METHOD AND APPARATUS FOR REMOTE ORDER AND PICKUP
The present application is a continuation-in-part application of commonly-owned, co-pending U.S. Patent Application No. 09/166,339 entitled "METHOD AND APPARATUS FOR MAINTAINING A CUSTOMER DATABASE USING LICENSE PLATE SCANNING", filed on October 5, 1998, which is incorporated herein by reference as part of the present disclosure.
FIELD OF THE INVENTION The present invention generally relates to remote ordering systems, and in particular, to the efficient fulfillment of orders received from a location remote from the point of pick up.
BACKGROUND OF THE INVENTION Technology has advanced to a point where everyday commercial transactions are routinely conducted using communications and computer technology. For example, consumers find ordering via the telephone or the Internet a convenient means of shopping. In particular, ordering from a location that is remote from the store (e.g. ordering from home) can reduce the waiting time at the store. In addition, there are often incentives, such as cheaper prices or bonuses, for conducting commercial transactions using communications and computer technology. The incentives are primarily due to the reduction in costs to the store.
Commercial transactions that involve the remote ordering of an item typically involve placing the order and the subsequent pick up or delivery of the item. Order placement is facilitated by a number of means, including (1) person-to-person telephone ordering; (2) telephone ordering using audio response units and; (3) facsimile transmission; and (4) remote ordering via a computer and communications network, such as the Internet. Traditionally, the pick up of the remote order requires the consumer to travel to the place where the order is fulfilled and pick up the order. Delivery, of course, simply requires that the item be sent to the consumer at a specified location.
One problem associated with remote ordering of food is the inability to efficiently coordinate the fulfillment of the order with the order pick up. The remote ordering is generally done in advance of the pick up of an item. However, the arrival time of the consumer may vary widely, making a precise pick up time impossible to calculate. It is not desirable to have the prepared food sit for long periods of time awaiting pick up. This may result in degradation of the quality of the cooked food item. To address the problems with the unpredictability of the pick up time of merchandise, others have proposed delaying the fulfillment of a remote order by a predetermined amount of time. One such solution is disclosed in U.S. Patent No. 5,602,730 issued to Coleman et al. In Coleman et al., after receiving an order, a supply system supplies the desired items to the customer after a predetermined amount of time has passed. This solution still does not provide acceptable results because the predetermined time cannot always be predicted with a sufficient amount of precision to provide an efficient and desirable result. Therefore, a need exists for a method and apparatus for remote order and pick up that efficiently and precisely times the fulfillment of an order to coincide with the pick up of items associated with the order.
SUMMARY OF THE INVENTION The present invention comprises a method and apparatus for remote order and pick up of a food item.
In accordance with the present invention, an order server receives an order for one or more food items for a customer. The order is received from a first location such as from a customer's home via a telephone or computer. The order server stores data representing the order for future use when the customer arrives at a restaurant to pick up the order. When the customer arrives at a second location (i.e. the location of the restaurant), he is identified by for example, reading his license plate or another customer identifier. Then the food items are prepared (e.g. cooked and packaged). Thus, the food items are timely prepared only when the customer is ready for them.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is a block diagram of an apparatus for remote order and pick up in accordance with the present invention.
FIG. 2 is a block diagram of an order server in accordance with the present invention. FIG. 3 is a block diagram of a store server in accordance with the present invention.
FIG. 4 is a layout of a customer database in accordance with the present invention.
FIG. 5 is a layout of a restaurant database in accordance with the present invention.
FIG. 6 is a layout of a restaurant menu price database in accordance with the present invention.
FIG. 7 is a layout of a restaurant suggestive sell database in accordance with the present invention. FIG. 8 is a layout of a license plate profile database in accordance with the present invention.
FIG. 9 is a layout of a transaction database in accordance with the present invention.
FIG. 10 is a layout of an inventory database in accordance with the present invention.
FIG. 11 is a layout of a remote order database in accordance with the present invention.
FIGS. 12A - C are a flowchart of a method for order registration in accordance with the present invention. FIG. 13 is a flowchart of a customer analysis and transaction method in accordance with the present invention.
FIG. 14 is a flowchart of an order fulfillment method in accordance with the present invention.
DETAILED DESCRIPTION OF THE INVENTION
FIG. 1 is a block diagram of an apparatus 100 provided in accordance with the present invention. The apparatus 100 includes a plurality of remote ordering
stations 110, 111 and 112. The remote ordering stations 110, 111 and 112 are used by customers to place orders for items. A remote ordering station may be a telephone or a computer, such as those based on the Intel(R) Pentium(R) microprocessor, or a Palm VII wireless hand held organizer by Palm Computing. Any or all of the remote ordering stations 110, 111 and 112 may include a GPS (Global Positioning System) device for determining the position of the ordering station on the Earth. A remote ordering station may also be a kiosk that accepts payment (e.g. cash or credit card) and thus allows the customer to prepay from a location such as a mall where the kiosk is located. Although three remote ordering stations are shown in FIG. 1 , any number of remote ordering stations may be included.
A network 116 connects the remote ordering stations 110, 111 and 112 with an order server 120. Order server 120 is a computer that receives and stores orders from the remote ordering stations 110, 111 and 112. A store server 124 is operably connected to order server 120 via a communications channel such as a network, including a local area network, wide area network, the Internet or a telephone network. Store server 124 receives orders from order server 120 for processing and fulfillment. A plurality of point of sale ("POS") terminals 126, 127, 128 and 129 are connected to store server 124. The point of sale terminals 126, 127, 128 and 129 facilitate the taking of orders from customers at store 122. POS terminals 126, 127, 128 and 129 receive point of sale data, such as orders, and calculate the purchase prices associated with orders, as is well known in the art. Store server 124 and point of sale terminals 126, 127, 128 and 129 each are typically located at store 122. The remote ordering stations 110, 111 and 112 are typically located remotely from store 122. In an alternate embodiment, a single computer may perform the functions of the order server 120 and the store server 124.
FIG. 2 is a block diagram of order server 120. Order server 120 includes a CPU 200 operably connected to a data storage device 212 (e.g. RAM, ROM, hard disk or a combination thereof), as is typical of conventional computer systems. A communications port 206 is operably connected to CPU 200 and to network 116 via communication medium 208. Communications port 206 is also connected to store server 124 via communication medium 210. In one embodiment, communications port
206 may be adapted to receive signals from and transmit signals to the Internet, as will be understood by those skilled in the art.
Data storage device 212 stores customer database 218, restaurant database 220, restaurant menu price database 222 and restaurant suggestive sell database 224. Restaurant database 220 includes data associated with restaurants. Restaurant menu price database 222 includes data for the menu food items and corresponding prices of a restaurant. Restaurant suggestive sell database 224 includes data associated with marketing promotions and the requirements for offering the promotions. Customer database 218 includes data associated with customers. Data storage device 212 also stores a program which directs the CPU 200 in accordance with the present invention and in particular with the methods described herein.
FIG. 3 is a block diagram of store server 124. As is typical of computers, store server 124 includes a CPU 300 operably connected to data storage device 302. An input device 306 is operably connected to CPU 300. Input device 306 may be, for example, a bar code reader, a card reader, an input key pad, a microphone, a radio frequency identification device (e.g. a radio frequency transponder such as those used in the E-Z Pass system of MFS Transtech, the Mobil SpeedPass system of Mobil Corporation or the Texas Instruments TIRIS system) or a biometric identification device. A weight sensor 310 is operably connected to CPU 300. The weight sensor 310 generates a signal in response to detecting the presence of a vehicle imposing weight on the weight sensor 310. POS terminals 126, 127, 128 and 129 and a digital menu board 312 are operably connected to CPU 300. The digital menu board 312, which may be the Digital MenuBoard™ by Siren Technologies of Chicago, IL, allows information (e.g. promotional messages, food items and/or prices for food items) to be displayed.
License plate reader 308 is operably connected to CPU 300. License plate reader 308 includes optoelectronic camera 314, CPU 316 and a data storage device 318 that stores an optical character recognition program 319. License plate reader 308 operates, in a manner well known to those of skill in the art, to read and identify characters (e.g. letters and digits) and on license plates. The optoelectronic camera 314 captures an image of the license plate and the optical character recognition program 319 directs the CPU 316 to process the image. License plate reader 308 may
be located such that it captures and processes images of license plates as cars pass through a drive-through lane. License plate readers are described in the parent application, U.S. Patent Application No. 09/166,339 entitled "METHOD AND APPARATUS FOR MAINTAINING A CUSTOMER DATABASE USING LICENSE PLATE SCANNING", filed on October 5, 1998.
Data storage device 302 stores a license plate profile database 330, a transaction database 332, an inventory database 338 and a remote orders database 340. Data storage device 302 also stores a program 320 that directs the CPU 300 in accordance with the present invention. License plate profile database 330 includes records of customers that are identified by their license plate. Transaction database 332 includes records of orders of customers identified by a license plate identifiers. Inventory database 338 contains information such as items available, price and the number of items on hand or in inventory. Remote orders database 340 includes records of remote orders of customers. The databases stored by the store server 124 may also, or alternatively, be stored by the order server 120. The order server 120 may store copies of the databases from several store servers, and may further aggregate corresponding databases from several store servers.
Referring to FIG. 4, a table 400 represents an embodiment of the customer database 218 (FIG. 2). The table 400 includes records 414, 416, 418, 420 and 422, each defining a customer that has placed an order with the order server 120 (FIG. 1). It will be understood by those skilled in the art that the table 400 may include any number of records. The table 400 also defines fields for each of the records 414, 146, 418, 420 and 422. The fields specify (i) a customer identifier 401 that uniquely identifies the customer, (ii) a name 402 of the customer, (iii) an address 404 of the customer, (iv) a number of orders made 406 by the customer, (v) a number of orders made this month 408 by the customer, (vi) a credit card number 412 which may also be the customer identifier as described above, and (vii) a default order 413 of the customer. Those skilled in the art will understand that a number of other fields may specify further information regarding a customer. For example, past orders of the customer may be stored to indicate the historical preferences of that customer.
The customer may be identified by various types of customer identifiers. Consequently, the contents of the field 401 may be of various types. For example, the field 401 may store a credit card number, as shown in records 414, 420, license plate characters (e.g. letters and digits), as shown in record 416, or arbitrary numbers as shown in records 418, 422.
Referring to FIG. 5, a table 500 represents an embodiment of the restaurant database 220 (FIG. 2). The table 500 includes records 504, 506, 508 and 510, each defining a restaurant. It will be understood by those skilled in the art that the table 500 may include any number of records. The table 500 also defines fields for each of the records 504, 506, 508 and 510. The fields specify (i) a restaurant identifier 501 that uniquely identifies the restaurant, (ii) an address 502 of the restaurant, and (iii) a restaurant chain identifier 504 that indicates a group of other affiliation of the restaurant. Those skilled in the art will understand that a number of other fields may specify further information regarding a restaurant. FIG. 6 is an illustration of an exemplary record 601 of restaurant menu price database 222 (FIG. 2). Field 600 contains the restaurant identifier of a restaurant. The record 600 also includes entries 608, 610, 612, 614, 616, 618 and 620, each defining a food item sold by the specified restaurant. It will be understood by those skilled in the art that the table 600 may include any number of entries. The table 600 also defines fields for each of the entries 608, 610, 612, 614, 616, 618 and 620. The fields specify (i) a name of the food item 602, (ii) a price 604 of the food item, and (iii) a number available 606 of the food item. Those skilled in the art will understand that a number of other fields may specify further information regarding a food item. FIG. 7 is an illustration of an exemplary record 701 of restaurant suggestive sell database 224 (FIG. 2). Field 700 contains the restaurant identifier of a restaurant. The record 700 also includes entries 708, 710, 712, 714 and 716, each defining a condition under which to provide a suggestive sell offer to the customer. It will be understood by those skilled in the art that the table 700 may include any number of entries. The table 700 also defines fields for each of the entries 708, 710, 712, 714 and 716. The fields specify (i) a condition identifier 702 that uniquely identifies the suggestive sell condition, (ii) a description 704 of the corresponding suggestive sell offer, and (iii) purchase requirements 706 defining the suggestive sell condition. Those
skilled in the art will understand that a number of other fields may specify further information regarding a food item. When a set of purchase requirements are satisfied, the corresponding suggestive sell offer is provided to the customer. For example, the field 704 for the entry 708 indicates an offer for "free fries". Corresponding purchase requirements specified by the field 706 are that six value meals are purchased.
Accordingly, if six value meals are purchased, then the offer for free fries is provided to the customer. The offer may be provided via the remote ordering station of the customer when the customer places his order. Alternatively, the offer may be provided when the customer picks up the order. Referring to FIG. 8, a table 800 represents an embodiment of the license plate profile database 330 (FIG. 3). The table 800 includes records 828, 830 and 832, each defining a license plate identifier (e.g. license plate characters and a state of registration) associated with a customer that has been present at a restaurant. It will be understood by those skilled in the art that the table 800 may include any number of records. The table 800 also defines fields for each of the records 828, 830 and 832. The fields specify (i) a license plate identifier 802 that identifies a license plate of a vehicle and thus a customer associated with the vehicle, (ii) a number of visits 804 by the customer to the location represented by the store server 124, and thus the corresponding restaurant, (iii) a number of visits 806 to all related locations (e.g. restaurants of a chain), (iv) a number of visits 808 to the location during this month, (v) a number of visits 810 to related locations during this month, (vi) a set 812 of four related restaurants visited more than twice, which indicates preferred locations for the customer, (vii) whether the customer is a "hopper" 814, and (viii) whether the default order was requested 820. Those skilled in the art will understand that a number of other fields may specify further information regarding a customer.
A customer may be deemed a hopper if the customer frequents several related restaurant, instead of being loyal to one. It may be advantageous to determine whether a customer is a hopper, since it may be possible to coax the customer to frequent only one restaurant. Referring to FIG. 9, a table 900 represents an embodiment of the transaction database 332 (FIG. 3). The table 900 includes records 912, 914 and 916, each defining a license plate identifier (e.g. license plate characters and a state of
registration) and a corresponding order of a customer identified by the license plate identifier. These orders may have been placed remotely, or may have been placed only after the customer arrived at the restaurant. It will be understood by those skilled in the art that the table 900 may include any number of records. The table 900 also defines fields for each of the records 912, 914 and 916. The fields specify (i) a license plate identifier 901 that identifies a license plate of a vehicle and thus a customer associated with the vehicle, (ii) the food items ordered 902, (iii) the quantities 904 of the food items ordered, (iv) the date 906 the order was picked up by the customer, (v) the time 908 the order was picked up by the customer, and (vi) the restaurant identifier 910 of the restaurant where the order was picked up. Those skilled in the art will understand that a number of other fields may specify further information regarding an order. In one embodiment, the field 901 that stores the license plate identifier may be empty for those transactions that were not retrieved by a customer in a vehicle.
In one embodiment, the restaurant identifier need not be stored for each record since the transaction database 332 typically represents orders at one restaurant. However, in another embodiment the restaurant identifier is stored for each record, and the transaction databases of a plurality of restaurants are received by the order server 120. The order server may then, in rum, track orders picked up at a plurality of restaurants. Accordingly, a customer may place his order with the order server 120 (FIG. 1 ), and then pick up the order at any restaurant of the plurality of restaurants that he desires.
Referring to FIG. 10, a table 1000 represents an embodiment of the inventory database 338 (FIG. 3). The table 1000 includes records 1006, 1008, 1010, 1012, 1014, 1016 and 1018, each defining a food item of the corresponding restaurant. It will be understood by those skilled in the art that the table 1000 may include any number of records. The table 1000 also defines fields for each of the records 1006, 1008, 1010, 1012, 1014, 1016 and 1018. The fields specify (i) a food item 1001, (ii) the price 1002 of the food item, and (iii) the number available 1004 of the food item. Those skilled in the art will understand that a number of other fields may specify further information regarding an order. For example, a record may further include a field that specifies a substitute food item to be offered to a customer if the food item is not available. The information stored in the inventory database 338 of a restaurant may
be used in creating a record of the restaurant menu price database 222 (FIG. 2) of the order server 120.
Referring to FIG. 11, a table 1100 represents an embodiment of the remote orders database 340 (FIG. 3). The table 1100 includes records 1114, 1116, 1118 and 1120, each defining an order that was placed remotely and filled at the corresponding restaurant. It will be understood by those skilled in the art that the table
1100 may include any number of records. The table 1100 also defines fields for each of the records 1114, 1116, 1118 and 1120. The fields specify (i) a customer identifier
1101 that identifies the customer, (ii) an order number 1102 that uniquely identifies the order, (iii) the food items ordered 1103, (iv) the quantities 1104 of the food items ordered, (v) a price 1105 of the order, (vi) an indication 1106 of whether the order is prepaid (paid at the time of ordering) or postpaid (paid at the time of pick up), (vii) the status 1108 that indicates whether the order has been filled, (viii) a time 1110 at which the order was picked up by the customer, and (ix) a restaurant identifier 1112 of the restaurant where the order was (or will be) picked up. Those skilled in the art will understand that a number of other fields may specify further information regarding an order.
In one embodiment, the restaurant identifier need not be stored for each record since the remote orders database 340 typically represents orders at one restaurant. However, in another embodiment the restaurant identifier is stored for each record, and the remote orders databases of a plurality of restaurants are received by the order server 120. The order server may then, in turn, track the remote orders of a plurality of restaurants.
FIGS. 12A - C show a flowchart 1200 describing a method for submitting a remote order. A customer identifier is received (step 1202) form a remote ordering station, such as the customer's telephone or computer. The customer identifier is received by order server 120 from a remote ordering station via network 116 and communications port 206. The customer identifier may be a credit card number, license plate identifier, or other means for identifying the customer (or the order). If a telephone is used for the remote ordering station, the customer placing the order may generate touch-tone signals representing the customer identifier by pressing buttons on his telephone. If a computer is used for the remote ordering station, the computer may
access a site on the World Wide Web, at which a form or similar display is provided to the customer to allow the customer to enter the customer identifier.
After receiving a customer identifier, it is determined based on the customer identifier whether the customer has an existing account (step 1204). The customer's credit card number is retrieved (step 1211) from the customer database 218 (FIG. 2) if the customer has an account. If the customer does not have an existing account, customer information is requested (step 1206). The form of the request for customer information varies based on the type of remote ordering station employed by the customer. For example, if the customer is using a telephone as a remote ordering station, the request for customer information may be a series of automated voice prompts directing the customer to input customer information by pressing buttons on the telephone. Alternatively, for example, if the remote ordering station is a computer with an Internet connection, a form may be presented to the customer with blanks to be completed for providing the necessary customer information, such as name, address and/or credit card number. The customer information is received (step 1208) and a new record in customer database 218 is created from the customer information (step 1210).
The customer is prompted to provide the geographical location (i.e. a preferred area for pickup of the food item) at which the customer would like to pick up his order (step 1214). As described above, the form of the request varies depending in part on the type of remote ordering station used by the customer. The geographical location is input by the customer (step 1216). Alternatively, the geographical location may be automatically determined from, for example, a GPS signal received from the ordering station, an ANI (Automatic Number Identification) signal received from a telephone used as the ordering station, or another signal that indicates a geographic area. The geographical location is then used to retrieve from the restaurant database all restaurants having an address in the received geographic location (step 1218). The list of restaurants in the geographical location is then output to the customer and the customer is prompted to select a restaurant (step 1220).
The restaurant selected by the customer is then received (step 1222) to thereby indicate a location for pickup. The corresponding record of the restaurant menu price database 222 is then queried to retrieve a menu for the restaurant specified by the customer (step 1224). In one embodiment, the menu defines special prices
and/or special food items that are different from those provided to customers that do not remotely order. The selected menu, in particular food items and corresponding prices, is then output to the customer (step 1226). The customer is thus able to select desired menu items, and the customer's request (i.e. desired items) is received (step 1228). The step 1228 may include allowing the customer to easily choose his default order with a single command (e.g. pressing the "*" button on a telephone, or clicking a "DEFAULT" button presented on a web site).
After receiving the customer's request, the order server 120 then determines whether the restaurant specified by the customer has conditions listed in the suggestive selling database 224 (step 1230). If the restaurant does not have conditions listed in the suggestive selling database, then a set of generic suggestive selling conditions are retrieved (step 1232). If the restaurant does have its own specific conditions listed in the suggestive selling database 224, then those conditions are retrieved. The retrieved conditions, whether generic or specific for the restaurant, are then compared to the actual food item selections made by the customer and any purchase requirements to determine an appropriate suggestive sell offer or offers to make to the customer (step 1234). The suggestive sell offer, if any, is then output to the customer (step 1236).
The response from the customer to the suggestive sell offers is received (step 1238). If the response indicates acceptance, the order may be modified accordingly (e.g. to include new food items). After determining all food items the customer desires to include in this order, including any suggestive sell items, the customer is asked whether he will prepay or postpay for the order (step 1240). If prepay is selected, then a total price for the order is calculated (step 1242) and the credit card account for prepayment is charged (step 1244). Otherwise, the customer will be charged upon pick up of the order, and the customer may optionally indicate which method of payment he would like to use to postpay.
The above described steps determine, among other things, the food items the customer desires to include in his order. In another embodiment, the order may be generated automatically. For example, the customer may have a standing order that is automatically placed at predetermined times, such as each non-holiday weekday at 8:00 AM.
Directions to the restaurant location are determined (step 1246). The directions are then output to the customer (step 1248). To finalize the order, a unique order identifier is generated (step 1250) and is output to the customer (step 1252). The order identifier may be, for example, a random number that uniquely identifies the order. Since the order identifier uniquely identifies the order, it may be advantageous in one embodiment to use the order identifier as a customer identifier. In such an embodiment, the order identifier could be presented by the customer when he arrives at the restaurant. The order identifier could also be represented by a bar code. If the remote ordering station is a computer, the bar code representing the order identifier could be printed by a printer directed by the computer. The bar code could then be presented by the customer when he arrives at the restaurant and read by a bar code reader.
A new record for the remote orders database 340 of the appropriate restaurant is created for the order, and the appropriate fields are populated (step 1254). The order (i.e. the new record) is output from order server 120 to the store server 124 of the specified restaurant (step 1256).
Throughout the order registration process described above with respect to FIGS. 12A - D, there is substantial interaction with the customer. A single step of the flowchart 1200 may comprise several iterations of prompts and responses from a customer. Also, as discussed above, the nature of these prompts and responses is dependent in part on the type of remote ordering station employed. Prompts for input from the customer may be, for example, supplied by an operator, automated voice prompts or computer-based forms. Responses from the customer may be, for example, vocal responses converted to computer commands by an operator or a voice recognition program, completed computer forms, digital responses or push button telephone responses. Those skilled in the art will realize other ways in which responses and prompts for responses may be performed.
FIG. 13 is a flowchart 1300 a method for identifying a customer at a restaurant. In one embodiment, license plate reader 308 reads a license plate identifier at an entryway into the store or restaurant (step 1302). The apparatus used to identify the customer may be located at or near an entryway to the store or restaurant, or at or near a drive-through lane. Identifying the customer may be performed in response to
detecting the presence of (or the arrival of) the customer at the restaurant. For example, many restaurants include a drive-through lane with a weight sensor. When a vehicle drives in the drive-through lane and imposes its weight on the weight sensor, the weight sensor generates a signal that indicates the presence of a customer in the drive-through lane. Those skilled in the art will understand that the weight sensor may be located elsewhere, such as at the entrance to a parking lot. Accordingly, a customer may be identified upon arriving at any particular location desirable.
Alternative methods for identifying the customer include (1) reading a bar code that identifies either a customer identifier or a remote order associated with the customer, in which the bar code is, for example, printed on a coupon or registered on an identification card; (2) reading a card (e.g. an identification card) with a card reader to read the customer identifier; (3) using a radio frequency identification device to receive a customer identifier that is transmitted via a radio frequency signal (e.g. by a radio frequency transmitter such in the E-Z Pass system of MFS Transtech, the Mobil SpeedPass system of Mobil Corporation or the Texas Instruments THUS system); (4) reading a credit card account number from a credit card, and (5) using biometric identification, such as retinal scanning or finger print analysis. Those skilled in the art will realize further methods for identifying a customer.
After a customer is identified, it may be desirable to provide the customer with a greeting. For example, when the customer arrives at the restaurant, the digital menu board 312 (or another display device) may present a message that includes the customer's name.
Once the license plate identifier (or other customer identifier) is received, a database search is conducted to determine whether there is a corresponding record in the license plate profile database 330 (step 1304). In alternate embodiments, the customer identifier is used to determine whether there is a record in the remote orders database 340 associated with that customer. If there is no record for the license plate identifier, a new record is created and is stored in the license plate profile database 330 (step 1306). The creation of a new record for the license plate identifier is significantly advantageous since it allows one or more databases of customer information to be created and updated automatically and unobtrusively.
If there is a record for the license plate identifier received from the license plate reader 308 (step 1304), then a query is made of the remote order database 340 to determine if the license plate identifier corresponds to an unfilled order (step 1317). If the customer has an unfulfilled order (step 1319), then a remote order fulfillment method is performed (step 1400). The remote order fulfillment method is discussed further below with respect to FIG. 14. If the customer does not have an unfulfilled order (step 1319), then the customer is requested to make an order (step 1325) and the order process continues conventionally (step 1330). For example, an attendant at a point of sale terminal can request the customer's order at that time and/or the food items indicated by the customer's order are prepared. As described above, the order may be stored to indicate the historical preferences of the customer.
FIG. 14 is a flowchart 1400 for an order fulfillment method of the present invention. As discussed above, the order fulfillment method is performed if it is determined that a customer at the store has an unfulfilled order (step 1319 of FIG. 13B).
The order is output to the customer (e.g. via audio or graphic display) to verify that the order is correct (step 1414). A response is received from the customer (step 1416). If the response indicates that the customer has not verified the order (step 1418), then the customer is requested to place a new order (step 1408) and the new order process completes conventionally (step 1410). Similarly, if one or more of the food items the customer desires are not available (e.g. out of stock), then the customer may be either (i) prompted to select alternate food items, and/or (ii) provided with a suggested substitute item that the customer may select.
If the order is verified by the customer (step 1418), then the order should be fulfilled. In one embodiment, the verified order is output to a kitchen video system ("KVS") monitor (step 1420) for display to kitchen personnel. The order is then displayed on the KVS monitor (step 1422), which instructs the restaurant personnel that the order should now be prepared (e.g. cooked and packaged). Alternatively or additionally, the verified order may be output to a kitchen preparation system, which is an apparatus that prepares one or more appropriate food items. The KVS may be, for example, the Universal Kitchen Video System from Panasonic.
Store server 124 then determines whether the order is a prepaid or postpaid order (step 1424). If the order has been prepaid, then a customer receipt is printed (step 1430) and provided to the customer. If the order is a postpaid order (step 1424), then the total price for the customer's order is determined (step 1426) and the credit card account (or other financial account) of the customer is charged for the total price (step 1428).
A receipt may be printed regardless of whether the order was postpaid or prepaid. The printed receipt may indicate whether the order was paid for or whether payment is forthcoming, in order to reduce the chance that a cashier will give away food items without receiving payment therefor. The printed receipt may be associated with the order (e.g. may include an identifier that identifies the order). The printed receipt may also be attached to the food items (e.g. stapled to a bag holding the food items). Instructions may be provided to the cashier to order him to attach the receipt. Other forms of payment besides a credit card account may be used. For example, cash may be tendered to pay for the food items. Accordingly, the customer may be prompted whether he would like to pay cash or would like his credit card account charged.
In one embodiment, an account identifier (e.g. a credit card number) which identifies a financial account may be transmitted via a radio signal from the vehicle (e.g. by a radio frequency transponder such as those used in the E-Z Pass system of MFS Transtech, the Mobil SpeedPass system of Mobil Corporation or the Texas Instruments TIRIS system). The financial account is then charged by the total price.
The customer receipt is printed (step 1430) and provided to the customer. The fulfilled order is then delivered to the customer.
In one embodiment, fulfilling the order comprises transmitting the unfulfilled order to a kitchen video system monitor (step 1420). In alternative embodiments the fulfillment of the order includes for example, printing a ticket indicating the unfulfilled order and providing the ticket to kitchen personnel. Also, the steps required to fulfill an order vary depending upon the nature of the item ordered and the facility fulfilling the order.
The embodiments described above relate to the fulfillment of an order by a restaurant. The method and apparatus disclosed herein are particularly well suited for remote orders of a restaurant. However, the invention is not so limited. The invention applies to remote orders of items from stores other than restaurants. The invention described herein efficiently coordinates the fulfillment of an order placed remotely. This is accomplished by delaying the fulfillment of an order until a customer has been identified at a facility where the order is to be fulfilled. In the context of a restaurant, the invention has the obvious advantage of timing the preparation of an order so that the food does not sit for an indeterminate amount of time prior to pick up. In other environments, the invention advantageously times the fulfillment of an order to coincide with its pick up, yet delays the effort required to fulfill the order for as long as possible, freeing resources to complete other tasks.
The present invention further permits existing drive-through lanes to be used to serve both customers having placed remote orders as well as customers that order at the drive-through. Also, the invention permits customer information to be unobtrusively collected when the customer picks up the order. Furthermore, the present invention permits customers to place an order with a central order server and then pick up corresponding food items at any of a number of restaurants by identifying the customer when he arrives at the specific restaurant. Although the present invention has been described with respect to specific embodiments thereof, it will be understood that various changes and modifications will be suggested to one skilled in the art and it is intended that the invention encompass such changes and modifications that fall within the scope of the appended claims.