JP2022506858A - Asynchronous mobile payment methods and systems for multiple face-to-face transactions in parallel - Google Patents

Abstract

A mobile consumer device with a display, processor and memory: Near the consumer device based on the broadcast information transmitted by the first merchant device and including the first identifier corresponding to the first merchant device. Identifies the merchant device; sends a first identifier to the server, receives electronic communications from the server containing identification and transaction information related to the merchant; displays the identification information, and receives the user selection of the merchant identification information. In response to this, it displays the merchant transaction information, receives the supplementary user information, and sends the supplementary transaction information to the server for the completion of the transaction.

Description

Technical field
[0001] The present application relates to the field of payment processing systems, in particular to mobile device to server payment processing systems initiated by short-range mobile device-to-device communication.

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

[0003] In addition, other consumers who want to pay to the same merchant must wait for the current transaction to complete processing. Consumers interact with merchants in sequence and wait for their turn.

[0004] This system is acceptable in traditional retail situations where one consumer purchases a product or service and the merchant requires a "checkout" task. In such an electronic payment system, the payment transaction is first initiated by the merchant (eg, requiring the consumer to pay a certain amount). These electronic payment systems do not work well if multiple consumers need to pay a single merchant at about the same time or if the merchant is unable to initiate payment processing.

[0005] Conversely, in automated retailers (such as vending machines), merchants (machines in this case) are always ready to accept payments. Consumers initiate payment processing by presenting their electronic payment credit certificate, which may include physical cards or mobile devices. These interactions are still limited to one consumer at a time.

Overview
[0006] An embodiment described herein is a method of enabling electronic payment via a mobile device so that multiple consumers can initiate superimposed face-to-face payments to a single merchant at the same time or at about the same time. And provide the system. Further, in some embodiments, the consumer has the option of sending the payment to the merchant without the merchant having to first request the payment.

[0007] There are many use cases for such systems, some of which are currently processed solely by cash payments (existing electronic payment systems allow multiple parties to pay payments to a single merchant. Because it does not correspond to the need to send). One exemplary use case involves paying a street performer who traditionally offers a box, hat or open guitar case (collectively referred to as a collection box) for spectator payments. While the performer is acting, any number of spectators may put cash in the collection box to pay the performer.

[0008] In particular, the performer (or merchant in various contexts) is not required to start paying with each consumer and does not need to stop what the performer is doing. Also, multiple consumers may pay the performer / merchant without waiting for each transaction to close. This transaction is asynchronous because the performer / merchant does not have to approve the transaction prior to the next payment and does not have to approve the payment at all. The methods and systems described herein address this and similar face-to-face payment scenarios via electronic payments managed via mobile electronic devices associated with merchants / performers and one or more customers. Enables.

[0009] In some embodiments, a method of making asynchronous mobile payments on a consumer device at least partially converts a first merchant device in the vicinity of the consumer device to broadcast information transmitted by the first merchant device. To identify based on, the broadcast information includes, the first identifier corresponding to the first merchant device, to identify; to send the first identifier to the server via the communication unit of the consumer device; and Includes receiving electronic communications from the server. In some embodiments, the electronic communication is the first merchant identification information of the first merchant associated with the first merchant device, the first merchant's name, logo, photo, address, telephone or electronic. First merchant identification information, including one or more of the emails; and first merchant transaction information identifying the proposed face-to-face transaction between the consumer device and the first merchant, a preset transaction. Includes first merchant transaction information, including amounts, available offers or available rewards. The method further, in some embodiments, displays the first merchant identification information on the display of the consumer device; receives a selection of the first merchant identification information from the user of the consumer device; and In response to receiving a selection of first merchant identification information: displaying the first merchant transaction information; selection of preset transaction amount, selection of available offers, selection of available rewards or freedom It involves receiving a first supplementary transaction information, which is a formal payment amount, from a user of the consumer device; and sending a first supplementary transaction information to a server. The method further comprises receiving confirmation from the server that the proposed transaction between the consumer device and the first merchant has been completed, in some embodiments.

[0010] In some embodiments, the consumer mobile device (eg, mobile device 104, FIGS. 1 and 13) is a display, one or more processors, and one or more for execution by one or more processors. Contains memory for storing the program of, and one or more programs include instructions for performing an operation or controlling performance thereof of any of the methods described herein. In some embodiments, the non-temporary computer-readable storage medium stores one or more programs, the one or more programs being a mobile device having one or more processors and a display (eg, a consumer mobile device 104). , 1 and 13) include instructions that cause a computer device to perform or control the performance of any of the methods described herein. In some embodiments, the consumer mobile device (eg, mobile device 104, FIGS. 1 and 13) operates or controls the performance of any of the methods described herein. Including means.

[0011] In some embodiments, the merchant device (eg, retailer 122 or merchant device 1304, FIGS. 1 and 13) is a display, one or more processors, one or one for execution by one or more processors. A memory for storing a plurality of programs is included, and one or more programs include an instruction for performing an operation of one of the methods described herein or controlling its performance. In some embodiments, the non-temporary computer-readable storage medium stores one or more programs, the one or more programs being a mobile device having one or more processors and a display (eg, a merchant device 122 or 1304). , 1 and 13) include instructions that cause a computer device to perform or control the performance of any of the methods described herein. In some embodiments, consumer mobile devices (eg, merchant devices 122, 1304, FIGS. 1 and 13) operate or control the performance of any of the methods described herein. Including means to do.

[0012] The various advantages of this application are evident in the light of the following description.

A brief description of the drawing
[0013] Not only the aforementioned features and advantages of the disclosed technique, but also its additional features and advantages will be more clearly understood as a result of the detailed description of the preferred embodiments in conjunction with the accompanying drawings.

[0014] In order to more clearly explain the technical solutions in the embodiments or prior arts of the present disclosure, the following concisely introduces the accompanying drawings necessary to illustrate the embodiments or prior arts. Obviously, the accompanying drawings in the following description show only some embodiments of the disclosed art, and one of ordinary skill in the art may further derive other drawings from these attached drawings without creative effort.

[0015] FIG. 3 is a block diagram of a payment processing system according to some embodiments. [0016] FIG. 6 is a block diagram of a mobile device according to some embodiments. [0017] FIG. 3 is a block diagram of a server system according to some embodiments. [0018] It is a schematic block diagram of an automated retailer according to some embodiments. [0019] It is a block diagram of a payment module according to some embodiments. [0020] FIG. 5 is a perspective view of the payment module (eg, series dongle adapter) of FIG. 5 according to some embodiments. [0021] FIG. 6 is a perspective view from the first end of the payment module of FIG. 6A according to some embodiments. [0022] FIG. 6A is a perspective view from the second end of the payment module of FIG. 6A according to some embodiments. [0023] FIG. 6 is a perspective view of the payment module of FIG. 6A in the automatic retailer of FIG. 4 according to some embodiments. [0024] It is a schematic flow chart of the process for initiating a transaction according to some embodiments. [0025] It is a schematic flow chart of the process for approving the transaction by some embodiments. [0026] FIG. 3 is a block diagram of an information packet broadcast by a payment module according to some embodiments. [0027] FIG. 3 is a block diagram of an authorization request according to some embodiments. [0028] It is a block diagram of an authorization grant token according to some embodiments. [0029] FIG. 3 is a block diagram of transaction information generated by a payment module according to some embodiments. [0030] Shown is an exemplary user interface for displaying promotional offers according to some embodiments. [0030] Shown is an exemplary user interface for displaying promotional offers according to some embodiments. [0030] Shown is an exemplary user interface for displaying promotional offers according to some embodiments. [0030] Shown is an exemplary user interface for displaying promotional offers according to some embodiments. [0030] Shown is an exemplary user interface for displaying promotional offers according to some embodiments. [0030] Shown is an exemplary user interface for displaying promotional offers according to some embodiments. [0030] Shown is an exemplary user interface for displaying promotional offers according to some embodiments. [0031] A flow chart diagram of a method of providing and processing a promotional offer for an automated retailer according to some embodiments is shown. [0031] A flow chart diagram of a method of providing and processing a promotional offer for an automated retailer according to some embodiments is shown. [0031] A flow chart diagram of a method of providing and processing a promotional offer for an automated retailer according to some embodiments is shown. [0032] FIG. 3 is a block diagram of a payment processing system according to some embodiments. [0033] FIG. 6 is a block diagram of a merchant device according to some embodiments. [0034] FIG. 3 is a block diagram of a consumer device according to some embodiments. [0034] FIG. 3 is a block diagram of a consumer device according to some embodiments. [0035] It is a block diagram of a server system according to some embodiments. [0035] It is a block diagram of a server system according to some embodiments. [0036] FIG. 3 is a block diagram of a payment processing system according to some embodiments. [0037] FIG. 3 is a block diagram of a payment processing system according to some embodiments. [0038] It is a flow chart of the process which processes payment by some embodiments asynchronously. [0039] It is a flow chart of the process which processes payment by some embodiments asynchronously. [0040] It is a flow chart of the process which processes payment by some embodiments asynchronously. [0041] FIG. 6 is a flow chart of a process for asynchronously processing a payment which is a continuation of the process of any one of the processes of FIGS. 19 to 21 according to some embodiments. [0042] An exemplary user interface for processing payments according to some embodiments is shown. [0042] An exemplary user interface for processing payments according to some embodiments is shown. [0042] An exemplary user interface for processing payments according to some embodiments is shown. [0042] An exemplary user interface for processing payments according to some embodiments is shown. [0042] An exemplary user interface for processing payments according to some embodiments is shown. [0042] An exemplary user interface for processing payments according to some embodiments is shown. [0042] An exemplary user interface for processing payments according to some embodiments is shown.

[0043] Similar reference numerals shall refer to corresponding parts across several figures of the accompanying drawings.

Description of the embodiment
[0044] An embodiment of which example is shown in the accompanying drawings will be referred to in detail below. The following detailed description provides many specific details to fully understand the subject matter presented herein. However, it will be apparent to those skilled in the art that the subject matter can be practiced without these specific details. In other examples, well-known methods, procedures, components, and circuits have not been described in detail so as not to unnecessarily obscure aspects of the embodiment.

[0045] In the following, the technical solutions of the embodiments of the present application will be described clearly and completely with reference to the accompanying drawings of the embodiments of the present application. Obviously, the embodiments described are merely a portion of the embodiments of the present application rather than all of them. All other embodiments obtained by one of ordinary skill in the art based on embodiments of this application without creative effort shall fall within the scope of protection of this application.

[0046] FIG. 1 shows a payment processing system 100. FIGS. 2-5 show exemplary devices within the payment processing system 100. 6A-6C and 7 show different views of the payment module 124 and the automatic retailer 122. FIG. 8 shows a schematic flow chart of the process 800 for initiating a transaction within the payment processing system 100. FIG. 9 shows a schematic flow chart of a process 900 for approving a transaction within the payment processing system 100. 10A-10D show data structures related to initiating and conducting transactions within the payment processing system 100. 11A-11G show an exemplary user interface for displaying promotional offers. 12A-12C show a flow chart diagram of method 1200 for providing and processing promotional offers for automated retailers. The user interface of FIGS. 11A-11G is used to illustrate the method of FIGS. 12A-12C.

Illustrative devices and systems
[0047] FIG. 1 is a block diagram of a payment processing system 100 according to some embodiments. According to some embodiments, the payment processing system 100 is a client-side processing 102-1, 102-2 (hereinafter "client-side module 102"), a server system, executed on the mobile devices 104-1 and 104-2. Includes a server-side process 106 (hereinafter "server-side module 106") performed on 108 (sometimes also referred to herein as a "server"), and a payment module 124 combined with an automated retailer 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 embodiments, the application associated with the client-side module 102 provides a user interface with the payment processing system 100 of the mobile device 104. The client-side module 102 communicates with the server-side module 106 via one or more networks 110 via a long-range communication protocol (eg, GSM, CDMA, Wi-Fi, etc.), and the client-side module 102 communicates with a short-range communication protocol (eg, proximity). Communicates with the payment module 124 via field communication (NFC: near-field communication), BLUETOOTH, BLUETOOTH low-energy (BLE), etc.). The server-side module 106 provides the server-side function of the payment processing system 100 of any number of client modules 102, each of which resides on the mobile device 104.

[0048] The payment processing system 100 utilizes the connectivity of the mobile device 104 to communicate with the payment module 124, which has neither a dedicated communication connection nor a long-distance communication transmitter / receiver. In this way, the mobile device 124 acts as a repeater between the payment module 124 and the server system 108. Further, utilizing the connectivity of the mobile device 104 helps to reduce the cost from the operator's point of view of the automatic retailer 122.

[0049] In some embodiments, the server-side module 106 provides input / output (I / O) interfaces to one or more processors 112, a user information database 114, an offer database 116, and one or more clients 118. include. The I / O interface to one or more clients 118 facilitates client-facing input / output processing of the server-side module 106. In some embodiments, one or more processors 112 approve a transaction request, determine a promotional offer for a particular mobile device 104, perform a closing account, and approve a completed transaction. The user information database 114 stores information of each user of the payment processing system 100 (for example, user ID, account certificate (user name and password), transaction history, account balance, linked credit card, bank account, etc.). The offer database 116 stores promotional offers provided by manufacturers, distributors, retailers, and the like.

[0050] Examples of mobile devices 104 are, but are not limited to, handheld computers, wearable computer devices, personal digital assistants (PDAs), tablet computers, laptop computers, desktop computers, cellular phones, smartphones, augmented general purpose packets. Wireless service (EGPRS: enhanced general packet radio service) mobile phones, media players, navigation devices, game consoles, televisions, remote controls, sales floor (POS: point-of-sale) terminals, in-vehicle computers, electronic book readers, or their data processing Includes any combination of two or more of devices or other data processing devices.

[0051] Examples of one or more networks 110 include a local area network (LAN) and a wide area network (WAN) such as the Internet. One or more networks 110 can optionally be Ethernet, Universal Serial Bus (USB), FIREWIRE, Long Term Evolution (LTE), Global System for Mobile Communication (GSM), Enhanced Data GSM Environment (EDGE), code division multiple access (CDMA), time division multiple access (TDMA), Bluetooth, Wi-Fi, voice over internet protocol Implemented using any known network protocol, including various wired or wireless protocols such as (VoIP: voice over Internet Protocol), Wi-MAX or any other suitable communication protocol.

[0052] The server system 108 is implemented on one or more stand-alone data processing devices or on a distributed network of computers. In some embodiments, the server system 108 is also of a third party service provider (eg, a third party cloud service provider) to provide the computational and / or infrastructure resources underlying the server system 108. Adopt various virtual devices and / or services. In some embodiments, the server system 108 includes, but is not limited to, a handheld computer, a tablet computer, a laptop computer, a desktop computer, or any combination of two or more of these data processing devices or other data processing devices.

The payment processing system 100 shown in FIG. 1 includes both a client-side portion (eg, client-side module 102) and a server-side portion (eg, server-side module 106). In some embodiments, the data processing is performed as a stand-alone application installed on the mobile device 104. In addition, the functional division between the client portion and the server portion of the payment processing system 100 can vary in various embodiments. For example, in some embodiments, the client-side module 102 is a thin-client that provides only user-facing I / O processing functionality and backs up all other data processing functionality. Delegate to an end server (eg, server system 108). Many aspects of the technique will be described in terms of the server system 108, but the actions taken by the mobile device 104 will be apparent to those skilled in the art without creative effort. Further, some embodiments of the present technology may be performed by the server system 108, by the mobile device 104, or by the server system 108 and the mobile device 104 in cooperation.

[0054] FIG. 2 is a block diagram of a mobile device 104 associated with a user according to some embodiments. The mobile device 104 typically comprises one or more processing units (CPUs) 202, two or more communication devices 204, memory 206, and one or more for interconnecting these components (sometimes referred to as chipsets). Includes communication bus 208. The two or more communication devices 204 are a first transmitter / receiver associated with a short-range communication protocol (eg, NFC, BLE, etc.) and a second transmitter / receiver associated with a long-range communication protocol (eg, GSM, CDMA, Wi-Fi, etc.). Including transmitter / receiver. The mobile device 104 also includes a user interface 210. The user interface 210 comprises one or more output devices 212 (including one or more speakers and / or one or more image displays) that allow the presentation of media content (eg, text, image, audio, video, etc.). include. The user interface 210 also includes user interface components such as a keyboard, mouse, voice command input unit or microphone, touch screen display, contact sensing input pad, gesture capture camera or other input button or control to facilitate user input 1. Or includes a plurality of input devices 214. Further, in some embodiments, the mobile device 104 uses a microphone and voice recognition or a camera and gesture recognition to complement or replace the keyboard. In some embodiments, the mobile device 104 optionally comprises one or more sensors 215 that provide contextual information about the current state of the mobile device 104 or the environmental state associated with the mobile device 104. One or more sensors 215, but 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, Includes one or more biological / biological sensors and the like. In some embodiments, the mobile device 104 optionally provides a position sensing device 217, such as a GPS (Global Positioning Satellite) receiver or other geographic location receiver to determine the position of the mobile device 104. include.

Memory 206 includes fast random access memory such as DRAM, SRAM, DDR RAM or other random access solid memory device and optionally one or more magnetic disk storage devices, one or more. Includes non-volatile memory such as an optical disk storage device, 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 away from one or more processing units 202. The non-volatile memory in memory 206 or optionally memory 206 includes a non-temporary computer-readable storage medium. In some embodiments, the memory 206 or the non-temporary computer-readable storage medium of the memory 206 stores the following programs, modules and data structures, or subsets or supersets thereof:
● Operating system 216, which includes procedures for handling various basic system services and for performing hardware-dependent tasks;
● Communication module 218 for transmitting and receiving signals to and from other devices (eg, server system 108 and payment module 124) via two or more communication devices 204;
● A presentation module 220 (eg, application 226, or client-side module 102) for enabling presentation of information on the mobile device 104 via one or more output devices 212 (eg, display, speaker, etc.) associated with the user interface 210. User interface for applications, widgets, websites and their web pages and / or games, audio and / or video content, text, etc. related to
● Input processing module 222 for detecting one or more user inputs or interactions from one or more input devices 214 and interpreting the detected inputs or interactions;
● Web browser module 224 for navigating, requesting (eg via HTTP) and displaying websites and their web pages;
● One or more applications 226 for execution by the mobile device 104 (eg games, application markets, payment platforms, and / or other web or non-web-based applications);
● Client-side module 102 that provides client-side data processing and functionality for the payment processing system 100, including, but not limited to, the following:
○ The broadcast acquisition module 230 for receiving the information packet broadcast by each payment module 124 via the first transmitter / receiver, and the information packet is at least a unique identifier corresponding to each payment module 124 (that is,). Broadcast acquisition module 230; which includes a device ID) and an authorization code for initiating a transaction with the automatic retailer 122 to which each payment module 124 is combined;
○ A transaction authorization request including an authorization code is sent to the server system 108 via the second transmitter / receiver; an authorization authorization token (authorization code) for initiating a transaction with the automatic retailer 122 to which each payment module 124 is combined. Is received from the server system 108 via the second transmitter / receiver; and the transaction authorization module 232 for storing the received authorization acceptance token (eg, in the user data 264);
○ An update to an application related to the client-side module 102 in response to obtaining (ie, receiving or searching) (ie, receiving or searching) a promotional offer from the server system 108 via a second transmitter / receiver (eg, sending a transaction authorization request). As part of or at another time); store promotional offers obtained from the server system in the offer database 266; multiple factors (eg, device ID, user ID and history, etc.) for one or more promotional offers. Arbitrarily determined based on one or more of the current location of the mobile device 104, the current time / date, etc.; one or more to the user of the mobile device via one or more output devices 212 (eg, display). Offer module 234 for presenting multiple promotional offers; and detecting that the user input selects each of one or more promotional offers presented to the user of the mobile device 104;
Trigger detection module 236 to detect a trigger to initiate a transaction with an automated retailer 122 to which each payment module 124 is coupled (eg, the trigger is a gesture or other user input by the user of the mobile device 104). , Admission of the mobile device 104 into the payment area based on RSSI observed from payment module 124, selection of each promotional offer, etc.);
○ A transaction start module for starting a transaction with an automatic retailer 122 combined with each payment module 124 by transmitting the stored authorization consent token to each payment module 124 via the first transmitter / receiver. 238;
○ The transaction completion notification receiving module 240 for receiving the transaction completion notification from the payment module 124 via the first transmitter / receiver, and the transaction completion notification is the transaction status information (for example, the transaction with the automatic retailer 122 is successful, Interruption or failure); one or more of the transaction details (eg authorization code, transaction amount, transaction related goods / products, transaction completion time / date, processing error information, etc.) Includes; and, more optionally, other miscellaneous information about the automated retailer 122 to which each payment module 124 and / or each payment module 124 is combined (blocked transaction information, status flags, inventory information, past). Transaction completion notification receiving module 240; including hard currency transaction information, other cashless transaction information, etc.)
○ Prompt the user of the mobile device 104 via one or more output devices 212 to obtain the product code of the product sold to validate each promotion offer; the product code of the product sold. (For example, the user of the mobile device 104 manually inputs the product code, the user of the mobile device 104 captures the image of the sold product from which the product code is extracted, the user of the mobile device 104 captures the product code. Use the scanner plug-in of the application associated with the client-side module 102 to obtain, etc.), and verify the product code or server for verification of the obtained product code via a second transmitter / receiver. Product code processing module 242 for either sending to system 108;
○ Information from the payment module 124 (eg, transaction status information, transaction details, other miscellaneous information about the automatic retailer 122 to which each payment module 124 and / or each payment module 124 is combined, etc.) is second. Information relay module 244 for transmission to the server system 108 via the transmitter / receiver of
○ The offer verification module for receiving the promotion verification information from the server system 108 via the second transmitter / receiver; and presenting the promotion verification information to the user of the mobile device via one or more output devices 212 (eg, display). 246;
○ Approval module 248 for transmitting approval information for transmitting approval information that the server system 108 has received and processed transaction status information and transaction detailed information to the payment module 124 via the first transmitter / receiver; and ○ FIG. 15A below. Asynchronous payment module 250, which provides the consumer-side payment function of the payment processing system 1300, which is described in more detail with reference to.
● Client data 260 that stores data related to the payment processing system 100, including, but not limited to, client data 260:
○ User information of mobile device 104 (unlimited but unique user identifier (ie user ID), login credit certificate (ie username or handle and password), transaction history, payment data (eg account balance, linked credit) Card or bank information, app credit or gift card balance, billing address, shipping address, etc., contact information (eg email address, phone number, etc.), user customer parameters (eg age, location, hobbies, etc.), user identification User profile 262, which stores trends and / or favorites / dislikes, etc.)
○ User data 264 that stores transaction history information, authorization acceptance tokens, etc.;
○ Offer database 266; which stores promotional offers provided by manufacturers, distributors, retailers, etc.; and ○ To store merchant identification information and payment amounts, which are described in more detail with reference to Figure 15B below. Asynchronous payment data 270.

Each of the elements identified above may be stored within one or more of the aforementioned memory devices and corresponds to a set of instructions for performing the above-mentioned functions. The modules or programs identified above (ie, sets of instructions) do not need to be implemented as separate software programs, procedures, modules or data structures, so the various subsets of these modules are in various embodiments. Can be combined or otherwise rearranged. In some embodiments, memory 206 optionally stores a subset of modules and data structures identified above. In addition, memory 206 optionally stores additional modules and data structures not described above.

[0057] FIG. 3 is a block diagram showing a server system 108 according to some embodiments. The server system 108 typically includes one or more processing units (CPUs) 112, one or more communication devices 304 (eg, including I / O interfaces to one or more clients 118), memory 306, and components thereof (eg,). Includes one or more communication buses 308 for interconnecting) (sometimes referred to as chipsets). Memory 306 includes high speed random access memory such as DRAM, SRAM, DDR RAM or other random access solid memory device, optionally one or more magnetic disk storage devices, one or more optical disk storage devices, 1 Or includes non-volatile memory such as multiple flash memory devices, or one or more other non-volatile solid storage devices. Memory 306 optionally includes one or more storage devices located away from one or more processing units 112. The non-volatile memory in memory 306 or alternative memory 306 includes non-temporary computer readable storage media. In some embodiments, the memory 306 or the non-temporary computer-readable storage medium of the memory 306 stores the following programs, modules, and data structures, or subsets or supersets thereof:
● Operating system 310, which includes procedures for handling various basic system services and for performing hardware-dependent tasks;
● Network communication module 312 for transmitting and receiving signals to and from the mobile device 104 via one or more communication devices 304;
● Server-side module 106 that provides server-side data processing and functions of the payment processing system 100, including, but not limited to, the following:
A transaction request containing a device ID and authorization code associated with each payment module 124 is received from each mobile device 104; and a transaction authorization module 314 for validating the transaction request;
○ Identifies the encryption / decryption key linked to the device ID of each payment module 124; decrypts the authorization code with the identified encryption / decryption key; and the authorization acceptance token with the identified encryption / decryption key Encryption / decryption module 316 for encrypting
○ One of multiple factors (for example, device ID included in the transaction request, user ID and history related to the user of each mobile device 104, current position of each mobile device 104, current time / date, etc.) Or an offer determination module 318 for determining one or more promotional offers based on multiple;
○ Send authorization consent tokens and one or more promotional offers to each mobile device 104 according to the determination that the transaction request has been validated; and send approval information to each mobile device 104 when the transaction is complete. Module 320;
○ Information including, but not limited to, product codes and corresponding selected promotional offers, transaction status information for each transaction, transaction details for each transaction, and / or other miscellaneous information from each mobile device 104. Receiving module 322 for receiving;
○ Validate the promotion offer based on the received product code, transaction status information, and / or transaction details; and send the promotion verification information to each mobile device 104 according to the judgment that the promotion offer has been verified. Offer Verification Module 324 to
○ Account module 326 for posting or charging account balances on linked credit cards or bank accounts according to transaction details;
○ Approval module 328 for transmitting approval information to each mobile device 104 for relay to each payment module 124; and ○ Payment processing system 1300 described in more detail with reference to FIG. 16A below. Asynchronous transaction module 350 that provides a consumer-side payment function; and ● Server data 340 that stores data of the payment processing system 100, including, but not limited to, server data 340:
A user information database 114 that stores information about each user of the payment processing system 100, including, but not limited to, a unique user identifier (ie, user ID), login credit certificate (ie, ie). Username or handle and password), transaction history, payment data (eg account balance, linked credit or bank information, app credit or gift card balance, billing address, shipping address, etc.), contact information (eg email address, etc.) User's custom parameters (eg age, location, hobbies, etc.), user's identified tendencies and / or favorites / dislikes, etc .;
○ Offer database 116 that stores promotional offers offered by manufacturers, distributors, retailers, etc.;
A payment module database 342 that stores information for each payment module 124 of the payment processing system 100, including a unique payment module identifier (ie, device ID), encryption / decryption key and / or similar. , But not limited to these; and ○ Asynchronous transaction data 360 for storing merchant details and transaction information described in more detail with reference to FIG. 16B below.

Each of the elements identified above may be stored within one or more of the aforementioned memory devices and corresponds to a set of instructions for performing the aforementioned functions. The identified modules or programs (ie, sets of instructions) need not be implemented as separate software programs, procedures or modules, and therefore various subsets of these modules may be combined in different embodiments. , Or otherwise it can be rearranged. In some embodiments, the memory 306 optionally stores a subset of the modules and data structures identified above. In addition, memory 306 optionally stores additional modules and data structures not described above.

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

[0060] FIG. 4 is a schematic block diagram showing an automated retailer 122 according to some embodiments. For example, the vending machine 122 is a vending machine or kiosk that provides goods or goods (eg, snacks, other food, school supplies, beverages, tickets, etc.) in response to user payments and choices of goods or goods. The automatic retailer 122 includes a controller 402; a power supply 404; a memory 406; a user interface 408; one or more optional sensors 414; a multi-drop bus (MDB) 416; and a dispenser 424.

[0061] In some embodiments, the controller 402 is a microcontroller, microprocessor, CPU, FPGA, ASIC, etc. that manages the functionality of the automated retailer 122. The power supply 404 is a connection to an external power source (for example, AC or DC) or a connection to an internal power source (for example, a battery). In some embodiments, the power source 404 further comprises one or more of a power converter and / or an inverter, a rectifier, a power conditioner, etc. for supplying power to various components of the automatic retailer 122. Memory 406 includes high speed random access memory such as DRAM, SRAM, DDR RAM or other random access solid memory device and optionally one or more magnetic disk storage devices, one or more optical disk storage devices, 1 Or includes non-volatile memory such as multiple flash memory devices, or one or more other non-volatile solid storage devices. In some embodiments, the memory 406 stores an operating system and instructions for performing functions and processing of the automated retailer 122 (eg, article delivery, inventory tracking, temperature control, power control, etc.). In some embodiments, the memory 406 also stores configuration data, DEX (data exchange) data corresponding to the inventory of the automated retailer 122, and transactions made by the automated retailer 122.

The user interface 408 comprises one or more output devices 410 (eg, one or more speakers and / or one or more image displays) that allow the presentation of information (eg, text, image, audio, video, etc.). Includes). The user interface 408 also comprises one or more input devices 412 including user interface components that facilitate user input and selection of articles such as microphones, keypads, touch screen displays, gesture capture cameras or other input buttons or control devices. include. One or more optional sensors 414, but 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. Includes motion sensors, one or more biometric / biological sensors, and the like.

[0063] In some embodiments, one or more cashless payment devices 418 (eg, credit card readers) for accepting cashless payments, one or more banknote verifiers 420 for accepting and verifying banknotes 420. , And various payment devices including any combination of one or more coin acceptors 422 for accepting money and providing fishing are combined with MDB416. In some embodiments, the dispenser 424 is an electromechanical system (eg, motor, actuator, etc.) for providing or selling goods or goods stored by the automated retailer 122. For example, the user inserts a bill into the bill verifier 420 and is guaranteed an amount equal to the bill. Continuing this example, one or more output devices 410 (eg, a display) indicate the payment amount, and the user selects an article via one or more input devices 412 (eg, using a keypad or a series of button presses). do). The controller 402 then sends a signal to the dispenser 424 to provide the selected product, which provides or sells the selected product.

[0064] FIG. 5 is a block diagram showing a payment module 124 according to some embodiments. In some embodiments, the payment module 124 is a series adapter dongle having male and female connectors coupled to the multi-drop bus (MDB) of each automated retailer 122 as shown in FIGS. 6B-6C and 7. .. For example, the payment module is serially connected into the MDB 416 of FIG. The payment module 124 typically includes one or more processing units (CPUs) 512, communication devices 504 (eg, transmitter / receiver associated with short-range communication protocols such as NFC, BLE), memory 506, and their components (sometimes chipsets). Includes one or more communication buses 508 for interconnecting). Memory 506 includes high speed random access memory such as DRAM, SRAM, DDR RAM or other random access solid memory device and optionally one or more magnetic disk storage devices, one or more optical disk storage devices, 1 Or includes non-volatile memory such as multiple flash memory devices, or one or more other non-volatile solid storage devices. Memory 506 optionally includes one or more storage devices located apart from one or more processing units 512. The non-volatile memory in memory 506 or alternative memory 506 includes non-temporary computer-readable storage media. In some embodiments, the memory 506 or the non-temporary computer-readable storage medium of the memory 506 stores the following programs, modules, and data structures, or subsets or supersets thereof:
● Operating system 510, which includes procedures for handling various basic system services and for performing hardware-dependent tasks;
● Network communication module 512 for transmitting and receiving signals to and from the mobile device 104 via the communication device 504;
● Transaction processing module 514, including but not limited to:
○ An information packet containing at least an information packet containing at least a unique identifier (that is, a device ID) corresponding to each payment module 124 and an authorization code for initiating a transaction with the automatic retailer 122 to which the payment module 124 is combined is included in the payment module 124. Broadcast module 516 for broadcasting to zero or more client devices 104 in the communication area (ie, BLE range) and storing the broadcast authorization code in authorization database 532;
○ Encrypt the authorization code with the encryption / decryption key corresponding to the payment module 124; and the encryption / decryption module 518 for decrypting the authorization consent token with the encryption / decryption key;
○ Detects signals related to hard currency transactions and / or signals related to other cashless transactions (eg credit card transactions) not related to the payment processing system 100; and said hard currency transactions and / or other cashless transactions. The transaction sniffing module 520; stores information related to (eg, in another information database 536).
○ Verification module 522 for verifying transactions by verifying the authorization code from the decrypted authorization acceptance token against the already broadcast authorization code stored in the authorization database 532;
○ Let the automatic retailer 122 sell or service the product according to the judgment that the transaction has been verified; and the transaction processing module 524 for storing the transaction details in the transaction database 534; and ○ the corresponding transaction. Approval module 526 for deleting transaction details from the transaction database 534 according to the determination that was approved by the server system 108; and ● Data 530 that stores data including, but not limited to:
○ Authorization database 532 that stores authorization codes that have already been broadcast;
○ Transaction database 534 storing transaction details of transactions processed by payment module 124; and ○ Status flags, inventory information, past hard currency for automatic retailer 122 combined with payment module 124 and / or payment module 124. Another information database 536 that stores various miscellaneous information such as transaction information, other cashless transaction information, and the like.

Each of the elements identified above may be stored within one or more of the aforementioned memory devices and corresponds to a set of instructions for performing the above-mentioned functions. The identified modules or programs (ie, sets of instructions) need not be implemented as separate software programs, procedures or modules, and therefore various subsets of these modules may be combined in different embodiments. , Or otherwise it can be rearranged. In some embodiments, memory 506 optionally stores a subset of modules and data structures identified above. In addition, memory 506 optionally stores additional modules and data structures not described above.

[0066] FIGS. 6A-6C show different views of the payment module 124 of FIG. 5 according to some embodiments. The payment module 124 is a relatively low cost hardware component preconfigured to work with the industry standard multi-drop bus (MDB). On machines without MDB technology, the payment module 124 may be configured or designed to work with other serial protocols or to activate a switch (eg, a cherry switch mechanism). See, for example, US Patent Application No. 14 / 458,192: "Method and System for Retrofitting an Offline-Payment Operated Machine to Accept Electronic Payments," which is incorporated by reference in its entirety. In essence, the payment module 124 simulates establishing a payment on an automated retailer 122 in much the same way as any other alternative form of payment (eg, cash).

[0067] The payment module 124 is preferably designed to be used, for example, as an adapter dongle for serial insertion in the MDB of a vending machine 122 (eg, a vending machine). The wires used in MDB technology use male-female connection ends or adapters to allow attachment of peripheral devices. In the case of vending machines, MDBs with connection ends or adapters will be present to allow the attachment of payment receiving mechanisms (eg coin mechanisms). The MDB male and female adapters 612, 614 of the MDB can be separated (as shown in FIGS. 6B-6C). The payment module 124 of FIGS. 6A-6C has a male adapter 602 and a female adapter 604. The payment module 124 may be plugged (inserted) in series (“in-line”) with the MDB. For example, the MDB female adapter 614 may be connected to the male adapter 602 of the payment module 124 and the MDB male adapter 612 may be connected to the female adapter 604 of the payment module 124. The resulting series configuration is shown in FIG. The payment module 124 is designed to allow pass-through communication, so if the mobile device-to-machine payment processing system is not enabled (for example, for a specific purchase or simply turned off). If so), it should be noted that the MDB functions as if the payment module 124 is not present there, and the automatic retailer 122 can function normally. In FIG. 7, the automatic retailer 122 includes a display 722 showing user selection, current credits, and the like. In FIG. 7, the automatic retailer 122 also includes a touch screen display 724 and a button 726 for selecting products.

User interface and related processing
[0068] FIG. 8 is a schematic flow chart of a process 800 for authenticating a user transaction in the payment processing system 100 according to some embodiments. In some embodiments, the payment processing system 100 comprises one or more payment modules 124 (eg, relating to a vending machine 122, such as a vending machine, each for providing goods and / or services), 1. Alternatively, it includes a plurality of mobile devices 104 and a server 108. Each of the one or more mobile devices 104 is an instance of the client-side module 102 as foreground or background processing to access and communicate with other devices in the payment processing system 100 (eg, server 108 and payment module 124). Run (eg as an application). The server 108 manages the payment processing system 100 and, in some cases, is associated with an entity that supplies, operates, and / or manufactures one or more payment modules 124. For simplicity, processing 800 will be described for each payment module 124 and each mobile device 104 within the payment processing system 100.

[0069] The payment module 124 broadcasts an information packet via short-range communication capability (eg, BLE) (802). The information packet contains at least the authorization code and unique identifier (ie, device ID) associated with the payment module 124. In some embodiments, the information packet further comprises the current firmware version of the payment module 124, as well as one or more status flags corresponding to one or more statuses of the payment module 124 and / or the automatic retailer 122. Information packets are further discussed below with reference to FIG. 10A.

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

[0071] In some embodiments, the payment module 124 stores the broadcast authorization code until the received authorization acceptance token matches one of the stored authorization codes and then removes the matching authorization code. (For example, in the authorization database 542 of FIG. 5). In some embodiments, the broadcast authorization code is a one-time use code, which allows the broadcast authorization code to be used by only one mobile device 104 before being invalidated and / or deleted to prevent replay attacks. Can be done. In some embodiments, the payment module 124 stores a previously broadcast authorization code for a predetermined time (eg, Y minutes), after which the authorization code expires and is deleted. In some embodiments, the authorization code is encrypted with a shared private key known by the server system 108 but unique to the payment module 124.

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

[0073] In some embodiments, the broadcast information packet requires the mobile device 104 (or the application associated with the client-side module 102) to observe from the payment module 124 before entering the authorization area of the payment module 124. Includes a baseline approved area threshold (ie, approved area criteria) that indicates the baseline received signal strength indication (RSSI). In some embodiments, the mobile device 104 (or application associated with the client-side module 102) is based on receive strength, its short-range communication capability (eg, BLE radio / transmitter / receiver) and / or other similar factors. Offset the line authorization area threshold. In some embodiments, the authorization request is an authorization code contained in a broadcast information packet, an identifier or user account (ie, a user ID) associated with the user of the mobile device 104 in which the user of the mobile device 104 logs in to the application. And at least the identifier (ie, device ID) associated with the payment module 124. In some embodiments, the authorization code included in the authorization request is a hash value in clear text. The authorization request is further discussed below with reference to FIG. 10B.

After receiving the authorization request, the server system 108 processes the authorization request (806). In some embodiments, the server system 108 identifies the shared private key based on the device ID and decrypts the authorization code contained in the authorization request with the identified shared private key. The server system 108 allows the user associated with the user ID in the authorization request to fund its own account in the payment processing system in order to make a transaction in the automated retailer 122 to which the payment module 124 corresponding to the device ID is coupled. Determine if you have it.

[0075] The server system 108 transmits an authorization consent token to the mobile device 104 via a long-distance communication capability (eg, GSM, CDMA, Wi-Fi, etc.) (808). In some embodiments, the server system 108 accepts authorization if the authorization code in the authorization request cannot be decrypted by the shared private key corresponding to payment module 124 (eg, if the authorization code is corrupted or hacked). Do not send tokens. In some embodiments, the server system 108 will issue an authorization consent token if the user associated with the user ID in the authorization request does not have sufficient funds in his account or exceeds a predetermined daily usage limit. Do not send. In some embodiments, in addition to the authorization acceptance token (or lack thereof if authorization is denied), the server system 108 sends a message directly to the mobile device 104 that is not encrypted by the shared private key corresponding to the payment module 124. Send. After receiving the message, the mobile device 104 displays to the user appropriate messages such as sufficient funds, authorized transactions, insufficient balances or rejected authorizations. In some embodiments, the server system 108 sends an authorization consent token in an amount equal to zero; in this case, the payment module 124 limits this to any number of reasons, including but not limited to insufficient balances or credits. It is interpreted as a possible refusal or failure of authorization. In some embodiments, the mobile device 104 stores an authorization consent token (eg, in user data 264) until a trigger condition is detected.

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

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

[0078] In some embodiments, the trigger condition is satisfied when the mobile device 104 observes RSSI from each automated retailer that is greater than or equal to the payment area criteria. For example, when the mobile device 104 enters the payment area, a transaction between each automatic retailer and the user of the mobile device 104 is automatically started. In some embodiments, after the RSSI observed from each retail machine is above the payment zone criteria, the mobile device 104 will provide a transaction confirmation that, when detected, will work to satisfy the trigger condition. Prompt the user. For example, when the mobile device 104 enters the payment area, the mobile device 104 prompts for an audible prompt, displayed notification or vibration to confirm its intention to initiate a transaction with each retail machine. Provide to users. Continuing this example, the user can flick the mobile device 104 towards the automatic retailer, swing the mobile device, provide audible instructions, or on the displayed user interface. You can confirm your intention to start trading with each retail machine by performing contact input / gesture at.

[0079] In some embodiments, the unused authorization acceptance (eg, if the trigger condition does not exist or has expired) sends a cancellation message to the server system 108 corresponding to the unused authorization acceptance. Is canceled by the mobile device 104. In some embodiments, the server system 108 rejects or denies the authorization acceptance sent to the mobile device 104 until it receives the transaction information transmitted to the mobile device 104 or until it receives the cancellation of the pending authorization acceptance. Restrict.

[0080] In response to detecting the trigger condition, the mobile device 104 sends an authorization consent token to the payment module 124 via short-range communication capability (eg, BLE) (812). The auto-retailer 122 then displays the credit to the user (eg, via one of the displays 722 or 724 shown in FIG. 7), and the user inputs the auto-retailer 122 to purchase the product and / or service. It interacts with the mechanism (eg, via the button 726 or touch screen display 724 shown in FIG. 7).

[0081] The specific order in which the process of FIG. 8 is described is merely exemplary, and is intended to indicate that the order described is the only order in which the operation may be performed. It should be understood that there is no such thing. One of ordinary skill in the art will recognize various ways of rearranging the operations described herein. In addition, details of other processes described herein with respect to other methods and / or processes described herein (eg, process 900 and method 1200) are also described above with respect to FIG. It should be noted that it is applicable in a manner similar to 800.

[0082] FIG. 9 is a schematic flow chart of processing 900 for processing approval information in the payment processing system 100 according to some embodiments. In some embodiments, the payment processing system 100 comprises one or more payment modules 124 (eg, relating to a vending machine 122, such as a vending machine, each for providing goods and / or services), 1. Alternatively, it includes a plurality of mobile devices 104 and a server 108. Each of the one or more mobile devices 104 of the client-side module 102 as foreground or background processing to access and communicate with other devices (eg, server 108 and payment module 124) within the payment processing system 100. Run the instance (eg as an application). The server 108 manages the payment processing system 100 and, in some cases, is associated with an entity that supplies, operates, and / or manufactures one or more payment modules 124. For simplicity, the process 900 will be described for each payment module 124 combined with each automated retailer 122 and each payment module 104 within the payment processing system 100. In process 900, the payment module 124 receives the first approval information of the first transaction via the mobile device 104 that initiated the first transaction.

[0083] The payment module 124 obtains a first notification from the automatic retailer 122 indicating the completion of the first transaction (902). For example, after the process 800 of FIG. 8, the user of the mobile device 104 automatically retails by interacting with one or more input mechanisms of the automatic retailer 122 (eg, button 726 or touch screen display 724 shown in FIG. 7). The product to be purchased is selected from the machine 122, and the automatic retail machine 122 provides the selected product. Continuing this example, after the product is offered, the transaction is completed and the payment module 124 gets a notification of the completed transaction from the automated retailer. In some embodiments, the notification includes the amount of the transaction and (optionally) machine status information related to the automatic retailer 122, such as inventory information about one or more products of the automatic retailer 122.

[0084] After obtaining the first notification, the payment module 124 generates the first transaction information based on the first notification (904), and the payment module 124 stores the first transaction information. In some embodiments, the transaction information is the transaction ID of the first transaction, the device ID corresponding to the payment module 124, the user ID corresponding to the mobile device 104, and the transaction status indicating that the first transaction has been completed. Includes information and the transaction amount indicated by the first notice. In some embodiments, the payment module 124 holds the authorization code contained in the original broadcast packet and / or authorization acceptance token, and includes the authorization code in the first transaction information. In some embodiments, the authorization code is encrypted with a private key (shared with the server system 108 rather than the mobile device 104) corresponding to the payment module 124. In some embodiments, the first transaction information further includes other information, such as a first notice corresponding to a previously blocked transaction or machine status information contained in the transaction information. See Figure 10D and attached text for further discussion of transaction information 1050.

[0085] The payment module 124 transmits the first transaction information to the mobile device 104 via a short range communication capability (eg, BLE) (906).

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

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

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

After receiving the first approval information, the mobile device 104 transmits the first approval information to the payment module 124 via a short range communication capability (eg, BLE) (914).

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

The specific order in which the process of FIG. 9 is described is merely exemplary, and the order described is intended to indicate that the operation is the only order in which it may be performed. It should be understood that there is no such thing. One of ordinary skill in the art will recognize various ways of rearranging the operations described herein. In addition, details of other processes described herein with respect to other methods and / or processes described herein (eg, process 800 and method 1200) are also described above with respect to FIG. It should be noted that it is applicable in a manner similar to 900.

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

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

[0094] In some embodiments, the authorization code 1004 is a hash value in clear text. In some embodiments, the payment module 124 randomly or pseudo-randomly generates numbers, or determines the number of consecutive numbers (see step 802 of process 800 in FIG. 8) and uses the hash value as authorization code 1004. A predetermined hash function (eg SHA-256) is performed on this number to generate it. In some embodiments, the authorization code 1004 is a unique code encrypted by the private encryption key corresponding to the payment module 124. A secret encryption key that allows the server system 108, rather than the mobile device 104, to decrypt the authorization code 1004 and encrypt the authorization acceptance token is shared with the server system 108. In some embodiments, the encryption between the server system 108 and the payment module 124 is achieved by two pairs of public / private keys.

[0095] In some embodiments, the firmware version information 1006 identifies the current firmware version 1012 of the payment module 124. In some embodiments, the firmware version information 1006 is also one or more packets received by the payment module 124 to update the firmware, or is required by the payment module 124 to update the firmware or one or more. Includes update status information 1014 indicating multiple packets.

[0096] In some embodiments, one or more status flags 1008 indicate the state of the automatic retailer 122 to which the payment module 124 and / or the payment module 124 is coupled. In some embodiments, one or more status flags 1008 indicate the status of the payment module 124, such an upload information indicator 1016 is information uploaded to the server system 108 (eg, one or more blocked transactions). Transaction information) is shown to be possessed by the payment module 124. In some embodiments, the upload information indicator 1016 triggers the mobile device 104 to connect immediately to the payment module 124 (eg, the payment module 124 has blocked transaction information uploaded to the server system 108). if). In some embodiments, one or more error indicators 1018 (eg, indicating that the banknote and / or coin acceptor of the automated retailer 122 is experiencing jams, error codes or malfunctions), monetary level indicators. 1020 (eg, indicating that the level of banknote and / or coin receiver accumulation in the automatic retailer 122 is full or empty), and / or inventory level indicator 1022 (eg, one or more products of the automatic retailer 122). One or more status flags 1008 including) indicate the status of the automatic retailer 122. In some embodiments, one or more status flags 1008 are error codes issued by the automatic retailer 122 on the MDB.

[0097] In some embodiments, the area criteria information 1010 is required to be observed until the authorized area criteria 1024 (eg, the mobile device 104 (or application) is within the authorized area of the payment module 124). Baseline authorization area threshold indicating baseline RSSI) and / or payment area criterion 1026 (eg, mobile device 104 (or application) is required to observe until it is within the payment area of payment module 124). Baseline payable area threshold indicating line RSSI) is specified. In some embodiments, the baseline authorization area threshold and the baseline payment area threshold are the default values determined by the server system 108 or stored as variables by the application, in which case the authorization area criteria 1024 and The payment area determination criterion 1026 is an offset to compensate for the strength and / or reception of the short-range communication capability of the payment module 124 (eg, BLE radio / transmitter / receiver). Alternatively, the area criteria information 1010 includes a variance between the baseline authorization area threshold and the baseline payment area threshold. Therefore, the mobile device 104 (or application) determines the baseline authorization zone threshold and the baseline payment zone threshold based on the variance and default value of either the baseline authorization zone threshold or the baseline payment zone threshold. For example, the variance shows -10db and the default baseline payment area threshold is -90db; therefore, the baseline authorization area threshold is -80db. Continuing this example, after determining the baseline authorization area threshold and the baseline payment area threshold, the mobile device 104 (or application) further sets the authorization area threshold and / or the payment area threshold to its short-range communication capability (ie, BLE). It can be adjusted based on the strength and / or reception of the radio / transmitter / receiver.

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

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

[0100] In some embodiments, the user ID 1034 is a unique identifier associated with the user of the mobile device 104 that sends the authorization request 1030 to the server system 108. In some embodiments, the user ID 1034 is associated with a user account logged in to the user application on the mobile device 104.

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

[0102] FIG. 10C is a block diagram of the authorization consent token 1040 transmitted to the mobile device 104 by the server system 108 according to some embodiments (eg, in step 808 of process 800 of FIG. 8). In some embodiments, the authorization code 1036 contained in the authorization request 1030 from the mobile device 104 is valid and the user associated with the mobile device 104 has sufficient funds in its account of the payment processing system. According to the determination to have, the server system 108 generates the authorization acceptance token 1040. In some embodiments, the authorization consent token 1040 comprises at least device ID 1002; user ID 1034; authorization amount 1046; (optionally) expiration date 1048; and (optionally) authorization code 1004. In some embodiments, the authorization acceptance token 1040 is encrypted with the shared private key corresponding to the payment module 124.

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

[0104] In some embodiments, the user ID 1034 is a unique identifier associated with the user of the mobile device 104 that has sent the authorization request 1030 to the server system 108.

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

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

[0107] In some embodiments, the authorization acceptance token 1040 further comprises an authorization code 1004 included in the authorization request 1030. In some embodiments, if the authorization code 1004 is a hash value, the server system 108 encrypts the authorization acceptance token 1040, including the hash value, with the shared secret encryption key associated with the payment module 124. The mobile device 104 then sends the authorization acceptance token 1040 to the payment module 124 after detecting the trigger condition, and the payment module 124 is a secret known only to the server system 108 and the payment module 124 (authenticating the message and authorization acceptance). The key is used to decrypt the authorization consent token 1040, and then with the hash value contained in the decrypted authorization acceptance token 1040 to determine the validity of the hash value (known only by the payment module 124). Consistent with a valid (ie, expired, unused) hash value that has already been broadcast (eg, a stored authorization code).

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

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

[0110] In some embodiments, device ID 1054 is a unique identifier corresponding to the payment module 124 in which each transaction was made.

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

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

[0113] In some embodiments, the transaction status information 1060 includes an indicator of whether each transaction was completed, not completed, or interrupted. For example, each transaction is unfinished if the jam occurs in the automatic retailer 122 and the user does not receive the product associated with each transaction. For example, if the user leaves the automatic retailer 122 after the money for each transaction has been deposited, each transaction is interrupted. In another example, the user was unable to select a product on the automatic retailer 122, so if each transaction expires after a predetermined period of time, each transaction is suspended. In another example, if the user activates the banknote or coin return mechanism of the automatic retailer 122, each transaction is interrupted.

[0114] In some embodiments, transaction detail information 1062 indicates the amount of each transaction or the amount of each transaction of a plurality of transactions (eg, in a multiple sales scenario). In some embodiments, the transaction details 1062 also relates to the respective transaction, such as the goods provided by the automatic retailer 122 and the type of transaction (eg, coins, banknotes, credit cards, manual mode, hands-free mode, etc.). Indicates other information to be done.

[0115] In some embodiments, the miscellaneous information 1064 includes other information relating to the payment module 124 and / or the automatic retailer 122 to which the payment module 124 is coupled. For example, miscellaneous information 1064 includes a verification request to the server system 108 to implement new firmware. In another example, miscellaneous information 1064 includes transaction information from one or more previously blocked transactions. In another example, miscellaneous information 1064 provides transaction information for one or more past hard currency transactions and / or other cashless transactions (eg, paid by credit card or bank card at automated retailer 122). include. In another example, miscellaneous information 1064 includes inventory information about one or more products of the automatic retailer 122.

[0116] Next, attention is paid to embodiments and related processes of a user interface (“UI”) that may be implemented on a mobile device 104 having zero or more speakers 1102, zero or more microphones 1104, and display 1106. Will be. For example, the display 1106 is a touch screen (as used herein) capable of accepting one or more contacts and displaying information (eg, media content, websites and their web pages, and / or user interfaces of application 326). Sometimes also called a "touch screen display"). 11A-11G show an exemplary user interface for facilitating the display of promotional offers according to some embodiments.

[0117] Some of the examples that follow are given with reference to the input on the touch screen (a combination of a touch sensitive surface and a display), but in some embodiments the mobile device is separated from the display. Detects input on the touch-sensitive surface. In some embodiments, the touch-sensitive surface has a spindle corresponding to the spindle on the display. According to these embodiments, the mobile device detects contact with a touch-sensitive surface at a position corresponding to each position on the display. In this way, the user input detected by the mobile device on the touch-sensitive surface is used by the mobile device to manipulate the user interface on the mobile device's display when the touch-sensitive surface is isolated from the display. To. It should be understood that similar methods are optionally used for the other user interfaces described herein.

[0118] In addition, the following examples are given primarily with reference to contacts (eg finger input such as finger contact, finger tap gesture, finger swipe gesture, etc.), but in some embodiments one or more of the above contacts. It should be understood that the plural is replaced by input from another input device (eg mouse-based, stylus-based, or physical button-based input). For example, a swipe gesture is optionally replaced by a mouse click (eg, instead of a touch) followed by a cursor movement (eg, instead of a touch movement) along the swipe path. As another example, a tap gesture can be done by mouse click while the cursor is over the position of the tap gesture (for example, instead of detecting a contact followed by stopping detecting the contact) or by a physical button. It is replaced arbitrarily by pressing. Similarly, it should be understood that when multiple user inputs are detected simultaneously, multiple computer mice are optionally used simultaneously or the mouse and finger contact are optionally used simultaneously.

[0119] FIGS. 11A-11G show a user interface 1108 displayed on each mobile device 104 (eg, a mobile phone associated with a user) for an application associated with payment processing system 100, which is illustrated by those skilled in the art. You will understand that the user interfaces shown in 11A-11G can be implemented on other similar computer devices. The user interfaces of FIGS. 11A-11G are used to indicate the processes described herein, including the methods described with respect to FIGS. 12A-12C. Those skilled in the art will appreciate that the following user interface is merely an example. In addition, those skilled in the art will appreciate that additional affordances and / or user interface elements or less affordances and / or user interface elements may actually be used.

[0120] FIG. 11A shows a mobile device 104 displaying a transaction start screen 1110 for a snack machine on the 8th floor. In FIG. 11A, the transaction start screen 1110 includes a series of indicators 1116, which states that "the 8th floor snack machine is one of the three automated retailers authorized to start trading by the user." Show that. For example, the user of the mobile device 104 may perform a left-to-right swipe gesture (or an alternative right-to-left swipe gesture) on the user interface 1108 to perform a second of the three auto-retailers. And by making a right-to-left swipe gesture (or alternative left-to-right swipe gesture) on the user interface 1108, the first of the three auto-retailers You can access the machine. The user of the mobile device 104 can access the application settings and / or the home screen by selecting affordance 1112 (eg by tap gesture) and trading by selecting affordance 1114 (eg by tap gesture). The start screen 1110 can be refreshed.

[0121] FIG. 11A also shows that the user of mobile device 104 has a prepaid balance of $ 100.00. The user of the mobile device 104 can start a transaction with the snack machine on the 8th floor by performing an upward swipe gesture originating from the area 1120 of the transaction start screen 1110. Users of the mobile device 104 can access special promotional offers by selecting the "special offer" area 1122 (eg, by tap gesture), and by selecting affordance 1124 (eg, by tap gesture). You can "prefer" or prefer the 8th floor snack machine. FIG. 11A also shows a mobile device 104 that detects contact 1140 at a location corresponding to the "special offer" region 1122.

[0122] FIG. 11B shows a mobile device 104 displaying a special offer screen 1130 for a snack machine on the 8th floor. In FIG. 11B, the special offer screen 1130 is the first region corresponding to the "offer A" 1152 on the product A with the image A of the product A; the "offer B" on the product A with the image A of the product A. A second region corresponding to "1154;" and a third region corresponding to "Offer C" 1156 on the product B accompanied by the image B of the product B. The special offer screen 1130 also includes a refresh affordance 1151 that causes the special offer screen 1130 to be refreshed when activated (eg, via a tap gesture). In FIG. 11B, none of offers A, B, C is currently selected. The user of the mobile device 104 can select "offer A" 1152 by performing a gesture (eg, tap gesture) on the selection affordance 1153. Similarly, the user of the mobile device 104 makes an "offer B" 1154 by making a gesture (eg, tap gesture) on the selected affordance 1155, or an "offer" by making a gesture (eg, tap gesture) on the selected affordance 1157. C "1156 can be selected. The user of the mobile device 104 can also make any of offers A, B, or C by making a right-to-left swipe gesture (or, in other embodiments, a left-to-right swipe gesture) within the corresponding area. You can abandon or delete things. FIG. 11B also detects a right-to-left swipe gesture in the second region corresponding to "offer B" 1154 by contact 1160 moving from the first position 1162-a to the second position 1162-b. The mobile device 104 is shown.

[0123] In some embodiments, the special offer screen 1130 further comprises a fourth area corresponding to a "No Selected Offer". For example, a user of the mobile device 104 may see a promotional offer on the special offer screen 1130, but may not want any of the promotional offers to apply to future transactions with the 8th floor snack machine. Thus, the user of the mobile device 104 may select the "non-selective offer" area (eg, by tap gesture), and accordingly, the mobile device 104 redisplays the transaction start screen 1110 as shown in FIG. 11A.

[0124] FIG. 11C presents a mobile device 104 displaying a delete affordance 1164 in a second region corresponding to "offer B" 1154 in response to detecting a right-to-left swipe gesture in FIG. 11B. show. Delete affordance 1164 causes "offer B" 1154 to be deleted from the special offer screen 1130 when activated (eg, via a tap gesture). FIG. 11C also shows a mobile device 104 that detects contact 1166 at a position corresponding to deletion affordance 1164.

[0125] FIG. 11D shows a mobile device 104 that discontinues displaying "offer B" 1154 in the special offer screen 1130 in response to detecting the selection of the deleted affordance 1164 in FIG. 11C. FIG. 11D also shows a mobile device 104 that detects a contact 1168 at a position corresponding to the selection affordance 1153 of "offer A" 1152. Alternatively, in some embodiments, the user of the mobile device may not wish to apply the offer to future transactions with the 8th floor snack machine. Therefore, the user may select affordances 1112 (eg, by tap gesture) to redisplay the transaction start screen 1110 as shown in FIG. 11A, or may make a predetermined gesture on the special offer screen 1130. good.

[0126] FIG. 11E shows that the selective affordance 1153 was selected in response to detecting the selection of the selective affordance 1153 of FIG. 11D. In some embodiments, the transaction with the 8th floor snack machine is automatically initiated in response to detecting the selection of the selection affordance 1153 of FIG. 11D. In another embodiment, after detecting the selection of the selection affordance 1153 in FIG. 11D, the mobile device 104 redisplays the transaction start screen 1110 (as shown in FIG. 11A) and the transaction with the 8th floor snack machine is a transaction. It is started in response to detecting an upward swipe gesture emanating from the area 1120 of the start screen 1110.

[0127] FIG. 11F is a product code that prompts the user of the mobile device 104 to obtain the product code of product A (eg, UPC code, SKU, etc.) to validate the "offer A" 1152 selected in FIG. 11D. The mobile device 104 displaying the screen 1170 is shown. The product code screen 1170 also includes a product code scanner window 1172 for capturing an image of product A and / or scanning the product code of product A. In FIG. 11F, the UPC code 1174 (eg, product code) of the product A (eg, candy bar) within the view of the camera of the mobile device 104 is shown in the product code scanner window 1172. For example, the user of the mobile device 104 taps in the product code scanner window 1172, issues an audible command, presses a predetermined physical button on the mobile device 104, and so on, thereby displaying an image of the product A (in the current field of view). Can capture (including UPC code 1174) or scan UPC code 1174. FIG. 11F also shows that the user of the mobile device 104 has a prepaid balance of $ 99.00, which is $ 1.00 less than the amount shown in FIGS. 11A-11E due to the purchase of product A.

[0128] FIG. 11G shows a mobile device 104 displaying the offer verification screen 1180. In some embodiments, the mobile device 104 displays the offer verification screen 1180 after the user completes the transaction with the 8th floor snack machine and the server validates the product code information (eg, UPC scanned in FIG. 11F). do. In FIG. 11G, the offer verification screen 1180 indicates that "offer A" 1152 has been verified and that $ 0.25 has been credited to the user's balance. FIG. 11G also shows that the user of the mobile device 104 is $ 0. 25 larger) to indicate that you have a prepaid balance.

[0129] FIGS. 12A-12C show a flow chart diagram of method 1200 for providing and processing promotional offers for automated retailers according to some embodiments. In some embodiments, method 1200 is performed by a mobile device having a display, one or more processors, and memory. For example, in some embodiments, the method 1200 is performed by a mobile device 104 (FIGS. 1-2) or a component thereof (eg, client-side module 102, FIGS. 1-2). In some embodiments, the method 1200 is controlled by instructions stored in a non-temporary computer-readable storage medium, the instructions being executed by one or more processors of the mobile device. Some operations in method 1200 are optionally combined and / or the order of some operations is optionally changed.

[0130] In some embodiments, the payment processing system 100 (FIG. 1) includes a mobile device 104 performing method 1200, a server system 108, and a payment module 124 combined with an automated retailer 122. An instance of the client-side module 102 (eg, as an application) runs on the mobile device 104 as foreground or background processing to access and communicate with other devices in the payment processing system 100 (eg, server 108 and payment module 124). Will be done. The server 108 manages the payment processing system 100 and, in some cases, is associated with the entity that provides, operates, and / or manufactures the payment module 124.

[0131] In some embodiments, prior to displaying one or more promotional offers, the mobile device is: an information packet broadcast by a payment module combined with an automated retailer to support the payment module. Obtains an information packet containing at least the authorization code and unique identifier to be used; sends a transaction authorization (including the authorization code and unique identifier corresponding to the payment module) request to the server; and in response to the transaction authorization request. Receives authorization information from the server, including authorization acceptance tokens for initiating transactions with automated retailers combined with payment modules and one or more promotional offers from the server (1202). As discussed in process 800, the mobile device 104 or a component thereof (eg, broadcast acquisition module 230, FIG. 2) is information broadcast by the payment module 124 that includes at least an authorization code and an identifier associated with the payment module 124. Receive a packet. The mobile device 104 or its components (eg, transaction authorization module 232, FIG. 2) then sends an authorization code to the server 108 to pre-authorize the transaction with the automated retailer 122 to which the payment module 124 is coupled. According to the determination that the server 108 has pre-authorized a potential transaction, the mobile device 104 or a component thereof (eg, transaction authorization module 232, FIG. 2) receives an authorization acceptance token for conducting a transaction with the automatic retailer 122. In some embodiments, the mobile device 104 has an authorization consent token (eg, user data 265) until a trigger condition for initiating a transaction with the automated retailer 122 is detected (eg, by the trigger detection module 236 in FIG. 2). Of the above, Fig. 2) is stored. In some embodiments, the trigger condition is satisfied when the mobile device 104 detects a user input on the user interface displayed by the mobile device 104. For example, referring to FIG. 11A, the transaction is initiated between the user of the mobile device 104 and the 8th floor snack machine when the mobile device 104 detects an upward swipe gesture emanating from region 1120 of the user interface 1108. In another example, with reference to FIG. 11D, the transaction is initiated between the user of the mobile device 104 and the 8th floor snack machine when the mobile device 104 detects the selection of offer A 1152 by contact 1166.

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

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

[0134] In some embodiments, one of one or more promotional offers is a "reward" for a product or service that is not associated with the automated retailer 122 (ie, an out-of-band offer). For example, if a user purchases a particular product, the user may have free downloads (eg songs, videos, etc.), in-app credits (eg $ 2.00 for purchases in the digital media market, or in-app purchases of games). You will receive the link via email for $ 2.00 credits) and so on. This may or may not require product verification. For example, now buy any product from this automated retailer and get a link from the retailer to a $ 1.00 discount coupon via email or text for one case of soda. In some embodiments, the offer may be an "additional sale", which is an out-of-band offer. For example, buy XYZ Coke now and get one case of XYZ Coke from the store for only $ 1.50 with a coupon mailed to your email address. In another example, buy an ABC chip now and get a special discount offer to buy a $ 5.00 cool T-shirt. In this example, $ 5.00 is added to the transaction price and the user is sent an email regarding the redemption and shipping of the cool T-shirt.

[0135] In some embodiments, the user can abandon or delete the offer and the mobile device 104 sends this information to the server 108 for analysis purposes. In one example, FIG. 11C presents a mobile device 104 displaying the deleted affordance 1164 in a second area corresponding to "offer B" 1154 in response to detecting a right-to-left swipe gesture in FIG. 11B. show. Continuing this example, FIG. 11D shows a mobile device 104 that discontinues displaying "offer B" 1154 in the special offer screen 1130 in response to detecting the selection of the deleted affordance 1164 in FIG. 11C.

[0136] In some embodiments, one or more promotional offers are a unique identifier corresponding to a payment module, at least one of the current time and date, the location of an automated retailer, the location of a mobile device, And identified based on at least one of the unique identifiers corresponding to the user of the mobile device (1208). In some embodiments, the server 108 or a component thereof (eg, offer determination module 328, FIG. 3) is associated with the current time / date, current location, device ID associated with the payment module, and user of the mobile device. Determine / identify one or more sales promotion offers based on the user ID and the like. In some embodiments, the mobile device 104 or a component thereof (eg, offer module 234, FIG. 2) is associated with the current time / date, current location, device ID associated with the payment module, and user of the mobile device. One or more sales promotion offers are determined / identified from a set of offers stored in advance based on the user ID or the like. For example, the mobile device 104 identifies one or more promotional offers from the offer database 266 that includes offers (such as part of an update) previously sent to the application by the server 108.

[0137] In some embodiments, the promotional offer is a product or past behavior stored in the automated retailer 122 (eg, a previous offer selected by the user, a previous offer deleted by the user, by the user. Identified based on previous offers that were not selected). For example, "side-by-side" is a separate snack vending machine and soda vending machine. The user buys soda first. Then, when the user goes to trade with the snack machine, the user is offered an offer for a particular product (eg, to allow cross-sales promotion between soda distributors and snack distributors). Alternatively, the offer may be based on an offer that the user did not select from the soda machine or was previously actively deleted.

[0138] In some embodiments, the supplier of the server 108 and the payment module 124 facilitates promotional offers by product manufacturers and distributors and also with various product manufacturers and distributors. Manage the promotional market to promote competition between them. For example, a product distributor or manufacturer may offer a $ 0.25 discount on a particular item at all applicable regional junior colleges in PDT California from 2:00 pm to 4:00 pm on Thursday. In another example, the distributor or manufacturer of a product sells a 50% discount on the product on the day the product expires with respect to all applicable auto retailers (eg to sell perishable sandwiches, etc.). Can make promotion offers. In some embodiments, a cross-promotion offer or combined promotion in which a user obtains credit (eg, a refund) for purchasing a particular beverage / snack combination (beverages and snacks are manufactured or distributed by different entities). Offers can also be made.

[0139] In some embodiments, promotional offers (substantially subsidies) for all goods in an automated retailer on the entity's premises are available only for user selection. For example, all lawyers and staff in law firms are given a snack subsidy rate, but cleaners do not benefit from the subsidy rate. In another example, all full-time workers are given a snack subsidy rate, but dispatched workers do not benefit from the subsidy rate.

[0140] In some embodiments, variable pricing is provided, which can change the base price of the goods and add promotional offers in addition to the variable price method. For example, distributors want to lower prices for all goods in the machine that are applicable during off-peak hours (eg 9:00 pm to 6:00 am). Therefore, after the transaction is completed, the server 108 charges the user only for the reduced price, and after the server processes and accounts for the transaction, the transaction approval information displayed on the mobile device 104 is automatically retailed by the user. It would indicate that only the reduced price was charged, not the price shown on machine 122.

[0141] The mobile device detects user input to select each promotional offer for one or more promotional offers (1210). For example, user input is contact input, voice input, or the like. 11D shows, for example, a mobile device 104 that detects the selection of the selection affordance 1153 of "offer A" 1152, FIG. 11E shows the selection affordance 1153 in response to detecting the selection of the selection affordance 1153 of FIG. 11D. Indicates that it has been selected. In some embodiments, each promotional offer is a negative promotional offer, such as a donation to an AIDS study that adds a selected amount to the user's next transaction. Alternatively, in some embodiments, each promotion offer is a negative promotion offer that rounds the transaction to the nearest dollar, where the additional amount is donated to the Cancer Research Foundation.

[0142] The mobile device initiates a transaction with an automated retailer combined with a payment module (1212), where the transaction corresponds to the purchase of goods stored by the automated retailer. In some embodiments, the transaction is initiated in response to the selection of each promotional offer (ie, one-click transaction initiation processing). For example, the transaction with the 8th floor snack machine is automatically started in response to detecting the selection of the selection affordance 1153 of FIG. 11D. In another embodiment, after the user selects an offer, the user performs an action to initiate a transaction with an automated retailer (ie, a two-step transaction initiation process). For example, after detecting the selection of the selection affordance 1153 in FIG. 11D, the mobile device 104 redisplays the transaction start screen 1110 (as shown in FIG. 11A), and the transaction with the 8th floor snack machine is on the transaction start screen 1110. It is initiated in response to detecting an upward swipe gesture emanating from region 1120.

[0143] In some embodiments, the fulfillment of a transaction with an automated retailer combined with a payment module is initiated by sending an authorization acceptance token containing an authorization code contained in a broadcast information packet to the payment module. (1214). In some embodiments, the transaction initiation act is that the mobile device 104 or a component thereof (eg, transaction initiation module 238, FIG. 2) sends a stored authorization acceptance token to the payment module 124 for payment. Including, the user manually selects a product using the user interface of the automatic retailer 122. Therefore, the automated retailer 122 knows nothing about the selected promotional offer, and the automated retailer 122 only knows that the user has sent a payment to the selected promotional offer. For example, the automatic retailer 122 returns the transaction and product information passed to the mobile device 104 by the payment module 124, but the automatic retailer 122 cannot determine or state in any way whether the product corresponds to the offer. For example, the transaction completion notice indicates that "E3 was sold for $ 1.00".

[0144] The mobile device receives a transaction completion notification from the payment module indicating that the product corresponding to each selected promotional offer has been sold by the automated retailer (1216). In some embodiments, the mobile device 104 or a component thereof (eg, transaction completion notification receiving module 240, FIG. 2) is a payment module 124 after the user manually selects a product using the user interface of the automatic retailer 122. Receives transaction completion notifications (eg, transaction status information, transaction details, other miscellaneous information about the automated retailer 122 to which each payment module 124 and / or each payment module 124 is combined, etc.). In some embodiments, the transaction completion notification is the transaction-related goods / services, the current inventory of the automated retailer 122, or the information related to one or more previous cash transactions, one or one processed by the payment module 124. Includes information related to multiple blocked transactions and / or other information related to the automated retailer 122 such as errors or maintenance status. In some embodiments, the payment module 124 issues an error message instead of a transaction completion notification when a transaction is interrupted or an error occurs during the transaction period (such as the requested goods / services unavailable or sales jam). Send.

[0145] In response to receiving the transaction completion notification, the mobile device provides the mobile device user with a prompt to obtain the product code of the product sold to validate each promotional offer. (1218). In some embodiments, the mobile device 104 or a component thereof (eg, product code processing module 242, FIG. 2) displays a scanning interface for capturing the product code of the goods to be sold after receiving the transaction completion notification. do. FIG. 11F is a product code screen that prompts the user of the mobile device 104 to obtain the product code of the product A (eg, UPC code, SKU, etc.) to verify, for example, the “offer A” 1152 selected in FIG. 11D. Shows mobile device 104 displaying 1170. The product code screen 1170 also includes a product code scanner window 1172 for capturing an image of product A and / or scanning the product code of product A. In FIG. 11F, the UPC code 1174 of the product A (eg, the candy bar) within the view of the camera of the mobile device 104 is shown in the product code scanner window 1172. For example, the user of the mobile device 104 taps in the product code scanner window 1172, issues an audible command, presses a predetermined physical button on the mobile device 104, and so on, thereby displaying an image of the product A (in the current field of view). Can capture (including UPC code 1174) or scan UPC code 1174.

[0146] In another embodiment, the mobile device 104 or a component thereof (eg, product code processing module 242, FIG. 2) is mobile to manually enter or otherwise obtain the product code of the goods to be sold. A pop-up message or banner notification prompting the user of the device 104 is displayed on the display. In another embodiment, the mobile device 104 or a component thereof (eg, product code processing module 242, FIG. 2) tells the user of the mobile device 104 to enter or otherwise obtain the product code of the goods to be sold. Provides a prompting audible sound, a voice prompt, or a series of tactile / tactile vibrations.

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

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

[0149] After obtaining the product code, the mobile device sends the product code to the server (1226). In response to sending the product code, the mobile device: receives promotional verification information from the server; and displays promotional verification information on the display indicating whether each promotional offer has been validated. In some embodiments, the mobile device 104 or a component thereof (eg, product code processing module 242, FIG. 2) verifies the acquired product code or sends the acquired product code to the server 108 for verification. Either to do. In some embodiments, the mobile device 104 or its components (eg, information relay module 244, FIG. 2) trade regardless of whether the user follows a prompt and whether the mobile device 104 finally obtains the product code. The completion notification or a part thereof is sent to the server 108. In some embodiments, the server 108 determines whether the terms for each promotional offer are based on a transaction and product code. For example, the server 108 determines whether the appropriate product code has been obtained for each promotion offer, whether each promotion offer has expired, and whether the user has "purchased N items for free. Determine if the "get" condition is met, whether the user meets the cross-promotion condition, and so on. In some embodiments, the offer is validated by the server 108 and applied to the user account.

[0150] In some embodiments, the mobile device 104 or a component thereof (eg, offer verification module 246, FIG. 2) receives and displays promotional verification information. For example, the promotion verification information indicates whether the offer has been validated and the updated user balance / transaction list. FIG. 11G shows, for example, a mobile device 104 displaying an offer verification screen 1180, where the offer verification screen 1180 indicates that "offer A" 1152 has been verified and that $ 0.25 has been credited to the user's balance. And. FIG. 11G also shows that the user of the mobile device 104 is $ 99.25 ($ 0.25 from the amount shown in FIG. 11G due to the validation of "Offer A" 1152 and the deposit of $ 0.25 for "Offer A" 1152. Large) indicates that you have a prepaid balance. For example, if the user gets the fifth purchased product for free, and the only product that was the target of the instant transaction is the first item to be purchased, the promotion verification information is "User free. You must buy three or more products before you can get them. " In some embodiments, the promotional verification information includes coupons for products or services that are not related to the automated retailer 122. For example, a user is emailed a $ 5 discount coupon for an amusement park for purchasing soda.

[0151] In some embodiments, after obtaining the product code, the mobile device determines if a predetermined period has expired (1228). Upon determining that it has expired, the mobile device provides users of the mobile device with a notification that each promotional offer has expired. Upon determining that it has not expired, the mobile device sends the product code to the server. In some embodiments, the predetermined period corresponds to the time between (A) the time when the transaction is started or the product code is waited for and (B) the time when the product code or some other period is acquired. do. For example, the mobile device 104 must receive the product code within 5 minutes of the prompt or within 5 minutes of the start of the transaction. In some embodiments, this can occur after hours or even days. In some embodiments, a predetermined proximity between the first position where the transaction was started and the second position where the product code was obtained is used in addition to or instead of the predetermined time period.

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

[0153] In some embodiments, the promotional verification information indicates the price of the product after the application of each promotional offer (1230). For example, the mobile device 104 displays the total amount deducted from the user account or charged to the user's linked bank card after the promotion offer is applied to the base purchase price included in the notification completion information. FIG. 11G shows, for example, a user of mobile device 104 $ 99.25 ($ 0.25 from the amount shown in FIG. 11G due to verification of "Offer A" 1152 and deposit of $ 0.25 for "Offer A" 1152. Large) indicates that you have a prepaid balance.

[0154] In some embodiments, the mobile device sends a transaction completion notification to the server (1232). In some embodiments, the mobile device 104 or a component thereof (eg, information relay module 244, FIG. 2) is a transaction completion notification (eg, transaction status information, transaction details, respective payment modules 124 and / or respective payments). Other miscellaneous information about the automatic retailer 122 to which the module 124 is coupled, etc.) or a portion thereof is transmitted to the server 108 prior to or together with the product code. In some embodiments, the transaction completion notification or a portion thereof is sent to the server 108 regardless of whether the user follows the prompt and the mobile device finally obtains the product code.

[0155] The specific order in which the operations in FIGS. 12A-12C are described is merely exemplary, and is intended to indicate that the order described is the only order in which the operation may be performed. It should be understood that it has not been done. One of ordinary skill in the art will recognize various ways of rearranging the operations described herein. In addition, details of other processes described herein (eg, processes 800 and 900) with respect to other methods and / or processes described herein are also described above with respect to FIGS. 12A-12C. It should be noted that it is applicable in a manner similar to Method 1200.

[0156] Although specific embodiments have been described above, it will be understood that they are not intended to limit their application to these specific embodiments. Conversely, these applications include alternatives, modifications and equivalents that fall within the spirit and scope of the appended claims. Many specific details are provided to fully understand the subject matter presented herein. However, it will be apparent to those skilled in the art that the subject matter can be practiced without these specific details. In other examples, well-known methods, procedures, components, and circuits have not been described in detail so as not to unnecessarily obscure aspects of the embodiment.

Asynchronous mobile payments for parallel transactions
[0157] The embodiments described in this chapter include methods and systems for processing multiple transactions in parallel and asynchronously between one or more consumer devices and merchant devices. In some embodiments, the merchant device (FIGS. 13, 1304) runs the merchant app (FIGS. 13, 1302), and one or more consumer mobile devices 104 run the consumer app 102, one or more. The server 108 interacts with both the merchant and consumer apps (eg, on a long-range network connection 110 such as the Internet or wireless mobile network). In this system, the merchant and consumer apps are in close proximity to each other so that they are within range of a local communication network 111 (eg, wifi, Bluetooth or IEEE 802.15.4 network). In some embodiments, the merchant app and / or the consumer app is an operation described with reference to other parts of the application (eg, an operation described with reference to any of FIGS. 8-12, FIG. 1). Perform all or a subset of any of the operations related to the mobile device 104 described above with reference to and / or the operations related to the payment module 124 described above with reference to FIG. It is additionally configured as.

[0158] In some embodiments, the merchant app is ready while idle (eg, while in sleep or background mode) and therefore initiates payment processing (eg, broadcasting a merchant identifier). Does not require any special instructions. In some embodiments, the merchant app broadcasts its unique identifier over a local radio for short-range communication. The consumer app in the vicinity of the merchant app (see FIGS. 17-18) picks up the broadcast unique identifier and then the consumer app passes this identifier to the server. The server may include, but is not limited to, the merchant's name, logo, photo, address, phone, reward, available offers, and any preset transaction amount (eg, the amount required by the merchant to complete the proposed transaction). And return the merchant details including rewards or loyalty points.

[0159] In some embodiments, the merchant information is presented to the consumer within the consumer app (FIG. 23A). If more than one merchant is in the vicinity, the consumer app presents all available merchants to allow the consumer to select the merchant with whom he wants to make a face-to-face transaction (FIG. 23B). The available merchant list is presented within the consumer app, and in some embodiments can be sorted according to the distance to the merchant based on the signal strength of the short range radio communication. Sorting may also be based on set position (eg GPS) coordinates or may be set from a server configuration for each merchant's sort order.

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

[0161] After entering the required information, the consumer can initiate payment to the selected merchant (eg, Figure 24, "Send Payment"). Payments are sent to the server by the consumer app. In particular, in some embodiments, payments are not sent directly to the merchant app via the short-range communication network 111. Rather, the consumer app sends the payment to the server over the long-distance communication network 110.

[0162] The server then processes the payment and sends a notification to the merchant app that the payment has been made. Confirmations are also sent to the consumer app.

[0163] In some embodiments, there are multiple consumers (using each of the plurality of consumer devices 104) transmitting payments in parallel to the same merchant. In some embodiments, the broadcast from the merchant app (including the merchant's unique identifier) is unencrypted and can therefore be picked up by any consumer app in the vicinity of the merchant device's short-range wireless communication. Each consumer device pays based on the server's requirements (eg, handling server bandwidth limits) to be able to process multiple requests simultaneously once it initiates payment on its consumer app. Can be sent at the same time.

[0164] In some embodiments (FIG. 20), the merchant inputs the amount to be charged into the merchant app (FIG. 25A). This amount is then broadcast over the short-range communication radio with a unique identifier or in a later broadcast. The consumer app picks up this amount from the broadcast and / or restricts consumers from sending different amounts to save consumer effort that requires entering this amount, and then use this amount. Pre-fill in the consumer app (eg, in the "Amount" field of FIG. 24A). Pre-filling the amount field also minimizes errors when the merchant, not the consumer, enters the amount to be paid, ensuring that this amount is correct. Consumers may optionally add a reminder surcharge.

[0165] In some embodiments (FIG. 21), the merchant configures a preset amount on the server. Next, the preset amount is returned from the server to the consumer app. Neither the merchant nor the consumer enters a preset amount. Consumers choose from a list of amounts to be sent (Fig. 26B).

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

[0167] In some embodiments, the merchant may have more than one unique identifier directed to the same merchant record, or may have more than one unique identifier pointing to more than one merchant record. You may. Unique identifiers do not have to be fixed and may change on demand or automatically via a schedule.

[0168] With respect to embodiments relating to preset payment amounts on the server, the merchant app can act as a beacon (in addition to or as an alternative to being implemented as a smartphone or other type of mobile device), and the beacon is a beacon. Provides any compatible consumer app within the scope of the information that allows the consumer app to make such payments on the server.

[0169] In some embodiments, the server is notified by a separate device (other than the Merchant App), such as a smartwatch or other device owned (or otherwise used) by the merchant. Can be sent to the merchant.

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

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

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

[0173] Consumer application 102 provides consumer-side functionality of the payment processing system 1300 and communication with both the server-side module 106 and the merchant application 1302. In some embodiments, the application associated with the consumer module 102 provides a user interface to the payment processing system 1300 for the consumer device 104. The consumer module 102 communicates with the server-side module 106 via a long-range communication protocol (eg, GSM, CDMA, Wi-Fi, etc.) over one or more networks 110, the consumer module 102 has one or more shorts. It communicates with the merchant module 1302 via a short-range communication protocol (eg, Near Field Communication (NFC), BLUETOOTH, BLUETOOTH Low Energy (BLE), etc.) over the range network 111. The server-side module 106 provides the server-side functionality of the payment processing system 1300 of any number of consumer modules 102 and merchant modules 1302, each resident on the mobile device 104 or 1304, respectively.

[0174] Examples of mobile devices 104 and 1304 include, but are not limited to, handheld computers, wearable computer devices, mobile information terminals (PDAs), tablet computers, laptop computers, desktop computers, cellular phones, smartphones, augmented general purpose packet wireless services. (EGPRS) Mobile phones, media players, navigation devices, game consoles, televisions, remote controls, sales floor (POS) terminals, in-vehicle computers, electronic book readers, or any combination of any two of these data processing devices or other data processing devices. including.

[0175] Examples of one or more networks 110 include a local area network (LAN) and a wide area network (WAN) such as the Internet. One or more networks 110 can optionally be Ethernet, Universal Serial Bus (USB), FIREWIRE, Long Term Evolution (LTE), World Mobile Communication System (GSM), Enhanced Data GSM Environment (EDGE), Code. Includes various wired or wireless protocols such as split multiple access (CDMA), time split multiple access (TDMA), Bluetooth, Wi-Fi, voice over internet protocol (VoIP), Wi-MAX or any other suitable communication protocol. Implemented using any known network protocol.

[0176] The server system 108 is implemented on a distributed network of one or more stand-alone data processors or computers. In some embodiments, the server system 108 is also of a third party service provider (eg, a third party cloud service provider) to provide the computational and / or infrastructure resources underlying the server system 108. Adopt various virtual devices and / or services. In some embodiments, the server system 108 includes, but is not limited to, a handheld computer, a tablet computer, a laptop computer, a desktop computer, or any combination of two or more of these data processing devices or other data processing devices.

[0177] The payment processing system 1300 shown in FIG. 1 includes both a client-side portion (eg, consumer modules 102, 1302) and a server-side portion (eg, server-side module 106). In some embodiments, the data processing is performed as a stand-alone application installed on the mobile device 104 and / or 1304. In addition, the functional division between the client portion and the server portion of the payment processing system 1300 can vary in various embodiments. For example, in some embodiments, the consumer module and the merchant module 102 and / or 1302 provide only user-directed input and output processing functions and all other data processing functions to a back-end server (eg, a server). Transfer to system 108). Many aspects of the technique have been described in terms of the server system 108, but the actions taken by the mobile device 104 and / or 1304 will be apparent to those of skill in the art without creative effort. Further, some aspects of the technique may be performed by the server system 108, by the mobile device 104 and / or 1304, or by the server system 108 and the mobile device 104 and / or 1304 in cooperation.

[0178] FIG. 14 is a block diagram of a merchant device 1304 associated with a merchant according to some embodiments. The merchant device 1304 is typically one or more processing units (CPUs) 1402, one or more communication devices 1404, memory 1406, and one or more for interconnecting these components (sometimes referred to as chipsets). Includes communication bus 1408. The two or more communication devices 1404 are a first transmitter / receiver associated with a short-range communication protocol (eg, NFC, BLE, etc.) and a second transmitter / receiver associated with a long-range communication protocol (eg, GSM, CDMA, Wi-Fi, etc.). Including transmitter / receiver. The merchant device 1304 also includes a user interface 1410. The user interface 1410 comprises one or more output devices 1412 (including one or more speakers and / or one or more image displays) that allow the presentation of media content (eg, text, images, audio, video, etc.). include. The user interface 1410 also includes user interface components such as a keyboard, mouse, voice command input unit or microphone, touch screen display, contact sensing input pad, gesture capture camera or other input button or control to facilitate user input 1. Or includes a plurality of input devices 1414. Further, in some embodiments, the mobile device 1304 uses a microphone and voice recognition or a camera and gesture recognition to complement or replace the keyboard. In some embodiments, the mobile device 1304 optionally comprises one or more sensors 1415 that provide contextual information about the current state of the merchant device 1304 or the environmental state associated with the merchant device 1304. One or more sensors 1415, but 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, Includes one or more biometric / biological sensors and the like. In some embodiments, the merchant device 1304 optionally provides a position sensing device 1417, such as a GPS (Global Positioning Satellite) receiver or other geographic location receiver to determine the position of the merchant device 1304. include.

[0179] Memory 1406 includes high speed random access memory such as DRAM, SRAM, DDR RAM or other random access solid memory device, optionally one or more magnetic disk storage devices, one or more optical disk storage. Devices include non-volatile memory such as one or more flash memory devices, or one or more other non-volatile solid storage devices. Memory 1406 optionally includes one or more storage devices located apart from one or more processing units 1402. Non-volatile memory in memory 1406 or alternative memory 1406 includes non-temporary computer-readable storage media. In some embodiments, memory 1406 or a non-temporary computer-readable storage medium in memory 1406 stores the following programs, modules, data structures, or subsets or supersets thereof:
● Operating system 1416, which includes procedures for handling various basic system services and for performing hardware-dependent tasks;
● Communication module 1418 for transmitting and receiving signals to and from other devices (eg, server system 108 and consumer module 102) via two or more communication devices 1404;
● To the presentation module 1420 (eg, application 1426, or merchant module 1302) for allowing presentation of information on the merchant device 1304 via one or more output devices 1412 (eg, display, speaker, etc.) associated with the user interface 1410. User interface for related applications, widgets, websites and their web pages and / or games, audio and / or video content, text, etc.);
An input processing module 1422 for detecting one or more user inputs or interactions from one or more input devices 1414 and interpreting the detected inputs or interactions;
● Web browser module 1424 for navigating, requesting (eg via HTTP) and displaying websites and their web pages;
● One or more applications 1426 for execution by merchant device 1304 (eg games, application markets, payment platforms, and / or other web or non-web-based applications);
● A merchant module 1302 that provides data processing and functions on the merchant side of the payment processing system 1300, including, but not limited to, the merchant module 1302:
Asynchronous payment acceptance module 1450 that provides the merchant-side payment function of the payment processing system 1300, including, but not limited to, asynchronous payment acceptance module 1450:
○ A broadcast module 1452 for broadcasting an information packet to zero or more consumer devices 104 within the communication area (ie, BLE range) of the merchant device 1304, wherein the information packet is a unique identifier corresponding to the merchant device 1304. Broadcast module 1452; including (eg, device ID) and, in some embodiments, at least the payment amount associated with the proposed face-to-face transaction;
○ Accept the client payment amount for the proposed transaction via the input device 1414 (eg, using the free-form form as shown in Figure 25A or the choice menu as shown in Figure 25B) and use it for the proposed transaction. Customer Amount Module 1454 for sending a custom payment amount to the consumer device 104 by using the short-range communication device 1404;
○ Accept customer payment amounts and configure them as presets (eg by using a free-form form like Figure 25A or a menu of choices like Figure 25B) and then set the payment amount. A preset amount module for transmission to server 108 by using the long-range communication device 1404 for use in the proposed transaction 1456;
○ Confirmation module 1458 for receiving confirmation messages from server 108 (for example, confirming that a transaction has been completed, payment has been made by a specific consumer, etc.) by using the long-range communication device 1404; And ○ to send a response to the confirmation message to the consumer device 104 by using the short-range communication device 1404, or by using the long-range communication device 1404 (forwarding to the consumer device 104). A response module 1460 for sending to server 108, which is either automatic (eg, when a confirmation message is received) or manually entered and sent (eg, message). When the decision to send is made by the merchant), the message (eg, "thank you") is preselected or customized (eg, entered by the merchant using a free form field) Response Module 1460; And ● Merchant data 1460 that stores data related to the payment processing system 1300, including, but not limited to, the following merchant data 1460:
○ Merchant identification information related to merchant device 1304, including merchant identification information (eg, user ID) for broadcasting by short-range communication device 1404 according to broadcast module 1452, and merchant identification information. Merchant profile 1462; which optionally stores one or more of the name, logo, photo, address, phone or email of the proposed face-to-face transaction between the consumer device 104 and the merchant device 1304. Merchant data 1464; containing transaction information (including preset transaction amounts (eg, Figure 25B), available offers or available rewards); and ● Completed transactions between the merchant device 1304 and the consumer device 104. Transaction history 1470 (eg, a history of payments made by each consumer associated with each consumer device 104 to a merchant associated with merchant device 1304).

[0180] Each of the identified elements is stored in one or more of the memory devices described above and corresponds to a set of instructions for performing the function. The specified modules or programs (ie, sets of instructions) need not be implemented as separate software programs, procedures, modules, or data structures, and thus various subsets of these modules are combined in different embodiments. Can be or can be rearranged. In some embodiments, memory 1406 optionally stores a subset of modules and data structures identified above. In addition, memory 1406 optionally stores additional modules and data structures not described above.

[0181] FIGS. 15A and 15B are more detailed block diagrams of the asynchronous payment module 250 and the asynchronous payment data 270 of the consumer device 104 described above with reference to FIG.

[0182] In some embodiments, the asynchronous payment module 250 stores the following programs, modules or subsets or supersets thereof:
● A discovery module 252 for receiving one or more information packets broadcast by one or more merchant modules 1302 via the short-range communication device 204, where each information packet is at least each merchant device 1304. 252;
● Display one or more merchants corresponding to the received merchant identifier on the output device 212, and select a user on the input device 214 of one of the merchants (eg, “tap to pay” in FIG. 23A. : Tap to Pay "merchant selection module 254 for receiving affordance user selection (see, eg, FIGS. 23A and 23B);
● The received merchant identifier is sent to the server, the merchant identification information (eg 1462) and the merchant transaction information (eg 1464) associated with each merchant identifier are received from the server, and in some embodiments received. Merchant Details Module 256 for pre-populating a list of payment amounts or payment choices according to merchant transaction information;
● Receives consumer selection (via input device 214) of supplemental transaction data (eg, payment amount, offer or chip; see FIGS. 24 and 26B), and the selected supplemental transaction data via long-range communication device 204. Trading module 258 for sending to server 108;
as well as,
● Receive a confirmation message from the server 108 via the long-distance communication device 204 indicating that the server has completed the transaction, and optionally receive follow-up communication (eg, "thank you") from the merchant (direct reception). Confirmation module 260 for either) or transfer via server 108.

[0183] In some embodiments, asynchronous payment data 270 stores the following data structure or its subsets or supersets:
● Merchant identifier and / or payment amount information 272 received by one or more merchants within (or otherwise nearby) the short-range communication device 204 of the consumer device.

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

[0185] In some embodiments, the asynchronous transaction module 350 stores the following programs, modules or subsets or supersets thereof:
● Merchant detail module 352 for receiving a request for merchant detail 370 from consumer device 104 and transmitting each merchant detail 370 to each consumer device 104;
● Receive consumer regulation supplemental transaction data (eg payment amounts, offers or chips; see FIGS. 24 and 26B) from each consumer device 104, and merchant details (eg payment acceptance information such as deposit account information) and transactions. Process each transaction according to data (eg, user-specified or merchant-specified payment amount) and send each confirmation message (indicating a completed transaction, accepted or processed payment, etc.) to each merchant device 1304 and / or each. Transaction completion module 354 for sending to consumer device 104; and storing completed transaction information 382; and ● receiving communication (eg, "thank you") from merchant device 1304, and each communication. Communication module 356 for transmission to the consumer device 104.

[0186] In some embodiments, asynchronous transaction data 360 stores the following data structure or its subsets or supersets:
● Merchant details 370 for each merchant device 372, including, for example, merchant identification information 374 (name, logo, etc.), transaction information 376 (offers, rewards, etc.), and ● completed transaction information (payment amount, etc.) Merchant transaction 380 of each merchant 382 including transaction time etc.).

[0187] FIG. 17 is another view of the payment processing system 1300 according to some embodiments. In this example, the merchant application 1302 sets the merchant identifier (in some embodiments, the merchant-specified payment amount) received by the consumer application 102 when the consumer is within range of the network 111 to the short-range communication network 111. Broadcast via. The consumer app 102 sends the identifier to a server on the long-distance communication network 110, which returns the merchant's name and / or logo. The consumer app 102 draws the name and / or logo received by the server according to the broadcasted merchant identifier as shown in the exemplary interface depicted in FIGS. 23A (1 merchant) and 23B (2 or more merchants). do. In some embodiments, the consumer app prefills the payment amount field, or otherwise supplies one or more payment amount selections. The consumer makes a supplementary selection (eg, fills in the field of FIG. 24) and the consumer application 104 sends this selection to the server. The server then processes the transaction on behalf of the merchant. When the transaction is completed, the server notifies the merchant application 1302 via the long-distance communication network 110 that the transaction has been completed. In some embodiments, the server also notifies the consumer application 102 via the long-distance communication network 110 that the transaction has been completed.

[0188] FIG. 18 is another view of the payment processing system 1300 according to some embodiments. In this example, N consumer devices (104-1 to 104-N) are within range of the merchant device 1304, and each of the N consumer devices uses short-range communication to identify the merchant's unique identifier. To receive. Each of the N consumer devices queries the server 108 using long-distance communication for additional details (eg, name, logo) about the merchant associated with the merchant device 1304. Consumers associated with the N consumer devices 104 interact asynchronously with their respective consumer applications 102, make choices, and in an order that is not necessarily the same as the order in which the consumer device has already received the merchant details. Determine to send supplemental transaction data (eg payment amount) at various times. Therefore, the server 108 processes each transaction from each consumer device 104 when the supplementary transaction information reaches the server. In some embodiments, the server 108 processes each transaction (or a superposed portion of each transaction) in parallel. When each transaction is completed, the server 108 asynchronously sends confirmation notifications to the merchant 1304 in an order that is not necessarily the same as the order in which the processing started. In some embodiments, the server 108 transmits confirmation notifications (or superimposed portions of confirmation notifications) in parallel.

[0189] FIGS. 19-22 are schematic flow charts of processing for processing payments asynchronously in the payment processing system 1300 according to some embodiments (1900, 2000, 2100, 2200, respectively). In some embodiments, the payment processing system 1300 includes one or more consumer devices 104, one or more merchant devices 1304, and a server 108. For each process, each of the one or more consumer devices 104 is in the foreground or back to access and communicate with other devices in the payment processing system 1300 (eg, servers 108 and one or more merchant devices 1304). An instance of the consumer module 102 (eg, as an application) is executed as a ground process. In addition, each of one or more merchant devices 1304 is in the foreground or background to access and communicate with other devices within the payment processing system 1300 (eg, servers 108 and one or more consumer devices 104). An instance of the merchant module 1302 (eg, as an application) is executed as a process. The server 108 manages the payment processing system 1300 and, in some cases, is associated with an entity that supplies, operates, and / or manufactures one or more merchant devices 1304. For simplicity, these processes will be described for each merchant device 1304 and each consumer device 104 within the payment processing system 1300.

[0190] In process 1900 (FIG. 19), merchant 1304 broadcasts a unique identifier. An exemplary broadcast has been described above with reference to FIG. 10A. In some embodiments, the broadcast is packet 1000 containing device ID 1002. In some embodiments, the broadcast packet contains only the device ID. Consumer 104 selects a merchant (FIG. 23A), requests merchant details from server 108, and server 108 responds with the requested details. Consumer 104 enters a payment amount (FIG. 24), and optionally selects an offer and / or specifies a tip amount, and then trade information for processing (consumer-specified payment amount, Offers and / or chips) are sent to the server 108. The server 108 processes the transaction and notifies the merchant 1304 and the consumer 104 that the payment has been accepted and therefore the transaction has been completed.

[0191] In process 2000 (FIG. 20), merchant 1304 broadcasts a unique identifier as described in the previous process. At some point before, during, and after the merchant device 1304 starts broadcasting, the merchant associated with the merchant device 1304 is defined using the payment amount (eg, the merchant UI depicted in FIG. 25A or 25B). T) is selected. The broadcast following this step includes both the device ID in the broadcast packet and the merchant-specified payment amount. Consumer 104 selects a merchant (FIG. 23A), requests merchant details from server 108, and server 108 responds with the requested details. Consumer 104 does not enter the payment amount as the payment amount has already been specified by the merchant (in this case, the "amount" field will be pre-filled in FIG. 24). Consumer 104 optionally selects an offer and / or specifies a tip amount, and then sends transaction information (merchant-specified payment amount, offer and / or tip) to server 108 for processing. The server 108 processes the transaction and notifies the merchant 1304 and the consumer 104 that the payment has been accepted and therefore the transaction has been completed.

[0192] In process 2100 (FIG. 21), merchant 1304 configures preset payment amounts (eg, by using the merchant UI as depicted in FIGS. 25A or 25B) and transfers those amounts to server 108. Send. Merchant 1304 broadcasts a unique identifier as described in the previous two processes. In some embodiments, the broadcast packet contains only the device ID. Consumer 104 selects a merchant (FIG. 23A), requests merchant details from server 108, and server 108 responds with the requested details (including the merchant-specified preset payment amount). Consumer 104 selects one of the merchant-specified preset payment amounts (FIG. 26B), and optionally selects an offer and / or specifies a tip amount, and then trade information for processing. (Current payment amount, offer, and / or tip specified by the merchant) is sent to the server 108. The server 108 processes the transaction and notifies the merchant 1304 and the consumer 104 that the payment has been accepted and therefore the transaction has been completed.

[0193] In some embodiments, treatments 1900, 2000 and / or 2100 continue to treatment 2200 (FIG. 22). After the server 108 processes the transaction and notifies the merchant 1304 and the consumer 104 that the transaction has been completed, the merchant 1304 transmits a message (eg, "thank you") to the consumer 104. In some embodiments, the message is propagated by the merchant 1304 sending the message to the server 108, which in turn sends the message to the consumer 104.

[0194] It should be understood that the particular order in which the operations in FIGS. 19-22 are described is merely exemplary, and the order described is intended to be only the order in which the operations may be performed. It has not been. One of ordinary skill in the art will recognize various ways of rearranging the operations described herein. In addition, details of other processes described herein (eg, processes 800, 900 and 1200) with respect to other methods and / or processes described herein are also above with respect to FIGS. 19-22. It should be noted that the method described is applicable in a manner similar to 1900-2200.

[0195] FIGS. 23A, 23B, 24, 26A, 26B show a consumer device 104 displaying various user input (UI) screens for sending payments.

[0196] In FIG. 23A, the consumer device 104 has received one merchant identifier corresponding to "Pizza Family Cuisine" and has a name and a name for consumer selection ("tap to pay"). Identify the logo. In FIG. 23B, the consumer device 104 received three merchant identifiers corresponding to "Pizza Family Cuisine", "Red Windsor Cheese Shop" and "Lupines Flowers and Shrubberies". Therefore, each merchant is listed by name on the same screen and waits for the consumer's choice. Alternatively, each screen that is scrollable, swipeable, etc. contains only one merchant.

[0197] In FIG. 24, whether the consumer device 104 is pre-filled (for implementation relating to the merchant-specified payment amount) or fillable (for implementation relating to the customer-specified payment amount). Display the Amount field, which is one of them.

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

[0199] FIGS. 25A and 25B show merchant device 1304 displaying various UI screens for defining payment amounts.

[0200] In FIG. 25A, the merchant enters the merchant-specified payment amount in the fillable field. In FIG. 25B, the merchant selects from a menu of pre-filled payment amounts for defining the merchant-specific payment amount.

[0201] Although specific embodiments have been described above, it will be understood that they are not intended to limit their application to these specific embodiments. Conversely, applications include alternatives, modifications and equivalents that fall within the spirit and scope of the appended claims. Many specific details are provided to fully understand the subject matter presented herein. However, it will be apparent to those skilled in the art that the subject matter can be practiced without these specific details. In other examples, well-known methods, procedures, components, and circuits have not been described in detail so as not to unnecessarily obscure aspects of the embodiment.

Claims (14)

In a consumer device including a display, one or more processors, communication units, and memory, depending on the application running on the consumer device:
Identifying a first merchant device in the vicinity of the consumer device, at least in part, based on broadcast information transmitted by the first merchant device, wherein the broadcast information corresponds to the first merchant device. Includes, identifies;
Sending the first identifier to a server via the communication unit of the consumer device and receiving electronic communication from the server, including:
The first merchant identification information of the first merchant associated with the first merchant device, wherein the first merchant identification information is the name, logo, photo, address, telephone or email of the first merchant. First merchant identification information comprising one or more of the; and first merchant transaction information identifying a proposed face-to-face transaction between the consumer device and the first merchant, said. The first merchant transaction information includes the preset transaction amount, available offers or available rewards, first merchant transaction information;
Displaying the first merchant identification information on the display of the consumer device;
Receiving the selection of the first merchant identification information from the user of the consumer device;
In response to receiving said selection of said first merchant identification information:
Displaying the first merchant transaction information;
The first supplementary transaction information is to receive the first supplementary transaction information from the user of the consumer device, the first supplementary transaction information being the selection of the preset transaction amount, the selection of the available offer, the use. Receiving, which is a possible reward selection or free-form payment amount; and sending the first supplementary transaction information to the server; and sending the first supplementary transaction information to the server. A method comprising responding to receiving confirmation from the server that the proposed transaction between the consumer device and the first merchant has been completed. Following receiving confirmation from the server that the proposed transaction between the consumer device and the merchant has been completed, the server sends a message from the merchant confirming that the transaction has been completed. The method of claim 1, further comprising receiving from. The method is:
Identifying a second merchant device in the vicinity of the consumer device by the application running on the consumer device, at least in part, based on broadcast information transmitted by the second merchant device. , The broadcast information includes and identifies a second identifier corresponding to the second merchant device;
Further comprising transmitting the second identifier to the server via the communication unit of the consumer device;
The electronic communication received from the server is:
The second merchant identification information of the second merchant associated with the second merchant device, wherein the second merchant identification information is the name, logo, photo, address, telephone or email of the second merchant. Second Merchant Identification Information comprising one or more of the; and second Merchant Transaction Information identifying a proposed face-to-face transaction between the consumer device and the second merchant. The second merchant transaction information further includes the second merchant transaction information, including the preset transaction amount, available offers or available rewards;
Displaying the first merchant identification information on the display of the consumer device is
Displaying the second merchant identification information on the display of the consumer device, or an indicator that the second merchant identification information is available for display on the display of the consumer device. The method of claim 1 or 2, further comprising displaying. Displaying the first and second merchant identification information is to display the first and second merchant devices according to the first and second distances between the consumer device and the first and second merchant devices, respectively. 3. The method of claim 3, comprising displaying one of the merchant information of the first and second merchant information more prominently than the other of the first and second merchant information. The first and second signals are measured by measuring the first and second signal strengths associated with the broadcast information transmitted by the first merchant device and the broadcast information transmitted by the second merchant device, respectively. 4. The method of claim 4, further comprising determining the distance between the two. Displaying the first and second merchant identification information refers to one of the first and second merchant information according to the first and second position coordinates of the first and second merchant devices, respectively. The method of any one of claims 3-5, comprising displaying the first and second merchant information more prominently than others. Displaying the first and second merchant identification information refers to one of the first and second merchant information according to a preselected sort order associated with the first and second merchant devices. The method of any one of claims 3-6, comprising displaying the 1st and 2nd merchant information more prominently than others. display;
The memory according to any one of claims 1 to 7, wherein one or a plurality of processors; and a memory for storing one or a plurality of programs executed by the one or a plurality of processors. A mobile device that contains memory, including instructions for implementing the method. The method according to any one of claims 1 to 7, wherein the non-temporary computer-readable storage medium for storing one or more programs configured for execution by a computer system. A non-temporary computer-readable storage medium that contains instructions for implementing. In a server that includes one or more processors, communication units and memory
Depending on the application running on the server:
Receiving the first merchant identifier from the first consumer device;
Sending the following to the first consumer device according to the first merchant identifier:
The first merchant identification information of the first merchant associated with the first merchant device, wherein the first merchant identification information is the name, logo, of the first merchant associated with the first merchant device. First Merchant Identification Information, including one or more of a photo, address, phone or email; and a first merchant identifying a proposed face-to-face transaction between the consumer device and the first merchant. Transaction information, wherein the first merchant transaction information includes a preset transaction amount, available offers or available rewards;
The first supplementary transaction information is to receive the first supplementary transaction information from the first consumer device, the first supplementary transaction information being the selection of the preset transaction amount, the selection of the available offer, the use. A choice of possible rewards or a free-form payment amount entered on the first consumer device, receiving;
Processing transactions between the first consumer device and the first merchant device;
Sending confirmation to the first consumer device that the proposed transaction between the first consumer device and the first merchant has been completed; and the first consumer device and said. A method comprising sending, to the first merchant device, a confirmation that the proposed transaction with the first merchant has been completed. Following sending the confirmation to the first merchant device:
10. The method of claim 10, further comprising receiving a message relating to the completed transaction from the first merchant device; and transmitting the message to the first consumer device. Following receiving the first merchant identifier from the first consumer device:
Receiving the first merchant identifier from the second consumer device;
Sending the first merchant identification information and the first merchant transaction information to the second consumer device according to the first merchant identifier;
Prior to receiving the first supplemental transaction information from the first consumer device:
Receiving the second supplemental transaction information from the second consumer device;
Processing transactions between the second consumer device and the first merchant device;
Sending confirmation to the second consumer device that the proposed transaction between the second consumer device and the first merchant has been completed; and the second consumer device and said. 11. The method of claim 11, further comprising transmitting to the first merchant device a confirmation that the proposed transaction with the first merchant has been completed. A server comprising one or more processors and a memory for storing one or more programs executed by the one or more processors, wherein the one or more programs is any one of claims 10-12. A server that contains instructions for performing the methods described in the section. The method according to any one of claims 10 to 12, which is a non-temporary computer-readable storage medium for storing one or more programs configured for execution by a server. A non-temporary computer-readable storage medium that contains instructions to perform.

Images