Patent Application
20250124489
Restaurant style point-of-sale systems can take an order from a user in a restaurant, automatically share that order to the food and drink dispensers, e.g., the bartenders and/or the kitchen, and maintain the bill for that order.
Many different systems of this type are known, including handheld systems that wirelessly communicate to another location.
Patent applications, including US 2009 0261974, describe a system that wirelessly monitors inventory in the dispensing of items.
The inventors recognized that there are a number of drawbacks with the current systems and recognized ways to improve the process of handheld devices beyond those described in previous patent applications.
Embodiments describe a drink dispensing system, that allows purchasing drinks, and following the process after the drink has been purchased to add additional accountability to the system such that it makes it more difficult for employees to pour free drinks and makes it less likely to provide drinks without billing for them.
In the Drawings:
the figures show aspects of the invention, and specifically:
The present application describes a system for monitoring the dispensing of products in a sales establishment, and maintaining sync between items that are dispensed, and the charges that are made for those items.
An embodiment describes monitoring the dispensing of alcoholic drinks. However, it should be understood that this system can be used to can monitor different products in different environments including food, non alcoholic drinks, as well as other items that are sold and dispensed in an environment including a restaurant environment.
An embodiment of the overall hardware used according to the present system is shown in
The block diagram of
The information read from the unique liquor bottle can be a unique identifier such as an RFID tag. The unique identifier is associated with the bottle weight and contents in a database 140.
In other embodiments, the unique identifier can include a barcode, or a hologram uniquely identifying the bottle, so that the identification and the bottle and its weight can be sent from each scale at each time to the server 150.
All locations where the bottles are located is also monitored by cameras, e.g, cameras 115, 116. In an embodiment, there are sufficient cameras to image and video every area which can store, or transport, or pour from liquor bottles. The information from the cameras and the scale and reader 100 is stored by a server 130 which operates as described herein.
The flowcharts shown in the figures can be carried out on one or more of the computers, and can be carried out on a cloud computing based system, or a distributed flowchart carried out using multiple different systems, for example individual users with phones or terminals such as point of sale system or comparable terminals having their apps carry out parts of the system operation which then communicate with a central database. Different parts of this invention can be used individually.
Each bottle typically arrives as part of a shipment of multiple bottles. As an initial step, the bottle is uniquely identified. In an embodiment, this can use an RFID tag that is affixed to the bottle. In an embodiment, there can be multiple different RFID tags, each with a unique address. These can be located in the stockroom in a sheet or roll of stickers that are manually or automatically affixed to the bottle when the bottle arrives in the stockroom. In other embodiments, this can use for example a QR code, which defines a unique ID, or can use some other form of identification. In an embodiment, the ID can be etched on to the bottle using a laser.
The specific contents of the bottle can be obtained. An embodiment can read universal product code or UPC of the bottle to find its contents. In another embodiment, the contents of the bottle can be determined from the camera obtaining information about the bottle contents and using an artificial intelligence algorithm to automatically determine the bottle contents by reading the printed on the bottle of the brand, alcohol type of the bottle, and its size.
When a UPC is used, The UPC brings up the bottle information about the specific contents of the bottle.
This forms a database 140 which is accessed and processed by the server. The database includes for each bottle, a unique bottle ID 141, information 142 indicative of the contents of that bottle, and the weight of the bottle 143. As described herein, the weight of the bottle will change over time.
In embodiments, each bottle is stored on a sensor such as 100. In an embodiment, the sensor weighs the bottle, and reads the RFID from an reader that is part of the sensor 100. In this way, whenever the bottle 101 is removed from the sensor, the sensor detects the weight go from a current weight to zero or close to zero. This weight change causes a lift event, where this detects the bottle being lifted from its sensor.
Similarly, when the bottle is replaced on the sensor, the weight goes from zero or close to zero, to a weight that includes its new and modified contents. This causes a replace event. After the replace event, the weight change between the weight before the lift event and the weight after the replace event is determined.
Each bottle is stored in a weighing and identifying location on a sensor. Sensors are shown herein as 100 or 110, however it should be understood that there can be many more systems, and any of a number of different systems can be used for this storage.
The drink order and pour operation is carried out as shown in
The database creates a list of drinks, shown as 220. This may be displayed to a drink dispenser, e.g., a bartender, in some way, or may produce paper tickets, or in some other way displayed to the person who is making the drinks.
In a more simple system, such as at a bar, the bartender may just make the drink when it is ordered, and there may be no display terminal.
The terminal or database includes a list of drink shown as drink 1, drink 2 and drink 3; although in general there could be only one drink or there could be many such drinks.
At 230, a lift event is detected. The lift event is when a bottle is removed from its sensor. The contents of the bottle are detected at 235, by matching the bottle's unique ID to its contents. The contents of the bottle are then matched to a drink that has been previously stored in the serving terminal, if there is a proper match.
If the UID is not matched to a drink, then a timer is started at 240. If no drink match is found at the end of the timer at 245 then an unmatched drink exception is declared at 250, indicating that a drink has been poured without a corresponding order.
When the bottle is replaced on the sensor, a replace event occurs at 260. The replace event indicates that the bottle has been put back. At this point, the weight change 265 is detected, which is the weight change for the drink. This is matched at 272 the specific drink, here drink 2. For example, if drink 2 was for a well vodka based drink, then the weight change at 265 should be a single shot weight change for a well vodka. If the weight change at 265 does not match to the order, then an exception is declared at 275 The exception at 275 may be additional to the exception for other exceptions.
In an embodiment, a drink pouring employee (bartender) can select an order to indicate that it is being poured, or the order otherwise comes into focus of the employee. For example, there can be many drinks on the terminal, and the top order can automatically be in focus. The top order will thus automatically be associated with the current actions of the server unless the server takes some other action in order to show that some other order is being poured. The server can select a different order, making that order become the order under action.
Other embodiments can automatically match the order to the poured drink.
In this embodiment, any time an exception is declared, video footage from the cameras in the area of the exception are associated with the exception. All of the video footage from every camera that was facing the inventory receiving is saved, and associated with this exception. This allows a supervisor or other person reviewing the exception later after it has occurred, to receive the video as part of the exception, to determine how the exception was caused. Exceptions as described herein can be caused by lift events that are not associated with orders, orders that do not get subsequent lift events and subsequent weight reductions, excessive weight reductions for the order that was placed, or the wrong material being poured for the order that was placed.
in certain embodiments, such as when this is used by a bartender at a bar, there may be a single order made to a single drink pouring individual, and the single order is then matched to a pour event caused by a lift event, followed by a replace event.
However, this may not be practical in a busy bar situation. In a busy bar situation, the bartender may receive multiple orders and once, and may also pour multiple drinks at one time.
When a lift event is detected, at 310, the system analyzes which bottle was lifted and poured, and then analyzes the list created at 305 to find the earliest order in the order list for that same bottle contents.
If this matches, then the order previously received is matched to the drink when it is later poured, and detected via the lift event and replace event, followed by the weight reduction.
If the lift and replace weight reduction event does not match to an order in the list, or matches to an order which is out of sync, then an exception is reported at 316. The order can be too old (e.g., more than 15 minutes old) or otherwise unmatched to the pour event.
If the drink is poured within the time window, then 320 determines if the amount of liquor that was poured is appropriate to the order. If not, an overpour exception is declared at 325. If the drink is not poured within the time window or direction at 315, then a general exception is declared at 316.
In an embodiment described above, the order matching is carried out according to the earliest order of the same material/liquor that is poured. However, the order matching can also be carried out or can include a destination. In this embodiment, when the customer orders a drink at 200, and the drink is entered into the database, it also includes either a destination such as a table number, or a server indication such as a server number. In this embodiment, the order matching finds not the correct bottle for the earliest order, but rather the correct bottle for the destination match.
At 400, the system detects a lift event. 402 detects if there is a matching order, using any of the techniques described herein, or any other technique of matching to an order. If there is a matching order, flow discontinues. If not, at 405, the system finds the most relevant point of sale device. This may be, for example, the closest point-of-sale to the lift event, which may be the server who is closest to the bottle that was lifted. Alternatively, the most relevant point-of-sale may be that associated with the server who is taking the most orders. The most relevant point-of-sale can be determined by artificial intelligence techniques to determine who is most likely to be the server taking the orders that was not entered not the POS.
At 410, the system pops up on the point-of-sale of the most relevant terminal, that drink X has been determined. This is done by detecting from the lift event, which alcoholic beverage has been lifted, and in the case of an actual poor detects how much of the alcohol has been poured. This can automatically form an order or drink to be added to an order. At 410, this pops up a message that drink X has been detected, and asks if drink X can be added to a new or existing order.
This operation can be carried out before an exception or incident is detected or did established in any of the other flowcharts. This also provides the server an opportunity to add this to the order, more easily since it is automatically populated specifically what has been served, and also minimizes the number of exceptions which are declared.
The previous description of the disclosed exemplary embodiments is provided to enable any person skilled in the art to make or use the present invention. Various modifications to these exemplary embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without departing from the spirit or scope of the invention. Thus, the present invention is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.
