Leveraging tamper-resistant hardware to transfer digital currency between local devices

Abstract

Digital transactions are secured by utilizing tamper-resistant hardware associated with at least one of the devices involved in the transaction. The mechanism controlling the transaction between the sending and receiving devices, such as an application or application plug-in, is configured to assign a high degree of trust to at least one of the devices with tamper-resistant hardware. In this way, any confirmations and representations from the device with tamper-resistant hardware can be trusted and locally relied upon. The tamper-resistant device is configured with rules to prevent certain actions, such as double-spending and over-spending, among other rules. Thus, as long as the receiving device can verify that the sending device is configured with tamper-resistant hardware, the receiving device can trust that the sending device is operating within the prescribed rules and that the money will be sent.

Description

[Technical Field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This non-provisional application claims benefit of and priority to U.S. Provisional Application No. 63 / 086,451, entitled "An Asynchronous Distributed Ledger with High Concurrency and Byzantine Fault Tolerance," filed October 1, 2020, the contents of which are incorporated herein by reference in their entirety. [Background technology]

[0002] The emergence of cryptocurrencies, mobile payments, and new banking regulations, among other developments, has led to an explosion of interest in digital payment technologies. At the heart of these digital payment systems is typically a digital ledger. A common approach to keeping a digital ledger secure is to distribute copies across multiple nodes. The challenge here is to keep the ledger synchronized and responsive to updates while dealing with system failures and network interruptions. Synchronizing the ledger is a challenge because failures can be engineered by an intelligent adversary aiming to subvert the system; such failures are commonly referred to as "Byzantine failures."

[0003] In addition to synchronizing ledgers, securing peer-to-peer digital transactions between personal wallets also poses problems. When a payment is transferred over an untrusted communication channel, it can be difficult to determine whether a digital payment was successfully transferred to another party over the untrusted communication. For example, assume that the channel stops working immediately after the payment is sent. In that case, the sender cannot know whether the payment failed or simply failed to receive confirmation that the transfer was successful. While the true situation can eventually be discovered when communication is restored, the deferred resolution presents problems in a live setting.

[0004] For example, in a retail setting, customers want to leave the store with the money they brought or the goods they purchased. If they leave the site believing their payment failed, they may not notice a charge appearing on their account later. Even if they do notice, it can be difficult to resolve the issue with the merchant. Payment service providers may be required to resolve disputes, which adds operational overhead and opens new avenues for fraud if the mechanisms for correcting incomplete transactions are broken. These challenges may grow as digital payment technologies expand to more devices, participants, and communication settings. Summary of the Invention

[0005] Digital transactions are secured by utilizing tamper-resistant hardware associated with at least one of the devices involved in the transaction. The mechanism controlling the transaction between the sending and receiving devices, such as an application or application plug-in, is configured to assign a high degree of trust to at least one of the devices with tamper-resistant hardware. In this way, any confirmations and representations from the device with tamper-resistant hardware can be trusted and locally relied upon.

[0006] The private key may be securely stored in tamper-resistant hardware within the user's device; The tamper-resistant device may be configured with rules to prevent certain actions, such as double-spending and over-spending, among other rules. Thus, as long as the funds in an account are under the exclusive control of its private key and the receiving device can verify that the sending device is configured with tamper-resistant hardware, the receiving device can trust that the sending device is operating within the prescribed rules, that the money will be transferred, and that the person behind the sending device is likely authenticated. Digital transactions can be carried out even if network connectivity to the remote ledger is incomplete or lost. The sending and receiving devices can report the transaction for inclusion in the ledger when network connectivity is re-established. To establish that funds are under the control of a private key known only to a genuine tamper-resistant hardware device operating according to a prescribed algorithm, the mutually trusted ledger may provide the device with a signed spend authorization that the device may present to other devices. The spend authorization may establish parameters such as a spending limit and may include an expiration date.

[0007] If the network connection is subject to failure, the sending device may forward a reversible payment transaction (RPT) to the receiving device. The RPT promises to settle a specific amount, subject to sender reversal, within the reversibility period transmitted in the RPT. The receiving device transmits a confirmation to the sending device in response to the RPT. The sending device transmits a non-reversible payment transaction (non-RPT) in response to receiving the receiver's confirmation. The sending device may also display "settled" on its user interface. The receiving device may report the executed transaction and the non-RPT to the ledger when the network connection is re-established. If the sending device fails to receive the confirmation, the sending device may generate a reversible payment transaction, display "canceled" on its user interface, and report the canceled transaction to the ledger when the network connection is re-established.

[0008] The receiving device, while still relying on viable communication with the sending device's tamper-resistant hardware, can confirm the fund transfer directly on the ledger if a live network connection is available. In this implementation, upon receiving the RPT from the sending device, the receiving device looks up and confirms the RPT with the ledger. The receiving device waits until the ledger transaction has been confirmed by the ledger before forwarding the confirmation to the sending device. While the receiving device continues to trust the sender's tamper-resistant device, the ability to verify the transaction with the remote ledger is available in real time and provides additional security that will ultimately be required by the sender and receiving devices anyway.

[0009] Additionally, the sending device may request a new spend authorization from the ledger to prioritize transmission of the RPT to the receiving device if a live connection is available. The spend authorization transmitted by the ledger provides updated proof of funds to the sending device's tamper-resistant hardware. This spend authorization may be passed to the ledger via the receiving device or transmitted separately from the sending device to the ledger.

[0010] Peer-to-peer digital transactions can also be secured if the receiver's device, rather than the sender's, has tamper-proof hardware. In this scenario, the sender device digitally signs a transaction to pay a specified amount to the receiver device and transmits the signed transaction to the receiver device over the local network in use. The receiver device saves the transaction in persistent local storage and submits it to the ledger either over a live network connection or as a pass-through using the sender's live connection to the ledger. When the ledger executes a transfer from the sending account to the receiving account, the ledger records a reverse check that the receiving device may perform to move the funds back to the sending device. If the receiving device receives confirmation from the ledger that the funds were successfully transferred, it signs and stores a completion transaction that cancels without performing the reverse check. If the receiving device fails to receive confirmation of the successful funds transfer from the ledger, the tamper-proof hardware performs the reverse check and thereby signs and stores a completion transaction that refunds the sender's money. If the original transfer is not performed on the ledger, there is no reverse check, so attempts to perform one have no effect.

[0011] While network connectivity failures with the ledger may be rare, the system's security measures and configuration help prevent attacks and unintended consequences orchestrated by malicious actors in those rare circumstances when network connectivity is lost. Reliance on tamper-resistant hardware on one or both devices in a transaction limits malicious actors' attempts to disrupt network connectivity, both locally to the other party and remotely to the ledger. The instant system's configuration allows all parties, including malicious third parties, to reach correct and defined conclusions.

[0012] This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended for use as an aid in determining the scope of the claimed subject matter. Moreover, the claimed subject matter is not limited to implementations that solve any or all of the disadvantages noted in any part of this disclosure. These and various other features will be apparent from a reading of the Detailed Description below and a review of the associated drawings. [Brief explanation of the drawings]

[0013] [Figure 1] 1 illustrates an exemplary environment of various users using local and remote ledger services to perform settlement transactions. [Figure 2] 1 illustrates an exemplary closed environment in which an originating wallet transmits a payment to a recipient wallet. [Figure 3] 1 illustrates an exemplary environment in which transactions between a sending device and a receiving device are reported to a remote ledger service. [Figure 4] 1 illustrates an exemplary environment in which a sending device having tamper-resistant hardware attempts a transaction with a receiving device. [Figure 5] 1 illustrates an exemplary schema of security features associated with tamper-resistant hardware. [Figure 6] 1 illustrates an exemplary environment with a network outage on a remote ledger service. [Figure 7] 1 illustrates an exemplary environment in which a sending device transmits a revocable payment transaction (RPT) to a receiving device. [Figure 8] 1 illustrates an exemplary environment in which a sending device transmits a non-RPT to a receiving device and, after receiving confirmation from the receiving device, displays "Payment Completed" on its user interface. [Figure 9] 1 illustrates an exemplary environment in which a sending device cancels a transaction and displays "cancelled" on its UI after failing to receive confirmation from the receiving device. [Figure 10] 1 shows a transaction flow diagram for an off-network payment protocol. [Figure 11] 1 shows a transaction flow diagram for a half-off network settlement protocol. [Figure 12] 10 shows a transaction flow diagram in which the receiving device has tamper-resistant hardware. [Figure 13] 1 illustrates an example flow diagram of a system that utilizes tamper-resistant hardware to transfer digital currency between local devices. [Figure 14] 1 illustrates an example flow diagram of a system that utilizes tamper-resistant hardware to transfer digital currency between local devices. [Figure 15] 1 shows a simplified block diagram of a computing device that may be used to implement the tamper-resistant hardware utilization of the present invention to transfer digital currency between local devices. [Figure 16] 1 shows a simplified block diagram of a computing device that may be used to implement the tamper-resistant hardware utilization of the present invention to transfer digital currency between local devices. DETAILED DESCRIPTION OF THE INVENTION

[0014] Like reference numerals refer to like elements in the several drawings, and elements are not drawn to scale unless otherwise indicated.

[0015] 1 illustrates an exemplary environment in which multiple, separate users 110 have their own digital wallets 130 and local ledgers 125 instantiated on their respective computing devices 105 to conduct transactions 115 in the form of transmitting and receiving digital payments. Each computing device may have a digital wallet from which digital currency is debited and credited. In this implementation, each user's computing device may have a common digital wallet application that utilizes the local ledger and the system described herein so that the wallets can communicate with each other on the same digital transaction platform.

[0016] As described in more detail below, a transaction between two users 110 is executed on their respective computing devices 105. The transaction 115 is executed on each local ledger, and once completed, the users' respective wallets 130 submit details of the transaction 135 to a remote ledger service 120 for completion. In some implementations, the remote ledger service may be configured using distributed ledger technology (DLT) or any other general ledger service capable of recording peer-to-peer transactions, as discussed below.

[0017] For example, as shown in FIG. 1, the remote ledger service 120 consists of multiple independent ledger nodes 155, with 3f+1 such nodes allowing for secure operation in the presence of failed nodes. Each ledger node has a public key known to the wallet, allowing the wallet to verify whether a given ledger node created a message. A transaction is completed when 2f+1 ledger nodes return a positive response. Completion ensures that the transaction matches all other completed transactions on the ledger service; that is, each wallet can only spend funds that it has received and not yet spent. Recipients of transactions can rely on relentless tracking of completion; without completion, value is not credited to the recipient's account.

[0018] 2 illustrates an exemplary transaction 215 between two users 110, 210. User 110 and device 105 are the sending user and sending device, respectively, and user 210 and device 205 are the receiving user and receiving device, respectively. In this example, the sending user 110 transfers funds from its originating wallet 235 to the receiving user. The user 210 transmits $50 to a receiving wallet 240 associated with a receiving computing device 205 owned by the user 210. The transaction may be written to each respective user's local ledger 125, 225. Once the transaction is completed locally, the originating and receiving wallets associated with the users may report the transaction to a remote ledger service 120, which may be a general-purpose ledger that can record these transactions or use DLT.

[0019] Figure 3 shows the example transaction from Figure 2, after which each user's wallet, originator wallet 235, and recipient wallet 240, independently confirms the transaction with 2f+1 ledger nodes 155 on the remote ledger service 120. Each ledger node verifies the accuracy and authenticity of the transaction for each wallet to maintain the fault tolerance of the distributed ledger.

[0020] 4-12 illustrate exemplary representations and environments in which local devices utilize tamper-resistant hardware to enable secure and trusted transactions between devices. The tamper-resistant hardware is utilized to prevent malicious actors from infiltrating and / or compromising digital currency transactions, such as when one or both of the sending and receiving devices are offline and unable to reach the remote ledger service 120.

[0021] 4 illustrates an exemplary environment in which a sending device 105 is configured with tamper-resistant hardware 405 to facilitate secure and trusted transactions. The sending device may be configured similarly to the secure tamper-resistant smart cards discussed in U.S. Patent Application No. 16 / 352,657, entitled “Secure Tamper Resistant Smart Card,” filed March 13, 2019, including, but not limited to, paragraphs

[0041] ,

[0064] ,

[0065] ,

[0091] , and

[0177] , among other portions of the specification and drawings, the entire contents of which are incorporated herein by reference. For example, the tamper-resistant hardware may include integrating sensitive functionality into a single system-on-chip (SoC) or having unclonable signatures as keys.

[0022] Tamper-resistant hardware may be considered a Trusted Platform Module (TPM) designed to provide hardware-based security-related functions. A TPM chip is a secure cryptoprocessor designed to perform cryptographic operations. A TPM chip may be configured to, among other security features, make a private key unavailable outside the TPM, require an authentication value to use the private key, and prevent access after too many incorrect guesses of the authentication value. Discussion of tamper-resistant hardware herein may include any one or more of these security features and may be hardware-based or software-based and hardware-based. In some implementations, pure software functionality may be utilized as a tamper-resistant component. Any discussion of a sending computing device, a receiving computing device, or any device configured with tamper-resistant hardware may consider any type of computing device, such as the smart-resistant smart card of U.S. Patent Application No. 16 / 352,657, a laptop computer, a smartphone computer, a tablet computer, a kiosk, a point-of-sale (POS) device, a desktop computer, or wearable technology (e.g., a smartwatch, a head-mounted display (HMD) device).

[0023] In a typical implementation, the sending computing device 105 and the receiving computing device 205 can safely and securely identify each other before attempting a transaction. In this way, man-in-the-middle (MITM) or other attacks are prevented. An attack cannot be performed on one or both devices. In one implementation, tamper-resistant hardware may generate messages and signatures using an internal private key that is inaccessible to the rest of the computing device. Once a message is generated and signed, the network interface of the sending or receiving computing device may transmit the message via Bluetooth, Near Field Communication (NFC), Wi-Fi, cellular networks, etc., since these are secure from tampering. A digitally signed transaction can reliably transfer funds from one account to another with high resistance to tampering. However, it may be beneficial to verify and establish a trusted connection between devices before the transaction.

[0024] As representatively shown by reference numeral 425, many methods can be used to establish a secure connection between two locally present devices. If one device has a camera and the other has a display, the second device (e.g., the receiving device 205) can display a randomly generated QR code to the first device (the sending device 105) and then communicate only with devices that know the contents of the QR code. The reverse scenario can occur if the sending device displays a QR code and the receiving device scans the code. If neither device has a camera, or if a camera is otherwise not a desirable option, but both have a display or other output device (e.g., the display of a peripheral device such as a smartwatch), the devices can be confident that they are communicating with each other by displaying and comparing a common code generated by a secure cryptographic method. For example, a secure connection can be established by exchanging public keys using Diffie-Hellman key exchange, and then a short hash of the two public keys can be displayed on each device to verify that each device is using the same key pair. Once the endpoints are securely identified, subsequent communications can be protected by authenticated encryption methods that provide both message confidentiality and integrity. Alternatively, one device may generate a code that the other user operating the other device can enter into the device's input mechanism to establish a trusted connection. Essentially, some initial authentication is performed between the devices to securely identify each other, and then tamper-resistant hardware can be utilized for the transaction.

[0025] As shown in Figure 4, tamper-resistant hardware is configured with various security features 410. Figure 5 shows an exemplary, non-exhaustive schema of security features 410 that may be associated with tamper-resistant hardware 405. Security features may include immutable data and instruction sets 505, authorization for access (e.g., passcode, biometric scan, PIN code, etc.) 510, preventing access after "n" unsuccessful attempts (e.g., 3, 4, etc.) 515, secure private keys, inaccessibility outside the tamper-resistant hardware 520, predetermined usage rules 525, and other security features 530.

[0026] The sending device 105 and the receiving device 205 are each configured with a locally running encryption application 420. The encryption application may be a standalone application installed on the device, or alternatively, may be a plug-in installed in another application. In Figure 4, users are attempting to execute a transaction between them, as representatively indicated by reference numeral 415. For example, the sending user 105 may be attempting to send digital currency to the receiving user 210 in exchange for goods or services. The receiving user may be a brick-and-mortar store selling goods such as groceries, personal care products, etc., or may be a window display. It may be a service provider such as a mopping service, auto repair service, etc. The specific provision of goods or services is not relevant to the overall running of the system; rather, the relevance is that the sending user intends to pay the receiving user for some goods or services.

[0027] 6-9 illustrate some ordered steps of an exemplary transaction in a high-level context, but not all steps may be included. Further clarifications and steps may be included in the transaction, as shown in FIGS. 10-12, depending on the specific circumstances of the transaction.

[0028] FIG. 6 shows an exemplary representation in which both the sending device 105 and the receiving device 205 have a network failure and are unable to communicate with the remote ledger service 120. The receiving device's cryptographic application 420 can identify that the sending device is configured with tamper-resistant hardware 405, as representatively indicated by reference numeral 610. This detection may occur, for example, when the sending device's tamper-resistant hardware transmits a spend authorization 605, which is a message signed by a mutually trusted bank. The bank may be any banking institution or company that holds digital currency for users. In this regard, the bank has a strong incentive to regulate its user base and vet to prevent and eliminate any fraudulent activity. The bank makes the determination that the tamper-resistant hardware is satisfactory when it validates the user's account. The bank may also stop issuing spend authorizations to tamper-resistant devices if the account exhibits fraudulent or otherwise anomalous behavior. The discussion of spend authorizations is discussed in more detail below.

[0029] The bank's determination is based on a certificate signed by the device manufacturer that created the tamper-resistant hardware, which the device presents to the bank during account activation so that the tamper-resistant hardware is authorized before any transactions are attempted.

[0030] FIG. 7 shows an exemplary representation of a sending device transmitting a revocable payment transaction (RPT) 705 to a receiving device 205 after tamper-resistant hardware is detected (FIG. 6). In this scenario, the sending device 105 and receiving device 205 do not have an active network connection to the remote ledger service 120 but can still perform trusted transactions using the tamper-resistant hardware 405. The tamper-resistant hardware transmits the RPT to the receiving device. The RPT may include, for example, a promise by the sender 110 or sending device 105 to pay a given amount (e.g., $50 in digital currency) that can be revoked within the revocability period, which is some predetermined time interval. Depending on the situation and system configuration, the revocability period can be minutes, hours, or days. In a typical implementation, the revocability period may be five days to allow for synchronization with the remote ledger service.

[0031] In response to receiving the RPT, the receiving device 205 transmits a confirmation 710 to the sending device 105. Upon receiving the confirmation message, the sending device considers the transaction final and irrevocable, but still requires execution on the ledger.

[0032] 8 illustrates an exemplary environment in which, in response to receiving a confirmation, the sending device transmits a non-reversible payment transaction (non-RPT) 805 to the receiving device 205. The non-RPT describes the same payment amount to the receiving device and indicates to the receiving device that the sending device can no longer reverse the transaction. Concurrent with, before, or after transmitting the non-RPT, the sending device displays a "Settled" 820 message on its computing device's display 815. The displayed message may be a word, symbol, graphic, artwork, icon, or alternatively, a sound that is triggered to indicate a positive outcome.

[0033] Once the sending device 105 and receiving device 205 regain their network connectivity, one or both of the devices can report the non-RPT to the remote ledger service 120, as representatively shown by reference numeral 810. Alternatively, if the non-RPT fails to reach the receiving device, the RPT can be reported to the remote ledger service. This ensures that funds are transferred even if the sending device is lost or otherwise fails to report the non-RPT in a timely manner.

[0034] In a typical implementation, a transaction can be canceled by the sending device 105 at any time until the non-RPT is transmitted or until the sending device receives confirmation. Once confirmation is received, the sending device may consider the transaction complete and perform such actions. After the receiving device transmits confirmation to the sending device, a prompt may appear on the receiving device instructing the receiving user to check the sending user's display for any "settled" or "cancelled" messages. This may occur if the non-RPT is not received at the receiving device, and therefore the receiving device does not know whether the transaction was executed. Reviewing the display of a device with tamper-resistant hardware can be a safe and secure mechanism for a non-tamper-resistant device user to verify an executed transaction.

[0035] 9 illustrates an exemplary environment in which confirmation is not received by the sending device, as representatively indicated by reference numeral 905. In response, the sending device displays "CANCELED" 910 on its user display 815. The "CANCELED" message indicates to both parties that the transaction was not executed, and once the network becomes available again, a settlement transaction reversal 910 is reported as such to the remote ledger service 120. The settlement transaction reversal is generated in response to the canceled transaction and is stored until the network becomes available.

[0036] 10-11 illustrate example flow diagrams of separate payment protocols that utilize duplication techniques and specific configurations and transmission protocols to protect transaction viability and authenticity. Each embodiment utilizes tamper-resistant hardware associated with at least one of the computing devices to facilitate transaction viability. While only one device is shown with tamper-resistant hardware, in other implementations, each device may be configured with tamper-resistant hardware. Furthermore, the tamper-resistant hardware is the component that generates the various communications for a given device, such as the sending computing device in FIGS. 10 and 11 and the receiving computing device in FIG. 12.

[0037] Tamper-resistant hardware may generate messages and signatures using internal private keys that are inaccessible to the rest of the computing device. Once a message is generated and signed, the network interface of the sending or receiving computing device may transmit the message over Bluetooth, Near Field Communication (NFC), Wi-Fi, cellular networks, etc., since these are safe from tampering. Digitally signed transactions can reliably transfer funds from one account to another while at the same time being highly resistant to tampering. However, this only works if the sender and recipient accounts specified in the transaction are correctly identified. Accounts read from a network connection can only be trusted if the other end of the network connection is securely associated with the correct device.

[0038] Establishing a secure connection between two locally present devices can be done in many ways. If one device has a camera and the other has a display, the second device can display a randomly generated QR code to the first device and then communicate only with devices that know the contents of the QR code. If neither device has a camera but both have displays, they can be sure they are communicating with each other by displaying and comparing a common code generated by a secure encryption method. Once the endpoints are securely identified, subsequent communications are protected by authenticated encryption methods that provide both message confidentiality and integrity. Essentially, some initial authentication can be performed between devices so that they can securely identify each other.

[0039] FIG. 10 shows an example flow diagram of an off-network payment protocol 1002, providing additional details and steps for the transaction described in FIGS. 6-9. The right-hand column, Transaction Status 1045, indicates the transaction status from the perspective of connection failure handling, meaning whether the transaction is cancellable 1050 if a failure occurs at that stage of the process, whether the sender and receiver are in an intermediate state where the receiver needs to confirm on the sender's display 1055'', or whether the payment was successful 1060.

[0040] In step 1005, the receiving device 205 requests a spend authorization from the sending device 105. The request may include identifying the payment provider and also specifies offline mode, since there is currently no available network connection to the ledger. Selecting offline mode means that all communication is local to the two devices and generally completes quickly or not at all. Therefore, a shorter timeout parameter is used than in online mode, which adds time to the completion of the transaction on the remote ledger. In step 1010, the tamper-resistant hardware of the sending device sends a spend authorization since its last ledger synchronization. The spend authorization includes an indication that the sending device is configured with tamper-resistant hardware that has been previously approved by a mutually trusted bank or financial institution that hosts the user account. The spend authorization provides sufficient security for the receiving device, since the bank can revoke the spend authorization if it detects fraudulent or anomalous behavior, such as an attempt to intentionally overdraw the account or tampering with the device's hardware.

[0041] The receiving device may evaluate the payment provider's signature on the spend authorization, the expiration date of the spend authorization, and the amount limit. If the payment provider's signature matches any payment provider public key stored on the receiving device, the spend authorization has not expired, and the amount limit is not less than the desired payment for the instant transaction, the receiving device may transmit a request for payment to the sending device.

[0042] In step 1015, the receiving device 205 transmits a request payment message to the sending device in response to receiving and evaluating the spend authorization. The request payment message includes the payment amount of the transaction and an incremented payee sequence number. When returned in a payment transaction, the payee sequence number allows the payee to identify the payment as newly generated rather than a replay of a previous payment.

[0043] In step 1020, the tamper-resistant hardware 405 of the sending computing device transmits the reversible payment transaction (RPT) to the receiving device, The RPT is then stored in persistent storage. Persistent storage, as used herein, may refer to non-volatile storage such as flash storage, hard disk, optical media, or other devices that retain data even after the device is turned off. The RPT contains the amount from the requested payment and a reversal period during which the sender can reverse the transaction. The reversal period begins when the receiving device submits the transaction to the remote ledger service 120. The recipient's sequence number prevents replay of previous payments.

[0044] In step 1025, the receiving device 205 evaluates the RPT, which includes verifying the sending device's signature, the consistency of the RPT with the spend authorization, and the consistency of the RPT with the payment request. If accepted, the receiving device saves the RPT in persistent storage.

[0045] In step 1030, the receiving device transmits a confirmation to the sending device. At this stage, the sending device can cancel the transaction if confirmation is not received. The transaction is cancelable until the tamper-resistant hardware 405 of the sending computing device receives confirmation and proceeds to the next step. If confirmation is not received within a predetermined time interval, the sending device submits a cancel settlement transaction to the remote service ledger once network connectivity becomes available.

[0046] In step 1035, the tamper-resistant hardware 405 of the sending computing device transmits the non-reversible payment transaction (non-RPT) to the receiving device and displays "Settled" on its user interface (UI) for the recipient's confirmation. Receipt of the non-RPT indicates to the receiving device that the transaction was executed locally. The recipient can confirm that the transaction was executed on the sending device by reviewing the "Settled" screen, regardless of whether the non-RPT was received due to a local network connection failure via Bluetooth, near field communication (NFC), Wi-Fi, etc. As shown in column Transaction Status 1045, the recipient can check the status of the offer by looking at the sender's display.

[0047] The receiving device evaluates the non-RPT upon receipt. The receiving device verifies the consistency of the non-RPT with the RPT, which is the signature of the sending device, saves the non-RPT in persistent storage, and discards the RPT. In step 1040, once the network becomes available, one or both of the sending device 105 and the receiving device 205 can report the non-RPT and the executed transaction to the remote ledger. The settlement is now successful and no longer cancellable, as representatively shown by numeral 1060. If the receiving device does not receive the non-RPT, the receiving device will submit the RPT the next time the remote ledger becomes available. Submitting the RPT ensures that the funds are transferred unless the sending device submits a reversal settlement transaction before the reversal period expires. Once the funds are transferred by the RPT, the ledger places the funds on hold and makes them unavailable for spending until the reversal period expires.

[0048] 11 shows an example flow diagram of a half-off network settlement protocol 1102 transaction between a sending device 105 and a receiving device 205. In this scenario, the receiving device has an operational network connection with a remote ledger service 120, and the sending device does not.

[0049] In step 1105, the receiving device 205 sends a spend authorization request to the sending device, including a request to identify the payment provider and an indication that the receiving device has a live connection and therefore the transaction will be in "online mode." Note the contrast from the off-network payment protocol 1002 of FIG. 10, where the receiving device indicates offline mode.

[0050] In step 1110, the tamper-resistant hardware 405 of the sending computing device transmits a request for a new spend authorization to the remote ledger service 120 in response to the request received from the receiving device. The spend authorization request is encrypted and passed from the receiving device to the remote ledger service 120. Specifically, the pass-through communication may be transmitted using any local connection to the receiving device, which then transmits the spend authorization request to the remote ledger using an established wide area network (WAN) connection. The pass-through spend authorization request allows the tamper-resistant hardware 405 of the sending computing device to receive the current ledger timestamp for that account and to submit any outstanding transactions.

[0051] In step 1115, the remote ledger service 120 transmits the new spend authorization as a pass-through communication to the tamper-resistant hardware 405 of the sending computing device 105. The remote ledger service executes the outstanding transaction and, provided the account remains in good standing, transmits an encrypted spend authorization detailing the sender's current ledger timestamp, expiration date, and spend limit. The spend authorization can be decrypted using the tamper-resistant hardware 405 of the sending device 105. The sending device stores the spend authorization in persistent storage for future transactions, which may be conducted offline.

[0052] In step 11120, the tamper-resistant hardware 405 of the sending computing device 105 transmits the spend authorization to the receiving device. The spend authorization includes a spend limit, an expiration date for the spend authorization, and a signature of the payment provider that verifies the tamper-resistant hardware of the sending device. In step 1125, the receiving device evaluates the spend authorization by reviewing the information therein. Upon verification, in step 1130, the receiving device transmits a payment request to the sending device. The payment request includes the transaction amount and an incremented payee sequence number that identifies the specific transaction on the receiving device.

[0053] In step 1135, the tamper-resistant hardware 405 of the sending computing device transmits the RPT to the receiving device and stores it in persistent storage. The RPT includes the amount from the requested payment and a reversible period during which the sender can reverse the transaction. In this scenario, the reversible period may last for a few seconds or minutes, depending on the implementation. Because there is a live connection to the remote ledger, the reversible period may last for one minute before receiving confirmation from the receiving device. The reversible period begins when the receiving device submits the transaction to the remote ledger service 120. The recipient's sequence number prevents replay of previous payments.

[0054] In step 1140, the receiving device transmits the RPT to the remote ledger service 120. In step 1145, the remote ledger service executes the transaction by moving funds from the sender's account to the receiver's account. The remote ledger service waits for consensus with other nodes to validate the transaction. In step 1150, the receiving device may confirm execution of the transaction with the remote ledger service. This confirmation step may occur, for example, if it is still waiting for confirmation from the remote ledger. In step 1155, the remote ledger service confirms execution of the transaction with the receiving device.

[0055] In step 1160, the receiving device sends a confirmation of receipt of the payment to the sending computer. In step 1165, the tamper-resistant hardware 405 of the sending computing device transmits the non-RPT to the receiving device and displays "paid" or similar connotation on its UI for the recipient's confirmation.

[0056] As shown in the Transaction Status 1180 column, the transaction was cancelable at any time until the sending device received the confirmation, transmitted the non-RPT, and displayed the "Settled" representation. In this regard, the transaction may be cancelable at any time before the sending device processes the receiving device's confirmation. The receiving device can confirm the execution of the transaction by reviewing the sender's display 1190 or by receiving the non-RPT after the confirmation is transmitted.

[0057] Upon receiving the non-RPT, the transaction status is considered "Settlement Successful" 1195. In step 1170, the receiving device submits the non-RPT to the remote ledger service 120. In step 1175, the remote ledger service executes the transaction against the receiving device's account.

[0058] Figure 12 shows an example flow diagram for a scenario in which, instead of the sending device as in Figures 10 and 11, the receiving device possesses tamper-resistant hardware 1202. As with the other scenarios, the device with the tamper-resistant hardware is considered trusted and therefore has the power to revoke transactions, which it can exercise until the transaction can be carried out.

[0059] In step 1205, the sending device 105 sends a payment request to the receiving device 105. The payment request may include the transaction amount. In step 1210, the receiving device transmits the payment request to the sending device. The payment request includes a spend authorization from a previous ledger synchronization to prove that the receiving device's tamper-resistant hardware is trusted to correctly use the granted revocation authority. The payment request may also include a payee sequence number so that the payee can easily identify this as a new payment.

[0060] In step 1215, the sending device 105 verifies the spend authorization to verify the receiving device's tamper-resistant hardware. In step 1220, the sending device sends a request for the current ledger time from the remote ledger service 120. In step 1225, the remote ledger service sends the current ledger time to the sending device. In step 1230, the sending device transmits a reversible payment transaction (Rev-PT) to the receiving device. The Rev-PT is distinct from the RPT in that the receiver has the authority to revoke the former, while the sender has the authority to revoke the latter. The Rev-PT includes the receiver sequence number from the payment request in step 1210 and a validity period, such as 20 seconds. The receiving device verifies the recipient's sequence number and saves the Rev-PT in persistent storage. In step 1235, the receiving device's tamper-resistant hardware transmits the Rev-PT to the remote ledger service as a pass-through communication.

[0061] In step 1240, the remote ledger service executes the transaction in response to receiving a pass via the Rev-PT from the receiving device 205. The receiving device waits the period of time (e.g., 20 seconds) identified in the Rev-PT from the sending device. The ledger may record a reverse check that records the amount, date, and sender of the transfer, allowing the receiving device to refund the money if it fails to receive confirmation that the transfer is complete. The receiving device's tamper-resistant hardware then sends the pass from the remote ledger. If no error is received immediately, the tamper-proof hardware waits a period of time until the ledger completes the transaction, then transmits an execution confirmation query as a pass-through to the remote ledger service in step 1245. In step 1250, the remote ledger service confirms the execution of the transaction as a pass-through communication to the tamper-proof hardware of the receiving device. Upon receiving the pass-through confirmation from the remote ledger, the tamper-proof hardware of the receiving device considers the transaction executed and can no longer be canceled. The receiving device completes the transaction and creates a delete-check transaction to delete the reverse check recorded in the ledger. If confirmation from the remote ledger does not arrive within a predetermined timeout, the receiver creates a refund transaction to execute the check on the remote ledger and return the funds to the sender. If the funds were never transferred in the first place, the check would not exist on the ledger and no refund would occur.

[0062] In step 1255, the receiving device's tamper-resistant hardware transmits a delete check transaction as confirmation of receipt of the payment and displays "Received" on its UI. From the sending device's prior, direct, and intentional transmission in step 1230 to receipt of confirmation and / or publication of "Received" on the receiving device's UI, the sender is in an intermediate state and relies on the receiving device's display for confirmation. The receiving device's display may provide status updates for each pass-through communication while the transaction is pending, alerting both parties to keep them informed of the situation.

[0063] In step 1260, the sending device 105 forwards a delete check transaction to the remote ledger service 120. In step 1265, the remote ledger service executes the delete check transaction and reports it to the sending device. In step 1270, the sending device displays that the settlement has been confirmed, which can be verified by the recipient by viewing the sender's display. Alternatively, if ledger confirmation does not arrive, the receiving device forwards a refund transaction, which the sender can execute to regain access to the funds.

[0064] Referring to the Transaction Status 1280 column, handling of connection failures varies depending on which parties are communicating. For example, as representatively shown by reference numeral 1275, the transaction may be canceled by the receiving device 205, the sending device 105, or the remote ledger service 120 until the sender sends the Rev-PT in step 1230. The transaction may be canceled by the receiving device, or the sender should confirm the execution of the transaction on the receiver's display until the receiving device receives confirmation from the remote ledger service in step 1250, as representatively shown by reference numeral 1290. Once the remote ledger service receives a delete check transaction in step 1260, as representatively shown by reference numeral 1295, the settlement is considered successful for all parties. The difference between field 1285 and field 1290 is due to the different parties involved at each point in the transaction.

[0065] In Figures 10-12, a transaction can be canceled at any time, as indicated in the status column on the right side of the flow diagram. Cancellation may occur, for example, if communication is lost at any time during the cancellation window. For example, in Figure 10, at communications 1005, 1010, 1015, 1020, and 1025, if any of these communications are lost or not responded to, both the sending and receiving devices may consider the transaction canceled. The period in which one party submits a confirmation, such as step 1030 in Figure 10, step 1160 in Figure 11, and step 1230 in Figure 12, is when that one party is in an intermediate state and is at least a non-RPT (Figures 10 and 11) or a deletion check (FIG. 12) is received, in which case the transaction can be checked on the tamper-resistant hardware display to confirm the transaction. Throughout this intermediate state, status updates may be displayed on the tamper-resistant device's user interface to keep both parties approving the progress of the transaction. The updates may include, for example, the specific communication most currently received or communicated, as shown in or discussed herein with reference to the drawings.

[0066] 13 and 14 illustrate an exemplary process performed by a sending computing device, a receiving computing device, a remote ledger service, or a combination thereof. While the steps are shown in sequential order, the functions and operations therein may be alternatively arranged and / or certain steps may be added or removed. This process is merely illustrative to illustrate one particular implementation for understanding features of the present disclosure.

[0067] 13, the sending computing device sends a revocable payment transaction (RPT) to the receiving computing device, the RPT including an amount and a revocability period. In step 1310, the sending computing device sends a non-revocable payment transaction (non-RPT) to the receiving computing device in response to receiving a confirmation message that the RPT has been received and verified at the receiving computing device. Alternatively, in step 1315, the sending computing device generates a revocable payment transaction in response to the sending computing device failing to receive a confirmation message from the receiving computing device. In this regard, the sending computing device generates either a non-RPT or a revocable payment transaction depending on receipt of the confirmation message.

[0068] 14, in step 1405, the sending computing device establishes that an off-network protocol will be used for the transaction. In step 1410, the sending computing device sends the RPT to the receiving computing device. In step 1415, the sending computing device receives a confirmation message that the RPT was received and verified at the receiving computing device. In step 1420, the sending computing device sends a non-RPT to the receiving computing device in response to receiving the confirmation message.

[0069] FIG. 15 illustrates an exemplary architecture 1500 for a device such as a smartphone, tablet, or laptop computer that can perform various functions described herein. The architecture 1500 illustrated in FIG. 15 includes one or more processors 1502 (e.g., a central processing unit, a dedicated AI chip, a graphics processing unit, etc.), a system memory 1504 including RAM (random access memory) 1506, ROM (read-only memory) 1508, and a long-term storage device 1512. A system bus 1510 operatively and functionally couples the components in the architecture 1500. A basic input / output system containing basic routines that help move information between elements in the architecture 1500, such as during startup, is typically stored in the ROM 1508. The architecture 1500 further includes a long-term storage device 1512 for storing software code or other computer-executable code utilized to implement applications, a file system, and an operating system. The storage device 1512 is connected to the processor 1502 via a storage controller (not shown) connected to the bus 1510. Storage device 1512 and its associated computer-readable storage media provide non-volatile storage for architecture 1500. The descriptions of computer-readable storage media contained herein may include hard disks or CD-ROMs. Although reference is made to long-term storage devices such as M drives, it will be understood by those skilled in the art that the computer-readable storage medium can be any available storage medium accessible by architecture 1500, including solid state drives and flash memory.

[0070] By way of example, and not limitation, computer-readable storage media may include volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information, such as computer-readable instructions, data structures, program modules, or other data. For example, computer-readable media include, but are not limited to, RAM, ROM, EPROM (erasable programmable read-only memory), EEPROM (electrically erasable programmable read-only memory), flash memory or other solid-state memory technology, CD-ROM, DVD, HD-DVD (high-definition DVD), Blu-ray, or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage, or other magnetic storage devices, or any other medium that can be used to store the desired information and that can be accessed by architecture 1500.

[0071] According to various embodiments, architecture 1500 may operate in a networked environment using logical connections to remote computers over a network. Architecture 1500 may connect to the network via a network interface unit 1516 connected to bus 1510. It will be appreciated that network interface unit 1516 may also be utilized to connect to other types of networks and remote computer systems. Architecture 1500 may also include an input / output controller 1518 for receiving and processing input from a number of other devices (not shown in FIG. 15 ), including control devices such as a keyboard, a mouse, a touchpad, a touchscreen, buttons and switches, or an electronic stylus. Similarly, input / output controller 1518 may provide output to a display screen, a user interface, a printer, or other type of output device (also not shown in FIG. 15 ).

[0072] It can be understood that any software components described herein, when loaded and executed on the processor 1502, may transform the processor 1502 and the entire architecture 1500 from a general-purpose computing system to a special-purpose computing system customized to facilitate the functions presented herein. The processor 1502 may be constructed from any number of transistors or other discrete circuit elements that, individually or collectively, can assume any number of states. More specifically, the processor 1502 may operate as a finite state machine in response to executable instructions contained within the software modules disclosed herein. These computer-executable instructions may transform the processor 1502 by specifying how the processor 1502 transitions between states, thereby modifying the transistors or other discrete hardware elements that make up the processor 1502.

[0073] Encoding the software modules presented herein may also modify the physical structure of the computer-readable storage medium presented herein. The particular modification of the physical structure may depend on various factors in various implementations of this description. Examples of such factors may include, but are not limited to, the technology used to implement the computer-readable storage medium, whether the computer-readable storage medium is characterized as primary or secondary storage, etc. For example, if the computer-readable storage medium is implemented as semiconductor-based memory, the software disclosed herein may be encoded on the computer-readable storage medium by modifying the physical state of the semiconductor memory. For example, the software may modify the transistors, capacitors, or other individual elements that make up the semiconductor memory. The software may transform the state of circuit elements. The software may also transform the physical state of such components in order to store data thereon.

[0074] As another example, the computer-readable storage media disclosed herein may be implemented using magnetic or optical technology. In such implementations, the software presented herein may transform the physical state of the magnetic or optical media when the software is encoded therein. These transformations may include changing the magnetic properties of specific locations within a given magnetic media. These transformations may also include changing the physical features or characteristics of specific locations within a given optical media to change the optical properties of those locations. The foregoing examples are provided solely to facilitate this discussion; other transformations of physical media are possible without departing from the scope and spirit of this description.

[0075] In light of the above, it can be understood that many types of physical variations can be made within architecture 1500 to store and execute the software components presented herein. It can also be understood that architecture 1500 can include other types of computing devices, including wearable devices, handheld computers, embedded computer systems, smartphones, PDAs, and other types of computing devices known to those skilled in the art. It is also contemplated that architecture 1500 may not include all of the components shown in FIG. 15, may include other components not explicitly shown in FIG. 15, or may utilize an entirely different architecture than that shown in FIG. 15.

[0076] A computing device may be further configured with tamper-resistant hardware 1522 to perform various functions and operations discussed herein, such as various transmissions performed by a sending or receiving computing device. Tamper-resistant hardware may be considered a device configured to make a private key unavailable outside of its enclosure, require an authentication value to use the private key, be immutable, and prevent access after too many incorrect authentication value guesses, among other security features. While hardware functions are discussed herein, tamper resistance may be configured as a hybrid of hardware and software, pure hardware, or pure software. The tamper-resistant device may provide indications of attempted tampering or may react when some physical intrusion is attempted. The tamper-resistant hardware may be a Trusted Platform Module (TPM) or may be implemented as a Trusted Execution Environment (TEE) created as part of a published processor.

[0077] 16 is a simplified block diagram of an exemplary computer system 1600, such as a remote server, smartphone, tablet computer, laptop computer, or personal computer (PC), in which the present disclosure may be implemented. The computer system 1600 includes a processor 1605, a system memory 1611, and a system bus 1614 that couples various system components including the system memory 1611 to the processor 1605. The system bus 1614 may be any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, or a local bus using any of a variety of bus architectures. The system memory 1611 includes a read-only memory (ROM) 1617 and a random access memory (RAM) 1621. A basic input / output system (BIOS) 1625, containing the basic routines that help to transfer information between elements within the computer system 1600, such as during start-up, is stored in the ROM 1617. The computer system 1600 further includes a hard disk drive 1628 for reading from and writing to an internally located hard disk, a removable magnetic disk (e.g., a floppy disk), and a The computer system 1600 may also include a magnetic disk drive 1630 for writing data to and from a removable optical disk 1643, such as a CD (compact disc), DVD (digital versatile disc), or other optical media. The hard disk drive 1628, the magnetic disk drive 1630, and the optical disk drive 1638 are connected to the system bus 1614 by a hard disk drive interface 1646, a magnetic disk drive interface 1649, and an optical drive interface 1652, respectively. The drives and their associated computer-readable storage media provide non-volatile storage of computer-readable instructions, data structures, program modules, and other data for the computer system 1600. Examples include a hard disk, a removable magnetic disk 1633, and a removable optical disk 1643, although other types of computer-readable storage media capable of storing data accessible by a computer, such as a magnetic cassette, a flash memory card, a digital video disk, a data cartridge, random access memory (RAM), read-only memory (ROM), etc., may also be used in some applications of the present disclosure. Additionally, as used herein, the term computer-readable storage medium includes one or more instances of a medium type (e.g., one or more magnetic disks, one or more CDs, etc.). For purposes of this specification and claims, the phrase "computer-readable storage medium" and variations thereof are intended to encompass non-transitory embodiments and do not include waveforms, signals, and / or other transitory and / or intangible communication media.

[0078] A number of program modules, including an operating system 1655, one or more application programs 1657, other program modules 1660, and program data 1663, may be stored on the hard disk, magnetic disk, or optical disk 1643, ROM 1617, or RAM 1621. A user may enter commands and information into the computer system 1600 through input devices such as a keyboard 1666, a pointing device (e.g., a mouse) 1668, or a touch-screen display 1673. Other input devices may include a microphone, joystick, game pad, satellite dish, scanner, trackball, touch pad, touch-sensitive device, voice command module or device, user motion or user gesture capture device, or the like. These and other input devices are often connected to the processor 1605 through a serial port interface 1671 coupled to the system bus 1614, but may also be connected by other interfaces, such as a parallel port, game port, or universal serial bus (USB). A monitor 1673 or other type of display device is also connected to the system bus 1614 via an interface, such as a video adapter 1675. In addition to the monitor 1673, personal computers typically include other peripheral output devices (not shown), such as speakers and printers. The example shown in Figure 16 also includes a host adapter 1678, a small computer system interface (SCSI) bus 1683, and an external storage device 1676 connected to the SCSI bus 1683.

[0079] Computer system 1600 can operate in a networked environment using logical connections to one or more remote computers, such as a remote computer 1688. The remote computer 1688 may be selected as another personal computer, a server, a router, a network PC, a peer device, or other common network node, and typically includes many or all of the elements described above with respect to computer system 1600, although only one representative remote memory / storage device 1690 is shown in FIG. 16. The logical connections depicted in FIG. 16 include a local area network (LAN) 1693 and a wide area network (WAN) 1695. Such networked environments are often deployed in, for example, offices, enterprise-wide computer networks, intranets, and the Internet.

[0080] When used in a LAN networking environment, the computer system 1600 is connected to the local area network 1693 via a network interface or adapter 1696. When used in a WAN networking environment, the computer system 1600 typically includes a broadband modem 1698, a network gateway, or other means for establishing communications over a wide area network 1695, such as the Internet. The broadband modem 1698, which may be internal or external, is connected to the system bus 1614 via a serial port interface 1671. In a networked environment, program modules associated with the computer system 1600, or portions thereof, may be stored in the remote memory storage device 1690. It is noted that the network connections shown in FIG. 16 are exemplary and other means of establishing a communications link between computers may be used depending on the particular requirements of the application of the present disclosure.

[0081] Various exemplary embodiments are disclosed herein. In one exemplary embodiment, a sending computing device configured for sending and receiving digital currency payments includes a network interface for communicating with a receiving computing device, tamper-resistant hardware that protects one or more private keys that are inaccessible outside the tamper-resistant hardware, one or more processors, and one or more hardware-based memory devices having instructions that, when executed by the one or more processors, cause the sending computing device to send a revocable payment transaction (RPT) to the receiving computing device, the RPT containing an amount and a period during which the sending device may perform the transaction. and one or more hardware-based memory devices that cause the receiving computing device to perform one of the following actions: in response to receiving a confirmation message that the RPT has been received and verified at the receiving computing device, send a non-revocable payment transaction (non-RPT) indicating that the settlement was successful and the revocable period from the RPT has been removed, or in response to the sending device failing to receive a confirmation message from the receiving computing device, generate a revocation payment transaction.

[0082] In another embodiment, the one or more processors are further configured to publish, on a user interface of the sending device, a confirmation message indicating the successful settlement in response to receiving a confirmation message from the receiving computing device. In another embodiment, the one or more processors are further configured to receive instructions that the transaction is to be performed under an off-network protocol. In another embodiment, instructions that the transaction is to be performed under an off-network protocol are received before transmitting the RPT. In another embodiment, the one or more processors are further configured to transmit the non-RPT to a remote ledger service once network access is available. In another embodiment, the sending and receiving computing devices are configured to consider the transaction canceled if any communication is lost before the sending computing device receives the confirmation message. In another embodiment, the one or more processors are further configured to publish a message on a user interface of the sending device indicating that the transaction is canceled in response to the sending device failing to receive a confirmation message from the receiving computing device within a predetermined time interval. In another embodiment, the one or more processors are further configured to transmit a spend authorization to the receiving computing device, where the spend authorization indicates that the sending account is protected by a tamper-proof hardware. In another embodiment, the one or more processors are further configured to transmit the reversal settlement transaction once a network connection is available. In another embodiment, the one or more processors are further configured to request a new spend authorization from the remote ledger service as a pass-through communication with the receiving computing device. In another embodiment, the one or more processors are further configured to send the new spend authorization to the receiving computing device.

[0083] Another exemplary embodiment discloses a method, at least partially executed by tamper-resistant hardware in a sending computing device, for executing a transaction, the method including: establishing that an off-network protocol is to be used for the transaction; sending a revocable payment transaction (RPT) to a receiving computing device, the RPT including an amount and a revocability period during which the sending device is authorized to cancel the transaction; receiving a confirmation message at the receiving computing device that the RPT has been received and verified; and, in response to receiving the confirmation message, sending a non-revocable payment transaction (non-RPT) to the receiving device indicating that the payment was successful and that the revocability period from the RPT has been removed.

[0084] In another embodiment, the method further includes publishing a successful settlement confirmation message on a user interface of the sending device in response to receiving the confirmation message from the receiving computing device. In another embodiment, an off-network protocol is established in response to receiving the instruction from the receiving computing device. In another embodiment, the method further includes transmitting the non-RPT to a remote ledger service once network access is available. As another example, the sending and receiving computing devices are configured to consider the transaction canceled if any communication is lost before the sending computing device receives the confirmation message.

[0085] Another exemplary embodiment discloses one or more hardware-based memory devices storing computer-executable instructions that, when executed by one or more processors associated with a sending computing device, cause the sending computing device to send a revocable payment transaction (RPT) to a receiving computing device, the RPT including an amount and a revocability period during which the sending device has the authority to cancel the transaction, and perform one of the following actions: in response to receiving a confirmation message at the receiving computing device that the RPT has been received and verified, send to the receiving computing device a non-revocable payment transaction (non-RPT) indicating that the payment was successful and the revocability period from the RPT has been removed, or in response to the sending device failing to receive a confirmation message from the receiving computing device, generate a revocable payment transaction.

[0086] In a further embodiment, the executed instructions further cause the sending computing device to transmit a spend authorization to the receiving computing device, where the spend authorization confirms that the sending computing device is configured with tamper-resistant hardware. As another embodiment, the executed instructions further cause the sending computing device to transmit the non-RPT to a remote ledger service once network access is available. As a further example, the executed instructions further cause the sending computing device to receive instructions that the transaction is performed under an off-network protocol.

[0087] Although the subject matter has been described in language specific to structural features and / or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

Claims

1. A sender computing device (105) configured for sending and receiving digital currency payments, comprising: a network interface (1516) for communicating with the receiving computing device (205); tamper-resistant hardware (405) that protects one or more private keys that are inaccessible outside of said tamper-resistant hardware (405); one or more processors (1502); one or more hardware-based memory devices (1504) having instructions that, when executed by the one or more processors, cause the sending computing device (105) to: sending a revocable payment transaction (RPT) (705) to the receiving computing device (205), the RPT (705) including an amount and a revocability period during which the sending computing device (105) has the authority to cancel the transaction; The following actions: In response to receiving a confirmation message (710) at the receiving computing device (205) that the RPT (705) has been received and verified, sending a non-revocable payment transaction (non-RPT) (805) to the receiving computing device (205) indicating that the payment was successful and that the revocability period from the RPT (705) has been removed; or and generating a cancellation settlement transaction (910) in response to the sending computing device (105) failing to receive the confirmation message (710) from the receiving computing device (205).

2. The one or more processors receive the confirmation message from the receiving computing device.

10. The sending computing device of claim 1, further configured to, in response to receiving a confirmation message, publish a confirmation message on a user interface of the sending computing device that the payment was successful.

3. The sending computing device of claim 1 , wherein the one or more processors are further configured to receive instructions that the transaction is to be performed under an off-network protocol.

4. The sending computing device of claim 3 , wherein the instruction that the transaction is to be performed under an off-network protocol is received prior to transmitting the RPT.

5. The sending computing device of claim 1 , wherein the one or more processors are further configured to transmit the non-RPT to a remote ledger service once network access is available.

6. 2. The sending computing device of claim 1, wherein the sending computing device and the receiving computing device are configured to consider the transaction canceled if any communication is lost before the sending computing device receives the confirmation message.

7. 2. The sending computing device of claim 1, wherein the one or more processors are further configured to, in response to the sending computing device failing to receive the confirmation message from the receiving computing device within a predetermined time interval, publish a message on a user interface of the sending computing device indicating that the transaction has been canceled.

8. 2. The sending computing device of claim 1, wherein the one or more processors are further configured to transmit a spend authorization to the receiving computing device, wherein the spend authorization confirms that a sending account is under the exclusive control of the sending computing device configured with tamper-resistant hardware.

9. The sending computing device of claim 1 , wherein the one or more processors are further configured to transmit the reversal settlement transaction once network access becomes available.

10. The sending computing device of claim 1 , wherein the one or more processors are further configured to request new spend authorization from a remote ledger service as a pass-through communication with the receiving computing device.

11. The sending computing device of claim 10 , wherein the one or more processors are further configured to send the new spend authorization to the receiving computing device.

12. 1. A method, at least in part, implemented by tamper-resistant hardware (405) in a sending computing device (105) for conducting a transaction, comprising: establishing that an off-network protocol is used for the transaction; Reversible Payment Transaction (RPT) (705) sending the RPT (705) to the sending computing device (105), the RPT (705) including an amount and a revocability period during which the sending computing device (105) has the authority to cancel the transaction; receiving a confirmation message (710) at the receiving computing device (205) that the RPT (705) has been received and verified; In response to receiving the confirmation message (710), sending a non-revocable payment transaction (non-RPT) (805) to the receiving computing device (205) indicating that the payment was successful and that the revocability period from the RPT (705) has been removed.

13. 13. The method of claim 12, further comprising publishing, on a user interface of the sending computing device, a confirmation message that the settlement was successful in response to receiving the confirmation message from the receiving computing device.

14. The method of claim 12 , wherein the off-network protocol is established in response to receiving instructions from the receiving computing device.

15. The method of claim 12 , further comprising transmitting the non-RPT to a remote ledger service once network access becomes available.

16. 13. The method of claim 12, wherein the sending computing device and the receiving computing device are configured to consider the transaction canceled if any communication is lost before the sending computing device receives the confirmation message.

17. One or more hardware-based memory devices (1504) storing computer-executable instructions that, when executed by one or more processors (1502) associated with a sending computing device (105), cause the sending computing device (105) to: sending a revocable payment transaction (RPT) (705) to a receiving computing device (205), said RPT (705) including an amount and a revocability period during which said sending computing device (105) has the authority to cancel the transaction; The following actions: In response to receiving a confirmation message (710) at the receiving computing device (205) that the RPT (705) has been received and verified, sending a non-revocable payment transaction (non-RPT) (805) to the receiving computing device (205) indicating that the payment was successful and that the revocability period from the RPT (705) has been removed; or and generating a cancellation settlement transaction (910) in response to the sending computing device (105) being unable to receive the confirmation message (710) from the receiving computing device (205).

18. 20. The one or more hardware-based memory devices of claim 17, wherein the executed instructions further cause the sending computing device to transmit a spend authorization to the receiving computing device, wherein the spend authorization confirms that the sending computing device is configured with tamper-resistant hardware.

19. The executed instructions further include: when network access becomes available, transmitting the sending computer 20. The one or more hardware-based memory devices of claim 17, wherein the one or more hardware-based memory devices cause a computing device to transmit the non-RPT to a remote ledger service.

20. 20. The one or more hardware-based memory devices of claim 17, wherein the executed instructions further cause the sending computing device to receive instructions that the transaction is performed under an off-network protocol.

Images