JP7532358B2 - Asynchronous mobile payment method and system for multiple parallel face-to-face transactions - Google Patents

Description

Technical Field
FIELD OF THE DISCLOSURE [0001] This application relates to the field of payment processing systems, and more particularly to short-range mobile device-to-server initiated payment processing systems.

background
[0002] Traditional electronic payment systems for in-person transactions are one-to-one such that there is one merchant and one consumer conducting one transaction at a time. The process requires dedicated and exclusive interaction between the merchant and the consumer, and typically neither party can leave the process until the payment is completed or canceled.

[0003] In addition, other consumers who want to make payments to the same merchant must wait until the current transaction has completed processing. Consumers interact with merchants sequentially, waiting their turn.

[0004] This system is acceptable in traditional retail situations that require a single consumer to purchase a good or service and a merchant to perform a "checkout" task. In such electronic payment systems, the payment transaction is first initiated by the merchant (e.g., requesting the consumer to pay an amount). These electronic payment systems do not work well when multiple consumers need to pay a single merchant at approximately the same time or when the merchant is unable to initiate the payment process.

[0005] Conversely, in automated retail machines (such as vending machines), the merchant (in this case the machine) is always ready to accept payment. Consumers initiate the payment transaction by presenting their electronic payment credentials, which may include a physical card or a mobile device. These interactions are still limited to one consumer at a time.

overview
[0006] The embodiments described herein provide methods and systems that enable electronic payments via mobile devices such that multiple consumers may simultaneously or near simultaneously initiate overlapping in-person payments to a single merchant. Additionally, in some embodiments, consumers have the option to send a payment to a merchant without the merchant having to first request the payment.

[0007] There are many use cases for such a system, some of which currently only handle cash payments (because existing electronic payment systems do not address the need for multiple parties to send payments to a single merchant). One exemplary use case involves payments to street performers, who traditionally hold out a box, hat, or open guitar case (collectively referred to as a collection box) for payment from spectators. While the performer is performing, any number of spectators may place cash in the collection box to pay the performer.

[0008] In particular, the performer (or merchant, in various contexts) is not required to initiate a payment with each consumer, nor does the performer have to stop what he or she is doing. Also, multiple consumers may pay the performer/merchant without waiting for each transaction to finish. The transactions are asynchronous, since the performer/merchant does not have to approve the transaction before the next payment, and may not approve the payment at all. The methods and systems described herein enable this and similar in-person payment scenarios to be handled via electronic payments administered via mobile electronic devices associated with the merchant/performer and one or more customers.

[0009] In some embodiments, a method of making an asynchronous mobile payment at a consumer device includes identifying a first merchant device in a vicinity of the consumer device based at least in part on broadcast information transmitted by the first merchant device, the broadcast information including a first identifier corresponding to the first merchant device; transmitting the first identifier to a server via a communication unit of the consumer device; and receiving an electronic communication from the server. In some embodiments, the electronic communication includes first merchant identification information of a first merchant associated with the first merchant device, the first merchant identification information including one or more of the first merchant's name, logo, photo, address, phone, or email; and first merchant transaction information identifying a proposed in-person transaction between the consumer device and the first merchant, the first merchant transaction information including a preset transaction amount, an available offer, or an available reward. The method further includes, in some embodiments, displaying the first merchant identification information on a display of the consumer device; receiving a selection of the first merchant identification information from a user of the consumer device; and in response to receiving the selection of the first merchant identification information: displaying the first merchant transaction information; receiving first supplemental transaction information from the user of the consumer device, the first supplemental transaction information being a selection of a preset transaction amount, a selection of an available offer, a selection of an available reward, or a free form payment amount; and transmitting the first supplemental transaction information to the server. The method further includes, in some embodiments, receiving a confirmation from the server that the proposed transaction between the consumer device and the first merchant has been completed.

[0010] In some embodiments, a consumer mobile device (e.g., mobile device 104, FIGS. 1 and 13) includes a display, one or more processors, and a memory storing one or more programs for execution by the one or more processors, the one or more programs including instructions for performing or controlling the performance of any of the methods described herein. In some embodiments, a non-transitory computer-readable storage medium stores one or more programs, the one or more programs including instructions for causing a computer device to perform or control the performance of any of the methods described herein when executed by a mobile device (e.g., consumer mobile device 104, FIGS. 1 and 13) having one or more processors and a display. In some embodiments, a consumer mobile device (e.g., mobile device 104, FIGS. 1 and 13) includes a means for performing or controlling the performance of any of the methods described herein.

[0011] In some embodiments, a merchant device (e.g., retail machine 122 or merchant device 1304, Figs. 1 and 13) includes a display, one or more processors, and a memory storing one or more programs for execution by the one or more processors, the one or more programs including instructions for performing or controlling the performance of any of the methods described herein. In some embodiments, a non-transitory computer readable storage medium stores one or more programs, the one or more programs including instructions for causing a computer device to perform or control the performance of any of the methods described herein when executed by a mobile device (e.g., merchant device 122 or 1304, Figs. 1 and 13) having one or more processors and a display. In some embodiments, a consumer mobile device (e.g., merchant device 122, 1304, Figs. 1 and 13) includes a means for performing or controlling the performance of any of the methods described herein.

[0012] Various advantages of the present application will become apparent in light of the following description.

BRIEF DESCRIPTION OF THE DRAWINGS
[0013] The foregoing features and advantages of the disclosed technology, as well as additional features and advantages thereof, will be more clearly understood as a result of the detailed description of the preferred embodiments when taken in conjunction with the accompanying drawings.

[0014] In order to more clearly describe the technical solutions in the embodiments of the disclosed technology or in the prior art, the following briefly introduces the accompanying drawings necessary to describe the embodiments or the prior art. Obviously, the accompanying drawings in the following description only show some embodiments of the disclosed technology, and those skilled in the art may further derive other drawings from these accompanying drawings without creative efforts.

[0015] FIG. 1 is a block diagram of a payment processing system according to some embodiments. [0016] FIG. 1 is a block diagram of a mobile device according to some embodiments. [0017] FIG. 1 is a block diagram of a server system according to some embodiments. [0018] FIG. 1 is a schematic block diagram of an automated retail machine according to some embodiments. [0019] FIG. 1 is a block diagram of a payment module according to some embodiments. [0020] FIG. 6 is a perspective view of the payment module (e.g., serial dongle adapter) of FIG. 5 according to some embodiments. [0021] FIG. 6B is a perspective view from a first end of the payment module of FIG. 6A according to some embodiments. FIG. 6B is a perspective view from a second end of the payment module of FIG. 6A according to some embodiments. FIG. 6B is a perspective view of the payment module of FIG. 6A in the automated retail machine of FIG. 4 according to some embodiments. [0024] FIG. 1 is a schematic flow diagram of a process for initiating a transaction according to some embodiments. [0025] FIG. 1 is a schematic flow diagram of a process for authorizing a transaction according to some embodiments. [0026] FIG. 11 is a block diagram of an information packet broadcast by a payment module according to some embodiments. [0027] FIG. 4 is a block diagram of an authorization request according to some embodiments. [0028] FIG. 1 is a block diagram of an authorization grant token according to some embodiments. [0029] FIG. 11 is a block diagram of transaction information generated by a payment module according to some embodiments. [0030] FIG. 1 illustrates an exemplary user interface for displaying promotional offers according to some embodiments. [0030] FIG. 1 illustrates an exemplary user interface for displaying promotional offers according to some embodiments. [0030] FIG. 1 illustrates an exemplary user interface for displaying promotional offers according to some embodiments. [0030] FIG. 1 illustrates an exemplary user interface for displaying promotional offers according to some embodiments. [0030] FIG. 1 illustrates an exemplary user interface for displaying promotional offers according to some embodiments. [0030] FIG. 1 illustrates an exemplary user interface for displaying promotional offers according to some embodiments. [0030] FIG. 1 illustrates an exemplary user interface for displaying promotional offers according to some embodiments. [0031] FIG. 1 illustrates a flowchart diagram of a method for providing and processing promotional offers in an automated retail machine according to some embodiments. [0031] FIG. 1 illustrates a flowchart diagram of a method for providing and processing promotional offers in an automated retail machine according to some embodiments. [0031] FIG. 1 illustrates a flowchart diagram of a method for providing and processing promotional offers in an automated retail machine according to some embodiments. [0032] FIG. 1 is a block diagram of a payment processing system according to some embodiments. [0033] FIG. 13 is a block diagram of a merchant device according to some embodiments. [0034] FIG. 1 is a block diagram of a consumer device according to some embodiments. [0034] FIG. 1 is a block diagram of a consumer device according to some embodiments. [0035] FIG. 1 is a block diagram of a server system according to some embodiments. [0035] FIG. 1 is a block diagram of a server system according to some embodiments. [0036] FIG. 1 is a block diagram of a payment processing system according to some embodiments. [0037] FIG. 1 is a block diagram of a payment processing system according to some embodiments. [0038] FIG. 11 is a flow diagram of a process for asynchronously processing payments according to some embodiments. [0039] FIG. 11 is a flow diagram of a process for asynchronously processing payments according to some embodiments. [0040] FIG. 11 is a flow diagram of a process for asynchronously processing payments according to some embodiments. [0041] FIG. 22 is a flow diagram of a process for asynchronously processing payments that is a continuation of any of the processes of FIGS. 19-21 according to some embodiments. [0042] FIG. 1 illustrates an exemplary user interface for processing payments according to some embodiments. [0042] FIG. 1 illustrates an exemplary user interface for processing payments according to some embodiments. [0042] FIG. 1 illustrates an exemplary user interface for processing payments according to some embodiments. [0042] FIG. 1 illustrates an exemplary user interface for processing payments according to some embodiments. [0042] FIG. 1 illustrates an exemplary user interface for processing payments according to some embodiments. [0042] FIG. 1 illustrates an exemplary user interface for processing payments according to some embodiments. [0042] FIG. 1 illustrates an exemplary user interface for processing payments according to some embodiments.

[0043] Like reference characters refer to corresponding parts throughout the several views of the accompanying drawings.

Description of the embodiments
[0044] Reference will now be made in detail to the embodiments, examples of which are illustrated in the accompanying drawings. In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the subject matter presented herein. However, it will be apparent to those skilled in the art that the subject matter may be practiced without these specific details. In other instances, well-known methods, procedures, components, and circuits have not been described in detail so as not to unnecessarily obscure aspects of the embodiments.

[0045] Hereinafter, the technical solutions in the embodiments of the present application will be clearly and completely described with reference to the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only a part, rather than all, of the embodiments of the present application. All other embodiments obtained by those skilled in the art based on the embodiments of the present application without creative efforts shall fall within the protection scope of the present application.

[0046] FIG. 1 illustrates a payment processing system 100. FIGS. 2-5 illustrate exemplary devices within the payment processing system 100. FIGS. 6A-6C and 7 illustrate various views of the payment module 124 and the automated retail machine 122. FIG. 8 illustrates a schematic flow diagram of a process 800 for initiating a transaction within the payment processing system 100. FIG. 9 illustrates a schematic flow diagram of a process 900 for authorizing a transaction within the payment processing system 100. FIGS. 10A-10D illustrate data structures associated with initiating and conducting a transaction within the payment processing system 100. FIGS. 11A-11G illustrate exemplary user interfaces for displaying promotional offers. FIGS. 12A-12C illustrate a flow chart diagram of a method 1200 for providing and processing promotional offers for an automated retail machine. The user interfaces of FIGS. 11A-11G are used to illustrate the method of FIGS. 12A-12C.

Exemplary Devices and Systems
[0047] Figure 1 is a block diagram of a payment processing system 100 according to some embodiments. According to some embodiments, the payment processing system 100 includes client-side processes 102-1, 102-2 (hereinafter "client-side modules 102") executing on mobile devices 104-1, 104-2, a server-side process 106 (hereinafter "server-side module 106") executing on a server system 108 (also sometimes referred to herein as a "server"), and a payment module 124 coupled to an automated retail machine 122. The client-side module 102 provides the client-side functionality of the payment processing system 100 and communication with both the server-side module 106 and the payment module 124. In some embodiments, an application associated with the client-side module 102 provides a user interface with the payment processing system 100 for the mobile device 104. The client-side modules 102 communicate with the server-side module 106 via a long-range communication protocol (e.g., GSM, CDMA, Wi-Fi, etc.) over one or more networks 110, and the client-side modules 102 communicate with the payment module 124 via a short-range communication protocol (e.g., near-field communication (NFC), BLUETOOTH, BLUETOOTH low-energy (BLE), etc.). The server-side module 106 provides the server-side functionality of the payment processing system 100 for any number of client modules 102, each resident on a mobile device 104.

[0048] The payment processing system 100 utilizes the connectivity of the mobile device 104 to communicate with the payment module 124, which does not have a dedicated communication connection or a long-range communication transceiver. In this manner, the mobile device 124 acts as a relay between the payment module 124 and the server system 108. Furthermore, utilizing the connectivity of the mobile device 104 helps to reduce costs from the perspective of the operator of the automated retail machine 122.

[0049] In some embodiments, the server-side module 106 includes one or more processors 112, a user information database 114, an offer database 116, and an input/output (I/O) interface to one or more clients 118. The I/O interface to the one or more clients 118 facilitates client-facing input/output processing of the server-side module 106. In some embodiments, the one or more processors 112 authorize transaction requests, determine promotional offers for a particular mobile device 104, perform accounting settlements, and approve 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 balances, linked credit cards and bank accounts, etc.), and the offer database 116 stores promotional offers provided by manufacturers, distributors, retailers, etc.

[0050] Examples of mobile devices 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, an in-vehicle computer, an e-book reader, or a combination of any two or more of these or other data processing devices.

[0051] Examples of the one or more networks 110 include a local area network (LAN) and a wide area network (WAN) such as the Internet. The 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 Communication (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.

[0052] The server system 108 is implemented on one or more stand-alone data processing devices or on a distributed network of computers. In some embodiments, the server system 108 also employs various virtual devices and/or services of a third party service provider (e.g., a third party cloud service provider) to provide the underlying computational and/or infrastructure resources of the server system 108. In some embodiments, 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 or other data processing devices.

[0053] The payment processing system 100 shown in FIG. 1 includes both a client-side portion (e.g., client-side module 102) and a server-side portion (e.g., server-side module 106). In some embodiments, data processing is implemented as a standalone application installed on the mobile device 104. In addition, the division of functionality between the client and server portions of the payment processing system 100 may vary in various embodiments. For example, in some embodiments, the client-side module 102 is a thin-client that provides only user-facing input/output processing functionality and delegates all other data processing functionality to a back-end server (e.g., server system 108). While many aspects of the present technology are described in terms of the server system 108, corresponding actions performed by the mobile device 104 will be apparent to one of ordinary skill in the art without creative effort. Additionally, some aspects of the present technology may be performed by the server system 108, by the mobile device 104, or in cooperation with the server system 108 and the mobile device 104.

[0054] Figure 2 is a block diagram of a mobile device 104 associated with a user according to some embodiments. 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 referred to as a chipset). The two or more communication devices 204 include a first transceiver associated with a short-range communication protocol (e.g., NFC, BLE, etc.) and a second transceiver associated with a long-range communication protocol (e.g., GSM, CDMA, Wi-Fi, etc.). The mobile device 104 also includes a user interface 210. The user interface 210 includes one or more output devices 212 (including one or more speakers and/or one or more image displays) that enable presentation of media content (e.g., text, images, audio, video, etc.). 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 capture camera or other input buttons or controls. Additionally, in some embodiments, the mobile device 104 uses a microphone and voice recognition or a camera and gesture recognition to complement or replace a keyboard. In some embodiments, the mobile device 104 optionally includes one or more sensors 215 that provide contextual information regarding the current state of the mobile device 104 or environmental conditions associated with the mobile device 104. The one or more sensors 215 include, but are not limited to, one or more microphones, one or more cameras, ambient light sensors, one or more accelerometers, one or more gyroscopes, temperature sensors, one or more motion sensors, one or more bio/biological sensors, and the like. In some embodiments, the mobile device 104 optionally includes a location detection device 217, such as a GPS (Global Positioning Satellite) receiver or other geographic location receiver for determining the location of the mobile device 104.

[0055] 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. Memory 206 optionally includes one or more storage devices located remotely from the one or more processing units 202. Memory 206, or alternatively the non-volatile memory within memory 206, includes a non-transitory computer-readable storage medium. In some embodiments, memory 206 or the non-transitory computer-readable storage medium of memory 206 stores the following programs, modules, and data structures, or a subset or superset thereof:
• An operating system 216 that contains procedures for handling various basic system services and for performing hardware dependent tasks;
• A communications module 218 for sending and receiving signals to other devices (e.g., the server system 108 and the payment module 124) via two or more communications devices 204;
a presentation module 220 for enabling presentation of information on the mobile device 104 via one or more output devices 212 (e.g., display, speakers, etc.) associated with a user interface 210 (e.g., user interface for applications 226, or applications, widgets, websites and their web pages and/or games, audio and/or video content, text, etc. associated with the client-side module 102);
an input processing module 222 for detecting one or more user inputs or interactions from one or more input devices 214 and interpreting the detected inputs or interactions;
• A web browser module 224 for navigating, requesting (e.g., via HTTP), and displaying websites and their web pages;
one or more applications 226 for execution by the mobile device 104 (e.g., games, an application marketplace, a payment platform, and/or other web or non-web based applications);
Client-side modules 102 that provide client-side data processing and functionality for the payment processing system 100, including but not limited to:
a broadcast acquisition module 230 for receiving, via a first transceiver, an information packet broadcast by each payment module 124, the information packet including at least a unique identifier (i.e., device ID) corresponding to each payment module 124 and an authorization code for initiating a transaction with the automated retail machine 122 to which the respective payment module 124 is coupled;
a transaction authorization module 232 for sending a transaction authorization request, including an authorization code, to the server system 108 via the second transceiver; receiving an authorization grant token (including the authorization code) from the server system 108 via the second transceiver for initiating a transaction with the automated retail machine 122 to which the respective payment module 124 is coupled; and storing (e.g., in the user data 264) the received authorization grant token;
o Retrieving (i.e., receiving or retrieving) promotional offers from the server system 108 via the second transceiver (e.g., in response to sending a transaction authorization request, as part of an update to an application associated with the client-side module 102, or at another time); storing the promotional offers retrieved from the server system in an offer database 266; optionally determining one or more promotional offers based on one or more of a number of factors (e.g., device ID, user ID and history, current location of the mobile device 104, current time/date, etc.); presenting the one or more promotional offers to a user of the mobile device via one or more output devices 212 (e.g., displays); and an offer module 234 for detecting a user input selection of each of the one or more promotional offers to be presented to the user of the mobile device 104;
o a trigger detection module 236 for detecting a trigger for initiating a transaction with the automated retail machine 122 to which the respective payment module 124 is coupled (e.g., the trigger being a gesture or other user input by a user of the mobile device 104, the entrance of the mobile device 104 into a payment area based on an RSSI observed from the payment module 124, the selection of a respective promotional offer, etc.);
a transaction initiation module 238 for initiating a transaction with the automated retail machine 122 coupled to the respective payment module 124 by transmitting the stored authorization grant token via the first transceiver to the respective payment module 124;
a transaction completion notification receiving module 240 for receiving, via the first transceiver, a transaction completion notification from the payment module 124, the transaction completion notification including one or more of: transaction status information (e.g., indicating whether the transaction with the automated retail machine 122 was successful, aborted, or failed); transaction detail information (e.g., authorization code, amount of the transaction, goods/products associated with the transaction, time/date the transaction was completed, processing error information, etc.); and, optionally, further including other miscellaneous information regarding the respective payment module 124 and/or the automated retail machine 122 to which the respective payment module 124 is coupled (blocked transaction information, status flags, inventory information, past hard currency transaction information, other cashless transaction information, etc.);
o providing a prompt to the user of the mobile device 104 via one or more output devices 212 to obtain a product code of the sold product to validate the respective promotional offer; a product code processing module 242 for obtaining the product code of the sold product (e.g., the user of the mobile device 104 manually enters the product code, the user of the mobile device 104 captures an image of the sold product from which the product code has been extracted, the user of the mobile device 104 uses a scanner plug-in of an application associated with the client-side module 102 to obtain the product code, etc.) and either validating the product code or transmitting the obtained product code to the server system 108 for validation via a second transceiver;
an information relay module 244 for transmitting information from the payment modules 124 (e.g., transaction status information, transaction detail information, other miscellaneous information regarding the respective payment module 124 and/or the automated retail machine 122 to which the respective payment module 124 is coupled, etc.) to the server system 108 via the second transceiver;
o an offer verification module 246 for receiving promotional verification information from the server system 108 via a second transceiver; and presenting the promotional verification information to the mobile device user via one or more output devices 212 (e.g., a display);
o an authorization module 248 for transmitting authorization information to the payment module 124 via the first transceiver acknowledging that the server system 108 has received and processed the transaction status information and transaction detail information; and o an asynchronous payment module 250 providing the consumer side payment functionality of the payment processing system 1300, which is described in more detail with reference to FIG. 15A below.
Client Data 260, which stores data related to the payment processing system 100, including but not limited to the following:
○ A user profile 262 that stores information about the user of the mobile device 104, including but not limited to a unique user identifier (i.e., user ID), login credentials (i.e., username 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.), the user's customer parameters (e.g., age, location, hobbies, etc.), the user's identified tendencies and/or likes/dislikes, etc.);
○ User data 264 that stores transaction history information, authorization grant tokens, etc.;
o An offer database 266 for storing promotional offers provided by manufacturers, distributors, retailers, etc.; and o An asynchronous payment data database 270 for storing merchant identification information and payment amounts, which is described in more detail with reference to FIG. 15B below.

[0056] Each of the above-identified elements may be stored in one or more of the memory devices mentioned above and corresponds to a set of instructions for performing the functions described above. The above-identified modules or programs (i.e., sets of instructions) need not be implemented as separate software programs, procedures, modules, or data structures, and thus various subsets of these modules may be combined or otherwise rearranged in various embodiments. In some embodiments, memory 206 optionally stores a subset of the above-identified modules and data structures. Additionally, memory 206 optionally stores additional modules and data structures not described above.

[0057] Figure 3 is a block diagram illustrating a server system 108 according to some embodiments. The server system 108 typically includes one or more processing units (CPUs) 112, one or more communication devices 304 (e.g., including I/O interfaces to one or more clients 118), memory 306, and one or more communication buses 308 for interconnecting these components (sometimes referred to as 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 located remotely from the one or more processing units 112. The memory 306, or alternatively the non-volatile memory in the memory 306, includes a non-transitory computer-readable storage medium. In some embodiments, memory 306 or the non-transitory computer readable storage medium of memory 306 stores the following programs, modules, and data structures, or a subset or superset thereof:
• An operating system 310 that contains procedures for handling various basic system services and for performing hardware dependent tasks;
A network communications module 312 for sending and receiving signals to the mobile device 104 via one or more communications devices 304;
Server-side modules 106 that provide server-side data processing and functionality for the payment processing system 100, including but not limited to:
o receiving a transaction request from each mobile device 104 including a device ID and an authorization code associated with each payment module 124; and a transaction authorization module 314 for validating the transaction request;
an encryption/decryption module 316 for identifying an encryption/decryption key linked to the device ID of each payment module 124; decrypting the authorization code with the identified encryption/decryption key; and encrypting an authorization grant token with the identified encryption/decryption key;
○ an offer determination module 318 for determining one or more promotional offers based on one or more of a number of factors (e.g., the device ID included in the transaction request, the user ID and history associated with the user of each mobile device 104, the current location of each mobile device 104, the current time/date, etc.);
a transmission module 320 for transmitting an authorization grant token and one or more promotional offers to each mobile device 104 pursuant to a determination that the transaction request is verified; and for transmitting authorization information to each mobile device 104 once the transaction is completed;
o A receiving module 322 for receiving information from each mobile device 104, including, but not limited to, product codes and corresponding selected promotional offers, transaction status information for each transaction, transaction details for each transaction, and/or other miscellaneous information;
o an offer verification module 324 for verifying the promotional offer based on the received product code, transaction status information, and/or transaction detail information; and for transmitting promotional verification information to the respective mobile device 104 pursuant to a determination that the promotional offer has been verified;
○ Accounting module 326 for debiting or charging account balances to linked credit cards or bank accounts according to transaction details;
o an authorization module 328 for transmitting authorization information to each mobile device 104 for relay to the respective payment module 124; and o an asynchronous transaction module 350 providing consumer-side payment functionality of the payment processing system 1300, which is described in more detail with reference to FIG. 16A below; and ● server data 340 storing data for the payment processing system 100, including but not limited to:
○ A user information database 114 that stores information for each user of the payment processing system 100, including but not limited to: a unique user identifier (i.e., user ID), login credentials (i.e., username 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.), user custom parameters (e.g., age, location, hobbies, etc.), user identified tendencies and/or likes/dislikes, etc.;
○ An offer database 116 that stores promotional offers provided by manufacturers, distributors, retailers, etc.;
o A payment module database 342 for storing information for each payment module 124 in the payment processing system 100, including but not limited to a unique payment module identifier (i.e. device ID), encryption/decryption keys and/or the like; and o Asynchronous transaction data 360 for storing merchant details and transaction information, which is described in more detail with reference to FIG. 16B below.

[0058] Each of the above-identified elements may be stored in one or more of the memory devices mentioned above and corresponds to a set of instructions for performing the functions described above. The above-identified modules or programs (i.e., sets of instructions) need not be implemented as separate software programs, procedures, or modules, and thus, in various embodiments, various subsets of these modules may be combined or otherwise rearranged. In some embodiments, memory 306 optionally stores a subset of the above-identified modules and data structures. Additionally, memory 306 optionally stores additional modules and data structures not described above.

[0059] In some embodiments, at least some of the functions of the server system 108 are performed by the mobile device 104, and corresponding sub-modules of these functions may be located in the mobile device 104 rather than the server system 108. In some embodiments, at least some of the functions of the mobile device 104 are performed by the server system 108, and corresponding sub-modules of these functions may be located in the server system 108 rather than the mobile device 104. The mobile device 104 and server system 108 shown in Figures 2-3, respectively, are merely exemplary, and thus different configurations of modules for implementing the functions described herein are possible in various embodiments.

4 is a schematic block diagram illustrating an automated retail machine 122 according to some embodiments. For example, the automated retail machine 122 is a vending machine or kiosk that provides goods or products (e.g., snacks, other food, school supplies, beverages, tickets, etc.) in response to a user payment and selection of the goods or products. The automated retail machine 122 includes a controller 402; a power supply 404; a memory 406; a user interface 408; one or more optional sensors 414; a multi-drop bus (MDB) 416; and a dispenser 424.

[0061] In some embodiments, the controller 402 is a microcontroller, microprocessor, CPU, FPGA, ASIC, etc. that manages the functions of the automated retail machine 122. The power source 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). In some embodiments, the power source 404 further includes one or more of a power converter and/or inverter, a rectifier, a power conditioner, etc., for providing power to various components of the automated 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. In some embodiments, the memory 406 stores an operating system and instructions for the functions and processing of the automated retail machine 122 (e.g., item dispensing, inventory tracking, temperature control, power control, etc.). In some embodiments, the memory 406 also stores configuration data, DEX (data exchange) data corresponding to the inventory of the automated retail machine 122, and transactions performed by the automated retail machine 122.

[0062] The user interface 408 includes one or more output devices 410 (e.g., including one or more speakers and/or one or more visual displays) that enable presentation of information (e.g., text, images, audio, video, etc.). The user interface 408 also includes one or more input devices 412 that include user interface components that facilitate user input and selection of items, such as a microphone, a keypad, a touch screen display, a gesture capture camera, or other input buttons or control devices. One or more optional sensors 414 include, but are not limited to, one or more microphones, one or more cameras, ambient light sensors, one or more accelerometers, one or more gyroscopes, temperature sensors, one or more motion sensors, one or more biometric/biological sensors, etc.

[0063] In some embodiments, various payment devices are coupled to the MDB 416, including any combination of one or more cashless payment devices 418 (e.g., credit card readers) for accepting cashless payments, one or more bill validators 420 for accepting and validating bills, and one or more coin acceptors 422 for accepting money and providing change. In some embodiments, the dispenser 424 is an electromechanical system (e.g., motors, actuators, etc.) for dispensing or selling goods or products stored by the automated retail machine 122. For example, a user inserts a bill into the bill validator 420 and is guaranteed an amount equal to the bill. Continuing with this example, one or more output devices 410 (e.g., displays) indicate the amount of the deposit, and the user selects an item via one or more input devices 412 (e.g., using a keypad or a series of button presses). The controller 402 then sends a signal to the dispenser 424 to dispense the selected product, and the dispenser dispenses or sells the selected product.

[0064] Figure 5 is a block diagram illustrating a payment module 124 according to some embodiments. In some embodiments, the payment module 124 is a serial adapter dongle with male and female connectors that mate with a multi-drop bus (MDB) of the respective automated retail machine 122 as shown in Figures 6B-6C and 7. For example, the payment module is serially connected into the MDB 416 of 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, etc.), a memory 506, and one or more communication buses 508 for interconnecting these components (sometimes referred to as a chipset). 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. Memory 506 optionally includes one or more storage devices located remotely from the one or more processing units 512. Memory 506, or alternatively the non-volatile memory within memory 506, includes a non-transitory computer-readable storage medium. In some embodiments, memory 506 or the non-transitory computer-readable storage medium of memory 506 stores the following programs, modules, and data structures, or a subset or superset thereof:
• An operating system 510 that contains procedures for handling various basic system services and for performing hardware dependent tasks;
• a network communications module 512 for sending and receiving signals to the mobile device 104 via the communications device 504;
A transaction processing module 514, including but not limited to:
a broadcast module 516 for broadcasting an information packet including at least a unique identifier (i.e., device ID) corresponding to each payment module 124 and an authorization code for initiating a transaction with the automated retail machine 122 to which the payment module 124 is coupled to zero or more client devices 104 within the communication range (i.e., BLE range) of the payment module 124, and for storing the broadcast authorization code in an authorization database 532;
an encryption/decryption module 518 for encrypting the authorization code with an encryption/decryption key corresponding to the payment module 124; and for decrypting the authorization grant token with the encryption/decryption key;
a transaction sniffing module 520 that detects 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 stores information associated with said hard currency transactions and/or other cashless transactions (e.g., in other information database 536);
a verification module 522 for verifying the transaction by checking the authorization code from the decrypted authorization grant token against previously broadcasted authorization codes stored in an authorization database 532;
o a transaction processing module 524 for causing the automated retail machine 122 to sell a product or perform a service pursuant to a determination that the transaction has been verified; and for storing the transaction detail information in a transaction database 534; and o an approval module 526 for deleting the transaction detail information from the transaction database 534 pursuant to a determination that the corresponding transaction has been approved by the server system 108; and
○ An authorization database 532 that stores authorization codes already broadcast;
o A transaction database 534 that stores transaction details for transactions processed by the payment module 124; and o An other information database 536 that stores various miscellaneous information such as status flags, inventory information, past hard currency transaction information, other cashless transaction information, etc. regarding the payment module 124 and/or the automated retail machines 122 coupled to the payment module 124.

[0065] Each of the above-identified elements may be stored in one or more of the memory devices mentioned above and corresponds to a set of instructions for performing the functions described above. The above-identified modules or programs (i.e., sets of instructions) need not be implemented as separate software programs, procedures, or modules, and thus, in various embodiments, various subsets of these modules may be combined or otherwise rearranged. In some embodiments, memory 506 optionally stores a subset of the above-identified modules and data structures. Additionally, memory 506 optionally stores additional modules and data structures not described above.

[0066] Figures 6A-6C show various views of the payment module 124 of Figure 5 according to some embodiments. The payment module 124 is a relatively low-cost hardware component preconfigured to work with the industry standard multi-drop bus (MDB). On machines that do not have MDB technology, the payment module 124 may be configured or designed to work with other serial protocols or activate a switch (e.g., a cherry switch mechanism). See, for example, U.S. Patent Application Serial No. 14/458,192: "Method and System for Retrofitting an Offline-Payment Operated Machine to Accept Electronic Payments," which is incorporated by reference in its entirety. In essence, the payment module 124 mimics establishing a payment on the automated retail machine 122 in much the same way as other alternative forms of payment (e.g., cash).

[0067] The payment module 124 is preferably designed to be used as an adapter dongle for serial insertion in the MDB of an automated retail machine 122 (e.g., a vending machine). The wires used in MDB technology use male and female connection ends or adapters to allow attachment of peripheral devices. In the case of a vending machine, an MDB with connection ends or adapters will be present to allow attachment of a payment receiving mechanism (e.g., a coin mechanism). The MDB male and female adapters 612, 614 of the MDB can be separated (as shown in Figs. 6B-6C). The payment module 124 of Figs. 6A-6C has a male adapter 602 and a female adapter 604. The payment module 124 can be plugged (inserted) in series ("in-line") with the MDB. For example, the MDB female adapter 614 can be connected to the male adapter 602 of the payment module 124 and the MDB male adapter 612 can be connected to the female adapter 604 of the payment module 124. The resulting serial configuration is shown in FIG. 7. It should be noted that since the payment module 124 is designed to allow pass-through communication, if the mobile device to machine payment processing system is not enabled (e.g., for a specific purchase or simply turned off), the MDB will function as if the payment module 124 was not there and the automated retail machine 122 will function normally. In FIG. 7, the automated retail machine 122 includes a display 722 that shows user selections, current credits, etc. In FIG. 7, the automated retail machine 122 also includes a touch screen display 724 and buttons 726 for selecting products.

User Interface and Related Processing
[0068] Figure 8 is a schematic flow diagram of a process 800 for authenticating a user to conduct a transaction in a payment processing system 100 according to some embodiments. In some embodiments, the payment processing system 100 includes one or more payment modules 124 (e.g., each associated with an automated retail machine 122, such as a vending machine, for providing goods and/or services), one or more mobile devices 104, and a server 108. Each of the one or more mobile devices 104 executes an instance of a 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. For simplicity, the process 800 will be described with respect to each payment module 124 and each mobile device 104 in the payment processing system 100.

[0069] The payment module 124 broadcasts (802) an information packet over short-range communication capabilities (e.g., BLE). The information packet includes at least an authorization code and a unique identifier (i.e., device ID) associated with the payment module 124. In some embodiments, 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 statuses of the payment module 124 and/or the automated retail machine 122. Information packets are further discussed below with reference to FIG. 10A.

[0070] In some embodiments, the payment module 124 sends out a unique authorization code every X seconds (e.g., 100 ms, 200 ms, 500 ms, etc.). In some embodiments, the unique authorization code is a randomly or pseudo-randomly generated number. In some embodiments, the payment module 124 initializes a random number and then the authorization code is a consecutive count from this random number. In such an embodiment, the payment module 124 stores the earliest valid (unexpired) counter without the need to store every valid authorization code. In some embodiments, the authentication code included in the broadcast information packet is a hash value of a randomly or pseudo-randomly generated number or consecutive numbers.

[0071] In some embodiments, the payment module 124 stores the broadcast authorization code (e.g., in the authorization database 542 of FIG. 5) until the received authorization grant token matches one of the stored authorization codes and then deletes the matching authorization code. In some embodiments, the broadcast authorization code is a one-time use code, such that the broadcast authorization code may be used by only one mobile device 104 before being disabled and/or deleted to prevent replay attacks. In some embodiments, the payment module 124 stores previously broadcasted authorization codes for a predetermined amount of time (e.g., Y minutes), after which the authorization code expires and is deleted. In some embodiments, the authorization code is encrypted with a shared secret key that is known by the server system 108 but unique to the payment module 124.

[0072] The mobile device 104 receives the broadcast information packet and transmits an authorization request to the server system 108 via a long-range communication capability (e.g., GSM, CDMA, Wi-Fi, etc.) (804). For example, an application associated with the client-side module 102 runs on the mobile device 104 as a foreground or background process. The application is used to access the payment processing system 100. In this example, the application receives the broadcast information packet and either automatically transmits an authorization request to the server system 108 when the mobile device 104 is within the communication range (i.e., BLE range) of the payment module 124, or transmits an authorization request when the mobile device 104 is within the authorization range of the payment module 124.

[0073] In some embodiments, the broadcast information packet includes a baseline authorization zone threshold (i.e., authorization zone criteria) indicating a baseline received signal strength indication (RSSI) that the mobile device 104 (or an application associated with the client-side module 102) is required to observe from the payment module 124 before entering the authorization zone of the payment module 124. In some embodiments, the mobile device 104 (or an application associated with the client-side module 102) offsets the baseline authorization zone threshold based on the received signal strength, its short-range communication capabilities (e.g., BLE radio/transceiver), and/or other similar factors. In some embodiments, the authorization request includes at least the authorization code included in the broadcast information packet, an identifier or user account (i.e., user ID) associated with the user of the mobile device 104 through which the user of the mobile device 104 is logged into the application, and an identifier (i.e., device ID) associated with the payment module 124. In some embodiments, the authentication code included in the authorization request is a hash value in clear text. The authorization request is further discussed below with reference to FIG. 10B.

[0074] After receiving the authorization request, the server system 108 processes the authorization request (806). In some embodiments, 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 or her account at the payment processing system to conduct a transaction at the automated retail machine 122 to which the payment module 124 corresponding to the device ID is coupled.

[0075] The server system 108 transmits (808) the authorization grant token to the mobile device 104 via long range communication capabilities (e.g., GSM, CDMA, Wi-Fi, etc.). In some embodiments, the server system 108 does not transmit 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., if the authorization code is corrupted or hacked). In some embodiments, the server system 108 does not transmit 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 spending limit. In some embodiments, in addition to the authorization grant token (or lack thereof, if authorization is denied), the server system 108 transmits a message directly to the mobile device 104 that 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, authorized transaction, insufficient balance, or denied authorization. In some embodiments, the server system 108 sends an authorization grant token for an amount equal to zero; in this case, the payment module 124 interprets this as a denial or failure of authorization, which may result for any number of reasons, including but not limited to insufficient balance or credit. In some embodiments, the mobile device 104 stores the authorization grant token (e.g., in the user data 264) until a trigger condition is detected.

[0076] The mobile device 104 receives the authorization acceptance token and then detects the trigger condition (810). In some embodiments, the mobile device 104 (or an application) detects the trigger condition via a hands-free mode (e.g., in response to entering a payment area of the payment module 124) or via a manual mode (e.g., by interacting with a user interface of the application to initiate a transaction with a payment accepting unit associated with the payment module 124).

[0077] In some embodiments, the trigger condition is satisfied when the mobile device 104 detects a user input on a user interface displayed by the mobile device 104. For example, referring to FIG. 11A, a transaction is initiated between a user of the mobile device 104 and the 8th floor snack machine when the mobile device 104 detects an upward swipe gesture emanating from area 1120 of the user interface 1108. In another example, referring to FIG. 11D, a transaction is initiated between a user of the mobile device 104 and the 8th floor snack machine when the mobile device 104 detects a selection of Offer A 1152 by contact 1166.

[0078] In some embodiments, the trigger condition is satisfied when the mobile device 104 observes an RSSI from the respective automated retail machine that is equal to or greater than a payment zone criterion. For example, when the mobile device 104 enters the payment zone, a transaction between the respective automated retail machine and the user of the mobile device 104 is automatically initiated. In some embodiments, after the observed RSSI from the respective retail machine is equal to or greater than the payment zone criterion, the mobile device 104 prompts the user to provide a transaction confirmation that, when detected, serves to satisfy the trigger condition. For example, when the mobile device 104 enters the payment zone, the mobile device 104 provides a prompt, such as an audible prompt, a displayed notification, or a vibration, to the user to confirm his/her intent to initiate a transaction with the respective retail machine. Continuing with this example, the user may confirm his/her intent to initiate a transaction with the respective retail machine by flicking the mobile device 104 toward the automated retail machine, by shaking the mobile device, by providing an audible command, or by making a touch input/gesture on a displayed user interface.

[0079] In some embodiments, unused authorization grants (e.g., if a trigger condition did not exist or has expired) are canceled by the mobile device 104 by sending a cancellation message to the server system 108 corresponding to the unused authorization grant. In some embodiments, the server system 108 rejects or limits the number of authorization grants sent to the mobile device 104 until it receives transaction information sent to the mobile device 104 or receives a cancellation of a pending authorization grant.

[0080] In response to detecting the trigger condition, the mobile device 104 transmits (812) an authorization acceptance token via short-range communication capabilities (e.g., BLE) to the payment module 124. The automated retail machine 122 then displays the credit to the user (e.g., via one of the displays 722 or 724 shown in FIG. 7 ), and the user interacts with an input mechanism of the automated retail machine 122 (e.g., via the buttons 726 or the touchscreen display 724 shown in FIG. 7 ) to purchase products and/or services.

[0081] It should be understood that the particular order in which the processes of FIG. 8 are described is merely exemplary, and is not intended to indicate that the described order is the only order in which operations may be performed. Those skilled in the art will recognize various ways to reorder the operations described herein. In addition, it should be noted that other process details described herein (e.g., process 900 and method 1200) with respect to other methods and/or processes described herein may also be applicable in a manner similar to process 800 described above with respect to FIG. 8.

[0082] Figure 9 is a schematic flow diagram of a process 900 for processing authorization information in a payment processing system 100 according to some embodiments. In some embodiments, the payment processing system 100 includes one or more payment modules 124 (e.g., each associated with an automated retail machine 122, such as a vending machine, for providing goods and/or services), one or more mobile devices 104, and a server 108. Each of the one or more mobile devices 104 executes an instance of a 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 module 124) in the payment processing system 100. The server 108 is associated with an entity that manages the payment processing system 100 and, in some cases, supplies, operates, and/or manufactures the one or more payment modules 124. For simplicity, process 900 will be described with respect to each payment module 124 associated with each automated retail machine 122 and each payment module 104 in payment processing system 100. In process 900, the payment module 124 receives a first authorization information for a first transaction via a mobile device 104 that initiated the first transaction.

[0083] The payment module 124 obtains (902) a first notification from the automated retail machine 122 indicating completion of a first transaction. For example, following process 800 of FIG. 8, a user of the mobile device 104 selects a product to purchase from the automated retail machine 122 by interacting with one or more input mechanisms of the automated retail machine 122 (e.g., buttons 726 or touch screen display 724 shown in FIG. 7), and the automated retail machine 122 dispenses the selected product. Continuing with the example, after the product is dispensed, the transaction is completed and the payment module 124 obtains a notification of the completed transaction from the automated retail machine. In some embodiments, the notification includes an amount of the transaction and (optionally) machine status information associated with the automated retail machine 122, such as inventory information for one or more products in the automated retail machine 122.

[0084] 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. In some embodiments, the transaction information includes a transaction ID of 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 completed, and a transaction amount indicated by the first notification. In some embodiments, the payment module 124 retains the authorization code included in the original broadcast packet and/or the authorization grant token, and includes the authorization code in the first transaction information. In some embodiments, the authorization code is encrypted by a private key corresponding to the payment module 124 (shared with the server system 108, not the mobile device 104). In some embodiments, the first transaction information further includes other information, such as machine status information included in the first notification or transaction information corresponding to a previously blocked transaction. See FIG. 10D and accompanying text for further discussion regarding the transaction information 1050.

[0085] The payment module 124 transmits (906) the first transaction information to the mobile device 104 via short-range communication capabilities (e.g., BLE).

[0086] The mobile device 104 transmits (908) the first transaction information to the server system 108 via a long range communication capability (e.g., GSM, CDMA, Wi-Fi, etc.).

[0087] The server system 108 processes (910) the first transaction information. For example, the server system 108 credits the account of the user associated with the user ID in the first transaction information with the amount indicated by the first transaction information.

[0088] The server system 108 transmits (912) the first authorization information to the mobile device 104 via a long range communication capability (e.g., GSM, CDMA, Wi-Fi, etc.). In some embodiments, the first authorization information acknowledges that the server system 108 has received the first transaction information. In some embodiments, the first authorization information includes a user ID, a device ID, a transaction ID, and (optionally) an authorization agreement (e.g., authorization code 1058 of FIG. 10D) included in the transaction information.

[0089] After receiving the first authorization information, the mobile device 104 transmits (914) the first authorization information to the payment module 124 via short-range communication capabilities (e.g., BLE).

[0090] After receiving the first approval information, the payment module 124 deletes (916) the stored first transaction information.

[0091] It should be understood that the particular order in which the processes of FIG. 9 are described is merely exemplary, and is not intended to indicate that the described order is the only order in which operations may be performed. Those skilled in the art will recognize various ways to reorder the operations described herein. In addition, it should be noted that other process details described herein (e.g., process 800 and method 1200) with respect to other methods and/or processes described herein may also be applicable in a manner similar to process 900 described above with respect to FIG. 9.

[0092] FIG. 10A is a block diagram of an information packet 1000 broadcast by the payment module 124 (e.g., in step 802 of process 800 of FIG. 8) according to some embodiments. In some embodiments, the information packet 1000 includes at least a device ID 1002 and an authorization code 1004. In some embodiments, the information packet 1000 additionally includes a current firmware version 1006; one or more status flags 1008; and zone criteria information 1010.

[0093] In some embodiments, the device ID 1002 is a unique identifier corresponding to the payment module 124 that broadcast the information packet 1000.

[0094] In some embodiments, the authorization code 1004 is a hash value in clear text. In some embodiments, the payment module 124 randomly or pseudo-randomly generates a number or determines a consecutive number (see step 802 of process 800 in FIG. 8) and performs a predefined hash function (e.g., SHA-256) on the number to generate a hash value as the authorization code 1004. In some embodiments, the authorization code 1004 is a unique code encrypted with a private encryption key corresponding to the payment module 124. The private encryption key is shared with the server system 108, allowing the server system 108, but not the mobile device 104, to decrypt the authorization code 1004 and to encrypt the authorization grant token. In some embodiments, encryption between the server system 108 and the payment module 124 is achieved with two public/private key pairs.

[0095] In some embodiments, the firmware version information 1006 identifies the current firmware version 1012 of the payment module 124. In some embodiments, 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 required by the payment module 124 to update the firmware.

[0096] In some embodiments, one or more status flags 1008 indicate a status of the payment module 124 and/or the automated retail machine 122 to which the payment module 124 is coupled. In some embodiments, one or more status flags 1008 indicate a status of the payment module 124, such that the upload information indicator 1016 indicates that the payment module 124 has information to be uploaded to the server system 108 (e.g., transaction information for one or more blocked transactions). In some embodiments, the upload information indicator 1016 triggers the mobile device 104 to immediately connect to the payment module 124 (e.g., if the payment module 124 has blocked transaction information to be uploaded to the server system 108). In some embodiments, one or more status flags 1008 indicate the status of the automated retail machine 122, including one or more error indicators 1018 (e.g., indicating that the bill and/or coin acceptor of the automated retail machine 122 is experiencing a jam, an error code, or a malfunction), a currency level indicator 1020 (e.g., indicating that the bill and/or coin acceptor storage level of the automated retail machine 122 is full or empty), and/or an inventory level indicator 1022 (e.g., indicating one or more products of the automated retail machine 122). In some embodiments, one or more status flags 1008 are error codes issued by the automated retail machine 122 on the MDB.

[0097] In some embodiments, the zone criteria information 1010 defines authorized zone criteria 1024 (e.g., a baseline authorized zone threshold indicating a baseline RSSI that the mobile device 104 (or application) is required to observe until it enters an authorized zone of the payment module 124) and/or a payment zone criteria 1026 (e.g., a baseline payable zone threshold indicating a baseline RSSI that the mobile device 104 (or application) is required to observe until it enters a payment zone of the payment module 124). In some embodiments, the baseline authorized zone threshold and the baseline payment zone threshold are default values determined by the server system 108 or stored as variables by the application, where the authorized zone criteria 1024 and the payment zone criteria 1026 are offsets to compensate for the strength and/or reception of the short-range communication capabilities of the payment module 124 (e.g., a BLE radio/transceiver). Alternatively, the zone criteria information 1010 includes a variance between the baseline authorized zone threshold and the baseline payment zone threshold. Thus, the mobile device 104 (or application) determines the baseline authorized zone threshold and the baseline payment zone threshold based on the variance and default value of either the baseline authorized zone threshold or the baseline payment zone threshold. For example, the variance may indicate -10 db, and the default baseline payment zone threshold is -90 db; therefore, the baseline authorized zone threshold is -80 db. Continuing with this example, after determining the baseline authorized zone threshold and the baseline payment zone threshold, the mobile device 104 (or application) may further adjust the authorized zone threshold and/or the payment zone threshold based on the strength and/or reception of its short-range communication capabilities (i.e., BLE radio/transceiver).

[0098] FIG. 10B is a block diagram of an authorization request 1030 sent by a mobile device 104 to a system server 108 (e.g., at step 804 of process 800 of FIG. 8) according to some embodiments. In some embodiments, the authorization request 1030 includes at least a device ID 1002; a user ID 1034; and an authorization code 1004.

[0099] In some embodiments, the device ID 1002 is a unique identifier corresponding to the payment module 124 that broadcast the information packet 1000 including the authorization code 1004.

[0100] In some embodiments, 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 embodiments, the user ID 1034 is associated with a user account logged into a user application on the mobile device 104.

[0101] In some embodiments, the authorization code 1030 is the authorization code 1004 included in the information packet 1000 broadcast by the payment module 124.

[0102] FIG. 10C 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 process 800 of FIG. 8 ) according to some embodiments. In some embodiments, the server system 108 generates the authorization grant token 1040 pursuant to 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 or her account at the payment processing system. In some embodiments, the authorization grant token 1040 includes at least the device ID 1002; the user ID 1034; the authorization amount 1046; (optionally) an expiration date 1048; and (optionally) the authorization code 1004. In some embodiments, the authorization grant token 1040 is encrypted with a shared secret key corresponding to the payment module 124.

[0103] In some embodiments, the device ID 1002 is a unique identifier corresponding to the payment module 124 that broadcast the information packet 1000 including the authorization code 1004.

[0104] In some embodiments, 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.

[0105] In some embodiments, the authorization amount 1046 indicates a maximum amount that the user of the mobile device 104 is authorized to transact using the authorization acceptance token 1140. For example, the authorization amount 1046 may be predetermined by the user of the mobile device 104 or by the server system 108 based on a daily spending limit, based on the user's total account balance, or based on the user's risk profile associated with the user ID 1034.

[0106] In some embodiments, the expiration date 1048 indicates an offset to the time that the payment module 124 holds the authorization acceptance token 1040 valid for initiating a transaction with the automated retail machine 122 associated with the payment module 124. For example, the expiration date 1048 depends on the history and credit of the user of the mobile device 104, or on a period of time predetermined by the user of the mobile device 104.

[0107] In some embodiments, the authorization grant token 1040 further includes the authorization code 1004 included in the authorization request 1030. In some embodiments, if the authorization code 1004 is a hash value, the server system 108 encrypts the authorization grant token 1040 including the hash value with a shared secret encryption key associated with the payment module 124. The mobile device 104 then transmits the authorization grant token 1040 to the payment module 124 after detecting the trigger condition, and the payment module 124 decrypts the authorization grant token 1040 using a private 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 with a valid (i.e., unexpired, unused) hash value already broadcast (e.g., a stored authorization code) to determine the validity of the hash value (known only to the payment module 124).

[0108] FIG. 10D is a block diagram of transaction information 1050 generated by the payment module 124 (e.g., at step 904 of process 900 of FIG. 9) according to some embodiments. In some embodiments, the transaction information 1050 includes a transaction ID 1052 for the respective transaction; a device ID 1054; a user ID 1056; (optionally) an authorization code 1058; transaction status information 1060; transaction details 1062; and miscellaneous information 1064. In some embodiments, the transaction information 1050 is encrypted with a shared secret key corresponding to the payment module 124.

[0109] In some embodiments, transaction ID 1052 is a unique identifier corresponding to each transaction. In some embodiments, transaction ID 1052 is encoded or associated with the time and/or date that each transaction occurred.

[0110] In some embodiments, the device ID 1054 is a unique identifier corresponding to the payment module 124 that performed the respective transaction.

[0111] In some embodiments, the user ID 1056 is an identifier associated with the user of the mobile device 104 that initiated the respective transaction.

[0112] In some embodiments, the authorization code 1058 corresponds to the original authorization code (e.g., authorization code 1004, FIGS. 10A-10C) and/or authorization grant token (e.g., authorization grant token 1040, FIG. 10C) used to initiate the respective transaction. In some embodiments, the authorization code 1056 is encrypted with a unique encryption key corresponding to the payment module 124.

[0113] In some embodiments, the transaction status information 1060 includes an indication of whether the respective transaction was completed, not completed, or aborted. For example, the respective transaction is incomplete if a jam occurs in the automated retail machine 122 and the user does not receive the product associated with the respective transaction. For example, the respective transaction is aborted if the user walks away from the automated retail machine 122 after money for the respective transaction is deposited. In another example, the respective transaction is aborted if the respective transaction times out after a predetermined period of time because the user was unable to select a product in the automated retail machine 122. In another example, the respective transaction is aborted if the user activates a bill or coin return mechanism of the automated retail machine 122.

[0114] In some embodiments, the transaction details 1062 indicate the amount of each transaction or the amount of each of multiple transactions (e.g., in a multi-sale scenario). In some embodiments, the transaction details 1062 also indicate other information related to each transaction, such as the item provided by the automated retail machine 122 and the type of transaction (e.g., coin, note, credit card, manual mode, hands-free mode, etc.).

[0115] In some embodiments, the miscellaneous information 1064 includes other information related to the payment module 124 and/or the automated retail machine 122 to which the payment module 124 is coupled. For example, the miscellaneous information 1064 includes a validation request to the server system 108 to implement new firmware. In another example, the miscellaneous information 1064 includes transaction information from one or more previously blocked transactions. In another example, the miscellaneous information 1064 includes transaction information of one or more past hard currency transactions and/or other cashless transactions (e.g., paid by credit card or bank card at the automated retail machine 122). In another example, the miscellaneous information 1064 includes inventory information regarding one or more products of the automated retail machine 122.

[0116] Attention is now directed to user interface ("UI") embodiments and associated processes that may be implemented on a mobile device 104 having zero or more speakers 1102, zero or more microphones 1104, and a display 1106. For example, the display 1106 may be a touch screen (sometimes referred to herein as a "touch screen display") that is adapted to accept one or more touches and display information (e.g., media content, a website and its web pages, and/or a user interface of an application 326). Figures 11A-11G illustrate exemplary user interfaces for facilitating displaying promotional offers according to some embodiments.

[0117] Although some of the examples that follow are given with reference to input on a touch screen (a combined touch-sensitive surface and display), in some embodiments the mobile device detects input on a touch-sensitive surface that is separate from the display. In some embodiments, the touch-sensitive surface has a major axis that corresponds to a major axis on the display. According to these embodiments, the mobile device detects contact with the touch-sensitive surface at locations that correspond to respective locations on the display. In this manner, user input detected by the mobile device on the touch-sensitive surface is used by the mobile device to operate a user interface on the display of the mobile 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.

[0118] Additionally, while the following examples are given primarily with reference to contacts (e.g., finger input such as finger contacts, finger tap gestures, finger swipe gestures, etc.), it should be understood that in some embodiments, one or more of the above contacts are replaced by input from another input device (e.g., mouse-based, stylus-based, or physical button-based input). For example, a swipe gesture is optionally replaced by a mouse click (e.g., instead of a contact) followed by movement of a cursor along the path of the swipe (e.g., instead of a movement of a contact). As another example, a tap gesture is optionally replaced by a mouse click (e.g., instead of detection of a contact followed by ceasing to detect the contact) while the cursor is over the location of the tap gesture, or by pressing a physical button. Similarly, it should be understood that when multiple user inputs are detected simultaneously, multiple computer mice are optionally used simultaneously, or mice and finger contacts are optionally used simultaneously.

[0119] Although FIGS. 11A-11G illustrate user interfaces 1108 displayed on a respective mobile device 104 (e.g., a mobile phone associated with a user) for an application associated with payment processing system 100, one skilled in the art will appreciate that the user interfaces illustrated in FIGS. 11A-11G may be implemented on other similar computing devices. The user interfaces of FIGS. 11A-11G are used to illustrate the processes described herein, including the methods described with respect to FIGS. 12A-12C. One skilled in the art will appreciate that the following user interfaces are merely exemplary. Furthermore, one skilled in the art will appreciate that additional or fewer affordances and/or user interface elements may actually be used.

11A illustrates a mobile device 104 displaying a transaction initiation screen 1110 for an 8th floor snack machine. In FIG. 11A, the transaction initiation screen 1110 includes a series of indicators 1116 that indicate that "the 8th floor snack machine is one of three automated retail machines for which the user is authorized to initiate a transaction." For example, a user of the mobile device 104 can access a second of the three automated retail machines by making a left-to-right swipe gesture (or alternatively a right-to-left swipe gesture) on the user interface 1108, and can access a first of the three automated retail machines by making a right-to-left swipe gesture (or alternatively a left-to-right swipe gesture) on the user interface 1108. A user of the mobile device 104 can access the application's settings and/or home screen by selecting affordance 1112 (e.g., with a tap gesture) and can refresh the transaction start screen 1110 by selecting affordance 1114 (e.g., with a tap gesture).

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 can initiate a transaction with the 8th Floor Snack Machine by making an upward swipe gesture emanating from area 1120 of the transaction initiation screen 1110. The user of the mobile device 104 can access special promotional offers by selecting (e.g., with a tap gesture) the "Special Offers" area 1122 and can "like" or prefer the 8th Floor Snack Machine by selecting (e.g., with a tap gesture) affordance 1124. FIG. 11A also shows the mobile device 104 detecting contact 1140 at a location corresponding to the "Special Offers" area 1122.

11B illustrates a mobile device 104 displaying a special offers screen 1130 for an 8th floor snack machine. In FIG. 11B, the special offers screen 1130 includes a first region corresponding to "Offer A" 1152 on product A accompanied by image A of product A; a second region corresponding to "Offer B" 1154 on product A accompanied by image A of product A; and a third region corresponding to "Offer C" 1156 on product B accompanied by image B of product B. The special offers screen 1130 also includes a refresh affordance 1151 that, when activated (e.g., via a tap gesture), causes the special offers screen 1130 to be refreshed. In FIG. 11B, none of offers A, B, or C are currently selected. A user of the mobile device 104 can select "Offer A" 1152 by making a gesture (e.g., a tap gesture) on selection affordance 1153. Similarly, a user of the mobile device 104 can select "Offer B" 1154 by making a gesture (e.g., a tap gesture) on selection affordance 1155, or "Offer C" 1156 by making a gesture (e.g., a tap gesture) on selection affordance 1157. A user of the mobile device 104 can also discard or remove any of Offers A, B, or C by making a right-to-left swipe gesture (or a left-to-right swipe gesture in other embodiments) within the corresponding region. FIG. 11B also shows the mobile device 104 detecting a right-to-left swipe gesture within a second region corresponding to "Offer B" 1154 with contact 1160 moving from a first position 1162-a to a second position 1162-b.

[0123] In some embodiments, the special offers screen 1130 further includes a fourth region corresponding to "No Selected Offer." For example, a user of the mobile device 104 may see promotional offers on the special offers screen 1130, but may not want any of the promotional offers to apply to future transactions with the 8th Floor Snack Machine. Thus, the user of the mobile device 104 may select the "No Selected Offer" region (e.g., via a tap gesture), and in response, the mobile device 104 re-displays the transaction initiation screen 1110, as shown in FIG. 11A.

11C shows the mobile device 104 displaying a delete affordance 1164 in a second region corresponding to "Offer B" 1154 in response to detecting the right-to-left swipe gesture in FIG. 11B. 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. FIG. 11C also shows the mobile device 104 detecting contact 1166 at a location corresponding to the delete affordance 1164.

11D illustrates the mobile device 104 ceasing to display "Offer B" 1154 within the special offers screen 1130 in response to detecting a selection of the delete affordance 1164 in FIG. 11C. FIG. 11D also illustrates the mobile device 104 detecting contact 1168 at a location corresponding to the selection affordance 1153 of "Offer A" 1152. Alternatively, in some embodiments, the user of the mobile device may not want to apply the offer to future transactions with the 8th Floor Snack Machine. Thus, the user may select affordance 1112 (e.g., with a tap gesture) or perform a predetermined gesture on the special offers screen 1130 to redisplay the transaction initiation screen 1110 as shown in FIG. 11A.

11E illustrates that selection affordance 1153 is selected in response to detecting a selection of selection affordance 1153 of FIG. 11D. In some embodiments, a transaction with the 8th floor snack machine is automatically initiated in response to detecting a selection of selection affordance 1153 of FIG. 11D. In other embodiments, after detecting a selection of selection affordance 1153 of FIG. 11D, mobile device 104 redisplays transaction initiation screen 1110 (as shown in FIG. 11A) and a transaction with the 8th floor snack machine is initiated in response to detecting an upward swipe gesture emanating from region 1120 of transaction initiation screen 1110.

11F illustrates a mobile device 104 displaying a product code screen 1170 that prompts a user of the mobile device 104 to obtain a product code (e.g., UPC code, SKU, etc.) for product A to verify the "Offer A" 1152 selected in FIG. 11D. 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. In FIG. 11F, a UPC code 1174 (e.g., product code) for product A (e.g., a candy bar) that is within the field of view of the camera of the mobile device 104 is shown in the product code scanner window 1172. For example, the user of the mobile device 104 can capture an image of product A (including the UPC code 1174 currently in the field of view) or scan the UPC code 1174 by tapping in the product code scanner window 1172, issuing an audible command, pressing a predetermined physical button on the mobile device 104, etc. FIG. 11F also shows that the user of mobile device 104 has a prepaid balance of $99.00 due to the purchase of Product A, $1.00 less than the amount shown in FIGS. 11A-11E.

[0128] FIG. 11G shows the mobile device 104 displaying an offer verification screen 1180. In some embodiments, the mobile device 104 displays the offer verification screen 1180 after the user completes a transaction with the 8th floor snack machine and the server verifies the product code information (e.g., the UPC scanned in FIG. 11F). In FIG. 11G, the offer verification screen 1180 indicates that "Offer A" 1152 has been verified and that $0.25 has been credited to the user's balance. FIG. 11G also indicates that the user of the mobile device 104 has a prepaid balance of $99.25 ($0.25 more than the amount shown in FIG. 11G due to the verification of "Offer A" 1152 and the credit of $0.25 for "Offer A" 1152).

[0129] Figures 12A-12C show a flowchart diagram of a method 1200 for providing and processing promotional offers in an automated retail machine according to some embodiments. In some embodiments, the method 1200 is performed by a mobile device having a display, one or more processors, and a memory. For example, in some embodiments, the method 1200 is performed by the mobile device 104 (Figures 1-2) or a component thereof (e.g., the client-side module 102, Figures 1-2). In some embodiments, the method 1200 is controlled by instructions 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.

[0130] In some embodiments, the payment processing system 100 (FIG. 1) includes a mobile device 104 that performs the method 1200, a server system 108, and a payment module 124 coupled to an automated retail machine 122. An instance of the client-side module 102 (e.g., as an application) runs on the mobile device 104 as a foreground or background process that accesses and communicates with other devices in the payment processing system 100 (e.g., the server 108 and the payment module 124). The server 108 manages the payment processing system 100, and in some cases is associated with the entity that provides, operates, and/or manufactures the payment module 124.

[0131] In some embodiments, prior to displaying one or more promotional offers, the mobile device: obtains an information packet broadcast by a payment module associated with the automated retail machine, the information packet including at least an authorization code and a unique identifier corresponding to the payment module; transmits a transaction authorization (including the authorization code and the unique identifier corresponding to the payment module) request to the server; and receives (1202) authorization information from the server in response to the transaction authorization request, the authorization information including an authorization grant token for initiating a transaction with the automated retail machine associated with the payment module and one or more promotional offers from the server. As discussed in process 800, the mobile device 104 or a component thereof (e.g., the broadcast acquisition module 230, FIG. 2) receives the information packet broadcast by the payment module 124 including at least an authorization code and an identifier associated with the payment module 124. The mobile device 104 or a component thereof (e.g., the transaction authorization module 232, FIG. 2) then transmits the authorization code to the server 108 to pre-authorize the transaction with the automated retail machine 122 to which the payment module 124 is associated. Pursuant to a determination that the server 108 has pre-authorized the potential transaction, the mobile device 104, or a component thereof (e.g., transaction authorization module 232, FIG. 2), receives an authorization grant token for conducting the transaction with the automated retail machine 122. In some embodiments, the mobile device 104 stores the authorization grant token (e.g., in user data 265, FIG. 2) until a trigger condition for initiating the transaction with the automated retail machine 122 is detected (e.g., by trigger detection module 236, FIG. 2). In some embodiments, the trigger condition is satisfied when the mobile device 104 detects a user input on a user interface displayed by the mobile device 104. For example, referring to FIG. 11A, a transaction is initiated between a user of the mobile device 104 and the 8th floor snack machine when the mobile device 104 detects an up swipe gesture emanating from area 1120 of user interface 1108. In another example, referring to FIG. 11D, a transaction is initiated between a user of the mobile device 104 and the 8th floor snack machine when the mobile device 104 detects a selection of Offer A 1152 via contact 1166.

[0132] In some embodiments, the mobile device further includes a first transceiver associated with a short-range communication protocol and a second transceiver associated with a long-range communication protocol (1204). The mobile device communicates with the payment module via the first transceiver and with the server via the second transceiver. For example, the short-range communication protocol is BLE, NFC, etc., and the long-range communication protocol is GSM, CDMA, Wi-Fi, etc.

[0133] The mobile device displays one or more promotional offers on the display (1206). In some embodiments, the mobile device 104 displays only promotional offers for products for which the user has sufficient balance. For example, a soda costs $2.00 and has a promotion for $0.50 off, but the user has only a balance of $1.00. In this example, the mobile device refrains from displaying the soda promotion. FIG. 11B illustrates a mobile device 104 displaying a special offers screen 1130 for, for example, an 8th floor snack machine. In FIG. 11B, the special offers screen 1130 includes a first region corresponding to "Offer A" 1152 on product A accompanied by image A of product A; a second region corresponding to "Offer B" 1154 on product A accompanied by image A of product A; and a third region corresponding to "Offer C" 1156 on product B accompanied by image B of product B. Alternatively, in some embodiments, each of the one or more promotional offers is automatically applied after the user completes the transaction, and the mobile device prompts the user to provide a product code corresponding to each promotion. In some embodiments, one or more advertisements are displayed in place of the one or more selectable promotional offers.

[0134] In some embodiments, one of the one or more promotional offers is a "reward" for a product or service not related to the automated retail machine 122 (i.e., an out-of-band offer). For example, if the user purchases a particular product, the user will receive a link via email for a free download (e.g., a song, video, etc.), an in-app credit (e.g., $2.00 for purchases in a digital media marketplace, or $2.00 credit for in-app purchases of games), and so on. This may or may not require product verification. For example, buy any product from this automated retail machine now, and get a link via email or text to a $1.00 off coupon from the retailer for a case of soda. In some embodiments, the offer may be an "add-on sale" that is an out-of-band offer. For example, buy XYZ cola now, and get a case of XYZ cola from the store for only $1.50 with a coupon mailed to your email address. In another example, buy ABC chips now, and get a special discount offer to buy cool t-shirts for $5.00. In this example, $5.00 is added to the transaction price and the user is sent an email regarding redemption and shipping of the cool t-shirt.

[0135] In some embodiments, the user can abandon or delete the offer, and the mobile device 104 transmits this information to the server 108 for analysis purposes. In one example, FIG. 11C illustrates the mobile device 104 displaying a delete affordance 1164 in the second region corresponding to "Offer B" 1154 in response to detecting a right-to-left swipe gesture in FIG. 11B. Continuing with the example, FIG. 11D illustrates the mobile device 104 ceasing to display "Offer B" 1154 in the special offers screen 1130 in response to detecting a selection of the delete affordance 1164 in FIG. 11C.

[0136] In some embodiments, one or more promotional offers are identified (1208) based on a unique identifier corresponding to the payment module, at least one of a current time and date, a location of the automated retail machine, a location of the mobile device, and at least one of a unique identifier corresponding to a user of the mobile device. In some embodiments, the server 108 or a part thereof (e.g., the offer determination module 328, FIG. 3) determines/identifies the one or more promotional offers based on a current time/date, a current location, a device ID associated with the payment module, a user ID associated with a user of the mobile device, etc. In some embodiments, the mobile device 104 or a part thereof (e.g., the offer module 234, FIG. 2) determines/identifies the one or more promotional offers from a set of pre-stored offers based on a current time/date, a current location, a device ID associated with the payment module, a user ID associated with a user of the mobile device, etc. For example, the mobile device 104 identifies one or more promotional offers from an offer database 266 that includes offers previously sent by the server 108 to the application (e.g., as part of an update).

[0137] In some embodiments, promotional offers are identified based on products stored in the automated retail machine 122 or past behavior (e.g., previous offers selected by the user, previous offers removed by the user, previous offers not selected by the user, etc.). For example, a "side-by-side" is a separate snack and soda machine. 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 allow cross-promotion between the soda distributor and the snack distributor). Alternatively, the offer may be based on offers that the user did not select from the soda machine or that were previously actively removed.

[0138] In some embodiments, the server 108 and the provider of the payment module 124 manage a promotional marketplace to facilitate promotional offers by product manufacturers and distributors and also to promote competition among various product manufacturers and distributors. For example, a product distributor or manufacturer may run a promotional offer for $0.25 off a particular item at all applicable local junior colleges in California on Thursdays from 2:00pm to 4:00pm PDT. In another example, a product distributor or manufacturer may run a promotional offer for 50% off a product on the day the product expires (e.g., to sell perishable sandwiches, etc.) at all applicable automated retail machines. In some embodiments, cross or combined promotional offers may also be run where a user receives a credit (e.g., a refund) for the purchase of a particular beverage/snack combination (where the beverage and snack are each manufactured or distributed by a different entity).

[0139] In some embodiments, promotional offers (effectively subsidies) on all items in automated retail machines on the entity's premises are available to select users only. For example, all lawyers and staff at a law firm are given a subsidized rate on snacks, but the cleaners do not benefit from said subsidized rate. In another example, all full-time employees are given a subsidized rate on snacks, but the temp workers do not benefit from said subsidized rate.

[0140] In some embodiments, variable pricing is implemented, whereby the base price of an item changes and promotional offers can be added on top of the variable pricing scheme. For example, a distributor may wish to reduce the price on all items in the applicable machine during off-peak hours (e.g., 9:00 PM to 6:00 AM). Thus, after the transaction is completed, the server 108 charges the user only the reduced price, and after the server processes and accounts for the transaction, the transaction approval information displayed on the mobile device 104 will indicate that the user was charged only the reduced price and not the price shown on the automated retail machine 122.

[0141] The mobile device detects (1210) a user input selecting a respective promotional offer of one or more promotional offers. For example, the user input may be a touch input, a voice input, or the like. FIG. 11D illustrates the mobile device 104 detecting a selection of the selection affordance 1153 of, for example, "Offer A" 1152, and FIG. 11E illustrates that the selection affordance 1153 is selected in response to detecting the selection of the selection affordance 1153 of FIG. 11D. In some embodiments, each promotional offer is a negative promotional offer, such as a donation to AIDS research that adds the selected amount to the user's next transaction. Alternatively, in some embodiments, each promotional offer is a negative promotional offer where the transaction is rounded to the nearest dollar, where the added amount is donated to the Cancer Research Foundation.

[0142] The mobile device initiates (1212) the execution of a transaction with the automated retail machine coupled to the payment module, where the transaction corresponds to a purchase of a product stocked by the automated retail machine. In some embodiments, the transaction is initiated in response to selection of a respective promotional offer (i.e., a one-click transaction initiation process). For example, the transaction with the 8th floor snack machine is automatically initiated in response to detecting a selection of the selection affordance 1153 of FIG. 11D. In other embodiments, after the user selects an offer, the user performs an action to initiate a transaction with the automated retail machine (i.e., a two-step transaction initiation process). For example, after detecting a selection of the selection affordance 1153 of FIG. 11D, the mobile device 104 redisplays the transaction initiation screen 1110 (as shown in FIG. 11A), and the transaction with the 8th floor snack machine is initiated in response to detecting an upward swipe gesture emanating from the area 1120 of the transaction initiation screen 1110.

[0143] In some embodiments, the execution of a transaction with an automated retail machine coupled to a payment module is initiated by sending an authorization grant token including an authorization code included in a broadcast information packet to the payment module (1214). In some embodiments, the act of initiating a transaction includes the mobile device 104 or a component thereof (e.g., transaction initiation module 238, FIG. 2) sending a stored authorization grant token to the payment module 124 for payment, and the user manually selecting a product using a user interface of the automated retail machine 122. Thus, the automated retail machine 122 does not know anything about the promotional offer selected, the automated retail machine 122 only knows that the user submitted a payment for the selected promotional offer. For example, the automated retail machine 122 returns the transaction and product information passed to the mobile device 104 by the payment module 124, but the automated retail machine 122 cannot determine or state in any way whether the product corresponds to the offer. For example, the transaction completion notification indicates that "E3 sold for $1.00".

[0144] The mobile device receives a transaction completion notification from the payment module indicating that a product corresponding to the respective selected promotional offer has been sold by the automated retail machine (1216). In some embodiments, the mobile device 104 or a component thereof (e.g., transaction completion notification receiving module 240, FIG. 2) receives a transaction completion notification (e.g., transaction status information, transaction detail information, other miscellaneous information related to the respective payment module 124 and/or the automated retail machine 122 to which the respective payment module 124 is coupled, etc.) from the payment module 124 after the user manually selects the product using a user interface of the automated retail machine 122. In some embodiments, the transaction completion notification includes information related to the goods/services associated with the transaction, the current inventory of the automated retail machine 122, information related to one or more previous cash transactions, information related to one or more blocked transactions processed by the payment module 124, and/or other information related to the automated retail machine 122, such as an error or maintenance status. In some embodiments, the payment module 124 sends an error message instead of a transaction completion notification if the transaction is interrupted or an error occurs during the transaction (such as unavailability of the requested item/service or a sales jam).

[0145] In response to receiving the transaction completion notification, the mobile device provides a prompt to the user of the mobile device to obtain the product code of the sold product to verify the respective promotional offer (1218). In some embodiments, the mobile device 104 or a component thereof (e.g., product code processing module 242, FIG. 2) displays a scanning interface to capture the product code of the sold item after receiving the transaction completion notification. FIG. 11F shows the mobile device 104 displaying a product code screen 1170 that prompts the user of the mobile device 104 to obtain the product code (e.g., UPC code, SKU, etc.) of product A to verify the "Offer A" 1152 selected in FIG. 11D, for example. 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. In FIG. 11F, the UPC code 1174 of product A (e.g., a candy bar) that is within the field of view of the camera of the mobile device 104 is shown in the product code scanner window 1172. For example, a user of the mobile device 104 can capture an image of product A (including UPC code 1174 in the current field of view) or scan UPC code 1174 by tapping in the product code scanner window 1172, issuing an audible command, pressing a predetermined physical button on the mobile device 104, etc.

[0146] In other embodiments, the mobile device 104 or a component thereof (e.g., product code processing module 242, FIG. 2) 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 a product code for the item being sold. In other embodiments, the mobile device 104 or a component thereof (e.g., product code processing module 242, FIG. 2) provides an audible sound, a voice prompt, or a series of haptic/tactile vibrations prompting the user of the mobile device 104 to enter or otherwise obtain a product code for the item being sold.

[0147] The mobile device obtains (1220) a product code for the sold product. For example, the user enters the barcode character by character, scans the barcode, or simply captures an image of the barcode. In some embodiments, the mobile device 104 or a component thereof (e.g., product code processing module 242, FIG. 2) receives the product code.

[0148] In some embodiments, obtaining the product code further includes capturing an image of the product including the product code and extracting the product code from the captured image (1222). In some embodiments, obtaining the product code further includes scanning the product code of the product with a scanner unit of the mobile device (1224). For example, a user of the mobile device 104 can access a product code capture plug-in (e.g., product code processing module 242, FIG. 2) from within an application associated with the payment processing system 100 that allows the user to capture an image of a product having a product code in view or scan the product code of the product. In this example, the mobile device 104 extracts the product code from the captured image and transmits the extracted product code to the server 108, or alternatively, the mobile device 104 transmits the captured image to the server 108 from which the product code is extracted. In another example, a user of the mobile device 104 can manually enter the product code (e.g., via a virtual keypad) from within the application or via a website associated with the payment processing system 100.

[0149] After obtaining the product code, the mobile device transmits the product code to the server (1226). In response to transmitting the product code, the mobile device: receives promotional verification information from the server; and displays the promotional verification information on the display indicating whether the respective promotional offer was verified. In some embodiments, the mobile device 104 or a component thereof (e.g., product code processing module 242, FIG. 2) either verifies the obtained product code or transmits the obtained product code to the server 108 for verification. In some embodiments, the mobile device 104 or a component thereof (e.g., information relay module 244, FIG. 2) transmits a transaction completion notification or a portion thereof to the server 108 regardless of whether the user complies with the prompts and whether the mobile device 104 ultimately obtains the product code. In some embodiments, the server 108 determines whether the terms for the respective promotional offer are based on the transaction and the product code. For example, the server 108 determines whether the appropriate product code has been obtained for each promotional offer, whether each promotional offer has expired, whether the user has met a "buy N get 1 free" condition, whether the user has met the conditions of a cross promotion, etc. In some embodiments, the offers are verified by the server 108 and applied to the user account.

[0150] In some embodiments, the mobile device 104 or a component thereof (e.g., offer verification module 246, FIG. 2) receives and displays promotion verification information. For example, the promotion verification information indicates whether the offer was verified and an updated user balance/transaction list. FIG. 11G, for example, shows the mobile device 104 displaying an offer verification screen 1180 indicating that "Offer A" 1152 was verified and that $0.25 was credited to the user's balance. FIG. 11G also indicates that the user of the mobile device 104 has a prepaid balance of $99.25 ($0.25 more than the amount shown in FIG. 11G due to the verification of "Offer A" 1152 and the crediting of $0.25 for "Offer A" 1152). For example, if a user gets a 5th product for free with a purchase and the product that was the subject of the instant transaction was the only product purchased, the promotion validation information indicates that "user must buy 3 or more products before getting the free product." In some embodiments, the promotion validation information includes a coupon for a product or service not related to the automated retail machine 122. For example, the user is emailed a $5 off coupon to an amusement park for purchasing a soda.

[0151] In some embodiments, after obtaining the product code, the mobile device determines (1228) whether the predetermined time period has expired. Pursuant to a determination that it has expired, the mobile device provides a notification to the user of the mobile device indicating that the respective promotional offer has expired. Pursuant to a determination that it has not expired, the mobile device transmits the product code to the server. In some embodiments, the predetermined time period corresponds to the time between (A) the time of initiating the fulfillment of the transaction or waiting for the input of the product code and (B) the time of obtaining the product code or some other time period. For example, the mobile device 104 must receive the product code within 5 minutes of a prompt or within 5 minutes of the initiation of the transaction. In some embodiments, this may occur after several hours or even days. In some embodiments, a predetermined proximity between a first location where the transaction is initiated and a second location where the product code is obtained is used in addition to or instead of the predetermined time period.

[0152] In some embodiments, an application associated with the payment processing system 100 has a coupon plug-in that allows a user of the mobile device 104 to scan a coupon after completing a transaction for a product and also scan the product code of the product to obtain a subsequent refund for the transaction.

[0153] In some embodiments, the promotional validation information indicates the price of the product after application of the respective promotional offer (1230). For example, the mobile device 104 displays the total amount that will be 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. FIG. 11G, for example, indicates that the user of the mobile device 104 has a prepaid balance of $99.25 ($0.25 more than the amount shown in FIG. 11G due to the validation of "Offer A" 1152 and the crediting of $0.25 for "Offer A" 1152).

[0154] In some embodiments, the mobile device transmits (1232) a transaction completion notification to the server. In some embodiments, the mobile device 104 or a component thereof (e.g., information relay module 244, FIG. 2) transmits the transaction completion notification (e.g., transaction status information, transaction detail information, other miscellaneous information regarding the respective payment module 124 and/or the automated retail machine 122 to which the respective payment module 124 is coupled, etc.) or a portion thereof to the server 108 prior to transmitting the product code or together with the product code. In some embodiments, the transaction completion notification or a portion thereof is transmitted to the server 108 regardless of whether the user complies with the prompts and whether the mobile device ultimately obtains the product code.

[0155] It should be understood that the particular order in which the operations of FIGS. 12A-12C are described is merely exemplary, and is not intended to indicate that the order described is the only order in which the operations may be performed. Those skilled in the art will recognize various ways to reorder the operations described herein. In addition, it should be noted that other process details described herein (e.g., processes 800 and 900) with respect to other methods and/or processes described herein may also be applied in a manner similar to method 1200 described above with respect to FIGS. 12A-12C.

[0156] Although specific embodiments have been described above, it will be understood that no limitation of application to those specific embodiments is intended. On the contrary, those applications include alternatives, modifications, and equivalents falling within the spirit and scope of the appended claims. Numerous specific details are described in order to provide a thorough understanding of the subject matter presented herein. However, it will be apparent to those skilled in the art that the subject matter may be practiced without these specific details. In other instances, well-known methods, procedures, components, and circuits have not been described in detail so as not to unnecessarily obscure aspects of the embodiments.

Asynchronous Mobile Payments for Parallel Transactions
[0157] The embodiments 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. In some embodiments, a merchant device (FIG. 13, 1304) executes a merchant app (FIG. 13, 1302), one or more consumer mobile devices 104 execute consumer apps 102, and one or more servers 108 interact with both the merchant and consumer apps (e.g., over a long-range network connection 110 such as the Internet or a wireless mobile network). In this system, the merchant and consumer apps are in close proximity to each other such that they are within range of a local communications network 111 (e.g., wifi, Bluetooth, or IEEE 802.15.4 network). In some embodiments, 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., the operations described with reference to any of Figures 8-12, the operations associated with the mobile device 104 described above with reference to Figure 1, and/or the operations associated with the payment module 124 described above with reference to Figure 1).

[0158] In some embodiments, the merchant app is ready while idle (e.g., while in sleep or background mode) and therefore does not require special instruction to initiate payment processing (e.g., by broadcasting a merchant identifier). In some embodiments, the merchant app broadcasts its unique identifier over a short-range local radio. A consumer app in the vicinity of the merchant app (see Figures 17-18) picks up the broadcasted unique identifier, which the consumer app then passes to the server. The server returns details of the merchant, including but not limited to the merchant's name, logo, photo, address, phone, email, available offers, any pre-set transaction amount (e.g., the amount required by the merchant to complete the proposed transaction), and rewards or loyalty points.

[0159] In some embodiments, merchant information is presented to the consumer in the consumer app (FIG. 23A). If multiple merchants are in the vicinity, the consumer app presents all available merchants to allow the consumer to select the merchant with whom they would like to transact in person (FIG. 23B). The available merchant list is presented in the consumer app and in some embodiments may be sorted according to distance to the merchant based on short-range wireless communication signal strength. Sorting may also be based on set location (e.g., GPS) coordinates or set from a server configuration for each merchant's sort order.

[0160] The consumer selects a desired merchant and then enters an amount to pay the selected merchant or selects a pre-filled amount (FIG. 24). In some embodiments, the consumer enters the amount in a free form field (FIG. 19). In some embodiments, one or more amounts are pre-filled and have already been entered by the merchant. In some embodiments, the pre-filled amount is included in the initial broadcast (the broadcast that includes the unique merchant identifier). Alternatively, the pre-filled amount is included in a broadcast from the merchant that follows the initial broadcast (FIG. 20). Alternatively, the pre-filled amount is provided by the server (FIG. 21). The consumer may also optionally view and select from available offers from the merchant. The consumer may also optionally enter a "tip" or gratuity amount and a payment description.

[0161] Upon entering the required information, the consumer can initiate a payment to the selected merchant (e.g., FIG. 24, “Send Payment”). The payment is sent by the consumer app to the server. Notably, in some embodiments, the payment is not sent directly to the merchant app over the short range communications network 111. Rather, the consumer app sends the payment to the server over the long range communications network 110.

[0162] 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.

[0163] In some embodiments, there are multiple consumers (using multiple respective consumer devices 104) sending payments in parallel to the same merchant. In some embodiments, the broadcast from the merchant app (including the merchant's unique identifier) is not encrypted and can therefore be picked up by any consumer app within short range wireless communication proximity of the merchant device. If each consumer device initiates the payment on its own consumer app, it can send payments simultaneously based on the server's requirements for being able to process multiple requests simultaneously (e.g., based on handling server bandwidth limitations).

[0164] In some embodiments (FIG. 20), the merchant enters the amount to be charged into the merchant app (FIG. 25A). This amount is then broadcast over short-range radio along with the unique identifier or in a later broadcast. The consumer app picks up this amount from the broadcast and pre-fills this amount in the consumer app (e.g., in the "Amount" field of FIG. 24A) to eliminate the consumer effort of having to enter this amount and/or to limit the consumer from sending a different amount. Pre-filling the amount field also minimizes errors in entering the amount due by the merchant rather than the consumer and ensures that the amount is correct. The consumer may optionally add an additional amount for a gratuity.

[0165] In some embodiments (FIG. 21), the merchant configures the preset amount on the server. The preset amount is then passed back from the server to the consumer app. Neither the merchant nor the consumer enters the preset amount. The consumer selects from a list of amounts to send (FIG. 26B).

[0166] In some embodiments, payment processing does not occur locally; rather, payment processing occurs remotely on a server, and only confirmations or notifications are sent back to the merchant and consumer apps. Thus, no confidential information (such as credit card numbers) is sent by the consumer app to the merchant app, thereby protecting the consumer's privacy and providing a more secure platform for conducting transactions.

[0167] In some embodiments, a merchant may have more than one unique identifier pointing to the same merchant record, or may have more than one unique identifier pointing to multiple merchant records. The unique identifiers do not need to be fixed and may be changed on demand or automatically via a schedule.

[0168] For embodiments involving pre-set payment amounts on a server, the merchant app may act as a beacon (in addition to or as an alternative to being implemented as a smartphone or other type of mobile device) that provides information to any compatible consumer app within range of the beacon that enables the consumer app to make such payments on the server.

[0169] In some embodiments, the server may send a confirmation notification to the merchant via a separate device (other than the merchant app), such as a smartwatch or other device owned (or otherwise used) by the merchant.

[0170] In some embodiments, the merchant may respond back to the consumer with a message, such as a "thank you" message (FIG. 22). In some embodiments, the merchant app sends the message to a server, which forwards the message to the consumer app. Alternatively, the merchant app sends the message directly to the consumer app.

[0171] In some embodiments, the server sends a detailed receipt to the consumer app based on the items, quantities, and/or amounts involved in the completed transaction.

[0172] FIG. 13 is a block diagram of a payment processing system 1300 according to some embodiments. The payment processing system 1300 includes a consumer application 102 (corresponding to the client-side module 102 of FIG. 1) executing on a mobile device 104, a merchant application 1302 executing on a merchant device 1304, and a server system 108 (as described with reference to the server system 108 of FIG. 1). In some embodiments, the merchant device 1304 is a mobile device. Alternatively or additionally, one or more of the merchant devices 1304 are point-of-sale machines (e.g., electronic payment processing systems) that do not take on a mobile device form factor. In some embodiments, the payment module 124 is an example of a merchant device 1302 and implements the merchant application 1302 in the same or similar manner.

[0173] The consumer application 102 provides the consumer side functionality of the payment processing system 1300 and communication with both the server side module 106 and the merchant application 1302. In some embodiments, the 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, etc.) over 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 Communication (NFC), BLUETOOTH, BLUETOOTH Low Energy (BLE), etc.) over one or more short range networks 111. The server-side module 106 provides the server-side functionality of the payment processing system 1300 for any number of consumer modules 102 and merchant modules 1302, each of which resides on a mobile device 104 or 1304, respectively.

[0174] Examples of mobile devices 104, 1304 include, but are not limited to, handheld computers, wearable computing devices, personal digital assistants (PDAs), tablet computers, laptop computers, desktop computers, cellular telephones, smart phones, Enhanced General Packet Radio Service (EGPRS) mobile phones, media players, navigation devices, game consoles, televisions, remote controls, point-of-sale (POS) terminals, in-vehicle computers, electronic book readers, or any combination of two of these or other data processing devices.

[0175] Examples of the one or more networks 110 include a local area network (LAN) and a wide area network (WAN) such as the Internet. The 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.

[0176] The server system 108 is implemented on a distributed network of one or more standalone data processing devices or computers. In some embodiments, the server system 108 also employs various virtual devices and/or services of a third party service provider (e.g., a third party cloud service provider) to provide the underlying computational and/or infrastructure resources of the server system 108. In some embodiments, 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 or other data processing devices.

[0177] The payment processing system 1300 shown in FIG. 1 includes both a client-side portion (e.g., consumer modules 102, 1302) and a server-side portion (e.g., server-side module 106). In some embodiments, data processing is implemented as a standalone application installed on the mobile device 104 and/or 1304. In addition, the division of functionality between the client and server portions of the payment processing system 1300 may vary in various embodiments. For example, in some embodiments, the consumer and merchant modules 102 and/or 1302 provide only user-directed input and output processing functions and delegate all other data processing functions to a back-end server (e.g., server system 108). While many aspects of the present technology have been described in terms of server system 108, corresponding actions taken by the mobile device 104 and/or 1304 will be apparent to one of ordinary skill in the art without creative effort. Additionally, some aspects of the technology may be performed by the server system 108, by the mobile devices 104 and/or 1304, or by the server system 108 and the mobile devices 104 and/or 1304 in cooperation.

[0178] FIG. 14 is a block diagram of a merchant device 1304 associated with a merchant, according to some embodiments. The merchant device 1304 typically includes one or more processing units (CPUs) 1402, two or more communication devices 1404, memory 1406, and one or more communication buses 1408 for interconnecting these components (sometimes referred to as a chipset). The two or more communication devices 1404 include a first transceiver associated with a short-range communication protocol (e.g., NFC, BLE, etc.) and a second transceiver associated with a long-range communication protocol (e.g., GSM, CDMA, Wi-Fi, etc.). The merchant device 1304 also includes a user interface 1410. The user interface 1410 includes one or more output devices 1412 (including one or more speakers and/or one or more image displays) that enable presentation of media content (e.g., text, images, audio, video, etc.). 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 capture camera or other input buttons or controls. Additionally, in some embodiments, the mobile device 1304 uses a microphone and voice recognition or a camera and gesture recognition to complement or replace a keyboard. In some embodiments, the mobile device 1304 optionally includes one or more sensors 1415 that provide contextual information regarding the current state of the merchant device 1304 or environmental conditions associated with the merchant device 1304. The one or more sensors 1415 include, but are not limited to, one or more microphones, one or more cameras, ambient light sensors, one or more accelerometers, one or more gyroscopes, temperature sensors, one or more motion sensors, one or more biometric/biological sensors, and the like. In some embodiments, the merchant device 1304 optionally includes a location detection device 1417, such as a GPS (Global Positioning Satellite) receiver or other geographic location receiver, for determining the location of the merchant device 1304.

[0179] Memory 1406 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. Memory 1406 optionally includes one or more storage devices located remotely from the one or more processing units 1402. Memory 1406, or alternatively the non-volatile memory in memory 1406, includes a non-transitory computer-readable storage medium. In some embodiments, memory 1406 or the non-transitory computer-readable storage medium of memory 1406 stores the following programs, modules, data structures, or a subset or superset thereof:
• An operating system 1416 that contains procedures for handling various basic system services and for performing hardware dependent tasks;
• A communications module 1418 for sending and receiving signals to other devices (e.g., the server system 108 and the consumer module 102) via two or more communications devices 1404;
a presentation module 1420 to enable presentation of information at the merchant device 1304 via one or more output devices 1412 (e.g., displays, speakers, etc.) associated with the user interface 1410 (e.g., user interface for applications 1426, or applications, widgets, websites and their web pages and/or games, audio and/or video content, text, etc. associated with the merchant module 1302);
an input processing module 1422 for detecting one or more user inputs or interactions from one or more input devices 1414 and interpreting the detected inputs or interactions;
• a web browser module 1424 for navigating, requesting (e.g., via HTTP), and displaying websites and their web pages;
one or more applications 1426 (e.g., games, application marketplaces, payment platforms, and/or other web or non-web based applications) for execution by the merchant device 1304;
A merchant module 1302 that provides merchant side data processing and functionality for the payment processing system 1300, including but not limited to the following:
An asynchronous payment acceptance module 1450 that provides the merchant side payment functionality of the payment processing system 1300, including but not limited to the following:
a broadcast module 1452 for broadcasting an information packet to zero or more consumer devices 104 within a communication range (i.e., BLE range) of the merchant device 1304, the information packet including at least a unique identifier (e.g., device ID) corresponding to the merchant device 1304 and, in some embodiments, a payment amount associated with the proposed in-person transaction;
a customer amount module 1454 for accepting a client payment amount for the proposed transaction via the input device 1414 (e.g., using a free form as in FIG. 25A or a menu of options as in FIG. 25B) and transmitting the custom payment amount to the consumer device 104 for use in the proposed transaction by using the short-range communication device 1404;
a preset amount module 1456 for accepting customer payment amounts and configuring them as presets (e.g., by using a free form as in FIG. 25A or a menu of options as in FIG. 25B) and transmitting the payment amounts to the server 108 by using the long range communication device 1404 for use in subsequent proposed transactions;
o A confirmation module 1458 for receiving a confirmation message from the server 108 by using the long range communication device 1404 (e.g., confirming that the transaction has been completed, that the payment has been made by the particular consumer, etc.); and o A response module 1460 for sending a response to the confirmation message to the consumer device 104 by using the short range communication device 1404, or for sending this response to the server 108 (for forwarding to the consumer device 104) by using the long range communication device 1404, where the sending is either automatic (e.g., upon receiving the confirmation message) or manually entered and sent (e.g., when the decision to send the message is made by the merchant), where the message (e.g., "Thank you") is pre-selected or customized (e.g., entered by the merchant using a free form field); and Merchant Data 1460 for storing data related to the payment processing system 1300, including but not limited to the following:
○ a merchant profile 1462 that stores identification information of a merchant associated with the merchant device 1304, including a unique merchant identifier (e.g., user ID) for broadcast by the short-range communications device 1404 in accordance with the broadcast module 1452, and optionally stores one or more of the merchant's name, logo, photo, address, phone or email; and ○ merchant data 1464 that stores transaction information of a proposed face-to-face transaction between the consumer device 104 and the merchant device 1304, including a pre-set transaction amount (e.g., FIG. 25B), available offers or available rewards; and ● a transaction history 1470 that stores a history of transactions completed between the merchant device 1304 and the consumer device 104 (e.g., a history of payments made to a merchant associated with the merchant device 1304 by each consumer associated with each consumer device 104).

[0180] Each of the above identified elements corresponds to a set of instructions stored in one or more of the aforementioned memory devices to perform the functions described above. The above identified modules or programs (i.e., sets of instructions) need not be implemented as separate software programs, procedures, modules, or data structures, and thus various subsets of these modules may be combined or rearranged in various embodiments. In some embodiments, memory 1406 optionally stores a subset of the above identified modules and data structures. Additionally, memory 1406 optionally stores additional modules and data structures not described above.

[0181] 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 described above with reference to Figure 2.

[0182] In some embodiments, the asynchronous payment module 250 stores the following programs, modules, or a subset or superset thereof:
a discovery module 252 for receiving, via the short-range communications device 204, one or more information packets broadcast by one or more merchant modules 1302, each respective information packet including at least a unique identifier (e.g., device ID) corresponding to a respective merchant device 1304 and, in some embodiments, a payment amount associated with a proposed in-person transaction;
a merchant selection module 254 (see, e.g., FIGS. 23A and 23B ) for displaying on the output device 212 one or more merchants corresponding to the received merchant identifiers and receiving a user selection on the input device 214 of one of the merchants (e.g., user selection of the “Tap to Pay” affordance of FIG. 23A );
• a merchant details module 256 for transmitting the received merchant identifiers to the server, 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 embodiments, pre-populating a list of payment amounts or payment options according to the received merchant transaction information;
• a transaction module 258 for receiving a consumer selection (via the input device 214) of supplemental transaction data (e.g., payment amount, offer, or tip; see Figs. 24 and 26B) and transmitting the selected supplemental transaction data to the server 108 via the long range communications device 204;
And,
● A confirmation module 260 for receiving a confirmation message from the server 108 via the long-range communication device 204 indicating that the server has completed the transaction, and optionally receiving a follow-up communication (e.g., a "thank you") from the merchant (either received directly or forwarded via the server 108).

[0183] In some embodiments, asynchronous payment data 270 stores the following data structures, or a subset or superset thereof:
• Merchant identifier and/or payment amount information 272 received by one or more merchants within range (or otherwise in proximity) of the consumer device's short-range communications device 204.

[0184] Figures 16A and 16B are more detailed block diagrams of the asynchronous transaction module 350 and asynchronous transaction data 360, respectively, of the server system 108 described with reference to Figure 3 above.

[0185] In some embodiments, the asynchronous trading module 350 stores the following programs, modules, or a subset or superset thereof:
• a merchant details module 352 for receiving requests for merchant details 370 from the consumer devices 104 and transmitting the respective merchant details 370 to the respective consumer devices 104;
● a transaction completion module 354 for receiving consumer-defined supplemental transaction data (e.g., payment amount, offer or tip; see Figures 24 and 26B) from each consumer device 104 and processing each transaction in accordance with the merchant details (e.g., payment authorization information such as deposit account information) and the transaction data (e.g., user-defined or merchant-defined payment amount) and sending each confirmation message (indicating a completed transaction, payment accepted or processed, etc.) to each merchant device 1304 and/or each consumer device 104; and storing the completed transaction information 382; and ● a communications module 356 for receiving a communication (e.g., "thank you") from the merchant device 1304 and sending the respective communication to each consumer device 104.

[0186] In some embodiments, asynchronous transaction data 360 stores the following data structures, or a subset or superset thereof:
● Merchant details 370 for each merchant device 372 including, for example, merchant identification information 374 (name, logo, etc.), transaction information 376 (offers, rewards, etc.), and pre-set amount 378; and ● Merchant transactions 380 for each merchant 382 including completed transaction information (amount paid, time of transaction, etc.).

[0187] FIG. 17 is another view of a payment processing system 1300 according to some embodiments. In this example, the merchant application 1302 broadcasts a merchant identifier (and in some embodiments, a merchant-defined payment amount) over the short-range communications network 111, which is received by the consumer application 102 when the consumer comes within range of the network 111. The consumer application 102 transmits the identifier to a server on the long-range communications network 110, and the server returns the name and/or logo of the merchant. The consumer application 102 renders the name and/or logo received by the server according to the broadcasted merchant identifier, as shown in the example interfaces depicted in FIG. 23A (one merchant) and FIG. 23B (two or more merchants). In some embodiments, the consumer application pre-fills the payment amount field or otherwise provides one or more payment amount selections. The consumer makes a supplemental selection (e.g., fills in the fields of FIG. 24), and the consumer application 104 transmits the selection to the server. The server then processes the transaction on behalf of the merchant. Once the transaction is complete, the server notifies the merchant application 1302 over the long distance communications network 110 that the transaction is complete. In some embodiments, the server also notifies the consumer application 102 over the long distance communications network 110 that the transaction is complete.

[0188] Figure 18 is another view of a payment processing system 1300 according to some embodiments. In this example, N consumer devices (104-1 through 104-N) are within range of a merchant device 1304, and each of the N consumer devices receives a unique identifier for the merchant using short-range communications. Each of the N consumer devices queries the server 108 using long-range communications for additional details (e.g., name, logo) about the merchant associated with the merchant device 1304. The consumers associated with the N consumer devices 104 interact asynchronously with their respective consumer applications 102, making selections and deciding to send supplemental transaction data (e.g., payment amount) at various times, not necessarily in the same order that the consumer devices have already received the merchant details. Thus, the server 108 processes each transaction from each consumer device 104 as the supplemental transaction information arrives at the server. In some embodiments, the server 108 processes each transaction (or overlapping portions of each transaction) in parallel. The server 108 asynchronously sends confirmations to the merchant 1304 as each transaction is completed, not necessarily in the same order that the transactions began. In some embodiments, the server 108 sends confirmations (or overlapping portions of confirmations) in parallel.

19-22 are schematic flow diagrams of processes for asynchronously processing payments in a payment processing system 1300 according to some embodiments (1900, 2000, 2100, 2200, respectively). In some embodiments, the payment processing system 1300 includes one or more consumer devices 104, one or more merchant devices 1304, and a server 108. For each process, each of the one or more consumer devices 104 executes an instance of a 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 one or more merchant devices 1304) in the payment processing system 1300. In addition, each of the one or more merchant devices 1304 executes an instance of a 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 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 one or more merchant devices 1304. For simplicity, these operations will be described with respect to each merchant device 1304 and each consumer device 104 in the payment processing system 1300.

[0190] In process 1900 (FIG. 19), the merchant 1304 broadcasts a unique identifier. An exemplary broadcast is described above with reference to FIG. 10A. In some embodiments, the broadcast is a packet 1000 that includes the device ID 1002. In some embodiments, the broadcast packet includes only the device ID. The consumer 104 selects a merchant (FIG. 23A) and requests merchant details from the server 108, which responds with the requested details. The consumer 104 enters a payment amount (FIG. 24), and optionally selects an offer and/or defines a tip amount, then transmits the transaction information (consumer-defined 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 thus the transaction is complete.

[0191] In process 2000 (FIG. 20), the merchant 1304 broadcasts a unique identifier as described in the previous process. At some point before, during, or after the merchant device 1304 begins broadcasting, the merchant associated with the merchant device 1304 selects a payment amount (e.g., defined using the merchant UI depicted in FIG. 25A or 25B). The broadcast following this step includes both the device ID and the merchant-defined payment amount in the broadcast packet. The consumer 104 selects a merchant (FIG. 23A) and requests merchant details from the server 108, which responds with the requested details. The consumer 104 does not enter a payment amount since the payment amount has already been defined by the merchant (in this case the "amount" field would be pre-filled in FIG. 24). The consumer 104 optionally selects an offer and/or defines a tip amount and then transmits the transaction information (merchant-defined 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 therefore the transaction is complete.

[0192] In process 2100 (FIG. 21), the merchant 1304 configures preset payment amounts (e.g., by using a merchant UI as depicted in FIG. 25A or 25B) and sends those amounts to the server 108. The merchant 1304 broadcasts a unique identifier as described in the previous two processes. In some embodiments, the broadcast packet includes only the device ID. The consumer 104 selects a merchant (FIG. 23A) and requests merchant details from the server 108, which responds with the requested details (including the merchant-defined preset payment amount). The consumer 104 selects one of the merchant-defined preset payment amounts (FIG. 26B) and, optionally, selects an offer and/or defines a tip amount, then sends the transaction information (the current merchant-defined payment amount, the offer, and/or the 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 therefore the transaction is complete.

[0193] In some embodiments, processes 1900, 2000 and/or 2100 continue to process 2200 (FIG. 22). After 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. In some embodiments, the message is communicated by the merchant 1304 sending a message to the server 108, which then sends the message to the consumer 104.

[0194] It should be understood that the particular order in which the operations of FIGS. 19-22 are described is merely exemplary, and the order described is not intended to be the only order in which the operations may be performed. Those skilled in the art will recognize various ways to reorder the operations described herein. In addition, it should be noted that other process details described herein (e.g., processes 800, 900, and 1200) with respect to other methods and/or processes described herein may also be applied in a manner similar to methods 1900-2200 described above with respect to FIGS. 19-22.

[0195] Figures 23A, 23B, 24, 26A, and 26B show consumer device 104 displaying various user input (UI) screens for submitting a payment.

[0196] In FIG. 23A, the consumer device 104 has received one merchant identifier corresponding to "Pizza Family Cuisine" and identifies the name and logo for consumer selection ("tap to pay"). In FIG. 23B, the consumer device 104 has received three merchant identifiers corresponding to "Pizza Family Cuisine," "Red Windsor Cheese Shop," and "Lupines Flowers and Shrubberies." Thus, each merchant is listed by name on the same screen, awaiting consumer selection. Alternatively, each screen, which may be scrollable, swipeable, etc., includes only one merchant.

[0197] In FIG. 24, the consumer device 104 displays an "Amount" field that is either pre-filled (for implementations involving a merchant-defined payment amount) or fillable (for implementations involving a customer-defined payment amount).

[0198] In FIG. 26A, the consumer device 104 displays pre-entered payment amounts, and the consumer may select from a list of pre-entered payment amounts in FIG. 26B.

[0199] Figures 25A and 25B show a merchant device 1304 displaying various UI screens for specifying a payment amount.

[0200] In FIG. 25A, the merchant enters a merchant-defined payment amount into a fillable field. In FIG. 25B, the merchant selects from a menu of pre-populated payment amounts to define a merchant-specific payment amount.

[0201] Although specific embodiments have been described above, it will be understood that no limitation of application to those specific embodiments is intended. On the contrary, application includes alternatives, modifications, and equivalents falling within the spirit and scope of the appended claims. Numerous specific details are described in order to provide a thorough understanding of the subject matter presented herein. However, it will be apparent to those skilled in the art that the subject matter may be practiced without these specific details. In other instances, well-known methods, procedures, components, and circuits have not been described in detail so as not to unnecessarily obscure aspects of the embodiments.

Claims (14)

In a consumer device including a display, one or more processors, a communication unit, and a memory, an application executing on the consumer device comprises:
identifying one or more merchant devices in a vicinity of the consumer device based at least in part on receiving a broadcast information packet transmitted by a payment module of each of the one or more merchant devices, the broadcast information packet including a unique device identifier corresponding to the payment module of each of the consumer devices;
transmitting the unique device identifier via the communication unit of the consumer device to a server and receiving from the server an electronic communication including merchant identification information of a merchant associated with a merchant device corresponding to the unique device identifier and merchant transaction information identifying a proposed in-person transaction between the consumer device and the merchant associated with the corresponding merchant device, the merchant identification information including one or more of the merchant 's name, logo, photo, address, phone or email, and the merchant transaction information including a preset transaction amount, available offers or available rewards;
displaying merchant identification information for each merchant associated with the one or more merchant devices on the display of the consumer device;
receiving from a user of the consumer device a selection of a first merchant identification for a first merchant associated with a first merchant device of the one or more merchant devices ;
in response to receiving the selection of the first merchant identifying information;
displaying first merchant transaction information identifying a proposed in-person transaction between the consumer device and the first merchant ;
receiving first supplemental transaction information from the user of the consumer device, the first supplemental transaction information being the preset transaction amount selection, the available offer selection, the available reward selection, or a free form payment amount;
transmitting the first supplemental transaction information to the server;
and asynchronously receiving a confirmation message from the server in response to transmitting the first supplemental transaction information to the server, the confirmation message indicating that the proposed transaction between the consumer device and the first merchant has been completed. The method of claim 1, further comprising, following receipt of the confirmation message from the server indicating that the proposed transaction between the consumer device and the merchant is completed, receiving a message from the server from the merchant confirming that the transaction is completed. identifying the one or more merchant devices includes identifying the first merchant device and a second merchant device in proximity to the consumer device;
receiving the electronic communication includes receiving the first merchant identification information and the first merchant transaction information, and second merchant identification information of a second merchant associated with the second merchant device and second merchant transaction information identifying a proposed in-person transaction between the consumer device and the second merchant;
Displaying the merchant identification information of each merchant
3. The method of claim 1 or 2, further comprising displaying the first merchant identification information and the second merchant identification information on the display of the consumer device, or displaying the first merchant identification information and an indication that the second merchant identification information is available for display on the display of the consumer device. 4. The method of claim 3, wherein displaying the first and second merchant identification information includes displaying one of the first and second merchant identification information more prominently than another of the first and second merchant identification information according to first and second distances between the consumer device and the first and second merchant devices, respectively. 5. The method of claim 4, further comprising determining the first and second distances by measuring first and second signal strengths associated with the broadcast information packet transmitted by the first merchant device and the broadcast information packet transmitted by the second merchant device, respectively. 6. The method of claim 3, wherein displaying the first and second merchant identification information comprises displaying one of the first and second merchant identification information more prominently than the other of the first and second merchant identification information according to first and second location coordinates of the first and second merchant devices, respectively. The method of any one of claims 3 to 6, wherein displaying the first and second merchant identification information includes displaying one of the first and second merchant identification information more prominently than the other of the first and second merchant identification information according to a preselected sort order associated with the first and second merchant devices. A display and
one or more processors;
and a memory storing one or more programs executed by said one or more processors, said one or more programs comprising instructions for performing the method of any one of claims 1 to 7. A non-transitory computer-readable storage medium storing one or more programs configured for execution by a computer system, the one or more programs including instructions for carrying out the method of any one of claims 1 to 7. A server including one or more processors, a communication unit and a memory,
An application running on the server,
receiving, from a first consumer device, a broadcast information packet transmitted by a payment module of a first merchant device, the broadcast information packet including a first unique device identifier corresponding to the payment module of the first merchant device;
transmitting to the first consumer device first merchant identification information of a first merchant associated with the first merchant device according to the first unique device identifier and first merchant transaction information identifying a proposed in-person transaction between the consumer device and the first merchant, the first merchant identification information including one or more of a name, a logo, a photo, an address, a phone number, or an email address of a first merchant associated with the first merchant device, and the first merchant transaction information including a preset transaction amount, an available offer, or an available reward;
receiving first supplemental transaction information from the first consumer device, the first supplemental transaction information being the preset transaction amount selection, the available offer selection, the available reward selection, or a free form payment amount entered at the first consumer device;
Processing a transaction between the first consumer device and the first merchant device;
asynchronously transmitting a confirmation message to the first consumer device indicating that the proposed transaction between the first consumer device and the first merchant has been completed;
asynchronously sending a confirmation message to the first merchant device indicating that the proposed transaction between the first consumer device and the first merchant has been completed. following sending the confirmation message to the first merchant device;
receiving a completion message from the first merchant device relating to the completed transaction;
and transmitting the completion message to the first consumer device. following receiving the first unique device identifier from the first consumer device,
receiving the first unique device identifier from a second consumer device;
transmitting the first merchant identification information and the first merchant transaction information to the second consumer device according to the first unique device identifier;
prior to receiving the first supplemental transaction information from the first consumer device;
receiving second supplemental transaction information from the second consumer device;
Processing a transaction between the second consumer device and the first merchant device;
asynchronously transmitting a confirmation message to the second consumer device indicating that the proposed transaction between the second consumer device and the first merchant has been completed;
12. The method of claim 11, further comprising asynchronously sending a confirmation message to the first merchant device indicating that the proposed transaction between the second consumer device and the first merchant has been completed. A server including one or more processors and a memory that stores one or more programs executed by the one or more processors, the one or more programs including instructions for carrying out the method according to any one of claims 10 to 12. A non-transitory computer-readable storage medium storing one or more programs configured for execution by a server, the one or more programs including instructions for carrying out the method according to any one of claims 10 to 12.

Images