[go: up one dir, main page]

HK40002951B - Vending system - Google Patents

Vending system Download PDF

Info

Publication number
HK40002951B
HK40002951B HK19126343.3A HK19126343A HK40002951B HK 40002951 B HK40002951 B HK 40002951B HK 19126343 A HK19126343 A HK 19126343A HK 40002951 B HK40002951 B HK 40002951B
Authority
HK
Hong Kong
Prior art keywords
computing node
mobile computing
remote
remote delivery
user
Prior art date
Application number
HK19126343.3A
Other languages
Chinese (zh)
Other versions
HK40002951A (en
Inventor
Alfonso Javier Barragán TREVIÑO
Alfonso Javier Barragán RODRÍGUEZ
James J. Crow
Original Assignee
Vendwatch Telematics, Llc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Vendwatch Telematics, Llc filed Critical Vendwatch Telematics, Llc
Publication of HK40002951A publication Critical patent/HK40002951A/en
Publication of HK40002951B publication Critical patent/HK40002951B/en

Links

Description

Vending system
The present application is a divisional application of the invention patent application with the national application number 201480066131.8, the international application date of the invention patent application is 2014, 10 month and 2 days, and the international application number PCT/US2014/058790 is named as a vending system.
Cross Reference to Related Applications
The present application claims priority from U.S. provisional patent application No. 61/886,231 filed on month 10, 2013 and entitled "System for Centrally Controlled, locally Managed Remote Point of Sale Terminals Via SmartphoneApplications (system for a centrally controlled, locally managed remote point of sale terminal via a smart phone application)", the contents of which are hereby incorporated by reference.
The present application claims priority from U.S. provisional patent application No. 61/929,666 filed on 1/21 2014 and entitled "System for Centrally Controlled, locally Managed Remote Point of Sale Terminals ViaSmartphone Applications (system for a centrally controlled, locally managed remote point of sale terminal via a smart phone application)", the contents of which are hereby incorporated by reference.
Technical Field
Embodiments are directed to vending systems, and more particularly, and in some embodiments, user/vending system interfaces and vending operator/vending system interfaces.
Background
Historically, vending Machines (VM) and other remote point of sale (PoS) terminals have been required to be intelligent and self-sufficient devices that can operate autonomously. This is a simple task in returning to the era of electromechanical-based vending operations combined with simple coin acceptance. However, there are several new trends in the industry for making these systems more complex. Examples of these are inclusion of wireless networking devices such as General Packet Radio Service (GPRS) or Wi-Fi modems, industry standard inventory and exception reporting such as Data Exchange (DEX), multi-product/multi-package/multi-price options requiring configuration of the machine. Probably the most complex factor is the advent of cashless vending models. This simple aspect has led to the complexity and security of VMs substantially matching those of remote registers such as ATM in order to protect the credit card information of consumers.
This increased complexity does provide useful advanced functionality for the machine, but at the cost of significantly increasing capital equipment and reproducing management costs for the VM while reducing the average time between failures. In addition, VM manufacturers must develop new machine types to keep up with feature requirements. This causes scrapping of existing machines and requires significant new capital expenditures by operators to bring new features to the existing market.
Disclosure of Invention
The first aspect of the present invention discloses a system for physical delivery, comprising a plurality of remote delivery terminals, each remote delivery terminal comprising: an external chassis; a short-range communication node disposed in the external chassis; an actuator for delivering cargo contained in the external chassis; at least one remote computing node comprising means for separately storing inventory data corresponding to goods held in each of a plurality of remote delivery terminals; wherein (a) the at least one remote computing node transmits inventory data corresponding to the goods held in each of the plurality of remote delivery terminals to the one or more mobile computing nodes, (b) the short-range communication node in one of the remote delivery terminals discovers a mobile computing node of a consumer in the vicinity of the one of the remote delivery terminals, (c) the short-range communication node in one of the remote delivery terminals establishes a communication connection with the mobile computing node, (d) the at least one remote computing node receives a user selection of the goods held in one of the remote delivery terminals from the mobile computing node, (e) the at least one remote computing node sends an actuation command to the mobile computing node, and (f) the short-range communication node in one of the remote delivery terminals receives an actuation command from the mobile computing node, (g) the actuator in one of the remote delivery terminals delivers the selected goods in response to the received actuation command.
A second aspect of the invention discloses a remote computing node comprising: at least one storage medium and at least one processor coupled to the at least one storage medium; an inventory management module included in the at least one storage medium that includes first inventory data corresponding to a first remote delivery terminal and second inventory data corresponding to a second remote delivery terminal; wherein the at least one storage medium has instructions stored thereon for causing the at least one remote computing node (a) to transmit a first actuation command to the first remote delivery terminal via the at least one mobile computing node to actuate an actuator of the first remote delivery terminal to provide the first cargo to an aperture included in the first remote delivery terminal; and (b) transmitting a second actuation command to the second remote delivery terminal via the at least one mobile computing node to actuate an actuator included in the second remote delivery terminal to provide a second cargo to an aperture included in the second remote delivery terminal; wherein neither of the first and second remote delivery terminals includes a memory storing inventory data related to either of the first and second inventory data.
A third aspect of the invention discloses a method of discovering a mobile computing node comprising moving the mobile computing node to be in physical proximity to a remote delivery terminal and initiating the discovery by touching or tapping the mobile computing node to a Radio Frequency Identification (RFID) reader device in the remote delivery terminal; the remote delivery terminal in response sends a standard RFID read command to the mobile computing node.
Drawings
Features and advantages of embodiments of the invention will become apparent from the appended claims, the following detailed description of one or more example embodiments, and the corresponding drawings. Where considered appropriate, reference numerals have been repeated among the figures to indicate corresponding or analogous elements.
Fig. 1 includes a network architecture in an embodiment of the invention.
Fig. 2 includes an application server in an embodiment.
Fig. 3 includes a vending apparatus in an embodiment of the invention.
Fig. 4 includes a mobile application in an embodiment of the invention.
FIG. 5 includes a process for application installation in an embodiment of the invention.
FIG. 6 includes a process depicting a basic user experience in an embodiment of the invention.
Fig. 7 includes a process for creating a secure channel in an embodiment of the invention.
Fig. 8 includes a process for beacon discovery in an embodiment of the invention.
Fig. 9 includes a process for manual discovery in an embodiment of the invention.
Fig. 10 includes a process for Radio Frequency Identification (RFID)/Near Field Communication (NFC) discovery in an embodiment of the invention.
Fig. 11 includes an embodiment for vending machine anomaly/alert in an embodiment of the invention.
FIG. 12 includes a process to remotely update a directory/database in an embodiment of the invention.
Fig. 13a-j depict a series of Graphical User Interfaces (GUIs) that provide a user experience in an embodiment of the present invention.
13k-m depict a series of GUIs providing a user experience in an embodiment.
Fig. 14 includes a virtual reward/gift redemption and delivery process in an embodiment of the present invention.
Fig. 15 includes a process for remote delivery of gifts in an embodiment of the invention.
Fig. 16 includes a system for a retrofit legacy VM in an embodiment of the invention.
Fig. 17 includes a system for use with embodiments of the present invention.
Fig. 18 includes an embodiment of a UI and process for observing inventory of different VMs.
Fig. 19 includes a "retrofit module" in an embodiment of the present invention.
FIG. 20 includes a process for the operation of a "retrofit module" in an embodiment of the present invention.
Detailed Description
In the following description, numerous specific details are set forth, but embodiments of the invention may be practiced without these specific details. Well-known circuits, structures and techniques have not been shown in detail in order not to obscure an understanding of this description. "embodiment," "various embodiments," etc., indicate that the embodiment(s) so described may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic. Some embodiments may have some, all, or none of the features described for other embodiments. "first," "second," "third," etc. describe a common object and indicate that different instances of like objects are being referred to. Such adjectives do not imply that the objects so described must be in a given sequence, either temporally, spatially, in ranking, or in any other manner.
Embodiments include a new model for remote point-of-sale terminals that reverses this trend of increased complexity and cost in VMs by taking advantage of the ubiquitous presence of new discoveries of wireless computing nodes that can act as mobile application platforms. In this model, all or most of the business intelligence is removed from the VM and converted into interactions between a central computing node (e.g., a cloud-based processing node (distributed or non-distributed), such as, for example, a server) and a community of mobile computing nodes held by consumers at the point of sale.
Computing nodes as used herein include, for example, smart phones, cellular phones, tablet computers, distributed and non-distributed computing nodes, notebooks, nodes in the "internet of things" (e.g., internet-connected thermostats and lighting devices/systems), eyeglasses with internet connectivity, chronograph/watches with wireless connectivity, and the like.
In an embodiment, the VM connects to the mobile computing node via a proximity-based wireless protocol that is a standard feature of modern mobile computing node devices. Applications running on the mobile computing nodes communicate to the central server through, for example, 3G/GPRS and/or Wi-Fi networking. This network forms a distributed application network for one or more VMs (e.g., an operator may operate a team of VMs), but centralizes all or most of the business intelligence and management functionality to one or more server nodes. In addition, this network provides different user identification (if desired and in some embodiments) and the ability for one-to-one marketing between consumers and brands. However, other embodiments may choose not to provide a different user identification. For example, as described below, a key or ID that uniquely identifies the consumer may be used, but other embodiments may use a group key architecture such that the user is identified as a member of an acceptable group, but his or her ID within the group is not uniquely identifiable (e.g., enhanced Privacy ID (EPID)).
Embodiments include architectures that include a simple VM controller (VMC) that is substantially equivalent in complexity to conventional electromechanical servos. In other words, the present embodiment includes a controller with the ability to actuate and control simple tasks that manage the environment of the machine (e.g., a cooling mechanism for the VM) and sell the product (e.g., actuation of controls that make the product available to the purchaser). However, the VM performs little or no other advanced functions (e.g., currency and/or credit card acceptance, billing, telemetry, etc.). Thus, within the VM there is only a basic electronic system for these functions that are now performed on the server and/or mobile computing node.
While embodiments include little equipment to perform (e.g., currency and/or credit card acceptance, billing, telemetry, etc.), such embodiments include a single electronic interface, such as a Bluetooth Low Energy (BLE) transceiver (or its equivalent). The BLE transceiver wirelessly receives command and control actions that are then transmitted to the VM. In an embodiment, the VM is a standard VM having a conventional multi-drop bus (MDB) based controller card without any coin and/or banknote acceptors, without any cashless vending devices, and without any telemetry devices. Alternatively, there will be a single BLE transceiver device attached to the MDB.
In an embodiment, the BLE device may be a very small battery powered device with reduced control functionality but still acting as an application endpoint. Embodiments include BLE devices (e.g., iBeacon manufactured by Apple inc.) that transmit a proximity "beacon" signal that can be detected by compatible mobile computing node devices. The BLE device continuously transmits this beacon and is therefore always ready to transact. The transmitted beacon signal is used to "wake up" a corresponding application on the mobile computing node of a consumer in the vicinity of the BLE-enabled VM. In other words, once the consumer is close enough to the VM close to BLE enabled; the application will activate and connect to the VM through the BLE wireless protocol. Once this data connection is established, the mobile computing node application acts as a client endpoint for the sales transaction. The application sends a request (e.g., via 3G and/or Wi-Fi) to the central server to identify the purchaser, authorize the sale, collect funds, and display marketing or other promotion/loyalty information. Once authorized, the mobile computing node application instructs the BLE device in the VM to sell the product.
The mobile computing node application may act as a "dashboard" for the transaction itself. Thus, embodiments include VMs that do not have buttons or User Interfaces (UIs) for a user to interact to select goods. Such VMs may not include such UIs, but may still include a display whose interaction with the user is minimal other than pure marketing. All user interactions for selecting a product for vending in response to a user-initiated selection are between the consumer and the mobile computing node application. In such embodiments, the VM is simply a cooler (a VM for vending goods that need to be cooled) with an electronic door or product locking mechanism for dispensing the goods under control of BLE and mobile computing node applications. A UI, as used herein, is defined as a junction between a user and logic, including an interface coupled to a set of commands or menus through which the user communicates with the logic.
In an embodiment, the BLE device gathers and caches operational information about the individual VM. This information may include alarm/anomaly data, access by technicians and product restocking personnel, and/or any event data that occurs during periods of sales inactivity. This information will be relayed to the mobile computing node application when a BLE connection is established with the mobile computing node. After this connection, the information will be relayed by the mobile computing node application to the central server. All or some of the available information (e.g., physical locations of VMs and/or users, user identification, etc.) will be collected by the application and forwarded to the central server with each transaction.
In a similar manner, in an embodiment, any information that the central server wishes to send to a particular VM may be formatted and cached on the server (which may include one or more computing nodes) awaiting future consumer sessions with that VM. During this future session, the server will transmit information to that particular mobile computing node application, which will in turn relay that information to the VM itself. An example embodiment of this function would be to update the content of the marketing display for the VM or the cooling temperature for inventory within the VM. In the case of updating the marketing display, the server will format the desired display content to accommodate the display included in the VM (e.g., consider the resolution specification/capabilities of the display in the VM) and wait for the transaction session. During this session, content will be relayed to the VM via the mobile computing node and BLE connectivity.
Embodiments include processes for dynamic pricing and marketing campaigns. Information about sales prices, promotions, loyalty discounts, coupons, etc. is stored on a VM-by-VM basis (or on a VM group-by-VM group basis) and/or on a per-consumer basis (or on a consumer group basis) on a server and dynamically displayed in the mobile computing node application at the time of the sales event.
Many or all of the embodiments described above eliminate the need for separate network connectivity for each VM. Alternatively, the consumer chooses to enter this system by downloading and enabling the mobile computing node application. The mobile computing nodes to which their network is attached then become the "backhaul" network (between the VM and the server) for some or all of telemetry, sales authorization, marketing and loyalty programs, location verification of the VM, and the like.
Many or all of the embodiments described above may be scaled up or down in terms of device and functional complexity. As described above, the BLE device may be a small battery powered device. In embodiments using such BLE devices, the BLE device will be low cost and considered to be nearly disposable. This would allow the ubiquitous presence of very large associations of these BLE devices across remote assets. An example would be to enable monitoring and user interaction for non-intelligent beverage and food chiller/refrigerator devices. The use of BLE devices in this embodiment serves to boost the function of a simple cooler or refrigerator to the role of a vending machine, albeit a VM of non-conventional form. Proximity-based mobile computing node applications and a central server monitoring these devices will enable applications such as remote machine and inventory management, user identification, brand marketing, loyalty and rewards programs.
Embodiments use BLE devices with "post mix" machines, including machines used in convenience stores and restaurants, where the beverage/product is dispensed into a cup or container. Embodiments include delivery in display materials used in retail stores and supermarkets. These promotional materials are enabled with BLE devices located inside the retail environment near the products on the shelves. For example, the VM may be located in a store window on a sidewalk where a consumer may view products in the store window (e.g., after the store has been closed at night) and still purchase the products using the BLE-enabled unit.
The addition of BLE beacons to these use cases and the ability to activate associated mobile computing node applications opens up a wide range of marketing, loyalty and social networking activities that will enable direct brand-to-consumer conversations, but do so within the consumer and vendor/dealer environments. For example, embodiments rely on consumer behavior in which an associated application is (1) loaded onto a consumer's mobile computing node, and (2) licensed for active participation in this network by the consumer. To guide this behavior, loyalty or promotions may be developed that involve the consumer in a reward-based system, driving his desire to participate. This is a natural application for gambling and bonus-based actuation.
Embodiments utilize the business logic of a vending transaction so that this simplified vending event can be locally integrated into a 3 rd party mobile computing node application (e.g., the application can be an embeddable "component" for use by a 3 rd party developer). For example, embodiments include a licensing program that provides consumers with the ability to win free products as rewards for playing games or other social networking activities. Video game developers embed vending applications into games and build systems that rewards game play achievements. The product that has been won may then be delivered at the player's convenience at any time of day at any location where there is a BLE enabled VM (or at a particular location of a particular VM located, for example, at the location of a sponsor). The integration of the application with the payment and/or loyalty system or other post office system will be through an Application Programming Interface (API) connection from the central server.
Accordingly, many of the embodiments described herein include using a opt-in proxy to create a backhaul network for remote telemetry and transaction sessions. Such systems transmit business intelligence logic and subsystems from a remote point-of-sale device and into an external mobile computing node. Embodiments include a VM without buttons and without cash/credit card such that all consumer interactions with the VM are through the mobile computing node application, and all (in some embodiments) financial transactions and/or authorizations occur in the cloud-based service provider.
Embodiments provide for management of remote assets through an intermittent, proximity-oriented network. Instead of placing a modem in an asset, the VM relies on the mobile computing node of the IP connection to "meet" the asset and then utilize the connection. For example, embodiments include a delivery system for physical objects whereby a consumer is in proximity to any remote delivery terminal. In this case, the user may win a prize on the video game during his commute on the train. Upon exiting the train, the user may walk adjacent to the VM, thereby using his rewards to purchase products from the VM.
Embodiments include systems that track normalized consumption and/or consumer behavior across some or all consumption channels through proximity-based telemetry. By enabling all sales of consumption (e.g., vending, retail, restaurant, etc.) with wireless interaction devices, brands can enable a newly discovered view of consumer behavior. Activities such as consumer analysis, product promotions and/or direct marketing are implemented with such systems in a wide variety of "all channels" that have heretofore been impossible.
Fig. 1 includes a network architecture in an embodiment of the invention. The vending operator 100 is a vending operator entity. For example, this entity is responsible for creating and managing vending networks, creating and managing sales and marketing aspects of remote PoS sales, maintaining inventory levels, and/or collecting revenue from operations. The payment service 101 is an online payment service that provides direct consumer payment via credit card, loyalty program, closed loop (scripting program), etc. (e.g., payPal or electronic wallet service). Server 102 is a cloud-based node (e.g., an internet resident application server) that includes management and control logic for the network of fig. 1. Mobile software application 104 interacts with element 102 via, for example, standard HTTP/internet protocols, where elements 102 and 104 represent distributed mobile applications. Vending device 103 (e.g., VM) represents one of many vending devices or VMs that comprise part of a vending network. Mobile application 104 represents a resident application coupled to (e.g., via the cloud) or in a computing node (e.g., a smart phone) of a consumer (e.g., resident in memory included within a chassis or package of the mobile computing node). Consumer 105 is a user (e.g., human, robot) that interacts with element 104 to locate, purchase, and acquire goods from the system. The application store 106 includes a delivery mechanism through which the user 105 downloads and installs the components 104.
Various communication lines are shown between the entities of fig. 1. Communication line 116 enables delivery of element 104 to consumer 105. Element 106 may be a third party application site adapted to host the make/model of the mobile computing node of application 104. In an embodiment, element 106 may be a private application site intended for use by an enterprise or private group. Communication line 117 represents a consumer interaction with element 104 via a touch screen UI, voice commands, swipe/shake movements, etc. Communication line 114 represents the wireless communication link(s) between elements 104 and 103. These may be Bluetooth, BTL, wi-Fi, NFC, etc. Communication line 115 represents the physical contact between elements 105 and 103 when the cargo is delivered (in an embodiment, when the cargo is a physical item). Communication line 113 represents an online conversation between elements 104 and 102 in a client/server relationship. Standard mobile computing node data access methods (e.g., 3G/4G and/or Wi-Fi) may be used along with standard internet protocols and transmissions. Communication line 112 is an online conversation between elements 101 and 112 for purposes of authorizing and settling monetary aspects of vending and retail purchases. This is a secure online service using industry standard transaction protocols. Communication line 111 is the administrative and management interface between elements 100 and 102. Configuration, management, and alarm/exception reporting is accomplished through this interface. In an embodiment, business management, planning, and analysis operations for use of the vending network of fig. 1 are performed through this interface. Which in an embodiment is a standard internet/web protocol and transmission system. Communication line 110 represents an interface between elements 100 and 101 to receive all payment and settlement information for all sales performed in the network and uses standard internet protocols and transmission interfaces.
Fig. 2 includes an embodiment of vending server 102. In an embodiment, the application server 102 includes several modules. The network management module 200 controls the logical and physical network of vending devices 103, allowing identification, configuration, and modification of these devices. User management module 201 manages the subscription and lifecycle states of consumer 105 (e.g., operational states as set forth in a later figure, such as figure 5) as consumer 105 interacts with application 104 and vending device 103. The device management module 202 allows individual vending devices 103 to be managed from the standpoint of inventory/stock, abnormal and positive error lists, sales marketing efforts, and the like. The payment management module 203 provides reporting and mediation interfaces to the third party payment service 101. Inventory management module 204 provides both reporting and analysis of current inventory included within both operator 100 resources (warehouses and teams) and within the vending network of component 103 devices. The operations on site (Ops) management module 205 represents the scheduling and control of all operations on site services required to maintain inventory and operation of a network of devices for the component 103 (e.g., scheduling technicians restocking certain vending devices 103 at certain times). Marketing/offer management module 206 allows for consumer marketing and offers directed to user 105 via interactions with element 104. Transaction management module 207 represents a workflow and user interaction manager for defining and controlling the user experience of user 105 in conjunction with element 104 through the overall location, purchase, and delivery process of remotely purchased goods. Alarm/anomaly management module 208 represents the collection, prioritization, and delivery of events and anomalies (e.g., errors such as a lack of inventory in vending equipment or a faulty cooling system in vending equipment 103) that occur within the vending network of fig. 1. The operations/reports database module 209 represents transaction information, online storage of the operation information, and provision of business analysis reports.
Fig. 3 includes an embodiment of vending apparatus 103. In an embodiment, vending device 103 is a stand-alone microprocessor-controlled electromechanical device that includes various subsystems/modules as follows. The proximity detector module 300 (e.g., BLE beacon) detects the presence and relative distance of mobile computing node devices that have been enabled with the application 104. The wireless communication module 301 enables a secure, authenticated, wireless communication session between elements 103 and 104. Element 103 has a wireless communication system and may communicate only to enabled and nearby (e.g., within 450 meters) instances of element 104. These wireless communications include things such as NFC, bluetooth. The application controller module 302 utilizes element 301 to provide application client functionality to elements 104 and 102 operating in coordination with each other. The element 302 is not a stand alone smart device, but instead operates only as a slave/client to the elements 104, 102. The lock/vending actuator 303 converts the application command into a physical electromechanical action, such as triggering a lock or solenoid/servo device to deliver the product to the user 105. The "inventory for sale" module 304 represents physical or logical goods being offered and sold to the user 105 via the vending network of fig. 1. Element 304 may represent actual physical goods such as consumable food/beverage products, or may represent virtual products such as mobile phone "minutes", shipping tokens, and the like. In the latter case, element 103 is used to limit access to the delivery method of the virtual good. An example of this would be virtual goods delivered by a one-time-use Quick Response (QR) code, which is included and/or managed by element 103 as an embodiment of element 304. For example, device 103 may include a display that displays a QR code (after purchase) that includes key material to unlock additional cellular telephones minutes, access to movies on the node running application 104, and the like.
Fig. 4 includes an embodiment of mobile application 104. Mobile application 104 is logic (e.g., a computer application) that resides within (or is coupled to) a computing node and utilizes services that exist in the computing node (e.g., a 3G/4G smart phone). In an embodiment, the application 104 includes the following subsystems/modules. Proximity detection module 400 utilizes wireless beacons or other signals to detect the presence of vending device 103 as consumer 105 and application 104 approach the vending network (e.g., vending device 103). Module 400 identifies individual device 103 units and selects and establishes a dialogue with any discrete device 103 it encounters. Subscription/certificate management module 401 enables consumer 105 to manage and maintain all configuration (e.g., keys, passwords) and preference settings for use within the vending network of fig. 1. Throughout all phases of use of the vending network of fig. 1, application logic module 402 manages the transaction lifecycle of user 105 (e.g., maintains the state of the nodes on which application 104 operates during a vending operation). Module 402 manages wireless communications and application states for communicating with element 102 (e.g., via 3G/4G communications) and wireless control (e.g., bluetooth) of instances of element 103 via module 403 during remote PoS actions. The wireless application controller module 403 performs direct control of the element 103 via the modules 301 and 302. Module 403 is the "master" role of the "slave" role of element 103 and executes various layers of application logic (e.g., wireless protocols, identities, security, user and device locations, logic commands and operations, etc.). The payment credentials and application module 404 represents credentials (e.g., account information) of individuals/groups of individuals (e.g., households sharing a group key) as they relate to the third party payment service 101.
FIG. 5 includes a process for installation of an application 104 onto a compute node in an embodiment of the invention. The mobile application 104 is installed on the user's mobile computing node based on consumer demand. The service will be marketed and direct new users to application stores 106 that are appropriate for the particular mobile computing node manufacturer. The consumer 105 will initiate the download and installation of the vending mobile application 104 using standard practices (element 501) of the application store 106. Once installed, consumer 105 launches application 104 and begins all the information necessary to complete the operation (element 502). This may include user Identity (ID), preferences, and social networking information. The next stage of configuration allows consumer 105 to create an online purchase certificate with internet-based payment service 101 (element 503). In an embodiment, these credentials are not stored in 104. Service 101 provides an API through which user 105 interacts with elements 104 and 101. For example, at element 504, application 104 creates and verifies payment account information with service 101. Upon successful conclusion of element 504, element 105 has a verified account within element 101 that can be used to authorize purchase and settlement funds for such online purchases. Upon successful payment verification, element 104 creates and causes a service account to be implemented for user 105 within vending service provider 102 (element 505). Successful service account creation (element 506) results in graphical and/or audio feedback (element 507) provided by element 104 to user 105 and initiation of services within the vending system. Application 104 uses the tour service (element 508), whereby application 104 enters a proximity detection mode/state until the presence of vending device 103 is detected (e.g., device 103 wakes up application 104).
FIG. 6 includes a process of depicting a basic user experience in an embodiment of the invention. After device 103 is discovered by vending device/machine 103, vending device 103 and mobile application 104 enter a device discovered state (element 601) and establish a secure communication channel (element 602), as described elsewhere herein (e.g., using Diffie-Hellman based key exchange techniques). For the purpose of describing the present embodiment, it is assumed that only a single device 103 has been found, but the present description also applies to the processing of a plurality of devices 103 (i.e., the devices 103 may be in a device found state while having more than one device 103). Element 104 requests a device information record from element 102 (element 603). The record includes relevant information about the element 103, such as spot inventory, pricing, marketing/advertising content, etc. When element 104 makes this request, the request includes ID information for user 105. Element 102 uses this user information to generate preferences, user messaging, or other personalized information for user 105. Some or all of the requested information is returned (element 604) by element 102 to element 104. Element 104 then utilizes the received information to present the product offer(s), loyalty/preference advice, marketing/advertising, etc. to user 105 (element 605). An embodiment of this operation is depicted, for example, in fig. 13. Ultimately, the user 105 makes a product selection for purchase, selects a desired payment method, and proceeds to "pay" (element 606), which is an actual purchase event. Element 104 formats the online payment transaction in the format of the requested payment method and sends this transaction to the online payment gateway for element 101 (element 607). Element 101 then processes the payment request and returns to the "authorized" or "unauthorized" state. For purposes of this description, it is assumed that element 101 returns an "authorized" state to element 104 (element 608). Upon receipt and verification of payment authorization by element 104, a delivery/vending actuation command (element 609) is sent (from application 104) to element 103 to deliver the entity. Note that element 609 will be specific to the type of device 103 and the type of cargo delivered. For purposes of this description, element 609 is considered a remote command to unlock a door or drawer that includes the product to be purchased (or in other embodiments, such as displaying a QR with purchased content encoded therein, etc.). Upon receipt of the actuation command (element 609), element 103 performs the requested action and delivers the product (element 610) and verifies its delivery by element 103. This verification may occur in several forms. In an embodiment, element 103 has a sensor array, such as an optical sensor or a weight measurement sensor, that detects product removal from 104. The user 105 receives the goods (element 610) and the verification delivery status is relayed by element 103 to element 104 (element 613). Element 104 formats the transaction session and transaction record and transmits (element 611) this information to element 102. Element 102 uses this information to update all information about elements 105, 104, 103, 101 (element 614). This portion of the process ends with element 104 displaying a confirmation/thank you User Interface (UI) to user 105 (element 612), and then all devices revert to normal state.
Fig. 7 includes a process for creating a secure channel in an embodiment of the invention. The application 104 and vending device 103 require secure communication channels (element 702) to exchange purchase and currency information with each other. In an embodiment, there is also a need for a persistent non-secure channel that will be used to enable key exchange and creation of secure channels. The following sequence may be used for techniques (e.g., BLE) in which services may be defined in order to provide secure services and non-secure services. In the normal state, element 103 stores locally (via non-secure channel 701) an advertisement unique identifier (UUID). Since application 104 remains in proximity detection mode and is present within the signal range of element(s) 103 device, element 104 will detect UUID advertisement when in close proximity to device 103 (element 703). Element 104 will verify the format of the UUID and generate a cryptographic temporary value. Element 104 will relay the temporary value to element 103 via the unsecure channel (element 704). Here, both element 103 and element 104 will use the UUID, temporary value, and private hash (hash)/code to generate the key value (elements 705, 706). The logic of this approach represents the shared secret between elements 103 and 104 and will result in the same key value being generated independently by elements 103 and 104. Various embodiments may use different protocols to generate symmetric keys (e.g., diffie-Hellman, SIGn and MAc (Sigma), etc.). Here, elements 103 and 104 may begin using secure channel 702 by encrypting the payloads for all traffic on this service using a derived key (element 708), such as Advanced Encryption Standard (AES). Note that the non-secure payload may be exchanged via channel 701 at any time (element 707). Element 104 may also regenerate the temporary value and resend the key generation command. This allows for increased security by allowing for rolling key values based on time or other event information.
Fig. 8 includes a process for beacon discovery in an embodiment of the invention. Vending device 103 may be discovered and/or located by application 104 in one of several ways. Note that each of these methods may be used to discover one or more devices 103. This means that upon completion of the device discovery state, the element 104 may have a list of one or more devices 103 that have been discovered.
In an embodiment, vending device 103 includes low-level wireless beacon services that are used to detect and enable device discovery. Consumer 105 owns a computing node (e.g., a smart phone) with an executing instance of element 104. As user 105 enters the beacon signal range of element 103, element 104 detects and verifies the beacon signature (element 801) as a valid instance of element 103. In response, element 104 activates and notifies user 105 that one or more instances of element 103 are nearby via a notification and selection screen and/or audio (element 802). The user 105 confirms the interest by selecting and/or confirming an action (element 803). Here, a particular instance of 103 is associated with an element 104, 105, and has been discovered (element 804).
Fig. 9 includes a process for manual discovery in an embodiment of the invention. In an embodiment, the manual discovery begins with the initiation of a sequence by consumer 105. The user 105 opens the element 104 (element 901) and initiates a search function within the element 104 via the UI (element 902). Element 104 makes a discovery request to element 102 (element 903). This request includes contextual information about the user 105 and the element 104, such as GPS derived location, identity, and other search/discovery criteria. Element 102 performs a search for devices 103 that best match the request and responds with a subset of devices 103 within the network (element 904). Element 104 presents this list to user 105 via the application UI (element 905), possibly with the maps and directions of the various devices 103. The user 105 responds to this by moving towards the nearest or desired 103 device (element 906). In an embodiment, all devices 103 actively "beacon" their UUIDs. As user 105 approaches the vicinity of one or more of devices 103, element 104 identifies and validates the beacon and UUID (element 907). Element 104 presents the user 105 with "welcome" and "complete" messages (element 908), and elements 104, 103 enter the device found state (element 909).
Fig. 10 includes a process for Radio Frequency Identification (RFID)/Near Field Communication (NFC) discovery in an embodiment of the invention. Device 103 may be discovered by initiating contact using an RFID/NFC device resident in a computing node (e.g., a smart phone). The user 105 is in close physical proximity to the element 103 and begins by touching or tapping (or being placed in close proximity) a computing node (e.g., a smart phone) to an RFID reader device in the element 103 (element 1001). Element 103 in response sends a standard RFID read command to the node (element 1002). This initiates two actions: element 1003 starts application 104 running in the compute node (or verifies that application 104 is running) and element 1004 starts BLE service (or verifies that BLE service has been started or is running). Once elements 1003, 1004 are complete, element 103 transmits a UUID to element 104 (element 1005) and the system enters a device discovered state.
Fig. 11 includes an embodiment for device abnormality/alarm in an embodiment of the invention. Since vending device 103 does not include telemetry devices capable of WAN communication (in some embodiments), a system for establishing cooperative relaying of information between element 103 and server application 102 is as follows. Element 103 encounters a local alarm, anomaly, or other event that should be relayed to element 102 (e.g., related to inventory or cooling systems for device 103). Element 103 captures information about the event as well as ancillary data such as time stamps and other local conditions. Element 103 queues this event in local storage and possibly places the event in a log with other queued events awaiting transmission. The user 105 encounters 103 by normal practice and enters the device found state as described above (element 1101). Elements 104 and 103 establish secure communication channel 1102 as described above. When there is this connection, element 103 relays some or all of the queuing information to 104 (element 1103). Since this may not be a purchase driving engagement for user 105, a permission sequence is initiated in which element 104 requests permission to relay information using the wireless (e.g., 3G/4G/Wi-Fi) network of element 104 (element 1104). When permission is granted (element 1105), element 104 initiates a series of one or more transactions as needed based on the exception or event from element 103 (elements 1106, 1107, 1108). In one embodiment, a single transaction is as follows. Element 104 transmits the queued event to element 102 (element 1106), which processes the event. Element 102 generates a response, which may include a state and/or command intended for element 103 to execute. Element 102 relays this response to element 104 (element 1107), which then transmits this information to element 103 (element 1108). Alternatively, the command may generate additional information from element 103, which is relayed back to element 104 (element 1111), and the sequences 1106, 1107, 1108 will repeat until all commands and states have been processed. Element 104 informs user 105 of the completed operation with the UI element (element 1109), which may be combined with rewards for allowing element 104 to utilize the WAN network interface. All devices enter a normal state upon completion (element 1110).
FIG. 12 includes a process to remotely update a directory/database in an embodiment of the invention. Since vending device 103 does not include WAN communication devices (in an embodiment), a system of cooperative relaying of information is established between elements 103 and 102. When element 102 has the need to send a command, configuration, or other information to element 103, the sequence is as follows in an embodiment. Element 102 prepares a queuing request destined for element 103 through user interaction or some time/event based logic (element 1201). Element 102 maintains separate queues for some or all devices 103 and the queues may include several pending requests. The user 105 encounters the element 103 by normal practice and enters the device found state as described above. Elements 104 and 103 enter a secure communication state as described above (see fig. 7). With this connection, element 104 makes a standard device request for element 102 (element 1202). Along with standard device information (e.g., sales inventory, pricing, etc.), element 102 samples the event queue for a particular device 103. If there is information in the queue, element 102 relays the information to element 104 as part of the response information (element 1203). Element 104 then delivers the queued event information to element 103 (element 1204), which then returns a response to element 104 (element 1205). Element 104 returns response data to element 102 (element 1206). Element 102 updates the database and device directory to reflect the queued event information and delivery of the response data (element 1207), and all devices enter a normal state.
13a-j depict a series of GUIs in an embodiment that provide a user experience (see, e.g., FIG. 6). Fig. 13a depicts a user having vending application 104 on their computing node in the vicinity of vending device 103 (but not linked or found by application 104). Application 104 refers to "VB," which for purposes of this discussion is an abbreviation for "vending box. Fig. 13b depicts application 104 and device 103 participating in device discovery (see, e.g., element 601 of fig. 8 or 6), resulting in elements 103 and 104 successfully discovering each other and each entering a device discovered state. Fig. 13c depicts the application 104 and the device 103 participating in creating a secure communication channel with each other (see, e.g., element 602 and general map 7 of fig. 6). Fig. 13c shows an "ID" passed between elements 103, 104, which is similar to block 703 of fig. 7. Fig. 13d corresponds to element 603 of fig. 6 and fig. 13e corresponds to element 604 of fig. 6. Fig. 13f corresponds to element 605 of fig. 6. Fig. 13g shows how the same application 104 may also use a different device 103 (shown in fig. 13g as device "E", while fig. 13c corresponds to device "a"). Fig. 13h, 13i and 13j correspond to fig. 13d, 13E and 13f, but again refer to device E instead of device a. As a result, fig. 13j shows a smaller selection of products (i.e., six products are available for device a, but only five products are available for device E). A smaller product offer may indicate that the previously available sixth product is now out of stock and thus is no longer listed as an option. Also, the backgrounds for fig. 13f and 13j are different from each other to illustrate how presentation and general marketing may be different for different devices or different groups of devices.
13k-m depict a series of GUIs that provide a user experience (see, e.g., FIG. 6) in an embodiment. Fig. 13k is similar to either of fig. 13f and 13 j. However, FIG. 13l illustrates how product specific information may be quickly made available to users based on the latest information (e.g., dynamically priced, whereby a price of $1.25 may be reduced in the "non-business hours" of the morning to entice a purchase). Fig. 13m illustrates a "thank you" UI reminding the user of the upcoming product delivery.
Fig. 14 includes a virtual reward/gift redemption and delivery process in an embodiment of the present invention. Embodiments enable rewards and delivery mechanisms that can be used to redeem virtual rewards and/or gifts for physical objects and allow remote delivery of such goods remotely to the intended recipient. Examples include a user winning a prize in a mobile video game and then receiving an entity as he/she encounters a local delivery location. User/player 1406 interacts with computing node (e.g., smart phone) 1405 (element 1412), which includes both video game application 1404 and vending mobile application 1414 (separate from each other in some embodiments and included within one another in additional embodiments). As user 1406 completes the performance in video game 1404, rewards are earned in return. The game 1404 may optionally report this status to the game server 1401 (element 1407, which may be included in the device server or vice versa in other embodiments), or may report this status directly to element 1414 via an inter-procedure call, uniform Resource Identifier (URI) resolution, or the like (element 1409). In either case, vending server 1402 receives the credit token. In the event of a contact from server 1401, a session between elements 1401 and 1402 is established (element 1408) and a token is exchanged. In the case of direct inter-application contact, element 1414 receives the enablement from element 1404 and then element 1414 directly contacts element 1402 via path 1410. Upon receipt of the token from either source, element 1402 verifies the identity of user 1406, processes any loyalty and/or rewards policies or rules, and returns a verified response to server 1401 and/or application 1414. Finally, element 1404 receives the enablement notification and displays this status to user 1406 (element 1412) to show that user 1406 is eligible to receive physical delivery (or non-physical delivery, such as rewards encoded within a barcode such as a 2D or 3D (holographic) QR code) from the vending network. Here, user 1406 may enter a device discovery state as described above. Upon device discovery, user 1406 enters the process described in the "basic user experience" of FIG. 6, where the process continues normally until element 606. As an alternative to payment selection and payment sequence, application 1414 displays credit or "free" product delivery and eliminates elements 607, 608 because payment is not required. Upon verification, application 1414 interacts with component 1403 as usual to actuate and deliver the product (element 1411). Element 1414 updates element 1402 (element 1410) upon completion and all devices enter a normal state.
Fig. 15 includes a process for remote delivery of gifts in an embodiment of the invention. Embodiments enable secure, authenticated remote delivery of physical objects (or non-physical delivery, such as rewards encoded within a QR code such as 2D or 3D (holographic)) from a "gift-giver" entity to a "gift-receiver" entity, where the two parties are in different and even unknown physical locations. The examples present the gift and receipt of the physical object and proceed as follows. The gift giver 1501 has a computing node (e.g., smart phone) 1504 that includes vending mobile applications 1505 (or non-mobile versions of applications operating on, for example, a personal computer). Alternatively, user 1501 may utilize local browser 1515 within element 1504. In the case of application 1505, user 1501 interacts with elements 1505 and 1507 (element 1506) to complete the identification, selection of user 1502 as the recipient, selection of the product of the gift to be delivered, and so forth. Payment for the gift is effected via element 1517, where element 1505 uses the stored credentials of user 1501 to authorize payment of the goods using payment gateway 1516. In the case of element 1515, user 1501 interacts with a web application (similar to application 1505 in terms of related functionality for the process of FIG. 15) provided by element 1507. Selecting user 1502 as the recipient, selecting a product to be gifted, and paying for the product using element 1516 are all implemented via elements 1506, 1517 using standard HTTP/HTTP sweb protocols and web application technologies. In either case, element 1507 processes the gift token and stores it in a database to be delivered to user 1502. This action causes a transaction completion UI to be delivered to the user 1501 and optionally a push notification to be generated and delivered to the user 1502 to announce the availability of the pending gift. The user 1502 has a computer node (e.g., internet-connected glasses or watches, smart phones, etc.) 1510 that includes (or is coupled to) a mobile application 1511. The user 1502 receives a push notification or detects a pending gift delivery upon actuation of element 1511. In either case, the user 1502 and element 1511 enter the device discovery state described above. Upon device discovery, the user 1502 enters the flow described in FIG. 6, where the flow continues normally until element 606. As an alternative to payment selection and payment sequence, element 1511 displays "gift" product delivery and eliminates elements 607, 608 because payment is not required (although those elements may still be used if the gift only meets a portion of the cost of the item or service to be sold). Upon verification, element 1511 interacts with element 1513 as usual to actuate and deliver the product (element 1512). Element 1511 updates element 1507 upon completion (element 1508), and all devices enter a normal state. Alternatively, element 1507 may generate a notification back to user 1501 as verification when delivered to user 1502.
Fig. 16 includes a system for a retrofit legacy VM in an embodiment of the invention. Embodiments allow for the feature discussed herein to enable an existing set of legacy VMs by "retrofitting" a module 1610 (which is new and an embodiment of the invention) to a legacy VM architecture (see element 1601 for an example of a legacy VM architecture). In a conventional architecture, VM 1601 includes a series of peripherals connected to a standard bus interface, such as a multi-drop bus (MDB) 1603. These peripheral devices provide separate functions to VMC 1609 and together form a complete set of features for the separate machine. These include, without limitation, a coin acceptor/change provider 1604, a currency note acceptor 1605, a magnetic credit card swipe reader 1606, a smart card NFC/RFID reader 1607, and a WAN telemetry device 1608. With the present embodiment, some or all of these components (e.g., elements 1603, 1604, 1605, 1606, 1607, 1608, and/or 1609) may be removed and replaced with an element 1602 having (in the present embodiment) an MDB and an attachment module 1610 (element 1611). With the replacement of the components described above, element 1610 performs simulation of some or all of the functional commands and response information for the MDB of each of these replaced elements. In this mode, the VMC element 1609 does not require any modification or change, and instead operates in the same mode as before replacement. VMC component 1609 senses the active protocols on the MDB for that role as component 1610 emulates each component. In this mode, full functionality of vending machine element 1601 is achieved, but with far fewer components. Note that the user experience and functionality is different between elements 1601 and 1602 (e.g., a substantially freestanding vending versus mobile computing node (e.g., smart phone) enabled vending network), but the basic VM units are the same (e.g., in terms of stock storage and servomotors to open the door and dispense the real object), and the vendor's investment in the traditional VM architecture is preserved. Component 1610 emulates some or all aspects of stand-alone device 103 by emulating a desired set of MDB attached peripherals to adequately control VMC 1609 using MDB standard commands (see fig. 1). Some embodiments provide an additional interface between elements 1610 and 1609 in addition to that provided by the standard MDB. This interface 1612 may be used for direct control of 1609 or 1602 as desired. Such a direct interface element 1612 may include, but is not limited to, a serial DEX interface, direct button/display control, temperature/temperature control sensing and/or control, compressor and/or lighting control, and the like.
Fig. 19 includes a "retrofit module" in an embodiment of the present invention. This figure presents an embodiment of the module 1610 presented above with respect to fig. 16. The module 1610 includes elements from embodiments of the vending apparatus 103 such as, for example, a proximity detection module 300 (see, e.g., fig. 8), a wireless communication subsystem and session establishment module 301 (see, e.g., fig. 7), and an application controller 302, which can be a slave module to the mobile application 104. Embodiments of the modules 300, 301, 302 and/or processes performed by such modules are described above. In addition, embodiments of module 1016 include a national automated sales association (NAMA) standard MDB optoelectronic interface 1901 (to dock MDBs 1603) and a device simulation library 1902 that is capable of guiding MDB-level simulations of industry-specific MDBs attachable devices. By way of example, element 1902 includes logic and state management capabilities to directly simulate a physical coin acceptor device (or banknote acceptor, etc.), such that VMC 1609 likewise recognizes logic 1902 and interacts with logic 1902 (e.g., directly or indirectly via direct VMC interface module 1612 in some embodiments) as if module 1610 were a real physical coin acceptor device. In this manner, logic 1902 is able to simulate the presence of various physical devices under the control of mobile application 104 as needed to fully automate the functions of vending machine 1601.
FIG. 20 includes a process for the operation of a "retrofit module" in an embodiment of the present invention. For example, fig. 20 includes an embodiment of a sequence of events for a retrofit module in a legacy VM, such as a retrofit VM 1602. With retrofit module 1610, conventional VMC1609 does not need to change configuration to support this retrofit mode of operation. Module 1610 provides a simulated and/or emulated local environment such that VMC1609 operates as usual (i.e., as it would with a conventional VM component (e.g., coin acceptor, banknote acceptor, etc.) coupled thereto. The operations of fig. 20 begin with device discovery (e.g., fig. 8), communication session establishment (e.g., fig. 7), product presentation (e.g., fig. 6), product selection (e.g., fig. 6), and payment authorization (e.g., fig. 6).
However, there is indeed a certain difference between the operation of vending device 103 and the operation of the converted VM using module 1610 (i.e., system 1602 has a difference in operation from device 104). For example, some differences are in interactions with a conventional MDB-based VM (e.g., VM 1601) that has been retrofitted with a module 1610 (e.g., rendering VM 1602). As shown in fig. 20, consumer 105 initiates an authorized sale according to the series of events previously described (see fig. 6-8) (element 2001). The mobile application 104 instructs the module 1610 to dispense the product (element 2002). Here, module 1610 begins MDB simulation (element 2003) of a series of standard devices (e.g., elements 1604, 1605, 1606) such that VMC1609 "sees" a standard VM sequence known to those skilled in the art. In this example, element 1902 simulates the protocols and status of a conventional coin acceptor 1604 that has been presented with sufficient currency to fulfill a sale. Other devices such as banknote acceptor 1605, cashless device 1606, RFID token 1607, and/or closed loop vending devices may be simulated in the same manner. Module 1902 injects peripheral device states and/or conditions (e.g., the simulated state and/or conditions of device 1604) into VMC1609 such that VMC1609 causes actuation of the product dispenser, which in turn delivers the sold product. This actuation may be performed by MDB simulation as shown in element 2003, or it may be, for example, an additional simulation simulating the pressing of a physical button, causing VMC1609 to sense a normal product selection event. In either case, the combination of the simulation of the currency acceptance and the simulation of the selection button press causes VMC1609 (or equivalent controller/processor) (element 2004) to effect actuation of physical device(s) (e.g., servo motor, locking mechanism, etc.) local to the VM (e.g., element 1604) and dispensing of the product to consumer 105 (element 2006). Conventional VMC1609 may communicate back to module 1610 a successful product allocation (element 2007), with module 1610 relaying or otherwise indicating success to application 104 (element 2008). Application 104 confirms the transaction with consumer 105 (element 2009) and then proceeds to normal after-market processing, as described in fig. 6. After completion, all devices enter a default state.
Embodiments of the invention include a vending system that includes a proximity detection module, a wireless communication module, an MDB interface, a device simulation module, and at least one storage medium having instructions stored thereon for causing the system to communicate to a VMC an MDB-level simulation of a status of at least one of a physical coin acceptor device, a banknote acceptor, and an RFID reader.
Thus, various embodiments are described herein, and those embodiments provide various advantages.
Embodiments include a distributed network of vending/point-of-sale machines that includes a simple VM that contains minimal control logic, where some or all of the business intelligence (e.g., inventory management, sales records, currency handling, and change/refund) does not exist in the VM.
Embodiments include a distributed network of vending/point-of-sale machines that includes a simple VM that includes a control system, where the non-intelligent VM is under direct control of a mobile computing node application and an internet resident server application.
Embodiments include a distributed network of vending/point-of-sale machines including simple VMs without a local user interface.
Embodiments include a distributed network including vending/point-of-sale machines including simple VMs that include a vending system, wherein all user interactions and experiences occur through UI elements included within a mobile computing node application.
Embodiments include a distributed network of vending/point-of-sale machines including simple VMs, wherein machine sales and product inventory control are not managed locally and autonomously by the machine. Alternatively, all machine aspects are controlled by a combination of mobile computing node applications and cloud-based server applications.
Embodiments include a distributed network of vending/point-of-sale machines that includes a simple VM that does not include an additional communication system in addition to a single BLE communication function used to communicate with mobile computing node applications in both secure and non-secure modes.
Embodiments include a distributed network of vending/point-of-sale machines that includes a simple VM that uses a 3G/4G/Wi-Fi data connection of a computing node (e.g., a smart phone) to communicate all machine and application related information and alerts.
Embodiments include a distributed network of vending/point-of-sale machines that incorporate queuing of various collected information by proximate remote point-of-sale terminals that are expected to cooperate to mobile computing node applications, thereby detecting proximity and relaying the queued information from the remote PoS to the computing node and then from the computing node to an internet resident data collection service.
Embodiments include a distributed network of vending/point-of-sale machines that incorporate queuing of approaching information intended for delivery by a central application or service to unconnected remote PoS devices to be used in cooperation with mobile computing node applications, thereby detecting the approaching and relaying information from the central service to the mobile computing nodes and then from the mobile computing nodes to the remote PoS devices.
Embodiments include a distributed network of vending/point-of-sale machines that incorporate an online payment system under the control of a computing node (e.g., smart phone) application to authorize and mediate sales.
Embodiments include a distributed network of vending/point-of-sale machines that incorporates a cloud-based server that maintains all sales, inventory, alert, anomaly information for two separate machines as an aggregated network.
Embodiments include a distributed network of vending/point-of-sale machines that incorporate an interactive console that displays status and conditions of all business and network operation related information.
Embodiments include a distributed network of vending/point-of-sale machines in which direct branding marketing to users is facilitated during sales transactions via the incorporation and coordination of user profiles, locations, preferences, and the like.
Embodiments include a distributed network of vending/point-of-sale machines that incorporate system redemption of virtual goods to physical objects by allowing delivery of the physical objects based on proximity to a nearest VM or other preferred criteria related to a remote delivery terminal.
Embodiments include a distributed network of vending/point-of-sale machines in which an individual may give a gift to another individual regardless of the physical location of each individual. The gift giver may utilize a mobile application consistent with the PoS terminal enabled or the giver may use a standard web-accessible application. The gift receiver will use the smart phone application and be directed to the device providing the gift at the remote location based on the recent proximity or some other preferred criteria.
Embodiments include a distributed network of vending/point-of-sale machines that incorporate a system that allows for "gambling" of the vending, wherein the physical object is "won" during the course of defined and programmed user activity. The system may be an add-on to existing computing node (e.g., smart phone) games and applications as a bonus system for playing games or other desired user behavior.
Embodiments include a distributed network of vending/point-of-sale machines that incorporate a system in which a conventional VM including a VMC, an MDB peripheral bus, and a conventional currency acceptor may be retrofitted with the wireless sales and product supply systems described herein.
Embodiments discussed herein (e.g., elements 103, 104, 102) may utilize a system such as the system of fig. 17 discussed below. Indeed, embodiments may be used in many different types of systems. For example, in one embodiment, a communication device may be arranged to perform the various methods and techniques described herein. Of course, the scope of the invention is not limited to communication devices, and other embodiments may alternatively be directed to other types of apparatus for processing instructions.
Program instructions may be used to cause a general-purpose or special-purpose processing system that is programmed with the instructions to perform the operations described herein. Alternatively, the operations may be performed by specific hardware components that contain hardwired logic for performing the operations, or by any combination of programmed computer components and custom hardware components. The methods described herein may be provided as (a) a computer program product that may include one or more machine-readable media having stored thereon instructions that may be used to program a processing system or other electronic device to perform the methods, or (b) at least one storage medium having stored thereon instructions for causing the system to perform the methods. The term "machine-readable medium" or "storage medium" used herein shall include any medium that is capable of storing or encoding a sequence of instructions (transitory medium, including signals, or non-transitory medium) for execution by the machine and that cause the machine to perform any one of the methodologies described herein. The term "machine-readable medium" or "storage medium" shall accordingly include, but not be limited to, memories such as solid-state memories, optical and magnetic disks, read-only memories (ROMs), programmable ROMs (PROMs), erasable PROMs (EPROMs), electrically EPROMs (EEPROMs), magnetic drives, floppy disks, compact disk ROMs (CD-ROMs), digital Versatile Disks (DVDs), flash memory, magneto-optical disks, and more exotic media such as machine-accessible biological state retention or signal retention storage. The medium may include any mechanism for storing, transmitting, or receiving information in a machine-readable form, and the medium may include media through which program code may pass, such as antennas, optical fibers, communication interfaces, and the like. The program code may be transmitted in the form of packets, serial data, parallel data, etc., and may be used in compressed or encrypted format. Moreover, it is often worth mentioning in the art that software, in one form or another (e.g., program, procedure, process, application, module, logic, etc.), acts or causes a result. Such expressions are merely a shorthand way of stating the execution of the software by a processing system cause the processor to perform an action or produce a result.
Referring now to FIG. 17, shown is a block diagram of a system embodiment 1000 in accordance with an embodiment of the present invention. The system 1000 may be included in, for example, computing nodes such as cellular telephones, smart phones, tablets, ultrabooks, notebooks, laptops, personal digital assistants, and mobile processor-based platforms.
A multiprocessor system 1000 is shown that includes a first processing element 1070 and a second processing element 1080. While two processing elements 1070 and 1080 are shown, it should be understood that embodiments of system 1000 may also include only one such processing element. System 1000 is shown as a point-to-point interconnect system in which a first processing element 1070 and a second processing element 1080 are coupled via a point-to-point interconnect 1050. It should be understood that any or all of the illustrated interconnects may be implemented as a multi-drop bus rather than a point-to-point interconnect. As shown, each of processing elements 1070 and 1080 may be multi-core processors, including first and second processor cores (i.e., processor cores 1074a and 1074b and processor cores 1084a and 1084 b). Such cores 1074, 1074b, 1084a, 1084b may be configured to execute instruction code in a manner similar to the methods described herein.
Each processing element 1070, 1080 may include at least one shared buffer memory. The shared buffer memory may store data (e.g., instructions) utilized by one or more components of the processor, such as cores 1074a, 1074b and 1084a, 1804b, respectively. For example, the shared buffer memory may locally cache data stored in memories 1032, 1034 for faster access by components of the processor. In one or more embodiments, the shared buffer memory may include one or more mid-level buffer memories, such as level 2 (L2), level 3 (L3), level 4 (L4), or other levels of buffer memory, last level buffer memory (LLC), and/or combinations thereof.
While only two processing elements 1070, 1080 are shown, it should be understood that the scope of the invention is not so limited. In other embodiments, one or more additional processing elements may be present in a given processor. Alternatively, one or more of the processing elements 1070, 1080 may be elements other than processors, such as accelerators and/or field programmable gate arrays. For example, the additional processing element(s) may include the same additional processor(s) as the first processor 1070, additional processor(s) heterogeneous or asymmetric to the first processor 1070, accelerators (such as, for example, graphics accelerators or Digital Signal Processing (DSP) units), field programmable gate arrays, or any other processing element. There may be various differences between the processing elements 1070, 1080 in terms of a spectrum of advantage metrics including architecture, microarchitecture, thermal, power consumption characteristics, etc. These differences may manifest themselves effectively as asymmetry and heterogeneity between the processing elements 1070, 1080. For at least one embodiment, the various processing elements 1070, 1080 may reside in the same die package.
The first processing element 1070 may also include memory controller logic (MC) 1072 and point-to-point (P-P) interfaces 1076 and 1078. Likewise, second processing element 1080 may include an MC 1082 and P-P interfaces 1086 and 1088.MC 1072 and 1082 couple the processors to respective memories, namely a memory 1032 and a memory 1034, which may be portions of main memory locally attached to the processors. While MC logic 1072 and 1082 is shown as being integrated into processing elements 1070, 1080, for alternative embodiments MC logic may be separate logic external to processing elements 1070, 1080 rather than integrated therein.
The first processing element 1070 and the second processing element 1080 may be coupled to an I/O subsystem 1090 via P-P interfaces 1076, 1086 via P-P interconnects 1062, 10104, respectively. As shown, I/O subsystem 1090 includes P-P interfaces 1094 and 1098. In addition, I/O subsystem 1090 includes an interface 1092 to couple I/O subsystem 1090 with high performance graphics engine 1038. In one embodiment, a bus may be used to couple graphics engine 1038 to I/O subsystem 1090. Alternatively, a point-to-point interconnect 1039 may couple these components.
In turn, I/O subsystem 1090 may be coupled to first bus 10110 via an interface 1096. In one embodiment, first bus 10110 may be a Peripheral Component Interconnect (PCI) bus, or a bus such as a PCI express bus or another third generation I/O interconnect bus, although the scope of the present invention is not so limited.
As shown, various I/O devices 1014, 1024 may be coupled to the first bus 10110, along with a bus bridge 1018 which may couple the first bus 10110 to a second bus 1020. In one embodiment, the second bus 1020 may be a Low Pin Count (LPC) bus. Various devices may be coupled to the second bus 1020 including, for example, a keyboard/mouse 1022, communication device(s) 1026 (which may in turn communicate with a computer network), and a data storage unit 1028, such as a disk drive or other mass storage device, which in one embodiment may include code 1030. Code 1030 may include instructions for performing embodiments of one or more of the methods described above. Further, an audio I/O1024 may be coupled to the second bus 1020.
Note that other embodiments are contemplated. For example, instead of the point-to-point architecture shown, the system may implement a multi-drop bus or another such communication topology. Also, more or fewer integrated chips than shown in fig. 17 may alternatively be used to segment the elements of fig. 17.
A module as used herein refers to any hardware, software, firmware, or combination thereof. The module boundaries shown as separate generally often change and potentially overlap. For example, the first and second modules may share hardware, software, firmware, or a combination thereof, while potentially maintaining some independent hardware, software, or firmware. In one embodiment, the use of the term logic includes hardware, such as transistors, registers, or other hardware, such as programmable logic devices. However, in another embodiment, the logic also includes software or code integrated with hardware, such as firmware or microcode.
Embodiments include a product purchase agreement. In such a protocol, vending device 103 performs the following: 1) beacon detection of nearby potential consumers, 4) BLE-mobile device connection enabled, 5) vending box 103 sending a seed, 20) vending box 103 receiving a key, 21) vending box 103 decrypting the key and confirming whether it is applicable, 22) vending box 103 dropping purchased product, 23) sensor confirming that the product was delivered, 24) vending box 103 sending a successful delivery confirmation. In such protocols, mobile application 104 performs the following: 2) A beacon triggered welcome screen (for the description of this embodiment, this element (2) will occur immediately after the upper element (1) and immediately before the lower element (3), etc.), 3) the consumer accepts the invitation (triggers the connection sequence), 6) sends the seed and consumer identity to vending server 102, 9) mobile device/application 104 receives and displays the product availability and price, 10) the user selects the product and quantity to purchase, 12) the user selects the payment method (vending box 103 rewards, payPal, etc.), 13) the user logs in to the payment method and approves the purchase, 18) mobile device application 104 receives the key, 19) mobile device application sends the key to vending box 103, 25) mobile device receives a successful delivery confirmation and informs vending server 102. In such an agreement, the payment service 101 performs the following: 14 Server 102 charges the consumer through the PayPal (or equivalent) API. In such protocols, the server 102 performs the following: 7) Server 102 receives a seed number from vending box 103, 8) sends the availability and price of the product for the vending box, 11) receives a product selection and quantity from the mobile device, 15) obtains a transaction confirmation, 16) generates a product drop key that uses the seed number as input and includes the product selection and quantity, 17) sends a temporary key to mobile device application 104, 26) receives a successful delivery confirmation and records the transaction, 27) determines whether to query the client for feedback.
Embodiments include incident reporting agreements. In such a protocol, vending device 103 performs the following: 1) vending box 103 detects the incident (power down, accelerometer triggered, etc.), 2) the event is marked and the timer starts counting, 3) the beacon will inform the passing clients about the opportunity for the incident and report, 6) vending box 103 sends the marking information (time, event, number of missales, etc.) to mobile device application 104, all formatted in DEX proper formatting. In such protocols, mobile application 104 performs the following: 4) Through clients being informed that the vending machine wants to report information (this element (4) will occur immediately after the upper element (3) and immediately before the lower element (5) etc. for the description of the present embodiment), 5) the clients decide to report, 7) receive the tag information, 8) send the information to the VB cloud together with the client identity, 13) display the awards granted. In such protocols, the server 102 performs the following: 9) Receive incident information, 10) select to reward the report, 11) reward the client and record the reward, 12) VB cloud notify the mobile device about the granted reward. In such an agreement, the operator 100 performs the following: 14 Server 102 immediately notifies vending operator 100 about the incident.
Embodiments include a product price change protocol. In such protocols, vending application 104 performs the following: 5) Querying a list of product availability and prices for a particular vending bin 103, 7) receiving a list of updated product availability and prices. In such protocols, the server 102 performs the following: 3) Receiving a change request, 4) updating a price list or product availability for the unique ID, 6) transmitting the updated product availability and price list. In such an agreement, the vending operator 10 performs the following: 1) Determining to change product pricing or availability, 2) sending a request to server 102 along with the new price/availability and vending box 103 unique ID. The numbers, e.g., 1) and 2), etc. should be interpreted as indicating a temporal order for the execution of the actions.
Embodiments include a vending operator request protocol. In such an agreement, the vending operator 100 performs the following: 1) Vending box 103 informs server 102 about the particular request (e.g., it wants to know where the vending machine is located), 10) vending box operator 100 is informed of the coordinates of the nearest vending box 103. In such protocols, the server 102 performs the following: 2) Receiving the request and creating the tag associated with the unique id, 5) receiving the inquiry and finding that vending box 103 is tagged, 6) sending the opportunity for participation and product availability and price, if applicable, to the consumer, 9) receiving the coordinate information, recording it and informing vending box 103 operator, 11) selecting the rewarding consumer, 12) recording the rewards and informing. In such protocols, the application 104 performs the following: 3) Obtaining an invitation to make a purchase via a beacon, 4) sending a unique ID to the VB cloud along with the consumer ID to query the product availability and price, 7) the consumer chooses to participate and report the current coordinates, 8) the consumer marks the current vending box 103 coordinates using a location service and sends this information to the VB cloud, 13) the consumer receives notification of the received rewards. The numbers, e.g., 1) and 2), etc. should be interpreted as indicating a temporal order for the execution of the actions.
Example 1a includes a system including a first Vending Machine (VM), the first VM comprising: an external chassis having a top, a bottom, a back, a front, and first and second sides coupling the front to the back; a wireless short-range communication node included in the chassis; and an actuator coupled to a compartment included in the chassis; wherein (a) the actuator provides vending to the aperture in the front face upon actuation, and (b) each of the front face and the first and second sides does not include a physically manipulable consumer interface with which a consumer can control the first VM via direct physical manipulation of the first VM.
In an example, the chassis may resemble a mere case without a traditional physical consumer interface (e.g., buttons to select soda, currency collectors, touch screens, etc.) that clutters the front of the vending case. From a consumer's perspective, the vending cabinet may resemble a simple cooler in some embodiments; but a cooler that creates the vending or merchandise via an aperture. Of course, the vending machine need not be a soda or food item, but may include post-mix supplies, and the like. The actuator may provide a vending from the interior compartment to the aperture (e.g., a cup in which the beverage is ultimately dispensed).
In example 2a, the subject matter of example 1a can optionally include, wherein each of the front face and the first and second sides does not include an electronic display, and the first VM does not include a group including a multi-drop bus (MDB), a coin collector, and a magnetic card reader.
Thus, embodiments provide a VM in which most of the conventional intelligence/logic (and corresponding costs) included in a conventional VM is now more efficiently distributed across mobile computing nodes and cloud-based computing nodes. Such embodiments are also more energy efficient in view of the lack of power extraction elements such as electronic displays.
In example 3a, the subject matter of examples 1a-2a can optionally include, wherein the front side and each of the first and second sides do not include physical buttons or an interactive electronic display that a consumer can use to control the first VM via direct physical manipulation of the first VM, and wherein the physically manipulable consumer interface of the first VM includes the front side and each of the first and second sides does not include physical buttons or an interactive electronic display that a consumer can use to control the first VM via direct physical manipulation of the first VM.
Examples of a "physically manipulable consumer interface that a consumer may use to control a first VM via direct physical manipulation of the first VM" include a touch screen or mechanical buttons whereby the user selects a product to be delivered to the user after payment. An embodiment is a simple unit that only discovers the mobile computing node and possibly allows key exchange between the mobile node and the VM, but it still does not correspond to a UI whereby the user can "control the first VM via direct physical manipulation of the first VM".
In example 4a, the subject matter of examples 1a-3a can optionally include a second VM; and at least one remote computing node comprising at least one machine readable medium storing first inventory data corresponding to the first VM and second inventory data corresponding to the second VM; wherein none of the first and second VMs includes a memory storing inventory data related to either of the first and second inventory data.
For example, embodiments of a VM may relinquish memory and associated devices for tracking its inventory, considering that it may now be handled with, for example, a cloud-based server or other such computing node.
In example 5a, the subject matter of examples 1a-4a can optionally include, wherein the at least one remote computing node comprises at least one machine readable medium having instructions stored thereon for causing the at least one remote computing node to: communicating with at least one mobile computing node; storing first and second data corresponding to the first and second VMs, respectively; in response to communicating with the at least one mobile computing node, the first and second data are transferred to the first and second VMs, respectively, via the at least one mobile computing node.
For example, the server node may include a queue with updated advertising programs for display (rather than UI) on the VM that only displays advertisements. The advertising program may be included in the first and second data. This data may be transferred to the VM over a period of time via the smartphone. For example, on monday, first data may be transferred from a smartphone to a first VM, and on monday, second data may be transferred from a different smartphone to a second VM.
In example 6a, the subject matter of examples 1a-5a can optionally include, wherein the first VM includes at least one machine-readable medium having instructions stored thereon for causing the first VM to discover and communicate with at least one mobile computing node; wherein the at least one remote computing node includes at least one storage medium having instructions stored thereon for causing the at least one remote computing node to transmit an actuation command to the first VM via the at least one mobile computing node to actuate an actuator to provide the vending to the aperture.
In example 7a, the subject matter of examples 1a-6a can optionally include, wherein the at least one remote computing node comprises at least one storage medium having instructions stored thereon for causing the at least one remote computing node to: establishing a first communication session with at least one mobile computing node; and transmitting the first and second inventory data to the at least one computing node in response to establishing the first communication session and before the first communication session ends.
In an example, a user may receive first and second inventory data for first and second VMs that the user's smartphone has discovered. The user can then flip or slide the UI on his smartphone from one list of inventory for the first VM to another list for the second VM so the user can quickly see the total number of his options.
Fig. 18 includes an embodiment of a UI and process for observing inventory of different VMs. At element 1801, BLE detects nearby VMs and obtains their respective information from server 102. The UI of element 1801 is for VM #198, and it is one of 5 nearby machines that is a reference point in the bottom portion of the screen display. At element 1802, the user may want products that are not listed for VM #198, so the user "swipes" to the next VM (that has been discovered) to see what products are available. At element 1803, VM# 206 appears with its current product availability. There are many more products from which to choose, and the user is now interested in purchasing "product 7", which may be soda, coffee, a piece of clothing, an electronic device, a QR code with a coded value, etc. At element 1804, when the user clicks on the product, the private connection from the user's mobile node to machine #206 is enabled by BLE. At element 1805, information about the selected product is downloaded from server 102 and displayed on the user's device along with the price and the current balance in the account the user was tied to vending operator 100. At element 1806, the user selects to purchase the product or cancel and return to the previous page. The user chooses to pay with his current balance or with a payment account similar to PayPal. After the transaction, the product is provided to the consumer.
In example 8a, the subject matter of examples 1a-7a can optionally include, wherein the first VM includes at least one machine-readable medium having instructions stored thereon for causing the first VM to establish a first communication session with the at least one mobile computing node and terminate the first communication session at a later time; wherein the second VM includes at least one machine readable medium having instructions stored thereon for causing the second VM to establish a second communication session with the at least one mobile computing node and to terminate the second communication session at a later time; wherein at least a portion of the first and second communication sessions overlap each other.
In an embodiment, the first and second VMs may be simultaneously in a device-discovered mode for a single mobile node.
In example 9a, the subject matter of examples 1a-8a can optionally include, wherein the at least one remote computing node comprises at least one storage medium having instructions stored thereon for causing the at least one remote computing node to: establishing a first communication session with at least one mobile computing node; transmitting the first and second inventory data to the at least one computing node in response to establishing the first communication session and before the first communication session ends; and providing guidance to the user regarding the physical location of the first VM in response to the user initiated selection of the product included in the first inventory data; wherein the user initiated selection is communicated from the at least one mobile computing node.
In an embodiment, a user may select a product from one VM instead of another, and then obtain instructions on how to reach a VM with his or her desired product.
In example 10a, the subject matter of examples 1a-9a can optionally include the at least one remote computing node comprising at least one storage medium having instructions stored thereon for causing the at least one remote computing node to: communicating with the first mobile computing node to determine that the first mobile computing node desires to purchase credit for the second computing node; granting credit to the second computing node in response to communicating with the first mobile computing node to determine that the first mobile computing node desires to purchase credit for the second computing node; communicating with the second mobile computing node to indicate granting of credit to the second computing node; and transmitting an actuation command to the first VM via the second mobile computing node based on granting credit to the second computing node.
In an embodiment, a user, such as a parent of a child using a parent's smart phone, may give credit as a gift to the child at school. The child's smart phone may be trusted and the child may then obtain the product that was sold.
In example 11b, the subject matter of examples 1a-10a can optionally include wherein the credit corresponds to a first product included in the inventory of the first VM and not a second product included in the inventory of the first VM. Thus, a parent of a child may target credit to a first product, for example, having a lower sugar content than a second product.
In example 11c, the subject matter of examples 1a-10a can optionally include a second VM, wherein the credit corresponds to the first VM and not the second VM and is redeemable at the first VM and not the second VM. Thus, the gift may direct the recipient to a VM that is rarely used and that wishes to generate new traffic at the location of the VM. For example, a user may often appear in a second VM (the vending operator has great effort to keep its full inventory, or the vending operator may have to pay a higher commission for it to the owner), while the operator may wish the user to be redirected to the first VM. The gift-giver may be able to select from a list of VMs posted on the internet. The gift may include keying material specific to the ID of the first VM but not the second VM (e.g., encrypted with a public key corresponding to the private key of the first VM), thereby limiting the granting of usefulness with the first VM.
In example 11a, the subject matter of examples 1a-10a can optionally include the at least one remote computing node comprising at least one storage medium having instructions stored thereon for causing the at least one remote computing node to: communicating with at least one of the additional remote computing node and the first mobile computing node to determine that credit should be awarded to the first mobile computing node in response to the user having been awarded a prize in the game; granting credit to the first mobile computing node in response to communicating with at least one of the additional remote computing node and the first mobile computing node; communicating with the first mobile computing node to indicate that credit is granted to the first computing node; and transmitting an actuation command to the first VM via the first mobile computing node based on granting credit to the first computing node.
In an embodiment, the prize is redeemable at a particular VM. The VM may be located at a certain location. For example, a grocery store chain may sponsor a prize for a gift/credit obtained by playing a game. A grocery chain may have one or more specific stores with VMs having unique ids that all will receive prizes (which may include keying material that is compatible only with keys on the designated VM). This may motivate the user to enter one of the locations of the grocery store.
In example 12a, the subject matter of examples 1a-11a can optionally include wherein the first VM is included in a storefront wall and the aperture is directly exposed to an area outside of the store that includes the storefront wall.
Embodiments according to the present example will allow storefronts on busy streets to sell products for "window shoppers" late until night. For example, in view of the simplicity and low cost nature of many vending box solutions described herein, a merchant may include a series of vending boxes in his or her storefront wall (e.g., a wall made of brick, glass (i.e., window), etc.). Each vending cabinet may have a single compartment with a single lock that the actuator of the VM actuates to unlock and provide the consumer with the product.
As another example, a coffee shop may receive orders in advance for the coffee being ordered. Such orders may come from office workers working at several streets from the coffee shop. The worker may submit his order (e.g., possibly over the internet or by voice), and then begin his travel to the coffee shop. A coffee shop may make coffee during its travel and place the coffee in a vending box corresponding to receipts and credits that office workers have on their phone (received from cloud-based nodes as described above). The office workers' smart phones, watches, glasses, etc. can then find the appropriate vending box, open the vending box using the actuation command received from the server, get their coffee, completely without having to enter a crowded coffee shop and deal with a lengthy wait for coffee. Of course, the vending cabinet need not be in the storefront wall for all embodiments.
In example 13a, the subject matter of examples 1a-12a can optionally include at least one remote computing node comprising at least one machine-readable medium storing first inventory data corresponding to one or more products accessible via the first VM; wherein the first VM includes at least one machine readable medium having instructions stored thereon for causing the first VM to discover and communicate with at least one mobile computing node; wherein the at least one remote computing node comprises at least one storage medium having instructions stored thereon for causing the at least one remote computing node to: (a) Receiving a selection communication from the at least one mobile computing node corresponding to a user selection of one or more products, and (b) in response to receiving the selection communication, transmitting an actuation command to the first VM via the at least one mobile computing node to cause the actuator to deliver the vending to the aperture.
In example 14a, the subject matter of examples 1a-13a can optionally include wherein the at least one remote computing node includes at least one storage medium having instructions stored thereon for causing the at least one remote computing node to transmit the user-selected order corresponding to the one or more products to the additional computing node via non-wireless short-range communication.
In an embodiment, the order may be sent via the internet to a node in, for example, a coffee shop so that the coffee shop vendor may begin preparing coffee before any discovery occurs between the user's mobile computing node and the vending bin.
In example 15a, the subject matter of examples 13a-14a can optionally include wherein the wireless short-range communication node is configured for at least one of bluetooth and Near Field Communication (NFC), and the at least one remote computing node comprises a server.
Example 1b includes at least one storage medium having instructions stored thereon for causing a first mobile computing node to: communicating with at least one remote computing node to indicate that the first mobile computing node desires to purchase the first credit for the second computing node; receiving a second credit from at least one of the second computing node and the third computing node in response to the at least one of the second computing node and the third computing node communicating with the at least one remote computing node to indicate that the at least one of the second computing node and the third computing node desires to purchase credit for the first mobile computing node; receiving a communication from the at least one remote computing node indicating that a second credit was granted to the first mobile computing node; and transmitting an actuation command to a first Vending Machine (VM) based on the second credit. Such first mobile computing nodes may include, for example, nodes that include application 104.
In example 2b, the subject matter of example 1b can optionally include wherein the second credit corresponds to a first product included in inventory of the first VM and not a second product included in inventory of the first VM.
In example 3b, the subject matter of examples 1b-2b can optionally include wherein the second credit corresponds to the first VM but not the second VM and is redeemable at the first VM but not the second VM.
In example 4b, the subject matter of examples 1b-3b can optionally include instructions to cause the first mobile computing node to: establishing a first communication session with the at least one remote computing node; and receiving, from the at least one remote computing node, first and second inventory data corresponding to the first VM and the second VM in response to establishing the first communication session and before the first communication session ends.
In example 5b, the subject matter of examples 1b-3b can optionally include instructions to cause the first mobile computing node to: establishing a first communication session with the at least one remote computing node; and receiving, from the at least one remote computing node, first and second inventory data corresponding to the first VM and the second VM in response to establishing the first communication session and before the first communication session ends; transmitting a user-initiated selection of a product included in the first inventory data to the at least one remote computing node; and receiving guidance regarding the physical location of the first VM but not the second VM in response to transmitting the user-initiated selection to the at least one remote computing node.
Example 1c includes a vending system comprising: a proximity detection module to detect proximity of a mobile computing node within 100 meters of the vending system; the wireless communication module is used for carrying out wireless communication with the mobile computing node; an equipment simulation module; a multi-drop bus (MDB) interface to couple the device analog module to the MDB; and at least one storage medium having instructions stored thereon for causing the system to transmit a first simulation of a first peripheral device state to a Vending Machine Controller (VMC); wherein the first peripheral device state corresponds to a state of at least one of a physical coin acceptor device, a banknote acceptor, a credit card reader, a Near Field Communication (NFC) reader, and a Radio Frequency Identification (RFID) reader. In other embodiments, the proximity detection module detects proximity of a mobile computing node within 1 cm, 1 m, 10 m, 50 m, 100 m, 250 m, 400 m, 500 m, and the like. Other embodiments are not limited to MDBs and may work with other bus systems. Other embodiments are not limited to VMCs and may work with other controller systems. In an embodiment, the first peripheral device state corresponds to the state of various forms of systems (e.g., cashless payment systems) that communicate financial information to the VM, and is not limited to physical coin acceptor devices, banknote acceptors, credit card readers, near Field Communication (NFC) readers, and Radio Frequency Identification (RFID) readers.
In example 2c, the subject matter of example 1c can optionally include, wherein the at least one medium comprises instructions to cause the system to: receiving a first actuation instruction from a mobile computing node; and in response to receiving the first actuation instruction, transmitting a second actuation instruction to the VMC; wherein the first actuation instruction corresponds to an authorization for the sale of the product and the second actuation instruction is configured to cause the VMC to issue a third actuation instruction to sell the product to the user from a vending machine coupled to the vending system; wherein the third actuation instructions enable mechanical actuation of the product dispenser to actuate the mechanical system to deliver the product to the user. In an embodiment, a "first actuation instruction" should not be understood to indicate that the first actuation instruction must require a direct actuation command, but instead may include an indirect actuation, such as a general approval instruction that causes a series of instructions, one of which ultimately causes the system (e.g., lock or gear) to operate and sell the product. The same is true for the "second" and "third" actuation commands, however, in some embodiments, some or all of the first, second, and third actuation commands do include direct actuation commands.
In example 3c, the subject matter of examples 1c-2c can optionally include wherein (a) the second actuation instructions correspond to instructions formatted for the VMC and indicating that a threshold level of credit is present to sell the product, and (c) the mechanical system includes at least one of a mechanical lock and a servo motor. This may require compliance with the standard or specification employed for communication with the VMC in embodiments with "formatted for VMC". The "threshold level of credit" may indicate that a sufficient amount of coins or banknotes or credits have been received (via a credit card or PayPal cube).
Embodiments may include a remote node, such as server 102. Embodiments may include Software As A Service (SAAS).
Example 1d includes at least one machine readable medium having instructions stored thereon for causing at least one remote computing node to: communicating with at least one mobile computing node; storing first and second data corresponding to a first Vending Machine (VM) and a second VM, respectively; in response to communicating with the at least one mobile computing node, the first and second data are transferred to the first and second VMs, respectively, via the at least one mobile computing node.
In example 2d, the subject matter of example 1d can optionally include the at least one machine-readable medium having instructions stored thereon to cause the at least one remote computing node to transmit an actuation command to the first VM via the at least one mobile computing node to cause the actuator to provide the vending to the aperture.
In example 3d, the subject matter of examples 1-2d can optionally include the at least one machine readable medium having instructions stored thereon for causing the at least one remote computing node to: establishing a first communication session with at least one mobile computing node; and transmitting, in response to establishing the first communication session and before the first communication session ends, the first and second inventory data corresponding to the first and second VMs to the at least one remote computing node.
In example 4d, the subject matter of examples 1-3d can optionally include the at least one machine readable medium having instructions stored thereon for causing the at least one remote computing node to: establishing a first communication session with at least one mobile computing node; transmitting the first and second inventory data to the at least one computing node in response to establishing the first communication session and before the first communication session ends; and providing guidance to the user regarding the physical location of the first VM in response to the user-initiated selection of the product included in the first inventory data corresponding to the first VM; wherein the user initiated selection is communicated from the at least one mobile computing node.
Example 1e includes at least one machine readable medium having instructions stored thereon for causing at least one remote computing node to: communicating with the first mobile computing node to determine that the first mobile computing node desires to purchase credit for the second computing node; granting credit to the second computing node in response to communication with the first mobile computing node to determine that the first mobile computing node desires to purchase credit for the second computing node; communicating with the second mobile computing node to indicate that credit is granted to the second computing node; and transmitting an actuation command to the first VM via the second mobile computing node based on granting credit to the second computing node. In an example, the credit corresponds to a first product included in the inventory of the first VM but not a second product included in the inventory of the first VM. In an example, the credit corresponds to the first VM but not the second VM and is redeemable at the first VM but not the second VM.
Example 1f includes at least one machine readable medium having instructions stored thereon for causing at least one remote computing node to: communicating with at least one of the additional remote computing node and the first mobile computing node to determine that credit should be awarded to the first mobile computing node in response to the user having been awarded a prize in the game; granting credit to the first mobile computing node in response to communicating with at least one of the additional remote computing node and the first mobile computing node; communicating with the first mobile computing node to indicate that credit is granted to the first computing node; and transmitting an actuation command to the first VM via the first mobile computing node based on granting credit to the first computing node.
Example 1g includes at least one machine readable medium having instructions stored thereon for causing at least one remote computing node to: storing first inventory data corresponding to one or more products available via a first Vending Machine (VM); receiving a selection communication from the at least one mobile computing node corresponding to a user selection of one or more products; and in response to receiving the selection communication, transmitting an actuation command to the first VM via the at least one mobile computing node to cause the actuator to deliver the vending to the aperture. In an example, the instructions may cause the at least one remote computing node to transmit, via non-wireless short-range communication, a user-selected order corresponding to the one or more products to the additional computing nodes.
Additional examples include a system comprising a first Vending Machine (VM), the first VM comprising: an external chassis having a top, a bottom, a back, a front, and first and second sides coupling the front to the back; means included in the chassis for wireless short-range communication; and an actuator device coupled to a compartment included in the chassis; wherein (a) the actuator means comprises means for providing vending to the aperture in the front face upon actuation, and (b) each of the front face and the first and second sides does not comprise a physically manipulable consumer interface that a consumer can use to control the first VM via direct physical manipulation of the first VM.
Additional examples may include wherein each of the front face and the first and second sides do not include an electronic display device, and the first VM does not include a group including a multi-drop bus (MDB), a coin collector, and a magnetic card reader.
Additional examples may include wherein the front face and each of the first and second sides do not include physical buttons or interactive electronic displays that a consumer may use to control the first VM via direct physical manipulation of the first VM.
Additional examples may include a second VM; and at least one remote computing node comprising means for storing first inventory data corresponding to the first VM and second inventory data corresponding to the second VM; wherein none of the first and second VMs comprises means for storing inventory data relating to either of the first and second inventory data.
Additional examples may include wherein the at least one remote computing node comprises means for causing the at least one remote computing node to: communicating with at least one mobile computing node; storing first and second data corresponding to the first and second VMs, respectively; in response to communicating with the at least one mobile computing node, the first and second data are transferred to the first and second VMs, respectively, via the at least one mobile computing node.
Additional examples may include wherein the first VM includes means for causing the first VM to discover and communicate with at least one mobile computing node; wherein the at least one remote computing node includes means for causing the at least one remote computing node to transmit an actuation command to the first VM via the at least one mobile computing node to cause the actuator to provide the vending to the aperture.
Additional examples may include wherein the at least one remote computing node comprises means for causing the at least one remote computing node to: establishing a first communication session with at least one mobile computing node; and transmitting the first and second inventory data to the at least one computing node in response to establishing the first communication session and before the first communication session ends.
Additional examples may include wherein the first VM includes means for causing the first VM to establish a first communication session with the at least one mobile computing node and to terminate the first communication session at a later time; wherein the second VM includes means for causing the second VM to establish a second communication session with the at least one mobile computing node and to terminate the second communication session at a later time; wherein at least a portion of the first and second communication sessions overlap each other.
Additional examples may include wherein the at least one remote computing node comprises means for causing the at least one remote computing node to: establishing a first communication session with at least one mobile computing node; transmitting the first and second inventory data to the at least one computing node in response to establishing the first communication session and before the first communication session ends; and providing guidance to the user regarding the physical location of the first VM in response to the user-initiated selection of the product included in the first inventory data; wherein the user initiated selection is communicated from the at least one mobile computing node.
Additional examples may include the at least one remote computing node comprising means for causing the at least one remote computing node to: communicating with the first mobile computing node to determine that the first mobile computing node desires to purchase credit for the second computing node; granting credit to the second computing node in response to communicating with the first mobile computing node to determine that the first mobile computing node desires to purchase credit for the second computing node; communicating with the second mobile computing node to indicate that credit is granted to the second computing node; and transmitting an actuation command to the first VM via the second mobile computing node based on granting credit to the second computing node.
Additional examples may include wherein the credit corresponds to a first product included in the inventory of the first VM and not a second product included in the inventory of the first VM.
Additional examples may include a second VM, wherein the credit corresponds to the first VM instead of the second VM and is redeemable at the first VM instead of the second VM.
Additional examples may include at least one remote computing node comprising means for causing the at least one remote computing node to: communicating with at least one of the additional remote computing node and the first mobile computing node to determine that credit should be awarded to the first mobile computing node in response to the user having been awarded a prize in the game; granting credit to the first mobile computing node in response to communicating with at least one of the additional remote computing node and the first mobile computing node; communicating with the first mobile computing node to indicate that credit is granted to the first computing node; and transmitting an actuation command to the first VM via the first mobile computing node based on granting credit to the first computing node.
Additional examples may include wherein the first VM is included in a storefront wall and the aperture is directly exposed to an area outside of the store that includes the storefront wall.
Additional examples may include at least one remote computing node comprising means for storing first inventory data corresponding to one or more products accessible via a first VM; wherein the first VM includes means for causing the first VM to discover and communicate with at least one mobile computing node; wherein the at least one remote computing node comprises means for causing the at least one remote computing node to: (a) Receiving a selection communication from the at least one mobile computing node corresponding to a user selection of one or more products, and (b) in response to receiving the selection communication, transmitting an actuation command to the first VM via the at least one mobile computing node to cause the actuator to deliver the vending to the aperture.
Additional examples may include wherein the at least one remote computing node includes means for causing the at least one remote computing node to transmit a user-selected order corresponding to the one or more products to the additional computing node via non-wireless short-range communication.
Additional examples may include wherein the wireless short-range communication node is configured for at least one of bluetooth and Near Field Communication (NFC), and the at least one remote computing node comprises a server.
While the present invention has been described with respect to a limited number of embodiments, those skilled in the art will appreciate numerous modifications and variations therefrom. It is intended that the appended claims cover all such modifications and variations as fall within the true spirit and scope of this present invention.

Claims (14)

1. A system for physical delivery comprising a plurality of remote delivery terminals, each remote delivery terminal comprising:
an external chassis;
a short-range communication node disposed in the external chassis;
an actuator for delivering cargo contained in the external chassis;
at least one remote computing node comprising means for separately storing inventory data corresponding to goods held in each of a plurality of remote delivery terminals;
wherein (a) the at least one remote computing node transmits inventory data corresponding to goods held in each of a plurality of remote delivery terminals to one or more mobile computing nodes, (b) a short-range communication node in one of the remote delivery terminals discovers a mobile computing node of a consumer in the vicinity of the one of the remote delivery terminals, (c) a short-range communication node in one of the remote delivery terminals establishes a communication connection with the mobile computing node, (d) at least one remote computing node receives a user selection of goods held in one of the remote delivery terminals from the mobile computing node, (e) the at least one remote computing node sends an actuation command to the mobile computing node, and (f) a short-range communication node in one of the remote delivery terminals receives an actuation command from the mobile computing node, (g) an actuator in one of the remote delivery terminals delivers the selected goods in response to the received actuation command.
2. The system of claim 1, wherein the at least one remote computing node comprises at least one machine-readable medium having instructions stored thereon for causing the at least one remote computing node to:
communicating with the mobile computing node;
storing first and second data corresponding to the first and second remote delivery terminals, respectively;
in response to communication with the mobile computing node, the first and second data are transmitted via the mobile computing node to first and second remote delivery terminals, respectively.
3. The system of claim 1, wherein the at least one remote computing node communicates, to the mobile computing node, the stock data corresponding to the good held in each of the plurality of remote delivery terminals in response to establishing a communication session with the mobile computing node and before a communication connection is completed.
4. The system according to claim 1,
wherein the first remote delivery terminal comprises at least one machine readable medium having stored thereon instructions for causing the first remote delivery terminal to establish a first communication session with the mobile computing node and subsequently terminate the first communication session;
Wherein the second remote delivery terminal comprises at least one machine readable medium having stored thereon instructions for causing the second remote delivery terminal to establish a second communication session with the mobile computing node and subsequently terminate the second communication session;
wherein at least a portion of the first and second communication sessions overlap each other.
5. The system of claim 1, wherein the at least one remote computing node comprises at least one storage medium having instructions stored thereon for causing the at least one remote computing node to:
establishing a first communication session with the mobile computing node;
transmitting, to the mobile computing node, in response to establishing a communication session with the mobile computing node and before the communication session ends, stock data corresponding to goods held in each of a plurality of remote delivery terminals; and
providing, via the mobile computing node, guidance to the user regarding the physical location of one of the remote delivery terminals in response to a user-initiated selection of a product corresponding to the inventory data;
wherein the user initiated selection is communicated from the mobile computing node.
6. The system of claim 1, wherein the inventory data corresponds to one or more products available via one of the remote delivery terminals;
Wherein one of the remote delivery terminals comprises at least one machine readable medium having stored thereon instructions for causing the one of the remote delivery terminals to discover and communicate with a mobile computing node;
wherein the at least one remote computing node comprises at least one storage medium having instructions stored thereon for causing the at least one remote computing node to: (a) Receiving a selection communication from the mobile computing node corresponding to a user selection of the good, and (b) in response to receiving the selection communication, transmitting an actuation command to one of the remote delivery terminals via the mobile computing node for actuating the actuator to deliver the good to an aperture of the one of the remote delivery terminals.
7. A remote computing node, comprising:
at least one storage medium and at least one processor coupled to the at least one storage medium;
an inventory management module included in the at least one storage medium that includes first inventory data corresponding to a first remote delivery terminal and second inventory data corresponding to a second remote delivery terminal;
Wherein the at least one storage medium has instructions stored thereon for causing the at least one remote computing node (a) to transmit a first actuation command to the first remote delivery terminal via the at least one mobile computing node to actuate an actuator of the first remote delivery terminal to provide the first cargo to an aperture included in the first remote delivery terminal; and (b) transmitting a second actuation command to the second remote delivery terminal via the at least one mobile computing node to actuate an actuator included in the second remote delivery terminal to provide a second cargo to an aperture included in the second remote delivery terminal;
wherein neither of the first and second remote delivery terminals includes a memory storing inventory data related to either of the first and second inventory data.
8. The remote computing node of claim 7, wherein the at least one storage medium has instructions to:
communicating with at least one mobile computing node;
storing first and second data corresponding to the first and second remote delivery terminals, respectively;
the first and second data are transmitted to the first and second remote delivery terminals, respectively, via the at least one mobile computing node in response to communication with the at least one mobile computing node.
9. The remote computing node of claim 7, wherein the at least one storage medium has instructions to:
establishing a first communication session with at least one mobile computing node; and
the first and second inventory data are communicated to the at least one mobile computing node in response to establishing the first communication session and before the first communication session ends.
10. The remote computing node of claim 7, wherein the at least one storage medium has instructions to:
establishing a first communication session with at least one mobile computing node;
transmitting the first and second inventory data to the at least one mobile computing node in response to establishing the first communication session and before the first communication session ends; and
providing, via the at least one mobile computing node, an indication to the user of the physical location of the first remote delivery terminal in response to a user-initiated selection of a product corresponding to the first inventory data;
wherein the user initiated selection is communicated from at least one mobile computing node.
11. The remote computing node of claim 7, wherein the at least one storage medium has instructions to:
receiving a selection communication from the at least one mobile computing node corresponding to a user selection of the first inventory data; a kind of electronic device with a high-performance liquid crystal display
In response to receiving the selection communication, a first actuation command is transmitted to the first remote delivery terminal.
12. A method for discovering a mobile computing node by a remote delivery terminal of the system of any one of claims 1-6, comprising
Physically moving a mobile computing node into proximity of the remote delivery terminal and initiating the discovery by touching or tapping the mobile computing node to a Radio Frequency Identification (RFID) reader device in the remote delivery terminal;
the remote delivery terminal responsively transmits a standard RFID read command to the mobile computing node.
13. The method of claim 12, wherein the remote delivery terminal responsively transmitting a standard RFID read command to the mobile computing node comprises:
starting an application running in the mobile computing node; and
bluetooth Low Energy (BLE) service is initiated.
14. The method of claim 12, wherein upon completion of launching an application running in a mobile computing node and launching a Bluetooth Low Energy (BLE) service, the remote delivery terminal transmits a locally stored unique identifier, UUID, to the application and enters a device discovered state.
HK19126343.3A 2013-10-03 2019-07-05 Vending system HK40002951B (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US61/886231 2013-10-03
US61/929666 2014-01-21

Publications (2)

Publication Number Publication Date
HK40002951A HK40002951A (en) 2020-04-03
HK40002951B true HK40002951B (en) 2023-07-28

Family

ID=

Similar Documents

Publication Publication Date Title
CN109858897B (en) Sales system
HK1226187A1 (en) Vending system
JP7766131B2 (en) Method and system for providing automated retail machine offers through a mobile device
US12314919B2 (en) Systems and methods for determining electric pulses to provide to an unattended machine based on remotely-configured options
US11966926B2 (en) Method and system for asynchronous mobile payments for multiple in-person transactions conducted in parallel
JP6898339B2 (en) Systems and methods for determining the electrical pulses to provide to the drone based on remote configuration options
US10748125B2 (en) Systems and methods for digital multimedia capture using haptic control, cloud voice changer, protecting digital multimedia privacy, and advertising and sell products or services via cloud gaming environments
US10229448B2 (en) Network of personalized devices determining data for shopping predictions
US11948428B2 (en) System and method for utilizing vouchers to facilitate purchases in association with a gaming establishment retail account
US20250104175A1 (en) System and method for utilizing prepaid cards to facilitate purchases in association with a gaming establishment retail account
US12417452B2 (en) Smart chip payment acceptance
US20230338858A1 (en) Settling gaming establishment retail purchases
JP7532358B2 (en) Asynchronous mobile payment method and system for multiple parallel face-to-face transactions
CN104050584A (en) System for digital bonus point management
US10346819B2 (en) Mobile device applications, other applications and associated kiosk-based systems and methods for facilitating coin saving
HK40002951B (en) Vending system
HK40002951A (en) Vending system
US20240127671A1 (en) Front money account integrated with gaming establishment account management system