Patent ID: 12211017

Embodiments of the present disclosure and their advantages are best understood by referring to the detailed description that follows. It should be appreciated that like reference numerals are used to identify like elements illustrated in one or more of the figures, wherein showings therein are for purposes of illustrating embodiments of the present disclosure and not for purposes of limiting the same.

DETAILED DESCRIPTION

The present disclosure includes methods and systems for facilitating offline cryptocurrency transactions based on transmissions and verifications of tokens between secured enclaves of devices using a transaction communication protocol. Traditionally, cryptocurrency transactions are conducted based on recording transaction data in a decentralized and distributed ledger (e.g., a blockchain). Copies of the ledger are stored in a distributed manner across multiple computers (also referred to as computer nodes) in a cryptocurrency network. When a new transaction (e.g., a transaction for transferring an amount of cryptocurrency from a sender account to a recipient account) is broadcasted, multiple computer nodes within the cryptocurrency computer network may compete against each other to process the new transaction by performing a required verification routine (e.g., a proof-of-work or a proof-of-stake routine), which consumes a substantial amount of computer processing resources. The one computer node that has completed the required routine the fastest would record the transaction on the ledger and receive a compensation (e.g., a mined coin and/or a service fee, etc.). Such a transaction that is verified and recorded by the cryptocurrency computer network in real-time (e.g., as the transaction is being conducted) is referred to an online cryptocurrency transaction, as the device(s) involved in conducting the transaction (e.g., the device associated with the sender account, the device associated with the recipient account, etc.) is required to connect with the distributed ledger in order to complete the transaction.

The verification and recording process ensures that the sender account does in fact have ownership over the amount of cryptocurrency at the time the transaction is being broadcasted, and that the amount of cryptocurrency will not be double-spent by the sender account, thereby maintaining the integrity of the cryptocurrency system. However, the verification process (e.g., the proof-of-work process, the proof-of-stake process, etc.) can consume a large amount of computer resources within the cryptocurrency computer network. Furthermore, the requirement of broadcasting and recording the transaction data to the distributed ledger in real-time (as required by processing online cryptocurrency transactions) prevents transactions to be conducted when connectivity to the cryptocurrency computer network is limited (e.g., insufficient bandwidth to transfer the transaction data from the device associated with the sender account to any computer node within the cryptocurrency computer network).

As such, according to various embodiments of the disclosure, a framework (also referred to as “an offline cryptocurrency transaction framework”) is provided for facilitating cryptocurrency transactions even when the devices involved in the transactions lack connectivity to the distributed ledger at the time that the transactions are conducted. Cryptocurrency transactions that do not require devices involved in the transactions to have connectivity to the distribute ledger at the time the transactions are conducted are referred to as offline cryptocurrency transactions. In some embodiments, the framework as disclosed herein enables offline cryptocurrency transactions while maintaining the integrity of the cryptocurrency, through the storing, transmission, and verification of tokens among computer applications (also referred to as “transaction applications”) that are executed within secure enclaves of devices. When an offline cryptocurrency transaction is conducted under the framework as disclosed herein, the transaction data associated with the transaction is not verified or recorded by the cryptocurrency computer network at the time the transaction is conducted. Thus, offline cryptocurrency transactions can be conducted by devices that have temporary limited connectivity with the distributed ledger (and/or the cryptocurrency computer network). Subsequent to conducting the offline cryptocurrency transaction (e.g., a period of time after the offline cryptocurrency transaction is completed, such as an hour, a day, etc.) and when the connectivity of the device to the distributed ledger is restored, the transaction data may be uploaded to the computer node(s) within the cryptocurrency computer network for verification and recordation to the distributed ledger.

Under the framework, a first transaction application that is executed within a first secure enclave of a first device associated with a first cryptocurrency account (e.g., a first digital wallet) may register itself with the cryptocurrency computer network for initiating offline cryptocurrency transactions. A secure enclave is a dedicated hardware subsystem within a device that includes at least a processor and a memory and that is separated from the main processor and memory associated with the device. The secure enclave is isolated from the main processor and designed to store data that would remain secure even when the main processor of the device becomes compromised. Typically, a secure enclave may include a read-only memory that stores all of the computer software programs (including the transaction application as disclosed herein) to be executed by the secure enclave. Thus, the transaction application may be pre-installed at the factory that manufactures the secure enclave (e.g., similar to a firmware of a device) such that the transaction application is ready for use when the device is purchased by the user. Reading and/or writing of data in the memory (e.g., random access memory) of the secure enclave is controlled by the computer software applications executed within the secure enclave such that no other processors, including the main processor of the device, can access the data stored in the memory of the secure enclave. In some embodiments, the secure enclave may include one or more sensors, such as a frequency sensor, a voltage sensor, a light sensor, etc., for detecting physical tampering of the secure enclave. In some embodiments, upon detecting a possible physical tampering of the secure enclave, a program executed within the secure enclave would automatically be triggered to wipe out the data stored within the secure enclave to further improve the security of the secure enclave.

In some embodiments, the first transaction application may generate a first pair of asymmetrical keys (e.g., a private/public key pair) for application-based signing, which are also known as application-based signing keys. The first transaction application may also generate remote attestation information based on attributes associated with the first secure enclave. In some embodiments, the remote attestation information may include a signed copy of the programming code associated with the first transaction application that is signed using the application-based private key of the first transaction application (which may indicate a make and version number of the first transaction application), attributes associated with the first secure enclave (e.g., a hardware and/or software security capability and configuration of the first secure enclave), a signed copy of the identifier of the first cryptocurrency account that is signed using the application-based private key of the first transaction application, and the application-based public key generated by the first transaction application. The first transaction application may then transmit the remote attestation information to the cryptocurrency computer network to be recorded on the distributed ledger. The remote attestation information serves to show the integrity of the first transaction application and that the first transaction application is configured to maintain the integrity of the cryptocurrency (e.g., the recordation of the signed copy of the code ensures that anyone that has access to the distributed ledger can verify that the first transaction application would behave according to the transaction communication protocol of the framework and would not behave in a malicious manner). The first transaction application may also store the signed remote attestation information in the first secure enclave of the first device.

Once the first transaction application has registered itself with the cryptocurrency computer network for performing offline cryptocurrency transactions, the first transaction application may reserve any portion (or the entirety) of the cryptocurrency possessed by a first user of the first cryptocurrency account for use in one or more offline cryptocurrency transactions for a duration of time. In some embodiments, the first transaction application may enable the first user of the first device, via a user interface presented on the first device, to request for a reservation of any portion of cryptocurrency possessed by the first user through the first cryptocurrency account. For example, when the first user anticipates a need for performing offline cryptocurrency transactions (e.g., planning to go to an area with limited cellular reception such as a remote farmer's market to make purchases, etc.), the first user may instruct the first transaction application to reserve an amount of cryptocurrency for offline cryptocurrency transactions. The first user may specify a particular amount of cryptocurrency (e.g., a particular denomination, such as a coin, five coins, a Satoshi, seven Satoshi, an ether, 10 weis, etc.) to be reserved and a duration of the reservation (e.g., an expiration time, such as 3 hours from a current time, a day from the current time, a month from the current time, etc.).

In response to receiving the request, the first transaction application may generate another pair of asymmetrical keys (e.g., a public/private key pair) for token-based signing, which is known as the token-based keys. The first transaction application may also generate a token to represent the particular denomination for use in the one or more offline cryptocurrency transactions. The token may include a hashed message authentication code (HMAC) address for the token (which can be used by other transaction applications to locate the remote attestation information and other data associated with the first secure enclave and the reserved cryptocurrency denomination stored on the distributed ledger), the particular denomination reserved by the first transaction application and represented by the token, the expiration time of the token, and the remote attestation information of the first transaction application. In some embodiments, the first transaction application may also sign the token using the token-based private key of the first transaction application.

The first transaction application may transmit a request to reserve the particular denomination of cryptocurrency and the token to the cryptocurrency computer network. Upon receiving the request, the cryptocurrency computer network may perform a transaction (e.g., executing a contract) to reserve the particular denomination (to put on hold) owned by the first user for a time period until the expiration time of the token. The reservation of the particular denomination, which is recorded on the distributed ledger as a transaction (e.g., a contract), prevents the particular denomination from being used (e.g., spent) by the first user in any online cryptocurrency transactions in the absence of the corresponding signed token that is signed using the token-based private key of the first transaction application.

Based on the reservation of the particular denomination for the first cryptocurrency account, the cryptocurrency computer network may generate a record that links the token and the remote attestation information to the first cryptocurrency account. The cryptocurrency computer network may store the record on the distributed ledger, such that any devices associated with a cryptocurrency account may download the record to be used for verification purposes in an offline cryptocurrency transaction with the first transaction application. After registering with the cryptocurrency computer network and reserving the particular cryptocurrency denomination, the first transaction application may initiate offline cryptocurrency transactions through the first cryptocurrency account with another transaction application via a peer-to-peer connection, without the need of connecting to the distributed ledger.

For example, the first user may be at a remote farmer's market where cellular connection is limited. When the first user wants to purchase an item from a merchant using cryptocurrency, the first user cannot conduct an online cryptocurrency transaction as neither the first device of the first user nor a second device of the merchant (e.g., a second user) has connectivity with the cryptocurrency computer network. Thus, the first transaction application may be instructed by the first user to perform an offline cryptocurrency transaction with a second transaction application executed within a second secure enclave of the second device (e.g., transferring the particular cryptocurrency denomination from the first cryptocurrency account to a second cryptocurrency account associated with the second device). The first transaction application may establish a peer-to-peer connection with the second transaction application (e.g., a short-range wireless connection such as a Bluetooth® connection, a near-field connection, a WiFi connection, etc.). The first transaction application may transmit a request for performing an offline cryptocurrency transaction with the second transaction application. In some embodiments, the second transaction application may determine whether the connectivity with the distributed ledger is available (i.e., no connectivity or insufficient connectivity to enable the transaction to be conducted or conducted within a threshold measurement), and may decline the request if it is determined that the connectivity with the distributed ledger is available (e.g., online cryptocurrency transactions can be performed by the second device).

If the second transaction application determines to accepts the request, the second transaction application may perform a series of verification processes to verify the security of the first secure enclave and the first transaction application, and the authenticity of the token being transferred to the second cryptocurrency account. In some embodiments, after the second transaction application accepts the request, the first transaction application may sign the token along with a timestamp representing a current time using the token-based private key associated with the first transaction application. The first transaction application may transmit the signed token, the timestamp, and the signed remote attestation information to the second transaction application via the peer-to-peer connection. The second transaction application may have downloaded the remote attestation information associated with the first transaction application and the record that links the token and the remote attestation information of the first transaction application to the first cryptocurrency account prior to receiving the request when the connectivity with the distributed ledger was available to the second transaction application. Thus, the second transaction application may decrypt the signed token using the token-based public key associated with the first transaction application and verify that the token is representative of the particular cryptocurrency denomination (e.g., the particular amount of coins, the particular amount of Satoshis, an either, 10 weis, etc.) of the first cryptocurrency account by comparing the decrypted token against the token in the record.

By decrypting the signed token using the token-based public key associated with the first cryptocurrency account and using the data in the record, the second transaction application may further verify that the first transaction application is associated with the first cryptocurrency account. In some embodiments, the second transaction application may access the remote attestation information associated with the first transaction application included in the record, and determine whether the first secure enclave satisfies a set of security requirements. The set of security requirements may include a make and a version number of secure enclaves (that the secure enclave is made by an approved manufacturer with a version higher than a threshold version number, etc.), a set of hardware/software security requirements (e.g., the presence of certain sensors, such as light sensor, frequency sensor, etc., the presence of certain software security measures, etc.). The set of requirements may be determined automatically by the second transaction application or by a second user of the second device. In some embodiments, the second transaction application may refuse to perform the offline cryptocurrency transaction with the first transaction application if it is determined that the first secure enclave and/or the first transaction application fails to satisfy the set of security requirements.

In some embodiments, the second transaction application may also verify that the timestamp received from the first transaction application indicates a time that is after the time when the token was generated and before the expiration time of the token. In some embodiments, the second transaction application may also determine whether a difference between the current time and the expiration time of the token is larger than a threshold (e.g., 3 hours, a day, etc.) such that the second transaction application has sufficient time to record the transaction on the distributed ledger after completing the offline cryptocurrency transaction with the first transaction application. For example, the second transaction application may refuse to conduct the offline cryptocurrency transaction (e.g., abort the transaction process) when the difference between the current time and the expiration time of the token is not larger than the threshold. If the second transaction application refuses to conduct the offline cryptocurrency transaction, the second transaction application may transmit an abort signal to the first transaction application via the peer-to-peer connection, and remove any data related to the offline cryptocurrency transaction from the second secure enclave.

To continue processing the offline cryptocurrency transaction, the second transaction application may transmit a confirmation signal to the first transaction application via the peer-to-peer connection. The confirmation signal indicates that the second transaction application has accepted the signed token from the first transaction application. The second transaction application may then store the signed token in the second secure enclave of the second device. Upon receiving the confirmation signal, the first transaction application may delete the signed token from the first secure enclave to ensure that the token will not be double-spent or used multiple times (e.g., the first transaction application may no longer use the token in any other offline cryptocurrency transaction). In some embodiments, the first transaction application may transmit a token deletion signal to the second transaction application via the peer-to-peer connection, indicating that the token has been removed from the first secure enclave to confirm that the second transaction application has the only copy of the signed token.

After the offline cryptocurrency transaction between the first and second transaction applications is complete, the second transaction application may monitor the connectivity between the second device and the distributed ledger. For example, the second transaction application may attempt to communicate with a computer node of the cryptocurrency computer network (e.g., periodically such as every five minutes, every hour, etc.). In some embodiments, the second transaction application may be configured to attempt to communicate with a computer node of the cryptocurrency computer network in a progressively shorter interval, such that the second transaction application may attempt to communicate with the cryptocurrency computer network more frequently as it is closer to the expiration time of the token. For example, the second transaction application may begin with attempting to communicate with the cryptocurrency computer network every hour. As it gets closer to the expiration time of the token, the second transaction application may increase the frequency of communication attempts to every five minutes, every minute, every second, etc.

When the second transaction application determines that the connectivity with the distributed ledger (e.g., with a node within the cryptocurrency computer network) is available, the second transaction application may communicate the signed token and other transaction data associated with the offline cryptocurrency transaction between the first cryptocurrency account and the second cryptocurrency account to the node within the cryptocurrency computer network. The communication or transmission of the signed token and the transaction data to the cryptocurrency computer network may trigger the verification and recordation of the offline cryptocurrency transaction on the distributed ledger, in a similar manner as an online cryptocurrency transaction is verified and recorded. Thus, using the framework as disclosed herein, cryptocurrency transactions can be conducted between devices associated with cryptocurrency accounts even when the devices temporarily lose connectivity with the distributed ledger.

In some embodiments, the framework also enables the second transaction application, after completing the offline cryptocurrency transaction with the first transaction application but before committing the offline cryptocurrency transaction to the distributed ledger, to use the signed token to perform another offline cryptocurrency transaction with another transaction application. For example, the second transaction application may also register itself with the cryptocurrency computer network for initiating offline cryptocurrency transactions. The second transaction application may generate remote attestation information based on attributes associated with the second secure enclave. In some embodiments, the remote attestation information may include a signed copy of the programming code associated with the second transaction application that is signed using an application-based private key of the second transaction application (which may indicate a make and version number of the second transaction application), attributes associated with the second secure enclave (e.g., a hardware and/or software security capability and configuration of the second secure enclave), a signed copy of the identifier of the second cryptocurrency account that is signed using the application-based private key of the second transaction application, and the application-based public key generated by the second transaction application. The second transaction application may then transmit the remote attestation information to the cryptocurrency computer network to be recorded on the distributed ledger.

The second transaction application may initiate an offline cryptocurrency transaction with a third transaction application of a third device that is within a threshold distance from the second device. The third transaction application may be executed in a third secure enclave of the third device. In some embodiments, the second transaction application may establish a peer-to-peer connection with the third transaction application, and may transmit a request to conduct an offline cryptocurrency transaction with the third transaction application. The second transaction application may sign the signed token using a token-based private key associated with the second transaction application. By signing the signed token that has already been signed using the token-based private key associated with the first transaction application, the second transaction application establishes a record of a series of trusted transactions (e.g., a chain of offline cryptocurrency transactions) in association with the token. The second transaction application may then transmit the double-signed token, a timestamp representing a current time, the remote attestation information of the second transaction application, and the remote attestation information of the first transaction application, to the third transaction application.

The third transaction application may have downloaded, from the distributed ledger, records (e.g., the remote attestation information and the record) associated with the registration of the first transaction application and the registration of the second transaction application. By decrypting (e.g., using the token-based public key of the second transaction application) and analyzing the data received from the second transaction application, the third transaction application may verify that the token was originated from the first transaction application and has been transferred to the second transaction application during a previous offline cryptocurrency transaction. The third transaction application may also verify the authenticity of the token, the security attributes of the first and second secure enclaves, and the security of the first and second transaction applications using similar techniques as disclosed herein.

The third transaction application may also verify that the difference between the current time and the expiration time of the token is larger than a threshold before continuing to complete the offline cryptocurrency transaction. If the third transaction application determines to complete the offline cryptocurrency transaction, the third transaction application may store the signed token in the third secure enclave of the third device, and may transmit a confirmation signal to the second transaction application via the peer-to-peer connection. Upon receiving the confirmation signal, the second transaction application may delete the signed token from the second secure enclave. After completing the offline cryptocurrency transaction and before the expiration time of the token, the third transaction application may commit the offline cryptocurrency transaction to the distributed ledger by transmitting the signed token and transaction data associated with the chain of offline cryptocurrency transactions (which includes the offline cryptocurrency transaction between the first and second transaction applications and the offline cryptocurrency transaction between the second and third transaction applications) to the cryptocurrency computer network.

In the examples illustrated above, each of the offline cryptocurrency transactions were conducted using the token representing the entire cryptocurrency denomination that was reserved for the transaction application (e.g., the first transaction application). In some embodiments, the framework also enables offline cryptocurrency transactions to be conducted using a portion of the entire cryptocurrency denomination. For example, after generating the initial token (also referred to as the “parent token”), the first transaction application may split the particular cryptocurrency denomination into multiple portions by generating multiple child tokens based on the parent token. Each child token may include a reference to the parent token (e.g., the HMAC address of the parent token), an HMAC address associated with the child token, a timestamp indicating the time that the child token is generated, and a sub-denomination representing a particular portion of the particular cryptocurrency denomination. The first transaction application may then record the child tokens on the distributed ledger in association with the parent token in a similar manner that the parent token is recorded. The first transaction application may then conduct offline cryptocurrency transactions with other transaction applications using the child tokens in a similar manner as conducting offline cryptocurrency transactions using the parent token.

FIG.1illustrates a networked system100, within which the offline cryptocurrency transaction framework may be implemented according to one embodiment of the disclosure. Note that the present techniques may be applied in many different computing and technological environments, however, and are not limited to those shown in the figures. The networked system100includes a service provider server130, a cryptocurrency computer network120, and user devices110,180and190that may be communicatively coupled with each other via a network160. The network160, in one embodiment, may be implemented as a single network or a combination of multiple networks. For example, in various embodiments, the network160may include the Internet and/or one or more intranets, landline networks, wireless networks, and/or other appropriate types of communication networks. In another example, the network160may comprise a wireless telecommunications network (e.g., cellular phone network) adapted to communicate with other communication networks, such as the Internet.

The cryptocurrency computer network120may include multiple computer nodes for managing transactions associated with a cryptocurrency using a decentralized and distributed ledger (e.g., a blockchain). The decentralized and distributed ledger may store transaction data related to cryptocurrency transactions of the cryptocurrency. Each computer node within the cryptocurrency computer network manages a copy of the distributed ledger. When the computer nodes receive transaction data associated with a cryptocurrency transaction from a device (e.g., the user devices110,180, and190, etc.), the computer nodes compete against each other in solving a mathematical problem (which is part of a verification process such as a proof-of-work process or a proof-of-stake process). Once a computer node solves the mathematical problem, the computer node may record the transaction (e.g., in a block) on its copy of the distributed ledger, and broadcast the block and the solution to the mathematical problem to the other computer nodes, such that the other computer nodes can update their copies of the distributed ledger. The computer node that won (e.g., the fastest to solve the mathematical problem) would be granted the right to receive a compensation (e.g., in the form of a mined coin and/or a service fee charged to a party to the transaction).

The user device110, in one embodiment, may be utilized by a user140to interact with the cryptocurrency computer network120, the service provider server130, and other user devices (e.g., the user devices180and190, etc.) over the network160. For example, the user140may use the user device110to conduct cryptocurrency transactions through a cryptocurrency account with other cryptocurrency accounts by communicating transaction data to the cryptocurrency computer network120. The user140may also log in to a user account to access account services or conduct electronic transactions (e.g., account transfers or payments, purchasing goods and/or services, etc.) with the service provider server130. The user device110, in various embodiments, may be implemented using any appropriate combination of hardware and/or software configured for wired and/or wireless communication over the network160. In various implementations, the user device110may include at least one of a wireless cellular phone, wearable computing device, PC, laptop, etc.

The user device110, in one embodiment, includes a user interface (UI) application112(e.g., a web browser, a mobile payment application, etc.), which may be utilized by the user140to interact with the service provider server130over the network160. In one implementation, the user interface application112includes a software program (e.g., a mobile application) that provides a graphical user interface (GUI) for the user140to interface and communicate with the service provider server130and/or the cryptocurrency computer network120via the network160. In another implementation, the user interface application112includes a browser module that provides a network interface to browse information available over the network160. For example, the user interface application112may be implemented, in part, as a web browser to view information available over the network160.

The user device110, in one embodiment, may include at least one identifier114, which may be implemented, for example, as operating system registry entries, cookies associated with the user interface application112and/or the wallet application116, identifiers associated with hardware of the user device110(e.g., a media control access (MAC) address), or various other appropriate identifiers. In various implementations, the identifier114may be passed with a user login request to the service provider server130via the network160, and the identifier114may be used by the service provider server130to associate the user140with a particular user account, a particular digital wallet (e.g., a cryptocurrency account), and/or a particular profile.

The user device110may include a wallet application116configured to facilitate cryptocurrency transactions for the user140. In some embodiments, the wallet application116may be associated with a cryptocurrency account (e.g., a digital wallet) of the user140such that funds (e.g., in a cryptocurrency, etc.) can be transferred from the cryptocurrency account of the user140to another cryptocurrency account of another user (e.g., the wallet application186of the user device180, the wallet application196of the user device190, or other wallet application associated with another entity, etc.) using the wallet application116. In some embodiments, the wallet application116may be configured to perform cryptocurrency transactions. The user140, through the user interface provided by the wallet application116on the user device110, may initiate a cryptocurrency transaction (e.g., transferring a particular amount in a cryptocurrency from the digital wallet of the user140to another digital wallet). In some embodiments, the wallet application116may initiate online cryptocurrency transactions. For example, the user140may specify an identity of a recipient cryptocurrency account, and an amount in the cryptocurrency via the user interface of the wallet application116. The wallet application116may broadcast transaction data associated with the cryptocurrency transaction over the cryptocurrency computer network120.

As discussed herein, the requirement of broadcasting and recording the transaction data to the distributed ledger in real-time (as required by processing online cryptocurrency transactions) prevents cryptocurrency transactions from being conducted when connectivity to the cryptocurrency computer network is limited (e.g., when the user device110has insufficient network bandwidth to transfer the transaction data to any computer node within the cryptocurrency computer network120). Furthermore, the verification process (e.g., the proof-of-work process, the proof-of-stake process, etc.) can consume a large amount of computer resources within the cryptocurrency computer network120.

As such, according to various embodiments of the disclosure, devices (e.g., the user devices110,180, and190, etc.) may be enabled to conduct offline cryptocurrency transactions even when the devices involved in the transactions lack connectivity to the cryptocurrency computer network120at the time that the transactions are conducted. In some embodiments, the offline cryptocurrency transactions are conducted via transaction applications that are executed within secure enclaves of devices involved in the transactions. As such, the user device110may include a secure enclave118for facilitating offline cryptocurrency transactions. The secure enclave118is a dedicated hardware subsystem within the user device110that includes at least a processor and a memory and that is separated from the main processor and memory associated with the user device110. The secure enclave118is isolated from the main processor and designed to store data that would remain secure even when the main processor of the user device110becomes compromised. In some embodiments, the secure enclave118may include a read-only memory that stores all of the computer software programs (including the transaction application) to be executed by the secure enclave118. Reading and/or writing of data in the memory (e.g., random access memory) of the secure enclave118is controlled by the computer software applications executed within the secure enclave118such that no other processors, including the main processor of the device, can access the data stored in the memory of the secure enclave. In some embodiments, the secure enclave118may include one or more sensors, such as a frequency sensor, a voltage sensor, a light sensor, etc., for detecting physical tampering of the secure enclave118. In some embodiments, upon detecting a possible physical tampering of the secure enclave118, a program executed within the secure enclave118would automatically be triggered to wipe out the data stored within the secure enclave118to further improve the security of the secure enclave118.

In various implementations, the user140is able to input data and information into an input component (e.g., a keyboard) of the user device110. For example, the user140may use the input component to interact with the UI application112, the digital wallet116, and the transaction application executed within the security enclave118(e.g., to conduct cryptocurrency transactions, etc.).

Each of the user devices180and190may include similar hardware and software components as the user device110to enable their respective users to interact with the cryptocurrency computer network120, the service provider server130, and other devices (e.g., to conduct cryptocurrency transactions, etc.) through the user devices180and190. For example, the users of the user devices110,180, and190may use the respective devices to conduct cryptocurrency transactions through different user cryptocurrency accounts. As such, each of the user devices180and190also includes a wallet application (e.g., the wallet applications186and196, respectively) configured to perform cryptocurrency functionalities, in a similar manner as the wallet application116. Each of the user devices180and190also includes a secure enclave (e.g., the secure enclaves188and198, respectively) and transaction applications executed within the secure enclaves188and198configured to conduct offline cryptocurrency transactions. Each of the secure enclaves188and198may include similar attributes as the secure enclave118.

The service provider server130, in one embodiment, may be maintained by a transaction processing entity or an online service provider, which may provide processing for electronic transactions between different entities (e.g., among the users of the user devices110,180, and190, between a user and one or more business entities, or other types of payees. As such, the service provider server130may include a service application138, which may be adapted to interact with the user devices110,180, and190over the network160to facilitate the searching, selection, purchase, payment of items, and/or other services offered by the service provider server130. In one example, the service provider server130may be provided by PayPal©, Inc., of San Jose, California, USA, and/or one or more service entities or a respective intermediary that may provide multiple point of sale devices at various locations to facilitate transaction routings between merchants and, for example, service entities.

In some embodiments, the service application138may include a payment processing application (not shown) for processing purchases and/or payments for electronic transactions between a user and a merchant or between any two entities (e.g., between two users, etc.). In one implementation, the payment processing application assists with resolving electronic transactions through validation, delivery, and settlement. As such, the payment processing application settles indebtedness between a user and a merchant, wherein accounts may be directly and/or automatically debited and/or credited of monetary funds.

The service provider server130may also include an interface server134that is configured to serve content (e.g., web content) to users and interact with users. For example, the interface server134may include a web server configured to serve web content in response to HTTP requests. In another example, the interface server134may include an application server configured to interact with a corresponding application (e.g., a service provider mobile application) installed on the user device110via one or more protocols (e.g., RESTAPI, SOAP, etc.). As such, the interface server134may include pre-generated electronic content ready to be served to users. For example, the interface server134may store a log-in page and is configured to serve the log-in page to users for logging into user accounts of the users to access various services provided by the service provider server130(e.g., such as the cryptocurrency transaction services as disclosed herein). The interface server134may also include other electronic pages associated with the different services (e.g., electronic transaction services, etc.) offered by the service provider server130. As a result, a user (e.g., the user140, users of the user devices180and190, etc.) may access a user account (e.g., a cryptocurrency account) associated with the user and access various services offered by the service provider server130, by generating HTTP requests directed at the service provider server130. In some embodiments, the fragment module integration framework may be implemented within or in association with the interface server134.

The service provider server130, in one embodiment, may be configured to maintain one or more user accounts (e.g., one or more cryptocurrency accounts that are linked to the wallet applications116,186, and196) in an account database136, each of which may be associated with a profile and may include account information associated with one or more individual users (e.g., the user140associated with user device110, users associated with the user devices180and190, etc.). The account information may include an identifier of a cryptocurrency account and an identifier of a transaction application associated with each user account of a user. In one implementation, a user may have credentials to authenticate or verify identity with the service provider server130. Thus, the service provider server may store the credentials of the users in corresponding records of the account database136associated with the user accounts.

In various embodiments, the service provider server130includes a transaction module132configured to facilitate cryptocurrency transactions for the users (e.g., the user140, the users of the user devices180and190, etc.). In some embodiments, the transaction module132may be one of the computer nodes within the cryptocurrency computer network120, and is configured to maintain and manage the distributed ledger associated with the cryptocurrency. Upon receiving transaction data associated with a cryptocurrency transaction from a user via a wallet application or a transaction application, the transaction module132may be configured to broadcast the transaction data to other computer nodes within the cryptocurrency computer network120, and perform the verification and recording processes as disclosed herein. In some embodiments, the transaction module132may also be configured to register transaction applications with the cryptocurrency computer network120and to reserve funds in the cryptocurrency for conducting offline cryptocurrency transactions.

FIGS.2A,2B, and2Cillustrate various stages in conducting an offline cryptocurrency transaction under the framework according to various embodiments of the disclosure. Specifically,FIG.2Aillustrates the steps for registering a transaction application with the cryptocurrency computer network120for performing offline cryptocurrency transactions and reserving a denomination of cryptocurrency for use in one or more offline cryptocurrency transactions.FIG.2Billustrates the steps for conducting an offline cryptocurrency transaction between two transaction applications.FIG.2Cillustrates the steps of committing the transaction data associated with the offline cryptocurrency transaction to the distributed ledger.

As discussed herein, offline cryptocurrency transactions may be conducted by transaction applications that are executed within secure enclaves of devices. Thus, each of the secure enclaves118,188, and198of user devices110,180, and190, respectively, may include a transaction application configured to facilitate offline cryptocurrency transactions under the framework. As shown inFIG.2A, the secure enclave118of the user device110includes a transaction application202, and the secure enclave188of the user device180includes a transaction application204. Offline cryptocurrency transactions may be conducted between the transaction applications202and204using the framework as disclosed herein.

In order to initiate offline cryptocurrency transactions, a user (e.g., the user140) is required to register the transaction application with the cryptocurrency computer network120for performing offline cryptocurrency transactions. In this example, the transaction application202may register itself with the cryptocurrency computer network120for performing offline cryptocurrency transactions when the connectivity of the user device110with the cryptocurrency computer network120is available. To register, the transaction application202may generate a pair of asymmetrical keys for application-based signing (e.g., encrypting), which are also known as application-based signing keys (an application-based private key and an application-based public key). The transaction application202may also generate remote attestation information based on attributes associated with the secure enclave118and the transaction application202. In some embodiments, the remote attestation information may include a signed copy of the programming code associated with the transaction application202that is signed (e.g., encrypted) using the application-based private key of the transaction application202. Based on the signed copy of the programming code, any device that has access to the signed copy of the programming code may (i) verify that the programming code is based on the transaction application202(e.g., by decrypting the signed programming code using the application-based public key of the transaction application202) and (ii) determine attributes of the transaction application202(a make and version number of the transaction application202) that is included in the secure enclave118and whether the transaction application202has been tampered with (e.g., by analyzing the programming code, a device may determine whether malicious code has been added to the transaction application202, any modification has been done to the transaction application202, any code deleted from the transaction application202, etc.). The remote attestation information may also include attributes associated with the secure enclave118(e.g., a hardware and/or software security capability and configuration of the secure enclave118), a signed copy of the identifier of the cryptocurrency account of the user140that is signed (e.g., encrypted) using the application-based private key of the transaction application202, and the application-based public key generated by the transaction application202(for use by other devices to decrypt the signed data).

The transaction application202may then transmit a package222that includes the remote attestation information to the cryptocurrency computer network120(e.g., via the transaction module132of the service provider server130) to be recorded on the distributed ledger. The remote attestation information serves to show the integrity of the transaction application202and that the transaction application202is configured to maintain the integrity of the cryptocurrency (e.g., the recordation of the signed copy of the programming code ensures that anyone that has access to the distributed ledger can verify that the transaction application202would behave according to the transaction communication protocol of the framework and would not behave in a malicious manner). The transaction application202may also store the signed remote attestation information in the secure enclave118of the user device101.

Once the transaction application202has registered itself with the cryptocurrency computer network120for performing offline cryptocurrency transactions, the transaction application202may reserve any portion (or the entirety) of the cryptocurrency possessed by the user140via the cryptocurrency account of the user140for use in one or more offline cryptocurrency transactions for a duration of time. For example, the user140may plan to purchase items or services using cryptocurrency in a remote area where cellular connection may be limited. Before going to the remote area and while the device110still has sufficient network connectivity to communicate with the cryptocurrency computer network120, the user140may request to reserve an amount of cryptocurrency for use in one or more offline cryptocurrency transactions in the future. In some embodiments, the transaction application118may provide a user interface on the user device110to interact with the user140. Through the user interface, the user140may request to reserve any portion of cryptocurrency possessed by the cryptocurrency account of the user140. The user140may specify a particular amount of cryptocurrency (e.g., a particular denomination, such as a coin, five coins, a Satoshi, seven Satoshi, an ether, 10 weis, etc.) to be reserved and a duration of the reservation (e.g., an expiration time, such as 3 hours from a current time, a day from the current time, a month from the current time, etc.). In one example, the user140may plan a trip to an area (e.g., a farmer's market located in a remote area with limited cellular services, etc.). Based on the length of the trip, the transaction application202may instruct the user140to reserve more time than the trip such that the recipient device may have sufficient time to commit the offline cryptocurrency transactions to the distributed ledger after the transaction is complete.

In response to receiving the request, the transaction application202may generate another pair of asymmetrical keys for token-based signing, which is known as the token-based keys (e.g., a token-based private key and a token-based public key). The transaction application202may also generate a token212to represent the particular denomination for use in the one or more offline cryptocurrency transactions. The token may include a hashed message authentication code (HMAC) address for the token (which can be used by other transaction applications to identify the token212and to locate the remote attestation information and other data associated with the secure enclave118and the reserved cryptocurrency denomination stored on the distributed ledger), the particular denomination reserved by the transaction application202and represented by the token212, the expiration time of the token212, and the remote attestation information of the transaction application202. In some embodiments, the transaction application202may also sign (e.g., encrypt) the token212using the token-based private key of the transaction application202.

The transaction application202may transmit a request to reserve the particular denomination of cryptocurrency to the cryptocurrency computer network120(e.g., via the transaction module132of the service provider server130). The request may include the token212intended for representing the particular denomination of cryptocurrency. Upon receiving the request, the cryptocurrency computer network120(or the transaction module132of the service provider server130) may perform a transaction (e.g., executing a contract and recording it on the distributed ledger) to reserve the particular denomination (e.g., to put on hold) owned by the cryptocurrency account of the user140for a time period until the expiration time of the token212. The reservation of the particular denomination, which is recorded on the distributed ledger as a transaction (e.g., a contract), prevents the particular denomination from being used (e.g., spent) by the user140in any online cryptocurrency transactions in the absence of a signed token212that is signed (e.g., encrypted) using the token-based private key of the transaction application202.

Based on the reservation of the particular denomination for the cryptocurrency account of the user140, the cryptocurrency computer network120may generate a record that links the token212and the remote attestation information of the transaction application202to the cryptocurrency account of the user140. The cryptocurrency computer network120may store the record on the distributed ledger, such that any devices associated with a cryptocurrency account may download the record to be used for verification purposes in an offline cryptocurrency transaction with the cryptocurrency account of the user140. For example, the transaction application204executed in the secure enclave188of the user device180may download, from the distributed ledger, the remote attestation information222and the record224to a data storage220(and also remote attestation information and records associated with other cryptocurrency accounts in anticipation of conducting offline cryptocurrency transactions with any cryptocurrency accounts). The data storage220may be part of the secure enclave188or outside of the secure enclave188.

After registering with the cryptocurrency computer network120and reserving the particular cryptocurrency denomination, the transaction application202may initiate offline cryptocurrency transactions through the cryptocurrency account of the user140with another transaction application via a peer-to-peer connection, without the need of connecting to the distributed ledger (or the cryptocurrency computer network120).

FIG.2Billustrates the processes and communications between the transaction applications202and204for conducting an offline cryptocurrency transaction. In this example, the transaction application202may be instructed by the user140to perform an offline cryptocurrency transaction with the transaction application204executed within the secure enclave188of the device180. For example, while the user140is at the remote area, the user140may wish to purchase an item or a service from a user (e.g., a merchant) of the user device180. The transaction application202may establish a peer-to-peer connection260with the transaction application204(e.g., a Bluetooth® connection, a near-field connection, a WiFi connection, etc.). The transaction application202may transmit a request for performing an offline cryptocurrency transaction with the transaction application204. In some embodiments, the transaction application204may first determine whether the connectivity with the cryptocurrency computer network120is available. If the connectivity with the cryptocurrency computer network120is available, the transaction application204may determine to conduct an online cryptocurrency transaction, instead of an offline cryptocurrency transaction, with the transaction application202, and may decline the request.

If the transaction application204determines not to decline the request (e.g., based on a determination that the connectivity with the cryptocurrency computer network120is unavailable, etc.), the transaction application204may proceed to verify the security of the secure enclave118and the transaction application202, and the authenticity of the token212being transferred to the user device180. In some embodiments, after the transaction application204accepts the request, the transaction application202may sign (e.g., encrypt) the token212along with a timestamp representing a current time using the token-based private key associated with the transaction application202. The transaction application202may transmit the signed token, the timestamp, and the signed remote attestation information to the transaction application204via the peer-to-peer connection260. The transaction application204may decrypt the signed token212using the token-based public key associated with the transaction application202and verify that the token212is representative of the particular cryptocurrency denomination (e.g., the particular amount of coins, the particular amount of Satoshis, the particular amount of ether, the particular amount of weis, etc.) of the cryptocurrency account of the user140by comparing the decrypted token212against the token in the record224.

By decrypting the signed token212using the token-based public key associated with the transaction application202and the records224, the transaction application204may further verify that the transaction application202is associated with the cryptocurrency account of the user140. In some embodiments, the transaction application204may analyze the remote attestation information associated with the transaction application202to determine whether the secure enclave118and the transaction application202satisfy a set of security requirements. The set of security requirements may include a make and a minimum version number of secure enclaves (that the secure enclave118is made by an approved manufacturers with a version higher than a threshold version number, etc.) and/or a set of hardware/software security requirements (e.g., the presence of certain sensors, such as light sensor, frequency sensor, etc., the presence of certain software security measures, etc.). The set of requirements may be determined automatically by the transaction application204or by the user of the device180. In some embodiments, the transaction application204may decline the request to perform the offline cryptocurrency transaction with the transaction application202if the transaction application204determines that the secure enclave118or the transaction application202fails to satisfy the set of security requirements (e.g., the version of the secure enclave118is too old, the secure enclave118lacks one or more required hardware or software security features, etc.).

In some embodiments, the transaction application204may also verify that the timestamp received from the transaction application202(or the current time) indicates a time that is after the time when the token212was generated and before the expiration time of the token212. In some embodiments, the transaction application204may also determine whether a difference between the current time and the expiration time of the token212is larger than a threshold (e.g., 3 hours, a day, etc., which can be determined by the transaction application204or by the user of the device180) such that the transaction application204has sufficient time to record the transaction on the distributed ledger after completing the offline cryptocurrency transaction with the transaction application202. In some embodiments, the transaction application204may decline the request to conduct the offline cryptocurrency transaction (e.g., abort the transaction process) with the transaction application202when the difference between the current time and the expiration time of the token212is not larger than the threshold.

If the transaction application204determines to decline the request to conduct the offline cryptocurrency transaction with the transaction application202, the transaction application204may transmit a termination signal to the transaction application202via the peer-to-peer connection260, and may remove all of the data received from the transaction application202related to the offline cryptocurrency transaction. However, if the transaction application204determines to continue processing the offline cryptocurrency transaction, the transaction application204may transmit a confirmation signal to the transaction application202via the peer-to-peer connection260. The confirmation signal indicates that the transaction application204has accepted the signed token212from the transaction application202. The transaction application204may then store the signed token212in the secure enclave188of the user device180. Upon receiving the confirmation signal, the transaction application202may delete the signed token212from the secure enclave118to ensure that the token212will not be spent again (e.g., the transaction application202may no longer use the token in any other offline cryptocurrency transaction). In some embodiments, the transaction application202may transmit a token deletion signal to the transaction application204via the peer-to-peer connection260, indicating that the token212has been removed from the secure enclave118to confirm that the transaction application204has the only copy of the signed token212.

After the offline cryptocurrency transaction between the transaction applications202and204is complete and before the expiration of the token212, the transaction application204may commit the offline cryptocurrency transaction to the distributed ledger, such that the transaction data associated with the offline cryptocurrency transaction can be verified and recorded on the distributed ledger.FIG.2Cillustrates the steps for committing the offline cryptocurrency transaction to the distributed ledger. As discussed above, one of the reasons for conducting the offline cryptocurrency transaction between the transaction applications202and204is that neither the device110nor the device180has connectivity to the distributed ledger (the cryptocurrency computer network120) at the time the transaction was conducted. Thus, after completing the offline cryptocurrency transaction, the transaction application204may monitor the connectivity between the device180and the cryptocurrency computer network120(e.g., the transaction module132of the service provider server130).

For example, the transaction application204may attempt to communicate with a computer node (e.g., the transaction module132of the service provider server130) of the cryptocurrency computer network120(e.g., periodically such as every five minutes, every hour, etc.). The transaction application204may transmit a signal to a network address associated with the computer node via a network (e.g., the network160) and determine whether a response signal from the computer node is received. In some embodiments, the transaction application204may be configured to attempt to communicate with a computer node of the cryptocurrency computer network120in a progressively shorter interval, such that the transaction application204may attempt to communicate to the cryptocurrency computer network120more frequently as it is closer to the expiration time of the token212. For example, immediately after completing the offline cryptocurrency transaction, the transaction application204may begin with attempting to communicate with the cryptocurrency computer network120every hour. As it gets closer to the expiration time of the token212, the transaction application204may increase the frequency of communication attempts to every five minutes, every minute, every second, etc.

When the transaction application204determines that the connectivity with the distributed ledger (e.g., with a node within the cryptocurrency computer network120) is available, the transaction application204may communicate the signed token212and other transaction data226associated with the offline cryptocurrency transaction to the node within the cryptocurrency computer network120(e.g., the transaction module132of the service provider server130). The communication of the signed token212and the transaction data226to the cryptocurrency computer network212may trigger the verification and recordation of the offline cryptocurrency transaction on the distributed ledger, in a similar manner as an online cryptocurrency transaction is verified and recorded. After committing the offline cryptocurrency transaction to the distributed ledger, the transaction application204may be configured to remove the signed token212from the secure enclave188to prevent the user of the user device180from using the signed token212in another offline cryptocurrency transaction (the signed token212is no longer valid after committing the offline cryptocurrency transaction to the distributed ledger). Thus, using the framework as disclosed herein, cryptocurrency transactions can be conducted between devices associated with cryptocurrency accounts even when the devices temporarily lose connectivity with the distributed ledger.

In some embodiments, instead of committing the offline cryptocurrency transaction to the distributed ledger, the transaction application204may use the signed token212to conduct additional offline cryptocurrency transactions with other transaction applications. When the same token is used in subsequent offline cryptocurrency transactions in series, the sequence of offline cryptocurrency transactions conducted using the same token is referred to as a chain of offline cryptocurrency transactions, and each offline cryptocurrency transaction within the chain is a chained offline cryptocurrency transaction.FIGS.3A,3B, and3Cillustrate various stages in a chained offline cryptocurrency transaction conducted under the framework according to various embodiments of the disclosure. Specifically,FIG.3Aillustrates steps for registering a transaction application with the cryptocurrency computer network120for performing offline cryptocurrency transactions.FIG.3Billustrates the steps for conducting a chained offline cryptocurrency transaction between two transaction applications.FIG.3Cillustrates the steps of committing the transaction data associated with the offline cryptocurrency transaction to the distributed ledger.

In some embodiments, in order for the transaction application204to initiate offline cryptocurrency transactions with other transaction applications, the transaction application204may register itself with the cryptocurrency computer network120for performing offline cryptocurrency transactions when the connectivity of the user device180with the cryptocurrency computer network120is available.FIG.3Aillustrates the registration of the transaction application204with the cryptocurrency computer network120for conducting offline cryptocurrency transactions. The steps for registering the transaction application204with the cryptocurrency computer network120for conducting offline cryptocurrency transactions is similar to the steps for registering the transaction application202disclosed above with respect toFIG.2A. For example, the transaction application204may generate a pair of asymmetrical keys for application-based signing, which are also known as application-based signing keys (an application-based private key and an application-based public key). The transaction application204may generate remote attestation information based on attributes associated with the secure enclave188. In some embodiments, the remote attestation information may include a signed copy of the programming code associated with the transaction application204that is signed (e.g., encrypted) using the application-based private key of the transaction application204(which may indicate a make and version number of the transaction application204), attributes associated with the second secure enclave188(e.g., a hardware and/or software security capability and configuration of the second secure enclave188), a signed copy of the identifier of the cryptocurrency account associated with the user device180that is signed (e.g., encrypted) using the application-based private key of the transaction application204, and the application-based public key generated by the transaction application204. As shown inFIG.3A, the transaction application204may transmit a package232that includes the remote attestation information to the cryptocurrency computer network120to be recorded on the distributed ledger. Since a chained offline cryptocurrency transaction re-uses the token obtained from a previous offline cryptocurrency transaction, there is no need to generate additional tokens and/or reserve additional denomination of cryptocurrency.

Other transaction applications may download the package232(along with the package222and the record224associated with the transaction application202) from the distributed ledger when the connectivity with the cryptocurrency computer network120is available. For example, a transaction application206executed in the secure enclave198of the user device190may download packages and records associated with different transaction applications when the connectivity with the cryptocurrency computer network120is available, in anticipation of conducting offline cryptocurrency transactions with other transaction applications. The downloaded packages and records may include the package232associated with the transaction application204, and the package222and the record224associated with the transaction application202. The transaction application206may store the package232, the package222, and the record224in a data storage230. The data storage230may be part of the secure enclave198or outside of the secure enclave198.

After registering with the cryptocurrency computer network120, the transaction application204may initiate offline cryptocurrency transactions with another transaction application via a peer-to-peer connection using the signed token212obtained from the transaction application202, without the need of connecting to the distributed ledger (or the cryptocurrency computer network120).

FIG.3Billustrates the processes and communications between the transaction applications204and206for conducting a chained offline cryptocurrency transaction. In this example, the transaction application204may be instructed by the user of the user device180to initiate a chained offline cryptocurrency transaction with the transaction application206executed within the secure enclave198of the device190. The transaction application204may establish a peer-to-peer connection262with the transaction application206(e.g., a Bluetooth® connection, a near-field connection, a WiFi connection, etc.). The transaction application204may transmit a request for performing an offline cryptocurrency transaction with the transaction application206. In some embodiments, the transaction application206may first determine whether the connectivity with the cryptocurrency computer network120is available. If the connectivity with the cryptocurrency computer network120is available, the transaction application206may determine to conduct an online cryptocurrency transaction, instead of an offline cryptocurrency transaction, with the transaction application204, and may decline the request.

If the transaction application206determines not to decline the request (e.g., based on a determination that the connectivity with the cryptocurrency computer network120is unavailable, etc.), the transaction application206may proceed to verify the authenticity of the token212and the security of any secure enclaves within which the token212has been stored through a chain of offline cryptocurrency transactions that involves the token212. For example, based on information (e.g., the remote attestation information associated with the transaction applications202and204, etc.) received from the transaction application204, the transaction application206may determine that the token was originated from the transaction application202, and was transmitted to the transaction application204in a previous cryptocurrency transaction between the transaction applications202and204.

Thus, the transaction application206may verify the authenticity of the token212, the security of the secure enclaves118and188, and the security of the transaction applications202and204. In some embodiments, after the transaction application206accepts the request, the transaction application204may sign (e.g., encrypt) the token212(which has already been signed using the token-based private key associated with the transaction application202) using the token-based private key associated with the transaction application204. As such, the token212is now signed with two different private keys, one associated with the transaction application202and the other one associated with the transaction application204. The transaction application204may transmit the signed token212, a timestamp, and the signed remote attestation information associated with the transaction application204to the transaction application206via the peer-to-peer connection262. The transaction application206may decrypt the signed token212using first the token-based public key associated with the transaction application204, and then the token-based public key associated with the transaction application202. The transaction application206may verify that the token212is representative of the particular cryptocurrency denomination (e.g., the particular amount of coins, the particular amount of Satoshis, the particular amount of ether, the particular amount of weis, etc.) of the cryptocurrency account of the user140by comparing the decrypted token212against the token in the record224.

By decrypting the signed token212using the token-based public keys associated with the transaction applications202and204, the transaction application206may further verify that the chain of offline cryptocurrency transactions includes a previous offline cryptocurrency transaction between the transaction applications202and204. In some embodiments, the transaction application204may analyze the remote attestation information associated with the transaction application202and the remote attestation information associated with the transaction application204to determine whether the secure enclaves118and188satisfy a set of security requirements. The set of security requirements may include a make and a minimum version number of secure enclaves (that the secure enclaves118and188are made by an approved manufacturer with a version higher than a threshold version number, etc.) and/or a set of hardware/software security requirements (e.g., the presence of certain sensors, such as light sensor, frequency sensor, etc., the presence of certain software security measures, etc.). The set of requirements may be determined automatically by the transaction application206or by a user of the user device190. In some embodiments, the transaction application206may decline the request to perform the offline cryptocurrency transaction with the transaction application204if the transaction application206determines that the secure enclave118or the secure enclave188fails to satisfy the set of security requirements (e.g., the version of either of the secure enclaves is too old, either of the secure enclaves lacks one or more required hardware or software security features, etc.).

In some embodiments, the transaction application206may also verify that the timestamp received from the transaction application204(or the current time) indicates a time that is after the time when the token212was generated and before the expiration time of the token212. In some embodiments, the transaction application206may also determine whether a difference between the current time and the expiration time of the token212is larger than a threshold (e.g., 3 hours, a day, etc.) such that the transaction application206has sufficient time to record the transaction on the distributed ledger after completing the offline cryptocurrency transaction with the transaction application204. In some embodiments, the transaction application206may decline the request to conduct the offline cryptocurrency transaction (e.g., abort the transaction process) with the transaction application204when the difference between the current time and the expiration time of the token212is not larger than the threshold.

If the transaction application206determines to decline the request to conduct the offline cryptocurrency transaction with the transaction application204, the transaction application206may transmit a termination signal to the transaction application204via the peer-to-peer connection262, and may remove all of the data received from the transaction application204related to the offline cryptocurrency transaction. However, if the transaction application206determines to continue processing the offline cryptocurrency transaction, the transaction application206may transmit a confirmation signal to the transaction application204via the peer-to-peer connection262. The confirmation signal indicates that the transaction application206has accepted the signed token212from the transaction application204. The transaction application206may then store the signed token212in the secure enclave198of the user device190. Upon receiving the confirmation signal, the transaction application204may delete the signed token212from the secure enclave188to ensure that the token212will not be double-spent (e.g., the transaction application204may no longer use the token in any other offline cryptocurrency transaction). In some embodiments, the transaction application204may transmit a token deletion signal to the transaction application206via the peer-to-peer connection262, indicating that the token212has been removed from the secure enclave188to confirm that the transaction application206has the only copy of the signed token212.

After the offline cryptocurrency transaction between the transaction applications204and206is complete and before the expiration of the token212, the transaction application206may commit the chain of offline cryptocurrency transactions to the distributed ledger, such that the transaction data associated with the chain of offline cryptocurrency transactions can be verified and recorded on the distributed ledger.FIG.3Cillustrates the steps for committing the chain of offline cryptocurrency transactions to the distributed ledger. In some embodiments, after completing the offline cryptocurrency transaction with the transaction application204, the transaction application206may attempt to communicate with the cryptocurrency computer network120in a similar manner discussed above by reference toFIG.2C. For example, the transaction application206may attempt to communicate with a computer node (e.g., the transaction module132of the service provider server130) of the cryptocurrency computer network120(e.g., periodically such as every five minutes, every hour, etc.). The transaction application206may transmit a signal to a network address associated with the computer node via a network (e.g., the network160) and determine whether a response signal from the computer node is received. In some embodiments, the transaction application206may be configured to attempt to communicate with a computer node of the cryptocurrency computer network120in a progressively shorter interval, such that the transaction application206may attempt to communicate to the cryptocurrency computer network120more frequently as it is closer to the expiration time of the token212. For example, immediately after completing the offline cryptocurrency transaction, the transaction application206may begin with attempting to communicate with the cryptocurrency computer network120every hour. As it gets closer to the expiration time of the token212, the transaction application206may increase the frequency of communication attempts to every five minutes, every minute, every second, etc.

When the transaction application206determines that the connectivity with the distributed ledger (e.g., with a node within the cryptocurrency computer network120) is available, the transaction application206may communicate the signed token212and other transaction data236associated with the chain of offline cryptocurrency transactions (e.g., including the transaction data associated with the offline cryptocurrency transaction between the transaction applications202and204, and the transaction data associated with the offline cryptocurrency transaction between the transaction applications204and206) to the node within the cryptocurrency computer network120(e.g., the transaction module132of the service provider server130). The communication of the signed token212and the transaction data236to the cryptocurrency computer network212may trigger the verification and recordation of the chain offline cryptocurrency transactions (the two sequential cryptocurrency transactions) on the distributed ledger, in a similar manner a sequence of online cryptocurrency transactions is verified and recorded. After committing the chain of offline cryptocurrency transactions to the distributed ledger, the transaction application206may be configured to remove the signed token212from the secure enclave198to prevent the user of the user device190from using the signed token212in another offline cryptocurrency transaction (the signed token212is no longer valid after committing the chain of offline cryptocurrency transactions to the distributed ledger). Performing and committing a chain of multiple offline cryptocurrency transactions to the distributed ledger also provide additional efficiency benefits. Since the chain of offline cryptocurrency transactions is verified and recorded on the distributed ledger by the cryptocurrency computer network120as a whole, the total amount of computer resources required for processing all of the transactions within the chain would be less than the amount of computer resources required for processing those transactions separately, as a single verification may be performed for all of the transactions in the chain.

In the examples illustrated above, each of the offline cryptocurrency transactions were conducted using the token representing the entire cryptocurrency denomination that is reserved for the transaction application. In some embodiments, the framework also enables offline cryptocurrency transactions to be conducted using a portion of the entire cryptocurrency denomination.FIG.4illustrates an example of splitting a reserved amount of cryptocurrency into multiple sub-denominations for use in offline cryptocurrency transactions. In the example illustrated inFIG.4, after generating the initial token212(also referred to as the “parent token”), the transaction application202may split the particular cryptocurrency denomination into multiple portions by generating multiple child tokens (e.g., tokens412and414) based on the parent token212. Each of the child tokens412and414may include a reference to the parent token212(e.g., the HMAC address of the parent token212), an HMAC address associated with the child token, a timestamp indicating the time that the child token is generated, and a sub-denomination representing a particular portion of the particular cryptocurrency denomination. The transaction application202may then record the child tokens412and414on the distributed ledger in association with the parent token212in a similar manner that the parent token is recorded. The cryptocurrency computer network120may generate a record424that links the child tokens412and414to the cryptocurrency account of the user140. Thus, other transaction applications (e.g., the transaction application204) may download the package222that includes the remote attestation information of the transaction application202along with the record424in anticipation of conducting future offline cryptocurrency transactions with the transaction application202. The transaction application202may then use any of the child tokens412and414to conduct offline cryptocurrency transactions with other transaction applications (e.g., the transaction application204). Upon receiving a request to conduct an offline cryptocurrency transaction with the transaction application202based on the child token412, the transaction application204may verify the token using at least the record424downloaded from the distributed ledger.

FIG.5illustrates a process500for registering a transaction application with a cryptocurrency computer network and reserving a denomination of cryptocurrency for offline cryptocurrency transactions according to various embodiments of the disclosure. In some embodiments, at least a portion of the process500may be performed by a transaction application (e.g., the transaction application202). The process500may begin by generating (at step505) remote attestation data for a transaction application. For example, in order to initiate offline cryptocurrency transactions (e.g., transferring cryptocurrency to another account) with other transaction applications, the transaction application202may register itself with the cryptocurrency computer network120. The transaction application202may generate remote attestation information based on attributes of the transaction application202and the secure enclave118in which the transaction application202is executed. The remote attestation information may include information associated with the programming code of the transaction application202(e.g., a version number of the programming code, etc.) and information associated with the secure enclave118(e.g., a make and version number of the secure enclave118, security features of the secure enclave118, etc.).

The process500then reserves (at step510) a denomination of cryptocurrency for offline cryptocurrency transactions for a time duration. For example, the transaction application202may submit a request to the cryptocurrency computer network120for reserving a denomination (e.g., a coin, 3 coins, etc.) of cryptocurrency. The process500also generates (at step515) one or more tokens to represent the reserved denomination of cryptocurrency and records (at step520) a copy of the one or more tokens in the distributed ledger. For example, the transaction application202may generate a token212to represent the denomination of cryptocurrency for use in the one or more offline cryptocurrency transactions. The token212may indicate the denomination of cryptocurrency it represents and an expiration time. The transaction application202may transmit a copy of the token212to the cryptocurrency computer network120to be recorded on the distributed ledger.

The process500stores (at step525) the one or more tokens in a secure enclave of a device. For example, the transaction application202may store the token212in the secure enclave118of the user device110. The process500also downloads (step530) remote attestation data and records associated with other transaction applications. For example, other transaction applications (e.g., the transaction applications204and206) may also register themselves with the cryptocurrency computer network and may reserve denominations of cryptocurrency for offline cryptocurrency transactions. As such, the transaction application202may download, from the distributed ledger, the remote attestation data and records (that link tokens to different cryptocurrency accounts) associated with the transaction applications204and206. Similarly, the transaction applications204and206may also download, from the distributed ledger, the remote attestation data and records associated with the transaction application202.

FIG.6illustrates a process600for conducting an offline cryptocurrency transaction according to various embodiments of the disclosure. In some embodiments, at least a portion of the process600may be performed by a transaction application (e.g., the transaction application204). The process600may begin by receiving (at step605), from a first transaction application, a request to conduct an offline cryptocurrency transaction. For example, the transaction application204may receive a request to conduct an offline cryptocurrency transaction with the transaction application202via the peer-to-peer connection260established between the user devices110and180.

The process600then performs a series of verifications before accepting the offline cryptocurrency transaction. Specifically, the process600verifies (at step610) that the first transaction application is associated with a first cryptocurrency account, verifies (at step615) that security attributes associated with the first secure enclave and the first transaction application satisfy a set of criteria, and verifies (at step620) that the current time is after the time that the token was generated and before the expiration time of the token. For example, the transaction application204may use a public key associated with the transaction application202to decrypt the token212and use the record from the distributed ledger to verify that the transaction application202is associated with a particular cryptocurrency account that owns the particular denomination of cryptocurrency represented by the token212. The transaction application204may also analyze the remote attestation information associated with the transaction application202to determine whether the attributes of the secure enclave118and the transaction application202satisfy a set of criteria.

When the verification steps are successfully completed, the process600stores (at step625) the signed token in a second secure enclave of a second device. For example, the transaction application202may sign the token212using a private key associated with the transaction application202and transmit the signed token212to the transaction application204via the peer-to-peer connection260. If the transaction application204accepts the signed token212(e.g., completed all of the verification steps), the transaction application204may store the signed token212in the secure enclave188, and may transmit a confirmation signal to the transaction application202. Upon receiving the confirmation signal, the transaction application202may delete the signed token212from the secure enclave118.

The process600then transmits (at step630) transaction data associated with the offline cryptocurrency transaction to the cryptocurrency computer network when a connectivity with the distributed ledger is available. For example, after conducting the offline cryptocurrency transaction with the transaction application202, the transaction application204may monitor the connectivity with the distributed ledger (e.g., the cryptocurrency computer network120). When the connectivity with the distributed ledger becomes available, the transaction application204may transmit transaction data associated with the offline cryptocurrency transaction to the cryptocurrency computer network120such that the offline cryptocurrency transaction can be verified and recorded by the cryptocurrency computer network120on the distributed ledger in the same manner as processing an online cryptocurrency transaction.

FIG.7is a block diagram of a computer system700suitable for implementing one or more embodiments of the present disclosure, including the service provider server130, any computer node within the cryptocurrency computer network120, and the user devices110,180, and190. In various implementations, each of the devices110,180, and190may include a mobile cellular phone, personal computer (PC), laptop, wearable computing device, etc. adapted for wireless communication, and each of the service provider server130and any node in the cryptocurrency computer network120may include a network computing device, such as a server. Thus, it should be appreciated that the devices/servers110,130,180, and190, and any computer nodes in the cryptocurrency computer network120may be implemented as the computer system700in a manner as follows.

The computer system700includes a bus712or other communication mechanism for communicating information data, signals, and information between various components of the computer system700. The components include an input/output (I/O) component704that processes a user (i.e., sender, recipient, service provider) action, such as selecting keys from a keypad/keyboard, selecting one or more buttons or links, etc., and sends a corresponding signal to the bus712. The I/O component704may also include an output component, such as a display702and a cursor control708(such as a keyboard, keypad, mouse, etc.). The display702may be configured to present a login page for logging into a user account. An optional audio input/output component706may also be included to allow a user to use voice for inputting information by converting audio signals. The audio I/O component706may allow the user to hear audio. A transceiver or network interface720transmits and receives signals between the computer system700and other devices, such as another user device, a merchant server, or a service provider server via a network722, such as network160ofFIG.1. In one embodiment, the transmission is wireless, although other transmission mediums and methods may also be suitable. A processor714, which can be a micro-controller, digital signal processor (DSP), or other processing component, processes these various signals, such as for display on the computer system700or transmission to other devices via a communication link724. The processor714may also control transmission of information, such as cookies or IP addresses, to other devices.

The components of the computer system700also include a system memory component710(e.g., RAM), a static storage component716(e.g., ROM), and/or a disk drive718(e.g., a solid-state drive, a hard drive). The computer system700performs specific operations by the processor714and other components by executing one or more sequences of instructions contained in the system memory component710. For example, the processor714can perform the functionalities related to conducting offline cryptocurrency transactions described herein according to the processes500and600.

Logic may be encoded in a computer readable medium, which may refer to any medium that participates in providing instructions to the processor714for execution. Such a medium may take many forms, including but not limited to, non-volatile media, volatile media, and transmission media. In various implementations, non-volatile media includes optical or magnetic disks, volatile media includes dynamic memory, such as the system memory component710, and transmission media includes coaxial cables, copper wire, and fiber optics, including wires that comprise the bus712. In one embodiment, the logic is encoded in non-transitory computer readable medium. In one example, transmission media may take the form of acoustic or light waves, such as those generated during radio wave, optical, and infrared data communications.

Some common forms of computer readable media include, for example, floppy disk, flexible disk, hard disk, magnetic tape, any other magnetic medium, CD-ROM, any other optical medium, punch cards, paper tape, any other physical medium with patterns of holes, RAM, PROM, EPROM, FLASH-EPROM, any other memory chip or cartridge, or any other medium from which a computer is adapted to read.

In various embodiments of the present disclosure, execution of instruction sequences to practice the present disclosure may be performed by the computer system700. In various other embodiments of the present disclosure, a plurality of computer systems700coupled by the communication link724to the network (e.g., such as a LAN, WLAN, PTSN, and/or various other wired or wireless networks, including telecommunications, mobile, and cellular phone networks) may perform instruction sequences to practice the present disclosure in coordination with one another.

Where applicable, various embodiments provided by the present disclosure may be implemented using hardware, software, or combinations of hardware and software. Also, where applicable, the various hardware components and/or software components set forth herein may be combined into composite components comprising software, hardware, and/or both without departing from the spirit of the present disclosure. Where applicable, the various hardware components and/or software components set forth herein may be separated into sub-components comprising software, hardware, or both without departing from the scope of the present disclosure. In addition, where applicable, it is contemplated that software components may be implemented as hardware components and vice-versa.

Software in accordance with the present disclosure, such as program code and/or data, may be stored on one or more computer readable mediums. It is also contemplated that software identified herein may be implemented using one or more general purpose or specific purpose computers and/or computer systems, networked and/or otherwise. Where applicable, the ordering of various steps described herein may be changed, combined into composite steps, and/or separated into sub-steps to provide features described herein.

The various features and steps described herein may be implemented as systems comprising one or more memories storing various information described herein and one or more processors coupled to the one or more memories and a network, wherein the one or more processors are operable to perform steps as described herein, as non-transitory machine-readable medium comprising a plurality of machine-readable instructions which, when executed by one or more processors, are adapted to cause the one or more processors to perform a method comprising steps described herein, and methods performed by one or more devices, such as a hardware processor, user device, server, and other devices described herein.