Patent Description:
Several control techniques already exist in the prior art. For instance, approaches utilizing radio-frequency identification (RFID) technologies have been commercialized. However costs associated with RFID tags and cups fitted with RFID chips - both in terms of money and cumbersome interactions with third party RFID technology suppliers -- have proven to be unattractive.

Similarly, with regard to approaches using serialized bar codes, a threat of forgery of the bar codes is ever present.

The above descriptions and examples are not admitted to be prior art by virtue of their inclusion in this section.

<CIT> discloses a self coordinated machine network established by two or more machines in proximity with each other via a wired or wireless network infrastructure.

In a first aspect, the present invention provides a beverage vending device comprising: a network interface; one or more processors; and a computer-readable tangible medium with instructions stored thereon that, when executed, direct the one or more processors to perform acts comprising: establishing contact with an available network; locating a second beverage vending device on the network; establishing contact with the second beverage vending device on the network; communicating inventory information with the second beverage vending device via the network including receiving inventory levels of the second beverage vending device; and receiving a request from a consumer to dispense a beverage; characterised in that the instructions, when executed, direct the one or more processors to perform acts comprising: determining that the beverage being requested is not available at the beverage vending device; utilizing the inventory information received from the second beverage vending device to determine that the requested beverage is available at the second beverage vending device; and providing the consumer a choice to either go to the second beverage vending device for the requested beverage or stay at the beverage vending device where an alternative beverage can be dispensed.

In a second aspect, the present invention provides a computer-readable tangible medium configured for use with a first beverage vending device, the computer-readable medium including instructions stored thereon that, when executed, direct a processor to perform acts comprising: establishing contact between the first beverage vending device and a second beverage vending device; facilitating communication between the first beverage vending device and the second beverage vending device; receiving inventory information from the second beverage vending device including inventory levels of the second beverage vending device; and receiving a request from a consumer to dispense a beverage; characterised in that the instructions, when executed, direct the processor to perform acts comprising: determining that the beverage being requested is not available at the beverage vending device; utilizing the inventory information received from the second beverage vending device to determine that the requested beverage is available at the second beverage vending device; and providing the consumer a choice to either go to the second beverage vending device for the requested beverage or stay at the first beverage vending device where an alternative beverage can be dispensed.

In a third aspect, the present invention provides a beverage vending device comprising: a network interface; one or more processors; and a computer-readable tangible medium with instructions stored thereon that, when executed, direct the one or more processors to perform acts comprising: locating a second beverage vending device; establishing direct communication with the second beverage vending device; communicating inventory information with the second beverage vending device including receiving inventory levels of the second beverage vending device; and receiving a request from a consumer to dispense a beverage; characterised in that the instructions, when executed, direct the one or more processors to perform acts comprising: determining that the beverage being requested is not available at the beverage vending device; utilizing the inventory information received from the second beverage vending device to determine that the requested beverage is available at the second beverage vending device; and providing the consumer a choice to either go to the second beverage vending device for the requested beverage or stay at the beverage vending device where an alternative beverage can be dispensed.

Other features of the current disclosure will become apparent to those skilled in the art upon review of the following drawings, the detailed description, and the appended claims.

Illustrative embodiments will be described referring to the accompanying drawings, wherein like numerals denote like elements.

In the following description, numerous details are set forth to provide an understanding of some embodiments of the present disclosure. However, it will be understood by those of ordinary skill in the art that the systems and/or methodologies may be practiced without these details and that numerous variations or modifications from the described embodiments may be possible.

As described herein, various techniques and technologies associated with beverage vending device networking can be used, for example, to network two or more beverage vending devices together so that they can communicate with one another directly and/or via a server. In one possible implementation, encryption/decryption technologies can be used to control the pouring of a beverage to a consumer at any of the beverage vending devices.

In some implementations, it may be desirable to have communication means between beverage vending devices to better serve customers and to ensure compliance where multiple beverage vending devices are available. Moreover, in various implementations, it may be desirable to have a network of beverage vending devices in order to facilitate other transactional operations, such as updates, inventory, maintenance, content changes, ordering, etc., associated with one or more of the beverage vending devices.

<FIG> illustrates an example configuration <NUM> of one or more beverage vending devices <NUM> and one or more sellers <NUM> in one possible embodiment of beverage vending device networking. Even though three beverage vending devices <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM> and two sellers <NUM>-<NUM>, <NUM>-<NUM> are illustrated in <FIG>, it will be understood that more or less beverage vending devices <NUM> and/or sellers <NUM> can also be present.

Beverage vending devices <NUM> can comprise any devices configured to dispense and/or vend beverages to consumers including, for example, beverage dispensers (i.e. dispensers of fountain beverages, etc.), vending machines, coolers, and so on. Further, beverage vending devices <NUM> can include one or more computing and/or programmable devices enabling beverage vending devices <NUM> to run programs and interact with, manipulate, store, transmit, etc., various forms of data.

Sellers <NUM>-<NUM>, <NUM>-<NUM> can include any entity wishing to sell a beverage to a consumer and/or dispense a beverage to a consumer via beverage vending devices <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM>. Thus sellers <NUM>-<NUM>, <NUM>-<NUM> can include restaurants, snack bars, etc..

In one possible implementation, configuration <NUM> can represent a dispersed serving area, such as a food court, a theme park, a sports venue (such as a stadium, an arena, a ball park, etc.), a theater, a cruise ship, a campus, and so on. In one possible implementation, such as the case of a food court, sellers <NUM> can be different restaurants, and the plurality of beverage vending devices <NUM> can be various self-serve and crew served beverage dispensers throughout the food court. In another possible implementation, such as the case of a theater, sellers <NUM> can all represent the same entity (i.e. the theater) and the plurality of beverage vending devices <NUM> can be various self-serve and crew served beverage dispensers throughout the theater.

In some possible implementations, one or more servers <NUM> can also be present in configuration <NUM>. Server <NUM> can collect information from sellers <NUM> and beverage vending devices <NUM>, as well as transmit information, such as, for example updates, etc., to sellers <NUM> and beverage vending devices <NUM>. For example, in one possible embodiment, beverage vending devices <NUM>, sellers <NUM>, and/or server <NUM> can communicate information amongst themselves by sending packets over a network <NUM>. The packets can include log files to update settings, etc., and/or instructions to execute various programs, such as programs installed on beverage vending devices <NUM>. In one possible aspect, such log files can be sent by beverage vending devices <NUM> to server <NUM> in any fashion known in the art including in real-time, at one or more predetermined times (e.g. nightly), when an action of interest takes place, when an appropriate query is made, etc. In a similar fashion, updates and/or instructions can be sent from server <NUM> to sellers <NUM> and/or beverage vending devices <NUM> in any fashion known in the art including continuously, at predetermined times (e.g. nightly), when an action of interest takes place, when an appropriate query is made, etc..

Server <NUM> can comprise anything known in the art that can send and receive information and instructions to sellers <NUM> and beverage vending devices <NUM>, including a local computer or computer system, a point of sale (POS) computing device, etc..

As illustrated, beverage vending devices <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM>, sellers <NUM>-<NUM>, <NUM>-<NUM> and server <NUM> (if present) can be connected via network <NUM>. It will be understood that network <NUM> can include any technology known in the art capable of allowing communication between beverage vending devices <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM>, sellers <NUM>-<NUM>, <NUM>-<NUM>, server <NUM> (if present), and other present entities. This can include any wired and/or wireless technologies known in the art, including any possible combinations thereof.

For example, some or all of network <NUM> can be administered through an existing hot spot (such as a hot spot run by a seller <NUM>). Alternately, or additionally, some or all of network <NUM> can include direct links between beverage vending devices <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM>, sellers <NUM>-<NUM>, <NUM>-<NUM> and server <NUM> (if present) via Ethernet, fiber optic, and/or any other networking technologies known in the art (including, for instance, <NUM>, <NUM>, Bluetooth, cloud, near field communication (NFC) technologies, and so on).

In one possible implementation, network <NUM> can allow communication between server <NUM>, all of beverage vending devices <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM>, and all of sellers <NUM>-<NUM>, <NUM>-<NUM>. In alternate embodiments, sellers <NUM>-<NUM>, <NUM>-<NUM> can be connected to server <NUM> via network <NUM> without being connected to beverage vending devices <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM>. This can include configurations in which each of sellers <NUM>-<NUM>, <NUM>-<NUM> is connected to server <NUM> without being connected to one another.

In other possible configurations, one or more of beverage vending devices <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM> can be connected to server <NUM> via network <NUM> without being in communication with one or more of sellers <NUM>-<NUM>, <NUM>-<NUM> via network <NUM>. This can include instances where a first portion of network <NUM> enables communication between one or more of beverage vending devices <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM> and server <NUM>, and a second portion of network <NUM> enables communication between one or more of sellers <NUM>-<NUM>, <NUM>-<NUM> and server <NUM>. In one possible aspect, the first portion of network <NUM> and the second portion of network <NUM> can be separate entities.

In yet other possible configurations, beverage vending devices <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM> can be connected directly to one another -- such as in various peer to peer configurationsenabling beverage vending devices <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM> to communicate directly with each other without intervention of other devices, such as server <NUM>.

In one possible aspect, sellers <NUM>-<NUM>, <NUM>-<NUM> can enable a consumer to request a beverage dispense from beverage vending devices <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM> by transmitting an encrypted dispense string to the consumer. In such an aspect, sellers <NUM>-<NUM>, <NUM>-<NUM> can use encryption keys <NUM>-<NUM>, <NUM>-<NUM>, respectively, to encrypt communications (such as dispense strings, for example), and beverage vending devices <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM> can use one or more decryption keys <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM> to decrypt the communications.

In one possible embodiment, encryption keys <NUM>-<NUM>, <NUM>-<NUM> and decryption keys <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM> can be transmitted to sellers <NUM>-<NUM>, <NUM>-<NUM> and beverage vending devices <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM> by server <NUM>. Such transmissions can include updates of encryption keys <NUM>-<NUM>, <NUM>-<NUM> and decryption keys <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM> from server <NUM>, and can happen in any manner desired, including at set intervals, on demand, etc..

In one possible implementation, once a dispense string has been encrypted, the encrypted dispense string can be transmitted to the consumer in the form of a machine-readable code, which the consumer can present for scanning at one or more of scanners <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM> associated with beverage vending devices <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM>.

The machine-readable code can include anything known in the art, such as, for example, a code associated with a magnetic stripe, a one dimensional barcode, a two dimensional barcode, etc., and/or any combination thereof. This can include, for instance, a universal product code (UPC), a European article number (EAN) code; a code <NUM> barcode, a code <NUM> barcode, and interleafed <NUM> of <NUM> (ITF) barcode, a code <NUM> barcode, a codabar barcode, a GS <NUM> databar barcode, a modified Plessey barcode, a quick response (QR) code barcode, a Datamatrix barcode, a PDF417 barcode, an Aztec barcode, etc..

The machine-readable code can be issued to the consumer through any technique known in the art. For example, the consumer can receive a cup on which the machine-readable code is printed/formed. Alternately, or additionally, the consumer can receive a receipt, coupon, giftcard, etc., on which the machine-readable-code is printed/formed. In one possible implementation, the machine-readable code on such a receipt, coupon, giftcard, etc., can be in the form of a sticker which can be affixed to a beverage container that the consumer can use to request the desired beverage from a beverage vending device <NUM>. In yet another possible implementation, the machine-readable code can be accessed by the consumer via a handheld device (such as a mobile phone, a tablet, a laptop, etc.).

Scanners <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM> can be located anywhere on beverage vending devices <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM>, with the possibility of each beverage vending device <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM> having more than one scanner <NUM>. Moreover, scanners <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM> can include any scanning technologies known in the art configured to scan the machine-readable codes discussed above.

<FIG> illustrates an example dispense string <NUM> including information which can be meaningful to beverage vending devices <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM> in accordance with various embodiments of beverage vending device networking. In one possible implementation, dispense string <NUM> can include a collection of blocks of information (such as numbers, letters, etc.), with each block having an associated meaning. As illustrated, dispense string <NUM> includes four blocks, namely a customer identifier (ID) <NUM>, a validity period <NUM>, a type of beverage sold <NUM>, and a string serial number <NUM>. It will be understood that more or less blocks, as desired, can be associated with dispense string <NUM>, such that dispense string <NUM> can represent any variety of desired information.

It will also be understood that the number of digits of customer identifier (ID) <NUM>, validity period <NUM>, type of beverage sold <NUM>, and string serial number <NUM> as illustrated in <FIG> represent one possible implementation. More or less digits can also be used for one or more of customer identifier (ID) <NUM>, validity period <NUM>, type of beverage sold <NUM>, and string serial number <NUM>, as desired.

Customer ID <NUM> can uniquely identify a seller <NUM>. In the event that the seller <NUM> has several locations, customer ID <NUM> can be shared for all locations. Alternately different customer IDs <NUM> can be issued for each location of seller <NUM> and/or for multiple pre-chosen locations of seller <NUM> in a specific area, etc. Further, if desired, customer IDs <NUM> can be issued for individual salespeople, etc., associated with a seller <NUM>.

Validity period <NUM> can include a date of sale, date of transfer, date of a beginning of validity, etc., of dispense string <NUM>, and can be used to limit a duration of validity during which the consumer can use dispense string <NUM> to dispense a beverage from one or more of beverage vending devices <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM>. For example, in one possible implementation, by presenting dispense string <NUM> to a beverage vending device <NUM> the consumer may be allowed to get one or more beverage dispenses on a given date in validity period <NUM>. In another possible implementation, the consumer may be allowed to get one or more beverage dispenses on any day in a range of dates indicated by all or part of validity period <NUM>.

Type of beverage sold <NUM> can be used as future proofing for different pricing on different types of beverages (such as, for example, juice, tea, sparkling water, still water, etc.). For instance, if a consumer buys a beverage in a certain drink class (such as, for example, a soft drink), type of beverage sold <NUM> can indicate the specific brand/type of soft drink purchased, or the generic class of "soft drinks".

In one possible aspect, type of beverage sold <NUM> can be used to limit the consumer to beverage dispenses of only the beverage indicated in type of beverage sold <NUM>. In other aspects, the consumer can be allowed to dispense other beverages with prices equal to and/or cheaper than the beverage indicated by type of beverage sold <NUM>. For instance if the consumer purchased an expensive beverage category such as "juice", in one possible aspect, the consumer could be allowed to dispense cheaper beverage categories like "water", "flavored water", etc., in addition to juice.

String serial number <NUM> can be a unique indicator for a consumer (or a group of consumers, if desired). String serial number <NUM> can be used for a variety of purposes, including, for example, limiting dispenses to individual consumers.

In one possible implementation, an asymmetric encryption algorithm (such as the advanced encryption standard (AES) or any other algorithm known in the art) can be used to encrypt dispense string <NUM> to form an encrypted dispense string <NUM> (such as the encrypted dispense string described above) that can correspondingly be transformed into a machine-readable code <NUM> (such as the machine readable code described above) using any technique and/or technology known in the art, before dispense string <NUM> is passed to the consumer. In one possible implementation, giving a consumer an encrypted dispense string <NUM> in the form of machine-readable code <NUM>, rather than simply giving the consumer the dispense string <NUM> in the form of machine-readable code <NUM>, decreases the risk of anyone forging dispense string <NUM>. In one possible embodiment, the machine-readable code <NUM> can be designed such that it becomes obfuscated (i.e. turns black, or otherwise becomes unreadable) once validity period <NUM> expires.

In one possible implementation, encryption and decryption of dispense string <NUM> can be accomplished using private and public keys. For example, encryption key <NUM>-<NUM> of seller <NUM>-<NUM> can be a private key, and decryption key <NUM>-<NUM> of beverage vending device <NUM>-<NUM> being used by a consumer can comprise a corresponding public key. It will be noted that the same public key can be made available to all beverage vending devices <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM> in configuration <NUM>.

By utilizing private and public keys in this manner, every seller <NUM> can produce secure machine-readable codes <NUM> for their consumers by encrypting dispense strings <NUM> and converting them into machine-readable codes <NUM>. Machine-readable codes <NUM> can be scanned by scanners <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM> in beverage vending devices <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM> and the encrypted dispense strings <NUM> in machine-readable codes <NUM> can be decrypted into the original dispense strings <NUM>.

For example, in one possible implementation, when seller <NUM>-<NUM> (such as a restaurant in a food court) sells or otherwise transfers a beverage to a consumer, seller <NUM>-<NUM> can provide the consumer with a machine-readable code <NUM> on a cup, receipt, gift card, coupon, email, text, etc. Machine-readable code <NUM> can comprise encrypted dispense string <NUM>, including information such as a customer identifier (ID) <NUM>, a validity period <NUM>, a type of beverage sold <NUM>, and a string serial number <NUM>. Machine-readable code <NUM> can be preprinted (such as by manufacturers of cups used by seller <NUM>-<NUM>) or it can be printed on demand at a computing device, such as a cash register.

Sales and/or transfers of beverages to customers can be made by sellers <NUM> using any methods known in the art, including through vending machines, via mobile pay plans associated with mobile phones, etc. Moreover, sales and/or transfers of beverages can include any controls known in the art. For example customers can choose among various features, including validity periods, types of beverages, numbers of refills, etc., that they wish to purchase.

After receiving machine-readable code <NUM> from seller <NUM>-<NUM> (or one of his agents), the consumer can proceed to one of beverage vending devices <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM>, where machine-readable code <NUM> can be scanned using one or more scanners <NUM> placed anywhere desired on a beverage vending device <NUM>. Moreover, any software known in the art (such as that included in a scanning module) can be used to scan the machine-readable code <NUM> and produce encrypted dispense string <NUM>.

For example, in one possible aspect, scanner <NUM> can be located proximate an area on beverage vending device <NUM> where a container will be placed by the consumer before a beverage dispense is requested. In such a scenario, machine-readable code <NUM> on the container can be conveniently scanned. In another possible aspect, scanner <NUM> can be placed near a user interface on beverage vending device <NUM>, such that a consumer can easily place machine-readable code <NUM> proximate scanner <NUM>.

Once machine-readable code <NUM> has been successfully scanned by scanner <NUM>, and encrypted dispense string <NUM> has been accessed, beverage vending device <NUM> can decrypt encrypted dispense string <NUM> using a decryption key <NUM> to produce the underlying dispense string <NUM>. In one possible implementation, any software known in the art (such as that included in a decryption module) can be used to perform such decryption.

For example, when dispense string <NUM> has been encrypted using a private key, a decryption module can decrypt encrypted dispense string <NUM> using a corresponding public key in its encryption/decryption key(s). In one possible aspect, a keyring of multiple public keys can be stored in the encryption/decryption key(s) such that the decryption module can try several public keys before finding the proper public key associated with the private key used to encrypt dispense string <NUM> into encrypted dispense string <NUM>.

In one possible implementation, when the encrypted dispense string <NUM> is decrypted, customer ID <NUM> in dispense string <NUM> can be checked against the public key used for the decryption. In one possible aspect, if the public key is appropriate for customer ID <NUM> (i.e. customer ID <NUM> and the public key are both associated with seller <NUM>-<NUM>), dispense string <NUM> can be processed as a valid string. If not, the next public key on the keyring can be checked until a valid customer ID <NUM>-public key pair is found or until all the public keys have been tried.

If no match is found, encrypted dispense string <NUM> will not be decrypted (such as, for example, by a decryption module), and beverage vending device <NUM> can issue any desirable error message, such as, for example, that machine-readable code <NUM> is incorrect. Beverage vending device <NUM> can also display a try again strategy with instructions on how to reenter the machine-readable code <NUM>. In one possible implementation, error messages, instructions, etc., can be displayed on a display associated with beverage vending device <NUM>.

Alternately, if a valid customer ID <NUM>-public key match is found, at least some of dispense string <NUM> may be used to determine if any restrictions stand in the way of a beverage dispense exist. Such restrictions can result in the alteration, or cancellation, of a requested beverage dispense.

Restrictions can include anything desirable to seller <NUM>-<NUM> and/or a person or entity administering beverage vending device <NUM> including, for example, restrictions on refills, restrictions on a time during which beverage dispenses can be made, restrictions on an amount of sweetener that can be dispensed to the consumer in a given period of time, restrictions on an amount of calories that can be dispensed to the consumer in a given period of time, restrictions on a type of beverage that can be dispensed to the consumer given the type of beverage purchased by the consumer (i.e. purchases of water may not be eligible for beverage dispenses of more expensive beverages like juices), etc. In one possible implementation, some or all of the restrictions applicable to a beverage vending device <NUM> can be stored in a memory area that holds, for example, restrictions. Moreover, the restrictions, and their limits and thresholds, etc., can be updated through communications between beverage vending devices <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM> and one or more outside entities, including for example, server <NUM>, sellers <NUM>, etc..

In some jurisdictions, laws and/or regulations may exist stipulating a restriction that no refills be given of certain beverages. In another possible example, laws and/or regulations may exist stipulating restrictions associated with a maximum limit of calories and/or sugar that can be dispensed in one or more beverages to a consumer in a given time period. In yet another example, a restriction may exist regarding a validity of dispense string <NUM> (i.e. perhaps validity period <NUM> can allow the consumer to request a beverage dispense on a given calendar day, within a set number of hours of purchase from a seller <NUM>, and/or any other time limit set by a seller <NUM> and/or the entity administering the beverage vending devices <NUM>).

In one possible aspect, if a beverage dispense requested by a customer associated with dispense string <NUM> doesn't run afoul of any of the restrictions, a beverage dispense decision can be made to implement the requested beverage dispense from a beverage vending device <NUM>. In another possible aspect, if the beverage dispense requested by a customer associated with dispense string <NUM> does run afoul of any of the restrictions, a beverage dispense decision can be made to either issue an error message and block the requested beverage dispense, or issue an error message and present the consumer with a few options (if any are possible) on how to vary the requested beverage dispense to avoid running afoul of the restriction(s).

In still another possible aspect, if the beverage dispense requested by a customer associated with dispense string <NUM> runs afoul of any of the restrictions, a beverage dispense decision can be made automatically to implement a beverage dispense that complies with the restrictions. For example, if a consumer wishes to get a refill of a beverage, but that refill would result in a dispense of more sugar to the consumer than is allowed by a local regulation in a given period of time, a beverage dispense decision can be made to dispense an amount of the requested beverage into the consumer's container such that the total amount of sugar dispensed to the consumer over the given period of time does not exceed a threshold spelled out in the restriction. In one possible implementation, any software known in the art (including a dispense decision module) can be used to make such dispense decisions.

In one possible implementation, beverage vending devices <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM>, in configuration <NUM> can communicate with one another (either directly and/or through server <NUM>) information regarding a consumer's beverage dispenses (i.e. beverage dispenses associated with a given string serial number <NUM>). Such synchronization of beverage vending devices <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM> can be done periodically (i.e. on a set schedule), can be triggered when a beverage dispense is completed to a consumer associated with a dispense string <NUM> at beverage vending devices <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM>, or can be implemented using any other methodologies known in the art. The synchronization can be conducted over network <NUM>, and/or any other manners known in the art. Such synchronization efforts can be implemented using any software in the art including, for example, through use of a database querying module.

For example, if the present date is within validity period <NUM>, and no restrictions exist blocking dispense of a beverage being requested (i.e. the beverage being requested is authorized for dispense given the type of beverage sold <NUM>, no restrictions against refills and/or sweetener levels exist, etc.), a dispense decision can be made authorizing a dispense of the beverage being requested, and the beverage can be dispensed to the consumer. In one possible aspect, as noted above, information associated with the beverage dispense resulting from the dispense decision can then be communicated to other beverage vending devices <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM> in configuration <NUM> for future reference in case the dispense string <NUM> is presented at another beverage vending device <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM> in configuration <NUM> in the future. In one possible aspect, previous beverage dispense information like this can be stored in previous dispense information stored in memory on, for example, one or more beverage vending devices <NUM> and/or server <NUM>.

In one possible implementation, a beverage vending device <NUM> can query one or more databases for previous dispense information associated with dispense string <NUM>. This can include querying for previous dispense information on the beverage vending device <NUM> at which the consumer is requesting a beverage dispense, and/or querying previous dispense information associated with dispense string <NUM> from other beverage vending devices <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM> in configuration <NUM> and/or querying for previous dispense information associated with dispense string <NUM> on server <NUM>.

In one possible embodiment, beverage vending devices <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM> can use any technologies known in the art (including for example, Wifi and/or network <NUM>) to exchange data regarding previous dispense information associated with dispense string <NUM> (such as customer ID <NUM>). This can include, for example, an amount of beverages already dispensed in accordance with dispense string <NUM> (and when), etc. Using such an approach, a total volume of beverages poured using dispense string <NUM> within a given time period at any of beverage vending devices <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM> in configuration <NUM> can be accessed. This information can be used to comply with any existing restrictions regardless of which beverage vending devices <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM> in configuration <NUM> were previously used by the consumer presenting dispense string <NUM>.

<FIG> illustrates several example peer-to-peer configurations that can be used in configuration <NUM> in accordance with various embodiments of beverage vending device networking. For example, in a broadcast configuration <NUM>, any desired number of beverage vending devices <NUM> can be connected wirelessly using any wireless technologies in the art. In one possible implementation, any given beverage vending device <NUM> can broadcast to all beverage vending devices <NUM> or any select subset of beverage vending devices <NUM> in broadcast configuration <NUM>. For example, beverage vending device <NUM>-<NUM> can broadcast to all beverage vending devices <NUM> in configuration <NUM>, or beverage vending device <NUM>-<NUM> can broadcast to beverage vending device <NUM>-N.

In another possible configuration <NUM>, any desired number of beverage vending devices <NUM> can be connected in a star configuration through a hub <NUM>. Hub <NUM> can include any device configured to allow communication between beverage vending devices <NUM> (including implementations in which hub <NUM> is itself a beverage vending device <NUM>), and connections between the beverage vending devices <NUM> and hub <NUM> can be conducted using any communication technologies known in the art, including wireless technologies, wired technologies, and any combinations thereof.

In yet another possible configuration, any desired number of beverage vending devices <NUM> can be connected through a master/slave configuration <NUM>. For example, two or more slave beverage vending devices <NUM> can be connected to a master beverage vending device <NUM>-<NUM>. As many slave beverage vending devices <NUM> as desired can be connected to master beverage vending device <NUM>-<NUM>, and connections between slave beverage vending devices <NUM> and master beverage vending device <NUM>-<NUM> can take the form of any communication technologies known in the art, including wireless technologies, wired technologies, and any combinations thereof.

In still another possible configuration, any desired number of beverage vending devices <NUM> can be connected through a ring configuration <NUM>. For example, three or more beverage vending devices <NUM> can be connected to one another directly or via an intermediate beverage vending device <NUM>. For example, beverage vending device <NUM>-<NUM> can communicate directly with beverage vending device <NUM>-<NUM> and indirectly with beverage vending device <NUM>-<NUM> via beverage vending device <NUM>-<NUM>. Any communication technologies known in the art can be used to connect beverage vending devices <NUM> in ring configuration <NUM>, including wireless technologies, wired technologies, and any combinations thereof.

It will also be understood that the above configurations <NUM>, <NUM>, <NUM>, <NUM> can be combined in any manners possible in configuration <NUM>.

<FIG> illustrates one such possible combination of configurations. As illustrated, one or more beverage vending devices <NUM> can be placed in communication with one or more other beverage vending devices <NUM> in a configuration <NUM>. This can include direct connections between all beverage vending devices <NUM> in the group (as illustrated), and/or one or more indirect connections in any way possible between beverage vending devices <NUM>. For instance, instead of (or in addition to) being directly coupled to beverage vending device <NUM>-<NUM> via a direct connection <NUM>, beverage vending device <NUM>-<NUM> can be connected to beverage vending device <NUM>-<NUM> via beverage vending device <NUM>-<NUM> (such as, for example, in a hub and/or master/slave configuration), through connections <NUM> and <NUM>. In a similar manner, in one possible implementation, all of beverage vending devices <NUM> in configuration <NUM> can be connected to server <NUM> (if present) either directly or indirectly, such as through one or more intervening beverage vending devices <NUM>. Connections <NUM>-<NUM> can include any wired and/or wireless technologies known in the art, including any possible combination thereof.

With reference to <FIG>, in operation, a consumer desiring a beverage from one of beverage vending devices <NUM> could be granted access to the desired beverage by one of sellers <NUM>. This could be implemented through any sort of transaction known in the art including, for example, a sale, a redemption of a coupon, etc. Access to the beverage could be granted by seller <NUM> (and/or an authorized associate of the seller) in a variety of ways, including, for example, via issuance of machine-readable code <NUM> to the consumer as described above.

In one possible implementation, the machine-readable code <NUM> can comprise dispense string <NUM> encoded into encoded dispense string <NUM> using an encryption key <NUM>, which can be decoded at a beverage vending device <NUM> using a corresponding decryption key <NUM> associated with encryption key <NUM>. Encryption key <NUM> and decryption key <NUM> can be any such keys known in the art including, for example, a private key and a public key, respectively.

Configuration <NUM>, and its many possible variations, can allow for a wide range of communications among potential devices and entities. <FIG> illustrate several such possibilities in accordance with various embodiments of beverage vending device networking. As shown, beverage vending devices <NUM> can include dispensers of fountain beverages, coolers from which beverages packaged in bottles and cans can be vended, and vending machines from which packaged beverages can be vended. It will be understood that the various configurations of beverage vending devices <NUM> in <FIG> are for illustrative purposes only. For example, more or less beverage vending devices <NUM> than illustrated may be used. Moreover, any combination of the various types of beverage vending devices <NUM> may be used, including scenarios in which all of the beverage vending devices <NUM> are of the same type.

It will also be understood that the beverage vending devices <NUM> illustrated in <FIG> can be networked together directly and/or indirectly using any of the possible embodiments of network <NUM> in configuration <NUM> discussed above in <FIG> and <FIG>, including embodiments employing a server <NUM>, even though such a server is not explicitly illustrated in <FIG>.

For example, <FIG> illustrates a possible embodiment of configuration <NUM> in which three beverage vending devices can exchange information about themselves via network <NUM>. In operation, usage information associated with each beverage vending device <NUM> can be shared with other beverage vending devices <NUM> via network <NUM>. For example, if a consumer interacts with a beverage vending device <NUM> using a particular dispense string <NUM>, information associated with that interaction (i.e. the time it happened, the type of beverage that was vended, the amount of beverage that was vended, the amount of sugar in the beverage that was vended, etc.) can be shared directly and/or indirectly in any of the manners discussed herein with one or more of the other beverage vending devices <NUM>. Thus if the consumer attempts to use dispense string <NUM> at one of the other beverage vending devices <NUM> later in an unauthorized manner (i.e. requests a dispense after a designated time period has elapsed from a first dispense/vending of a beverage, and/or tries to get more beverage and/or sugar than might be allowable, etc.) the other beverage vending devices <NUM> will be able to make appropriate decisions based on what is allowable given the dispense string <NUM> and the previous beverage vends associated therewith. This can include refusing the dispense being requested by the consumer when it is seen as being unauthorized in light of the consumer's previous interactions with other beverage vending devices <NUM> on network <NUM> using dispense string <NUM>.

An example of such a scenario is illustrated in <FIG>. As shown, a consumer <NUM> interacting with beverage vending device <NUM>-<NUM> is requesting a particular beverage dispense. In one possible implementation, consumer <NUM> can present dispense string <NUM> to beverage vending device <NUM>-<NUM> via any of the scanning and/or input technologies discussed herein, and beverage vending device <NUM>-<NUM> can view information in dispense string <NUM> in light of any existing interactions with any of the various beverage vending devices <NUM> on network <NUM>, to determine if the requested dispense is authorized or not. For example, if consumer <NUM> is requesting a dispense that will put dispense string <NUM> over a predetermined volume and/or sugar content limit, then beverage vending device <NUM>-<NUM> can refuse the dispense request. Alternately, or additionally, beverage vending device <NUM>-<NUM> can authorize a pour that does not dispense more than the predetermined volume and/or sugar content limit (which can include, for example authorizing a dispense of another beverage, such as water).

In one possible implementation, any information associated with the dispense string <NUM>, such as how much more beverage and/or sugar can be dispensed, what types of beverages can be dispensed, when the dispense string <NUM> expires, etc., can be presented to consumer <NUM> via an interface <NUM> on beverage vending device <NUM>-<NUM>. Similarly, previous usage information associated with dispense string <NUM>, consumer information associated with consumer <NUM>, etc., can also be presented on interface <NUM>.

Returning to <FIG>, beverage vending devices <NUM> communicate inventory information with each other. Inventory information includes information regarding ingredients, beverages, etc., available at a beverage vending device <NUM>, including the quantities of such ingredients, beverages, etc., that are available. For example, if beverage vending device <NUM>-<NUM> is low on, or out of, ingredients for a particular beverage, this may be communicated to one or more of beverage vending devices <NUM>-<NUM>, <NUM>-<NUM>. In such a manner, the various inventory levels of each beverage vending device <NUM> are known by the other beverage vending devices <NUM> on network <NUM>.

<FIG> illustrates a scenario in which consumer <NUM> interacts with beverage vending device <NUM>-<NUM> and requests a beverage which is out of stock. In such an instance, beverage vending device <NUM>-<NUM> can inform consumer <NUM> via interface <NUM> that the beverage being requested is not available on beverage vending device <NUM>-<NUM>. Beverage vending device <NUM>-<NUM> also looks at the inventory information it has received from other beverage vending devices <NUM> and makes recommendations on where consumer <NUM> can go to get the desired beverage. For example, beverage vending device <NUM>-<NUM> issues a message <NUM> on interface <NUM> recommending the consumer to go to a nearby beverage vending device <NUM>-<NUM> at which the requested beverage is available. An example message <NUM> is illustrated in <FIG>, however it will be understood that any desired message may be displayed.

The beverage vending device <NUM>-<NUM> makes recommendations on other beverages that consumer <NUM> may enjoy which are available on beverage vending device <NUM>-<NUM>, giving consumer <NUM> a choice to either go to another beverage vending device <NUM> for the original beverage requested, or stay at beverage vending device <NUM>-<NUM> where an alternate beverage can be dispensed.

<FIG> illustrates an embodiment of configuration <NUM> in which a plurality of beverage vending devices <NUM> connected to network <NUM> can be remotely accessible to various entities <NUM> wishing to interact with (i.e. monitor, communicate with, etc.) the beverage vending devices <NUM>. Entities <NUM> can include any entity having an interest in the functioning and/or operation of beverage vending devices <NUM> including, for example, an operations manager <NUM>-<NUM>, a technician <NUM>-<NUM>, a manager <NUM>-<NUM> at a seller <NUM>, etc. Entities <NUM> can interact with beverage vending devices <NUM> using various computing devices, including a hand held device <NUM> (such as, for example, a smartphone), a tablet <NUM>, a personal computer <NUM>, a laptop, or any other computing device known in the art. In one possible aspect, entities <NUM> can interact with beverage vending devices <NUM> via an app on handled device <NUM> and/or tablet <NUM>. Further, entities <NUM> can interact with beverage vending devices <NUM> directly, and/or indirectly, such as through server <NUM> and/or one or more other beverage vending devices <NUM>.

For example, in one possible implementation, store manager <NUM>-<NUM> can interact with beverage vending device <NUM>-<NUM> via beverage vending device <NUM>-<NUM>. In yet another possible implementation, store manager <NUM>-<NUM> can interact directly with beverage vending device <NUM>-<NUM>. In still another possible implementation, store manager <NUM>-<NUM> can interact with beverage vending device <NUM>-<NUM> via server <NUM>. In another possible implementation, store manager <NUM>-<NUM> can interact with beverage vending device <NUM>-<NUM> via server <NUM> and beverage vending device <NUM>-<NUM>.

In one possible implementation, entities <NUM> can interact with beverage vending devices <NUM> via one or more internet websites associated with the beverage vending devices <NUM>. In still another possible aspect, various information may be uploaded to a beverage vending device <NUM> using an internet protocol (IP) address such as file transfer protocol (FTP), or by emailing an account associated with the beverage vending device <NUM>.

In one possible embodiment, beverage vending devices <NUM>-<NUM> can proactively adapt to issues with network <NUM>. For example, if a connection between a given beverage vending device <NUM> and server <NUM> is disrupted, the given beverage vending device <NUM> can begin communicating with server <NUM> via one or more other beverage vending devices <NUM> on network <NUM>. This can occur, for example, when the given beverage vending device <NUM> is scheduled to transmit information such as a periodic report to server <NUM>, but direct communication is not possible. In such an instance the given beverage vending device <NUM> can make its report to server <NUM> via one or more other beverage vending devices <NUM> on network <NUM>. Similar mechanisms can be used to adapt to issues encountered when interaction is desired between an entity <NUM> and a given beverage vending device <NUM>.

In one possible implementation, any of the possible methods or technologies that entities <NUM> can use to interact with beverage vending devices <NUM> and server <NUM> can be considered to be a portion of network <NUM>.

The information that can be communicated between beverage vending devices <NUM>, server <NUM>, and entities <NUM> can include anything known in the art, including, for example, any desired usage information associated with one or more or the beverage vending devices <NUM>. Usage information can include any information desirable to an entity <NUM>, including for instance how much of a beverage, ingredient, etc., has been dispensed/vended from one or more beverage vending devices <NUM>, how much of a beverage, ingredient, etc., has been dispensed/vended to individual consumers and/or given dispense strings <NUM>, composite usage information associated with a plurality of beverage vending devices <NUM>, when such dispenses/vendings occurred, etc..

Moreover, the information that can be communicated between beverage vending devices <NUM>, server <NUM>, and entities <NUM> includes any desired inventory information associated with one or more beverage vending devices <NUM>, such as ingredient levels, product levels, etc..

Further, the information that can be communicated between beverage vending devices <NUM>, server <NUM>, and entities <NUM> can further include any type of content known in the art. This can include, for example, software, recipes (such as promotional drinks, seasonal recipes, etc.) and any types of updates (such as software updates, menu updates, recipe updates, etc.) of content that may be desired for the one or more beverage vending devices <NUM>.

The information can be communicated between beverage vending devices <NUM>, server <NUM>, and entities <NUM> using any methodology known in the art. For example, information can be communicated on demand, in real time as events occur, periodically (including at preset times), when an event occurs (such as when an inventory item drops to a predetermined level), etc. Moreover, information can be requested (i.e. pulled) based on the methodology above.

In one possible implementation, the ability to interact with beverage vending devices <NUM> can enable entities <NUM> to remotely upload and download information noted herein to and from beverage vending devices <NUM>. For example, individual beverage vending devices <NUM>, can notify one or more of entities <NUM> of their inventories, including notifying entities <NUM> when ingredients and/or products get below a preset level. This can allow entities <NUM> to begin the process of proactively restocking the beverage vending device <NUM> before the ingredient and/or product goes out of stock. Further, entities <NUM> can remotely monitor individual beverage vending devices <NUM> of interest. In one possible implementation, entities <NUM> can get information on individual beverage vending devices <NUM> and/or composite information on two or more individual beverage vending devices <NUM> from server <NUM>. This can include, for example, information allowing a plurality of sellers <NUM> to accurately divide revenue from sales of beverages to consumers <NUM> interacting with beverage vending devices <NUM> (by, for example, using dispense information from beverage vending devices <NUM>, etc.).

Further, individual beverage vending devices <NUM> can access information from each other, server <NUM>, and entities <NUM>. For instance, consumer information (such as, for example, a consumer profile, etc.) can be accessed from server <NUM> by a beverage vending device <NUM> in response to an interaction with the consumer at the beverage vending device <NUM>.

In one possible implementation, entities <NUM> and server <NUM> can be termed control entities. In one possible aspect this can arise because of the abilities of entities <NUM> and server <NUM> to exert at least partial control over, and effect changes on, various beverage vending devices <NUM> in some embodiments.

<FIG> illustrates example fuel gauges <NUM>, <NUM> that can be used to present information associated with one or more beverage vending devices <NUM> in accordance with embodiments of beverage vending device networking. In one possible implementation, fuel gauges <NUM>, <NUM>, either alone or together, can be presented on the display of any computing device known in the art, including, for example, hand held device <NUM>, a tablet <NUM>, personal computer <NUM>, a laptop, etc., such that entities <NUM> can view information associated with the one or more beverage vending devices <NUM> without physically visiting the one or more beverage vending devices <NUM>. Fuel gauges can be implemented through any software known in the art including, for example, through software in a fuel gauge monitor.

As shown, fuel gauge <NUM> illustrates information associated with a given beverage vending device <NUM>, which can include, for example, an identification (ID) code <NUM> associated with the given beverage vending device <NUM>. Fuel gauge <NUM> can also include a cartridge/ingredient ID code <NUM>, an indicator <NUM> of a percentage remaining of the cartridge/ingredient, as well as a field <NUM> reporting errors being experienced at the beverage vending device <NUM>. Moreover, fuel gauge <NUM> can also display a field <NUM> associated with a cleaning status and a field <NUM> associated with a work order status of the beverage vending device <NUM>. Additionally a field <NUM> can exist to display other data of interest to an entity such as, for example, information indicating a software and/or content version, packet data for updates, information associated with a last reboot, etc..

The above content displayed by fuel gage <NUM> is for illustration only, as it will be understood that more or less content can be displayed on fuel gauge <NUM> as desired.

Fuel gauge <NUM> illustrates another possible graphic user interface that can be made available to an entity <NUM>. As illustrated, fuel gauge <NUM> can include a number of tabs <NUM>, with each tab <NUM> corresponding to a given beverage vending device <NUM>. For example, if an entity <NUM> interacting with fuel gauge <NUM> selects tab <NUM>-<NUM>, information associated with a given beverage vending device <NUM> (such as beverage vending device <NUM>-<NUM>) can be displayed, while if entity <NUM> selects tab <NUM>-<NUM>, information associated with another beverage vending device <NUM> (such as beverage vending device <NUM>-<NUM>) can be displayed. The information can be displayed in a plurality of graphic entries <NUM> which can correspond to anything of interest to an entity, including, for example, fluid levels of cartridges and/or fluid levels of bag in boxes (BIBs), inventories of bottles and/or cans, temperatures, etc., associated with the beverage vending device <NUM> corresponding to the chosen tab <NUM>. As with fuel gauge <NUM> above, fuel gauge <NUM> can be customized to display more or less items of interest in entries <NUM>.

<FIG> illustrates a system <NUM> in which a beverage vending device <NUM>-<NUM> can monitor one or more other beverage vending devices <NUM> on network <NUM>. In one possible embodiment, this can occur in real-time, with beverage vending device <NUM>-<NUM> displaying information such as inventory stock-outs, sold-outs, low ingredient levels, etc., associated with the one or more beverage vending devices <NUM> being monitored by beverage vending device <NUM>-<NUM>. This can occur on a central location such as on a display area <NUM> of beverage vending device <NUM>-<NUM>, via a stand-alone networked monitor, on a POS screen, and/or via any other desired display device. In one possible implementation, display area <NUM> can be located in a back room, at a counter, etc..

In one possible embodiment, any signals/displays known in the art can be used to indicate that ingredients and/or products at the one or more beverage vending devices <NUM> being monitored are sold out. For example, a flashing light <NUM> could indicate that something is sold out in a beverage vending device <NUM> in a dining room, while an "x" <NUM> can indicate that something is sold out on a crew served beverage vending device <NUM>. In a similar fashion, any signals and/or displays known in the art can be employed to indicate that various inventory items, etc. are running low.

<FIG> illustrate example methods for implementing aspects of beverage vending device networking. The methods are illustrated as a collection of blocks and other elements in a logical flow graph representing a sequence of operations that can be implemented in hardware, software, firmware, various logic or any combination thereof. The order in which the methods are described is not intended to be construed as a limitation, and any number of the described method blocks can be combined in any order to implement the methods, or alternate methods. Additionally, individual blocks and/or elements may be deleted from the methods without departing from the spirit and scope of the subject matter described therein. In the context of software, the blocks and other elements can represent computer instructions that, when executed by one or more processors, perform the recited operations. Moreover, for discussion purposes, and not purposes of limitation, selected aspects of the methods may be described with reference to elements shown in <FIG>.

<FIG> illustrates example method(s) <NUM> for implementing aspects of beverage vending device networking. At block <NUM> a machine-readable code, such as for example machine-readable code <NUM>, is scanned. The machine-readable code can be provided to a consumer by a seller, such as seller <NUM>, in response to, for example, a purchase of a beverage by the consumer from the seller. In one possible implementation, the machine-readable code can include anything known in the art, such as, for example, a code associated with a magnetic stripe, a one dimensional barcode, a two dimensional barcode, etc., or any combination thereof. Moreover, the machine-readable code can be issued to the consumer through any technique known in the art. For example, the consumer can receive a cup on which the machine-readable code is printed/formed. Alternately, or additionally, the consumer can receive a receipt, coupon, giftcard, etc., on which the machine-readable code is printed/formed. In one possible implementation, the machine-readable code on such a receipt, coupon, giftcard, etc., can be in the form of a sticker which can be affixed to a beverage container that the consumer can use to receive the desired beverage from a beverage vending device, such as beverage vending device <NUM>. In yet another possible implementation, the machine-readable code can be accessed by the consumer via a handheld device (such as a mobile phone, a tablet, a laptop, etc.) and be displayed on a display of the handheld device.

At block <NUM> an encrypted dispense string, such as encrypted dispense string <NUM>, can be accessed. This can include, for example, reading the encrypted dispense string from the machine-readable code. In one possible implementation, this can be implemented by a scanner, such as scanner <NUM>, located anywhere on the beverage vending device. The scanner can include any scanning technologies known in the art configured to scan the machine-readable code and produce the encrypted dispense string.

At block <NUM>, one or more attempts can be made to decrypt the encrypted dispense string. In one possible aspect, software, such as a decryption module, can be used in such an effort. For example, the beverage vending device can attempt to decrypt the encrypted dispense string using one or more decryption keys, such as decryption keys <NUM>, to produce the underlying dispense string, such as dispense string <NUM>, from the encrypted dispense string.

In one possible implementation, when the dispense string has been encrypted using a private key, a decryption module can decrypt the encrypted dispense string using a corresponding public key, such as might be stored in an encryption/decryption key(s) memory location. In one possible aspect, a keyring of multiple public keys can be available in the encryption/decryption key(s) memory location, such that the decryption module can try several public keys before finding the proper public key associated with the private key used to encrypt the dispense string into the encrypted dispense string.

In one possible implementation, when the encrypted dispense string is decrypted, method <NUM> can move to block <NUM> where a customer identifier (ID), such as customer ID <NUM>, in the dispense string can be checked against the public key used for the decryption. In one possible aspect, if the public key is appropriate for the customer ID (i.e. the customer ID and the public key are both associated with the same seller), the dispense string can be processed as a valid string and method <NUM> can move on to block <NUM>. If not, the next public key on the keyring can be checked until a valid customer ID <NUM>-public key pair is found or until all the public keys have been tried.

If no matching decryption key is found, in one possible embodiment, the encrypted dispense string will not be decrypted by the decryption module, and method <NUM> can proceed to block <NUM>. Alternately, or additionally, if the public key is not appropriate for the customer ID (i.e. the customer ID and the public key are not both associated with the same seller), method <NUM> can proceed from block <NUM> to block <NUM>.

At block <NUM>, the beverage vending device can issue any desirable error message, such as, for example, that the machine-readable code is incorrect. The beverage vending device can also display a try again strategy with instructions on how to reenter the machine-readable code into the scanner on the beverage vending device. In one possible implementation, error messages, instructions, etc., can be displayed on a display, such as interface <NUM>, associated with the beverage vending device.

At block <NUM>, if a matching decryption key is found, and the customer ID is correct, at least some of the dispense string may be used to determine allowable dispense options. In one possible implementation this can include determining if any restrictions stand in the way of a particular beverage dispense. Such restrictions can result in the alteration or cancellation of a requested beverage dispense.

Restrictions that can be used to constrain allowable dispense options can include anything desirable to the seller and/or a person or entity, such as entities <NUM>, administering the beverage vending device including, for example, restrictions on refills, restrictions on a time during which beverage dispenses can be made, restrictions on an amount of sweetener dispensed to the consumer in a given period of time, restrictions on an amount of calories dispensed to the consumer in a given period of time, restrictions on a type of beverage that can be dispensed to the consumer given the type of beverage purchased by the consumer (i.e. purchases of water may not be eligible for beverage dispenses of more expensive beverages like juices), etc. In one possible implementation, some or all of the restrictions applicable to a beverage vending device can be stored in a restrictions area in memory. Moreover, the restrictions, and their limits and thresholds, etc., can be updated through communications between multiple beverage vending devices (such as beverage vending devices <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM>, for example) and/or between the beverage vending device and one or more outside entities, including for example, a server (such as server <NUM>), and the seller, etc..

For example, in some jurisdictions, laws and/or regulations may exist stipulating a restriction that no refills be given of certain beverages. In another possible example, laws and/or regulations may exist stipulating restrictions associated with a maximum limit of calories and/or sugar that can be dispensed in one or more beverages to a consumer in a given time period. In yet another possible example, a restriction may exist regarding a duration of validity of the dispense string (i.e. a validity period, such as validity period <NUM>, during which the consumer may request a beverage dispense). The duration of validity can be, for example, a given calendar day, a set number of hours from the purchase of the beverage from the seller, and/or within any other time limit set by the seller and/or the entity administering the beverage vending devices.

In one possible aspect, if a beverage dispense requested by a customer associated with the dispense string doesn't run afoul of any of the restrictions (i.e. the beverage dispense requested by the customer is within the allowable dispense options associated with the dispense string), method <NUM> can proceed to block <NUM> and a beverage dispense decision can be made to implement the requested beverage dispense. In one possible embodiment, the beverage dispense can be made from the beverage vending device at which the beverage dispense request is being made by the customer.

In another possible aspect, if the beverage dispense requested by the consumer associated with the dispense string runs afoul of any of the restrictions, method <NUM> can proceed to block <NUM> where a beverage dispense decision can be made to either issue an error message and block the requested beverage dispense, or issue an error message and present the consumer with a few options (if any are possible) on how to vary the requested beverage dispense requested to avoid running afoul of the restriction(s).

<FIG> illustrates example methods <NUM> for implementing aspects of beverage vending device networking. At block <NUM> contact is established between a first beverage vending device and a second beverage vending device. In one possible implementation, the first beverage vending device and the second beverage vending device can take any of the forms of a beverage vending device <NUM> (i.e., beverage dispensers - such as dispensers of fountain beverages, etc., vending machines, coolers, etc.).

The first beverage device can be part of a configuration of beverage vending devices, such as configuration <NUM>, and can establish contact with the second beverage vending device using any of the possible methods associated with configuration <NUM>, through a network, such as network <NUM>. For example, in one possible implementation, the first beverage vending device can establish contact with the network and then locate the second beverage vending device on the network. In another possible implementation, the first beverage vending device can simply begin broadcasting and receive an answer from the second beverage vending device.

At block <NUM>, communication can be facilitated between the first beverage vending device and the second beverage vending device using any techniques associated with configuration <NUM>. This can include, for example, indirect communication, in which the first beverage vending device communicates with the second beverage vending device through a backend server, such as server <NUM> and/or through one or more other beverage vending device.

In another possible implementation, communication between the first beverage vending device and the second beverage vending device can occur directly, such as, through a direct connection between the first beverage vending device and the second beverage vending device.

Any information desired can be communicated between the first beverage vending device and the second beverage vending device, including inventory information, usage information, update information, software updates, etc..

<FIG> illustrates an example device <NUM>, with one or more processor(s) <NUM> and memory <NUM> for hosting programs <NUM> configured to implement various embodiments of beverage vending device networking as discussed in this disclosure.

Memory <NUM> can also host data storage <NUM> such as, for example, one or more databases, and a variety of data discussed herein. Memory <NUM> can comprise one or more forms of volatile data storage media such as random access memory (RAM), and/or one or more forms of nonvolatile storage media (such as read-only memory (ROM), flash memory, and so forth).

Device <NUM> is one example of a computing device or programmable device, and is not intended to suggest any limitation as to scope of use or functionality of device <NUM> and/or its possible architectures. For example, device <NUM> should not be interpreted as having any dependency relating to one or a combination of components illustrated in device <NUM>. Device <NUM> can comprise one or more desktop computers, programmable logic controllers (PLCs), laptop computers, handheld devices, mainframe computers, computing clusters, clouds, etc., including any combination or accumulation thereof. Further, one or more devices <NUM> can be included in beverage vending devices <NUM> and be used to provide the functionality described herein.

Device <NUM> can also include a bus <NUM> configured to allow various components and devices, such as processors <NUM>, memory <NUM>, and local data storage among other components, to communicate with each other.

Bus <NUM> can include one or more of any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of a variety of bus architectures. Bus <NUM> can also include wired and/or wireless buses.

Data storage <NUM> can include local data storage such as fixed media (e.g., RAM, ROM, a fixed hard drive, etc.) as well as removable media (e.g., a flash memory drive, a removable hard drive, optical disks, magnetic disks, and so forth), cloud storage, etc..

One or more input/output (I/O) device(s) <NUM> may also communicate via a user interface (UI) controller <NUM>, which may connect with I/O device(s) <NUM> either directly or through bus <NUM>.

In one possible implementation, a network/connection interface <NUM> may communicate outside of device <NUM> via a connected network (such as network <NUM>, for example), and in some implementations may communicate with hardware such as various functionality found in a beverage vending device <NUM>, etc. Network/connection interface <NUM> can include any device configured to send and/or receive electronic signals, including, for example, modems, three in one connectivity modules, etc..

In one possible embodiment, communication between device <NUM> and functionality in a beverage vending device <NUM> and/or consumers interacting with the beverage vending device and/or one or more remote servers <NUM>, etc., can be facilitated through input/output device(s) <NUM> via bus <NUM>, such as via a USB port, for example.

A media drive/interface <NUM> can accept removable tangible media <NUM>, such as flash drives, optical disks, removable hard drives, software products, etc..

In one possible embodiment, input/output device(s) <NUM> can allow a consumer to enter commands and information to device <NUM>, and also allow information to be presented to the consumer and/or other components or devices. Examples of input device(s) <NUM> include, for example, sensors, scanners (such as scanners <NUM>), a keyboard, a touch screen display, a cursor control device (e.g., a mouse), a microphone, and any other input devices known in the art. Examples of output devices include a display device (e.g., a monitor or projector), speakers, a printer, a network card, and so on.

Various processes of programs <NUM> may be described herein in the general context of software or program modules, or the techniques and modules may be implemented in pure computing hardware. Software generally includes routines, programs, objects, components, data structures, and so forth that perform particular tasks or implement particular abstract data types. An implementation of these modules and techniques may be stored on or transmitted across some form of tangible computer-readable media. Computer-readable media can be any available data storage medium or media that is tangible and can be accessed by a computing device. Computer readable media may thus comprise computer storage media. "Computer storage media" designates tangible media, and includes volatile and nonvolatile, removable and non-removable tangible media implemented for storage of information such as computer readable instructions, data structures, program modules, or other data. Computer storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other tangible medium which can be used to store the desired information, and which can be accessed by a computer.

In one possible implementation, device <NUM>, or a plurality thereof, can be employed within one or more beverage vending devices, seller terminals, remote servers, etc..

<FIG> illustrates an example configuration of memory <NUM> comprising computer-readable media including programs <NUM> and data storage <NUM> configured to implement various embodiments of beverage vending device networking as discussed in this disclosure. Memory <NUM> can provide any storage mechanisms known in the art to store various information, data and/or instructions such as program(s) <NUM> (including any types of software known in the art) and any other types of information and data related to operational aspects of device <NUM>. For example, programs <NUM> stored in memory <NUM> can include a decryption module <NUM>, a dispense decision module <NUM>, a network communication module <NUM>, a scanning module <NUM>, a database querying module <NUM>, a sensor module <NUM>, a fuel gauge module <NUM>, a maintenance module <NUM> and other modules that are not shown in <FIG>, such as a point of sale (POS) module, an order management module, etc. Programs <NUM> stored in memory <NUM> can also include other programs <NUM> - such as an operating system and/or assorted application programs. Programs <NUM> can be executed on processor(s) <NUM>.

Memory <NUM> can also include data storage <NUM> in which can be stored, for example, information such as encryption keys and/or decryption keys <NUM> (including encryption keys <NUM>, decryption keys <NUM>, one or more private keys and/or one or more public keys), restrictions <NUM>, dispense rules <NUM>, previous dispense information <NUM>, a dispense string library <NUM>, and other data <NUM> (including intermediate and final data created through use of one or more of programs <NUM>).

Any of programs <NUM> and data in data storage <NUM> can reside wholly or partially on any of a variety of media types found in memory <NUM> and/or media <NUM>. For example, portions of decryption module <NUM> can reside at different times in random access memory (RAM), read only memory (ROM), optical storage discs (such as media <NUM>), cloud memory, optical devices, flash devices, etc. Alternately, or additionally, some or all of program(s) <NUM> may be implemented through use of other functionality, such as electronic circuitry, etc..

Claim 1:
A beverage vending device (<NUM>) comprising:
a network interface;
one or more processors; and
a computer-readable tangible medium with instructions stored thereon that, when executed, direct the one or more processors to perform acts comprising:
establishing contact with an available network (<NUM>);
locating a second beverage vending device (<NUM>) on the network;
establishing contact with the second beverage vending device on the network;
communicating inventory information with the second beverage vending device via the network including receiving inventory levels of the second beverage vending device; and
receiving a request from a consumer (<NUM>) to dispense a beverage;
characterised in that the instructions, when executed, direct the one or more processors to perform acts comprising:
determining that the beverage being requested is not available at the beverage vending device;
utilizing the inventory information received from the second beverage vending device to determine that the requested beverage is available at the second beverage vending device; and
providing the consumer a choice to either go to the second beverage vending device for the requested beverage or stay at the beverage vending device where an alternative beverage can be dispensed.