Authentication of a user and/or a device through parallel synchronous update of immutable hash histories

CLAIMS OF PRIORITY AND CROSS REFERENCES TO RELATED APPLICATIONS

This patent application claims priority from, and hereby incorporates by reference: U.S. provisional patent application No. 62/203,647, titled ‘AUTHENTICATION OF A USER AND/OR A DEVICE THROUGH PARALLEL SYNCHRONOUS UPDATE OF IMMUTABLE HASH HISTORIES’, filed Aug. 11, 2016.

This patent application is a continuation-in-part, claims priority from, and hereby incorporates by reference: U.S. utility patent application Ser. No. 14/754,514, titled ‘SEMANTIC DATA STRUCTURE AND METHOD’ filed on Jun. 29, 2015, which claims priority to U.S. Provisional patent application No. 62/019,363, titled ‘DATABASE SECURITY AND ACCESS CONTROL THROUGH A SEMANTIC DATA MODEL’ filed on Jun. 30, 2014.

FIELD OF TECHNOLOGY

This disclosure relates generally to data processing devices and, more particularly, to a method, a device, a system of authentication of a user and/or a device through parallel synchronous update of immutable hash histories.

BACKGROUND

A datastore may be a repository for storing, managing, and distributing electronic data, and may store any of the data resources produced and/or utilized by an individual and/or an organization. Data resources may include any electronic data such as files, documents, media like music and video, records (e.g., electronic medical records), transaction data (e.g., financial transaction records), sensor data, and/or user profiles, and/or a portion of data thereof. The datastore may also include protected resources that are proprietary, confidential, and/or private data. A security system may require a user to be authenticated before the user can access the datastore and/or authorized before the user can utilize one or more of the protected resources (e.g., use the protected resource on a device and/or manage the protected resource on a server). An authentication process may be used by the security system to verify that the user is who they purport to be (e.g., validate an identity of the user and/or a device of the user). An authorization process may be used to determine whether the user is privileged to utilize the protected resource (e.g., watch a video file, access a corporate document, view personal information of a user profile).

The security system may require the user to provide one or more identity credentials at the time of an authentication process, each identity credential based on an authentication factor. There may be three common authentication factors: what the user “knows” (e.g., a password); what the user “has” (e.g., a device such as a fob); and what the user “is” (e.g., a biometric such as a fingerprint). In general, the greater the number of authentication factors used in the authentication process, the greater the certainty that the user is who they purport to be. For example, two-factor authentication employing both a password and a physical object may generally lead to greater security of the datastore than just a password.

However, use of a greater number of authentication factors may also decrease convenience in utilizing data resources of the datastore, and/or make using application programs that may utilize the datastore more confusing or even frustrating. This inconvenience, or “user friction,” may discourage the user from using the application program when it takes too long to log in or when the user cannot communicate one or more of the identity credential, for example due to a forgotten password. In an enterprise environment, user friction during the authentication process may also cause the user to try to operate outside enterprise security procedures. For example, the user might store protected resources on a local hard disk of the user's computer when enterprise policy requires the protected resources remain centrally administered.

Identity credentials such as passwords may also be easy to “social engineer” or hack. In a social engineering attack the user discloses the password to a seemingly well-intentioned person that is a hacker, for example by disclosing the password to an phony IT professional or typing it into a fake login screen of misleading website. Similarly, for convenience, users may choose passwords that are easy for hackers to crack or guess through the use of password libraries, or use the same password across multiple user profiles. Once obtained, the password may give the hacker access to the datastore for long periods without detection. Biometrics may provide additional certainty of the user's identity but may in some cases require expensive equipment. They may also be compromised, for example where a thumbprints of a person are stored in an electronic datastore and can be reproduced physically or digitally to fool the security system.

The user may be authenticated for a period of time or for a set amount of interaction with the datastore, for example to increase convenience to the user and/or to reduce computing overhead of the security system. In some cases, the user may be authenticated at the beginning of a session of interaction with the datastore. The user may be provided with a session token that the security system may check when the user requests one or more protected resources. However, the session token may remain relatively static and constantly transmitted over a primary channel of a network. A hacker may be able to fake the session token and/or relatively easily capture authentication credentials, allowing the hacker to covertly access the datastore, steal information, and/or destroy protected resources.

Once the user is authenticated, the security system may authorize a user when the user requests a given piece of data such as the protected resource from the datastore. For example, an access control list (ACL) may traditionally determine that the user is associated with the permission to access a particular file, and a computer may then copy and distribute the file to the user. However, it may be difficult to build systems that significantly distinguish the authentication process from the authorization process. For example, the security system may define security groups into which a set of data resources are placed and several users are associated (e.g., an admin group, a business development group). As a result, the user may be over-permissioned by having access to data resources that are unnecessary for the user's purpose, increasing risk to an organization that owns the datastore if that user acts against the organization's interest or loses his or her identity credentials. At the same time, the user may face an inconvenience (and/or the organization may suffer inefficiencies) when the user is under-permissioned, e.g., when requesting the protected resource from a different group for which the user is not generally permissioned.

As a result, current authentication processes may require a tradeoff between convenience (e.g., a fewer number of authentication factors) and stronger authentication (e.g., a greater number of authentication factors). Some identity credentials may be relatively easy to social engineer, may persist for longer than necessary due to system architecture, and/or may be difficult or expensive to implement (e.g., iris scanning). The authentication process and the authorization process may be relatively difficult to separate without increasing computing overhead and complexity, leading to protected resources that lack an appropriate scope of control within an organization. Therefore, the risk that the datastore will be subject to unauthorized access and protected data to unauthorized utilization, theft or damage may be increased. Once compromised, the datastore and/or the data of the datastore may lead to irreparable harm, for example when sensitive medical records, personal payment details or valuable trade secrets are stolen by hackers.

SUMMARY

Disclosed are a method, a device, and/or a system of authentication of a user and/or a device through parallel synchronous update of immutable hash histories. A computer-implemented method for authentication includes receiving an authentication request from a first device and an identity claim from the first device and/or a second device associated with the first device. The identity claim includes a device root hash computed by a hash function using inputs that include a previous transaction record along with a penultimate hash value of a hash history of the device. The hash history of the device referred to as a device hastory.

The method also retrieves data of a user profile associated with the first device and/or a user of the first device. The user profile includes a hash history of the profile, referred to as a profile hastory. The profile hastory includes a profile root hash computed by the hash function using inputs that include the previous transaction record along with a penultimate hash value of the profile hastory. The profile hastory includes a set of blocks in a sequential chain, with each block of the set of blocks including a transaction record of a set of previous transactions in which the first device and/or the user participated. The device hastory and the profile hastory may be stored as a Merkle tree, a hash chain, and/or a hash list.

The method extracts the profile root hash from the user profile associated with the first device and/or the user of the first device, and then compares the device root hash of the device hastory with the profile root hash of the profile hastory. The comparison verifies an identity the first device and/or the user of the first device when it is determined that the device root hash and the profile root hash are identical. The method then validates the identity of the device and/or the user of the device.

The method may also include assembling a transaction record of the identity claim generated by at least one of the first device and a second device associated with the first device. Additionally, the transaction record of the identity claim may be deposited in a new block of the sequential chain of the profile hastory. The method may compute a new profile root hash with the hash function using inputs including the profile root hash and the transaction record of the identity claim. As a result, the identity of the user profile evolves.

The method may also include receiving a first portion of data usable to assemble the transaction record of the identity claim over a first channel, along with a second portion of data usable to assemble the transaction record of the identity claim over a second channel. A verification of an identity update of the user profile may be transmitted to the first device and/or the second device. Similarly, a verification of an identity update of the first device and/or the second device may be received. The new profile root hash of the profile hastory may then be committed to synchronize the identity of the user profile with the identity of the first device and/or the second device. However, the method may also determine that the device root hash of the second authentication request and the new profile root hash of the user profile are not identical. In such case, the authentication request may be denied and the user profile may be locked to deny a prospective authentication request by the device and/or the user of the device.

In another embodiment, a computer-implemented method for authenticating a user in association with an authorization request includes receiving an authorization request from a device to utilize a protected resource stored in a datastore of a server along with an identity claim from the first device and/or a second device associated with the first device. The identity claim includes a device root hash computed by a hash function dependent on a dataset that includes one or more transaction records of previous identity claims. Data of a user profile associated with the first device and/or a user of the first device is retrieved. The user profile includes a hash history of the profile, referred to as a profile hastory, and the profile hastory includes a set of blocks in a sequential chain. The set of blocks have one or more transaction records of previous identity claims.

The profile root hash is extracted from the user profile that is associated with the first device and/or the user of the first device. The method then compares the device root hash with the profile root hash of the profile hastory to verify an identity the first device and/or the user of the first device. It is determined that the device root hash and the profile root hash are identical. The method may then evaluate one or more permissions of the protected resource in relation to the user profile authorizing utilization of the protected resource.

In yet another embodiment, a system includes a datastore server, a network, a mediation server, a profile server, and a first device. The datastore server stores a protected resource and transmits the protected resource to the first device upon authentication of the first device and/or a user of the first device. The mediation server receives an authentication request from the first device to access the datastore and/or an authorization request from the first device to utilize the protected resource, and additionally acts to receive an identity claim from the device that includes a device root hash.

The profile server transmits data of a user profile that is associated with the device and/or the user of the device. The user profile includes a hash history of the profile, referred to as a profile hastory, and the profile hastory includes a profile root hash computed by the hash function. The hash function uses inputs that include a previous transaction record along with a penultimate hash value of the profile hastory. The profile hastory also includes set of blocks in a sequential chain, each block of the set of blocks including a transaction record of a set of previous transactions in which the first device and/or the user participated. The system also includes the first device. The first device transmit the identity claim that includes the device root hash. The device root hash is the hash value computed by a hash function with inputs that include a previous transaction record along with a penultimate hash value of a hash history of the device, the hash history of the device referred to as a device hastory.

The system may also include a second device, to receive an identity update notice to re-calculate the device root hash. The result synchronizes the identity of the device and the identity of the user profile. The identity update notice may be transmitted over an encrypted channel out-of-band from a primary channel used to transmit the protected resource. The mediation server may extract the profile root hash from the user profile that is associated with the first device and/or the user of the first device, and then compare the device root hash of the device hastory with the profile root hash of the profile hastory. The mediation server may then verify an identity of the first device and/or the user of the first device when it is determined that the device root hash and the profile root hash are identical.

The system may additionally have a record runtime environment. The record runtime environment may receive and assemble an identity claim record generated by the first device, and deposit the identity claim record in a new block of the sequential chain of the profile hastory. The profile server may then compute the profile root hash of the profile hastory with the new block resulting in evolution of the identity of the user profile. The profile server may transmit a server update verification to the first device to instruct the first device to commit the device root hash and to synchronize the identity of the first device and the identity of the user profile. The first device can also transmit a device update verification to the profile server to instruct the profile server to commit the profile root hash and to synchronize the identity of the first device and the identity of the user profile. The result may be a parallel synchronization of the identity of the user profile and the identity of the first device.

BRIEF DESCRIPTION OF THE DRAWINGS

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:

<figref idref="DRAWINGS">FIG. 1.1</figref> is a data resource control network that carries out transactions between and/or among data resources within a datastore, controls replication of data resources to maintain data uniqueness, controls ownership transfer of the data resources, authenticates a device requesting access to the datastore, authorizes utilization of a particular data resource, and/or controls use of data resources through a use policy and a terms engine, according to one or more embodiments.

<figref idref="DRAWINGS">FIG. 1.2</figref> is an instantiation of the data resource control network of <figref idref="DRAWINGS">FIG. 1.1</figref> illustrating a set of servers providing micro services to the data resource control network, including a datamode microservice for storing data resources, a usermode microservice comprising a user datastore for storing user profiles, and an objectmode microservice for storing relationships between and among the data resources, according to one or more embodiments.

<figref idref="DRAWINGS">FIG. 2.1</figref> is an instance of a data resource, having a controlled identity within the datastore, referred to as a data organism, the data organism comprising an identifier, a hastory that is an immutable record of previous transactions in which the data organism participated forming an evolving identity of the data organism, a contained data that the data organism contains, and a set of computing processes that may be executed by the data resource control network of <figref idref="DRAWINGS">FIG. 1.1</figref> when the data organism is called and/or addressed, according to one or more embodiments.

<figref idref="DRAWINGS">FIG. 2.2</figref> is a data organism transaction view illustrating a first data organism transacting with a second data organism, the transaction conducted by a transaction engine of a mediation server and a transaction record deposited in each of the hastories of the first data organism and the second data organism through a record runtime environment, according to one or more embodiments.

<figref idref="DRAWINGS">FIG. 2.3</figref> is a hastory view illustrating the hastory of <figref idref="DRAWINGS">FIG. 2.2</figref> including a sequential chain of blocks implemented as a hash chain, each block including a transaction record and a hash value, the hash value generated based upon the transaction record of the block and a penultimate hash value of a previous block, a root hash unique within the datastore for a given data within each of the blocks and a given block order of the sequential chain, according to one or more embodiments.

<figref idref="DRAWINGS">FIG. 2.4</figref> is a second hastory view illustrating the hastory of <figref idref="DRAWINGS">FIG. 2.2</figref> implemented as a Merkle tree, a binary tree of a set of leaf nodes extended from the sequential chain of blocks to a root node that includes a root hash that is unique within the datastore, according to one or more embodiments.

<figref idref="DRAWINGS">FIG. 2.5</figref> is a data organism identity evolution view showing the data organism of <figref idref="DRAWINGS">FIG. 2.1</figref> copied to form an original data organism and a copied data organism that remains unique within the datastore as each engages in different transactions that are added to each of the hastories to result in different root hashes, according to one or more embodiments.

<figref idref="DRAWINGS">FIG. 2.6</figref> is a transaction process flow illustrating a process by which two of the data organisms of <figref idref="DRAWINGS">FIG. 2.2</figref> engage in a transaction to result in one or more evolved identities, according to one or more embodiments.

<figref idref="DRAWINGS">FIG. 2.7</figref> is a second transaction process flow illustrating a detailed process by which one or more data resources and/or data organisms transact such that data organisms having controlled identities of the transacting data organisms remain unique within the datastore, according to one or more embodiments.

<figref idref="DRAWINGS">FIG. 2.8</figref> is a controlled copying process flow illustrating a process by which the copying transaction shown in <figref idref="DRAWINGS">FIG. 2.5</figref> may be controlled within the datastore such that the original data organism and the copied data organism remain unique, according to one or more embodiments.

<figref idref="DRAWINGS">FIG. 2.9</figref> is a data organism transfer process flow showing a process by which the data organism of <figref idref="DRAWINGS">FIG. 2.1</figref> may have an ownership transferred between a first user and a second user by changing an ownership designation and depositing a record of the transaction in a block of the hastory, according to one or more embodiments.

<figref idref="DRAWINGS">FIG. 2.10</figref> is a second data organism transfer process flow illustrating a second process by which the ownership of the data organism may be transferred by copying the data organism, and: flagging an original of the data organism as extinct; depositing an ownership transfer as a termination block of the hastory of the original data organism; and/or, erasing the original data organism from the datastore, according to one or more embodiments.

<figref idref="DRAWINGS">FIG. 2.11</figref> is a media use transaction view illustrating a video data stored in a media file that is a first data organism, the media file an application resource for a second data organism that is an application profile and the media file accessed by a user associated with a user profile that is a third data organism, according to one or more embodiments.

<figref idref="DRAWINGS">FIG. 3.1</figref> is an authentication transaction network in which the device of <figref idref="DRAWINGS">FIG. 1.1</figref> completes a multi-factor login that may establish a secure communication channel over the network and submits an identity claim comprising a device root hash of a device hastory to a server for comparison to a profile root hash of a profile hastory to validate the identity claim, according to one or more embodiments.

<figref idref="DRAWINGS">FIG. 3.2</figref> is a multi-factor login process flow of the multi-factor login of <figref idref="DRAWINGS">FIG. 3.1</figref>, according to one or more embodiments.

<figref idref="DRAWINGS">FIG. 3.3</figref> is the multi-factor login process of <figref idref="DRAWINGS">FIG. 3.2</figref> continued, according to one or more embodiments.

<figref idref="DRAWINGS">FIG. 3.4</figref> is an authentication process flow illustrating a process by which the device of <figref idref="DRAWINGS">FIG. 3.1</figref> may be securely authenticated using un-forgeable identity credentials that define a fourth authentication factor based on a transaction history of the device and the user profile associated with the device, according to one or more embodiments.

<figref idref="DRAWINGS">FIG. 3.5</figref> is an identity evolution process flow that illustrates a process for evolving both the profile hastory and the device hastory in parallel to synchronize their identities for comparison in a subsequent authentication request, according to one or more embodiments.

<figref idref="DRAWINGS">FIG. 3.6</figref> is a profile hastory and device hastory view illustrating a detailed view of the sequential chain of blocks of the profile hastory with transactions records such as a profile data and several identity claim records associated with transaction such as a login transaction, a data use transaction and a log out transaction, according to one or more embodiments.

<figref idref="DRAWINGS">FIG. 3.7</figref> is an real-time authentication process flow illustrating a process by which the device of <figref idref="DRAWINGS">FIG. 3.1</figref> can submit to just-in-time authentication in association with an authorization request to utilize a data resource of the datastore of <figref idref="DRAWINGS">FIG. 1.1</figref>, according to one or more embodiments.

<figref idref="DRAWINGS">FIG. 3.8</figref> is an application identity evolution process flow showing a process whereby an identity claim may be made by the device and/or the user profile against an application profile of an application program, according to one or more embodiments.

<figref idref="DRAWINGS">FIG. 3.9</figref> is a profile attack detection process flow showing a process that invalidates forged identify credentials if the identity credentials are copied from the device based on the evolution of the device hastory and the profile hastory, according to one or more embodiments.

<figref idref="DRAWINGS">FIG. 3.10</figref> is a forged credential detection view showing a failed identity claim by an impersonator who cloned credentials from a device of user, the failed identity claim identifier and optionally responded to by the process of <figref idref="DRAWINGS">FIG. 3.9</figref>, according to one or more embodiments.

<figref idref="DRAWINGS">FIG. 4.1</figref> is an authorization network showing a set of servers usable to authorize use of a protected resource by a device and control use of the protected resource on the device using a terms engine according to a use policy, according to one or more embodiments.

<figref idref="DRAWINGS">FIG. 4.2</figref> is a contextual authorization process showing the authorization network of <figref idref="DRAWINGS">FIG. 4.1</figref> receiving a use request from the device, processing an identity claim, retrieving a use policy that evaluates one or more contextual values, depositing a use key in a key server, and returning a use key to the device, according to one or more embodiments.

<figref idref="DRAWINGS">FIG. 4.3</figref> is a controlled data delivery process showing the contextual authorization network of <figref idref="DRAWINGS">FIG. 4.2</figref> receiving a redemption request comprising the use key, verifying the use key in the key server, and streaming data of the protected resource to the device, according to one or more embodiments.

<figref idref="DRAWINGS">FIG. 4.4</figref> is a terms engine view showing the contextual authorization network of <figref idref="DRAWINGS">FIG. 4.3</figref> monitoring use of and enforcing ephemerality of data of the protected resource of <figref idref="DRAWINGS">FIG. 4.1</figref> through a device-side terms engine associated through the network with a server-side terms engine, according to one or more embodiments.

<figref idref="DRAWINGS">FIG. 4.5</figref> is a real-time revocable authorization process by which data of the protected resource in active use by the device may have use terminated based on an updated use policy generated by a second user in control of the protected resource, a termination notice and/or a termination report generated by the device and transmitted to the mediation server to close the use transaction, according to one or more embodiments.

<figref idref="DRAWINGS">FIG. 4.6</figref> is a use key generation process flow illustrating a process by which the contextual values of the use policy may be evaluated and the use key of <figref idref="DRAWINGS">FIG. 4.2</figref> may be generated, according to one or more embodiments.

<figref idref="DRAWINGS">FIG. 4.7</figref> is a continued process flow of the use key generation process flow of <figref idref="DRAWINGS">FIG. 4.6</figref>, illustrating a process by which the contextual values of the use policy may be evaluated and the use key of <figref idref="DRAWINGS">FIG. 4.2</figref> may be generated, according to one or more embodiments.

<figref idref="DRAWINGS">FIG. 4.8</figref> is a use request evaluation process flow showing a process for authorizing use of a protected resource according to a set of computer-readable instructions of a use policy, according to one or more embodiments.

<figref idref="DRAWINGS">FIG. 4.9</figref> is a key generation and redemption process flow showing, subsequent to evaluation of the contextual values of the use policy of <figref idref="DRAWINGS">FIG. 4.1</figref>, a process by which the use keys may be generated, returned to the device, and redeemed upon a redemption request by the device, according to one or more embodiments.

<figref idref="DRAWINGS">FIG. 4.10</figref> device active data use process flow showing a process that can be used to monitor use of the protected resource by the device and/or enforce ephemerality of the protected resource on the device in accordance with the use policy and a set of use terms generated based on the use policy, according to one or more embodiments.

<figref idref="DRAWINGS">FIG. 4.11</figref> is a use termination process flow illustrating a process by which an open transaction record of the active use of the protected resource is closed when the protected resource is determined to no longer be in active use, a network connection to the device was lost, and/or the device performed an action outside of the use terms, according to one or more embodiments.

<figref idref="DRAWINGS">FIG. 4.12</figref> is an enterprise use policy view illustrating use of the use policy to define an authorized context for limited access and use of a protected resource that is a confidential spreadsheet, the authorized context including flexible controls such as a requirement that an executive of the enterprise be within a geospatial fence of the premises for an employee to view the confidential spreadsheet, according to one or more embodiments.

Other features of the present embodiments will be apparent from the accompanying drawings and from the detailed description that follows.

DETAILED DESCRIPTION

Disclosed are a method, a device, a system and/or a manufacture of authentication of a user and/or a device through parallel synchronous update of immutable hash histories. 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.

<figref idref="DRAWINGS">FIG. 1.1</figref> is a data resource control network <b>1</b>.<b>100</b> that carries out transactions between and/or among data resources within a datastore <b>1</b>.<b>114</b>, controls replication of data resources to maintain data uniqueness, controls ownership transfer of the data resources, authenticates a device <b>1</b>.<b>104</b>A requesting access to the datastore, authorizes utilization of a particular data resource, and/or controls use of data resources through a use policy and a terms engine <b>1</b>.<b>112</b>, according to one or more embodiments. Specifically, <figref idref="DRAWINGS">FIG. 1.1</figref> shows a network <b>1</b>.<b>101</b>, a mediation server <b>1</b>.<b>102</b>, two devices <b>1</b>.<b>104</b>A and <b>1</b>.<b>04</b>B, a set of servers <b>1</b>.<b>106</b>A through <b>1</b>.<b>106</b>N (each of which may include a datastore <b>1</b>.<b>114</b>A through <b>1</b>.<b>114</b>N and a record runtime environment <b>1</b>.<b>116</b>A through <b>1</b>.<b>116</b>N, respectively), a key server <b>1</b>.<b>108</b>, a transaction engine <b>1</b>.<b>110</b>, and a terms engine <b>1</b>.<b>112</b> having a terms engine server-side <b>1</b>.<b>112</b>A along with a terms engine device-side <b>1</b>.<b>112</b>B communicatively coupled through the network <b>1</b>.<b>101</b>.

The mediation server <b>1</b>.<b>102</b> may receive a communication from the device <b>1</b>.<b>104</b>A over the network <b>1</b>.<b>101</b> to utilize a data resource stored in one or more of the datastores <b>1</b>.<b>114</b>A through <b>1</b>.<b>114</b>N. Utilization may be, for example, using the data resource on the device <b>1</b>.<b>104</b>A and/or managing the data resource within one or more of the datastores <b>1</b>.<b>114</b> (e.g., copy, delete, update). The device <b>1</b>.<b>104</b>A and/or the device <b>1</b>.<b>104</b>B may be a smartphone, a tablet, a desktop computer, or a different server. The device <b>1</b>.<b>104</b>A and/or the device <b>1</b>.<b>104</b>B may also be a piece of machinery like a CNC mill or a 3D printer, a vehicle such as an automobile having an onboard computer and networking capability, a piece of networking equipment such as a router, and/or an unmanned autonomous vehicle. The network <b>1</b>.<b>101</b> may be a network connecting two or more computers such as a wide area network (WAN) or the internet.

A data resource is a discrete piece of data, or portion thereof, that is usable as a resource for an application program. For example a data resource may include a file, a document, a record, a message, an image, statistical and scientific data, and/or media such as music or video. In a specific example, a data resource may include a user profile that includes a set of attributes and values associated holding information about a particular person. Similarly, a portion of the user profile such as a single attribute-value pair specifying a social security number of the person may also be a data resource. In another example, a data resource may include an audio file (e.g., an MP3 file, an AAC file), and/or a portion of that audio file, for example a 30 second long section streamed to a device for use. Where the data resource is protected by a security system, for example that may require authentication and/or authorization before utilization, the data resource may be referred to as the protected resource. The data resource may also be a cryptographic key of a cryptographic currency, for example a Bitcoin private key.

In addition, where the data resource has a controlled identity within one of the datastores <b>1</b>.<b>114</b>, the data resource may be containerized into a particular data structure and associated with a hash history, referred to as a hastory <b>2</b>.<b>104</b>, as shown in <figref idref="DRAWINGS">FIG. 2.1</figref>. The data resource having the hastory <b>2</b>.<b>104</b> may also be referred to as a data organism <b>2</b>.<b>100</b> due to an evolving identity based on an immutable record of previous transactions in which a particular data organism <b>2</b>.<b>100</b> participated. The identity of a data organism <b>2</b>.<b>100</b> may evolve based upon transaction records (e.g., the transaction record <b>2</b>.<b>302</b> of <figref idref="DRAWINGS">FIG. 2.2</figref>) added to the hastory of the data organism <b>2</b>.<b>100</b> by the record runtime environment <b>1</b>.<b>116</b> associated with a particular server <b>1</b>.<b>106</b> on which the particular data organism <b>2</b>.<b>100</b> is stored.

The data resource control network <b>1</b>.<b>100</b> may act as a data privatization network. One or more embodiments that comprise the network <b>1</b>.<b>100</b>, working along or in combination, may be able to track data resources and ensure their uniqueness, authenticate users requesting access to one or more of the datastores <b>1</b>.<b>114</b>, authorization access and use requests of the data resources in addition to control use of the data resources (in contrast to mere access to data resources without continuing use control). The data resource control network <b>1</b>.<b>100</b> may be used by an enterprise such as a corporation, one or more government agencies, or may be used as a platform for application programs to provide services to consumers (e.g., secure messaging and file transfer). The users may be, for example, enterprise executives, employees, healthcare professionals, consumers, attorneys and their clients, a government employee, a datastore administrators, etc. First, the device <b>1</b>.<b>104</b>A may request a transaction between one or more of the data resources, for example as a normal operation of an application program calling on data resources to populate a user interface of the device <b>1</b>.<b>104</b>A. The mediation server <b>1</b>.<b>102</b> transacts in one or more of the data resources and/or data organisms using the transaction engine <b>1</b>.<b>110</b>, as shown in conjunction with <figref idref="DRAWINGS">FIG. 2.1</figref> through <figref idref="DRAWINGS">FIG. 2.11</figref>. A transaction (e.g., the transaction <b>2</b>.<b>200</b> of <figref idref="DRAWINGS">FIG. 2.2</figref>) may include, for example, an instance of an interaction between two data resources (e.g., an interaction between a user profile and document when a user associated the user profile views the document, as shown and described in <figref idref="DRAWINGS">FIG. 2.11</figref>). The transaction may also be an interaction such as a controlled copying transaction in which an original data organism and a copy of the data organism are maintained as unique within the datastore (as shown and described in <figref idref="DRAWINGS">FIG. 2.5</figref>). Another example of a transaction includes an ownership transfer in which the original data organism <b>2</b>.<b>100</b> may have ownership transferred between a first user and a second user (as shown and described in conjunction with <figref idref="DRAWINGS">FIG. 2.9</figref> and <figref idref="DRAWINGS">FIG. 2.10</figref>).

The mediation server <b>1</b>.<b>102</b> may also coordinate secure login of the device <b>1</b>.<b>104</b>A to one or more servers, and may orchestrate authentication of the device <b>1</b>.<b>104</b>A as shown and described in conjunction with <figref idref="DRAWINGS">FIG. 3.1</figref> through <figref idref="DRAWINGS">FIG. 3.10</figref>. The authentication process may also include real-time authentication in association with the authorization of the device <b>1</b>.<b>104</b>A to utilize a particular date resource (e.g., in conjunction with a use transaction as shown in <figref idref="DRAWINGS">FIG. 4.1</figref>). The authentication process verifies an identity claim made by the device <b>1</b>.<b>104</b>A by utilizing the evolving nature of an identity of the user profile that is associated with a user and/or the device <b>1</b>.<b>104</b>A (such as the user profile <b>3</b>.<b>106</b> of <figref idref="DRAWINGS">FIG. 3</figref>). The identity claim may include one or more identity credentials, including a root hash of a device hastory. Verifying the identity claim by comparing the root hash of the device hastory to the root hash of the profile hastory may result in virtually un-forgeable identity credentials, greatly increasing security of the datastore <b>1</b>.<b>114</b> and control over the data resources. The authentication process may utilize a second device, the device <b>1</b>.<b>104</b>B, for example to store the device hastory and/or identity credentials to be communicated in the identify claim over a channel that is distinct from the channel over which use of the data resource was requested.

The mediation server <b>1</b>.<b>102</b> may also operate the terms engine <b>1</b>.<b>112</b> to control access to, and use of, a data resource (referred to as a protected resource <b>4</b>.<b>102</b>) by the device <b>1</b>.<b>104</b> through a use transaction and a use policy <b>4</b>.<b>108</b>, as shown and described in conjunction with <figref idref="DRAWINGS">FIG. 4.1 through 4.12</figref>. The use policy <b>4</b>.<b>108</b> may evaluate one or more contextual values defined in computer-readable instruction <b>4</b>.<b>204</b> to authorize access to and use of the data resource in conjunction with the key server <b>1</b>.<b>108</b>, as shown in <figref idref="DRAWINGS">FIG. 4.1</figref> and <figref idref="DRAWINGS">FIG. 4.9</figref>. The terms engine server-side <b>1</b>.<b>112</b>A may maintain an open transaction record <b>4</b>.<b>404</b> of a data resource and/or a data organism <b>2</b>.<b>100</b> that is in an active use by the device <b>1</b>.<b>104</b>A. The device <b>1</b>.<b>104</b>A may then use the terms engine device-side <b>1</b>.<b>112</b>B to monitor use of and enforce ephemerality of the data resource on the device <b>1</b>.<b>104</b>A according to a use terms (e.g., the use terms <b>4</b>.<b>116</b> of <figref idref="DRAWINGS">FIG. 4.1</figref>) generated from the use policy <b>4</b>.<b>108</b>. Upon termination of the use by the device <b>1</b>.<b>104</b>A, a termination report <b>4</b>.<b>508</b> logged by the mediation server <b>1</b>.<b>102</b> and the open transaction record may be closed. For example, the use of the protected resource <b>4</b>.<b>102</b> may be terminated when: the use falls outside the authorized context, the use of the protected resource <b>4</b>.<b>102</b> by the device is no longer active, a network connection is lost (e.g., through the network <b>1</b>.<b>101</b>), and/or a second user that may own the protected resource revokes authorization with a policy update <b>4</b>.<b>501</b>, as shown in <figref idref="DRAWINGS">FIG. 4.5</figref>.

The arbiter <b>1</b>.<b>900</b> may act as a temporary owner for any of the data resources and/or data organisms <b>2</b>.<b>100</b>. According to the computing processes defining the transaction (some of which may be specified in a particular data resource and/or data organism <b>2</b>.<b>100</b>, e.g., as the computing processes <b>2</b>.<b>110</b> of <figref idref="DRAWINGS">FIG. 2.1</figref>), ownership of the particular data resource and/or the particular data organism <b>2</b>.<b>100</b> may be temporarily given over to the arbiter <b>1</b>.<b>900</b>. The arbiter <b>1</b>.<b>900</b> may re-distribute the data organism <b>2</b>.<b>100</b> to one or more users according to the computing processes of the transaction. For example, the arbiter <b>1</b>.<b>900</b> may be used to effect an escrow, a wager, and/or another type of complex agreement and/or transaction in which events programmatically alter a state of the data resource and/or data organism, including the value of an attribute specifying an ownership designation <b>2</b>.<b>106</b>. The arbiter <b>1</b>.<b>900</b> may connect to one or more external services, not shown in the embodiment of <figref idref="DRAWINGS">FIG. 1.1</figref>, to retrieve inputs to determine an outcome in accordance with the use policy <b>4</b>.<b>108</b>.

Each of the servers of <figref idref="DRAWINGS">FIG. 1.1</figref> (e.g., the servers <b>1</b>.<b>106</b>A through <b>1</b>.<b>106</b>N, the mediation server <b>1</b>.<b>102</b>, the key server <b>1</b>.<b>108</b>) are computers that include computer processors, computer memories, and may additionally use storage such as a hard disk, a solid-state drive and/or other physical storage/memory mechanisms such as memristors. One or more of the servers may be implemented on shared physical hardware or each may run on a dedicated piece of physical hardware. Each of the individual datastores <b>1</b>.<b>114</b>A through <b>1</b>.<b>114</b>N may collectively act as a single datastore (e.g., referred to as the datastore <b>1</b>.<b>114</b>). For example, the datastore <b>1</b>.<b>114</b>A may store data resources and/or data organisms <b>2</b>.<b>100</b> related to users, datastore <b>1</b>.<b>114</b>B may store data resources and/or data organisms <b>2</b>.<b>100</b> related to files (e.g., a document, an electronic record), and datastore <b>1</b>.<b>114</b>N may store data resources and/or data organisms related to messages (e.g., an electronic message). Each of the networks <b>1</b>.<b>101</b> shown in the embodiment of <figref idref="DRAWINGS">FIG. 1.1</figref> may be similar or distinct. For example, the instance of the network <b>1</b>.<b>101</b> connecting the mediation server <b>1</b>.<b>102</b> to the device <b>1</b>.<b>104</b> may be the internet whereas an instance of the network <b>1</b>.<b>101</b> connecting each of the servers <b>1</b>.<b>106</b> to the mediation server <b>1</b>.<b>102</b> may be a local area network (LAN) and/or a wide area network (WAN).

The data resource stored in the datastore <b>1</b>.<b>114</b> may be a grouped collection of attributes and values within a data structure (which may be commonly referred to as a data object). The grouped attributes and values may comprise an identifier <b>2</b>.<b>102</b> whereby the data resource may be addressed in the datastore (e.g., a file name, a unique identifier, a global unique identifier) and a contained data (e.g., similar to the contained data <b>2</b>.<b>108</b> of <figref idref="DRAWINGS">FIG. 2.1</figref>) that the particular data resource contains. The contained data of the data resource, for example, may be one or more attributes containing data such as a binary large object (BLOB) of a primitive data such as a document, a music file (e.g., an MP3, an AAC file) and/or a video file. Other attributes may be referential attributes pointing to other data resources to specify relationships (e.g., containing relationships, directed acyclic relationships, and/or contextual relationships). Where the data resource includes protections such as an authorization process before it can be accessed and/or used, the data resource may be referred to as a protected resource. The data resource, the protected resource and/or the data organism <b>2</b>.<b>100</b> are further described in conjunction with <figref idref="DRAWINGS">FIG. 2.1</figref>.

The datastore <b>1</b>.<b>114</b> and/or each of the datastores <b>1</b>.<b>114</b>A through <b>1</b>.<b>114</b>N that comprise the datastore <b>1</b>.<b>114</b> may be implemented on a commercial database application supporting a collection of grouped attribute-value pairs forming the data resources and/or the data organisms <b>2</b>.<b>100</b> (e.g., a “NoSQL” database supporting a document store, such as MongoDB®). Additionally, a data structure supporting collections of attributes and values of the data resource may be built on top of the commercial database application. For example, a model supporting data resources may be built on top of a key value store such as Aerospike®, and/or a columner store such as Cassandra®. In one preferred embodiment, the relationships between the data resources and/or the data organisms are stored according to a non-hierarchical data structure that may be disclosed in co-pending patent applications by a similar inventive entity and/or common assignee as the present disclosure. In such case, the data resources and/or data organisms <b>2</b>.<b>100</b> may be stored as nodes in the non-hierarchical data structure, resulting in, for example, a graph data structure and/or a directed acyclic graph with one or more of the data resources including referential attributes pointing to other data resources.

Demonstrating an example of specialization of each of the datastores <b>1</b>.<b>114</b>A through <b>1</b>.<b>114</b>N that together comprise the datastore <b>1</b>.<b>114</b>, <figref idref="DRAWINGS">FIG. 1.2</figref> is an instantiation of the data resource control network of <figref idref="DRAWINGS">FIG. 1.1</figref> illustrating a set of servers providing micro services to the data resource control network <b>1</b>.<b>200</b>, including a datamode microservice <b>1</b>.<b>130</b> for storing data resources, a usermode microservice <b>1</b>.<b>140</b> comprising a user datastore <b>1</b>.<b>141</b> for storing user profiles, and an objectmode microservice <b>1</b>.<b>120</b> for storing relationships between and among the data resources, according to one or more embodiments. In accordance with co-pending patent applications by a similar inventive entity and/or a common assignee of the present disclosure, a subject datastore <b>1</b>.<b>131</b> of the datamode microserver <b>1</b>.<b>130</b> may store data resources and/or data organisms <b>2</b>.<b>100</b> that include a primitive data such as an image, document, music and/or video. A user datastore <b>1</b>.<b>141</b> may store data resources and/or data organisms <b>2</b>.<b>100</b> that are user profiles <b>4</b>.<b>404</b> associated a user of one or more of the datastores <b>1</b>.<b>114</b> of the data resource control network <b>1</b>.<b>200</b>. An object datastore <b>1</b>.<b>121</b> of the objectmode microserver may contain data resources and/or data organisms <b>2</b>.<b>100</b> representing relationships between other data resources and/or data organisms <b>2</b>.<b>100</b> (for example, between a video file and its an image representation as stored in the subject datastore <b>1</b>.<b>131</b>). In addition, the object datastore <b>1</b>.<b>121</b> may store control relationships such as the security node <b>4</b>.<b>110</b> of <figref idref="DRAWINGS">FIG. 4.1</figref>.

<figref idref="DRAWINGS">FIG. 2.1</figref> is an instance of a data resource, having a controlled identity within the datastore, referred to as a data organism <b>2</b>.<b>100</b>, according to one or more embodiments. The data organism <b>2</b>.<b>100</b> may include an identifier <b>2</b>.<b>102</b>, a hastory <b>2</b>.<b>104</b> that is an immutable record of previous transactions in which the data organism participated forming an evolving identity of the data organism <b>2</b>.<b>100</b>, a contained data <b>2</b>.<b>108</b> that the data organism contains, and a set of computing processes that may be executed by the data resource control network <b>2</b>.<b>100</b> of <figref idref="DRAWINGS">FIG. 1.1</figref> when the data organism <b>2</b>.<b>100</b> is called and/or addressed, according to one or more embodiments. The identifier <b>2</b>.<b>102</b> provides a means to address the data organism <b>2</b>.<b>100</b> within the datastore <b>1</b>.<b>114</b>, and is preferably a unique identifier (UID) and/or a globally unique identifier (GUID) generated through a random or pseudo-random number generator. This method of generation may ensure that there is a very low probability of two data resources having the same unique identifier within the datastore and/or across all datastores <b>1</b>.<b>114</b> on the network <b>1</b>.<b>101</b>.

The hastory <b>2</b>.<b>104</b> is a hash history of the data organism <b>2</b>.<b>100</b>. A sequential chain of blocks <b>2</b>.<b>300</b> forms an immutable record of transactions in which the data organism <b>2</b>.<b>100</b> participated. Each block <b>2</b>.<b>304</b> of the sequential chain of blocks <b>2</b>.<b>300</b> comprise a transaction record <b>2</b>.<b>302</b> of a transaction <b>2</b>.<b>200</b> in which the data organism <b>2</b>.<b>100</b> previously participated (‘T<b>1</b>’ may stand for a first transaction, ‘T<b>2</b>’ for a second transaction, etc.). In addition, each of the blocks <b>2</b>.<b>304</b> includes a unique hash value (e.g., the hash value <b>2</b>.<b>306</b> of <figref idref="DRAWINGS">FIG. 2.3</figref>) calculated with a hash function. The hash function may depend on both data of each of the blocks in addition to an order of each of the blocks such that any alternation of the data of any of the blocks or the block order in the sequential chain yields a different root hash of the hastory <b>2</b>.<b>104</b>. Thus, the set of transition stored in the sequential chain may be immutable. The most recent hash value <b>2</b>.<b>306</b> in the sequential chain of blocks <b>2</b>.<b>300</b> may be referred to as a root hash value <b>2</b>.<b>306</b>, and may be used as an identity of the particular data organism <b>2</b>.<b>100</b> and/or to generate identity claims. The hastory is further described in conjunction with <figref idref="DRAWINGS">FIG. 2.2 through 2.4</figref>.

The data organism <b>2</b>.<b>100</b> may include the ownership designation <b>2</b>.<b>106</b> attribute that may have as an associated value a name (e.g. of a user, an organization, a computer application) and/or a reference to a different data resource such as a user profile representing the user, the organization, and/or the application program. In other cases, the ownership of the data organism <b>2</b>.<b>100</b> may be implicit through reference from the user profile.

The contained data <b>2</b>.<b>108</b> may contain one or more attributes and associated values of data that the data organism <b>2</b>.<b>100</b> is meant to hold, contain and/or represent. For example, where the data organism <b>2</b>.<b>100</b> is a media file, the contained data <b>2</b>.<b>108</b> may contain a video data, images representing the video data, and/or metadata related to the video data. The data organism <b>2</b>.<b>100</b> may also contain computing processes <b>2</b>.<b>110</b> that may be executed (e.g., by the mediation server <b>1</b>.<b>102</b>) when the data organism <b>2</b>.<b>100</b> is called and/or addressed, for example by a different data organism <b>2</b>.<b>100</b>. The computing processes <b>2</b>.<b>110</b> may be used in part or in full to determine who the data organism <b>2</b>.<b>100</b> transacts. The computing processes <b>2</b>.<b>110</b> may contain the computer-readable instructions <b>4</b>.<b>204</b> that may also specify a use policy <b>4</b>.<b>108</b> that defines an authorized context for which access to and/or use of the data organism <b>2</b>.<b>100</b> is authorized by the device <b>1</b>.<b>104</b>A and/or a user of the device <b>1</b>.<b>104</b>A. The use policy <b>4</b>.<b>108</b> evaluates one or more contextual values to determine whether a use request satisfies the authorized context. For example, the contextual values may include which user is making the authorization request, a date and a time of the authorization request, a geospatial location of the device, a value called from another data organism <b>2</b>.<b>100</b>, and/or a value called from an API. Similarly, the computing processes <b>2</b>.<b>110</b> may include instructions executable by the arbiter <b>1</b>.<b>900</b> of <figref idref="DRAWINGS">FIG. 1.1</figref>. The computing processes <b>2</b>.<b>110</b> may be written in a Turing-complete scripting language that supports a read operation, a write operation (e.g., to data of the data organism <b>2</b>.<b>100</b> and/or a different data organism <b>2</b>.<b>100</b>), a go-to operation, and a conditional branching operation.

<figref idref="DRAWINGS">FIG. 2.2</figref> is a data organism transaction view <b>2</b>.<b>250</b> illustrating a first data organism <b>2</b>.<b>100</b>A transacting with a second data organism <b>2</b>.<b>100</b>B, the transaction conducted by a transaction engine <b>1</b>.<b>112</b> of a mediation server <b>1</b>.<b>102</b> and a transaction record <b>2</b>.<b>302</b> deposited in each of the hastories <b>2</b>.<b>104</b>A and <b>2</b>.<b>104</b>B of the first data organism <b>2</b>.<b>100</b>A and the second data organism <b>2</b>.<b>100</b>B through a record runtime environment <b>1</b>.<b>116</b>A and <b>1</b>.<b>116</b>B, according to one or more embodiments. In <figref idref="DRAWINGS">FIG. 2.2</figref>, the transaction <b>2</b>.<b>200</b> may be initiated when data organism <b>2</b>.<b>100</b>A receives a communication addressed from data organism <b>2</b>.<b>100</b>B. For example, the data organism <b>2</b>.<b>100</b>B may be a user profile (e.g., the user profile <b>3</b>.<b>114</b>) requesting access to an electronic record in the contained data <b>2</b>.<b>108</b>A of the data organism <b>2</b>.<b>100</b>A. In another example, the data organism <b>2</b>.<b>100</b>B may contain within the contained data <b>2</b>.<b>108</b> software code of an application program and an application profile associated with the application program may address the data organism <b>2</b>.<b>100</b>A to instruct data organism <b>2</b>.<b>100</b>A to automatically update the software code. Each server <b>1</b>.<b>106</b> may pass any required data to effect the transaction <b>2</b>.<b>200</b> to the transaction engine <b>1</b>.<b>112</b> of the mediation server <b>1</b>.<b>102</b>. The transaction engine <b>1</b>.<b>112</b> may be a set of machine-readable instructions that carries out the transaction <b>2</b>.<b>200</b> according procedures, including machine-readable instructions defined in the contained data <b>2</b>.<b>108</b> and/or the computing processes <b>2</b>.<b>212</b> of one or more data organisms <b>2</b>.<b>100</b>. Examples of the transaction <b>2</b>.<b>200</b> include a controlled copying of a data organism <b>2</b>.<b>100</b>, an ownership transfer the data organism <b>2</b>.<b>100</b>, and/or a use transaction of the data organism <b>2</b>.<b>100</b>. In each such example, a user profile that owns the data organism <b>2</b>.<b>100</b> may address the data organism <b>2</b>.<b>100</b> to initiation the controlled copying or ownership transfer transaction.

Upon completion of the transaction <b>2</b>.<b>200</b>, a transaction record <b>2</b>.<b>200</b> is generated by the transaction engine <b>1</b>.<b>112</b>. The transaction record <b>2</b>.<b>302</b> may include data as to the nature of the transaction <b>2</b>.<b>200</b>, an outcome of the transaction <b>2</b>.<b>200</b>, which data organisms <b>2</b>.<b>100</b> and/or data resources interacted, a date and/or time of the transaction <b>2</b>.<b>200</b>, a monetary value associated with the transaction <b>2</b>.<b>200</b>, details about use of the data organism <b>2</b>.<b>100</b>, and any additional data relevant for recordation and/or accounting purposes. The transaction record <b>2</b>.<b>302</b> is transmitted from the mediation server <b>1</b>.<b>102</b> to each server <b>1</b>.<b>116</b> that includes data organisms <b>2</b>.<b>100</b> participating in the transaction <b>2</b>.<b>200</b>, and specifically the transaction record <b>2</b>.<b>302</b> may be submitted to a record runtime environment <b>1</b>.<b>116</b>. In the embodiment of <figref idref="DRAWINGS">FIG. 2.2</figref>, the transaction record <b>2</b>.<b>302</b> is transmitted to record runtime environment <b>1</b>.<b>116</b>A to be deposited as ‘T<b>5</b>’ via record deposition <b>2</b>.<b>204</b>A in the hastory <b>2</b>.<b>104</b>A of data organism <b>2</b>.<b>100</b>A. Similarly, the transaction record <b>2</b>.<b>302</b> is transmitted to the record runtime environment <b>1</b>.<b>116</b>B to be added as ‘T<b>3</b>’ of the hastory <b>2</b>.<b>104</b>B. Following each of the record depositions <b>2</b>.<b>204</b>, each of the hastories <b>2</b>.<b>104</b> may re-calculate the root hash <b>2</b>.<b>310</b> of each of their respective sequential chains <b>2</b>.<b>300</b>, as shown and described in conjunction with <figref idref="DRAWINGS">FIG. 2.6</figref>. Although not shown in the embodiment of <figref idref="DRAWINGS">FIG. 2.2</figref>, both the data organism <b>2</b>.<b>100</b>A and the data organism <b>2</b>.<b>100</b>B may be resident on the same server <b>1</b>.<b>106</b>A. Additionally, a transaction <b>2</b>.<b>200</b> may occur between one data organism <b>2</b>.<b>100</b> (e.g., a data resource having a controlled identity within the datastore <b>1</b>.<b>114</b>) and one or more data resource that do not have controlled identities.

<figref idref="DRAWINGS">FIG. 2.3</figref> is a hastory view <b>2</b>.<b>350</b> illustrating the hastory <b>2</b>.<b>104</b> of <figref idref="DRAWINGS">FIG. 2.1</figref> including a sequential chain of blocks <b>2</b>.<b>300</b> implemented as a hash chain, each block <b>2</b>.<b>304</b> including a transaction record <b>2</b>.<b>302</b> and a hash value <b>2</b>.<b>306</b>, the hash value <b>2</b>.<b>306</b> generated based on the transaction record <b>2</b>.<b>302</b> and a penultimate hash value <b>2</b>.<b>308</b> of a previous block <b>2</b>.<b>304</b>, a root hash <b>3</b>.<b>210</b> unique within the datastore <b>1</b>.<b>114</b> for a given data within each of the blocks <b>2</b>.<b>304</b> and a given block order of the sequential chain <b>2</b>.<b>300</b>, according to one or more embodiments. In <figref idref="DRAWINGS">FIG. 2.3</figref>, the hastory <b>2</b>.<b>104</b> is shown as a set of five blocks, the block <b>2</b>.<b>304</b>A through <b>2</b>.<b>304</b>D, although the hastory <b>2</b>.<b>104</b> may grow to an arbitrary number of blocks <b>2</b>.<b>304</b> in length. A first block <b>2</b>.<b>304</b> of the sequential chain <b>2</b>.<b>300</b>, shown as a genesis block <b>2</b>.<b>303</b>A, may be a block initiating the hastory <b>2</b>.<b>104</b> and the controlled identity of the data organism <b>2</b>.<b>100</b>. For example, where the data organism <b>2</b>.<b>100</b> is a user profile <b>3</b>.<b>114</b>, the genesis block <b>2</b>.<b>303</b>A may contain a transaction record <b>2</b>.<b>302</b>A that includes data related to or associated with a user that the user profile represents, such as an email address, an IP address, associated device IDs, a social security number, a physical mailing address, an age, and/or other information of the user. Where the data organism <b>2</b>.<b>100</b> is a media file, the genesis block <b>2</b>.<b>303</b>A may be data related to when the data organism <b>2</b>.<b>100</b> was created and a hash value of the initial contained data <b>2</b>.<b>108</b> of the data organism <b>2</b>.<b>100</b>. The genesis block <b>2</b>.<b>302</b>A is hashed according to a hash function (e.g., the SHA256 algorithm) denoted ‘f( ),’ using as an input the transaction record <b>2</b>.<b>302</b>A to yield the hash value <b>2</b>.<b>306</b>A. The hash function may be a cryptographic function and/or algorithm that converts a set of data to a string of other data such as alphanumeric characters. Additionally, the hash function may be a function that can be used to map digital data of arbitrary size to digital data of fixed size, where a small change in the input digital data yields a large difference in the output digital data of fixed size. The hash chain may be usable in successive application of a cryptographic hash function to a piece of data, can be applied successively to additional pieces of data in order to record a chronology of an existence of all of the data.

After undergoing a second transaction <b>2</b>.<b>200</b>, the transaction record <b>2</b>.<b>302</b> may be generated and deposited in the block <b>2</b>.<b>204</b>B. For example, the transaction record <b>2</b>.<b>302</b>B may be a login transaction where the data organism <b>2</b>.<b>100</b> is the user profile, or may be a use transaction where the data organism <b>2</b>.<b>100</b> is the media file. In calculating the hash value <b>2</b>.<b>406</b>B of block <b>2</b>.<b>304</b>B, the hash function uses inputs that include the data of the transaction record <b>2402</b>B in addition to the previous hash value <b>2</b>.<b>306</b>A. This process continues as each block <b>2</b>.<b>406</b> is added to the sequential chain <b>2</b>.<b>300</b> such that a new root hash <b>2</b>.<b>310</b> is generated using the most recent transaction record <b>2</b>.<b>302</b> (e.g., of a present transaction) along with a penultimate hash <b>3</b>.<b>208</b> associated with a transaction that immediately proceeded the present transaction. After repeating this process for five transactions <b>2</b>.<b>200</b>, the sequential chain of blocks <b>2</b>.<b>300</b> may include four previous transactions <b>2</b>.<b>301</b>, and one most recent block, the block <b>2</b>.<b>304</b>E. In the embodiment of <figref idref="DRAWINGS">FIG. 2.3</figref>, the last hash value <b>2</b>.<b>306</b>E of the sequential chain of blocks <b>2</b>.<b>300</b> is the root hash <b>2</b>.<b>310</b>, which may be used to uniquely distinguish the data organism <b>2</b>.<b>100</b> from any other data organisms <b>2</b>.<b>100</b> in the datastore <b>1</b>.<b>114</b>. The root hash <b>2</b>.<b>310</b> is unique for a given data of each of the transaction records <b>2</b>.<b>302</b> and for a given order of the blocks <b>2</b>.<b>304</b> of the sequential chain of blocks <b>2</b>.<b>300</b>. Although not shown in the embodiment of <figref idref="DRAWINGS">FIG. 2.3</figref>, the hash function may additionally use as inputs additional data such as a nonce.

<figref idref="DRAWINGS">FIG. 2.4</figref> is a second hastory view <b>2</b>.<b>450</b> illustrating the hastory <b>2</b>.<b>104</b> of <figref idref="DRAWINGS">FIG. 2.1</figref> implemented as a Merkle tree, a binary tree of a set of leaf nodes extended from the sequential chain of blocks <b>2</b>.<b>300</b> to a root node that includes a root hash <b>2</b>.<b>310</b> that is unique within the datastore <b>1</b>.<b>114</b>, according to one or more embodiments. The Merkle tree implementation of the hastory <b>2</b>.<b>104</b> may be useful to reduce computing overhead in re-computing the root hash <b>2</b>.<b>310</b> and/or where the hastory <b>2</b>.<b>104</b> may include a large number of blocks <b>2</b>.<b>304</b>. In <figref idref="DRAWINGS">FIG. 2.4</figref>, the data of each pair of the blocks <b>2</b>.<b>302</b> in the sequential chain of blocks <b>2</b>.<b>300</b> starting with the genesis block <b>2</b>.<b>303</b>A are used as inputs to a hash function to generate a leaf hash <b>2</b>.<b>400</b> that is a “leaf node” of the Merkle tree. For example, in <figref idref="DRAWINGS">FIG. 2.4</figref> the genesis block <b>2</b>.<b>303</b>A and the block <b>2</b>.<b>304</b>B are both hashed to yield a leaf hash <b>2</b>.<b>400</b>A. In turn, each pair of leaf hashes <b>2</b>.<b>400</b> are input into the hash function to yield the leaf hash <b>2501</b>. Any unpaired blocks <b>2</b>.<b>304</b> are replicated to form a pair of duplicate blocks <b>2</b>.<b>304</b>. For example, where block <b>2</b>.<b>304</b>E is an unpaired block <b>2</b>.<b>304</b>, the data of the block <b>2</b>.<b>304</b>E is replicated to form a block <b>2</b>.<b>304</b>F (denoted ‘T<b>5</b>’ and which may be referred to as “T<b>5</b> prime”). The leaf hash <b>2</b>.<b>400</b>C is then computing using as inputs block <b>2</b>.<b>304</b>E (T<b>5</b>) and the block <b>2</b>.<b>304</b>F (T<b>5</b>′). Later, when an even-numbered transaction (e.g., T<b>6</b>) is added to the sequential chain of blocks <b>2</b>.<b>300</b>, T<b>5</b>′ is replaced with T<b>6</b> and all leaf hashs dependent on the block <b>2</b>.<b>304</b>F are re-calculated (e.g., leaf hash <b>2</b>.<b>400</b>C, the leaf hash <b>2</b>.<b>401</b>B, the root hash <b>2</b>.<b>310</b>). In the case of the Merkle tree, the penultimate hash <b>2</b>.<b>408</b> may be the a hash value <b>2</b>.<b>500</b> of a leaf node that is dependent on the transaction immediately previous to a present transaction. For example, in the embodiment of <figref idref="DRAWINGS">FIG. 2.4</figref>, the penultimate hash <b>2</b>.<b>408</b> may be the hash value <b>2</b>.<b>500</b>C that uses as an input T<b>5</b> of <figref idref="DRAWINGS">FIG. 2.4</figref>. The hash function calculating the root hash <b>2</b>.<b>310</b> uses the penultimate hash as an input through the incorporation of the penultimate hash in a higher leaf node (e.g., the lead node (<b>1</b>-<b>1</b>) of <figref idref="DRAWINGS">FIG. 2.4</figref>.

<figref idref="DRAWINGS">FIG. 2.5</figref> is a data organism identity evolution view <b>2</b>.<b>550</b> showing the data organism <b>2</b>.<b>100</b> of <figref idref="DRAWINGS">FIG. 2.1</figref> copied to form an original data organism <b>2</b>.<b>300</b>A and a copied data organism <b>2</b>.<b>300</b>X that remain uniques within the datastore as each engages in different transactions <b>2</b>.<b>200</b> that are added to each of the hastories <b>2</b>.<b>104</b>A and <b>2</b>.<b>104</b>X to result in different root hashes <b>2</b>.<b>310</b>, according to one or more embodiments. In <figref idref="DRAWINGS">FIG. 2.5</figref>, the record runtime environment <b>1</b>.<b>116</b> via record deposition <b>2</b>.<b>204</b> deposits the transaction record <b>2</b>.<b>302</b> (T<b>4</b>) as a new block <b>2</b>.<b>304</b> in the data organism <b>2</b>.<b>100</b>A. In the embodiment of <figref idref="DRAWINGS">FIG. 2.5</figref>, the transaction <b>2</b>.<b>200</b> T<b>4</b> is a controlled copying transaction as shown and described in conjunction with <figref idref="DRAWINGS">FIG. 2.8</figref>. The result of the controlled copying transaction is: a new block <b>2</b>.<b>304</b> added to the hastory <b>2</b>.<b>104</b>A (T<b>5</b>) and a new block <b>2</b>.<b>304</b> added to the hastory <b>2</b>.<b>104</b>X (T<b>5</b>′). The data of T<b>5</b> and T<b>5</b>′ is slightly different, e.g., T<b>5</b> may include an “original” designation within the transaction record <b>2</b>.<b>302</b> and T<b>5</b>′ may include a “copied” designation. As a result, the hastory <b>2</b>.<b>100</b>A has been “forked” into the hastory <b>2</b>.<b>104</b>A of the original data organism <b>2</b>.<b>100</b>A and the hastory <b>2</b>.<b>104</b>X of the copied data organism <b>2</b>.<b>100</b>X. Alternatively, although not shown in <figref idref="DRAWINGS">FIG. 2.5</figref>, the copied data organism <b>2</b>.<b>100</b>X may begin with a new hastory <b>2</b>.<b>104</b>X having a single genesis block <b>2</b>.<b>303</b>A. The original data organism <b>2</b>.<b>100</b>A and the copied data organism <b>2</b>.<b>100</b>X will undergo different transactions <b>2</b>.<b>200</b>, diverging their identities. Following the controlled copying, the root hash <b>2</b>.<b>306</b>A of the original data organism <b>2</b>.<b>100</b>A and the root hash <b>2</b>.<b>306</b>X of the copied data organism <b>2</b>.<b>100</b>X will not have the same values due to the cryptographic properties of the hash function. Thus, both the original data organism <b>2</b>.<b>100</b>A and the copied data organism <b>2</b>.<b>100</b>X remain unique within the datastore <b>1</b>.<b>114</b>, and computing processes may be defined (including the computing processes of the transaction engine <b>1</b>.<b>110</b>) that pertain to and/or specify either individually.

<figref idref="DRAWINGS">FIG. 2.6</figref> is a transaction process flow <b>2</b>.<b>600</b> illustrating a process by which two of the data organisms of <figref idref="DRAWINGS">FIG. 2.2</figref> engage in a transaction to result in one or more evolved identities, according to one or more embodiments. Operation <b>2</b>.<b>602</b> receives a communication from a first data organism <b>2</b>.<b>100</b> addressed to a second data organism <b>2</b>.<b>100</b>, each of the data organisms <b>2</b>.<b>100</b> participants in a present transaction <b>2</b>.<b>200</b> comprising one or more computing processes. The computing processes may include, for example, the computing processes <b>2</b>.<b>110</b> contained in either or both of the first data organism <b>2</b>.<b>100</b> and the second data organism <b>2</b>.<b>100</b>. The communication may be a message such as a use request (e.g., the use request <b>4</b>.<b>130</b> of <figref idref="DRAWINGS">FIG. 4.1</figref>) from the first data organism <b>2</b>.<b>100</b> (e.g., a user profile <b>3</b>.<b>114</b>) to the second data organism <b>2</b>.<b>100</b> (e.g., containing a document). Operation <b>2</b>.<b>604</b> determines that the first data organism <b>2</b>.<b>100</b> and/or the second data organism <b>2</b>.<b>100</b> has a controlled identity within the datastore <b>1</b>.<b>114</b>, a particular data organism <b>2</b>.<b>100</b> of the first data organism <b>2</b>.<b>100</b> and/or the second data organism <b>2</b>.<b>100</b> including a hastory <b>2</b>.<b>104</b> forming a unique identity based upon a set of previous transactions (e.g., a set of the transactions <b>2</b>.<b>200</b>) of the particular data organism <b>2</b>.<b>100</b>. For example, the transaction engine <b>1</b>.<b>110</b> and/or the server <b>1</b>.<b>106</b>A may determine that a data resource has a controlled identity (e.g., that it an instance of the data organism <b>2</b>.<b>100</b>) by the presence of a hastory attribute of the data organism <b>2</b>.<b>100</b> and/or a different attribute indicating that the data resource is to be a controlled identity within the datastore <b>1</b>.<b>114</b>. Operation <b>2</b>.<b>606</b> executes the one or more computing processes utilizing the contained data <b>2</b>.<b>108</b> of the first data organism <b>2</b>.<b>100</b> and/or the second data organism <b>2</b>.<b>100</b>. For example, the transaction <b>2</b>.<b>100</b> may involve the use of a video file of the contained data of the second data organism <b>2</b>.<b>100</b>. In another example, the data organism <b>2</b>.<b>100</b> may contain within the contained data <b>2</b>.<b>108</b> an SQL query executed against a relational database application when the data organism <b>2</b>.<b>100</b> is called. Operation <b>2</b>.<b>608</b> determines that the present transaction <b>2</b>.<b>200</b> is complete when the one or more computing processes terminate. For example, as shown in conjunction with <figref idref="DRAWINGS">FIG. 4.5</figref>, a use transaction may terminate when a protected resource is no longer in active use by the device <b>1</b>.<b>104</b>. In operation <b>2</b>.<b>610</b>, a transaction record <b>2</b>.<b>302</b> of the present transaction <b>2</b>.<b>200</b> is generated. Generating the transaction record <b>2</b>.<b>302</b> may also occur along with the process of closing an open transaction record (e.g., the open transaction record <b>4</b>.<b>404</b> of <figref idref="DRAWINGS">FIG. 4.404</figref>). Operation <b>2</b>.<b>612</b> deposits the transaction record <b>2</b>.<b>302</b> of the present transaction <b>2</b>.<b>200</b> as a new block <b>2</b>.<b>304</b> in a sequential chain <b>2</b>.<b>300</b> of the hastory <b>2</b>.<b>104</b> of the first data organism <b>2</b>.<b>100</b> and/or the second data organism <b>2</b>.<b>100</b> having the controlled identity. Operation <b>2</b>.<b>614</b> re-calculates the root hash <b>2</b>.<b>310</b> of the hastory <b>2</b>.<b>104</b> with the hash function using inputs comprising the new block <b>2</b>.<b>304</b> of the hastory <b>2</b>.<b>104</b>, to evolve the controlled identity of at the first data organism <b>2</b>.<b>100</b> and/or the second data organism <b>2</b>.<b>100</b>, as further shown and described in conjunction with <figref idref="DRAWINGS">FIG. 2.3</figref> and/or <figref idref="DRAWINGS">FIG. 2.4</figref>.

<figref idref="DRAWINGS">FIG. 2.7</figref> is a second transaction process flow <b>2</b>.<b>700</b> illustrating a detailed process by which one or more data resources and/or data organisms <b>2</b>.<b>100</b> transact such that data organisms <b>2</b>.<b>100</b> having controlled identities participating in the transaction <b>2</b>.<b>200</b> remain unique within the datastore <b>1</b>.<b>114</b>, according to one or more embodiments. Operation <b>2</b>.<b>702</b> transmits a communication (e.g., sends an addressed) from a first set of one or more data resources. The one or more data resources may include one or more data organisms <b>2</b>.<b>100</b>. For example, the communication may be a 1:N communication in which a data organism <b>2</b>.<b>100</b>A that is a user profile <b>3</b>.<b>114</b> sends a message to a number of other data organisms <b>2</b>.<b>100</b>B through <b>2</b>.<b>100</b>N that are also user profiles <b>3</b>.<b>114</b>. Similarly, the communication may be N:1 or N:N, with ‘N’ representing an arbitrary number of transacting data resources and/or data organisms <b>2</b>.<b>100</b>. Similarly, a data organism <b>2</b>.<b>100</b> may address itself, for example when a user associated with a user profile <b>3</b>.<b>114</b> updates data of the user profile <b>3</b>.<b>114</b>. Operation <b>2</b>.<b>704</b> receives the communication at a second set of one or more data organism <b>2</b>.<b>100</b>. Operation <b>2</b>.<b>706</b> extracts computing processes used in the transaction <b>2</b>.<b>200</b>. For example, the computing processes may specify a series of operations to perform as part of the transaction <b>2</b>.<b>200</b> when the data organism <b>2</b>.<b>100</b> is called and/or addressed. In another example, the computing processes may define a use policy <b>4</b>.<b>108</b> comprising computer-readable instructions calling one or more contextual values to define an authorized context for which utilization of a protected resource is authorized. The computing processes may be extracted from a server (e.g., the mediation server <b>1</b>.<b>102</b>, the usermode microservice <b>1</b>.<b>140</b>), and/or from the contained data <b>2</b>.<b>108</b> of the data resource and/or the data organism <b>2</b>.<b>100</b> (e.g., the computing processes used in the transaction <b>2</b>.<b>200</b> may include the computing processes <b>2</b>.<b>110</b> stored within the contained data <b>2</b>.<b>108</b>). Operation <b>2</b>.<b>708</b> executes the computing processes to effect the transaction <b>2</b>.<b>200</b>. For example, operation <b>2</b>.<b>708</b> may effect a controlled copying of the data organism <b>2</b>.<b>100</b> through a sub-set of the operations of the process flow <b>2</b>.<b>800</b> of <figref idref="DRAWINGS">FIG. 2.8</figref>.

Operation <b>2</b>.<b>710</b> is a decision that determines whether the contained data <b>2</b>.<b>108</b> of one or more of the data resources and/or data organisms <b>2</b>.<b>100</b> that are transacting should be updated. For example, a user may replace the contents of a data organism <b>2</b>.<b>100</b>, or may update attributes and/or values of the data organism <b>2</b>.<b>100</b>. If the contained data <b>2</b>.<b>108</b> is to be updated, operation <b>2</b>.<b>712</b> updates the contained data <b>2</b>.<b>712</b> of appropriate data organism <b>2</b>.<b>100</b>, then proceeds to operation <b>2</b>.<b>714</b>. Otherwise, operation <b>2</b>.<b>710</b> proceeds to operation <b>2</b>.<b>714</b>, which generates one or more transaction records <b>2</b>.<b>302</b>. The transaction records <b>2</b>.<b>302</b> may include, for example, the identifiers <b>2</b>.<b>102</b> of other data organisms <b>2</b>.<b>100</b> in the transaction <b>2</b>.<b>200</b>, information such as a time of the transaction <b>2</b>.<b>00</b>, use data of the transaction <b>2</b>.<b>00</b>, and/or performance of the executed computing processes. The transaction records <b>2</b>.<b>302</b> may also include data such as use termination records (e.g., the termination report <b>4</b>.<b>508</b>) and records of updates made to a use policy <b>4</b>.<b>108</b> controlling use of data within the data organism <b>2</b>.<b>100</b>. Operation <b>2</b>.<b>716</b> determines whether each of the data resources involved in the transaction <b>2</b>.<b>100</b> are controlled identities within the datastore <b>1</b>.<b>114</b>. If not, no further action may be taken for the particular data resource. If the particular data resource is a controlled identity (e.g., it is a data organisms <b>2</b>.<b>100</b>), then operation <b>2</b>.<b>718</b> deposits one or more transaction records <b>2</b>.<b>302</b> in the hastory <b>2</b>.<b>104</b> of the particular data resource that is a data organism <b>2</b>.<b>100</b>. Operation <b>2</b>.<b>720</b> then re-calculates a root hash <b>2</b>.<b>310</b> to evolve an identity of the data organism <b>2</b>.<b>100</b>.

To control copies within the datastore <b>1</b>.<b>114</b>, a primary use of the evolving identity of data organisms <b>2</b>.<b>100</b> may be to control copying and/or replication of the data within the datastore <b>1</b>.<b>114</b> such that data retains uniqueness. <figref idref="DRAWINGS">FIG. 2.8</figref> is a controlled copying process flow <b>2</b>.<b>800</b> illustrating a process by which the copying transaction shown in <figref idref="DRAWINGS">FIG. 2.5</figref> may be controlled within the datastore <b>1</b>.<b>114</b> such that an original data organism <b>2</b>.<b>100</b> and a copied data organism <b>2</b>.<b>100</b> remain unique, according to one or more embodiments. Operation <b>2</b>.<b>802</b> specifies an original data organism <b>2</b>.<b>100</b> to be a subject matter of a controlled copying instance of the transaction <b>2</b>.<b>200</b>. For example, a user may specify an original data organism <b>2</b>.<b>100</b> to be copied, as may be useful for versioning of the contained data <b>2</b>.<b>108</b> of the original data organism <b>2</b>.<b>100</b>. Similarly, a server could use the controlled copying transaction when distributing instances of the data organism <b>2</b>.<b>100</b> across several physical locations to track those instances. Operation <b>2</b>.<b>802</b> determines that the data organism <b>2</b>.<b>100</b> is a controlled identity within the datastore <b>1</b>.<b>114</b> (e.g., it is a data resource including a hastory <b>2</b>.<b>104</b>). Operation <b>2</b>.<b>806</b> generates a transaction record <b>2</b>.<b>302</b> of the transaction of the controlled copying of the original data organism <b>2</b>.<b>100</b>, and operation <b>2</b>.<b>208</b> copies the contained data <b>2</b>.<b>108</b> of the original data organism into a copied data organism <b>2</b>.<b>100</b>. Other attributes and values of the original data organism <b>2</b>.<b>100</b>, such as the ownership designation <b>2</b>.<b>106</b>. Operation <b>2</b>.<b>810</b> deposits the transaction record <b>2</b>.<b>302</b> in a hastory <b>2</b>.<b>104</b> of the original data organism <b>2</b>.<b>100</b> as a new block <b>2</b>.<b>304</b> in a sequential chain <b>2</b>.<b>300</b> of the hastory <b>2</b>.<b>104</b> of the original data organism <b>2</b>.<b>100</b>. Operation <b>2</b>.<b>812</b> re-calculates a root hash <b>2</b>.<b>310</b> of the hastory <b>2</b>.<b>104</b> of the original data organism <b>2</b>.<b>100</b> based upon the genesis <b>2</b>.<b>303</b>, to evolve the identity of the original data organism <b>2</b>.<b>100</b>. Operation <b>2</b>.<b>214</b> deposits the transaction record <b>2</b>.<b>302</b> of the controlled copying as a genesis block <b>2</b>.<b>303</b> of a hastory <b>2</b>.<b>104</b> of the copied data organism <b>2</b>.<b>100</b>, the genesis block <b>2</b>.<b>303</b> added as a first block <b>2</b>.<b>304</b> of a sequential chain <b>2</b>.<b>300</b> of the hastory <b>2</b>.<b>104</b> of the copied data organism <b>2</b>.<b>100</b>. Operation <b>2</b>.<b>816</b> calculates the root hash <b>2</b>.<b>310</b> of the hastory <b>2</b>.<b>104</b> of the copied data organism <b>2</b>.<b>100</b> based upon the genesis block <b>2</b>.<b>303</b>, to initiate an identity of the copied data organism <b>2</b>.<b>100</b> and distinguish the original data organism <b>2</b>.<b>100</b> from the copied data organism <b>2</b>.<b>100</b>. Optionally, operation <b>2</b>.<b>818</b> may assign a new unique identifier to the copied data organism <b>2</b>.<b>100</b> such that it can be uniquely addressed within the datastore <b>2</b>.<b>114</b> even as the root hash <b>2</b>.<b>310</b> continues to change. In one or more embodiments, the new unique identifier may be recorded in a transaction record <b>2</b>.<b>302</b>.

In addition to the controlled copying transaction, the data resource control network <b>1</b>.<b>100</b> may be used to control ownership of and to effect an ownership transfer of the set of bits that comprise an original data organism <b>2</b>.<b>100</b>. <figref idref="DRAWINGS">FIG. 2.9</figref> is a data organism transfer process flow <b>2</b>.<b>900</b> showing a process by which the data organism <b>2</b>.<b>100</b> of <figref idref="DRAWINGS">FIG. 2.1</figref> may have an ownership transferred between a first user and a second user by changing an ownership designation <b>2</b>.<b>106</b> and depositing a record of the transaction (e.g., the transaction record <b>2</b>.<b>302</b>) in a block <b>2</b>.<b>304</b> of the hastory <b>2</b>.<b>104</b> of the data organism <b>2</b>.<b>100</b>, according to one or more embodiments. Operation <b>2</b>.<b>902</b> specifies an original data organism <b>2</b>.<b>100</b> to be a subject matter of an ownership transfer, the original data organism <b>2</b>.<b>100</b> comprising a unique identifier (e.g., an instance of the identifier <b>2</b>.<b>302</b> of <figref idref="DRAWINGS">FIG. 2.1</figref>), an ownership designation <b>2</b>.<b>106</b>, a contained data <b>2</b>.<b>108</b>, and a hastory <b>2</b>.<b>104</b>. For example, a user may request to transfer ownership of one or more data organisms <b>2</b>.<b>100</b> that the user owns, and/or the arbiter <b>1</b>.<b>900</b> of <figref idref="DRAWINGS">FIG. 1.1</figref> may transfer ownership to one or more other users. Operation <b>2</b>.<b>904</b> determines that the original data organism <b>2</b>.<b>100</b> is a controlled identity within the datastore <b>1</b>.<b>114</b> by detected a hastory <b>2</b>.<b>102</b> associated with the original data organism <b>2</b>.<b>100</b>. Operation <b>2</b>.<b>906</b> changes the ownership designation <b>2</b>.<b>106</b> of the original data organism <b>2</b>.<b>100</b> to a new ownership designation <b>2</b>.<b>106</b>. Operation <b>2</b>.<b>108</b> generates a transaction record <b>2</b>.<b>302</b> of the transaction <b>2</b>.<b>200</b> that is the ownership transfer of the original data organism <b>2</b>.<b>100</b>, and operation <b>2</b>.<b>910</b> deposits the transaction record <b>2</b>.<b>302</b> of the ownership transfer as a new block <b>2</b>.<b>304</b> in the sequential chain <b>2</b>.<b>300</b> of the hastory <b>2</b>.<b>104</b> of the original data organism <b>2</b>.<b>100</b>. For example, the transaction record <b>2</b>.<b>302</b> may be generated by the transaction engine <b>1</b>.<b>110</b> and deposited by one or more record runtime environments <b>1</b>.<b>116</b>. Operation <b>2</b>.<b>912</b> re-calculates a root hash <b>2</b>.<b>310</b> of the hastory <b>2</b>.<b>104</b> of the original data organism <b>2</b>.<b>100</b> based upon the new block <b>2</b>.<b>304</b>, to evolve the identity of the original data organism <b>2</b>.<b>100</b>. Upon the competition of process flow <b>2</b>.<b>900</b>, the identity of the original data organism <b>2</b>.<b>100</b> will evolve to distinguish the original from copies within the datastore <b>1</b>.<b>114</b>.

<figref idref="DRAWINGS">FIG. 2.10</figref> is a second data organism transfer process flow <b>2</b>.<b>900</b> illustrating a second process by which the ownership of the data organism <b>2</b>.<b>100</b> may be transferred by copying the data organism and: flagging an original of the data organism <b>2</b>.<b>100</b> as extinct; depositing an ownership transfer as a termination block <b>2</b>.<b>304</b> of the hastory <b>2</b>.<b>104</b> of the original data organism <b>2</b>.<b>100</b>; and/or, erasing the original data organism <b>2</b>.<b>100</b> from the datastore <b>2</b>.<b>114</b>, according to one or more embodiments. Operations <b>2</b>.<b>1002</b> and <b>2</b>.<b>1004</b> of <figref idref="DRAWINGS">FIG. 2.10</figref> are similar to operations <b>2</b>.<b>902</b> and operations <b>2</b>.<b>904</b> of <figref idref="DRAWINGS">FIG. 2.9</figref>. Operation <b>2</b>.<b>1006</b> copies the contained data <b>2</b>.<b>108</b> of the data organism <b>2</b>.<b>100</b> into a copied data organism <b>2</b>.<b>100</b>, similar to operation <b>2</b>.<b>808</b> of <figref idref="DRAWINGS">FIG. 2.8</figref>. Operation <b>2</b>.<b>1008</b> through operation <b>2</b>.<b>1012</b> are similar to operation <b>2</b>.<b>908</b> through <b>2</b>.<b>912</b> of <figref idref="DRAWINGS">FIG. 2.9</figref>. Operation <b>2</b>.<b>1014</b> effects one of the following processes: flags the original data organism <b>2</b>.<b>100</b> as extinct; deposits the transaction record <b>2</b>.<b>302</b> of the ownership transfer as a termination block <b>2</b>.<b>304</b> of the hastory of the original data organism <b>2</b>.<b>100</b>; and/or, erases the original data organism <b>2</b>.<b>100</b> from the datastore <b>1</b>.<b>114</b>. The data organism <b>2</b>.<b>100</b> flagged as distinct may be partitioned within the datastore <b>1</b>.<b>114</b> and may have its ownership designation changed to an application program for creating auditing records. Operation <b>2</b>.<b>1016</b> may deposit the transaction record <b>2</b>.<b>302</b> of the ownership transfer as a genesis block <b>2</b>.<b>303</b> of a hastory <b>2</b>.<b>104</b> of the copied data organism <b>2</b>.<b>100</b>, the genesis block <b>2</b>.<b>303</b> added as a first block <b>2</b>.<b>304</b> in the sequential chain <b>2</b>.<b>300</b>. Operation <b>2</b>.<b>1018</b> calculates the root hash <b>2</b>.<b>310</b> of the hastory <b>2</b>.<b>104</b> of the copied data organism <b>2</b>.<b>100</b> based upon the genesis block <b>2</b>.<b>303</b>, to initiate an identity of the copied data organism <b>2</b>.<b>100</b> (e.g., as a new data resource of the datastore <b>1</b>.<b>114</b> having a controlled identity). Similarly, the calculated root hash <b>2</b>.<b>310</b> distinguishs the original data organism <b>2</b>.<b>100</b> (e.g., which may now be deleted, and/or extinct) from the copied data organism <b>2</b>.<b>100</b>. Finally, operation <b>2</b>.<b>1020</b> may assign a new unique identifier (e.g., an instance of the identifier <b>2</b>.<b>102</b> that is unique within the datastore) to the copied data organism <b>2</b>.<b>100</b>.

<figref idref="DRAWINGS">FIG. 2.11</figref> is a media use transaction view <b>2</b>.<b>1150</b> illustrating a video data <b>2</b>.<b>1101</b> stored in a media file <b>2</b>.<b>1100</b> that is a first data organism <b>2</b>.<b>100</b>A, the media file <b>2</b>.<b>1100</b> an application resource for a second data organism <b>2</b>.<b>100</b>B that is an application profile <b>2</b>.<b>1105</b> and the media file <b>2</b>.<b>1100</b> accessed by a user associated with a user profile <b>3</b>.<b>106</b> that is a third data organism <b>2</b>.<b>100</b>, according to one or more embodiments. Specifically, <figref idref="DRAWINGS">FIG. 2.11</figref> is an example of a transaction <b>2</b>.<b>200</b> in which a user requests to utilize a first data organism <b>2</b>.<b>100</b> through use by an application program on a device <b>1</b>.<b>104</b> associated with a user. For example, the application program might be a music streaming player or an enterprise business contact application. The application program may include an instance of the data resource and/or the data organism <b>2</b>.<b>100</b> that is the application profile <b>2</b>.<b>1105</b>, which may catalogue and/or list each of the data resources and/or data organisms <b>2</b>.<b>100</b> available to the application program (e.g., as application resources). Using a user interface (UI) of the application program, the user may select a video which the user would like to view. After an authentication of the user and/or the device along with authorization of the user, the mediation server <b>1</b>.<b>102</b> may initiate a use transaction. For example, the use transaction may be data use as shown in described in conjunction with <figref idref="DRAWINGS">FIG. 4.1</figref> On conclusion of the use transaction, the resulting transaction record <b>2</b>.<b>302</b> may be deposited in each of the hastories <b>2</b>.<b>1104</b> of the media file <b>2</b>.<b>1100</b>, the user profile <b>3</b>.<b>114</b>, and/or the application profile <b>2</b>.<b>1105</b> to evolve the identities of each and create an auditing record of the transaction within each. The media file <b>2</b>.<b>1100</b> may be transacting with several user profiles <b>3</b>.<b>106</b> simultaneously. For example, there may be several open transaction records <b>4</b>.<b>404</b> within the terms engine server-side <b>1</b>.<b>112</b>A as shown in <figref idref="DRAWINGS">FIG. 4.4</figref>. In one or more embodiments, while each transaction <b>2</b>.<b>200</b> may open at a different time, a particular transaction <b>2</b>.<b>200</b> that closes (e.g., generates a transaction record <b>2</b>.<b>302</b>) may be added to the file hastory <b>2</b>.<b>1104</b> first. Similarly, the application program may be simultaneously transacting with hundred or thousands of user profiles <b>3</b>.<b>106</b> and/or other data organisms <b>2</b>.<b>100</b>. As shown in <figref idref="DRAWINGS">FIG. 2.11</figref>, the transaction record <b>2</b>.<b>302</b> of <figref idref="DRAWINGS">FIG. 2.11</figref> is added as T<b>49</b>, while a different transaction <b>2</b>.<b>200</b> may still be pending (to tentatively have a transaction record <b>2</b>.<b>302</b> of the different transaction <b>2</b>.<b>200</b> added as T<b>50</b> within the application hastory <b>2</b>.<b>1106</b>).

The embodiments shown and described in conjunction with <figref idref="DRAWINGS">FIG. 2.1</figref> through <figref idref="DRAWINGS">FIG. 2.11</figref> lead to a number of advantages. First, characterizing various interactions within the datastore <b>1</b>.<b>114</b> as transactions may allow for a distinguishing factor of data resources based on a developing history of how they transact. Hashing this developing history may form an immutable record of transactions associated with each data resource that is usable to distinguish the data resource from any other data resource within the datastore <b>1</b>.<b>114</b>. The result may be one or more data organisms <b>2</b>.<b>100</b>, each of which have an evolving identity. In other words, the data within the datastore <b>1</b>.<b>114</b> is able to remain unique within the datastore <b>1</b>.<b>114</b> and/or globally unique.

Computing processes may be defined to treat each of the data organisms <b>2</b>.<b>100</b> differently. For example, a user who owns an original data <b>2</b>.<b>100</b> resource may be able to determine constrained permissions for any copy of the set of bits of the original data organism <b>2</b>.<b>100</b>. Specifically, the user may decide that an original document can only be modified by himself or herself, whereas a copy may only have read-access. As a result, the set of bits of original data resource may have increased economic value being that the original data organism <b>2</b>.<b>100</b> includes a single instance that may be permanently and/or immutably transferred (e.g., the ownership transfer transaction). In addition, the data organisms <b>2</b>.<b>100</b> are able to participate in agreements between one or more users and/or parties wherein ownership is temporarily granted to the arbiter <b>1</b>.<b>900</b>. The ability to enforce such agreements may provide a foundation for marketplaces for data organisms <b>2</b>.<b>100</b> that may further increase their monetary value.

Third, the root hash <b>2</b>.<b>310</b> may be used that two or more data organisms which may include other similar identifying names (e.g., a file name) may contain different data. For example, one or more transactions may be recorded that change the contained data of a particular data organism <b>2</b>.<b>100</b>, thus changing the root hash <b>2</b>.<b>310</b> of the hastory <b>2</b>.<b>104</b> of the particular data organism. Where the hash function additionally includes as an input one or more pieces of the contained data <b>2</b>.<b>108</b>, it may also affect the root hash <b>2</b>.<b>310</b>. These advantages may markedly increase efficiency of the datastore <b>1</b>.<b>114</b>, for users, an enterprise administering the datastore <b>1</b>.<b>114</b>, and/or developers building application programs that interact with the datastore <b>1</b>.<b>114</b>.

In addition, use of one or more data organisms <b>2</b>.<b>100</b> within the datastore <b>1</b>.<b>114</b> may improve ease of data analysis being that each data resource and the transactions in which it has participated can be individually identified and distinguished. For example, comparing root hashes <b>3</b>.<b>310</b> and/or transaction records <b>3</b>.<b>304</b> can be used to de-duplicate a dataset for analysis, and/or track a family of copies spawned from an original instance of the data organism <b>2</b>.<b>100</b>. The chain of blocks <b>2</b>.<b>300</b>, each block <b>2</b>.<b>304</b> of which includes a transaction record <b>3</b>.<b>302</b>, creates an immutable accounting record of important interactions in which the data organism <b>2</b>.<b>100</b> has participated. For example, this auditing trail may be used to quickly and easily determine which employees of an enterprise used a particular data organism along with details of the use, which may be superior to re-constructing auditing logs from an external scheme that attempts to build accounting records that may be complex and require significant computing overhead. Using the immutable audit records associated with each of the data organisms <b>2</b>.<b>100</b> increases security of the datastore <b>1</b>.<b>114</b> by making it easier to detect suspicious activity by analysis and/or examination of particular data resources.

In addition to conducting transactions between data resources and maintaining uniqueness of data organisms, the immutable records of one or more data organisms <b>2</b>.<b>100</b> may be used to authenticate a user and/or a device, including “just-in-time” authentication when a particular data resource is requested. <figref idref="DRAWINGS">FIG. 3.1</figref> is an authentication transaction network <b>3</b>.<b>100</b> in which the device <b>3</b>.<b>104</b>A completes a multi-factor login that may establish a secure communication channel over the network <b>1</b>.<b>101</b>, the device <b>3</b>.<b>104</b>A and/or the device <b>3</b>.<b>104</b>B then submits an identity claim <b>3</b>.<b>120</b> comprising a device root hash <b>3</b>.<b>602</b> of a device hastory <b>3</b>.<b>108</b> to a server (e.g., the mediation server <b>1</b>.<b>102</b>) for comparison to a profile root hash <b>3</b>.<b>600</b> of a profile hastory <b>3</b>.<b>112</b> to validate the identity claim <b>3</b>.<b>120</b>, according to one or more embodiments. As a result, the root hash <b>3</b>.<b>310</b> may be used to define a fourth authentication factor based on a transaction history. This fourth authentication factor may act as a virtually un-forgeable, single-use identity credential that changes after each identity claim by a user (e.g., the user <b>3</b>.<b>303</b>) and/or a device (e.g., the device <b>1</b>.<b>304</b>A) is made. <figref idref="DRAWINGS">FIG. 3.1</figref> further illustrates four instances of a network <b>1</b>.<b>101</b>A through <b>1</b>.<b>101</b>E, a server <b>3</b>.<b>102</b> and a server <b>3</b>.<b>106</b>, a user <b>3</b>.<b>303</b>, a device <b>3</b>.<b>104</b>A and a device <b>3</b>.<b>104</b>B, a device hastory <b>3</b>.<b>108</b>, a device profile <b>3</b>.<b>110</b>, a profile hastory <b>3</b>.<b>112</b>, a user profile <b>3</b>.<b>114</b>, and an identity claim record <b>3</b>.<b>116</b>. The authentication transaction network <b>3</b>.<b>100</b> may be implemented as a part of, or independently of, the data resource control network <b>1</b>.<b>100</b>. For example, in one or more embodiments the server <b>3</b>.<b>102</b> may be the mediation server <b>1</b>.<b>102</b> of <figref idref="DRAWINGS">FIG. 1</figref>. Similarly, the server <b>3</b>.<b>106</b> may be the server <b>1</b>.<b>106</b>A and/or the usermode microservice <b>1</b>.<b>140</b>. The device <b>3</b>.<b>104</b>A and <b>3</b>.<b>104</b>B may be the device <b>1</b>.<b>104</b>A and the device <b>1</b>.<b>104</b>B, respectively. Each of the networks <b>1</b>.<b>101</b>A through <b>1</b>.<b>101</b>E may be similar or different. In one preferred embodiment, network <b>1</b>.<b>101</b>A is the internet or a first WAN, network <b>1</b>.<b>101</b>B is a Bluetooth® connection, a tether (e.g., a wired connection) a LAN, and/or a near field communication connection, the network <b>1</b>.<b>101</b>C is the internet or the first WAN, the network <b>1</b>.<b>101</b>D is a LAN and/or a second WAN behind a firewall, and the network <b>1</b>.<b>101</b>E is the internet or the first WAN. Where two or more of the network <b>1</b>.<b>101</b>A, <b>1</b>.<b>101</b>C and <b>1</b>.<b>101</b>E are the same, preferably a first channel is used to communicate between the device <b>3</b>.<b>104</b>A and server <b>3</b>.<b>102</b>, a second channel is used between device <b>3</b>.<b>106</b> and device <b>3</b>.<b>104</b>B, and a third channel to communicate between the device <b>3</b>.<b>104</b>A and server <b>3</b>.<b>106</b>. The device <b>3</b>.<b>104</b>A and the device <b>3</b>.<b>104</b>B may be a desktop computer, a smartphone (e.g., an iPhone®, a Galexy® phone, an Android® phone, a Windows® Phone), a notebook computer, a different server, a piece of wearable technology (such as a smart watch ike an iWatch), and/or a tablet device (such as an iPad). In one preferred embodiment, the device <b>3</b>.<b>104</b>A is the desktop computer and the device <b>3</b>.<b>104</b>B is the smartphone. In another preferred embodiment the device <b>3</b>.<b>104</b>A is a smartphone (e.g., an iPhone®) and the device <b>3</b>.<b>104</b>B is a piece of wearable technology (e.g., an iWatch®).

In <figref idref="DRAWINGS">FIG. 3.1</figref>, the device <b>3</b>.<b>104</b>A may request access to a service provided by a server, for example the datastore <b>1</b>.<b>114</b>. The service may also be, for example an application running on the server. The device <b>3</b>.<b>104</b>A may engage in a multi-factor login <b>3</b>.<b>118</b>, as shown and described in conjunction <figref idref="DRAWINGS">FIG. 3.2</figref> and <figref idref="DRAWINGS">FIG. 3.3</figref>. The multi-factor login <b>3</b>.<b>118</b> may establish one or more secure channels of communication (e.g., the first channel over network <b>1</b>.<b>101</b>A) by verifying that the one or more of the channels are not being intercepted by a third party (e.g., a “man-in-the-middle” attack) after which a cryptographic shared secret may be utilized, for example using a Diffie-Hellman key exchange to establish an encrypted channel. Independent of the multi-factor login, the device profile <b>3</b>.<b>110</b> makes an identity claim <b>3</b>.<b>120</b> against the user profile <b>3</b>.<b>114</b> to authenticate the device <b>3</b>.<b>104</b>A and/or the user <b>3</b>.<b>303</b> of the device <b>3</b>.<b>304</b>A. The identity claim <b>3</b>.<b>120</b> may be transmitted in addition to one or more of the tokens of the multi-factor login <b>3</b>.<b>118</b>. The identity claim <b>3</b>.<b>120</b> comprises a device root hash <b>3</b>.<b>602</b> of a device hastory <b>3</b>.<b>108</b>, as shown in <figref idref="DRAWINGS">FIG. 3.6</figref>. The device root hash <b>3</b>.<b>602</b> may be transmitted over one of the networks <b>1</b>.<b>101</b> as part of the identity claim <b>3</b>.<b>120</b> to be compared to a profile root hash <b>3</b>.<b>600</b> of a profile hastory <b>3</b>.<b>112</b>, as shown in conjunction with <figref idref="DRAWINGS">FIG. 3.3</figref> through <figref idref="DRAWINGS">FIG. 3.10</figref>. In the transaction record generation <b>3</b>.<b>130</b> the device <b>3</b>.<b>104</b>A and/or the device <b>3</b>.<b>104</b>B may generate an identity claim record <b>3</b>.<b>116</b> of the authorization request. The identity claim record <b>3</b>.<b>116</b> may be similar to the transaction record <b>2</b>.<b>200</b> of <figref idref="DRAWINGS">FIG. 2.2</figref> in nature, but may be generated by the device <b>1</b>.<b>104</b>A and/or the device <b>1</b>.<b>104</b>B. The identity update <b>3</b>.<b>150</b> comprising data of the identity claim record <b>3</b>.<b>116</b> may then be transmitted through one or more channels of communication to the server <b>3</b>.<b>106</b> in the identity update <b>3</b>.<b>150</b> for assembly into an identical and/or virtually identical instance of the identity claim record <b>3</b>.<b>116</b>, the assembly occurring in the transaction record generation <b>3</b>.<b>160</b>. The server <b>3</b>.<b>106</b> adds the transaction record to a pending and/or forming instance of the block <b>2</b>.<b>304</b> of the profile hastory <b>3</b>.<b>112</b> in the profile hastory update <b>3</b>.<b>170</b>. The root hash of the device hastory <b>3</b>.<b>108</b> and the root hash of the profile hastory <b>3</b>.<b>114</b> may be re-calculated. The server update verification <b>3</b>.<b>180</b> may then be transmitted to the device <b>3</b>.<b>104</b>B as an acknowledgment of receipt and assembly of the identity claim record <b>3</b>.<b>116</b>. Similarly, the device update verification <b>3</b>.<b>185</b> may acknowledge receipt of the server update verification <b>3</b>.<b>190</b>. The device and the server <b>1</b>.<b>106</b> may then proceed with the hastory commit <b>3</b>.<b>190</b> and the profile hastory commit <b>3</b>.<b>195</b>. If either of the server update verification <b>3</b>.<b>180</b> or the device update verification <b>3</b>.<b>185</b> are not properly received, the authentication transaction may be rolled back such that the neither the profile hastory <b>3</b>.<b>112</b> or the device hastory <b>3</b>.<b>108</b> evolve. In such case the device may be required to re-submit a second identity claim <b>3</b>.<b>120</b> in a second authentication attempt. Although not shown in the embodiment of <figref idref="DRAWINGS">FIG. 3.1</figref>, an optional transaction with an application profile (e.g., the application profile <b>2</b>.<b>1105</b> of <figref idref="DRAWINGS">FIG. 2.11</figref>) may occur between the user profile <b>3</b>.<b>106</b> and an application hastory (e.g., the application hastory <b>2</b>.<b>1106</b>), as shown in the process flow of <figref idref="DRAWINGS">FIG. 3.8</figref>. In such case an identity update <b>3</b>.<b>150</b> comprising data usable to assemble a resulting transaction record <b>2</b>.<b>302</b> may be sent from the server <b>3</b>.<b>106</b> and/or a different server to the device <b>1</b>.<b>104</b>B, with the device assembling the resulting truncation record <b>2</b>.<b>302</b> before updating the device hastory <b>3</b>.<b>108</b> and verifying the update with the server <b>3</b>.<b>106</b>. Additionally, although shown stored on the device <b>3</b>.<b>104</b>B, the device profile <b>3</b>.<b>110</b> may alternatively or in addition reside on the device <b>3</b>.<b>104</b>A.

<figref idref="DRAWINGS">FIG. 3.2</figref> is a multi-factor login process flow <b>3</b>.<b>200</b> of the multi-factor login <b>3</b>.<b>120</b> of <figref idref="DRAWINGS">FIG. 3.1</figref>, according to one or more embodiments. Operation <b>3</b>.<b>202</b> receives a login request through the network <b>1</b>.<b>101</b>, the login request received from a first device (e.g., the device <b>3</b>.<b>104</b>A of <figref idref="DRAWINGS">FIG. 3.1</figref>) referred to in <figref idref="DRAWINGS">FIG. 3.2</figref> as ‘device A’. The login request may be generated from a particular application program on the first device such as an enterprise application where the first device is a desktop computer, or a streaming music app where the first device is a mobile device. The login request may include data identifying the first device, the application program, and/or a user of the first device. A first server, referred to in <figref idref="DRAWINGS">FIG. 3.2</figref> as ‘server A’ may generate a token X in operation <b>3</b>.<b>204</b> and return the token X through the network <b>1</b>.<b>101</b> to the first device in operation <b>3</b>.<b>206</b>. The application program generating the login request and/or a separate application program referred to as a profile process (e.g., an application program for identity management) may then generate a token Y in operation <b>3</b>.<b>208</b>.

In operation <b>3</b>.<b>210</b>, the first device transmits the token X and the token Y through the network <b>1</b>.<b>101</b>B to a second device (e.g., the device <b>3</b>.<b>104</b>B of <figref idref="DRAWINGS">FIG. 3.1</figref>), referred to as a ‘device B’ in <figref idref="DRAWINGS">FIG. 3.2</figref>. The token Y may be an identifier of the first device and token X may include data identifying the user of the first device. The network <b>1</b>.<b>101</b>B can be, for example, a Bluetooth® or near-field communication connection between the first device and the second device. In operation <b>3</b>.<b>212</b>, the second device determines whether token Y is associated with a user profile (e.g., the user profile <b>3</b>.<b>114</b>) of the user of the first device. If not, operation <b>3</b>.<b>214</b> generates and error message and/or terminates the multi-factor login <b>3</b>.<b>118</b>. If a profile association is determined, in operation <b>3</b>.<b>216</b> the second device transmits the token X and the token Y to a second server (e.g., the server <b>3</b>.<b>106</b>), referred to in <figref idref="DRAWINGS">FIG. 3.2</figref> as ‘server B.’ The transmission between the second device and the second server may occur through the network <b>1</b>.<b>101</b> over a separate channel than a channel carrying communication between the first device and the first server. Although now shown, data of the identity claim <b>3</b>.<b>120</b> may be transmitted during this operation as well. In operation <b>3</b>.<b>218</b>, the second server may determine whether the token Y is associated with a valid user profile. If not, operation <b>3</b>.<b>218</b> may proceed to operation <b>3</b>.<b>214</b>. If there is a valid association, operation <b>3</b>.<b>218</b> may proceed to operation <b>3</b>.<b>220</b>, in which the second server transmits token X to the first server through the network <b>1</b>.<b>101</b> (e.g., a LAN and/or a WAN behind a firewall).

<figref idref="DRAWINGS">FIG. 3.3</figref> is the multi-factor login process <b>3</b>.<b>200</b> of <figref idref="DRAWINGS">FIG. 3.2</figref> continued as the multi-factor login process <b>3</b>.<b>300</b>, according to one or more embodiments. After the first server receives the token X from the second server, the first server determines according to operation <b>2</b>.<b>222</b> whether the first server issued the token X and whether the token X remains valid (e.g., has not expired). If the token X received by the first server was not issued (e.g., it is a third token Z of unknown origin) and/or the token X has expired, operation <b>2</b>.<b>222</b> may proceed to generate an error message and terminate login in accordance to operation <b>3</b>.<b>214</b>. Otherwise, in accordance with operation <b>2</b>.<b>224</b>, the first server transmits data to the second server to indicate that a token was issued to a particular user by transmitting an identifier of the particular user. In operation <b>2</b>.<b>226</b>, the second server verifies that a user profile is associated with the identifier of the particular user, and if not proceeds to operation <b>3</b>.<b>214</b>. If the second server determines that a user profile is associated with the particular user, the second server transmits data of the user profile of the particular user to the first server in operation <b>2</b>.<b>228</b>. In accordance with operation <b>2</b>.<b>230</b>, the first server then transmits a login token to the first device. As a result, a secure channel and/or a secure socket between the first device and the first server may then be established. The device and the server may exchange cryptographic keys in a Diffie-Hellman key exchange that may be a specific method for securely exchanging the cryptographic keys over a public communication channel (e.g., the network <b>1</b>.<b>101</b>).

<figref idref="DRAWINGS">FIG. 3.4</figref> is an authentication process flow <b>3</b>.<b>400</b> illustrating a process by which the device <b>3</b>.<b>104</b>A of <figref idref="DRAWINGS">FIG. 3.1</figref> may be securely authenticated using un-forgeable identity credentials that define a fourth authentication factor based on a transaction history of the device (e.g., the device <b>3</b>.<b>104</b>A, the device <b>3</b>.<b>104</b>B) and a user profile (e.g., the user profile <b>3</b>.<b>114</b>) associated with the device, according to one or more embodiments. Operation <b>3</b>.<b>402</b> receives an authentication request from a first device (e.g., the device <b>3</b>.<b>104</b>A) to access a service and/or a datastore (e.g., the datastore <b>1</b>.<b>114</b>). For example, the authentication request may be generated from an application program on the device <b>3</b>.<b>104</b>A. Operation <b>3</b>.<b>404</b> receives an identity claim <b>3</b>.<b>120</b> from the first device and/or a second device (e.g., the device <b>3</b>.<b>104</b>B) associated with the first device (e.g., under the control of the same user and/or sharing LAN and/or a Bluetooth® connection), the identity claim <b>3</b>.<b>120</b> comprising a device root hash <b>3</b>.<b>602</b> computed by a hash function. The hash function may use inputs comprising a previous transaction record <b>3</b>.<b>402</b> along with a previous hash value <b>2</b>.<b>306</b> of a hastory of the device, referred to as a device hastory <b>3</b>.<b>108</b>. The identity claim <b>3</b>.<b>120</b> in one or more preferred embodiments is made by the device <b>3</b>.<b>104</b>B over a channel that different than a primary channel of communication between the device <b>3</b>.<b>104</b>A and the server <b>3</b>.<b>102</b>. The primary channel, for example, may be used by the application program to receive one or more data resources (e.g., by the data stream <b>4</b>.<b>180</b> of <figref idref="DRAWINGS">FIG. 4.1</figref>). Operation <b>3</b>.<b>406</b> retrieves data of a user profile <b>3</b>.<b>114</b> associated with the first device <b>3</b>.<b>104</b>A and/or the user <b>3</b>.<b>303</b> of the first device <b>3</b>.<b>104</b>A, the user profile <b>3</b>.<b>114</b> including a profile hastory <b>3</b>.<b>112</b> including a profile root hash <b>3</b>.<b>600</b> computed by the hash function using inputs comprising the previous transaction record <b>3</b>.<b>402</b> along with a penultimate hash value <b>2</b>.<b>308</b> of the profile hastory <b>3</b>.<b>112</b>. Operation <b>3</b>.<b>408</b> extracts the profile root hash <b>3</b>.<b>600</b> from the user profile <b>3</b>.<b>114</b> associated with the device <b>3</b>.<b>104</b>A and/or the user <b>3</b>.<b>303</b> of the device <b>3</b>.<b>104</b>A. Operation <b>3</b>.<b>410</b> compares the device root hash <b>3</b>.<b>602</b> of the device hastory <b>3</b>.<b>108</b> with the profile root hash <b>3</b>.<b>600</b> of the profile hastory <b>3</b>.<b>112</b> to verify an identity of the device <b>3</b>.<b>104</b>A and/or the user <b>3</b>.<b>303</b> of the device <b>3</b>.<b>104</b>A. Operation <b>3</b>.<b>412</b> determines that the device root hash <b>3</b>.<b>602</b> and the profile root hash <b>3</b>.<b>600</b> are identical. Finally, operation <b>3</b>.<b>414</b> validates the identity of the device <b>3</b>.<b>104</b>A and/or the user <b>3</b>.<b>303</b> of the device <b>3</b>.<b>104</b>A.

<figref idref="DRAWINGS">FIG. 3.5</figref> is an identity evolution process flow <b>3</b>.<b>500</b> that illustrates a process for evolving both the profile hastory <b>3</b>.<b>114</b> and the device hastory <b>3</b>.<b>108</b> in parallel to synchronize their identities for comparison in a subsequent authentication request, according to one or more embodiments. Operation <b>3</b>.<b>502</b> receives data usable to assemble a transaction record of the identity claim <b>3</b>.<b>120</b> (referred to as the identity claim record <b>3</b>.<b>116</b> in <figref idref="DRAWINGS">FIG. 3.1</figref>) generated by the device <b>3</b>.<b>104</b>A. In one preferred embodiment, operation <b>3</b>.<b>502</b> receives portions of the data usable to assemble the identity claim record <b>3</b>.<b>116</b> from two or more sources and/or over two or more channels. For example, a first portion of data usable to assemble the identity claim record <b>3</b>.<b>116</b> may be received over a first channel (e.g., a first channel of the network <b>1</b>.<b>101</b>E of <figref idref="DRAWINGS">FIG. 3.1</figref>) and a second portion of data usable to assemble the identity claim record <b>3</b>.<b>116</b> may be received over a second channel (e.g., the second channel of the network <b>1</b>.<b>101</b>C of <figref idref="DRAWINGS">FIG. 3.1</figref>). In such case, the first portion of the data usable to assemble the identity claim record <b>3</b>.<b>116</b> may be transmitted from the device <b>3</b>.<b>104</b>B to the device <b>3</b>.<b>104</b>A for re-transmission to the server <b>3</b>.<b>106</b> (e.g., through the network <b>1</b>.<b>101</b>E of <figref idref="DRAWINGS">FIG. 3.1</figref>). Operation <b>3</b>.<b>504</b> assembles the transaction record of the identity claim (e.g., the identity claim record <b>3</b>.<b>116</b>) generated by the device <b>3</b>.<b>104</b>B. Operation <b>3</b>.<b>504</b> assembles the identity claim record <b>3</b>.<b>116</b> to yield an identical instance of the identity claim record <b>3</b>.<b>116</b> generated on the device <b>3</b>.<b>104</b>B. For example, the identity claim record <b>3</b>.<b>116</b> may be assembled according to a procedure that will yield a virtually identical identity claim record <b>3</b>.<b>116</b> as produced on the device <b>3</b>.<b>104</b>B. Operation <b>3</b>.<b>506</b> deposits the transaction record of the identity claim in a new block <b>4</b>.<b>404</b> of the sequential chain of blocks <b>4</b>.<b>400</b> of a profile hastory <b>3</b>.<b>112</b>. For example, the data of the assembled identity claim record <b>3</b>.<b>116</b> may be placed into the data structure of the sequential chain of blocks <b>4</b>.<b>400</b> as an instance of a transaction record <b>2</b>.<b>302</b> of <figref idref="DRAWINGS">FIG. 4.2</figref>. The data structure, according to one or more embodiments, may be the hash chain of <figref idref="DRAWINGS">FIG. 2.3</figref> or the Merkle tree of <figref idref="DRAWINGS">FIG. 2.4</figref>. Operation <b>3</b>.<b>508</b> computes a new profile root hash (e.g., a new instance of the root hash <b>2</b>.<b>310</b> of <figref idref="DRAWINGS">FIG. 3.6</figref>) with a hash function using as inputs the profile root hash (e.g., the profile root hash <b>3</b>.<b>600</b> of <figref idref="DRAWINGS">FIG. 3.6</figref>) and the transaction record of the identity claim (e.g., the identity claim record <b>3</b>.<b>116</b>), to evolve the identity of the user profile <b>3</b>.<b>114</b>. Operation <b>3</b>.<b>510</b>, <b>3</b>.<b>512</b> and <b>3</b>.<b>514</b> may implement a two-phase commit process. The two phase commit process may be a distributed algorithm that coordinates a distributed atomic transaction on whether to commit or abort (e.g., roll back) the computation of the new profile root hash <b>3</b>.<b>600</b> and/or the new device root hash <b>3</b>.<b>602</b>. Specifically, operation <b>3</b>.<b>510</b> transmits a verification of an identity update of the user profile <b>3</b>.<b>114</b> (e.g., server update verification <b>3</b>.<b>180</b> of <figref idref="DRAWINGS">FIG. 3.1</figref>) to the first device (e.g., the device <b>3</b>.<b>104</b>A) and/or the second device (e.g., the device <b>1</b>.<b>104</b>B). The verification of the identity update may include a simple indicator that assembly of the identity claim record <b>3</b>.<b>116</b> was successful. The indicator may itself include a different hash value of a different hash function that may selectively hash only the data of the assembled identity claim record <b>3</b>.<b>116</b>. The verification of the identity update may also include additional data such as a time at which the identity claim record <b>3</b>.<b>116</b> was assembled and/or added to the profile hastory <b>3</b>.<b>112</b>. Following transmission of the verification of the identity update, e.g., by the server, the device <b>3</b>.<b>104</b>A and/or the device <b>3</b>.<b>104</b>B may likewise generate a verification of receive of the verification of the identity update made by the server and/or a verification of an identity update of the first device and/or the second device (e.g., device update verification <b>3</b>.<b>185</b> of <figref idref="DRAWINGS">FIG. 3.1</figref>). Operation <b>3</b>.<b>512</b> then receives a verification of an identity update of the first device <b>3</b>.<b>104</b>A and/or the second device <b>3</b>.<b>104</b>B. Operation <b>3</b>.<b>514</b> commits the new profile root hash <b>3</b>.<b>600</b> of the profile hastory <b>3</b>.<b>113</b>, to synchronize the identity of the user profile <b>3</b>.<b>114</b> with the identity of the device profile <b>3</b>.<b>108</b> of the first device (e.g., the device <b>3</b>.<b>104</b>A) and/or the second device (e.g., the device <b>3</b>.<b>104</b>B).

<figref idref="DRAWINGS">FIG. 3.6</figref> is a profile hastory and device hastory view <b>3</b>.<b>650</b> illustrating a detailed view of the sequential chain of blocks <b>2</b>.<b>300</b> of the profile hastory <b>3</b>.<b>112</b> with transactions records <b>2</b>.<b>302</b>A through <b>2</b>.<b>302</b>D including a profile data <b>3</b>.<b>604</b>, an identity claim record <b>3</b>.<b>116</b>B of a login transaction, an identity claim record <b>3</b>.<b>116</b>C of a data use transaction, and an identity claim record <b>3</b>.<b>116</b>C of a log out transaction, according to one or more embodiments. <figref idref="DRAWINGS">FIG. 3.6</figref> shows an instance of the hastory of <figref idref="DRAWINGS">FIG. 2.3</figref> usable for the authentication process and/or the real-time authentication process associated with an authorization request, as shown and described in conjunction with <figref idref="DRAWINGS">FIG. 4.1</figref>. The genesis block <b>2</b>.<b>303</b>A may include, for example, the transaction record <b>2</b>.<b>302</b>A including the profile data <b>3</b>.<b>604</b> used in creating the user profile <b>3</b>.<b>114</b> associated with the hastory <b>3</b>.<b>112</b> of <figref idref="DRAWINGS">FIG. 3.6</figref>. The hash value <b>2</b>.<b>306</b>A may include as inputs the data of the transaction record <b>2</b>.<b>302</b>A such as the profile data <b>3</b>.<b>604</b>. The hash value <b>2</b>.<b>306</b>A, the genesis block <b>2</b>.<b>303</b>A and/or any other data of the profile hastory <b>3</b>.<b>112</b> may be communicated to the device <b>3</b>.<b>104</b>A and/or <b>3</b>.<b>104</b>B to initiate the device hastory <b>3</b>.<b>108</b>, setting up an initial synchronization between the identity of the user profile <b>3</b>.<b>114</b> and the device profile <b>3</b>.<b>110</b>. The device profile <b>3</b>.<b>110</b> may represent a user (e.g., the user <b>3</b>.<b>303</b> of <figref idref="DRAWINGS">FIG. 3.1</figref>) and/or the device <b>3</b>.<b>104</b>A and/or the device <b>3</b>.<b>104</b>B.

A set of blocks <b>2</b>.<b>304</b>B through <b>2</b>.<b>304</b>D may be added the after genesis block <b>2</b>.<b>303</b>A for each of several identity claims (e.g., one or more of the identity claims <b>3</b>.<b>120</b> of <figref idref="DRAWINGS">FIG. 3.1</figref>) made by the device profile <b>3</b>.<b>110</b> against the user profile <b>3</b>.<b>114</b>. For example: the identity claim record <b>3</b>.<b>116</b>B may be added as the transaction record <b>2</b>.<b>302</b>B when the user <b>3</b>.<b>303</b> and/or the device <b>3</b>.<b>104</b>A logs in to the server <b>3</b>.<b>102</b> (e.g., to use a service and/or the datastore <b>1</b>.<b>114</b>): the identity claim record <b>3</b>.<b>116</b>C may be added when the user <b>3</b>.<b>303</b> and/or the device <b>3</b>.<b>104</b>A submits an authorization request to use a data resource of the datastore <b>1</b>.<b>114</b> (e.g., the authorization request of <figref idref="DRAWINGS">FIG. 3.7</figref> and/or the use request <b>4</b>.<b>130</b> of <figref idref="DRAWINGS">FIG. 4.1</figref>); and, the identity claim record <b>3</b>.<b>116</b>D may be added when the user <b>3</b>.<b>303</b> and/or the device <b>1</b>.<b>104</b>A completes a log out transaction from the server <b>3</b>.<b>102</b> and/or the datastore <b>1</b>.<b>114</b>. A most recently computing hash value of the profile hastory <b>3</b>.<b>112</b> such as the hash value <b>2</b>.<b>306</b>D is referred to as the profile root hash <b>3</b>.<b>600</b> which may be analogous to the root hash <b>2</b>.<b>310</b> of <figref idref="DRAWINGS">FIG. 2.3</figref>. The profile root hash <b>3</b>.<b>600</b> is computed using a hash function with inputs comprising a most recent transaction record <b>2</b>.<b>302</b> (which in the embodiment of <figref idref="DRAWINGS">FIG. 3.6</figref> is the transaction record <b>2</b>.<b>302</b>D) along with a penultimate hash <b>2</b>.<b>308</b> (which in the embodiment of <figref idref="DRAWINGS">FIG. 3.6</figref> is hash value <b>2</b>.<b>406</b>C). When a new transaction record (e.g., a transaction record <b>3</b>.<b>402</b>E, not shown in the embodiment of <figref idref="DRAWINGS">FIG. 3.6</figref>) is added to the sequential chain of blocks <b>2</b>.<b>300</b>, the profile root hash <b>3</b>.<b>600</b> becomes a new instance of the penultimate hash <b>2</b>.<b>308</b>, and the penultimate hash <b>2</b>.<b>308</b> prior to addition of the new transaction record ceases to be an instance of the penultimate hash <b>2</b>.<b>308</b>.

The device profile <b>3</b>.<b>110</b> comprising the device hastory <b>3</b>.<b>108</b> is stored on the device <b>3</b>.<b>104</b>A and/or the device <b>3</b>.<b>104</b>B. In one embodiment, the device hastory <b>3</b>.<b>108</b> may include a complete set of blocks <b>2</b>.<b>304</b> back to the genesis block <b>2</b>.<b>303</b>A. However, as shown in <figref idref="DRAWINGS">FIG. 3.6</figref> the device hastory <b>3</b>.<b>108</b> may be an attenuated version of the profile hastory <b>3</b>.<b>112</b> that includes only the most recent transaction record <b>3</b>.<b>402</b> (here, the transaction record <b>3</b>.<b>402</b>D) along with the most recent hash value (referred to within the device hastory <b>3</b>.<b>108</b> as the device root hash <b>3</b>.<b>602</b>). The profile root hash <b>3</b>.<b>600</b> and the device root hash <b>3</b>.<b>602</b> are identical when the profile hastroy <b>3</b>.<b>112</b> and the device hastory <b>3</b>.<b>108</b> are synchronized (e.g., the identities of user profile <b>3</b>.<b>114</b> and the device profile <b>3</b>.<b>110</b> are aligned). The device <b>3</b>.<b>104</b>A and/or the device <b>3</b>.<b>104</b>B may generate a new instance of the transaction record <b>3</b>.<b>402</b> (for example a transaction record <b>3</b>.<b>402</b>E, not shown in the embodiment of <figref idref="DRAWINGS">FIG. 3.6</figref>) at the time that the user <b>3</b>.<b>303</b>, the device <b>3</b>.<b>104</b>A and/or the device <b>3</b>.<b>104</b>B make an identity claim <b>3</b>.<b>120</b> against the user profile <b>3</b>.<b>114</b> according to the identity update <b>3</b>.<b>150</b>. The device <b>3</b>.<b>104</b>A and/or <b>3</b>.<b>104</b>B then transmits data of the transaction record of the identity claim <b>3</b>.<b>120</b> through one or more channels to be re-assembled and placed in a new block <b>2</b>.<b>304</b> of the profile hastory <b>3</b>.<b>112</b>. Although not shown in the figures, in one or more embodiments a “reverse” identity update (e.g., similar to the identity update <b>3</b>.<b>150</b>) may be transmitted from one or more servers that generated the identity claim record <b>3</b>.<b>116</b> to the device <b>3</b>.<b>104</b>A and/or the device <b>3</b>.<b>104</b>B.

<figref idref="DRAWINGS">FIG. 3.7</figref> is an real-time authentication process flow <b>3</b>.<b>700</b> illustrating a process by which the device <b>3</b>.<b>104</b>A of <figref idref="DRAWINGS">FIG. 3.1</figref> can submit to just-in-time authentication in association with an authorization request to utilize a data resource of the datastore <b>1</b>.<b>114</b> of <figref idref="DRAWINGS">FIG. 1.1</figref>, according to one or more embodiments. Operation <b>3</b>.<b>702</b> receives an authorization request, such as the use request <b>4</b>.<b>130</b> of <figref idref="DRAWINGS">FIG. 4.1</figref>, from a first device (e.g., the device <b>3</b>.<b>104</b>A) to utilize a data resource within a datastore of a server (e.g., the server <b>1</b>.<b>106</b>A of <figref idref="DRAWINGS">FIG. 1.1</figref>). For example, the utilization of a data resource may include downloading a file, deleting data of the data resource, or having data of the data resource temporarily streamed to the device <b>3</b>.<b>104</b>A for temporary use. The temporary use may include continuous monitoring and control of the data resource control network <b>1</b>.<b>100</b> as shown in the embodiments of <figref idref="DRAWINGS">FIG. 4.1</figref> through <figref idref="DRAWINGS">FIG. 4.12</figref>. Operation <b>3</b>.<b>704</b> receives an identity claim <b>3</b>.<b>120</b> from the first device and/or a second device (e.g., the device <b>3</b>.<b>104</b>B of <figref idref="DRAWINGS">FIG. 3.1</figref>) associated with the first device, the identity claim <b>3</b>.<b>120</b> including a device root hash <b>3</b>.<b>602</b> computed by a hash function dependent on a dataset that includes one or more transaction records (e.g., the transaction records <b>2</b>.<b>302</b>D of <figref idref="DRAWINGS">FIG. 2.4</figref> and/or <figref idref="DRAWINGS">FIG. 3.6</figref>) of previous identity claims <b>3</b>.<b>120</b>. Specifically, addition of an additional transaction record <b>2</b>.<b>302</b> and/or re-arrangement of an order of the transaction records <b>2</b>.<b>302</b> result in virtually unpredictable changes in the device root hash <b>3</b>.<b>602</b> and/or the profile root hash <b>3</b>.<b>600</b>. In operation <b>3</b>.<b>706</b>, a user profile <b>3</b>.<b>114</b> associated with at least one of the first device (e.g., the device <b>3</b>.<b>104</b>A) and a user (e.g., the <b>3</b>.<b>303</b>) of the first device is retrieved, the user profile including a profile hastory <b>3</b>.<b>114</b>. Operation <b>3</b>.<b>708</b> extracts the profile root hash <b>3</b>.<b>600</b> from the user profile <b>3</b>.<b>114</b> associated with the first device and/or the user of the first device. Specifically, for example, the server <b>3</b>.<b>106</b> may use computing processes to copy and place into physical memory a most recent instance of the hash value <b>2</b>.<b>306</b> of the chain of blocks <b>2</b>.<b>300</b> of the profile hastory <b>3</b>.<b>112</b>. Operation <b>3</b>.<b>708</b> may function similarly to operation <b>3</b>.<b>410</b> of <figref idref="DRAWINGS">FIG. 3.4</figref> to compare the device root hash <b>3</b>.<b>606</b> with the profile root hash <b>3</b>.<b>600</b> of the profile hastory <b>3</b>.<b>112</b> to verify an identity of the first device and/or the user of the first device. Operation <b>3</b>.<b>712</b> determines that the device root hash <b>3</b>.<b>602</b> and the profile hash value <b>3</b>.<b>600</b> are identical. Thereafter, the user and/or the first device may be authenticated, which may occur rapidly (e.g., within milliseconds) in association with authorizing utilization of the data resource may be authorized. The sever <b>3</b>.<b>102</b> and/or <b>3</b>.<b>106</b> may then proceed with an authorization process for example operation <b>3</b>.<b>714</b> that evaluates one or more permissions of the data resource in relation to the user profile <b>3</b>.<b>114</b> (such as read access, write access, or in one or more preferred embodiments the use controls shown and described in conjunction with <figref idref="DRAWINGS">FIG. 4.1</figref> through <figref idref="DRAWINGS">FIG. 4.12</figref>). While the use of the authentication process shown in <figref idref="DRAWINGS">FIG. 3.7</figref> may be used for real-time authentication in association with an authorization request, in one or more embodiments the authentication process may also result in a tradition token (e.g., an authentication authorization token) that may be communicated to the device <b>3</b>.<b>104</b>A and/or the device <b>3</b>.<b>104</b>B for use in a session of use with the datastore <b>1</b>.<b>114</b> and/or other services of one or more of the servers (e.g., the mediation server <b>1</b>.<b>102</b>).

<figref idref="DRAWINGS">FIG. 3.8</figref> is an application identity evolution process flow <b>3</b>.<b>800</b> showing a process whereby an identity claim <b>3</b>.<b>120</b> may be made by the device <b>3</b>.<b>104</b>A and/or the user profile <b>3</b>.<b>114</b> against an application profile <b>2</b>.<b>1105</b> of an application program, according to one or more embodiments. The application program may be any computer program such as an appliance, server software, consumer software such as a computer or social network app, an enterprise software application such as a calendar app and/or a word processing app. Within the datastore <b>1</b>.<b>114</b> the application program may be represented by an application profile <b>2</b>.<b>1105</b> including data about the application program in addition to a catalogue of data resources that are available to the application program. When utilization of a data resource is requested by the user (e.g. the user <b>3</b>.<b>303</b>) and/or the device (e.g., the device <b>3</b>.<b>104</b>), the server <b>3</b>.<b>106</b> may determine whether to make an identity claim (e.g., the identity claim <b>3</b>.<b>120</b>) from the user profile <b>3</b>.<b>114</b> against the application profile <b>2</b>.<b>1105</b> to determine whether the application program has previously interacted with the user <b>3</b>.<b>114</b> and/or the device. In operation <b>3</b>.<b>802</b>, an application profile <b>2</b>.<b>1105</b> is referenced, the application profile <b>2</b>.<b>1105</b> associated with the application program for which a protected resource is an application resource. An application resource is an instance of the data resource and/or the data organism <b>2</b>.<b>100</b> that is available to be addressed, accessed, and/or used within the datastore <b>1</b>.<b>114</b>. Operation <b>3</b>.<b>804</b> resolves an identity claim of the user profile in relation to the application profile by determining that the user profile <b>3</b>.<b>114</b> and the application profile both include a transaction record <b>2</b>.<b>302</b> that is identical within the profile hastory <b>3</b>.<b>112</b> and the application hastory. In contrast to the identity claim <b>3</b>.<b>120</b> of <figref idref="DRAWINGS">FIG. 3.1</figref>, the identity claim of process flow <b>3</b>.<b>800</b> may or may not utilize in an instance of the hash value <b>2</b>.<b>306</b> in the identity claim against the application profile <b>2</b>.<b>1105</b>. Rather, data and/or contents of one or more transaction records <b>2</b>.<b>302</b> of both the application profile <b>2</b>.<b>1105</b> and the user profile <b>3</b>.<b>114</b> are compared to determine that both have previously transitioned. If they have not previously interacted, for example, additional permissions may be required by the data resource control network <b>1</b>.<b>100</b>. Operation <b>3</b>.<b>806</b> deposits a transaction record <b>2</b>.<b>302</b> of the second identity claim in an application hastory <b>2</b>.<b>1106</b> of the application profile <b>2</b>.<b>1105</b>, and operation <b>3</b>.<b>808</b> computes an application root hash of the application hastory <b>2</b>.<b>1106</b> with the transaction record <b>2</b>.<b>302</b> of the identity claim made against the application profile, to evolve the identity of the application profile <b>2</b>.<b>1105</b>. For example, operations <b>3</b>.<b>806</b> and <b>3</b>.<b>808</b> may be also shown and described in the transaction of <figref idref="DRAWINGS">FIG. 2.11</figref>. Finally, if the profile hastory <b>2</b>.<b>114</b> is updated as a result of the identity claim against the application profile <b>2</b>.<b>1105</b>, operation <b>3</b>.<b>810</b> transmits to the device <b>3</b>.<b>104</b>A and/or the device <b>3</b>.<b>104</b>B data usable to assemble a transaction record of the identity claim (e.g., the identity claim record <b>3</b>.<b>116</b>) of the user profile <b>3</b>.<b>114</b> in relation to the application profile <b>2</b>.<b>1105</b>. Additional verification similar to operations <b>3</b>.<b>510</b> and <b>3</b>.<b>512</b> of process flow <b>3</b>.<b>500</b> may occur before commitment of the identity update <b>3</b>.<b>150</b> of the device <b>3</b>.<b>104</b>A, the device <b>3</b>.<b>104</b>B and/or the user profile <b>3</b>.<b>114</b>.

<figref idref="DRAWINGS">FIG. 3.9</figref> is a profile attack detection process flow <b>3</b>.<b>900</b> showing a process that invalidates forged identify credentials if the identity credentials are copied from the device <b>3</b>.<b>104</b>A and/or the device <b>3</b>.<b>104</b>B based on the evolution of the device hastory <b>3</b>.<b>108</b> and the profile hastory <b>3</b>.<b>112</b>, according to one or more embodiments. Operation <b>3</b>.<b>902</b> receives an authentication request and/or an authorization request from a device (e.g., the device <b>3</b>.<b>104</b>A) to login and/or to utilize a data resource within a datastore of a server (e.g., the server <b>3</b>.<b>102</b>). Operations <b>3</b>.<b>904</b> receives an identity claim <b>3</b>.<b>120</b> from the device <b>3</b>.<b>104</b>A and/or a device <b>3</b>.<b>104</b>B including a device root hash <b>3</b>.<b>602</b>. Operation <b>3</b>.<b>906</b> through <b>3</b>.<b>910</b> may occur similarly to operations <b>3</b>.<b>406</b> through <b>3</b>.<b>410</b> of <figref idref="DRAWINGS">FIG. 3.4</figref>, respectively. However, in contrast to the embodiment of <figref idref="DRAWINGS">FIG. 3.4</figref>, operation <b>3</b>.<b>412</b> determines that the device root hash <b>3</b>.<b>602</b> and the profile root hash <b>3</b>.<b>600</b> are different (e.g., not virtually identical such that they will result in a same hash value when used as an input to a particular hash function). As a result, operation <b>3</b>.<b>914</b> may deny the authentication request and/or the authorization request and operation <b>3</b>.<b>916</b> may optionally lock the user profile <b>3</b>.<b>114</b> to prevent prospective authentication attempts by the user <b>3</b>.<b>303</b>, the device <b>3</b>.<b>104</b>A, and/or the device <b>3</b>.<b>104</b>B. In the context of an enterprise, for example, an administrator of the datastore <b>1</b>.<b>114</b> may have to be contacted to unlock the user profile <b>3</b>.<b>114</b>, or an additional identity credential submitted over a different secure channel.

<figref idref="DRAWINGS">FIG. 3.10</figref> is a forged credential detection view <b>3</b>.<b>1050</b> showing a failed identity claim <b>3</b>.<b>1002</b> by an impersonator who cloned credentials from a device <b>3</b>.<b>104</b>A (e.g., such as a smartphone) of user <b>3</b>.<b>303</b>, the failed identity claim <b>3</b>.<b>1050</b> identified and optionally responded to by the process of <figref idref="DRAWINGS">FIG. 3.9</figref>, according to one or more embodiments. A section of a chain of blocks <b>2</b>.<b>300</b> of the profile hastory <b>3</b>.<b>104</b> is shown in <figref idref="DRAWINGS">FIG. 3.10</figref>, the chain of blocks <b>2</b>.<b>300</b> originating at an genesis block <b>2</b>.<b>304</b> (not show in the embodiment of <figref idref="DRAWINGS">FIG. 3.10</figref>). A device hastory <b>3</b>.<b>108</b>A is in an initial synchronized state with the profile hastory <b>3</b>.<b>104</b> after both the device <b>3</b>.<b>104</b> and the server <b>3</b>.<b>106</b> commit the transaction record <b>3</b>.<b>402</b>A (‘T<b>55</b>’). At the initial state, both the device root hash <b>3</b>.<b>602</b> and the profile hash <b>3</b>.<b>600</b> are equal to the hash value <b>2</b>.<b>306</b>A. The hash value <b>2</b>.<b>306</b>A is that included as inputs to a hash function a previous instance of the have value <b>2</b>.<b>306</b> (“H<b>54</b>”) along with the transaction record <b>3</b>.<b>402</b>A (“T<b>55</b>”). After the initial state, the user <b>3</b>.<b>303</b> and/or the device <b>3</b>.<b>104</b>A may make an identity claim <b>3</b>.<b>120</b>B against the profile hastory <b>3</b>.<b>104</b> by transmitting the device root hash <b>3</b>.<b>602</b> (then the hash value <b>2</b>.<b>406</b>A) to the server <b>3</b>.<b>106</b> to be compared to the profile root hash <b>3</b>.<b>600</b> stored in a user profile <b>3</b>.<b>114</b>. One or more servers (e.g., the server <b>3</b>.<b>106</b> of <figref idref="DRAWINGS">FIG. 3.1</figref>) may then effect one or more additional processes of the process flow <b>3</b>.<b>400</b> of <figref idref="DRAWINGS">FIG. 3.4</figref>, including the server update verification <b>3</b>.<b>180</b>B.

After the parallel synchronization of the device hastory <b>3</b>.<b>102</b>A and the profile hastory <b>3</b>.<b>104</b> to result in block <b>2</b>.<b>304</b>B, an impersonator <b>3</b>.<b>1001</b> (for example, a hacker) may find some way to copy a memory of the device <b>3</b>.<b>104</b>A through the credential cloning <b>3</b>.<b>1000</b>. The memory may is copied onto a device <b>3</b>.<b>104</b>X having a copied instance of the device hastory <b>3</b>.<b>108</b>A referred to as the device hastory <b>3</b>.<b>108</b>X. Additionally, the impersonator <b>3</b>.<b>1001</b> may have through some other means obtained the identity credentials of the device <b>3</b>.<b>104</b>A that may include the device root hash <b>3</b>.<b>602</b> and stored them on the device <b>3</b>.<b>104</b>X. At the time of the credential cloning <b>3</b>.<b>1000</b> in <figref idref="DRAWINGS">FIG. 3.10</figref> the device root hash <b>3</b>.<b>602</b> is equal to the hash value <b>2</b>.<b>306</b>B.

After the credential cloning <b>3</b>.<b>1000</b>, either the device <b>3</b>.<b>104</b>A or device <b>3</b>.<b>104</b>X may succeed at an identity claim <b>3</b>.<b>120</b>A. Where the user <b>3</b>.<b>303</b> makes the identity claim <b>3</b>.<b>120</b>C, the identity of the profile hastory <b>3</b>.<b>104</b> will evolve after addition of the block <b>4</b>.<b>404</b>C. The impersonator <b>3</b>.<b>1001</b> may then make an identify claim <b>3</b>.<b>104</b> that will fail (e.g., the failed identity claim <b>3</b>.<b>1002</b>) due to mismatch of the hash value <b>3</b>.<b>406</b>B with the hash value <b>3</b>.<b>406</b>C, for example per the process flow <b>3</b>.<b>900</b> of <figref idref="DRAWINGS">FIG. 3.9</figref>. The user <b>3</b>.<b>303</b> and/or an administrator of the datastore <b>1</b>.<b>114</b> may then be alerted as to the failed identity claim <b>3</b>.<b>1002</b>. The user profile <b>3</b>.<b>114</b> may also optionally be locked until an administrator of the datastore <b>1</b>.<b>114</b> can determine the cause of the failed identity claim <b>3</b>.<b>1002</b>. On the other hand, where the impersonator <b>3</b>.<b>1001</b> makes the identity claim <b>3</b>.<b>120</b>C before the user <b>3</b>.<b>303</b>, the user <b>3</b>.<b>303</b> may be alerted the next time the user <b>3</b>.<b>303</b> and/or the device <b>3</b>.<b>104</b>A attempts to transact with the profile hastory <b>3</b>.<b>104</b>. Additional processes may determine when to lock the user profile <b>3</b>.<b>114</b> as opposed to allow continued identity claims <b>3</b>.<b>120</b> to be made against the profile hastory <b>3</b>.<b>104</b> (in which case alerts may be generated and communicated to the user <b>3</b>.<b>303</b> and/or an administrator of the datastore <b>1</b>.<b>114</b>. According to the embodiment of <figref idref="DRAWINGS">FIG. 3.10</figref>, the identity credentials (e.g., the device root hash <b>3</b>.<b>602</b>) may act as a single-use identity credential usable for rapid authentication. The authentication transaction network <b>3</b>.<b>100</b> may lock out impersonators <b>3</b>.<b>1001</b> due to the parallel synchronized update of the identity of the device hastory <b>3</b>.<b>108</b>A and the identity of the profile hastory <b>3</b>.<b>112</b>.

The authentication transaction network <b>3</b>.<b>100</b> and associated processes as shown in the embodiments of <figref idref="DRAWINGS">FIG. 3.1</figref> through <figref idref="DRAWINGS">FIG. 3.11</figref> represents a number of advances in the first ‘A’ of the triple AAA framework, Authentication. To what may be considered the three standard authentication factors (what the user “knows,” what the user “has,” and/or what the user “is”), the authentication process disclosed adds a fourth authentication factor, what the “has been” or what the user “was.” This fourth authentication factor may be based on a history of interaction in between the user and/or a device, that history of transaction records forming the immutable record of transactions in the hashed history, referred to as a hastory. As a result, the authentication process may have a higher degree of certainty when verifying an identity and/or validating an identity claim of the use and/or the device.

At the same time, the datastore and/or services offered by one or more servers may retain two-factor authentication while not requiring either passwords (e.g., something the user knows) or biometrics (something the user has). Rather, the two-factor authentication may comprise what the user “has” (e.g., a first device such as a smartphone) and what the user “was” (e.g., the hastory that may be stored on both the first device, a second device, and/or one or more servers). The result may be a frictionless authentication process, for example where a user brings a first device under the user's control (e.g., a smartphone) into a close proximity with a second device (e.g., a desktop computer, a tablet) on which the user would like to access the datastore or a data resource.

In addition, use of the root hash of the hastory as an identity credential may eliminate general use and/or dependence passwords that may be especially susceptible to social engineering attacks. For example, a social engineer may have to possess one or more devices in order to authenticate in place of the user, unlike a password which once handed out to a social engineer may not be changed and allow access of both the user and the social engineer without detection.

The root hash of the hastory additionally increases security of the datastore by allowing the identity credentials of the device to be single use. As disclosed, the root hash may be communicated out-of-band from a primary channel used to communicate with the datastore, for example to request and receive data of a data resource, which may markedly decrease chances that the identity credentials will be intercepted. However, in the event identity credentials are obtained by an impersonator, for example through interception of the network or cloning of the device, the root hash may still represent an advantage of a session token and/or other identity credentials. Specially, an impersonator will be barred from interaction with the datastore if the true user makes even one more additional identity claim to a server of the authentication transaction network <b>3</b>.<b>100</b>.

Due to a relatively rapid comparison between the device root hash and the profile root hash, the authentication transaction network <b>3</b>.<b>100</b> may reduce computing overhead and permit real-time and/or “just-in-time” authentication that permits the device and/or a user of the device to be re-authenticated after a short period of time (a few seconds, a minute). Therefore, optionally authentication may occur with each interaction between the device <b>3</b>.<b>104</b>A and/or the server <b>3</b>.<b>102</b>, for example each request for a data resource and/or protected resource. As a result, it may be technically feasible set permissions for individual data resources based on an identity of the user and/or the device, permitting fine grain control of data resources within the datastore. For example, the data resource control network <b>1</b>.<b>100</b> may be able to scale to a large number of user of an enterprise (e.g., customers, employees) while still defining access and/or use controls of each individual data resource when necessary, rather than broad and potentially over-permissioned user groups. Data resources may also be particularly permission, reducing under-permissioning. The user requesting access to the datastore, utilization of data resources, and/or other electronic services is authenticated with a higher degree of certainty due to use of a fourth authentication factor, a hashed history forming an immutable transaction records in which the user participated.

<figref idref="DRAWINGS">FIG. 4.1</figref> is an authorization network <b>4</b>.<b>100</b> showing a set of servers (including the mediation server <b>1</b>.<b>102</b>, the key server <b>1</b>.<b>108</b>, the datamode microservice <b>1</b>.<b>130</b>, and the usermode microservice <b>1</b>.<b>140</b>) usable to authorize use of a protected resource by a device <b>1</b>.<b>104</b> and control use of the protected resource on the device <b>1</b>.<b>104</b> using a terms engine <b>1</b>.<b>112</b> (including a terms engine server-side <b>1</b>.<b>112</b>A and a terms engine device-side <b>1</b>.<b>112</b>B) according to a use policy <b>4</b>.<b>108</b>, according to one or more embodiments. The authorization network <b>4</b>.<b>100</b> may operate in contrast to a server implementing a datastore with a hierarchical file system that may merely control access to data resources. Although not shown for clarity, each of the arrows in <figref idref="DRAWINGS">FIG. 4.1</figref> through <figref idref="DRAWINGS">FIG. 4.3</figref> represent communication over one or more instances of the network <b>1</b>.<b>101</b> (e.g., the internet, a WAN, a LAN), and each of the servers (e.g., the mediation server <b>1</b>.<b>102</b>, the usermode microservice <b>1</b>.<b>141</b>) and the device <b>1</b>.<b>104</b> are communicatively coupled by one or more instances of the network <b>1</b>.<b>101</b>. The authorization network <b>4</b>.<b>100</b> may be implemented as a part of the data resource control network <b>1</b>.<b>100</b>, work in coordination with the authentication transaction network <b>3</b>.<b>100</b>, and/or may be a distinct operating environment.

In <figref idref="DRAWINGS">FIG. 4.1</figref>, a device <b>1</b>.<b>104</b> transmits a use request <b>4</b>.<b>130</b> to a mediation server <b>1</b>.<b>102</b> to use a protected resource <b>4</b>.<b>102</b> of a datastore <b>1</b>.<b>114</b> (shown as the subject datastore <b>1</b>.<b>131</b> in <figref idref="DRAWINGS">FIG. 4.1</figref>). The protected resource <b>4</b>.<b>102</b> may be stored in a data node <b>4</b>.<b>104</b> of a non-hierarchical data structure <b>1</b>.<b>114</b>, and in one or more embodiments, a security node <b>4</b>.<b>110</b> may reference the data node. The use request <b>4</b>.<b>130</b> may include one or more pieces of data that identify which protected resource <b>4</b>.<b>102</b> is requested by the device <b>1</b>.<b>104</b>. For example, the use request <b>4</b>.<b>130</b> may include a security node identifier <b>4</b>.<b>112</b> (referred to as the SNID <b>4</b>.<b>112</b> in <figref idref="DRAWINGS">FIG. 4.1</figref>). A use policy retrieval <b>4</b>.<b>135</b> may be effected by the mediation server <b>1</b>.<b>102</b> to retrieve a use policy <b>4</b>.<b>108</b> associated with the protected resource <b>4</b>.<b>102</b>. The use policy <b>4</b>.<b>108</b> may be stored, for example, within the security node <b>4</b>.<b>110</b>, and therefore retrieved by the SNID <b>4</b>.<b>112</b> that may be submitted in the use request <b>4</b>.<b>130</b>. As shown and described in conjunction with <figref idref="DRAWINGS">FIG. 3.1</figref> through <figref idref="DRAWINGS">FIG. 3.10</figref>, the device <b>1</b>.<b>104</b> and/or a user of the device <b>1</b>.<b>104</b> may make an identity claim <b>3</b>.<b>120</b> against a user profile <b>3</b>.<b>114</b> associated with the device <b>1</b>.<b>104</b> and/or a user of the device <b>1</b>.<b>104</b>. The identity claim <b>3</b>.<b>120</b> may be to effect just-in-time authenticate the user and/or the device <b>1</b>.<b>104</b> as part of a request as described in conjunction with <figref idref="DRAWINGS">FIG. 3.7</figref>. The meditation server <b>1</b>.<b>102</b> may open a transaction record of a use transaction and evaluate the use policy <b>4</b>.<b>108</b> to determine whether an authorized context for use of the protected resource is present based on a set of contextual values that may be gathered and compared to one or more reference values by the mediation server <b>1</b>.<b>102</b> when executing the use policy <b>4</b>.<b>108</b>. For example, the mediation server <b>1</b>.<b>102</b> may evaluate a state dataset (e.g., the state dataset <b>4</b>.<b>200</b> of <figref idref="DRAWINGS">FIG. 4.2</figref>) from the device <b>1</b>.<b>104</b> to determine that the device <b>1</b>.<b>104</b> is, for example, within an authorized geospatial location and the use request <b>4</b>.<b>130</b> occurs within a permissible time. The mediation server <b>1</b>.<b>102</b> may then authorize access to the protected resource <b>4</b>.<b>102</b> and generate a set of use terms <b>4</b>.<b>116</b> that are delivered to the device <b>1</b>.<b>104</b> to be used by a terms engine device-side <b>1</b>.<b>112</b>B that monitors and enforces ephemerality of data of the protected resource <b>4</b>.<b>102</b>.

The authorization network <b>4</b>.<b>100</b> may then directly deliver the protected resource <b>4</b>.<b>102</b>, as described below or in one or more preferred embodiments may then use a key system to provide a level of indirection in redemption of a use key <b>4</b>.<b>118</b> to obtain data of the protected resource <b>4</b>.<b>102</b>. The key system may allow for dynamic load balancing and increase security by permitting control of one or more segments of the data of the protected resource <b>4</b>.<b>102</b>. In the key implementation, the mediation server <b>1</b>.<b>102</b> may generate a set of one or more use keys <b>4</b>.<b>118</b> and append a protected resource identifier <b>4</b>.<b>106</b> (e.g., as a value of the key) to each of the set of one or more use keys <b>4</b>.<b>118</b> to generate one or more key-identifier pairs <b>4</b>.<b>120</b> (e.g., key-value pairs). The key may be a unique set of alphanumeric characters generated by on or more of the servers. The key-identifier pairs <b>4</b>.<b>120</b> may be deposited in the key server <b>1</b>.<b>108</b> in a key deposition <b>4</b>.<b>140</b> and each may be associated with an expiration condition <b>4</b>.<b>122</b>. The use key <b>4</b>.<b>118</b> may be returned to the device <b>1</b>.<b>104</b> in the use key return <b>4</b>.<b>150</b>. The device <b>1</b>.<b>104</b> then submits the use key <b>4</b>.<b>150</b> in the redemption request <b>4</b>.<b>160</b>. The redemption request <b>4</b>.<b>160</b> may be transmitted, as shown in <figref idref="DRAWINGS">FIG. 4.1</figref>, to one or more servers (e.g., the datamode microservice <b>1</b>.<b>130</b>) running the datastore <b>1</b>.<b>114</b> (e.g., the subject datastore <b>1</b>.<b>131</b>). The one or more servers may then submit a key verification <b>4</b>.<b>170</b> to the key server <b>1</b>.<b>108</b> to verify that the use key <b>4</b>.<b>118</b> was issued. Upon verification, the key server <b>1</b>.<b>108</b> may extract the PRID <b>4</b>.<b>106</b> that is associated with the use key <b>4</b>.<b>118</b> and that identifies the protected resource <b>4</b>.<b>102</b>, and return the PRID <b>4</b>.<b>106</b> to the one or more servers (e.g., the datamode microservice <b>1</b>.<b>130</b>). A data stream <b>4</b>.<b>180</b> of data of the protected resource <b>4</b>.<b>102</b> may then be delivered to the device <b>1</b>.<b>104</b> and monitored in accordance, for example, with the device active data use process flow <b>4</b>.<b>1000</b> of <figref idref="DRAWINGS">FIG. 4.10</figref>. If active use of the data of the protected resource <b>4</b>.<b>102</b> ends and/or exceeds the authorized context of the use terms <b>4</b>.<b>116</b>, the terms engine device-side <b>1</b>.<b>112</b> may terminate use of the protected resource <b>4</b>.<b>102</b> and the mediation server <b>1</b>.<b>102</b> may close the open transaction record. The transaction record of the use by the device <b>1</b>.<b>104</b> may be recorded in one or more hastories of data organisms within the datastore <b>1</b>.<b>114</b>, as shown and described throughout this disclosure. In one or more embodiments the security node <b>4</b>.<b>110</b> and/or the data node <b>4</b>.<b>104</b> may be data organisms <b>2</b>.<b>100</b> and the protected resource <b>4</b>.<b>102</b> may be stored in the contained data <b>2</b>.<b>108</b> of each of the one or more data organisms <b>2</b>.<b>100</b>.

Each of the processes of the authorization network <b>4</b>.<b>100</b> will now be described. <figref idref="DRAWINGS">FIG. 4.2</figref> is a contextual authorization process <b>4</b>.<b>250</b> showing the authorization network <b>4</b>.<b>100</b> of <figref idref="DRAWINGS">FIG. 4.1</figref> receiving a use request <b>4</b>.<b>130</b> from the device <b>1</b>.<b>104</b>, processing an identity claim <b>3</b>.<b>120</b>, retrieving a use policy <b>4</b>.<b>108</b> to evaluate one or more contextual values, depositing a use key <b>4</b>.<b>118</b> in a key server <b>1</b>.<b>108</b>, and returning a use key <b>4</b>.<b>118</b> to the device <b>1</b>.<b>104</b>, according to one or more embodiments. The device <b>1</b>.<b>104</b> may store the SNID <b>4</b>.<b>112</b> of a security node <b>4</b>.<b>110</b> that stores the protected resource identifier <b>4</b>.<b>106</b> in a referential attribute <b>4</b>.<b>302</b>. When called, the security node <b>4</b>.<b>110</b> may deliver the use policy <b>4</b>.<b>108</b> to a source of the call (e.g., the mediation server <b>1</b>.<b>102</b>) and trigger evaluation of a use policy <b>4</b>.<b>108</b> that defines an authorized context for which use of the protected resource <b>4</b>.<b>102</b> is authorized. The SNID <b>4</b>.<b>112</b> may be obtained by previous interaction of the device <b>1</b>.<b>104</b> and the subject datastore <b>1</b>.<b>131</b>. For example, an application program of the device <b>1</b>.<b>104</b> may have previously been authorized to generally use data resources of the subject datastore <b>1</b>.<b>131</b> that are not protected by a use policy <b>4</b>.<b>108</b>. The device <b>1</b>.<b>104</b> may also include a state dataset <b>4</b>.<b>200</b> that may be dynamically updated and/or generated at the time the use request <b>4</b>.<b>130</b> is generated. The state dataset <b>4</b>.<b>200</b> may include data about a state of the device <b>1</b>.<b>104</b> such as a geospatial location, a user of the device <b>1</b>.<b>104</b> (e.g., the user <b>3</b>.<b>303</b>), an application program generating the use request <b>4</b>.<b>130</b>, a device ID identifying the device <b>1</b>.<b>104</b>, and/or a time at which the use request <b>4</b>.<b>130</b> was generated.

The use request <b>4</b>.<b>130</b> may include some identifier (e.g., a unique identifier) of a node within the subject datastore <b>1</b>.<b>131</b> that either directly includes the protected resource <b>4</b>.<b>102</b> or points to a data node <b>4</b>.<b>104</b> that includes the protected resource <b>4</b>.<b>102</b>. For example the SNID <b>4</b>.<b>112</b> may point to the data node <b>4</b>.<b>104</b>. The use request <b>4</b>.<b>130</b> may include the state dataset <b>4</b>.<b>200</b> and/or the device root hash <b>3</b>.<b>602</b>. The state dataset <b>4</b>.<b>200</b> and the device root hash <b>3</b>.<b>602</b> may be communicated over a first channel of the network <b>1</b>.<b>101</b> whereas the device root hash <b>3</b>.<b>602</b> may be communicated over a second channel of the network <b>1</b>.<b>101</b> including submission through a second device associated with the device <b>1</b>.<b>104</b>, as described in conjunction with <figref idref="DRAWINGS">FIG. 3.1</figref> through <figref idref="DRAWINGS">FIG. 3.10</figref>.

The mediation server <b>1</b>.<b>102</b> may receive the use request <b>4</b>.<b>130</b> over the network <b>1</b>.<b>101</b>, for example the internet and/or a WAN. The mediation server <b>1</b>.<b>102</b> may then communicate the SNID <b>4</b>.<b>112</b> to one or more datastore servers, for example the datamode microservice <b>1</b>.<b>130</b> comprising the subject datastore <b>1</b>.<b>131</b>, to retrieve the PRID <b>4</b>.<b>106</b> that may directly reference the data node <b>4</b>.<b>104</b>. The one or more datastore servers look up the security node <b>4</b>.<b>110</b> having a referential attribute <b>4</b>.<b>203</b> pointing to the data node <b>4</b>.<b>104</b> comprising the protected resource <b>4</b>.<b>102</b>. The security node <b>4</b>.<b>110</b> may reference the data node <b>4</b>.<b>104</b> by using the PRID <b>4</b>.<b>106</b> of the data node <b>4</b>.<b>104</b>. The security node <b>4</b>.<b>110</b> may also include a use policy <b>4</b>.<b>108</b>.

The use policy <b>4</b>.<b>108</b> comprises computer-readable instructions defining an authorized context for which the device <b>1</b>.<b>104</b> can use the protected resource <b>4</b>.<b>102</b>. The computer-readable instructions may include one or more contextual values that are called when the use policy <b>4</b>.<b>108</b> is evaluated by the mediation server <b>1</b>.<b>102</b>. For example, one of the contextual values may request a geospatial coordinate extracted from the state dataset <b>4</b>.<b>200</b> to be compared to predetermined value in the use policy <b>4</b>.<b>108</b>. Another of the contextual values may be called from an external dataset <b>4</b>.<b>202</b>. The external dataset <b>4</b>.<b>202</b> may include any data to be called that is not included within the state dataset <b>4</b>.<b>200</b> of the device <b>1</b>.<b>104</b> such as a data from a different data organism <b>2</b>.<b>100</b>, a different data resource, and/or an external API (e.g., a public demographic data, a sports score). For example, the contextual values may require that two professional sports scores from the Entertainment and Sports Programming Network (ESPN) are compared to one another. In the embodiment of <figref idref="DRAWINGS">FIG. 4.2</figref>, the use policy <b>1</b>.<b>08</b> defines the following authorized context: (1) the user associated with the device <b>1</b>.<b>104</b> must have an email address of foo@foo.com (which may be included within the user profile associated with the user); (2) the device <b>1</b>.<b>104</b> is located in North America; and, (3) that the time be between 8 PM Pacific Standard Time and 10 PM Pacific Standard Time. One or more of the contextual values may also require interaction from other users, for example by requiring affirmative manual authorization for use of the protected resource (e.g., from an IT administrator, from an executive of an enterprise). The computer-readable instructions that express the use policy <b>4</b>.<b>108</b> may be defined in a Turing-complete language.

The one or more datastore servers return the PRID <b>4</b>.<b>106</b> to the mediation server <b>1</b>.<b>102</b> along with the use policy <b>4</b>.<b>108</b>. The mediation server <b>1</b>.<b>102</b> then evaluates the use policy <b>4</b>.<b>108</b> by calling each of the one or more contextual values. For example, the email address of the user may be drawn from a user profile (e.g., the user profile <b>3</b>.<b>114</b>) associated with the device <b>1</b>.<b>104</b>, the time drawn from an internal clock of the mediation server <b>1</b>.<b>102</b>, and a location extracted from a geospatial coordinate generated by an operating system of the device <b>1</b>.<b>104</b> and communicated in the state dataset <b>4</b>.<b>200</b>. After determining the authorized context for which use of the protected resource <b>4</b>.<b>102</b> by the device <b>1</b>.<b>104</b> is present in association with the use request <b>4</b>.<b>130</b>, the mediation server <b>1</b>.<b>102</b> may generate one or more use keys (e.g., the use key <b>4</b>.<b>118</b>A, the use key <b>4</b>.<b>118</b>B), as shown in <figref idref="DRAWINGS">FIG. 4.2</figref>. The mediation server <b>1</b>.<b>102</b> may append the PRID <b>4</b>.<b>106</b> of the data node <b>4</b>.<b>104</b> to each of the one or more use keys <b>4</b>.<b>118</b> to form one or more key-identifier pairs <b>4</b>.<b>120</b> (e.g., the key-identifier pair <b>4</b>.<b>120</b>A, the key-identifier pair <b>4</b>.<b>120</b>B). More then one use key <b>4</b>.<b>118</b> may be utilized where the protected resource <b>4</b>.<b>102</b> is to be chunked and delivered in segments. For example, the data of the protected resource <b>4</b>.<b>102</b> may be broken into several segments, each of which may be given a segment identifier (e.g., the segment ID <b>4</b>.<b>302</b> of <figref idref="DRAWINGS">FIG. 4.3</figref>). The mediation server <b>1</b>.<b>102</b> may associate each segment ID <b>4</b>.<b>302</b> with each key-identifier pair <b>4</b>.<b>120</b> to form a key-identifier-segment triplet. The mediation server <b>1</b>.<b>102</b> may then associate an expiration condition <b>4</b>.<b>122</b> with each of the one or more key-value pairs <b>4</b>.<b>120</b> and/or key-identifier-segment triplet and then may deposit them in key deposition <b>4</b>.<b>140</b>, along with the expiration condition <b>4</b>.<b>122</b>, in the key server <b>1</b>.<b>108</b>. The expiration condition <b>4</b>.<b>122</b> may, for example, include data to indicate to a process of the key server <b>1</b>.<b>108</b> that the key-identifier pair <b>4</b>.<b>122</b> should be deleted after five seconds, one hour, and/or be deleted upon a happening of a specific event. The expiration condition <b>4</b>.<b>122</b> may even be short (e.g., one second) as the redemption request <b>4</b>.<b>160</b> may occur in a range of hundreds of milisecods. The same instance of the expiration condition <b>4</b>.<b>122</b> or different expiration conditions (e.g., an expiration condition <b>4</b>.<b>122</b>A, an expiration condition <b>4</b>.<b>122</b>B) may be appended to each of the key-identifier pairs <b>4</b>.<b>120</b>A. Additionally, one or more of the key-identifier pairs <b>4</b>.<b>122</b> may be automatically deleted regardless of the expiration condition after each has its associated PRID <b>4</b>.<b>106</b> called by the one or more datastore servers and extracted by the key server <b>1</b>.<b>108</b>, as shown in <figref idref="DRAWINGS">FIG. 4.3</figref>.

The terms engine server-side <b>1</b>.<b>112</b>A of the mediation server <b>1</b>.<b>102</b> may generate a use terms <b>4</b>.<b>116</b> comprising data instructing the terms engine device-side <b>1</b>.<b>112</b>B to conform with the authorized context. For example, the use terms <b>4</b>.<b>116</b> in the embodiment of <figref idref="DRAWINGS">FIG. 4.2</figref> may include data specifying that data of the protected resource <b>4</b>.<b>102</b> may be used between a set of geospatial coordinates (e.g., which may be determined by the mediation server <b>1</b>.<b>102</b> to specify a territory in North America) and between a time of 8 PM PCT to 10 PM PCT. The use terms <b>4</b>.<b>116</b> may be a succinct set of computer instructions usable by the device <b>1</b>.<b>104</b>, the terms engine server-side <b>1</b>.<b>112</b>A and/or the terms engine device-side <b>1</b>.<b>112</b>B to determine the set of permissible actions that a particular user and/or device may take in association with the data of the protected resource <b>4</b>.<b>102</b>. The use policy <b>4</b>.<b>108</b>, for example, may specify an authorized context with specifies several individual users and allows them use of data in different ways. A given use policy <b>4</b>.<b>108</b> may yield a first set of use terms <b>4</b>.<b>116</b>A for a first use request <b>4</b>.<b>130</b> of a first user <b>1</b>.<b>104</b>A and a second set of use terms <b>4</b>.<b>116</b>B for a second user <b>1</b>.<b>104</b>B. The first set of use terms <b>4</b>.<b>116</b>A may provide a “sub” authorized context based on geospatial constraints while the use terms <b>4</b>.<b>116</b>B may provide a different sub authorized context based on affirmative permission from an administrator or 30 second only use (e.g., sufficient time to read an abstract of a document). The mediation server <b>1</b>.<b>102</b> may then transmit, according to the key return <b>4</b>.<b>150</b>, a first use key <b>4</b>.<b>118</b>A, a route <b>4</b>.<b>206</b>A for the redemption of the first use key <b>4</b>.<b>118</b>A, and/or the set of use terms <b>4</b>.<b>116</b>.

<figref idref="DRAWINGS">FIG. 4.3</figref> is a controlled data delivery process <b>4</b>.<b>350</b> showing the contextual authorization network <b>4</b>.<b>100</b> of <figref idref="DRAWINGS">FIG. 4.2</figref> receiving a redemption request <b>4</b>.<b>160</b> comprising the use key <b>4</b>.<b>118</b>A, verifying the use key <b>4</b>.<b>118</b>A in the key server <b>1</b>.<b>108</b>, and streaming data of the protected resource <b>4</b>.<b>102</b> to the device, according to one or more embodiments. The device <b>1</b>.<b>104</b> transmits the use key <b>4</b>.<b>118</b>A to the one or more datastore servers that may include, for example, the datamode microservice <b>1</b>.<b>130</b>. The redemption request <b>4</b>.<b>160</b> may be made by way of the route <b>4</b>.<b>206</b>A (e.g., which may also be referred to as a redemption route) and returned to the device <b>1</b>.<b>104</b> by the mediation server <b>1</b>.<b>102</b>. For example, the route <b>4</b>.<b>206</b>A that may referred to as a redemption route may be a network address such as a media access control (MAC) address and/or an internet protocol (IP) address specifying a node of an instance of the network <b>1</b>.<b>101</b>. In addition to the redemption route a dynamic protocol designation may be conveyed that specifies which communications protocol to use in an interaction with one or more servers (e.g., the redemption). The one or more datastore servers may effect the key verification <b>4</b>.<b>170</b> that queries the key server <b>1</b>.<b>108</b> with the use key <b>4</b>.<b>118</b>A. If the use key <b>4</b>.<b>118</b>A is present (e.g., the expiration condition <b>4</b>.<b>122</b>A has not transpired), the key server <b>1</b>.<b>108</b> may return the PRID <b>4</b>.<b>106</b> and/or the segment ID <b>4</b>.<b>302</b>A to the one or more datastore servers. In addition, the key server <b>1</b>.<b>108</b> may return a use key <b>4</b>.<b>118</b>B of a second segment of the protected resource <b>4</b>.<b>102</b>, the second use key <b>4</b>.<b>118</b>B to be returned to the device <b>1</b>.<b>104</b> for use a second instance of the redemption request <b>4</b>.<b>160</b> (e.g., which may occur automatically when data the protected resource <b>4</b>.<b>108</b> as used by the device <b>1</b>.<b>104</b> reaches the end of a memory buffer of the device <b>1</b>.<b>104</b>). After receiving the PRID <b>4</b>.<b>106</b>, the segment identifier <b>4</b>.<b>302</b>A and/or the use key <b>4</b>.<b>118</b>B, the one or more datastore servers may then reference the data node <b>4</b>.<b>104</b> comprising the protected resource <b>4</b>.<b>102</b>, extract a segment matching the segment ID <b>4</b>.<b>302</b>A, and initiate the data stream <b>4</b>.<b>180</b> to the device <b>1</b>.<b>104</b> to effect a controlled delivery of a first segment of the protected resource <b>4</b>.<b>102</b>. The second use key <b>4</b>.<b>118</b>B and a new route <b>4</b>.<b>206</b>B may be communicated to the device <b>1</b>.<b>104</b> for the next redemption request <b>4</b>.<b>160</b>. As the data stream <b>4</b>.<b>180</b> is received, the device <b>1</b>.<b>104</b> may begin to monitor use of the data of the protected resource <b>4</b>.<b>102</b> with the terms engine device-side <b>1</b>.<b>112</b>B. In addition, the terms engine server-die <b>1</b>.<b>112</b>A may have an open transaction record <b>4</b>.<b>404</b> of a use transaction of the device <b>1</b>.<b>104</b>A to continue monitoring use of the data of the protected resource <b>4</b>.<b>102</b> until the use transaction is closed, as shown in <figref idref="DRAWINGS">FIG. 4.4</figref>.

<figref idref="DRAWINGS">FIG. 4.4</figref> is a terms engine view <b>4</b>.<b>450</b> showing the contextual authorization network <b>4</b>.<b>100</b> of <figref idref="DRAWINGS">FIG. 4.3</figref> monitoring use of and enforcing ephemerality of data of the protected resource <b>4</b>.<b>102</b> of <figref idref="DRAWINGS">FIG. 4.1</figref> through a device-side terms engine (e.g., the terms engine device-side <b>1</b>.<b>112</b>B) associated through the network <b>1</b>.<b>101</b> with a server-side terms engine (e.g., the terms engine server-side <b>1</b>.<b>112</b>A), according to one or more embodiments. In <figref idref="DRAWINGS">FIG. 4.4</figref>, the user <b>3</b>.<b>303</b>A may be using the device <b>1</b>.<b>104</b> to view and/or edit data of the protected resource <b>4</b>.<b>402</b> (for example, a document), listen to the protected resource <b>4</b>.<b>402</b> (for example, music) and/or view the protected resource <b>4</b>.<b>402</b> (for example, a video).

In the embodiment of <figref idref="DRAWINGS">FIG. 4.4</figref> the mediation server <b>1</b>.<b>102</b> includes the terms engine server-side <b>1</b>.<b>112</b>A having an open transaction record <b>4</b>.<b>404</b> of a set of use transactions that are currently active. For example, when the device <b>1</b>.<b>104</b>A is using the protected resource <b>4</b>.<b>102</b> the open transaction record <b>4</b>.<b>404</b> may include the use policy <b>4</b>.<b>108</b> associated with the protected resource <b>4</b>.<b>102</b> (e.g., from the security node <b>4</b>.<b>110</b>), the state dataset <b>4</b>.<b>200</b> of device <b>1</b>.<b>104</b> that may be communicated along with the use request <b>4</b>.<b>130</b> (and may also include the external dataset <b>4</b>.<b>202</b> assembled during evaluation of the use policy), and/or the use terms <b>4</b>.<b>116</b>A generated for the use request <b>4</b>.<b>130</b> of the device <b>1</b>.<b>104</b>. The open transaction record <b>4</b>.<b>404</b> may also include a use identifier <b>4</b>.<b>402</b>A specifying the use transaction that is open. Although now shown in the embodiment of <figref idref="DRAWINGS">FIG. 4.4</figref>, the open transaction record <b>4</b>.<b>404</b> may also include the PRID <b>4</b>.<b>102</b> of the protected resource <b>4</b>.<b>102</b> such that updates to the use policy <b>4</b>.<b>108</b> of the protected resource <b>4</b>.<b>102</b> may be matched to the open transaction record <b>4</b>.<b>404</b>. This may be useful, for example, to effect the policy update <b>4</b>.<b>501</b> shown in <figref idref="DRAWINGS">FIG. 4.5</figref>.

The terms engine device-side <b>1</b>.<b>112</b>B may include an active use ledger <b>4</b>.<b>400</b> specifying data of one or more protected resource <b>4</b>.<b>102</b> that is in active use by the device <b>1</b>.<b>104</b>. The terms engine device-side <b>1</b>.<b>112</b>B may be part of an application program running on the device <b>1</b>.<b>104</b> and/or may be a separate process running on the device that monitors use of the data of the protected resource <b>4</b>.<b>102</b> and/or enforces ephemerality of the protected resource <b>4</b>.<b>102</b> by erasing appropriate memory addresses within the device <b>1</b>.<b>104</b> when use of a particular protected resource <b>4</b>.<b>102</b> is ends and/or is terminated. In the embodiment of <figref idref="DRAWINGS">FIG. 4.4</figref> each piece of data may include the use identifier (e.g., the use identifier <b>4</b>.<b>402</b>A for the first segment of the protected resource <b>4</b>.<b>102</b>, the use identifier <b>4</b>.<b>402</b>B for a different protected resource <b>4</b>.<b>102</b>). For example, the application program on the device <b>1</b>.<b>104</b> may display a user interface to the first user <b>3</b>.<b>303</b>A that includes text (which may be a first protected resource <b>4</b>.<b>102</b>A) while simultaneously displaying an image (which may be a different protected resource <b>4</b>.<b>102</b>B). If the user <b>3</b>.<b>303</b>A switches to a different user interface view not displaying the text and/or the image, the active use may be determined by the terms engine device-side <b>1</b>.<b>112</b>B to have ended and the data of the protected resource <b>4</b>.<b>102</b> (e.g., associated with the use identifier <b>4</b>.<b>206</b>A) and/or the different protected resource (e.g., associated with the use identifier <b>4</b>.<b>402</b>B) may be scrubbed from memory one or more memory addresses of the device <b>1</b>.<b>104</b>. The terms engine device-side <b>1</b>.<b>112</b>B may also be configured to terminate active use of the data of one or more items monitored within the active use ledger <b>4</b>.<b>400</b> when a network connection (e.g., the network connection <b>1</b>.<b>101</b>) is lost or unreliable. The active use, for example, may be relatively frequent direct interaction (e.g., providing input such as typing or switching between screens every few seconds, minutes or hours). The active use may also be based, for example, upon a screen that is currently shown on a display of the device <b>1</b>.<b>104</b>, whether one or more application programs is analyzing data, and/or whether an audio track has been paused or a video volume muted. In addition, the terms engine device-side <b>1</b>.<b>112</b>B may terminate active use of one or more protected resources <b>4</b>.<b>102</b> where the state dataset <b>4</b>.<b>200</b> (which may be dynamically changing as time increases and/or the device <b>1</b>.<b>104</b> changes location) no longer conforms to one or more parameters and/or programmatic terms of the use terms <b>4</b>.<b>116</b> stored in the terms-engine device-side <b>1</b>.<b>112</b>B. Active monitoring by the device <b>1</b>.<b>104</b> is shown and described in conjunction with the process flow <b>4</b>.<b>1000</b> of <figref idref="DRAWINGS">FIG. 4.10</figref>. The mediation serer <b>1</b>.<b>102</b> may also instruct the device <b>1</b>.<b>104</b> to terminate active use of the data of one or more protected resources <b>4</b>.<b>102</b>, as shown and described in conjunction with <figref idref="DRAWINGS">FIG. 4.5</figref>.

<figref idref="DRAWINGS">FIG. 4.5</figref> is a real-time revocable authorization process <b>4</b>.<b>550</b> by which data of the protected resource <b>4</b>.<b>102</b> in active use by the device <b>1</b>.<b>104</b> may have use terminated based on an updated use policy <b>4</b>.<b>502</b> generated by a second user <b>3</b>.<b>303</b>B in control of the protected resource <b>4</b>.<b>102</b>, a termination notice <b>4</b>.<b>506</b> and/or a termination report <b>4</b>.<b>508</b> generated by the device <b>1</b>.<b>104</b> and transmitted to the mediation server <b>1</b>.<b>102</b> to close the use transaction, according to one or more embodiments. In <figref idref="DRAWINGS">FIG. 4.5</figref> a second user <b>3</b>.<b>303</b>B may communicate over an instance of the network <b>1</b>.<b>101</b> with one or more datastore servers containing the protected resource <b>4</b>.<b>102</b>, for example the subject datastore <b>1</b>.<b>131</b>, using the device <b>4</b>.<b>504</b> (e.g., a smartphone, a different server, a desktop computer, a notebook computer). The user <b>3</b>.<b>303</b>B may generate the policy update <b>4</b>.<b>501</b> that changes the use policy <b>4</b>.<b>502</b> defining the authorized context for which use of the protected resource is authorized. For example, the user <b>3</b>.<b>303</b>B may modify the use policy <b>4</b>.<b>108</b> of the security node <b>4</b>.<b>110</b> to define additional contextual values or changed values and/or additional parameters in which the contextual values are compared to define the authorized context.

Upon receipt of the updated use policy <b>4</b>.<b>502</b>, the one or more datastore servers may transmit the PRID <b>4</b>.<b>106</b> of the protected resource <b>4</b>.<b>102</b> receiving the policy update <b>4</b>.<b>501</b> to the key server <b>1</b>.<b>108</b>. They key server <b>1</b>.<b>108</b> may immediately expire all keys associated with the PRID <b>4</b>.<b>106</b>. The updated use policy <b>4</b>.<b>502</b> along with the PRID <b>4</b>.<b>106</b> associated with the update use policy <b>4</b>.<b>502</b> may be communicated through the network <b>1</b>.<b>101</b> in the mediation server <b>1</b>.<b>102</b> where it is matched with the open transaction record <b>4</b>.<b>404</b>. The terms engine server-side <b>1</b>.<b>112</b>A may then re-evaluate the updated use policy <b>4</b>.<b>502</b> using the stored state dataset <b>4</b>.<b>200</b> received by the mediation server <b>1</b>.<b>102</b> in association with of the use request <b>4</b>.<b>130</b>. The terms engine server-side <b>1</b>.<b>112</b>A may also query the device <b>1</b>.<b>104</b> for an update use policy <b>4</b>.<b>500</b> and re-evaluate the updated use policy <b>4</b>.<b>502</b> with the updated state dataset <b>4</b>.<b>500</b>. If the use by the device <b>1</b>.<b>104</b> no longer conforms to the authorized context based on the updated use policy <b>4</b>.<b>502</b>, the terms engine server-side <b>1</b>.<b>112</b>A may transmit a termination notice to the terms engine device-side <b>1</b>.<b>112</b>B to end use of the data of the protected resource <b>4</b>.<b>102</b>. Otherwise, the terms engine server-side <b>1</b>.<b>112</b> may generate the updated use terms <b>4</b>.<b>116</b> and transmit them through the network <b>1</b>.<b>101</b> to the device <b>1</b>.<b>104</b>. Once received by the device <b>1</b>.<b>104</b>, the updated use terms may replace the existing use terms (e.g., the updated use terms <b>4</b>.<b>516</b> may replace the use terms <b>4</b>.<b>116</b>A). The terms engine device-side <b>1</b>.<b>112</b>B may then continue to monitor active use of the data of the protected resource <b>4</b>.<b>102</b> for conformance with the updated use terms <b>4</b>.<b>516</b> that define the particular authorized context.

Where active use of the data of the protected resource <b>4</b>.<b>102</b> is terminated, the device <b>1</b>.<b>104</b> may generate a termination notice <b>3</b>.<b>406</b> and/or a termination report <b>4</b>.<b>508</b>. The termination notice <b>4</b>.<b>506</b> may be generated, for example, where the terms engine device-side determines that the use by the device <b>1</b>.<b>104</b> does not conform to the use terms <b>4</b>.<b>116</b> stored in the active use ledger <b>4</b>.<b>400</b>. The termination notice <b>4</b>.<b>506</b> may be transmitted through the network <b>1</b>.<b>101</b> to the mediation server <b>1</b>.<b>102</b>. Once received, the terms engine server-side <b>1</b>.<b>112</b>A may close the open transaction record <b>4</b>.<b>404</b> to end the use transaction. The termination notice <b>4</b>.<b>506</b> may also be generated when network connectivity is lost but may be late transmitted to the mediation server <b>1</b>.<b>102</b> when network connectivity is re-established. In addition to the termination notice <b>4</b>.<b>506</b>, the terms engine device-side may generate the termination report <b>4</b>.<b>508</b> specifying which actions the device <b>1</b>.<b>104</b> and/or the first user <b>3</b>.<b>303</b>A of the device <b>1</b>.<b>104</b> took outside the scope of the authorized context (e.g., against an applicable instance of the use terms <b>4</b>.<b>116</b>). The use transaction, which may include data of the termination report <b>4</b>.<b>508</b>, may be deposited in a block of one or more hastoreis <b>2</b>.<b>104</b> of one or more data organisms <b>2</b>.<b>100</b> in accordance with <figref idref="DRAWINGS">FIG. 2.1</figref> through <figref idref="DRAWINGS">FIG. 2.11</figref>. For example the use transaction record may be deposited as a transaction record <b>2</b>.<b>302</b> in a profile hastory <b>3</b>.<b>104</b> of a user profile <b>3</b>.<b>114</b> associated with the user <b>3</b>.<b>303</b>A and/or the user <b>3</b>.<b>303</b>B. The use transaction record may also be deposited in a file hastory <b>2</b>.<b>1104</b> (e.g., of the data node <b>4</b>.<b>104</b>), an application hastory <b>2</b>.<b>1106</b> associated with an application program for which the protected resource <b>2</b>.<b>102</b> is an application resource, and/or a hastory of the security node <b>4</b>.<b>110</b>. Where an identity of a user profile <b>3</b>.<b>114</b> associated with the device <b>1</b>.<b>104</b> and/or the user <b>3</b>.<b>303</b>A is updated, the mediation server <b>1</b>.<b>102</b> may transmit data usable to assemble the transaction record <b>4</b>.<b>402</b> of the use transaction through one or more channels to the device <b>1</b>.<b>104</b> to be assembled and used in evolving the identity of the device hastory <b>3</b>.<b>108</b> to yield a new device root hash <b>3</b>.<b>602</b>, as shown and described in conjunction with <figref idref="DRAWINGS">FIG. 3.1</figref> through <figref idref="DRAWINGS">FIG. 3.10</figref>.

In an alternate embodiment not shown in <figref idref="DRAWINGS">FIG. 4.1</figref> through <figref idref="DRAWINGS">FIG. 4.6</figref>, after determining the authorized context is present the mediation server <b>1</b>.<b>102</b> may authorize use of the protected resource <b>4</b>.<b>102</b> and effect the data stream <b>4</b>.<b>180</b> of <figref idref="DRAWINGS">FIG. 4.1</figref>. The terms engine device-side <b>1</b>.<b>112</b>B may automatically erase the data of the protected resource <b>4</b>.<b>102</b> according to a simple set of terms, for example after five seconds, when the data of the protected resource <b>4</b>.<b>102</b> is not in active use, and/or when a network connection is lost and/or unreliable.

<figref idref="DRAWINGS">FIG. 4.6</figref> is a use key generation process flow <b>5</b>.<b>600</b> illustrating a process by which the contextual values of the use policy <b>4</b>.<b>108</b> may be evaluated and the use key <b>4</b>.<b>118</b> of <figref idref="DRAWINGS">FIG. 4.2</figref> may be generated, according to one or more embodiments. Operation <b>4</b>.<b>602</b> receives a use request <b>4</b>.<b>130</b> from the device <b>1</b>.<b>104</b>. The use request <b>4</b>.<b>130</b>, for example, may be received by the mediation server <b>1</b>.<b>102</b> and/or a different server of the data resource control network <b>1</b>.<b>100</b>. Operation <b>4</b>.<b>604</b> may open a use transaction, for example by generating the open transaction record <b>4</b>.<b>404</b> within the terms-engine server-side <b>1</b>.<b>112</b>A. In operation <b>4</b>.<b>606</b>, the state dataset <b>4</b>.<b>200</b> is extracted from the use request <b>4</b>.<b>130</b>. For example, a device ID, an application program ID, one or more geospatial coordinates, an operating system of the device <b>1</b>.<b>104</b>, data related to use of data resources and/or additional data may be pulled from a protocol conveying the use request <b>4</b>.<b>130</b>. Operation <b>4</b>.<b>608</b> extracts a use policy <b>4</b>.<b>108</b> from one or more datastores <b>1</b>.<b>114</b>, for example from the data node <b>4</b>.<b>104</b> and/or the security node <b>4</b>.<b>110</b>. Operation <b>4</b>.<b>610</b> gathers one or more contextual values that may be present in the use policy <b>4</b>.<b>108</b>. The values of the contextual values may be draw from the state dataset <b>4</b>.<b>200</b> and/or the external dataset <b>4</b>.<b>202</b> (both of which may be collectively referred to as a contextual dataset). The external dataset <b>4</b>.<b>202</b> may be any data not received from or associated with the device <b>1</b>.<b>104</b>. For example, to assemble the external dataset <b>4</b>.<b>202</b> the mediation server <b>1</b>.<b>102</b> may retrieve values from one or more data resources and/or data organisms <b>2</b>.<b>100</b> (e.g., a service level associated with a user profile <b>3</b>.<b>114</b>), and/or values from sources outside the data resource control network <b>1</b>.<b>100</b>, such as weather events, government statistics, and/or values drawn from a distributed consensus network. Operation <b>4</b>.<b>612</b> may generate a set of use terms <b>4</b>.<b>116</b> from the use policy <b>4</b>.<b>108</b>, for example by evaluating computer-readable instructions of the use policy <b>4</b>.<b>108</b> and/or using data received by calling the contextual values to generate specific permissible use parameters for the use request <b>4</b>.<b>130</b>.

<figref idref="DRAWINGS">FIG. 4.7</figref> is a continued process flow <b>4</b>.<b>700</b> of the use key generation process flow <b>4</b>.<b>600</b> of <figref idref="DRAWINGS">FIG. 4.6</figref>, illustrating a process by which the contextual values of the use policy <b>4</b>.<b>108</b> may be evaluated and the use key <b>4</b>.<b>118</b> of <figref idref="DRAWINGS">FIG. 4.2</figref> may be generated, according to one or more embodiments. Operation <b>4</b>.<b>614</b> is a decision that determines whether use of data of the protected resource <b>4</b>.<b>102</b> by the device <b>1</b>.<b>104</b> conforms to the authorized context of the use policy <b>4</b>.<b>108</b>. For example, contextual values may be compared to value ranges using comparators within the computer-readable instructions of the use policy <b>4</b>.<b>108</b>. If the use request <b>4</b>.<b>130</b> does not conform to the authorized context, operation <b>4</b>.<b>616</b> may generate an error message that may be returned to the device <b>1</b>.<b>104</b>, and operation <b>4</b>.<b>618</b> may close the open transaction record <b>4</b>.<b>404</b> of the terms engine device-side <b>1</b>.<b>112</b>A. If use by the device <b>1</b>.<b>102</b> conforms to the authorized context, operation <b>4</b>.<b>620</b> determines whether the protected resource <b>4</b>.<b>102</b> is to be segmented. The data node <b>4</b>.<b>104</b>, the security node <b>4</b>.<b>110</b>, the use policy <b>4</b>.<b>108</b> and/or the data resource <b>4</b>.<b>102</b> may include data specifying how the data resource <b>4</b>.<b>102</b> is to be segmented. Alternatively, one or more servers may automatically segment the protected resource <b>4</b>.<b>104</b>, for example in ten second segments where the protected resource <b>4</b>.<b>102</b> is an audio file and/or individual paragraphs where the protected resource <b>4</b>.<b>102</b> is a text file (e.g., a segmented file in XML, format, a PDF, and/or a markdown file). If the data of the protected resource <b>4</b>.<b>102</b> is to be segmented, operation <b>5</b>.<b>624</b> generates two or more segment identifiers (e.g., the segment IDs <b>4</b>.<b>302</b> of <figref idref="DRAWINGS">FIG. 4.3</figref>) and operation <b>4</b>.<b>626</b> generates two or more use keys <b>4</b>.<b>118</b>, appends the PRID <b>4</b>.<b>106</b> to each of the two or more use keys to form two or more key-identifier pairs <b>4</b>.<b>120</b>, and the may further append the segment identifiers to form two or more key-identifier-segment triplets (which still comprises the key-identifier pair <b>4</b>.<b>120</b>). Where it is determined in operation <b>4</b>.<b>620</b> that protected resource <b>4</b>.<b>620</b> does not include segments, operation <b>4</b>.<b>622</b> generates a use key <b>4</b>.<b>118</b> and appends the PRID <b>4</b>.<b>106</b> to form a key-identifier pair <b>4</b>.<b>120</b>. Additional processes may then return one or more use keys <b>4</b>.<b>118</b> to the device <b>1</b>.<b>104</b> to be submitted in the redemption request <b>4</b>.<b>160</b> and to deposit the one or more key-identifier pairs <b>4</b>.<b>120</b> and/or key-identifier-segment triplets in the key-server <b>1</b>.<b>108</b> for the key verification <b>4</b>.<b>170</b>. However, in one or more other embodiments the keys need not be generated simultaneously. For example, a use key <b>4</b>.<b>118</b>B may be generated when a process of the device determines that data associated with a first segment (obtained by redemption of the first use key <b>4</b>.<b>118</b>A) is nearing the end of a memory buffer or otherwise required by the user.

<figref idref="DRAWINGS">FIG. 4.8</figref> is a use request evaluation process flow <b>4</b>.<b>800</b> showing a process for authorizing use of a protected resource <b>4</b>.<b>102</b> according to a set of computer-readable instructions of a use policy <b>4</b>.<b>108</b>, according to one or more embodiments. Operation <b>4</b>.<b>802</b> receives a use request <b>4</b>.<b>130</b> from a device <b>1</b>.<b>104</b> to use a protected resource <b>4</b>.<b>102</b> stored in a data node <b>4</b>.<b>104</b> of a data structure within a datastore <b>1</b>.<b>114</b>. In one or more embodiments, the data structure may be a non-hierarchical data structure. A hierarchical data structure is a data structure that includes a set of nodes, all of which except one are subordinate to one of the set of nodes. Specifically, each child node has only one parent node, whereas each parent node can have one or more child node. In order to retrieve data from a hierarchical data structure, a tree structure may need to be traversed starting from a root node of the hierarchy (not to be confused with the root node of the Merkle tree of <figref idref="DRAWINGS">FIG. 2.4</figref> or any of the root hashes discussed in the present embodiments). A non-hierarchical data structure may include, for example, a graph data structure in which a set of data objects that may be collections of attribute-value pairs may reference one another using one or more referential attributes. The references may form a directed acyclic graph that may be known to those in the art. In one or more preferred embodiments, the data resources and/or the data organisms <b>2</b>.<b>100</b> are stored in a proprietary semantic data structure disclosed by a related inventive entity and/or common assignee of the present disclosure. The semantic data structure may use “domains” as the data nodes <b>4</b>.<b>104</b> that may be flexibly related to model any relationship by using referential attributes. The domains may be data resources, data organisms <b>2</b>.<b>100</b>, and/or protected resources that may act as containers of not only a primitive data such as a document or video (e.g., the primitive data itself may be an example of a data resource), but may also store a hastory <b>2</b>.<b>104</b>, referential attributes, the use policy <b>4</b>.<b>108</b>, ownership information, a unique identifier, and/or additional data.

Operation <b>4</b>.<b>804</b> extracts from the data node <b>4</b>.<b>104</b> and/or a security node <b>4</b>.<b>110</b> having a referential attribute <b>4</b>.<b>203</b> pointing to the data node <b>4</b>.<b>104</b> a use policy <b>4</b>.<b>108</b> including computer-readable instructions defining an authorized context for which the device <b>1</b>.<b>104</b> can use the protected resource <b>4</b>.<b>102</b> based on one or more contextual values. Operation <b>4</b>.<b>806</b> initiates a use transaction (which may be, in one or more embodiments, an instance of the transaction <b>2</b>.<b>200</b> of <figref idref="DRAWINGS">FIG. 2.2</figref> that is recorded in one or more hastories <b>2</b>.<b>104</b>) that executes the computer-readable instructions of the use policy <b>4</b>.<b>108</b> to gather one or more contextual values and to determine whether the use request <b>4</b>.<b>130</b> satisfies the authorized context for which the device <b>1</b>.<b>104</b> can use the protected resource <b>4</b>.<b>102</b>. Operation <b>4</b>.<b>808</b> authorizes access to the protected resource <b>4</b>.<b>102</b> by the device <b>1</b>.<b>104</b> when it is determined based on the contextual values that the use request (e.g., the use request <b>4</b>.<b>130</b>) conforms to the authorized context for which the device <b>4</b>.<b>104</b> may use the protected resource. For example, the use policy <b>4</b>.<b>108</b> may require that the protected resource <b>4</b>.<b>102</b> may only be accessed and/or used when the device <b>1</b>.<b>140</b> is within a geospatial boundary around an enterprise headquarters and when the use request <b>4</b>.<b>130</b> is within business hours of the enterprise. Operation <b>4</b>.<b>810</b> generates a use terms <b>4</b>.<b>116</b> from the computer-readable instructions defining the authorized context for the use request <b>4</b>.<b>130</b>. For example, depending on the use policy <b>4</b>.<b>108</b>, a different set of use terms may be generated for a device <b>1</b>.<b>104</b> of a first user and a device <b>1</b>.<b>104</b> of a second user.

<figref idref="DRAWINGS">FIG. 4.9</figref> is a key generation and redemption process flow <b>4</b>.<b>900</b> showing, subsequent to evaluation of the contextual values of the use policy <b>4</b>.<b>108</b> of <figref idref="DRAWINGS">FIG. 4.1</figref>, a process by which the use keys <b>4</b>.<b>118</b> may be generated, returned to the device <b>1</b>.<b>104</b>, and redeemed upon a redemption request <b>4</b>.<b>160</b> by the device <b>1</b>.<b>104</b>, according to one or more embodiments. Operation <b>4</b>.<b>902</b> generates a set of one or more use keys <b>4</b>.<b>118</b> and appends an identifier of a protected resource (e.g., the PRID <b>4</b>.<b>102</b>) to each of the set of one or more use keys <b>4</b>.<b>118</b> to form one or more key-identifier pairs <b>4</b>.<b>120</b>. Operation <b>4</b>.<b>904</b> associates an expiration condition <b>4</b>.<b>122</b> with each of the one or more key-identifier pairs <b>4</b>.<b>120</b>, and operation <b>4</b>.<b>906</b> optionally divides data of the protected resource <b>4</b>.<b>102</b> into two or more segments and may attach a segment identifier to each (e.g., two or more instance of the segment ID <b>3</b>.<b>402</b>) of the one or more key-identifier pairs <b>4</b>.<b>120</b>. The result may be referred to as a key-identifier-segment triplet (that includes the key-identifier pair <b>4</b>.<b>120</b>). The key-identifier pairs <b>4</b>.<b>120</b> and/or the key-identifier-segment triplets may be deposited in a server such as the key server <b>1</b>.<b>108</b>. The key server <b>1</b>.<b>108</b> may be configured to monitor each expiration condition <b>4</b>.<b>122</b> of each and effect rapid verification of validity of the use keys <b>4</b>.<b>118</b> when queried by one or more servers. Operation <b>1</b>.<b>102</b> returns a first use key <b>4</b>.<b>118</b>A of the set of one or more use keys <b>4</b>.<b>118</b> to the device <b>1</b>.<b>104</b> through the network <b>1</b>.<b>101</b>. The mediation server <b>1</b>.<b>102</b> may transmit the first use key <b>4</b>.<b>118</b>A. Operation <b>4</b>.<b>910</b> may receive a redemption request <b>4</b>.<b>160</b> from the device <b>1</b>.<b>104</b> including the first use key <b>4</b>.<b>118</b>A, and operation <b>4</b>.<b>912</b> may verify the first use key <b>4</b>.<b>118</b>A by determining, for example, that a PRID <b>4</b>.<b>106</b> is associated with the use key <b>4</b>.<b>118</b>A within at least one key-identifier pair <b>4</b>.<b>120</b> that has not expired.

Operation <b>4</b>.<b>914</b> extracts the identifier of the protected resource (e.g., the PRID <b>4</b>.<b>106</b>) from a first key-identifier pair <b>4</b>.<b>120</b>A of the one or more key-identifier pairs <b>4</b>.<b>120</b> and retrieves the protected resource <b>4</b>.<b>102</b> with the identifier of the protected resource <b>4</b>.<b>102</b>. For example, the key server <b>1</b>.<b>108</b> may extract the PRID <b>4</b>.<b>106</b> and the datamode microserver <b>1</b>.<b>130</b> may retrieve the protected resource <b>4</b>.<b>104</b> within the datastore <b>1</b>.<b>114</b> (e.g., the subject datastore <b>1</b>.<b>131</b>). Operation <b>4</b>.<b>916</b> streams the protected resource <b>4</b>.<b>102</b> to the device <b>1</b>.<b>104</b> for use by the device <b>1</b>.<b>104</b>, optionally including a second use key <b>4</b>.<b>118</b>B of a second segment identifier (e.g., the segment ID <b>4</b>.<b>302</b>B). Additionally, operation <b>4</b>.<b>916</b> may convey the route <b>2</b>.<b>306</b>B for the next redemption request. Operation <b>4</b>.<b>918</b> may then receive a continued use request automatically generated by the device <b>1</b>.<b>104</b> when the first segment of the data of the protected resource <b>4</b>.<b>102</b> approaches an end of a memory buffer of the device <b>1</b>.<b>104</b>, the continued use request including the second use key <b>4</b>.<b>118</b>B of the one or more use keys <b>4</b>.<b>118</b>. The second use key <b>4</b>.<b>118</b>B may be conveyed using the route <b>4</b>.<b>206</b>B provided to the device <b>1</b>.<b>104</b>. The route <b>4</b>.<b>206</b>B, for example, may include an IP address of a content delivery server closest to the device <b>1</b>.<b>104</b> (that may include some or all of the data resources of the datastore <b>1</b>.<b>114</b>). Operations <b>4</b>.<b>916</b> and operations <b>4</b>.<b>918</b> may then repeat for additional segments of the protected resource <b>4</b>.<b>102</b>, each segment streamed to the device <b>1</b>.<b>104</b> may include a new use key <b>4</b>.<b>118</b> of the set of one or more use keys <b>4</b>.<b>118</b> and may include a new instance of the route <b>4</b>.<b>206</b>.

<figref idref="DRAWINGS">FIG. 4.10</figref> is a device active data use process flow <b>4</b>.<b>1000</b> showing a process that can be used to monitor use of the protected resource <b>4</b>.<b>102</b> by the device <b>1</b>.<b>104</b> and/or enforce ephemerality of the protected resource <b>4</b>.<b>102</b> on the device <b>1</b>.<b>104</b> in accordance with the use policy <b>4</b>.<b>108</b> and a set of use terms <b>4</b>.<b>116</b> generated based on the use policy <b>4</b>.<b>108</b>, according to one or more embodiments. Operation <b>4</b>.<b>1001</b> may redeem a use key <b>4</b>.<b>118</b>, for example from one or more datastore servers and according to a network address specified by a route <b>4</b>.<b>206</b>. Operation <b>4</b>.<b>1002</b> receives a data stream of the protected resource <b>1</b>.<b>104</b> (e.g., the data stream <b>4</b>.<b>180</b> of <figref idref="DRAWINGS">FIG. 4.1</figref>). Operation <b>4</b>.<b>1004</b> deposits a use ID (e.g., the use identifier <b>4</b>.<b>402</b> of <figref idref="DRAWINGS">FIG. 4.4</figref>) and a use terms <b>4</b>.<b>116</b> in an active use ledger <b>4</b>.<b>400</b> of the device <b>1</b>.<b>104</b>. In operation <b>4</b>.<b>1006</b>, the device <b>1</b>.<b>104</b> and/or an application program of the device <b>1</b>.<b>104</b> uses the data of the protected resource <b>4</b>.<b>102</b>, for example by viewing a document, playing an audio track, and/or visualizing a report (e.g., graphs, charts) based upon data of the protected resource <b>4</b>.<b>102</b>. While the data of the protected resource <b>4</b>.<b>102</b> is in use, operation <b>4</b>.<b>1008</b> and operation <b>4</b>.<b>1012</b> through operation <b>4</b>.<b>1016</b> may monitor its use. Operation <b>4</b>.<b>1008</b> determines if the data is in active use. The definition of active use may be pre-set within the terms engine device-side <b>1</b>.<b>112</b>B and/or may be defined by the use terms <b>4</b>.<b>116</b>. For example, the use terms <b>4</b>.<b>116</b> may specify that data is not in active use when it is not currently displayed on a screen of the device <b>1</b>.<b>104</b>, where the user has not provided an input for a predetermined period of time (e.g., 30 seconds, 1 hour) where the device <b>1</b>.<b>104</b> and/or an application of the device <b>1</b>.<b>104</b> has been inactive, or when a display of the device <b>1</b>.<b>104</b> is powered down by the operating system. If the data is no longer in active use, operation <b>4</b>.<b>1010</b> determines whether there are additional segments and whether the active use terminated due to a current segment of data of the protected resource <b>4</b>.<b>102</b> reaching or nearing the end of a memory buffer. For example, operation <b>4</b>.<b>1010</b> may determine that an additional segment should be retrieved where a segment of audio is about to end. Operation <b>4</b>.<b>1010</b> may also determine whether additional segments of the protected resource <b>4</b>.<b>102</b> exist by checking if additional use keys (e.g., the use key <b>4</b>.<b>118</b>B) were returned to the device <b>1</b>.<b>104</b> in association with operation <b>4</b>.<b>1002</b>. To retrieve additional segments, operation <b>4</b>.<b>1010</b> returns to operation <b>4</b>.<b>1000</b> which redeems the a next use key (e.g., the use key <b>4</b>.<b>118</b>B). If no additional segments are to be retrieved, operation <b>4</b>.<b>1010</b> proceeds to operation <b>4</b>.<b>1018</b> which may delete data of the protected resource <b>4</b>.<b>104</b> at one or more memory addresses tracked by the terms engine device-side <b>1</b>.<b>112</b>B and/or scrub the memory buffer of the device <b>1</b>.<b>104</b>. Operation <b>4</b>.<b>1020</b> may then generate a termination notice <b>4</b>.<b>506</b> and/or a termination report <b>5</b>.<b>408</b> and one or more servers may close an open transaction record <b>4</b>.<b>404</b> of the use transaction by the device <b>1</b>.<b>104</b>.

If the data of the protected resource <b>4</b>.<b>102</b> continues to be in active use, operation <b>4</b>.<b>1008</b> proceeds to operation <b>4</b>.<b>1012</b> that is a decision process that determines whether updated use terms <b>4</b>.<b>516</b> have been received. If so, operation <b>4</b>.<b>1012</b> proceeds to operation <b>4</b>.<b>1004</b> that may then deposit the updated use terms <b>4</b>.<b>516</b> in place of the use terms <b>4</b>.<b>116</b>. If no updated use terms <b>4</b>.<b>516</b> have been received, operation <b>4</b>.<b>1014</b> determines whether a network connection remains established over the network <b>1</b>.<b>101</b> (e.g., between the device <b>1</b>.<b>104</b> and one or more servers of the authorization network <b>4</b>.<b>100</b>). The network connection may be considered to be lost if, for example, a latency of a predetermined threshold value is reached. If no network connection remains, operation <b>4</b>.<b>1014</b> may proceed to operation <b>4</b>.<b>1018</b>. If a connection remains established, operation <b>4</b>.<b>1014</b> may proceed to operation <b>4</b>.<b>1016</b> that evaluates the active use of the data of the protected resource <b>4</b>.<b>102</b> to determine whether it conforms to the use terms <b>4</b>.<b>116</b> and/or, where applicable, the updated use terms <b>4</b>.<b>516</b>. For example, a set of geospatial coordinates within the use terms <b>4</b>.<b>106</b> may require that the active use occur within a given municipality. If the state dataset <b>4</b>.<b>200</b> of the device, as may be retrieved from an operating system of the device <b>4</b>.<b>102</b>, indicates the coordinates are outside of the geospatial coordinates of the municipality, operation <b>4</b>.<b>1016</b> may proceed to operation <b>4</b>.<b>1018</b>. Otherwise, operation <b>4</b>.<b>1016</b> returns to operation <b>4</b>.<b>1006</b>.

<figref idref="DRAWINGS">FIG. 4.11</figref> is a use termination process flow <b>4</b>.<b>1000</b> illustrating a process by which an open transaction record <b>4</b>.<b>404</b> of the active use of the protected resource <b>4</b>.<b>102</b> is closed the protected resource <b>4</b>.<b>102</b> is determined to no longer be in active use, a network connection to the device <b>1</b>.<b>104</b> was lost, and/or the device <b>1</b>.<b>104</b> performed an action outside of the use terms <b>4</b>.<b>116</b>, according to one or more embodiments. Operation <b>4</b>.<b>1102</b> maintains an open transaction record <b>4</b>.<b>404</b> of a use transaction and stores one or more contextual values usable to determine an authorized context (e.g., values of the state dataset <b>4</b>.<b>200</b> and/or the external dataset <b>4</b>.<b>202</b>), the open transaction record <b>4</b>.<b>404</b> associating a device <b>1</b>.<b>104</b> with an active use of a protected resource <b>4</b>.<b>102</b>. Operation <b>4</b>.<b>1104</b> returns the use terms <b>4</b>.<b>116</b> generated from a set of computer-readable instructions (e.g., the set of computer-readable instructions of the use policy <b>4</b>.<b>108</b>) to the device <b>1</b>.<b>104</b>. Operation <b>4</b>.<b>1106</b> may monitor use of and enforce ephemerality of the protected resource <b>4</b>.<b>102</b> on the device <b>1</b>.<b>104</b> by maintaining a ledger (e.g., the active use ledger <b>4</b>.<b>400</b>) including data identifying the protected resource (e.g., the use ID <b>4</b>.<b>402</b>) that is in active use by the device and a corresponding instance of the use terms <b>4</b>.<b>116</b> associated with the authorized use of the protected resource <b>4</b>.<b>102</b>. As shown in conjunction with <figref idref="DRAWINGS">FIG. 4.5</figref>, operation <b>4</b>.<b>1108</b> receives from a second user (e.g., the second user <b>3</b>.<b>303</b>B) a policy update <b>4</b>.<b>501</b> that alters the computer-readable instructions of the use policy <b>4</b>.<b>108</b> defining the authorized context for use of the protected resource <b>4</b>.<b>102</b>. The result may be the updated use policy <b>4</b>.<b>502</b>. Operation <b>4</b>.<b>1110</b> determine the open transaction record <b>4</b>.<b>404</b> is associated with the protected resource <b>4</b>.<b>102</b> and the device <b>1</b>.<b>104</b>. For example, one or more of the datastore servers that include the data node <b>4</b>.<b>104</b> storing the protected resource <b>4</b>.<b>102</b> may transmit the updated use policy <b>4</b>.<b>502</b> to the mediation server <b>1</b>.<b>102</b> along with the PRID <b>4</b>.<b>106</b>. The mediation server <b>1</b>.<b>102</b> may then use the PRID <b>4</b>.<b>106</b> or another method to locate open transaction records <b>4</b>.<b>404</b> associated with the PRID <b>4</b>.<b>106</b>.

<b>4</b>.<b>1112</b> re-generates the use terms <b>4</b>.<b>116</b> to an updated use terms <b>4</b>.<b>516</b> based on the stored one or more contextual values (e.g., the state dataset <b>4</b>.<b>200</b>) and/or a new set of gathered values (e.g., the updated state dataset <b>4</b>.<b>500</b>) to form a new instance of the authorized context. Operation <b>4</b>.<b>1114</b> then pushes the updated use terms <b>4</b>.<b>516</b> generated from the policy update <b>4</b>.<b>501</b> to the device <b>1</b>.<b>102</b>. Operation <b>4</b>.<b>1116</b> processes a termination notice. For example the termination notice may be a termination notice <b>4</b>.<b>506</b> that the protected resource <b>4</b>.<b>102</b> is no longer in active use by the device and/or that use of the protected resource <b>4</b>.<b>102</b> has been automatically terminated where the device <b>4</b>.<b>102</b> performed an action outside of the use terms <b>4</b>.<b>116</b> and/or the updated use terms <b>4</b>.<b>516</b>. The termination notice may also be generated by a server of the authorization network <b>4</b>.<b>100</b>, for example where a network connection to the device <b>4</b>.<b>102</b> is lost. Finally, in operation <b>4</b>.<b>1118</b>, the result of the termination notice (e.g., the termination notice <b>4</b>.<b>506</b>) may be logged, the open transaction <b>4</b>.<b>404</b> record may be closed, and optionally one or more hastories <b>2</b>.<b>104</b> may be updated with a transaction record <b>2</b>.<b>302</b> of the use transaction.

The authorization network <b>4</b>.<b>100</b> provides a number of advantages. Permissions of a data resource through the use policy are both flexible and can relatively easily defined for each protected resource. The use policy based on gathering contextual values is able to compare those values, for example to determine by defining inputs to be extracted from a gathered external dataset that a user may use a particular protected resource only where one sports score is larger than another sports score. In a specific example, if an employee of an enterprise asks for access to a protected resource the employee is not generally permissioned to use, contextual access and/or use controls through the use policy may be placed by an administrator rather than add the employee to a group that may over-permission the employee. This may prevent compromise of an entire group of protected resources if, for example, the employee loses his or her identity credentials that allow access to an entire group of protected resources. Similarly, a musician may wish to share a digital asset such as music with a fan, but only wish to control how many times the fan can listen to that music on the fan's device, which may substantially increase the economic value of the music to the artist. The use policy <b>4</b>.<b>108</b> may even be able to respond to events of the device. For example, where a 3D computer aided design file (CAD) is streamed to the device for single time use, an error of the 3D printer during the manufacturing process may be reported back to one or more servers and the use policy may include computer-readable instructions to interpret the error and re-stream the 3D CAD file.

The data authorization network <b>4</b>.<b>100</b> may also be able to implement use controls over data without a separate external system for storing permissions such as an access control list. This may decrease computing overhead in resolving authorization requests, allowing the authorization network <b>4</b>.<b>100</b> and/or the data resource control network <b>1</b>.<b>100</b> to scale, both in the number of users that can interact and the number of authorization requests per each user that can be quickly resolved. Association of both a protected resource and the use policy defining the authorized context may also make it easier for users to determine which controls are associated with which protected resources and/or whether a data resource is unprotected, improving data security and control.

Finally, the authorization network <b>4</b>.<b>100</b> may be able to implement a capability-based control system with real-time revocable authorization of protected resources. As a result, protected resources may not leave the control of the authorization network <b>4</b>.<b>100</b>, e.g., through use of the terms engine. There is therefore a much higher probably that control of the protected resources, along with associated data about their use that may be valuable for analysis and insight, is retained by an owner and/or an organization running the datastore.

An example of the authorization network will not be provided within the context of an enterprise. <figref idref="DRAWINGS">FIG. 4.12</figref> is an enterprise use policy view <b>4</b>.<b>1250</b> illustrating use of the use policy <b>4</b>.<b>108</b> to define an authorized context for limited access and use of a protected resource that is a confidential spreadsheet <b>4</b>.<b>1202</b>, the authorized context including flexible controls such as a requirement that an executive of the enterprise (e.g., a corporate executive office <b>4</b>.<b>1203</b>A, the corporate financial officer <b>4</b>.<b>1203</b>B) be within a geospatial fence of the business premises <b>4</b>.<b>1200</b> for an employee <b>4</b>.<b>1203</b>C to view the confidential spreadsheet <b>4</b>.<b>1202</b>, according to one or more embodiments. The confidential spreadsheet <b>4</b>.<b>1202</b> may be a protected resource stored in a first datastore server <b>1</b>.<b>106</b>A (e.g., within the data node <b>4</b>.<b>104</b> of <figref idref="DRAWINGS">FIG. 4.1</figref>). The datastore server <b>1</b>.<b>106</b>B may store the control policy <b>4</b>.<b>108</b> defining an authorized context for access to and use of the confidential spreadsheet <b>4</b>.<b>1202</b>. The business premises <b>4</b>.<b>1200</b> may be an office building or other physical location and may be specified as a “geofence” which may be a set of geospatial coordinates forming a bounded area. Each of the devices and servers in <figref idref="DRAWINGS">FIG. 4.12</figref> may be connected through one or more networks. The device <b>1</b>.<b>104</b>A and the device <b>1</b>.<b>104</b>B are communicatively coupled to the datastore server <b>1</b>.<b>106</b>B through a cellular network that may have a capability of transferring IP packets (e.g., by a protocol such as 3G, LTE).

The use policy <b>4</b>.<b>108</b> of <figref idref="DRAWINGS">FIG. 4.12</figref> is implemented to provide careful scope over access to and use of the confidential spreadsheet <b>4</b>.<b>1202</b> as it may contain vital trade secrets such as revenue of the enterprise or key business strategy. In a detailed example, the use policy <b>4</b>.<b>108</b> may specify a complex authorization scheme. First, any executive of the enterprise (including the CEO <b>4</b>.<b>1203</b>A and the CFO <b>4</b>.<b>1203</b>B) may view the spreadsheet <b>4</b>.<b>1202</b> in any geospatial location as long as another executive of the enterprise is within 100 yards of the executive. This determination of proximity may be made based up one or more state datasets <b>4</b>.<b>200</b> retrieved from devices of the executives (e.g., the device <b>1</b>.<b>104</b>A, the device <b>1</b>.<b>104</b>B). Second, the control policy may specify that an employee of the enterprise may have access to the confidential spreadsheet <b>4</b>.<b>1202</b> if: (1) at least one executive is within the geospatial boundary of the business premises <b>4</b>.<b>1200</b>; (2) if the use request (e.g., the use request <b>4</b>.<b>130</b>) for the confidential spreadsheet <b>4</b>.<b>1203</b> originates from a specific set of Ethernet network addresses associated with a local area network of the business premises <b>4</b>.<b>1200</b>; and (3) if the use request is generated between business hours (e.g., between 8 AM to 6 PM).

The employee <b>4</b>.<b>1203</b> may need to see a couple calculations or numbers within the confidential spreadsheet <b>4</b>.<b>1202</b>. After the employee <b>4</b>.<b>1203</b>C is authenticated (e.g., by the process described in conjunction with <figref idref="DRAWINGS">FIG. 3.1</figref>), the employee <b>4</b>.<b>1203</b>C may submit a use request to the mediation server <b>1</b>.<b>102</b> including an SNID <b>4</b>.<b>112</b> of the security node <b>4</b>.<b>110</b> storing the use policy <b>4</b>.<b>108</b> and reference the data node <b>4</b>.<b>104</b> that stored the confidential spreadsheet <b>4</b>.<b>1202</b>. The mediation server <b>12</b>.<b>02</b> may execute the one or more conditionals of the use policy <b>4</b>.<b>108</b> and retrieve one or more contextual values such as the Ethernet address of the device <b>1</b>.<b>104</b>C, a geospatial coordinate of at least one of the device <b>1</b>.<b>104</b>B and <b>1</b>.<b>104</b>A, and a time as may be maintained on an internal clock of the mediation server <b>1</b>.<b>102</b>. After evaluating the use policy <b>4</b>.<b>108</b>, the mediation server <b>1</b>.<b>102</b> may create an open transaction record <b>4</b>.<b>404</b> in transaction engine <b>1</b>.<b>110</b> and/or the terms engine server-side <b>1</b>.<b>112</b>, generate a use terms (e.g., the use terms <b>4</b>.<b>116</b> of <figref idref="DRAWINGS">FIG. 4.1</figref>), and generate and deliver a set of use keys <b>4</b>.<b>118</b> for multiple segments of the confidential spreadsheet <b>4</b>.<b>1202</b>, for example each page.

The mediation server <b>1</b>.<b>102</b> may return a first use key <b>4</b>.<b>116</b>A corresponding to a first page of the confidential spreadsheet <b>4</b>.<b>1202</b>. An application program of the device <b>1</b>.<b>104</b>C may then redeem the first use key <b>4</b>.<b>116</b>A for the first page (along with a second use key <b>4</b>.<b>116</b>B which may also be returned at the same time as the first page). When the user <b>4</b>.<b>1203</b>C determines that what he or she wishes to see is on the next page, the key <b>4</b>.<b>116</b>B is redeemed. As a second page of the confidential spreadsheet is streamed to the device <b>1</b>.<b>104</b>C, the first page may no longer be in “active use” by device <b>1</b>.<b>104</b>C according to the use terms <b>4</b>.<b>116</b> stored on the terms engine device-side <b>1</b>.<b>112</b>B and may therefore be automatically scrubbed form a memory of the device <b>1</b>.<b>104</b>C. If the employee <b>4</b>.<b>1203</b>C takes a screenshot capture of the active page in contradiction to the use terms <b>4</b>.<b>116</b>, the terms engine device-side may terminate use of the confidential spreadsheet <b>4</b>.<b>1202</b>, and generate and convey a termination report <b>4</b>.<b>508</b> to the mediation server <b>1</b>.<b>102</b>. The mediation server <b>1</b>.<b>102</b> may instruct the key server <b>1</b>.<b>108</b> to delete all use keys, may close the open transaction record (e.g., the use transaction) and then have the transaction record deposited in one or more hastories. Additionally, the use policy <b>4</b>.<b>108</b> specifies that based upon the termination report <b>4</b>.<b>508</b> the executive at the business premises <b>4</b>.<b>1200</b> (e.g., the CFO <b>4</b>.<b>1203</b>B) should have a notification sent to his or her device (e.g., the device <b>1</b>.<b>104</b>B). Similarly, the use may be terminated where a network connection between the device <b>1</b>.<b>104</b>C and the mediation server <b>1</b>.<b>102</b> is lost, or where all executives leave the geospatial boundary of the business premises <b>4</b>.<b>1200</b> as may be periodically polled by the mediation server <b>1</b>.<b>102</b>. The transaction record generated from the use of the confidential spreadsheet <b>4</b>.<b>1202</b> may be deposited directly into a hastory of the security node <b>4</b>.<b>110</b> referencing the data node <b>4</b>.<b>104</b> such as to create an immutable record of the transaction that may be used in auditing and/or accounting of protected resources of the datastore <b>1</b>.<b>114</b>.

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, servers and engines 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 (ASIC) circuitry and/or Digital Signal Processor (DSP) circuitry).

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 device <b>1</b>.<b>104</b>A, the mediation server <b>1</b>.<b>102</b>, one or more servers <b>1</b>.<b>106</b>, the key server <b>1</b>.<b>108</b>). Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense.

The structures and engines in the figures may be shown as distinct and communicating with only a few specific structures and not others. The structures may be merged with each 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.

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 are within the scope of the preceding disclosure.