Patent Description:
This description relates generally to the use of virtual blockchain protocols to implement a fair electronic exchange (FEE).

A public ledger is a tamperproof sequence of data that can be read and augmented. Shared public ledgers can revolutionize the way a modem society operates. Traditional transactions -such as payments, asset transfers, and titling-can be secured in an order in which they occur. New transactions-such as cryptocurrencies and smart contracts can be enabled. Corruption can be reduced, intermediaries removed, and a new paradigm for trust can be ushered in. The publication "<NPL>.

TECHNOLOGY (ICOICT), <NPL>, proposes a method for implementing a witness using block chains. Since conventional agreements use only digital signatures, the sender of the contract documents can be authenticated but there is still problem because both parties cannot perform mutual authentication and it cannot resolve a legal dispute. Therefore, a witness was required, to overcome the problems when legal dispute was occurred. For implementing the witness, block chaining is proposed. There are several works that have been proposed for realizing authentication, and one of them is using RSA proposed by Raji et al. Since RSA needs large complexity, then in this research, ECC and ECDSA is proposed. ECC and ECDSA is proposed because it has less complexity than RSA. Based on the experiment result, it is shown that legal dispute can be resolved and the security level of the proposed method is greater than RSA. Meanwhile, the complexity of ECDSA is less than digital signature based on RSA. <CIT> proposes a method for combining multiple interactions into a single record entry. A data package can be created that represents a set of interactions, and each entity associated with an interaction can review the data package. Each entity can indicate agreement with the interactions by digitally signing the data package. Once signed by each involved entity, the data package can be stored in a record such as a blockchain.

However, traditional public ledgers do not achieve their potential. Traditional public ledgers can put all trust on a single entity, who can arbitrarily refuse to publicize payments made by given keys, and is vulnerable to a cyberattack. Indeed, once the single central authority is compromised, so is the entire system. Some traditional systems are expensive to run, waste computation and other valuable resources, concentrate power in the hands of new entities (miners), suffer from considerable ambiguity (forks), and have long latency and small throughput. Other traditional implementations are permissioned, or assume the ability of punishing malicious users, or both, and/or trust that some subset of users are immune to cyberattacks for a suitably long time.

The embodiments herein relate to methods, systems, and apparatuses to implement virtual blockchain protocols, as defined by the independent claims. A first computer device generates a public key and a corresponding private key. The public key is for transmitting a message from a sender to a recipient. The first computer device is associated with the sender. The first computer device encrypts the message using the public key and a cryptographic key of the recipient to generate a first data payload. The cryptographic key of the recipient indicates an identity of the recipient. The first computer device signs a data package using a cryptographic key of the sender to generate a second data payload. The cryptographic key of the sender indicates an identity of the sender. The data package includes the identity of the sender, the identity of the recipient, the public key, and a hash function of the first data payload.

The first computer device transmits the first data payload and the second data payload to a second computer device associated with the recipient. The first computer device receives a signed version of the second data payload from the second computer device. The signed version of the second data payload is signed using the cryptographic key of the recipient. The first computer device determines that the signed version of the second data payload has been posted to a blockchain. Responsive to the determining that the signed version of the second data payload has been posted to the blockchain, the first computer device posts the private key to the blockchain for decrypting the cryptographic message by the recipient.

The benefits and advantages of the embodiments disclosed herein include reduced computation effort compared to other techniques. The blockchain remains in the background and is used very rarely, if at all, in execution of the virtual blockchain protocol. When a fair electronic exchange (FEE) is implemented using the virtual blockchain protocol, commercially equitable transactions conducted by honest parties are provided by the protocol without use of the blockchain. A party is denoted as being "honest," if the party does not attempt to obtain a benefit of a transaction at the expense of another party. On the other hand, if a first party receives the benefit of a transaction while a second party does not, the second party can invoke the blockchain to restore the commercial equitability of the transaction.

The virtual blockchain protocol provides commercially equitable exchange in a more efficient and more economical manner compared to other techniques. The blockchain intervenes very rarely in the virtual blockchain protocol. When both parties are honest, the transaction is conducted off-chain. The blockchain is utilized only when a commercially inequitable transaction occurs, to restore the commercial equitability of the transaction. Failure to perform is in fact discouraged because the advantages gained by failing to perform are reduced compared to other techniques. Transaction costs are reduced compared to other techniques because parties transact bilaterally by bypassing the blockchain, avoiding the payment of transaction fees for posting information in blocks and avoiding the wait for a new block to be generated.

Cryptoasset and other transactions, such as certified e-mail or electronically signed contracts, can be produced in a shorter time using virtual blockchain protocols compared to other techniques and transactions are finalized sooner. Further benefits and advantages include privacy and confidentiality for transactions. The virtual blockchain protocols can meet a regulatory regime they are subjected to for ensuring commercially equitable transactions. Virtual blockchain protocols can reduce the need for more complex and computationally expensive smart contracts.

A trusted third party is sometimes used to secure a transaction, for example, transmission of certified e-mail, signing and delivering an electronically signed contract, or a cryptoasset transaction. However, a transaction involving a trusted third party can be inefficient or expensive because such a trusted third party can slow down the transaction and demand remuneration for its services. A blockchain can be used in place of a trusted third party in certain settings at a reduced cost. However, a blockchain can also incur costs in terms of processing time and monetary constraints. The embodiments disclosed herein provide virtual blockchain protocols to implement a fair electronic exchange (FEE). An FEE represents a set of transactions that includes certified e-mail, electronic contract signing, and other implementations.

A virtual blockchain protocol is one that can be used to securely complete a two-party transaction in the presence of a blockchain, such that the blockchain is not used when both parties are honest and neither party incurs an additional expense. If a first party is not honest, the blockchain is minimally used by the virtual blockchain protocol, such that the second party is not disadvantaged. Hence, a virtual blockchain protocol is one in which the blockchain operates in the background and is not invoked unless a party acts in a commercially inequitable manner.

<FIG> illustrates an example virtual blockchain protocol. The illustration of <FIG> includes a sender <NUM>, a computer device <NUM>, a recipient <NUM>, a computer device <NUM>, and a blockchain <NUM>. The sender <NUM> is an entity that wishes to transmit a message M to the recipient <NUM> to perform a transaction, such as transmission of certified e-mail or a cryptoasset transaction. For example, the sender <NUM> can represent a cryptoasset account, a company, a university, or a single person, etc. The computer device <NUM> is communicably coupled to the sender <NUM> and can be a smartphone, a tablet, a laptop, or another computer device implemented using the components illustrated and described in more detail with reference to <FIG>. The recipient <NUM> is an entity for whom the message M is intended. For example, the recipient <NUM> can represent a cryptoasset account, a company, a university, or a single person, etc. The computer device <NUM> is communicably coupled to the recipient <NUM> and can be a smartphone, a tablet, a laptop, or another computer device implemented using the components illustrated and described in more detail with reference to <FIG>.

The computer devices <NUM>, <NUM> use a virtual blockchain protocol to transmit the message M from the sender <NUM> to the recipient <NUM>. The virtual blockchain protocol enables bilateral transactions, such as used to implement an FEE. When the sender <NUM> and recipient <NUM> are both honest parties, the blockchain <NUM> is in fact not used to perform the transaction. A party is denoted as being "honest," if the party does not attempt to obtain a benefit of a transaction at the expense of another party. For example, consider a scenario in which the sender <NUM> has an automobile title and the recipient has an electronic address of a cryptoasset account. Neither party initially knows the other's asset, but will recognize it can access the asset. If the sender <NUM> is "honest," it will not attempt to obtain the electronic address of the cryptoasset account while failing to transmit the automobile title to the recipient.

The sender <NUM> and recipient <NUM> may each use the blockchain <NUM> once, to register information about themselves, and can then honestly interact with other honest parties without involving the blockchain <NUM>. The registered information can include, for example, a public cryptographic key A of the sender <NUM> and a public cryptographic key B of the recipient <NUM>. The public cryptographic keys A, B are also sometimes referred to as public keys or public encryption keys. A cryptographic key can be a public key and/or a private (secret) key that is used for digitally signing, encrypting, or decrypting data, such as a message. When one of the two parties is not honest, the virtual blockchain protocol resolves the problem by enabling posting of information on the blockchain <NUM>, such that the honest party is not disadvantaged.

In some embodiments, the virtual blockchain protocol enables blocks (e.g., blocks <NUM>, <NUM>) of the blockchain <NUM> incorporate time information with a particular level of accuracy. In other embodiments, Alternatively, the virtual blockchain protocol measures time in block units. For example, posting information Y on the blockchain <NUM> within a given amount of time from the appearance of the block <NUM> results in posting Y in one of the <NUM> blocks following block <NUM>, for example, block <NUM>.

The computer device <NUM> generates a public key P and a corresponding private key S. The public key P is for transmitting the message M from the sender <NUM> to the recipient <NUM>. The sender <NUM> has its own unique identifier A, for example, a public encryption key, a public signature key, or a public cryptographic key. The sender <NUM> also has its own corresponding secret key or private decryption key. The public cryptographic key A of the sender <NUM> can be posted on the blockchain <NUM> when the sender <NUM> enrolls in a certain system, for example, a certified e-mail system. Similarly, the recipient <NUM> has a unique identifier B, for example, a public cryptographic key. The sender <NUM> can sign the message M to generate a signed message denoted by SIGA(M). The sender <NUM> can encrypt the message M to generate an encrypted message denoted by EA(M).

The computer device <NUM> encrypts the message M using the public key P and a cryptographic key B of the recipient <NUM> to generate a first data payload Z = EPB(A,B,M). The cryptographic key B of the recipient <NUM> indicates an identity of the recipient <NUM>. Any user, for example, the recipient <NUM>, can in fact encrypt the message M using the public cryptographic key A of the sender <NUM>, but only the sender <NUM> can decrypt EA(M) as long as the sender <NUM> has its corresponding private decryption key. The digital signature and encryption methods disclosed herein are non-malleable and CCA-<NUM> secure. CCA-<NUM> security refers to a ciphertext indistinguishability standard for cryptographic security. The digital signature and encryption methods disclosed herein are provably decipherable without revealing the private decryption keys. Moreover, the digital signature and encryption methods disclosed herein are secure against adaptive chosen message attacks.

The encryption described by the embodiments disclosed herein is implemented in more than one phase. For example, in a first phase, the computer device <NUM> can encrypt the message M using only the public key P to generate a data payload EP(A,B,M). In a second phase, the computer device <NUM> can encrypt the message M using the public key P as well as a one-time or temporary key O to generate a data payload EPO(A,B,M). The temporary key O is sometimes referred to as an ephemeral key. In some embodiments, encrypting the message M using the public key P includes encrypting M in a private-key cryptosystem using a private key K and encrypting the private K using P.

In some embodiments, the digital signature and encryption methods disclosed herein implement joint encryption. For example, P denotes a public encryption key and S denotes a corresponding private decryption key. Continuing the example, X denotes another public encryption key and Sx denotes a corresponding secret key of X. The computer device <NUM> can compute, from P and X, a "joint" public encryption key PX, whose corresponding joint secret (private) key includes S and Sx. The encryption of the message M using the joint public encryption key PX is denoted by Z, where Z = EPX(M). Such an encrypted message can be decrypted when a computer device can access both S and Sx. When Z = EPX(M), PX denotes a public encryption key, and Sx denotes a corresponding secret decryption key, the computer device <NUM> can jointly decrypt (P, X, S, Sx, Z) to obtain the message M. The data EPX(M) remains secure as long as only the recipient <NUM> has access to the secret keys S and Sx. When Z = EPX(M) but another key S' is not the secret decryption key corresponding to P, then the data M' obtained by jointly decrypting (P, X, S', Sx, Z) will be very different from M, and can be proven without revealing Sx.

After the computer device <NUM> has received the message M from the sender <NUM>, the computer device <NUM> generates the corresponding public and secret (private) encryption pair (P, S) and computes data Z = EPB(A, B, M), which denotes a joint encryption using P and the public cryptographic key B of the recipient <NUM>. Z denotes a first data payload and identifies the sender <NUM> by A and the recipient <NUM> by B. In some embodiments, the first data payload Z thus includes the cryptographic key B of the recipient and the cryptographic key A of the sender. The first data payload Z does not contain S. The first data payload Z thus excludes the private decryption key S needed by the recipient <NUM> to decrypt the first data payload EPB(A, B, M) and access the message M.

The computer device <NUM> signs a data package (A, B, P, t, H(Z)) using the cryptographic key A of the sender <NUM> to generate a second data payload Y. The cryptographic key A of the sender <NUM> indicates an identity of the sender <NUM>. The data package thus includes the identity of the sender <NUM>, the identity of the recipient <NUM>, the public key P, and a hash function H(Z) of the first data payload Z. In some embodiments, t denotes a deadline for either the sender <NUM> or recipient <NUM> to perform a follow-on function. For example, t can indicates a deadline for the computer device <NUM> to receive an acknowledgement of the second data payload Y from the second computer device <NUM>. In other embodiments, t specifies a future point in time after which the recipient <NUM> will be unable to restore the "fairness" of the transaction.

An exchange or transaction is denoted as being "fair" if it is commercially equitable, such that a malicious entity does not benefit at the expense of a non-malicious entity. Continuing the example above in which the sender <NUM> has an automobile title and the recipient has an electronic address of a cryptoasset account. Neither party initially knows the other's asset, but will recognize it can access the asset. In an exchange protocol, it is desired (but not guaranteed) that the parties electronically exchange their assets, that is, the sender obtains the electronic address of the cryptoasset account and the recipient <NUM> obtains the automobile title. The exchange protocol is denoted as "fair" if (without forcing an exchange against the parties' will) the protocol provides that the recipient <NUM> obtains the automobile title if and only if the sender <NUM> obtains the electronic address of the cryptoasset account. The protocol should have only two possible commercially equitable outcomes: (<NUM>) the sender <NUM> obtains the electronic address of the cryptoasset account and the recipient <NUM> obtains the automobile title, or (<NUM>) neither party obtains the other's asset.

Continuing the example illustrated in <FIG>, in some embodiments, t can be omitted or set to a large value, such as infinity. The computer device <NUM> generates the second data payload Y = SIGA(A, B, P, t, H(Z)) using the cryptographic key A of the sender <NUM>. In some embodiments, H is a collision-resistant hash function. There is, therefore, only a very low probability that two different strings C and D can be found, such that H(C)=H(D)). The hash function H(Z) is used to encode Z, such that a first size of the first data payload Y is larger than a second size of the second data payload Z.

The computer device <NUM> transmits data <NUM> (the first data payload Z and the second data payload Y) to the computer device <NUM> associated with the recipient <NUM>. Upon receiving data Y from the computer device <NUM>, in some embodiments, the computer device <NUM> determines whether the current time is sufficiently before the deadline t, such that the computer device <NUM> can restore the fairness of the transaction if needed. The computer device <NUM> digitally signs data Y to generate data <NUM> (SIGB(Y)). The data <NUM> is used as a receipt to indicate to the computer device <NUM> that the computer device <NUM> received data <NUM>. For example, the computer device <NUM> receives the signed version SIGB(Y) of the second data payload Y from the computer device <NUM>. The signed version SIGB(Y) of the second data payload Y is signed using the cryptographic key B of the recipient <NUM>. In some embodiments, the data package (A, B, P, t, H(Z)) denotes a deadline (using the value of t) for the computer device <NUM> to receive the signed version of the second data payload Y from the computer device <NUM>. For example, if t is violated, the transaction will be annulled or cancelled.

When the sender <NUM> receives the properly signed receipt (the signed version SIGB(Y) of the second data payload Y) from the recipient <NUM>, the sender <NUM> is supposed to send the data <NUM> (private key S) to the recipient <NUM>. In some embodiments, t denotes a time deadline by which the computer device <NUM> is to transmit the private key S to the computer device <NUM> after the computer device <NUM> has received the data <NUM>. If the computer device <NUM> determines that it has received the private key S at a time sufficiently earlier than the deadline t, the virtual blockchain protocol successfully completes.

In some embodiments, the computer device <NUM> determines a failure of the computer device <NUM> to receive the private key S (data <NUM>) from the computer device <NUM>. In other embodiments, the computer device <NUM> determines that the computer device <NUM> did not transmit the private key S to the computer device <NUM> by the deadline t. The FEE can thus be violated. In an example, the sender <NUM> is an automobile seller, the recipient <NUM> is an automobile buyer, and C denotes an offer to sell an automobile by the sender <NUM>. The sender <NUM> transmits data SIGA(C) to the recipient <NUM>, but the recipient <NUM> never responds. In this event, the sender <NUM> may sell its automobile to another buyer after which the recipient <NUM> claims the automobile. A party can thus recognize that it has obtained desired information, and then force the exchange to remain incomplete.

To implement an FEE, responsive to determining the failure to receive the private key S, the computer device <NUM> posts a challenge to the blockchain <NUM>. The challenge includes the signed version SIGB(Y) of the second data payload Y. The posting of the signed version SIGB(Y) to the blockchain <NUM> indicates, to the computer device <NUM>, the failure of the computer device <NUM> to receive the private key S from the computer device <NUM>. <FIG> illustrates that the computer device <NUM> posts the challenge in the block <NUM>. In some embodiments, t denotes a deadline for the computer device <NUM> to post the signed version of the second data payload Y to the blockchain <NUM>. The data package (A, B, P, t, H(Z)) thus indicates a deadline t=T1 by which time the computer device <NUM> is to post the challenge to the blockchain <NUM>. If T1 is violated, the contract is nullified or cancelled and the sender <NUM> does not need to perform. If the data SIGB(Y) appears in the blockchain <NUM> within the time t (T1), the computer device <NUM> posts the private key S on the blockchain <NUM> within a given amount of time as long as the sender <NUM> wishes to perform honestly and complete the transaction fairly. The value of t (T1) allows the sender <NUM> to upper bound the time during which the transaction stays "open. " Before sending the computer device <NUM> the receipt SIGB(Y), the recipient <NUM> can subjectively evaluate whether the recipient has time to react (by time T1) in case the computer device <NUM> does not transmit S to the recipient <NUM>.

In some embodiments, the computer device <NUM> determines that the signed version SIGB(Y) of the second data payload Y has been posted to the blockchain <NUM>. Responsive to determining that the signed version SIGB(Y) of the second data payload Y has been posted to the blockchain <NUM>, the computer device <NUM> posts the private key S to the blockchain <NUM> for decrypting the message M by the recipient <NUM>. For example, the private key S can be posted to the block <NUM>. In some embodiments, the computer device <NUM> posts the private key S to the blockchain <NUM> responsive to determining that the signed version SIGB(Y) of the second data payload Y is posted to the blockchain <NUM> at a time earlier the deadline T1. In some embodiments, t denotes a deadline T2 for the computer device <NUM> to post the private key S to the blockchain <NUM> after the signed version of the second data payload Y is posted to the blockchain <NUM> by the computer device <NUM>. The computer device <NUM> is to, therefore, post S to block <NUM> before time T2.

Continuing the example, the computer device <NUM> determines that the private key S is posted to the blockchain <NUM> by the computer device <NUM>. The computer device <NUM> decrypts the first data payload Z using the private key S to obtain the message M. On the other hand, if the computer device <NUM> fails to post S to the blockchain <NUM> within the deadline T2 after the posting of the data SIGB(Y), this signifies that the sender <NUM> agrees that the recipient <NUM> has not received the message M committed to by the function H(Z).

If the sender <NUM> acts honestly, then, given the data SIG(Y), the sender <NUM> can, by releasing M and S, prove the content of the message for which SIGB(Y) is a receipt. Any entity can verify that S is the decryption key corresponding to P, and that the joint encryption of (A, B, M) relative to P and the cryptographic key B of the recipient <NUM> is indeed Z. Thus, any entity can verify that, given S, the recipient <NUM> can recover M. If the recipient <NUM> never received S, the computer device <NUM> is to timely post Y on the blockchain <NUM>, such that the sender <NUM> is to publicly post S or publicly agree that the recipient <NUM> is "off the hook" relative to receiving the message M. For example, if the computer device <NUM> fails to timely post the private key S after Y has been timely posted to the blockchain <NUM>, then the sender <NUM> can be caused to reimburse the recipient <NUM> for (at least some of) the transaction costs for posting Y to the blockchain <NUM>.

In some embodiments, rather than using the single encryption EPX(A, B, M), the sender <NUM> can use two (or more) encryptions to transmit M, relative to different public keys. In some embodiments, the sender <NUM> can register multiple public encryption keys in the blockchain <NUM>. In other embodiments, the recipient <NUM> may not have any registered public encryption key, but can generate the one(s) needed when the sender <NUM> alerts the recipient <NUM> that the sender <NUM> will transmit a certified message, for example, M. For example, the recipient <NUM> may possess only public signature key(s) and use them to authenticate any public encryption key the recipient <NUM> needs for the virtual blockchain protocol.

When receiving the value Z = EPX(A, B, M) from the computer device <NUM>, the recipient is unable to readily decrypt M from Z (because S is not yet available). Thus, if the recipient <NUM> halts processing, the sender <NUM> will not receive the receipt SIGB(Y), and the recipient <NUM> will not receive the message M either. If the computer device <NUM> transmits the receipt SIGB(Y) to the computer device <NUM>, then the sender <NUM> receives a valid receipt from the recipient <NUM> for the message M. Thus, for the exchange of the message M and the receipt SIGB(Y) to be fair, the recipient <NUM> should be able to readily easily obtain M. The FEE is implemented when the sender <NUM> transmits the private key S. If the sender <NUM> does not transmit the private key S, then the computer device <NUM> is to timely post the receipt SIGB(Y) to the blockchain <NUM>, essentially requesting the computer device <NUM> to timely post S to the blockchain <NUM>.

In some embodiments, the virtual blockchain protocol disclosed herein is used to implement an electronic checks and transfers system (outside the blockchain <NUM>). For example, the recipient <NUM> is able to access the money from an electronic check if and only if the sender <NUM> receives a receipt that the recipient <NUM> received the check. In some embodiments, the virtual blockchain protocol disclosed herein can be used to implement a system in which an agent has an obligation to inform another agent (for example, regarding a deadline to exercise an option). The system performs in a manner that proves the agent complied with their obligations (for example, to inform a board of directors to notify employees of their option deadlines).

In some embodiments, the virtual blockchain protocol disclosed herein is used to implement a subscription-based model. In a subscription-based model, an entity is required to pay a recurring price at regular intervals for access to a product or service. To obtain the ability to use the blockchain, when needed, to restore the fairness of a transaction, the sender <NUM> and recipient <NUM> may be required to pay a monthly or annual subscription fee, for example, by posting a transaction to the blockchain <NUM>, specifying a particular string (that denotes the type of service sought) and paying a fee. The type of service can be certified e-mail, electronically signed contracts, etc. The fee can be (a) paid to an entity (for example, a company, a foundation, etc.) that is responsible for maintaining the blockchain <NUM>, (b) incorporated in a pool of transactions fees to be distributed to users contributing to the maintenance of the blockchain <NUM>, (c) paid to a particular entity or user E, or (d) a combination thereof. If, for example, the recipient <NUM> has not paid such a subscription fee, then it is not enabled to use the blockchain <NUM> to restore fairness.

The advantages and benefits of the virtual blockchain protocol subscription-based model include the ability for users to perform multiple honest, fair exchanges at no additional cost. The company or foundation maintaining the blockchain <NUM> benefits from the subscription fees for providing a service that does not involve the company or foundation further in each transaction. If the subscription fees are incorporated into a transaction pool, the beneficiaries of the pool benefit further when a cheated user (for example, recipient <NUM>) utilizes the blockchain <NUM> to post the data SIGB(Y) that restores the fairness of the transaction. In the virtual blockchain protocol, a user agrees to pay a subscription fee a priori. An a posteriori transaction fee is paid only for transactions in which cheating occurs. In traditional blockchain-based techniques, a user must agree to pay an a priori transaction fee for each transaction even when all parties are honest, because cheating can occur. Moreover, a subscriber F in a virtual blockchain protocol subscription-based model can represent a set of users rather than a single user. For example, F can represent a law firm and the subscription fee paid by F can be proportional to a numbers of users that use an FEE service implemented by the virtual blockchain protocol subscription-based model. In some embodiments, F can act on behalf of all users. For example, in a CEM system, F can represent a computer server that provides receipts for messages addressed to some of its users, and then distributes the messages internally as needed. The computer server can be implemented using the components illustrated and described in more detail with reference to <FIG>.

<FIG> illustrates a process for virtual blockchain protocols. In some embodiments, the process of <FIG> is performed by the computer device <NUM> illustrated and described in more detail with reference to <FIG>. Other entities perform some or all of the steps of the process in other embodiments. Likewise, embodiments may include different and/or additional steps, or perform the steps in different orders.

The computer device <NUM> generates <NUM> a public key P and a corresponding private key S. The public key P and private key S are illustrated and described in more detail with reference to <FIG>. The public key P is for transmitting a message M from a sender <NUM> to a recipient <NUM>. The message M, sender <NUM>, and recipient <NUM> are illustrated and described in more detail with reference to <FIG>. The computer device <NUM> is associated with the sender <NUM>.

The computer device <NUM> encrypts <NUM> the message M using the public key P and a cryptographic key B of the recipient <NUM> to generate a first data payload Z. The cryptographic key B of the recipient <NUM> indicates an identity of the recipient <NUM>. The first data payload Z is expressed as EPB(A,B,M). Any user, for example, the recipient <NUM>, can in fact encrypt the message M using the public cryptographic key A of the sender <NUM>, but only the sender <NUM> can decrypt EA(M) as long as the sender <NUM> has its corresponding private decryption key.

The computer device <NUM> signs <NUM> a data package (A, B, P, t, H(Z)) using a cryptographic key A of the sender <NUM> to generate a second data payload Y. The cryptographic key A of the sender <NUM> indicates an identity of the sender <NUM>. The data package includes the identity of the sender <NUM>, the identity of the recipient <NUM>, the public key P, and a hash function H(Z) of the first data payload. In some embodiments, t denotes a deadline for either the sender <NUM> or recipient <NUM> to perform a follow-on function. For example, t can indicates a deadline for the computer device <NUM> to receive an acknowledgement of the second data payload Y from the second computer device <NUM>. In other embodiments, t specifies a future point in time after which the recipient <NUM> will be unable to restore the fairness of the transaction.

The computer device <NUM> transmits <NUM> the first data payload Z and the second data payload Y to a computer device <NUM> associated with the recipient <NUM>. Upon receiving data Y from the computer device <NUM>, in some embodiments, the computer device <NUM> determines whether the current time is sufficiently before the deadline t, such that the computer device <NUM> can restore the fairness of the transaction if needed. The computer device <NUM> digitally signs data Y to generate data <NUM> (SIGB(Y)). The data <NUM> is used as a receipt to indicate to the computer device <NUM> that the computer device <NUM> received data <NUM>. The data <NUM> and data <NUM> are illustrated and described in more detail with reference to <FIG>.

The computer device <NUM> receives <NUM> the signed version SIGB(Y) of the second data payload Y from the computer device <NUM>. The signed version SIGB(Y) of the second data payload Y is signed using the cryptographic key B of the recipient <NUM>. In some embodiments, the data package (A, B, P, t, H(Z)) denotes a deadline (using the value of t) for the computer device <NUM> to receive the signed version of the second data payload Y from the computer device <NUM>. For example, if t is violated, the transaction will be annulled or cancelled.

The computer device <NUM> determines <NUM> that the signed version SIGB(Y) of the second data payload Y has been posted to the blockchain <NUM> by the computer device <NUM>. When the sender <NUM> receives the properly signed receipt (the signed version SIGB(Y) of the second data payload Y) from the recipient <NUM>, the sender <NUM> is supposed to send the data <NUM> (private key S) to the recipient <NUM>. The data <NUM> is illustrated and described in more detail with reference to <FIG>. When the computer device <NUM> determines a failure of the computer device <NUM> to receive the private key S (data <NUM>) from the computer device <NUM>, the computer device <NUM> posts the signed version SIGB(Y) of the second data payload Y to the blockchain <NUM>.

Responsive to determining that the signed version of the second data payload Y has been posted to the blockchain <NUM>, the computer device <NUM> posts <NUM> the private key S to the blockchain <NUM> for decrypting the message M by the recipient <NUM>. In some embodiments, t denotes a deadline T2 for the computer device <NUM> to post the private key S to the blockchain <NUM> after the signed version of the second data payload Y is posted to the blockchain <NUM> by the computer device <NUM>. The computer device <NUM> is to, therefore, post S to block <NUM> before time T2.

<FIG> illustrates an example machine. In the implementation of <FIG>, the computer system <NUM> is a special purpose computing device. The special-purpose computing device is hard-wired to execute blockchain protocols, includes digital electronic devices such as one or more application-specific integrated circuits (ASICs) or field programmable gate arrays (FPGAs) that are persistently programmed to perform the techniques herein, or includes one or more general purpose hardware processors programmed to perform the techniques pursuant to program instructions in firmware, memory, other storage, or a combination. In various implementations, the special-purpose computing devices are desktop computer systems, portable computer systems, handheld devices, network devices or any other device that incorporates both hard-wired or program logic to implement the techniques.

The computer system <NUM> includes a bus <NUM> or other communication mechanism for communicating information, and one or more computer hardware processors <NUM> coupled to the bus <NUM> for processing information. In some implementations, the hardware processors <NUM> are general-purpose microprocessors. The computer system <NUM> also includes a main memory <NUM>, such as a random-access memory (RAM) or other dynamic storage device, coupled to the bus <NUM> for storing information and instructions to be executed by processors <NUM>. In one implementation, the main memory <NUM> is used for storing temporary variables or other intermediate information during execution of instructions to be executed by the processors <NUM>. Such instructions, when stored in non-transitory storage media accessible to the processors <NUM>, render the computer system <NUM> into a special-purpose machine customized to perform the operations specified in the instructions.

In an implementation, the computer system <NUM> further includes a read only memory (ROM) <NUM> or other static storage device coupled to the bus <NUM> for storing static information and instructions for the processors <NUM>. A storage device <NUM>, such as a magnetic disk, optical disk, solid-state drive, or three-dimensional cross point memory is provided and coupled to the bus <NUM> for storing information and instructions.

In an implementation, the computer system <NUM> is coupled via the bus <NUM> to a display <NUM>, such as a cathode ray tube (CRT), a liquid crystal display (LCD), plasma display, light emitting diode (LED) display, or an organic light emitting diode (OLED) display for displaying information to a computer user. An input device <NUM>, including alphanumeric and other keys, is coupled to bus <NUM> for communicating information and command selections to the processors <NUM>. Another type of user input device is a cursor controller <NUM>, such as a mouse, a trackball, a touch-enabled display, or cursor direction keys for communicating direction information and command selections to the processors <NUM> and for controlling cursor movement on the display <NUM>.

According to one implementation, the techniques herein are performed by the computer system <NUM> in response to the processors <NUM> executing one or more sequences of one or more instructions contained in the main memory <NUM>. Such instructions are read into the main memory <NUM> from another storage medium, such as the storage device <NUM>. Execution of the sequences of instructions contained in the main memory <NUM> causes the processors <NUM> to perform the process steps described herein. In alternative implementations, hard-wired circuitry is used in place of or in combination with software instructions.

The term "storage media" as used herein refers to any non-transitory media that store both data or instructions that cause a machine to operate in a specific fashion. Such storage media includes both non-volatile media or volatile media. Non-volatile media includes, such as optical disks, magnetic disks, solid-state drives, or three-dimensional cross point memory, such as the storage device <NUM>. Common forms of storage media include, such as a floppy disk, a flexible disk, hard disk, solid-state drive, magnetic tape, or any other magnetic data storage medium, a CD-ROM, any other optical data storage medium, any physical medium with patterns of holes, a RAM, a PROM, and EPROM, a FLASH-EPROM, NV-RAM, or any other memory chip or cartridge. Storage media is distinct from but is used in conjunction with transmission media. Transmission media includes coaxial cables, copper wire and fiber optics, including the wires that include the bus <NUM>.

In an implementation, various forms of media are involved in carrying one or more sequences of one or more instructions to the processors <NUM> for execution. The instructions are initially carried on a magnetic disk or solid-state drive of a remote computer. The remote computer loads the instructions into its dynamic memory and send the instructions over a telephone line using a modem. A modem local to the computer system <NUM> receives the data on the telephone line and use an infrared transmitter to convert the data to an infrared signal. An infrared detector receives the data carried in the infrared signal and appropriate circuitry places the data on the bus <NUM>. The bus <NUM> carries the data to the main memory <NUM>, from which processors <NUM> retrieves and executes the instructions. The instructions received by the main memory <NUM> are optionally stored on the storage device <NUM> either before or after execution by processors <NUM>.

The computer system <NUM> also includes a communication interface <NUM> coupled to the bus <NUM>. The communication interface <NUM> provides a two-way data communication coupling to a network link <NUM> connected to a local network <NUM>. The communication interface <NUM> is an integrated service digital network (ISDN) card, cable modem, satellite modem, or a modem to provide a data communication connection to a corresponding type of telephone line. In another implementation, the communication interface <NUM> is a local area network (LAN) card to provide a data communication connection to a compatible LAN. In some implementations, wireless links are also implemented.

The network link <NUM> typically provides data communication through one or more networks to other data devices. The network link <NUM> provides a connection through the local network <NUM> to a host computer <NUM> or to a cloud data center or equipment operated by an Internet Service Provider (ISP) <NUM>. The ISP <NUM> in turn provides data communication services through the world-wide packet data communication network now commonly referred to as the "Internet" <NUM>. The local network <NUM> and Internet <NUM> both use electrical, electromagnetic or optical signals that carry digital data streams.

Any or all of the features and functions described above can be combined with each other, except to the extent it may be otherwise stated above or to the extent that any such embodiments may be incompatible by virtue of their function or structure, as will be apparent to persons of ordinary skill in the art. Unless contrary to physical possibility, it is envisioned that (i) the methods/steps described herein may be performed in any sequence and/or in any combination, and that (ii) the components of respective embodiments may be combined in any manner.

In the drawings, specific arrangements or orderings of schematic elements, such as those representing devices, modules, instruction blocks and data elements, are shown for ease of description. However, it should be understood by those skilled in the art that the specific ordering or arrangement of the schematic elements in the drawings is not meant to imply that a particular order or sequence of processing, or separation of processes, is required. Further, the inclusion of a schematic element in a drawing is not meant to imply that such element is required in all embodiments or that the features represented by such element may not be included in or combined with other elements in some embodiments.

Further, in the drawings, where connecting elements, such as solid or dashed lines or arrows, are used to illustrate a connection, relationship, or association between or among two or more other schematic elements, the absence of any such connecting elements is not meant to imply that no connection, relationship, or association can exist. In other words, some connections, relationships, or associations between elements are not shown in the drawings so as not to obscure the disclosure. In addition, for ease of illustration, a single connecting element is used to represent multiple connections, relationships or associations between elements. For example, where a connecting element represents a communication of signals, data, or instructions, it should be understood by those skilled in the art that such element represents one or multiple signal paths (e.g., a bus), as may be needed, to affect the communication.

Claim 1:
A method comprising:
generating (<NUM>), by a first computer device, a public key and a corresponding private key, the public key for transmitting a message from a sender to a recipient, the first computer device associated with the sender;
encrypting (<NUM>), by the first computer device, the message using the public key and a cryptographic key of the recipient to generate a first data payload, the cryptographic key of the recipient indicating an identity of the recipient;
signing (<NUM>), by the first computer device, a data package using a cryptographic key of the sender to generate a second data payload, the cryptographic key of the sender indicating an identity of the sender, the data package comprising the identity of the sender, the identity of the recipient, the public key, and a hash function of the first data payload;
transmitting (<NUM>), by the first computer device, the first data payload and the second data payload to a second computer device associated with the recipient;
receiving (<NUM>), by the first computer device, a signed version of the second data payload from the second computer device, the signed version of the second data payload signed using the cryptographic key of the recipient;
determining (<NUM>), by the first computer device, that the signed version of the second data payload has been posted to a blockchain; characterized in that the method further comprises:
responsive to the determining that the signed version of the second data payload has been posted to the blockchain, posting (<NUM>), by the first computer device, the private key to the blockchain for decrypting the message by the recipient.