PRIORITY CLAIM

[0001] The present application claims priority to and the benefit of U.S. Provisional Patent Application Serial No. 63/266,817, filed January 14, 2022. U.S. Provisional Patent Application Serial No. 63/266,817 is incorporated in its entirety by reference herein.

FIELD

[0002] The present disclosure relates generally to the field of medical services. Embodiments of the invention relate more particularly to methods and systems for sanitization liquid dispensing, monitoring, tracking, and analytics.

BACKGROUND

[0003] Hospital Acquired Infections (HAIs) are a significant cause of illness and death that create a significant financial strain on healthcare facilities. An important way to reduce HAI infection rates is to improve compliance in hand sanitization.

SUMMARY

[0004] According to one aspect of the disclosed embodiments, a tracking module for tracking one or more dispensing events for one or more user using a liquid dispenser comprises: a processor; a user detector coupled to the processor for wirelessly communicating with one or more wireless proximity devices to track a user within a proximity of the tracking module; and a dispensing sensor for detecting when a dispensing pump of the liquid dispenser has been activated. The processor may be configured to log, or cause to be logged, at least one dispensing event including received data from the wireless proximity device in response to detecting that the dispensing pump has been activated.

[0005] Various examples are disclosed herein.

[0006] According to another aspect of the disclosed embodiments, a liquid dispenser including a housing and a tracking module is provided.

[0007] According to another aspect of the disclosed embodiments, a tracking system for tracking one or more dispensing events for one or more user using a liquid dispenser is provided including a tracking module, a wireless proximity device, and a remote processing device.

[0008] Methods for tracking a user, for logging and tracking dispensing events, for analyzing logged dispensing events and user data to determine opportunities and missed opportunities, for generating and providing reports based on example analysis, and for configuring features are provided in example embodiments.

[0009] Other features and advantages of the invention will be apparent from the following specification taken in conjunction with the following drawings.

[0010] The details of one or more exemplary embodiments of the invention are set forth in the accompanying drawings and the description below. Other features, objects, and advantages of the invention will be apparent from the description and drawings, and from the claims. [0011] All publications, patents, patent applications cited herein are hereby expressly incorporated by reference in their entireties for all purposes.

DESCRIPTION OF THE DRAWINGS

[0012] The drawings set forth herein are illustrative of exemplary embodiments provided herein and are not meant to limit the scope of the invention as encompassed by the claims.

[0013] The present disclosure will become more fully understood from the detailed description and the accompanying drawings, wherein:

[0014] Figure 1 shows an example liquid sanitizer dispenser having sanitizing event tracking capabilities according to embodiments.

[0015] Figures 2-3 show exterior and interior portions, respectively, of an example pump that can be coupled to a dispenser container of an example liquid sanitizer dispenser for selectively dispensing the stored liquid.

[0016] Figure 4 shows an example liquid sanitizer dispenser according to additional embodiments.

[0017] Figure 5 shows a rear perspective view of an interior of an example dispenser backpack housing in a vertical orientation (right) and a partial perspective view of the interior of the example dispenser backpack housing in a horizontal orientation (left), illustrating example features.

[0018] Figure 6 is a front view of an upper portion of a dispenser backpack connected to a rear portion of a dispenser container for the example liquid sanitizer dispenser of Figure 1. [0019] Figure 7 shows rear views of an interior (center), interior with rear lid (right), and upper portion of interior (left) of a dispenser backpack, illustrating various features.

[0020] Figure 8 shows an example printed circuit board (PCB) for the dispenser backpack, illustrating various features.

[0021] Figure 9A shows an example wireless proximity device.

[0022] Figure 9B shows a room in which an example tracking system may be implemented.

[0023] Figure 10 shows an example Console Log with an internet protocol (IP) Address Assigned.

[0024] Figure 11 shows an example cloud-based system backend configuration for a remote processing device in communication with networked devices.

[0025] Figure 12 shows an example operation of a tracking system, referred to herein as an opportunities workflow.

[0026] Figures 13-14 show example Client Portal screenshot provided by a remote processing device according to example methods, illustrating example dashboards.

[0027] Figures 15-25 show example Client Portal screenshots provided by a remote processing device according to example methods, illustrating displayed data and reports of various types and accessing users, including administration (Figure 15, Admin Users; Figure 16, Device Type; Figure 17, Event Type; Figure 18, Organization Type); Management (Figure 19, Organization; Figure 20, Device Data; Figure 21 ; Users); and reports (Figure 22; Dispensation Activities; Figure 23, Device Status; Figure 24, Missed Opportunities; Figure 25, Sanitization). [0028] In the drawings, reference numbers may be reused to identify similar and/or identical elements.

DETAILED DESCRIPTION

[0029] It would be useful to provide devices, methods, and systems that can improve user compliance with sanitizing practices, e.g., hand sanitizing practices, in a facility such as but not limited to a hospital or other medical facility. In some example sanitization and tracking methods, devices, and systems provided herein, user compliance with (e.g., hand) sanitization practices can be improved by tracking compliance by users in a facility and providing feedback to such users on site. Example systems and devices can be integrated with sanitizing equipment such as dispensers, providing smart dispensers that can log, track, and/or enforce hand sanitization practices. Systems and methods can optionally include one or more features to reduce or minimize power consumption. Though example embodiments herein refer to hand sanitization for an illustrative application, embodiments may be applied to sanitizing practices more generally.

[0030] Example hand sanitization and tracking systems including smart dispensers can provide or be integrated into a comprehensive hygiene system that assists facilities in tracking compliance and consistency in sanitizing practices. For a medical facility, for instance, example systems can assist in lowering HAI rates to increase patient safety and outcomes, such as by significantly reduce infectious diseases. This may be provided in example systems by recording, or logging, user (such as but not limited to facility staff) dispensing events (e.g., where the dispenser is operated) and in some methods may be further provided by providing one or more reports for compliance purposes. Automated tracking that may be performed by example methods and systems can reduce or eliminate guessing with actionable data on who, what, when and where employee sanitization occurred, which can in turn help to modify behavior and/or drive staff compliance.

[0031] Preferred embodiments will now be discussed with respect to the drawings. The drawings include schematic figures that may not be to scale, which will be fully understood by skilled artisans with reference to the accompanying description. Features may be exaggerated for purposes of illustration. From the preferred embodiments, artisans will recognize additional features and broader aspects of the invention.

[0032] Example Smart Dispenser and Tracking Module

[0033] Figure 1 shows an example liquid sanitizer dispenser 100 having sanitizing event tracking capabilities. Example liquid sanitizer dispensers having sanitizing event tracking capabilities may be generally referred to as “smart” dispensers. The example smart dispenser 100 includes a dispenser container 102 for storing a liquid, such as a cleaning or sanitizing liquid, examples of which will be appreciated by an artisan. The smart dispenser 100 can contain various liquids to be dispensed for sanitizing needs, including but not limited antimicrobial water, alcohol-based solution, water, and soap. A nonlimiting example sanitizing liquid that may be contained within the dispenser container 102 is an antibacterial alcohol hand sanitizer liquid including water, ethyl alcohol (e.g., 70% (v/v)), and one or more inactive ingredients. Another example sanitizing liquid is an antibacterial alcohol-free hand sanitizer liquid. [0034] Figures 2-3 shows an example pump 110 that can be coupled to the dispenser container for selectively dispensing the stored liquid. The dispenser container 102 and pump 110 may be contained within a housing 112, as will be appreciated by an artisan. The configuration of the dispenser container 102, pump 110, and/or dispenser housing 112, including dimensions, shape, materials, etc. can vary as needed for the intended operation, operating environment, etc., and those shown herein are merely exemplary. For instance, Figure 4 shows another example smart dispenser 200 in which a lower retaining portion 202 is connected to or integrated with a housing of a dispenser container 204 to receive excess dispensed liquid.

[0035] Referring again to Figures 2-3, the pump 110 may be operated, e.g., using a pump motor 114 that is activated manually (e.g., via a button, switch, etc.) or automatically. An automatic activation can use a sensor such as an optical sensor 116 to detect the presence of a user (e.g., a user’s hand(s)) and automatically trigger the pump motor, as will be appreciated by an artisan.

[0036] The smart dispenser 100, 200 further includes a tracking module such as tracking module 120 for detecting pump dispensing operation and presence of one or more users, and for storing (e.g., logging) data regarding the pump dispensing operation and presence and/or wirelessly transmitting data regarding the pump operation and presence to an external device in communication with the tracking module. The tracking module 120 may be integrated in or with the housing of the dispenser container, or, as shown by example in Figures 1 and 4-7, may be provided in an additional housing 122 that is connected to or otherwise integrated with the housing 112 of the dispenser container 102. In the example smart dispenser 100, the housing 122 is configured, e.g., sized, to connect to or mate with a back portion of the dispenser container 102.

[0037] Figure 6 shows an upper portion of the tracking module 120 connected to a rear portion of the dispenser container 102. An example tracking module having a housing configured to be provided behind a dispenser container is referred to in herein as a dispenser backpack 120. The dispenser backpack 120 may be modular or integrated with other components of the smart dispenser 100 such as the dispenser container 102.

[0038] The dispenser backpack 120 may be coupled to, e.g., mounted to, a mounting surface 130, such as shown in Figure 4, for mounting the smart dispenser 100. As another example, Figure 5 shows a dispenser backpack housing 122 including a movable back plate 132 coupled to the housing 122 via a hinge 134. The back plate 132 includes a plurality of openings for accommodating fasteners (not shown) for securing the back plate to the mounting surface 130. Alternatively, or additionally, the back plate 132 can be secured to the mounting surface 130 or to another surface using, e.g., an adhesive such as but not limited to glue or double-sided tape. Magnets 136 can be used to secure the back plate 132 to close the housing 122 or to connect the housing 122 to a surface. The mounting surface 130 itself may be mounted or otherwise secured or connected to a surface, such as a wall of a room, etc. The smart dispenser 100 can alternatively or additionally be mounted to a stand that is disposed within the room.

[0039] Circuitry, e.g., embodied in a printed circuit board (PCB) 140, can be disposed within the backpack housing 122 and configured for performing example operations for the tracking module 120. Figure 7 shows the example PCB 140 mounted to the backpack housing 122. Figure 8 shows illustrative features of the example PCB 140. A user detector 142, e.g., embodied in a wireless module including a wireless receiver and antenna, is provided on the PCB 140 for wirelessly communicating with one or more wireless proximity devices, such as via Bluetooth low energy (BLE), ultrawideband, or other wireless protocols and methods. In example embodiments, the one or more wireless proximity devices, or at least a subset thereof, are identifiable, e.g., uniquely identifiable. In an example operation, the user detector 142 scans for and detects the presence of the wireless proximity devices to identify users within a predetermined or selectable proximity to the smart dispenser 102. The user detector 142 can determine and/or log the user, e.g., via the unique identifier assigned to the wireless proximity device, and in some example embodiments can determine and/or log a distance from the wireless proximity device to the smart dispenser 102, using BLE or other wireless protocols or technologies as will be appreciated by an artisan.

[0040] An example wireless proximity device is a user proximity badge 144 such as shown in Figure 9A, which is embodied in a Bluetooth low-energy (BLE)-equipped badge or tag (BLE badge). The user proximity badge 144 can be wearable or otherwise portable by a user, e.g., as a badge, tag, watch, etc. Example operations herein will be described using a BLE badge, though it will be appreciated that similar operations are possible using BLE tags, other suitable user proximity badges or wearables, Internet-of-things (loT) devices, or other portable wireless devices. [0041] Referring again to Figure 8, the PCB 140 can include a communication device such as a wireless transceiver (or receiver and transmitter) and antenna, a wired input/output interface, or any combination for communicating with a remote computer or processor (remote processor), as explained by example further below. The communication device can be used to transmit data logged by the smart dispenser 100, e.g., by tracking module 120, and receive signals for data, commands, configurations, etc.

[0042] The smart dispenser 100, e.g., tracking module 120, can be configured to conserve battery power by “sleeping” when not processing data, and to periodically wake up using an internal software “heartbeat” and/or to wake up based on external stimulus or programmable sensor alerts. For instance, the tracking module 120 can include, e.g., on the PCB 140, distance-specific motion sensors, timers, and/or on- device alerting mechanisms. In the example smart dispenser 100, a motion sensor 150, such as but not limited to an infrared (IR) emitter/detector, can be provided on the PCB 140 for detecting a presence of a user within the room.

[0043] Motion detection can be used by the smart dispenser 100 to selectively control operation of the wireless scanning performed by the user detector 142. For instance, if the motion sensor 144 detects movement, the smart dispenser 100 can be configured to stay on and to scan periodically (every 30 seconds, as a nonlimiting example) for the wireless proximity device 144 and optionally to record the distance. If no movement is detected, on the other hand, the smart dispenser 100 can be configured to sleep after a predetermined time, as a nonlimiting example 30 minutes. Configuration for smart dispenser features can be provided, e.g., by programming firmware or software (referred to generally as firmware) of the PCB 140, such as for a processor of the PCB.

[0044] An ambient light sensor 152 can alternatively or additionally be provided to detect ambient light. Based on the presence or absence of detected light, the smart dispenser 100 can be configured, for instance, to dynamically decide whether scanning for wireless proximity devices 144 should cease in a darkened room to save battery power.

[0045] One or more dispensing sensors may be provided for detecting when the dispenser pump 110 has been operated (referred to herein as a dispensing event). For instance, an activation sensor 154 on the PCB 140 can be coupled directly or indirectly to an optical sensor such as the optical sensor 116 for detection of hands under dispenser. Alternatively or additionally, as shown in Figures 2-3 and 7, for example, the activation sensor 154 can be coupled directly or indirectly to the motor, e.g., to motor wires of the dispenser pump 110 such as via an FET, to detect that the pump 110 is being powered.

[0046] The smart dispenser 100 may further include one or more features to alert users locally, for instance, alerting the users to activity opportunities such as an opportunity to operate the pump. For instance, the dispenser backpack 120 may include a sound actuator 156 such as a buzzer, sound chip, or other transducer to provide audible alerts (e.g., audio chirps). The sound actuator 156 may be connected to the PCB 140, for instance, at coupling 163. Visual indicators, such as but not limited to an LED (e.g., multi-color LED) or digital display 160, may be provided. Such alert features may be configured locally, and/or remotely, and may actuate in response to local determinations, to determinations made via data aggregation and analytics by a remote processor, or a combination.

[0047] A power source 162, e.g., one or more batteries contained within a battery holder, may be coupled to the PCB 140, e.g., at coupling 163, for powering the PCB and other components of the dispenser backpack 120 and/or the smart dispenser 100.

[0048] The PCB 140 includes a processor and memory 142 for controlling operations and storing data. The processor 142 may be configured, e.g., according to methods provided herein. A programming header 166 is provided for configuring the processor 142. An example firmware and/or software (generally referred to herein as firmware) for the dispensing backpack 120 can be provided, for instance, in executable code stored in the memory, and/or in hardware or firmware. Example executable code is provided as C Code, though other languages may be used.

[0049] Example Tracking Network

[0050] Figure 9B shows an example networked system 180 in a facility, e.g., a room 182 of a hospital. The system 180 includes the smart dispenser 100 in wireless communication (e.g., via BLE, Wi-Fi, UWB, etc.) with the wireless proximity device 144 as well as to a remote processing device (remote processor) 184, e.g., a remotely located computer that communicates with the smart dispenser via a network (LAN, WAN, WLAN, Internet, etc.). The remote processing device 184 can execute one or more applications, e.g., a cloud application such as but not limited to an Amazon Web Service (AWS) Cloud application. The connection to the remote processor 184 may be wired, wireless (e.g., Wi-Fi, cellular, etc.), or a combination. Standard protocols and languages such as but not limited to HTML, C, PHP & MySQL can be used to provide secure data transfer to, e.g., existing enterprise software systems.

[0051] The dispenser backpack 120 in the smart dispenser 100 can provide an automated nerve center for the system 180. The smart dispenser 100 can wirelessly connect (directly or indirectly) to the wireless proximity device(s) 144, for instance, using, e.g., BLE, Wi-Fi, ultrawideband, etc., and can connect (directly or indirectly) to the remote processing device 184 via, e.g., wired, Wi-Fi, cellular, or other wired or wireless networking devices, protocols, and methods, or a combination.

[0052] Example smart dispensers 100 can use, as a nonlimiting example, industry standard secure WIFI networking for exchange of wireless commands and data to and from the remote processing device 184. A secure wireless protocol, for instance, can permit the smart dispensers 100 to be securely integrated to a wireless network 188 for integration with an existing enterprise without affecting operation of existing wireless devices or WIFI networks already in use.

[0053] In an example operation, the smart dispenser 100 detects and identifies users (such as personnel at the facility) within a (e.g., predetermined) distance from the smart dispenser through recognition of the wireless proximity device(s) 144, which are transported by the user(s) in the room 182. For example, the wireless tracker 142 of the dispenser backpack 140 may detect proximity of a user that will allow the person to be identified via the wireless proximity device 144 (e.g., if the wireless proximity device is uniquely identifiable and associated with the user). The optical sensor 116, such as via the activation sensor 154, may be used to confirm that the user’s hands are placed properly in the center of the dispensing pump’s 110 sensing range prior to dispensing fluid. The smart dispenser 100 using the pump 110 dispenses hand sanitization liquid, and the smart dispenser (e.g., the dispenser backpack 120) records or logs (which can include causing to be recorded or logged) the dispensing event (e.g., time/date, person, and location) for monitoring purposes. The user traffic and dispensing patterns can be tracked and/or logged through one or more processorexecutable methods, including but not limited to methods that correlate dispensing activity and/or distance with specific users.

[0054] Each dispensing event may be recorded in the smart dispenser 100 and/or in the remote processor 184. An example remote processor 184 may execute a cloud application such as but not limited to an Amazon Web Service (AWS) Cloud application to perform one or more features of example methods. In an example method for recording or logging a dispensing event, data locally acquired from the user wearing or otherwise carrying the wireless proximity device 144 may be instantly logged by the smart dispenser 100 and/or transmitted to the remote processor 184 for tracking. Activity tracking of the user can incorporate, for instance, the determined distance from the smart dispenser 100, dispensing events (activation of the pump 110), and/or the time since the last dispensing event to analyze sanitization events and potential missed opportunities.

[0055] Steps of example tracking methods may be performed by the smart dispenser 100, the remote processor 184, or a combination. Providing the remote processor 184 to perform tracking or other processing steps can help reduce power consumption by the smart dispenser 100. In some example methods, data for pump dispensing events may be stored locally in memory of the dispenser backpack 140 and transmitted to the remote processor 184, and the remote processor may store the received data, may process the data according to example methods described herein, and/or may transmit one more signals (e.g., command signals or status data) in response for causing the smart dispenser 100 to activate an alert (audible or visible) that provides on-site feedback to the user. Reports based on the processed data can also be provided for access, e.g., via a web-based portal (or portal having another interface) such as a remote, client, or cloud Portal (generally referred to herein as a Client Portal) provided by the remote processor 184.

[0056] Collected data may be encrypted before being stored or transmitted. Example application programming interface (API) data transmission and protocols, for instance, may allow for transmission of data with HTTPS/encryption enabled. A nonlimiting example encryption uses web connection TLS 1 .2 or higher (Certificates of SSL/TSL). Data can be secured to adhere to appropriate security requirements or best practices, examples of which will be appreciated by an artisan. Using an example remote or cloud application, for instance, the remote processing device 184 can record each dispensing event by one or more of user (person), place (room or facility), time/date, and department.

[0057] The smart dispenser 100 may be configured to alert users to activity opportunities locally via audio signals, e.g., chirps from the buzzer 156, and visual signals, e.g., via the LED digital display 160, both of which can be provided on-device. These alerts can be configured locally and/or remotely via data aggregation and analytics within the cloud application.

[0058] Wireless Proximity Device [0059] In operation, an example wireless proximity device embodied in a BLE badge 144 (e.g., as shown in Figure 9A) may transmit a unique identifier such as but not limited to an ID number, which in some example embodiments may be, or be associated with, the user's ID number. The unique identifier can register when in proximity of the smart dispenser 100. For instance, the smart dispenser 100 may be disposed in a patient room such as the room 182 shown in Figure 9B, a common area, or another area of a facility. The smart dispensers 100 can be located within the facility to provide partial or complete facility coverage for reporting and data collection.

[0060] For example, serial numbers on the badge 144 may be provided that correspond with inventory lists for tracking purposes. An example BLE badge is embodied in a BEEKs™ Combo Badge (BLE tag) (HID Global, Austin, TX). Example parameters for a BLE badge are shown for illustration in the table below:

[0061] Dispenser Processor

[0062] Referring again to Figure 8, the processor 164 of the smart dispenser 100, e.g., disposed on the PCB 140 of the dispenser backpack 120, may execute processor- executable instructions stored in memory, which may be embodied in device firmware or combination of firmware and software stored on non-transitory machine-readable media (referred to generally herein as firmware) for performing example operations. The firmware can be configured or adapted for use, e.g., communication, with the wireless proximity devices 144, and with the remote processor 184.

[0063] The smart dispenser 100 can be connected to the remote processor 184 directly or indirectly. For instance, the smart dispenser 100 can be connected to the facility’s WIFI network 188. Using this communication, the smart dispenser 100 can communicate with the remote processor 184, e.g., executing a remote application such as an AWS Cloud application, and may transmit (some or all) dispensing event data and collected user data from the wireless proximity device 144.

[0064] In some example embodiments, the smart dispenser 100 firmware may be initially configured to connect to a facility network (e.g., Wi-Fi network) via an application on a mobile communication device (e.g., phone app), nonlimiting examples of which include an Android or iOS app such as DA16600 Provisioning App. In an example smart dispenser firmware configuration, an initial SSID, password and encryption type may be set via an application so that the smart dispenser can be added to a secure Wi-Fi network.

[0065] The smart dispenser’s 100 firmware configuration may be field updatable over the (e.g., Wi-Fi) network, for instance updated from the remote processor 184 (e.g., via the AWS cloud), as needed. WIFI network or other network configuration updates can be performed, for instance, through a web interface or portal for each smart dispenser, which is then communicated to the built in firmware. [0066] An address, e.g., MAC address, for the smart dispenser 102 may be fixed. In the event of client SSID change, multiple (as a nonlimiting example, up to three) SSIDs and passwords may be provided, e.g., by a client, which may be stored in the dispenser backpack 120 memory and may alternate to maintain persistent connection. SSID and password changes may be submitted for import, e.g., through the Client Portal. Figure 10 shows an example Console Log with an internet protocol (IP) Address Assigned.

[0067] Room Modes

[0068] Example tracking methods may accommodate one or more room types and/or user volume scenarios to optimize efficiency and preserve battery life for the smart dispenser 100.

[0069] For example, an example remote (e.g., web) application such as provided by or accessed from the remote processor 184 may house multiple configurable “room mode” settings which allow users to optimize the smart dispenser 100 for one or more predetermined conditions. Such settings may help preserve battery life and extend the use of the smart dispenser 100. The example remote application, for instance, may communicate settings to the smart dispenser 100 per one or more user updates. The smart dispenser room mode can be configurable, for instance, via the Client Portal.

[0070] Example room modes may be defined at least partly based on one or more alert configuration variables or parameters. As an illustration, example value ranges for alert configuration variables are shown in the table below, where values 0-1 = true/false: Value Ranges:

[0071] Features of illustrative example room modes will now be described with respect to an example medical facility, though it will be appreciated that other modes, rooms, facilities, etc., are possible.

[0072] For a Patient Room mode, persistent active scanning may be performed. A default distance may be set at, as a nonlimiting example, 6 feet, and an audio signal (e.g., a chirp) may be turned off by the client. For instance, a visual alert may be retained, but the audio signal may be deactivated at night. The smart dispenser 100 may transmit data for every BLE 144 and record the distance from the smart dispenser. An example set of default values for a Patient Room mode is shown in the table below:

Default Values - Patient Room:

[0073] A Private Physician Practice mode may include an overnight sleep mode. The motion sensor may be used to detect movement. If no movement is detected, the smart dispenser may be configured to sleep after, say, 30 minutes. If movement is detected, the smart dispenser may be configured to stay on, scanning every 30 seconds (for example) for a BLE badge 144 and record distance. An example set of default values for a Private Physician Practice mode are shown in the table below:

Default Values - Private Physician Practice:

[0074] A Public Dispenser mode may provide use-only recording. The BLE 144 may be scanned upon the use of the dispenser, and the closest person may be recorded. An example set of default values for a Public Dispenser mode is shown in the table below:

Default Values - Public Dispenser:

[0075] One or more audio and visual alert modes may also be configured. For instance, alerts may include high-intensity multi-color (e.g., green and red) LED alerts (blinking, flashing, steady, etc.). An audio alert, e.g., a single audio chirp, can accompany each LED alert. The audio level may be controllable and may be disabled.

[0076] For collecting dispensing data, the firmware can be configured to record all tags, e.g., BLE tags 144 within a defined distance (as a nonlimiting example, 6ft) when a dispensing event occurs. If a dispensing event does not occur, the firmware can be configured to log the users in room, with their distance from the smart dispenser and time. A visual alert (e.g., LED light) and audio alert (e.g., buzzer) can be configured to alert, as a nonlimiting example for 1 second, 5 times or until the dispenser backpack detects liquid being dispensed, though other intervals and number of repeating times are possible.

[0077] The dispensing event or lack thereof can be recorded in the dispenser backpack 120 and transmitted, e.g., via WIFI or other network interface to the remote processor 184, e.g., the AWS Cloud. An example AWS system backend 210 configuration is shown in Figure 11 . Missed Opportunities and Alert Requirements, explained in more detail below, may be determined and/or accessed in the Client Portal, which may be accessed, e.g., by one or more processors for administrators 212 that are connected to the backend 210 via suitable network communication. [0078] The range of the BLE tags 144 may be limited so that the smart dispenser 100 can determine that the BLE tags are present without other BLE interference in the tracking system 180. The firmware may be configured so that the smart dispenser 100 sends signal strength, or an approximation of the distance based on signal strength, to the remote processor 184, e.g., to the AWS system backend 210. The backend 210 may be configured to use the information to determine who would have sanitized their hands based in combination with the number of sanitation events.

[0079] For instance, a threshold can be set to be 6ft (2m) (as a nonlimiting example), so that when the tag 144 is within 6ft of the dispenser 100, it will trigger a configurable alert. The example smart dispenser 100 may use the knowledge that a user is within this range to determine who is in the room 182 (as opposed to, say, being outside of the room). The placement of the smart dispenser 100 can affect the detection. For instance, a metal plate on the rear of the smart dispenser 100 may attenuate signals from behind the smart dispenser to focus detection on BLE badges in front of the dispenser.

[0080] The firmware may be configured (e.g., programmed) to not scan for BLE devices 144 if the light level is too low, e.g., as determined by the ambient light sensor 152, which can save battery when the room 182 is not in use (i.e., dark). Additionally or alternatively, the firmware may be configured (e.g., programmed) to scan only when there is activity in the room, such as detected via the motion sensor 150, which saves battery if there is movement in the room 182 (i.e., no humans present).

[0081] The firmware may also be configured to cause the dispenser backpack 120 to log the wireless proximity device 144 (e.g., proximity tag) ID and time at each instance when the smart dispenser 102 is used, e.g., a dispensing event where the dispensing pump is activated. A successful dispense alert, such as a blue (or other color) LED or other alert provided by the LED display 160, can be configured. The firmware may be configured to send a log to the remote processor 184 at set periods, e.g., every X hours/minutes, if there is not a dispensing event for the dispenser 100 itself. A nonlimiting configurable alert default period may be provided, a nonlimiting example being 4 hours. The remote processor 184, e.g., via the client portal, may be configured to notify the administrator 212 of additional “Missed Opportunities” such as via a dashboard, as shown in more detail below, and/or via email or other messaging.

[0082] The firmware may be configured to provide alerts for the dispenser container’s liquid level determined either locally or via the remote processor 184. For instance, after each pump-cycle dispensing event, the dispenser backpack 120 may log the number of times the dispenser pump 110 had been activated. The available soap level may be decremented by a predetermined amount, which may be configured, e.g., via remote (e.g., AWS) programming. An alert may be generated based on configurable fault condition thresholds. For instance, 25% full = Green LED; 10% = Red LED.

[0083] The firmware may be configured to provide power (e.g., battery) level alerts. The configured dispenser backpack 140 may monitor the battery voltage, e.g., of battery 162, for indications of battery health. When voltage drops below a threshold, e.g., 1.1V during the dispense time or 1.2V when not dispensing, the dispenser backpack 120 may begin to alert for battery replacement. The dispenser usage and voltage monitoring alert may be set, for instance, to fault condition thresholds, such as 25% = Green LED; 10% = Red LED. An ongoing alert, e.g., a yellow LED, may be provided to remind users of low battery with each dispensing event. The remote processor 184, e.g., via the client portal, may be configured to also notify an administrator of battery level via dashboard and/or email.

[0084] The firmware may be configured to provide detector fault alerts, for instance, in the event of a system outage. An administrator may hold a reset button down for a period of time, as a nonlimiting example 5 seconds, and an alert/blink may be generated to show that the smart dispenser 100 is in configuration mode. The administrator could then go back to the configuration app to re-establish a secure connection to the WIFI network or other network.

[0085] Dispenser In-Room User Detection Operation

[0086] Example smart dispenser use cases may be processed using example methods that determine, for instance, wireless proximity device (e.g., BLE tag) 144 presence, successful dispensing events, and lack of dispensing events within a configurable amount of time.

[0087] In example methods, upon installation, the smart dispenser 100 (e.g., including the dispenser backpack 120) may track users on all dispensing events using the wireless proximity devices 144 transported by the users. An example tracking system 180 may detect the incoming presence of a new user or users and then notify the user(s) of the requirement to sanitize or wash their hands using a configurable audio and/or visual alert. The smart dispenser 100 may read the wireless proximity device 144 to capture user data including, for instance, ID key, location approximate to the BLE badge, and time. [0088] For instance, the smart dispenser 100 may use the BLE 144 or other wireless signals to detect the proximity of a user within a specified distance (e.g., 6ft accuracy, though this distance can be greater or lower). In an example operation using uniquely identifiable BLE badges as wireless proximity devices 144, each user’s assigned BLE badge may ping periodically, e.g., once per second. The BLE badge 144 may transmit periodically, e.g., every second, and the smart dispenser 100 may check for pings at an interval, e.g., every 30 seconds. The smart dispenser 100 may capture one or more items of user data, e.g., user ID, location, and time, via BLE connection to the user’s BLE badge 144, and may send user data securely to the remote processor 184, e.g., the AWS Cloud, via WIFI or other network communication.

[0089] The remote processor 184 executing the cloud application or other application may analyze the received user data to identify or recognize one or more user data trends, and may send data resulting from this analysis back to the smart dispenser 100. In response to the received data, as described above, the smart dispenser 100 may then issue an alert (LED flashing light and/or audio, per configuration) for the user to sanitize their hands based on predetermined criteria, e.g., when a threshold is reached.

[0090] The smart dispenser 100 may monitor use of dispensing events using one or more internal sensors. When the pump motor is triggered to dispense liquid, the smart dispenser 100 may register the event (dispensing event). In an example method, the optical sensor 116 for the dispenser pump 110 may detect the presence of a user’s hands, and triggers operation of the pump motor. [0091] Figures 2-3 illustrate example leads (e.g., wires) for the pump 110 extending from the dispenser backpack 120, into the dispenser pump, and into the housing 112 that houses the pump dispenser’s electronics and motor. In the pump 110, for instance, a first, e.g., plastic, connector may be coupled to the pump motor, a second connector (e.g., wires shown in Figure 3) may lead directly into the pump’s circuitry (e.g., pump PCB 140), and a third connector may lead into the PCB 140 inside the dispenser backpack 120. When the pump motor is activated, a power line for the motor (which may be, for instance, integrated in the motor electronics) may be sitting at an elevated voltage (e.g., 5 volts). This may switch on an activation detector, such as an FET, coupled to or integrated with the PCB 140, to indicate a pump dispensing event. The dispenser backpack may also internally monitor battery consumption and can issue an alert when a threshold is reached, as described above.

[0092] Figure 12 shows an example operation 500 of the tracking system 180, which operation may be referred to as an opportunities workflow. In the example operation 500, all user IDs (e.g., identifiable using the wireless proximity device 144) within a configured radius (e.g., a 6ft radius as described above) may be recorded according to dispenser protocols provided herein. Each use of the smart dispenser 100 may be logged, and dispensing events or use events in which the dispenser is activated may be recorded.

[0093] Closest user logic may be applied in example methods to determine which user is using the smart dispenser 100. Successful and missed opportunities may be determined. In an example method, each dispensing event may be associated to the nearest user (identifiable via wireless proximity device 144). [0094] As a nonlimiting example, assume a scenario where there are 4 users and 2 dispensing events. The user detector 142 may scan every 30 seconds. In the example method 500, described in further detail below, users may be checked in and checked out for processing. A first dispensing event (dispensing event 1 ) occurs. If, say, there are 4 users within a 6ft radius, the closest user may be recorded as having used the smart dispenser 100. The other users may be recorded as having a potential missed opportunity depending on a threshold set since their last sanitation event. Thresholds may be configurable, e.g., within the Client Portal, and/or may be determined by the client administrator 212 within set value ranges (30min, 1 hr, 4hr, etc.).

[0095] At the next scan (e.g., 30 seconds later) assume that only 3 users are sensed. If the missing user was determined to have completed a dispensing event within the check-in or check-out window, then it may be logged as a successful opportunity and their user threshold is reset. If not, then it may be logged as a missed opportunity. Dispensing Event 2 then occurs. The closest user logic re-runs, and the scan repeats every 30 seconds.

[0096] In another scenario, assume that a user enters a room and leaves a room with no sanitization event. The user detector 142 may scan every 30 seconds and apply logic, or the users who enter and exit between scans may not be recorded.

[0097] In another scenario, assume that a user is logged as entering a room, but no dispensing event is recorded. A missed opportunity may be logged for the user.

[0098] In another scenario, assume that a user has not had a sanitization event within the threshold. A missed opportunity may be logged, and an alert may be sent to the smart dispenser 100. The user may be prompted for a sanitization event using one or more dispenser backpack alerts. For instance, if a user has not had a sanitization within the set threshold, then the smart dispenser 100 may alert the user visually and/or audially per the backpack’s configuration settings. The alerts may be configured and/or disabled, e.g., within the Client Portal.

[0099] Activity logs may be transmitted. For instance, the remote processing device 184, e.g., executing an application via AWS Cloud or other application, may generate a list of all missed opportunities alerts for users who have not sanitized within the configured threshold. The generated list may be made available to administrators 212 via the Client Portal.

[0100] Referring again to Figure 12, in the example operation 500, the smart dispenser 102 scans a room for users at set intervals, e.g., every 30 seconds at 502. A list of all of the detected users in the room 182 (identified via wireless proximity devices 144) is sent to the backend 210, e.g., through an API call at 504. The backend pulls a list of the users currently checked into the room 182 and compares it with the updated list provided by the smart dispenser at 506. If an existing user has not left the room 182 at 508, and no new user has entered the room at 510, the process (or current iteration) ends at 512. If a new user has entered the room 182 at 510, the new user is then added to the list of users checked into the room at 514. If an existing user has left the room 182 at 508, it is determined at 516 whether the user sanitized their hands before leaving the room. If so, the user is removed from the list of users checked into the room at 518. If not, it is marked as a missed opportunity at 520. The result may be stored, e.g., saved to database (e.g., a relational database (RDS) at 520, and the user may then be removed from the list of users checked into the room at 518. [0101] Liquid and Battery Usage Consumption Monitoring

[0102] Additional example methods that may be performed governing liquid volume and/or battery consumption, e.g., by the remote processing device 184, e.g., executing the AWS cloud application, and/or by the smart dispenser 100, will now be described. For governing liquid volume, the measurement of available liquid (fill levels) may be decremented via configuration (e.g., programming) in response to dispensing (pump) events. As a nonlimiting example, a pump-cycle dispensing event may be standardized so that 0.2 ml is (or is assumed to be) dispensed per event, and the dispenser volume may be standardized so that each filled dispenser container 102 will hold (or is assumed to hold) 33.8 fl oz. Thus, in this example, 33.8 Fluid Ounces (1000ml) I 0.2 ml = 5,000 Successful Dispense Events per fill. An alert may be generated by the smart dispenser 100, e.g., by the dispenser backpack 120 (either locally or in response to a signal from the remote processing device 184) at one or more thresholds, e.g., 3,750 events occurred = 25% Green LED; 4,500 events occurred = 10% Red LED. The countdown may be restarted, for instance, by the administrator 212 resetting it via the Client Portal.

[0103] For monitoring battery consumption, the remote processing device 184 may receive alerts from the smart dispenser 100 (e.g., the dispenser backpack 120) via an API. This API may return a list of all the WIFI networks 188 or other networks for the organization where the dispenser backpack 120 is located. For instance, as explained above, a maximum of three (or more, or fewer) may be held in the smart dispenser 100 for rotating use. [0104] Figures 13-25 show illustrative screenshots for an example client web application portal or other remote application portal (Client Portal) that may be operated using the remote processor 184. Using the example Client Portal, clients, e.g., administrators 212, may log in to an application, e.g., on a cloud service such as AWS Cloud Services 210, for management of the clients’ profile, and/or to add or configure devices or users, determine or configure preferences, pull reporting, etc.

[0105] An example admin console and configuration will now be described. A client portal application may be accessed by the admin users 212, e.g., via a web browser or other suitable interface. The client portal may provide the ability to track accounts or client use of the web application. Accounts may be separated into individual locations/facilities.

[0106] The example client portal may be used to recognize and manage devices, including smart dispensers, wireless proximity device, etc., that are added to a client’s network. The smart dispenser 100 may be set to a particular SSID and password default via an app such as a phone app, as explained above, or in other ways, so that the device can be added to the client network. The WIFI or other network configuration can be updated, for instance, through the Client Portal for each dispenser backpack 120.

[0107] As explained above, the address, e.g., MAC address, for devices such as smart dispensers 100 or dispenser backpacks 120 may be fixed. In the event of a client SSID change, the client, e.g., admin 212, may provide up to a certain number (e.g., three) of SSIDs and passwords which can be stored in the dispenser backpack memory. These may alternate to maintain persistent connection. The client may submit SSID and password changes for mass import through the AWS cloud 210. The client portal may also be used to initiate or enable firmware update to smart dispensers 100.

[0108] Users to be logged and tracked may be tied to a facility such as the facility 182, with some users tied to multiple facilities. An example tracking system 180 may work in multiple facilities as users travel from one to the other, e.g., among multiple hospitals within a same hospital group. In this way, users can use the same BLE badge 144 to be tracked and reported on no matter the facility within the hospital system. The Client Portal may have various admin user profiles and hierarchy, e.g., for system admin, servicer admin, support, organization admin, supervisors, etc., with various restrictions as to access, reports, device settings and configurations, etc. Secure login and passwords may be provided.

[0109] In an example admin and/or user profile page for the Client Portal, user data may be viewable, configurable, and/or editable by a client, e.g., via request. Example data may include but is not limited to: name, email, organization, department, role, employee number, BLE tag 144 assigned, mobile, set up date, status (active, deactivated, deleted), etc. Data may be uploaded to the cloud application using any of various file types and/or formats.

[0110] Example client alerts and notifications may include two-way communication, in which the cloud 210, e.g., via an API, may communicate back to the smart dispenser 100 to generate an alert, e.g., a light up or chirp as describe herein. Notifications may be enabled/disabled through a user interface (Ul). Example notifications may be embodied in, e.g., email or messages to administrators 212 and/or to the user. [0111] The example cloud or client portal may produce one or more alerts to track hand sanitization compliance periodically, e.g., every 4 hours. For instance, the smart dispenser 100 may send an alert to a III if no dispensing event has been recorded in a period of, say, 4 hours. Once the smart dispenser 100 sends data on a hand sanitization event to the AWS cloud 210, the cloud application may review all user hand sanitizing events in the same period (e.g., past 4 hours) and alert the user via the Ul/smart dispenser 100 of the need for hand sanitization as provided in methods described above.

[0112] As explained above, the example cloud application or client portal may produce alerts for smart dispenser battery power levels. Alerts at 25% and 10% power, for instance, may be generated per API calls from the dispenser backpack. A reset option may be provided for the client. Further, the example cloud application or client portal may produce alerts for sanitizing liquid levels. Alerts at 25% and 10% levels may be generated according to example methods described above. A reset option may be provided for the client.

[0113] As explained above, the cloud application or client portal can further be configured to generate reports. For example, data communicated from the smart dispenser 100 can be reported such as one or more of: location; data captured by user; time; user’s last dispensing event; dispenser setting types; low battery; and/or low liquid level.

[0114] Figures 13-14 show example client portal dashboards. Figures 15-25 show example client portal screenshots providing example data for: administration (Figure 15, Admin Users; Figure 16, Device Type; Figure 17, Event Type; Figure 18, Organization Type); Management (Figure 19, Organization; Figure 20, Device Data; Figure 21 ; Users); and reports (Figure 22; Dispensation Activities; Figure 23, Device Status; Figure 24, Missed Opportunities; Figure 25, Sanitization).

[0115] As shown by example in Figures 13-25, data relating to dispenser events may be reported, such as but not limited to: o User lists

■ Determined active and inactive users

■ Date of set up

■ Date user was inactive, and by whom and when o Deleted users

■ Date when account was set up

■ Deleted, and by whom and when o User event data

■ Time

■ Distance

■ Location of the dispenser used o Dispenser use:

■ User of each dispenser

■ Location

■ Time Distance of user from dispenser o Location

■ Dispenser location and dispenser name in WIFI (or other network) set up correlation o Compliance

■ Users who sanitized every four hours (or other period)

■ Users that don’t use dispensers every 4 hours (or other period)

■ Users who miss not sanitizing when enter or a room o Liquid (e.g., sanitization liquid) related data (third parties, such as vendors, may be granted some access via an API for fulfillment and shipment confirmation)

■ Track purchased units of liquid and manage inventory

■ Track expiration dates of liquid received

[0116] One or more of the above data points may be aggregated and combined into various configurable dashboards for easy reference, as shown by example in Figures 13-25. Aggregated items that may be depicted by example dashboards include, but are not limited to:

• Dispensers (e.g., all dispensers) with low battery

• Dispensers (e.g., all dispensers) with low liquid levels

• Dispensers Online (e.g., all dispensers online)

Liquid Refill Inventory Missed Opportunities: Daily, Weekly, Monthly, MOM, 6 (or other number of) months (e.g., to align with compliance standards and expectations)

• Facility Percent in compliance: Monthly, MOM, Annual (e.g., to align with compliance standards and expectations)

• User Percent in compliance (e.g., to align with compliance standards and expectations)

[0117] General

Example embodiments of the invention provide, among other things, a tracking module for tracking one or more dispensing events for one or more user using a liquid dispenser, comprising a processor; a user detector coupled to the processor for wirelessly communicating with one or more wireless proximity devices to track a user within a proximity of the tracking module; and a dispensing sensor for detecting when a dispensing pump of the liquid dispenser has been activated. The processor may be configured to log, or cause to be logged, at least one dispensing event including received data from the wireless proximity device in response to detecting that the dispensing pump has been activated. In addition to any of the above features in this paragraph, the tracking module may further comprise a housing, which may be provided by, or configured to be integrated in or with or connected to a housing of the liquid dispenser. In addition to any of the above features in this paragraph, the housing may be embodied in a dispenser backpack for connecting to the housing of the liquid dispenser. In addition to any of the above features in this paragraph, the tracking module may further comprise circuitry disposed within the housing. In addition to any of the above features in this paragraph, the tracking module may further comprise a power supply for powering operation of the tracking module. In addition to any of the above features in this paragraph, the processor may be configured for controlling operation of the tracking module. In addition to any of the above features in this paragraph, some or all of the one or more wireless proximity devices may be identifiable, uniquely identifiable. In addition to any of the above features in this paragraph, the tracking module may further comprise: a communication device for transmitting data logged by the processor to a remote processing device and to receive input signals. In addition to any of the above features in this paragraph, the input signals may represent one or more of commands, data, or configuration. In addition to any of the above features in this paragraph, the tracking module may further comprise a housing that may be embodied in a dispenser backpack for connecting to a housing of the liquid dispenser. In addition to any of the above features in this paragraph, the tracking module may further comprise a housing that may be configured for attachment to a mounting surface. In addition to any of the above features in this paragraph, the tracking module may comprise circuitry including a PCB. In addition to any of the above features in this paragraph, the wireless proximity device may comprise a Bluetooth Low Energy (BLE) device. In addition to any of the above features in this paragraph, the BLE device may comprise a tag, badge, and/or a wearable device. In addition to any of the above features in this paragraph, the tracking module may further comprise a motion sensor for determining a presence of a user within a facility. In addition to any of the above features in this paragraph, the tracking module may further comprise an ambient light sensor. In addition to any of the above features in this paragraph, the tracking module may be configured to activate or deactivate the tracking of the user in response to the determined presence of the user and/or detection of ambient light. In addition to any of the above features in this paragraph, the tracking module may further comprise: a visible alert display; and/or an audible alert generator. In addition to any of the above features in this paragraph, the tracking module may further comprise a communication device for transmitting data logged by the processor to a remote processing device and to receive input signals. In addition to any of the above features in this paragraph, the tracking module may be configured to generate an alert in response to a command from the remote processing device.

[0118] Additional embodiments of the invention provide a tracking system for a liquid dispenser comprising: a tracking module according to the above paragraph; at least one wireless proximity device; and a remote processing device in communication with the tracking module. Additional embodiments of the invention provide a liquid dispenser comprising: a housing; a liquid container; a dispenser pump; and a tracking module according to the above paragraph. Additional embodiments of the invention provide a tracking system for a liquid dispenser comprising: a liquid dispenser according to this paragraph; at least one wireless proximity device; and a remote processing device in communication with the tracking module. In addition to any of the above features in this paragraph, the remote processing device may comprise a computer executing a real-time, cloud-based software system. In addition to any of the above features in this paragraph, the remote processing device may be accessible by at least one admin via a web-based portal. In addition to any of the above features in this paragraph, the tracking module may communicate with the remote processing device via a secure connection. [0119] Additional embodiments of the invention provide a remote processing device including a processor and memory and configured using computer-readable instructions to: receive data logged by the processor of the tracking module according to any of the above paragraphs; analyze the received data to determine one or more activity opportunities and/ or missed opportunities; and transmit one or more signals to the tracking module in response. In addition to any of the above features in this paragraph, the transmitted signals may represent one or more of data, commands, or configurations. In addition to any of the above features in this paragraph, activity opportunities may comprise opportunities to operate the dispensing pump, and missed opportunities may comprise instances in which the pump was not operated by a detected user. In addition to any of the above features in this paragraph, the remote processing device may be further configured to generate one or more reports based on the analyzing and providing the generated reports to one or more admin clients via a web portal. In addition to any of the above features in this paragraph, the generated reports may be delivered via a reporting format. In addition to any of the above features in this paragraph, the generated reports may be delivered via a displayed dashboard. In addition to any of the above features in this paragraph, the tracking module and/or the remote processing device may be configured to monitor a power supply within the circuitry of the tracking module and/or the dispenser pump. In addition to any of the above features in this paragraph, the remote processing device may be configured to cause the tracking module and/or the liquid dispenser to generate one or more alerts. In addition to any of the above features in this paragraph, the remote processing device may be configured to generate one or more alerts via the web portal and/or via messaging or email.

[0120] Additional embodiments of the invention provide a method for tracking a user of a liquid dispenser as shown and described herein.

[0121] Additional embodiments of the invention provide a dispenser backpack as shown and described herein.

[0122] Additional embodiments of the invention provide a liquid dispenser including a dispenser backpack as shown and described herein.

[0123] Any of the above aspects and embodiments can be combined with any other aspect or embodiment as disclosed here in the Summary, Figures and/or Detailed Description sections.

[0124] As used in this specification and the claims, the singular forms “a,” “an” and “the” include plural referents unless the context clearly dictates otherwise.

[0125] Unless specifically stated or obvious from context, as used herein, the term “or” is understood to be inclusive and covers both “or” and “and”.

[0126] Unless specifically stated or obvious from context, as used herein, the term “about” is understood as within a range of normal tolerance in the art, for example within 2 standard deviations of the mean. About can be understood as within 20%, 19%, 18%, 17%, 16%, 15%, 14%, 13%, 12%, 11 %, 10%, 9%, 8%, 7%, 6%, 5%, 4%, 3%, 2%, 1 %, 0.5%, 0.1 %, 0.05%, or 0.01 % of the stated value. Unless otherwise clear from the context, all numerical values provided herein are modified by the term “about.” [0127] Unless specifically stated or obvious from context, as used herein, the terms “substantially all”, “substantially most of”, “substantially all of” or “majority of” encompass at least about 90%, 95%, 97%, 98%, 99% or 99.5%, or more of a referenced amount of a composition.

[0128] The entirety of each patent, patent application, publication and document referenced herein hereby is incorporated by reference. Citation of the above patents, patent applications, publications and documents is not an admission that any of the foregoing is pertinent prior art, nor does it constitute any admission as to the contents or date of these publications or documents. Incorporation by reference of these documents, standing alone, should not be construed as an assertion or admission that any portion of the contents of any document is considered to be essential material for satisfying any national or regional statutory disclosure requirement for patent applications. Notwithstanding, the right is reserved for relying upon any of such documents, where appropriate, for providing material deemed essential to the claimed subject matter by an examining authority or court.

[0129] It should be understood that one or more steps within a method may be executed in different order (or concurrently) without altering the principles of the present disclosure. Further, although each of the embodiments is described above as having certain features, any one or more of those features described with respect to any embodiment of the disclosure may be implemented in and/or combined with features of any of the other embodiments, even if that combination is not explicitly described. In other words, the described embodiments are not mutually exclusive, and permutations of one or more embodiments with one another remain within the scope of this disclosure.

[0130] Modules or processors may include one or more interface circuits. In some examples, the interface circuits may include wired or wireless interfaces that are connected to a local area network (LAN), the Internet, a wide area network (WAN), or combinations thereof. The functionality of any given module or processor of the present disclosure may be distributed among multiple modules or processors that are connected via interface circuits. For example, multiple modules may allow load balancing. In a further example, a server (also known as remote, or cloud) module or processor may accomplish some functionality on behalf of a client module. Each module may be implemented using code. The term code, as used above, may include software, firmware, and/or microcode, and may refer to programs, routines, functions, classes, data structures, and/or objects.

[0131] The term memory circuit is a subset of the term computer-readable medium. The term computer-readable medium, as used herein, does not encompass transitory electrical or electromagnetic signals propagating through a medium (such as on a carrier wave); the term computer-readable medium may therefore be considered tangible and non-transitory. Non-limiting examples of a non-transitory, tangible computer-readable medium are nonvolatile memory circuits (such as a flash memory circuit, an erasable programmable read-only memory circuit, or a mask read-only memory circuit), volatile memory circuits (such as a static random access memory circuit or a dynamic random access memory circuit), magnetic storage media (such as an analog or digital magnetic tape or a hard disk drive), and optical storage media (such as a CD, a DVD, or a Blu-ray Disc).

[0132] The systems and methods described herein may be partially or fully implemented by a special purpose computer created by configuring a general-purpose computer to execute one or more particular functions embodied in program code of computer programs. The functional blocks, flowchart components, and other elements described above serve as software specifications, which may be translated into program code of the computer programs by the routine work of a skilled technician or programmer.

[0133] The program code of the computer programs includes processor-executable instructions that are stored on at least one non-transitory, tangible computer-readable medium. The program code of the computer programs may also include or rely on stored data. The program code of the computer programs may encompass a basic input/output system (BIOS) that interacts with hardware of the special purpose computer, device drivers that interact with particular devices of the special purpose computer, one or more operating systems, user applications, background services, background applications, etc.

[0134] The program code of the computer programs may include: (i) descriptive text to be parsed, such as HTML (hypertext markup language), XML (extensible markup language), or JSON (JavaScript Object Notation) (ii) assembly code, (iii) object code generated from source code by a compiler, (iv) source code for execution by an interpreter, (v) source code for compilation and execution by a just-in-time compiler, etc. As examples only, source code may be written using syntax from languages including C, C++, C#, Objective C, Swift, Haskell, Go, SQL, R, Lisp, Java®, Fortran, Perl, Pascal, Curl, OCaml, Javascript®, HTML5 (Hypertext Markup Language 5th revision), etc.

[0135] Modifications may be made to the foregoing without departing from the basic aspects of the invention. Although the invention has been described in substantial detail with reference to one or more specific embodiments, those of ordinary skill in the art will recognize that changes may be made to the embodiments specifically disclosed in this application, and yet these modifications and improvements are within the scope and spirit of the invention. The invention illustratively described herein suitably may be practiced in the absence of any element(s) not specifically disclosed herein. Thus, for example, in each instance herein any of the terms "comprising", "consisting essentially of", and "consisting of" may be replaced with either of the other two terms. Thus, the terms and expressions which have been employed are used as terms of description and not of limitation, equivalents of the features shown and described, or portions thereof, are not excluded, and it is recognized that various modifications are possible within the scope of the invention. Embodiments of the invention are set forth in the following claims.

[0136] A number of embodiments of the invention have been described. Nevertheless, it can be understood that various modifications may be made without departing from the spirit and scope of the invention. Accordingly, other embodiments are within the scope of the following claims.