US-20260127593-A1 - CRYPTOGRAPHIC SECURITY OF AN EVOLVING ACTUAL POSSESSION TOKEN

US20260127593A1US 20260127593 A1US20260127593 A1US 20260127593A1US-20260127593-A1

Abstract

Disclosed is a method, a device, a system and/or a manufacture of cryptographic security of an evolving actual possession token. In one aspect, a method may include receiving an electronic token in a current transfer transaction having a block hash of the previous transfer transaction representing a state of the electronic token following the previous transfer transaction. A data block of the current transfer transaction is generated along with a secret value. The method feeds into a cryptographic hash function inputs including transaction data of the current transfer transaction, the block hash of the previous transfer transaction, and the secret value to generate a block hash of the current transfer transaction. The method stores the secret value in the computer memory and transmits for storage on a server a state hash representing an evolved state of the electronic token to establish independent evidence of evolution of the electronic token.

Inventors

Dhryl Anton
Michael McFall

Assignees

ONLI, INC.

Dates

Publication Date: 20260507
Application Date: 20260105

Claims (20)

1 . A method for cryptographically securing an electronic token in a computer memory to enable actual possession of the electronic token, the method comprising: receiving the electronic token in a current transfer transaction and storing the electronic token in the computer memory, the electronic token comprising a data block of a previous transfer transaction and a block hash of the data block of the previous transfer transaction representing a state of the electronic token following the previous transfer transaction, wherein the block hash of the data block of the previous transfer transaction generated as an output of a cryptographic hash function with inputs comprising a transaction data of the previous transfer transaction; generating a data block of the current transfer transaction comprising a transaction data of the current transfer transaction comprising data at least one of received at the computer memory and generated on the computer memory; generating a secret value; adding the data block of the current transfer transaction to the electronic token; feeding inputs into a first cryptographic hash function, wherein the inputs comprising the transaction data of the current transfer transaction, the block hash of the data block of the previous transfer transaction, and the secret value; generating a block hash of the data block of the current transfer transaction as an output of the first cryptographic hash function; storing the secret value in the computer memory; and transmitting for storage on a server a state hash representing an evolved state of the electronic token that is at least one of the block hash of the data block of the current transfer transaction, an output of a cryptographic hash function with inputs comprising the block hash of the data block of the current transfer transaction, and a value that is dependent on the block hash of the data block of the current transfer transaction, to establish independent evidence of evolution of the electronic token.
2 . The method of claim 1 , further comprising: at least one of reading and receiving two or more block hashes for each of two or more data blocks previously generated in a set of transfer transactions of the electronic token.
3 . The method of claim 1 , wherein the secret value generated based on an entropic input gathered from an entropy source.
4 . The method of claim 1 , wherein the server stores a state datastore on two or more computing nodes communicatively coupled through a network.
5 . The method of claim 4 , wherein the state datastore rendered eventually consistent through a raft algorithm.
6 . The method of claim 4 , wherein the state datastore stores a copy of the state datastore on each of the two or more computing nodes and reconciled through a consensus mechanism executed through a consensus algorithm of each of the two or more computing nodes.
7 . The method of claim 1 , generating a transfer instruction initiating a new transfer transaction in which possession of the electronic token to transfer to a user to receive possession of the electronic token following the new transfer transaction; generating a transaction data of the new transfer transaction; and generating a verified acceptance of the new transfer transaction from at least one of a user who received possession of the electronic token following the current transfer transaction and the user to receive possession of the electronic token following the new transfer transaction.
8 . The method of claim 7 , further comprising: reading the electronic token from the computer memory and transmitting the electronic token to a computing device of the user to receive possession of the electronic token following the new transfer transaction; receiving a transaction completion data communicating that the electronic token has undergone a state evolution associated with the new transfer transaction; and deleting the electronic token, now outdated by the state evolution, from the computer memory.
9 . A system for validating an electronic token that can be actually possessed and comprises a state of the electronic token within a sequence of one or more transactions of the electronic token, the system comprising: a network, and a server comprising: a processor of the server; and a computer readable memory of the server that is non-transitory comprising computer readable instructions that when executed on the processor of the server cause the processor of the server to: receive a transfer instruction to initiate a current transfer transaction of the electronic token, the transfer instruction comprising a token ID of the electronic token; authenticate at least one of a user possessing the electronic token before the current transfer transaction and a computing device of the user possessing the electronic token at a conclusion of a previous transfer transaction; receive a secret value of the previous transfer transaction utilized in generating a block hash of a data block of the previous transfer transaction of the electronic token; receiving data of the electronic token comprising: a data block of a previous transfer transaction, a state hash of the previous transfer transaction that is at least one of (i) a block hash of the data block of the previous transfer transaction as an output of a cryptographic hash function having inputs comprising a transaction data of the previous transfer transaction and the secret value of the previous transfer transaction, (ii) an output of a cryptographic hash function with inputs comprising the block hash of the data block of the previous transfer transaction, and (iii) dependent on the block hash of the data block of the previous transfer transaction, at least one of receiving and reading an instance of the state hash of the electronic token from a state datastore previously stored in association with the previous transfer transaction independently of the user possessing the electronic token; inputting the data block of the previous transfer transaction and the secret value of the previous transfer transaction into one or more hash functions to output a recalculated instance of the state hash of the electronic token after the previous transfer transaction; comparing the recalculated instance of the state hash to the electronic token to the instance of the state hash of the electronic token read from the state datastore; and determining a match between the recalculated instance of the state hash and the instance of the state hash of the electronic token read from the state datastore to validate the previous transfer transaction of the electronic token.
10 . The system of claim 9 , further comprising: a device of a user receiving the electronic token in the current transfer transaction, the device comprising: a processor of the device, a computer readable memory of the device that is non-transitory comprising computer readable instructions that, when executed on the processor of the device, cause the processor of the device to: receive the electronic token for the current transfer transaction and store the electronic token in the computer readable memory of the device, generate a data block of the current transfer transaction comprising a transaction data of the current transfer transaction; generate a secret value of the current transfer transaction; add the data block of the current transfer transaction to the electronic token; feed input data into a first cryptographic hash function, wherein the input data comprising the transaction data of the current transfer transaction, the block hash of the data block of the previous transfer transaction, and the secret value of the current transfer transaction; generate a block hash of the data block of the current transfer transaction as an output of the first cryptographic hash function; store the secret value of the current transfer transaction in the computer readable memory; and transmit to the server for subsequent validation a state hash of the current transfer transaction representing an evolved state of the electronic token that is at least one of the block hash of the data block of the current transfer transaction, an output of a cryptographic hash function with inputs comprising the block hash of the data block of the current transfer transaction, and a value that is dependent on the block hash of the data block of the current transfer transaction, to establish an independent evidence of evolution of the electronic token.
11 . The system of claim 9 , wherein the secret value of the current transfer transaction generated based on an entropic input gathered from an entropy source of the device.
12 . The system of claim 9 , wherein the state datastore stored on two or more computing nodes communicatively coupled through the network.
13 . The system of claim 12 , wherein the state datastore is rendered eventually consistent through at least one of: (i) a raft algorithm; (ii) the state datastore storing a copy of the state datastore on each of the two or more computing nodes and reconciled through a consensus mechanism executed through a consensus algorithm of each of the two or more computing nodes; and (iii) byzantine fault tolerance.
14 . The system of claim 10 , wherein the computer readable memory of the device further comprising the computer readable instructions that, when executed on the processor of the device, further cause the processor of the device to: generate a transfer instruction initiating a new transfer transaction in which possession of the electronic token to transfer to a user to receive possession of the electronic token following the new transfer transaction; generate a transaction data of the new transfer transaction; and generate a verified acceptance of the new transfer transaction from at least one of a user who received possession of the electronic token following the current transfer transaction and the user to receive possession of the electronic token following the new transfer transaction.
15 . The system of claim 14 , wherein the computer readable memory of the device further comprising the computer readable instructions that, when executed on the processor of the device, further cause the processor of the device to: read the electronic token from the computer readable memory and transmitting the electronic token to a computing device of the user to receive possession of the electronic token following the new transfer transaction; receive a transaction completion data communicating that the electronic token has undergone a state evolution associated with the new transfer transaction; and delete the electronic token, now outdated by the state evolution, from the computer readable memory.
16 . A computer readable medium that is non-transitory for processing an electronic token that can be actually possessed, the computer readable medium comprising computer readable instructions that, when executed on a processor, cause the processor to: receive the electronic token for a current transfer transaction and store the electronic token, wherein the electronic token comprising a data block of a previous transfer transaction and a block hash of the data block of the previous transfer transaction representing a state of the electronic token following the previous transfer transaction and generated as an output of a cryptographic hash function with inputs comprising a transaction data of the previous transfer transaction; generate a data block of the current transfer transaction comprising a transaction data of the current transfer transaction; generate a secret value; add the data block of the current transfer transaction to the electronic token, feed inputs into a first cryptographic hash function, wherein the inputs comprising the transaction data of the current transfer transaction, the block hash of the data block of the previous transfer transaction, and the secret value; generate a block hash of the data block of the current transfer transaction as an output of the first cryptographic hash function; store the secret value; and transmit for storage on a server a state hash representing an evolved state of the electronic token that is at least one of the block hash of the data block of the current transfer transaction, an output of a cryptographic hash function with inputs comprising the block hash of the data block of the current transfer transaction, and a value that is dependent on the block hash of the data block of the current transfer transaction, to establish an independent evidence of evolution of the electronic token.
17 . The computer readable medium of claim 16 , wherein the comprising computer readable instructions, when executed on the processor, further cause the processor to: at least one of reading and receiving two or more block hashes for two or more block previously generated in two or more transfer transactions of the electronic token, wherein the secret value generated based on an entropic input gathered from an entropy source.
18 . The computer readable medium of claim 16 , wherein the server stores the state hash representing the evolved state of the electronic token in a distributed database stored on two or more computing nodes communicatively coupled through a network, and wherein the distributed database is rendered eventually consistent through at least one of: (i) a raft algorithm; (ii) the distributed database storing a copy of the distributed database on each of the two or more computing nodes and reconciled through a consensus mechanism executed through a consensus algorithm of each of the two or more computing nodes; and (iii) byzantine fault tolerance.
19 . The computer readable medium of claim 16 , wherein the comprising computer readable instructions, when executed on the processor, further cause the processor to: generate a transfer instruction initiating a new transfer transaction in which possession of the electronic token to transfer to a user to receive possession of the electronic token following the new transfer transaction; generate a transaction data of the new transfer transaction; and generate a verified acceptance of the new transfer transaction from at least one of a user who received possession of the electronic token following the current transfer transaction and the user to receive possession of the electronic token following the new transfer transaction.
20 . The computer readable medium of claim 19 , wherein the comprising computer readable instructions, when executed on the processor, further cause the processor to: read the electronic token and transmit the electronic token to a computing device of the user to receive possession of the electronic token following the new transfer transaction; receive a transaction completion data communicating that the electronic token has undergone a state evolution associated with the new transfer transaction; and delete the electronic token, now outdated by the state evolution.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of U.S. National Phase Ser. No. 16/636,195 , filed Feb. 3, 2020, entitled EVOLVING ACTUAL POSSESSION TOKEN WITH VERIFIABLE EVOLUTION, which claims the benefit of International Patent Application No. PCT/US18/45282 under the patent cooperation treaty filed Aug. 3, 2018, entitled: EVOLVING ACTUAL POSSESSION TOKEN WITH VERIFIABLE EVOLUTION STATE, which claims the benefit of U.S. Provisional Application No. 62/541,056, filed Aug. 3, 2017, entitled: ELECTRONIC TOKEN. The patent applications identified above are incorporated here by reference in its entirety to provide continuity of disclosure. FIELD OF TECHNOLOGY This disclosure relates generally to data processing devices and, more particularly, to a method, a device, a system, and/or a manufacture of cryptographic security of an evolving actual possession token. BACKGROUND Digital technologies for representing and tracking ownership of assets are in general relatively fast and convenient compared to practices that predate data processing systems, for example paper ledgers or physically transferring possession of a large amount of a commodity. Sometimes digital technologies for representing and tracking ownership are also more accurate and secure. Asset “tokenization”, including of an asset that is a real-world and/or physical asset, can imbue the token representing the asset with properties the asset does not have, for example almost instantaneous transfer or enforced trading rules. A ledger has been used in many contexts to track ownership of the asset. However, copies of the ledger stored on separate computers may be difficult to coordinate, keep consistent, and keep safe. The ledger may also be subject to having entries changed when no transaction has taken place, for example from hacking or fraud. There may be little evidence of such manipulation of the ledger has occurred. In a distributed database, copies of the ledger may be stored on one or more computing devices and reconciled. If data is stored in a blockchain data structure, changes in entries can be detected and thus the data can made “immutable.” In a distributed ledger blockchain, a set of ledger copies stored in the blockchain data structure may be distributed over a set of computing nodes, where units of account or tokens in the ledger may represent the asset. A consensus mechanism may reconcile the ledger and prevent a value and/or token representing the asset from a “double spend. ” A capability to detect any attempted change in the data means that a tampered-with copy of the ledger can be disregarded in favor of a correct ledger copy determined through the consensus mechanism. Thus, the distributed ledger blockchain may make the ledger more consistent and more difficult to hack in some contexts. However, there may be trade-offs. The consensus mechanism may be relatively slow compared to updates of previous systems and methods for storing the ledger. Value or token may be attached to a public key, where a private key unlocks the value or token, where the private key may be vulnerable to theft or hacking resulting in loss of the value or token. In addition, the set of computing nodes running a software application that runs the distributed ledger blockchain (e.g., including a consensus algorithm) may be able to “fork”, creating diverging copies of the ledger. This may lead to confusion about which copy of the token represents the asset, especially if the asset is a physical asset in the real world. Historically, one generally useful method for tracking ownership may be possession. Possession may work well for an asset in the physical world, but may be difficult to effect in the electronic world due to the relative ease of copying electronic bits of information. In general, the electronic bits as stored in a computer memory may easily be created, deleted, or copied. Systems, methods, and/or devices for electronic ownership tracking must be carefully designed to prevent copying, double-spending, and confusion over which token is tied to which asset. SUMMARY Disclosed are a method, a device, a system, and/or a manufacture of cryptographic security of an evolving actual possession token. A system of one or more computers can be configured to perform particular operations or actions by virtue of having software, firmware, hardware, or a combination of them installed on the system that in operation causes or cause the system to perform the actions. One or more computer programs can be configured to perform particular operations or actions by virtue of including instructions that, when executed by data processing apparatus, cause the apparatus to perform the actions. In one general aspect, a method may include receiving the electronic token in a current transfer transaction and storing the electronic token in the computer memory, the electronic token having a data block of a previous transfer transaction and a block hash of t