Guardtime Sa

Guardtime IP Holdings Limited

Exelis Inc.

Hema Krishnamurthy

Jeffrey Pearce

Michael Shu Xie

Garrett Day

Risto Alas

Ahto Truu

Anthony Kenyon

Matthew Johnson

Rando Mihkelsaar

Gregory Raymond

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.

System and method for verifiably proving proximity

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.

Event verification receipt system and methods

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.

Auditable system and methods for secret sharing

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.

System and method for registering multi-party consent

Initial data is included in a data structure such as an initial container at an initial entity, along with rules and a data signature of at least a portion of the initial data and other container contents relating to the initial entity and the initial data. Each rule defines at least one condition governing the permissible transfer and processing of the initial data by other entities in a provenance chain. Each receiving entity creates a container of its own to encapsulate received containers, and, after optional processing of its own, such as adding or altering data and rules, digital signature for its container. The digital signatures may be obtained from a hash tree-based signing infrastructure that returns data signatures enabling recomputation of a logically uppermost value of the hash tree. A lineage map of any given container may also be displayed for analysis by a user.

Data and data lineage control, tracking, and verification

Data packets passing from a source to a destination in a network according to a Service Function Chain (SFC) are processed by an ordered sequence of at least one service function (SF). For each SF in the SFC in order, a current value of a function, such as a hash function, is recursively computed including, as input values, at least current identifying data that identifies a corresponding current one of the SFs, and a value of the function output from an immediately preceding SF. After computing the current value of the function for a selected SF in the SFC, the current value of the function is compared with an expected value. If the value of the function for the selected SF is the same as the expected value, the data packet is allowed to be transmitted to a subsequent processing stage; if not, then an error response action is taken.

Verification mechanism for network service chain paths

Blockchain blocks are provided with either or both of two element types that enable later verification of block validity. One element type is identifiers, such as signatures, of trusted validators that approve entry of the block into the blockchain. Another element is a history hash tree that encodes data from not only the current block, but also at least one previous block.

Whenever users receive or transfer a copy of any of a set of documents, prior verification of the document is enforced by an administrative system, which associates verification metadata with the copy. As each copy is itself copied, possibly modified, and transferred, updated verification metadata is included with the previous verification metadata to form a verification lineage chain, which can later be examined to determine the circumstances of any verification failure. Documents are preferably verified by comparing the digital signature of the current copy with the signature of a reference copy. Documents may be signed by submitting them as transactions to a blockchain, with the blockchain receipt comprising the digital signature of the respective document.

Verification lineage tracking and transfer control of data sets

Data acquired, for example by a mobile platform, such as a sequence of images observed by a mobile platform, is grouped. A signature is computed for each group and is transmitted along with frame data to a reception system, which verifies correct transmission based on the group signature. The signature may be a root value of a hash tree that has at least selected ones of each group as inputs. Transmission events may also be separately signed as a whole using an event validation system. Although the signature maybe computed for all frames in a group, it may also be computed based on only a subset, selected pseudo-randomly.

System and method for secure transmission of streamed data frames

Whenever users receive or transfer a copy of any of a set of documents, prior verification of the document is enforced by an administrative system, which associates verification metadata with the copy. As each copy is itself copied and transferred, updated verification metadata is included with the previous verification metadata to form a verification lineage chain, which can later be examined to determine the circumstances of any verification failure. Documents are preferably verified by comparing the digital signature of the current copy with the signature of a reference copy. Documents may be signed by submitting them as input records to a distributed, keyless, hash tree infrastructure.

System and method for verification lineage tracking of data sets

Methods and systems provide a secure virtual keyboard represented as an onscreen keyboard with multiple levels of security. The secure virtual keyboard provides keys that are a combination of numerals, alphabets and special characters. Different security features provided include, but are not limited to, randomly changing the key layout, providing an option for mouse-hover input, and using a secure encrypted transmission path.

Growing community of inventors

Phoenix, AZ, United States of America

Hema Krishnamurthy