(57)【要約】【課題】　本発明は、食堂等のオーダリングシステムに関する発明である。従来の食堂では、来客数の把握や材料の発注数、調理すべき料理の数量の把握は担当者がこれまでの傾向や勘に頼って決定していたが、実際の来店数と大きく異なる可能性が高く、料理や材料が無駄になる可能性や、逆に料理数が足りなくなる可能性が高い。そのため、本発明はこのような問題点を解決するためになされた。【解決手段】　メニューファイル、材料ファイル等を備えたサーバと、端末装置ＰＣとをネットワークにより接続、端末装置ＰＣからサーバをアクセスして注文を行う。客はメニューファイルから読み出された食堂のメニューに関する情報から、注文しようとするメニューを選択する。また、客からの注文に応じて、当日調理すべきメニューとその数量、発注が必要となる材料とその数量に関する情報を逐次更新する。【選択図】　図１
2004078986.tif 000002
【特許請求の範囲】
【請求項１】
顧客からの注文を受け付けるオーダリングシステムにおいて、顧客が注文内容を入力する端末装置と、前記端末装置から入力された注文を受け付けるサーバとを備え、前記サーバには、顧客が注文可能な商品に関する情報を格納する商品ファイルと、顧客が選択した商品を含む注文内容を格納する注文ファイルと、を備えたことを特徴とする、オーダリングシステム。
【請求項２】
前記オーダリンクシステムにおいて、前記サーバは更に、商品と、商品毎の発注先に関する情報が格納される発注ファイルを備えることを特徴とする、請求項１記載のオーダリングシステム。
【請求項３】
前記オーダリングシステムにおいて、前記サーバは更に発注先に発注された商品が納入されたか否かを判別する検品フラグが設定されるファイルを備えることを特徴とする、請求項１記載のオーダリングシステム。
【請求項４】
前記オーダリングシステムにおいて、前記注文ファイルは顧客によりなされた特別注文内容を格納することを特徴とする、請求項１記載のオーダリングシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
　本発明は、食堂等を始めとする店舗での注文受付に用いられるオーダリングシステムに関するものであり、特に社員食堂などのカフェテリアの形態を取る食堂に適したオーダリングシステムに関する。
【背景技術】
【０００２】
　各種の食堂の中でも、社員食堂や学生食堂といった食堂はカフェテリア形式を採用する例が多い。これらの食堂に限らず、カフェテリア方式の食堂では予め調理済の料理を棚に並べておき、来店者が自分の好みの料理を棚から取り、その後精算が行われるケースが大半を占める。
【０００３】
　このような食堂の場合には従って、事前にある程度の数量の料理を、事前に調理しておく必要がある。また、料理の選択の幅を広げるためには、複数種類の料理を調理しなくてはならない。また、この他の形態の食堂では、客が来店して料理を注文した後に、料理が調理される。しかし、この場合であっても料理の下準備は行っておく必要がある。そして、一品毎に調理できないような料理については、多人数分予め調理しておく必要もある。
【０００４】
　更に、どのような形態の食堂でも、事前に材料を注文しておく必要がある。材料の発注量は、必要とする最小限の数量に止めることが色々な意味から望ましい。
【発明の開示】
【発明が解決しようとする課題】
【０００５】
　ここで、食堂の一般的な問題として、ある日の、あるいはある時間帯の来店者数を事前に予測することが非常に難しい点を上げることができる。長年営業していれば、それまでの経験則からおおよその来店者数を予測することはできるが、日付や曜日、その日の天候、各種行事催行等の条件により、来店者数は大きく増減する。また、来店者個人の都合という、予測がまず不可能な条件も加わる。従って、実際の来店者数が予測来店者数とは異なるケースも多い。
【０００６】
　来店予想は、当日の調理数や材料の発注数を決定するために非常に重要な要素となる。特にカフェテリア方式の食堂では事前調理が必要であるため、来店者に合わせて調理する数を適宜調整することが困難である。これらの調理・発注数は予測来店数により決定されるが、予測来定数と実際の来店数とが異なった場合、以下のような運営上の問題がでてくる。なお、調理・発注数量は、予測来店者数に基づいて決定されているものと仮定する。１）来店者数が予測数を上回る場合この場合には、料理の数や発注した材料が不足する可能性が非常に高い。料理が不足した場合には、後からの来店者に対して料理を提供することができなくなる。常に提供できる料理が不足気味である状況が続くと、その店は十分な料理を提供できないということで、店の信用にも影響を与える可能性がある。２）来店者数が予測数を下回る場合この場合には、仕入れた材料や調理済みの料理が無駄になる可能性が非常に高くなる。特に生鮮食品の中には保存が効かないものもあり、これらについては余った分は廃棄せざるを得ない。
【０００７】
　また、特にカフェテリア形式の食堂の場合には、客が来店した時点ですぐに料理を手にすることができるようにする必要がある。そのため、事前調理が絶対的に必要であるが、未調理の材料については翌日まで取っておくことができるとしても、調理済みの料理については保存ができず、その日のうちに消費する必要がある。そのため、余った調理済みの料理についても、場合によっては廃棄せざるを得ない。
【０００８】
　ここで、廃棄される料理については、全て店の損となってしまい、廃棄量が多くなればなるほど、店の負担は増える。また、調理済みの料理の廃棄量が常に多い状況が続くと「食べ物を粗末にする店」といった風評が立つ恐れもあり、店の信用問題にもかかわってくる。材料の余剰分は、仮に保存がきいたとしても、保存のための施設への投資などが必要となってくる。また、発注量は常に必要となる分に抑えないと、保管等のコストを考えればこれも店の負担・損失となってしまう。そのため、材料の発注数・事前の調理数は可能な限り抑えることが望ましい。
【０００９】
　その一方で、来店した客に料理を提供できないという事態も、サービス業である以上どうしても避けなければならない。従って、この場合には、発注数や事前の調理数を予測数値よりも割増して考えなければならなくなる。このように、食堂運営上材料の発注数や調理数は非常に大きな問題となる。本発明はこのような問題に鑑み、効率的な材料の発注や調理を行うことができるオーダリングシステムを実現することを目的とする。
【００１０】
　また、本発明は、発注すべき材料数や調理すべき数量を、自動的に算出・更新が可能となるオーダリングシステムを実現することを目的とする。なお、商品の発注数量等の自動的な算出・更新や、ある日に最低限必要となる商品数量を事前に把握するという効果は、食堂以外の店舗や各種通信販売においても適用可能であることはいうまでもないが、以下特に食堂システムに本発明を適用した例について説明する。
【課題を解決するための手段】
【００１１】
　上記した課題を解決するために、本発明は、顧客からの注文を受け付けるオーダリングシステムにおいて、顧客が注文内容を入力する端末装置と、前記端末装置から入力された注文を受け付けるサーバとを備え、前記サーバには、顧客が注文可能な商品に関する情報を格納する商品ファイルと、顧客が選択した商品を含む注文内容を格納する注文ファイルと、を備えたことを特徴とする。
【００１２】
　また、前記オーダリンクシステムにおいて、前記サーバは更に、商品と商品毎の発注先に関する情報が格納される発注ファイルを備えることを特徴とする。また、前記オーダリングシステムにおいて、前記サーバは更に発注先に発注された商品が納入されたか否かを判別する検品フラグが設定されるファイルを備えることを特徴とする。
【００１３】
　また、前記オーダリングシステムにおいて、前記注文ファイルは顧客によりなされた特別注文内容を格納することを特徴とする。
【発明の効果】
【００１４】
　このようなオーダリングシステムを用いることで、以下のような効果を実現することができる。１）特に食堂の場合には、事前にどのようなメニューがどの位注文されているのかを判別することができる。そのため、調理・材料発注数をその数に合わせて決定すればよく、勘に頼ることなく、効率的な食堂運営が可能となる。２）客からの注文内容を自動的に集計・更新することができるため、店側は煩わしい集計のための手間が省ける。３）自動的に各発注先に対して、注文内容に応じて材料等の発注を行うため、店側は発注ミス等を防止することができる。４）客側からは、事前に、職場等に設置されているパソコン等を用いて、簡易に注文を行うことができる。食堂の場合には予約を簡単に行えるため、客としても利便性が高くなる。また、食堂側は注文内容に合わせて材料発注／調理を行うため、客は注文したメニューを受け取れないという問題が生じる可能性が非常に低くなる。５）支払い方法を客や状況に応じて選択可能としているため、客としては利便性が高くなる。６）予め注文を受け付けているため、材料発注／調理はこの注文数に合わせればよい。そのため、無駄な材料の発注／調理の恐れが従来と比較して非常に低減される。
【発明を実施するための最良の形態】
【００１５】
　図１は、本発明の一実施形態における食堂システムのシステム構成を図示する図面である。ここでは特に、社員食堂への適用例について説明するが、この他の形態の食堂であっても当然本発明は適用可能であり、この他にも一般的な通信販売などの各種オーダリングシステムに対応可能であることはいうまでもない。
【００１６】
　本実施形態による食堂システムは、大きくわけて食堂サーバ、食堂用の端末、客（つまり社員）側に設けられた一乃至複数の端末装置、社員サーバが備えられる。食堂サーバ、端末装置および社員サーバはネットワークにより接続されている。社員サーバは、従業員データベースや給与データベースを備えている。社員食堂を利用する場合に給料天引で支払う際には、社員サーバに登録されている給与口座から利用した分の料金を天引する。
【００１７】
　ここで、社員食堂等の場合にはＬＡＮ等を利用すればよいが、不特定多数の客の利用が予想される一般の食堂の場合には、近年特に普及しているインターネット等を使用するようにすればよい。図２は、食堂側の構成を更に詳細に図示した図面である。図２の例では、食堂側には食堂サーバ、厨房用端末、発注管理用端末、受付用端末、売場端末が備えられる。なお、食堂側の端末装置はこれらに限定されるものではなく、他の端末装置が備えられていても、また図２に図示された各端末装置の機能を一台の装置に統合するようにしてもよい。食堂側の構成は、食堂の規模等によって適宜変更が可能である。
【００１８】
　食堂サーバには、各種のファイルが設けられている。以下、これらのファイルについて説明する。図３は、メニューファイルの構成を説明する図面である。図３（Ａ）は大分類ファイル、図３（Ｂ）は小分類ファイルである。メニューファイルには、食堂が提供できるメニューに関する情報が格納されており、客が注文する際にはこのメニューファイルが参照される。
【００１９】
　大分類ファイルには、食堂が提供できるメニュー内容の大分類が格納されている。図３（Ａ）の例では「洋食」「和食」「中華」「丼物」等の項目が設定されている。図３（Ｂ）に図示される小分類ファイルは、大分類ファイルとリンクされるように構成されている。そして小分類ファイルには、大分類毎にメニュー名と値段、熱量に関する情報が対になって格納されている。図３（Ｂ）の場合には、大分類ファイルで「丼物」が選択された場合のリンク先となる、「丼物」小分類ファイルが図示されている。
【００２０】
　またメニューファイルには、図３には詳細は図示されていないが、メニュー毎の写真が小分類ファイル内のメニュー毎にリンクして格納されている。メニュー写真は、客側の端末で表示され、メニューの内容を視覚的に認識してもらうために使用される。図４は材料ファイルの構成を説明する図面である。材料ファイルは、メニュー毎に、１品調理するのに必要となる材料名とその数量に関する情報が対に格納されている。
【００２１】
　例えば図４の例では「カツ丼」が例示されている。ここでは「ごはん」つまり米が１合、「豚肉」が１００グラム、「たまねぎ」が１／４個、「卵」が１個などの情報が格納されている。これらは、「カツ丼」を一つ調理するのに必要な材料と、その数量を示す。また、大盛りの場合には材料が１割増しとなる旨、情報が設定される（図示されず）。
【００２２】
　このような「大盛り」の割増量などのオプション情報は、材料ファイルにメニュー毎に設定してもよいし（「ごはん」＝「１．１合」と記録するか、「１割増」と記録する）、例えば「大盛り」が選択された際に材料ファイル内の数量を一律かつ自動的に割増するようにしてもよい。前者の場合には、材料ファイル内に割増量を格納しておく必要かあるのに対し、後者の場合には通常時の数量のみをとりあえずは設定しておけばよいが、割増量を算出する必要がでてくる。
【００２３】
　また、前者の場合には、メニュー毎に、あるいは材料毎に大盛りのときの割増量を変えて設定することも可能である。例えば「ごはん」のみ１割増とし、その他は割増しないといった設定も行うことができる。また大盛りに対応できないメニューがある場合には「大盛り不可」という情報をメニューファイルに加えることもできるため、よりきめ細かな対応が可能となる。これに対し、後者の場合には材料ファイルの構造が単純になるため、特に食堂サーバ側に余裕がない場合などには適していると言える。
【００２４】
　図５はオーダ受付ファイルの構成を説明する図面である。オーダ受付ファイルは、客を識別する情報（社員食堂を例示しているため図５では従業員番号）、利用日時、注文品とその数量、オプション（大盛り等の特別注文）とその数量並びに支払い方法に関する情報が格納されている。ここで、社員食堂を対象とするのであれば、基本的には料金の支払いは給料天引とすることができるであろう。ただし、社員食堂といっても外部の者が訪れる可能性もあり、このような者に対しては給料天引はできないため、現金払いやプリペイドカード、ＩＣカード（電子マネー）等の支払いにも対応できるようにする必要がある。また、社員の中には、食堂の利用は給料天引ではない方を選ぶ者もいる。図５に図示されるオーダ受付ファイルでは、これらに対処できるように、支払い方法に関する情報が注文内容と一緒に格納される。
【００２５】
　支払い方法は注文時に指定されるが、この指定方法の詳細については詳細後述する。なお、支払い方法としてはこの他にクレジットカードによる支払いも可能である。また、会員制の店の場合を想定すると、客の氏名は予め店側に登録されている。これは社員食堂の例の社員と食堂の関係にも似ている。このように来店者が特定できる場合（言い換えれば「飛び込み」の客の来店を考慮する必要がない場合）には、客毎に支払い方法を一律に設定することも可能である。客が特定できれば支払い方法も特定できるのであれば、オーダ受付ファイルからは支払い方法に関する情報設定欄を削除することもできる。
【００２６】
　図６は材料発注ファイルであり、食堂が材料を発注する際に利用されるものである。この材料発注ファイルには、メニューとは無関係に食堂が発注すべき材料と発注数、そして発注先に関する情報が格納される。材料発注ファイルの内容の更新方法については詳細は後述するが、オーダ受付ファイルに格納されている注文されたメニューの数量と、材料ファイルに格納された各メニューの材料毎の必要数量とを参照して、材料数量が逐次更新される。そして、食堂側では材料発注ファイルに格納された数量分、各発注先に対して材料を発注する。
【００２７】
　ここで、例えばたまねぎを発注する場合に、一個未満を発注することはできないであろう。この場合、材料発注ファイルに格納される材料の数量に端数が生じる場合には、端数分を自動的に単位数に切り上げる。たまねぎの例であれば、注文数と材料ファイルに格納された必要数とに基づいて算出された必要数が１個未満の端数を生じる場合、合算した端数が１個に達するまで合算数量を自動的に１個に切り上げる。
【００２８】
　また、発注先情報としては、図６の場合には発注先名が記録されている。ここで、発注先にもネットワークで接続された端末装置が設置されている場合には、これを利用することが可能である。そのため、これに対処するためには、発注先毎のメールアドレスなどを格納しておき、発注時にこれを参照して自動的にネットワークを介して発注情報を各発注先に伝送するようにしてもよい。当然のことながら全ての発注先がネットワークで接続されているわけではないので、この場合には電話／ファクス番号等を発注先明とともに記録すればよい。
【００２９】
　また、「納入日」の欄には、注文した材料が納入される予定日が設定されている。この「納入日」情報は、材料が納入されたか否かのチェックに用いることもできる。つまり、材料が納入されるべき日に、材料発注ファイルを参照して、その日が納入予定日となっている材料に関する情報（材料名）を読みだす。そして、各材料毎に納入されたか否かを確認するのである。
【００３０】
　図７は献立ファイルである。ここには、ある日（図示の例では１月１３日）に調理する必要があるメニューについて、必要数量と、調理する上で必要となる材料とその数量が対応づけて格納されている。また、献立ファイルには材料の納入日（予定日）と、材料が納入されたか否かを識別するための検品フラグが設定される。なお、納入日と検品フラグについては、別ファイルとすることも可能であるし、また材料発注ファイルと内容が一部重複するため、一方のみを設定するようにしてもよい。
【００３１】
　献立ファイルに格納された情報は、厨房端末や売場端末に送られて、調理する上で必要な情報がこれらの端末上に表示される。厨房を例にとれば、その日に調理する必要があるメニューとその数量、材料数等を厨房端末に表示することができる。これによって、調理時に何をどれだけ調理すればよいのかを一目で確認することができる。さらに、当日利用するために調理済みの数量が書き込まれる欄も、献立ファイルには設定されている。この欄は、調理時にどのくらいの数が調理済みなのか、あるいはあとどれくらい調理すればよいのかを厨房で把握するために用いられる。
【００３２】
　メニューによっては、注文された数量を一度には調理しきれない可能性があるので、このときには同じメニューを数度に分けて調理しなければならない。この際に、いくつ調理済なのか、あるいはあといくつ調理する必要があるのかという情報を厨房端末に表示することは運用上非常に有効である。そこで、献立ファイル内に上記した情報を格納し、厨房端末に情報を表示する際には調理済み数あるいは残未調理数を表示する。
【００３３】
　また、大盛りなどの特別注文（オプション）がある場合には、この情報も献立ファイルに設定する。図７では図示されていないが、大盛り等のオプション品の数量を、全体の要調理数とは別に献立ファイルに書き込めばよい（内数でも可）。これによって、どのようなオプション品を、いくつ調理すればよいかを厨房端末に分かりやすく表示することができるし、調理間違いなども低減できる。
【００３４】
　図８は個人設定ファイルであり、図８の例では従業員番号と客毎のパスワードとが対になって設定されている。これは客が注文する際に入力するパスワードとの照合を行うために用いられるものであり、通常の操作ではみることはできないように構成される。図８の場合には、客毎に支払い方法を特定していないケースを想定している。ここで、前述したような会員制の店のように、客が特定できれば支払い方法も特定できるようなケースもある。この場合には、個人設定ファイルに支払い方法を記録する欄を設定する。また、現金払いのみを認めるケースのように、客に関わらず支払い方法が一律となるケースの場合には、支払い方法に関する情報をいずれのファイルにも設定しなくてもよい。
【００３５】
　本実施形態では、これらのファイルが食堂サーバに設定される。なお、各図に図示されたファイルの内容を一つのファイルにまとめるような変形も、当然可能である。図９は、端末装置側の構成例を図示する図面である。近年職場にパーソナルコンピュータが設置されるケースが増えているので、端末装置は通常のパーソナルコンピュータ等を用いることができる。また、注文専用の端末装置を利用することも当然可能である。ここで、パーソナルコンピュータにはプリンタが備えられているケースが殆どであり、またＩＣカードリーダ／ライタ（図示Ｒ／Ｗ、以下同様に表記）も接続が可能となっている。客が注文する場合には、これらのプリンタやＲ／Ｗも用いる。
【００３６】
　客が注文する場合、職場毎に設置されているプリンタを用いて食券が発行される。通常のプリンタを使用することによって、新たな食券用のプリンタをわざわざ設置する必要はない（設置することも可能ではある）。また、近年では従業員証としてＩＤカード（磁気カードやＩＣカード）が使用されていることから、食堂利用時にこのカードを使用することが考えられる。特にＩＣカードは記憶容量が大きいため、食券の変わりに注文した内容をＩＣカードに書き込むようにすれば、プリンタを用いて食券を印刷する必要はない。
【００３７】
　図１０は、端末装置内部の構成を示すブロック図である。端末装置は、処理を司るＣＰＵ、ネットワークとの通信を行う際に使用される通信制御部、各種のプログラムを格納するとともに、注文時に入力された内容が一時的に格納されるメモリ、ディスプレイ、プリンタ、情報入力用のキーボード、カードＲ／Ｗが備えられる。
【００３８】
　図１１は、食堂側の受付端末／管理端末の構成を図示する図面である。これらの端末についても、通常のパーソナルコンピュータを使用することができ、図１０に図示された端末装置と同様な構成である。図１１の場合には特にプリンタ、カードＲ／Ｗは図示省略されているが、これは本実施形態において必須となる機能を実現するための最小限の構成のみを図示したためであり、必要に応じてこれらを備えていてもよいのは当然のことである。
【００３９】
　図１２は食堂の売場毎に設置される売場端末の構成を図示する図面である。売場端末は一般的なパーソナルコンピュータ等でもよいが、来店時に客に操作してもらうことを考慮するならば、利用者の利便を考えて専用端末としてもよい。売場端末には、ディスプレイやカードＲ／Ｗが設けられる。カードＲ／Ｗには従業員のＩＤカードが差し込まれる。ＩＤカードにその従業員が注文した内容が書き込まれている場合には、ここから読みだされた注文内容に応じて、ディスプレイにはその客が注文したメニューに関連する情報（メニュー名・数量・場所等各種）が表示される。または、売場端末が食堂サーバを参照して、ＩＤカードをカードＲ／Ｗに差し込んだ従業員の注文内容を読み出し、それをディスプレイに表示するようにしてもよい。ＩＤカードに従業員番号等のみが記録されている場合には、Ｒ／Ｗよりこれを読み出し、食堂サーバを参照してその客が注文したメニュー情報を表示してもよい。この形態は、食堂の運用形態に応じて適宜決定可能であり、この他の方法が適用可能であることはいうまでもない。売場端末のディスプレイに表示された案内に従って、客は自分が事前に注文したメニューを受け取る。
【００４０】
　なお、売場端末には食券発行の機能を持たせてもよい。図１２に点線で図示されたプリンタは、食券発行用のものである。ＩＤカードがカードＲ／Ｗに差し込まれると、記憶されている注文情報を読みだして、これに基づいてプリンタから食券が発行される。図１３は厨房端末の構成を図示する図面である。ここまで説明した用途のみを考えるのであれば、厨房端末は調理すべき内容が表示されれば十分であるため、本実施形態の場合には特にカードＲ／Ｗや食券発行のためのプリンタは必要ない（他用途のためには必要となる可能性はある）。そのため、本実施形態による厨房端末では、カードＲ／Ｗやプリンタは特に図示していない。図１４は、食堂システムを用いて注文を行う場合の、主に利用者の操作に着目した場合の手順を図示したフローチャートである。
【００４１】
　まず、食堂システムを使用する場合には、利用者は自分の職場に設置される端末装置から食堂サーバ（図面では「食堂のホームページ」）をアクセスする。ここで、図面で「ホームページ」と表現した理由は、近年のインターネットの利用拡大を考慮したものである。食堂サーバがアクセスされると、食堂サーバからメニュー選択用の画面情報が端末装置に対して送信される。端末装置は受信した画面情報を画面上に表示するため、利用者は画面から注文しようとするメニューを選択する。そして、選択された注文情報は食堂サーバに送付される。続いて、食堂サーバは端末装置から送信された情報に基づいて注文書画面を作成し、端末装置に画面情報を転送する。端末装置では、転送された注文書画面をディスプレイに表示し、利用者による注文書の入力を待つ。注文書は、入力した注文の内容を確定させるために用いられる。注文書画面の詳細については、後述する。
【００４２】
　利用者は、注文書画面から注文内容を入力する。注文書入力が確定すると、これに応答して確認画面が端末装置上に表示される。この確認画面によって、利用者は注文内容が正しく入力されたか、あるいは注文を確定してよいか、確認することができる。注文内容を確認した後、利用者は確認操作を行う。一方、注文内容を変更する場合には、再び注文画面を表示させ、あらためて注文の入力が行なわれる。
【００４３】
　図１５は、図１４の操作に続いて端末装置備えつけのプリンタを用いて引換券（食券）を発行する場合の動作を説明する。確認操作が行われると、入力された注文内容は確定したものとして食堂サーバに一旦送信される。これに応じて、食堂サーバは端末装置に対して引換券発行のために必要となる情報を送付する。端末装置は、この情報を受信した後引換券発行のために情報を編集し、プリンタを動作させて引換券を発行する。
【００４４】
　図１６は、図１５の処理に代えて利用者が保持するカード（ＩＣカード等）に注文内容を書き込む場合の処理を示す。図１４で確認操作が行われた後、注文確定が食堂サーバに転送される点までは、図１５の場合と同様である。そして，引換券発行の場合と同様に注文品に関する情報が食堂サーバから端末装置に対して送信される。なお、引換券発行時の情報と、カードに書き込まれる情報は全く同じものであってもよい。つまり、紙として印刷される引換券をＩＣカード内に代わりに書き込むようにしている、と考えることができるからである。当然、上記のような引換券／カードといった形態別に、別情報を作成するようにしてもよい。
【００４５】
　端末装置が食堂サーバからの情報を受信すると、利用者に対してカードＲ／Ｗにカードを挿入するよう促すメッセージを表示する。これに伴い利用者がカードをカードＲ／Ｗに挿入すると、端末装置は挿入されたカードに注文内容に関する情報を書き込んだ後、カードを排出する。このような処理／操作により、一連の注文処理が実行される。各手順の詳細については、必要に応じて後述する。
【００４６】
　図１７及び図１８は、注文時の端末装置と食堂側での一連の動作の詳細を説明するフローチャートである。図示右側は端末装置側、図示右側は食堂サーバ側での処理を示している。端末装置側ではまず食堂サーバをアクセスする。これに応じて、食堂サーバでは初期画面データを端末装置に転送する。端末装置は、受信した初期画面データに基づいて、画面上に初期メニューを表示する。
【００４７】
　図１９は、初期メニュー画面の例を図示した図面である。初期メニュー画面上には、利用者が選択可能なメニューの大分類の項目と、暗証番号設定の項目（詳細後述）とが表示される。利用者は、初期メニュー画面を用いて注文するメニューの大分類をまず選択する。初期メニューから大分類メニューが選択されると、その結果は食堂サーバに通知される。すると、食堂サーバではメニューファイルを参照して、選択された大分類に対応する小分類情報を読みだして、端末装置に転送する。端末装置では、転送された小分類情報画面を、画面上に表示する。ここでは、まずメニューの一覧が表示される。
【００４８】
　図２０は、図１９に図示される画面から和食メニューが選択された場合の、選択メニュー一覧の例を図示するものである。メニュー一覧には、食堂が提供可能なメニュー名と値段、熱量が一覧表示されている。メニュー画面から利用者が特定のメニューを選択すると、詳細メニュー画面が端末装置の画面上に表示される。
【００４９】
　図２１は、詳細メニュー画面の表示例を図示するものであり、焼き魚定食が選択された場合の例が図示されている。詳細メニュー画面には、選択されたメニューの内容（品目）とともに、メニューの写真が表示される。これによって、利用者は選択しようとするメニューの内容を確認できる。なお、図２１に図示された詳細メニュー画面で「ごはん」については大盛り時に２０円増しとなることが述べられている。これにより、利用者は焼き魚定食についてはごはんの大盛りが可能であることを理解できる。
【００５０】
　また、詳細メニュー画面の右すみには「注文」欄と「戻り」欄とが設定される。「注文」欄が選択されると、詳細メニューに表示されたメニューの注文が食堂サーバ側に転送される。また「戻り」欄が選択されると、画面は再び選択メニュー画面に変わる。詳細メニュー側で「注文」欄が選択されたことを受けて、食堂サーバは注文書画面を、選択されたメニューに応じて編集し、端末装置に転送する。
【００５１】
　図２２は、注文書の例を図示する図面であり、食堂サーバから情報を受信した端末装置の画面上に表示されるものである。注文書には、注文日が自動的に表示される。また、注文書には従業員番号入力欄、注文品表示欄、注文個数表示欄、オプション情報選択欄、オプション対象個数表示欄、利用日時表示欄、支払い方法表示欄、暗証番号入力欄がそれぞれ設定されている。
【００５２】
　従業員番号入力欄には、利用者が手入力、あるいはＩＤカードの読取により、従業員番号が入力される。注文品表示欄には、詳細メニュー画面で選択されたメニュー名が表示される。オプション情報選択欄は「ごはん大盛り」などの各種オプション（特別注文）に関する情報を選択するために用いられる。オプションの内容は、選択されたメニューに応じて定まっており、利用者はこの中から適宜希望する内容を選択する。
【００５３】
　個人毎に好き嫌いにより、あるいは体質や健康上の問題から、食べることができないもの／食べないものが多々ある。本実施形態によるオプション選択は、このようなケースにも対処することができる。つまり、オプション情報選択欄から自分が食べることができないものを入力することで、特定の品を注文したメニューから取り除くことができる。「焼き魚定食」の例でいえば、例えば「野菜サラダ」を省く、あるいは「野菜サラダ」の中身の特定のものを除く、といった対応が可能となるであろう。
【００５４】
　また、食堂側で対応が可能であれば、オプションとしては本来はメニューに含まれていない品の追加を指定することも可能である。利用日時表示欄には、本実施形態では翌日分の注文を基本に考えているので、自動的に翌日の昼食時間が表示される。ただし、利用者は必ずしも翌日分のみの注文を行うわけではなく、また昼食時間には来店できないケースもある。このため、本実施形態では利用日時欄から手入力で日時を入力することにより、利用日時を変更することが可能である。
【００５５】
　利用日時、特に時間が予め指定されていれば、食堂側はその時間に合わせて料理を調理すればよい。そのため、利用日時を確認画面から入力してもらうことは食堂側にとって非常に有用なことである。本実施形態では社員食堂の例を考慮しているため、支払い方法欄には自動的に「給料天引」が表示される。ただし、社員食堂に訪れる利用者全てが社員であるとは限らず、給料天引き以外の支払い方法も選択可能としておく必要がある。そのため、他の支払い方法（現金払いやカード利用等）を選択する場合、支払い方法欄から所望の支払い方法を選ぶ。
【００５６】
　食堂システムの利用は、特に金銭的なやりとりが発生するため、本実施形態では暗証番号を入力させることで、利用者が正当な者であるか否かを判定する。入力された暗証番号は、従業員番号とともに食堂サーバ側で照合され、入力が正しいか否かが判断される。これらの情報の入力が確定すると、食堂サーバに対して注文書が転送されるため、これに応答して食堂サーバから端末装置に対して注文受付確認画面情報が転送され、同画面が端末装置に表示される。図２３は、注文受付確認画面の一例を図示した図面である。
【００５７】
　注文受付確認画面には、注文時、利用日時、注文品と数量、オプションがあればさその内容、代金と支払い方法といった項目が表示される。利用者は注文受付確認画面を参照して、自分の注文内容が正しく入力されたか否かを確認する。注文受付確認画面の右隅には「確認」欄と「取消」欄とが設定されている。注文内容が正しい場合あるいは変更しない場合には「確認」欄が選択される。これによって、注文内容が確定し、その旨食堂サーバに通知される。「取消」が選択されると、前の画面（選択画面等）が表示される。
【００５８】
　「確認」が選択されると、食堂サーバでは注文が確定したものと見なし、入力された注文内容に基づいて、既に詳細を説明した注文ファイル等の各ファイルの内容を更新する。これによって、一連の注文処理が完了する。図２４は暗証番号（パスワード）の設定を考慮した場合の、端末装置での処理を図示したフローチャートである。食堂サーバがアクセスされ、初期メニューが表示されると、端末装置ではパスワードの設定が選択されたか否かが判別される（項目選択有無の監視）。パスワード設定が選択されない場合には、続いてメニュー（大分類）が選択されたか否かが、これも監視により判別される。
【００５９】
　ここでパスワード設定が選択されると端末装置は図２５の処理を実行する。図２５は、パスワード設定の一連の処理を図示したフローチャートである。また、図２６はパスワード設定の初期画面を図示するものである。ここで、パスワード設定には新規の設定とパスワード変更とがあるため、図２５に図示される初期画面を用いてどちらを行うのかを利用者に選択させる。
【００６０】
　まず、新規設定の場合について説明する。これは、客が新たに食堂システムを利用する場合などに実行される。パスワード設定の初期メニューから「新規設定」が選択されると、画面上に暗証番号新規設定画面が表示される（図２７）。暗証番号新規設定画面には従業員番号入力欄と暗証番号入力欄とが設定されている。利用者は、暗証番号新規設定画面を用いて、自分の従業員番号とともに、設定しようとする暗証番号を入力する。なお、暗証番号は第三者からは見えないようにするために、図２６の例では暗証番号が入力された桁位置にはアスタリスクが表示されている。
【００６１】
　暗証番号新規設定画面から従業員番号と暗証番号とが入力されると、続いて暗証番号設定確認画面（図２８）が表示される。ここでは、先に入力した暗証番号を再入力させることにより、暗証番号が正しく、利用者が考えている通りに入力されたか否かが確認される。ここで、暗証番号新規設定画面から入力された暗証番号と、暗証番号設定確認画面から入力された暗証番号とが一致する場合、暗証番号の設定処理を終了し、図２６の初期メニュー画面が端末装置に表示される。
【００６２】
　一方、暗証番号が正しく再入力されなかった場合には、画面上に「指定した暗証番号を再度入力下さい。」という暗証番号入力誤りを知らせるメッセージを画面上に表示し、再度暗証番号の再入力を行うよう利用者に促す。次に、暗証番号の変更時の処理について説明する。暗証番号設定画面で「番号変更」が選択されると、端末装置には暗証番号変更画面が表示される（図２９）。この画面が表示されると、利用者は自分の従業員番号とともに、その時点での暗証番号を入力する。この処理により、暗証番号を変更しようとする者の正当性が確認される。
【００６３】
　現暗証番号が正しい場合には、続いて新たな暗証番号を新暗証番号入力欄から入力する（図３０）。続いて、新規設定の場合と同様に、図２８に図示される暗証番号設定確認画面が端末装置に表示される。暗証番号が設定されると、食堂サーバ側にこの情報が転送される。そして、個人ファイル内に従業員番号と対応付けて格納される。
【００６４】
　暗証番号の設定後に再び初期メニューが表示されるため、引き続き注文を行おうとする利用者は通常の注文時と同じようにメニューの選択を行うことができる。ここで、従業員番号の代わりに氏名、住所等を入力できるようにすれば、一般の食堂などの利用登録に図２５の処理を応用することができる。この際に、支払い方法の一つの選択肢としてクレジットカード支払いがある。社員食堂とは異なり、客の特定がしにくい場合には、クレジットカード番号などの入力を求め、支払い能力に問題がないかどうかの確認を行うことも有用であろう。
【００６５】
　図３１は、注文が受け付けられた後の食堂サーバ側での処理手順を示したフローチャートである。利用者からの注文が転送されると、食堂サーバではまずオーダ受付ファイルに従業員番号、来店日時、注文されたメニュー、数量、オプションがあればその情報が書き込まれる。続いて、食堂サーバでは注文されたメニューに対応する材料ファイルを参照する。
【００６６】
　材料ファイルが参照されると、食堂サーバでは次に材料ファイルより注文品に対応する材料と必要個数を読みだして、これに基づいて材料ファイルを更新する。これは、材料ファイルに格納された材料毎の個数を、新たに注文を受けたメニューの個数分加算していく。ここで、先に述べた通り材料ファイルは材料の発注に使用されるため、単位個数未満の場合には、合算した個数が単位個数に達するまで、個数欄はは単位数に切り上げられた個数が記録されるようにしている。
【００６７】
　続いて、転送された注文品に基づいて、献立ファイルの内容を更新する。献立ファイルにはある日に調理する必要があるメニューの数量（材料含む）が、メニュー毎に記録されている。新たな注文が発生した場合には、献立ファイルの個数を更新していく。同様に、メニュー毎の材料数量を更新する。本実施形態による食堂システムでは、主に材料発注の都合上、受付締切り時間が設定されている。図３２は、端末装置からの注文があった場合の食堂サーバでの処理を図示した図面である。ここでは、メニュー選択の操作が行われると、その時刻が締切り時間前か否かが判別される。締切り前であれば注文を受け付けるが、締切り時間のちであれば注文は受け付けられない。
【００６８】
　また、ある日の調理に間に合わせるように材料を発注するためには、例えば前日の午後までに材料を各発注先に発注する必要があるからである。そこで、締切り時間に達すると、食堂サーバ側では材料ファイルの内容を読み出して、そこに記録されている各材料を、各発注先に対して発注する。一旦注文した後、注文内容の変更や取消を利用者が希望する場合がある。この場合でも、本実施形態による食堂システムでは、締切り時間前を条件に対応できるようにする。図３３は、そのための処理手順を説明するためのフローチャートである。
【００６９】
　注文取消時には、利用者は食堂サーバをアクセスし、取消画面を選択する（特に図示せず）。すると、食堂サーバでは取消操作が締切り時間後であるか否かを判別する。締切り時間後である場合、材料が既に発注済である可能性が高いために、食堂サーバでは注文の取消（変更）を受け付けることができない。そのために、端末装置に対して取消操作が締切り時間後であることを利用者に通知するための画面を表示するように指示する。同時に、キャンセルすることでキャンセル料が発生することなども利用者に通知される。
【００７０】
　続いて、食堂サーバでは端末装置にキャンセル可否確認のための画面を表示することを指示する。キャンセルが不可の場合には、注文の取消は行わずに処理を終了する。一方、キャンセルを行うことを示す操作がなされた場合には、取消し処理が行われる。なお、締切り後のキャンセルであったにも関わらず、キャンセル料が支払われないようなケースも考えられる。これは特に、現金などその場での支払いが行われた際に問題となる。従って、締切り後のキャンセル発生時には、キャンセル料が支払われたか否かを確認する必要がある。そして、締切り後のキャンセルが多く、且つキャンセル料が支払われない客については、食堂システムの利用を制限する必要もでてくるであろう。
【００７１】
　また、取消操作が締切り時間前であった場合にも取消の処理が実行される。取消処理を行う場合には、食堂サーバ側で受付ファイルを参照し、当該利用者の注文品を読みだす。そして、取消画面を編集し、端末装置に転送する。取消画面には、当該利用者が注文した品と利用予定日時が少なくとも表示される。なお、同一利用者が複数の日時分注文をしている場合には、当該利用者の全ての来店予定日時を一覧表示し、利用者に選択させるようにする。一画面内に入りきらない場合には、分割して表示するようにしてもよい。
【００７２】
　取消画面が表示されると、利用者は取消をしようとする内容を選択し、取消操作を行う。取消装置の後に、注文時の確認画面と同様に取消内容を確認する画面を表示する。確認画面で利用者の取消が確認されると、食堂サーバでは各ファイルの内容を取消内容に応じて修正・更新する。なお，取消処理はある日時のために注文した内容を一括して取り消すのではなく、一部のみ取消とすることも当然可能である。例えば、複数の品を同日に注文した場合に、一品のみを取り消す必要がでるケースなどである。
【００７３】
　また，注文の変更も同様の手順により処理される。この場合には取消の代わりに変更内容が各ファイルに書き込まれることになる。図３４は、厨房端末を用いた処理の手順を図示したフローチャートである。厨房端末では、当日調理されるべきメニューとその個数を表示することができるが、図３４はそのための手順を示している。
【００７４】
　図３５は、厨房端末に表示される画面の例を図示するものであり、図３５の例では当日調理すべきメニューとその数量が合わせて表示される。詳細表示を行うためには、厨房端末で図３５の画面に表示されていく品目を選択する。品目の選択は、キーボードや各種のポインティングデバイスを用いることができ、また画面上にタッチパネルを形成すれば画面に触れるだけで品目を選択することができる。
【００７５】
　ここでは、品目毎の材料等の詳細を表示する例について説明する。図３５の画面で「カツ丼」が選択されると、カツ丼を調理するために必要な材料と、全体を調理するための必要個数、一品当りの材料の必要個数が合わせて表示される（図３６）。また画面の右隅にはオプションの参照欄が設けられている。ここでは、オプションの有無とその内容、材料の数量などの変更に関する情報が表示される。なお、図３６の例では全体を調理するために必要な材料・数量と、１品当りの材料・数量とが表示された例が図示されるが、後に詳述する通り、未調理残数を入力・表示することに対応して、未調理残数を調理するために必要な材料の数量を表示できるようにしてもよい。
【００７６】
　あるメニューが調理されると、厨房端末を用いて調理済みであることが入力される。ここで、前述の通り全ての注文品を同時に調理することは困難な場合もあるため、調理済み数量をメニュー毎に入力できるようにしている。この内容は献立ファイルに反映され、調理済み数分献立ファイルの注文数が更新される（減算）。全てが調理済みであるかどうか、あるいは未調理の残数がどのくらいなのかを厨房端末を用いて確認することができる。
【００７７】
　図３５の画面でも調理済みを示す情報欄が設定されており、当該メニューが所定数調理済みである場合には、その旨を知らせる表示（図示丸印）が行われる。これによって、図３５の場合には焼き魚定食はこれ以上調理する必要がないことが一目で判る。なお、全数調理済みでないものについては、図３５では特に表示はおこなっていない。未調理残数を表示するためには、厨房端末を用いてメニューを選択する。タッチパネルが使用されている場合には、特定のメニューの調理済みの欄を触れることで、当該メニューの未調理残数を表示させる。
【００７８】
　図３７はカツ丼についての未調理残数を示す画面の表示例である。ここでは、未調理残数の全体の数とともに、通常品も含めたオプション別に未調理残数が表示されている。このような表示を行うことで、厨房で過不足なくメニュー毎の調理を行うことができる。なお、残数を図３５の調理済み画面に合わせて表示するようにしてもよい。この場合、画面切り換えの手間を減らすことができる。ただし、オプション品についても図３５の画面に一緒に表示すると、画面が細々として見にくくなる可能性もあるために、オプション品を含めた未調理残数は別画面に表示した方が望ましいと思われる。この場合には、図３５の「調理済」欄に未調理残数を表示するなどの対処が可能である。
【００７９】
　図３８は、厨房端末で表示される納品チェック画面の例である。ここでは、各材料毎に確かに納入されたか否かを確認するために使用される。納品が確認された材料については画面上丸印が付されているが、例えば不足等の事由がある場合にはその旨表示される（図示三角）。図３９は厨房端末に使用されるキーボードの部分を図示したものであり、テンキー部とともに各項目を指示するためのキーが配置されている。項目キーとして図示の例では「特注（オプション）確認」、「検品確認」、「材料参照」、「調理済入（力）」、「備考参照」などの項目が設定されているが、これらは適宜変更可能である。例えば「材料参照」のキーを押下すると、図３８の画面が表示されるように制御される。
【００８０】
　図４０は利用者が来店した場合の処理・操作手順を図示したフローチャートである。ここでは、ＩＤカードを利用する場合について特に例示する。利用者が来店すると、売場端末にＩＤカードを挿入する。この処理は、図示される通り端末から従業員番号を手入力するものでもよい。これによって、売場端末では食堂サーバを参照し、受付ファイルから当該利用者が注文したメニューに関する情報を読みだして、売場端末に表示する（図４１）。合わせて、どの場所にいけば注文した品物を受け取ることができるのかを示す情報を表示する。これは、メニュー毎に売場を対応付けて受付ファイルあるいはメニューファイルに予め格納しておけば対応可能である。
【００８１】
　また、オプション品を注文した客については、オプション品が注文されていることを確認させるための情報も表示する。ここで、オプション品などの条件付きの注文を行った利用者が来店したことが、ＩＤカードの挿入・ＩＤ読取に伴って、厨房端末等に表示される。これによって、大盛りなどのオプション品を当該利用者に確実に手渡すことができる。
【００８２】
　利用者が注文した品を受け取ると、献立ファイルから引き取り済商品数を減算していく。これによって、メニューの残量を随時確認することが可能となる。ＩＣカードに注文内容が記録されているケースであれば、注文品表示の際に食堂サーバを参照しなくてもよい。また、支払いについては、予め注文時に支払い方法が指定されている。そこで、客が店舗端末を利用した時点で、支払い方法を確認させるための表示を行う。給料天引などその場での現金移動等がない場合であれば「支払い済」等の表示を行う。一方、現金払いやカード類による支払いが選択されている場合には、別途設けられた精算カウンタに客を誘導するための表示を行う。
【００８３】
　ここで、客による不正を防止するためには、現金払いを指定した者が支払いを行わなかった場合に、アラームを上げる、等の対処法をとればよい。図４２は、材料検品後の処理フローチャートを図示する図面である。材料が検品されると、入力に応じて献立ファイルの検品フラグがオンにされる。また、厨房端末からの指示により献立内容がファイルから読みだされて、厨房端末に表示される。
【００８４】
　メニューが調理される毎に、調理済メニューやその数量が厨房端末より入力されると、献立ファイルの数量等が更新される。図４３は、注文の結果、指定した利用日時では利用予約で満杯である場合に、端末装置で表示される画面例を図示した図面であり、特に予約制の食堂で利用する場合に有用である。画面の下には、確認のためのボタンが設定されている。ここで、端末装置と食堂サーバとはネットワークで接続されているため、利用者の要望等を食堂側に伝えやすいという特性がある。そこで、端末装置にアンケート画面を表示させ、利用者が今後提供してほしいと望むメニューをアンケート画面から入力してもらうようにしてもよい。
【００８５】
　食堂サーバでは、利用者からのアンケートの回答を集計する。これによって、利用者の嗜好の傾向を把握することができ、利用者の要望に適したメニューの提供が可能となる。従前では、食堂で過去の実績によりメニューを決定するか、世の中の流れに基づいてメニューを決定していた。前者については、提供したことがないようなメニューを追加することが非常に困難であり、後者については世の中の流行とその店の実際の客層とのギャップが大きくなると、利用者が望む料理は提供できなくなる。
【００８６】
　本実施形態によればこのような問題は解消可能であり、利用者へのサービス提供が向上する。なお、上記した実施形態では、材料発注数／調理数を客から注文された数と同数とする例が特に説明されている。しかし、完全予約制の店ならばともかくとして、当日急に来店する客が出てくる可能性はどうしても残る。このような場合に予約分のみ調理しておくと、予約なしで当日来店した客が食堂を利用できないか、このような客が先に料理を取ってしまい、予約客が自分の注文品を受け取ることができない可能性がでてくる。
【００８７】
　このようなケースに対処するためには、発注する材料数や、当日の調理数を幾分割増することが考えられる。具体的には、図６の材料発注ファイルや図７の献立ファイルに設定される調理数／材料数量を、幾分か割増して記録する。つまり、予約分をまかなうために必要となる数量よりも若干多めに材料を発注し、多めに料理を調理するのである。
【００８８】
　ここで、割増数は店側の経験から判断するのが一番確実であるが、判断材料を持たない場合には、各メニュー毎に、一律同じ量だけ割増してしまうのが簡単である。このような余分の発注／調理はしかし、無駄が生じてしまう。だが、ベースとなる数字が全くない状況から発注数／調理数を予測する場合と比較すると、オーダリングシステムにより予め予約されているケースでは、最小限の必要数が予め判っているため、発注／調理の無駄は確実に低減されるであろう。
【００８９】
　また、このようなケースでは、予約済の料理は予約客に確実に確保されている必要がある。そのためには、未予約客に対して提供してもよい料理数を、常に把握する必要がある。未予約客に提供可能な料理数は、全調理数量から予約済数量を差し引いた数に相当する。そして、この分は予約分とは別個にしておく。客が来店する毎に、ＩＤカードの操作などによってこの客が予約済の客か否かを判別する。そして、予約客か否かに応じて、客を誘導する先を変える。
【００９０】
　予約客については、予約客分の料理が確保されたところに誘導する。また、未予約客については、未予約客用の料理が容易されたところに誘導する。いずれの場合についても、料理が引き取られる毎に残数量を算出する。特に未予約客分については、常に残数量を表示しておき、残量が「０」となった料理については「残なし」を示すメッセージを表示することが望ましい。あるいは、未予約客が来店時に一目で判断することができるように、提供可能な料理の一覧とその数量を表示できるようにしてもよいであろう。
【００９１】
　また、当日来店した未予約者については、オーダリングシステムによる本人確認が行われていないため、現金などの支払い方法を選択させ、給料天引等は避けることが、後日のトラブルを回避するためには好ましいであろう。
【図面の簡単な説明】
【００９２】
【図１】本発明の一実施形態による食堂システムを示す図面。
【図２】食堂側のシステム構成を示す図面。
【図３】メニューファイルの構成を示す図面。
【図４】材料ファイルの構成を示す図面。
【図５】オーダ受付ファイルの構成を示す図面。
【図６】材料発注ファイルの構成を示す図面。
【図７】献立ファイルの構成を示す図面。
【図８】個人設定ファイルの構成を示す図面。
【図９】端末装置の構成を示す図面。
【図１０】端末装置の内部構成を示すブロック図。
【図１１】受付装置／管理端末の内部構成を示すブロック図。
【図１２】売場端末の内部構成を示すブロック図。
【図１３】厨房端末の内部構成を示すブロック図。
【図１４】注文次の客による操作に着目した処理手順を示したフローチャート。
【図１５】プリンタを用いて引換券を発行する際の処理を示す図。
【図１６】客のカードに注文内容を書き込む際の処理を示す図。
【図１７】注文時の端末装置／食堂サーバ側での処理手順を示すフローチャートその１。
【図１８】注文時の端末装置／食堂サーバ側での処理手順を示すフローチャートその２。
【図１９】初期メニュー画面の表示例を示す図。
【図２０】和食メニュー一覧の表示例を示す図。
【図２１】選択されたメニューの詳細画面の表示例を示す図。
【図２２】注文書の表示例と記入例を示す図。
【図２３】確認画面の表示例を示す図。
【図２４】パスワード設定を行う場合の食堂システムでの処理手順を示したフローチャートその１。
【図２５】パスワード設定を行う場合の食堂システムでの処理手順を示したフローチャートその２。
【図２６】パスワード設定初期画面の表示例を示す図。
【図２７】新規設定画面の表示例。
【図２８】新規設定確認画面の表示例。
【図２９】パスワード変更画面の表示例１。
【図３０】パスワード変更画面の表示例２。
【図３１】注文受付後に食堂サーバ側で実行される処理手順を示すフローチャート。
【図３２】締切時と締切前の食堂サーバ側の処理手順を示すフローチャート。
【図３３】注文取消時の食堂システムでの処理手順を示すフローチャート。
【図３４】厨房端末に情報を表示する際の処理手順を示すフローチャート。
【図３５】厨房端末に表示される画面例を示す図。
【図３６】あるメニューに対する情報を示す厨房端末の表示画面の例を示す図。
【図３７】未調理残数の表示画面例を示す図。
【図３８】納品チェック画面の表示例を示す図。
【図３９】厨房端末のキーボード例を示す図。
【図４０】来店時の処理手順を示すフローチャート。
【図４１】客案内表示例を示す図。
【図４２】材料検品時の処理手順を示すフローチャート。
【図４３】満員時のメッセージ表示例を示す図。
【図１】
2004078986.tif 000003
【図２】
2004078986.tif 000004
【図３】
2004078986.tif 000005
【図４】
2004078986.tif 000006
【図５】
2004078986.tif 000007
【図６】
2004078986.tif 000008
【図７】
2004078986.tif 000009
【図８】
2004078986.tif 000010
【図９】
2004078986.tif 000011
【図１０】
2004078986.tif 000012
【図１１】
2004078986.tif 000013
【図１２】
2004078986.tif 000014
【図１３】
2004078986.tif 000015
【図１４】
2004078986.tif 000016
【図１５】
2004078986.tif 000017
【図１６】
2004078986.tif 000018
【図１７】
2004078986.tif 000019
【図１８】
2004078986.tif 000020
【図１９】
2004078986.tif 000021
【図２０】
2004078986.tif 000022
【図２１】
2004078986.tif 000023
【図２２】
2004078986.tif 000024
【図２３】
2004078986.tif 000025
【図２４】
2004078986.tif 000026
【図２５】
2004078986.tif 000027
【図２６】
2004078986.tif 000028
【図２７】
2004078986.tif 000029
【図２８】
2004078986.tif 000030
【図２９】
2004078986.tif 000031
【図３０】
2004078986.tif 000032
【図３１】
2004078986.tif 000033
【図３２】
2004078986.tif 000034
【図３３】
2004078986.tif 000035
【図３４】
2004078986.tif 000036
【図３５】
2004078986.tif 000037
【図３６】
2004078986.tif 000038
【図３７】
2004078986.tif 000039
【図３８】
2004078986.tif 000040
【図３９】
2004078986.tif 000041
【図４０】
2004078986.tif 000042
【図４１】
2004078986.tif 000043
【図４２】
2004078986.tif 000044
【図４３】
2004078986.tif 000045