Abstract:
A liquid level sensing and reporting system for bar keepers is proposed, having a liquid level sensor in wireless communication with a remote computer having software algorithms for calculating and reporting volume. The sensor is substantially in the form of a liquor bottle spout, and includes a means for measuring the height of the liquid in a bottle, sensing inversion of the spout, and sending the data wirelessly to a receiver. The receiver is associated with the computer, and transmits the data to the computer which calculates liquor volumes based on the changing height of the liquid in a bottle from pre-pour to post-pour status. The software extrapolates this information to produce a variety of real-time beverage consumption reports, including error reports caused by over pours, under pours, and skimming.

Description:
[0001]    This application claims the benefit of the filing date of provisional application No. 61/292,472, filed on Jan. 5, 2010. 
     
    
     BACKGROUND 
       [0002]    Monitoring the volume of beer, wine and liquor decanted by bartenders in dram shops to prevent skimming and other theft is known in the art. Various devices in the current art have been developed to automatically limit and/or record the volume of liquid decanted from specific liquor bottles. Devices in the current art, however, are prone to error, may be easily modified to avoid theft detection, and adversely affect the relationship between bar tenders and customers. 
         [0003]    The present invention is therefore drawn to an improvement in the art of liquid measurement and monitoring, and particularly to a device for accurately measuring and monitoring liquor sales. In particular, the invention is drawn to an apparatus for accurately gauging beverage container liquid level change and reporting it to a remote computer for calculation as bartenders decant liquids, correlating individual bottles to beverage type, and reporting volume errors based on prior bottle volumes and cash register data, while still permitting bar tenders to determine individual pour volumes. These and other objects of the invention will be further developed in the appended summary, description and claims. 
       SUMMARY 
       [0004]    The present invention is directed to an apparatus and process satisfying the need for accurate liquor measurement, particularly in a bar setting. The invention includes a liquid measuring device having a liquid level sensor or probe for ascertaining the position of a liquor bottle liquid level. Also included in the device is a transmitter associated with the sensor, adapted to wirelessly transmit liquid level data from the sensor to a remote computer. The sensor device includes a spout for decanting liquid, and a means for detecting when the spout is inverted. 
         [0005]    Software installed on the computer receives liquid level data, translating it into volume data and processes the information using algorithms to establish for one or more vessels, a first “pre-pour” volume and a second “post-pour” volume. The pre and post pour volumes are used to calculate the quality of liquid decanted from a bottle during pour events, and more importantly, allow the software to recognize anomalies or volume errors. Instances of anomalous pour events include the following examples: a bottle is inverted and the liquid level doesn&#39;t change; a bottle upon re-inversion has not been inverted and the liquid level changes. Other examples, including liquid change correlation with point of sale data are anticipated. 
         [0006]    Additional embodiments of the invention include a memory and transfer device for wirelessly transmitting pour data to a remote computer or receiver/transmitter that can then forward the data to a computer for software processing. The spout may also include liquor type-identifying indicia, and a programmable viewing screen. In one embodiment, the spout may comprise an accelerometer to determine its orientation. 
         [0007]    In additional embodiments of the spout, it is anticipated that the sensor may be a float-type sensor, capacitance sensor or optical sensor. Movement sensing and spout orientation may be accomplished by an Accelerometer, MEMs Gyroscope or similar sensor. Preferably the spout has an input for programming the spout. 
         [0008]    For the software to generate reports, it must correlate a first set of volume data, the “pre-pour” and “post-pour” data from a spout with a second set of data based on the size and contents of a particular bottle. Container size information, liquor description, product brand, code, and vendor identifiers may also be included in the second set of data. Using predetermined formulas to calculate vessel volume with volume change data, vessel volume change information can be delivered in real time as bottles are decanted. 
         [0009]    In addition to calculating volume data, the software program includes the ability to correlate data from the spout to identify multiple pours in cases where liquor is decanted into multiple glasses with a single inversion. The multiple pour data is used to ascertain the total number of continuous pours on a per bottle basis allowing it to suggest possible drink combinations. At any time, when the inventory program detects a data anomaly falling outside a predetermined set of pour parameters, it will generate an error report. 
         [0010]    In addition to the pour volume data and vessel size data, the software is also programmed with an inventory function. The program stores individualized inventory data and automatically triggers a re-order event when inventory reaches a predetermined level. In various embodiments of the invention, the re-order event may range from a simple warning to contact a particular supplier, or the software may be programmed to automatically contact a supplier electronically and re-order a predetermined quantity of product. 
         [0011]    It is anticipated that the software will interface with and receive sales data from point of purchase machines, including cash registers. Each spout at a particular station, it is anticipated, will be associated with the station&#39;s point of sale device. In the case of mixed drinks, the software program interfaces with the point of sale machine, translating individual pour data into combination pour data and suggesting likely combinations according to a predetermined list of mixed drinks. 
         [0012]    By interfacing with point of sale devices, sensor anomalies generated by the software can be correlated to point of sale anomalies. In this manner, the system can identify instances where an error occurred. For instance, it may identify instances where the wrong key on the point of sale device was input, or instances where the wrong product was served or used to create a mixed drink. The software allows users to see time-based transaction histories of pour and point of sale data so that persons responsible for the error and the time of the error can be easily correlated. If a user wishes to examine a particular transaction history range, the software is capable of displaying the information without affecting real time pour data collection. 
         [0013]    It is anticipated that individual pour spouts will be programmed to activate or reset upon the occurrence of a predetermined activation event. In this manner, when the system is initially set up, and as new inventory is opened, the software program will maintain an accurate record of total inventory, pour data and errors. By manipulating the pre and post-pour data, the software program may generate various reports, including pour to drink correlation, pour to bartender correlation, pour to time correlation, pour to point of sale correlation, and open bottle pour to inventory levels. 
         [0014]    These and other features, aspects, and advantages of the present invention will become better understood with regard to the following description, appended claims, and accompanying drawings where: 
     
    
     
       BRIEF DESCRIPTION OF THE FIGURES 
         [0015]      FIG. 1  is a diagram of a liquid level measuring device according to the present version of the invention. 
           [0016]      FIG. 2  is a perspective view of the pour spout of the liquid level measuring device according to the present version of the invention. 
           [0017]      FIG. 3  shows the main screen of the liquid level measuring software of the present version of the invention. 
           [0018]      FIG. 4  shows the products screen of the liquid level measuring software of the present version of the invention. 
           [0019]      FIG. 5  shows the device programming screen of the liquid level measuring software of the present version of the invention. 
           [0020]      FIG. 6  shows the inventory manager screen of the liquid level measuring software of the present version of the invention. 
           [0021]      FIG. 7  shows the transaction history screen of the liquid level measuring software of the present version of the invention. 
           [0022]      FIG. 8  shows the purchase manager screen of the liquid level measuring software of the present version of the invention. 
           [0023]      FIG. 9  shows the report manager screen of the liquid level measuring software of the present version of the invention. 
           [0024]      FIG. 10  shows the drink matrix screen of the liquid level measuring software of the present version of the invention. 
           [0025]      FIG. 11  shows the variance manager screen of the liquid level measuring software of the present version of the invention. 
           [0026]      FIG. 12  shows the export manager screen of the liquid level measuring software of the present version of the invention. 
           [0027]      FIG. 13  shows the configuration manager screen of the liquid level measuring software of the present version of the invention. 
       
    
    
     DESCRIPTION 
       [0028]    Referring to  FIG. 1 , a liquor pour spout  10 , having a probe sensor  12  for quantifying the liquid level in a liquor bottle, and a transmitter  14  for transmitting liquid level information is inserted into a liquor bottle. The probe sensor  12  measures the liquid level in the bottle and communicates the information to the transmitter  14 . A relay  16  receives the liquid level information from the pour spout, and transmits the data, as well as individually identifying the pour spout from which data was received, to the back office computer  18 . The back office computer  18  extrapolates the data from individual pour spouts and compares it to previously received data to establish a per-pour volume record for each pour spout. 
         [0029]    Referring to  FIG. 2 , the pour spout  10  comprises structures typically associated with conventional pour spouts. A collar  20  for sealing liquids in a bottle, and an air vent  22  allows air to replace liquid as the bottle is emptied. Unlike conventional pour spouts however, the pour spout  10  has a probe sensor  12  and transmitter  14  for sending liquid level information wirelessly away from the spout  10 . 
         [0030]    Preferably, the spout  10  is battery powered and capable of storing data in a memory for a predetermined period of time prior to data transmission, however Radio Frequency Identification (RFID) versions are also anticipated. Associating an RFID with each bottle as it goes into inventory, or as a part of the labeling process, enables real-time inventory control and tracking. 
         [0031]    RFID devices, or “tags,” usually consist of an integrated circuit for storing and processing information and processing transmitted and received radio frequency signals. They may be active, associated with a power source, or passive, stimulated by an external RF signal. By associating a unique RFID with each piece of inventory, the system can continually scan the inventory and detect, in real-time, when an item is removed or missing from inventory storage. At any time, therefore, an owner will know exactly how many bottles are in inventory and what types of bottles they are. By combining the level sensing technology of the present invention with RFID inventory maintenance, the system can automatically update and remove consumed bottles from inventory. 
         [0032]    Since RFID tags are very small, they may be easily imbedded in stickers or labels applied to bottles. By virtue of a unique identifier, such as an Internet Protocol address, users may track individual bottles. Indicia in which RFID tags are embedded may also bear imprinted bar codes allowing users to physically scan indicia into the inventory control system in tandem with automatic activation. Users can also scan a bottle&#39;s original bar code at the same time, thereby providing specific product information (liquor type, brand, etc.) to the system. By correlating product information with RFID tag information, the system can automatically track liquor sales from entry into inventory to consumption. 
         [0033]    Each spout may be assigned a unique Internet Protocol (IP) address. By associating individual spouts with individual IP addresses, the spouts in the system can comprise a network and individual spouts may be monitored by a host computer. In this manner, messages can be sent or received between one or more host computers and the individual spouts. Network messages using IP addresses may be wired or wireless, and since the IP system is standard in the computer industry, the spouts may take advantage of industry infrastructure, including specifications, products and integrated circuits, among others. 
         [0034]    In various contemplated embodiments, it is anticipated that the transmitter  14  has a memory capacity for storing and transmitting data. Additionally, the spout may have a programmable viewing screen for displaying the type of liquor contained in the bottle attached to the spout, including the brand name, or other indicia. In another embodiment, the spout comprises an inversion sensor, such as an accelerometer, to sense bottle inversion. 
         [0035]    The software associated with each spout accepts transmitted spout data and correlates a first set of volume data to a second set of data each time the spout is inverted and the liquid level in the bottle changes. The second set of data corresponds to the size and contents of a vessel, and comprises information of a type chosen from the list of container size, liquor description, product brand, product code and vendor information. 
         [0036]    Using predetermined algorithms, the inventory program uses volume data to calculate and deliver vessel volume change information in real time to the software and thereby to an end user. The inventory program correlates data from the spout to ascertain the total number of continuous multiple pours by virtue of the pour data received from the sensor probe. In this manner, individualized error reports for data anomalies occurring outside a predetermined set of volume-per-pour parameters can be provided. In addition to reporting errors, the inventory program also stores individualized inventory data and causes a re-order event at individual predetermined inventory levels. 
         [0037]    The inventory program receives sales data from a point of sale machine associated with a vessel. By interfacing with a point of sale machine, the software correlates individual pour data to combination pour data, and suggests likely individual pour events based on a predetermined set of data combinations. Anomalies from sensors are correlated to anomalies from points of sale. The inventory program generates time-based transaction histories associated with pour data and point of sale data. users may switch from real-time transaction monitoring to view transaction histories without affecting data collection. 
         [0038]    A spout transmits activation data upon the occurrence of a predetermined activation event. The first set of data and second set of data may be manipulated in individualized data fields to generate reports including correlating pours to drinks, pours to bartenders, pours to time, pours to point of sale transaction, and pours to inventory open bottle level. 
         [0039]    The sensor is preferably a type chosen from the list of float sensor, capacitance sensor and optical sensor. An accelerometer or a micro-electro-mechanical (including piezoelectric/piezoceramic) gyroscope is used to sense horizontal and vertical spout orientation. The inventory program calculates and reports the volume of liquid poured and existing inventory in real time, and the spouts comprise inputs for programming them according to inventory. 
         [0040]    Referring to  FIG. 3 , a start screen for a device user interface is shown. The computer receives transmissions of data from pour spouts and interprets the data into spout-specific volume data according to software algorithms. the inventory program uses liquid volume data to establish for individual bottles a first “pre-pour” volume, a second “post-pour” volume, and using this data calculates a third volume comprising the difference between the pre-pour and post pour volumes. The software then ascribes the information to a particular pour spout and can therefore identify a particular bartender. 
         [0041]    Still referring to  FIG. 3 , specific activities governed by the software can include: product management, device management, inventory management, purchase management, report management, a drink matrix, variance management, import management and a configuration manager. Each of these functions will now be discussed 
         [0042]    Referring to  FIG. 4 , a product management screen is shown and described. The product management function tracks various types of liquor brands. For each liquor type and brand, the software identifies the product code number, product brand, liquor type, bottle sizes stocked by an individual user, and the vendor supplying the product in question. Since the software is preferably pre-loaded with most common liquor types, new products brought into inventory can be easily added to the database. 
         [0043]    Referring to  FIG. 5 , A device manager screen is shown and described. The device manager is used to assign a specific size and type of liquor bottle to an individual pour spout. Preferably, when establishing the system, spouts are individually inverted and assigned unique serial number identifiers. With a serial number assigned, a user selects the liquor type and container size. A status field indicates whether or not a spout is active, and displays the date and time of activation. A “venue” field allows users to indicate the specific area in which a spout is used, such as a restaurant bar, lounge or other area, and each entry comprises a status bar field to indicate when a pour has resulted in an error. 
         [0044]    Referring to  FIG. 6 , the inventory manager screen is shown and described. Since pour spouts are capable of establishing and maintaining a liquor level record for individual bottles, and are also capable of detecting pour errors, the system can be used as an inventory manager capable of maintaining liquor inventories in real time. The inventory manager screen shows products according to their code number, liquor type, vendor and size. In addition, open stock levels, backstock inventories, overhead cost, products on order and order cost are calculated. 
         [0045]    The inventory manager allows users to perform a one-time inventory count for sealed back stock. Once the back stock information is combined with the open stock measurements from the pour spouts, inventory is constantly monitored to the 10 th  of an ounce per product. As new products arrive, they can be scanned for automatic updating. The ability to track backordered inventory also allows users to project costs based on inventory data. 
         [0046]    Referring to  FIG. 7 , a “live view” screen can be generated for all recent pours on the inventory manager page. Live views are provided for all bar locations, and selecting a pour log will display each bottle&#39;s historical pour path from full to empty. Also included in the live view screen is a feature that displays every brands&#39; purchase and lifespan history, wherein each bottle can be recalled at any time to review its pour path and associated data. 
         [0047]    Referring to  FIG. 8 , a purchase manager screen is shown and described. The purchase manager uses inventory data from the inventory manager to anticipate when re-orders will be necessary and enables users to set up automatic orders for types of liquor. Like the other screens, the purchase manager displays vendor, liquor type, brand and product code information. Additional fields are included for displaying open stock and bottles in inventory, and an auto-order function. The auto-order function causes the device to automatically send an order for additional product when inventory reaches a predetermined level. The screen displays the number of bottles on auto-order, the cost and an auto-order override button. Additional fields include quantities of product received as they are manually scanned in, and a total cost display for each liquor type. 
         [0048]    Referring to  FIG. 9 , a report manager screen is shown and described. The report manager takes advantage of the pour calculations of the system to provide real time information regarding pour errors. Pour errors may be an over pour, missing inventory, an export error, or a variance error. The report manager is designed to work similar to anti-virus software in that it monitors data in real time to generate an error report immediately upon receiving erroneous data. In addition, an error level field is provided to establish the severity of an error. For instance a minor over pour might be assigned a low or medium level of severity, while a missing inventory error would be assigned a high level of severity. 
         [0049]    In addition to the error reports, traditional reports are generated from the report manager, including sales reports, inventory reports, employee reports, financial reports, vendor reports, purchase reports, export reports, import reports, error reports, memorized reports, and custom reports. Reports may be filtered according to their fields. 
         [0050]    Referring to  FIG. 10 , a drink matrix screen is shown and described. The drink matrix allows multiple ingredients to be easily programmed into a single mixed drink product that can be identified through the variance manager and import manager. The software comes pre-loaded with common mixed drinks identified and additional combinations can be easily added by users as they arise. The drink matrix displays the drink name, its primary, secondary, tertiary and quaternary ingredients and the necessary volumes for each. 
         [0051]    Referring to  FIG. 11 , a variance manager screen is shown and described. In addition to its own internal calculations, it is anticipated that the software will also integrate with point of sale machinery in order to match cash register input with spout data. The variance manager exploits this feature by analyzing drinks poured compared to drinks processed in a point of sale (POS) system. The POS data imported into the software confirms pours. Referring to the sample data, four individual shots of liquor are recorded with the date and time of the pour and ounces poured. For each of these first four transactions, the data can be matched to a POS drink sale by correlating the liquor type, date and time of sale. The fifth sixth and seventh pours are recorded by the system from pour spout information, and the system correlates these pours to coincide with a drink comprising three pours of the type recorded by the system. Since the mixed drink, in this case a Cosmopolitan, comprises vodka, Gran Marnier and cranberry, the system correlates the mixed drink to the pours based on the similarity of ingredients and optionally the time of the pours versus time of sale. The eighth pour, recorded by the pour spouts has no corresponding POS data. Therefore the system perceives this as an error and reports it with an indicator to the user. By using the variance manager, the system avoids generating errors from drinks using multiple liquors or mixers. 
         [0052]    Referring to  FIG. 12 , an export manager screen is shown and described. The export manager is works similar to the variance manager in that it interfaces with a third party POS system. The export manager is the screen used by bartenders or other employees when entering drinks into the POS system. In the system, each pour is first selected by staff and added to an open ticket. If any pours remain at the end of the evening, then it will become apparent staff made an error. In the sample data, several unreported pours are noted, and based on the timing of the pour and ingredients, potential mixed drinks are suggested. 
         [0053]    Referring to  FIG. 13 , a configuration manager incorporated into the software allows users to customize the software for specific installations. Location information including country and measurement units allow the system to be installed in a variety of locations, communications protocol information including port, TCP configuration, data and export file locations are also included. Departments and categories are included to permit or exclude data sharing, and spout and software versions report the spout model and software revision used by the system. Fields are also included for notes specific to a particular user. 
         [0054]    Although the present invention has been described in considerable detail with reference to certain preferred versions thereof, other versions are possible. For example, liquid level data may be obtained by a device other than the probe disclosed herein, and the software may operate on a system lacking a central computer. Therefore the spirit and scope of the appended claims should not be limited to the description of the preferred versions contained herein. 
         [0055]    The reader&#39;s attention is directed to all papers and documents which are filed concurrently with this specification and which are open to public inspection with this specification, and the contents of all such papers and documents are incorporated herein by reference. All features disclosed in this specification (including any accompanying claims, abstract, and drawings) may be replaced by alternative features serving the same, equivalent or similar purpose, unless expressly stated otherwise. Thus, unless expressly stated otherwise, each feature disclosed is one example only of a generic series of equivalent or similar features. 
         [0056]    Any element in a claim that does not explicitly state “means for” performing a specified function, or “step for” performing a specific function, is not to be interpreted as a “means” or “step” clause as specified in 35 U.S.C. §112, ¶6. In particular, the use of “step of” in the claims herein is not intended to invoke the provisions of 35 U.S.C. §112, ¶  6 .