Secure offline transactions using trusted payer

Abstract

A method for making an offline transaction between a payee and a payer, performed by a payee device in communication with a payer device, is provided. The method includes sending, by the payee device, towards the payer device, a first message including signed payee offline information. The method includes receiving, by the payee device, from the payer device, signed payer offline information that is signed with a transaction broker node private key. The method includes receiving, by the payee device, from the payer device, a signed offline transaction that is signed with the payer private key. The method includes verifying, by the payee device, the signed payer offline information. The method includes verifying, by the payee device, the signed offline transaction. The method includes, as a result of verifying, by the payee device, the signed payer offline information and the signed offline transaction, accepting the signed offline transaction.

Description

SECURE OFFLINE TRANSACTIONS USING TRUSTED PAYERTECHNICAL FIELD

[0001] Disclosed are embodiments related to secure offline transactions using a trusted payer.BACKGROUND

[0002] Most payment systems today rely on that at least the Payee (the receiver of funds in a financial transaction) is online (i.e., connected to their financial institution in some way) to verify that a financial transaction from the Payer (the sender of funds in a transaction) to the Payee can be performed. Many proposals have been made as to how to be able to support offline transactions, where both the Payer and the Payee are offline without any network connectivity to the financial institution. The reasons for that both Payer and Payee are offline could include, for example:• Connectivity is not available due to the geographical location; for example, due to a remote location without mobile network communication, or on an airplane.• Some temporary disturbance; for example, electricity issues or a natural disaster causing disturbances in network communications, or problems in normal financial networks.

[0003] Cryptography is used in most existing proposed solutions together with a secure element on the Payer and Payee devices to support offline transactions. To perform the offline transaction, some proximity peer-to-peer technology is typically used, such as transferring information via QR code, NFC, Bluetooth, Wi-Fi, IR, or sound, directly between the Payer and the Payee.

[0004] One example article which contains a solution for offline transactions is “Towards a Two-Tier Hierarchical Infrastructure: An Offline Payment System for Central Bank Digital Currencies” (https: / / arxiv.org / pdf / 2012.08003.pdf).

[0005] There is also some existing technology that can be used for verifying credentials (also known as VC) without contacting the issuer of the credential (see for example https: / / www.w3.org / TR / vc-data-model / ). Some use cases are mentioned by W3C in the context of finance: https: / / www.w3.Org / TR / vc-use-cases / #finance. There are also some offline use casesfor verifiable credentials discussed in https: / / github.com / WebOfTrustInfo / rwot7- toronto / blob / master / draft- documents / Use%20Cases%20and%20Proposed%20Solutions%20for%20Verifiable%200ffline %20Credentials.md.SUMMARY

[0006] One problem with allowing offline transactions is how to reduce fraudulent spending, either by a fraudster impersonating a Payer or by the Payer themselves trying to fraud the system, so that more funds can be used than should be available. Offline transactions are possible to perform with existing technology, but since the transaction details can’t be verified against a system holding the actual balance in real time during the actual transaction, there is always a risk involved that the Payer is trying to fraud the Payee and / or the system, so that the transaction will not be successful when it is later settled online.

[0007] The existing solutions often rely on a secure element on the Payer’s device being 100% secure and that the secure device can’t be tampered with. The economic incentive for a fraudster to try to tamper with a device is very strong, as a successful fraudster could effectively be able to print their own digital funds. Who is responsible for the financial risk in case a fraudster would be successful in tampering with a device is most often not discussed in different solutions or assumed to be the operator of the service.

[0008] Some existing proposed solutions to verify that the Payer is who they say they are require very advanced technologies like face-recognition of the Payer. In some markets or other use cases, such technology may not be available.

[0009] There is a report named A handbook for offline payments with CBDC (see https: / / www.bis.org / publ / othp64.pdf) from BIS (Bank for International Settlement) that discusses design of offline transaction systems in general and gives a very good introduction to the subject of offline transactions. Section 5 in the report covers identified risks with offline transaction systems. The report does not offer any real technical solutions how to mitigate risks with offline transaction systems, just some high-level suggestions.

[0010] Verifiable credentials, mentioned in the previous section, can’t be used by itself to solve offline transactions, the technology can only be used for parts of a solution. Additionally,neither the finance use cases, nor offline use cases, mentions offline transactions as a possible use case, and as such does not provide any kind of solution for how to use verifiable credentials for offline transactions.

[0011] It is very hard to implement a secure offline system. One way to lower the total risk in an offline transaction system is for the Payee to take the full or at least part of the financial risk of an offline transaction, instead of the provider of the offline transaction system taking the full financial risk for each financial transaction. By having the financial risk for an offline transaction on the Payee, the Payee is incentivized to perform additional verifications of the Payer’s ability to pay, as the Payee might otherwise lose funds.

[0012] Embodiments enable a Payee, as part of an offline transaction, to get trusted information about the Payer, that allows the Payee application / system or Payee themselves to verify the Payer. Embodiments provide a number of advantages, some of which follow.

[0013] To allow a Payee application / system and / or Payee to make additional verifications regarding the Payer, information about the Payer that can be trusted is needed. The information to allow the Payee to perform the verifications may be signed by a financial broker node (e.g., a financial institution) or another trusted central authority, so that the Payee can verify that the information about the Payer is valid. By including information about the Payer that the Payee can easily verify automatically, semi-automatically or manually (or a combination of these), embodiments can also be used in less technology-advanced setups, compared to if for example only biometric data such as fingerprint or some automatic face-recognition technology was used.

[0014] By having information about a Payer that can easily be verified by the Payee in less technology-advanced setups, in combination with the Payee taking the financial risk of the transaction and that the information about the Payer is signed by a transaction broker node (e.g., a financial institution), the security requirements on the Payer’s device can be lower than in other potential solutions. This is because the Payee is incentivized to perform additional verification in a trusted manner, instead of relying on the offline transaction system itself being totally secure. For example, it should be possible to use a TEE (Trusted Execution Environment) or a virtual SE (Secure Element) instead of a hardware -based SE on a mobile device to secure theinformation. A TEE is present in virtually all smart phones, compared to a SE which is only available in a fraction of Android devices. A TEE is generally not considered as secure as a SE.

[0015] Embodiments also allow the Payer to verify that the Payee is who they say they are, by including trusted information about the Payee. Embodiments also provide additional security protections. If a fraudster manages to get hold of the Payer’s private key to sign offline transactions, they would also need to get hold of the signed information about the Payer and then manage to convince the Payee that they are the actual Payer. By having, for example, the passport number as part of the signed information, the Payer would need to copy the passport and change it in a way so that the Payee can believe that the passport is valid and that the fraudster is really the Payer. Additionally, if a passcode has been added, the fraudster would also need to find out the passcode somehow. There are also other signed information elements added that can aid the Payee in verifying the Payer. If it is a Payer themselves that tries to fraud a Payee, they will need to be able to access and change the current offline balance that is securely stored on their device. Using for example an optional credit score as part of the signed information can aid the Payee in knowing which Payers that can be trusted. Additionally, the financial institution can identify the Payer as part of the online settlement process in case the Payer would manage to fraud a Payee.

[0016] According to a first aspect, a method for making an offline transaction between a payee and a payer, performed by a payee device in communication with a payer device is provided. The method includes sending, by the payee device, towards the payer device, a first message including signed payee offline information. The method includes receiving, by the payee device, from the payer device, signed payer offline information that is signed with a transaction broker node private key. The method includes receiving, by the payee device, from the payer device, a signed offline transaction that is signed with a payer private key. The method includes verifying, by the payee device, the signed payer offline information. The method includes verifying, by the payee device, the signed offline transaction. The method includes, as a result of verifying, by the payee device, the signed payer offline information and the signed offline transaction, accepting the signed offline transaction.

[0017] According to a second aspect, a method for making an offline transaction between a payee and a payer, performed by a payer device in communication with a payee device, isprovided. The method includes receiving, by the payer device, from the payee device, a first message including signed payee offline information that is signed with a transaction broker node private key. The method includes verifying, by the payer device, the signed payee offline information. The method includes sending, by the payer device, towards the payee device, signed payer offline information. The method includes creating a signed offline transaction. The method includes sending, by the payer device, towards the payee device, the signed offline transaction.

[0018] According to a third aspect, a payee device is provided. The device includes processing circuitry; and a memory. The memory contains instructions executable by the processing circuitry, whereby when executed the processing circuitry is configured to send, by the payee device, towards the payer device, a first message including signed payee offline information. The processing circuitry is configured to receive, by the payee device, from the payer device, signed payer offline information that is signed with a transaction broker node private key. The processing circuitry is configured to receive, by the payee device, from the payer device, a signed offline transaction that is signed with a payer private key. The processing circuitry is configured to verify, by the payee device, the signed payer offline information. The processing circuitry is configured to verify, by the payee device, the signed offline transaction. The processing circuitry is configured to, as a result of verifying, by the payee device, the signed payer offline information and the signed offline transaction, accept the signed offline transaction.

[0019] According to a fourth aspect, a payer device is provided. The device includes processing circuitry; and a memory. The memory contains instructions executable by the processing circuitry, whereby when executed the processing circuitry is configured to receive, by the payer device, from the payee device, a first message including signed payee offline information that is signed with a transaction broker node private key. The processing circuitry is configured to verify, by the payer device, the signed payee offline information. The processing circuitry is configured to send, by the payer device, towards the payee device, signed payer offline information. The processing circuitry is configured to create a signed offline transaction. The processing circuitry is configured to send, by the payer device, towards the payee device, the signed offline transaction.

[0020] According to a fifth aspect, a computer program is provided, comprising instructions which when executed by the processing circuitry of a node cause the node to perform the method of any of the embodiments of the first or second aspects.

[0021] According to a sixth aspect, a carrier is provided, containing the computer program of the fifth aspect. The carrier is one of an electronic signal, an optical signal, a radio signal, and a computer readable storage medium.BRIEF DESCRIPTION OF THE DRAWINGS

[0022] The accompanying drawings, which are incorporated herein and form part of the specification, illustrate various embodiments.

[0023] FIG. 1 illustrates a system according to an embodiment.

[0024] FIG. 2 illustrates a system according to an embodiment.

[0025] FIG. 3 illustrates a sequence diagram according to an embodiment.

[0026] FIG. 4 illustrates a sequence diagram according to some embodiments.

[0027] FIG. 5 illustrates a sequence diagram according to some embodiments.

[0028] FIG. 6 illustrates a sequence diagram according to some embodiments.

[0029] FIG. 7 illustrates a sequence diagram according to some embodiments.

[0030] FIG. 8 illustrates a sequence diagram according to some embodiments.

[0031] FIG. 9 illustrates a sequence diagram according to some embodiments.

[0032] FIG. 10 illustrates a flowchart according to an embodiment.

[0033] FIG. 11 illustrates a flowchart according to an embodiment.

[0034] FIG. 12 is a block diagram of an apparatus according to an embodiment.DETAILED DESCRIPTION

[0035] FIG. 1 illustrates a system according to an embodiment. In particular, FIG. 1 shows a system overview of an embodiment for offline transactions within a single transaction broker node 102 (e.g., a financial institution), where both Payer and Payee are in the same transaction broker node 102 (e.g., financial institution). In general, the terms transaction brokernode and financial institution are used interchangeably throughout this disclosure. The transaction broker node 102 holds a number of account holders in the system, including information about them in the account holder data 110 data structure. For each account holder, the transaction broker node 102 holds account holder data information (also known as Know Your Customer data, or KYC), such as passport number, as well as an online balance for the account holder. For those account holders who sign up as Payer or Payee in offline transactions, data related to these respective functionalities can be added to the offline information that can be used by the other party as part of an offline transaction to verify that the account holder is who they say they are. As shown, account holder data 110 includes offline payer data 112 and offline payee data 114. Account holder data 110 may also include data about other account holders, and a given account holder may be represented in the transaction broker node 102 as either a payee, a payer, or both a payee and a payer.

[0036] The transaction broker node 102 may include an application 116 and a secure environment 118. The transaction broker node 102 holds a public-private key pair, e.g., a Transaction Broker Node Private Key (which may be part of the secure environment 118), which may also be referred to as a Financial Institution Private Key, and a Transaction Broker Node Public Key (which may be part of the application 116), which may also be referred to as a Financial Institution Public Key, and which may be used to sign and verify signatures for Payer Offline Information and Payee Offline Information. These information elements contain trusted information about a Payer or a Payee respectively. The Payer Offline Information may contain information elements to help a Payee to decide if a Payer can be trusted enough to perform an offline transaction. Likewise, the Payee Offline Information may contain information for a Payer to decide if a Payee can be trusted.

[0037] The system may also include a payer device 104 and a payee device 106, both of which are communicatively coupled to each other and to the transaction broker node 102 via a network 140. The device for a Payer and Payee should contain some kind of secure environment (e.g., secure environment 122 of the payer device 104 or secure environment 132 of the payee device 106) that protects information that should be securely stored, as well as protecting against tampering and code injection attacks, for example a Secure Element, a TEE, or a virtual secure element. Which type of device it is, for example a mobile phone, a POS (Point Of Sale) device,a payment terminal, a wearable, a tablet, a smart card, a computer, is not important, as long as the device has some secure environment and can communicate via some technology to another device. The Payer Private Key and Payee Private Key needs to be stored securely on the respective devices, along with at least the Payer Offline Balance. Other information may also be stored on an application of these devices (e.g., application 120 of the payer device 104 or application 130 of the payee device 106).

[0038] The system overview shown in FIG. 1 only shows one public and private key pair for each of the transaction broker node 102 (e.g., a financial institution), Payer, and Payee for simplicity. There could be more key pairs per party, for example to avoid using the same key pair for signing and encryption. The key pairs should also be rotated on regular intervals using best practices within the security industry.

[0039] The communication between the Payer or the Payee and the financial institution is via network 140, e.g., the Internet or some other network that allows a device to communicate with the transaction broker node 102, such as USSD over a mobile network. The Payer and Payee may communicate with the transaction broker node 102 to sign up for the service, update signed information, and / or perform online settlement.

[0040] The communication between the Payer and the Payee to perform an offline transaction should typically use some kind of a proximity-based peer-to-peer technology 142, such as transferring information via QR code, NFC, Bluetooth, Wi-Fi, IR, or sound, directly between the Payer and the Payee. There is nothing in proposed embodiments that prevents the information to be shared via some other network that is not proximity-based or directly peer-to- peer between the Payer and Payee, for example via a network on an airplane, but the Payer and Payee should ideally be in the same location to be able to perform the additional verifications as proposed in some embodiments. Embodiments could also be used for performance reasons, avoiding the extra network communication during the actual financial transaction and settling the transaction later.

[0041] The processes for signing up as Payer and Payee and the information stored for the two are similar, though typically a Payer should require more information compared to a Payee, as it is the Payee that potentially takes a financial risk and should therefore verify thePayer as part of the offline transaction. These processes are further described below, with respect to FIGS. 4-5. A transaction broker node 102 could also decide to allow an account holder to sign up as both Payer and Payee in the same process. There is no requirement in some embodiments that the Payer and Payee keys are different; an account holder, for example, could use the same keys both for being a Payer and Payee. On the other hand, in some embodiments, an account holder may use different keys for being a Payer and Payee.

[0042] FIG. 2 illustrates a system according to an embodiment. In particular, FIG. 2 shows an alternate system overview where a centrally trusted authority system (a central transaction broker node) is used to allow account holders from different financial institutions to perform offline transactions between them (also known as interoperability or interoperable offline transactions). For example, one or more financial institutions 202, each with account holder data 110, may be in communication, e.g., via network 140, with a central transaction broker node 102. This central transaction broker node 102 may collect information about different payers and payees, and it may provide a central contact for payers and payees to sign up for and / or settle offline transactions. For ease of illustration, the processes shown in this disclosure depict a single transaction broker node 102, but there is nothing technically preventing a similar process to be used for interoperable offline transactions where the Payer and Payee belongs to different transaction broker nodes 102 (e.g., different financial institutions 202), and embodiments encompass such interoperable offline transactions. For example, the online settlement (e.g., as described with respect to FIG. 9) could include a settlement between the Payer’s financial institution and the Payee’s financial institution to facilitate the interoperable transaction. A single, centralized transaction broker node 102 may coordinate such interoperability, or different transaction broker nodes 102 or financial institutions 202 may themselves cooperate to provide the interoperability.

[0043] FIG. 3 illustrates a sequence diagram for an offline transaction according to an embodiment. The overall process is simplified, but shows the basic elements of the offline transaction. The order of different steps may be different from what is shown, there may be more or fewer messages than what is shown, and different information than what is indicated and / or additional information may be sent, in some embodiments.

[0044] Account holders at a financial institution or some other trusted central authority can sign up as Payer and / or Payee for offline transactions. Using a trusted central authority could be used to support interoperable transactions where the Payer and Payee are account holders in different banks. The financial institution or trusted central authority has information about the account holder and signs the information so that it can be verified and trusted by the counterparty in an offline transaction.

[0045] Embodiments enable the Payee in an offline transaction to make an informed decision regarding the financial risk for the transaction from a Payer by including verified information regarding the Payer, instead of having to trust that the offline transaction system is 100% secure. The Payee can request which information is required about the Payer to minimize sharing of privacy sensitive information. The information about the Payer can then be verified in several ways, e.g.,• Automatically; e.g., a Payee application / system verifies physical location against approved Payer locations, a Payee application / system verifies Payer’s credit score against pre-defined allowed credit score, a Payee application / system verifies expiry time of signed information, and so on.• Semi-automatically; e.g., a Payer enters a PIN code that is automatically verified by the Payee or Payer application / system, or Payee enters other information about the Payer that is automatically verified by the Payee application / system.• Manually; e.g., a Payee verifies that the Payer’s passport matches the passport number from the signed Payer information.Additionally, any combination of the above could be used in embodiments.

[0046] la. Payee device 106 generates a public -private key pair. This key pair is used for offline transactions.

[0047] 2a. Payee device 106 communicates with transaction broker node 102 to sign up for offline transactions as a payee. In doing so, payee device 106 includes the public key it will use for offline transactions.

[0048] 3a. Transaction broker node 102 creates signed payee offline information. This information is based on information the transaction broker node 102 has about the payee, or is based on information the transaction broker node 102 may receive about the payee from another transaction broker node 102 (e.g., another financial institution), or some combination of this information. In embodiments, multiple signed payee offline information may be generated, each having different information in it, in order to allow the payee to better control the privacy of the payee’s private information. The transaction broker node 102 may collect information about the payee that can be used by a payer to validate the payee, and may use its private key to sign the payee offline information.

[0049] 4a. Transaction broker node 102 sends the signed payee offline information to the payee device 106, along with the public key corresponding to the private key that the transaction broker node 102 used to sign the signed payee offline information.

[0050] lb. Payer device 104 generates a public -private key pair. This key pair is used for offline transactions.

[0051] 2b. Payer device 104 communicates with transaction broker node 102 to sign up for offline transactions as a payer. In doing so, payer device 104 includes the public key it will use for offline transactions.

[0052] 3b. Transaction broker node 102 creates signed payer offline information. This information is based on information the transaction broker node 102 has about the payer, or is based on information the transaction broker node 102 may receive about the payer from another transaction broker node 102 (e.g., another financial institution), or some combination of this information. In embodiments, multiple signed payer offline information may be generated, each having different information in it, in order to allow the payer to better control the privacy of the payer’s private information. The transaction broker node 102 may collect information about the payer that can be used by a payee to validate the payer, and may use its private key to sign the payer offline information.

[0053] 4b. Transaction broker node 102 sends the signed payer offline information to the payer device 104, along with the public key corresponding to the private key that the transaction broker node 102 used to sign the signed payer offline information.

[0054] Note: The order of steps la-4a and steps lb-4b is not critical. For example, the payee may sign up before the payer, or the payer may sign up before the payee, or both may sign up concurrently.

[0055] 5. The payee may indicate that the payee would like to be paid by the payer and initiate the offline transaction. In some embodiments, it may be the payer that initiates the offline transaction.

[0056] 6. The payee device 106 may send towards the payer device 104 signed payee offline information and a transaction amount.

[0057] 7. The payer device 104 may verify the signed payee offline information.

[0058] 8. The payer device 104 may create the signed offline transaction.

[0059] 9. The payer device 104 may send to the payee device 106 the signed payer offline information and the signed offline transaction. As this is an offline transaction, the payer device 104 may perform this step without communicating with the transaction broker node 102.

[0060] 10. The payee device 106 may verify the signed payer offline information.

[0061] 11. The payee device 106 may verify the signed offline transaction. Following an approved verification, the payee device 106 may accept the signed offline transaction, and store the signed offline transaction for subsequent settlement.

[0062] 12. When a connection to the transaction broker node 102 is available, the payee device 106 may send its payee unsettled offline transactions to the transaction broker node 102.

[0063] 13. When a connection to the transaction broker node 102 is available, the payer device 104 may send its payer unsettled offline transactions to the transaction broker node 102.

[0064] 14. The transaction broker node 102 may settle the offline transactions that it receives.

[0065] Embodiments enable a Payee as part of an offline transaction to get trusted information about the Payer, that allows the Payee application / system or Payee themselves to verify the Payer either automatically, semi-automatically, manually, or any combination of these. The information about the Payer is signed by the financial institution or another centrally trustedauthority that holds information about the Payer, to ascertain that the information can be trusted by the Payee. The financial institution can decide the minimum information that should be provided by a Payer to be allowed to sign up for the ability to perform offline transactions. Similarly, it is then up to the Payee to decide if they think that the provided information about the Payer is enough to accept an offline transaction. Embodiments allow the Payee application / system to optionally request only the information that is required, thus minimizing the amount of privacy sensitive data to be sent.

[0066] To prevent eavesdropping of sensitive personal data, any personal information about the Payer can be encrypted as part of some embodiments, so that only the intended Payee can read it. The Payee can also state which information that they need to verify the Payer, so that only the required information needs to be sent by the Payer which minimizes the amount of privacy sensitive data that is shared.

[0067] Signing up as Payee for Offline Transactions

[0068] FIG. 4 illustrates a sequence diagram for registering for offline transactions as a payee according to an embodiment. In particular, FIG. 4 shows the process for signing up as a Payee for offline transactions. As part of the process, the Payee gets the Transaction Broker Node Public Key, which is later used to verify the signature for the Signed Payer Offline Information when a Payer would like to make an offline transaction. The order of the beginning of the process is not important; the Payee Public Key could also be sent as part of the request to sign up as Payee (instead of in separate messages), but the Payee Public Key needs to be part of the Signed Payee Offline Information so that the Payer can get hold of the signed Payee Public Key.

[0069] 1. Payee 106a indicates to the payee device 106, e.g., using an application, that payee 106a would like to sign up as a payee for offline transactions.

[0070] 2. Payee device 106, e.g., via an application, sends a message to transaction broker node 102 requesting to sign up as a payee for offline transactions.

[0071] 3. Transaction broker node 102 verifies the account holder (i.e., payee 106a).Payee 106a may be an account holder with transaction broker node 102 itself, or may be anaccount holder of some other financial institution, in which case transaction broker node 102 may need to communicate with the other financial institution to verify the account holder.

[0072] 4. Transaction broker node 102 sends a request to the payee device 106 for the payee device 106 to send its payee public key.

[0073] 5. Payee device 106 securely generates an asymmetric key pair, and stores the resulting public and private keys.

[0074] 6. Payee device 106 sends to transaction broker node 102 the payee public key.

[0075] 7. Transaction broker node 102 collects information about the payee 106a, including the payee public key, and signs the information to generate the signed payee offline information. Transaction broker node 102 uses its private key to sign the payee offline information.

[0076] 8. Transaction broker node 102 sends to the payee device 106 the public key corresponding to the private key used to sign the payee offline information, as well as sending the signed payee offline information.

[0077] 9. Payee device 106 stores the public key of the transaction broker node 102 and the signed payee offline information.

[0078] 10. Payee device 106 indicates to payee 106a a successful sign up as payee for offline transactions.

[0079] 11. Optionally, payee 106a may set an offline balance limit and offline transaction limit on payee device 106.

[0080] 12. Payee device 106 may store, e.g., in the application, the offline balance limit and the offline transaction limit.

[0081] 13. Payee device 106 may show payee 106a the offline balance limit and the offline transaction limit.

[0082] The use of a Signed Payee Offline Information is not required by embodiments, but its use can improve both security and privacy. For example, the Payer can verify that the Payee is who they say they are. Also, the Payer can encrypt sensitive information to the Payeeusing a Payee Public Key so that no one other than the Payee can decrypt it. In some embodiments, the Signed Payee Offline Information may not be used.

[0083] When the Signed Payee Offline Information is used, it must contain the Payee Public Key. In addition, it may contain additional information, such as the expiry time of the information; and a Payee identifier, for example, a name. The identifier can be used by a Payer to verify that they are paying to the correct Payee. The Signed Payee Offline Information could also contain other information about the Payee, to help a Payer to verify that the Payee is who they say they are. Examples could be a photo of the Payee, or some physical attributes of the Payee that could be verified manually by the Payer, such as height, age, hair color, eye color, gender, and so on.

[0084] Signing up as Payer for Offline Transactions

[0085] FIG. 5 illustrates a sequence diagram for registering for offline transactions as a payer according to an embodiment. In particular, FIG. 5 shows the process for signing up as a Payer for offline transactions. As part of the process, the Payer generates an asymmetric keypair, where the Payer Private Key will be used to sign each Offline Transaction. The Payer Public Key is sent to the transaction broker node 102 so that the transaction broker node 102 can include it in the Signed Payer Offline Information to allow a Payee to verify signatures from the Payer. The order of the beginning of the process is not important; the Payer Public Key could also be sent as part of the request to sign up as Payer (instead of in separate messages), but the Payer Public Key needs to be part of the Signed Payer Offline Information so that the Payee can get hold of the signed Payer Public Key.

[0086] The Signed Payer Offline Information must contain the Payer Public Key. The Signed Payer Offline Information may also contain information to aid the Payee in the verification of the Payer. The following are non-exhaustive examples of information that can be included:• Expiry time of the information.• Eevel of KYC information that the Payer has provided and verified by the financial institution. For example, a higher KYC level may suggest that the Payer can be more trusted.Credit score as calculated by the financial institution, or by some external service. For example, a more credit-worthy Payer may be more trusted.• Reserved amount for offline transactions. For example, a higher reserved amount could indicate that the Payer has enough funds to cover the offline transaction.• Photo of the Payer. For example, a photo can be used for quick manual or automatic verification that the Payer is who they say they are.• Identification type and number, for example, a passport number that can be verified by the Payee. The identification type and number can be used to verify that the Payer is who they say they are.• Physical attributes of the Payer that could be verified manually by the Payee, such as height, age, hair color, eye color, gender, and so on.• Name of the Payer.• Biometric data that can be used in automatic recognition by the Payee, such as fingerprint data or data that can be used in face or voice recognition.• Allowed, disallowed, preferred and / or non-pref erred payment locations. For example, for preferred locations, a less stringent verification of the Payer could be performed; while, for non-preferred locations, a more stringent verification should be performed.• Allowed and disallowed currencies.• Pass- or PIN-code that the Payer needs to provide. Setting a pass- or pin-code serves multiple purposes; for example, it allows the Payee to verify that the Payer is actually the Payer, and it prevents fraudsters from either stealing the Payer’s device or extracting the Payer’s private key and using it to sign offline transactions.• An identifier of the Payer’s device. For example, the device identifier can be used to prevent a Payer’s private key to be used in other devices than the originally used device.• Allowed per transaction amount. Additionally, there could be multiple levels of amount, where each level suggests additional verifications to be performed, as well as a recommended maximum amount.Generic security questions that are not generally known, such as mother’s maiden name, favorite book, or name of first pet.

[0087] The financial institution can decide the minimum information detail that should be provided by a Payer to be allowed to sign up for the ability to perform offline transactions. Similarly, it is then up to the Payee to decide if they think that the provided information about the Payer is enough to be able to accept an offline transaction. The Payee can also, as part of the transaction, state which information that they would like to have for the Payee to be able to accept the transaction.

[0088] To protect the privacy of the Payer, the financial institution can sign the different information in the Signed Payer Offline Information individually or in different groups of information. This allows the Payer to only send information that is actually required by the Payee in their verification of the Payer. Examples of groups might be to use one group of information for lower-value transactions, and another group for higher-value transactions that contains additional information (or for which both groups of information need to be sent). As an example, an identification type and number might only be required for higher-value transactions, while a pass- or PIN-code might be included in a base level required for offline transactions to protect both the Payer and Payee. For simplicity in the flow diagrams, the Signed Payer Offline Information is shown as being sent in one single element.

[0089] 1. Payer 104a indicates to the payer device 104, e.g., using an application, that payer 104a would like to sign up as a payer for offline transactions.

[0090] 2. Payer device 104, e.g., via an application, sends a message to transaction broker node 102 requesting to sign up as a payer for offline transactions.

[0091] 3. Transaction broker node 102 verifies the account holder (i.e., payer 104a).Payer 104a may be an account holder with transaction broker node 102 itself, or may be an account holder of some other financial institution, in which case transaction broker node 102 may need to communicate with the other financial institution to verify the account holder.

[0092] 4. Transaction broker node 102 sends a request to the payer device 104 for the payer device 104 to send its payer public key.

[0093] 5. Payer device 104 securely generates an asymmetric key pair, and stores the resulting public and private keys.

[0094] 6. Payer device 104 sends to transaction broker node 102 the payer public key.

[0095] 7. Transaction broker node 102 stores the payer public key.

[0096] 8. Transaction broker node 102 collects information about the payer 104a, including the payer public key, and signs the information to generate the signed payer offline information. Transaction broker node 102 uses its private key to sign the payer offline information. The information about the Payer could already be stored as part of KYC information for the account holder, or the information could be collected as part of the sign-up process, or information could be added later. If the information is added later, a new Signed Payer Offline Information should be created with the updated information.

[0097] 9. Optionally, transaction broker node 102 reserves funds for the payer 104a for offline transactions.

[0098] 10. Transaction broker node 102 sends to the payer device 104 the public key corresponding to the private key used to sign the payer offline information, as well as sending the signed payer offline information and any optionally reserved funds for offline transactions.

[0099] 11. Payer device 104 stores the public key of the transaction broker node 102 and the signed payer offline information. Payer device 104 may also set the payer offline balance, which may be based on the optionally reserved funds for offline transactions. The reserved funds should be used as Payer Offline Balance, but an implementation may also choose to use another value as the initial Payer Offline Balance.

[0100] 12. Payer device 104 indicates to payer 104a a successful sign up as payer for offline transactions.

[0101] Updating Signed Information

[0102] While an expiry date is optional for any of the signed information disclosed herein, the Signed Payer Offline Information should contain an expiry date, and the Signed Payee Offline Information might contain an expiry date. Accordingly, an account holder should be able to regularly update their respective signed information to make sure that the validityperiod is extended in case the account holder is offline for an extended period of time (actual time depending on expiry time).

[0103] As an example, a Signed Payer Offline Information might be valid for two weeks. To ensure that the Payer always have two weeks of potentially being offline, the Signed Payer Offline Information may be updated daily.

[0104] FIG. 6 illustrates a sequence diagram for updating signed information for an offline transaction according to an embodiment. In particular, FIG. 6 shows the process for updating the signed information, either as a Payer or Payee. As noted previously, the respective party’s (i.e., Payer, Payee, financial institution) key pair(s) should also be regularly updated to follow industry standards on key rotation. A similar flow as shown for updating signed information could be used for key rotation as well.

[0105] 1. On regular intervals, for example daily, the account holder’s application requests to get a new Signed Payer Offline Information or Signed Payee Offline Information (depending on role). The request could also be initiated by the account holder themselves, or the updated information could be pushed from the transaction broker node 102.

[0106] 2. The request to get a new Signed Payer Offline Information or Signed PayeeOffline Information is sent to the transaction broker node 102, optionally along with a device identification and the current offline balance or other information to verify the account holder.

[0107] 3. The transaction broker node 102 authorizes and verifies the account holder that wants to update their offline information and optionally verifies that the device identification hasn’t been changed and that the offline balance on the device matches the offline balance stored in the financial institution.

[0108] 4. The transaction broker node 102 collects information about the account holder, adds the collected information along with the Payer Public Key or Payee Public Key, sets a new expiry date and signs the information using the Transaction Broker Node Private Key.

[0109] 5. The transaction broker node 102 sends the updated Signed Payer OfflineInformation or Signed Payee Offline Information containing the new expiry date to the account holder.

[0110] 6. The updated Signed Payer Offline Information or Signed Payee OfflineInformation is stored in the account holder’s application.

[0111] As noted, this process may be repeated at regular intervals. It may also be initiated by the account holder and / or the transaction broker node 102 at any time.

[0112] Transaction Process

[0113] When a Payer would like to pay a Payee, there are mainly 3 different options envisaged by the disclosed embodiments:• Payee requests a transaction from Payer using an initial verification before the actual transaction. This option is shown in FIG. 7. The use of an initial verification allows earlier detection of errors, and an offline transaction is not needed to be created if some manual verification of the Payer would fail. The initial verification uses one additional roundtrip message between the Payer and Payee, so it has drawbacks in case the peer-to- peer technology used to send information between Payer and Payee requires manual interaction, for example QR codes. The Payee can optionally choose to use an initial verification before the transaction is performed.• Payee requests a transaction from Payer without using an initial verification. This option is shown in FIG. 8.• Payer initiates the transaction directly to the Payer. This option is not detailed in a figure, as it is not as secure as the other options, but is contemplated by certain embodiments. Having the Payer initiating the transaction is the least secure option, as there is no possibility to include a nonce by the Payee or state which Payer information elements that are required for verification by the Payee. If the Payee Public Key is not known, then the Signed Offline Transaction would also not be possible to encrypt. The identifier of the Payee would also need to be set in the Signed Offline Transaction in some other way than provided by the Payee, for example reusing an identifier from an earlier transaction or using some other identifier like a mobile phone number or email address.

[0114] There are also other possible minor variations to the flow, for example, not encrypting data between Payer and Payee.

[0115] FIG. 7 illustrates a sequence diagram for an offline transaction with initial verification according to an embodiment.

[0116] 1. Payee 106a would like to receive funds from a Payer 104a in an offline transaction. Payee 106a decides to use an initial verification process of the offline transaction. The transaction amount is entered by Payee 106a or retrieved from some other system.

[0117] 2. Payee device 106, e.g., via an application, sends Signed Payee OfflineInformation to the Payer 104a to allow the Payer 104a to verify the Payee 106a and / or to encrypt sensitive information with the Payee Public Key. The transaction amount is included and the request could also contain which Signed Payer Offline Information elements that are required by the Payer.

[0118] 3. Payer device 104, e.g., via an application, verifies the Signed Payee OfflineInformation using the Transaction Broker Node Public Key that was shared in the sign-up process, or that was otherwise provided, e.g., via a key update message. The transaction amount is also verified against the Payer Offline Balance so that the Payer 104a has enough funds to perform the offline transaction.

[0119] 4. Payer 104a can verify the transaction amount and the Payee 106a, as well as decide if the required information about the Payer 104a can be sent to the Payee 106a.

[0120] 5. If the payer 104a declines the transaction, no further processing is required, though the payer device 104 may communicate the decision to the payee device 106. In this example, Payer 104a accepts the transaction.

[0121] 6. Payer device 104, e.g., via an application, optionally uses the Payee PublicKey to encrypt sensitive Signed Payer Offline Information elements.

[0122] 7. The Signed Payer Offline Information is sent from the Payer 104a to the Payee106a by their respective devices.

[0123] 8. If the Signed Payer Offline Information was encrypted, the Payee device 106 uses the Payee Private Key to decrypt it. The Payee device 106 then uses the Transaction Broker Node Public Key that was shared in the sign-up process, or that was otherwise provided, to verify the signature of the Signed Payer Offline Information.

[0124] 9. Payee device 106 then either verifies the information about the Payer 104a automatically, semi-automatically, or allows the Payee 106a to manually verify the information, or a combination of these. Which verification(s) that are performed could be mandated by the operator of the offline transaction system or chosen by the Payee 106a. Examples of how the verification may proceed are provided below.

[0125] For automatic verification, the Payee device 106 automatically verifies the trusted information about the Payer, i.e., without manual involvement from the Payee. For example: (i) Payee device 106 verifies current physical location against approved Payer locations in the Signed Payer Offline Information; (ii) Payee device 106 verifies Payer’s credit score in the information in Signed Payer Offline Information against a pre-defined minimum allowed credit score by Payee; (iii) Payee device 106 verifies expiry time included in Signed Payer Offline Information against the current time.

[0126] For semi-automatic verification, the Payee device 106 semi-automatically verifies the trusted information about the Payer 104a, i.e., with some manual involvement from the Payee 106a. For example: (i) Payer 104a is asked to enter their PIN code in either the Payee device 106 or Payer device 104 that is then automatically verified against the information in Signed Payer Offline Information; (ii) Payee 106a or Payer 104a enters / adds information in the Payee device 106 about the Payer 104a that is then automatically verified by the Payee device 106 against the information in Signed Payer Offline Information. The information could, for example, be age of the Payer, height of the Payer, or other types of information stored in Signed Payer Offline Information.

[0127] For manual verification, the Payee device 106 shows trusted information about the Payer 104a that the Payee 106a can verify manually. For example: (i) Payee device 106 shows the passport number of the Payer stored in the Signed Payer Offline Information, which the Payee can use to manually verify against the Payer’s passport; (ii) Payee device 106 shows a picture of the Payer stored in the Signed Payer Offline Information, which the Payee can use to manually verify against the physically present Payer.

[0128] 10. Payee device 106 sends a request to the Payer device 104 to perform the transaction. The request should include a nonce, for example a sequence number, randomnumber, or timestamp, that the Payer 104a should return as part of the transaction to prevent replay attacks. The request could also include the transaction amount and Signed Payer Offline Information again, and the request could optionally be encrypted using Payer Public Key.

[0129] 11. Payer device 104 decrypts the request if encrypted using the Payer PrivateKey, then verifies the request from the Payee device 106. The Payer device 104 then creates a Signed Offline Transaction that contains, in this example, at least the following information: (i) identifiers of the Payer and the Payee, for example the Payer Public Key and Payee Public Key;(ii) the transaction amount, and optionally currency; (iii) some kind of a nonce to make the transaction unique, such as a sequence number, a timestamp, or similar.

[0130] The offline transaction information is signed using the Payer Private Key and stored in the device as Payer Unsettled Offline Transactions. The Payer Offline Balance is updated to reflect the new offline transaction.

[0131] 12. Payer device 104 encrypts the Signed Offline Transaction using Payee Public

[0132] 13. Payer device 104 sends the encrypted Signed Offline Transaction to thePayee device 106.

[0133] 14. Payee device 106 decrypts the request using Payee Private Key and verifies the signature of the Signed Offline Transaction using the Payer Public Key and then the information in the offline transaction including the nonce. A successfully verified Signed Offline Transaction is stored in the Payee device 106 as Payee Unsettled Offline Transactions and the Payee Offline Balance is updated to reflect the transaction amount.

[0134] 15. If there are any issues after the Payer device 104 has sent the Signed OfflineTransaction that causes the transaction to fail for the Payee 106a, the Signed Offline Transaction must be removed from the Payee Unsettled Offline Transactions and the Payee Offline Balance must be reverted.

[0135] 16. The Payer device 104 should be informed of the failed transaction.

[0136] 17. Payer device 104 removes the Signed Offline Transaction from the PayerUnsettled Offline Transactions. The Payer Offline Balance is also reverted.

[0137] FIG. 8 illustrates a sequence diagram for an offline transaction without initial verification according to an embodiment.

[0138] 1. Payee 106a would like to receive funds from a Payer 104a in an offline transaction. Payee 106a decides not to use an initial verification process of the offline transaction. The transaction amount is entered by the Payee 106a or retrieved from some other system.

[0139] 2. Payee device 106 sends Signed Payee Offline Information to the Payer device104 to allow the Payer 104a to verify the Payee 106a and / or to encrypt sensitive information with the Payee Public Key. The transaction amount is included and the request could contain which Signed Payer Offline Information elements that are required by the Payee 106a. The request should include a nonce, for example a sequence number, random number, or timestamp, that the Payer 104a should return as part of the transaction to prevent replay attacks.

[0140] 3. Payer device 104 verifies the Signed Payee Offline Information using theTransaction Broker Node Public Key that was shared in the sign-up process or otherwise obtained. The transaction amount is also verified against the Payer Offline Balance so that the Payer has enough funds to perform the offline transaction.

[0141] 4. Payer 104a can verify the transaction amount and the Payee 106a, as well as decide if the required information about the Payer can be sent to the Payee 106a.

[0142] 5. If the payer 104a declines the transaction, no further processing is required, though the payer device 104 may communicate the decision to the payee device 106. In this example, Payer 104a accepts the transaction.

[0143] 6. Payer device 104 creates a Signed Offline Transaction that contains, in this example, at least the following information: (i) identifiers of the Payer and the Payer, for example the Payer Public Key and Payee Public Key; (ii) the transaction amount, and optionally currency; (iii) some kind of a nonce to make the transaction unique, such as a sequence number, a timestamp or similar. The offline transaction information is signed using the Payer Private Key and stored in the payer device 104 as Payer Unsettled Offline Transactions. The Payer Offline Balance is updated to reflect the new offline transaction.

[0144] 7. Payer device 104 includes the required Signed Payer Offline Information elements and the Signed Offline Transaction and optionally encrypts the information using Payee Public Key.

[0145] 8. The Signed Offline Transaction and Signed Payer Offline Information is sent from the Payer device 104 to the Payee device 106.

[0146] 9. If the Signed Offline Transaction and Signed Payer Offline Information were encrypted, the Payee device 106 uses the Payee Private Key to decrypt the information. The signature of the Signed Offline Transaction is verified using the Payer Public Key and then the information in the offline transaction is verified including the nonce. The Payee device 106 also uses the Transaction Broker Node Public Key that was shared in the sign-up process or otherwise obtained to verify the signature of the Signed Payer Offline Information.

[0147] 10. Payee device 106 then either verifies the information about the Payer 104a automatically, semi-automatically, or allows the Payee 106a to manually verify the information, or a combination of these. Which verification(s) that are performed could be mandated by the operator of the offline transaction system or chosen by the Payee 106a. Examples of this verification follow.

[0148] For automatic verification, the Payee device 106 automatically verifies the trusted information about the Payer 104a, i.e., without manual involvement from the Payee. For example: (i) Payee device 106 verifies current physical location against approved Payer locations in Signed Payer Offline Information; (ii) Payee device 106 verifies Payer’s credit score in the information in Signed Payer Offline Information against a pre-defined minimum allowed credit score by Payee 106a; (iii) Payee device 106 verifies expiry time included in Signed Payer Offline Information against the current time.

[0149] For semi-automatic verification, the Payee device 106 semi-automatically verifies the trusted information about the Payer 104a, i.e., with some manual involvement from the Payee 106a. For example: (i) Payer 104a is asked to enter their PIN code in either the Payee or Payer device that is then automatically verified against the information in Signed Payer Offline Information; (ii) Payee or Payee enters / adds information in the Payee device 106 about the Payer 104a that is then automatically verified by the Payee device 106 against the information inSigned Payer Offline Information. The information could, for example, be age of the Payer, height of the Payer, or other types of information stored in Signed Payer Offline Information.

[0150] For manual verification, the Payee device 106 shows trusted information about the Payer 104a that the Payee 106a can verify manually. For example: (i) Payee device 106 shows the passport number of the Payer 104a stored in the Signed Payer Offline Information, which the Payee 106a can use to manually verify against the Payer’s passport; (ii) Payee device 106 shows a picture of the Payer 104a stored in the Signed Payer Offline Information, which the Payee 106a can use to manually verify against the physically present Payer 104a.

[0151] 11. If the Payer 104a was successfully verified, the Signed Offline Transaction is stored in the Payee device 106 as Payee Unsettled Offline Transactions and the Payee Offline Balance is updated to reflect the transaction amount.

[0152] 12. If there are any issues after the Payer 104a has sent the Signed OfflineTransaction that causes the transaction to fail for the Payee 106a, the Payer device 104 should be informed of the failed transaction.

[0153] 13. Payer device 104 removes the Signed Offline Transaction from the PayerUnsettled Offline Transactions. The Payer Offline Balance is also reverted.

[0154] There is a possibility that a fraudulent Payee’s application might indicate to the Payer that the transaction failed (see steps 16-17 in FIG. 7, alternatively steps 12-13 in FIG. 8), but keep the Signed Offline Transaction by avoiding step 15 in FIG. 7 or step 12 in FIG. 8 and later send the Signed Offline Transaction for online settlement to receive the funds. One example might be a fraudulent merchant, who because of the “failed transaction” doesn’t have to provide the paid service or goods but still manages to receive the funds later during online settlement. There are some possible mitigations to this, such as the following:• The Payee application could be required to sign a failed transaction. With the signature, the Payer can prove that this transaction was actually failed if the Payee would send the offline transaction for online settlement.Payer application could verify if the Payee application is signed by the financial institution or centrally trusted authority, to ascertain that the Payee has not tampered with their application by not performing step 15 in FIG. 7 or step 12 in FIG. 8.

[0155] An option that can be used to further improve the security and privacy, is to share the public keys in an additional request and response between the Payer and Payee before any other information is shared, so that the initial request from Payee to the Payer can also be encrypted.

[0156] Online Settlement

[0157] FIG. 9 illustrates a sequence diagram for online settlement of offline transactions according to an embodiment. When a Payer or Payee device is online, i.e., the device is connected to a network that can communicate with the financial institution, all Payer Unsettled Offline Transactions or Payee Unsettled Offline Transactions should be uploaded to the financial institution so that the transaction can be performed online. The process is shown in FIG. 9.

[0158] An alternative to this process is to only allow the Payee to upload transactions for online settlement, which is an easier solution as only one party can upload transactions. Having both Payer and Payee being able to upload transactions for online settlement adds some extra redundancy, as it allows one of them to lose their device. The online settlement process could also be combined with the process for updating the signed information (e.g., see FIG. 6), so that the Payer or Payee automatically gets a new updated expiry time of the signed information as part of the online settlement.

[0159] 1. Payer or Payee’s device 104, 106 notes that it is online and that there areSigned Offline Transaction in the Payer Unsettled Offline Transactions or Payee Unsettled Offline Transactions. An alternative is that the Payer or Payee initiates the request themselves.

[0160] 2. Payer or Payee’s application uploads all Signed Offline Transaction from thePayer Unsettled Offline Transactions or Payee Unsettled Offline Transactions along with the Payer Offline Balance or Payee Offline Balance to the transaction broker node 102. The respective offline balance is not required but can be used for further verification purposes.

[0161] 3. Transaction broker node 102 starts to verify the uploaded Payer UnsettledOffline Transactions or Payee Unsettled Offline Transactions. Steps 3-7 may form a loop which are performed for each Signed Offline Transaction. The signature in each Signed Offline Transaction is verified using the Payer Public Key to make sure that the transaction was performed by the Payer. The transaction broker node 102 then checks if the transaction has already been processed, for example, if it has already been uploaded by the counterparty in the transaction.

[0162] 4. If the offline transaction has already been processed by the transaction broker node 102, the offline transaction will not be performed again.

[0163] 5. If the offline transaction has not already been processed by the transaction broker node 102, the transaction broker node 102 checks if the Payer has sufficient funds to perform the transaction.

[0164] 6. If the Payer has sufficient funds, the transaction is performed online by sending the funds in the offline transaction from the Payer to the Payee as defined in the Signed Offline Transaction. The transaction could be either directly from the Payer to the Payee, or it could be split in one or more transactions from the Payer to some intermediary offline system account, and then one or more transactions from some offline system account to the Payer.Using some offline system account between the Payer and Payee should improve the privacy of the offline transaction by avoiding a direct transaction from the Payer to the Payee. Using a direct transaction from the Payer to the Payee allows offline transactions to work in a similar way as online transactions. Embodiments support both variants. There are also other anonymization techniques that could be applied, for example by generating a random identifier representing the Payer in that transaction specifically, so that the Payee can’t easily identify the Payer.

[0165] 7. If the Payer has insufficient funds to perform a transaction for some reason, for example a reservation was not done for the offline balance, the failed transaction needs to be handled, for example mark it for manual handling, or allow the Payee to perform an automatic debt collection from the Payer that will automatically transfer incoming funds to the Payee until the debt has been paid off.

[0166] 8. The Payer Offline Balance or Payee Offline Balance are verified against theSigned Offline Transactions and a new balance is calculated.

[0167] 9. The result of the online settlement along with the updated Payer OfflineBalance or Payee Offline Balance is sent to the Payer or Payee device 104, 106.

[0168] 10. The Payer or Payee device 104, 106 clears the Payer Unsettled OfflineTransactions or Payee Unsettled Offline Transactions and updates the Payer Offline Balance or Payee Offline Balance.

[0169] 11. The result of the online settlement is shown to the Payer or Payee along with the updated Payer Offline Balance or Payee Offline Balance.

[0170] Other Alternatives

[0171] An alternative is to always use offline transactions process, even though the Payee is online. This would make the transaction process consistent for the Payer and Payee, no matter if the Payee is online or offline. The online settlement could then be performed as part of the offline transaction, or directly afterwards.

[0172] The offline transaction service could also be implemented as a separate node, where the account holder data is at the transaction broker node (e.g., a financial institution), but the offline specific data is at a payment service provider. The flows that include network communication with the transaction broker node 102 would add the payment service provider as an additional node. The offline transaction flows wouldn’t change, as the transaction is offline.

[0173] FIG. 10 is a flowchart illustrating a process 1000 for making an offline transaction between a payee (106a) and a payer (104a), according to an embodiment, performed by a payee device (106) in communication with a payer device (104). Process 1000 may begin in step S1002.

[0174] Step sl002 comprises sending (sl002), by the payee device (106), towards the payer device (104), a first message including signed payee offline information.

[0175] Step sl004 comprises receiving (sl004), by the payee device (106), from the payer device (104), signed payer offline information that is signed with a transaction broker node private key.

[0176] Step sl006 comprises receiving (sl006), by the payee device (106), from the payer device (104), a signed offline transaction that is signed with a payer private key.

[0177] Step sl008 comprises verifying (sl008), by the payee device (106), the signed payer offline information.

[0178] Step slOlO comprises verifying (slOlO), by the payee device (106), the signed offline transaction.

[0179] Step sl012 comprises as a result of verifying, by the payee device (106), the signed payer offline information and the signed offline transaction, accepting (sl012) the signed offline transaction.

[0180] In some embodiments, the method further includes receiving, by the payee device (106), from the payer device (104), an offline transaction request. In some embodiments, the signed payer offline information and the signed offline transaction are received by the payee device (106) in a single message. In some embodiments, the first message is an offline transaction request and the first message further includes a nonce. In some embodiments, the signed payer offline information is received by the payee device (106) in a second message and the signed offline transaction is received by the payee device (106) in a third message different from the second message. In some embodiments, verifying (sl008), by the payee device (106), the signed payer offline information is performed in response to receiving the second message, and the method further comprises, in response to receiving the second message, sending an offline transaction request to the payer device (104), wherein the offline transaction request includes a nonce.

[0181] In some embodiments, the first message further includes a transaction amount and the signed payee offline information includes information about the payee (106a). In some embodiments, the information about the payee (106a) includes one or more of: (i) a public key, (ii) an identifier, (iii) an expiration time, (iv) a photograph, and (v) a visual description, each associated with the payee (106a). In some embodiments, the signed payer offline information includes information about the payer (104a). In some embodiments, the information about the payer (104a) includes one or more of: (i) a public key, (ii) an identifier, (iii) an expiration time, (iv) a photograph, (v) a visual description, (vi) a know-your-customer (KYC) level, (vii) a creditscore, (viii) an offline transaction reservation amount, (ix) biometric data, (x) allowed, disallowed, preferred, and / or non-preferred offline transaction locations, (xi) allowed and / or disallowed currencies, (xii) passcode and / or personal identification number (PIN) code, (xiii) a device identifier, (xiv) a per-transaction amount limit and / or a range of permitted per-transaction amounts, and (xv) one or more security questions and answers, each associated with the payer (104a).

[0182] In some embodiments, verifying (sl008), by the payee device (106), the signed payer offline information comprises obtaining the transaction broker node public key from a source independent of the payer (104a), and authenticating the signed payer offline information using the transaction broker node public key. In some embodiments, verifying (sl008), by the payee device (106), the signed payer offline information further comprises using one or more information elements contained in the signed payer offline information to authenticate the payer (104a). In some embodiments, verifying (slOlO), by the payee device (106), the signed offline transaction comprises obtaining the payer public key from a source independent of the payer (104a), and authenticating the signed offline transaction using the payer public key. In some embodiments, one or more of the first message, the signed payer offline information, and the signed offline transaction is encrypted.

[0183] In some embodiments, the method further includes registering, by the payee device (106), with a transaction broker node (102) to participate in offline transactions as a payee; and receiving, from the transaction broker node (102), the signed payee offline information and the transaction broker node public key. In some embodiments, the method further includes sending towards a transaction broker node (102) the signed offline transaction for settling the signed offline transaction. In some embodiments, the method further includes updating, by the payee device (106), the signed payee offline information.

[0184] FIG. 11 is a flowchart illustrating a process 1100 for making an offline transaction between a payee (106a) and a payer (104a), according to an embodiment, performed by a payer device (104) in communication with a payee device (106). Process 1100 may begin in step si 102.

[0185] Step si 102 comprises receiving (si 102), by the payer device (104), from the payee device (106), a first message including signed payee offline information that is signed with a transaction broker node private key.

[0186] Step si 104 comprises verifying (si 104), by the payer device (104), the signed payee offline information.

[0187] Step si 106 comprises sending (si 106), by the payer device (104), towards the payee device (106), signed payer offline information.

[0188] Step si 108 comprises creating (si 108) a signed offline transaction.

[0189] Step si 110 comprises sending (si 110), by the payer device (104), towards the payee device (106), the signed offline transaction.

[0190] In some embodiments, the method further includes sending, by the payer device (104), towards the payer device (104), an offline transaction request. In some embodiments, the signed payer offline information and the signed offline transaction are sent by the payer device (104) in a single message. In some embodiments, the first message is an offline transaction request and the first message further includes a nonce. In some embodiments, the signed payer offline information is sent by the payer device (104) in a second message and the signed offline transaction is sent by the payer device (104) in a third message different from the second message. In some embodiments, the method further comprises, after sending the second message, receiving an offline transaction request from the payee device (106), wherein the offline transaction request includes a nonce.

[0191] In some embodiments, the first message further includes a transaction amount and the signed payee offline information includes information about the payee (106a). In some embodiments, the information about the payee (106a) includes one or more of: (i) a public key, (ii) an identifier, (iii) an expiration time, (iv) a photograph, and (v) a visual description, each associated with the payee (106a). In some embodiments, the signed payer offline information includes information about the payer (104a). In some embodiments, the information about the payer (104a) includes one or more of: (i) a public key, (ii) an identifier, (iii) an expiration time, (iv) a photograph, (v) a visual description, (vi) a know-your-customer (KYC) level, (vii) a credit score, (viii) an offline transaction reservation amount, (ix) biometric data, (x) allowed,disallowed, preferred, and / or non-preferred offline transaction locations, (xi) allowed and / or disallowed currencies, (xii) passcode and / or personal identification number (PIN) code, (xiii) a device identifier, (xiv) a per-transaction amount limit and / or a range of permitted per-transaction amounts, and (xv) one or more security questions and answers, each associated with the payer (104a).

[0192] In some embodiments, verifying (si 104), by the payer device (104), the signed payee offline information comprises obtaining the transaction broker node public key from a source independent of the payee (106a), and authenticating the signed payee offline information using the transaction broker node public key. In some embodiments, verifying (si 104), by the payer device (104), the signed payee offline information further comprises using one or more information elements contained in the signed payee offline information to authenticate the payee (106a). In some embodiments, the method further includes updating a payer offline balance based on the signed offline transaction. In some embodiments, one or more of the first message, the signed payer offline information, and the signed offline transaction is encrypted.

[0193] In some embodiments, the method further includes registering, by the payer device (104), with a transaction broker node (102) to participate in offline transactions as a payer; and receiving, from the transaction broker node, the signed payer offline information and the transaction broker node public key. In some embodiments, the method further includes sending towards a transaction broker node (102) the signed offline transaction for settling the signed offline transaction. In some embodiments, the method further includes updating, by the payer device (104), the signed payer offline information.

[0194] FIG. 12 is a block diagram of apparatus 1200 (e.g., transaction broker node 102, payer device 104, payee device 106), according to some embodiments, for performing the methods disclosed herein. As shown in FIG. 12, apparatus 1200 may comprise: processing circuitry (PC) 1202, which may include one or more processors (P) 1255 (e.g., a general purpose microprocessor and / or one or more other processors, such as an application specific integrated circuit (ASIC), field-programmable gate arrays (FPGAs), and the like), which processors may be co-located in a single housing or in a single data center or may be geographically distributed (i.e., apparatus 1200 may be a distributed computing apparatus); at least one network interface 1248 comprising a transmitter (Tx) 1245 and a receiver (Rx) 1247 for enabling apparatus 1200 totransmit data to and receive data from other nodes connected to a network 1210 (e.g., an Internet Protocol (IP) network) to which network interface 1248 is connected (directly or indirectly) (e.g., network interface 1248 may be wirelessly connected to the network 1210, in which case network interface 1248 is connected to an antenna arrangement); and a storage unit (a.k.a., “data storage system”) 1208, which may include one or more non-volatile storage devices and / or one or more volatile storage devices. Interface 1260 may connect PC 1202 and storage unit 1208, interface 762 may connect PC 1202 and network interface 1248, and interface 1264 may connect network interface 1248 and network 1210. In embodiments where PC 1202 includes a programmable processor, a computer program product (CPP) 1241 may be provided. CPP 1241 includes a computer readable medium (CRM) 1242 storing a computer program (CP) 1243 comprising computer readable instructions (CRI) 1244. CRM 1242 may be a non-transitory computer readable medium, such as, magnetic media (e.g., a hard disk), optical media, memory devices (e.g., random access memory, flash memory), and the like. In some embodiments, the CRI 1244 of computer program 1243 is configured such that when executed by PC 1202, the CRI causes apparatus 1200 to perform steps described herein (e.g., steps described herein with reference to the flow charts). In other embodiments, apparatus 1200 may be configured to perform steps described herein without the need for code. That is, for example, PC 1202 may consist merely of one or more ASICs. Hence, the features of the embodiments described herein may be implemented in hardware and / or software.

[0195] While various embodiments are described herein, it should be understood that they have been presented by way of example only, and not limitation. Thus, the breadth and scope of this disclosure should not be limited by any of the above described exemplary embodiments. Moreover, any combination of the above-described embodiments in all possible variations thereof is encompassed by the disclosure unless otherwise indicated herein or otherwise clearly contradicted by context.

[0196] Additionally, while the processes described above and illustrated in the drawings are shown as a sequence of steps, this was done solely for the sake of illustration. Accordingly, it is contemplated that some steps may be added, some steps may be omitted, the order of the steps may be re-arranged, and some steps may be performed in parallel.

Claims

CLAIMS1. A method for making an offline transaction between a payee (106a) and a payer (104a), performed by a payee device (106) in communication with a payer device (104), the method comprising: sending (sl002), by the payee device (106), towards the payer device (104), a first message including signed payee offline information; receiving (sl004), by the payee device (106), from the payer device (104), signed payer offline information that is signed with a transaction broker node private key; receiving (sl006), by the payee device (106), from the payer device (104), a signed offline transaction that is signed with a payer private key; verifying (sl008), by the payee device (106), the signed payer offline information; verifying (slOlO), by the payee device (106), the signed offline transaction; and as a result of verifying, by the payee device (106), the signed payer offline information and the signed offline transaction, accepting (sl012) the signed offline transaction.

2. The method of claim 1, further comprising receiving, by the payee device (106), from the payer device (104), an offline transaction request.

3. The method of claim 1, wherein the signed payer offline information and the signed offline transaction are received by the payee device (106) in a single message.

4. The method of claim 3, wherein the first message is an offline transaction request and the first message further includes a nonce.

5. The method of claim 1, wherein the signed payer offline information is received by the payee device (106) in a second message and the signed offline transaction is received by the payee device (106) in a third message different from the second message.

6. The method of claim 5, wherein verifying (sl008), by the payee device (106), the signed payer offline information is performed in response to receiving the second message, and the method further comprises, in response to receiving the second message, sending an offline transaction request to the payer device (104), wherein the offline transaction request includes a nonce.

7. The method of any one of claims 1-6, wherein the first message further includes a transaction amount and the signed payee offline information includes information about the payee (106a).

8. The method of claim 7, wherein the information about the payee (106a) includes one or more of: (i) a public key, (ii) an identifier, (iii) an expiration time, (iv) a photograph, and (v) a visual description, each associated with the payee (106a).

9. The method of any one of claims 1-8, wherein the signed payer offline information includes information about the payer (104a).

10. The method of claim 9, wherein the information about the payer (104a) includes one or more of: (i) a public key, (ii) an identifier, (iii) an expiration time, (iv) a photograph, (v) a visual description, (vi) a know-your-customer (KYC) level, (vii) a credit score, (viii) an offline transaction reservation amount, (ix) biometric data, (x) allowed, disallowed, preferred, and / or non-preferred offline transaction locations, (xi) allowed and / or disallowed currencies, (xii) passcode and / or personal identification number (PIN) code, (xiii) a device identifier, (xiv) a per-transaction amount limit and / or a range of permitted per-transaction amounts, and (xv) one or more security questions and answers, each associated with the payer (104a).

11. The method of any one of claims 1-10, wherein verifying (sl008), by the payee device (106), the signed payer offline information comprises obtaining the transaction broker node public key from a source independent of the payer (104a), and authenticating the signed payer offline information using the transaction broker node public key.

12. The method of claim 11, wherein verifying (sl008), by the payee device (106), the signed payer offline information further comprises using one or more information elements contained in the signed payer offline information to authenticate the payer (104a).

13. The method of any one of claims 1-12, wherein verifying (slOlO), by the payee device (106), the signed offline transaction comprises obtaining the payer public key from a source independent of the payer (104a), and authenticating the signed offline transaction using the payer public key.

14. The method of any one of claims 1-13, wherein one or more of the first message, the signed payer offline information, and the signed offline transaction is encrypted.

15. The method of any one of claims 1-14, further comprising: registering, by the payee device (106), with a transaction broker node (102) to participate in offline transactions as a payee; and receiving, from the transaction broker node (102), the signed payee offline information and the transaction broker node public key.

16. The method of any one of claims 1-15, further comprising sending towards a transaction broker node (102) the signed offline transaction for settling the signed offline transaction.

17. The method of any one of claims 1-16, further comprising updating, by the payee device (106), the signed payee offline information.

18. A method for making an offline transaction between a payee (106a) and a payer (104a), performed by a payer device (104) in communication with a payee device (106), the method comprising: receiving (si 102), by the payer device (104), from the payee device (106), a first message including signed payee offline information that is signed with a transaction broker node private key; verifying (si 104), by the payer device (104), the signed payee offline information ; sending (si 106), by the payer device (104), towards the payee device (106), signed payer offline information; creating (si 108) a signed offline transaction; and sending (si 110), by the payer device (104), towards the payee device (106), the signed offline transaction.

19. The method of claim 18, further comprising sending, by the payer device (104), towards the payee device (106), an offline transaction request.

20. The method of claim 18, wherein the signed payer offline information and the signed offline transaction are sent by the payer device (104) in a single message.

21. The method of claim 20, wherein the first message is an offline transaction request and the first message further includes a nonce.

22. The method of claim 18, wherein the signed payer offline information is sent by the payer device (104) in a second message and the signed offline transaction is sent by the payer device (104) in a third message different from the second message.

23. The method of claim 22, wherein the method further comprises, after sending the second message, receiving an offline transaction request from the payee device (106), wherein the offline transaction request includes a nonce.

24. The method of any one of claims 18-23, wherein the first message further includes a transaction amount and the signed payee offline information includes information about the payee (106a).

25. The method of claim 24, wherein the information about the payee (106a) includes one or more of: (i) a public key, (ii) an identifier, (iii) an expiration time, (iv) a photograph, and (v) a visual description, each associated with the payee (106a).

26. The method of any one of claims 18-25, wherein the signed payer offline information includes information about the payer (104a).

27. The method of claim 26, wherein the information about the payer (104a) includes one or more of: (i) a public key, (ii) an identifier, (iii) an expiration time, (iv) a photograph, (v) a visual description, (vi) a know-your-customer (KYC) level, (vii) a credit score, (viii) an offline transaction reservation amount, (ix) biometric data, (x) allowed, disallowed, preferred, and / or non-preferred offline transaction locations, (xi) allowed and / or disallowed currencies, (xii)passcode and / or personal identification number (PIN) code, (xiii) a device identifier, (xiv) a pertransaction amount limit and / or a range of permitted per-transaction amounts, and (xv) one or more security questions and answers, each associated with the payer (104a).

28. The method of any one of claims 18-27, wherein verifying (si 104), by the payer device (104), the signed payee offline information comprises obtaining the transaction broker node public key from a source independent of the payee (106a), and authenticating the signed payee offline information using the transaction broker node public key.

29. The method of claim 28, wherein verifying (si 104), by the payer device (104), the signed payee offline information further comprises using one or more information elements contained in the signed payee offline information to authenticate the payee (106a).

30. The method of any one of claims 18-29, further comprising updating a payer offline balance based on the signed offline transaction.

31. The method of any one of claims 18-30, wherein one or more of the first message, the signed payer offline information, and the signed offline transaction is encrypted.

32. The method of any one of claims 18-31, further comprising: registering, by the payer device (104), with a transaction broker node (102) to participate in offline transactions as a payer; and receiving, from the transaction broker node, the signed payer offline information and the transaction broker node public key.

33. The method of any one of claims 18-32, further comprising sending towards a transaction broker node (102) the signed offline transaction for settling the signed offline transaction.

34. The method of any one of claims 18-33, further comprising updating, by the payer device (104), the signed payer offline information.

35. A payee device (106) comprising: processing circuitry (1202); and a memory, the memory containing instructions (1244) executable by the processing circuitry (1202), whereby when executed the processing circuitry (1202) is configured to: send, by the payee device (106), towards the payer device (104), a first message including signed payee offline information; receive, by the payee device (106), from the payer device (104), signed payer offline information that is signed with a transaction broker node private key; receive, by the payee device (106), from the payer device (104), a signed offline transaction that is signed with a payer private key; verify, by the payee device (106), the signed payer offline information; verify, by the payee device (106), the signed offline transaction; and as a result of verifying, by the payee device (106), the signed payer offline information and the signed offline transaction, accept the signed offline transaction.

36. The payee device (106) of claim 35, wherein the processing circuitry (1202) is further configured to perform any one of the methods of claims 2-17.

37. A payer device (104) comprising:processing circuitry (1202); and a memory, the memory containing instructions (1244) executable by the processing circuitry (1202), whereby when executed the processing circuitry (1202) is configured to: receive, by the payer device (104), from the payee device (106), a first message including signed payee offline information that is signed with a transaction broker node private key; verify, by the payer device (104), the signed payee offline information; send, by the payer device (104), towards the payee device (106), signed payer offline information; create a signed offline transaction; and send, by the payer device (104), towards the payee device (106), the signed offline transaction.

38. The payer device (104) of claim 37, wherein the processing circuitry (1202) is further configured to perform any one of the methods of claims 19-34.

39. A computer program (1243) comprising instructions which when executed by processing circuitry (1202) of a node (1200), causes the node (1200) to perform the method of any one of claims 1-34.

40. A carrier containing the computer program (1243) of claim 27, wherein the carrier is one of an electronic signal, an optical signal, a radio signal, and a computer readable storage medium (1242).

Images