JPH11338912A - オーダリングシステム、情報処理装置及びオーダリング方法 - Google Patents

Abstract

(57)【要約】 【目的】本発明は、食堂等のオーダリングシステムに関
する発明である。従来の食堂では、来客数の把握や材料
の発注数、調理すべき料理の数量の把握は担当者がこれ
までの傾向や勘に頼って決定していたが、実際の来店数
と大きく異なる可能性が高く、料理や材料が無駄になる
可能性や、逆に料理数が足りなくなる可能性が高い。そ
のため、本発明はこのような問題点を解決するためにな
された。 【構成】メニューファイル、材料ファイル等を備えた食
堂サーバと、客が利用する端末装置ＰＣとをネットワー
クにより接続、端末装置ＰＣから食堂サーバをアクセス
して注文を行う。客はメニューファイルから読み出され
た食堂のメニューに関する情報から、注文しようとする
メニューを選択する。また、客からの注文に応じて、当
日調理すべきメニューとその数量、発注が必要となる材
料とその数量に関する情報を逐次更新する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、食堂等を始めとす
る店舗での注文受付に用いられるオーダリングシステム
に関するものであり、特に社員食堂などのカフェテリア
の形態を取る食堂に適したオーダリングシステムに関す
る。

【０００２】

【従来の技術】各種の食堂の中でも、社員食堂や学生食
堂といった食堂はカフェテリア形式を採用する例が多
い。これらの食堂に限らず、カフェテリア方式の食堂で
は予め調理済の料理を棚に並べておき、来店者が自分の
好みの料理を棚から取り、その後精算が行われるケース
が大半を占める。

【０００３】このような食堂の場合には従って、事前に
ある程度の数量の料理を、事前に調理しておく必要があ
る。また、料理の選択の幅を広げるためには、複数種類
の料理を調理しなくてはならない。また、この他の形態
の食堂では、客が来店して料理を注文した後に、料理が
調理される。しかし、この場合であっても料理の下準備
は行っておく必要がある。そして、一品毎に調理できな
いような料理については、多人数分予め調理しておく必
要もある。

【０００４】更に、どのような形態の食堂でも、事前に
材料を注文しておく必要がある。材料の発注量は、必要
とする最小限の数量に止めることが色々な意味から望ま
しい。

【０００５】

【発明が解決しようとする課題】ここで、食堂の一般的
な問題として、ある日の、あるいはある時間帯の来店者
数を事前に予測することが非常に難しい点を上げること
ができる。長年営業していれば、それまでの経験則から
おおよその来店者数を予測することはできるが、日付や
曜日、その日の天候、各種行事催行等の条件により、来
店者数は大きく増減する。また、来店者個人の都合とい
う、予測がまず不可能な条件も加わる。従って、実際の
来店者数が予測来店者数とは異なるケースも多い。

【０００６】来店予想は、当日の調理数や材料の発注数
を決定するために非常に重要な要素となる。特にカフェ
テリア方式の食堂では事前調理が必要であるため、来店
者に合わせて調理する数を適宜調整することが困難であ
る。これらの調理・発注数は予測来店数により決定され
るが、予測来定数と実際の来店数とが異なった場合、以
下のような運営上の問題がでてくる。なお、調理・発注
数量は、予測来店者数に基づいて決定されているものと
仮定する。 １）来店者数が予測数を上回る場合 この場合には、料理の数や発注した材料が不足する可能
性が非常に高い。料理が不足した場合には、後からの来
店者に対して料理を提供することができなくなる。常に
提供できる料理が不足気味である状況が続くと、その店
は十分な料理を提供できないということで、店の信用に
も影響を与える可能性がある。 ２）来店者数が予測数を下回る場合 この場合には、仕入れた材料や調理済みの料理が無駄に
なる可能性が非常に高くなる。特に生鮮食品の中には保
存が効かないものもあり、これらについては余った分は
廃棄せざるを得ない。

【０００７】また、特にカフェテリア形式の食堂の場合
には、客が来店した時点ですぐに料理を手にすることが
できるようにする必要がある。そのため、事前調理が絶
対的に必要であるが、未調理の材料については翌日まで
取っておくことができるとしても、調理済みの料理につ
いては保存ができず、その日のうちに消費する必要があ
る。そのため、余った調理済みの料理についても、場合
によっては廃棄せざるを得ない。

【０００８】ここで、廃棄される料理については、全て
店の損となってしまい、廃棄量が多くなればなるほど、
店の負担は増える。また、調理済みの料理の廃棄量が常
に多い状況が続くと「食べ物を粗末にする店」といった
風評が立つ恐れもあり、店の信用問題にもかかわってく
る。材料の余剰分は、仮に保存がきいたとしても、保存
のための施設への投資などが必要となってくる。また、
発注量は常に必要となる分に抑えないと、保管等のコス
トを考えればこれも店の負担・損失となってしまう。そ
のため、材料の発注数・事前の調理数は可能な限り抑え
ることが望ましい。

【０００９】その一方で、来店した客に料理を提供でき
ないという事態も、サービス業である以上どうしても避
けなければならない。従って、この場合には、発注数や
事前の調理数を予測数値よりも割増して考えなければな
らなくなる。このように、食堂運営上材料の発注数や調
理数は非常に大きな問題となる。本発明はこのような問
題に鑑み、効率的な材料の発注や調理を行うことができ
るオーダリングシステムを実現することを目的とする。

【００１０】また、本発明は、発注すべき材料数や調理
すべき数量を、自動的に算出・更新が可能となるオーダ
リングシステムを実現することを目的とする。なお、商
品の発注数量等の自動的な算出・更新や、ある日に最低
限必要となる商品数量を事前に把握するという効果は、
食堂以外の店舗や各種通信販売においても適用可能であ
ることはいうまでもないが、以下特に食堂システムに本
発明を適用した例について説明する。

【００１１】

【課題を解決するための手段】上記した課題を解決する
ために、本発明は互いに伝送路で接続された、食堂サー
バと、食堂の利用者が操作する端末装置とを備えるオー
ダリングシステムであり、前記食堂サーバには、食堂が
提供するメニューに関する情報を格納するメニューファ
イルと、前記メニューファイルに格納されたメニュー毎
に必要となる材料名と数量が格納された材料ファイル
と、利用者が注文したメニューに関する情報を格納する
受付ファイルと、前記利用者による注文に基づいて材料
毎に必要となる数量を集計する材料集計ファイルと、あ
る期間に調理する必要があるメニューとその数量および
メニュー調理に必要な材料に関する情報を格納する献立
ファイルと、を備えるオーダリングシステムであること
を特徴とする。

【００１２】また、前記食堂サーバにおいて、前記材料
集計ファイルには各材料毎の発注先に関する情報が格納
されることを特徴とする。また、前記食堂サーバは、発
注先に備えられた端末装置と伝送路により接続されてお
り、前記材料集計ファイルには発注先の端末識別情報が
格納されており、前記食堂サーバからの材料発注時に
は、前記端末識別情報に基づいて伝送路を用いて発注情
報を発注先端末装置に伝送することを特徴とする。

【００１３】更に、前記食堂サーバにおいて、利用者か
らの注文受付の締切り時間が設定され、前記締切り時間
となった後に前記材料集計ファイルの情報に基づいて材
料の発注を行うことを特徴とする。また、前記受付ファ
イルには利用者が注文したメニュー名とその数量、利用
時間、支払い方法並びに特別注文に関する情報が格納さ
れることを特徴とする。

【００１４】また、前記献立ファイルには、調理済みメ
ニューの調理済み数量に関する情報が格納されることを
特徴とする。また、前記調理済みメニュー数量に基づい
て、未調理数量を算出し、前記未調理数量を画面表示す
ることを特徴とする。また、前記献立ファイルには、各
メニュー毎に未調理数量に関する情報が格納されること
を特徴とする。

【００１５】また、前記献立ファイルには、各材料毎に
納入の有無を識別するフラグが設定されることを特徴と
する。また、前記材料集計ファイルには、各材料毎に納
入の有無を識別するフラグが設定されることを特徴とす
る。また、前記メニューファイルには、各メニュー毎に
写真情報が格納されることを特徴とする。

【００１６】一方、本発明は、食堂に設置される情報処
理装置において、前記情報処理装置は、食堂が提供する
メニューに関する情報を格納するメニューファイルと、
前記メニューファイルに格納されたメニュー毎に必要な
材料とその数量が格納された材料ファイルと、利用者の
注文に関する情報を格納する受付ファイルと、注文内容
に基づいて各材料毎に必要な数量を集計する材料集計フ
ァイルと、ある期間に調理されるべきメニューとその数
量およびメニュー調理に必要な材料に関する情報を格納
する献立ファイルとを備える情報処理装置であることを
特徴とする。

【００１７】また、前記情報処理装置は、利用者が注文
内容を入力する注文端末と接続されており、前記注文端
末の操作に応じて利用者の注文を受け付けることを特徴
とする。また、本発明は、顧客からの注文を受け付ける
オーダリングシステムにおいて、顧客が注文内容を入力
する端末装置と、前記端末装置から入力された注文を受
け付けるサーバとを備え、前記サーバには、顧客が注文
可能な商品に関する情報を格納する商品ファイルと、顧
客が選択した商品を含む注文内容を格納する注文ファイ
ルと、を備えたことを特徴とする。

【００１８】また、前記オーダリンクシステムにおい
て、前記サーバは更に、商品と商品毎の発注先に関する
情報が格納される発注ファイルを備えることを特徴とす
る。また、前記オーダリングシステムにおいて、前記サ
ーバは更に発注先に発注された商品が納入されたか否か
を判別する検品フラグが設定されるファイルを備えるこ
とを特徴とする。

【００１９】また、前記オーダリングシステムにおい
て、前記注文ファイルは顧客によりなされた特別注文内
容を格納することを特徴とする。また、本発明は、顧客
からの注文を受け付けるオーダリングシステムにおける
オーダリング方法において、注文可能な商品に関する情
報を注文用端末装置に表示し、注文用端末装置からの商
品選択に応じて、受付端末に設けられた、注文内容に関
する情報を格納する注文ファイルの内容を更新すること
を特徴とする。

【００２０】また、顧客からの注文を受け付けるオーダ
リングシステムにおけるオーダリング方法において、顧
客が注文内容を入力する注文用端末装置に、注文可能な
商品一覧画面を表示し、顧客による商品選択に応じて、
注文内容を入力するための注文書画面を前記注文用端末
装置に表示し、前記注文用端末装置により注文書画面か
ら注文内容が入力されたことを受けて、注文内容を顧客
に確認させるための確認画面を表示し、確認画面に表示
された内容を顧客が確認する旨の操作を受けて、注文を
受け付けるオーダリング方法であることを特徴とする。

【００２１】また、前記オーダリング方法において、前
記商品一覧表示の際に、始めに顧客が注文可能な商品の
大分類一覧画面を表示し、前記大分類一覧画面より顧客
が商品分類を選択したことを受けて、該当する大分類に
属する商品一覧を示す小分類一覧画面を表示することを
特徴とする。また、顧客からの商品の注文を、注文用端
末装置から受け付けるオーダリングシステムにおいて、
顧客からの注文入力時点で、注文受付締切り時間を過ぎ
ているか否かを判定し、締切り時間を過ぎていない場合
には、前記顧客からの注文を受け付けるとともに、前記
締切り時間を過ぎている場合には、前記注文用端末装置
に締切り時間を経過していることを示すメッセージを表
示し、前記注文を受け付けないように構成されるオーダ
リングシステムであることを特徴とする。

【００２２】

【実施の形態】図１は、本発明の一実施形態における食
堂システムのシステム構成を図示する図面である。ここ
では特に、社員食堂への適用例について説明するが、こ
の他の形態の食堂であっても当然本発明は適用可能であ
り、この他にも一般的な通信販売などの各種オーダリン
グシステムに対応可能であることはいうまでもない。

【００２３】本実施形態による食堂システムは、大きく
わけて食堂サーバ、食堂用の端末、客（つまり社員）側
に設けられた一乃至複数の端末装置、社員サーバが備え
られる。食堂サーバ、端末装置および社員サーバはネッ
トワークにより接続されている。社員サーバは、従業員
データベースや給与データベースを備えている。社員食
堂を利用する場合に給料天引で支払う際には、社員サー
バに登録されている給与口座から利用した分の料金を天
引する。

【００２４】ここで、社員食堂等の場合にはＬＡＮ等を
利用すればよいが、不特定多数の客の利用が予想される
一般の食堂の場合には、近年特に普及しているインター
ネット等を使用するようにすればよい。図２は、食堂側
の構成を更に詳細に図示した図面である。図２の例で
は、食堂側には食堂サーバ、厨房用端末、発注管理用端
末、受付用端末、売場端末が備えられる。なお、食堂側
の端末装置はこれらに限定されるものではなく、他の端
末装置が備えられていても、また図２に図示された各端
末装置の機能を一台の装置に統合するようにしてもよ
い。食堂側の構成は、食堂の規模等によって適宜変更が
可能である。

【００２５】食堂サーバには、各種のファイルが設けら
れている。以下、これらのファイルについて説明する。
図３は、メニューファイルの構成を説明する図面であ
る。図３（Ａ）は大分類ファイル、図３（Ｂ）は小分類
ファイルである。メニューファイルには、食堂が提供で
きるメニューに関する情報が格納されており、客が注文
する際にはこのメニューファイルが参照される。

【００２６】大分類ファイルには、食堂が提供できるメ
ニュー内容の大分類が格納されている。図３（Ａ）の例
では「洋食」「和食」「中華」「丼物」等の項目が設定
されている。図３（Ｂ）に図示される小分類ファイル
は、大分類ファイルとリンクされるように構成されてい
る。そして小分類ファイルには、大分類毎にメニュー名
と値段、熱量に関する情報が対になって格納されてい
る。図３（Ｂ）の場合には、大分類ファイルで「丼物」
が選択された場合のリンク先となる、「丼物」小分類フ
ァイルが図示されている。

【００２７】またメニューファイルには、図３には詳細
は図示されていないが、メニュー毎の写真が小分類ファ
イル内のメニュー毎にリンクして格納されている。メニ
ュー写真は、客側の端末で表示され、メニューの内容を
視覚的に認識してもらうために使用される。図４は材料
ファイルの構成を説明する図面である。材料ファイル
は、メニュー毎に、１品調理するのに必要となる材料名
とその数量に関する情報が対に格納されている。

【００２８】例えば図４の例では「カツ丼」が例示され
ている。ここでは「ごはん」つまり米が１合、「豚肉」
が１００グラム、「たまねぎ」が１／４個、「卵」が１
個などの情報が格納されている。これらは、「カツ丼」
を一つ調理するのに必要な材料と、その数量を示す。ま
た、大盛りの場合には材料が１割増しとなる旨、情報が
設定される（図示されず）。

【００２９】このような「大盛り」の割増量などのオプ
ション情報は、材料ファイルにメニュー毎に設定しても
よいし（「ごはん」＝「１．１合」と記録するか、「１
割増」と記録する）、例えば「大盛り」が選択された際
に材料ファイル内の数量を一律かつ自動的に割増するよ
うにしてもよい。前者の場合には、材料ファイル内に割
増量を格納しておく必要かあるのに対し、後者の場合に
は通常時の数量のみをとりあえずは設定しておけばよい
が、割増量を算出する必要がでてくる。

【００３０】また、前者の場合には、メニュー毎に、あ
るいは材料毎に大盛りのときの割増量を変えて設定する
ことも可能である。例えば「ごはん」のみ１割増とし、
その他は割増しないといった設定も行うことができる。
また大盛りに対応できないメニューがある場合には「大
盛り不可」という情報をメニューファイルに加えること
もできるため、よりきめ細かな対応が可能となる。これ
に対し、後者の場合には材料ファイルの構造が単純にな
るため、特に食堂サーバ側に余裕がない場合などには適
していると言える。

【００３１】図５はオーダ受付ファイルの構成を説明す
る図面である。オーダ受付ファイルは、客を識別する情
報（社員食堂を例示しているため図５では従業員番
号）、利用日時、注文品とその数量、オプション（大盛
り等の特別注文）とその数量並びに支払い方法に関する
情報が格納されている。ここで、社員食堂を対象とする
のであれば、基本的には料金の支払いは給料天引とする
ことができるであろう。ただし、社員食堂といっても外
部の者が訪れる可能性もあり、このような者に対しては
給料天引はできないため、現金払いやプリペイドカー
ド、ＩＣカード（電子マネー）等の支払いにも対応でき
るようにする必要がある。また、社員の中には、食堂の
利用は給料天引ではない方を選ぶ者もいる。図５に図示
されるオーダ受付ファイルでは、これらに対処できるよ
うに、支払い方法に関する情報が注文内容と一緒に格納
される。

【００３２】支払い方法は注文時に指定されるが、この
指定方法の詳細については詳細後述する。なお、支払い
方法としてはこの他にクレジットカードによる支払いも
可能である。また、会員制の店の場合を想定すると、客
の氏名は予め店側に登録されている。これは社員食堂の
例の社員と食堂の関係にも似ている。このように来店者
が特定できる場合（言い換えれば「飛び込み」の客の来
店を考慮する必要がない場合）には、客毎に支払い方法
を一律に設定することも可能である。客が特定できれば
支払い方法も特定できるのであれば、オーダ受付ファイ
ルからは支払い方法に関する情報設定欄を削除すること
もできる。

【００３３】図６は材料発注ファイルであり、食堂が材
料を発注する際に利用されるものである。この材料発注
ファイルには、メニューとは無関係に食堂が発注すべき
材料と発注数、そして発注先に関する情報が格納され
る。材料発注ファイルの内容の更新方法については詳細
は後述するが、オーダ受付ファイルに格納されている注
文されたメニューの数量と、材料ファイルに格納された
各メニューの材料毎の必要数量とを参照して、材料数量
が逐次更新される。そして、食堂側では材料発注ファイ
ルに格納された数量分、各発注先に対して材料を発注す
る。

【００３４】ここで、例えばたまねぎを発注する場合
に、一個未満を発注することはできないであろう。この
場合、材料発注ファイルに格納される材料の数量に端数
が生じる場合には、端数分を自動的に単位数に切り上げ
る。たまねぎの例であれば、注文数と材料ファイルに格
納された必要数とに基づいて算出された必要数が１個未
満の端数を生じる場合、合算した端数が１個に達するま
で合算数量を自動的に１個に切り上げる。

【００３５】また、発注先情報としては、図６の場合に
は発注先名が記録されている。ここで、発注先にもネッ
トワークで接続された端末装置が設置されている場合に
は、これを利用することが可能である。そのため、これ
に対処するためには、発注先毎のメールアドレスなどを
格納しておき、発注時にこれを参照して自動的にネット
ワークを介して発注情報を各発注先に伝送するようにし
てもよい。当然のことながら全ての発注先がネットワー
クで接続されているわけではないので、この場合には電
話／ファクス番号等を発注先明とともに記録すればよ
い。

【００３６】また、「納入日」の欄には、注文した材料
が納入される予定日が設定されている。この「納入日」
情報は、材料が納入されたか否かのチェックに用いるこ
ともできる。つまり、材料が納入されるべき日に、材料
発注ファイルを参照して、その日が納入予定日となって
いる材料に関する情報（材料名）を読みだす。そして、
各材料毎に納入されたか否かを確認するのである。

【００３７】図７は献立ファイルである。ここには、あ
る日（図示の例では１月１３日）に調理する必要がある
メニューについて、必要数量と、調理する上で必要とな
る材料とその数量が対応づけて格納されている。また、
献立ファイルには材料の納入日（予定日）と、材料が納
入されたか否かを識別するための検品フラグが設定され
る。なお、納入日と検品フラグについては、別ファイル
とすることも可能であるし、また材料発注ファイルと内
容が一部重複するため、一方のみを設定するようにして
もよい。

【００３８】献立ファイルに格納された情報は、厨房端
末や売場端末に送られて、調理する上で必要な情報がこ
れらの端末上に表示される。厨房を例にとれば、その日
に調理する必要があるメニューとその数量、材料数等を
厨房端末に表示することができる。これによって、調理
時に何をどれだけ調理すればよいのかを一目で確認する
ことができる。さらに、当日利用するために調理済みの
数量が書き込まれる欄も、献立ファイルには設定されて
いる。この欄は、調理時にどのくらいの数が調理済みな
のか、あるいはあとどれくらい調理すればよいのかを厨
房で把握するために用いられる。

【００３９】メニューによっては、注文された数量を一
度には調理しきれない可能性があるので、このときには
同じメニューを数度に分けて調理しなければならない。
この際に、いくつ調理済なのか、あるいはあといくつ調
理する必要があるのかという情報を厨房端末に表示する
ことは運用上非常に有効である。そこで、献立ファイル
内に上記した情報を格納し、厨房端末に情報を表示する
際には調理済み数あるいは残未調理数を表示する。

【００４０】また、大盛りなどの特別注文（オプショ
ン）がある場合には、この情報も献立ファイルに設定す
る。図７では図示されていないが、大盛り等のオプショ
ン品の数量を、全体の要調理数とは別に献立ファイルに
書き込めばよい（内数でも可）。これによって、どのよ
うなオプション品を、いくつ調理すればよいかを厨房端
末に分かりやすく表示することができるし、調理間違い
なども低減できる。

【００４１】図８は個人設定ファイルであり、図８の例
では従業員番号と客毎のパスワードとが対になって設定
されている。これは客が注文する際に入力するパスワー
ドとの照合を行うために用いられるものであり、通常の
操作ではみることはできないように構成される。図８の
場合には、客毎に支払い方法を特定していないケースを
想定している。ここで、前述したような会員制の店のよ
うに、客が特定できれば支払い方法も特定できるような
ケースもある。この場合には、個人設定ファイルに支払
い方法を記録する欄を設定する。また、現金払いのみを
認めるケースのように、客に関わらず支払い方法が一律
となるケースの場合には、支払い方法に関する情報をい
ずれのファイルにも設定しなくてもよい。

【００４２】本実施形態では、これらのファイルが食堂
サーバに設定される。なお、各図に図示されたファイル
の内容を一つのファイルにまとめるような変形も、当然
可能である。図９は、端末装置側の構成例を図示する図
面である。近年職場にパーソナルコンピュータが設置さ
れるケースが増えているので、端末装置は通常のパーソ
ナルコンピュータ等を用いることができる。また、注文
専用の端末装置を利用することも当然可能である。ここ
で、パーソナルコンピュータにはプリンタが備えられて
いるケースが殆どであり、またＩＣカードリーダ／ライ
タ（図示Ｒ／Ｗ、以下同様に表記）も接続が可能となっ
ている。客が注文する場合には、これらのプリンタやＲ
／Ｗも用いる。

【００４３】客が注文する場合、職場毎に設置されてい
るプリンタを用いて食券が発行される。通常のプリンタ
を使用することによって、新たな食券用のプリンタをわ
ざわざ設置する必要はない（設置することも可能ではあ
る）。また、近年では従業員証としてＩＤカード（磁気
カードやＩＣカード）が使用されていることから、食堂
利用時にこのカードを使用することが考えられる。特に
ＩＣカードは記憶容量が大きいため、食券の変わりに注
文した内容をＩＣカードに書き込むようにすれば、プリ
ンタを用いて食券を印刷する必要はない。

【００４４】図１０は、端末装置内部の構成を示すブロ
ック図である。端末装置は、処理を司るＣＰＵ、ネット
ワークとの通信を行う際に使用される通信制御部、各種
のプログラムを格納するとともに、注文時に入力された
内容が一時的に格納されるメモリ、ディスプレイ、プリ
ンタ、情報入力用のキーボード、カードＲ／Ｗが備えら
れる。

【００４５】図１１は、食堂側の受付端末／管理端末の
構成を図示する図面である。これらの端末についても、
通常のパーソナルコンピュータを使用することができ、
図１０に図示された端末装置と同様な構成である。図１
１の場合には特にプリンタ、カードＲ／Ｗは図示省略さ
れているが、これは本実施形態において必須となる機能
を実現するための最小限の構成のみを図示したためであ
り、必要に応じてこれらを備えていてもよいのは当然の
ことである。

【００４６】図１２は食堂の売場毎に設置される売場端
末の構成を図示する図面である。売場端末は一般的なパ
ーソナルコンピュータ等でもよいが、来店時に客に操作
してもらうことを考慮するならば、利用者の利便を考え
て専用端末としてもよい。売場端末には、ディスプレイ
やカードＲ／Ｗが設けられる。カードＲ／Ｗには従業員
のＩＤカードが差し込まれる。ＩＤカードにその従業員
が注文した内容が書き込まれている場合には、ここから
読みだされた注文内容に応じて、ディスプレイにはその
客が注文したメニューに関連する情報（メニュー名・数
量・場所等各種）が表示される。または、売場端末が食
堂サーバを参照して、ＩＤカードをカードＲ／Ｗに差し
込んだ従業員の注文内容を読み出し、それをディスプレ
イに表示するようにしてもよい。ＩＤカードに従業員番
号等のみが記録されている場合には、Ｒ／Ｗよりこれを
読み出し、食堂サーバを参照してその客が注文したメニ
ュー情報を表示してもよい。この形態は、食堂の運用形
態に応じて適宜決定可能であり、この他の方法が適用可
能であることはいうまでもない。売場端末のディスプレ
イに表示された案内に従って、客は自分が事前に注文し
たメニューを受け取る。

【００４７】なお、売場端末には食券発行の機能を持た
せてもよい。図１２に点線で図示されたプリンタは、食
券発行用のものである。ＩＤカードがカードＲ／Ｗに差
し込まれると、記憶されている注文情報を読みだして、
これに基づいてプリンタから食券が発行される。図１３
は厨房端末の構成を図示する図面である。ここまで説明
した用途のみを考えるのであれば、厨房端末は調理すべ
き内容が表示されれば十分であるため、本実施形態の場
合には特にカードＲ／Ｗや食券発行のためのプリンタは
必要ない（他用途のためには必要となる可能性はあ
る）。そのため、本実施形態による厨房端末では、カー
ドＲ／Ｗやプリンタは特に図示していない。図１４は、
食堂システムを用いて注文を行う場合の、主に利用者の
操作に着目した場合の手順を図示したフローチャートで
ある。

【００４８】まず、食堂システムを使用する場合には、
利用者は自分の職場に設置される端末装置から食堂サー
バ（図面では「食堂のホームページ」）をアクセスす
る。ここで、図面で「ホームページ」と表現した理由
は、近年のインターネットの利用拡大を考慮したもので
ある。食堂サーバがアクセスされると、食堂サーバから
メニュー選択用の画面情報が端末装置に対して送信され
る。端末装置は受信した画面情報を画面上に表示するた
め、利用者は画面から注文しようとするメニューを選択
する。そして、選択された注文情報は食堂サーバに送付
される。続いて、食堂サーバは端末装置から送信された
情報に基づいて注文書画面を作成し、端末装置に画面情
報を転送する。端末装置では、転送された注文書画面を
ディスプレイに表示し、利用者による注文書の入力を待
つ。注文書は、入力した注文の内容を確定させるために
用いられる。注文書画面の詳細については、後述する。

【００４９】利用者は、注文書画面から注文内容を入力
する。注文書入力が確定すると、これに応答して確認画
面が端末装置上に表示される。この確認画面によって、
利用者は注文内容が正しく入力されたか、あるいは注文
を確定してよいか、確認することができる。注文内容を
確認した後、利用者は確認操作を行う。一方、注文内容
を変更する場合には、再び注文画面を表示させ、あらた
めて注文の入力が行なわれる。

【００５０】図１５は、図１４の操作に続いて端末装置
備えつけのプリンタを用いて引換券（食券）を発行する
場合の動作を説明する。確認操作が行われると、入力さ
れた注文内容は確定したものとして食堂サーバに一旦送
信される。これに応じて、食堂サーバは端末装置に対し
て引換券発行のために必要となる情報を送付する。端末
装置は、この情報を受信した後引換券発行のために情報
を編集し、プリンタを動作させて引換券を発行する。

【００５１】図１６は、図１５の処理に代えて利用者が
保持するカード（ＩＣカード等）に注文内容を書き込む
場合の処理を示す。図１４で確認操作が行われた後、注
文確定が食堂サーバに転送される点までは、図１５の場
合と同様である。そして，引換券発行の場合と同様に注
文品に関する情報が食堂サーバから端末装置に対して送
信される。なお、引換券発行時の情報と、カードに書き
込まれる情報は全く同じものであってもよい。つまり、
紙として印刷される引換券をＩＣカード内に代わりに書
き込むようにしている、と考えることができるからであ
る。当然、上記のような引換券／カードといった形態別
に、別情報を作成するようにしてもよい。

【００５２】端末装置が食堂サーバからの情報を受信す
ると、利用者に対してカードＲ／Ｗにカードを挿入する
よう促すメッセージを表示する。これに伴い利用者がカ
ードをカードＲ／Ｗに挿入すると、端末装置は挿入され
たカードに注文内容に関する情報を書き込んだ後、カー
ドを排出する。このような処理／操作により、一連の注
文処理が実行される。各手順の詳細については、必要に
応じて後述する。

【００５３】図１７及び図１８は、注文時の端末装置と
食堂側での一連の動作の詳細を説明するフローチャート
である。図示右側は端末装置側、図示右側は食堂サーバ
側での処理を示している。端末装置側ではまず食堂サー
バをアクセスする。これに応じて、食堂サーバでは初期
画面データを端末装置に転送する。端末装置は、受信し
た初期画面データに基づいて、画面上に初期メニューを
表示する。

【００５４】図１９は、初期メニュー画面の例を図示し
た図面である。初期メニュー画面上には、利用者が選択
可能なメニューの大分類の項目と、暗証番号設定の項目
（詳細後述）とが表示される。利用者は、初期メニュー
画面を用いて注文するメニューの大分類をまず選択す
る。初期メニューから大分類メニューが選択されると、
その結果は食堂サーバに通知される。すると、食堂サー
バではメニューファイルを参照して、選択された大分類
に対応する小分類情報を読みだして、端末装置に転送す
る。端末装置では、転送された小分類情報画面を、画面
上に表示する。ここでは、まずメニューの一覧が表示さ
れる。

【００５５】図２０は、図１９に図示される画面から和
食メニューが選択された場合の、選択メニュー一覧の例
を図示するものである。メニュー一覧には、食堂が提供
可能なメニュー名と値段、熱量が一覧表示されている。
メニュー画面から利用者が特定のメニューを選択する
と、詳細メニュー画面が端末装置の画面上に表示され
る。

【００５６】図２１は、詳細メニュー画面の表示例を図
示するものであり、焼き魚定食が選択された場合の例が
図示されている。詳細メニュー画面には、選択されたメ
ニューの内容（品目）とともに、メニューの写真が表示
される。これによって、利用者は選択しようとするメニ
ューの内容を確認できる。なお、図２１に図示された詳
細メニュー画面で「ごはん」については大盛り時に２０
円増しとなることが述べられている。これにより、利用
者は焼き魚定食についてはごはんの大盛りが可能である
ことを理解できる。

【００５７】また、詳細メニュー画面の右すみには「注
文」欄と「戻り」欄とが設定される。「注文」欄が選択
されると、詳細メニューに表示されたメニューの注文が
食堂サーバ側に転送される。また「戻り」欄が選択され
ると、画面は再び選択メニュー画面に変わる。詳細メニ
ュー側で「注文」欄が選択されたことを受けて、食堂サ
ーバは注文書画面を、選択されたメニューに応じて編集
し、端末装置に転送する。

【００５８】図２２は、注文書の例を図示する図面であ
り、食堂サーバから情報を受信した端末装置の画面上に
表示されるものである。注文書には、注文日が自動的に
表示される。また、注文書には従業員番号入力欄、注文
品表示欄、注文個数表示欄、オプション情報選択欄、オ
プション対象個数表示欄、利用日時表示欄、支払い方法
表示欄、暗証番号入力欄がそれぞれ設定されている。

【００５９】従業員番号入力欄には、利用者が手入力、
あるいはＩＤカードの読取により、従業員番号が入力さ
れる。注文品表示欄には、詳細メニュー画面で選択され
たメニュー名が表示される。オプション情報選択欄は
「ごはん大盛り」などの各種オプション（特別注文）に
関する情報を選択するために用いられる。オプションの
内容は、選択されたメニューに応じて定まっており、利
用者はこの中から適宜希望する内容を選択する。

【００６０】個人毎に好き嫌いにより、あるいは体質や
健康上の問題から、食べることができないもの／食べな
いものが多々ある。本実施形態によるオプション選択
は、このようなケースにも対処することができる。つま
り、オプション情報選択欄から自分が食べることができ
ないものを入力することで、特定の品を注文したメニュ
ーから取り除くことができる。「焼き魚定食」の例でい
えば、例えば「野菜サラダ」を省く、あるいは「野菜サ
ラダ」の中身の特定のものを除く、といった対応が可能
となるであろう。

【００６１】また、食堂側で対応が可能であれば、オプ
ションとしては本来はメニューに含まれていない品の追
加を指定することも可能である。利用日時表示欄には、
本実施形態では翌日分の注文を基本に考えているので、
自動的に翌日の昼食時間が表示される。ただし、利用者
は必ずしも翌日分のみの注文を行うわけではなく、また
昼食時間には来店できないケースもある。このため、本
実施形態では利用日時欄から手入力で日時を入力するこ
とにより、利用日時を変更することが可能である。

【００６２】利用日時、特に時間が予め指定されていれ
ば、食堂側はその時間に合わせて料理を調理すればよ
い。そのため、利用日時を確認画面から入力してもらう
ことは食堂側にとって非常に有用なことである。本実施
形態では社員食堂の例を考慮しているため、支払い方法
欄には自動的に「給料天引」が表示される。ただし、社
員食堂に訪れる利用者全てが社員であるとは限らず、給
料天引き以外の支払い方法も選択可能としておく必要が
ある。そのため、他の支払い方法（現金払いやカード利
用等）を選択する場合、支払い方法欄から所望の支払い
方法を選ぶ。

【００６３】食堂システムの利用は、特に金銭的なやり
とりが発生するため、本実施形態では暗証番号を入力さ
せることで、利用者が正当な者であるか否かを判定す
る。入力された暗証番号は、従業員番号とともに食堂サ
ーバ側で照合され、入力が正しいか否かが判断される。
これらの情報の入力が確定すると、食堂サーバに対して
注文書が転送されるため、これに応答して食堂サーバか
ら端末装置に対して注文受付確認画面情報が転送され、
同画面が端末装置に表示される。図２３は、注文受付確
認画面の一例を図示した図面である。

【００６４】注文受付確認画面には、注文時、利用日
時、注文品と数量、オプションがあればさその内容、代
金と支払い方法といった項目が表示される。利用者は注
文受付確認画面を参照して、自分の注文内容が正しく入
力されたか否かを確認する。注文受付確認画面の右隅に
は「確認」欄と「取消」欄とが設定されている。注文内
容が正しい場合あるいは変更しない場合には「確認」欄
が選択される。これによって、注文内容が確定し、その
旨食堂サーバに通知される。「取消」が選択されると、
前の画面（選択画面等）が表示される。

【００６５】「確認」が選択されると、食堂サーバでは
注文が確定したものと見なし、入力された注文内容に基
づいて、既に詳細を説明した注文ファイル等の各ファイ
ルの内容を更新する。これによって、一連の注文処理が
完了する。図２４は暗証番号（パスワード）の設定を考
慮した場合の、端末装置での処理を図示したフローチャ
ートである。食堂サーバがアクセスされ、初期メニュー
が表示されると、端末装置ではパスワードの設定が選択
されたか否かが判別される（項目選択有無の監視）。パ
スワード設定が選択されない場合には、続いてメニュー
（大分類）が選択されたか否かが、これも監視により判
別される。

【００６６】ここでパスワード設定が選択されると端末
装置は図２５の処理を実行する。図２５は、パスワード
設定の一連の処理を図示したフローチャートである。ま
た、図２６はパスワード設定の初期画面を図示するもの
である。ここで、パスワード設定には新規の設定とパス
ワード変更とがあるため、図２５に図示される初期画面
を用いてどちらを行うのかを利用者に選択させる。

【００６７】まず、新規設定の場合について説明する。
これは、客が新たに食堂システムを利用する場合などに
実行される。パスワード設定の初期メニューから「新規
設定」が選択されると、画面上に暗証番号新規設定画面
が表示される（図２７）。暗証番号新規設定画面には従
業員番号入力欄と暗証番号入力欄とが設定されている。
利用者は、暗証番号新規設定画面を用いて、自分の従業
員番号とともに、設定しようとする暗証番号を入力す
る。なお、暗証番号は第三者からは見えないようにする
ために、図２６の例では暗証番号が入力された桁位置に
はアスタリスクが表示されている。

【００６８】暗証番号新規設定画面から従業員番号と暗
証番号とが入力されると、続いて暗証番号設定確認画面
（図２８）が表示される。ここでは、先に入力した暗証
番号を再入力させることにより、暗証番号が正しく、利
用者が考えている通りに入力されたか否かが確認され
る。ここで、暗証番号新規設定画面から入力された暗証
番号と、暗証番号設定確認画面から入力された暗証番号
とが一致する場合、暗証番号の設定処理を終了し、図２
６の初期メニュー画面が端末装置に表示される。

【００６９】一方、暗証番号が正しく再入力されなかっ
た場合には、画面上に「指定した暗証番号を再度入力下
さい。」という暗証番号入力誤りを知らせるメッセージ
を画面上に表示し、再度暗証番号の再入力を行うよう利
用者に促す。次に、暗証番号の変更時の処理について説
明する。暗証番号設定画面で「番号変更」が選択される
と、端末装置には暗証番号変更画面が表示される（図２
９）。この画面が表示されると、利用者は自分の従業員
番号とともに、その時点での暗証番号を入力する。この
処理により、暗証番号を変更しようとする者の正当性が
確認される。

【００７０】現暗証番号が正しい場合には、続いて新た
な暗証番号を新暗証番号入力欄から入力する（図３
０）。続いて、新規設定の場合と同様に、図２８に図示
される暗証番号設定確認画面が端末装置に表示される。
暗証番号が設定されると、食堂サーバ側にこの情報が転
送される。そして、個人ファイル内に従業員番号と対応
付けて格納される。

【００７１】暗証番号の設定後に再び初期メニューが表
示されるため、引き続き注文を行おうとする利用者は通
常の注文時と同じようにメニューの選択を行うことがで
きる。ここで、従業員番号の代わりに氏名、住所等を入
力できるようにすれば、一般の食堂などの利用登録に図
２５の処理を応用することができる。この際に、支払い
方法の一つの選択肢としてクレジットカード支払いがあ
る。社員食堂とは異なり、客の特定がしにくい場合に
は、クレジットカード番号などの入力を求め、支払い能
力に問題がないかどうかの確認を行うことも有用であろ
う。

【００７２】図３１は、注文が受け付けられた後の食堂
サーバ側での処理手順を示したフローチャートである。
利用者からの注文が転送されると、食堂サーバではまず
オーダ受付ファイルに従業員番号、来店日時、注文され
たメニュー、数量、オプションがあればその情報が書き
込まれる。続いて、食堂サーバでは注文されたメニュー
に対応する材料ファイルを参照する。

【００７３】材料ファイルが参照されると、食堂サーバ
では次に材料ファイルより注文品に対応する材料と必要
個数を読みだして、これに基づいて材料ファイルを更新
する。これは、材料ファイルに格納された材料毎の個数
を、新たに注文を受けたメニューの個数分加算してい
く。ここで、先に述べた通り材料ファイルは材料の発注
に使用されるため、単位個数未満の場合には、合算した
個数が単位個数に達するまで、個数欄はは単位数に切り
上げられた個数が記録されるようにしている。

【００７４】続いて、転送された注文品に基づいて、献
立ファイルの内容を更新する。献立ファイルにはある日
に調理する必要があるメニューの数量（材料含む）が、
メニュー毎に記録されている。新たな注文が発生した場
合には、献立ファイルの個数を更新していく。同様に、
メニュー毎の材料数量を更新する。本実施形態による食
堂システムでは、主に材料発注の都合上、受付締切り時
間が設定されている。図３２は、端末装置からの注文が
あった場合の食堂サーバでの処理を図示した図面であ
る。ここでは、メニュー選択の操作が行われると、その
時刻が締切り時間前か否かが判別される。締切り前であ
れば注文を受け付けるが、締切り時間のちであれば注文
は受け付けられない。

【００７５】また、ある日の調理に間に合わせるように
材料を発注するためには、例えば前日の午後までに材料
を各発注先に発注する必要があるからである。そこで、
締切り時間に達すると、食堂サーバ側では材料ファイル
の内容を読み出して、そこに記録されている各材料を、
各発注先に対して発注する。一旦注文した後、注文内容
の変更や取消を利用者が希望する場合がある。この場合
でも、本実施形態による食堂システムでは、締切り時間
前を条件に対応できるようにする。図３３は、そのため
の処理手順を説明するためのフローチャートである。

【００７６】注文取消時には、利用者は食堂サーバをア
クセスし、取消画面を選択する（特に図示せず）。する
と、食堂サーバでは取消操作が締切り時間後であるか否
かを判別する。締切り時間後である場合、材料が既に発
注済である可能性が高いために、食堂サーバでは注文の
取消（変更）を受け付けることができない。そのため
に、端末装置に対して取消操作が締切り時間後であるこ
とを利用者に通知するための画面を表示するように指示
する。同時に、キャンセルすることでキャンセル料が発
生することなども利用者に通知される。

【００７７】続いて、食堂サーバでは端末装置にキャン
セル可否確認のための画面を表示することを指示する。
キャンセルが不可の場合には、注文の取消は行わずに処
理を終了する。一方、キャンセルを行うことを示す操作
がなされた場合には、取消し処理が行われる。なお、締
切り後のキャンセルであったにも関わらず、キャンセル
料が支払われないようなケースも考えられる。これは特
に、現金などその場での支払いが行われた際に問題とな
る。従って、締切り後のキャンセル発生時には、キャン
セル料が支払われたか否かを確認する必要がある。そし
て、締切り後のキャンセルが多く、且つキャンセル料が
支払われない客については、食堂システムの利用を制限
する必要もでてくるであろう。

【００７８】また、取消操作が締切り時間前であった場
合にも取消の処理が実行される。取消処理を行う場合に
は、食堂サーバ側で受付ファイルを参照し、当該利用者
の注文品を読みだす。そして、取消画面を編集し、端末
装置に転送する。取消画面には、当該利用者が注文した
品と利用予定日時が少なくとも表示される。なお、同一
利用者が複数の日時分注文をしている場合には、当該利
用者の全ての来店予定日時を一覧表示し、利用者に選択
させるようにする。一画面内に入りきらない場合には、
分割して表示するようにしてもよい。

【００７９】取消画面が表示されると、利用者は取消を
しようとする内容を選択し、取消操作を行う。取消装置
の後に、注文時の確認画面と同様に取消内容を確認する
画面を表示する。確認画面で利用者の取消が確認される
と、食堂サーバでは各ファイルの内容を取消内容に応じ
て修正・更新する。なお，取消処理はある日時のために
注文した内容を一括して取り消すのではなく、一部のみ
取消とすることも当然可能である。例えば、複数の品を
同日に注文した場合に、一品のみを取り消す必要がでる
ケースなどである。

【００８０】また，注文の変更も同様の手順により処理
される。この場合には取消の代わりに変更内容が各ファ
イルに書き込まれることになる。図３４は、厨房端末を
用いた処理の手順を図示したフローチャートである。厨
房端末では、当日調理されるべきメニューとその個数を
表示することができるが、図３４はそのための手順を示
している。

【００８１】図３５は、厨房端末に表示される画面の例
を図示するものであり、図３５の例では当日調理すべき
メニューとその数量が合わせて表示される。詳細表示を
行うためには、厨房端末で図３５の画面に表示されてい
く品目を選択する。品目の選択は、キーボードや各種の
ポインティングデバイスを用いることができ、また画面
上にタッチパネルを形成すれば画面に触れるだけで品目
を選択することができる。

【００８２】ここでは、品目毎の材料等の詳細を表示す
る例について説明する。図３５の画面で「カツ丼」が選
択されると、カツ丼を調理するために必要な材料と、全
体を調理するための必要個数、一品当りの材料の必要個
数が合わせて表示される（図３６）。また画面の右隅に
はオプションの参照欄が設けられている。ここでは、オ
プションの有無とその内容、材料の数量などの変更に関
する情報が表示される。なお、図３６の例では全体を調
理するために必要な材料・数量と、１品当りの材料・数
量とが表示された例が図示されるが、後に詳述する通
り、未調理残数を入力・表示することに対応して、未調
理残数を調理するために必要な材料の数量を表示できる
ようにしてもよい。

【００８３】あるメニューが調理されると、厨房端末を
用いて調理済みであることが入力される。ここで、前述
の通り全ての注文品を同時に調理することは困難な場合
もあるため、調理済み数量をメニュー毎に入力できるよ
うにしている。この内容は献立ファイルに反映され、調
理済み数分献立ファイルの注文数が更新される（減
算）。全てが調理済みであるかどうか、あるいは未調理
の残数がどのくらいなのかを厨房端末を用いて確認する
ことができる。

【００８４】図３５の画面でも調理済みを示す情報欄が
設定されており、当該メニューが所定数調理済みである
場合には、その旨を知らせる表示（図示丸印）が行われ
る。これによって、図３５の場合には焼き魚定食はこれ
以上調理する必要がないことが一目で判る。なお、全数
調理済みでないものについては、図３５では特に表示は
おこなっていない。未調理残数を表示するためには、厨
房端末を用いてメニューを選択する。タッチパネルが使
用されている場合には、特定のメニューの調理済みの欄
を触れることで、当該メニューの未調理残数を表示させ
る。

【００８５】図３７はカツ丼についての未調理残数を示
す画面の表示例である。ここでは、未調理残数の全体の
数とともに、通常品も含めたオプション別に未調理残数
が表示されている。このような表示を行うことで、厨房
で過不足なくメニュー毎の調理を行うことができる。な
お、残数を図３５の調理済み画面に合わせて表示するよ
うにしてもよい。この場合、画面切り換えの手間を減ら
すことができる。ただし、オプション品についても図３
５の画面に一緒に表示すると、画面が細々として見にく
くなる可能性もあるために、オプション品を含めた未調
理残数は別画面に表示した方が望ましいと思われる。こ
の場合には、図３５の「調理済」欄に未調理残数を表示
するなどの対処が可能である。

【００８６】図３８は、厨房端末で表示される納品チェ
ック画面の例である。ここでは、各材料毎に確かに納入
されたか否かを確認するために使用される。納品が確認
された材料については画面上丸印が付されているが、例
えば不足等の事由がある場合にはその旨表示される（図
示三角）。図３９は厨房端末に使用されるキーボードの
部分を図示したものであり、テンキー部とともに各項目
を指示するためのキーが配置されている。項目キーとし
て図示の例では「特注（オプション）確認」、「検品確
認」、「材料参照」、「調理済入（力）」、「備考参
照」などの項目が設定されているが、これらは適宜変更
可能である。例えば「材料参照」のキーを押下すると、
図３８の画面が表示されるように制御される。

【００８７】図４０は利用者が来店した場合の処理・操
作手順を図示したフローチャートである。ここでは、Ｉ
Ｄカードを利用する場合について特に例示する。利用者
が来店すると、売場端末にＩＤカードを挿入する。この
処理は、図示される通り端末から従業員番号を手入力す
るものでもよい。これによって、売場端末では食堂サー
バを参照し、受付ファイルから当該利用者が注文したメ
ニューに関する情報を読みだして、売場端末に表示する
（図４１）。合わせて、どの場所にいけば注文した品物
を受け取ることができるのかを示す情報を表示する。こ
れは、メニュー毎に売場を対応付けて受付ファイルある
いはメニューファイルに予め格納しておけば対応可能で
ある。

【００８８】また、オプション品を注文した客について
は、オプション品が注文されていることを確認させるた
めの情報も表示する。ここで、オプション品などの条件
付きの注文を行った利用者が来店したことが、ＩＤカー
ドの挿入・ＩＤ読取に伴って、厨房端末等に表示され
る。これによって、大盛りなどのオプション品を当該利
用者に確実に手渡すことができる。

【００８９】利用者が注文した品を受け取ると、献立フ
ァイルから引き取り済商品数を減算していく。これによ
って、メニューの残量を随時確認することが可能とな
る。ＩＣカードに注文内容が記録されているケースであ
れば、注文品表示の際に食堂サーバを参照しなくてもよ
い。また、支払いについては、予め注文時に支払い方法
が指定されている。そこで、客が店舗端末を利用した時
点で、支払い方法を確認させるための表示を行う。給料
天引などその場での現金移動等がない場合であれば「支
払い済」等の表示を行う。一方、現金払いやカード類に
よる支払いが選択されている場合には、別途設けられた
精算カウンタに客を誘導するための表示を行う。

【００９０】ここで、客による不正を防止するために
は、現金払いを指定した者が支払いを行わなかった場合
に、アラームを上げる、等の対処法をとればよい。図４
２は、材料検品後の処理フローチャートを図示する図面
である。材料が検品されると、入力に応じて献立ファイ
ルの検品フラグがオンにされる。また、厨房端末からの
指示により献立内容がファイルから読みだされて、厨房
端末に表示される。

【００９１】メニューが調理される毎に、調理済メニュ
ーやその数量が厨房端末より入力されると、献立ファイ
ルの数量等が更新される。図４３は、注文の結果、指定
した利用日時では利用予約で満杯である場合に、端末装
置で表示される画面例を図示した図面であり、特に予約
制の食堂で利用する場合に有用である。画面の下には、
確認のためのボタンが設定されている。ここで、端末装
置と食堂サーバとはネットワークで接続されているた
め、利用者の要望等を食堂側に伝えやすいという特性が
ある。そこで、端末装置にアンケート画面を表示させ、
利用者が今後提供してほしいと望むメニューをアンケー
ト画面から入力してもらうようにしてもよい。

【００９２】食堂サーバでは、利用者からのアンケート
の回答を集計する。これによって、利用者の嗜好の傾向
を把握することができ、利用者の要望に適したメニュー
の提供が可能となる。従前では、食堂で過去の実績によ
りメニューを決定するか、世の中の流れに基づいてメニ
ューを決定していた。前者については、提供したことが
ないようなメニューを追加することが非常に困難であ
り、後者については世の中の流行とその店の実際の客層
とのギャップが大きくなると、利用者が望む料理は提供
できなくなる。

【００９３】本実施形態によればこのような問題は解消
可能であり、利用者へのサービス提供が向上する。な
お、上記した実施形態では、材料発注数／調理数を客か
ら注文された数と同数とする例が特に説明されている。
しかし、完全予約制の店ならばともかくとして、当日急
に来店する客が出てくる可能性はどうしても残る。この
ような場合に予約分のみ調理しておくと、予約なしで当
日来店した客が食堂を利用できないか、このような客が
先に料理を取ってしまい、予約客が自分の注文品を受け
取ることができない可能性がでてくる。

【００９４】このようなケースに対処するためには、発
注する材料数や、当日の調理数を幾分割増することが考
えられる。具体的には、図６の材料発注ファイルや図７
の献立ファイルに設定される調理数／材料数量を、幾分
か割増して記録する。つまり、予約分をまかなうために
必要となる数量よりも若干多めに材料を発注し、多めに
料理を調理するのである。

【００９５】ここで、割増数は店側の経験から判断する
のが一番確実であるが、判断材料を持たない場合には、
各メニュー毎に、一律同じ量だけ割増してしまうのが簡
単である。このような余分の発注／調理はしかし、無駄
が生じてしまう。だが、ベースとなる数字が全くない状
況から発注数／調理数を予測する場合と比較すると、オ
ーダリングシステムにより予め予約されているケースで
は、最小限の必要数が予め判っているため、発注／調理
の無駄は確実に低減されるであろう。

【００９６】また、このようなケースでは、予約済の料
理は予約客に確実に確保されている必要がある。そのた
めには、未予約客に対して提供してもよい料理数を、常
に把握する必要がある。未予約客に提供可能な料理数
は、全調理数量から予約済数量を差し引いた数に相当す
る。そして、この分は予約分とは別個にしておく。客が
来店する毎に、ＩＤカードの操作などによってこの客が
予約済の客か否かを判別する。そして、予約客か否かに
応じて、客を誘導する先を変える。

【００９７】予約客については、予約客分の料理が確保
されたところに誘導する。また、未予約客については、
未予約客用の料理が容易されたところに誘導する。いず
れの場合についても、料理が引き取られる毎に残数量を
算出する。特に未予約客分については、常に残数量を表
示しておき、残量が「０」となった料理については「残
なし」を示すメッセージを表示することが望ましい。あ
るいは、未予約客が来店時に一目で判断することができ
るように、提供可能な料理の一覧とその数量を表示でき
るようにしてもよいであろう。

【００９８】また、当日来店した未予約者については、
オーダリングシステムによる本人確認が行われていない
ため、現金などの支払い方法を選択させ、給料天引等は
避けることが、後日のトラブルを回避するためには好ま
しいであろう。

【００９９】

【発明の効果】このようなオーダリングシステムを用い
ることで、以下のような効果を実現することができる。 １）特に食堂の場合には、事前にどのようなメニューが
どの位注文されているのかを判別することができる。そ
のため、調理・材料発注数をその数に合わせて決定すれ
ばよく、勘に頼ることなく、効率的な食堂運営が可能と
なる。 ２）客からの注文内容を自動的に集計・更新することが
できるため、店側は煩わしい集計のための手間が省け
る。 ３）自動的に各発注先に対して、注文内容に応じて材料
等の発注を行うため、店側は発注ミス等を防止すること
ができる。 ４）客側からは、事前に、職場等に設置されているパソ
コン等を用いて、簡易に注文を行うことができる。食堂
の場合には予約を簡単に行えるため、客としても利便性
が高くなる。また、食堂側は注文内容に合わせて材料発
注／調理を行うため、客は注文したメニューを受け取れ
ないという問題が生じる可能性が非常に低くなる。 ５）支払い方法を客や状況に応じて選択可能としている
ため、客としては利便性が高くなる。 ６）予め注文を受け付けているため、材料発注／調理は
この注文数に合わせればよい。そのため、無駄な材料の
発注／調理の恐れが従来と比較して非常に低減される。

【図面の簡単な説明】

【図１】本発明の一実施形態による食堂システムを示す
図面。

【図２】食堂側のシステム構成を示す図面。

【図３】メニューファイルの構成を示す図面。

【図４】材料ファイルの構成を示す図面。

【図５】オーダ受付ファイルの構成を示す図面。

【図６】材料発注ファイルの構成を示す図面。

【図７】献立ファイルの構成を示す図面。

【図８】個人設定ファイルの構成を示す図面。

【図９】端末装置の構成を示す図面。

【図１０】端末装置の内部構成を示すブロック図。

【図１１】受付装置／管理端末の内部構成を示すブロッ
ク図。

【図１２】売場端末の内部構成を示すブロック図。

【図１３】厨房端末の内部構成を示すブロック図。

【図１４】注文次の客による操作に着目した処理手順を
示したフローチャート。

【図１５】プリンタを用いて引換券を発行する際の処理
を示す図。

【図１６】客のカードに注文内容を書き込む際の処理を
示す図。

【図１７】注文時の端末装置／食堂サーバ側での処理手
順を示すフローチャートその１。

【図１８】注文時の端末装置／食堂サーバ側での処理手
順を示すフローチャートその２。

【図１９】初期メニュー画面の表示例を示す図。

【図２０】和食メニュー一覧の表示例を示す図。

【図２１】選択されたメニューの詳細画面の表示例を示
す図。

【図２２】注文書の表示例と記入例を示す図。

【図２３】確認画面の表示例を示す図。

【図２４】パスワード設定を行う場合の食堂システムで
の処理手順を示したフローチャートその１。

【図２５】パスワード設定を行う場合の食堂システムで
の処理手順を示したフローチャートその２。

【図２６】パスワード設定初期画面の表示例を示す図。

【図２７】新規設定画面の表示例。

【図２８】新規設定確認画面の表示例。

【図２９】パスワード変更画面の表示例１。

【図３０】パスワード変更画面の表示例２。

【図３１】注文受付後に食堂サーバ側で実行される処理
手順を示すフローチャート。

【図３２】締切時と締切前の食堂サーバ側の処理手順を
示すフローチャート。

【図３３】注文取消時の食堂システムでの処理手順を示
すフローチャート。

【図３４】厨房端末に情報を表示する際の処理手順を示
すフローチャート。

【図３５】厨房端末に表示される画面例を示す図。

【図３６】あるメニューに対する情報を示す厨房端末の
表示画面の例を示す図。

【図３７】未調理残数の表示画面例を示す図。

【図３８】納品チェック画面の表示例を示す図。

【図３９】厨房端末のキーボード例を示す図。

【図４０】来店時の処理手順を示すフローチャート。

【図４１】客案内表示例を示す図。

【図４２】材料検品時の処理手順を示すフローチャー
ト。

【図４３】満員時のメッセージ表示例を示す図。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 小林 康秀 神奈川県川崎市中原区上小田中４丁目１番 １号 富士通株式会社内 (72)発明者 竪月 忠夫 神奈川県川崎市中原区上小田中４丁目１番 １号 富士通株式会社内 (72)発明者 増田 稔 神奈川県川崎市中原区上小田中４丁目１番 １号 富士通株式会社内 (72)発明者 西沢 俊輔 神奈川県川崎市中原区上小田中４丁目１番 １号 富士通株式会社内

Claims (22)

【特許請求の範囲】
1. 【請求項１】 互いに伝送路で接続された、食堂サーバ
   と、食堂の利用者が操作する端末装置とを備えるオーダ
   リングシステムであり、 前記食堂サーバには、食堂が提供するメニューに関する
   情報を格納するメニューファイルと、前記メニューファ
   イルに格納されたメニュー毎に必要となる材料名と数量
   が格納された材料ファイルと、利用者が前記端末装置か
   ら注文したメニューに関する情報を格納する受付ファイ
   ルと、前記利用者による注文に基づいて材料毎に必要と
   なる数量を集計する材料集計ファイルと、ある期間に調
   理する必要があるメニューとその数量およびメニュー調
   理に必要な材料に関する情報を格納する献立ファイル
   と、を備えることを特徴とするオーダリングシステム。
2. 【請求項２】 前記食堂サーバにおいて、前記材料集計
   ファイルには各材料毎の発注先に関する情報が格納され
   ることを特徴とする、請求項１に記載のオーダリングシ
   ステム。
3. 【請求項３】 前記食堂サーバは、発注先に備えられた
   端末装置と伝送路により接続されており、 前記材料集計ファイルには発注先の端末識別情報が格納
   されており、 前記食堂サーバからの材料発注時には、前記端末識別情
   報に基づいて伝送路を用いて発注情報を発注先端末装置
   に伝送することを特徴とする、請求項２に記載のオーダ
   リングシステム。
4. 【請求項４】 前記食堂サーバにおいて、 利用者からの注文受付の締切り時間が設定され、前記締
   切り時間となった後に前記材料集計ファイルの情報に基
   づいて材料の発注を行うことを特徴とする、請求項１乃
   至請求項３のいずれかに記載のオーダリングシステム。
5. 【請求項５】 前記食堂サーバにおいて、 前記受付ファイルには、利用者が注文したメニュー名と
   その数量、利用時間、支払い方法並びに特別注文に関す
   る情報が格納されることを特徴とする、請求項１に記載
   のオーダリングシステム。
6. 【請求項６】 前記オーダリングシステムにおいて、 前記献立ファイルには、調理済みメニューの調理済み数
   量に関する情報が格納されることを特徴とする、請求項
   １に記載のオーダリングシステム。
7. 【請求項７】 前記オーダリングシステムにおいて、 前記調理済みメニュー数量に基づいて、未調理数量を算
   出し、前記未調理数量を画面表示することを特徴とす
   る、請求項６に記載のオーダリングシステム。
8. 【請求項８】 前記オーダリンクシステムにおいて、 前記献立ファイルには、各メニュー毎に未調理数量に関
   する情報が格納されることを特徴とする、請求項１に記
   載のオーダリングシステム。
9. 【請求項９】 前記オーダリングシステムにおいて、 前記献立ファイルには、各材料毎に納入の有無を識別す
   るフラグが設定されることを特徴とする、請求項１に記
   載のオーダリングシステム。
10. 【請求項１０】前記オーダリングシステムにおいて、 前記材料集計ファイルには、各材料毎に納入の有無を識
    別するフラグが設定されることを特徴とする、請求項１
    に記載のオーダリングシステム。
11. 【請求項１１】前記オーダリングシステムにおいて、 前記メニューファイルには、各メニュー毎に写真情報が
    格納されることを特徴とする、請求項１に記載のオーダ
    リングシステム。
12. 【請求項１２】食堂に設置される情報処理装置におい
    て、 前記情報処理装置は、食堂が提供するメニューに関する
    情報を格納するメニューファイルと、前記メニューファ
    イルに格納されたメニュー毎に必要な材料とその数量が
    格納された材料ファイルと、利用者の注文に関する情報
    を格納する受付ファイルと、注文内容に基づいて各材料
    毎に必要な数量を集計する材料集計ファイルと、ある期
    間に調理されるべきメニューとその数量およびメニュー
    調理に必要な材料に関する情報を格納する献立ファイル
    と、を備えることを特徴とする、情報処理装置。
13. 【請求項１３】前記情報処理装置は、利用者が注文内容
    を入力する注文端末と接続されており、 前記注文端末の操作に応じて利用者の注文を受け付ける
    ことを特徴とする、請求項１２記載の情報処理装置。
14. 【請求項１４】顧客からの注文を受け付けるオーダリン
    グシステムにおいて、 顧客が注文内容を入力する端末装置と、 前記端末装置から入力された注文を受け付けるサーバと
    を備え、 前記サーバには、顧客が注文可能な商品に関する情報を
    格納する商品ファイルと、 顧客が選択した商品を含む注文内容を格納する注文ファ
    イルと、 を備えたことを特徴とする、オーダリングシステム。
15. 【請求項１５】前記オーダリンクシステムにおいて、 前記サーバは更に、 商品と、商品毎の発注先に関する情報が格納される発注
    ファイルを備えることを特徴とする、請求項１４記載の
    オーダリングシステム。
16. 【請求項１６】前記オーダリングシステムにおいて、 前記サーバは更に発注先に発注された商品が納入された
    か否かを判別する検品フラグが設定されるファイルを備
    えることを特徴とする、請求項１７記載のオーダリング
    システム。
17. 【請求項１７】前記オーダリングシステムにおいて、 前記注文ファイルは顧客によりなされた特別注文内容を
    格納することを特徴とする、請求項１４記載のオーダリ
    ングシステム。
18. 【請求項１８】顧客からの注文を受け付けるオーダリン
    グシステムにおけるオーダリング方法において、 注文可能な商品に関する情報を注文用端末装置に表示
    し、 注文用端末装置からの商品選択に応じて、受付端末に設
    けられた、注文内容に関する情報を格納する注文ファイ
    ルの内容を更新することを特徴とする、オーダリングシ
    ステム。
19. 【請求項１９】顧客からの注文を受け付けるオーダリン
    グシステムにおけるオーダリング方法において、 顧客が注文内容を入力する注文用端末装置に、注文可能
    な商品一覧画面を表示し、 顧客による商品選択に応じて、注文内容を入力するため
    の注文書画面を前記注文用端末装置に表示し、 前記注文用端末装置により注文書画面から注文内容が入
    力されたことを受けて、注文内容を顧客に確認させるた
    めの確認画面を表示し、 確認画面に表示された内容を顧客が確認する旨の操作を
    受けて、注文を受け付けることを特徴とする、オーダリ
    ング方法。
20. 【請求項２０】前記オーダリング方法において、 前記商品一覧表示の際に、始めに顧客が注文可能な商品
    の大分類一覧画面を表示し、 前記大分類一覧画面より顧客が商品分類を選択したこと
    を受けて、該当する大分類に属する商品一覧を示す小分
    類一覧画面を表示することを特徴とする、請求項１９記
    載のオーダリング方法。
21. 【請求項２１】顧客からの商品の注文を、注文用端末装
    置から受け付けるオーダリングシステムにおいて、 顧客からの注文入力時点で、注文受付締切り時間を過ぎ
    ているか否かを判定し、 締切り時間を過ぎていない場合には、前記顧客からの注
    文を受け付けるとともに、 前記締切り時間を過ぎている場合には、前記注文用端末
    装置に締切り時間を経過していることを示すメッセージ
    を表示し、前記注文を受け付けないように構成されるこ
    とを特徴とする、オーダリングシステム。
22. 【請求項２２】顧客からの商品の注文受付を行うオーダ
    リングシステムであって、 店舗が提供できる商品に関する情報が格納されたメニュ
    ーファイルを備えた店舗サーバと、 前記店舗サーバとネットワークにより接続された顧客が
    操作する端末装置ととを有し、 顧客が前記端末装置により前記食堂サーバをアクセス
    し、前記メニューファイルに格納された商品を選択する
    ことにより、商品注文が受け付けられることを特徴とす
    る、オーダリングシステム。