Patent Description:
The present disclosure relates to fluid dispensing. More particularly, this disclosure relates to fluid dispensing meters.

Fluid management has become increasingly important to control the costs of fluid overhead. For example, many vehicle fleet managers and auto dealerships have installed fluid management systems to efficiently dispense fluids, such as motor oil or transmission fluid. Such fluid management systems frequently include a fluid tank and pump located away from the dispensing point. Fluid management systems can include wireless transmission and reception of meter and tank level information to simplify tracking of fluid dispenses throughout an entire facility.

A fluid dispensing meter, also referred to as a metered valve or metering valve, can have different trigger designs. For example, a fluid dispensing meter can have a manual trigger or a pre-set fluid dispensing meter, which has a manual trigger but has the added functionality of automatically stopping a fluid dispense when a pre-set fluid dispense volume has been reached. Fluid dispensing meters can have the additional ability of preventing fluid dispenses until the meter has received dispense authorization via an RF signal that activates the trigger mechanism. The fluid dispensing meter can include a trigger actuation solenoid that controls activation of the trigger mechanism.

The fluid dispensing meter can require a user to enter a PIN code to authorize activation of the trigger mechanism by the solenoid. Current fluid management systems require the user to enter a PIN code on the meter interface to activate the meter, identify the technician, and perform a fluid dispense. Similarly, the user is required to enter a work order number or scroll through a list of work orders on the meter interface screen to select the work order that the dispense is associated with. Both entering a PIN to activate the trigger mechanism and associating a work order with the dispense event are cumbersome and time consuming.

The fluid dispensing meter can also require that the work order and the fluid dispense parameters associated with the work order (e.g., amount of fluid to be dispensed, type of fluid, etc.) be sent to the fluid dispensing meter over a Wi-Fi network. Current fluid management systems create a work order in a database, which is then transmitted to the metered valve over the Wi-Fi network. Typically, the user is required to enter a work order number using the keypad of the fluid dispensing meter or to scroll through a list of work orders on the meter interface screen to select the appropriate work order for that dispense event. Both entering a PIN to activate the trigger mechanism and associating a work order with the dispense event are cumbersome and time consuming. Further, a Wi-Fi or similar network may not be available, practical to install, and/or economical.

The present invention relates to a fluid dispensing meter according to claim <NUM>, a fluid management system according to claim <NUM> and a method of authorizing a fluid dispense according to claim <NUM>.

<FIG> is a schematic block diagram of fluid management system <NUM>. <FIG> is a cross-sectional view of fluid dispensing meter <NUM>. <FIG> is an enlarged view of detail C in <FIG>. <FIG> will be discussed together. Fluid management system <NUM> includes fluid dispensing meter <NUM>, system controller <NUM>, and authenticator <NUM>. Fluid dispensing meter <NUM> includes control board <NUM>, antenna <NUM>, sensor <NUM>, trigger control mechanism <NUM>, user interface <NUM>, meter body <NUM>, bezel housing <NUM>, trigger <NUM>, valve <NUM>, and meter <NUM>. Control board <NUM> includes memory <NUM> and processor <NUM>. Trigger control mechanism <NUM> includes solenoid <NUM>, trip rod <NUM>, and balls <NUM>. User interface <NUM> includes display screen <NUM> and user input <NUM>. Meter body <NUM> includes handle <NUM>, fluid inlet <NUM>, metering chamber <NUM>, valve inlet port <NUM>, valve cavity <NUM>, valve outlet port <NUM>, and fluid outlet <NUM>.

Fluid management system <NUM> is a system for dispensing fluid and tracking fluid dispenses. For example, fluid management system <NUM> can be implemented in an automotive shop to track dispenses of oil, coolant, and other automotive fluids. Fluid dispensing meter <NUM> is configured to dispense and meter fluid at various locations within fluid management system <NUM>. Fluid management software is implemented on system controller <NUM>, and system controller <NUM> is configured to generate work orders, track and record discrete fluid dispense events, and implement system-wide fluid tracking. It is understood that system controller <NUM> can be any suitable processor-based device for generating work orders and managing fluid data within fluid management system. For example, system controller <NUM> can be a PC or a mobile device, such as a smart phone, personal data assistant, handheld bill payment machine, and/or a mobile point of sale system.

Bezel housing <NUM> is mounted on meter body <NUM> and is configured to enclose the various electronics of fluid dispensing meter <NUM>. Control board <NUM> is disposed in bezel housing <NUM> and is in communication with antenna <NUM>, user interface <NUM>, sensor <NUM>, and trigger control mechanism <NUM>. Control board <NUM> is mounted in bezel housing <NUM> below antenna <NUM>. Antenna <NUM> is mounted in bezel housing <NUM> between control board <NUM> and display screen <NUM>, and antenna <NUM> communicates with processor <NUM>. While antenna <NUM> is described as disposed within bezel housing <NUM>, it is understood that antenna <NUM> can be mounted at any desired location where antenna <NUM> can communicate with authenticator <NUM> and processor <NUM>. For example, antenna <NUM> can extend through handle <NUM> or project out of bezel housing <NUM>. Antenna <NUM> can also be referred to as a data receiver. It is understood, however, that antenna <NUM> can be configured to both transmit and receive data. Moreover, it is understood that fluid dispensing meter <NUM> can include one or more antennas <NUM> configured to utilize different communications standards to facilitate communications between fluid dispensing meter <NUM> and various devices external to fluid dispensing meter <NUM>.

Memory <NUM> and processor <NUM> are mounted on control board <NUM>. While memory <NUM> and processor <NUM> are shown on a common control board <NUM>, it is understood that memory <NUM> and processor <NUM> can be mounted on separate circuit boards and electrically connected, such as by wiring. Memory <NUM> stores software that, when executed by processor <NUM>, authorizes fluid dispenses, tracks and records the volume of each fluid dispense, and communicates fluid dispense information to and from the user. User interface <NUM> is disposed on and in bezel housing <NUM> and is configured to receive inputs from and provide outputs to the user.

Processor <NUM>, in one example, is configured to implement functionality and/or process instructions. For instance, processor <NUM> can be capable of processing instructions stored in memory <NUM>. Examples of processor <NUM> can include any one or more of a microprocessor, a controller, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other equivalent discrete or integrated logic circuitry. It is understood that, in some examples, processor <NUM> can be implemented as a plurality of discrete circuitry subassemblies.

Memory <NUM>, in some examples, can be configured to store information during operation. Memory <NUM>, in some examples, is described as computer-readable storage media. In some examples, a computer-readable storage medium can include a non-transitory medium. The term "non-transitory" can indicate that the storage medium is not embodied in a carrier wave or a propagated signal. In some examples, memory <NUM> is a temporary memory, meaning that a primary purpose of memory <NUM> is not long-term storage. Memory <NUM>, in some examples, is described as volatile memory, meaning that memory <NUM> does not maintain stored contents when power to fluid dispensing meter <NUM> is turned off. Memory <NUM>, in some examples, also includes one or more computer-readable storage media. Memory <NUM> can be configured to store larger amounts of information than volatile memory. Memory <NUM> can further be configured for long-term storage of information. In some examples, memory <NUM> includes non-volatile storage elements.

Handle <NUM> is configured to be grasped by a single hand of a user, such that the user can manipulate fluid dispensing meter <NUM> and dispense fluid at a desired location with one hand. Fluid inlet <NUM> extends into handle <NUM> and is configured to receive a supply hose extending from a fluid storage tank. Metering chamber <NUM> is disposed in meter body <NUM>, and meter <NUM> is disposed in metering chamber <NUM>. Meter <NUM>, in some examples, can be a positive displacement meter configured to generate a volumetric measurement of the fluid flowing through fluid dispensing meter <NUM>. Sensor <NUM> interfaces with meter <NUM> and is configured to generate a volumetric flow count based on the volumetric measurement generated by meter <NUM>. Valve inlet port <NUM> extends between metering chamber <NUM> and valve cavity <NUM>. Valve <NUM> is disposed in valve cavity <NUM> and is configured to control fluid flow through fluid dispensing meter <NUM>. Valve outlet port <NUM> extends downstream from valve cavity <NUM>. Fluid outlet <NUM> is configured to receive the fluid flow from valve outlet port <NUM> and extends out of meter body <NUM>.

Trigger <NUM> extends from meter body <NUM> and interfaces with valve <NUM>. Trigger control mechanism <NUM> is mounted on meter body <NUM> and is configured to control trigger <NUM> between an activated state, where trigger <NUM> can displace valve <NUM> between a closed position and an open position, and a deactivated state, where trigger <NUM> is prevented from displacing valve <NUM> between the closed position and the open position. Solenoid <NUM> is mounted on meter body <NUM> and extends into bezel housing <NUM>. Trip rod <NUM> extends from solenoid <NUM> and is connected to trigger <NUM>. When trigger control mechanism <NUM> is activated, solenoid <NUM> locks trip rod <NUM> in position, such as with balls <NUM>. With trip rod <NUM> locked in position, trigger <NUM> pivots on trip rod <NUM> such that trigger <NUM> can displace valve <NUM> to the open position. When trigger control mechanism <NUM> is deactivated, solenoid <NUM> unlocks trip rod <NUM> such that trip rod <NUM> is capable of sliding within meter body <NUM>. With trip rod <NUM> unlocked, trigger <NUM> cannot pivot on trip rod <NUM> and instead pivots on valve <NUM>, pulling trip rod <NUM> downward within meter body <NUM>. As such, trigger <NUM> is prevented from shifting valve <NUM> to the open position with trigger control mechanism <NUM> deactivated. Trigger control mechanism <NUM> operates substantially similar to the trigger release mechanism disclosed in <CIT>.

Authenticator <NUM>, which can also be referred to as an external data source, passively provides dispense-identification data, such as user-identification data that identifies a particular user and/or a group of users, to fluid dispensing meter <NUM>. The dispense-identification data can include the user identity and work orders associated with the user, among other data. The user-identification data is provided to fluid dispensing meter <NUM> via the communication link between authenticator <NUM> and antenna <NUM>. As such, authenticator <NUM> authorizes dispenses and can set fluid limits on dispenses without requiring direct communication between system controller <NUM> and fluid dispensing meter <NUM>.

In some examples, authenticator <NUM> is a Near Field Communication ("NFC") device configured to provide the user-identification data to fluid dispensing meter <NUM>. Examples of authenticator <NUM> can include an NFC-configured wrist band, an NFC-configured ring, an NFC-configured access card, or any other suitable NFC-configured device. Where authenticator <NUM> is an NFC-enabled device, an NFC tag can be embedded on control board <NUM>. In such an example, antenna <NUM> can be an NFC tag configured to interact with authenticator <NUM>. While authenticator <NUM> is described as utilizing NFC to communicate with fluid dispensing meter <NUM>, it is understood that authenticator <NUM> can additionally or alternatively utilize any desired communication standard to communicate with fluid dispensing meter <NUM>. For example, authenticator <NUM> can utilize Bluetooth SIG (e.g., Bluetooth <NUM>, Bluetooth low energy protocol stack, Bluetooth Ultra Low Power, etc.), Wibree, BlueZ, Affix, ISO <NUM>, IEEE <NUM>/Wi Fi, ISO/IEC <NUM>, ISO/IEC <NUM>, ISM band, WLAN, active RFID (e.g., Active Reader Active Tag), passive RFID (e.g., Active Reader Passive Tag), NFCIP-<NUM>, ISO/IEC <NUM>, among other options. Antenna <NUM> can be configured to utilize any communication standard compatible with authenticator <NUM>.

During operation, a work order associated with a discrete fluid dispense event is entered at system controller <NUM>. The work order contains relevant work order information, such as the type of fluid to be dispensed, the volume of fluid to be dispensed, the customer associated with the work order, the desired location of the dispense event, and/or the identities of users authorized to perform the dispense event, among other desired information. In some examples, the work order includes a list of authorized users, which are the users authorized to complete the dispense event identified by the work order. It is understood, however, that the work order can include as much or as little information as desired to facilitate the dispense event. For example, the work order may include only the type and volume of fluid to be dispensed. The work order can be provided to fluid dispensing meter <NUM> via the communication link between system controller <NUM> and fluid dispensing meter <NUM>. The work order information can be stored in memory <NUM>.

The user, such as an automotive technician, proceeds to fluid dispensing meter <NUM> with authenticator <NUM>, which includes the dispense-identification data. When the user grasps fluid dispensing meter <NUM>, or otherwise brings authenticator <NUM> within an operable range of antenna <NUM>, authenticator <NUM> provides the user-identification data to processor <NUM> via the communication link between authenticator <NUM> and antenna <NUM>. In some examples, authenticator <NUM> is required to be within a short distance of antenna <NUM> to transmit the user-identification data, such as about <NUM>-<NUM> (about <NUM>-<NUM> in. It is understood that the data transmission between authenticator <NUM> and fluid dispensing meter <NUM> can be active or passive. Processor <NUM> recalls the work order information from memory <NUM> and compares the work order information to the user-identification data to determine if the dispense event is authorized and if the user is authorized to complete a dispense event. For example, memory <NUM> can contain a list of authorized users that processor <NUM> compares with the user-identification data. The list of authorized users can include all users authorized to make dispenses or can include particular users associated with particular work orders. In examples where the dispense-identification data includes work order-identification data, processor <NUM> also receives the work order-identification data from authenticator <NUM>. Processor <NUM> can then automatically associate the user with the work order.

In some examples, multiple work orders are associated with one user. Processor <NUM> recalls the work order data from memory <NUM> and causes user interface <NUM> to display a list of work orders to the user. In examples where the work order data includes a list of authorized users, the list displayed to the user via user interface <NUM> contains only those work orders for which the user is authorized to complete the dispense. The user can then select the work order associated with the current dispense event via user interface <NUM>.

When processor <NUM> determines that the dispense event is not authorized based on the comparison, such as where the user-identification data does not match any user on the list of authorized users, then trigger control mechanism <NUM> remains deactivated such that the user cannot dispense fluid with fluid dispensing meter <NUM>. Processor <NUM> can cause user interface <NUM> to display a notification to the user that the dispense event is not authorized, and can cause fluid dispensing meter <NUM> to communicate that an unauthorized dispense was attempted to system controller <NUM>.

When processor <NUM> determines that the dispense event is authorized based on the comparison, then processor <NUM> enables fluid dispensing meter <NUM> to proceed with the dispense event. Processor <NUM> activates trigger control mechanism <NUM>, such as by activating a power source for solenoid <NUM> to thereby power solenoid <NUM>. With trigger control mechanism <NUM> activated, trigger <NUM> is able to shift valve <NUM> to the open position. The user is then able to dispense the fluid using fluid dispensing meter <NUM>. Fluid dispensing meter <NUM> can transmit information regarding the dispense event to system controller <NUM> for work order management and system-wide fluid tracking.

Fluid management system <NUM> provides significant advantages. Authenticator <NUM> uniquely identifies a user, and processor <NUM> is configured to authorize fluid dispenses only when authenticator <NUM> is within range of antenna <NUM> and when processor <NUM> determines that the user-identification data matches the list of authorized users. As such, processor <NUM> and authenticator <NUM> prevent unauthorized fluid dispenses, as fluid dispensing meter <NUM> remains deactivated until processor <NUM> activates trigger control mechanism <NUM>. Unlocking fluid dispensing meter <NUM> with authenticator <NUM> also eliminates the need for the user to remember and enter a PIN code to unlock fluid dispensing meter <NUM>. Instead, the user can simply pick up fluid dispensing meter <NUM> and processor <NUM> unlocks fluid dispensing meter <NUM> based on the proximity of authenticator <NUM>.

<FIG> is a schematic block diagram of fluid management system <NUM>'. <FIG> is an isometric view of fluid dispensing meter <NUM> with an enlarged view of integrated optical scanner <NUM> and scanner opening <NUM>. <FIG> is a cross-sectional view of a portion of fluid dispensing meter <NUM>. <FIG> will be discussed together. Fluid management system <NUM>' includes fluid dispensing meter <NUM>, system controller <NUM>, visual pattern <NUM>, and external optical scanner <NUM>. Fluid dispensing meter <NUM> includes control board <NUM>, antenna <NUM>, sensor <NUM>, trigger control mechanism <NUM>, user interface <NUM>, meter body <NUM>, bezel housing <NUM>, trigger <NUM>, valve <NUM>, meter <NUM>, and integrated optical scanner <NUM>. Control board <NUM> includes memory <NUM> and processor <NUM>. Solenoid <NUM> of trigger control mechanism <NUM> is shown. User interface <NUM> includes display screen <NUM> and user input <NUM>. Handle <NUM>, fluid inlet <NUM>, metering chamber <NUM>, valve inlet port <NUM>, valve cavity <NUM>, and fluid outlet <NUM> of meter body <NUM> are shown. Bezel housing <NUM> includes scanner opening <NUM>.

Fluid dispensing meter <NUM> is configured to meter and dispense fluid at various locations within fluid management system <NUM>'. Fluid management software is implemented on system controller <NUM>, and system controller <NUM> is configured to generate work orders, track and record discrete fluid dispense events, and implement system-wide fluid tracking. It is understood that system controller <NUM> can be any suitable processor-based device for generating work orders and managing fluid data within fluid management system. For example, system controller <NUM> can be a PC or a mobile device, such as a smart phone, personal data assistant, handheld bill payment machine, and/or a mobile point of sale system.

Visual pattern <NUM>, which can also be referred to as an external data source, includes a unique identifier that is associated with a work order and/or a user authorized to make a fluid dispense. As such, the unique identifier provides dispense-identification data. For example, the unique identifier data can include user-identification data where visual pattern <NUM> is associated with a unique user, work order-identification data where visual pattern <NUM> is associated with a work order, or both where visual pattern <NUM> is associated with both a user and a work order. Visual pattern <NUM> can be any visual pattern configured to uniquely identify the user, the work order, or both. For example, visual pattern <NUM> can be a bar code or a QR code. Each authorized user of fluid management system <NUM>' can be issued a unique visual pattern <NUM> and/or a unique visual pattern <NUM> can be generated for each work order. Visual pattern <NUM> can be disposed on a paper print out and/or can be displayed on the screen of a device.

External optical scanner <NUM> is configured to perform optical pattern recognition and produce coded signals corresponding to the patterns recognized. For example, external optical scanner <NUM> can be a bar code scanner. External optical scanner <NUM> is a separate component from fluid dispensing meter <NUM>. While external optical scanner <NUM> is illustrated as separate from system controller <NUM>, it is understood that external optical scanner <NUM> can be integrated into system controller <NUM>, such as where system controller <NUM> is a smartphone or tablet device. External optical scanner <NUM> can also communicate visual pattern <NUM> to fluid dispensing meter <NUM>, either directly or through by way of system controller <NUM>. In some examples, external optical scanner <NUM> can be equipped with NFC card emulation, similar to authenticator <NUM> (<FIG> and <FIG>).

Similar to external optical scanner <NUM>, integrated optical scanner <NUM> is configured to perform optical pattern recognition and produce coded signals corresponding to the patterns recognized. Integrated optical scanner <NUM> integrated into the electronics of fluid dispensing meter <NUM> and communicates with processor <NUM>. Integrated optical scanner <NUM> is mounted in bezel housing <NUM> and receives visual pattern <NUM> through scanner opening <NUM> in bezel housing <NUM>. While scanner opening <NUM> is illustrated on a side of bezel housing <NUM>, it is understood that scanner opening <NUM>, and integrated optical scanner <NUM>, can be located at any desired location on fluid dispensing meter <NUM> where integrated optical scanner <NUM> maintains communications with control board <NUM>. For example, scanner opening <NUM> can extend through a left-hand side of bezel housing <NUM>, a right-hand side of bezel housing <NUM>, a front of bezel housing <NUM>, or through a hand guard extending around trigger <NUM>. A user can activate integrated optical scanner <NUM> via user interface <NUM>. Integrated optical scanner <NUM> can also be referred to as a data receiver.

During operation, fluid dispensing meter <NUM> utilizes the unique identifier from visual pattern <NUM> to authorize a fluid dispense event. The user can scan visual pattern <NUM> with either external optical scanner <NUM> or integrated optical scanner <NUM> and the dispense-identification data is transmitted to processor <NUM>. When the user utilizes external optical scanner <NUM>, external optical scanner <NUM> transmits the dispense-identification data from visual pattern <NUM> to fluid dispensing meter <NUM> either directly via the communication link between external optical scanner <NUM> and fluid dispensing meter <NUM>, or through system controller <NUM>. Where the user utilizes integrated optical scanner <NUM>, the dispense-identification data is provided directly to processor <NUM> by integrated optical scanner <NUM>. Processor <NUM> recalls authorized-dispense data from memory <NUM> and compares the authorized-dispense data to the dispense-identification data to determine if the dispense event is authorized. The authorized-dispense data can include, among others, a list of authorized users and a list of work orders that fluid dispensing meter <NUM> is authorized to complete.

Processor <NUM> compares the dispense-identification data from visual pattern <NUM> to the authorized-dispense data stored in memory <NUM>. For example, where the dispense-identification data from visual pattern <NUM> include user-identification data, processor <NUM> compares the user-identification data from visual pattern <NUM> to a list of authorized users stored in memory <NUM>. If processor <NUM> determines that the dispense event is authorized, then processor <NUM> activates trigger control mechanism <NUM> such that trigger <NUM> can shift valve <NUM> to the open position and the user can dispense fluid with fluid dispensing meter <NUM>. With trigger control mechanism <NUM> activated, the user can dispense the fluid using fluid dispensing meter <NUM>. Processor <NUM> can end the dispense event by deactivating trigger control mechanism <NUM>, such as where sensor <NUM> indicates that the actual fluid volume dispensed has reached an authorized fluid volume. Fluid dispensing meter <NUM> can transmit information regarding the dispense event to system controller <NUM> for work order management and system-wide fluid tracking.

Fluid management system <NUM>' provides significant advantages. Visual pattern <NUM> provides unique identification for both work orders and users authorized to make fluid dispenses. Processor <NUM> is configured to authorized fluid dispenses only when processor <NUM> determines that the dispense-identification data matches the authorized-dispense data stored in memory <NUM>. Integrated optical scanner <NUM> allows the dispense-identification data contained in visual pattern <NUM> to be provided directly to fluid dispensing meter <NUM> at the dispense location. Providing the dispense-identification data from integrated optical scanner <NUM> or external optical scanner <NUM> eliminates the need for the user to remember a PIN code and does not require the user to interact with user interface <NUM> to unlock fluid dispensing meter <NUM>.

<FIG> is a schematic block diagram of fluid management system <NUM>". Fluid management system <NUM>" includes fluid dispensing meter <NUM>, system controller <NUM>, authenticator <NUM>, visual pattern <NUM>, and external optical scanner <NUM>. Fluid dispensing meter <NUM> includes control board <NUM>, antenna <NUM>, sensor <NUM>, trigger control mechanism <NUM>, user interface <NUM>, and integrated optical scanner <NUM>. Control board <NUM> includes memory <NUM> and processor <NUM>.

Fluid dispensing meter <NUM> can be configured to authorize fluid dispenses based on two-part authentication from visual pattern <NUM> and authenticator <NUM>. Visual pattern <NUM> and authenticator <NUM> are both external data sources. The user scans visual pattern <NUM> with one of external optical scanner <NUM> and integrated optical scanner <NUM>. The dispense-identification data received from visual pattern <NUM> is transmitted to control board <NUM> and can be stored in memory <NUM> to be recalled at a later time. For example, multiple work orders can be scanned and the work order-identification data for each unique work order can be stored in memory <NUM>. Each unique work order can be associated with one or more users authorized to complete the work order, such that only that user or group of users are authorized to complete fluid dispense for those work orders. To initiate the dispense event, the user grasps fluid dispending meter <NUM>, bringing authenticator <NUM> within range of antenna <NUM>. In some examples, the user scans visual pattern <NUM> with integrated optical scanner <NUM> at the beginning of the dispense event to activate a work order identified by work order-identification data contained in visual pattern <NUM>.

With the work order activated, processor <NUM> compares the user-identification data received from authenticator <NUM> with the list of users authorized to complete that work order. If processor <NUM> determines that the dispense event is authorized, then processor <NUM> activates trigger control mechanism <NUM> such that the user can pull trigger <NUM> (best seen in <FIG>) and shift valve <NUM> (shown in <FIG>) to the open position. If processor <NUM> determines that the dispense event is unauthorized, then processor <NUM> does not activate trigger control mechanism <NUM>, and fluid dispensing meter <NUM> is unable to dispense fluid.

Fluid management system <NUM>" provides significant advantages. Authenticator <NUM> uniquely identifies a dispense event and/or a user, and processor <NUM> is configured to authorize fluid dispenses only when authenticator <NUM> is within range of antenna <NUM> and when processor <NUM> determines that the user-identification data matches a list of authorized users stored in memory <NUM>. Visual pattern <NUM> provides unique dispense-identification data to fluid dispensing meter <NUM>. Processor <NUM> can recall a list of work orders from memory <NUM> and identify if the user is authorized to make the fluid dispense based on the user-identification data provide by authenticator <NUM> and the list of work orders associated with that user-identification data. Passively identifying users with authenticator <NUM> and automatically activating fluid dispensing meter <NUM> based on user-identification data allows the user to more quickly and efficiently dispense fluid, as the user is not required to remember a PIN code or actively log into fluid dispensing meter <NUM>.

<FIG>, <FIG>, and <FIG> are flowcharts illustrating methods of dispensing fluid. <FIG> differ in the level of authorization required for the user. <FIG> illustrates method <NUM> of authorizing a fluid dispense that requires user authorization at fluid dispensing meter <NUM>, such as by authenticator <NUM> (<FIG> and <FIG>). <FIG> illustrates method <NUM> of authorizing a fluid dispense that requires generation of a work order and user authorization at fluid dispensing meter <NUM>. <FIG> illustrates method <NUM> of authorizing a fluid dispense that requires generation of a work order and association of specific users with that work order. User authorization is still required at fluid dispensing meter <NUM>, but the user is required to be authorized to both dispense fluid using fluid dispensing meter <NUM> and dispense fluid for that work order.

<FIG> is a flowchart illustrating method <NUM> of authorizing a fluid dispense. In step <NUM>, dispense-identification data, such as user-identification data and/or work order-identification data, is received by a fluid dispensing meter, such as fluid dispensing meter <NUM> (<FIG>). The user-identification data can be passively provided to the fluid dispensing meter by an authentication device utilizing near field communications, such as authenticator <NUM> (<FIG> and <FIG>). For example, the user can wear a bracelet, watch, ring, belt, or other authentication device that is NFC enabled, and the user-identification data can be transmitted to a processor of the fluid dispensing meter by the authenticator. In another example, the user-identification data is encoded in a visual identifier, such as visual pattern <NUM> (<FIG> and <NUM>). The user can scan the visual identifier using an optical scanner, such as external optical scanner <NUM> (<FIG> and <FIG>) or integrated optical scanner <NUM> (<FIG>).

In step <NUM>, the user-identification data provided to the fluid dispensing meter in step <NUM> is compared to a list of authorized users stored in a memory of the fluid dispensing meter. In step <NUM>, the processor determines if the user is authorized based on the comparison made in step <NUM>. If the user-identification data does not match a user identity stored in the list of authorized users, then the answer is NO and the fluid dispensing meter will not allow the user to dispense fluid with fluid dispensing meter. If the user-identification data matches a user identity stored in the list of authorized users stored in the memory, then the answer is YES and method <NUM> proceeds to step <NUM>.

In step <NUM>, the processor of the fluid dispensing meter activates a trigger control mechanism, such as trigger control mechanism <NUM> (best seen in <FIG>). For example, the processor can provide power to a solenoid, such as solenoid <NUM> (best seen in <FIG>), to cause the solenoid to lock a trip rod in position within the fluid dispensing meter. With the trigger control mechanism activated, the trigger of the fluid dispensing meter is able to shift a valve within the fluid dispensing meter into an open position.

In step <NUM>, the user dispenses the fluid with the fluid dispensing meter. In some examples, a preset fluid volume is associated with the user, such that the processor deactivates the trigger control mechanism based on the actual fluid volume dispensed reaching the preset fluid volume. Dispense information, such as the type of fluid dispensed, the identity of the user completing the dispense, the time of the dispense, the volume of fluid dispensed, and the location of the dispense are recorded. In one example, the dispense information is transmitted to a system controller, such as system controller <NUM> (<FIG>, <FIG>, and <FIG>), for fluid tracking and billing.

<FIG> is a flowchart illustrating method <NUM> of authorizing a fluid dispense. In step <NUM>, a work order is generated for a discrete dispense event. The work order can include dispense information relevant to the dispense event, such as, among others, one or more of the type of fluid to be dispensed, the volume of fluid to be dispensed, the location of the dispense event, and customer information. In step <NUM>, dispense-identification data, such as user-identification data and/or work order-identification data, is received by a fluid dispensing meter, such as fluid dispensing meter <NUM> (<FIG>). The user-identification data can be passively provided to the fluid dispensing meter by an authentication device utilizing near field communications, such as authenticator <NUM> (<FIG> and <FIG>). For example, the user can wear a bracelet, watch, ring, belt, or other authentication device that is NFC enabled, and the user-identification data can be transmitted to a processor of the fluid dispensing meter by the authenticator. In another example, the dispense-identification data is encoded in a visual identifier, such as visual pattern <NUM> (<FIG> and <FIG>). The user can scan the visual identifier using an optical scanner, such as external optical scanner <NUM> (<FIG> and <FIG>) or integrated optical scanner <NUM> (<FIG>).

In step <NUM>, the dispense-identification data provided to the fluid dispensing meter is step <NUM> is compared to authorized-dispense data stored in a memory of the fluid dispensing meter. In step <NUM>, the processor determines if the user is authorized based on the comparison made in step <NUM>. For example, the processor can compare the user-identification data to a list of authorized users stored in the memory. If the user-identification data does not match a user identity stored in the list of authorized users, then the answer is NO and the fluid dispensing meter will not allow the user to dispense fluid with fluid dispensing meter. If the user-identification data matches a user identity stored in the list of authorized users stored in the memory, then the answer is YES and method <NUM> proceeds to step <NUM>.

In step <NUM>, the current dispense event is associated with the work order. In some examples, each authorized user is authorized to complete fluid dispenses for multiple work orders. In one example, the current dispense event is associated with the work order by selecting the work order via a user interface of the fluid dispensing meter. The multiple work orders associated with the user can be displayed on a display screen, such as display screen <NUM> (best seen in <FIG>), of the fluid dispensing meter. The user can select the appropriate work order for the current dispense event by navigating the display screen with the input, such as user input <NUM> (best seen in <FIG>), and selecting the work order. In another example, the user work order data is encoded in a visual identifier, such as visual pattern <NUM>, and the user scans the visual identifier into the fluid dispensing meter using an optical scanner, such as external optical scanner <NUM> or integrated optical scanner <NUM>.

In step <NUM>, the user dispenses the fluid with the fluid dispensing meter. Where a preset fluid volume is associated with the work order and/or the user, the processor deactivates the trigger control mechanism based on the actual fluid volume dispensed reaching the preset fluid volume. Dispense information, such as the type of fluid dispensed, the identity of the user completing the dispense, the time of the dispense, the volume of fluid dispensed, and the location of the dispense are recorded. In one example, the dispense information is transmitted to a system controller, such as system controller <NUM> (<FIG>, <FIG>, and <FIG>), for fluid tracking and billing.

<FIG> is a flowchart illustrating method <NUM> of authorizing fluid dispenses. In step <NUM>, a work order, and associated work order-identification data, is generated for a discrete dispense event. The work order-identification data can include dispense information relevant to the dispense event, such as, among others, the type of fluid to be dispensed, the volume of fluid to be dispensed, the location of the dispense, and customer information. In step <NUM>, the work order is associated with specific authorized users, such that the fluid dispensing meter will activate only for the specific users associated with the work order. The work order-identification data and associated authorized users are transmitted to one or more fluid dispensing meters, such as fluid dispensing meter <NUM> (<FIG>). In step <NUM>, a dispense event is initiated by loading the work order to the fluid dispensing meter. For example, the work order number can be keyed into the fluid dispensing meter via a user interface of the fluid dispensing meter, or the work order number can be scanned into the fluid dispensing meter by an optical scanner, such as external optical scanner <NUM> (<FIG> and <FIG>) or integrated optical scanner <NUM> (<FIG>).

In step <NUM>, user-identification data is received by the fluid dispensing meter. The user-identification data can be passively provided to the fluid dispensing meter by an authentication device utilizing near field communications, such as authenticator <NUM> (<FIG> and <FIG>). For example, the user can wear a bracelet, watch, ring, belt, or other authentication device that is NFC enabled, and the user-identification data can be transmitted to a processor of the fluid dispensing meter by the authenticator. In another example, the user-identification data is encoded in a visual identifier, such as visual pattern <NUM> (<FIG> and <FIG>). The user can scan the visual identifier using an optical scanner, such as external optical scanner <NUM> (<FIG> and <FIG>) or integrated optical scanner <NUM> (<FIG>).

In step <NUM>, the user-identification data provided to the fluid dispensing meter is step <NUM> is compared to a list of authorized users stored in a memory of the fluid dispensing meter. In step <NUM>, the processor determines if the user is authorized based on the comparison made in step <NUM>. If the user-identification data does not match a user identity stored in the list of authorized users, then the answer is NO and the fluid dispensing meter will not allow the user to dispense fluid with fluid dispensing meter. If the user-identification data matches a user identity stored in the list of authorized users stored in the memory, then the answer is YES and method proceed to step <NUM>.

In step <NUM>, the user dispenses the fluid with the fluid dispensing meter. In examples where a preset fluid volume is associated with the work order and/or the user the processor deactivates the trigger control mechanism based on the actual fluid volume dispensed reaching the preset fluid volume. Dispense information, such as the type of fluid dispensed, the identity of the user completing the dispense, the time of the dispense, the volume of fluid dispensed, and the location of the dispense are recorded. In one example, the dispense information is transmitted to a system controller, such as system controller <NUM> (<FIG>, <FIG>, and <FIG>), for fluid tracking and billing.

<FIG> is a schematic block diagram of first part <NUM> of fluid management system <NUM>"'. <FIG> is a schematic block diagram of second part <NUM> of fluid management system <NUM>"'. First part <NUM> of fluid management system <NUM>‴ includes system controller <NUM> and authenticator <NUM>. Second part <NUM> of fluid management system <NUM>‴ includes authenticator <NUM> and fluid dispensing meter <NUM>. Fluid dispensing meter <NUM> includes control board <NUM>, antenna <NUM>, sensor <NUM>, trigger control mechanism <NUM>, and user interface <NUM>. Control board <NUM> includes memory <NUM> and processor <NUM>.

Fluid management system <NUM>‴ is a system for generating, authorizing, and tracking fluid dispense events. For example, fluid management system <NUM>‴ can be implemented in an automotive shop, on a manufacturing line, and/or at any other suitable location to track dispenses of oil, coolant, and other fluids. In first part <NUM> of fluid management system <NUM>"', dispense-identification data is generated and written to authenticator <NUM>. In second part <NUM> of fluid management system <NUM>‴, authenticator <NUM> communicates dispense-identification data to fluid dispensing meter <NUM>. Fluid dispensing meter <NUM> includes software stored on memory <NUM> that, when executed by processor <NUM>, authorizes or denies fluid dispenses by fluid dispensing meter <NUM> based on the dispense-identification data communicated to fluid dispensing meter <NUM> by authenticator <NUM>.

Fluid dispensing meter <NUM> is configured to dispense and meter fluid at various locations within fluid management system <NUM>. Fluid management software is implemented on system controller <NUM>, and system controller <NUM> is configured to generate work orders, track and record discrete fluid dispense events, and/or implement system-wide fluid tracking. It is understood that system controller <NUM> can be any suitable processor-based device for generating dispense information and writing the dispense information to authenticator <NUM>. For example, system controller <NUM> can be a PC or a mobile device, such as a smart phone, personal data assistant, handheld bill payment machine, and/or a mobile point of sale system.

Authenticator <NUM> is a device configured to receive, store, and transmit data regarding fluid dispenses utilizing NFC. Authenticator <NUM> can also be referred to as an external data source and/or as an NFC data source. As such, authenticator <NUM> can automatically, wirelessly transmit and/or receive data when brought within a short distance, such as about <NUM>-<NUM> (about <NUM>-<NUM> in. ), of a compatible device. Authenticator <NUM> can therefore be referred to as an NFC data source. Authenticator <NUM> is configured for NFC communications according to any desired standard, such as ISO/IEC <NUM> / ECMA-<NUM>; ISO/IEC <NUM> / ECMA-<NUM>; GSMA; NFC Forum; and/or any other applicable standard regarding NFC communications. Authenticator <NUM> can take any desired form that can receive an NFC tag to be capable of NFC communications. For example, authenticator <NUM> can be an NFC-configured wristband, an NFC-configured card, an NFC-configured sticker, an NFC-configured ring, an NFC-configured token, or any other desired NFC-capable device.

In first part <NUM> of fluid management system <NUM>"', relevant dispense-authorization data is generated and stored on authenticator <NUM>. The dispense-authorization data can be stored on authenticator <NUM> in a read-only format or a read-write format. The dispense-authorization data is provided to system controller <NUM>, and system controller <NUM> writes the dispense-authorization data to authenticator <NUM>. For example, a user can provide the dispense-authorization data to system controller <NUM> via a user interface of system controller <NUM>, and the user can then cause system controller <NUM> to write the data to authenticator <NUM>. While system controller <NUM> is described as generating and writing data to authenticator <NUM>, it is understood that any device capable of writing information to an NFC device can be utilized to provide the dispense-identification data to authenticator <NUM>. In addition, a programming unit separate from system controller <NUM> can be utilized to write the dispense-authorization data to authenticator <NUM>. For example, a facility can include a plurality of programming units at locations remote from system controller <NUM> to facilitate loading information to authenticator <NUM>. In some examples, the programming units are networked together and/or with system controller <NUM> to facilitate fluid management and tracking throughout fluid management system <NUM>‴.

The dispense-authorization data includes sufficient information to facilitate a fluid dispense event. For example, the dispense-authorization data can include fluid type information and dispense volume information. The fluid type information provides information regarding the type of fluid for the dispense event, and the dispense volume information provides the volume of fluid for the fluid dispense event. The fluid type information can be generic, such as "motor oil," or can be specific, such as "10W-<NUM> synthetic motor oil. " The dispense-authorization data can also include any additional information desired to be communicated to fluid dispensing meter <NUM> regarding the dispense event. For example, the dispense-authorization data can include user-identification data and work order-identification data.

In other examples, the data generated and stored in first part <NUM> can be initial configuration data regarding fluid dispensing meter <NUM>. Initial configuration data is the information provided to fluid dispensing meter <NUM> and stored in memory <NUM> during an initial set up of fluid dispensing meter <NUM> prior to operation. The initial configuration data is stored in memory <NUM> and is recalled during use of fluid dispensing meter <NUM>. The configuration data can include one or more of the type of fluid connected to fluid dispensing meter <NUM>, authorized-dispense data for fluid dispensing meter <NUM>, the display language of user interface <NUM> (e.g. English, Spanish, German, etc.), the units for dispense quantities (e.g. gallons, liters, etc.), and/or any other desired information for configuring fluid dispensing meter <NUM> for use.

In second part <NUM> of fluid management system <NUM>‴, the dispense-authorization data generated and stored in first part <NUM> is communicated to fluid dispensing meter <NUM> by authenticator <NUM>. The dispense-authorization data is utilized by fluid dispensing meter <NUM> to determine if a dispense event is authorized and/or to configure fluid dispensing meter <NUM> for use. Second part <NUM> of fluid management system <NUM>‴ is separate from first part <NUM> in that authenticator <NUM> authorizes fluid dispenses in second part <NUM> without requiring any additional communication between system controller <NUM> and either authenticator <NUM> or fluid dispensing meter <NUM>.

Antenna <NUM> is disposed in and/or on fluid dispensing meter <NUM> and is in communication with processor <NUM>. Antenna <NUM>, which is a data receiver and can, in some examples, also be a data transmitter, is configured to communicate with authenticator <NUM>. As such, where authenticator <NUM> is an NFC-configured device, antenna <NUM> can be an NFC tag capable of communicating with authenticator <NUM>. It is understood, that fluid dispensing meter <NUM> can be configured to communicate utilizing multiple modes of wireless communications, such as Bluetooth SIG (e.g., Bluetooth <NUM>, Bluetooth low energy protocol stack, Bluetooth Ultra Low Power, etc.), Wibree, BlueZ, Affix, ISO <NUM>, IEEE <NUM>/Wi Fi, ISO/IEC <NUM>, ISO/IEC <NUM>, ISM band, WLAN, active RFID (e.g., Active Reader Active Tag), passive RFID (e.g., Active Reader Passive Tag), NFCIP-<NUM>, ISO/IEC <NUM>, among other options. As such, fluid dispensing meter <NUM> can include one or more additional data receivers and/or data transmitters to facilitate communications utilizing the multiple modes.

Antenna <NUM> transmits information to and from control board <NUM> during operation. It is understood that antenna <NUM> can include transceiver electronics as known in the art. As such, antenna <NUM> can also be referred to as a transceiver that can transmit and/or receive data and that includes a physical component for transducing wireless signals and circuitry for handling/communicating the signals from the physical component, as known in the art. Memory <NUM> of fluid dispensing meter <NUM> includes software that, when executed by processor <NUM>, authorizes fluid dispenses; tracks and, in some examples, records the volume of fluid dispensed; and communicates fluid dispense information to the user and/or authenticator <NUM>. Processor <NUM>, which can be implemented in some embodiments as a plurality of discrete circuitry subassemblies, can control trigger control mechanism <NUM> between the activated state and the deactivated state based on the data received from authenticator <NUM>. As described above with regard to <FIG>, trigger control mechanism <NUM> controls the functionality of trigger <NUM> (shown in <FIG> and <FIG>) such that the user can dispense fluid when trigger control mechanism <NUM> is in the activated state and the user cannot dispense fluid when trigger control mechanism <NUM> is in the deactivated state. Sensor <NUM> is disposed in fluid dispensing meter <NUM> and is configured to sense the volume of fluid flowing through fluid dispensing meter <NUM> during a dispense event and to generate a volumetric flow count. Sensor <NUM> communicates the volumetric flow count to control board <NUM>.

During operation, authenticator <NUM> provides all information required to authorize a fluid dispense from fluid dispensing meter <NUM>. In first part <NUM>, the dispense-authorization data is generated at system controller <NUM> and written to authenticator <NUM>. Authenticator <NUM> facilitates information transfer between system controller <NUM> and fluid dispensing meter <NUM>. Authenticator <NUM> authorizes fluid dispenses by fluid dispensing meter <NUM> without requiring communication between fluid dispensing meter <NUM> and system controller <NUM> or any other central database. Instead, authenticator <NUM> is a physical object that provides information transfer between system controller <NUM> and fluid dispensing meter <NUM>.

The user brings authenticator <NUM> within operable range of antenna <NUM>. As described above, in some embodiments, authenticator <NUM> is an NFC-configured device and antenna <NUM> is an NFC tag. As such, the operable range is less than about <NUM> (about <NUM> inches) and preferably about <NUM>-<NUM> (about <NUM>-<NUM> in. Antenna <NUM> is powered by the power source of fluid dispensing meter <NUM>, and antenna <NUM> wirelessly receives the dispense-authorization data from authenticator <NUM>. As noted above, the dispense-authorization data includes sufficient information to facilitate the dispense event, such as the fluid type information and dispense volume information.

The dispense-authorization data is provided to fluid dispensing meter <NUM> by authenticator <NUM>. Processor <NUM> can recall configuration data from memory <NUM> and compare the configuration data to the dispense-authorization data. Processor <NUM> can determine whether to authorize or deny the fluid dispense based on that comparison. For example, the configuration data can include the type of fluid that fluid dispensing meter <NUM> is connected to dispense. Processor <NUM> then compares that configuration data to the fluid type information from the dispense-authorization data to determine the authorization status of the dispense event. If the fluid type information from the dispense-authorization data matches the fluid type information from the configuration data, then processor <NUM> knows that fluid dispensing meter <NUM> can make the requested dispense. Processor <NUM> then causes trigger control mechanism <NUM> to enter the activated state, which allows the user to dispense fluid with fluid dispensing meter <NUM>.

As the fluid is dispensed, sensor <NUM> generates and communicates the volumetric flow count to processor <NUM>. Processor <NUM> compares the volumetric flow count to the dispense volume information from the dispense-authorization data. Processor <NUM> knows that fluid dispensing meter <NUM> has dispensed the full volume of fluid authorized for that dispense event when the volumetric flow count reaches the authorized dispense volume. Processor <NUM> then causes trigger control mechanism <NUM> to enter the deactivated state, which stops the flow of fluid through fluid dispensing meter <NUM> and prevents the user from dispensing additional fluid. The fluid dispense event is thus complete.

Authenticator <NUM> can also, in some examples, include dispense-authorization data for multiple fluid dispense events. For example, authenticator <NUM> can include information for a first dispense event and a second dispense event. The dispense-authorization data for the first and second dispense events can include the same fluid type information with different dispense volume information. In such an instance, processor <NUM> will prompt the user, via user interface <NUM>, to select the dispense event that the user wants to complete. In examples where the first and second dispense events have different fluid types, processor <NUM> can automatically select and authorize one of the dispense events based on the fluid type information from the configuration data.

Authenticator <NUM> can be configured as either read-only or read-write. When authenticator <NUM> is read-only, the dispense-authorization data remains on authenticator <NUM>, such that authenticator <NUM> can authorize multiple dispenses of the same fluid type and quantity. When authenticator <NUM> is read-write, dispense-authorization data can be removed from authenticator <NUM> based on fluid dispensing meter <NUM> accepting and authorizing the fluid dispense event. Removing the dispense-authorization data from authenticator <NUM> prevents additional, undesired fluid dispenses and can be used to confirm dispenses. For example, the user can bring authenticator <NUM> back to system controller <NUM>, and system controller <NUM> can read authenticator <NUM> to confirm the number of dispense-authorizations remaining on authenticator <NUM>. With authenticator <NUM> being read-write, fluid dispensing meter <NUM> can also write dispense information regarding each dispense event to authenticator <NUM>. The dispense information is then stored on authenticator <NUM> until authenticator <NUM> is brought within operable range of system controller <NUM>, at which point authenticator <NUM> communicates the dispense information to system controller <NUM> to facilitate system-wide fluid management and tracking. In other examples, fluid dispensing meter <NUM> can provide the dispense information directly to system controller <NUM>, such as via Wi-Fi, Bluetooth, or other modes of wireless communication.

Fluid management system <NUM>‴ and authenticator <NUM> facilitate efficient, secure fluid dispenses across a variety of applications.

In one example, authenticator <NUM> is configured as a fluid voucher. Authenticator <NUM> is loaded with dispense-authorization data for multiple dispense events at system controller <NUM>. When authenticator <NUM> is brought within operable range of fluid dispensing meter <NUM>, fluid dispensing meter <NUM> authorizes a dispense event based on the dispense-authorization data contained on authenticator <NUM>. The authorized dispense event is removed from authenticator <NUM> based on fluid dispensing meter <NUM> accepting and authorizing the dispense event. As such, authenticator <NUM> would then include dispense-authorization data for one less dispense event.

For example, authenticator <NUM> can be loaded with dispense-authorization data relating to five individual dispense events. The dispense-authorization data can be the same for each dispense event (i.e. all dispenses include the same fluid type information and dispense volume information) or can vary across the various dispense events. Authenticator <NUM> is brought within operable range of fluid dispensing meter <NUM>, and processor <NUM> determines the authorization status based on the dispense-authorization data received from authenticator <NUM>. If processor <NUM> determines that the event is authorized, then processor <NUM> will cause trigger control mechanism <NUM> to enter the activated state and will remove the dispense-authorization data from authenticator <NUM>. With that dispense-authorization data removed from authenticator <NUM>, authenticator <NUM> now includes dispense-authorization data for four additional dispense events.

Configuring authenticator <NUM> as a fluid voucher can provide significant advantages. A user, such as an automotive shop, can provide pre-loaded NFC data sources (i.e., authenticator <NUM>) to customers that can be redeemed when bringing a vehicle in for servicing. Storing fluid vouchers on and redeeming fluid vouchers through authenticator <NUM> provides a secure system that avoids coupon issues, such as counterfeiting and alterations. The user simply brings authenticator <NUM> within operable range of fluid dispensing meter <NUM> to authorize the dispense event. Fluid dispensing meter <NUM> actually authorizing the dispense event validates the fluid voucher, providing increased confidence to both the user and the consumer.

In other examples, authenticator <NUM> is configured as a general authorization device for use of fluid dispensing meter <NUM>. For example, authenticator <NUM> can include dispense-authorization data that authorizes dispenses of a certain fluid type, such as transmission fluid. In some examples, the dispense-authorization data can further or alternatively include an authorized timeframe within which authenticator <NUM> is able to activate fluid dispensing meter <NUM>. For authenticator <NUM> to activate fluid dispensing meter <NUM>, processor <NUM> compares the fluid type associated with fluid dispensing meter <NUM> to the fluid type information from the dispense-authorization data. Processor <NUM> also or alternatively compares the authorized timeframe to the current time to determine if the dispense event is authorized. For example, the authorized timeframe can be the business hours of an automotive shop. Processor <NUM> will deny any attempted fluid dispense occurring outside of the business hours based on current time being outside of the authorized timeframe provided by authenticator <NUM>. In such an example, the authorized timeframe and/or dispense-authorization data can be read-only, such that the dispense-authorization data is not removed from authenticator <NUM> upon authorization of a dispense event by fluid dispensing meter <NUM>. Authenticator <NUM> being a general authorization device can provide significant advantages. As a general authorization device, authenticator <NUM> prevents unauthorized dispenses outside of a desired timeframe and provides greater end user confidence by ensuring that the correct, desired fluid is dispensed.

In other examples, authenticator <NUM> is configured as a rechargeable key. Authenticator <NUM> being a rechargeable key means that authenticator <NUM> provides authorization for a defined period before authenticator <NUM> needs to be reloaded to authorize additional fluid dispenses. The defined period can be based on a time period and/or a number of dispenses. For example, the authorized-dispense data can include a defined time period that begins to run when authenticator <NUM> first provides authorized-dispense data to fluid dispensing meter <NUM> or begins to run as soon as authorized-dispense data is loaded onto authenticator <NUM>. Alternatively or in addition to the defined time period, a set number of dispenses can be written onto authenticator <NUM>. Similar to the voucher capabilities discussed above, dispense-authorization data for a single dispense event can be subtracted from the plurality of dispense events each time a fluid dispense event is authorized by authenticator <NUM>. Authenticator <NUM> would need to be reloaded with additional dispense-authorization data after the set number of dispenses is exhausted. Configuring authenticator <NUM> as a rechargeable key can provide significant advantages. Authenticator <NUM> prevents unauthorized dispense from occurring beyond the number authorized and/or outside of the authorized timeframe, providing increased security and confidence.

In other examples, fluid management system <NUM>‴ is utilized for fleet-based fluid management to track, monitor, and authorize fluid dispenses for a fleet of vehicles. An authenticator <NUM> can be located on each individual vehicle in a fleet of vehicles and can be loaded with information specific to the individual vehicle. When the vehicle is brought in for servicing, the technician is able to recall relevant information regarding the vehicle by simply bringing fluid dispensing meter <NUM> within operable range of authenticator <NUM>. Authenticator <NUM> provides relevant information to the user via user interface <NUM> of fluid dispensing meter <NUM>. In some examples, authenticator <NUM> can also provide immediate authorization for dispenses of various fluids based on the elapsed time since the vehicle was last serviced. Updated service information can be written to authenticator <NUM> by fluid dispensing meter <NUM> throughout servicing, such as at the end of each fluid dispense event.

For example, authenticator <NUM> can be located on a vehicle, such as by locating an NFC-configured sticker on the dashboard or the vehicle door jamb. The dispense-authorization data loaded onto authenticator <NUM> is based on the particular vehicle that authenticator <NUM> is associated with. For example, different engines require different types and quantities of fluids. The dispense-authorization data loaded onto authenticator <NUM> is specific to that vehicle's fluid requirements. Most vehicle fluids are supposed to be replaced after a certain time period or a certain number of miles driven. Authenticator <NUM> can automatically authorize fluid dispenses based on the certain time period passing since the most-recent servicing.

For example, the vehicle may require an oil change every three months and a power steering fluid change every three years. For example, it can be assumed that both of the fluids were changed at the first vehicle servicing. Dispense-authorization data regarding both the oil and the power steering fluid is written to authenticator <NUM> after the fluid dispenses are complete. The dispense-authorization data written to authenticator <NUM> can include a specific time interval for each fluid, the date on which the servicing occurred, and/or the date that the next servicing is required. The vehicle is brought in for its second servicing after five months. Fluid dispensing meter <NUM> is brought within operable range of authenticator <NUM>, and authenticator <NUM> provides the dispense-authorization data to fluid dispensing meter <NUM>. Because more than three months have elapsed since the last oil change, authenticator <NUM> authorizes a fluid dispense event for oil. However, because less than three years have passed since the last power steering fluid change, authenticator <NUM> does not authorize a fluid dispense event for the power steering fluid. The dispense-authorization data for oil is reset such that authenticator <NUM> will not authorize another oil dispense until the specific time interval has passed since the second servicing.

Authenticator <NUM> can automatically reset the time interval based on authenticator <NUM> providing the authorization for an oil dispense to fluid dispensing meter <NUM>, based on fluid dispensing meter <NUM> accepting the authorization from authenticator <NUM>, or based on the fluid dispense event being completed. For example, the user can dispense the oil and then bring fluid dispensing meter <NUM> within operable range of authenticator <NUM> to provide information to authenticator <NUM> and reset the specific time interval. Utilizing fluid management system <NUM>‴ for fleet-based fluid management can provide significant advantages. The information specific to each vehicle in the fleet is stored on an authenticator <NUM> specific to that vehicle. The service technician does not need to look up the last service date for each fluid from a central database, but instead simply brings fluid dispensing meter <NUM> within operable range of authenticator <NUM>. This provides a simpler, more efficient process for ascertaining the status of various fluids.

In another example, fluid management system <NUM>‴ can be implemented during the vehicle manufacturing process. When a vehicle is manufactured it requires first fills of various fluids. Authenticator <NUM> can be loaded with dispense-authorization data for each of the various fluids, and authenticator <NUM> can be located on the vehicle in any desired manner. As such, authenticator <NUM> can provide a "recipe" for first fluid fills during manufacturing. As the vehicle reaches a point in the manufacturing process where a first fill is desired, a fluid dispensing meter <NUM> is brought within operable range of authenticator <NUM>. Fluid dispensing meter <NUM> receives dispense-authorization data from authenticator <NUM>. As discussed above, fluid dispensing meter <NUM> is initially configured at set up so fluid dispensing meter <NUM> knows the fluid type that fluid dispensing meter <NUM> is connected to. Fluid dispensing meter <NUM> will accept and initiate only fluid dispenses for the fluid type associated with fluid dispensing meter <NUM> during the initial configuration. In some instances, similar to the voucher example discussed above, the dispense-authorization data regarding that fluid is removed from authenticator <NUM> when the dispense event is accepted by fluid dispensing meter <NUM>. Removing the dispense-authorization data regarding the authorized dispense event from authenticator <NUM> provides tracking and eliminates uncertainty as to whether the fluid has previously been added. At the end of the manufacturing process, authenticator <NUM> can be checked to ensure that all required fluids have been added to the vehicle. Where authenticator <NUM> includes no additional dispense-authorization data, the manufacturer knows that all of the initial fluid fills have been completed.

Fluid management system <NUM>‴ provides significant advantages. Fluid management system <NUM>‴ does not require any wired connections between the point of authorization, such as system controller <NUM>, and fluid dispensing meter <NUM>. Instead, authenticator <NUM> is physically moved between the point of authorization and fluid dispensing meter <NUM> to provide dispense-authorization data to fluid dispensing meter <NUM>. In addition, first part <NUM> and second part <NUM> of fluid management system <NUM>‴ are separate; as such, dispense events can be created and loaded to authenticator <NUM>, and authenticator <NUM> can be managed as a physical component of fluid management system <NUM>‴. Managing authenticator <NUM> as a physical component of fluid management system <NUM>‴ provides greater certainty to the user and simplifies tracking of fluid dispenses. In addition, fluid management system <NUM>‴ utilizes NFC to transfer data to and from authenticator <NUM>, which protects against RF interference that can affect other wireless systems. Authenticator <NUM> can also take any desired form capable of supporting an NFC tag, such as a card, fob, wearable, sticker, etc. Authenticator <NUM> can thus be implemented in any desired way to best meet the requirements of the particular application that authenticator <NUM> is being used in. Authenticator <NUM> thereby provides flexibility to fluid management system <NUM>‴ to allow fluid management system <NUM>‴ to adapt to any desired environment, from an automotive shop to a manufacturing line.

<FIG> is a flowchart illustrating method <NUM> of dispensing fluid. Method <NUM> is performed using a fluid management system, such as fluid management system <NUM>‴ (<FIG>), and a near field communication ("NFC") data source, such as authenticator <NUM> (<FIG>), to provide user-identification data, work order data, and/or other data to a fluid dispensing meter, such as fluid dispensing meter <NUM> (shown in <FIG>, <FIG>). The fluid dispensing meter includes a trigger control mechanism, such as trigger control mechanism <NUM> (best seen in <FIG>); an NFC data receiver, such as antenna <NUM> (<FIG>); and a control board, such as control board <NUM> (shown in <FIG>, <FIG>, <FIG>, and <FIG>). However, with this embodiment, the dispensing meter may, optionally, not include a Wi-Fi antenna. Instead (or in addition to the Wi-Fi antenna), the fluid data receiver is configured to receive the dispense-authorization data (e.g., a fluid dispense "voucher") from an NFC-configured data source, which may be in addition to or in lieu of the user-identification data. The control board includes a processor, such as processor <NUM> (<FIG>, <FIG>, <FIG>, and <FIG>), and a memory, such as memory <NUM> (<FIG>, <FIG>, <FIG>, and <FIG>), encoded with instructions that, when executed by the processor, cause the processor to recall the dispense-authorization data (and other data, such as the dispense-identification data) from the NFC data source, and to control the trigger control mechanism between the activated state and the deactivated state based on the dispense-authorization data. The trigger control mechanism is mounted in a body of the fluid dispensing meter and is controllable between an activated state, where the fluid dispensing meter can dispense fluid, and a deactivated state, where the fluid dispensing meter is prevented from dispensing fluid.

In step <NUM>, a work order for a fluid dispense event is created. By way of example, a vehicle service department manager or parts department manager may create a fluid dispense work order on a computer with a processor, such as on system controller <NUM> (shown in <FIG>, <FIG>, <FIG>, and <FIG>). The work order includes dispense-authorization data, such as the type and amount of fluid to be dispensed.

In step <NUM>, the dispense-authorization data is written to the NFC data source. The dispense-authorization data can be written to the NFC data source in any applicable manner. For example, the computer on which the work order was created can be linked to a NFC reader/writer, which is used to transmit the dispense-authorization data to the NFC chip.

In step <NUM>, the NFC data source is placed within an operable proximity of the NFC data receiver of the fluid dispensing meter. With NFC data source within operable proximity, NFC data source is activated and transmits the dispense-authorization data to the fluid dispensing meter via the NFC data receiver. In some examples, the data transmission can be preceded by activating the fluid dispensing meter. For example, the dispensing meter may be asleep, and as such, may need to be awoken; or the NFC data receiver in the dispensing meter may need to be activated. Additionally, method <NUM> can include the user authentication steps as described in method <NUM> (<FIG>), method <NUM> (<FIG>), or method <NUM> (<FIG>). The NFC data receiver transmits the dispense-authorization data to the control board, where the processor determines the authorization status of the fluid dispense event based on the dispense-authorization data.

In step <NUM>, the dispense-authorization data provided in step <NUM> is compared to configuration data stored in the memory of the fluid dispensing meter. In step <NUM>, the processor of the fluid dispensing meter determines an authorization status based on the dispense-authorization data. Initially, the processor can determine whether the dispense-authorization data includes sufficient information for a fluid dispense event. For example, the processor can be configured to accept the dispense-authorization data only if fluid type information is provided to ensure that the fluid dispensing meter can actually perform the requested fluid dispense. The processor compares the dispense-authorization data to configuration data recalled from the memory of the fluid dispensing meter to determine the authorization status of the fluid dispense event. In some examples, the processor can proceed straight to the comparison without checking for sufficient information. In such an example, the processor recognizes that there is insufficient information when making the comparison and can deny the fluid dispense based on that recognition. Alternatively, the authorization and/or denial can be based on additional authorization parameters (e.g., dispense volume information, user authorization status, etc.). If the dispense-authorization data is insufficient or not accepted, then the answer is NO and the fluid dispensing meter will not allow the user to dispense fluid with the fluid dispensing meter. If the dispense-authorization data is sufficient and accepted, then the answer is YES and method <NUM> proceeds to step <NUM>.

Claim 1:
A fluid dispensing meter (<NUM>) configured to be grasped by a single hand of a user comprising:
a handle (<NUM>) to be grasped by a single hand of the user;
a trigger (<NUM>) interfaced with a valve (<NUM>) disposed within the body of the fluid dispensing meter (<NUM>), the trigger (<NUM>) configured to displace the valve (<NUM>) between a closed position and an open position;
a trigger control mechanism (<NUM>) disposed in the body of the fluid dispensing meter (<NUM>), the trigger control mechanism (<NUM>) controllable between an activated state, where the trigger (<NUM>) can displace the valve (<NUM>) to the open position, and a deactivated state, where the trigger is prevented from displacing the valve to the open position;
a near field communications (NFC) data receiver disposed in the fluid dispensing meter (<NUM>), the NFC data receiver configured to receive data from an external data source; and
a control board (<NUM>) disposed in the fluid dispensing meter (<NUM>), the control board (<NUM>) comprising:
a processor (<NUM>); and
a memory (<NUM>) encoded with instructions that, when executed by the processor (<NUM>), cause the processor to:
recall configuration data from the memory (<NUM>), the configuration data including a fluid type that the fluid dispensing meter (<NUM>) is connected to dispense;
compare the configuration data to dispense-authorization data received from the external data source, wherein the dispense-authorization data includes fluid type information; and
control the trigger control mechanism (<NUM>) between the activated state and the deactivated state based on the comparison of the configuration data and the dispense-authorization data.