Method and system for providing automated retail machine offers through a mobile device

Abstract

To provide and process proposals of sales promotion of an auto-vending machine.SOLUTION: A mobile device displays sales-promotion proposals, detects a user input to select one of the sales-promotion proposals, and starts to execute a transaction with an auto-vending machine for purchasing a product stored in the auto-vending machine. The mobile device receives from a payment module a transaction completion notification indicating that a product corresponding to the selected proposal of sales promotion is sold by the auto-vending machine and, in response to a reception of the transaction completion notification, provides a user of the mobile device a prompt for acquiring a product code of the sold product in order to verify the proposal of sales promotion. Furthermore, the mobile device acquires the product code of the product, sends the product code to a server and, in response thereto, receives sales-promotion verification information from the server, and displays the sales-promotion verification information indicating whether or not the corresponding sales-promotion proposal is verified.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001]

[0001] The present application relates to the field of payment processing systems, and in particular to payment processing systems between mobile devices and machines over non-persistent networks. [Background technology]

[0002] Vending machines (or more broadly, "retail machines"), in the broadest sense, have been around for thousands of years. The first simple mechanical coin-operated vending machines were introduced in the 1880s. Modern vending machines stock many different types of products, including, but not limited to, beverages (e.g., water, juice, coffee, and soda), edible products / items (e.g., snacks, candy, fruit, and frozen foods), and a wide variety of non-edible items. In this fast-paced world, vending machines are ubiquitous.

[0003] A vending machine is a type of "payment acceptance unit" (which is also collectively referred to herein as a "machine"). A payment acceptance unit (or machine) is a device that requests payment for the dispensing of products and / or services. In addition to vending machines, payment acceptance units can also be other machines that request payment for the dispensing of products and / or services. These include, but are not limited to, parking meters, toll booths, laundromat washers and dryers, gaming machines, kiosks, photo booths, toll booths, transit ticket machines, and other known or yet to be discovered payment acceptance units.

[0004]

[0004] In using a payment acceptance unit, a user (1) approaches the payment acceptance unit, (2) determines the desired product (or service) from the surface of the payment acceptance unit, (3) inserts payment (coins, bills, or payment card), and (4) inputs their selection into the payment acceptance unit using a user interface (e.g., a series of buttons, a keypad, a touch screen, or other input mechanism using columns and rows in which products are arranged). Based on the selections entered by the user, technology within the payment acceptance unit provides the desired product (or service) to the user.

[0005]

[0005] As the number of people owning internet-connected mobile devices has grown exponentially, the uses of such devices have also diversified. Mobile payments are a logical extension. Significant development effort is being expended to bring mobile payments to the retail sector, not only to provide users with choice but also to enhance convenience. Summary of the Invention [Means for solving the problem]

[0006] In some implementations, a method for providing and processing promotional offers for an automated retail machine is performed on a mobile device (e.g., mobile device 104, FIGS. 1 and 2) that includes a display, one or more processors, and a memory. The method includes displaying one or more promotional offers on the display, detecting user input selecting each promotional offer of the one or more promotional offers, and initiating execution of a transaction with the automated retail machine coupled to a payment module, the transaction corresponding to a purchase of products stored in the automated retail machine. The method also includes receiving a transaction completion notification from the payment module, the transaction completion notification indicating that products corresponding to each selected promotional offer have been sold by the automated retail machine, and, in response to receiving the transaction completion notification, providing a prompt to a user of the mobile device to obtain product codes of the sold products in order to verify each promotional offer. The method further includes the steps of obtaining a product code for the sold product; transmitting the product code to a server after obtaining the product code; receiving promotion verification information from the server in response to transmitting the product code; and displaying the promotion verification information on a display, wherein the promotion verification information indicates whether each promotion offer has been verified.

[0007] In some implementations, a mobile device (e.g., mobile device 104, FIGS. 1 and 2) comprises a display, one or more processors, and memory that stores one or more programs executed by the one or more processors, the one or more programs including instructions that perform or control the execution of operations of any method described herein. In some implementations, a non-transitory computer-readable storage medium stores one or more programs including instructions that, when executed by a mobile device (e.g., mobile device 104, FIGS. 1 and 2) comprising one or more processors and a display, cause the computing device to perform or control the execution of operations of any method described herein. In some implementations, a mobile device (e.g., mobile device 104, FIGS. 1 and 2) comprises means for performing or controlling the execution of operations of any method described herein.

[0008]

[0008] (Al) In some implementations, a method is executed on a mobile device having a display, one or more processors, and a memory. The method includes displaying one or more promotional offers on the display, detecting user input selecting each promotional offer of the one or more promotional offers, and initiating execution of a transaction with an automated retail machine coupled to a payment module. In some implementations, the transaction corresponds to a purchase of products stored in the automated retail machine. The method also includes receiving a transaction completion notification from the payment module indicating that a product corresponding to each selected promotional offer has been sold by the automated retail machine. In response to receiving the transaction completion notification, the method includes providing a prompt to a user of the mobile device to obtain product codes of the sold products to verify each promotional offer. The method further includes obtaining the product codes of the sold products. After obtaining the product codes, the method includes transmitting the product codes to a server. In response to transmitting the product codes, the method includes (i) receiving promotional verification information from the server and (ii) displaying the promotional verification information on the display. In some implementations, the promotional verification information indicates whether each promotional offer has been verified.

[0009]

[0009] (A2) In some implementations of the method of A1, one or more promotional offers are identified based on at least one of a unique identifier corresponding to the payment module, at least one of the current time and date, the location of the automated retail machine, the location of the mobile device, and a unique identifier corresponding to a user of the mobile device.

[0010]

[0010] (A3) In some implementations of the method of A1 or A2, before displaying one or more promotional offers, the method includes: (i) a step of obtaining an information packet broadcast by a payment module coupled to the automated retail machine, the information packet including at least an authorization code and a unique identifier corresponding to the payment module; (ii) a step of sending a request for transaction authorization to a server, the transaction authorization including the authorization code and the unique identifier corresponding to the payment module; and (iii) in response to the request for transaction authorization, receiving authorization information from the server including an authorization grant token for initiating a transaction with the automated retail machine coupled to the payment module and one or more promotional offers from the server.

[0011]

[0011] (A4) In some implementations of any one of the methods of A3, execution of a transaction with an automated retail machine coupled to a payment module is initiated by sending an authorization grant token to the payment module that includes an authorization code included in the broadcast information packet.

[0012]

[0012] (A5) In some implementations of any one of methods A1 to A4, the step of obtaining the product code further includes the steps of (i) capturing an image of the product including the product code, and (ii) extracting the product code from the captured image.

[0013] (A6) In some implementations of any one of the methods A1 to A5, obtaining the product code further includes scanning the product code of the product with a scanner unit of the mobile device.

[0014] (A7) In some implementations of any one of the methods of A1-A6, the promotion validation information indicates a price of the product after applying each promotional offer.

[0015] (A8) In some implementations of any one of the methods of A1 to A7, the method further includes, after obtaining the product code, determining whether a predetermined time period has expired. In response to determining that the time period has expired, the method includes providing a notification to a user of the mobile device indicating that the promotional offer has expired. In response to determining that the time period has not expired, the method includes transmitting the product code to a server.

[0016] (A9) In some implementations of any one of the methods A1 to A8, the method includes sending a transaction completion notification to the server.

[0017]

[0017] (A10) In some implementation forms of any one of the methods A1 to A9, 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.

[0018]

[0018] (A11) In an additional aspect, a method is executed on a mobile device comprising a display, one or more processors, a short-range transceiver (e.g., a first communication unit), a long-range transceiver (e.g., a second communication unit) different from the short-range transceiver, and a memory. In some implementations, the method includes identifying, by an application executing on the mobile device, the automated retail machine based at least in part on signal strength of information broadcast from an electronic payment device coupled to the automated retail machine. The method also includes displaying one or more promotional offers associated with the automated retail machine on the display. In some implementations, the method further includes detecting user input selecting each promotional offer of the one or more promotional offers. The method additionally includes initiating execution of a transaction with the automated retail machine, via the short-range transceiver, corresponding to a purchase of a product stocked by the automated retail machine. The method also includes receiving, via the short-range transceiver, a transaction completion notification from the electronic payment device indicating that the product has been sold by the automated retail machine. In response to receiving the transaction completion notification, the method includes providing a prompt to a user of the mobile device instructing the user to obtain a product code for the sold product. The method further includes obtaining a product code for the sold product based on user input provided in response to the prompt. After obtaining the product code, the method includes transmitting the product code to a server via the long-range transceiver. In response to transmitting the product code, (i) receiving promotional verification information from the server via the long-range transceiver, and (ii) displaying, on the display, an indication of whether each promotional offer was verified and information identifying a credit to the user after applying each promotional offer based on the promotional verification information.

[0019] (A12) In some implementations of the method of A11, the method further includes any of the operations described in A2 to A10 above.

[0020]

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

[0021]

[0021] The above-mentioned features and advantages, as well as additional features and advantages, of the disclosed technology will be more clearly understood from the following detailed description of preferred implementations, read in conjunction with the accompanying drawings.

[0022]

[0022] In order to more clearly describe the implementation of the technology of the present disclosure or the technical solutions in the prior art, the following briefly introduces the accompanying drawings necessary for describing the implementation or prior art. Needless to say, the accompanying drawings in the following description only show some implementations of the technology of the present disclosure, and those skilled in the art can further derive other drawings from these accompanying drawings without creative efforts. [Brief explanation of the drawings]

[0023] [Figure 1]

[0023] FIG. 1 is a block diagram of a payment processing system according to some implementations. [Figure 2]

[0024] FIG. 1 is a block diagram of a mobile device according to some implementations. [Figure 3]

[0025] FIG. 1 is a block diagram of a server system according to some implementations. [Figure 4]

[0026] FIG. 1 is a schematic block diagram of an automated retail machine according to some implementations. [Figure 5]

[0027] FIG. 10 is a block diagram of a payment module according to some implementations. [Figure 6A]

[0028] FIG. 6 is a perspective view of the payment module (e.g., inline dongle adapter) of FIG. 5 according to some implementations. [Figure 6B]

[0029] FIG. 6B is a perspective view from a first end of the payment module of FIG. 6A according to some implementations. [Figure 6C]

[0030] FIG. 6B is a perspective view from a second end of the payment module of FIG. 6A according to some implementations. [Figure 7]

[0031] 6B is a perspective view of the payment module of FIG. 6A in the automated retail machine of FIG. 4 according to some implementations. [Figure 8]

[0032] 1 is a simplified flow diagram of a process for initiating a transaction according to some implementations. [Figure 9]

[0033] 1 is a simplified flow diagram of a process for validating a transaction according to some implementations. [Figure 10A]

[0034] FIG. 10 is a block diagram of an information packet broadcast by a payment module according to some implementations. [Figure 10B]

[0035] FIG. 1 is a block diagram of an authorization request according to some implementations. [Figure 10C]

[0036] FIG. 1 is a block diagram of an authorization grant token according to some implementations. [Figure 10D]

[0037] FIG. 10 is a block diagram of transaction information generated by a payment module according to some implementations. [Figure 11A]

[0038] FIG. 10 illustrates an exemplary user interface for displaying promotional offers in accordance with some embodiments. [Figure 11B] FIG. 10 illustrates an exemplary user interface for displaying promotional offers in accordance with some embodiments. [Figure 11C] FIG. 10 illustrates an exemplary user interface for displaying promotional offers in accordance with some embodiments. [Figure 11D] FIG. 10 illustrates an exemplary user interface for displaying promotional offers in accordance with some embodiments. [Figure 11E] FIG. 10 illustrates an exemplary user interface for displaying promotional offers in accordance with some embodiments. [Figure 11F] FIG. 10 illustrates an exemplary user interface for displaying promotional offers in accordance with some embodiments. [Figure 11G] FIG. 10 illustrates an exemplary user interface for displaying promotional offers in accordance with some embodiments. [Figure 12A]

[0039] 1 is a flow diagram of a method for providing and processing promotional offers in an automated retail machine according to some implementations. [Figure 12B] 1 is a flow diagram of a method for providing and processing promotional offers in an automated retail machine according to some implementations. [Figure 12C] 1 is a flow diagram of a method for providing and processing promotional offers in an automated retail machine according to some implementations. DETAILED DESCRIPTION OF THE INVENTION

[0024]

[0040] Like reference numerals refer to corresponding parts throughout the several views of the drawings.

[0025]

[0041] Reference will now be made in detail to implementations, 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 implementations.

[0026]

[0042] The following clearly and completely describes the technical solutions in the implementation of the present application, with reference to the accompanying drawings of the implementation of the present application. Needless to say, the described implementation is only a part, not all, of the implementation of the present application. Based on the implementation of the present application, all other implementations obtained by those skilled in the art without using creative efforts shall fall within the protection scope of the present application.

[0027]

[0043] FIG. 1 illustrates a payment processing system 100. FIGS. 2-5 illustrate example devices within the payment processing system 100. FIGS. 6A-6C and 7 illustrate various exterior views of the payment module 124 and automated retail machine 122. FIG. 8 is a schematic flow diagram of a process 800 for initiating a transaction within the payment processing system 100. FIG. 9 is a schematic flow diagram of a process 900 for confirming a transaction within the payment processing system 100. FIGS. 10A-10D illustrate data structures associated with initiating and executing a transaction within the payment processing system 100. FIGS. 11A-11G illustrate example user interfaces for displaying promotional offers. FIGS. 12A-12C are a flow 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.

[0028] Device and System Examples

[0044] 1 is a block diagram of a payment processing system 100 according to some implementations. According to some implementations, 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 referred to herein as a “server”), and a payment module 124 coupled to an automated retail machine 122. The client-side module 102 provides 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 implementations, an application associated with the client-side module 102 provides a user interface to the payment processing system 100 for the mobile device 104. The client-side module 102 communicates with the server-side module 106 over one or more networks 110 via a long-range communication protocol (e.g., GSM, CDMA, Wi-Fi, etc.), and the client-side module 102 communicates 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 server-side functionality of the payment processing system 100 to any number of client modules 102, each resident on a respective mobile device 104.

[0029]

[0045] The payment processing system 100 uses the mobile device 104's connectivity to communicate with the payment module 124, which does not have a dedicated communication connection or a long-range communication transceiver. As such, the mobile device 104 acts as a relay between the payment module 124 and the server system 108. Furthermore, utilizing the mobile device 104's connectivity helps keep costs low from the perspective of the automated retail machine 122 operator.

[0030]

[0046] In some implementations, the server-side module 106 comprises one or more processors 112, a user information database 114, a proposal database 116, and one or more client-facing input / output (I / O) interfaces 118. The one or more client-facing I / O interfaces 118 facilitate client-facing input / output processing of the server-side module 106. In some implementations, the one or more processors 112 authorize transaction requests, determine promotional offers for particular mobile devices 104, perform transaction settlement, and verify completed transactions. The user information database 114 stores information for each user of the payment processing system 100 (e.g., user ID, account credentials (username and password), transaction history, account balance, linked credit card and bank accounts, etc.), and the proposal database 116 stores promotional offers provided by manufacturers, distributors, retailers, etc.

[0031]

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

[0032]

[0048] Examples of the one or more networks 110 include a local area network (LAN) or 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.

[0033]

[0049] The server system 108 is implemented with one or more standalone data processing devices or a distributed network of computers. In some implementations, the server system 108 utilizes various virtual devices and / or services from third-party service providers (e.g., third-party cloud service providers) to provide the underlying computing and / or infrastructure resources for the server system 108. In some implementations, 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.

[0034]

[0050] The payment processing system 100 shown in FIG. 1 includes both a client-side portion (e.g., a client-side module 102) and a server-side portion (e.g., a server-side module 106). In some implementations, data processing is implemented as a standalone application installed on the mobile device 104. Additionally, the division of functionality between the client-side and server-side portions of the payment processing system 100 may vary depending on the implementation. For example, in some implementations, 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., a server system 108). While many aspects of the present technology are described in terms of the server system 108, corresponding operations performed by the mobile device 104 will be apparent to those skilled in the art without any creative effort. Furthermore, some aspects of the present technology may be performed by the server system 108, the mobile device 104, or a combination of the server system 108 and the mobile device 104.

[0035]

[0051] 2 is a block diagram of a mobile device 104 associated with a user, according to some implementations. The mobile device 104 typically includes one or more processing units (CPUs) 202, two or more communication devices 204, memory 206, and one or more communication buses 208 interconnecting these components (also referred to as chipsets). 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 further includes a user interface 210. The user interface 210 includes one or more output devices 212 that enable the presentation of media content (e.g., text, images, audio, video, etc.), including one or more speakers and / or one or more visual displays. The user interface 210 further 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 touchscreen display, a touch-sensitive input pad, a gesture capture camera, or other input buttons or controls. Additionally, in some implementations, the mobile device 104 uses a microphone and voice recognition, or a camera and gesture recognition, to supplement or replace a keyboard. In some implementations, the mobile device 104 optionally includes one or more sensors 215 that provide contextual information about 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 biometric / living sensors, etc. In some implementations, the mobile device 104 optionally includes a location detection device 217, such as a global positioning satellite (GPS) or other geolocation receiver, to determine the location of the mobile device 104.

[0036]

[0052] 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 implementations, 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, which includes procedures for handling various basic system services and performing hardware-dependent tasks. • A communications module 218 that sends and receives signals to and from other devices (e.g., the server system 108 and the payment module 124) via two or more communications devices 204. a presentation module 220 that enables presentation of information (e.g., a user interface of an application 226 or an application associated with the client-side module 102, widgets, a website and its web pages, and / or games, audio and / or video content, text, etc.) via one or more output devices 212 (e.g., a display, speakers, etc.) associated with the user interface 210 on the mobile device 104; • An input processing module 222 that detects one or more user inputs or interactions from one or more input devices 214 and interprets the detected inputs or interactions. • A web browser module 224 that navigates, requests (via HTTP), and displays websites and their web pages. One or more applications 226 executed by the mobile device 104 (e.g., games, application marketplaces, payment platforms, and / or other web-based or non-web-based applications) A client-side module 102 that provides client-side data processing and functionality for the payment processing system 100, including, but not limited to: a broadcast acquisition module 230 that receives, via the first transceiver, an information packet broadcast by each payment module 124. The information packet includes 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 each payment module 124 is coupled; a transaction authorization module 232 that sends a transaction authorization request including the authorization code to the server system 108 via the second transceiver, receives an authorization grant token including the authorization code from the server system 108 via the second transceiver to initiate a transaction with the automated retail machine 122 to which each payment module 124 is coupled, and stores the received authorization grant token (e.g., in the user data 264); a proposal module 234 that retrieves (i.e., receives or retrieves) promotional offers from the server system 108 via the second transceiver (e.g., in response to sending a transaction authorization request to an application associated with the client-side module 102 or at another time), stores the promotional offers retrieved from the server system in a proposal database 266, optionally determines one or more promotional offers based on one or more of a plurality of factors (e.g., device ID, user ID and history, current location of the mobile device 104, current date / time, etc.), presents the one or more promotional offers to a user of the mobile device via one or more output devices 212 (e.g., displays), and detects user input selecting one of the one or more promotional offers to be presented to the user of the mobile device 104. a trigger detection module 236 that detects a trigger for each payment module 124 to initiate a transaction with the associated automated retail machine 122 (e.g., the trigger being a gesture or other user input by a user of the mobile device 104, the mobile device 104 entering a payment zone based on RSSI observed from the payment module 124, the selection of a respective promotional offer, etc.); a transaction initiation module 238 that initiates a transaction with the automated retail machine 122 coupled to each payment module 124 by transmitting the stored authorization grant token to each payment module 124 via the first transceiver; a transaction completion notification receiving module 240 that receives a transaction completion notification from the payment module 124 via the first transceiver, 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 details (e.g., authorization code, transaction amount, merchandise / product associated with the transaction, time / date the transaction was completed, transaction error information, etc.), and optionally other information about each payment module 124 and / or the automated retail machine 122 to which each payment module 124 is coupled, such as aborted transaction information, status flags, inventory information, past monetary transaction information, other cashless transaction information, etc. a product code processing module 242 that provides a prompt to the user of the mobile device 104 via one or more output devices 212 to obtain a product code for the sold product in order to verify each promotional offer, obtains the product code for 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 is extracted, the user of the mobile device 104 obtains the product code using a scanner plug-in of an application associated with the client-side module 102, etc.), and validates the product code or transmits the obtained product code via the second transceiver to the server system 108 for validation; an information relay module 244 that transmits information (e.g., transaction status information, transaction details, and other information about each payment module 124 and / or the automated retail machine 122 to which each payment module 124 is coupled) from the payment modules 124 to the server system 108 via the second transceiver; A proposal verification module 246 that receives promotion verification information from the server system 108 via the second transceiver and presents the promotion verification information to the mobile device user via one or more output devices 212 (e.g., displays). A confirmation module 248 that sends confirmation information to the payment module 124 via the first transceiver confirming that the server system 108 has received and processed the transaction status information and transaction detail information. Client data 260, which stores data related to the payment processing system 100, including, but not limited to: 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.), user custom parameters (e.g., age, location, hobbies, etc.), the user's identified tendencies and / or likes / dislikes, etc. User data 264, which stores transaction history information, authorization tokens, etc. A proposal database 266 that stores promotional proposals provided by manufacturers, distributors, retailers, etc.

[0037]

[0053] Each of the above-identified elements may be stored in one or more of the memory devices described above and corresponds to an instruction set that performs the functions described above. The above-identified modules or programs (i.e., instruction sets) need not be implemented as independent software programs, procedures, modules, or data structures, and thus various subsets of these modules may be combined or rearranged in various implementations. In some implementations, 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.

[0038]

[0054] 3 is a block diagram illustrating a server system 108 according to some implementations. 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 interconnecting these components (also 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 within the memory 306, includes a non-transitory computer-readable storage medium. In some implementations, 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, which includes procedures for handling various basic system services and performing hardware-dependent tasks. a network communication module 312 that sends and receives signals to and from the mobile device 104 via one or more communication devices 304; • A server-side module 106 that provides server-side data processing and functionality for the payment processing system 100, including, but not limited to: A transaction authorization module 314 that receives a transaction request from each mobile device 104, including a device ID and authorization code associated with each payment module 124, and validates the transaction request. an encryption / decryption module 316 that identifies an encryption / decryption key linked to the device ID of each payment module 124, decrypts the authorization code with the identified encryption / decryption key, and encrypts the authorization grant token with the identified encryption / decryption key; An offer determination module 318 that determines one or more promotional offers based on one or more of a number of factors (e.g., device ID included in the transaction request, user ID and history associated with the user of each mobile device 104, current location of each mobile device 104, current time / date, etc.). a transmission module 320 that, in response to determining that the transaction request is verified, transmits an authorization grant token and one or more promotional offers to each mobile device 104, and transmits confirmation information to each mobile device 104 when the transaction is completed; A receiving module 322 that receives 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 information. an offer verification module 324 that verifies the promotional offer based on the received product code, transaction status information, and / or transaction details, and, upon determining that the promotional offer is verified, transmits promotion verification information to each mobile device 104; A payment module 326 that debits your account balance or charges your linked credit card or bank account depending on the transaction details. A verification module 328 that sends verification information to each mobile device 104 for relay to each payment module 124 Server data 340, which stores 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. A proposal database 116 that stores promotional proposals submitted by manufacturers, distributors, retailers, etc. A payment module database 342 that stores information for each payment module 124 in the payment processing system 100, including but not limited to unique payment module identifiers (i.e., device IDs), encryption / decryption keys, etc.

[0039]

[0055] Each of the above-identified elements may be stored in one or more of the memory devices described above and corresponds to an instruction set that performs the functions described above. The above-identified modules or programs (i.e., instruction sets) need not be implemented as separate software programs, procedures, or modules, and thus various subsets of these modules may be combined or rearranged in various implementations. In some implementations, 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.

[0040]

[0056] In some implementations, at least some of the functions of the server system 108 are performed by the mobile device 104, and corresponding sub-modules of those functions may be located in the mobile device 104 rather than the server system 108. In some implementations, at least some of the functions of the mobile device 104 are performed by the server system 108, and corresponding sub-modules of those 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 and 3, respectively, are merely exemplary, and different configurations of modules implementing the functions described herein are possible in various implementations.

[0041]

[0057] 4 is a schematic block diagram illustrating an automated retail machine 122 according to some implementations. For example, the automated retail machine 122 is a vending machine or kiosk that dispenses items or products (e.g., snacks, other food, school supplies, beverages, tickets, etc.) in response to payment and selection of the items or products by a user. 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 multidrop bus (MDB) 416, and a dispenser 424.

[0042]

[0058] In some implementations, the controller 402 is a microcontroller, microprocessor, CPU, FPGA, ASIC, etc. that manages the functions of the automated retail machine 122. The power supply 404 is a connection to an external power source (e.g., AC or DC) or a connection to an internal power source (e.g., a battery). In some implementations, the power supply 404 further comprises one or more power converters and / or inverters, rectifiers, power conditioners, etc. to provide 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, one or more other non-volatile solid-state storage devices, etc. In some implementations, the memory 406 stores an operating system and instructions for executing the functions and processes of the automated retail machine 122 (e.g., dispensing items, tracking inventory, temperature control, power control, etc.). In some implementations, the memory 406 further stores configuration data and DEX (data exchange) data corresponding to the inventory of the automated retail machine 122 and transactions performed at the automated retail machine 122 .

[0043]

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

[0044]

[0060] In some implementations, various payment devices are coupled to the MDB 416. This includes 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 coins and providing change. In some implementations, the dispenser 424 is an electromechanical system (e.g., motors, actuators, etc.) that dispenses or sells items or products stored by the automated retail machine 122. For example, a user inserts a bill into the bill validator 420 and is credited an amount equivalent to the bill. Continuing with this example, the one or more output devices 410 (e.g., a display) indicate the credited amount, and the user selects an item via the one or more input devices 412 (e.g., using a keypad or by 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.

[0045]

[0061] Figure 5 is a block diagram illustrating a payment module 124 according to some implementations. In some implementations, the payment module 124 is an inline adapter dongle with male and female connectors that couple to a multidrop bus (MDB) of each automated retail machine 122, as shown in Figures 6B, 6C, and 7. For example, the payment module is connected inline to the MDB 416 shown in Figure 4. The payment module 124 typically includes one or more processing units (CPUs) 512, a communication device 504 (e.g., a transceiver associated with a short-range communication protocol such as NFC, BLE, etc.), memory 506, and one or more communication buses 508 interconnecting these components (also referred to as chipsets). The memory 506 includes high-speed random-access memory such as DRAM, SRAM, DDR RAM, or other random-access solid-state memory devices, and optionally includes non-volatile memory such as one or more magnetic disk storage devices, one or more optical disk storage devices, one or more flash memory devices, or one or more other non-volatile solid-state storage devices. The memory 506 optionally includes one or more storage devices located remotely from the one or more processing units 512. The memory 506, or alternatively the non-volatile memory within the memory 506, includes a non-transitory computer-readable storage medium. In some implementations, the memory 506 or the non-transitory computer-readable storage medium of the memory 506 stores the following programs, modules, and data structures, or a subset or superset thereof: • Operating system 510, which includes procedures for handling various basic system services and performing hardware-dependent tasks. a communications module 512 that transmits and receives signals to and from the mobile device 104 via the communications device 504; • A transaction processing module 514, including but not limited to: a broadcast module 516 that broadcasts an information packet to zero or more client devices 104 within the communication zone (i.e., BLE range) of the payment module 124. The information packet includes at least a unique identifier (i.e., device ID) corresponding to the payment module 124 and an authorization code for initiating a transaction with the automated retail machine 122 to which each payment module 124 is coupled. The broadcast module 516 also stores the broadcasted authorization code in an authorization database 532. an encryption / decryption module 518 that encrypts the authorization code with an encryption / decryption key corresponding to the payment module 124 and decrypts the authorization grant token with the encryption / decryption key; a transaction sniffing module 520 that detects signals associated with monetary and / or other cashless transactions not associated with the payment processing system 100 (e.g., credit card transactions) and stores information associated with the monetary and / or other cashless transactions (e.g., in the other information database 536); A validation module 522 that validates the transaction by checking the authorization code in the decrypted authorization grant token against previously broadcast authorization codes stored in the authorization database 532. A transaction processing module 524 that, in response to determining that the transaction is verified, causes the automated retail machine 122 to sell the product or perform the service and stores the transaction details in a transaction database 534 A validation module 526 that deletes the transaction detail information from the transaction database 534 in response to determining that the corresponding transaction has been validated by the server system 108. ● Data 530, which stores data including but not limited to the following: Authorization database 532, which stores previously broadcast authorization codes A transaction database 534 that stores transaction details for transactions processed by the payment module 124 Other information database 536 that stores information about the payment module 124 and / or the automated retail machine 122 coupled to the payment module 124, such as status flags, inventory information, past monetary transaction information, and other cashless transaction information.

[0046]

[0062] Each element identified above may be stored in one or more of the memory devices described above and corresponds to an instruction set that performs the functions described above. The modules or programs (i.e., instruction sets) identified above need not be implemented as separate software programs, procedures, or modules, and thus various subsets of these modules may be combined or rearranged in various implementations. In some implementations, memory 506 optionally stores a subset of the modules and data structures identified above. Additionally, memory 506 optionally stores additional modules and data structures not described above.

[0047]

[0063] 6A-6C illustrate various views of the payment module 124 of FIG. 5 , according to some embodiments. The payment module 124 is a relatively low-cost hardware component pre-configured to interface with the industry-standard multidrop bus (MDB). In machines that do not use MDB technology, the payment module 124 can be configured or designed to interface with other serial protocols or to activate a switch (e.g., a Cherry switch mechanism). See, for example, U.S. Patent Application No. 14 / 458,192, entitled "Method and System for Retrofitting Offline Payment Machines to Accept Electronic Payments," which is incorporated by reference in its entirety. Essentially, the payment module 124 simulates the establishment of payments at the automated retail machine 122 in much the same manner as other alternative forms of payment (e.g., cash).

[0048]

[0064] The payment module 124 is preferably designed to be used as an adapter dongle for in-line insertion into an MDB or the like 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 peripherals to be attached. In the case of a vending machine, an MDB with connection ends or adapters exists to allow a payment acceptance mechanism (e.g., a coin mechanism) to be attached. The MDB's MDB male adapter 612 and MDB female adapter 614 may be separated (as shown in Figures 6B and 6C). The payment module 124 of Figures 6A-6C has a male adapter 602 and a female adapter 604. The payment module 124 may be plugged (inserted) serially ("in-line") into the MDB. For example, the MDB female adapter 614 may be connected to the payment module's 124 male adapter 602, and the MDB male adapter 612 may be connected to the payment module's 124 female adapter 604. The resulting in-line configuration is shown in Figure 7. It should be noted that the payment module 124 is designed to allow pass-through communication. Therefore, if the payment processing system between the mobile device and the machine is not enabled (e.g., for a particular purchase or because it is simply turned off), the MDB functions as if the payment module 124 were not present, and the automated retail machine 122 can function normally. In Figure 7, the automated retail machine 122 includes a display 722 that displays the user's selections, current credit, etc. In Figure 7, the automated retail machine 122 further includes a touchscreen display 724 and buttons 726 for product selection.

[0049] User Interface and Related Processes

[0065] 8 is a schematic flow diagram of a process 800 for authenticating a user conducting a transaction with a payment processing system 100 according to some embodiments. In some implementations, the payment processing system 100 includes one or more payment modules 124 (e.g., each associated with a respective automated retail machine 122, such as a vending machine, that sells goods and / or services), one or more mobile devices 104, and a server 108. Each of the one or more mobile devices 104 runs 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 in the payment processing system 100 (e.g., the server 108 and the payment modules 124). 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 in the context of each payment module 124 and each mobile device 104 in the payment processing system 100.

[0050]

[0066] The payment module 124 broadcasts 802 an information packet via short-range communication capabilities (e.g., BLE). The information packet includes at least an authorization code and a unique identifier (i.e., a device ID) associated with the payment module 124. In some implementations, the information packet further includes the 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. The information packet is further described below with reference to FIG. 10A.

[0051]

[0067] In some implementations, the payment module 124 sends a unique authorization code every X seconds (e.g., 100 ms, 200 ms, 500 ms, etc.). In some implementations, the unique authorization code is a randomly or pseudo-randomly generated number. In some implementations, the payment module 124 initializes a random number, and the authorization code is a sequential count from this random number. In such implementations, the payment module 124 does not store all valid authorization codes, but instead stores the earliest valid (unexpired) counter. In some implementations, the authentication code included in the broadcasted information packet is a hash value of a randomly or pseudo-randomly generated number or sequential number.

[0052]

[0068] In some implementations, the payment module 124 stores the broadcasted 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 implementations, the broadcasted authorization code is a single-use code. As such, the broadcasted authorization code may be used with only one mobile device 104 before being disabled and / or deleted to prevent replay attacks. In some implementations, the payment module 124 stores previously broadcasted authorization codes for a predetermined amount of time (e.g., Y minutes) before the authorization code expires and is deleted. In some implementations, the authorization code is encrypted with a shared secret key known by the server system 108 but unique to the payment module 124.

[0053]

[0069] The mobile device 104 receives the broadcasted information packet, and the mobile device 104 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 broadcasted information packet and automatically transmits an authorization request to the server system 108 when the mobile device 104 is within the communication zone (i.e., BLE range) of the payment module 124, or transmits an authorization request to the server system 108 when the mobile device 104 is within the authorization zone of the payment module 124.

[0054]

[0070] In some implementations, the broadcasted information packet includes a baseline authorization zone threshold (i.e., authorization zone criterion) 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 implementations, the mobile device 104 (or an application associated with the client-side module 102) offsets the baseline authorization zone threshold based on the receive strength of its short-range communication capabilities (e.g., BLE radio / transceiver) and / or other similar factors. In some implementations, the authorization request includes at least the authorization code that was included in the broadcasted information packet, an identifier associated with the user of the mobile device 104 or the user account through which the user of the mobile device 104 logged into the application (i.e., user ID), and an identifier associated with the payment module 124 (i.e., device ID). In some implementations, the authentication code included in the authorization request is a cleartext hash value. Authorization requests are further described below with reference to FIG. 10B.

[0055]

[0071] After receiving the authorization request, the server system 108 processes the authorization request (806). In some implementations, 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 secret key. The server system 108 determines whether the user associated with the user ID in the authorization request has sufficient funds in an account to perform a transaction at the automated retail machine 122 to which the payment processing system is coupled with the payment module 124 corresponding to the device ID.

[0056]

[0072] 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 implementations, 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., the authorization code is corrupted or hacked). In some implementations, 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 their account or has exceeded a predetermined daily limit. In some implementations, in addition to the authorization grant token (or without the authorization grant token 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, the transaction is authorized, insufficient balance, authorization is denied, etc. In some implementations, the server system 108 sends an authorization grant token for an amount equal to zero, which the payment module 124 interprets as authorization being denied or failed for any number of reasons, including but not limited to insufficient balance or credit. In some implementations, the mobile device 104 stores the authorization grant token (e.g., in the user data 264) until a trigger condition is detected.

[0057]

[0073] The mobile device 104 receives the authorization grant token, after which the mobile device 104 detects the trigger condition (810). In some implementations, the mobile device 104 (or an application) detects the trigger condition via a hands-free mode (e.g., upon entering a payment zone of the payment module 124) or a manual mode (e.g., interacting with the application's user interface to initiate a transaction with a payment acceptance unit associated with the payment module 124).

[0058]

[0074] In some implementations, the trigger condition is met when the mobile device 104 detects user input in a user interface displayed by the mobile device 104. For example, referring to Figure 11A, a transaction is initiated between a user of the mobile device 104 and a snack machine on the eighth floor when the mobile device 104 detects an upward swipe gesture originating from area 1120 of the user interface 1108. In another example, referring to Figure 11D, a transaction is initiated between a user of the mobile device 104 and a snack machine on the eighth floor when the mobile device 104 detects that suggestion A 1152 is selected by contact 1166.

[0059]

[0075] In some implementations, the trigger condition is met when the mobile device 104 observes an RSSI from each automated retail machine that is equal to or exceeds the payment zone condition criterion. For example, when the mobile device 104 enters the payment zone, a transaction between each automated retail machine and the user of the mobile device 104 is automatically initiated. In some implementations, after the RSSI observed from each retail machine is equal to or exceeds 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 display notification, or a vibration, to the user to confirm the user's intent to initiate a transaction with each retail machine. Continuing with this example, the user may confirm their intent to initiate a transaction with each retail machine by flicking the mobile device 104 toward the automated retail machine, shaking the mobile device, providing an audible command, or performing a touch input / gesture on a displayed user interface.

[0060]

[0076] In some implementations, 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 corresponding to the unused authorization grant to the server system 108. In some implementations, the server system 108 refuses or limits the number of authorization grants sent to the mobile device 104 until it receives transaction information or cancellation of an authorization for any outstanding authorization grants sent to the mobile device 104.

[0061]

[0077] In response to detecting the trigger condition, the mobile device 104 transmits (812) the authorization grant 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 display 722 or 724 shown in FIG. 7 ), and the user interacts with the automated retail machine 122's input mechanism (e.g., via button 726 or touchscreen display 724 in FIG. 7 ) to purchase products and / or services.

[0062]

[0078] It should be understood that the specific order described for the process in Figure 8 is merely an example and is not intended to indicate that the described order is the only order in which operations can be performed. Those skilled in the art will recognize various ways to change the order of operations described herein. Additionally, it should be noted that other process details described herein in connection with other methods and / or processes described herein (e.g., process 900 and method 1200) also apply equally to process 800 described above in connection with Figure 8.

[0063]

[0079] 9 is a schematic flow diagram of a process 900 for processing confirmation information in a payment processing system 100 according to some embodiments. In some implementations, the payment processing system 100 includes one or more payment modules 124 (e.g., each associated with a respective automated retail machine 122, such as a vending machine, that sells goods and / or services), one or more mobile devices 104, and a server 108. Each of the one or more mobile devices 104 runs 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 in the payment processing system 100 (e.g., the server 108 and the payment modules 124). 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 900 will be described in the context of each payment module 124 and each mobile device 104 coupled to each automated retail machine 122 in the payment processing system 100. In process 900, the payment module 124 receives a first confirmation of the first transaction via the mobile device 104 that initiated the first transaction.

[0064]

[0080] The payment module 124 obtains (902) a first notification from the automated retail machine 122 indicating the completion of the first transaction. For example, following process 800 of FIG. 8 , a user of the mobile device 104 selects products 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 touchscreen display 724 shown in FIG. 7 ), and the automated retail machine 122 dispenses the selected products. Continuing with the example, after the products are dispensed, the transaction is complete and the payment module 124 obtains a notification from the machine that the transaction is complete. In some implementations, the notification includes the amount of the transaction and (optionally) machine status information related to the automated retail machine 122, such as inventory information for one or more products in the automated retail machine 122.

[0065]

[0081] 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 implementations, 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 implementations, the payment module 124 maintains the authorization code and / or authorization grant token included in the original broadcast packet and includes the authorization code in the first transaction information. In some implementations, the authorization code is encrypted with a private key corresponding to the payment module 124. This private key is shared with the server system 108 but not with the mobile device 104. In some implementations, the first transaction information further includes other information, such as machine status information included in the first notification and transaction information corresponding to a previously interrupted transaction. For further description of the transaction information 1050, see FIG. 10D and corresponding text.

[0066]

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

[0067]

[0083] 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.).

[0068]

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

[0069]

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

[0070]

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

[0071]

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

[0072]

[0088] It should be understood that the specific order described for the process in Figure 9 is merely an example and is not intended to indicate that the described order is the only order in which operations can be performed. Those skilled in the art will recognize various ways to change the order of operations described herein. Additionally, it should be noted that other process details described herein in connection with other methods and / or processes described herein (e.g., process 800 and method 1200) also apply equally to process 900 described above in connection with Figure 9.

[0073]

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

[0074]

[0090] In some implementations, the device ID 1002 is a unique identifier corresponding to the payment module 124 broadcasting the information packet 1000.

[0075]

[0091] In some implementations, the authorization code 1004 is a cleartext hash value. In some implementations, the payment module 124 randomly or pseudo-randomly generates a number or determines a sequential number (see step 802 of process 800 in FIG. 8 ) and performs a predetermined hash function (e.g., SHA-256) on the number to create the hash value as the authorization code 1004. In some implementations, 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 by the server system 108 and enables the server system 108 to decrypt the authorization code 1004 and encrypt the authorization grant token, but is not shared with the mobile device 104. In some implementations, encryption between the server system 108 and the payment module 124 is achieved with two pairs of public / private keys.

[0076]

[0092] In some implementations, the firmware version information 1006 identifies the current firmware version 1012 of the payment module 124. In some implementations, the firmware version information 1006 further includes update status information 1014 that indicates 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.

[0077]

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

[0078]

[0094] In some implementations, the zone criteria information 1010 specifies authorization zone criteria 1024 (e.g., a baseline authorization zone threshold indicating a baseline RSSI that a mobile device 104 (or application) is required to observe before entering the authorization zone of the payment module 124) and / or payment zone criteria 1026 (e.g., a baseline payment zone threshold indicating a baseline RSSI that a mobile device 104 (or application) is required to observe before entering the payment zone of the payment module 124). In some implementations, the baseline authorization zone threshold and the baseline payment zone threshold are default values ​​determined by the server system 108 or stored as variables by the application. In the latter case, the authorization zone criteria 1024 and the payment zone criteria 1026 are offsets that compensate for the strength and / or receiver sensitivity of the near-field communication capabilities (e.g., BLE radio / transceiver) of the payment module 124. Alternatively, the zone criteria information 1010 indicates the interval between the baseline authorization zone threshold and the baseline payment zone threshold. Thus, the mobile device 104 (or application) determines the baseline authorization zone threshold and the baseline payment zone threshold based on the interval value and a default value for the baseline authorization zone threshold or the baseline payment zone threshold. For example, if the interval indicates -10 db and the default baseline payment zone threshold is -90 db, then the baseline authorization zone threshold is -80 db. Continuing with this example, after determining the baseline authorization zone threshold and the baseline payment zone threshold, the mobile device 104 (or application) may further adjust the baseline authorization zone threshold and / or the baseline payment zone threshold based on the strength and / or receiver sensitivity of its near-field communication capabilities (i.e., BLE radio / transceiver).

[0079]

[0095] 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 implementations, the authorization request 1030 includes at least a device ID 1002, a user ID 1034, and an authorization code 1004.

[0080]

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

[0081]

[0097] In some implementations, the user ID 1034 is a unique identifier associated with the user of the mobile device 104 that sends the authorization request 1030 to the server system 108. In some implementations, the user ID 1034 is associated with the user account through which the user of the mobile device 104 logged into the application.

[0082]

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

[0083]

[0099] 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 implementations. In some implementations, the server system 108 generates the authorization grant token 1040 in response to determining 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 an account with the payment processing system. In some implementations, the authorization grant token 1040 includes at least the device ID 1002, the user ID 1034, the authorization amount 1046, (optionally) the expiration period 1048, and (optionally) the authorization code 1004. In some implementations, the authorization grant token 1040 is encrypted with a shared secret corresponding to the payment module 124.

[0084]

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

[0085]

[0101] In some implementations, 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 .

[0086]

[0102] In some implementations, the authorization amount 1046 is the maximum amount that the user of the mobile device 104 is authorized to conduct transactions for using the authorization grant token 1140. For example, the authorization amount 1046 is predetermined by the user of the mobile device 104 or the server system 108 based on a daily limit, based on the user's total account balance, or based on the user's risk profile associated with the user ID 1034.

[0087]

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

[0088]

[0104] In some implementations, the authorization grant token 1040 further includes the authorization code 1004 that was included in the authorization request 1030. In some implementations, 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 1024. Then, when the mobile device 104 sends the authorization grant token 1040 to the payment module 124 after detecting the trigger condition, 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 matches the hash value included in the decrypted authorization grant token 1040 to a previously broadcast valid (i.e., unrevoked and unused) hash value (e.g., a stored authorization code) to determine the validity of the hash value (known only to the payment module 124).

[0089]

[0105] 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 implementations. In some implementations, the transaction information 1050 includes a transaction ID 1052, a device ID 1054, a user ID 1056, (optionally) an authorization code 1058, transaction status information 1060, transaction details 1062, and miscellaneous information 1064 for each transaction. In some implementations, the transaction information 1050 is encrypted with a shared secret key corresponding to the payment module 124.

[0090]

[0106] In some implementations, the transaction ID 1052 is a unique identifier corresponding to each transaction. In some implementations, the transaction ID 1052 is encoded based on or associated with the time and / or date and location at which each transaction occurred.

[0091]

[0107] In some implementations, the device ID 1054 is a unique identifier corresponding to the payment module 124 that performed each transaction.

[0092]

[0108] In some implementations, the user ID 1056 is an identifier associated with the user of the mobile device 104 that initiated each transaction.

[0093]

[0109] In some implementations, 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 each transaction. In some implementations, the authorization code 1056 is encrypted with a unique encryption key corresponding to the payment module 124.

[0094]

[0110] In some implementations, the transaction status information 1060 includes an indication of whether each transaction is completed, incomplete, or aborted. For example, each transaction is incomplete if the automated retail machine 122 jams and the user does not receive the product associated with each transaction. For example, each transaction is aborted if the user walks away from the automated retail machine 122 after the amount has been credited for that transaction. In another example, each transaction is aborted if it times out after a predetermined period of time because the user did not select a product at the automated retail machine 122. In another example, a transaction is aborted if the user activates the bill or coin return mechanism of the automated retail machine 122.

[0095]

[0111] In some implementations, the transaction details 1062 indicate the amount of each transaction, or the amount of each of multiple transactions (e.g., in the case of a multiple-sale scenario). In some implementations, the transaction details 1062 also indicate other information about each transaction, such as the item dispensed by the automated retail machine 122, the type of transaction (e.g., coin, bill, credit card, manual mode, hands-free mode, etc.).

[0096]

[0112] In some implementations, the miscellaneous information 1064 includes other information about 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 verification request to the server system 108 to implement new firmware. In another example, the miscellaneous information 1064 includes transaction information for one or more previously aborted transactions. In another example, the miscellaneous information 1064 includes transaction information for one or more past monetary and / or other cashless transactions (e.g., credit card or bank card payments at the automated retail machine 122). In another example, the miscellaneous information 1064 includes inventory information for one or more products at the automated retail machine 122.

[0097]

[0113] Attention now turns to implementations of user interfaces ("UIs") and related processes that may be implemented on a mobile device 104 that includes zero or more speakers 1102, zero or more microphones 1104, and a display 1106. For example, the display 1106 is a touchscreen (also referred to herein as a "touchscreen display") adapted to receive one or more touches and display information (e.g., media content, a website and its web pages, and / or the user interface of an application 326). Figures 11A-11G illustrate exemplary user interfaces that facilitate the display of promotional offers, according to some embodiments.

[0098]

[0114] Although some of the following examples are shown in relation to input on a touchscreen (a combined touch-sensitive surface and display), in some implementations, the device detects input on a touch-sensitive surface that is independent of the display. In some implementations, the touch-sensitive surface has a major axis that corresponds to a major axis of the display. According to these implementations, the device detects contact with the touch-sensitive surface at locations that correspond to locations on the display. In this manner, user input detected by the device on the touch-sensitive surface is used by the device to operate a user interface on the device's display when the touch-sensitive surface is separate from the display. It should be understood that similar methods are optionally used for the other user interfaces described herein.

[0099]

[0115] Additionally, while the following examples are primarily illustrated 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 implementations, one or more contacts are replaced with 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., in place of the contact) followed by cursor movement along the path of the swipe (e.g., in place of the contact movement). As another example, a tap gesture is optionally replaced by a mouse click (e.g., in place of the contact detection followed by the end of the contact detection) with the cursor over the location of the tap gesture, or by a physical button press. Similarly, when multiple user inputs are detected simultaneously, it should be understood that multiple computer mice are optionally used simultaneously, or that a mouse and finger contacts are optionally used simultaneously.

[0100]

[0116] 11A-11G illustrate a user interface 1108 displayed on each mobile device 104 (e.g., a mobile phone associated with a user) for an application associated with the payment processing system 100. However, those skilled in the art will understand 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 reference to FIGS. 12A-12C. Those skilled in the art will understand that the following user interfaces are merely examples. Furthermore, those skilled in the art will understand that additional affordances and / or user interface elements, or fewer affordances and / or user interface elements, may be used in practice.

[0101]

[0117] 11A shows the mobile device 104 displaying a transaction initiation screen 1110 for a snack machine on the eighth floor. In FIG. 11A, the transaction initiation screen 1110 includes a series of indicators 1116 indicating that the snack machine on the eighth floor is one of three automated retail machines at which the user is authorized to initiate a transaction. For example, a user of the mobile device 104 can access the second of the three automated retail machines by performing a left-to-right swipe gesture on the user interface 1108 (or, alternatively, a right-to-left swipe gesture), and can access the first of the three automated retail machines by performing a right-to-left swipe gesture on the user interface 1108 (or, alternatively, a left-to-right swipe gesture). 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 a user of the mobile device 104 can update the transaction start screen 1110 by selecting affordance 1114 (e.g., with a tap gesture).

[0102]

[0118] 11A further indicates 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 snack machine on the eighth floor by performing an upward swipe gesture starting 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) “Special Offers” area 1122, and the user of the mobile device 104 can “like” or favorite the snack machine on the eighth floor by selecting (e.g., with a tap gesture) affordance 1124. FIG. 11A further indicates that the mobile device 104 detects contact 1140 at a location corresponding to “Special Offers” area 1122.

[0103]

[0119] 11B shows the mobile device 104 displaying a special offers screen 1130 of a snack machine on the eighth floor. In FIG. 11B, the special offers screen 1130 includes a first region corresponding to "Suggestion A" 1152 for product A with image A of product A, a second region corresponding to "Suggestion B" 1154 for product A with image A of product A, and a third region corresponding to "Suggestion C" 1156 for product B with image B of product B. The special offers screen 1130 further includes an update affordance 1151 that, when activated (e.g., via a tap gesture), updates the special offers screen 1130. In FIG. 11B, none of suggestions A, B, or C are currently selected. A user of the mobile device 104 can select "Suggestion A" 1152 by performing a gesture (e.g., a tap gesture) at selection affordance 1153. Similarly, a user of the mobile device 104 can select “Suggestion B” 1154 by performing a gesture (e.g., a tap gesture) at selection affordance 1155, or can select “Suggestion C” 1156 by performing a gesture (e.g., a tap gesture) at selection affordance 1157. A user of the mobile device 104 can also dismiss or delete any of suggestions A, B, or C by performing a right-to-left swipe gesture (or, in other implementations, a left-to-right swipe gesture) in the corresponding region. FIG. 11B further shows the mobile device 104 detecting a right-to-left swipe gesture with contact 1106 moving from a first position 1162-a to a second position 1162-b within a second region corresponding to “Suggestion B” 1154.

[0104]

[0120] In some implementations, the special offers screen 1130 further includes a fourth region corresponding to "no offers selected." For example, a user of the mobile device 104 may view promotional offers on the special offers screen 1130 but not want to apply any of the offers to future transactions with the snack machine on the eighth floor. In that case, the user of the mobile device 104 may select (e.g., with a tap gesture) the "no offers selected" region, in response to which the mobile device 104 re-displays the transaction initiation screen 1110 shown in FIG. 11A .

[0105]

[0121] 11C shows the mobile device 104 displaying a delete affordance 1164 in the second region corresponding to "Suggestion 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 "Suggestion B" 1154 to be deleted from the special suggestions screen 1130. FIG. 11C further shows the mobile device 104 detecting a contact 1166 at a location corresponding to the delete affordance 1164.

[0106]

[0122] 11C 。 Figure 11D shows the mobile device 104 having finished displaying "Suggestion B" 1154 within the special offers screen 1130 in response to detecting a selection of the delete affordance 1164 in Figure 11C . Figure 11D also shows the mobile device 104 detecting contact 1168 corresponding to the location of the selection affordance 1153 of "Suggestion A" 1152. Alternatively, in some implementations, the user of the mobile device may not want any suggestions to apply to future transactions with the snack machine on the eighth floor. In that case, the user can select affordance 1112 (e.g., with a tap gesture) or perform a predetermined gesture on the special offers screen 1130 to redisplay the transaction start screen 1110 shown in Figure 11A .

[0107]

[0123] Figure 11E illustrates selection affordance 1153 being selected in response to detecting selection of selection affordance 1153 in Figure 11D. In some implementations, a transaction with the snack machine on the eighth floor is automatically initiated in response to detecting selection of selection affordance 1153 in Figure 11D. In other implementations, after detecting selection of selection affordance 1153 in Figure 11D, mobile device 104 again displays transaction initiation screen 1110 (shown in Figure 11A), and a transaction with the snack machine on the eighth floor is initiated in response to detecting an upward swipe gesture originating from area 1120 of transaction initiation screen 1110.

[0108]

[0124] FIG. 11F shows the mobile device 104 displaying a product code screen 1170 that prompts the user of the mobile device 104 to obtain a product code (e.g., a UPC code, SKU, etc.) for product A to verify “Suggestion A” 1152 selected in FIG. 11D. The product code screen 1170 further 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) within the field of view of the camera of the mobile device 104 is displayed within 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 within the current field of view) or scan the UPC code 1174 by tapping within 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 the mobile device 104 has a prepaid balance of $99.00 due to the purchase of Product A, which is $1.00 less than the amount shown in FIGS. 11A-11E.

[0109]

[0125] 11G shows the mobile device 104 displaying the proposal verification screen 1180. In some implementations, the mobile device 104 displays the proposal verification screen 1180 after the user completes a transaction with the snack machine on the eighth floor and the server verifies the product code information (e.g., the UPC scanned in FIG. 11F). In FIG. 11G, the proposal verification screen 1180 indicates that "Proposal A" 1152 has been verified and $0.25 has been credited to the user's balance. FIG. 11G further indicates that the user of the mobile device 104 now has a prepaid balance of $99.25, $0.25 more than the amount shown in FIG. 11G, because "Proposal A" 1152 has been verified and the $0.25 has been credited for "Proposal A" 1152.

[0110]

[0126] 12A-12C illustrate a flow diagram of a method 1200 for providing and processing promotional offers in an automated retail machine according to some implementations. In some implementations, the method 1200 is performed by a mobile device including a display, one or more processors, and a memory. For example, in some implementations, the method 1200 is performed by the mobile device 104 (FIGS. 1 and 2) or components thereof (e.g., the client-side module 102, FIG. 1 and 2). In some implementations, the method 1200 is governed by instructions stored on a non-transitory computer-readable storage medium, which are executed by one or more processors of the mobile device. Some operations of the method 1200 are optionally combined and / or the order of some operations is optionally changed.

[0111]

[0127] In some implementations, 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 to access and communicate 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 an entity that supplies, operates, and / or manufactures the payment module 124.

[0112]

[0128] In some implementations, before displaying the one or more promotional offers, the mobile device acquires an information packet broadcast by a payment module coupled to the automated retail machine, the information packet including at least an authorization code and a unique identifier corresponding to the payment module, sends a request for transaction authorization to a server, the information packet including the authorization code and the unique identifier corresponding to the payment module, and receives authorization information from the server in response to the request for transaction authorization, the authorization information including an authorization grant token for initiating a transaction with the automated retail machine coupled to the payment module and one or more promotional offers from the server (1202). As described in process 800, the mobile device 104 or a component thereof (e.g., broadcast acquisition module 230, FIG. 2) acquires the information packet broadcast by the payment module 124, the information packet including at least the authorization code and an identifier associated with the payment module 124. Subsequently, the mobile device 104 or a component thereof (e.g., transaction authorization module 232, FIG. 2) 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 coupled. In response to determining 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 implementations, the mobile device 104 stores the authorization grant token (e.g., in user data 265 of 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 of FIG. 2 ). In some implementations, the trigger condition is met when the mobile device 104 detects user input on a user interface displayed by the mobile device 104. For example, with reference to FIG. 11A , a transaction is initiated between a user of the mobile device 104 and a snack machine on the eighth floor when the mobile device 104 detects an upward swipe gesture originating from region 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 a snack machine on the eighth floor when the mobile device 104 detects selection of suggestion A 1152 via contact 1166.

[0113]

[0129] In some implementations, the mobile device 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 the mobile device communicates 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.

[0114]

[0130] The mobile device displays 1206 one or more promotional offers on the display. In some implementations, the mobile device 104 displays only promotional offers for products for which the user has sufficient balance. For example, a soda costs $2.00, a $0.50 discount is being promoted, and the user only has $1.00. In this example, the mobile device forgoes displaying the soda promotion. For example, FIG. 11B shows the mobile device 104 displaying a special offers screen 1130 for a snack machine on the eighth floor. In FIG. 11B, the special offers screen 1130 includes a first area corresponding to "Suggestion A" 1152 for product A with image A of product A, a second area corresponding to "Suggestion B" 1154 for product A with image A of product A, and a third area corresponding to "Suggestion C" 1156 for product B with image B of product B. Alternatively, in some implementations, one 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 the promotion. In some implementations, one or more advertisements are displayed in place of the one or more selectable promotional offers.

[0115]

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

[0116]

[0132] In some implementations, the user can reject or delete the suggestion, and the mobile device 104 sends this information to the server 108 for analysis purposes. In one example, FIG. 11C shows the mobile device 104 displaying a delete affordance 1164 in the second region corresponding to "Suggestion B" 1154 in response to detecting a right-to-left swipe gesture in FIG. 11B. Continuing the example, FIG. 11D shows the mobile device 104 having finished displaying "Suggestion B" 1154 in the special suggestions screen 1130 in response to detecting a selection of the delete affordance 1164 in FIG. 11C.

[0117]

[0133] In some implementations, one or more promotional offers are identified (1208) based on at least one of a unique identifier corresponding to the payment module, the current time and date, the location of the automated retail machine, the location of the mobile device, and a unique identifier corresponding to a user of the mobile device. In some implementations, the server 108 or a component thereof (e.g., offer determination module 328, FIG. 3) determines / identifies the one or more promotional offers based on the current time / date, the current location, a device ID associated with the payment module, a user ID associated with the user of the mobile device, etc. In some implementations, the mobile device 104 or a component thereof (e.g., offer module 234, FIG. 2) determines / identifies the one or more promotional offers from a collection of pre-stored offers based on the current time / date, the current location, a device ID associated with the payment module, a user ID associated with the 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, such as as part of an application update.

[0118]

[0134] In some implementations, promotional offers are identified based on products stocked at the 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, consider a snack vending machine and a soda vending machine side by side. The user first purchases a soda. Then, when the user transacts with the snack machine, the user is presented with a specific product offer (e.g., to enable cross-promotion between the soda and snack vendors). Alternatively, the offer may be based on what the user did not select at the soda machine or offers that were previously actively removed.

[0119]

[0135] In some implementations, the server 108 and payment module 124 provider manage a promotional marketplace to facilitate the placement of promotional offers by product manufacturers and distributors and to promote competition among various manufacturers and distributors. For example, a product distributor or manufacturer may place a promotional offer for a $0.25 discount on a particular item at all applicable community colleges in California on Thursdays between 2:00 PM and 4:00 PM Pacific Daylight Time. In another example, a product distributor or manufacturer may place a promotional offer for a 50% discount on a product at all applicable retail machines (e.g., to sell perishable sandwiches, etc.) on the day the product expires. In some implementations, cross-promotional or combined promotional offers may also be placed to allow users to receive credits (e.g., rebates) when they purchase a particular beverage and snack combination manufactured or sold by different entities.

[0120]

[0136] In some implementations, promotional offers (essentially subsidies) for all products in automated retail machines on an entity's campus are available only to select users. For example, all attorneys and staff at a law firm are given subsidized rates on snacks, but the cleaning staff do not benefit from the subsidized rates. In another example, all full-time employees are given subsidized rates on snacks, but temporary staff do not benefit from the subsidized rates.

[0121]

[0137] In some implementations, variable pricing is established where the base price of an item varies, and promotional offers can be added to the variable pricing scheme. For example, a merchant may want to lower the prices of all items at applicable machines during off-peak hours (e.g., 9:00 PM - 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 considers the transaction, the transaction confirmation information displayed on the mobile device 104 indicates that the user was charged only the reduced price, not the price displayed on the automated retail machine 122.

[0122]

[0138] The mobile device detects (1210) user input selecting each promotional offer of one or more promotional offers. For example, the user input may be touch input, voice input, etc. For example, FIG. 11D shows the mobile device 104 detecting selection of the selection affordance 1153 of "Offer A" 1152, and FIG. 11E shows selection affordance 1153 being selected in response to detecting selection of selection affordance 1153 in FIG. 11D. In some implementations, 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 implementations, each promotional offer is a negative promotional offer in which the transaction is rounded up to the nearest dollar and the additional amount is donated to the Cancer Research Foundation.

[0123]

[0139] The mobile device initiates (1212) execution of a transaction with an automated retail machine coupled to the payment module corresponding to the purchase of a product stocked by the automated retail machine. In some implementations, the transaction is initiated in response to selection of each promotional offer (i.e., a one-click transaction initiation process). For example, a transaction with the snack machine on the eighth floor is initiated automatically in response to detecting selection of selection affordance 1153 in FIG. 11D . In other implementations, the user performs an action to initiate a transaction with the automated retail machine after selecting a offer (i.e., a two-step transaction initiation process). For example, after detecting selection of selection affordance 1153 in FIG. 11D , the mobile device 104 again displays transaction initiation screen 1110 (shown in FIG. 11A ), and a transaction with the snack machine on the eighth floor is initiated in response to detecting an upward swipe gesture starting from area 1120 of transaction initiation screen 1110.

[0124]

[0140] In some implementations, execution of a transaction with an automated retail machine coupled to the payment module is initiated by transmitting an authorization grant token containing the authorization code included in the broadcast information packet to the payment module (1214). In some implementations, initiating execution of a transaction involves the mobile device 104 or a component thereof (e.g., transaction initiation module 238, FIG. 2 ) transmitting the stored authorization grant token to the payment module 124 for payment and the user manually selecting a product using the automated retail machine 122's user interface. As such, the automated retail machine 122 has no knowledge of the selected promotional offer, only that a payment was submitted by the user. For example, the automated retail machine 122 returns the transaction and the product information passed to the mobile device 104 by the payment module 124, but cannot determine or state whether it is the product corresponding to the offer. For example, a transaction completion notification may indicate, "I sold E3 for $1.00."

[0125]

[0141] The mobile device receives a transaction completion notification from the payment module indicating that a product corresponding to each selected promotional offer has been sold by the automated retail machine (1216). In some implementations, 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 details, other information about each payment module 124 and / or the automated retail machine 122 to which each payment module 124 is coupled, etc.) from the payment module 124 after a user manually selects products using a user interface of the automated retail machine 122. In some implementations, the transaction completion notification includes information about the goods / services associated with the transaction, the automated retail machine 122's current inventory, information related to one or more previous cash transactions, information related to one or more aborted transactions processed by the payment module 124, and / or other information about the automated retail machine 122, such as an error condition or maintenance status. In some implementations, the payment module 124 sends an error message instead of a transaction completion notification if the transaction is aborted or an error occurs during the transaction, such as the lack of a requested product / service or a sales jam.

[0126]

[0142] 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 codes of the sold products to verify each promotional offer (1218). In some implementations, the mobile device 104 or a component thereof (e.g., product code processing module 242, FIG. 2) displays a scan interface for capturing the product codes of the sold items after receiving the transaction completion notification. For example, 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 “Proposal A” 1152 selected in FIG. 11D. The product code screen 1170 further 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) within the field of view of the camera of the mobile device 104 is displayed in the product code scanner window 1172. For example, a user of the mobile device 104 may capture an image of product A (including the UPC code 1174 within the current field of view) or scan the UPC code 1174 by tapping within the product code scanner window 1172, issuing an audible command, pressing a predetermined physical button on the mobile device 104, etc.

[0127]

[0143] In other implementations, 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 a display prompting the user of the mobile device 104 to manually enter or otherwise obtain the product code for the sold item. In other implementations, the mobile device 104 or a component thereof (e.g., product code processing module 242, FIG. 2) provides a sequence of audible tones, voice prompts, or tactile / haptic vibrations prompting the user of the mobile device 104 to enter or otherwise obtain the product code for the sold item.

[0128]

[0144] The mobile device obtains (1220) the product code of 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 implementations, the mobile device 104 or a component thereof (e.g., product code processing module 242, FIG. 2 ) receives the product code.

[0129]

[0145] In some implementations, acquiring 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 implementations, acquiring 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 from within an application associated with the payment processing system 100 (e.g., product code processing module 242, FIG. 2 ) that enables the user to capture an image of the product with the 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, where the product code is extracted. In another example, the user of the mobile device 104 can manually enter the product code from within the application (e.g., via a virtual keypad) or via a website associated with the payment processing system 100.

[0130]

[0146] 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 promotion verification information from the server and displays the promotion verification information on a display indicating whether each promotional offer was verified. In some implementations, the mobile device 104 or a component thereof (e.g., product code processing module 242, FIG. 2) verifies the obtained product code or transmits the obtained product code to the server 108 for verification. In some implementations, 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 followed the prompts and the mobile device 104 ultimately obtained the product code. In some implementations, the server 108 determines whether the terms of each promotional offer were based on the transaction and the product code. For example, the server 108 determines whether the appropriate product code was obtained for each promotional offer, whether each promotional offer has expired, whether the user has met a buy-N-item-get-1-free condition, whether the user has met cross-promotion conditions, etc. In some implementations, the offers are validated by the server 108 and applied to the user's account.

[0131]

[0147] In some implementations, 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. For example, FIG. 11G shows the mobile device 104 displaying an offer verification screen 1180 indicating that “Offer A” 1152 was verified and $0.25 was credited to the user’s balance. FIG. 11G further indicates that the user of the mobile device 104 has a prepaid balance of $99.25, which is $0.25 more than the amount shown in FIG. 11G , because “Offer A” 1152 was verified and $0.25 was credited for “Offer A” 1152. For example, if a user is eligible to receive a free product with their fifth purchase, and the product that is the subject of the current transaction was only the first item purchased, the promotion verification information indicates that the user must purchase three more to receive the free product. In some implementations, the promotion verification information includes coupons for products or services not associated with the automated retail machine 122. For example, a user may be emailed a coupon for $5 off an amusement park with the purchase of a soda.

[0132]

[0148] In some implementations, after obtaining the product code, the mobile device determines (1228) whether a predetermined time period has expired. In response to determining that the time period has expired, the mobile device provides a notification to the mobile device user indicating that each promotional offer has expired. In response to determining that the time period has not expired, the mobile device transmits the product code to the server. In some implementations, the predetermined time period corresponds to the time from (A) the initiation of execution of the transaction or the display of the product code prompt to (B) the acquisition of the product code, or some other time period. For example, the mobile device 104 must receive the product code within five minutes of the prompt or within five minutes of the initiation of the transaction. In some implementations, this may occur several hours or a day later. In some implementations, 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.

[0133]

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

[0134]

[0150] In some implementations, the promotional verification information indicates (1230) the price of the product after each promotional offer is applied. For example, the mobile device 104 displays the total that will be deducted from the user's account or charged to the user's linked bank card after applying the promotional offer to the base purchase price included in the notification completion information. For example, FIG. 11G shows 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, because "Proposal A" 1152 was verified and $0.25 was credited for "Proposal A" 1152.

[0135]

[0151] In some implementations, the mobile device sends a transaction completion notification to the server (1232). In some implementations, the mobile device 104 or a component thereof (e.g., information relay module 244, FIG. 2 ) sends a transaction completion notification (e.g., transaction status information, transaction details, other information about each payment module 124 and / or the automated retail machine 122 to which the payment module 124 is coupled, etc.) or a portion thereof to the server 108 before or along with the product code. In some implementations, the transaction completion notification or a portion thereof is sent to the server 108 regardless of whether the user follows prompts and the mobile device ultimately obtains the product code.

[0136]

[0152] It should be understood that the specific order of operations described in Figures 12A-12C is merely an example and is not intended to indicate that the described order is the only order in which the operations can be performed. Those skilled in the art will recognize various ways of reordering the operations described herein. Additionally, it should be noted that other process details described herein in connection with other methods and / or processes described herein (e.g., processes 800 and 900) also apply equally to method 1200 described above in connection with Figures 12A-12C.

[0137]

[0153] Although specific embodiments have been described above, it will be understood that the present application is not intended to be limited to these specific embodiments. On the contrary, the present application includes alternatives, modifications, and equivalents falling within the spirit and scope of the appended claims. Numerous specific details have been set forth to facilitate 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 implementation.

Claims

1. A mobile device comprising a display, one or more processors, a wireless communication module, and a memory, identifying an automated retail machine capable of accepting payments from a mobile payment application executing on the mobile device, the identification based at least in part on a unique identifier corresponding to the automated retail machine; displaying on said display one or more promotional offers related to said automated retail machine; detecting an input from a user of the mobile device selecting each promotional offer of the one or more promotional offers; initiating execution of a transaction with the automated retail machine via the wireless communication module, the transaction corresponding to a purchase of a product stored at the automated retail machine or a service performed at the automated retail machine; obtaining a code for the purchased product or service based on user input provided at the automated retail machine; After obtaining the code, transmitting the code to a server via the wireless communication module; In response to transmission of said code, receiving promotional validation information from the server via the wireless communication module; displaying on the display an indication of whether each promotional offer has been verified based on the promotion verification information; A method comprising:

2. The one or more promotional offers:

2. The method of claim 1, wherein the mobile device is identified based on at least one of the unique identifier corresponding to the automated retail machine, at least one of a current time and date, a location of the automated retail machine, a location of the mobile device, and a unique identifier corresponding to a user of the mobile device.

3. The step of obtaining the code includes: capturing an image relating to the product or service including the code; extracting the code from the captured image; 3. The method of claim 1 or 2, further comprising:

4. Obtaining the code includes: scanning the code with a scanner unit of the mobile device; The method of any one of claims 1 to 3, further comprising:

5. determining whether a predetermined period of time has expired after obtaining the code; responsive to determining that the time period has expired, providing a notification to the user of the mobile device indicating that each promotional offer has expired; responsive to determining that the period has not expired, transmitting the code to the server; The method of any one of claims 1 to 4, further comprising:

6. 6. The method of claim 1, further comprising selecting the one or more promotional offers related to the automated retail machine based at least in part on products stocked by the automated retail machine or services provided by the automated retail machine before displaying the one or more promotional offers related to the automated retail machine on the display.

7. 7. The method of claim 6, wherein selecting the one or more promotional offers is further based, at least in part, on at least one previous transaction completed by the user at a different automated retail machine than the automated retail machine.

8. 8. The method of claim 1, wherein each selected promotional offer is associated with both time-based and product-based conditions that limit use of each selected promotional offer at the automated retail machine, and further wherein the promotional verification information includes an indication of whether the transaction satisfied the time-based and product-based conditions.

9. detecting a request from the user to reject a particular promotional offer from the one or more promotional offers while displaying the one or more promotional offers on the display; In response to detecting the request, (i) ceasing to display the particular promotional offer on the display, and (ii) transmitting, via the wireless communication module, information indicating that the user has rejected the particular promotional offer; 9. The method of claim 1, further comprising:

10. 10. The method according to claim 1, wherein the automated retail machine is a washing machine with a payment function, a dryer with a payment function, a vending machine, a parking meter, a toll booth, a game machine, a kiosk, a photo booth, a toll booth, or a ticket issuing machine.

11. The display and a wireless communication module; one or more processors; a memory for storing one or more programs to be executed by said one or more processors; 10. A mobile device comprising: one or more programs including instructions for performing the method of any one of claims 1 to 9.

12. 10. A non-transitory computer-readable storage medium storing one or more programs, the one or more programs comprising instructions that, when executed by a mobile device having a display, a wireless communication module, and one or more processors, cause the mobile device to perform the method of any one of claims 1 to 9.

Images