Abstract:
The illustrated embodiments integrate in-restaurant food ordering, paying, and reviewing using online and offline communications. The system, using offline beacons, detects which specific table a user sits at in a restaurant. A user orders and pays for the food while the system tracks what dishes the user orders. The system is enabled simply by placing the user&#39;s phone on the table; the user need not open an application or interact with the phone. Even if the user doesn&#39;t order or pay using the phone, the system will automatically save dining history. This system requires no human involvement to map the customer to the point-of-sale system. A transaction based review feature and a health care and nutrition tracking feature is included. By tracking and storing data on food ordered and reviews generated by the user, the system performs dining curation by tracking user&#39;s dining patterns to suggest food and restaurants.

Description:
BACKGROUND 
       [0001]    Field of the Invention 
         [0002]    The invention relates to the field of data processing systems of methods, specially adapted for commercial purposes. More specifically, it relates to the systems or methods specially adapted for a specific business sector, of services and restaurants. Namely, the fields of invention are CPC G0 6 Q, 50/12, 20/237, 10/02, 20/20, 20/322. 
         [0003]    The Problem 
         [0004]    There is no efficient system for ordering, paying, and reviewing food using user equipment. Prior art used online communications to allow a user to order, pay, review, and suggest food from user equipment. However, these past systems did not allow the user to interact with the system without interacting with the equipment. Further, there are too many restaurant applications for smartphones, none of which integrate all components together in a convenient way that empowers the user. This invention, by using online and offline communications, allows the system to track the user history by simply placing the phone on the restaurant table. This invention is a system that would be a digital waiter (with ordering and payment capabilities) integrated into the restaurant&#39;s computer service and ordering system using off-line (LAN)/online Bluetooth connections. This application also uses internet presentation of customer responses, menus, and input access from customers. Furthermore, by using offline beacons, the system can detect which specific table a user sits at in a restaurant such that the system can track what dishes the user orders while the user orders and pays for the food. combination that integrates several restaurant-based functions. Even if the user doesn&#39;t order or pay using the phone, the system will automatically save dining history. This system requires no human involvement to map the customer to the point-of-sale system. Furthermore, a transaction based review feature and a health care and nutrition tracking feature is included. By tracking and storing data on food ordered and reviews generated by the user, the system performs dining curation by tracking user&#39;s dining patterns to suggest food and restaurants. 
       BRIEF SUMMARY 
       [0005]    This illustrated embodiments of the invention include three overall apparatus or processes: (1) an apparatus of transaction enabled review and credit back for additional detail; (2) Restaurant ordering and review system; and (3) Method of suggesting consumable items based on ingredient and/or caloric history of the user. 
     
    
     
       BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS 
         [0006]    To easily identify the discussion of any particular element or act, the most significant digit or digits in a reference number refer to the Figure number in which that element is first introduced. 
           [0007]      FIG. 1  is a simplified block diagram showing one embodiment which illustrates a method  100  of allowing users to leave reviews of food or restaurants only when the user has actually purchased the dish or from the restaurant. 
           [0008]      FIG. 2  is a simplified block diagram showing another embodiment which illustrates a method  200 , which is the same as method  100  except that the transaction validation server and user review server are combined into one transaction enabled review server. 
           [0009]      FIG. 3  is a simplified flowchart illustrating yet another embodiment which illustrates a method  300  of allowing users to leave reviews of food or restaurants only when the user has actually purchased the dish or from the restaurant. 
           [0010]      FIG. 4  is a simplified block diagram showing one embodiment which illustrates a method  400  of using offline beacons to identify and couple a user to a specific table and to a specific restaurant. 
           [0011]      FIG. 5  is a simplified block diagram illustrating another embodiment which illustrates a method  500 , which is the same as method  400  except that the transaction validation server and user review server are combined into one transaction enabled review server. 
           [0012]      FIG. 6  is a simplified flowchart illustrating yet another embodiment which illustrates a method  600  of using offline beacons to identify and couple a user to a specific table and to a specific restaurant. 
           [0013]      FIG. 7  is a simplified block diagram showing an embodiment which illustrates a method  700  of using a computer medium to store and access food and health data of a user to suggest food at a particular restaurant the user it at with nutrition within the user&#39;s health restrictions. 
           [0014]      FIG. 8  is a simplified block diagram illustrating another embodiment which illustrates a method  800 , which is the same as method  700  except that the consumable item suggestion is derived not from an outside server, but by a consumable item suggestion module within the user equipment. 
           [0015]      FIG. 9  is a simplified block diagram illustrating yet another embodiment which illustrates a method  900 , which is the same as method  700  except that the user profile storage, food data storage, and dietary healthy data storage are stored within the user equipment. 
           [0016]      FIG. 10  is a simplified flowchart illustrating an embodiment which illustrates a method  1000  of how the computer medium can store and access food and health data of a user to suggest food at a particular restaurant the user it at with nutrition within the user&#39;s health restrictions. 
       
    
    
     DETAILED DESCRIPTION 
       [0017]      FIG. 1  is a block diagram which illustrates a method  100  of allowing users to leave reviews of food or restaurants only when the user has actually purchased the dish or from the restaurant. The user  105  utilizes the user equipment  140 , such as a smartphone or a tablet to communicate with the network  150 , such as a cellular network or the internet. The network  150  is communicated with the user review server  155  when the user wants to leave a review. However, the user  105  is first validated via communication step  125  with the transaction validation server  110 , which ensures the user  105  actually ordered at the restaurant or bought the dish that the user wants to review. When the network  150  accesses the user review server  120 , the review server  120  accesses the transaction validation server  110  to make sure the user  105  actually ordered from the restaurant or ordered the food or dish in question. This transaction validation server  110  also communicates with the point-of-sale system  130 , such as the point-of-sale of the restaurant, in order to receive validation of user purchase via communication step  115 . When the point of sale system  130  acknowledges a completed purchase by the user  105 , then it communicates with the transaction validation server  110  via communication step  115  to tell the server  110  the user  105  did in fact make the order. In this way, the point of sale system  130  can communicate indirectly with the network through communication step  135  if the user  105  chooses the place orders with the live in-store employee, as denoted in  FIG. 1  by using dotted lines for communication step  135 . As an optional feature, the point-of-sale system  130  can also communicate directly with the network  150  if the user  105  chooses to order using the user equipment  140 . Then, the transaction validation server  110  communicates with the user review server  120  via communication step  125  to tell the server that the user  105  is validated to leave a review. Then the user review server  120  communicates with the network  150  via communication step  155  to tell the network  150  to allow the user equipment  140  to access a review screen, to allow the user  105  to leave a review. 
         [0018]      FIG. 2  is a block diagram illustrating another embodiment of the method  200  of validating users to allow users to leave reviews of food or of restaurants only when the user has actually purchased the dish or from the restaurant.  FIG. 2  shows a different embodiment from  FIG. 1  in that the user review server  120  and the transaction validation server  110  of  FIG. 1 &#39;s embodiment are combined in  FIG. 2  to form a single transaction enabled review server  210 , eliminating the communication step  125 . The user  105  uses the user equipment  140 , such as a smartphone or a tablet to communicate via communication step  145  with the network  150 , such as a cellular network or the internet. The network  150  then communicates directly with the transaction enabled review server  210  via communication step  225  when the user  105  wants to leave a review. This server  210  can validate the transaction to ensure the user  105  actually ordered at the restaurant or bought the dish that the user  105  wants to review. This transaction enabled review server  210  can communicate with the point-of-sale system  130 , such as the point-of-sale of the restaurant, in order to receive validation of user purchase via communication step  215 . When the point of sale system  130  acknowledges a completed purchase by the user, then it communicates with the transaction enabled review server  210  via communication step  215  to tell the server  210  that the user  105  did in fact make the order. In this way, the point of sale system  130  can interact indirectly with the network at communication step  135 , as denoted by using dotted lines for step  135 . Then, the transaction enabled review server  210  communicates with the network  150  via communication step  225  to allow the user equipment  140  to access a review screen, to allow the user  105  to leave a review. 
         [0019]      FIG. 3  is a flowchart which illustrates how the system of  FIGS. 1 and 2  allows a user to leave a review only when validated. First, at step  310 , a server  110 ,  210  validates a transaction for a user  105  of the user equipment  140 . Then, at step  320 , the server  120 ,  210  communicates a transaction validation message to the network  150 . Next, at step  330 , the user or transaction enabled review server  120 ,  210  communicates at least one of the following to a user  105  of user equipment  140 : 1) a request for a simple review, and 2) an offer for credit back on at least a portion of the transaction in exchange for submission of a detailed review. Then, at step  340 , the user or transaction enabled review server  120 ,  210  communicates a simple review or a detailed review to the user equipment  140 . Then, at step  350 , the user review or transaction enabled server  120 ,  210  creates a detailed review receipt message if the user  105  submits the detailed review. At step  360 , the detailed review receipt message is sent to the user equipment  140 . Then, at step  370 , any of the following pieces of information are communicated to the user equipment  140  from the user or transaction enabled review server  120 ,  210 : 1) the data associated with credit back, 2) identification of a user, and 3) identification of a transaction. 
         [0020]      FIG. 4  is a block diagram which illustrates a system  400  of using beacons  460 ,  470  to identify and associate a user  105  to a specific table via communication step  475  and to a specific restaurant via communication step  465 . The identification of the user  105  at a specific table at a specific restaurant allows the user equipment  140 , without further action by the user  105  other than having the user equipment  140  on the table, to track the orders made by the user  105  in an offline setting. 
         [0021]    The offline restaurant beacon  460  includes a general beacon, such as a Bluetooth enabled beacon. Each restaurant has its own restaurant beacon  460 , which sends out a unique, encrypted identifier that is received and decrypted by the user equipment  140 , such that the user equipment  140  can identify in which restaurant that user  105  is sitting via communication step  465  to the user equipment  140 . 
         [0022]    The offline table beacon  470  includes a general beacon, such as a Bluetooth enabled beacon. Each table at a restaurant has its own table beacon  470 , which sends the information of which table the user  105  is sitting at via communication step  475 , through a unique, encrypted identifier that is received and decrypted by the user equipment  140 , such that the user equipment  140  can identify at which table that user  105  is sitting. 
         [0023]    Then, the user equipment  140  communicates online with the network  150 , such as a cellular network or the internet to directly communicate with the user review server  120  when the user  105  wants to leave a review. However, the user  105  is first validated via communication step  125  by the transaction validation server  110 , which ensures the user  105  has actually ordered at the restaurant or bought the dish that the user  105  wants to review. When the network  150  is trying to access the user review server  120 , the review server  120  accesses the transaction validation server  110  to make sure the user  105  actually ordered from the restaurant or ordered the dish in question. This transaction validation server  110  can also communicate with the point-of-sale system  130 , such as the point-of-sale system of the restaurant, in order to receive validation of user purchase via communication step  115 . When the point-of-sale system  130  acknowledges a completed purchase by the user  105 , it then communicates with the transaction validation server  110  via communication step  115  to tell the server  110  the user  105  did in fact order the dish. In this way, the point of sale system  130  can communicate indirectly with the network at communication step  135  if the user chooses to place orders with the live in-store employee, as denoted by the use of dotted lines. As an optional feature, the point-of-sale system  130  can also communicate directly with the network  150  if the user  105  chooses to order using the user equipment  140 . If the user  105  elects to use the optional feature to communicate directly with the network  150  by ordering using the user equipment  140 , then a menu storage server  490  will interact with the network  150  via communication step  485  to allow the user  105  to access the menu information. This menu storage server  490  then communicates with the point of sale system  130  to allow the user  105  to also pay using his or her user equipment  140 . 
         [0024]      FIG. 5  is a block diagram which illustrates a similar embodiment to that in  FIG. 4 , where the difference is that the transaction validation server  110  and the user review server  120  are combined into the transaction enabled review server  210 . 
         [0025]      FIG. 5  shows the system  500  of using beacons  460 ,  470  to identify and associate a user  105  to a specific table via communication step  475  and to a specific restaurant via communication step  465 . The identification of the user  105  as a specific table at a specific restaurant allows the user equipment  140 , without further action by the user  105  other than having the user equipment  140  on the table, to track the orders made by the user  105  in an offline setting. 
         [0026]    The offline restaurant beacon  460  includes a general beacon, such as a Bluetooth enabled beacon. Each restaurant has its own restaurant beacon  460 , which sends out a unique, encrypted identifier that is received and decrypted by the user equipment  140 , such that the user equipment  140  can identify in which restaurant that user  105  is sitting via communication step  465  to the user equipment  140 . 
         [0027]    The offline table beacon  470  includes a general beacon, such as a Bluetooth enabled beacon. Each table at a restaurant has its own table beacon  470 , which sends the information through a unique, encrypted identifier that is received and decrypted by the user equipment  140 , such that the user equipment  140  can identify at which table that user  105  is sitting, 
         [0028]    Then, the user equipment  140  communicates online with the network  150 , such as a cellular network or the internet to communicate directly with the transaction enabled review server  210  when the user  105  wants to leave a review, to ensure the user  105  actually ordered at the restaurant or bought the dish that the user  105  wants to review. This transaction enabled review server  210  can also communicate with the point-of-sale system  130 , such as the point-of-sale system of the restaurant, in order to receive validation of user purchase via communication step  215 . When the point-of-sale system  130  acknowledges a completed purchase by the user  105 , it then communicates with the transaction validation server  210  via communication step  215  to tell the server  210  that the user  105  did in fact order the dish in question. In this way, the point of sale system  130  can communicate indirectly with the network  150  at communication step  135  if the user  105  chooses to place orders with the live in-store employee, as denoted by the use of dotted lines for communication step  485 . As an optional feature, the point-of-sale system  130  can also communicate directly with the network  150  if the user  105  chooses to order using the user equipment  140 . If the user  105  elects to use the optional feature to communicate directly with the network  150  by ordering using the user equipment  140 , then a menu storage server  490  will interact with the network  150  via communication step  485  to allow the user access to the menu information. This menu storage server  490  can then communicate with the point of sale system  130  to allow the user to also pay using his or her user equipment  140 . 
         [0029]      FIG. 6  is a flowchart which illustrates how the offline beacon systems of  FIGS. 4 and 5  associate a unique table identifier with at least one order, allow the user equipment to not only store data on orders but also allow the user  105  to order and pay from the user equipment  140 . First, at step  610 , the user equipment  140  communicates with the network  150  to download menu items from a menu storage device  490 . Then, at step  620 , the user equipment  140  presents the menu items to the user  105  on the user equipment  140 . Next, at step  630 , the user equipment  140  accepts at least one order compromising at least one of the menu items from at least one user  105 . Then, at step  640 , the offline beacons  470  associate a unique table identifier with at least one order. Then, at step  650 , the user equipment  140  communicates with the network  150  to send at least one order to the point-of-sale system  130 . At step  660 , the user equipment  140  receives a bill for at least one order from the point-of-sale system  130 . Then, at step  670 , the user equipment  140  receives a request for a simple review from the user or transaction enabled review server  120 ,  210  after validation of at least one transaction. Then, at step  680 , the user equipment  140 , accepts at least one review input from the user  105 . At step  690 , the user equipment  140  communicates with the network  150  to send at least one review input to at least one user or transaction enabled review server  120 ,  210  using network  150 . 
         [0030]      FIG. 7  is a block diagram of one embodiment illustrating how a computer stores and accesses food and health data of a user  105  to suggest food at a particular restaurant where the user  105  is with suggestions compliant with the user&#39;s health restrictions. 
         [0031]    First, the user  105  inputs commands to the user equipment  140 . One option is for the user  105  to select a food item from a restaurant&#39;s menu  710 . Then, after selecting this item  710 , the user equipment  140  communicates the selection to the network  150  via communication step  145  to order the selected item  710  using point of sale software  130  via communication step  135 ;store the selected item  710  as a part of the user&#39;s profile on the user profile storage server  760  via communication step  767 ; store the selected item on the food data storage server  770  via communication step  777 ; send the selected item&#39;s nutritional information to a health organization server  790  via communication step  797  to either become part of the medical record of the user  105  or part of an overall nutrition information collection for disease prevention. 
         [0032]    Alternatively, the user  105  could use the user equipment  140  to communicate with a consumable item suggestion server  720  using the network via communication steps  145  and  755 . The consumable item suggestion server  720  processes the request and suggests a food item back to the user  105  after choosing the item using an algorithm that weighs one of more of the following: the dietary health data storage  780  of the user  105 , the food data history of the user  770 , and/or the user profile  765 . This consumable item suggestions server  720  can also communicate with the point-of-sale system  130  via communication step  725  to allow the user  105  to pay for the suggested item using the user equipment  140 . 
         [0033]      FIG. 8  shows a similar embodiment to that of  FIG. 7 , where the difference is that the consumable item suggestion is derived not from an outside server  720 , but by a consumable item suggestion module  820  within the user equipment  840 . 
         [0034]      FIG. 8  is a block diagram of an embodiment illustrating how a computer stores and accesses food and health data of a user  105  to suggest food at a particular restaurant where the user  105  is with menu selections compliant with the user&#39;s health restrictions. 
         [0035]    First, the user  105  communicates with the user equipment  840 . One option is that the user  105  uses the user equipment  840  to select a food item from a restaurant&#39;s menu  710 . Then, after selecting this item  710 , the user equipment  840  communicates with the network  150  via communication step  145  to: order the selected item  710  using point of sale software  830  via communication step  835 ; store the selected item  710  as a part of the user&#39;s profile on the user profile storage server  760  via communication step  767 ; store the selected item on the food data storage server  770  via communication step  777 ; send the selected item&#39;s nutritional information to a health organization server  790  via communication step  797  to either become part of the dietary health data storage  780  of the user  105 , or part of an overall nutrition information collection for disease prevention. 
         [0036]    Alternatively, the user  105  uses the user equipment  840 , which includes the consumable item suggestion module  820  in the form of an application stored within the user equipment  840 . The consumable item suggestion module  820  processes the request and suggests a food item back to the user  105  after choosing the item  710  using an algorithm that weighs one of more of the following: the dietary health data storage  780  of the user, the food data history of the user  770 , and/or the user profile  865 . This consumable item suggestions module  820  may also communicate with the point-of-sale system  830  via communication step  825  to allow the user  105  to pay for the suggested item  710  using the user equipment  840 . 
         [0037]      FIG. 9  is a block diagram which illustrates a similar embodiment to  FIG. 7  and  FIG. 8 , where the difference is that the consumable item suggestion module  820  is located within the user equipment  940  along with the user profile storage  960 , the food data storage  970 , and the dietary health data storage  980 . 
         [0038]      FIG. 9  illustrates how a computer stores and accesses food and health data of a user  105  to suggest food at a particular restaurant where the user  105  is with nutrition compliant with the user&#39;s health restrictions. 
         [0039]    First, the user  105  communicates with the user equipment  940 . One option is that the user  105  uses the user equipment  940  to select a food item from a restaurant&#39;s menu  710 . This selected item  710  is ordered by the user equipment  940  by directly communicating with the point of sale system  130  via communication step  935 A. The selected item  710  is then stored on the user equipment  940  as a part of the user&#39;s profile on the user profile storage server  960 , or on the food data storage server  970 , or as part of the dietary health data storage  980  of the user  105 . 
         [0040]    Alternatively, after selecting an item, the user equipment  940  communicates with the network  150  via communication step  145  to order the selected item  710  using point of sale system  130  via communication step  935 B, or sends the selected item&#39;s nutritional information to a health organization server  790  via communication step  797  to become part of the user&#39;s medical record, or part an overall nutrition information collection for disease prevention. 
         [0041]      FIG. 10  is a flowchart which illustrates how a computer stores and accesses food and health data of a user  105  to suggest food at a particular restaurant where the user  105  is with nutrition compliant with the user&#39;s health restrictions. 
         [0042]    First, at step  1010 , the user equipment  140 ,  840 ,  940  accesses a user profile from a user profile storage device either a separate server  720  as depicted in  FIG. 7  or as a part or the user equipment  840 ,  940  as depicted in  FIGS. 8 and 9 , comprising at least one previous event for the user  105 . Then, at step  1020 , the user equipment  140 ,  840 ,  940  accesses caloric ingredient information from at least one food data storage device  770 ,  970 . At step  1030 , user  105  selects at least one consumable item. Alternatively, at step  1040 , a consumable item suggestion algorithm either a separate server  720  as depicted in  FIG. 7  or as a component of the user equipment  840 ,  940  as depicted in  FIGS. 8 and 9  suggests at least one consumable item to user  105 . Then, at step  1050 , the user equipment  140 ,  840 ,  940  accepts at least one selected consumable item from user  105 . At step  1060 , the user equipment  140 ,  840 ,  940  creates a new event comprising ingredient information of the selected item. Then, at step  1070 , the user equipment  140 ,  840 ,  940  communicates the new event to the user profile storage device  760 ,  960 .