Patent ID: 12190321

Like reference numerals indicate like elements in the drawings. Elements are not drawn to scale unless otherwise indicated.

DETAILED DESCRIPTION

FIG.1shows an illustrative environment in which multiple and distinct users110have their own digital wallet130and local ledger125instantiated on their respective computing devices105for executing transactions115in the form of transmitting and receiving digital payments. Each computing device may have a digital wallet from and to which digital currency is debited and credited, respectively. In this implementation, each user's computing device may have a common digital wallet application that utilizes a local ledger and the system described herein so that wallets are able to communicate with each other over the same digital transaction platform.

As described in greater detail below, a transaction between two users110is executed on their respective computing devices105. Transaction115is executed on each local ledger, and upon completion, the respective wallets130for the users submit the details of the transactions135to a remote ledger service120for finalization. In some implementations, the remote ledger service may be configured using distributed ledger technology (DLT) or some other generic ledger service capable of recording the peer-to-peer transactions discussed below.

As shown inFIG.1, for example, the remote ledger service120consists of multiple independent ledger nodes155, with 3f+1 such nodes allowing for safe operation in the presence of faulty nodes. Each ledger node has a public key known to the wallets, enabling wallets to verify if a given ledger node created a message. A transaction is finalized when 2f+1 ledger nodes return a positive response. Finalization ensures that the transaction is consistent with all other transactions that have been finalized on the ledger service, i.e., each wallet can only spend funds that it has received and has not already spent. Transaction recipients can be relied upon to diligently pursue finalization, for otherwise, the value will not be credited to their account.

FIG.2shows an exemplary transaction215between two users110,210. User110and device105are the sending user and the sending device, respectively, and user210and device205are the receiving user and the receiving device, respectively. In this example, sending user110transmits $50 from its source wallet235to the receiving wallet240associated with receiving computing device205owned by receiving user210. The transaction may be written to each respective user's local ledger125,225. Once the transaction is completed locally, the source and receiving wallets associated with the users may report the transaction to the remote ledger service120, which may be a generic ledger capable of logging these transactions or using DLT.

FIG.3shows the exemplary transaction fromFIG.2, after which each user's wallet, the source wallet235, and the recipient's wallet240independently confirm the transaction with 2f+1 ledger nodes155on the remote ledger service120. Each ledger node will verify the accuracy and authenticity of the transaction for each wallet to maintain the distributed ledger's fault tolerance.

FIGS.4-12show illustrative representations and environments in which local devices utilize tamper-resistant hardware to enable secure and reliable transactions between the devices. The tamper-resistant hardware is leveraged to prevent a malicious actor from penetrating and/or compromising the digital monetary transaction, such as when one or both of the sending and receiving devices are offline and cannot reach the remote ledger service120.

FIG.4shows an illustrative environment where the sending device105is configured with tamper-resistant hardware405to facilitate secure and reliable transactions. The sending device may be configured similarly as the secure tamper-resistant smart card discussed in U.S. patent application Ser. No. 16/352,657, entitled “Secure Tamper Resistant Smart Card,” filed Mar. 13, 2019, such as at, but not limited to, paragraphs [0041], [0064], [0065], [0091], and [0177], among other portions of its specification and drawings, the entire contents of which is hereby incorporated herein by reference. For example, the tamper-resistant hardware can include integrating sensitive functions on a single System On a Chip (SoC) or having unclonable signatures as keys.

The 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 crypto-processor that is designed to carry out cryptographic operations. The TPM chip may be configured to make a private key unavailable outside of the TPM, require an authorization value in order to use its private key, and prevent access after too many incorrect authorization value guesses, among other security features. Any discussion of tamper-resistant hardware herein may include any one or more of these security features and may be hardware-based or software- and hardware-based. In some implementations, purely software features may be leveraged as the tamper-resistant component. Any discussion of a sending computing device, receiving computing device, or any device configured with tamper-resistant hardware, may be considered any type of computing device, such as the smart resistant smart card in U.S. application Ser. No. 16/352,657, a laptop computer, a smartphone computer, a tablet computer, a kiosk, a point-of-sale (POS) device, a desktop computer, wearable technology (e.g., smartwatch, head-mounted display (HMD) devices), etc.

In typical implementations, before a transaction can be attempted, the sending computing device105and receiving computing device205can securely and reliably identify each other. This way, a man-in-the-middle (MITM) or other attacks cannot be performed against one or both devices. In one implementation, the tamper-resistant hardware may generate messages and signatures using internal private keys inaccessible to the rest of the computing device. Once a message is generated and signed, the sending or receiving computing device's network interface may transmit the message as it is safe from tampering, such as over Bluetooth®, Near Field Communication (NFC), Wi-Fi, cellular network, etc. Digitally signed transactions can reliably transfer funds from one account to another while being highly resistant to tampering. Before the transaction, however, it may be beneficial to validate and establish a reliable connection between the devices.

A number of methods can be used to establish a secure connection between two locally present devices, as representatively shown by numeral425. If one of the devices has a camera and the other has a display, the second device (e.g., receiving device205) can display a randomly generated QR code to the first device (sending device105), and then communicate only with a device who knows the contents of the QR code. A vice versa scenario can result if the sending device displays the QR code and the receiving device scans the code. If neither device has a camera or the camera is otherwise not a desirable option, but both have displays or other output devices (e.g., displays on a peripheral device like a smartwatch), the devices can be confident they are communicating with each other by displaying and comparing a common code generated by secure cryptographic methods. For example, a Diffie-Hellman key exchange can be used to establish a secure connection by exchanging public keys, and then a short hash of the two public keys can be displayed on each device to confirm that each device is using the same pair of keys. Once the end-point has been reliably identified, subsequent communications can be secured by Authenticated Encryption methods, which provide both confidentiality and integrity of messages. Alternatively, one device may generate the code that the other user operating the opposing device can enter into their device's input mechanism to establish a reliable connection. Essentially, some initial authentication between the devices can be performed to securely identify each other and then leverage the tamper-resistant hardware for the transaction.

As shown inFIG.4, the tamper-resistant hardware is configured with various security features410.FIG.5shows an illustrative and non-exhaustive schema of security features410that may be associated with tamper-resistant hardware405. Security features can include immutable data and instruction set505, authorization to access (e.g., password, biometric scan, PIN (personal identification number) code, etc.)510, prevent access after ‘n’ (e.g., three, four, etc.) unsuccessful attempts515, secured private key; inaccessible outside tamper-resistant hardware520, prescribed rules of use525, and other security features530.

The sending device105and receiving device205are each configured with a crypto application420that is locally executing. The crypto application may be a standalone application installed on the device, or alternatively may be a plugin installed in another application. InFIG.4, the users are attempting to execute a transaction between them, as representatively shown by numeral415. For example, the sending user105may be attempting to send digital currency to receiving user210in exchange for goods or services. The receiving user may be a brick and mortar store that sells goods, such as groceries, personal care items, etc., or may be a service provider, such as window cleaning, auto repair services, etc. The specific offering of goods or services is not pertinent to the system's overall execution, rather, the relevancy is that the sending user intends to pay the receiving user for some good or service.

FIGS.6-9show high-level environments several ordered steps of an exemplary transaction but may not include all of the steps. Further clarification and steps may be included in a transaction depending on the specific circumstances of the transaction, as shown inFIGS.10-12.

FIG.6shows an illustrative representation in which both the sending device105and the receiving device205have a network failure and cannot communicate with the remote ledger service120. The receiving device's crypto application420is able to identify that the sending device is configured with tamper-resistant hardware405, as representatively shown by numeral610. This detection may be done, for example, when the sending device's tamper-resistant hardware transmits the Spend Authorization605, which is a message that is signed by a mutually trusted bank. The bank may be some banking institution or company that holds the digital currency for the user. In this regard, the bank has a strong incentive to regulate its user base and prevent and vet out any corruption. The bank makes the judgment that the tamper-resistant hardware is satisfactory when they enable the user's account. The bank may also stop issuing Spend Authorizations to the tamper-resistant device if the account exhibits corrupt or otherwise unordinary behavior. Discussion of the Spend Authorization is discussed in greater detail below.

The bank judgment is based on a certificate signed by the device manufacturer who created the tamper-resistant hardware. The device presents this certificate to the bank during account activation so that the tamper-resistant hardware is approved before any transactions are ever attempted.

FIG.7shows an illustrative representation in which the sending device transmits a Revokable Payment Transaction (RPT)705to the receiving device205after the tamper-resistant hardware has been detected (FIG.6). In this scenario, the sending device105and receiving device205do not have active network connections to the remote ledger service120but can still execute a trustworthy transaction using the tamper-resistant hardware405. The tamper-resistant hardware transmits the RPT to the receiving device. The RPT may include, for example, a promise to pay a given amount (e.g., $50 of digital currency) that the sender110or sending device105can revoke within a revokable term, which is some predetermined time interval. Depending on the situation and system configuration, the revokable term can be minutes, hours, or days. In typical implementations, the revokable term may be five days to enable sync up with the remote ledger service.

The receiving device205transmits a Confirmation710to the sending device105responsively to receiving the RPT. Upon receipt of the Confirmation message, the sending device considers the transaction final and irrevocable, though still requiring execution on the ledger.

FIG.8shows an illustrative environment where, responsively to receiving the confirmation, the sending device transmits a Non-Revokable Payment Transaction (Non-RPT)805to the receiving device205. 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 revoke the transaction. Simultaneously with the transmission of the Non-RPT, before transmitting the Non-RPT, or after transmitting the Non-RPT, the sending device also displays a “Paid” 820 message on its computing device's display815. The displayed message may be words, symbols, graphics, artwork, icons, or alternatively, may be a sound that is triggered that represents a positive outcome.

When the sending device105and receiving device205regain their network connection, one or both of the devices can report the Non-RPT to the remote ledger service120, as representatively shown by numerals810. Or, in the case where the Non-RPT did not arrive at the receiving device, it can report the RPT to the remote ledger service. This will insure that funds will transfer even if the sending device is lost or otherwise fails to report the Non-RPT in a timely manner.

In typical implementations, the transaction can be canceled by the sending device105anytime until the Non-RPT is transmitted or until the sending device receives the confirmation. Once the confirmation is received, the sending device may consider the transaction final and perform operations as such. After the receiving device transmits the confirmation to the sending device, a prompt may show up on the receiving device that tells the receiving user to check the sending user's display for some “Paid” or “Cancelled” message. This may occur in case the Non-RPT is not received at the receiving device, and therefore, the receiving device is not sure whether the transaction was executed. Reviewing the device's display with tamper-resistant hardware can be a safe and secure mechanism for the non-tamper-resistant device user to verify the transaction executed.

FIG.9shows an illustrative environment in which the confirmation was not received by the sending device, as representatively shown by numeral905. Responsively, the sending device displays “Cancelled”910on its user display815. The “Cancelled” message indicates to both parties that the transaction was not executed, and a Revoke Payment Transaction910will be reported as such to the remote ledger service120when the network becomes available again. The Revoke Payment Transaction is generated responsively to the canceled transaction and saved until the network is available.

FIGS.10-11show illustrative flow diagrams of distinct payment protocols that utilize overlapping techniques and leverage specific configurations and transmission protocols to safeguard the viability and trustworthiness of the transactions. Each embodiment leverages the tamper-resistant hardware associated with at least one of the computing devices to facilitate the transaction's viability. While only one device is shown with tamper-resistant hardware, in other implementations, each device may be configured with tamper-resistant hardware. Furthermore, tamper-resistant hardware is the component generating the various communications for a given device, such as the sending computing device inFIGS.10and11and the receiving computing device inFIG.12.

The tamper-resistant hardware may generate messages and signatures using internal private keys inaccessible to the rest of the computing device. Once a message is generated and signed, the sending or receiving computing device's network interface may transmit the message as it is safe from tampering, such as over Bluetooth®, Near Field Communication (NFC), Wi-Fi, cellular network, etc. Digitally signed transactions can reliably transfer funds from one account to another while being highly resistant to tampering. However, this presumes that the sender and receiver accounts specified by the transactions have been 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.

A number of methods can be used to establish a secure connection between two locally present devices. If one of the devices has a camera and the other has a display, the second device can display a randomly generated QR code to first device, and then communicate only with a device who knows the contents of the QR code. If neither device has a camera, but both have displays, they can be certain they are communicating with each other by displaying and comparing a common code generated by secure cryptographic methods. Once the end-point has been reliably identified, subsequent communications can be secured by Authenticated Encryption methods, which provide both confidentiality and integrity of messages. Essentially, some initial authentication between the devices can be performed so that the devices can securely identify each other.

FIG.10shows an illustrative flow diagram of an off-network payment protocol1002, which shows additional details and steps about the transaction described inFIGS.6-9. The right side column, transaction status1045, shows the transaction status from a connection failure handling perspective. Meaning whether the transaction is cancelable1050if a failure occurs at that stage in the process, whether the sender and receiver are in an intermediate state in which the receiver should confirm with the sender's display1055,” or whether the payment was a success1060.

In step1005, the receiving device205requests a Spend Authorization from the sending device105. The request may include identifying the payment provider and specifies an offline mode since there is no presently available network connection to the ledger. Selection of the offline mode means that all communications will be local to the two devices, so should generally complete quickly or not at all. Thus, shorter timeout parameters are used than in the online mode where time finalizing transactions on a remote ledger takes additional time. In step1010, the tamper-resistant hardware at the sending device sends the Spend Authorization from its last ledger sync. The Spend Authorization includes an indication that the sending device is configured with tamper-resistant hardware that was previously approved by a mutually trusted bank or financial institution that provides user accounts. The Spend Authorization provides sufficient security to the receiving device since the bank can revoke the Spend Authorization if the bank detects corrupt or unordinary behavior, such as intentionally attempting to overdraw an account, tampering with the device's hardware, etc.

The receiving device may evaluate the payment provider's signature on the Spend Authorization, the expiration period for the Spend Authorization, and the amount limit. If the payment provider's signature matches with some payment provider public key stored at the receiving device, the Spend Authorization has not expired, and the amount limit is not lower than the desired payment for the instant transaction, then the receiving device may transmit a request for payment to the sending device.

In step1015, the receiving device205transmits a request payment message to the sending device, responsive to receiving and evaluating the Spend Authorization. The request payment message includes a payment amount for the transaction and an incremented recipient sequence number. When returned back in the payment transaction, the recipient sequence number allows the recipient to identify the payment as a newly generated one, not a replay of a previous payment.

In step1020, the tamper-resistant hardware405at the sending computing device transmits a Revokable Payment Transaction (RPT) to the receiving device and saves the RPT in persistent storage. Persistent storage herein may refer to non-volatile storage, such as flash storage, hard disk, optical media, or other devices that retain data after switching off the device. The RPT includes the amount from the requested payment and a revokable term over which the sender can revoke the transaction. The revokable term begins when the receiving device submits the transaction to the remote ledger service120. The recipient sequence number prevents the replay of previous payments.

In step1025, the receiving device205evaluates the RPT. Evaluation of the RPT includes the sending device's signature, consistency of the RPT with the Spend Authorization, and consistency of the RPT with the Payment Request. Upon acceptance, the receiving device saves the RPT in persistent storage.

In step1030, the receiving device transmits a Confirmation to the sending device. At this stage, the sending device can revoke the transaction if the confirmation is not received. The transaction is cancelable until the tamper-resistant hardware405at the sending computing device receives the confirmation and proceeds with its next steps. Should the confirmation not be received within a predetermined time interval, the sending device submits a Revoke Payment Transaction to the remote service ledger when a network connection becomes available.

In step1035, the tamper-resistant hardware405at the sending computing device transmits a Non-Revokable Payment Transaction (Non-RPT) to the receiving device and displays “Paid” on its user interface (UI) for the receiver's confirmation. Receipt of the Non-RPT indicates to the receiving device that the transaction was locally executed. The receiver can confirm that the transaction was executed at the sending device by reviewing the “Paid” screen, regardless of whether the Non-RPT was received due to some local network connection failure over Bluetooth®, Near-Field Communication (NFC), Wi-Fi, etc. As shown in the transaction status1045column, the receiver can confirm the application's status by viewing the sender's display.

The receiving device evaluates the Non-RPT upon receipt. The receiving device verifies the consistency of the Non-RPT with the RPT, the sending device's signature, saves the Non-RPT to persistent storage, and discards the RPT. In step1040, one or both of the sending device105or the receiving device205can report the Non-RPT and the executed transaction to the remote ledger when the network becomes available. The payment is a success at this stage, as representatively shown by numeral1060, and is no longer cancelable. If the receiving device does not receive the Non-RPT, it will submit the RPT when the remote ledger next becomes available. Submitting the RPT ensures that funds will transfer, as long as the sending device does not submit a Revoke Payment transaction before the revokable term expires. When funds are transferred by an RPT, the ledger may place them in a held state, not available for spending until the revokable term expires.

FIG.11shows an illustrative flow diagram of a half off-network payment protocol1102transaction between the sending device105and receiving device205. In this scenario, the receiving device has an operable network connection with the remote ledger service120, and the sending device does not.

In step1105, the receiving device205sends a Spend Authorization request to the sending device. The Spend Authorization request includes a request to identify the payment provider and an indication that the transaction will be in an “online mode” since the receiving device has a live connection. Note the contrast from the off-network payment protocol1002inFIG.10, in which the receiving device indicates an offline mode.

In step1110, the tamper-resistant hardware405at the sending computing device transmits a request for a fresh Spend Authorization to the remote ledger service120responsive to the received request from the receiving device. The Spend Authorization request is encrypted and passes through to the receiving device to the remote ledger service120. Specifically, the pass-through communication may be transmitted using some local connection to the receiving device, and then the receiving device uses its established Wide Area Network (WAN) connection to transmit the Spend Authorization request to the remote ledger. The pass-through Spend Authorization request enables the tamper-resistant hardware405at the sending computing device to receive a current ledger timestamp for its account and submit any outstanding transactions.

In step1115, the remote ledger service120transmits the fresh Spend Authorization as a pass-through communication to the tamper-resistant hardware405at the sending computing device105. The remote ledger service executes any outstanding transactions and, provided that the account remains in good standing, transmits the encrypted Spend Authorization, which details the sender's current ledger time stamp, expiration, and spending limits. The Spend authorization can be deciphered using the tamper-resistant hardware405at the sending device105. The sending device stores the Spending Authorization in persistent storage for future transactions that may be performed offline.

In step11120, the tamper-resistant hardware405at the sending computing device105transmits the Spend authorization to the receiving device. The Spend Authorization includes a spending limit, an expiration for the Spend Authorization, and the payment provider's signature, which validates the sending device's tamper-resistant hardware. In step1125, the receiving device evaluates the Spend Authorization by reviewing the information therein. Upon validation, in step1130, the receiving device transmits the payment request to the sending device. The payment request includes an amount for the transaction and an incremented recipient sequence number identifying the receiving device's specific transaction.

In step1135, the tamper-resistant hardware405at the sending computing device transmits an RPT to the receiving device and saves the RPT in persistent storage. The RPT includes the amount from the requested payment and a revokable term over which the sender can revoke the transaction. In this scenario, the revokable term may last seconds or minutes, depending on the implementation. Since there is a live connection to the remote ledger, the revokable term may last one minute to receive confirmation from the receiving device. The revokable term begins when the receiving device submits the transaction to the remote ledger service120. The recipient sequence number prevents the replay of previous payments.

In step1140, the receiving device transmits the RPT to the remote ledger service120. In step1145, the remote ledger service executes the transaction by transferring funds from the sender's account to the receiver's account. The remote ledger service verifies the transaction by waiting for consensus with other nodes. In step1150, the receiving device may confirm the 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 step1155, the remote ledger service confirms the execution of the transaction with the receiving device.

In step1160, the receiving device transmits a confirmation of payment receipt to the tamper-resistant hardware405at the sending computing device. In step1165, the tamper-resistant hardware405at the sending computing device transmits a Non-RPT to the receiving device and displays a “Paid” or similar connotation on its UI.

As shown in the transaction status1180column, the transaction was cancelable anytime up until the sending device receives the confirmation, transmits the Non-RPT, and displays the “Paid” representation. In this regard, the transaction may be cancelable anytime before the sending device processes the receiving device's confirmation. The receiving device can confirm the execution of the transaction after confirmation is transmitted by reviewing the sender's display1190or by receiving the Non-RPT.

Upon receiving the Non-RPT, the transaction status is considered a “Payment success”1195. In step1170, the receiving device submits the Non-RPT to the remote ledger service120. In step1175, the remote ledger service executes the transaction against the receiving device's account.

FIG.12shows an illustrative flow diagram for a scenario in which the receiving device possesses the tamper-resistant hardware1202instead of the sending device, as inFIGS.10and11. Like the other scenarios, the device with tamper-resistant hardware is considered trusted and thus has the authority to revoke a transaction, which it can exercise until the transaction is viably executed.

In step1205, the sending device105sends a payment request to the receiving device105. The payment request may include a monetary amount for the transaction. In step1210, the receiving device transmits the Payment Request to the sending device. The Payment Request includes a Spend Authorization from a prior ledger sync to prove the receiving device's tamper-resistant hardware is trusted to correctly use the revoke power granted to it. The Payment Request may also include the recipient sequence number to allow the recipient to easily identify that the payment is new.

In step1215, the sending device105validates the Spend Authorization to verify the tamper-resistant hardware of the receiving device. In step1220, the sending device sends a request for a current ledger time from the remote ledger service120. In step1225, the remote ledger service sends the current ledger time to the sending device. In step1230, 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 power to revoke in the former, while the sender has the power in the latter. The Rev-PT includes the recipient's sequence number from the payment request in step1210, and includes an expiration period, such as 20 seconds. The receiving device confirms the recipient sequence number and saves the Rev-PT to persistent storage. In step1235, the tamper-resistant hardware at the receiving device transmits the Rev-PT to the remote ledger service as a pass-through communication.

In step1240, the remote ledger service executes the transaction responsively to receiving the pass through Rev-PT from the receiving device205. The receiving device waits the period identified in the Rev-PT from the sending device, such as 20 seconds. The ledger may record a reverse check, which records the amount, date, and sender of the transfer, allowing the receiving device to refund the money if they fail to receive confirmation that the transfer completed. If the tamper-resistant hardware at the receiving device does not receive an immediate error from the remote ledger, the tamper-resistant hardware waits a period of time for the ledger to finalize the transaction, then transmits a confirm execution query as a pass-through to the remote ledger service in step1245. In step1250, the remote ledger service confirms the transaction's execution as a pass-through communication to the tamper-resistant hardware at the receiving device. Upon receiving the pass-through confirmation from the remote ledger, the tamper-resistant hardware at the receiving device considers the transaction executed and is no longer cancelable. The receiving device finalizes the transaction and creates a delete-check transaction to delete the reverse check recorded on the ledger. If confirmation from the remote ledger fails to 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 not transferred in the first place, then the check will not exist on the ledger, so no refund will occur.

In step1255, the tamper-resistant hardware at the receiving device sends the delete-check transaction as confirmation of payment receipt and displays “Received” on its UI. From the sending device's prior direct and deliberate transmittal in step1230until the receipt of the confirmation and/or the exposure 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 of each pass-through communication throughout the pendency of the transaction to alert both parties to know of the status.

In step1260, the sending device105forwards a delete-check transaction to the remote ledger service120. In step1265, the remote ledger service executes and reports the delete-check transaction to the sending device. In step1270, the sending device displays that the payment is confirmed, which can be verified by the receiver by viewing the sender's display. Or, in the case where the ledger confirmation failed to arrive, the receiving device will forward the refund transaction, which the sender can execute to regain access to the funds.

Referring to the transaction status1280column, the connection failure handling varies depending on which party is communicating. For example, the transaction may be canceled by the receiving device205, sending device105, or the remote ledger service120up until the sender sends the Rev-PT in step1230, as representatively shown by numeral1275. The transaction may be canceled by the receiving device or the sender should confirm the transaction's execution on the receiver's display up until the receiving device receives the confirmation from the remote ledger service in step1250, as representatively shown by numeral1290. The payment is considered a success for all parties when the remote ledger service receives the delete-check transaction in step1260, as representatively shown by numeral1295. The variances in areas1285and1290are due to the different parties involved at points in the transaction.

InFIGS.10-12, the transaction can be canceled at any point as shown in the status columns on the right sides of the flow diagrams. The cancellations may occur, for example, if a communication is lost at any point in time during the cancelation window. For example, inFIG.10, in communications1005,1010,1015,1020, and1025, both the sending and receiving devices may consider the transaction canceled if any of those communications are lost or not responded to. The periods at which one party submitted a confirmation, such as steps1030inFIG.10,1160inFIG.11, and1230inFIG.12, are when that one party is in an intermediate state and can confirm on the tamper-resistant hardware's display to confirm the transaction, at least until a Non-RPT (FIGS.10and11) or delete-check (FIG.12) is received. Throughout this intermediate state, status updates may be displayed on the tamper-resistant device's user interface to keep both parties approved of the transaction's progression. The updates may include, for example, the specific communication that was most presently received or communicated as shown in the drawings or discussed herein in reference to the drawings.

FIGS.13and14show illustrative processes performed by a sending computing device, receiving computing device, a remote ledger service, or a combination there. Although the steps are shown in sequential order, the features and actions therein may be alternatively arranged and/or certain steps may be added or removed. The process is exemplary only to show one specific implementation for understanding the present disclosure's features.

In step1305, inFIG.13, the sending computing device sends a Revokable Payment Transaction (RPT) to a receiving computing device, in which the RPT includes a monetary amount and a revokable term. In step1310, the sending computing device, responsive to receiving a confirmation message that the RPT was received and validated at the receiving computing device, sends a Non-Revokable Payment Transaction (Non-RPT) to the receiving computing device. Alternatively, in step1315, the sending computing device generates a Revoke Payment Transaction responsive to the sending computing device failing to receive the confirmation message from the receiving computing device. In this regard, the sending computing device either generates the Non-RPT or the Revoke Payment Transaction depending on the confirmation messages receipt status.

In step1405, inFIG.14, the sending computing device establishes that off-network protocols are to be used for the transaction. In step1410, the sending computing device sends an RPT to a receiving computing device. In step1415, the sending computing device receives a confirmation message that the RPT was received and validated at the receiving computing device. In step1420, the sending computing device, responsive to receiving the confirmation message, sends a Non-RPT to the receiving computing device.

FIG.15shows an illustrative architecture1500for a device, such as a smartphone, tablet, or laptop computer capable of executing the various features described herein. The architecture1500illustrated inFIG.15includes one or more processors1502(e.g., central processing unit, dedicated AI chip, graphics processing unit, etc.), a system memory1504, including RAM (random access memory)1506, ROM (read only memory)1508, and long-term storage devices1512. The system bus1510operatively and functionally couples the components in the architecture1500. A basic input/output system containing the basic routines that help to transfer information between elements within the architecture1500, such as during startup, is typically stored in the ROM1508. The architecture1500further includes a long-term storage device1512for storing software code or other computer-executed code that is utilized to implement applications, the file system, and the operating system. The storage device1512is connected to the processor1502through a storage controller (not shown) connected to the bus1510. The storage device1512and its associated computer-readable storage media provide non-volatile storage for the architecture1500. Although the description of computer-readable storage media contained herein refers to a long-term storage device, such as a hard disk or CD-ROM drive, it may be appreciated by those skilled in the art that computer-readable storage media can be any available storage media that can be accessed by the architecture1500, including solid stage drives and flash memory.

By way of example, and not limitation, computer-readable storage media may include volatile and non-volatile, 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 includes, but is 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, DVDs, 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 which can be used to store the desired information and which can be accessed by the architecture1500.

According to various embodiments, the architecture1500may operate in a networked environment using logical connections to remote computers through a network. The architecture1500may connect to the network through a network interface unit1516connected to the bus1510. It may be appreciated that the network interface unit1516also may be utilized to connect to other types of networks and remote computer systems. The architecture1500also may include an input/output controller1518for receiving and processing input from a number of other devices, including a keyboard, mouse, touchpad, touchscreen, control devices such as buttons and switches or electronic stylus (not shown inFIG.15). Similarly, the input/output controller1518may provide output to a display screen, user interface, a printer, or other type of output device (also not shown inFIG.15).

It may be appreciated that any software components described herein may, when loaded into the processor1502and executed, transform the processor1502and the overall architecture1500from a general-purpose computing system into a special-purpose computing system customized to facilitate the functionality presented herein. The processor1502may be constructed from any number of transistors or other discrete circuit elements, which may individually or collectively assume any number of states. More specifically, the processor1502may 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 processor1502by specifying how the processor1502transitions between states, thereby transforming the transistors or other discrete hardware elements constituting the processor1502.

Encoding the software modules presented herein also may transform the physical structure of the computer-readable storage media presented herein. The specific transformation of physical structure may depend on various factors in different implementations of this description. Examples of such factors may include, but are not limited to, the technology used to implement the computer-readable storage media, whether the computer-readable storage media is characterized as primary or secondary storage, and the like. For example, if the computer-readable storage media is implemented as semiconductor-based memory, the software disclosed herein may be encoded on the computer-readable storage media by transforming the physical state of the semiconductor memory. For example, the software may transform the state of transistors, capacitors, or other discrete circuit elements constituting the semiconductor memory. The software also may transform the physical state of such components in order to store data thereupon.

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 magnetic or optical media, when the software is encoded therein. These transformations may include altering the magnetic characteristics of particular locations within given magnetic media. These transformations also may include altering the physical features or characteristics of particular locations within given optical media to change the optical characteristics of those locations. Other transformations of physical media are possible without departing from the scope and spirit of the present description, with the foregoing examples provided only to facilitate this discussion.

In light of the above, it may be appreciated that many types of physical transformations take place in the architecture1500in order to store and execute the software components presented herein. It also may be appreciated that the architecture1500may 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 the architecture1500may not include all of the components shown inFIG.15, may include other components that are not explicitly shown inFIG.15, or may utilize an architecture completely different from that shown inFIG.15.

The computing device may further be configured with tamper-resistant hardware1522to execute various functions and operations discussed herein, such as the various transmissions performed by the sending computing device or the receiving computing device. The tamper-resistant hardware may be considered a device that is configured to make a private key unavailable outside its enclosure, require an authorization value in order to use its private key, be immutable, and prevent access after too many incorrect authorization value guesses, among other security features. While hardware features are discussed herein, the tamper-resistance may be configured as a hybrid of hardware and software, purely hardware, or purely software. The tamper-resistant device may exhibit signs of attempted corruption or may react when some physical intrusion is attempted. The tamper-resistant hardware may be a trusted platform module (TPM) or implemented as a Trusted Execution Environment (TEE) created as a portion of the exposed processor.

FIG.16is a simplified block diagram of an illustrative computer system1600such as a remote server, smartphone, tablet computer, laptop computer, or personal computer (PC) which the present disclosure may be implemented. Computer system1600includes a processor1605, a system memory1611, and a system bus1614that couples various system components including the system memory1611to the processor1605. The system bus1614may 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 memory1611includes read only memory (ROM)1617and 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 system1600, such as during startup, is stored in ROM1617. The computer system1600may further include a hard disk drive1628for reading from and writing to an internally disposed hard disk, a magnetic disk drive1630for reading from or writing to a removable magnetic disk (e.g., a floppy disk), and an optical disk drive1638for reading from or writing to a removable optical disk1643such as a CD (compact disc), DVD (digital versatile disc), or other optical media. The hard disk drive1628, magnetic disk drive1630, and optical disk drive1638are connected to the system bus1614by a hard disk drive interface1646, a magnetic disk drive interface1649, and an optical drive interface1652, 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 system1600. Although this illustrative example includes a hard disk, a removable magnetic disk1633, and a removable optical disk1643, other types of computer-readable storage media which can store data that is accessible by a computer such as magnetic cassettes, Flash memory cards, digital video disks, data cartridges, random access memories (RAMs), read only memories (ROMs), and the like may also be used in some applications of the present disclosure. In addition, as used herein, the term computer-readable storage media includes one or more instances of a media type (e.g., one or more magnetic disks, one or more CDs, etc.). For purposes of this specification and the claims, the phrase “computer-readable storage media” and variations thereof, are intended to cover non-transitory embodiments, and does not include waves, signals, and/or other transitory and/or intangible communication media.

A number of program modules may be stored on the hard disk, magnetic disk, optical disk1643, ROM1617, or RAM1621, including an operating system1655, one or more application programs1657, other program modules1660, and program data1663. A user may enter commands and information into the computer system1600through input devices such as a keyboard1666, pointing device (e.g., mouse)1668, or touch-screen display1673. Other input devices may include a microphone, joystick, game pad, satellite dish, scanner, trackball, touchpad, 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 processor1605through a serial port interface1671that is coupled to the system bus1614, but may be connected by other interfaces, such as a parallel port, game port, or universal serial bus (USB). A monitor1673or other type of display device is also connected to the system bus1614via an interface, such as a video adapter1675. In addition to the monitor1673, personal computers typically include other peripheral output devices (not shown), such as speakers and printers. The illustrative example shown inFIG.16also includes a host adapter1678, a Small Computer System Interface (SCSI) bus1683, and an external storage device1676connected to the SCSI bus1683.

The computer system1600is operable in a networked environment using logical connections to one or more remote computers, such as a remote computer1688. The remote computer1688may 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 relative to the computer system1600, although only a single representative remote memory/storage device1690is shown inFIG.16. The logical connections depicted inFIG.16include a local area network (LAN)1693and a wide area network (WAN)1695. Such networking environments are often deployed, for example, in offices, enterprise-wide computer networks, intranets, and the Internet.

When used in a LAN networking environment, the computer system1600is connected to the local area network1693through a network interface or adapter1696. When used in a WAN networking environment, the computer system1600typically includes a broadband modem1698, network gateway, or other means for establishing communications over the wide area network1695, such as the Internet. The broadband modem1698, which may be internal or external, is connected to the system bus1614via a serial port interface1671. In a networked environment, program modules related to the computer system1600, or portions thereof, may be stored in the remote memory storage device1690. It is noted that the network connections shown inFIG.16are illustrative and other means of establishing a communications link between the computers may be used depending on the specific requirements of an application of the present disclosure.

Various illustrative embodiments are disclosed herein. In one exemplary embodiment, disclosed is a sending computing device configured for sending and receiving digital currency payments, comprising: a network interface to communicate with receiving computing device; tamper-resistant hardware, which secures one or more private keys that are inaccessible outside of the tamper-resistant hardware; one or more processors; and one or more hardware-based memory devices having instructions which, when executed by the one or more processors, cause the sending computing device to: send a Revokable Payment Transaction (RPT) to a receiving computing device, in which the RPT includes a monetary amount and a revokable term over which the sending device is authorized to cancel a transaction; and execute one of the following actions: responsive to receiving a confirmation message that the RPT was received and validated at the receiving computing device, send a Non-Revokable Payment Transaction (Non-RPT) to the receiving computing device, which indicates a payment has succeeded and the revokable term from the RPT has been removed; or generate a Revoke Payment Transaction responsive to the sending device failing to receive the confirmation message from the receiving computing device.

In another example, the one or more processors are further configured to expose, on the sending device's user interface, a confirmation message that the payment has succeeded, responsive to receiving the confirmation message from the receiving computing device. As another example, the one or more processors are further configured to receive instructions that the transaction will be executed under off-network protocols. In another example, the instruction that the transaction will be executed under off-network protocols is received prior to transmitting the RPT. In another example, the one or more processors are further configured to transmit the Non-RPT to a remote ledger service when network access becomes available. As another example, the sending computing device and receiving computing device are configured to consider the transaction canceled when any communication is lost before the sending computing device receives the confirmation message. In another example, the one or more processors are further configured to expose, on the sending device's user interface, a message that indicates the transaction is canceled, responsive to the sending device failing to receive the confirmation message from the receiving computing device within a predetermined time interval. As another example, the one or more processors are further configured to transmit a Spend Authorization to the receiving computing device, in which the Spend Authorization confirms that a sending account is under exclusive control of the sending computing device is configured with tamper-resistant hardware. In another example, the one or more processors are further configured to transmit the Revoke Payment Transaction when network connection becomes available. In another example, the one or more processors are further configured to request a fresh Spend Authorization from a remote ledger service as a pass-through communication with the receiving computing device. As another example, the one or more processors are further configured to send the fresh Spend Authorization to the receiving computing device.

Another illustrative embodiment discloses a method performed at least partially by tamper-resistant hardware within a sending computing device to execute a transaction, comprising: establishing that off-network protocols are to be used for the transaction; sending a Revokable Payment Transaction (RPT) to a receiving computing device, in which the RPT includes a monetary amount and a revokable term over which the sending device is authorized to cancel a transaction; and receiving a confirmation message that the RPT was received and validated at the receiving computing device; responsive to receiving the confirmation message, sending a Non-Revokable Payment Transaction (Non-RPT) to the receiving device, which indicates a payment has succeeded and the revokable term from the RPT has been removed.

In another example, further comprising exposing, on the sending device's user interface, a confirmation message that the payment has succeeded, responsive to receiving the confirmation message from the receiving computing device. In another example, the off-network protocols are established responsively to receiving instructions from the receiving computing device. In another example, further comprising transmitting the Non-RPT to a remote ledger service when network access becomes available. As another example, wherein the sending computing device and receiving computing device are configured to consider the transaction canceled when any communication is lost before the sending computing device receives the confirmation message.

Another illustrative embodiment discloses one or more hardware-based memory devices storing computer-executable instructions which, when executed by one or more processors associated with a sending computing device, cause the sending computing device to: send a Revokable Payment Transaction (RPT) to a receiving computing device, in which the RPT includes a monetary amount and a revokable term over which the sending device is authorized to cancel a transaction; and execute one of the following actions: responsive to receiving a confirmation message that the RPT was received and validated at the receiving computing device, send a Non-Revokable Payment Transaction (Non-RPT) to the receiving computing device, which indicates a payment has succeeded and the revokable term from the RPT has been removed; or generate a Revoke Payment Transaction responsive to the sending device failing to receive the confirmation message from the receiving computing device.

In a further example, the executed instructions further cause the sending computing device to transmit a Spend Authorization to the receiving computing device, in which the Spend Authorization confirms that the sending computing device is configured with tamper-resistant hardware. As another example, the executed instructions further cause the sending computing device to transmit the Non-RPT to a remote ledger service when network access becomes available. As a further example, the executed instructions further cause the sending computing device to receive instructions that the transaction will be executed under off-network protocols

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.