WO2020102102A1 - Procédé et système pour des paiements mobiles asynchrones pour de multiples transactions en personne effectuées en parallèle - Google Patents

Procédé et système pour des paiements mobiles asynchrones pour de multiples transactions en personne effectuées en parallèle Download PDF

Info

Publication number
WO2020102102A1
WO2020102102A1 PCT/US2019/060777 US2019060777W WO2020102102A1 WO 2020102102 A1 WO2020102102 A1 WO 2020102102A1 US 2019060777 W US2019060777 W US 2019060777W WO 2020102102 A1 WO2020102102 A1 WO 2020102102A1
Authority
WO
WIPO (PCT)
Prior art keywords
merchant
transaction
information
implementations
server
Prior art date
Application number
PCT/US2019/060777
Other languages
English (en)
Inventor
Paresh K. PATEL
Srinivas Annam
Prashant Kanhere
Rakesh Kulangara
Original Assignee
Payrange, Inc.
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
Application filed by Payrange, Inc. filed Critical Payrange, Inc.
Priority to JP2021524473A priority Critical patent/JP2022506858A/ja
Priority to EP19820916.5A priority patent/EP3881257A1/fr
Priority to US16/681,673 priority patent/US11481780B2/en
Publication of WO2020102102A1 publication Critical patent/WO2020102102A1/fr
Priority to US17/973,506 priority patent/US11966926B2/en

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/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/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • 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/22—Payment schemes or models
    • G06Q20/223—Payment schemes or models based on the use of peer-to-peer networks
    • 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]
    • 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

Definitions

  • the present application relates to the field of payment processing systems, and in particular, to a mobile-device-to-server payment processing system initiated by a short- range mobile-device-to-mobile-device communication.
  • This system is acceptable in traditional retail situations where one consumer is purchasing a good or service and needs the merchant to perform“check out” tasks.
  • the payment transaction is first initiated by the merchant (e.g., requesting a consumer pay a certain amount).
  • the merchant e.g., requesting a consumer pay a certain amount.
  • Implementations described herein provide methods and systems for enabling electronic payments via a mobile device such that multiple consumers can initiate overlapping in-person payments to a single merchant at the same time, or substantially the same time. Moreover, in some implementations, the consumer has the option to send payment to a merchant without the merchant having to request payment first.
  • the performer (or in different contexts, a merchant) is not required to initiate the payment with each consumer and does not need to stop doing what he or she is doing.
  • a plurality of consumers can also pay the performer/merchant without needing to wait for each transaction to finish.
  • the transaction is asynchronous as the performer/merchant need not acknowledge the transaction before the next payment and may not acknowledge the payment at all.
  • a method for performing asynchronous mobile payments at a consumer device includes: identifying a first merchant device in proximity to the consumer device based at least in part on broadcasted information transmitted by the first merchant device, wherein the broadcasted information includes a first identifier
  • the electronic communication includes first merchant identification information of a first merchant associated with the first merchant device, wherein the first merchant identification information includes one or more of a name, logo, picture, address, phone, or email of the first merchant; and first merchant transaction information identifying a proposed in-person transaction between the consumer device and the first merchant, wherein the first merchant transaction information includes a preset transaction amount, an available offer, or an available reward.
  • the method further includes in some implementations displaying on the display of the consumer device the first merchant identification information; receiving from a user of the consumer device selection of the first merchant identification information; and in response to receiving the selection of the first merchant identification information: displaying the first merchant transaction information; receiving from the user of the consumer device first supplemental transaction information, wherein the first supplemental transaction information is a selection of the preset transaction amount, a selection of the available offer, a selection of the available reward, or a freeform payment amount; and transmitting the first supplemental transaction information to the server.
  • the method further includes in some implementations receiving confirmation from the server that the proposed transaction between the consumer device and the first merchant has been completed.
  • a consumer mobile device e.g., the mobile device
  • a display includes one or more processors, and memory storing one or more programs for execution by the one or more processors, the one or more programs include instructions for performing, or controlling performance of, the operations of any of the methods described herein.
  • a non-transitory computer readable storage medium storing one or more programs, the one or more programs comprising instructions, which, when executed by a mobile device (e.g., the consumer mobile device 104, Figures 1 and 13) with one or more processors and a display, cause the computing device to perform, or control performance of, the operations of any of the methods described herein.
  • a consumer mobile device e.g., the mobile device 104, Figures 1 and 13
  • a merchant device (e g , the retail machine 122 or merchant device 1304, Figures 1 and 13) includes a display, one or more processors, and memory storing one or more programs for execution by the one or more processors, the one or more programs include instructions for performing, or controlling performance of, the operations of any of the methods described herein.
  • a non-transitory computer readable storage medium storing one or more programs, the one or more programs comprising instructions, which, when executed by a mobile device (e.g., the merchant device 122 or 1304, Figures 1 and 13) with one or more processors and a display, cause the computing device to perform, or control performance of, the operations of any of the methods described herein.
  • a consumer mobile device (e.g., the merchant device 122 or 1304, Figures 1 and 13) includes means for performing, or controlling performance of, the operations of any of the methods described herein.
  • Figure 1 is a block diagram of a payment processing system in accordance with some implementations.
  • Figure 2 is a block diagram of a mobile device in accordance with some implementations.
  • Figure 3 is a block diagram of a server system in accordance with some implementations.
  • Figure 4 is a schematic block diagram of an automatic retail machine in accordance with some implementations.
  • FIG. 5 is a block diagram of a payment module in accordance with some implementations.
  • Figure 6A is a perspective view of the payment module of Figure 5 (e.g., an in-line dongle adapter) in accordance with some implementations.
  • the payment module of Figure 5 e.g., an in-line dongle adapter
  • Figure 6B is a perspective view taken from the first end of the payment module of Figure 6A in accordance with some implementations.
  • Figure 6C is a perspective view taken from the second end of the payment module of Figure 6A in accordance with some implementations.
  • Figure 7 is a perspective view of the payment module of Figure 6A within the automatic retail machine of Figure 4 in accordance with some implementations.
  • Figure 8 is a schematic flow diagram of a process for initiating a transaction in accordance with some implementations.
  • Figure 9 is a schematic flow diagram of a process for acknowledging a transaction in accordance with some implementations.
  • Figure 10A is a block diagram of an information packet broadcast by the payment module in accordance with some implementations.
  • Figure 10B is a block diagram of an authorization request in accordance with some implementations.
  • Figure IOC is a block diagram of an authorization grant token in accordance with some implementations.
  • Figure 10D is a block diagram of transaction information generated by the payment module in accordance with some implementations.
  • Figures 1 lA-11G illustrate exemplary user interface for displaying promotional offers in accordance with some implementations.
  • Figures 12A-12C illustrate a flowchart diagram of a method of providing and handling promotional offers for an automatic retail machine in accordance with some implementations.
  • Figure 13 is a block diagram of a payment processing system in accordance with some implementations.
  • Figure 14 is a block diagram of a merchant device in accordance with some implementations.
  • Figures 15A-15B are block diagrams of a consumer device in accordance with some implementations.
  • FIGS 16A-16B are block diagrams of a server system in accordance with some implementations.
  • Figure 17 is a block diagram of a payment processing system in accordance with some implementations.
  • Figure 18 is a block diagram of a payment processing system in accordance with some implementations.
  • Figure 19 is a flow diagram of a process for asynchronously processing payments in accordance with some implementations.
  • Figure 20 is a flow diagram of a process for asynchronously processing payments in accordance with some implementations.
  • Figure 21 is a flow diagram of a process for asynchronously processing payments in accordance with some implementations.
  • Figure 22 is a flow diagram of a process for asynchronously processing payments which, in some implementations, is a continuation of any of the processes in Figures 19-21.
  • Figures 23A - 23B, 24, 25A - 25B and 26A - 26B illustrate exemplary user interfaces for processing payments in accordance with some implementations.
  • Figure 1 illustrates a payment processing system 100.
  • Figures 2-5 illustrate example devices within the payment processing system 100.
  • Figures 6A-6C and 7 show various views of the payment module 124 and the automatic retail machine 122.
  • Figure 8 illustrates a schematic flow diagram of a process 800 for initiating a transaction within the payment processing system 100.
  • Figure 9 illustrates a schematic flow diagram of a process 900 for acknowledging a transaction within the payment processing system 100.
  • Figures 10A-10D illustrate data structures associated with initiating and performing transactions within the payment processing system 100.
  • Figures 1 lA-11G illustrate example user interfaces for displaying promotional offers.
  • Figures 12A-12C illustrate a flowchart diagram of a method 1200 of providing and handling promotional offers for an automatic retail machine. The user interfaces in Figures 1 lA-11G are used to illustrate the method in Figures 12A-12C.
  • FIG. 1 is a block diagram of a payment processing system 100 in accordance with some implementations.
  • the payment processing system 100 includes client-side processing 102-1, 102-2 (hereinafter“client-side modules 102”) executed on a mobile device 104-1, 104-2, server-side processing 106 (hereinafter“server-side module 106”) executed on a server system 108 (sometimes also herein referred to as“the server”), and a payment module 124 coupled with an automatic retail machine 122.
  • the client-side module 102 provides client-side functionalities for the payment processing system 100 and communications with both the server-side module 106 and the payment module 124.
  • an application associated with the client-side module 102 provides a user interface to the payment processing system 100 for the mobile device 104.
  • the client-side module 102 communicates with the server-side module 106 via a long-range communication protocol (e.g., GSM, CDMA, Wi-Fi, or the like) through one or more networks 110, and the client-side module 102 communicates with the payment module 124 via a short-range communication protocol (e.g., near-field
  • the server-side module 106 provides server-side functionalities for the payment processing system 100 for any number of client modules 102 each residing on a respective mobile device 104.
  • the payment processing system 100 harnesses the connectivity of the mobile device 104 to communicate with the payment module 124, which has neither a dedicated communication connection nor a long-range communication transceiver. As such, the mobile device 124 acts as a relay between the payment module 124 and the server system 108.
  • the server-side module 106 includes one or more processors 112, a user information database 114, an offers database 116, and an input and output (I/O) interface to one or more clients 118.
  • the I/O interface to one or more clients 118 facilitates the client-facing input and output processing for the server-side module 106.
  • the one or more processors 112 authorize transaction requests, determine promotional offers for a particular mobile device 104, perform transaction accounting, and acknowledge completed transactions.
  • the user information database 114 stores information for each user of the payment processing system 100 (e.g., user ID, account credentials (user name and password), transaction history, account balance, linked credit cards and bank accounts, and/or the like), and the offers database 116 stores promotional offers provided by manufacturers, distributors, retailers, and the like.
  • Examples of the mobile device 104 include, but are not limited to, a handheld computer, a wearable computing device, a personal digital assistant (PDA), a tablet computer, a laptop computer, a desktop computer, a cellular telephone, a smart phone, an enhanced general packet radio service (EGPRS) mobile phone, a media player, a navigation device, a game console, a television, a remote control, a point-of-sale (POS) terminal, vehicle-mounted computer, an eBook reader, or a combination of any two or more of these data processing devices or other data processing devices.
  • PDA personal digital assistant
  • EGPS enhanced general packet radio service
  • POS point-of-sale
  • Examples of the one or more networks 110 include local area networks (LAN) and wide area networks (WAN) such as the Internet.
  • One or more networks 110 are, optionally, implemented using any known network protocol, including various wired or wireless protocols, such as Ethernet, Universal Serial Bus (USB), FIREWIRE, Long Term Evolution (LTE), Global System for Mobile Communications (GSM), Enhanced Data GSM Environment (EDGE), code division multiple access (CDMA), time division multiple access (TDMA), Bluetooth, Wi-Fi, voice over Internet Protocol (VoIP), Wi-MAX, or any other suitable communication protocol.
  • the server system 108 is implemented on one or more standalone data processing apparatuses or a distributed network of computers.
  • the server system 108 also employs various virtual devices and/or services of third party service providers (e.g., third-party cloud service providers) to provide the underlying computing resources and/or infrastructure resources of the server system 108.
  • third party service providers e.g., third-party cloud service providers
  • the server system 108 includes, but is not limited to, a handheld computer, a tablet computer, a laptop computer, a desktop computer, or a combination of any two or more of these data processing devices or other data processing devices.
  • the payment processing system 100 shown in Figure 1 includes both a client- side portion (e.g., the client-side module 102) and a server-side portion (e.g., the server-side module 106).
  • data processing is implemented as a standalone application installed on the mobile device 104.
  • the division of functionalities between the client and server portions of the payment processing system 100 can vary in different implementations.
  • the client-side module 102 is a thin-client that provides only user-facing input and output processing functions, and delegates all other data processing functionalities to a backend server (e.g., the server system 108).
  • FIG. 2 is a block diagram of the mobile device 104 associated with a user in accordance with some implementations.
  • the mobile device 104 typically, includes one or more processing units (CPUs) 202, two or more communication devices 204, memory 206, and one or more communication buses 208 for interconnecting these components (sometimes called a chipset).
  • the two or more communication devices 204 include a first transceiver associated with a short-range communication protocol (e.g., NFC, BLE, or the like) and a second transceiver associated with a long-range communication protocol (e.g., GSM, CDMA,
  • the mobile device 104 also includes a user interface 210.
  • the user interface 210 includes one or more output devices 212 that enable presentation of media content (e.g., text, images, audio, video, etc ), including one or more speakers and/or one or more visual displays.
  • the user interface 210 also includes one or more input devices 214, including user interface components that facilitate user input such as a keyboard, a mouse, a voice-command input unit or microphone, a touch screen display, a touch-sensitive input pad, a gesture capturing camera, or other input buttons or controls.
  • the mobile device 104 uses a microphone and voice recognition or a camera and gesture recognition to supplement or replace the keyboard.
  • the mobile device 104 optionally includes one or more sensors 215, which provide context information as to the current state of the mobile device 104 or the environmental conditions associated with mobile device 104.
  • the one or more sensors 215 include, but are not limited, to one or more microphones, one or more cameras, an ambient light sensor, one or more accelerometers, one or more gyroscopes, a temperature sensor, one or more motion sensors, one or more biometric/biological sensors, and so on.
  • the mobile device 104 optionally includes a location detection device 217, such as a GPS (global positioning satellite) or other geo-location receiver, for determining the location of the mobile device 104.
  • GPS global positioning satellite
  • the memory 206 includes high-speed random access memory, such as
  • DRAM, SRAM, DDR RAM, or other random access solid state memory devices and, optionally, includes non-volatile memory, such as one or more magnetic disk storage devices, one or more optical disk storage devices, one or more flash memory devices, or one or more other non-volatile solid state storage devices.
  • the memory 206 optionally, includes one or more storage devices remotely located from the one or more processing units 202.
  • the memory 206 or alternatively the non-volatile memory within the memory 206, includes a non-transitory computer readable storage medium.
  • the memory 206, or the non-transitory computer readable storage medium of the memory 206 stores the following programs, modules, and data structures, or a subset or superset thereof:
  • operating system 216 including procedures for handling various basic system services and for performing hardware dependent tasks
  • communication module 218 for transmitting signals to and receiving signals from other devices (e.g., the server system 108 and the payment module 124) via the two or more communication devices 204;
  • presentation module 220 for enabling presentation of information (e.g., a user
  • output devices 212 e.g., displays, speakers, etc.
  • input processing module 222 for detecting one or more user inputs or interactions from the one or more input devices 214 and interpreting the detected inputs or interactions;
  • web browser module 224 for navigating, requesting (e.g., via HTTP), and displaying websites and web pages thereof;
  • client-side module 102 which provides client-side data processing and functionalities for the payment processing system 100, including but not limited to:
  • o broadcast obtaining module 230 for receiving, via the first transceiver, an information packet broadcast by a respective payment module 124, where the information packet at least includes a unique identifier corresponding to the respective payment module 124 (i.e., the device ID) and an authorization code for initiating a transaction with an automatic retail machine 122 to which the respective payment module 124 is coupled;
  • o transaction authorization module 232 for: sending, via the second transceiver, a transaction authorization request to the server system 108 including the authorization code; receiving, via the second transceiver, an authorization grant token from the server system 108, including the authorization code, for initiating a transaction with the automatic retail machine 122 to which the respective payment module 124 is coupled; and storing the received authorization grant token (e.g., in the user data 264);
  • o offer(s) module 234 for: obtaining (i.e., receiving or retrieving), via the second transceiver, promotional offers from the server system 108 (e.g., in response to sending the transaction authorization request, as part of an update to the application associated with the client-side module 102, or at another time); storing the promotional offers obtained from the server system in the offers database 266; optionally determining one or more promotional offers based on one or more of a plurality of factors (e.g., the device ID, user ID and history, current location of the mobile device 104, current time/date, and/or the like); presenting one or more promotional offers to the user of the mobile device via the one or more output devices 212 (e.g., a display); and detecting a user input selecting a respective one of the one or more promotional offers presented to the user of the mobile device 104;
  • the server system 108 e.g., in response to sending the transaction authorization request, as part of an update to the application associated with the client-side module 102
  • o trigger detecting module 236 for detecting a trigger to initiate a transaction with the automatic retail machine 122 to which the respective payment module 124 is coupled (e.g., the trigger is a gesture or other user input by the user of the mobile device 104, entrance of the mobile device 104 into a payment zone based on the RSSI observed from the payment module 124, selection of the respective promotional offer, or the like); transaction initiating module 238 for initiating a transaction with the automatic retail machine 122 coupled with the respective payment module 124 by sending, via the first transceiver, the stored authorization grant token to the respective payment module 124;
  • transaction completion notification receiving module 240 for receiving, via the first transceiver, a transaction completion notification from the payment module 124, where the transaction completion notification includes one or more of: transaction status information (e.g., indicating whether the transaction with the automatic retail machine 122 was successful, aborted, or failed); transaction detail information (e.g., the authorization code, the amount of the transaction, the good/product associated with the transaction, the time/date the transaction was completed, transaction error information, and/or the like); and optionally includes other miscellaneous information regarding the respective payment module 124 and/or the automatic retail machine 122 to which the respective payment module 124 is coupled, such as interrupted transaction information, status flags, inventory information, past hard currency transaction information, other cashless transaction information, and/or the like; product code processing module 242 for: providing a prompt to the user of the mobile device 104 via the one or more output devices 212 to obtain a product code for a vended product to validate the respective promotional offer;
  • transaction status information e.g., indicating whether the transaction with
  • the user of the mobile device 104 manually inputs the product code, the user of the mobile device 104 captures an image of the vended product from which the product code is extracted, the user of the mobile device 104 uses a scanner plug-in of the application associated with the client-side module 102 to obtain the product code, or the like); and either validating the product code or sending, via the second transceiver, the obtained product code to the server system 108 for validation;
  • information relaying module 244 for transmitting, via the second transceiver, information from the payment module 124 to the server system 108 (e.g., the transaction status information, the transaction detail information, the other miscellaneous information regarding the respective payment module 124 and/or the automatic retail machine 122 to which the respective payment module 124 is coupled, and/or the like); o offer validation module 246 for: receiving, via the second transceiver, promotion validation information from the server system 108; and presenting the promotion validation information to the user of the mobile device via the one or more output devices 212 (e g., the display);
  • o acknowledgment module 248 for sending, via the first transceiver, acknowledgment information to the payment module 124, where the acknowledgment information acknowledges that the server system 108 received and processed the transaction status information and the transaction detail information;
  • asynchronous payment module 250 which provides consumer-side payment functionalities for the payment processing system 1300, described in more detail with reference to Figure 15A below.
  • client data 260 storing data associated with the payment processing system 100, including, but is not limited to:
  • o user profile 262 storing information for the user of the mobile device 104, including but not limited to: a unique user identifier (i.e., a user ID), login credentials (i.e., user name or handle and password), transaction history, payment data (e.g., account balance, linked credit card or bank information, app credit or gift card balance, billing address, shipping address, etc.), contact information (e g., email address, phone number, etc ), custom parameters for the user (e.g., age, location, hobbies, etc ), identified trends and/or likes/dislikes of the user, and/or the like;
  • a unique user identifier i.e., a user ID
  • login credentials i.e., user name or handle and password
  • transaction history e.g., payment data
  • payment data e.g., account balance, linked credit card or bank information, app credit or gift card balance, billing address, shipping address, etc.
  • contact information e.g., email address, phone number, etc
  • o user data 264 storing transaction history information, authorization grant tokens, and/or the like;
  • o offers database 266 storing promotional offers provided by manufacturers, distributors, retailers, and/or the like.
  • Each of the above identified elements may be stored in one or more of the previously mentioned memory devices, and corresponds to a set of instructions for performing a function described above.
  • the above identified modules or programs i.e., sets of instructions
  • the memory 206 optionally, stores a subset of the modules and data structures identified above.
  • the memory 206 optionally, stores additional modules and data structures not described above.
  • FIG. 3 is a block diagram illustrating the server system 108 in accordance with some implementations.
  • the server system 108 typically, includes one or more processing units (CPUs) 112, one or more communication devices 304 (e.g., including the I/O interface to one or more clients 118), memory 306, and one or more communication buses 308 for interconnecting these components (sometimes called a chipset).
  • the memory 306 includes high-speed random access memory, such as DRAM, SRAM, DDR RAM, or other random access solid state memory devices; and, optionally, includes non-volatile memory, such as one or more magnetic disk storage devices, one or more optical disk storage devices, one or more flash memory devices, or one or more other non-volatile solid state storage devices.
  • the memory 306, optionally, includes one or more storage devices remotely located from the one or more processing units 112.
  • the memory 306, or alternatively the non-volatile memory within the memory 306, includes a non-transitory computer readable storage medium.
  • the memory 306, or the non-transitory computer readable storage medium of the memory 306, stores the following programs, modules, and data structures, or a subset or superset thereof:
  • operating system 310 including procedures for handling various basic system services and for performing hardware dependent tasks
  • network communication module 312 for transmitting signals to and receiving signals from mobile devices 104 via the one or more communication devices 304;
  • server-side module 106 which provides server-side data processing
  • o transaction authorization module 314 for: receiving a transaction request from a respective mobile device 104, where the transaction request includes a device ID associated with a respective payment module 124 and an authorization code; and validating the transaction request;
  • o encryption/decryption module 316 for: identifying an encryption/decryption key linked to the device ID for the respective payment module 124; decrypting the authorization code with the identified encryption/decryption key; and encrypting the authorization grant token with the identified encryption/decryption key;
  • o offer determining module 318 for determining one or more promotional offers based on one or more of a plurality of factors (e.g., the device ED included in the transaction request, the user ID and history associated with the user of the respective mobile device 104, current location of the respective mobile device 104, current time/date, and/or the like);
  • o transmitting module 320 for: transmitting, in accordance with a determination that the transaction request is validated, an authorization grant token and the one or more promotional offers to the respective mobile device 104; and transmitting acknowledgment information once a transaction is completed to the respective mobile device 104;
  • o receiving module 322 for receiving information from the respective mobile device 104, including but not limited to: a product code and a corresponding selected promotional offer, the transaction status information for a respective transaction, the transaction detail information for the respective transaction, and/or the other miscellaneous information;
  • o offer validation module 324 for: validating a promotional offer based on a received product code, transaction status information, and/or transaction detail information; and sending, in accordance with a determination that the promotional offer is validated, promotion validation information to the respective mobile device 104;
  • o accounting module 326 for debiting an account balance or charging a linked credit card or bank account according to the transaction detail information; o acknowledgment module 328 for sending acknowledgment information to the respective mobile device 104 for relay to the respective payment module 124; and
  • asynchronous transactions module 350 which provides server-side payment functionalities for the payment processing system 1300, described in more detail with reference to Figure 16A below;
  • server data 340 storing data for the payment processing system 100, including but not limited to:
  • o user information database 114 storing stores information for each user of the payment processing system 100, including but not limited to: a unique user identifier (i.e., a user ID), login credentials (i.e., user name or handle and password), transaction history, payment data (e.g., account balance, linked credit card or bank information, app credit or gift card balance, billing address, shipping address, etc.), contact information (e.g., email address, phone number, etc.), custom parameters for the user (e.g., age, location, hobbies, etc.), identified trends and/or likes/dislikes of the user, and/or the like;
  • a unique user identifier i.e., a user ID
  • login credentials i.e., user name or handle and password
  • transaction history e.g., payment data
  • payment data e.g., account balance, linked credit card or bank information, app credit or gift card balance, billing address, shipping address, etc.
  • contact information e.g., email address, phone number,
  • o offers database 116 storing promotional offers provided by manufacturers, distributors, retailers, and/or the like;
  • o payment module database 342 storing information for each payment module 124 of the payment processing system 100, including but not limited to: a unique payment module identifier (i.e., a device ID), an encryption/decryption key, and/or the like; and
  • Each of the above identified elements may be stored in one or more of the previously mentioned memory devices, and corresponds to a set of instructions for performing a function described above.
  • the above identified modules or programs i.e., sets of instructions
  • the memory 306 optionally, stores a subset of the modules and data structures identified above.
  • the memory 306, optionally, stores additional modules and data structures not described above.
  • FIG. 108 are performed by the mobile device 104, and the corresponding sub-modules of these functions may be located within the mobile device 104 rather than the server system 108. In some implementations, at least some of the functions of mobile device 104 are performed by the server system 108, and the corresponding sub-modules of these functions may be located within the server system 108 rather than the mobile device 104.
  • the mobile device 104 and the server system 108 shown in Figures 2-3, respectively, are merely illustrative, and different configurations of the modules for implementing the functions described herein are possible in various implementations.
  • Figure 4 is a schematic block diagram illustrating the automatic retail machine
  • the automatic retail machine 122 is a vending machine or kiosk that dispenses an item or product (e.g., snacks, other foodstuffs, school supplies, drinks, tickets, and the like) in response to user payment for and selection of the item or product.
  • the automatic retail machine 122 includes: a controller 402; a power supply 404; memory 406; a user interface 408; one or more optional sensors 414; a multi-drop bus (MDB) 416; and a dispenser 424.
  • MDB multi-drop bus
  • the controller 402 is a microcontroller
  • the power supply 404 is a connection to an external power source (e.g., AC or DC) or a connection to an internal power source (e.g., a battery).
  • an external power source e.g., AC or DC
  • an internal power source e.g., a battery
  • the power supply 404 further includes one or more of a power converter and/or inverter, a rectifier, a power conditioner, or the like for providing power to the various components of the automatic retail machine 122.
  • the memory 406 includes high-speed random access memory, such as DRAM, SRAM, DDR RAM, or other random access solid state memory devices; and, optionally, includes non-volatile memory, such as one or more magnetic disk storage devices, one or more optical disk storage devices, one or more flash memory devices, or one or more other non-volatile solid state storage devices.
  • the memory 406 stores an operating system and instructions for carrying out the functions and processes of the automatic retail machine 122 (e.g., dispensing items, tracking inventory, temperature control, power control, and the like). In some
  • the memory 406 also stores configuration data and DEX (data exchange) data corresponding to the inventory of the automatic retail machine 122 and transactions performed with the automatic retail machine 122.
  • DEX data exchange
  • the user interface 408 includes one or more output devices 410 that enable presentation of information (e.g., text, images, audio, video, etc.), for example, one or more speakers and/or one or more visual displays.
  • the user interface 408 also includes one or more input devices 412, including user interface components that facilitate user input and selection of items such as a microphone, a keypad, a touch screen display, a gesture capturing camera, or other input buttons or controls.
  • the one or more optional sensors 414 include, but are not limited, to one or more microphones, one or more cameras, an ambient light sensor, one or more accelerometers, one or more gyroscopes, a temperature sensor, one or more motion sensors, one or more biometric/biological sensors, and so on.
  • a variety of payment devices are coupled with the
  • MDB 416 including any combination of one or more cashless payment devices 418 (e.g., credit card reader(s)) for accepting cashless payments, one or more bill validators 420 for accepting and validating bills, and one or more coin accepters 422 for accepting coins and providing change.
  • the dispenser 424 is an electromechanical system (e.g., motors, actuators, and the like) for dispensing or vending items or products stocked by the automatic retail machine. 122 For example, a user inserts a bill into the bill validator(s) 420 and is credited with an amount of money equal to the bill.
  • the one or more output devices 410 (e.g., a display) shows the credited amount, and the user selects an item via the one or more input devices 412 (e.g., using a keypad or a sequence of button presses). Subsequently, the controller 402 sends signals to the dispenser 424 to dispense the selected product, and the dispenser dispenses or vends the selected product.
  • the controller 402 sends signals to the dispenser 424 to dispense the selected product, and the dispenser dispenses or vends the selected product.
  • FIG. 5 is a block diagram illustrating the payment module 124 in accordance with some implementations.
  • the payment module 124 is an in-line adapter dongle with male and female connectors that couples with the multi-drop bus (MDB) of the respective automatic retail machine 122 as shown in Figures 6B-6C and 7.
  • MDB multi-drop bus
  • the payment module is connected in-line into the MDB 416 in Figure 4.
  • the payment module 124 typically, includes one or more processing units (CPUs) 512, a communication device 504 (e.g., a transceiver associated with a short-range communication protocol such as NFC, BLE, or the like), memory 506, and one or more communication buses 508 for interconnecting these components (sometimes called a chipset).
  • CPUs processing units
  • a communication device 504 e.g., a transceiver associated with a short-range communication protocol such as NFC, BLE, or the like
  • memory 506 e.g., a transceiver
  • the memory 506 includes high-speed random access memory, such as DRAM, SRAM, DDR RAM, or other random access solid state memory devices; and, optionally, includes non-volatile memory, such as one or more magnetic disk storage devices, one or more optical disk storage devices, one or more flash memory devices, or one or more other non-volatile solid state storage devices.
  • the memory 506, optionally, includes one or more storage devices remotely located from one or more processing units 512.
  • the memory 506, or alternatively the non-volatile memory within the memory 506, includes a non-transitory computer readable storage medium.
  • the memory 506, or the non-transitory computer readable storage medium of the memory 506, stores the following programs, modules, and data structures, or a subset or superset thereof: • operating system 510 including procedures for handling various basic system services and for performing hardware dependent tasks;
  • communication module 512 for transmitting signals to and receiving signals from mobile devices 104 via the communication device 504;
  • transaction-processing module 514 including but not limited to:
  • o broadcasting module 516 for: broadcasting an information packet to zero or more client devices 104 within the communication zone of the payment module 124 (i.e., BLE range), where the information packet at least includes a unique identifier corresponding to the payment module 124 (e.g., the device ID) and an authorization code for initiating a transaction with the automatic retail machine 122 to which the payment module 124 is coupled; and storing broadcast authorization codes in authorization database 532;
  • o encryption/decryption module 518 for: encrypting the authorization code with an encryption/decryption key that corresponds to the payment module 124; and decrypting the authorization grant token with the encryption/decryption key;
  • o transaction sniffing module 520 for: detecting signals associated with hard currency transactions and/or other cashless transactions not associated with the payment processing system 100 (e.g., credit card transactions); and storing information associated with said hard currency transactions and/or other cashless transactions (e.g., in the other information database 536); o validating module 522 for validating a transaction by checking the authorization code from the decrypted authorization grant token against previously broadcast authorization codes stored in the authorization database 532;
  • o transaction processing module 524 for: causing, in accordance with a determination that the transaction is validated, the automatic retail machine 122 to vend a product or perform a service; and storing transaction detail information in the transaction database 534;
  • o acknowledgement module 526 for deleting transaction detail information from the transaction database 534 in accordance with a determination that the corresponding transaction is acknowledged by the server system 108;
  • data 530 storing data, including but not limited to:
  • o authorization database 532 storing previously broadcast authorization codes
  • o transaction database 534 storing transaction detail information for transactions processed by the payment module 124
  • miscellaneous information regarding the payment module 124 and/or the automatic retail machine 122 coupled with the payment module 124 such as status flags, inventory information, past hard currency transaction information, other cashless transaction information, and/or the like.
  • Each of the above identified elements may be stored in one or more of the previously mentioned memory devices, and corresponds to a set of instructions for performing a function described above.
  • the above identified modules or programs i.e., sets of instructions
  • the memory 506, optionally, stores a subset of the modules and data structures identified above.
  • the memory 506, optionally, stores additional modules and data structures not described above.
  • FIGS 6A-6C show various views of the payment module 124 of Figure 5 in accordance with some implementations.
  • the payment module 124 is a relatively low cost hardware component that is pre-configured to work with the industry standard multi-drop bus (MDB).
  • MDB industry standard multi-drop bus
  • the payment module 124 can be configured or designed to work with other serial protocols or activate a switch (e.g., a cherry switch mechanism).
  • a switch e.g., a cherry switch mechanism
  • Payments which is incorporated by reference in its entirety.
  • the payment module 124 simulates establishing payment on the automatic retail machine 122 in much the same manner as other alternative forms of payment (e.g., cash).
  • the payment module 124 is preferably designed to be used as an adapter dongle for in-line insertion within, for example, the MDB of the automatic retail machine 122 (e.g., a vending machine).
  • the wire used in MDB technology uses male and female connection ends or adapters to allow the attachment of peripherals. In the case of a vending machine, the MDB with connection ends or adapters would be present to allow the attachment of a payment receiving mechanism (e.g., a coin mechanism).
  • the MDB male and female adapters 612, 614 of the MDB may be separated (as shown in Figures 6B-6C).
  • the payment module 124 in Figures 6A-6C has a male adapter 602 and a female adapter 604.
  • the payment module 124 may be plugged (inserted) in serial (“in-line”) with the MDB.
  • the MDB female adapter 614 may be connected to the male adapter 602 of the payment module 124
  • the MDB male adapter 612 may be connected to the female adapter 604 of the payment module 124.
  • the resulting in-line configuration is shown in Figure 7.
  • the payment module 124 is designed to allow pass-through communications so that if the mobile-device-to-machine payment processing system is not enabled (e.g., for a particular purchase or simply turned off) the MDB functions as though the payment module 124 is not there and the automatic retail machine 122 can function normally.
  • the automatic retail machine 122 includes a display 722 showing user selections, current credit, and the like.
  • the automatic retail machine 122 also includes a touch-screen display 724 and buttons 726 for selecting a product.
  • FIG. 8 is a schematic flow diagram of a process 800 for authenticating a user to perform a transaction in the payment processing system 100 in accordance with some implementations.
  • the payment processing system 100 includes one or more payment modules 124 (e.g., each associated with a respective automatic retail machine 122 such a vending machine for dispensing goods and/or services), one or more mobile devices 104, and the server 108.
  • Each of the one or more mobile devices 104 executes an instance of the client-side module 102 (e.g., as an application) as a foreground or background process to access and communicate with other devices (e.g., the server 108 and the payment modules 124) in the payment processing system 100.
  • the server 108 manages the payment processing system 100 and, in some cases, is associated with an entity that supplies, operates, and/or manufactures the one or more payment modules 124.
  • the process 800 will be described with respect to a respective payment module 124 and a respective mobile device 104 within the payment processing system 100.
  • the payment module 124 broadcasts (802), via a short-range communication capability (e.g., BLE), an information packet.
  • the information packet at least includes an authorization code and a unique identifier associated with the payment module 124 (i.e., the device ID).
  • the information packet further includes a current firmware version of the payment module 124 and one or more status flags corresponding to one or more states of the payment module 124 and/or the automatic retail machine 122.
  • the information packet is further discussed below with reference to Figure 10A.
  • the payment module 124 sends out a unique authorization code every X seconds (e.g., 100 ms, 200 ms, 500 ms, etc.). In some
  • the unique authorization codes are randomly or pseudo-randomly generated numbers.
  • the payment module 124 initializes a random number and then the authorization codes are sequential counts from this random number.
  • the payment module 124 stores the earliest valid (unexpired) counter without a need to store every valid authorization code.
  • the authentication code included in the broadcast information packet is a hash value of the randomly or pseudo-randomly generated number or the sequential number.
  • the payment module 124 stores broadcast authorization codes (e.g., in authorization database 542, Figure 5) until a received authorization grant token matches one of the stored authorization codes and subsequently deletes the matching authorization code.
  • broadcast authorization codes e.g., in authorization database 542, Figure 5
  • authorization codes are one-time use codes whereby a broadcast authorization code may only be used by one mobile device 104 before it is invalidated and/or deleted to prevent re-play attacks.
  • the payment module 124 stores previously broadcast authorization codes for a predetermined amount of time (e.g., Y minutes) after which time an authorization code expires and is deleted.
  • the authorization code is encrypted with a shared secret key known by the server system 108 but unique to the payment module 124.
  • the mobile device 104 receives the broadcast information packet, and the mobile device 104 sends (804), via a long-range communication capability (e.g., GSM, CDMA, Wi-Fi, or the like), an authorization request to the server system 108.
  • a long-range communication capability e.g., GSM, CDMA, Wi-Fi, or the like
  • an application associated with the client-side module 102 is executed as a foreground or background process on the mobile device 104.
  • the application is used for accessing the payment processing system 100.
  • the application receives the broadcast information packet when the mobile device 104 is within the communication zone of the payment module 124 (i.e., BLE range) and either automatically sends the authorization request to the server system 108 or sends the authorization request to the server system 108 when the mobile device 104 is within the authorization zone of the payment module 124.
  • the communication zone of the payment module 124 i.e., BLE range
  • the broadcast information packet includes a baseline authorization zone threshold (i.e., an authorization zone criterion) indicating a baseline received signal strength indication (RSSI) that the mobile device 104 (or the application associated with the client-side module 102) is required to observe from the payment module 124 before being within the authorization zone of the payment module 124.
  • a baseline authorization zone threshold i.e., an authorization zone criterion
  • RSSI received signal strength indication
  • the mobile device 104 (or the application associated with the client-side module 102) offsets the baseline authorization zone threshold based on the reception strength its short-range communication capability (e.g., BLE radio/transceiver) and/or other similar factors.
  • the authorization request at least includes the authorization code which was included in the broadcast information packet, an identifier associated with the user of the mobile device 104 or the user account under which the user of the mobile device 104 is logged into the application (i.e., user ID), and the identifier associated with the payment module 124 (i.e., device ID).
  • the authentication code included in the authorization request is a hash value in cleartext. The authorization request is further discussed below with reference to Figure 10B.
  • the server system 108 After receiving the authorization request, the server system 108 processes
  • the server system 108 identifies a shared secret key based on the device ID and decrypts the authorization code included in the authorization request with the identified shared secret key. The server system 108 determines whether the user associated with the user ID in the authorization request has sufficient funds in his/her account for the payment processing system to perform a transaction at the automatic retail machine 122 to which the payment module 124 corresponding to the device ID is coupled.
  • the server system 108 sends (808), via a long-range communication capability
  • the server system 108 does not send the authorization grant token if the authorization code in the authorization request cannot be decrypted with the shared secret key corresponding to the payment module 124 (e.g., the authorization code is corrupted or hacked). In some implementations, the server system 108 does not send the authorization grant token if the user associated with the user ID in the authorization request does not have sufficient funds in his/her account or has exceeded a predefined daily limit.
  • the server system 108 in addition to the authorization grant token (or lack thereof if the authorization is declined), sends a message directly to the mobile device 104 which is not encrypted with the shared secret key corresponding to the payment module 124. After receiving the message, the mobile device 104 displays an appropriate message to the user such as sufficient funds, transaction authorized, insufficient balance, or declined authorization. In some implementations, the server system 108 sends an
  • the mobile device 104 stores the authorization grant token (e.g., in the user data 264) until a trigger condition is detected.
  • the mobile device 104 receives the authorization grant token, and, subsequently, the mobile device 104 detects (810) a trigger condition. In some
  • the mobile device 104 detects the trigger condition via the hand-free mode (e g., upon entrance into the payment zone of the payment module 124) or manual mode (e.g., interacting with the user interface of the application to initiate a transaction with the payment accepting unit associated with the payment module 124).
  • the hand-free mode e.g., upon entrance into the payment zone of the payment module 124
  • manual mode e.g., interacting with the user interface of the application to initiate a transaction with the payment accepting unit associated with the payment module 124.
  • the trigger condition is satisfied when the mobile device 104 detects a user input on the user interface displayed by the mobile device 104.
  • a transaction is initiated between the user of the mobile device 104 and the 8th floor snack machine when the mobile device 104 detects an upward swipe gesture originating from region 1120 of the user interface 1108.
  • a transaction is initiated between the user of the mobile device 104 and the 8th floor snack machine when the mobile device 104 detects selection of Offer A 1152 with contact 1166.
  • the trigger condition is satisfied when the mobile device 104 observes an RSSI from a respective automatic retail machine that is greater than or equal to the payment zone criterion. For example, once the mobile device 104 is within the payment zone, a transaction between the respective automatic retail machine and the user of the mobile device 104 is automatically initiated. In some implementations, after the RSSI observed from the respective retail machine is greater than or equal to the payment zone criterion, the mobile device 104 prompts the user to provide a transaction confirmation, which when detected serves to satisfy the trigger condition.
  • the mobile device 104 provides a prompts to the user, such as an audible prompt, displayed notification, or vibration, to confirm his/her intention to initiate a transaction with the respective retail machine.
  • the user may confirm his/her intention to initiate the transaction with the respective retail machine by flicking the mobile device 104 towards the automatic retail machine, shaking the mobile device, providing an audible command, or performing a touch input/gesture on the displayed user interface.
  • unused authorization grants (e.g., if there was no trigger condition or it expired) are canceled by the mobile device 104 by sending a cancellation message to the server system 108 corresponding to the unused authorization grant.
  • the server system 108 denies or limits the number of authorization grants sent to the mobile device 104 until it has received transaction
  • the mobile device 104 In response to detecting the trigger condition, the mobile device 104 sends
  • the automatic retail machine 122 displays credit to the user (e.g., via one of the displays 722 or 724 shown in Figure 7) and the user interacts with the input mechanisms of the automatic retail machine 122 (e.g., via the buttons 726 or a touch screen display 724 shown in Figure 7) to purchase products and/or services.
  • the short-range communication capability e.g., BLE
  • the authorization grant token to the payment module 124.
  • the automatic retail machine 122 displays credit to the user (e.g., via one of the displays 722 or 724 shown in Figure 7) and the user interacts with the input mechanisms of the automatic retail machine 122 (e.g., via the buttons 726 or a touch screen display 724 shown in Figure 7) to purchase products and/or services.
  • FIG. 9 is a schematic flow diagram of a process 900 for processing acknowledgment information in the payment processing system 100 in accordance with some implementations.
  • the payment processing system 100 includes one or more payment modules 124 (e.g., each associated with a respective automatic retail machine 122 such a vending machine for dispensing goods and/or services), one or more mobile devices 104, and the server 108.
  • Each of the one or more mobile devices 104 executes an instance of the client-side module 102 (e.g., as an application) as a foreground or background process to access and communicate with other devices (e.g., the server 108 and the payment modules 124) in the payment processing system 100.
  • the server 108 manages the payment processing system 100 and, in some cases, is associated with an entity that supplies, operates, and/or manufactures the one or more payment modules 124.
  • the process 900 will be described with respect to a respective payment module 124 coupled with a respective automatic retail machine 122 and a respective mobile device 104 in the payment processing system 100.
  • the payment module 124 receives first acknowledgment information for a first transaction via the mobile device 104 that initiated the first transaction.
  • the payment module 124 obtains (902) a first notification indicating completion of a first transaction from the automatic retail machine 122.
  • the user of the mobile device 104 selects a product to purchase from the automatic retail machine 122 by interacting with one or more input mechanisms of the automatic retail machine 122 (e.g., he buttons 726 or a touch screen display 724 shown in Figure 7), and the automatic retail machine 122 dispenses the selected product.
  • the payment module 124 obtains a notification from the machine of the completed transaction.
  • the notification includes the amount of the transaction and (optionally) machine status information associated with the automatic retail machine 122 such as inventory information as to one or more products of the automatic retail machine 122 and/or the like.
  • the payment module 124 After obtaining the first notification, the payment module 124 generates (904) first transaction information based on the first notification, and the payment module 124 stores the first transaction information.
  • the transaction information includes a transaction ID for the first transaction, a device ID corresponding to the payment module 124, a user ID corresponding to the mobile device 104, transaction status information indicating that the first transaction is complete, and the transaction amount indicated by the first notification.
  • the payment module 124 retains the authorization code included in the original broadcasted packet and/or the authorization grant token and includes the authorization code in the first transaction information.
  • the authorization code is encrypted with a secret key corresponding to the payment module 124, which is shared with the server system 108 but not the mobile device 104.
  • the first transaction information further includes other information such as the machine status information included in the first notification or transaction information corresponding to previous interrupted transac on(s). See Figure 10D and the accompanying text for further discussion regarding the transaction information 1050.
  • the payment module 124 sends (906), via a short-range communication capability (e.g., BLE), the first transaction information to the mobile device 104.
  • a short-range communication capability e.g., BLE
  • the mobile device 104 sends (908), via a long-range communication capability (e.g., GSM, CDMA, Wi-Fi, or the like), the first transaction information to the server system 108.
  • a long-range communication capability e.g., GSM, CDMA, Wi-Fi, or the like
  • the server system 108 processes (910) the first transaction information. For example, the server system 108 debits the account of the user associated with the user ID in the first transaction information in the amount indicated by the first transaction information.
  • the server system 108 sends (912), via a long-range communication capability
  • first acknowledgment information to the mobile device 104.
  • the first acknowledgment information acknowledges that the server system 108 received the first transaction information.
  • the first acknowledgment information includes the user ID, the device ID, the transaction ID, and (optionally) the authorization grant included in the transaction information (e.g., the authorization code 1058, Figure 10D).
  • the mobile device 104 After receiving the first acknowledgement information, the mobile device 104 sends (914), via a short-range communication capability (e.g., BLE), the first
  • the payment module After receiving the first acknowledgment information, the payment module
  • FIG. 9 is a block diagram of an information packet 1000 broadcast by the payment module 124 (e.g., in step 802 of the process 800 in Figure 8) in accordance with some implementations.
  • the information packet 1000 at least includes: device ID 1002 and authorization code 1004.
  • the information packet 1000 additionally includes: a current firmware version 1006; one or more status flags 1008; and zone criteria information 1010.
  • the device ID 1002 is a unique identifier corresponding to the payment module 124 that broadcast the information packet 1000.
  • the authorization code 1004 is a hash value in cleartext.
  • the payment module 124 randomly or pseudo-randomly generates a number or determines a sequential number (See step 802 of the process 800 in Figure 8) and performs a predetermined hash function (e.g., SHA-256) on the number to produce the hash value as the authorization code 1004.
  • the authorization code 1004 is a unique code that is encrypted with a secret encryption key corresponding to the payment module 124. The secret encryption key is shared with the server system 108, which enables the server system 108 to decrypt the authorization code 1004 and encrypt the authorization grant token but not the mobile device 104.
  • the encryption between server system 108 and payment module 124 is accomplished by two pairs of public/private keys.
  • the firmware version information 1006 identifies a current firmware version 1012 of the payment module 124.
  • the firmware version information 1006 also includes update status information 1014 indicating one or more packets received by the payment module 124 to update the firmware or one or more packets needed by the payment module 124 to update the firmware.
  • the one or more status flags 1008 indicate a state of the payment module 124 and/or the automatic retail machine 122 to which the payment module 124 is coupled. In some implementations, the one or more status flags 1008 indicate a state of the payment module 124 such upload information indicator 1016 indicating that that the payment module 124 has information to be uploaded to the server system 108 (e.g., transaction information for one or more interrupted transactions). In some implementations, upload information indicator 1016 triggers the mobile device 104 to connect to payment module 124 immediately (e.g., if it has interrupted transaction information to be uploaded to the server system 108).
  • the one or more status flags 1008 indicate a state of the automatic retail machine 122 including one or more of an error indicator 1018 (e.g., indicating that a bill and/or coin acceptor of the automatic retail machine 122 is experiencing a jam, error code, or malfunction), a currency level indicator 1020 (e.g., indicating that the level of the bill and/or coin acceptor reservoir of the automatic retail machine 122 is full or empty), and/or inventory level(s) indicator 1022 (e.g., indicating that one or more products of the automatic retail machine 122).
  • the one or more status flags 1008 are error codes issued by the automatic retail machine 122 over the MDB.
  • the zone criteria information 1010 specifies an authorization zone criterion 1024 (e.g., a baseline authorization zone threshold indicating a baseline RSSI that the mobile device 104 (or the application) is required to observe before being within the authorization zone of the payment module 124) and/or a payment zone criterion 1026 (e.g., a baseline payment zone threshold indicating a baseline RSSI that the mobile device 104 (or the application) is required to observe before being within the payment zone of the payment module 124).
  • an authorization zone criterion 1024 e.g., a baseline authorization zone threshold indicating a baseline RSSI that the mobile device 104 (or the application) is required to observe before being within the authorization zone of the payment module 12
  • a payment zone criterion 1026 e.g., a baseline payment zone threshold indicating a baseline RSSI that the mobile device 104 (or the application) is required to observe before being within the payment zone of the payment module 124.
  • the baseline authorization zone threshold and the baseline payment zone threshold are default values determined by the server system 108 or stored as variables by the application, in which case the authorization zone criterion 1024 and payment zone criterion 1026 are offsets to compensate for the strength and/or reception of the short-range communication capability (e.g., BLE
  • zone criteria information 1010 includes a spread between the baseline authorization zone threshold and the baseline payment zone threshold.
  • the mobile device 104 determines the baseline authorization zone threshold and the baseline payment zone threshold based on the spread value and a default value for either the baseline authorization zone threshold or the baseline payment zone threshold. For example, the spread indicates -10 db and the default baseline payment zone threshold is -90 db; thus, the baseline authorization zone threshold is -80 db.
  • the mobile device 104 may further adjust the authorization zone threshold and/or the payment zone threshold based on the strength and/or reception of its short-range communication capability (i.e., BLE
  • FIG 10B is a block diagram of an authorization request 1030 sent by the mobile device 104 to the system server 108 (e.g., in step 804 of the process 800 in Figure 8) in accordance with some implementations.
  • the authorization request 1030 at least includes: a device ID 1002; a user ID 1034; and an authorization code 1004.
  • the device ID 1002 is a unique identifier corresponding to the payment module 124 that broadcast the information packet 1000 that included the authorization code 1004.
  • the user ID 1034 is a unique identifier associated with the user of the mobile device 104 sending the authorization request 1030 to the server system 108. In some implementations, the user ID 1034 is associated with the user account under which the user of the mobile device 104 is logged into the application.
  • the authorization code 1030 is the authorization code 1004 included in the information packet 1000 of that was broadcast by the payment module 124.
  • Figure IOC is a block diagram of an authorization grant token 1040 sent by the server system 108 to the mobile device 104 (e.g., in step 808 of the process 800 in Figure 8) in accordance with some implementations.
  • the server system 108 in accordance with a determination that the authorization code 1036 included in the authorization request 1030 from the mobile device 104 is valid and that the user associated with the mobile device 104 has sufficient funds in his/her account for the payment processing system, the server system 108 generates the authorization grant token 1040.
  • the authorization grant token 1040 at least includes: a device ID 1002; a user ID 1034; an authorized amount 1046; (optionally) an expiration period 1048; and (optionally) the authorization code 1004.
  • the authorization grant token 1040 is encrypted with the shared secret key corresponding to the payment module 124.
  • the device ID 1002 is a unique identifier corresponding to the payment module 124 that broadcast the information packet 1000 that included the authorization code 1004.
  • the user ID 1034 is a unique identifier associated with the user of the mobile device 104 that sent the authorization request 1030 to the server system 108.
  • the authorized amount 1046 indicates a maximum amount for which the user of the mobile device 104 is authorized to perform transaction(s) using the authorization grant token 1140.
  • the authorized amount 1046 is predefined by the user of the mobile device 104 or by the server system 108 based on a daily limit or based on the user’s total account balance or based on a risk profile of the user associated with the user ID 1034.
  • the expiration period 1048 indicates an offset to the amount of time that the payment module 124 holds the authorization grant token 1040 valid for initiation of a transaction with the automatic retail machine 122 associated with the payment module 124.
  • the expiration period 1048 depends on the history and credit of the user of the mobile device 104 or a period predefined by the user of the mobile device 104.
  • the authorization grant token 1040 further includes the authorization code 1004 that was included in the authorization request 1030.
  • the server system 108 encrypts the authorization grant token 1040 including the hashed value with the shared secret encryption key associated with the payment module 124.
  • the payment module 124 decrypts the authorization grant token 1040 using the secret key known only to the server system 108 and the payment module 124 (which authenticates the message and the authorization grant), and then matches the hash value included in the decrypted authorization grant token 1040 to previously broadcast valid (i.e., unexpired and un-used) hash values (e.g., stored authorization codes) to determine the validity of the hash value (which was known only by the payment module 124).
  • valid i.e., unexpired and un-used
  • hash values e.g., stored authorization codes
  • FIG. 10D is a block diagram of transaction information 1050 generated by the payment module 124 (e.g., in step 904 of the process 900 in Figure 9) in accordance with some implementations.
  • the transaction information 1050 includes: a transaction ID 1052 for the respective transaction; a device ID 1054; a user ID 1056;
  • the transaction information 1050 is encrypted with the shared secret key corresponding to the payment module 124.
  • the transaction ID 1052 is a unique identifier corresponding to the respective transaction.
  • the transaction ID 1052 is encoded based on or associated with the time and/or date on which and the location at which the respective transaction took place.
  • the device ID 1054 is a unique identifier corresponding to the payment module 124 that performed the respective transaction.
  • the user ID 1056 is an identifier associated with the user of the mobile device 104 that initiated the respective transaction.
  • the authorization code 1058 corresponds to the original authorization code (e.g., the auth code 1004, Figures 10A-10C) and/or authorization grant token (e.g., the auth grant token 1040, Figure IOC) that was used to initiate the respective transaction.
  • the authorization code 1056 is encrypted with a unique encryption key corresponding to the payment module 124.
  • the transaction status information 1060 includes an indication whether the respective transaction was completed, not-completed, or aborted.
  • the respective transaction is incomplete if a jam occurred at the automatic retail machine 122 and the user did not receive the product associated with the respective transaction.
  • the respective transaction is aborted.
  • respective transaction times out after a predetermined time period because the user failed to select a product at the automatic retail machine 122 the respective transaction is aborted.
  • the respective transaction is aborted.
  • the user actuates a bill or coin return mechanism of the automatic retail machine 122 the respective transaction is aborted.
  • the transaction detail information 1062 indicates the amount of the respective transaction or the amount of each of multiple transactions (e.g., in a multi-vend scenario). In some implementations, the transaction detail information 1062 also indicates other information related to the respective transaction such as the items dispensed by the automatic retail machine 122 and the type of transaction (e.g., coins, bills, credit card, manual mode, hands-free mode, etc.).
  • the miscellaneous information 1064 includes other information related to the payment module 124 and/or the automatic retail machine 122 to which the payment module 124 is coupled.
  • the miscellaneous information 1064 includes a verification request to the server system 108 in order to implement new firmware.
  • the miscellaneous information 1064 includes transaction information from one or more previous interrupted transactions.
  • the miscellaneous information 1064 includes transaction information for one or more past hard currency transactions and/or other cashless transactions (e.g., paid with a credit card or bank card at the automatic retail machine 122).
  • the miscellaneous information 1064 includes inventory information as to one or more products of the automatic retail machine 122
  • UIs user interfaces
  • the display 1106 is a touch screen (sometimes also herein called a“touch screen display”) enabled to receive one or more contacts and display information (e g., media content, websites and web pages thereof, and/or user interfaces for application(s) 326).
  • Figures 11 A-l 1G illustrate exemplary user interfaces for facilitating displaying promotional offers in accordance with some implementations.
  • the device detects inputs on a touch-sensitive surface that is separate from the display.
  • the touch sensitive surface has a primary axis that corresponds to a primary axis on the display.
  • the device detects contacts with the touch-sensitive surface at locations that correspond to respective locations on the display. In this way, user inputs detected by the device on the touch-sensitive surface are used by the device to manipulate the user interface on the display of the device when the touch-sensitive surface is separate from the display. It should be understood that similar methods are, optionally, used for other user interfaces described herein.
  • contacts e.g., finger inputs such as finger contacts, finger tap gestures, finger swipe gestures, etc.
  • one or more of the contacts are replaced with input from another input device (e.g., a mouse-based, stylus-based, or physical button-based input).
  • a swipe gesture is, optionally, replaced with a mouse click (e.g., instead of a contact) followed by movement of the cursor along the path of the swipe (e.g., instead of movement of the contact).
  • a tap gesture is, optionally, replaced with a mouse click while the cursor is located over the location of the tap gesture (e.g., instead of detection of the contact followed by ceasing to detect the contact) or depression of a physical button.
  • a tap gesture is, optionally, replaced with a mouse click while the cursor is located over the location of the tap gesture (e.g., instead of detection of the contact followed by ceasing to detect the contact) or depression of a physical button.
  • multiple user inputs are simultaneously detected, it should be understood that multiple computer mice are, optionally, used simultaneously, or a mouse and finger contacts are, optionally, used simultaneously.
  • Figures 1 lA-11G show user interface 1108 displayed on respective mobile device 104 (e.g., a mobile phone associated with a user) for an application associated with the payment processing system 100; however, one skilled in the art will appreciate that the user interfaces shown in Figures 1 lA-11G may be implemented on other similar computing devices.
  • the user interfaces in Figures 1 lA-11G are used to illustrate the processes described herein, including the method described with respect to Figures 12A-12C.
  • the following user interfaces are merely examples.
  • affordances and/or user interface elements may be used in practice.
  • FIG 11A illustrates the mobile device 104 displaying a transaction initiation screen 1110 for 8th floor snack machine.
  • the transaction initiation screen 1110 includes a sequence of indicators 1116 showing that 8th floor snack machine is one of three automatic retail machines with which the user is authorized to initiate a transaction.
  • the user of the mobile device 104 is able to access the second of the three automatic retail machines by performing a left-to-right swipe gesture on the user interface 1108 (or alternatively a right-to-left swipe gesture) and the first second the three automatic retail machines by performing a right-to-left swipe gesture on the user interface 1108 (or alternatively a left-to-right swipe gesture).
  • the user of the mobile device 104 is able to access settings and/or a home screen of the application by selecting affordance 1112 (e.g., with a tap gesture), and the user of the mobile device 104 is able to refresh the transaction initiation screen 1110 by selecting affordance 1114 (e.g., with a tap gesture).
  • affordance 1112 e.g., with a tap gesture
  • affordance 1114 e.g., with a tap gesture
  • Figure 11A also shows that the user of the mobile device 104 has a prepaid balance of $100.00.
  • the user of the mobile device 104 is able to initiate a transaction with the 8th floor snack machine by performing an upward swipe gesture originating from region 1120 of the transaction initiation screen 1110.
  • the user of the mobile device 104 is able to access special promotional offers by selecting“Special Offers” region 1122 (e.g., with a tap gesture), and the user of the mobile device 104 is able to“like” or favorite the 8th floor snack machine by selecting affordance 1124 (e.g., with a tap gesture).
  • Figure 11 A also illustrates the mobile device 104 detecting contact 1140 at a location corresponding to“Special Offers” region 1122.
  • Figure 1 IB illustrates the mobile device 104 displaying a special offers screen
  • the special offers screen 1130 includes: a first region that corresponds to“Offer A” 1152 on product A accompanied by image A of product A; a second region that corresponds to“Offer B” 1154 on product A accompanied by image A of product A; and a third region that corresponds to“Offer C” 1156 on product B accompanied by image B of product B.
  • the special offers screen 1130 also includes refresh affordance 1151, which, when activated (e.g., via a tap gesture), causes the special offers screen 1130 to be refreshed.
  • none of Offers A, B, C are currently selected.
  • the user of the mobile device 104 is able to select“Offer A” 1152 by performing a gesture (e.g., a tap gesture) on selection affordance 1153.
  • the user of the mobile device 104 is able to select“Offer B” 1154 by performing a gesture (e.g., a tap gesture) on selection affordance 1155 or“Offer C” 1156 by performing a gesture (e.g., a tap gesture) on selection affordance 1157.
  • the user of the mobile device 104 is also able to dismiss or delete any of Offers A, B, or C by performing a right-to-left swipe gesture (or a left-to right swipe gesture in other implementations) in a corresponding region.
  • Figure 1 IB also illustrates the mobile device 104 detecting a right-to-left swipe gesture within the second region corresponding to“Offer B” 1154 with contact 1160 moving from a first location 1162-a to a second location 1162-b.
  • the special offers screen 1130 further includes a fourth region corresponding to“No Selected Offer.”
  • the user of the mobile device 104 may view the promotional offers on the special offers screen 1130 but not wish to apply any of them to a future transaction with the 8th floor snack machine.
  • the user of the mobile device 104 may select the“No Selected Offer” region (e.g., with a tap gesture), and, in response, the mobile device 104 re-displays the transaction initiation screen 1110 as shown in Figure 11 A.
  • Figure 11C illustrates the mobile device 104 displaying delete affordance 1164 within the second region corresponding to“Offer B” 1154 in response to detecting the right- to-left swipe gesture in Figure 1 IB.
  • the delete affordance 1164 when activated, (e.g., via a tap gesture), causes“Offer B” 1154 to be deleted from the special offers screen 1130.
  • Figure l lC also illustrates mobile device 104 detecting contact 1166 at a location corresponding to delete affordance 1164.
  • Figure 1 ID illustrates the mobile device 104 ceasing to display“Offer B”
  • Figure 1 ID also illustrates mobile device 104 detecting contact 1168 at a location corresponding to selection affordance 1153 for“Offer A” 1152.
  • the user of the mobile device may not wish to apply any of the offers to a future transaction with the 8th floor snack machine.
  • the user may select the affordance 1112 (e.g., with a tap gesture) or perform a predefined gesture on the special offers screen 1130 to re-display the transaction initiation screen 1110 as shown in Figure 11 A.
  • Figure 1 IE shows that selection affordance 1153 is selected in response to detecting selection of selection affordance 1153 in Figure 1 ID.
  • a transaction with the 8th floor snack machine is automatically initiated in response to detecting selection of selection affordance 1153 in Figure 1 ID.
  • the mobile device 104 after detecting selection of selection affordance 1153 in Figure 1 ID, the mobile device 104 re-displays the transaction initiation screen 1110 (as shown in Figure 11A) and the transaction with the 8th floor snack machine is initiated in response to detecting upward swipe gesture originating from region 1120 of the transaction initiation screen 1110.
  • Figure 1 IF illustrates the mobile device 104 displaying a product code screen
  • the product code screen 1170 also includes a product code scanner window 1172 for capturing an image of product A and/or scanning the product code of product A.
  • UPC code 1174 e.g., the product code
  • product A e.g., a candy bar
  • the user of the mobile device 104 is able to capture the image of product A (including the UPC code 1174 within the current field of view) or scan the UPC code 1174 by tapping within product code scanner window 1172, issuing an audible command, depressing a predetermined physical button of the mobile device 104, or the like.
  • Figure 1 IF also shows that the user of the mobile device 104 has a prepaid balance of $99.00, which is $1.00 less than the amount shown in Figures 1 lA-1 IE due to purchase of product A.
  • Figure 11G illustrates the mobile device 104 displaying an offer validation screen 1180.
  • the mobile device 104 displays the offer validation screen 1180 after the user completes the transaction with the 8th floor snack machine and the server validates the product code information (e.g., the UPC scanned in Figure 1 IF).
  • the offer validation screen 1180 indicates that the“Offer A” 1152 was validated and that the user’s balance was credited $0.25.
  • Figure 11G also shows that the user of the mobile device 104 has a prepaid balance of $99.25, which is $0.25 more than the amount shown in Figure 11G due to validation of the“Offer A” 1152 and a credit of $0.25 for the “Offer A” 1152.
  • Figures 12A-12C illustrate a flowchart diagram of a method 1200 of providing and handling promotional offers for an automatic retail machine in accordance with some implementations.
  • method 1200 is performed by a mobile device with a display, one or more processors, and memory.
  • method 1200 is performed by mobile device 104 ( Figures 1-2) or a component thereof (e.g., the client-side module 102, Figures 1-2).
  • method 1200 is governed by instructions that are stored in a non-transitory computer readable storage medium and the instructions are executed by one or more processors of the mobile device. Some operations in the method 1200 are, optionally, combined and/or the order of some operations is, optionally, changed.
  • the payment processing system 100 ( Figure 1) includes the mobile device 104, which performs the method 1200, a server system 108, and a payment module 124 coupled with an automatic retail machine 122.
  • An instance of the client- side module 102 (e.g., as an application) is executed on the mobile device 104 as a foreground or background process to access and communicate with other devices (e.g., the server 108 and the payment module 124) in the payment processing system 100.
  • the server 108 manages the payment processing system 100 and, in some cases, is associated with an entity that supplies, operates, and/or manufactures the payment module 124.
  • the mobile device prior to displaying the one or more promotional offers, the mobile device (1202): obtains an information packet broadcast by a payment module coupled with a automatic retail machine, where the information packet at least includes an authorization code and a unique identifier corresponding to the payment module; send a transaction authorization request to a server, where the transaction authorization includes the authorization code and the unique identifier corresponding to the payment module; and, in response to the transaction authorization request, receive authorization information from the server that includes an authorization grant token for initiating a transaction with the automatic retail machine coupled with the payment module and the one or more promotional offers from the server.
  • the mobile device 104 or a component thereof receives the information packet broadcast by the payment module 124 which at least includes an authorization code and an identifier associated with the payment module 124.
  • the mobile device 104 or a component thereof sends the authorization code to the server 108 to pre authorize a transaction with the automatic retail machine 122 to which the payment module 124 is coupled.
  • the mobile device 104 or a component thereof receives an authorization grant token for performing a transaction with the automatic retail machine 122.
  • the mobile device 104 stores the authorization grant token (e.g., in user data 265, Figure 2) until a trigger condition for initiating the transaction with the automatic retail machine 122 is detected (e.g., by the trigger detecting module 236, Figure 2).
  • the trigger condition is satisfied when the mobile device 104 detects a user input on the user interface displayed by the mobile device 104.
  • a transaction is initiated between the user of the mobile device 104 and the 8th floor snack machine when the mobile device 104 detects an upward swipe gesture originating from region 1120 of the user interface 1108.
  • a transaction is initiated between the user of the mobile device 104 and the 8th floor snack machine when the mobile device 104 detects selection of Offer A 1152 with contact 1166.
  • the mobile device further includes (1204) a first transceiver associated with a short-range communication protocol and a second transceiver associated with a long-range communication protocol.
  • the mobile device communicates with the payment module via the first transceiver, and the mobile device communicates with the server via the second transceiver.
  • the short-range communication protocol is BLE, NFC, or the like
  • the long-range communication protocol is GSM, CDMA, Wi-Fi, or the like.
  • the mobile device displays (1206) one or more promotional offers on the display.
  • the mobile device 104 only displays promotional offers for products which the user has a sufficient balance. For example, a soda costs $2.00 and there is a promotion for $0.50 off, however, the user has a balance of only $1.00.
  • the mobile device forgoes displaying the promotion for the soda.
  • Figure 1 IB shows the mobile device 104 displaying special offers screen 1130 for the 8th floor snack machine.
  • the special offers screen 1130 includes: a first region that corresponds to “Offer A” 1152 on product A accompanied by image A of product A; a second region that corresponds to“Offer B” 1154 on product A accompanied by image A of product A; and a third region that corresponds to“Offer C” 1156 on product B accompanied by image B of product B.
  • a respective one of the one or more promotional offers is applied automatically after the user completes a transaction, and the mobile device prompts the user to provide the product code corresponding to the respective promotion.
  • one or more advertisements are displayed in place of the one or more selectable promotional offers.
  • one of the one or more promotional offers is a
  • “reward” for a product or service that is not associated with the automatic retail machine 122 i.e., an out-of-band offer. For example, if the user purchases a particular product, he/she will receive a link via email for a free download (e.g., a song, video, etc.), in-app credit (e.g., $2.00 for purchases within a digital media marketplace or a $2.00 credit for in-app purchases for a game), or the like. This may or may not require validation of product. For example, buy any product now from this machine and get a link to a $1.00 off coupon via email or text for a case of soda from a retail store.
  • a free download e.g., a song, video, etc.
  • in-app credit e.g., $2.00 for purchases within a digital media marketplace or a $2.00 credit for in-app purchases for a game
  • This may or may not require validation of product. For example, buy any product now from this machine and get a link to
  • the offer might be an“additional sale” this is an out-of-band offer.
  • purchase XYZ Cola now and get a case of XYZ Cola from a store for only $1.50 with a coupon to be mailed to your email address.
  • purchase ABC Chips now and get a special discount offer to buy a cool T- shirt for $5.00. In this example, $5.00 is added to transaction price and the user is sent an email regarding redemption and shipping of the cool the T-shirt.
  • the user is able to dismiss or delete offers and the mobile device 104 sends this information to the server 108 for analytics purposes.
  • Figure 11C shows the mobile device 104 displaying delete affordance 1164 within the second region corresponding to“Offer B” 1154 in response to detecting the right-to-left swipe gesture in Figure 1 IB.
  • Figure 1 ID shows the mobile device 104 ceasing to display“Offer B” 1154 within the special offers screen 1130 in response to detecting selection of delete affordance 1164 in Figure 11C.
  • the one or more promotional offers are identified
  • the server 108 or a component thereof determines/identifies the one or more promotional offers based on the current time/date, current location, device ID associated with the payment module, user ID associated with the user of the mobile device, and the like.
  • the mobile device 104 or a component thereof determines/identifies the one or more promotional offers from a pre-stored collection of offers based on the current time/date, current location, device ID associated with the payment module, user ED associated with the user of the mobile device, and the like. For example, the mobile device 104 identifies the one or more promotional offers from the offers database 266 which includes offers sent by the server 108 at a prior time such as a part of an update to the application.
  • the promotional offers are identified based on the products stocked in the automatic retail machine 122 or past behavior (e g., previous offers selected by the user, previous offers deleted by the user, previous offers not selected by the user, etc.). For example, side-by-side are separate snack and soda vending machines. The user buys a soda first. Then, when the user goes to transact with the snack machine, the user is presented with an offer for a particular product (e.g., to enable cross promotions between soda and snack distributors). Alternatively, the offers could be based on what a user did not select from the soda machine or offers that were actively deleted before.
  • the provider of the server 108 and payment module is not limited to the provider of the server 108 and payment module
  • 124 manages a promotion marketplace to facilitate placing of promotional offers by manufacturers and distributors of products and to also facilitate competition between various product manufacturers and distributors.
  • a distributor or manufacturer of a product may place a promotional offer for $0.25 off on a particular item in all applicable community colleges in California on Thursdays between 2:00 and 4:00 PM PDT.
  • a distributor or manufacturer of a product may place a promotional offer for 50% off on the product on the day the product expires (e.g., to sell perishable sandwiches or the like) for all applicable automatic retail machines.
  • cross- promotional offers or complex promotional offers may also be placed whereby a user gets a credit (e.g., a rebate) for purchasing a particular drink and snack combination where each are manufactured or distributed by different entities.
  • a promotional offer on all items in automatic retail machines on a entity’s campus (essentially a subsidy) is only available to select users. For example, all attorneys and staff at a law firm are given a subsidized rate on snacks but cleaning persons do not benefit from said subsidized rate. In another example, all full-time employees are given a subsidized rate on snacks but temporary workers do not benefit from said subsidized rate.
  • variable pricing is enacted whereby the base price of items changes and promotion offers may be added in addition to the variable pricing scheme.
  • a distributer wishes to decrease the price on all items in applicable machines during the off-peak hours (e g., 9:00 PM - 6:00 AM). Therefore, after a transaction is completed, the server 108 will only charge a user the decreased price, and, after the server processes and accounts for the transaction, transaction acknowledgment information displayed at the mobile device 104 will indicate that the user was only charged the decreased price and not the price shown at the automatic retail machine 122.
  • the mobile device detects (1210) a user input selecting a respective promotional offer of the one or more promotional offers.
  • the user input is a touch input, voice input, or the like.
  • Figure 1 ID shows the mobile device 104 detecting selection of selection affordance 1153 for“Offer A” 1152, and Figure 1 IE shows that selection affordance 1153 is selected in response to detecting selection of selection affordance 1153 in Figure 1 ID.
  • the respective promotional offer is a negative one, such as a donation to AIDS research, that adds a selected amount to the user’s next transaction.
  • the respective promotional offer is a negative one whereby the transaction is rounded up to the nearest dollar, where additional amount is donated to a Cancer research foundation.
  • the mobile device initiates (1212) performance of a transaction with an automatic retail machine coupled with a payment module, where the transaction corresponds to purchase of a product stocked by the automatic retail machine.
  • the transaction is initiated in response to selection of the respective promotional offer (i.e., one-click transaction initiation process).
  • a transaction with the 8th floor snack machine is automatically initiated in response to detecting selection of selection affordance 1153 in Figure 1 ID.
  • the user after the user selects an offer the user performs an action to initiate a transaction with the automatic retail machine (i.e., a two-step transaction initiation process).
  • the mobile device 104 After detecting selection of selection affordance 1153 in Figure 1 ID, the mobile device 104 re-displays the transaction initiation screen 1110 (as shown in Figure 11 A) and the transaction with the 8th floor snack machine is initiated in response to detecting upward swipe gesture originating from region 1120 of the transaction initiation screen 1110.
  • performance of the transaction with the automatic retail machine coupled with the payment module is initiated (1214) by sending the authorization grant token to the payment module, where the authorization grant token includes the authorization code included in the broadcast information packet.
  • initiating performance of the transaction includes the mobile device 104 or a component thereof (e g., the transaction initiating module 238, Figure 2) sending the stored authorization grant token to the payment module 124 for payment and the user manually selects a product using the user interface of the automatic retail machine 122.
  • the automatic retail machine 122 knows nothing about the selected promotional offer - it only knows that the user sent it a payment.
  • the automatic retail machine 122 returns transaction and product information that is passed to the mobile device 104 by the payment module 124 but it cannot determine or state in any way if it is a product that corresponds to the offer.
  • the transaction completion notification indicates“I vended E3 for $1.00”.
  • the mobile device receives (1216) a transaction completion notification from the payment module, where the transaction completion notification indicates that the product corresponding to the selected respective promotional offer was vended by the automatic retail machine.
  • the mobile device 104 or a component thereof e.g., the transaction completion notification receiving module 240, Figure 2
  • receives transaction completion notification e.g., the transaction status information, the transaction detail information, the other miscellaneous information regarding the respective payment module 124 and/or the automatic retail machine 122 to which the respective payment module 124 is coupled, and/or the like
  • transaction completion notification e.g., the transaction status information, the transaction detail information, the other miscellaneous information regarding the respective payment module 124 and/or the automatic retail machine 122 to which the respective payment module 124 is coupled, and/or the like
  • the transaction completion notification includes the good/service associated with the transaction, the current inventory of the automatic retail machine 122, information associated with one or more previous cash transactions, information associated with one or more interrupted transactions handled by the payment module 124, and/or other information associated with the automatic retail machine 122 such as error or maintenance states.
  • the payment module 124 sends an error message in place of the transaction completion notification when the transaction is aborted or an error occurs during the transaction such as unavailability of a requested good/service or a vending jam.
  • the mobile device In response to receiving the transaction completion notification, the mobile device provides (1218) a prompt to the user of the mobile device to obtain a product code for the vended product to validate the respective promotional offer.
  • the mobile device 104 or a component thereof e ., the product code processing module 242, Figure 2
  • Figure 1 shows the mobile device 104 displaying a product code screen 1170, which prompts the user of the mobile device 104 to obtain the product code (e.g., UPC code, SKU, or the like) for product A so as to validate Offer A” 1152 selected in Figure 1 ID.
  • the product code e.g., UPC code, SKU, or the like
  • the product code screen 1170 also includes a product code scanner window 1172 for capturing an image of product A and/or scanning the product code of product A.
  • the UPC code 1174 of product A e.g., a candy bar
  • the product code scanner window 1172 is shown within the product code scanner window 1172.
  • the user of the mobile device 104 is able to capture the image of product A (including the UPC code 1174 within the current field of view) or scan the UPC code 1174 by tapping within product code scanner window 1172, issuing an audible command, depressing a predetermined physical button of the mobile device 104, or the like.
  • the mobile device 104 or a component thereof displays a pop-up message or banner notification on the display prompting the user of the mobile device 104 to manually enter or otherwise obtain the product code of the vended item.
  • the mobile device 104 or a component thereof e.g., the product code processing module 242, Figure 2 provides an audible tone, a vocal prompt, or a sequence of tactile/haptic vibrations prompting the user of the mobile device 104 to enter or otherwise obtain the product code of the vended item.
  • the mobile device obtains (1220) the product code for the vended product.
  • the user enters the barcode character-by-character, scans the barcode, or simply captures an image of the barcode.
  • the mobile device 104 or a component thereof e.g., the product code processing module 242, Figure 2 receives the product code.
  • obtaining the product code further comprises
  • obtaining the product code further comprises (1224): scanning the product code of the product with a scanner unit of the mobile device.
  • the user of the mobile device 104 is able to access a product code capture plug-in from within the application associated with the payment processing system 100 (e g., the product code processing module 242, Figure 2) which enables the user to capture an image of the product with the product code in the field of view or scan the product code of the product.
  • the mobile device 104 extracts the product code from the captured image and sends the extracted product code to the server 108 or, alternatively, the mobile device 104 sends the captured image to the server 108 where the product code is extracted.
  • the user of the mobile device 104 is able to manually enter the product code from within the application (e g., via a virtual keypad) or via a website associated with the payment processing system 100.
  • the mobile device transmits (1226) the product code to the server.
  • the mobile device receives promotion validation information from the server; and displays the promotion validation information on the display, where the promotion validation information indicates whether the respective promotion offer was validated.
  • the mobile device 104 or a component thereof e.g., the product code processing module 242, Figure 2 either validates the obtained product code or sends the obtained product code to the server 108 for validation.
  • the mobile device 104 or a component thereof e.g., the information relaying module 244, Figure 2 sends the transaction completion notification or a portion thereof to the server 108 regardless of whether the user follows the prompt and the mobile device 104 ultimately obtains the product code.
  • the server 108 determines whether conditions for the respective promotional offer have been based on the transaction and the product code. For example, the server 108 determines whether the proper product code was obtained for the respective promotional offer, whether the respective promotional offer has expired, whether the user has fulfilled a buy N items get one free condition, whether the user has fulfilled cross-promotion condition, and/or the like. In some implementations, the offer is validated and applied by the server 108 to the user’s account.
  • the mobile device 104 of a component thereof receives and displays the promotion validation information.
  • the promotion validation information indicates whether the offer was validated and an updated user balance/transaction listing.
  • Figure 11G shows the mobile device 104 displaying an offer validation screen 1180, which indicates that the“Offer A” 1152 was validated and that the user’s balance was credited $0.25.
  • Figure 11G also shows that the user of the mobile device 104 has a prepaid balance of $99.25, which is $0.25 more than the amount shown in Figure 11G due to validation of the“Offer A” 1152 and a credit of $0.25 for the“Offer A” 1152.
  • the promotion validation information indicates that the user must buy 3 more of the product before he/she gets a free product.
  • the promotion validation information includes a coupon for a product or service that is not associated with the automatic retail machine 122 For example, the user is emailed a coupon for $5 off an amusement park for purchasing a soda.
  • the mobile device determines (1228) whether a predetermined time period has expired. In accordance with a determination that the time period has expired, the mobile device provides a notification to the user of mobile device indicating that the respective promotional offer has expired. In accordance with a determination that the time period has not expired, the mobile device transmits the product code to the server.
  • the predetermined time period corresponds to the time between (A) initiating performance of the transaction or prompting for the product code, (B) obtaining the product code or some other time period.
  • the mobile device 104 must receive the product code within 5 minutes of the prompt or within 5 minutes of initiation of the transaction. In some implementations, this may occur hours or even days later. In some implementations, a predetermined proximity between a first location where the transaction was initiated and a second location where the product code was obtained is used in addition to or in place of the predetermined time period.
  • the application associated with the payment processing system 100 has a coupon plug-in whereby the user of the mobile device 104 is able to scan a coupon after completing a transaction for a product and also scan the product code of the product to get a post hoc rebate for the transaction.
  • the promotion validation information indicates
  • the mobile device 104 displays the total deducted from the user’s account or charged to the user’s linked bank card after application of the promotional offer to the base purchase price included in the notification completion information.
  • Figure 11G shows that the user of the mobile device 104 has a prepaid balance of $99.25, which is $0.25 more than the amount shown in Figure 11G due to validation of the“Offer A” 1152 and a credit of $0.25 for the“Offer A” 1152
  • the mobile device transmits (1232) the transaction completion notification to the server.
  • the mobile device 104 or a component thereof e.g., the information relaying module 244, Figure 2
  • sends the transaction completion notification e.g., the transaction status information, the transaction detail information, the other miscellaneous information regarding the respective payment module 124 and/or the automatic retail machine 122 to which the respective payment module 124 is coupled, and/or the like
  • the transaction completion notification or a portion thereof is sent to the server 108 regardless of whether the user follows the prompt and the mobile device ultimately obtains the product code.
  • Figures 12A-12C have been described is merely exemplary and is not intended to indicate that the described order is the only order in which the operations could be performed.
  • One of ordinary skill in the art would recognize various ways to reorder the operations described herein. Additionally, it should be noted that details of other processes described herein with respect to other methods and/or processes described herein (e.g., the processes 800 and 900) are also applicable in an analogous manner to method 1200 described above with respect to Figures 12A-12C.
  • Implementations described in this section include methods and systems for asynchronously processing multiple transactions between one or more consumer devices and a merchant device in parallel.
  • a merchant device ( Figure 13, 1304) runs a merchant app ( Figure 13, 1302), one or more consumer mobile devices 104 run a consumer app 102, and one or more servers 108 interact with both the merchant app and the consumer app (e.g., over a long-range network connection 110, such as the Internet or a wireless mobile network).
  • a long-range network connection 110 such as the Internet or a wireless mobile network.
  • the merchant app and the consumer app are in proximity to each other such that they are within the range of a local communication network 111 (e.g., a wifi, Bluetooth or IEEE 802.15.4 network).
  • the merchant app and/or the consumer app are additionally configured to perform all or a subset of any of the operations described with reference to other portions of the application (e.g., operations described with reference to any of Figures 8-12, operations associated with the mobile devices 104 described above with reference to Figure 1, and/or operations associated with the payment module 124 described above with reference to Figure 1).
  • the merchant app is ready during an idle state (e.g., while in a sleep state or in a background mode) and does not need specific direction to initiate the payment process (e.g., by broadcasting a merchant identifier).
  • the merchant app broadcasts its unique identifier via a local radio for short-range
  • the consumer app in proximity to the merchant app picks up the broadcasted unique identifier, and then the consumer app passes that identifier to a server.
  • the server returns the merchant’s details which can include, but are not limited to, the merchant’s name, logo, picture, address, phone, email, available offers, any preset transaction amounts (e.g., amounts requested by the merchant in order to complete a proposed transaction), and rewards or loyalty points.
  • the merchant information is presented to the consumer in the consumer app ( Figure 23 A). If there are a plurality of merchants in the vicinity, the consumer app presents all available merchants ( Figure 23B) to allow a consumer to select the merchant with whom the consumer wants to conduct an in-person transaction.
  • the available merchant list is presented in the consumer app and may be sorted according to distance to the merchant, which is, in some implementations, based on the signal strength of the short-range radio.
  • the sorting can also be based on set location (e.g., GPS) coordinates, or set from a configuration from the server for sort order for each merchant.
  • the consumer selects the desired merchant and then enters an amount to pay the selected merchant, or selects a pre-filled amount (Figure 24). In some implementations, the consumer enters the amount in a freeform field ( Figure 19). In some implementations, one or more amounts are pre-filled, having already been entered by the merchant. In some implementations, the pre-filled amount(s) is included in the initial broadcast (the broadcast that includes the unique merchant identifier). Alternatively, the pre-filled amount(s) is included in a broadcast form the merchant subsequent to the initial broadcast ( Figure 20). Alternatively, the pre-filled amount(s) is supplied by the server ( Figure 21). The consumer may also optionally view and select available offers for that merchant. The consumer may also optionally enter a“tip” or gratuity amount, and a description for the payment.
  • the consumer Once the consumer has entered the required information, he or she is able to initiate payment to the selected merchant (e.g., Figure 24,“Send Payment”).
  • the payment is sent by the consumer app to the server.
  • the payment is not sent directly to the merchant app via the short-range communication network 111. Rather, the consumer app sends the payment to the server via the long-range communication network 110
  • the server then processes the payment and sends a notification to the merchant app that the payment has been made. A confirmation is also sent to the consumer app.
  • the broadcast from the merchant app (including the merchant’s unique identifier) is unencrypted and may be picked up by any consumer app in the vicinity of the merchant device’s short-range radio.
  • Each consumer device if initiating payment on its own consumer app, can send payments simultaneously based on the requirements of the server(s) to be able to handle multiple requests at the same time (e g., based on processing bandwidth limits of the server).
  • the merchant enters the amount to charge in the Merchant App ( Figure 25A).
  • the amount is then broadcasted via the short- range communications radio along with the unique identifier, or in a subsequent broadcast.
  • the consumer app picks this amount up from the broadcast and prefills it into the consumer app (e g., into the“Amount” field in Figure 24A) to save the consumer effort from having to enter the amount and/or for restricting the consumer from sending a different amount.
  • Pre filling the amount field also minimizes errors as the merchant, not the consumer, enters the amount to pay, ensuring that the amount is correct.
  • the consumer may optionally add an additional amount for gratuity.
  • the merchant configures preset amounts on the server. The amounts are then returned from the server to the consumer app. Neither the merchant nor the consumer enters the amount. The consumer selects from a list of amounts to send ( Figure 26B).
  • the payment processing is not happening locally; rather, the payment processing is happening remotely on the server and only a confirmation or notification is returned to the merchant and consumer apps. As such, no sensitive information (such as credit card numbers) is sent to the merchant app by the consumer app, thereby protecting the consumer’s privacy and providing a more secure platform on which to conduct transactions.
  • the merchant may have more than one unique identifier that directs to the same merchant record, or the merchant may have more than one unique identifier that points to multiple merchant records.
  • the unique identifier need not be fixed and could be changed on demand or automatically via a schedule.
  • a merchant app can act as a beacon (in addition to or as an alternative to being implemented as a smart phone or other type of mobile device) that provides any compatible consumer app in range of the beacon with information enabling the consumer app to perform such payment on the server.
  • the server may transmit the confirmation notification to the merchant by way of a separate device (other than the merchant app), such as a smart watch or other device owned (or otherwise being used) by the merchant.
  • the merchant may respond with a message back to the consumer, such as a“Thank you” message ( Figure 22).
  • the merchant app transmits the message to the server, and the server forwards the message to the consumer app.
  • the merchant app transmits the message directly to the consumer app.
  • the server transmits to the consumer app an itemized receipt based on the items, quantities, and/or amount involved in the completed transaction.
  • FIG 13 is a block diagram of a payment processing system 1300 in accordance with some implementations.
  • the payment processing system 1300 includes consumer application(s) 102 (corresponding to client-side modules 102 in Figure 1) executed on mobile device(s) 104, merchant application(s) 1302 executing on merchant device(s)
  • merchant devices 1304 are mobile devices. Alternatively or additionally, one or more of the merchant devices 1304 are point-of-sale machines (e.g., electronic payment processing systems) which do not take the form factor of a mobile device.
  • the payment module 124 is an example of a merchant device 1302 and implements the merchant application 1302 in the same or similar manner.
  • the consumer application 102 provides consumer-side functionalities for the payment processing system 1300 and communications with both the server-side module 106 and the merchant application 1302.
  • an application associated with the consumer module 102 provides a user interface to the payment processing system 1300 for the consumer device 104.
  • the consumer module 102 communicates with the server-side module 106 via a long-range communication protocol (e.g., GSM, CDMA, Wi-Fi, or the like) through one or more networks 110, and the consumer module 102 communicates with the merchant module 1302 via a short-range communication protocol (e.g., near-field
  • a long-range communication protocol e.g., GSM, CDMA, Wi-Fi, or the like
  • a short-range communication protocol e.g., near-field
  • the server-side module 106 provides server-side functionalities for the payment processing system 1300 for any number of consumer modules 102 and merchant modules 1302 each residing on a respective mobile device 104 or 1304, respectively.
  • Examples of the mobile device(s) 104 and 1304 include, but are not limited to, a handheld computer, a wearable computing device, a personal digital assistant (PDA), a tablet computer, a laptop computer, a desktop computer, a cellular telephone, a smart phone, an enhanced general packet radio service (EGPRS) mobile phone, a media player, a navigation device, a game console, a television, a remote control, a point-of-sale (POS) terminal, vehicle-mounted computer, an eBook reader, or a combination of any two or more of these data processing devices or other data processing devices.
  • PDA personal digital assistant
  • EGPS enhanced general packet radio service
  • POS point-of-sale
  • Examples of the one or more networks 110 include local area networks (LAN) and wide area networks (WAN) such as the Internet.
  • One or more networks 110 are, optionally, implemented using any known network protocol, including various wired or wireless protocols, such as Ethernet, Universal Serial Bus (USB), FIREWIRE, Long Term Evolution (LTE), Global System for Mobile Communications (GSM), Enhanced Data GSM Environment (EDGE), code division multiple access (CDMA), time division multiple access (TDMA), Bluetooth, Wi-Fi, voice over Internet Protocol (VoIP), Wi-MAX, or any other suitable communication protocol.
  • the server system 108 is implemented on one or more standalone data processing apparatuses or a distributed network of computers.
  • the server system 108 also employs various virtual devices and/or services of third party service providers (e.g., third-party cloud service providers) to provide the underlying computing resources and/or infrastructure resources of the server system 108.
  • third party service providers e.g., third-party cloud service providers
  • the server system 108 includes, but is not limited to, a handheld computer, a tablet computer, a laptop computer, a desktop computer, or a combination of any two or more of these data processing devices or other data processing devices.
  • the payment processing system 1300 shown in Figure 1 includes both a client-side portion (e.g., the consumer modules 102 and 1302) and a server-side portion (e.g., the server-side module 106).
  • data processing is implemented as a standalone application installed on the mobile device(s) 104 and/or 1304.
  • the division of functionalities between the client and server portions of the payment processing system 1300 can vary in different implementations.
  • the consumer and merchant module(s) 102 and/or 1302 provide only user-facing input and output processing functions, and delegate all other data processing functionalities to a backend server (e.g., the server system 108).
  • the server system 108 Although many aspects of the present technology are described from the perspective of the server system 108, the corresponding actions performed by the mobile device(s) 104 and/or 1304 would be apparent to ones skilled in the art without any creative efforts. Furthermore, some aspects of the present technology may be performed by the server system 108, the mobile device(s) 104 and/or 1304, or the server system 108 and the mobile device(s) 104 and/or 1304 cooperatively.
  • FIG 14 is a block diagram of the merchant device 1304 associated with a merchant in accordance with some implementations.
  • the merchant device 1304, typically, includes one or more processing units (CPUs) 1402, two or more communication devices
  • the two or more communication devices 1404 include a first transceiver associated with a short-range communication protocol (e.g., NFC,
  • the merchant device 1304 also includes a user interface 1410.
  • the user interface 1410 includes one or more output devices 1412 that enable presentation of media content (e.g., text, images, audio, video, etc.), including one or more speakers and/or one or more visual displays.
  • the user interface 1410 also includes one or more input devices 1414, including user interface components that facilitate user input such as a keyboard, a mouse, a voice-command input unit or microphone, a touch screen display, a touch-sensitive input pad, a gesture capturing camera, or other input buttons or controls.
  • the mobile device 1304 uses a microphone and voice recognition or a camera and gesture recognition to supplement or replace the keyboard.
  • the mobile device 1304 optionally includes one or more sensors 1415, which provide context information as to the current state of the merchant device 1304 or the environmental conditions associated with merchant device 1304.
  • the one or more sensors 1415 include, but are not limited, to one or more microphones, one or more cameras, an ambient light sensor, one or more accelerometers, one or more gyroscopes, a temperature sensor, one or more motion sensors, one or more biometric/biological sensors, and so on.
  • the merchant device 1304 optionally includes a location detection device 1417, such as a GPS (global positioning satellite) or other geo-location receiver, for determining the location of the merchant device 1304.
  • GPS global positioning satellite
  • the memory 1406 includes high-speed random access memory, such as
  • the memory 1406, optionally, includes one or more storage devices remotely located from the one or more processing units 1402.
  • the memory 1406, or alternatively the non-volatile memory within the memory 1406, includes a non-transitory computer readable storage medium.
  • the memory 1406, or the non-transitory computer readable storage medium of the memory 1406, stores the following programs, modules, and data structures, or a subset or superset thereof:
  • operating system 1416 including procedures for handling various basic system
  • communication module 1418 for transmitting signals to and receiving signals from other devices (e.g., the server system 108 and the consumer module 102) via the two or more communication devices 1404;
  • presentation module 1420 for enabling presentation of information (e.g., a user
  • output devices 1412 e.g., displays, speakers, etc.
  • input processing module 1422 for detecting one or more user inputs or interactions from the one or more input devices 1414 and interpreting the detected inputs or interactions;
  • web browser module 1424 for navigating, requesting (e.g., via HTTP), and displaying websites and web pages thereof;
  • one or more applications 1426 for execution by the merchant device 1304 e.g., games, application marketplaces, payment platforms, and/or other web or non-web based applications
  • merchant module 1302 which provides merchant-side data processing
  • payment functionalities for the payment processing system 1300 including but not limited to:
  • o broadcasting module 1452 for broadcasting an information packet to zero or more consumer devices 104 within the communication zone of the merchant device 1304 (i.e., BLE range), where the information packet at least includes a unique identifier corresponding to the merchant device 1304 (e.g., the device ID) and, in some implementations, a payment amount associated with a proposed in-person transaction;
  • o custom amount module 1454 for accepting custom payment amounts for
  • proposed transactions through input device 1414 (e.g., using a free-fill form as in Figure 25A, or a menu of options as in Figure 25B), and transmitting the custom payment amount, using a short-range communication device 1404 to a consumer device 104 for use in proposed transactions;
  • o preset amount module 1456 for accepting custom payment amounts
  • o confirmation module 1458 for receiving a confirmation message from the server 108, using a long-range communication device 1404 (e.g., confirming that the transaction has been completed, the payment has been made by a particular consumer, and the like); and
  • o response module 1460 for transmitting a response to the confirmation message to a consumer device 104 using either a short-range communication device 1404, or for transmitting the response to the server 108 (for forwarding to the consumer device 104) using a long-range communication device 1404, wherein the transmitting is either automatic (e.g., upon receipt of the confirmation message) or manually entered and sent (e.g., upon a decision by the merchant to send the message), wherein the message is preselected (e g., “Thank you”) or customized (e.g., entered by the merchant using a freeform field); and
  • merchant data 1460 storing data associated with the payment processing system 1300, including, but is not limited to:
  • o merchant profile 1462 storing identification information of the merchant associated with the merchant device 1304, including a unique merchant identifier (e.g., a user ID) for broadcasting by the short-range communication device 1404 in accordance with the broadcast module 1452; and optionally storing one or more of a name, logo, picture, address, phone, or email of the merchant; and o merchant data 1464 storing transaction information for proposed in-person transactions between consumer devices 104 and the merchant device 1304, including preset transaction amounts (e.g., Figure 25B), an available offer, or an available reward; and
  • transaction history 1470 storing a history of completed transactions between the
  • consumer devices 104 e.g., a history of payments that have been made by respective consumers associated with respective consumer devices 104 to the merchant associated with the merchant device 1304.
  • Each of the above identified elements may be stored in one or more of the previously mentioned memory devices, and corresponds to a set of instructions for performing a function described above.
  • the above identified modules or programs i.e., sets of instructions
  • the memory 1406, optionally, stores a subset of the modules and data structures identified above.
  • the memory 1406, optionally, stores additional modules and data structures not described above.
  • Figures 15A and 15B are more detailed block diagrams of the asynchronous payment module 250 and asynchronous payment data 270, respectively, of the consumer device 104 as described with reference to Figure 2 above.
  • asynchronous payment module 250 stores the following programs, modules, or a subset or superset thereof:
  • discovery module 252 for receiving, via the short-range communication device 204, one or more information packets broadcast by one or more merchant modules 1302, where each respective information packet at least includes a unique identifier corresponding to the respective merchant device 1304 (e.g., the device ID) and, in some implementations, a payment amount associated with a proposed in-person transaction;
  • merchant selection module 254 for displaying on an output device 212 one or more merchants corresponding to the received merchant identifiers (see, e.g., Figures 23A and 23B); and receiving user selection on an input device 214 of one of the merchants (e.g., user selection of the“Tap to Pay” affordance in Figure 23 A); • merchant detail module 256 for transmitting the received merchant identifiers to the server and receiving from the server merchant identification information (e.g., 1462) and merchant transaction information (e.g., 1464) associated with each merchant identifier; and, in some implementations, for pre-populating a payment amount or a list of payment selections in accordance with the received merchant transaction information;
  • server merchant identification information e.g., 1462
  • merchant transaction information e.g., 1464
  • transaction module 258 for receiving consumer selection (through input device 214) of supplemental transaction data (e.g., a payment amount, an offer, or a tip; see Figures 24 and 26B), and transmitting through the long-range communication device 204 to the server 108 the selected supplemental transaction data; and
  • supplemental transaction data e.g., a payment amount, an offer, or a tip; see Figures 24 and 26B
  • confirmation module 260 for receiving through the long-range communication device 204 a confirmation message from the server 108 indicating the server completed the transaction, and optionally, for receiving a follow-up communication (e.g.,“thank you”) from the merchant (either directly or forwarded through the server 108).
  • a follow-up communication e.g.,“thank you”
  • asynchronous payment data 270 stores the following data structures, or a subset or superset thereof:
  • Figures 16A and 16B are more detailed block diagrams of the asynchronous transactions module 350 and asynchronous transactions data 360, respectively, of the server system 108 as described with reference to Figure 3 above.
  • asynchronous transactions module 350 stores the following programs, modules, or a subset or superset thereof:
  • merchant detail module 352 for receiving requests for merchant details 370 from consumer device(s) 104, and transmitting respective merchant details 370 to respective consumer devices 104;
  • transaction completion module 354 for receiving consumer-specified supplemental transaction data (e.g., a payment amount, an offer, or a tip; see Figures 24 and 26B) from respective consumer device(s) 104 and processing respective transactions in accordance with the merchant details (e.g., payment acceptance information, such as deposit account information) and transaction data (e.g., user-specified or merchant- specified payment amount); and for sending respective confirmation messages (indicating a completed transaction, an accepted or processed payment, and so forth) to respective merchant devices 1304 and/or to respective consumer devices 104; and storing completed transaction information 382; and
  • consumer-specified supplemental transaction data e.g., a payment amount, an offer, or a tip; see Figures 24 and 26B
  • the merchant details e.g., payment acceptance information, such as deposit account information
  • transaction data e.g., user-specified or merchant- specified payment amount
  • respective confirmation messages indicating a completed transaction, an accepted or processed payment, and so forth
  • communication module 356 for receiving communications (e.g.,“thank you”) from merchant device(s) 1304 and transmitting respective communications to respective consumer device(s) 104.
  • asynchronous transactions data 360 stores the following data structures, or a subset or superset thereof:
  • FIG 17 is another view of the payment processing system 1300 in accordance with some implementations.
  • a merchant application 1302 broadcasts a merchant identifier (and in some implementations, a merchant-specified payment amount) through a short-range communication network 111, where it is received by a consumer application 102 when the consumer is in range of the network 111.
  • the consumer app 102 transmits the identifier to the server over long-range communication network 110, and the server returns the merchant’s name and/or logo.
  • the consumer app 102 renders the name(s) and/or logo(s) received by the server in accordance with the broadcasted merchant identifier(s), as shown in the example interfaces depicted in Figures 23A (one merchant) and 23B (two or more merchants).
  • the consumer app pre-fills the payment amount field, or otherwise supplies one or more payment amount choices.
  • the consumer makes supplemental selections (e.g., fills out the fields in Figure 24), and the consumer application 104 transmits the selections back to the server.
  • the server then processes the transaction on behalf of the merchant.
  • the server notifies the merchant application 1302, through the long-range communication network 110, that the transaction is complete.
  • the server also notifies the consumer application 102, through the long-range communication network 110, that the transaction is complete.
  • FIG 18 is another view of the payment processing system 1300 in accordance with some implementations.
  • N consumer devices (104-1 through 104-N) are in range of the merchant device 1304, and each of the N consumer devices receive the merchant’s unique identifier using short-range communications.
  • Each of the N consumer devices consult the server 108, using long-range communications, for additional details regarding the merchant associated with merchant device 1304 (e.g., name, logo).
  • Consumers associated with the N consumer devices 104 asynchronously interact with their respective consumer applications 102, making selections and deciding to transmit supplemental transaction data (e.g., payment amounts) at different times, not necessarily in the same order in which the consumer devices previously received the merchant’s details.
  • supplemental transaction data e.g., payment amounts
  • the server 108 processes respective transactions from respective consumer devices 104 as the supplemental transaction information arrives at the server.
  • the server 108 processes the respective transactions (or overlapping parts of the respective transactions) in parallel.
  • the server 108 asynchronously sends confirmation notifications to the merchant 1304 as each transaction is completed, not necessarily in the order in which the processing began.
  • the server 108 sends the confirmation notifications (or overlapping parts of the confirmation notifications) in parallel.
  • Figures 19-22 are schematic flow diagrams of processes (1900, 2000, 2100, and 2200, respectively) for asynchronously processing payments in the payment processing system 1300 in accordance with some implementations.
  • the payment processing system 1300 includes one or more consumer devices 104, one or more merchant devices 1304, and a server 108.
  • each of the one or more consumer devices 104 executes an instance of the consumer module 102 (e.g., as an application) as a foreground or background process to access and communicate with other devices (e.g., the server 108 and the one or more merchant devices 1304) in the payment processing system 1300.
  • each of the one or more merchant devices 1304 executes an instance of the merchant module 1302 (e.g., as an application) as a foreground or background process to access and communicate with other devices (e.g., the server 108 and the one or more consumer devices 104) in the payment processing system 1300.
  • the server 108 manages the payment processing system 1300 and, in some cases, is associated with an entity that supplies, operates, and/or manufactures the one or more merchant devices 1304. For brevity, the processes will be described with respect to a respective merchant device 1304 and a respective consumer device 104 within the payment processing system 1300.
  • the broadcast is a packet 1000 including a device ID 1002.
  • the broadcast packet includes only a device ID.
  • the consumer 104 selects the merchant ( Figure 23 A) and requests merchant details from the server 108, which responds with the requested details.
  • the consumer 104 enters a payment amount ( Figure 24), and optionally selects an offer and/or specifies a tip amount, and then sends the transaction information (consumer-specified payment amount, offer, and/or tip) to the server 108 for processing.
  • the server 108 processes the transaction, and notifies the merchant 1304 and the consumer 104 that the payment has been accepted and the transaction is therefore complete.
  • the merchant 1304 broadcasts a unique identifier, as described in the previous process.
  • a merchant associated with the merchant device 1304 selects a payment amount (e.g., specified using a merchant UI as depicted in Figures 25A or 25B). Broadcasts subsequent to this step include both the device ID and the merchant- specified payment amount in the broadcast packet.
  • the consumer 104 selects the merchant ( Figure 23 A) and requests merchant details from the server 108, which responds with the requested details. The consumer 104 does not enter a payment amount, as the payment amount has already been specified by the merchant (in this case, the“Amount” field would be pre-filled in Figure 24).
  • the consumer 104 optionally selects an offer and/or specifies a tip amount, and then sends the transaction information (merchant-specified payment amount, offer, and/or tip) to the server 108 for processing.
  • the server 108 processes the transaction, and notifies the merchant 1304 and the consumer 104 that the payment has been accepted and the transaction is therefore complete.
  • the merchant 1304 configures preset payment amounts (e.g., by using a merchant UI as depicted in Figures 25A or 25B), and transmits those amounts to the server 108.
  • the merchant 1304 broadcasts a unique identifier, as described in the previous two processes. In some implementations, the broadcast packet includes only a device ID.
  • the consumer 104 selects the merchant ( Figure 23 A) and requests merchant details from the server 108, which responds with the requested details, including the merchant-specified preset payment amounts.
  • the consumer 104 selects one of the merchant-specified preset payment amounts ( Figure 26B), and optionally selects an offer and/or specifies a tip amount, and then sends the transaction information (merchant-specified present payment amount, offer, and/or tip) to the server 108 for processing.
  • the server 108 processes the transaction, and notifies the merchant 1304 and the consumer 104 that the payment has been accepted and the transaction is therefore complete.
  • processes 1900, 2000, and/or 2100 continue with process 2200 ( Figure 22).
  • the server 108 processes the transaction and notifies the merchant 1304 and the consumer 104 that the transaction is complete
  • the merchant 1304 communicates a message (e.g.,“Thank you”) to the consumer 104.
  • the message is communicated by the merchant 1304 transmitting the message to the server 108, which then transmits the message to the consumer 104.
  • Figures 19-22 have been described is merely exemplary and is not intended to indicate that the described order is the only order in which the operations could be performed.
  • One of ordinary skill in the art would recognize various ways to reorder the operations described herein. Additionally, it should be noted that details of other processes described herein with respect to other methods and/or processes described herein (e.g., the processes 800, 900, and 1200) are also applicable in an analogous manner to methods 1900-2200 described above with respect to Figures 19-22.
  • Figures 23 A, 23B, 24, 26A, and 26B illustrate the consumer device 104 displaying various user input (UI) screens for sending payments.
  • UI user input
  • the consumer device 104 received one merchant identifier corresponding to“Pizza Family Cuisine,” and identifies the name and logo for consumer selection (“Tap to Pay”).
  • the consumer device 104 received three merchant identifiers correspond to“Pizza Family Cuisine,”“Red Windsor Cheese Shop,” and“Lupines Flowers and Shrubberies.” As such, each merchant is listed by name in the same screen, awaiting the consumer’s selection. Alternatively, each screen only includes one merchant, with the screens being scrollable, swipe-able, and so forth.
  • the consumer device 104 displays an“Amount” field, which is either pre-filled (for implementations involving a merchant-specified payment amount) or flllable (for implementations involving a customer-specified payment amount).
  • Figure 26A the consumer device 104 displays a prepopulated payment amount; the consumer can choose among a list of prepopulated payment amounts in Figure 26B.
  • Figures 25A and 25B illustrate the merchant device 1304 displaying various
  • Figure 25A the merchant enters a fillable field with the merchant-specified payment amount.
  • Figure 25B the merchant selects from a menu of prepopulated payment amounts for specifying the merchant-specific payment amount.

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • Cash Registers Or Receiving Machines (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

La présente invention concerne un dispositif de client mobile équipé d'un afficheur, d'un/de processeur(s) et d'une mémoire : qui identifie un dispositif de commerçant à proximité du dispositif de client sur la base d'informations diffusées transmises par le premier dispositif de commerçant, les informations diffusées comprenant un premier identifiant correspondant au premier dispositif de commerçant ; transmet le premier identifiant à un serveur et reçoit du serveur une communication électronique comprenant des informations d'identification et de transaction associées au commerçant ; affiche les informations d'identification, reçoit une sélection d'utilisateur des informations d'identification de commerçant ; et en réponse, affiche les informations de transaction de commerçant, reçoit des informations d'utilisateur supplémentaires et transmet les informations de transaction supplémentaires au serveur pour terminer la transaction.
PCT/US2019/060777 2013-12-18 2019-11-11 Procédé et système pour des paiements mobiles asynchrones pour de multiples transactions en personne effectuées en parallèle WO2020102102A1 (fr)

Priority Applications (4)

Application Number Priority Date Filing Date Title
JP2021524473A JP2022506858A (ja) 2018-11-12 2019-11-11 並列に行われる複数の対面取引のための非同期モバイル支払いの方法及びシステム
EP19820916.5A EP3881257A1 (fr) 2018-11-12 2019-11-11 Procédé et système pour des paiements mobiles asynchrones pour de multiples transactions en personne effectuées en parallèle
US16/681,673 US11481780B2 (en) 2013-12-18 2019-11-12 Method and system for asynchronous mobile payments for multiple in-person transactions conducted in parallel
US17/973,506 US11966926B2 (en) 2013-12-18 2022-10-25 Method and system for asynchronous mobile payments for multiple in-person transactions conducted in parallel

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201862760032P 2018-11-12 2018-11-12
US62/760,032 2018-11-12

Related Parent Applications (2)

Application Number Title Priority Date Filing Date
US15/406,492 Continuation-In-Part US10719833B2 (en) 2013-12-18 2017-01-13 Method and system for performing mobile device-to-machine payments
US16/029,483 Continuation-In-Part US10963905B2 (en) 2013-12-18 2018-07-06 Method and system for providing offers for automated retail machines via mobile devices

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US16/681,673 Continuation US11481780B2 (en) 2013-12-18 2019-11-12 Method and system for asynchronous mobile payments for multiple in-person transactions conducted in parallel

Publications (1)

Publication Number Publication Date
WO2020102102A1 true WO2020102102A1 (fr) 2020-05-22

Family

ID=68887109

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2019/060777 WO2020102102A1 (fr) 2013-12-18 2019-11-11 Procédé et système pour des paiements mobiles asynchrones pour de multiples transactions en personne effectuées en parallèle

Country Status (3)

Country Link
EP (1) EP3881257A1 (fr)
JP (1) JP2022506858A (fr)
WO (1) WO2020102102A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114004662A (zh) * 2021-12-31 2022-02-01 浙江口碑网络技术有限公司 一种资源核销方法及装置、存储介质、计算设备
WO2023272332A1 (fr) * 2021-07-02 2023-01-05 Vipaso Gmbh Procédé d'initiation et d'autorisation de paiements électroniques

Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090076896A1 (en) * 2007-09-13 2009-03-19 Dewitt Jay Allen Merchant supplied offer to a consumer within a predetermined distance
US20100320266A1 (en) * 2009-06-23 2010-12-23 At&T Mobility Ii Llc Devices, Systems and Methods for Wireless Point-of-Sale
US20110178883A1 (en) * 2010-01-15 2011-07-21 Granbery J Hastings Transactions associated with a mobile device
US20110238476A1 (en) * 2010-03-23 2011-09-29 Michael Carr Location-based Coupons and Mobile Devices
US20140052524A1 (en) * 2012-06-06 2014-02-20 Robert Andersen Systems and Methods for Providing Transaction Rewards
US20140108108A1 (en) * 2012-10-17 2014-04-17 Groupon, Inc. Consumer presence based deal offers
US20140279101A1 (en) * 2013-03-15 2014-09-18 Clinkle Corporation Distance factor based mobile device selection
WO2016123545A1 (fr) * 2015-01-30 2016-08-04 Payrange, Inc. Procédé et système pour fournir des offres pour des machines de détail automatisées par l'intermédiaire de dispositifs mobiles
US20160232515A1 (en) * 2013-09-20 2016-08-11 Lucova Inc. Systems and methods for facilitating mobile commerce interactions between customers and merchants
US20180005220A1 (en) * 2016-06-30 2018-01-04 Paypal, Inc. Localized identifier broadcasts to alert users of available processes and retrieve online server data

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9721282B2 (en) * 2011-12-07 2017-08-01 Amazon Technologies, Inc. Merchant verification of in-person electronic transactions
US20130275303A1 (en) * 2012-04-11 2013-10-17 Mastercard International Incorporated Method and system for two stage authentication with geolocation
US20140289047A1 (en) * 2013-03-25 2014-09-25 Danny Yee Selective banner ad display
US9445220B2 (en) * 2013-09-06 2016-09-13 Paypal, Inc. Systems and methods for enabling additional devices to check in to bluetooth low energy (BLE) beacons
US20160092859A1 (en) * 2014-09-26 2016-03-31 Apriva, Llc System and method for facilitating a purchase transaction using beacon equipped devices
CN108141708A (zh) * 2015-09-07 2018-06-08 Sk普兰尼特有限公司 使用信标提供内容信息的服务方法以及确定用户是否进入和离开商店的方法
JP6660207B2 (ja) * 2016-02-24 2020-03-11 ダイドーグループホールディングス株式会社 情報表示プログラム、情報配信方法、および情報配信システム
US20180101834A1 (en) * 2016-10-06 2018-04-12 Paypal, Inc. Wireless communication beacon offer and transaction system

Patent Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090076896A1 (en) * 2007-09-13 2009-03-19 Dewitt Jay Allen Merchant supplied offer to a consumer within a predetermined distance
US20100320266A1 (en) * 2009-06-23 2010-12-23 At&T Mobility Ii Llc Devices, Systems and Methods for Wireless Point-of-Sale
US20110178883A1 (en) * 2010-01-15 2011-07-21 Granbery J Hastings Transactions associated with a mobile device
US20110238476A1 (en) * 2010-03-23 2011-09-29 Michael Carr Location-based Coupons and Mobile Devices
US20140052524A1 (en) * 2012-06-06 2014-02-20 Robert Andersen Systems and Methods for Providing Transaction Rewards
US20140108108A1 (en) * 2012-10-17 2014-04-17 Groupon, Inc. Consumer presence based deal offers
US20140279101A1 (en) * 2013-03-15 2014-09-18 Clinkle Corporation Distance factor based mobile device selection
US20160232515A1 (en) * 2013-09-20 2016-08-11 Lucova Inc. Systems and methods for facilitating mobile commerce interactions between customers and merchants
WO2016123545A1 (fr) * 2015-01-30 2016-08-04 Payrange, Inc. Procédé et système pour fournir des offres pour des machines de détail automatisées par l'intermédiaire de dispositifs mobiles
US20180005220A1 (en) * 2016-06-30 2018-01-04 Paypal, Inc. Localized identifier broadcasts to alert users of available processes and retrieve online server data

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2023272332A1 (fr) * 2021-07-02 2023-01-05 Vipaso Gmbh Procédé d'initiation et d'autorisation de paiements électroniques
CN114004662A (zh) * 2021-12-31 2022-02-01 浙江口碑网络技术有限公司 一种资源核销方法及装置、存储介质、计算设备
CN114004662B (zh) * 2021-12-31 2022-04-15 浙江口碑网络技术有限公司 一种资源核销方法及装置、存储介质、计算设备

Also Published As

Publication number Publication date
JP2022506858A (ja) 2022-01-17
EP3881257A1 (fr) 2021-09-22

Similar Documents

Publication Publication Date Title
US11961107B2 (en) Method and system for providing offers for automated retail machines via mobile devices
US11481780B2 (en) Method and system for asynchronous mobile payments for multiple in-person transactions conducted in parallel
US11501296B2 (en) Method and system for presenting representations of payment accepting unit events
US10891608B2 (en) Method and system for an offline-payment operated machine to accept electronic payments
JP7295164B2 (ja) 遠隔構成オプションに基づいて無人機に提供する電気パルスを決定するシステム及び方法
US11966926B2 (en) Method and system for asynchronous mobile payments for multiple in-person transactions conducted in parallel
US11966898B2 (en) Systems and methods for determining electric pulses to provide to an unattended machine based on remotely-configured options
US11966895B2 (en) Refund centers for processing and dispensing vending machine refunds via an MDB router
US20120310774A1 (en) Electronic payment system
US11210623B2 (en) Authentication system for purchase delivery
US20200051157A1 (en) Electronic payment methods and systems
EP3881257A1 (fr) Procédé et système pour des paiements mobiles asynchrones pour de multiples transactions en personne effectuées en parallèle

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19820916

Country of ref document: EP

Kind code of ref document: A1

DPE1 Request for preliminary examination filed after expiration of 19th month from priority date (pct application filed from 20040101)
ENP Entry into the national phase

Ref document number: 2021524473

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2019820916

Country of ref document: EP

Effective date: 20210614