Patent Grant
11935051
The present application relates to the field of electronic peripheral devices, and in particular, to a system for providing access to an electronic peripheral device over a non-persistent network connection.
Master/slave technology uses a model of dualistic communication where one device or process (the master) has control over one or more other devices (the slave(s)), sometimes referred to as peripheral devices.
Peripheral devices are often disposed at the functional interface between various internal components of a machine and a user of those components, thereby enabling human/machine interaction. While some types of peripheral devices may be removed and replaced (e.g., a Universal Serial Bus (USB) mouse or keyboard) or accessed by outside devices (e.g., a wireless printer), other types of peripheral devices, such as a bill acceptor or card reader, may be embedded in a machine and dependent on aspects of the machine (such as the machine's power supply, processing system, and physical housing) to operate.
As the number of people with Internet-connected mobile devices proliferates, so does the variety of uses for such devices. Some uses may be enhanced or even require certain types of peripheral devices which have traditionally only been accessible in embedded systems which do not necessarily provide access to outside devices.
Disclosed herein is a system for providing external access to electronic peripheral devices disposed in a machine. The system enables an external device to access functionality provided by an electronic peripheral device of a machine by providing wireless communications between a mobile application and the electronic peripheral device. In order to provide this access, the system (i) communicatively decouples the electronic peripheral device from a machine controller which normally would function as the master of the electronic peripheral device, and (ii) communicatively couples the electronic peripheral device with the mobile application which functions as the master of the electronic peripheral device until the mobile application no longer requires access to the functionality provided by the electronic peripheral device.
Like reference numerals refer to corresponding parts throughout the several views of the drawings.
Disclosed herein is a payment processing system or, more specifically, a mobile-device-to-machine payment processing system for processing transactions over a non-persistent network connection. The mobile-device-to-machine payment processing system disclosed herein focuses on the unattended retail space (e.g., a payment accepting unit 120, sometimes also herein called a “machine 120”). More specifically, the mobile-device-to-machine payment processing system disclosed herein allows a user (having a mobile device 150 with a mobile application 140 thereon) to make a cashless purchase from a payment accepting unit 120 (having an adapter module 100 associated therewith).
The mobile-device-to-machine payment processing system described herein can be implemented with one or more of the following features: easy installation feature, a non-persistent network connection feature; a manual (swipe to pay) mode feature; a hands-free mode feature; and a multiple vending transactions (multi-vend) feature.
Easy Installation: Installation is very easy, requires no tools, requires no configuration, and takes as little as 30 seconds. This is accomplished by using an adapter module 100 (sometimes also herein called “payment module 100”) such as an in-line dongle (a hardware device with software thereon) design for in-line insertion within a multi-drop bus (MDB) of a payment accepting unit 120 (e.g., a vending machine) (sometimes also herein called ‘the machine 120”). Installation is as simple as “powering down” (turning off) the machine 120, identifying the “wire” that connects with a payment receiving mechanism (e.g., the coin mechanism), disconnecting the wire (so that there are two loose ends, such as a male connection end or adapter of an MDB and a female connection end or adapter of an MDB), plugging (inserting) the adapter module 100 in serial (“in-line”) with the wire (e.g., connecting the MDB female adapter to a male adapter of the adapter module 100 and connecting the MDB male adapter to a female adapter of the adapter module 100), tucking the wire and the installed adapter module 100 back into position, and “powering up” (turning on) the machine 120. Most vending machines made since 1995 have this industry standard MDB technology that would allow this easy 30-second installation. On machines without MDB technology, the adapter module 100 can be configured or designed to work with other serial protocols or activate a switch. In essence the adapter module 100 simulates establishing payment on payment accepting unit 120 in much the same manner as other alternative forms of payment (e.g., cash).
Non-persistent Network Connection: Although payment accepting units (or “machines”) that accept only cash (e.g., paper currency and coins) may not require a connection (persistent or non-persistent) to a network, traditional payment accepting units that accept cashless payments (e.g., credit cards, debit cards, and alternative mobile device payment methods using, for example, smart phones) require a persistent connection to a network (wired or wireless) to facilitate the cashless payments. In other words, without a persistent (ongoing or accessible on demand) network connection, traditional payment accepting units cannot accept cashless payments. Most traditional payment accepting units that accept cashless payments include the technology to accomplish this persistent network connection that allows them to connect to a remote server. If the network connection to a traditional machine is temporarily interrupted, cashless payments will be temporarily unavailable. If the machine is located in a location where no network connection is available, cashless payments is not possible. In addition to using a mobile device 150 as an intermediary between the payment accepting units 120 and the server 130, the mobile-device-to-machine payment processing system described herein minimizes (i.e., the manual mode) or eliminates (i.e., the hands-free mode) user interaction with the mobile device 150. Further, in some implementations, the mobile-device-to-machine payment processing system described herein facilitates the acceptance of cashless payments without requiring any network connection near the payment accepting unit 120. In some implementations, when the mobile-device-to-machine payment processing system described herein is located in a remote location where network connection is unavailable, the mobile-device-to-machine payment processing system, therefore, can still accept cashless payments.
Manual (Swipe-to-Pay) Mode: Using a “swipe-to-pay” feature (or just “swipe”) refers to a user's action implemented on his/her mobile device 150 where he/she quickly brushes his/her finger (or other pre-determined interaction) on the mobile device's touch screen 152 (
Hands-Free Mode: A “hands-free pay” feature (or just “hands-free”) would most likely be used with “favorite” payment accepting units 120 (e.g., a frequently used vending machine at a user's work or school). From the user's perspective, he/she would approach the favorite payment accepting unit 120 and notice that the display 122, 124 (
Multiple Vending Transactions (Multi-Vend): Both the manual and hands-free modes could be used multiple times in sequence (implemented, for example, as a loop) so that a user may make multiple purchases. After making his/her first selection and receiving his product (or service), the user would observe that additional funds were available on the display 122, 124 (
The features described above, alone or in combination with other features described herein will revolutionize the hundred billion dollar automated retail industry. The hardware is very low cost and there are no reoccurring fees because no cellular connection is required on the machine 120. Using the mobile-device-to-machine payment processing system described herein, operators of machines 120 can increase frequency of visits by purchasers and items sold with each visit.
The mobile-device-to-machine payment processing system described herein may be implemented as an apparatus, system, and/or method for enabling payments to a machine 120 via a mobile device 150. The mobile-device-to-machine payment processing system may be better understood with reference to the drawings, but the shown mobile-device-to-machine payment processing system is not intended to be of a limiting nature.
Before describing the mobile-device-to-machine payment processing system and the figures, some of the terminology should be clarified. Please note that the terms and phrases may have additional definitions and/or examples throughout the specification. Where otherwise not specifically defined, words, phrases, and acronyms are given their ordinary meaning in the art. The following paragraphs provide some of the definitions for terms and phrases used herein.
Adapter Module 100: As shown in
Mobile Device 150 and Application 140 (also referred to as a “mobile application,” “mobile app,” or “app”): In general, a mobile device 150 may be a user's personal mobile device 150. The mobile device 150 (with a mobile application 140 thereon) acts as a communication bridge between the adapter module 100 (associated with a payment accepting unit 120) and the server 130. The mobile device 150 and the application 140, however, are not “trusted” in that the communications (transmissions) it passes are encrypted. Encrypted (secured) communications are undecipherable (unencryptable, unreadable, and/or unusable) by the mobile device 150. This keeps the communications passed between the adapter module 100 and the server 130 secured and safe from hacking. Mobile devices include, but are not limited to smart phones, tablet or laptop computers, or personal digital assistants (PDAs), smart cards, or other technology (e.g., a hardware-software combination) known or yet to be discovered that has structure and/or capabilities similar to the mobile devices described herein. The mobile device 150 preferably has an application (e.g., the application 140) running on it. The term “app” is used broadly to include any software program(s) capable of implementing the features described herein.
Payment Accepting Unit 120 (or Machine 120): A payment accepting unit 120 (or the machine 120) is equipment that requires payment for the dispensing of an product and/or service. Payment accepting units 120 may be vending machines, parking meters, toll booths, laundromat washers and dryers, arcade games, kiosks, photo booths, toll booths, transit ticket dispensing machines, 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 (paper currency and coins)) by accepting payment from, for example, credit cards, debit cards, and mobile devices.
Network Connections: For purposes of this discussion, a persistent network connection is a wired or wireless communications 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 for the machine to make a temporary connection to a server or the ability for the user to contact a server from his mobile device). Typically the persistent network connection has been conducted over “long-range communication technology” or “long-range communication protocol” (e.g., hardwired, telephone network technology, cellular technology (e.g., GSM, CDMA, or the like), Wi-Fi technology, wide area network (WAN), local area network (LAN), or any wired or wireless communication technology over the Internet that is known or yet to be discovered). Traditionally, machines that accept payment other than cash require a persistent (ongoing or accessible on demand) connection to a network to facilitate payment. This is true for machines that accept, for example, credit cards and debit cards. The payment accepting units 120 described herein do not require a traditional persistent network connection. The user's mobile device 150 acts as a communication bridge between the adapter module 100 and the server 130. Communications between user mobile devices 150 and the servers (e.g., a system management server 130 and/or a funding source server 160) take place using long-range communication technology. Communications between user mobile devices 150 and the adapter module 100 of the payment accepting unit 120 take place using “short-range communication technology” or “short-range communication protocol” (e.g., Bluetooth (such as Bluetooth 4.0, Bluetooth Smart, Bluetooth Low Energy (BLE)), near-field communication (NFC), Ultra Wideband (UWB), radio frequency identification (RFID), infrared wireless, induction wireless, or any wired or wireless technology that could be used to communicate a small distance (approximately a hundred feet or closer) that is known or yet to be discovered). Therefore, neither the adapter module 100 nor the payment accepting unit 120 requires a traditional persistent long-range wireless network connection. The communications technology shown in the figures may be replaced with alternative like communications technology and, therefore, specific shown communications technologies are not meant to be limiting. For example, Wi-Fi technology could be replaced with another long-range communication technology.
Server: A server is the host processing server that may be operated by the company running the payment processing system. For each user, the server 130 preferably maintains at least one “virtual wallet” having at least one “balance” (which can be $0) of designated funds for which the server 130 keeps an accounting. The balance may represent, for example, “cash” or it may be a “promotional value” that represents funds that may be spent under certain circumstances. If these funds begin to be depleted, the user may be notified (e.g., via the application 140 on the mobile device 150) that additional funds need to be designated and/or transferred. Alternatively, funds from other sources (e.g., the funding source server 160) may be automatically transferred to restore a predetermined balance. The balance may also be increased based on a promotion (e.g., points earned or coupons). As shown in
Advertise Presence: Each adapter module 100 advertises its presence by broadcasting signals (advertising broadcast signals) to mobile devices in the zones 102, 104, 106. Each adapter module 100 can listen to other adapter modules' advertisements.
Received Signal Strength Indicator (RSSI): The adapter module 100 may have a self-calibrating signal strength to determine zone thresholds (e.g., a payment zone threshold and an authentication zone threshold). At the time the user selects an item (product or service) from the payment accepting unit 120, the Received Signal Strength Indicator (RSSI) is logged. At this moment, it is presumed the user is within “arm's-length” (which may be a predetermined length approximating the distance of a user standing in front of a machine for the purpose of making a purchase) from the payment accepting unit 120. A mathematical computation (i.e., In-Range Heuristics) is conducted to derive the optimal RSSI threshold at which point payment should be triggered by an application 140 on a mobile device 150. The threshold may be payment accepting unit specific and can vary over a period of time. This optimal zone threshold is preferably reported to the mobile device 150 during an initial handshake.
In-Range Heuristics: A mathematical computation that determines the RSSI threshold to determine when a user is in the authorization zone 104 and/or the payment zone 102. This computation can take into consideration numerous historical data points as well as transaction specific information such as which the mobile device 150 is being used, payment accepting unit type, among other factors. Preferably the RSSI is logged while the user is making his selection (this is the one time in the entire process that the user definitely will be “in range” (e.g., they will be arm's length from the machine 120 because they are physically interacting with the machine 120). The type of user mobile device 150, accelerometer data (e.g., is the user moving or stationary), and/or other information may also be logged while the user is making his selection. The adapter module 100 can give a reference RSSI for the payment zone 102 for the machine 120, and the application 140 can make a +/− adjustment based on the specific mobile device 150 on which it is installed. Over a period of time, the payment processing system continues to improve itself based on additional data points.
Authorization Request (“AuthRequest:): When a user enters the authorization zone 104, the mobile device 150 notifies the adapter module 100 and the adapter module 100 sends a secured authorization request (e.g., the encrypted authorization request) as a “message” (also referred to as a communication or transmissions) to the server 130 via the mobile device 150. Encryption may be performed by a security unit 755 (
Authorization Grant Token (“AuthGrant”): This is a “message” (also referred to as a communication or transmissions) encrypted by the security unit 955 (
Synchronization: Time may be synchronized to the adapter module 100 from the server 130. The server 130 sends time information with encrypted messages and the adapter module 100 uses the time encoded in the messages for synchronization.
The mobile-device-to-machine payment processing system and components thereof may have associated hardware, software, and/or firmware (a variation, subset, or hybrid of hardware and/or software). The term “hardware” includes at least one “processing unit,” “processor,” “computer,” “programmable apparatus,” and/or other known or yet to be discovered technology capable of executing instructions or steps (shown as the processing unit 750 in
It should be noted that the terms “programs” and “subprograms” 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 onto a computer to produce a “machine,” such that the instructions that execute on the computer create structures for implementing the functions described herein or shown in the figures. Further, these programs and subprograms may be loaded onto a computer so that they can direct the computer to function in a particular manner, such that the instructions produce an article of manufacture including instruction structures that implement the function specified in the flow chart block or blocks. The programs and subprograms may also be loaded onto a computer to cause a series of operational steps to be performed on or by the computer to produce a computer implemented process such that the instructions that execute on the computer provide steps for implementing the functions specified in the flow chart block or blocks. The phrase “loaded onto a computer” also includes being loaded into the memory of the computer or a memory associated with or accessible by the computer. Separate, albeit interacting, programs and subprograms may be associated with the adapter modules 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.
The terms “messages,” “communications,” “signals,” and/or “transmissions” include various types of information and/or instructions including, but not limited to, data, commands, bits, symbols, voltages, currents, electromagnetic waves, magnetic fields or particles, optical fields or particles, and/or any combination thereof. Appropriate technology may be used to implement the “communications,” “signals,” and/or “transmissions” including, for example, transmitters, receivers, and transceivers. “Communications,” “signals,” and/or “transmissions” described herein would use appropriate technology for their intended purpose. For example, hard-wired communications (e.g., wired serial communications) would use technology appropriate for hard-wired communications, short-range communications (e.g., Bluetooth) would use technology appropriate for close communications, and long-range communications (e.g., GSM, CDMA, Wi-Fi, or the like) would use technology appropriate for remote communications over a distance. Appropriate security (e.g., SSL or TLS) for each type of communication is included herein. The security units 755 and 955 include technology for securing messages. The security technology may be, for example, encryption/decryption technology (e.g., software or hardware). Although encryption/decryption is discussed primarily as being performed using a unique private key, alternative strategies include, but are not limited to encryption/decryption performed using public/private keys (i.e., asymmetric cryptography), or other encryption/decryption strategies known or yet to be discovered. Appropriate input mechanisms and/or output mechanisms, even if not specifically described, are considered to be part of the technology described herein. The communications unit 770 (shown in
When used in relation to “communications,” “signals,” and/or “transmissions,” the terms “provide” and “providing” (and variations thereof) are meant to include standard means of provision including “transmit” and “transmitting,” but can also be used for non-traditional provisions as long as the “communications,” “signals,” and/or “transmissions” are “received” (that can also mean obtained). The terms “transmit” and “transmitting” (and variations thereof) are meant to include standard means of transmission, but can also be used for non-traditional transmissions as long as the “communications,” “signals,” and/or “transmissions” are “sent.” The terms “receive” and “receiving” (and variations thereof) are meant to include standard means of reception, but can also be used for non-traditional methods of obtaining as long as the “communications,” “signals,” and/or “transmissions” are “obtained.”
The term “associated” is defined to mean integral or original, retrofitted, attached, connected (including functionally connected), positioned near, and/or accessible by. For example, if the user interface (e.g., a traditional display 122 (
As shown, the adapter module 100 functionally connected bi-directionally to the payment accepting unit 120 via a wired serial connection such that no security is necessary. The adapter module 100 is also functionally connected bi-directionally to the mobile device 150 (and its installed mobile application 140) via short-range communication technology (e.g., a Bluetooth connection). Because the mobile device 150 is not a “trusted” link (e.g., it could be hacked by a user), only secured communications (transmissions) are passed between the adapter module 100 and the mobile device 150. This keeps communications secured and safe from hacking. The mobile device 150 (and its installed mobile application 140) is also functionally connected bi-directionally to a system management server 130 and/or a funding source server 160 via long-range communication technology (e.g., Wi-Fi or Cellular connection) that preferably has appropriate security (e.g., SSL security). Security between the mobile device 150 and the system management server 130 has the advantage of protecting communications from the mobile device 150 to the system management server 130 that may include sensitive data and may not be encrypted. The system management server 130 and the funding source server 160 may be connected via a wired Internet connection with SSL security. The system management server 130 may be connected via a wired Internet connection with SSL security to an operators' server 170. Although not necessary to implement a purchase transaction, for other purposes (e.g., inventory), the operators' server 170 may be connected to the payment accepting unit 120 using a handheld computer sync or a cellular connection.
Also, a unique private key may be used to securely transmit encrypted messages between the adapter module 100 and the system management server 130 (although the encrypted transmissions would most likely be routed through the mobile device 150). The server 130 stores a private key for each adapter module 100, and this key is only known to the adapter module 100 and the server 130. No intermediary is privy to this key (especially not the mobile device 150). 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 with 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 is able to 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 messages to the adapter module 100 and sends the message to the mobile device 150 to relay to the adapter module 100 that is able to decrypt the message using the security unit 755 of the adapter module 100 and the unique private key.
It should be noted that
The shown adapter modules 100 are preferably designed to be used as an in-line dongle for in-line insertion within, for example, a MDB of a machine 120. The wire used in MDB technology uses male and female connection ends or adapters to allow the attachment of peripherals. In the case of a vending machine, the wire with the connection ends or adapters would be present to allow the attachment of a payment receiving mechanism (e.g., a coin mechanism). The MDB male and female adapters 700, 710 may be separated (as shown in
Summarily, if it is available, a hands-free mode, from the user's perspective, would allow the user to approach a favorite payment accepting unit 120 and notice that the display (e.g., the displays 122 or 124 shown in
During an initial handshake with the mobile device 150 (when the user is within range), the adapter module 100 reports to the mobile device 150 whether or not hands-free mode is available. If it is available, the installed mobile application 140 automatically connects to the payment accepting unit 120 without the user having to interact with the mobile device 150. The user observes that funds are available on the display 122, 124 of the payment accepting unit 120 and completes the purchase transaction as if cash was inserted in the machine 120 by inputting his selection on the payment accepting unit 120. The payment accepting unit 120 dispenses the product or service. After the selection is made, the change is returned to the mobile device 150.
Whether hands-free payment is available is determined by factors including, but not limited to whether if other mobile devices 150 are in range, if other adapter modules 100 are in range, if there are any alerts, if the payment trigger threshold is having wide variances and so deemed unstable, or if the payment accepting unit operator (e.g., a vending machine operator) has opted to disable hands-free mode for the payment accepting unit 120. In the latter instance, operators can disable via a maintenance mobile device 150, as well as through the operators' server 170 and/or the system management server 130.
Balance Display: An optional feature of the mobile-device-to-machine payment system that is particularly helpful in the hands-free mode (although it may be available in the manual mode and/or in a multiple-vend scenarios) is when the user's mobile device 150 sends “credit” to the payment accepting unit 120 (either via hands-free payment or through a manual swipe), the wallet balance is sent to the payment accepting unit 120 that is then displayed to the user on a display 122, 124 of the machine 120. This is particularly beneficial during hands-free mode when the user does not retrieve the mobile device 150 and, therefore, may not know the balance. Also, in a multiple-vend scenario the user would not have to calculate a remaining balance.
An example of a hands-free, multiple-vend scenario where a balance is displayed by the payment accepting unit 120, follows: The user has $5.00 in his/her virtual wallet as that is the amount that has been authorized (the AuthGrant being stored on the mobile device 150). The user walks up to the payment accepting unit 120 and $5.00 is displayed on the display 122, 124 of the payment accepting unit 120 since hands-free mode was enabled and credit was sent (e.g., via the short-range communication capability) to the payment accepting unit 120. The user makes a selection of $1.50 by interacting (e.g., pressing buttons) with the machine 120. The item (product or service) is dispensed and the “change” is “returned” (e.g., via the short-range communication capability) to the virtual wallet. But since the user is still standing in 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 now see that he/she has a $3.50 balance. (It should be noted that the authorized funds may remain on the machine 120 and not be transferred back to the mobile device 150 between transactions.) The user decides to purchase a $1.50 item, and the transaction is completed as usual (e.g., by interacting with the machine 120). Now the user is still standing in the payment zone 102 and he/she sees the wallet balance of $2.00 on the display 122, 124 of the payment accepting unit 120. The user decides that he/she does not wish to purchase anything else and simply walks away. As he/she walks out of the payment zone 102, the credit is cleared from the machine 120, but he/she is left with the knowledge that his wallet balance is $2.00 even though he/she never touched the mobile device 150. Communications between the payment accepting unit 120 and the adapter module 100 (via the mobile device 150) handle the accounting incidental to the transaction. The remaining balance ($2.00) is technically stored on the server 130, and may be reflected on the application 140 on the mobile device 150.
As shown in
Bluetooth Range 106 (sometimes also herein called the “communication zone”): The outermost range is the Bluetooth range 106 (shown in
Authorization Zone 104: The middle region is the authorization zone 104 (shown in
An authorization occurs in preparation for when the user enters the payment zone 102 (shown in
Payment Zone 102: As a user enters the payment zone 102, the mobile device 150 establishes exclusive control of the adapter module 100. Once established, any other user in the payment zone 102 is put into a “waiting” status.
In the payment zone 102, the payment can be triggered automatically if the payment processing system has and is in hands-free mode. In such instances, the mobile device 150 is running the application 140 in background mode and will send credit to the payment accepting unit 120 without any explicit user interaction. The user completes the transaction on the payment accepting unit 120 in much the same manner as if cash had been inserted into the payment accepting unit 120 to establish credit. After the user completes the transaction (that may include one or more purchases), details of the transaction are preferably returned to the mobile device 150 and server 130 in separate messages. The message to the server 130 is preferably encrypted with the adapter module's 100 private key (
The other mode of operation is manual mode. In manual mode, the user launches the mobile device 150 and is able to swipe to send payment to the payment accepting unit 120. The user can also swipe back to cancel the payment. Like in hands-free mode, the purchase transaction is completed on the payment accepting unit 120 in the same manner as if cash were inserted into the payment accepting unit 120. The mobile device 150 is only used to send payment. Selection is made directly on the payment accepting unit 120.
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 machine to machine, environment to environment, and device to device, having a fixed threshold at which payment is triggered can be problematic. The approach suggested herein is the creation of a self-calibrating threshold. When the user is interacting with the payment accepting unit 120 (such as when he makes his selection on the payment accepting unit 120), the payment accepting unit 120 notifies the adapter module 100 and the adapter module 100 logs the conditions such as RSSI, type of user mobile device 150, accelerometer data, and other information. It is at this point that it can be ascertained safely that the user is within arm's-length from the payment accepting unit 120 (by necessity the user is arm's-length because he is making some physical interaction with the payment accepting unit 120). This is the only point in the entire transaction in which it can be certain that the user is within arm's-length from the payment accepting unit 120.
Optionally, during the handshake between the mobile device 150 and the adapter module 100, the information transmitted to the adapter module 100 may include, for example, the model of the mobile device 150. Using the received information pertaining to the mobile device models, the adapter module 100 can create multiple payment thresholds, one for each mobile device model. This allows for variances that may be inherent in different types of Bluetooth radios. An alternative to this method is for the adapter module 100 to broadcast a baseline payment zone threshold, and the mobile device 150 can use an offset from this baseline based on its specific model type. The payment zone thresholds (or baseline offsets) can be unique to specific types of mobile devices (e.g., by manufacturer, operating system, or component parts), models of mobile devices, or individual mobile devices (unique to each user).
In a typical scenario in which the payment zone threshold has been calibrated, the adapter module 100 advertises its presence along with the threshold at which it considers any mobile device 150 to be in the authorization zone 104. This is a one-way communication from adapter module 100 to mobile device 150. Once the mobile device 150 enters the authorization zone 104, there is a handshake that is 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 threshold for that specific model.
Optionally, in addition to calibrating the payment zone threshold, the adapter module 100 can apply the self-calibrating model to the authorization zone 104 to calibrate the authorization zone threshold. As with the payment zone thresholds, the authorization zone thresholds can be unique to specific types of mobile devices, models of mobile devices, or individual mobile devices. In this scenario, the adapter module 100 would broadcast multiple thresholds by device type and the mobile device 150 would determine which threshold to apply (or alternatively broadcast a baseline and the mobile device 150 uses an offset based on its device model). Even in this scenario, the authorization zone 104 is a one-way communication.
Optionally, along with the threshold that is calculated (in the payment and/or the authorization zone(s)), a safety margin can be added to minimize scenarios in which a user is within range, but the mobile-device-to-machine payment processing system does not recognize it because the threshold may not have been reached. For example, if the calculated RSSI for an iPhone™ 5 on machine 4567 is −68 db, the mobile-device-to-machine payment processing system may add a safety margin of −5 db, and establish the threshold at −73 db. So when a user's phone is communicating with the adapter module 100 at an RSSI of −73 db or better, the mobile-device-to-machine payment processing system will allow the mobile device 150 to credit the payment accepting unit 120. The safety margin can be set on the server 130 and downloaded to the adapter module 100, or set on the mobile device 150, or set on the adapter module 100 itself.
Optionally, in the payment zone threshold, the mobile device 150 can use other data to determine when to cancel the exclusive control of the payment accepting unit 120, to identify when the user is moving out of the payment zone 102. External data could include accelerometer data from the mobile device 150. Using that data, the mobile device 150 can determine whether the user is standing relatively still in front of the payment accepting unit 120, or if the user is in motion—effectively walking away from the payment accepting unit 120.
The mobile-device-to-machine payment processing system described herein uses a mobile device's 150 short-range communication technology (e.g., Bluetooth mechanisms) (shown as short-range communication capability 876 in
One option if there is no cellular or Wi-Fi coverage within the payment zone 102 is to determine whether there is cellular or Wi-Fi coverage within the authorization zone 104 or the Bluetooth range 106. If there is, then the sizes of the zones 102, 104, 106 could be adapted and the timing could be adapted. For example, if the mobile devices 150 detected problems with the cellular or Wi-Fi coverage within the payment zone 102, the user could carry his mobile device 150 into the other zones (or the mobile device 150 could use short-range communication technology to communicate with other mobile devices 150 within the authorization zone 104 or the Bluetooth range 106) to determine whether the zones have cellular or Wi-Fi coverage. If they do have coverage, communication between the mobile device 150 and the server 130 can be advanced (conducted earlier when the mobile device 150 is further from the machine 120) or delayed (conducted later when the mobile device 150 is further from the machine 120). This can be thought of as changing the size or shapes of the zones 102, 104, 106. The timing would also have to be adjusted so that the authorization of funds (AuthGrant) does not expire before the user has a chance to make a purchase. It also means that balance updates to the server 130 may happen after the user has moved away from the machine 120 and has cellular or Wi-Fi coverage again.
Another option if there is no cellular or Wi-Fi coverage within any of the zones 102, 104, 106 is for the user to obtain authorization while outside of the zones in a place with cellular or Wi-Fi coverage. This may occur, for example, if a user knows that he will be going to a place with a payment accepting unit 120 equipped with an adapter module 100 (perhaps to a favorite payment accepting unit 120) that does not have (or rarely has) cellular or Wi-Fi coverage. A user may also use the mobile application 140 to query payment accepting units 120 in 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 zones 102, 104, 106. The user can then obtain pre-authorization from the server 130 using the mobile application 140. Again, the timing would also have to be adjusted so that the authorization of funds (AuthGrant) does not expire before the user has a chance to make a purchase. It also means that balance updates to the server 130 may happen after the user has moved away from the machine 120 and has cellular or Wi-Fi coverage again. A mobile-device-to-machine payment system having the ability to implement this option would be able to accept cashless payments without requiring any network connection near the payment accepting unit 120. In some implementations, the mobile-device-to-machine payment processing systems described herein is located in a remote location where no signal is available, therefore, can accept cashless payments.
As an example of a situation in which there might be no cellular or Wi-Fi coverage within any of the zones 102, 104, 106 of a particular payment accepting unit 120, the user (a teenager) may be traveling to a remote location to attend summer camp where there is no cellular or Wi-Fi coverage. The camp may have several payment accepting units 120 (e.g., a machine that creates a dedicated “hot spot” that requires payment for use, vending machines, or machines for renting equipment such as bikes, kayaks, or basketballs). The camp facility might notify parents that the mobile-device-to-machine payment system is available. The parents, while at home, could obtain authorization for a particular amount (that could be doled out a certain amount per day or limited to type of machine or location) to be authorized and “loaded” into the user's mobile device 150 and specify that the authorization will not expire for a certain period or until a certain date. Thereafter, while at camp, the user could use the mobile application 140 on his mobile device 150 in a manner similar to those discussed elsewhere herein. Short-range communications may be used for communications between the adapter modules 100 (associated with the machines 120) and users' mobile devices 150.
One subtle but powerful component of the payment processing system described herein is that it requires a long-range communication capability (e.g., an Internet or cellular network connection) only in the authorization zone 104 and only for the time period required to send the AuthRequest and receive the AuthGrant. Once a valid AuthGrant is received by the mobile device 150, the long-range communication capability (e.g., an Internet or cellular network connection) is not required by either the mobile device 150 or the adapter module 100 in the payment zone 102 as long as the AuthGrant is valid (unexpired). This mechanism allows the system to seamlessly handle authenticated transactions in (temporary) offline mode, with the deferred acknowledgement and transaction messages performing the bookkeeping and cleanup when network connection is regained. The alternatives described above provide a unique way to artificially extend the authorization zone to include any location where the mobile device 150 can communicate with the server 130.
As shown in
Users 4 and 7 are within the Bluetooth range 106 and the user 10 is either entering or leaving the Bluetooth range 106. Within the Bluetooth range 106 the users' mobile devices 150 are able to see the adapter module's 100 advertisement. In this zone, the mobile device 150 preferably does not initiate a connection. The adapter module 100 is preferably unaware of the users in the Bluetooth range 106. All the adapter module 100 is doing is advertising its presence to any multitude of users that may be in Bluetooth range 106.
The adapter module 100 begins to log users as the users (and their respective mobile devices 150) enter the authorization zone 104 (shown in
If there is only one user in the payment zone 102, a purchase transaction may be performed. If there are multiple users in the payment zone 102, the mobile-device-to-machine payment system must handle the situation.
One optional solution for handling the situation of the multiple users in the payment zone 102 is queuing users in the payment zone 102. Once any mobile device 150 enters the payment zone 102, it establishes exclusivity to a particular mobile device 150 (e.g., in a first-come-first-serve manner). Technically, however, the adapter module 100 is not establishing an exclusive connection to the mobile device 150. The adapter module 100 can still perform a round-robin poll 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 was first and whether the authorization has expired) and it notifies (e.g., alerts) other mobile devices 150 to wait. The earliest valid (unexpired) authorization takes precedence when there is any tie in the RSSI. Otherwise, for example, the strongest average RSSI takes priority. Preferably the queue is not a static measure of the RSSI but an averaged measure over the period of time in the queue. This compensates for a scenario in which a user may be walking around in the queue and then shows up at the payment accepting unit 120 just as the previous user is finishing. If another user was also in the payment zone 102 and stood there the entire time, but may have newer authorization, he could win out.
Anytime that the adapter module 100 cannot determine exactly which user is in the payment zone 102 in front of the payment accepting unit 120, the adapter module 100 will disable hands-free payment. The mobile device 150 will send an alert to the user and he can use swipe to pay (manual mode). All users in payment zone 102 will show “Connected” and the first to swipe payment to the payment accepting unit 120 then locks out other users.
In the scenario where there are multiple modules present, determining which payment accepting unit 120 a user is in front of can be a challenge. In some implementations, the mobile-device-to-machine payment processing system described herein allows adapter modules 100 to communicate to other adapter modules 100 in range via Bluetooth. Each user receives authorization grants for specific payment accepting units 120. This means if there are multiple adapter modules 100 within the same authorization zone 104, there will be multiple authorization grants for the user. When the user enters the payment zone 102, it can be difficult to differentiate which payment accepting unit 120 the user is in front of if the payment zones 102 overlap.
To solve this problem, when the user enters the payment zone 102, the adapter modules 100 communicate with each other to determine the RSSI for the particular user (based on the signal from his mobile device 150) to triangulate which adapter module 100 (and the associated payment accepting unit 120) is closer to the user. Optionally, the inter-module communications can restrict the user to establishing an exclusive connection with only one payment accepting unit 120.
Optionally, when the user connects to a payment accepting unit 120, the mobile device 150 can send a communication to the payment accepting unit 120 for momentary display to the user on the display 122, 124 of the payment accepting unit 120. For example, the mobile device 150 can send a communication (e.g., “connected” or “Fred's Mobile Device Connected”) to the payment accepting unit's display 122, 124 for a predetermined period of time (e.g., 1-3 seconds) so when the user is in payment zone 102, it is clear which payment accepting unit 120 the user is connected to prior to making a purchase (either in hands-free or manual mode).
In addition, when the user is in manual mode, the mobile device 150 can display (e.g., on the touch screen 152 as shown in
Prior to vending transactions, a user downloads a mobile application 140 onto his mobile device 150, creates an account, and configures a funding source via, for example, a funding source server 160. A funding source may be, for example, a debit card, a credit card, campus cards, rewards points, bank accounts, payment services (e.g., PayPal™) or other payment option or combination of payment options known or yet to be discovered. The funding sources may be traditional and/or nontraditional payment sources that are integrated into the ecosystem described herein and then used indirectly as a source of funds. Funds from the funding source are preferably held on the server 130 such that when an AuthRequest is received by the server 130, the server 130 can send an AuthGrant authorizing funds for a purchase.
The user can specify one or more “favorite” adapter module(s) 100 (that has a one-to-one relationship to the payment accepting unit 120) that he may visit regularly, such as a vending machine at school or work. Favorite adapter modules 100 appear on a pre-filtered list and allow for additional rich features such as hands-free payment.
The payment accepting unit 120 may be equipped with an adapter module 100 that is constantly advertising its availability via Bluetooth (or other “signals,” “communications,” and/or “transmissions”). This ongoing advertising and scanning for adapter modules is shown in
As the user approaches a specific adapter module 100, the user enters the payment zone 102 and an event threshold is triggered based on heuristics performed by the mobile device 150. Blocks 310 and 312 show the loop steps of waiting for a mobile device 150 from the authorization zone 104 to enter the payment zone 102. If the user leaves the authorization zone 104 without entering the payment zone 102, the adapter module 100 returns to advertising its presence (block 300).
Several of the figures are flow charts (e.g.,
The payment module 100 broadcasts (1002), via a short-range communication capability (e.g., BLE), a packet of information (sometimes also herein called “advertised information”). The packet of information at least includes an authorization code and an identifier associated with the payment module 100 (module ID). In some implementations, the packet of information further includes a 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. The information included in the packet broadcast by the payment module 100 is further discussed below with reference to
In some implementations, the payment module 100 sends out a unique authorization code every X seconds (e.g., 100 ms, 200 ms, 500 ms, etc.). In some implementations, the unique authorization codes are randomly or pseudo-randomly generated numbers. In some implementations, the payment module 100 stores broadcasted authorization codes until a received authorization grant token matches one of the stored authorization codes. In some implementations, the payment module 100 stores broadcasted authorization codes for a predetermined amount of time (e.g., Y minutes) after which time an authorization code expires and is deleted. In some implementations, the authorization code is encrypted with a shared secret key known by the server 130 but unique to the payment module 100. In some implementations, the payment module 100 initializes a random number and then the authorization codes are sequential counts from this random number. In such implementations, the payment module 100 stores the earliest valid (unexpired) counter without a need to store every valid authorization code. In some implementations, the authentication code included in the broadcast packet of information is a hash value of the randomly or pseudo-randomly generated number or the sequential number.
The mobile device 150 receives the broadcasted packet of information, and the mobile device 150 sends (1004), via a long-range communication capability (e.g., GSM, CDMA, Wi-Fi, or the like), an authorization request to the server 130. For example, an application 140 that is associated with the payment processing system is executing as a foreground or background process on the mobile device 150. In this example, the application 140 receives the broadcasted packet of information when the mobile device 150 is within the communication zone of the payment module 100 (i.e., BLE range) and either automatically sends the authorization request to the server 130 or sends the authorization request to the server 130 when the mobile device 150 is within the authorization zone of the payment module 100. In some implementations, the broadcasted packet of information includes a baseline authorization zone threshold (i.e., an authorization zone criterion) indicating a baseline RSSI that the mobile device 150 (or the application 140) is required to observe before being within the authorization zone of the payment module 100. In some implementations, the mobile device 150 (or the application 140) offsets the baseline authorization zone threshold based on the strength and/or reception of the short-range communication capability (e.g., BLE radio/transceiver) of the mobile device 150. In some implementations, the authorization request at least includes the authorization code which was included in the broadcasted packet of information, an identifier associated with the user of the mobile device 150 or the user account under which the user of the mobile device 150 is logged into the application 140 (user ID), and the identifier associated with the payment module 100 (module ID). In some implementations, the authentication code included in authorization request is the hash value in cleartext. The authorization request is further discussed below with reference to
After receiving the authorization request, the server 130 processes (1006) the authorization request. In some implementations, the server 130 decrypts the authorization code included in the authorization request with the shared secret key corresponding to the payment module 100. In some implementations, the server 130 determines whether the user associated with the user ID in the authorization request has sufficient funds in his/her account for the payment processing system to perform a transaction at the machine 120 that is associated with the payment module 100 corresponding to the module ID in the authorization request.
The server 130 sends (1008), via a long-range communication capability (e.g., GSM, CDMA, Wi-Fi, or the like), an authorization grant token to the mobile device 150. In some implementations, the server 130 does not send the authorization grant token if the authorization code in the authorization request cannot be decrypted with the shared secret key corresponding to the payment module 100 (e.g., the authorization code is corrupted or hacked). In some implementations, the server 130 does not send the authorization grant token if the user associated with the user ID in the authorization request does not have sufficient funds in his/her account. In some implementations, in addition to the authorization grant token, the server 130 sends a message directly to the mobile device 150 which 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 declined authorization. In some implementations, the server 130 sends an authorization grant token for an amount equal to zero; in which case, the payment module 100 interprets this as a declined or failed authorization which can result for any number of reasons including, but not limited to, insufficient balance or credit.
The mobile device 150 receives the authorization grant token, and, subsequently, the mobile device 150 detects (1010) a trigger condition. In some implementations, the mobile device 150 (or the application 140) detects the trigger condition via the hand-free mode (e.g., upon entrance into the payment zone of the payment module 100) or manual mode (e.g., interacting with the user interface of the application 140 to initiate a transaction with the payment accepting unit associated with the payment module 100).
In some implementations, unused authorization grants (e.g., if there was no trigger condition or it expired) are canceled by the mobile device 150 by sending a cancellation message to the server 130 corresponding to the unused authorization grant. In some implementations, the server 130 denies or limits the number of authorization grants sent to the mobile device 150 until it has received transaction information or cancellation of authorization outstanding authorization grants sent to the mobile device 150.
In response to detecting the trigger condition, the mobile device 150 sends (1012), via a short-range communication capability (e.g., BLE), the authorization grant token to the payment module 100. Subsequently, the machine 120 displays credit to the user (e.g., via one of the displays 122 or 124 shown in
In some implementations, the module ID 1102 is a unique identifier corresponding to the payment module 100 (sometimes also herein called the “adapter module 100”) that broadcast the packet 1100.
In some implementations, the authorization code 1104 is a hash value in cleartext. In some implementations, the payment module 100 randomly or pseudo-randomly generates a number or determines a sequential number (See step 1002 of process 1000 in
In some implementations, the firmware version information 1106 identifies a current firmware version 1112 of the payment module 100. In some implementations, the firmware version information 1106 also includes update status information 1114 indicating one or more packets received by the payment module 100 to update the firmware or one or more packets needed by the payment module 100 to update the firmware. See
In some implementations, the one or more status flags 1108 indicate a state 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 a state of the payment module 100 such upload information indicator 1116 indicating that that the payment module 100 has information to be uploaded to the server 130 (e.g., transaction information for one or more interrupted transactions). In some implementations, upload information indicator 1116 triggers the mobile device 150 to connect to payment module 100 immediately (e.g., if it has interrupted transaction information to be uploaded to the server 130). See
In some implementations, the zone criteria information 1110 specifies an authorization zone criterion 1124 (e.g., a baseline authorization zone threshold indicating a baseline RSSI that the mobile device 150 (or the application 140) is required to observe before being within the authorization zone of the payment module 100) and/or a payment zone criterion 1126 (e.g., a baseline payment zone threshold indicating a baseline RSSI that the mobile device 150 (or the application 140) is required to observe before being within the payment zone of the payment module 100). In some implementations, 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 criterion 1124 and payment zone criterion 1126 are offsets to compensate for the strength and/or reception of the short-range communication capability (e.g., BLE radio/transceiver) of the payment module 100. Alternatively, zone criteria information 1110 includes a spread between the baseline authorization zone threshold and the baseline payment zone threshold. Thus, the mobile device 150 (or the application 140) determines the baseline authorization zone threshold and the baseline payment zone threshold based on the spread value and a default value for either the baseline authorization zone threshold or the baseline payment zone threshold. For example, the spread indicates −10 db and the default baseline payment zone threshold is −90 db; thus, the baseline authorization zone threshold is −80 db. Continuing with this example, after determining the baseline authorization zone threshold and the baseline payment zone threshold, the mobile device 150 (or the application 140) may further adjust the authorization zone threshold and/or the payment zone threshold based on the strength and/or reception of its short-range communication capability (i.e., BLE radio/transceiver).
In some implementations, the module ID 1102 is a unique identifier corresponding to the payment module 100 that broadcast the 1100 that included the authorization code 1104.
In some implementations, the user ID 1134 is an identifier associated with the user of the mobile device 150 sending the authorization request 1130 to the server 130. In some implementations, the user ID 1134 is associated with the user account under which the user of the mobile device 150 is logged into the application 140.
In some implementations, the authorization code 1130 includes the authorization code 1104 included in the packet 1100 of information that was broadcast by the payment module 100.
In some implementations, the module ID 1102 is a unique identifier corresponding to the payment module 100 that broadcast the packet 1100 that included the authorization code 1104.
In some implementations, the user ID 1134 is an identifier associated with the user of the mobile device 150 that sent the authorization request 1130 to the server 130.
In some implementations, the authorized amount 1146 indicates a maximum amount for which the user of the mobile device 150 is authorized for a transaction using the authorization grant token 1140. For example, the authorized amount 1146 is predefined by the user of the mobile device 150 or by the server 130 based on a daily limit or based on the user's total account balance or based on a risk profile of the user correspond to the user ID 1134.
In some implementations, the expiration period 1148 offset indicates an offset to the amount of time that the payment module 100 holds the authorization grant token 1140 valid for initiation of a transaction with the machine 120 associated with the payment module 100. For example, the expiration period offset 1148 depends on the history and credit of the user of mobile device 150 or a period predefined by the user of mobile device 150.
In some implementations, the authorization grant token 1140 further includes the authorization code 1104 that was included in the authorization request 1130. In some implementations, when the authorization code 1104 is the hash value, the server 130 encrypts the authorization grant token 1140 including the hashed value with the shared secret encryption key associated with payment module 100. Subsequently, when mobile device 150 sends the authorization grant token 1140 to payment module 100 after detecting a trigger condition, the payment module 100 decrypts the authorization grant token 1140 using the secret key known only to server 130 and payment module 100 (which authenticates the message and the authorization grant), and then matches the hash value included in the decrypted authorization grant token 1140 to previously broadcast valid (unexpired) hash values (i.e., auth codes) to determine validity of the (which was known only by payment module 100).
In some implementations, the transaction ID 1152 is a unique identifier corresponding to the respective transaction. In some implementations, the transaction ID 1152 is encoded based on or associated with the time and/or date on which and the location at which the respective transaction took place.
In some implementations, the module ID 1154 is a unique identifier corresponding to the payment module 100 that performed the respective transaction.
In some implementations, the user ID 1156 is an identifier associated with the user of the mobile device 150 that initiated the respective transaction.
In some implementations, the authorization code 1158 corresponds to the original authorization code (e.g., auth code 1104,
In some implementations, the transaction status information 1160 includes an indication whether the respective transaction was completed, not-completed, or aborted. For example, the respective transaction is incomplete if a jam occurred at the payment accepting unit 120 and the user did not receive the product associated with the respective transaction. For example, if the user walks away from the payment accepting unit 120 after money was credited for the respective transaction, the respective transaction is aborted. In another example, if respective transaction times out after a predetermined time period because the user failed to select a product at the payment accepting unit 120, the respective transaction is aborted. In another example, if the user actuates a bill or coin return mechanism of the payment accepting unit 120, the respective transaction is aborted.
In some implementations, the transaction amount 1162 indicates the amount of the respective transaction or the amount of each of multiple transactions (e.g., in a multi-vend scenario). In some implementations, the transaction amount 1162 is encrypted with a unique encryption key corresponding to the payment module 100.
In some implementations, the other information 1164 includes other information related to the respective transaction such as the items dispensed by the payment accepting unit 120 and the type of transaction (e.g., coins, bills, credit card, manual mode, hands-free mode, etc.). In some implementations, the other information 1164 includes other information related to the payment module 100 and/or the payment accepting unit 120 associated with the payment module 100. For example, the other information 1164 includes a verification request to the server 130 in order to implement new firmware. See
The payment module 100 obtains (1202) a first notification indicating completion of a first transaction from the machine 120. For example, after the process 1000 in
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 implementations, the transaction information includes a transaction ID for the first transaction, a module ID corresponding to payment module 100, a user ID corresponding to the mobile device 150, transaction status information indicating that the first transaction is complete, and the transaction amount indicated by the first notification. In some implementations, the payment module 100 retains the authorization code included in the original broadcasted packet and/or the authorization grant token and includes the authorization code in the first transaction information. In some implementations, the authorization code is encrypted with a secret key corresponding to the payment module 100, which is shared with the server 130 but not the mobile device 150. In some implementations, the first transaction information further includes other information such as the machine status information included in the first notification or transaction information corresponding to previous interrupted transaction(s). See
The payment module 100 sends (1206), via a short-range communication capability (e.g., BLE), the first transaction information to the mobile device 150.
The mobile device 150 sends (1208), via a long-range communication capability (e.g., GSM, CDMA, Wi-Fi, or the like), the first transaction information to the server 130.
The server 130 processes (1210) the first transaction information. For example, the server 130 debits the account of the user associated with the user ID in the first transaction information in the amount indicated by the first transaction information.
The server 130 sends (1212), via a long-range communication capability (e.g., GSM, CDMA, Wi-Fi, or the like), first acknowledgment information to the mobile device 150. In some implementations, the first acknowledgment information acknowledges that the server 130 received the first transaction information. In some implementations, the first acknowledgment information includes the user ID, the module ID, the transaction ID, and (optionally) the authorization grant included in the transaction information (e.g., auth grant 1158,
After receiving the first acknowledgement information, the mobile device 150 sends (1214), via a short-range communication capability (e.g., BLE), the first acknowledgment information to the payment module 100.
After receiving the first acknowledgment information, the payment module 100 deletes (1216) the stored first transaction information.
In some implementations, during normal operation, the machine 120 includes a multi-drop bus (MDB) connecting a machine controller 1360 (also referred to herein as a payment accepting unit controller) of the machine 120 with payment peripherals (e.g., other payment peripheral(s) 1350, 1355 including coin acceptors, bill acceptors, cashless payment devices such as a payment card reader, and/or the like). In some implementations, the device 1300 is connected in-line to the MDB as shown in
In
In
In some implementations, the machine 120 further includes one or more other payment peripherals 1350, 1355 coupled with the MDB. Example payment peripherals of the one or more other payment peripherals include a bill acceptor, coin acceptor, or payment card reader. In these implementations, the device 1300 further includes an additional interface 1304 configured to couple the device with the one or more other payment peripherals 1355 of the machine. For example, with reference to
In some implementations, the device 1300 further includes a pass-through channel configured to pass through signals from the one or more other payment peripherals 1355 to the machine controller 1360. For example, with reference to
In some implementations, the device 1300 optionally includes an internal payment peripheral 1340 with hardware, software, firmware, or a combination thereof for providing one or more of the payment processing functionalities described above with reference to
In some implementations, the machine controller 1360 (
In some implementations, in response to the poll 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 the device 1300 has not yet been 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 implementations, the device 1300 identifies itself as a coin acceptor, a bill acceptor, or a cashless payment device to the machine controller 1360 via the reset signal.
In some implementations, in response to the reset signal, the machine controller 1360 sends (1406) a setup signal to the device 1300. In some implementations, the setup signal includes an address assigned to the device 1300.
In some implementations, after receiving and processing the setup signal, the device 1300 sends (1408) an acknowledgement to the machine controller 1360 confirming registration as a slave.
Upon sending the acknowledgement, the device 1300 has been registered as a slave (e.g., a payment peripheral) to the machine controller 1360.
In some implementations, the device 1300 polls (1412) the payment peripheral 1330-A.
In some implementations, in response to the poll 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 has not yet been registered as a slave (e.g., a payment peripheral) to the device 1300. In another example, the payment peripheral 1330-A sends the reset signal to re-register itself as a slave. In some implementations, the payment peripheral 1330-A identifies itself as a coin acceptor, a bill acceptor, or a cashless payment device to the device 1300 via the reset signal.
In some implementations, in response to the reset signal, the device 1300 sends (1416) a setup signal to the payment peripheral 1330-A. In some implementations, the setup signal includes an address assigned to the payment peripheral 1330-A.
In some implementations, after receiving and processing the setup signal, the payment peripheral 1330-A sends (1418) an acknowledgement to device 1300 confirming registration as a slave.
In some implementations, the device 1300 polls (1422) the payment peripheral 1330-N.
In some implementations, in response to the poll command, the payment peripheral 1330-N sends (1424) a reset signal to the device 1300. For example, the payment peripheral 1330-N sends the reset signal to the device 1300 if it has not yet been registered as a slave (e.g., a payment peripheral). In another example, the payment peripheral 1330-N sends the reset signal to re-register itself as a slave. In some implementations, the payment peripheral 1330-N identifies itself as a coin acceptor, a bill acceptor, or a cashless payment device to the device 1300 via the reset signal.
In some implementations, in response to the reset signal, the device 1300 sends (1426) a setup signal to the payment peripheral 1330-N. In some implementations, the setup signal includes an address assigned to the payment peripheral 1330-N.
In some implementations, after receiving and processing the setup signal, the payment peripheral 1330-N sends (1428) an acknowledgement to the device 1300 confirming registration as a slave.
In some implementations, 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 (
In some implementations, in a manner similar to the machine controller 1360, the device 1300 also polls the payment peripheral(s) 1330 according to the predetermined time period (e.g., 5 ms). For example, the device 1300 polls the payment peripheral(s) 1330 whenever the device 1300 is polled by the machine controller 1360.
In some implementations, the machine controller 1360 polls (1502) the device 1300.
In response to the polling command in operation 1502, the device 1300 sends (1504) an acknowledgment to the machine controller 1360.
In response to or independent of the polling command in operation 1502, 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.
In response to or independent of the polling command in operation 1502, the device 1300 polls (1510) the payment peripheral 1330-A. In response to the polling command in operation 1510, the payment peripheral 1330-A sends (1512) a request to begin a payment session. For example, the request to begin the payment session is sent in response to a user inserting payment (e.g., a bill(s) or coin(s)) into the payment peripheral 1330-A prior to the polling command in operation 1510.
In response to the request to begin the payment session, the device 1300 sends (1514) an acknowledgment to the payment peripheral 1330-A.
In response to the request to begin the payment session, the device 1300 also sends (1516) a disable command to the payment peripheral 1330-N so as 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.
The machine controller 1360 polls (1520) the device 1300.
In response to the polling command in operation 1520, the device 1300 sends (1522) a request to begin a payment session to the machine controller 1360. For example, the request to begin the payment session (sent to the machine controller 1360 in operation 1522) mirrors the request to begin the payment session (received from the payment peripheral 1330-A in operation 1512).
In response to the request to begin the payment session in operation 1522, the machine controller 1360 sends (1524) an acknowledgement to the device 1300 and also sends (1526) a vend request to the device 1300. In process 1500, vending of a service or product is taken as a non-limiting example.
In response to receiving the vend request, the device 1300 sends (1527) an acknowledgment to the machine controller 1360.
In some implementations, the machine controller 1360 polls (1528) the device 1300 N times prior to the device 1300 sending a vend approved signal in operation 1540. In some implementations, the device 1300 responds to the N polling commands with acknowledgments indicating that the device 1300 is still present and processing the vend request.
In response to receiving the vend request in operation 1526, the device 1300 relays (1530) the vend request to the payment peripheral 1330-A.
In response to the vend request in operation 1530, the payment peripheral 1330-A sends (1532) an acknowledgement to the device 1300.
Subsequently, the device 1300 polls (1534) the payment peripheral 1330-A. In response to the polling command in operation 1534, the payment peripheral 1330-A sends (1536) a vend approved signal to the device 1300. For example, the vend approved signal indicates that the payment inserted by the user was not refunded and was used to purchase a service or product.
In response to receiving the vend approved signal in operation 1536, the device 1300 sends (1538) an acknowledgment to the payment peripheral 1330-A and also relays (1540) the vend approved signal to the machine controller 1360.
In response to receiving the vend approved 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 to indicate whether the vend was a success or a failure.
In response to receiving the request in operation 1544, the device 1300 sends (1546) a response to the machine controller 1360 indicating that the vend was a success or a failure and also relays (1550) the request to the payment peripheral 1330-A to indicate whether the vend was a success or a failure.
In response to the request in operation 1550, the payment peripheral 1330-A sends (1552) an acknowledgement to the device 1300.
In response to receiving the response in operation 1546, the machine controller 1360 sends (1548) an acknowledgement to the device 1300 and also sends (1554) a command to end the payment session to the device 1300.
In response to receiving the command to end the payment session in operation 1554, the device 1300 sends (1556) an acknowledgment to the machine controller 1360 and relays (1558) the command to end the payment session to the payment peripheral 1330-A.
In response to the command to end the payment session in operation 1558, the payment peripheral 1330-A sends (1560) an acknowledgment to the device 1300.
After receiving the acknowledgment from the payment peripheral 1330-A in operation 1560, the device 1300 sends (1562) an enable command to the payment peripheral 1330-N so as to enable the payment peripheral 1330-N after completion of the payment session for the payment peripheral 1330-A. In response to the enable command received in operation 1562, the payment peripheral 1330-N sends (1564) an acknowledgment to the device 1300.
The device 1300 performs (1602) as a virtual payment peripheral (slave) for the machine controller 1360 by registering itself as a slave to the machine controller 1360, and the device 1300 performs as a virtual machine controller (master) for the one or more payment peripherals 1330 by registering the 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 expands 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(s) 1330 coupled with the host interface(s) 1320 and (ii) emulating a payment peripheral 1330 to the machine controller 1360. As such, in some implementations, the machine controller 1360 views the device 1300 as another payment peripheral 1330 connected to the MDB, where the device 1300 sends signals to the machine controller 1360 in a manner as if originated by the device 1300 that is functioning as a singular virtual payment peripheral 1330 (in other words, in a manner as if originated by a payment peripheral 1330). Moreover, in some implementations, the payment peripheral(s) 1330 view the device 1300 as the machine controller 1360, where the device 1300 sends signals to the payment peripheral(s) 1330 in a manner as if originated by the machine controller 1360.
In some implementations, registering the device 1300 as a slave to the machine controller 1360 further comprises (1602a): identifying the device 1300 to the machine controller 1360 as a cashless payment peripheral; and accepting registration of the device 1300 with the machine controller 1360 as a cashless payment peripheral. For example, the device 1300 identifies itself to the machine controller 1360 as a cashless payment device (e.g., a payment card reader) when sending the reset signal to the machine controller 1360 in operation 1404, and the device 1300 accepts registration as a cashless payment device when receiving the setup signal from the machine controller 1360 in operation 1406 (see
In some implementations, registering the device 1300 as a slave to the machine controller 1360 further comprises (1602b): identifying the device 1300 to the machine controller 1360 as a coin acceptor peripheral; and accepting registration of the device 1300 with the machine controller 1360 as a coin acceptor peripheral. For example, the device 1300 identifies itself to the machine controller 1360 as a coin acceptor when sending the reset signal to the machine controller 1360 in operation 1404, and the device 1300 accepts registration as a coin acceptor when receiving the setup signal from the machine controller 1360 in operation 1406 (see
In some implementations, registering the device 1300 as a slave to the machine controller 1360 further comprises (1602c): identifying the device 1300 to the machine controller 1360 as a bill acceptor peripheral; and accepting registration of the device 1300 with the machine controller 1360 as a bill acceptor peripheral. For example, the device 1300 identifies itself to the machine controller 1360 as a bill acceptor/validator when sending the reset signal to the machine controller 1360 in operation 1404, and the device 1300 accepts registration as a bill acceptor/validator when receiving the setup signal from the machine controller 1360 in operation 1406 (see
The device 1300 receives (1604) a command (in the form of a signal) from the machine controller 1360 via the slave interface 1302, where signals from the machine controller 1360 are sent in a manner as if sent to a singular payment peripheral 1330. For example, with reference to process 1500, the machine controller 1360 sends a command to the device 1300 to end the payment session in operation 1554 (see
In response to receiving the command from the machine controller 1360, the device 1300 sends (1604) an acknowledgement to the command to the machine controller 1360 via the slave interface 1302, where signals are sent to the machine controller 1360 in a manner as if originated by the device 1300 that is functioning as a singular virtual payment peripheral 1330 (in other words, as if originated by a payment peripheral 1330); and relays the command to the respective payment peripheral 1330 via the respective host interface 1320 corresponding to the respective payment peripheral 1330, where the device 1300 sends signals to and receives signals from the machine controller 1360 asynchronous of the device 1300 sending signals to and receiving signals from the one or more payment peripherals 1330 (in other words, communications between the device 1300 and the machine controller 1360 are not necessarily synchronized to communications between the device 1300 and the payment peripheral(s) 1330). Continuing with the example above, with reference to process 1500, in response to receiving the command to end the payment session in operation 1554, the device 1300 sends an acknowledgment to the machine controller 1360 in operation 1556 in a manner as if originated by the device that is functioning as a singular virtual payment peripheral 1330 (in other words, in a manner as if originated by the payment peripheral 1330). Continuing with this example, in response to receiving the command to end the payment session in operation 1554, the device 1300 also asynchronously relays the command to end the payment session to the payment peripheral 1330-A in operation 1558. As such, the command is relayed to the payment peripheral 1330-A asynchronous of sending the acknowledgment to the machine controller 1360 (in other words, the signals 1556 and 1558 are not necessarily synchronized).
In some implementations, in response to relaying the command, the device 1300 receives (1608) via the respective host interface 1320 corresponding to the respective payment peripheral 1330 a response from the respective payment peripheral 1330. Continuing with the example above, with reference to process 1500, in response to the relayed complete session command in operation 1558, the payment peripheral 1330-A sends an acknowledgment to the device 1300 in operation 1560.
In some implementations, in response to receiving the response from the respective payment peripheral 1330, the device 1300: sends an acknowledgement to the respective payment peripheral 1330, where signals are sent to the one or more payment peripherals 1330 in a manner as if originated by the machine controller 1360; and relays the response to the machine controller 1360 via the slave interface 1302, where the device 1300 sends signals to and receives signals from the machine controller 1360 asynchronous of the device sending signals to and receiving signals from the one or more payment peripherals 1330 (in other words, communications between the device 1300 and the machine controller 1360 are not necessarily synchronized to communications between the device 1300 and the payment peripheral(s) 1330). In some implementations, in response to receiving the response from the respective payment peripheral 1330, the device forgoes the above steps (e.g., the device 1300 does not relay the acknowledgement 1560 to the machine controller 1360 because the device 1300 had already acknowledged the machine controller 1360's session complete command in operation 1556).
In some implementations, the device 1300 receives (1610) a command from a respective payment peripheral 1330 via the respective host interface 1320 corresponding to the respective payment peripheral 1330, where signals from the payment peripheral(s) 1330 are sent to the device 1300 in a manner as if sent to the machine controller 1360, and, in response to receiving the command from the respective payment peripheral 1330, the device 1300 sends (1612) an acknowledgement to the command to the respective payment peripheral 1330, where signals are sent from the device 1300 to the payment peripheral(s) 1330 in a manner as if originated by the machine controller 1360; and relays the command to the machine controller 1360 via the slave interface 1302, where the device 1300 sends signals to and receives signals from the machine controller 1360 asynchronous of the device 1300 sending signals to and receiving signals from the payment peripheral(s) 1330 (in other words, communications between the device 1300 and the machine controller 1360 are not necessarily synchronized to communications between the device 1300 and the payment peripheral(s) 1330). For example, with reference to process 1500, when polled in operation 1534, the payment peripheral 1330-A sends a vend approved signal to the device 1300 in a manner as if sent to the machine controller 1360 in operation 1536. Continuing with this example, in response to receiving the vend approved signal in operation 1536, the device 1300 sends an acknowledgement to the payment peripheral 1330-A in a manner as if originated by the machine controller 1360 in operation 1538. Continuing with this example, in response to receiving the vend approved signal in operation 1536, the device 1300 also asynchronously relays the vend approved signal to the machine controller 1360 in operation 1540. As such, the command is relayed to the machine controller 1360 asynchronous of sending the acknowledgment to the payment peripheral 1330-A (in other words, the signals 1538 and 1540 are not necessarily synchronized).
In some implementations, in response to relaying the command, the device 1300 receives (1614) via the slave interface 1302 a response from the machine controller 1360. Continuing with the example above, with reference to process 1500, in response to the relayed vend approved signal in operation 1540, the machine controller 1360 sends an acknowledgment to the device 1300 in operation 1542.
In some implementations, the device 1300 further includes an internal payment peripheral 1340 including a short-range communication capability corresponding to a short-range communication protocol, where the short-range communication capability is configured to communicate with one or more mobile devices, and where each of the one or more mobile devices is configured with (i) a complimentary short-range communication capability and (ii) a long-range communication capability corresponding to a long-range communication protocol. For example, with reference to
In some implementations, the device 1300 receives (1616) a transaction request via the short-range communication capability from a respective mobile device to perform a transaction with the machine controller 1360, the device 1300 validates the transaction request, where validation of the transaction request indicates that the respective mobile device is authorized to initiate payment for the transaction by a remote server via the respective mobile device's long-range communication capability, and, in accordance with a determination that the transaction request is valid, the device 1300 causes the machine controller 1360 to perform the requested transaction by, for example, issuing a signal to perform the transaction to the machine controller 1360 via the slave interface 1302. In some implementations, the device 1300 or a component thereof (e.g., internal payment peripheral 1340,
In some implementations, in accordance with a determination that a command received from the respective payment peripheral 1330 corresponds to a transaction, the device 1300 stores (1618) transaction information at least including an amount of the transaction associated with an identifier for the respective payment peripheral 1330; after storing the transaction information, the device 1300 sends the transaction information to the respective mobile device via the short-range communication capability; and issues a command to the respective mobile device to send the transaction information to the remote server via the respective mobile device's long-range communication capability.
In some implementations, the device 1300 or a component thereof (e.g., the internal payment peripheral 1340,
In some implementations, the device 1300 or a component thereof (e.g., the internal payment peripheral 1340,
The particular order in which the operations in
In some implementations, the electronic device 1300 receives, from a mobile device 150 via the short-range communication capability of the internal peripheral 1340, a request to access one or more of the peripherals 1330. In response to this request, the device 1300 intercepts signals received from peripheral(s) 1330 via respective host interface(s) 1320 (e.g., a payment signal reporting an amount of money received at a bill acceptor peripheral or a coin acceptor peripheral). Instead of relaying the signals to the machine controller 1360, the device 1300 relays the signals (or data based on the signals) to the mobile device 150 through the internal peripheral 1340. While the device 1300 is intercepting signals received from the peripheral(s) 1330 (i.e., relaying the signals to the internal peripheral 1340 instead of the machine controller 1360), the device 1300 responds to commands that are addressed to the peripheral(s) 1330 (e.g., poll commands sent from the machine controller 1360) with acknowledgements (e.g., merely reporting presence), rather than relaying the commands to the peripheral(s) 1330.
By intercepting signals as described herein, the device 1300 can provide external access to the peripheral(s) 1330 (also referred to as providing peripheral access to an external device). More specifically, the device 1300 may be configured to enable an external device (e.g., a mobile device 150, or any device that is physically external to the machine 120 and in communication with the device 1300) to access functionality provided by the peripheral(s) 1330 of the machine 120. As used herein, the term “access” may refer to provision of data based on functionality of a peripheral 1330, but does not require direct communication between the external device and the peripheral 1330 being accessed. By providing an external device with access to a peripheral 1330, the external device is provided with the benefit of functionality of the peripheral 1330. For example, if the peripheral 1330 is a bill collector, an external device with access to functionality of the bill collector may be provided with data indicating a state of the bill collector or any other data associated with functionality of the bill collector (e.g., an indication that the bill collector has just received a $1 bill).
In one example scenario, an application executing on a mobile device 150 in communication with the device 1300 may be provided access to a bill accepter peripheral 1330 of a machine 120, thereby providing a way for the application to accept cash payments. As such, capabilities of the mobile device 150 (and, therefore, applications executing on the mobile device 150) are augmented when given access to functionality provided by the peripheral(s) 1330 of a machine 120 as described herein. Such an application executing on a mobile device 150 (referred to herein as a mobile application) may be configured to sell products and/or services that are not necessarily stocked by the machine 120 of the peripheral 1330 being accessed, but benefit from the availability of the option to pay for the product and/or service with cash. For example, an application executing on a mobile device 150 may sell lottery tickets, which, according to the laws of some jurisdictions, can only be purchased using cash. Example products may include physical products that are available at a location associated with the machine 120 (e.g., provided by a store attendant or bank teller), or may include virtual products that are not required to be picked up or otherwise physically delivered (e.g., lottery tickets associated with virtual lottery applications that do not require delivery or use of a physical scratch card). Example services include banking (e.g., using a bill acceptor peripheral 1330 of a machine 120 to deposit cash to an account of a bank or credit union, regardless of whether the bank or credit union has a physical location), or any other service requiring or otherwise providing the option to deposit cash to an account (e.g., a gaming service with add-on functionality purchasable with cash, a peer-to-peer money transfer service enabling a sender to deposit cash into the bill acceptor of a machine 120 and a receiver to withdraw cash by accessing the cash return module of another machine 120, or any other service accepting cash payments). Such products and/or services may be related to products and/or services vended or advertised by the machine 120, or they may be independent of products and/or services vended or advertised by the machine 120 (e.g., functionality of the bill acceptor of a soda machine may be accessed by a mobile application selling lottery tickets, or functionality of the coin acceptor of a laundry machine may be accessed by a mobile gaming application configured to accept payments in return for in-game add-on features).
In
In
In some implementations, signals received at the device controller 1310 include at least (i) a destination address, and (ii) message data. More specifically, signals received at the device 1300 from a peripheral 1330 include the address of a specified master (referred to herein as a master address), and signals received at the device 1300 from the machine controller 1360 include the address of a specified peripheral 1330 (referred to herein as a peripheral address). The master and peripheral addresses may be identified or otherwise assigned during a registration process (e.g., during setup operations 1406, 1416, and 1426 in
For example, when a signal sent by the peripheral 1330 to the device 1300 specifies the address of the machine controller 1360 as the master address, the device controller 1310 relays the signal, including the signal's message (e.g., indicating receipt of a $1 bill) to the machine controller 1360 as depicted in
The operations in
While the methods 3100-3400 depict an implementation including one peripheral 1330 (for purposes of brevity and clarity of the concepts described herein), the concepts described herein also apply to implementations including a plurality of peripherals 1330 (for example, peripherals 1330-A through 1330-N as described above with reference to
Further, while the methods 3100-3400 refer to the peripheral 1330 as a bill acceptor, the concepts described herein also apply to other types of peripherals 1330. As described above, example peripherals 1330 include bill acceptors, coin acceptors, and cashless payment devices such as payment card readers. Example peripherals 1330 may also include any other type of electronic peripheral device related to or unrelated to accepting payments.
Lastly, the operations of methods 3100-3400 are depicted in a particular order, and at particular vertical offsets (spacing) with respect to each other. Regarding the particular order, unless the description for a particular operation states otherwise, the operations may be implemented out of the order depicted in the figures, especially with respect to operations in different columns, and especially with respect to operations described as being asynchronous. For example, the acknowledgement in operation 3104 is described (in more detail below) as being sent in response to the poll signal sent in operation 3102; as such, this pair of operations and those similarly described must be implemented in the order depicted in the figures. However, the poll signal in operation 3106 may be sent before, at the same time as, or after the poll signal sent in operation 3102, since the description of these operations does not state a particular order or include any temporal limitations. Regarding the particular vertical offsets with respect to the operations, these offsets are provided for purposes of clarity and are not to temporal scale. As such, relative spacing sizes between operations have no effect on relative amounts of time that must pass between execution of such operations.
As described above with reference to
The machine controller 1360 continues to poll the device 1300 at a frequency determined by the particular implementation of the MDB protocol, and the device 1300 proceeds to poll the peripheral 1330 at a frequency determined either 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 $1 bill is received). Until the device 1300 receives a signal indicating the payment event from the peripheral 1330, the device 1300 responds to polls from the machine controller 1360 with acknowledgements. As such, when the machine controller 1360 polls (3110) the device 1300 again, the device 1300 responds (3112) with an acknowledgement. Subsequent to the payment event, the device 1300 polls (3116) the peripheral 1330, and the peripheral 1330 responds (3118) with a payment received signal, indicating the payment event 3114. For example, the payment received signal is addressed to the machine controller 1360 and includes a message indicating a $1 bill was received at the peripheral 1330 (as depicted in
In response to receiving the payment received signal from the peripheral 1330, the device 1300 (i) responds (3120) to the peripheral 1330 with an acknowledgement, and after receiving (3122) the next poll from the machine controller 1360, (ii) sends (3124) a payment received signal to the machine controller 1360 (e.g., including the $1 received message). As described above with reference to
As described above with reference to
In response to connecting to the mobile device 150 and/or to the request to access functionality associated with the peripheral 1330, the device 1300 sends a reset signal (3206) and/or a setup signal (3208) to the peripheral 1330 in order to reconfigure the peripheral 1330 to communicate with the device 1300 (rather than with the machine controller 1360). As described above, the device 1300 reconfigures the peripheral 1330 to communicate with the device 1300 by resetting the master address (the signal destination address) of the peripheral 1330 to be the address of the device 1300. Upon resetting the master address of the peripheral 1330 to the address of the device 1300, the device 1300 effectively becomes the master to the peripheral 1330. As a result, the machine controller 1360 is no longer the master to the peripheral 1330 (see
Once the signal destination address of the peripheral 1330 is updated to be that of the device 1300, the device 1300 continues to poll the peripheral 1330 (3212, 3216) and receive acknowledgements from the peripheral 1330 (3214, 3218). Polls received at the device 1300 from the machine controller 1360 (3222, 3226) during this time are not relayed to the peripheral 1330. Instead, the device 1300 merely acknowledges (3224, 3228) the polls so that the machine controller 1360 does not remove the device 1300 from its list of registered devices. Stated another way, the device 1300 normally passes signals received from the machine controller 1360 to the peripheral 1330, but while performing intercept operations (as a result of the mobile device 150 connecting to the device 1300 and the device 1300 resetting the peripheral 1330), the device 1300 still responds to polls received from the machine controller 1360, but does not pass any messages through to the peripheral 1330. Instead, the device 1300 just acknowledges messages received from the machine controller 1360. Accordingly, the device 1300 remains registered with the machine controller 1360 and appears to be in an idle state (from the point of view of the machine controller 1360). While performing intercept operations, communications between (i) the device 1300 and the machine controller 1360 and (ii) the device 1300 and the peripheral 1330 continue to be asynchronous. The device 1300 continues to perform intercept operations until transitioning back to normal operations (described in more detail below with reference to
The device 1300 transmits (3312) the transaction (more specifically, a signal including a message describing or otherwise 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 in accordance with the amount of cash that was deposited as part of the payment event 3302 (e.g., adds $1 to the user's account). As another example, the server 130 sends an amount of funds to a recipient in accordance with the amount of cash that was deposited as part of the payment event 3302 (e.g., sends $1 to the recipient). As another example, the server 130 associates a specified product or service with the user's account in accordance with a requested purchase (e.g., associates a virtual lottery ticket with the user's account in return for an amount of funds associated with the amount of cash that was deposited as part of the payment event 3302).
As a result of the processing of the transaction, the server 130 sends (3318) a notification to the mobile device 150 indicating the payment was processed and/or a result of the payment being processed (e.g., a purchase confirmation or a deposit confirmation). In some implementations, the mobile device 150 (more specifically, an application executing on the mobile device) displays information related to the received notification (e.g., an alert indicating a successful purchase or deposit, or an updated user interface indicating a new account balance).
Returning to the bill collector example, in some implementations, operations 3302 through 3312 are repeated each time a person inserts a bill into the peripheral 1330. Optionally, the mobile device 150 groups successive transactions (e.g., successive $1 insertions) into a single transaction message and sends the transaction message in operation 3314 for processing at the server 130. Alternatively, the mobile device 150 sends transaction messages in operation 3314 for processing at the server 130 for each successive transaction (e.g., successive $1 insertions). In such implementations, operations 3302 through 3316 (or operations 3302 through 3318, or operations 3302 through 3320) are repeated each time a person inserts a bill into the peripheral 1330.
As the device 1300 performs the intercept operations described above with reference to
In response to receiving the access complete notification, the device 1300 sends (3406) a reset signal to the peripheral 1330, thereby causing the peripheral to no longer address signals to the device 1300. The device 1300 proceeds to reset the signal destination address of the peripheral 1330 to be that of the machine controller 1360, for example, by sending (3416) a setup signal. As a result, subsequent messages sent by the peripheral 1330 to the device 1300 are addressed to the machine controller 1360. Stated another way, the machine controller 1360 once again functions as the master and the device 1300 once again functions as a router of messages between the machine controller 1360 (master) and the peripheral 1330 (slave).
As a result of the signal destination address of the peripheral 1330 being reset to that of the machine controller 1360, the device 1300 proceeds with normal operations as described above with reference to
The implementations described with reference to
Further, implementations need not be limited to scenarios involving cash transactions. Other types of electronic peripheral devices may be accessed from a machine 120 in order to extend functionality of a mobile application that would not otherwise have direct access to the hardware necessary to support such functionality. Stated another way, the device 1300 enables a mobile device 150 to access functionality provided by an electronic peripheral device 1300 of a machine 120 by providing wireless communications between an application executing on the mobile device 150 and the electronic peripheral device 1330, by (i) communicatively decoupling the electronic peripheral device 1300 from the machine controller 1360 which normally would function as the master of the electronic peripheral device 1330, and (ii) communicatively coupling the electronic peripheral device 1300 with the mobile application which functions as the master of the electronic peripheral device until the mobile application no longer requires access to the functionality provided by the electronic peripheral device 1330.
The foregoing description has been described with reference to specific implementations. However, the illustrative discussions above are not intended to be exhaustive or to limit the claims to the precise forms disclosed. Many variations are possible in view of the above teachings. The implementations were chosen and described in order to best explain principles of operation and practical applications, to thereby enable others skilled in the art.
The various drawings illustrate a number of elements in a particular order. However, elements that are not order dependent may be reordered and other elements may be combined or separated. While some reordering or other groupings are specifically mentioned, others will be obvious to those of ordinary skill in the art, so the ordering and groupings presented herein are not an exhaustive list of alternatives.
As used herein: the singular forms “a”, “an,” and “the” include the plural forms as well, unless the context clearly indicates otherwise; the term “and/or” encompasses all possible combinations of one or more of the associated listed items; the terms “first,” “second,” etc. are only used to distinguish one element from another and do not limit the elements themselves; the term “if” may be construed to mean “when,” “upon,” “in response to,” or “in accordance with,” depending on the context; and the terms “include,” “including,” “comprise,” and “comprising” specify particular features or operations but do not preclude additional features or operations. Lastly, as used herein, the terms “master” and “host” are synonymous unless clearly stated otherwise.
The present application is a continuation of U.S. patent application Ser. No. 16/934,933, filed Jul. 21, 2020, which is hereby incorporated by reference in its entirety. U.S. patent application Ser. No. 16/934,933 is a continuation-in-part of U.S. patent application Ser. No. 15/406,492, filed Jan. 13, 2017 and issued as U.S. Pat. No. 10,719,833 on Jul. 21, 2020, which is a continuation of U.S. patent application Ser. No. 14/335,762, filed Jul. 18, 2014 and issued as U.S. Pat. No. 9,547,859 on Jan. 17, 2017, which is a continuation of U.S. patent application Ser. No. 14/214,644, filed Mar. 14 2014 and issued as U.S. Pat. No. 8,856,045 on Oct. 7, 2014, which claims priority to U.S. Provisional Patent Application No. 61/917,936, filed Dec. 18, 2013, and is a continuation-in-part of U.S. Design patent application No. 29/477,025, filed Dec. 18, 2013 and issued as U.S. Pat. No. D755,183 on May 3, 2016, each of which is hereby incorporated by reference in its entirety. U.S. patent application Ser. No. 16/934,933 is also a continuation-in-part of U.S. patent application Ser. No. 16/029,483, filed Jul. 6, 2018 and issued as U.S. Pat. No. 10,963,905 on Mar. 30, 2021, which is a continuation of Ser. No. 14/611,065, filed Jan. 30, 2015 and issued as U.S. Pat. No. 10,019,724 on Jul. 10, 2018, each of which is hereby incorporated by reference in its entirety. U.S. patent application Ser. No. 16/934,933 is also a continuation-in-part of U.S. patent application Ser. No. 15/893,514, filed Feb. 9, 2018, which claims priority to International Patent Application No. PCT/US17/15676, filed Jan. 30, 2017, which is a continuation of U.S. Provisional Patent Application No. 62/289,158, filed Jan. 29, 2016. U.S. patent application Ser. No. 15/893,514 is also a continuation-in-part of U.S. patent application Ser. No. 14/641,236, filed Mar. 6, 2015, which claims priority to U.S. Provisional Patent Application No. 62/081,492, filed Nov. 18, 2014. U.S. patent application Ser. No. 14/641,236 is also a continuation-in-part of U.S. patent application Ser. No. 14/320,534, filed Jun. 30, 2014, which is a continuation-in-part of U.S. patent application Ser. No. 14/214,644, filed Mar. 14 2014 and issued as U.S. Pat. No. 8,856,045 on Oct. 7, 2014, which claims priority to U.S. Provisional Patent Application No. 61/917,936, filed Dec. 18, 2013, and is a continuation-in-part of U.S. Design patent application No. 29/477,025, filed Dec. 18, 2013 and issued as U.S. Pat. No. D755,183 on May 3, 2016, each of which is hereby incorporated by reference in its entirety.
| Number | Name | Date | Kind |
|---|---|---|---|
| 4374557 | Sugimoto et al. | Feb 1983 | A |
| 5479602 | Baecker et al. | Dec 1995 | A |
| 5844808 | Konsmo et al. | Dec 1998 | A |
| 5854994 | Canada et al. | Dec 1998 | A |
| 5880733 | Horvitz et al. | Mar 1999 | A |
| 5892900 | Ginter et al. | Apr 1999 | A |
| 5955718 | Levasseur | Sep 1999 | A |
| 6056194 | Kolls | May 2000 | A |
| 6390269 | Billington | May 2002 | B1 |
| 6462644 | Howell | Oct 2002 | B1 |
| 6505095 | Kolls | Jan 2003 | B1 |
| 6584309 | Whigham | Jun 2003 | B1 |
| 6594759 | Wang | Jul 2003 | B1 |
| 6743095 | Cole et al. | Jun 2004 | B2 |
| 6793134 | Clark | Sep 2004 | B2 |
| 6810234 | Rasanen | Oct 2004 | B1 |
| 6840860 | Okuniewicz | Jan 2005 | B1 |
| 7085556 | Offer | Aug 2006 | B2 |
| 7110954 | Yung et al. | Sep 2006 | B2 |
| 7127236 | Khan | Oct 2006 | B2 |
| 7131575 | Kolls | Nov 2006 | B1 |
| 7455223 | Wilson | Nov 2008 | B1 |
| 7458510 | Zhou | Dec 2008 | B1 |
| 7464867 | Kolls | Dec 2008 | B1 |
| 7493288 | Biship | Feb 2009 | B2 |
| 7513419 | Crews et al. | Apr 2009 | B1 |
| 7672680 | Lee et al. | Mar 2010 | B1 |
| 7690495 | Kolls | Apr 2010 | B1 |
| 7721958 | Belfer et al. | May 2010 | B2 |
| 7848980 | Carlson | Dec 2010 | B2 |
| 7962369 | Rosenberg | Jun 2011 | B2 |
| 7965693 | Jiang et al. | Jun 2011 | B2 |
| 7983670 | Elliott | Jul 2011 | B1 |
| 8020763 | Kowalchyk | Sep 2011 | B1 |
| 8059101 | Westerman | Nov 2011 | B2 |
| 8157167 | Cost et al. | Apr 2012 | B2 |
| 8201736 | Majer | Jun 2012 | B2 |
| 8255323 | Casey et al. | Aug 2012 | B1 |
| D669899 | Cheng et al. | Oct 2012 | S |
| 8346670 | Hasson et al. | Jan 2013 | B2 |
| 8356754 | Johnson et al. | Jan 2013 | B2 |
| 8376227 | Hammad et al. | Feb 2013 | B2 |
| 8396589 | Katzenstein Garibaldi | Mar 2013 | B2 |
| 8412626 | Hirson et al. | Apr 2013 | B2 |
| 8438066 | Yuen | May 2013 | B1 |
| 8479190 | Sueyoshi et al. | Jul 2013 | B2 |
| 8489140 | Weiner et al. | Jul 2013 | B2 |
| 8514775 | Frecassetti et al. | Aug 2013 | B2 |
| 8517766 | Golko et al. | Aug 2013 | B2 |
| 8548426 | Smith | Oct 2013 | B2 |
| 8577734 | Treyz | Nov 2013 | B2 |
| 8583496 | You et al. | Nov 2013 | B2 |
| 8596528 | Fernandes et al. | Dec 2013 | B2 |
| 8596529 | Kolls | Dec 2013 | B1 |
| 8600899 | Davis | Dec 2013 | B1 |
| 8606702 | Ruckart | Dec 2013 | B2 |
| 8615445 | Dorsey et al. | Dec 2013 | B2 |
| 8645971 | Carlson et al. | Feb 2014 | B2 |
| 8700530 | Smith | Apr 2014 | B2 |
| 8707276 | Hill et al. | Apr 2014 | B2 |
| 8712893 | Brandmaier | Apr 2014 | B1 |
| 8761809 | Faith et al. | Jun 2014 | B2 |
| 8769643 | Ben Ayed | Jul 2014 | B1 |
| 8788341 | Patel | Jul 2014 | B1 |
| 8794734 | Drummond | Aug 2014 | B2 |
| 8810430 | Proud | Aug 2014 | B2 |
| 8819659 | Ramer et al. | Aug 2014 | B2 |
| 8831677 | Villa-Real | Sep 2014 | B2 |
| 8838481 | Moshfeghi | Sep 2014 | B2 |
| 8850421 | Proud | Sep 2014 | B2 |
| 8856045 | Patel et al. | Oct 2014 | B1 |
| 8881975 | Matthews | Nov 2014 | B1 |
| 8898620 | Eizenman et al. | Nov 2014 | B2 |
| 8903737 | Cameron et al. | Dec 2014 | B2 |
| 8958846 | Freeny, Jr. | Feb 2015 | B2 |
| 9001047 | Forstall | Apr 2015 | B2 |
| 9037492 | White | May 2015 | B2 |
| 9092768 | Breitenbach et al. | Jul 2015 | B2 |
| 9098961 | Block et al. | Aug 2015 | B1 |
| 9210247 | Vance et al. | Dec 2015 | B2 |
| 9262771 | Patel | Feb 2016 | B1 |
| 9272713 | Dvoskin et al. | Mar 2016 | B1 |
| 9395888 | Schiplacoff et al. | Jul 2016 | B2 |
| 9424603 | Hammad | Aug 2016 | B2 |
| 9483763 | Van Os | Nov 2016 | B2 |
| 9547859 | Patel | Jan 2017 | B2 |
| 9875473 | Patel | Jan 2018 | B2 |
| 9898884 | Arora et al. | Feb 2018 | B1 |
| 10121318 | LeMay et al. | Nov 2018 | B2 |
| 10163292 | Romero | Dec 2018 | B1 |
| 10210501 | Low et al. | Feb 2019 | B2 |
| 10217151 | Greiner et al. | Feb 2019 | B1 |
| 10304057 | Powell | May 2019 | B1 |
| 10380573 | Lin et al. | Aug 2019 | B2 |
| 10410194 | Grassadonia | Sep 2019 | B1 |
| 10423949 | Lyons et al. | Sep 2019 | B2 |
| 10824828 | Ostri | Nov 2020 | B2 |
| 10977642 | Khan | Apr 2021 | B2 |
| 11010759 | Maeng | May 2021 | B1 |
| 11042852 | Wadhwa | Jun 2021 | B1 |
| 11074577 | Soccorsy et al. | Jul 2021 | B1 |
| 11182794 | Aument | Nov 2021 | B1 |
| 11227275 | Van Heerden et al. | Jan 2022 | B2 |
| 11308462 | Berman et al. | Apr 2022 | B2 |
| 11373147 | Moore | Jun 2022 | B1 |
| 11564266 | Kahn | Jan 2023 | B1 |
| 20020016740 | Ogasawara | Feb 2002 | A1 |
| 20020152123 | Giordano et al. | Oct 2002 | A1 |
| 20020164953 | Curtis | Nov 2002 | A1 |
| 20030009385 | Tucciarone | Jan 2003 | A1 |
| 20030089767 | Kiyomatsu | May 2003 | A1 |
| 20030101096 | Suzuki et al. | May 2003 | A1 |
| 20030110097 | Lei | Jun 2003 | A1 |
| 20030130902 | Athwal | Jul 2003 | A1 |
| 20030158891 | Lei et al. | Aug 2003 | A1 |
| 20030191811 | Hashem | Oct 2003 | A1 |
| 20030206542 | Holder | Nov 2003 | A1 |
| 20030236872 | Atkinson | Dec 2003 | A1 |
| 20040049454 | Kanno et al. | Mar 2004 | A1 |
| 20040117262 | Berger et al. | Jun 2004 | A1 |
| 20040122685 | Bunce et al. | Jun 2004 | A1 |
| 20040133653 | Defosse | Jul 2004 | A1 |
| 20050021459 | Bell | Jan 2005 | A1 |
| 20050043011 | Murray | Feb 2005 | A1 |
| 20050080510 | Bates | Apr 2005 | A1 |
| 20050101295 | Rupp | May 2005 | A1 |
| 20050177798 | Thomson et al. | Aug 2005 | A1 |
| 20050181804 | Misikangas et al. | Aug 2005 | A1 |
| 20050232421 | Simons et al. | Oct 2005 | A1 |
| 20050234776 | Jacoves | Oct 2005 | A1 |
| 20060043175 | Fu | Mar 2006 | A1 |
| 20060052157 | Walker et al. | Mar 2006 | A1 |
| 20060123335 | Sanchez et al. | Jun 2006 | A1 |
| 20070050083 | Signorelli et al. | Mar 2007 | A1 |
| 20070083287 | Defosse et al. | Apr 2007 | A1 |
| 20070095901 | Illingworth | May 2007 | A1 |
| 20070119680 | Saltsov et al. | May 2007 | A1 |
| 20070159994 | Brown et al. | Jul 2007 | A1 |
| 20070186105 | Bailey | Aug 2007 | A1 |
| 20070187491 | Godwin et al. | Aug 2007 | A1 |
| 20070227856 | Gopel | Oct 2007 | A1 |
| 20070255653 | Tumminaro | Nov 2007 | A1 |
| 20080010190 | Rackley, III et al. | Jan 2008 | A1 |
| 20080010193 | Rackley, III et al. | Jan 2008 | A1 |
| 20080033880 | Fiebiger et al. | Feb 2008 | A1 |
| 20080040265 | Rackley, III et al. | Feb 2008 | A1 |
| 20080126213 | Robertson et al. | May 2008 | A1 |
| 20080141033 | Ginter et al. | Jun 2008 | A1 |
| 20080154727 | Carlson | Jun 2008 | A1 |
| 20080154735 | Carlson | Jun 2008 | A1 |
| 20080163257 | Carlson et al. | Jul 2008 | A1 |
| 20080167017 | Wentker et al. | Jul 2008 | A1 |
| 20080167991 | Carlson et al. | Jul 2008 | A1 |
| 20080183480 | Carlson et al. | Jul 2008 | A1 |
| 20080201226 | Carlson et al. | Aug 2008 | A1 |
| 20080208762 | Arthur et al. | Aug 2008 | A1 |
| 20080249658 | Walker | Oct 2008 | A1 |
| 20080254853 | Wright et al. | Oct 2008 | A1 |
| 20080255947 | Friedman | Oct 2008 | A1 |
| 20080319913 | Wiechers | Dec 2008 | A1 |
| 20090037284 | Lewis et al. | Feb 2009 | A1 |
| 20090076896 | Dewitt | Mar 2009 | A1 |
| 20090099961 | Ogilvy | Apr 2009 | A1 |
| 20090106160 | Skowronek | Apr 2009 | A1 |
| 20090119190 | Realini | May 2009 | A1 |
| 20090171682 | Dixon et al. | Jul 2009 | A1 |
| 20090287349 | Mardiks | Nov 2009 | A1 |
| 20090288173 | Mardiks | Nov 2009 | A1 |
| 20090303982 | Blachman et al. | Dec 2009 | A1 |
| 20090306818 | Slagley et al. | Dec 2009 | A1 |
| 20090306819 | Insolia | Dec 2009 | A1 |
| 20090313125 | Roh et al. | Dec 2009 | A1 |
| 20090313132 | Kenna et al. | Dec 2009 | A1 |
| 20090327089 | Kanno et al. | Dec 2009 | A1 |
| 20100061294 | Proctor, Jr. | Mar 2010 | A1 |
| 20100082485 | Lin et al. | Apr 2010 | A1 |
| 20100094456 | Simpkins et al. | Apr 2010 | A1 |
| 20100105454 | Weber et al. | Apr 2010 | A1 |
| 20100198400 | Pascal | Aug 2010 | A1 |
| 20100227671 | Laaroussi et al. | Sep 2010 | A1 |
| 20100276484 | Banerjee | Nov 2010 | A1 |
| 20100280956 | Chutorash | Nov 2010 | A1 |
| 20100312692 | Teicher | Dec 2010 | A1 |
| 20100320266 | White | Dec 2010 | A1 |
| 20100329285 | Stanton | Dec 2010 | A1 |
| 20110029405 | Cronin | Feb 2011 | A1 |
| 20110040686 | Carlson | Feb 2011 | A1 |
| 20110125561 | Marcus | May 2011 | A1 |
| 20110153436 | Krampe | Jun 2011 | A1 |
| 20110153442 | Krampe | Jun 2011 | A1 |
| 20110153495 | Dixon et al. | Jun 2011 | A1 |
| 20110172848 | Breitenbach et al. | Jul 2011 | A1 |
| 20110178883 | Granbery | Jul 2011 | A1 |
| 20110225067 | Dunwoody | Sep 2011 | A1 |
| 20110238476 | Carr | Sep 2011 | A1 |
| 20110244799 | Roberts et al. | Oct 2011 | A1 |
| 20110251892 | Laracey | Oct 2011 | A1 |
| 20110251910 | Dimmick | Oct 2011 | A1 |
| 20110276636 | Cheng et al. | Nov 2011 | A1 |
| 20110289023 | Forster et al. | Nov 2011 | A1 |
| 20120011024 | Dorsey et al. | Jan 2012 | A1 |
| 20120016731 | Smith et al. | Jan 2012 | A1 |
| 20120029691 | Mockus et al. | Feb 2012 | A1 |
| 20120030047 | Fuentes | Feb 2012 | A1 |
| 20120036045 | Lowe et al. | Feb 2012 | A1 |
| 20120066096 | Penide | Mar 2012 | A1 |
| 20120078735 | Bauer et al. | Mar 2012 | A1 |
| 20120108173 | Hahm et al. | May 2012 | A1 |
| 20120136478 | Anand | May 2012 | A1 |
| 20120150742 | Poon et al. | Jun 2012 | A1 |
| 20120158172 | Wencslao | Jun 2012 | A1 |
| 20120158528 | Hsu et al. | Jun 2012 | A1 |
| 20120160912 | Laracey | Jun 2012 | A1 |
| 20120197740 | Grigg et al. | Aug 2012 | A1 |
| 20120203666 | Torossian et al. | Aug 2012 | A1 |
| 20120231844 | Coppinger | Sep 2012 | A1 |
| 20120246074 | Annamalai et al. | Sep 2012 | A1 |
| 20120253852 | Pourfallah | Oct 2012 | A1 |
| 20120254631 | Skillman et al. | Oct 2012 | A1 |
| 20120255653 | Chin | Oct 2012 | A1 |
| 20120258773 | Alvarez Rivera | Oct 2012 | A1 |
| 20120276845 | Wikander | Nov 2012 | A1 |
| 20120290472 | Mullen et al. | Nov 2012 | A1 |
| 20120296826 | Bergdale et al. | Nov 2012 | A1 |
| 20120303528 | Weiner et al. | Nov 2012 | A1 |
| 20120316963 | Moshfeghi | Dec 2012 | A1 |
| 20120330764 | Nahidipour | Dec 2012 | A1 |
| 20120330844 | Kaufman | Dec 2012 | A1 |
| 20130030931 | Moshfeghi | Jan 2013 | A1 |
| 20130054016 | Canter et al. | Feb 2013 | A1 |
| 20130054336 | Graylin | Feb 2013 | A1 |
| 20130054395 | Cyr et al. | Feb 2013 | A1 |
| 20130067365 | Shrufi et al. | Mar 2013 | A1 |
| 20130085835 | Horowitz | Apr 2013 | A1 |
| 20130087050 | Studor et al. | Apr 2013 | A1 |
| 20130100886 | Cherian | Apr 2013 | A1 |
| 20130110296 | Khoo | May 2013 | A1 |
| 20130117490 | Harriman | May 2013 | A1 |
| 20130117738 | Livingston et al. | May 2013 | A1 |
| 20130124289 | Fisher | May 2013 | A1 |
| 20130126607 | Behjat | May 2013 | A1 |
| 20130143498 | Niemi | Jun 2013 | A1 |
| 20130166448 | Narayanan | Jun 2013 | A1 |
| 20130185150 | Crum | Jul 2013 | A1 |
| 20130191789 | Calman | Jul 2013 | A1 |
| 20130217333 | Sprigg et al. | Aug 2013 | A1 |
| 20130246171 | Carapelli | Sep 2013 | A1 |
| 20130246364 | Bhavith | Sep 2013 | A1 |
| 20130267121 | Hsu | Oct 2013 | A1 |
| 20130267176 | Hertel et al. | Oct 2013 | A1 |
| 20130275303 | Fiore | Oct 2013 | A1 |
| 20130275305 | Duplan | Oct 2013 | A1 |
| 20130278622 | Sun et al. | Oct 2013 | A1 |
| 20130282590 | Rajarethnam et al. | Oct 2013 | A1 |
| 20130297422 | Hunter et al. | Nov 2013 | A1 |
| 20130311379 | Smith | Nov 2013 | A1 |
| 20130311382 | Fosmark et al. | Nov 2013 | A1 |
| 20130331985 | Felique | Dec 2013 | A1 |
| 20130332293 | Ran | Dec 2013 | A1 |
| 20130346305 | Mendes | Dec 2013 | A1 |
| 20140006451 | Mullis et al. | Jan 2014 | A1 |
| 20140012414 | Pérez et al. | Jan 2014 | A1 |
| 20140019367 | Khan et al. | Jan 2014 | A1 |
| 20140025958 | Calman | Jan 2014 | A1 |
| 20140032410 | Georgiev et al. | Jan 2014 | A1 |
| 20140032413 | Low | Jan 2014 | A1 |
| 20140040028 | King et al. | Feb 2014 | A1 |
| 20140040117 | Jain | Feb 2014 | A1 |
| 20140052524 | Andersen | Feb 2014 | A1 |
| 20140052607 | Park | Feb 2014 | A1 |
| 20140064116 | Linde et al. | Mar 2014 | A1 |
| 20140067542 | Everingham | Mar 2014 | A1 |
| 20140074714 | Melone et al. | Mar 2014 | A1 |
| 20140074723 | Kamat | Mar 2014 | A1 |
| 20140085046 | Shin et al. | Mar 2014 | A1 |
| 20140085109 | Stefik | Mar 2014 | A1 |
| 20140089016 | Smullin | Mar 2014 | A1 |
| 20140100977 | Davis | Apr 2014 | A1 |
| 20140122298 | Over | May 2014 | A1 |
| 20140136301 | Valdes | May 2014 | A1 |
| 20140136411 | Cho | May 2014 | A1 |
| 20140143055 | Johnson | May 2014 | A1 |
| 20140143074 | Kolls | May 2014 | A1 |
| 20140143137 | Carlson | May 2014 | A1 |
| 20140172179 | Baudin | Jun 2014 | A1 |
| 20140180852 | Kamat | Jun 2014 | A1 |
| 20140108108 | Artman | Jul 2014 | A1 |
| 20140188708 | Govindarajan et al. | Jul 2014 | A1 |
| 20140201066 | Roux et al. | Jul 2014 | A1 |
| 20140249995 | Ogilvy | Sep 2014 | A1 |
| 20140278989 | Calman | Sep 2014 | A1 |
| 20140279008 | Calman | Sep 2014 | A1 |
| 20140279101 | Duplan et al. | Sep 2014 | A1 |
| 20140279426 | Holman et al. | Sep 2014 | A1 |
| 20140279537 | Cicoretti | Sep 2014 | A1 |
| 20140279556 | Priebatsch | Sep 2014 | A1 |
| 20140289047 | Yee | Sep 2014 | A1 |
| 20140317611 | Wojcik et al. | Oct 2014 | A1 |
| 20140324627 | Haver | Oct 2014 | A1 |
| 20140337235 | Van Heerden et al. | Nov 2014 | A1 |
| 20140351099 | Zhu | Nov 2014 | A1 |
| 20140361872 | Garcia et al. | Dec 2014 | A1 |
| 20140378057 | Ramon et al. | Dec 2014 | A1 |
| 20150006421 | Pearson | Jan 2015 | A1 |
| 20150051977 | Lyman | Feb 2015 | A1 |
| 20150073980 | Griffin et al. | Mar 2015 | A1 |
| 20150081462 | Ozvat et al. | Mar 2015 | A1 |
| 20150088698 | Ackerman | Mar 2015 | A1 |
| 20150100152 | Trevino et al. | Apr 2015 | A1 |
| 20150105901 | Joshi et al. | Apr 2015 | A1 |
| 20150120546 | Fernandes | Apr 2015 | A1 |
| 20150120555 | Jung | Apr 2015 | A1 |
| 20150149992 | Wade et al. | May 2015 | A1 |
| 20150154579 | Teicher | Jun 2015 | A1 |
| 20150169312 | Patel | Jun 2015 | A1 |
| 20150170131 | Patel | Jun 2015 | A1 |
| 20150170132 | Patel | Jun 2015 | A1 |
| 20150170136 | Patel | Jun 2015 | A1 |
| 20150178702 | Patel | Jun 2015 | A1 |
| 20150220381 | Horagan et al. | Aug 2015 | A1 |
| 20150235202 | Zabala | Aug 2015 | A1 |
| 20150278811 | Lalchandani | Oct 2015 | A1 |
| 20150287085 | Windmueller | Oct 2015 | A1 |
| 20150302377 | Sweitzer | Oct 2015 | A1 |
| 20150302411 | Bondesen et al. | Oct 2015 | A1 |
| 20150317720 | Ramaratnam | Nov 2015 | A1 |
| 20150332029 | Coxe | Nov 2015 | A1 |
| 20150346994 | Chanyontpatanakul | Dec 2015 | A1 |
| 20150373537 | Toksvig | Dec 2015 | A1 |
| 20150379491 | Ma et al. | Dec 2015 | A1 |
| 20160012465 | Sharp | Jan 2016 | A1 |
| 20160019604 | Kobayashi | Jan 2016 | A1 |
| 20160063476 | Baldie | Mar 2016 | A1 |
| 20160086145 | Tsutsui | Mar 2016 | A1 |
| 20160092859 | Klingen | Mar 2016 | A1 |
| 20160098690 | Silvia et al. | Apr 2016 | A1 |
| 20160132870 | Xu et al. | May 2016 | A1 |
| 20160196220 | Perez et al. | Jul 2016 | A1 |
| 20160232515 | Jhas | Aug 2016 | A1 |
| 20160292469 | Ianni | Oct 2016 | A1 |
| 20160335620 | Lyons et al. | Nov 2016 | A1 |
| 20160350744 | Tang et al. | Dec 2016 | A1 |
| 20170006656 | Nacer et al. | Jan 2017 | A1 |
| 20170193508 | Patel et al. | Jan 2017 | A1 |
| 20170193478 | Dhurka | Jul 2017 | A1 |
| 20170193479 | Kamat | Jul 2017 | A1 |
| 20170330164 | Suelberg et al. | Nov 2017 | A1 |
| 20180005220 | Laracey | Jan 2018 | A1 |
| 20180197167 | Ganesan et al. | Jul 2018 | A1 |
| 20180240096 | Patel | Aug 2018 | A1 |
| 20180276674 | Ramatchandirane et al. | Sep 2018 | A1 |
| 20180315271 | Gharabegian et al. | Nov 2018 | A1 |
| 20180374076 | Wheeler et al. | Dec 2018 | A1 |
| 20190236586 | Mei et al. | Aug 2019 | A1 |
| 20190244205 | Fieglein | Aug 2019 | A1 |
| 20190244465 | Saunders et al. | Aug 2019 | A1 |
| 20200387881 | Smith et al. | Dec 2020 | A1 |
| 20210012318 | Ducoulombier | Jan 2021 | A1 |
| 20210056552 | Murray | Feb 2021 | A1 |
| 20210158309 | Mcginlay et al. | May 2021 | A1 |
| 20210375094 | Thomas et al. | Dec 2021 | A1 |
| 20220405733 | Yao et al. | Dec 2022 | A1 |
| 20230222506 | Patel et al. | Jul 2023 | A1 |
| Number | Date | Country |
|---|---|---|
| 1561508 | Jan 2005 | CN |
| 204375056 | Jun 2015 | CN |
| 105139196 | Dec 2015 | CN |
| 106803175 | Jun 2017 | CN |
| 107480975 | Dec 2017 | CN |
| 207663510 | Jul 2018 | CN |
| 109389755 | Feb 2019 | CN |
| 108367497 | Jun 2021 | CN |
| 108352094 | Sep 2021 | CN |
| 1571607 | Sep 2005 | EP |
| 2061001 | May 2009 | EP |
| 3901880 | Oct 2021 | EP |
| H1125320 | Jan 1999 | JP |
| 2002-183812 | Jun 2002 | JP |
| 2003-242401 | Aug 2003 | JP |
| 2003-323662 | Nov 2003 | JP |
| 2004-252640 | Sep 2004 | JP |
| 2004310740 | Nov 2004 | JP |
| 2005-526325 | Sep 2005 | JP |
| 2009-259226 | Nov 2009 | JP |
| 2010528716 | Aug 2010 | JP |
| 4586607 | Nov 2010 | JP |
| 2012-504273 | Feb 2012 | JP |
| 20130138637 | Dec 2013 | KR |
| WO 2003098561 | Nov 2003 | WO |
| WO2006020692 | Feb 2006 | WO |
| WO 2007015610 | Feb 2007 | WO |
| WO 2008083022 | Jul 2008 | WO |
| WO 2008083025 | Jul 2008 | WO |
| WO 2008083078 | Jul 2008 | WO |
| WO 2008083089 | Jul 2008 | WO |
| WO 2008083105 | Jul 2008 | WO |
| WO 2008083115 | Jul 2008 | WO |
| WO 2008083119 | Jul 2008 | WO |
| WO 2009070430 | Jun 2009 | WO |
| WO 2013132995 | Sep 2013 | WO |
| WO 2013177416 | Nov 2013 | WO |
| WO 2014093857 | Jun 2014 | WO |
| WO 2016123545 | Aug 2016 | WO |
| WO2016158748 | Oct 2016 | WO |
| WO 2017010936 | Jan 2017 | WO |
| WO2017010936 | Jan 2017 | WO |
| WO 2017143079 | Aug 2017 | WO |
| Entry |
|---|
| @RobocopyEs, posted Oct. 11, 2014, retrieved Feb. 13, 2018, <URL:https://twitter.com/robocopyes> 2 pgs. |
| Adams, How can stationary kiosks thrive in a mobile world?, American Banker, 2012. |
| Balan et al., mFerio: the design and evaluation of a peer-to-peer mobile payment system, Jun. 2009, 14 pgs. |
| Balfe et al., e-EMV: emulating EMV for internet payments with trusted computing Technologies, Oct. 2008, 12 pgs. |
| Bing, Bing Images Search: “dongle”, http://www.bing.com/images/search?q=dongle&FORM+HDRSC2, Dec. 5, 2013, 8 pgs. |
| Carlson, Specification, U.S. Appl. No. 60/871,898, filed Dec. 26, 2006, 169 pgs. |
| Frolick, Assessing M-Commerce Opportunities, Auerbach Publications Inc., Information Systems Management, Spring 2004. |
| Google, Chromecast, htttp://www.google.com/intl/devices/chromecast/, Dec. 12, 2013, 4 pgs. |
| How to Pay the New Way, youtube, Apr. 5, 2018, 4 pgs. |
| How will Apple's new mobile wallet Passbook impact other mobile wallets?, posted Jun. 13, 2012, retrieved Feb. 13, 2018 from <URL:https://www.quora.com/How-will-Apples-new-mobile-wallet-Passbook-impact-other-mobile-wallets>, 5 pgs. |
| Kadambi et al., Near-Field Communication-based Secure Mobile Payment Service, Aug. 2009, 10 pgs. |
| Madlmayr et al., Near Field Communication Based Mobile Payment System, Austrian Research Funding Agency, Project 811408, Mar. 6, 2008, 13 pgs. |
| Novotny, Applying RFID technology in the retail industry-benefits and concerns from the consumer's perspective, Institute of Economic Science, Eszterhazy Karoly College, Eger, Hungary, Retail Technologies for the 21 Century, innovation and competitiveness in the retail industry, 2015. |
| Nurel, Recent Developments in Wireless Network Systems, Izmir Institute of Technology, Sep. 2001, 280 pgs. |
| Patel, Final Office Action, U.S. Appl. No. 14/320,534, dated Mar. 2, 2018, 26 pgs. |
| Patel, Final Office Action, U.S. Appl. No. 14/320,534, dated Apr. 16, 2015, 21 pgs. |
| Patel, Final Office Action, U.S. Appl. No. 14/320,534, dated Nov. 30, 2016, 24 pgs. |
| Patel, Final Office Action, U.S. Appl. No. 14/321,717, dated Jun. 18, 2015, 22 pgs. |
| Patel, Final Office Action, U.S. Appl. No. 14/321,724, dated Oct. 8, 2015, 19 pgs. |
| Patel, Final Office Action, U.S. Appl. No. 14/321,724, dated Dec. 13, 2017, 22 pgs. |
| Patel, Final Office Action, U.S. Appl. No. 14/321,733, dated Nov. 14, 2014, 11 pgs. |
| Patel, Final Office Action, U.S. Appl. No. 14/335,762, dated Jun. 9, 2016, 15 pgs. |
| Patel, Final Office Action, U.S. Appl. No. 14/456,683, dated Jun. 8, 2015, 14 pgs. |
| Patel, Final Office Action, U.S. Appl. No. 14/458,192, dated Sep. 16, 2015, 26 pgs. |
| Patel, Final Office Action, U.S. Appl. No. 14/458,199, dated Jun. 24, 2015, 8 pgs. |
| Patel, Final Office Action, U.S. Appl. No. 14/641,236, dated Mar. 11, 2016, 16 pgs. |
| Patel, Final Office Action, U.S. Appl. No. 14/968,703, dated Feb. 12, 2019, 22 pgs. |
| Patel, Final Office Action, U.S. Appl. No. 15/435,228, dated Oct. 2, 2020, 24 pgs. |
| Patel, Final Office Action, U.S. Appl. No. 15/893,514, dated Jul. 22, 2021, 12 pgs. |
| Patel, Final Office Action, U.S. Appl. No. 15/956,741, dated Oct. 2, 2020, 12 pgs. |
| Patel, Notice of Allowance, U.S. Appl. No. 14/214,644, dated Jun. 10, 2014, 9 pgs. |
| Patel, Notice of Allowance, U.S. Appl. No. 14/321,733, dated Jun. 22, 2015, 8 pgs. |
| Patel, Notice of Allowance, U.S. Appl. No. 14/321,733, dated Feb. 27, 2015, 9 pgs. |
| Patel, Notice of Allowance, U.S. Appl. No. 14/335,762, dated Oct. 3, 2016, 7 pgs. |
| Patel, Notice of Allowance, U.S. Appl. No. 14/335,762, dated Mar. 30, 2015, 9 pgs. |
| Patel, Notice of Allowance, U.S. Appl. No. 14/456,683, dated Oct. 8, 2015, 15 pgs. |
| Patel, Notice of Allowance, U.S. Appl. No. 14/458,192, dated Oct. 12, 2017, 8 pgs. |
| Patel, Notice of Allowance, U.S. Appl. No. 14/458,199, dated Jan. 20, 2017, 9 pgs. |
| Patel, Notice of Allowance, U.S. Appl. No. 14/611,065, dated Mar. 26, 2018, 18 pgs. |
| Patel, Notice of Allowance, U.S. Appl. No. 14/614,336, dated Dec. 11, 2015, 8 pgs. |
| Patel, Notice of Allowance, U.S. Appl. No. 14/614,336, dated Nov. 25, 2015, 13 pgs. |
| Patel, Notice of Allowance, U.S. Appl. No. 14/968,703, dated Jun. 27, 2019, 10 pgs. |
| Patel, Notice of Allowance, U.S. Appl. No. 15/406,492, dated Mar. 11, 2020, 9 pgs. |
| Patel, Notice of Allowance, U.S. Appl. No. 15/435,228, dated Aug. 12, 2021, 9 pgs. |
| Patel, Notice of Allowance, U.S. Appl. No. 15/603,400, dated Dec. 18, 2019, 8 pgs. |
| Patel, Notice of Allowance, U.S. Appl. No. 15/603,400, dated Jun. 18, 2020, 5 pgs. |
| Patel, Notice of Allowance, U.S. Appl. No. 15/878,352, dated Oct. 23, 2020, 8 pgs. |
| Patel, Notice of Allowance, U.S. Appl. No. 16/029,483, dated Dec. 23, 2020, 21 pgs. |
| Patel, Notice of Allowance, U.S. Appl. No. 16/748,727, dated May 9, 2022, 16 pgs. |
| Patel, Notice of Allowance, U.S. Appl. No. 16/748,727, dated Jan. 20, 2022, 15 pgs. |
| Patel, Notice of Allowance, U.S. Appl. No. 16/750,477, dated Jan. 26, 2022, 14 pgs. |
| Patel, Notice of Allowance, U.S. Appl. No. 16/934,933, dated Mar. 31, 2021, 8 pgs. |
| Patel, Office Action, U.S. Appl. No. 14/320,534, dated Apr. 8, 2016, 21 pgs. |
| Patel, Office Action, U.S. Appl. No. 14/320,534, dated Oct. 29, 2014, 18 pgs. |
| Patel, Office Action, U.S. Appl. No. 14/321,717, dated Dec. 19, 2014, 16 pgs. |
| Patel, Office Action, U.S. Appl. No. 14/321,724, dated Mar. 13, 2017, 21 pgs. |
| Patel, Office Action, U.S. Appl. No. 14/321,724, dated May 15, 2015, 19 pgs. |
| Patel, Office Action, U.S. Appl. No. 14/321,733, dated Aug. 21, 2014, 9 pgs. |
| Patel, Office Action, U.S. Appl. No. 14/335,762, dated Dec. 10, 2014, 7 pgs. |
| Patel, Office Action, U.S. Appl. No. 14/335,762, dated Sep. 18, 2015, 13 pgs. |
| Patel, Office Action, U.S. Appl. No. 14/456,683, dated Jan. 2, 2015, 10 pgs. |
| Patel, Office Action, U.S. Appl. No. 14/458,192, dated Mar. 23, 2017, 26 pgs. |
| Patel, Office Action, U.S. Appl. No. 14/458,192, dated Jan. 30, 2015, 24 pgs. |
| Patel, Office Action, U.S. Appl. No. 14/458,199, dated Jan. 5, 2015, 7 pgs. |
| Patel, Office Action, U.S. Appl. No. 14/458,199, dated Mar. 28, 2016, 8 pgs. |
| Patel, Office Action, U.S. Appl. No. 14/611,065, dated Oct. 3, 2016, 19 pgs. |
| Patel, Office Action, U.S. Appl. No. 14/611,065, dated Jun. 13, 2017, 17 pgs. |
| Patel, Office Action, U.S. Appl. No. 14/614,336, dated May 27, 2015, 17 pgs. |
| Patel, Office Action, U.S. Appl. No. 14/641,236, dated Feb. 7, 2018, 19 pgs. |
| Patel, Office Action, U.S. Appl. No. 14/641,236, dated May 29, 2015, 10 pgs. |
| Patel, Office Action, U.S. Appl. No. 14/968,703, dated Aug. 7, 2018, 31 pgs. |
| Patel, Office Action, U.S. Appl. No. 15/406,492, dated Jul. 25, 2019, 16 pgs. |
| Patel, Office Action, U.S. Appl. No. 15/435,228, dated Mar. 26, 2020, 21 pgs. |
| Patel, Office Action, U.S. Appl. No. 15/603,400, dated Jun. 12, 2019, 10 pgs. |
| Patel, Office Action, U.S. Appl. No. 15/878,352, dated Jan. 24, 2020, 12 pgs. |
| Patel, Office Action, U.S. Appl. No. 15/893,514, dated Oct. 29, 2020, 17 pgs. |
| Patel, Office Action, U.S. Appl. No. 15/956,741, dated Apr. 22, 2020, 10 pgs. |
| Patel, Office Action, U.S. Appl. No. 15/956,741, dated Dec. 27, 2021, 10 pgs. |
| Patel, Office Action, U.S. Appl. No. 16/029,483, dated Apr. 27, 2020, 28 pgs. |
| Patel, Office Action, U.S. Appl. No. 16/681,673, dated Dec. 24, 2021, 20 pgs. |
| Patel, Office Action, U.S. Appl. No. 16/934,933, dated Oct. 28, 2020, 9 pgs. |
| Patel, Office Action, U.S. Appl. No. 17/216,399, dated Apr. 8, 2022, 14 pgs. |
| PayRange Inc., Communication Pursuant to Article 94(3), EP 14828617.2, dated Dec. 19, 2017, 6 pgs. |
| PayRange Inc., Communication Pursuant to Article 94(3), EP 16706931.9, dated Jun. 29, 2018, 8 pgs. |
| PayRange Inc., Communication Pursuant to Rules 161(1) and 162, EP 14828617.2, dated Sep. 21, 2016, 2 pgs. |
| PayRange Inc., Communication Pursuant to Rules 161(1) and 162, EP 16706931.9, dated Sep. 21, 2017, 2 pgs. |
| PayRange Inc., Communication under Rule 71(3) EPC, EP 14828617.2, dated Nov. 19, 2020, 8 pgs. |
| PayRange Inc., Communication under Rule 71(3) EPC, EP 17708929.9, dated Jun. 12, 2020, 5 pgs. |
| PayRange Inc., European Search Report, EP 20203134.1, dated Feb. 9, 2021, 2 pgs. |
| PayRange Inc., European Search Report, EP 21165692.1, dated Sep. 14, 2021, 9 pgs. |
| PayRange Inc., IPRP, PCT/US2014/071284, dated Jun. 21, 2016, 6 pgs. |
| PayRange Inc., IPRP, PCT/US2016/015763, dated Aug. 1, 2017, 7 pgs. |
| PayRange Inc., IPRP, PCT/US2017/015676, dated Jul. 31, 2018, 9 pgs. |
| PayRange Inc., IPRP, PCT/US2017/018194, dated Aug. 21, 2018, 17 pgs. |
| PayRange Inc., IPRP, PCT/US2019/060777, dated May 11, 2021, 7 pgs. |
| PayRange Inc., ISR/WO, PCT/US2014/071284, dated Mar. 25, 2015, 9 pgs. |
| PayRange Inc., ISR/WO, PCT/US2016/015763, dated Apr. 8, 2016, 9 pgs. |
| PayRange Inc., ISR/WO, PCT/US2017/015676, dated Apr. 18, 2017, 11 pgs. |
| PayRange Inc., ISR/WO, PCT/US2017/018194, dated Apr. 12, 2017, 10 pgs. |
| PayRange Inc., ISR/WO, PCT/US2019/060777, dated Feb. 6, 2020, 11 pgs. |
| PayRange Inc., ISR/WO, PCT/US2021/042632, dated Nov. 17, 2021, 11 pgs. |
| PayRange Inc., Notice of Reasons for Rejection, JP 2017-527886, dated Aug. 29, 2019, 10 pgs. |
| PayRange Inc., Notice of Reasons for Rejection, JP 2018-543707, dated Sep. 4, 2020, 4 pgs. |
| PayRange Inc., Notice of Reasons for Rejection, JP 2020-101558, dated Oct. 7, 2021, 2 pgs. |
| PayRange Inc., Summons to Attend Oral Proceedings, EP 14828617.2, Apr. 2, 2020, 12 pgs. |
| PayRange New Product Launch, posted at youtube.com Jun. 27, 2015, © 2016 YouTube, LLC, [online], [site visited Mar. 2, 2016]. Available from Internet, <URL: https://www.youtube.com/watch?v=NTvvV03XFeg., 1 pg. |
| Raja, A Stochastic Game Theoretic Model for Expanding ATM Services. Https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=7395687, 2015, 8 pgs. |
| Smart Vending Machine Demo at TechCrunch Disrupt 2013, posted at youtube.com Dec. 3, 2013, © 2016 YouTube, LLC, [online], [site visited Mar. 2, 2016]. Available from internet, ,URL: https://www.youtube.com/watch?v=XEz1H-gxLj8>. |
| Square Mobile Credit Card Processing for iPhone, iPod, iPad, posted at youtube.com, posting date Apr. 30, 2011, © 2016 YouTube, LLC, [online], [site visited Mar. 2, 2016]. Available from internet, <URL: https://www.youtube.com/watch?v=v6sKb3CFSKw>. |
| Kumar, Amazon gets Indian patent for auto authentication of mobile transactions, ProQuest document Id:2433007646, Financial Express, Aug. 13, 2020, 4 pgs. |
| Patel, Notice of Allowance, U.S. Appl. No. 16/681,673, dated Aug. 17, 2022, 21 pgs. |
| Patel, Notice of Allowance, U.S. Appl. No. 16/934,392, dated Sep. 28, 2022, 2 pgs. |
| Patel, Notice of Allowance, U.S. Appl. No. 17/529,111, dated Sep. 22, 2022, 9 pgs. |
| Patel, Notice of Allowance, U.S. Appl. No. 17/654,732, dated Sep. 16, 2022, 8pgs. |
| Patel, Office Action, U.S. Appl. No. 15/893,514, dated Sep. 30, 2022, 9pgs. |
| Patel, Notice of Allownce, U.S. Appl. No. 17/147,305, dated AUg. 31, 2022, 5 pgs. |
| Hoffman et al., “New options in Wireless payments”, Internet World 7.7:37 Penton Media Inc., Penton Business Media, Inc. and their subsidiaries . (Year: 2001 ). |
| Carton et al., Framework for Mobile Payments Integration, Electronic Journal of Information Systems Evaluation, 15.1: 14-24, Academic Conferences International Limited, Jan. 2012. |
| Apriva LLC Awarded Patent for System and Method for Facilitating a Purchase Transaction using a Customer Device Beacon, Jun. 7, 2017, Global IP News (Year: 2017). |
| Nurel “Recent Developments in Wireless Network Systems”, Izmir Institute of Technology, Sep. 2001, 280 pages (Year: 2001 ). |
| When the Future Feels Worse Than the Past: A Temporal Inconsistency in Moral Judgment, 15 pgs. (Year: 2010) https://citeseerx.ist.psu.edu/viewdoc/ download?doi=10.1.1.675.3584&rep=rep1&type=pdf. |
| Patel, Non-Final Office Action, U.S. Appl. No. 15/956,741, dated Feb. 27, 2023, 11 pgs. |
| Patel et al., U.S. Appl. No. 15/893,514, Notice of Allowance, dated Apr. 10, 2023, 13 pgs. |
| Heimerl et al., “Community sourcing: Engaging Local Crowds to Perform Expert Work Via Physical Kiosks”, CHI '12: Proceedings of the SIGCHI Conference on Human Factors in Computing Systems, May 2012, pp. 1539-1548, 10 pgs. https://doi.org/10.1145/2207676.2208619. |
| Patel, Notice of Allowance, U.S. Appl. No. 17/983,311, dated Jun. 28, 2023, 10 pgs. |
| EIC 3600 Search Report, STIC, Scientific & Technical Information Center, Date Completed Jun. 12, 2023, 5 pgs. |
| Patel et al., Notice of Allowance, U.S. Appl. No. 15/893,514, dated Jul. 12, 2023, 13 pgs. |
| Patel et al., Notice of Allowance, U.S. Appl. No. 17/973,506, dated Jul. 26, 2023, 13 pgs. |
| Katy Jacob, “Are mobile payments the smart cards of the aughts?”, Scientific and Technical Information Center, Report Information from Dialog, Jul. 14, 2023—11:33, ProQuest, Publication Info: Chicago Fed Letter 240: 1-4. Federal Reserve Bank of Chicago. (Jul. 2007), 9 pgs. |
| Patel et al., Notice of Allowance, U.S. Appl. No. 17/963,170, dated Aug. 4, 2023, 16 pgs. |
| USA Technologies Announces Cashless Solution to Be Offered by Blackboard Inc., Scientific and Technical Information Center, Report Information from Dialog, Jul. 25, 2023, ProQuest, Publication Info: Business Wire Jul. 18, 2007: NA, 6 pgs. |
| Patel, Non-Final Office Action, U.S. Appl. No. 18/197,071, dated Aug. 16, 2023, 9 pgs. |
| Hossain et al., “Comprehensive Study of Bluetooth Signal Parameters for Localization”, Department of Electrical & Computer Engineering National University of Singapore, 5 pgs. Email: {g0500774, weeseng}@nus.edu.sg. |
| Hands-Free Profile 1.5, Doc. No. HFP1.5_SPEC, Nov. 25, 2005, 93 pgs. |
| DEX and MDB: A Primer For Vendors | Vending Market Watch, Feb. 7, 2008, 5 pgs. https://www.vendingmarketwatch.com/print/content/10272928. |
| MDB Protocol V4.2—Multi-Drop Bus—Internal Communication Protocol, MDB / ICP, Version 4.2, Feb. 2011, 313 pgs. |
| Gruber et al., “The Commodity Vending Machine”, Forum Ware International Feb. 2005, 11 pgs. |
| Michael L. Kasavana, Innovative VDI Standards: Moving an Industry Forward, The Journal of International Management, vol. 4, No. 3, Dec. 2009, 1 pg. |
| SDFL Administrative Order 2021-33, Apr. 6, 2021, 5 pgs. |
| The New York Times by David Poque, In Arrived of 2 iPhones, 3 Lessons, Sep. 17, 2013, 4 pgs. https://www./nytime.com/2013/09/18/technology/personaltech/In-Arrived-of-2-iPhones-3-Lessons.html. |
| Cnet, John Thompson, How to use S Beam on your Samsung Galaxy S3, Jun. 21, 2012, 5 pgs. https://www.cnet.com/how-to/how-to-use-s-beam-on-your-samsung-galaxy-s3/. |
| IPhone, User Guide For iOS 6.1 Software, 156 pgs. |
| Apple Reports Fourth Quarter Results, Oct. 28, 2013, 4 pgs. |
| Apple Announces iPhone 5s—The Most Forward—Thinking Smartphone in the World, Sep. 10, 2013, 5 pgs. |
| CNet, by Marguerite Reardon, Motion sensing comes to mobile phones, Jun. 11, 2007, 4 pgs. |
| Multi-Drop Bus—Internal Communication Protocol, MDB / ICP, Version 3, Mar. 26, 2003, 270 pgs. |
| Weidong Kou, Payment Technologies for E-Commerce, University of Hong Kong Pokfulam Road, Hong Kong, ACM Subject Classification (1998): H.4, K.4.4, J.1, 339 pgs. |
| Specification for RFID Air Interface, EPC™ Radio-Frequency Identity Protocols, Class-1 Generation-2 UHF RFID, Protocol for Communications at 860 MHz-960 MHz, Version 1.2.0, EPCglobal Inc., Oct. 23, 2008, 108 pgs. |
| Baier et al., “Principles of Model Checking”, The MIT Press Cambridge, Massachusetts, London, England, 2008, 994 pgs. |
| Patel, Notice of Allowance, U.S. Appl. No. 17/443,802, dated Nov. 1, 2023, 8 pgs. |
| Patel et al., Notice of Allowance, U.S. Appl. No. 15/893,514, dated Nov. 8, 2023, 13 pgs. |
| Kevin Werbach et al., “Contracts Ex Machina”, Articles, Faculty Scholarship, University of Michigan Law School, The University of Michigan Law School Scholarship Repository, (Year: 2017), 71 pgs. https://repository.law.umich.edu/cgi/viewcontent.cgi?article=2936&context=articles. |
| Patel et al., Notice of Allowance, U.S. Appl. No. 17/973,506, dated Dec. 7, 2023, 11 pgs. |
| Bailey, Mobile-phone payment option gains ground, Dialog, STIC, Report Information from Dialog, Nov. 29, 2023, 6 pgs. |
| Patel, Non-Final Office Action, U.S. Appl. No. 17/968,672, dated Dec. 15, 2023, 14 pgs. |
| Patel, Non-Final Office Action, U.S. Appl. No. 17/973,505, dated Dec. 15, 2023, 14 pgs. |
| Patel, Notice of Allowance, U.S. Appl. No. 18/197,070, dated Dec. 20, 2023, 10 pgs. |
| “Mobile payment heads to the U.S.”, Mobile Internet 6.10:1. Information Gatekeepers, Inc. (Oct. 2004), 2 pgs. |
| “During the period 2005 to 2009, the total number of wireless data connections used for retail applications in Europe can be expected to rise from less than 1 million to around 3 million”, M2 Press Wire, Feb. 28 (Year: 2006), 3 pgs. |
| Patel, Non-Final Office Action, U.S. Appl. No. 17/973,507, dated Jan. 26, 2024, 9 pgs. |
| Patel, Notice of Allowance, U.S. Appl. No. 15/956,741, dated Jan. 18, 2024, 18 pgs. |
| IEEE Standard for Information technology—Telecommunication and information exchange between systems—Local and metropolitan area networks—Specific requirements, Part 15.4: Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for Low-Rate Wireless Personal Area Networks (LR-WPANs), IEEE, The Institute of Electrical and Electronics Engineers, Inc., 3 Park Avenue, New York, NY 10016-5997, USA, Oct. 1, 2003, 679 pgs. |
| Patel et al., Notice of Allowance, U.S. Appl. No. 17/963,170, dated Dec. 12, 2023, 11 pgs. |
| Slick self-service options: as staffing remains lean grocers are using advanced self-service checkouts and kiosks to augment customer service, Dialog, STIC, Report Information from Dialog, Nov. 30, 2023, 8 pgs. |
| Patel, Notice of Allowance, U.S. Appl. No. 18/197,071, dated Jan. 26, 2024, 10 pgs. |
| Number | Date | Country | |
|---|---|---|---|
| 20210357932 A1 | Nov 2021 | US |
| Number | Date | Country | |
|---|---|---|---|
| 62289158 | Jan 2016 | US | |
| 62081492 | Nov 2014 | US | |
| 61917936 | Dec 2013 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 16934933 | Jul 2020 | US |
| Child | 17443802 | US | |
| Parent | PCT/US2017/015676 | Jan 2017 | US |
| Child | 15893514 | US | |
| Parent | 14611065 | Jan 2015 | US |
| Child | 16029483 | US | |
| Parent | 14214644 | Mar 2014 | US |
| Child | 14335762 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 16029483 | Jul 2018 | US |
| Child | 16934933 | US | |
| Parent | 15893514 | Feb 2018 | US |
| Child | 16029483 | US | |
| Parent | 15406492 | Jan 2017 | US |
| Child | 16934933 | US | |
| Parent | 14641236 | Mar 2015 | US |
| Child | 15893514 | US | |
| Parent | 14214644 | Mar 2014 | US |
| Child | 14320534 | US | |
| Parent | 29477025 | Dec 2013 | US |
| Child | 14214644 | US |
