EP3123426A1 - Système de paiement hors ligne sécurisé - Google Patents

Système de paiement hors ligne sécurisé

Info

Publication number
EP3123426A1
EP3123426A1 EP15769698.0A EP15769698A EP3123426A1 EP 3123426 A1 EP3123426 A1 EP 3123426A1 EP 15769698 A EP15769698 A EP 15769698A EP 3123426 A1 EP3123426 A1 EP 3123426A1
Authority
EP
European Patent Office
Prior art keywords
communication device
mobile communication
payment transaction
user
management system
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP15769698.0A
Other languages
German (de)
English (en)
Other versions
EP3123426A4 (fr
Inventor
Fan Jiang
Aneto Pablo OKONKWO
Erwin AITENBICHLER
Iyad ASSAD
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Google LLC
Original Assignee
Google LLC
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US14/226,798 external-priority patent/US20150278796A1/en
Priority claimed from US14/226,785 external-priority patent/US20150278795A1/en
Application filed by Google LLC filed Critical Google LLC
Publication of EP3123426A1 publication Critical patent/EP3123426A1/fr
Publication of EP3123426A4 publication Critical patent/EP3123426A4/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/405—Establishing or using transaction specific rules
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G06Q20/108—Remote banking, e.g. home banking
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
    • G06Q20/3224—Transactions dependent on location of M-devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/327—Short range or proximity payments by means of M-devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/327—Short range or proximity payments by means of M-devices
    • G06Q20/3272—Short range or proximity payments by means of M-devices using an audio code
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/327—Short range or proximity payments by means of M-devices
    • G06Q20/3278—RFID or NFC payments by means of M-devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • G06Q20/3676—Balancing accounts
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • G06Q20/3678—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes e-cash details, e.g. blinded, divisible or detecting double spending
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3821—Electronic credentials
    • G06Q20/38215—Use of certificates or encrypted proofs of transaction rights
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3825—Use of electronic signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/403—Solvency checks
    • G06Q20/4033—Local solvency checks

Definitions

  • the present disclosure relates generally to a payment system, and more particularly to methods and systems that allow users to perform payment transactions offline and without network access.
  • Proximity communication technology has a limited range of one meter or less and can enable merchant device payment technologies.
  • the short communication distances enable customer identification and secure communication between proximity communication enabled devices.
  • proximity communication technologies comprise Near Field Communication (NFC), Radio frequency identification (RFID), or Bluetooth Low Energy (BLE).
  • NFC Near Field Communication
  • RFID Radio frequency identification
  • BLE Bluetooth Low Energy
  • a user "taps" a device, such as an NFC-enabled mobile phone or NFC-enable smart card, to a reader.
  • the reader recognizes the NFC-enabled device when the device is moved within range of the reader, establishes a secure communication channel with the device, and initiates a payment transaction between the reader and the device.
  • a user brings a device, such as a BLE-enabled mobile phone into close proximity of another BLE-enabled device, such as another BLE-enabled mobile phone.
  • the BLE devices detect that they are in proximity of each other and can establish a secure communication channel to initiate a payment transaction.
  • Mobile communication devices can be utilized in a transaction that involves the exchange of data or information, for example, in financial transactions.
  • a mobile communication device used in a financial transaction is linked to a financial account or contains financial account information. Consequently, when the mobile communication device is used, the reader receives the financial account information and conducts a debit transaction from the financial account, requiring network access to process the on-line transaction.
  • Such conventional mobile communication device enabled financial transactions are inoperable when access to a network or to specific computers on the network is not available.
  • a method for providing secure offline payments comprises a user device that requests a deposit of funds into a user account maintained by an account management system and/or requests an up-to-date balance certificate.
  • the request may comprise a request to lock certain funds in the user's account to prevent double spending.
  • the user device request may also comprise a duration that funds are locked and/or a request that certain funds are only available at a certain location.
  • the lock is later removed when the unlocked funds are used, the balance certificate expires, and/or the user requests that the lock is removed.
  • the account management system accesses the user's account management system account, determines the available unlocked funds, creates and signs a balance certificate, and transmits the signed balance certificate to the user device.
  • the user device and a merchant device establish a communication channel.
  • the merchant device transmits a payment request to the user device, and the user device generates a signed withdrawal record for a payment amount.
  • the signed withdrawal record and the signed balance certificate are transmitted to the merchant device, where the merchant device verifies the signed withdrawal record to confirm the identity of the user device and verifies the signed balance to confirm the availability of the funds to complete the offline payment transaction.
  • the merchant device signs the withdrawal record, transmits it to the user device, and saves it until the merchant device has network access.
  • the merchant device has network access, it transmits the signed withdrawal certificate to the account management system.
  • the account management system verifies the withdrawal record and records the withdrawal record in the user's account management system account.
  • the user device requests a new balance certificate
  • the user device transmits the signed withdrawal record to the account management system, and the account management system verifies the account balance, and creates a new balance certificate.
  • Figure 1 is a block diagram depicting an offline payment system, in accordance with certain example embodiments.
  • Figure 2 is a block flow diagram depicting a method for processing an offline payment transaction, in accordance with certain example embodiments.
  • Figure 3 is a block flow diagram depicting a method for receiving an up-to- date balance certificate from an account management system, in accordance with certain example embodiments.
  • Figure 4 is a block flow diagram depicting a method for providing a singed balance certificate to a user device, in accordance with certain example embodiments.
  • Figure 5 is a block flow diagram depicting a method for calculating a balance of available funds in a user account, in accordance with certain example embodiments.
  • Figure 6 is a block flow diagram depicting a method for processing a payment request received from a merchant device, in accordance with certain example embodiments.
  • Figure 7 is a block flow diagram depicting a method for verifying a user device response to a payment request, in accordance with certain example embodiments.
  • Figure 8 is a block flow diagram depicting a method for verifying a withdrawal record, in accordance with certain example embodiments.
  • Figure 9 is a block diagram depicting a computer machine and module, in accordance with certain example embodiments.
  • a user enables an application and authorizes a user device to communicate a request to perform an offline payment transaction to an account management system.
  • the user device establishes a communication channel with the account management system and requests to deposit funds into a user account maintained by the account management system and/or requests an up-to-date balance certificate.
  • the account management system accesses the user's account management system account and creates the balance certificate.
  • the balance certificate is limited in time (for example, it expires after a predefined amount of time has passed), limited in the number of payment transactions it can be used in (for example, it expires after being used in an offline payment transaction), limited by the amount of funds available for a single offline payment transaction (for example, it can be used for an offline payment transaction under X dollars) and/or limited by a location (for example, it can be used for an offline payment transaction only at a restaurant or only at location Z).
  • the account management system signs the balance certificate with a balance certificate private key and transmits the balance certificate to the user device.
  • only a selected portion of the funds in the user's account management system account are available for each offline payment transaction, and the remaining funds are locked to prevent double spending.
  • the user determines the amount and duration of the locked funds. For example, the user submits a request to lock certain funds in the request for a balance certificate.
  • the account management system determines the amount and duration of the locked funds.
  • the account management system and the user determine the amount and duration of the locked funds.
  • the user requests that certain funds are only available at a certain location (for example, the user only wishes to use funds for mass transit, at restaurants, or in City X).
  • the requested lock is removed when the unlocked funds are used, the balance certificate expires, and/or the user requests that the lock is removed.
  • the user indicates a desire to complete an offline payment transaction with a merchant or other transaction counterparty.
  • the user "taps" the user device within a predefined distance of a merchant device, and the devices establish a communication channel.
  • the devices communicate via a near field communication (NFC), Bluetooth, or short-range communication channel.
  • NFC near field communication
  • the merchant device transmits a payment request to the user device, and the user device generates a withdrawal record for an amount indicated on the payment request received from the merchant device.
  • the user device signs the withdrawal record with an account certificate private key and transmits the signed withdrawal record with the signed balance certificate to the merchant device.
  • the merchant device verifies the signed withdrawal record using an account certificate public key to confirm the identity of the user device.
  • the merchant device also verifies the signed balance certificate using a balance certificate public key to confirm the balance certificate is not expired and to confirm the availability of the funds to complete the offline payment transaction.
  • the merchant device signs the withdrawal record using a merchant device signing certificate, transmits it to the user device, and saves it until the merchant device has network access.
  • the merchant device transmits a status code or message to the user device indicating that the transaction was successful. When the merchant device has network access, it transmits the signed withdrawal certificate to the account management system.
  • the account management system verifies the withdrawal record using the merchant device signing certificate public key and records the withdrawal record in the user's account management system account.
  • the user device requests a new balance certificate
  • the user device transmits the signed withdrawal record to the account management system
  • the account management system verifies the account balance, and creates a new balance certificate.
  • FIG. 1 is a block diagram depicting an offline payment system 100, in accordance with certain example embodiments.
  • the exemplary operating environment 100 comprises a merchant computing device 120, a user computing device 110, and an account management computing system 130 that are configured to communicate with one another via one or more networks 140.
  • a user associated with a device must install an application and/or make a feature selection to obtain the benefits of the techniques described herein.
  • the user device 110 and the merchant device 120 are configured to communicate directly and exchange information without a network 140 connection.
  • the devices communicate via a proximity communication technology.
  • a proximity communication technology For example, via a near field communication channel, Bluetooth communication, Bluetooth Low Energy (BLE) communication, a form of standardized radio frequency, infrared, sound (for example, audible sounds, melodies, and ultrasound), other short range communication channel, or system that facilitates the communication of signals, data, and/or messages (generally referred to as data).
  • BLE Bluetooth Low Energy
  • a user associated with a device must install an application and/or make a feature selection to obtain the benefits of the techniques described herein.
  • Each network 140 includes a wired or wireless telecommunication means by which network systems/de vices (including systems/devices 110, 120, and 130) can communicate and exchange data.
  • each network 140 can be implemented as, or may be a part of, a storage area network (SAN), personal area network (PAN), a metropolitan area network (MAN), a local area network (LAN), a wide area network (WAN), a wireless local area network (WLAN), a virtual private network (VPN), an intranet, an Internet, a mobile telephone network, a card network, or any combination thereof, or any other appropriate architecture.
  • SAN storage area network
  • PAN personal area network
  • MAN metropolitan area network
  • LAN local area network
  • WAN wide area network
  • WLAN wireless local area network
  • VPN virtual private network
  • intranet an Internet
  • a mobile telephone network a card network, or any combination thereof, or any other appropriate architecture.
  • each network computing system 110, 120, 130 includes a device having a communication module capable of transmitting and receiving data over the network 140.
  • each network systems/devices may comprise a server, personal computer, mobile device (for example, notebook computer, tablet computer, netbook computer, personal digital assistant (PDA), video game device, GPS locator device, cellular telephone, Smartphone, or other mobile device), a television with one or more processors embedded therein and/or coupled thereto, or other appropriate technology that includes or is coupled to a web browser or other application for communicating via the network 140.
  • the network systems/de vices including systems/devices 110, 120, and 130
  • the network systems/de vices are operated by merchants, users, and an account management system operator, respectively.
  • the merchant device 120 can refer to a smart communication device that can communicate via an electronic, magnetic, or radio frequency field between the device 120 and another device, such as a user device 110.
  • the merchant device 120 has processing capabilities, such as storage capacity/memory and one or more applications 125 that can perform a particular function.
  • the merchant device 120 contains an operating system (not illustrated) and user interface 121.
  • Example merchant devices 120 smart phones, mobile phones, personal digital assistants (PDAs), mobile computing devices (for example, netbooks, tablets, and iPads), laptops, wearable computing devices (for example, watches, rings, or glasses), and other devices, in each case having processing and user interface functionality.
  • PDAs personal digital assistants
  • mobile computing devices for example, netbooks, tablets, and iPads
  • laptops wearable computing devices (for example, watches, rings, or glasses), and other devices, in each case having processing and user interface functionality.
  • the controller 126 is a Bluetooth link controller.
  • the Bluetooth link controller 126 may be capable of sending and receiving data, identifying the user device 110, performing authentication and ciphering functions, and directing how the merchant device 120 will listen for transmissions from the user device 110 or configure the merchant device 120 into various power-save modes according to the Bluetooth-specified procedures.
  • the controller 126 is a Wi-Fi controller or an NFC controller capable of performing similar functions.
  • the application 125 is a program, function, routine, applet or similar entity that exists on and performs its operations on a merchant device 120.
  • the application 125 may be one or more of an offline payment application, a digital wallet application, a coupon application, a loyalty card application, another value-added application, a user interface application, or other suitable application operating on the merchant device 120.
  • the merchant device 120 may comprise a secure element (not illustrated), which can exist within a removable smart chip or a secure digital (SD) card or which can be embedded within a fixed chip on the device 120.
  • SIM Subscribed Identity Module
  • the secure element allows a software application 125 resident on the device 120 and accessible by the device user to interact securely with certain functions within the secure element, while protecting information stored within the secure element.
  • the secure element may comprise one or more applications 125 running thereon that perform the functionality described herein.
  • An example merchant device 120 comprises one or more keys and/or certificates.
  • the merchant device 120 verifies a withdrawal record received from the user device 110 in response to a payment request.
  • the user device 110 signs the withdrawal record using an account certificate 112 and the merchant device verifies the record using an account certificate public key 112s to confirm the identity of the user device 110.
  • the merchant device 110 verifies a balance certificate 113 received from the user device 110 in response to a payment request.
  • the merchant device 120 verifies the balance certificate 113 using a balance certificate public key 113a to confirm the balance certificate 113a is not expired and to confirm the availability of the funds to complete the offline payment transaction.
  • the merchant device 120 signs the withdrawal record using a merchant device signing certificate 124 and transmits the signed withdrawal record to the user device 110. Both devices (110 and 120) save the signed withdrawal record the devices (110 and 120) have network 140 access and can transmit the record to the account management system 130.
  • the data storage unit 129 may be implemented in a secure element or other secure memory (not shown) on the merchant device 120 or may be a separate memory unit resident on the merchant device 120.
  • An example data storage unit 129 enables storage of signed withdrawal records until the merchant device 120 has network 140 access and can communicate the signed withdrawal records to the account management system 130.
  • the data storage unit 129 can include any local or remote data storage structure accessible to the merchant device 120 suitable for storing information.
  • the data storage unit 129 stores encrypted information, such as HTML5 local storage.
  • the merchant device 120 may connect to network 140 via a wired connection.
  • the connection may be a wired universal serial bus (USB) or Ethernet connection.
  • the merchant device 120 may connect to the network via a wireless connection.
  • the connection may be a Wi-Fi or Bluetooth connection to a hotspot that has a wired/wireless Internet connection (for example, MiFi), or any other wired or wireless connection suitable for communicating signals with network 140.
  • the connection may be a cellular network connection.
  • the merchant device 120 functions as a point of sale (POS) terminal and is capable of processing a purchase transaction initiated by a user of a user device 110.
  • the user requests a purchase from the merchant device 120.
  • the merchant device 120 receives or otherwise reads payment account information from the user device 110.
  • the purchase is initiated by a wireless "tap" of the user device 110 with the merchant device 120.
  • the merchant device 120 communicates with the user device 110 via an antenna 127.
  • the controller 126 is notified of the state of readiness of the merchant device 120 for a transaction.
  • the controller 126 outputs through the antenna 127 a radio signal, or listens for radio signals from the user device 110.
  • the merchant device 120 may request a list of applications 115 available from the user device 110.
  • a directory is first displayed, after which, based on the set priority or the type of user device 110, an application 115 is chosen and initiated for the transaction.
  • An example user device 110 can refer to a smart communication device that can communicate via an electronic, magnetic or radio frequency field between the user device 110 and another device, such as a merchant device 120 using an antenna 117.
  • the user device 110 has processing capabilities, such as storage capacity/memory and one or more applications 115 that can perform a particular function.
  • the user device 110 contains an operating system (not illustrated) and user interface 111.
  • Example user device 110 comprise smart phones, mobile phones, personal digital assistants (PDAs), mobile computing devices (for example, netbooks, tablets, and iPads), laptops, wearable computing devices (for example, watches, rings, or glasses), and other devices, in each case having processing and user interface functionality.
  • PDAs personal digital assistants
  • mobile computing devices for example, netbooks, tablets, and iPads
  • laptops wearable computing devices (for example, watches, rings, or glasses), and other devices, in each case having processing and user interface functionality.
  • the user can use the user device 110 to perform an offline payment transaction via a user interface 111 and the application 115.
  • the application 115 is a program, function, routine, applet or similar entity that exists on and performs its operations on the user device 110.
  • the application 115 may be one or more of a shopping application, merchant device 120 application, a payment application, a digital wallet application, a loyalty card application, another value-added application, a user interface 111 application, or other suitable application operating on the user device 110.
  • the user must install an application 115 and/or make a feature selection on the user device 110 to obtain the benefits of the techniques described herein.
  • the user device 110 may comprise a secure element (not illustrated), which can exist within a removable smart chip or a secure digital (SD) card, which can be embedded within a fixed chip on the device 110, or be realized as a secure compartment of a security-enhanced operating system.
  • SIM Subscribed Identity Module
  • SIM cards may be capable of hosting a secure element, for example, an NFC SIM Card.
  • the secure element allows a software application 115 resident on the user device 110 and accessible by the device user to interact securely with certain functions within the secure element, while protecting information stored within the secure element.
  • the secure element may comprise one or more applications 115 running thereon that perform the functionality described herein.
  • the controller 116 is a Bluetooth link controller.
  • the Bluetooth link controller 116 may be capable of sending and receiving data, identifying the merchant device 120, performing authentication and ciphering functions, and directing how the user device 110 will listen for transmissions from the merchant device or configure the user device 110 into various power-save modes according to the Bluetooth-specified procedures.
  • the controller 116 is a Wi-Fi controller or an NFC controller capable of performing similar functions.
  • An example user device 110 comprises one or more keys and/or certificates.
  • the user device 110 generates a withdrawal record for an amount indicated on the payment request received from the merchant device 120.
  • the user device 110 signs the withdrawal record with an account certificate private key 112 and transmits the signed withdrawal record with the balance certificate 113 to the merchant device 120.
  • the data storage unit 119 may be implemented in a secure element or other secure memory (not shown) on the user device 110 or may be a separate memory unit resident on the user device 110.
  • An example data storage unit 119 enables storage of signed withdrawal records until the user device 110 has network 140 access and can communicate the signed withdrawal records to the account management system 130.
  • the data storage unit 119 can include any local or remote data storage structure accessible to the user device 110 suitable for storing information.
  • the data storage unit 119 stores encrypted information, such as HTML5 local storage.
  • the user device 110 may connect to network 140 via a wired connection.
  • the connection may be a wired universal serial bus (USB) or Ethernet connection.
  • the user device 110 may connect to the network via a wireless connection.
  • the connection may be a Wi-Fi or Bluetooth connection to a hotspot that has a wired/wireless Internet connection (for example, MiFi), or any other wired or wireless connection suitable for communicating signals with network 140.
  • the connection may be a cellular network connection.
  • An example user device 110 and merchant device 120 communicate with the account management system 130.
  • An example account management system 130 comprises an account management module 131 and a data storage unit 137.
  • An example account management module 131 maintains an account for the user.
  • the account comprises information for one or more financial accounts maintained by one or more financial institutions.
  • the financial account information is saved in the data storage unit 137.
  • the account management system 130 stores the user's financial transactions made using the user's account management system 130 account. For example, each deposit of funds and each withdrawal of funds for each account in the data storage unit 137.
  • the account management system 130 analyzes the transaction history to identify missing data or possible errors.
  • An example account management system 130 comprises one or more keys and/or certificates.
  • the account management system 130 comprises the account certificate public key 112a and can verify the identity of the user device 110 and/or user's account management system 130 account using the account certificate public key 112a.
  • the account management system 130 accesses the user's account management system 130 account and creates the balance certificate 113.
  • the account management system 130 signs the balance certificate 113 with a balance certificate private key 113 and transmits the balance certificate 113 to the user device 110.
  • the merchant device 120 comprises the balance certificate public key 113a and confirms that the balance certificate 113 was signed by the account management system 130 as part of the verification process.
  • the account management system 130 also comprises a merchant device signing certificate public key 124a.
  • the account management system 130 verifies the withdrawal record signed by the merchant device signing certificate 124 using the merchant device signing certificate public key 124a to confirm the identity of the merchant device 120.
  • the account management system 130 accesses the user's account management system 130 account and saves the signed withdrawal records in the data storage unit 137.
  • the data storage unit 137 can include any local or remote data storage structure accessible to the account management system 130 suitable for storing information.
  • the data storage unit 137 stores encrypted information, such as HTML5 local storage.
  • Figure 2 is a block flow diagram depicting a method 200 for processing an offline payment transaction, in accordance with certain example embodiments. The method 200 is described with reference to the components illustrated in Figure 1.
  • the user enables an application 115 on the user device 110 and/or indicates a desire to perform an offline financial transaction.
  • the user enables the application 115 to allow the user device 110 to communicate with the account management system 130 and perform an offline payment transaction with the merchant device 120.
  • user device 110 receives an up-to-date balance certificate from the account management system 130.
  • the method 220 for receiving the up-to-date balance certificate from the account management system 130 is described in more detail hereinafter with reference to the methods described in Figure 3.
  • Figure 3 is a block flow diagram depicting a method 220 for receiving an up- to-date balance certificate from an account management system 130, in accordance with certain example embodiments, as referenced in block 220.
  • the method 220 is described with reference to the components illustrated in Figure 1.
  • the user device 110 requests an up-to-date balance certificate
  • the request comprises an authorization to deposit of fund to the user's account management system 130 account.
  • the user authorizes the deposit by authorizing a transfer of funds from a financial account to the user's account management system 130 account.
  • the user device 110 requests a lock of available funds.
  • the user device 110 requests an unlock of available funds.
  • an up-to-date balance certificate 113 is requested during any communication between the user device 110 and the account management system 130.
  • the user device 120 receives the request and determines whether the user device 120 has network 140 access.
  • network 140 access is required to communicate with the account management system 130.
  • the user device 120 determines whether there is network 140 access by trying to establish a communication channel with the account management system 130.
  • the method 220 proceeds to block 325.
  • the user device 120 retries establishing a communication channel with the account management system 130 when the device 120 has network 140 access.
  • the method 220 proceeds to block 330.
  • the user device 120 establishes a communication channel with the account management system 130.
  • the communication channel is established via the network 140.
  • the account management system 130 determines whether the user has an account maintained by, or accessible to, the account management system 130. In an example embodiment, the account management system 130 receives notification that the user has enabled the application 115 on the user devices 110 and determines whether the user has an account management system 130 account. In an example embodiment, the user is prompted to log into or create an account management system 130 account when the application 115 is enabled. In another example embodiment, the user previously logged into the account management system 130 account and is otherwise automatically logged into the account. In yet another example embodiment, the user's login credentials are shared across other accounts (for example, social networking websites and user device 120 accounts) and the user is automatically logged into the account management system 130 account using the shared login credentials.
  • the method 220 proceeds to block 345 in Figure 3.
  • the user is prompted to create an account management system 130 account.
  • the user is prompted to register with the account management system 130 when the user enables the application 115.
  • the user may create the account management system 130 account at any time prior to, after, or while enabling the application 115.
  • the user accesses the account management system 130 via the application 115 and the network 140.
  • the user submits registration information to the account management system 130, including, but not limited to, name, address, phone number, e-mail address, and information for one or more registered financial card accounts, including bank account debit cards, credit cards, a loyalty rewards account card, or other type of account that can be used to make a purchase (for example, card type, card number, expiration date, security code, and billing address).
  • the user's account management system 130 account information is saved in the data storage unit 137 and is accessible to the account management module 131.
  • the account management system 130 account is a digital wallet account maintained by the account management system 130 or a third party system.
  • the user may use a website to register with the account management system 130.
  • the user is not required to log in or register for the account management system 130 account. In this embodiment, the methods described herein are performed for a "guest" user.
  • the account management system 130 creates an account certificate.
  • the account certificate 112 comprises an identity of the user and/or user device 110 that corresponds to the user's account management system 130 account.
  • the account certificate 112 is maintained by the user device 110 and/or account management system 130.
  • the account certificate 112 functions to sign a withdrawal record created by the user device 110 in response to an offline payment request received from a merchant device 120.
  • the account certificate 112 comprises an account certificate public key 112a.
  • the account certificate public key 112a functions to verify the authenticity of the withdrawal record signed by the account certificate 112.
  • the account certificate public key 112a is maintained by the merchant device 120 and/or the account management system 130.
  • the account certificate public key 112a is transmitted by the account management system 130 to the merchant device 120 when the merchant device 120 is registered or at any time thereafter.
  • the account management system 130 transmits the account certificate 112 to the user device 110.
  • any communication between the user device 110 and the account management system 130 is signed by the account certificate 112.
  • the account management system 130 identifies the user's account management system 130 account by reading the signature.
  • the user device 110 receives the account certificate 112.
  • the account management system 130 determines whether the request for an up-to-date balance certificate 113 comprises an authorization to deposit of fund to the user's account management system 130 account.
  • the user authorizes the deposit by authorizing a transfer of funds from a financial account to the user's account management system 130 account.
  • the user performs the authorization using the user device 110.
  • the user accesses the application 115 to requests a deposit of funds.
  • the user performs the authorization using another computing device or a third party system that can communicate with the account management system 130.
  • the user device 120 will request an up-to-date balance certificate at a time when the device 120 has network access.
  • the method 220 proceeds to block 380 in Figure 3.
  • the account management system 130 processed the deposit of funds into the user's account.
  • funds are electronically transferred from a financial account to the user's account management system 130 account.
  • the method 220 proceeds to block 390 in Figure 3.
  • the account management system 130 provides a signed balance certificate 113 to the user device 110.
  • the method 390 for providing a signed balance certificate 113 to the user device 110 is described in more detail hereinafter with reference to the methods described in Figure 4.
  • Figure 4 is a block flow diagram depicting a method 390 for providing a signed balance certificate 113 to the user device 110, in accordance with certain example embodiments, as referenced in block 390. The method 390 is described with reference to the components illustrated in Figure 1.
  • the account management system 130 determines whether the request for an up-to-date balance certificate 113 comprises a withdrawal record.
  • the user device 110 transmits one or more withdrawal records to the account management system 130 with the request for an up-to-date balance certificate 113.
  • the user device 110 transmits all withdrawal records to the account management system.
  • the user device 110 determines which withdrawal records have not yet been sent and transmits those records to the account management system 130.
  • each withdrawal record comprises an identification of an offline payment transaction that took place with a merchant device 120.
  • the account management system 130 saves each withdrawal record in the user's account management system 130 account and uses the records to determine an available balance of funds.
  • each withdrawal record is signed by a merchant device 120 during the offline payment transaction.
  • the merchant device 120 signs the withdrawal record using the merchant device signing certificate 124.
  • the withdrawal record is signed by the merchant device signing certificate 124 to authenticate the record.
  • the account management system 130 can verify the withdrawal record using the merchant device signing certificate public key 124a.
  • the signed withdrawal record verifies that the offline payment transaction occurred between the user device 110 and the merchant device 120.
  • the method 390 proceeds to block 430 in Figure 4.
  • the transaction is rejected and the account management system 130 transmits a notice to the user device 120.
  • the method 390 proceeds to block 440 in Figure 4.
  • the account management system 130 records the withdrawal record in the user's account management system 130 account.
  • the account management system 130 updates the user's account to note the offline payment transaction.
  • the method 390 proceeds to block 450 in Figure 4.
  • the account management system 130 calculates a balance of available funds in the user's account management system 130 account.
  • the method 450 for calculating a balance of available funds in the user's account management system 130 account is described in more detail hereinafter with reference to the methods described in Figure 5.
  • Figure 5 is a block flow diagram depicting a method 450 for calculating a balance of available funds in the user's account management system 130 account, in accordance with certain example embodiments, as referenced in block 450.
  • the method 450 is described with reference to the components illustrated in Figure 1.
  • the account management system 130 calculates a balance of funds in the user's account management system 130 account. In an example embodiment, the account management system 130 calculates a difference between the total amount of deposits and the total amount of the withdrawal records. In another example embodiment, the account management system 130 maintains a running total of the balance of funds in the user's account.
  • the account management system 130 determines whether a portion of the balance of funds is locked.
  • the user transmits a request to lock a portion of the balance of funds with the request for an up-to-date balance certificate 113.
  • the account management system 130 maintains rules or logic understood without human intervention that determine an amount of the locked funds.
  • the user defines the rules for determining the amount of locked funds. For example, a rule may require a $25 minimum balance is maintained in the user's account management system 130 account. In this example, the account management system 130 would lock $25 to prevent this minimum amount from being available for an offline payment.
  • a rule may require that 5% of the funds available in the user's account management system 130 account are locked. In this example, if the user had $100 in the user's account, the account management system 130 would lock $5 to prevent this minimum amount from being available for an offline payment.
  • the account management system 130 determines the rules for locking or unlocking a portion of the balance of funds.
  • the rules are defined by the user, the account management system, a third party, or any combination thereof.
  • the rules are defined when the user's account management system 130 account is established.
  • the rules are established and are subject to change at any time after being established.
  • the user's request for an up-to-date balance certificate 113 comprises one or more rules for locking or unlocking funds.
  • all the funds in the user's account management system 130 account are locked and the account management system 130 determines whether a portion of the balance of funds may be unlocked based on the rules. For example, the account management system 130 determines that 50% of the balance of funds can be made available for an offline payment transaction by applying one or more rules.
  • the account management system 130 determines whether there is a time -based rule for locking or unlocking a portion of the balance of funds.
  • a portion of the balance of funds is available for a limited time.
  • a portion of the balance of funds may be unlocked for a single transaction.
  • the balance certificate 113 is valid for only a single transaction or for only a short amount of time (for example, long enough to only complete one offline transaction). After a single offline payment transaction is completed, or after the expiration of the time available for the balance certificate 113, the user is required to request a new up-to-date balance certificate 113.
  • a portion of the available funds may be locked for a period of time. For example, a portion of balance of funds is locked for five minutes.
  • the user can complete an offline payment transaction during those five minutes with an amount of available funds up to the locked amount. After the transaction is completed, the lock is removed. The user can extend the locking time before those five minutes expire by requesting a new balance certificate 113.
  • the method 450 proceeds to block 550 in Figure 5.
  • the account management system 130 determines the available funds for the pre-defined time period.
  • the method 450 proceeds to block 560 in Figure 5.
  • the account management system 130 determines whether there is a location-based rule for locking or unlocking a portion of the balance of funds.
  • funds are only available for use in a specified location or for an offline payment transaction with a specified type of merchant. For example, the user only wishes to use funds for mass transit, at restaurants, or in City X.
  • funds are only available for use within a predefined proximity of a first offline payment transaction or other geographic location.
  • each user may have more than one user device 110.
  • each user device 110 can have a different balance certificate. By locking a portion of the balance of funds according to location, the user cannot use more than one user device 110 to over spend the user's balance of funds.
  • the method 450 proceeds to block 570 in Figure 5.
  • the account management system 130 determines the available funds for the pre-defined location or merchant type.
  • the method 450 then proceeds to block 580 in Figure 5.
  • the account management system 130 determines there is not a location-based rule for locking or unlocking a portion of the balance of funds, the method 450 proceeds to block 580 in Figure 5.
  • account management system 130 determines an amount of locked funds not available for an offline payment transaction and an amount of funds available for an offline payment transaction based on the one or more rules for locking funds.
  • the amount of available funds comprises a difference between the total amount of deposits and the total amount of the withdrawal records minus any locked funds.
  • the account management system 130 creates an up-to-date balance certificate 113 for the user device 110.
  • the up-to-date balance certificate 113 comprises the amount of funds available for an offline payment transaction.
  • the balance certificate 113 is limited in time. In this example embodiment, the balance certificate 113 expires after a predefined amount of time passes. In another example embodiment, the balance certificate 113 is limited in a number of offline purchase transactions. In this example embodiment, the balance certificate 113 expires after the pre-defined number of offline purchase transaction are completed. In another example embodiment, the balance certificate 113 is limited by time, number of transactions, geographic location, type of merchant, or any other limiting rule established by the account management system 130 or the user. In an example embodiment, the balance certificate comprises one or more rules limiting the amount of funds available for the payment transaction.
  • the account management system 130 signs the balance certificate 113.
  • the merchant device 120 can read the signed balance certificate 113 using the balance certificate public key 113a to verify the authenticity of the signed balance certificate 113.
  • the account management system 130 transmits the signed balance certificate 113 to the user device 110.
  • the signed balance certificate 113 is transmitted via the network 140 connection to the user device 110.
  • the user device 110 receives the signed balance certificate 113.
  • the user has indicated a desire to complete an offline payment transaction with the merchant.
  • the user accesses an application 115 on the user device 110 that enables the user device 110 to perform an offline payment transaction.
  • the user accesses an application 115 that enables the user device 110 to wirelessly communicate with the merchant device 120.
  • the devices including devices 110 and 120) communicate via a secure communication channel (for example, near field communications, Bluetooth, Wi-Fi, or other form of wireless communication channel).
  • the merchant device 120 transmits a payment request to the user device 110.
  • the merchant enters a payment request amount into an application 125 on the merchant device 120.
  • the payment request comprises an identification of the merchant device 120, a payment request amount, and/or a timestamp.
  • the payment request is transmitted via the secure communication channel.
  • the user device 110 processes the payment request received from the merchant device 120.
  • the method 250 for processing a payment request received from a merchant device 120 is described in more detail hereinafter with reference to the methods described in Figure 6.
  • Figure 6 is a block flow diagram depicting a method 250 for processing a payment request received from a merchant device 120, in accordance with certain example embodiments, as referenced in block 250. The method 250 is described with reference to the components illustrated in Figure 1.
  • the user device 110 receives the payment request from the merchant device 120.
  • the user device 110 generates a withdrawal record for an amount indicated on the payment request received from the merchant device 120.
  • the withdrawal record comprises information received in the payment request (for example, an identification of the merchant or merchant device 120, a payment request amount, and a timestamp).
  • the withdrawal record comprises an identification of the user device 110, an identification of the user, and/or an identification of the user's account management system 130 account.
  • the user may change the payment request amount using the application 115 prior to or while the withdrawal record is created.
  • the user device 110 signs the withdrawal record.
  • the withdrawal record is signed with the account certificate 112 private key.
  • withdrawal record is signed by the user device 110 or application 115 to allow the merchant device 120 to verify that the account information (for example, the account management system 130 account) belongs to the user and is authorized for use in the offline payment transaction.
  • the user device 110 retrieves the up-to-date balance certificate
  • the balance certificate 113 is retrieved at any time after the payment request is received from the merchant device 120.
  • the user device 120 confirms the availability of funds for the offline payment transaction by cross-referencing the payment request amount with the amount of funds available for an offline payment transaction disclosed by the balance certificate 113.
  • the user device 120 confirms the availability of funds for the offline payment transaction by cross-referencing the payment request amount with the amount of funds available for an offline payment transaction disclosed by the balance certificate 113.
  • the user device 110 transmits a response to the payment request to the merchant device 120.
  • the response comprises the signed withdrawal record and the signed balance certificate 113.
  • the response to the payment request is transmitted via the secure communication channel between the user device 110 and the merchant device 120.
  • the merchant device 120 verifies the response to the payment request received from the user device 110.
  • the method 260 for verifying the response to the payment request received from the user device 110 is described in more detail hereinafter with reference to the methods described in Figure 7.
  • Figure 7 is a block flow diagram depicting a method 260 for verifying the response to the payment request received from the user device 110, in accordance with certain example embodiments, as referenced in block 260.
  • the method 260 is described with reference to the components illustrated in Figure 1.
  • the merchant device 120 receives the response to the payment request from the user device 110.
  • the response comprises the signed withdrawal record and the signed balance certificate 113.
  • the merchant device 120 verifies the withdrawal record.
  • the merchant device 120 verifies the signed withdrawal record using an account certificate public key 112a.
  • the withdrawal record was signed by the account certificate 112 on the user device 110 prior to transmission to the merchant device 120.
  • the merchant device 120 verifies the signature on withdrawal record to confirm the identity of the user device 110, the user, and/or the user's account management system 130 account.
  • the method 260 proceeds to block 730 in Figure 7.
  • the offline payment transaction is rejected.
  • the merchant device 120 transmits a notification of the rejected transaction to the user device 110.
  • the method 260 proceeds to block 740 in Figure 7.
  • the merchant device 120 verifies the balance certificate 113.
  • the merchant device 120 verifies the signed balance certificate 113 using a balance certificate public key 113a.
  • the balance certificate 113 was signed by the account management system 130 prior to transmission to the user device 110.
  • the signed balance certificate 113 was transmitted to the merchant device 120 with the withdrawal record in response to the payment request.
  • the merchant device 120 verifies the signature on the balance certificate 113 to confirm the availability of the funds to complete the offline payment transaction.
  • the merchant device 120 verifies that the balance certificate 113 is not expired and/or that any other limitations placed on the balance certificate (for example, geographic limitations, merchant limitations, or other functional limitations) are met.
  • the offline payment transaction is rejected.
  • the merchant device 120 transmits a notification of the rejected transaction to the user device 110.
  • the method 260 proceeds to block 760 in Figure 7.
  • the merchant device 120 verifies the availability of funds to complete the offline payment transaction.
  • the merchant device 120 reads the available funds from the balance certificate 113.
  • the merchant device 120 verifies the offline payment transaction complies with any rules placed on the available funds.
  • the method 260 proceeds to block 770 in Figure 7.
  • the merchant device 120 and/or user device 110 determine whether a portion of the balance of funds are locked or otherwise unavailable for use during the offline payment transaction.
  • the balance certificate 113 comprises a notation that a portion of the funds are locked.
  • the method 260 proceeds to block 775 in Figure 7.
  • the offline payment transaction is rejected.
  • the merchant device 120 transmits a notification of the rejected transaction to the user device 110.
  • block 780 the user authorizes a request to the account management system 130 to unlock a portion of the funds.
  • a request to unlock funds is transmitted to the account management system 130 only when the user device 110 has a network 140 connection. In this embodiment, the transaction is rejected until additional funds are unlocked.
  • the method 260 then proceeds to block 310 in Figure 3 and the user device
  • the method 260 proceeds to block 790 in Figure 7.
  • the merchant device 120 authorizes the offline payment transaction.
  • the account management system 130 verifies the withdrawal record.
  • the method 270 for verifying the withdrawal record is described in more detail hereinafter with reference to the methods described in Figure 8.
  • Figure 8 is a block flow diagram depicting a method 270 for verifying the withdrawal record, in accordance with certain example embodiments, as referenced in block 270.
  • the method 270 is described with reference to the components illustrated in Figure 1.
  • the merchant device 120 signs the withdrawal record with the merchant device signing certificate 124.
  • the merchant device 120 authorized the offline payment transaction after it verified the withdrawal record, verified the balance certificate 113, and determined that there are sufficient funds for the offline payment transaction.
  • the merchant device 120 signs the withdrawal record to authorize the transaction.
  • the merchant device 120 creates a status code or message that indicates to the user device 110 that the transaction was successful.
  • the merchant device 120 transmits the signed withdrawal record to the user device 110.
  • the signed withdrawal record is transmitted via the secure communication channel between the user device 110 and the merchant device 120.
  • transmission of the signed withdrawal record to the user device 110 completes the offline payment transaction.
  • the merchant device 120 transmits a status code or message to the user device 110 indicating that the transaction was successful.
  • the merchant device 120 determines whether it has network 140 access. In an example embodiment, the merchant device 120 requires network 140 access to communicate with the account management system 130.
  • the method 270 proceeds to block 830 in Figure 8.
  • the merchant device 120 stores the withdrawal record until it has network 140 access.
  • the method 270 proceeds to block 840 in Figure 8.
  • the merchant device 120 transmits the withdrawal record to the account management system 130.
  • the withdrawal record is signed by the merchant device signing certificate 124.
  • the withdrawal record is the same withdrawal record received from the user device 110 in response to the payment request.
  • the account management system 130 receives the withdrawal record from the merchant device 120.
  • the account management system 130 verifies the withdrawal record.
  • the account management system 130 verifies the withdrawal record using the merchant device signing certificate public key 124a.
  • the account management system 130 verifies the identity or validity of the withdrawal record and/or the merchant device 120.
  • the merchant device 120 transmits an identifier or message with the withdrawal record.
  • the account management system 130 verifies the withdrawal record by confirming the identity of the merchant device 120.
  • the account management system 130 verifies the withdrawal record by verifying the identity of the user or user device 110.
  • the offline payment transaction is rejected.
  • the account management system 130 transmits a notification of the rejected transaction to the merchant device 120.
  • the method 270 proceeds to block 880 in Figure 8.
  • the account management system 130 records the withdrawal record in the user's account management system 130 account.
  • the withdrawal record comprises an identification of the user, user device 110, and/or user's account management system 130 account.
  • the account management system 130 updates the user's account with the withdrawal record received from the merchant device 120.
  • the user device 110 requests a new balance certificate 113 prior to or after the merchant device 120 transmits the withdrawal record to the account management system 130.
  • the user device 110 transmits the signed withdrawal record to the account management system 130.
  • the account management system 130 records the two withdrawal records received for the same offline payment transaction in the user's account management system 130 account.
  • the two withdrawal records are used to verify the validity of the balance of funds in the user's account.
  • FIG. 9 depicts a computing machine 2000 and a module 2050 in accordance with certain example embodiments.
  • the computing machine 2000 may correspond to any of the various computers, servers, mobile devices, embedded systems, or computing systems presented herein.
  • the module 2050 may comprise one or more hardware or software elements configured to facilitate the computing machine 2000 in performing the various methods and processing functions presented herein.
  • the computing machine 2000 may include various internal or attached components such as a processor 2010, system bus 2020, system memory 2030, storage media 2040, input/output interface 2060, and a network interface 2070 for communicating with a network 2080.
  • the computing machine 2000 may be implemented as a conventional computer system, an embedded controller, a laptop, a server, a mobile device, a smartphone, a set-top box, a kiosk, a vehicular information system, one more processors associated with a television, a customized machine, any other hardware platform, or any combination or multiplicity thereof.
  • the computing machine 2000 may be a distributed system configured to function using multiple computing machines interconnected via a data network or bus system.
  • the processor 2010 may be configured to execute code or instructions to perform the operations and functionality described herein, manage request flow and address mappings, and to perform calculations and generate commands.
  • the processor 2010 may be configured to monitor and control the operation of the components in the computing machine 2000.
  • the processor 2010 may be a general purpose processor, a processor core, a multiprocessor, a reconfigurable processor, a microcontroller, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a graphics processing unit (GPU), a field programmable gate array (FPGA), a programmable logic device (PLD), a controller, a state machine, gated logic, discrete hardware components, any other processing unit, or any combination or multiplicity thereof.
  • DSP digital signal processor
  • ASIC application specific integrated circuit
  • GPU graphics processing unit
  • FPGA field programmable gate array
  • PLD programmable logic device
  • the processor 2010 may be a single processing unit, multiple processing units, a single processing core, multiple processing cores, special purpose processing cores, co-processors, or any combination thereof. According to certain embodiments, the processor 2010 along with other components of the computing machine 2000 may be a virtualized computing machine executing within one or more other computing machines.
  • the system memory 2030 may include non- volatile memories such as read-only memory (ROM), programmable read-only memory (PROM), erasable programmable readonly memory (EPROM), flash memory, or any other device capable of storing program instructions or data with or without applied power.
  • the system memory 2030 may also include volatile memories such as random access memory (RAM), static random access memory (SRAM), dynamic random access memory (DRAM), and synchronous dynamic random access memory (SDRAM). Other types of RAM also may be used to implement the system memory 2030.
  • RAM random access memory
  • SRAM static random access memory
  • DRAM dynamic random access memory
  • SDRAM synchronous dynamic random access memory
  • Other types of RAM also may be used to implement the system memory 2030.
  • the system memory 2030 may be implemented using a single memory module or multiple memory modules.
  • system memory 2030 is depicted as being part of the computing machine 2000, one skilled in the art will recognize that the system memory 2030 may be separate from the computing machine 2000 without departing from the scope of the subject technology. It should also be appreciated that the system memory 2030 may include, or operate in conjunction with, a non-volatile storage device such as the storage media 2040.
  • the storage media 2040 may include a hard disk, a floppy disk, a compact disc read only memory (CD-ROM), a digital versatile disc (DVD), a Blu-ray disc, a magnetic tape, a flash memory, other non-volatile memory device, a solid state drive (SSD), any magnetic storage device, any optical storage device, any electrical storage device, any semiconductor storage device, any physical-based storage device, any other data storage device, or any combination or multiplicity thereof.
  • the storage media 2040 may store one or more operating systems, application programs and program modules such as module 2050, data, or any other information.
  • the storage media 2040 may be part of, or connected to, the computing machine 2000.
  • the storage media 2040 may also be part of one or more other computing machines that are in communication with the computing machine 2000 such as servers, database servers, cloud storage, network attached storage, and so forth.
  • the module 2050 may comprise one or more hardware or software elements configured to facilitate the computing machine 2000 with performing the various methods and processing functions presented herein.
  • the module 2050 may include one or more sequences of instructions stored as software or firmware in association with the system memory 2030, the storage media 2040, or both.
  • the storage media 2040 may therefore represent examples of machine or computer readable media on which instructions or code may be stored for execution by the processor 2010.
  • Machine or computer readable media may generally refer to any medium or media used to provide instructions to the processor 2010.
  • Such machine or computer readable media associated with the module 2050 may comprise a computer software product.
  • a computer software product comprising the module 2050 may also be associated with one or more processes or methods for delivering the module 2050 to the computing machine 2000 via the network 2080, any signal-bearing medium, or any other communication or delivery technology.
  • the module 2050 may also comprise hardware circuits or information for configuring hardware circuits such as microcode or configuration information for an FPGA or other PLD.
  • the input/output (I/O) interface 2060 may be configured to couple to one or more external devices, to receive data from the one or more external devices, and to send data to the one or more external devices. Such external devices along with the various internal devices may also be known as peripheral devices.
  • the I/O interface 2060 may include both electrical and physical connections for operably coupling the various peripheral devices to the computing machine 2000 or the processor 2010.
  • the I/O interface 2060 may be configured to communicate data, addresses, and control signals between the peripheral devices, the computing machine 2000, or the processor 2010.
  • the I/O interface 2060 may be configured to implement any standard interface, such as small computer system interface (SCSI), serial-attached SCSI (SAS), fiber channel, peripheral component interconnect (PCI), PCI express (PCIe), serial bus, parallel bus, advanced technology attached (ATA), serial ATA (SATA), universal serial bus (USB), Thunderbolt, FireWire, various video buses, and the like.
  • the I/O interface 2060 may be configured to implement only one interface or bus technology. Alternatively, the I/O interface 2060 may be configured to implement multiple interfaces or bus technologies.
  • the I/O interface 2060 may be configured as part of, all of, or to operate in conjunction with, the system bus 2020.
  • the I/O interface 2060 may include one or more buffers for buffering transmissions between one or more external devices, internal devices, the computing machine 2000, or the processor 2010.
  • the I/O interface 2060 may couple the computing machine 2000 to various input devices including mice, touch-screens, scanners, electronic digitizers, sensors, receivers, touchpads, trackballs, cameras, microphones, keyboards, any other pointing devices, or any combinations thereof.
  • the I/O interface 2060 may couple the computing machine 2000 to various output devices including video displays, speakers, printers, projectors, tactile feedback devices, automation control, robotic components, actuators, motors, fans, solenoids, valves, pumps, transmitters, signal emitters, lights, and so forth.
  • the computing machine 2000 may operate in a networked environment using logical connections through the network interface 2070 to one or more other systems or computing machines across the network 2080.
  • the network 2080 may include wide area networks (WAN), local area networks (LAN), intranets, the Internet, wireless access networks, wired networks, mobile networks, telephone networks, optical networks, or combinations thereof.
  • the network 2080 may be packet switched, circuit switched, of any topology, and may use any communication protocol. Communication links within the network 2080 may involve various digital or an analog communication media such as fiber optic cables, free-space optics, waveguides, electrical conductors, wireless links, antennas, radio-frequency communications, and so forth.
  • the processor 2010 may be connected to the other elements of the computing machine 2000 or the various peripherals discussed herein through the system bus 2020. It should be appreciated that the system bus 2020 may be within the processor 2010, outside the processor 2010, or both. According to some embodiments, any of the processor 2010, the other elements of the computing machine 2000, or the various peripherals discussed herein may be integrated into a single device such as a system on chip (SOC), system on package (SOP), or ASIC device.
  • SOC system on chip
  • SOP system on package
  • ASIC application specific integrated circuit
  • the users may be provided with an opportunity or option to control whether programs or features collect user information (e.g., information about a user's social network, social actions or activities, profession, a user's preferences, or a user's current location), or to control whether and/or how to receive content from the content server that may be more relevant to the user.
  • user information e.g., information about a user's social network, social actions or activities, profession, a user's preferences, or a user's current location
  • certain data may be treated in one or more ways before it is stored or used, so that personally identifiable information is removed.
  • a user's identity may be treated so that no personally identifiable information can be determined for the user, or a user's geographic location may be generalized where location information is obtained (such as to a city, ZIP code, or state level), so that a particular location of a user cannot be determined.
  • location information such as to a city, ZIP code, or state level
  • the user may have control over how information is collected about the user and used by a content server.
  • Embodiments may comprise a computer program that embodies the functions described and illustrated herein, wherein the computer program is implemented in a computer system that comprises instructions stored in a machine -readable medium and a processor that executes the instructions.
  • the embodiments should not be construed as limited to any one set of computer program instructions.
  • a skilled programmer would be able to write such a computer program to implement an embodiment of the disclosed embodiments based on the appended flow charts and associated description in the application text. Therefore, disclosure of a particular set of program code instructions is not considered necessary for an adequate understanding of how to make and use embodiments.
  • the example embodiments described herein can be used with computer hardware and software that perform the methods and processing functions described herein.
  • the systems, methods, and procedures described herein can be embodied in a programmable computer, computer-executable software, or digital circuitry.
  • the software can be stored on computer-readable media.
  • computer-readable media can include a floppy disk, RAM, ROM, hard disk, removable media, flash memory, memory stick, optical media, magneto-optical media, CD-ROM, etc.
  • Digital circuitry can include integrated circuits, gate arrays, building block logic, field programmable gate arrays (FPGA), etc.

Abstract

L'invention concerne un procédé pour permettre des paiements hors ligne sécurisés, lequel procédé comprend un système de compte qui communique un certificat de solde signé à un dispositif d'utilisateur. Le système accède au compte de l'utilisateur, détermine les fonds non verrouillés disponibles, crée et signe un certificat de solde, et transmet le certificat de solde signé au dispositif d'utilisateur. Pour achever une transaction de paiement hors ligne, le dispositif d'utilisateur et un dispositif de commerçant établissent un canal de communication. Le dispositif de commerçant transmet une requête de paiement au dispositif d'utilisateur. Un enregistrement de retrait signé et le certificat de solde signé sont transmis au dispositif de commerçant pour la vérification et l'achèvement de la transaction de paiement hors ligne. Le dispositif de commerçant signe l'enregistrement de retrait, le transmet au dispositif d'utilisateur, et le sauvegarde jusqu'à ce que le dispositif de commerçant ait un accès au réseau et puisse le transmettre au système. Le système vérifie l'enregistrement de retrait et l'enregistre dans le compte de l'utilisateur.
EP15769698.0A 2014-03-26 2015-03-26 Système de paiement hors ligne sécurisé Withdrawn EP3123426A4 (fr)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US14/226,798 US20150278796A1 (en) 2014-03-26 2014-03-26 Reserving account balance for concurrent payments in secure offline payment system
US14/226,785 US20150278795A1 (en) 2014-03-26 2014-03-26 Secure offline payment system
PCT/US2015/022831 WO2015148850A1 (fr) 2014-03-26 2015-03-26 Système de paiement hors ligne sécurisé

Publications (2)

Publication Number Publication Date
EP3123426A1 true EP3123426A1 (fr) 2017-02-01
EP3123426A4 EP3123426A4 (fr) 2017-11-01

Family

ID=54196420

Family Applications (1)

Application Number Title Priority Date Filing Date
EP15769698.0A Withdrawn EP3123426A4 (fr) 2014-03-26 2015-03-26 Système de paiement hors ligne sécurisé

Country Status (7)

Country Link
EP (1) EP3123426A4 (fr)
JP (1) JP2017513122A (fr)
KR (1) KR20160135799A (fr)
CN (1) CN106133769A (fr)
AU (2) AU2015235940A1 (fr)
CA (1) CA2943810A1 (fr)
WO (1) WO2015148850A1 (fr)

Families Citing this family (32)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20230196328A1 (en) * 2013-02-14 2023-06-22 Advanced New Technologies Co., Ltd. Data interaction method and device, and offline credit payment method and device
US10192214B2 (en) 2013-03-11 2019-01-29 Google Llc Pending deposit for payment processing system
WO2017106472A1 (fr) * 2015-12-17 2017-06-22 Mastercard International Incorporated Procédé et système de distribution, utilisation et validation de certificats d'habilitation électroniques
CN106997529B (zh) 2016-01-25 2021-12-24 创新先进技术有限公司 基于移动终端eSE的信用支付方法及装置
CN106997527A (zh) * 2016-01-25 2017-08-01 阿里巴巴集团控股有限公司 基于移动终端p2p的信用支付方法及装置
CN115719224A (zh) 2016-01-25 2023-02-28 创新先进技术有限公司 基于移动终端卡模拟的信用支付方法及装置
US11354658B2 (en) * 2016-02-11 2022-06-07 Mastercard International Incorporated Method and system for offline blockchain exchanges
EP3293686A1 (fr) * 2016-09-07 2018-03-14 Mastercard International, Inc. Procédé et système d'autorisation de transactions entre 2 postes hors ligne au moyen de jetons approvisionnés échangeables
WO2018102263A1 (fr) * 2016-12-02 2018-06-07 Google Llc Interface graphique utilisateur affichant des animations de post-interaction
CN108205755A (zh) * 2016-12-19 2018-06-26 北京握奇智能科技有限公司 一种电子支付系统及方法
CN106790527A (zh) * 2016-12-20 2017-05-31 张峰 账户信息处理方法、系统和终端
CN106875179B (zh) * 2017-02-03 2020-12-08 杭州小步科技有限公司 一种离线二维码支付方法及其系统
WO2018151953A1 (fr) * 2017-02-15 2018-08-23 Mastercard International Incorporated Système et procédé de transaction hors ligne
US20180260795A1 (en) * 2017-03-13 2018-09-13 Mastercard International Incorporated Method and system for accessing locally stored digital funds
CN107665427A (zh) * 2017-08-22 2018-02-06 阿里巴巴集团控股有限公司 一种离线支付、业务处理、支付处理的方法及装置
CN108460593B (zh) * 2017-11-01 2022-09-20 福建博思软件股份有限公司 一种离线二维码支付方法及装置
US10834269B2 (en) 2018-10-02 2020-11-10 International Business Machines Corporation Specialized secondary compartment in a mobile device
US11030610B2 (en) 2018-10-02 2021-06-08 International Business Machines Corporation Preauthorization of mobile payments expected in a reduced-functionality state
SG11202109372WA (en) * 2019-06-10 2021-09-29 Visa Int Service Ass System, method, and computer program product for exchanging transaction data
CN112241879A (zh) * 2019-07-17 2021-01-19 天地融科技股份有限公司 一种基于电子现金的脱机交易方法和系统
CN110610367B (zh) * 2019-08-29 2023-09-05 深圳市元征科技股份有限公司 一种交易数据支付方法及装置、电子设备和服务器
JP6896813B2 (ja) * 2019-08-30 2021-06-30 株式会社日立製作所 トランザクション実行方法およびシステム
JP7075917B2 (ja) * 2019-10-18 2022-05-26 真敬 森下 管理装置、管理プログラム、管理方法、端末装置、及び管理システム
CN110880106A (zh) * 2019-10-30 2020-03-13 支付宝(杭州)信息技术有限公司 双离线支付的实现方法和装置
SE1951426A1 (en) * 2019-12-11 2021-06-12 Trust Anchor Group Ipr Ab Method for performing an offline transaction
WO2021154136A1 (fr) * 2020-01-29 2021-08-05 Crunchfish Digital Cash Ab Procédé, système, dispositifs et produits programmes informatiques permettant de gérer des paiements numériques entre des payeurs et des bénéficiaires se trouvant à proximité physique l'un de l'autre
BR112023016194A2 (pt) * 2021-02-12 2024-03-12 Crunchfish Digital Cash Ab Interoperabilidade de provedor de serviços de pagamento para pagamentos digitais
SE544227C2 (en) * 2021-02-12 2022-03-08 Crunchfish Digital Cash Ab Payment service provider interoperability for offline digital payments
WO2022216216A1 (fr) * 2021-04-08 2022-10-13 Crunchfish Digital Cash Ab Procédé et système de paiements par carte électronique hors ligne
WO2022231471A1 (fr) * 2021-04-28 2022-11-03 Акционерное общество "Национальная система платежных карт" Système et procédé de transfert sans numéraire de pourboires
CN113850579A (zh) * 2021-09-27 2021-12-28 支付宝(杭州)信息技术有限公司 一种离线支付的授权、离线支付、收款方法及装置
FR3130055A1 (fr) * 2021-12-02 2023-06-09 Banks And Acquirers International Holding Procédé de réalisation d’une transaction, dispositifs et programmes correspondants.

Family Cites Families (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5694471A (en) * 1994-08-03 1997-12-02 V-One Corporation Counterfeit-proof identification card
JPH09185658A (ja) * 1995-12-27 1997-07-15 N T T Data Tsushin Kk 電子現金システム
JP4338901B2 (ja) * 2001-01-15 2009-10-07 株式会社エヌ・ティ・ティ・データ 移動体用情報伝達システム及び与信システム
US20030125012A1 (en) * 2001-12-28 2003-07-03 Allen Lee S. Micro-credit certificate for access to services on heterogeneous access networks
JP2004355486A (ja) * 2003-05-30 2004-12-16 Bank Of Tokyo-Mitsubishi Ltd 多機能ｉｃカード及びｉｃカード端末
JP2004362332A (ja) * 2003-06-05 2004-12-24 Bank Of Tokyo-Mitsubishi Ltd Ｉｃカード決済システム
US7912789B2 (en) * 2004-07-22 2011-03-22 Panasonic Corporation Electronic value, electronic purse device, and system for using the same
US20070168260A1 (en) * 2005-09-30 2007-07-19 Mastercard International Incorporated Payment apparatus and method
US8117453B2 (en) * 2005-11-23 2012-02-14 Proton World International N.V. Customization of an electronic circuit
JP4923637B2 (ja) * 2006-03-08 2012-04-25 日本電気株式会社 電子決済システム、電子決済方法、電子決済プログラム及び記録媒体
JP2010026811A (ja) * 2008-07-18 2010-02-04 Fuji Electric Holdings Co Ltd Ｉｃカード・サービスシステム、そのサービス管理センタ、サービス端末、プログラム
US8341084B2 (en) * 2009-06-08 2012-12-25 Mastercard International Incorporated Method, apparatus, and computer program product for topping up prepaid payment cards for offline use
US9911154B2 (en) * 2010-07-08 2018-03-06 Mastercard International Incorporated Apparatus and method for dynamic offline balance management for preauthorized smart cards
US20130103523A1 (en) * 2011-10-24 2013-04-25 Aneto Pablo Okonkwo Transaction storage scheme for offline payment system
US20130185214A1 (en) * 2012-01-12 2013-07-18 Firethorn Mobile Inc. System and Method For Secure Offline Payment Transactions Using A Portable Computing Device
US8898088B2 (en) * 2012-02-29 2014-11-25 Google Inc. In-card access control and monotonic counters for offline payment processing system
JP2013186528A (ja) * 2012-03-06 2013-09-19 Toppan Printing Co Ltd 決済カード管理システム、決済カード管理方法
JP2013186529A (ja) * 2012-03-06 2013-09-19 Toppan Printing Co Ltd 決済カード管理システム、決済カード管理方法

Also Published As

Publication number Publication date
CA2943810A1 (fr) 2015-10-01
AU2018201795A1 (en) 2018-04-05
WO2015148850A1 (fr) 2015-10-01
JP2017513122A (ja) 2017-05-25
CN106133769A (zh) 2016-11-16
EP3123426A4 (fr) 2017-11-01
AU2015235940A1 (en) 2016-09-01
KR20160135799A (ko) 2016-11-28

Similar Documents

Publication Publication Date Title
AU2018201795A1 (en) Secure offline payment system
US20150278795A1 (en) Secure offline payment system
US11374943B2 (en) Secure interface using non-secure element processors
US20150278796A1 (en) Reserving account balance for concurrent payments in secure offline payment system
US20230289777A1 (en) Confirming Physical Possession of Plastic NFC Cards with a Mobile Digital Wallet Application
US11087297B1 (en) Systems and methods for financial operations performed at a contactless ATM
US10192214B2 (en) Pending deposit for payment processing system
US20160371716A1 (en) Loyalty rewards in offline payment system
US20160132875A1 (en) Enhancement of mobile device initiated transactions
US10581814B2 (en) Re-programmable secure device
WO2014210227A1 (fr) Mise à jour de portefeuille numérique depuis un émetteur de compte financier
US20160005023A1 (en) Conducting financial transactions by telephone
US10275766B2 (en) Encrypting financial account numbers such that every decryption attempt results in valid account numbers
WO2020104929A1 (fr) Établissement d'une session partagée entre des entités

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20160922

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
A4 Supplementary search report drawn up and despatched

Effective date: 20170929

RIC1 Information provided on ipc code assigned before grant

Ipc: G06Q 20/20 20120101ALI20170925BHEP

Ipc: G06Q 20/40 20120101ALI20170925BHEP

Ipc: G06Q 20/32 20120101ALI20170925BHEP

Ipc: G06Q 20/10 20120101ALI20170925BHEP

Ipc: G06Q 20/38 20120101AFI20170925BHEP

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: GOOGLE LLC

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20181120

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20190402

P01 Opt-out of the competence of the unified patent court (upc) registered

Effective date: 20230522