Using baseline calibration to track hydration

Abstract

Various embodiments include methods and electronic devices for tracking hydration of a user. Embodiments can include determining an amount of liquid consumed by a user based on a predetermined baseline consumption rate of the user and a number of sips or swallows detected by a sensor, and reporting an indication of a determined hydration level of the user based on the determined amount of liquid consumed. Some embodiments include determining a predetermined baseline consumption rate of a user based on previous counted sips or swallows detected by a sensor or input by the user when the user consumed a known amount of liquid. Some embodiments include selecting a predetermined baseline consumption rate of a user based on a determined type of liquid consumed. Some embodiments include determining a hydration level of a user further based on a context of drinking by the user and / or a type of liquid consumed.

Description

BACKGROUND

[0001] Proper hydration helps maintain body temperature, flushes waste, lubricates joints, and is beneficial to overall health. In addition, adequate hydration can improve sleep quality, cognition, and mood. For professional athletes, hydration is critical to optimal athletic performance. While many people are aware of the importance of proper hydration, it can be difficult for people to know if they are consuming the appropriate amount of fluids each day, especially for those who are busy or elderly who are beginning to lose their sense of thirst. In addition, while some people attempt to manually track their fluid consumption, this can be cumbersome and prone to inaccurate data entry, especially when the people are busy or prone to forgetting to enter their fluid intake each time. SUMMARY

[0002] Aspects include methods for tracking hydration of a user and computing devices implementing the methods executed by a processor of an electronic device. Aspects can include determining an amount of liquid consumed by a user based on a predetermined baseline consumption rate of the user and a number of at least one of sips or swallows detected by a sensor coupled to the processor, and reporting an indication of a determined hydration level of the user based on the determined amount of liquid consumed.

[0003] Some aspects can include determining the predetermined baseline consumption rate of the user based on a number of previous counts of at least one of sips or swallows detected by the sensor when a known amount of liquid was consumed by the user. Some aspects can include determining the predetermined baseline consumption rate of the user based on a manual user input indicating at least one of the known amount of liquid or a number of sips or swallows required to consume the known amount of liquid. Some aspects can include determining the predetermined baseline consumption rate of the user based on a context in which the liquid was consumed.

[0004] Some aspects can further include determining a type of liquid consumed, and selecting the predetermined baseline consumption rate of the user based on the determined type of liquid consumed.

[0005] Some aspects can further include determining an update to a previously determined baseline consumption rate of the user based on liquid consumption information from at least one of the sensor, a user input, or a context in which the liquid was consumed, wherein the predetermined baseline consumption rate is based on the determined update to the previously determined baseline consumption rate of the user.

[0006] Some aspects may further include receiving contextual information indicating a context in which the user took at least one of the number of sips or swallows, and determining a hydration level of the user based further in part on the context in which the user took at least one of the number of sips or swallows. Some aspects may further include determining whether the user consumed solids along with the amount of liquid consumed, wherein, in response to determining that the user consumed solids along with the liquid, determining the amount of liquid consumed by the user is based on the number of sips by the user.

[0007] Some aspects may further include receiving an indication of a type of fluid consumed by the user, wherein determining the user's hydration level based on the determined amount of fluid consumed is further based on the type of fluid consumed by the user. In these aspects, the received indication of the type of fluid consumed by the user may indicate that the fluid consumed by the user includes at least one of a diuretic or a dehydrating substance, and determining the user's hydration level based on the determined amount of fluid consumed may include adjusting the hydration level down due to the diuretic or dehydrating substance indicated in the received indication. In these aspects, the received indication of the type of fluid consumed by the user may indicate that the fluid consumed by the user includes an antidiuretic, and determining the user's hydration level based on the determined amount of fluid consumed may include adjusting the hydration level up if no antidiuretic is indicated.

[0008] Some aspects may further include receiving food consumption information associated with food consumed by the user, and determining a hydration level of the user based further in part on the received food consumption information.

[0009] Other aspects include an electronic device including a processor configured with processor-executable instructions to perform the operations of any of the methods reviewed above. Other aspects include a non-transitory processor-readable storage medium having stored thereon processor-executable software instructions configured to cause the processor to perform the operations of any of the methods reviewed above. Other aspects include a processing device for use in an electronic device, the processing device configured to perform the operations of any of the methods reviewed above. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate exemplary embodiments and, together with the general description given above and the detailed description given below, serve to explain features of the various embodiments.

[0011] Figure 1 is a schematic diagram illustrating an electronic device in the form of a user device for tracking a user's hydration in conjunction with a wearable device according to various embodiments.

[0012] Figure 2 is a block diagram illustrating components of an example system in a package for an electronic device in accordance with various embodiments.

[0013] Figure 3 is a component block diagram of an example system configured for execution by a processor of an electronic device to ensure that a user receives scheduled notifications.

[0014] Figure 4A 、 Figure 4B 、 Figure 4C 、 Figure 4D 、 Figure 4E 、 Figure 4F 、 Figure 4G 、 Figure 4H 、 Figure 4I and / or Figure 4J A process flow diagram illustrating an example method performed by a processor of an electronic device for tracking hydration of a user in accordance with various embodiments is shown.

[0015] Figure 5 is a flow diagram of a process for tracking hydration by monitoring only the fluid consumed by a user, according to various embodiments.

[0016] Figure 6 is another process flow diagram for tracking hydration by monitoring both fluids and solids consumed by a user in accordance with various embodiments.

[0017] Figure 7 is a component block diagram of a network computing device suitable for use with various embodiments.

[0018] Figure 8 is a component block diagram of a wireless computing device suitable for use with various embodiments.

[0019] Figure 9 is a component block diagram of an example of smart glasses suitable for use with various embodiments. DETAILED DESCRIPTION

[0020] The various aspects will be described in detail with reference to the accompanying drawings. Throughout the drawings, the same reference numerals are used to refer to the same or similar parts as much as possible. Reference to specific examples and embodiments is for illustrative purposes only and is not intended to limit the scope of the various aspects or claims.

[0021] Various embodiments provide a method for tracking hydration of a user, performed by a processor of an electronic device. Various embodiments may determine an amount of fluid consumed by the user based on a predetermined baseline consumption rate of the user and a number of at least one of sips or swallows of the user detected by a sensor coupled to the processor in response to determining that a received indication of consumption by the user involves drinking fluid. Furthermore, a hydration level of the user may be determined based on the determined amount of fluid consumed.

[0022] As used herein, the term "hydration level" refers to the percentage of water or body fluids in a user's body. Ideal hydration levels can vary based on many factors (e.g., age, gender, weight, exercise level, activity level, etc.). Generally speaking, women require less hydration than men. For example, the ideal hydration percentage for an adult woman may fluctuate between 45% and 60% of total body weight, while the ideal hydration percentage for an adult man may be between 50% and 65% of total body weight. For an athletic body type, the ideal hydration level may need to be 5% higher than the average adult range.

[0023] As used herein, the term "electronic device" refers to an electronic device that is equipped with at least a processor and memory configured with a contact database. Furthermore, the term "user device" as used herein refers to a specific type of electronic device from which a user can receive notifications. Electronic devices comprising user devices may include cellular phones, smartphones, portable computing devices, personal or mobile multimedia players, laptop computers, tablet computers, 2-in-1 laptop / desktop computers, smartbooks, ultrabooks, handheld computers, wireless email receivers, multimedia internet-enabled cellular phones, wearable devices (including smartwatches, smart glasses, headphones (e.g., headphones or earbuds), smart contact lenses), augmented / virtual reality devices, entertainment devices (e.g., wireless game controllers, music and video players, satellite radio, etc.), exercise equipment, and similar electronic devices that include memory and a programmable processor. In various embodiments, the electronic device may be configured with memory and / or storage. Furthermore, the electronic devices mentioned in various example embodiments may be coupled to or include wired or wireless communication capabilities that implement the various embodiments, such as (one or more) network transceivers and (one or more) antennas configured to communicate with a wireless communication network.

[0024] As used herein, the term "smart" in conjunction with a device refers to a device that includes a processor for automatic operation, for collecting and / or processing data, and / or that can be programmed to perform all or part of the operations described with respect to the various embodiments herein, for example, a smartphone, smart glasses, smart contact lenses, a smart watch, a smart ring, a smart necklace, a smart cup, a smart straw, a smart appliance, etc.

[0025] The term "system on chip" (SOC) as used herein refers to a single integrated circuit (IC) chip that contains multiple resources and / or processors integrated on a single substrate. A single SOC may contain circuits for digital, analog, mixed-signal, and radio frequency functions. A single SOC may also include any number of general-purpose and / or special-purpose processors (digital signal processors, modem processors, video processors, etc.), memory blocks (e.g., ROM, RAM, flash memory, etc.), and resources (e.g., timers, voltage regulators, oscillators, etc.). The SOC may also include software for controlling the integrated resources and processors and for controlling peripheral devices.

[0026] The term "system-in-package" (SIP) may be used herein to refer to a single module or package that contains multiple resources, computing units, cores, and / or processors on two or more IC chips, substrates, or SOCs. For example, a SIP may include a single substrate on which multiple IC chips or semiconductor dies are stacked in a vertical configuration. Similarly, a SIP may include one or more multi-chip modules (MCMs) on which multiple ICs or semiconductor dies are packaged into a unified substrate. A SIP may also include multiple independent SOCs that are coupled together via high-speed communication circuits and packaged in close proximity to each other, such as on a single motherboard or in a single wireless device. The proximity of the SOCs facilitates high-speed communication and the sharing of memory and resources.

[0027] Various embodiments use one or more electronic devices, such as one or more sensor-equipped wearable electronic devices (also referred to herein as "wearable devices") or other sensor-equipped electronic devices, to measure activities associated with personalized water drinking rates and eating behaviors to automatically track total fluid consumption and determine a user's hydration level. Sensors can be used to detect certain user behaviors that are associated with drinking, eating, or other activities and / or conditions. Various sensors can be used to detect drinking behavior by analyzing video images of what the user consumes, as well as detecting other indicators such as sounds, vibrations, muscle activity, and / or changes in ear pressure when the user sips and / or swallows. For example, to distinguish between liquid intake and solid food intake, motion sensors can be used to detect jaw movement, and / or electromyography can be used to monitor jaw muscle activity during swallowing, such as to distinguish between liquid intake and solid food (chewing before swallowing). Additionally or alternatively, a wearable camera can be used to capture images of what the user consumes for analysis. Cameras and / or gas chemical sensors can identify different types of liquids (e.g., coffee, alcohol, juice, water, soda, etc.), solids, and / or combinations thereof. Thermal imaging cameras can measure ambient temperature, the temperature of consumables, the volume of containers holding liquids versus empty volume (i.e., due to the temperature difference between the air and liquid contents), and more.

[0028] Certain types of liquids, such as alcohol or coffee, can either dehydrate the body due to diuretic effects, or keep the body hydrated due to anti-diuretic effects. Thus, in addition to determining the total amount of liquid consumed, detection of diuretic and / or anti-diuretic consumption can be used to adjust the determined total hydration level of the user.

[0029] Sensors can be used to collect information useful for estimating the amount and type of liquid consumed can be incorporated into mobile electronic devices, such as smartphones and tablets, as well as wearable devices, such as a pair of smart glasses, earphones (e.g., headphones or earbuds), other head-worn devices, a necklace, a chest band, a watch, a bracelet, other wrist-worn devices, a smart ring, and / or other wearable electronic devices. In addition, sensors can be incorporated into remote sensing devices, such as smart home appliances or dedicated remote sensors.

[0030] In addition to the time of liquid intake and the type of liquid, various embodiments can more accurately measure and track the amount of liquid consumed by a user by developing, maintaining, and using a baseline consumption rate for the amount of liquid intake per sip and / or swallow by the individual. For example, the individual can be subjected to controlled liquid intake measurements and recorded through a calibration or learning process, where the user drinks a predetermined amount of liquid, and the sensor calculates how many sips and / or swallows the user takes to consume that predetermined amount of liquid, possibly under different conditions (e.g., different temperatures, time of day, liquid type, amount of activity, etc.). Calibration can further involve ingesting different types of liquids, thereby potentially establishing different baseline consumption rates for each type of liquid. This controlled liquid intake measurement uses active participation and input from the user, and is therefore referred to herein as “active baselining.” Active baselining can be particularly useful for initially determining how much the user consumes on average per sip or swallow. Active baselining can also help determine how many swallows the user takes on average per sip, or vice versa. Establishing an active baseline can be useful in situations where the sensor cannot detect or cannot accurately detect what liquid or how much liquid the user is consuming.

[0031] While a previously determined (i.e., predetermined) baseline consumption rate is useful when the sensor cannot accurately detect what liquid is being consumed or how much liquid is being consumed, sometimes the sensor is able to accurately measure liquid consumption. Therefore, instead of using a predetermined baseline consumption rate measurement, various embodiments may use only or primarily sensor measurements to determine how much liquid has been consumed. In addition, when the sensor is able to accurately measure liquid consumption, the processor can use this measurement of liquid consumption to determine, verify, and / or update the baseline consumption rate without the user having to manually or actively input information about what has been consumed, which is referred to herein as "passive baseline." Passive baselines can be useful when the sensor is able to reliably measure and determine what liquid the user is consuming or how much liquid they are consuming. For example, if the user is accustomed to drinking the same drink every day, or drinking from a can or bottle with a defined volume, a transparent glass or smart cup that provides a reliable measurement of the amount of liquid consumed. In this way, once an active baseline is established for the user, passive baselines can provide continuous calibration or refinement of the baseline to more accurately estimate the user's total hydration.

[0032] Various embodiments can analyze what the user consumes to determine whether the user is consuming solid food, liquid, something in between (e.g., yogurt), or a combination thereof. In addition to liquid intake, the water in food also tends to contribute 20%-30% of an individual's total water intake. Because the water content of food varies greatly and people have different eating habits, the amount of water obtained from food may vary from person to person, which will affect their overall hydration level. Therefore, various embodiments can monitor (e.g., using a camera on a wearable device) and take into account the quantity and type of food consumed by the user (e.g., vegetables, fruits, fish, meat, grains, etc.). Using a lookup table or database, an average water content can be determined for the quantity and type of food detected. In the event that the food type cannot be automatically detected, various embodiments can receive manual input from the user to identify the food being consumed. By analyzing the user's eating patterns, the electronic device can provide user suggestions and feedback to help the user achieve appropriate and / or better hydration.

[0033] Various embodiments may additionally apply contextual analysis to more accurately determine a user's current hydration level. Contextual analysis may be used to refine baseline measurements, thereby increasing the accuracy of how much fluid a user has consumed and how much fluid they are likely to retain in a given context. For example, various embodiments may consider exercise perspiration as well as external temperature and humidity when estimating a user's hydration level. Thus, the processor may consider all information received from the sensors, i.e., not only how much fluid has been consumed, but also how much fluid has been lost or not retained, in order to determine overall hydration.

[0034] Figure 1The user 5 is shown in action consuming various embodiments of a liquid 25 while various sensors take measurements that are processed by an electronic device in the form of a user device 110 to estimate the user's hydration level. The user device 110 is shown in the form of a cellular telephone (i.e., a smartphone), but other forms of electronic devices (e.g., tablets, personal computers, fitness equipment, etc.) may also be used. Various devices with sensors include wearable devices such as smart glasses 130, a sensor-equipped neckband 150, a smart watch 170, and headphones 180. The user device 110 can be configured to communicate with a remote computing device (e.g., a server 195) via a wireless connection 125 (e.g., Wi-Fi, Bluetooth, cellular, etc.) over a wireless network 190, which can be supported by a wireless local area network router (not shown), such as a Wi-Fi wireless router or a cellular network base station.

[0035] In various embodiments, the user device 110 may determine the amount of liquid 25 consumed by the user 5 in response to determining that the indication of consumption received from the sensor by the user 5 involves drinking the liquid. In some embodiments, the user device (or other electronic device) may determine the amount of liquid consumed based on a predetermined baseline consumption rate for the user 5 and a number of sips and / or swallows by the user 5, where the number of sips and / or swallows by the user 5 is detected based on data provided by one or more sensors, such as smart glasses 130, a sensor-equipped neckband 150, and a smartwatch 170. Indications of liquid consumption, sips and / or swallows, may be determined by the user device 110 by correlating information from one or more sensors (e.g., wearable devices) with swallowing patterns determined during calibration.

[0036] Smart glasses 130 are in the form of wearable devices that may include a built-in camera 135 and a heads-up display or augmented reality feature on or near the front lens 131. Like other sensor devices that provide information to the user device 110, smart glasses 130 can collect information from external sensors, such as a head-mounted camera 135 with a field of view 136, an electromyogram (e.g., in the arms of the frame), a microphone, a thermometer, and / or internal sensors such as an inertial measurement unit (IMU), proximity / motion sensors, light sensors, lidar, gas sensors, and the like. An electromyogram can detect muscle movements associated with sipping or swallowing. A microphone can detect the sounds of sipping and / or swallowing, as well as the sounds made by some carbonated beverages (particularly when opened). A thermometer can record the user's temperature and / or the ambient temperature around the user 5, which can provide contextual information relevant to determining the user's overall hydration level. When a user is very hot, the user may take larger sips (gulps) of liquids. Similarly, when the air temperature is higher, the user may drink water more quickly. Therefore, based on a previous calibration for the user, the estimated amount of liquid consumed per sip can be adjusted based on the user's temperature and / or the ambient temperature. Furthermore, sensors such as a laser thermometer or thermal imaging camera (not shown) can be used to detect the temperature of food and / or liquid consumed by the user 5. Users who consume very hot or very cold food or liquid tend to consume smaller amounts. Therefore, the estimated amount of liquid consumed per sip can be adjusted based on the temperature of the substance being consumed. Thus, the user's temperature, the ambient temperature, and / or the temperature of the food or liquid being consumed can provide contextual information relevant to determining the user's consumption and, therefore, their overall hydration level. The IMU can detect the drink 25 or food being presented to the mouth and the tilt angle of the glass 20 and the wearer's head, which can be used to determine the remaining contents of the container and / or the size of the sip, thereby determining how much has been consumed. A gas sensor can detect the type of food or liquid consumed. The smart glasses 130 can support wireless technologies such as Bluetooth or Wi-Fi, enabling communication via a wireless communication link 125, such as to the user device 110 and / or other wearable devices (e.g., 150, 170). Additionally, smart glasses 130 may control or retrieve data from other wearable devices (eg, 150 , 170 ) and / or remote computing devices ( 110 , 195 ).

[0037] Various sensors such as camera 135 can image a drink 25 (i.e., a liquid) or food (i.e., a solid and / or a mixture of solids and liquids) being delivered to the mouth (e.g., in a glass 20) to enable image processing to determine the type of drink or food being consumed, how much has been consumed, and possibly how much liquid has not been consumed (e.g., by measuring the remaining contents of the container).

[0038] In some embodiments, the smart glasses 130 can operate independently with a mobile operating system and can provide feedback to the user 5 through an augmented reality or heads-up display on the front-facing lens 131, through auditory or haptic feedback if available, and / or through a wireless communication link 125 to other electronic devices.

[0039] The sensor-equipped neckband 150 can be in the form of a necklace, a choker, or other neck-worn apparel / jewelry. The sensor-equipped neckband 150 can collect information from external sensors, such as a pressure sensor 151 and / or a neck-mounted camera 155, microphone, and / or internal sensors, such as an IMU, proximity / motion sensor, gas sensor, etc. The sensor-equipped neckband 150 can operate independently with a mobile operating system to provide feedback to the user 5 through vibrations, sound, and / or electrical stimulation along the band of the sensor-equipped neckband 150. In addition, the sensor-equipped neckband 150 can support wireless technologies like Bluetooth and Wi-Fi, enabling communication through a wireless communication link 125, such as the user device 110 and / or other wearable devices (e.g., 130, 170, 180). Thus, the sensor-equipped neckband 150 can provide feedback to the user 5 through the wireless communication link 125. In addition, the sensor-equipped neckband 150 can control or retrieve data from other wearable devices (e.g., 130, 170, 180) and / or remote computing devices (110, 195).

[0040] The smart watch 170 can collect information from external sensors, such as one or more sensors facing and / or contacting the user’s wrist (i.e., skin), and / or internal sensors, such as an IMU, proximity / motion sensor, light sensor, gas sensor, camera, etc. The smart watch 170 can operate with a mobile operating system to provide feedback to the user 5 through a watch face display, vibrations, and / or sound. The smart watch 170 can support wireless technologies like Bluetooth and Wi-Fi, enabling communication through a wireless communication link 125, such as the user device 110 and / or other wearable devices (e.g., 130, 150, 180). Thus, the smart watch 170 can provide feedback to the user 5 through the wireless communication link 125. In addition, the smart watch 170 can control or retrieve data from other wearable devices (e.g., 130, 150, 180) and / or remote computing devices (110, 195).

[0041] The earphones 180 can collect information from external sensors, such as one or more sensors facing and / or contacting the user's ears or cheeks (i.e., skin), and internal sensors, such as an IMU, proximity / motion sensors, light sensors, gas sensors, cameras, microphones, and the like. The earphones 180 can operate using a mobile operating system to provide feedback to the user 5 via vibration and / or sound. The earphones 180 can support wireless technologies such as Bluetooth and Wi-Fi, enabling communication with the user device 110 and / or other wearable devices (e.g., 130, 150, 170) via a wireless communication link 125. Thus, the earphones 180 can provide feedback to the user 5 via the wireless communication link 125. In addition, the earphones 180 can control or obtain data from other wearable devices (e.g., 130, 150, 170) and / or remote computing devices (110, 195).

[0042] The user device 110 and / or the wearable devices 130, 150, 170, 180 may include other or additional sensors, such as cameras, microphones, IMUs, clocks, electromyograms, gas sensors, pressure sensors, proximity / motion sensors, light sensors, and thermometers. Figure 1 Three wearable devices 130, 150, 170, 180 are shown, but various embodiments may include fewer or greater numbers of wearable devices and / or remote computing devices, including Figure 1 One or more different types of wearable devices and / or electronic devices not shown in FIG. For example, various embodiments may include a remote computing device that acts as an accessory, such as a smart cup or smart straw that can be used to detect how much fluid the user 5 has consumed.

[0043] The user device 110 may use conventional functionality applied to determining how much fluid has been consumed, such as a clock / timer that can provide a measurement of how long the container has been at the mouth, which, if combined with a tilt angle measurement, can indicate how much liquid has been poured.

[0044] In addition to determining the user's current hydration level by estimating the amount of water consumed, the user device 110 may be configured to provide feedback to the user 5 via the display 115 , such as displaying a warning such as “Warning, you haven’t consumed enough fluids today, have a drink!”

[0045] In some embodiments, a user's predetermined baseline consumption rate can be determined based on a previously counted number of at least one of sips or swallows detected by a sensor when the user consumes a known amount of liquid. Additionally or alternatively, a user's predetermined baseline consumption rate can be determined based on manual user input indicating at least one of a known amount of liquid or the number of sips or swallows required to consume the known amount of liquid. As a further supplement or further alternative, a user's predetermined baseline consumption rate can be determined based on the context in which the liquid is consumed. For example, a user may have a habit of drinking slowly in the morning, which can be taken into account in the predetermined baseline consumption rate in the morning. Similarly, when in the office, exercising, or when the ambient temperature is high and / or the humidity is high, the user may tend to drink more, which can also be taken into account in the predetermined baseline consumption rate in those situations.

[0046] In some embodiments, updates to a previously determined baseline consumption rate may be determined for a user based on liquid consumption information from at least one of a sensor, user input, or the context in which the liquid is consumed. The predetermined baseline consumption rate may be based on updates to a previously determined baseline consumption rate for the user.

[0047] In some embodiments, the processor of user device 110 may receive contextual information indicating a context in which the user took at least one of the number of sips and / or swallows. Furthermore, the user's hydration level may be determined based in part on the context in which the user took at least one of the number of sips or swallows.

[0048] Some embodiments may determine whether the user consumed solids along with the amount of liquid consumed. Additionally, in response to determining that the user consumed solids along with the liquid, determining the amount of liquid consumed by the user may be based on the number of sips taken by the user.

[0049] In some embodiments, an electronic device (e.g., user device 110) may receive an indication of the type of liquid consumed by a user. Using such information, the electronic device may further determine the user's hydration level based on the type of liquid consumed by the user. For example, if the received indication of the type of liquid consumed by the user indicates that the liquid consumed by the user includes at least one of a diuretic or a dehydrating substance, the electronic device may determine the user's hydration level based on the determined amount of liquid consumed, with a reduction adjustment for the hydration level to take into account the diuretic or dehydrating substance indicated in the received indication. As another example, if the received indication of the type of liquid consumed by the user indicates that the liquid consumed by the user includes an antidiuretic, the electronic device may determine the user's hydration level based on the determined amount of liquid consumed, with an increase adjustment to take into account the indicated antidiuretic. Similarly, if the received indication of the type of liquid consumed by the user indicates that the liquid is a medication with diuretic or antidiuretic properties, the determined user's hydration level may be adjusted accordingly.

[0050] In some embodiments, an electronic device (e.g., user device 110) may receive food consumption information associated with food consumed by a user, and further determine the user's hydration level based in part on the received food consumption information. Furthermore, the user's hydration level may be further determined based in part on the received food consumption information.

[0051] Various embodiments may be implemented in various types of user devices and electronic devices using a variety of single-processor and multi-processor computer systems, including systems on a chip (SOCs) or systems in packages (SIPs). Figure 2 An example computing system or SIP 200 architecture is shown that may be used in an electronic device, such as an electronic device (eg, user device 110 ) and / or one or more wearable devices (eg, 130 , 150 , 170 , etc.) implementing various embodiments.

[0052] refer to Figure 1 and 2 , the example SIP 200 shown includes two SOCs 202 and 204, a clock 206, a voltage regulator 208, and a wireless transceiver 266. In some embodiments, the first SOC 202 serves as the central processing unit (CPU) of the wireless device, executing instructions of a software application by performing arithmetic, logic, control, and input / output (I / O) operations specified by the instructions. In some embodiments, the second SOC 204 can operate as a dedicated processing unit. For example, the second SOC 204 can serve as a dedicated 5G processing unit responsible for managing high-capacity, high-speed (e.g., 5 Gbps, etc.) and / or very high frequency short wavelength (e.g., 28 GHz millimeter wave spectrum, etc.) communications.

[0053] The first SOC 202 may include a digital signal processor (DSP) 210, a modem processor 212, a graphics processor 214, an application processor 216, one or more coprocessors 218 (e.g., vector coprocessors) connected to one or more processors, memory 220, custom circuitry 222, system components and resources 224, an interconnect / bus module 226, one or more sensors 230 (e.g., thermal sensors, motion sensors, proximity sensors, multimeters, etc.), a thermal management unit 232, and a thermal power envelope (TPE) component 234. The second SOC 204 may include a 5G modem processor 252, a power management unit 254, an interconnect / bus module 264, multiple mmWave transceivers 256, memory 258, and various additional processors 260, such as an application processor, a packet processor, etc.

[0054] Each processor 210, 212, 214, 216, 218, 252, 260 may include one or more cores, and each processor / core may operate independently of the other processors / cores. For example, the first SOC 202 may include a processor that executes a first type of operating system (e.g., FreeBSD, LINUX, OS X, etc.) and a processor that executes a second type of operating system (e.g., Microsoft Windows 10). In addition, any or all of the processors 210, 212, 214, 216, 218, 252, 260 may be part of a processor cluster architecture (e.g., a synchronous processor cluster architecture, an asynchronous or heterogeneous processor cluster architecture, etc.).

[0055] The first and second SOCs 202, 204 may include various system components, resources, and custom circuits for managing sensor data, analog-to-digital conversion, wireless data transmission, and for performing other specialized operations, such as decoding data packets and processing encoded audio and video signals for presentation in a web browser. For example, the system components and resources 224 of the first SOC 202 may include power amplifiers, voltage regulators, oscillators, phase-locked loops, peripheral bridges, data controllers, memory controllers, system controllers, access ports, timers, and other similar components for supporting processors and software clients running on the wireless device. The system components and resources 224 and / or custom circuits 222 may also include circuits for interfacing with peripheral devices, such as cameras, electronic displays, wireless communication devices, external memory chips, and the like.

[0056] The first and second SOCs 202, 204 can communicate via interconnect / bus modules 250. The various processors 210, 212, 214, 216, 218 can be interconnected via interconnect / bus modules 226 with one or more memory elements 220, system components and resources 224, custom circuitry 222, and thermal management unit 232. Similarly, processor 252 can be interconnected via interconnect / bus modules 264 with power management unit 254, millimeter wave transceiver 256, memory 258, and various additional processors 260. The interconnect / bus modules 226, 250, 264 can include reconfigurable arrays of logic gates and / or implement bus architectures (e.g., CoreConnect, AMBA, etc.). Communication can be provided by high-level interconnects such as high-performance networks on a chip (NoCs).

[0057] The first and / or second SOCs 202, 204 can also include input / output modules (not shown) for communicating with resources external to the SOC, such as clock 206 and voltage regulator 208. Resources external to the SOC (e.g., clock 206, voltage regulator 208) can be shared by two or more internal SOC processors / cores.

[0058] In addition to the example SIP 200 discussed above, various embodiments can be implemented in a variety of computing systems, which can include a single processor, multiple processors, multi-core processors, or any combination thereof.

[0059] In some embodiments, only one SOC (e.g., 202) can be used in less capable electronic devices, such as a wearable device (e.g., 130, 150, 170, etc.) configured to provide sensor information to a more capable electronic device, such as a smartphone 110. In such embodiments, the communication capabilities of the wearable device (e.g., 130, 150, 170, etc.) can be limited to short-range communication links, such as Bluetooth or Wi-Fi, in which case a 5G-capable SOC 204 can not be included in the processing system of the wearable device.

[0060] As used herein, the terms “component,” “system,” “unit,” “module,” and the like include computer-related entities such as, but not limited to, hardware, firmware, a combination of hardware and software, software, or software in execution, which are configured to perform particular operations or functions. For example, a component can be, but is not limited to, a process running on a processor, a processor, an object, an executable, a thread of execution, a program, and / or a computer. By way of illustration, both an application running on a communication device and the communication device can be referred to as a component. One or more components can reside within a process and / or thread of execution and a component can be localized, co-resident, and / or distributed amongst one or more computer processors or cores. Also, these components can execute from various non-transitory computer readable media having various instructions and / or data structures stored thereon. Components can communicate via local and / or remote processes, function- or procedure-calls, electronic signals, data packets, memory reads / writes, and other known computer, processor, and / or process related communication methods.

[0061] Figure 3 is a component block diagram illustrating a system 300 configured for tracking a user’s hydration by a processor of an electronic device 310, in accordance with various embodiments. Referring to Figure 1-Figure 3 , the system 300 can include an electronic device 310 (e.g., user device 110) and be configured to communicate with one or more remote computing devices 315 (e.g., servers 195) or other electronic devices via a local area wireless network router (e.g., Wi-Fi, Bluetooth, Ant, etc.) that can be coupled to the Internet. The electronic device 310 (e.g., user device 110) can also be configured to communicate with external resources 320 (e.g., servers 195) via a wireless network 190, such as a cellular wireless communication network. Figure 1

[0062] The electronic device 310 (e.g., user device 110) can include electronic storage 325, one or more processors 330, a wireless transceiver 266, and other components. The electronic device 310 can include communication lines or ports to enable exchange of information with networks and / or other computing platforms. Figure 3 The illustration of the electronic device 310 inis not intended to be limiting. The electronic device 310 can include multiple hardware, software, and / or firmware components operating together to provide the functionality attributed herein to the electronic device 310.

[0063] Electronic storage 325 may include non-transitory storage media that electronically stores information. The electronic storage media of electronic storage 325 may include one or both of system storage that is provided integrally with electronic device 310 (e.g., user device 110) (i.e., substantially non-removable) and / or removable storage that is removably connected to electronic device 310 via, for example, a port (e.g., a Universal Serial Bus (USB) port, a FireWire port, etc.) or a drive (e.g., a disk drive, etc.). Electronic storage 325 may include one or more of optically readable storage media (e.g., optical disks, etc.), magnetically readable storage media (e.g., magnetic tape, a magnetic hard drive, a floppy disk drive, etc.), charge-based storage media (e.g., EEPROM, RAM, etc.), solid-state storage media (e.g., a flash drive, etc.), and / or other electronically readable storage media. Electronic storage 325 may include one or more virtual storage resources (e.g., cloud storage, a virtual private network, and / or other virtual storage resources). Electronic storage 325 may store software algorithms, information determined by processor 330 , information received from user device 310 , information received from remote platform 304 , and / or other information that enables electronic device 310 to function as described herein.

[0064] Processor 330 may be configured to provide information processing capabilities in electronic device 310 (e.g., user device 110). As such, processor 330 may include one or more of a digital processor, an analog processor, a digital circuit designed to process information, an analog circuit designed to process information, a state machine, and / or other mechanisms for electronically processing information. Although processor 330 may be configured to provide information processing capabilities in electronic device 310 (e.g., user device 110), processor 330 may include one or more of a digital processor, an analog processor, a digital circuit designed to process information, an analog circuit designed to process information, a state machine, and / or other mechanisms for electronically processing information. Figure 3 3. In some embodiments, processor 330 may include multiple processing units. These processing units may be physically located within the same device, or processor 330 may represent processing functionality of multiple devices operating in coordination.

[0065] The electronic device 310 (e.g., user device 110) may be configured by machine-readable instructions 335, which may include one or more instruction modules. The instruction modules may include computer program modules. Specifically, the instruction modules may include a consumption indication receiving module 340, a consumption type determining module 345, a context information receiving module 350, a baseline consumption rate determining module 355, a baseline consumption rate adjusting module 360, a consumption amount determining module 365, a hydration level determining module 370, a hydration level adjusting module 375, a hydration level reporting module 380, and / or other instruction modules.

[0066] The consumption indication receiving module 340 can be configured to receive consumption indications from one or more sensors of the electronic device 310 (e.g., the user device 110) and / or a local computing device near the electronic device 310 (e.g., smart glasses 130, a sensor-equipped neckband 150, a smartwatch 170, etc.). The sensors can detect when a user performs certain actions associated with the consumption of a drink / food and / or can detect the presence of consumables (i.e., a drink and / or food). As non-limiting examples, consumption indications can come from cameras, lidars, light sensors, microphones, IMUs, electromyograms, pressure sensors, proximity / motion sensors, and gas sensors. Cameras and lidars can detect a drink or food being brought to the mouth. Microphones can detect the sounds of sipping and / or swallowing, as well as the sound of a can or carbonated beverage being opened. IMUs can detect when a drink or food is brought to the mouth. Electromyograms can detect muscle movements associated with sipping and / or swallowing. Gas sensors can detect when food and / or liquid is near the user's mouth (i.e., being consumed or about to be consumed). A smart cup or smart straw can detect when liquid is being dispensed.

[0067] The processor of the electronic device (e.g., 210, 212, 214, 216, 218, 252, 260) can receive consumption indication information directly from onboard sensors and / or use one or more transceivers (e.g., 256, 266) to detect available wireless connections 125 (e.g., Wi-Fi, Bluetooth, cellular, etc.). In addition, the consumption indication receiving module 340 can be configured to determine whether the detected communication link is available for the wearable device or other remote computing device.

[0068] The consumption type determination module 345 can be configured to determine whether the consumption indication (i.e., received by the consumption indication receiving module 340) indicates that the user is eating and / or drinking. In addition, the consumption type determination module 345 can be configured to determine the type of food or drink being consumed. As non-limiting examples, a camera and / or lidar can collect images that identify consumables, a microphone can collect sounds (e.g., a carbonated beverage can opening), an electromyogram can collect indications of muscle movement (e.g., associated with chewing or sipping), and the smart device can provide specific information about what is being consumed in general or specifically. The processor (e.g., 210, 212, 214, 216, 218, 252, 260) can use details about what is being consumed or how it is being consumed to determine whether the user is eating and / or drinking. The determination of what type of consumables being consumed (i.e., beverage or food, food mixture, or specifically, the type of food, beverage or food / beverage mixture being consumed) can be directly from the identification of the food, beverage or food / beverage mixture itself, or indirectly from the container, plate or other object for delivering food, beverage or its combination. In addition, depending on the level of detail included in the consumption indication (i.e., received by the consumption indication receiving module 340), the consumption type determination module 345 can be configured to more accurately determine what is being consumed or has been consumed. For example, the consumption indication can identify the food and / or beverage consumed as containing a diuretic or antidiuretic, which can affect the user's total hydration.

[0069] In order to determine the type of consumables consumed, the consumption type determination module 345 can also access a database containing one or more data records, which are stored in the memory (e.g., 220, 258, 325) or obtained from a remote source (such as a remote system (e.g., 315) or an external resource (e.g., 320)) using a transceiver (e.g., 256, 266) and related components. The processor of the electronic device can access the data record to compare previously stored information about the sensor data with the data received from the sensor to determine what the received consumption indication represents. For example, a lookup table can provide information for determining the type of consumables detected and / or even its specific details. Alternatively, a gas sensor can be configured to detect a gas, which the processor can use to determine the consumables or consumable types being consumed. Therefore, the consumption type determination module 345 can determine whether the user is consuming a liquid, a solid, or a solid in combination with some liquid. Alternatively or additionally, the consumption type determination module 345 can determine the type of liquid consumed, and whether the liquid has diuretic or antidiuretic properties, which can be determined based on the information stored in the memory. Alternatively or additionally, the consumption type determination module 345 may determine the food or food / liquid combination being consumed and how much hydration the consumable provides to the user, and possibly determine whether the consumable has diuretic or antidiuretic properties.

[0070] The contextual information receiving module 350 can be configured to receive contextual information from one or more sources for consideration of all available information about what is being consumed. Contextual information about what is being consumed and how it is being consumed can be used to adjust determinations of how much liquid is consumed and the total hydration level. The contextual information can include one or more temperatures (e.g., the user's body temperature, the temperature of the consumable, and / or the ambient temperature and / or humidity). Additionally, the contextual information can include information about the environment, the time of day, or information about the user's activity level or health status, which can impact the determination of total hydration. In some embodiments, the received contextual information can indicate the context in which the user performed at least one of the number of sips or swallows.

[0071] In some embodiments, the context in which the user performs at least one of the number of sips or swallows can include recent past events or conditions that may affect the user's baseline consumption rate. For example, the user may have just finished exercising, or may have just entered shelter after being outdoors in extreme heat. When drinking and / or eating, the user may no longer be exercising or exposed to extreme heat, but the user's body may still be affected by this recent past event or condition, which may persist for some time. In this way, the context in which the user consumes liquids, solids, or solid / liquid mixtures can reflect past events or conditions that, at the time of consumption, still affect the user's baseline consumption rate.

[0072] The temperature and / or composition of a liquid can affect how quickly or slowly a user consumes it. For example, hot coffee is typically consumed slower than iced tea. While the precise temperature of a liquid or other consumable is helpful, a temperature range may also be useful for estimating a baseline consumption rate. For example, liquids in the high, medium, or low temperature range may be associated with baseline consumption rates that are appropriate for the corresponding temperature range. Additionally, the properties of the liquid, such as whether it is carbonated, viscous, or has solids in it (e.g., ice), may affect the user's consumption rate. Liquid contents such as ice can be detected visually or based on sounds detected by a microphone (e.g., ice in a glass or clinking against a user's teeth). Additionally, manual input from a user can provide information about the contents and / or temperature of a consumable.

[0073] As non-limiting examples, context information may be received from sensors that provide information to an electronic device (e.g., user device 110) and / or a local computing device (e.g., smart glasses 130, sensor-equipped neckband 150, smartwatch 170, etc.) near the electronic device 310. The context information receiving module 350 may also receive context information by accessing a database containing one or more data records stored in a local memory (e.g., 220, 258, 325) or obtained from a remote source (e.g., a remote system (e.g., 315) or an external resource (e.g., 320)) using a transceiver (e.g., 256, 266) and related components.

[0074] The baseline consumption rate determination module 355 can be configured to determine the user's baseline consumption rate. In some embodiments, the baseline consumption rate can be determined based on a previously counted number of at least one of sips or swallows detected by a sensor when the user consumes a known amount of liquid (e.g., water) (i.e., a parameter detected by the sensor). In some other embodiments, the baseline consumption rate can be determined based on a manual user input indicating at least one of the known amount of liquid or the number of sips or swallows required for the user to consume the known amount of liquid. In some embodiments, the baseline consumption rate can be determined based on the context (i.e., contextual information) of the consumed liquid (e.g., obtained by the contextual information receiving module 350). In some embodiments, the baseline consumption rate can be determined based on a combination of sensor-detected parameters, manual user input, or contextual information.

[0075] During an initial calibration, a user can be instructed to consume a specified volume of liquid and provide an indication when the liquid is completely consumed. The electronic device can process information received from the various sensors and calibrate the information or correlate the information to the number of sips and / or swallows the user takes to consume the liquid during this initial calibration. The number of sips and / or swallows associated with consuming the liquid, as well as the sensor data collected while the user consumes the liquid, can be used as a baseline consumption rate as well as a baseline sensor calibration. For example, the processor of the electronic device can analyze the sensor data received while the user consumes the liquid and correlate the various sensor readings to the sips or swallows the user makes during that time. Thus, the calibration process not only calibrates the average amount of liquid consumed per sip or swallow, but can also correlate the various sensor data to the detection of a sip or swallow. Moreover, this volume-sip / swallow calibration and sensor data correlation to sips or swallows can be dependent on the type of liquid consumed, which can require performing the calibration process for various types of liquids the user typically consumes. As part of the active baseline setting, the user can be prompted to indicate or confirm what liquid is being consumed. The same procedure can be applied to determine baseline consumption rates and sensor calibration for different liquids, liquids of different temperatures, and / or liquids of different consistencies (e.g., viscous, foamy, milky, mixed with solids, etc.). Furthermore, the same calibration process can be used for the same consumable in different contexts (e.g., different ambient temperatures / humidity, while exercising, different times of day, different locations, etc.). Once the calibration process is complete, the results can be stored in memory in the form of a lookup table and the processor can use the lookup table to determine the amount of liquid consumed during normal operation.

[0076] Alternatively or additionally, in some cases, passive baseline setting can be used for initial calibration. For example, using a drink container of a standard size (such as a 12-ounce can), the processor can detect an event, such as when the can is opened (e.g., using a microphone), and then determine the number of sips or swallows used when a completion event is detected, such as a sound associated with the last sip or a clank sound when the can is placed on a surface, a sound when the can is crushed, and / or a sound associated with the can being thrown in the trash.

[0077] Using the baseline consumption rate determination module 355 to determine the baseline consumption rate can allow the user to not have to wear a plurality of wearable devices and / or sensors every time they eat or drink. Once the user's baseline consumption rate is determined, the user can consume liquids and / or solids, and the determined baseline consumption rate can be used to determine how much is consumed without requiring many wearable devices and / or sensors to make this determination. For example, when calculating the baseline consumption rate, the processor can use input from various sensors to determine the number of times the user took a sip and how much liquid was consumed with each sip. Thereafter, once the baseline is determined, the processor may only need input from fewer sensors that determine the number of sips taken, but may use the amount of liquid consumed with each sip from the previously determined baseline consumption rate.

[0078] As a non-limiting example, the processor of the electronic device (e.g., 210, 212, 214, 216, 218, 252, 260) can use active and / or passive baseline determination techniques to determine an initial baseline consumption rate. Manual entry of consumption or contextual information by the user may be helpful in determining the baseline, particularly during an initial calibration process, to ensure that the number of sips and / or swallows measured is accurately compared against the correct liquid volume, type, temperature, and viscosity. However, consumption contextual information automatically entered by the sensor may also or alternatively be used in the initial calibration process to determine the user's baseline consumption rate. In addition, the initial baseline consumption rate may take into account contextual factors that may have affected the initial baseline consumption rate, such as temperature, environment, time of day, or information about the user's activity level, age, gender, weight, or health status (e.g., diabetes), which may affect the determination of total hydration.

[0079] To determine the baseline consumption rate, the baseline consumption rate determination module 355 can receive information from a sensor and / or access a database containing one or more data records. The records can be stored in a local memory (e.g., 220, 258, 325) or received from a remote source (e.g., a remote system (e.g., 315) or an external resource (e.g., 320)) using a transceiver (e.g., 256, 266) and associated components. The sensor can similarly be part of an electronic device or receive from a remote source (e.g., a remote system (e.g., 315) or an external resource (e.g., 320)) using a transceiver (e.g., 256, 266) and associated components.

[0080] The baseline consumption rate adjustment module 360 ​​can be configured to determine an update (i.e., recalibration) to a previously determined baseline consumption rate and change the previously determined baseline consumption rate. In cases where the previously determined baseline consumption rate is not necessary for determining an update, the determined update can be based on new consumption information from one or more sensors. A baseline consumption rate for a particular beverage can be established and recorded, but the processor can then detect changes in this baseline consumption rate. The baseline consumption rate adjustment module 360 ​​can be used to calculate and record this change. For example, the processor can prompt the user to indicate or confirm when the user consumes something whose baseline consumption rate may require an update. If the measured baseline consumption rate deviates sufficiently from the recorded baseline consumption rate, the processor can immediately initiate a recalibration procedure using the baseline consumption rate adjustment module 360. Alternatively, the processor can maintain a rolling average of the baseline consumption rate of the beverage and prompt the user when the rolling average changes by more than a threshold. The prompt can ask the user to confirm a calculated guess (i.e., estimate) of the number of sips and / or swallows required to consume a known amount of liquid to obtain feedback and provide further calibration to generate an update to the user's previously determined baseline consumption rate. When there is no baseline consumption rate available for the liquid being consumed, the calculated guess can be based on different liquids and may therefore benefit from user feedback, which helps to obtain a more accurate baseline consumption rate for the new liquid being consumed. Various embodiments can apply machine learning to determine updates that may occur from time to time and identify the user's consumption habits at specific times of the day or specific days of the week, which may be useful for determining what is consumed and how much is consumed (e.g., a 16-ounce cup of coffee every morning). The processor can associate contextual information with the determined updates. For example, situations where the user has a fever, has dark or yellow urine, has been unusually active, or consumes on hot or very cold days can be associated with the determined updates for use in similar situations in the future.

[0081] Additionally, the processor may receive input from the user indicating that an update is needed. For example, after issuing an alert indicating that the user is dehydrated and needs to drink some fluids, the processor may receive user input indicating that the user is not dehydrated, in which case the processor may initiate a recalibration routine for updating one or more previously determined baseline consumption rates. The user may have additional information confirming that they are not dehydrated (e.g., frequent urination and / or very light or almost clear urine). Alternatively, the user may manually initiate the recalibration routine.

[0082] The baseline consumption rate adjustment module 360 ​​can enable the user to wear fewer wearable devices and / or sensors each time they eat or drink. When the user does occasionally wear a large number of wearable devices and / or sensors, the baseline consumption rate adjustment module 360 ​​can be used to recalibrate and update one or more baseline consumption rates stored in the memory. For example, the processor can occasionally prompt the user to run a new training routine that involves the user using a smart cup or smart straw (i.e., additional sensors). Similarly, the processor can prompt the user to wear one or more additional wearable devices and / or sensors during a new training routine. The new training routine can include consuming only one cup, or can include consuming more than one cup at different times and / or on different days.

[0083] As a non-limiting example, a processor (e.g., 210, 212, 214, 216, 218, 252, 260) of an electronic device (e.g., user device 110) can use active and / or passive baseline determination techniques to determine updates to a previous baseline consumption rate. To determine one or more updates to a previous baseline consumption rate, the baseline consumption rate adjustment module 360 ​​can receive information from a sensor and / or access a database containing one or more data records. The records can be stored in a local memory (e.g., 220, 258, 325) or received from a remote source (e.g., a remote system (e.g., 315) or an external resource (e.g., 320)) using a transceiver (e.g., 256, 266) and related components. The sensor can similarly be part of the electronic device or receive from a remote source (e.g., a remote system (e.g., 315) or an external resource (e.g., 320)) using a transceiver (e.g., 256, 266) and related components.

[0084] The consumption determination module 365 can be configured to determine the amount of liquid consumed by the user based on a predetermined baseline consumption rate (determined by the baseline consumption rate determination module 355 and / or updated by the baseline consumption rate adjustment module 360) and the number of at least one of sips or swallows of the user detected by one or more sensors coupled to the processor. In various embodiments, the clock can provide a measurement of how long the container rests at the mouth, which, when combined with the tilt angle measurement measured by other sensors (such as an IMU), can indicate how much liquid was poured out. In some embodiments, the consumption determination module 365 can measure how much was consumed through image analysis of camera, thermal and / or lidar imaging. Alternatively, the consumption determination module 365 can measure how much has not been consumed (i.e., how much is left in the container) through image analysis of camera imaging, which can be used to determine how much has been consumed.

[0085] According to various embodiments, generally when a person drinks a liquid, each detected sip can correspond to more than one swallow. This can be because most people sip or otherwise ingest more than what can be swallowed in one mouthful. Thus, by using the detected number of swallows rather than sip counts, the baseline can tend to be more accurate, particularly given that the range of liquid volume consumed per swallow is narrower than the range of liquid volume typically consumed per sip. Thus, some embodiments can use the detected swallow count in the consumed volume determination module 365 to determine the volume consumed. However, when the user is eating and drinking at the same time, the sip count can be a more accurate measure of fluid intake than the swallow count. Thus, in response to the processor determining that the user is drinking (as determined by the consumption type determination module 345), the swallow count obtained from the sensors and / or data lookup can be used to determine the volume of liquid consumed by the user. Swallows can be detected based on data received from one or more electromyograms, pressure sensors, strain sensors, microphones, etc. Conversely, in response to the processor determining that the user is eating or drinking a liquid mixed with solids (e.g., ice or a thick soup), as determined by the consumption type determination module 345, the sip count obtained from the sensors and / or data lookup can be used to determine the volume of liquid consumed by the user. In the case of mixed consumption, if there is a good measure of how much is ingested into the mouth per sip, then the sip count can be more accurate than the swallow count because there is more uncertainty about the volume of liquid swallowed by the user. Sips can be detected by camera images, data from microphones, electromyograms, motion sensors (e.g., on a smart necklace), etc., as well as information from other sensors that can confirm a sip, such as IMU-based motion data, pressure sensors, strain sensors, etc. Moreover, in determining which counting method (i.e., sip count or swallow count) is more appropriate, the processor can use the active and / or passive methods described above. Moreover, baseline calibration routines involving mixed consumption scenarios can be provided.

[0086] As a non-limiting example, the electronic device (e.g., user device 110) can receive sip and / or swallow count information from sensors (e.g., smart glasses 130, sensor-equipped neckband 150, and smart watch 170, etc.). The consumed volume determination module 365 can estimate sip and / or swallow counts based on the sensor information by comparing the information to calibration information in a database containing one or more data records stored in local memory (e.g., 220, 258, 325) or obtained from a remote source (such as a remote system (e.g., 315) or external resource (e.g., 320)) using a transceiver (e.g., 256, 266) and related components.

[0087] The hydration level determination module 370 can be configured to estimate the user's hydration level based on the determined amount of liquid consumed (determined by the consumption determination module 365). In some embodiments, the estimate of hydration level determined by the hydration level determination module 370 can be merely a preliminary determination of the user's hydration level based solely on the baseline consumption rate and the known or estimated volume of liquid consumed. As further described below, the hydration level adjustment module 375 can take into account other factors that affect hydration level.

[0088] In some embodiments, the hydration level determination module 370 can be configured to track when a hydration level check is needed on behalf of the user. Hydration levels may need to be checked periodically, or at other frequencies deemed appropriate for the user. Furthermore, the need for a hydration level check can be triggered by what the user has consumed, what the user has done or is doing, and / or external factors that may affect the user's hydration level.

[0089] Considering that 70-80% of total hydration comes from consumed fluids, even if the processor ignores fluid consumption from food sources, a hydration level based solely on fluid consumption measurements can still determine the most important driver of a user's hydration, namely fluid consumption. Therefore, tracking only fluid consumption can provide a fairly accurate picture of total hydration, as well as a preliminary determination of the hydration level calculated by the hydration level determination module 370.

[0090] Some embodiments may only measure liquids consumed by the user, without measuring solids or solid / liquid mixtures, but will adjust by assuming the percentage of liquid consumed from unmeasured consumables. For example, if only liquid consumption is measured, it may only account for approximately 80% of the user's liquid intake, and the remaining percentage (i.e., 20% in this example) may be liquid consumed from food (i.e., solids and solid / liquid mixtures). In the absence of actual measurement of the solids or solid / liquid mixtures consumed, various embodiments may assume an average percentage of liquid intake from those unmeasured consumables consumed by the user. Thus, in this example, if only 80% of the user's hydration levels are actually measured, the remaining 20% ​​can be considered to have also been consumed. The amount of liquid consumed through solids or solid / liquid mixtures may be determined by the user's diet, so other users who consume less fruit and / or vegetables (i.e., foods with higher hydration) may need to take in more liquid by drinking fluids. Similarly, exercise and the user's regular activity level can control how much liquid the user needs to take in. Additionally, the user's body composition may be considered when determining total hydration, as the more body fat a user has in their weight, the less water is required per pound (or kilogram) to achieve optimal hydration.

[0091] As a non-limiting example, the volume of liquid consumed by the user can be received from the consumption amount determination module 365. Using the body weight, the hydration level of the user can be calculated as a percentage of liquid to that body weight. Further, using the user's biometric data, such as age, gender, body composition (e.g., body mass index), and previously determined and / or confirmed hydration level information, the processor can determine a more personalized hydration level for the user.

[0092] The hydration level determination module 370 can additionally or alternatively obtain information from sensors that provide information to the electronic device 310 (e.g., user device 110) and / or a local computing device in the vicinity of the electronic device 310 (e.g., smart glasses 130, sensor-equipped neckband 150, and smart watch 170, etc.). The hydration level determination module 370 can also receive sipping and / or swallowing count information by accessing a database containing one or more data records stored in local memory (e.g., 220, 258, 325) or obtained from a remote source, such as a remote system (e.g., 315) or external resource (e.g., 320) using a transceiver (e.g., 256, 266) and related components. Further, the hydration level determination module 370 can store the determined value of the user's hydration level in local memory (e.g., 220, 258, 325) or in memory of a remote source, such as a remote system (e.g., 315) or external resource (e.g., 320) using a transceiver (e.g., 256, 266) and related components.

[0093] The hydration level adjustment module 375 can be configured to determine one or more adjustments to the preliminary hydration level determination of the user (determined by the hydration level determination module 370). To determine all necessary adjustments, the processor can consider all provided / available information. For example, the processor can access consumption information about the types of food and / or beverages consumed. Not all food or liquid promotes hydration in the same way. Certain liquids or foods can dehydrate the body, such as liquids or foods containing diuretics or antidiuretics. The electronic device can use gas sensors and camera images to identify when these types of liquids and / or foods are consumed. Further, the water content of food can vary greatly, so the system can rely on manual input from the user to identify and track how much hydration is provided from food. The processor can store or obtain from a database detailed hydration information about various liquids, foods, or combinations thereof. Some of this hydration information can have been manually entered by the user or obtained from other sources.

[0094] In some embodiments, the hydration level adjustment module 375 can adjust the initially determined hydration level to account for diuretics and antidiuretics. The system can use gas sensors and camera images to identify the type of liquid consumed. The amount of diuretics and antidiuretics in liquids and foods can vary greatly, so the system may rely on manual input from the user to identify and track how much diuretics and antidiuretics are consumed. The system can store common liquids and foods entered by the user to make it easier to enter the diuretic and antidiuretic content of these liquids and foods in the future, if not automatically.

[0095] In some embodiments, the hydration level adjustment module 375 can adjust the initially determined hydration level based on the user's activity or exercise level and the user's health status. For example, the processor can determine the user's hydration level when a user consumes 80 ounces of liquid. However, for the same user, if she significantly increases or decreases her daily exercise level, the same level of liquid consumption may result in different hydration level determinations. Similarly, for different users, the same level of liquid consumption may result in different hydration level determinations because users may absorb and perspire liquids differently (e.g., due to age, gender, body composition, health status, etc.). The hydration level adjustment module 375 can be used to regularly and / or periodically adjust the user's hydration level determination and adapt to different users.

[0096] As a non-limiting example, a processor (e.g., 210, 212, 214, 216, 218, 252, 260) of an electronic device can determine an adjustment to the hydration level determined by the hydration level determination module 370. To determine one or more adjustments to the initially determined hydration level, the hydration level adjustment module 375 can receive information from a sensor and / or access a database containing one or more data records. The records can be stored in a local memory (e.g., 220, 258, 325) or received from a remote source (e.g., a remote system (e.g., 315) or an external resource (e.g., 320)) using a transceiver (e.g., 256, 266) and associated components. The sensor can similarly be part of the electronic device or receive information from a remote source (e.g., a remote system (e.g., 315) or an external resource (e.g., 320)) using a transceiver (e.g., 256, 266) and associated components. In addition, the hydration level determination module 370 can store the determined value of the adjustment to the determined user's hydration level in local memory (e.g., 220, 258, 325), or store it in the memory of a remote source (such as a remote system (e.g., 315) or an external resource (e.g., 320)) using a transceiver (e.g., 256, 266) and related components.

[0097] The hydration level reporting module 380 can be configured to report the indication of the determined hydration level based on the determined hydration level of the user. The indication of the determined hydration level reported can include the actual measurement of the user's hydration level, the indication of the fluid percentage of the user's weight, and / or a message indicating whether the user is dehydrated, overhydrated, or within a normal range. The reported indication can be conveyed to the user via a display (e.g., 115), a speaker, or a tactile feedback device on an electronic device (e.g., user device 110). Alternatively or additionally, a transceiver (e.g., 256, 266) and related components can be used to send the reported indication to a remote source, such as a remote system (e.g., 315) or an external resource (e.g., 320). For example, a processor can generate text or present an image on a display of an electronic device to provide an alarm message when the user is dehydrated. Alternatively, the processor can send an alarm message that is configured to cause a remote computing device to perform a notification function on behalf of the electronic device.

[0098] As a non-limiting example, the processor of the electronic device (e.g., 210, 212, 214, 216, 218, 252, 260) can report the determined hydration level to the user using a display (e.g., 115). In addition, the processor of the electronic device (e.g., 210, 212, 214, 216, 218, 252, 260) can use one or more transceivers (e.g., 256, 266) to send an indication of the reported determined hydration level to a remote computing device (e.g., 120, 130, 140) with instructions on how, when, and / or under what circumstances a notification function of the remote computing device should function.

[0099] The remote computing device 315 may include one or more processors configured to execute computer program modules similar to those in the machine-readable instructions 335 described above. As non-limiting examples, in addition to the wearable devices described above (e.g., 130, 150, 170), the remote computing device may also include one or more of a smart cup, a smart straw, a smart ring, a smart appliance, a desktop computer, a laptop computer, a handheld computer, a tablet computing platform, a netbook, another smart phone, a game console, and / or other computing devices.

[0100] External resources 320 may include a remote server storing a contact database (or a backup copy of a contact database), information sources external to system 300, external entities participating in system 300, and / or other resources. In some embodiments, some or all of the functionality attributed herein to external resources 320 may be provided by resources included in system 300.

[0101] The processor 330 may be configured to execute modules 340, 345, 350, 355, 360, 365, 370, 375, and / or 380 and / or other modules. The processor 330 may be configured to execute modules 340, 345, 350, 355, 360, 365, 370, 375, and / or 380 and / or other modules through software, hardware, firmware, some combination of software, hardware, and / or firmware, and / or other mechanisms for configuring processing capabilities on the processor 330. As used herein, the term "module" may refer to any component or set of components that performs the functionality attributed to the module. This may include one or more physical processors, processor-readable instructions, circuitry, hardware, storage media, or any other component during the execution of processor-readable instructions.

[0102] The description of the functionality provided by the different modules 340, 345, 350, 355, 360, 365, 370, 375, and / or 380 described below is for purposes of illustration and not limitation, as any of the modules 340, 345, 350, 355, 360, 365, 370, 375, and / or 380 may provide more or less functionality than described. For example, one or more of the modules 340, 345, 350, 355, 360, 365, 370, 375, and / or 380 may be excluded, and some or all of their functionality may be provided by other modules in the modules 340, 345, 350, 355, 360, 365, 370, 375, and / or 380. As another example, processor 330 may be configured to execute one or more additional modules that may perform some or all of the functionality attributed below to one of modules 340 , 345 , 350 , 355 , 360 , 365 , 370 , 375 , and / or 380 .

[0103] Figure 4A A method 400 for tracking hydration of a user is shown, which may be performed by a processor of an electronic device and / or one or more other computing devices, in accordance with various embodiments. Figure 4B 、 Figure 4C 、 Figure 4D 、 Figure 4E 、 Figure 4F 、 Figure 4G 、 Figure 4H 、 Figure 4I and Figure 4JAdditional or alternative operations are shown in methods 401, 402, 403, 404, 405, 406, 407, 408, and 409, which, in some embodiments, may be performed as part of method 400. The operations of methods 400, 401, 402, 403, 404, 405, 406, 407, 408, and 409 are intended to be illustrative. In some embodiments, methods 400, 401, 402, 403, 404, 405, 406, 407, 408, and 409 may be accomplished with one or more additional operations not described and / or by omitting one or more of the operations discussed. Furthermore, in Figure 4A 、 Figure 4B 、 Figure 4C 、 Figure 4D 、 Figure 4E 、 Figure 4F 、 Figure 4G 、 Figure 4H 、 Figure 4I and Figure 4J The order in which the operations of methods 400 , 401 , 402 , 403 , 404 , 405 , 406 , 407 , 408 , and 409 are illustrated and described below is not intended to be limiting.

[0104] refer to Figure 1-Figure 4I , methods 400, 401, 402, 403, 404, 405, 406, 407, 408, and 409 can be implemented in one or more processors (e.g., 202, 204, 210, 212, 214, 216, 218, 252, 260) of an electronic device (e.g., user device 110) and / or one or more other computing devices, including wearable devices (e.g., smart glasses 130) configured with processor-executable instructions stored on a non-transitory processor-readable storage medium. The one or more processors may include one or more devices configured by hardware, firmware, and / or software specifically designed to perform one or more operations of the method.

[0105] Figure 4A A method 400 is shown by which a processor of an electronic device may track hydration of a user in accordance with one or more embodiments.

[0106] In block 420, a processor of the electronic device may perform operations including determining an amount of liquid consumed by the user based on a predetermined baseline consumption rate for the user and a number of sips or swallows of the user detected by a sensor coupled to the processor. To implement the determination in block 420, the processor may use a baseline consumption rate determination module (e.g., 355) and / or a baseline consumption rate adjustment module (e.g., 360) to determine a baseline consumption rate for the user and, in conjunction with a consumption amount determination module (e.g., 365), determine the amount of liquid consumed by the user. Furthermore, in block 420, the processor may access a database containing one or more data records stored in a local memory (e.g., 220, 258) or obtained from a remote source (e.g., a remote system (e.g., 315) or an external resource (e.g., 320)) using a transceiver (e.g., 256, 266) and associated components. The database may provide information about the user's baseline consumption rate and / or the number of sips and / or swallows taken by the user while consuming liquid. Means for performing the operations of block 420 may include a processor (e.g., 202, 204, 210, 212, 214, 216, 218, 252, 260) coupled to a memory (e.g., 220, 258, 325) or obtained from a remote source, such as a remote system (e.g., 315) or an external resource (e.g., 320), using a transceiver (e.g., 256, 266) and related components.

[0107] In block 422, the processor of the electronic device may perform operations including reporting an indication of the user's determined hydration level based on the determined amount of fluid consumed. To perform the operations in block 422, the processor may use a hydration level determination module (e.g., 370), a hydration level adjustment module (e.g., 375), and / or a hydration level recording / reporting module (e.g., 380). Furthermore, in block 422, the processor may cause a display (e.g., 115) to display an indication of the determined hydration level and / or display an alert (e.g., "Warning, you haven't consumed enough fluids today. Have a drink.") if the determined hydration level falls below a specified threshold. Alternatively, the display may display the amount of fluid consumed and how much should have been consumed at that time of day. Additionally, or as a further alternative, the display may indicate to the user how much more the user should have consumed at that time of day. Additionally, or as a further alternative, in block 422, the processor may activate an audible alert (e.g., a sound or message), flash or blink a light, and / or generate vibration or other tactile feedback to alert the user. Additionally or alternatively, if the determined hydration level is below a specified threshold, the processor may instruct the remote computing device to display an indication of the determined hydration level, display an alarm, activate an audible alarm (e.g., a sound or message), flash or blink a light, and / or generate vibration or other tactile feedback. As a further alternative, the processor may activate a component for performing the operations of block 422, which may include a processor (e.g., 202, 204, 210, 212, 214, 216, 218, 252, 260) coupled to a display, a speaker, a vibration device, a memory (e.g., 220, 258, 325), or obtained from a remote source (such as a remote system (e.g., 315) or an external resource (e.g., 320)) using a transceiver (e.g., 256, 266) and related components.

[0108] Reporting an indication of the determined hydration level to the user can not only help inform the user, but also provide a way to recalibrate the system. For example, if the processor reports a low hydration level that indicates the user is dehydrated, but the user has reason to believe that he / she is not dehydrated (e.g., the urine is light in color), the user can initiate a recalibration routine. This user feedback can be used to further train the hydration level determination module 370. In addition, such feedback can initiate an enhanced calibration routine, such as one that requests the user to perform some measured consumption (e.g., using a wearable device or other computing device), a more direct dehydration test (e.g., using a smart toilet or otherwise collecting a urine sample), or enlist the help of a third party (e.g., a medical practitioner).

[0109] Alternatively, if the processor reports a low hydration level, and the user confirms that he / she is dehydrated, such feedback may be equally useful.

[0110] Figure 4B The method 401 is shown, where the processor can determine a predetermined baseline consumption rate of the user based on a previously counted number of at least one of sips or swallows detected by the sensor when the user consumed a known amount of liquid. In block 424, the processor can determine a predetermined baseline consumption rate of the user based on a previously counted number of at least one of sips or swallows detected by the sensor when the user consumed a known amount of a known type of liquid during a calibration process. Different beverages and different conditions in which these beverages are consumed can establish different baseline consumption rates, which can be determined by the processor. For example, when drinking hot tea as part of an initial calibration process, a user can average thirty-six (36) swallows to drink a cup of eight (8) ounces of tea. Thus, thirty-six (36) swallows of eight (8) ounces of hot beverage can be the predetermined baseline consumption rate determined by the processor. As another example, when drinking a strong alcoholic beverage, such as straight whiskey (i.e., not on ice), a user can average twenty (20) sips to drink two (2) ounces of whiskey. Thus, twenty (20) sips of two (2) ounces of strong alcohol can be the predetermined baseline consumption rate determined by the processor. Similarly, when drinking a carbonated beverage, such as a can of soda, a user can sip thirty-six (36) times to drink eight (8) ounces of the can, establishing a baseline consumption rate for all or most carbonated beverages. In yet another example, when drinking a cup of water that is cool or room temperature, a user can average fifteen (15) swallows to drink a twelve (12) ounce cup of water. Thus, fifteen (15) swallows of twelve (12) ounces of water can be the predetermined baseline consumption rate determined by the processor.

[0111] To perform the operations in block 424, the processor can use the baseline consumption rate determination module 355 and / or the baseline consumption rate adjustment module 360. Means for performing the operations of block 424 can include a processor (e.g., 202, 204, 210, 212, 214, 216, 218, 252, 260) coupled to a memory (e.g., 220, 258, 325) or using a transceiver (e.g., 256, 266) and related components to obtain from a remote source, such as a remote system (e.g., 315) or an external resource (e.g., 320).

[0112] After the initial calibration operation in block 424, the processor can perform the operations in block 420 of the method 400.

[0113] Figure 4CThe method 402 is shown in which the processor can determine a predetermined baseline consumption rate of the user based on manual user input indicative of at least one of a known liquid amount or a number of sips or swallows required to consume the known liquid amount. In block 426, the processor can determine a predetermined baseline consumption rate of the user based on manual user input indicative of at least one of a known liquid amount or a number of sips or swallows required by the user to consume the known liquid amount. For example, when drinking hot coffee as part of an initial calibration process, the user can have manually entered a baseline consumption rate of thirty-five (35) swallows to complete drinking a cup of twelve (12) ounces of hot coffee. Thus, thirty-five (35) swallows of twelve (12) ounces of hot drink can be the predetermined baseline consumption rate determined by the processor. As another example, when consuming yogurt (i.e., a substance that is not entirely liquid nor entirely solid), the user can confirm that the processor estimates twelve (12) swallows to complete eating six (6) ounces of yogurt. Thus, twelve (12) swallows of six (6) ounces of yogurt can be the predetermined baseline consumption rate determined by the processor.

[0114] To perform the operations in block 426, the processor can use a baseline consumption rate determination module (e.g., 355) and / or a baseline consumption rate adjustment module (e.g., 360). Means for performing the operations of block 426 can include a processor (e.g., 202, 204, 210, 212, 214, 216, 218, 252, 260) coupled to a memory (e.g., 220, 258, 325) or using a transceiver (e.g., 256, 266) and related components to obtain from a remote source such as a remote system (e.g., 315) or an external resource (e.g., 320).

[0115] After the initial calibration operation in block 426, the processor can perform the operations in block 420 of the method 400.

[0116] Figure 4DMethod 403 is shown in which the processor may determine a predetermined baseline consumption rate for a user based on the context in which the liquid is consumed. In box 428, the processor may determine a predetermined baseline consumption rate for the user based on the context in which the liquid is consumed. For example, the user may be accustomed to drinking a four (4) ounce energy drink at 6:00 a.m. Monday through Friday, which is consumed in two (2) gulps (i.e., two large swallows). To accommodate this situation, the user may perform an initial calibration procedure in the morning to determine a baseline consumption rate for the liquid at that time of day. Thereafter, in response to the processor determining that the time is 6:00 a.m. on Tuesday, the processor may use the baseline consumption rate associated with the particular energy drink stored in memory. As another example, after an intense aerobic workout, the user may drink water faster than normal, requiring only eight (8) swallows to drink an eight (8) ounce glass of water, whereas the user would otherwise require twelve (12) swallows to drink that much water. Thus, in response to the processor determining that the user has just completed a vigorous aerobic exercise, the processor may use the baseline consumption rate associated with eight (8) swallows of eight (8) ounces of water stored in memory after the initial calibration procedure of box 428.

[0117] To perform the operations in block 428, the processor may use a baseline consumption rate determination module (e.g., 355) and / or a baseline consumption rate adjustment module (e.g., 360). Means for performing the operations in block 428 may include a processor (e.g., 202, 204, 210, 212, 214, 216, 218, 252, 260) coupled to a memory (e.g., 220, 258, 325) or obtained from a remote source (e.g., a remote system (e.g., 315) or an external resource (e.g., 320)) using a transceiver (e.g., 256, 266) and related components.

[0118] After the operations in block 428 , the processor may perform the operations in block 420 of the method 400 .

[0119] Figure 4EMethod 404 is shown, in which the processor may select a predetermined baseline consumption rate for the user based on the type of liquid being consumed as detected by a sensor. In block 430, the processor may use sensor input received by the processor indicating what type of fluid is being consumed to select a predetermined baseline consumption rate for the user based on the context in which the liquid is being consumed. For example, the user may be drinking hot tea, which a thermal sensor on the user's smart glasses has detected as a hot beverage (i.e., above a predetermined temperature). The processor may receive an indication from the thermal sensor that a hot beverage is being consumed and, based on this information, select a predetermined baseline consumption rate determined for hot beverages. To determine a predetermined baseline consumption rate for tea or other hot beverages, the user may perform an initial calibration procedure in which the user drinks the same or similar hot tea and / or other hot beverage under controlled and measured conditions. Thereafter, in response to the processor determining that the user is drinking the same or similar hot beverage, the processor may use a baseline consumption rate associated with that type of liquid stored in memory. Thus, in response to the processor receiving an indication of the type of liquid being consumed, the processor may select an appropriate baseline consumption rate stored in memory to determine the amount of liquid consumed by the user.

[0120] To perform the operations in block 430, the processor may use a consumption type determination module (e.g., 345) and / or a baseline consumption rate determination module (e.g., 355). Components for performing the operations in block 430 may include a processor (e.g., 202, 204, 210, 212, 214, 216, 218, 252, 260) coupled to a memory (e.g., 220, 258, 325) and one or more devices with sensors (e.g., smart glasses 130, sensor-equipped neckband 150, smart watch 170, headset 180, etc.), or obtained from a remote source (e.g., a remote system (e.g., 315) or an external resource (e.g., 320)) using a transceiver (e.g., 256, 266) and related components.

[0121] After the operations in block 430 , the processor may perform the operations in block 420 of the method 400 .

[0122] Figure 4FThe method 405 is shown, where the processor can determine an update to a previously determined baseline consumption rate of the user based on liquid consumption information from at least one of a sensor, user input, or a context in which the liquid was consumed. In block 432, the processor can determine an update to a previously determined baseline consumption rate of the user based on liquid consumption information from at least one of a sensor, user input, or a context in which the liquid was consumed. For example, a user can repeatedly drink ten (10) ounces of iced tea using a smart cup for several consecutive days, and a neckband equipped with a sensor (e.g., 150) detects that the user swallows thirteen (13) sips to finish. As part of the operation in block 432, the processor can compare the previously determined baseline consumption rate of the user for iced tea to the most recent consecutive smart cup usage to determine that the previously determined baseline consumption rate is inaccurate and needs to be updated. As another example, a user can manually input an indication that the previously determined baseline consumption rate needs to be updated, thereby initiating a calibration protocol. In response to the processor determining that the previously determined baseline consumption rate needs to be updated, the processor can determine an update to the previously determined baseline consumption rate in block 432. In another example, when the ambient temperature drops below freezing, a record can indicate that the user’s baseline consumption rate also drops by ten percent (10%) from its usual consumption rate. Thus, in response to the processor determining that the ambient temperature is below freezing, the processor can identify and / or edit an update to the previously determined baseline consumption rate for drinking in freezing conditions.

[0123] To perform the operations in block 432, the processor can use a baseline consumption rate determination module (e.g., 355) and / or a baseline consumption rate adjustment module (e.g., 360). Means for performing the operations of block 432 can include a processor (e.g., 202, 204, 210, 212, 214, 216, 218, 252, 260) coupled to a memory (e.g., 220, 258, 325) or using a transceiver (e.g., 256, 266) and related components to obtain from a remote source such as a remote system (e.g., 315) or an external resource (e.g., 320).

[0124] After the operations in block 432, the processor can perform the operations in block 420 of the method 400, where the predetermined baseline consumption rate is based on the update to the previously determined baseline consumption rate of the user.

[0125] Figure 4G The method 406 is shown, according to some embodiments, by which a processor of an electronic device can receive context information and further determine a hydration level of a user based at least in part on a context in which the user made the number of sips or swallows.

[0126] In block 434, following the operations in block 420, the processor of the electronic device may perform operations including receiving contextual information indicating the context in which the user took at least one of the number of sips or swallows. To perform the operations in block 434, the processor may use the contextual information receiving module 350. The components for performing the operations in block 434 may include a processor (e.g., 202, 204, 210, 212, 214, 216, 218, 252, 260) coupled to a memory (e.g., 220, 258, 325) or obtained from a remote source (e.g., a remote system (e.g., 315) or an external resource (e.g., 320)) using a transceiver (e.g., 256, 266) and related components.

[0127] As a non-limiting example, context information may be received from a sensor that provides information to an electronic device (e.g., user device 110) and / or a local computing device near the electronic device (e.g., smart glasses 130, sensor-equipped neckband 150, smartwatch 170, headset 180, etc.). Context information may also be received by accessing a database containing one or more data records stored in a local memory (e.g., 220, 258, 325) or obtained from a remote source (e.g., a remote system (e.g., 315) or an external resource (e.g., 320)) using a transceiver (e.g., 256, 266) and related components.

[0128] In block 436, the processor may further determine the user's hydration level based in part on the context in which the user performed at least one of the number of sips or swallows. For example, the processor may receive an indication that the user has just performed an intense workout. A database lookup may indicate that such activity requires intake of ten percent (10%) more fluid to maintain an appropriate hydration level. Thus, based on contextual information about the user's activity level, the processor may determine the user's hydration level while taking into account the increased activity level. As another example, the processor may detect that the user consumed a drink and / or food with antidiuretic properties. A database lookup may indicate that, due to the water-retaining properties of the antidiuretic, such an antidiuretic requires intake of five percent (5%) less fluid to maintain an appropriate hydration level. Thus, based on contextual information about the user's consumption of the drink and / or food, the processor may determine the user's hydration level while taking into account the contextual information.

[0129] To perform the operations in block 436, the processor can utilize the hydration level determination module 370 and / or the hydration level adjustment module 375 in conjunction with the contextual information receiving module 350. Furthermore, in block 436, the processor can access a database containing one or more data records stored in a local memory (e.g., 220, 258) or obtained from a remote source (e.g., a remote system (e.g., 315) or an external resource (e.g., 320)) using a transceiver (e.g., 256, 266) and related components. The database can provide information useful for determining the user's hydration level, including the user's baseline consumption rate and / or the number of sips and / or swallows the user makes when consuming liquids. Furthermore, the database can include contextual information relevant to the calculation of the user's hydration level. Means for performing the operations of block 436 may include a processor (e.g., 202, 204, 210, 212, 214, 216, 218, 252, 260) coupled to a memory (e.g., 220, 258, 325) or obtained from a remote source, such as a remote system (e.g., 315) or an external resource (e.g., 320), using a transceiver (e.g., 256, 266) and related components.

[0130] After the operations in block 436 , the processor may perform the operations in block 422 of the method 400 .

[0131] Figure 4H Method 407 is shown in which the processor may determine whether the user consumed solids along with the amount of liquid consumed to determine whether sipping rather than swallowing is used to measure liquid consumption.

[0132] In determination block 438, after the operations in block 420, the processor of the electronic device can perform operations including determining whether the user consumed a solid with the consumed amount of liquid. For example, the user can be drinking a drink with ice or eating a thick soup (i.e., containing large chunks of meat, vegetables, and / or noodles). To make the determination in determination block 438, the processor can use a consumption type determination module (e.g., 345). Further, in determination block 438, the processor can access a database containing one or more data records stored in local memory (e.g., 220, 258) or obtained from a remote source, such as a remote system (e.g., 315) or an external resource (e.g., 320), using a transceiver (e.g., 256, 266) and related components. The database can provide information about the consumed substance. The components for performing the operations of block 420 can include a processor (e.g., 202, 204, 210, 212, 214, 216, 218, 252, 260) coupled to memory (e.g., 220, 258, 325) or obtained from a remote source, such as a remote system (e.g., 315) or an external resource (e.g., 320), using a transceiver (e.g., 256, 266) and related components.

[0133] In response to determining that the user did not consume a solid with the consumed amount of liquid (i.e., determination block 438 = "No"), the processor can perform the operations in block 420.

[0134] In response to determining that the user consumed a solid with the consumed amount of liquid (i.e., determination block 438 If the user is satisfied that the user has consumed a certain amount of liquid, the processor may perform operations in block 439 including determining the amount of liquid consumed by the user based on a predetermined baseline consumption rate for the user and a number of sips taken by the user as detected by a sensor coupled to the processor. To implement the determination in block 439, the processor may use a baseline consumption rate determination module (e.g., 355) and / or a baseline consumption rate adjustment module (e.g., 360) to determine the baseline consumption rate for the user and, in conjunction with a consumption determination module (e.g., 365), determine the amount of liquid consumed by the user. Additionally, in block 439, the processor may access a database containing one or more data records stored in a local memory (e.g., 220, 258) or using a transceiver. (e.g., 256, 266) and related components are obtained from a remote source, such as a remote system (e.g., 315) or an external resource (e.g., 320). The database may provide information about the user's baseline consumption rate and / or the number of sips and / or swallows taken by the user when consuming liquids. The components for performing the operations of block 439 may include a processor (e.g., 202, 204, 210, 212, 214, 216, 218, 252, 260) coupled to a memory (e.g., 220, 258, 325) or obtained from a remote source, such as a remote system (e.g., 315) or an external resource (e.g., 320) using a transceiver (e.g., 256, 266) and related components.

[0135] After the operations in block 439 , the processor may perform the operations in block 422 of the method 400 .

[0136] Figure 4I Method 408 is shown by which a processor of an electronic device may receive an indication of a type of liquid consumed by a user, in accordance with some embodiments.

[0137] In block 440, the processor of the electronic device may perform operations including receiving an indication of the type of liquid consumed by the user. To perform the operations in block 440, the processor may use the consumption type determination module 345. The components for performing the operations of block 440 may include a processor (e.g., 202, 204, 210, 212, 214, 216, 218, 252, 260) coupled to a memory (e.g., 220, 258, 325) or obtained from a remote source (e.g., a remote system (e.g., 315) or an external resource (e.g., 320)) using a transceiver (e.g., 256, 266) and related components.

[0138] As a non-limiting example, an indication of the type of liquid consumed by the user can be received from a sensor that provides information to an electronic device (e.g., user device 110) and / or a local computing device near the electronic device (e.g., smart glasses 130, sensor-equipped neckband 150, smartwatch 170, headphones 180, etc.). The indication of the type of liquid consumed can also be received by accessing a database containing one or more data records stored in a local memory (e.g., 220, 258, 325) or obtained from a remote source (such as a remote system (e.g., 315) or an external resource (e.g., 320)) using a transceiver (e.g., 256, 266) and related components.

[0139] Following the operations in block 440 , the processor may perform the operations in block 420 of the method 400 , wherein the determined amount of liquid consumed by the user is further based on the type of liquid consumed by the user.

[0140] Figure 4J Method 409 is shown by which a processor of an electronic device may receive food consumption information and further determine a hydration level of a user based in part on the received food consumption information, in accordance with some embodiments.

[0141] In box 442, after the operation in box 420, the processor of the electronic device can perform operations including receiving food consumption information associated with the food consumed by the user. For example, the processor can receive liquid content information about the food or interactive characteristics of the food (which include diuresis, antidiuresis and / or other characteristics). To perform the operations in box 442, the processor can use the consumption type determination module 345. The components for performing the operations of box 442 may include a processor (e.g., 202, 204, 210, 212, 214, 216, 218, 252, 260), which is coupled to a memory (e.g., 220, 258, 325) or obtained from a remote source (such as a remote system (e.g., 315) or an external resource (e.g., 320)) using a transceiver (e.g., 256, 266) and related components.

[0142] As a non-limiting example, the consumption information may be received from a sensor that provides information to an electronic device (e.g., user device 110) and / or a local computing device near the electronic device (e.g., smart glasses 130, sensor-equipped neckband 150, smartwatch 170, headset 180, etc.). The consumption information may also be received by accessing a database containing one or more data records stored in a local memory (e.g., 220, 258, 325) or obtained from a remote source (e.g., a remote system (e.g., 315) or an external resource (e.g., 320)) using a transceiver (e.g., 256, 266) and related components.

[0143] In block 444, the processor can further determine a hydration level of the user based in part on the received food consumption information. For example, the processor can receive an indication that the user has just eaten a large piece of watermelon, some or other food. A database lookup can indicate that such food contains an average percentage of liquid. Thus, based on the received food consumption information, the processor can determine an estimate of the user's hydration level.

[0144] To perform the operations in block 444, the processor can use hydration level determination module 370 and / or hydration level adjustment module 375 in conjunction with consumption type determination module 345. Further, in block 444, the processor can access a database containing one or more data records stored in local memory (e.g., 220, 258) or obtained from a remote source such as a remote system (e.g., 315) or external resource (e.g., 320) using a transceiver (e.g., 256, 266) and related components. The database can provide information for determining a hydration level of the user, including a liquid content of the identified consumed food. Further, the database can include consumption information related to the calculation of the user's hydration level. Means for performing the operations of block 436 can include a processor (e.g., 202, 204, 210, 212, 214, 216, 218, 252, 260) coupled to memory (e.g., 220, 258, 325) or obtaining from a remote source such as a remote system (e.g., 315) or external resource (e.g., 320) using a transceiver (e.g., 256, 266) and related components.

[0145] After the operations in block 444, the processor can perform the operations in block 422 of the method 400.

[0146] Figure 5 A method 500 according to various embodiments is shown that can be performed by a processor of an electronic device and / or one or more other computing devices for tracking hydration of a user. The operations of the method 500 are intended to be illustrative. In some embodiments, the method 500 can be completed with one or more additional operations not described, and / or without one or more of the Figure 5 The order in which the operations of the method 500 are illustrated and described below is not intended to be limiting.

[0147] Reference is made to Figure 1-Figure 5The method 500 may be implemented in one or more processors (e.g., 202, 204, 210, 212, 214, 216, 218, 252, 260) of an electronic device (e.g., user device 110), a wearable device (e.g., 130, 150, 170), and other computing devices configured with processor-executable instructions stored on a non-transitory processor-readable storage medium. The one or more processors may include one or more devices configured by hardware, firmware, and / or software specifically designed to perform one or more operations of the method.

[0148] In block 510, a processor of the electronic device may perform operations including receiving an indication of consumption by a user or determining that a hydration level check is required. The received indication of consumption may come from sensor input consistent with consumption (such as swallowing, sipping, chewing, etc.). The determination of the need for a hydration level check may be based on various factors, such as time, interval since the last check, user activity, contextual information, etc. To perform the operations in block 510, the processor may use a consumption indication receiving module 340, such as a clock. The components for performing the operations in block 510 may include a processor (e.g., 202, 204, 210, 212, 214, 216, 218, 252, 260), coupled to a memory (e.g., 220, 258, 325) or obtained from a remote source (such as a remote system (e.g., 315) or an external resource (e.g., 320)) using a transceiver (e.g., 256, 266) and related components.

[0149] As a non-limiting example, the consumption indication information may be received from a sensor that provides information to the electronic device (e.g., user device 110) and / or a local computing device near the electronic device (e.g., smart glasses 130, sensor-equipped neckband 150, smartwatch 170, headset 180, etc.). The consumption indication information may also be received by accessing a database containing one or more data records stored in a local memory (e.g., 220, 258, 325) or obtained from a remote source (e.g., a remote system (e.g., 315) or an external resource (e.g., 320)) using a transceiver (e.g., 256, 266) and related components.

[0150] In determination block 515, the processor may determine whether the user is eating and / or drinking based on the indication of consumption received in block 510. To make the determination in determination block 515, the processor may use a consumption type determination module (e.g., 345). In addition, in determination block 515, the processor may access a database containing one or more data records stored in a local memory (e.g., 220, 258) or obtained from a remote source (e.g., a remote system (e.g., 315) or an external resource (e.g., 320)) using a transceiver (e.g., 256, 266) and related components. The database may provide information about the substance consumed. Means for performing the operations of box 515 may include a processor (e.g., 202, 204, 210, 212, 214, 216, 218, 252, 260) coupled to a memory (e.g., 220, 258, 325) or obtained from a remote source (such as a remote system (e.g., 315) or an external resource (e.g., 320)) using a transceiver (e.g., 256, 266) and related components.

[0151] In response to determining that the user is not eating and / or drinking (ie, determination block 515 =“No”), the processor may determine the user's hydration level in block 570 .

[0152] In response to determining that the user is eating and / or drinking something (i.e., determination block 515 = "Yes"), the processor can determine whether the substance being consumed is a liquid, or whether the substance being consumed is a solid or a solid / liquid mixture. To make the determination in determination block 520, the processor can use a consumption type determination module (e.g., 345). In addition, in determination block 520, the processor can access a database containing one or more data records stored in local memory (e.g., 220, 258) or obtained from a remote source (such as a remote system (e.g., 315) or an external resource (e.g., 320)) using a transceiver (e.g., 256, 266) and related components. The database can provide information about the substance being consumed. Means for performing the operations of block 520 may include a processor (e.g., 202, 204, 210, 212, 214, 216, 218, 252, 260) coupled to a memory (e.g., 220, 258, 325) or obtained from a remote source, such as a remote system (e.g., 315) or an external resource (e.g., 320), using a transceiver (e.g., 256, 266) and related components.

[0153] In response to determining that the user is drinking a liquid (i.e., determination block 520 = "Liquid"), the processor may determine a predetermined baseline consumption rate for liquid consumption applicable to the user. Various factors may be considered to determine which predetermined baseline consumption rate to use, such as whether a known liquid is being consumed, whether user input is received or available, and / or whether contextual information is available or applicable. The determination of the predetermined baseline consumption rate in block 530 may include the operations in blocks 424, 426, 428, and / or 430 of methods 401, 402, 403, and / or 404.

[0154] In block 540 , the processor may determine the amount of fluid consumed by the user by counting the number of sips or swallows and correlating that count with the total fluid consumed based on a predetermined baseline consumption rate, such as by using the operations in blocks 420 or 439 of method 400 or 406 .

[0155] In determination block 545, the processor may determine whether the consumed substance includes a diuretic or an antidiuretic. To make this determination in determination block 520, the processor may use a consumption type determination module (e.g., 345). Additionally, in determination block 520, the processor may access a database containing one or more data records stored in a local memory (e.g., 220, 258) or obtained from a remote source (e.g., a remote system (e.g., 315) or an external resource (e.g., 320)) using a transceiver (e.g., 256, 266) and associated components. The database may provide information about the diuretic or antidiuretic properties of the consumed substance. Means for performing the operations of block 520 may include a processor (e.g., 202, 204, 210, 212, 214, 216, 218, 252, 260) coupled to a memory (e.g., 220, 258, 325) or obtained from a remote source, such as a remote system (e.g., 315) or an external resource (e.g., 320), using a transceiver (e.g., 256, 266) and related components.

[0156] In response to determining that the consumed substance includes a diuretic or antidiuretic (ie, determination block 545 Yes), the processor may determine a hydration adjustment based on the consumed fluid in block 550. To perform the operations in block 550, the processor may use the hydration level adjustment module 375. Additionally, in block 550, the processor may access a database containing one or more data records stored in a local memory (e.g., 220, 258) or obtained from a remote source (e.g., a remote system (e.g., 315) or an external resource (e.g., 320)) using a transceiver (e.g., 256, 266) and related components. The database may provide Information for determining adjustments to the user's hydration level based on the type and amount of diuretic or antidiuretic consumed. Means for performing the operations of block 550 may include a processor (e.g., 202, 204, 210, 212, 214, 216, 218, 252, 260) coupled to a memory (e.g., 220, 258, 325) or obtained from a remote source (e.g., a remote system (e.g., 315) or an external resource (e.g., 320)) using a transceiver (e.g., 256, 266) and related components.

[0157] In response to determining that the user is consuming a solid or a solid / liquid mixture (i.e., determination block 520 = "(Solid or Solid / Liquid Mixture)"), the processor may determine the water content of the consumed solid or solid / liquid mixture at block 560. In determining the water content, the processor may use a consumption type determination module 345, which may access a database of one or more data records containing information about the water content in various foods and drinks, the data records being stored in a memory (e.g., 220, 258, 325) or obtained from a remote source (e.g., a remote system (e.g., 315) or an external resource (e.g., 320)) using a transceiver (e.g., 256, 266) and related components. The processor of the electronic device may access the data records to determine how much water is in the consumed solid or solid / liquid mixture. For example, a lookup table may provide an estimate of how much water is contained in a particular food or drink containing a solid (e.g., fruit, ice, etc.).

[0158] In response to determining that the consumed substance does not include a diuretic or antidiuretic (i.e., determination block 545 = "No"), after determining that the user is not eating and / or drinking anything (i.e., determination block 515 = "No"), after hydration adjustment in block 550, or after determining the water content of the solid or solid / liquid mixture in block 560, the processor can determine the user's hydration level in block 570. The processor can determine the user's hydration level based on the consumed liquid and, optionally, additional water from any food consumed. To perform the operations in block 444, the processor can use the hydration level determination module 370 and / or the hydration level adjustment module 375 in conjunction with the consumption type determination module 345. In addition, in block 444, the processor can access a database containing one or more data records stored in local memory (e.g., 220, 258) or obtained from a remote source (e.g., a remote system (e.g., 315) or an external resource (e.g., 320)) using a transceiver (e.g., 256, 266) and related components. The database can provide information for determining the user's hydration level, including the liquid content of the identified consumed food. In addition, the database can include consumption information related to the calculation of the user's hydration level. The components for performing the operations of block 436 can include a processor (e.g., 202, 204, 210, 212, 214, 216, 218, 252, 260) coupled to a memory (e.g., 220, 258, 325) or obtained from a remote source (such as a remote system (e.g., 315) or an external resource (e.g., 320)) using a transceiver (e.g., 256, 266) and related components.

[0159] In determination block 575, the processor may determine whether the determined hydration level is within a threshold. For example, the threshold may be a minimum healthy hydration level. As another example, the threshold may be a target healthy threshold for a particular activity level of the user. As another example, the threshold may be in the form of a minimum threshold and a maximum threshold, where the minimum threshold is a minimum healthy hydration level and the maximum threshold is a maximum hydration level consistent with healthy activity. Furthermore, the threshold may be user-specific, such as based on the user's age, weight, gender, medical condition, and other personal health characteristics.

[0160] In response to determining that the determined hydration level is not within the threshold (ie, determination block 575 = "No"), the processor may alert the user, such as by displaying a report of the hydration level in block 580, such as Figure 1 In block 580 , the processor reports the hydration level, which may be similar to the operation in block 422 of the method 400 .

[0161] In response to determining that the determined hydration level is within the threshold (i.e., determination block 575 = "Yes"), or after reporting the hydration level in block 580, the processor can record the hydration level in local memory (e.g., 220, 258), or using a transceiver (e.g., 256, 266) and related components in memory of a remote source, such as a remote system (e.g., 315) or an external resource (e.g., 320), in block 590.

[0162] The operations in method 500 can be performed at any time when the user begins to consume a liquid or food.

[0163] Figure 6 Method 600 is shown, which can be performed as part of method 500 by using separate baseline consumption rates for liquids and food (i.e., solids or solid / liquid mixtures in some embodiments). The operations in method 600 can be performed by a processor of an electronic device and / or one or more other computing devices for tracking hydration of a user, according to various embodiments. The operations of method 600 are intended to be illustrative. In some embodiments, method 600 can be accomplished with one or more additional operations not described, and / or without one or more of the operations discussed. Additionally, the order in which the operations of method 600 are illustrated and described is not intended to be limiting. Figure 6 The order in which the operations of method 600 are illustrated and described below is not intended to be limiting.

[0164] Referring to Figures 1-6 Method 600 can be implemented in one or more processors (e.g., 202, 204, 210, 212, 214, 216, 218, 252, 260) of an electronic device (e.g., user device 110), a wearable device (e.g., 130, 150, 170), and other computing devices configured with processor-executable instructions stored on a non-transitory processor-readable storage medium, according to various embodiments. The one or more processors can include one or more devices configured by hardware, firmware, and / or software designed specifically for performing one or more operations of the method.

[0165] In response to determining that the user is consuming or has consumed a solid or solid / liquid mixture (i.e., determination block 520 = "solid or solid / liquid mixture"), the processor can determine a predetermined baseline solid or solid / liquid mixture consumption rate applicable to the user's solid or solid / liquid mixture consumption in block 630. The determination of the predetermined baseline solid or solid / liquid mixture consumption rate in block 630 can be performed using operations similar to those applied to the liquid consumption determination in blocks 424, 426, 428, and / or 530 of methods 401, 402, 403, and / or 500.

[0166] In block 640, the processor can determine an amount of liquid consumed from the solid or solid / liquid mixture consumed by the user. The determination of the amount of liquid consumed from the solid or solid / liquid mixture consumed in block 640 can be performed using similar operations as applied in block 420 or 439 of the methods 400 or 406, respectively.

[0167] Various embodiments, including but not limited to the embodiments discussed above with reference to Figures 1-6 may be implemented on various computing devices, examples of which are illustrated in Figure 7 the form of a server in FIG. 7. With reference to Figure 1-Figure 7 , the network computing device 700 can include a processor 701 coupled to volatile memory 702 and large capacity nonvolatile memory, such as a disk drive 703. The network computing device 700 can also include a peripheral memory access device coupled to the processor 701, such as a floppy disk drive, a compact disc (CD) or digital video disc (DVD) drive 706. The network computing device 700 can also include a network access port 704 (or interface) coupled to the processor 701 for establishing data connections with a network, such as the Internet and / or a local area network coupled to other system computers and servers. The network computing device 700 can include one or more antennas 707 for sending and receiving electromagnetic radiation, which can be connected to a wireless communication link. The network computing device 700 can include additional access ports, such as USB, Firewire, Thunderbolt interface, etc., for coupling to peripheral devices, external memory or other devices.

[0168] Various embodiments, including but not limited to the embodiments discussed above with reference to Figures 1-6 may be implemented on various computing devices, examples of which are illustrated in Figure 8 the form of a mobile computing device in FIG. 8. With reference to Figures 1-8 , the mobile computing device 800 can include a first SoC 202 (e.g., SoC-CPU) coupled to a second SoC 204 (e.g., 5G-capable SoC), such as a D2D link established in a dedicated ITS 5.9 GHz spectrum communication. The first and / or second SoCs 202, 204 can be coupled to internal memory 325, 825, a display 115, and a speaker 814. In addition, the mobile computing device 800 can include one or more antennas 804 for sending and receiving electromagnetic radiation, which can be connected to one or more wireless transceivers 266 (e.g., wireless data link and / or cellular transceiver, etc.) coupled to one or more processors in the first and / or second SoCs 202, 204. The mobile computing device 800 can also include menu selection buttons or a rocker switch 820 for receiving user input.

[0169] The mobile computing device 800 may also include a sound coding / decoding (CODEC) circuit 810 that digitizes sound received from a microphone into data packets suitable for wireless transmission and decodes the received sound data packets to generate an analog signal, which is provided to a speaker to generate sound. In addition, one or more of the processors in the first and / or second SOCs 202 and 204, the wireless transceiver 266, and the CODEC circuit 810 may include a digital signal processor (DSP) circuit (not separately shown).

[0170] Various embodiments (including the above reference Figures 1-6 The embodiments discussed herein can be implemented on various wearable devices, examples of which are shown in FIG. Figure 9 1 is shown in the form of a pair of smart glasses 130. Figures 1-9 , a pair of smart glasses 130 can operate like traditional glasses, but with enhanced computer features and sensors, like a built-in camera 135 and a heads-up display or augmented reality feature on or near the lens 131. Like any glasses, the smart glasses can include a frame 902 coupled to temples 904 that fit alongside the wearer's head and behind the ears. The frame 902 holds the lens 131 in place in front of the wearer's eyes when the nose pads 906 on the nose bridge 908 rest on the wearer's nose.

[0171] In some embodiments, the smart glasses 130 may include an image presentation device 914 (e.g., an image projector) that may be embedded in one or both temples 904 of the frame 902 and configured to project an image onto the optical lens 131. In some embodiments, the image presentation device 914 may include a light emitting diode (LED) module, a light tunnel, a homogenizing lens, an optical display, a folding mirror, or other components of a well-known projector or head-mounted display. In some embodiments (e.g., where the image presentation device 914 is not included or used), the optical lens 131 may be or may include a see-through or partially see-through electronic display. In some embodiments, the optical lens 131 includes an image generating element, such as a see-through organic light emitting diode (OLED) display element or a liquid crystal on silicon (LCOS) display element. In some embodiments, the optical lens 131 may include independent left-eye and right-eye display elements. In some embodiments, the optical lens 131 may include or operate as a light guide for transferring light from the display element to the wearer's eyes.

[0172] The smart glasses 130 can include a plurality of external sensors that can be configured to obtain information about the wearer's movements and external conditions, which can be used to sense images, sounds, muscle movements, and other phenomena that can be used to detect when the wearer consumes liquids, as described. In some embodiments, the smart glasses 130 can include a camera 135 that is configured to image objects in front of the wearer in the form of a still image or video stream, which can be transmitted to another computing device (e.g., mobile device 800) for analysis. In some embodiments, the smart glasses 130 can include a microphone 910 that is positioned and configured to record sounds near the wearer. In some embodiments, multiple microphones can be positioned at different locations on the frame 902, such as at the distal end of the temple 904 near the jaw, to record sounds made by the wearer, such as jaw movements, chewing sounds, swallowing sounds, etc. In some embodiments, the smart glasses 130 can include one or more electromyograms 916 mounted on one or both temples 904, such as near the temple or above the ear, which are configured to measure the electrical activity of nerves and muscles in the jaw and temple area of ​​the wearer. In some embodiments, smart glasses 130 may include pressure sensors, such as on nose pads 906, that are configured to sense facial motion. In some embodiments, smart glasses 130 may include other sensors (e.g., a thermometer, a heart rate monitor, a body temperature sensor, a pulse oximeter, etc.) for collecting information about the environment and / or user conditions that may be used to detect when the wearer consumes liquids.

[0173] The processing system 912 may include a processing and communication SOC 202, which may include one or more processors (e.g., 202, 204, 210, 212, 214, 216, 218), one or more of which may be configured with processor-executable instructions to perform the operations of various embodiments. The processing and communication SOC 202 may be coupled to internal sensors 920, internal memory 922, and communication circuitry 924, which is coupled to one or more antennas 926 for establishing a wireless data link with an external computing device (e.g., mobile device 800), such as via a Bluetooth link. The processing and communication SOC 202 may also be coupled to a sensor interface circuit 928, which is configured to control and receive data from the camera 135, the microphone 910, one or more electromyograms 916, and other sensors located on the frame 902.

[0174] The internal sensors 920 can include an IMU including electronic gyroscopes, accelerometers, and magnetic compasses configured to measure motion and orientation of the wearer's head. The internal sensors 920 can also include a magnetometer, altimeter, odometry, and barometric pressure sensor, among other sensors for determining the orientation and motion of the smart glasses 130. Such sensors can be used in various embodiments to detect head motion related to the consumption of the liquid.

[0175] The processing system 912 can also include a power source, such as a rechargeable battery 930, coupled to the SOC 202 and to external sensors on the frame 902.

[0176] The processor implementing various embodiments can be any programmable microprocessor, microcomputer or one or more processors chips that can be configured by software instructions (applications) to perform a variety of functions, including the functions of the various aspects described in this application. In some communications devices, multiple processors can be provided, such as one processor dedicated to wireless communication functions and one processor dedicated to running other applications. Typically, software applications can be stored in the internal memory before being accessed and loaded into the processor. The processor can include internal memory sufficient to store the application software instructions.

[0177] As used in this application, the terms "component," "module," "system" and the like are intended to refer to a computer-related entity, either hardware, firmware, a combination of hardware and software, software, or software in execution, configured to perform particular operations or functions. For example, a component can be, but is not limited to being, a process running on a processor, a processor, an object, an executable, a thread of execution, a program, and / or a computer. By way of illustration, both an application running on a communication device and the communication device can be referred to as a component. One or more components can reside within a process and / or thread of execution and a component can be localized, co-resident, and / or distributed across one or more processes and / or threads of execution. Also, these components can be executed from various non-transitory computer-readable media having various instructions executing on one or more computer systems. Components can communicate via local and / or remote processes, function- or procedure-calls, electronic signals, data packets, memory reads / writes, and other known communications methodologies within and / or between computer systems, computer processors, and / or processes.

[0178] Many different cellular and mobile communication services and standards are achievable or anticipated in the future, all of which can be implemented and benefit from various aspects. These services and standards may include, for example, the Third Generation Partnership Project (3GPP), Long Term Evolution (LTE), third generation wireless mobile communication technology (3G), fourth generation wireless mobile communication technology (4G), fifth generation wireless mobile communication technology (5G), Global System for Mobile Communications (GSM), Universal Mobile Telecommunications System (UMTS), 3GSM, General Packet Radio Service (GPRS), Code Division Multiple Access (CDMA) systems (e.g., cdmaOne, CDMA1020™), EDGE, Advanced Mobile Phone System (AMPS), Digital AMPS (IS-136 / TDMA), Evolution-Data Optimized (EV-DO), Digital Enhanced Cordless Telecommunications (DECT), Worldwide Interoperability for Microwave Access (WiMAX), Wireless Local Area Network (WLAN), Protected Wireless Computer Networks I & II (WPA, WPA2), Integrated Digital Enhanced Network (iden), C-V2X, V2V, V2P, V2I and V2N, etc. Each of these technologies involves, for example, the transmission and reception of voice, data, signaling, and / or content messages. It should be understood that any reference to terminology and / or technical details related to a single telecommunications standard or technology is for illustrative purposes only and is not intended to limit the scope of the claims to a particular communication system or technology unless specifically stated in the claim language.

[0179] The various aspects shown and described are provided merely as examples to illustrate various features of the claims. However, the features shown and described with respect to any given aspect are not necessarily limited to the related aspect, but may be used or combined with other aspects shown and described. Furthermore, the claims are not intended to be limited by any one example aspect. For example, one or more operations of these methods may be substituted for or combined with one or more operations of these methods.

[0180] The foregoing method descriptions and process flow charts are provided as illustrative examples only and are not intended to require or imply that the operations of the various aspects must be performed in the order presented. As will be understood by those skilled in the art, the operations in the foregoing aspects may be performed in any order. Words such as "thereafter," "then," "next," etc. are not intended to limit the order of operations; these words are used to guide the reader through the description of these methods. In addition, any reference to a claim element in the singular, such as the use of the articles "a," "an," or "the," should not be construed as limiting the element to the singular.

[0181] The various illustrative logical blocks, modules, components, circuits, and algorithm operations described in connection with the aspects disclosed herein can be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and operations have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans can implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the claims.

[0182] The hardware used to implement the various illustrative logics, logical blocks, modules, and circuits described in connection with the aspects disclosed herein can be implemented or performed with a general purpose processor, a digital signal processor (DSP), an ASIC, a field

[0183] In one or more aspects, the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, these functions may be stored as one or more instructions or codes on a non-transitory computer-readable storage medium or a non-transitory processor-readable storage medium. The operations of the methods or algorithms disclosed herein may be embodied in a processor-executable software module or processor-executable instructions, which may reside on a non-transitory computer-readable or processor-readable storage medium. A non-transitory computer-readable or processor-readable storage medium may be any storage medium that can be accessed by a computer or processor. By way of example and not limitation, such non-transitory computer-readable or processor-readable storage medium may include RAM, ROM, EEPROM, flash memory, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage smart objects, or any other medium that can be used to store the desired program code in the form of instructions or data structures and that can be accessed by a computer. Disks and optical disks used herein include compact discs (CDs), laser discs, optical discs, digital versatile discs (DVDs), floppy disks, and Blu-ray discs, where disks typically reproduce data magnetically, while optical discs reproduce data optically with lasers. Combinations of the above are also included within the scope of non-transitory computer-readable and processor-readable media. Furthermore, the operations of a method or algorithm may reside as one or any combination or set of codes and / or instructions on a non-transitory processor-readable storage medium and / or computer-readable storage medium, which may be incorporated into a computer program product.

[0184] The foregoing description of the disclosed aspects is intended to enable any person skilled in the art to make or use the claims. Various modifications to these aspects will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other aspects without departing from the scope of the claims. Therefore, the present disclosure is not intended to be limited to the aspects shown herein but is to be accorded the widest scope consistent with the following claims and the principles and novel features disclosed herein.

Claims

1. A method for tracking hydration of a user, performed by a processor of an electronic device, comprising: receiving an indication of a type of liquid consumed by the user; determining an amount of liquid consumed by the user based on a predetermined baseline consumption rate of the user and a number of at least one of sips or swallows of the user detected by a sensor coupled to the processor; determining a hydration level of the user based on the determined amount of fluid consumed, wherein the hydration level is adjusted to take into account the indication of the type of fluid consumed by the user; and An indication of the user's determined hydration level is reported.

2. The method according to claim 1, further comprising: The predetermined baseline consumption rate of the user is determined based on a previously counted number of at least one of sips or swallows detected by the sensor when the user consumed a known amount of liquid.

3. The method according to claim 1, further comprising: The predetermined baseline consumption rate of the user is determined based on manual user input indicating at least one of a known amount of liquid or a number of sips or swallows required to consume the known amount of liquid.

4. The method according to claim 1, further comprising: The predetermined baseline consumption rate of the user is determined based on the context in which fluid is consumed.

5. The method according to claim 1, further comprising: The predetermined baseline consumption rate of the user is selected based on the type of liquid being consumed.

6. The method according to claim 1, further comprising: determining an update to a previously determined baseline consumption rate for the user based on liquid consumption information from at least one of the sensor, user input, or the context in which the liquid was consumed, Wherein the predetermined baseline consumption rate is based on a determined update to the previously determined baseline consumption rate of the user.

7. The method according to claim 1, further comprising: receiving contextual information indicating a context in which the user took at least one of the number of sips or swallows; as well as A hydration level of the user is further determined based in part on the context in which the user takes at least one of the number of sips or swallows.

8. The method according to claim 1, further comprising: A determination is made as to whether the user consumed solids along with the consumed amount of liquid, wherein in response to determining that the user consumed solids along with the liquid, the amount of liquid consumed by the user is determined based on a number of sips taken by the user.

9. The method of claim 1 , wherein the received indication of a type of fluid consumed by the user indicates that the fluid consumed by the user includes at least one of a diuretic or a dehydrating substance, wherein determining the user's hydration level based on the determined amount of fluid consumed comprises: The hydration level determined based on the determined amount of fluid consumed is adjusted downward due to the diuretic or dehydrating substance indicated in the received indication.

10. The method of claim 1 , wherein the received indication of a type of fluid consumed by the user indicates that the fluid consumed by the user includes an antidiuretic, wherein determining the user's hydration level based on the determined amount of fluid consumed comprises: Hydration levels based on the determined amount of fluid consumed were adjusted upward in the absence of an indication for antidiuretics.

11. The method according to claim 1 , further comprising: receiving food consumption information associated with food consumed by the user; as well as A hydration level of the user is further determined based in part on the received food consumption information.

12. An electronic device comprising: at least one memory comprising instructions; and at least one processor configured to execute instructions so that the electronic device: receiving an indication of a type of liquid consumed by a user; determining an amount of liquid consumed by the user based on a predetermined baseline consumption rate of the user and a number of at least one of sips or swallows of the user detected by a sensor coupled to the processor; determining a hydration level of the user based on the determined amount of fluid consumed, wherein the hydration level is adjusted to take into account the indication of the type of fluid consumed by the user; and An indication of the user's determined hydration level is reported.

13. The electronic device of claim 12, wherein the at least one processor is further configured to cause the electronic device to: The predetermined baseline consumption rate of the user is determined based on a previously counted number of at least one of sips or swallows detected by the sensor when the user consumed a known amount of liquid.

14. The electronic device of claim 12, wherein the at least one processor is further configured to cause the electronic device to: The predetermined baseline consumption rate of the user is determined based on manual user input indicating at least one of a known amount of liquid or a number of sips or swallows required to consume the known amount of liquid.

15. The electronic device of claim 12, wherein the at least one processor is further configured to cause the electronic device to: The predetermined baseline consumption rate of the user is determined based on the context in which fluid is consumed.

16. The electronic device of claim 12, wherein the at least one processor is further configured to cause the electronic device to: The predetermined baseline consumption rate of the user is selected based on the type of liquid being consumed.

17. The electronic device of claim 12, wherein the at least one processor is further configured to cause the electronic device to: determining an update to a previously determined baseline consumption rate for the user based on liquid consumption information from at least one of the sensor, user input, or the context in which the liquid was consumed, Wherein the predetermined baseline consumption rate is based on a determined update to the previously determined baseline consumption rate of the user.

18. The electronic device of claim 12, wherein the at least one processor is further configured to cause the electronic device to: receiving contextual information indicating a context in which the user took at least one of the number of sips or swallows; and A hydration level of the user is further determined based in part on the context in which the user takes at least one of the number of sips or swallows.

19. The electronic device of claim 12, wherein the at least one processor is further configured to cause the electronic device to: determining whether the user consumed a solid along with the consumed amount of liquid; and In response to determining that the user consumed a solid with a liquid, an amount of liquid consumed by the user is determined based on a number of sips taken by the user.

20. The electronic device according to claim 12, wherein: The received indication of the type of fluid consumed by the user is used to indicate that the fluid consumed by the user includes at least one of a diuretic or a dehydrating substance; and The at least one processor is further configured to cause the electronic device to determine the hydration level of the user based on the determined amount of fluid consumed by adjusting the hydration level determined based on the determined amount of fluid consumed downward due to the diuretic or dehydrating substance indicated in the received indication.

21. The electronic device according to claim 12, wherein: the received indication of a type of fluid consumed by the user is used to indicate that the fluid consumed by the user includes an antidiuretic; and The at least one processor is further configured to cause the electronic device to determine a hydration level of the user based on the determined amount of fluid consumed by adjusting upward a hydration level determined based on the determined amount of fluid consumed if no antidiuretic is indicated.

22. The electronic device of claim 12, wherein the at least one processor is further configured to cause the electronic device to: receiving food consumption information associated with food consumed by the user; and A hydration level of the user is further determined based in part on the received food consumption information.

23. A non-transitory processor-readable medium having stored thereon processor-executable instructions, the processor-executable instructions being configured to cause a processor of an electronic device to perform operations comprising: receiving an indication of a type of liquid consumed by a user; determining an amount of liquid consumed by the user based on a predetermined baseline consumption rate of the user and a number of at least one of sips or swallows of the user detected by a sensor coupled to the processor; determining a hydration level of the user based on the determined amount of fluid consumed, wherein adjusting the hydration level taking into account an indication of the type of fluid consumed by the user; and An indication of the user's determined hydration level is reported.

24. The non-transitory processor-readable medium of claim 23, wherein the stored processor-executable instructions are configured to cause a processor of an electronic device to perform operations further comprising: The predetermined baseline consumption rate of the user is determined based on a previously counted number of at least one of sips or swallows detected by the sensor or input by the user when the user consumed a known amount of liquid.

25. The non-transitory processor-readable medium of claim 23, wherein the stored processor-executable instructions are configured to cause a processor of an electronic device to perform operations further comprising: The predetermined baseline consumption rate of the user is selected based on the type of liquid being consumed.

26. The non-transitory processor-readable medium of claim 23, wherein the stored processor-executable instructions are configured to cause a processor of an electronic device to perform operations further comprising: receiving contextual information indicating a context in which the user took at least one of the number of sips or swallows; and A hydration level of the user is further determined based in part on the context in which the user takes at least one of the number of sips or swallows.

27. An electronic device comprising: means for receiving an indication from a user of the type of liquid consumed; means for determining an amount of liquid consumed by the user based on a predetermined baseline consumption rate of the user and a number of at least one of sips or swallows by the user; means for determining a hydration level of the user based on the determined amount of fluid consumed, wherein the hydration level is adjusted to take into account an indication of a type of fluid consumed by the user; as well as Means for reporting an indication of the determined hydration level of the user.

28. A computer program product comprising computer-readable instructions executable by a processor to cause the processor to perform the method according to any one of claims 1 to 11.

Images