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&#39;s profile, and (c) alerts the customer to the presence of harmful ingredients or prescribed (recommended) food substance.

Description:
FIELD OF INVENTION  
         [0001]    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  
         [0002]    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.  
           [0003]    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.  
           [0004]    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.  
           [0005]    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.  
           [0006]    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.  
           [0007]    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.  
           [0008]    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&#39;s indications.  
           [0009]    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.  
           [0010]    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:  
           [0011]    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).  
           [0012]    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.  
           [0013]    Religious-observant, such as Kosher or Hindu  
           [0014]    Vegetarian  
           [0015]    Ingredient sensitivity, e.g. lactose intolerance or ingredient sensitivity  
           [0016]    Individuals managing an illness or disease such as digestive disorders or with chronic conditions, such as ulcers, which are aggravated by specific ingredients.  
           [0017]    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.  
           [0018]    Additionally, merely the process of reading food labels poses great difficulty for the following individuals:  
           [0019]    The visually impaired who presently must strain to read the fine print of nutritional labels.  
           [0020]    Individuals whose main language is not English.  
           [0021]    Individuals who suffer from learning disabilities, dyslexia, or struggle with literacy.  
           [0022]    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.  
           [0023]    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  
         [0024]    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&#39;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&#39;s profile, and alerts the customer to the presence of harmful ingredients or prescribed food substance.  
           [0025]    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.  
           [0026]    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).  
           [0027]    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  
       [0028]    [0028]FIG. 1: System Architecture (Physical View)  
         [0029]    Illustrates the system architecture and provides a physical view to every tier involved in the overall system.  
         [0030]    [0030]FIG. 2: Package Diagram  
         [0031]    Embodiment of the system blown up into logical packages that would function in tandem to work as a full-fledged system.  
         [0032]    [0032]FIG. 3: Client-side Class Diagram  
         [0033]    Schematic of the client-side interface and various objects that would participate at the user end.  
         [0034]    [0034]FIG. 4: Server-side Class Diagram  
         [0035]    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.  
         [0036]    [0036]FIG. 5: High Level Use Case Diagram for Customer  
         [0037]    Illustrates all possible scenarios under which the customer would interact with the system  
         [0038]    [0038]FIG. 6: High Level Use Case Diagram for Store Manager(s)  
         [0039]    Illustrates all possible scenarios under which the store manager(s) would interact with the system  
         [0040]    [0040]FIG. 7: High Level Use Case Diagram for Administrator  
         [0041]    Illustrates all possible scenarios under which the administrator would interact with the system  
         [0042]    [0042]FIG. 8: Deployment Diagram  
         [0043]    Illustrates the implementation level architecture providing a complete overview of how the system would be deploye  
     
    
     DETAILED DESCRIPTION OF THE INVENTION  
       [0044]    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-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 .  
         [0045]    Once the requests have been authenticated by the Firewall system  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.  
         [0046]    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.  
         [0047]    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.  
         [0048]    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  3 .  
         [0049]    [0049]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) 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.  
         [0050]    All operations requested by the client-end processor would be sent via simple http using browser protocols or an 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.  
         [0051]    All requests coming to the server are redirected to the 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.  
         [0052]    [0052]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.  
         [0053]    [0053]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—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.  
         [0054]    [0054]FIG. 3 represents the server-side class diagram for the system. After getting validated by the firewall system  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.  
         [0055]    [0055]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.  
         [0056]    [0056]FIG. 5 illustrates a high level use case diagram for customers interacting with the system.  
         [0057]    A 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.  
         [0058]    A customer  32  could manage his customer profile subject to authentication using the web application system.  
         [0059]    A 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 .  
         [0060]    A customer  32  would be able to Upload scanned data by an interface in a persistent data collection mode or manually.  
         [0061]    A customer  32  would be able to clear scanner data especially but not limited to personal barcode scanners.  
         [0062]    A customer  32  would be able to access the web application system  26  for future reference if need be.  
         [0063]    A 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 .  
         [0064]    [0064]FIG. 6 illustrates a high level use case diagram for administrator interacting with the system.  
         [0065]    An administrator  41  would be able to manage all stores, outlets and sales location  42  via the system.  
         [0066]    An administrator  41  would be able to manage all customers  43  via the system.  
         [0067]    An administrator  41  would able to manage product catalogs  44  on behalf of stores, outlets and sales locations where the consumables will be sold.  
         [0068]    An administrator  41  would be able to manage Allergy, sub allergy and other hazardous constituents  45  recognized and validated by the system.  
         [0069]    An 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.  
         [0070]    An administrator  41  would be strictly subjected to Authentication  47  to perform any of the administration activities.  
         [0071]    [0071]FIG. 7 illustrates a high level use case diagram for store manager(s) interacting with the system.  
         [0072]    store manager(s)  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.  
         [0073]    store manager(s)  48  would be able to manage store customer  53  data using their premises or services via the system.  
         [0074]    store manager(s)  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.  
         [0075]    store manager(s)  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.  
         [0076]    store manager(s)  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.  
         [0077]    store manager(s)  48  would be strictly subjected to Authentication  49  to perform any of the mentioned activities  50 ,  51 ,  52 ,  53  and  54 .  
         [0078]    [0078]FIG. 8 illustrates the implementation level architecture providing a complete overview of how the system would be deployed.  
         [0079]    [0079]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.  
         [0080]    The Client-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.  
         [0081]    The client-node  55  would present a different interface for Store Manager(s) and Administrator to perform activities illustrated in FIG. 6 and FIG. 7.  
         [0082]    The 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.  
         [0083]    The 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.  
         [0084]    The application server node  58  represents the location where all server-side components would be hosted and utilized by the web server node  57 .  
         [0085]    Additional components such as plug-in 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 .  
         [0086]    Additional Components such as 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.  
         [0087]    Additional Components such as Users  63  may reside in the application server node  58 . The Users  63  component would group all processes essential or invoked by/for users.  
         [0088]    Additional Components such as Products  64  may reside in the application server node  58 . The Products  64  component would group all processes essential or invoked for products.  
         [0089]    Components such as 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.  
         [0090]    The Back-End node would act as the central repository for UserDB  28  and ProductsDb  29 . In addition to this a MasterDB  66  would serve if needed to store information about the system in general.  
         [0091]    The Back-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 .  
         [0092]    an audible or visible alert sent to the user whenever an incompatibility is encountered. This would be detected and sent from the web server node  57  to the client node  55 .