Abstract: When a mobile device such as a smart phone comes within range of a location device, the mobile device inputs a location token from the location device and a travel token is created from a mobile device token and the location token. The mobile and location tokens may include data elements indicating not only identity, but also such other characteristics as an authorization or infection risk level. Tokens may be digitally signed, preferably with an independently verifiable signature that also encodes time. Mobile and location devices may be created and issued by a tracking service provider, which may also store tokens, analyze travel tokens with respect to a location's risk level, and update mobile device and location tokens to change a status of the mobile or location device.

Abstract: Individually identifiable data units, making up a global set of such units, are each associated uniquely with one of a group of nodes, which form shards of a logical global blockchain. Each node maintains a subledger for each data unit associated with it, the subledger keeping track of at least the current ownership state of the data unit. Different mechanisms are provided to enable multiple data units to be transferred atomically, for example, to logically join the data units to form a new unit designating and amount equal to the sum of the amounts of the transferred data units. For example, in implementations in which the data units represent money, with a plurality of denominations, smaller units may be exchanged for a single larger unit. Sharding enables multiple transfer orders to be processed in parallel.

Abstract: When a mobile device such as a smart phone comes within range of a location device, the mobile device inputs a location token from the location device and a travel token is created from a mobile device token and the location token. The mobile and location tokens may include data elements indicating not only identity, but also such other characteristics as an authorization or infection risk level. Tokens may be digitally signed, preferably with an independently verifiable signature that also encodes time. Mobile and location devices may be created and issued by a tracking service provider, which may also store tokens, analyze travel tokens with respect to a location's risk level, and update mobile device and location tokens to change a status of the mobile or location device.

Abstract: When a mobile device such as a smart phone comes within range of a location device, the mobile device inputs a location token from the location device and a travel token is created from a mobile device token and the location token. The mobile and location tokens may include data elements indicating not only identity, but also such other characteristics as an authorization or infection risk level. Tokens may be digitally signed, preferably with an independently verifiable signature that also encodes time. Mobile and location devices may be created and issued by a tracking service provider, which may also store tokens, analyze travel tokens with respect to a location's risk level, and update mobile device and location tokens to change a status of the mobile or location device.

Abstract: A global set of transferrable value items is represented as a set of individually identifiable data units, the state of each of which is encoded in a respective data structure, such as a blockchain, that has a series of linked blocks maintained in one of a plurality of nodes determined as a function of an identifier of each data unit. A transferor submits a transfer request that indicates a quantity. The request may indicate which data unit it wishes to transfer, or, in an alternative embodiment, the node may select one or more data units owned by the transferor. If the selected data unit's value does not equal the quantity to be transferred, the node logically splits the (or one of the) data unit(s) to satisfy the request, and creates corresponding blocks in the data structure. Data units may, as one example, correspond to digital cash.

Abstract: Digital signatures are generated for a message using an authentication tree data structure in which nodes are created as needed from a root node. A public and secret key pair is generated using a one-time signature method to form each node, and the secret key of each parent node is used to sign the public keys of its child nodes. Once the secret key of a node has been used in creating a signature for a message, it may be revealed. The signature data structure is unbounded and stateless, and need not be pre-generated and fixed.

Abstract: A vaccination certificate is provided with at least one optically readable marking that encodes a digital signature of the identity of a patient, and well as data relating to a vaccine and its administration to the patient. The digital signature enables verification of purportedly correct information without needing to know the personal identifying information of the patient, and without querying an external database. A salt value may also be added to the patient identity information to increase entropy in the digital signature.

Abstract: A log, comprising a sequence of temporally ordered digital entries, is authenticated by entering a new entry into the log only after expiration of a minimum time interval. A digital signature and timestamp are generated for each entry in the log and are included in each respective entry. In a validity verification phase, the timestamp of at least one of the entries is examined to determine whether it indicates entry into the log at a time relative to a preceding entry in the log after less than an expected minimum time interval. If so, a remedial action is taken.

Abstract: Data security is provided in the form of a method for digitally signing a data message. A client device issues a issuing a signature request to a server and generates a first signature part as functions of selected ones of first signature parameters. It then receives from the server a second signature part, said second signature part having been computed by the server as functions of second signature parameters and at least one of the first signature parameters. The client device then attempts to verify components of the second signature part and generates a final digital signature of the message only if the components of the second signature part are valid. Part of the computational effort of creating the signature is thus offloaded to the server, even though the server may not be fully trusted.

Abstract: A method for auditably tracking data objects is proposed.

Abstract: When a mobile device such as a smart phone comes within range of a location device, the mobile device inputs a location token from the location device and a travel token is created from a mobile device token and the location token. The mobile and location tokens may include data elements indicating not only identity, but also such other characteristics as an authorization or infection risk level. Tokens may be digitally signed, preferably with an independently verifiable signature that also encodes time. Mobile and location devices may be created and issued by a tracking service provider, which may also store tokens, analyze travel tokens with respect to a location's risk level, and update mobile device and location tokens to change a status of the mobile or location device.

Abstract: Exclusive ownership of data units, such as monetary units, is transferred by inputting a request from a transferor, to transfer to a transferee at least a designated one of the data units, said request including an identifier of the transferor, an identifier of the designated data unit, and an identifier of a transferee. The identifier of the transferor is verified and the absence of any other request to transfer the designated data unit is confirmed. A designation of ownership of the designated data unit is then changed from the transferor to the transferee in a ledger, which is comprised of a group of subledgers, each configured as a blockchain.

Abstract: During a period of uni-directional, device-to-collector communication, a digital signature is created for at least one data set based on a public key, which is computed from at least one time-bound secret key. When collector-to-device communication becomes available, the collector signals to the device that the current data collection period may end, at which point the time-bound secret key(s) previously used may be revealed but are not longer usable.

Abstract: Exclusive ownership of data units, such as monetary units, is transferred by inputting a request from a transferor, to transfer to a transferee at least a designated one of the data units, said request including an identifier of the transferor, an identifier of the designated data unit, and an identifier of a transferee. The identifier of the transferor is verified and the absence of any other request to transfer the designated data unit during an update period is confirmed. A designation of ownership of the designated data unit is then changed from the transferor to the transferee in a ledger, which is comprised of a group of subledgers, each configured as a blockchain. Ownership is thereby processed per-unit instead of per-account.

Abstract: An event is registered in at least one node server in a directed data structure, which comprises a computationally linked series of nodes such that each node encodes information included in at least one preceding node. Within at least selected nodes of the directed data structure after at least one initial node, a representation of at least one history data structure is included and has a highest-level value computed based on inputs of lowest level input values, at least one said lowest level input value encoding node-specific information of at least one preceding node. In a verification phase, a purportedly valid lowest level input value is verified by recomputing the corresponding highest-level value from the representation of the history data structure included in the corresponding node.

Abstract: A set of secret, indexed keys is generated and used in requests from a signing entity to a signing server for digital signature of messages. The signing server maintains a counter as well as a hash tree that aggregates requests during a round into a root value that is stored in an append-only data structure in a repository. Each signing entity is associated with a leaf of the hash tree. After a signature is formed, the counter for the requesting signing entity is incremented, whereby the secret key that was used cannot be used again.

Abstract: Parties communicate input values to a central entity by first decomposing them according to a chosen operation into share values, which are sent either directly or, in a transformed form such as being hashed and/or encrypted, via a bulletin board data structure, to respective nodes, such that no node receives the input value itself. The nodes then combine the share values using the operation and pass these respective node values to the central entity for computation of a global value. The operation of the parties and of the nodes may be made verifiable by aggregating the share values within a party or the received share values within a node using a data and computational structure such as a hash tree or skip list. Digital signing and timestamping may also be applied.

Abstract: Parties communicate input values to a central entity by first decomposing them according to a chosen operation into share values, which are sent either directly or, in a transformed form such as being hashed and/or encrypted, via a bulletin board data structure, to respective nodes, such that no node receives the input value itself. The nodes then combine the share values using the operation and pass these respective node values to the central entity for computation of a global value. The operation of the parties and of the nodes may be made verifiable by aggregating the share values within a party or the received share values within a node using a data and computational structure such as a hash tree or skip list. Digital signing and timestamping may also be applied.

Abstract: Multi-party consent to performance of an action is securely registered by receiving from at least one consent requesting entity (CRE) a consent action request (CAR), which is matched with a consent policy. The policy may specify a plurality of consent voting entities (CVE), and direct confirmation of registration of an identity of each CVE in a blockchain. A consent request (CR) may then be issued to the CVEs. Consent request responses (CRRs) from the CVEs are then compared with at least one condition in the consent policy. A representation of a state of the CRRs is relative to the consent policy is registered in the blockchain. If the policy condition(s) is satisfied, a subject entity may be signaled to perform the action corresponding to the CAR, and a state indication of performance of the action may also be registered in the blockchain.

Abstract: Data security is provided in the form of a method for digitally signing a data message. A client device issues a issuing a signature request to a server and generates a first signature part as functions of selected ones of first signature parameters. It then receives from the server a second signature part, said second signature part having been computed by the server as functions of second signature parameters and at least one of the first signature parameters. The client device then attempts to verify components of the second signature part and generates a final digital signature of the message only if the components of the second signature part are valid. Part of the computational effort of creating the signature is thus offloaded to the server, even though the server may not be fully trusted.