This invention relates to an automatic drink dispensing system. More specifically, this invention relates to a portable automatic drink dispensing system having a drink suggestion engine.
At social gatherings patrons desire drinks. Usually, preparation and distribution of the drinks is accomplished by a bartender mixing and serving the drinks. Depending on the scenario, the process of obtaining the drink can be frustrating for the patron for several reasons. First, the drink area may be too busy or lightly staffed, making it difficult to order and obtain the drink. Second, the bartender may be slow, or unfamiliar with the type of drink the patron desires. Finally, the bartender could measure the quantities of ingredients incorrectly. The owner of the establishment can also become frustrated if the particular bartender is poorly trained and wastes the drinks, or works at a slower pace because this directly affects profit margins. If the event is hosted at a private location like a home or professional meeting space, those issues can be more compounded. The host must determine what the guests will drink, how to transport the drinks to the location, locate a serving area, and find someone to serve the patrons and refresh supplies as they become diminished. If the drinks run low, someone must restock the items, make sure they are chilled, and provide the accompanying products for which to serve them.
Beyond the obvious frustrations of anticipating the needs and wants of the patrons, finding the space to place the serving area, and securing a party to serve, restock, and refill products, there is also the concern associated with paying for drinks with a risky waitress or bartender. Today, identity theft is rampant. Too often patrons have their credit card numbers stolen or lost.
There are also issues at social gatherings regarding the accidental serving of alcoholic drinks to minors. At private events, such as weddings or parties, having inexperienced or unconcerned bartenders, and thus allowing everyone at the party to enjoy drinks without verifying the age of the patron, a minor can easily be mistakenly served.
Ideally, patrons of any of the above mentioned scenarios could benefit from having a system where they could order their own drink and pay for it without having to stand in a line. Bar owners or party hosts can also benefit from a system that they could set up and leave to dispense multiple types of drinks for extended periods, without human mistake or interaction.
Further, due to the advent of social media and sharing, people may desire to share information with each other regarding the types of drinks they are ordering.
For the foregoing reasons, there is a need for a portable device, capable for mixing and dispensing a variety of drinks without the need for human intervention. This device would ideally communicate wirelessly, with a computer/phone application or server to utilize intelligent logic to suggest drinks, among other benefits that will be apparent from the detailed description below.
This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the invention.
A portable drink dispenser for preparing and dispensing drinks having a housing containing one or more refillable containers is provided, wherein the drink selection may be based on a single ingredient or mixture of ingredients contained in the container(s). The drink dispenser is capable of mixing multiple ingredients from the containers, using pumps attached to each container for dispensing the drink as requested by the consumer.
The dispenser also contains a means for programming a processor to associate each pump with a particular ingredient to be mixed with other ingredients contained in other containers in the dispenser to create a drink for the consumer.
Also provided is a sealing mechanism for sealing each container to preserve the ingredients contained in the container for long periods of time.
It is another object of the present invention to provide a means for detecting the size of a container and accordingly adjusting the amount of ingredient pulled from the container to make a drink in proportion to the volume of the container size.
It is another object of the invention to provide a drink suggestion engine to generate suggested drinks based on a consumer's stored profile, the consumer's taste, concentration, and/or ingredient preference.
It is another object of the invention to select and display a drink selection based on the consumer's history of drink selection stored on a mobile device or taken from a wireless location such as a cloud.
It is another object of the invention to provide a display device to show drink selections available in the dispenser that are created from the ingredients available in the dispenser, wherein the drink selections are selectable by the consumer for consumption.
It is another object of this invention to provide an age verification system where previously stored information regarding the consumer's age or date of birth is provided to the dispenser using a storage/reading device, such as an RFID device, an identification card scanner, near-field communication (NFC) from a phone, or biometric readings of the consumer.
It is also an object of the invention to provide a method for a first dispenser to connect to other dispensers to receive suggested or most selected drink recipes from that other dispenser for use at the first dispenser. This can be accomplished using a wireless communication connection or other data transfer means.
Finally, it is the intent of the invention to utilize a mobile phone application that provides favorite drink recipes from other selected consumers, that provides alerts for low ingredient levels, and provides the capability to perform other administrative tasks.
Still other objects of the present invention will become readily apparent to those skilled in this art from the following description wherein there is shown and described the embodiments of this invention, simply by way of illustration of the best modes suited to carry out the invention. As it will be realized, the invention is capable of other different embodiments and its several details are capable of modifications in various obvious aspects all without departing from the scope of the invention. Accordingly, the drawing and descriptions will be regarded as illustrative in nature and not as restrictive.
Various exemplary embodiments of this invention will be described in detail, wherein like reference numerals refer to identical or similar components, with reference to the following figures, wherein:
The claimed subject matter is now described with reference to the drawings. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the claimed subject matter. It may be evident, however, that the claimed subject matter may be practiced with or without any combination of these specific details, without departing from the spirit and scope of this invention and the claims.
As used in this application, the terms “component”, “module”, “system”, “interface”, or the like are generally intended to refer to a computer-related entity, either hardware, a combination of hardware and software, software, or software in execution. For example, a component may be, but is not limited to being, a process running on a processor, a processor, an object, an executable, a thread of execution, a program, and/or a computer. By way of illustration, both an application running on a controller and the controller can be a component.
The dispenser 10, may be portable in nature and can generally be placed on a table or countertop. The dispenser 10 can be made from any material including polycarbonates, ceramics, metals, or plastics or any other material not yet known which serves the structural purpose necessary to support the device and the internal components.
Various components of dispenser 10 are contained within a housing 20 and a removable top 30. On its front side, housing 20 includes a display/input device 24, a recess 21 and a nozzle 25 located within recess 21. Although not shown in
The display/input device 24 includes a main display area that can be touch screen or include one or more buttons that a consumer can press to initiate various operations of the dispenser 10. For example, display/input device 24 may have a button that a consumer can actuate to select a drink or to begin drink flow from nozzle 25. As another example, display/input device 24 might include a touch screen interface for performing administrative tasks, such as initial set up or ingredient refilling of dispenser 10. Also, the display/input 24 device may be a voice recognition system wherein the display/input device may be in a listening (voice recognition) mode where based on the consumer's previously recognized voice, an input may be provided to processor 241 (as shown in
Generally on the top side of housing 20, dispenser 10 includes a pump bank 23 and the open ends of a number of container(s) 22. Pump bank 23 is made of multiple individual pumps. Each individual pump in pump bank 23 is coupled with each container(s) 22. As used herein, “coupled” includes two elements that are attached directly or by one or more intermediate elements. Each pump in pump bank 23 can include a variable speed peristaltic pump or other type of known pump used for pumping beverage grade liquids at a controllable rate, with pump speed versus flow rate data provided by the pump manufacturer or determined through a calibration test. Container(s) 22 can be made of anything capable of holding consumer grade liquids, including glass, plastic, paper or a bag-in-a-box (BIB).
A controller, which is not shown in
Now referring to removable top 30 of dispenser 10, the removable top 30 has on its underside, a sealing mechanism 31. When the removable top 30 is placed on the housing 20, the sealing mechanism 31 intended to be positioned to contact each open end of container(s) 22. The contact between the sealing mechanism 31 and each container(s) 22 is intended to be substantially airtight to prevent contamination, prevent spillage and preserve the integrity of the ingredients contained in each container(s) 22. The sealing mechanism 31 may be a silicone type or other acceptable material now known or later developed, which does not contaminate or alter the general nature of the ingredients in container(s) 22. One of ordinary skill in would recognize that the sealing mechanism 31 can be individual seals that are attached to each container(s) 22, without being attached the removable top 30, without departing from the scope of the invention.
As explained more fully below, controller 240 is configured to control operations of dispenser 10. Controller 240 communicates instructions to and receives signals from display 24. In a similar manner, controller 240 communicates with and/or supplies power to the wireless radio 150, reader 100 and display 24.
Controller 240 also communicates control signals and/or provides power to each pump of pump bank 23. Each pump of pump bank 23 includes an electric motor and a pumping mechanism. In response to control signals and/or power from controller 240, the motor drives the pumping mechanism so as to pull and dispense ingredients from container(s) 22. In particular, each pump of pump bank 23 is in fluid communication with hose 27. As used herein, “in fluid communication” means that fluid can flow from one named point to another named point. Once container(s) 22 has been filled with an ingredient and hose 27 is inserted into the container(s) 22, a corresponding pump in pump bank 23 can thereby withdraw that ingredient from that container. A second end of hose 27 is attached to a fitting (not shown) of a corresponding pump in pump bank 23. Fluid output from the actuated pump in pump bank 23 flows through a hose 28 to nozzle 25. So as to avoid unnecessary drawing detail, certain conventional components have been omitted from
Each container(s) 22 has an associated reader 100 in communication with it. Reader 100 is a fluid level sensor. Numerous commercially developed types of fluid level sensors and associated electronics are known in the art and thus not further described here. Other embodiments may employ different types of known and commercially available data reading devices to identify ingredients in container(s) 22, including but not limited to RFID (radio frequency ID) readers, bar code scanners, OCR (optical character recognition) scanners, etc. Reader 100 periodically sends data updates to processor 241 indicating the measured ingredient level in each container(s) 22. Using that measured ingredient level, processor 241 then stores that data in memory 242 and initiates actions if the ingredient level is below a certain thresh hold. For example, processor 241 can initiate commands to send a text message to the owner of the dispenser 10 alerting him that ingredient levels are low.
As discussed above, processor 241 also determines the appropriate rate at which pump 23 must be operated so as to mix the ingredients in the correct ratio. The determined mixing parameters can then be stored in memory 242.
In operation, as a consumer inputs a drink selection at display 24, processor 241 receives a dispense signal. In response to the dispense signal, processor 241 accesses the data previously stored and associated with the dispense signal in memory 242 and activates components of pump bank 23, in accordance with that data. For example, if the consumer were to make a drink selection that calls for ingredients to be dispensed from two separate container(s) 22, the dispense signal would initiate that selection and according to the stored data associated with those signals, the processor 241 would send the appropriate pump control signals to pump bank 23 to dispense the ingredients from those containers. This action can be performed for a single container(s) 22 or for multiple container(s) 22. This may also be performed in any sequence based on the dispense signal.
Also shown in
The server 40 also contains at least one processor for carrying out their server's specific functions and commands related to the functions performed by the server 40. In the next subsequent few paragraphs, examples of some of the functions that may be carried out by each server will be illustrated for contextual purposes. However, one of ordinary skill in the art will recognize that other functions and commands may be carried out in each server without departing from the scope of this invention.
According to the embodiments of this invention, the server 40 contains at least a drink suggestion engine function, a mobile application function, a dispenser function and an administration (admin) function. These functions may be performed by separate dedicated processors or they may be performed by a single set of instructions contained in a single processor. In general, server 40 initiates, executes, stores, sends and retrieves commands and data related to these functions to and from the mobile device 80, the wireless radio 150 and other connected dispensers, as shown in
Drink Suggestion Engine Function
The drink suggestion engine function's purpose is to provide a consumer with a listing of drinks suggested based on a previously stored, newly created profile or previously stored data in dispenser 10. More particularly, the drink suggestion function uses previously stored data to provide a listing of drinks to the consumer that are based on ingredients or other drink characteristics stored in container(s) 22 that are the same or similar to drinks either stored in the consumer profile or recently ordered from the dispenser 10. In the case of using a consumer profile, upon the input of a consumer profile at display 24, the processor 241 communicates with the server 40 to retrieve drink suggestions from the data stored in the server 40 based on the same or similar ingredients or characteristics. For example, if a consumer has traditionally ordered drinks with cranberry juice as one ingredient and that ingredient is currently in container(s) 22, the processor 241 will retrieve drink recipes from the server 40 that are cranberry juice based and present those in a listing to the consumer for selection. Also, instead of using a particular ingredient from previously ordered drinks, the drink suggestion engine may suggest drinks based on other characteristics that have been previously tagged by the consumer or previously stored by a system administrator. This may include suggesting drinks based on taste preference from user such as strong, sweet, sour, etc. It should be understood that while this exemplary embodiment describes the drink suggestion engine as being a part of the server 40, it should be understood from one of ordinary skill in the art that the drink suggestion engine may be local to the dispenser 10 or in the mobile application, without departing from the scope of this invention.
In the case of using data from the dispenser 10, the consumer may select an input from display 24 asking for the most popular drinks ordered from dispenser 10. These suggested drinks will also be based on the current ingredients contained in container(s) 22. Upon processing of this information by the processor 241, the dispenser 10 will interact with server 40 to retrieve and display a listing of drinks based on this selection and data. Going forward, both listings of drinks (profile based and dispenser based) will commonly be referred to as “suggested drinks”.
Mobile Application Function
The mobile application function's purpose, among other things, is to manage and initiate commands related to communications to and from mobile device 80. Mobile device 80 may communicate with the dispenser 10 directly or via the wireless radio 150 or via routing through server 40 to dispenser 10. The server 40 further may be in communication with one or more databases, that store drink selections and various items of data (application data) related to providing suggested drinks or drink recipes to users of mobile device 80, as well as storing and using consumer profiles. Such consumer profile data may include a mobile device user profile or profiles of other consumers that are downloadable by mobile device 80, and metadata related to the application files that allow users of mobile device 80 to catalog consumer profiles stored on the mobile device 80. The application metadata also may include information regarding the cost of drinks, any promotional pricing changes or the like to be applied to a particular dispenser 10, information regarding the geographic markets and end-user language for which the server 40 may retrieve data from, editorial content such as media and consumer reviews of a drink selection, any mobile operator-specific business policies that are to be applied to the purchase of a drink, and any other suitable type of metadata related to drink selections and suggested drinks stored in the server 40.
For illustrative purposes, a consumer may input their favorite drink selections or suggested drinks in a mobile application resident on mobile device 80. Communicating through the wireless radio 150, the processor 241 may connect to server 40 and retrieve the drink recipe or the consumer may push the recipe down to dispenser 10 using the same bidirectional communication. Alternatively, the mobile device user may wish to provide or “tag” their suggested drinks on the server 40 for use in providing suggested drink listings, as described above.
The server 40 also may also store consumer profile data, which can be input from the mobile device 80 by a user. The consumer profile data may include data related to individual consumers, including but not limited to a consumer's identity, account number, credit card/debit card/other preferred payment mechanism, type of mobile device used by each consumer, geographic location of each consumer, language preferences of each consumer, etc.
Administrative Function
Continuing with
The administration function may also allow a consumer to submit/store new drink selections for inclusion in the suggested drink listings of server 40, to submit updates and new versions to the mobile application used by mobile device 80, to push promotions for drinks, to modify pricing, business rules, and other information related a dispenser 10, and to take any other suitable action related to interactions submitted using mobile device 80 and/or configured to be operated on other dispensers that access the server 40. The server 40 also contains a processor for carrying out functions, such as determining what function (administration, application or dispenser) an incoming command relates to and thus routing the command to the appropriate function for execution or storage. For example, the administration function can parse profile updates and suggested drink data being sent from a mobile device consumer so that it can be stored in the appropriate locations of data servers of server 40.
Dispenser Function
The server 40 may also contain a dispenser function where various processes related to other connected dispensers can be carried out. In general, the dispenser function is provided to provide a means for dispenser 10 to remotely communicate with another dispenser connected to server 40. For example, in some instances an owner may own multiple dispensers 10 and would like to provide drink selection data from dispenser 10 to the other dispensers owned by the consumer. The dispenser function identifies and stores data related to each of the owner's dispensers such that the other owned dispensers can be identified and communicated with. This can be in the form of a unique identifier of each dispenser, profile and/or location data of each dispenser. Additionally, using the administration function, as described above, a consumer may update the appropriate firmware of all owned dispensers simultaneously. Lastly, a consumer having a mobile application resident on a mobile device 80 may be able to retrieve ingredient level information from all dispensers that he/she owns.
Additionally, for example an owner of dispenser 10 may want to provide drink recipes to another dispenser connected server 40, but not owned by that particular owner. For example, if an owner's friend has a dispenser connected to server 40, and that owner has authorization to provide or retrieve suggested drinks directly to the friend's dispenser, the owner may initiate that process at dispenser 10 to identify the profile and authentication of the friend's dispenser and push or retrieve suggested drinks to the friend's dispenser. The processor 241 may initiate operations input by the consumer at display 24 to connect to the other dispenser and retrieve and display a listing of drinks from the other dispenser. From there, the consumer may select a drink and then be prompted by processor 241 on how to setup their dispenser to make the same drink.
In some embodiments, the methods may be implemented in one or more processing devices (e.g., a digital processor, an analog processor, a digital circuit designed to process information, an analog circuit designed to process information, a state machine, and/or other mechanisms for electronically processing information). The one or more processing devices may include one or more devices executing some or all of the operations of the methods in response to instructions stored electronically on an electronic storage medium, such as memory 242 shown in
At operation S3100, the consumer is prompted to select from a series of preprogrammed drink themes stored in a memory. This selection of drink theme begins the instructions for filling the dispenser and allows the consumer to select a drink configuration for the dispenser. For example, the drink themes can be based on a basic set up, a themed setup or brand specific set up. In this example, the basic set up could be based on drinks made from traditional alcohol based drink ingredients, such as vodka, rum, whiskey, gin, cola, water, orange juice and tonic. The themed selections could be based on a selection among geographic areas (Hawaiian, Caribbean, etc.), where the ingredients requested by the dispenser at operation S3200 will be those ingredients that traditionally make up drinks from a particular region. Also, the drink theme presented to the consumer may be based on a brand of drink. For example, the processor may be preprogrammed with drinks based on Bacardi™ brand ingredients. Operation S3200 may be performed by a controller that is the same as or similar to controller 240 shown in
At operation S3200, a processor then causes a display to show a series of instructions to the consumer to fill each container with a particular ingredient, based on the drink themes selected by the consumer at operation S3100. Unlike other methods discussed below, because the processor is presenting the instructions to the consumer there is no need write data to the memory indicating what ingredient has been placed in each container. In this operation, the consumer simply needs to follow the preprogrammed on screen instructions. For example, an instruction can be that orange juice needs to be placed in the first container and cola should be placed in the third container. The instructions will continue until each container is filled or until all ingredients for the selection have been added. The method then continues to operation S3300.
At S3300, the consumer verifies that the instruction steps have been completed. The operation moves to S3400, where the processor resets the dispenser by priming the pumps and places it into dispense mode and ends.
At operation S4150, if necessary, the processor then may initiate an age verification process to ensure that the consumer is of an age suitable to purchase beverages from the dispenser. Execution of this operation may be made dependent on the set up previously initiated in the set up process, as illustrated in
At operation S4200, a preprogrammed message is displayed indicating that the age verification was not complete, no drink is dispensed at S4250 and then the process ends.
At operation S4300, where the consumer's age has been verified, the processor may retrieve a consumer record from memory to determine if the consumer has a favorite drink(s) or a drink that they have previously stored as a drink that they would like to try. If the consumer does not have a previously stored consumer profile, the process automatically moves to operation S4350, where the ingredient levels in the containers are read by a liquid level reader and provided to the processor to determine which drinks will be suggested to the consumer at operation S4400.
If a consumer's profile is available, once the ingredient levels have been checked for availability, the processor retrieves and displays drinks that can be made from the ingredient levels available in the containers that are the same or similar to drinks in the consumer's profile. If there is not an available consumer profile, the processor will create suggested drinks from the available ingredients in the containers based on drink recipes previously stored in the dispenser or based on a listing of suggested drinks retrieved from a server. Additionally, characteristics such as the strength of drink, the most ordered drink or drinks suggested from a consumer through a mobile phone application may be used by the processor to determine suggested drinks to display. The process then moves to S4400 where the suggested drinks are displayed to the consumer.
At this point, the consumer may either select one of the suggested drinks, in which the memory will be cued for the selected drink; or the consumer may not select any of the suggested drinks and create their own drink selection. The process moves to operation S4450 where the processor goes into a loop and waits on the consumer to select one of the suggested drinks or decide to make their own selection. If the consumer selects one of the suggested drinks, the process moves to S4500; otherwise, if the consumer indicates that the selected drinks are not wanted, the process moves to operation S4550.
At operation S4550, the consumer may choose to create their own drink based on the ingredients already contained in the dispenser. Here, the consumer can select each ingredient to be mixed and dispensed for consumption. This is achieved by inputting a series of selections on the display indicating how many units of each ingredient the consumer wants dispensed. For example, the consumer may select two units of cola and one unit of rum to be dispensed, if they are available in the container and the ingredient levels are adequate. Upon completion of the selections, the process moves to operation S4600 and then to S4650 where the processor queries a liquid level reader to ensure that the selected ingredient units are present in the dispenser. As in this example, if the two units of cola are not available in the containers, the selected drink cannot be dispensed. Therefore the process returns to operation S4400 where the processor would perform operations to suggest drinks to the consumer based on the ingredient levels available in the dispenser; otherwise the process moves to S4700 where a payment for the selected drink may be requested.
Returning now to operation S4500, where the consumer has accepted the suggested drink, the processor will query the memory for the correct recipe of the selected drink. The process then moves to operation S4700, where a payment is requested and authorized. Should a payment not be needed, the process moves past operation S4700 and then moves to operation S4750.
At operation S4750, the pumps attached to the containers with the selected ingredients are readied and the process may then initiate a process to determine the size of the cup and recalculate the recipe to fill a larger cup. For example, the dispenser may initially calculate a recipe for a 10 oz. drink. Should the consumer put an 18 oz cup in the recess, the processor will recalculate the recipe to dispense an 18 oz drink, rather than a 10 oz drink. The drink is then dispensed at operation S4800 and the process ends.
The process in
At operation S5100, the dispenser connects to a server to retrieve suggested drinks from the consumer. Upon the processor initiating a command to retrieve the identified suggested drinks, the consumer's identification and drink suggestions are communicated over a communication network from the remote server connected to the dispenser. The dispenser then stores the suggested drinks in a suggested drink list in its memory for use and display to the consumer. The process then moves to operation S5200.
At operation S5200, the consumer selects a drink from the suggested drink list. This selection can be any method, such as interaction with a graphical user interface (GUI). From there, the process moves to S5300, where the processor queries a liquid level reader to ensure that the needed ingredients are present in the dispenser. If so, the processor moves to operation S5400 where the drink is added to the suggested drink list and output to the display. If not, the process moves to operation S5500 to see if there are enough empty containers available to add the necessary ingredients. If there are enough empty containers. The process moves to operation S5600 where the consumer follows on screen instructions to fill the containers with the ingredients needed for the suggested drink. Then the process ends.
At operation S6100, the dispenser connects to a wireless communication network to retrieve suggested drinks from the consumer. Upon the processor initiating a command to retrieve the identified suggested drinks, the consumer's identification and drink suggestions are communicated over the communication network from the remote server connected to the dispenser. The dispenser then stores the suggested drinks in a suggested drink list in its memory for use and display to the consumer. The process then moves to operation S6200.
At operation S6200, the consumer selects a drink from the suggested drink list. This selection can be any method, such as interaction with a graphical user interface (GUI). From there, the process moves to S6300, where the processor queries a liquid level reader to ensure that the needed ingredients are present in the dispenser. If so, the processor moves to operation S6400 where the drink is added to the suggested drink list and output to the display. If not, the process moves to operation S6500 to see if there are enough empty containers available to add the necessary ingredients. If there are enough empty containers. The process moves to operation S6600 where the consumer follows on screen instructions to fill the containers with the ingredients needed for the suggested drink. Then the process ends.
What has been described above includes examples of the claimed subject matter. It is, of course, not possible to describe every conceivable combination of components or methodologies for purposes of describing the claimed subject matter, but one of ordinary skill in the art can recognize that many further combinations and permutations of such matter are possible. Accordingly, the claimed subject matter is intended to embrace all such alterations, modifications and variations that fall within the spirit and scope of the appended claims. Furthermore, to the extent that the term “includes” is used in either the detailed description or the claims, such term is intended to be inclusive in a manner similar to the term “comprising” as “comprising” is interpreted when employed as a transitional word in a claim.
This application claims priority to Provisional U.S. Patent Application Ser. No. 61/700,312, filed Sep. 12, 2012, and titled “Method and Apparatus for Mixing and Distributing Alcoholic Beverages,” which application in its entirety is incorporated by reference herein.
Number | Date | Country | |
---|---|---|---|
61700312 | Sep 2012 | US |