Device and method for providing external access to a multi-drop bus peripheral device

Abstract

To provide external access to an electronic peripheral device disposed in a machine.SOLUTION: An electronic device includes a slave interface to couple to a machine controller of a machine via a communication bus, a host interface to couple to a first peripheral device of the machine, and a memory to store a program to be executed by a processor. Registering the electronic device as a slave to the machine controller, registering the first peripheral device as a slave to the electronic device, receiving a request from the mobile device to access a signal generated by the first peripheral device, validating the request, and sending a reset command to the first peripheral device via the host interface, the reset command including instructions to update a signal destination address of the first peripheral device from a controller address of the machine controller to a device address of the electronic device; SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] (Priority claims and related applications)

[0001] This application is a continuation of U.S. patent application Ser. No. 16 / 934,933, filed July 21, 2020.

[0002] FIELD OF THE INVENTION

[0002] This application relates to the technical field of electronic peripheral devices, and more particularly to a system for providing access to electronic peripheral devices over a non-persistent network connection. [Background technology]

[0003] Master / slave technology uses a dualistic model of communication in which one device or process (the master) controls one or more other devices (the slaves), sometimes called peripheral devices.

[0004]

[0004] Peripheral devices are often located at the functional interface between various internal components of a machine and the users of those components, thereby enabling human / machine interaction. Some types of peripheral devices may be removed and replaced (e.g., a universal serial bus (USB) mouse or keyboard) or accessed by external devices (e.g., a wireless printer), while other types of peripheral devices, such as bill acceptors and card readers, may be embedded in a machine and depend on the machine's features to operate (such as the machine's power source, processing system, and physical enclosure).

[0005] As the number of people with internet-connected mobile devices has grown exponentially, the uses for such devices have also diversified, with some uses even requiring specific types of peripheral devices that are extended or traditionally only accessible in embedded systems that do not necessarily provide access to external devices. Summary of the Invention

[0006]

[0006] Disclosed herein is a system for providing external access to an electronic peripheral device disposed on a machine. The system allows an external device to access functionality provided by the electronic peripheral device of the machine by providing wireless communication between a mobile application and the electronic peripheral device. To provide this access, the system (i) communicatively isolates the electronic peripheral device from a machine controller that normally functions as a master for the electronic peripheral device, and (ii) communicatively connects the electronic peripheral device to a mobile application that functions as a master for the electronic peripheral device until the mobile application no longer requires access to functionality provided by the electronic peripheral device. [Brief explanation of the drawings]

[0007] [Figure 1] FIG. 7 is a schematic diagram illustrating three zones: a “communication zone” (eg, Bluetooth range), an “authorization zone,” and a “payment zone,” according to some embodiments. [Figure 2]

[0008] 2 is a schematic diagram illustrating the three zones of FIG. 1 with multiple users therein according to some embodiments. [Figure 3]

[0009] 1 is a table illustrating hands-free credit or alert user principles according to some embodiments. [Figure 4]

[0010] 1 is a flowchart illustrating logging of received signal strength indicator (RSSI) information according to some embodiments. [Figure 5]

[0011] 1 is a block schematic diagram illustrating elements of a payment processing system, including an adapter module, a machine, a mobile device, and a server, and the communications therebetween, according to some embodiments. [Figure 6]

[0012] 1 is a block schematic diagram illustrating three areas (each bidirectional) of cryptography used between an adapter module, a machine, a mobile device, and / or a server, according to some embodiments. [Figure 7]

[0013] FIG. 10 is a block diagram illustrating communication, messaging, vending sequence, and purchase flow between an adapter module, a mobile device, and a system management server, according to some embodiments. [Figure 8A]

[0014] FIG. 1 is a schematic process flow diagram illustrating additional elements and features (e.g., communications, messaging, vending sequence, and purchase flow) of a payment processing system when a user enters a “communication zone” (e.g., Bluetooth range) in accordance with some embodiments. [Figure 8B]

[0015] 1 is a schematic process flow diagram illustrating additional elements and features (e.g., communications, messaging, vending sequence, and purchase flow) of a payment processing system when a user enters an “authorized zone,” according to some embodiments. [Figure 8C]

[0016] FIG. 1 is a schematic process flow diagram illustrating additional elements and features (e.g., communications, messaging, vending sequence, and purchase flow) of a payment processing system according to some embodiments when a user enters a “payment zone,” and particularly detailing hands-free mode and swipe mode embodiments. [Figure 8D]

[0017] 1 is a schematic process flow diagram illustrating additional elements and features (e.g., communications, messaging, vending sequence, and purchase flow) of a payment processing system for a vending transaction involving multiple transaction loops, according to some embodiments. [Figure 8E]

[0018] 1 is a schematic process flow diagram illustrating additional elements and features (e.g., communications, messaging, vending sequence, and purchase flow) of a payment processing system in login mode, according to some embodiments. [Figure 8F]

[0019] 1 is a schematic process flow diagram illustrating additional elements and features (e.g., communications, messaging, vending sequence, and purchase flow) of a payment processing system during adapter module boot-up, according to some embodiments. [Figure 8G]

[0020] 1 is a schematic process flow diagram illustrating additional elements and features (e.g., communications, messaging, vending sequence, and purchase flow) of a payment processing system during an account check / update process, according to some embodiments. [Figure 9]

[0021] 9A-E are flowcharts illustrating example steps and features (eg, communications, messaging, vending sequences, and purchase flows) of a payment processing system according to some embodiments. [Figure 10]

[0022] 10A-D illustrate a mobile device with a graphical representation of a mobile application used as part of a mobile device-machine payment processing system, according to some embodiments. [Figure 11]

[0023] 1 is a perspective view of an inline dongle adapter module according to some embodiments. FIG. [Figure 12]

[0024] FIG. 12 is a front plan view of the inline dongle adapter module of FIG. 11 according to some embodiments. [Figure 13]

[0025] FIG. 12 is a rear plan view of the inline dongle adapter module of FIG. 11 according to some embodiments. [Figure 14]

[0026] FIG. 12 is a side view of the inline dongle adapter module of FIG. 11 according to some embodiments. [Figure 15]

[0027] FIG. 12 is a first end view of the connector receptacle of the inline dongle adapter module of FIG. 11 according to some embodiments. [Figure 16]

[0028] FIG. 12 is a second end view of the connector receptacle of the inline dongle adapter module of FIG. 11 according to some embodiments. [Figure 17]

[0029] FIG. 12 is a perspective view from a first end of the inline dongle adapter module of FIG. 11 , showing in phantom the connector and cable into which the inline dongle adapter module is inserted, for illustrative purposes, in accordance with some embodiments. [Figure 18]

[0030] FIG. 12 is a perspective view from a second end of the inline dongle adapter module of FIG. 11 , showing the connector and cable into which the inline dongle adapter module is inserted in dashed lines for illustrative purposes, according to some embodiments. [Figure 19]

[0031] FIG. 12 is a perspective view of the inline dongle adapter module of FIG. 11 in a vending machine according to some embodiments. [Figure 20]

[0032] FIG. 1 is a block diagram of an adapter module according to some embodiments. [Figure 21]

[0033] FIG. 1 is a block diagram of a mobile device according to some embodiments. [Figure 22]

[0034] FIG. 2 is a block diagram of a server according to some embodiments. [Figure 23]

[0035] 1 is a schematic flow diagram of a process for authenticating a user to perform a transaction in a payment processing system according to some embodiments. [Figure 24A]

[0036] FIG. 10 is a block diagram of an information packet broadcast by a payment module (sometimes referred to herein as an “adapter module”) according to some embodiments. [Figure 24B]

[0037] FIG. 10 is a block diagram of an authorization request according to some embodiments. [Figure 24C]

[0038] FIG. 1 is a block diagram of an authorization grant token according to some embodiments. [Figure 24D]

[0039] FIG. 10 is a block diagram of transaction information generated by a payment module according to some embodiments. [Figure 25]

[0040] 1 is a schematic flow diagram of a process for processing authorization information in a payment processing system according to some embodiments. [Figure 26]

[0041] FIG. 1 is a block diagram of a device for adapting a payment accepting unit (e.g., machine 120) to accommodate multiple payment peripherals according to some embodiments. [Figure 27]

[0042] 1 is a schematic flow diagram of a payment peripheral registration process according to some embodiments. [Figure 28]

[0043] 28A and 28B show a schematic flow diagram of a payment process according to some embodiments. [Figure 29]

[0044] 1 illustrates a flowchart of a method for adapting a payment accepting unit to support multiple payment peripherals according to some embodiments. [Figure 30]

[0045] 30A and 30B show block diagrams of normal and intercept operations of a device for modifying a payment accepting unit (e.g., machine 120) to provide external access to electronic peripheral devices according to some embodiments. [Figure 31]

[0046] 1 illustrates a schematic flow diagram of a process for providing external access to an electronic peripheral device according to some embodiments. [Figure 32]

[0046] A schematic flow diagram of a process for providing external access to an electronic peripheral device according to some embodiments is shown. [Figure 33]

[0046] A schematic flow diagram of a process for providing external access to an electronic peripheral device according to some embodiments is shown. [Figure 34]

[0046] A schematic flow diagram of a process for providing external access to an electronic peripheral device according to some embodiments is shown. [Figure 35]

[0047] 35A and 35B illustrate a mobile device with a graphical representation of a mobile application being used as part of a peripheral device access system according to some embodiments. DETAILED DESCRIPTION OF THE INVENTION

[0008]

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

[0009]

[0049] Disclosed herein is a payment processing system, or more specifically, a mobile device-machine payment processing system for processing transactions over a non-persistent network connection. The mobile device-machine payment processing system disclosed herein focuses on unattended retail spaces (e.g., payment accepting units 120, sometimes referred to herein as "machines 120"). More specifically, the mobile device-machine payment processing system disclosed herein enables a user (having a mobile device 150 with a mobile application 140) to make cashless purchases from a payment accepting unit 120 (having an associated adapter module 100).

[0010]

[0050] The mobile device-machine payment processing systems described herein may be implemented with one or more of the following features: easy installation, non-persistent network connectivity, manual (swipe payment) mode, hands-free mode, and multi-vendor transaction (multi-vendor) functionality.

[0011]

[0051] Easy Installation: Installation is very easy, requiring no tools, no setup, and only 30 seconds. This is achieved by using an adapter module 100 (sometimes referred to herein as “payment module 100”) such as an inline dongle (a hardware device with software) design for inline insertion within the multi-drop bus (MDB) of a payment accepting unit 120 (e.g., a vending machine) (sometimes referred to herein as “machine 120”). Installation is as simple as "powering down" (turning off) the machine 120, identifying the "wire" that connects to the payment acceptance mechanism (e.g., coin mechanism), removing the wire (so that there are two loose ends, such as a male connection end or male adapter on the MDB and a female connection end or female adapter on the MDB), plugging (inserting) the wire in series ("in-line") into the adapter module 100 (e.g., connecting the female adapter on the MDB to the male adapter on the adapter module 100 and connecting the male adapter on the MDB to the female adapter on the adapter module 100), replacing the wire and installed adapter module 100 in place, and "powering up" (turning on) the machine 120. Most vending machines made after 1995 have this industry-standard MDB technology, which allows for this easy 30-second installation. In machines without MDB technology, the adapter module 100 may be configured or designed to function with other serial protocols or activate a switch. Essentially, the adapter module 100 simulates the establishment of a payment at the payment accepting unit 120 in much the same way as other alternative forms of payment (eg, cash).

[0012]

[0052] Non-Persistent Network Connection: While payment acceptance units (or "machines") that only accept cash (e.g., banknotes and coins) may not require a connection (permanent or non-permanent) to a network, traditional payment acceptance units that accept cashless payments (e.g., credit cards, debit cards, and alternative mobile device payment methods, e.g., using smartphones) require a permanent connection (wired or wireless) to a network to facilitate cashless payments. In other words, without a permanent (continuous or accessible on demand) network connection, traditional payment acceptance units cannot accept cashless payments. Most traditional payment acceptance units that accept cashless payments include technology to achieve this permanent network connection that allows them to connect to a remote server. If the network connection to a traditional machine is temporarily interrupted, cashless payments become temporarily unavailable. If the machine is located in a location where network connectivity is not available, cashless payments are not possible. In addition to using the mobile device 150 as an intermediary between the payment accepting unit 120 and the server 130, the mobile device-machine payment processing systems described herein minimize (i.e., manual mode) or eliminate (i.e., hands-free mode) user interaction with the mobile device 150. Furthermore, in some embodiments, the mobile device-machine payment processing systems described herein facilitate cashless payment acceptance without requiring any network connection in the vicinity of the payment accepting unit 120. Thus, in some embodiments, even when the mobile device-machine payment processing systems described herein are located in remote locations where network connectivity is unavailable, the mobile device-machine payment processing systems can still accept cashless payments.

[0013]

[0053] Manual (Swipe Pay) Mode: Using the "Swipe Pay" feature (or simply "Swipe") refers to a user action (or other predetermined interaction) performed on the user's mobile device 150 in which the user quickly swipes a finger on the mobile device's touchscreen 152 (FIGS. 10A-10D) or other input device associated with the mobile device 150. From the user's perspective, a pre-installed mobile application 140 automatically connects to a payment accepting unit 120 (e.g., a vending machine) when the user is within range. The mobile application 140 may display (on the touchscreen 152) a prepaid balance that the user "swipes" to transfer payment to the payment accepting unit 120. The user can view the transferred funds on the touchscreen 152 of the mobile device 150 and / or on the display 122, 124 of the payment accepting unit 120 (FIG. 19). The transaction is completed as if cash had been inserted into the machine 120, with the user entering a selection into the payment acceptance unit 120, which then provides the product or service. After the selection is made, change is returned to the mobile device 150, which may be shown on the touchscreen 152 of the mobile device 150.

[0014]

[0054] Hands-Free Mode: The "hands-free payment" feature (or simply "hands-free") is most likely to be used with a "favorite" payment accepting unit 120 (e.g., a frequently used vending machine at the user's workplace or school). From the user's perspective, the user approaches the favorite payment accepting unit 120, notices that the display 122, 124 (FIG. 19) of the payment accepting unit 120 shows available funds, uses the payment accepting unit's input mechanism (e.g., buttons 126 or touchscreen display 124 shown in FIG. 19) to select a product or service, and retrieves the offered service or product. It's that simple. More specifically, when the user is within range, the pre-installed mobile application 140 automatically connects to the payment accepting unit 120 (e.g., a vending machine). The user may leave the mobile device 150 in their pocket, purse, briefcase, backpack, or other carrier. When the user approaches the payment accepting unit 120 and is approximately at "arm's length" (e.g., 3-5 feet) from the payment accepting unit 120, the user can view the transferred funds on the display 122, 124 (FIG. 19) of the payment accepting unit 120. The transaction is completed as if cash had been deposited into the payment accepting unit 120, with the user entering a selection into the payment accepting unit 120 and the payment accepting unit 120 providing the product or service. After the selection is made, change is returned to the mobile device 150. FIG. 3 details when hands-free mode is available.

[0015]

[0055] Multiple Vending Transactions (“Multi-Vending”): Both the manual mode and the hands-free mode may be used multiple times in succession (e.g., implemented as a loop) to allow a user to make multiple purchases. After the user makes an initial selection and receives a product (or service), the user will see that additional funds are available on the display 122, 124 ( FIG. 19 ) of the payment accepting unit 120. The user can make another selection (or multiple selections) and receive additional products (or services). More specifically, the display 122, 124 ( FIG. 19 ) may reset as if the transaction was completed, but because the user is still within range, the mobile application 140 will send another credit to the payment accepting unit 120, allowing for a second purchase. When the user walks away, the system clears (e.g., returns any unused funds to the application 140 on the mobile device 150).

[0016]

[0056] The above features, alone or in combination with other features described herein, will revolutionize the $100 billion automated retail industry. The hardware is very low cost, and the machines 120 do not require cellular connectivity, eliminating recurring costs. Using the mobile device-to-machine payment processing system described herein, machine 120 operators can increase the frequency of customer visits and the number of items sold per visit.

[0017]

[0057] The mobile device-machine payment processing systems described herein may be implemented as apparatuses, systems, and / or methods for enabling payments to machines 120 via mobile devices 150. The mobile device-machine payment processing systems may be better understood with reference to the drawings, although the mobile device-machine payment processing systems shown are not intended to be limiting in nature.

[0018] definition

[0058] Before describing the mobile device-machine payment processing system and diagrams, some terminology needs to be clarified. Note that terms and phrases may have additional definitions and / or examples throughout this specification. Unless otherwise defined, words, phrases, and acronyms are given their ordinary meaning in the art. The following paragraphs provide some definitions of terms and phrases used herein.

[0019]

[0059] Adapter Module 100: As shown in FIGS. 1 and 2 , adapter module 100 (sometimes referred to herein as “payment module 100”) is a physical device installed in machine 120 (payment accepting unit 120). The adapter module 100 shown is an in-line dongle (a hardware device with software) device that can be inserted serially into the multidrop bus (MDB) of machine 120. Adapter module 100 bridges communications between machine 120 and mobile device 150. While described as a sole component, it should be noted that adapter module 100 may be implemented as multiple devices or integrated into other devices (e.g., components of machine 120). In its sole component form, adapter module 100 may be easily inserted into machine 120 such that machine 120 can perform new functions with the aid of adapter module 100. FIG. 20 illustrates components associated with adapter module 100. 20, the communication unit 770 of the adapter module 100 includes short-range communication capabilities 776 (e.g., Bluetooth mechanisms). The illustrated example may be split into multiple separate components that are associated with each other, as long as the components are associated with each other, or such example may be incorporated into or derived from other technology (e.g., a computer or payment acceptance unit).

[0020]

[0060] Mobile device 150 and application 140 (also referred to as a "mobile application," "mobile app," or "app"): Generally, the mobile device 150 may be a user's personal mobile device 150. The mobile device 150 (including the mobile application 140) acts as a bridge for communication between the adapter module 100 (associated with the payment accepting unit 120) and the server 130. However, the mobile device 150 and application 140 are not "trusted" in that the communications (transmissions) passed through them are encrypted. Encrypted (protected) communications cannot be deciphered (decrypted, unreadable, and / or unusable) by the mobile device 150. This keeps the communications passed between the adapter module 100 and the server 130 secure and safe from hacking. Mobile devices include smartphones, tablet or laptop computers, or personal digital assistants (PDAs), smart cards, or other known or yet to be discovered technologies (e.g., combinations of hardware and software) having a structure and / or functionality similar to the mobile devices described herein. Mobile device 150 preferably has an application (e.g., application 140) running thereon. The term "app" is used broadly to encompass any software program capable of performing the functions described herein. FIGS. 10A-10D illustrate the user interface of application 140 displayed by mobile device 150. Note that the term "mobile device" may be assumed to include associated apps unless otherwise specified. Similarly, note that an "app" may be assumed to be running on an associated mobile device unless otherwise specified. FIG. 21 illustrates components associated with mobile device 150. The illustrated examples may be divided into multiple separate components that are associated with each other, to the extent that the components are associated with each other, or such examples may be incorporated into or derived from other technologies (e.g., a mobile phone itself).

[0021]

[0061] Payment Accepting Unit 120 (or Machine 120): A payment accepting unit 120 (or machine 120) is a device that requests payment for the provision of products and / or services. A payment accepting unit 120 may be a vending machine, a parking meter, a toll booth, a laundromat washer and dryer, an arcade game, a kiosk, a photography device, a toll booth, a transit ticket dispenser, and other known or yet to be discovered payment accepting units 120. Some payment accepting units 120 can accept cashless payments (payments other than cash (bills and coins)), for example, by accepting payments from credit cards, debit cards, and mobile devices.

[0022]

[0062] Network Connection: For purposes of this discussion, a persistent network connection is a wired or wireless communication connection that is ongoing (e.g., a dedicated connection, a dedicated online connection, and / or a hardwired connection) or accessible on demand (e.g., the ability of a machine to temporarily connect to a server or the ability of a user to contact a server from a mobile device). Typically, a persistent network connection has been made via a “long-range communication technology” or “long-range communication protocol” (e.g., hardwired, telephone network technology, cellular technology (e.g., GSM, CDMA, etc.), Wi-Fi technology, wide area network (WAN), local area network (LAN), or any known or undiscovered wired or wireless communication technology over the Internet). Traditionally, machines that accept payments other than cash require a persistent (ongoing or accessible on demand) connection to a network to facilitate payments. This is true, for example, for machines that accept credit and debit cards. The payment acceptance unit 120 described herein does not require a traditional persistent network connection. The user's mobile device 150 serves as the communications bridge between the adapter module 100 and the server 130. Communication between the user's mobile device 150 and a server (e.g., the system administration server 130 and / or the funding source server 160) occurs using long-range communication technologies. Communication between the user's mobile device 150 and the adapter module 100 of the payment accepting unit 120 occurs using "short-range communication technologies" or "short-range communication protocols" (e.g., Bluetooth (Bluetooth 4.0, Bluetooth Smart, Bluetooth Low Energy (BLE)), near field communication (NFC), ultra-wideband (UWB), radio frequency identification (RFID), infrared radio, inductive radio, or any wired or wireless technology that can be used for communication over known or undiscovered short ranges (approximately 100 feet or closer)). Thus, neither the adapter module 100 nor the payment accepting unit 120 requires a conventional permanent long-range wireless network connection.The communication technologies shown in the figures may be replaced with alternative similar communication technologies, and therefore the particular communication technologies shown are not meant to be limiting. For example, Wi-Fi technology may be replaced with another long-range communication technology.

[0023]

[0063] Server: The server is a host processing server that may be operated by the company that runs the payment processing system. For each user, the server 130 preferably maintains at least one "virtual wallet" with at least one "balance" of designated funds (which may be $0) for which the server 130 maintains an account. The balance may represent, for example, "cash" or may be "promotional value" representing funds that can be spent under certain circumstances. If these funds begin to deplete, the user may be notified (e.g., via application 140 on the mobile device 150) that additional funds need to be designated and / or transferred. Alternatively, funds from other sources (e.g., funding source server 160) may be automatically transferred to restore a predetermined balance. The balance may also be increased based on promotions (e.g., earned points or coupons). As shown in FIG. 22, the server comprises a suitable processor 950, memory 960 (which maintains an account of the user's balance in a manner similar to a gift card), and a communication system 970. As shown in FIG. 22, the communication unit 970 of the server 130 includes long-range communication capabilities 972 (e.g., cellular technology and / or Wi-Fi mechanisms). The server 130 also includes a security unit 955 for encrypting and decrypting messages. The server 130 receives authorization requests (sometimes referred to herein as “AuthRequests”) from the adapter module 100 (via the mobile device 150) and returns an authorization grant of funds (sometimes referred to herein as “AuthGrants” or “Authorization Grant Tokens”) if funds are available. FIG. 22 illustrates components associated with the server 130. The illustrated example may be divided into multiple separate components that are associated with each other, to the extent that the components are associated with each other, or such example may be incorporated into or derived from other technologies (e.g., computers or mainframes).

[0024]

[0064] Advertisement of Presence: Each adapter module 100 advertises its presence by broadcasting a signal (advertisement broadcast signal) to mobile devices within zones 102, 104, 106. Each adapter module 100 can listen to the advertisements of other adapter modules.

[0025]

[0065] Received Signal Strength Indicator (RSSI): The adapter module 100 may have self-calibrated signal strength to determine zone thresholds (e.g., payment zone threshold and authentication zone threshold). When a user selects an item (product or service) from the payment accepting unit 120, a received signal strength indicator (RSSI) is logged. At this time, it is assumed that the user is within "arm's length" (which may be a predetermined length that approximates the distance of a user standing in front of the machine to make a purchase) from the payment accepting unit 120. A mathematical calculation (i.e., a range heuristic) is performed to derive an optimal RSSI threshold at which payment should be triggered by the application 140 on the mobile device 150. The threshold may be specific to the payment accepting unit and may change over time. This optimal zone threshold is preferably reported to the mobile device 150 during the initial handshake.

[0026]

[0066] In-Range Heuristic: A mathematical calculation that determines an RSSI threshold for identifying when a user is in the authorization zone 104 and / or payment zone 102. This calculation can take into account many past data points and transaction-specific information, such as the mobile device 150 being used and the payment acceptance unit type, among other factors. Preferably, the RSSI is logged while the user is making their selection, which is a period during the entire process when the user is sure to be “in-range” (e.g., physically interacting with the machine 120, and therefore at arm's length from the machine 120). While the user is making their selection, the type of the user's mobile device 150, accelerometer data (e.g., whether the user is moving or stationary), and / or other information may also be logged. The adapter module 100 can provide the machine 120 with a baseline RSSI for the payment zone 102, and the application 140 can make + / - adjustments based on the particular mobile device 150 on which the application 140 is installed. Over a period of time, the payment processing system continues to improve itself based on additional data points.

[0027]

[0067] Authorization Request (“AuthRequest”): When a user enters the authorized zone 104, the mobile device 150 notifies the adapter module 100, which sends a secure authorization request (e.g., an encrypted authorization request) as a “message” (also called a communication or transmission) to the server 130 via the mobile device 150. The encryption may be performed by the security unit 755 ( FIG. 20 ) using security techniques (e.g., encryption and decryption means) that may be associated with the processing unit 750 and / or memory 760. Importantly, the AuthRequest is an authorization request for funds, not a transaction. The purpose of the funds is independent of the server 130.

[0028]

[0068] Authorization Grant Token ("AuthGrant"): This is a "message" (also called a communication or transmission) that is encrypted by security unit 955 (FIG. 22) using security technology (e.g., encryption and decryption means) of server 130 with a unique private key corresponding to adapter module 100. A secure authorization grant (e.g., an encrypted authorization grant) is passed in the form of a message from server 130 to adapter module 100 via mobile device 150. However, mobile device 150 cannot decrypt and / or read the message. The authorization grant is in response to an authorization request. The amount of funds authorized by an AuthGrant may be determined by factors including the amount of available funds (or if funds are not available, a microloan may be authorized), a pre-authorized amount (e.g., set by the server, set by the user during setup, set by the funding source, or a standard amount), a time restriction (e.g., only a certain amount per hour, or a predetermined amount at a particular time and day), a limit to a maximum amount for a given item on the machine (or an amount sufficient for two or three items in the machine), or one or more of these and other factors. Importantly, an AuthGrant makes funds available, but does not authorize a transaction. An AuthGrant may have an associated expiration date in that it may expire if not used within a predetermined period of time.The length of time before an AuthGrant expires may be determined by factors including the user's trustworthiness (e.g., the user has a long history with the payment processing system or some known provider (e.g., a credit card provider, bank, or credit union), the user's high credit rating, or the user's large wallet balance), a pre-authorized period (e.g., set by the server, set by the user during setup, set by the funding source, or a standard period), a time restriction (e.g., a predetermined period at a particular day and time, such as longer hours during breakfast, lunch, and dinner), a restriction by the machine or the products or services sold at the machine, a restriction by the number of other users near the machine (e.g., an AuthGrant may expire sooner at a busy machine), or one or more of these and other factors. An AuthGrant remains valid until it expires or until some other event occurs that terminates its validity (e.g., the user cancels it). This means that under normal circumstances, the mobile device 150 will hold an AuthGrant that authorizes the use of funds for a predetermined period that allows the user enough time to make a purchase. The authorized amount may be considered a "wallet balance" held within a virtual "wallet."

[0029]

[0069] Synchronization: Time may be synchronized from the server 130 to the adapter module 100. The server 130 sends the time information in an encrypted message, and the adapter module 100 uses the time encoded in the message for synchronization.

[0030]

[0070] A mobile device-machine payment processing system and its components may have associated hardware, software, and / or firmware (variations, subsets, or hybrids of hardware and / or software). The term “hardware” includes at least one “processing unit,” “processor,” “computer,” “programmable device,” and / or other known or yet to be discovered technology capable of executing instructions or steps (shown as processing unit 750 in FIG. 20 , processing unit 850 in FIG. 21 , and processing unit 950 in FIG. 22 ). The term “software” includes at least one “program,” “subprogram,” “set of instructions,” or other known or yet to be discovered hardware instructions or hardware-readable program code. Software may be loaded into hardware (or firmware) to create a “machine,” such that the software executes on the hardware and provides a structure for performing the functions described herein. Furthermore, software may be loaded into hardware (or firmware) to instruct a mobile device-machine payment processing system (and its components) to function in a particular manner described herein or to perform a sequence of operational steps described herein. "Hardware" such as the adapter module 100, mobile device 150, and payment accepting unit 120 may have software (e.g., programs and apps) loaded onto it. The phrase "loaded into hardware" also includes being loaded into memory associated with or accessible by the hardware (shown as memory 760 in FIG. 20, memory 860 in FIG. 21, and memory 960 in FIG. 22).The term "memory" is defined to encompass any type of hardware (or other technology) readable medium (also referred to as computer-readable storage medium), including attached storage media (e.g., hard disk drives, network disk drives, servers), internal storage media (e.g., RAM, ROM, EPROM, flash EPROM, or any other memory chip or cartridge), removable storage media (e.g., CDs, DVDs, flash drives, memory cards, floppy disks, flexible disks), firmware, and / or other known or yet to be discovered storage media. Depending on the purpose, memory may be transient and / or non-transitory. Any suitable "messages," "communications," "signals," and / or "transmissions" (including various types of information and / or instructions, including data, commands, bits, symbols, voltages, currents, electromagnetic waves, magnetic fields or particles, optical fields or particles, and / or any combination thereof) via suitable "communications channels," "transmission channels," and other means of transmitting signals, including any type of connection between two elements on a payment processing system (e.g., adapter module 100, mobile device 150, payment accepting unit 120, hardware systems and subsystems, and memory), will be used as appropriate to facilitate control and communication.

[0031]

[0071] It should be noted that the terms "program" and "subprogram" are defined as a series of instructions that may be implemented as software (i.e., computer program instructions or computer-readable program code) that may be loaded into a computer to create a "machine," such that the instructions executed on the computer result in a structure that implements the functions described herein or shown in the figures. Furthermore, these programs and subprograms may be loaded into a computer so as to instruct the computer to function in a particular manner, thereby creating a product that includes an instruction structure that implements the functions specified in one or more blocks of the flowchart. Programs and subprograms may also be loaded into a computer and executed by a series of operating steps on or by a computer to create a computer-implemented process in which the computer-executable instructions provide steps that implement the functions specified in one or more blocks of the flowchart. The phrase "loaded into a computer" also includes being loaded into the memory of the computer or into a memory associated with or accessible by the computer. Interacting but separate programs and subprograms may be associated with the adapter module 100, the server 130, and the mobile device 150 (including the mobile application 140), and these programs and subprograms may be divided into smaller subprograms to perform specific functions.

[0032]

[0072] The terms “message,” “communication,” “signal,” and / or “transmission” include various types of information and / or instructions, including data, commands, bits, symbols, voltage, current, electromagnetic waves, magnetic fields or particles, optical fields or particles, and / or any combination thereof. “Communication,” “signal,” and / or “transmission” may be implemented using appropriate technology, including, for example, a transmitter, a receiver, and a transceiver. “Communication,” “signal,” and / or “transmission” as used herein will use technology appropriate for the intended purpose. For example, hardwired communication (e.g., wired serial communication) will use technology appropriate for hardwired communication, short-range communication (e.g., Bluetooth) will use technology appropriate for close-range communication, and long-range communication (e.g., GSM, CDMA, Wi-Fi, etc.) will use technology appropriate for long-distance remote communication. Appropriate security (e.g., SSL or TLS) for each type of communication is included herein. Security units 755 and 955 include technology for protecting messages. Security technology may be, for example, encryption / decryption technology (e.g., software or hardware). While encryption / decryption is primarily discussed as being performed using a unique, private key, alternative strategies include encryption / decryption performed using public / private keys (i.e., asymmetric encryption), or other encryption / decryption strategies, known or yet to be discovered. Unless specifically described, suitable input and / or output mechanisms are considered part of the technology described herein. Communication unit 770 of adapter module 100 (shown in FIG. 20 ) is shown to include suitable input mechanisms 772 and output mechanisms 774 that may be implemented in conjunction with (e.g., functionally communicatively direct or indirect) male adapter 720 and female adapter 730 of adapter module 100. Communication unit 870 of mobile device 150 (shown in FIG. 21 ) includes mechanisms for both long-range communication (shown as long-range communication capability 872, such as cellular and / or Wi-Fi mechanism) for communicating with server 130 and short-range communication (shown as short-range communication capability 876, such as Bluetooth mechanism) for communicating with adapter module 100.

[0033]

[0073] When used in connection with "communications," "signals," and / or "transmissions," the terms "provide" or "providing" (and variations thereof) are meant to encompass the standard meaning of providing, including "transmit" and "transmitting," but may also be used for non-traditional providing, to the extent that "communications," "signals," and / or "transmissions" are "received" (which may also mean obtained). The terms "transmit" and "transmitting" (and variations thereof) are meant to encompass the standard meaning of transmission, but may also be used for non-traditional transmission, to the extent that "communications," "signals," and / or "transmissions" are "sent." The terms "receive" and "receiving" (and variations thereof) are meant to encompass the standard meaning of receiving, but may also be used for non-traditional ways of obtaining, to the extent that "communications," "signals," and / or "transmissions" are "obtained."

[0034]

[0074] The term "associated" is defined to mean integral with or original to, modified, attached to, connected (including operatively connected to), located near, and / or accessible. For example, when a user interface (e.g., a conventional display 122 ( FIG. 19 ), a touchscreen display 124 ( FIG. 19 ), a keypad 126 ( FIG. 19 ), buttons 126 ( FIG. 19 , shown as part of keypad 126), a keyboard (not shown), and / or other input or output mechanism) is associated with payment accepting unit 120, the user interface may be native to, incorporated into, attached to, and / or near payment accepting unit 120. Similarly, the adapter module 100 may be associated with the payment accepting unit 120 in that the adapter module 100 may be native to the payment accepting unit 120, incorporated into the payment accepting unit 120, attached to the payment accepting unit 120, and / or be in proximity to the payment accepting unit 120.

[0035] System Overview

[0075] Figures 5, 6 and 7 collectively show the main components of a mobile device-machine payment system and the interactions between them.

[0036]

[0076] As shown, the adapter module 100 is functionally bidirectionally connected to the payment acceptance unit 120 via a wired serial connection, so that security is not required. The adapter module 100 is also functionally bidirectionally connected to the mobile device 150 (and the mobile application 140 installed thereon) via a short-range communication technology (e.g., a Bluetooth connection). Because the mobile device 150 is not a "trusted" link (e.g., it can be hacked by a user), only protected communications (transmissions) are passed between the adapter module 100 and the mobile device 150. This keeps communications secure and safe from hacking. The mobile device 150 (and the mobile application 140 installed thereon) is also functionally bidirectionally connected to the system administration server 130 and / or the funding source server 160 via a long-range communication technology (e.g., a Wi-Fi or cellular connection), preferably with appropriate security (e.g., SSL security). Security between the mobile device 150 and the system administration server 130 has the advantage of protecting communications from the mobile device 150 to the system administration server 130, which may contain sensitive data and may not be encrypted. The system administration server 130 and the funding source server 160 may be connected via a wired internet connection with SSL security. The system administration server 130 may be connected to the operator's server 170 via a wired internet connection with SSL security. Although not required to conduct purchase transactions, for other purposes (e.g., inventory checks), the operator's server 170 may be connected to the payment acceptance unit 120 using a handheld computer sync or cellular connection.

[0037]

[0077] The unique private key may also be used to securely transmit encrypted messages between the adapter module 100 and the system management server 130 (although the encrypted transmission will most likely be routed through the mobile device 150). The server 130 stores the private key for each adapter module 100, and this key is known only to the adapter module 100 and the server 130. No intermediaries (particularly the mobile device 150) are aware of this key. When the adapter module 100 and the server 130 communicate messages (e.g., AuthRequest and AuthGrant), the security unit 755 of the adapter module 100 encrypts the message using its private key and passes the message to the mobile device 150. The mobile device 150 (which preferably cannot decrypt the message) passes the encrypted message to the server 130. The server 130 can decrypt the message using the security unit 955 of the adapter module 100 and the unique private key. The security unit 955 of the server 130 uses this same unique private key to encrypt a message to the adapter module 100 and transmits the message to the mobile device 150, which relays it to the adapter module 100, which can decrypt the message using the security unit 755 of the adapter module 100 and the unique private key.

[0038]

[0078] 7 illustrates certain communications and messaging with a sequential order (numbers to the left of the communications and messaging) between adapter module 100, mobile device 150, and system management server 130. These communications are discussed in more detail in the discussion of the schematic flow diagrams (FIGS. 8A-8G) and flowcharts (FIGS. 9A-9E).

[0039]

[0079] It should be noted that Figures 5, 6, and 7 are examples and are intended to facilitate understanding of the mobile device-machine payment system. For example, the long-range communication technologies shown may be replaced with alternative long-range communication technologies, known or undiscovered, the short-range communication technologies shown may be replaced with alternative short-range communication technologies, known or undiscovered, and the security shown may be replaced with alternative security, known or undiscovered. The connections shown are intended to be examples, and there may be intermediaries not shown. The components shown are simplified in that, for example, only one mobile device 150 (or machine 120, adapter module 100, or server 130) is shown when many may be included. Finally, the order of steps may be changed, and some steps may be omitted.

[0040] Adapter Module

[0080] 11-18 show diagrams of adapter module 100a (commonly referred to as adapter module 100). Adapter module 100 is a relatively low-cost hardware component that is pre-configured to work with the industry-standard multi-drop bus (MDB). In machines that do not use MDB technology, adapter module 100 may be configured or designed to work with other serial protocols or activate switches. Essentially, adapter module 100 simulates the establishment of a payment at payment acceptance unit 120 in much the same way as other alternative forms of payment (e.g., cash).

[0041]

[0081] The illustrated adapter module 100 is preferably designed for use as an inline dongle, inserted in-line into, for example, the MDB of the machine 120. The wires used in MDB technology allow for the attachment of peripherals using male and female connection ends or adapters. In the case of vending machines, there will be wires with connection ends or adapters to allow for the attachment of a payment acceptance mechanism (e.g., a coin mechanism). The MDB male adapter 700 and the MDB female adapter 710 may be separate (as shown in FIGS. 17 and 18). The adapter module 100a in FIGS. 11, 17, and 18 has a male adapter 720 and a female adapter 730. The adapter module 100a may be plugged (inserted) in series (“in-line”) with the wires. For example, the MDB female adapter 710 may be connected to the male adapter 720 of the adapter module 100, and the MDB male adapter 700 may be connected to the female adapter 730 of the adapter module 100. The resulting in-line configuration is shown in FIG. 19. It should be noted that the adapter module 100 is designed to allow pass-through communication so that if the mobile device-machine payment processing system is not enabled (e.g., for a particular purchase or simply turned off), the MDB functions as if the adapter module 100 were not there and the machine 120 can function normally.

[0042] Hands-free mode

[0082] Briefly, if a hands-free mode is available, from the user's perspective, the hands-free mode allows the user to approach a favorite payment accepting unit 120 and notice that a display associated with the payment accepting unit 120 (e.g., display 122 or 124 shown in FIG. 19) shows available funds (e.g., wallet balance). The user would select a product or service using an input mechanism associated with the payment accepting unit 120 (e.g., button 126 or touchscreen display 124 shown in FIG. 19) and retrieve the provided service or product.

[0043]

[0083] During the initial handshake with the mobile device 150 (when the user is within range), the adapter module 100 reports to the mobile device 150 whether hands-free mode is available. If so, the installed mobile application 140 automatically connects to the payment acceptance unit 120 without the user having to interact with the mobile device 150. The user sees funds available on the display 122, 124 of the payment acceptance unit 120 and completes the purchase transaction by entering a selection into the payment acceptance unit 120, just as if cash had been deposited into the machine 120. The payment acceptance unit 120 delivers the product or service. After the selection is made, change is returned to the mobile device 150.

[0044]

[0084] Whether hands-free payment is available is determined by factors including whether other mobile devices 150 are within range, whether other adapter modules 100 are within range, whether there are any alerts, whether the payment trigger threshold appears unstable with a wide variance, or whether the operator of the payment accepting unit (e.g., a vending machine operator) has chosen to disable hands-free mode for the payment accepting unit 120. In the latter case, the operator can disable it via the maintenance mobile device 150, as well as via the operator's server 170 and / or the system administration server 130.

[0045]

[0085] FIG. 3 is a table illustrating considerations, conditions, or factors that may be used to determine whether the hands-free payment feature is available. Starting with the “Favorite?” column, this indicates whether the payment accepting unit 120 is a favorite machine. Preferably, the hands-free payment feature is only available for use with “favorite” payment accepting units 120 (e.g., vending machines at work or school). The “Alert” column relates to whether there is any reason why the hands-free payment feature should not work (e.g., too many users in range); if so, the user may be notified (warned) and be able to use a manual mode to resolve the alert and / or complete the transaction. FIG. 3 illustrates situations in which it is and is not possible to make a hands-free purchase from the machine 120 using the mobile application 140 on the user's mobile device 150. Note that the interface shown is an example. For example, some of the features may be automated or pre-selected. (Note that the left column, the "Tab" column, relates to whether the tab selected on the mobile application 140 is "All" or "Favorites." Figures 10A through 10D all show these tabs. Unlike the other columns in Figure 3, this column relates more to the functionality and views of the application 140 than to the hands-free functionality in particular. The tabs allow the user to select whether they want to be alerted when they are within range of all payment accepting units 120 or only their "favorite" payment accepting units 120, and the application 140 will show the appropriate view.)

[0046]

[0086] Balance Display: An optional feature of the mobile device-machine payment system that is particularly useful in hands-free mode (but may be available in manual mode and / or multiple vending scenarios) is that when a user's mobile device 150 sends "credit" to the payment accepting unit 120 (either via a hands-free payment or a manual swipe), the wallet balance is transmitted to the payment accepting unit 120 and then displayed to the user on the display 122, 124 of the machine 120. This is particularly beneficial in hands-free mode when the user does not remove the mobile device 150 and therefore may not know the balance. Also, in multiple vending scenarios, the user does not need to calculate the balance.

[0047]

[0087] An example of a hands-free multi-vending scenario in which the balance is displayed by the payment accepting unit 120 is as follows: The user has $5.00 in their virtual wallet, which is the authorized amount (the AuthGrant is stored on the mobile device 150). The user walks up to the payment accepting unit 120, hands-free mode is enabled, and $5.00 is displayed on the display 122, 124 of the payment accepting unit 120 because credit has been sent to the payment accepting unit 120 (e.g., via short-range communications). The user selects $1.50 by interacting with the machine 120 (e.g., pressing a button). The item (product or service) is delivered, and the “change” is “returned” to the virtual wallet (e.g., via short-range communications). However, because the user is still standing within the payment zone 102, the remaining wallet balance of $3.50 is sent to the payment accepting unit 120 and displayed so that the user can see that they now have a balance of $3.50. (Note that authorized funds may remain in the machine 120 and not be transferred back to the mobile device 150 between transactions.) The user decides to purchase an item for $1.50 and completes the transaction normally (e.g., by interacting with the machine 120). At this point, the user is still standing in the payment zone 102 and sees a wallet balance of $2.00 on the displays 122, 124 of the payment acceptance unit 120. The user decides they do not want to purchase anything else and simply walks away. When the user leaves the payment zone 102, the credit is cleared from the machine 120, but the user leaves knowing that their wallet balance is $2.00, even though they never touched the mobile device 150. Communication between the payment acceptance unit 120 and the adapter module 100 (via the mobile device 150) handles the accounting associated with the transaction. The balance ($2.00) is technically stored on the server 130 and may be reflected in the application 140 of the mobile device 150.

[0048] Multiple separate zones

[0088] As shown in FIGS. 1 and 2 , the functions performed by the adapter module 100 may be divided into distinct zones: a first “communication zone” (e.g., “Bluetooth range” 106), a second “authorization zone” 104, and a third “payment zone” 102. The payment zone 102 may be smaller than or equal to (completely overlap) the authorization zone 104. In other words, the payment zone 102 is within or coextensive with the authorization zone 104. The payment zone 102 is a subset of the authorization zone 104, with the ratio of the payment zone 102 to the authorization zone 104 ranging from 0.01:1 to 1:1. This ratio is not necessarily constant and may vary between different payment accepting units 120, different mobile devices 150, different users, and over time. Although the zones 102, 104, 106 are shown as having uniform shapes, the zones may not necessarily be uniform (or constant over time) in that the shapes may change. For example, the shape of the Bluetooth range 106 may change depending on environmental conditions such as obstacles in a room and the door / wall material of the payment accepting unit 120.

[0049]

[0089] Bluetooth Range 106 (sometimes referred to herein as a "communication zone"): The outermost range is Bluetooth range 106 (shown in FIGS. 1 and 2). This is the area in which adapter module 100 can broadcast its presence. In many cases, Bluetooth range 106 is a passive range in that no actual data is exchanged between mobile device 150 and adapter module 100. While within Bluetooth range 106, mobile device 150 monitors RSSI (Received Signal Strength Indicator).

[0050]

[0090] Authorized Zone 104: The intermediate region is the authorized zone 104 (shown in FIGS. 1 and 2). This is an area calculated based on RSSI. As already mentioned, the mobile device 150 monitors the RSSI while within Bluetooth range 106. If the RSSI reaches a certain predetermined threshold based on the in-range heuristic, the mobile device 150 may be considered to be within the authorized zone 104. In the authorized zone 104, the mobile device 150 establishes a connection to the adapter module 100 (e.g., a Bluetooth connection (FIG. 5) with SSL protection (FIG. 6)) and makes its presence known to the adapter module 100. After a successful handshake with the adapter module 100, the mobile device 150 registers the adapter module 100, and the adapter module 100 requests authorization from the server 130 via the mobile device's network connection (e.g., a Wi-Fi or cellular connection (FIG. 5) with SSL protection (FIG. 6)). It is important to note that the mobile device 150 and the adapter module 100 have a non-exclusive relationship at this point. The adapter module 100 may collect registrations of all mobile devices 150 within the authorized zone 104 .

[0051]

[0091] Authorization occurs in preparation for when the user enters the payment zone 102 (shown in FIGS. 1 and 2). Authorization expires after a set period of time (e.g., five minutes), so if the mobile device 150 is still within the authorization zone 104 when it expires, the adapter module 100 will request and receive another authorization. This will continue for a set number of times (e.g., the limit may be three, limiting instances where a mobile device is authorized multiple times, potentially remaining in the authorization zone 104 for an extended period of time without completing a transaction). If the user fails authorization before entering the payment zone 102 (e.g., the limit is reached), the adapter module 100 will request authorization when the mobile device 150 enters the payment zone 102 (adding a few seconds to the experience).

[0052]

[0092] Payment Zone 102: When a user enters the payment zone 102, the mobile device 150 establishes exclusive control of the adapter module 100. Once established, any other users within the payment zone 102 are placed in a "waiting" status.

[0053]

[0093] In the payment zone 102, the payment processing system has a hands-free mode, and when in the hands-free mode, payment can be automatically triggered. In such a case, the mobile device 150 runs the application 140 in background mode and will send credit to the payment acceptance unit 120 without any explicit user interaction. To establish credit, the user completes a transaction at the payment acceptance unit 120 much as if cash had been inserted into the payment acceptance unit 120. After the user completes the transaction (which may include one or more purchases), transaction details are preferably returned to the mobile device 150 and the server 130 in a separate message. The message to the server 130 is preferably encrypted using the adapter module 100's private key (FIG. 6) to ensure data integrity. As shown in FIG. 7, the "private key"-encoded message (encrypted vending details) is preferably sent via the mobile device 150. The message to the mobile device 150 may be sent only to complete the transaction. Transaction history and balances are updated on the server side via encrypted messages sent to the server 130 .

[0054]

[0094] Another mode of operation is manual mode. In manual mode, a user can turn on the mobile device 150 and swipe to send a payment to the payment accepting unit 120. The user can also swipe backwards to cancel the payment. As in hands-free mode, the purchase transaction is completed at the payment accepting unit 120 just as if cash had been inserted into the payment accepting unit 120. The mobile device 150 is only used to send the payment. Selections are made directly at the payment accepting unit 120.

[0055]

[0095] Self-calibrating zone threshold: A key but optional feature of the payment processing system is a self-calibrating payment zone RSSI threshold. Because RSSI can vary from machine to machine, environment to environment, and device to device, having a fixed threshold at which a payment is triggered can be problematic. The approach suggested herein is the generation of a self-calibrating threshold. When a user is interacting with the payment accepting unit 120 (such as when the user makes a selection at the payment accepting unit 120), the payment accepting unit 120 notifies the adapter module 100, which records the situation, such as the RSSI, the type of user mobile device 150, accelerometer data, and other information. It is at this point that it can be safely confirmed that the user is within arm's length of the payment accepting unit 120 (the user is necessarily at arm's length because the user is having some physical interaction with the payment accepting unit 120). This is the only point in the entire transaction where it can be certain that the user is within arm's length of the payment accepting unit 120.

[0056]

[0096] FIG. 4 illustrates a simplified sequence of steps involved when a user enters the payment zone 102. In particular, FIG. 4 illustrates that credit is established (200) (which may occur in the authorization zone 104, but is otherwise processed in the payment zone 102), the user makes a selection using a machine (202), the machine notifies the adapter module of the selection (204), the adapter module (optionally) records the RSSI (206), and the purchase process continues (208). Using the previously recorded RSSI data, the adapter module 100 calculates one of several “average” RSSIs using various mathematical models. This “average” could be a traditional average, a moving average, a weighted average, a median, or other similar aggregation function. The adapter module 100 may pre-process the historical data before performing the function, such as removing top and bottom data points, suspicious data points, etc.

[0057]

[0097] Optionally, during a handshake between mobile device 150 and adapter module 100, information transmitted to adapter module 100 may include, for example, the model of mobile device 150. Using the received information regarding the model of the mobile device, adapter module 100 can generate multiple payment thresholds, one for each mobile device model. This allows for variations that may be inherent in different types of Bluetooth radios. An alternative to this method is for adapter module 100 to broadcast a baseline payment zone threshold, and mobile device 150 can use an offset from this baseline based on its particular model type. The payment zone threshold (or baseline offset) can be specific to a particular type of mobile device (e.g., by manufacturer, operating system, or component parts), a model of a mobile device, or an individual mobile device (unique to each user).

[0058]

[0098] In a typical scenario where the payment zone thresholds have been calibrated, the adapter module 100 advertises its presence along with the thresholds at which any mobile device 150 will consider itself within the authorized zone 104. This is a one-way communication from the adapter module 100 to the mobile device 150. When the mobile device 150 enters the authorized zone 104, there is a handshake established between the adapter module 100 and the mobile device 150. During this handshake, the mobile device 150 can share its model information with the adapter module 100, and the adapter module 100 can return the payment zone 102 thresholds for that particular model.

[0059]

[0099] Optionally, in addition to calibrating the payment zone thresholds, the adapter module 100 can apply a self-calibration model to the authorization zone 104 to calibrate the authorization zone thresholds. Like the payment zone thresholds, the authorization zone thresholds can be specific to a particular type of mobile device, a model of mobile device, or an individual mobile device. In this scenario, the adapter module 100 broadcasts multiple thresholds by device type, and the mobile device 150 will decide which threshold to apply (or alternatively broadcast a baseline, and the mobile device 150 will use an offset based on its device model). Again, the authorization zone 104 is a unidirectional communication.

[0060]

[0100] Optionally, a safety margin can be added along with the calculated threshold (in the payment zone and / or authorization zone) to minimize scenarios where the mobile device-machine payment processing system does not recognize a user who is in range but has missed the threshold. For example, if the RSSI calculated for an iPhone® 5 at machine 4567 is −68 db, the mobile device-machine payment processing system may add a safety margin of −5 db and establish the threshold at −73 db. Thus, if the user's phone communicates with the adapter module 100 with an RSSI of −73 db or greater, the mobile device-machine payment processing system will allow the mobile device 150 to trust the payment accepting unit 120. The safety margin can be configured on the server 130 and downloaded to the adapter module 100, or configured on the mobile device 150, or configured on the adapter module 100 itself.

[0061]

[0101] Optionally, at the payment zone threshold, the mobile device 150 may use other data to determine when to cancel exclusive control of the payment accepting unit 120 and to identify when the user is moving out of the payment zone 102. The external data may include accelerometer data from the mobile device 150. Using that data, the mobile device 150 may determine whether the user is standing relatively still in front of the payment accepting unit 120 or, if the user is moving, is actually moving away from the payment accepting unit 120.

[0062] Adapting to signal unavailability

[0102] The mobile device-machine payment processing system described herein uses a short-range communication technology (e.g., Bluetooth mechanism) of the mobile device 150 (shown in FIG. 21 as short-range communication function 876) and a long-range communication technology (e.g., cellular and / or Wi-Fi mechanism) of the mobile device 150 (shown in FIG. 21 as long-range communication function 872). The short-range communication function 876 communicates with the short-range communication technology (e.g., Bluetooth mechanism) of the adapter module 100 (shown in FIG. 20 as short-range communication function 776). The long-range communication function 872 communicates with the long-range communication technology (e.g., cellular and / or Wi-Fi mechanism) of the server 130 (shown in FIG. 22 as long-range communication function 972). The mobile device 150 (with the mobile application 140) acts as a communication bridge between the adapter module 100 (associated with the payment accepting unit 120) and the server 130. This process is described herein and works well when there is cellular or Wi-Fi coverage within the payment zone 102.

[0063]

[0103] If there is no cellular or Wi-Fi coverage within the payment zone 102, one option is to determine whether there is cellular or Wi-Fi coverage within the authorized zone 104 or Bluetooth range 106. If so, the size of the zones 102, 104, 106 can be adapted, and the timing can be adapted. For example, if the mobile device 150 detects a problem with cellular or Wi-Fi coverage within the payment zone 102, the user can drive the mobile device 150 into other zones (or the mobile device 150 can communicate with other mobile devices 150 within the authorized zone 104 or Bluetooth range 106 using short-range communication techniques) and determine whether those zones have cellular or Wi-Fi coverage. If those zones have coverage, communication between the mobile device 150 and the server 130 can be advanced (occurring earlier if the mobile device 150 is further away from the machine 120) or delayed (occurring later if the mobile device 150 is further away from the machine 120). This could be thought of as a change in the size or shape of zones 102, 104, 106. Timing would also need to be adjusted so that the authorization for funds (AuthGrant) does not expire before the user has an opportunity to make a purchase. This also means that a balance update to server 130 could occur after the user has traveled away from machine 120 and once again has cellular or Wi-Fi coverage.

[0064]

[0104] If there is no cellular or Wi-Fi coverage within any of the zones 102, 104, 106, another option is for the user to obtain authorization in a location with cellular or Wi-Fi coverage while outside the zone. This might be done, for example, if the user knows they will be going to a location (perhaps a favorite payment accepting unit 120) where there is a payment accepting unit 120 equipped with an adapter module 100 that does not (or rarely) have cellular or Wi-Fi coverage. The user might use the mobile application 140 to query payment accepting units 120 within a given range (e.g., within 50 miles) or at a given location (e.g., at a campground or in a particular remote city) to determine whether there is cellular or Wi-Fi coverage within the zone 102, 104, 106. The user can then obtain pre-authorization from the server 130 using the mobile application 140. Again, timing must also be coordinated so that the authorization of funds (AuthGrant) does not expire before the user has an opportunity to make a purchase. This also means that a balance update on server 130 can occur after the user travels away from machine 120 and again has cellular or Wi-Fi coverage. A mobile device-machine payment system with the ability to implement this option will be able to accept cashless payments without requiring any network connection in the vicinity of payment acceptance unit 120. In some implementations, the mobile device-machine payment processing systems described herein are located in remote locations where no signal is available and therefore can accept cashless payments.

[0065]

[0105] As an example of a situation in which there may be no cellular or Wi-Fi coverage within any zone 102, 104, 106 of a particular payment accepting unit 120, a user (teenager) may travel to a remote location without cellular or Wi-Fi coverage to attend summer camp. The camp may have several payment accepting units 120 (e.g., machines that generate dedicated "hot spots" that require a usage fee, vending machines, or machines for renting equipment such as bicycles, kayaks, or basketballs). The camp facility may notify parents that a mobile device-to-machine payment system is available. While at home, the parent can obtain authorization for a specific amount to be authorized (which may be a fixed amount per day or limited to a machine type or location), "load" it onto the user's mobile device 150, and specify that the authorization does not expire for a certain period of time or until a specific date. Then, while at camp, the user can use the mobile application 140 on the mobile device 150 in a similar manner as discussed elsewhere herein. Short-range communication may be used for communication between the adapter module 100 (associated with the machine 120) and the user's mobile device 150.

[0066]

[0106] One unobtrusive yet powerful component of the payment processing system described herein requires long-range communication capabilities (e.g., Internet or cellular network connectivity) only in the authorized zone 104 and only for the period needed to send an AuthRequest and receive an AuthGrant. Once a valid AuthGrant is received by the mobile device 150, long-range communication capabilities (e.g., Internet or cellular network connectivity) are not required for either the mobile device 150 or the adapter module 100 within the payment zone 102 as long as the AuthGrant is valid (unexpired). This mechanism allows the system to seamlessly process genuine transactions in (temporarily) offline mode, with pending authorization and transaction messages performing bookkeeping and cleanup when network connectivity is regained. The above alternatives provide a unique way to artificially expand the authorized zone to include any location where the mobile device 150 can communicate with the server 130.

[0067] Multi-user resolution

[0107] 2, in one practical scenario, multiple users are present in zones 102, 104, and 106. As shown in FIG. 2, users 1, 2, and 3 are in payment zone 102 near machine 120, users 5 and 6 are shown to be located between authorization zone 104 and Bluetooth range 106, users 4 and 7 are within Bluetooth range 106, user 10 is located at the edge of Bluetooth range 106, and users 8 and 9 are located outside Bluetooth range 106. In some implementations, the mobile device-machine payment processing system manages and resolves issues related to multiple users.

[0068]

[0108] Users 4 and 7 are within Bluetooth range 106, and user 10 is either entering or leaving Bluetooth range 106. Within Bluetooth range 106, the user's mobile device 150 can see the advertisement for adapter module 100. In this zone, mobile device 150 preferably does not initiate a connection. Adapter module 100 is preferably unaware of users within Bluetooth range 106. All adapter module 100 does is advertise its presence to any users that may be within Bluetooth range 106.

[0069]

[0109] The adapter module 100 begins recording users (shown as users 5 and 6 in FIG. 2 ) (and their respective mobile devices 150) when they enter the authorized zone 104. At this point, there is a non-exclusive connection to the adapter module 100 initiated by the mobile device 150. After a handshake (e.g., to exchange information needed to obtain authorization and, optionally, to record information needed for self-calibration of the authorized zone thresholds), the mobile device 150 contacts the server 130 for authorization (e.g., sending an AuthRequest and receiving an AuthGrant). The adapter module 100 registers all mobile devices 150 that have requested and received an AuthGrant. The adapter module 100 also continues to communicate with any other mobile devices 150 that enter the authorized zone 104. After the initial contact, the adapter module 100 may provide a grace delay for the mobile device 150 as to when to check back in with the adapter module 100, allowing other mobile devices 150 an opportunity to communicate with the adapter module 100.

[0070]

[0110] A purchase transaction may be performed if there is only one user in the payment zone 102. If there are multiple users in the payment zone 102, the mobile device-machine payment system must handle this situation.

[0071]

[0111] One optional solution for dealing with situations where there are multiple users in the payment zone 102 is to queue users within the payment zone 102. When any mobile device 150 enters the payment zone 102, the adapter module 100 establishes exclusivity for the particular mobile device 150 (e.g., first-come, first-served). However, technically, the adapter module 100 does not establish an exclusive connection to the mobile device 150. The adapter module 100 can still perform round-robin polling and communicate with and advertise to other mobile devices 150. Instead, the adapter module 100 establishes a queue prioritized by RSSI and time (e.g., who is first and whether the authorization has expired) and notifies (e.g., alerts) the other mobile devices 150 to wait. If RSSI is relevant, the earliest valid (unexpired) authorization takes precedence. Otherwise, for example, the strongest average RSSI takes precedence. Preferably, the queue is not a static measure of RSSI, but an average measure over a period of time within the queue. This complements the scenario where a user may be walking around in a queue and appear at the payment acceptance unit 120 just as the previous user is finishing. If another user is also in the payment zone 102 and has been standing there all this time, but has a newer authorization, that user may take priority.

[0072]

[0112] The adapter module 100 will disable hands-free payment whenever the adapter module 100 cannot accurately determine which user is in front of the payment acceptance unit 120 in the payment zone 102. The mobile device 150 will send an alert to the user, who can then use swipe-to-pay (manual mode). All users in the payment zone 102 will show "connected," and the first user to swipe-pay against the payment acceptance unit 120 will then lock out other users.

[0073] Multiple Module Resolution

[0113] In a scenario where multiple modules are present, it can be difficult to determine which payment accepting unit 120 the user is in front of. In some implementations, the mobile device-machine payment processing system described herein enables the adapter module 100 to communicate with other adapter modules 100 within range via Bluetooth. Each user receives an authorization acceptance for a specific payment accepting unit 120. This means that if there are multiple adapter modules 100 in the same authorization zone 104, the user will have multiple authorization acceptances. When a user enters a payment zone 102, if the payment zones 102 overlap, it can be difficult to identify which payment accepting unit 120 the user is in front of.

[0074]

[0114] To solve this problem, when a user enters a payment zone 102, the adapter modules 100 communicate with each other to identify the RSSI of a particular user (based on signals from the user's mobile device 150) and triangulate which adapter module 100 (and associated payment accepting unit 120) is closer to the user. Optionally, inter-module communication can limit a user to establishing an exclusive connection to only one payment accepting unit 120.

[0075]

[0115] Optionally, when a user connects to a payment accepting unit 120, the mobile device 150 may send a message to the payment accepting unit 120 to be temporarily displayed to the user on the display 122, 124 of the payment accepting unit 120. For example, when the user is within the payment zone 102, the mobile device 150 may send a message (e.g., "Connecting" or "Fred's mobile device is connecting") to the display 122, 124 of the payment accepting unit for a predetermined period of time (e.g., 1-3 seconds) so that it is clear which payment accepting unit 120 the user is connected to before making a purchase (in hands-free mode or manual mode).

[0076]

[0116] Additionally, when the user is in manual mode, the mobile device 150 may display a visual representation of the payment accepting unit 120 (e.g., a photo of the payment accepting unit 120 and / or a payment accepting unit ID) for viewing (e.g., on the touch screen 152 as shown in Figures 10A-10D). When the user is in manual mode, the user may manually change the payment accepting unit 120.

[0077] Illustrative scenario

[0117] Figures 7, 8A-8G, and 9A-9E (as well as other figures) can be used to understand detailed scenarios of the mobile device-machine payment processing system described herein. The flow of communications and steps is generally described below with reference to these (and other figures). Note that alternative scenarios may involve, for example, a change in the order of steps being performed.

[0078]

[0118] Prior to a vending transaction, a user downloads the mobile application 140 to the mobile device 150, creates an account, and configures a funding source, for example, via the funding source server 160. The funding source may be, for example, a debit card, a credit card, a campus card, reward points, a bank account, a payment service (e.g., PayPal®), or any other payment option or combination of known or yet to be discovered payment options. The funding source may be a traditional and / or non-traditional payment source integrated into the ecosystem described herein and may be used indirectly as a funding source. Funds from the funding source are preferably held at the server 130 so that when an AuthRequest is received by the server 130, the server 130 can send an AuthGrant authorizing funds for the purchase.

[0079]

[0119] A user can designate one or more "favorite" adapter modules 100 (which have a one-to-one relationship to a payment acceptance unit 120) that they may visit regularly, such as vending machines at school or work. Favorite adapter modules 100 appear in a pre-filtered list and enable additional rich functionality, such as hands-free payment.

[0080]

[0120] The payment accepting unit 120 may include an adapter module 100 that is constantly advertising its availability via Bluetooth (or other "signal," "communication," and / or "transmission"). This ongoing advertising and scanning for adapter modules is illustrated in FIG. 8A. As shown, the mobile device 150 is continuously scanning for any adapter modules 100 within Bluetooth (or other "signal," "communication," and / or "transmission") range. When the user is within range of an adapter module 100, the mobile device 150 tracks and monitors the signal strength until a predetermined "authorization zone" threshold is achieved.

[0081]

[0121] 8B and 9A collectively illustrate a mobile device 150 entering an authorization zone (block 302) and registering an adapter module 100 when an authorization zone threshold is reached. The mobile device 150 connects to the server 130 (block 304). The application 140 on the mobile device 150 creates an authorization request (AuthRequest) and passes the AuthRequest to the server 130 using an appropriate communications technology (e.g., GSM, CDMA, Wi-Fi, etc.) (block 306). The server 130 responds with an authorization grant (AuthGrant) encrypted with the specific adapter module's private key (block 306). This authorization token may include at least a user identifier (ID), a device ID (for the adapter module 100), an authorization amount, and a validity period. The mobile device 150 receives the AuthGrant from the server 130 and retains it until the mobile device 150 is ready to make a payment to the adapter module 100. The mobile device 150 collects all pending AuthGrant(s), which may be one or more depending on how many adapter modules 100 are in range. Unused AuthGrant(s) that expire are purged from the mobile device 150 and the server 130. It is important to note that the mobile device 150 cannot read the AuthGrant(s) because they are encrypted with the adapter module's unique private key, known only to the server 130 and the adapter module 100. This provides a desirable key element of security in the system, as the adapter module 100 only trusts AuthGrant(s) that have been issued by the server 130, and the AuthGrant(s) cannot be read or altered by the mobile device 150 or any other entity between the server and the adapter module 100. Additional mobile devices 150 may enter the authorized zone 104 (block 308).

[0082]

[0122] When a user approaches a particular adapter module 100, they enter a payment zone 102 and an event threshold is triggered based on heuristics executed by the mobile device 150. Blocks 310 and 312 show a looping step that waits for a mobile device 150 from an authorized zone 104 to enter the payment zone 102. If the user exits the authorized zone 104 without entering the payment zone 102, the adapter module 100 returns to advertising its presence (block 300).

[0083]

[0123] 8C and 9B collectively depict a user entering a payment zone. The mobile device 150 verifies that it has a valid, unexpired AuthGrant. If the AuthGrant is not good, an AuthGrant may be requested again, and the authorization request process is repeated (block 315). If the AuthGrant is good, the mobile device 150 sends a valid AuthGrant (including the wallet balance) to the adapter module 100 (block 322) and initiates the transaction. The mobile device 150 may automatically issue an AuthGrant without specific user interaction if hands-free mode is supported (and the device is a favorite (block 318), there is only one device in the payment zone 102 (block 318), and (optionally) there is only one user in the authorization zone 104 (block 320). If any of these factors are not present, the mobile device 150 will prompt the user to manually initiate the transaction and / or wait for the user to manually initiate the transaction (block 324).

[0084]

[0124] 8D, 9C, and 9D collectively illustrate the transaction process. As shown in FIG. 9C, the adapter module 100 runs through a series of questions to determine whether there are any issues that would prevent vending, including whether the user canceled within the app (block 326), whether the user walked away (block 328), whether the coin return button was pressed (block 330), and whether more than a predetermined time has passed (block 332). If the answer to any of these questions is "yes," the transaction does not proceed. If the answer to all of these questions is "no," the user makes a selection on the payment acceptance unit 120 in the same or similar manner as if cash or credit were provided to the payment acceptance unit 120 (block 334). The machine 120 attempts to release the product if vending is possible (block 336). If vending is unsuccessful (block 338), the machine reports the failure (block 340), and the credit is returned to the virtual wallet (block 342). If the vending is successful (block 338), the machine reports success (block 344). In other words, after the transaction is completed, the adapter module 100 returns to the mobile device 150 the transaction details and an encrypted packet containing the vending details to be sent to the server 130 via the mobile device 150. Optionally, the adapter module 100 can pass additional information not directly related to the transaction, such as the health of the payment acceptance unit, vending data, error codes, etc.

[0085]

[0125] Figures 8D and 9E generally illustrate the multi-vending feature. If the machine's multi-vending feature is enabled (block 350) and the multi-vending limit has not been reached, the process returns to the inquiry as to whether the user is within the payment zone (block 310 of Figure 9A). If the machine's multi-vending feature is not enabled (block 350) or the multi-vending limit has been reached, the wallet is decremented by the vending amount, the "change" is returned to the virtual wallet (block 354), and the process ends (block 356).

[0086]

[0126] Figure 8E is a schematic flow diagram of an exemplary login process, Figure 8F is a schematic flow diagram of an exemplary boot-up process, and Figure 8G is a schematic flow diagram of an exemplary account check / update process.

[0087]

[0127] Some of the figures are flowcharts illustrating methods and systems (e.g., FIGS. 9A through 9E). It is understood that each block of these flowcharts, components of all or some of the blocks of these flowcharts, and / or combinations of blocks within these flowcharts can be implemented by software (e.g., coding, software, computer program instructions, software programs, subprograms, or other series of computer-executable or processor-executable instructions), by hardware (e.g., processor, memory), by firmware, and / or by combinations of these forms. In the case of software, as an example, computer program instructions (computer-readable program code) can be loaded into a computer to generate a machine, such that the instructions that execute on the computer provide a structure for performing the functions specified in one or more blocks of the flowcharts. These computer program instructions can also be stored in a memory and can instruct a computer to function in a particular manner, such that the instructions stored in the memory generate a product including an instruction structure that implements the functions specified in one or more blocks of the flowcharts. The computer program instructions can also be loaded into a computer to cause a series of operational steps to be performed by or by the computer, such that the computer-executable instructions provide steps for performing the functions specified in one or more blocks of the flowcharts, to generate a computer-implemented process. As such, the blocks of the flowcharts support combinations of steps, structures, and / or modules for performing the specified functions. It is also understood that each block of the flowcharts, and combinations of blocks within the flowcharts, may be separated and / or combined with other blocks of the flowcharts without affecting the scope of the invention. Thus, for example, the computer-readable program code may be stored entirely in one memory, or various components of the computer-readable program code may be stored in two or more memories.

[0088] Additional Examples

[0128] 23 shows a schematic flow diagram of a process 1000 for authenticating a user to perform a transaction in a payment processing system according to some embodiments. In some embodiments, the payment processing system includes one or more payment modules 100 (e.g., each associated with a respective payment accepting unit 120, such as an automated retail machine for providing goods and / or services), one or more mobile devices 150 (e.g., each executing an application 140 for the payment processing system as a foreground or background process), and a server 130. The server 130 manages the payment processing system and, in some cases, is associated with an entity that supplies, operates, and / or manufactures the one or more payment modules 100. For simplicity, the process 1000 will be described with respect to each payment module 100 and each mobile device 150 in the payment processing system.

[0089]

[0129] The payment module 100 broadcasts 1002 a packet of information (sometimes referred to herein as "promotional information") via short-range communication capabilities (e.g., BLE). The packet of information includes at least an authorization code and an identifier (module ID) associated with the payment module 100. In some embodiments, the packet of information further includes the firmware version of the payment module 100 and one or more status flags corresponding to one or more states of the payment module 100 and / or the payment accepting unit 120. Information included in the packet broadcast by the payment module 100 is described further below with reference to FIG. 24A.

[0090]

[0130] In some embodiments, the payment module 100 sends out a unique authorization code every X seconds (e.g., 100 ms, 200 ms, 500 ms, etc.). In some embodiments, the unique authorization code is a randomly or pseudo-randomly generated number. In some embodiments, the payment module 100 stores the broadcasted authorization code until the received authorization grant token matches one of its stored authorization codes. In some embodiments, the payment module 100 stores the broadcasted authorization code for a predetermined amount of time (e.g., Y minutes), after which the authorization code expires and is deleted. In some embodiments, the authorization code is encrypted with a shared secret key known to the server 130 but unique to the payment module 100. In some embodiments, the payment module 100 initializes a random number, and therefore the authorization code is a sequential count from this random number. In such embodiments, the payment module 100 stores the earliest valid (unexpired) counter without having to store every valid authorization code. In some embodiments, the authorization code included in the broadcast information packet is a randomly or pseudo-randomly generated number or a hash value of a sequence of numbers.

[0091]

[0131] The mobile device 150 receives the broadcasted information packet, and the mobile device 150 transmits 1004 an authorization request to the server 130 via a long-range communication capability (e.g., GSM, CDMA, Wi-Fi, etc.). For example, an application 140 associated with a payment processing system is running on the mobile device 150 as a foreground or background process. In this example, the application 140 receives the broadcasted information packet when the mobile device 150 is within the communication zone (i.e., BLE range) of the payment module 100, and either automatically transmits an authorization request to the server 130 when the mobile device 150 is within the authorization zone of the payment module 100, or transmits an authorization request to the server 130. In some embodiments, the broadcasted information packet includes a baseline authorization zone threshold (i.e., authorization zone criteria) that indicates the baseline RSSI that the mobile device 150 (or application 140) must observe before entering the authorization zone of the payment module 100. In some embodiments, mobile device 150 (or application 140) offsets the baseline authorization zone threshold based on the strength and / or reception of short-range communication capabilities (e.g., BLE radio / transceiver) of mobile device 150. In some embodiments, the authorization request includes at least the authorization code included in the broadcast information packet, an identifier (User ID) associated with the user of mobile device 150 or the user account through which the user of mobile device 150 logs into application 140, and an identifier (Module ID) associated with payment module 100. In some embodiments, the authorization code included in the authorization request is a hash value of plaintext. Authorization requests are described further below with reference to FIG. 24B.

[0092]

[0132] After receiving the authorization request, server 130 processes 1006 the authorization request. In some embodiments, server 130 decrypts the authorization code included in the authorization request with a shared secret key corresponding to payment module 100. In some embodiments, server 130 determines whether the user associated with the user ID in the authorization request has sufficient funds in the user's account in the payment processing system to perform the transaction at the machine 120 associated with the payment module 100 corresponding to the module ID in the authorization request.

[0093]

[0133] The server 130 transmits 1008 the authorization grant token to the mobile device 150 via a long-range communication capability (e.g., GSM, CDMA, Wi-Fi, etc.). In some embodiments, the server 130 does not transmit the authorization grant token if the authorization code in the authorization request cannot be decrypted with the shared secret key corresponding to the payment module 100 (e.g., the authorization code is corrupted or hacked). In some embodiments, the server 130 does not transmit the authorization grant token if the user associated with the user ID in the authorization request does not have sufficient funds in the account. In some embodiments, in addition to the authorization grant token, the server 130 transmits a message directly to the mobile device 150 that is not encrypted with the shared secret key corresponding to the payment module 100. After receiving the message, the mobile device 150 displays an appropriate message to the user, such as insufficient balance or authorization denied. In some embodiments, the server 130 sends an authorization acceptance token for an amount equal to zero, which the payment module 100 interprets as a denial or failure of authorization, which may occur for any number of reasons, including, but not limited to, insufficient balance or credit.

[0094]

[0134] The mobile device 150 receives the authorization acceptance token and subsequently detects the trigger condition 1010. In some implementations, the mobile device 150 (or the application 140) detects the trigger condition via a hands-free mode (e.g., upon entering a payment zone of the payment module 100) or a manual mode (e.g., by interacting with a user interface of the application 140 to initiate a transaction with a payment acceptance unit associated with the payment module 100).

[0095]

[0135] In some embodiments, unused authorization acceptances (e.g., because they did not have a trigger condition or because they have expired) are canceled by the mobile device 150 by sending a cancellation message corresponding to the unused authorization acceptance to the server 130. In some embodiments, the server 130 rejects or limits the number of authorization acceptances sent to the mobile device 150 until the server 130 receives transaction information or cancellation of any outstanding authorization acceptances.

[0096]

[0136] In response to detecting the trigger condition, mobile device 150 transmits 1012 an authorization acceptance token to payment module 100 via short-range communication capabilities (e.g., BLE). Machine 120 then displays the credit to the user (e.g., via one of displays 122 or 124 shown in FIG. 19), and the user interacts with an input mechanism of machine 120 (e.g., via buttons 126 or touchscreen display 124 shown in FIG. 19) to purchase products and / or services.

[0097]

[0137] 24A shows a block diagram of a packet 1100 of information broadcast by payment module 100 (e.g., in step 1002 of process 1000 in FIG. 23) according to some embodiments. In some embodiments, packet 1100 includes at least a module ID 1102 and an authorization code 1104. In some embodiments, packet 1100 further includes a firmware version 1106 and one or more status flags 1108.

[0098]

[0138] In some implementations, module ID 1102 is a unique identifier corresponding to the payment module 100 (sometimes referred to herein as the “adapter module 100 ”) broadcasting packet 1100 .

[0099]

[0139] In some embodiments, the authorization code 1104 is a hash value of plaintext. In some embodiments, the payment module 100 randomly or pseudo-randomly generates numbers or determines a sequence of numbers (see step 1002 of process 1000 in FIG. 23 ) and runs a predetermined hash function (e.g., SHA-256) on the numbers to generate a hash value as the authorization code 1104. In some embodiments, the authorization code 1104 is a unique code that is encrypted with a private encryption key corresponding to the payment module 100. The private encryption key is shared with the server 130 and allows the server 130 to decrypt the authorization code 1104 and encrypt the authorization grant token, but not the mobile device 150. In some embodiments, encryption between the server 130 and the payment module 100 is achieved by two public / private key pairs.

[0100]

[0140] In some embodiments, firmware version information 1106 identifies the current firmware version 1112 of payment module 100. In some embodiments, firmware version information 1106 also includes update status information 1114 that indicates one or more packets that payment module 100 receives to update the firmware, or that indicate one or more packets that payment module 100 needs to update the firmware. See Figures 26A and 26B and 30A-30D and accompanying text for further discussion regarding updating firmware for payment module 100.

[0101]

[0141] In some implementations, one or more status flags 1108 indicate the status of the payment module 100 and / or the payment accepting unit 120 associated with the payment module 100. In some implementations, the one or more status flags 1108 indicate the status of the payment module 100, such as an upload information indicator 1116 indicating that the payment module 100 has information to be uploaded to the server 130 (e.g., transaction information for one or more pending transactions). In some implementations, the upload information indicator 1116 immediately triggers a connection by the mobile device 150 to the payment module 100 (e.g., if it has pending transaction information to be uploaded to the server 130). See Figures 25A and 25B and 29 and accompanying text for further discussion regarding pending transactions. In some implementations, the one or more status flags 1108 indicate a status of the payment accepting unit 120, including one or more of an error indicator 1118 (e.g., indicating that the note and / or coin acceptor of the payment accepting unit 120 is experiencing a jam, error code, or malfunction), a currency level indicator 1120 (e.g., indicating that the reservoir level of the note and / or coin acceptor of the payment accepting unit 120 is full or empty), and / or an inventory level indicator 1122 (e.g., indicating one or more products of the payment accepting unit 120). In some implementations, the one or more status flags 1108 are error codes issued by the payment accepting unit 120 via the MDB.

[0102]

[0142] In some embodiments, the zone criteria information 1110 specifies authorization zone criteria 1124 (e.g., a baseline authorization zone threshold indicating a baseline RSSI that a mobile device 150 (or application 140) must observe before entering the authorization zone of the payment module 100) and / or payment zone criteria 1126 (e.g., a baseline payment zone threshold indicating a baseline RSSI that a mobile device 150 (or application 140) must observe before entering the payment zone of the payment module 100). In some embodiments, the baseline authorization zone threshold and the baseline payment zone threshold are default values ​​determined by the server 130 or stored as variables by the application 140, in which case the authorization zone criteria 1124 and the payment zone criteria 1126 are offsets that compensate for the strength and / or reception of the short-range communication capabilities (e.g., BLE radio / transceiver) of the payment module 100. Alternatively, the zone criteria information 1110 includes a spread between the baseline authorization zone threshold and the baseline payment zone threshold. Thus, mobile device 150 (or application 140) determines the baseline authorization zone threshold and the baseline pay zone threshold based on the spread value and a default value for either the baseline authorization zone threshold or the baseline pay zone threshold. For example, the spread may indicate -10 db, the default baseline pay zone threshold is -90 db, and therefore the baseline authorization zone threshold is -80 db. Continuing with this example, after determining the baseline authorization zone threshold and the baseline pay zone threshold, mobile device 150 (or application 140) may further adjust the authorization zone threshold and / or the pay zone threshold based on the strength and / or reception of its short-range communication capabilities (i.e., BLE radio / transceiver).

[0103]

[0143] 24B is a block diagram of an authorization request 1130 sent by mobile device 150 to server 130 (e.g., in step 1004 of process 1000 in FIG. 23) according to some embodiments. In some embodiments, authorization request 1130 includes at least module ID 1102, user ID 1134, and authorization code 1104.

[0104]

[0144] In some implementations, the module ID 1102 is a unique identifier corresponding to the payment module 100 that broadcast 1100 containing the authorization code 1104 .

[0105]

[0145] In some implementations, user ID 1134 is an identifier associated with the user of mobile device 150 sending authorization request 1130 to server 130. In some implementations, user ID 1134 is associated with the user account with which the user of mobile device 150 logged into application 140.

[0106]

[0146] In some implementations, the authorization code 1130 comprises the authorization code 1104 included in the packet of information 1100 broadcast by the payment module 100 .

[0107]

[0147] 24C is a block diagram of an authorization grant token 1140 sent by server 130 to mobile device 150 (e.g., in step 1008 of process 1000 in FIG. 23 ) according to some embodiments. In some embodiments, server 130 generates authorization grant token 1140 pursuant to a determination that the authorization code 1136 included in authorization request 1130 from mobile device 150 is valid and that the user associated with mobile device 150 has sufficient funds in its account at the payment processing system. In some embodiments, authorization grant token 1140 includes at least module ID 1102, user ID 1134, authorization amount 1146, (optionally) expiration offset 1148, and (optionally) authorization code 1104.

[0108]

[0148] In some implementations, the module ID 1102 is a unique identifier corresponding to the payment module 100 that broadcast the packet 1100 containing the authorization code 1104 .

[0109]

[0149] In some implementations, user ID 1134 is an identifier associated with the user of mobile device 150 that sent authorization request 1130 to server 130 .

[0110]

[0150] In some implementations, the authorization amount 1146 indicates the maximum amount authorized for a transaction in which the user of the mobile device 150 uses the authorization acceptance token 1140. For example, the authorization amount 1146 is predefined by the user of the mobile device 150 or by the server 130 based on a daily limit, based on the user's total account balance, or based on the risk profile of the user corresponding to the user ID 1134.

[0111]

[0151] In some implementations, the expiration date 1148 offset indicates an offset to the time that the payment module 100 keeps the authorization acceptance token 1140 valid for initiating a transaction with a machine 120 associated with the payment module 100. For example, the expiration date offset 1148 depends on the history and credit of the user of the mobile device 150 or a period predefined by the user of the mobile device 150.

[0112]

[0152] In some embodiments, the authorization grant token 1140 further includes the authorization code 1104 that was included in the authorization request 1130. In some embodiments, if the authorization code 1104 is a hash value, the server 130 encrypts the authorization grant token 1140, including the hash value, with a shared secret encryption key associated with the payment module 100. Subsequently, when the mobile device 150 sends the authorization grant token 1140 to the payment module 100 after detecting the trigger condition, the payment module 100 decrypts the authorization grant token 1140 using a private key known only to the server 130 and the payment module 100 (which authenticates the message and the authorization grant), and then compares the hash value included in the decrypted authorization grant token 1140 with a previously broadcast valid (unexpired) hash value (i.e., authorization code) to determine its validity (known only to the payment module 100).

[0113]

[0153] Figure 24D shows a block diagram of transaction information 1150 generated by payment module 100 (e.g., in step 1204 of process 1200 in Figure 25A) according to some embodiments. In some embodiments, transaction information 1150 includes a transaction ID 1152, a module ID 1154, a user ID 1156, (optionally) an authorization code 1158, transaction status information 1160, a transaction amount 1162, and other information 1164 for each transaction.

[0114]

[0154] In some embodiments, transaction ID 1152 is a unique identifier corresponding to each transaction. In some embodiments, transaction ID 1152 is coded based on or associated with the time and / or date and location at which each transaction occurred.

[0115]

[0155] In some implementations, the module ID 1154 is a unique identifier corresponding to the payment module 100 that performed each transaction.

[0116]

[0156] In some implementations, user ID 1156 is an identifier associated with the user of mobile device 150 that initiated each transaction.

[0117]

[0157] In some embodiments, the authorization code 1158 corresponds to the original authorization code (e.g., authorization code 1104 in Figures 24A-24C) and / or authorization grant token (e.g., authorization grant token 1140 in Figure 24C) used to initiate each transaction. In some embodiments, the authorization code 1156 is encrypted with a unique encryption key corresponding to the payment module 100.

[0118]

[0158] In some embodiments, transaction status information 1160 includes an indication of whether each transaction is completed, incomplete, or aborted. For example, each transaction is incomplete if a jam occurs at the payment accepting unit 120 and the user does not receive the product associated with the transaction. Each transaction is aborted if, for example, the user walks away from the payment accepting unit 120 after money has been deposited in the transaction. In another example, each transaction is aborted if the transaction times out after a predetermined period of time because the user was unable to select a product at the payment accepting unit 120. In another example, each transaction is aborted if the user activates the bill or coin return mechanism of the payment accepting unit 120.

[0119]

[0159] In some implementations, transaction amount 1162 indicates the amount of each transaction or the amount of each of multiple transactions (e.g., in a multi-vending scenario). In some implementations, transaction amount 1162 is encrypted with a unique encryption key corresponding to payment module 100.

[0120]

[0160] In some embodiments, other information 1164 includes other information associated with each transaction, such as the item provided by payment accepting unit 120 and the type of transaction (e.g., coin, bill, credit card, manual mode, hands-free mode, etc.). In some embodiments, other information 1164 includes other information associated with the payment module 100 and / or the payment accepting unit 120 associated with payment module 100. For example, other information 1164 includes a verification request to server 130 to implement new firmware. See FIGS. 26A and 26B and the accompanying text for a further discussion of verification requests. In another example, other information 1164 includes transaction information from one or more previous aborted transactions. In another example, other information 1164 includes transaction information for one or more transactions paid with bills and / or coins. In another example, other information 1164 includes inventory information for one or more products of payment accepting unit 120.

[0121]

[0161] 25 shows a schematic flow diagram of a process 1200 for processing authorization information according to some embodiments. In some embodiments, a payment processing system includes one or more payment modules 100 (e.g., each associated with a respective payment accepting unit 120, such as an automated retail machine for selling goods and / or services), one or more mobile devices 150 (e.g., each executing an application 140 for the payment processing system as a foreground or background process), and a server 130. The server 130 manages the payment processing system and, in some cases, supplies, operates, and / or manufactures the one or more payment modules 100. For simplicity, the process 1200 will be described with respect to each payment module 100 and each mobile device 150 associated with each payment accepting unit 120 (machine 120) in the payment processing system. In the process 1200, the payment module 100 receives first authorization information for a first transaction via the mobile device 150 that initiated the first transaction.

[0122]

[0162] Payment module 100 obtains 1202 a first notification from machine 120 indicating the completion of a first transaction. For example, following process 1000 in FIG. 23 , a user of mobile device 150 selects products to purchase from machine 120 by interacting with one or more input mechanisms of machine 120 (e.g., buttons 126 or touchscreen display 124 shown in FIG. 19 ), and machine 120 dispenses the selected products. Continuing with the example, after the products are dispensed, the transaction is complete, and payment module 100 obtains 120 a notification from the machine of the completed transaction. In some implementations, the notification includes the amount of the transaction and (optionally) machine status information associated with machine 120, such as, for example, inventory information for one or more products at payment accepting unit 120.

[0123]

[0163] After obtaining the first notification, the payment module 100 generates 1204 first transaction information based on the first notification, and the payment module 100 stores the first transaction information. In some embodiments, the transaction information includes a transaction ID of the first transaction, a module ID corresponding to the payment module 100, a user ID corresponding to the mobile device 150, transaction status information indicating that the first transaction is completed, and the transaction amount indicated by the first notification. In some embodiments, the payment module 100 retains the authorization code and / or authorization grant token included in the original broadcast packet and includes the authorization code in the first transaction information. In some embodiments, the authorization code is encrypted with a private key corresponding to the payment module 100, which is shared with the server 130 but not with the mobile device 150. In some embodiments, the first transaction information further includes other information, such as machine status information included in the first notification or transaction information corresponding to a previous aborted transaction. For further discussion regarding transaction information 1150, see FIG. 24D and accompanying text.

[0124]

[0164] The payment module 100 transmits 1206 the first transaction information to the mobile device 150 via a short-range communication capability (e.g., BLE).

[0125]

[0165] The mobile device 150 transmits 1208 the first transaction information to the server 130 via a long-range communication capability (e.g., GSM, CDMA, Wi-Fi, etc.).

[0126]

[0166] The server 130 processes the first transaction information (1210). For example, the server 130 debits the amount indicated by the first transaction information from the account of the user associated with the user ID in the first transaction information.

[0127]

[0167] The server 130 has long-distance communication capabilities (e.g., The first authorization information is transmitted 1212 to the mobile device 150 via a mobile communication network (e.g., GSM, CDMA, Wi-Fi, etc.). In some embodiments, the first authorization information acknowledges that the server 130 has received the first transaction information. In some embodiments, the first authorization information includes a user ID, a module ID, a transaction ID, and (optionally) an authorization grant included in the transaction information (e.g., authorization grant 1158 of FIG. 24D).

[0128]

[0168] After receiving the first authorization information, the mobile device 150 transmits 1214 the first authorization information to the payment module 100 via a short-range communication capability (e.g., BLE).

[0129]

[0169] After receiving the first authorization information, the payment module 100 deletes (1216) the stored first transaction information.

[0130] Peripheral Expansion and Routing

[0170] Figure 26 is a block diagram of an electronic device 1300 for adapting a machine 120 (also referred to herein as a payment acceptance unit, vending machine, or retail machine) to accommodate multiple electronic peripheral devices 1330 (also referred to herein as peripherals) according to some embodiments. Device 1300 is similar to and adapted from adapter module 100 (also referred to herein as a payment module) shown in Figure 20 in that device 1300 connects to a multidrop bus (MDB) of machine 120 and optionally provides payment processing functionality (e.g., via internal peripherals 1340) as discussed in Figures 7, 8A-8G, 9A-9E, and 23.

[0131]

[0171] In some embodiments, during normal operation, machine 120 includes a multi-drop bus (MDB) that connects machine controller 1360 (also referred to herein as a payment acceptance unit controller) of machine 120 with payment peripherals (e.g., other payment peripherals 1350, 1355, including coin acceptors, bill acceptors, cashless payment devices such as payment card readers, etc.). In some embodiments, device 1300 is connected in-line to the MDB shown in FIGS. 17 and 18. In some embodiments, the MDB protocol or machine 120 is configured to support a limited number of payment peripherals or does not support certain payment peripherals. For example, in some situations, machine 120 supports a maximum of two cashless payment devices, or machine 120 supports only bill acceptors and coin acceptors and does not support cashless payment devices or other payment peripherals. Device 1300 can increase the number of payment peripherals connected to machine 120 beyond this limited number and support multiple payment peripherals that may or may not be compliant with machine 120 and / or the MDB protocol.

[0132]

[0172] 26 , device 1300 is configured to (i) function as a virtual payment peripheral for machine controller 1360 of machine 120, and (ii) function as a virtual machine controller (also referred to herein as a master or virtual master) for one or more payment peripherals 1330. Thus, in some embodiments, machine controller 1360 considers device 1300 to be another payment peripheral connected to the MDB when device 1300 transmits a signal to machine controller 1360 as if it were emitted by peripheral 1330. In some embodiments, transmitting a signal to machine controller 1360 as if it were emitted by peripheral 1330 includes labeling the signal or including a label with the signal, where the label includes registration information and / or identification information of the peripheral device (e.g., an address of the peripheral device). In other words, device 1300 identifies itself to machine controller 1360 as peripheral 1330 by using the registration information or identification information of the peripheral device. Additionally, in some embodiments, one or more payment peripherals 1330 consider the device 1300 to be a machine controller 1360 if the signal is sent to the one or more payment peripherals 1330 as if it were originated by the machine controller 1360. In some embodiments, sending a signal to a peripheral 1330 as if it were originated by the machine controller 1360 includes labeling the signal or including a label with the signal, where the label includes the machine controller's identity (e.g., the machine controller's address). In other words, the device 1300 identifies itself to the peripherals 1330 as the machine controller 1360 by using the machine controller's identity. To accomplish this, the device 1300 (in its role as a virtual machine controller) manages and hosts one or more payment peripherals 1330. The device 1300 also translates addresses and modifies communications as necessary so that the machine controller 1360 perceives traffic passing through it as coming from only one virtual payment peripheral.

[0133]

[0173] In FIG. 26, device 1300 includes a slave interface 1302 (e.g., male adapter 720, FIG. 20) and an additional interface 1304 (e.g., female adapter 730, FIG. 20) for connecting device 1300 to an MDB. Device 1300 also includes a device controller 1310 including a processing unit 1312 (e.g., including one or more processors, cores, microcontrollers, microprocessors, etc.) and a memory 1314 that stores one or more programs executed by processing unit 1312. In some embodiments, the one or more programs cause device 1300 to function as a virtual payment peripheral for machine controller 1360 and as a virtual machine controller for one or more payment peripherals 1330. In FIG. 26, device 1300 also includes one or more host interfaces 1320 (e.g., MDB ports or non-MDB ports) for connecting device 1300 to one or more payment peripherals 1330 (e.g., payment peripherals 1330-A through 1330-N).

[0134]

[0174] In some embodiments, machine 120 further comprises one or more other payment peripherals 1350, 1355 coupled to the MDB. Exemplary payment peripherals of the one or more other payment peripherals include a bill acceptor, a coin acceptor, or a payment card reader. In these embodiments, device 1300 further comprises an additional interface 1304 configured to couple the device with one or more other payment peripherals 1355 of the machine. For example, with reference to FIG. 26 , the other payment peripherals 1350 (e.g., acceptor, coin acceptor, payment card reader, etc.) are connected to the MDB before device 1300 (e.g., prior to slave interface 1302), and the other payment peripherals 1355 (e.g., acceptor, coin acceptor, payment card reader, etc.) are connected to the MDB after device 1300 (e.g., after the additional interface 1304).

[0135]

[0175] In some embodiments, the device 1300 further comprises a pass-through channel configured to pass signals from one or more other payment peripherals 1355 to the machine controller 1360. For example, with reference to FIG. 26 , the device 1300 comprises a pass-through channel that allows signals from the machine controller 1360 to reach the other payment peripherals 1355 and that allows signals from the other payment peripherals 1355 to reach the machine controller 1360.

[0136]

[0176] In some embodiments, device 1300 optionally includes an internal payment peripheral 1340 that includes hardware, software, firmware, or a combination thereof for providing one or more of the payment processing functions described above with reference to Figures 7, 8A-8G, 9A-9E, and 23 (e.g., including security unit 755 and communication unit 770 shown in Figure 20).

[0137]

[0177] 27 illustrates a schematic flow diagram of a payment peripheral registration process 1400 according to some embodiments. As a result of process 1400, for example, in accordance with the MDB protocol, device 1300 is registered as a slave (e.g., as a payment peripheral) of machine controller 1360, and payment peripheral 1330 is registered as a slave of device 1300. In other words, device 1300 acts (i) as a slave of machine controller 1360 (e.g., for operations 1402-1408) and (ii) as a master (machine controller) of payment peripheral 1330 (e.g., for operations 1412-1428).

[0138]

[0178] In some embodiments, the machine controller 1360 (FIG. 26) polls 1402 the device 1300. For example, the machine controller 1360 sends a polling command to the device 1300.

[0139]

[0179] In some embodiments, in response to the polling command, the device 1300 sends 1404 a reset signal to the machine controller 1360. For example, the device 1300 sends the reset signal to the machine controller 1360 if it is not already registered as a slave (e.g., a payment peripheral). In another example, the device 1300 sends the reset signal to re-register itself as a slave. In some embodiments, the reset signal causes the device 1300 to identify itself to the machine controller 1360 as a coin acceptor, a bill acceptor, or a cashless payment device.

[0140]

[0180] In some embodiments, in response to the reset signal, the machine controller 1360 sends 1406 a configuration signal to the device 1300. In some embodiments, the configuration signal includes an address assigned to the device 1300.

[0141]

[0181] In some embodiments, after receiving and processing the configuration signal, the device 1300 sends 1408 an acknowledgement to the machine controller 1360 confirming its registration as a slave.

[0142]

[0182] Upon sending the acknowledgement, the device 1300 is registered as a slave (e.g., a payment peripheral) of the machine controller 1360.

[0143]

[0183] In some implementations, the device 1300 polls 1412 the payment peripheral 1330-A.

[0144]

[0184] In some embodiments, in response to the polling command, the payment peripheral 1330-A sends 1414 a reset signal to the device 1300. For example, the payment peripheral 1330-A sends the reset signal to the device 1300 if it is not already registered as a slave (e.g., a payment peripheral) of the device 1300. In another example, the payment peripheral 1330-A sends the reset signal to re-register itself as a slave. In some embodiments, the reset signal causes the payment peripheral 1330-A to identify itself to the device 1300 as a coin acceptor, a bill acceptor, or a cashless payment device.

[0145]

[0185] In some embodiments, in response to the reset signal, the device 1300 sends 1416 a configuration signal to the payment peripheral 1330-A. In some embodiments, the configuration signal includes an address assigned to the payment peripheral 1330-A.

[0146]

[0186] In some embodiments, after receiving and processing the configuration signal, the payment peripheral 1330-A sends 1418 an acknowledgment to the device 1300 confirming its registration as a slave.

[0147]

[0187] In some implementations, the device 1300 polls (1422) the payment peripherals 1330-N.

[0148]

[0188] In some embodiments, in response to the polling command, the payment peripheral 1330-N sends 1424 a reset signal to the device 1300. For example, the payment peripheral 1330-N sends a reset signal to the device 1300 if it is not already registered as a slave (e.g., a payment peripheral). In another example, the payment peripheral 1330-N sends a reset signal to re-register itself as a slave. In some embodiments, the reset signal causes the payment peripheral 1330-N to identify itself to the device 1300 as a coin acceptor, a bill acceptor, or a cashless payment device.

[0149]

[0189] In some embodiments, in response to the reset signal, the device 1300 sends 1426 a configuration signal to the payment peripheral 1330-N. In some embodiments, the configuration signal includes an address assigned to the payment peripheral 1330-N.

[0150]

[0190] In some embodiments, after receiving and processing the configuration signal, the payment peripheral 1330-N sends 1428 an acknowledgment to the device 1300 confirming its registration as a slave.

[0151]

[0191] 28A and 28B show a schematic flow diagram of a payment process 1500 according to some embodiments. In some embodiments, according to process 1400 (FIG. 27), (i) device 1300 is already registered as a slave (e.g., payment peripheral) of machine controller 1360, and (ii) payment peripherals 1330-A, 1330-N are already registered as slaves (e.g., payment peripherals) of device 1300. In other words, device 1300 acts (i) as a slave to machine controller 1360 (e.g., for operations 1502-1504, 1520-1528, 1540-1548, and 1554-1556) and (ii) as a master (machine controller) of payment peripheral 1330 (e.g., for operations 1506-1518, 1530-1538, 1550-1552, and 1558-1564).

[0152]

[0192] In some embodiments, the machine controller 1360 polls the device 1300, along with other payment peripherals connected to the MDB and registered as slaves (e.g., other payment peripherals 1350, 1355 (FIG. 26)), according to a predetermined time (e.g., 5 ms). For example, the predetermined time is specified by the MDB protocol or specification (e.g., versions 1.0-3.0 or higher), which is incorporated herein by reference in its entirety. In response to the polling command, all slave devices (e.g., including at least the device 1300) respond with an acknowledgment (e.g., indicating that they are still on the MDB) or another signal (e.g., indicating another state). In some embodiments, in response to a command from the machine controller 1360, the device 1300 responds to the command immediately and asynchronously relays the command to at least one of the payment peripherals 1330.

[0153]

[0193] In some embodiments, the device 1300 polls the payment peripheral 1330 according to a predetermined time (e.g., 5 ms), just like the machine controller 1360. For example, the device 1300 polls the payment peripheral 1330 whenever it is polled by the machine controller 1360.

[0154]

[0194] In some embodiments, the machine controller 1360 polls 1502 the device 1300 .

[0155]

[0195] In response to the polling command in operation 1502, the device 1300 sends 1504 an acknowledgement to the machine controller 1360.

[0156]

[0196] In response to the polling command in operation 1502 or independently, the device 1300 polls (1506) the payment peripheral 1330-N. In response to the polling command in operation 1506, the payment peripheral 1330-N sends (1508) an acknowledgment to the device 1300.

[0157]

[0197] In response to the polling command at operation 1502 or independently, the device 1300 polls 1510 the payment peripheral 1330-A. In response to the polling command at operation 1510, the payment peripheral 1330-A sends 1512 a request to initiate a payment session. For example, the request to initiate a payment session may be sent in response to a user inserting a payment (e.g., a note or coin) into the payment peripheral 1330-A prior to the polling command at operation 1510.

[0158]

[0198] In response to the request to initiate a payment session, the device 1300 sends 1514 an acknowledgment to the payment peripheral 1330-A.

[0159]

[0199] In response to the request to initiate a payment session, the device 1300 also sends (1516) a disable command to the payment peripheral 1330-N to disable the payment peripheral 1330-N while processing the payment session for the payment peripheral 1330-A. In response to the disable command, the payment peripheral 1330-N sends (1518) an acknowledgment to the device 1300.

[0160]

[0200] The machine controller 1360 polls 1520 the device 1300 .

[0161]

[0201] In response to the polling command at operation 1520, the device 1300 sends (1522) a request to initiate a payment session to the machine controller 1360. For example, the request to initiate a payment session (sent to the machine controller 1360 at operation 1522) reflects the request to initiate a payment session (received from the payment peripheral 1330-A at operation 1512).

[0162]

[0202] In response to the request to initiate a payment session in operation 1522, the machine controller 1360 sends 1524 an acknowledgment to the device 1300 and also sends 1526 a vending request to the device 1300. In process 1500, vending of a service or product is considered a non-limiting example.

[0163]

[0203] In response to receiving the vending request, the device 1300 sends 1527 an acknowledgment to the machine controller 1360.

[0164]

[0204] In some embodiments, the machine controller 1360 polls 1528 the device 1300 N times before the device 1300 sends a vending acknowledgement signal in operation 1540. In some embodiments, the device 1300 responds to the N polling commands with an acknowledgement that indicates the device 1300 is still present and processing vending requests.

[0165]

[0205] In response to receiving the vending request in operation 1526, the device 1300 relays 1530 the vending request to the payment peripheral 1330-A.

[0166]

[0206] In response to the vending request in operation 1530, the payment peripheral 1330-A sends 1532 an acknowledgment to the device 1300.

[0167]

[0207] The device 1300 then polls (1534) the payment peripheral 1330-A. In response to the polling command in operation 1534, the payment peripheral 1330-A sends (1536) a vending authorization signal to the device 1300. For example, the vending authorization signal indicates that the payment entered by the user has not been refunded and has been used to purchase a service or product.

[0168]

[0208] In response to receiving the vending authorization signal in operation 1536, the device 1300 sends (1538) an acknowledgment to the payment peripheral 1330-A and relays (1540) the vending authorization signal to the machine controller 1360.

[0169]

[0209] In response to receiving the vending acknowledgement signal in operation 1540, the machine controller 1360 sends (1542) an acknowledgment to the device 1300 and also sends (1544) a request to the device 1300 indicating whether the vending was successful or unsuccessful.

[0170]

[0210] In response to receiving the request in operation 1544, the device 1300 sends (1546) a response to the machine controller 1360 indicating whether the vending was successful or unsuccessful, and relays (1550) a request to the payment peripheral 1330-A indicating whether the vending was successful or unsuccessful.

[0171]

[0211] In response to the request in operation 1550, the payment peripheral 1330-A sends 1552 an acknowledgment to the device 1300.

[0172]

[0212] In response to receiving the response in operation 1546, the machine controller 1360 sends (1548) an acknowledgment to the device 1300 and also sends (1554) a command to the device 1300 to terminate the payment session.

[0173]

[0213] In response to receiving the command to terminate the payment session in operation 1554, the device 1300 sends an acknowledgment to the machine controller 1360 (1556) and relays the command to terminate the payment session to the payment peripheral 1330-A (1558).

[0174]

[0214] In response to the command to terminate the payment session in operation 1558, the payment peripheral 1330-A sends 1560 an acknowledgment to the device 1300.

[0175]

[0215] After receiving the confirmation response from the payment peripheral 1330-A in operation 1560, the device 1300 sends (1562) an enable command to the payment peripheral 1330-N to enable the payment peripheral 1330-N after completion of the payment session of the payment peripheral 1330-A. In response to the enable command received in operation 1562, the payment peripheral 1330-N sends (1564) an acknowledgement response to the device 1300.

[0176]

[0216] FIG. 29 illustrates a flowchart of a method 1600 of adapting a machine controller 1360 (also referred to herein as a payment accepting unit, vending machine, retail machine, and / or a processor or controller of a payment accepting unit, vending machine, or retail machine) to accommodate multiple payment peripherals 1330 (also referred to herein as electronic peripheral devices, peripheral devices, or peripherals) in accordance with some embodiments. In some embodiments, method 1600 is performed in a device controller 1310 of an electronic device 1300 that includes one or more processing units 1312 (processors), a memory 1314, a slave interface 1302 configured to couple the device 1300 to a machine controller 1360 via a multi-drop bus (MDB), and one or more host interfaces 1320 configured to couple the device 1300 to one or more payment peripherals 1330 (e.g., cashless payment devices such as coin acceptors, bill acceptors, payment card readers, etc.), where each payment peripheral 1330 is separate from the MDB interface of the machine controller 1360 and coupled to a respective host interface 1320, where the payment peripherals 1330 are configured to communicate via the MDB protocol. For example, in some embodiments, method 1600 is performed by the device 1300 or a component thereof (e.g., the device controller 1310). In some embodiments, method 1600 is governed by instructions stored in a non-transitory computer-readable storage medium (e.g., memory 1314) and executed by one or more processors of the device (e.g., processing unit 1312). Optional operations are indicated by dashed lines (e.g., boxes with dashed borders).

[0177]

[0217] The device 1300 acts as a virtual payment peripheral (slave) for the machine controller 1360 by registering itself as a slave to the machine controller 1360 (1602), and the device 1300 acts as a virtual machine controller (master) for one or more payment peripherals 1330 by registering one or more payment peripherals 1330 as slaves to the device 1300 using the MDB protocol. In some implementations, the MDB protocol supports a limited number of payment peripherals 1330. The device 1300 increases the number of payment peripherals 1330 that can be connected to the machine controller 1360 beyond this limited number by (i) emulating the machine controller 1360 to the payment peripheral 1330 coupled with the host interface 1320, and (ii) emulating the payment peripheral 1330 to the machine controller 1360. Thus, in some embodiments, the machine controller 1360 sees the device 1300 as another payment peripheral 1330 connected to the MDB, and the device 1300 sends signals to the machine controller 1360 as if they were emitted by the device 1300 functioning as the only virtual payment peripheral 1330 (in other words, as if they were emitted by the payment peripheral 1330). Also, in some embodiments, the payment peripheral 1330 sees the device 1300 as the machine controller 1360, and the device 1300 sends signals to the payment peripheral 1330 as if they were emitted by the machine controller 1360.

[0178]

[0218] In some embodiments, registering the device 1300 as a slave to the machine controller 1360 further includes identifying the device 1300 as a cashless payment peripheral to the machine controller 1360 and accepting 1602a the registration of the device 1300 as a cashless payment peripheral with the machine controller 1360. For example, the device 1300 identifies itself to the machine controller 1360 as a cashless payment device (e.g., a payment card reader) when it sends a reset signal to the machine controller 1360 in operation 1404, and the device 1300 accepts registration as a cashless payment device when it receives a configuration signal from the machine controller 1360 in operation 1406 (see FIG. 27 ).

[0179]

[0219] In some embodiments, registering device 1300 as a slave to machine controller 1360 further includes identifying device 1300 as a coin acceptor peripheral to machine controller 1360 and accepting (1602b) registration of device 1300 as a coin acceptor peripheral with machine controller 1360. For example, device 1300 identifies itself as a coin acceptor to machine controller 1360 when it sends a reset signal to machine controller 1360 in operation 1404, and device 1300 accepts registration as a coin acceptor when it receives a set signal from machine controller 1360 in operation 1406 (see FIG. 27 ).

[0180]

[0220] In some embodiments, registering the device 1300 as a slave to the machine controller 1360 further includes identifying the device 1300 as a bill acceptor peripheral to the machine controller 1360 and accepting (1602c) the registration of the device 1300 as a bill acceptor peripheral with the machine controller 1360. For example, the device 1300 identifies itself as a bill acceptor / validator to the machine controller 1360 when it sends a reset signal to the machine controller 1360 in operation 1404, and the device 1300 accepts the registration as a bill acceptor / validator when it receives a set signal from the machine controller 1360 in operation 1406 (see FIG. 27 ).

[0181]

[0221] The device 1300 receives 1604 a command (in the form of a signal) from the machine controller 1360 via the slave interface 1302, and the signal from the machine controller 1360 is transmitted as if it were transmitted to only one payment peripheral 1330. For example, referring to process 1500, the machine controller 1360 transmits a command to the device 1300 to terminate the payment session in operation 1554 (see FIG. 28B).

[0182]

[0222] In response to receiving the command from the machine controller 1360, the device 1300 sends (1604) an acknowledgment of the command to the machine controller 1360 via the slave interface 1302, which sends a signal to the machine controller 1360 as if it had been issued by the device 1300 acting as the only virtual payment peripheral 1330 (in other words, as if it had been issued by the payment peripheral 1330), which relays the command to each payment peripheral 1330 via each host interface 1320 corresponding to each payment peripheral 1330, and the device 1300 sends and receives signals to the machine controller 1360 asynchronously with the device 1300's sending and receiving of signals to one or more payment peripherals 1330 (in other words, communication between the device 1300 and the machine controller 1360 is not necessarily synchronized with communication between the device 1300 and the payment peripherals 1330). Continuing with the above example and referring to process 1500, in response to receiving the command to terminate the payment session at operation 1554, the device 1300 sends an acknowledgment to the machine controller 1360 at operation 1556, as if issued by the device 1300 acting as the only virtual payment peripheral 1330 (in other words, as if issued by the payment peripheral 1330). Continuing with the example, in response to receiving the command to terminate the payment session at operation 1554, the device 1300 also asynchronously relays the command to terminate the payment session to the payment peripheral 1330-A at operation 1558. Thus, the command is relayed to the payment peripheral 1330-A asynchronously with sending the acknowledgment to the machine controller 1360 (in other words, signals 1556 and 1558 are not necessarily synchronized).

[0183]

[0223] In some embodiments, in response to relaying the command, the device 1300 receives 1608 a response from each payment peripheral 1330 via a respective host interface 1320 corresponding to each payment peripheral 1330. Continuing with the above example and referring to process 1500, in response to the relayed complete session command at operation 1558, the payment peripheral 1330-A sends an acknowledgment to the device 1300 at operation 1560.

[0184]

[0224] In some embodiments, in response to receiving a response from each payment peripheral 1330, the device 1300 sends an acknowledgment to each payment peripheral 1330, the signal is sent to one or more payment peripherals 1330 as if it were initiated by the machine controller 1360, and relays the response to the machine controller 1360 via the slave interface 1302, the device 1300 sending and receiving signals to the machine controller 1360 asynchronously with the device's sending and receiving of signals to one or more payment peripherals 1330 (in other words, communication between the device 1300 and the machine controller 1360 is not necessarily synchronized with communication between the device 1300 and the payment peripherals 1330). In some embodiments, in response to receiving a response from each payment peripheral 1330, the device forgoes the above steps (e.g., the device 1300 does not relay the acknowledgment 1560 to the machine controller 1360 because it already acknowledged the machine controller's 1360's session complete command in operation 1556).

[0185]

[0225] In some embodiments, the device 1300 receives 1610 a command from each payment peripheral 1330 via a respective host interface 1320 corresponding to each payment peripheral 1330, a signal from each payment peripheral 1330 is transmitted to the device 1300 as if it were transmitted to a machine controller 1360, and in response to receiving the command from each payment peripheral 1330, the device 1300 transmits 1612 an acknowledgment for the command to each payment peripheral 1330, and the signal is transmitted as if it were transmitted to a machine controller 1360. The command is sent from the device 1300 to the payment peripheral 1330 as if issued by the machine controller 1360, which relays the command to the machine controller 1360 via the slave interface 1302, with the device 1300 sending and receiving signals to the machine controller 1360 asynchronously with the device 1300 sending and receiving signals to the payment peripheral 1330 (in other words, communication between the device 1300 and the machine controller 1360 is not necessarily synchronized with communication between the device 1300 and the payment peripheral 1330). For example, referring to process 1500, when polled at operation 1534, the payment peripheral 1330-A sends a vending authorization signal to the device 1300 at operation 1536 as if sent to the machine controller 1360. Continuing with this example, in response to receiving the vending authorization signal at operation 1536, the device 1300 sends an acknowledgment to the payment peripheral 1330-A at operation 1538 as if issued by the machine controller 1360. Continuing with this example, in response to receiving the vending authorization signal at operation 1536, the device 1300 also asynchronously relays the vending authorization signal to the machine controller 1360 at operation 1540. Thus, the command is relayed to the machine controller 1360 asynchronously with sending an acknowledgment to the payment peripheral 1330-A (in other words, signals 1538 and 1540 are not necessarily synchronized).

[0186]

[0226] In some embodiments, in response to relaying the command, the device 1300 receives 1614 a response from the machine controller 1360 via the slave interface 1302. Continuing with the above example and referring to process 1500, in response to the relayed self-sales acknowledgement signal in operation 1540, the machine controller 1360 sends an acknowledgment to the device 1300 in operation 1542.

[0187]

[0227] In some embodiments, device 1300 further comprises an internal payment peripheral 1340 with short-range communication capabilities corresponding to a short-range communication protocol, the short-range communication capabilities configured to communicate with one or more mobile devices, each of which is configured with (i) complementary short-range communication capabilities and (ii) long-range communication capabilities corresponding to a long-range communication protocol. For example, with reference to Figure 26, device 1300 comprises internal payment peripheral 1340 including hardware, software, firmware, or a combination thereof for providing the payment processing functionality discussed in Figures 7, 8A-8G, 9A-9E, and 23 (e.g., security unit 755 and communication unit 770 shown in Figure 20). For example, each mobile device corresponds to mobile device 150 (Figure 21) with long-range communication capabilities 872 and short-range communication capabilities 876.

[0188]

[0228] In some embodiments, device 1300 receives (1616) a transaction request from each mobile device via the short-range communication capability to execute the transaction with machine controller 1360, device 1300 validates the transaction request, indicating that each mobile device has been authorized by the remote server via the long-range communication capability of each mobile device to initiate payment for the transaction, and pursuant to a determination that the transaction request is valid, device 1300 causes machine controller 1360 to execute the requested transaction, e.g., by issuing a signal to machine controller 1360 via slave interface 1302 to execute the transaction. In some embodiments, device 1300 or a component thereof (e.g., internal payment peripheral 1340, FIG. 26) receives a transaction request from each mobile device 150 (FIGS. 7, 8A to 8G, 9A to 9E, and FIG. 21) via a short-range communication capability (e.g., BLE, NFC, etc.), and device 1300 or a component thereof (e.g., internal payment peripheral 1340, FIG. 26; or device controller 1310, FIG. 26) verifies the transaction request from each mobile device 150 by determining whether an AuthGrant or authorization acceptance token associated with the transaction request contains a valid authorization code. In some embodiments, following a determination that the transaction request is associated with a valid authorization code, the device 1300 or a component thereof (e.g., the internal payment peripheral 1340, FIG. 26; or the device controller 1310, FIG. 26) issues a command to the machine controller 1360 via the slave interface 1302 to execute the requested transaction as if issued by the device 1300 acting as the only virtual payment peripheral 1330 or 1340 (in other words, as if issued by the payment peripheral 1330 or 1340).

[0189]

[0229] In some embodiments, in accordance with a determination that the command received from each payment peripheral 1330 corresponds to a transaction, the device 130 0 stores 1618 transaction information including at least the amount of the transaction associated with an identifier of each payment peripheral device 1330, and after storing the transaction information, the device 1300 transmits the transaction information to each mobile device via a short-range communication capability and issues a command to each mobile device to transmit the transaction information to a remote server via a long-range communication capability of each mobile device.

[0190]

[0230] In some embodiments, the device 1300 or a component thereof (e.g., the internal payment peripheral 1340, FIG. 26; or the device controller 1310, FIG. 26) monitors commands and signals from one or more payment peripherals 1330 that are relayed to the machine controller 1360, and, pursuant to a determination that a command or signal is associated with a transaction, stores transaction information, such as the transaction amount and each payment peripheral 1330 associated with the transaction. For example, the device 1300 stores the transaction information for each of the one or more payment peripherals 1330 in a table that associates the transaction information with the type of payment peripheral (e.g., bill acceptor, coin acceptor, payment card reader, etc.). In some embodiments, the device 1300 or a component thereof (e.g., the internal payment peripheral 1340, FIG. 26; or the device controller 1310, FIG. 26) transmits the table of transaction information, or a portion thereof, to each mobile device 150 that sent a transaction request (or another mobile device 150 that executes a transaction with the device 1300) via a short-range communication capability. In some implementations, the device 1300 or a component thereof (e.g., the internal payment peripheral 1340, FIG. 26; or the device controller 1310, FIG. 26) instructs each mobile device 150 to transmit a table of transaction information, or a portion thereof, to the server 130 via the long-range communication capabilities of the mobile device. Thus, the device 1300 uses each mobile device 150 as a communication bridge with the server 130.

[0191]

[0231] In some embodiments, the device 1300 or a component thereof (e.g., an internal payment peripheral 1340, FIG. 26; or a device controller 1310, FIG. 26) also monitors commands and signals from one or more payment peripherals 1330 that are relayed to the machine controller 1360, and stores corresponding operational information upon determining that a command or signal is associated with an error code (e.g., coin jam, low coin or note count, etc.) or other information associated with the operation of one or more payment peripherals 1330. In some embodiments, the device 1300 also transmits the operational information along with a table or portion thereof of transaction information to the server 130, using each mobile device 150 as a communication bridge with the server 130.

[0192]

[0232] The particular order in which the operations of Figure 29 are described is merely exemplary and is not intended to represent the only order in which the operations may be performed. Those skilled in the art will recognize various ways to reorder the operations described herein. Additionally, other process details described herein with respect to other methods described herein are also equally applicable to method 1600 described above with respect to Figure 29.

[0193] Providing external access to peripherals

[0233] In some embodiments, electronic device 1300 receives a request to access one or more of peripherals 1330 from mobile device 150 via the short-range communication capabilities of internal peripherals 1340. In response to the request, device 1300 intercepts signals (e.g., disbursement signals reporting amounts received at a bill acceptor peripheral or a coin acceptor peripheral) received from peripherals 1330 via their respective host interfaces 1320. Rather than relaying the signals to machine controller 1360, device 1300 relays the signals (or data based on the signals) to mobile device 150 through internal peripherals 1340. While the device 1300 is blocking signals received from the peripheral 1330 (i.e., relaying the signals to the internal peripheral 1340 rather than the machine controller 1360), the device 1300 responds to commands intended for the peripheral 1330 (e.g., polling commands sent from the machine controller 1360) with an acknowledgment (e.g., simply reporting its presence) rather than relaying the command to the peripheral 1330.

[0194]

[0234] By blocking signals as described herein, device 1300 can provide external access to peripheral 1330 (also referred to as providing peripheral access to an external device). More specifically, device 1300 may be configured to allow an external device (e.g., a mobile device 150 or any device physically external to machine 120 and in communication with device 1300) to access functionality provided by peripheral 1330 of machine 120. As used herein, the term “access” may refer to the provision of data based on the functionality of peripheral 1330, but does not require direct communication between the external device and the peripheral 1330 being accessed. Providing an external device with access to peripheral 1330 allows the external device to benefit from the functionality of peripheral 1330. For example, if peripheral 1330 is a bill collector, an external device accessing the functionality of the bill collector may be provided with data indicating the status of the bill collector or any other data related to the functionality of the bill collector (e.g., that the bill collector just accepted a one-dollar bill).

[0195]

[0235] In one exemplary scenario, an application executing on a mobile device 150 in communication with device 1300 may be provided with access to a bill acceptor peripheral 1330 of machine 120, thereby providing a way for the application to accept cash payments. Thus, the capabilities of mobile device 150 (and therefore applications executing on mobile device 150) are enhanced when given access to functionality provided by peripheral 1330 of machine 120 as described herein. Applications executing on such mobile devices 150 (referred to herein as mobile applications) may be configured to sell products and / or services not necessarily stored by machine 120 of the accessed peripheral 1330, but to benefit from the availability of the option to pay for the products and / or services with cash. For example, an application executing on mobile device 150 may sell lottery tickets that, according to the laws of some jurisdictions, can only be purchased using cash. Exemplary products may include physical products available at a location associated with machine 120 (e.g., offered by a store clerk or bank teller), or may include virtual products that do not need to be obtained or physically delivered (e.g., lottery tickets associated with virtual draw entries that do not require the delivery or use of a physical scratch card). Exemplary services include banking transactions (e.g., using the bill acceptor peripheral 1330 of machine 120 to deposit cash into a bank or credit union account, regardless of whether the bank or credit union has a physical location), or any other service that requires or offers the option to deposit cash into an account (e.g., a gaming service where add-on features can be purchased with cash, a peer-to-peer money transfer service that allows a sender to deposit cash into a bill acceptor of machine 120 and a recipient to withdraw the cash by accessing a cash dispensing module of another machine 120, or any other service that accepts cash payments).Such products and / or services may be related to the products and / or services vended or advertised by machine 120 or may be unrelated to the products and / or services vended or advertised by machine 120 (e.g., the bill acceptor functionality of a soda machine may be accessed by a mobile application that sells lottery tickets, or the coin acceptor functionality of a washing machine may be accessed by a mobile gaming application configured to accept payment in exchange for add-on features within the game).

[0196]

[0236] 30A-30B illustrate block diagrams of normal operation 3002 and intercept operation 3004 of device 1300 for modifying machine 120 to provide external access to electronic peripheral device 1330 according to some embodiments. Device 1300 and associated components (1302-1360) correspond to like-numbered features described above with reference to FIG. 26, some of which will not be discussed further for the sake of brevity. Additionally, although some features shown in FIG. 26 are not shown in FIGS. 30A-30B (for clarity), each of the concepts described above with respect to FIGS. 26-29 apply equally to the embodiments described herein with respect to FIGS. 30A-30B, 31-34, and 35A-35B.

[0197]

[0237] In FIG. 30A , device 1300 is configured to relay signals between machine controller 1360 and peripheral device 1330. For example, device 1300 receives (3118) a payment receipt signal from peripheral device 1330 (e.g., upon receiving a one dollar bill) and relays (3124) the signal to machine controller 1360. With respect to polling in normal operation, device 1300 is configured to respond to polls received from machine controller 1360 and to asynchronously send polls to peripheral device 1330. As described above with reference to FIGS. 28A and 28B , device 1300 responds to polls received from machine controller 1360 based on the polling responses received from peripheral device 1330. Thus, while performing normal operation, device 1300 functions as a signal router bridging peripheral device 1330 and machine controller 1360 as described above with reference to FIGS. 28A and 28B and in more detail below with reference to FIGS. 31 and 32 .

[0198]

[0238] 30B , the device 1300 is configured to acknowledge signals received from the machine controller 1360 (e.g., acknowledge polling), but not relay those signals to the peripheral 1330 (or transmit a signal based on those received signals). Furthermore, rather than relaying signals received from the peripheral 1330 (e.g., payment receipt signal 3306) to the machine controller 1360, the device 1300 relays the signals received from the peripheral 1330 (or transmits a signal, such as a transmit transaction signal 3312, based on the received signals) to an external device (e.g., the mobile device 150) via the internal peripheral 1340. For example, the device 1300 receives the payment receipt signal 3306 from the peripheral 1330 (e.g., upon receiving a one-dollar bill) and relays the payment receipt signal 3306, or a signal based on the payment receipt signal (e.g., transmit transaction signal 3312), to the mobile device 150 via the internal peripheral 1340. This disclosure refers to the act of relaying a signal received from the peripheral device 1330 to an external device, but not to the machine controller 1360, as blocking the signal, or as an intercept operation. While performing an intercept operation, the device 1300 acts as a signal router bridging the peripheral device 1330 and the external device (e.g., the mobile device 150), as described in more detail below with reference to FIGS.

[0199]

[0239] In some embodiments, a signal received by the device controller 1310 includes at least (i) a destination address and (ii) message data. More specifically, a signal received by the device 1300 from a peripheral 1330 includes the address of a designated master (referred to herein as a master address), and a signal received by the device 1300 from the machine controller 1360 includes the address of a designated peripheral 1330 (referred to herein as a peripheral address). The master address and peripheral address may be identified or assigned during a registration process (e.g., during set operations 1406, 1416, and 1426 of FIG. 27 , during set operations 3102 and 3106 of FIG. 31 , during set operation 3208 of FIG. 32 , and during set operation 3416 of FIG. 34 ). The message data may include an indication of the status of the originating module (e.g., a signal received from a particular peripheral 1330 may include an indication of the status of the particular peripheral 1330) or any other data related to the functionality of the originating module. As used herein, the term "originating module" refers to a module (eg, peripheral device 1330 or machine controller 1360) that sent a signal containing the described destination address or message data.

[0200]

[0240] For example, if the signal sent by peripheral device 1330 to device 1300 designates machine controller 1360 as the master address, device controller 1310 relays a signal containing the signal's message (e.g., indicating receipt of a $1 bill) to machine controller 1360, as shown in Figure 30A. On the other hand, if the signal sent by peripheral device 1330 to device 1300 designates device 1300 as the master address, device controller 1310 either relays the signal containing the signal's message (e.g., indicating receipt of a $1 bill) to an external device (e.g., mobile device 150), as shown in Figure 30B, or processes the signal and sends a signal containing a message based at least in part on the originally received message (e.g., indicating that a $1 bill was received and not refunded within a threshold time).

[0201]

[0241] Figures 31 through 34 illustrate schematic flow diagrams of a process for providing external access to electronic peripherals 1330 of machine 120 in accordance with some embodiments. Figure 31 illustrates a method 3100 for normal operation (e.g., 3002 in Figure 30A), Figure 32 illustrates a method 3200 for transitioning from normal operation to intercept operation (e.g., 3004 in Figure 30B), Figure 33 illustrates a method 3300 for intercept operation, and Figure 34 illustrates a method 3400 for transitioning from intercept operation to normal operation.

[0202]

[0242] The operations of Figures 31-34 are governed by instructions stored in computer memory or non-transitory computer-readable storage media of any combination of machine controller 1360, electronic device 1300 (e.g., memory 1314 of Figure 26), electronic peripheral 1330, mobile device 150, and server 130. The instructions are executed by one or more processors of any combination of machine controller 1360, electronic device 1300 (e.g., processing unit 1312 of Figure 26), electronic peripheral 1330, mobile device 150, and server 130. Each computer-readable storage medium may include a magnetic or optical disk storage device, a solid-state storage device such as flash memory, or one or more other non-volatile memory devices. The instructions stored on each computer-readable storage medium may include one or more of source code, assembly language code, object code, or other instruction formats interpreted by one or more processors. Some operations of Figures 31-34 may be combined, and / or the order of some operations of Figures 31-34 may be changed.

[0203]

[0243] Although methods 3100-3400 illustrate an embodiment including one peripheral device 1330 (for brevity and clarity of the concepts described herein), the concepts described herein also apply to embodiments including multiple peripheral devices 1330 (e.g., peripherals 1330-A through 1330-N, as described above with reference to FIGS. 26-29). Specifically, in embodiments in which machine 120 includes multiple peripheral devices 1330, device 1300 (i) polls each of the multiple peripheral devices 1330, (ii) processes signals received from a particular peripheral device 1330 of the multiple peripheral devices 1330 as described in methods 3100-3400, and (iii) responds to the peripheral device 1330 that sent the signal as described in methods 3100-3400. For example, machine 120 may include a bill acceptor as a first peripheral device 1330 and a coin acceptor as a second peripheral device 1330. In such a scenario, the mobile device 150 would be provided with data regarding signals received from the banknote acceptor in accordance with the concepts described in methods 3100-3400 and signals received from the coin acceptor in accordance with the concepts described in methods 3100-3400.

[0204]

[0244] Additionally, although methods 3100-3400 refer to peripheral device 1330 as a bill acceptor, the concepts described herein also apply to other types of peripheral device 1330. As discussed above, exemplary peripheral device 1330 include bill acceptors, coin acceptors, and cashless payment devices such as payment card readers. Exemplary peripheral device 1330 may also include any other type of electronic peripheral device, whether related or unrelated to accepting payments.

[0205]

[0245] Finally, the operations of methods 3100-3400 are shown in a particular order and with particular vertical offsets (spacings) relative to one another. Regarding particular orders, unless otherwise noted in the description of a particular operation, operations may be performed out of the order shown in the figures, particularly for operations in different columns, and particularly for operations that are described as asynchronous. For example, the acknowledgment of operation 3104 is described (more fully below) as being sent in response to the polling signal sent in operation 3102; therefore, this pair of operations, and others similarly described, must be performed in the order shown in the figures. However, the polling signal of operation 3106 may be sent before, after, or simultaneously with the polling signal sent in operation 3102, because no particular order or time constraints are described in the description of these operations. Regarding particular vertical offsets for operations, these offsets are provided for clarity and are not a time scale. Thus, the relative interval sizes between operations do not affect the relative time that must elapse between the execution of such operations.

[0206]

[0246] As described above with reference to FIG. 30A , normal operation may be characterized by the device 1300 relaying signals between the peripheral 1330 and the machine controller 1360. FIG. 31 illustrates an exemplary normal operation according to some embodiments. Referring to FIG. 31 , the machine controller 1360 polls the device 1300 (3102), and the device 1300 responds with an acknowledgment (3104). Asynchronously (relative to operations 3102 and 3104), the device 1300 polls the peripheral 1330 (1306), and the peripheral 1330 responds with an acknowledgment (3108). If the device 1300 is not registered as a slave with the machine controller 1360 when polled in operation 3102, the machine controller 1360 registers the device 1300 with a configuration signal as described above with reference to FIG. 27 (operations 1404-1408). Similarly, if peripheral device 1330 is not registered as a slave to device 1300 when polled in operation 3106, device 1300 registers peripheral device 1330 with a configuration signal as described above with reference to FIG. 27 (operations 1414-1418).

[0207]

[0247] The machine controller 1360 continues to poll the device 1300 at a frequency determined by the particular implementation of the MDB protocol, which in turn polls the peripheral 1330 at a frequency determined by the particular implementation of the MDB protocol, or at any other predetermined frequency. Eventually, a payment event (3114) occurs at the peripheral 1330 (e.g., a one dollar bill is accepted). The device 1300 responds to polls from the machine controller 1360 with an acknowledgment until the device 1300 receives a signal from the peripheral 1330 indicating the payment event. Thus, when the machine controller 1360 again polls the device 1300 (3110), the device 1300 responds with an acknowledgment (3112). After the payment event, the device 1300 polls the peripheral 1330 (3116), which responds with a payment acceptance signal indicating the payment event 3114 (3118). For example, the payment acceptance signal may be sent to machine controller 1360 (as shown in FIG. 30A) and may include a message indicating that a one dollar bill has been accepted by peripheral device 1330.

[0208]

[0248] In response to receiving the payment receipt signal from the peripheral 1330, the device 1300 (i) responds (3120) with an acknowledgment to the peripheral 1330, and after receiving (3122) the next poll from the machine controller 1360, (ii) transmits (3124) the payment receipt signal (e.g., including a $1 receipt message) to the machine controller 1360. As described above with reference to FIGS. 28A and 28B , the device 1300 may respond with an acknowledgment to the peripheral 1330 at operation 3120 without waiting for any other action or event to occur, but the device 1300 must wait to receive the next poll (as shown in operation 3122) until it has an opportunity to transmit the payment receipt signal to the machine controller 1360 at operation 3124.

[0209]

[0249] As described above with reference to FIG. 30B , an intercept operation may be characterized by the device 1300 relaying signals between the peripheral 1330 and an external device (e.g., the mobile device 150) via the internal peripheral 1340 (rather than between the device 1300 and the machine controller 1360). FIG. 32 illustrates a transition from normal operation to an intercept operation according to some embodiments. Referring to FIG. 32 , an application executing on the mobile device 150 may require access to an electronic peripheral device (e.g., the peripheral 1330) to perform a function requested by a user. For example, the application receives 3202 a user request to process a cash transaction (e.g., to pay for a product or service, to credit an account, or for any of the above reasons). In response to the user request, the mobile device 150 establishes 3204 a connection with the device 1300 (e.g., via the internal peripheral 1340 described above). In some embodiments, as part of the connection process, mobile device 150 sends device 1300 a request to access functionality associated with peripheral device 1330. In some embodiments, as part of the connection process, device 1300 verifies the request, indicating that mobile device 150 has been authorized by a remote server (e.g., server 130) to access signals generated by peripheral device 1330 via the mobile device's communications capabilities (e.g., long-range communications capabilities). Implementation features of the device verification process and the connection process (between mobile device 150 and device 1300) are described in more detail above with reference to FIGS. 7, 8A-8G, 9A-9E, and 23 (including, e.g., security unit 755 and communications unit 770 shown in FIG. 20).

[0210]

[0250] In response to a request to connect to the mobile device 150 and / or access functionality associated with the peripheral device 1330, the device 1300 sends a reset signal (3206) and / or a configure signal (3208) to the peripheral device 1330 to reconfigure the peripheral device 1330 to communicate with the device 1300 (rather than with the machine controller 1360). As described above, the device 1300 reconfigures the peripheral device 1330 to communicate with the device 1300 by resetting the master address (signal destination address) of the peripheral device 1330 to the address of the device 1300. Resetting the master address of the peripheral device 1330 to the address of the device 1300 effectively makes the device 1300 the master of the peripheral device 1330. As a result, the machine controller 1360 is no longer the master of the peripheral device 1330 (see FIG. 30B ). By becoming the master of the peripheral device 1330, the device 1300 appears to be the machine 120. In other words, peripheral 1330 communicates with device 1300 as if it were machine 120 or machine controller 1360 (e.g., peripheral 1330 sends signals to device 1300 rather than to machine controller 1360). For example, upon receipt of a $1 bill, bill collector peripheral 1330 reports receipt of the $1 bill to device 1300 rather than to machine controller 1360. As a result, machine controller 1360 receives no indication that a $1 bill has been deposited into the bill collector of machine 120 and therefore does not proceed with internal vending operations (even though money was deposited into the machine, no product stored in the machine can be purchased or credit can be used to purchase a product). In other words, any signals reporting receipt of the $1 bill at the bill collector are intercepted by the device and not relayed to machine controller 1360. After the reset and / or configuration signal, the device 1300 receives 3210 an acknowledgement from the peripheral 1330 .

[0211]

[0251] Once the signal destination address of the peripheral device 1330 is updated to be the address of the device 1300, the device 1300 continues to poll (3212, 3216) and receive (3214, 3218) acknowledgments from the peripheral device 1330. During this time, polls (3222, 3226) received by the device 1300 from the machine controller 1360 are not relayed to the peripheral device 1330. Instead, the device 1300 simply acknowledges (3224, 3228) the polls to prevent the machine controller 1360 from removing the device 1300 from its list of registered devices. In other words, while device 1300 would normally pass on signals received from machine controller 1360 to peripheral 1330, while performing an intercept operation (as a result of mobile device 150 connecting to device 1300 and device 1300 resetting peripheral 1330), device 1300 still responds to polls received from machine controller 1360 but does not pass on any messages to peripheral 1330. Instead, device 1300 simply acknowledges messages received from machine controller 1360. Thus, device 1300 remains registered with machine controller 1360 and appears to be idle (from the perspective of machine controller 1360). While performing an intercept operation, (i) communication between device 1300 and machine controller 1360 and (ii) communication between device 1300 and peripheral 1330 remain asynchronous. The device 1300 continues to perform the intercept operation until a transition back to normal operation is made (described in more detail below with reference to FIG. 34).

[0212]

[0252] Figure 33 illustrates an intercept operation according to some embodiments. Referring to Figure 33, a payment event (3302) occurs at the peripheral device 1330 (e.g., a $1 bill is deposited into the bill acceptor peripheral device 1330). In response to the next poll (3304) received from the device 1300, the peripheral device 1330 sends a payment receipt signal (3306) to the device 1300 with a message indicating or associated with the payment event (e.g., $1 received). The device 1300 acknowledges (3308) the payment receipt signal and generates (3310) a transaction based on the payment receipt signal. The transaction may include the same message included in the payment receipt signal (e.g., $1 received) and / or an associated message, optionally including additional information (e.g., $1 received and no refund).

[0213]

[0253] The device 1300 sends (3312) the transaction (more specifically, a signal including a message describing or associated with the transaction) to the mobile device 150. The mobile device 150 forwards (3314) the transaction to the server 130 for further processing. The server 130 processes (3316) the transaction. For example, the server 130 adds an amount of funds to the user's account according to the amount of cash deposited as part of the payment event 3302 (e.g., adds $1 to the user's account). As another example, the server 130 transfers an amount of funds to the recipient according to the amount of cash deposited as part of the payment event 3302 (e.g., transfers $1 to the recipient). As another example, the server 130 associates the specified product or service with the user's account according to the requested purchase (e.g., associates a virtual lottery ticket with the user's account in exchange for an amount of funds associated with the amount of cash deposited as part of the payment event 3302).

[0214]

[0254] As a result of processing the transaction, server 130 sends (3318) a notification to mobile device 150 indicating that the payment has been processed and / or the result of the processed payment (e.g., a purchase confirmation or a deposit confirmation). In some implementations, mobile device 150 (more specifically, an application executing on the mobile device) displays information about the received notification (e.g., an alert indicating a successful purchase or deposit, or an updated user interface showing the new account balance).

[0215]

[0255] Returning to the bill collector example, in some embodiments, operations 3302-3312 are repeated each time a bill is inserted into the peripheral device 1330. Optionally, the mobile device 150 groups consecutive transactions (e.g., consecutive $1 insertions) into a single transaction message and transmits the transaction message in operation 3314 for processing by the server 130. Alternatively, the mobile device 150 transmits a transaction message in operation 3314 for processing by the server 130 for each consecutive transaction (e.g., consecutive $1 insertions). In such embodiments, operations 3302-3316 (or operations 3302-3318, or operations 3302-3320) are repeated each time a bill is inserted into the peripheral device 1330.

[0216]

[0256] When the device 1300 performs the intercept operation described above with reference to FIG. 33, the device 1300 responds with acknowledgements (3324, 3328) to polls (3322, 3326) received from the machine controller 1360 so as to maintain registration with the machine controller 1360 as described above with reference to FIG. 32.

[0217]

[0257] FIG. 34 illustrates a transition from intercept operation back to normal operation according to some embodiments. Referring to FIG. 34, the mobile device 150 receives or acquires (3402) an indication (e.g., via user input to an application executing on the mobile device 150) that the mobile device 150 no longer requires access to the peripheral device 1330 (or functionality provided by the peripheral device 1330). For example, the user selects an affordance in the application's user interface indicating that the transaction or deposit is complete (e.g., the user selects the "No" option when asked if they want to purchase more lottery tickets or if they want to deposit more). In response to the access completion notification 3402, the mobile device sends (3404) an access completion notification to the device 1300 indicating that the mobile device 150 no longer requires access to the peripheral device 1330 (or functionality provided by the peripheral device 1330).

[0218]

[0258] In response to receiving the access complete notification, device 1300 sends (3406) a reset signal to peripheral 1330, causing the peripheral to no longer send signals addressed to device 1300. Device 1300 then resets (3416), for example by sending a set signal, the signal destination address of peripheral 1330 to the address of machine controller 1360. As a result, subsequent messages sent by peripheral 1330 to device 1300 are addressed to machine controller 1360. In other words, machine controller 1360 again acts as a master, and device 1300 again acts as a router for messages between machine controller 1360 (master) and peripheral 1330 (slave).

[0219]

[0259] As a result of the peripheral's 1330 signal destination address being reset to the machine controller's 1360 address, the device 1300 begins normal operation as described above with reference to Figures 30A, 31, and 32. For example, the device 1300 acknowledges (3414) a poll received from the machine controller 1360 (3412) and asynchronously polls (3416) the peripheral 1330. The device 1300 receives an acknowledgement (3418) from the peripheral 1330 and relays the message received from the peripheral 1330 to the machine controller 1360.

[0220]

[0260] 35A and 35B illustrate a mobile device 150 with a graphical representation of a mobile application being used as part of a peripheral access system according to some embodiments.

[0221]

[0261] FIG. 35A illustrates an exemplary scenario in which mobile device 150 accesses peripheral 1330 of machine 120 to accept a cash payment for the purchase of a virtual product (e.g., a lottery ticket) unrelated to a product stored in machine 120. In this example, the user's account has a balance of $3, and mobile application user interface 3502 prompts the user to deposit $2 into machine 120 (e.g., after connecting to machine 120 as a result of operation 3204 of FIG. 32) to make a $5 purchase. When the user deposits $2 into machine 120 and the transaction is processed as described above with reference to operations 3302-3320 (FIG. 33), mobile application user interface 3504 notifies the user that the $5 purchase was successful and that the new balance is $0. The notification corresponds to the acknowledgement in operation 3320 (FIG. 33).

[0222]

[0262] FIG. 35B illustrates an exemplary scenario in which mobile device 150 accesses peripheral 1330 of machine 120 to accept a cash payment for deposit into the user's account. In this example, the user's account has a balance of $3, and mobile application user interface 3512 prompts the user to deposit $2 into machine 120 as a result of the user selecting an option to deposit $2 (e.g., after connecting to machine 120 as a result of operation 3204 of FIG. 32). When the user deposits $2 into machine 120 and the transaction is processed as described above with reference to operations 3302-3320 (FIG. 33), mobile application user interface 3514 notifies the user that the $2 deposit was successful and that the new balance is $5. The notification corresponds to the acknowledgement in operation 3320 (FIG. 33).

[0223]

[0263] The embodiments described with reference to Figures 30A through 35B use an illustrative example (e.g., peripheral 1330 is a bill acceptor and peripheral 1330 is accessed to support cash purchases or deposits). Other scenarios may be implemented by providing a mobile application access to electronic peripheral devices of a machine that are otherwise unrelated to the device running the mobile application. For example, a mobile application may access a cash-dispensing peripheral of machine 120 (e.g., a module for processing refunds at vending machine 120, such as using a quarter return slot to dispense quarters or a bill acceptor to dispense one-dollar bills) to support functionality of the mobile application that enables cash to be used by a user (e.g., receiving peer-to-peer cash payments, withdrawing cash from an account, receiving cash refunds for products or services offered by the mobile application, receiving a prize as a result of achievement in a gaming application, receiving a cash payment as a result of winning a virtual lottery ticket, etc.).

[0224]

[0264] Moreover, embodiments need not be limited to scenarios involving cash transactions. Other types of electronic peripheral devices may be accessed by machine 120 to extend the functionality of mobile applications that would otherwise not have direct access to the hardware necessary to support such functionality. In other words, device 1300 enables mobile device 150 to access functionality provided by electronic peripheral device 1300 of machine 120 by providing wireless communication between applications running on mobile device 150 and electronic peripheral device 1330 by (i) communicatively isolating electronic peripheral device 1300 from machine controller 1360, which normally acts as a master for electronic peripheral device 1330, and (ii) communicatively coupling electronic peripheral device 1300 with the mobile application acting as a master for electronic peripheral device 1330 until the mobile application no longer requires access to the functionality provided by electronic peripheral device 1330.

[0225] others

[0265] The foregoing description has been described with reference to specific embodiments. However, the above illustrative discussion is not intended to be exhaustive or to limit the claims to the precise form disclosed. Many variations are possible in light of the above teachings. The embodiments were chosen and described to best explain the principles and practicality of operation and enable others skilled in the art to practice them.

[0226]

[0266] The various figures show elements in a particular order, although elements that are not order-dependent may be rearranged and other elements may be combined or separated. While some rearrangements and other groupings are specifically mentioned, others will be apparent to those skilled in the art, and the ordering and groupings presented herein are not an exhaustive list of alternatives.

[0227]

[0267] As used herein, the singular forms "a," "an," and "the" include the plural unless the context clearly dictates otherwise; the term "and / or" includes all possible combinations of one or more of the associated listed items; the terms "first" and "second" are used only to distinguish one element from another and do not limit the elements themselves; the term "if" may be interpreted to mean "when," "upon," "in response to," or "in accordance with," depending on the context; and the terms "include," "including," "comprise," and "comprising" identify particular features or operations but do not exclude additional features or operations. Finally, as used herein, the terms "master" and "host" are synonymous unless clearly stated to the contrary.

Claims

1. 1. An electronic device for modifying a machine to provide external access to one or more electronic peripheral devices of said machine, comprising: a slave interface coupling said electronic device to a machine controller of said machine via a multi-drop bus (MDB); a host interface coupling the electronic device to a first peripheral device of the one or more electronic peripheral devices of the machine, the first peripheral device communicating via an MDB protocol and isolated from the MDB of the machine; A radio transceiver; one or more processors; a non-transitory memory that stores one or more programs to be executed by the one or more processors; The one or more programs instructions to register the electronic device as a slave of the machine controller; instructions for registering the first peripheral device as a slave of the electronic device; instructions for receiving from a mobile device via the wireless transceiver a request to access a signal generated by the first peripheral device; instructions for validating the request to indicate that the mobile device is authorized by a remote server to access the signal generated by the first peripheral device; and instructions to send a first reset command to the first peripheral device via the host interface, the first reset command including instructions to update a signal destination address of the first peripheral device from a controller address of the machine controller to a device address of the electronic device.

2. the one or more programs further comprising: instructions at the host interface of the electronic device to receive from the first peripheral device a first signal directed to the electronic device according to the updated signal destination address; in response to receiving the first signal from the first peripheral device; sending an acknowledgement to the first peripheral device via the host interface; transmitting a second signal, including data associated with the first signal received from the first peripheral device, to the mobile device via the wireless transceiver for transfer to the server via a long-range communication capability of the mobile device; 10. The electronic device of claim 1, further comprising: instructions to withhold providing the first signal to the machine controller.

3. the one or more programs further comprising: instructions for receiving, via the wireless transceiver, a notification from the mobile device to cease interacting with the mobile device; In response to receiving the notification to stop interacting with the mobile device, and an instruction to send a second reset command to the first peripheral device via the host interface, the second reset command including an instruction to update the signal destination address of the first peripheral device from the device address of the electronic device to the controller address of the machine controller.

4. the one or more programs further comprising: instructions to receive, at the slave interface of the electronic device, a first command from the machine controller directed to the first peripheral device; in response to receiving the first command from the machine controller; sending an acknowledgment to the machine controller via the slave interface as if it had originated from the first peripheral device; and instructions for relaying the first command to the first peripheral device via the host interface.

5. the one or more programs further comprising: instructions at the host interface of the electronic device to receive from the first peripheral device a third signal directed to the machine controller; in response to receiving the third signal from the first peripheral device; sending an acknowledgment to the first peripheral device via the host interface as if it had originated from the machine controller; and instructions to relay the third signal to the machine controller via the slave interface.

6. the instructions to register the electronic device as a slave of the machine controller, instructions for identifying the electronic device to the machine controller as the first peripheral device; and instructions for accepting registration of the electronic device as the first peripheral device.

7. 7. The electronic device of claim 1, wherein the first peripheral device is a coin acceptor, a banknote acceptor, or a payment card reader.

8. 8. The electronic device of claim 1, wherein the machine is a vending machine, a parking meter, a toll booth, a washer or dryer at a laundromat, an arcade game, a kiosk, a photography device, a toll booth, or a transit ticket dispenser.

9. 9. The electronic device of claim 1, wherein the first signal is a payment receipt signal and the second signal is a transmission transaction signal.

10. 10. The electronic device of claim 1, wherein the third signal is a payment receipt signal.

11. 1. A method of modifying a machine to provide external access to one or more electronic peripheral devices of said machine, comprising:

1. An electronic device comprising: a wireless transceiver; one or more processors; a non-transitory memory; a slave interface coupling an electronic device to a machine controller of the machine; and a host interface coupling the electronic device to a first peripheral device of the one or more electronic peripheral devices of the machine, the first peripheral device communicating via an MDB protocol and isolated from the MDB of the machine, registering said electronic device as a slave of said machine controller; registering the first peripheral device as a slave of the electronic device; receiving a request from a mobile device via the wireless transceiver to access a signal generated by the first peripheral device; validating the request to indicate that the mobile device is authorized by a remote server to access the signal generated by the first peripheral device; and sending a first reset command to the first peripheral device via the host interface, the first reset command including instructions to update a signal destination address of the first peripheral device from a controller address of the machine controller to a device address of the electronic device.

12. receiving, at the host interface of the electronic device, from the first peripheral device, a first signal directed to the electronic device according to the updated signal destination address; in response to receiving the first signal from the first peripheral device; sending an acknowledgement to the first peripheral device via the host interface; transmitting a second signal, including data associated with the first signal received from the first peripheral device, to the mobile device via the wireless transceiver for transfer to the server via a long-range communication capability of the mobile device; The method of claim 11 , further comprising withholding the first signal from the machine controller.

13. receiving a notification from the mobile device via the wireless transceiver to stop interacting with the mobile device; In response to receiving the notification to stop interacting with the mobile device, 13. The method of claim 11 or 12, further comprising sending a second reset command to the first peripheral device via the host interface, the second reset command including instructions to update the signal destination address of the first peripheral device from the device address of the electronic device to the controller address of the machine controller.

14. receiving, at the slave interface of the electronic device, a first command from the machine controller directed to the first peripheral device; in response to receiving the first command from the machine controller; sending an acknowledgment to the machine controller via the slave interface as if it had originated from the first peripheral device; 14. The method of claim 11, further comprising relaying the first command to the first peripheral device via the host interface.

15. receiving, at the host interface of the electronic device, a third signal from the first peripheral device, the third signal being directed to the machine controller; in response to receiving the third signal from the first peripheral device; sending an acknowledgment to the first peripheral device via the host interface as if it had originated from the machine controller; 15. The method of any one of claims 11 to 14, further comprising relaying the third signal to the machine controller via the slave interface.

16. registering the electronic device as a slave of the machine controller; identifying the electronic device to the machine controller as the first peripheral device; and 16. The method of claim 11, comprising accepting registration of the electronic device as the first peripheral device.

17. 17. A method according to any one of claims 11 to 16, wherein the first peripheral device is a coin acceptor, a banknote acceptor or a payment card reader.

18. 18. The method of any one of claims 11 to 17, wherein the machine is a vending machine, a parking meter, a toll booth, a washer or dryer at a laundromat, an arcade game, a kiosk, a photography device, a toll booth, or a transit ticket dispenser.

19. 19. The method of any one of claims 11 to 18, wherein the first signal is a payment receipt signal and the second signal is a transmit transaction signal.

20. 20. The method of any one of claims 11 to 19, wherein the third signal is a payment receipt signal.

21. A non-transitory computer-readable storage medium storing one or more programs, when executed by an electronic device comprising: a wireless transceiver; one or more processors; a non-transitory memory; a slave interface coupling an electronic device to a machine controller of the machine; and a host interface coupling the electronic device to a first peripheral device of the one or more electronic peripheral devices of the machine, the first peripheral device communicating via an MDB protocol and isolated from the MDB of the machine, registering said electronic device as a slave of said machine controller; registering the first peripheral device as a slave of the electronic device; receiving a request from a mobile device via the wireless transceiver to access a signal generated by the first peripheral device; validating the request to indicate that the mobile device is authorized by a remote server to access the signal generated by the first peripheral device; and a non-transitory computer-readable storage medium comprising instructions to cause the electronic device to perform operations including sending a first reset command via the host interface to the first peripheral device, the first reset command including instructions to update a signal destination address of the first peripheral device from a controller address of the machine controller to a device address of the electronic device;

22. The instruction: receiving, at the host interface of the electronic device, from the first peripheral device, a first signal directed to the electronic device according to the updated signal destination address; in response to receiving the first signal from the first peripheral device; sending an acknowledgement to the first peripheral device via the host interface; transmitting a second signal, including data associated with the first signal received from the first peripheral device, to the mobile device via the wireless transceiver for transfer to the server via a long-range communication capability of the mobile device; 22. The non-transitory computer-readable storage medium of claim 21, further causing the electronic device to perform operations including withholding providing the first signal to the machine controller.

23. The instruction: receiving a notification from the mobile device via the wireless transceiver to stop interacting with the mobile device; In response to receiving the notification to stop interacting with the mobile device, 23. The non-transitory computer-readable storage medium of claim 21 or 22, further causing the electronic device to perform an operation including sending, via the host interface, a second reset command to the first peripheral device including instructions to update the signal destination address of the first peripheral device from the device address of the electronic device to the controller address of the machine controller.

24. The instruction: receiving, at the slave interface of the electronic device, a first command from the machine controller directed to the first peripheral device; in response to receiving the first command from the machine controller; sending an acknowledgment to the machine controller via the slave interface as if it had originated from the first peripheral device; 24. The non-transitory computer-readable storage medium of claim 21, further causing the electronic device to perform an operation including relaying the first command to the first peripheral device via the host interface.

25. The instruction: receiving, at the host interface of the electronic device, a third signal from the first peripheral device, the third signal being directed to the machine controller; in response to receiving the third signal from the first peripheral device; sending an acknowledgment to the first peripheral device via the host interface as if it had originated from the machine controller; 25. The non-transitory computer-readable storage medium of claim 21, further causing the electronic device to perform an operation including relaying the third signal to the machine controller via the slave interface.

26. the instructions causing the electronic device to perform operations including registering the electronic device as a slave of the machine controller, identifying the electronic device to the machine controller as the first peripheral device; and 26. The non-transitory computer-readable storage medium of claim 21, comprising instructions that cause the electronic device to perform operations including accepting registration of the electronic device as the first peripheral device.

27. 27. The non-transitory computer-readable storage medium of any one of claims 21 to 26, wherein the first peripheral device is a coin acceptor, a banknote acceptor, or a payment card reader.

28. 28. The non-transitory computer-readable storage medium of any one of claims 21 to 27, wherein the machine is a vending machine, a parking meter, a toll booth, a washer or dryer at a laundromat, an arcade game, a kiosk, a photography device, a toll booth, or a transit ticket dispenser.

29. 29. The non-transitory computer-readable storage medium of any one of claims 21 to 28, wherein the first signal is a payment receipt signal and the second signal is a transmission transaction signal.

30. 30. The non-transitory computer-readable storage medium of any one of claims 21 to 29, wherein the third signal is a payment receipt signal.

Images