GB2341704A - Ordering system - Google Patents

Abstract

An ordering system of a cafeteria etc., includes a cafeteria etc server provided with a menu file 1, ingredient file 2, etc. and terminals PC for use by customers, connected by a network. Orders are placed by the customers by accessing the server from the terminals PC. The customers select the food they want from the menu based on information read from the menu file. The information concerning the food to be cooked that day and the quantity thereof and the ingredients which have to be ordered and the quantity thereof is successively updated in accordance with the orders from the customers.

Description

ORDERING SYSTEM The present invention relates to an ordering system used

for taking orders at a store, for example, a restaurant, more particularly relates to an ordering system suitable for a restaurant of a self-service format such as a company cafeteria for employees.

Among the various types of restaurants, restaurants, such as employee cafeterias and student cafeterias, often adopt the self-service format. Not only these cafeterias, but also all restaurants of the self- service format usually arrange already cooked food on shelves in advance, have persons coming to eat select their favorite foods from the shelves, and then have them settle their bills at the cashier.

In the case of such restaurants, accordingly, it is necessary to prepare in advance a certain quantity of food. Further, in order to increase the range of selection off the food, it is necessary to prepare a number of different types of food.

Further, in other forms of restaurants, the food is prepared after the customer comes in and decides what to order. Even in this case, however, it is necessary to prepare for cooking the food in advance. Further, it is necessary to prepare several portions worth of food in advance in the case of food which cannot be prepared in single serving portions.

Further, no matter what the form of the restaurant, it is necessary to order the ingredients in advance. It is preferable in many senses to limit the amoun-k of ingredients ordered to the required least amount.

Here, a general problem of restaurants is that 2 - it is very difficult to predict the number of customers who will come in on a certain day or in a certain time frame. When a restaurant has been run for a long number of years, its manager can predict the approximate number of people who will come in by the rule of thumb, but the exact number of guests will vary considerably due to date of the month, the day of the week, the weather of that day, holidays and events, and other conditions. Further, there are the individual whims of the guests - a condition making prediction quite impossible.

Accordingly, the actual number of customers who come in will differ from the predicted number of customers in many cases.

Prediction of the number of customers coming to the restau-rant is an extremely important factor in the determination of the number of servings of food to prepare for that day and the amount of the ingredients to order. Such advance preparations are particularly necessary in the case of a restaurant of the self-service format, and thus it is difficult to appropriately adjust the number of servings to prepare to meet with the number of customers.

while the number of servings and amount of ingredients ordered are determined according to the predicted number-of customers, when the predicted number of customers and the actual number of customers differ, the following problems arise in running the restaurant.

Note that here it is assumed that the number of servings and the amount of ingredients ordered are determined based on the predicted number of customers.

1) Case where the number of customers is larger than the predicted number In this case, there is an extremely high chance that the number of servings and the ordered ingredients will be insufficient. Where there is insufficient food, it becomes impossible to serve customers who arrive later. If this insufficient amount of food continues 3 -- regularly, the restaurant may gain the reputation of being unable to provide sufficient food.

2) Case where the number of customers is lower than the predicted number In this case, there is an extremely high chance that the ingredients purchased and the cooked food will be wasted. Particularly, there are fresh foods which cannot be preserved and any remaining amount thereof must be thrown away.

Further, particularly in a case of the restaurant of a self-service format, it is necessary for customers to be able to immediately obtain the food they desire when they arrive. For this reason, precooking is absolutely necessary. while it possible however to keep uncooked ingredients until the next day, such precooked food cannot be preserved, so it is necessary that it be consumed within the same day. For this reason, it is sometimes necessary to throw away the left over cooked food.

Thrown away foods become a loss for the restaurants. The larger the amount thrown away, the larger the burden on the restaurant. Further, if a large amount of precooked food continues to be thrown away, the restaurant may end up with the reputationof a place which wastes food. This may also cause problems with the general reputation of the restaurant.

Even if the amount of surplus ingredients could be preserved, investment etc. in storage equipment becomes necessary. Further, unless the amount of ingredients ordered is kept to the required level at all times, considering the cost of storage etc., the restaurant will end up with greater expenses and loss.

For this reason, the amount of ingredients ordered and the number of servings prepared in advance preferably should be kept as low as possible.

on the other hand, it is necessary to avoid situations where customers coming to the restaurant 4 cannot be served since this is a service industry.

Accordingly, in this case, it becomes necessary to increase the amount of ingredients ordered and the number of servings prepared in advance by a certain percentage above thg predicted levels.

In this way, the amount of ingredients ordered and the number of servings prepared become very large problems in running a restaurant, It is desirable to provide an ordering system capable of efficiently ordering ingredients and preparing f 00C, - It is also desirable to an ordering system enabling automatic calculation provL and updating of the amount of ingredients which should be ordered and the quantity which should be cooked.

Note that needless to say the effect of automatic calculation and updating of the quantity of goods ordered etc. or the ability to obtain a grasp in advance oil the minimum quantity of goods which will become necessary on a certain day can also be applied to stores other than restaurants or to mail order sales, telephone shopping, and on-line sales, but the following explanation will be m35e of the case of appLicat= of an eabidinErt of the presert uTet-icn to. a cafeteria system as an example.

In an ordering system embodying the present invention, a cafeteria server provided wIth a menu file, ingredient file, etc.

and terminals PC for use by customers are connected by a network and orders placed by the customers accessing the cafeteria server from the terminals PC. The customers select the food they want from the menu based on information concerning the menu of the cafeteria read from the menu file. The information concerning the food to be cooked that day and the quantity thereof and the ingredients which have to be ordered and the quantity - thereof is successively updated in accordance with the orders from the customers.

Reference will now be made, by way of example, -;c':

to the accomiDanying drawings, in wl..,,.

Fig. 1 is a view of a cafeteria system according to an embodiment of the present invention; Fig. 2 is a view of the system configuration on the cafeteria side; Fig. 3 is a view of the configuration of a menu file; Fig. 4 is a view of the configuration of an ingredient file; Fig. 5 is a view of the configuration of an order receiving file; Fig. 6 is a view of the configuration of an ingredient ordering file; Fig. 7 is a view of the configuration of a serving file; Fig. 8 is a view of the configuration oil an individual setting file; Fig. 9 is a view of the configuration of a terminal; Fig. 10 is a block diagram of an internal configuration of the terminal; Fig. 11 is a block diagram of the internal configuration of a reception device/management terminal; Fig. 12 is a block diagram of the internal configuration of a counter terminal; Fig. 13 is a block diagram of the internal configuration of a kitchen terminal; Fig. 14 is a flow chart of a processing routine taking note of the operation for placing an ordering by a customer; Fig. 15 is a view of processing when issuing a coupon by using a printer; 6 -- Fig. 16 is a view of the processing when writing the content of an ordering on a customer card; Figs. 17A and 17B are first parts of a flow chart of the processing routines on the terminal and restaurant server sde when placing an order; Fig. 18 is a second part of a flow chart of the processing routines on the terminal and restaurant server side when placing an order; Fig. 19 is a view of an example of a display of an initial menu screen; Fig. 20 is a view of an example of the display of a table of a Japanese food menu; Fig. 21 is a view of an example of the display of a detailed screen of a selected menu; Fig. 22 is a view of an example of the display of an order form and an example of entries in it; Fig. 23 is a view of an example of the display c-' a confirmation screen; the Fig. 24 is a first part of a flow chart o-A processing routine in a cafeteria system when setting a password; Figs. 25A and 25B are second parts of a flow chart of the processing routine in the cafeteria system when setting a password; Fig. 26 is a view of an example of the display of an initial screen of the password setting; Fig. 27 is a view of an example of the display of a screen of a new setting; Fig. 28 is a view of an example of the display cf a screen for confirming the new setting; Fig. 29 is a first Part of a view of an example of the display of a screen for change of a password; Fig. 30 is a second part of a view of an example of the display of a screen for change of a password; Fig. 31 is a flow chart of a processing routine executed on a cafeteria server side after reception c-' an order; 7 Fig. 32 is a flow chart of the processing routines on the cafeteria server side at the time of a deadline and before a deadline; Figs. 33A and 333 are flow charts of a processing routine in a cafeteria system at the time of cancellation of an orer; Fig. 34 is a flow chart of a processing routine when displaying information on a kitchen terminal; Fig. 35 is a view of an example of a screen displayed on the kitchen terminal; Fig. 36 is a view of an example of a display screen of a kitchen terminal showing information with respect to a certain menu; Fig. 37 is a view of an example of a display screen of a remaining number of uncooked servings; Fig. 38 is a view of an example of the display of a screen for checking on deliveries; Fig. 39 is a view of an example of a keyboard of the kitchen terminal; Fig. 40 is a flow chart, of a processing routine when the customer comes to a cafeteria; Fig. 41 is a view of an example of a customer guide display; Fig. 42 is a flow chart. oil a processing routine when inspecting ingredients; and Fig. 43 is a view of an example of the display of a message when the cafeteria is full.

An enbodiment of a first aspect of the present irAEriticn can prov-ide an ordering system provided with a cafeteria server and a terminal operated by a user of the cafeteria connected to each other by a transmission line, wherein the cafeteria server is provided with a menu file for storing information concerning the menu provided by the cafeteria, an ingredient file for storing names of __) - 8 -_ ingredients and quantities which become necessary for every item on the menu stored in the menu file, a reception file for storing information concerning the items on the menu ordered by the user, an ingredient totaling,file for totaling the quantity which will become necessary for every ingredient based on the order by the user, and a serving file for storing information concerning the items of the menu which have to be cooked during a certain period, the quantities thereof, and the ingredients required for cooking the items of the menu therein.

In the cafeteria server, information concerning suppliers for every ingredient may be stored in the ingredient totaling file.

The cafeteria server may be connected to a terminal provided at a supplier by a transmission line; terminal identification information of the supplier may be stored in the ingredient totaling file; and order information may be transmitted to the supplier terminal over the transmission line according to terminal identification information at the time of the cafeteria server ordering ingredients.

Further, in the cafeteria server, a deadline for accepting orders from users may be set and the ingredients ordered based on the information of the ingredient totaling file after the deadline is reached.

Information concerning the names of the items on the menu ordered by users and the quantities of the same, utilization time, method of payment, and special requests may be stored in the reception file.

Information concerning the quantities of items On the menu already prepared may be stored in the serving file.

The quantity of uncooked food may be calculated based on the quantities of items on the menu already prepared and the quantity of uncooked food displayed on a screen.

9 Information concerning the quantity of uncooked food may be stored in the serving file for every item on the menu.

A flag for indicating whether supplies have been delivered for 'every ingredient may be set in the serving file.

A flag for indicating whether supplies have been delivered for every ingredient may be set in the ingredient totaling file.

Photo information may be stored for every item on the menu in the menu file.

An errbodiment of a second aspect of the present invention can provide a data processing unit irstaUed in a cafeteria, provided with a menu file for storing information concerning the menu provided by the cafeteria, an ingredient file for storing names of ingredients and quantities which become necessary for every item on the menu stored in the menu file, a reception file for storing information concerning the items on the menu ordered by a user, an ingredient totaling file for totaling the quantity which will become necessary for every ingredient based on the order by the user, and a serving file for storing information concerning the items of the menu which have to be cooked during,a certain period, the quantities thereof, and the ingredients required for cooking the items of the menu therein.

The data processing unit may be connected to an order terminal from which a user inputs content of his or her order and the order of the user accepted in accordance with the operation of the order terminal.

An errbodiment of a third aspect of the present invention can provide.. an GrdiEring --system or_ receiving an order from a custcmer, provided with a terminal for a customer to input the content of an order- and a server for receiving an order input from the terminal, the server provided with a product file for storing information concerning the products which can be ordered by a customer and an order - file for storing the content of orders including products selected by a customer.

The server may be further provided, in the ordering system, with an order file in which information concerning products and suppliers for every product are stored.

The server may in addition be provided, in the ordering system, with a file in which an inspection flag is set for indicating whether or not a product ordered to a supplier is delivered.

The order file may store the content of special requests made by a customer.

An embodiment of a fourth aspect of the present invention can provide an ordering method in an ordering system for rejeivinganerc3erfrcm is a customer, comprising displaying information concerning products which can be ordered on an order terminal and updating the content of the order file storing the information concerning the content of the orders provided in a reception terminal in accordance with the selection of a product from the order terminal.

An embodiment of a fifth aspect of the present invention can provide an ordering method in an ordering system for receiving an order from a customer, comprising displaying a screen a,' a list of products which can be ordered on an order terminal from which a customer inputs the content of an order, displaying a screen of an order form for inputting the content of an order on the order terminal in accordance with the selection of a product by the customer; displaying a confirmation screen for allowing a customer to confirm the content of an order by the order terminal in response to the input of the content of the order from the order form screen; and accepting the order after an operation by the customer confirming the content displayed on the confirmation screen.

when displaying a list of products, it may first display a screen of a list of large classifications of products which can be ordered by the customer and then __) - 11 - display a screen of a list of small classifications of products belonging to a large classification of products selected from the screen of the list of large classifications by the customer.

An embodiment of a sixth aspect of the present invention can provide ai ordering system for receiving an order for a product from a customer from an order terminal, comprising judging, when an order from a customer has been input, if the deadline for receiving the order has passed or not, accepting, when the deadline has not passed, the order from the customer, while displaying, when the deadline has passed, a message indicating that the deadline has passed on the order terminal and not accepting the order.

Turning now to specific examples of the present invention, Fig. 1 is a view of the system configuration of a cafeteria system in an embodiment of the present invention. Here, particularly, an example of application to an employee cafeteria will be explained, but the present invention can naturally also be applied to other types of restaurants and needless to say can be used for various types of ordering systems such as mail order, telephone shopping, and on-line sales.

The cafeteria system according to the present embodiment is, roughly speaking, provided with a cafeteria server, a cafeteria terminal, at least one terminal provided on a customer (that is, employee) side, and an employee server. The cafeteria server, terminal server, and employee server are connected to each other by a network. The employee server is provided with an employee data base (DB) and a salary data base. When paying a bill by deduction from one's salary when using the employee cafeteria, the sum corresponding to the bill is deducted from a salary account recorded in the employee server.

Here, a LAN etc. may be utilized in the case oil an employee cafeteria etc., but in the case of a general cafeteria where use by a large number of unknown 12 customers is expected, the recently popularized In-ernet etc. may be used.

Figure 2 is a view showing the configuration of the cafeteria side in further detail. In the example 010 Fig.

2, the c5afeteria side is provided with the cafeteria server. a kitchen terminal, an order management terminal, a reception terminal, and a counter terminal. Note that the terminals on the cafeteria side are not limited to these. It is possible to provide other terminals or to combine the functions of the terminals illustrated in Fig. 2 into one terminal. The configuration of the cafeteria side can be appropriately changed according to the size etc. of the cafeteria.

A variety of files are provided in the cafeteria is server. Below, an explanation will be made of these files.

Figure 3 is a view for explaining the configuration of the menu file. (A) of Fig. 3 is a large classification file; and (B) of Fig. 3 is a small classification file.

Information concerning the menu which can be provided by the cafeteria are stored in the menu file.

This menu file is referred to when a customer places an order.

The large classification file stores the large classes of the content of the menu which can be provided by the cafeteria. In the example of (A) of Fig. 3, the items "western food, "Japanese food", "Chinese food", "bowl meals", etc. are set.

The small classification file illustrated in (B) of Fig. 3 is comprised so as to be linked to the large classification file. The small classification file stores information concerning the names of items on the menu, prices, and calories as a set for every large classification. In the case of (B) of Fig. 3, the small classification file for "BOWL MEALS", the destination of the link when "BOWL MEALS" is selected in the large classification file, is illustrated.

13. - Further, the menu file, although details are not illustrated in Fig. 3, also stores a photo for every item on the menu linked to every item on the menu in the small classification file. The photos of the items on the menu are displayed at the customer terminal and.used for visually checking the content of the menu.

Figure 4 is a view explaining the configuration of the ingredient file. The ingredient file stores sets of na.-,nes of ingredients required for cooking a dish and the quantities thereof for each item on the menu.

For example, the Japanese dish "pork cutlet on rice" is shown as an example in Fig. 4. Here, information such as 180 cc of rice, 100 g of pork, 1/4 of an onion, and one egg is stored. This shows the ingredients necessary for preparing one serving of "pork cutlet on rice" and the quantities thereof. Further, in the case of a request for a "large serving", information is set indicating to increase the ingredients by 10% (not illustrated).

Such option information such as the increased quantities for a "large serving" may be set for every item on the menu in the ingredient file (recorded as "198 cc of rice" or "increase by 10%"). For example, when "large serving" is selected, it is also possible to uniformly and automatically increase the quantities in the ingredient file. In the former case, the increased quantities must be stored in the ingredient file, while in the latter case, it is sufficient to set just the normal quantities, but necessary to calculate the increased quantities.

Further, in the former case, it is also possible to change the quantities for the large servings for every item on the menu or for every ingredient. For example, it is also possible to set the quantities so as to only increase the amount of rice by 10 percent and not increase the other ingredients. Further, when there is an item on the menu which cannot be provided as a large serving, it is also possible to add information that 14 "large serving not possible" to the menu file, ' and thus enabling a provision of user-friendly services. As opposed to this, in the latter case, since the structure of the ingredient file becomes simple, it may be said to be suited particularly for a case where there is not enough money on the cafeteria server side and so on.

Figure 5 is a view for explaining the configuration of the order receiving file. In the order receiving file, information for identifying the customer (employee number in Fig. 5 since an employee cafeteria is used as an example), date of utilization, ordered food and the quantities thereof, options (special request such as large serving) and the quantities thereof, and the method of payment are stored.

is Here, if dealing with an employee cafeteria, basically the bill may be paid by deducting the amount from the salary. Even in the case of an employee cafeteria, there is a possibility that an outside person will visit it to eat. Since the bill cannot be deducted from salary for such a person, it is necessary to make it to deal with the bill by payment by cash, a poss. prepaid card, IC card (electronic money), or the like. Further, there may also be employees who choose not to deduct the bill from their salaries when using the cafeteria. In the order receiving file illustrated in Fig. 5, the information concerning the method of payment is stored together with the content of an order so as to enable the order to be handled.

The method of payment is designated at the time of placing the order. Details of this method of designation will be explained later. Note that, as the method of payment, other than this, payment by a credit card is also possible.

Further, envisioning a case of a members-only store, the names of the customers are registered at the store side in advance. This resembles the relationship between employees and the cafeteria in the case of the example of the employee cafeteria. In this way, when the people who come to the store can be specified (in other words, when it is not necessary to consider the arrival of walk-in customers), it is also possible to uniformly set the method o payment for every customer. When the customers can be specified and also the method of- payment can be specified, it is also possible to eliminate the information setting field concerning the method of payment from the order reception file.

Figure 6 is an ingredient ordering file which is utilized when the cafeteria orders ingredients. In this ingredient ordering file, information concerning the ingredients which are to be ordered by the cafeteria, the quantities oil the order, and the suppliers are stored without relation with the menu.

Details oil the method of updating the content of the ingredient ordering file will be explained later, but briefly the quantities of ingredients are successively updated by referring to the quantities of the items on the menu ordered, which are stored in the order receiving file, and the quantities of every ingredient for each item on the menu required, which are stored in the ingredient file. The cafeteria side then places orders for the quantities stored in the ingredient ordering file to the suppliers.

Here, when for example ordering onions, it is probably impossible to order less than one onion. In this case, when a fraction arises in the quantity of an ingredient stored in the ingredient ordering file, that fraction is automatically rounded up to a regular unit quantity. In the example of an onion, where the required number of onions, calculated based on the number of orders and the required quantities stored in the ingredient file, becomes a fraction less than one, the totaled up quantity is automatically rounded up to reach one.

Further, as the supplier information, in the case of 16 - Fig. 6, the names of suppliers are recorded. Here, when the suppliers have also terminals connected by a network, it is possible to utilize these terminals. For this reason, to deal with this, it is also possible to store the e-mail address etc. for every supplier, refer to these at the time of placing orders, and automatically transmit the order information to the suppliers via the network. Of course, not all suppliers wi,ll be connected by the network, so in this case the telephone or -facsimile numbers etc. may be recorded together with the names of the suppliers.

Further, in the field "date of delivery", the scheduled date when ordered ingredients will be delivered is set. This "date of delivery" information can also be used for checking of whether or not the ingredients were delivered. That is, an the date when the ingredients are supposed to be delivered, the information for the ingredients (names of ingredients) which are scheduled to be delivered during that day is read by referring to the ingredient ordering file. Then, it is confirmed whether or not the delivery is made for every ingredient.

Figure 7 shows the serving file. This stores the required quantities for the items on the menu which must be cooked in a certain day (January 13 in the illustrated example) and the ingredients which are required for cooking them and the quantities thereof in correspondence with each other. Further, the serving file may be set with the dates of delivery (scheduled dates) of ingredients and check flags for indicating whether or not the ingredients were actually delivered. Note that it is also possible to store the dates of delivery and the check flags in different files, andalternatively, set only one since the contents of the ingredient ordering file and the serving file partially overlapped.

The information stored in the serving file is sent to the kitchen terminal and the counter terminal where the information required for cooking is displayed on 17.

their screens. When taking a kitchen as an example, the items on the menu which must be cooked that day, the quantities thereof, the quantities of ingredients, etc. can be displayed on the kitchen terminal. Due to this, it is possible to confirm at a glance what and how much is to be cooked at the time of cooking. Further, a field in which the quantities of already prepared foods for use that day also are entered is set in the serving file. This field is used for the kitchen obtaining an information of the quantities which have been already cooked or how much must be cooked.

Depending on the item on the menu, there is a possibility that the entire ordered quantity cannot be cooked at one time. Therefore, at this time, the item must be cooked divided into several pork-ions. At this time, it is very effective in running the cafeteria if information on how many servings have been already cooked or how many servings still have to be cooked are displayed on the kitchen terminal. Therefore, the serving file stores the above information and the kitchen terminal displays the number of the already cooked servings or the number of the uncooked servings when displaying the information.

Further, when there is a special request (option) such as a request for a large serving, this information is also set, in the serving file. Although not illustrated in Fig. 7, the quantities of the large servings and other options may be written in the serving file separately from the overall required quantity of food (inclusive number also possible). Due to this, it is possible to display, on the kitchen terminal, what and how many options should be cooked for easy understanding and reduce the errors in cooking or the like.

Figure 8 shows an individual setting file. in the example of Fig. 8, an employee number and password are set in pairs for every customer. These are used for comparison against a password which is input when a customer places an order and are designed nou to be able to be seen by a usual operation.

In the case of Fig. 8, a case where the method of payment is not specified for every customer is assumed.

However,,there is also a case where the method of payment can be specified if the customer can be specified as in a members-only store as explained above. In this case, a field for recording the method of payment is set in the individual setting file. Further, in a case where the method of payment becomes uniform irrespective of the customer as in the case where only payment by cash is accepted, it is possible to not set information concerning the method of payment in any file.

In the present embodiment, these files are set in the cafeteria server. Note that a modification in which the contents of the files illustrated in the figures are combined in one file is also possible.

Figure 9 is a view of an example of the configuration of the terminal side. In recent years, personal computers are being installed in the workplace in increasing cases. Therefore, these usual personal computers etc. can also be used as the terminals.

Further, of course, it is also possible to utilize exclusive terminals for placing orders. Here, personal computers are almost always provided with printers.

Further, they can also be connected to IC card readers or writers (illus-lk--rated as R/W, same below). When a customer places an order, these printers and R/WS may also be used.

when a customer places an order, a meal ticket may be issued by using a printer installed at the customer's workplace. By using a usual printer, there is no need to go to the trouble of providing a special new printer for the meal tickets (though installing them may also be possible).

Further, in recent years, as proof of employment, ID cards (ragnetic cards or 1C cards) have been used.

T _1 19 - Therefore, use of such cards at the time of utilization of the cafeteria can be considered. Particularly, an IC card has a large storage capacity, therefore if the content of the orders is written in the IC card in place of the meal ticket, it is not necessary to print a meal ticket by using a printer.

Figure 10 is a block diagram of the configuration of the internal portion of a terminal. The terminal is provided with a CPU for performing the processing, a communication control unit used when communicating with the network, a memory in which various types of programs are stored and also the content input at the time of ordering is temporarily stored, a display, a printer, a keyboard for inputting the information, and a card R/W.

Figure 11 is a view of the configuration of the reception terminal/management terminal on the cafeteria side. An ordinary personal computer can be used for this terminal as well. This terminal has a similar configuration to that of the terminal illustrated in Fig.

10. in the case of Fig. 11, the illustration of the printer and R/W is omitted. This is because only the minimum configuration for realizing the functions indispensable for the present embodiment is illustrated. Of course, these devices can be provided according to need.

Figure 12 is a view of the configuration of the counter terminal installed at every counter of the cafeteria. The counter terminal can be a general personal computer or the like or can be an exclusive terminal considering the convenience to the user taking into account that the customer has to operate the terminal when coming to the cafeteria.

The counter terminal is provided with a display or card R/W. The ID card of the employee may inserted into the card R/W. When the content ordered by the employee is written into his!D card, information concerning the items on the menu ordered by that customer (information 1\ - 20--- such as the names of the items on the menu, cuantity, and location) are displayed on the display in accordance with the content of the order read from the IC card. Alternatively, it is possible for the counter terminal to refer to.the cafeteria server, read the content of an order of an employee who inserted the ID card into the card R/W, and display the same on the display. When only the employee number or the like is recorded on the ID card, it is also possible to read this from the R/W, refer to the cafeteria server, and display the information on the items on the menu ordered by that customer. The form oil this can be appropriately determined in accordance with the method oil operation of the cafeteria. Needless to say, other methods can be applied as well. The customer receives the items on the menu which he ordered in advance according to guide information displayed on the display of the counter terminal.

Note that it is also possible to give the counter terminal the function of issuing a meal ticket. The printer illustrated by the dotted line in Fig. 12 is used for issuing the meal ticket. when inserting an ID card into the card R/W, the stored order information is read and the meal ticket is issued from the printer based on this.

Figure 13 is a view of the configuration of the kitchen terminal. when considering only the purpose explained heretofore, it is sufficient so far as the content to be cooked be displayed on the kitchen terminal, therefore, in the case of the present embodiment, a printer for a card R/W or issuing a meal ticket is not particularly necessary (these may become necessary for other purposes). For this reason, a card R/W and printer are not particularly illustrated in the kitchen terminal according to the present embodiment.

Figure 14 is a flow chart illustrating the routine when noting the operation of the user mainly where it 21-- places an order using the cafeteria system.

First, when using a cafeteria system, the user accesses the cafeteria server ("cafeteria home page,, in the figure) from a terminal disposed in its office. Here, the reason why the term "home page" is used in the illustration is that consideration is given to increasing utilization of the Internet in coming years.

When the cafeteria server is accessed, the screen information for selection of the menu is transmitted from the cafeteria server to the terminal. The terminal displays the received screen information on its screen.

The user selects - the items on the menu which he or she desires to order from that screen. Then, the selected order information is sent to the cafeteria server. The cafeteria server prepares an order form screen based on the information sent from the terminal and transfers its screen information to the terminal. At the terminal, the transferred order form screen is displayed on its display and the order form input by the user is awaited. The order form is used for confirming the content of the input order. Details of the order form screen will be explained later.

The user inputs the content of -an order from the order form screen. when the input of the order form is confirmed, a confirmation screen is displayed on the terminal in response. Using this confirmation screen, the user can confirm if the content of an order was correctly input or confirm if his or her order should be settled.

After checking the content of an order, the user executes a confirmation operation. on the other hand, when changing the content of an order, the order screen is displayed again and the order is input again.

Figure 15 explains the operation in the case of issuing a coupon (meal ticket) using a printer equipped in the terminal after the operation of Fig. 14. When the confirmation operation is executed, the input content of an order is transmitted to the cafeteria server as 22 con'L-"Lrmed. In response to this, the cafeteria server sends information which is necessary for issuance of the coupon to the terminal. The terminal edits the information for issuing the coupon after receiving it and activate.s the printer to issue the coupon.

Figure 16 shows the processing, in place of the processing of Fig. 15, in the case where the content of an order is written in a card (IC card etc.) held by the user. The processing is similar to the case of Fig. 15 up to the point where the confirmation operation is carried out in Fig. 14 and the order confirmation is transferred to the cafeteria server. Then, in the same way as the case of the issuance of a coupon, information concerning the ordered food is sent from the cafeteria server to the terminal. Note that the information at the time of issuance of the coupon and the information written on the card may be exactly the same. This is because it may be considered that the information of a coupon usually printed as paper is written in the IC card instead. Of course, it is also possible to prepare information separately for each of the formats such as the coupons or cards described above.

when the terminal receives information from the cafeteria server, it displays a message prompting the insertion of 'the card into the card R/W to the user. When the user inserts the card into the card R/W along with this, the terminal writes the information concerning the content of the order in the card inserted and then ejects the card.

The series of processing for placing an order is executed by such a processing operation. Details of the routines will be explained later according to need.

Figures 17A and 17B and Fig. 18 are flow charts for explaining details of the series of operations at the terminal and cafeteria side at the time of placing an order. The left sides of the figures show the processing on the terminal side, while the right sides of the 23- - figures show the processing on the cafeteria server side.

on the terminal side, first, the cafeteria server is accessed. In response to this, the cafeteria server transfers the initial screen data to the terminal. The terminal,displays the initial menu on the screen based on the received initial screen data.

Figure 19 is a view of the example of the initial menu screen. The initial menu screen displays large classes of items of the menu which can be selected by the user and items for setting a PIN code (details explained later). The user first selects a large class- of items on the menu to be ordered by using the initial menu screen.

When a large class of items on the menu is selected from the initial menu, the result is notified to the cafeteria server. The cafeteria server refers to the menu file, reads the small classification information corresponding to the selected large class, and transfers the same to the terminal. on the terminal, the transferred small classification information is displayed on the screen. Here, a list of the items on the menu is first displayed.

Figure 20 illustrates an example of the list of the selection of items on the menu when a Japanese food menu.is selected from the screen illustrated in Fig. 19. In the menu list, names of items on the menu which can be provided by the cafeteria, prices thereof, and calories f a table. when a user selects are displayed in the form of a specific item on the menu from the menu screen, the detailed menu is displayed on the screen of the terminal.

Figure 21 illustrates an example of the display of the screen of the detailed menu and shows an example of a case where a grilled fish set is selected. The detailed menu screen displays the content (item) of the selected menu and a photo of the item. By this, the user can confirm the content of the item on the menu which he or she is selecting. Note that, on the detailed menu screen illustrated in Fig. 21, it is explained that a larger 24 - serving of rice costs an extra 20 yen. By this, the user can be informed that a large serving can be obtained in the grilled fish set.

Further, at the right corner of the detailed menu screen, an "order" field and a "return" field are set. When the "order" field is selected, the order of the item on the menu displayed on the detailed menu screen is transferred to the cafeteria server side. Further, when the "return" field is selected, the screen changes to the selection menu screen again.

upon receipt of the selection of the "order" field on the detailed menu side, the cafeteria server edits the screen of the order form in accordance with the selected item on the menu and transfers this to the terminal.

Figure 22 is a view of an example of the order form which is displayed on the screen of the terminal receiving the information from the cafeteria server. The order form automatically displays the date of the order.

Further, the order form is set with employee number input field, an order display field, an order quantity display field, an option information selection field, an option object number display field, a utilization date display field, a payment method display field, and a PIN code input field.

The employee number is input in the employee number input field manually by the user or by reading the ID card. The order display field displays the name of the item on the menu selected on the detailed menu screen.

The option information selection field is used for selecting information concerning various options (special requests) such as a,large serving of rice". The content of the options is determined in accordance with the selected item an the menu. The user appropriately selects the -Intended content from this.

There are many foods which cannot be eaten or are not eaten due to the preferences of the individual or his or her constitution or health. The option selection - according to the present embodiment can also handle such cases. That is, by inputting items which he or she cannot eat from the option information selection field, specific items can be removed from the ordered menu. In the example of the "grilled fish set", it becomes possible to omit for example a 'vegetable salaC or eliminate specific items in the "vegetable salad".

Further, if the cafeteria side can handle it, as a further option, it is also possible for a user to designate the addition of an item which is not indicated on the menu.

In the display field of the utilization date, since this embodiment basically considers the orders for the next day, the lunch time hours of the next day are automatically displayed. Note that the user does not always place orders only for the next day and there are cases where he or she cannot come to the cafeteria at lunch time. For this reason, in the present embodiment, it is made possible to change the date of utilization by manually inputting the date from the field of the utilization date.

If the utilization date, particularly the time, is designated in advance, the cafeteria side may cook the food to be ready for the time. For this reason, the input of the utilization date from the confirmation screen is very useful for the cafeteria side.

Since the example of the employee cafeteria is taken into account in the present embodiment, "salary deduction,' is automatically displayed in the field of the method of payment. Note that not all of the users who visit the employee cafeteria are always employees of the company, so the selection of a method oil payment other than salary deduction must also be made possible. For this reason, when another method of payment (cash payment, utilization of card, etc.) is selected, the intended method of payment is selected in the field of the method of payment.

26 -- In the utilization of the cafeteria system, monetary transactions take place, so in the present embodiment, it is judged if the user is the proper person by having him or her input a PIN code. The input PIN code is verified on the cafeteria server side as well as the employee number to decide whether or not the input code is correct.

when the input of this information is confirmed, the order form is transferred to the cafeteria server, therefore, in response to this, the screen information of the order reception confirmation is transferred from the cafeteria server to the terminal and displayed on the terminal. Figure 23 is a view of one example of the screen of the order reception confirmation.

on the screen of the order reception confirmation, various items such as the time of ordering, utCilization date, ordered item and quantity, the content of options if any, the bill, and method of payment are displayed.

The user refers to the screen of the order reception confirmation to confirm whether or not the content of one's order was correctly input.

At the right corner of the screen of the order reception confirmation, a "confirm" field and "cancel,, field are set. when the content of an order is correct or is notthanged, the "confirm" field is selected. By this, the content of an order is confirmed and this is notified to the cafeteria server. when the "cancel" field is selected, the previous screen (selection screen etc.) is displayed.

when "confirm" is selected, the cafeteria server deems that the order has been confirmed and updates the contents of the files such as the ordering file, already explained in detail, based on the input content of an order.

This ends the series of processing for placing an order.

Figure 24 is a flow chart illustrating the 27 - the terminal in the case of considering processing a. entry of a PIN code (password). when the cafeteria server is accessed and the initial menu is displayed, the terminal determines whether or not entry of a password was selected (monitoring whether not a selection of item was made). when entry of a password is not selected, it is determined by the monitoring whether or not the menu (large classification) was selected.

Here, when entry of a password is selected, the terminal executes the processing of Figs. 25A and 25B.

Figures 25A and 25B are flow charts illustrating the series of processing for setting a password. Further, Fig. 26 illustrates the initial screen of the password entry. Here, the password entry includes new entry and change of password, so the user select which to carry out by using the initial screen illustrated in Figs. 25A and 25B.

First, an explanation will be made of the case of new entry. This is executed in a case where the customer newly utilizes the cafeteria system etc.

when "new entry" is selected from the initial menu of the password entry, the screen for new entry of the PIN code is displayed on the screen (Fig. 27). On the screen for new entry of the PIN co de the employee number input field and the PIN code input field are set. The user inputs the secret code to be entered together with his or her employee number by using the screen for new entry of a PIN code. Note that, in order to prevent the PIN code from being seen by others, in the example of

Fig. 27, asterisks are displayed instead of the digits of the PIN code which are input.

when the employee number and the PIN code are input from the screen for new entry of a PIN code, the screen for confirmation of the entry of the PIN code is -he subsequently displayed (Fig. 28). Here, by inputting t previously input PIN code again, it is confirmed whether or not the PIN code is correct and therefore the PIN code 28 - was input as intended by the user.

Here, when the PIN code input from the screen for the new entry of a PIN code and the PIN code input from the screen for confirming the entry of the PIN code match, the processing for entry of the PIN code is terminated, and the initial menu screen of the Fig. 19 is displayed on the terminal.

on the other hand, when the PIN code was not correctly input again, a message informing the user of the input-error of the PIN code such as "Please input designated PIN code again,, is.displayed on the screen to prompt the user to input the PIN code again.

Next, an explanation will be made of the processing E the PIN code.

at the time of change of when "change code" is selected on the screen for entry of a PIN code, the terminal displays the screen for change of a PIN code (Fig. 29). When this screen is - that point of displayed, the user inputs the PIN code at time together with its employee number. Due to this processing, the legitimacy of the person desiring to change the PIN code is confirmed.

When the current PIN code is correct, a new PIN code is input from the new PIN code input field (Fig. 30).

Then, Jin the same way as the case of a new entry, the screen for the confirmation of the entry of the PIN code illustrated in Fig. 28 is displayed on the terminal.

When the PIN code is entered, this information is transferred to the cafeteria server side. Then, it is stored in the individual information file linked with the employee number.

The initial menu is displayed again after the entry of the PIN code, so the user desiring to place an order next can select an item from the menu in the same way as at the time of placing a usual order.

Here, if making it possible to input a name, address, etc. in place of the employee number, the processing of Figs. 25A and 25B can be applied for 29 registration for use at general cafeterias. AC this time, as one choice of the method of payment, there is payment by a credit card. when it is hard to identify customers, unlike in an employee cafeteria, it is also useful to request the input of a credit card number etc. and check if there will be a problem in the customer's ability to pay.

Figure 31 is a flow chart of the processing routine on the cafeteria server side after an order is received.

when an order is transferred from the user, the cafeteria server first writes the employee number, date when he or she came, ordered item on the menu, quantity, and information of options if any in the order reception file. Then, the cafeteria server refers to the ingredient file corresponding to the ordered item on the menu.

When the ingredient file is referred to, the cafeteria server next reads the ingredients corresponding to the ordered item and the quantities from the ingredient file and updates the ingredient file based on this. in this, it adds to the quantities for every ingredient stored in the ingredient file the quantities 1 items on the menu newly corresponding to the number of ordered. Here, as previously explained, the ingredient file is used for the.ordering of-the ingredients, therefore where the quantity is less than the unit number, a totaled up quantity rounded up to reach the unit number is recorded in the quantity field.

Next, based on the transferred order, the content oi the serving file is updated. The serving file records the quantities of the items on the menu (including ingredients) which have to be cooked on a certain day for every item on the menu. When a new order is placed, the quantities in the serving file are updated. Similarly, the quantities of the ingredients for every item on the menu are updated.

In the cafeteria system according to the present embodiment, a deadline for acceptance is set for the - convenience in ordering the ingredients. Figure 32 is a view of the processing at the cafeteria server in the case of an order from a terminal. Here, when the terminal is operated for making a selection of an item on the menu, it-is determined whether or not the deadline has passed. when the deadline has not passed, the order is accepted, but when the deadline has passed, the order cannot be accepted.

Further, in order to order the ingredients so as to be in time for cooking on a certain day, for example, it is necessary to order the ingredients from the suppliers in the afternoon of the previous day at the latest. There-fore, when the deadline has been reached, the cafeteria server side reads the content of the ingredient file and orders the ingredients recorded there from the suppliers.

Sometimes a user will want to change the content of or cancel an order he or she placed once. In this case as well, the cafeteria system according to the present embodiment can handle this if before the deadline. Figures 33A and 33B are flow charts for explaining the processing routines for this purpose.

when canceling an order, the user accesses the cafeteria server and. selects the cancellation screen (not particularly illustrated). Then, the cafeteria server determines whether or not the canceling operation has been performed after the deadline. when the deadline has passed, there is a possibility that the ingredients have already been ordered, therefore the cafeteria server cannot accept the cancellation (change) of the order. For this reason, the terminal is instructed to display a screen notifying the user of the fact that the cancellation operation was after the deadline. Simultaneously, it notifies the user of the fact that there is a cancellation fee for cancellation.

Next, the cafeteria server instructs the terminal to display a screen for confirming the possibility of 31-- cancellation. when cancellation is impossible, the order is not canceled and the processing it terminated. on the other hand, when the terminal is operated for instructing cancellation, the cancellation is processed.

Not? that there may also be cases where the cancellation fee is not paid even though of the cancellation was made after the deadline. This is particularly a problem when payment was made at that time, for example, by cash. Accordingly, if an order is canceled after the deadline, it is necessary to confirm whether or not the cancellation fee was paid. It may therefore become necessary to limit use of the cafeteria system for customers who frequently cancel orders after deadlines and do not pay the cancellation fees.

Further, the cancellation may be processed even if the cancellation operation is made before the deadline.

where the cancellation is processed, the cafeteria server side refers to the reception file and reads the order of the related user. The cancellation screen is then edited and transferred to the terminal.

The cancellation screen displays at least the items ordered by the relateduser and the scheduled date of utilization date. Note that when the same user places orders for a number-of days or times, all scheduled dates of arrival at the cafeteria of the related user are displayed in a list and the user is made to select from it. When they will not completely fit on one screen, a split display is also possible.

when the cancellation screen is displayed, the user selects the content to be cancelled and executes the cancellation operation. After the cancellation operation, a screen for confirming the content, of the cancellation is displayed in the same way as the confirmation screen a the time of placing an order. when the cancellation by the user is confirmed on the confirmation screen, the c-'eteriia server corrects or updates the content of each a. file in accordance with the content of the cancellation.

32--- Note that, of course, in the cancellation processing, it is possible not only to cancel the entire content of an order for a certain date, but also to cancel only part. For example, this is the case where it is necessary to cancel only one item out of a plurality of items ordered for the same day.

Further, a change of an order is processed by a similar procedure. In this case, in place of the cancellation, the content of the change is written in each file.

Figure 34 is a flow chart illustrating the routine for processing using the kitchen terminal. The kitchen terminal can display the items on the menu which must be cooked at that day and the quantities thereof. Figure 34 shows the routine for this purpose.

Figure 35 illustrates an example of the screen displayed on the kitchen terminal. In the example of Fig. 35, the items on the menu which must be cooked that day and the quantities thereof are displayed together. In order to display the details, the items to be displayed on the screen of Fig. 35 are selected on the kitchen terminal. For the selection of items, a keyboard or various types of pointing devices can be used. if a touch panel is formed on the screen, items can be selected by just touching the screen.

Here, an explanation will be made of an example where details of the ingredients are displayed for every item. when "pork cutlet on rice" is selected on the screen of Fig. 35, the ingredients required for cooking pork cutlet on rice, the required quantities of the ingredients for cooking all of the servings, and the required quantities of ingredients for cooking one item are displayed together (Fig. 36). Further, a reference field for options is provided at the right corner of the screen. Here, information concerning the existence of any options and the content thereof and the change of- the quantities of the ingredients etc. are displayed. Note 33 - that, in Fig. 36, an example where the ingredients and quantities required for cooking all of the servings and the ingredients and quantities per item are displayed is illustrated, but as will be explained in detail later, it is also possible to display the quantities of the ingredients required for cooking the remaining quantity of uncooked servings in correspondence with the input and display of the remaining quantity of uncooked servings.

when a certain item on the menu is cooked, the kitchen terminal is used to input that it has been cooked. Here, there are also cases where it is difficult to simultaneously cook all ordered items as explained above, therefore it is made possible to input the quantity of the already cooked servings for every item on the menu. The content of this is reflected in the serving file and the quantity of orders in the serving file is updated (reduced) by the amount of the already cooked servings. The kitchen terminal may be used to confirm if all servings have already been cooked or how many servings remain uncooked.

An information field indicating that all servings have finished being cooked is also set in the screen of Fig. 35. When the predetermined number of servings of the related item on the menu has finished being cooked, a mark indicating this (a circle in the illustration) is added. By this, it can be seen at a glance that it is not necessary to cook more grilled fish sets in the case of that all of the items on the menu which Fig. 35. Note -11 have not yet finished being cooked are not particularly displayed in Fig. 35. In order to display the remaining number of uncooked servings, an item on the menu is selected by using the kitchen terminal. when using a touch panel, the remaining number of uncooked servings of a related item on the menu is put on display by touching the field of finished cooking for the specific item on the menu.

Figure 37 shows an example of display of a screen 34 showing the remaining number of uncooked servings of park cutlet on rice. Here, together with the entire remaining number of uncooked servings, the remaining number of uncooked servings is displayed for each of the options, includiny normal servings. By performing such a display, every item on the menu can be cooked without waste or shortage in the kitchen.

Note that it is possible to display the remaining quantity together with the finished cooking screen o-f Fig. 35. In this case, the procedures of switching screens can be reduced. Note, if the options are displayed on the screen of Fig. 35 together, there is a possibility that the screen might be too fine and hard to see, therefore the remaining number of uncooked servings including the options is preferably displayed on a different screen. In this case, it may be required to display, for example, the remaining number of uncooked servings in the "finished cooking" field of Fig. 35.

Figure 38 shows an example of a screen for checking the delivery of goods displayed on the kitchen terminal. This screen is used for confirming whether or not ingredients were actually delivered for every ingredient. A circle is added to the ingredients whose delivery was confirmed on the screen. when for example there are reasons for a shortage etc., this is displayed too (triangle in the illustration).

Figure 39 illustrates the part of a keyboard used in the kitchen terminal. Function keys for instructing specific functions are arranged together with the ten-key portion. AS the function keys, in the illustrated example, functions such as "confirm special order (option)", "confirm check", "see ingredients", "input finished cooking", and "see notes" are set, but they can be suitably changed. For example, if the "see ingredients" function key is pressed, the screen of Fig. 38 is displayed.

Figure 40 is a flow chart illustrating the NI - 35 - processing and operation routine when a user comes to the cafeteria. Here, a case where an ID card is utilized is used as an example.

When the user arrives, he or she inserts his or her ID card into the counter terminal. This processing may also be performed by manually inputting the employee number from the terminal as illustrated.

By this, the counter terminal refers to the cafeteria server and reads the information concerning the items on the menu ordered by the related user from the reception file and displays them on the counter terminal (Fig. 41). In addition, it displays the information indicating where he or she can obtain the ordered items.

This can be handled by storing information in advance in the reception file or the menu file, while linking counters with every item on the menu.

Further, it displays information as well for the customer who orders an option to confirm that the option was ordered.

Here, the fact that a user, who placed the order attaching special conditions such as options, arrived at the cafeteria is displayed on the kitchen terminal etc.

by the insertion of the ID card and the reading oil his or her ID. Due to this, the option such as a large serving can be reliably served to the related user.

when the user receives the ordered item, the number of received items is subtracted from the serving file. By this, it becomes possible to confirm the remaining amounts of the items on the menu at all times.

When the content of an order is recorded in an IC card, it is not necessary to refer to the cafeteria server at the time of display of the ordered items.

Further, for the payment, the method of payment is designated in advance at the time of the order.

Therefore, when the customer utilizes the cafeteria terminal, it displays a screen requesting that he or she 11 will should confirm the method of payment. when the bl 36 - be deducted from the salary or there will otherwise be no transfer of cash on the spot, the terminal will display "paid,, or the like. On the other hand, in a case where payment by.cash or payment by credit card is selected, the termnal displays information for guiding the customer to another cash counter for such payment.

Here, in order to prevent customers from cheating, an alarm may be activated or another means adopted when a person designating payment by cash does not pay.

Figure 42 is a flow chart of the processing after the check.of ingredients. When the i.ngredients are checked, a check flag of the serving file is added in accordance with its input. Further, the content of the serving is read from the file by instruction from the kitchen terminal and displayed on the kitchen terminal.

Each time an item on the menu is cooked, the cooked item and the quantities thereof are input from the kitchen terminal to update the quantity etc. in the serving file.

Figure 43 is a view of the example of the screen displayed at a terminal when a cafeteria is booked full at the designated date and time of utilization as a result of orders, which is particularly useful in the C _case of. use c--" the system for a reservation-only restaurant. At the bottom of the screen, a confirmation field is set.

Here, since the terminals and the cafeteria server are connected by a network, the requests of the users etc. can be easily conveyed to the cafeteria side.

Therefore, it is also possible to make the terminal display a questionnaire screen and to ask users to input items which they would like to see on the menu in the future from the questionnaire screen.

The cafeteria server totals the answers of the questionnaires from users. Due to this, it becomes possible to know the preferences of the users and to offer a menus tailored to the demands of the users.

Heretofore, menus have been determined according to past results on the cafeteria side or menus have been determined based on the culinary trends in the world. It is very difficult to add new items to a menu in the former case and impossible to provide foods desired by the users any longer if the gap between world culinary trends in the world and the actual customers of the cafeteria becomes too great in the latter case.

According to the present embodiment, such problems can be solved and the service provided to the users can be improved.

Note that, in the above embodiment, the explanation was made of an example where the same quantities of ingredients were ordered and the number of servings prepared as the number of servings ordered by the customers. However, leaving aside restaurants requiring reservations, there is also the possibility of walk-in customers on the day in question. In such a case, if only the reserved servIngs of food are prepared, a customer who walks in on that day without a reservation cannot be served at the restaurant or will end up eating the food intended for others, so there will be a possibility that a customer who placed a reservation cannot be served his order.

In order to cope with such a case, it may be considered to slightly increase the quantities of ingredients to be ordered or increase the number of servings that day. Specifically, the numbers of servings and the quantities of ingredients set in the ingredient ordering file of Fig. 6 and the serving file of Fig. 7 are recorded slightly increased. That is, the ingredients are ordered in slightly larger amounts than the actual quantities necessary for preparing the reserved servings and larger numbers of servings are prepared.

Here, it is the most reliable for the cafeteria side Lo decide on the amount of increase by experience, but when there are no grounds 11or making such decisions, it 38 is simplest to just increase the quantities uniformly for each item on the menu.

However, such excessive ordering and cooking may result in waste. Nevertheless, when compared with a case of predicting from nothing the quantities of ingredients required and the number of servings required that is, from a state where no base figures exist, when the ordering system is used to obtain reservations in advance, the minimum required quantities can be determined in advance and therefore the waste in orders and cooking can. be reliably reduced.

Further, in such a case, it is necessary to secure the reserved food for the customers who placed reservations. For this purpose, it is necessary to maintain a constant grasp over the number of servings which can be provided to customers who did not make reservations.

The number of servings which can be provided to customers who did not make reservations corresponds to the total number of servings prepared minus the number of reserved servings. This amount is kept separate from the reservations. Whenever a customer comes in, it is determined by the use of an ID card or the like whether or not this customer is a customer who has already made a reservation. The destination to which the customer is led to is varied in accordance with whether or not he had made a reservation.

Customers who made reservations are led to a destination for serving customers with reservations. Customers who did not make reservations are led to a destination for serving customers without reservations. in both cases, the remaining servings are calculated whenever food is served. Particularly, the remaining amount of servings for customers who have not made reservations is constantly displayed. Preferably, a message indicating "no servings remaining" is displayed for the items on the menu which have run out.

39 - Alternatively, a list of items which can be served and the quantities thereof can be displayed so that customer without reservations can decide at a glance what is available when coming to the restaurant.

Further, since the ordering system has not confirmed the identity of a customer walking in without a reservation, it is preferable that the customer be asked to indicate the method of payment, for example, cash, and to avoid the deduction of the bill from the salary or the like to avoid later trouble.

When an embodiment of an ordering system according to the present invention is used, one or more of the following effects can be achieved:

1) Particularly in the case of a cafeteria or restaurant, it can be determined what items on the menu have been ordered in what quantities in advance. For this reason, the number of servings to prepare and quantities of ingredients to order may be determined in accordance with those numbers and therefore efficient operation of the cafeteria or restaurant becomes possible without having to depend upon intuition.

2) The contents of orders from customers can be automatically totaled and updated, so the cafeteria side can be saved the troublesome procedure of totaling the bills.

3) Ingredients may be ordered to suppliers automatically according to the contents of orders, therefore the cafeteria side can prevent errors in orders or the like.

4) Customers can easily place orders by using personal computers or the like from offices or the like in advance. Since it becomes easy to reserve tables and food at restaurants, the customers enjoy greater convenience. Further, since the cafeteria side orders the ingredients and prepares the servings in accordance with the contents of the orders, the possibility of a customer not being able to be served his or her desired food becomes very low.

5) Since the method of payment can be selected s in accordance with the customer or the circumstance, the customers enjoy greater convenience.

6) Since orders are accepted in advance, the ingredients may be ordered and the food cooked according to the number of orders. For this reason, there is extremely less apprehension of the over ordering and wasted cooking of ingredients when compared with the conventional case.

Although embodiments of the present invention as described hereinbefore have been for use in a is cafeteria, it will be appreciated that an ordering system embodying the present invention can be used in many other situations. For example, the ordering system could be used in a computer-aided manufacturing (CAM) system in which products such as personal computers are manufactured. As is well-known, a range of personal computer products may share the same basic platform (e.g. casing and motherboard etc), but different models within the range will be equipped with different optional facilities or modules (e.g. CD Rom drive, memory). In this case, the "menu" would be a list of the available models in the range (first file of claim 23). The "ingredient file" (second file) would store the identities of the optional modules required by each module and the quantities of such modules (e.g. random access memory (RAM) modules). The "reception file" (third file) would store a list of the modules ordered by each user (for example a distributor). The "ingredient totalling file" (fourth file) would store the total quantity of each module required to meet the order concerned. The "serving file" (fifth file) would store the information concerning the models which have to be produced within a certain period (e.g. by the end of that day or production period, the quantities of those models and the modules required to produce the models). The CAM system would use the information in the "serving file,, to operate automated production facilities. Thus, an embodiment of the present invention can provide a manufacturing method employing an ordering system as described above.

-42

Claims (30)

1. An ordering system provided with a cafeteria server and a terminal operated by a user of the cafeteria connected to each other by a transmission line, wherein the cafeeria server is provided with:

   a menu file for storing information concerning the menu provided by the cafeteria, an ingredient file for storing names of ingredients and quantities which become necessary for every item on the menu stored in the menu file, a reception file for storing information concerning the iLtems on the menu ordered by the user from said terminal, an ingredient totaling file for totaling the quantity which will become necessary for every ingredient based on the order by the user, and a serving file for storing information concerning the items of the menu which have to be cooked during a certain period, the quantities thereof, and the ingredients required for cooking the items of the menu therein.
2. 2. An ordering system as set forth in claim 1, wherein, in said cafeteria server, information concerning suppliers for every ingredien t is stored in said ingredient totaling file.
3. 3. An ordering system as set forth in claim 2, wherein:

   said cafeteria server is connected to a terminal provided at a supplier by a transmission line; terminal identification information of the supplier is stored in said ingredient totaling file; and order information is transmitted to the supplier terminal over the transmission line according to said terminal identification information at the time of said cafeteria server ordering ingredients.
4. 4. An crdering sjstEm as set fcrth in a-y pmcadiM claim, wherein a deadline for accepting orders fro-m, users is set and the ingredients are ordered based on the information o"L the ingredient totaling file after the deadline is reached.
5. 5. An ordering system as set forth in any preceding claim, wherein information concerning the names of the items on the menu ordered by users and the quantities of the same, utilization time, method of payment, and special requests is stored in the reception file.
6. 6. An ordering system as set forth in any preceding claim, wherein information concerning the quantities of items on the menu already prepared is stored in said serving file.
7. 7. An ordering system as set forth in claim 6, wherein the quantity of uncooked food is calculated based on the quantities of items on the menu already prepared and the quantity of uncooked food displayed on a screen.
8. 8. An ordering system as set forth in any preceding claim, wherein information concerning the quantity of uncooked food is stored in said serving file for every item on the menu.
9. 9. An ordering system as set forth in any preceding claim, wherein a flag for indicating whether supplies have been delivered for every ingredient is set in said servIng file.
10. 10. An ordering system as set forth in any preceding claim, wherein aflag for indicating whether supplies have been delivered for every ingredient is set in said ingredient totaling file.
11. 11. An ordering system as set forth in any preceding claim, wherein photo information is stored for every item on the menu in said menu file.
12. 12. A data processing unit installed in a cafeteria, provided with a menu file for storing information concerning the menu provided by a cafeteria, an ingredient file for storing names of ingredients and quantities which become necessary for every item on the menu stored in said menu file, a reception file for storing information concerning the items on the menu ordered by a user, an ingredient totaling file for totaling the quantity which will become necessary for every ingredient based on the order by the user, and a serving file for storing information concerning the items of the menu which have to be cooked during a certain period, the quantities thereof, and the ingredients required for cooking the items of the menu therein.
13. 13. A data processing unit as set forth in claim 12, wherein:

    said data processing unit is connected to an order terminal from which a user inputs content of his or her order and the order of the user is accepted in accordance with the operation of said order terminal.
14. 14. An ordering system for receiving an order from a customer, provided with:

    a terminal for a customer to input the content of an order and a server for receiving an order input from said terminal, the server provided with:

    a product file for storing information concerning the products which can be ordered by a customer and an order file for storing the content of orders including products selected by a customer.
15. 15. An ordering system as set forth in claim 14, wherein said server is further provided with an order file in which information concerning products and suppliers for every product are stored.
16. 16. An ordering system as set forth in claim 14 or 15, wherein said server is further provided with a file in which an inspection flag is set for indicating whether or not a oroduct ordered to a supplier is delivered.
17. 17. An ordering system as set fcrth in any of claims 14 to 16, wherein the order file stores the content of special requests made by a customer.
18. 18. An ordering method in an ordering system for receiving an order from a customer, comprising:

    displaying information concerning products which can be ordered on an order terminal and updating the content of the order file storing the information concerning the content of the orders provided in a reception terminal in accordance with the selection of a product from the order terminal.
19. 19. An ordering method in an ordering system for receiving an order from a customer, comprising:

    displaying a screen of a list of products which can be ordered on an order terminal from which a customer inputs the content of an order, displaying a screen of an order form for inputting the content of an order on the order terminal in accordance with the selection of a product by the customer; displaying a confirmation screen for allowing a customer to confirm the content of an order by the order terminal in response to the input of the content of the order from the order form screen; and accepting the order after an operation by the customer confirming the content displayed on the confirmation screen.
20. 20. An ordering method as set forth in claim 19, further comprising, when displaying a list of products:

    first displaying a screen of a list of large classifications of products which can be ordered by the customer and displaying a screen of a list of small classifications of products belonging to a large classification of products selected from the screen of the list of large classifications by the customer.
21. 21. An ordering system for receiving an order for a product from a customer from an order terminal, comprising:

    judging, when an order from a customer has been input, if the deadline for receiving the order has passed or not, accepting, when the deadline has not passed, the order from the customer, and displaying, when the deadline has passed, a message indicating tha-L the deadline has passed on the order terminal and not accepting the order.
22. 22. An ordering system for receiving an order for a product from a customer comprising:

    a shop server having a menu file for storing information concerning products which can be served from the shop; and a terminal connected with said shop server by a network and operated by the customer, thereby said shop server is accessed by said customer through said terminal to select the product stored, as information, in said menu file so that the order for the selected product is accepted.
23. 23. Ordering apparatus including server means and user-operable terminal means connected together by transmission line means, wherein said server means is provided with:

    a first file for storing information concerning items available to be ordered; a second file for storing first item data and second item data associated with each item for which information is stored in the first file; a third file for storing information concerning the items ordered by the user from said terminal means; a fourth file for totalling the second item data which will become necessary for every class of is first item data based on the order by the user; and a fifth file for storing information concerning processing of orders of the available items.
24. 24. Ordering apparatus as claimed in claim 23, for use in a cafeteria, wherein:

    the said server means is a cafeteria server; the user-operable terminal means are operable by a user of the cafeteria; the said first file is a menu file and the said items available to be ordered are taken from a menu provided by the cafeteria; the said second file is an ingredient file in which the first item data specifies names of ingredients for each item on the menu and the second item data specifies the quantity of the or each ingredient concerned; the third file is a reception file; the fourth file is an ingredient totalling file for totalling the quantity of each named ingredient specified by such first item data in the said second file; and the said fifth file is a serving file for storing information concerning the items of the menu which have to be cooked during a certain period, the quantities thereof and the ingredients required for cooking the items of the menu therein.
25. 25. 'A computer program which, when loaded into a computer system, causes the computer system to become an ordering system as claimed in any one of claims 1 to 11, 14 to 17 and 21 and 22.
26. 26. A computer program which, when run on a computer system, causes the computer system to carry out an ordering method as claimed in claim 19 or 20.
27. 27. A computer program which, when loaded into a computer, causes the computer to become a data processing unit as claimed in claim 12 or 13.

    is
28. 28. An ordering system substantially as hereinbefore described with reference to the accompanying drawings.
29. 29. A data processing unit substantially as hereinbefore described with reference to the accompanying drawings.
30. 30. An ordering method substantially as hereinbefore described with reference to the accompanying drawings.