MOBILE COMPUTING WEIGHT, DIET, NUTRITION, AND EXERCISE MANAGEMENT SYSTEM WITH ENHANCED FEEDBACK AND GOAL ACHIEVING FUNCTIONALITY
An illustrative mobile computing device executing weight, nutrition, health, behavior and exercise application software serves as a simulated combination personal trainer and dietician/nutritionist for the user using comprehensive databases storing personalized health, nutrition and exercise information. A mobile computing device, such as a smartphone, executing such software monitors, tracks and/or adjusts caloric intake, energy expenditure taking into account nutritional information and behavioral factors. The mobile computing device receives food consumption, exercise-related, behavior and other input using speech input and the device's GPS subsystem to ease data entry burden on users and to promote continued long-term usage. The system rewards user goal achievement in an automatic, seamless manner, through, for example, downloading music, books, or other media. In illustrative implementations, the system assists users to make healthy food and exercise choices by using a comprehensive color code system to identify good choices, bad choices and those in between.
This application is a continuation of allowed U.S. patent application Ser. No. 14/242,106, which is a continuation of U.S. patent application Ser. No. 13/733,588, filed on Jan. 3, 2013, now U.S. Pat. No. 8,690,578, which are hereby incorporated by reference in their entirety.
FIELD OF THE INVENTIONThe invention generally relates to a computing diet, nutrition and exercise tracking system and methodology. More particularly, the illustrative implementations relate to a mobile computing weight, diet, nutrition, behavioral, and exercise tracking system with enhanced data acquisition functionality to ease tracking calories consumed and calories burned through exercise while providing enhanced user feedback features to improve the probability of goal achievement.
BACKGROUND AND SUMMARYObesity has been a well-recognized serious health problem in the United States for decades, significantly contributing to shortening lives and increasing medical expenses for millions of Americans. Many diseases, such as type II diabetes, hypertension, hyperlipidemia, heart disease, and others have been directly linked to obesity. Unfortunately, the threat of a reduced lifespan, reduced quality of life and an enhanced probability of suffering from comorbid diseases in the future is not sufficient for those who are significantly overweight to be successful in reducing their weight and in maintaining such a reduced weight, and a healthy lifestyle incorporating a consistent exercise program.
The causes of obesity are multiple and can be complex. Genetic predisposition impacting metabolism and environmental factors such as diminished physical activity often play a key role. For some individuals additional psychological factors such as stress and depression and medical conditions such as hypothyroidism, chronic pain and other conditions that restrict physical activity or affect metabolism all can contribute in varying degrees in causing obesity.
Given the complexity of obesity, there are many approaches to its treatment. At the most basic level, treatment involves the manipulation of energy intake and energy expenditure. To lose weight one has to take in fewer calories than one expends. To attain this objective, diets limiting the intake of calories are typically coupled with exercise to increase energy expenditure and thus create negative energy balance. Along with this, however, when restricting calories one must be aware of the nutritional needs of the body. Healthy weight loss is best achieved when nutritional requirements of the body are fulfilled during the process of limiting caloric intake.
Since many individuals suffering from obesity also are afflicted with comorbid medical conditions, the determination of appropriate nutritional intake, caloric restriction and exercise regimens should take into account these conditions and, often, the medications associated with them. Safety is of utmost concern when establishing an exercise regimen and in determining nutritional requirements making up a dietary protocol. For example, an appropriate dietary protocol and exercise regimen for weight loss for a 60 year old morbidly obese male individual with hypertension, coronary artery disease and history of heart attack would be very different than the appropriate protocol for a 38 year old moderately obese female having type II diabetes treated with oral medications. Given these factors, it is recommended that protocols for weight loss including nutritional guidelines and exercise be constructed by healthcare professionals including physicians, nutritionists and others.
In this country, there is significant variation in the approaches available to address obesity. Many commercial programs exist, such as Weight Watchers, that provide nutritional and exercise direction along with help to keep on track. There are many individual health care professionals that provide specific weight management services such as nutritionists, trainers, exercise physiologists, counselors, psychologists, nurses and physicians. In some areas, there are more comprehensive programs available at multidisciplinary medical weight management centers where medical management, nutrition, exercise and psychological intervention are provided in a global, coordinated approach. Also, there are surgical approaches available offering a number of procedures aimed at altering caloric intake and absorption.
In addition to services and programs, there are a myriad of weight loss products available. FDA approved prescription medications, herbal products and over the counter products to stimulate metabolism and to increase satiety, prepackaged, low and zero calorie foods and beverages and many other products are available to alter caloric intake. Exercise machines, devices and videos are also available to encourage increased energy expenditure.
In the end, the success of individuals, whether it be in losing weight and maintaining the weight loss or any health enhancement endeavor is most affected by their ability to make positive behavior changes and to maintain those positive behaviors indefinitely.
Well known programs, such as Weight Watchers, have employed weight-loss monitoring data processing systems that have been helpful to participants in this program. In recent years, weight-loss applications have become available for use with iPhones and iPads to assist dieters in successfully meeting their weight loss goals.
While existing weight-loss computing systems have a variety of useful features, such systems are typically cumbersome to use due in part to the complexities of adequate data entry. The difficulties in various data entry steps in such systems are likely to discourage consistent use over a long period of time for many users.
Moreover, there is a need for a diet, exercise and behavioral monitoring system that provides the user with a structured system for addressing the old adage “you are what you eat” in part by providing feedback in real time to the user as to food consumed, exercise performed and/or progress towards goal achievement. In illustrative implementations, such feedback includes nutritional and/or health information about food items to be consumed of which the user may be unaware. Armed with such information, the user is then equipped to make an informed decision whether to eat a selected food item. With such a system, even those who are not overweight (or suffering from any known illness) but who wish to structure a diet that minimizes their odds of in the future suffering from a variety of diseases linked to poor diet, have an opportunity to do so. Still others, who are not overweight but who suffer from high blood pressure, diabetes, lipid disorders, renal disease and perhaps various cancers, have an opportunity to meet their food consumption and exercise goals to take advantage of a diet and exercise protocol that has been linked to helping control such medical conditions. Also individuals in good health who may have very specific health and fitness goals such as bodybuilders, runners, martial arts enthusiasts and others may utilize such a system to help attain their fitness and health goals by monitoring and tracking exercise, behavioral and nutrition parameters.
There is a need for an easy to use weight, nutrition, exercise and behavior monitoring data processing system that, for example, simplifies data entry for food consumed and/or exercise modes of operation and/or behavior parameters, while providing valuable health beneficial feedback and rewards for behavior change and goal achievement. Former smokers and those who are attempting to quit smoking have a dire need to eat in a nutritionally sound manner, exercise as much as they are able, and be rewarded for their efforts to stop smoking. Moreover, it is desirable for such a system to, for example, dynamically adjust to changing user food intake, exercise regimens and behaviors, to change user profiles and associated goals, and to appropriately generate medical warnings as needed.
In practical effect, in illustrative implementations, the mobile computing device executing the weight, nutrition, health, behavior and exercise application software as described herein serves as a simulated personal trainer, dietician/nutritionist, and physician's assistant for the user while having access to massive amounts of personalized health, nutrition and exercise information. In non-limiting, illustrative implementations, a mobile computing device, such as an Iphone, is augmented with a unique weight, nutrition, health, behavior and exercise tracking application and databases that provide enhanced user feedback features and automated data entry.
The illustrative implementations advantageously contribute to the ability of users to maintain positive diet, nutrition and exercise lifestyle changes by monitoring, tracking and adjusting caloric intake, energy expenditure, nutritional information and environmental and behavioral factors. Identifying behavioral issues and working to improve them through prompts and recommendations are used to enhance and maintain positive behavior change. In maintaining the positive behaviors, weight loss and health improvement can be achieved and maintained long term, resulting in significant improvement in quality of life, self esteem, medical conditions and overall health.
In an illustrative implementation (or set of illustrative implementations), the mobile computing device receives food consumption, exercise-related, behavior and other input from various input devices/mechanisms using speech input and digital imaging technology to ease the data entry burden on users and to promote continued long-term usage. In certain illustrative implementations, the system is designed to reward user goal achievement in an automatic, seamless manner, through for example downloading music, books, or other media to the user's mobile computing device via the Internet.
As used herein, it should be understood that any feature identified as being used in one illustrative implementation, is contemplated as being usable in any other illustrative implementation identified herein. Thus, merely because a feature is not expressly identified as being used in a particular illustrative implementation should not be interpreted as an indication that it is not contemplated for use in that implementation. Similarly, any reference herein to “in an implementation/embodiment” or the like should be interpreted as indicating a contemplation of use in any desired implementation. Further, reference to a feature or a set of features being used in “illustrative implementations” should not be construed as an indication that some or all of such features must be used in “all” implementations.
In an illustrative implementation, food consumption and exercise and other goals are set using input from a physician, and/or a nutritionist, and/or healthcare provider, and/or personal trainer, and/or the user, and/or another source. For example, a physician may provide input to set appropriate thresholds for the user including average calorie intake per day, grams of sugar intake per day, amount of exercise per day, etc.
In an illustrative implementation, a “select mode” display is generated. In such an illustrative implementation a wide array of mode select icons are displayed to indicate, for example, a user profile mode for creating a user profile that is modifiable and displayable, a diet selection mode, a food data entry mode, an exercise data entry mode including those using the computing device's GPS functionality, a food purchase mode, a diet and exercise issue mode for addressing a range of issues including user “behavioral” issues in comporting with a diet and exercise program, and various other modes.
One of various mechanisms used by the illustrative implementations to assist, motivate and encourage users to make good, healthy food and exercise choices is a color code system to identify good choices, bad choices and those in between. For example, in an illustrative implementation, the colors GREEN, LIME, YELLOW, ORANGE, and RED, respectively indicate relative values such as Best, Good, Okay, Bad, and Worst with respect to food and exercise choices.
In an illustrative implementation, for each food and exercise activity supported by the system described herein, the system advantageously provides color code feedback to the user with respect to (WRT) any and all of the many nutritional parameters monitored by the system while taking into consideration related health information from a user's profile.
In an illustrative implementation, for each food and each exercise identified by the user, a color code is displayed to the user and dynamically adjusted taking into account, for example, user weight, height, sex, age, health, goals, progress, etc. Such a color code system aids in motivating the user to abide by color codes that are internationally-recognized signals (e.g., “Go” on Green, “Stop” on Red) to select the foods or exercises that provide the greatest benefit (as indicated by the color Green in this example), to avoid the poor choices that provide the least benefit or may even be harmful (as indicated by the color Red in this example), and to advance the color up from Red to Green as soon as possible.
The color coding system used in illustrative implementations is dynamically tailored to individual users in real time. In an illustrative implementation, in generating color code feedback to the user for use in the user's profile generation, the system adjusts the color coding taking into consideration the specific health characteristic to which the user (or the user's physician, nutritionist, or personal trainer) is seeking to improve. For example, in an overweight male user trying to lose weight, fruit is color coded Green but in the overweight female diabetic user who is trying to lose weight and improve her diabetes control, fruit is color coded Orange. Under a variety of circumstances, the same food may undergo a color change for the same user. For example, with the diabetic user, after surpassing a certain amount of fruit in a day, fruit becomes Red due to the sugars in fruit making them not as good for diabetics.
In illustrative implementations with respect to exercise, for a user with significant arthritis in the knees and hips who is trying to lose weight, treadmill walking is coded Red while elliptical machine exercise is coded Orange. However, for such a user, walking or swimming in a pool is coded Green.
In an illustrative implementation, exercise duration times are also factored in by color coding the activity based on the activity itself and the time participating in the activity. In such implementations, too little or too much exercise time generate a less desirable color code, taking into consideration the user's health parameters (heart disease, arthritis, asthma, etc) and the user's goal (to lose/gain weight, improve strength, increase endurance, quit smoking, etc).
In practical effect, the system guides the user to make healthy choices based upon nutrition and health factors tailored to the user, which the user may be unaware of or otherwise avoiding.
In an illustrative implementation, a wide variety of modes may be entered from a “Select Mode” display screen. Initially, a user profile-related mode is entered to permit a user to create, modify, or display his or her user's profile. Entry into such a mode may, for example, enable the user to immediately access his/her current weight loss, calories consumed, calories burned, and other exercise or health-related data to get real-time feedback on his/her progress to date.
In an illustrative implementation, a diet selection mode permits a user to select a diet to be associated with the user's profile that may be used to target one or more medical conditions of the user. In an exemplary implementation, upon the selection of the “diet selection” mode, an array of icons are displayed identifying various diet regimens, at least some of which are targeted to address weight loss, one or more serious medical concerns, and/or other specialized dietary needs such as those of athletes. For example, one or more icons zone in on a diet tailored to addressing the needs of diabetics, cancer patients, gluten-intolerant individuals, individuals with high blood pressure, or individuals with other major medical conditions, who are attempting to stop smoking or drinking, etc. In an illustrative implementation, the application generates selection of a diet by accessing an associated database that contains pre-formulated breakfasts, lunches and dinners targeted to comport with the selected diet and associates such meals with the user's profile.
In an illustrative implementation, one of such icons available in the diet selection mode would, for example, enable selection of the “GOMBS” diet (or a variation thereof) promoted in the mass media by Dr. Joel Fuhrman. In such an implementation, variations of meals following the spirit of the GOMBS diet as identified in Dr. Fuhrman's book “Secrets to Healthy Cooking” are stored in one of the databases used in the illustrative implementation. GOMBS is an acronym for Greens, Onions, Mushrooms, Beans & berries, and Seeds & nuts. Such foods have reportedly been associated with healthier blood vessels/blood flow, enhanced weight loss, reduced suffering from certain cancers, anti-diabetic and other beneficial properties.
In an illustrative implementation, entry into a food consumption data entry mode (Food mode) permits the user to enter into the system, food that is consumed either in or outside a user's home in a manner that is as user-friendly as possible. Over a period of time, users tend to eat one or more of the same favorite meals for breakfast, lunch, or dinner on a consistent basis. Taking advantage of this habituated tendency, the system can learn a great deal about the user's present nutrition profile by initially asking him/her to declare his/her Top 5 favorite meals. In an illustrative implementation where the food is nutritional and low in calories, a user works with, for example, a physician/nutritionist/other consultant to select various breakfast, lunch, and dinner combinations that have beneficial amounts of nutrition (e.g., low in calories, sugars, saturated fats, sodium, etc.) that are then stored in the user's profile (or a database associated therewith). For example, a user who has chosen to eat a breakfast of Cheerios, with raspberries, blueberries, and skim milk may have an associated user profile having such a breakfast identified as “breakfast number 1” and storing (or otherwise identifying by pointing to a database storage location) a wide array of nutritional information for such a breakfast including, for example, calories and sugar content. In such an implementation, using speech recognition software, the system recognizes, for example, the user stating “breakfast number 1” in response to a verbal or displayed prompt to describe the breakfast to be consumed. In certain other illustrative implementations, a touch screen display (or other identification) of a particular food may be used to obtain user confirmation that the speech recognition software accurately decoded the food he/she identified.
After speech recognition software determines, for example, that the user has stated the particular food consumed and the food amount, the system then determines the caloric, nutritional, and other health-related characteristics of the food consumed which is stored and analyzed as described herein. In the above example, a Green color code is displayed to the user consuming such a breakfast number 1. Additionally, in certain illustrative implementations, image processing technology may be utilized to identify the food and the caloric and other nutritional/health-related characteristics of the food consumed. This same user/system interactive process is likewise used for the user to store and later specify other favorite meals such as “Lunch number 3”, “Dinner number 5”, etc.
In an illustrative implementation, a user's exercise activities are tracked and analyzed. In one of various exercise modes, GPS technology embodied in the user's computing device is used to automatically acquire user coordinate position data using the GPS receiver associated with the mobile computing device, and the system monitors the time over which running, walking, or bicycling exercise activities have occurred. After user entry of the type of exercise being undertaken and after determining the distance traveled during the monitored time, the system generates an estimate of the number of calories burned by the user during such GPS-tracked activity.
In an illustrative embodiment, other exercise modes may be entered in which, for example, speech analysis software is utilized to enable the user to input a specific type of exercise: for example, various exercise-related “tags” are stored in a newly-created exercise record identifying the duration, resistance, rest interval, and other characteristics of the exercise. Under circumstances where various conventional health club exercise machines are used, the system stores the generated output of such exercise machines, such as elliptical machines, stationary bicycle machines, stepper machines, etc., that generate, for example, the number of calories burned during an exercise session.
Further, in other illustrative implementations, a food purchasing mode may be entered to guide the user during food shopping or at a restaurant to determine whether a food product being purchased is consonant with the user's profile and associated goals and health issues. In an illustrative implementation, a database is accessed to identify, where possible, alternative foods of the same food type to enable a user, for example, to select a desired food and yet cut down on, for example, the amount of sugars, fats, sodium, or calories consumed.
Further, in another illustrative example, a diet/exercise issue mode may be entered where the user selects a category corresponding with a behavioral issue that may be impacting diet or exercise success. The user is then prompted to answer questions regarding the behavioral issue raised by the user's problem. The responses are analyzed by the system and the system provides the user with recommendations to improve the behavior: e.g., to eat an apple at 3 PM in response to a user query regarding hunger issues in the middle of the afternoon.
Additionally, in illustrative implementations access to external servers and databases is advantageously utilized to provide a behavior enhancing reward system designed to motivate users to achieve their goals through rewards based on goal achievement and/or progress towards goal achievement. In an illustrative implementation, any diet, exercise, health or nutritional goal being met may trigger an award generation, including weight-related goals, exercise-related goals and smoking cessation-related goals. A reward may be embodied in a wide variety of forms including, without limitation, automatically downloaded music, movies, digital versions of TV shows, music videos, cash, discounts at movies, restaurants (particularly those that include a wide range of healthy alternatives), discounts at sporting events, mobile games, mobile gaming currency, other mobile applications, etc. In an illustrative implementation, a user's types of reward preferences, e.g., music, electronic book, etc., are stored in the user's profile to guide the system in generating and downloading an appropriate reward.
These and other features of the illustrative implementations will become apparent from a review of the drawings of which:
FIG. 2B1 illustrates various nutrition and exercise-related modes of operation of the mobile computing device when performing the weight, exercise and nutrition tracking methodology described herein;
FIG. 2B2 is an illustrative diet selection screen that is generated when a diet selection mode icon 52 is selected by a user;
FIG. 2D1 illustrates macronutrients considered essential to the human body, plus an identifying color code level for each macronutrient;
FIG. 2D2 illustrates micronutrients considered essential to the human body, plus an identifying color code level for each micronutrient;
FIGS. 2G1 and 2G2 are an illustration of a recommended daily intake (RDI) database that discriminates the calorie needs of various users based on, e.g., their body weight, gender, age, and level of physical activity;
FIGS. 4B1 and 4B2 illustrate macro- and micro-nutrients in the USDA Nutrient Database;
FIGS. 5B1 and 5B2 show numerous examples of calories burned via activities/exercises, excerpted from the Compendium of Physical Activities (researched/updated for NIH by Arizona State Univ 2012) which, taken together with an illustrative calorie coefficient, form an illustrative system Activity Database;
FIG. 7A1 illustrates a database format specifying a record format to track user weight loss (gain) across time toward multiple delta subgoals, leading to an overall final goal;
FIGS. 7A2-7A4 provide 3 illustrative examples that use FIG. 7A1 delta subgoals to track weight loss from obese to overweight, from overweight to healthy weight, and from healthy to ideal weight;
FIGS. 7B1 and 7B2 show illustrative DB register formats for each user food eaten and exercise done (for the Food DB in
FIGS. 7B3 and 7B4 show companion DB register formats for user Daily and Delta Records, which accumulate Cals In/Cals Out to calculate weight loss (gain) on a daily and cumulative basis, respectively, to show user food, exercise, and weight loss (gain) history from start to current date;
FIG. 13C1 illustrates an ideal weight database that allows the system to provide an ideal weight matched to a user's height for both men (left side) and women (right side);
FIG. 13C2 is a chart showing the step-wise linear MIN/MAX boundary equations used to define the limits of ideal weight for men and women, as tabulated in FIG. 13C1 and charted in
As will be explained further below, mobile computing device 1 communicates via the Internet with a server 14 that includes associated user profile, weight tracking, exercise/activity databases, and food/nutrition databases as described in more detail below.
Additionally, mobile computing device 1 also communicates via Internet 11 with a rewards server 16 that includes an associated rewards database that in turn communicates with a music, video and entertainment server 17 that is utilized during reward processing to provide additional motivation to users for enhancing the likelihood of goal achievement. It should be understood that, while servers 14 and 16 and physician/nutritionist/personal trainer/data processing system/server 20 are represented by multiple computers having multiple associated databases, such systems may be implemented, if desired, at one data processing system location using one data processing system having one database.
Mobile computing device 1, in an illustrative implementation, may be implemented by any of a wide array of commercially available, conventional mobile computing devices, including, for example, conventional smart phones, such as Apple's iPhone 4s or 5, or Samsung's quad-core processor-based Galaxy S3, a tablet computing device such as Apple's iPad, or any of a number of laptop computers. In certain illustrative implementations, such mobile computing devices may be modified to include a pedometer 13 that provides user step-related data to the mobile computing device's processing system 2. See, for example, the commercially available Ipod Nano with a built in pedometer. In other implementations, a pedometer 13A wirelessly transmits pedometer data to mobile computing device 1 that is received by a receiver in mobile computing device 1 in a manner understood by those skilled in the art. See, for example, the commercially available pedometer used with an Ipod or Iphone that receives pedometer transmissions from a shoe. Although in illustrative implementations, step-related data may be transmitted wirelessly to mobile computing device 1 for use in exercise tracking in walking or running activities, exercise-tracking during such activities may be made based on GPS data analysis alone, as will be explained further below.
Mobile computing device 1, as will be appreciated by those skilled in the art, includes a processing system 2 that is operatively coupled to receive speech input from microphone 9, GPS data from GPS receiver 5, and image data from camera 10. Processing system 2, inter alia, executes the unique weight, diet, food/nutrition, exercise/activity, behavior, health-related tracking, analysis, and user feedback application software 6 stored in the mobile computing device's memory subsystem 15. Memory 15 may, for example, be implemented by a 64 GB memory, such as that associated with the iPhone 4S or iPhone 5. Although not shown in
The computing device 1 also includes one or more cameras 10 that, as will be explained further below, may be advantageously utilized as a food consumption and, if desired in certain instances, an exercise-related input device. The illustrative digital camera 10 that may, for example, be the digital camera in a conventional iPhone 4S or iPhone 5, incorporates a conventional optical system including an imaging device having a CCD/CMOS image sensor. For example, the CCD image sensor captures an optical image of a target and the imaging device outputs a converted image signal. As will be understood by those skilled in the art, image processing circuitry including an analog to digital converting circuit converts processed image data into a digital image signal. Such a digital image signal is transferred to processing system 2.
Memory 15, in an illustrative implementation, stores a wide range of user-related data 21 including a User Profile, and various user databases including for example, a food database, a nutrient database, an exercise database, and an activity database, each of which is described in detail herein. As described below, an illustrative user profile record format is shown in
The mobile computing device 1, in an illustrative implementation, also includes associated speech recognition, analysis, and synthesis software 8 stored in memory 15 that is utilized as is described below to provide data entry for food consumption, and certain exercise and behavior. A person skilled in the art will recognize that commercial speech recognition, analysis and synthesis software systems are well known and are commercially available, such as Dragon Naturally Speaking offered by ScanSoft and Via Voice marketed by IBM. Further, the speech recognition, analysis and synthesis software (hereinafter referred to as speech recognition) 8 may be implemented by a system corresponding to Apple's Siri intelligent personal assistant and navigator system utilized in the iPhone 4S or iPhone 5 augmented to incorporate the speech recognition, voice synthesis/communication and control features described herein. The speech recognition software 8 is executed by processing system 2. The speech recognition software includes a voice recognition module that is responsible for parsing input speech as digitized by an audio codec and analog to digital converter operatively coupled to processing system 2. Well known speech recognition algorithms are well understood to those skilled in the art and are available for inclusion included in such speech recognition software 8, such as, for example, the voice recognition methodology described in U.S. Pat. No. 7,809,565, which is incorporated herein by reference. In an illustrative implementation, as will be explained further below, speech recognition operations are simplified due to user prompts that condition the system to expect receipt of a certain type of information from the user to trigger the storage of, for example, food consumption-related data.
Mobile computing device 1 includes a GPS receiver 5 that is capable of determining the geographic location of computing device 1 via received satellite signals from antenna 7 in a manner well understood by those skilled in the art. The GPS receiver 5 in an illustrative implementation is operable to output to processing system 2 the geographical coordinates of mobile computing device 1 to define its current location in real time. The geographical coordinate location data may be stored in conjunction with time-related data under the control of processing system 2 for use in calories burned-related calculations. As noted above, in illustrative implementations, in addition to wirelessly receiving GPS data, mobile computing device 1 may wirelessly receive step-related data from a pedometer-based device 13A including a transmitter that transmits step-related data that is received via, for example, the mobile computing devices' antenna 7 and processed as described herein in a manner appreciated by those skilled in the art.
It should be recognized that in yet other illustrative implementations, a vast number of additional mobile computing devices 1A-N (where A to N—used herein as any desired integer—may range from 1 to any desired number of devices N) may also be utilizing servers 14, 16, 17 and 20 for the same weight, diet, and nutrition tracking and analysis as described in detail herein. In illustrative implementations, weight loss competition between users may occur. Moreover, teams of users may be formed to compete against each other based on a variety of criteria such as total weight loss by team members, successful weight loss by highest percentage of team members, total calories burned during exercise by team members, etc. In such an implementation, server 14 is programmed to compile the results for each team, assess such results, and declare a victor in the competition. Team members are rewarded in a manner corresponding to the description below of the reward generation process when an individual user meets individual goals.
In an illustrative embodiment, the mobile computing device 1 communicates via the Internet 11 with one or more physicians and/or nutritionists and/or personal trainers located at one or more remotely located data processing stations 20 exemplified in
In certain illustrative embodiments, server 20 may be distributed and implemented by, for example, individual physicians who already have a doctor-patient relationship with the user of mobile device 1. Such physicians commonly have an extensive medical history stored for patients. Various implementations, particularly those that involve large numbers of users may employ artificial intelligence-based software that automatically responds to medical queries and sends warning messages if maximum or minimum thresholds are exceeded or are not met triggered by, for example, a user consuming too much sugar, too many calories, not completing enough exercise, etc. As will be appreciated by those skilled in the art, the number of servers 20 employed will need to be tailored to the volume of inquiries. In other implementations, particularly those having a modest volume of queries, it is contemplated that a physician, nurse, physician's assistant, nutritionist, personal trainer, or other professional individually responds to queries and personally manages the user's food consumption and exercise programs.
After initialization operations, if not previously created, a user profile is generated during create user profile processing (32) as is described in detail herein in conjunction with the description of
After a user profile data entry operation has been completed (32), a check is made to determine whether the user profile is complete (33). If not, the user is prompted to “please complete profile” (23) by entering further data in the user profile as indicated at block 32. The user's continued efforts in completing the profile provide an opportunity for the user to correct any data entry errors by modifying any previously entered data. In an illustrative implementation, the user is given a limited number of attempts to complete the user profile to provide some predetermined minimum level of completion. Once this limited number of attempts has been reached, if no data is entered by the user, the weight tracking and nutrition analysis routine is exited. While it is desired to limit the number of user data entries to the bare minimum, in illustrative implementations, it is likewise desirable to require a sufficient amount of information about the user to assist the user in gaining life changing, long-term health benefits from the system described herein.
If the check at block 33 indicates that the user profile is complete, then the user profile is stored locally in the user phone DB (storage 15) and also uploaded to remote server 14 (25).
Thereafter, mobile computing device 1 generates a “select mode” display (35) as illustrated in
A check is then made to determine the mode of operation to enter based on a user's selection of the modes displayed on the display of the user's mobile computing device 1 (36), as explained in further detail in conjunction with
If the user has not selected the exit icon in
If, for example, the food mode has been selected, the system acquires the user's desired food consumption data (39), as will be explained further below. A check is then made at block 40 to determine whether data is available. If data is not available, the routine continues to check for data. Such data checking continues until a predetermined time period passes (e.g., a number of minutes of no data entry), at which point the routine branches back to display mode block 35. If data is available, the system acquires the appropriate data for the mode being processed, and the detailed processing associated with the selected mode is performed (42) as shown in the continuation of
After a mode processing operation (42) has been completed, a check is made at block 43 to determine whether the mode of operation in process has ended. If the mode being processed is not yet finished, the routine branches back to block 42 to complete mode processing. If the mode has finished, then a check is made at block 44 to determine whether the user has decided to cancel the current mode being processed or to change to a different mode (44). If the user has decided to cancel or change the mode, the routine branches back to display mode block 35.
If the user has not canceled or changed the mode as indicated by the check at block 44, the databases associated with the user are updated (46) to reflect in real time the current status of, for example, the user's food consumed or exercise performed.
A check is then made as indicated at block 47 to determine whether a reward has been earned based on, for example, the updated data generated during mode processing that was stored at block 46. If no reward has been earned, the routine branches back to display modes block 35.
If the check at block 47 indicates that a reward has been earned, the system performs reward processing operations to determine if goals have been met and, if so, provides, as desired, a reward to the user for meeting daily, weekly, or monthly goals (48). By way of example, based upon a user's indicated preference for a music-based reward, the reward processing system (44) may utilize Apple's iTunes application. The iTunes' app automatically selects music to download to the user based upon: [1] the contents of the user's iTunes' playlist; [2] the music listened to by the user during exercise; or [3] a stored playlist created by the mobile computing system 1 over time. Thereafter, the routine branches back to display modes block 35.
As shown in FIG. 2B1, in one illustrative implementation of the mobile tracking system and methodology described herein, a “Select mode” display is generated in which an array of select mode icons are displayed. The user may enter any mode he or she chooses, starting with the User Profile mode 50 where, upon system startup, the user can extensively personalize the system by declaring his/her favorite foods and exercises (explained in detail with
As also shown in FIG. 2B1, in an illustrative implementation, the icons are conveniently arranged in a layout corresponding to the user's expected most frequent accesses to the system. For example, in this illustrative implementation, the top level is reserved for the most often accessed icons: displaying/modifying the User Profile 50 (
As shown in FIG. 2B1 and as explained in detail in conjunction with
Detailed Discussion of Diet Selection Mode 52 (FIG. 2B2):
In an illustrative implementation, a Diet Selection mode 52 permits a user to select a diet to be associated with the user's profile that may, for example, be used to target one or more medical conditions of the user. As used herein, the term “diet” is used broadly to refer to an organized plan for specifying or limiting what one eats and drinks. The plan does not necessarily have to have weight loss as its goal.
In an exemplary implementation, upon the selection of the “diet selection” mode, an array of icons are displayed identifying various diet regimens, at least some of which are targeted to address one or more serious medical concerns or specialized needs. For example, one or more icons zone in on a diet tailored to addressing the needs of diabetics, cancer patients, individuals who are attempting to quit smoking, gluten intolerant individuals, and users having high blood pressure, other major medical conditions or specialized needs such as those of athletes. Upon the selection of such a diet, the application generates and/or accesses pre-formulated breakfasts, lunches and dinners that are targeted to comport, where possible, with a user's indicated favorites, and with the selected diet and associates such meals with the user's profile.
In an illustrative implementation, one of such icons available in the diet selection mode would, for example, enable selection of the “GOMBS”-related diet promoted on various mass media by Dr. Joel Fuhrman. In such an implementation, variations of meals following the spirit of the GOMBS-related diet as identified in Dr. Fuhrman's book “Secrets to Healthy Cooking” are stored in a database used in the illustrative implementation.
GOMBS is an acronym for Greens, Onions, Mushrooms, Beans and berries, and Seeds and nuts. Such foods have reportedly been associated with healthier blood vessels/blood flow, reduction in the likelihood of suffering from certain cancers, enhanced weight loss, anti-diabetic and other beneficial properties. It has been reported that green leafy vegetables have many diverse nutrients and properties that help the body to allow blood vessels to function better. Onion consumption has been associated with reduction in certain cancers in at least one European study. Mushroom consumption has been associated with a decreased likelihood to develop breast cancer in certain studies. Beans and berries have been reported to have high cancer preventive antioxidants levels while promoting healthy brain function. Beans and legumes have been reported as containing soluble fiber and as having anti-diabetic and weight-loss properties. Blueberries, strawberries and blackberries are low in sugar and very high in nutrients. The antioxidants in berries have been reported as providing both heart-protective and anti-cancer effects. Raw seeds and nuts have been reported as helping to reduce the body's inflammation and to reduce cholesterol.
In accordance with an illustrative implementation, if the user selects the GOMBS diet (on his or her own or after being prompted to consider this diet due to a user's profile indicated health condition), the application generates and/or accesses pre-formulated breakfasts, lunches and dinners that feature these health benefitting ingredients and that comport, where possible with the user's favorite foods and with the GOMBS-related diet and associates such meals with the user's profile using a variation of the format shown in
Turning to an illustrative example of the diet selection mode, the user's selection of diet selection mode icon 52 shown in FIG. 2B1 triggers the generation of a display of an array of diet-related icons, such as is shown in FIG. 2B2. In an illustrative implementation, it is contemplated that the user will have the opportunity to select a totally customized diet plan or any one of a variety of popular diet plans such as, by way of example only, the Atkins diet (100) and the South Beach diet (101). The selection of icon 100 or 101 will respectively result in the generation of a presentation of the details of the Atkins and South Beach diet plans including a list of foods that comport with each plan.
In addition, in an illustrative implementation, an array of icons are generated that have been recognized as being helpful in addressing various medical conditions including those identified by users in their user profiles. The use of specific dietary regimens to enhance the treatment and control of medical conditions is often an important component of an overall treatment plan for the specific condition. As such, specialized dietary regimens can be utilized as part of the overall treatment of that medical condition in an individual whose goal is to keep their weight stable. Additionally, these specialized dietary regimens can be used as part of a weight loss intervention for an individual suffering from certain medical conditions. In this setting, a calorically restricted regimen having specific beneficial components relative to the medical condition would be utilized.
In an individual suffering from more than one medical condition, a customized dietary regimen utilizing and incorporating specific beneficial components of a number of specialized regimens would be utilized addressing special dietary needs in a way that enhances the treatment of all of the medical conditions. An example might be use of a specialized dietary regimen having beneficial components to improve diabetes and hypertension concurrently.
Another situation to consider is the individual suffering from a medical condition such as cancer or gastrointestinal absorption problems resulting in excessive weight loss and difficulty maintaining weight. There are specialized dietary regimens that can be utilized to improve this situation. In an illustrative implementation, one or more of such regimens would be identified and highlighted to such an individual and would be included in the array of icons dedicated to therapeutic diet plans (98).
There are also other circumstances in which individuals may benefit from specific dietary regimens not related to weight loss and not related to a medical condition. Examples include athletes in a specific training regimen such as endurance running or weight training. In an illustrative implementation, one or more of such regimens would be identified and highlighted to such an individual and would be included in the array of icons shown in FIG. 2B2.
It is possible to contemplate even more permutations of special dietary needs in individuals that may have certain medical conditions, are stable and otherwise healthy and are pursuing various athletic endeavors. An example might be a young type I diabetic who is a long distance runner. This individual would benefit from some aspects of a diabetic diet but would have vastly different nutritional needs compared to a sedentary type I diabetic. In an illustrative implementation, an acceptable regimen would be identified and highlighted to such an individual and would be included in the array of icons dedicated to therapeutic diet plans (98).
In an illustrative implementation, when the diet selection mode icon 52 is selected, a display is generated identifying an array of icons each defining a diet regimen that may be selected by a user. For example, as shown in FIG. 2B2 when the diet selection mode icon 52 is selected a diet selection screen is generated. As indicated above, the diet selection screen includes an array of possible diets that may be selected by user to review foods that may be eaten in conformance with a diet.
As shown in FIG. 2B2, in this example, with respect to medical condition-related diets, a user will be enabled to select a diabetic diet 91, a hypertension diet 92, a renal diet 93, the GOMBS diet (102) described above, a cardiac diet 94, a gluten-free diet 95, a food allergy diet(s) 96, athletic/muscle building diets 97, and any of an array of other therapeutic diets 98, at any time the user may exit from the diet selection screen by touching the exit icon 99.
In illustrative implementation, when a user identifies in his or her user profile a health condition which implicates one or more of the identified diets, upon selecting the diet selection screen one or more of the diets shown in FIG. 2B2 is highlighted for the user. For example, for a user who indicates in his or her user profile, a diabetic or blood sugar-related problem, diabetic diet 91 will be highlighted for the user to peruse.
In such an implementation, each of the medical condition/health condition-related diets is indexed in the system in a memory table used to access one or more diet plans. The memory table is structured to associate a set of medical or health conditions with one or more diet plans. For example, key terms such as “diabetes,” “blood sugar,” “diabetic,” etc., are linked in the memory table used to access one or more diet plans to a diabetic diet. Similarly, key terms such as “hypertension,” “high blood pressure,” etc., are linked in such a table to a hypertension diet. Key terms such as “cardiac,” “heart,” etc. are linked in this table to a cardiac diet plan. Likewise, terms such as “gluten,” or “allergy” are respectively linked in the table to a gluten-free diet or a food allergy diet. Further, in an illustrative implementation, the user is prompted to review the diet highlighted on the diet selection screen or otherwise notified of appropriate diets, if the user has identified (e.g., during the creation of his or her user's profile) a condition suggesting the efficacy of such a diet in addressing the symptoms or causes of the user's condition.
The following are some examples of special dietary regimens including those identified above that would be beneficial in the treatment and context of certain medical conditions and certain athletic situations and that would be selected by the system for consideration by the user based upon the user's profile implicating one or more of the following diets:
-
- 1) Diabetic diet—goal is to alter diet in a manner that improves control of serum glucose. This regimen typically decreases sugary carbohydrates and saturated fats while increasing fiber and protein. Also, timing of food intake is important in a diabetic dietary regimen. A calorie restricted version of this diet would be utilized in diabetic individuals needing to lose weight.
- 2) Hypertension diet—goal is to alter diet in a manner shown to improve blood pressure control. The DASH diet (Dietary Approach to Stop Hypertension) is an accepted example of such a regimen. This regimen typically promotes use of more fruits, vegetables, low fat dairy, grains, fish and poultry and foods rich in magnesium, potassium and calcium while discouraging saturated fats, red meat, sugary carbohydrates and salt. A calorie restricted version of this diet would be utilized in hypertensive individuals needing to lose weight
- 3) Renal diet—goal is to alter diet in a manner shown to minimize complications associated with existing or developing renal dysfunction. Those individuals having compromised renal function and those to the point requiring dialysis must limit intake of sodium, potassium and phosphorous while delicately balancing fluid intake and output and maintaining appropriate levels of electrolytes while also taking in an appropriate amount of protein to maintain lean body mass but not negatively impact remaining renal function. A calorie restricted version of this diet would be utilized in individuals having renal function impairment needing to lose weight
- 4) Cardiac diet—goal is to alter diet in a manner to minimize risk of cardiac illness and promote cardiac function in the context of existing cardiac disease. This regimen discourages foods with high amounts of cholesterol and saturated fats while promoting low fat protein, vegetables, fruits and unsaturated fats. A calorie restricted version of this diet would be utilized in individuals having cardiac disease needing to lose weight
- 5) Gluten free diet—goal is to eliminate or minimize foods containing gluten. Individuals suffering from celiac disease cannot process gluten containing foods. These foods, including most cereals, breads and pastas must be eliminated and replaced with fruits, vegetables, unprocessed meats, dairy and non gluten containing grains such as rice. A calorie restricted version of this diet would be utilized in individuals with celiac disease needing to lose weight
- 6) Therapeutic diets—there are numerous additional conditions that would benefit from customized, specialty dietary regimens that would help diminish the negative affects of the condition. An example here would be food allergies. Some individuals suffer from allergies to certain foods which can vary in number from few to many. Specialized dietary regimens are often required to help minimize the food allergy symptoms. A calorie restricted version of this diet would be utilized in individuals requiring the use of therapeutic diets needing to lose weight
- 7) Athletic diets—nutritional requirements of athletic vary significantly based on the type, duration and goal of the athletic activity. For example, individuals in weight training building large amounts of muscle need greatly increased amounts of protein daily while the dietary regimen of endurance runners would need to include more carbohydrates and some fats.
Detailed Discussion of remaining Select Modes in FIG. 2B1
Entry into the Food mode 56 permits the user to enter into the system food that is consumed in a manner that is as user-friendly as possible. Over a period of time, users tend to eat one or more of the same favorite meals for breakfast, lunch, or dinner on a consistent basis. Taking advantage of this habituated tendency, the system can learn a great deal about the user's present nutrition profile by initially asking him/her to declare his/her Top 5 favorite meals. In an illustrative implementation, a user working, for example, with a physician, nutritionist, or other consultant selects various breakfast, lunch, and dinner combinations where the food is nutritional (e.g., low in calories, sugars, saturated fats, sodium, etc.) that will be stored either directly in or linked to the User Profile. Such preselected meals may be stored in the User Profile as schematically represented in
Using speech recognition software 8 shown in
In an illustrative implementation, in conjunction with creating a user profile, if a user indicates a particular favorite food such as a snack, e.g., chocolate ice cream, the system will display its associated color code, e.g., Orange or Red, indicating a poor choice by the user. The system will thereafter display alternative snack choices have better color code ratings—e.g., yogurt (color Green), an apple (color Lime) or almonds, walnuts and flax seeds (color Green)—all in an attempt to prompt the user to select a healthier favorite.
In an illustrative implementation, the system accesses a wide range of accessible nutritional information from existing sources through Internet resources. For example, food/nutrition lists having information regarding calories, fats, carbs, etc. are available though such sources as CDC or NIH (e.g., see FIGS. 4B1-4B2) or weight watchers or similar organizations (with permission to obtain such lists). With such available nutritional information accessed through its databases, the system can calculate the wide range of calorie and nutrition values referenced herein. Similarly, various exercise lists with associated calories burned information have also been developed/refined across many years of research, and are readily accessible (see FIGS. 5B1, 5B2). There are also preexisting classifications of food and drinks that assign a value as to how satisfying a particular food might be (e.g., a satiety index) that may be used in the illustrative implementations.
Additionally, as explained further below, in illustrative implementations image processing technology may be utilized to identify the food consumed to aid in the identification of caloric and other nutritional/health-related characteristics of the food.
In an illustrative embodiment, an Exercise mode 62 may be entered in which, for example, speech analysis software 8 is utilized to enable the user to input a wide variety of exercise data, as is explained in detail below in conjunction with
Upon detection of the user entering a GPS-based exercise mode via the GPS exercise icon 64, the system automatically acquires user coordinate position data and monitors the time over which running, walking, or bicycling activities have occurred (e.g., via “Start” and “Stop” screen icons). After user entry of the type of exercise undertaken, the system generates the number of calories burned based on the distance traveled within the time monitored.
Further, in an illustrative implementation, a Food Purchase mode may be entered via the Food Purchase icon 58 to guide the user during food purchasing (at a grocery store or at a restaurant) to determine whether a food product being purchased is consonant with the user's profile, selected diet, and associated goals and health issues. This mode allows a user (in a grocery store shopping or in a restaurant dining) to access a database that identifies alternative products of the same product type. This enables a user, e.g., to select a similar alternative that cuts down on the amount of sugar or calories consumed.
Various other modes (not shown) may be incorporated in the “Select Mode” display shown in FIG. 2B1.
In an illustrative implementation, for each food and exercise activity supported by the system described herein, the system advantageously provides color code feedback to the user with respect to any and all of the many nutritional parameters monitored by the system while taking into consideration the specific health improvement the user is seeking. For example, in an overweight male user trying to lose weight, fruit is color coded “Green” to indicate a very positive choice by the user. However, when providing feedback to an overweight female diabetic user who is trying to lose weight and improve her diabetes control, fruit is color coded either “Orange” or, after surpassing a certain amount of fruit in one day, it turns “Red” due to the sugars in fruit that make it a liability for diabetics.
Similarly, with respect to exercise, for a user with significant arthritis in the knees and hips who is trying to lose weight, treadmill walking is coded red but elliptical machine is coded orange and walking or swimming in a pool is coded green. In an illustrative implementation, exercise duration times are also taken into account by color coding the activity based on the activity itself and the time performing the activity—with too little (or too much) exercise time generating the less desirable color code, all taking into consideration the user's health parameters (heart disease, arthritis, asthma, etc) and the user's goal (to lose or gain weight, improve strength, increase endurance, quit smoking, etc).
In the illustrative implementation, these 5 colors are an expansion of the ubiquitous Stoplight Colors for traffic control (RED/YELLOW/GREEN) that have become “Stop-and-Go” conventions for traffic worldwide. As such here, they are designed to trigger compulsive, lifelong-conditioned responses in users to “Stop” on RED cues and “Go” on GREEN. The system uses these strong internalized negative/positive stimulants to guide the user to his/her desired goal (lose weight, get stronger, get healthier, etc.): e.g., by hopefully shifting the user over time from his/her worst food items (color RED) to nature's best choices (color GREEN) . . . or by elevating an average exercise such as casual “walking” (color YELLOW) to a better exercise like timed “jogging” (color LIME) . . . and ultimately to a best exercise like “running” (color GREEN).
Moreover, in an illustrative implementation, beyond the “best” GREEN level 285 lies a “Superior” BLUE level 286, which represents an exceptional Food or Exercise value that goes beyond 100% on any scale (e.g., exceeding the user's goal). Any such top value is awarded a BLUE RIBBON by the system for superior performance—which is also a recognized color convention. Finally, as also depicted in top block 280, upon each user Food or Exercise input, the system immediately displays its rating as a RED==>BLUE “button” attached to the item.
The center block 290 of
-
- Bottom Level: starting at the bottom level, the first pair of examples 291/292 is actually a continuum of parallel ratings that run the gamut for what nature has to offer as a “nutrient” WRT its bad-to-good effect on the human body:
Unhealthy Nutrient 292 runs the gamut from “Worst”−100%==>0% “Best” . . .
Healthy Nutrient 291 continues the run from “Worst” 0%==>+100% “Best” . . . so that taken together, the pair runs continuously from −100%==>0%==>+100% - Range Limits: each rating example is expressed as a series of 5 range limits that are calculated WRT a baseline of extremes—i.e., each baseline for a given nutrient is established WRT its most accessible, widely-available Top 5 items (e.g., oranges available from any food store as opposed to Borneo jungle fruit):
Healthy Nutrient 100% baseline 291 is based on its highest-rated Top 5 sources (seeFIG. 2E for an example of how a +100% baseline is derived for Vitamin C)
Unhealthy Nutrient −100% baseline 292 is based on lowest-rated Worst 5 sources, so the user can be guided from his worst RED snack to Nature's best GREEN food - Middle Level: at the system mid-level displays are Straight-Line Curves 293 for linear functions, such as milligrams (MGs) for a given Vitamin or Mineral from all food sources. Such a curve is a linear plot of MGs—fewest (RED) to most (GREEN)—where all increments are the same size from 0%==>100% (see
FIG. 2E for an example of how Vitamin C would plot as a straight line, where each 20% increment of 15 MGs corresponds to 11 unique food items) - Top Level: at the top level of system displays are Changing-Rate Curves 294 for non-linear functions such as Weight Loss, which typically starts with a few large increments (40%==>30%) that quickly taper off to smaller increments (20%==>10%) over time. This allows user progress to be displayed as a non-linear RED==>GREEN curve vs. his/her goal curve over a week/month/year (see FIG. 7A4 for an example of how healthy==>to ideal weight tapers off, where each 20% delta of 3 weeks tapers off from 4==>3==>2==>to 1 pound which shows, for example, as often experienced by professional boxers, how difficult it is to burn off the last few pounds).
- Bottom Level: starting at the bottom level, the first pair of examples 291/292 is actually a continuum of parallel ratings that run the gamut for what nature has to offer as a “nutrient” WRT its bad-to-good effect on the human body:
FIGS. 2D1 and 2D2, which is largely self-explanatory, illustrates a database that delineates, in light of the current state of the art, essential nutrients that the human body needs to function properly, together with color codes for each nutrient. Macronutrients (FIG. 2D1) are nutrients the body needs in larger amounts (e.g., >10 grams), and micronutrients (FIG. 2D2) are nutrients the body needs in smaller amounts (e.g., mostly <1 gram) so that it can perform all of its functions properly. Although micronutrients are only needed in minute amounts, their deficiency can ultimately lead to critical health problems.
The database illustrated in FIG. 2D1 shows various categories of macro nutrients, together with their Daily Value (DV) in MGs at 2000 cal per day. The macronutrient categories of essential nutrients for the human body include carbohydrates, sugars, dietary fiber, cholesterol, dietary fat, and proteins. As shown in the left-most column of FIG. 2D1, each macronutrient is further associated with a color code that identifies whether it is good, bad, or somewhere in between. For example, saturated fats (DV=20 g) are associated with a color code of Red that indicates the worst level of health, because Americans typically get far more than 20 g per day—particularly from hamburgers and french fries (e.g., see
-
- Total Cholesterol (mg/dL)=HDL+LDL+Triglycerides/5 (mg/dL) which is unlikely to be calculated or tracked or tracked by most individuals
- The 5 rungs of the Cholesterol Ladder are displayed as 5 corresponding colors to the user for each food with meaningful levels of HDL/LDL cholesterol
FIG. 2D2, which is also largely self-explanatory, is an illustration of essential nutrients-micronutrients database identifying color coding levels for each nutrient that the body needs to function properly. The database illustrated in FIG. 2D2 is based upon nutrient and daily value (DV) data taken from a published USDA database (e.g., downloadable directly from USDA websites) and shows various categories of micronutrients together with their daily value (where a daily value has been established) in micrograms at 2000 cal per day. With respect to food and nutrition tracking, it is significant for users to be aware of whether the foods they are consuming provide the required amounts of nutrients identified in the database of FIG. 2D2. As indicated in FIG. 2D2, each of the associated categories of vitamins, carotenoids, macro minerals, micro minerals, and various trace minerals are color-coded to indicate their Green and Blue Ribbon ratings, indicating their extremely high nutritional value (caveat: no DV can be established for trace minerals since their subtle functions are generally too difficult to isolate). The international-standard USDA Nutrient DB (delineated in FIGS. 4B1 and 4B2) contains all of the above essential nutrients (identified in
With respect to the exemplary nutrient Vitamin C,
As illustrated in
-
- commonly known to the vast majority of users)
- widely available In food stores throughout the country)
- palatable to the vast majority (eliminating “hot spicy” foods))
- consumable in portions >1 ounce (eliminating many garnishing spices
Thus, looking back at the top Vitamin C foods in
100% Baseline and 5 Color Code increments: Once this process qualifies the Top 5 for Vitamin C, a 100% baseline can be drawn beneath the #5 qualifier (Brussels Sprouts) at “greater than 80 mg” such that all foods >80 mg of vitamin C are now considered @ Blue Ribbon level 6. In the example shown
Each of the foods indicated in the illustrated column one of the database is one of nature's finest sources for the identified macronutrients, micronutrients, and minerals, especially where it serves as an abundant source. The database also includes a link to a list of related foods, or best peers, to the identified top food. The database is utilized as a source for providing alternative recommendations of foods so that the system can encourage users, for example, to replace an unhealthy selection with a Top 14 healthy choice (or a best peer). In an illustrative embodiment, users may be encouraged to replace an unhealthy food selection with a healthier selection on a step-wise basis using best peers selected from this database, then stepping up the food ladder to a Top 14 healthy choice. The database also provides a user who has already chosen one of the top-ranked healthy foods with an array of alternate healthy foods to form a weekly food cycle.
FIG. 2G1 shows a database containing an illustrative array of recommended daily intake (RDI) values for various categories of users. This RDA database delineates the daily calories required to sustain men and women of varying age, weight, and level of physical activity. For example, as shown in FIG. 2G1, a man weighing 110 pounds is assigned an RDI of 2000 calories, whereas a woman of the same weight is assigned an RDI of 1500 calories. Similarly, a man weighing 176 pounds is assigned an RDI of 3500 calories, whereas a woman weighing 176 pounds is assigned an RDI of 3000 calories. This 500 calorie difference between men and women at the same weight can be attributed to men being typically more muscular than women (i.e., muscles weigh more than normal body fat). Additionally, adjustments to RDI are made based upon whether the user's nominal physical activity is sedentary, moderate, or heavy. Note that these generic levels have been further discriminated into specific user activities, with associated calories burned across 30 minutes, in FIGS. 5B1 and 5B2. As further illustrated in FIG. 2G1, RDIs are differentiated on the basis of age, i.e., linear calorie increments for 3-year age groupings of children, boys, and girls, followed by single calorie values for adult men, women, and pregnant women, followed by modulated values for senior men, women, and lactating women. (all groups are assumed @ average healthy weight/height for their given age) Here are nutritional points revealed by this illustrative database:
RDI varies considerably with age, sex, body weight, and physical activity\
the singular DV of 2000 calories will only sustain a healthy woman @ 132 lbs
DV of 2000 applies to all women age 19-60, but only if they remain @ 132 lbs
the singular DV of 2000 cals only applies to a healthy 9-year old boy @ 110 lbs
DV of 2000 is not sufficient for any man >110 lbs or for any boy >age 9
the singular DV of 2500 cals applies to all men age 19-60, but only @ 132 lbs
all DVs must be modulated UP for higher weight/heavier activity/pregnancy/etc.
FIG. 2G2 shows that the RDI described in FIG. 2G1 can be flexibly modulated up/down from the singular DV of 2000 calories. And, looking at the expansion of RDI ranges for Protein/Carbs/Fat/Saturated Fat, FIG. 2G2 further shows that such modulations to higher RDIs (e.g., for heavier healthy men) are strictly linear from 1800 cals/day==>DV @ 2000==>2500 cals/day. As explained below, the system described herein calculates a Recommended Daily Intake (RDI) precisely tailored to each user per the Recommended Daily Intake (RDI) database in FIGS. 2G1-2G2. This RDI differs from USDA's ubiquitous “DV for a 2000 calorie diet” (that is strictly applicable to women @ 132 lbs or less). The system's RDI can be fine-tuned to each user's age, sex, activity level, obesity level, current weight, ideal weight, and body frame, which applies to just about every medium- and large-frame Male/Female above 5′2″ in the Ideal Weight database of
-
- Purpose: To capture as much personal user information as possible up front, when the user is first introduced to the system, in an effort to keep tedious, repetitive user inputs to a minimum in the future. This also showcases the expandable functionality of the system and provides a baseline to which the system can compare future user activity.
- Strategy: To capture the minimum data items required for the system to be of the desired degree of help to the user, and then encourage the user to select as many optional favorite data items as he/she is willing to share. However, even if the user fails to provide all his/her ID data, assumptions can be made about the items that allow the system to proceed, but with the caveat of possibly degraded, less relevant recommendations to the user (see below).
- Parallel Audio/Visual Prompts: In an illustrative implementation, system prompts and feedback are offered via parallel synthesized voice and touch-screen visual displays substantially simultaneously, to which the user can respond alternatively by voice or touch (which, inter alia, allows users with heavy foreign accents or speech impediments to more successfully participate).
- Open-Ended Lists: In an illustrative implementation of the Create User Profile Mode (described below), each category in the User Profile displays a set of popular exemplary items to get the first-time user started. This is intended to stimulate the user to visualize and enter as many of his/her own favorite choices as he/she wishes (up to a preset limit N). With all the thousands of foods and exercises that exist, such open-ended lists allow a user to expand his/her profile selectively in all food/exercise categories. This process efficiently personalizes each user profile, without having to maintain/display exhaustive checklists of every food and exercise.
- Quantified Items: In an illustrative implementation, wherever appropriate, data items entered by the user are next quantified by asking “How Much?” with respect to food/nutrition (pounds/pints/ounces) or exercise (pounds/reps/distance)—e.g., “12-ounce steak” or “100-pound bench press for 3 reps”—so that the system can accurately calculate calories in versus calories out for the user as the quantified items appear in the future.
- Exercise Tags: In an illustrative implementation, wherever appropriate, exercise items entered by the user are quantified with “How Long?” (hours/minutes) and “How Often?” (times per week)—e.g., “jog for 30 minutes” or “tennis match for 2 hours” (duration tags in the system database) plus “3 times per week” (frequency tags). Such extended data gives the system a revealing snapshot (or baseline profile) of what foods and exercises the user is already engaged in and at what level.
- Nutrition Tags: In an illustrative implementation, wherever appropriate, each nutrition item selected by the user is further qualified by the system with nutrient tags representing its nutrient value per unit (including, inter alia, calories, carbs, fats, cholesterol, sugars, fiber, protein, vitamins, minerals, omega-3s, herbs, antioxidants, etc.), plus an overall rating tag representing its relative value to user health from 1 to 5 (explained below). These short nutrition and exercise tags are further examples of how the system efficiently expands user profiles outward while keeping storage to a minimum.
- Parallel System/User Databases (DBs): In an illustrative implementation, all items accepted from the user are stored immediately in the user DB within the mobile computing device's (e.g., smart phone's) local memory 15, and then later as a cumulative batch update in the parallel system DB within remote server 14. Having a parallel, for example, smart phone DB allows the user to view/update/add items to his/her DB locally offline at his/her convenience, without tying up the phone with unnecessary, sustained low-activity communication to the remote server. Equally important, it enables the user to access his/her DB in remote areas and enclosed buildings (such as restaurants/spas/gyms) that often have degraded or no phone signal.
Streamlined Database Structure: In an illustrative implementation, tracking the wide range of every possible snack-to-dinner food item and low- to high-energy exercise requires many “wordy” user inputs each day across long periods of time. Hence, in an illustrative implementation, the system DB structure has been radically streamlined to minimize its size and to curb its exponential growth. In this example, all of this starts with the User Profile Create mode (below) where, e.g., each open-ended list is constrained to actual user choices 1-N (as above) and quantified with short tags (as above). In such an implementation, the User Profile Create mode generates a single baseline record from initial user inputs that the user can later expand, one item at a time, in any food or exercise category. However, none of these long “wordy” entries (1−N) are repeated in subsequent daily records where any repeat is represented by a simple binary “ditto” (1−N). Thus, in an illustrative implementation, the system DB has one long baseline record followed by a string of short daily records that can compress the span of many years into a small disk area.
The table below summarizes various aspects of the creation of illustrative user profiles, subsequent revisions/modifications thereof, user profile-related process flow and exemplary data structures involving food and exercise. Various user profile features and data structures are explained in detail below particularly in conjunction with the referenced
In an illustrative implementation, as shown in
In the Create Mode, in an illustrative implementation, the user selects User ID in order to enter the following Minimum User ID data 306 for the system in this example:
-
- Name: required in an illustrative implementation to maintain a unique baseline record for each person—but since all kinds of aliases may arise, such as initials, first/last name only, nicknames, screen names, etc., the UP may add unique numbers to make each user name unique
- Sex: required in an illustrative implementation to calculate his/her ideal weight via the Ideal Weight DB, and to recommend exercise regimes appropriate to his/her natural motions and limits
- Age: required in an illustrative implementation to differentiate higher-to-lower calorie requirements to account for the younger, more energetic teenagers . . . to the older, more sedentary retirees
- Height: required in an illustrative implementation to calculate ideal weight via the Ideal Weight DB, ranging from 4′10″==>6′6″ for both men and women (the DB can be further extended for taller/shorter users, if necessary)
- Weight: required in an illustrative implementation to calculate ideal weight via the Ideal Weight DB (
FIG. 13C ), to serve as the primary baseline to compare successful weight loss (or gain) and, from a system point of view, to calculate reasonable increments to achieve ideal weight—in illustrative implementations, the DB has been structured to permit an accurate determination of ideal weight, taking into account various user characteristics. In some of these illustrative implementations, the UP may ask for user weight “5/10 years ago” to glean a historical trend. - Wrist Size (
FIG. 12B ): may be advantageously used to differentiate body frames via the Ideal Weight DB as small/medium/large—a revealing, user friendly measurement (takes 30 seconds) that can serve to discriminate between such worldwide healthy extremes as:
Women (small frame)<==>Women (large frame, both healthy)
@ healthy weight MIN edge @ healthy weight MAX edge
Note: Wrist Size is a more user-friendly measurement than the more difficult
Elbow Size that was initiated by Met Life in 1942 (seeFIG. 12B ) - Waist Size (
FIG. 12C ): required to differentiate obesity level via the Ideal Weight DB as healthy/overweight/obese—a revealing, user friendly measurement (takes 30 secs) that can serve to discriminate between such worldwide obesity extremes as:
Women (large frame)<==>Women (large frame, same height)
@ healthy weight MAX edge @ obese weight MIN edge
Note: this metric can also separate muscular healthy athletes from obese people at the same height and weight. - Goals: although the most commonly desired goal today is to lose weight, the system is designed to handle a wide variety of users: from obese to underweight, from out-of-shape weak to perfectly fit, from sick to healthy, etc. Thus, the system has been designed to handle user goals that are going to vary accordingly:
from lose weight==>to gain weight
from get stronger==>to last longer (more endurance)
from get healthier==>to drop bad habits (e.g., smoking/drinking/drugs)
Note: in illustrative implementations, the user has the option of selecting as many goals as desired; e.g., most people would like to get healthier while they are trying to lose weight.
-
- Timeframe: used to calculate reachable increments toward the user goal across a reasonable time interval with a typical range of 1-2 lbs per week
- Rewards: a significant factor in achieving goals—in this case, it is a user reaching an incremental goal toward resurrecting his/her own health and body. In illustrative implementations, rewards are downloaded iTunes and Netflix movies—and these can be expanded to prizes (for achieving a long sought-after goal) such as dinner at an organic free-range chicken restaurant
- Default User ID data: for an illustrative implementation, all the above items are considered minimum User ID data needed to calculate an ideal weight for any given user, and to facilitate him/her achieving that goal (or any other goal above) via reachable increments toward that goal that are rewarded proportionally. It should be understood that in some illustrative implementations, apart from all the above minimum User ID data needed to calculate a user's ideal weight, the system can just as easily be run with a few token values made up by the user, or even none at all, if desired by a particular user. That is, the user could simply experiment with the system by plugging in any token height/weight/sex and look to see how the system would go about resolving a typical overweight male/female, e.g.:
Male: 5′9″ @ 195 lbs (assumed to be about 16 lbs overweight)
Female: 5′4″ @ 170 lbs (assumed to be about 24 lbs overweight)
Furthermore, it is noted that this system can be run without any of the minimum User ID data—e.g., as an exemplary “trial demo” (for a user who has no desire to enter data) by, for example, making a few real-world assumptions regarding the user, who could be an average U.S. male/female (whose actual weight/height/overweight level are listed above). The average U.S. male/female are then compared to an “ideal” average male/female at a similar height—in this case, an average German male/female, whose average weight is deemed “ideal” by the Ideal Weight DB shown in
Minimum User Clicks: In illustrative implementations to promote enhanced user friendly data entry, the User Profile module is streamlined to yield the highest level of system output for the least number of user input “clicks” (where a “click” can be, for example, a written or spoken entry or a choice from a displayed list) to keep the user enthusiastic and locked in throughout the initial Create mode, as follows:
Maximum User Choices in Minimum Time: In illustrative implementations, to facilitate the user's food/exercise entries shown in the above table, the UP has also been streamlined at all levels to provide the User the maximum number of popular choices (primarily, via the open-ended lists of
Turning back to
-
- Ideal Weight: in illustrative implementations, the data base illustrated in
FIG. 13C zones in on an ideal weight for both Men and Women and for people with different body frames and vastly different levels of obesity. As in any system, the higher the level of precision to pinpoint correct ideal weight means the higher the level of precision for all calculations that follow (below) - Weight Loss Increments (or “deltas”): UP calculates a reachable weight “delta” within a periodic interval (week/biweek/month/etc.) based on his/her specified timeframe, all of which is precisely tailored to each user
- Ideal Weight: in illustrative implementations, the data base illustrated in
Recommended Daily Intake (RDI): UP calculates an RDI precisely tailored to each user per the RDI database in FIG. 2G1. This RDI differs from the USDA's ubiquitous “DV for a 2000 calorie diet” (that is primarily applicable to women @ 132 lbs or less). The system RDI can be fine-tuned to each user's age, sex, activity level, obesity level, current weight, ideal weight, and body frame, which applies to just about every medium- and large-frame Male/Female above 5′2″ in the Ideal Weight data base of
-
- Calorie Counters: UP maintains a set of running Calories IN/Calories OUT counters that keep track of running daily/weekly/monthly amounts of Calories IN (from food eaten by the user) versus parallel running amounts of Calories OUT (from exercise by the user) that can be selectively displayed or plotted by the user. UP maintains these counters based on food eaten (where each gram of protein or carbs=4 Calories, each gram of fat=9 Cals, each gram of alcohol=7 Cals, etc.) and based on user exercise to balance out the food eaten (where each pound worked off=3500 Calories). Thus, at any given time or for any given timeframe, weight loss can be easily calculated via the delta between Cals IN vs. Cals OUT:
Weight Loss Delta (lbs)=(Cals OUT−Cals IN)/3500 Cals per pound
-
- Goal Percentage (%): Armed with these pairs of running Calorie Counters, at any given time or across any given timeframe, UP can now maintain a corresponding set of running Goal Percentages (%) with respect to the user's specific ideal weight and/or current weight increment above, as follows: Current Goal (%)=current Weight Loss Delta/current Weight Increment
Ideal Weight Goal (%)=cumulative Weight Loss Deltas/(Baseline Weight−Ideal Weight)
In an illustrative implementation, the above Calorie Counters and Goal Percentages are displayed on the user's mobile computing device 1 screen as running display counters, or as more stimulating color X-Y plots of Weight across Time—e.g., as cumulative weight loss vs. successive weight increments.
User Profile Modify Mode: the above System Tracking Data 308 is initialized by the Create Mode at the user's declared Goal(s) and Weight, plus UP-calculated Ideal Weight. Beyond these initial baseline entries, all remaining user tracking functions—including successive weight increments, calorie counting, and goal percentages—are performed by the Modify Mode during subsequent UP passes, following the same process flow shown in the flowchart of
Parallel Audio/Visual Interface: As set forth above, in an illustrative implementation, all User Profile prompts and feedback, as well as all user choices for data entry and/or next course of action, are offered to the user via simultaneous, parallel synthesized voice and touch-screen video, to which the user may respond alternatively by voice or touch.
Turning back to
After finishing User ID processing, if the user hits any icon but “User Health” (NO out of 324), the UP tests for Create Mode at 326 and, if it is in not in the Create Mode, but is in the Modify Mode, advances to Nutrition 348 (NO out of 326). Otherwise, UP prompts the user to “please enter all Health items” at 328 and returns to re-enter User Health data 330, as will next be delineated item-by-item.
In the Create Mode, in an illustrative implementation, the user must select User Health to enter the following Minimum User Health data 306 for the system to optimally assist in recommending food/exercises that are not otherwise unsafe or even harmful. It is expected that individuals will be open and honest about their handicaps, ailments and injuries.
-
- General Level of Health: in an illustrative implementation used to actively elicit from a user a rating defining the user's self-image of his/her own health, on a color-coded scale of Worst 1==>5 Best. In illustrative implementations, UP next may ask the follow-up “What level 5 and 10 year ago?” to glean a historical trend.
- In illustrative implementations, each item below has “None” as the first answer to accelerate healthy users through this Health section as quickly as possible.
- Injuries: In illustrative implementations, UP first asks whether a user's injury is permanent or temporary (with a date for expected recovery). It then asks what areas of the body are affected, such as skeletal, muscles, organs, nerves, brain, etc., followed up, as needed, by what limbs such as (right or left) hand/foot/arm/leg/torso/back/neck/etc. Such a body injury profile guides the system away from bad limbs to help the remaining good ones
- Ailments: In illustrative implementations, ailments such an diseases (cancer, diabetes, etc.), and allergies. UP follows the same inquiry process as that above to identify specific Injuries, except that ailments often imply a weakening of the entire body which can preclude, e.g., eating certain foods and nutrients, exercising outdoors, exercising the remaining healthy limbs (as above), etc.
- Handicaps: In illustrative implementations, UP follows the same inquiry process as that above to identify specific Injuries except handicaps often imply a severe weakening of entire limbs or the entire body which can complicate any system trying to help them, e.g., mobility limited to a wheelchair, exercise limited to special gym equipment, etc.
- Addictions/Health Impacting Bad Habits: Only addictions and habitual behavior that significantly affect body health and/or normal exercise—namely, smoking, drinking, and drugs—are embraced in illustrative implementations tracking these activities. Here, UP asks the simple question of frequency, “How often?” on a scale of Seldom 1==>5 Every Day. However, focusing on these three activities does not in any way preclude adding any number of other habitual behaviors that affect health and/or exercise to a lesser degree, or that involve fewer people.
- Medications: Each of the above Health issues can require Meds that may be inconsistent with or interact with certain foods/nutrients/supplements the system might normally recommend. Therefore, UP asks in illustrative implementations for whatever Meds the user is taking regardless of the specific health reason, to avoid such unnecessary, potentially hazardous conflicts.
- Historical Trends: Finally, for each of the significant injuries, ailments, handicaps, and bad habits, UP asks the follow-up “What level 5 and 10 year ago?” (optional) to glean a historical trend that may influence recommended exercises and/or diets.
In an illustrative implementation, once the user enters the above Minimum User Health data 330 in the Create Mode, UP can now establish the system baseline User Restrictions 332 based on, for example, the injuries/ailments/handicaps/bad habits/meds disclosed by the user, and set RED flags on all foods/diets and exercise regimes that should be excluded due to them, particularly during subsequent passes in the Modify Mode. In an illustrative implementation, these RED flags are backed up by a RED Zone Body chart (not shown) that flags affected body areas.
Vitamins/Minerals: Similarly, in an illustrative implementation, a goal of the Create mode at 352 is to encourage a user to enter certain favorites identifying his/her Top 5 favorite supplements among Vitamins/Minerals/Herbs/Omega-3s/Antioxidants (which are the system's 5 supplement categories), following the same user input process as above. For Vitamins, this could be as complicated as all eight Vitamin E tocopherols and tocotrienols (each has alpha/beta/delta/gamma variations) or as simple as a One-a-Day multi-vitamin (the process for specifying Top 5 is described in detail next with
Color-Coded Foods/Nutrients: As shown and illustrated in
Top-to-Bottom Color Codes: In an illustrative implementation, this color-code rating extends across the entire system—from top-to-bottom. For example, at the highest level, each meal (Breakfast/Lunch/Dinner) is color coded with a RED==>GREEN color based on the weighted-average color of all its food elements (drink/appetizer/entrée/vegetable/dessert/etc). This same color rating extends all the way to the lowest level where, for example, each food item is color-rated WRT its cals/carbs/sugars/fiber/fats/cholesterol/protein/etc—as well as its total vitamins/minerals/omega-3s/antioxidants/etc—each nutrient individually.
Hence, to satisfy likely user curiosity, the inquisitive user can click on any color-coded icon (food/vitamin/exercise/etc.) to find out exactly what lower-level element (high LDL cholesterol/low protein/slow walking pace/etc.) caused the RED ALERT.
Moreover, this top-to-bottom color-coding serves to educate the user as to each item's “bad” RED elements that were otherwise “hidden” from his/her view prior to using this system—revealing why he/she should move up to the next-higher level food choice. Alternatively, it reveals what he/she has to do to correct and/or improve a RED exercise.
User Health/Attitude Profile: One significant function of storing a user's food/nutrient favorites is to piece together a revealing snapshot of the user's current health—and his/her collective attitude toward healthy eating via Top 5 Meals and adequate nutrition via Top 5 Vitamins—presumably formed over many years. Taken together with Top 5 Exercises (gathered via parallel
On the positive side: if the user reveals a long-term healthy diet profile, the system can more aggressively “harden” the recommendations toward the highest GREEN level foods to accelerate the user directly to his/her ideal weight—such “hardening” is especially important for already fit athletes, who easily qualify for this group.
On the negative side: however, if the user reveals a long-term unhealthy diet profile, in an illustrative implementation, the system may, for example, cautiously “soften” the recommendations toward the lowest RED level—such “softening” avoids overburdening an obese user with average goals that are beyond his/her physical reach and current diet attitude. Such a plan may be modified as desired to accelerate obese users towards goal achievement based upon a medical need to do so, or an indication from an analysis of performance data that the user is ready for more accelerated goal achievement.
For more details on how this strategy is fine-tuned, see the discussion on how food are adapted to each user by the Create mode in
Food Database:
[1] the top-level Categories (horizontal axis across
[2] the middle-level Dishes (vertical axis down
[3] an Open-Ended List for each mid-level Dish (into the paper in
[4] the bottom Tags attached to each open-ended List (orthogonal to above 3 axes)
As shown in
[1] the top-level Categories (horizontal axis across
[2] the middle-level Dishes (vertical axis down
[3] an Open-Ended List for each mid-level Dish (into the paper in
[4] the bottom Tags attached to each open-ended List (orthogonal to above 3 axes)
-
- The UP access sequence for this Food DB is broken into 5 major Categories: Breakfast 360/Lunch 362/Dinner 364 plus Snacks 384/Drinks 385 (not shown here for clarity) as shown on
FIG. 3C . UP accesses each level as follows: - UP accesses these 5 Categories sequentially (as shown by the top arrows), overflowing into Snacks 384/Drinks 385 on
FIG. 3C before exiting. - Next, for each of the 3 meal categories, UP cycles through the 3 Dishes: 1st Course 366/Entrée 368/3rd Course 370 (as shown by the middle arrows).
- Within each of the 3 Dishes, UP cycles through 4 Meal Items that, taken together comprise 12 unique items for each meal (as listed at 366/368/370), the significance of which is explained in more depth in
FIG. 3C (below). - Within each of the 4 Meal Items, UP cycles through the 3 Tags at the bottom: Add-Ons 372/Quantity 374/Nutrients 376 (as shown by the bottom arrows), which are selectively created as-needed to qualify or quantify the item.
- Finally, the last Tag—Nutrients 376—is generated by UP as a helpful FYI for the user, with RED==>GREEN codes displayed with each nutrient to educate him/her as to the relative GREEN value or RED danger posed by that Meal Item, and the Meal as a whole (as discussed at Color-Coded Foods/Nutrients above).
- Moreover, it is hard to grasp the significance of the first Tag—Add-Ons 372—until the system calculates the total calories added to meal items by the Add-On examples (sauce/dressing/gravy/syrup/cream/etc.) that can downgrade an ordinarily healthy slice of turkey to RED ALERT, as will be discussed in depth next with
FIG. 3C .
- The UP access sequence for this Food DB is broken into 5 major Categories: Breakfast 360/Lunch 362/Dinner 364 plus Snacks 384/Drinks 385 (not shown here for clarity) as shown on
Food Database Meal Matrix:
[1] the 5 Categories corresponding to horizontal Matrix columns 381==>385
[2] the 12 Dishes corresponding to vertical Matrix rows 387==>398, except that Snacks/Drinks (columns 384/385) are not indexed to the 12 Dishes (column 380)
[3] the 60 Open-Ended Lists corresponding to each cell in the 5×12 Matrix array, where each cell initially contains a popular example to stimulate User choices
[4] the 3 Tags attached to each of the 60 Open-Ended Lists (180 max Tags) where:
Add-Ons 372 initially contain a popular example, like sauce/dressing/syrup/etc.
Quantity Tags 374 are generated by the user after he/she eats each food/meal
Nutrient Tags 376 are generated/displayed by the system upon user request
Top 5 Favorite Meals: UP initially asks the user to enter up to 5 Favorites for each Category 381==>385, starting with his/her #1 favorite food, and optionally entering up to 4 or more favorites per category at user discretion. At any time from this juncture on, the user can conveniently select any “repeat” favorite by its sequence number among the Top 5 Favorite lists—for example:
Breakfast #1==>Lunch #2==>Dinner #3==>Snack #4==>Drink #5
which saves the user all the time and effort to re-enter the same Favorite food/meal
This initial system/user interplay over Top 5 Favorites provides the opportunity for UP to find out exactly what the user's attitude toward food is, and perhaps even explain where all his/her excess weight (if any) came from—e.g., even if the user doesn't eat the favorites very often. Knowledge of the users urges may be significant in guiding the user towards a more healthy diet.
The system advantageously matches the 60 food examples shown in the initial matrix of
Based on all the above User ID/User Health inputs (that will normally yield an ideal weight and target weight loss goal for the user) coupled with the skeletal user “5/10 years ago” history data, UP can gauge which initial 1==>5 level to display. That is, as an illustrative embodiment here, the 60 examples shown in
This initial Create mode strategy dovetails with the higher-order strategy of an illustrative implementation of the entire system to facilitate weight loss (or gain), which can be accomplished more effectively when the system knows the exact diet/exercise profile of the user:
at the obese RED extreme, in an illustrative implementation, UP will present all the customary RED foods that likely enticed certain users to become obese in the first place, to avoid wasting their time with GREEN foods they already ignore, and to otherwise establish an accurate RED baseline
at the healthy GREEN extreme, UP will present all the high-caliber GREEN foods that fit athletes are already aware of and/or eating religiously, to avoid wasting their time with RED foods they already dislike, and otherwise establish an accurate GREEN baseline
-
- One such illustrative system strategy is to boot-strap each user from his/her current RED==>GREEN level (as just described) up the diet ladder, one notch at a time, as shown with the Meat Ladder below:
-
- As can be seen from the essential macronutrients database of
FIG. 2D , the rib roast is high in calories, low in protein, and high in fat when compared to the light turkey shown in the above chart. The calories, protein, and fat parameters for rib roast are unhealthy and merit a red rating. In contrast, white meat turkey calorie, protein, and fat parameters are healthy and merit a blue rating. The diet ladder chart shows that the rib roast alternatives of sirloin steak, round steak, dark chicken, and light chicken provide increasingly healthy choices that a user may progress through on a stepwise basis to habitually consume more healthy products. - Thus, this Meat Ladder chart illustrates an illustrative system strategy of boot-strapping the user at any diet level—e.g., obese RED==>healthy GREEN—up the ladder, one step at a time—from the fattening RED rib roast or ORANGE sirloin steak, up the ladder toward the GREEN light chicken or ultimate BLUE light turkey
- This Meat Ladder concept illustrates how the system can make a user healthier: i.e., there is a similar 5-color food ladder for each one of the 60 Open-Ended Lists by which the system can improve a user's diet, one step along one ladder at a time.
- As can be seen from the essential macronutrients database of
In one implementation, the system operates to recommend healthier foods to a user as follows. In an illustrative implementation, after a user has selected a food such as “rib roast,” the system will encourage the user to “step up the ladder” by selecting a healthier alternative that is next highest up the ladder of related foods, such as described in the meat ladder above. In this implementation, the healthier alternative is added to the users “favorites” list in a highlighted fashion ((e.g., displayed higher up the favorites list based upon a displayed color code indicating a “healthier choice” than the red colored rib roast) with a frequency count of zero indicating that the user has not selected the food at this particular point in time. However, the presence of the food in the user's favorites list will serve to encourage future selection by the user.
Turning back to
Thus, one or more of the foods shown in
-
- Although in this example there is no minimum required data here in Create
Mode, as a purely “common sense” rule of data entry, in one implementation, UP obliges the user to at least consider each of the five Exercise categories of Daily Activities, Periodic Activities, Sports, Conditioning Exercise, and Weightlifting (406/410/414/418/428). Each of the exercise categories in
-
- Moreover, other than lifting weights, there are enough ubiquitous activities (e.g., “sit at work (perhaps the lowest level of activity)” or “walk outdoors”), that all but handicapped users are likely to do them. Forcing such an obligatory first look at each category, serves to introduce the user to the vast array of exercises he/she can get credit for.
As described earlier for Nutrition (
While picking out 5 favorites for each category is entirely optional, UP encourages the user to specify at least his/her #1 “all-time” favorite exercise items (per the Minimum User Click chart above) which, for Daily Activities 408, could be as complex as “lifting a heavy load overhead” . . . or as simple as “sitting at a desk”.
Similarly, the goal of Create mode at 424/426 is to encourage the selection of favorites from the user as to his/her Top 5 favorite conditioning exercises among indoor/outdoor regimes and upper/lower body weight lifts 428, following the same optional input process as above. For weightlifting 428, this could be as complex as “max bench press with 2 spotters” or as simple as “wrist curls with 25-lb bar” (the process for specifying Top 5 is described in detail next with
Color-Coded Activities/Exercises: as shown and illustrated in
In this example, color-code rating extends across the entire system, from top-to-bottom. For example, at the highest level, each workout (all sets/reps/weights combined) is color coded with a RED==>GREEN color based on the weighted-average color of all its separate lifts (for torso/upper limbs/lower limbs). This same color rating extends all the way to the lowest level where, for example, each set of a given lift is color-rated for its reps/weight level/rest interval WRT user capability.
Hence, in an illustrative implementation, to satisfy user curiosity, the inquisitive user can click on any color-coded icon (5-mile run, 100-lb lift, etc) to find out exactly what lower-level element (slow pace/weight too low/rest interval too long) caused the RED ALERT.
Moreover, this top-to-bottom color-coding serves to educate the user as to each item's “toxic” elements that were otherwise “hidden” from his/her view prior to using this system—revealing why he/she should move up to the next-higher level. In addition, it points to what he/she has to do to correct/improve a RED exercise.
User Health/Attitude Profile: the underlying motive for encouraging selection of the user's favorites is to piece together a revealing “snapshot” of the user's current fitness—and his collective “attitude” toward healthy lifestyle via Top 5 Activities and healthy conditioning via Top 5 Exercises—presumably formed over many years. Taken together with Top 5 Exercises (gathered via parallel
On the positive side: if the user reveals a long-term healthy exercise profile, the system can freely “harden” the recommendations toward the highest GREEN level exercises to accelerate the user directly to his/her ideal fitness—such “hardening” is especially important for already fit athletes, who easily qualify for this group.
On the negative side: however, if the user reveals a long-term unhealthy exercise profile, in this example, the system will cautiously “soften” the recommendations toward the lowest RED level—such “softening” avoids overburdening an obese user with average goals that are beyond his/her physical reach and current exercise attitude.
For more details on how this strategy is fine-tuned, see the discussion of how exercise examples are adapted to each user by the Create mode in
Turning to a more detailed discussion of the flow between the blocks on
Daily Activities 408: upon entry (YES out of 406), UP initially offers the “To/From Work” choices to give the user extra credit for, say, walking to work—then offers the choices of what activities the user performs on a daily basis at work (or school) including at a minimum, “sit at desk”, referenced to Indoor or Outdoor, where all user responses are merely his/her estimates of average hours per day. When the user is finished, UP next highlights the icon for Periodic Activities 410.
Periodic Activities 412: upon entry (YES out of 410), UP initially offers simple Home Tasks, such as “mow lawn” or “wash dishes”—then offers some low-energy/recreational Sports away from home—indexed to Indoor or Outdoor. When the user is finished, UP next highlights the icon for Competitive Sports 414.
Competitive Sports 416: upon entry (YES out of 414), UP initially offers Competitive Individual Sports, such as “Martial Arts” or “Tennis”—then offers high-energy Team Sports such as “Football” or “Basketball”—all referenced again to Indoor or Outdoor. UP next qualifies each sport as to its competitive level: training only/hobby or recreational/middle school/high school/college/sport club/semi-pro/pro—in order to establish a ball-park measure of the user's athletic fitness. When the user is finished, UP next highlights the icon for Conditioning Exercise 418.
Conditioning Exercise 424: if the user does not enter this Category (NO out of 418), UP prompts him/her at 420 with “any other exercise not identified yet?” and, if not, tests for Create Mode—if YES out of either test 420/422, UP returns to the user to Conditioning block 424. Either way, upon 424 entry (YES out of 418), UP initially offers Outdoor exercises, first using Body Only, then with Equipment. >Next, UP offers Indoor Strength/Endurance exercises, first using Body Only, then with indoor Equipment—followed by Stretch/Balance exercises like “Yoga”
Finally, UP offers Indoor Weight Training exercises, first for the Upper Body, then for the Lower Body—covering all the opposing muscle pairs (see
UP next qualifies each exercise as to its competitive level: (training only/hobby or recreational/middle school/high school/college/sport club/semi-pro/pro) so as to establish a ball-park measure of the user's athletic fitness. When the user is finished, UP next returns at 430 to the system Mainline Routine.
[1] the top-level Categories (horizontal axis across
[2] the middle-level Modes (vertical axis down
[3] an Open-Ended List for each mid-level Mode (into the paper in
[4] the bottom Tags attached to each open-ended List (orthogonal to above 3 axes)
UP access sequence for this Exercise DB is broken into 5 major Categories: Periodic 440/Sports 442/Conditioning 444/Weights 446 plus Daily (not shown here for clarity) as shown at 481 on
-
- UP accesses these 5 Categories sequentially (as shown by the top arrows), starting with Daily Activities 481 on
FIG. 3F before entering Periodic 440 here. - Next, for each of the 5 exercise categories (including Daily Activities 481), UP cycles through the 4 Modes: Outdoor 450/Indoor 452/Upper Body 454/Lower Body 456 (as shown by the middle arrows).
- UP accesses these 5 Categories sequentially (as shown by the top arrows), starting with Daily Activities 481 on
Within each of the 4 Modes, UP cycles through 2 Forces that, taken together, comprise all unique types of exercise (as listed at 450/452/454/456), the significance of which is explained in more depth in
Frequency 460/Duration 462/Cycle 464/Quantity 466 (as shown by the bottom arrows), which are selectively created as-needed to qualify or quantify the item.
Finally, the last Tag—Quantity 466—includes horizontal ground Distance, which the system can optionally provide via GPS tracking if the user decides to carry his/her mobile computing device 1 equipped with GPS capabilities (e.g., an iphone) along on an outdoor walk/jog/run/skate/bike trip/etc. Here at the lowest data level, each data item associated with each tag is also displayed with RED==>GREEN color codes to inform him/her as to the relative GREEN positive or RED negative value of that particular exercise parameter, and the Exercise as a whole (as discussed at Color-Coded Activities/Exercises above)
[1] the 5 Categories corresponding to horizontal Matrix columns 481==>485
[2] the 10 Modes corresponding to vertical Matrix rows 487==>496, except that To/From Work (column segment 498) is not indexed to the 10 Modes (col. 480)
[3] the 50 Open-Ended Lists corresponding to each cell in the 5×10 Matrix array, where each cell initially contains a popular example to stimulate User choices
[4] the 4 Tags attached to each of the 50 Open-Ended Lists (200 max Tags) where:
Frequency Tags 460 initially contain a popular example like “3 times per week”
Duration Tags 462 initially contain popular example like “60 mins per workout”
Cycle Tags 464 initially contain a popular example like “3 sets @ 10 reps”
Quantity Tags 466 initially contain popular examples like “100 lbs” or “1 mile” that are later modified or updated by the user after he/she completes a set or a run (or alternatively hits “done” to stop optional GPS tracking for a walk/jog/run/etc.)
Top 5 Favorite Exercises: UP initially asks the user to enter up to 5 Favorites for each Category 481==>485, starting with his/her #1 favorite, and optionally entering up to 4 or more favorites per category at his/her discretion. At any time from this juncture on, the user can conveniently select any “repeat” favorite by its sequence number among the Top 5 Favorite lists—for example: Daily #1==>Periodic #2==>Sports #3==>Conditioning #4==>Weights #5 which saves the user all the time and effort to re-enter the same Favorite exercise.
This initial system/user interplay over Top 5 Favorites provides an opportunity for UP to find out exactly what the user's attitude toward exercise is, and perhaps explain where all his/her excess weight (if any) came from—e.g., even if the user doesn't do the favorites very often, it is his/her urges that count. The system matches the 60 exercise examples shown in the initial matrix of
This initial Create mode strategy dovetails with the higher-order strategy of an illustrative implementation of the entire system to facilitate weight loss (or gain), which can be accomplished more effectively when the system knows the exact exercise profile of the user:
at the obese RED extreme, in an illustrative implementation, UP will present all the customary RED activities that may have contributed to the user's obesity in the first place, to avoid wasting their time with GREEN exercises they already ignore, and to otherwise establish an accurate RED baseline
at the healthy GREEN extreme, UP will present all the high-caliber GREEN exercises that fit athletes are already aware of and/or doing religiously, to avoid wasting time with RED activities they dislike, and otherwise establish an accurate GREEN baseline.
One such illustrative system strategy is to boot-strap each user from his/her current RED==>GREEN level (as just described) up the exercise ladder, one notch at a time, as shown with the Walk/Run Ladder below:
-
- This Walk/Run Ladder illustrates the prime system strategy of boot-strapping a user at any exercise level—e.g., obese RED==>healthy GREEN—up the ladder one step at a time—from the slowest RED walk time or ORANGE Walk/Jog time, up the ladder toward the GREEN fast run time or ultimate BLUE fast sprint time
- This Run/Walk Ladder illustrates how the system can make a user healthier: i.e., there is a similar 5-color exercise ladder for each one of the 60 Open-Ended Lists by which the system improves user exercises, one step along one ladder at a time.
Initially, a check is made at block 502 to poll for the user selecting his/her “favorite foods” icon. As explained above for
If the check at block 502 reveals that the “favorite foods” icon was selected, the routine displays the various food categories (510) described above for
If the check at block 514 reveals a category has been chosen, then the user food database (516) is accessed to, for example, obtain the user's favorite foods for breakfast, assuming the “breakfast” category was chosen. The user's favorite foods for breakfast are then displayed together with the frequency of consumption (518). The user may, for example, select favorite breakfast No. 1, (which may, for example, consist of one cup of Cheerios with whole-grain and ½ cup of skim milk), whereupon the associated tag information is displayed with associated color codes. Such tag information includes nutritional information (such as 140 calories, 2 grams of total fat, 160 mg of sodium, 1 g of sugar, etc.) that is accessed from Nutrient DB (566), as explained below.
It is noted that, every time the user eats a given food item, that item is added to the favorites list, together with an indication of the number of times such food has been consumed. By tracking the number of times an item is eaten, the system is able to rank favorites based on the user's frequency of eating that food item over time.
In illustrative implementations, the system operates to recommend healthier foods to a user. In such implementations, by way of example only, after a user has selected a RED food such as “rib roast,” the system encourages the user to “step up the ladder” at least one rung by selecting a healthier alternative that is the next highest up the ladder of related foods, such as described in the exemplary Meat Ladder shown above. This healthier alternative is added to the user's “favorites” list in a highlighted fashion (e.g., displayed higher up the favorites list with a higher-level color code indicating a “healthier choice” than the RED color-coded rib roast) with a frequency count of “zero”, until the user selects the recommended food which raises the count to “one”. However, the presence of the food in the user's favorites list serves to encourage later selection by the user.
Turning back to the flowchart in
If the user has chosen a food and quantity as determined at block 520, a check is then made at block 522 to determine whether the user has selected a different add-on than the original favorite (if any). If the user has not selected a different add-on at block 522, the routine branches to node C at block 560.
If the user has decided to add a different add-on, such a new or additional add-on is then specified at 524 so that data can be accumulated for a new food record. For example, if the user had selected a meal including ham and eggs with the add-on “honey” on the ham, the check at block 522 gives the user an opportunity to select a different add-on for the ham and eggs at 524 such as “apple sauce”. In an illustrative embodiment, the system provides an open-ended list of alternative add-ons for each food selected that is augmented by each new add-on declared by the user. Alternatively, the user may identify the add-on by voice input, as described earlier. The user's selection may in an illustrative embodiment be confirmed by a display to the user of the selection made, such as by a textual display of “apple sauce.” In an illustrative implementation, the newly-selected add-on is next attached to the food item as a tag, as shown in
Once an add-on has been specified by the user or, if the user does not include a different add-on, the routine branches to block 560 at node C. As indicated at block 560, the chosen foods are displayed as a tentatively selected meal, items and add-ons, reflecting the user's selections (562). The meal referred to in block 562 is an aggregate of all the items constituting the meal. Furthermore, each item may have its own separate add-on (e.g., a sauce, dressing, butter, etc.).
In an illustrative implementation, the meal itself, each of the items in the meal. and each add-on has an associated color code that is displayed to inform the user as to, for example the relative healthiness of each meal/item/add-on to be consumed. In addition, in an illustrative implementation, a user may request to see the nutrient content of a food item/add-on selected, as indicated by the “show nutrient” check at block 564. Such a user selection may be prompted by, for example, a RED color code associated a selection, as would be the case with a rib roast or an ice cream sundae.
If the check at block 564 indicates that the user has chosen to see an item's nutritional content, the system then accesses the Nutrient Database (566) which displays all the food nutrients (and their quantities) associated with the item selected (at its quantity). All of this is displayed to the user together with associated color codes indicating the quality of nutritional content (568) via a call “F1” to the Calculate Calories utility subroutine shown in
After the nutrient display, a check is made at 570 to determine whether the user has chosen to eat the food tentatively selected after reviewing the nutrient value and color code information displayed at 568. If the user chooses not to eat the food, the routine returns to the mainline in
If the user chooses to eat the food selected at 570, the user Food Database is updated at 571. If the item is a Favorite Food, the program (573) calls the Calculate Calories subroutine at “F1” (where the food's usage counter is incremented by one) and, upon its return, exits to the mainline at 572. If the item is not a Favorite Food, the program creates a new record for each item in the meal (including its associated quantity, add-on(s), and calories), appends the new record to the Favorite Food DB (with a usage count of zero), and makes the same “F1” call and final exit as above. In this manner, the system is able to sort and display the user's favorite foods according to the frequency he/she eats those foods.
In other words, any new food item, such as an old meal but with a new add-on, is added to the favorites list via creation of a new record—hence, the system creates a new record for each such item plus tags (575). The tags in this example identify the quantity of the food item consumed, together with any add-ons and their calories consumed, displayed separately on the same screen. The manner in which the total calories are monitored and tallied is discussed below in conjunction with
As shown in
The routine then checks at 530 whether a restaurant or diet plan has been chosen. If a restaurant/diet plan has not been chosen, the routine branches back to node “A” to poll for another mode selection. For convenience purposes, only restaurant menus are identified below without further reference to diet plans. It should be recognized that the description below equally applies to the user making selections from a diet plan, as discussed earlier with FIG. 2B2.
If a restaurant has been chosen at block 530, the routine accesses a restaurant database (532) and displays the menu for the selected restaurant (534).
A check is then made to determine whether the user has chosen a meal from the menu, or an identifiable a la carte item that is not associated with a meal from the menu (536). When a meal has been selected, the routine identifies the various items constituting the meal. In an illustrative implementation, such a meal is displayed with caloric information and with nutritional values associated with each of the meal items—including, e.g., main entrée, plus side dishes, plus any add-ons, as delineated in
If no meal or item is chosen by the user as indicated by the check at 536, the system branches back to node “A”. If a meal or item has been chosen in accordance with the check at 536, then the routine checks at 538 whether the user desires to select more items. If so, the routine branches back to the displayed menu at 534. If no more items have been selected by the user, a check is made to determine whether additional add-ons to an item have been selected (540). If the user has chosen to modify the meal add-ons, then the user is asked to specify the add-ons (542) as explained previously in conjunction with blocks 522 and 524 in the “favorite foods” processing described above.
After add-ons have been specified by the user or, if no more add-ons were selected, the routine branches to branch point “C” at block 560 and processing continues as explained above in conjunction with the favorite foods processing at blocks 560 through 575 (including return 572). It should be understood that once the user selects a meal, e.g., at a restaurant, the selection made is added to the favorites list in the manner explained above and as indicated at block 575. Thus, the selection and data entry of the identical meal (at a later point in time) is significantly simplified for the user to choose and to enter due to the ever-expanding nature of the user's open-ended list of favorite foods.
If the user selects the “user voice” icon (506), the routine prompts the user to identify the food item to be consumed and the food quantity (544). The prompt may be verbal or displayed on the mobile computing device's display screen. The user may, for example, respond “chicken breast, 4 ounces.” Upon the user articulating the food to be consumed, the routine analyzes and decodes the user's voice response (545). The routine then displays the identified food and the food quantity for user verification on, for example, the LCD display of the mobile computing device shown in
After the food and its quantity are displayed, the routine checks whether the user has confirmed that the system identified the food and quantity correctly (at 546). If the user indicates that the correct food was not displayed, the routine analyzes a 2nd and 3rd attempt to display the correct food and quantity. If the correct food is still not identified on the 3rd try (at 548), the user is prompted to type in the correct food and quantity (at 550). Prior to the 3rd try, if the correct food has not been identified, the routine branches back to node B and, once again, prompts the user to identify the food and quantity thereof at 544.
After the user types in the correct food, the system displays the food selected and its quantity at 552, where, in an illustrative implementation, the system also displays, for example, two foods that are equivalent in nutritional value to that chosen by the user. The two equivalent foods presented to the user are accessible from the Top Foods relational database schematically depicted in
A check is then made at block 554 to determine whether the displayed food is the correct food. If so, the routine proceeds to display the chosen food at block 560 and processing continues in blocks 560 through 575 (including 572) in the manner described above. If the food is still not determined to be correct as a result of the check at block 554 an unknown food flag is set (at 556) and the routine returns (at 558) to the main routine in
As shown at block 508 in
If the phone picture icon 508 is selected, a check is then made to determine whether the user has chosen a packaged meal having a barcode (574). If so, the barcode is decoded and a Barcode Database (576) is accessed to find the food and its quantity (578). The food is then displayed at block 547 and processing continues as explained above, beginning at block 546 through 575 (including 572). In an alternative implementation, instead of using a Barcode Database 576, the system may utilize, for example, prepackaged lunches and dinners, each of which is identified with a barcode that may be a two-dimensional barcode such as a QR code. A QR code may be used to store and/or otherwise identify both the food consumed, portion size, and nutritional information including calories, fat, sugar content, and any other quantity the user, a physician or nutritionist desires to monitor.
If the check at block 574 indicates that a barcode package is not involved, the routine branches to a check at block 580 to determine whether the correct food has been identified. In this mode of operation, the user's mobile computing device camera is utilized to take a picture of a meal item or items. The digital image taken is used to determine the food and quantity based on an analysis of the picture taken. In an illustrative implementation, the image processing may be utilized in conjunction with specially designed plates of a known diameter having, for example, concave portions or built-in containers of a predetermined size that provide a known portion size of a meat, vegetable, and/or other food.
The image analysis reveals certain food identifying characteristic features of the food (582) and accesses a Food Feature Database (584) that correlates a given food with a set of food features. Such features include characteristics of the outer surface of the food and may include interior cross-section features of the food. With respect to the food outer surface, the routine looks for matches in the database with respect to food shape, surface textures, striations and food colors, and then matches such data to stored data relating to characteristics of various foods. Thus, the combination of various surface textures, striations, color and shape obtained from the digital image analysis is used to identify a particular food item. For example, a precooked hamburger or hot dog may be identified and indexed in the database based upon a combination of their visual characteristics of: 1) an identifiable round shape, 2) a predetermined surface texture, and 3) typical range of colors. Food quantity assessments (in ounces) are based on various visual characteristics (586) such as size and shape. Based upon such pattern matching data, the routine displays the best match for food and food quantity after considering, for example, the best 2 or 3 matches in the database (588). In an illustrative implementation, both the best match and the next best match for the digital food image may be displayed and the user may select the correct match, via, for example, a touchscreen selection.
A check is then made at block 590 to determine whether the displayed match with the mobile computing device's camera generated digital image for food and quantity identified the correct food and quantity. If the correct food is identified processing continues at block 560 as explained above, until the routine returns to the mainline routine at block 572.
If the correct food was not identified, the routine cycles back through blocks 580 and 582 and again accesses the Feature Database (584) to display the next best match for the photo once again checking for whether the correct food was displayed (590). If, after the third try (580), a correct match has not been found, the routine branches to node B and prompts the user to verbally identify the food and quantity (544). The previously described processing cycle then continues which, as described above, may ultimately prompt the user to type in the food and quantity (550). Processing continues as described above until the routine returns at block 572 to the mainline routine of
FIGS. 4B1 and 4B2 identify and illustrate the contents of the publically-available USDA Nutrient Database that may be utilized in whole or in part to implement the system Nutrient Database 566 in
FIGS. 4B1 and 4B2 show for each identified nutrient number, the nutrient name and the number of foods in the database that contain it—e.g., for nutrient number 208, the USDA database provides the number of calories (energy) contained in 8,194 foods.
The USDA DB identified in FIGS. 4B1 and 4B2 includes nutrients that are generally self-explanatory, including most of the Macronutrients and Micronutrients delineated in FIGS. 2D1 and 2D2, respectively—however, for clarity, the common name/mnemonic for several nutrients has been added. It is also noted that the USDA DB includes total lipid (fat) information @ nutrient #204 (found in all 8,194 foods) and that, for clarity here, this “fat” category is later broken down into its constituent “Fatty Acid” subcategories, as follows:
-
- Saturated Fatty Acids (SFAs) @ #606, then non-sequentially through #654
- Mono-Unsaturated Fatty Acids (MUFAs) @ #645, then sporadically through #859
- Poly-Unsaturated Fatty Acids (PUFAs) @ #646, then sporadically through #858
- Trans Fatty Acids (TFAs) @ #605, plus #693 and #695
-
- WRT protein, the Sockeye Salmon/Turkey Breast provide 56 g/67 g, whereas the Seasoned Fries/Big Mac respectively provide only 9 g/26 g of protein
- WRT fats, the Sockeye Salmon/Turkey Breast are limited to 15 g/5 g, whereas the Seasoned Fries/Big Mac respectively provide 34 g/33 g of fat
- Far worse, WRT saturated fats, the Salmon/Turkey are limited to 2 g/1.3 g, whereas Seasoned Fries/Big Mac provide 6 g/14 g, which is the bane of the American diet
- Again worse, WRT sodium, the Salmon/Turkey have radically lower 295/219 mg, whereas Seasoned Fries/Big Mac have 842/1007 mg, another bane of today's diet
- As for hard-to-find Selenium (that is vital to activating Vitamin E as a catalyst), the Salmon/Turkey have 81/67 micrograms, in stark contrast to the negligible selenium found in Seasoned Fries/Big Mac, which have only 9/0 micrograms
Additionally,
The routine initially checks whether the user has selected the Favorite Exercises mode (at 600). If the check at 600 indicates it was selected, the routine displays the favorite exercises categories of daily, periodic, sports, conditioning, and weights (602) as previously described, for example, in conjunction with
If the user has chosen favorites, the routine accesses the Exercise Database as illustrated in
The illustrative implementations contemplate a wide range of tags that are associated with various exercises, as shown for example in
The routine next checks at 610 whether the user has selected a favorite exercise together with its associated tags. If an exercise plus tags has not been selected, then the user has decided to exit out of the favorite exercises mode and the routine branches back to node A. If the user has selected an exercise as indicated by the check at block 610, then the routine checks at 612 whether the user has elected to modify the tags associated with the exercise. For example, the user may have decided to modify the frequency, duration, cycle, or quantity associated with the selected exercise. A user may increase, for example, the reps for a bench press from 6 to 10 reps, or the weight from 100 to 150 pounds, thereby indicating a change in the “cycles” or “quantity” tag shown in
If the check at block 612 indicates the user decided to modify one or more of the tag parameters associated with the exercise, the user must next specify the new tags (at 614). If a different tag has not been entered, as indicated by the check at 612, the old exercise record remains unchanged and the routine branches to node C to display the original favorite exercise, tags and calories that will be burned upon completion of the exercise. Since no new tag has been selected, the originally-calculated calories burned and the original color code still apply to the user's chosen favorite exercise. Otherwise, if a new tag has been specified at 614, the routine proceeds to calculate calories burned (at 616). The calories burned is calculated by multiplying the user's body weight by a calorie coefficient for a given activity (at 618) as is described in detail below.
FIGS. 5B1 and 5B2 delineate an illustrative portion of an activity database based on calories per user activity for an exemplary user. The database was excerpted from the government-funded database published in the latest “Compendium of Physical Activities” by Ainsworth et al. (2011), as updated by Arizona State University in August 2012, which is hereby incorporated herein by reference. As shown in the database excerpts in FIGS. 5B1 and 5B2, the database provides an associated calorie coefficient for the exemplary user for a 30-minute timeframe across a wide range of activities. The calories burned during the identified activities are calculated by multiplying the user's body weight times the identified calorie coefficient.
The illustrative database shown provides calorie burned data for an exemplary user identified in FIG. 5B1 as a healthy, large-frame 6′3″ American male, age 25 who weighs 200 pounds. As set forth at the top of FIG. 5B1, the data shown for an exemplary 200-lb 6′3″ male may be modulated by the identified percentages (e.g., per pound, per inch, per year, etc.) to embrace a wider range of users depending upon the user's weight, height, age, and gender. Using these and similarly-patterned clusters of percentages for other weight ranges centered, for example, at 80/110/150/250/300 pounds, a stepwise-linear Activities Database has been developed for a comprehensive range of users from the “Compendium of Physical Activities” (cited above), as will be appreciated by those skilled in the art.
As shown in FIGS. 5B1 and 5B2, activities are characterized by various parameters that further qualify the activity by specifying, for example, resistance, speed, or load level associated with the activity. Examples of qualifiers for an activity of carrying a load upstairs include carrying a load of 1 to 15 pounds upstairs, carrying 16 to 24 pounds upstairs, etc. For the activity of bicycling, illustrative qualifiers are leisure cycling speeds of 5.5 mph and 9.4 mph. Similarly, qualifiers for jogging, running, walking include a range of different speeds in miles per hour which reveal a non-linear increase in calories burned as speed is increased. In this illustrative DB excerpt, various universally popular categories of activities are walking, running. swimming, biking, gym, and sports
The database shown in FIGS. 5B1 and 5B2 may be used to encourage users to step up from a minimally strenuous exercise such as walking at 2 mph to burning more calories by walking at 2.5 mph, and then 5 mph. Similar to nudging a user to step up a “Meat Ladder” from rib roast to light turkey meat (as described above) to eat additional more nutritious food with less calories, a user may be encouraged here to step up an “Exercise Ladder” by advancing through stages of walking faster from 2 to 2.5 mph, then running at 4 mph, at 6 mph, up to 7 mph, to get more aerobic exercise and burn more calories.
In illustrative implementations when a user changes an exercise tag such as those shown in
Turning back to
Thereafter, the system displays the chosen exercise together with all the associated tags as described above (at 620) including the calories burned for the given exercise activity (at 622) via call “E1” to the Calculate Calories utility subroutine (shown in
The routine then checks at 680 whether the user has actually completed the exercise or is merely contemplating performing it. If the user does not perform the chosen exercise, the routine returns to the mainline routine in
If the favorite exercises icon was not selected at block 600, the routine checks whether the “Activities” mode (624) was selected for entry of activities that occur on a daily basis (626) or on an as-needed periodic basis (628).
In an illustrative implementation, if the Activities exercise mode is selected at block 624, under a “Daily” heading, two daily icons are displayed: To/From Travel (630) and Job/School (634). Additionally, under a “Periodic” heading, two periodic icons are displayed: Indoor (638) and Outdoor (644).
If the “Daily” To/From Travel icon is selected, a user will have a choice of selecting a range of travel options including, for example, train, car, bike and walk. Thus, in this fashion, a user receives credit for calories burned, for example, while bicycling or walking to work as a daily activity. In an illustrative implementation, the user is informed not to redundantly enter walking or bicycling to and from work as both a daily activity and, for example, a conditioning exercise so as to duplicate the calories burned totals entered into the system. Alternatively, while the system registers that travel to and from work or school is done by car, only a minimal amount of calories burned is attributed to such minimal activity.
Additionally, in the example shown in
Similarly, with respect to “Periodic” activities, if the indoor icon (638) is selected, the routine displays an array of periodic home activities such as, for example, scrub/mop floors, vacuum rugs, and wash dishes. If a user selects periodic home outdoor activities, an array of periodic home outdoor activities (644) are displayed including, for example, mow/rake grass, wash/wax car, mulch/weed garden (646). Although such common activities are often dismissed as mundane, users here will get full faith and credit for their extra diligence.
If any one of the icons 630, 634, 638, and 644 are selected and the user chooses an activity displayed as a result of selecting a given icon, the user then enters tags associated with the activity, as described above, defining the time per day, for example, to the nearest half hour (648). After the tags have been entered, the routine proceeds to node B at block 616 to calculate the calories burned and completes the processing described above with respect to blocks 616 through 622 and 680 through 688.
If the user did not select the Activities icon (624), the routine next checks whether the user has selected the “Sports” icon (650). If so, the routine displays a Recreational Sports icon (652), a Competitive Individual Sports icon (654), and an Organized Team Sports icon (656).
If the user selects the Recreational Sports icon (652), an array of recreational sports options is displayed to the user (658). For example, the user may select ping-pong, golf, badminton, pool, water skiing, snow skiing, etc. If the user selected Competitive Individual Sports icon (654), an array of competitive individual sports icons are displayed including for example run, bike, swim, tennis, martial arts, gymnastics, track & field, etc. (660). If the Organized Team Sports icon (656) is selected, an array of organized team sports is displayed to the user (662). For example, as shown in block 662, the user may select basketball, baseball, football, soccer, hockey, field hockey, etc. If the user has selected any of the sports activities shown in the open-ended lists represented in block 658, 660, or 662, depending upon the sports activity chosen, the user may add a wide variety of qualifying tag information tailored to the individual activities (664). For example, as indicated by the illustrative list below, a user may specify racks (pool), rounds or holes played (golf), miles run/elapsed time, games/sets/time (tennis), events (gymnastics), quarters/time of play (football), team position (e.g., running back, QB, pitcher, goalie), etc. Additionally, in an illustrative implementation, since calories burned are modulated on user performance levels, the routine asks the user to declare his/her involvement at one of the following performance levels: training, recreational, middle school, high school, college, sports club, semi-professional, professional, etc. After a tag entry by the user (664), the routine proceeds to calculate calories for the given activity at block 616 and to complete the processing at blocks 616 through 622 and 680 through 688.
If the Sports icon was not selected as indicated by the check at block 650, the routine next checks whether the user has selected the Conditioning icon (666). If it was not selected, the routine branches back to node A at block 600.
If the Conditioning icon was selected, icons for “Noncompetitive” Conditioning (664), “Machine” Conditioning (666) and “Weight” Conditioning (668) are displayed. If the user selects the Noncompetitive Conditioning icon (664), a wide array of noncompetitive activities are displayed for user selection. For example, the user is presented with an array of open-ended lists of such exercises, including walk, run, swim, bike, hike, climb, dance, karate forms, Yoga, Pilates, Tai Chi, etc. (at 670)—plus shadow boxing, skip rope, push-ups, pull-ups, sit-ups, knee bends, jumping jacks, alternating-leg lunges, etc. (also at 670) which are vital to properly warmup before any athletic exercise, especially weightlifting.
With respect to linear-motion activities such as walking, running, biking, hiking, and even swimming (with proper waterproofing), the user may initiate a GPS-based exercise mode (64) shown in
In an illustrative implementation, after acquiring user position and/or pedometer data, the routine displays the user position together with progress data on the user's screen display. The progress data may, for example, include a wide range of data regarding the run including the distance traveled in real time, the pace of the activity, whether the pace is faster or slower than the average pace during the past week's exercise session, etc. In various implementations, the user (or a simulated “avatar” of the user) may be visually depicted traversing the path defined by the GPS data while engaged in the walking, running, or bicycling activity. In this fashion, a user may view his or her position in real-time during, for example, a walk, run, or bicycling exercise routine through the city or suburban path chosen by the user, while, for example, listening to selected music, audio books or other entertainment or educational media. In certain embodiments, the pace of the user may be monitored and a simulated “personal trainer” may prompt the user to, for example, adjust the pace (up or down) as appropriate based upon age and health-related criteria. In an illustrative implementation, the user is prompted to provide a walk, run, or bicycling activity start signal to, for example, indicate that the current exercise is a walk, run, or bicycling exercise session and to signal that the exercise session has commenced.
Additionally, in an illustrative implementation, with respect to, for example, non-competitive activities, the system determines a wide range of parameters regarding the activity including various pace-related parameters, the distance traveled since the beginning of the exercise and the length of time of the exercise. In an illustrative implementation feedback is provided to the user to, for example, indicate that the 30-minute run was faster than his/her last run, or the fastest run of the week based upon stored historical exercise data. In addition, in an illustrative implementation, information regarding the speed of the run and the calories burned during the run are displayed to the user. In certain illustrative embodiments, assuming the exercise took place after lunch, the system may, for example, display to the user the amount of calories that may be consumed at dinner to meet current goals, based upon the calories consumed at breakfast and lunch minus the calories burned during the exercise, as is conveniently tracked via the running display counter of cumulative “User Cals Today” shown in
If the user has selected the Machine Conditioning icon (666), an array of exercise machines are displayed to the user that may be selected (672). For example, the system provides the user with the ability to select treadmill, cross-country ski, stationary bike, stair stepper, elliptical, rowing machine, etc. In an illustrative implementation, if the system does not already have stored information regarding the machine being utilized, in an illustrative implementation, a user prompt is generated for the user to input the specific brand of exercise equipment being used. Additionally, if the machine generates an array of workout information, the routine may capture data from identified equipment by, for example, prompting the user to verbally indicate the data output from the equipment such as the amount of calories burned, the distance traveled, the level of difficulty or resistance, and other significant data relevant to defining and/or delimiting the machine-guided exercise. In certain illustrative implementations, the user may capture a displayed array of output data using the computing device's camera. Many machines provide a display of identified data such as calories burned, miles traveled, etc., that may be captured via a camera, via verbal user input, or via a wireless communication link with compatible exercise equipment that has been expressly designed to transmit data to, for example, smart phones.
If the user selected the Weight Conditioning icon (668), an array of weightlifting exercises are displayed to the user that may be selected (677). For example, as shown in block 677:
-
- with respect to upper body weightlift exercises, the user can select, inter alia: bench press, overhead press, incline press, dumbbell press, tricep press, tricep pressdowns, bicep curls, wrist curls, standing cable pulls, seated rowing, etc.
- With respect to lower body weightlift exercises, the user can select, inter alia: squats, weighted lunges, leg curls, leg extensions, weighted back extensions, calf press, seated leg press, incline leg press, vertical leg press, etc.
- As with the other exercise categories above, there is an open-ended list of weightlift exercises dedicated to each motion of the torso and each limb (forward/back, up/down, and CW/CCW rotation as appropriate),
- This includes exercises for both limbs (arms/hands, legs/feet) working together and independently isolated, which can be adapted to the user's unique needs (e.g., a weak limb or one with limited range of motion, as declared by the user)
- This also includes sequentially-paired exercises for opposing muscle groups (e.g., chest/upper back, stomach/lower back, biceps/triceps, quads/hamstrings, thigh subduction/abduction, forward/reverse wrist rolls, etc)
For most weightlifting exercises, there are four parallel options that each have their advantages and disadvantages, which include:
-
- Free Weight Barbells: working with a barbell provides a real two-hand (or two-leg) challenge that quickly reveals any weakness in one limb or the other—hence, a lifter gets the best advantage out of maintaining RH/LH equilibrium—however, at higher weights, presses/squats require a spotter for safety reasons
- Free Weight Dumbbells: working with one or two dumbbells provides the best mechanism to strengthen the inevitable weaker RH or LH arm/shoulder/hand—however, they only benefit the arms and can still harm a user at higher weights
- Weightlifting Machines: working with machines provides the most convenient way to emulate most free weight lifts but without the instability or the spotter—however, it is much more difficult to isolate/strengthen a weaker limb, and without the pressure of maintaining weight equilibrium, the torso gets left out
- Isolated versus Combined Lifts: since two hands are always better than one, most users can lift a barbell with much more than twice what either arm or leg can lift separately with dumbbells or machines, mostly because the torso helps
- however, over time, isolated lifts strengthen the weak side of a combined lift so that both lifts are essential to optimizing overall strength of the entire body
- Therefore, for any given weight exercise, the system offers all 4 options above, side-by-side on the user screen, wherever practical and/or possible, taking into account a 20% differential from free weight levels up to higher machine levels, using back-to-back opposing-muscle lifts to optimize available blood flow, and the user's unique needs (e.g., a weak limb and/or with limited range of motion)
After the selection of the non-competitive, machines, or weightlifting conditioning exercise, the user enters any of a wide array of tags (678). Such tags may include distance, time, sets, repetitions, etc., depending upon the activity selected. As explained above, the distance information and time information may be provided by the system when operating with the use of the computing device's GPS subsystem. Additionally, resistance levels may be entered with respect to the various machines identified. Further, with respect to weightlifting, the user may, for example, enter pounds, pulse rate, and rest interval information.
After the tags have been entered (678), the routine proceeds to node B at block 616 to calculate the calories burned and completes the processing as described above with respect to blocks 616 through 622 and 680 through 688.
Food and Exercise Recommendations—Stepping Up the Ladder
In certain illustrative implementations, it is contemplated that the system described herein will play an active role in encouraging users to eat and exercise in a healthier fashion than they have done in the past. With respect to both healthy food intake and optimum exercise routines, many individuals benefit from a highly structured system in which some of the individual's food and exercise choices are selected for them. It is contemplated that certain illustrative implementations will advantageously utilize food and exercise ladders of the type described herein to encourage users to “step up the ladder” so that they can find out for themselves the joy of eating and exercising in a healthier fashion over time.
For example, the Meat Ladder shown above illustrates how the system can make a user healthier by way of better nutrition:
This Meat Ladder chart illustrates an illustrative system strategy of boot-strapping the user at any diet level—e.g., obese RED==>healthy GREEN—up the ladder, one step at a time—from the fattening RED rib roast or ORANGE sirloin steak, up the ladder toward the ultimate GREEN light chicken or BLUE light turkey. Moreover, in illustrative implementations, there is a similar 5-color food ladder for each one of the 60 Open-Ended Lists by which the system can improve a user's diet, one step along one ladder at a time.
Similarly, the exercise ladder shown above illustrates how the system can make a user healthier by encouraging better exercise or at least some exercise:
This Walk/Run Ladder illustrates the system strategy of boot-strapping a user at any exercise level—e.g., obese RED==>healthy GREEN—up the ladder one step at a time—from the slowest RED walk time or ORANGE Walk/Jog time, up the ladder toward the GREEN fast run time or ultimate BLUE fast sprint time. This Run/Walk Ladder illustrates how the system can make a user healthier. In an illustrative implementation, there is a similar 5-color exercise ladder for each one of the 60 Open-Ended Lists by which the system improves user exercises, one step along one ladder at a time.
Regarding food intake, in an illustrative implementation, the system provides the user with a scheduled diet to consume for a prescribed time period. In an illustrative implementation, the user is provided with (e.g., by display or email) a “Grocery List” of foods to be obtained at the market, for example, for consumption during the following one week or two week time span. The grocery list is based on a projection of foods needed to create 3 meals, snacks and drinks for each day based on the user profile information including the user's favorites list and the user's selected diet plan with caloric intake projected over time.
As indicated above, in an illustrative implementation, the system operates to recommend healthier foods to a user as follows. After a user has selected a food such as “rib roast,” the system encourages the user to “step up the ladder” by selecting a healthier alternative that is next highest up the ladder of related foods such as described in the meat ladder above. In this implementation, the healthier alternative is added to the users “favorites” list in a highlighted fashion ((e.g., displayed higher up the favorites list based upon a displayed color code indicating a “healthier choice” than the red colored rib roast) with a frequency count of zero indicating that the user has not selected the food at this particular point in time.
In illustrative implementations, the grocery list for the next two weeks is based at least in part on healthier entries added to the user's favorites list to encourage the user to step up the ladder. Thus, the list of foods to purchase for the next week would be based on what was consumed the previous week but also factors in the step ladder by adding foods to purchase for the next week including some foods on the next rung up the ladder. Since many people do better during dieting when some of their choices are made for them, the system prepares a daily diet menu that the user can follow and creates a “Grocery List” so that the user will know what foods and amounts to obtain such that the daily menus can be followed. In such an approach, planned visits to restaurants may be factored into the foods needed calculations for the next two weeks.
These healthier entries may be automatically added to the grocery list based upon any of a variety of reasonable approaches. For example, the generated grocery list may be based in large part on the favorite meals recently consumed by the user as indicated by the Food Database 571 (
In certain illustrative implementations, a similar approach is also applied to exercise by having the system generate an “exercise prescription” for the user. In such an implementation, the system projects, for example, a two week user's exercise plan by identifying the exercise activities that the user should be trying to do over a future period of time. Such a projection would be based upon the user's current exercise favorites (e.g., compared to his/her original Top 5) and on the caloric expenditure requirements determined by the system based on the user's profile and goal data.
In such an implementation, the system generates a plan that the user sees over time (e.g., by display or email). A chart may be generated that defines the recommended exercise plan for a projected 2-week month, or 6-month period, as illustrated for an exemplary overweight American male in
As indicated above, the database described in conjunction with
As with the food entries, the healthier exercises may be automatically added to the exercise prescription based upon any of a variety of reasonable approaches. For example, the generated prescription may be based in large part on the favorite exercises recently performed by the user as indicated by the Exercise Database 682 (
In this fashion, the user may plan for exercise by knowing that he/she would need to set time aside, for example, four, 30 minute periods on the elliptical this week and four, 40 minute periods next week. Such an “exercise prescription” generated in light of one or more exercise ladders will change dynamically based on how well the user did during the previous timeframe.
The routine then, using speech recognition software 8, decodes the input product information and accesses the server 14 database to acquire nutritional information regarding the product and any closely-related products (85). Similarly, in a restaurant context, in one illustrative implementation, the server 14 database stores menus and nutritional information data regarding selections from the menu in the users geographical area as determined by the mobile computing units GPS subsystem. The server 14 then accesses nutritional information regarding the user's selected entree and entrées that are in the same family of food selected by the user. In one illustrative example, if the user selects a fish entrée, the system will access and display all available nutritional information regarding the selected entrée and all other fish alternatives on that menu, together with their associated color codes, to inform the user of his/her immediate options to eat the worst RED 1==>5 best GREEN choices (if any are available).
As indicated at block 86, a check is then made to determine whether the product selected is acceptable in light of the user's profile. In the present example, if the user's profile indicates that the user is a diabetic, the system proceeds to identify a more appropriate product of the same product type (87). Thus, using the example of a request for Honey Nut Cheerios, the database in server 14 is accessed and the routine determines that at least two alternative products may be better alternatives since Honey Nut Cheerios has 9 g of sugar, whereas the original Cheerios has 1 g of sugar and Multi-grain Cheerios has 6 g of sugar. For a diabetic, the routine may only identify original Cheerios as an alternative. For a user without sugar-related problems, in this illustrative example, the routine would nevertheless display the original Cheerios and multigrain Cheerios as alternatives of the same product type. In addition, in certain implementations, basic nutritional information for each alternative may be displayed. As shown in
Thereafter, the food purchasing mode routine adds the selected product/entree to the food caloric, nutritional and health related portions of the database associated with server 14, if the product/entree is acceptable for consumption by the user (88). Products/entrees which are identified as not being acceptable based on input from the physician's data processing center 20 shown in
A check is then made at block 89 to determine whether the item selected is the last item to be purchased. If so, the routine exits. If other items remain to be purchased, the routine branches back to block 84 when user is again prompted to input food product information.
In an illustrative implementation, if the user's response indicates a behavioral issue, the mobile computing device 1 generates and displays a sequence of prompts (115) to elicit a response from the user identifying the area(s) of behavioral difficulty as being in a particular category or categories, such as dietary adherence, exercise adherence and/or other issues that impact adherence (including, but are not limited to, difficulties caused by symptoms from diabetes, chemotherapy, physical disabilities, etc.).
For each category in which an adherence issue is identified (117, 119, 120), the mobile computing device 1 generates and communicates in an appropriate sequence one or more questions specific to each identified category by LCD display and/or digitally synthesized verbal message (121, 122, 123). Although not represented in the simplified flowchart, as will be appreciated by those skilled in the art, once the system determines that no further adherence issues remain to be processed, the behavioral adherence mode processing ends.
If, for example, the user identifies a dietary behavioral adherence assessment problem, the system may respond with a series of questions and prompts such as: Are you hungry? At certain times? Are you feeling tired, stress, bored? Are you going long periods of time without eating? Are you eating too much at a particular meal time? Are you snacking in between meals?
If the user identifies that he or she is having trouble adhering to an exercise regimen, the system may respond with a series of questions such as: Are you having trouble finding time for exercise? Are you getting short of breath during exercise? Are you straining muscles during exercise?
The user responds to these questions via LCD display touch screen selection and/or speech input that is analyzed by speech analysis software 8 (124, 125, 126).
The mobile computing device 1 accesses the user profile and associated database(s) to assess exercise, behavioral, nutritional and other related data (127, 128, 129). In illustrative embodiments, mobile computing device 1 then displays results to the user pertaining to behavioral issues and provides feedback regarding the identified issues with, for example, suggestions to address the identified issues (131, 133, 135). An evaluation of the user's responses may lead to any of a wide range of dietary and exercise-related behavioral recommendations such as: “Add a piece of fruit at 4 pm”, “Stay occupied with a project or activity after 8 pm”, “Eat some protein with each meal,” “Eat smaller portion meals every 3 hours,” “Stop exercising if you feel faint and see your physician,” “Slow down your run to a 11 minutes per mile pace,” “Increase your distance run by ¼ mile per day until you reach a distance of 3 miles,” or step up one or more food and/or exercise ladders as explained in detailed above, etc.
In illustrative implementation, under circumstances where a user's issue suggests that the user is not sufficiently motivated to address his or her obesity or overweight condition, a wide range of motivational information may be displayed to the user. In addition to positive reinforcement in light of prior weight loss accomplishments documented by the system, may be displayed to the user to emphasize the significant increase in risk associated with being obese and/or overweight. An illustrative risk table of the type that may be displayed is shown in
In an illustrative implementation, a generated behavioral recommendation at blocks 131, 133, and 135 includes links to behavioral web sites and to blog sites where the user is able to interact with others having similar dietary and/or health problems while trying to lose weight, maintain weight loss, successfully complete exercise regimens and combat health issues through dietary and exercising lifestyle changes.
FIGS. 7A1-7A4 are an illustrative implementation of a user database format to record weight loss for a system-derived weight progression plan adapted to each user's profile and goals. The illustrative weight loss plan database format stores user data from a “start” point when the user begins the program (689), through a series of system-programmed weight loss deltas (693), until the user reaches his/her goal (697). In an illustrative implementation, the system categorizes user's weight in a category from Obese==>to Healthy (690) at a level within that category from Min==>to Max (691) plus the color associated with his/her category from Red==>Green (692) at the start date when the user first signed up for the weight loss plan.
The user database format examples shown in FIGS. 7A2-7A4 show three typical transitions for users of the present system with color codes reflecting their cumulative progress:
FIG. 7A1: user weight loss database format
FIG. 7A2: from RED obese==>to YELLOW overweight
FIG. 7A3: from YELLOW overweight==>GREEN to healthy
FIG. 7A4: from GREEN healthy==>to BLUE RIBBON ideal weight
These 3 examples use the database format shown in FIG. 7A1 with typical exemplary data values. Accordingly, each of the database format fields are identically numbered but contain different data values pertinent to each example.
The database format shown in FIG. 7A1 additionally includes a set of “weight loss deltas” (693) that in this example are four sets of (unspecified) weeks over which the user's goal is to be reached. It should be noted that, if desired, there may be more than four such “deltas” defined in increments of time other than weeks. As shown in FIG. 7A1, each of the deltas 1-4 (694) define a number of pounds to be lost during each increment of time (695) as will be illustrated below. The weight loss delta portion of the database format also stores the color code (696) as it hopefully transitions from Red towards Green during deltas 1-4. It should be understood that the weight loss plan may be modified at any time to adjust the delta periods as well as the delta subgoals, e.g., to keep the goals achievable in response to the user's mid-stream progress (or lack thereof).
The goal portion (697) of the database format includes, for example, the user's goal weight (698), the timeframe (699) over which the goal is to be reached, the category (701) to be reached when the goal is attained, and the level reached (703) within that category when the goal is reached. Additionally, the database format specifies the reward (705) that the user is targeted to receive for reaching the goal. It should be understood that such rewards may be allotted upon the user meeting the expected goal increment at the end of each of the deltas specified in weight loss deltas (693), or alternatively that each delta subgoal reached can be rewarded with another smaller reward.
As delineated above, FIGS. 7A2-7A4 show three examples of use of the database format as applied to an exemplary user transitioning all the way from mid-range obese to his/her ideal weight. In the illustrative example, the exemplary user could be one individual transitioning from obese to ideal weight. However, it should be recognized that the example shown in FIGS. 7A2-7A4 may otherwise represent three distinct individuals. In fact, the 40-pound weight loss depicted in the first example is a notable accomplishment in and of itself.
The hypothetical user in the example is a postulated as a large-frame obese American male who is 5 foot, 9.4 inches tall and weighs 236 pounds. As shown in the first example in FIG. 7A2, the user is categorized as a mid-range plus obese person whose weight goal has been set to be 196 pounds in six months, which still is in an “overweight” category at a maximum level. As shown in the first example, the weight loss deltas (696) set intermediate weight goals of losing 13/11/9/7 pounds in 7/6/7/6 weeks, respectively. Thus, at a minimum, the system will prompt users to enter their current weight at least as of the end of each of the delta periods. During this time frame if the user achieves such weight loss, the users color code changes from red to orange to yellow as shown. In the first example, the user's goal is to lose the 40 pounds necessary to reach 196 pounds in six months and to reach the MAX edge of the “overweight” category in this timeframe. In fact, according to the CDC, the average weight for the American male as of 2010 is 196 pounds at a height of 5 feet, 9.4 inches. Thus according to this example, it would take at least six months to bring an obese 236-pound male back to the American average of 196 pounds at a height of 5′9″, which is right at the MAX edge of the “overweight” category (as shown in FIG. 13C2).
The reward (705) for attaining the goal is set to be 4 iTune song selections selected for example by analyzing the user's iTunes playlist as described further below during rewards processing. If desired a reward may be allotted at the end of the successful completion of an intermediate subgoal defined by one of the weight loss deltas (693). For example, if the hypothetical user after seven weeks lost 13 pounds and then after six more weeks lost 11 pounds, the system will automatically download a selected song performed by one of the user's favorite artists at the end of the 7th week and the 13th week, respectively.
In the second illustrated example in FIG. 7A3, transitioning from overweight to healthy, the hypothetical user's goal is to lose 20 pounds, from the starting weight of 196 pounds to an end weight of 176 pounds, within a 6-month timeframe. During the second set of weight loss deltas (693), the user is targeted to lose 6/5/5/4 pounds at the end of 7/6/7/6 week increments, respectively. If the user successfully meets these intermediate subgoals the user will transition from yellow==>to lime==>to green color code ratings and, thus, be targeted to receive a reward of 4 downloaded movies or books.
In the third illustrative example in FIG. 7A4, transitioning from healthy to ideal weight, the hypothetical user's goal is to lose 10 pounds from the starting weight of 176 pounds to an ideal weight of 166 pounds within a 3-month timeframe. During the third weight loss deltas (693), the user is targeted to lose 4/3/2/1 pound at the end of 5/3/2/2 week increments while transitioning between green==>to aqua==>to blue color code ratings. In this example, the blue-green color “aqua” is added as an incentive for highly motivated users trying to shed the last few pounds up to their ideal weight. For this latter example, in recognition of the arduous difficulty of an obese individual reaching his “ideal weight”, the system, in concert with cooperating restaurants, may reward the user with a wild salmon dinner (e.g., in certain implementations with the purchase of a 2nd entrée).
The Exercise Record in FIG. 7B1 is created for each new exercise or each old exercise with a new tag. Each exercise and food record is created on a trial basis until the exercise is performed or the food is consumed. Such is the case since the user may be considering either exercise or food to determine whether a given exercise will burn a certain number of calories or a given food/meal contains less than a certain number of calories. Field 702 in the Exercise Record identifies each exercise (e.g., bench press) with its category (weightlifting) and its mode (upper body push), as shown at 428 in
The Food Record shown in FIG. 7B2 is created for each new food or each old food with a new tag. Field 720 in the Food Record identifies each Food (e.g., Turkey Breast+gravy) with its meal (Dinner) and its dish (Poultry), as shown at 368 in
-
- Calories: a minimum 325 Calories IN (16% DV) for its portion size
- Protein: a maximum 67 g Protein (134% DV) and maximum Amino Acids e.g., all 9 essential Amino Acids @ 108%-183% of RDA for a 220-lb male
- Fats: a minimum 1.3 g of Saturated Fat (6% DV) and minimum 0.05 g Trans-Fat
- Minerals: a minimum 219 g of Sodium (9% DV) with maximum 4 mg zinc (27% DV) and 67 mmg of hard-to-find Selenium (96% DV)
- Vitamins: 26 mg of Vitamin B-3 Niacin (130% DV)
- All the above data was excerpted from the USDA Nutrient DB (see
FIG. 4B ) and was delineated in the side-by-side comparison with salmon (seeFIG. 4C )
Additionally, the food tag field includes an Add-on Calories tag 730 to define the number of calories attributable to add-ons (e.g., gravy). As explained above, in connection with the exercise record, the food record additionally includes a Usage Counter 732 to identify the number of times a user consumes the given food (e.g., Turkey Breast). A field defining other tag qualifiers 734 is provided, for example, to identify a user's food allergy. A date field 736 is provided for identifying each date the food was eaten—from the first time until the last—to provide a history of food consumption. By providing the dates each food was consumed, the system is able to identify good and bad patterns, such as the fact that the user generally eats a large steak twice a week, thereby contributing to an already problematic high cholesterol problem. In an illustrative implementation, armed with this or similar data, the system is able to recommend healthier alternatives (for example, smaller portions with lower cholesterol) to proactively address the issue in real time before further damage is done.
In order to track progress towards a user's goal on a daily basis a daily record is maintained and updated with every user's use of the system. As shown in FIG. 7B3, a Daily Record is maintained by providing cumulative daily totals of the food record's Calories IN 722 and the exercise record's Calories OUT 704, i.e, once it is confirmed that the record has advanced beyond the trial stage where the user is merely considering eating a food or doing an exercise. Once the user has confirmed eating the food or doing the exercise, the respective calories are added into the daily record's food Calories IN field 742 and the daily record's exercise Calories OUT field 744, as described above WRT the Food Mode and Exercise Mode (via Calculate Calorie calls F2 in
The Daily Record also includes an Expected Weight Loss in field 740 which the system calculates for the current day X (as defined at the top of
The baseline records in
Minimizing the Size of System Databases: to minimize the physical size of the system databases over many years of anticipated exponential growth, the record structure has been built like an “Egyptian pyramid” for each user:
-
- FIGS. 7B1/7B2: the structure is large and volatile at the base of the pyramid where one record arises from every new/unique Food and Exercise transaction; volume is minimized by incrementing a usage counter for each repeated item; and any variations in “tags” associated with the same food/exercise are merely tacked onto the variable-length original record to avoid making another record; nutrients are stored once (in mg/100 g units) and scaled up/down to portion size
- FIG. 7B3: the structure is steady and predictable in the middle of the pyramid where just one small record emerges per day for all Food/Exercise transactions; fixed disk space can be allocated yearly since the DB only grows 1 record/day; the resulting DB allows the system to display cumulative weight vs time plots
- FIG. 7B4: the structure is small and pointed at the top of the pyramid where just one record carries all the cumulative data for each successive delta; thus, only the original plus 4 delta records are generated for any given weight plan; the resulting DB allows quick display of weight vs time plots across all 4 deltas which simplifies any statistical analysis across the entire population of users
As shown in
The user ID data list 723 includes a user ID number that is assigned by the system to uniquely identify the user. Further, a revision level data item is included that identifies the number of times that the user has revised his or her user profile. The original user profile created by the user when first using the weight and exercise tracking system described herein, forms the baseline record for the user and is preserved intact.
The date and/or time the user initially begins using the system and a device number, a unique identifier identifying the user's portable computing device (such as a cell phone serial number), are also stored. The identification of, for example, a cell phone serial number permits added security features to be included in illustrative implementations. The user's email address may be acquired to serve as an alternative communication link and to, for example, communicate with the user to, for example, enabling the system to confirm that changes made to the user's profile were actually made by the authorized user.
The system also records in the user's profile, the user's name (e.g., while a name like “John” may be accepted, the system may also use a unique numeric modifier to distinguish John Smith from John Doe), sex, age, height, wrist size, and waist size. As explained herein, measurements of wrist size may be simply made by users with a string and a ruler and permits the system to identify the appropriate category for the user's body frame. The user's waist size permits the system to determine whether the user should be characterized as, for example, overweight or obese.
The exemplary list of data items 721 include an ID flag that identifies any change that is made in the user data item list so that the system may, if desired, challenge any such change. In an illustrative implementation, any time a change is made in the user profile, the data is recorded as a subsequent revision of the user's profile, e.g., Rev 2 is a revision of Rev 1.
The user ID data list 723 includes various weight related entries such as weight0, weight5, weight10 which respectively store the user's current declared weight, the user's weight five years ago and the user's weight 10 years ago. The user profile also stores the user's ideal weight by accessing the ideal weight database shown in
In certain illustrative implementations, such a user specified goal weight may be used to set the user's original goal weight. In other illustrative implementations, particularly those in which the user has selected no weight goal, the ideal weight database illustrated in
Turning back to
Similarly, a user's indicated goal of increasing endurance (goalE) may be specified in response to system queries (e.g., “Is your goal to increase endurance?”) and attained by assessing the user's top-five endurance exercises. For example, endurance may be enhanced by increasing the distance run, cycled, or swum during one or more of the user's top-five endurance exercises. A goal of getting healthier (goal H) may be specified in response to system queries (e.g., “Is your goal to get healthier?”) and may be attained by assessing the user's top-five foods/meals and, for example, by recommending alternative foods high in vitamins and health promoting nutritional parameters. Further, a goal of dropping bad habits and/or treating addictions (goal D) may be identified in response to system queries (e.g., “Is your goal to increase endurance?” and “what is your bad habit or addiction?”) which can be attained by, for example, monitoring and rewarding the user's progress with respect to not smoking, not drinking, not using drugs, food addictions, etc.
The user ID data list 723 also includes a goal date for achievement of a defined goal and may be set by the user or system. A goal flag is set upon any change in an identified goal. Thus, if the user defines a new goal weight, the system re-calculates any prior plan for goal attainment to take into account a new endpoint.
As shown in the
As illustrated in
The user health data list 724 also provides for variable length records which allow a user to define, for example, his or her handicaps. Thus, a user may, for example, indicate that he or she is confined to a wheelchair, lacks a specified limb, has limited eyesight, etc. In an illustrative implementation, for each of the specified handicaps the user is asked whether the handicap has existed for five years or 10 years to determine, inter alia, how recently the user might have eaten typical foods and/or performed typical exercises. The user health data list 724 also includes an ailment data item, wherein the system records whether the user is suffering from, for example, asthma, allergies to specific foods, etc. in the period of time over which the user has been suffering from such ailments. Moreover, the ailment data item may be used to indicate that the user is a diabetic, has high blood pressure, cardiac issues etc. The health data list 724 also includes a data item entry for injuries 1 to N to identify temporary health issues, such as a sprained ankle or a separated shoulder, which usually heals over a short time.
The user health data list 724 also includes a Weak Flag that is set for each weak limb (or associated muscle, such as a hamstring). Such a flag is set if, for example, a user identifies a weak left or right arm that cannot exercise to the same extent as its counterpart, e.g., many right-handed tennis players have weak left arms. Similarly, a Range Flag is similarly set if, for example, a user identifies a limb or (or associated muscle) that has a limited range of motion. Given such limitations, the system would not recommend exercises that involve movement beyond the limited range, or that require equal pressure, e.g., on a loaded barbell—i.e., in this case, the system would recommend isolated exercises (described above) where, for example, the weaker arm would use a lighter dumbbell.
In an illustrative implementation, the user health data list 724 also includes a data item for the user to identify a range of habits including but not limited to smoking, drinking, drug issues, food addictions etc. Additionally, a user's medications are identified that, for example, are utilized to treat any of the identified ailments and injuries. The list of medications may, for example, be analyzed by the system to determine whether such medications will present normal weight loss or tend to trigger increased weight gain. If such is the case, the system may recommend alternative medications or alter goals in light of such a medication.
The user health data list 724 also includes a data item “Restrict F” to identify foods excluded due to food allergies, ailments, or any other condition identified by the user. For example, a user who identifies a peanut allergy may identify specific peanut containing foods that should be excluded. Moreover, in an illustrative implementation, the system may access well-known sources for a list of foods that should be avoided in light of the given allergy to identify foods that may be unknown to the user that may cause issues in light of an identified allergy. Further, the user's health data list 724 includes a “Restrict E” data item that identifies specific exercises that are either limited or excluded in light of handicaps, ailments, or injuries identified by the user.
Food-related restrictions may be stored in the user's profile based upon information received directly or indirectly from a participating physician and/or nutritionist and/or healthcare provider including any thresholds for the user including but not limited to caloric intake, grams of saturated fat, grams of trans fat, milligrams of cholesterol, milligrams of sodium, grams of carbohydrate dietary fiber, grams of carbohydrate sugar, grams of protein, amounts by percent of daily requirement of Vitamin A, Vitamin C, Calcium and Iron, amount of exercise energy expenditure and other variables related to specific medical, nutritional and other needs of the user. Moreover, based upon input received directly or indirectly from a physician, restrictions that are stored in the user's profile may be placed on both food and exercise for users suffering from cardiac issues. Checks are made to ensure that any health-related nutritional and exercise thresholds have not been exceeded. Examples include excess sugar consumption by users who have diabetic or borderline diabetic issues, excess sodium in those with hypertension, excess potassium and protein in those with renal disease and exercise limitations in the user with cardiovascular disease.
In illustrative implementations, based directly or indirectly on input from a physician, food consumption and exercise thresholds may be dynamically changed in the user's profile as necessary. Exercise, for example, may increase from an expenditure of 300 calories per day, 3 times per week early in the process to 500 calories per day, 5 times per week with light weights by the end of the active weight loss process. Calories may be advanced at this point from, for example, 1200 per day to 1500 per day. In illustrative implementations, such restrictions may be identified in the user's profile in the variable length food and exercise restriction segment thereof. As another example of dynamic regimen changing, if a behavioral issue exists such that the user is not doing well adhering to the initially prescribed dietary regimen, an assessment of the issues contributing to the adherence problem can be made and the dietary regimen might be changed based upon an analysis in conjunction with the
In an illustrative implementation, the same storage format and sequencing is used for recording the user's Top 5 favorite foods/meals is also used for recording everyday food consumed by a user at, for example, a restaurant via the Food Mode process of
As illustrated in
In addition to the amount of calories, macronutrients, and micronutrients, the system associates color codes with the user's profile that may be stored in a linked shadow database. As illustrated in
The color codes assigned to each of the foods/add-ons and macro-/micro-nutrients are mapped (as numbers 1==>5) into a “shadow” DB correlated 1-for-1 with this DB. The shadow DB provides instantaneous access to associated color codes, since each code is the exact same relative displacement within that DB as its parent data item in the above
While most of the data items referenced in
-
- all food/exercise data with wide-ranging values are variable-length open-ended lists, rather than fixed choices
- all individual text fields are also variable-length, rather than widened them out to the maximum text value
- all but the 1st DB segment are variable-length, e.g., adding up to 5 Favorites per each category
- for quick “burst-energy” exercises like sprints and weightlifting, the record is extended by modular data for 1==>N Trials/Sets (see the cyclical format)
The following is an exemplary sequence of DB segments with their respective variable lengths, if any:
As indicated in
In an illustrative implementation, in completing his or her user profile, the user is prompted to select a category of favorites such as B or L or D, and then select any desired add-ons (739) and quantities (740). Thus, if for example the user chooses the category lunch (738), the user may select beef, chicken, fish, or a vegetable (733) together with desired add-ons (739) and then add any desired dishes from rows 732, 734. The user may next select a similar set of Top 5 snacks and/or drinks indicated in row 735. Once the user selects a particular category such as drinks, a user will be presented with popular examples such as coffee and cream as shown in the food database of
Furthermore, in an illustrative implementation, the system next prompts the user to enter his/her favorite vitamins/minerals/omega-3s/antioxidants/herbs/etc. which are stored as an open-ended list for each category, such as is shown in
In an illustrative implementation, the same storage format and sequencing is used for recording the user's Top 5 favorite exercises/activities is also used for recording everyday exercise performed by a user at, for example, at home or at a gym via the Exercise Mode process of
The entries in the user profile/exercise record format 760 are provided by the user except for the Cals OUT that are calculated by the system.
As can be seen from
With respect to the categories 748 to 753, the data entry cycle repeats up to five times for each of the Daily, Periodic, Sports, Conditioning, and Weights exercises. As shown in
Periodic activities 749, as described above in conjunction with FIGS. 3D and 5A, include various indoor and outdoor activities that may be performed either at home or away from home. Indoor activities include, for example, vacuuming, washing floors, and playing pool. Outdoor activities include, for example, washing a car, mowing the lawn, etc.
In an illustrative implementation, all competitive and noncompetitive sports are grouped together in a Sports category 750. where each team sport is further qualified by the user's position on a team such as goalie, pitcher, quarterback, guard etc. This is because the position on a team may significantly impact the calories burned during participation in sport. For example, an outfielder in baseball burns significantly less calories than the team's pitcher. Furthermore, each sport is qualified by the user's level of competition, which in turn will trigger changes in the Cals OUT calculation. For example, a professional soccer player will inevitably burn more calories playing soccer than a middle school player. Such levels of competition include, for example, training only, recreational, middle school, high school, college, club sport, semi-professional and professional. Cycle information is also recorded, if pertinent to the sport at issue focusing on, for example, goals, sets, planned attempts/trials, and or number of actual repetitions completed. For example, a 260-lb weightlifter tries to bench press 200 lbs for 3 sets of 5 reps—he manages to complete the first 2 sets without a problem but, as lactic acid builds up, he fails on the 4th rep of the 3rd set. Using the cyclic “Multiple Sets” provision of the Exercise DB here, this would end up as a parent Bench Press record with set tags ½ showing Pass and tag 3 showing Fail.
With respect to conditioning activities 751, a wide range of activities summarized in conjunction with
The Exercise Mode routine in
The multiple trials/sets entry 753 permits the system to handle “burst-energy” exercises below ½-hour to extend the tracking system across the entire sports spectrum, i.e.: from slow “low-energy” exercises greater than 30 minutes==>to “quick-burst” acts of less than 30 seconds. This format for repetitive “sets” of a given lift may be applied to ALL likewise-repetitive “trials” for increasing Track & Field “goals” in the sports record 750:
e.g., short races/sprints/shotputs/throws/vaults==>for a single BEST/MAX goal e.g., pole vaults/high jumps/long jumps==>for an increasing-level BEST/MAX goal. That is, for such a given track and field event, the goal is to reach a MAX height/distance in the trials allowed.
In an illustrative implementation, the tracking of weightlifting may be expanded from exercise record 752 via the use of the multiple trials/sets entry 753 (see the dynamic Multiple Sets just described in example above). If, as in the earlier example, the user completed the 5th repetition of bench pressing 200 lbs, the user will be credited with passing the trial. Additionally, in an illustrative implementation the user's target pulse range based upon age limitations is identified together with the pulse rate achieved during the exercise. Rest interval information between repetitions is also identified. Such information is recorded for each of multiple trials and sets. The system may then recommend to the user, the parameters of the next set based on the user's performance of the just completed set. Thus, such timely interactive information allows the system to dynamically recommend increasing/decreasing the amount of weight being bench pressed, decreasing the rest interval, increasing/decreasing the number of repetitions etc.
In this fashion, in an illustrative implementation, such a weightlifting training protocol permits the system to act as a “personal trainer,” interactively guiding the user through a rigorous weightlifting workout in real time. In an illustrative implementation, through the use of databases stored locally in for example, a 64 GB local cell phone memory, such personal trainer functionality may be accomplished off-line without any internet link to the remote server.
The inherent advantages of this efficient, dynamic DB format are:
ALL exercises can be tracked . . . from longest/slowest==>to shortest/fastest
the DB's compact size allows, in an illustrative implementation, the whole DB to be locally stored in the user's smartphone
this enables the user to access/update the DB in real-time, without being online with a server enabling full functionality inside a gym or other location where there's often no signal
the system provides real-time feedback to the user, e.g., based on the results of previous N−1 set (pass/fail, rest interval, pulse rate, etc), the system can adjust optimal weight/reps for sets N/N+1/etc so as not to “kill” user enthusiasm.
Beginning with the F1 subroutine, this subroutine is executed to perform the functions shown in
Thereafter, as indicated at block 776, the calories contained in the food and add-on are calculated to factor in the quantity of food and convert to the unit of measure being tracked by the system based upon the data been entered by the user (e.g., 8, 10, 12 ounces). Such a calculation is necessary to scale the user's portion up/down to match the unit measure of the USDA database calorie data which is in milligrams per 100 grams (mg/100 g). Once the food and add-on calories are each calculated, the associated values are stored in a trial food record (778). The data is not permanently entered into the system until it is confirmed that the user is past the consideration stage and has consumed the food. The food being consumed together with all nutrients, such as grams of proteins, are displayed to the user (780), and the calories consumed are also displayed (782). Thereafter, the routine returns to block 568 of
As previously described in conjunction with
Thereafter, the food calories in (i.e., consumed) are added to both the daily record and the Delta record (796) shown in FIGS. 7B3/7B4, respectively. The calories are then displayed (798) and the routine returns to the calling routine in
Turning next to the Exercise1 subroutine (E1), this utility subroutine is called during the processing previously described in
Thereafter, the calories burned during exercise are calculated using the calorie coefficient obtained from the database illustrated in
Update favorite processing (684) calls the Exercise2 subroutine (E2). Upon the initiation of E2 (816), the routine accesses the exercise record shown in
The display in
The display shown in
In this example, with respect to the “actual values” for user weight (868), the user's starting weight is again identified at (870) for comparison with his/her actual current weight displayed at (872). In this fashion, a user can see his/her actual current weight and compare the actual calculated weight with the current expected weight for goal achievement at block 854. In an illustrative implementation, this display may be augmented with the color codes associated with the user's weight loss progress to date, visually depicting the degree of progress. Additionally, under the “user cals to date” heading (874), the actual total number of calories consumed (876) and the total calories burned (878) during the delta period to date are identified for comparison with the calculated calories IN and calories OUT for goal achievement.
In an illustrative implementation, this display may be augmented with the color codes associated with the user's progress to date regarding calories consumed and burned, visually depicting the degree of progress. Finally, under the “user calls today” heading, the actual calories consumed (882) and the total calories burned (884) during the current day are displayed for comparison with the calculated calories IN and calories OUT for goal achievement for the current day. In an illustrative implementation, this display may be augmented with the color codes associated with the user's performance during the current day regarding calories consumed and burned, visually depicting the performance.
A check is initially made at block 202 to determine whether any new food record has been generated. If so, then a check is made at block 204 to determine whether the food consumed by the user had an associated color code other than Green (where the value 5 indicates the healthiest food color coded Green as explained above). If any food in a meal being consumed is other than the healthiest food (as indicated by Green), the previously described “stepping up the ladder” processing is initiated. Thus, as indicated at block 206, the system recommends food(s) at the next higher color code value to encourage the user to eat in a more healthy fashion. After recommending an alternative food to the user, the food recommendation is stored in a shadow database location associated with the food record (208). Thereafter, a daily food flag is set and the daily record shown in FIG. 7B3 is updated. The daily food flag indicates that a food record was constructed on the current day. Additionally, the cumulative “Cals IN” entry in the daily record shown in FIG. 7B3 is updated (210).
After the processing at block 210, or if the check for a new food record indicates that there is no new food record to process, a check is made at block 212 to determine whether there is a new exercise record to process. If so, a check is made at block 214 to determine whether any associated exercise was performed that has an associated color code other than Green (and therefore has an associated value less than 5). If any exercise is performed other than the healthiest rated exercise for the user (as indicated by the “Green” color code value 5), as indicated at block 216, the previously described “stepping up the ladder” exercise processing is performed. Thus, if a new exercise record indicates that the user ran 2 miles in 30 minutes that might be classified as a “Red” color code, the user will be, for example, encouraged to run at a somewhat faster pace to reach a pace that would be classified using an “Orange” color code instead of the original Red color code. Thus, as indicated at block 216, the system recommends one or more exercises at the next higher color code value to encourage the user to exercise in a healthier fashion.
After recommending an alternative exercise to the user, the exercise recommendation is stored in a shadow database location associated with the exercise record (218). Thereafter, a daily exercise flag is set and the daily record shown in FIG. 7B3 is updated. The daily exercise flag indicates that an exercise record was conducted on the current day. Additionally, the cumulative “Cals OUT” entry in the daily record shown in FIG. 7B3 is updated (220).
After the processing at block 220, or if the check for a new exercise record indicates that there is no new exercise record to process, a check is made at block 222 to determine whether any of the user's restrictions have been violated. The user's profile record format 720 is monitored to, for example, check the foods excluded in light of the data item RestrictF stored in the user health data list 724 shown in
In illustrative implementations, it is contemplated that this warning system can be used to warn the user about a wide range of health related issues. For example, the system can warn an unwary user that a food contemplated for consumption includes a peanut-based oil to which the user is allergic. Similarly, a user may be warned that a food to be consumed includes a sufficient amount of sugar to raise a concern in light of the user's indicated issue with diabetes. Moreover, a user may be warned if a food or exercise record indicates consumption of a food or participation in exercise that does not comport with the user profile's designation of handicaps, ailments, injuries, habits, or medications. A warning may be generated, for example, if a food or beverage (such as alcohol) to be consumed is not appropriate in light of medications taken. In illustrative implementations, such restriction information may be based on input received from the user, or from other sources in implementations in which, for example, a physician, nutritionist, or other third party is actively participating to provide professional input. In certain illustrative implementations, based, for example, on input from a physician, food consumption thresholds, exercise thresholds and behavioral parameters may be either maintained or dynamically changed as needed. Exercise, for example, may increase from an expenditure of 300 calories per day 3 times per week early in the process to 500 calories per day, 5 times per week with light weights by the end of a certain active weight loss process interval. Calories may be advanced at this point from, for example, 1200 per day to 1500 per day. In another example, if a behavioral issue exists such that the user is not doing well adhering to the initially prescribed dietary regimen, an assessment of the issues contributing to the adherence problem can be made and the dietary regimen might be changed for example by increasing calories or adding more fruit to help the user improve adherence.
In such implementations where a physician, nutritionist or other third party is providing input (either directly or indirectly through the user), the routine accesses the user's profile to assess health-related information received directly or indirectly from a participating physician and/or nutritionist and/or healthcare provider including any generated thresholds for the user including but not limited to caloric intake, grams of saturated fat, grams of trans fat, milligrams of cholesterol, milligrams of sodium, grams of carbohydrate dietary fiber, grams of carbohydrate sugar, grams of protein, amounts by percent of daily requirement of Vitamin A, Vitamin C, Calcium and Iron, amount of exercise energy expenditure and other variables related to specific medical, nutritional and other needs of the user. For example, a physician may place both food and exercise restrictions on users suffering from cardiac issues. Checks are made to ensure that any health-related nutritional and exercise thresholds have not been exceeded. Examples include excess sugar consumption by users who have diabetic or borderline diabetic issues, excess sodium in those with hypertension, excess potassium and protein in those with renal disease and exercise limitations in the user with cardiovascular disease.
In an illustrative implementation, such restrictions received either directly or indirectly from a physician may result in a goal weight modification recommended by the system to either increase the amount of weight that should be lost, or slow down the rate at which weight should be lost to decrease stress on the user.
Turning back to
After the processing at block 226 of the restriction-related content of
If a user has entered a new weight, the newly entered weight is stored in a record associated with the user's profile shown in
After the delta record has been updated, the system displays either a weight loss or weight gain across the current delta time frame (238). In an illustrative implementation, such a display includes two curves of expected weight over the “delta” time period (the user's weight expectation based on goals that have been set) and calculated weight over the delta time period (the user's weight based on calories burned less calories consumed), and the user's actual reported weight over this time frame so that the user can see his or her progress over time and assess the accuracy of the user's reported calories consumed and calories burned. Additionally, in an illustrative embodiment, an overlay is created to display daily food, exercise, and weight flags so that the user can see, for example, the regularity with which food and exercise entries have been made. In an illustrative implementation, if there are major gaps in the exercise flag entries, the system generates a display encouraging the user to exercise more often.
If the check at block 228 indicates that a no new weight has been entered by the user, then a check is made at block 234 to determine whether the current day is a new day. If the current day is a new day, then the updating and display processing at blocks 236 and 238 is performed. The completion of processing after block 238 completes the updating of the baseline records shown in
After the processing at blocks 236 and 238, or if the check at block 234 indicates that the current day is not a new day, the display calories and goals illustrated in
After the calorie and goal related display has been generated a check is made at block 242 to determine whether the current day is the last day of a delta period that is used for goal assessment.
If the current day is the last day of the delta period, then the baseline record shown in FIG. 7A1 is updated to record the delta weight loss achievement (244). Additionally, a display is generated to show the weight loss or weight gain across all the deltas relating to the user's goal (245). In an illustrative implementation, such a display includes, for example, expected, calculated, and actual weight across time and an overlay showing each day that food, exercise, and weight has been entered by the user over the delta time period. A display that shows, for example, sparse exercise entries may serve to explain to the user why his/her current goal has not been met.
A check is then made at block 246 to determine whether a user's goal has been met. It should be recognized that the system may require, for example, 100% achievement of a goal weight loss before a reward is targeted for downloading to user. However, in this example, a reward trigger signal is generated if the user achieved 95% of the assigned goal for any delta period based on the check at block 246. Thus, the check at block 246 may be used to determine whether the user's overall weight loss goal has been met or whether an interim “subgoal” has been met to indicate whether or not the user is on track to reaching his or her overall goal.
The specific percentage assigned as the proper “reward” percentage may vary based on many factors including the user's past weight loss history, how close or how far the user is from his or her ideal weight, the user's overall general health, and other factors targeted to providing the individual user with the optimum amount of effective motivation and encouragement.
If the check at block 246 indicates that the required percentage of the user's goal has been met, the routine generates a goal has been met signal and transmits such a signal together with goal achievement data to the reward processing routine (241) illustrated in
If the check at block 246 reveals that the user has achieved, for example, less than 95% of the assigned “delta” subgoal, processing is initiated to determine whether there is a need, for example, to change the final goal or current subgoal that is lower than the originally set goal depending on various factors, including the degree to which the goal has been missed and whether the initially assigned goal or subgoal is appropriate for the user given the user's food consumption and exercise performance history.
Daily caloric goals with their associated nutritional requirements may require modification at various points during the weight loss process. These adjustments may be made as a function of the weight loss progress (or lack of progress) as determined by the check at block 246. Alternatively, goals may need to be changed to address issues associated with recently developed medical conditions, such as diabetes or hypertension. Exercise goals may need to be changed as the process progresses. Typically, the amount of daily exercise will need to increase as weight comes down or specific alterations in type and duration of exercise will be needed based on the progress (or lack of progress) of the user. The specific goals of exercise may change throughout the process from predominantly aerobic, calorie burning exercise at the beginning of the weight loss endeavor to an exercise regimen that includes more muscle building activity and less aerobic activity as a user approaches his/her weight goal and transitions into a weight maintenance mode. New goals are displayed to the user on the user's mobile computing device display as indicated at block 249. Food or exercise related warnings are displayed to the user (e.g., as indicated at block 224).
In an illustrative implementation, the existing goal may be lowered by a desired increment, for example, 5% or 10% (247). In an illustrative implementation, such processing includes prompting the user to indicate if any new unreported injuries, ailments, or handicaps have arisen that contributed to the failure to meet a goal or subgoal. If so, the user is prompted to modify his or her user profile to result in a modified new goal. Such new user profile data may in turn create new food consumption and exercise related thresholds that may serve as new restrictions recorded in the user's profile.
Thereafter, the subgoal values for the delta periods shown in FIG. 7A1 are recalculated and modified to reflect the new goal weight loss and/or new goal anticipated achievement date (248). Thereafter, a new baseline record as illustrated in FIG. 7A1 is displayed with the modified, recalculated delta values and goals (249) and the routine branches back to the calling routine (243).
In illustrative implementations, after the goal analysis has been completed (during the processing at blocks 241, 246, 247-249), the routine generates feedback to the user regarding whether goals have been met, and provides recommended adjustments that may need to be made with respect to food consumption or exercise completion, and/or any warnings regarding exceeding physician's/healthcare provider's set thresholds for such health-related parameters as sugar intake, daily calorie intake, etc. Behavioral recommendations are also generated as needed taking into consideration caloric, nutritional, exercise and other parameters. In an illustrative implementation, for those who are grossly overweight or those who are attempting to stop smoking, congratulatory progress statements are forwarded with regularity as daily goals are met.
As noted above,
As shown in
The elbow size measurement involves the following steps:
-
- Start in a standing position:
- Hold out your arm so that it's horizontal and parallel to the floor
- Make sure that your palm is facing upward
- Then bend your elbow so your forearm is at ninety degrees to the floor
- Use your index finger and thumb of opposite hand to find the narrow part of your elbow joint
- Use your finger and thumb like a gauge to find the breadth of your elbow
- Do this by measuring the gap in between them with a ruler or measuring tape.
-
- the RH severe overweight slice==>matches the LH “Action” slice
- the RH overweight slice==>matches the LH “Take Care” slice
- the RH healthy weight slice==>matches the LH dark “OK” slice
- the RH underweight slice==>matches the left-most “Take Care” slice
- the RH height runs 4′10″-6′6″==>the LH height runs 4′5″-6′7″
- the RH weight runs 50-250 lbs==>the LH waist size runs 18—50″
In the USDA Chart generated in 1995, BMI has been utilized to determine the line between obesity and healthy weight. However, using BMI as the determining factor belies the significance of the underlying BMI equation (weight/height2×703) and the fact it ignores the huge weight-per-height gap between Men and Women that was prominently declared for 50 years by its predecessor, the Met Life Table. In fact, the oversimplified BMI calculation itself (weight/height2×703) is fatally flawed in that it does not require any measurement of actual body fat, but rather, wrongly assumes any excess weight above average for a given height is due to fat rather than muscle.
Given that the general definition of obese (for the Met Life table) is someone whose weight is 20% more than their ideal weight, this basic BMI flaw alone inflates the obesity rate of most countries by adding virtually every muscular athlete with <20% body fat to its obesity group—men and women who are by definition among the healthiest specimens on the planet—a factor that is partially accounted for by Met Life's wise expansion into body frames and frame overlaps.
This separation of the Men's profile (by 18 pounds upstream) from the Women's profile appears to confirm that the ultra-low healthy weight slice of the USDA Chart is entirely demarcated for Women, and as such is generally beyond the reach of Men. It is noted that the Chart and Table profiles for Women intersect at 5′9.″
-
- Bottom Half (4′10″==>5′9″) The time-honored independent Met Life profiles for both Women and Men were adopted exactly as shown in
FIG. 13A . This new weight regime resolves the worst differences and complaints at both extremes:
- Bottom Half (4′10″==>5′9″) The time-honored independent Met Life profiles for both Women and Men were adopted exactly as shown in
Leading Edge: Studies reveal that Japanese Women still falls within the profile, but now correctly at the leading edge—i.e., the Chart values are so severe at the low end that no one in the world (but Japanese women) can achieve them
-
- the same holds true for Japanese Men who are now correctly positioned right at the leading edge among all men (with the world-lowest 3.2% obesity)
Trailing Edge: Studies reveal that Italian Men/Women correctly shifted to the center of their respective healthy weight slices (at a very low 8.5% obesity)
-
- similarly, the German Men/Women are correctly shifted just inside their respective healthy weight slices (at a reasonable 12.9% obesity)
- the Canadian Men/Women are correctly remained just inside the new, more narrow moderate weight slice (at weighted-average 14.3% obesity)
- the American Men/Women remained unmoved from their precarious perch just inside the severe weight slice (at world-worst 33.9% obesity)
- Top Half (5′9″==>6′6″) This half was adopted from the more modern USDA Chart profile for Women, while the wholly independent Met Life profile for Men was adapted to the more relaxed slope of the Chart, exactly as shown in
FIG. 13A . This weight regime will resolve the worst differences/complaints at both extremes: - Leading Edge: the worst-case extreme here is the Men's MIN up at 6′6″ (small frame) where, according to the Chart, a 6′6″ male is still healthy at 165 lbs
- But this weight is not achievable even by tall Dutchmen (at low 10% obesity) who are already up to 195 lbs @ 6′1″ (world's tallest avg height), whereas the Dutch women reach 165 lbs @ 5′8″ (avg), but they're 10 inches shorter than 6′6″
- Thus, the Men's MIN becomes more realistic shifted up by 13 lbs to 178 lbs
- Trailing Edge: Only the German Men at 5′10″ were affected here by the 6° CW rotation (around the pivot point at 5′9″)—the GM is now correctly shifted just inside the trailing edge, which exactly matches the position of GW
The upper-level weights are now achievable by tall men. This has been the most contentious area in the Met Life Tables—namely, they do not account for men taller than their 1942 model that are heavier but still healthy e.g., the 1983 Met Life table sets a healthy large-frame 6′1″ US male @ 192 lbs whereas, with the upgraded profile, he can now aim at more achievable 200 lbs.
In fact, the Dutch Men and Dutch Women (cited above) actually confirm the validity of both new profiles for Men/Women since, at their very low obesity rate (10%) they clearly qualify to appear in the Healthy Weight slice of the USDA Chart. This can be easily visualized by comparing where they map into the new profiles (overlaid on
By embracing this extreme—the tallest healthy Men/Women in the world—this case in point confirms another significant way the newly-configured profiles for Men and Women have improved over the USDA Chart and Met Life Table. Moreover, this upgrade for taller men becomes all the more significant in light of the spiraling growth of sports, from recreational to competitive, worldwide—and the parallel explosion of fit athletes who play the sports, but are rated obese.
Unique Database (DB) to Calculate Ideal Weight Vs. Height
In accordance with an illustrative implementation, a user's weight goal may be selected based upon the ideal weight database shown in FIG. 13C1. In an illustrative implementation, the system may select a weight goal for the user based upon the FIG. 13C1 ideal weight database described below using user profile entries of height, weight, gender, and frame size (taking into account waist and wrist size (see
In determining a user's goal weight, FIG. 13C1 depicts in a table format an illustrative new and improved system database relating a user's height to a healthy “ideal” weight for a range of small, medium, and large frame minimum and maximum weight values for both men and women. The illustrative weight, nutrition, and exercise tracking system that is dedicated to helping today's users get healthier and/or lose weight presents a unique answer to the age-old question . . . exactly what is an “ideal” weight for a given user height? The database shown in FIG. 13C1 takes into account various generic factors that may affect the user's weight, such as gender, body frame (small/medium/large) and relative level of obesity. In an illustrative implementation, the database is advantageously designed to assist in calculating small increments of weight loss that can eventually lead an overweight user to a goal within his or her reach. The database shown in FIG. 13C1 is accessed in part by using wrist size to differentiate body frame and waist size to differentiate obesity level.
This new database has been derived by selectively reconciling and integrating the most historically reliable sources of height vs. weight data still in widespread use today:
-
- Metropolitan Life Table (Met Life table), from their 1942 life expectancy data (updated 1983)
But, this aging data falls short of today's taller, heavier bodies that are still healthy - USDA CNPP center Chart, from their 1995 obesity data (and Met Life Table).
- Metropolitan Life Table (Met Life table), from their 1942 life expectancy data (updated 1983)
The Met Life table has become a standard that is still widely used for determining recommended body weights. This table has been criticized for varied reasons:
Insured people tend to be healthier than uninsured people
The people included were predominantly white and middle-class
Frame size was not consistently measured
Some people were actually weighed, some were not
The table did not consider percentage of body fat or distribution
The table is considered okay for people in their forties, but the weights are too heavy for younger people and too light for older people.
Yet despite all these caveats, the table has continued to serve as a worldwide standard together with updated versions of this table.
The database of FIG. 13C1 has been designed to take into account such criticisms of the Met Life table and to accommodate taller, healthy men and women, in that the Table has been extended up to 6′2″ for women and up to 6′6″ (and down to 4′10″) for men by interpolation. Further, the present DB has been designed to classify large/small-bone people in their correct frame size, which becomes important in taking into account the differences between men and women. Thus, the ideal weight database has been customized by the melding of Met Life tables, demographic data, frame size, body mass index, etc. While this approach has not been clinically proven or tested, it is presented as an illustrative implementation of a highly useful tool in determining a user's ideal weight that is tailored to individual users in a unique manner.
FIG. 13C1 ties together the above Tables/Charts into a single 2012 DB that integrates MIN/MAX frames (scaled up from 1983 Met Life Table) within MIN healthy/moderate edges (rotated/shifted from 1995 USDA Chart) that allows the system to provide an ideal weight (nearest lb) matched precisely to a user's exact height (nearest ¼″) for both Men (left side) and Women (right side). This Table reflects Ideal Weight per Body Frame according to Met Life data (updated 1983), with new MIN boundaries per
Unless separated by their naturally higher weights, men have been improperly lumped into impossible for many to reach lower weight profiles for women. The 2012 updates include reconfigured “healthy weight” slices, now separated for men and women, as redefined in the compare columns in
In effect, the Chart of
In effect, Chart 13B/Table 13C1 tie together data:
-
- For 5 Major Countries:
Ideal Weight vs. Height in the spectrum of Obese==>Healthy
-
- For individual Men/Women:
- As shown in the table, the 2012 Database Table 13C1 comprises modified primary data values
FIG. 13C2 is a chart showing boundary equations that may be used to identify the ideal weight for men and women shown in
In the example shown in
If an identified user's goal has been met, the routine determines the extent to which the goal has been exceeded (254). Such a determination may be made in an illustrative implementation based on data transmitted from server 14 regarding the user's goal achievement.
It should be understood that a reward may be embodied in a wide variety of forms. It is contemplated, without limitation, that, for example, rewards may be in the form of downloaded music, movies, digital versions of TV shows, music videos, cash, discounts at movies, restaurants (particularly those that include a wide range of healthy alternatives), discounts at sporting events, mobile games, mobile gaming currency, other mobile applications, etc.
In an illustrative implementation, a reward is selected based upon the extent to which a goal being exceeded (256). Thus if a user exceeds weight loss goals in a given month by, for example, 20 pounds or has stopped smoking for a predetermined extended, time period, the user may receive a movie as a reward as opposed to receiving downloaded music. In order to provide adequate motivation for users, it is desirable to provide rewards as soon as it is determined that a goal has been exceeded. For example, in an illustrative implementation, if a user exceeds a daily food consumption, smoking cessation, or exercise goal, the system may reward such performance, by automatically downloading music of the type to which the user has shown an inclination to listen.
In accordance with an illustrative implementation, the system accesses one or more of the user's playlists (258). For example, users of the iPhone often utilize the iTunes application to download music of their choice. Accessing of the playlist associated with the user's use of iTunes will reveal a great deal of information regarding the user's listening and viewing preferences. For example, by accessing such a playlist or the like, it may be determined that the user has a particular preference for ‘90’s music, classical music, music videos together with the particular selections within those and other categories. Moreover, it may be determined which selections are the user's top-rated, recently added, top 25 and most recently played selections. Further, the user's preferences with respect to movies, TV shows and other entertainment preferences may be determined.
Based upon an analysis of such data from iTunes, the routine may select a particular song which is likely to be appreciated by the user since, for example, it is performed by an artist who has been identified in the playlist as the performer of one of the user's top-rated songs (260). In this example, such a song may be downloaded upon the user meeting a daily goal. In other implementations, the routine may select up to three songs for the user to choose from; a similar approach may be used for TV shows, movies, or other reward options. If, for example, a user meets a weekly or monthly goal, a selected TV show or movie may be downloaded to the user as a reward. Alternatively, one of the other above identified wide range of rewards, such as a discount coupon to an entertainment or sporting event may be downloaded.
If for example, a song has been selected for downloading, the routine may interact with the iTunes store to trigger downloading such a song to the user to provide the user's reward for goal achievement (262). Thereafter, the routine returns to the mainline routine of
While the invention has been described in connection with what is presently considered to be the most practical and preferred embodiment, it is to be understood that the invention is not to be limited to the disclosed embodiments, but on the contrary, is intended to cover various modifications and equivalent arrangements included within the spirit and scope of the submitted claims.
Claims
1. A hand-held mobile weight and exercise management computing device having a housing sized to be held in a user's hand comprising:
- a storage subsystem for storing health information including a user profile, said storage subsystem being operable to store health information about a user, including body weight, pulse rate information, at least one food-related goal including a calorie-related daily goal, and an exercise-related goal; said storage subsystem being further operable to store data relating to a plurality of user-selectable foods and to store data relating to a plurality of user-selectable exercises;
- a touch screen display operable to display food-related and exercise-related information to said user;
- a user interface operable to receive input from said user and to communicate output to said user, said user interface including a plurality of user interface displays displayable on said touch screen display; said user interface being operable to selectively initiate entry into said user profile or at least one food-related operation or at least one exercise-related operation, said user interface including a plurality of user-selectable symbols; said user-selectable symbols being operable to initiate entry into said user profile or at least one food-related operation or at least one exercise-related operation;
- a GPS receiver in said housing operable to receive input GPS data;
- a pedometer in said housing operable to generate step-related data;
- said user interface being operable to display on said touch screen display in said housing: a food mode symbol, a first exercise mode symbol for initiating an exercise mode that uses position coordinate information based upon said input GPS data, and a second exercise mode symbol for entry of data regarding a plurality of exercise modes that do not use position coordinate information based upon said input GPS data;
- a processing subsystem, operatively coupled to said user interface, said GPS receiver, said pedometer, said touch screen display, and said storage subsystem, said processing subsystem including: a food monitoring subsystem being operatively coupled to said storage subsystem and being operable to receive food-related data from said user, via said user interface, including data identifying a first set of foods input by said user, and being operable to link said first set of foods to a specific user meal, said first set of foods including a first food and a quantity-related parameter identified by said user; said food monitoring subsystem being operable to determine the calories expected to be consumed by said user upon eating said first food, and to store food-related information in said storage subsystem relating to said first food, including information relating to the nutritional content of said first food and the calories consumed by said user upon eating said first food, based in part on said food-related data from said user; said food monitoring subsystem, in response to user selection of said food mode symbol, being further operable to generate a food selection display screen identifying a plurality of meal category symbols that allow the user to select a meal category including a breakfast category symbol, a lunch category symbol, and a dinner category symbol; said food monitoring subsystem being further operable to generate a list of said user's favorite foods in response to food-related inputs by said user during food selection for said specific user meal; and an exercise monitoring subsystem being operatively coupled to said storage subsystem and, in response to user selection of said first exercise mode symbol or said second exercise mode symbol, being operable to receive exercise-related data from said user, via said user interface, including data identifying a first exercise expected to be performed by said user; said exercise monitoring subsystem being operable to determine the calories expected to be burned by said user upon performing said first exercise, and to store exercise-related information in said storage subsystem relating to said first exercise, including the calories burned by said user and an exercise quantity-related parameter upon said user performing said first exercise, based in part on data from said user; said exercise monitoring subsystem being further operable to analyze data related to user performance of at least one exercise, and to generate exercise feedback for said user relating to said at least one exercise; said exercise monitoring subsystem, in response to user selection of said first exercise mode symbol, being further operable to receive exercise data including user location data via signals received from said GPS receiver, to determine user distance traveled using location data from said GPS receiver, and to track user distance traveled and duration traveled;
- said exercise monitoring subsystem being further operable to associate each of a plurality of exercise levels with at least one user-selectable exercise, said user-selectable exercise including an associated exercise parameter combination;
- said exercise monitoring subsystem being further operable to allow said user to select a user-selectable exercise to be performed from any one of said plurality of exercise levels from said storage subsystem;
- said plurality of exercise levels ranging from a low exercise level, linked to an exercise with an associated exercise parameter combination that may be performed by users having a relatively low fitness level, to a first high exercise level, linked to an exercise having an exercise parameter combination requiring a relatively high fitness level to perform; said plurality of exercise levels including a second high exercise level, linked to an exercise requiring a relatively high fitness level to perform, where said second high exercise level is at a lower exercise level than said first high exercise level, but at a higher exercise level than other exercise levels in said plurality of exercise levels, based upon a comparison of exercise parameter combinations associated with exercises of respective exercise levels being compared;
- said processing subsystem being further operable to monitor the user's performance of at least one exercise activity and to notify said user, if said user's performance exceeds the user's prior best performance of said at least one exercise activity;
- said exercise monitoring subsystem being further operable to receive said step-related data from said pedometer, to determine the number of steps taken by said user during a step-related exercise, and to calculate the distance traveled during said step-related exercise;
- said processing subsystem being further operable to monitor a user's food consumption and exercise performance, based in part on user input, and to generate a notification to said user via said user interface of progress towards the achievement by said user of at least one daily food-related goal and at least one exercise-related goal; said processing subsystem being further operable to generate a display of a food-related daily goal and data indicative of said user's progress towards meeting said food-related daily goal, and to generate a display of an exercise-related goal and data indicative of said user's progress towards meeting said exercise-related goal;
- said processing subsystem being further operable to monitor said user's weight over time, and being operable to receive user weight data from said user interface and to store said user weight data in said storage subsystem, said processing subsystem being further operable to generate a weight-related display visually depicting a plurality of instances of said user's weight over time on said touch screen display;
- said touch screen display being operatively coupled to said processing subsystem to display at least some of said user's favorite foods to aid in food data entry by said user, to display said food-related daily goal and data indicative of said user's progress towards meeting said food-related goal, to display said exercise-related goal and data indicative of said user's progress towards meeting said exercise-related goal, and to display at least one current exercise parameter during the user's performance of an exercise.
2. A hand-held mobile weight and exercise management system according to claim 1, wherein said food monitoring subsystem is further operable to generate a nutritional-related rating for said specific user meal and to communicate said rating to said user via said user interface.
3. A hand-held mobile weight and exercise management computing device according to claim 1, wherein said processing subsystem is further operable to initiate communication of said exercise feedback to said user to change the level of exercise.
4. A hand-held mobile weight and exercise management computing device according to claim 1, wherein said exercise quantity-related parameter is distance and wherein said processing subsystem is operable to generate and couple to said touch screen display a visual depiction of the current exercise location and the pace of the exercise.
5. A hand-held mobile weight and exercise management computing device according to claim 1, further including a camera, wherein said food monitoring subsystem is operable to receive image data from said camera of a least one food item.
6. A hand-held mobile weight and exercise management computing device according to claim 1, wherein said storage subsystem includes: a first set of memory locations for storing data identifying said plurality of user-selectable foods, wherein each of said foods is associated with a unique food identifying signal, and for storing a plurality of descriptors associated with at least one of said foods, wherein said plurality of descriptors includes the quantity of each food, said first set of memory locations further operable to store data relating to the calories consumed by said user for each food based in part upon user input; and a second set of memory locations for storing data identifying said plurality of user-selectable exercises and for storing a plurality of descriptors associated with at least one of said exercises, wherein said plurality of descriptors includes data indicative of distance traveled during at least one motion-related exercise based upon data received from said GPS receiver, said second set of memory locations further operable to store data relating to the calories burned by said user during each exercise.
7. A hand-held mobile weight and exercise management computing device according to claim 1, wherein said user interface includes an audio input device being operable to receive a speech signal from a user, and wherein said storage subsystem includes memory locations being operable to store a set of instructions for performing speech recognition.
8. A hand-held mobile weight and exercise management computing device according to claim 1, wherein said processing subsystem is operable to store in said user profile data indicative of said user's age and height.
9. A hand-held mobile weight and exercise management computing device according to claim 1, wherein said processing subsystem is operable to store in said user profile data indicative of a user's physical statistics including a user's height, and a body frame size-related parameter.
10. A hand-held mobile weight and exercise management computing device according to claim 1, wherein said processing subsystem is operable to store in said user profile data indicative of a user's heart rate during exercise and to determine a target heart rate based in part on data stored in the user's profile.
11. A hand-held mobile weight and exercise management computing device according to claim 1, wherein said processing subsystem further includes a reward generating subsystem being operable to automatically select a reward for said user if a user health-related goal has been met by said user.
12. A hand-held mobile weight and exercise management computing device according to claim 1, wherein said processing subsystem further includes a behavioral subsystem that generates requests for input from a user regarding dietary issues, and generates dietary recommendations in response to the user's input.
13. A hand-held mobile weight and exercise management computing device according to claim 1, wherein said exercise monitoring subsystem, in response to user selection of said first exercise mode symbol, using said user location data received from said GPS receiver in said hand-held housing, being further operable to generate a visual depiction of the current location of said current exercise in real time indicating the user traversing the path defined by said user location data.
14. A hand-held mobile weight and exercise management computing device having a housing sized to be held in a user's hand comprising:
- a storage subsystem for storing health information including a user profile, said storage subsystem being operable to store health information about a user, including body weight, height, pulse rate information, at least one food-related goal including a calorie-related daily goal, and an exercise-related goal; said storage subsystem being further operable to store data relating to a plurality of user-selectable foods and to store data relating to a plurality of user-selectable exercises;
- a touch screen display operable to display food-related and exercise-related information to said user;
- a user interface operable to receive input from said user and to communicate output to said user, said user interface including a plurality of user interface displays displayable on said touch screen display; said user interface being operable to selectively initiate entry into said user profile or at least one food-related operation or at least one exercise-related operation, said user interface including a plurality of user-selectable symbols; said user-selectable symbols being operable to initiate entry into said user profile or at least one food-related operation or at least one exercise-related operation;
- a GPS receiver in said housing operable to receive input GPS data;
- a pedometer in said housing operable to generate step-related data;
- said user interface being operable to display on said touch screen display in said housing: a food mode symbol, a first exercise mode symbol for initiating an exercise mode that uses position coordinate information based upon said input GPS data, and a second exercise mode symbol for entry of data regarding a plurality of exercise modes that do not use position coordinate information based upon said input GPS data;
- a processing subsystem, operatively coupled to said user interface, said GPS receiver, said pedometer, said touch screen display, and said storage subsystem, said processing subsystem including: a food monitoring subsystem being operatively coupled to said storage subsystem and being operable to receive food-related data from said user, via said user interface, including data identifying a first set of foods input by said user, and being operable to link said first set of foods to a specific user meal, said first set of foods including a first food and a quantity-related parameter identified by said user; said food monitoring subsystem being operable to determine the calories expected to be consumed by said user upon eating said first food, and to store food-related information in said storage subsystem relating to said first food, including information relating to the nutritional content of said first food and the calories consumed by said user upon eating said first food, based in part on said food-related data from said user;
- said food monitoring subsystem, in response to user selection of said food mode symbol, being further operable to generate a food selection display screen identifying a plurality of meal category symbols that allow the user to select a meal category including a breakfast category symbol, a lunch category symbol, a dinner category symbol, and a snack category symbol;
- said food monitoring subsystem being further operable to generate a list of said user's favorite foods in response to food-related inputs by said user during food selection for said specific user meal; and an exercise monitoring subsystem being operatively coupled to said storage subsystem and, in response to user selection of said first exercise mode symbol or said second exercise mode symbol, being operable to receive exercise-related data from said user, via said user interface, including data identifying a first exercise expected to be performed by said user; said exercise monitoring subsystem being operable to determine the calories expected to be burned by said user upon performing said first exercise, and to store exercise-related information in said storage subsystem relating to said first exercise, including the calories burned by said user and an exercise quantity-related parameter upon said user performing said first exercise, based in part on data from said user; said exercise monitoring subsystem being further operable to accumulate the calories burned by the user during at least one day, and to display said calories burned during said at least one day to said user via said touch screen display; said exercise monitoring subsystem being further operable to analyze data related to user performance of at least one exercise, and to generate exercise feedback for said user relating to said at least one exercise; said exercise monitoring subsystem, in response to user selection of said first exercise mode symbol, being further operable to receive exercise data including user location data via signals received from said GPS receiver, to determine user distance traveled using location data from said GPS receiver, and to track user distance traveled and duration traveled; said exercise monitoring subsystem, in response to user selection of said first exercise mode symbol, using said user location data received from said GPS receiver in said hand-held housing, being further operable to generate the current location of a motion-related exercise, and to generate a visual depiction in real time indicating the user traversing the path defined by said user location data; said exercise monitoring subsystem being further operable to associate each of a plurality of exercise levels with at least one user-selectable exercise, said user-selectable exercise including an associated exercise parameter combination; said exercise monitoring subsystem being further operable to allow said user to select a user-selectable exercise to be performed from any one of said plurality of exercise levels from said storage subsystem;
- said plurality of exercise levels ranging from a low exercise level, linked to an exercise with an associated exercise parameter combination that may be performed by users having a relatively low fitness level, to a first high exercise level, linked to an exercise having an exercise parameter combination requiring a relatively high fitness level to perform; said plurality of exercise levels including a second high exercise level, linked to an exercise requiring a relatively high fitness level to perform, where said second high exercise level is at a lower exercise level than said first high exercise level, but at a higher exercise level than other exercise levels in said plurality of exercise levels, based upon a comparison of exercise parameter combinations associated with exercises of respective exercise levels being compared;
- said processing subsystem being further operable to monitor the user's performance of at least one exercise activity and to notify said user, if said user's performance exceeds the user's prior best performance of said at least one exercise activity;
- said exercise monitoring subsystem being further operable to receive said step-related data from said pedometer, to determine the number of steps taken by said user during a step-related exercise, and to calculate the distance traveled during said step-related exercise;
- said processing subsystem being further operable to monitor a user's food consumption and exercise performance, based in part on user input, and to generate a notification to said user via said user interface of progress towards the achievement by said user of at least one food-related daily goal and at least one exercise-related goal; said processing subsystem being further operable to generate a display of a food-related daily goal and data indicative of said user's progress towards meeting said food-related daily goal, and to generate a display of an exercise-related goal and data indicative of said user's progress towards meeting said exercise-related goal;
- said processing subsystem being further operable to monitor said user's weight over time, and being operable to receive user weight data from said user interface and to store said user weight data in said storage subsystem, said processing subsystem being further operable to generate a weight-related display visually depicting a plurality of instances of said user's weight over time on said touch screen display;
- said touch screen display being operatively coupled to said processing subsystem to display said food-related daily goal and data indicative of said user's progress towards meeting said food-related goal, to display said exercise-related goal and data indicative of said user's progress towards meeting said exercise-related goal, to display at least some of said user's favorite foods to aid in food data entry by said user; and being further operatively coupled to display said visual depiction of said motion-related exercise in real time indicating the user traversing the path defined by said user location data while the user is moving along said path, and to display to said user at least one current exercise parameter during the user's performance of an exercise.
15. A hand-held mobile weight and exercise management computing device according to claim 14, wherein said food monitoring subsystem is further operable to generate a nutritional-related rating for said specific user meal and to communicate said rating to said user via said user interface.
16. A hand-held mobile weight and exercise management computing device according to claim 14, wherein said processing subsystem is operable to generate a color code indication to said user, via said touch screen display, of progress towards achievement of a calories consumed-related goal.
17. A hand-held mobile weight and exercise management computing device according to claim 14, further including a camera, wherein said food monitoring subsystem is operable to receive image data from said camera of a least one food item.
18. A hand-held mobile weight and exercise management computing device according to claim 14, wherein said processing subsystem is operable to store in said user's profile data indicative of a user's heart rate during exercise and to determine a target heart rate based in part on the user's age stored in the user's profile.
19. A hand-held mobile weight and exercise management computing device having a housing comprising:
- a storage subsystem for storing health information about a user including a user's profile, said storage subsystem being operable to store health information about said user including body weight, height, pulse rate, a calorie-related daily goal, and an exercise-related goal; said storage subsystem being further operable to store data relating to a plurality of user-selectable foods and to store data relating to a plurality of user-selectable exercises;
- a touch screen display operable to display food-related and exercise-related information to said user;
- a user interface operable to receive input from said user and to communicate output to said user, said user interface including a plurality of user interface displays displayable on said touch screen display; said user interface being operable to selectively initiate entry into said user profile or a food-related operation or an exercise-related operation, said user interface including a plurality of symbols selectable by said user, including a symbol operable to initiate entry into a user profile mode of operation, at least one food-related symbol operable to initiate entry into a food-related mode of operation, and a plurality of exercise-related symbols operable to initiate entry into a plurality of exercise-related modes of operation;
- a GPS receiver in said housing operable to receive input GPS data;
- a pedometer in said housing operable to generate step-related data;
- said user interface being operable to display on said touch screen display in said housing: a food mode symbol, a first exercise mode symbol for initiating an exercise mode that uses position coordinate information based upon said input GPS data, and a second exercise mode symbol for entry of data regarding a plurality of exercise modes that do not use position coordinate information based upon said input GPS data;
- a processing subsystem operatively coupled to said user interface, said GPS receiver, said pedometer, said touch screen display, and said storage subsystem, said processing subsystem including: a food monitoring subsystem being operatively coupled to said storage subsystem and being operable to receive food-related data from said user, via said user interface, including data identifying a first set of foods input by said user, and being operable to link said first set of foods to a specific user meal, said first set of foods including a first food identified by said user and a quantity-related food parameter; said food monitoring subsystem being operable to determine the calories expected to be consumed by said user upon eating said first food, and to store food-related information in said storage subsystem relating to said first food, including information relating to the nutritional content of said first food and the calories consumed by said user upon eating said first food, based in part on said food-related input from said user; said food monitoring subsystem being further operable to accumulate the calories consumed by said user during a given day based in part on the user's food-related inputs and to display said calories consumed by said user on said given day via said touch screen display; said food monitoring subsystem, in response to user selection of said food mode symbol, being further operable to generate a food selection display screen identifying a plurality of meal category symbols that allow the user to select a meal category including a breakfast category symbol, a lunch category symbol, a dinner category symbol, and a snack category symbol; said food monitoring subsystem being further operable to generate a list of said user's favorite foods in response to food-related inputs from said user interface; and an exercise monitoring subsystem being operatively coupled to said storage subsystem and being operable, in response to user selection of said first exercise mode symbol or said second exercise mode symbol, to receive exercise-related data from said user, via said user interface, including data identifying a first exercise expected to be performed by said user; said exercise monitoring subsystem being further operable to determine the calories expected to be burned by said user by performing said first exercise; and to store exercise-related information in said storage subsystem relating to said first exercise, including the calories burned by said user and an exercise-quantity related parameter upon said user performing said first exercise, based in part on data from said user; said exercise monitoring subsystem being further operable to accumulate the calories burned by the user during at least a given day, and to display said calories burned to said user via said touch screen display; said exercise monitoring subsystem, in response to user selection of said first exercise mode symbol, being further operable to receive exercise data including user location data via signals received from said GPS receiver, and to determine user distance traveled using said location data from said GPS receiver; said exercise monitoring subsystem being operable to track user distance traveled and duration traveled; said exercise monitoring subsystem being operable, in response to user selection of said first exercise mode symbol, to generate, via said touch screen display, a visual depiction of the current location of a current exercise and an exercise parameter relating to the user's performance of said current exercise;
- said exercise monitoring subsystem, in response to user selection of said first exercise mode symbol, using said user location data received from said GPS receiver in said hand-held housing, being further operable to generate a visual depiction of the current location of said current exercise in real time indicating the user traversing the path defined by said user location data;
- said exercise monitoring subsystem being operable to receive said step-related data from said pedometer, to determine the number of steps taken by said user during at least one step-related exercise, to calculate the distance traveled during said step-related exercise, and to determine the number of calories burned during said step-related exercise; said exercise monitoring subsystem being further operable to display real-time performance data regarding said step-related exercise to said user, via said touch screen display;
- said processing subsystem being further operable to monitor said user's weight over time, and being operable to receive user weight data and to store said user weight data in said storage subsystem; said processing subsystem being further operable to generate a user's weight-related display visually depicting a plurality of instances of said user's weight over time on said touch screen display;
- said processing subsystem being further operable for a motion-related exercise to associate a first color code with said user's expected performance at a first pace, and to associate a second color code with said user's expected performance at a second pace that is faster than said first pace;
- said processing subsystem being further operable to monitor the user's performance of at least one exercise and to notify said user, if said user's performance exceeds the user's prior best performance of said at least one exercise;
- said processing subsystem being further operable to monitor a user's food consumption and exercise performance, based in part on user input, and to generate a notification to said user via said user interface of progress towards the achievement by said user of at least one food-related daily goal and at least one exercise-related goal;
- said processing subsystem being further operable to generate a display of a food-related daily goal and data indicative of said user's progress towards meeting said food-related daily goal, and to generate a display of an exercise-related goal and data indicative of said user's progress towards meeting said exercise-related goal;
- said touch screen display being operatively coupled to said processing subsystem, while in a food-related mode, to display said calorie-related daily goal and data indicative of said user's progress towards meeting said calorie-related daily goal, and to display at least some of said user's favorite foods to aid in food data entry by said user; and, while in an exercise-related mode, to display said exercise-related goal and data indicative of said user's progress towards meeting said exercise-related goal, to display the calories burned by the user during a given day based in part on the user's input, to display said visual depiction of the current location of said current exercise in real time indicating the user traversing the path defined by said user location data while the user is moving along said path, and to display an exercise parameter relating to said current exercise; said touch screen display being further operable to display a plurality of instances of said user's weight over time.
20. A hand-held mobile weight and exercise management computing device according to claim 19, wherein said exercise monitoring subsystem is operable to analyze data related to the user's performance of at least one current exercise, and to generate exercise feedback to said user to change the level of exercise, based at least in part on said pulse rate information stored in said storage subsystem, said processing subsystem being further operable to initiate communication of said exercise feedback to said user to change the level of exercise, based at least in part on said stored pulse rate information.
21. A hand-held mobile weight and exercise management computing device according to claim 19, wherein said processing subsystem is further operable to store information indicative of the performance of a current exercise by said user and to dynamically generate a recommendation to the user to increase or decrease the amount of exercise based on the user's performance of said current exercise.
22. A hand-held mobile weight and exercise management computing device according to claim 19, wherein said visual depiction in real time indicating the user traversing the path shows an avatar traversing the path.
Type: Application
Filed: Feb 19, 2016
Publication Date: Jun 16, 2016
Inventors: Mark E. Nusbaum , Vincent Pera, JR. (Cranston, RI)
Application Number: 15/047,817
