« PreviousContinue »
(i9) United States
(12) Patent Application Publication
Messa et al.
(io) Pub. No.: US 2008/0004964 Al (43) Pub. Date: Jan. 3, 2008
(54) METHOD AND SYSTEMS FOR PERSONAL RESTAURANT ASSISTANT
(75) Inventors: Suzette Messa, Ben Lomond, CA (US); Mark Orttung, Menlo Park, CA (US)
GREENBERG TRAURIG, LLP (SV)
2450 COLORADO AVENUE, SUITE 400E
SANTA MONICA, CA 90404
A method and systems for a personal restaurant assistant. In one embodiment, the method, that may be implemented on a system, comprises identifying from an invoice for a group of diner's having ordered meals, charge items from the invoice to be allocated to one or more of the diners; transmitting over a network connection to a service provider, the identification of the charge items having been allocated to the one or more diners, to have calculated an allocated amount of the invoice for the one or more diners; and receiving over the network connection from the service provider, a calculated allocated amount of the invoice for the one or more diners.
Patent Application Publication Jan. 3,2008 Sheet 1 of 2 US 2008/0004964 Al
METHOD AND SYSTEMS FOR PERSONAL
 When a large group of people dine in a restaurant and each member of the party is paying their own bill, calculating each member's share of the total bill, including each member's share of the tip, can become very complex, particularly if there are shared items, such as appetizers and beverages. For example, sharing a bottle of wine. Usually a restaurant would prefer to bill the whole party as one group, and in some cases it will not bill each member of a group separately.
 What is clearly needed is a system and method for a personal restaurant assistant that can help diners in a large party calculate their share of the total bill in a simple, easy-to-use, and elegant manner.
SUMMARY OF THE DESCRIPTION
 One embodiment described herein provides a method, that may be implemented on a system, for a personal restaurant assistant. In one embodiment, the method, that may be implemented on a system, comprises identifying from an invoice for a group of diners having ordered meals, charge items from the invoice to be allocated to one or more of the diners; transmitting over a network connection to a service provider, the identification of the charge items having been allocated to the one or more diners, to have calculated an allocated amount of the invoice for the one or more diners; and receiving over the network connection from the service provider, a calculated allocated amount of the invoice for the one or more diners.
BRIEF DESCRIPTION OF THE DRAWINGS
 FIG. 1 presents a block diagram of a service platform, in accordance with one embodiment; and  FIG. 2 shows the flow process 200 of a transaction according to this embodiment of the present invention.
 In the following detailed description of embodiments, reference is made to the accompanying drawings in which like references indicate similar elements, and in which is shown by way of illustration of specific embodiments. These embodiments are described in sufficient detail to enable those skilled in the art to practice the techniques disclosed herein, and it is to be understood that other embodiments may be utilized and that logical, mechanical, electrical, functional, and other changes may be made without departing from the scope of the present inventions. The following detailed description is, therefore, not to be taken in a limiting sense, and the scope of the present disclosure is defined only by the appended claims.  FIG. 1 shows an example of a preferred embodiment of the present invention. A service platform 101, which could be, for example, a Rearden eServices Platform communicates through the Internet 103 with service providers SPl-SPn 102 a-n, in this example restaurants that may or may not have connections 104 a-n to the services platform. Users 105 a-n are connected to the Internet via communication pathways 106 a-n, which may typically be wireless devices such as cellular or other data devices. In some cases users may connect through services platform 101 to the
service provider; while in other cases the service provider may offer his own local URL, without relying on the availability of the services platform. However, some functions of this embodiment of the present invention may be distributed and actually performed at the services platform, while in other cases the services may be provided entirely by an insular service provider, such as SPx, who does not have an explicit connection to the services platform 101. In yet other cases, the connection of the users to a service provider SPn may rely on such methods as infrared or Bluetooth or WiFi and would not require an actual Internet connection.  FIG. 2 shows the flow process 200 of a transaction according to this embodiment of the present invention. As shown in this exemplary diagram, the flow starts at a point after the food orders are completed—that is, the meal is finished—and the waiter has closed the table ordering so it is ready for payment. It is the electronic equivalent of presenting a paper check, but is different in some key aspects, discussed below. At this point, all ordered (and billable) items have been entered into the service of the table number, typically, and a total is calculated, including applicable taxes, liquor and wine break-outs if required, and in some cases standard tips (as often are charged to larger groups).
 In step 201, a user would log in to a specific restaurant service, giving an ID in step 202, and a table number and sometimes a restaurant number in step 203. The ID may depend on the system, whether it's a permanent system ID or a temporary one-time-use ID, such as a code printed on an offering coupon, or a combination of meal ID and table number, printed on an ordering slip. In some cases the necessary information may be presented on a paper slip, like or together with a traditional check. In other cases, the waiter may beam a v-card via InfraRed beam or BlueTooth wireless or similar type of connection to the guest(s).  At step 204, the process branches. One user in a party may act as a "maitre d'," a user who checks all the items that have been ordered and assigns them to individual diners. In some cases, the person(s) may place the order electronically, for example by selecting on a web-style interface that pops up, allowing for full self-service. In yet other cases, the order may be pre-entered, for example on the way to a restaurant or while waiting to be seated. In yet different cases, a regular guest may have his "stored menu", which he may only slightly modify.
 If the party does not wish to use a maitre d' (no) the process for each diner moves to step 212, wherein a diner views the list of items that are on the bill for the party, and then in step 213 he selects the items for which he is responsible. In step 214, the diner specifies his portion of a shared (split) item, such as, for example, a shared salad (split 50 percent) or a bottle of wine (split 20 percent). In step 215, the diner may, optionally, add a tip. The current embodiment of this invention may offer various ways to calculate the tip. For example, one method may ask the diner to specify a percentage of his bill and then it may calculate the amount and add it to the bill. Another method of calculating the tip could simply ask the diner to grade the quality of his dining experience, for example, on a scale of 1 to 5, with 1 being "poor" and 5 being "excellent, and then the system could automatically calculate an appropriate tip for the grade. In step 216, the diner views his total bill, and in step 217, the diner selects his method of payment. If, for example, the diner and the restaurant both subscribe to e-pay service (y),