FOOD DATA ACCESS AND DELIVERY SYSTEM
1. A system for coding nutritional information associated with ingestible substances, comprising:
- a first database storing dietary products along with nutritional fields and values for each nutritional field in association with each dietary product;
a second database storing more than one predetermined profile, each predetermined profile indicating a different subset of the nutritional fields and an order for the subset of nutritional fields;
a computer coupled the first database and the second database and configured to generate a nutritional tag comprising coded information representing a subset of the values for each dietary product based upon one of the predetermined profiles;
a tag capture device for receiving the coded information; and
a decoder for identifying the predetermined profile used to encode the coded information and for decoding the subset of values based upon the predetermined profile.
An improved system for accessing food data and tracking a user'"'"'s food intake includes a nutrition information system and a mobile PDA or smartphone-based tag reading system. The two systems are configured to communication. The mobile tag reading system includes a tag capture device for reading the nutritional tag, and a decoder for decoding the header or visual effects included in the nutritional tag to identify the predetermined profile. The decoder is also configured to decode the nutritional tag to generate the subset of the dietary product descriptions and associated nutritional values based upon the predetermined profile. A tracking log is included for storing the associated nutritional values or the modified associated nutritional values based upon input from the user.
- 1. A system for coding nutritional information associated with ingestible substances, comprising:
a first database storing dietary products along with nutritional fields and values for each nutritional field in association with each dietary product; a second database storing more than one predetermined profile, each predetermined profile indicating a different subset of the nutritional fields and an order for the subset of nutritional fields; a computer coupled the first database and the second database and configured to generate a nutritional tag comprising coded information representing a subset of the values for each dietary product based upon one of the predetermined profiles; a tag capture device for receiving the coded information; and a decoder for identifying the predetermined profile used to encode the coded information and for decoding the subset of values based upon the predetermined profile.
- View Dependent Claims (2, 3, 4, 5, 6, 7, 8, 9, 10, 11)
- 12. A method for coding nutritional information associated with ingestible substances, comprising the steps of:
storing dietary products along with nutritional fields and values for each nutritional field in association with each dietary product; storing more than one predetermined profile, each predetermined profile indicating a different subset of the nutritional fields and an order for the subset of nutritional fields; generating a nutritional tag comprising coded information representing a subset of the values for each dietary product based upon one of the predetermined profiles; identifying the predetermined profile used to encode the coded information; decoding the subset of values based upon the predetermined profile used to encode the coded information; and storing the values in a user log.
- View Dependent Claims (13, 14, 15, 16, 17)
- 18. A tag reading system configured for use with a nutrition information system, said nutrition information system including a database storing dietary product descriptions and associated nutritional information, and a computer coupled to the database and configured to generate a nutritional tag representing a subset of the dietary product descriptions and associated nutritional information based upon one of a plurality of predetermined profiles, wherein the nutritional tag comprises at least one of a header and visual effects indicative of the predetermined profile, the tag reading system comprising:
a tag capture device for reading the nutritional tag; a decoder for first decoding the header or visual effects included in the nutritional tag to identify the predetermined profile, and then decoding the nutritional tag to generate the subset of the dietary product descriptions and associated nutritional values based upon the predetermined profile, and wherein the decoded dietary descriptions and associated nutritional values represent sub-items that are combined to make up an item; a tracking log for accumulating nutritional values extracted from previously read nutritional tags, and wherein the values accumulated in the user log are associated with the sub-items; a consumer application configured to use downloaded items to enable a user to substitute one sub-item with another sub-item; and a tracking log modification means interfaced with the consumer applications for creating modified nutritional values in the tracking log based on sub-item substitutions selected by a user and for providing the modified nutritional values to the tracking log.
- View Dependent Claims (19, 20)
This application is a continuation of U.S. patent application Ser. No. 15/190,952, “Food Data Access and Delivery System,” filed on Jun. 23, 2016, which claims priority to and the benefit of U.S. Provisional Patent Application No. 62/184,160, “Electronically Readable Dietary Tag and Reader,” filed Jun. 24, 2015; U.S. Provisional Patent Application No. 62/197,854, “Electronically Readable Dietary Tag and Reader,” filed Jul. 28, 2015; U.S. Provisional Patent Application No. 62/293,230, “Electronically Readable Dietary Tag and Reader,” filed Feb. 9, 2016; U.S. Provisional Patent Application No. 62/293,709, “Electronically Readable Dietary Tag and Reader.” filed Feb. 10, 2016; and U.S. Provisional Patent Application No. 62/334,078, “Scannable Nutrition Coded Tag Integration,” filed May 10, 2016, and U.S. application Ser. No. 14/766,866, “Electronically Readable Dietary Tag and Reader,” filed Aug. 10, 2015, which claims priority to PCT/US2014/016326, “Electronically Readable Dietary Tag and Reader,” filed Feb. 13, 2014, which claims priority to U.S. Provisional Application No. 61/764,172, “Electronically Readable Dietary Tag and Reader,” filed Feb. 13, 2013. Each of these applications is hereby incorporated by reference in its entirety.
The present application relates generally to the field of food data access systems, and more specifically to technical improvements in the field of computer-based identification of food data and systems for delivering food data on demand.
Studies have shown that people who track what they eat on paper, in an app, or in some other record, have better success at losing weight, managing their diet, controlling their portions, and sticking to healthy eating habits. For example, individuals who keep a food diary, or a regular log of what they'"'"'ve eaten and when, are more conscious of what they'"'"'ve eaten and are better able to maintain a healthy diet, even without counting calories. One study concluded that people who kept a journal were more likely to keep the weight they lost off, and another review of studies concluded that people who kept a record of their meals and kept up with diet and exercise lost nearly twice as much weight as people who did not keep a log. (Kaiser Permanente. “Keeping A Food Diary Doubles Diet Weight Loss, Study Suggests.” ScienceDaily, 8 Jul. 2008. www.sciencedaily.com/releases/2008/07/080708080738.htm.)
Tools have been developed to help individuals track their diets. Current trackers enable users to access food data by searching various databases of foods. There are many drawbacks, however, with this approach. The databases are often incomplete and the foods that the user is searching for are not included or the search results do not correlate well to the intended food the user is searching for. For example, searching for peppers brings up different color peppers, different kinds of peppers, e.g., chili versus bell, and different spices.
More importantly, many databases are created with crowd-sourced data so that the data may not be accurate nor is it clear what food information was used to generate each of the food entries. To illustrate this problem, one can do a search using a popular food tracker called MyFitnessPal (MFP) for Chicken Tikka Marsala. The MFP tracker returns approximately 20,000 results all of which are based on different recipes, possibly sides like rice that are served with the dish, and other factors that are not known to the user initiating the search. If the user has ordered a menu item from a restaurant, he may be able to narrow the search by entering the restaurant name as a search term. But even doing that still creates a long list of items that the user needs to search through to try to estimate which item approximates the food that the user is searching for. To illustrate this, consider the following. Potbelly sandwich shops provide a nutrition information page for their sandwiches. A Wreck sandwich is served on multigrain bread, with roast beef, turkey salami, ham and Swiss cheese. Some people choose different kinds of breads, make different meat and cheese choices, and add different toppings (tomatoes, mayo, etc.). A search in MFP for a Potbelly A Wreck sandwich yields 135 different search results ranging from about 220 calories to about 800 calories. There is no way to tell which result, if any, match the combination of ingredients the user is interested in and there is no way from the listing alone that a user could determine if the data is accurate. A user could go to the Potbelly nutrition page and make the custom selections he is interested in and calculate the corresponding nutrition information but then the user would have to manually enter that information into his tracker and save a new Potbelly A Wreck sandwich, making a 136th entry.
Some restaurants also provide only very incomplete information such as the total number of calories for the cheeseburger and fries. There is no way for a user to modify the information if the user only plans to eat half the fries, substitute the fries for a salad, decides to hold the cheese, or adds BBQ sauce to the burger. Other restaurants and venues where people eat, e.g., banquets, company picnics, grab and go counters, pot lucks, dinner parties, etc., don'"'"'t provide any nutrition information for the foods being served. So a user can only search for the individual ingredients that are easily identifiable in the food served.
Given all of these challenges it is extremely inefficient, time consuming and tedious to ascertain food data and track it. The problems that individuals face in food tracking today are well documented in Barriers and Negative Nudges: Exploring Challenges in Food Journaling, Cordeiro et al. (available at http://www.depstein.net/pubs/fcordeiro_chil5.pdf). The inventive system described below addresses these challenges.
The inventive system improves the process of tracking consumption for a large variety of foods, including those prepared from recipes or served by venues, thus making it easier and more efficient for individuals to make better choices. Illustrative embodiments of the present invention coordinate the use of ubiquitous technology to enable a user'"'"'s smartphone to record the data important to the user'"'"'s unique nutrition needs, whether at a store, restaurant, kitchen, or wherever else food items are consumed.
In an exemplary embodiment, the present invention provides a tag reading system configured for use with a nutrition information system, where the nutrition information system includes a database storing dietary product descriptions and associated nutritional information. A computer coupled to the database is configured to generate a nutritional tag representing a subset of the dietary product descriptions and associated nutritional information based upon one of a plurality of predetermined profiles. The nutritional tag includes a header or visual effects, or both. The header or visual effects are coded symbols representing a specific predetermined profile.
In the exemplary embodiment, the tag reading system includes a tag capture device for reading the nutritional tag, a decoder for decoding the header or visual effects included in the nutritional tag to identify the predetermined profile, and then decoding the nutritional tag to generate the subset of the dietary product descriptions and associated nutritional values based upon the predetermined profile. A tracking log is also included in the tag reading system for accumulating nutritional values extracted from previously read nutritional tags. A tracking log modification module is also included for creating modified nutritional values in the tracking log based on food substitutions selected by the user.
The structure of the nutritional tags in combination with the structural features of the nutrition information system and tag reading system, including logical structures and processes, synergistically cause a number of advantageous technical effects. Importantly, the system is more efficient in logging users'"'"' daily food intake. Moreover, the system is able to more accurately, and more precisely, log the users'"'"' food intake. The use of a central database storing dietary product descriptions and nutritional information, in combination with the inventive nutrition tags and smartphone-based tag reading system, improves the process of collecting, organizing, and presenting nutrition data for a large variety of foods.
Other aspects of the present invention are described below.
The foregoing summary, as well as the following detailed description are better understood when read in conjunction with the appended drawings. For the purpose of illustrating the invention, there is shown in the drawings exemplary constructions of the invention; however, the invention is not limited to the specific methods and instrumentalities disclosed. Like reference numerals refer to like elements throughout the drawings.
We will now describe illustrative embodiments of the present invention. With reference to
One embodiment of the present invention contemplates an electronically readable tag as described in U.S. Provisional Patent Application Nos. 62/184,160 and 62/197,854, entitled “Electronically Readable Dietary Tag and Reader” filed Jun. 24 and Jul. 28, 2015, respectively.
A user having a tag reader 40 will scan a tag associated with an item that a user has consumed or is considering consuming. The tag reader 40 is configured to decode the scanned tag. Once the scanned tag is decoded, the decoded information is stored in the user'"'"'s log 50. If the user desires to modify the logged information by changing the portion size or making a substitution, the user may invoke the change module 60. A user could make the changes before anything is logged and then only log after the changes are made. In one embodiment of the invention the tag reader 40, consumer log 50 and change module 60 are all part of a user application 65 accessible from one or more of the user'"'"'s devices such as a mobile phone, laptop computer, tablet, desk top computer, wearable device or any other computing device. The change module 60 connects to the network tag database 25 and the ingredients database 20 to look up the relevant changes and overwrite the new information in the log 50. In one embodiment of the invention the network tag database 25 is stored on a secure server that is accessible only to registered venues and registered users.
8 oz of prime rib,
1 cup of garlic mashed potatoes comprising ½ potato, ¼ cup of skim milk, 2 garlic cloves, 2 tbsp of Acme brand butter, ⅛ tsp of salt and ⅛ tsp of pepper
1.5 cups of seasonal vegetables comprising ⅓ cup zucchini, ⅓ cup yellow squash, ⅓ cup red pepper, ½ cup chopped cauliflower, ½ tablespoon of oil, fresh rosemary
Building the menu item can be implemented in a variety of ways and the invention is not limited to these precise steps.
A sample input screen illustrating steps 130 to 170 for the above example is shown in
A user may track the nutritional and other information pertaining to the items consumed according to the process shown in
In one embodiment of the invention, the user can optionally modify an item that has been logged at step 330 as shown at step 340. If the user wishes to modify an item, for example by modifying a portion or by making a substitution, the user selects an item at 345. The selection step 345 may be implemented, by way of example only, by displaying a list of the user'"'"'s logged items from which the user may electronically select one or more of the listed items, or the user could instead search for a specific item. It should be further understood that the number of items listed could be based on a variety of factors such as for illustrative purposes only the items logged in the past day. The user would select the item to be modified at 345 and would make the desired changes to the item at 350. The changes may be implemented in a variety of ways as is described below. Once the changes are made, a new look-up is performed in accordance with step 360.
In addition, the tag will preferably include a venue field with the unique network ID such that each venue that has registered to become part of the network has an individually unique ID. Since the network tag database 25 stores the amounts and ingredients for the various items, registered users and venues can access the database to “break it down” so that modifications can be made based on elimination of certain ingredients or decisions not to eat certain portions, e.g., only ate half the garlic mashed potatoes. It should be understood that if the network tag database 25 is secured with access only to registered users and venues, users and venues may only be given access to the item information in the user'"'"'s own log or the items generated by the corresponding venue, respectively.
In another embodiment of the invention, the user may wish to modify the logged info by requesting the modified information by, for example, sending a request to a network service provider and having the network service provider send back the modified information.
In another embodiment of the invention, the user may be notified of items the user logged when visiting a particular venue again or when in the vicinity of the same venue. For example, if a user purchased a ham and cheese sandwich on whole grain bread with mustard at the Ma & Pop'"'"'s corner deli, the user application 65 can be set to check for prior items consumed at the venue.
In another embodiment, a venue can register with multiple locations so that the consumer application could look up and display any previous items consumed at any of the venue'"'"'s locations when determining that the user has entered the venue or is nearby any of the venue locations. Correspondingly, a user could select certain items in its log and initiate a search for the closest location for the associated venue. Venues with multiple locations would preferably indicate when generating tags for their respective items if certain items are only available at certain locations so that such information could be stored in the network tag database 25 (
The consumer application 65 in one embodiment of the invention may also permit the user to select certain search criteria, such as for illustration purposes only, meals that meet certain dietary thresholds, e.g., 5 Weight Watchers® points or Zone® ratio meals. Alternatively, the consumer application could be programmed to monitor the user'"'"'s consumption trends. For example, every weekday the user eats lunch out and typically orders a salad. If it is about the time of day when the user normally eats lunch, the consumer application in this embodiment would search for venues that serve salads and display the venue name, location and salads including the nutritional and other information associated with the salads. To provide another example, if a user typically consumes more protein, and presumably should consider finding a high protein meal, the consumer application may notify the user that he or she is low on protein and then search for venues that serve high protein meals displaying the venue names, locations and high protein meals with their associated nutritional information. It should be understood that venue locations for all of the above search scenarios may be shown by address or by map such as by interfacing with a common mapping application. It should further be understood that the foregoing examples are for illustrative purposes only and not intended to limit the invention.
In another embodiment of the invention, the consumer log 50 stores the time of day when an item is consumed. The time may be stored automatically when the tag is decoded and logged or it may be entered manually by the user. The consumer application 65 may preferably include a consumer indication module 830 enabling the user to input various indications reflecting the user'"'"'s health, wellness or overall subjective feelings or mood. For example, the user may input that he or she feels tired, bloated, or anxious, or that he or she is nauseas or has a headache. These indications along with the time of day may be recorded in the consumer log 50. The trend monitor module 830 could be programmed to search consumer log for 50 for nutrition, allergen, or other factors such as time between meals that might have a correlation to one or more of the user input indications. If a correlation is detected by the consumer indication module 830 that is based on a dietary deficiency, the consumer indication module 830 could signal the search venue module 810 to initiate a search for a registered venue that serves items that would fill the dietary deficiency identified by the consumer indication module 830.
As discussed previously, a user, like a venue, may be requested to register with the network service provider 910. The user, like the venue, would also receive a unique user network ID associated with being a user.
In one embodiment of the invention, the consumer log 50 is accessible only by the user irrespective of whether the consumer log is stored on the user'"'"'s device and/or remotely, i.e., on a cloud server. In another embodiment of the invention, the consumer log 50 and the network tag database 25 are managed by the network service provider 910. In this embodiment of the invention, the network service provider could provide a venue, in a variety of ways, the items logged by users that the user purchased from that venue. Data such as the user'"'"'s network id, the item consumed, any modifications that were made to the portion size or substitutions, any profile preferences, and the date and time such item was purchased along with any other relevant information of interest that is trackable could be provided to such venue.
In another embodiment of the invention, a venue could search for registered users that have also been customers of such venue. The network service provider 910 could provide information in the venue-specific customer log 920 to the Consumer Search Application 900. The venue using the Consumer Search Application 900 could evaluate the customer'"'"'s specific purchases or trends related to that venue and send messages to the customer as discussed above when the customer enters the venue or is nearby. In addition to messages discussed above, the venue could use more targeted messages such as providing discounts for items that the customer previously purchased or propose that that the customer come in to purchase an item that, based on previous purchases, the customer may enjoy.
It should be understood, that the network service provider 910 may provide any trend information to any venue and enable the venue to message the user irrespective of whether or not the user is a customer and whether or not the message is based on a user trend, indication, specified criteria or some other criteria or preference.
In another embodiment of the invention, venues can utilize a network service provider 910 to evaluate the venue'"'"'s customer purchases and make suggestions about when to buy new supplies or when to have specials to encourage sales of perishable foods. According to this embodiment, the network service provider 910 could evaluate all of the venue-specific customer logs 920 over a period of time that could be pre-programmed or specified by the venue and tabulate items and sub-items purchased or consumed during that applicable time period. The network service provider 910 could identify those items or sub-items purchased the most and send a message to the venue network application 930 to check to see if it needs to order more of the item or sub-item. Conversely the network service provider 910 could identify those items or sub-items that were purchased the least over the applicable period of time and identify any perishable items so identified and send a message to the venue network application to sell the perishable items before they go bad. It should be understood that the data stored in the venue-specific user logs 920 could be evaluated for a variety of different reasons, and consequently different types of messages could be generated and transmitted to the venue network application 930. For example, a message alert stating: “No one has bought ham for 1 week. Run a special to sell it before it goes bad to avoid having to dispose of bad ham.” Or as another example, sending a message stating: “Many customers are substituting brown rice for white rice, do you need to order more brown rice?” Other important information can be ascertained from the consumption data, such as customers are not eating their pickles, so the venue should only include pickles if requested. It should be understood that these examples are for illustrative purposes and not intended to limit this feature of the invention.
In another embodiment of the invention, a registered venue could offer a loyalty program to its customers that are network registered users. For example, suppose a venue wants to offer a free dessert after the purchase of 5 meals. The venue could use the tag generator application 10 in
After the tag generator application has stored the relevant nutritional and other information for an item in the network tag database (step 215 in
In one embodiment of the invention, the information provided by the venue at steps 1010 and 1025 is transmitted to the network service provider at step 1030. The network service provider registers the loyalty program at step 1030 and creates a tag at step 220 with a field indicating that the item is associated with the loyalty program. At step 1035, the network service provider initiates a counter associated with the registered venue. When a registered user scans the tag for an item at step 1040, and stores the information in the user'"'"'s log (as described above), the network service provider could update a counter at step 1050 for that registered user. The network service provider could store the updated counter in the user log or the venue-specific customer database or both. The network service provider then checks the counter at step 1060 against the limit set by the venue when inputting the details of the loyalty program at step 1040 and sends a message at 1070 to the venue, customer or both if the limit has been reached. In this example, the message could say “This customer has earned a free dessert” or “You are entitled to a free dessert.” It should be understood that the message could be sent by text, pop-up message through the relevant applications, or other suitable means. It should further be understood that the counter could be implemented within the venue'"'"'s POS terminal and connected computing devices or within the consumer application for each customer. This example is described for illustrative purposes only and is not intended to limit the invention to the example or the implementation described.
Embodiments of the present invention enable a user to scan a venue-unique tag to identify only those items that satisfy the user'"'"'s profile or other preferences. For example, if a user is allergic to dairy products, the consumer application would identify those menu items available from the venue that are dairy-free.
The user may also use the downloaded items and sub-items to modify a scanned tag or logged entry as discussed above in connection with
A presently preferred implementation of the nutritional tag 100 is described in detail in U.S. application Ser. No. 14/766,866. Moreover, the invention may be implemented using other coding structures, such as QR codes as discussed below and in US Provisional Application Nos. 62/293,230 and U.S. Provisional Patent Application No. 62/334,078.
A nutritional tag 100 is shown in
In this example, the tag 100 would comprise 11 rows 101 and each row would be coded in accordance with the value associated with a food, beverage or other ingestible substance. In a preferred embodiment the coding is represented in Binary Coded Decimal. However, those skilled in the art will recognize that other coding schemes are also suitable, such as binary, or 2D matrix bar codes such as Aztec and the like. The profile would also have a predetermined serving size associated with the nutritional information. The serving size could be a specific measure or amount such as 1 tablespoon, ½ cup, or 6 ounces. Alternatively, the serving size could be equivalent to a single serving as sold for prepared, packaged, or ordered products. It should be understood that that the serving size may also be encoded into the tag rather than associated in a predetermined manner with a particular profile. For illustrative purposes only, a serving of Ricotta cheese could be specified as ¼ of a cup and have the following values associated with the profile specified in Table 1 above.
The tag 100 for the above example of Ricotta cheese using BCD coding is shown in
In a second profile according to the present example, the nutritional information may be extended as specified in Table 3 below.
For a serving of ricotta cheese, the values associated with the extended profile are listed in Table 4.
The tag 100 coded according to the extended profile for a serving of ricotta cheese is shown in
In an alternative embodiment, the profile identifier may be represented by visual or coded effects associated with the tag in a predetermined manner. For example,
It should also be understood that some profiles may take advantage of both a header and a visual or coded effect to identify the profile represented. For example, a standard for all nutritional information could be created where the nutritional information would be listed in a predetermined order corresponding to a row number in a given tag. In creating the tag, only those rows to be tracked are included in the tag. The header for such tag would include a list of the row numbers corresponding to the nutritional information included in the tag. For instance, if an individual was interested in tracking only his niacin, calcium and Vitamin D intake, and the rows corresponding to niacin, calcium and Vitamin D are 7, 12 and 16 out of a possible 56 total predetermined rows, then the header could be represented as 56 cells with the 7th, 12th and 16th cell marked. A profile could be defined for this type of tagging, i.e., a subset of the universal list and identified by a visual effect.
Many profile variations are also contemplated by the present invention such as drug directives, allergens, artificial substances and the like. For example, a profile could also be created that specifies allergens or other substances to be avoided that are present in a particular ingestible substance.
Table 5 shows an exemplary predetermined scheme for allergens and other substances that may be found in ingestible products that individuals may choose to avoid.
The predetermined scheme may include N substances although very few ingestible substances would likely contain more than a fraction of such substances. Therefore, the tag associated with such a profile might include only the row numbers for those allergens or other substances that are present in a particular food. For example, a serving of chocolate cake may include gluten, dairy, eggs and caffeine. Assume for the purposes of this example that N=25.
In the case of drug directives, a profile could be created for each drug with the relevant directives such as avoiding dairy or alcohol. Table 6 is an exemplary profile associated with drug directives.
As noted above, the inventive system may be implemented using QR codes for the tags. As envisioned, the system would be configured to import the specific information for any food and encode the nutritional and allergen information into scannable tags. The scannable tags can be printed on menus, receipts, and signs, or even transmitted or displayed electronically. Users can then scan the tags using the inventive mobile app described below. Unlike the trackers and tools available today, the inventive system allows the user to select any of the ingredients and change its portion size, substitute it for something else and add other items that are available from the venue. Once those changes are made, the user needs but a single click to automatically populate the tracker with the relevant food data.
The tag itself is quite versatile and may be used in a variety of additional ways. For example, users could share tags with guests at a dinner party. Or the encoded information could be expanded to include other information, such as GMOs, artificial ingredients, or other data of interest. Data can be exported after it is scanned and logged to a different tracker. The encoded data can be used to provide users with personalized alerts, notices, and suggestions based on their personal targets and profile. Venues can use encoded fields to support promotions, loyalty programs and other marketing to the network of users. The tags can also be customized in a way that includes unique information types, such as “certified organic” or “IBUs” for beer.
There are dozens of recipe sites with thousands of recipes each. Some provide nutritional information that could be manually entered into a tracker but many do not. Most cooks, however, make modifications to the ingredients and amounts when preparing the actual recipe. As a result many recipes are followed by reviews with suggested changes. The inventive system could partner with a recipe site where the recipe ingredient lists are exported to the system. The system could then produce a tag and export it to the recipe site to include with a recipe. Cooks could scan the tag or click on a link to the system to make changes to the ingredients list to calculate the nutritional info based on those changes. If that cook left a review, the revised tag could be affixed to the review so that cooks making the same changes could simply scan the tag.
Most venues use a food service solution to maintain their inventory, point of sale, and recipe costing systems. Using these systems, venues know what they sell and how much of a margin they have per item sold but they cannot optimize if they don'"'"'t know how much food their customers are actually consuming. The inventive system could import the recipe ingredient lists and generate tags for the venue. When the tags are scanned by the venues customers, the system could provide consumption reports, e.g., 80% of your customers don'"'"'t eat the roll you include with their order, that would enable venues to optimize their margins.
The system could also import all of the items available at each station in a cafeteria and create a single tag. When the tag is scanned the customer can see the list of everything that is available and make his or her selections and portion size adjustments and then with a single click log the relevant nutrition info. Consumption data reports would be of use to the cafeteria as a means to avoid waste, e.g., determine what people are actually consuming to minimize waste.
Aspects of a base product are described in U.S. Provisional Patent Application No. 62/293,230, Feb. 9, 2016; U.S. Provisional Patent Application No. 62/293,709, Feb. 10, 2016; and U.S. Provisional Patent Application No. 62/334,078, May 10, 2016. Important aspects of the technology-based solutions described relate to the areas of information coding, user interfaces, data compression, and extensibility. The inventive solutions involve new, efficient ways of encoding information on both physical encoded tags/packaging as well as on digital storage media. The inventive system for producing electronically readable dietary tags solves the technical problem of optimally selecting, arranging, and displaying the nutritional information in the form of an encoded tag that can be physically associated with food items and also electronically read using optical imaging technology (such as a camera or bar code or QR code reader). The novel tag design improves the operational efficiency and effectiveness of the overall system itself, and it solves the technical problem of attaching the relevant nutritional information to the dietary products and transferring that information to users that purchase or consume the dietary products. Moreover, the coded information may be based on standardized or predetermined profiles so that the information actually encoded can be reduced and so that the codes can be designed with flexibility in mind. For example, one standardized profile could include just the essential nutritional information and allergens that are required by labeling laws on certain processed products (“Core Profile”). Another profile could include all the Core Profile information plus any artificial ingredients and/or GMOs. Other profiles could be adapted to include various vitamins, minerals or other substances of interest for certain diets or for certain health-related conditions. The size of the printed code will be important to ensure that it is large enough to be accurately scanned but not so large that it needs to take up too much real estate on the menus, receipts, packaging etc. Flexibility is also important not only for users who may be interested in different kinds of information but for venues and producers who may not be willing to adopt a system if certain information either must be included or excluded from the tags.
As discussed in the Background section above, several food trackers are now available enabling users to log dietary information relating to the foods/beverages consumed by such users. These food trackers are implemented as mobile apps with corresponding websites, e.g., MyFitnessPal, that enable users to access other dietary resources and information. The mobile apps provide a variety of tools, e.g. databases, barcode readers, etc., permitting users to obtain the dietary information they want to track. Only a small percentage of food as prepared for consumption, however, has been barcoded and the barcodes only identify the food product; a separate database needs to be created to store the nutritional info associated with the product. Databases have been created so that users can input each ingredient to compute cumulative dietary information such as the number of calories per meal but this look-up process is very time consuming and often inaccurate as the ingredients are not known to the user.
The present solution solves this problem by encoding each menu item'"'"'s and sub-item'"'"'s nutritional information into a tag that can be scanned directly by a user using a mobile app food tracker and logging the coded information into the user'"'"'s daily food log. The user will be easily able to modify the portion size of each sub-item that is served with the item ordered, delete sub-items, add extras or make substitutions that can be ordered from the venue.
U.S. Provisional Patent Application No. 62/293,709 includes descriptions of the following aspects of the inventive system.
Mobile application wireframes, depicted in
Web application wireframes, depicted in
It should be noted, however, that unless specifically so limited, the scope of protection of the claims of the present application is by no means intended to be limited to the specific features depicted in the wireframe diagrams.
A. User Scenarios
Some user scenarios supported in the exemplary base product include:
1. Scan and Log User Dietary Information—
Using the mobile app, the user scans a tag associated with a food or beverage the user has consumed or plans to consume. The scanned tag is decoded to display the nutritional and other related information on the user'"'"'s mobile device. The user may modify the portion size or make substitutions (e.g., side salad instead of potatoes) where applicable to reflect what the user has/will actually consume. The user may save the decoded data, in modified or unmodified form, to the user'"'"'s consumption log. If the food is not tagged, the user may scan a barcode if available or search for the food from the database (including food served at large chain venues) to identify the relevant nutritional and allergen information.
2. Personal Profile Matching—
When the user registers with the system, the user will identify any dietary preferences (e.g., vegan, vegetarian, diabetic, etc.) or allergies (e.g., dairy, peanuts, etc.). When the user scans a tag with his/her mobile device, the user will be notified if the scanned item is believed to contain any allergens that are identified in his/her profile and whether the item is believed to match a dietary preference.
3. Food Item Creation—
Both individual users and venues may enter food items. There are several options for entry. Each ingredient in a prepared food may be individually entered to create a “Food” to be served. The ingredients may be looked-up by searching the database or by the barcode UPC associated with the ingredient. Ingredients may also be imported from certain recipe websites. Users will be provided with electronic scrapbooks that will enable them to copy recipes from notes, pictures, emails, etc. that can later be transcribed into the ingredient entry feature. As ingredients are added, their corresponding nutritional information is acquired through public sources or entered by the user. Allergen information is identified corresponding to the ingredient. The user may identify any dietary preferences associated with the food item. Venues will additionally be able to group sub-items (e.g., meat, potatoes, and vegetables) together in a manner in which they are served at the venue and identify appropriate substitutions (e.g., rice or side salad) or options (e.g. with your turkey sandwich you can have lettuce, tomato, onion, mustard, mayo, pickles, etc.). Users may also search for existing database foods, modify some or all of the ingredients, portion sizes, etc. to create a new food. Venues'"'"' ingredient entries may be private and venues optionally can omit ingredient entries and only enter the recipe name and corresponding nutritional and allergen info.
4. Creating and Printing Tags—
Using the web application, users may search for or otherwise identify Foods/Items they wish to tag. Once identified, the user can initiate the encoding process to create a tag for the identified food(s). The user may compile a number of tags along with the Food or Item name in a single print file so that venues may include inserts with their menus or provide signage with the tags within the venue, or other users can make them available to guests at a dinner party or pot luck, for example. The tags may also be stored and viewed in electronic form from both web and mobile apps and emailed electronically to others (web app) or shared with others (mobile app).
5. Consumption Log Review—
Using the web or mobile app, users may view their own consumption logs, filtering the log by date, date range, or other criteria. Users may also search for certain logged foods and modify the portion size, make a substitution, delete the entry, or enter it again for a new date/time. Venues will also be able to review the venue'"'"'s food items that have been logged by the venue'"'"'s own customers although the customers'"'"' identities/personal info may not be revealed.
A system administrator may enter recipes/ingredient information on behalf of registered venues and generate usage reports relating to, among other things, tags generated and scanned, recipes created and scanned, and feedback received from users.
B. Food/Item Creation
There are several options for users to create foods for recipes they prepare and for Venues to create Item and Sub-Items that reflect their menus.
1. Users preparing their own Foods
The user may enter new Foods in a number of ways in the web application.
Import Ingredients from Recipes Posted on Supported Websites.
The user can either enter the URL for the online recipe from the web app or when the user is viewing the recipe for the ingredients the user wants to import, the user can just click on a designated button from the user'"'"'s navigation or favorites bar. In either case, as long as the recipe site is supported (i.e., it has a public API or uses a standard metadata scheme), the ingredients will be automatically imported along with the name of the recipe (and corresponding amounts) into the database. If the imported ingredients are found in the database, the nutritional information will automatically be populated as well for relevant amounts and measurement units. If an imported ingredient is not found in the database, the user will be required to enter the nutritional information (described in subpart iii below). Allergens are identified and are not input by a user. The list of ingredients, amounts, measurement units, and nutritional and allergen info will be displayed following the import and any entry required and the user will save or clear the entry. The user will be prompted to enter a dietary preference associated with the new Food but the user is not required to enter the dietary preference and may save the new Food without doing so. After saving, all of the information is logged into the database as a new Food for that user.
Batch Import Ingredients from Recipes Posted on Supported Websites.
Users can list up to 10 URLs for recipes and the ingredients from each of those recipes along with the ingredient amounts and recipe names will be imported to the database. The same process described above will be implemented for each of the imported recipes. The database will log these new Foods in association with the user that imported them.
Manual Entry of Ingredients.
The user may enter ingredients from his/her own recipe. The Web wireframes show an example of the UI where the user would add a name for the new Food, each ingredient, the amount for each ingredient and the measurement units associated with the amount (See Enter a Food Page). As the user types in the ingredient, the web app will search the database and begin to list relevant matches. If the user finds a match for the intended ingredient, that match will be selected by the user and will populate the ingredient field. The amount and measurement units will be populated as well. The nutritional info for that ingredient will be displayed for the ingredient as well as any allergens or applicable dietary preferences. The user may change the amounts and measurement units. It should be understood that a variety of methods may be implemented to convert units such as a conversion table or lookups for ingredients having the desired unit match. Those changes will automatically adjust the nutrition information displayed to correspond to the new amounts and units. If the ingredient is not found in the database, the user will enter all applicable information: ingredient name, amount, measurement units, nutrition information, relevant serving size and number of servings for the nutritional values entered, and optionally any dietary preferences. If an ingredient has a barcode, the user may optionally enter in the UPC code and the ingredient name, amount, nutritional info, etc. will be displayed in the UI. Allergens are identified and are not input by a user. As each ingredient is entered the nutritional information is updated to reflect the cumulative nutritional information for all ingredients. The user can continue to add ingredients in this fashion until all of the ingredients for the recipe have been entered. If the user does not complete the input, s/he can save it to his/her Scrapbook and can come back to the same point at a later time. If the user completes the entry, the user saves the Food as a new Food and the ingredients, amounts, measurement units, nutritional info, serving size, number of servings, allergens and dietary references are saved to the database in association with the user that entered the Food. The user will be prompted to enter a dietary preference associated with the new Food but the user is not required to enter the dietary preference and may save the new Food without doing so. Other users should be permitted a way to add dietary preferences in association with any Product in the database.
Edit and Enter an Existing Food.
The user may search for a Food that has already been entered into the database. The user may use the “Find a Product Page” to search for a specific Food or may search his/her Consumption Log to find a Food that he or she already logged. When the Food is found, the user may select “edit” which will bring up the “Enter a Food Page” already populated with the existing Food information. The user may add, delete, or modify ingredients and resave the Food as a new Food associated with the user that made the edits. The same process as described in subpart iii is applicable here.
Enter Using the User'"'"'s Scrapbook.
Each user will have a Scrapbook. Using the web app, the user may open his or her scrapbook when entering ingredients for a new Food so that information saved to the user'"'"'s Scrapbook can be easily transcribed into the relevant fields on the Enter a Food Page as described in subpart iii. If a URL or multiple URLs are in the Scrapbook, they can be copied and imported as described in subparts i or ii above. As described with each of the entry methods above, the user may save the new Food once all of the information has been populated along with optional dietary preferences.
The user may save recipe info to his or her scrapbook from his or her mobile device but the user will not be able to enter new Foods via the mobile app. If the user is using a laptop or tablet, the user may use the web app as described above to enter a new Food. The user could also use the web app on his or her mobile phone but the user interface should not be optimized for these smaller form factors in the base product.
2. Entering Items and Sub-Items Served at a Venue
The venue entry is a superset of the user entry. In order for users to be able to make substitutions, delete sub-items, add extras etc. after scanning a tag, the venue must have its menu items along with all applicable sub-items stored in the database and all applicable substitutable sub-items or add-ons and any extras that may be available from that venue stored in the database. (In this context, “add-on” refers to a category of sub-items that are not substitutes but are things that customers can add to their order; “category” refers to the name of a group of sub-items that can be substituted for one another when ordering an item; “extras” refer to products that are available from a venue but are not listed on the menu; and “substitutes” are sub-items that can be substituted within an item for the default sub-item that is specified on the venue'"'"'s menu.) The Sample My Menu Pages, Sample Create My Menu Page, and Sample Create My Menu Page included in the Web wireframes should be reviewed along with this description.
Each venue may have different categories that make sense for the items it serves. The samples shown in the web wireframes are for a pizza restaurant. The customer can order a specific pizza that comes with a sauce, a cheese, a veggie and a meat or some combination of those. In that case, it might make sense to have 4 categories as shown in the samples. Alternatively there could be a single category of add-ons that include some or all the sauces, cheeses, veggies and meats. For example, there could be categories “sauces” and “cheeses” but add-ons that include all possible veggies and meats. It is up to the venue as to what categories to create and what sub-items or add-ons to include. In either case, it would be expected that the customer would order one of the specific pizza combinations and then might want to make a substitution and/or add-on a particular topping. By associating each menu item with appropriate substitutions and add-ons the customer will easily be able to log what he or she actually orders. There may also be a mechanism to input extras that the venue provides such that the user can easily search for and add these if consumed to the user'"'"'s Consumption Log.
Entering Menu Items.
Since a menu item is simply the name that the venue includes on its menu to define something to order, the nutrition information, allergens and dietary preferences are determined by the specific sub-items associated or grouped together to form an Item. In the pizza example, in addition to the sauces, cheese, etc., there would also be the pizza crust. Some venues might have multiple types of crust in which case a Category would need to be created but if there is only one type of crust, crust would always be included as a default sub-item with any Item. As another example, consider a venue that prepares a daily quiche. The quiche (the “Item”) has 2 sub-items, the filling and the crust. Assuming the daily quiche is homemade both the filling and the crust would be associated with a specific recipe for which the ingredients, amounts, measurement units, etc. would be added as descripted in Part 1 subpart iii above.
3. My Menu or My Foods
A user should be able to access the Foods he or she has entered and saved by clicking on My Foods from both the mobile and the web app. Similarly a venue should be able to click on My Menu from the web and mobile app and bring up its Menu Items, sub-items, Categories, add-ons and Extras.
C. Scanning and Logging
Scanning takes place solely from the mobile app but there are several other options for logging products into a user'"'"'s consumption log. The database stores ingredients from the USDA database and other available nutrition databases including groceries (bar-coded products) and foods available from certain large-chain restaurants. In addition, the database stores the user entered foods as well as the venue entered information. A product is anything in the database that has nutritional information associated with it. In other words, a product includes every food, menu Item, sub-item, add-on, extra, grocery, and chain restaurant food. In addition to scanning, a user can search for a product in the database and log the product or the user can search his or her foods or consumption log to find a food or previously consumed meal to log. The user may also scan a bar code on a grocery to include the grocery in the user'"'"'s consumption log.
Scanning a Tag and Logging a Venue Item
The mobile app Home page includes the “Scan a Tag” function which launches the QR code scanner. The user uses the scanner to scan a Tag generated for a Venue Item. The mobile app decodes a Tag. The decoded nutrition information is displayed as shown in the mobile wireframes for the entire Item. Each sub-item is shown for the Item Tag scanned along with options to modify the portion size, substitute another Sub-Item, or delete the Sub-Item. There should also be options to include an Add-On if there are Add-Ons and Extras (not shown). If the user chooses to modify the portion size, the Sub-Item alone will be shown with a portion size UI feature. The user adjusts the portion size to reflect what s/he has or will consume. The nutritional information for that Item will then update to reflect that the Sub-Item portion size was adjusted. The user can also choose the substitute option which will bring up the default Sub-Item and a list of sub-items that can replace the default sub-item. The user may select one of the listed sub-items which will then replace the default sub-item in the menu Item and the mobile app with update the nutrition app after the substitution is made. If there are Add-Ons or Extras, the user can click on those options in connection with an Item (not Sub-Item) and again a list would be presented to which the user can select the ones he or she has or will consume with the Item. Once the user has made all appropriate changes and additions, he or she may save the Item to his or her Consumption Log. In doing so, the time, date, Venue, Menu Item, Sub-Items with portion sizes, add-ons, if any, with portion sizes, Extras, if any, with portion sizes, along with the cumulative nutrition information will be save in the database in association with the user'"'"'s Consumption Log.
It should be understood that categories and extras may be used by individual cooks as well as venues for creating meals according to the present invention.
Scanning a Barcode and Logging a Grocery Product
The mobile app Home Page also includes the “Scan a Barcode” function which brings up the barcode scanner. The user uses the scanner to scan a barcode on a Grocery. The barcode is decoded to identify the UPC and the UPC is looked up in the database to bring up the nutritional information for the Grocery. The mobile app UI displays the name of the Grocery, the serving size and nutritional information along with an option to change the portion size. The portion size and nutrition update process is described above. If the user saves the Grocery to his or her Consumption Log, the time, date, Grocery name, UPC, amount, and nutritional info will be saved to the database for that user'"'"'s Consumption Log.
Logging an Existing Product or Food
The user can search for products or foods in a number of ways. Upon identifying an ingredient, grocery, venue item or chain restaurant item in the database, the user can change the portion size and log the applicable product into the user'"'"'s consumption log creating a new entry for that user along with the date, time, and name of the product. If the product is a venue item, the user will also be able to make substitutions, additions, and deletions. If the user searches for a food that has been entered by the user or any user, the user can elect to edit the food as described above. The food in modified or unmodified form may be logged by the user to his or her consumption log, creating a new entry with the date, time, and name of the unmodified food or new food, along with the applicable nutrition info.
Importing a Recipe
This section describes ways to implement the feature “Import recipe from existing website/API”.
Several ways of importing imply creating a “list of supported websites”. This means, that only recipes from sites in this list get imported directly to the app. It is possible to import recipes from unsupported websites to the app'"'"'s Scrapbook. This can be done using a browser extension, an embedded browser view, a website API, a mobile device “share” feature, or email.
Each module is described in detail below.
The database contains the following information:
Table contains information about each user in system, such as first and last name, unique user ID, email, password, allergies, dietary preferences etc.
Table contains detailed information about user dish consumption.
Table contains nutrition values for each food in database, such as Calories, Total Fat, Sodium, Protein, etc.
Table store food components grouped into recipes. For example—Burger: beef, red onions, extra-virgin olive oil, mayonnaise, salt, etc.
Table contain information about compatibility between foods and allergens, to produce allergy warnings.
App Server Components
- ASP.NET MVC—responsible for providing HTML, CSS, JS resources for web clients.
- ASP.NET Web API—REST API framework.
- Data-access layer, ORM: Entity Framework 6—provides object mapping to database entities.
- Business logic layer—classes that implement all application-specific logic.
Web Application Components
The web application uses an established web development framework as a base and follows the framework development guidelines and best practices. Example frameworks include Angular JS with additional plugins and directives, and Twitter Bootstrap 3. It should be understood that numerous other technical architectures may be used to implement the inventive system such as the architecture illustrated in
Mobile Application Components
The mobile application can be based on PhoneGap (also called Apache Cordova) or Xamarin to simplify cross-platform development. The same development framework used in the web application is preferably used to simplify development and reuse components where possible. The main features of the mobile app are:
Uses QR scanner PhoneGap plugin
For best performance, different plugins can be used for iOS and Android
Split into components according to framework
Accesses REST API for data.
QR Code Structure
The QR Code stores basic recipe nutrition information, allergy and dietary compliance data and recipe ID. To form a QR Code, these numbers are encoded as bytes and concatenated to a fixed-length number. It incorporates both Venue and Users.
The basic tag encoding may be implemented substantially in accordance with the following format and conversion to a QR code. A 2-byte value provides a maximum of 65535 different entries.
A QR-code with 32 binary encoded bytes:
cook:˜$ xxd 8 bytes
0000000: 0123 4567 89ab cdef 0123 4567 89ab cdef.#Eg . . . #Eg . . .
cook:˜$ cat 8 bytes|grencode-l L-8-o 8 bytes.png
The QR Code according to this format should not need to exceed about 0.5 inches when printed based on capability of user devices scanning/imaging technology. It should be understood that further compression may be achieved by predefining other features of the fields or by eliminating certain fields. It should be further understood that different encoding schemes will have better compression characteristics and may be used instead of QR encoding.
For enhanced scalability and extensibility, the service-oriented architecture (SOA) may be used. The high level overview of main services is depicted in
As described above and shown in
USDA National Nutrient Database for Standard Reference
Documentation and User Guide
info on the API
Tree nuts: http://www.kidswithfoodallergies.org/page/tree-nut-allergy. spx
The service-oriented architecture provides an ability to address application scalability and reliability needs. As each application feature is backed by a simple service, it can be easily scaled, without affecting other components. Moreover, as the services are loosely coupled (access only over HTTP Rest API), each service can be included/excluded from the system according to specific needs. Moreover, the SOA-based approach naturally blends with cloud-based solution deployment, which ensures even faster and simpler responses to increased load and hardware malfunctioning.
User Interface Designs for Mobile and Web Applications
As mentioned above,
In addition, in the illustrative embodiment, a first network service provider monitor 1100.1 is configured to enable a network service provider 1100 to monitor user logs and provide alerts and suggestions regarding general dietary trends. In addition, a second network service provider monitor 1100.2 is configured to enable a network service provider to evaluate a venue'"'"'s customer purchases and provide suggestions about when the venue should buy new supplies or to have specials to encourage sales of perishable foods. It be noted that the network service provider(s) is (are) not limited to people, as they could be completely automated.
In the illustrative embodiment of
In the illustrative embodiment of
The mobile tag reading system 900 of
The tag reading system 900 may also include a food item creation module 980 to enable the creation of nutritional tags for newly created foot items. A discovery module 930 is also included for providing the user with a list of network-registered venues based on the user'"'"'s current location and the user'"'"'s dietary preferences. This feature enables the user to select a nearby venue offering items compatible with the user'"'"'s dietary preferences.
The tag reading system may also include a user search module 950 to enable the user to search the user'"'"'s log, and to display information in the venue fields. This is especially useful in cases where the user is a customer of a specific venue. A menu display filter 960 is advantageously included to enable the user to scan a unique venue tag and view a personalized menu of only those items that meet the user'"'"'s dietary requirements. Also included is a consumer application 970 configured to use downloaded items to enable the user to substitute one item or sub-item with another item or sub-item. Finally, a local profile database 906 may also be included in the tag reading system. (It should be noted that querying of venue tags could go through the tracking log or the query could go right to the database 620 or 906 with the venue information with a request to match against certain user profile information contained in the user'"'"'s profile.)
In the description above, sub-items may be formed from one or more ingredients. If more than one ingredient is included, the ingredients are grouped together to form the sub-item. Items or menu items can include one or more sub-items. If more than one, the sub-items are grouped together to form the item. A user can make changes to the sub-items based on actual consumption. In some cases those changes could be to ingredients if the sub-item contains only a single ingredient, e.g. butter. Changes to the ingredient lists denote changes to a recipe, not necessarily the user'"'"'s consumption.
The true scope the present invention is not limited to the illustrative embodiments disclosed herein. For example, the foregoing disclosure of presently preferred embodiment of a tag reading system uses explanatory terms, such as tag capture device, decoder, and tracking log, which should not be construed so as to limit the scope of protection of the following claims, or to otherwise imply that the inventive aspects of the system are limited to the particular methods and apparatus disclosed. Moreover, as will be understood by those skilled in the art, many of the inventive aspects disclosed herein are based on software applications running on known and ubiquitous hardware processing platforms. These functional entities are, in essence, programmable data collection and processing devices that could take a variety of forms without departing from the inventive concepts disclosed herein. In some cases, the structural details of a given element, as well as the place of implementation, of an element described herein will be a designer'"'"'s preference based on presently available technologies and cost constraints, and not a hard requirement. Accordingly, except as they may be expressly so limited, the scope of protection of the following claims is not intended to be limited to the specific embodiments described above.