Secure exchange of cryptographically signed records

Abstract

Disclosed are systems and methods for securely exchanging cryptographically signed records. In one aspect, after receiving a content request, a sender device can send a record to a requesting receiver device (e.g., a proxy device). The record can be sent in a decentralized (e.g., peer-to-peer) manner via a short-range link, and the devices may not communicate with a centralized processing platform. The record can include a sender signature created using the sender device's private key. The receiver device can use the sender device's public key to verify the authenticity of the sender signature. After adding the encryption-based receiver signature, the receiver device can redeem the record with the platform. Upon successful verification of the record, the platform can execute as indicated by the content of the record (e.g., modify or update a user account).

Description

[0001] This application is a divisional application of the Chinese patent application with application number 201780059173.2. The application date of the original application is July 27, 2017, the priority date is July 29, 2016, and the date of entering the Chinese national phase is March 26, 2019. The name of the invention is “Secure Exchange of Encrypted Signature Records”.

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS

[0003] This application claims priority to U.S. Provisional Application No. 62 / 368,408, filed on July 29, 2016, entitled “SECURE EXCHANGE OF CRYPTOGRAPHICALLY SIGNED RECORDS,” the contents of which are incorporated herein by reference in their entirety. Technical Field

[0004] The present disclosure relates generally to systems and methods for encryption, and more particularly to securely exchanging cryptographically signed records over a computer network. Background Art

[0005] Conventional systems, such as digital transmission, are useful for exchanging content and records over computer networks. This digital transmission can replace the need for traditional physical exchange of records. Parties utilizing these conventional systems are required to be connected to a network, such as the Internet, during the exchange. These conventional systems require all parties to the exchange to continuously access a central data center in order to verify the exchange. Summary of the Invention

[0006] Disclosed are systems and methods for securely exchanging cryptographically signed records. The systems and methods may use public and private key cryptography techniques. In one aspect, after receiving a content request, a sender device may send a record to a first recipient device that issued the request. The record may be sent in a decentralized (e.g., peer-to-peer) manner via a short-range link, and the devices may not communicate with a centralized processing platform. The record may include a sender signature created using the private key of the sender device. The first recipient device may use the public key of the sender device to verify the authenticity of the sender signature. After adding a "for processing only approval" and the recipient signature, the first recipient device may exchange the record with the processing platform. Based on the successful verification of the sender signature and the recipient signature, the processing platform may execute as indicated by the record content.

[0007] In another aspect, a first recipient device can send the record to a second recipient device after adding the first recipient's signature to the record. The second recipient device can verify the authenticity of the signature using the public keys of the sending device and the first recipient device. After adding the "processing only approval" and the second recipient's signature, the second recipient device can redeem the record with the processing platform.

[0008] On the other hand, after receiving a content request, the sender device can send a record to the proxy device that made the request on behalf of the principal. The proxy device can use the sender device's public key to verify the authenticity of the sender's signature in the record. The proxy device can add "Processed by Accreditation" to the record before the principal redeems the record with the processing platform.

[0009] In one aspect, a sender device may send a record to a receiver device. The receiver device may verify the received record by detecting malicious behavior (such as sender cloning with a single receiver, mousing, ghosting, sender cloning with multiple receivers, or forking). After detecting the malicious behavior, the receiver device may add a malicious endorsement to the record before sending the endorsed record to the processing platform. The processing platform may add the sender device to a blacklist after performing fuzzy determination or Boolean analysis. In another aspect, the processing platform may verify the record received from the device by detecting malicious behavior such as receiver cloning or ghosting.

[0010] Embodiments of systems and methods for securely exchanging cryptographically signed records are disclosed. In one aspect, after receiving a request for content, a sender device can send a record to the requesting recipient device. The record can be sent in a decentralized (e.g., peer-to-peer) manner via a short-range link, and the devices can not communicate with a centralized processing platform. The record can include a sender signature created using the private key of the sender device. The recipient device can use the public key of the sender device to verify the authenticity of the sender signature. After adding a "for processing only approval" and the recipient signature, the recipient device can redeem the record with the processing platform. Based on the successful verification of the sender signature and the recipient signature, the processing platform can execute as indicated by the record content.

[0011] Embodiments of systems and methods for securely exchanging cryptographically signed records are disclosed. In one aspect, after receiving a request for content, a sender device may send a record to a proxy device that made the request on behalf of a principal. The record may be sent in a decentralized (e.g., peer-to-peer) manner via a short-range link, and the devices may not communicate with a centralized processing platform. The record may include a sender signature created using the private key of the sender device. The proxy device may use the public key of the sender device to verify the authenticity of the sender signature. The proxy device may add "Processed by Approval" to the record before the principal redeems the record with the processing platform. Based on successful verification of the sender signature and the recipient signature, the processing platform may execute as indicated by the record content.

[0012] Embodiments of systems and methods for securely exchanging chains of cryptographically signed records involving multiple recipients are disclosed. In one aspect, a sender device can send a record to a first recipient device. The record can include a sender signature created using the sender device's private key. The first recipient device can verify the authenticity of the signature using the sender device's public key. After adding the first recipient signature to the record, the first recipient device can send the record to a second recipient device. The second recipient device can verify the authenticity of the signature using the sender device and the first recipient device's public keys. After adding a "processing only approval" and the second recipient signature, the second recipient device can redeem the record with a processing platform. Based on successfully verifying the signature, the processing platform can execute as indicated by the contents of the record.

[0013] Embodiments of systems and methods for verifying cryptographically signed records are disclosed. In one aspect, a sender device is capable of sending a record to a receiver device. The receiver device can verify the received record by detecting malicious behavior (such as sender cloning with a single receiver, snooping, ghosting, sender cloning with multiple receivers, or forking). After detecting the malicious behavior, the receiver device is capable of adding a malicious endorsement to the record before sending the endorsed record to a processing platform. The processing platform is capable of adding the sender device to a blacklist after performing a fuzzy decision or Boolean analysis. In another aspect, the processing platform is capable of verifying the record received from the device by detecting malicious behavior such as receiver cloning or ghosting.

[0014] The details of one or more embodiments of the subject matter described in this specification are set forth in the accompanying drawings and the following description. Other features, aspects, and advantages will become apparent from the description, drawings, and claims. Neither this summary nor the following detailed description is intended to define or restrict the scope of the inventive subject matter. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] Figure 1A and Figure 1B One embodiment of securely exchanging cryptographically signed content and records over a wireless network is schematically illustrated.

[0016] Figure 2 is a block diagram of an example user device configured to store public and private encryption keys.

[0017] Figure 3 is a block diagram of an example processing platform configured to store public encryption keys for user devices.

[0018] Figure 4 is an interaction diagram illustrating one embodiment of securely exchanging and redeeming individual records created for a record recipient.

[0019] Figure 5An example of an individual record created for one record recipient is schematically shown.

[0020] Figure 6 is an interaction diagram illustrating one embodiment of securely exchanging and redeeming individual records created for two record recipients.

[0021] Figure 7 Example individual records created for two record recipients are schematically shown.

[0022] Figure 8 Example individual records created for multiple record recipients are schematically illustrated.

[0023] Figure 9 is an interaction diagram illustrating one embodiment of securely exchanging and redeeming individual records involving an agent and a recipient.

[0024] Figure 10 Example individual records involving agents and record recipients are schematically illustrated.

[0025] Figure 11 is an interaction diagram illustrating one embodiment of securely exchanging and redeeming individual records involving query approval.

[0026] Figure 12 Example individual records related to query approval are schematically shown.

[0027] Figure 13 is an interaction diagram illustrating one embodiment of distributing public records from a processing platform.

[0028] Figure 14 An example public record for distribution is schematically shown.

[0029] Figure 15 is an interaction diagram illustrating an example of propagation of a public record by a record recipient device.

[0030] Figure 16 is an interaction diagram illustrating an example of propagation of a public record by a record sender device.

[0031] Figure 17 is an interaction diagram illustrating an example of malicious behavior by a sender cloning with multiple receivers.

[0032] Figure 18 is an interaction diagram illustrating an example of malicious behavior by a sender cloning with a single receiver.

[0033] Figure 19 is an interaction diagram illustrating an example of malicious behavior through forking.

[0034] Figure 20is an interaction diagram illustrating an example of malicious behavior through receiver cloning.

[0035] Figure 21 is an interaction diagram illustrating an example of malicious behavior through snooping.

[0036] Figure 22 is an interaction diagram illustrating an example of malicious behavior through ghosting.

[0037] Figure 23 is a block diagram of an example user device.

[0038] Figure 24 is a block diagram of an example processing platform.

[0039] Figure 25 An example of a standard transaction is shown schematically.

[0040] Figure 26 An example of a buyer clone with multiple sellers is schematically shown.

[0041] Figure 27 An example of a buyer clone with a single seller is schematically shown.

[0042] Figure 28 An example of check bifurcation is schematically shown.

[0043] Figure 29 An example of a vendor clone is schematically shown.

[0044] Figure 30 An example using snooping is schematically shown.

[0045] Figure 31 An example of ghosting is schematically shown.

[0046] Figure 32 An example of a Point of Sale (PoS) transaction is schematically shown.

[0047] Figures 33A-33B One embodiment of securely exchanging cryptographically signed digital checks is schematically illustrated. Figure 33C Another embodiment of securely exchanging cryptographically signed digital checks is schematically illustrated.

[0048] Figure 34A is an interactive diagram illustrating one embodiment of securely exchanging and redeeming cryptographically signed digital checks. Figure 34B is an interactive diagram illustrating another embodiment of securely exchanging and redeeming cryptographically signed digital checks.

[0049] Figure 35 An example of a wearable display system is schematically shown.

[0050] Reference numerals may be repeated throughout the drawings to indicate corresponding relationships between referenced elements.The drawings are provided to illustrate the example embodiments described herein and are not intended to limit the scope of the present disclosure. DETAILED DESCRIPTION

[0051] Overview

[0052] The systems and methods disclosed herein address various challenges associated with digital transmission and physical exchange. For example, a hybrid system can be used to securely transmit and exchange content and records over a network. The hybrid system provides for meaningful and satisfactory centralized and peer-to-peer exchange of content or records. Other advantages include ease of use, speed of exchange, verification capabilities, security, anonymity, irreversibility, and non-repudiation.

[0053] The systems and methods disclosed herein can face similar challenges that may arise with physical exchanges. They address various challenges associated with digital transmission, such as the non-trivial nature of replicating transaction instruments due to the differences between virtual and physical environments. They also disclose features that leverage digital tools and techniques available on digital platforms, such as the use of digital encryption, a more robust cryptographic analog to traditional handwritten signatures, for document authentication.

[0054] Example of securely exchanging cryptographically signed records

[0055] Figure 1A One embodiment of securely exchanging cryptographically signed content and records (e.g., cryptographically signed individual records 100) is schematically illustrated. A record sender 102a, using a record sender device, can create an individual record 100 and send it to a record receiver 102b. The record sender 102a can be a person who wishes to transfer content or a record to the record receiver 102b. The record receiver 102b can be a person who wishes to receive content or a record from the record sender 102a.

[0056] The record receiver 102b, using the record recipient device, can then modify the individual record 100 to create a modified individual record 100m1, where m indicates that the individual record 100 has been modified and m1 indicates the first modification of the individual record 100. The record receiver 102b can exchange the modified individual record 100m1 with the service provider 104. After the service provider 104 successfully processes the individual record 100m1 by operating a secure electronic processing platform, the service provider 104 can provide the record receiver 102b with a document, such as that indicated by the modified individual record 100m1. The record sender 102a and the record receiver 102b can exchange the individual records 100 in a distributed or decentralized (e.g., peer-to-peer) manner.

[0057] For illustrative purposes, the following example will describe the exchange of electronic records between a sender 102a and a receiver 102b. It should be understood that the sender 102a and the receiver 102b use physical electronic devices to perform the exchange of electronic records. For example, the sender and receiver electronic devices may include cellular phones, portable computing devices (e.g., laptop computers, tablet computers, e-readers), desktop computing devices, augmented reality devices (e.g., head-mounted augmented, virtual, or mixed reality displays), etc. It should be understood that the service provider 104 may use physical electronic devices to process the exchanged electronic records. For example, the service provider electronic devices may include one or more centralized or distributed server computers.

[0058] The record sender 102a, using its user device, can send the individual record 100 directly to the record receiver 102b in a peer-to-peer manner, for example, using a short-range link (e.g., a Bluetooth link), or directly through another user of the system. When sending the individual record 100, the user devices of the record sender 102a and the record receiver 102b can be online or offline. For example, the user devices of the record sender 102a and the record receiver 102b can both be online and connected to a network such as the Internet. As another example, one or both of the user devices of the record sender 102a and the record receiver 102b can be offline and not connected to the network. When the user device of the record receiver 102b communicates with the service provider 104, the record receiver 102b can exchange the modified individual record 100m1 with the service provider 104.

[0059] An individual record 100 may be a digital object comprising a plurality of blocks that may be sent from a record sender 102a to a record receiver 102b. In some embodiments, an individual record 100 may include a block 105a. A block 105a may include a number of components.

[0060] In order to provide security for exchanges, encryption techniques can be used in electronic records. For example, public key encryption techniques can be used, in which each party to a transaction (sender 102a and recipient 102b) or each device in a transaction (sender device and recipient device) is associated with both a public key (which can be widely disseminated) and a private key (which is kept secret and known only to the parties involved). Any sender can use the recipient's public key to encrypt a message for the recipient, but the encrypted message can only be decrypted by the recipient using the recipient's private key. The recipient of a message can securely reply to the sender by encrypting a reply message using the sender's public key, so that only the sender can decrypt the reply message using the sender's private key. As will be further described below, the sender and recipient's electronic devices can include hardware or software that can securely store the respective parties' private keys and perform encryption and decryption using the disseminated public key. Public key encryption is an example of asymmetric encryption, in which the key used for encryption (e.g., the recipient's public key) is different from the key used for decryption (e.g., the recipient's private key). In other embodiments, other asymmetric encryption techniques can be used.

[0061] For example, block 105a may include a public key 106a of a record sender device in a "from field," a public key 106b of a record receiver device in a "to field," a record identifier (ID) 108, content 110, and a record sender signature 112a of block 105a. The public key 106a of the record sender device may identify the originator of the individual record 100, i.e., the record sender 102a. The public key 106b of the record receiver device may identify the recipient of the individual record 100, i.e., the record receiver 102b.

[0062] The record ID 108 may increase, e.g., monotonically, so that no two individual records 100 created by a record sender device have the same record ID 108. For example, the content 110 may identify a document that the record recipient 102b may receive when redeeming the modified personal record 100m1 with the service provider 104. The service provider 104 may act as directed by the content 100 itself or indirectly through a third party.

[0063] A user can sign an individual record 100 by creating a secure encrypted signature for the individual record. The record sender 102a can use his user device to sign the individual record 100 by creating a record sender signature 112a. In order to sign the individual record 100, the record sender device can require authentication of the record sender 102a. Non-limiting examples of authentication include passphrase authentication, biometric authentication such as fingerprint authentication or iris authentication, or biometric data authentication. The record sender signature 112a can be a digital signature created using encryption. For example, the record sender device can use public key encryption such as Rivest-Shamir-Adleman (RSA) encryption to encrypt a hash such as a secure hash algorithm (SHA)-2 of the individual record 100. For example, any SHA-2 hash function with a record digest of 224, 245, 384, or 512 bits (e.g., SHA-256) can be used. The record sender signature 112a can be created using the private key of the record sender device public key encryption pair. The record sender device can securely store the private key. The record sender signature 112a can be verified by others as being authentically signed by the sender 102a (e.g., by the record receiver 102b having the record sender's device public key 106a). The record receiver 102b can obtain the record sender's device public key 106a from the individual record 100. Once created, the record sender signature 112a signs the block 105a. The record sender's device public key 106a, the record receiver's device public key 106b, the record ID 108, the content 110, and the record sender signature 112a can complete the block 105a of the individual record 100.

[0064] Once the record recipient 102b is in place, the record recipient 102b can add the approval in the approval block 105b to the individual record 100 to create the modified individual record 100m1. For example, the approval can be an "approval for processing only" 114, which specifies that the modified individual record 100m1 can only be redeemed by the recipient of the individual record in block 105a (the record recipient 102b). Once the approval is given, such as adding the "approval for processing only" 114, the record recipient 102b can repeat the process of generating a record recipient signature 112b for the approval block 105b to create the modified individual record 100. The record recipient signature 112b can be based on one or more portions of the modified individual record 100m1. For example, the record recipient signature 112b can be based on the approval block 105b. As another example, the record recipient signature 112b can be based on the block 105a, the approval block 105b, or any combination thereof. The modified individual record 100m1 may be transmitted electronically to the service provider 104 or to another party's electronic device.

[0065] Thus, an individual record can comprise a chain of blocks, each identifying its originator. At each block, the entire preceding portion of the chain can be signed by the user processing the block at the time. A user can sign the entire preceding portion of the chain using the private key associated with their user device. For example, a modified individual record 100m1 can be a chain consisting of two blocks 105a and 105b. Block 105a of individual record 100 can contain the public key 106a of the record sender device, which, together with the public key 106a of the record sender device, can identify the record sender 102a. The record sender signature 112a can be signed by the record sender device using the private key of the record sender device's public key encryption pair. The approval block 105b can contain the record recipient signature 112b, which, together with the public key 106b of the record recipient device, can identify the record recipient device. The record recipient signature 112b can be signed by the record recipient device using the private key of the record recipient device's public key encryption pair. The record recipient signature 112b may be based on the approval block 105b, or may be based on the approval block 105b, one or more blocks preceding the approval block 105b (eg, block 105a), or any combination thereof.

[0066] An individual record (e.g., a modified individual record 100m1, whose last block includes a "For Processing Only Endorsement" (FPOE) 114) can be electronically communicated and redeemed with a service provider 104. Upon redemption, the service provider 104 can process the modified individual record 100m1 by verifying the authenticity of one or more signatures in the chain of blocks 105a and 105b. For example, the service provider 104 can verify the authenticity of all signatures in the modified individual record 100m1, including the record sender signature 112a and the record receiver signature 112b. The authenticity of a signature can refer to the signature being created using a specific private key. For example, to authenticate the record sender signature 112a, the public key of the record sender device can be used to verify the record sender signature 112a and confirm that the record sender signature 112a was created using the record sender device's private key. Therefore, as long as the record sender 102a maintains that its private key remains private, the record sender 102a cannot reject an individual record 100 digitally signed by the record sender device.

[0067] If the content 110 includes instructions that the record recipient 102b should be given access to a document, such as a document with a specific ID, and all signatures in the chain are verified to be authentic, the document can be provided to the record recipient 102b at the end of the chain in the modified individual record 100m1, or to the user device of the record recipient 102b. For example, if the record sender signature 112a and the record recipient signature 112b in the modified original record 100m1 are verified to be authentic, the service provider 104 can provide the document, such as indicated by the content 110, to the record recipient 102b. The time when the record recipient 102b connects to the service provider 104 and redeems the modified individual record 100m1 constitutes a redemption event.

[0068] The content 110 of the record 100 may include, for example, messages, data, instructions to provide documents or other information to an entity, instructions to execute a computer program, contractual obligations or rights (e.g., smart contracts), instructions to transfer consideration (e.g., currency, cryptocurrency, securities, physical or intangible assets, etc.), etc. An advantage of certain embodiments is that by utilizing individual records that are not document-bearing, large amounts of consideration can be exchanged without the presence of the two parties at a central depository.

[0069] In one non-limiting example, sender 102a is the buyer of an asset from a seller, recipient 102b. Content 110 includes instructions from service provider 104 to transfer a cryptocurrency amount from sender 102a's account to recipient 102b's account. The sender's device digitally signs record 100 using the sender's device's private key and electronically transmits record 100 to the recipient's device. The recipient's device approves the record with approval 114 (e.g., in this context, the approval may be a "deposit-only approval") and digitally signs the record using the recipient's device's private key to create a modified record 100m1. The recipient's device transmits the modified record 100m1 to service provider 104, which redeems the modified record 100m1. The service provider 104 can verify that the modified record 100m1 is authentically signed by both the sender 102a and the receiver 102b (using their respective public keys), and can transfer the cryptocurrency amount (in the content 110) from the sender's account to the receiver's account.

[0070] Thus, in this non-limiting example, the record acts as a check in a digital check system and can be used by a buyer (sender 102a) to pay an asset to a seller (receiver 102b). In some cases, the asset is an electronic asset (e.g., computer code that provides the buyer with the desired functionality). The seller (receiver 102b) can create a record (similar to record 100) with the electronic asset as content, digitally sign it, and electronically transmit the record to the buyer (sender 102a). Thus, the buyer and seller can exchange cryptographically secure records to transfer the asset from the seller to the buyer in return for consideration (e.g., an amount in cryptocurrency). The service provider 104 can act as a clearing house for at least some of this exchange (e.g., debiting the buyer's cryptocurrency account and crediting the seller's cryptocurrency account).

[0071] Example system for exchanging cryptographically signed individual records

[0072] Example user device

[0073] The methods and systems for securely exchanging content and records of the present disclosure may be implemented by one or more user devices and one or more processing platforms. Figure 1B In the non-limiting example system shown in , users may operate user devices to create, send, receive, modify, or redeem individual records 100. For example, record sender 102a may operate record sender device 116a, and record receiver 102b may operate record receiver device 116b.

[0074] The user devices (e.g., the record sender device 116a and the record receiver device 116b) may be the same or may be different. The user devices may include a cellular phone, a tablet computer, an e-reader, a smartwatch, a head-mounted augmented, virtual or mixed reality display system, a wearable display system, or a computer. The user devices 116a, 116b may include the following references Figure 35 An embodiment of a wearable display system 3500 is described. The user device 116a or 116b can communicate with other devices on a network 118 using a communication link 120a, 120b (e.g., a cellular communication link). The network 118 can be a local area network (LAN), a wide area network (WAN), or the Internet accessible via a wired or wireless communication link (e.g., implementing the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standard).

[0075] When sending individual records 100, one or both of the record sender device 116a and the record recipient device 116b may be offline and not connected to the network 118. The record sender 102a, using the record sender device 116a, may use a short-range link (SRL) 122 to send the individual records 100 to the record recipient 102b. The short-range link (SRL) 122 may be a peer-to-peer wireless or other link through which the user devices 116a or 116b can communicate with each other. The short-range link (SRL) 122 may be based on the Infrared Data Association (IrDA) / Infrared Physical Layer Specification (IrPHY), Bluetooth, Near Field Communication (NFC), ad hoc 802.11, or any other wired or wireless communication method or system.

[0076] The processing platform 124 operated by the service provider 104 can communicate with other devices on the network 118 (e.g., user devices 116a and 116b) using a communication link 126. The communication link 120a, 120b, or 126 can be a wired or wireless communication, cellular communication, Local Area Network (LAN), Wide Area Network (WLAN), Radio Frequency (RF), Infrared (IR), or any other communication method or system. User 102a or 102b can redeem individual records with processing platform 124. For example, record recipient 102b using record recipient device 116b can redeem modified individual record 100m1 with processing platform 124.

[0077] Figure 2 is a block diagram of an example user device 116 configured to store public and private encryption keys. The user device 116 may include an individual record container 202, a secure element (SE) 204, and a public record 206. The individual record container 202 may be a digital data structure configured to contain an unredeemed individual record 208. For example, the individual record container 202b of the record recipient device 116b may contain the modified individual record 100m1 before the modified individual record 100m1 is electronically transmitted to and redeemed with the processing platform 124.

[0078] The secure element (SE) 204 can securely store the private key 210 of the user device and the service provider public key 212. The secure element (SE) 204 can use the private key 212 of the user device to sign the individual record 100 and the modified individual record 100m1. For example, the secure element (SE) 204a of the record sender device 116a can create the record sender signature 112a of the individual record 100. As another example, the secure element (SE) 204b of the record receiver device 116b can create the record receiver signature 112b of the modified individual record 100m1. In some embodiments, the secure element (SE) 204a of the record sender device 116a can add the public key 106a of the record sender device, the public key 106b of the record receiver device, the record ID 108, and one or more of the content 110 to the individual record 100.

[0079] The security element (SE) 204 can use the service provider public key 212 to verify the authenticity of the information received from the service provider 104. For example, the service provider 104 can use the processing platform 124 to send the updated public key of the device 214 to the user device 116a or 116b. The processing platform 124 can use the private key of the service provider public key encryption pair to sign the public key of the device 214. In some embodiments, the service provider private key is exclusive to the service provider. The security element (SE) 204 can verify the authenticity of the updated public key of the device 214. Verifying the authenticity of the updated public key of the device 214 can include using the service provider public key 212 to determine whether the signature of the public key of the device 214 has been created using the service provider public key. In some embodiments, there can be two or more independently operating processing platforms 124. And the user device 116 can include one or more service provider public keys 212 for two or more processing platforms 124.

[0080] The public record 206 may include valid user identities and additional information about users of the service provider processing platform 124. The public record 206 is publicly disseminated and shared among users of the processing platform 124. For example, the public record 206 may include the public key of the user device 214 disseminated by the system so that other users can cryptographically verify the digital signature. The public key of the user device 214a in the public record 206a of the record sender device 116a and the public key of the user device 214b in the public record 206b of the record receiver device 116b may be the same or different. Figure 1B, in order for the record sender 116a to use the new user device 116a2, the processing platform 104 may have to notify the other user devices 116 of the system of the public key of the user device 116'. When the other user devices 116 connect to the network 118, the processing platform 124 may send updated public records 206 including the updated public keys of the devices 214 (including the public key of the user device 116') to the other user devices 116. If the user device 116a is connected to the network 118 and the user device 116b is not connected, the user device 116a may receive the updated public key of the device 214a. Therefore, the public key of the device 214b in the public record 206b of the user device 116b may be a subset of the updated public key of the device 214a in the public record 206a of the user device 116a.

[0081] In some embodiments, some public keys may no longer be used and may be removed from the public keys of the device 214 by the processing platform 124. For example, if the record sender 102a no longer uses the record sender device 116a, the processing platform 124 may delete the record sender device's public key 106a from the processing platform's records. The processing platform 124 may send updated public keys for the device 214 (which exclude the record sender device's public key 106a) to other user devices 116. To maintain cryptographic security, if the record sender device 116a is no longer used, the device private key 210 should be permanently deleted or the device destroyed.

[0082] The user device can verify the authenticity of the received individual record using the public key of the user device 214. For example, the public key of the user device 214b in the public record 206b of the record recipient device 116b may include the public key 106a of the record sender device. The record recipient device 116b can verify the authenticity of the individual record 100 by using the public key 106a of the record sender device to determine whether the record signature 112a of the individual record 112a was created using the private key of the record sender device 116a.

[0083] Example processing platform

[0084] Figure 31 is a block diagram of an example processing platform 124 configured to store public encryption keys for user devices. Processing platform 124 may include a server or collection of servers that may be system infrastructure. Processing platform 124 may be directly connected to network 118 and may be indirectly, and perhaps only intermittently, connected to user devices 116 via network 118. Processing platform 124 may contain and maintain a central record 302 to track users, user devices 116, and access to content identified in the record. Processing platform 124 may process instructions contained in content 110 of record 100. For example, as described above, if content 110 of record 100 contains instructions to transfer cryptocurrency between user accounts, platform 124 may perform the transfer when the record is redeemed.

[0085] The processing platform 124 can maintain the public record 206 or can generate the public record 206 from the central record 302. The central record 302 can contain the public key of the device 214. The public key of the device 214 in the public record 206 of the user device 116 can be a subset of the public key of the user device 214 in the central record 302. For example, the public key of the user device 214 may have been updated, and the user device 116 may not have received the updated public key of the user device 214.

[0086] Central record 302 may include identifying information and auxiliary information for user 102a or 102b or user device 116a or 116b. Central record 302 may include user information 304 that may identify the association between a user and a user device. For example, central record 302 may include the association between record sender 102a and two record sender devices 116a and 116a'. In some embodiments, a user with multiple devices may be considered multiple users. In some embodiments, a user with multiple devices may be considered a single user. Public record 206 may not include user information 304.

[0087] The central record 302 may include a user record status 306 for tracking user information. For example, the content 110 of an individual record 100 may instruct the processing platform 124 to provide record recipient 102b with access to a document having its document ID stored in the content 110. However, the user record status 306 may indicate that only the record sender 102a itself can access the document; and that the record sender 102a cannot grant other users access to the document. As another example, the user record status 306 may indicate that the record sender 102a can provide other users with access to the document. As another example, the user record status 306 may indicate that the record sender 102a can only provide users with access to the document multiple times (such as once); and the user record status 306 may keep track of whether the individual record 100 has been redeemed and accessed by any user (e.g., record recipient 102b).

[0088] As a non-limiting example, the user record state 306 may track the record sender's account balance (e.g., in cryptocurrency). The record sender's account may be a payer account. If the content 110 of an individual record 100 instructs the processing platform 124 to pay the record receiver 102b an amount less than or equal to the record sender's account balance, the processing platform 124 may debit the record sender's account by the specified amount and credit the record receiver's account by the same amount. The record receiver's account may be a payee account. If the content 110 of an individual record 100 instructs the processing platform 124 to pay the record receiver 102b an amount greater than the record sender's account balance, the processing platform 124 may refuse to credit the record receiver's account by the specified amount. However, the record sender's account may be debited with an overdraft fee. The public record 206 may not include the user record state 306.

[0089] The exchange of cryptographically signed individual records disclosed herein may include many benefits. Benefits include, for example, ease of use or speed of exchange. Figure 1A and 1B As shown in , the record sender device 116a can send individual records 100 to the record receiver device 116b via a short range link (SRL) 122 without either party communicating with the service provider 104 through the network 118. Additional or alternative benefits may include, for example, the ability to verify or authenticate digital signatures. Figure 2 As shown in , the public key 214 of the user device is propagated in the public record 206. Thus, the record recipient device 116b can verify the authenticity of the record sender signature 112a in the individual record 100 and that the record sender device 116a has sent the individual record 100. Another benefit can be, for example, cryptographic security. Figure 1AAs shown in , record sender device 116a can sign individual record 100 with record sender signature 112a, and record receiver device 116b can sign modified individual record 100m1 with record receiver signature 112b. A malicious user device that is not record receiver device 116b cannot forge record receiver signature 112b because they do not know the record receiver private key. The malicious user device cannot exchange the modified individual record 100m1 with processing platform 124 because the individual record 100 shows that its recipient is record receiver device 116b and not the malicious user device. Additional or alternative benefits may include, for example, anonymity (there is no need to use an actual legal name, only information associated with the user's identification public key), or non-repudiation (digital signatures can be authenticated using a public key, and the signer cannot deny signing while claiming that his private key remains private). Another benefit may be, for example, irreversibility. Once the record sender device 116a sends the individual record 100 to the record recipient device 116b, the processing platform 124 can refuse to act as directed by the record sender device 116a requesting the processing platform 124 to not act as directed by the content 110 of the individual record. Another benefit can be, for example, that the individual record 100 can include different content 110. In addition, the record sender 102a can enable the record recipient 102b to access a large amount of information, such as a document having an ID stored in the content 110 of the individual record 100, without sending the information directly to the record recipient 102b.

[0090] One receiver of the example

[0091] In some embodiments, a record recipient may receive individual records from a record sender. Figure 4 1 is an interaction diagram illustrating one embodiment of securely exchanging and redeeming individual records created for a record recipient. Record recipient 102b, using record recipient device 116b, can request individual records 100 from record sender 102a by sending a content request 402 to record sender device 116a. Record recipient 102b can send content request 402 to record sender 102a using short-range link (SRL) 122 at interaction 404. Content request 402 can include content (e.g., content B 110b) and the public key 106b of the record recipient device. Content B 110b can include, for example, a request for a document having its document ID stored in content B 110b. In some embodiments, the public key 106b of the record recipient device can uniquely identify record recipient device 116b. In some embodiments, the public key 106b of the record recipient device can uniquely identify record recipient 102b. In some embodiments, the public key 106b can be located in a public record that can be stored in a secure element (SE) 204b.

[0092] Example Partner ID

[0093] refer to Figure 4 At interaction 408, record sender device 116a, using its transaction partner identifier, can confirm the identity of record recipient device 116b via the partner identification. Because content request 402 may have already been electronically sent to record sender device 116a, record sender device 116a may not be certain of the identity of the user device that sent content request 402. Partner identification can be advantageous. For example, using partner identification, record sender device 116a can distinguish content request 402 from record recipient device 116b and malicious users. As another example, through partner identification, a malicious user cannot receive individual records that are not intended for them. As yet another example, through partner identification, a malicious user cannot redeem individual records even after receiving individual records that are not intended for them.

[0094] Example Individual Record Creation

[0095] Figure 5 Schematically illustrates an example individual record created for a record recipient. Figure 4-5 As shown in FIG, after the security element (SE) 204a of the record sender device 116a verifies the authentication information 512a of the record sender, the security element (SE) 204a can sign the individual record 100 at interaction 416. Before signing the individual record 100 at interaction 416, the security element (SE) 204a can require both the block to be digitally signed (e.g., block 105a of the individual record 100) and the authentication of the record sender 102a. Non-limiting examples of authentication can include password authentication, biometric authentication such as fingerprint authentication or iris authentication, biometric data authentication, or any combination thereof. Biometric authentication can utilize a biometric template based on, for example, a fingerprint or eye image. The security element (SE) 204a can implement a biometric fuzzy library for identifying biometric templates.

[0096] An individual record 100 may be a digital object comprising one or more blocks. The individual record 100 may include a block 105a, which may include the public key 106a of the record sender device in the "From field," the public key 106b of the record receiver device in the "To field," the record ID 108, content A 110a, and the record sender's signature 112a for block 105a. The public key 106a of the record sender device may identify the originator of the individual record 100, namely, the record sender device 116a. The public key 106b of the record receiver device may identify the original recipient of the individual record 100, namely, the record receiver device 116b. The content of content A 110a may vary. Content A 110a and content B 110b may be the same, similar, related, or different. Content A 110a may be the same as content B 110b, for example, a specific document. Content A 110a may be similar or related to content B 110b. For example, content B 110b may request access to a document, and content A 110a may grant access to the document. As another example, content B 110b may request access to two documents, and content A 110a may grant access to only two documents. As described above, in the context of cryptocurrency, content A 110a and content B 110b may be the same amount of cryptocurrency. Content A 110a and content B 110b may be similar or related. For example, content B 110b may be a pre-tax amount, and content A 110a may be an after-tax amount. As another example, content B 110b may be a pre-tip amount, and content A 110a may be an after-tip amount.

[0097] refer to Figure 4 At interaction 420, the record sender 102a may send the individual record 100 to the record receiver 102b in a peer-to-peer manner, for example, using a short-range link (SRL). Once the record receiver 102b is in contact, the record receiver 102b may verify the individual record 100 at interaction 424. Verifying the individual record 100 may include authenticating the record sender signature 112a. Authenticating the record sender signature 112a may include using the record sender device's public key 106a to determine whether the record sender signature 112a was created using the record sender device's private key 210. The record sender device's public key 106a may be obtained in a variety of ways. For example, the record sender device's public key 106a may be obtained from the individual record 100. As another example, the record sender device's public key 106a may be obtained from the public record 206 of the record receiver device 116b.

[0098] Example Individual Record Redemption

[0099] refer to Figure 4After successfully verifying the individual record 100, the record recipient device 116b can use its secure element 204b to create and sign the modified individual record 100m1 at interaction 428. Before signing the modified individual record 100m1 at interaction 428, the secure element (SE) 204b can require the block to be digitally signed (e.g., block 105b of the modified individual record 100m1) and the record recipient's authentication information 512b. The modified individual record 100m1 can include block 105a of the individual record 100 and an endorsement block 105b. For example, the endorsement can be a "processing only endorsement" (FPOE) 114, which, together with the record recipient's public key 106b, specifies that the modified individual record 100m1 can only be redeemed by the record recipient 102b. As described above, in the context of cryptocurrency, examples of FPOE approvals include a “deposit only approval” (FDOE), where the processing platform 124 deposits the cryptocurrency amount into the account of the record recipient 102b but will not recognize further approvals to another party.

[0100] After signing the modified individual record 100m1, when the record recipient 102b communicates with the processing platform 124 over, for example, a network, the record recipient 102b can redeem the modified individual record 100m1 with the processing platform 124 at interaction 432. Upon redemption, the service provider 104 operating the processing platform 124 can process the modified individual record 100m1 at interaction 436 by verifying the authenticity of one or more signatures (e.g., the record sender signature 112a and the record recipient signature 112b) in the chain of blocks 105a and 105b in the modified individual record 100m1. Upon successful verification, the processing platform 124 can execute as indicated by the content A 110a of the modified individual record 100m1.

[0101] The sender device 116a may receive an indication that the processing platform 124 has or has not performed as indicated by the content A 110a of the modified individual record 100m1. For example, the processing platform 124 may send an email to the sender device 116a indicating that the processing platform 124 has performed as indicated by the content A 110a of the modified individual record 100m1. As another example, the processing platform 124 may send an electronic message to the sender device 116a indicating that the processing platform 124 has not performed as indicated by the content A 110a of the modified individual record 100m1 because the content A 110a instructed the processing platform 124 to provide a document stored in a repository to the record recipient device 116b and the repository is temporarily or permanently unavailable. As another example, the processing platform 124 may periodically (such as hourly, daily, weekly, monthly, or yearly) provide the sender device 116a with its user record status 306. When one or more conditions are met (such as the record sender device 116 is no longer able to enable another user device to access the document), the processing platform 124 can provide the sender device 116a with its user record status 306 .

[0102] Example Partner ID

[0103] Partner identification can be based on various methods. Non-limiting examples of methods for partner identification include content authorization, knocking, physical indication, beamforming, prior placement, coarse verification, or any combination thereof.

[0104] Sample Content Authorization

[0105] In some embodiments, the partner identification may include content authorization. Using the content authorization, the record sender 102a can issue an intent to exchange individual records to the record recipient device 116b based on the public key 106b in the content request 402. The content of the intent to exchange individual records can vary. For example, the content of the intent to exchange individual records can be empty or contain one or more zero values. After the record recipient device 116b receives the intent to exchange individual records, the record recipient 102b can confirm its status as the recipient of the intent to exchange individual records through non-electronic means. For example, the record recipient 102b can verbally notify the record sender 102a that it has received the intent to exchange individual records. As another example, the record recipient 102b can notify the record sender 102a that it has received the intent to exchange individual records electronically. After confirmation, the content request 402 from the record recipient 102b can be verified, and the record sender 102a can send the individual records 100 with the appropriate content to the record recipient device 116b.

[0106] Example tap

[0107] In some embodiments, partner identification may include tapping. Recording sender device 116a and recording receiver device 116b may each include a motion sensor. Using tapping, recording sender device 116a and recording receiver device 116b may make physical contact. This contact may be measured by the motion sensors of recording sender device 116a and recording receiver device 116b. The relative timing of contact and sending and receiving content request 402 may vary. For example, recording receiver device 116b may send content request 402 upon contact (e.g., upon "tapping"). As another example, recording receiver device 116b may send content request 402 shortly after contact (e.g., within a threshold time of 10 seconds, 20 seconds, 30 seconds, 1 minute, 10 minutes, etc.). If the content request is not sent within the threshold time, partner identification may require tapping the device again.

[0108] The recording sender device 116a can accept the content request 402 based on the temporal concurrence of the contact and the receipt of the content request 402. In some embodiments, the recording receiver device 116b can send a contact signature to the recording sender device 116a. The signature of the contact can be created using the private key of the recording receiver device public key encryption pair. The signature of the contact can be based on the contact measured by the motion sensor of the recording receiver device 116b and the timing of the measured contact. The signature of the contact can be part of the content request 402, or it can be a separate communication from the recording receiver device 116b to the recording sender device 116a. Because the contact can produce an equal and opposite reaction in the recording sender device 116a, the recording sender device 116a can verify the signature of the contact.

[0109] Example Physical Instructions

[0110] In some embodiments, the partner identification may include a physical indication. The recording sender device 116a and the recording receiver device 116b may include an imaging sensor (e.g., a digital camera). The recording sender device 116a and the recording receiver device 116b may be oriented so as to "see" each other using their imaging sensors. The recording receiver device 116b may send an image of the recording sender device 116a that it captured to the recording sender device 116a. The image may be part of the content request 402, or may be a separate communication from the recording receiver device 116b to the recording sender device 116a. Because the image of the recording sender device 116a and the image of the recording receiver device 116b may be opposite to each other, the recording sender device 116a may confirm the identification of the recording receiver device 116b by qualitative or quantitative comparison of the images. For example, if recording sender device 116a "sees" recording recipient device 116b up and to the left, then recording recipient device 116b should appear to be down and to the right in the image of recording sender device 116a captured by recording recipient device 116b.

[0111] In some embodiments, the physical indication may be based on simultaneous observation of the environment by recording sender device 116a and recording receiver device 116b. Recording sender device 116a and recording receiver device 116b may include microphones. The physical indication may be based on simultaneous audio recording of the environment by the microphones of recording sender device 116a and recording receiver device 116b. Both recording sender device 116a and recording receiver device 116b can simultaneously "hear" their environments using their microphones. Recording receiver device 116b may send the audio recording of its environment it captured and the time of the recording to recording sender device 116a. The audio recording may be part of content request 402 or may be a separate communication from recording receiver device 116b to recording sender device 116a. Because the sound recording sent by recording receiver device 116b may be identical or similar to the sound recording simultaneously "heard" by recording sender device 116a, recording sender device 116a can confirm the identity of recording receiver device 116b by qualitatively or quantitatively comparing the sound recordings and the content it "heard." As another example, the physical indication may be based on the recording sender device 116a and the recording recipient device 116b's simultaneous audio observation of each other.As another example, the physical indication may be based on the recording sender device 116a and the recording recipient device 116b's simultaneous visual observation of the environment.

[0112] Example Beamforming

[0113] In some embodiments, partner identification may include beamforming. User device 116 may include a directional (e.g., using beamforming or directional antenna) short-range link (SRL) interface. Record sender device 116a and record receiver device 116b may point their short-range link (SRL) interfaces toward each other. Utilizing beamforming, record sender device 116a may receive content requests 402 from record receiver device 116b, rather than other content requests sent from other directions, such as from a malicious user. Utilizing beamforming, only record sender device 116a, rather than other users, may receive content requests 402 from record receiver device 116b.

[0114] Example first layout

[0115] In some embodiments, the partner identification may include prior arrangement. For example, the record sender device 116a may have prior knowledge of the public key 106b of the record recipient device before receiving the content request 402 from the record recipient device 116b. As another example, the record sender device 116a may have prior knowledge of the public key 106b of the record recipient device to which the content request (e.g., content request 402) will be sent. For example, the sender 102a may have previously informed the recipient 102b that the record will be sent. The recipient 102b may utilize a user interface (UI) on the recipient device 116b to provide an indication that the expected record is from the sender device 116a (e.g., within a threshold time period).

[0116] Example rough verification

[0117] In some embodiments, the partner identification may include a rough verification. For example, the public record 206 may contain an identification string, such as BigBoxStore, which may be used for rough verification of the content request 402. As an example where the recipient 102b is a merchant, the record recipient 102b may be identified as the merchant in the public record 206. This identification may be associated with an indication (e.g., a bit) in the public record 206 that the identification has been verified by the processing platform 124. This verified identification may be distinguished from an assigned or self-provided identification by the user.

[0118] Sample Content and Exchange

[0119] The content 110 of an individual record 100 can vary. For example, the content 110 can include instructions for providing a document whose document ID is stored in the content 110 to the record recipient 102b. As another example, the content 110 can include instructions for paying a specific number of currency units (e.g., U.S. dollars) to the record recipient 102b. The payment can be in the form of, for example, a national currency, a fiat currency, a commodity or commodity currency, a cryptocurrency, a financial product or security (e.g., a stock or bond), or any combination thereof.

[0120] The content 110 of an individual record 100 may include software code. When certain conditions are met, the processing platform 124 may execute the software code. The conditions may be time-based, such as when the record recipient 102b redeems the individual record 100 containing the software code. The content 110 may include self-executing software code. When certain conditions are met, the self-executing code may automatically execute. In some embodiments, for example, when certain conditions such as fraud are detected, the user may be able to prevent or delay the execution of the software code. In some embodiments, the user may not be able to prevent or delay the execution of the software code.

[0121] The content 110 of an individual record 100 may include contractual obligations or rights (e.g., smart contracts) between a sender and a receiver. For example, a record receiver 102b may be contractually obligated to perform a service, such as backing up the record sender's computer infrastructure, and may have a contractual right to receive payment for the service; and a record sender 102a may be contractually obligated to pay a record receiver 102b for the service and may have a contractual right to receive payment for the service performed by the record receiver. Smart contracts may be between individual users, partners, companies, or groups. Smart contracts may involve the recurring execution of software code. Software code may include software code that executes when certain conditions are met. As an example, software code may include software code for backing up or security scanning the receiver's computer infrastructure. Software code may execute when a condition occurs (e.g., transferring a monthly payment of cryptocurrency to the sender). In some embodiments, a smart contract may involve recurring payments when certain conditions are met. For example, a smart contract may require record receiver 102b to back up the record sender's computer infrastructure on a regular basis (such as weekly). The record sender 102a is contractually obligated under the smart contract to periodically pay the record receiver 102b when the conditions for periodic execution are met.

[0122] The content 110 may involve third-party escrow. For example, a record sender 102a and a record receiver 102b may wish to exchange code, such as software code. After providing the first software code to a repository (e.g., processing platform 124), the record sender 102a may provide the first individual record 100 to the record receiver 102b and, if a first condition is met, instruct the repository to provide the first software code to the record receiver 102b. Similarly, the original record receiver 102b may provide the second individual record 100m1 to the original record sender 102a and, if a second condition is met, instruct the repository to provide the second software code to the original record sender 102a. The first condition and the second condition may be time-based. The first condition and the second condition may be the same or different.

[0123] In some embodiments, a record sender 102a may provide an individual record 100 to a record receiver 102b as part of an exchange. For example, the content 110 of the individual record may instruct the processing platform 124 to debit the record sender's account for a first amount and credit the record receiver's account for a second amount. The account debits and credits may accompany the record receiver 102b providing, for example, a product or some code to the record sender 102a.

[0124] Example two receivers

[0125] Example first content request

[0126] In some embodiments, after receiving an individual record from a record sender, the record recipient may send the received individual record to a subsequent record recipient. Figure 6 is an interaction diagram illustrating one embodiment of securely exchanging and redeeming individual records created for two record recipients. Figure 4-5 As shown in FIG, a first record recipient 102b using a first record recipient device 116b may request an individual record from a first record sender 102a by sending a first content request 402 to the first record sender device 116a at interaction 404. The first content request 402 may include content B 110b and the first public key 106b of the first record recipient device.

[0127] At interaction 408, the first record sender device 116a can confirm the identity of the first record recipient device 116b through the partner identity. After the secure element (SE) 204a of the first record sender device 116a verifies the authentication information 512a of the first record sender, the secure element (SE) 204a can sign the individual record 100 at interaction 416.

[0128] Figure 7 Schematically illustrates example individual records created for two record recipients. Figure 6-7 As shown in FIG, an individual record 100 may be a digital object including a block 105a. The block 105a may include a first public key 106a of a first record sender device in a "from field", a first public key 106b of a first record recipient device in a "to field", a record ID 108, content A 110a, and a first record sender signature 112a of the block 105a.

[0129] At interaction 420, the first record sender 102a may send the individual record 100 to the first record recipient 102b, for example, in a peer-to-peer manner using a short range link (SRL) 122. Once with the first record recipient 102b, the first record recipient 102b may verify the individual record 100 at interaction 424.

[0130] Example Second Content Request

[0131] refer to Figure 6 , a second record recipient, using a record recipient device, may request an individual record from a record sender by sending a content request to the record sender device using a short range link (SRL) 122 at interaction 604. For example, a second record recipient 102c, using a second record recipient device 116c, may request an individual record from a first record recipient 102b by sending a second content request 602 to the first record recipient device 116b. The first record recipient 102b may be the second record sender, and the first record recipient device 116b may be referred to as the second record sender device. The second content request 602 may include content (e.g., content C 110c) and the public key 106c of the second record recipient device.

[0132] At interaction 608, the second record sender device 116b may confirm the identity of the second record recipient device 116c using the partner identity. After the secure element (SE) 204b of the second record sender device / first record recipient device 116b verifies the second record sender's authentication information 512b, the second record sender device 116b may decide to send the first modification record 100m1 to the second record recipient device 116c after signing it for various reasons and purposes. For example, the second record recipient 102c may be an assignee of the second record sender 102b. Instead of executing the first record recipient / second record sender 102b as indicated by content A 110a, the processing platform 124 may execute the second record recipient 102c. Content A 110a, content B 110b, and content C 110c may be the same, similar, related, or different.

[0133] The secure element (SE) 204b may sign the first modified individual record 100m1 at interaction 612. Signing the first modified individual record 100m1 may include adding a block (e.g., block 105b) to the individual record 100 to create the first modified individual record 100m1. Block 105b of the first modified individual record 100m1 may include the second public key 106c of the second record recipient device and the second record sender signature / first record recipient signature 112b of block 105b.

[0134] At interaction 616, the second record sender 102b may send the first modified individual record 100m1 to the second record recipient 102c in a peer-to-peer manner, e.g., using a short range link (SRL) 122. Once with the second record recipient 102c, the second record recipient 102c may verify the first modified individual record 100m1 at interaction 620. Verifying the first modified individual record 100m1 may include, e.g., authenticating the first record sender signature 112a and the second record sender signature 112b using the public key 106a of the first record sender device and the public key 106b of the second record sender device in the first modified individual record 100m1.

[0135] Example Individual Record Redemption

[0136] refer to Figure 6 After successfully verifying the first modified individual record 100m1, the second record recipient device 116c can use its secure element (SE) 204c to create and sign a second modified individual record 100m2 at interaction 624, where m indicates that the individual record 100 has been modified and m2 indicates that the individual record 100 has been modified at least twice. Before signing the second modified individual record 100m2, the secure element (SE) 204c can require both the block to be digitally signed (e.g., block 105c of the second modified individual record 100m2) and the second record recipient's authentication information 512c. The second modified individual record 100m2 can include block 105a of the individual record 100, block 105b of the first modified individual record, and an endorsement block 105c. For example, the endorsement can be a "For Processing Only Endorsement" (FPOE) 114, which, together with the record recipient device's public key 106c, specifies that the second modified individual record 100m2 can only be redeemed by the second record recipient 102c.

[0137] After signing the second modified individual record 100m2, the second record recipient 102c can redeem the second modified individual record 100m2 with the processing platform 124 at interaction 628. Upon redemption, the service provider 104 operating the processing platform 124 can process the second modified individual record 100m2 at interaction 632 by verifying the authenticity of one or more signatures in the chain of blocks 105a, 105b, and 105c in the second modified individual record 100m2. The verified signatures may include the first record sender signature 112a, the second record sender signature / first record recipient signature 112b, and the second record recipient signature 112c. Upon successful verification, the processing platform 124 can proceed as indicated by the content A 110a of the second modified individual record 100m1.

[0138] Example N receivers

[0139] In some embodiments, after receiving an individual record from a record sender, the record receiver can send the received individual record to a subsequent record receiver. The subsequent record receiver can, in turn, send the received individual record to another record receiver. The final record receiver can exchange the received individual record with the processing platform. The number N of senders / receivers in the record chain can be 2, 3, 4, 5, 6, 10, 20, 100, or more.

[0140] Example first content request

[0141] Figure 8 Schematically illustrates example individual records created for multiple record recipients. Figure 4-7 As shown in FIG, a first record recipient 102b using a first record recipient device 116b may request an individual record from a first record sender 102a by sending a first content request to the first record sender device 116a using a short range link (SRL) 122. The first content request may include content B and the first public key 106b of the first record recipient device.

[0142] The first record sender device 116a can confirm the identity of the first record recipient device 116b through the partner identity. After the secure element (SE) 204a of the first record sender device 116a verifies the authentication information 512a of the first record sender, the secure element (SE) 204a can sign the individual record 100 at interaction 416.

[0143] Individual record 100 may be a digital object including block 105a. Block 105a may include a first public key 106a of a first record sender device in a "from field," a first public key 106b of a first record recipient device in a "to field," a record ID 108, content A 110a, and a first record sender signature 112a of block 105a.

[0144] The first record sender 102a can send the individual record 100 to the first record receiver 102b using a short range link (SRL) 122, for example, in a peer-to-peer manner. Once the first record receiver 102b is

[0145] The first record recipient 102b can then verify the individual record 100.

[0146] Example Second Content Request

[0147] refer to Figure 8 , a second record recipient, using a record recipient device, can request an individual record from a record sender by sending a content request to the record sender device using a short-range link (SRL) 122. For example, a second record recipient 102c, using a second record recipient device 116c, can request an individual record from a second record sender 102b by sending a second content request to the second record sender device 116b using a short-range link (SRL) 122. The first record recipient 102b can be the second record sender, and the first record recipient device 116b can be referred to as the second record sender device. The second content request can include content C and the public key 106c of the second record recipient device.

[0148] The second record sender device / first record receiver device 116b can confirm the identity of the second record receiver device 116c through the partner identity. After the secure element (SE) 204b of the second record sender device / first record receiver device 116b verifies the authentication information 512b of the second record sender, the second record sender device 116b can decide to send the first modification record 100m1 to the second record receiver device 116c after signing.

[0149] The secure element (SE) 204b of the second record sender device 116b may sign the first modified individual record 100m1 at interaction 612. Signing the first modified individual record 100m1 may include adding a block (e.g., block 105b) to the individual record 100 to create the first modified individual record 100m1. Block 105b of the first modified individual record 100m1 may include the second public key 106c of the second record recipient device of block 105b and the second record sender signature / first record recipient signature 112b.

[0150] The second record sender 102b can send the first modified individual record 100m1 to the second record receiver 102c in, for example, a peer-to-peer manner using a short-range link (SRL) 122. Once with the second record receiver 102c, the second record receiver 102c can verify the first modified individual record 100m1. Verifying the first modified individual record 100m1 can include authenticating the first record sender signature 112a and the second record sender signature 112b using, for example, the public key 106a of the first record sender device and the public key 106b of the second record sender device in the first modified individual record 100m1.

[0151] Example third content request

[0152] refer to Figure 8 , a third record recipient, using a third record recipient device, may request an individual record from the record sender by sending a content request to the record sender device using a short-range link (SRL) 122. For example, a third record recipient, using a third record recipient device, may request an individual record from the third record sender by sending a third content request to a third record sender device 116c using a short-range link (SRL) 122. The second record recipient 102b may be the third record sender, and the second record recipient device 116b may be referred to as the third record sender device. The third content request may include the content and the public key of the third record recipient device.

[0153] The third record sender device 116c can confirm the identity of the third record recipient device through the partner identity. After the secure element (SE) 204c of the third record sender device / second record recipient device 116c verifies the authentication information 512c of the third record sender, the third record sender device can send the second modification record 100m2 to the third record recipient device after signing.

[0154] The secure element (SE) 204c may sign the second modified individual record 100m2 at interaction 624. Signing the second modified individual record 100m2 may include adding a block (e.g., block 105c) to the first modified individual record 100m1 to create the second modified individual record 100m2. The block 105c of the second modified individual record 100m2 may include the third public key 106c of the second record recipient device of the block 105c and the third record sender signature / second record recipient signature 112c.

[0155] The third record sender 102c can send the second modified individual record 100m2 to the third record receiver in, for example, a peer-to-peer manner using a short-range link (SRL) 122. Once with the third record receiver, the third record receiver can verify the second modified individual record 100m2. Verifying the second modified individual record 100m2 can include authenticating the first record sender signature 112a, the second record sender signature / first record receiver signature 112b, and the third record sender signature / second record receiver signature 112c using, for example, the public keys 106a, 106b, and 106c of the first record sender device, the second record sender device, and the third record sender device in the second modified individual record 100m2.

[0156] Example nth content request

[0157] refer to Figure 8 , an nth record recipient using an nth record recipient device may request an individual record from an nth record sender by sending an nth content request to the nth record sender device using a short range link (SRL) 122. The nth record sender may be the (n-1)th record recipient, and the (n-1)th record recipient device may be referred to as the nth record sender device. The nth content request may include content and a public key of the nth record recipient device.

[0158] The nth record sender device can confirm the identity of the nth record receiver device through the partner identity. After the secure element (SE) of the nth record sender device / the (n-1)th record receiver device verifies the authentication information of the nth record sender, the nth record sender device can send the (n-1)th modification record 100m(n-1) to the nth record receiver device after signing, where m indicates that the individual record 100 has been modified, and m(n-1) indicates that the individual record 100 has been modified at least (n-1) times.

[0159] The secure element (SE) of the nth record sender device may sign the (n-1)th modified individual record 100m(n-1). Signing the (n-1)th modified individual record 100m(n-1) may include adding block 105(n-1) to the (n-2)th modified individual record to create the (n-1)th modified individual record 100m(n-1). Block 105(n-1) of the (n-1)th modified individual record 100m(n-1) may include the nth public key 106n of the nth record receiver device of block 105(n-1) and the nth record sender signature / (n-1)th record receiver signature 112(n-1).

[0160] The nth record sender may send the (n-1)th modified individual record 100m(n-1) to the nth record receiver in, for example, a peer-to-peer manner using a short range link (SRL) 122. Once with the nth record receiver, the nth record receiver may verify the (n-1)th modified individual record 100m(n-1). Verifying the (n-1)th modified individual record 100m(n-1) may include authenticating the first record sender signature 112a, the second record sender signature 112b, ..., and the (n-1)th record sender signature 112(n-1) using, for example, the public keys of the first record sender device 112a, the second record sender device 112b, the third record sender device 112c, ..., and the nth record sender device in the (n-1)th modified individual record 100m(n-1).

[0161] Example Individual Record Redemption

[0162] refer to Figure 8 After successfully verifying the (n-1)th modified individual record 100m(n-1), the nth record recipient device can use its secure element to create and sign the nth modified individual record 100mn, where m indicates that the individual record 100 has been modified and mn indicates that the individual record 100 has been modified at least N times. Before signing the nth modified individual record 100MM, the secure element (SE) can require the block to be digitally signed (e.g., block 105n of the nth modified individual record 100mn) and the authentication information of the nth record recipient. The nth modified individual record 100mn may include an approval block 105n. For example, the approval can be a "processing only approval" (FPOE) 114, which, together with the public key in the nth modified individual record 100mn, specifies that the nth modified individual record 100mn can only be redeemed by the nth record recipient.

[0163] After signing the nth modified individual record 100mn, the nth record recipient can redeem the nth modified individual record 100mn with the processing platform. Upon redemption, the service provider operating the processing platform can process the nth modified individual record 100mn by verifying the authenticity of the signatures in the chain of blocks 105a, 105b, 105c, ..., 105(n-1), and 105n in the nth modified individual record 100mn. Upon successful verification, the processing platform 124 can execute as indicated by the content A 110a of the nth modified individual record 100mn.

[0164] Example interaction between an agent and a record receiver

[0165] Example from record sender to proxy

[0166] In some embodiments, the agent can act on behalf of the recipient of record. In the example scenario of a merchant or principal, the merchant or principal can be the recipient of record, and the agent can be an attendant at a checkout lane or payment kiosk. In another example scenario, the agent can be a self-service checkout machine or self-service terminal that allows customers to process their own purchases from the merchant. The attendant typically uses a point of sale (POS) device such as a cash register to receive payment sent from the customer's electronic device 116a to accept payment on behalf of the merchant when the customer checks out.

[0167] Figure 9 1 is an interaction diagram illustrating one embodiment of securely exchanging and redeeming individual records involving an agent and a recipient. Agent 102d of record recipient 102b, using agent device 116d, may request an individual record from record sender 102a by sending a content request 402 to record sender device 116a using short range link (SRL) 122 at interaction 404. Content request 402 may include content B 110b and the record recipient's public key 106b.

[0168] A record receiver 102b (e.g., a merchant) may have or be associated with one or more agents 102d (e.g., ten agents (e.g., inspectors)). The relationship between agents 102d and agent devices 116d may vary. For example, some agents 102d may share a single agent device 116d, and the agent device 116d may support multiple logins for authorized agents 102d. As another example, some agents 102d may not share an agent device 116d. As another example, some agents 102d may each have more than one agent device 116d. Some agents 102d may have their own agent device 116d.

[0169] Record receiver 102b may have or be associated with one or more public keys 106b. For example, record receiver 102b may have one public key 106b. As another example, record receiver 102b may have one public key 106b for each location (e.g., a physical location or a virtual location). A physical location may be a store location or an exchange location. As another example, record receiver 102b may have one public key 106b for each external device.

[0170] The agent 102d can advantageously interact with external devices that are not part of the systems and methods of the present disclosure. Non-limiting examples of external devices include cellular phones, tablet computers, e-readers, smart watches, head-mounted augmented, virtual or mixed reality display systems, wearable display systems, computers, server computers, point-of-sale systems, or cash registers. The external device can be fixed to a certain location, such as a physical location (such as a store location). The external device can be part of infrastructure (e.g., existing infrastructure).

[0171] The management of the public key 106b can vary. For example, the record recipient 102b can use the record recipient device 116b or one or more other computers operated by it to manage the public key 106b itself. As another example, the service provider 104 can manage the record recipient's public key 106b as a service similar to "Software as a Service" (SaaS).

[0172] Advantageously, the agent 102d cannot exchange the individual record 100 or the first modified individual record 100m1 with the processing platform 124 because the block 105a contains the public key 106b of the record recipient device 116b, rather than the public key 106d of the agent device 116d.

[0173] At interaction 408, the record sender device 116a may confirm the identity of the proxy device 116d or the identity of the record receiver device 116b through the partner identity. After the secure element (SE) 204a of the record sender device 116a verifies the authentication information 512a of the record sender, the secure element (SE) 204a may sign the individual record 100 at interaction 416.

[0174] Figure 10 Schematically illustrates example individual records involving agents and record recipients. Figure 9-10 As shown in FIG, an individual record 100 may be a digital object including a block 105a. The block 105a may include a public key 106a of the record sender device in a "from field," a public key 106b of the record receiver device in a "to field," a record ID 108, content A 110a, and a signature 112a of the record sender of the block 105a.

[0175] At interaction 420, the record sender 102a may use the short range link (SRL) 122 to send the individual record 100 to the proxy 102d, for example, in a peer-to-peer manner. Once with the proxy 102d, the proxy 102d may verify the individual record 100 at interaction 424. In some embodiments, the proxy device 116d may connect to a network, such as the network 118, via the dedicated network of the record receiver 102b. Using this connection to the network 118, the proxy device 116d may verify the individual record 100 using the processing platform 124. In some embodiments, the proxy device 116d may access the network instead of the record sender device 116a.

[0176] Example from proxy to record receiver

[0177] refer to Figure 9 In some embodiments, the secure element (SE) 204d of the proxy device 116d may create and sign the first modified individual record 100m1 at interaction 904 before sending the first modified individual record 100m1 to the record recipient 102b at interaction 908. Signing the first modified individual record 100m1 may include adding the block 105b to the first individual record 100 to create the first modified individual record 100m1. The block 105b of the first modified individual record 100m1 may include the public key 106d of the proxy device of the block 105b, an endorsement, and a proxy signature 112d. For example, the endorsement may be "Handled by Endorsement" (HBE) 114a. “Handled by Endorsement” (HBE), the proxy device's public key 106d and the proxy signature 112d, along with the record sender device's public key 106a and the record recipient device's public key 106b, may indicate that the proxy device 116d may receive the individual record 100 from the record sender device 116a on behalf of the record recipient 102b.

[0178] At interaction 908, the agent 102d may send the first modified individual record 100m1 to the record recipient 102b directly over the communication link or indirectly. For example, the agent 102d may send the first modified individual record 100m1 to the record recipient 102b in, for example, a peer-to-peer manner using a short range link (SRL) 122. As another example, the agent 102d may send the first modified individual record 100m1 to the record recipient 102b over a network (e.g., network 118). The configuration of the record recipient device 116b may vary. For example, the record recipient device 116b may be connected to Figure 2 The user equipment 116 shown in Figure 3 The processing platform 124 shown in FIG. 1 , or any combination thereof, may be similar or identical to the processing platform 124 shown in FIG. 1 .

[0179] In some embodiments, once the record recipient 102b is present, the record recipient 102b can verify the first modified individual record 100m1. Verifying the first modified individual record 100m1 can include determining whether the public key 106d associated with the proxy device is associated with the authorized agent 102d. The record recipient 102b can reject individual records received by unauthorized personnel or without the approval of the authorized agent. Verifying the first modified individual record 100m1 can include authenticating the record sender signature 112a and the proxy signature 112d using, for example, the public key 106a of the record sender device and the public key 106d of the proxy device in the first modified individual record 100m1.

[0180] Example Individual Record Redemption

[0181] refer to Figure 9 , the record recipient device 116b may use, for example, its secure element (SE) 204b to create and sign the second modified individual record 100m2. In some embodiments, before signing the second modified individual record 100m2 at interaction 912, the secure element (SE) 204b of the record recipient device 116b may require both the block to be digitally signed (e.g., block 105c of the second modified individual record 100m2) and authentication information of the record recipient or an authorized person working for the record recipient 102b.

[0182] The content of the second modified individual record 100m2 can vary. For example, the second modified individual record 100m2 can include block 105b of the first modified individual record 100m1. As another example, the second modified individual record 100m2 may not include block 105b of the first modified individual record 100m1. The second modified individual record 100m2 may include an endorsement block 105c. For example, the endorsement can be a "processing only endorsement" (FPOE) 114b, which, together with the record recipient's public key 106b, specifies that the second modified individual record 100m2 can only be redeemed by the record recipient 102b.

[0183] After signing the second modified individual record 100m2, the record recipient 102b can redeem the second modified individual record 100m2 with the processing platform 124 at interaction 916. Upon redemption, the service provider 104 operating the processing platform 124 can process the second modified individual record 100m2 at interaction 920 by verifying the authenticity of one or more signatures in the chain of blocks 105a, 105b, and 105c in the second modified individual record 100m2. For example, the processing platform 124 can verify the record sender signature 112a, the proxy signature 112d, and the record recipient signature 112b. Upon successful verification, the processing platform 124 can proceed as indicated by the content A 110a of the second modified individual record 100m2.

[0184] In some embodiments, the processing platform 124 may notify the record recipient device 116b that the second modified individual record 100m2 has been successfully processed at interaction 924. The record recipient device 116b may, in turn, notify the proxy device 116d at interaction 928 that the modified individual record 100m1 has been successfully processed using, for example, "Handled by Endorsement" (HBE).

[0185] The agent device 116d may remove the modified individual record 100m1 stored in the agent device 116d individual record container 202 as one of the unredeemed individual records 208. The agent device 116d may input the content A110a of the personal record 100 into the external device, accompanied by a message such as "record cleared," for example.

[0186] Example scenarios for buyer / payer and seller / payee

[0187] In some embodiments, the content request 402 may be a payment request 402 including an amount B 110b. The individual record 100 may include a digital check 100. The content A 110a of the individual record 100 may include an amount A 110a. Amount B and amount A may be the same, similar, or different. The amount may be a fiat currency, a cryptocurrency (e.g., Bitcoin), a financial security (e.g., a stock or bond), or any type of real, intangible, or virtual asset. The record ID 108 may include a check ID 108. Creating the individual record 100 may include creating a digital check 100, and creating a modified individual record 100m1 may include creating a modified digital check 100m1. The "processing only authorization" (FPOE) may be a "deposit only authorization" (FDOE).

[0188] Record sender 102a may be a buyer or payee 102a, and record receiver 102b may be a seller or payee 102b. Record sender device 116a and record receiver device 116b may be a buyer device or payee device 116a and a seller device or payee device 116b. An exchange involving individual records 100 may involve record sender 102a purchasing, for example, a computer from record receiver 102b, and record sender 102a paying for the purchase with a digital check 110, where amount A 110a is the purchase price of the computer. Figure 9 The agent 102d shown in FIG may be a checker or a cashier 102d. Figure 9 The record recipient 102b shown in FIG may be a merchant 102b. The external device may be a point of sale system or a cash register.

[0189] The public records 206 in the public record container 240 may be the public ledger 206 in the public ledger container 240. The unredeemed individual records 208 stored in the individual record container 202 may be the unredeemed checks 208 stored in the wallet 202.

[0190] The processing platform 124 can process the payment. The processing platform 124 can perform actions for the record recipient 102b, as indicated by the content 110 of the modified individual record 100m1, including providing the amount A 110a to the payee device, as indicated by the modified digital check 100m1. The central record container 332 can be a central ledger, and the central record 302 can include a public ledger. The user record status 306 can include the user's current balance 306.

[0191] Examples of costs / fees

[0192] Third parties other than user 102a or 102b and service provider 104 may charge third-party fees for certain activities. For example, a third party that maintains documents, such as those having their document IDs stored in content 110 of individual record 100, may charge processing platform 124 an access fee for accessing these documents. Processing platform 124, in turn, may charge user 102a or 102b an access fee.

[0193] The processing platform 124 may charge transaction fees for certain transactions. For example, the processing platform 124 may charge a transaction fee for processing an individual record 100 or for maintaining a user account. As another example, the processing platform 124 may charge a transaction fee for accessing documents as indicated by the content 110 of the individual record 100. As another example, the processing platform 124 may charge a transaction fee to provide a record recipient with access to a document having its document ID stored in the content 110 of the individual record 100. The processing platform 124 may charge different fees to different users for the same or similar transactions (such as accessing the same or similar documents). As another example, the processing platform 124 may charge a fee to a user for undesirable behavior, such as granting other users access to documents when they should not. The transaction fee may be based on the transaction size or the number of transactions, may be fixed, or any combination thereof.

[0194] Processing platform 124 can use agent 102d to charge record recipient 102b, for example, a maintenance fee for the key pair. For example, the maintenance fee can be charged once when processing platform 124 provides the key pair to record recipient 102b, or can be charged periodically. The fee can be fixed, negotiated, discounted, preferential, exclusive, or any combination thereof.

[0195] Example query approval

[0196] In some embodiments, a record receiver may be connected to a network even though the record sender may not be connected. For example, a record sender 102a and a record receiver 102b may exchange individual records 100 at the record sender's place of business. A record receiver device 116b operated by record receiver 102b may connect to network 118 via a dedicated network operated by, for example, record receiver 106b. And a record sender device 116a operated by record sender 102a may not be able to connect to network 118 due to, for example, poor cellular connectivity. Before accepting an exchange involving an individual record 100, when the individual record 100 is electronically transferred to and exchanged with processing platform 124, record receiver 102b may electronically query processing platform 124 regarding whether processing platform 124 will execute the content indicated in content A 110a of the individual record 100. For example, content A 110a may enable record receiver device 102b to access a document having its document ID stored in content A 110a. The recipient 102b may use, for example, a "Query Entitlement" (QE) of the processing platform 124 to verify that the record sender 102a can provide access to the document to the record recipient 102b.

[0197] Figure 11is an interaction diagram illustrating one embodiment of securely exchanging and redeeming individual records involving query approval. Figure 4-5 As shown in FIG, record recipient 102b using record recipient device 116b may request individual record 100 from record sender 102A by sending content request 402 to record sender device 116A using short range link (SRL) 122 at interaction 404. Content request 402 may include content B 110b and the public key 106b of the record recipient device.

[0198] At interaction 408, the record sender device 116A may confirm the identity of the record recipient device 116b through the partner identity. After the secure element (SE) 204A of the record sender device 116A verifies the record sender's authentication information 512A, the secure element 204A may sign the individual record 100 at interaction 416. Before signing the individual record 100 at interaction 416, the secure element 204A may require the block to be digitally signed (e.g., block 105A of the individual record 100) and the authentication of the record sender 102A.

[0199] Figure 12 Schematically illustrates an example individual record related to query approval. Figure 11-12 As shown in FIG, an individual record 100 may be a digital object comprising one or more blocks. The individual record 100 may include a block 105a. The block 105a may include a public key 106a of a record sender device in a "from field", a public key 106b of a record receiver device, a record ID 108 in a "to field", content A 110a, and a signature 112a of the record sender of the block 105a.

[0200] like Figure 11 As shown in FIG, at interaction 420, the record sender 102a may send the individual record 100 to the record recipient 102b using a short range link (SRL) 122, for example, in a peer-to-peer manner. Once with the record recipient 102b, the record recipient 102b may verify the individual record 100 at interaction 424. Verifying the individual record 100 may include authenticating the record sender signature 112a using, for example, the public key 106a of the record sender device in the individual record 100.

[0201] Example query

[0202] refer to Figure 11, after successfully verifying the individual record 100, the record recipient device 116b can use its security element 204b to create and sign a first modified individual record 100m1. Before signing the first modified individual record 100m1 at interaction 1104, the security element (SE) 204b can require the block to be digitally signed (e.g., block 105b of the modified individual record 100m1) and the record recipient's authentication information 512b. The first modified individual record 100m1 may include blocks 105a and 105b of the individual record 100. Block 105b may include an acknowledgment of block 105b and a record recipient signature 112b. For example, the acknowledgment may be a "query acknowledgment" (QE) 114a. The "query acknowledgment" 114a may indicate that the first modified individual record is for query, not for redemption. If one or more conditions are met, "query authorization" 114a may indicate or include a request by the recipient device 102b to determine whether the processing platform 124 will perform the query indicated by the content A 110a of the first modified individual record 100m1. Non-limiting examples of conditions include a second modified individual record 100m2 based on an individual record 100 having a "Process Only Authorization" (FPOE) electronically communicated and redeemed by the record recipient 102b with the processing platform 124, the record sender 102a or record recipient 102b having performed a task, or the occurrence of an event such as receiving authorization from another user or non-user, or a specific time. In some embodiments, the processing platform 124 may provide sourcing information and cost splitting information to the record recipient 102b.

[0203] After signing the first modified individual record 100m1, the record recipient 102b may send the modified individual record 100m1 to the processing platform 124 at interaction 1108. After processing the query approval 114a in the first modified individual record 100m1 at interaction 1112, the processing platform 124 may provide the query result to the record recipient 102b at interaction 1116. For example, the query result may indicate that the processing platform 124 will execute or not execute as indicated by the content A 110a and the timing of execution of the first modified individual record 100m1. As another example, the query result may indicate that the processing platform 124 will execute as indicated by the content A 110a if one or more conditions are met. As another example, the query result may include source information or cost.

[0204] Example Individual Record Redemption

[0205] refer to Figure 11Given the query results, record recipient 102b can decide whether to accept the exchange involving individual record 100 with record sender 102a. If record recipient 102b decides to accept the exchange of individual record 100 and redeem it with processing platform 124, record recipient device 116b can use its secure element 204b to create and sign a second modified individual record 100m2. Before signing the modified individual record 100m1 at interaction 428, secure element (SE) 204b can request the block to be digitally signed (e.g., block 105c of the second modified individual record 100m2) and record recipient authentication information 512b. Modified individual record 100m1 may include block 105a of the individual record 100 and an approval block 105c. Block 105c may include the approval of block 105c and record recipient signature 112b'. For example, the endorsement may be a "Processing Only Endorsement" (FPOE) 114b, which specifies that the modified individual record 100m1 may only be redeemed by the record recipient 102b. In some embodiments, the second modified individual record 100m2 may include the block 105b of the first modified individual record 100m1.

[0206] After signing the second modified individual record 100m2, the record recipient 102b can redeem the second modified individual record 100m2 with the processing platform 124 at interaction 432. Upon redemption, the service provider 104 operating the processing platform 124 can process the second modified individual record 100m2 at interaction 436 by verifying the authenticity of one or more signatures in the chain of blocks 105a and 105c in the modified individual record 100m1. The authenticated signatures may include the record sender signature 112a and the second record recipient signature 112b. Upon successful verification, the processing platform 124 can proceed as indicated by the content A 110a of the second modified individual record 100m2.

[0207] The timing at which an exchange involving an individual record 100 is considered complete may vary in different implementations. For example, the exchange involving the individual record 100 may be considered complete when the record receiver 102b accepts the exchange involving the individual record 100 with the record sender 102a after receiving the query result at interaction 1116. The query result may indicate that the processing platform 124 will execute as indicated by the content A 110a of the first modified individual record 100m1 and the timing of execution. As another example, the exchange involving the individual record 100 may be considered complete when the service provider 104 operating the processing platform 124 successfully processes the second modified individual record 100m2 at interaction 436. The processing platform 124 may verify the authenticity of one or more signatures in the chain of blocks 105a and 105c in the modified individual record 100m1. As another example, the exchange involving the individual record 100 may be considered complete when the central platform 124 executes as indicated by the content A 110a of the second modified individual record 100m2.

[0208] Distribution of example public records

[0209] Sample update frequency

[0210] The processing platform 124 may update the public record 206 from time to time or at regular intervals by sending the updated public record 206 to one or more user devices. In some embodiments, the regular interval may be time-based, such as hourly, daily, weekly, or monthly.

[0211] In some embodiments, the regular interval may be based on the number or percentage of users or user devices that have changed status. Non-limiting examples of changed status include a device becoming a user device 116, a device 116 no longer being a user device, a user 102a or 102b or user device 116 being added to or removed from a demerit list (demerits are described below), a change in the demerit status of the user 102a or 102b or user device 116a or 116b on the demerit list, such as an increase or decrease in demerit points, or a user 102a or 102b or user device 116 being added to or removed from a blacklist. For example, the number of users or user devices 116 that have changed status may be 100. As another example, the percentage of users or user devices 116 that have changed status may be 1% of all users or user devices 116.

[0212] In some embodiments, the regular interval may be based on a number of error events, e.g., 100 error events, detected by the error manager of processing platform 124 or determined by the error manager of user device 116. For example, an error event may be the receipt by the processing platform of an individual record with a "Malicious Code" (MC) designation (described further below).

[0213] Example public records received from the processing platform

[0214] Figure 13 is an interaction diagram illustrating one embodiment of distributing a public record 206 from a processing platform 124. At interaction 1304, the processing platform 124, using, for example, a public record generator, may create a public record message 1308. Figure 14 An example public record for distribution is schematically shown. Figure 13-14 , the public record message 1308 may include the updated public record 206, which may include the updated public key of the device 214. The public record message 1308 may include the demerit list 1402 and the blacklist 1404. The processing platform 124 may sign the public record message 1308 by adding a service provider signature 1312 to the public record message 1308. The service provider signature 1312 may be created by the public record generator 340 using a service provider private key 348 owned by the service provider.

[0215] The public record distributor of processing platform 124 can distribute public record messages 1308 to user devices. Processing platform 124 can distribute public record messages 1308 to user devices sequentially. For example, processing platform 124 can first distribute public record messages 1308 to record recipient device 102b at interaction 1316a, and then distribute public record messages 1308 to record sender device 102a at interaction 1316b. This sequential distribution can advantageously avoid traffic congestion and bandwidth bottlenecks. Public record recipients of record sender device 102a and record recipient device 102b can receive public record messages 1308 from processing platform 124.

[0216] The processing platform 124 may distribute the public record messages 1308 to one or more user devices 116 simultaneously or close in time. For example, the public record distributor may distribute the public record messages 1308 to 100 user devices 116 simultaneously. As another example, the public record distributor 344 may distribute the public record messages 1308 to 10% of the user devices 116 simultaneously. As another example, the public record distributor 344 may distribute the public record messages 1308 to the user devices 116 in batches of 100.

[0217] At interaction 1320, the secure element (SE) 130b of the record recipient device 102b can verify the authenticity of the public record message 1308. Verifying the authenticity of the public record message 1308 can include verifying the service provider signature 1308. The service provider signature 1308 can include using the service provider public key 212 stored in the secure element 204b to determine whether the service provider signature 1308 has been created using the service provider private key 348. Similarly, at interaction 1328, the secure element 204a of the record sender device 102a can verify the authenticity of the public record message 1308.

[0218] Example public record received from a record receiver

[0219] After receiving the public record message 1308 from the processing platform 124, the user device (e.g., the record recipient device) can propagate the public record message 1308 to other user devices including the record sender device. For example, the user device that has received the public record message 1308 can broadcast the received public record message 1308 to other user devices for a period of time after receiving the public record message 1308 or continuously until a new public record message is received from the processing platform 124.

[0220] Figure 15 13 is an interaction diagram illustrating an example of propagating a public record by a record recipient device. After creating and signing a public record message 1308 at interaction 1304, the processing platform 124 may distribute the public record message 1308 to a user device (e.g., record recipient device 102b) at interaction 1316. At interaction 1320, the secure element (SE) 204b of the record recipient device 102b may verify the authenticity of the public record message 1308.

[0221] In exchanging individual records (e.g. Figure 4-12 100) shown in FIG, the record sender device 102a may not have received the public record message 1308 from the processing platform 124 or any other user device 116. At interaction 1504, the record recipient device 102b may propagate the public record message 1308 by providing and sending the public record message 1308 to the record sender device 102a. The public record message 1308 received from the record recipient device 102b by the record sender device 102a may include the signature of the record recipient device. At interaction 1508, the secure element (SE) 204a of the record sender device 102a may verify the authenticity of the public record message 1308.

[0222] Example public record received from the record sender

[0223] After receiving the public record 206 from the processing platform 124 , a user device (eg, a record sender device) may propagate the public record 206 to other user devices, including record recipient devices. Figure 16 13 is an interaction diagram illustrating an example of propagating a public record by a record sender device. After creating and signing a public record message 1308 at interaction 1304, the processing platform 124 can distribute the public record message 1308 to a user device (e.g., the record sender device 102b) at interaction 1316. At interaction 1328, the secure element (SE) 204a of the record sender device 102a can verify the authenticity of the public record message 1308.

[0224] In exchanging individual records (e.g. Figure 4-12 ), the record recipient device 102b may not have received a public record message 1308 from the processing platform 124 or any other user device 116 prior to receiving the individual record 100 shown in FIG. 1 . For example, the record sender device 116a may be a new user device, and the record recipient device 116b may not have the public key 106a of the record sender device. Without receiving the public record message 1308 containing the public key 106 of the record sender device, the record recipient 102b may not be able to verify that the record sender device 116a is a valid user device.

[0225] At interaction 1504, the record sender device 102a may propagate the public record message 1308 by offering to send the public record message 1308 and sending it to the record recipient device 102b. At interaction 1508, the secure element (SE) 204b of the record recipient device 102b may verify the authenticity of the public record message 1308. This propagation advantageously allows for the exchange of separate records even though the record recipient device 102b may not have the public key 102a of the record sender device prior to receiving the public record message 1308 from the record sender device 102a.

[0226] Example Error Management

[0227] The individual records received by the processing platform 124 from the user device may contain intended or unexpected errors. A user may engage in malicious behavior by creating invalid individual records (e.g., individual records with invalid signatures). An unscrupulous user may cause other users to appear malicious, for example, by causing them to create invalid individual records.

[0228] Example of sender cloning with multiple receivers

[0229] In some embodiments, a malicious record sender may send an individual record to two different record recipients. Figure 17is an interaction diagram illustrating this malicious behavior, which may be referred to as sender cloning with multiple recipients. A first record recipient 102b, using a first record recipient device 116b, may request an individual record from a record sender 102a by sending a first content request 402 to the first record sender device 116a using a short-range link (SRL) 122 at interaction 404. The first content request 402 may include content B 110b and the first public key 106b of the first record recipient device. A second record recipient 102c, using a second record recipient device 116c, may request an individual record from the record sender 102a by sending a second content request 1702 to the record sender device 116a using a short-range link 122 at interaction 1704. The second content request 402 may include content C 110c and the second public key 106c of the second record recipient device. The record sender 102a may receive the first content request 402 before, after, or simultaneously with receiving the second content request 1702.

[0230] Before sending the first copy of the individual record 100 to the first record recipient device 116b at interaction 420, the secure element (SE) 204a of the record sender device 116a can create and sign the individual record 100 at interaction 416. After successfully verifying the individual record 100 at interaction 424, the first record recipient device 116b can redeem the individual record 100 with the processing platform 124 at interaction 432. Upon redemption, the service provider 104 operating the processing platform 124 can process the individual record 100 at interaction 436 by verifying the authenticity of one or more signatures in the redeemed individual record 100. After successful verification, the processing platform 124 can execute as directed by the content A 110a of the individual record 100.

[0231] After creating and signing the individual record 100 at interaction 416, the record sender device 116a may also send a second copy of the individual record 100 to the second record recipient device 116b at interaction 1720. The record sender 102a may send the copy of the individual record 100 to the first record recipient 102b before, after, or simultaneously with sending another copy of the individual record 100 to the second record recipient 102c.

[0232] Content B 100b and content C 100c may be identical or similar, such that content A 100a may appear to satisfy the first content request 402 and the second content request 1702, respectively, to the first record recipient 102b and the second record recipient 102c. However, verification of the individual record 100 by the second record recipient 116c at interaction 1724 may fail because the individual record 100 may include the public key 106b of the first record recipient device, but not the public key 106c of the second record recipient device. This may indicate that the individual record 100 is intended for the first record recipient 102b, not the second record recipient 102c. Due to the unsuccessful verification, the second record recipient 106c may reject the exchange involving the second content request 1702 with the record sender 102a. In some embodiments, following the unsuccessful verification, the second record sender device 116c may add a "Malicious Record Endorsement" (MRE) to the individual record 100 before sending it to the processing platform 124 at interaction 1728.

[0233] Example of sender cloning with a single receiver

[0234] In some embodiments, a malicious record sender may send two copies of the same individual record to a record receiver. Figure 18 is an interaction diagram illustrating this malicious behavior, which may be referred to as sender cloning with a single recipient. Recording recipient 102b, using recording recipient device 116b, may request an individual recording from recording sender 102a by sending a first content request 402 to recording sender device 116a using short-range link (SRL) 122 at interaction 404. The first content request 402 may include content B 110b and the public key 106b of the recording recipient device. Similarly, recording recipient 102b may request another individual recording from recording sender 102a by sending a second content request 1802 to recording sender device 116a using short-range link 122 at interaction 1804. The second content request 1802 may include content B'110b' and the public key 106b of the recording recipient device. Recording recipient 102b may send the first content request 402 and the second content request 1802 simultaneously or at different times.

[0235] Before sending the first copy of the individual record 100 to the record recipient device 116b at interaction 420, the secure element (SE) 204a of the record sender device 116a may create and sign the individual record 100 at interaction 416. The record ID of the individual record 100 may be, for example, N. After successfully verifying the individual record 100 at interaction 424, the record recipient device 116b may redeem the individual record 100 with the processing platform 124 at interaction 432. Upon redemption, the service provider 104 operating the processing platform 124 may process the individual record 100 at interaction 436 by verifying the authenticity of one or more signatures in the redeemed individual record 100. After successful verification, the processing platform 124 may execute as indicated by the content A 110a of the individual record 100.

[0236] At interaction 1820, record sender device 116a may send a second copy of individual record 100 to record recipient device 116b. Content B 100b and content B' 100b' may be identical or similar, such that content A 100a may be displayed to record recipient 102b as satisfying first content request 402 and second content request 1802.

[0237] However, verification of the second copy of the individual record 100 by the record recipient 116b at interaction 1820 may fail. For each user device from which the record recipient device 116b has received one or more individual records, the record history tracker of the record recipient device 116b may track the record ID of the last individual record received from the user device. For example, the record history tracker may track the record ID 108N of the last individual record 100 it received from the record sender device 116a. Therefore, the record sender device 116a should not have sent a second copy of the individual record 100 containing the same record ID 108N to the record recipient device 116b.

[0238] In some embodiments, for each user device from which the record recipient device 116b has received one or more individual records, the record history tracker can track the individual records 100 using the largest record ID 108 received. Advantageously, for each user device from which the record recipient device 116b has received one or more individual records, the record recipient device 116b can only track the record ID 108 of the last individual record 100 received from the user device, because the record IDs 108 of individual records created by a record sender can increase monotonically. In some embodiments, the record history tracker can track the record IDs 108 of all individual records received.

[0239] Due to the unsuccessful authentication, the record receiver 106b may reject the exchange with the record sender 102a involving the second content request 1802. In some embodiments, after the unsuccessful authentication, the record sender device 116b may add a "malicious record endorsement" to the second copy of the individual record 100 before sending the individual record 100 to the processing platform 124 at interaction 1828.

[0240] Example fork

[0241] In some embodiments, a malicious record recipient may copy an individual record before acknowledging it and attempt to send the saved copy of the individual record to a second record recipient. Figure 19 4 is an interaction diagram illustrating this malicious behavior, which may be referred to as a fork. A first record receiver 102b, using a first record receiver device 116b, may request an individual record from a first record sender 102a by sending a first content request 402 to the first record sender device 116a using a short range link (SRL) 122 at interaction 404. The first content request 402 may include content B 110b and the public key 106b of the first record receiver device.

[0242] Before sending the individual record 100 to the first record recipient device 116b at interaction 420, the secure element (SE) 204a of the first record sender device 116a can create and sign the individual record 100 at interaction 416. After successful verification of the individual record 100 at interaction 424, the first record recipient device 116b can create a modified individual record 100m1 with the first record recipient signature 112b at interaction 428. When redeeming the modified individual record 100m1 with the processing platform 124 at interaction 432, the service provider 104 operating the processing platform 124 can process the modified individual record 100m1 at interaction 436 by verifying the authenticity of one or more signatures in the modified individual record 100m1. After successful verification, the processing platform 124 can execute as indicated by the content A 110a of the modified individual record 100m1.

[0243] The second record recipient 102c, using the second record recipient device 116c, may request an individual record from the first record recipient 102b by sending a second content request 1902 to the first record recipient device 116b. The first record recipient 102b may be the second record sender 102b, and the first record sender device 116b may be referred to as the second record sender device 116b. The second content request 1902 may include the content C 110c and the public key 106c of the second record recipient device.

[0244] The second record sender device 116b may send a copy of the individual record 100 to the second record recipient device 116c at interaction 1916. However, verification of the individual record 100 by the second record recipient 116c at interaction 1920 may fail because the individual record 100 may include the public key 106b of the second record sender device, but not the public key 106c of the second record recipient device. This may indicate that the individual record 100 is intended for the first record recipient 102b, not the second record recipient 102c. Due to the unsuccessful verification, the second record recipient 106c may reject the exchange involving the second content request 1902 with the second record sender 102b. In some embodiments, after the unsuccessful verification, the second record sender device 116c may add a "malicious record endorsement" to the individual record 100 before sending the individual record 100 to the processing platform 124 at interaction 1924.

[0245] Example Receiver Clone

[0246] In some embodiments, a malicious record recipient may attempt to redeem an individual record twice. In some embodiments, a malicious record recipient may redeem an individual record twice in an attempt to attribute the record sender to a clone of the record sender with a single recipient. Figure 20 4 is an interaction diagram illustrating this malicious behavior, which may be referred to as recipient cloning. Record receiver 102b, using record receiver device 116b, may request an individual recording from record sender 102a by sending a content request 402 to record sender device 116a using short range link (SRL) 122 at interaction 404. Content request 402 may include content B 110b and the public key 106b of the record receiver device.

[0247] Before sending the individual record 100 to the record recipient device 116b at interaction 420, the secure element (SE) 204a of the record sender device 116a may create and sign the individual record 100 with the record ID 108N at interaction 416. After successful verification of the individual record 100 at 424, the record recipient device 116b may create a modified individual record 100m1 with the record recipient signature 112b at interaction 428 before redeeming the first copy of the modified individual record 100m1 with the processing platform 124 at interaction 432. Upon redemption, the service provider 104 operating the processing platform 124 may process the modified individual record 100m1 at interaction 436 by verifying the authenticity of one or more signatures in the modified individual record 100m1. After successful verification, the processing platform 124 may execute as indicated by the content A 110a of the individual record 100.

[0248] Record sender device 116b may attempt to redeem the second copy of the modified individual record 100m1 with processing platform 124 at interaction 2032. However, at interaction 2036, processing of the second copy of the modified individual record 100m1 may fail. Processing platform 124 previously successfully processed the first copy of the modified individual record 100m1 at interaction 436. For each record sender device, user record state 306 of central record 302 may contain the record ID of the individual record already processed by processing platform 302. For example, for record sender device 116a, user record state 306 of central record 302 may contain record ID 108N of modified individual record 100m1. When record sender device 116b attempts to redeem the second copy of the modified individual record 100m1 with the same record ID 108N, processing platform 124 may detect the malicious redemption by comparing record ID 108N of modified individual record 100m1 with user record state 306.

[0249] Example Peek

[0250] In some embodiments, a malicious record sender may create an individual record with an inappropriate signature by bypassing the secure element (SE) of its record sender device. Figure 21 4 is an interaction diagram illustrating this malicious behavior, which may be referred to as snooping. Record receiver 102b, using record receiver device 116b, may request an individual recording from record sender 102a by sending a content request 402 to record sender device 116a using short range link (SRL) 122 at interaction 404. Content request 402 may include content B 110b and the public key 106b of the record receiver device.

[0251] By hacking into or bypassing its secure element (SE) 204a, the record sender device 116a may create an individual record 100 with an inappropriate signature 112a' at interaction 416 before sending the individual record 100 to the record recipient device 116b at interaction 420. The inappropriate signature 112' may be a random signature or may be created using a private key not associated with the record sender device 106b.

[0252] Verification of the individual record 100 by the record receiver 116b at interaction 424 may fail. The record receiver device 116b cannot determine that the inappropriate signature 112' was created using the private key 210a of the record sender device. The record receiver device 116b cannot decrypt the inappropriate signature 112' using the public key 106a of the record sender device. Due to the unsuccessful verification, the record receiver 106b may deny the exchange involving the content request 402 with the record sender 102a. In some embodiments, after the unsuccessful verification, the record sender device 116b may add a "malicious record approval" to the individual record 100 before sending the individual record 100 to the processing platform 124 at interaction 2124.

[0253] Example Ghosting

[0254] In some embodiments, a malicious record sender may create individual records with inappropriate signatures. Figure 22 4 is an interaction diagram illustrating this malicious behavior, which may be referred to as ghosting. Record receiver 102b, using record receiver device 116b, may request an individual recording from record sender 102a by sending a content request 402 to record sender device 116a using short range link (SRL) 122 at interaction 404. Content request 402 may include content B 110b and the public key 106b of the record receiver device.

[0255] By hacking into or bypassing its secure element (SE) 204a, the record sender device 116a can create an individual record 100 with an inappropriate public key 106a' and an inappropriate signature 112' at interaction 416' before sending the individual record 100 to the record recipient device 116b at interaction 420. The inappropriate public key 106' of the record sender device and the public key 106a can be different. The inappropriate signature 112' can be created using an inappropriate private key 210'.

[0256] If the record recipient device has the most recent public key for device 214b, verification of the individual record 100 by record recipient 116b at 424a may fail. Even if record recipient device 116b can decrypt the inappropriate signature 112', record recipient device 116b may know that the inappropriate public key 106' may not belong to the user device. The inappropriate public key 106' may not be among the public keys of device 214b in the public record 206. Due to the unsuccessful verification, record recipient 106b may deny the exchange involving content request 402 with record sender 102a. In some embodiments, after the unsuccessful verification, record sender device 116b may add a "Malicious Record Endorsement" (MRE) to the individual record 100 before sending the individual record 100 to processing platform 124 at interaction 2224.

[0257] In some embodiments, the verification of the individual record 100 by the record recipient 116b at interaction 424b may be successful because the record recipient device may not have the device's most recent public key 214b. Because the inappropriate signature 112' was created using the inappropriate private key 210', the record recipient device 116b can successfully decrypt the inappropriate signature 112' using the inappropriate public key 106' in the individual record 100a. After successfully verifying the individual record 100 at interaction 424b, the first record recipient device 116b can create a modified individual record 100m1 with the record recipient signature 112b at interaction 428 before exchanging the modified individual record 100m1 with the processing platform 124 at interaction 432. However, processing of the modified individual record 100m1 may fail at interaction 436 because the inappropriate public key 106a' is not in the public keys of the device 214 in the central record 302. In some embodiments, even though verification of the individual record 100 by record recipient 116b at interaction 424b may succeed, record recipient 102b may reject the exchange involving content request 402 with record sender 102a because the inappropriate public key 106a is not among the public keys of device 214 of public record 206. In some embodiments, a proprietary variant of an encryption algorithm may be employed to make ghosting impossible.

[0258] Example faults and blacklists

[0259] In the methods and systems disclosed herein, certain actions of users are undesirable. In some embodiments, the undesirable actions may not require changing or hacking the user device. For example, the undesirable action may be the result of a record sender 116a creating an individual record 100 with inappropriate content 110. For example, the user record status 306 may indicate that only the record sender 102a itself can access the document with its document ID stored in the content 110; and the record sender 102a cannot authorize other users to access the document. If the content 110 of an individual record 100 attempts to authorize a record recipient 102b to access the document, the content 110 may be inappropriate. By creating an individual record 100 with inappropriate content 110, the record sender 102a may act undesirably.

[0260] The processing platform 124 may include a demerit list that is configured to track the number of unwanted actions by a user. The demerit list may track and may be based on the number of unwanted actions processed or the number of individual records 100 with inappropriate content 110 processed, the type of unwanted actions or inappropriate content 110, when and how the unwanted actions occurred, when and how individual records 100 with inappropriate content 110 were processed, or any combination thereof. In some embodiments, the demerit list may determine demerits for users and user devices 116. Demerit points may be based on the information that the demerit list may track. Demerits may be standardized for all users or for some users (e.g., new users).

[0261] In some embodiments, the undesirable action may require changing or hacking the user device. Non-limiting examples of undesirable actions requiring changes to the user device may include sender cloning with multiple recipients, sender cloning with a single recipient, forking, recipient cloning, snooping, ghosting, or any combination thereof. Various detection schemes and methods may be used to detect undesirable actions. Figure 17-22 As shown in , these undesirable actions can be detected. As another example, the processing platform 124 can detect device changes based on verification and signature authentication of software and hardware on the user device 116.

[0262] The processing platform 124 may include a blacklist that tracks user devices that have been changed by detecting their participation in undesirable actions that require device changes. In some embodiments, if a user's user device is on the blacklist, all of the user's user devices may be on the blacklist 1404. If a user device is on the blacklist, the methods and systems disclosed herein may be temporarily or permanently prohibited. In some embodiments, users and user devices 116 with a certain number of demerit points may be placed on the blacklist.

[0263] Example Malicious Record Recognition

[0264] For some unexpected actions, the record receiving device 116b can detect changes or hacking attacks on the record sending device 116a itself. Figure 17, the second record recipient device 116c can detect on its own whether the individual record 100 is intended for the first record recipient device 116b. In some embodiments, upon unsuccessful authentication, the second record sender device 116c can add a "Malicious Record Endorsement" (MRE) to the individual record 100 before sending the individual record 100 to the processing platform 124 at interaction 1724. The second record sender device 116c can send the individual record 100 with the "Malicious Record Endorsement" to the processing platform 124 along with the record recipient signature 112c, which can be referred to as a signed "Malicious Record Endorsement." When the record sender device 116c is connected to the network 118, the record sender device 116c can send the individual record 100 with the "Malicious Record Endorsement."

[0265] Example fuzzy judgment

[0266] When processing platform 124 receives an individual record 100 with a signed "Malicious Record Approval," processing platform 124 may determine that a malicious user exists. However, processing platform 124 may not be able to distinguish between certain undesirable actions, such as a sender clone and a receiver clone with a single recipient. Furthermore, processing platform 124 may not be able to assign fault or failure to a specific user or user device 116.

[0267] For certain undesirable actions, the processing platform 124 may be able to assign fault or failure to a specific user. For example, if two identical copies of an individual record 100 involving a record sender 102a and a first record recipient 102b are redeemed at the processing platform 124, then either the record sender 102a or the first record recipient 102b is a malicious user. Based on whether either the record sender 102a or the first record recipient 102b is a malicious user, the processing platform 124 may generate a number of rules. Non-limiting example rules are:

[0268] M(sender)+M(first receiver)=true, (Rule 1)

[0269] Wherein M() represents a Boolean operator, which is used to determine whether a parameter is malicious, and “+” represents a logical OR operation.

[0270] This information can be stored for future use. For example, if two identical copies of another individual's record involving a record sender 102a and a second record recipient 102b' are redeemed at the processing platform 124, the processing platform 124 can generate a number of rules. Non-limiting example rules are:

[0271] (M(sender)+M(first receiver))*(M(sender)+M(second receiver))=true, (Rule 2)

[0272] Where "*" represents a logical AND operation.

[0273] Rule 2 can be rewritten as:

[0274] M(sender) + (M(first receiver)) * M(second receiver)) = true. (Rule 3)

[0275] When interpreting the rules, processing platform 124 may, for example, assume that no two users are malicious. If no two users are malicious, processing platform 124 may infer from Rule 3 that record sender 102a is malicious. As another example, processing platform 124 may assert the a priori belief that malicious users are likely rare, with a probability "p" greater than 0 and less than 1. The probability that both first record receiver 102b and second record receiver 102b' are malicious may then be p*p in Rule 3. The left side of Rule 3 may be expressed as p+p*p.

[0276] Similarly, this interpretation and assumption can be expanded to include all observations of all users by processing platform 124 and can be expressed as a sum of products. Therefore, the term with the fewest elements in the product is most likely to be true. For example, in Rule 3, the term M (sender) may have the fewest elements and be most likely to be true. These users and user devices can be marked as malicious and blacklisted, either immediately, temporarily, or for further investigation.

[0277] Example user device

[0278] Example processors, memories, storage, network interfaces, and short-range link interfaces

[0279] Figure 23 An example user device 116 is schematically shown. The user device 116 can be a recording sender device, a recording receiver device, and a proxy device. The user device 116 may include a processor 2304 configured to execute instructions stored in a memory 2308 (e.g., a random access memory (RAM)). The memory 2308 may be configured to store instructions and data when the user device 116 is powered on. The memory 2308 may include both read-only and writable memory. The user device 116 may include a storage device 2312 configured to store instructions and data when the user device 116 is powered on or off. One or both of the memory 2308 and the storage device 2312 may store instructions for securely exchanging content and recordings.

[0280] User equipment 116 may include a network interface 2316 and a short range link (SRL) interface 2320. Network interface 2316 may be configured to communicate synchronously or asynchronously with other devices on network 118 (e.g., processing platform 124). Non-limiting examples of network interface 2316 include wired communication, wireless communication, cellular communication, and communication using The short-range link (SRL) interface 2320 may be configured to communicate with other user devices 116 via the short-range link (SRL) 122. The short-range link interface 2320 may be a peer-to-peer wireless or other interface through which user devices 116a or 116b may communicate with each other. The short-range link interface 2320 may be based on the Infrared Data Association (IrDA) / Infrared Physical Layer Specification (IrPHY), Near Field Communication (NFC), ad hoc Institute of Electrical and Electronics Engineers (IEEE) 802.11, or any other wireless communication methods and systems.

[0281] Example Sensor

[0282] The user device 116 may include one or more sensors 2324 for sensing the surroundings of the user device. In some embodiments, the sensor 2324 may include a motion sensor, an orientation sensor, a position sensor, or any combination thereof. The motion sensor may be configured to sense, detect, and determine the motion of a user operating the user device 116, such as the user shaking the user device 116. In some embodiments, the motion sensor may convert the user's motion into an electrical signal for processing by the user device 116. For example, the motion sensor may include a single-axis accelerometer configured to sense, detect, and determine the motion exerted by the user on the user device 116. As another example, the motion sensor may include multiple accelerometers, such as a single-axis accelerometer and a 3D accelerometer, to enable detection of directional motion and vibration in multiple directions and increase detection sensitivity.

[0283] The orientation sensor can be configured to determine the orientation of the user device 116. For example, the orientation sensor of the sender device 116a can determine the position of the record sender's head relative to a fixed plane (e.g., the floor of the business premises where the record sender 102a and the record receiver 102b are securely exchanging individual records 100). In some embodiments, the orientation sensor can convert the orientation information into an electrical signal for processing by the user device 116. The position sensor can be configured to determine the user's position based on the position of the user device 116. Non-limiting examples of position sensors include a global positioning system (GPS) or an assisted GPS (aGPS) transceiver.

[0284] Sensor 2324 may include an imaging sensor (e.g., a digital camera), a microphone, or a biometric sensor. The imaging sensor may be configured to capture what the user sees. For example, the imaging sensor of record sender device 116a may capture one or more images of what record sender 102a sees. As another example, when record sender 102a and record receiver 102b securely exchange individual records 100, the imaging sensor of record sender device 116a may capture an image of record receiver device 116b to authenticate record sender device 116a. In some embodiments, the imaging sensor may convert photons into electrical signals and images for processing by user device 116.

[0285] The microphone can be configured to detect sound waves from the user's surroundings and from the user. User device 116 can detect and "hear" what the user hears and says. In some embodiments, the microphone can convert the sound waves into electrical signals for processing by user device 116. The biometric sensor can be configured to capture biometric information of the user. Non-limiting examples of biometric information include iris scans, skin color, skin texture, or fingerprints.

[0286] Example individual record processors, containers, communicators, and trackers

[0287] The user device 116 may include an individual record processor 2326, an individual record container 202, an individual record communicator 2328, and a record history tracker 2332. The individual record processor 2326 may be configured to create and modify individual records. The individual record container 202 may be configured to store unredeemed individual records 208. The individual record communicator 2328 may be configured to send, receive, or redeem individual records and modified individual records. The record history tracker 2332 may be configured to track individual records that the user device 116 has created, received, modified, or redeemed.

[0288] For example, the individual record processor 2326 of the record sender device 116a can create an individual record 100. The individual record communicator 2328 of the record sender device 116a can send the individual record 100 to the record recipient device 116b. The record recipient device 116b can receive the individual record 100 using its individual record communicator 2328. The individual record processor 2326 of the record recipient device 116b can modify the individual record 100 to create a modified individual record 100m1. The record recipient device 116b can store the modified individual record 100m1 in the individual record container 202 as one of the unredeemed individual records 208. The record recipient 116b can use its individual record communicator 2328 to redeem the modified individual record 100m1 with the processing platform 124.

[0289] The record history tracker 2332 may include a highest record ID 2336 for tracking the record ID of the most recently created individual record 100 by the user device 116. After the user device 116 creates a new individual record with a record ID greater than the highest record ID 2336, the user device 116 may update the highest record ID 2336. As another example, the record history tracker 2332 may track all individual records 100 that the user device 116 has created, received, modified, or redeemed. The record sender device 116a may include a copy of the individual record 100, and the record recipient device 116b may include a copy of the modified individual record 100m1.

[0290] Example Secure Element (SE)

[0291] The user device 116 may include a secure element (SE) 204. The secure element 204 may be configured to securely store the user device's private key 210 and one or more service provider public keys 212. In some embodiments, the secure element 204 may include the public key of a service provider 124. In some embodiments, the secure element 204 may include two or more service provider public keys 212 of one service provider 124. In some embodiments, the secure element 204 may include two or more service provider public keys 212 of two or more service providers. The secure element 204 may use the user device's private key 210 to sign an individual record 100. The secure element 204a of the record sender device 116a may add the recipient public key 106b and the record ID 108 to the individual record 100. The ID 108 may be based on, for example, the highest record ID 2336 tracked by the record history tracker 2332. In some embodiments, the secure element 204 may include one or more of the record history tracker 2332 and the highest record ID 2336.

[0292] The secure element (SE) 204 can use the service provider public key 212 to verify the authenticity of information received from the service provider 104. For example, the information received from the service provider 104 may include a service provider signature created using a private key of the service provider public key encryption pair. Verifying the authenticity of the information received from the service provider 104 may include using the service provider public key 212 to determine whether the service provider signature has been created using the service provider private key. In some embodiments, the service provider public key 212 may be hard-coded in the secure element 204. In some embodiments, the service provider public key 212 may be updated by the processing platform 124.

[0293] Security element (SE) 204 can have different implementations, including hardware implementation, secure virtualization, secure execution environment or any combination thereof. For example, security element 204 can include an integrated circuit or another hardware component that can securely store the private key 210 associated with user device 116. As another example, security element 204 can be implemented by a virtualization infrastructure. Virtualization infrastructure can be supported by one or more hardware features in a processor (e.g., processor 2304) in user device 116. As another example, security element 204 can be implemented as a secure execution environment. A secure execution environment can be a virtual implementation of an infrastructure (such as a global platform (GP) that can run Java Card applets). The global platform system can be hosted by, for example, the trust zone feature of an advanced reduced instruction set computing (RISC) machine (ARM) processor of a user device 116 providing a trusted execution environment (TEE).

[0294] Example public record receiver and container

[0295] The user device 116 may include a public record receiver 2338 that may be configured to receive public records 206 for storage in a public record container 2340. The public record 206 may include a public key for the device 214. In some embodiments, the public record 206 may include a user record status 306. In some embodiments, the public record 206 may include a demerit list 1402 and a blacklist 1404. A user or user device may be on the demerit list 1402 if it has created an individual record that instructs the processing platform 124 to perform a task when the user or user device should not have performed it. A user or user device may be on the blacklist 1404 if it attempts to redeem an individual record, for example, by signing it with a private key that is not assigned to the user device.

[0296] Example Trading Partner Identifier

[0297] The user device 116 may include a transaction partner identifier 2348 configured to identify the record sender device and the record receiver device. Figure 1B As shown in , in order for the record sender device 116a to create an individual record 100 and send it to the record recipient device 116b, the record sender device 116a may need to identify the public key 106b of the record recipient device 116b. The record recipient device 116b may use, for example, the short-range link interface 2320 to send the public key to the record sender device 116a. The transaction partner identifier 2348 of the record sender device 116a may confirm that the public key received from the record recipient device 116b is, for example, the public key 106b of the record recipient device.

[0298] Sample Error Manager

[0299] The user device 116 may include an error manager 2356 for handling received incorrect individual records. For example, the record recipient device 116b may be unable to verify the authenticity of the record sender signature 112a of the individual record 100 received from the record sender device 116a. In some embodiments, in response to receiving the incorrect individual record, the error manager 2356 may send the individual record to the processing platform 124 after adding a "malicious record endorsement" to the incorrect individual record.

[0300] Example Seeking Source

[0301] The user device 116 may include a source container 2360 configured to maintain source information 2364. The source information 2364 may be associated with an identification string (e.g., the name of a storage location). The source information 2364 may identify multiple sources for obtaining, for example, a document having its ID stored in the content 110 of the individual record 100. The source may or may not be part of the processing platform 264.

[0302] The user device 116 can create an individual record 100 with a source field for storing source information. In some embodiments, if the individual record 100 has an empty or no source field, it can be assumed that the individual record 100 has a default source. For example, if the individual record 100 instructs the processing platform 124 to provide a document to the record recipient 102b, the individual record 100 can include a source field, such as a specific repository for obtaining the document. If the individual record 100 does not include a source field or includes an empty source field, the processing platform 124 can obtain the document from the default repository.

[0303] In some embodiments, individual records 100 may include a cost-sharing field that indicates whether record sender 102a or record recipient 102b will pay or share in sourcing fees associated with sourcing. For example, a repository may charge a fee to processing platform 100 for accessing a document as indicated by an individual record 100, and the cost-sharing field may indicate whether record sender 102a or record sender 102b will be charged by the repository or whether and how they will share in the fee. In some embodiments, user device 116 may reject individual records 100 that have certain source fields, cost-sharing fields, or any combination thereof.

[0304] The user device 116 may include a source user interface 2368 for receiving source information 2364 from a user. For example, the user may input the source information 2364 using a web interface or an application on the user device 116. As another example, the source user interface 2368 may provide a visual interface for extracting the source information 2364 from a document containing the source information 264. The visual interface may utilize a sensor 2324 (e.g., an imaging sensor) and a computer vision algorithm.

[0305] Example processing platform

[0306] Example processors, memories, storage devices, and network interfaces

[0307] Processing platform 124 may include one or more server computers. The server computers may be centralized or distributed. Figure 24 An example processing platform 124 is schematically illustrated. The processing platform 124 may include a processor 2404 configured to execute instructions stored in a memory 2408 (e.g., random access memory (RAM)). The memory 2408 may be configured to store instructions and data while the processing platform 124 is powered on. The memory 2408 may include both read-only and writable memory. The processing platform 124 may include a memory 2412 configured to store instructions and data while the processing platform 124 is powered on or off. One or both of the memory 2408 and the storage device 2412 may store instructions for processing individual records (e.g., the modified individual record 100m1 that the record recipient device 116b has exchanged with the processing platform 104). The processing platform 124 may include a network interface 2416 configured to communicate synchronously or asynchronously, continuously or intermittently, with other devices on the network 118 (e.g., the user device 116). The network interface 2416 of the processing platform 124 and the network interface 306 of the user device 116 may be the same or different.

[0308] Example individual record receiver and processor

[0309] The processing platform 124 may include an individual record receiver 2420 configured to receive individual records 100 from the user device 116. The individual record processor 2424 of the processing platform 124 may be configured to process the individual records 100 received by the individual record receiver 2420 from the user device 116. For example, the individual record processor 2424 of the processing platform 124 may process the modified individual record 100m1 received by the individual record receiver 2420 from the record receiver 102b.

[0310] Processing an individual record 100 may include authenticating some or all signatures in the individual record 100 from the originator of the individual record 100 as "processing only endorsed" (FPOE) signers. For example, processing a modified individual record 100m1 may include authenticating one or both of the record sender signature 112a and the record recipient signature 112b.

[0311] Authenticating the signature in the individual record 100 can be based on the public key of the user device 214 stored in the central record container 2432 containing the central record 302. For example, the individual record processor 2424 can authenticate the record sender signature 112a and the record receiver signature 112b in the modified individual record 100m1. Authenticating the record sender signature 112a and the record receiver signature 112b can include determining whether the record sender signature 112a and the record receiver signature 112b were created using the private key 212a of the record sender device and the private key 212b of the record receiver device 116b, respectively. Determining whether the record sender signature 112a and the record receiver signature 112b were created using the private key 212a of the record sender device and the private key 212b of the record receiver device can include determining the authenticity of the signature using the public key 106a of the record sender device and the public key 106b of the record receiver device.

[0312] Processing an individual record may include performing operations as indicated by the content 110 of the processed individual record 100. For example, if the content 110 of the modified individual record 100m1 includes an instruction that the record recipient device 116b should be given access to a document having a particular document ID, then processing the modified individual record 100m1 may include granting the record recipient device 116b such access.

[0313] Example Central Record Processor and Container

[0314] After the individual record processor 2424 completes processing the received individual record, the central record processor 2428 of the processing platform 124 can be configured to update the central record 302 contained in the central record container 2432. The central record processor 2428 can back up the central record 302 contained in the central record container 2432, for example, to a backup storage device. In some embodiments, the central record 302 contained in the central record container 2432 is authoritative. For example, the user record state 306 of the central record 302 can contain the most up-to-date and accurate information for the user or user device. In some embodiments, at any given time, there may be unredeemed individual records that may not be reflected in the central record 302.

[0315] The central record 302 may include the public key of the user device 214, the user information 304, the user record status 306, the demerit list 1402, the blacklist 1404, and the source information 2436. For example, after the individual record processor 2424 grants the record recipient device 116b access to the document as indicated by the content 110 of the modified individual record 100m1, the central record processor 2428 may update the user record status 306 to reflect this access authorization.

[0316] The source information 2436 may include information about how the content 110 of the individual record 100 may be processed. For example, the modified individual record 100m1 may instruct the processing platform 124 to grant the record recipient device 116b access to a document with a specific document ID, and that the document may be stored in two databases. The source information 2436 may indicate that the document may be obtained from either database, or, if possible, should be obtained from one of the two databases.

[0317] Example Public Record Generator and Distributor

[0318] Public record generator 2440 of processing platform 124 can create public record 206 from central record 302 for distribution to user devices 116 by public record distributor 2444. The content of public record 206 can vary. For example, public record 206 can be identical to central record 302. As another example, public record 206 can be a subset of central record 302. Public record 206 can include one or more of the public key of device 214, user information 304, user record status 306, demerit list 1402, blacklist 1404, and source information 2436. Public record distributor 2444 can distribute public record 206 using a signature of public record 206 created by service provider private key 2448. One or both of service provider public key 212 and service provider private key 2448 can be stored in a secure element (SE) of processing platform 124. Service provider private key 2448 can be proprietary or non-proprietary to processing platform 124.

[0319] Sample Error Manager

[0320] The processor platform 124 may include an error manager 2452 configured to handle incorrect individual records. For example, the record recipient device 116b may send a modified individual record 100m1 with a "Malicious Record Approval" in the approval block 105b. The error manager 2452 may be configured to determine whether the record sender device 116a should be placed on the delinquency list 1402 or the blacklist 1404 based on the incorrect individual record received by the processing platform 124.

[0321] Example Seeking Source

[0322] The processing platform 124 may include a source manager 2456 for managing source information 2436 stored in the central record 302. The source manager 2456 may be configured to facilitate interactions with sources and to determine which sources to interact with. The source information 2436 may identify multiple sources (including default sources and preferences for different sources) for execution as indicated by the content 110 of the individual record 100 being redeemed. The source information 2436 may include costs associated with accessing sources, such as the cost to the source for accessing them. The source information 2436 may include information received from the user.

[0323] Example system for cryptographically secure transfer of funds

[0324] Disclosed herein are systems and methods for offline digital transfer of funds. For example, transaction instruments such as digital checks can be securely transferred and exchanged using a hybrid system. When not all parties to a transaction are connected to a central data server that can authenticate the transaction, the hybrid system can provide a centralized and peer-to-peer exchange of digital checks or value transfers that is meaningful or satisfactory. Digital checks can have a variable value, rather than bearer documents (such as cash), and they allow large amounts of value to be transferred from one person or entity to another without requiring both parties to be present at a central depository such as a bank. Challenges associated with digital transfers, such as the triviality that digital checks can be copied, are addressed. Features based on digital tools and techniques available on digital platforms are disclosed, such as the use of digital encryption, which is a more powerful cryptographic analog of a traditional handwritten signature, for the approval of digital checks.

[0325] A hybrid system may include one or more components for transferring funds from one user of the system to another. A hybrid system may have both centralized and peer-to-peer components. Using a hybrid system, users may conduct financial transactions with each other without accessing the central components of the system at the time of transaction. The system may utilize a network, such as the Internet, a global network accessible via wired or wireless communications implementing protocols such as the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standard, or a remote network such as a cellular telephone network.

[0326] One or more components of the system may include a digital check, a user such as a buyer or seller, a mobile computer (MC), a wallet, a short range link (SRL), a processing platform, a central ledger, a public ledger, or a company. A digital check may be a digital object, a block of data, that can be sent from one component of the system to another. A buyer may be a payee who wishes to transfer funds to another person (e.g., a seller). A seller may be a payee who wishes to receive funds from another person (e.g., a buyer). A mobile computer may be a computing device possessed by the buyer and the seller. The mobile computers possessed by the buyer and the seller may be the same or different. For example, a mobile computer may be a cellular phone. A wallet may be a digital data structure residing on a mobile computer that contains all digital checks received by the mobile computer that have not yet been sent to the processing platform. A short range link may be a peer-to-peer wireless or other link that allows mobile computers to communicate with each other. The link may be based on the Infrared Data Association (IrDA) / Infrared Physical Layer Specification (IrPHY), Near Field Communication (NFC), ad hoc Institute of Electrical and Electronics Engineers (IEEE) 802.11, or any other wireless communication methods and systems.

[0327] The processing platform can be a server comprising a machine or a collection of machines, which can be the system's infrastructure. The processing platform can be connected to a network and indirectly (but perhaps only intermittently) connected to a mobile computer. The processing platform can maintain a central ledger as well as a public ledger. The central ledger can be a database that maintains balances measured in monetary units. The monetary unit can be an existing national currency (e.g., the US dollar). The monetary unit can also be a new legal tender created for the system. This balance information can be stored for each user of the system. The central ledger can maintain other auxiliary or identifying information about each user. Public ledgers associated with the central ledger can be distributed throughout the system. The public ledger can contain a list of valid user identifiers (IDs). The public ledger can also contain other information about users. The public ledger differs from the central ledger in that, in some embodiments, the public ledger does not contain account balances. The public ledger can omit other information found in the central ledger. The company can be a service provider or the entity operating the processing platform.

[0328] Example Basic Transaction

[0329] Figure 25An example of a standard transaction is schematically shown. A buyer can issue an instruction to a central ledger that can be provided to a seller. This instruction can be a digital check. The seller can then cash this digital check at a processing platform that maintains the central ledger to transfer the funds. The transaction between the buyer and seller can be completed offline, without either party being connected to the internet, and data transfer can also be accomplished via a short-range link (SRL). The seller can then cash the digital check with the processing platform that maintains the central ledger at any later time when their mobile computer is connected to the processing platform via the internet.

[0330] Both the buyer and the seller can have a mobile computer (MC). The mobile computer can be equipped with a security element (SE). The security element can have different embodiments, including hardware embodiment, secure virtualization, secure execution environment or any combination thereof. For example, the security element can be a chip or other hardware component that can safely store the private key of a public key encryption algorithm such as Rivest-Shamir-Adleman (RSA) encryption. As another example, the SE can be a virtualization infrastructure that can be supported by the hardware features in another processor in the MC. As another example, the SE can be a virtual embodiment of the infrastructure of a global platform (GP) such as running a Java Card applet thereon. The entire GP system can be hosted by means of the TrustZone feature (such as ARM global platform trusted execution environment (TEE)) of the advanced reduced instruction set computing (RISC) machine (ARM) processor of the mobile device.

[0331] The secure element can sign the data block of a digital check. The secure element can have other, possibly unrelated, functions that the SE can also perform. When signing the data block, the secure element can also implement two additional fields in the block. The first additional field can be a public key associated with the user, which can be stored in the SE. The second additional field can be a check identifier (ID), which is a uniformly incremented number within the SE so that the same number never appears twice.

[0332] The action of the SE can be triggered by providing both a digital check block to be digitally signed and a passphrase or biometric template. The passphrase or biometric template may be required in order for the SE to issue a signature. The biometric template may be derived from a fingerprint, iris, or any other source. The SE may implement a biometric fuzzy library configured to recognize the biometric template. The signature may be completed and the block may be signed. The signature may be a digital signature and may be created using an algorithm such as RSA to encrypt a hash such as a secure hash algorithm (SHA)-2 of the block. The signature may be created using a private key stored in the SE, but may be verified by any holder of the user's associated public key.

[0333] The buyer can send the signed digital check directly to the seller with the help of an SRL or any other means, or indirectly through any other party. Once the seller has, the seller can choose to add an approval block to the digital check. The approval can be a "deposit only approval" (FDOE), which specifies that only the digital check can be deposited. The approval can further redirect the digital check to a third party. Once the approval is added, the seller can repeat the process of generating a signature for the entire digital check (including the original block, the buyer's signature, and the approval block). Therefore, any digital check can be a chain of blocks, each of which identifies its originator. At each block, the entire previous part of the chain can be signed by the party that processed the block using the private key of its mobile computer at that time.

[0334] Any digital check whose last block is an FDOE can be redeemed with the processing platform. Upon redemption, the processing platform verifies the authenticity of each signature in the chain back to the originator of the digital check (e.g., the original buyer). If all signatures are authentic, the funds are transferred from the originator's account and placed in the user account at the end of the chain in the digital check. A redemption event occurs when the seller connects to the processing platform and redeems the digital check in their wallet.

[0335] Example Central Ledger

[0336] The company may be responsible for maintaining the processing platform, and the processing platform may be configured to maintain a central ledger. The central ledger may be or may include a user database. The central ledger may contain known information about users, including their public keys and current balances. In some embodiments, the central ledger may contain all information about known users in the system. The public key may be associated with the private key in the SE of the mobile computer. The records in the central ledger may be device records, rather than individual records. If this information is available, mobile computers owned by a user can be grouped together by user. In some embodiments, balances across devices associated with a particular user can be consolidated.

[0337] Even though backup copies of the central ledger may exist, the central ledger must be unique so that the balances it contains are authoritative in the system. At any given time, there may be outstanding digital checks in the system that the central ledger may not be aware of. The processing platform that maintains the central ledger can use the information in the central ledger to verify any digital check from its origin to the signer of the FDOE.

[0338] Example public ledger

[0339] Each mobile computer in the system can maintain a data structure called a public ledger. The public ledger can be a derivative of the central ledger that does not contain financial balance information. The public ledger can contain a list of all valid public keys (i.e., user identities) in the system. The public ledger can also contain information about individual users, such as their delinquency or blacklist status (described further below).

[0340] The public ledger can be updated from time to time by the processing platform. When distributed, it can be cryptographically signed using a private key known only to the processing platform. Each recipient can be provided in advance with the corresponding public key needed to verify the signature on the public ledger.

[0341] Example Trading Partner ID

[0342] Because the system's digital checks can be sent electronically from buyers to sellers, buyers may not be sure of the seller's identity. For example, when a merchant acting as a seller wishes to be paid by a buyer acting as a payee, the merchant may issue a "payment request" (PR) via the SRL. The payment request may contain the merchant's identifier (ID), such as the merchant's public key and the requested value. A malicious actor may generate a payment request at approximately the same time as the merchant, hoping that the buyer may mistakenly send a digital check to him rather than to the merchant who issued the payment request. Therefore, the buyer may need to be able to identify the seller. The buyer may identify the seller through a partner identification. Non-limiting examples of methods for partner identification include payment authorization, tapping, physical indication, beamforming, prior arrangement, rough verification, or any combination thereof.

[0343] Example payment authorization

[0344] In some embodiments, the partner identification may include a payment authorization (PA). For example, the buyer may issue a payment intent (IP). The payment intent may be a zero-value transaction sent to the buyer, such as the public key of the seller's mobile computer provided in the payment request. If the payment intent reaches the seller's MC, the seller may indicate that he is the recipient of the payment intent through non-electronic methods. For example, the seller may verbally notify the buyer that he has received the payment intent. When the seller indicates to the buyer that he is the recipient of the payment intent, the seller's request to pay can be verified and the buyer can send the payment to the seller.

[0345] Example tap

[0346] In some embodiments, partner identification may include tapping. For example, the buyer's mobile computer (MC) and the seller's mobile computer may make physical contact, such as tapping. The mobile computers may include motion sensors. And the motion sensors of the buyer's mobile computer and the seller's mobile computer may measure the physical contact. The simultaneity of the physical contact measured by the buyer's mobile computer and the seller's mobile computer may be proof of authenticity. The seller's mobile computer may send a payment authorization when the tapping occurs. The buyer's mobile computer may accept the payment authorization based on the temporal concurrency of the physical contact measured by itself and the receipt of the payment authorization. In some embodiments, to provide additional security, the seller may send a signature of the contact measured by it to the buyer. Since contact may produce an equal and opposite reaction in the buyer's mobile computer, the buyer's mobile computer may verify the contact measured by the seller's mobile computer.

[0347] Example Physical Instructions

[0348] In some embodiments, partner identification may include physical indications. For example, if a mobile computer (MC) is able to perceive the environment (e.g., via an imaging sensor such as a camera), two mobile computers can be oriented so as to perceive each other. When tapping is used for partner identification, the gesture of the other MC observed acts like a signature of the tapping. For example, if the camera of A's mobile computer sees B's MC pointing up and to the left, the camera of B's ​​mobile computer should see A's MC pointing down and to the right. The perceived orientations can be compared qualitatively or quantitatively.

[0349] Example Beamforming

[0350] In some embodiments, partner identification may include beamforming. For example, the mobile computer's short-range link (SRL) may be directional (e.g., using beamforming or a directional antenna). With beamforming, the buyer's mobile computer and the seller's mobile computer may point toward each other when sending or receiving a payment request. Thus, a payment request (PR) from the seller's mobile computer may be sent to the buyer's mobile computer (MC). If another PR is sent from another direction, the buyer's mobile computer may not receive a response because the buyer's MC is directed toward the seller's MC.

[0351] Example first layout

[0352] In some embodiments, the partner identification may include prior arrangement.For example, the buyer may know the identifier (ID) of a particular seller; therefore, verification may not be necessary.

[0353] Example rough verification

[0354] In some embodiments, the partner identification may include a rough verification. The public ledger may contain an identification string, such as BigBoxStore, which can be used to roughly verify the payment request. For example, the merchant may be identified as BigBoxStore by a company operating a processing platform in the public ledger. This identification may be associated with an indication (e.g., a bit) in the public ledger indicating that the BigBoxStore's identification has been verified by the company. The verified identification can be distinguished from the identification assigned or provided by the user himself.

[0355] Error Management

[0356] The system disclosed herein is capable of authenticating any chain of approval in a digital check as authentic. However, digital checks may contain errors. Unethical users operating within the system can attack the system by creating invalid digital checks, or unethical entities can attack other users of the system by making them appear to be malicious attackers. In some embodiments, some attacks may initially be indistinguishable from other attacks.

[0357] Example of a buyer clone with multiple sellers

[0358] A malicious buyer can copy the digital check after signing it and send identical copies of the digital check to two different sellers with the intention that it can receive goods from both sellers while paying only once. Figure 26 This example of malicious behavior, known as buyer cloning with multiple sellers, is schematically illustrated. For example, when a digital check is intended for a first seller, the malicious buyer can send identical copies of the digital check to both the first and second sellers. Upon receiving the copies, the second seller can immediately determine that the digital check is not recognized. Therefore, the second seller can reject the digital check.

[0359] Example Buyer Clone with a Single Seller

[0360] A malicious buyer can copy the digital check after signing it and later attempt to reuse the digital check with the same seller with the intention that it can receive goods from the seller twice while paying only once. Figure 27This malicious behavior, which can be referred to as buyer cloning with a single seller, is schematically illustrated. The seller's mobile computer (MC) can detect this malicious behavior. For example, the seller's mobile computer can keep a record of the check ID of the last digital check from any particular user from which it has received a digital check. In some embodiments, because check IDs can be issued in strictly increasing order, the seller's mobile computer can track the ID of the last digital check it received from any particular user. In some embodiments, the seller's mobile computer can track the IDs of all digital checks it has received. Any new digital check received from a particular user should have a check ID that is greater than the highest check ID on record.

[0361] Because the central ledger can always detect duplicate digital checks, the processing platform will never pay out duplicate digital checks. Therefore, the seller is responsible for maintaining a record of this transaction. The seller's MC can execute a software program or hardware program to automatically record transactions and digital checks it has received and compare all new transactions to this log.

[0362] Example fork

[0363] A malicious seller may receive a digital check from a buyer. After receiving the digital check, the seller may copy the digital check before approving it and attempt to use the received digital check to pay a second seller with the intention of purchasing goods from the second seller without paying the fee. Figure 28 This malicious behavior, which may be referred to as check forking, is schematically illustrated.The second seller may reject a digital check received from the malicious seller because it may verify that the received digital check does not indicate that it is the intended recipient.

[0364] Example Seller Clone

[0365] A malicious seller can copy a received digital check and deposit it twice, with the intention that the seller can be paid twice for the transaction. Figure 29 This malicious behavior, which may be referred to as seller cloning, is schematically illustrated. A malicious seller may attempt seller cloning with the intention that the buyer be attributed to buyer cloning.

[0366] Because the central ledger can contain the same check ID number from the buyer, the processing platform can identify this malicious activity when a malicious seller deposits a received digital check a second time. To detect this attack, the central ledger can maintain a record of all check ID numbers redeemed from a specific originating ID on a mobile computer. In some embodiments, this record can be included in a public ledger and distributed to users or mobile devices of the system. This allows users or user devices to receive digital checks that were received out of order.

[0367] Example Peek

[0368] A malicious buyer can bypass the secure element of his mobile computer and generate a false signature for the digital check. The false signature can be a signature that was not created using the private key of the malicious buyer's mobile computer. Figure 30 This malicious behavior, which can be referred to as snooping, is schematically illustrated. A malicious buyer's goal might be to fail to cash a digital check because the seller cannot verify that it originated from the malicious buyer. The seller can immediately detect this malicious behavior because the digital check's signature cannot be decrypted using the buyer's ID (e.g., the malicious buyer's public key included as part of the digital check). Therefore, the seller can immediately reject the digital check.

[0369] Example Ghosting

[0370] A malicious buyer could generate a digital check using an ID different from their own and then sign it using a private key associated with a different ID. Figure 31 This malicious behavior, which can be referred to as ghosting, is schematically illustrated. If the seller has an up-to-date list of all users in the system and the processing platform can detect digital checks as they arrive on the ledger, the seller can detect ghosting. The seller can have a copy of the public ledger and can reject the digital check or accept it at their own risk if their public ledger does not contain the buyer's ID on the digital check. In some embodiments, the system can employ proprietary variations of encryption algorithms to make ghosting impossible.

[0371] Example strengths, weaknesses, and blacklists

[0372] Certain activities of a user may be undesirable. The system may respond to a user engaging in undesirable activities in a variety of ways. A first class of undesirable activities does not require any explicit modification to the mobile computer or the computer program running on the mobile computer (MC). The first class of undesirable activities, overdrafts, may include "rebounced" digital checks, such as issuing a value in a digital check that is higher than the value that the issuer's balance can support. When a user engages in an overdraft, the system may assign demerits to them. For example, the demerit system may track one or more of the following: demerits based on the number of dishonored digital checks, demerits based on the value of dishonored digital checks, demerits based on the recency of dishonored digital checks, or any combination thereof. The demerit system may normalize some or all of the demerits that it tracks by the total number of digital checks redeemed or the value of all digital checks redeemed.

[0373] The second type of undesirable activity, hacking, may require tampering with the mobile computer, its secure element (SE), or the computer program running on it. This type of undesirable activity may include the attacks mentioned in the previous section, such as forking, cloning, or snooping, which require explicit hacking or modification of the mobile computer, its secure element, or the computer program running on it (i.e., unauthorized modification of the mobile computer's behavior, the SE, or the computer program). The system can detect some hacking attacks using checksums and signing certificates for computer programs running on the mobile computer. When a user participates in a hacking attack, the system can place them on a blacklist. A blacklist can be a list of user IDs that are temporarily banned or banned from all future transactions. Since user IDs can be uniquely tied to a mobile computer, blacklisting a user ID can be equivalent to blacklisting the mobile computer. Any user who is shown to have participated in a hacking attack from a hacking device can be blacklisted.

[0374] Sample Signed Statement

[0375] Certain types of hacking attacks can be detected immediately by the seller. For example, in the case of a buyer clone with multiple sellers, the second seller can immediately detect that it has received a malicious "hacker" check. It may be advantageous if such a hacking attack event is reported to the processing platform. For example, the seller's mobile computer can approve the digital check received via a "Malicious Check" (MC) approval. The MC approval can be signed like any other digital check from the second seller, and the approved check can be sent to the processing platform when redeeming other digital checks owned by the seller with the processing platform.

[0376] The receipt of a signed MC endorsement by the processing platform can indicate the presence of a malicious actor in the system. However, the identity of the malicious actor may be unclear. For example, the MC provided by a seller could indicate a buyer clone of a malicious buyer with whom the seller actually transacted; however, it could also be a legitimate digital check received by a malicious seller who has cloned the buyer's check in order to attribute it to the cloned buyer. In either case, a malicious actor exists in the system.

[0377] Example fuzzy judgment

[0378] For some types of hacking attacks, it may be difficult or impossible to clearly assign fault to a specific party in the transaction. However, because digital checks are signed using signatures that are available only to the parties to the transaction, it is possible to attribute responsibility to a specific party. For example, if two identical digital checks are redeemed at a processing platform, either the originator (buyer) or the depositor (seller) could be the malicious actor. Based on this observation, a non-restrictive rule can be generated:

[0379] M(buyer)+M(sender)=true, (Rule 4)

[0380] Wherein M() represents a Boolean operator that determines whether a parameter is malicious, and "+" represents a logical OR operation.

[0381] This information can be stored for future use. For example, if the central ledger later receives another identical pair of digital checks from a different seller and the same buyer, another non-restrictive rule can be generated:

[0382] (M(buyer)+M(first seller))*(M(buyer)+M(second seller))=true, (Rule 5)

[0383] Where "*" represents a logical AND operation. Rule 5 can be rewritten as:

[0384] M(buyer) + (M(first seller)) * M(second seller)) = true. (Rule 6)

[0385] For example, when interpreting the rules, the processing platform may assume that no two actors are malicious. Therefore, the processing platform may infer from Rule 6 that the buyer is malicious. As another example, the processing platform may assert the prior belief that malicious actors are rare, with a probability "p" greater than 0 and less than 1. Then, in Rule 6, the probability that both sellers are malicious may be p*p. The left-hand side of Rule 6 may be expressed as p+p*p.

[0386] Similarly, this explanation and assumption can be extended to include all observations of the system for all users and can be expressed as a sum of products. Therefore, the term with the fewest elements in the product is most likely to be true. These actors can be marked as malicious and blacklisted, either immediately, temporarily, or for further investigation.

[0387] Sample Point of Sale

[0388] The system can interface with point of sale systems. Figure 32An example of a point-of-sale (PoS) transaction is schematically shown. The point-of-sale (PoS) system may be a cash register or equivalent. The PoS system may be located at a fixed location. The PoS system may be part of an existing infrastructure (e.g., an existing infrastructure with cash registers at a merchant such as a Big Box Store).

[0389] Merchants can be associated with one or more user identifiers (IDs). Merchants can have individual accounts, one account per cash register, or one account per store location. A merchant's account can be associated with a mobile computer like other users, or it can be associated with a key pair issued to the merchant by the system. The merchant key pair can be managed by a computer owned by the merchant, or it can be hosted by a company as a service similar to "Software as a Service" (SaaS).

[0390] A checker, cashier or PoS operator working for a merchant may have access to a mobile computer (MC) issued specifically to him, or the mobile computer may support multiple logins by authorized checkers, cashiers or PoS operators working for the merchant.

[0391] When a buyer wishes to purchase goods or services from a merchant, the buyer can create a digital check that is issued to the merchant's user ID but sent to a checker via a short-range link (SRL). Once in contact with the checker, the checker can verify that the digital check is valid by accessing, for example, the merchant's network. The merchant's network can be a secure Institute of Electrical and Electronics Engineers (IEEE) 802.11 network or similar network that the checker can access, but not the buyer. The checker can then send the digital check to the merchant's wallet via, for example, the merchant's secure network.

[0392] In transactions involving point-of-sale systems, the original digital check from the buyer can be issued to the merchant but given to the checker. The checker can then add "Processed by Endorsement" (HBE) before sending the digital check to the merchant. The merchant can then add "Endorsement for Deposit Only" (FDOE) and redeem the digital check with the processing platform.

[0393] Before sending a digital check to a merchant, a checker can add a "Handled" endorsement (HBE) containing his or her own user ID and signed by the secure element of his or her mobile computer. A merchant can choose to only process digital checks marked with an HBE from one of its checkers.

[0394] When a digital check is redeemed by a merchant, a message can be sent to the checker, for example using an HBE, indicating that the processing platform has cleared the digital check. At this point, the checker can close the sale by entering the value of the digital check into the cash register as a "cleared check" or appropriate designation.

[0395] The merchant's PoS system may require little or no changes. The merchant can issue mobile computers to its checkers. Some checkers may have their own MCs, and the merchant may choose to accept digital checks from HBEs issued by the checker's private MC.

[0396] Example funds inflows and outflows relative to the central ledger

[0397] Funds can enter and exit the central ledger from other common monetary instruments. When a user or user device wishes to add money to the central ledger, the processing platform can transfer the money to the user's or user device's account via a transfer-in method. The transfer-in method can be a withdrawal from a credit card, an automated clearing house (ACH) transfer, the mailing of a physical check, or the processing of a physical cash instrument. After receiving the money, the processing platform can credit the user's or user device's account. For such instruments that incur transaction fees, the processing platform may or may not reimburse these fees.

[0398] When a user or user device wishes to remove money from the central ledger, the processing platform may transfer the money from the user's or user device's account using a transfer-out method. The transfer-out method may be an ACH transfer, a mailed physical check, or any similar means. The processing platform may debit the user's or user device's account before sending the money using the transfer-out method. The processing platform may charge a fee for the removed money. This fee may vary for different customers or different types of customers.

[0399] A fee may be charged to the merchant or user for the key pair. For example, the merchant or user may be charged periodically (e.g., monthly) or only once (e.g., during setup). Key pairs may be sold at a fixed price or a negotiated price, which may include volume discounts for merchants with multiple active key pairs. The processing platform may offer preferential or exclusive pricing to certain users or merchants.

[0400] Sample Fees

[0401] As described above, fees may be charged for any transfer into, out of, or within the system. These transfer fees may be proportional to the size of the transaction, fixed, or a combination of both. Fees may also be assessed for digital checks issued by a user's device with insufficient account balances. The processing platform may choose to assume the resulting debt and, in such circumstances, may charge interest or fees associated with the resulting debt.

[0402] Example source transactions

[0403] Transactions in the system disclosed herein can be "sourced" from an available balance in a buyer's account on a central ledger. It may be advantageous if the buyer issues a digital check that automatically draws funds from a source known to the public ledger, rather than a portion thereof. For example, a buyer may wish to purchase an item from a merchant for $100 and may want the central ledger to draw $100 from a specific source (such as the buyer's checking account at their bank) or from a specific credit card. The system may include an interface for entering source information (SI) (such as bank account information or credit card information) into the central ledger. The buyer's mobile computer may store the source account with an identification string (SAIS). The digital check may include a data field for storing the SAIS.

[0404] The interface used to input source information into the system may vary in different embodiments. For example, the interface may include a webpage or an "app" on the MC. Such an interface may include a visual interface (e.g., using a digital camera and software implementing computer vision algorithms) for extracting source information from physical checks, bank statements, physical credit cards, credit card statements, or any combination thereof.

[0405] The system may not accept digital checks with a blank SAIS field. If the system accepts digital checks with a blank SAIS field, the blank SAIS field may be interpreted as a hint that the processing platform should withdraw funds from the user's account or other default source.

[0406] The digital check may include a fee sharing field that indicates a fee sharing policy. The fee sharing field may be a bit, a bit field, or other value that indicates a fee sharing policy (such as whether the buyer will pay fees associated with the source or how the seller or buyer will share fees associated with the source). For example, a digital check may include a bit that indicates that the buyer will (or will not) pay source fees associated with the source account (e.g., credit card fees) and a second bit that indicates that the buyer will (or will not) pay transfer fees (e.g., fees charged by the processing platform for transferring funds from the buyer's account to the seller's account).

[0407] The system can make these fees visible or invisible to the buyer or seller.In some embodiments, the seller may be able to selectively reject a digital check based on its associated fees and the buyer's fee sharing policy.

[0408] Example Funds Verification

[0409] The seller can be connected to the processing platform via a network such as the Internet, even though the buyer may not be. For example, a merchant can connect via its dedicated network connection with a wired or wireless connection to the Internet, even though the buyer may not be connected to the processing platform due to, for example, poor cellular phone connectivity. When the seller has access to the Internet, it can verify the availability of funds in the buyer's account before accepting the transaction.

[0410] For example, a seller may be allowed to submit an authorized version of a digital check issued by a buyer with an authorization such as a "Query Entitlement" (QE), indicating that the digital check is for inquiry only. Such a Query Entitlement (QE) may be signed by the seller. Upon receiving a digital check with a QE, the processing platform may return information to the seller about the buyer and the buyer's ability to complete the transaction. For example, the processing platform may return information such as immediate funds availability (the current central ledger balance, or if the current central ledger balance reaches or exceeds the value of the digital check), source information if the digital check is obtained with the aid of a SAIS field (e.g., including default source information if an overdraft against current funds is expected), or any combination thereof. The source information may include information about fees. A fee apportionment field may be used to determine whether fee information is to be apportioned in response to a QE digital check (e.g., fee information may not be apportioned with a seller holding a digital check indicating that the buyer is bearing the fees).

[0411] Example secure exchange of cryptographically signed digital checks involving financial institutions

[0412] The systems and methods for securely exchanging content and records of the present disclosure (eg, cryptographically signed digital checks) may be implemented by one or more user devices, one or more processing platforms, and one or more financial institution servers. Figures 33A to 33C Another embodiment of securely exchanging cryptographically signed digital checks involving a financial institution is schematically illustrated. Figures 33A to 33C In the non-limiting example embodiment shown in FIG, a user may operate a user device to create, send, receive, modify, or redeem an individual record 100, such as a cryptographically signed digital check. For example, a sender 102a of a digital check may operate a check sender device 116a or 116a'. A receiver 102b of a digital check may operate a check receiver device 116b.

[0413] User devices, such as the check sender device 116a and the check receiver device 116b, may be the same or different. User devices may include cellular phones, tablet computers, e-readers, smart watches, head-mounted augmented, virtual, or mixed reality display systems, wearable display systems, or computers. User devices 116a or 116b may communicate with other devices on a network 118 using communication links 120a, 120b (e.g., cellular communication links). Network 118 may be a local area network (LAN), a wide area network (WAN), or the Internet accessible via a wired or wireless communication link (e.g., implementing the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standard).

[0414] When sending the digital check 100, one or both of the check sender device 116a and the check recipient device 116b may be offline and not connected to the network 118. The check sender 102a, using the check sender device 116a, may send the cryptographically signed digital check 100 to the check recipient 102b using a short range link (SRL) 122. The short range link (SRL) 122 may be a peer-to-peer wireless or other link over which the user devices 116a or 116b can communicate with each other. The short range link (SRL) 122 may be based on the Infrared Data Association (IrDA) / Infrared Physical Layer Specification (IrPHY), Near Field Communication (NFC), ad hoc 802.11 or any other wired or wireless communication method or system.

[0415] The processing platform 124 operated by the service provider 104 can communicate with other devices on the network 118 (e.g., user devices 116a, 116b) using the communication link 126. The financial institution server 3304 operated by the service provider 104 or a financial institution affiliated with the processing platform 104 can communicate with other devices on the network 118 (e.g., the processing platform 124). The communication link 120a, 120b, 126, or 3304 can be a wired or wireless communication, cellular communication, Local Area Network (LAN), Wide Area Network (WLAN), Radio Frequency (RF), Infrared (IR), or any other communication method or system.

[0416] The user 102a or 102b can exchange a cryptographically signed digital check with the processing platform 124. For example, the sender 102a operating the check sender device 116a can be the buyer of a product or service from the seller, who is the receiver 102b operating the check receiver device 116b. Figure 33BThe content 110 of the digital check 100 may include instructions for transferring an amount of cryptocurrency (or real money) from the account of the sender 102a to the account of the recipient 102b, or instructions for the processing platform 124 to transfer an amount of cryptocurrency from the account of the sender 102a to the account of the recipient 102b (or from the account of the check sender device 116a to the account of the check recipient device 116b). The check sender device 116a may digitally sign the digital check 100 using the sender device private key and electronically transmit the digital check 100 to the recipient device 116b. The recipient device 116b approves the check with the approval 114 (for example, in this scenario, the approval may be a "deposit only approval") and digitally signs the digital check using the recipient device private key to create a modified digital check 100m1. The recipient device 116b transmits the modified digital check 100m1 to the service provider 104, which redeems the modified digital check 100m1.

[0417] The processing platform 124 can verify that the modified digital check 100m1 is authentically signed by the sender device 116a and the recipient device 116b (using their respective public keys). The processing platform 124 can then instruct the financial institution server 3304 to transfer the cryptocurrency amount from the sender 102a's account to the recipient 102b's account (or vice versa). The financial institution server 3304 can maintain the sender 102a's account and the recipient 102b's account. In some embodiments, the processing platform 124 can also track the sender 102a's account balance and the recipient 102b's account balance. Thus, in this non-limiting example, the record serves as a check in the digital check system and can be used by the buyer (sender 102a) to pay the seller (recipient 102b) for assets. The service provider 104 can act as a clearing house for at least some of these exchanges (e.g., debiting the buyer's cryptocurrency or real currency account and crediting the seller's cryptocurrency account).

[0418] Figure 33CAnother embodiment of securely exchanging cryptographically signed digital checks is schematically illustrated. After receiving a modified digital check 100m1, the processing platform 124 can verify that the modified digital check 100m1 is authentically signed by both the sender device 116a and the recipient device 116b (using their respective public keys). The processing platform 124 can then instruct a server 3304a at a financial institution to transfer a cryptocurrency amount from the sender 102a's account at a financial institution to the recipient 102b's account at another financial institution (or from the check sender device 116a's account at a financial institution to the check recipient device 116b's account at another financial institution). The financial institution server 3304a can maintain the sender 102a's account. The financial institution server 3304b can maintain the recipient 102b's account. After receiving the transfer of the cryptocurrency amount, the server 3304b at the other financial institution can update the balance of the recipient 102b's account (or the check recipient device 116b's account) at the other financial institution. In some implementations, the processing platform 124 may also track the account balance of the sender 102a and the account balance of the receiver 102b.

[0419] In some embodiments, some of the terms described herein may have the meanings as defined in 15 U.S.C. § 1693 (Consumer Protection Definitions). For example, a financial institution may be a state or national bank, a state or federal savings and loan association, a mutual savings bank, a state or federal credit union, or any other person that directly or indirectly holds an account belonging to a consumer. As another example, an account may be a checking account, a savings account, or other asset account (other than a credit balance).

[0420] Sample digital check

[0421] In some embodiments, a check recipient may receive a cryptographically signed digital check from a check sender. Figure 41 is an interaction diagram illustrating one embodiment of securely exchanging and redeeming individual records created for a record recipient. A check recipient 102b (e.g., a payee) using a check recipient device 116b can request a digital check 100 from a check sender 102a (e.g., a payee) by sending a payment request 402 to a check sender device 116a. At interaction 404, the check recipient 102b can send the payment request 402 to the check sender 102a using a short-range link (SRL) 122. The payment request 402 may include content such as a payment amount 110b and a public key 106b of the check recipient device. The payment amount 110b may be the amount that the check recipient 102b desires to receive from the check sender 102a. In some embodiments, the public key 106b of the check recipient device may uniquely identify the check recipient device 116b. In some embodiments, the public key 106b of the check recipient device may uniquely identify the check recipient 102b. The public key 106b may be in a public record, which in some embodiments may be stored in a secure element (SE) 204b.

[0422] Example Partner ID

[0423] refer to Figure 34A At interaction 408, check sender device 116a, using its transaction partner identifier, can confirm the identity of check recipient device 116b via partner identification. Because payment request 402 may have already been electronically sent to check recipient device 116a, check recipient device 116a may not be certain of the identity of the user device that sent payment request 402. Partner identification can be advantageous. For example, via partner identification, check sender device 116a can distinguish payment request 402 from check recipient device 116b and a malicious user. As another example, via partner identification, a malicious user cannot receive a digital check that is not intended for them. As another example, via partner identification, a malicious user cannot cash a digital check even after receiving a digital check that is not intended for them.

[0424] Sample Digital Check Creation

[0425] After the secure element (SE) 204a of the check sender device 116a verifies the record sender's authentication information, the secure element (SE) 204a may sign the digital check 100 at interaction 416. Before signing the individual record 100 at interaction 416, the secure element (SE) 204a may require both the block to be digitally signed (e.g., block 105a of the digital check 100) and authentication of the record sender 102a. Non-limiting examples of authentication may include password authentication, biometric authentication such as fingerprint authentication or iris authentication, biometric data authentication, or any combination thereof. Biometric authentication may utilize a biometric template based on, for example, a fingerprint or eye image. The secure element (SE) 204a may implement a biometric fuzzy library for recognizing biometric templates.

[0426] refer to Figure 33B , the digital check 100 may be a digital object including one or more blocks. The digital check 100 may include a block 105a, and the block 105a may include a public key 106a of a check sender device 116a in a "from field," a public key 106b of a check receiver device in a "to field," a check ID 108, a payment amount 110a, and a check sender signature 112a of the block 105a. The public key 106a of the check sender device 116a may identify the originator of the digital check 100, i.e., the check sender device 116a. The public key 106b of the check receiver device may identify the original recipient of the digital check 100, i.e., the check receiver device 116b. The payment amount 110a may vary. The payment amount 110a and Figure 34A The requested payment amount 110b in the transaction can be the same, similar, related, or different. In the context of cryptocurrency, the sent payment amount 110a and the requested payment amount 110b can be the same amount in cryptocurrency. The sent payment amount 110a and the requested payment amount 110b can be similar or related. For example, the requested payment amount 110b can be a pre-tax amount, and the sent payment amount 110a can be a post-tax amount. As another example, the requested payment amount 110b can be a pre-tip amount, and the sent payment amount 110a can be a post-tip amount.

[0427] refer to Figure 34AAt interaction 420, the check sender 102a may send the digital check 100 to the check recipient 102b in a peer-to-peer manner, for example, using a short-range link (SRL). Once with the check recipient 102b, the check recipient 102b may verify the digital check 100 at interaction 424. Verifying the digital check 100 may include authenticating the check sender signature 112a. Authenticating the check sender signature 112a may include using the check sender device's public key 106a to determine whether the check sender signature 112a has been created using the check sender device's private key 210. The check sender device's public key 106a may be obtained in a variety of ways. For example, the check sender device's public key 106a may be obtained from the digital check 100. As another example, the check sender device's public key 106a may be obtained from the check recipient device's public records 206.

[0428] Example Individual Record Exchange - A Financial Institution

[0429] refer to Figure 33B and Figure 34A After successfully verifying the digital check 100, the check recipient device 116b can use its secure element 204b to create and sign a modified digital check 100m1 at interaction 428. Before signing the modified digital check 100m1 at interaction 428, the secure element (SE) 204b can require both the block to be digitally signed (e.g., block 105b of the modified digital check 100m1) and the check recipient's authentication information 512b. The modified digital check 100m1 can include block 105a of the digital check 100 and an approval block 105b. For example, the approval can be a "For Deposit Only Approval" (FPOE) 114, which, together with the check recipient's public key 106b, specifies that the modified digital check 100m1 can only be redeemed by the check recipient 102b. In the context of cryptocurrency, upon receiving a “Deposit Only Authorization” (FDOE) digital check, the processing platform 124 may deposit or direct the deposit of the cryptocurrency amount into the account of the check recipient 102b but will not recognize further authorizations to the other party.

[0430] After signing the modified digital check 100m1, when the check recipient 102b communicates with the processing platform 124 via, for example, the network 118, the check recipient 102b may redeem the modified digital check 100m1 with the processing platform 124 at interaction 432. Upon redemption, the service provider 104 operating the processing platform 124 may process the modified individual record 100m1 at interaction 436 by verifying the authenticity of one or more signatures (e.g., the check sender signature 112a and the check recipient signature 112b) in the chain of blocks 105a and 105b in the modified digital check 100m1. Upon successful verification, the processing platform 124 may execute based on the payment amount 110a of the modified digital check 100m1.

[0431] The processing platform 124 can instruct the financial institution server 3304 to transfer the payment amount 110a, such as cryptocurrency or real currency, from the account of the sender 102a to the account of the recipient 102b (or from the account of the check sender device 116a to the account of the check recipient device 116b). The financial institution operating the server 3304a can maintain the accounts of the sender 102a and the recipient 102b. At interaction 3404, the processing platform 124 can instruct the financial institution or the server 3304a operated by the financial institution to debit the sender's account and credit the recipient's account with the payment amount 110a. After the processing platform 124 is authenticated and sufficient funds are available in the sender's account, the financial institution can debit the sender's account and credit the recipient's account with the payment amount 110a at interaction 3408. After receiving an indication from the financial institution server 3304a that the account has been debited and credited at interaction 3424, the processing platform 124 may send an indication to the recipient device 116b that the processing platform 124 has acted based on the sent payment amount 110a of the modified digital check 100m1 at interaction 3428. In some embodiments, the processing platform 124 may track the account balance of the sender 102a and the account balance of the recipient 102b and update the account balances after interaction 3424.

[0432] Example Individual Record Exchange - Multiple Financial Institutions

[0433] Figure 34B is an interactive diagram illustrating another embodiment of securely exchanging and redeeming cryptographically signed digital checks involving two financial institutions. Figure 34A describe Figure 34B 4. The payment request 402 and interactions 404, 408, 416, 420, 424, 428, 432, and 436 in FIG. After successful authentication at interaction 436, the processing platform 124 may execute based on the payment amount 110a of the modified digital check 100m1.

[0434] The processing platform 124 may instruct the financial institution server 3304 to transfer the sent payment amount 110a from the account of the sender 102a to the account of the recipient 102b (or from the account of the check sender device 116a to the account of the check recipient device 116b). The financial institution operating the server 3304a may maintain the account of the sender 102a. The financial institution operating the server 3304a may also maintain the account of the recipient 102b. At interaction 3404, the processing platform 124 may instruct the financial institution or the server 3304a operated by the financial institution to debit the sender's account and credit the recipient's account for the requested payment amount 110a. After verifying that sufficient funds are in the processing platform 124 and the sender's account, the financial institution may debit the sender's account at interaction 3408. The financial institution server 3304a may then request another financial institution or a server 3304b operated by another financial institution to credit the recipient's account for the sent payment amount 110a at interaction 3412. After successfully crediting the recipient account for the sent payment amount 110a at interaction 3412, server 3304b may send an indication to the financial institution's server 3304a that the recipient account was successfully credited.

[0435] After receiving an indication from the financial institution server 3304a that the account has been debited and credited at interaction 3424, the processing platform 124 may send an indication to the recipient device 116b that the processing platform 124 has executed the sent payment amount 110a based on the modified digital check 100m1 at interaction 3428. In some embodiments, the processing platform 124 may track the account balance of the sender 102a and the account balance of the recipient 102b and update the account balances after interaction 3424.

[0436] Example Payment Types

[0437] The payment from sender 102a to receiver 102b can be similar to a check transaction, a debit transaction, a credit card transaction, an automated clearing house (ACH) transaction, a wire transfer, or a combination thereof. Check-type transactions may require "terms," ​​for example, under the Uniform Commercial Code (UCC). A check transaction can be considered a contract between a financial institution (e.g., the financial institution operating server 3304a) and a customer (e.g., sender 102a) who has an account at the financial institution. (1) Payment can be completed immediately if processed over the counter at the financial institution (e.g., a virtual counter), or (2) payment can be completed at midnight on the day the financial institution receives the modified check 100m1. The financial institution may be liable for fraudulent activity or unauthorized payments unless the account holder is negligent.

[0438] Debit-type transactions can be considered exceptions to the UCC provision because debit transactions can involve a "signal" that completes the transaction. Payment can be completed at the time of sale (e.g., when the seller, payee, or check recipient receives a digital check), where the financial institution is immediately authorized to debit the account to the seller. In some embodiments, unauthorized payments are subject to a "deductible" liability for the check sender. For example, if the purported check sender reports the unauthorized payment within a short time period (e.g., two days), the deductible may be $50. If the purported check sender reports the unauthorized payment within a medium time period (e.g., 60 days), the deductible may be $500. If the unauthorized payment is not reported within the medium time period, the purported check sender is responsible for the unauthorized payment. Unless the account holder is negligent, the purported check sender's financial institution may be responsible for the remaining unauthorized balance.

[0439] With a credit card type transaction, payment is complete when the sender of the check pays the financial institution (e.g., the credit card company). If the statement has already been paid (two billing cycles to dispute), then disputing the charge may not be allowed. As long as the statement remains unpaid, the financial institution remains liable.

[0440] ACH transactions can include both credit ACH payments and debit ACH payments. For credit ACH payments, the financial institution can cancel the payment for any reason. For debit ACH payments, the account holder (e.g., the sender of a check) has one business day to stop the payment; otherwise, the payment goes through, and the customer has 15 days to notify the unauthorized payment. Payment can be taken into account at the time of sale, up to one day later for debit ACH payments, or up to two days later for credit ACH payments.

[0441] A wire transfer can be a transfer between financial institutions. The Electronic Funds Transfer Act allows wire transfers involving natural persons. A wire transfer involves a two-stage payment order: First, the payee or check sender provides transfer information to a first financial institution, such as a financial institution operating server 3304a (or processing platform 124), to transfer money to a second financial institution (e.g., another financial institution operating server 3304b). Second, the first financial institution can provide instructions to the second financial institution regarding the transfer. Regardless of whether the funds are actually transferred from the first financial institution to the second financial institution, the payment can be considered complete when step 2 is completed. Therefore, the check sender or payer has a very fast responsibility to the payee of the check recipient, but if they make a mistake in the transfer, the second financial institution may be held responsible.

[0442] In some embodiments, the systems and methods disclosed herein can be used for complex bargaining. For example, a seller or supplier may offer a debit transaction at one price because the seller can access funds more quickly. However, the buyer may act maliciously, and the seller may automatically block debit requests for goods under $50 due to the deductible threshold. As another example, a seller may request a wire transfer, knowing that verification between financial institutions will occur. However, the buyer may reject such a request because they may not want to pay the two-step transfer fee unless there is a fee sharing involved.

[0443] Example Wearable Display System

[0444] The user device 116 may be or may be included in a wearable display device that may advantageously provide a more immersive virtual reality (VR), augmented reality (AR), or mixed reality (MR) experience in which a digitally reproduced image or portion thereof is presented to the wearer in a manner that appears or may be perceived as real.

[0445] Without being limited by theory, it is believed that the human eye can generally interpret a finite number of depth planes to provide depth perception. Therefore, by providing the eye with a different presentation of an image corresponding to each of these finite number of depth planes, a highly convincing simulation of perceived depth can be achieved. For example, a display comprising a waveguide stack can be configured to be worn and positioned in front of the eyes of a user or observer. A waveguide stack can be utilized to provide a three-dimensional perception to the eye / brain by using multiple waveguides to direct light from an image injection device (e.g., the output of a discrete display or a multiplexed display that transmits image information via one or more optical fibers) to the eyes of an observer at specific angles (and divergences) corresponding to the depth planes associated with the particular waveguides.

[0446] In some embodiments, two waveguide stacks may be utilized, one for each eye of the observer, to provide a different image to each eye. As an example, an augmented reality scene may cause the wearer of the AR technology to see a real-world park-like setting featuring people, trees, buildings in the background, and a specific platform. In addition to these items, the wearer of the AR technology may also perceive that he "sees" a robotic statue standing on the real-world platform, and a flying, cartoon-like avatar character that appears to be an anthropomorphic representation of a bumblebee, even though the robotic statue and bumblebee do not exist in the real world. (Multiple) waveguide stacks may be used to generate a light field corresponding to an input image, and in some embodiments, the wearable display includes a wearable light field display. Examples of wearable display devices and waveguide stacks for providing light field images are described in U.S. Patent Publication No. 2015 / 0016777, the entire contents of which are incorporated herein by reference in their entirety.

[0447] Figure 35 An example of a wearable display system 3500 is shown that can be used to present an AR, MR, or VR experience to a wearer 3504. The wearable display system 3500 can be programmed to perform any application or embodiment described herein. The display system 3500 includes a display 3508, and various mechanical and electronic modules and systems that support the functionality of the display 3508. The display 3508 can be coupled to a frame 3512 that can be worn by a display system wearer or observer 3504 and is configured to position the display 3508 in front of the eyes of the wearer 3504. The display 3508 can be a light field display. In some embodiments, a speaker 35616 is coupled to the frame 3512 and, in some embodiments, is positioned adjacent to an ear canal of the user, with another speaker (not shown) positioned adjacent to the other ear canal of the user to provide stereo / shapeable sound control. The display 3508 is operably coupled 3520 to a local data processing module 3524, such as by a wired lead or a wireless connection, which can be mounted in various configurations, such as fixedly attached to the frame 3512, fixedly attached to a helmet or hat worn by the user, embedded in headphones, or otherwise removably attached to the user 3504 (e.g., a backpack configuration, a belt-connected configuration).

[0448] The local processing and data module 3524 can include a hardware processor, as well as non-transitory digital memory, such as non-volatile memory (e.g., flash memory), both of which can be used to assist in processing, caching, and storing data. The data includes data that is: (a) captured from a sensor (such as an image capture device (such as a camera), a microphone, an inertial measurement unit, an accelerometer, a compass, a GPS unit, a wireless device, and / or a gyroscope) (which can, for example, be operably coupled to the frame 3512 or otherwise attached to the wearer 3504); and / or (b) acquired and / or processed using the remote processing module 3528 and / or the remote data repository 3532, possibly for delivery to the display 3508 after such processing or acquisition. The local processing and data module 3524 can be operably coupled to the remote processing module 3528 and the remote data repository 3532 via communication links 3536, 3540 (such as via wired or wireless communication links), so that these remote modules 3528, 3532 are operably coupled to each other and can be used as resources for the local processing and data module 3524.

[0449] In some embodiments, the remote processing module 3528 may include one or more processors configured to analyze and process data and / or image information, such as video information captured by an image capture device. Video data may be stored locally in the local processing and data module 3524 and / or in a remote data repository 3532. In some embodiments, the remote data repository 3532 may include a digital data storage facility that may be available via the Internet or other network configuration in a "cloud" resource configuration. In some embodiments, all data is stored and all calculations are performed in the local processing and data module 3524, allowing for complete autonomous use from the remote module.

[0450] In some embodiments, local processing and data module 3524 and / or remote processing module 3528 are programmed to perform embodiments of the systems and methods disclosed herein. An image capture device can capture video for a particular application (e.g., video of the wearer's eyes for an eye tracking application or video of the wearer's hands or fingers for a gesture recognition application). The video can be analyzed by one or both of processing modules 3524, 3528. In some cases, offloading at least some of the analysis to a remote processing module (e.g., in the "cloud") can improve computational efficiency or speed. Parameters of the systems and methods disclosed herein can be stored in data modules 3524 and / or 3532.

[0451] The analysis results can be used by one or both of the processing modules 3524 and 3528 for additional operations or processing. For example, the wearable display system 3500 can use biometrics, eye tracking, recognition or classification of gestures, objects, postures, etc. For example, the wearable display system 3500 can analyze a captured video of the wearer's 3504 hand and recognize a gesture by the wearer's hand (e.g., picking up a real or virtual object, signaling approval or disapproval (e.g., "thumbs up" or "thumbs down"), etc.), and the wearable display system 3500 can perform an appropriate action in response to the wearer's gesture (e.g., moving a virtual object, performing additional operations based on the wearer's approval / disapproval). As another example, a video of the wearer's eyes can be analyzed by the wearable display system 3500 to determine the gaze direction of the wearer 3504 via the display 3508. As another example, the processing modules 3524 and 3528 can analyze a video of the wearer's surroundings to identify (or count) objects of a particular category of objects (e.g., identifying "cats" or "cars" near the wearer 3504). The processing modules 3524, 3528 of the wearable display system 3500 can be programmed to perform any of the methods or video or image processing applications described herein or any of the methods or applications for secure exchange of cryptographically signed records described herein. For example, an embodiment of the wearable display system 3500 can be configured as a user device 116a (e.g., sender 102a) or a user device 116b (e.g., receiver 102b) and used to create, send, receive, modify, or redeem a record 100 in a cryptographically secure manner as described herein.

[0452] Additional aspects

[0453] Secure exchange of cryptographically signed records

[0454] In a first aspect, a method for securely exchanging cryptographically signed records is disclosed. The method is executed under control of a hardware processor and includes: receiving a recipient individual record from a record receiver device, wherein the recipient individual record includes a sender individual record and a recipient signature of the recipient individual record; wherein, after receiving a record content request from the record receiver device and identifying the record receiver device, creating the sender individual record by the record sender device, wherein the sender individual record includes the record content, a sender public key of the record sender device, a recipient public key of the record receiver device, and a sender signature of the sender individual record; wherein, using the record sender device to generate a record content request, the sender individual record includes a sender public key of the record sender device, a recipient public key of the record receiver device, and a sender signature of the sender individual record; wherein, using the record sender device to generate a record content request, the sender individual record includes a sender public key of the record sender device, a recipient public key of the record receiver device, and a sender signature of the sender individual record; wherein, The processing platform comprises: a processing platform for executing a recording receiver device and a processing platform for executing a recording receiver device; ...

[0455] In a second aspect, the method of aspect 1, wherein the content request includes a recipient public key and the requested content, and wherein the recorded content is related to the requested content.

[0456] In aspect 3, a method according to any one of aspects 1-2, wherein identifying the recording recipient device includes performing partner identification, wherein the partner identification includes content authorization, tapping, physical indication, beamforming, prior arrangement, rough verification or any combination thereof.

[0457] In a fourth aspect, the method according to any one of aspects 1-3, wherein the sender individual record further comprises a record identifier.

[0458] In a fifth aspect, the method according to aspect 4, wherein the record identifier is a monotonically increasing number.

[0459] In a sixth aspect, the method according to any one of aspects 1-5, wherein receiving the sender individual record from the record receiver device comprises receiving the sender individual record from the record sender device via a short-range link directly or through an intermediate device.

[0460] In a seventh aspect, the method of aspect 6, wherein the short range link is a peer to peer communication link.

[0461] In an eighth aspect, the method according to any one of aspects 1-7, wherein the recipient individual record further comprises a redemption-only endorsement, a query endorsement, a malicious record endorsement, or any combination thereof.

[0462] In aspect 9, a method according to any one of aspects 1-8, wherein a sender individual record is created by a record sender device after receiving authentication information of a record sender, and wherein a receiver individual record is created by a record receiver device after receiving authentication information of a record receiver.

[0463] In aspect 10, the method according to any one of aspects 1-9, wherein verifying the sender individual record comprises: using the sender public key to determine the use of the sender private key to create the sender signature; and using the sender public key to determine the use of the sender private key to create the sender signature.

[0464] In an eleventh aspect, the method according to any one of aspects 1-10 further comprises providing a public record to the record sender device or the record receiver device, wherein the public record comprises a sender public key and a receiver public key.

[0465] In aspect 12, the method according to any one of aspects 1-10 further comprises: providing a public record to a record sender device, wherein the public record comprises a sender public key and a receiver public key; and causing the record sender device to send the public record to the record receiver device.

[0466] In aspect 13, the method according to any one of aspects 1-10 further comprises: providing a public record to a record receiver device, wherein the public record comprises a sender public key and a receiver public key; and causing the record receiver device to send the public record to the record sender device.

[0467] In a 14th aspect, the method of any of aspects 11-13, wherein the public record further comprises a third signature of the public record, wherein the public record further comprises a third signature of the public record, and wherein the third signature is created using a third private key of the processing platform.

[0468] In aspect 15, the method according to any one of aspects 11-14 further includes: generating a public record from a central record, wherein the central record includes a sender public key, a receiver public key, a user record status of the record sender device, and a user record status of the record receiver device.

[0469] In a 16th aspect, the method of aspect 15 further comprises: determining that the record sender's user record status prohibits the processing platform from performing the record recipient device as indicated by the recipient individual record; and adding the payer device to the delinquency list.

[0470] In a seventeenth aspect, a method for securely exchanging cryptographically signed records is disclosed. The method is executed under the control of a hardware processor and includes: receiving a content request from a recording receiver device; identifying the recording receiver device; creating a sender individual record, wherein the sender individual record includes the recording content, the sender public key of the recording sender device, the receiver public key of the recording receiver device, and the sender signature of the sender individual record, wherein the sender signature is created using the sender private key of the recording sender device, and wherein the sender public key and the sender private key form a sender public key encryption pair; sending the sender individual record to the recording receiver device; and receiving an instruction from the recording receiver device to: receive the sender individual record; verify the sender individual record using the sender public key without necessarily communicating with a processing platform; creating a receiver individual record, wherein the receiver individual record includes the sender individual record and the receiver signature of the receiver individual record, wherein the receiver signature is created using the receiver private key of the recording receiver device, and wherein the receiver public key and the receiver private key form a receiver public key encryption pair; exchanging the receiver individual record with the processing platform; and receiving execution of the processing platform as indicated by the receiver individual record.

[0471] In an 18th aspect, the method of aspect 17, wherein the content request includes a recipient public key and the requested content, and wherein the recorded content is related to the requested content.

[0472] In aspect 19, the method of any of aspects 17-18, wherein identifying the recording recipient device comprises performing partner identification, wherein the partner identification comprises content authorization, tapping, physical indication, beamforming, prior placement, rough verification, or any combination thereof.

[0473] In aspect 20, the method according to any one of aspects 17-19, wherein the sender individual record further comprises a record identifier.

[0474] In aspect 21, the method of aspect 20, wherein the record identifier is a monotonically increasing number.

[0475] In a 22nd aspect, the method according to any one of aspects 17-21, wherein sending the sender individual record to the record recipient device comprises sending the sender individual record to the record recipient device via a short-range link directly or through an intermediate device.

[0476] In a 23rd aspect, the method of aspect 22, wherein the short range link is a peer to peer communication link.

[0477] In a 24th aspect, the method of any of aspects 17-23, wherein the recipient individual record further comprises a redemption-only endorsement, a query endorsement, a malicious record endorsement, or any combination thereof.

[0478] In aspect 25, the method of aspect 24, wherein the recipient individual record further comprises a query acknowledgment, wherein executing on the record recipient device as indicated by the recipient individual record comprises sending a query result to the record recipient device, and wherein the query result indicates that the processing platform will execute as indicated by the recipient individual record.

[0479] In aspect 26, a method according to any of aspects 17-25, wherein creating a sender individual record includes receiving authentication information of the record sender by the record sender device, and wherein creating a recipient individual record includes receiving authentication information of the record recipient by the record recipient device.

[0480] In a 27th aspect, the method of any of aspects 17-26, wherein verifying the sender individual record comprises using the sender public key to determine the sender signature was created using the sender private key.

[0481] In aspect 28, the method of any of aspects 17-27, wherein the sender signature is created by a secure element of record sender device using a sender private key, and wherein the sender private key is stored in the secure element of record sender device.

[0482] In aspect 29, the method of any of aspects 17-28, wherein the recipient signature is created by a secure element of the recipient device of record using a recipient private key, and wherein the recipient private key is stored in the secure element of the recipient device of record.

[0483] In a 30th aspect, the method of any of aspects 17-29 further comprises receiving a public record from the processing platform, wherein the public record comprises a sender public key and a recipient public key.

[0484] In a 31st aspect, the method of any of aspects 17-29 further comprises receiving a public record from a record recipient device, wherein the public record comprises a sender public key and a recipient public key.

[0485] In aspect 32, the method of any of aspects 30-31, wherein the public record further comprises a third signature of the public record, wherein the third signature is created using a third private key of the processing platform, the method further comprising verifying the public record using the third public key of the processing platform without necessarily communicating with the processing platform, wherein the third public key and the third private key form a third public key encryption pair, and wherein verifying the public record comprises using the third public key to determine that the third signature was created using the third private key.

[0486] In a 33rd aspect, a method for securely exchanging cryptographically signed records is provided. The method is executed under the control of a hardware processor and includes: sending a content request to a record sender device; receiving a sender individual record from the record sender device, wherein, after receiving the content request from the record receiver device and identifying the record receiver device, the record sender device creates a sender individual record, wherein the sender individual record includes the record content, the sender public key of the record sender device, the receiver public key of the record receiver device, and the sender signature of the sender individual record, wherein the sender signature is created using the sender private key of the record sender device, and wherein the sender public key and the sender private key form a sender public key encryption pair; verifying the sender individual record using the sender public key without necessarily communicating with a processing platform; creating a receiver individual record, wherein the receiver individual record includes the sender individual record and the receiver signature of the receiver individual record, and wherein the receiver signature is created using the receiver private key of the record receiver device, and wherein the receiver public key and the receiver private key form a receiver public key encryption pair; exchanging the receiver individual record with the processing platform; and receiving execution of the processing platform as indicated by the receiver individual record.

[0487] In a 34th aspect, the method of aspect 33, wherein the content request includes a recipient public key and the requested content, and wherein the recorded content is related to the requested content.

[0488] In aspect 35, the method of any of aspects 33-34, wherein identifying the payee device comprises performing partner identification, wherein the partner identification comprises payment authorization, tapping, physical indication, beamforming, prior placement, rough confirmation, or any combination thereof.

[0489] In aspect 36, the method according to any one of aspects 33-35, wherein the sender individual record further comprises a record identifier.

[0490] In aspect 37, the method of aspect 36, wherein the record identifier is a monotonically increasing number.

[0491] In a 38th aspect, the method of any of aspects 33-37, wherein receiving the sender individual record from the record sender device comprises receiving the sender individual record from the record sender device via a short-range link directly or through an intermediary device.

[0492] In a 39th aspect, the method of aspect 38, wherein the short range link is a peer to peer communication link.

[0493] In a 40th aspect, the method of any of aspects 33-39, wherein the recipient individual record further comprises a redemption-only endorsement, a query endorsement, a malicious record endorsement, or any combination thereof.

[0494] In aspect 41, a method according to any of aspects 33-40, wherein the sender individual record is created after the record sender device receives the authentication information of the record sender, and wherein creating the recipient individual record includes receiving the authentication information of the record receiver by the record receiver device.

[0495] In a 42nd aspect, the method of any of aspects 33-41, wherein verifying the sender individual record comprises using the sender public key to determine the sender signature was created using the sender private key.

[0496] In a 43rd aspect, the method of any of aspects 33-42, wherein the sender signature is created using a secure element of a device of record sender using a sender private key, and wherein the sender private key is stored in the secure element of the device of record sender.

[0497] In aspect 44, the method of any of aspects 33-43, wherein the recipient signature is created using a secure element of the recipient device of record using a recipient private key, and wherein the recipient private key is stored in the secure element of the recipient device of record.

[0498] In a 45th aspect, the method of any of aspects 33-44 further comprises receiving a public record from the processing platform, wherein the public record comprises a sender public key and a recipient public key.

[0499] In a 46th aspect, the method of aspect 45 further comprises sending the public record to the record sender device.

[0500] In a 47th aspect, the method according to any of aspects 33-44, further comprising receiving a public record from a record sender device, wherein the public record comprises a sender public key and a recipient public key.

[0501] In aspect 48, the method of any of aspects 45-47, wherein the public record further comprises a third signature of the public record, and wherein the third signature is created using a third private key of the processing platform, the method further comprising verifying the public record using the third public key of the processing platform without necessarily communicating with the processing platform, wherein the third public key and the third private key form a third public key encryption pair, and wherein verifying the public record comprises using the third public key to determine that the third signature was created using the third private key.

[0502] In aspect 49, a computer system is disclosed, comprising: a hardware processor; and a non-transitory memory having instructions stored thereon, the instructions, when executed by the processor, causing the processor to perform the method of any one of aspects 1-48.

[0503] In a 50th aspect, the computer system of aspect 49, wherein the computer system is a mobile device.

[0504] In a 51st aspect, the computer system of aspect 50, wherein the mobile device is a wearable display system.

[0505] Secure exchange of cryptographically signed records of proxies

[0506] In aspect 52, a method for securely exchanging encrypted signed records by an agent is disclosed. The method is executed under control of a hardware processor and comprises: receiving a master-modified individual record from a master device, wherein the master-modified individual record comprises an agent-modified individual record and a signature of the master-modified individual record, wherein the agent-modified individual record comprises an original individual record, an agent public key of the agent device, and a signature of the agent-modified individual record, wherein the original individual record comprises record content, a sender public key of a record sender device, a master public key of the master device, and the signature of the original individual record, wherein the signature of the master-modified individual record is created using a master private key of the master device, and wherein the master public key and the master private key form a master public key encryption pair, wherein in After receiving the original individual record from the master device, a proxy-modified individual record is created by the proxy device, wherein a signature of the proxy-modified individual record is created using the proxy private key of the proxy device, wherein the proxy public key and the proxy private key form a proxy public key encryption pair, and wherein, after receiving a content request from the proxy device and identifying the proxy device, the original individual record is created by the record sender device, wherein the signature of the original individual record is created using the sender private key of the record sender device, and wherein the sender public key and the sender private key form a sender public key encryption pair; verifies the master-modified individual record; and executes the master device as indicated by the master-modified individual record.

[0507] In a 53rd aspect, the method of aspect 52, wherein the content request comprises a master public key and the requested content, wherein the recorded content is related to the requested content.

[0508] In aspect 54, the method of any of aspects 52-53, wherein identifying the proxy device comprises performing partner identification, wherein the partner identification comprises payment authorization, tapping, physical indication, beamforming, prior placement, coarse verification, or any combination thereof.

[0509] In aspect 55, the method of aspect 54, wherein the original individual record further comprises a record identifier.

[0510] In aspect 56, the method of aspect 55, wherein the record identifier is a monotonically increasing number.

[0511] In a 57th aspect, the method of any of aspects 52-56, wherein receiving the original individual record from the record sender device comprises receiving the original individual record from the record sender device via a short-range link directly or through an intermediary device.

[0512] In a 58th aspect, the method of aspect 57, wherein the short range link is a peer to peer communication link.

[0513] In aspect 59, a method according to any of aspects 52-58, wherein the individual record modified by the agent further includes processing by an approval, a query approval, a malicious record approval, or any combination thereof, and wherein the individual record modified by the master further includes an approval for redemption only, a query approval, a malicious record approval, or any combination thereof.

[0514] In aspect 60, a method according to any of aspects 52-59, wherein the original individual record is created by the record sender device after the record sender device receives the authentication information of the record sender, and wherein the agent-modified individual record is created by the agent device after the agent device receives the authentication information of the agent.

[0515] In aspect 61, a method according to any one of aspects 52-60, wherein verifying the original individual record includes: using the sender public key to determine the signature of the original individual record created using the sender private key; using the proxy public key to determine the signature of the proxy-modified individual record created using the proxy private key; and using the master public key to determine the signature of the master device created using the master private key.

[0516] In a 62nd aspect, the method according to any of aspects 52-61 further comprises providing a public record to the record sender device, the proxy device and the master device, wherein the public record comprises a sender public key and a master public key.

[0517] In a 63rd aspect, the method of any of aspects 52-61 further comprises providing the public record to the record sender device, wherein the public record comprises the sender public key and the master public key; and causing the record sender device to provide the public record to the agent.

[0518] In a 64th aspect, the method of any of aspects 52-61 further comprises providing the public record to the agent, wherein the public record comprises the sender public key and the master public key; and causing the agent to provide the public record to the record sender device.

[0519] In a 65th aspect, the method of any of aspects 52-61 further comprises providing the public record to the master device, wherein the public record comprises the sender public key and the master public key; and causing the master device to provide the public record to the agent.

[0520] In a 66th aspect, the method of aspect 65 further comprises causing the agent to provide the public record to the record sender device.

[0521] In aspect 67, the method of any of aspects 62-66, wherein the public record further comprises a public record signature, wherein the public record signature is created using a processing platform private key of the processing platform, the method further comprising verifying the public record using the processing platform public key of the processing platform without necessarily communicating with the processing platform, wherein the processing platform public key and the processing platform private key form a processing platform public key encryption pair, and wherein verifying the public record comprises using the processing platform public key to determine that the public record signature was created using the processing platform private key.

[0522] In aspect 68, the method according to any one of aspects 62-67 further includes: generating a public record from a central record, wherein the central record includes the sender public key, the master public key, the proxy public key, the user record state of the record sender device, and the user record state of the master device.

[0523] In a 69th aspect, the method according to any one of aspects 52-68 further comprises charging a fee to the merchant for the proxy public key encryption pair or the master encryption pair periodically or once.

[0524] In aspect 70, a method for securely exchanging encrypted signature records through a proxy is disclosed. The method is executed under the control of a hardware processor and includes: receiving a content request from a proxy device; identifying the proxy device; creating an original individual record, wherein the original individual record includes the record content, a sender public key of the record sender device, a master public key of the master device, and a signature of the original individual record, wherein the signature of the original individual record is created using a sender private key of the record sender device, and wherein the sender public key and the sender private key form a sender public key encryption pair; sending the original individual record to the proxy device; receiving an instruction from the proxy device to receive the original individual record; verifying the original individual record using the sender public key without necessarily communicating with the processing platform; creating an agent-modified individual record, wherein the agent-modified individual record includes the original individual record, the proxy device's The agent public key and the signature of the agent-modified individual record, wherein the signature of the agent-modified individual record is created using the agent private key of the agent device, and wherein the agent public key and the agent private key form an agent public key encryption pair; and sending the agent-modified individual record to the master device; and receiving an instruction from the master device: receiving the agent-modified individual record; creating a master-modified individual record, wherein the master-modified individual record includes the agent-modified individual record and the signature of the master-modified individual record, wherein the signature of the master-modified individual record is created using the master private key of the master device, and wherein the master public key and the master private key form a master public key encryption pair; exchanging the master-modified individual record with the processing platform; receiving execution of the processing platform as indicated by the master-modified individual record; and notifying the agent device to receive the execution.

[0525] In aspect 71, the method of aspect 70, wherein the content request comprises a master public key and the requested content, wherein the recorded content is related to the requested content.

[0526] In aspect 72, the method of any of aspects 70-71, wherein identifying the proxy device comprises performing partner identification, wherein the partner identification comprises payment authorization, tapping, physical indication, beamforming, prior placement, coarse verification, or any combination thereof.

[0527] In aspect 73, the method of any one of aspects 70-72, wherein the original individual record further comprises a record identifier.

[0528] In aspect 74, the method of aspect 73, wherein the record identifier is a monotonically increasing number.

[0529] In a 75th aspect, the method of any one of aspects 70-74, wherein sending the original individual record to the proxy device comprises sending the original individual record to the proxy device via a short-range link directly or through an intermediary device.

[0530] In a 76th aspect, the method of aspect 75, wherein the short range link is a peer to peer communication link.

[0531] In aspect 77, a method according to any of aspects 70-76, wherein the individual record modified by the agent further includes an approval process, a query approval, a malicious record approval, or any combination thereof, and wherein the individual record modified by the master further includes an approval for redemption only, a query approval, a malicious record approval, or any combination thereof.

[0532] In aspect 78, a method according to any of aspects 70-77, wherein creating the original individual record includes receiving, by the record sender device, authentication information of the record sender, and wherein creating the agent-modified individual record includes receiving, by the agent device, authentication information of the agent.

[0533] In a 79th aspect, the method of any of aspects 70-78, wherein verifying the original individual record comprises using the sender public key to determine a signature of the original individual record created using the sender private key.

[0534] In aspect 80, the method of any of aspects 70-79, wherein the signature of the original individual record is created by a secure element of the record sender device using a sender private key, and wherein the sender private key is stored in the secure element of the record sender device.

[0535] In aspect 81, the method of any of aspects 70-80, wherein the signature of the proxy-modified individual record is created by a secure element of the proxy device using a proxy private key, and wherein the proxy private key is stored in the secure element of the proxy device.

[0536] In aspect 82, the method according to any of aspects 70-81 further comprises receiving a public record from the processing platform, wherein the public record comprises a sender public key and a master public key.

[0537] In an 83rd aspect, the method according to any of aspects 70-81 further comprises receiving a public record from the proxy device, wherein the public record comprises a sender public key and a master public key.

[0538] In aspect 84, the method of any of aspects 82-83, wherein the public record further comprises a public record signature, wherein the public record signature is created using a processing platform private key of the processing platform, the method further comprising verifying the public record using the processing platform public key of the processing platform without necessarily communicating with the processing platform, wherein the processing platform public key and the processing platform private key form a processing platform public key encryption pair, and wherein verifying the public record comprises using the processing platform public key to determine that the public record signature was created using the processing platform private key.

[0539] In aspect 85, a method for securely exchanging cryptographically signed records through a proxy is disclosed. The method is executed under control of a hardware processor and includes: sending a content request to a record sender device; receiving an original individual record from the record sender device, wherein the original individual record is created by the record sender device after receiving the content request from the record sender device and identifying the proxy device, wherein the original individual record includes the record content, a sender public key of the record sender device, a master public key of the master device, and a signature of the original individual record, wherein the signature of the original individual record is created using a sender private key of the record sender device, and wherein the sender public key and the sender private key form a sender public key encryption pair; verifying the original individual record using the sender public key without necessarily communicating with a processing platform; creating a proxy-modified individual record, wherein the proxy-modified individual record including an original individual record, a proxy public key of a proxy device, and a signature of an agent-modified individual record, wherein the signature of the agent-modified individual record is created using a proxy private key of the proxy device, and wherein the proxy public key and the proxy private key form an agent public key encryption pair; sending the agent-modified individual record to a master device; and receiving an instruction from the master device: receiving the agent-modified individual record; creating a master-modified individual record, wherein the master-modified individual record includes the proxy-modified individual record and the signature of the master-modified individual record, wherein the signature of the master-modified individual record is created using the master private key of the master device, and wherein the master public key and the master private key form a master public key encryption pair; exchanging the master-modified individual record with a processing platform; and receiving execution of the processing platform as indicated by the master-modified individual record.

[0540] In aspect 86, the method of aspect 85, wherein the content request comprises a master public key and the requested content, wherein the recorded content is related to the requested content.

[0541] In aspect 87, the method of any of aspects 85-86, wherein identifying the proxy device comprises performing partner identification, wherein the partner identification comprises payment authorization, tapping, physical indication, beamforming, prior placement, coarse verification, or any combination thereof.

[0542] In aspect 88, the method according to any one of aspects 85-87, wherein the original individual record further comprises a record identifier.

[0543] In aspect 89, the method of aspect 88, wherein the record identifier is a monotonically increasing number.

[0544] In a 90th aspect, the method of any one of aspects 85-89, wherein receiving the original individual record from the record sender device comprises receiving the original individual record from the record sender device via a short-range link directly or through an intermediary device.

[0545] In a 91st aspect, the method of aspect 90, wherein the short range link is a peer to peer communication link.

[0546] In aspect 92, a method according to any of aspects 85-91, wherein the individual record modified by the agent further includes processing by an approval, a query approval, a malicious record approval, or any combination thereof, and wherein the individual record modified by the master further includes an approval for redemption only, a query approval, a malicious record approval, or any combination thereof.

[0547] In aspect 93, a method according to any of aspects 85-92, wherein creating the original individual record includes receiving, by the record sender device, authentication information of the record sender, and wherein creating the agent-modified individual record includes receiving, by the agent device, authentication information of the agent.

[0548] In a 94th aspect, the method of any of aspects 85-93, wherein verifying the original individual record comprises using the sender public key to determine a signature of the original individual record created using the sender private key.

[0549] In aspect 95, the method of any of aspects 85-94, wherein the signature of the original individual record is created by a secure element of the record sender device using a sender private key, and wherein the sender private key is stored in the secure element of the record sender device.

[0550] In aspect 96, the method of any of aspects 85-95, wherein the signature of the proxy-modified individual record is created by the secure element of the proxy device using the proxy private key, and wherein the proxy private key is stored in the secure element of the proxy device.

[0551] In a 97th aspect, the method according to any of aspects 85-96, further comprising receiving a public record from the processing platform, wherein the public record comprises a sender public key and a master public key.

[0552] In a 98th aspect, the method of aspect 97 further comprises sending the public record to the record sender device.

[0553] In a 99th aspect, the method according to any of aspects 85-96, further comprising receiving a public record from the master device, wherein the public record comprises a sender public key and a master public key.

[0554] In aspect 100, the method of any of aspects 97-99, wherein the public record further comprises a public record signature, wherein the public record signature is created using a processing platform private key of the processing platform, the method further comprising verifying the public record using the processing platform public key of the processing platform without necessarily communicating with the processing platform, wherein the processing platform public key and the processing platform private key form a processing platform public key encryption pair, and wherein verifying the public record comprises using the processing platform public key to determine that the public record signature was created using the processing platform private key.

[0555] In aspect 101, a computer system is disclosed, comprising: a processor; and a non-transitory memory having instructions stored thereon, the instructions causing the processor to perform the method of any one of aspects 52-100 when executed by the processor.

[0556] In aspect 102, the computer system of aspect 101, wherein the computer system is a mobile device.

[0557] In a 103rd aspect, the computer system of aspect 102, wherein the mobile device is a wearable display system.

[0558] Secure exchange of cryptographically signed record chains

[0559] In aspect 104, a method for securely exchanging a chain of cryptographically signed records is disclosed. The method is executed under control of a hardware processor and includes: receiving a subsequent recipient individual record from a subsequent record recipient device, wherein the subsequent recipient individual record includes an original recipient individual record and a subsequent recipient signature of the subsequent recipient individual record, wherein the original recipient individual record includes a sender individual record, a subsequent recipient public key of the subsequent record recipient device, and an original recipient signature of the original recipient individual record, wherein the sender individual record includes record content, a sender public key of the record sender device, an original recipient public key of the original record recipient device, and a sender signature of the sender individual record, wherein the sender individual record is created by the record sender device after receiving an original content request from the original record recipient device and identifying the original record recipient device, wherein the record is created using A sender private key of a sender device creates a sender signature, and wherein the sender public key and the sender private key form a sender public key encryption pair, wherein, after receiving a subsequent content request from a subsequent record recipient device and identifying the subsequent record recipient device, an original recipient individual record is created by the original record recipient device, wherein an original recipient signature is created using the original recipient private key of the original record recipient device, and wherein the original recipient public key and the original recipient private key form an original recipient public key encryption pair, wherein a subsequent recipient signature is created using the subsequent record recipient device's subsequent recipient private key, and wherein the subsequent recipient public key and the subsequent recipient private key form a subsequent recipient public key encryption pair; verifies the subsequent recipient individual record; and executes the subsequent record recipient as indicated by the subsequent recipient individual record.

[0560] In aspect 105, the method of aspect 104, wherein the original content request comprises an original recipient public key and the original content, wherein the recorded content is related to the original content, wherein the subsequent content request comprises a subsequent recipient public key and the subsequent content, wherein the original content is related to the subsequent content.

[0561] In aspect 106, the method of any of aspects 104-105, wherein identifying the original content requester or identifying the subsequent content requester comprises performing partner identification, wherein the partner identification comprises content authorization, tapping, physical indication, beamforming, prior placement, coarse verification, or any combination thereof.

[0562] In aspect 107, the method according to any one of aspects 104-106, wherein the sender individual record further comprises a record identifier.

[0563] In aspect 108, the method of aspect 107, wherein the record identifier is a monotonically increasing number.

[0564] In aspect 109, a method according to any one of aspects 104-108, wherein the sender individual record is sent by the record sender device to the original record recipient device directly or through an intermediate device via a first short-range link, and wherein sending the original recipient individual record to the subsequent record recipient device includes sending the original recipient individual record to the subsequent record recipient device directly or through an intermediate device via a second short-range link.

[0565] In aspect 110, the method of aspect 109, wherein the first short range link is a peer to peer communication link, or wherein the second short range link is a peer to peer communication link.

[0566] In aspect 111, the method of any of aspects 104-110, wherein the subsequent recipient individual record further comprises a redemption-only endorsement, a query endorsement, a malicious record endorsement, or any combination thereof.

[0567] In aspect 112, a method according to any one of aspects 104-111, wherein the sender individual record is created by the record sender device after receiving authentication information of the record sender, wherein the original recipient individual record is created by the original record recipient device after receiving authentication information of the original record recipient device, and wherein the subsequent recipient individual record is created by the subsequent record recipient device after receiving authentication information of the subsequent record recipient device.

[0568] In aspect 113, the method according to any of aspects 104-112, wherein verifying the subsequent recipient individual record includes: using the sender public key to determine the use of the sender private key to create the sender signature; using the original recipient public key to determine the use of the original recipient private key to create the original recipient signature; and using the subsequent recipient public key to determine the use of the subsequent recipient private key to create the subsequent recipient signature.

[0569] In aspect 114, a method according to any one of aspects 104-113, wherein a sender signature is created by a secure element of a recording sender device using a sender private key, wherein the sender private key is stored in a secure element of the recording sender device, wherein an original recipient signature is created by a secure element of an original recording recipient device using the original recipient private key, wherein the original recipient private key is stored in a secure element of the original recording recipient device, wherein a subsequent recipient signature is created by a secure element of a subsequent recording recipient device using the subsequent recipient private key, and wherein the subsequent recipient private key is stored in a secure element of a subsequent recording recipient device.

[0570] In aspect 115, a method for securely exchanging a chain of cryptographically signed records is disclosed. The method is executed under the control of a hardware processor and includes: receiving an original content request from an original record recipient device; identifying the original record recipient device; creating a sender individual record, wherein the sender individual record includes the record content, a sender public key of the record sender device, an original recipient public key of the original record recipient device, and a sender signature of the sender individual record, wherein the sender signature is created using a sender private key of the record sender device, and wherein the sender public key and the sender private key form a sender public key encryption pair; sending the sender individual record to the original content requester; and receiving an instruction from the original content requester to: receive the sender individual record; verify the sender individual record using the sender public key without necessarily communicating with a processing platform; receiving a subsequent content request from a subsequent record recipient device; identifying the subsequent record recipient device; creating the original recipient individual record, wherein the original recipient individual record includes the sender individual record, the subsequent recipient public key of the subsequent record recipient device, and the subsequent recipient public key of the subsequent record recipient device. , and an original recipient signature of the original recipient individual record, wherein the original recipient signature is created using the original recipient private key of the original record recipient device, and wherein the original recipient public key and the original recipient private key form an original recipient public key encryption pair; sending the original recipient individual record to the subsequent record recipient device; and receiving an instruction from the subsequent record recipient: receiving the original recipient individual record; verifying the original recipient individual record using the sender public key and the original recipient public key without necessarily communicating with the processing platform; creating a subsequent recipient individual record, wherein the subsequent recipient individual record includes the original recipient individual record and a subsequent recipient signature of the subsequent recipient individual record, wherein the subsequent recipient signature is created using the subsequent recipient private key of the subsequent record recipient device, and wherein the subsequent recipient public key and the subsequent recipient private key form a subsequent recipient public key encryption pair; exchanging the original recipient individual record with the processing platform; and receiving execution of the processing platform as indicated by the subsequent recipient individual record.

[0571] In aspect 116, the method of aspect 115, wherein the original content request comprises an original recipient public key and the original content, wherein the recorded content is related to the original content, wherein the subsequent content request comprises a subsequent recipient public key and the subsequent content, wherein the original content is related to the subsequent content.

[0572] In aspect 117, the method of any of aspects 115-116, wherein identifying the original content requester or identifying the subsequent content requester comprises performing partner identification, wherein the partner identification comprises content authorization, tapping, physical indication, beamforming, prior placement, coarse verification, or any combination thereof.

[0573] In aspect 118, the method according to any one of aspects 115-117, wherein the sender individual record further comprises a record identifier.

[0574] In aspect 119, the method of aspect 118, wherein the record identifier is a monotonically increasing number.

[0575] In aspect 120, a method according to any one of aspects 115-119, wherein sending the sender individual record to the original record recipient device includes sending the sender individual record to the original record recipient device directly or through an intermediate device via a first short-range link, and wherein sending the original recipient individual record to the subsequent record recipient device includes sending the original recipient individual record to the subsequent record recipient device directly or through an intermediate device via a second short-range link.

[0576] In aspect 121, the method of aspect 120, wherein the first short range link is a peer to peer communication link, or wherein the second short range link is a peer to peer communication link.

[0577] In aspect 122, the method of any of aspects 115-121, wherein the subsequent recipient individual record further comprises a redemption-only endorsement, a query endorsement, a malicious record endorsement, or any combination thereof.

[0578] In aspect 123, a method according to any one of aspects 115-122, wherein creating a sender individual record includes receiving authentication information of the record sender by the record sender device, wherein creating an original recipient individual record includes receiving authentication information of the original record recipient by the original record recipient device, and wherein creating a subsequent recipient individual record includes receiving authentication information of the subsequent record recipient by the subsequent record recipient device.

[0579] In aspect 124, a method according to any of aspects 115-123, wherein verifying the sender individual record includes using the sender public key to determine the use of the sender private key to create the sender signature, and wherein verifying the original recipient individual record includes using the original recipient public key to determine the use of the original recipient private key to create the original recipient signature.

[0580] In aspect 125, a method according to any one of aspects 115-124, wherein a sender signature is created by a secure element of a recording sender device using a sender private key, wherein the sender private key is stored in a secure element of the recording sender device, wherein an original recipient signature is created by a secure element of an original recording recipient device using the original recipient private key, wherein the original recipient private key is stored in a secure element of the original recording recipient device, wherein a subsequent recipient signature is created by a secure element of a subsequent recording recipient device using a subsequent recipient private key, and wherein the subsequent recipient private key is stored in a secure element of a subsequent recording recipient device.

[0581] In aspect 126, a method for securely exchanging a chain of cryptographically signed records is disclosed. The method is executed under the control of a hardware processor and includes: sending an original content request to a record sender device; receiving a sender individual record from the record sender device, wherein the sender individual record includes the record content, a sender public key of the record sender device, an original receiver public key of the original record receiver device, and a sender signature of the sender individual record, wherein the sender signature is created using a sender private key of the record sender device, and wherein the sender public key and the sender private key form a sender public key encryption pair; verifying the sender individual record using the sender public key without necessarily communicating with a processing platform; receiving a subsequent content request from a subsequent record receiver device; identifying a subsequent record receiver device; creating an original receiver individual record, wherein the original receiver individual record includes the sender individual record, the subsequent receiver public key of the subsequent record receiver device, and the original receiver signature of the original receiver ... Creating an original recipient signature using the original recipient private key of the original record recipient device, and wherein the original recipient public key and the original recipient private key form an original recipient public key encryption pair; sending the original recipient individual record to the subsequent record recipient device; and receiving instructions from the subsequent record recipient: receiving the original recipient individual record; verifying the original recipient individual record using the sender public key and the original recipient public key without necessarily communicating with the processing platform; creating a subsequent recipient individual record, wherein the subsequent recipient individual record includes the original recipient individual record and a subsequent recipient signature of the subsequent recipient individual record, wherein the subsequent recipient signature is created using the subsequent recipient private key of the subsequent record recipient device, and wherein the subsequent recipient public key and the subsequent recipient private key form a subsequent recipient public key encryption pair; exchanging the original recipient individual record with the processing platform; and receiving execution of the processing platform as indicated by the subsequent recipient individual record.

[0582] In aspect 127, the method of aspect 126, wherein the original content request comprises an original recipient public key and the original content, wherein the recorded content is related to the original content, wherein the subsequent content request comprises a subsequent recipient public key and the subsequent content, wherein the original content is related to the subsequent content.

[0583] In aspect 128, the method of any of aspects 126-127, wherein identifying the original content requester or identifying the subsequent content requester comprises performing partner identification, wherein the partner identification comprises content authorization, tapping, physical indication, beamforming, prior placement, coarse verification, or any combination thereof.

[0584] In aspect 129, the method of any of aspects 126-128, wherein the sender individual record further comprises a record identifier.

[0585] In aspect 130, the method of aspect 129, wherein the record identifier is a monotonically increasing number.

[0586] In aspect 131, a method according to any one of aspects 126-130, wherein sending the sender individual record to the original record recipient device includes sending the sender individual record to the original record recipient device directly or through an intermediate device via a first short-range link, and wherein sending the original recipient individual record to the subsequent record recipient device includes sending the original recipient individual record to the subsequent record recipient device directly or through an intermediate device via a second short-range link.

[0587] In aspect 132, the method of aspect 131, wherein the first short range link is a peer to peer communication link, or wherein the second short range link is a peer to peer communication link.

[0588] In aspect 133, the method of any of aspects 126-132, wherein the subsequent recipient individual record further comprises a redemption-only endorsement, a query endorsement, a malicious record endorsement, or any combination thereof.

[0589] In aspect 134, a method according to any one of aspects 126-133, wherein creating a sender individual record includes receiving, by a record sender device, authentication information of the record sender, wherein creating an original recipient individual record includes receiving, by an original record recipient device, authentication information of the original record recipient, and wherein creating a subsequent recipient individual record includes receiving, by a subsequent record recipient device, authentication information of the subsequent record recipient.

[0590] In aspect 135, a method according to any of aspects 126-134, wherein verifying the sender individual record includes using the sender public key to determine the use of the sender private key to create the sender signature, and wherein verifying the original recipient individual record includes using the original recipient public key to determine the use of the original recipient private key to create the original recipient signature.

[0591] In aspect 136, a method according to any one of aspects 126-135, wherein a sender signature is created by a secure element of a recording sender device using a sender private key, wherein the sender private key is stored in a secure element of the recording sender device, wherein an original recipient signature is created by a secure element of an original recording recipient device using the original recipient private key, wherein the original recipient private key is stored in a secure element of the original recording recipient device, wherein a subsequent recipient signature is created by a secure element of a subsequent recording recipient device using the subsequent recipient private key, and wherein the subsequent recipient private key is stored in a secure element of a subsequent recording recipient device.

[0592] In aspect 137, a method for securely exchanging a chain of cryptographically signed records is disclosed. The method is executed under control of a hardware processor and includes: sending a subsequent content request to an original record recipient device, receiving an original recipient individual record from the original record recipient device, wherein the original recipient individual record includes a sender individual record, a subsequent recipient public key of the subsequent record recipient device, and an original recipient signature of the original recipient individual record, wherein the sender individual record includes the record content, the sender public key of the record sender device, the original recipient public key of the original record recipient device, and the sender signature of the sender individual record, wherein the sender individual record is created by the record sender device after receiving the original content request from the original record recipient device and identifying the original record recipient device, wherein the sender signature is created using a sender private key of the record sender device, and wherein the sender public key and the sender private key form a sender public key encryption pair, wherein after receiving the subsequent content request from the original record recipient device, the sender signature is created using a sender private key of the record sender device, and wherein the sender public key and the sender private key form a sender public key encryption pair, wherein after receiving the subsequent content request from the original record recipient device, the sender signature is created using a sender private key of the record sender device, and wherein the sender public key and the sender private key form a sender public key encryption pair, wherein After the record recipient device receives a subsequent content request and identifies a subsequent record recipient device, the original record recipient device creates an original recipient individual record, wherein an original recipient signature is created using the original recipient private key of the original record recipient device, and wherein the original recipient public key and the original recipient private key form an original recipient public key encryption pair; verifies the original recipient individual record without necessarily communicating with the processing platform; creates a subsequent recipient individual record, wherein the subsequent recipient individual record includes the original recipient individual record and a subsequent recipient signature of the subsequent recipient individual record, wherein the subsequent recipient signature is created using the subsequent recipient private key of the subsequent record recipient device, and wherein the subsequent recipient public key and the subsequent recipient private key form a subsequent recipient public key encryption pair; exchanges the subsequent recipient individual record with the processing platform; and receives execution of the processing platform as indicated by the subsequent recipient individual record.

[0593] In aspect 138, the method of aspect 137, wherein the original content request comprises an original recipient public key and the original content, wherein the recorded content is related to the original content, wherein the subsequent content request comprises a subsequent recipient public key and the subsequent content, wherein the original content is related to the subsequent content.

[0594] In aspect 139, the method of any of aspects 137-138, wherein identifying the original content requester or identifying the subsequent content requester comprises performing partner identification, wherein the partner identification comprises content authorization, tapping, physical indication, beamforming, prior placement, coarse verification, or any combination thereof.

[0595] In aspect 140, the method according to any one of aspects 137-139, wherein the sender individual record further comprises a record identifier.

[0596] In aspect 141, the method of aspect 140, wherein the record identifier is a monotonically increasing number.

[0597] In aspect 142, the method of any of aspects 137-141, wherein receiving the original recipient individual record from the original record recipient device comprises receiving the original recipient individual record from the original record recipient device via a short-range link directly or through an intermediary device.

[0598] In aspect 143, the method of aspect 142, wherein the short range link is a peer to peer communication link.

[0599] In aspect 144, the method of any of aspects 137-143, wherein the subsequent recipient individual record further comprises a redemption-only endorsement, a query endorsement, a malicious record endorsement, or any combination thereof.

[0600] In aspect 145, a method according to any one of aspects 137-144, wherein the sender individual record is created by the record sender device after receiving authentication information of the record sender, wherein the original recipient individual record is created by the original record recipient device after receiving authentication information of the original record recipient device, and wherein creating the subsequent recipient individual record includes receiving authentication information of the subsequent record recipient by the subsequent record recipient device.

[0601] In aspect 146, the method of any of ...

Claims

1. A method for securely exchanging a chain of cryptographically signed records, the method being performed under the control of a hardware processor executing a computer program, the method comprising: receiving a subsequent recipient individual record from a subsequent record recipient device, The subsequent recipient individual record includes the original recipient individual record and the subsequent recipient signature of the subsequent recipient individual record. The original recipient individual record includes the sender individual record, the subsequent recipient public key of the subsequent record recipient device and the original recipient signature of the original recipient individual record. The sender individual record includes the record content, the sender public key of the record sender device, the original receiver public key of the original record receiver device, and the sender signature of the sender individual record. wherein the record content of the sender individual record of the original recipient individual record includes an instruction to the subsequent record recipient device to access a document having a specific identifier, wherein the sender individual record is created by the record sender device after receiving an original content request from the original record recipient device and identifying the original record recipient device, wherein the sender signature is created using the sender private key of the record sender device, The sender's public key and the sender's private key form a sender's public key encryption pair. wherein the original recipient individual record is created by the original record recipient device after receiving a subsequent content request from the subsequent record recipient device and identifying the subsequent record recipient device, wherein the original recipient signature is created using the original recipient private key of the original record recipient device, The original recipient's public key and the original recipient's private key form an original recipient's public key encryption pair. wherein the subsequent recipient signature is created using the subsequent recipient private key of the subsequent record recipient device, and wherein the subsequent recipient public key and the subsequent recipient private key form a subsequent recipient public key encryption pair; Verifying the subsequent recipient individual record; and Based on the instruction to give the subsequent record recipient device access to the document with the specific identifier included in the record content of the sender individual record of the original recipient individual record of the subsequent recipient individual record, the document with the specific identifier is provided to the subsequent record recipient device via a computer network.

2. The method according to claim 1, wherein The original content request includes the original recipient public key and original content, wherein the recorded content is related to the original content, wherein the subsequent content request includes the subsequent recipient public key and subsequent content, and wherein the original content is related to the subsequent content.

3. The method according to claim 1, wherein Identifying the original content requester or identifying the subsequent content requester includes performing partner identification, wherein partner identification includes content authorization, tapping, physical indication, beamforming, prior placement, coarse verification, or any combination thereof.

4. The method according to claim 1, wherein The sender individual record further includes a record identifier.

5. The method according to claim 4, wherein The record identifier is a monotonically increasing number.

6. The method according to claim 1, wherein The sender individual record is sent by the record sender device to the original record recipient device via a first short-range link directly or through an intermediate device, and wherein sending the original recipient individual record to the subsequent record recipient device includes sending the original recipient individual record to the subsequent record recipient device directly or through an intermediate device via a second short-range link.

7. The method according to claim 1, wherein The subsequent recipient individual record further includes a redemption-only approval, a query approval, a malicious record approval, or any combination thereof.

8. The method according to claim 1, wherein The sender individual record is created by the record sender device after receiving authentication information of the record sender, wherein the original recipient individual record is created by the original record recipient device after receiving authentication information of the original record recipient, and wherein the subsequent recipient individual record is created by the subsequent record recipient device after receiving authentication information of the subsequent record recipient device.

9. The method according to claim 1, wherein Verifying the subsequent recipient individual record includes: Using the sender public key to determine creating the sender signature using the sender private key; using the original recipient public key to determine creating the original recipient signature using the original recipient private key; and The subsequent recipient public key is used to determine creation of the subsequent recipient signature using the subsequent recipient private key.

10. The method according to claim 1, wherein The sender signature is created by the security element of the record sender device using the sender private key, wherein the sender private key is stored in the security element of the record sender device, wherein the original recipient signature is created by the security element of the original record recipient device using the original recipient private key, wherein the original recipient private key is stored in the security element of the original record recipient device, wherein the subsequent recipient signature is created by the security element of the subsequent record recipient device using the subsequent recipient private key, and wherein the subsequent recipient private key is stored in the security element of the subsequent record recipient device.

11. A method for securely exchanging a chain of cryptographically signed records, the method being performed under the control of a hardware processor executing a computer program, the method comprising: receiving an original content request from an original recording recipient device; Identifying the original record recipient device; Creating a sender individual record, wherein the sender individual record includes the record content, the sender public key of the record sender device, the original receiver public key of the original record receiver device, and the sender signature of the sender individual record, The record content recorded by the sender individual includes instructions to a subsequent record receiver device to access a document with a specific identifier, wherein the sender signature is created using a sender private key of the record sender device, and wherein the sender public key and the sender private key form a sender public key encryption pair; Sending the sender individual record to the original content requester; Receive an instruction from the original content requester: receiving the sender individual record; Verify the sender individual record using the sender public key; receiving a subsequent content request from the subsequent record recipient device; identifying a subsequent record recipient device; creating an original recipient individual record, wherein the original recipient individual record includes the sender individual record, a subsequent recipient public key of the subsequent record recipient device, and an original recipient signature of the original recipient individual record, wherein the original recipient signature is created using an original recipient private key of the original record recipient device, and wherein the original recipient public key and the original recipient private key form an original recipient public key encryption pair; sending the original recipient individual record to the subsequent record recipient device; receiving an instruction from a recipient of the subsequent record; receiving the original recipient individual record; Verify the original recipient individual record using the sender public key and the original recipient public key; creating a subsequent recipient individual record, wherein the subsequent recipient individual record includes the original recipient individual record and a subsequent recipient signature of the subsequent recipient individual record, wherein the subsequent recipient signature is created using a subsequent recipient private key of the subsequent record recipient device, and wherein the subsequent recipient public key and the subsequent recipient private key form a subsequent recipient public key encryption pair; exchanging the original recipient individual record with the processing platform; and Execution of the processing platform is received via a computer network as indicated by the instructions included in the record content of the sender individual record of the original recipient individual record of the subsequent recipient individual record to give the subsequent record recipient device access to the document with the specific identifier.

12. The method according to claim 11, wherein The original content request includes the original recipient public key and original content, wherein the recorded content is related to the original content, wherein the subsequent content request includes the subsequent recipient public key and subsequent content, wherein the original content is related to the subsequent content.

13. The method according to claim 11, wherein The sender individual record further includes a record identifier.

14. The method according to claim 11, wherein Sending the sender individual record to the original record recipient device includes sending the sender individual record to the original record recipient device directly or through an intermediate device via a first short-range link, and wherein, sending the original recipient individual record to the subsequent record recipient device includes sending the original recipient individual record to the subsequent record recipient device directly or through an intermediate device via a second short-range link.

15. The method according to claim 11, wherein Creating the sender individual record includes receiving the authentication information of the record sender by the record sender device, wherein creating the original recipient individual record includes receiving the authentication information of the original record recipient by the original record recipient device, and wherein creating the subsequent recipient individual record includes receiving the authentication information of the subsequent record recipient by the subsequent record recipient device.

16. The method according to claim 11, wherein Verifying the sender individual record includes using the sender public key to determine that the sender signature was created using the sender private key, and wherein verifying the original recipient individual record includes using the original recipient public key to determine that the original recipient signature was created using the original recipient private key.

17. The method according to claim 11, wherein The sender signature is created by the security element of the record sender device using the sender private key, wherein the sender private key is stored in the security element of the record sender device, wherein the original recipient signature is created by the security element of the original record recipient device using the original recipient private key, wherein the original recipient private key is stored in the security element of the original record recipient device, wherein the subsequent recipient signature is created by the security element of the subsequent record recipient device using the subsequent recipient private key, and wherein the subsequent recipient private key is stored in the security element of the subsequent record recipient device.

18. A method for securely exchanging a chain of cryptographically signed records, the method being performed under the control of a hardware processor executing a computer program, the method comprising: Sending an original content request to a record sender device; receiving a sender individual record from the record sender device, wherein the sender individual record includes record content, a sender public key of the record sender device, an original receiver public key of the original record receiver device, and a sender signature of the sender individual record, wherein the record content of the sender individual record includes instructions to a subsequent record recipient device to access a document with a specific identifier, instructions to transfer cryptocurrency between accounts, or instructions to execute a computer program, wherein the sender signature is created using a sender private key of the record sender device, and wherein the sender public key and the sender private key form a sender public key encryption pair; Verify the sender individual record using the sender public key; receiving a subsequent content request from the subsequent record recipient device; identifying a subsequent record recipient device; creating an original recipient individual record, wherein the original recipient individual record includes the sender individual record, a subsequent recipient public key of the subsequent record recipient device, and an original recipient signature of the original recipient individual record, wherein the original recipient signature is created using an original recipient private key of the original record recipient device, and wherein the original recipient public key and the original recipient private key form an original recipient public key encryption pair; sending the original recipient individual record to the subsequent record recipient device; Receiving an indication of the subsequent record recipient: receiving the original recipient individual record; Verify the original recipient individual record using the sender public key and the original recipient public key; creating a subsequent recipient individual record, wherein the subsequent recipient individual record includes the original recipient individual record and a subsequent recipient signature of the subsequent recipient individual record, wherein the subsequent recipient signature is created using a subsequent recipient private key of the subsequent record recipient device, and wherein the subsequent recipient public key and the subsequent recipient private key form a subsequent recipient public key encryption pair; exchanging the original recipient individual record via a computer network and processing platform; and Execution of the processing platform is received as directed by the instruction included in the record content of the sender individual record of the original recipient individual record of the subsequent recipient individual record to grant access to the document having the specific identifier to the subsequent record recipient device.

19. The method according to claim 18, wherein The original content request includes the original recipient public key and original content, wherein the recorded content is related to the original content, wherein the subsequent content request includes the subsequent recipient public key and subsequent content, wherein the original content is related to the subsequent content.

20. The method according to claim 18, wherein Sending the sender individual record to the original record recipient device includes sending the sender individual record to the original record recipient device directly or through an intermediate device via a first short-range link, and wherein, sending the original recipient individual record to the subsequent record recipient device includes sending the original recipient individual record to the subsequent record recipient device directly or through an intermediate device via a second short-range link.

Images