Conditional offline system with offline reversal

Abstract

A method includes a first user device generating an interaction message during an interaction between the first user device and a second user device. The interaction message includes an amount, an expiry time, and a condition. The first user device can provide the interaction message to the second user device. The second user device can obtain a witness that satisfies the condition. The first user device can receive the witness or a proof. The first user device can verify that the witness satisfies the condition or the validity of the proof. A transfer of the amount from a first user to a second user according to the interaction is facilitated using a blockchain.

Description

CONDITIONAL OFFLINE SYSTEM WITH OFFLINE REVERSALBACKGROUND

[0001] Digital interactions traditionally rely on online communications with intermediary server computers to authorize interactions. While such networks are usually designed to be highly available with continuous uptime, a user may occasionally experience little or no access to these networks. Previous solutions that allow interactions to happen offline between two clients could partially solve this problem. Such previous solutions allow two clients to transfer funds in an offline manner, but the recipient of funds must contact a managing server computer to claim and ultimately obtain the funds. However, the prior solutions have some drawbacks, making them fall short of the convenience and the resiliency of traditional fiat currency interactions. For example, these solutions expect that either (1 ) the recipient to accept the risk that the sender may not have sufficient funds available online, or (2) the same funds may potentially be spent offline before the recipient claims them online. These assumptions require that any transacting offline clients be capable of contacting a managing server computer to complete any offline payment transactions. This can make the circulation of funds dependent on the clients being online, contradicting the real-time nature of fiat interactions that make them convenient.

[0002] Improvements in conditional offline payment systems (OPS) can allow clients of a trusted server to spend money offline without imposing any risk on either client, while allowing them to spend the funds they receive offline without going online. Moreover, OPS allows clients to recover their offline funds in case of device loss. OPS also prevents double spending by relying on trusted execution environments (TEEs) that are widely available today (e.g., on smartphones and smartwatches).

[0003] However, one of the drawbacks of the conditional OPS protocol is that under certain circumstances, parties have to go online and interact with a server. For example, to reverse a conditional interaction a user device is required to communicate with the server to reobtain their funds.

[0004] Embodiments of the disclosure address this problem and other problems individually and collectively.SUMMARY

[0005] One embodiment is related to a method comprising: generating, by a first user device, an interaction message during an interaction between the first user device and a second user device, wherein the interaction message includes an amount, an expiry time, and a condition; providing, by the first user device, the interaction message to the second user device, wherein the second user device obtains a witness that satisfies the condition; receiving, by the first user device, the witness or a proof; and verifying, by the first user device, that the witness satisfies the condition or the validity of the proof, wherein a transfer of the amount from a first user to a second user according to the interaction is facilitated using a blockchain.

[0006] Another embodiment is related to a first user device comprising: a processor; and a computer-readable medium coupled to the processor, the computer-readable medium comprising code executable by the processor for implementing a method comprising: generating an interaction message during an interaction between the first user device and a second user device, wherein the interaction message includes an amount, an expiry time, and a condition; providing the interaction message to the second user device, wherein the second user device obtains a witness that satisfies the condition; receiving the witness or a proof; and verifying that the witness satisfies the condition or the validity of the proof, wherein a transfer of the amount from a first user to a second user according to the interaction is facilitated using a blockchain.

[0007] Another embodiment is related to a method comprising: receiving, by second user device, an interaction message during an interaction between a first user device and the second user device from the first user device, wherein the interaction message includes an amount, an expiry time, and a condition, the interaction message generated by the first user device; obtaining, by the second user device, a witness that satisfies the condition; and providing, by the second user device, the witness to the first user device or to a blockchain network, wherein the first user device obtains the witness from the second user device or a proof ofpublication of the witness in a blockchain from the blockchain network, wherein the first user device verifies that the witness satisfies the condition or verifies the validity of the proof, wherein a transfer of the amount from a first user to a second user according to the interaction is facilitated using the blockchain.

[0008] Further details regarding embodiments of the disclosure can be found in the Detailed Description and the Figures.BRIEF DESCRIPTION OF THE DRAWINGS

[0009] FIG. 1 shows a block diagram of a conditional offline interaction system according to embodiments.

[0010] FIG. 2 shows a block diagram of components of a user device according to embodiments.

[0011] FIG. 3 shows a flow diagram of a conditional offline interaction utilizing a blockchain according to embodiments.

[0012] FIG. 4 shows a flow diagram of a conditional offline interaction where a sender has write access to a blockchain according to embodiments.

[0013] FIG. 5 shows a flow diagram of a conditional offline interaction where a receiver has write access to a blockchain according to embodiments.

[0014] FIG. 6 shows a flow diagram of a conditional offline interaction where a sender and a receiver both include trusted execution environments method according to embodiments.

[0015] FIG. 7 shows a diagram of a blockchain according to embodiments of the present invention.DETAILED DESCRIPTION

[0016] Prior to discussing embodiments of the disclosure, some terms can be described in further detail.

[0017] A “user device” may be a device that is operated by a user. Examples of user devices may include a mobile phone, a smart phone, a card, a personal digital assistant (PDA), a laptop computer, a desktop computer, a server computer, avehicle such as an automobile, a thin-client device, a tablet PC, etc. Additionally, user devices may be any type of wearable technology device, such as a watch, earpiece, glasses, etc. The user device may include one or more processors capable of processing user input. The user device may also include one or more input sensors for receiving user input. There are a variety of input sensors capable of detecting user input, such as accelerometers, cameras, microphones, etc. The user input obtained by the input sensors may be from a variety of data input types, including, but not limited to, audio data, visual data, or biometric data. The user device may comprise any electronic device that may be operated by a user, which may also provide remote communication capabilities to a network. Examples of remote communication capabilities include using a mobile phone (wireless) network, wireless data network (e.g., 3G, 4G or similar networks), Wi-Fi, Wi-Max, or any other communication medium that may provide access to a network such as the Internet or a private network.

[0018] A “user” may include an individual. In some embodiments, a user may be associated with one or more personal accounts and / or mobile devices. The user may also be referred to as a cardholder, account holder, or consumer in some embodiments. In some embodiments, a resource provider can be a user and may operate a user device.

[0019] A “secure element” can include an element that is secure. A secure element can include a cryptographically secure computer-on-a-chip or microprocessor. A secure element can carry out cryptographic operations and may be embedded in a packaging with one or more physical security measures. In some embodiments, a secure element can include a component that can perform a function securely. A secure element may be a memory that securely stores data, such that its access is protected. A secure element can include a trusted execution environment on a secure area of a processor. An example of a secure element is a universal integrated-circuit card (IIICC). Another example of a secure element is an embedded secure element, an embedded hardware component in a larger mechanical or electrical system. Another example of a secure element is a hardware security module (HSM), which is a physical computing device that can safeguard andmanage cryptographic keys for authentication and provide crypto-processing functions.

[0020] A “trusted execution environment” (TEE) can include a secure area. A trusted execution environment can be a software stack stored on a read-only memory (ROM). A trusted execution environment can be included within a secure element. A trusted execution environment software stack can include of a set of resources to access the secure element, a trusted operating system (TOS) that provides a developer access to the underlying secure element, and one or more trusted applications (TA) that implement application-specific functionalities within the trusted application environment.

[0021] In some embodiments, a trusted execution environment can be an isolated execution environment that provides security features such as isolated execution, integrity of applications executing with the trusted execution environment, along with confidentiality of their assets. A trusted execution environment can offer an execution space that provides a higher level of security for trusted applications running on the device than a rich operating system and more functionality than a secure element alone.

[0022] A “trusted application” can include an application that is implemented within a trusted execution environment. A trusted application may perform specific functionalities. A trusted application can be paired with an application-specific client application (CA) that resides outside of the isolated trusted execution environment space and provides user-facing functionalities by interacting with the trusted application through the trusted operating system.

[0023] An “interaction” may include a reciprocal action or influence. An interaction can include a communication, contact, or exchange between parties, devices, and / or entities. Example interactions include a transaction between two parties and a data exchange between two devices. In other embodiments, an interaction can include a payment transaction in which two devices can interact to facilitate a payment.

[0024] “Interaction data” can include data related to and / or recorded during an interaction. In some embodiments, interaction data can be transaction data of thenetwork data. Transaction data can comprise a plurality of data elements with data values.

[0025] “Credentials” may comprise any evidence of authority, rights, or entitlement to privileges. For example, access credentials may comprise permissions to access certain tangible or intangible assets, such as a building or a file. Examples of credentials may include passwords, passcodes, or secret messages. In another example, payment credentials may include any suitable information associated with and / or identifying an account (e.g., a payment account and / or payment device associated with the account). Such information may be directly related to the account or may be derived from information related to the account. Examples of account information may include an “account identifier” such as a PAN (primary account number or “account number”), a token, a subtoken, a gift card number or code, a prepaid card number or code, a user name, an expiration date, a CW (card verification value), a dCVV (dynamic card verification value), a CVV2 (card verification value 2), a CVC3 card verification value, etc. An example of a PAN is a 16-digit number, such as “4147 0900 0000 1234”. In some embodiments, credentials may be considered sensitive information.

[0026] An “amount” can include a quantity of something. An amount can include a total of a thing or things in number, size, value, or extent.

[0027] An “offline amount” can include a quantity of something that may be used when offline (i.e. , when direct communication with a server computer is not present). An offline amount can be stored locally on a user device. For example, an offline amount can be stored in a secure element on a user device. An offline amount can be utilized during an offline interaction. For example, a first user can select to provide an amount to a second user while the first user’s device is not connected to or in communication with a server computer (e.g., is not online). The first user device can deduct the amount to be provided from the offline amount stored in the secure element.

[0028] An “online amount” can include a quantity of something that may be used when online. An online amount can be stored on a server computer. For example, a plurality online amounts associated with a plurality of users can be stored on a server computer and / or a database maintained by the server computer. In someembodiments, an online amount can be utilized during an online interaction. In other embodiments, an amount from the online amount on a server computer can be transferred to an offline amount on a user device. For example, a server computer can deduct an amount from an online amount associated with a first user, then provide the amount in a secure message to a first user device. The first user device can include the received amount into an offline amount stored in a secure element.

[0029] A “resource provider” may be an entity that can provide a resource such as goods, services, information, and / or access. Examples of resource providers includes merchants, data providers, transit agencies, governmental entities, venue and dwelling operators, etc.

[0030] The term “verification” and its derivatives may refer to a process that utilizes information to determine whether an underlying subject is valid under a given set of circumstances. Verification may include any comparison of information to ensure some data or information is correct, valid, accurate, legitimate, and / or in good standing.

[0031] The term "public / private key pair" may include a pair of linked cryptographic keys generated by an entity. The public key may be used for functions such as encrypting a message to send to the entity or for verifying a digital signature which was supposedly made by the entity. The private key may be used for functions such as decrypting a received message or applying a digital signature. The public key can be authorized by a certificate authority, which can store the public key in a database and distribute it to any other entity which requests the public key. The private key can be kept in a secure storage medium and will usually only be known to the entity. However, the cryptographic systems described herein may feature key recovery mechanisms for recovering lost keys and avoiding data loss. Public and private keys may be in any suitable format, including those based on Rivest-Shamir- Adleman (RSA) or elliptic curve cryptography (ECC).

[0032] A "digital signature" may include a type of electronic signature. A digital signature may encrypt documents with digital codes that can be difficult to duplicate. In some embodiments, a digital signature may refer to the result of applying an algorithm based on a public / private key pair, which allows a signing party to manifest, and a verifying party to verify, the authenticity and integrity of a document.The signing party acts by means of the private key and the verifying party acts by means of the public key. This process certifies the authenticity of the sender, the integrity of the signed document and the so-called principle of nonrepudiation, which does not allow disowning what has been signed. A certificate or other data that includes a digital signature by a signing party is said to be "signed" by the signing party.

[0033] A "certificate" or "digital certificate" may include an electronic document and / or data file. In some cases, the certificate or the digital certificate may be a device certificate. In some embodiments, a digital certificate may use a digital signature to bind a public key with data associated with an identity. A digital certificate may be used to prove the ownership of a public key. The certificate may include one or more data fields, such as the legal name of the identity, a serial number of the certificate, a valid-from and valid-to date for the certificate, certificate related permissions, etc. A certificate may contain a "valid-from" date indicating the first date the certificate is valid, and a "valid-to" date indicating the last date the certificate is valid. A certificate may also contain a hash of the data in the certificate including the data fields. A certificate can be signed by a certificate authority.

[0034] A "certificate authority" may include an entity that issues digital certificates. A certificate authority may prove its identity using a certificate authority certificate, which includes the certificate authority’s public key. A certificate authority certificate may be signed by another certificate authority’s private key or may be signed by the same certificate authority’s private key. The latter is known as a selfsigned certificate. The certificate authority may maintain a database of all certificates issued by the certificate authority. The certificate authority may maintain a list of revoked certificates. The certificate authority may be operated by an entity, for example, a processing network entity, an issuer, an acquirer, a central bank etc.

[0035] A “witness” can include evidence or proof of something. In some embodiments, a “witness” can be a term used in cryptography, that can be a tuple (or other value) that can be used to verify an expected result. A witness can be input into a condition that can evaluate the witness. For example, a witness can include proof of an event, such as transferring a resource during an interaction. A witness can be a preimage that satisfies a condition. A preimage can include, for a givenfunction, the set of all elements of the domain that are mapped into a given subset of the codomain. Specifically, given a function / : X — > Y and a subset B c Y, the set / -1 (B) = {x e X : / (x) e B}. A witness can be a receipt or interaction related data created during the interaction that is capable of satisfying a predetermined condition.

[0036] A “condition” can include a state of affairs that must exist or be brought about before something else is possible or permitted. A condition can be a condition function that evaluates whether or not something is permitted. A condition can accept a witness as input. A condition can be evaluated on whether or not a witness satisfies the condition. A condition can be a mathematical function that takes a witness as input and outputs a value of 1 if the witness satisfies the condition and outputs a value other than 1 if the witness does not satisfy the condition.

[0037] A “blockchain” can be a distributed database that maintains a continuously-growing list of records secured from tampering and revision. A blockchain may include a number of blocks of data. Each block in the blockchain can contain also include a timestamp and a link to a previous block. Stated differently, data in a blockchain may be stored as a series of “blocks,” or permanent files that include a record of data (e.g., a number of interactions, interaction messages, etc.) occurring over a given period of time. Blocks may be appended to a blockchain by an appropriate node after it completes the block and the block is validated. Each block can be associated with a block header. In embodiments of the invention, a blockchain may be distributed, and a copy of the blockchain may be maintained at each full node in a verification network. Any node within the verification network may subsequently use the blockchain to verify interactions.

[0038] A “processor” may include a device that processes something. In some embodiments, a processor can include any suitable data computation device or devices. A processor may comprise one or more microprocessors working together to accomplish a desired function. The processor may include a CPU comprising at least one high-speed data processor adequate to execute program components for executing user and / or system -generated requests. The CPU may be a microprocessor such as AMD's Athlon, Duron and / or Opteron; IBM and / or Motorola's PowerPC; IBM's and Sony's Cell processor; Intel's Celeron, Itanium, Pentium, Xeon, and / or XScale; and / or the like processor(s).

[0039] A “memory” may be any suitable device or devices that can store electronic data. A suitable memory may comprise a non-transitory computer readable medium that stores instructions that can be executed by a processor to implement a desired method. Examples of memories may comprise one or more memory chips, disk drives, etc. Such memories may operate using any suitable electrical, optical, and / or magnetic mode of operation.

[0040] A “server computer” may include a powerful computer or cluster of computers. For example, the server computer can be a large mainframe, a minicomputer cluster, or a group of servers functioning as a unit. In one example, the server computer may be a database server coupled to a Web server. The server computer may comprise one or more computational apparatuses and may use any of a variety of computing structures, arrangements, and compilations for servicing the requests from one or more client computers.

[0041] Traditionally, digital payments are made over account-based systems, where the ownership of funds is tied to user identities. One of the core features of physical cash is the ability to transact and settle offline with a counter-party in a point-to-point manner without any intermediaries.

[0042] Card payment networks can provide some form of offline payments for situations where the acceptance device (e.g., a card terminal) cannot connect to payment providers for authorization. These payments require the receiver device to be at risk of not obtaining an agreed upon amount from the sender device during the interaction. Additionally, there is the technical problem of the sender device utilizing the same amount multiple times since there is no central server in constant communication (e.g., a double spending attack). Embodiments provide for solutions to tackle this technical problem by relying on what is known as a trusted execution environment (TEE), an isolated area of a main processor that guarantees code and data loaded into them is protected with respect to integrity and confidentiality. Being validated and provisioned through an initial trusted setup with a remote, trusted server, a TEE is then allowed to store a balance and sign interaction objects using a private key that is stored securely inside the TEE.

[0043] A limitation of existing offline interaction solutions is that they do not allow a receiving device to spend the money they receive as part of an offlinepayment immediately; the receiving device has to go online to communicate with a remote, trusted third party to first “claim” the received funds and then move them to the receiving device’s TEE for future offline payments. This is a departure from the convenience that fiat interactions provide with the real-time availability of funds.

[0044] Furthermore, a feature missing in previous offline payment solutions that could generally apply to any digital system is the ability to recover the system’s state in case of failures or reversals.

[0045] Embodiments solve the technical problems of allowing offline payments between two clients (1 ) without creating any counter-party risk on either client, while (2) allowing the recipient to spend the funds without going online, and (3) allow clients to recover their unspent funds in case of device loss.

[0046] Embodiments of the disclosure allow for a conditional offline system with offline interaction reversal, and provide for technical solutions and advantages relative to the technical problems. The user devices can be offline from a management server computer that maintains online balances for the user devices. Each user device, if it includes a trusted execution environment, can maintain an offline balance. The user devices can interact (e.g., transact) with one another without communicating with the server computer during the interaction.Embodiments advantageously provide for methods and systems that allow for reversal of offline interactions between two user devices, even though the user devices are not able to communicate with the management server computer.

[0047] The user devices can communicate with a blockchain network to include data related to the interaction into the blockchain such that there is a proof of publication of the data that is provable to other user devices. The blockchain network comprises a network of computers that manage a blockchain. Because of its distributed nature, the update of the blockchain is not reliant upon the persistent online availability of a single management server computer. Furthermore, the blockchain network does not need advanced or active processing capabilities that are directed to implementing methods for the user devices. The blockchain can store data and can provide proofs of publication of the data, but does not need to actively verify the data as a management server computer would.

[0048] Embodiments also solve a technical problem of having reversable interactions that can be reversed while two devices interaction offline from a server computer that maintains online balances for the devices and provides the offline balances to the devices.

[0049] Embodiments provide for a method where a first user device generates an interaction message during an interaction between the first user device and a second user device. The interaction message includes an amount, an expiry time, and a condition. The first user device provides the interaction message to the second user device. The second user device obtains a witness that satisfies the condition. The first user device receives the witness or a proof. The first suer device then verifies that the witness satisfies the condition or the validity of the proof. A transfer of the amount from a first user to a second user according to the interaction is facilitated using a blockchain.

[0050] FIG. 1 shows a system 100 according to embodiments of the disclosure. The system 100 comprises a first user device 102, a server computer 104, a second user device 106, a plurality of user devices 108, a certificate authority computer 110, and a blockchain network 112. The first user device 102 can include a trusted execution environment 114 and a rich execution environment 116.

[0051] The first user device 102 can be in operative communication with the server computer 104, the second user device 106, the plurality of user devices 108, and the blockchain network 112. The server computer can be in operative communication with the first user device 102, the second user device 106, the plurality of user devices 108, and the certification authority computer 110. The second user device 106 can be in operative communication with the first user device 102, the server computer 104, the plurality of user devices 108, and the blockchain network 112. The plurality of user devices 108 can be in operative communication with the first user device 102, the server computer 104, the second user device 106, and the blockchain network 112. The certificate authority computer 110 can be in operative communication with the server computer 104. The blockchain network 112 can be in operative communication with the first user device 102, the second user device 106, and the plurality of user devices 108.

[0052] For simplicity of illustration, a certain number of components are shown in FIG. 1 . It is understood, however, that embodiments of the invention may include more than one of each component. In addition, some embodiments of the invention may include fewer than or greater than all of the components shown in FIG. 1 .

[0053] Messages between the devices in FIG. 1 can be transmitted using a secure communications protocols such as, but not limited to, File Transfer Protocol (FTP); HyperText Transfer Protocol (HTTP); Secure Hypertext Transfer Protocol (HTTPS), SSL, ISO (e.g., ISO 8583) and / or the like. The communications network may include any one and / or the combination of the following: a direct interconnection; the Internet; a Local Area Network (LAN); a Metropolitan Area Network (MAN); an Operating Missions as Nodes on the Internet (OMNI); a secured custom connection; a Wide Area Network (WAN); a wireless network (e.g., employing protocols such as, but not limited to a Wireless Application Protocol (WAP), l-mode, and / or the like); and / or the like. The communications network can use any suitable communications protocol to generate one or more secure communication channels. A communications channel may, in some instances, comprise a secure communication channel, which may be established in any known manner, such as through the use of mutual authentication and a session key, and establishment of a Secure Socket Layer (SSL) session.

[0054] The first user device 102 can include a user device operated by a user (e.g., a phone, a tablet, a smartwatch, etc.). The first user device 102 can include the trusted execution environment 114, such as in a secure element as described in further detail herein. The user can utilize the first user device 102 to perform an interaction (e.g., a transaction, a data transfer, etc.) with the second user device 106. The first user device 102 can perform a transaction with the second user device 106 when the first user device 102 and the second user device 106 are offline (e.g., not connected to the server computer 104). The second user device 106 can include a resource provider device operated by a resource provider (e.g., a phone, a tablet, a smartwatch, etc.). In other cases, the second user device 106 can be operated by a second user that is not a resource provider.

[0055] The trusted execution environment 114 can be a software stack stored on a read-only memory within a secure element in the first user device 102. Thesoftware stack includes a set of resources to access the secure element, a trusted operating system (TOS) that provides developer access to the underlying secure element, and one or more trusted applications (TAs) that implement applicationspecific functionalities to be executed securely by the trusted execution environment 114.

[0056] Each user device (with or without the trusted execution environment) can include a rich execution environment, such as the rich execution environment 116, that includes one or more application-specific untrusted applications (UA) that reside in the untrusted region of the device and thus has a possibility of being malicious. A benign untrusted application provides user-facing functionalities to receive, verify, and store interactions on the device as well as to submit the interactions to the server computer 104 whenever the device goes online. In case of a TEE-enabled client, the untrusted application in the rich execution environment 116 can also interacts with a trusted application in the TEE to provide wallet operations to the user, such as creating new offline payments, adding / collecting received payments into the secure wallet, etc.

[0057] The server computer 104 can include a remote computer. The server computer 104 can provide an offline amount to the first user device 102 to be stored in a secure element of the first user device 102. For example, the first user device 102 can request an offline amount from the server computer 104. In other situations, the server computer 104 can push an offline amount to the first user device 102. The server computer 104 can maintain online balances in online accounts for each user device.

[0058] The first user device, the second user device, and the plurality of user devices 108 can communicate with the server computer 104 to obtain an offline balance that is stored in the secure element of each user device from the online balance maintained by the server computer 104.

[0059] In some embodiments, the first user device 102 can perform an interaction with one or more devices of the plurality of user devices 108, which can include resource provider devices and / or user devices. The plurality of user devices 108 can include any suitable number of user devices and / or resource provider devices.

[0060] In some embodiments, the first user device 102 and the second user device 106 can perform an offline interaction. The second user device 106 can receive an offline amount from the first user device 102. The second user device 106 can then perform a second offline transaction with a device of the plurality of user devices 108.

[0061] In other embodiments, after receiving the offline amount from the first user device 102, the second user device 106 can goes online and connect to the server computer 104. The second user device 106 can send a request to the server computer 104 to collect an amount equal to the received offline amount.

[0062] The certificate authority computer 110 can create and issue certificates to the server computer 104. The certificate authority computer 110 may include one or more server computers. In some embodiments, the certificate authority computer 110 may be capable of issuing certificates to resource provider device, authorizing entity computers, transport computers, server computer, network processing computers, user devices, etc. The certificate authority computer 110 may be capable of generating a certificate authority key pair. In some embodiments, the certificate authority computer 110 may be in operative communication with and / or operatively coupled to the server computer 104 and may generate certificates on behalf of the server computer 104. In some embodiments, a root certificate authority, not shown, can issue certificates to the certificate authority computer 110. The certificate authority computer 110 can then utilize the certificate obtained from the root certificate authority to issue certificates to the server computer 104.

[0063] The blockchain network 112 can include one or more computers that participate in maintaining a blockchain. The blockchain is a decentralized and distributed digital ledger that is used to record data across many computers so that the record cannot be altered retroactively without the alteration of all subsequent blocks and the collusion of the network. The blockchain network 112 can store interaction messages and other data relating to interactions such that user devices can obtain proofs relating to the publication of the stored data. The blockchain network 112 can provide proof such as a proof of publication or a proof of nonpublication to users’ user devices.

[0064] The proof of publication can be utilized to authenticate that certain information was published at a certain date or position in the blockchain. The proof of publication may include a proof of membership of the relevant data in the blockchain. Such a proof can be used to validate whether or not a particular data point (e.g., a particular interaction message) belongs to a predefined set of data (e.g., the data in the blockchain). The proof of publication can be created by the blockchain network 112 as known to one of skill in the art. For example, for a proof of publication, the blockchain network 112 can create an address space among leaves of a proof of publication Merkle Tree in which each unique leaf has a unique identifier. The inclusion of an address that points to the block that includes the relevant data in the blockchain into the Merkle Tree can server as proof of publication of the relevant data.

[0065] The proof of nonpublication can be utilized to authenticate that certain information was not published in the blockchain. The proof of nonpublication can include blocks (along with their inclusion proofs) that were published between the conditional payment’s expiry time, and thus is of finite length. Further efficiency is possible by providing this proof using (zk)SNARKs.

[0066] As an overview of the offline interaction system, consider two client devices A and B who hold online accounts with a server S. A client’s account maintains information about the amount of money (e.g., balance) that the client holds at the server S. The goal of our OPS protocol is to allow client device A (e.g., a sender device) to pay client device B (e.g., a receiver device) an amount of funds denoted by x from device A’s account with the server S without either client device communicating with the server S during the payment. It can be assumed that the device A (or any other client device that acts as a sender device) includes a secure device that can securely store data and execute code via a trusted execution environment. However, it is not required that the client device B (or any other client device that is a receiver device) includes a trusted execution environment. We first describe our TEE model and the main components of our protocol. Next, we briefly describe the main OPS protocols to set up the clients and perform offline payments.

[0067] During setup, both the first user device 102 and the second user device 106 can register with the server computer 104 during a one-time, online setup toestablish asymmetric cryptographic keys that are later used to issue and verify offline payments. The online setup can allow the first user device 102 to initialize its trusted execution environment 114 jointly by the server computer 104 and the device’s manufacturer. The trusted execution environment 114 setup consists of three phases: (1 ) remote attestation to allow either the manufacturer or the server computer 104 to remotely verify the validity of the TEE stack; (2) TA (trusted application) provisioning to allow either the manufacturer or the server computer 104 to securely deploy a TA inside the TEE; and (3) TA registration to allow the TA to establish a signing key pair, register it with the server computer 104, and obtain a certificate attesting to the validity of the key pair.

[0068] The first user device 102 can initially deposit funds into its secure element when the first user device 102 is online to be able to send offline payments later. In particular, the first user device 102 can request the server computer 104 to deposit an amount of x money from an online balance associated with the first user device 102 and stored at the server computer 104 into the offline balance stored in the trusted execution environment 114 in the first user device 102. The server computer 104 can respond with a signature showing that x was deducted from A’s online balance. The trusted execution environment 114 can verify the signature with the server’s public verification key and adds x to the offline balance stored in the trusted execution environment 114.

[0069] During an interaction, in some embodiments, an offline payment can be initiated by the second user device 106, which sends a payment request to the first user device 102. The payment request can include a second user device certificate. The first user device 102 can invokes TA. Pay to securely deduct the payment amount from the offline balance maintained by the trusted execution environment 114 and to create a signed payment message P containing the payment amount and the certificates of both user devices. The first user device 102 can send the payment message P to the second user device 106, which verifies the first user device signature and the first user device certificate, and checks that the payment contains the second user device certificate as the recipient. If all checks pass, the second user device 106 can accept the payment and stores the payment message P on the second user device 106.

[0070] Further details regarding offline interaction system initialization, deposit, and interaction, can be found in U.S. Non-Provisional Application 17 / 860,553, filed on July 8, 2022, which is incorporated herein by reference in its entirety.

[0071] By deducting the payment amount from the balance stored in the trusted execution environment 114 in the first user device, the trusted execution environment 114 prevents double spending of that amount.

[0072] FIG. 2 shows a block diagram of a user device 200 according to embodiments. The exemplary user device 200 may comprise a processor 204. The processor 204 may be coupled to a memory 202, a network interface 206, a computer readable medium 208, a trusted execution environment 210, and a rich execution environment 212. The computer readable medium 208 can comprise an interaction message module 208A, a witness module 208B, a witness verification module 208C, and a blockchain module 208D.

[0073] The memory 202 can be used to store data and code. For example, the memory 202 can store interaction messages, amounts, expiry times, conditions, witnesses, etc. The memory 202 may be coupled to the processor 204 internally or externally (e.g., cloud based data storage), and may comprise any combination of volatile and / or non-volatile memory, such as RAM, DRAM, ROM, flash, or any other suitable memory device.

[0074] If the user device 200 is a first user device (e.g., a sender device), the computer readable medium 208 may comprise code, executable by the processor 204, for performing a method comprising: generating, by a first user device, an interaction message during an interaction between the first user device and a second user device, wherein the interaction message includes an amount, an expiry time, and a condition; providing, by the first user device, the interaction message to the second user device, wherein the second user device obtains a witness that satisfies the condition; receiving, by the first user device, the witness or a proof; and verifying, by the first user device, that the witness satisfies the condition or the validity of the proof, wherein a transfer of the amount from a first user to a second user according to the interaction is facilitated using a blockchain.

[0075] If the user device 200 is a second user device (e.g., a receiver device), the computer readable medium 208 may comprise code, executable by the processor 204, for performing a method comprising: receiving, by second user device, an interaction message during an interaction between a first user device and the second user device from the first user device, wherein the interaction message includes an amount, an expiry time, and a condition, the interaction message generated by the first user device; obtaining, by the second user device, a witness that satisfies the condition; and providing, by the second user device, the witness to the first user device or to a blockchain network, wherein the first user device obtains the witness from the second user device or a proof of publication of the witness in a blockchain from the blockchain network, wherein the first user device verifies that the witness satisfies the condition or verifies the validity of the proof, wherein a transfer of the amount from a first user to a second user according to the interaction is facilitated using the blockchain.

[0076] The interaction message module 208A may comprise code or software, executable by the processor 204, for generating interaction messages. The interaction message module 208A, in conjunction with the processor 204, can generate an interaction message for an interaction between the user device 200 and another user device. The interaction message module 208A, in conjunction with the processor 204, can generate an interaction message comprising an amount, an expiry time, and a condition. The interaction message can be a transaction message that includes details regarding a transaction that performed between the first user device 102 and the second user device.

[0077] The witness module 208B may comprise code or software, executable by the processor 204, for generating a witness. The witness module 208B, in conjunction with the processor 204, can generate a witness for an interaction. The witness module 208B, in conjunction with the processor 204, can generate a witness for the interaction between the devices such that the witness satisfies the condition included in the interaction message.

[0078] The witness module 208B, in conjunction with the processor 204, can generate a witness that acts as a proof of performing an action. For example, the witness can be proof that a user device has performed an action according to theinteraction between two user devices. For example, the witness can include a value generated from data included in the interaction message (e.g., the amount, certificates, etc.), a value derived from a photo of resources procured, a value derived from a receipt or proof of completion, etc.

[0079] As another example, the condition can be a condition that the interaction occurs between the first user device and the second user device at a particular location (e.g., at a zip code of 94608). The witness can be a zip code or other data item that indicates a location. If the witness zip code is equal to 94608, then when the witness zip code is input into the condition function, the condition function will output a value of 1 to indicate that the condition is satisfied. The witness module 208B, in conjunction with the processor 204, can generate the witness by obtaining a current location zip code using, for example, global positioning system coordinates and determining a zip code. In some embodiments, the witness can be global position system coordinates for a condition that evaluates global positioning system coordinates. In some embodiments, the witness, which is a location, can be sufficiently satisfying to both parties involved in the interaction if the location is obtained from a trusted source such as a third party or a secure element and may be signed by the trusted source or the third party using a cryptographic private key.

[0080] As another example, the condition can be a function that compares a pre-interaction generated hash value to an input witness that is a hash value generated during the interaction. The pre-interaction generated hash value can be created from a combination of any of the following: an intended location, the interaction amount, a proof that a different interaction was performed, a proof that data was transferred, and / or other data that can prove something. In such a case, the witness can be generated by hashing the relevant information, such as the current location, the interaction amount, the proof that the different interaction was performed, the proof that the data was transferred, and / or the other data that can prove something. The condition compares the two hash values to determine whether or not they match.

[0081] As a simple mathematical example, the condition can indicate that an acceptable input value (e.g., an acceptable witness) should be a value that is asquare of a prime number. A witness that satisfies the condition is the value 4 since the value 4 is a square of the prime number 2 (e.g., 22= 4).

[0082] The condition can relate to a resource being provided from a second user of a second user device to a first user of a first user device according to an interaction.

[0083] The witness verification module 208C may comprise code or software, executable by the processor 204, for verifying a witness. The witness verification module 208C, in conjunction with the processor 204, can verify whether or not a received witness satisfies a condition. For example, witness verification module 208C, in conjunction with the processor 204, can receive a witness from a different user device that generated the witness. The witness verification module 208C, in conjunction with the processor 204, can input the witness into the condition, which is a function, to determine an output of the condition function. The witness verification module 208C, in conjunction with the processor 204, can determine that the witness satisfies the condition if the output of the condition function, with the witness as input, is equal to a value of 1 (or other predetermined value that indicates satisfaction, such as 0).

[0084] The blockchain module 208D may comprise code or software, executable by the processor 204, for interacting with a blockchain network. The blockchain module 208D, in conjunction with the processor 204, can generate proof request messages that request a proof of publication or a proof of nonpublication from a blockchain network. The proof request message can include an interaction identifier or other data that indicates what data the blockchain module 208D is attempting to locate in the blockchain. The blockchain module 208D, in conjunction with the processor 204, can provide the proof request message to the blockchain network. In response, the blockchain network can return the proof.

[0085] The network interface 206 may include an interface that can allow the user device 200 to communicate with external computers. The network interface 206 may enable the user device 200 to communicate data to and from another device (e.g., the server computer 104, the blockchain network 112, and other user devices, etc.). Some examples of the network interface 206 may include a modem,a physical network interface (such as an Ethernet card or other Network Interface Card (NIC)), a virtual network interface, a communications port, a Personal Computer Memory Card International Association (PCMCIA) slot and card, or the like. The wireless protocols enabled by the network interface 206 may include WiFi™. Data transferred via the network interface 206 may be in the form of signals which may be electrical, electromagnetic, optical, or any other signal capable of being received by the external communications interface (collectively referred to as “electronic signals” or “electronic messages”). These electronic messages that may comprise data or instructions may be provided between the network interface 206 and other devices via a communications path or channel. As noted above, any suitable communication path or channel may be used such as, for instance, a wire or cable, fiber optics, a telephone line, a cellular link, a radio frequency (RF) link, a WAN or LAN network, the Internet, or any other suitable medium.

[0086] The user device 200 can host a split trusted execution environment 210 that has resources that are split into two execution environments via hardware means: the rich execution environment 212 (REE) and the trusted execution environment 210 (TEE). The trusted execution environment 210 has its own dedicated memory, registers etc. along with its own trusted operating system. On top of the trusted operating system, third-party trusted applications can be built by making use of trusted execution environment internal APIs. Similarly, a client application can be built on top of the rich operating system. Applications running in the trusted execution environment 210 can access the resources of the rich operating system execution environment, but application running in the rich operating system execution environment cannot access the resources of the trusted execution environment 210. A client application residing in the rich operating system execution environment can communicate with a trusted application only via the trusted execution environment client APIs if the client application requests the services of the trusted application.

[0087] There can be different variations of trusted execution environments 210 depending on the platform upon which they run and / or the hardware used to achieve the isolation in the system. Since various embodiments can be performed on mobile devices, trusted execution environments that run on mobile devices are provided asan example. However, it is noted that embodiments are not limited thereto. For example, the trusted execution environment can use a TrustZone architecture (by ARM). The TrustZone architecture achieves the isolation in the system by augmenting computation cores with a mode that allows them to operate only for the trusted execution environment. A physical core is split into two virtual cores with TrustZone: one virtual core operates only for the trusted execution environment 210 and the other operates for the rest of the system. To switch from one environment to another, system calls can be used. Applications running within the trusted execution environment 210 may be further isolated from each other by the OS running in trusted execution environment 210.

[0088] The trusted execution environment 210 can be included in the user device 200. The trusted execution environment 210 can be located within any suitable secure hardware element included in the user device 200. In some embodiments, the trusted execution environment 210 can be a secure software module in the user device 200. In some embodiments, the trusted execution environment 210 can be located partially within a secure element and partially outside of the secure element, where each portion provides different capabilities. In other embodiments, the trusted execution environment 210 can be a secure element in the user device 200.

[0089] The trusted execution environment 210 can be a hardware-assisted execution environment within a system with its own resources (e.g., memory, registers, peripherals, and its own software stack, such as OS, applications etc.). The resources of the trusted execution environment 210 as well as the processes running within the trusted execution environment 210 cannot be accessed by the rest of the system directly.

[0090] The rich execution environment 212 can be located within any suitable hardware included in the user device 200. The rich execution environment 212 can include an embedded operating system that is included in the user device 200 and utilized by the user of the user device 200. The user can install applications, which can be considered as untrusted applications, within the rich execution environment 212 of the user device 200. The untrusted applications are untrusted in so far as they may potentially be malicious and can be obtained from an unknown third party.

[0091] Before registering a device which uses trusted execution environment functionalities in the offline interaction system protocol, an original equipment manufacturer (OEM) can attest that the trusted execution environment within a device is set up correctly. Then, embodiments can ensure that the trusted execution environment 210 is provisioned with the right applications. Finally, embodiments can register the instance of a trusted application running in a device with the server computer 104 if the attestation and the provisioning verifications are successful.

[0092] FIG. 3 shows a flow diagram of a conditional offline interaction utilizing a blockchain according to embodiments. The method illustrated in FIG. 3 will be described in the context of a first user device 102 being a sender device, which sends an interaction to a second user device 106 that is a receiver device.

[0093] At step 302, the first user device 102 can generate an interaction message during an interaction between the first user device 102 and a second user device 106. The interaction message can include details regarding the interaction. For example, the interaction message can include an amount, an expiry time, and a condition. The interaction message information can be previously agreed upon by the first user device 102, the second user device 106, the first user, and / or the second user. In some embodiments, the second user device 106 can generate one or more data elements that are included in the interaction message and can provide the one or more data elements to the first user device 102 for inclusion into the interaction message.

[0094] The amount can be an amount of a thing (e.g., funds, data, etc.) to transfer from the first user device 102 to the second user device 106 in exchange for one or more goods or services that are to be provided from the second user device 106 to the first user device 102. The amount can be a numerical value that indicates an amount of money that is to be transferred from the first user device 102 to the second user device 106.

[0095] The condition can indicate a state that must be achieved for the interaction to process. For example, the condition can be a condition that the interaction will proceed if the purchased resources are provided by the second user to the first user. The condition can be any suitable agreement and / or data security rule that can be established prior to the interaction and completed during theinteraction to allow the interaction to proceed. In some embodiments, the first user device 102 can generate the condition. In other embodiments, the second user device 106 can generate the condition and provide the condition to the first user device 102.

[0096] As an illustrative example, the condition can be a condition that outputs a value of 1 given a satisfactory input witness. The condition can be a function that compares a pre-generated hash value to an input witness that is a hash value that is generated during the interaction. The pre-generated hash value can be created from a combination of any of the following: an intended location, the interaction amount, a proof that a different interaction was performed, a proof that data was transferred, and / or other data that can prove something. In such a case, the witness can be generated by hashing the relevant information, such as the current location, the interaction amount, the proof that the different interaction was performed, the proof that the data was transferred, and / or the other data that can prove something.

[0097] The condition can be created digitally such that it is a function that accepts an input. The input to the condition function can be a witness. When the witness successfully fulfils the condition agreed upon by the first user and the second user, the condition function can output a value of 1 or other predetermined success value.

[0098] The expiry time can be a time at which the interaction is to expire if something in the method goes wrong, if a device does not properly respond to a message, or any other reason of failure. After the expiry time, the interaction can be reversed. The expiry time can be a point in time at which, if the interaction has not yet been completed, the interaction should be terminated and considered void.

[0099] The interaction message can also include additional data related to the interaction and / or the devices involved in the interaction. For example, the interaction message can include an interaction identifier, a first user device certificate, a first user device public key, a first user device trusted execution environment public key, a second user device certificate, a second user device public key, a timestamp of transmission, etc. A certificate can include a public key of the entity for which the certificate is issued to, or otherwise assigned with. As such, the second user device certificate can include a second user device public key.Also, the second user device secure element certificate can include a second user device secure element public key. The public key can correspond to a private key maintained securely by the device or secure element.

[0100] At step 304, after generating the interaction message, the first user device 102 can provide the interaction message to the second user device 106. As an example, the first user device 102 can transmit the interaction message over a communication channel that utilizes Bluetooth, Bluetooth low energy, ultra wideband, an electrical connection point, the Internet, or other short, medium, or long range communication channel.

[0101] At step 306, after receiving the interaction message, the second user device 106 can obtain a witness that satisfies the condition in the interaction message. As an illustrative example, if the condition is the function that compares the pre-generated hash value to an input hash value, then the second user device 106 can generate the witness by hashing the relevant data that was also used to create the pre-generated hash value. The hash value used for the witness can be created from the same combination of any of the following as the pre-generated hash value: an intended location, the interaction amount, a proof that a different interaction was performed, a proof that data was transferred, and / or other data that can prove something. For example, the second user device 106 can generate the witness by hashing together the intended location (e.g., country code, state code, etc.), the interaction amount, and the proof that the resources were transferred (e.g., a shipping label, a receipt, etc.).

[0102] At step 308, after obtaining the witness, the second user device 106 can generate a witness message comprising the witness.

[0103] At step 310, the second user device 106 can provide the witness message to the first user device 102. As an example, the second user device 106 can transmit the witness message over a communication channel that utilizes Bluetooth, Bluetooth low energy, ultra wideband, an electrical connection point, the Internet, or other short, medium, or long range communication channel to the first user device 102.

[0104] In some embodiments, the second user device 106 can provide the witness message to a blockchain network 112 rather than to the first user device 102. The blockchain network 112 can store the witness message into a blockchain. At some point later in time, the first user device 102 can communicate with the blockchain to determine whether or not the blockchain includes the witness message. The first user device 102 can obtain a proof relating to the witness message. The proof can be a proof of publication or a proof of nonpublication. If the witness message is included in the blockchain, then the first user device 102 can also obtain the witness message from the blockchain network 112.

[0105] At step 312, after obtaining the witness message and / or the proof, if the first user device 102 obtained the witness, then the first user device 102 can verify that the witness satisfies the condition. If the first user device 102 obtained the proof, then the first user device 102 can verify the validity of the proof.

[0106] The witness can satisfy the condition if, when input into the condition, the witness matches the pre-generated hash value. The hash value used for the witness can be created from the same combination of any of the following as the pregenerated hash value: an intended location, the interaction amount, a proof that a different interaction was performed, a proof that data was transferred, and / or other data that can prove something. The first user device 102 can input the witness into the condition to obtain an output value. If the output value is equal to a value of 1 , or other suitable output value, then the witness is valid.

[0107] At step 314, if the witness is valid, then a transfer of the amount from the first user to the second user, according to the interaction.

[0108] FIG. 4 shows a flow diagram of a conditional offline interaction where a sender has write access to a blockchain according to embodiments. The method illustrated in FIG. 4 will be described in the context of a first user device 102 being a sender device. The first user device 102 can include a trusted execution environment 114 and a rich execution environment 116. The first user device 102 can write data to a blockchain maintained by a blockchain network during an interaction between the first user device 102 and a second user device 106.

[0109] Prior to step 402 and the interaction, the first user device 102 and the second user device 106 can determine an amount and a condition for the interaction. The amount can be an amount of funds that are to be provided from the first user device 102 to the second user device 106. The condition can be a requisite that the second user device 106 can fulfil using a witness in order to complete the interaction.

[0110] Within the first user device 102, both the trusted execution environment 114 and the rich execution environment 116 can obtain the amount and the condition.

[0111] At step 402, the first user device 102 can generate an interaction message. The interaction message can be generated within the rich execution environment 116 of the first user device 102 during the interaction between the first user device 102 and the second user device 106. The interaction message includes the amount and the condition. The interaction message can also include an expiry time, a first user device identifier, a second user device identifier, and a timestamp.

[0112] For example, the interaction message can include an amount of $200 and a condition created using a pre-image, which can be a hash of a receipt generated based on the amount, the first user device identifier, the second user device identifier, a nonce known to the second user device 106, and an interaction identifier. The condition can receive a hash value as input (referred to as the image) and compare the image to the pre-image. The condition would be satisfied when the image and the pre-image match. As an example, the pre-image can be a collection of the data prior to the interaction, while the image can be a collection of the data during the interaction.

[0113] At step 404, after generating the interaction message, the first user device 102 can provide the interaction message to the second user device 106.

[0114] At step 406, after receiving the interaction message, the second user device 106 can obtain a witness for the condition. For example, the second user device 106 can generate the witness by hashing together the amount, the first user device identifier, the second user device identifier, the nonce known to the second user device 106, and the interaction identifier.

[0115] The witness can further include data that satisfies a particular condition. For example, the second user device 106 can further include, in the witness hash, a current geolocation of the second user device 106 (e.g., to prove that the interaction is occurring at a particular conditional location), an image of an item to be provided to the first user (e.g., to prove that the particular item exists such that the second user device 106 can obtain an image of the item during the interaction), a proof of inclusion of data in a blockchain (e.g., to prove that the second user device 106 included agreed upon data in a blockchain for the first user device 102), a legal document (e.g., to prove ownership, identity, authority, etc. such as a medical license), and / or any other data capable of proving something and / or satisfying a condition.

[0116] At step 408, after obtaining the witness, the second user device 106 can obtain a cryptographic key. The cryptographic key can be a symmetric cryptographic key. In some embodiments, the second user device 106 can generate the cryptographic key. In other embodiments, the second user device 106 can obtain the cryptographic key from memory, which can include one or more cryptographic keys.

[0117] At step 410, after obtaining the cryptographic key, the second user device 106 can perform a cryptographic key exchange process with the trusted execution environment 114 in the first user device 102. The cryptographic key exchange process can provide the cryptographic key from the second user device 106 to the trusted execution environment 114 in a secure manner and without allowing the rich execution environment 116 of the first user device 102 to obtain the cryptographic key. For example, the cryptographic key exchange process can be a Diffie-Hellman cryptographic key exchange or any other suitable secure key exchange process.

[0118] At step 412, after providing the cryptographic key to the trusted execution environment 114 of the first user device 102, the second user device 106 can encrypt the witness using the cryptographic key.

[0119] At step 414, the second user device 106 can provide the encrypted witness to the trusted execution environment 114 of the first user device 102.

[0120] At step 416, after receiving the encrypted witness, the trusted execution environment 114 can decrypt the witness using the cryptographic key. The trusted execution environment 114 can then validate the witness.

[0121] The trusted execution environment 114 can validate the witness by determining whether or not the witness satisfies the condition. For example, the first trusted execution environment 114 can input the witness into the condition function to determine an output value. For example, the trusted execution environment 114 can input the witness (which is the hash value generated by the second user device 106) into the condition (which compares the input hash value to the pre-image). The output value, which is output from the condition, can be evaluated by the trusted execution environment 114. If the output value is equal to 1 , then the trusted execution environment 114 can determine that the witness satisfies the condition. If the output value is not equal to 1 , then the trusted execution environment 114 can determine that the witness does not satisfy the condition.

[0122] At any point prior to step 418 and after obtaining the condition and the amount, the trusted execution environment 114 can generate an unconditional payment. The unconditional payment can be a data structure that, when posted to the blockchain, performs an unconditional payment to the second user device 106 from the first user device 102. The unconditional payment can include the condition and the amount. The unconditional payment can also include a first user device identifier, a second user device identifier, , a timestamp, and any other data relating to the interaction and / or the processing of the interaction. The trusted execution environment 114 can sign the unconditional payment using a trusted execution environment private key.

[0123] At step 418, after validating the witness, the trusted execution environment 114 can release the unconditional payment to the rich execution environment 116 of the first user device 102.

[0124] At step 420, after obtaining the unconditional payment, the rich execution environment 116 can submit the unconditional payment to the blockchain network 112 for inclusion into the blockchain that is maintained by the blockchain network 112.

[0125] The blockchain network 112 can include the unconditional payment into a block of the blockchain. Note that the payment is not processed through the blockchain by a cryptocurrency, rather the blockchain network 112 is utilized to provide proofs of publication of data from the user devices. The blockchain network 112 can allow the second user device 106 to prove that the first user device 102 has agreed to the unconditional payment.

[0126] At step 422, after providing the unconditional payment to the blockchain network 112, the rich execution environment 116 of the first user device can obtain a proof of publication of the unconditional payment from the blockchain network 112. The proof of publication can be data that indicates proof that the unconditional payment data structure was included in the blockchain.

[0127] At step 424, after obtaining the proof of publication, the rich execution environment 116 can provide the proof of publication to the trusted execution environment 114.

[0128] At step 426, the trusted execution environment 114 can verify the proof of publication. The trusted execution environment 114 can verify the proof of publication in any suitable manner. For example, the proof of publication can include a block identifier that indicates a particular block in the blockchain that includes the unconditional payment data structure. The trusted execution environment 114 can evaluate the block, as indicated by the block identifier, to determine whether or not the unconditional payment data structure is included in the block.

[0129] At step 428, if the proof of publication is valid, the trusted execution environment 114 can release the witness from the trusted execution environment 114 to the rich execution environment 116.

[0130] The interaction can be completed when the rich execution environment 116 obtains the witness. The witness can indicate to the rich execution environment 116 of the first user device 102 that the second user device 106 has completed the second user device’s 106 portion of the interaction. The interaction (e.g., the transaction) can be concluded since the first user device 102 has obtained the witness and the second user device 106 has obtained the information needed to obtain the amount.

[0131] In some embodiments, the second user device 106 can attempt to obtain the proof of publication from the blockchain network 112 at any point after step 412. The second user device 106 can utilize the proof of publication to confirm that the interaction was completed.

[0132] FIG. 5 shows a flow diagram of a conditional offline interaction where a receiver has write access to a blockchain according to embodiments. The method illustrated in FIG. 5 will be described in the context of a first user device 102 and a second user device 106 performing an interaction utilizing a blockchain network 112. The second user device 106 can have write access to a blockchain maintained by the blockchain network. The first user device 102 can include both a trusted execution environment 114 and a rich execution environment 116.

[0133] Prior to step 502, the first user device 102 and the second user device 106 and / or the first user and the second user can determine an amount, a condition, and an expiry time for the interaction. In some embodiments, the user devices can agree on a specific expiry time (e.g., 5 minutes, 30 minutes, 1 hour, 4 hours, 1 day, etc.). Within the first user device 102, both the trusted execution environment 114 and the rich execution environment 116 can obtain the amount, the condition, and the expiry time.

[0134] At step 502, the trusted execution environment 114 of the first user device 102 can generate an interaction message. The interaction message can include the amount, the condition, and the expiry time.

[0135] The trusted execution environment 114 maintains an offline balance for the first user device 102 in a secure manner. The offline balance can be an amount of offline funds that the first user device 102 can utilize while offline for interactions. The trusted execution environment 114 can deduct the amount from the offline balance.

[0136] For example, the trusted execution environment 114 can maintain an offline balance of $100. The interaction message can include an amount of $20. The trusted execution environment 114 can decrease the offline balance by the amount (e.g., $100 - $20 = $80).

[0137] Specifically, the trusted execution environment 114 of the first user device 102 can generate the interaction message asTA.ConditionalPay(x, receiverCert, , t). For example, the trusted execution environment 114 of the first user device 102 can generate the interaction message as follows.

[0138] The trusted execution environment 114 of the first user device 102 can verify that the current time is less than the expiry time. If the current time is greater than or equal to the expiry time, then the interaction has expired and the trusted execution environment 114 can terminate the process.

[0139] The trusted execution environment 114 of the first user device 102 can then create the interaction message and decrease an offline balance maintained by the trusted execution environment 114 (e.g., designated as T.bal). To do so, the trusted execution environment 114 can determine whether or not the trusted execution environment 114 stores a certificate (e.g., abort if T.cert = 0). If the trusted execution environment 114 does not have a certificate, then the trusted execution environment 114 can abort the process. The trusted execution environment 114 can also determine whether or not the amount included in the interaction request message exceeds the offline balance maintained by the trusted execution environment 114 (e.g., T.bal < x). If the trusted execution environment 114 determines that the offline balance is smaller than the amount, then the trusted execution environment 114 can abort the process. The trusted execution environment 114 can then modify the offline balance by the amount. The trusted execution environment 114 can also increase a counter or index that is maintained by the trusted execution environment 114 by 1 . The counter or index can track the number of interactions performed by the first user device 102. The trusted execution environment 114 can then create the interaction message including the amount, the trusted execution environment 114 certificate, the second user device certificate, and in some embodiments, the counter or index. In some embodiments, the trusted execution environment 114 can create a digital signature (e.g., designated as P.sig) on the interaction message using a trusted execution environment private key that corresponds to the trusted execution environment public key. At this point, if the interaction was not a conditional interaction, the trusted execution environment 114 could return the interaction message to the first user device 102 for use in theinteraction. However, for the conditional interaction, the secure element continues processing as follows.

[0140] The trusted execution environment 114 of the first user device 102 can then add a type into the interaction message. The type can indicate the type of interaction. For example, the type can be “Conditional.” The trusted execution environment 114 can add a type of “Conditional” into the interaction message. For example, the trusted execution environment 114 can perform P.type «— “Conditional”.

[0141] The trusted execution environment 114 can include the condition and the expiry time into the interaction message. For example, the trusted execution environment 114 can perform P .condition «— and P.expiry «— t.

[0142] The trusted execution environment 114 can then update the signature on the interaction message since this is a conditional message that has included the type, the condition, and the expiry time, thus changing the overall contents of the message. Therefore, a new signature is needed. The trusted execution environment 114 can generate a updated signature. The trusted execution environment 114 can generate the signature (e.g., P.sig) using the secure element private key (T.sk). For example, the trusted execution environment 114 can perform Update P.sig «— Sign([P.amount, P.senderCert, P.receiverCert, P.index, P.condition, P.expiry], T.sk).

[0143] The trusted execution environment 114 can then add the interaction message (e.g., designated as P) to an interaction log (e.g., designated as T.outPaymentLog) maintained by the trusted execution environment 114. The trusted execution environment 114 can append the interaction message along with an indicator of 0 (e.g., indicating that this is a first portion of the interaction message, more can be added later with an indicator of 1 ) to the interaction log. For example, the trusted execution environment 114 can perform Append (P, 0) to T.outPaymentLog.

[0144] At step 504, the rich execution environment 116 of the first user device 102 can provide the interaction message to the second user device 106.

[0145] As an illustrative example, the first user device 102 can provide the interaction message to the second user device 106, where the interaction messageincludes the amount of “$20,” the condition of the interaction taking place in the zip code of 94608, an expiry time of “January 1st, 2025 at 5:30 PM,” the second user device certificate, the first secure element certificate, an index value of 7 (e.g., this is the 7thinteraction performed by the first user device 102), the signature (e.g., that was created by the trusted execution environment 114).

[0146] At step 506, after receiving the interaction message, the second user device 106 can obtain a witness for the condition. The witness can satisfy the condition. For example, the witness can be a value that is input into the condition, which is a function. The output of the condition can equal a value of 1 (or other predetermined satisfactory value) if the witness satisfies the condition.

[0147] For example, the second user device 106 can determine a witness that is a zip code to satisfy the location based condition. The second user device 106 can determine a current location of the second user device 106 using a global positioning system or other location determination method. The second user device 106 can obtain a current location in the form of a zip code. The witness can be the zip code of 94608.

[0148] The second user device 106 can verify that the witness satisfies the condition (e.g., P.condition(w) = 1 ). The second user device 106 can input the witness into the condition that is included in the interaction message. The second user device 106 can evaluate the condition using the witness to generate an output value. If the output value equals a value of 1 , then the witness satisfies the condition. If the output value does not equal a value of 1 , then the witness does not satisfy the condition.

[0149] As an illustrative example, the second user device 106 can input the zip code of 94608 into the condition and determine an output value. The condition function can accept the zip code of 94608, then determine whether or not the input zip code matches the predetermined and agreed upon zip code of 94608. Since, the zip codes match in this case, the condition can output a value of 1 . However, if the second user device 106 was located in a different location (e.g., a zip code of 80516), then the condition would compare the input zip code of 80516 to the 94608 zip code, determine that they are different, and output a value other than 1.

[0150] In some embodiments, prior to obtaining the witness, the second user device 106 can verify the interaction message. To verify the interaction message, the second user device 106 can determine whether or not the original condition created during step 402 matches the condition included in the interaction message. If the original condition does not match the condition included in the interaction message, then the second user device 106 can terminate the process. The second user device 106 can further verify the interaction message by determining whether or not the original expiry time matches the expiry time included in the interaction message. If the original expiry time does not match the expiry time included in the interaction message, then the second user device 106 can terminate the process.

[0151] The second user device 106 can further verify the interaction message by determining that the type included in the interaction message matches a type of “Conditional,” since this is a conditional interaction. If the type included in the interaction message is not “Conditional,” then the second user device 106 can terminate the process.

[0152] The second user device 106 can further verify the interaction message by verifying that the receiver certificate included in the interaction message matches the second user device certificate. If the second user device 106 includes a secure element, then the second user device 106 can verify that the interaction message includes the receiver certificate that matches the second user device secure element certificate.

[0153] The second user device 106 can further verify the interaction message by verifying the sender certificate (e.g., the first user device certificate or the first user device secure element certificate) that is included in the interaction message. A certificate can be verified using a public key included in the certificate to verify a signature in the certificate that is created by a corresponding private key. As such, for example, the second user device 106 can verify the signature included in the first user device secure element certificate using the first user device secure element public key included in the first user device secure element certificate.

[0154] The second user device 106 can further verify the interaction message by verifying the signature included in the interaction message using the first userdevice secure element public key included in the first user device secure element certificate that is included in the interaction message.

[0155] At step 508, after obtaining the witness, the second user device 106 can provide the witness to the blockchain network 112 for inclusion into the blockchain. In some embodiments, the witness can be provided to the blockchain network 112 along with an identifier that can be used to identify the witness. The identifier can be an interaction identifier associated with the interaction, a second user device identifier associated with the second user device 106, a first user device identifier associated with the first user device 102, and / or any other identifier that can allow the first user device 102 to identify the witness that corresponds with the current interaction.

[0156] In some embodiments, at step 510, the second user device 106 can also provide the witness directly to the rich execution environment 116 of the first user device 102.

[0157] At step 512, the first user device 102 can check that the witness was included in the blockchain. The first user device 102 can identify the witness on the blockchain using an identifier that is stored in association with the witness. The identifier can be an interaction identifier, for example.

[0158] In some embodiments, after receiving the witness from the second user device 106, the rich execution environment 116 can communicate with the blockchain network 112 to determine whether or not the witness was included in the blockchain.

[0159] In other embodiments, if the witness was not received from the second user device 106 at step 510 and at the expiry time, the rich execution environment 116 can communicate with the blockchain network 112 to determine whether or not the witness was included in the blockchain.

[0160] At step 514, the rich execution environment 116 can obtain a proof from the blockchain network 112. The proof can be a proof of publication of the witness into the blockchain or a proof of nonpublication of the witness into the blockchain.

[0161] The proof of publication can include data that can be utilized to prove that the relevant data (e.g., the witness) is included in the blockchain. The proof of publication can include a block identifier that identifies a particular block in the blockchain that includes the witness.

[0162] The proof of nonpublication can include data that can be utilized to prove that the relevant data (e.g., the witness) is not included in the blockchain. The proof of nonpublication can include any suitable verifiable proof that indicates that the witness is not in the blockchain. As an example, the proof of nonpublication can include a sparse Merkle tree that proves non-inclusion of an element in the sparse Merkle tree. It is understood that any suitable proof of nonpublication of data in a blockchain can be utilized. As another example, in some embodiments, the first user device 102 can search the blockchain for inclusion of the data between or around timestamps of providing the interaction message to the second user device 106 (e.g., at step 504) and the expiry time. As another example, in some embodiments, the blockchain network 112 can perform a consensus process to determine whether or not the data was included in the blockchain, where a threshold amount (e.g., 75%) of blockchain network 112 devices need to respond for consensus regarding nonpublication of the data.

[0163] At step 516, after obtaining the proof, the rich execution environment 116 can provide the proof to the trusted execution environment 114.

[0164] At step 518, the trusted execution environment 114 can verify the proof depending on the type of proof utilized. For example, if the proof is a proof of publication and includes a block address of the witness, then the trusted execution environment 114 can evaluate the block in the blockchain indicated by the block address for the witness. As another example, if the proof is a proof of nonpublication and includes a sparse Merkle tree that is updated by the blockchain network for each interaction, then the trusted execution environment 114 can verify that one or more hash values in the sparse Merkle tree are valid, depending on the protocol used to create the proof of nonpublication by the blockchain network.

[0165] At step 520, if the proof is not valid or if the proof is a proof of nonpublication, then the trusted execution environment 114 can reverse the interaction. The trusted execution environment 114 can modify the offline balancemaintained by the trusted execution environment 114 based on the amount. For example, the offline balance maintained by the trusted execution environment 114 can be $80. The trusted execution environment 114 can add the amount to the offline balance (e.g., $80 + $20 = $100). As such, the trusted execution environment 114 can reverse the offline interaction based on the proof of nonpublication of the witness.

[0166] At step 522, the second user device 106 can provide data that indicates proof of the completed interaction to the server computer 104 to increase an online balance maintained by the server computer 104 for the second user device 106 based on the amount. The second user device 106 can perform step 522 at any point after step 508.

[0167] The second user device 106 can provide the proof of publication of the witness to the blockchain, the interaction message, and the witness to the server computer 104 as data that indicates proof of the completed interaction to the server computer 104.

[0168] At step 524, the server computer 104 can verify the data that indicates proof of the completed interaction. The server computer 104 can verify the proof of inclusion of the witness into the blockchain. The server computer 104 can verify that the witness satisfies the condition, as described herein.

[0169] At step 526, if the data that indicates proof of the completed interaction is valid, then the server computer 104 can increase an online balance of the second user device 106 by the amount.

[0170] FIG. 6 shows a flow diagram of a conditional offline interaction where a sender and a receiver both include trusted execution environments method according to embodiments. The method illustrated in FIG. 6 will be described in the context of a first user device 102 performing an interaction with a second user device 106. The first user device 102 can include a first trusted execution environment 114 and a first rich execution environment 116. The second user device 106 can include a second trusted execution environment 650 and a second rich execution environment 652.

[0171] Prior to step 602, in some embodiments, a first user of the first user device 102 and a second user of the second user device 106 can initiate an interaction for one or more resources (e.g., for a bicycle). The second user device 106 can obtain a condition and an amount for the interaction from input provided by the second user. For example, the second user can input an amount of $200 into the second user device 106. Also, the second user device 106 may present one or more available conditions to utilize for the interaction. The second user can select a condition that indicates that the second user device 106 is to take a photo of the resource (e.g., the bicycle) to obtain an image of the resource. The condition can also indicate that particular metadata is to be included in the image. For example, the condition can output a success value (e.g., a value of 1 ) if the metadata includes a timestamp that is between a time of selection of the condition (e.g., 11 :00 AM) and the expiry time (e.g., 11 :20 AM). As another example, the condition can output a success value if the metadata includes a geolocation of the image that matches the geolocation of the second user device 106 when the condition is selected (e.g., 37.814578, -122.291501 ).

[0172] As such, the witness can be an image of a bicycle with time and location based metadata, that when input into the condition can output a value of 1 if the witness satisfies the condition. For example, the condition, which is a function, can evaluate the input witness image to determine whether or not the bicycle is included in the image (e.g., using a pretrained machine learning model). The condition can output a value of 1 if the bicycle is included in the image.

[0173] The second user device 106 can provide the condition, the amount, and the expiry time to the first user device 102 (not shown in FIG. 6). Within the first user device 102, both the trusted execution environment 114 and the rich execution environment 116 can obtain the amount, the condition, and the expiry time. The second user device 106 can also provide a second user device certificate to the first user device 102.

[0174] At step 602, the first trusted execution environment 114 can generate the interaction message. The interaction message can include the condition, the amount, and the expiry time. The interaction message can also include the seconduser device certificate, a first user device certificate, and / or any other data related to the first user device 102, the second user device 106, and / or the interaction.

[0175] As an example, the first trusted execution environment 114 can first verify that a current time is prior to the expiry time. If the current time is after the expiry time, then the first trusted execution environment 114 can terminate the process.

[0176] The first trusted execution environment 114 can determine whether or not an offline balance maintained by the first trusted execution environment 114 is greater than or equal to the amount. If the offline balance is less than the amount, then the first trusted execution environment 114 can terminate the process.

[0177] After determining that the offline balance includes sufficient funds, the first trusted execution environment 114 can deduct the amount from the offline balance.

[0178] In some embodiments, the first trusted execution environment 114 can maintain an index that is incremented with every interaction performed by the first trusted execution environment 114. The first trusted execution environment 114 can increment the index.

[0179] The first trusted execution environment 114 can create the interaction message including the amount, the first user device certificate, the second user device certificate, the index, a type field that indicates that the interaction is conditional or nonconditional, the condition, and the expiry time. In some embodiments, the user device certificates can be trusted execution environment certificates for the user devices.

[0180] The first trusted execution environment 114 can then sign the interaction message using a first trusted execution environment private key that corresponds to a first trusted execution environment public key.

[0181] The first trusted execution environment 114 can add the interaction message to an outgoing interaction log maintained by the first trusted execution environment 114.

[0182] At step 604, the first trusted execution environment 114 can provide the interaction message to the second trusted execution environment 650 via the first user device 102 and the second user device 106.

[0183] At step 606, after receiving the interaction message, the second rich execution environment 652 can obtain a witness for the condition. For example, the condition can indicate that the second user device 106 is to take a photo of the resource (e.g., the bicycle) to obtain an image of the resource. The condition can also indicate that particular metadata is to be included in the image such as the timestamp and the geolocation.

[0184] The second user device 106 can capture an image of the resource (e.g., the bicycle) that is to be provided to the first user of the first user device 102. The second user device 106 can include a camera capable of capturing an image. The second user device 106 can utilize the image as the witness. The metadata can be generated by the camera and / or any software associated with the camera included in the second user device 106.

[0185] As an example, the image can be an image of the bicycle and can include metadata that indicates a time at which the image was captured (e.g., 11 :05 AM) and a geolocation at which the image was captured (e.g., a latitude-longitude of 37.814578, -122.291501 ).

[0186] At step 608, the second rich execution environment 652 can provide the witness to the blockchain network 112.

[0187] In some embodiments, at step 610, the second rich execution environment 652 provide the witness to the first user device 102. For example, by providing the witness directly to the first user device 102 the method may be completed faster since the first user device 102 does not need to wait until the expiry time to communicate with the blockchain network 112 to verify the witness. Rather, by obtaining the witness, the first user device 102 is notified that the witness is available.

[0188] At step 612, after obtaining the witness or at the expiry time, the first rich execution environment 116 of the first user device 102 can check for proof of thewitness on the blockchain maintained by the blockchain network 112, as described herein.

[0189] At step 614, the first rich execution environment 116 can obtain a proof from the blockchain network 112. The proof can be a proof of publication or a proof of nonpublication. The proof of publication can indicate that the witness was included into the blockchain. The proof of nonpublication can indicate that the second trusted execution environment 650 did not publish the witness to the blockchain network 112.

[0190] At step 616, after obtaining the proof, the first rich execution environment 116 can provide the proof to the first trusted execution environment 114.

[0191] At step 618, after obtaining the proof from the first rich execution environment 116, the first trusted execution environment 114 can verify the proof as described herein.

[0192] The first trusted execution environment 114 can determine if the proof is a proof of publication or a proof of nonpublication. For example, the proof can include a proof type indicator that indicates if the proof is a proof of publication or is a proof of nonpublication.

[0193] At step 620, if the proof is a proof of nonpublication and the proof is valid, the first trusted execution environment 114 can begin an interaction reversal process, since the second user device 106 did not provide the witness to complete the interaction. The first trusted execution environment 114 can increment the offline balance by the amount.

[0194] If the proof is not valid, then the first user device 102 can communicate with the blockchain network 112 to obtain a valid proof. If the first user device 102 does not obtain a valid proof, then the first user device 102 can reverse the interaction and / or communicate with the server computer 104 regarding the nonvalid proofs.

[0195] If the proof is a proof of publication and is valid, then the first trusted execution environment 114 can verify that the witness satisfies the condition. Thefirst trusted execution environment 114 can input the witness into the condition. For example, the first trusted execution environment 114 can input the witness, which is the image of the bicycle, into the condition. The condition can process the image to determine whether or not the image includes the bicycle using a pretrained machine learning model that is capable of identifying items in an image. The condition can also process the metadata in the image to verify that the timestamp of the image (e.g., 11 :05 AM) is between the time of selection of the condition (e.g., 11 :00 AM) and the expiry time (e.g., 11 :20 AM). The condition can also process the geolocation metadata to compare the geolocation of the second user device 106 when the condition is selected (e.g., 37.814578, -122.291501 ) to the geolocation metadata (e.g., 37.814578, -122.291501 ). The condition can determine whether or not a distance between the two geolocations is within a predetermined threshold difference. In this example, since the witness satisfies the condition, the condition can output a value of 1 .

[0196] After verifying that the witness satisfies the condition, the first trusted execution environment 114 can proceed to step 622 to perform a process that allows the second user device 106 to collect the amount from the interaction message.

[0197] At step 622, after verifying the witness, the first trusted execution environment 114 can sign the interaction message and the witness in such a way that allows the second user device 106 to collect the amount. To sign the interaction message and the witness, the first trusted execution environment 114 can perform the following processing.

[0198] The first trusted execution environment 114 can determine whether or not the interaction message is included in an outgoing interaction log stored in the first trusted execution environment 114. If the interaction message is already included in the outgoing interaction log, then the first trusted execution environment 114 can terminate the process. If the first trusted execution environment 114 determines that the interaction message is not included in the outgoing interaction log, then the first trusted execution environment 114 can continue with the process.

[0199] The first trusted execution environment 114 can verify that the received witness satisfies the condition. The first trusted execution environment 114 can input the witness into the condition to obtain an output value. If the output value is equalto a value of 1 (or other predetermined value), then the first trusted execution environment 114 can determine that the witness is valid and can continue with the process. If the witness is not valid, then the first trusted execution environment 114 can reverse if interaction if not yet reversed.

[0200] The first trusted execution environment 114 can verify that the witness was received prior to the expiry time. If the witness was not received prior to the expiry time, then the first trusted execution environment 114 can reverse the interaction if not yet reversed. If the witness was received prior to the expiry time, then the first trusted execution environment 114 can continue with the process.

[0201] The first trusted execution environment 114 can set a collectable indicator in the interaction message that indicates whether or not the interaction is collectable by the receiver device (e.g., the second user device 106). The collectable indicator can be a flag that can have two states, not collectable and collectable (e.g., 0 or 1 ).

[0202] The first trusted execution environment 114 can sign a data element that includes both the interaction message and the witness, using a first trusted execution environment secret key, to obtain a signature.

[0203] At step 624, after signing the interaction message and the witness, the first trusted execution environment 114 can provide the signature to the blockchain network 112 for inclusion into the blockchain.

[0204] In some embodiments, at step 626, the first trusted execution environment 114 can provide the signature to the second user device 106.

[0205] At step 628, after receiving the signature from the first user device 102 or at the expiry time, the second rich execution environment 652 can check for the signature on the blockchain.

[0206] At step 630, the second rich execution environment 652 can obtain the signature from the blockchain network 112. If the signature is not included in the blockchain, then the second user device 106 can perform processing, described below, to still be able to obtain the amount.

[0207] At step 632, after obtaining the signature from the blockchain network 112, the second rich execution environment 652 can provide the signature to the second trusted execution environment 650.

[0208] At step 634, if a signature was obtained, then the second trusted execution environment 650 can begin to collect the amount of the interaction message into an offline balance maintained by the second trusted execution environment 650. The second trusted execution environment 650 can evaluate the interaction message, the witness, and the signature.

[0209] The second trusted execution environment 650 can verify that the first user device certificate included in the interaction message is valid. The second trusted execution environment 650 can verify the signature using a public key corresponding to the private key used to create the signature. The public key can be a first trusted execution environment public key, which was included in the interaction message.

[0210] The second trusted execution environment 650 can verify that the second user device certificate included in the interaction message is valid and matches the second user device certificate stored by the second user device 106.

[0211] The second trusted execution environment 650 can determine whether or not the interaction message, or indicator thereof, is included in the incoming interaction log. If the interaction message is already included in the incoming interaction log, then the second trusted execution environment 650 can terminate the process. If the interaction message is not in the incoming interaction log, then the second trusted execution environment 650 can proceed with the process.

[0212] At step 636, the second trusted execution environment 650 can increase the offline balance maintained by the second trusted execution environment 650 based on the amount. The second trusted execution environment 650 can increase the offline balance by the amount.

[0213] After increasing the offline balance by the amount, the second trusted execution environment 650 can include the interaction message into the incoming interaction log.

[0214] In some embodiments, if the second user device 106 did not receive a signature on the witness from the first user device 102 or the blockchain network 112, the second user device 106 can still obtain the amount. For example, if the first user device 102 acts maliciously or in error and does not provide the signature in response to obtaining the witness, the second user device 106 can still obtain the amount.

[0215] The second user device 106 can provide the interaction message and the witness to the blockchain network 112 for inclusion into the blockchain. The blockchain network 112 can provide a proof of publication of the witness in response to publishing the witness to the second user device 106.

[0216] The second user device 106 can provide the interaction message and the proof of publication of the witness to the second trusted execution environment 650. The second trusted execution environment 650 can verify the proof of publication and the interaction message as described herein. Upon successful validation, the second trusted execution environment 650 can increment the offline balance by the amount to complete the interaction.

[0217] Since both the first user device 102 and the second user device 106 include trusted execution environments, the first user device 102 and the second user device 106 can remain offline from the server computer 104 (see FIG. 1). Both the first user device 102 and the second user device 106 can continue to perform interactions while remaining offline from the server computer 104 until running out of available offline funds or to provide offline funds to an online balance. For example, the first user device 102 can perform an additional interaction with a third user device and then a fourth user device before communicating with the server computer 104 to obtain an additional amount for the offline balance maintained in the trusted execution environment of the first suer device 102.

[0218] FIG. 7 shows a diagram of a blockchain according to embodiments of the present invention. FIG. 7 includes a blockchain 700 comprising a first block 710 and a second block 740. The blockchain 700 can include any suitable number of blocks (e.g., 10, 500, 2000, 500000, etc.).

[0219] Current blockchain technologies, such as Bitcoin and Ethereum, maintain an append-only ledger in a network. The ledger includes a list of blocks of transaction data, the blocks are cryptographically chained together. A block is created by a computationally intensive process called proof-of-work in which valid blocks need to demonstrate a sufficient “difficulty" (i.e. , sufficient computation power to create on average). If there are more than one available chains of blocks, then network participants (i.e., nodes) can download all blocks in all chains and follow the chain which has the highest total difficulty. This mechanism guarantees that, in the long run, the network will agree on a single and valid chain, see [Garay et al, The Bitcoin backbone protocol: Analysis and applications. In Advances in Cryptology - EUROCRYPT 2015, pages 281-310, 2015], [Bitcoin Website, bitcoin.org], and [Rafael Pass, Lior Seeman, and Abhi Shelat. Analysis of the blockchain protocol in asynchronous networks. In Jean-Sebastien Coron and Jesper Buus Nielsen, editors, Advances in Cryptology - EUROCRYPT 2017, pages 643-673, Cham, 2017. Springer International Publishing.], which are all incorporated herein by reference for all purposes.

[0220] The blockchain 700 can create a history of data deposits, messages, or entries in a series of blocks where each block contains a mathematical summary, called a hash, of the previous block. This creates a chain where any changes made to a block will change that block's hash, which must be recomputed and stored in the next block. This changes the hash of the next block, which must also be recomputed and so on until the end of the chain.

[0221] Although the hash can be simple to compute, rules may be imposed, which require the value of the hash to be below a certain threshold value (i.e., a difficulty value). In addition, the hash is based on a type of mathematical function that is not reversible. One cannot predict what input can be used to produce the desired output. A valid hash is found by repeatedly adjusting a changeable value in the block, and recalculating the hash until it meets the validity requirements. The freely changeable value can be a nonce. The unpredictable nature of the hash considerably increases the difficulty of finding a nonce that produces a valid hash of the block.

[0222] As an example, the first block 710 can include a block header 720 and block entries 730. The block header 720 of the first block 710 can comprise a previous hash 712, a timestamp 714, a Merkle root 716, and a nonce 718.

[0223] The previous hash 712 can be a hash of the previous block’s header. The previous hash 712 can be the result of a non-reversible mathematical computation using data from the previous block as the input. According to some embodiments, the computation used can include a SHA256 hash function. One of ordinary skill in the art would recognize that any suitable hash function could be used without departing from the spirit and scope of the present invention. The hash function can be designed so that any change to the data in the previous block results in an unpredictable change in the hash of that block. The previous hash 712 can be a link between blocks, chaining them together to form the blockchain 700.

[0224] When calculating the previous hash 712 for the previous block, a node can determine if the previous hash 712 can meet certain criteria defined by a difficulty value. In some embodiments, the difficulty value may include a number that the calculated hash must be less than. However, because the output of the hashing function is unpredictable, the output cannot be determined what input will result in an output that is less than the difficulty value before the hash is calculated. The nonce 718 can be used to vary the data content of the block, allowing for a large number of different outputs to be produced by the hash function in pursuit of an output that meets the difficulty value. This makes can make it computationally expensive to produce a valid block with a nonce 718 that produces a hash value meeting the criteria of the difficulty value.

[0225] The hash algorithms used for the previous hash 712 can include MD5, SHA-1 , SHA-224, SHA-256, SHA-384, SHA-512, SHA-512 / 224, SHA-512 / 256, SHA- 3 or any suitable hash function. There is also no requirement that a hash be computed only once. The results of a hash function may be reused as inputs into another or the same hash function again multiple times in order to produce a final result. One of ordinary skill in the art would recognize that any hash function could be used to compute the required hashing without departing from the spirit and scope of the present invention.

[0226] The Merkle root 716 can be a root of a Merkle tree, which can include a tree in which every leaf node is labelled with the hash of a data block, for example an entry. Each leaf of the Merkle tree can represent one of the entries. Each entry can be hashed together with a sibling node (i.e. , entry) in the Merkle tree. Successively hashing sibling nodes in the Merkle tree can result in the Merkle root 716.

[0227] The block entries 730 can include interaction data and / or smart contracts. The block entries 730 can include any suitable number of entries. Example entries can include the data described above, such as witnesses, signed witnesses, digital signatures, interaction messages, unconditional payment data, proof of inclusions, other data related to the processing of an offline interaction between two user devices, etc. In some embodiments, an entry may be a null value, for example, in the case of the Merkle tree being a sparse Merkle tree.

[0228] In some embodiments, the number of entries in the block entries 730 may be limited by the overall size of the block (e.g., the first block 710). For example, the blocks on the blockchain may be limited by a certain amount of data (e.g., 1 / 2 MB, 1 MB, 2 MB, 5 MB, 10 MB, etc.). In other embodiments, the number of entries in the block entries 730 may be a predetermined number of entries. For example, the nodes in the verification network can determine that 1 , 10, 150, 500, 1000, etc. entries can be included in the block entries 730.

[0229] The timestamp 714 can include a time that the block was created within a certain range of error. According to some embodiments of the present invention, the full nodes of the verification network can check the timestamp 714 against their own known time and can reject any block that seems to have an erroneous timestamp 714.

[0230] The nonce 718 can be a value adjusted by a full node while performing a proof-of-work process, as described herein. A nonce can be input into a hash function along with block data to determine the output hash value. A correct nonce (also referred to as a golden nonce) yields an output hash value that satisfies a predetermined criteria, such as being less than a difficulty value.

[0231] The second block 740 can be similar to the first block 710. For example, the second block 740 can include a block header 750 and block entries760. The block header 750 of the second block 740 can comprise a previous hash 752, a timestamp 754, a Merkle root 756, and a nonce 758. The block entries 760 can include image data as well as smart contracts, and can be similar to the block entries 730.

[0232] Embodiments of the disclosure have a number of technical advantages. For example, embodiments provide for a technical solution to the technical problem of allowing user devices, which maintain offline balances, to reverse interactions while offline from a management server computer that maintains online balances for the user devices. The user devices can conduct transactions and reverse them without the requirement that they be able to consistently access the management server. Embodiments of the invention can use a blockchain in a blockchain network to store proof that an entity behaved in a manner consistent with the transaction being conducted. Because the blockchain network is a distributed system and the blockchain managed by it is immutable, the entities to a transaction will be able to access the blockchain and obtain proof or nonproof of publication even if one or a few of the computers in the blockchain network are unavailable.

[0233] Although the steps in the flowcharts and process flows described above are illustrated or described in a specific order, it is understood that embodiments of the invention may include methods that have the steps in different orders. In addition, steps may be omitted or added and may still be within embodiments of the invention.

[0234] Any of the software components or functions described in this application may be implemented as software code to be executed by a processor using any suitable computer language such as, for example, Java, C, C++, C#, Objective-C, Swift, or scripting language such as Perl or Python using, for example, conventional or object-oriented techniques. The software code may be stored as a series of instructions or commands on a computer readable medium for storage and / or transmission, suitable media include random access memory (RAM), a read only memory (ROM), a magnetic medium such as a hard-drive or a floppy disk, or an optical medium such as a compact disk (CD) or DVD (digital versatile disk), flash memory, and the like. The computer readable medium may be any combination of such storage or transmission devices.

[0235] Such programs may also be encoded and transmitted using carrier signals adapted for transmission via wired, optical, and / or wireless networks conforming to a variety of protocols, including the Internet. As such, a computer readable medium according to an embodiment of the present invention may be created using a data signal encoded with such programs. Computer readable media encoded with the program code may be packaged with a compatible device or provided separately from other devices (e.g., via Internet download). Any such computer readable medium may reside on or within a single computer product (e.g. a hard drive, a CD, or an entire computer system), and may be present on or within different computer products within a system or network. A computer system may include a monitor, printer, or other suitable display for providing any of the results mentioned herein to a user.

[0236] The above description is illustrative and is not restrictive. Many variations of the invention will become apparent to those skilled in the art upon review of the disclosure. The scope of the invention should, therefore, be determined not with reference to the above description, but instead should be determined with reference to the pending claims along with their full scope or equivalents.

[0237] One or more features from any embodiment may be combined with one or more features of any other embodiment without departing from the scope of the invention.

[0238] As used herein, the use of "a," "an," or "the" is intended to mean "at least one," unless specifically indicated to the contrary.

Claims

WHAT IS CLAIMED IS:1 . A method comprising: generating, by a first user device, an interaction message during an interaction between the first user device and a second user device, wherein the interaction message includes an amount, an expiry time, and a condition; providing, by the first user device, the interaction message to the second user device, wherein the second user device obtains a witness that satisfies the condition; receiving, by the first user device, the witness or a proof; and verifying, by the first user device, that the witness satisfies the condition or the validity of the proof, wherein a transfer of the amount from a first user to a second user according to the interaction is facilitated using a blockchain.

2. The method of claim 1 , wherein after providing the interaction message to the second user device the method further comprises: receiving, by a first rich execution environment in the first user device, a cryptographic key exchange request message from the second user device; providing, by the first rich execution environment in the first user device, the cryptographic key exchange request message to a first trusted execution environment in the first user device; and performing, by the first trusted execution environment in the first user device, a cryptographic key exchange based on the cryptographic key exchange request message with the second user device, wherein the first trusted execution environment and the second user device obtain a cryptographic key.

3. The method of claim 2, wherein receiving the witness further comprises: receiving, by the first user device, an encrypted witness from the second user device, wherein the encrypted witness is the witness encrypted by the cryptographic key.

4. The method of claim 3 further comprising: providing, by the first rich execution environment in the first user device, the encrypted witness to the trusted execution environment;decrypting, by the trusted execution environment in the first user device, the encrypted witness using the cryptographic key to obtain the witness; providing, by the trusted execution environment in the first user device, an unconditional interaction to the first rich execution environment in the first user device; providing, by the first user device, the unconditional interaction to a blockchain network managing the blockchain; in response to providing the unconditional interaction to the blockchain network, receiving, by the first rich execution environment in the first user device, a proof of publication of the unconditional interaction from the blockchain network; providing, by the first rich execution environment in the first user device, the proof of publication to the trusted execution environment; verifying, by the trusted execution environment in the first user device, the proof of publication; and if the proof of publication is valid, providing, by the trusted execution environment in the first user device, the witness to the first rich execution environment in the first user device.

5. The method of claim 1 , wherein the first user device receives the witness from the second user device or from a blockchain network.

6. The method of claim 1 , wherein the interaction is a conditional interaction, wherein the amount indicates a value deducted from an offline balance maintained by a trusted execution environment in the first user device, wherein the method further comprises: at the expiry time or after receiving the witness, requesting, by the first user device, the proof from a blockchain network comprising the blockchain for the witness, wherein the proof is a proof of publication or a proof of nonpublication; receiving, by a first rich execution environment in the first user device, the proof from the blockchain network; providing, by the first rich execution environment in the first user device, the proof to the trusted execution environment in the first user device; verifying, by the trusted execution environment in the first user device, the proof; andif the proof is a proof of nonpublication, reversing, by the trusted execution environment in the first user device, the deduction of the amount from the offline balance.

7. The method of claim 6, wherein if the proof is a proof of publication, the method further comprises: signing, by the trusted execution environment in the first user device, a collection enabled message comprising the witness and the conditional interaction; providing, by the first user device, the signed collection enabled message to the second user device and / or the blockchain network, wherein the second user device obtains the signed collection enabled message from the first user device or from the blockchain network, obtains a proof of publication of the signed collection enabled message from the blockchain network, provides the proof of publication to a second trusted execution environment in the second user device, wherein the second trusted execution environment verifies the proof of publication and increases an offline balance maintained by the second trusted execution environment by the amount.

8. The method of claim 1 , wherein the interaction message further comprises a first user device certificate, a second user device certificate, and a type field that indicates whether the interaction is conditional or nonconditional.

9. The method of claim 1 further comprising: prior to generating the interaction message, receiving, by the first user device, the condition from the second user device.

10. The method of claim 1 , wherein the transfer of the amount from the first user to the second user according to the interaction is facilitated using the blockchain by having the blockchain store data related to the interaction that is verifiable by the first user device and the second user device.

11. A first user device comprising: a processor; anda computer-readable medium coupled to the processor, the computer- readable medium comprising code executable by the processor for implementing a method comprising: generating an interaction message during an interaction between the first user device and a second user device, wherein the interaction message includes an amount, an expiry time, and a condition; providing the interaction message to the second user device, wherein the second user device obtains a witness that satisfies the condition; receiving the witness or a proof; and verifying that the witness satisfies the condition or the validity of the proof, wherein a transfer of the amount from a first user to a second user according to the interaction is facilitated using a blockchain.

12. The first user device of claim 11 , wherein the interaction message further comprises a first user device certificate, a second user device certificate, and an index, wherein the method further comprises: reducing, by the first user device using a secure element, a stored offline value by the amount, wherein the stored offline value is stored in the secure element of the first user device; and signing, by the first user device using the secure element, the interaction message using a secure element private key.

13. The first user device of claim 11 , wherein the method further comprises: receiving, by a first rich execution environment in the first user device, a cryptographic key exchange request message from the second user device; providing, by the first rich execution environment, the cryptographic key exchange request message to a first trusted execution environment in the first user device; performing, by the first trusted execution environment in the first user device, a cryptographic key exchange based on the cryptographic key exchange request message with the second user device, wherein the first trusted execution environment and the second user device obtain a cryptographic key;receiving, by the first rich execution environment, an encrypted witness from the second user device, wherein the encrypted witness is the witness encrypted by the cryptographic key; providing, by the first rich execution environment, the encrypted witness to the trusted execution environment; decrypting, by the trusted execution environment in the first user device, the encrypted witness using the cryptographic key to obtain the witness; providing, by the trusted execution environment in the first user device to the first rich execution environment, an unconditional interaction to the first user device; providing, by the first rich execution environment, the unconditional interaction to a blockchain network; in response to providing the unconditional interaction to the blockchain network, receiving, by the first rich execution environment, a proof of publication of the unconditional interaction from the blockchain network; providing, by the first rich execution environment, the proof of publication to the trusted execution environment; verifying, by the trusted execution environment in the first user device, the proof of publication; and if the proof of publication is valid, providing, by the trusted execution environment in the first user device, the witness to the first rich execution environment in the first user device.

14. The first user device of claim 11 further comprising: a trusted execution environment; and a rich execution environment.

15. The first user device of claim 11 , wherein the method further comprises: prior to generating the interaction message, receiving the condition, the amount, and a second user device certificate from the second user device, wherein the interaction message further includes the second user device certificate.

16. The first user device of claim 11 , wherein the condition relates to a resource being provided from a second user of the second user device to the first user of the first user device according to the interaction.

17. A method comprising: receiving, by second user device, an interaction message during an interaction between a first user device and the second user device from the first user device, wherein the interaction message includes an amount, an expiry time, and a condition, the interaction message generated by the first user device; obtaining, by the second user device, a witness that satisfies the condition; and providing, by the second user device, the witness to the first user device or to a blockchain network, wherein the first user device obtains the witness from the second user device or a proof of publication of the witness in a blockchain from the blockchain network, wherein the first user device verifies that the witness satisfies the condition or verifies the validity of the proof, wherein a transfer of the amount from a first user to a second user according to the interaction is facilitated using the blockchain.

18. The method of claim 17 further comprising: prior to receiving the interaction message, receiving, by the second user device, a selection of the condition from one or more available conditions from a second user of the second user device; and providing, by the second user device, the condition to the first user device.

19. The method of claim 17 further comprising: providing, by the second user device, a cryptographic key exchange request message to the first user device, wherein the first user device provides the cryptographic key exchange request message from a first rich execution environment to a first trusted execution environment in the first user device; performing, by the second user device, a cryptographic key exchange based on the cryptographic key exchange request message with the first trustedexecution environment, wherein the first trusted execution environment and the second user device obtain a symmetric cryptographic key; encrypting, by the second user device, the witness with the symmetric cryptographic key.

20. The method of claim 19, wherein providing the witness to the first user device or to the blockchain network comprises: providing, by the second user device, the encrypted witness to the first user device or to the blockchain network.

Images