Controlled data state, location, uniqueness, use, and / or operational authority and validation thereof through a transformable vectorset data structure

Abstract

Disclosed is a method, a device, a system and / or a manufacture of controlled data state, location, uniqueness, use, and / or operational authority and validation thereof through a transformable vectorset data structure. In one embodiment, a vectorset comprises n vectors each having an array of two or more data compartments with at least one attribute-value pair. The vectorset may evolve as it changes state, for example through tensor transformation. The vectorset includes one or more seal hashes that seal one or more data compartments, for example according to a sealing schema specifying a vector seal stored in a terminal index of the array of each vector generated as the output of a hash function. The vectorset and sealing schema may be used to prove the state of stored data, location data, constrain and validate operations on the data, and maintain uniqueness of the vectorset across a network of connected devices.

Description

CONTROLLED DATA STATE, LOCATION, UNIQUENESS, USE, AND / OR OPERATIONAL AUTHORITY AND VALIDATION THEREOF THROUGH A TRANSFORMABLE VECTORSET DATA STRUCTUREFIELD OF TECHNOLOGY

[0001] This disclosure relates generally to data processing devices, data storage data structures and / or cybersecurity, and, more particularly, to a method, a device, and / or a system of controlled data state, location, uniqueness, use, and / or operational authority and validation thereof through a transformable vectorset data structure.BACKGROUND

[0002] It can be challenging to maintain the state of data within a data processing system and / or device, especially a system of networked devices each which have data processing and storage capabilities, e.g., a collection of client devices and servers communicating over one or more networks. For example, some existing methods utilize a file system to copy and transmit data when one computer requests data from another computer. It can be similarly difficult to control the location of data and copies of that data.

[0003] Another challenge may be constraining the ability for a data processing system such as a computer to perform operations on the data, and thereafter validating that the constraints were effective and / or that the computer did not operate outside of its authority. A related challenge is defining permissible use of data and verifying use of data. Generally, once a copy of data is made and sent, little or no control may be able to be exercised over it.

[0004] Yet another challenge is proving ownership of data, especially data representing a digital asset or digitally represented physical asset. Historically, centralized access control systems have played some role in restricting initial access to data, especially in file systems. But such access control systems are often are not capable of the controlling the data once access is permitted and a copy of the file is transmitted to the requestor. As a result, there is no control over location of the data, processing of the data, and / or uniqueness is difficult to maintain. Access control systems also may be subject to vulnerability in that permissions are often hierarchically defined such that once a user is permitted past a point in the hierarchy all data below the access point or directory is available. While distributed databases have provided some level of granularity of control (e.g., protecting a data field rather than a file), queried data once released can be copied and operated on in almost any way by the querying computer. If a copy of the database is made, it can be difficult or impossible to ensure a computing system maintaining the database copy does not make unauthorized uses of its data, or alterations to it. This ease of copying can be seen as one of the factors leading to the devaluation of digitally available multimedia content, from research papers to music. Such challenges have put similar pressure on individuals, enterprises, and governments to securely store, transmit, and use data such as private financial information, trade secrets, and even national secrets.

[0005] These challenges manifest in another related context: storing and moving digital value and / or digital assets. Digital value and / or assets require a form of scarcity to maintain their value, and therefore anti-copying (e.g., unrestricted copying resulting in counterfeiting) and processing restriction mechanisms (e.g., inadvertent or malicious changes in ownership). Digital value in centralized systems has been historically tracked in centralized ledgers through relational databases.

[0006] However, some distributed success for value representation and storage has been achieved with distributed leger technology (DLT), in which elaborate encryption methods, infrastructure sharing schemes, and database consensus mechanisms work together to ensure that one version of a ledger at a given time is a “source of truth,” most notably Bitcoin, Ethereum, or “private blockchains” such as Hyperledger or Chorda. These systems may be subject to relatively slow transactions speeds (compared with centralized or parallel- processed systems), may be subject to lost assets (e.g., a user misplaces a private key that control database entries having value), and / or may utilize a large amount of electricity due to “mining” which incentivizes processing nodes to participate in the DLT network. Many DLT-based systems also publish data to all users of the system, eroding data and financial privacy. Transaction data is often replicated and sent to every node for processing. Although only one or some nodes will be selected as the “source of truth” for a given time period (which may be measured in blocks), the data itself is generally outside the control of the “owner”. For example, while in possession of the any of the DLT nodes, such nodes can perform any operations on the data. In fact, the DLT nodes often store an entire copy of the DLT database and its entire history, or in rare cases substantial portions of the database referred to as “shards”, that give them complete visibility and ability to process the data.

[0007] While DLT networks are often successful at maintaining an agreed upon ‘state’ of the database, the state is generally ‘global’ in the sense that a collection of transactions must make it into a ‘block’, rather than individual. The DLT therefore has little or no restriction on copies or processing, but rather rules for determining “which copy will matter” when the consensus mechanism resolves. However, such DLT networks arc also subject to occasional disagreement in the consensus mechanism, cither inadvertently (e.g., a “soft fork”) or intentionally (e.g., “a hard fork”), undermining the value proposition of a guaranteed state and source of truth.

[0008] One attempt at controlling the data within the DLT are structures referred to as “smart contracts”. These self-executing contracts become embedded in the DLT and resolve according to their terms when processed by each node. However, smart contracts generally are only effective at controlling data within the ledger. They are also generally rigid and once defined may not be able to be changed. In some cases, the inflexibility is desired (e.g., the inherent constraints of contracting), but in many others it is detrimental and diverges from the expectations of controlling real-world assets or the flexibility for one or both parties to make limited changes as new circumstances arise.

[0009] As a result, new devices, system, and / or methods are needed and economically valuable for maintaining (i) the state of data, (ii) the location of data, (iii) the uniqueness of data, and (iv) the ownership of data. Similarly, new devices, systems, and / or methods are needed and economically valuable for (v) constraining the authority of computers to operate on data (vi) constraining use data, and / or (vii) validatingsuch constraints were effective. One or more of these challenges arise in a wide array of valuable context, from controlling and establishing scarcity of multimedia, to maintaining trade secrets, and to establishing value within a digital commodity and / or medium of exchange. In addition, these goals are further enhanced in value when made granular, scalable, resource efficient, and / or secure yet flexible.SUMMARY

[0010] Disclosed are a method, a device, and / or a system of controlled data state, location, uniqueness, use, and / or operational authority and validation thereof through a transformable vectorset data structure.

[0011] In one embodiment, a data structure for secure transmission, processing, and / or storage of data includes a vectorset that includes n vectors, each vector of the vectorset including two or more data compartments, and each data compartment of the two or more data compartments comprising an attributevalue pair. The data structure further includes a vectorset identifier stored in a first data compartment of a first vector of the vectorset such that the vectorset may be uniquely addressed within a computing memory, and a vector designator stored in an initial index of the vector such that a second vector of the vectorset may be individually addressed within the vectorset. The vectorset also includes a vector seal stored in a terminal index of each vector of the vectorset. The vector seal includes a first hash value generated as an output of a first hash function, with hash inputs to the first hash function comprising one or more other data compartments of the second vector of the vectorset in which the vector seal is stored. The n vectors may include a seal vector including at least one data compartment storing a hash value generated as the output of the first hash function, with hash inputs to the first hash function including a value extracted from the attribute-value pair of at least one data compartment of each other vector of the vectorset. The vectorset also includes a vectorset hash including a third hash value generated as an output of a second hash function, with hash inputs to the second hash function comprising each vector seal of each vector within the vectorset.

[0012] The data structure may further include N instances of the vectorset defining a tensor space having at least three dimensions. A data operation that may include a read operation, a write operation, an update operation, and / or a delete operation may perform a tensor transformation on an Nth instance of the vectorset to generate an Nth+1 instance of the vectorset reflecting completion of the data operation. For at least one vector of the Nth+1 instance of the vectorset, the hash inputs to the first hash function generating the vector seal of the Nth+1 instance of the vectorset may further include a previous instance of the vector seal from the Nth instance of vectorset, to immutably associate the Nth instance of the vectorset with the Nth+1 instance of the vectorset. At least one of the one or more data compartments stores a use policy specifying a controlled operation. The controlled operation may include a permissible use of data of the vectorset, an access right to the data of the vectorset, an access right to data referenced by the vectorset, and / or a CRUD permission for the data of the vectorset stored within the vectorset. The controlled operation may apply to a controlled portion that is (i) all of the data of the vectorset, (ii) a vector of the vectorset, and / or (iii) at least one data compartment of the vectorset.

[0013] The use policy may include a terms data, the terms data at least one of a user UID authorized to perform the controlled operation, a location at which the controlled operation can be executed, a time at which the controlled operation can be executed, and / or a number of times which the controlled operation can be executed by a computer processor. The use policy may further include a conditions data, and the conditions data may include one or more conditionals that (i) must be satisfied prior to execution of the controlled operation, and / or (ii) upon satisfaction update the terms of the use policy.

[0014] For the vectorset, n may be greater than or equal to five and, the n vectors of the vectorset further include: (i) an identity vector usable to store data sufficient to uniquely address the vectorset, referred to as an iD vector, comprising the vectorset identifier stored in a first data compartment of the iD vector, optionally a vectorset version stored in a second data compartment of the iD vector, and optionally a rights data stored in a third instance of a data compartment of the iD vector; (ii) an owner vector usable to store ownership information associated with the vectorset, referred to as an oW vector, the oW vector comprising an owner identifier stored in a first instance of a data compartment of the oW vector, and optionally an owner name stored in a second instance of the data compartment of the oW vector; (iii) a transaction history vector usable to store information associated with a transaction history of the vectorset, referred to as a heredity vector and / or referred to as an hY vector, the hY vector comprising a transaction data stored in one or more data compartments of the hY vector; and / or (iv) a use policy vector, referred to as an uP vector, comprising the use policy.

[0015] The transaction data may further include (i) a sending data including a sending user identifier and / or a sending device identifier, (ii) a receiver data including a receiving user identifier and / or a receiving device identifier, and / or (iii) a transaction identifier. The terms data may include an authorized user identifier, an authorized time, an authorized location, and / or an authorized use extent. The uP vector may optionally include a use policy reference to an instance of the use policy stored outside of the vectorset.

[0016] The data structure may also have n greater than or equal to ten. The vectorset may further include: (i) an origin vector usable to store data associated with an origin of the vectorset, referred to as an oG vector, the oG vector comprising an origin data stored in one or more data compartments of the oG vector (the origin data may include an origin location identifier, an origin timestamp, and / or an originating user identifier); (ii) a state vector comprising data associated with a current storage location and / or a current status (e.g., secured, in a static state, being processed, being utilized by a user, etc.) of a physical positioning and / or a logical positioning of the vectorset, referred to as an sA vector, the sA vector comprising a state data stored in one or more data compartments of the sA vector; (iii) a content vector usable to store data associated with one or more applications utilizing the vectorset as a data resource, referred to as an nT vector, the nT vector comprising an application data of at least one of the one or more applications, and optionally comprising an authentication data comprising a passphrase hash and / or an encryption key for communication with at least one of the one or more applications; (iv) a context vector usable to store data associated with an operational context and a functional context for the vectorset, referred to as an xT vector, the xT vector comprising an authorized behavior of the vectorset, and / or (v) a vectorset type vector, referred to as a genotype vector and a gT vector, the gT vector comprising a creation application identifier of an application of the one or more applications that created the vectorset, a vectorset type specifying a class of the vectorset and / or a type of the vectorset.

[0017] The state data may include a location state seal that is the output of the first hash function with inputs comprising a state seal and a location identifier of the current storage location. The state data may optionally include a storage device identifier, a location description, and / or the owner identifier.

[0018] The vectorset may be associated with a user profile of a user, and may have n set be greater than or equal to five, where the vectorset may further include: (i) a user type vector, referred to as uS, including a user role for an application that includes reading from and / or writing to the vectorset, an application API key for utilization and / or development of the application, and a recovery code usable to recover the user profile of the user (the owner identifier may include a unique identifier of the user profile of the user); and / or (ii) a permission vector usable to store data associated with permissions of a user profile associated with the vectorset, referred to as a pN vector, the pN vector comprising an authorized behavior of the user profile and / or an authorized target for the authorized behavior of the user profile. The authorized behavior of the user profile may be a login to the application, a vectorset acquisition action for acquiring ownership of the vectorset, a vectorset disposition action for disposition of the vectorset, and / or a process utilization action associated with the application.

[0019] The hash inputs to the first hash function may further include a data compartment of a different vector of the vectorset that is different from the vector of the vectorset in which the vector seal is stored. An instance of the hash value may be generated as the output of the first hash function, with hash inputs of the first hash function comprising (i) a secret value generated by a device on which the vectorset is currently stored, and optionally (ii) the transaction data. The instance of the hash value may be utilized as a state indicator of the location of the vectorset. The state indicator of the location of the vectorset may be transmitted to a server for later evidence of a unique instance of the vectorset associated with at least one of the N instances of the vectorset. The seal vector may include at least x data compartments, where x is greater than or equal to the greatest number of data compartments of any other vector of the vectorset, and wherein each index value of each data compartment of the seal vector stores the hash value as the output of the first hash function with hash inputs comprising the value of each matching index value of the data compartment of each other vector of the vectorset.

[0020] The vectorset may further include (i) a face value for use as a digital currency, (ii) a physical object associated with the vectorset, and / or (iii) a non-fungiblc digital object associated with the vectorset. The nT vector may optionally include a run sequence value that is less than or equal to a run max value, and optionally the run max value. The vectorset may include a content data to be controlled by the use policy. The content data may include a document, an audio file, a video file, an artificial intelligence model, and / or a dataset.

[0021] The vectorset be and / or include an n by m dimensional matrix, with the n vectors each forming a row, and each vector of the vectorset comprising m data compartments resulting in m columns, each of the two or more data compartments of each of the n vectors defined at an intersection of each row and each column. The n by m dimensional matrix may include a row designation column wherein each data compartment of the row designation column comprising at instance of each of the vector designator of each vector of the vectorset, and / or a seal index wherein each data compartment of the seal index comprising an instance of the vector seal of each vector of the vectorset.

[0022] In another embodiment, a method for secure transmission, processing, and / or storage of data includes initiating a data transaction to write, update, and / or a delete data stored within a vectorset, whereinthe vectorset including n vectors, each vector of the vectorset including: (i) two or more data compartments, each data compartment of the two or more data compartments each comprising an attribute-value pair of each data compartment of the vectorset; and (ii) a vectorset identifier stored at least one data compartment of the vectorset, such that the vectorset may be uniquely addressed within a computing memory. The method generates a data operation that is and / or includes a write operation, an update operation, and / or a delate operation on a first attribute-value pair of a first vector of the n vectors. The method then extracts a first set of inputs from the first vector, the first set of inputs comprising a value of the first attribute-value pair of the first vector and a value of each of one or more other attribute-value pairs of the first vector, inputs the first set of inputs into a hash function, and outputs a first hash value as a first seal hash. The method then stores the first hash value in a second attribute-value pair of the first vector to evolve the vector and define a vector seal of the first vector enabling detection alteration of data within the first vector without a valid instance of the update transaction.

[0023] The vectorset may further include a use policy. The method may also determine a user identifier of a user profile associated with initiation of the data transaction, query the use policy of the vectorset, determine the data operation includes a controlled operation that the user profile is permitted to initiate, and determine a controlled portion of the vectorset to which the controlled operation may be applied, the controlled portion of the vectorset comprising a controlled vector, a controlled compartment, and / or a controlled attribute-value pair. The user profile may then be authenticated, and the controlled operation on the controlled portion of the vectorset executed. The data transaction may include the controlled operation.

[0024] The vectorset further may further include a seal vector, and the method may further include extracting a second set of inputs comprising the value of the first attribute-value pair of the first vector and a value from a first attribute-value pair of a second vector; inputting the second set of inputs into the hash function; outputting a second hash value; and / or storing the second hash value in a first attribute-value pair of the seal vector to enhance detection of alteration of data within the vectorset without a valid instance of the data transaction.

[0025] The method may also initiate a new data transaction from a first data processing system to update the value of the first attribute-value pair of the first vector; extract a plurality of seal hashes from the vectorset, the plurality of seal hashes comprising the first hash value from the first vector and the second hash value from the seal vector; transmit the plurality of seal hashes to a second processing system; and / or recalculate and store within the vectorset the first hash value of the first vector to result in an updated first vector hash and recalculate the second hash value of the seal vector to result in an updated second hash value.

[0026] The method may still further transmit the vectorset to the second processing system; recalculate the plurality of seal hashes to result in updated seal hashes; compare the plurality of updated seal hashes to the plurality of seal hashes; and determine that the first data processing system executed within a processing authority associated with the first data processing system, through determination that only the first seal hash and the second seal hash were updated within the plurality of updated seal hashes to implicate sole update of the first-attribute-value pair of the first vector.

[0027] The method may also select a first data compartment of the vectorset including an attribute-value pair of the first data compartment; determine a first seal pair comprising the first data compartment and a second data compartment comprising an attribute-value pair of the second data compartment; and / or determine a second seal pair comprising the first data compartment and a third data compartment comprising an attribute-value pair of the third data compartment. The first seal pair may include a data structure adjacency of the first data compartment to the second data compartment and the second seal pair that includes a data structure adjacency of the first data compartment to the third data compartment. The method may then extract a value of the first data compartment and a value of the second data compartment and input the value of the first data compartment and the value of the second data compartment into the hash function to generate a third hash value representing the first seal pair;

[0028] The value of the first data compartment and a value of the third data compartment may be extracted, and the value of the first data compartment and the value of the third data compartment input into the hash function to generate a fourth hash value representing the second seal pair. The method may then store the third hash value and the fourth hash value in association with the vectorset, to enable detection of unauthorized alteration in the value of the first data compartment.

[0029] The first set of inputs that are input into the hash function may further include a previous instance of the first seal hash from a previous state of the vectorset, referred to as an Nth-1 instance of the vectorset, to cryptographically tie the Nth-1 instance to a present instance of the vectorset, referred to as an Nth instance of the vectorset. The first set of inputs that are input into the hash function may further include at least one value of an attribute-value pair of a different vector of the vectorset that differs from the first vector, to establish a seal cross-dependency between at least two or more vectors of the vectorset.

[0030] Each vector of the vectorset may include an instance of a seal hash of each vector and and / or each data compartment of each vector of the vectorset comprising a seal grouping of each data compartment of each vector of the vectorset. The method may then extract a plurality of hash values that includes (i) the seal hash of each vector and / or (ii) the seal grouping of each data compartment of each vector of the Nth instance of the vectorset; generating a secret value; and store the secret value on a computing memory of a first device on which the vectorset is stored.

[0031] The method may also input the plurality of hash values and the secret value into the hash function to generate a vectorset hash representing a static state of the Nth instance of the vectorset and then receive the vectorset hash on a second device over a network as a static state verification hash. A location change of the vectorset may be initiated from the computing memory of the first device to a computing memory of a third device, and the vectorset and the secret value may be received at the second device.

[0032] The method may include recalculating the vectorset hash of the vectorset received on the second device as a recalculated vectorset hash and comparing the static state verification hash and the recalculated vectorset hash. The method may also include determining a match between the state verification hash and the recalculated vectorset hash to prove both (i) the static state of the vectorset was maintained and (ii) the vectorset was uniquely maintained in the first device and authorizing transfer of the vectorset from the first device to the third device.

[0033] I yet another embodiment, a method of an evolving vectorset includes initiating a location change of a vectorset from a computing memory of a first device to a computing memory of a second device. The vectorset includes n vectors (each vector of the vectorset comprising two or more data compartments, and each data compartment of the two or more data compartments comprising an attribute-value pair) and a vectorset identifier stored in at least one data compartment of the vectorset, such that the vectorset may be uniquely addressed. The vector may also include a state vector usable to store data associated with a current location and a current status of a physical positioning and / or a logical positioning of the vectorset, referred to as an sA vector, the sA vector including a state data stored in one or more data compartments of the sA vector. The vector may also include a plurality of seal hashes that include (i) a seal hash of one or more vectors of the vectorset and / or (ii) a seal grouping for one or more data compartments of the vectorset.

[0034] The method may generate a data operation including a write operation, a delete operation, and / or an update operation, on a first attribute-value pair of the sA vector, and extract a first set of inputs from the sA vector, the first set of inputs comprising a value of the first attribute-value pair of the sA vector and optionally a value of each of one or more other attribute-value pairs of the sA vector;

[0035] The first set of inputsm may be then input into a hash function and a first hash value output as a location state seal. The plurality of seal hashes may include a first seal hash. The location state seal may be stored in a second attribute-value pair of a first vector and the sA vector, to evolve a state of the sA vector and to enable detection of an unauthorized change in location of the vectorset.

[0036] The method may also include transmitting the location state seal to a third computing device and storing the location state seal on the third computing device, receiving the vectorset on the third device from the first device; and / or authenticating the first device from which the vectorset was received.

[0037] The method may determine a match between a device identifier of the first device and a device identifier stored in the sA vector, recalculate the location state seal as a recalculated location state hash, compare the location state seal and the recalculated location state seal; and / or determine a match between the location state seal and the recalculated location state seal to prove the location of the vectorset was maintained in the first device.

[0038] The method may further inciude inputting a plurality of hash values comprising the first seal hash into the hash function to generate a vectorset hash representing a static state of the vectorset; receiving the vectorset hash on a second device over a network as a static state verification hash; and determining a match between the state verification hash and the recalculated vectorset hash to prove the static state of the vectorset was maintained after transfer to the first device.

[0039] The hash inputs to the hash function further may include a secret value, and the method may further include receiving the vectorset and the secret value at a third device, recalculating a vectorset hash of the vectorset received on the third device as a recalculated vectorset hash, comparing the state verification hash and the recalculated vectorset hash ad determining a match between the state verification hash and the recalculated vectorset hash to prove a static state of the vectorset was maintained in the first device. The method may then authorize transfer of the vectorset from the first device to the second device.

[0040] In one example, the vectorset may further include a cryptographic tie to a user profile, an authentication data usable to authenticate the user profile; and / or an encryption data comprising one or more encryption keys for communicating with one or more applications.

[0041] In another example, the vectorset may include a sending device ID and / or a sending user ID, a receiving device ID and / or a receiving user ID, and a seal hash incorporating as a hash input (i) the sending device ID and / or the sending user ID, and / or (ii) the receiving device ID and / or the receiving user ID. The vectorset may also include a run sequence value, a run max value, and / or a run sequence value.Alternatively, or in addition, the vectorset may include a seal hash incorporating as an additional hash input a run sequence value, a run max value, and / or a run sequence value.

[0042] The state data may include a location state seal that is the output of the hash function with the hash inputs further comprising a state seal and a location identifier of a current storage location. The state data optionally may include a storage device identifier, a location description, and / or an owner identifier.BRIEF DESCRIPTION OF THE DRAWINGS

[0043] The embodiments of this disclosure are illustrated by way of example and not limitation in the figures of the accompanying drawings, in which like references indicate similar elements and in which:

[0044] Figure 1 illustrates a vectorset data structure usable as a data storage container to store a wide variety of data, the vectorset comprised of ‘n’ vectors each having one or more indexes, each vector comprising one or more data compartments each comprising one or more attribute-value pairs, the vectorset optionally arranged in an n by m matrix in which the number of indices of each vector are equal resulting in two or more index vectors, according to one or more embodiments.

[0045] Figure 2 illustrates seal hashing of the vectorset of Figure 1 to enable data security integrity in storage, transmission, processing, and / or enabling other benefits shown and described herein, including illustration of a seal set including vector hashes, index hashes, and / or a vectorset hash (which may also be referred to herein as a vectorset seal), according to one or more embodiments.

[0046] Figure 3 illustrates transformation of the vectorset over a series of states, denoted N, including tensor transformations of the vectors of the vectorset such as data operations modifying attribute-value pairs to enable controlled state update and / or validate operations thereon, according to one or more embodiments.

[0047] Figure 4 illustrates hash forwarding from a previous state (N-l) and incorporation of a forwarded hash into the seal hash of a new state (N) to bind the series of states of the vectorset and / or prove continuity of evolution, according to one or more embodiments.

[0048] Figure 5 illustrates a vectorset with vectors of various index length, including calculation of an index hash utilizing the vectors of various index length, according to one or more embodiments.

[0049] Figure 6A illustrates a sealing schema in which each of one or more data compartments may be associated with a seal set comprised of two or more seal pairs which may be usable to detect and / or indicate a location of a modification to the vectorset without revealing the modification to an outside system, according to one or more embodiments. Also illustrated is a vectorset hash and secret value usable to enhance proof of static state and / or uniqueness, according to one or more embodiments.

[0050] Figure 6B illustrates an abbreviated notation for the sealing schema of Figure 6A, according to one or more embodiments.

[0051] Figure 6C illustrates a shorthand notation for the sealing schema of Figure 6A and Figure 6B, according to one or more embodiments.

[0052] Figure 7A illustrates a sealing schema in which a vector seal (e.g., of a row vector) and an index hash (e.g., of an index vector), for example as illustrated in Figure 2, which may be identified as seal trips and cross-rcfcrcnccd to determine a modification location which can be tested against modification authority, according to one or more embodiments.

[0053] Figure 7B illustrates a sealing schema, similar to Figure 6C, in which the seal pairs of the seal sets are identified as seal trips to determine the modification location, according to one or more embodiments.

[0054] Figure 8 illustrates an instantiation of the vectorset of Figure 1 in which vectors of the vectorset are designated for organization and storage of particular data, including assignment of a vectorset uniqueidentifier within an identity vector and storage of content within a content vector, to data allocation enabling granular security and controlled operations thereon, according to one or more embodiments.

[0055] Figure 9 illustrates an example vectorset origination process, including a cryptographic tie between a proof, generation transaction data, and the vectorset, according to one or more embodiments.

[0056] Figure 10 illustrates a vectorset initiation process flow, according to one or more embodiments.

[0057] Figure 11 illustrates a second vectorset initiation process flow that may be a continuation of the vectorset initiation process flow of Figure 10, according to one or more embodiments.

[0058] Figure 12 illustrates a vector and / or vectorset hash process flow, according to one or more embodiments.

[0059] Figure 13 illustrates a system authority enforcement process flow, according to one or more embodiments.

[0060] Figure 14 illustrates a vector state enforcement process flow, according to one or more embodiments.

[0061] Figure 15 illustrates a vector state enforcement process flow that may be a continuation of the vector state enforcement process flow of Figure 14, according to one or more embodiments.

[0062] Figure 16 illustrates a vectorset state enforcement process flow, according to one or more embodiments.

[0063] Figure 17 illustrates a vectorset state enforcement process flow that may be a continuation of the vectorset state enforcement process flow of Figure 16, according to one or more embodiments.

[0064] Figure 18 illustrates a vectorset use policy process flow, according to one or more embodiments.

[0065] Figure 19 illustrates a vectorset use policy process flow which may be a continuation of the vectorset use policy process flow of Figure 18, according to one or more embodiments.

[0066] Figure 20 illustrates a use policy storable within and / or in association with the vectorset, according to one or more embodiments.

[0067] Figure 21 illustrates an instance of the vectorset for storing data utilized by an application, comprising vector designations including: an identity vector (referred to as an iD vector); an owner vector (referred to as an oW vector); an origin vector (referred to as an oG vector); a vectorset type vector (referred to as an gT vector); a heredity vector (referred to as an hY vector); a permission vector (referred to as an pN vector); a state vector (referred to as an sA vector); a content vector (referred to as an nT vector); a context vector (referred to as an xT vector); a use policy vector (referred to as an uP vector); and a seal vector, according to one or more embodiments.

[0068] Figure 22 illustrates an instance of the vectorset for representing an evolving state of a user profile including secure storage of important information related to the user profile, including vectorset ownership data, authentication data and / or encryption data, according to one or more embodiments.

[0069] Figure 23 illustrates a system for storing, moving, transacting with, controlling state of, using data from, and authorizing data operations on the vectorset, including a set of one or more devices such as clientdevices and a set of one or more devices and / or systems such as server computers, according to one or more embodiments.

[0070] Figure 24 illustrates the device such as the client device of Figure 24 which may store the vectorset, perform operations on and tensor transformations on the vectorset, evolve the state of the vectorset, seal the vectorset, transact with the vectorset, and / or perform other related data processing operations, according to one or more embodiments.

[0071] Figure 25 illustrates the device and / or system of Figure 23, for example the server, usable to store the vectorset, process the vectorset, perform operations and tensor transformations on the vectorset, confirm static state maintenance of the vectorset, assess modification authority of the vectorset, seal the vectorset, and / or perform other related operations, according to one or more embodiments.

[0072] Other features of the present embodiments will be apparent from the accompanying drawings and from the detailed description that follows.DETAILED DESCRIPTION

[0073] Disclosed are a method, a device, and / or system of controlled data state, location, uniqueness, use, and / or operational authority and validation thereof through a transformable vectorset data structure. Although the present embodiments have been described with reference to specific example embodiments, it will be evident that various modifications and changes may be made to these embodiments without departing from the broader spirit and scope of the various embodiments.

[0074] In this disclosure, the 100 number series (e.g., 100 through 199) are generally related to data structures and principles and concepts thereof. The 200 number series (e.g., 200 through 299) is generally utilized in conjunction with, and reserved for, a specialized instance of the vectorset 2100, as shown and described in Figure 21 and as also referenced throughout the various embodiments. However, the 200 number series may apply to any instance of the vectorset 100. For example, in one or more embodiments all vectorsets 100 may include a vectorset identifier 201, even if not otherwise organized like the vectorset 2100. Similarly, the 300 number series is generally utilized in conjunction with a specialized instance of the vectorset 2200 usable in association with a digital user identity, as shown and described in Figure 22. The number series 400 is generally reserved for the use policy 400 and related elements, as shown and described in conjunction with the embodiment of Figure 20. The number series 500 through the number series 900 (e.g., 400 through 999) is generally used in conjunction with devices, systems, and / or other processes herein, for example as shown and described in Figure 23, Figure 24, and Figure 25.

[0075] Figure 1 illustrates a vectorset 100 that is a data structure usable to store data, secure data, control modification of data, maintain uniqueness of data, and / or maintain ownership data, according to one or more embodiments. The vectorset 100 may define an array of vectors collectively associated and / or bound within the data structure, but which may be independently queried and controlled with capability-based granular data access and security including implementation with an embedded use policy (e.g., as shown and described in conjunction with Figure 20). The vectorset 100 may be evolved and / or transformed to change states, forming a hyperdimensional vector storage container. As shown and described throughout the present embodiments,various computational methods, devices, and systems may be used to transact in, operate on, control, and / or ensure integrity of the data within the vectorset 100.

[0076] In one or more embodiments, the vectorset 100 includes one or more vectors 102. Each vector 102 may comprise two or more data compartments 104. Each data compartment 104 may comprise one or more attribute -value pairs 105 that store a data attribute (e.g., a “field”) and an associated value. The value may store data of any time, including a string, a number, a floating point number, an array, a binary large object (BLOB), a reference, a pointer, and / or other data types. There may be an arbitrary number of vectors 102 within the vectorset 100, denoted in Figure 1 as n vectors 102. For example, the vector 102 that is the second vector may be referred to herein as the vector 102v2, and the vector 102 that is the ‘nth’ vector may be referred to herein as the vector 102vn.

[0077] Each vector 102 may include one or more indexes, each index specifying a data compartment 104 and / or attribute-value pair 105 generally arranged in sequence. Each vector 102 may have an arbitrary number of indices. The indices may be referred to as il, i2, etc., up to an arbitrary number im. A particular data compartment 104 of the vectorset 100 may be referred to by its position within a vector 102 and an index, for example the data compartment 104(2,2) may refer to the data compartment 104 that is in the vector 102v2 and in the second index (i2). Although standard nomenclature of the computing arts may generally refer to indices starting at ‘O’, the disclosure herein generally utilizes an initial index of ‘ 1’ unless otherwise noted.

[0078] In one or more embodiments, different vectors 102 within the vectorset 100 (e.g., the vector 102vl , the vector 102v2) may have differing numbers of indices, for example as shown and described in conjunction with the embodiment of Figure 5. However, in one or more embodiments, the vectorset 100 may include an equal number of indices in each vector 102. Where the vectorset 100 may include an equal number of indices in each vector 102, the vectorset 100 may define an n by m matrix, referred herein as the matrix 101. Unused data compartments 104 may utilize nulls or other values to designate present non-use.

[0079] The vectorset 100 may organize the vectors such that the indices define columns, which may be referred to as an index vector 106. Where the vectorset 100 defines a matrix 101, the vectors 102 may be alternatively referred to as a row vector 103 and the index vector 106 may be alternatively referred to as the column vector 107.

[0080] The vectorset 100 may be defined in computer memory and / or implemented with a variety of commercially available databases. However, in one or more embodiments the vectorset 100 may be built on a key -value store, wherein each vector 102 may be stored as an array of values with attributes in a schema associated with the array of values. This may provide one of the faster and more capable implementations, and further enable granular query and control of the data structure due to query addressability of each key.

[0081] Each of the vectors 102 and / or indices may be specialized in storing certain types of data, and / or organizing data for performance of regulated and / or secured data operations thereon (e.g., the data operations 134 and / or the controlled operation 135). Such organization may depend on the intended use or data to be stored, or which applications (e.g., application 602) will use the vectorset 100 as a data resource. There may be cross-references between and among vectors 102 and data compartments 104 within a vectorset 100 and / or between and among multiple vectorsets 100. In addition, each vectorset 100 may change in state over time,including controlled authorization checks as to the state change and modification of the data within the vectorset 100. Many of the instantiations, uses, and advantages will now be described, and still others will be apparent to one skilled in the art of data science, computer science, and / or software engineering.

[0082] Figure 2 illustrates seal hashing of the vectorset 100 of Figure 1 to enable data integrity, data immutability, static state maintenance, dynamic modification authority enforcement, and / or other benefits shown and described herein, according to one or more embodiments. Figure 2 includes illustration of a set of seal hashes 110 including vector hashes 112, index hashes 116, and a vectorset hash 120, according to one or more embodiments. The data within the vectorset 100 may be sealed according to a sealing schema, which may also be referred to as a seal schema and / or a hashing schema. Depending on data security needs and objectives of data storage, data stored within one or more vectors 102 and / or one or more index vector 106 may be ‘sealed’ such that change in the data can be detected with reference to the resulting seal hash 110. The seal hash 110, when combined with methods to detect alteration, can be said to make the data “immutable”, or, more accurately, that changes can be detected, rejected, and / or rolled back to a previously accepted state.

[0083] In one or more embodiments, each vector 102 may be sealed. One or more attribute-value pair 105 of one or more data compartments 104 of the vector 102 may be extracted (as a hash input 108) and input into a hash function 109 to output a seal hash 110. However, in one or more embodiments, every attributevalue pair 105 of every data compartment 104 of the vector 102 is extracted and input into the hash function 109 to output the seal hash 110 (with the exception of any data compartment 104 in which the seal hash 110 is to be stored). For example, as shown in Figure 2, from the vector 102vl may be extracted the value of data compartment 104(1,1), the data compartment 104(1,2), etc., up to the data compartment 104(1, m- ), each of which are collectively input into the hash function 109. The output is the seal hash 110 placed in the data compartment 104(1, m). The seal hash 110 of a vector 102 may be referred to as a vector hash 112, and specifically in this case as the vector hash 112(vl). It should be noted that additional inputs to the hash function 109 also may be provided to the hash function 109 generating given seal hash 110 and / or the vector hash 112, for example a previous seal hash 110, a secret value 118, or values from other vectors 102, as will be further shown and described herein.

[0084] Throughout the present figures, an arrow that includes open triangle may illustrate extraction or production of a value (generally as a hash input 108 and / or output of a hash function 109), and an arrow that is a closed triangle may illustrate input of a value into something (e.g., to the hash function 109) and / or storage of the value (e.g., as a value of an attribute-value pair 105).

[0085] Where two or more of the vectors 102 are sealed, a resulting seal index 113 may be defined. The seal index 113 may be a data vector comprising each of the vectors seals 112, even if such vector seals 112 are stored in disparate indices between vectors 102 of the vectorset 100. For example, and briefly referring to Figure 5 for illustration, if each of the vectors 102 of Figure 5 were sealed, the seal index 113 would comprise the data compartment 104(1,5), the data compartment 104(2,2,), the data compartment 104(3,7), and the data compartment 104(4,4). In such example, the data compartment 104(n,m) would likely be reserved for a vectorset hash 120, as described below.

[0086] However, where the vectorset 100 defines the matrix 101, the seal index 113 may include the same index for each vector 102. For example, and referring briefly to the embodiment of Figure 21, the vector seal 112(1,9) through the vector seal 112(9,9) occur within the same column vector 107.

[0087] Figure 2 further illustrates that values of attribute-value pairs 105 may be extracted from intervector 102 data compartments 104 (as hash inputs 108) and sealed into a seal hash 110. For example, the values of the data compartment 104(1,1), the data compartment 104(2,1), and the data compartment 104(H- 1,1) may be extracted and put into the hash function 109 to output a seal hash 110. The seal hash 110 for a given index may be referred to as an index hash 116. In the present case, because the vectorset 100 defines the matrix 101, the index hash 116 may also be referred to as a “column hash.” Specifically, the resulting seal hash 110 may be referred to as the index hash 116(il).

[0088] Where two or more of the indices of the vectorset 100 are sealed (or, in one or more embodiments, all or all but one of the indices are sealed), a seal vector 117 may be defined. For example, in Figure 2, the seal vector 117 includes the index hash 116(il) in data compartment 104(n,l), the index hash 116(i2) in data compartment 104(7?.2). etc. The vectorset hash 120 may be a special case deviating from this pattern, according to one or more embodiments, and as further described below.

[0089] The seal hashes 110 (including, for example, the vector hash 112, the index hash 116, and / or the vectorset hash 120) may be utilized to detect one or more changes in data that occurred to at least one of the hash inputs 108 that were used to generate a particular seal hash 110. As a straightforward description, any change to a value of a data compartment 104 within vector 102vl would result in a changed vector 102(vl) if the vector hash 112(vl) was calculated with the changed value of the vector hash 112(vl). Similarly, any change to a value of a data compartment 104 within index vector 106(H) would result in a changed index hash 116(il) if the vector hash was calculated with the changed value of the index vector 106(H). In one or more embodiments, one or more of the seal hashes 110 may be transmitted or reported to illustrate proof of state, for example the state of a vector 102 and / or the state of the vectorset 100. As will be further described in conjunction with Figure 4, Figure 6A through Figure 6C, Figure 7A and Figure 7B, and throughout Figure 10 through Figure 19, the seal hashes 110 and their detection capability may be utilized by various systems, devices, and / or methods to assist in establishing the state of data, the location of data, uniqueness of that data, constraints on use of the data, and validation of each, including resulting implementations capable of secure recordation and maintenance of ownership, according to one or more embodiments. For example, the seal hashes 110 may be useful for executing tensor transformations 132 and / or data operations 134, and establishing a state of the vectorset 100, and / or proving a state of a vector 102 and / or the vectorset 100 (or other part thereof) was maintained or modified. In one or more embodiments, seal hashes 110 may be also be used as hash inputs 108 to output more seal hashes 110, which can be referred to as metahashes or metaseals. These can be used to effectively pinpoint a location of modification, especially where defined as a hierarchy and / or tree that can be traced to determine a modification location 144, as will be described.

[0090] The vectorset hash 120 may be a special instance of the seal hash 110 that is the output of the hash function 109, where the hash function 109 accepts as inputs (e.g., hash inputs 108) other instances of the seal hash 110. Specifically, as shown and described in conjunction with the embodiment of Figure 2, the vectorsethash 120 stored in data compartment 104(n,m) may be the output of a hash function 109 with hash inputs 108 that include each value of the seal index 1 13 (other than the vectorset hash 120) and each value of the seal vector 117 (other than the vectorset hash 120). The vectorset hash 120 may therefore also be a “metaseal”, or a seal of seals. In one or more embodiments, and where each (i) and every value of the vectorset 100 is incorporated as a hash input 108 into at least one seal hash 110, and (ii) such seal hashes 110 in turn act as hash inputs 108 incorporated into the vectorset hash 120, then as a result a change in any value of any attribute -value pair 105 of any vector 102 of the vectorset 100 will be detectable through the vectorset hash 120.

[0091] In one or more embodiments, any of the seal hashes 110 may have additional data inputs (as a hash input 108), which may be stored within or without the vectorset 100. For example, and as may be shown and described further throughout the present embodiments, the hash function 109 outputting the vectorset hash 120 may additionally include as data inputs 108 a secret value 118. The secret value 118 may be a number, an alphanumeric string, or other unpredictable or random data of sufficient complexity that it is difficult to guess or “brute force”. The secret value 118 may be generated on a vectorset-by-vectorset basis, may be generated on a state-by-state basis, and / or utilized according to other triggers and timings depending on the security need or level. The secret value 118 may be stored on a device or system storing the vectorset 100, may be securely stored in a separate device or system, and / or may be otherwise securely stored. Although not shown, it is possible to include a secret value 118 as an input to any of the hash functions 109 within the vectorset 100 including for individual seal groupings 115, for example as shown and described in conjunction with Figure 6A.

[0092] Figure 3 illustrates state change and / or tensor transformation of the vectorset 100, according to one or more embodiments. In one or more embodiments, the vectorset 100 may be represented by a state, referred to as the vectorset state 130 and denoted N. The vectorset 100 may act as a forward moving state machine, in which one or more data operations 134 update the state. The data operation 134 may include CRUD operations, for example a create operation (e.g., increase the size of a vector 102, add a data compartment 104 to a vector 102, add an additional vector 102, write a value of an attribute-value pair 105, etc.), a read operation (e.g., reading the value of one or more attribute-value pairs 105, extracting one or more values from attribute -value pairs 105, validating seal hashes 110, etc.), an update operation (e.g., change the value of an attribute -value pair 105, re-designate a vector designator designating a type of vector 102, etc.), and a delete operation (e.g., decreasing the size of a vector 102, deleting a data compartment 104 to a vector 102, deleting a vector 102, deleting the value of an attribute-value pair 105, etc.). Both the create operation and / or the update operation may be referred to as a write operation.

[0093] In one or more embodiments, the vectorset 100 represents a multi-dimensional and / or hyperdimensional tensor space that may vary “spatially” (e.g., degrees of data storage, such as the vectors 102), across vectors (e.g., index columns 117), and / or “temporally,” over time.

[0094] In Figure 3, the vectorset 100 is illustrated across five states, N-3, N-2, N-l, N, and N+l. For discussion purposes of the present example only, a state N may be a “present state” at a moment in time, with states prior to N representing previous states in time and states after N representing later states in time. In oneor more embodiments, “time” may be measured through sequential tensor transformations 132 and / or data operations 134. The tensor transformation 132 between states may be referred to with reference to the initial and ending state. For example, the tensor transformation 132(N-1,N) may denote the tensor transformation 132 of the vectorset from the vectorset 100N-1 to the vectorset 100N.

[0095] Figure 3 illustrates the evolution of the vectorset 100 through four tensor transformations 132. Specifically, in the tensor transformations 132(N-3,N-2) the data compartment 104(1, m) may be subject to a data operation 134, such as an update operation. In the tensor transformations 132(N-2,N-1) the data compartment 104(1,2) may be subject to a data operation 134, which may be repeated again during the tensor transformations 132(N-1,N). Finally, in the tensor transformations 132(N,N+1). the data compartment 104(1,1) may be subject to a data operation 134.

[0096] Although a single data operation 134 is shown for clarity of explanation in Figure 3, it will be recognized that multiple data operations 134 may occur from one state to another. Similarly, mathematical operations and vector mathematics may be executed and / on or performed on the vectorset 100 and / or the matrix 101. Conversely, simple read operation of a single attribute-value pair 105 may constitute a data operation 134 effecting a state update, e.g., where such reads are recorded in a use report data 440 or other data compartment 104, which may be enforced through the application 602 or, for operations by a server 700, a server-side application. During each tensor transformation 132, any of the seal hashes 110 shown and described in Figure 2 or throughout the present embodiments may be updated. Tensor transformation 1 2 and / or data operations 134 initiating tensor transformation 132 may be controlled such that vectorset state 130 changes in only certain triggering circumstances. In one or more other embodiments, state of individual elements of the vectorset 100 may be tracked for state (e.g., individual vectors 102), with certain thresholds initiating evolution of the vectorset state 130. For example, location state of the vectorset 100 may be tracked through a state vector 260.

[0097] Figure 4 illustrates a hash forward 140 which may be utilized to create dependency, continuity, and / or binding between states vectors 102 and / or the vectorset 100, according to one or more embodiments. In one or more embodiments, a seal hash 110 from a state (e.g., a state N) may be forwarded (e.g., the hash forward 140) to a next state (e.g., a state N+l) and stored within a data compartment 104 of the next state. In the present example, the vector hash 112(v 1) of the vectorset 100(N-l) in data compartment 104(1,4) of the vectorset 100(N-l) may be extracted and stored in the data compartment 104(1,3) of the vectorset 100N. The extracted and stored “previous” seal hash 110 may then act as a hash input 108 for the vector seal 112(vl) of the vectorset 100(N), which may create a cryptographically provable dependency within the forward moving state of the vectorset 100. In a next state evolution, the vector hash 112(vl) of the vectorset 100)(N) in data compartment 104(1,4) of the vectorset 100(N) may be extracted and stored in the data compartment 104(1,3) of the vectorset 100(N+l), with a new vector hash 112(vl) of the vectorset 100(N+l) then being generated. Attention is briefly drawn to Figure 21 for an additional illustration, in which each of the vector 102vl through the vector 102v9 (e.g., the identity vector 200 through the policy vector 290) may store a previous vector hash 112(N-1), stored in data compartments 104 at index 8 each vector 102. The previous vector hashes112(N-1) may then be incorporated as hash inputs 108 resulting in a vector hash 112(N), which then may be each stored at data compartments 104 at index 9.

[0098] Although the last indices are used in the present examples (e.g., the “terminal index”), it will be recognized by one skilled in the art that any data compartment 104 of the vectorset 100 may be utilized to store the seal hash 110 and / or a previous seal hash 110. The sealing schema may define such storage location within the vectorset 100. For example, a seal hash 110 and / or vector seal 112 may be just as easily stored in a first index (z 1) as a last index (im).

[0099] The process may repeat to form a set of chained state dependencies. Where previous states of the vectorset 100 are stored (e.g., the seal set 124 in the datastore 790 of Figure 25), the data may be made “immutable” across all states of the vectorset 100, such that any altered data and / or update, write, or create operations in a previous state (if such altered data was included as a hash input 108) could be provably shown to be subsequently altered due to the unpredictability in the output of the hash function 109. Such unpredictability would, from the point of alteration, set off a chain reaction through the set of hash forwards 140 resulting in an incongruent and / or unexpected seal hash 110 in a latest state of the vectorset 100. In addition, the entire chain need not be tracked or retained: security can be established through reference to one, two, or a few previous states through which the hash chain extends. Similarly, individual vector seals 112 and / or seal pairs 114 may incorporate previous vector hashes 112 or previous seal pairs 114, respectively.

[0100] Although a single vector 102 is utilized to illustrate the hash forward 140, a similar hash forward 140 may be utilized for the vectorset hash 120 in which a previous vectorset hash 120 for a state N is utilized as the input to the hash function 109 outputting the new vectorset hash 120 for a state N+l.

[0101] Figure 5 illustrates an instance of the vectorset 100 with vectors 102 of varying length, according to one or more embodiments. Figure 5 further illustrates calculation of vector hashes 112 and index hashes 116 from varying lengths of vector 102. In one or more embodiments, the index hash 116 may be provided at a fixed index (e.g., i5, as shown) and / or a relative index (e.g., the “first” index, the “last” index, or the “penultimate” index of each vector 102). For example, a seal index 113 could include the data compartment 104(1,5), the data compartment 104(2,2,), the data compartment 104(3,7), and the data compartment 104(4,4), with the data compartment 104(n,m) likely be reserved for a vectorset hash 120.

[0102] It will be recognized by one skilled in the art that a logical representation of the vectorset 100 and / or the matrix 101 may include data compartments 104 that are not actually stored in physical computer readable memory. For example, and referring to Figure 21 for reference, each of the empty data compartments 104 may be unspecified in an array implemented with a key-value store, Alternatively or in addition, a null data type may be utilized as a placeholder, although this is not necessary.

[0103] Figure 6A though Figure 6C demonstrate sealing schemas that result in different instances of the seal hash 1 10, and / or differ from the vector seals 1 12 and the index hashes 1 16 previously described. However, it will be recognized that the sealing schemas of Figure 6A through Figure 6C can be utilized alongside and in addition to the other sealing schemas shown and described herein, and the others contemplated hereby that will be recognized by one skilled in the art of data science and software engineering given the present teachings.

[0104] Figure 6A illustrates a sealing schema in which each of one or more data compartments 104 may be associated with a seal grouping 115 comprised of two or more seal pairs 114, according to one or more embodiments. A seal pair 114 may include at least two values extracted from attribute-value pairs 105 that have a known and / or fixed relationship. The sealing schema may define the relationship, either within the vectorset 100, without the vectorset 100, inherent within use of the vectorset 100, and / or in another device or system associated with the vectorset 100. For example, and as shown in Figure 6A, the data compartment 104(1,1) may be associated with three seal pairs 114, drawn from a hash of the values extracted from (i) data compartment 104(1,1) and data compartment 104(1,2); (ii) data compartment 104(1,1) and data compartment 104(2,1); and (iii) data compartment 104(1,1) and data compartment 104(2,2). As shown, each data compartment 104 may be associated with at least two seal pairs 114, generally from two or three “neighboring” or “adjacent” data compartments 104. As shown and described in conjunction with the embodiment of Figure 7B, a write operation and / or a delete operation effected on data compartment 104(1,1) advancing a state (N to N+l) will cause each the seal pair 114 to be “tripped” when re-calculated compared with the corresponding seal pairs of the original state N.

[0105] Figure 6A further illustrates a plurality of seal hashes 122 that are the collection of each output value from each of the seal pairs 114. The plurality of seal hashes 122, when again placed into a hash function 109, result in the hash value output that is the vectorset hash 120. The vectorset hash 120 that may act as a static state verification hash 121 usable to prove a state was maintained and to assist in providing data uniqueness. As shown and described in conjunction with the embodiment of Figure 2 and throughout the present embodiments, a secret value 118 may be additionally input into the hash function 109 before generating the vectorset hash 120. The seal set 124 may be a plurality of the seal hashes 110 sealing the data of the vectorset 100. Together, the plurality of seal hashes 122 and any vectorset hash 120 may be referred to as the seal set 124.

[0106] Figure 6B illustrates an abbreviated notation for the sealing schema of Figure 6A, according to one or more embodiments. Figure 6B illustrates the seal pairs 114, including reference to each data compartment 104 acting as a hash input 108. For example, the seal grouping 115 for the data compartment 104(1,1) includes the seal pair 114[(vl,il) / (v2,il)], designating data compartments 104(1,1) and data compartment 104(2,1) as hash inputs 108. Figure 6C illustrates a shorthand notation for the sealing schema of Figure 6A and Figure 6B, according to one or more embodiments. In one or more embodiments, the sealing schema in which data compartments 104 are cryptographically tied may be referred to as “stitching”.

[0107] Other robust sealing schemas are possible. For example, one seal hash 110 may be generated for each data compartment 104, where the hash inputs 108 to the hash function 109 outputting the seal hash 110 comprise each data compartment 104 within a row and a column of that data compartment 105. By way of example, and referring to Figure 21, a seal hash 110 allocated to the data compartment 105(5,5) (e.g., primarily storing the receiving device ID 244 as shown in Figure 21) would include values extracted from the Heredity Vector 240 (e.g., the sending user ID 241, the sending device ID 242, the receiving user Id 243, the receiving device ID 244), and all values extracted from index 5 (e.g., the proof root 224, the location description 264, the encryption key 274, and / or the run sequence value 284). Such a seal hash 1 10 could beadded as a second attribute-value pair 105 of the data compartment 104 to which it was associated, and / or may be stored in a separate set of vectors (e.g., another instance of the vectorset 100, referred to as the vectorset 100B) associated with the vectorset 100 (e.g., the vectorset 100A). In one or more other embodiments, a select “distance” from the data compartment 104 may be used (measured in indices and / or vectors).

[0108] In one or more embodiments, the sealing schema may be confidential, dynamic, and / or subject to encryption. For example, the sealing schema may change with each state of the evolved vectorset 100. In one or more embodiments, a first data processing system and a second data processing system (e.g., a client device 600 and a server 700) may initial exchange data which can be later used to deterministically derive the sealing schema based on a state and / or state number of the vectorset 100. If several state updates to the vectorset 100 occur at the first data processing system and the first data processing system transmits a seal set 124 to a second data processing, then the second data processing system may be able to derive the sealing schema and re-calculate the seal set 124 for comparison to the received seal set 124. In one or more embodiments, the seal set 124 when transmitted may be a string of values but may not self-describe the sealing schema, which may need to be derived or otherwise determined by the recipient.

[0109] Figure 7A illustrates a sealing schema in which a vector seal 112(v2) and an index hash 116(i2), for example as illustrated in Figure 2, may be identified as seal trips 142 and cross-referenced to determine a modification location 144, according to one or more embodiments. The modification location 144 may have been subject to a data operation 134, and can be tested for modification authority, according to one or more embodiments. In one or more embodiments, and as further shown and described herein, CRUD operation and / or a modification (e.g., a write, update, delete) in a given location (e.g., data compartment 104) can be defined or predicted when the vectorset 100 is processed by a device or system, and therefore the expected (or allowed) seal trips 142 determined or predicted. For example, certain systems or devices may be constrained or permissioned such that they are only permitted to trip certain seal hashes 110, according to one or more embodiments.

[0110] Figure 7B illustrates a scaling schema, similar to Figure 6C, in which the seal pairs 114 of the seal grouping 115 are identified as seal trips 142 to determine the modification location 144, according to one or more embodiments. Specifically, the modification location 144 at data compartment 104(2,2) is determined through tripping of the seal pair 114[(2,2)(2,3 )] and the seal pair 114[(2,2)(3,2)].

[0111] In one or more embodiments, seal pairs 114 may be additionally paired as hash inputs 108 to a hash function 109 to output another seal hash 110 that may be a meta seal. In turn, those seal hashes 110 may additional be paired and hashed (e.g., resulting in a meta-meta-seal). As a result, a tree (e.g., similar to a Merkle tree with leaf nodes) may be formed with a final hash at the top, which may be equivalent to the vectorset hash 120 resulting. An efficient tree parsing algorithm may be able to rapidly follow the “leaf nodes” or “legs” of the tree determine a location of the tripped seals and ultimately the modification location 144, as such tree parsing algorithms are known in the art of computer science. When forming the tree, any odd number of leaves may be repeated and hashed together, as known in the art. In one or more embodiments, use of the tree may represent an increase in efficiency of determining an exact modification location 144.

[0112] In one or more embodiments, the vectors 102 may organize and store specialized data. For example, in one or more embodiments, an identity vector 200 (referred to as an iD vector) may store data which uniquely identifies, or as a group uniquely distinguishes, the vectorset 100. This data may include a unique identifier, shown and described as the vectorset identifier 201 by which the vectorset 2100 may be uniquely addressed within a datastore and / or a database. Referring to the above discussion, the sealing schema may be optimized for determining changes within one category of data, e.g., each vector 102. Other configurations arc also possible, for example grouping three vectors 102 that arc known to be generally modifiable for a single static state vector hash incorporating data of all three vectors 102, while granularly monitoring and protecting data in important or consequential data vectors 102 and / or data compartments 104.

[0113] Figure 8 illustrates an instantiation of the vectorset of Figure 1 in which vectors 102 of the vectorset 100 are designated for organization and storage of particular data, including assignment of a vectorset unique identifier 201 (also referred to as the vectorset ID 201) within an identity vector 200 (also referred to as the iD vector 200) and storage of content (e.g., the content data 278) within a content vector 270 (also referred to as the nT vector 270), according to one or more embodiments. For ease of presentation, Figure 8 adopts the numbering scheme of Figure 21, although omitted interstitial numbers need not be included elements in Figure 8, as will be apparent to one skilled in the art of software engineering and / or data science. The selection of vectors 102, their order and optionally their number of data compartments 104, may be referred to as the “vectorset schema”. The attributes within the vector may be referred to as the “vector schema.”

[0114] In one or more embodiments, the vectorset 100 (such as the instantiated instance of the vectorset 150) may include an identity vector 200 usable to store data sufficient to uniquely address the vectorset 100 (e.g., which may be or include the identity data 208). The identity vector 200 also may be referred to as an iD vector 200. The iD vector 200 may include a vectorset ID 201, for example a UUID, a GUID, and / or a 32 character alphanumeric string allow for the vectorset 100 to be uniquely addressed. The iD vector may be scaled (e.g., by the vector seal 112vl(N), assuming the embodiment of Figure 8 is shown in state N), and may also incorporate a previous vector hash 112 (e.g., the vector hash 112vl(N-l) from a previous state, as further shown and described in conjunction with the embodiment of Figure 4. The vectorset ID 201 may also include a sequence number in state appended or incorporated into the identifier, and / or this data can be stored in a separate data compartment 104 if explicitly tracked.

[0115] In one or more embodiments, the vectorset 100 (such as the instantiated instance of the vectorset 150) may include an owner vector 210 usable to store ownership information (e.g., within the ownership data 218) associated with the vectorset 100. The owner vector 210 may also be referred to as an oW vector 210. The oW vector 210 may include an owner identifier 211 (e.g., the ownership ID 211), which may also be or include a UUID, a GUID, and / or a 32 character alphanumeric string allowing for an owner data object (or another instance of the vectorset 100 associated with the owner object, for example the vectorset 2200, as described below) to uniquely address the owner data object.

[0116] In one or more embodiments, the vectorset 100 (such as the instantiated instance of the vectorset 150) may include an origin vector 220 usable to store data associated with an origin of the vectorset 100 (e.g.,within the origin data 228). The origin vector 220 may also be referred to as the oG vector 220. The oG vector 220 may include an origin data 228 stored in one or more data compartments of the oG vector 220. The origin data 228 may list systems, devices, processes, and associated resources, users, timestamps, and / or other data or metadata related to origination and / or initiation of the vectorset. For example, the first time the vectorset 100 is created or defined origin data may result, as further shown and described in conjunction with the embodiment of Figure 9. In one or more embodiments, the oG vector 220 may include an origin location ID 228 (e.g., a device ID, a system ID) and / or an origin timestamp 222 (e.g., a time in UTM, a relative time).

[0117] In one or more embodiments, the vectorset 100 (such as the instantiated instance of the vectorset 150) may include a content vector 270 usable to store data associated with one or more applications 602 (e.g., software applications, software appliances, computing software running on hardware systems, etc.) utilizing the vectorset 100 as a data resource. The content vector 270 may be referred to as an nT vector 270. The content vector 270 may include an application data of at least one of one or more applications (e.g., the application 602). As just one example, the resource might be a file of any MIME type, a multimedia file, a video file, an audio file, a dataset, an Al model, a binary large object (BLOB), a password, an encryption key, a private key associated with cryptocurrency, etc. The data resource could be used to populate graphical user interfaces (GUIs), provide Al models, reference parameters to run proprietary algorithms, or other data uses.

[0118] In one or more embodiments, the vectorset 100 may include a context vector 280 usable to store data (e.g., within the context data 288) associated with an operational context and / or a functional context for the vectorset 100 (e.g., such as the instantiated instance of the vectorset 150). The context vector 280 may also be referred to as an xT vector 280, according to one or more embodiments. The xT vector 280, for example, may store “behaviors” that may include permitted, nominal, and / or expected uses or interactions with respect to other instances of the vectorsets 100. The xT vector 280 may also form an extensible data storage vector 102 that can be accessed and utilized by one or more of the applications 602 utilizing the vectorset 100. The vectorset 100, such as the vectorset 150, may be used to permit or enable query of individual vectors 102, such as the iD vector 200 (e.g., without giving access or permissions to other vectors 102 within the vectorset 100). The vectorset 100, such as the vectorset 150, may be further used to store data to which ownership is assigned, for example user-generated content on a social media site which can be transferred and / or change ownership, but may begin its “life” with a first owner. Another example may be implementation of a non-fungible token (NFT). Additionally, the vectorset 100 may be used as a common data storage mechanism for multiple applications (e.g., the applications 602), each of which may be allocated data compartments 104 and / or other storage space within the xT vector 280. Numerous other possibilities and advantages will be shown and described in conjunction with the embodiment of Figure 21, and throughout the present embodiments.

[0119] Through this simple example, the vectorset 100 may define a data resource for an application 602, with any data operations 134 causing evolution of the state of the vectorset 100, including tracking any changes thereto. However, many additional organizations of data utilizing the vectorset 100 are possible, including the organization as shown and described in conjunction with the embodiment of Figure 21 and Figure 22.

[0120] Depending on the intended use of the vectorset 100, the vectorset 100 may be originated to have an initial structure for present or future data storage and / or data transactional utilization. The vectorset 150 of Figure 8 illustrates one possible differentiation that may be initially established. While Figure 8 demonstrates use of a vectorset 100 for general data storage, the vectorset 100 may also be utilized and / or instantiated to store or represent value, e.g., acting as a micro commodity, digital currency, and / or medium of exchange. Certain properties and capabilities shown and described herein may be useful and beneficial for this purpose, for example maintenance of the data of a state (e.g., usable to store ownership and / or control of a vectorset 100 within the vectorset 100), maintaining uniqueness, and / or ensuring security in transfer and storage.

[0121] Figure 9 illustrates an example vectorset origination process flow 900, including a cryptographic tie between a physical proof 160, generation transaction data 164 (including one or more subparts, such as the generation transaction data 164 A and the generation transaction data 164B), and the vectorset 100, according to one or more embodiments.

[0122] In one or more embodiments and the embodiment of Figure 9, the vectorset 100 may be originated and tied to a physical proof 160. The physical proof 160 may embody a proof value 162 (or simply, “proof 162” as used herein). The proof value 162 may be a value that may be uniquely stored within a series, sequence, and / or set. The physical proof 160 may be a physical instance of the proof value 162 that may be, for example, stored in indelible media or otherwise recorded in a physical, human readable and / or machine readable medium. In one or more embodiments, a group of vectorsets 100 (e.g., thousands of vectorsets 100 for storage and control of digital assets, one million vectorsets 100 issued in a sequence and transferrable as a microcommodity and / or medium of exchange, etc.) may be each linked to at least one physical proof 160 through its proof value 162. In one or more embodiments, each physical proof 160 is tied to one and only one vectorset 100, and each vectorset is tied to one and only one physical proof 160 (e.g., a 1 : 1 relationship). The tie may be a cryptographic tie established through a dependency of one or more values on the proof value 162. Henceforth in this specification, the proof value 162 will be simply referred to as the proof 162. The proof 162 may further promote establishment of a unique tic to a physical origin — a tic which can be audited or assessed in real time to validate a 1: 1 tie with a physical original.

[0123] In one or more embodiments, the proof 162 may comprise a value that includes an alphanumeric string output from a cryptographic algorithm, for example a hashing algorithm and / or GUID generation algorithm. The input to the cryptographic algorithm may include an entropy source 161. Although a pseudorandom number generator can be utilized to provide an input to the cryptographic algorithm, in one or more embodiments, a true random number generator based on physical entropy gathering may be utilized (e.g., thermally gathered entropy, electromagnetic gathered entropy, quantum entropy, motion generated entropy (e.g., random movements of the client device 600 or its physical input devices), radio isotopic generated entropy, and / or other physical entropy sources) may be utilized. Each proof 162 may be checked for uniqueness (e.g., a “collision check”) against each other proof 162 within a set (which may be recommended prior to storage and / or indelible storage as physical proof 160). Each set of proofs 162 may be further given a sequence number or other assigned identifier, such that collision checks do not need to occur across sequences, according to one or more embodiments.

[0124] Each proof 162 may be cryptographically tied to the vetorset 100 in a variety of ways and / or by a varity of methods. However, in one or more embodiments, the proof 162 may be hashed (e.g., utilized as a hash input 108 to a hash function 109), with the output stored in one or more of the data compartments 104 of the vectorset 100. Specifically, in one or more embodiments, the output may be utilized as the unique identifier of vectorset 100 and stored as the vectorset identifier 201. The vectorset identifier 201 may be further stored within the identity vector 200. Additional data may be input into the hash function 109 to generate the vectorset identifier 201, for example some or all of the generation transaction data 164. Any data used as an input to generate the vectorset identifier 201 may be retained for future validation that the physical proof 160 is tied to the vectorset 100. Such validation may occur when, upon receiving the vectorset 100 for validation, the proof 162 and any other inputs are re-entered into the hash function 109 as hash inputs 108 and the output compared against the vectorset identifier 201 of the received vectorset 100; a match may validate that the vectorset 100, or at least the vectorset identifier 201, is cryptographically tied to the proof 162 and / or any physical proof 160. Any necessary inputs for this calculation may be stored alongside the physical proof 160, for example a origin timestamp 222 in which the proof value 162 was generated and / or the physical proof 160 was “minted”. In one or more embodiments, each vectorset identifier 201 also may be collision checked against each other vectorset identifier 201 within a series as to guarantee unique addressability within a datastore. Such addressability may occur across states, with a latest state being the version uniquely addressed, for example as enabled by one or more of the systems and methods for state maintenance shown and described herein.

[0125] Additional and / or redundant checks also may be established. In one or more embodiments, the proof 162 and other data, including for example the vectorset identifier 201, may be hashed to result in a proof root 224. Upon requested validation of the vectorset 100, the proof root 224 may be similarly checked to ensure it can be properly recalculated. The proof root 224 may be stored in each of one or more of the vectors 102 as one of several possible methods to tie each vector 102 to the vectorset identifier 201 and / or to the proof 162.

[0126] In the embodiment of Figure 9, the generation transaction data 164 is illustrated in two parts; the generation transaction data 164A and the generation transaction data 164B. The generation transaction data 164A illustrates data incorporated into the hash function 109 to output the vectorset identifier 201, whereas the generation transaction data 164B illustrates data not incorporated into the hash function 109. An arbitrary allocation of the generation transaction data 164 may be made between the generation transaction data 164A and the generation transaction data 164B. In one or more embodiments, all relevant generation transaction data 164 may be incorporated therein, and in one or more embodiments none of the generation transaction data 164 may be incorporated therein.

[0127] The generation transaction data 164 may include, for example, origin data 228. The origin data 228 may include an origin location identifier 221 (abbreviated origin loc. identifier 221), an origin timestamp 222, an originating user identifier 223 (abbreviated originating user ident. 223), and / or a proof root 224, as previously described. The origin timestamp 222 may include a timestamp associated with generation of the series of proofs 162 and / or an generation of an individual proof 162 within the series. An originating useridentifier 223 which may include a value specifying a user (e.g., a machine user or person use, and / or their associated profile) that originated and / or was responsible for originating the proofs 162 and / or the vectorset 100.

[0128] In one or more embodiments, the generation transaction data 164 may store additional data related to the series of physical proofs 160 generated and / or the other vectorsets 100 within the series. For example, there may be a run sequence value 284 that may specify a sequential number of the vectorset 100 and / or its associated proof 162 within the sequence. Similarly, the run max value 283 may specify a maximum number of vectorsets 100 and / or associated proofs 162 within the series. For example, where the vectorset 100 is just one instance of one billion instances that were created, the run sequence value 284 may an arbitrary number between or including one and one billion depending on when created in the sequence of the series. In this example, the run max value 283 would be a value equal to one billion.

[0129] In one or more embodiments, the generation transaction data 164 may include data related to the type or intended use of the vectorset 100. In one or more embodiments, especially where the vectorset 100 may represent value, a microcommodity, a digital currency, and / or act as a medium of exchange, the generation transaction data 164 may include a face value 233 assigned to the vectorset 100 as a denomination (e.g., a base 10 face value of 1, 10, 100, 100, 1000, etc.).

[0130] In one or more other embodiments, a vectorset type may be assigned, which may further influence and / or dictate definition and / or differentiation of the vectorset 100. The vectorset type may define how may vectors 102 are included in the vectorset 100, how many indices are included within each vector 102, which designations are provided to each vector 102, the sealing schema, and / or which attribute-values pairs 105 to designate.

[0131] In one or more embodiments, the vectorset type may be specified within a vectorset type vector 230. In one or more embodiments, the vectorset type vector 230 may include an application identifier 231 that may store an identifier specifying an application that may have created, requested creation of, and / or may be primarily intended to utilize the vectorset 100 (although, in one or more embodiments, multiple applications 602 may utilize a vectorset 100. The vectorset type 232 may store an explicit type designation of the vectorset 100). The vectorset type 232 may be queried and evaluated, for example, to determine who or what is permitted to query, effect data operations on, determine the format of, determine the sealing schema of, and / or or otherwise process or store the vectorset 100 by one or more devices or systems. Although one example of origination of the vectorset 100 has been illustrated in Figure 9, many other processes (including incremental definition and / or differentiation) may be effected.

[0132] As shown and described in Figure 1 through Figure 9, and throughout the present embodiments: (1) data within the vectorset 100 may be immutable in a way which can be tested, with unauthorized, corrupted, or incorrect data rejected; (2) data immutability may mean that state can be known and therefore enforced, including in granular portions of the vectorset 100; (3) the location to which the vectorset 100 is sent and received can be assessed and proven by numerous methods, including (a) checking threshold checks on record ownership (as further described below), (b) assessment of the location listed within the vectorset 100 and determination that a seal hash 110 can be properly re-calculated from the data listing that location;(c) verifying the seal hash matches previously provided seal hashes; (4) once state and location can be determined with certainty, is possible to prove uniqueness of the vectorset 100 and its data, for example which may be defined as the most recent state of the vectorset 100; and (5) systems, devices, and methods may be implemented to accept only the most recent state, rejecting all others. In summary, the vectorset 100 may therefore define a flexible, hyper-dimensional storage container which can securely store data and ensure its uniqueness across a network of connected devices, such as client device 600 and servers 700 communicating over a network 502.

[0133] It should be noted that although Figure 1 illustrates a n by m matrix 101, an arbitrary dimension of vectors 102 is possible. For example, an n by m by o matrix 101 may define three-dimensional matrix, where each data compartment 104 forms a “data box”, and a fourth dimension are previous and future states (e.g., N-l, N, N+l, etc.). One skilled in the art of computer science will recognized how to generalize the teachings herein into additional dimensions, for example adapting a sealing schema such that individual modification locations 144 within the three dimensional matrix can be determined.

[0134] Figure 10 illustrates a vectorset initiation process flow 1000, according to one or more embodiments. Operation 1000 may generate a proof 162 (e.g., a proof value 162). In one or more embodiments, the proof 162 may be generated as an alphanumeric string utilizing input from a random number generator (e.g., a 64-character alphanumeric string). Operation 1002 may determine if a “collision” would exist with any other proof 162 within an arbitrary designation of proofs 162, such as a group and / or “series.” For example, existing proofs 162 may be indexed by alphanumeric value and the index rapidly queried for exact-value matching. If a collision (e.g., exact value match) is determined, operation 1002 may proceed to operation 1004 which may discard the proof 162 and then return to operation 1000. Proofs 162 may be ensured unique between and / or among series by appending a series number that may be sequential and / or also randomly generated onto each of the proofs 162 within the series. If operation 1002 determines that no collision exists, operation 1002 may proceed to operation 1003 which may securely store the proof 162. In one or more embodiments, the proof 162 may be transmitted to and / or stored on a high-security storage device or system. For example, the proof 162 may be generated and stored on an air gapped computing system or hardware security module (HSM) and / or secure hardware enclave. The proof 162 may be physically and / or indelibly stored as a physical proof 160, including for example in non-electric and / or non-magnetic computer readable media. Once verified and stored, each proof 162 may also be assigned a sequential number (e.g., the run sequence value 284), according to one or more embodiments. The sequential number may be usable as an alternative unique identifier within the series.

[0135] Operation 1004 may input the proof 162 and the generation transaction data 164 into a hash function 109. The hash function 109 may, for example, may be SHA-1, SHA-256, SHA-512, CRC-64, and / or other hashing algorithms. In one or more other embodiments, the hash function 109 may be SHA256 and / or xxHash64. Certain aspects of the generation transaction data 164 may be selected, such as users or user IDs associated with generation of the proof 162, timestamps, metadata related to the proofs 162 and / or physical proofs 160 created, etc. Operation 1006 may output a vectorset identifier 201 as the output of the hash function 109. Alternatively, or in addition, a vector identifier may be produced for each vector 102 within the vectorset100, for example by hashing a vector designator (e.g., one of iD, nT, xT, uP, etc.) along with the proof 162 to result in a vector identifier (not to be confused with the vectorset identifier 201 ) which may be stored in each vector 102 and allow the vector 102 to be individually addressed within a datastore. Binding to the proof 162 may support, for example, partial unbinding or controlled copying of certain vectors 102 to be send to an external system for processing before being returned and the modified vectors 102 being integrated into the vectorset 100, possibly initiating a state update. For example, in one or more embodiments, a database transaction may be defined in which select vectors 102 are sent from a first device or system storing the vectorset 100 for processing at a second device or system, returned to the first device or system after being processed or modified, verified for authority and / or other security indicia, integrated into the vectorset 100, and then the vectorset 100 evolved. In such case, the entire vectorset need not be exposed to the second device or system.

[0136] Operation 1008 may perform a collusion check on the vectorset identifier 201, similar to operation 1002. Similarly, an index of vectorset identifiers 201 may be built and queried against. The collision check may be made against the proof series, and / or against all vectorset identifiers 201 known to the system of any series. If operation 1008 returns a collision, operation 1009 may discard the vectorset identifier 201 and either (i) return to operation 1004 and discard the proof (although this may require voiding of the any securely stored physical proof 160) and / or (ii) add a nonce to the inputs of the hash function 109 and return to operation 1009. Any added nonce may be securely stored in association with the proof 162 and / or physical proof 160 such that the cryptographic tie can later be tested and / or proven through recalculation and comparison.

[0137] Where no collision is detected, operation 1008 may proceed to operation 1010 which may initiate a vectorset 100 in computing memory. For example, the vectorset 100 may be initialized and stored in a computer readable memory (e.g., RAM) as a collection of one or more arrays with <null> values in each attribute -value pair 105. Operation 1012 may then store the vectorset ID 201 in a vector 102 of the vectorset 100 such that the vectorset 100 is provided a unique addressable identity. Additionally, operation 1010 may designate one or more vectors 102 that the system may specify across all vectorset types. For example, a specialized iD vector 200 may be utilized to store the vectorset ID 201, according to one or more embodiments. Any nonce utilized in generation of the vectorset ID 201 may also be utilized.

[0138] Operation 1012 may select generation transaction data 164 for inclusion in the vectorset 100, for example as may be allocated between one or more vectors 102 based on the purpose, use, and / or control of the information associated with such data. For example, the generation transaction data 164 may include an origin location identifier 221 (a location and / or device on which the proof 162, the physical proof 160, and / or the vectorset identifier 201 was generated), an origin timestamp 222 (e.g., a time at which the proof 162, physical proof 160, and / or vectorset identifier 201 was generated), an originating user identifier 223 (e.g., user identifier of a user associated with generation of the proof 162, physical proof 160, and / or vectorset identifier 201), and / or a proof root 224 (e.g., a hash of the proof 162 and additional data stored in the vectorset 100, for example the vectorset identifier 201).

[0139] Operation 1012 may additionally store data related to a version of software, an application (e.g., the application 602) and / or hardware that created the vectorset 100 (e.g., the version data 203), and / or anylegal rights or intellectual property rights associated therewith (e.g., copyright notices, trademark notices, patent notices, confidential information designations, federal data rights disclosures, moral rights, jurisdictional rights boundaries, etc.).

[0140] Additional data from the generation transaction data 164 may include a run max value 213, and / or a run sequence value 284. Still additional generation transaction data 164 may include an application identifier 231, a vectorset type 232, and a face value 233 (e.g., in mathematical base two, base ten, or base twelve). Any portion of the generation transaction data 164 used as an input into the hash function 109, including without limitation the order and format in which the generation transaction data 164 was used as an input, may be stored for later evaluation of the binding and / or connectivity of the proof 162 and the vectorset 100, e.g., through recalculation of the vectorset identifier 201 and / or the proof root 224, as shown and described throughout the present embodiments.

[0141] Operation 1016 determines if a vectorset schema or a vector schema is specified. If specified, data such as the generation transaction data 164 may be allocated according to the vectorset schema and / or vector schema. It should be noted that the vectorset schema and / or vector schema may also be dependent upon and / or specified by vectorset type, as further shown and described in conjunction with the embodiment of Figure 11. Any generation transaction data 164 to be stored may be initially stored, then optionally re-allocated based on the assigned vectorset type specified for the vectorset 100 (e.g., the vectorset type 232), according to one or more embodiments.

[0142] Where a vectorset schema and / or vector schema is specified, operation 1016 may proceed to operation 1018 through operation 1022 to store specific data in various vectors 102 according to any vector schema. For example, operation 1018 may store select portions of the generation transaction data 164 in a vector 102, for example, data related to origination (e.g., the origin data 228) in an origin vector 220. Similarly, operation 1020 may store select portions of the generation transaction data 164 in a different vector 102, for example, content (e.g., the content data 278) in a context vector 280. Operation 1020 may store select portions of the generation transaction data 164 in still another vector 102, for example, data related to vectorset type in a vectorset type vector 230 (e.g., an application identifier 231, a face value 233, etc.). Operation 1022 may then proceed to operation 1024.

[0143] Operation 1024 may store and initiate the vectorset 100 for use, for example by the application 602 identified by the application identifier 231, a different application 602, and / or a general computing storage system or database for vectorsets 100. Operation 1024 may then end, for example with the vectorset 100 initialized, stored, and / or ready for future or immediate use. Alternatively, or in addition, the operation 1024 may proceed along path ‘Circle A’ to the process flow of Figure 11, according to one or more embodiments.

[0144] Figure 11 illustrates a vectorset initiation process flow 1100, according to one or more embodiments, and may continue from the vectorset initiation process flow 1000. Operation 1100 may query (from a datastore of vectorsets 100) or otherwise receive a vectorset 100 for use, for example a “shelved” vectorset 100 and / or a newly created vectorset 100. Operation 1102 determines whether to assign a vectorset type to the vectorset 100. Type may have already been established during origination, in which case operation 1102 may proceed to operation 1104. Alternatively, the vectorset 100 may not have a type assigned. If a typehas not been assigned following the vectorset 100’s selection for further use or differentiation, but should be assigned, operation 1 102 may proceed to operation 1 103 which may update a vector with a vectorset type 232. The vectorset type 232 designation may also automatically determine and / or set a vectorset schema, vector schema, and / or a sealing schema. In one or more embodiments, the vectorset type vector 230 may be updated. However, the type may be stored in other locations, for example, within the identity vector 200 if the vectorset 100 does not include an explicit vectorset type vector 230. In one or more other embodiments, it will be recognized that an entire system utilizing the vectorset may utilize the same type, and therefore type may not need to be specified. For example, the vectorset schema of the vectorset 2200 of Figure 22 may implicitly describe its type as representing and / or bound to a user profile 2210 due to its organization, the attributes of the attribute -value pairs 105, and / or other data stored within. Similarly, a vectorset schema, a vector schema, sealing schema, and / or other data stored within the vectorset 100 may imply the vectorset type without explicit designation or reference.

[0145] Operation 1104 determines if a specific application 602 and / or application type should be designated (e.g., a music app, a social media app, a digital currency storage and transaction app, etc.), in which case operation 1104 may proceed to operation 1105 which may update a vector with information specifying the application. For example, the application 602 may be a software application that might be a content delivery and control application for musicians and artists, a value storage and transfer application, a user identity management application, a software game. The application 602 may be downloadable on an application platform (e.g., the Apple App Store®, the an Adroid® app on GooglePlay, an application in the Microsoft store, etc.). The application 602 may be usable on a mobile device (e.g., an iPhone based on the iOS, an Android phone based on the Android OS), and / or a desktop computer (e.g., a Mac running OSX, a PC running Windows®, etc.). In one or more embodiments, a unique identifier may be assigned to the application 602 and stored in the application identifier 231, according to one or more embodiments.

[0146] In one or more embodiments, operation 1106 may initiate a heredity of the vectorset 100. In one or more embodiments, the heredity may store information about previous ownership and transfer, including validation thereof. In one or more embodiments, the heredity information may include transaction data 248 related to a transaction giving rise to the current ownership (e.g., as may be expressed in the owner vector 210). When initiated, the heredity may have no initial ownership information or transactional history, except possibly that of origination.

[0147] Operation 1108 may assign an initial owner in a vector 1108. For example, the owner may be a user associated with a user profile accessible to the application 602 as a data resource. The owner may be designated within a vector 102, for example the owner vector 210, according to one or more embodiments. For example, the owner may be specified within the owner identifier 211. Alternatively, or in addition, the owner may be specified through name (e.g., stored in the owner name 212), or specified through another method of designation. In one or more embodiments, the owner need not be represented by a user profile, and instead can be referenced into the physical world without need for additional information (e.g., a legal name only, a social security number or other government issued identifier, etc.). Sensitive data (e.g., bearing private or secret information) can be subject to the use policy 400, for example specifying the data compartments104 storing such information (e.g., the social security number). In one or more embodiments, only verified apps with current certificates and confirmed control processes may receive, decrypt, and / or operate on vectorsets 100.

[0148] Operation 1110 may determine whether initial contents may be stored in and / or referenced by the vector 102. For example, initiation of the process flow of Figure 10 and / or Figure 11 may have occurred at the request of a user of an application 602, for example a user who is uploading an item of multimedia for storage and possible controlled sharing and / or monetization. Therefore, the item of multimedia, c.g., a multimedia data, may be stored in memory until the vectorset 100 is sufficiently parameterized to store and / or reference storage location of the multimedia data. In another example, where the vectorset 100 is associated with a user profile (e.g., the user profile 2210) to provide heredity and other properties and transaction history to the user profile, as further described below, the content may include authentication data 277, as further shown and described in conjunction with the embodiment of Figure 21. Where the vectorset 100 is created for use as a micro commodity, digital currency, and / or medium of exchange, the content data 278 may include the face value 233, which may be added at the time the physical proof 160 is physically stored (although, as described elsewhere herein, the face value 233 may alternatively or in addition be stored in a different vector, such as the vectorset type vector 230). In such case that the vectorset 100 is created for use to “tokenize” a specific asset (e.g., as a non-fungible token of a digital asset, as a storage container for crypto currency keys, as a representation of a specific physical object such as real estate, a gold bar, a vehicle, etc.), the content may include a reference or other identifying information of the specific asset. In yet another example, where the vectorset 100 is created for use of storing, in custody, and / or securing cryptocurrency from a distributed ledged-based blockchain (e.g., Bitcoin®, Ethereum, etc.), the content may include a private encryption key (a “private key”) controlling and / or unlocking the value on a public key (the “public address”), both of which may have been as an asymmetric encryption pair. In still yet another example, where the vectorset 100 represents an Al model (e.g., based on an artificial neural network), the contents may store the model, or a reference to the Al model, and / or Al model or machine learning training data. The Al model, for example, may be a recognition model, a generative model, a large language model (LLM), etc.

[0149] Operation 1111 stores the contents and / or content reference in a vector 102 of the vectorset 100, for example in the content vector 270. At this time, any data within the content vector 270 (or any other vector 102) may be encrypted such that even a query to the vectorset 100 and / or an authorized use per the use policy 400 may additionally require decryption of the data therein. Operation 1111 may then proceed to operation 1112. Where no initial contents are to be specified, operation 1110 may also proceed to operation 1112.

[0150] Operation 1112 may determine whether an initial use policy 400 should be specified, in in which case operation 1112 should proceed to operation 1113. Some possible examples of the use policy 400 are further shown and described in conjunction with the embodiments of Figure 18, Figure 19, Figure 21, and throughout the present embodiments. Operation 1113 may then define and store the use policy 400, for example within a use policy vector 290, including the terms data 402, the conditions data 410, any adaptations (e.g., as may be defined in the adaptation data 420), and / or a use policy reference 293. Depending on the intended use of the vector 102 and / or the application 602, the vectorset type, and / or the owner of the vectorset100, there may be an initial default use policy 400 specified. Operation 1113 may then proceed to operation 1 1 14. if no initial use policy 400 is to be set, operation 1 1 12 may also proceed to operation 1 1 14.

[0151] Operation 1114 may generate and store initial state data, e.g., the state data 268. The state data may specify a current location state of the vectorset 100 which may specifying its logical or physical storage location on a system, device, and / or within computing memory. As described herein, the location state may be especially useful or advantageous for controlling and validating movement of a unique instance of the vectorset 100 which may be enforced through one or more of the present embodiments, including assessment of a vectorset hash 120 and / or a static state verification hash 121. The state data 268 may be stored within a vector such as the state vector 260, according to one or more embodiments.

[0152] Operation 1118 may generate seal hashes 110, including for example vector seals (e.g., the vector hash 112), index seals (e.g., the index hash 116, which may also be referred to as an index seal herein), one or more metaseals, and / or the vectorset hash 120. The seal hashes 110 may be generated as the output of a hash function 109, with inputs comprising those specified according to the sealing schema. The sealing schema may be a hard-coded standard, may be automatically determined based on the size of the vectorset 100 (e.g., in number of vectors 102, number of data compartments 104, etc.) and / or “shape” of the vectorset 100, and / or based upon one or more referenced patterns. The sealing schema may also be dynamically updated, for example upon state update, with the new sealing schema shared with or more other devices or systems. For example, the sealing schema may be encrypted and transmitted from the client device 600 to a server 700, including using an out-of-band communication channel. The vectorset 100 then may be stored for use, for example for the application 602.

[0153] Although not shown in the present embodiment, additional aspects shown and described in conjunction with Figure 21 may be specified, for example permission data of the permission vector 250.

[0154] Figure 12 illustrates a vectorset and / or vectorset hash process flow 1250, according to one or more embodiments. Operation 1200 may initiate a data transaction performing a data operation 134 on the vectorset 100. The data operation 134 may include a CRUD operation within the computing memory designated for storage of the vectorset 100, for example a create operation, a read operation, an update operation, and / or a delete operation. The data transaction may include an interaction with the vectorset 100 (e.g., a query of the vectorset 100 and / or index thereof to populate a list within the application 602), the content of the vectorset 100 (e.g., using data or a file stored as content by the vectorset 100), changing owner of the vectorset (e.g., which may require the data operation of updating the owner identifier 211, moving the vectorset 100 (e.g., which may require updating the state data 268), etc. Operation 1202 may then execute the data operation on one or more attribute-value pairs 105 of the vectorset 100. For example, changing an owner of the vectorset 100 may end up causing performance of update operations and / or write operations to the owner identifier 211, the owner name 212, the state data 268, and / or the use policy 400.

[0155] Operation 1204 may determine a sealing schema of the vectorset 100. For example, as described in conjunction with the embodiment of Figure 11, the sealing schema may be automatically determined based on the “size” and / or “shape” of the vectorset 100, may be automatically determined from a hard-coded, preexisting reference (e.g., all vectorsets 100 utilizing a 10x10 instance of the matrix 101), an explicitreference or specified sealing schema stored within the vectorset 100, a dynamic changing sealing schema recalculated based on data known only to between two or more network endpoints (e.g., including based on a shared cryptographic secret), etc.

[0156] Operation 1206 extracts one or more hash inputs 108 from the vector 102 may be extracted as data inputs 108 and / or from the seal grouping 115, depending on the sealing schema. For example, where the sealing schema specifies that each vector 102 is to be sealed, e.g., as illustrated in the embodiment of Figure 2, all of the values from the attribute-value pairs 104 of the vector 102 (other than, optionally, within the last data compartment 104, which may be used to store the output of the hash function 109). In one or more other embodiments, as shown and described in conjunction with Figure 6A, values from the attribute-value pairs 105 of each seal grouping 115 may be extracted, even if one or more seal pairs 114 are from other and / or adjacent instances of the vector 102 other than the vector 102 selected for sealing. The values needed for each seal grouping 115 of each data compartment 104 of the vector 102 selected in operation 1204 may be extracted as hash inputs 108.

[0157] Operation 1208 may determine whether one or more hash inputs 108 may be gathered from additional vectors 102. For example, some sealing schemas may incorporate the values of additional attributevalue pairs 105. This may be referred to as a cross-dependency, for example of a seal hash 110 of a first vector 102vl for data of a second vector 102v2. As a specific example, the vectorset identifier 201 may be included as a hash input 108 such that, for a give seal hash 110, it can be proven that a specific instance of the vectorset 100 was utilized for generation of the seal hash 110. For a dynamic sealing schema, the sealing schema for the present state may first be determined and calculated before the extraction. Operation 1210 may then extract the additional hash inputs 108, and operation 1212 may input the set of hash inputs 108 into the hash function 109. Operation 1214 may output a hash value from the hash function 109, which may be defined to be the seal hash 110.

[0158] It will be recognized that inclusion of hash inputs 108 from additional vectors 102 may also create cross-dependency and / or decrease predictability in the hash inputs 108 (especially where a frequently changing value occurs and / or a value updated with every state evolution, such as in timestamp of a transaction). On the other hand, cross-dependency may expand the possible options for recognition of modification location 144. In one or more embodiments, separate sealing schemas for identification of the modification location 144, versus specialized seals for use in later proving incorporated information (e.g., identity, location state, and heredity), may be defined and / or adopted.

[0159] Operation 1216 may determine whether an additional vector 102 and / or seal grouping 115 are to be sealed. For example, the sealing may continue until each seal hash 110 specified in the sealing schema is calculated and stored. If additional sealing is to occur, operation 1216 may return to operation 1206. For example, and as shown and described in conjunction with the embodiment of Figure 21, the sealing schema may specify to continue down each vector 102 in sequence and / or in parallel through parallel processing (e.g., the vector hash 112vl(N) of the identity vector 200, the vector hash 112v2(N) of the owner vector 210, the vector hash 112v3(N) of the origin vector 220, etc.). Similarly, index hashes 116 of the seal vector 117 may be sequentially calculated.

[0160] It should be noted that due to the storage in vectors 102 and allocation thereof, it may be possible to efficiently use parallel processing to relatively quickly (compared with serialized processing) compute seal hashes 110. Similarly, because the seal hashes 110 may be competed quickly and in parallel for various designated portions of the vectorset 100 (e.g., per vector 102, per specified group of data compartments 104, per seal grouping 115), calculation of a vectorset hash 120 usable to detect a change in any of the data within the vectorset 100 may also be relatively rapid compared with individually extracting every value of the vectorset 100 for hashing.

[0161] If all vectors 102 and / or seal groupings 115 have been accounted for (e.g., within the sealing schema), operation 1216 may proceed to operation 1218 which may determine if a metaseal is to be utilized. Note that, in one or more embodiments, the vectorset hash 120 may be implemented as a metaseal which incorporates (e.g., as hash inputs 108 to a hash function 109 which outputs the vectorset hash 120) one or more other seal hashes 110 as hash inputs 108.

[0162] Where a vectorset hash 120 and / or metaseal is to be utilized, operation 1218 may proceed to operation 1220 which may extract the additional seal hashes 110 (and / or other values). Operation 1222 may then input the seal hashes 110 (and / or other vales) into a hash function 109, and operation 1124 may then output a hash value that may be defined as the metaseal and / or vectorset hash 120.

[0163] Alternatively, or in addition, the vectorset hash 120 need not be a metaseal. For example, the vectorset hash 120 may incorporate a plurality of values (or all values) of all of the data compartments 104 (other than, optionally, those storing seal hashes 110) as hash inputs 108. In such case, operation 1218 through operation 1224 may alternatively extract the additional values other than seal hashes 110, input the values into a hash function 109, and output the vectorset hash 120 which is not necessarily a meta seal.

[0164] Operation 1226 may store the seal hashes 110, including any generated in operation 1214 and / or operation 1224. The seal hashes 110 may be stored in any data compartments 104 within the vectorset 100. For example, as shown in Figure 21, the seal hashes 110 may be stored in the last data compartment 104 to assist in logical organization of data related to sealing. Alternatively, or in addition, in one or more embodiments a seal vectorset 100 (e.g., a vectorset 100B) may be defined and stored within the primary vectorset (e.g., the vectorset 100A). The separate vectorset may store each seal hash 110, optionally in a spatially mappable arrangement allowing for matrix mathematical operations and / or tensor transformations 132 thereon in addition the primary vectorset 100A. For example, for the vectorset of Figure 21, the seal vectorset 100B may comprise a n=10, m=3 matrix 101, where each vector 102 of the seal vectorset corresponds with one vector 102 of the primary vectorset 100A, an index vector 106 (for il) stores the vector hashes 112, a second index vector 106 (for z’2) stores the index hashes 116 of the primary vectorset 100 A, and third index vector 106 (for z‘3) may store any metaseals, for example the vectorset hash 120. Alternatively, or in addition, an array of all seal hashes 110 (e.g., within an array data type of comma delimited values) may be stored in a single data compartment 104. Operation 1226 may then end. In one or more embodiments, the vectorset 100 may be “at rest” at an endpoint in computer memory on a known device upon the conclusion of operation 1226.

[0165] Figure 13 illustrates a system authority enforcement process flow 1350, according to one or more embodiments. Operation 1300 may store the vectorset 100 in a first system and / or device (e.g., a client device 600, a server 700). The system or device may be defined at multiple levels of complexity or abstraction, physically or logically. For example, the system may be a set of computers and / or networking computing equipment at a physical location such as a data center (e.g., the server 700). The system could alternatively be the smartphone of a user, a personal computer of the user or a tablet of the user (e.g., each an example of the client device 600), and / or a portion of a multi-tenant server allocated to the user (e.g., a portion of the server 700 with reserved or allocated computing resources). Alternatively, the system may be a single device, such as the smartphone of the user, or even a portion of a computer, such as a particular hard drive (e.g., a portion of the memory 603). Storage within a particular location, system, and / or device may update the location state of the vectorset 100, according to one or more embodiments. In yet another example, each system may be a different software process, module, agent, and / or engine responsible for various aspects of data operations in different portions of the vectorset 100. In still yet another example, each system may include data processing equipment owned by different legal entities.

[0166] Operation 1302 may extract a plurality of seal hashes 110, e.g., seal vectors 112, seal indexes 116, and / or seal sets 124, each associated with a present state, denoted N (e.g., which may be referred to as the seal hashes 110(N), seal vectors 112(N), seal indexes 116(N), and / or seal sets 124(N)). For example, prior to querying, copying, transmitting, performing data operations, or otherwise processing or utilizing the vectorset 100, the seal hashes 110(N) may be extracted. For illustrative purposes, reference is made to the vectorset 2100 of Figure 21, in which the first system might extract each of the vector hashes 112vl(N) through vector hash 112vlO(N) and the seal hashes 116il(N) through 116i8(N), and optionally the vectorset hash 120.

[0167] Operation 1304 may define a processing authority at a second system or device. The second system may be defined with the same flexibility as the first system or device. In one or more embodiments, the first system may be device(s) and / or computing hardware associated with a user, and the second system may be a third-party data processor which may include one or more servers 700. In one or more other embodiments, the first system may be a first portion of data processing within a data center (e.g., a server 700A responsible for changing ownership within the owner vector 210), and the second system or device may be a second portion of data processing within the data center (e.g., responsible for changing heredity within the heredity vector 240). The authority defined at the second system or device may be limited to certain data operations (e.g., read, writing to a particular data compartment 104, writing within a particular vector 102, etc.). In one or more embodiments, the authority of the second system or device may be stored in an independent system, for example an authority description 746, as may be stored in an authority database. However, in one or more embodiments, the authority of a given system of device may be specified within the vectorset 100 itself, for example within the permission vector 250 and / or within the use policy vector 290. Similarly, any application^ ) specified in the application identifier 231, or associated server 700 acting as backend support on their behalf, may each have inherent or explicitly defined authority with regard to data operations 134. The processing authority may include a description and / or specification of which data compartments 104 arepermitted to be modified (permissible modification locations 144), for example as shown and described in conjunction with the embodiment of Figure 7A and Figure 7B.

[0168] Operation 1306 may retain the plurality of seal hashes 110 at the first system and / or forward the plurality of seal hashes 110 (e.g., the seal set 124) to a third system or device. In a straightforward example, both the first system or the third system or device may be generally more trusted (and / or vested with differing authority) than the second system or device, as may be further shown and described in conjunction with the embodiment of Figure 23. However, in a more nuanccd example, the first system and the second system of device may not necessarily be “more trusted,” but rather may be tasked and / or vested with the authority to reject transactions of the second system which may have exceeded the authority permitted by the second system.

[0169] Operation 1308 may transmit the vectorset 100 to the second system or device. Operation 1310 may then perform a data operation 134 (including a read operation, a write operation, an update operation, and / or a delete operation). The data operation 134 may be performed on one or more specified data compartments 104, one or more specified attribute-value pairs 105, one or more vectors 102, and / or other arbitrarily defined elements or subsections of the vectorset 100. For illustrative purposes, reference is made to the vectorset 2100 of Figure 21, in which the second system or device (e.g., the server 700B) might modify the owner identifier 211 and the owner name 212 (illustrated in data compartment 104(2,2) and data compartment 104(2,3), respectively). At state N, such data compartments 104 may be referred to as the data compartment 104(2, 2)(N) and data compartment 104(2, 3)(N)). Following any data operation 134, the data compartments 104 may be referred to as data compartment 104(2, 2)(N+1) and data compartment 104(2, 3)(N+1). Operation 1310 may then return the vectorset 100 (e.g., at a state N+l) to the first system or device and / or transmit the vectorset to the third.

[0170] Operation 12214 may recalculate the plurality of seal hashes 110 at the state N+l. The recalculation will occur following the data operations of operation 1310, such that the seal hashes calculated at state N+l will incorporate the new values of the data operation 134 (or in the case of a read operation only, use the same values). Operation 12216 may then compare the plurality of seal hashes 110 calculated at state N to the plurality of seal hashes 110 calculated at state N+l. The modification location 144 may then be determined. For example, the seal trips (e.g., the seal trips 142) may be determined, and therefore the modification location 144, as shown and described in conjunction with the embodiment of Figure 7A and Figure 7B.

[0171] Operation 1318 may determine the expected modification location 144 and the actual and / or new modification location 144. For example, the authority specified for the second system may or device include specification of which modification location 144 is permissible within the authority of the second system. Operation 1318 may then determine which modification location 144 actually occurred based on the seal trips 142 when comparing the Nth state of the vectorset 100 to the Nth+1 state of the vectorset 100. Where the second system or device only has read authority (e.g., limited permission to conduct a read operation), there may be no expected modification locations 144. In such case, the vectorset hash 120 could also be utilized (unless, for example, certain vectors 102 may be automatically updated due to enforcement of updates for changes in location). Alternatively, some or all read operations may be required to be logged in at least onedata compartment 104, possibly including a timestamp and / or other metadata related to the read operation. For example, a read operation may not need to he logged when reading a vectorset unique identifier 201 , but may need to be logged for any interaction with the content vector 270.

[0172] Operation 1320 may determine whether the modification location 144 is different than expected based on the authority of the second system or device, in which case operation 1320 may proceed to operation 1322. Operation 1322 may then generate an authority error, and / or roll back one or more data operation of the second system or device. For example, in one or more embodiments, a distributed two-phase commit may occur in which: (i) the vectorset 100 is transmitted to the second system but remains stored on the first system in the Nth state, (ii) the first system or device forwards a plurality of seal hashes 110 (e.g., the seal set 124) to a third system or device; (iii) the second system or device effects one or more data operations 134 contemplated by the transactions, resulting in a tentative and / or proposed Nth+1 state; (iv) the vectorset 100 in the Nth+1 state is moved to the third system or device which confirms the data operations 134 occurred within the authority of the second system or device, and (v) the third system or device informs the first system or device of a valid transfer and the first system or device deletes the Nth state of the vectorset 100. Failure to confirm operation of the second system within the specified authority may cause the pending Nth+1 state to be deleted and the Nth state to remain unchanged on the first system. Where the second system or device did operate within its authority, operation 1320 may proceed to operation 1322, which may confirm the validity of the transaction and optionally update a state of the vectorset 100 (e.g., the Nth+1 state).

[0173] In one or more embodiments, an advantage includes that the first system or device need not know exactly what modifications the second system is going to make to constrain the authority of the second system or device. Similarly, in one or more embodiments, the third system can confirm the proper data operations occurred on the correct data compartments 104 without knowing the original values stored in those data compartments 104 in the Nth state, which can enhance privacy. It should be noted that additional systems, devices, methods, and / or processes may be put in place to ensure not only where modifications occur within the vectorset 100, but also the value of such modifications that are expected. In a straightforward example, a dataset on a client device 600 and / or server 700 can include a database of expected or permissible values for a given data compartment 104. In one or more other embodiments, a hash of a value can be returned to the client device 600 or server 700 for comparison against the hash of one or more of the permissible or expected values. In one or more other embodiments, patterns or boundaries may be established through observation of network traffic and vectorset 100 storage, with expected values baselined and / or parameterized for recognition of outliers. In one or more other embodiments, one system or device may provide the permissible values when requesting processing by a second system or device, and / or provide hashes of permissible values. In this case, the second system or device may be able to test when it has provided an acceptable value without knowing the other potential permissible values.

[0174] In one or more embodiments, and as may be further shown and described in conjunction with the embodiments of Figure 6A, Figure 14, Figure 15, Figure 16, and Figure 17, one or more secret values 118 may be utilized to enhance security and / or ensure maintenance of a static state and / or data immutability withina state of one or more elements (vectors 102, data compartments 104, attribute-value pairs 105, etc.), as further shown and described herein.

[0175] Figure 14 illustrates a vector state enforcement process flow 1450, according to one or more embodiments. Operation 1400 may store a vector 102, for example a vector 102 bundled with and / or associated with a vectorset 100. Operation 1402 determines whether an independently verifiable input should be utilized. The independently verifiable input may be information or data only known to the system or device generating the seal set 124. If an independently verifiable input should not be utilized, operation 1402 may proceed to operation 1412, discussed below. If an independently verifiable input is to be utilized, operation 1402 may proceed to operation 1404. Operation 1404 may utilize or generate the independently verifiable input, e.g., generate a secret value 118. The secret value 118 may be stored within the system or device maintaining the state of the vectorset 100 and / or vector 102 of the vectorset 100. The independently verifiable value such as the secret value 118 may be a randomly generated value, for example utilizing a cryptographic algorithm with an entropy source as input. For example, the secret value 118 may be generated with a GUID algorithm, a hash algorithm (e.g., including the hash function 109), and / or another algorithm useful for generating unique, distinct values with a low probability reoccurrence and / or value collision. The secret value 118 may then be utilized as a hash input 108 to a hash function 109, along with other hash inputs 108 that would be ordinarily specified for formation of a seal hash 110. For example, and referring to Figure 21 for illustration, the vector hash 112vl(N) may be the output of a hash function 109, with inputs including the vectorset identifier 201, the rights data 202, the version data 203, the previous vector hash 112v 1(N-1 ), and the secret value 118 (which, in this context, may be numbered the secret value 118vl(N) for its generation and use within the first vector 102vl in the Nth state). Operation 1410 may then output a seal hash 110 such as a vector seal 1 12 (in the present example, the vector hash 1 12vl (N)). Operation 1410 may extract the vector seal 112, and then in operation 1414 transmit the vector seal 112 to a server (e.g., a second system or device, e.g., the server 700B). In one or more embodiments, for example, all or a portion of the vector state enforcement process flow 1450 may occur in sealing the vectorset 100 upon arrival at an “endpoint.” The endpoint may be a location of long term storage, a location defining a storage location at the terminus of a data processing transaction, etc. In one or more embodiments, the vectorset 100 may be moved between client devices 600 as endpoints (e.g., a client device 600A to a client device 600B). Operation 1414 may then end (e.g., with the vectorset 100 securely stored), and / or proceed along path ‘Circle B’ to the process flow of Figure 15.

[0176] Where the sealing schema may utilize seal groupings 115, a secret value 118 can be generated for one or more of the seal groupings 115 of the vectorset 100, and in one or more embodiments, each of the seal groupings 115 defining the sealing schema.

[0177] Figure 15 illustrates a vector state enforcement process flow 1550, according to one or more embodiments. Operation 1500 may initiate a transaction related to the vectorset 100. For example, the transaction may be a change in location from a first system or device to a second system or device, a change in ownership of the vectorset 100 from a first user to a second user, an initial issuance of a digital currency, etc. The transaction may have occurred almost immediately after operation 1414 (e.g., miliseconds, seconds),or may have occurred at a later time (e.g., minutes, months, years). At the time operation 1500 is initiated, the vectorset 100 may be at rest in a device or system which generated and stored the secret value 1 18 before reporting the vector seal 112 to which the secret value 118 was a hash input 108 (e.g., the hash function 109 outputting the secret value 118). The transaction may involve one or more data operations 134 performed on the vectorset 100 by one or more devices and / or systems. In one or more embodiments, only those vectors 102 which need to be operated on may need to be decrypted (if they are encrypted), transmitted to a processing system, and / or otherwise utilized. However, in one or more other embodiments, the entire vectorset 100 may also be moved or transmitted as bound set, especially in such case as the vectorset 100 implements a unique, actual-possession based, data storage container. It should be noted that, as shown and described herein, where the vectorset 100 is able to have a controlled location and controlled state, and therefore uniqueness of the vectorset 100, then it is possible to ensure that the vectorset 100 exists in one and only one location, enabling data ownership or control based on actual possession of that data in computing memory ownered or controlled by a user.

[0178] Operation 1502 may transmit the vectorset 100 and / or the vector 102 along with the vector seal 112 and the secret value 118. These components may be transmitted to a device and / or system which stores or has access to the vector seal 112 originally reported. Operation 1504 may then re-calculate the vector seal 112, and, to effect the re-calculation, operation 1506 may input hash inputs 108 and the secret value 118 into the hash function 109. In operation 1508, the re-calculated vector seal 112 may be output from the hash function 109 and stored. Operation 1510 queries the vector seal 112 originally received (including in any distinct device or system to which it may be stored).

[0179] Operation 1512 may then compare the vector seal 112 and the re-calculated vector seal 112 to determine whether the vector seal 112 and the re-calculated vector seal 112 match. If no match occurs, then operation 1512 may proceed to operation 1518, which may determine that a state of the vector hash 112 has not been maintained. For example, data within a data compartment 104 of the vector 102 may have been altered impermissibly following reporting of the vector hash 112 to a device or system responsible for later checking against the reported state. Alternatively, or in addition, the failure to match may be the result of an incorrect secret value 118, which may indicate that the vector 102 and / or vectorset 100 is in an outdated state (e.g., N-l, rather than N), or even that the vectorset 100 received is fraudulent. Operation 1520 may then reject and / or roll back the transaction, for example similarly to the two-phase commit rollback described in conjunction with operation 1322 of Figure 13.

[0180] Where a match is determined in operation 1512, operation 1512 may advance to operation 1514, which may verify that the vector state has been maintained and authorize the transaction to proceed. Operation 1516 may then execute the transaction, including any data operations 134 and any prescribed or automatic updates in state. In one or more embodiments, especially where the transaction is a transfer transaction between devices or systems, the vector 102 may be subject to a state update resulting in a new secret value 118 being generated (e.g., a secret value 118(N+ 1 )) and a new vector hash 112 being reported (e.g., a vector hash 112(N+1 )). In such case, operation 1516 may proceed along path ‘Circle C’ to return to the process flow of Figure 14. Otherwise, operation 1516 may end with the transaction having completed.

[0181] Figure 16 illustrates a vector state enforcement process flow 1650, according to one or more embodiments. While the process flows of Figure 15 and Figure 16 discuss state control and enforcement at a vector-level, Figure 16 and Figure 17 generalize a state enforcement process that may, for example, apply to the vectorset 100 as a whole, or major portions thereof (E.g., multiple vectors 102). This can introduce additional advantages such as confirming that no modification has occurred anywhere within a vectorset 100 with regard to a given state (e.g., that the state N has been maintained).

[0182] Operation 1600 may store the vectorset 100 in a first device and / or system. For example, as previously described, the first system may be a user system, such as a collection of computers or devices associated with the user, or may be a single device (e.g., the client device 600) or element of a device (e.g., a particular hard drive). Operation 1602 may increment the state N of the vectorset 100. For example, if the vectorset 100 was in its thousandth state (e.g., the vectorset 100(1000), operation 1602 may initiate the thousandth plus one state (e.g., the vectorset 100(1001)).

[0183] Operation 1604 generates a plurality of seal hashes 110 for the new state, which may also be referred to as the seal set 124. For example, depending on the sealing schema, the seal hashes 110 generated may include vector hashes 112, index hashes 116, and / or seal sets 124. In one or more embodiments, the vectorset hash 120 at this point may not yet have been calculated. Operation 1606 may then generate a secret value 118. As previously described, the secret value 118 may be generated with a hash algorithm (e.g., including the hash function 109), and / or another algorithm useful for generating unique, distinct values with a low probability reoccurrence and / or collision. Operation 1608 may then store the secret value 118, optionally within the first system. In one or more embodiments, the secret value 118 may be stored directly in the vectorset 100. However, in one or more other embodiments, the secret value 118 may be stored in a different portion of the first system or device, may be stored in a vectorset associated with a user profile 2210 (e.g., the vectorset 2200), may be subject to further encryption, and / or may otherwise be secured. For example, there may be hundreds of vectorsets 100 stored on the first device or system, each of which may have a single secret value 118. Alternatively, each of the vectorsets 100 stored on the first device or system may share a secret value 118, especially if they were received and are expected to be later transmitted as a group.

[0184] Operation 1610 inputs the plurality of seal hashes 110 and the secret value 118 into a hash function 109. For example, and with reference to Figure 21, the following may act as hash inputs 108: (i) the vector hash 112vl(N) through vector hash 112vlO(N); (ii) the index hash 116i 1 (N) through the index hash 116i8(N), and (iii) the secret value 118 generated in operation 1606 (not shown in Figure 21). Operation 1612 may output the vectorset hash 120 as a static state verification hash 121 at state N (which was incremented in operation 1602). Operation 1614 may then transmit the static state verification hash 121 to a different device or system, for example to act as “proof’ or “evidence” of the present state N that was incremented in operation 1602. Operation 1614 may then proceed along path ‘Circle D’ to the process flow of Figure 17.

[0185] It should be noted that a seal hash 110 can be defined to include an arbitrary portion of the vectorset 100. For example, there could be two “half vectorset hashes” that each cover five of ten total vectors 102. Itis also possible for there to be multi-vectorset hashes, for example sealing several related or bound vectorsets 100.

[0186] Figure 17 illustrates a vectorset state enforcement process flow 1750, according to one or more embodiments. Operation 1700 may initiate a transaction related to the vectorset 100. For example, the transaction may be a change in location from a first system or device to a second system or device, and / or change in ownership of the vectorset 100 from a first user to a second user. The transaction may have occurred almost immediately after operation 1614, or may have occurred at a later time. At the time operation 1700 is initiated, the vectorset 100 may be at rest in a device or system which generated and stored the secret value 118 before reporting the vectorset hash 120 (which may be utilized as the static state verification hash 121) to which the secret value 118 was an input (e.g., the hash function 109 outputting the secret value 118). The transaction may involve one or more data operations 134 performed on the vectorset 100 by one or more devices and / or systems.

[0187] Operation 1702 may transmit the vectorset 100 and the secret value 118, for example to a second device and / or system. The second device and / or system which may store, or has access to, the vectorset hash 120 that was originally reported. Operation 1704 may then re-calculate the vectorset hash 120. Operation 1706 may input the hash inputs 108 and the secret value 118 into the hash function 109. In operation 1708, the re-calculated vectorset hash 120 may be output from the hash function 109 and stored. Operation 1710 queries the vectorset hash 120 originally received and intended to act as the static state verification hash 121 (including querying any distinct device and / or system to which the originally received vectorset hash 120 was transmitted and shared).

[0188] Operation 1712 may then compare the vectorset hash 120 and the re-calculated vectorset hash 120 to determine whether the vectorset hash 120 and the re-calculated vectorset hash 120 match. If no match occurs, then operation 1712 may proceed to operation 1718, which may determine that a state of the vectorset 100 has not been maintained. For example, data within a vector 102 and / or a data compartment 104 may have been altered following reporting of the static state verification hash 121. Alternatively, or in addition, the failure to match may be the result of an incorrect secret value 118, which may indicate that the vectorset 100 is in an outdated state (e.g., N-l, rather than N), or even that the vectorset 100 received is fraudulent. Operation 1720 may then reject and / or roll back the transaction, for example similarly to the two-phase commit rollback described in conjunction with operation 1322 of Figure 13 and operation 1520 of Figure 15.

[0189] Where a match is determined in operation 1712, operation 1712 may advance to operation 1714, which may verify that the static state of the vectorset 100 has been maintained and authorize the transaction to proceed. Operation 1716 may then execute the transaction, including any data operations 134 and updates in state. In one or more embodiments, especially where the transaction is a transfer transaction, the vectorset 100 may be subject to a state update resulting in a new secret value 118 being generated (e.g., a secret value 118(N+ 1)) and a new vector hash 112 being reported (e.g., a vector hash 112(N+1)). In such case, operation 1716 may proceed along path ‘Circle E’ to return to the process flow of Figure 16. Otherwise, operation 1716 may end with the transaction having completed. In comparing the vectorset state enforcement process flow1750 and the vector state enforcement process flow 1550, it will be noted that both can be utilized. For example, the same or different instances of the secret value 1 18 may be utilized with both a vector seal 1 12 and / or the vectorset hash 120.

[0190] Figure 18 illustrates a vectorset use policy process flow 1850, according to one or more embodiments. Operation 1800 receives a request for use of data of a vectorset 100 and / or a request to perform a data operation 134 on the vectorset 100 (e.g., the use request 504). In general, a user of data of the vectorset 100 may include one or more data operations 134, each of which may occur on a portion of the vectorset 100 and may occur within a context that can be assessed. As one example, an application 602 may request access to and / or use of data stored within the vectorset 100, e.g., a file stored or referenced in the content vector 270. In a specific example, the application 602 may first request a representation 271 of the vectorset 100 and / or the content data 278 (e.g., a graphical representation, such as an image thumbnail usable to populate a menu or a list on a GUI), and then, upon receiving a selection by a user of the application 602 (e.g., the user selecting the thumbnail), requesting the complete content data 278. In another example, the request for use of data may include a query to gather data or information about numerous instances of the vectorset 100 stored in a device or system (e.g., a query of each of the vectorset identifiers 201 within a segment of computer readable memory). It will be noted by one skilled in the art that in each of these two examples of data use, such use may require a read operation (e.g., a type of data operation 134). In yet another example, the use request 504 may be a data operation 134 that may include a write operation and / or an update operation to change the owner (e.g., change the owner identifier 211), or write to another data compartment 104 of the vectorset 100. Other use and / or constituent data operations 134 may be performed as a result of a transaction (e.g., a move transaction, a change owner transaction). The use request 504 and / or query may include information about the requesting device, system, and / or intended use, for example a user ID, a device ID, a geospatial coordinate generated by a device at the use request 504, and application 602 generating the use request 504, and / or other data which may be assessed by the use policy 400, as described below.

[0191] Operation 1802 determines the scope of the use request 504 and / or included data operation 134. For example, operation 1802 may determine if the use request 504 and / or data operation 134 applies to the vectorset 100 as a whole, one or more vectors 102 of the vectorset 100, one or more data compartments 104 of the vectorset 100, and / or one or more attribute-value pairs 105 of the one or more data compartments 104. This may be referred to as the WHAT of data use (e.g., the WHAT 403 atribute). If the querying or requesting device and / or system is aware of the vectorset schema and vector schemas of the vectorset 100 (e.g., size and data structure, layout, and / or format), the queried data, targeted data, and / or data to be operated on may be explicit within the query itself (e.g., a query for “all information in the owner vector 210”, or a query for “data compartment 104(v3i6), etc.). However, in one or more embodiments, queries or use requests 504 may be less explicit, especially if the vectorset schema of the vectorset 100 is either entirely or partially unknown to the querying device and / or system. For example, a query may be generated for all “representations” of vectorsets 100 within a database (e.g., a representation 271). Similarly, a query can be generated for “all seal hashes” of a vectorset 100, etc.

[0192] Operation 1804 queries the use policy 400 and loads the use policy 400 into computer memory for assessing use of the one or more vectorsets 100 queried. For clarity of explanation, Figure 18 will assume that a single vectorset 100 is requested for use and a single associated use policy 400 evaluated. Operation 1806 may then determine whether a controlled operation (e.g., a controlled operation 135) is implicated by (or likely to be implicated by) the use request 504 and / or constituent data operation 134. For example, the use policy vector 290 may be queried to determine whether the use policy 400 applies to the scope identified in operation 1802, e.g., the vectorset 100 as a whole, a vector 102 of the vectorset 100, a data compartment 104 of the vectorset 100, and / or an attribute-value pair 105 of a data compartment 104. Where controlled operations 135 are not implicated, operation 1802 may proceed along path ‘Circle F’ to operation 1900 of Figure 19, which, as shown and described below, may authorize the data use and / or data operation 134. Where one or more controlled operations 135 are implicated, operation 1806 may advance to operation 1808. In one or more embodiments, the controlled operation 135 may include a permissible use of data of the vectorset 100, an access right to the data of the vectorset 100 (e.g., a read operation), an access right to data referenced by the vectorset (e.g., data referenced by the content data 278), and / or a CRUD permission for the data of the vectorset 100 stored within the vectorset 100. In one or more embodiments, the controlled operation 135 may apply to a controlled portion of the vectorset 100 that is (i) all of the data of the vectorset 100, (ii) a vector 102 of the vectorset 100, and / or (iii) at least one data compartment 105 of the vectorset 100.

[0193] In one or more embodiments, the use policy 400 may be structured into distinct portions. In one or more embodiments, the use policy 400 may include a terms portion and a conditions portion. The terms portion may be stored in a terms data 402 (e.g., within the use policy vector 290) and the conditions portion may be stored within a conditions data 410. Although the word “terms” is used herein, the terms data 402 may still define what is known in the art of computing science as conditionals and / or define data defining conditional statements, as will be described. Similarly, although the word “conditions” is utilized, the conditions data 410 may still be colloquially understood to potentially define at least some of the “terms upon which something may be used”.

[0194] Rather, in one or more of the present embodiments, the terms portion, as defined and stored in the terms data 402, may specify explicit requirements of use that must be met prior to authorizing the controlled operation 135 to proceed. For example, the terms data 402 may specify WHO may perform the controlled operation 135 (e.g., a particular user, group of users, or type of users), WHERE the controlled operation 135 may be performed (e.g., geospatial location of a device, or even which logical system or physical device or system), WHEN the controlled operation 135 may be authorized to execute (e.g., within a certain time of day, within a certain date range), and / or HOW MANY times the controlled operation 135 may be performed (e.g., in general, or even per location or user). Similarly, the terms data 402 may also specify WHAT is controlled (e.g., which specified portions of the vectorset 100, and / or specified portions controlled under certain circumstances). HOW MANY may also be interpreted as and / or defined as HOW MUCH, where, for example, the content vector 270 may include content data 278 that is severable (e.g., a total of 20 minutes of a file can be streamed; size and content query parameters for an Al model use, etc.). In one or more embodiments, the terms portion must be assessed before the conditions portion, which may represent at leasttwo advantages: (i) an initial determination of basic use queries can be quickly resolved without executing potentially more complex code, resource-intensive code, and / or making calls to external services, and (ii) the initial requirements for use may be easily human-readable. These advantages, for example, may reduce the resources typically required to resolve “smart contracts” (also known as self-executing contracts) on distributed ledger technology (DLT) systems, and similarly, prevent errors in interpretation that often lead to irreversible and / or expensive mistakes. An example of the terms data 402 is further shown and described in conjunction with the embodiment of Figure 20.

[0195] Operation 1808 therefore begins evaluation of the terms portion (e.g., as may be defined in the terms data 402). It should be noted that, at this point or previously, the user associated with the user ID (e.g., the user identifier 2111) will have already been electronically authenticated, as known in the art. The evaluation may first determine whether sufficient information exists to evaluate whether the terms portion is satisfied, and if so then proceed to perform the evaluation.

[0196] Operation 1810 determines whether sufficient information has been provided in the use request 504 and / or query to evaluate the terms portion. If insufficient information exists in the query or request, operation1810 may proceed to operation 1811. For example, where the user ID is provided (e.g., which may be needed if the WHO is specified), but a geospatial location has been omitted (e.g., which may be needed if the WHERE is specified as a geospatial boundary or location), operation 1810 may proceed to operation 1811. Operation1811 may then call the user requestor (and / or query generator), and / or may call an external system (e.g., which may be operated by a third party) for the omitted data. It will be recognized that some embodiments will be intentionally structured in this way: the use request 504 will include some of the data sufficient to evaluate terms, but a third-party system is required to fill in, validate and / or confirm the information. Alternatively, the request for additional information may go back to the system or device that generated the use request 504, for example out-of-band and / or across a different communication channel for security purposes. Operation 1811 may then return to operation 1808. Where sufficient information is available, operation 1810 proceeds to operation 1812.

[0197] Operation 1812 determines whether the terms arc satisfied. For example, the user ID 2211 of the requestor, a geospatial coordinate, the intended use or application 602 requesting use, and other data, may be compared against the terms data 402 (e.g., the WHO, WHAT, WHERE, WHEN, HOW MANY / MUCH). If the terms portion is not satisfied, operation 1812 may proceed to operation 1820, which may deny use and / or generate an error. The error may or may not be returned to the requestor. Where the terms are satisfied, operation 1812 may advance to operation 1814.

[0198] Where a use policy 400 should be defined to be only based on the flexible conditions portion, the terms data 402 may be set to a certain uniform value, e.g., left null, or each of the values of the WHO, WHAT, WHERE, WHEN, HOW MANY / MUCH set to an alphanumeric value defined to mean an ‘unlimited value’ . Conversely, where no use is permitted, one or more of the terms data 402 values may be set to zero or an alphanumeric value defined to mean no uses are permitted.

[0199] In one or more of the present embodiments, the conditions portion, as defined and stored in the conditions data 410, may specify additional requirements of use that must be met prior to authorizing the oneor more controlled operation 135 to proceed. The conditions portion may defined in a programming language (e.g., Java, Python, C, Swift, Go, etc.), a custom programming language, and / or through other means of expressing conditionals, loops, and / or other software engineering structures known in the art. The conditions data 410 may include functions, data objects, and / or define remote procedure calls to external systems, for example as shown and described in conjunction with Figure 20. In one or more embodiments, the conditions portion may be Turing complete. In one or more embodiments, the conditions portion may be usable to define highly flexible requirements or impose detailed conditions on use for the vectorset 100, portions thereof, and / or data therein, including rules for active monitoring of use if the requesting application 602 supports such monitoring. In one or more embodiments, the use will only be approved if the application 602 includes such monitoring capability, and, for example, the application developer of the application 602 retains a valid certificate that can be verified. As one example, the condition portion may specify that the vectorset 100 is only transferrable if a market price of a commodity is above a certain threshold, where the price of the commodity can be checked through a query to an external service (e.g., the COMEX exchange API). In another example, the conditions portion may specify that a multimedia file is usable so long as the user does not take a screenshot. In this example, an additional condition may include that the application 602 requesting use is registered with a system controlling the vectorset 100 and that the application is confirmed to have screenshot monitoring and reporting. The use policy 400 or relevant portions thereof may be copied and transmitted along with any returned data for enforcement of the application 602, according to one or more embodiments.

[0200] An advantage of the conditions portion is that the vectorset 100 may remain able to be controlled with high flexibility and specificity, e.g., as may be available in some “smart contracts” on DLT systems. In still other cases, the condition portion exceeds the flexibility of DLT systems and / or blockchain-based systems due to the lack of constraint of transacting on the “on chain” network. In one or more embodiments, certain safeguards may be placed on the Turing complete aspect; for example, certain processes may be given an execution time limit, computing resources allocation, working memory allocation (and / or temporary storage space within the vectorset 100 for storing variables and values), or other limits to prevent infinite loops or continuous attempts to contact unresponsive remote systems. Where bilateral or multilateral constraint is desired to form a self-executing contract subject to reduced or no unilateral revocation or modification, such inflexibility can be defined in a variety of ways. For example, a use policy 400 may be defined that contains its own owners’ vectorsets 100, and / or a vectorset 100 can have ownership transferred to a machine user that may arbitrate execution.

[0201] Operation 1816 may determine if sufficient information is present to evaluate the conditions portion. If not, operation 1816 may return to operation 1811. In one or more embodiments, the terms may be re-evaluated upon the request of any additional information for the conditions portion. For example, this may ensure that the WHEN or WHERE terms are complied with. However, in one or more other embodiments, the terms do not need to be re-evaluated. It should be noted that data received may be timestamped and have a limited “duration” in which it is permitted to be used, which may be implicit, or explicitly defined within the conditions data 410. Operation 1 18 may determine whether the conditions are satisfied. The evaluationmay require executing the code defining the conditionals, which may require extracting the code from the conditions data 410 and executing it on one or more devices and / or systems. If not satisfied, operation 1818 may proceed to operation 1820. However, if satisfied, operation 1818 may proceed along path ‘Circle G’ to the process flow of Figure 19.

[0202] The terms portion or the conditions portion, or sub-elements thereof, may also be referenced by the vectorset 100 (in contrast to direct storage in the vectorset 100). For example, in one or more embodiments a use policy reference 293 may designate a default use policy 400, including any terms data 402 and / or conditions data 410 thereof. However, in one or more embodiments, there may be an advantage to including all data required to be evaluated within the vectorset 100 such that when the vectorset 100 moves, the use policy 400 moves along with it and all data necessary to evaluate the use policy 400 is readily accessible and / or rapidly processable on a local CPU. In one or more embodiments, for example where the vectorset 100 is maintained in a controlled system of registered, certificated, authenticated devices, and / or applications 602 thereon, the use policy 400 may even be able to be evaluated for use by a device on which it is stored. For example, a first application 602B running on a smartphone may have allocated storage for vectorsets 100, and a second application running on the smartphone may request use of the vectorset 100. The first application 602 A may then evaluate the use policy 400 before enabling any use or a controlled operation 135 for the first application 602A. In one or more embodiments, a single application 602 storing the vectorset 100 may even evaluate use of a user using that application 602, especially where the application 602 or relevant SDK and / or code library is compiled and the user does not have access to source code.

[0203] Figure 19 illustrates a vectorset use policy process flow 1950 that is a continuation of the vectorset use policy process flow 1850, according to one or more embodiments. The use policy 400, a possible implementation of which is shown and described in conjunction with Figure 20, may control use of data of the vectorset 100 in one of several locations. First, a use request 504 may be generated locally on a system or device, and the use policy and data use assessed locally. This may be useful when a registered or certificated application 602 is requesting use of a vectorset 100 that was downloaded. Second, the use request 504 may be made remotely, with the potential use assessed and the vectorset 100 or data thereof then transmitted back to the requestor. The use may then be subject to further modification, similar to the first case. Third, request may be made remotely, and the entire vectorset 100 or a portion of the vectorset 100 sent for processing, before being returned to the system or device from which it was requested (where the possibility also exists to evaluate whether use was complied with to accept or reject the asserted data return). For example, this may occur when a first server 700 requests a vectorset 100 from a second server 700, operates on the vectorset 100, and returns the vectorset 100 (possibly in an evolved state) to the first server 700. Fourth, a remote use request 504 may be made, where both the use policy 400 is determined remotely and the intended use occurs remotely. This may occur, for example, where a user requests use of an algorithm or model stored in a vectorset on a server 700, and where the algorithm or model will execute remotely, possibly on data uploaded by the user. Any of these patterns may be reversed as well; the use request 504 may include a data “push” asking whether a device or system may attempt to use the vectorset 100 or data therein.

[0204] Operation 1900 authorizes use and / or the controlled operations 135. In one or more embodiments, no additional actions need to be performed or taken for use to proceed. However, certain continued aspects of the conditions portion may continue (e.g., active monitoring of use, processing, storing and / or reporting any data or metadata resulting from the use or constituent controlled operation 135, etc.). However, in one or more embodiments, the conditions portion, and / or a separate portion referred to as an adaptation portion (e.g., defined in the adaptation data 420), may modify the terms portion and / or conditions portion. In one or more preferred embodiments, and as shown in Figure 20, the adaptations portion may only modify the conditions portion (e.g., make changes or CRUD operations on the conditions data 410). This constraint may help promote clear, human-readable conditions precedent to use defined by the terms portion. Operation 1904 may determine whether the conditions portion should be updated. If the conditions portion should be updated, operation 1904 proceed to operation 1906, which may then modify the conditions data 410. The adaptations portion may also be defined in a programming language and may be Turing complete. In one or more embodiments, the conditions portion may revert to a default state following each use request 504 (e.g., resetting variables, etc.), while the adaptations portion may modify lines of executable code. An allocated memory 430 may store variables usable across use requests 504, etc. In one or more embodiments, an advantage to separating adaptations within the data structure of the vectorset may be a clear presentation of what may change across use requests 504 such that such changes do not get “lost” in the conditions data 410 and remain human readable. Similar to the terms data 402, this may reduce human error and increase clarity of presentation within the data structure.

[0205] Where the conditions portion is to be modified, operation 1904 may advance to operation 1906, which may modify the conditions data 410. Operation 1906 may then return along path ‘Circle H’ to operation 1814 to re-evaluate the changed conditions portion (if such changes are required to be evaluated). For example, the adaptation may have cause the conditions data 410 to change such that the user is no longer permitted to use the data and / or perform the controlled operation 135. However, this check may occur instantaneously, possibly with existing data from the use request 504, and except for any other conditions that may need to be evaluated or further adaptations, operation 1904 may be rapidly re-arrived at. In one or more other embodiments, operation 1906 may proceed directly to operation 1910 rather than return to operation 1814.

[0206] Operation 1908 may determine if the vectorset 100 should be generally updated, for example, the state of the vectorset 100, e.g., due to the use and / or controlled operation 135. If the vectorset 100 is to be updated, operation 1908 may proceed to operation 1910, which may optionally evolve the state of the vectorset 100 and / or generated updated seal hashes 110, including incorporating any modified conditions that occurred in operation 1906. Operation 1910 may then proceed to operation 1912. Similarly, where no vectorset update is to occur, operation 1908 may proceed to operation 1912. Operation 1912 may determine if an additional use request 504 is present. For example, the use request 504 may have included two or more serial and / or sequential use requests 504 (e.g., a user request 504A, a user request 504B), or execution of the conditions portion and / or adaptations portions may have triggered additional use requests 504. If additionaluse requests 504 are pending, operation 1912 returns along path ‘Circle I’ to operation 1806. Otherwise, operation 1812 may terminate.

[0207] It should be noted that the use policy 400 may store data related to the requested use (e.g., metadata, use reports, etc.), the data related to use may be stored within the vectorset 100 or data referenced by the vectorset 100. For example, a history of use can be stored, and even optionally included within transaction data 248 (e.g., as may be stored within the heredity vector 240). The data related to each use may be stored in a use report data 440, as shown and described in conjunction with the embodiment of Figure 20. In another note, the adaptations portion may occur even where use is denied in operation 1820.

[0208] Figure 20 illustrates a use policy 400 storable within and / or in association with, and / or referenced by the vectorset 100, according to one or more embodiments. The use policy 400 may include a terms data 402 (including one or more terms sections 401A through 401N), a conditions data 410, an adaptation data 420, an allocated memory 430, and / or one or more instances of a use report data 440.

[0209] In one or more embodiments, the use policy 400 may include a terms portion, as defined and stored in the terms data 402. The terms data 402 may specify explicit requirements of use that must be met prior to authorizing data use and / or one or more instances of a controlled operation 135 that make up that use. For example, and as shown in Figure 20, the terms data 402 may specify each or any of the following. A WHAT (e.g., a what term 403) may specify which portion of the vectorset 100 is being controlled (e.g., which specified portions of the vectorset 100, and / or specified portions controlled under certain circumstances). For example, in the term section 401 A, two vector IDs are specified in an array, e.g., the content vector 270 and the context vector 280. A WHO (e.g., a who term 404) may specify a user, class of user, group of users, category of user, and / or type of user who may perform the data use. For example, in the term section 401 A, the who term is shown specifying a user type. The user type may be qualified by reference to a requesting users’ profile or other available information. A WHERE (e.g., a where term 405) may specify a coordinate or location where the data use may be performed (e.g., geospatial location of a device or computer performing the use). For example, the where term 405 in the term section 401 is shown specifying a geospatial range, e.g., a geofence comprised of three or more geospatial coordinate pairs forming an area. WHERE may also or alternatively specify a system or device, a type of system or device (e.g., an iPhone, a secure enclave of a specific make and model, an HSM, etc.). Many other methods of geospatial reference are possible as known in the art, for example, reference to a single coordinate and calculation of a radius therefrom.

[0210] The WHEN (e.g., a when term 406) may specify a time, time range, or other temporal constraint. For example, the when term 406 in the term section 401A is shown specifying “business hours”, which may be further specified within the vectorset 100 or may be a standard default setting (e.g., 9AM to 5PM in the time zone of the location of permissible use). Alternatively, or in addition, the when term 406 may be a set time, a date range, etc.. The HOW MUCH (which may also be referred to as HOW MANY and / or an extent term 407), may specify the extent to which the data use and / or its controlled operations 135 may be performed. For example, depending on how configured, the extent term 407 may specify how many times data or portion thereof may be accessed or used, the amount of the data or a portion thereof may be accessed or used, theamount of time or other measure of the experience of the data or portion thereof that may be accessed or used, etc.

[0211] The second term section 401B shows that a data compartment 104 is specified by WHAT, a specific user ID 2211 is specified for WHO, a system ID is specified for WHERE (e.g., the user can only use the data when accessing the data through a particular system or communication network), no temporal constrain is specified by WHEN (e.g., a value of “any”), and no limit is placed on extent (e.g., a null within HOW MUCH).

[0212] Figure 20 further illustrates that the terms data 402 may include one or more terms sections 401 (e.g., a terms section 401 A, a terms sections 401B, etc.). The terms section 401 may carry a Boolean operator, specifically shown as “OR”, meaning satisfaction of any of the terms sections 401 may overcome threshold conditions precedent for proceeding with the use policy 400. Other Boolean operators are also possible, or arrangement or combinations thereof (e.g., AND, XOR). However, in one or more embodiments, OR may be preferred as a default. Additionally, where the vectorset 100 may be subject to complete control by the conditions data 410 and any adaptation data 420, the terms data 402 may be deleted or replaced by nulls or other unrestricted indicators in each of the fields.

[0213] Although WHO, WHAT, WHERE, WHEN, and HOW MUCH have ben specified in the terms data 402, it will be recognized the, in one or more embodiments, fewer, different, and / or additional conditions precedent to data use and / or evaluation of the conditions portion may be defined. For example, a CONCURRENT requirement could define a maximum number of concurrent users (although, in one or more embodiments, such a requirement could be implemented utilizing the conditions data 410).

[0214] In one or more of the present embodiments, the conditions portion, as may be defined and stored in the conditions data 410, may specify additional requirements of use that must be met prior to authorizing data use and / or a controlled operation 135 to proceed and / or may include rules to be monitored during use. As described above, the conditions data 410 may include conditional computer-executable code defined in a programming language (e.g., lava, Python, C, Swift, Go, etc.), a custom programming language, and / or through other means of expressing conditionals, loops, and other software engineering structures.

[0215] In one or more embodiments, and for example as shown in the embodiment of Figure 20, the conditions data 410 may include one or more: variables 411 (and declarations thereof), conditionals 412, loops 413, and / or functions 414, each of which will be known to one skilled in the art of computer science and / or software engineering. The conditions data 410 may also include data objects and other object-oriented programming structures. The conditions data 410 may further include and / or define vectorset procedure calls 415 to the vectorset 100 storing the use policy 400 and / or one or more other stored instances of the vectorset 100, whether on a local or remote device or system. The conditions data 410 may still further include one or more remote procedure calls 416 to one or more external systems. In one or more embodiments, the conditions portion may be Turing complete. However, an execution time limit, computing resources allocation, working memory allocation, and / or other limits may be implemented to prevent infinite looping, and / or runaway or cascading resource use.

[0216] The use policy 400 may further include an adaptation data 420. The adaptation data 420 may include executable instructions that modify the use policy 400. In one or more embodiments, the codemodification 422 may occur to the conditions data 410. In one or more embodiments, any modifications to the conditions data 410 may be logged, for example within the allocated memory 430, and any modifications may optionally trigger a state update of the vectorset 100.

[0217] The use policy 400 may include an allocated memory 430. The allocated memory 430 may be physically retained in a number of locations. In one or more embodiments, the allocated memory 430 may be stored in temporary computing memory registers and / or memory addresses associated with the vectorset 100 but distinct from the vectorset 100. However, in one or more other embodiments, the allocated memory 430 may be stored within the data structure of the vectorset 100, for example within one or more data compartments 104, such that the vectorset 100 may act as its own database allocated to execution of the use policy 400. The allocated memory 430 may be, for example, used to store standard code libraries utilized by the conditions data 410, used to store variables, functions, objects, and / or states of the conditions data 410, to act as a database accessible or usable by the conditions data 410, and / or to store use data and / or use reports (e.g., the use reports data 440). In one or more embodiments, the conditions data 410 may be able to store data usable between, among, or “across” use requests 504. As just one straightforward example, the conditions data 410 and the allocated memory 430 could together define authorization of “every other” use request 504 received, where the current status (e.g., whether the previous use request 504 was permitted or denied) may be stored in the allocated memory 430 as a variable spanning use requests 504 (e.g., IF x = 0, THEN Authorize Use and Set x = 1, IF x = 1, THEN Deny Use and Set x = 0).

[0218] The use report data 440 may store one or more use reports related to use requests 504. The use report data 440 may include metadata regarding the use request 504 (e.g., a requesting user or device, a timestamp, a requesting application 602, etc.), the outcome of the use request 504 (including, for example, the outcome of the evaluation of the terms data 402 and / or conditions data 410), any modifications made through the adaptation data 420, and / or any related state changes. The use report data 440 may be stored within the vectorset 100 and / or may be stored in an external database and referenced. This may be preferable in certain situations in which many use reports are generated, for example because use requests occur frequently (e.g., multiple times per day, hour, minute, or even second).

[0219] Figure 21 illustrates an example of the vectorset 100, referred to as the vectorset 2100, according to one or more embodiments. In one or more embodiments, the vectorset 100 may be implemented with ten instances of the vector 102 allocated for primary data storage, plus an additional vector 102 as a seal vector 117 (e.g., a total of eleven vectors 102). The vectorset 100 may evolve (e.g., through tensor transformation 132), forming a complex and secure digital entity that represents a set of data with unique identifying information, ownership history, origin, and / or other characteristics.

[0220] In one or more embodiments, the vectorset 2100 may include one or more of: an identity vector 200 (also referred to as an iD vector 200); an owner vector 210 (also referred to as an oW vector 210), an origin vector 220 (also referred to as an oG vector 220), a vectorset type vector 230 (also referred to as an gT vector 230, and / or a genotype vector 230), a heredity vector 240 (also referred to as an hY vector 240), a permission vector 250 (also referred to as a pN vector 250), a state vector 260 (also referred to as an sA vector260), a content vector 270 (also referred to as an nT vector 270), a context vector 280 (also referred to as an xT vector 280), a use policy vector 290 (also referred to as an uP vector 290), and / or a seal vector 1 17.

[0221] The vectorset 100 such as the vectorset 2100 may or may not store explicit designators in attributevalue pairs 105 for each of the vectors 102. For example, there may or may not be data stored in an attribute with an associated value for “identity” or “TY”. However, in one or more embodiments, a vector designator may be stored in an initial index (e.g., il) of each vector 102 such that each vector of the vectorset 100 may be individually addressed within the vectorset 100. For example, an application 602 could query the content vector 270, even without knowing which order the vector appeared in within the vectorset 100 binding. This may help is assisting applications 602 address the vectorset 100 as a data resource without knowing its exact description and / or definition.

[0222] The identity vector 200 may store fundamental identifiers for the vectorset 100 (e.g., the identity data 208), including the vectorsetJD' (e.g., a vectorset identifier 201) which may be usable to look up, query, and / or address the vectorset 100, according to one or more embodiments. The identity vector 200 may also include a rights data 202 for any legal annotations, such as patent, copyright, and / or trademark rights, and a version data 203 to track an iteration of the vectorset 100, its vectorset schema and / or sealing schema, or other versioning requirements.

[0223] The owner vector 210 may store data related to ownership (current and / or former) of the vectorset 100. In one or more embodiments, the owner vector 210 may include an owner identifier 21 1 and an owner name 212. A previous owner or owners may also be specified in the owner vector 210. In one or more embodiments, the owner vector 210 may chronicle the ownership lineage through additional attribute -value pairs 105 for ‘last Owner’. In one or more embodiments, and depending on the use to which the vectorset 100 is intended, each and every previous owner identifier (e.g., a user ID 2211) may be stored, for example to demonstrate chain of title of a physical asset which the vectorset may represent. However, this implementation is likely not necessary for most uses of the vectorset 100.

[0224] The origin vector 220 may include origin data 228, for example as previously shown and described in conjunction with Figure 8 and Figure 9. In one or more embodiments, the origin vector 220 may store details related to the genesis of the vectorset 100 with, additional attributes such as 'created on' (e.g., a date) and 'created where' (e.g., a system and / or device that is physical and / or logical).

[0225] The vectorset type vector 230, which may also be referred to as the genotype vector 230, may describe the classification and attributes of the vectorset 100 and / or any vectorset schema or vector schemas. The type may also be referred to as the “genus”, in one or more embodiments. The vectorset type vector 230 may include an application identifier 231 of a software application that setup, uses, and / or has access to the vectorset 100. The vectorset type 232 may set the type and / or “genus”, including possibly determining the storage schemas (e.g., vectorset schema, vector schema) and / or and any sealing schema for the vectorset 100. The face value 238 may set a face value (e.g., “facie ad valorem” or facie valorem”), for example where the vectorset 100 or its contents represent value, a micro commodity, and / or a medium of exchange. Although not shown, the data schema and / or sealing schema may also be stored or described in one or more data compartments 104 of the vectorset 100.

[0226] The heredity vector 240 may store data related to a transaction history of the vectorset 100, especially as may be related to changes of ownership. In one or more embodiments, the heredity vector 240 may include immutable record of the vectorset 100 transaction history from one owner to another. The transaction history may be stored as a transaction data 248, for example including a sending user ID 241, a sending device ID 248, a receiving user ID 243, and / or a receiving device ID 244. It should be noted that, in one or more embodiments, and depending on the intended purpose of the vectorset 100, the owner vector 210 and the heredity vector 240 may be combined. In one or more other embodiments, the owner vector 210 and the heredity vector 240 may serve different purposes. For example, in one or more embodiments, the owner vector 210 may exclusively store information related to current ownership, whereas the heredity vector 240 may store information related to previous ownership. This separation may assist in controlling the data available to certain applications 602 or compartmentalizing data for general queries (and / or easy selection of controllable data by the use policy 400). For example, it may be easy to specify that outside queries checking current ownership are allowed, while those checking heredity would be denied and therefore only available to the owners inspecting their owned and / or possessed vectorset 100. In another example, the owner vector 210 may store legal ownership, whereas the heredity vector 240 may store all data related to transfer of the vectorset 100 between and among devices, even if legal ownership did not change during such transfers. Some transactions may be defined such that they are tracked as part of the “heredity”, while others may not (e.g., a use logged in a use report data 440).

[0227] A permission vector 250 may store a permission data 258 (not shown) that may specify who (e.g., which user(s), as may be specified by a user ID 2211) may make changes to the vectorset 100. In one or more embodiments, the permission may apply by default if no use policy 400 is set, may take priority over the use policy 400, and / or may apply to all portions of the vectorset 100 to which the use policy 400 does not provide access (e.g., data of the vectorset 100 may be said to be “private by default.”. For example, in one or more embodiments, the permission data 258 may be the only portion specifying who (generally the owner) can modify the use policy 400. The permission vector 250 may also, or alternatively, include an authorized behavior 251 that is an authorized behavior of the vectorset 100 in transacting and / or when one or more applications 602 or electronic devices, systems, and / or use profile utilizes the vectorset 100. As an example, an application may include a list of application behaviors that the vectorset 100 is subject to (e.g., for a digital currency, “buy”, “sell”, or “transfer”). In another example, the authorized behavior may be that of a user profile 2110, and may include an authorized behavior to login to the application 602, a vectorset acquisition action for acquiring ownership of the vectorset 100, a vectorset disposition action for disposition of the vectorset 100, and / or a process utilization action associated with the application 602, for example for using certain processing, functionality, and / or features of the application 602. The specified behaviors may, for example, implement application-side controls over use of the vectorset 100 by the application 602, in one or more embodiments. If a user profile 2210 is allowed (or prohibited) by the application 602 or its operator to engage in those behaviors, the application may not permit use of the vectorset 100 for engaging in such behaviors. This functionality could be used, for example, to freeze user accounts with respect to transacting in or with the vectorset 100 (at least with respect to the application 602), or create a buy-only account, toimplement an application demo with limited functionality, etc. In one or more embodiments, the authorized behavior 251 could also be utilized to implement a paid version of an application 602 with additional capabilities. Similarly, the permission vector 250 may also, or alternatively, include an authorized target 252. The authorized target 252 may specify a certain behavior and / or method that the vectorset 100 may be subject to, both by the owner and / or an external service.

[0228] The state vector 260 may store a record of a current status and / or current location of the vectorset 100, including its physical or logical positioning within the system. For example, the state data 268 may include a location ID 261 of a physical or logical location of the vectorset 100, a state seal 262 that may be an immutable seal hash 110 incorporating data related to location state, a storage device ID 263 (e.g., a device certificate, a MAC address, a static network address, and / or another device identifier), a location description (e.g., which may be human-readable and describe a current storage location), and / or the owner identifier 265 (which may be the same as the owner identifier 211, or may alternatively specify an owner of a device or the location on which the vectorset 100 is stored).

[0229] A content vector 270 may store a content data 278. In one or more embodiments, and depending on the intended use of the vectorset 100, the content vector 270 may store information about the content or data contained within the vectorset 100, which may be typically defined by an application developer using the vectorset 100 as a development resource. The content vector 270, depending on the intended use of the vectorset 100, may also be used to store a primary data modeled by, stored by, and / or represented by the vectorset 100, according to one or more embodiments. For example, the vectorset 100 may store multimedia data (e.g., a movie file, an audio file, an Al model, a set of Al model parameters or configurations, an Al model training data set or reference thereto, encryption keys, cryptocurrency-controlling private keys such as a private key used by Bitcoin or Ethereum, etc.).

[0230] The content vector 270 may also store a representation data 271 which may be used to represent the content and / or the vectorset 100. The representation 271 may be able to be independently queried (and which may have differing and / or more lenient use authorization requirements), for example to populate a menu of user interface of an application 602. As a specific example, the representation data 271 may include an image thumbnail, a sample sound that is a portion of an audio track, a low-resolution version of an image, a watermarked version of an image, etc. These representations can be used to help a user select or preview a higher quality version and / or higher quality version which may be a paid version.

[0231] A context vector 280 may store a context data 288, which may store an operational and / or a functional context in which the vectorset 100 or contents thereof is used, such as the behavior expected from the vectorset 100 in different electronic processing and / or transaction scenarios. In one or more embodiments, the context vector 280 may also, or alternatively, include an authorized behavior 281 of the vectorset 100, where the authorized vectorset 100 may be associated with certain triggering conditions and / or contexts. Similarly, the context vector 280 may also, or alternatively, include an authorized target 282 of the vectorset 100, where the vectorset 100 may be associated with certain triggering conditions and / or contexts. Where the vectorset 100 is utilized as a micro commodity and / or to represent value or a medium of exchange, and / or has been created in association with a series of proofs 162, the context vector 280 may store a run max value 283and / or a run sequence value 284, for example as shown and described in conjunction with the embodiment of Figure 9.

[0232] The vectorset 100 may include a use policy 400. The use policy 400, for example as shown and described in Figure 19, Figure 20, and throughout the present embodiments, may outline policies governing the use of the vectorset 100, including detailing any capabilities of use and / or restrictions of use. The use policy 400 may include a terms data 402, a conditions data 410, an adaptation data 420, and optionally an allocated memory 430, for example, as each arc shown and described in conjunction with the embodiment of Figure 20.

[0233] Each vector 102 within the vectorset 2100 may be additionally “sealed” with a hash value of the contents of that vector 102 (e.g., each of the data compartments 104 of the vector 102), which may ensure integrity of the information when maintaining each vector 102 in a static state and / or evaluating select modification locations 144 thereof. Specifically, any change to the data within the vector 102 may result in an incongruent vector hash 112 upon re-calculation and comparison to an originally calculated instance of the vector hash 112.

[0234] Within a vectorset 100 implementing a micro commodity, medium of exchange, and / or storing economic value, sealing of the contents of each vector 102, and any meta seals thereof, may ensure the integrity of the information. The previous vector hash 112 (e.g., for state N-l) refers to the hash of the previous state of the vectorset 100, and its incorporation as a hash input 108 (e.g., as shown and described in conjunction with Figure 4), especially when effected for all vectors 102 within the vectorset 100, may establish a secure and verifiable lineage of the vectorset 100. This data structure may therefore help enable precise and secure management of digital assets within one or more systems.

[0235] The vectorset 100 such as the vectorset 2100 may include a seal vector 117 which may be comprised of an index hash 116 for each index of the vectorset 2100. Although not shown, an additional instance of the seal vector 117 could also be included for storing a previous state of each index hash 116 (e.g., an index hash 116il(N-l) through an index hash 116i8(N-l)) for incorporation as a hash input 108 into the a hash function 109 outputting the index hash 116 at state N. The sealing schema that is the combination of vector hashes 112 and index hashes 116 may enable cross-referencing of seal trips 142 and determination of a modification location 144, for example as shown and described in conjunction with the embodiment of Figure 7A. Finally, the vectorset 2100 may include a vectorset hash 120, which may be the output of a hash function 109 with inputs comprising each of the seal hashes 112 (e.g., the seal hash 112vl(N) through the seal hash 112vlO(N)) and each of index hashes 116 of the index vectors 117 (e.g., the index vector 116i 1 (N) through the index vector 116i8). In the present example, the vectorset hash 120 may also act as a static state verification hash 121 that may be tripped when any change within the vectorset 2100 occurs (such change “tripping” at least one vector hash 112 and one index hash 116, which in turn “trips” the vectorset hash 120).

[0236] Figure 22 illustrates an instance of the vectorset 100, referred to as the vectorset 2200, usable to represent an evolving state of a user profile 2210, including secure storage of important information related to the user profile 2210, including authentication data 377 and / or encryption data 375, according to one or more embodiments.

[0237] For ease of reference, certain similar elements appearing in both the vectorset 2100 and the vectorset 2200 have being given different, but like numbering. Unless otherwise noted, the elements previous described in the embodiment of Figure 21 are the same. For example, the vectorset identifier 201 has generally been described as a unique identifier usable to unique address the vectorset 2100; the vectorset identifier 301 is an instance of the vectorset identifier 201 that may store a unique identifier for addressing the vectorset 2200 of Figure 22. New elements introduced in Figure 22 may carry new numbering in their last two digits; for example, the authorizer ID 349, as further described below.

[0238] In one or more embodiments, it will be recognized that a network of connected devices and / or a system with multiple communicating devices may use an identity management system whereby actions (such as logins, application actions, use requests, queries, etc.) may be performed on behalf of user profiles 2210. The user profile 2210, for example, may represent a natural person, an organization, and / or a machine-user. As known in the art, a user profile 2210 is generally authenticated as to ensure the intended user acts on behalf of the user profile 2210.

[0239] In one or more embodiments, the vectorset 100 may be utilized (i) to directly to store data as a user profile 2210 and / or (ii) to represent, store, and secure certain data associated with the user profile 2210 or its associated user. In the present example of Figure 22, a user profile 2210 is shown in a traditional user database 300. As will be recognized in the art, the user profile 2210 may include a user ID 2211, a user name 2212, and a set of user data 2213 (e.g., addresses, demographic information, etc.). However, as may not be known in the art, the user profile 2210 may then store and / or reference a vectorset 100, including for example, through the user vectorset reference 2214. The user vectorset reference 2214 may store the vectorset identifier 201 of the vectorset 100 (in this example, the instantiation that is the vectorset 2200). The user profile 2210 may also store references to any owned and / or controlled vectorsets 100, for example through an owned vectorset 2215 attribute, where the set of owned vectorsets 100 may be stored as values in an array, or through another storage mechanism or database data structure known in the art. The owned vectorset 2215 attribute may store one or more instances of the vectorset ID reference 2216, which may each store a value of a vectorset identifier 201. In one or more other embodiments, references to the set of owned vectorsets 100 may be stored within the vectorset 2200.

[0240] As illustrated in Figure 22, the vectorset 100, such as the instantiation as the vectorset 2200, may be utilized to model an evolving state of the user profile 2210, and store important data and / or information related to the user profile 2210 and its represented user, according to one or more embodiments. The owner identifier 311 may be the user ID 2211 of the user profile 2210.

[0241] In one or more embodiments, the user profile 2210 may be cryptographically bound (e.g., “tightly coupled”) to the vectorset 100 such as the vectorset 2200. As an example, the vectorset identifier 301 of the vectorset 2200 may be generated by inputting the user ID 2211, and potentially other data and / or a nonce, into a hash function 109 to output the vectorset identifier 301 , such that a testable and / or provable relationship exists between the user profile 2210 and the vectorset 2200. As described in conjunction with the embodiment of Figure 9, the vectorset 2200 may also utilize a proof 162, and may incorporate additional generationtransaction data 164 into the vectorset identifier 301 to further bind and / or associate the user profile 2210 with the vectorset 2200.

[0242] Possible differences in stored data and / or attribute-value pairs 105 between the vectorset 2100 and the vectorset 2200 will now be described. The vectorset 2200 may include a user type vector 335, which may store several items usable by an application 602 on which the user profile 2210 may log in to local or remote backend services of the application 602. The application key 336 may store a token and / or authentication key or other value usable to log into the application 602. A user role 337 may specify a role for the user profile 2210. A recovery code 338 may store backup codes usable to recover one or more authentication credentials for the application. Although one application 602 is referenced, it will be recognized that the user type vector 335 may be able to store such data for multiple applications 602. The user type vector 335 may also store an application API key for utilization of and / or development of the application 602.

[0243] The heredity vector 340 may include transaction data 348, where the transaction may be defined as the movement of the vectorset 2200 from one device or system to another. For example, in one or more embodiments, while the user profile 2210 may be replicated across systems, the user may be able to choose to maintain the vectorset 2200 on a device of the user (e.g., the client device of Figure 23), such that the user remains in control of its data. The from device ID 345 may store a device identifier of a device from which the vectorset 2200 was moved, and the to device ID 346 may store a device identifier of a device to which the vectorset 2200 was moved. A transaction identifier 347 may store a tracking identifier that may be assigned by a server or other system for the transfer, and an authorizer ID 349 may store the identifier of a party who authorized the transfer (e.g., which may or may not be the user associated with the user profile 2210).

[0244] In one or more embodiments, the heredity vector 340 may also store data related to logins or other authentications, where such events are themselves treated as transactions which may evolve the state of the vectorset 2200.

[0245] The authorized behavior of the vectorset 351 of the permission vector 350 may specify authorized behavior of the user within the application 602, for example a role and / or capabilities of a role. This designation may, for example, define the difference between a general user, a database administrator, a business administrator, and / or a developer for a referenced application 602. In another example, the authorized behavior of the vectorset 351 could specify that user profile 2210 is allowed to engage in a demo version, premium version, or unlimited version. In yet another example, such behavior could be set to “trade only”, “buy only”, “sell only”, or “on hold.” Similarly, the authorized target of vectorset 352 may specify permissible actions the application 602 may take with respect to the vectorset 2200, which may include predefined rights or performable data operations 134.

[0246] The content vector 370 may store authentication data 377, including authentication data for a user to log into the user profile 2210, to log into an account within the application 602, and / or other authentication actions. For example, the authentication data 377 may store a password or passphrase hash (e.g., such that a passphrase or password is not directly stored but can still be assessed, as known in the art), biometric data for comparison to that submitted by a user, etc. Similarly, the authentication data 377 may include authenticationkeys otherwise used by one or more applications 602. The content vector 370 may also store a set of one or more encryption keys 374, for example which may be usable to encrypt each vectorset 100 owned or controlled by the user profile 2210. Such encryption keys 374 may be used to encrypt data in a particular attribute-value pair 105 of a vectorset 100, a data compartment 104 of a vectorset, and of the seal hashes 110, and / or the entire vectorset 100, according to one or more embodiments.

[0247] Although not shown, the vectorset 2200 may also store the set of secret values 118, including for example corresponding to a present state of any vectorsets 100 stored in association with the user profile 2210.

[0248] Although not shown, it is also possible for a use policy vector 390 to be stored within, and / or a use policy 400 to apply to, the vectorset 2200, for example permitting limitations on external devices, systems, and / or application 602 for modifying data within the vectorset 2200.

[0249] In one or more embodiments, each of the vectorsets 100 owned by a user may make reference to the vectorset 100 that is bound to the user profile 2210 (e.g., the vectorset 2200), rather than the user profile 2210. For example, where the vectorset 2100 would be owned by the user profile 2210 bound to the vectorset 2200, the owner identifier 211 of the vectorset 2100 may store a value that includes a vectorset identifier 201 of the vectorset 2200. Such reference may create a level of indirection and keep some or all designations of data ownership within a controlled vectorset 100 modification “ecosystem”.

[0250] Figure 23 illustrates a vectorset storage, use, transmission, and / or evolution network 500 (also referred to as the vectorset network 500) usable for storing, moving, transacting in the vectorset 100, and / or, controlling state of, using data from, and / or authorizing data operations on the vectorset 100. In one or more embodiments, the vectorset network 500 may include a set of one or more devices such as client devices 600 and / or a set of one or more server 700 (e.g., referred to as “servers”), according to one or more embodiments. Each of the client devices 600 and servers 700 may be communicatively coupled through a network 502. The network 502 may be, for example, a local area network (LAN), a wide area network (WAN), a virtual private network (VPN), and / or the Internet. In the embodiment of Figure 23, the broken lines illustrate the movement of data and / or information from one device to another; however, it will be appreciated that such data and / or information moves over and / or through the network 502, and that such communication may involve two-way communication between the client(s) 600 and servers 700(s), for example standard TCP / IP packet confirmations, communications of newly generated states or evidence thereof (e.g., the seal sets 124), exchange of encryption keys, etc.

[0251] Figure 23 illustrates a set of client devices 600, the client device 600A through the client device 600N may include a first application 602A. The application 602A, for example, may store, process, evolve, perform data operations 134 on, and / or otherwise transact with the vectorset 100. As just one example, the vectorset 100 may represent a micro commodity or medium of exchange which can be moved around the vectorset network 500. In the present example, the vectorset 100 will be illustrated being moved from the client device 600A to the client device 600N.

[0252] In one or more embodiments, a client device 600A may store a vectorset 100 in a state ‘N’, referred to as the vectorset 100(N). The vectorset 100 may have been originated through multiple systems, devices, ormethods, for example as shown and described in conjunction with the embodiment of Figure 9. For example, although the vectorset 100 may be associated with a physical proof 160, not shown in the present embodiment.

[0253] The client device 600A may seal the vectorset 100(N), for example, utilizing any of the systems or methods described herein and / or with the vectorset hashing engine 710, as further shown and described in conjunction with the embodiment of Figure 7. A sealing schema may be following to effect the sealing of the vectorset 100(N), which may result in a seal set 124 and / or a vectorset hash 120 that may also be utilized as a static state verification hash 121, for example as shown and described in conjunction with Figure 2, Figure 6A, and throughout the present embodiments. The seal set 124 and the static state verification hash 121 for state ‘N’ may be respectively referred to as the seal set 124(N) and the static state verification hash 121(N) in the present example. At a first time, possibly immediately after the state ‘N’ is generated, the seal set 124 and / or the static state verification hash 121 may be communicated to the server 700A, where it may be stored.

[0254] The vectorset l OOfN) then may be transmitted to the server 700 A. The server 700A may first determine if the vectorset 100(N) was maintained in a state matching the seal set 124 and / or the static state verification hash 121, for example as shown and described throughout the present embodiments. A state enforcement engine 750 may be utilized to determine whether the state ‘N’ was maintained, for example as described in conjunction with the embodiment of Figure 25. Determination of whether the state ‘N’ was maintained may help determine that no tampering occurred at the client device 600A and / or that no “man-in- the-middle” attack occurred over the network 502. Following confirmation, the server 700A may perform a data operation 134 resulting in a state update to ‘N+l ’, and seal the vectorset 100(N+l) to result in the seal set 124(N+1).

[0255] The vectorset 100 subsequently may be intended to reach the server 700N, but via the server 700B, where the server 700B is intended to perform a data operation 134 that will result in a state update. The server 700B may be subject to an authority check whereby a modification of the vectorset 100 can be checked to ensure the server 700B docs not exceed its authority for modification. This could be advantageous for cybersecurity compartmentalization of IT systems, and / or of the server 700B is an external system or service controlled by a different technical or legal entity. It can also be advantageous where, despite a controlled “ecosystem”, the server 700B may be outside that ecosystem.

[0256] Therefore, the server 700A may forward the seal set 124(N+1) to the server 700N through the network 502, and at the same time transmit the vectorset 100(N+l) to the server 700B. The server 700B may perform one or more data operations 134 to result in the vectorset 1001N+2). The server 700B may or may not re-seal the vectorset 1001N+2). Re-sealing may not be necessary because this may be calculated by the server 700N and the server 700B has not provided a seal set to the server 700N, according to one or more embodiments.

[0257] The server 700N may have received and stored the seal set 124(N+1) from the server 700A. The server 700N may then receive the vectorset 100(N+2) from the server 700B and determine, through one or more systems or methods described herein, whether the server 700B exceeded its authority. For example, as shown and described in conjunction with the embodiment of Figure 25, an authority determination engine740 may reference an authority description 746 describing anticipated and / or permissible changes that may be made by the server 700B to the vectorset 100. The authority determination engine 740 may then calculate and determine the anticipated modification locations 144, for example through comparison of the seal set 124(N+1) to the received and / or recalculated seal set 124(N+2) and calculation of seal trips 142. (In one or more other embodiments, it will be understood that the server 700B may not be permitted to perform operations or modify the vectorset 100 (it may only have to perform read operations on the vectorset 100), in which case the server 700A could ensure the state ‘N+l’ was maintained by recalculation of the static state verification hash 121).

[0258] Optionally without evolving state, the server 700N may transmit the vectorset 100(N+2) to the client device 600N, which may then perform one or more operation on the vectorset 100 that may result in an updated state (e.g., the vectorset 100(N+3)). Although not shown, the client device 600N could then seal the vectorset 100(N+3) to result in the seal set 124(N+3) and the static state verification hash 121(N+3), which could be reported to the server 700A in anticipation of future transactions.

[0259] In any of the state transformations, the use policy 400 may be used to constrain the permissible modifications and / or data operations 134 that each client device 600 and / or server 700 performs (e.g., controlled operations 135), and where such modifications and / or data operation 134 may be verified for authority by a different client device 600 and / or server 700 through the forwarding and checking of the seal set 124 and / or static state verification hash 121.

[0260] The location, frequency, and conditions upon which a state update occurs may be arbitrarily defined. For example, in one or more alternate embodiments, the vectorset 100(N) may move entirely through the set of one or more servers 700, and may be deposited on the client device 600N, before receiving a state update to become the vectorset 100(N+l). In such example, state updates may occur when the vectorset 100 “lands” in a client device 600 as an “endpoint”, and may be otherwise considered in transit. However, in one or more other embodiments, the state update may occur where the vectorset 100 is moved between certain computing systems or devices, for example any server 700 to any other instance of the server 700.

[0261] In yet another example of the use of the vectorset network 500, the vectorset 100 may store a multimedia file such as digital audio or video that can be queried and used. For example, the client device 600X may include an application 602X which may play multimedia files. The application 602X may generate the use request 504 that may be transmitted to any of the servers 700 (and / or even client devices 600). The use request 504 may include a vectorset identifier 201 and may request use of content (e.g., the content data 278), for example a digital image, an audio file, a video file, an Al model, a proprietary dataset, etc. A use policy 400 of a vectorset 100 may be evaluated and resolved to result in a use determination, such as denial or authorization.

[0262] To demonstrate the flexibility of the vectorset 100, the two above examples in Figure 23 may be combined. In one or more embodiments, the vectorset 100 may store a unique multimedia file which is to be uniquely maintained and subject to one, and only one copy. According to one or more embodiments, because there is one and only one copy in the latest state, the multimedia file is able to be actually possessed by one and only one device or system. This example of the vectorset 100 may be able to be bought, owned, and soldby a user of the client device 600A. The use associated with the client device 600A may be able to monetize the unique multimedia file by transferring the vectorset 100 to a server (e.g., the server 700B) for monetization, for example allowing the client device 600X to query the vectorset 100 (e.g., with the use request 504). The server 700B may be permitted only to log use requests (e.g., within the use report data 440), but make no other modifications. The limited authority to store use report data 440 may be checked by the server 700N, for example. Subsequently, the user of the client device 600 A may sell the vectorset 100 to the client device 600N, resulting in a verification by server 700N that no modifications occurred and then a transmission to the client device 600N. The client device 600A may even be able to provide a seal set 124 to the buyer, such that the client device 600B can check to ensure the server 700 did not impermissibly alter the data.

[0263] To provide a straightforward example, Figure 23 has excluded the optional use of the secret value 118. However, it will be appreciated that, in combination with one or more other embodiments herein, the secret value 118 may be incorporated into the static state verification hash 121 and subsequently turned in for verification. For example, the secret value 118(N) may have been utilized as a hash input 108 resulting in the static state verification hash 121(N). When the client device 600A later transmits the vectorset 100(N), the secret value 118(N) may be included in the transmission. The server 700A may then verify that, utilizing the secret value 118(N), the static state verification hash 121(N) can be, in fact, re-calculated. A vectorset 100 can undergo temporary unbinding, with some of the vectors sent for independent modification. For example, the server 700B may only receive the content vector 270 and the context vector 280, before returning those vectors with modified values which can be copied into and / or re-merged with the vectorset 100, according to one or more embodiments. This mat also present an advantage when providing limited trust to certain devices or systems.

[0264] Possible instantiations of the client device 600 and the server 700 will now be described in greater detail in the embodiments of Figure 24 and Figure 25, respectively.

[0265] Figure 24 illustrates the device such as the client device 600 of Figure 23 which may store the vectorset 100, perform tensor transformations 132 comprises of one or more data operations 134 on the vectorset 100, evolve the state of the vectorset 100, seal the vectorset 100, transact in the vectorset 100, and / or perform other related operations, according to one or more embodiments. In one or more embodiments the client device 600 may include a processor 601 that is a computer processor and a memory 603 that is a computer readable memory (e.g., random access memory, a solid state drive, a disk drive, a memory-resistor, etc.). The memory 603 may store a vectorset 100(N) and any secret value 118.

[0266] In one or more embodiments, the client device 600 may include an application 602. The application 602 may, for example, receive and store instances of the vectorsets 100, view data from vectorsets 100, manage vectorsets 100, perform data operations 134 on vectorsets 100, transact in vectorsets 100, and / or otherwise utilize vectorsets 100 as a data resource, alone or in combination with other data resources. As one example, the application 602 may be a software application and / or computer program for storing and moving value represented by the vectorset 100. In such case, each vectorset 100 may implement a physically possessed denomination of value. In another example, the application 602 may include functionality for using,viewing, or trading multimedia data which could be monetized. In another example, the application 602 may be a private social network where profile data is stored within the vectorset 100 on each user’s client device 600 and individual use requests 504 are routed to the client device 600 such that the user keeps control of all, or almost all, data on the social network. Due to the flexibility of the vectorset 100 as a data storage container, almost any application 602 may be able to utilize and / or benefit from the vectorset 100, including defining new levels of functionality, privacy, validation, and security due to the numerous advances and advantages shown and described herein.

[0267] In one or more embodiments, the client device 600 may include a secret management engine 606. In one or more embodiments, the secret management engine 606 may include a secret generation routine 608 and a secret storage routine 610. In one or more embodiments, the secret generation routine 606 includes computer readable instructions that generate a secret value. For example, the secret generation routine 606 may gather entropy data from an entropy source (similar to the entropy source 161) and feed the entropy data into a hash function (e.g., similar to the hash function 109) or other algorithm for unpredictable value generation to result in an unpredictable and / or random value of sufficient complexity to be difficult to guess through manual or automated methods. Alternatively, or in addition, a random number generator may be utilized. In one or more embodiments, the secret storage routine 610 may store the secret value 118 on the computing memory 603 of the client device 600, for example the client device 600 on which the vectorset 100 is stored.

[0268] The client device 600 may additionally include any of the engines, routines, and / or modules shown and described in conjunction with the embodiment of Figure 25. For example, the client device 600 may also include the authority determination engine 740, which can determine if a server 700 (or a different peer client device 600) correctly exercised authority granted to it by the client device 600 if the vectorset 100 is sent to the server 700 (or other peer client device 600) for processing, use, and / or modification. However, two such elements are shown, the vectorset hashing engine 710 and the seal set communication routine 726, as each will be further shown and described in conjunction with the embodiment of Figure 25. For example, following receipt of the vectorset 100 (e.g., in an ‘N-l’ state), the client device 600 may evolve the vectorset to the ‘N’ state by performing one or more data operations 134. Evolution to the ‘N’ state may then trigger re-sealing the vectorset 100 (e.g., now in the ‘N’) state, which may be effected by the vectorset hashing engine 710, and then optionally transmitting or reporting that state, which may be effected by the seal set communication routine 726, according to one or more embodiments.

[0269] Figure 25 illustrates a device such as the server 700 Figure 23, for example usable to store the vectorset 100, process the vectorset 100, perform data operations 134 and tensor transformations 132 on the vectorset 100, perform data operations 134 and controlled operations 135, seal the vectorset 100, confirm static state maintenance of the vectorset 100, assess modification authority of the vectorset 100, and / or perform other related operations, according to one or more embodiments. It will be recognized that multiple instances of the server 700 may communicate over a communication network (e.g., the network 502), with each instance including all or a portion of the illustrated elements therein. For example, in one or more embodiments, a system may include multiple instances of the server 700, with elements repeated and / orallocated among the instances of the server 700 depending on processing and / or security needs. The server 700 may include a processor 701 that is a computer processor and a memory 703 that is a computer readable memory. The server 700 may include an authentication routine 705 for authenticating one or more users and / or associated data processing devices such as the client device 600 and / or a different instance of the server 700.

[0270] In one or more embodiments, the server 700 may include a vectorset hashing engine 710. The vectorset hashing engine 710 may include a scaling schema determination routine 712, a hash input extraction routine 714, and / or a vectorset hash generator 716, according to one or more embodiments. In one or more embodiments, the sealing schema determination routine 712 be configured to determine the sealing schema of the vectorset 100. For example, the sealing schema may be inferred (e.g., a necessary pattern, a hard-coded pattern applicable to all instances of the vectorset 100), may be explicit (e.g., defined in a database), and / or self-described (defined within the vectorset 100, itself). In one or more embodiments, the sealing schema determination routine 712 may derive a sealing schema that is dynamic. The determination of the dynamic sealing schema may be made with reference to data only available to two or more systems processing, transacting in, storing, and / or communicating the vectorset 100. For example, a client device 600 and a server 700 may setup and share an initial value, with deterministic rules for how that value changes. The deterministic rules may be based on data of later transactions of both the client device 600 and server 700, for example an observed state of the vectorset 100. As just one specific example, a random value available to both the client device 600 and the server 700 corresponding to a state N may be fed into a hash function 109 may result in a new random value for state N+l; and such the random number and the new random number both may be used to seed a deterministic algorithm that randomly assigns two each data compartment 104 to have two sealing pairs 1 14. Such sealing pairs 1 14 are likely to end up being non-adjacent in a vectorset with multiple vectors 112 and / or indicies. In one or more embodiments, the hash input extraction routine 714 may be configured extract hash inputs 108 from the vectorset 100 according to the sealing schema.

[0271] In one or more embodiments, the vectorset hashing engine 710 may be utilized to seal vectors 102 to form any of the vector hashes 110, such as a vector seal 112. For example, in one or more embodiments, the hash input extraction routine 714 may include computer readable instructions that when executed extract a first set of inputs (e.g., the hash inputs 108) from a first vector 102, the first set of inputs including a value of a first attribute-value pair 105 of a first vector 102 (e.g., the vector 102vl) and a value of each of one or more other attribute- value pairs of the first vector 102. The vectorset hashing engine 710 may then include computer readable instructions that when executed: (i) input the first set of inputs into a hash function 109, (ii) output a first hash value as a first seal hash 110, and (iii) store the first hash value in a second attributevalue pair 105 of the first vector 102 to evolve the vector 102 and define a vector seal 112 of the first vector 102. The vector seal 112 may enable detection of altered data within the first vector 102 that nay have occurred outside a valid instance of the update transaction (e.g., an instance of the data operation 134).

[0272] In one or more embodiments, the vectorset hashing engine 710 may be utilized to seal one data compartments 104 of or more indices, for example, all data compartments 104 of a specific index (e.g., i2) to form an index hash 116(i2). However, not every data compartment 105 of the index need be extracted, nordoes at least one data compartment of each vector 102 need to be extracted. For example, in one or more embodiments, the vectorset hashing engine 710 may include computer readable instructions that when executed extract a second set of inputs (e.g., hash inputs 108) comprising the value of the first attribute -value pair 105 of the first vector 102vl and a value from a first attribute-value pair 105 of a second vector 102v2. The vectorset hashing engine 710 may include computer readable instructions that when executed (i) input the second set of inputs into a hash function 109, (ii) output a second hash value (e.g., as an index hash 116), and (iii) store the second hash value in a first attribute- value pair, for example in a seal vector 117. The seal vector 117 may be utilized to enhance detection of alteration of data within the vectorset 100 without a valid instance of the data transaction and / or valid data operations 134 thereof. Detection of altered data can be used to detect an unmaintained state and / or impermissible authority.

[0273] In one or more embodiments, the vectorset hashing engine 710 may also be utilized to seal one or more seal groupings 115. In one or more embodiments, the hash input extraction routine 714 may include computer readable instructions that, when executed: (i) select a data compartment 104 of the vectorset 100; (ii) determine a first seal pair 114 comprising the first data compartment 104A and a second data compartment 104B comprising an attribute-value pair 105B of the second data compartment 104B; and (iii) determine a second seal pair 114B comprising the first data compartment 104A and a third data compartment 104C comprising an attribute-value pair 105C of the third data compartment 104C. The first seal pair 114A may include a data structure adjacency of the first data compartment 104A to the second data compartment 104B, and the second seal pair 114B may include a data structure adjacency of the first data compartment 104A to the third data compartment 104C. The data structure adjacent may be either plus or minus one vector value, plus or minus one index value, and / or plus or minus one vector value and one index value. For example, and as shown in the embodiment of Figure 6B, the data compartment 104(v1 ,i 1 ) may be adjacent within the data structure of the vectorset 100 to the data compartment 104(vl,i2), the data compartment 104(v2,il), and the data compartment 104(v2,i2). The vectorset hashing engine 710 may repeat this process for each data compartment 104 of the vectorset 100, or possible a smaller portion thereof (e.g., a single instances of the vector 102 to be protected, or even only a group of one or more data compartments 104).

[0274] In one or more embodiments, the vectorset hashing engine 710 may include computer readable instructions that when executed extract a value of the first data compartment 104 A and a value of the second data compartment 104B, and then input the value of the first data compartment 104A and the value of the second data compartment 104B into a hash function 109 to generate a third hash value 110 representing the first seal pair 114A. Similarly, the process may be repeated to result in a second instance of the seal pair 114B. The computer readable instructions of the vectorset hashing engine 710 may extract the value of the first data compartment 104A and a value of the third data compartment 104C, and input the value of the first data compartment 104A and the value of the third data compartment 104C into a hash function 109 to generate a fourth hash value representing the second seal pair 114B. The vectorset hashing engine 710 may also include computer readable instructions that when executed store the third hash value and the fourth hash value in association with the vectorset 100 (e.g., as a seal grouping 115 within the seal set 124). This may enable rapidand efficient detection of unauthorized alteration in the value of the first data compartment 104A, as shown and described herein.

[0275] In one or more embodiments, for a dynamic sealing schema, the pairs of each sealing schema may be selected at random and may be non-adjacent. For example, and referring to Figure 21, a data compartment 104 storing the origin timestamp 222 may randomly form a seal grouping 115 with two other data compartments, such as the run max value 283 and the sending user ID 241, where a seal pair 114A results from hashing the value of the origin timestamp 222 with the run max value 283, and a seal pair 114B results from hashing the origin timestamp 222 with the sending user ID 241. In one or more embodiments, more than two seal pairs 114 may be specified for the seal grouping 115, and / or the seal pairs 114 may include three or more data compartments acting as hash inputs 108 (despite being referred to as a “pair”). In one or more embodiments, the dynamic sealing schema may ensure that each data compartment 104 is selected for a seal pair 114 an equal number of times.

[0276] In one or more embodiments, the server 700 may include a vectorset state receipt agent 720 that may be configured to receive evidence or one more states of a vectorset 100, as may be evidenced by seal hashes 110 or other data. For example, the vectorset state receipt agent 720 may be configured to receive and process a seal set 124, a vectorset hash 120 (including when acting as a static state verification hash 121), and / or individual seal hashes 110 (e.g., a vector seal 112). In one or more embodiments, a seal set 124 or other seal hashes 110 of a vectorset 100 may be received along with the vectorset identifier 201 of the vectorset 100, and / or possibly other metadata. In one or more embodiments, the vectorset state receipt agent 720 may include computer readable instructions that when executed receive a vectorset hash 120 over a network (e.g., the network 502) as a static state verification hash 121. The static state verification hash 121 may be utilized to verify that additional modifications to the vectorset 100, wherever located, have not occurred upon future receipt of the vectorset 100. The vectorset state receipt agent 720 may then call the vectorset state storage module 722, which may store the vectorset hash 120, for example in an index within a database organized by vectorset identifier 201 such as the datastore 790, further described below. Similarly, the vectorset state receipt agent 720 may receive the seal set 124 and the vectorset state storage module 722 may store the seal set 124. The seal set 124 may be stored in a database for later use and comparison when the associated vectorset 100 is received. It should be noted that the vectorset hash 120 and / or the seal set 124 may optionally store all previous instances of the vectorset hash 120 and / or the seal set 124 back to the origination of the vectorset 100, and any secret values 118 used in generating the vectorset hash 120 or any of the seal hashes 110 of the seal set 124, which may enable enhanced tracking and / or verification back to origination and / or the proof 162.

[0277] In one or more embodiments, the server 700 may include a seal set extraction routine 724 which may extract one or more seal hashes 110 from a vectorset 100 (including any newly calculated seal hashes 110 due to a state update). The one or more seal hashes 110 may include, without limitation, one or more vector hashes 112, index hashes 116, one or more hash values of one or more seal groupings 115, and / or the vectorset hash 120. In one or more embodiments, the seal set extraction routine 724 may include computer readable instructions that when executed extract a plurality of seal hashes 110 form the vectorset 100, forexample a first hash value from the first vector 102 (e.g., a vector hash 112) and the second hash value from the seal vector 1 17 (e.g., an index hash 1 16). The plurality of seal hashes 1 10 may comprise the seal set 124. The seal set communication routine 726 may then transmit the seal set 124 and / or any constituent seal hashes 110 thereof to another system or device, for example a different server 700.

[0278] In one or more embodiments, the server 700 may include a vectorset transmission routine 728. The vectorset transmission routine 728 may be configured to move and / or transmit the vectorset 100 from one device to another, for example from a server 700 to a client device 600, from a client device 600 to a server 700, from a client device 600A to a client device 600B, and / or from a server 700A to a server 700B. In one or more embodiments, the vectorset transmission routine 728 may include computer readable instructions that when executed transmit the vectorset from a first data processing device (e.g., the client device 600A, the server 700A) to a second data processing device (e.g., the client device 600B, the server 700B). For example, a network address may be looked up for the second data processing device, a secure connection established (e.g., an encrypted TLS connection), and optionally a seal set 124 sent out-of-band for comparison to a seal set 124 calculated at the second data processing device. The out-of-band communication may be sent and received through a different application 602, a different network connector, a different communication channel, and / or a different network 502.

[0279] In one or more embodiments, the vectorset transmission routine 728 may include computer readable instructions that when executed initiate a location change of the vectorset 100 from a computing memory (e.g., the memory 703A) of the first device (e.g., the server 700A) to a computing memory (e.g., another instance of the memory 703) of a different device (e.g., the server 700B). The location change may include updating the state vector 260. For example, in one or more embodiments, the vectorset transmission routine 728 may include computer readable instructions that when executed generating a data operation 134 that includes a write operation, a delete operation, and / or an update operation on a first attribute-value pair 105 of the sA vector 260. For example, the location ID 261, the state seal 262, the storage device ID 263, and / or the location description 264 may be updated.

[0280] It should be noted that following update of a vector such as the state vector 260, both the hash input extraction routine 714 and the vectorset hashing engine 710 may then extract changed hash inputs 108 and input the hash inputs 108 into a hash function 109 to generate new seal hashes 110. For example, the hash input extraction routine 714 may include computer readable instructions that when executed extract a first set of inputs (e.g., the hash inputs 108) from the sA vector 260, where the first set of inputs may include a value of the first attribute-value pair 105 of the sA vector 260 and optionally a value of each of one or more other attribute-value pairs 105 of the sA vector 260. For example, and referring to the embodiment of Figure 21, the indexes il through i8 could be extracted. The vectorset hashing engine 710 may then include computer readable instructions that when executed: (i) input the first set of inputs into a hash function 109; (ii) output a first hash value (e.g., a seal hash 110) that may act as a location state seal hash, and (iii) store the location state seal hash in a second attribute-value pair 105 of a vector 102 (e.g., the sA vector 260) to evolve a state of the sA vector 260 and to enable detection of an unauthorized change in location of the vectorset 100.Similar processes may be followed to generate static states for other instantiations of vectors 102 shown or described herein, including those shown and described in conjunction with the embodiment of Figure 21.

[0281] In one or more embodiments, the server 700 may include a transfer enforcement engine 730. The transfer enforcement engine 730 may be configured to verify static state maintenance and / or operational or modification authority prior to permitting transmission and / or receipt of the vectorset 100. For example, the transfer enforcement engine 730 may be configured to authorize or deny (and / or initiate any transactional roll -back) related to sending or receiving the vectorset 100.

[0282] In one or more embodiments, the server 700 may include a seal state determination routine 732. The seal state determination routine 732 may be configured to determine a dynamic sealing schema of the vectorset 100, for example with information known only to two or more systems or devices (e.g., the server 700 and one or more other instance of the client device 600 and / or the server 700). In one or more embodiments, the seal state determination routine 732 may include computer readable instructions that when executed (i) extract a value known only to two or more devices and / or systems communicating over the network 502; and (ii) input the value into an algorithm that unpredictably but deterministically generates one or more designations of sealing pairs 114 and / or seal groupings 115 for each data compartment 104 of the vectorset 100; and (iii) generate an output data comprising the sealing schema that includes the designations of sealing pairs 114 and / or seal groupings 115 for each data compartment 104 of the vectorset 100.

[0283] In one or more embodiments, the server 700 may include a vectorset tracking engine 734. The vectorset tracking engine 734 may be store information (e.g., the transaction data 738) about where and / or what location a vectorset 100 is transmitted (e.g., a “location of record”), and what state the vectorset 100 is in when transferred and / or what state it evolves to following transfer, a current owner which now owns the vectorset, a previous owner which previously owned the vectorset, use reports, and / or other data related to transactions. Even where a possession-based “ecosystem” is implemented using uniquely maintained instance of the vectorset 100, this data may need to be maintained for regulatory purposes (especially where the vectorset 100 implements a digital currency or other value store), and / or for general statistical and development data related to the application 602. The transaction data 738 may be stored in a datastore 736. The transaction data 738 may also increase efficiency in certain transactions, for example by providing a threshold check if a transfer request originated from the last owner of record before employing one or more additional validation steps shown and described herein.

[0284] In one or more embodiments, the server 700 may include an authority determination engine 740 that may be configured to determine and / or evaluate the authority of a different data processing device, such as a different client device 600 and / or a different server 700. In one or more embodiments, the authority determination engine 740 may include computer readable instructions that when executed recalculate the plurality of seal hashes 110 (e.g., the seal set 124) to result in updated seal hashes. For example, the recalculation may occur after (i) a seal set 124 for a particular state (e.g., a seal set 124(N) was received that was associated with a particular vectorset 100 in a particular state (e.g., the vectorset 100(N)); (ii) the vectorset 100 is received from a different data processing system which modified or otherwise performed a data operation 134 to result in an updated state (e.g., the vectorset 100(N+1 ). The authority determination engine740 may include a seal comparison routine 742 configured to compare the seal set 124 at one state with the seal set 124 at another state (e.g., the seal set 124(N) with the seal set 124(N+1 )), where the seal set 124(N+1 ) may be recalculated by the server 700 once in possession of the vectorset 100(N+l)). In one or more embodiments, the authority determination engine 740 may include computer readable instructions that when executed compare the plurality of updated seal hashes 110 (e.g., the seal set 124(N+1)) to the original plurality of seal hashes 110 (e.g., the seal set 124(N)).

[0285] In one or more embodiments, the authority determination engine 740 may include an authority confirmation routine 744. The authority confirmation routine 744 may include computer readable instructions that when executed determine that a processing system (e.g., a client device 600, a server 700) executed within a processing authority (e.g., for performing data operations 134). For example, the execution evaluation may be made through determination that modifications only occurred at modification locations 144 that were permissible, for example by reference to the explicit description of the vectorset 100 (in an unmodified data compartment 104) and / or an authority description 746 which be stored on, or otherwise available to, the server 700. For instance, in the above example, the first seal hash 110A and the second seal hash HOB were updated within the plurality of updated seal hashes (e.g., the seal set 124) to implicate sole update of the first-attribute-value pair 105 of a vector 102, for example through cross-reference as show and described in the embodiment of Figure 7A. This technique may be applied to determine if the use policy 400 was executed, where the use, report data 440 can be assessed.

[0286] In one or more embodiments, the server 700 may include a state enforcement engine 750. The state enforcement engine 750 may be configured to enforce a state of one or more data compartments 104 of the vectorset 100, one or more vectors 112 of the vectorset 100, and / or the entire instance of the vectorset 100 (e.g., any and all elements of the vectorset 100). The state enforcement engine 750 may include a seal comparison routine 752 and / or a state confirmation routine 754. In one or more embodiments, the state enforcement engine 750 may include computer readable instructions that may recalculate the vectorset hash 120 of the vectorset 100 to generate a recalculated instance of the vectorset hash 120, which may be referred to as a recalculated vectorset hash 120. The recalculation may occur following previous receipt of a vectorset hash 120 acting as a static state verification hash 121 at a given state (e.g., the vectorset hash 120(N)). The seal comparison routine 752 may also include computer readable instructions that when executed compare the static state verification hash 121 and the recalculated vectorset hash 120. The state confirmation routine 754 may include computer readable instructions that when executed determine a match between the static state verification hash 121 and the recalculated vectorset hash to prove both (i) the static state of the vectorset 100 was maintained and (ii) the vectorset 100 was uniquely maintained within a data processing device from which the vectorset 100 was received. This can be further reinforced if the storage location ID 221 matches the storage location ID from the system or device from which the vectorset 100 was received and / or matches the location of record on the server-side, as may be stored in the vectorset transaction data 738. The state enforcement engine 750 may perform one or more actions in response to a termination the static state of the vectorset 100 was maintained, for example authorize transfer of the vectorset 100 from the one data processing system to another.

[0287] The state enforcement engine 750 may be similarly utilized with respect to a vector 102, or even a data compartment 104. For example, in one or more embodiments, a state of the sA vector 260 may be evaluated to ensure maintenance of location of the vectorset 100 and / or that the authorized location or associated data processing system last possessed or transmitted the vectorset 100.

[0288] In one or more embodiments, some vectors 102 and / or data compartments 104 may have less restrictive authorization for modification, while others (e.g., those evidencing storage location) may be more restrictive with respect to modification. In one or more embodiments, the state enforcement engine 750 includes computer readable instructions that when executed determine a match between a device identifier of a first device (e.g., a client device 600) and a device identifier stored in the sA vector 260 (e.g., the storage device ID 236). The state enforcement engine 750 may then recalculate the location state seal 267 (and / or the vector hash 112v7), which may have incorporated the storage device ID 236 as a hash input 108 according to the sealing schema. The state enforcement engine 750 may then compare the location state seal 267 and the recalculated location state seal 267. Where a match is determined between the location state seal 267 and the recalculated location state seal 267, it may be proved that the location of the vectorset 100 was maintained in the first device (especially where a controlled ecosystem requires state changes for any transmission or location change at any endpoint), and / or that the vectorset 100 was received from the “storage location of record” for the vectorset 100. The authority determination engine 740 may similarly access previous stored and / or returned seal set 124 to ensure compliance with a previously reported location inherently incorporated into the vector hash 112 of the state vector 260. As yet another check, where a secret value 118 was directly input into a hash function 109 outputting the location state seal 267 and / or the vector seal 112v7, the secret value 118 can be received and tested (e.g., at the device or system received the vectorset 100) when recalculating the location state seal 267 and / or the vector seal 112v7.

[0289] In one or more embodiments, the server 700 may include a use request agent 760. The use request agent 760 may be configured to receive the use request 504, for example, as shown and described in conjunction with the embodiment of Figure 23. In one or more embodiments, the use request agent 760 may include computer readable instructions that when executed determine a user identifier (e.g., a user ID 2211, an owner identifier 211) of a user profile 2210 associated with initiation of a data transaction. The data transaction may include one or more data operation 134, for example a read operation on the content data 270, an update operation on the owner identifier 211, etc. In one or more embodiments, the server 700 may also include a policy determination routine 762. The policy determination routine 762 includes computer readable instructions that when executed: query a use policy 400 of the vectorset 100 (e.g., in the uP vector 290, and / or by following a use policy reference 291); determine the data operation 134 includes controlled operation 135 that the user profile 2210 is permitted to initiate; and determine a controlled portion of the vectorset 100 to which the controlled operation 135 may be applied. For example, the controlled portion of the vectorset 100 may include a vector 102 (in which case the vector 102 may be referred to as a controlled vector), a data compartment 104 (in which the compartment 104 may be referred to as a controlled compartment 104), and / or an attribute-value pair 105 (in which case the attribute-value pair 105 may be referred to as a controlled attribute- value pair). In one or more embodiments, a use policy execution engine764 may be configured to execute the controlled operation 135 on the controlled portion of the vectorset 100. Tn one or more embodiments, the data transaction may also include the controlled operation 135. A possible example of the use policy 400, and description of execution and enforcement thereof, is further shown and described in conjunction with the embodiment of Figure 20. The example of Figure 20 further illustrates evaluation and / or execution of a terms data 402, a conditions data 410, and / or an adaptation data 420, including possible utilization of an allocated memory 430 and / or storage of a user report data 440.

[0290] The server 700 may include a datastorc 770 which may store a collection of one or more vectorsets 100. In one or more embodiments, the datastore 770 may include thousands, millions, billions (or more), instances of the vectorset 100, possible stored across many servers 700 and / or data centers. The vectorsets 100 may represent diverse sets of data, uses, mediums of exchange, multimedia, and / or resources of applications 602, according to one or more embodiments. Although multiple states of a vectorset 100 may be stored, theoretically back to an origin state, in one or more embodiments only the latest state of the vectorset 100 need be stored or maintained by the collection of data processing devices storing and / or transacting with the vectorset 100. The server 700 may also include the user database 2202, for example as shown and described in conjunction with the embodiment of Figure 22. The server 700 may additionally include a datastore 780 storing one or more secret values 118, for example as may be turned in within each vectorset 100 transaction and / or transfer, potentially with a reference to a corresponding entry in a dataset 790 which may store the seal set 124 and / or the vectorset hash 120, according to one or more embodiments. An index within the datastore 780 and / or the datastore 790 may be organized by vectorset identifier 201, which may enable efficient storage of any seal sets 124 and vectorset hashes 120 received prior to receiving a vectorset 100, and / or secret values 118 turned in along with a transmitted vectorset 100. The datastore 790 may therefore store the seal sets 124 against which recalculated hash seals 1 10 may be compared to evaluate state and / or authority.

[0291] Although the present embodiments have been described with reference to specific example embodiments, it will be evident that various modifications and changes may be made to these embodiments without departing from the broader spirit and scope of the various embodiments. For example, the various devices, engines, agent, routines, and modules described herein may be enabled and operated using hardware circuitry (e.g., CMOS based logic circuitry), firmware, software, or any combination of hardware, firmware, and software (e.g., embodied in a non-transitory machine-readable medium). For example, the various electrical structure and methods may be embodied using transistors, logic gates, and electrical circuits (e.g., application specific integrated circuitry (ASIC) and / or Digital Signal Processor (DSP) circuitry).

[0292] In addition, it will be appreciated that the various operations, processes, and methods disclosed herein may be embodied in a non-transitory machine-readable medium and / or a machine-accessible medium compatible with a data processing system (e.g., the vectorset network 500, client device 600, and / or server 700). Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense.

[0293] The structures in the figures such as the engines, routines, and modules may be shown as distinct and communicating with only a few specific structures and not others. The structures may be merged witheach other, may perform overlapping functions, and may communicate with other structures not shown to be connected in the figures. Accordingly, the specification and / or drawings may be regarded in an illustrative rather than a restrictive sense.

[0294] In addition, the logic flows depicted in the figures do not require the particular order shown, or sequential order, to achieve desirable results. In addition, other steps may be provided, or steps may be eliminated, from the described flows, and other components may be added to, or removed from, the described systems. Accordingly, other embodiments arc within the scope of the preceding disclosure.

[0295] Embodiments of the invention are discussed above with reference to the Figures. However, those skilled in the art will readily appreciate that the detailed description given herein with respect to these figures is for explanatory purposes as the invention extends beyond these limited embodiments. For example, it should be appreciated that those skilled in the art will, in light of the teachings of the present invention, recognize a multiplicity of alternate and suitable approaches, depending upon the needs of the particular application, to implement the functionality of any given detail described herein, beyond the particular implementation choices in the following embodiments described and shown. That is, there are modifications and variations of the invention that are too numerous to be listed but that all fit within the scope of the invention. Also, singular words should be read as plural and vice versa and masculine as feminine and vice versa, where appropriate, and alternative embodiments do not necessarily imply that the two are mutually exclusive.

[0296] Unless defined otherwise, all technical and scientific terms used herein have the same meanings as commonly understood by one of ordinary skill in the art to which this invention belongs. Preferred methods, techniques, devices, and materials are described, although any methods, techniques, devices, or materials similar or equivalent to those described herein may be used in the practice or testing of the present invention. Structures described herein are to be understood also to refer to functional equivalents of such structures.

[0297] From reading the present disclosure, other variations and modifications will be apparent to persons skilled in the art. Such variations and modifications may involve equivalent and other features which are already known in the art, and which may be used instead of or in addition to features already described herein.

[0298] Although claims have been formulated in this application to particular combinations of features, it should be understood that the scope of the disclosure of the present invention also includes any novel feature or any novel combination of features disclosed herein either explicitly or implicitly or any generalization thereof, whether or not it relates to the same invention as presently claimed in any claim and whether or not it mitigates any or all of the same technical problems.

[0299] Features which are described in the context of separate embodiments may also be provided in combination in a single embodiment. Conversely, various features which are, for brevity, described in the context of a single embodiment, may also be provided separately or in any suitable sub-combination. The applicants hereby give notice that new claims may be formulated to such features and / or combinations of such features during the prosecution of the present application or of any further application derived therefrom.

[0300] References to "one embodiment," "an embodiment," "example embodiment," "various embodiments," “one or more embodiments,” etc., may indicate that the embodiment(s) of the invention sodescribed may include a particular feature, structure, or characteristic, but not every possible embodiment of the invention necessarily includes the particular feature, structure, or characteristic. Further, repeated use of the phrase "in one embodiment," or "in an exemplary embodiment," “an embodiment,” do not necessarily refer to the same embodiment, although they may. Moreover, any use of phrases like “embodiments” in connection with “the invention” are never meant to characterize that all embodiments of the invention must include the particular feature, structure, or characteristic, and should instead be understood to mean “at least one or more embodiments of the invention” includes the stated particular feature, structure, or characteristic.

[0301] The enumerated listing of items does not imply that any or all of the items are mutually exclusive, unless expressly specified otherwise.

[0302] It is understood that the use of a specific component, device and / or parameter names are for example only and not meant to imply any limitations on the invention. The invention may thus be implemented with different nomenclature and / or terminology utilized to describe the mechanisms, units, structures, components, devices, parameters and / or elements herein, without limitation. Each term utilized herein is to be given its broadest interpretation given the context in which that term is utilized.

[0303] Devices or system modules that are in at least general communication with each other need not be in continuous communication with each other, unless expressly specified otherwise. In addition, devices or system modules that are in at least general communication with each other may communicate directly or indirectly through one or more intermediaries.

[0304] A description of an embodiment with several components in communication with each other does not imply that all such components are required. On the contrary a variety of optional components are described to illustrate the wide variety of possible embodiments of the present invention.

[0305] A "computer" may refer to one or more apparatus and / or one or more systems that are capable of accepting a structured input, processing the structured input according to prescribed rules, and producing results of the processing as output. Examples of a computer may include: a computer; a stationary and / or portable computer; a computer having a single processor, multiple processors, or multi-core processors, which may operate in parallel and / or not in parallel; a general purpose computer; a supercomputer; a mainframe; a super mini-computer; a mini-computer; a workstation; a micro-computer; a server; a client; an interactive television; a web appliance; a telecommunications device with internet access; a hybrid combination of a computer and an interactive television; a portable computer; a tablet personal computer (PC); a personal digital assistant (PDA); a portable telephone; a smartphone, application-specific hardware to emulate a computer and / or software, such as, for example, a digital signal processor (DSP), a field-programmable gate array (FPGA), an application specific integrated circuit (ASIC), an application specific instruction-set processor (ASIP), a chip, chips, a system on a chip, or a chip set; a data acquisition device; an optical computer; a quantum computer; a biological computer; and generally, an apparatus that may accept data, process data according to one or more stored software programs, generate results, and typically include input, output, storage, arithmetic, logic, and control units.

[0306] Those of skill in the art will appreciate that where appropriate, one or more embodiments of the disclosure may be practiced in network computing environments with many types of computer systemconfigurations, including personal computers, hand-held devices, multi-processor systems, microprocessorbased or programmable consumer electronics, network PCs, minicomputers, mainframe computers, and the like. Where appropriate, embodiments may also be practiced in distributed computing environments where tasks are performed by local and remote processing devices that are linked (either by hardwired links, wireless links, or by a combination thereof) through a communications network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices.

[0307] The example embodiments described herein can be implemented in an operating environment comprising computer-executable instructions (e.g., software) installed on a computer, in hardware, or in a combination of software and hardware. The computer-executable instructions can be written in a computer programming language or can be embodied in firmware logic. If written in a programming language conforming to a recognized standard, such instructions can be executed on a variety of hardware platforms and for interfaces to a variety of operating systems. Although not limited thereto, computer software program code for carrying out operations for aspects of the present invention can be written in any combination of one or more suitable programming languages, including an object oriented programming languages and / or conventional procedural programming languages, and / or programming languages such as, for example, Hypertext Markup Language (HTML), Dynamic HTML, Extensible Markup Language (XML), Extensible Stylesheet Language (XSL), Document Style Semantics and Specification Language (DSSSL), Cascading Style Sheets (CSS), Synchronized Multimedia Integration Language (SMIL), Wireless Markup Language (WML), Java.TM., Jini.TM., C, C++, Smalltalk, Perl, UNIX Shell, Visual Basic or Visual Basic Script, Virtual Reality Markup Language (VRML), ColdFusion. TM. or other compilers, assemblers, interpreters or other computer languages or platforms.

[0308] Computer program code for carrying out operations for aspects of the present invention may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C++ or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).

[0309] A network is a collection of links and nodes (e.g., multiple computers and / or other devices connected together) arranged so that information may be passed from one part of the network to another over multiple links and through various nodes. Examples of networks include the Internet, the public switched telephone network, the global Telex network, computer networks (e.g., an intranet, an extranet, a local-area network, or a wide-area network), wired networks, and wireless networks.

[0310] Aspects of the present invention are described above with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams,and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions / acts specified in the flowchart and / or block diagram block or blocks.

[0311] The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and / or flowchart illustration, and combinations of blocks in the block diagrams and / or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

[0312] These computer program instructions may also be stored in a computer readable medium that can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions stored in the computer readable medium produce an article of manufacture including instructions which implement the function / act specified in the flowchart and / or block diagram block or blocks.

[0313] Further, although process steps, method steps, algorithms or the like may be described in a sequential order, such processes, methods and algorithms may be configured to work in alternate orders. In other words, any sequence or order of steps that may be described does not necessarily indicate a requirement that the steps be performed in that order. The steps of processes described herein may be performed in any order practical. Further, some steps may be performed simultaneously.

[0314] It will be readily apparent that the various methods and algorithms described herein may be implemented by, e.g., appropriately programmed general purpose computers and computing devices. Typically a processor (e.g., a microprocessor) will receive instructions from a memory or like device, and execute those instructions, thereby performing a process defined by those instructions. Further, programs that implement such methods and algorithms may be stored and transmitted using a variety of known media.

[0315] When a single device or article is described herein, it will be readily apparent that more than one device / article (whether or not they cooperate) may be used in place of a single device / article. Similarly, where more than one device or article is described herein (whether or not they cooperate), it will be readily apparent that a single device / article may be used in place of the more than one device or article.

[0316] The functionality and / or the features of a device may be alternatively embodied by one or more other devices which are not explicitly described as having such functionality / features. Thus, other embodiments of the present invention need not include the device itself.

[0317] The term "computer-readable medium" as used herein refers to any medium that participates in providing data (e.g., instructions) which may be read by a computer, a processor or a like device. Such a medium may take many forms, including but not limited to, non-volatile media, volatile media, and transmission media. Non-volatile media include, for example, optical or magnetic disks and other persistent memory. Volatile media include dynamic random access memory (DRAM), which typically constitutes the main memory. Transmission media include coaxial cables, copper wire and fiber optics, including the wires that comprise a system bus coupled to the processor. Transmission media may include or convey acoustic waves, light waves and electromagnetic emissions, such as those generated during radio frequency (RF) and infrared (IR) data communications. Common forms of computer-readable media include, for example, a floppy disk, a flexible disk, hard disk, magnetic tape, any other magnetic medium, a CD-ROM, DVD, any other optical medium, punch cards, paper tape, any other physical medium with patterns of holes, a RAM, a PROM, an EPROM, a FLASH-EEPROM, removable media, flash memory, a "memory stick", any other memory chip or cartridge, a carrier wave as described hereinafter, or any other medium from which a computer can read.

[0318] Where databases are described, it will be understood by one of ordinary skill in the art that (i) alternative database structures to those described may be readily employed, (ii) other memory structures besides databases may be readily employed. Any schematic illustrations and accompanying descriptions of any sample databases presented herein are exemplary arrangements for stored representations of information. Any number of other arrangements may be employed besides those suggested by the tables shown. Similarly, any illustrated entries of the databases represent exemplary information only; those skilled in the art will understand that the number and content of the entries can be different from those illustrated herein. Further, despite any depiction of the databases as tables, an object-based model could be used to store and manipulate the data types of the present invention and likewise, object methods or behaviors can be used to implement the processes of the present invention.

[0319] Embodiments of the invention may also be implemented in one or a combination of hardware, firmware, and software. They may be implemented as instructions stored on a machine -readable medium, which may be read and executed by a computing platform to perform the operations described herein.

[0320] More specifically, as will be appreciated by one skilled in the art, aspects of the present invention may be embodied as a system, method or computer program product. Accordingly, aspects of the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a "circuit," "module" or "system." Furthermore, aspects of the present invention may take the form of a computer program product embodied in one or more computer readable medium(s) having computer readable program code embodied thereon.

[0321] Unless specifically stated otherwise, and as may be apparent from the following description and claims, it should be appreciated that throughout the specification descriptions utilizing terms such as "processing," "computing," "calculating," "determining," or the like, refer to the action and / or processes of a computer or computing system, or similar electronic computing device, that manipulate and / or transform data represented as physical, such as electronic, quantities within the computing system's registers and / or memories into other data similarly represented as physical quantities within the computing system's memories, registers or other such information storage, transmission or display devices.

[0322] The term "processor" may refer to any device or portion of a device that processes electronic data from registers and / or memory to transform that electronic data into other electronic data that may be stored in registers and / or memory. A "computing platform" may comprise one or more processors.

[0323] Those skilled in the art will readily recognize, in light of and in accordance with the teachings of the present invention, that any of the foregoing steps and / or system modules may be suitably replaced, reordered, removed and additional steps and / or system modules may be inserted depending upon the needs of the particular application, and that the systems of the foregoing embodiments may be implemented using any of a wide variety of suitable processes and system modules, and is not limited to any particular computer hardware, software, middleware, firmware, microcode and the like. For any method steps described in the present application that can be carried out on a computing machine, a typical computer system can, when appropriately configured or designed, serve as a computer system in which those aspects of the invention may be embodied.

[0324] It will be further apparent to those skilled in the art that at least a portion of the novel method steps and / or system components of the present invention may be practiced and / or located in location(s) possibly outside the jurisdiction of the United States of America (USA), whereby it will be accordingly readily recognized that at least a subset of the novel method steps and / or system components in the foregoing embodiments must be practiced within the jurisdiction of the USA for the benefit of an entity therein or to achieve an object of the present invention.

[0325] All the features disclosed in this specification, including any accompanying abstract and drawings, may be replaced by alternative features serving the same, equivalent or similar purpose, unless expressly stated otherwise. Thus, unless expressly stated otherwise, each feature disclosed is one example only of a generic series of equivalent or similar features.

[0326] Having fully described at least one embodiment of the present invention, other equivalent or alternative methods of implementing the vectorset 100, the use policy 400, the vectorset network 500, the client device 600, and / or the server 700, according to the present invention will be apparent to those skilled in the art. Various aspects of the invention have been described above by way of illustration, and the specific embodiments disclosed are not intended to limit the invention to the particular forms disclosed. The particular implementation of the vectorset 100, the use policy 400, the vectorset network 500, the client device 600, and / or the server 700 may vary depending upon the particular context or application. It is to be further understood that not all of the disclosed embodiments in the foregoing specification will necessarily satisfy or achieve each of the objects, advantages, or improvements described in the foregoing specification.

[0327] Claim elements and steps herein may have been numbered and / or lettered solely as an aid in readability and understanding. Any such numbering and lettering in itself is not intended to and should not be taken to indicate the ordering of elements and / or steps in the claims.

[0328] The description of the present invention has been presented for purposes of illustration and description, but is not intended to be exhaustive or limited to the invention in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the invention. The embodiment was chosen and described in order to best explain the principles of the invention and the practical application, and to enable others of ordinary skill in the art to understand the invention for various embodiments with various modifications as are suited to the particular use contemplated.

[0329] The Abstract is provided to comply with 37 C.F.R. Section 1.72(b) requiring an abstract that will allow the reader to ascertain the nature and gist of the technical disclosure. It is submitted with the understanding that it will not be used to limit or interpret the scope or meaning of the claims. The following claims are hereby incorporated into the detailed description, with each claim standing on its own as a separate embodiment.

Claims

CLAIMSWhat is claimed is:

1. A data structure for secure transmission, processing, and / or storage of data, the data structure comprising: a vectorset comprising n vectors, each vector of the vectorset comprising two or more data compartments, each data compartment of the two or more data compartments comprising an attribute-value pair, a vectorset identifier stored in a first data compartment of a first vector of the vectorset such that the vectorset may be uniquely addressed within a computing memory; a vector designator stored in an initial index of the vector such that a second vector of the vectorset may be individually addressed within the vectorset, a vector seal stored in a terminal index of each vector of the vectorset, wherein the vector seal comprising a first hash value generated as an output of a first hash function, with hash inputs to the first hash function comprising one or more other data compartments of the second vector of the vectorset in which the vector seal is stored, and wherein the n vectors comprising a seal vector comprising at least one data compartment storing a hash value generated as the output of the first hash function, with hash inputs to the first hash function comprising a value extracted from the attribute -value pair of at least one data compartment of each other vector of the vectorset; and a vectorset hash comprising a third hash value generated as an output of a second hash function, with hash inputs to the second hash function comprising each vector seal of each vector within the vectorset.

2. The data structure of claim 1, further comprising:N instances of the vectorset defining a tensor space having at least three dimensions, wherein a data operation that is at least one of a read operation, a write operation, an update operation, and a delete operation performs a tensor transformation on Nih instance of the vectorset to generate an Nth+1 instance of the vectorset reflecting completion of the data operation.

3. The data structure of claim 2, wherein for at least one vector of the Nth+1 instance of the vectorset, the hash inputs to the first hash function generating the vector seal of the Nth+1 instance of the vectorset further comprise a previous instance of the vector seal from the Nth instance of vectorset, to immutably associate the Nth instance of the vectorset with the Nth+1 instance of the vectorset.

4. The data structure of claim 2, further comprising: wherein at least one or more data compartments stores a use policy specifying a controlled operation, wherein the controlled operation is at least one of a permissible use of data of the vectorset, an access right to the data of the vectorset, an access right to data referenced by the vectorset, and a CRUD permission for the data of the vectorset stored within the vectorset, andwherein the controlled operation applying to a controlled portion that is at least one of (i) all of the data of the vectorset, (ii) a vector of the vectorset, and (iii) at least one data compartment of the vectorset.

5. The data structure of claim 4, wherein the use policy comprising a terms data, the terms data at least one of a user UID authorized to perform the controlled operation, a location at which the controlled operation can be executed, a time at which the controlled operation can be executed, and a number of times which the controlled operation can be executed by a computer processor.

6. The data structure of claim 5, wherein the use policy further comprising a conditions data, the conditions data comprising one or more conditionals that at least one of (i) must be satisfied prior to execution of the controlled operation, and (ii) upon satisfaction update the terms of the use policy.

7. The data structure of claim 6, wherein n > 5 and the n vectors of the vectorset further comprising: an identity vector usable to store data sufficient to uniquely address the vectorset, referred to as an iD vector, comprising the vectorset identifier stored in a first data compartment of the iD vector, optionally a vectorset version stored in a second data compartment of the iD vector, and optionally a rights data stored in a third instance of a data compartment of the iD vector; an owner vector usable to store ownership information associated with the vectorset, referred to as an oW vector, the oW vector comprising an owner identifier stored in a first instance of a data compartment of the oW vector, and optionally an owner name stored in a second instance of the data compartment of the oW vector; a transaction history vector usable to store information associated with a transaction history of the vectorset, referred to as at least one of a heredity vector and referred to as an hY vector, the hY vector comprising a transaction data stored in one or more data compartments of the hY vector, wherein the transaction data further comprising (i) a sending data comprising at least one of a sending user identifier and a sending device identifier, (ii) a receive data comprising at least one of a receiving user identifier and a receiving device identifier, and (iii) a transaction identifier; and a use policy vector, referred to as an uP vector, comprising the use policy, wherein the terms data comprising at least one of an authorized user identifier, an authorized time, an authorized location, and an authorized use extent, and wherein the uP vector optionally comprising a use policy reference to an instance of the use policy stored outside of the vectorset.

8. The data structure of claim 7, wherein n > 10 and the vectorset further comprising:an origin vector usable to store data associated with an origin of the vectorset, referred to as an oG vector, the oG vector comprising an origin data stored in one or more data compartments of the oG vector, wherein the origin data comprising an origin location identifier, an origin timestamp, and an originating user identifier; a state vector comprising data associated with at least one of a current storage location and a current status of at least one of a physical positioning and a logical positioning of the vectorset, referred to as an sA vector, the sA vector comprising a state data stored in one or more data compartments of the sA vector, wherein the state data comprising a location state seal that is the output of the first hash function with inputs comprising a state seal and a location identifier of the current storage location, wherein the state data optionally comprises a storage device identifier, a location description, and the owner identifier, a content vector usable to store data associated with one or more applications utilizing the vectorset as a data resource, referred to as an nT vector, the nT vector comprising an application data of at least one of the one or more applications, and optionally comprising an authentication data comprising at least one of a passphrase hash and an encryption key for communication with at least one of the one or more applications, a context vector usable to store data associated with at least one of an operational context and a functional context for the vectorset, referred to as an xT vector, the xT vector comprising an authorized behavior of the vectorset, and a vectorset type vector, referred to as a genotype vector and a gT vector, the gT vector comprising a creation application identifier of an application of the one or more applications that created the vectorset, a vectorset type specifying at least one of a class of the vectorset and a type of the vectorset.

9. The data structure of claim 7, wherein the vectorset is associated with a user profile of a user, n > 5, and the vectorset further comprises: a user type vector, referred to as uS, comprising at least one of a user role for an application at least one of reading from and writing to the vectorset, an application API key for at least one of utilization and development of the application, and a recovery code usable to recover the user profile of the user, wherein the owner identifier comprises a unique identifier of the user profile of the user; and a permission vector usable to store data associated with at least one of permissions of a user profile associated with the vectorset, referred to as a pN vector, the pN vector comprising an authorized behavior of the user profile and an authorized target for the authorized behavior of the user profile,wherein the authorized behavior of the user profile is at least one of a login to the application, a vectorset acquisition action for acquiring ownership of the vectorset, a vectorset disposition action for disposition of the vectorset, and a process utilization action associated with the application.

10. The data structure of claim 8, further comprising: wherein the hash inputs to the first hash function further comprising a data compartment of a different vector of the vectorset that is different from the vector of the vectorset in which the vector seal is stored, wherein an instance of the hash value that is generated as the output of the first hash function, with hash inputs of the first hash function comprising (i) a secret value generated by a device on which the vectorset is currently stored, and optionally (ii) the transaction data, wherein the instance of the hash value is utilized as a state indicator of the location of the vectorset, wherein the state indicator of the location of the vectorset is transmitted to a server for later evidence of a unique instance of the vectorset associated with at least one of the TV instances of the vectorset, and wherein the seal vector comprising at least x data compartments, where x is greater than or equal to the greatest number of data compartments of any other vector of the vectorset, and wherein each index value of each data compartment of the seal vector stores the hash value as the output of the first hash function with hash inputs comprising the value of each matching index value of the data compartment of each other vector of the vectorset.

11. The data structure of claim 8, wherein the vectorset further comprising at least one of (i) a face value for use as a digital currency, (ii) a physical object associated with the vectorset, and (iii) a non-fungiblc digital object associated with the vectorset, wherein the nT vector optionally comprising a run sequence value that is less than or equal to a run max value, and optionally the run max value.

12. The data structure of claim 8, wherein the vectorset comprising a content data to be controlled by the use policy, wherein the content data is at least one of a document, an audio file, a video file, an artificial intelligence model, and a dataset.

13. The data structure of claim 1, wherein the vectorset comprises an n by m dimensional matrix, with the n vectors each forming a row, and each vector of the vectorset comprising m data compartments resulting in m columns, each of the two or more data compartments of each of the n vectors defined at an intersection of each row and each column, the n by m dimensional matrix comprising: a row designation column wherein each data compartment of the row designation column comprising at instance of each of the vector designator of each vector of the vectorset; and a seal index wherein each data compartment of the seal index comprising an instance of the vector seal of each vector of the vectorset.

14. A method for secure transmission, processing, and / or storage of data, the method comprising: initiating a data transaction to at least one of a write, update, and delete data stored within a vectorset, wherein the vectorset comprising: n vectors, each vector of the vectorset comprising two or more data compartments, each data compartment of the two or more data compartments each comprising an attribute-value pair of each data compartment of the vectorset; and a vectorset identifier stored at least one data compartment of the vectorset, such that the vectorset may be uniquely addressed within a computing memory; generating a data operation that is at least one of a write operation, an update operation, and a delate operation on a first attribute-value pair of a first vector of the n vectors; extracting a first set of inputs from the first vector, the first set of inputs comprising a value of the first attribute- value pair of the first vector and a value of each of one or more other attributevalue pairs of the first vector; inputting the first set of inputs into a hash function; outputting a first hash value as a first seal hash; and storing the first hash value in a second attribute-value pair of the first vector to evolve the vector and define a vector seal of the first vector enabling detection alteration of data within the first vector without a valid instance of the update transaction.

15. The method of claim 14, wherein the vectorset further comprising a use policy, the method further comprising: determining a user identifier of a user profile associated with initiation of the data transaction; querying the use policy of the vectorset; determining the data operation comprises a controlled operation that the user profile is permitted to initiate; determining a controlled portion of the vectorset to which the controlled operation may be applied, the controlled portion of the vectorset comprising at least one of a controlled vector, a controlled compartment, and a controlled attribute-value pair; authenticating the user profile; and executing the controlled operation on the controlled portion of the vectorset, wherein is the data transaction comprises the controlled operation.

16. The method of claim 14, wherein the vectorset further comprising a seal vector, the method further comprising:extracting a second set of inputs comprising the value of the first attribute-value pair of the first vector and a value from a first attribute-value pair of a second vector; inputting the second set of inputs into the hash function; outputting a second hash value; storing the second hash value in a first attribute-value pair of the seal vector to enhance detection of alteration of data within the vectorset without a valid instance of the data transaction; initiating a new data transaction from a first data processing system to update the value of the first attribute-value pair of the first vector; extracting a plurality of seal hashes from the vectorset, the plurality of seal hashes comprising the first hash value from the first vector and the second hash value from the seal vector; transmitting the plurality of seal hashes to a second processing system; recalculating and storing within the vectorset the first hash value of the first vector to result in an updated first vector hash and recalculating the second hash value of the seal vector to result in an updated second hash value; transmitting the vectorset to the second processing system; recalculating the plurality of seal hashes to result in updated seal hashes; comparing the plurality of updated seal hashes to the plurality of seal hashes; and determining that the first data processing system executed within a processing authority associated with the first data processing system, through determination that only the first seal hash and the second seal hash were updated within the plurality of updated seal hashes to implicate sole update of the first-attribute-value pair of the first vector.

17. The method of claim 14, further comprising: selecting a first data compartment of the vectorset comprising an attribute-value pair of the first data compartment; determining a first seal pair comprising the first data compartment and a second data compartment comprising an attribute-value pair of the second data compartment; determining a second seal pair comprising the first data compartment and a third data compartment comprising an attribute-value pair of the third data compartment; wherein the first seal pair comprises a data structure adjacency of the first data compartment to the second data compartment and the second seal pair comprises a data structure adjacency of the first data compartment to the third data compartment; extracting a value of the first data compartment and a value of the second data compartment; inputting the value of the first data compartment and the value of the second data compartment into the hash function to generate a third hash value representing the first seal pair; extracting the value of the first data compartment and a value of the third data compartment;inputting the value of the first data compartment and the value of the third data compartment into the hash function to generate a fourth hash value representing the second seal pair; storing the third hash value and the fourth hash value in association with the vectorset, to enable detection of unauthorized alteration in the value of the first data compartment.

18. The method of claim 17, further comprising: wherein the first set of inputs that are input into the hash function further comprise a previous instance of the first seal hash from a previous state of the vectorset, referred to as an NthA instance of the vectorset, to cryptographically tie the Nih- \ instance to a present instance of the vectorset, referred to as an Nth instance of the vectorset, and wherein the first set of inputs that are input into the hash function further comprise at least one value of an attribute-value pair of a different vector of the vectorset that differs from the first vector, to establish a seal cross-dependency between at least two or more vectors of the vectorset.

19. The method of claim 18, wherein at least one of (i) each vector of the vectorset comprising an instance of a seal hash of each vector and (ii) each data compartment of each vector of the vectorset comprising a seal grouping of each data compartment of each vector of the vectorset, the method further comprising: extracting a plurality of hash values that comprise at least one of (i) the seal hash of each vector and (ii) the seal grouping of each data compartment of each vector of the Nth instance of the vectorset; generating a secret value; storing the secret value on a computing memory of a first device on which the vectorset is stored; inputting the plurality of hash values and the secret value into the hash function to generate a vectorset hash representing a static state of the Nth instance of the vectorset; receiving the vectorset hash on a second device over a network as a static state verification hash; initiating a location change of the vectorset from the computing memory of the first device to a computing memory of a third device; receiving the vectorset and the secret value at the second device; recalculating the vectorset hash of the vectorset received on the second device as a recalculated vectorset hash; comparing the static state verification hash and the recalculated vectorset hash; determining a match between the state verification hash and the recalculated vectorset hash to prove both (i) the static state of the vectorset was maintained and (ii) the vectorset was uniquely maintained in the first device; and authorizing transfer of the vectorset from the first device to the third device.

20. A method of an evolving vectorset, the method comprising:initiating a location change of a vectorset from a computing memory of a first device to a computing memory of a second device, wherein the vectorset comprising: n vectors, each vector of the vectorset comprising two or more data compartments, each data compartment of the two or more data compartments comprising an attribute-value pair, a vectorset identifier stored in at least one data compartment of the vectorset, such that the vectorset may be uniquely addressed, a state vector usable to store data associated with at least one of a current location and a current status of at least one of a physical positioning and a logical positioning of the vectorset, referred to as an sA vector, the sA vector comprising a state data stored in one or more data compartments of the sA vector, and a plurality of seal hashes the comprise at least one of (i) a seal hash of one or more vectors of the vectorset (ii) a seal grouping for one or more data compartments of the vectorset; generating a data operation comprising at least one of a write operation, a delete operation, and an update operation, on a first attribute-value pair of the sA vector; extracting a first set of inputs from the sA vector, the first set of inputs comprising a value of the first attribute- value pair of the sA vector and optionally a value of each of one or more other attribute- value pairs of the sA vector; inputting the first set of inputs into a hash function; outputting a first hash value as a location state seal, wherein the plurality of seal hashes comprises a first seal hash; storing the location state seal in a second attribute-value pair of at least one of a first vector and the sA vector to evolve a state of the sA vector and to enable detection of an unauthorized change in location of the vectorset.

21. The method of claim 20, further comprising: transmitting the location state seal to a third computing device and storing the location state seal on the third computing device; receiving the vectorset on the third device from the first device; and authenticating the first device from which the vectorset was received.

22. The method of claim 21, further comprising: determining a match between a device identifier of the first device and a device identifier stored in the sA vector;recalculating the location state seal as a recalculated location state hash; comparing the location state seal and the recalculated location state seal; and determining a match between the location state seal and the recalculated location state seal to prove the location of the vectorset was maintained in the first device.

23. The method of claim 22, further comprising: inputting a plurality of hash values comprising the first seal hash into the hash function to generate a vectorset hash representing a static state of the vectorset; receiving the vectorset hash on a second device over a network as a static state verification hash; and determining a match between the state verification hash and the recalculated vectorset hash to prove the static state of the vectorset was maintained after transfer to the first device.

24. The method of claim 22, wherein the hash inputs to the hash function further comprising a secret value, the method further comprising: receiving the vectorset and the secret value at a third device; recalculating a vectorset hash of the vectorset received on the third device as a recalculated vectorset hash; comparing the state verification hash and the recalculated vectorset hash; determining a match between the state verification hash and the recalculated vectorset hash to prove a static state of the vectorset was maintained in the first device; and authorizing transfer of the vectorset from the first device to the second device.

25. The method of claim 22, wherein the vectorset comprising: a cryptographic tie to a user profile, an authentication data usable to authenticate the user profile; and an encryption data comprising one or more encryption keys for communicating with one or more applications.

26. The method of claim 22, wherein the vectorset comprising: at least one of a sending device ID and a sending user ID, at least one of a receiving device ID and a receiving user ID, a seal hash incorporating as a hash input (i) the at least one of the sending device ID and the sending user ID, and (ii) at least one of the receiving device ID and the receiving user ID, at least one of a run sequence value, a run max value, and a run sequence value, anda seal hash incorporating as an additional hash input at least one of a run sequence value, a run max value, and a run sequence value.

27. The method of claim 22, wherein the state data comprising a location state seal that is the output of the hash function with the hash inputs further comprising a state seal and a location identifier of a current storage location, and wherein the state data optionally comprises a storage device identifier, a location description, and an owner identifier.

Images