Patent Description:
In the dispensing of liquids, particularly alcoholic beverages, it is customary to use pouring spouts mounted on the tops of bottles to facilitate the dispensing with minimum spillage. In general, these pouring spouts are free-flow pouring devices (i.e., the liquid continues to flow from the bottle so long as the bottle remains tilted. Customarily, the liquid is dispensed into a measuring vessel of fixed volume, as for example: ½ oz, <NUM>/<NUM> oz, <NUM> oz, <NUM>½ oz, (1oz = <NUM>) etc. and, when the desired volume is reached in the measuring vessel, the bottle is tilted to its upright non pouring position. The contents of the measuring vessel, typically, is then emptied into a serving glass thereafter, or the like.

This procedure of pouring the liquid from the bottle to a measuring container and thence to the glass or other vessel (in which the beverage is to be served or mixed) is sometimes a tedious and time consuming process - especially in the case where many beverages are to be dispensed in a short period of time. Consequently, in the press of business, a bartender may resort to sight measuring the amount of beverage directly into the glass or mixing container, thereby eliminating the intermediate step of pouring the beverage first into a measuring container. Because of variations in the size and shape of glasses and mixing containers, the amount and size of ice cubes and the like which may be present in the container, and other factors, sight-measuring is at best a haphazard measuring procedure.

To preserve the speed of pouring by sight-measure, many pouring devices have been made which themselves combine the pouring function and the measuring function so that as the pouring operation proceeds, a fixed volume of liquid will be dispensed with each pouring operation.

<CIT> discloses a system for controlling an amount of liquid poured from a liquid container including a spout configured for attachment to an opening of a liquid container and for controlling a desired amount of liquid poured from the liquid container. The spout is further configured to emit signals containing activity information. A receiver is configured to receive the signals, and a computer is coupled to the receiver, for processing the signals into text for viewing. <CIT> discloses a liquid pour metering device comprising a body defining a liquid passageway having an inlet at one end and an outlet at the other end, the liquid passageway having a mechanical portion controller therein comprising a ball bearing moveable along at least portion of the length of the liquid passageway. There is provided a motion sensor to detect when a pour operation has commenced and a ball bearing sensor operable to detect the end of the pour operation. There is further provided a timer and a transmitter for transmitting data relating to the length of time required to perform the pour operation.

However, in order to properly calculate the amount of alcohol served, compared to the amount of alcohol sales generated, an inventory must be performed, manually, and sometimes by eyesight estimation, of the approximate volume in the bottle.

Different bottles have different shapes and sizes. This drawback, along with the typically large number of bottles, presents a tedious and often inaccurate inventory that ultimately provides inexact figures for alcohol sales.

There remains a need for improved methods and devices for tracking the amount of liquid being poured from a pour spout.

According to the present invention, there is provided an inventory tracking device according to claim <NUM>.

Embodiments of the present disclosure may solve many of the problems in conventional beverage consumption and inventory tracking by providing an adjustable, controlled volume liquid pouring device (herein referred to as the "device"). A device consistent with embodiments of the present disclosure is provided to track how much liquid is dispensed through the device. Although the various embodiments herein are disclosed with the context of "liquids," one of ordinary skill in the field of the present disclosure may adapt the embodiments for any fluid type.

The device may comprise, but not be limited to, a measured pour spout which may be configured to a top portion of a bottle. For example, in some embodiments, a portion of the device may be inserted into the bottle opening. In this way, the device is configured such that the liquid passes through the device as the liquid is poured out of the bottle.

The liquid passing through the device is tracked by a sensor configured within the device. The sensor comprises a sensor stick comprises a circuitry and may comprise at least one magnetic field sensor. The sensor may be operable with a magnetic ball bearing affecting the reading by the at least one magnetic field sensor. As the bottle, and, in turn, the device is titled, the ball bearing may displace within the device. The flux in magnetic field, as a result from the displacement, may be read by the sensor. Such interaction between the ball bearing and the sensor, may, in turn, serve as an indication as to the passing liquid from the bottle, through the device.

Still consistent with embodiments of the present disclosure, the device may be configured to collect data from the sensor readings. The data may be received by computing device operatively associated with the device. In some embodiments, a local computing device (e.g., embedded microprocessor) may be integrated within the device circuitry. Still, in other embodiments, a remote computing device (e.g., a hub) may be in remote communication with the device, via, for example, a communications module embedded within the device (e.g., Bluetooth protocol compatible).

Still consistent with embodiments of the present disclosure, the device may comprise a calibrated chamber which may be configured to limit the flow of liquid to a specific amount each time the bottle is positioned to dispense the liquid through the device. In some embodiments, the chamber may be adjusted to a desired volumetric flow rate of liquid. The adjustment of the chamber may be performed mechanically, through various components configured to affect the flow rate of liquid through the device. In some embodiments, a plurality of devices may come with a specific chamber caliber pre-set, with an interchangeable cap for each pour amount. In turn, the specification of chamber calibration may be accounted for by a computing device associated with the device. In this way, based on the particular calibration of the device chamber, the sensor data may be analyzed to ascertain an amount of liquid poured through the device.

In yet further embodiments, a remote computing device (referred to herein as a "hub") may receive data from a plurality of devices. The hub, may, in turn, aggregate, store, communicate, analyze, or otherwise operate on the devices and its corresponding received data. In some embodiments, the hub may reside in local proximity to the devices, so as to communicate with the devices in a near-field communication protocol. While in additional embodiments, the hub may be further embodied as, for example, an allocated resource in a cloud computing environment.

Still, in some embodiments, a local computing device in near-field communication with a plurality of devices may receive device data and communicate the data to the hub. The local computing device may then receive data back from the hub. In this way, a centralized operator may control and/or monitor a plurality of devices located in a plurality of locations. Accordingly, the hub may, by way of non-limiting example, calculate an amount of liquid left in each bottle (knowing the specification of each container) by summing the total amount poured by each device, and return corresponding data or instructions back to a local computing device in operative communication with the plurality of devices.

Further still, in some embodiments, a user interface may be provided for consuming and/or acting upon the data. The interface may be provided through, for example, but not limited, a web application or a mobile device application. In some embodiments, the hub may be in further communication with third party infrastructure, such as, but not limited to, for example, cloud computing, inventory management, distribution systems, and marketing and sales platforms. In this way, conventional systems and methods for managing liquor inventory and sales may be improved upon with the methods, systems, and devices of the present disclosure.

Both the foregoing brief overview and the following detailed description provide examples and are explanatory only. Accordingly, the foregoing brief overview and the following detailed description should not be considered to be restrictive. Further, features or variations may be provided in addition to those set forth herein. For example, embodiments may be directed to various feature combinations and sub-combinations described in the detailed description.

The drawings contain representations of various trademarks and copyrights owned by the Applicants. In addition, the drawings may contain other marks owned by third parties and are being used for illustrative purposes only. All rights to various trademarks and copyrights represented herein, except those belonging to their respective owners, are vested in and the property of the Applicants. The Applicants retain and reserve all rights in their trademarks and copyrights included herein, and grant permission to reproduce the material only in connection with reproduction of the granted patent and for no other purpose.

Furthermore, the drawings may contain text or captions that may explain certain embodiments of the present disclosure. This text is included for illustrative, non-limiting, explanatory purposes of certain embodiments detailed in the present disclosure. In the drawings:.

Any sequence(s) and/or temporal order of steps of various processes or methods that are described herein are illustrative and not restrictive. Accordingly, it should be understood that, although steps of various processes or methods may be shown and described as being in a sequence or temporal order, the steps of any such processes or methods are not limited to being carried out in any particular sequence or order, absent an indication otherwise. Indeed, the steps in such processes or methods generally may be carried out in various different sequences and orders while still falling within the scope of the present invention.

Additionally, it is important to note that each term used herein refers to that which an ordinary artisan would understand such term to mean based on the contextual use of such term herein. To the extent that the meaning of a term used herein- as understood by the ordinary artisan based on the contextual use of such term- differs in any way from any particular dictionary definition of such term, it is intended that the meaning of the term as understood by the ordinary artisan should prevail.

Furthermore, it is important to note that, as used herein, "a" and "an" each generally denotes "at least one," but does not exclude a plurality unless the contextual use dictates otherwise. When used herein to join a list of items, "or" denotes "at least one of the items," but does not exclude a plurality of items of the list. Finally, when used herein to join a list of items, "and" denotes "all of the items of the list.

The following detailed description refers to the accompanying drawings. Wherever possible, the same reference numbers are used in the drawings and the following description to refer to the same or similar elements. While many embodiments of the disclosure may be described, modifications, adaptations, and other implementations are possible. For example, substitutions, additions, or modifications may be made to the elements illustrated in the drawings, and the methods described herein may be modified by substituting, reordering, or adding stages to the disclosed methods. Accordingly, the following detailed description does not limit the disclosure. Instead, the proper scope of the disclosure is defined by the appended claims. The present disclosure contains headers. It should be understood that these headers are used as references and are not to be construed as limiting upon the subjected matter disclosed under the header.

The present disclosure includes many aspects and features. Moreover, while many aspects and features relate to, and are described in, the context of beverage dispensing from a bottle, embodiments of the present disclosure are not limited to use only in this context. For example, any fluid or liquid dispensing applications may be anticipated to be within the scope of the present disclosure.

This brief overview is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This brief overview is not intended to identify key features or essential features of the claimed subject matter. Nor is this brief overview intended to be used to limit the claimed subject matter's scope.

Methods, systems, and devices disclosed herein may be collectively referred to as a "platform. " A platform consistent with embodiments herein may be used by individuals or companies to track an amount of liquid poured from at least one liquid container. The platform may comprise a tracking device and a computing hub in operative bi-directional communication.

The device may be configured to a liquid dispensing container such as, but not limited to, a bottle. The device may be configured to receive a liquid from the container and transfer the liquid through a chamber within the device. As the liquid is transferred through the device, a computing element and sensing component integrated within the device may be configured to track an amount of liquid dispensed through the device. A communications module may then communicate the data with the hub.

Still consistent with embodiments of the present disclosure, the device may be configured to limit an amount of liquid dispensed through the device by way of a calibrated chamber which dispenses a specific amount each time the bottle inverts. In turn, the device may be configured to sense an amount of liquid poured through the device. The device may then communicate the sensor data to a computing element, either integrated within the device itself, and/or to a network computing element.

The computing element, having received the data from the device, may then calculate, for example, at least one of the following: an amount of liquid dispensed and an amount of liquid remaining in the bottle to which the device is attached. Accordingly, the device may be paired or registered with the platform, along with a specification of a liquid container type that the device is configured to. In this way, the platform may be configured to report a plurality of metrics associated with a plurality of liquid containers having a device consistent with embodiments of the present disclosure configured thereto.

Both the foregoing overview and the following detailed description provide examples and are explanatory only. Accordingly, the foregoing overview and the following detailed description should not be considered to be restrictive. Further, features or variations may be provided in addition to those set forth herein. For example, embodiments may be directed to various feature combinations and sub-combinations described in the detailed description.

A device consistent with embodiments of the present disclosure may be, for example, a liquid pouring spout (referred to as a "device" throughout the present disclosure) that connects to a liquid container. In some embodiments, as with conventional liquid pouring spouts, the device may comprise an adjustably controllable measuring liquid pourer for dispensing liquid in a predetermined quantity.

<FIG> illustrates one possible embodiment of the liquid pouring spout <NUM>, in three configurations. In a first configuration <NUM>, spout <NUM> may be in an upright position, ready to receive liquid. In a second configuration <NUM>, spout <NUM> may be receiving liquid through the chamber. In a third configuration <NUM>, spout <NUM> may have completed the dispensing of liquid. The following disclosure will describe spout <NUM>, as a device <NUM>, through the various configurations.

Consistent with embodiments of the present disclosure, device <NUM> may comprise a calibrated chamber <NUM> which may be configured to limit the flow of liquid to a specific amount each time the bottle is positioned to dispense the liquid through the device. In some embodiments, chamber <NUM> may be adjusted to a desired volumetric flow rate of liquid. The adjustment of chamber <NUM> may be performed mechanically, through various components configured to affect the flow rate of liquid through the device. In some embodiments, a plurality of devices may come with a specific chamber caliber pre-set, with an interchangeable cap <NUM> for each pour amount.

Still, in further embodiments, it is anticipated that, for example, a computer-controlled actuator may be configured to dynamically and programmatically adjust a property of device <NUM> (e.g., an opening <NUM> of cap <NUM>) so as to affect the flow rate through device <NUM>. In this way, for example, a remote operator of the device may be enabled, via a computing device and communications module, to control the limits of liquid flow through device <NUM>. In turn, the specification of chamber calibration may be accounted for by a computing device associated with device <NUM>. In this way, based on the particular calibration of the device <NUM> (e.g., by way of chamber <NUM> or cap <NUM>), the sensor data may be analyzed to ascertain an amount of liquid poured through the device.

Referring still to <FIG>, chamber <NUM> within upright configuration <NUM> may comprise a ball bearing <NUM> resting at the base of camber <NUM>, adjacent to cap <NUM>. Cap <NUM> may comprise a cut-out <NUM> for receiving a liquid into chamber <NUM> from a liquid container to which device <NUM> may be configured. In some embodiments, cap <NUM> may be configured so as to be inserted into a liquid container opening (e.g., at the top of a bottle) and receive the liquid from the container. In such embodiments, and as illustrated with reference to <FIG>, a stopping and sealing means <NUM> may be provided to ensure a secure connection to a liquid container. The stopping and sealing means <NUM> may comprise, but not be limited to, for example, a silicon, rubber, elastomeric, silicone, polyurethane, plastic, or cork material. Still, within upright configuration <NUM>, ball bearing <NUM> may rest at the base of the chamber, thereby sealing the liquid within the container connected to device <NUM>.

Referring back to <FIG>, pouring configuration <NUM>, liquid may enter device <NUM> through opening <NUM>, filling chamber <NUM>. A vacuum effect may be created with opening <NUM>, thereby causing ball bearing <NUM> to float on the liquid through chamber <NUM>, as facilitated by an air vent cut-out <NUM> positioned within chamber <NUM>. To understand the operation of device <NUM> during pouring configuration <NUM>, we turn to <FIG>.

Still consistent with embodiments of the present disclosure, and as illustrated in <FIG>, a hollow space (herein known as a "channel for sensor") may be designed alongside chamber <NUM>, spanning the length of chamber <NUM>. The channels purpose may be, but is not limited to, to create a space for the sensor stick to be placed secure and flush alongside the ball chamber <NUM>.

A magnetic sensing device comprising a magnetic sensor circuitry (hereinafter referred to as a "sensor stick") may be placed inside the channel for sensor. <FIG> illustrates one example embodiment of sensing device <NUM>, and <FIG> illustrates how sensing device <NUM> may be inserted into the channel. Sensing device <NUM> may comprise two primary components: a circuit board of a predetermined width having at least one processor <NUM> thereon, the length of the circuit board being at least the span of the ball chamber <NUM>; and a plurality of sensors U1, U2, U3, and U4. The sensing device <NUM> may also include a physical connector or interface <NUM>, configured to communicate with an external processor (not illustrated) or other device. It is noted that processor <NUM> may be physically present on the sensing device <NUM>, or may be a separate device (not illustrated). The circuit board may be a printed circuit board and may include printed circuitry and may be sized to be retained within the channel for sensor. There may be no limitation to a quantity of sensors used. In some embodiments, the quantity may range from one to four sensors, mounted on the circuit board and orientated, by way of non-limiting example, equidistant from each other (See <FIG>, sensors U1-U4).

Consistent with embodiments of the present disclosure, ball bearing <NUM> may have magnetic properties so as to interface with sensing device <NUM>. The magnetic field sensors on the sensing device <NUM> may be used to determine the magnetic ball bearing's location. I some embodiments, sensing device <NUM> may determine the magnetic ball bearing's location using, for example, without limitation, the hall effect. The hall effect is the production of a voltage difference across an electrical conductor, transverse to an electric current in the conductor and to an applied magnetic field perpendicular to the current. By tracking location of ball bearing <NUM> as a function of the pour spout's position, the amount of liquid released may be tracked by a computing device in accordance to embodiments disclosed herein. Tracking may comprise, but not be limited to, for example, calculating the displacement of ball bearing <NUM> within chamber <NUM>.

In some embodiments, the sensors may be coupled with additional components, use alternative measurements (e.g., magnetic flux, electrical flux, or EM flux) to ascertain the ball bearing's location. For example, optomechanical systems and corresponding sensors may be used in conjunction with, or ingratiated with, the sensing device <NUM>. In further embodiments, a magnetically operated mechanical switch may be used in conjunction with, or ingratiated with, the sensing device <NUM>. In yet further embodiments, MEMS magnetic field sensors using Lorentz force may be used in conjunction with, or ingratiated with, the sensing device <NUM>. Furthermore, although particularly described as using a magnetic field sensor or other sensor in the several preceding examples herein, capacitance sensing, limit-switch sensing, physical displacement sensing, and any other suitable form of sensing is also applicable. Accordingly, it should be understood by one of ordinary skill in the field of the present disclosure that a plurality of systems may be adapted to be in conjunction with, or integrated with, sensing device <NUM> to achieve the desired results.

Referring now to <FIG>, device <NUM> may comprise a cover <NUM> corresponding to the area and shape of the main pour spout and air vent <NUM>, so as to fit flush with the main pour spout and prevent moisture from entering through cover <NUM>. The material of cover <NUM> may be made from, but not limited to metal, plastic, or wood. Cover <NUM> may be used, but not limited to, for example, insulate the channel for sensor from outside elements such as, but not limited to, liquid, dirt, and grime.

Accordingly, referring back to <FIG>, device <NUM> may allow measured liquid pours specified by a user to be administered from a bottle in discrete portions. Device <NUM> may be attached to the opening of a bottle containing liquid. The starting orientation, in the initial configuration <NUM>, may be such that a base of a liquid container (e.g., the bottle) is level with the ground, with the pour spout facing upwards, perpendicular with the ground, and ball bearing <NUM> is at the bottom of chamber <NUM>.

Turing towards configuration <NUM>, device <NUM> may then invert (i.e., Rotated <NUM>° - <NUM>° from original orientation) such that ball bearing <NUM> begins travel down the path of the ball chamber <NUM>. The liquid in ball chamber <NUM> may then be expelled by the force of gravity, and force ball bearing <NUM> down the chamber <NUM>. The displacement of ball bearing <NUM> is detected by sensing device <NUM> and is used, in turn, to track an amount of liquid dispensed during the pour.

Now in configuration <NUM>, ball bearing <NUM> may cease travel when it reaches "top" of the ball chamber <NUM>, as ball bearing <NUM> may be configured to seal a pouring hole in device <NUM>. In some embodiments, ball bearing <NUM> may also cover, at least in part, air-vent <NUM>, further affecting the liquid flow rate. In scenarios of a partial pour, ball bearing <NUM> may not be completely forced to the "top" of chamber <NUM> (e.g., device <NUM> is not inverted long enough for ball bearing <NUM> to travel the length of chamber <NUM> is then reverted to its initial configuration <NUM>. Nevertheless, sensing device <NUM> may still measure the total displacement of ball bearing <NUM> within chamber <NUM>.

In some embodiments, the measured distance may be exported to a computing device (e.g., a hub). Having each pour spout assigned to a particular spirit, the measured distance may serve as input to an algorithm configured to calculate an amount of liquid dispensed from the bottle to which device <NUM> is affixed.

As described above, the device <NUM> may include a variety of features and mechanics configured to assist in tracking inventory. For example, with reference to <FIG>, the device may include a bottom cap <NUM>. The bottom cap <NUM> includes a first opening <NUM> to receive a liquid from a bottle and a second opening to measurably release the received liquid into ball chamber <NUM>. Generally, increasing the size of the first opening <NUM> of the bottom cap <NUM> decreases the predetermined amount of the liquid. Similarly, decreasing the size of the first opening <NUM> of the bottom cap <NUM> increases the predetermined amount of liquid.

The ball chamber <NUM> is arranged on the bottom cap <NUM>. The ball chamber <NUM> includes a bottom opening in fluid communication with the second opening of the bottom cap <NUM>. The ball chamber <NUM> includes a cylindrical cavity arranged to retain the ball bearing and the predetermined amount of liquid. The cylindrical cavity is also in fluid communication with the bottom opening. Finally, the ball chamber <NUM> also includes a top opening in fluid communication with the cylindrical cavity so that liquid can be poured through to main pour spout <NUM>.

Air vent <NUM> is arranged proximate the ball chamber <NUM>. Air vent <NUM> is configured to receive air from an exterior of a liquid dispensing container and direct the received air to the interior of the liquid dispensing container.

The sensor cavity <NUM> is arranged proximate the ball chamber <NUM>. The sensor cavity <NUM> is also termed a "channel for sensor" herein, and is an elongated channel configured to retain at least one sensor. Generally, the at least one sensor can be actuated by the ball bearing as described herein. Additionally, the sensor cavity <NUM> is sealed to prevent the liquid from entering the sensor cavity <NUM> and fouling the at least one sensor.

The device <NUM> may also include a top <NUM> configured to seat onto or about a neck or top opening of a liquid dispensing container, such as a liquor or wine bottle. The top <NUM> may be covered by cover <NUM>. Additional electronics, including any necessary antennas, transceivers, or other electronics may be housed beneath the cover <NUM>. Additionally, the device <NUM> can include a sealing member or sealing ring <NUM> arranged about the ball chamber, configured to seal and/or seat within the bottle neck beneath the top <NUM>.

Hereinafter, operation of individual inventory tracking devices <NUM> is presented with reference to <FIG> and <FIG>.

<FIG> and <FIG> illustrate possible operating environments through which a platform consistent with embodiments of the present disclosure may be provided. By way of non-limiting example, the platform may be hosted on a centralized server, such as, for example, a hub or a cloud computing service. A user may access the platform through a software application. The software application may be embodied as, for example, but not be limited to, a website, a web application, a desktop application, and a mobile application compatible with a computing device <FIG>. One possible embodiment of the software application may be provided by the BarMinder™ suite of products and services provided by BarMinder, LLC.

As will be detailed with reference to <FIG> below, the computing device through which the platform may be accessed may comprise, but not be limited to, for example, an integrated circuit, a desktop computer, a laptop, a tablet, mobile telecommunications device, or an Internet of Things (IOT) device.

A platform for tracking beverage consumption and inventory may be configured to operate as disclosed herein. Although the stages of operation depicted herein are disclosed in a particular order, it should be understood that the order is disclosed for illustrative purposes only. Stages may be combined, separated, reordered, and various intermediary stages may exist. Accordingly, it should be understood that the various stages may be, in various embodiments, performed in arrangements that differ from the ones illustrated. Moreover, various stages may be added or removed without altering or deterring from the fundamental scope of the depicted methods and systems disclosed herein.

Consistent with embodiments of the present disclosure, sensing device <NUM> may be operatively associated with a communications module (e.g., integrated near-field communications technology) to send data wirelessly to a hub. The communications module may be a part of, or separate from, the at least one processor <NUM>. As mentioned above, a hub may be, for example, an on-premises computing device in local proximity to device <NUM>. Each data stream may be associated with a particular device configured to a particular bottle, each programmatically registered with the platform. In this way, the platform may ascertain which device is attached to which bottle. The data streams communicated to the hub associated with a particular device may be assigned a "pour number" uniquely for the particular device. The data stream may comprise, for example, but not be limited to, a volume of any particular pour (<NUM>/<NUM> oz, 1oz, <NUM>. 5oz etc., wherein 1oz = <NUM>,<NUM>), and total volume poured since placed on new bottle, battery voltage, and other metrics on functionality of device (e.g., recently placed on new bottle, etc.).

Still consistent with embodiments of the present disclosure, the hub may send data back to device <NUM> (e.g., software updates). Such bi-directional communication may be facilitated by a communications module configured to communicate directly over a local network with, for example, a software application associated with the platform. In addition, the hub may be configured to communicate with other computing devices in a networked environment. One such computing device may be within a cloud computing environment, connected through a telecommunications channel. The cloud computing device may be configured to track a plurality of devices within a plurality of locations, and enable remote computing devices (e.g., a mobile phone) to connect thereto. In some embodiments, data collected on the cloud computing environment may be used and sold to companies such as, but not limited to, advertising agencies, liquor manufacturers, marketing teams, and due diligence practitioners.

The mobile app and web client may enable the user to interact with the data collected. The app may communicate through the internet to the cloud servers, and directly to the Hub. This facilitates easier setup and management if Internet connectivity isn't available. The mobile app may have the following data aggregated: relevant data generated by the system, inventory levels, predictions of when inventory orders need to be placed, automatic adding of needed inventory to a cart for simple ordering or the ability to enable automatic ordering at set thresholds, access to a marketplace to order new inventory, allows manual reconciliation with physical counts during auditing to bring system's count of inventory in line.

In yet further embodiments, and as illustrated in <FIG>, a "marketplace" may provide a centralized network for communication between buyers of spirits, liquor distributors, and data clients. The marketplace may facilitate a streamlined sales process for distributors to advertise, solicit, and sell their spirits to prospective buyers. When an order of spirits is needed, they may be requested or publicly posted in the marketplace, and distributors may compete to bid and fill orders. Distributors traditionally employ large salesforces to sell through their products. The marketplace reduces the work required to place and fulfill orders and may increase distributors' margins. The marketplace may charge the distributor a set percentage fee on each order. Distributors may manage actual delivery of inventory to the physical location of the bar.

An exemplary process as shown in <FIG> may follow the following procedure. Although the stages of operation depicted herein are disclosed in a particular order, it should be understood that the order is disclosed for illustrative purposes only. Stages may be combined, separated, reordered, and various intermediary stages may exist. Accordingly, it should be understood that the various stages may be, in various embodiments, performed in arrangements that differ from the ones illustrated. Moreover, various stages may be added or removed without altering or deterring from the fundamental scope of the depicted methods and systems disclosed herein.

First, a plurality of devices consistent with embodiments disclosed herein may collect information from their respective bottles. Each device's data may be sent to, for example, the hub, which calculates and logs liquid container inventory. The logged inventory may be viewed from a computing device connected to the hub. Then, data from the hub is sent to, for example, a centralized server. Based on the information on the server, orders may be placed on the marketplace, or that information may be sold to third parties. As orders are placed and fulfilled in the marketplace, distributors may coordinate the shipping and distribution of the ordered products. Hereinafter, a more detailed discussion of operation of the platforms described herein is provided with reference to <FIG>.

<FIG> is a flowchart of a method <NUM> of automated inventory control of dispensed liquids, in accordance with various embodiments of the present disclosure. The method <NUM> may include registering and/or associating a device with a particular liquid dispensing container and a hub, at block <NUM>. Generally, registering includes assigning associated identifying data to an inventory tracking device, where the identifying data identifies a particular type of liquid dispensing container associated with the inventory tracking device.

The method <NUM> may further include receiving individual inventory data related to dispensing containers from the registered devices, at block <NUM>. For example, individual inventory tracking devices <NUM> can transmit volumetric data of the liquid dispensing container to the hub.

The method <NUM> may further include assembling inventory data for the devices and associated dispensing containers responsive to the receiving, at block <NUM>. The assembling can include aggregating data for every bottle for a customer that has an active inventory tracking device <NUM>.

The method <NUM> may further includes transmitting the assembled inventory data to a centralized server or cloud server, at block <NUM>. For example, the centralized cloud server is described with reference to <FIG> and <FIG>, above. In addition to the assembled inventory data, or in the alternative, the hub may transmit one or more purchase orders to the centralized server. For example, the one or more purchase orders may include inventory data or other suitable data to ensure an order is validly placed from the hub.

Thereafter, the method <NUM> may include determining a need to collect data from the registered devices, at block <NUM>, and determining if a new device is present, if an unregistered device is within range, or if a software update is available, at block <NUM>. Generally, the need to collect data may be based on a flow of business, a total number of pours from a device or other indicators of diminishing inventory. The need may also be based on a predetermined schedule, regular schedule, or other schedule. Software update availability may be manually pushed onto the hub or may be based on a predetermined schedule to check for updates.

If there is a need to collect data, the method <NUM> resumes at block <NUM>. If there is a software update available, the method <NUM> includes pushing the software and/or firmware update to the registered device, at block <NUM>. The method <NUM> may subsequently continue with block <NUM> or <NUM>, depending upon any desired implementation of the methodology.

As described above, the method <NUM> includes operations configured to be performed by a hub or localized processor, and individual devices. Hereafter, method <NUM> is described as related to operations configured to be performed through a centralized server or cloud-based architecture.

<FIG> is a flowchart of the method <NUM> of automated inventory control of dispensed liquids. The method <NUM> includes requesting inventory data from a customer computing device, at block <NUM>. The inventory data may be received from a hub over a network. The inventory data may be received regularly, on a regular schedule, or may be received according to a different schedule. The inventory data may also be received based on a demand. The demand may be a demand for additional product. The demand may be based on an amount of liquid poured / served, an amount of sales, activity at a customer location, or other attributes. This network may be separate or different from the network used by the hub to communicate with the individual device <NUM>.

The method <NUM> further includes receiving the requested inventory data from the customer computing device, at block <NUM>. The inventory data may be received over the network. The inventory data may include volumetric data, sales data, and/or other suitable data.

The method <NUM> also includes determining if inventory levels indicate a need for additional product, at block <NUM>. For example, the need may be based on sales volume or other attributes, including predicted holidays or large sales events. Other attributes for need can be adjusted based on any desired implementation.

The method <NUM> also includes assembling one or more purchase orders based on the determining the need for additional product, at block <NUM>. The method <NUM> also includes transmitting the one or more orders to distributors based on product data, at block <NUM>. The distributors may be sent purchase orders based on inventory at the distributor or availability data for products. Thus, the method <NUM> may also include choosing a distributor based on an attribute, such as availability of a food product or spirit.

It is noted that both the hub and centralized server may be quipped to issue purchase orders. For example, according to one aspect, the hub may issue purchase orders on behalf of a customer. According to an additional aspect, the centralized server may issue purchase orders on behalf of a customer.

The method <NUM> also includes determining that a customer associated with the one or more orders has opted-in to receive marketing promotions or otherwise authorized release of purchase order or inventory data, at block <NUM>. If the customer has opted-in or otherwise agreed, the method <NUM> can include transmitting a summary of the inventory data and/or the one or more purchase orders to a third party, at block <NUM>.

As described above, various methodologies associated with automated inventory control of dispensed liquids has been provided herein. The methodologies may be associated with any dispensed liquid, such as food products, liquors, wines, or other consumable liquids. In other implementations, the methodologies may be associated with a dispensed liquid such as motor oil, washing fluid, or other liquids associated with automotive maintenance. In other implementations, the methodologies may be associated with a dispensed liquid such as a hair product, nail polish, cream or lotion, or other liquids associated with a beauty salon. In still further implementations, the methodologies may be associated with any liquid to be dispensed that is measurable in volume through sensing displacement, as described herein.

Portions of the invention may be embodied as, for example, but not be limited to, a website, a web application, a desktop application, backend application, and a mobile application compatible with a computing device <NUM>. Any portion of the disclosed systems may include a computing device <NUM>, including the sensor stick <NUM>, hub, cloud server, centralized server, or any other portion of the invention. The computing device <NUM> may comprise, but not be limited to the following:.

Embodiments herein may be hosted on a centralized server or a cloud computing service. Although methods <NUM> and <NUM> have been described to be performed by a computing device <NUM>, it should be understood that, in some embodiments, different operations may be performed by a plurality of the computing devices <NUM> in operative communication at least one network.

Embodiments of the present disclosure may comprise a system having a central processing unit (CPU) <NUM>, a bus <NUM>, a memory unit <NUM>, a power supply unit (PSU) <NUM>, and one or more Input / Output (I/O) units. The CPU <NUM> coupled to the memory unit <NUM> and the plurality of I/O units <NUM> via the bus <NUM>, all of which are powered by the PSU <NUM>. It should be understood that, in some embodiments, each disclosed unit may actually be a plurality of such units for the purposes of redundancy, high availability, and/or performance. The combination of the presently disclosed units is configured to perform the stages any method disclosed herein.

<FIG> is a block diagram of a system including computing device <NUM>. Consistent with an embodiment of the disclosure, the aforementioned CPU <NUM>, the bus <NUM>, the memory unit <NUM>, a PSU <NUM>, and the plurality of I/O units <NUM> may be implemented in a computing device, such as computing device <NUM> of <FIG>. Any suitable combination of hardware, software, or firmware may be used to implement the aforementioned units. For example, the CPU <NUM>, the bus <NUM>, and the memory unit <NUM> may be implemented with computing device <NUM> or any of other computing devices <NUM>, in combination with computing device <NUM>. The aforementioned system, device, and components are examples and other systems, devices, and components may comprise the aforementioned CPU <NUM>, the bus <NUM>, the memory unit <NUM>, consistent with embodiments of the disclosure.

At least one computing device <NUM> may be embodied as any of the computing elements illustrated in all of the attached figures, including sensor stick <NUM>, processor <NUM>, local hub, cloud server, web client, or any other element described herein. A computing device <NUM> does not need to be electronic, nor even have a CPU <NUM>, nor bus <NUM>, nor memory unit <NUM>. The definition of the computing device <NUM> to a person having ordinary skill in the art is "A device that computes, especially a programmable [usually] electronic machine that performs high-speed mathematical or logical operations or that assembles, stores, correlates, or otherwise processes information. " Any device which processes information qualifies as a computing device <NUM>, especially if the processing is purposeful.

With reference to <FIG>, a system consistent with an embodiment of the disclosure may include a computing device, such as computing device <NUM>. In a basic configuration, computing device <NUM> may include at least one clock module <NUM>, at least one CPU <NUM>, at least one bus <NUM>, and at least one memory unit <NUM>, at least one PSU <NUM>, and at least one I/O <NUM> module, wherein I/O module may be comprised of, but not limited to a non-volatile storage sub-module <NUM>, a communication sub-module <NUM>, a sensors sub-module <NUM>, and a peripherals sub-module <NUM>.

A system consistent with an embodiment of the disclosure the computing device <NUM> may include the clock module <NUM> may be known to a person having ordinary skill in the art as a clock generator, which produces clock signals. Clock signal is a particular type of signal that oscillates between a high and a low state and is used like a metronome to coordinate actions of digital circuits. Most integrated circuits (ICs) of sufficient complexity use a clock signal in order to synchronize different parts of the circuit, cycling at a rate slower than the worst-case internal propagation delays. The preeminent example of the aforementioned integrated circuit is the CPU <NUM>, the central component of modern computers, which relies on a clock. The only exceptions are asynchronous circuits such as asynchronous CPUs. The clock <NUM> can comprise a plurality of embodiments, such as, but not limited to, single-phase clock which transmits all clock signals on effectively <NUM> wire, two-phase clock which distributes clock signals on two wires, each with non-overlapping pulses, and four-phase clock which distributes clock signals on <NUM> wires.

Many computing devices <NUM> use a "clock multiplier" which multiplies a lower frequency external clock to the appropriate clock rate of the CPU <NUM>. This allows the CPU <NUM> to operate at a much higher frequency than the rest of the computer, which affords performance gains in situations where the CPU <NUM> does not need to wait on an external factor (like memory <NUM> or input/output <NUM>). Some embodiments of the clock <NUM> may include dynamic frequency change, where, the time between clock edges can vary widely from one edge to the next and back again.

A system consistent with an embodiment of the disclosure the computing device <NUM> may include the CPU unit <NUM> comprising at least one CPU Core <NUM>. A plurality of CPU cores <NUM> may comprise identical the CPU cores <NUM>, such as, but not limited to, homogeneous multi-core systems. It is also possible for the plurality of CPU cores <NUM> to comprise different the CPU cores <NUM>, such as, but not limited to, heterogeneous multi-core systems, big. LITTLE systems and some AMD accelerated processing units (APU). The CPU unit <NUM> reads and executes program instructions which may be used across many application domains, for example, but not limited to, general purpose computing, embedded computing, network computing, digital signal processing (DSP), and graphics processing (GPU). The CPU unit <NUM> may run multiple instructions on separate CPU cores <NUM> at the same time. The CPU unit <NUM> may be integrated into at least one of a single integrated circuit die and multiple dies in a single chip package. The single integrated circuit die and multiple dies in a single chip package may contain a plurality of other aspects of the computing device <NUM>, for example, but not limited to, the clock <NUM>, the CPU <NUM>, the bus <NUM>, the memory <NUM>, and I/O <NUM>.

The CPU unit <NUM> may contain cache <NUM> such as, but not limited to, a level <NUM> cache, level <NUM> cache, level <NUM> cache or combination thereof. The aforementioned cache <NUM> may or may not be shared amongst a plurality of CPU cores <NUM>. The cache <NUM> sharing comprises at least one of message passing and inter-core communication methods may be used for the at least one CPU Core <NUM> to communicate with the cache <NUM>. The inter-core communication methods may comprise, but not limited to, bus, ring, two-dimensional mesh, and crossbar. The aforementioned CPU unit <NUM> may employ symmetric multiprocessing (SMP) design.

The plurality of the aforementioned CPU cores <NUM> may comprise soft microprocessor cores on a single field programmable gate array (FPGA), such as semiconductor intellectual property cores (IP Core). The plurality of CPU cores <NUM> architecture may be based on at least one of, but not limited to, Complex instruction set computing (CISC), Zero instruction set computing (ZISC), and Reduced instruction set computing (RISC). At least one of the performance-enhancing methods may be employed by the plurality of the CPU cores <NUM>, for example, but not limited to Instruction-level parallelism (ILP) such as, but not limited to, superscalar pipelining, and Thread-level parallelism (TLP).

Consistent with the embodiments of the present disclosure, the aforementioned computing device <NUM> may employ a communication system that transfers data between components inside the aforementioned computing device <NUM>, and/or the plurality of computing devices <NUM>. The aforementioned communication system will be known to a person having ordinary skill in the art as a bus <NUM>. The bus <NUM> may embody internal and/or external plurality of hardware and software components, for example, but not limited to a wire, optical fiber, communication protocols, and any physical arrangement that provides the same logical function as a parallel electrical bus. The bus <NUM> may comprise at least one of, but not limited to a parallel bus, wherein the parallel bus carry data words in parallel on multiple wires, and a serial bus, wherein the serial bus carry data in bit-serial form. The bus <NUM> may embody a plurality of topologies, for example, but not limited to, a multidrop / electrical parallel topology, a daisy chain topology, and a connected by switched hubs, such as USB bus. The bus <NUM> may comprise a plurality of embodiments, for example, but not limited to:.

including embodiments and derivatives such as, but not limited to, Integrated Drive Electronics (IDE) / Enhanced IDE (EIDE), ATA Packet Interface (ATAPI), Ultra-Direct Memory Access (UDMA), Ultra ATA (UATA) / Parallel ATA (PATA) / Serial ATA (SATA), CompactFlash (CF) interface, Consumer Electronics ATA (CE-ATA) / Fiber Attached Technology Adapted (FATA), Advanced Host Controller Interface (AHCI), SATA Express (SATAe) / External SATA (eSATA), including the powered embodiment eSATAp / Mini-SATA (mSATA), and Next Generation Form Factor (NGFF) / M.

Consistent with the embodiments of the present disclosure, the aforementioned computing device <NUM> may employ hardware integrated circuits that store information for immediate use in the computing device <NUM>, know to the person having ordinary skill in the art as primary storage or memory <NUM>. The memory <NUM> operates at high speed, distinguishing it from the non-volatile storage sub-module <NUM>, which may be referred to as secondary or tertiary storage, which provides slow-to-access information but offers higher capacities at lower cost. The contents contained in memory <NUM>, may be transferred to secondary storage via techniques such as, but not limited to, virtual memory and swap. The memory <NUM> may be associated with addressable semiconductor memory, such as integrated circuits consisting of silicon-based transistors, used for example as primary storage but also other purposes in the computing device <NUM>. The memory <NUM> may comprise a plurality of embodiments, such as, but not limited to volatile memory, non-volatile memory, and semi-volatile memory. It should be understood by a person having ordinary skill in the art that the ensuing are non-limiting examples of the aforementioned memory:.

Consistent with the embodiments of the present disclosure, the aforementioned computing device <NUM> may employ the communication system between an information processing system, such as the computing device <NUM>, and the outside world, for example, but not limited to, human, environment, and another computing device <NUM>. The aforementioned communication system will be known to a person having ordinary skill in the art as I/O <NUM>. The I/O module <NUM> regulates a plurality of inputs and outputs with regard to the computing device <NUM>, wherein the inputs are a plurality of signals and data received by the computing device <NUM>, and the outputs are the plurality of signals and data sent from the computing device <NUM>. The I/O module <NUM> interfaces a plurality of hardware, such as, but not limited to, non-volatile storage <NUM>, communication devices <NUM>, sensors <NUM>, and peripherals <NUM>. The plurality of hardware is used by the at least one of, but not limited to, human, environment, and another computing device <NUM> to communicate with the present computing device <NUM>. The I/O module <NUM> may comprise a plurality of forms, for example, but not limited to channel I/O, port mapped I/O, asynchronous I/O, and Direct Memory Access (DMA).

Consistent with the embodiments of the present disclosure, the aforementioned computing device <NUM> may employ the non-volatile storage sub-module <NUM>, which may be referred to by a person having ordinary skill in the art as one of secondary storage, external memory, tertiary storage, off-line storage, and auxiliary storage. The non-volatile storage sub-module <NUM> may not be accessed directly by the CPU <NUM> without using intermediate area in the memory <NUM>. The non-volatile storage sub-module <NUM> does not lose data when power is removed and may be two orders of magnitude less costly than storage used in memory module, at the expense of speed and latency. The non-volatile storage sub-module <NUM> may comprise a plurality of forms, such as, but not limited to, Direct Attached Storage (DAS), Network Attached Storage (NAS), Storage Area Network (SAN), nearline storage, Massive Array of Idle Disks (MAID), Redundant Array of Independent Disks (RAID), device mirroring, off-line storage, and robotic storage. The non-volatile storage sub-module (<NUM>) may comprise a plurality of embodiments, such as, but not limited to:.

Consistent with the embodiments of the present disclosure, the aforementioned computing device <NUM> may employ the communication sub-module <NUM> as a subset of the I/O <NUM>, which may be referred to by a person having ordinary skill in the art as at least one of, but not limited to, computer network, data network, and network. The network allows computing devices <NUM> to exchange data using connections, which may be known to a person having ordinary skill in the art as data links, between network nodes. The nodes comprise network computer devices <NUM> that originate, route, and terminate data. The nodes are identified by network addresses and can include a plurality of hosts consistent with the embodiments of a computing device <NUM>. The aforementioned embodiments include, but not limited to personal computers, phones, servers, drones, and networking devices such as, but not limited to, hubs, switches, routers, modems, and firewalls.

Two nodes can be said are networked together, when one computing device <NUM> is able to exchange information with the other computing device <NUM>, whether or not they have a direct connection with each other. The communication sub-module <NUM> supports a plurality of applications and services, such as, but not limited to World Wide Web (WWW), digital video and audio, shared use of application and storage computing devices <NUM>, printers/scanners/fax machines, email/online chat/instant messaging, remote control, distributed computing, etc. The network may comprise a plurality of transmission mediums, such as, but not limited to conductive wire, fiber optics, and wireless. The network may comprise a plurality of communications protocols to organize network traffic, wherein application-specific communications protocols are layered, may be known to a person having ordinary skill in the art as carried as payload, over other more general communications protocols. The plurality of communications protocols may comprise, but not limited to, IEEE <NUM>, ethernet, Wireless LAN (WLAN / Wi-Fi), Internet Protocol (IP) suite (e.g., TCP/IP, UDP, Internet Protocol version <NUM> [IPv4], and Internet Protocol version <NUM> [IPv6]), Synchronous Optical Networking (SONET) / Synchronous Digital Hierarchy (SDH), Asynchronous Transfer Mode (ATM), and cellular standards (e.g., Global System for Mobile Communications [GSM], General Packet Radio Service [GPRS], Code-Division Multiple Access [CDMA], and Integrated Digital Enhanced Network [IDEN]).

The communication sub-module <NUM> may comprise a plurality of size, topology, traffic control mechanism and organizational intent. The communication sub-module <NUM> may comprise a plurality of embodiments, such as, but not limited to:.

The aforementioned network may comprise a plurality of layouts, such as, but not limited to, bus network such as ethernet, star network such as Wi-Fi, ring network, mesh network, fully connected network, and tree network. The network can be characterized by its physical capacity or its organizational purpose. Use of the network, including user authorization and access rights, differ accordingly. The characterization may include, but not limited to nanoscale network, Personal Area Network (PAN), Local Area Network (LAN), Home Area Network (HAN), Storage Area Network (SAN), Campus Area Network (CAN), backbone network, Metropolitan Area Network (MAN), Wide Area Network (WAN), enterprise private network, Virtual Private Network (VPN), and Global Area Network (GAN).

Consistent with the embodiments of the present disclosure, the aforementioned computing device <NUM> may employ the sensors sub-module <NUM> as a subset of the I/O <NUM>. The sensors sub-module <NUM> comprises at least one of the devices, modules, and subsystems whose purpose is to detect events or changes in its environment and send the information to the computing device <NUM>. Sensors are sensitive to the measured property, are not sensitive to any property not measured, but may be encountered in its application, and do not significantly influence the measured property. The sensors sub-module <NUM> may comprise a plurality of digital devices and analog devices, wherein if an analog device is used, an Analog to Digital (A-to-D) converter must be employed to interface the said device with the computing device <NUM>. The sensors may be subject to a plurality of deviations that limit sensor accuracy. The sensors sub-module <NUM> may comprise a plurality of embodiments, such as, but not limited to, chemical sensors, automotive sensors, acoustic / sound / vibration sensors, electric current / electric potential / magnetic / radio sensors, environmental / weather / moisture / humidity sensors, flow / fluid velocity sensors, ionizing radiation / particle sensors, navigation sensors, position / angle / displacement / distance / speed / acceleration sensors, imaging / optical / light sensors, pressure sensors, force / density / level sensors, thermal / temperature sensors, and proximity / presence sensors. It should be understood by a person having ordinary skill in the art that the ensuing are non-limiting examples of the aforementioned sensors:.

Consistent with the embodiments of the present disclosure, the aforementioned computing device <NUM> may employ the peripherals sub-module <NUM> as a subset of the I/O <NUM>. The peripheral sub-module <NUM> comprises ancillary devices uses to put information into and get information out of the computing device <NUM>. There are <NUM> categories of devices comprising the peripheral sub-module <NUM>, which exist based on their relationship with the computing device <NUM>, input devices, output devices, and input / output devices. Input devices send at least one of data and instructions to the computing device <NUM>. Input devices can be categorized based on, but not limited to:.

Claim 1:
An inventory tracking device configured to dispense a predetermined amount of liquid, comprising:
a bottom cap (<NUM>), the bottom cap having a first opening (<NUM>) to receive a liquid and a second opening to measurably release the received liquid;
a ball chamber (<NUM>) arranged on the bottom cap, the ball chamber having a bottom opening in fluid communication with the second opening of the bottom cap, the ball chamber having a cylindrical cavity arranged to retain a ball bearing (<NUM>) and the predetermined amount of liquid, the cylindrical cavity being in fluid communication with the bottom opening, the ball chamber further having a top opening in fluid communication with the cylindrical cavity;
a sensor cavity (<NUM>) arranged proximate the ball chamber (<NUM>) and along a length of the ball chamber, the sensor cavity configured to retain at least one sensor actuated by the ball bearing and sealed to prevent the liquid from entering the sensor cavity wherein the at least one sensor is configured to be actuated by the ball bearing within the ball chamber to determine a distance traveled in order to generate volumetric data;
a pour spout (<NUM>) arranged on the ball chamber, the pour spout being in fluid communication with the top opening of the ball chamber and configured to pour the predetermined amount of liquid;
a sensor stick (<NUM>) comprising a printed circuit board disposed within the sensor cavity, the sensor stick comprising:
the at least one sensor configured to sense a position of the ball bearing throughout the following:
an entire path of the ball chamber, and
a portion of the entire path of the ball chamber, and
at least one processor (<NUM>) configured to:
determine that the at least one sensor has been actuated by the ball bearing in response to movement of the liquid dispensing container, detect a displacement of the ball bearing along the ball chamber based on the at least one sensor being actuated, and
generate volumetric data, based on the at least one sensor's sensitivity to the ball bearing throughout the length of the ball chamber, in order to determine the distance traveled by the ball bearing along the length of the ball chamber.