US20040078218A1

US20040078218A1 - System and apparatus for a consumer to determine food/medicine interactions on a real-time basis

Info

Publication number: US20040078218A1
Application number: US10/272,596
Authority: US
Inventors: Ellen Badinelli
Original assignee: SCANAVERT Inc; WES CONSULTING
Current assignee: SCANAVERT Inc; WES CONSULTING
Priority date: 2002-10-16
Filing date: 2002-10-16
Publication date: 2004-04-22
Also published as: JP2004038946A; US20080263011A1; US20110054930A1; US7805319B2; US20040006494A1; EP1363225A3; US8060383B2; EP1363225A2

Abstract

The system and apparatus for this invention is disclosed and declared to elaborate various actors, entities and other physical and logical units that collaborate and participate through multiple scenarios and mediums to detect harmful ingredients in food, OTC remedies and related consumables as specified by their nutritional and ingredients labels that may cause allergic reaction, health risks or any incompatibility between prescription drugs and normal food/ingredient consumption of an individual, on an automated, real-time system. The invention uses scanning based technologies (Barcode Scanning and Text Scanning) as well as non scanning based technologies via an interactive communication channel that could be used from a centralized access medium or an offline setup that (a) translates various terminologies used in nutritional and ingredients labels, (b) compares the composition information with the customer's profile, and (c) alerts the customer to the presence of harmful ingredients or prescribed (recommended) food substance.

Description

FIELD OF INVENTION

This invention relates to the system, method and apparatus for detecting harmful and hazardous ingredients, as mentioned in the nutritional and composition labels for food, beverage and drug products that may cause an allergic or undesired reaction, on a real-time automated basis, in places where these commodities are sold, prepared or served, including but not limited to supermarkets, restaurants and related business in the hospitality industry, camps, schools, manufacturers, health care and home care facilities. . . . For the purposed of this document, the term “store manager”, “administrator”, “actor” may be used interchangeably with the business environments described above.

BACKGROUND OF INVENTION

The American Academy of Allergy, Asthma and Immunology estimates that 2% of adults and 8% of children in the United States are afflicted with food allergies, an estimated total of 7 million Americans, according to the Food Allergy and Anaphylaxis Network. The allergic family represents an estimate 25 billion of grocery spending per year.

Allergies are the leading cause of chronic disease in United States costing the healthcare system 18 billion dollars annually. It is estimated that 150-200 people die each year from food allergies. Food allergy is the leading cause of anaphylaxis outside a hospital setting accounting for approximately 30,000 emergency room visits and 2,000 hospitalizations. The Epinephrine injection is the most effective method of treating anaphylaxis, however in a 1999 study conducted by Mt. Sinai Medical Center, only 32% of 101 parents administered it correctly, and only 21% of physicians administered it correctly.

In a 1999 study by the Mt. Sinai Medical Center, 91 sets of parents were asked to identify products whose ingredients their children must avoid. The most restricted food groups, peanut products and milk products, yielded correct answers in only 54% and 7%, respectively.

Indeed, reading labels to ensure they do not contain any harmful or unwanted product is a complex and time consuming process. There are more than 30 synonymous for milk and eggs only. By translating all synonyms relating to the same ingredient, the system will allow an immediate and reliable detection of all ingredient related to one specific allergy.

Moreover, some labels may identify an ingredient, such as mayonnaise, without specifying its sub-ingredient such as “egg” while individuals with egg allergies must avoid those products as well. The System will automatically perform this function of alerting consumers to harmful sub-ingredients that may not be specified clearly in the nutritional label.

The NCPI, National Council on Patient Information, estimates that 95% of individuals over 65, 32 million Americans, receive daily prescriptions, an average of 2.4 prescriptions per person. This group accounts for 13.4% of the population but accounts for 42% of total outpatient prescription spending.

In a study reported in the Jun. 12, 2002 issue of Annals of Emergency Medicine, elderly patients admitted to an urban hospital ER, the average number of prescriptions medications per patient was six. However, only 42% of these patients could correctly identify their medications. Additionally only 15% could identify their medication's indications.

Further, in a long-awaited national study conducted by the University of Wisconsin-Madison, (findings released by the FDA Jun. 18, 2002) regarding the distribution and “usefulness” of the medicine leaflets, one of every three leaflets received a low score, “1” or “2”, out of 5, for print size, print quality line spacing and ease of reading.

While the prime beneficiaries of the system are the allergy afflicted and individuals receiving prescription drugs, an a much larger segment of population stands to benefit as well:

Children whose physicians, neurologists, or other medical specialist, advocate removal of certain ingredients from their diet as it is perceived to interfere with learning, e.g. Feingold Diet recommends a gluten-free and a food colorings-free (Yellow #5 and Red #3) diet to improve the focus of children diagnosed Attention Deficit Disorder (ADD) and Attention Deficit Hyperactivity Disorder (ADHD).

Women who want to decrease the possibility of having a child with food allergies who are instructed by their doctor to refrain from consuming certain ingredients during their pregnancy.

Religious-observant, such as Kosher or Hindu

Vegetarian

Ingredient sensitivity, e.g. lactose intolerance or ingredient sensitivity

Individuals managing an illness or disease such as digestive disorders or with chronic conditions, such as ulcers, which are aggravated by specific ingredients.

Children, who may be receiving prescription medication for perceived learning disabilities, e.g. Ritalin or Adder all, who must refrain from certain OTC medications, or food/beverage ingredients that may inhibit, suppress the effectiveness of the prescription or its duration.

Additionally, merely the process of reading food labels poses great difficulty for the following individuals:

The visually impaired who presently must strain to read the fine print of nutritional labels.

Individuals whose main language is not English.

Individuals who suffer from learning disabilities, dyslexia, or struggle with literacy.

Any individual who falls under the American with Disabilities Act, ADA, whose manual dexterity compromises their ability to read labels, e.g. those suffering from Parkinson Disease, Palsy, and Muscular Dystrophy.

In summary, the present invention benefits any individual whose dietary regimen has specific restrictions or requirements for a variety of health and nutritional reasons or anyone who wishes to receive information in an automated format and thereby reduce the human error associated with correctly reading, deciphering and interpreting nutritional terminology.

SUMMARY OF INVENTION

Using mobile wireless scanners or stationary self-service terminals, customers will be able to scan their products and their barcode subscriber card and to receive real-time information related to the compatibility between the product they scanned and their profile. The profile contains information regarding consumer's allergies, prescriptions, chronic illness and conditions, or specific dietary requirements. The system translates various terminologies used in nutritional and ingredients labels, compares the composition information with the customer's profile, and alerts the customer to the presence of harmful ingredients or prescribed food substance.

The service generates an alarm for any substance or ingredient contained in a product, including Over The Counter substances or products (*), that will either cause a harmful or allergic reaction, interfere with the effectiveness of a prescription drug, or exacerbate symptoms associated with a chronic illness.

As an illustration, a parent shopping in a supermarket will be able to check that products he or she is purchasing are compatible with the identified allergy of his son (for example tree-nuts), or does not contain substances he or she wishes to avoid (for example: The Feingold Diet recommends removal of Yellow dye #5 in the diet of a child diagnosed with Attention Deficit Hyperactivity Disorder).

Using the same equipment, an elderly person will easily check the compatibility his or her prescriptions and any product purchased Over-The-Counter (*) or in the grocery aisles.

BRIEF DESCRIPTION OF DRAWINGS

FIG. 1: System Architecture (Physical View) [0028]
Illustrates the system architecture and provides a physical view to every tier involved in the overall system. [0029]
FIG. 2: Package Diagram [0030]
Embodiment of the system blown up into logical packages that would function in tandem to work as a full-fledged system. [0031]
FIG. 3: Client-side Class Diagram [0032]
Schematic of the client-side interface and various objects that would participate at the user end. [0033]
FIG. 4: Server-side Class Diagram [0034]
Schematic of the client-side interface and various objects that would participate at the server end, thereby correlating an n-tier architecture followed by the system. [0035]
FIG. 5: High Level Use Case Diagram for Customer [0036]
Illustrates all possible scenarios under which the customer would interact with the system [0037]
FIG. 6: High Level Use Case Diagram for Store Manager(s) [0038]
Illustrates all possible scenarios under which the store manager(s) would interact with the system [0039]
FIG. 7: High Level Use Case Diagram for Administrator [0040]
Illustrates all possible scenarios under which the administrator would interact with the system [0041]
FIG. 8: Deployment Diagram [0042]
Illustrates the implementation level architecture providing a complete overview of how the system would be deploye [0043]

DETAILED DESCRIPTION OF THE INVENTION

The system has been conceived to work in an n-tier architecture where the customers would be provided with multiple ways to interact with the system. FIG. 1 shows that the Client-[0044] end 1, would allow various devices like computers, PDA, mobile phones, static terminals installed in the store location and other handheld devices to scan item barcodes or nutrition labels and compare that information with their nutrition profile. The customer profile can be used synonymously with nutrition profile. The only constraint that the client interface has to abide by is a continuous connection to the Internet via their Internet Service Providers, ISP, or using the connection available at the store location. FIG. 1 illustrates the system architecture and provides a physical view to every tier involved in the overall system. The client end 1 would include devices as well as the client application that the customers would use to access the system. The client application could be browser-based accessed from desktops or kiosks, or small devices such as handhelds, mobile phones, or add-ons, that would be embedded into static terminals or small devices such as handhelds or mobile phones. The client-end 1 would interact with the system via an Internet connection 2. WAP enabled devices such as mobile phones and PDAs would interact with the system through a WAP gateway provided by ISPs. All requests for service would be authenticated for security by a Firewall system 3.
Once the requests have been authenticated by the Firewall system [0045] 3, they are received by the web application system that would normally be a cluster of web servers 4 serving the application in collaboration with application servers 5 and the backend database system 4 to perform all necessary processing. Once the requests have been processed, the web application would then create a static document that would contain the response to the request after the processing was completed. This response would then be redirected to the client interface that invoked the request through their respective devices. Typical requests made by the client-end 1 would be to register for the system, thereby enabling them to use scanning capable devices/equipment to get product information, upload device data (handheld scanners, static terminals, mobile phones and handheld devices with inbuilt scanners) and compare it against their profile.
The present invention is a method relating to the input, output and analysis of product information against a customer profile to provide data about potentially harmful substance or a substance that the customer chooses to avoid for health or other reasons. Food allergies and interference with prescription drugs are the most common examples of the necessity for harmful reaction detection to prevent consumption of ingredients not suited or intended for a specific individual. Disease or illness management, e.g., Diabetic, Celiac Disease, or religious observance e.g., Kosher, are other compelling reasons for this technology. [0046]
The invention focuses around using scanning technologies to enable users to use text scanners or barcode scanners to get information about potentially harmful substance or a substance that the customer chooses to avoid for health or other reasons. The data can be entered by individuals or others, e.g., pharmacist, with input devices capable of OCR-based scanning, by scanning the Customer Care Card followed by scanning the barcodes or ingredient labels of the items they are interested in. This information is then uploaded to the web application referred in FIG. 1 and a translation of data takes place. First the Customer barcode is interpreted followed by item barcodes. The customer barcode is then checked against the database to be associated with a customer profile. As stores might be using their own user database, a replication feature is provided to store managers and administrators to replicate their database with the central database of the system. The customer profile is then temporarily stored in the process space of the web-application. The item barcodes are then checked against the database. The item information (Name, Composition and Ingredients) are stored in the process space of the application. This is compared against the customer profile. The results are stored in a static document and then sent back to client application that invoked the request. The upload request can be made in two modes-Persistent data detection and manual upload. In persistent data detection mode, the device constantly waits for data. This is true for small devices such as a handheld or mobile phones, where large amount of data cannot be stored. As soon as data is received by the device, it is pushed via the Internet to the web application system for interpretation. This would mean that the user would view information about the items one by one. In manual upload mode, the user invokes the upload of data from the device to the web application system, thereby allowing them to make multiple scans and “push” a set of item barcodes to the system. [0047]
There is another aspect considered by this invention about persistent data scanning mode. Since the “push” takes place as soon as the scan occurs, the user profile has to be available before hand. This could imply that the client application to be used by handheld or mobile devices might ask the user to get authenticated before they start scanning items or allow a small plug-in to be installed in these devices that would store the customer profile before hand as stated in claim [0048] 3.
FIG. 2 refers to an embodiment of the package diagram, an illustration depicting all the necessary components grouped together based on their nature and the tier they are fitted in. The Customer (Client) [0049] Package 7 represents the client application that would be used to access the service. The client application could be browser based static WebPages served to computer terminals, kiosks, web enabled PDAs and mobile phones by the server based Web Application System or could be a software plug-in embedded in to the device itself thereby preventing the user to authenticate themselves each time they want to use the system. Mobile Processor, Handheld (Scanner) processor and terminal process 10, 9, and 8 respectively represent the processing that would be initiated by the client-application and serves mainly to imagine a scenario where multiple interfaces could be used by the customer to access the application.
All operations requested by the client-end processor would be sent via simple http using browser protocols or an [0050] XML package 11 on the client-end that would provide a more structured and platform-independent way to address all the requests from these different devices from a common platform. The XML package 11 represents the client-side process that would actually send data in and out of the client-application and therefore represents the purpose and not a necessity that using XML would be the only way. This package could be replaced by any package that would provide features fulfilling the purpose described in this section.
All requests coming to the server are redirected to the [0051] web application 12, which then interprets the requests and processes it using the components installed on the application server. A typical upload request would be redirected for parsing the Upload Parser package 13 that includes a set of components instantiated depending on the device information. After the parser package finishes filtering the barcodes, the first barcode is assumed to be a user barcode and is run against the database UserDB 15 to extract the customer profile. If matches are not found against the UserDB 15, the upload parser sends a message to the web application 12 to indicate an “abort”. If the customer profile is found then the rest of the barcodes are compared against the ProductDB 16 for item information. Thus, we get two set of data, namely customer profile comprising of the allergies, sub allergies, ingredients that the customer has to refrain from consuming and a set of ingredients and composition information for each item uploaded by this customer. This information is then taken by the data investigator package 14. The data investigator package 14 then runs a comparison between the two data explained earlier in this section and creates a result sheet comprising of any essential alerts against the items uploaded and extensive information for the cause of this alert. The result sheet is saved as a static document and sent back to the client-application via the web application.
FIG. 3 and FIG. 4 embody a clearer picture of the essential classes (components) by separating the client-side processes with the server-side processes. [0052]
FIG. 3 represents the client-side class diagram for the system. If we further break down the client-side processes, the client-side application would be broadly divided though not limited to three categories—[0053] Mobile_App 17 representing a client-side application that could be browser based or stand-alone and used by PDAs, mobile phones and other small interactive devices with computing features and an inbuilt monitor and scanner, HandHeld_App 19 representing a browser based application for users equipped with handheld personal barcode scanners that could be connected to a computer and Terminal_App 21 representing a client-side application installed on static terminals that could be used for by customers at store locations. Scanner_Addon 18, Scanner_Plugin 20 and Terminal_Plugin 22 modularizes the process specific to the retrieval of data from the scanning device and converting into an intelligible piece of information that could be send via XMLHTTP 23 to the web-application system.
FIG. 3 represents the server-side class diagram for the system. After getting validated by the firewall system [0054] 3, a server-side component receives data sent by the client-side XMLHTTP 23 into a server-side XMLHTTP 24. The Web Service 25 represents the complete server-side system that comprises of the cluster of web servers serving the web application 26, the application server hosting components such as the Upload_Parser 31, Data_Investigator 30 and util_Components 27 and the backend database server hosting UserDB 28 and Product_Db 29. WAP requests will be converted into an http request by the web service before going through the common web application system. The Upload_Parser 31 would make use of the UserDB 28 and ProductDB 29 by components provided the Util_Components 27. The WebApplication 26 would also make use of the UserDB 28 and ProductDB 29 by components provided the Util_Components 27. A typical upload request would be redirected for parsing the Upload Parser package 31 that includes a set of components instantiated depending on the device information. After the parser package finishes filtering the barcodes, the first barcode is assumed to be a user barcode and is run against the database UserDB 28 to extract the customer profile. If matches are not found against the UserDB 28, the upload parser sends a message to the web application 26 to indicate an “abort”. If the customer profile is found then the rest of the barcodes are compared against the ProductDB 29 for item information. Thus, we get two set of data, namely customer profile comprising of the allergies, sub allergies, ingredients that the customer has to refrain from consuming and a set of ingredients and composition information for each item uploaded by this customer. This information is then taken by the data investigator package 30. The data investigator package 30 then runs a comparison between the two data explained earlier in this section and creates a result sheet comprising of any essential alerts against the items uploaded and extensive information for the cause of this alert. The result sheet is saved as a static document and sent back to the client-application via the web application.
FIG. 5, FIG. 6 and FIG. 7 provide a schema for various broad use-cases depicting possible scenarios in which the actors Customers, Store Manager(s) and Administrator would interact with the system. An actor is an abstraction for entities outside a system, subsystem or class that interact directly with the system. A use case is a specification of sequences of actions, including variant sequences and error sequences, that a system, subsystem, or class can perform by interacting with actors. [0055]
FIG. 5 illustrates a high level use case diagram for customers interacting with the system. [0056]
A [0057] customer 32 could register to the web application system. This would create a barcode against the customer and also generate a customer care card. The customer 32 would then be able to download plug-in 18, 20 and use the system for scanning items and getting it validated.
A [0058] customer 32 could manage his customer profile subject to authentication using the web application system.
A [0059] customer 32 would scan item barcodes across stores or any recognized outlet where food and drugs are sold. The customer would also be able to use text scanners to scan nutrition and ingredient labels for products and validate it against his profile via the plug-in 18 and 19.
A [0060] customer 32 would be able to Upload scanned data by an interface in a persistent data collection mode or manually.
A [0061] customer 32 would be able to clear scanner data especially but not limited to personal barcode scanners.
A [0062] customer 32 would be able to access the web application system 26 for future reference if need be.
A [0063] customer 32 represents the end user who would be actually performing the scanning on items and/or uploading this information to the web application system 26.
FIG. 6 illustrates a high level use case diagram for administrator interacting with the system. [0064]
An [0065] administrator 41 would be able to manage all stores, outlets and sales location 42 via the system.
An [0066] administrator 41 would be able to manage all customers 43 via the system.
An [0067] administrator 41 would able to manage product catalogs 44 on behalf of stores, outlets and sales locations where the consumables will be sold.
An [0068] administrator 41 would be able to manage Allergy, sub allergy and other hazardous constituents 45 recognized and validated by the system.
An [0069] administrator 41 would be able to replicate the central database server components UserDB 28 and ProductDB 29 to be in sync with data available in external user and product databases hosted by the stores, outlets and sales locations.
An [0070] administrator 41 would be strictly subjected to Authentication 47 to perform any of the administration activities.
FIG. 7 illustrates a high level use case diagram for store manager(s) interacting with the system. [0071]
store manager(s) [0072] 48 would be able to manage their stores, outlets and sale location 54 via the system. This would only comprise of managing data related to their specific stores that are subject to change and would be essential to be modified in the system as well.
store manager(s) [0073] 48 would be able to manage store customer 53 data using their premises or services via the system.
store manager(s) [0074] 48 would able to manage store product catalogs 52 limited to their store locations, outlets and sales location via the system. This would be subjected only to data maintained specifically by/for the store or outlet.
store manager(s) [0075] 48 would be able to manage Allergy, sub allergy and other hazardous constituents 51 recognized and validated by the system. This would be subjected only to data maintained specifically by/for the store or outlet.
store manager(s) [0076] 48 would be able to replicate 50 the central database server components UserDB 28 and ProductDB 29 to be in sync with data available in external user and product databases hosted by the stores, outlets and sales locations. This would be subjected only to data maintained specifically by/for the store or outlet.
store manager(s) [0077] 48 would be strictly subjected to Authentication 49 to perform any of the mentioned activities 50, 51, 52, 53 and 54.
FIG. 8 illustrates the implementation level architecture providing a complete overview of how the system would be deployed. [0078]
FIG. 8 embodies the various tiers that would comprise the system. The various nodes represent physical deployment of various components at various levels in the system. [0079]
The Client-[0080] node 55 comprises of two essential parts. The core scanning and upload feature would be provided by the textreader component and barcodereader component better described earlier in this document as plug-in 18, 20 and 22. The second part in this node would be the client-application that would use plug-in 18, 20 and 22 to interface with the system. The client-node would be accessible and flavored to be used by multiple computer devices such as computer with a browser, WAP enabled phones and handhelds or static terminals installed onsite where the consumables will be sold.
The client-[0081] node 55 would present a different interface for Store Manager(s) and Administrator to perform activities illustrated in FIG. 6 and FIG. 7.
The [0082] firewall node 56 represents the complete set of security features provided at the server end of the system. This could be a set of hardware and software that may be manufacture, developed and supported by a recognized third party.
The [0083] web server node 57 represents the location where the web application 26 would be hosted. This may involve one or more than one web server working as a cluster. All static and dynamic webpages would be served from this node.
The [0084] application server node 58 represents the location where all server-side components would be hosted and utilized by the web server node 57.
Additional components such as plug-in [0085] installer 61 to provide embedded plug-in 18, 20 and 22 to be installed or served to the client-node may reside in the application server node 58.
Additional Components such as [0086] ScannerManager 62 may reside in the application server node 58. The ScannerManager 62 would track all scanners and maintain information regarding the use of the scanners.
Additional Components such as [0087] Users 63 may reside in the application server node 58. The Users 63 component would group all processes essential or invoked by/for users.
Additional Components such as [0088] Products 64 may reside in the application server node 58. The Products 64 component would group all processes essential or invoked for products.
Components such as [0089] DataManager 65 may reside in the application server node 58. The DataManager 65 component would group all processes essential or invoked for data replication as illustrated in FIG. 6 and FIG. 7.
The Back-End node would act as the central repository for [0090] UserDB 28 and ProductsDb 29. In addition to this a MasterDB 66 would serve if needed to store information about the system in general.
The Back-[0091] end node 59 would also include the infrastructure 60 that has to be in place to allow fast and reliable information to the components hosted by the application server node 58 and the web server node 57.
an audible or visible alert sent to the user whenever an incompatibility is encountered. This would be detected and sent from the [0092] web server node 57 to the client node 55.

Claims

What is claimed is:

1. A computer-based system for a customer to determine the compatibility of food/medicine interactions on an automated real time basis detecting harmful/incompatible ingredients in food, drugs and related consumables as specified by their nutritional and ingredients labels that may cause allergic reaction, health risks and any incompatibility with the normal food habits or prescribed drug intake of a specific individual comprising:

a. Any suitable scanning device, such as barcode or text scanner for reading barcode or text on the product's label capturing information by scanning the item(s);

b. Uploading the scanned information to a centralized or distributed system working with a single central repository or distributed repositories of product related information;

c. Mapping the information uploaded with the nutrition and ingredients data;

d. Comparing this data with the Customer Profile as explained in claim 2 with ingredients or composition that may be incompatible and/or cause allergic reaction or health risk and therefore avoided, or, conversely, is professionally recommended as a dietary requirement and therefore include;

e. Generating an alert, that signals the presence of harmful ingredients or required dietary ingredients, audibly with adjoining text.

2. A computer-based system for a customer to determine the compatibility of food/medicine interactions on an automated real time basis of claim 1 wherein Customer-Profile information is stored, and said information includes harmful food substance, allergic ingredients in food, drugs and related consumables incompatible and/or harmful to the customer-establishing an Avoidance Profile, and/or conversely, dietary requirements beneficial to the customer, establishing a Requirement Profile.

3. A computer-based system for a customer to determine the compatibility of food/medicine interactions on an automated real time basis of claim 1 wherein the information scanned is embedding Customer Profile information of claim 2 comprising:

a. A scanning device, such as barcode or text scanners, providing output information indicative of the information scanned; and

b. An application process that takes the data as an input and compare it with the stored Customer-Profile.

4. A computer-based system for a customer to determine the compatibility of food/medicine interactions on an automated real time basis comprising:

a. A text-based scanning device providing product information by scanning the nutrition and ingredients labels of item(s);

b. Handling this data via an embedded application as described in claim 3;

c. Comparing this data with the Customer Profile as explained in claim 2 for possible ingredients or composition that may cause allergy, health risks or might be prescribed as a healthy and necessary food substance; and

d. Generating an alert to the customer, in an audible and visual signal, as to the presence of harmful ingredients or prescribed food substance or restate 1 e above.

5. A computer-based system for a customer to determine the compatibility of food/medicine interactions on an automated real time basis comprising:

a. An application embedded into existing independent systems upon an intent of use by the system owner and to be able to execute upon the occurrence of an event (for e.g. Search request, Add to Cart etc) to capture product information related but not limited to nutritional composition and ingredients of item(s); and

b. Comparing this data with the Customer Profile as explained in claim 2 for possible ingredients or composition that may cause allergy, health risks or might be prescribed as a healthy and necessary food substance; and

c. Alerting the customer in the presence of harmful ingredients or prescribed food substance by sending an audible and visual signal.

6. A computer-based system to be used for processes explained in claim 1, claim 4, and claim 5 comprising: a centralized application that would facilitate users to create their own Customer Profiles through an interactive channel specifying information related but not limited to allergies, illnesses, prescriptions and dietary requirements.

7. A computer-based system to be used for processes explained in claim 1, claim 4, and claim 5 comprising: applications that would facilitate users to access their own Customer Profiles through different types of interactive channel, such as by scanning or swiping a barcode subscriber card, entering a login manually, recognizing finger prints as well as iris identification, or whatever auto-ID developing or evolving technology becomes standard, practiced or customary.