(57)【要約】【課題】システム導入時の費用負担を軽減すると共に、顧客に有効な料理情報を提供すること。【解決手段】会員の属性情報を保存する会員ＤＢと、料理の画像パターンを保存する画像情報ＤＢと、会員ごとの注文履歴を保存する注文履歴ＤＢと、顧客の携帯端末から送られてくる画像データを受信して画像情報ＤＢに保存されている画像パターンとを照合して顧客の撮影した料理を特定する料理特定手段と、会員ＤＢに保存されている顧客の属性情報と他の会員の属性情報とを比較して、顧客の属性と類似の属性を有する類似会員を抽出する類似会員抽出手段と、注文履歴ＤＢを参照して、抽出された類似会員の過去の注文情報をもとに料理特定手段により特定された料理と同じ料理を注文した際に、注文した料理以外に他の料理を注文した類似会員が存在するか否かを判定して、存在する場合は当該類似会員の注文した他の料理を顧客に推薦する推薦料理判定手段とを備える。【選択図】図１
2010238118.tif 000002
【特許請求の範囲】
【請求項１】
撮影手段を有する会員登録された顧客の携帯端末と通信回線を介して接続する管理サーバを具備し、前記携帯端末から送られてくる前記撮影手段によって撮影された料理の画像データを用いて注文処理を実行すると共に前記顧客に料理情報を提供するオーダリングシステムであって、
前記管理サーバは、
会員の属性情報を保存する会員ＤＢと、
料理の画像パターンと料理識別情報とを関連付けて保存する画像情報ＤＢと、
会員ごとの注文履歴情報を保存する注文履歴ＤＢと、
前記携帯端末から送られてくる料理の画像データを受信する情報受信手段と、
前記情報受信手段によって受信された画像データと前記画像情報ＤＢに保存されている画像パターンとを照合し、合致する画像パターンに関連付けられている料理識別情報を抽出することによって前記顧客の撮影した料理を注文候補料理として特定する料理特定手段と、
前記料理特定手段によって特定された注文候補料理及び前記推薦料理判定手段によって抽出された注文候補料理に関する情報を、前記顧客の携帯端末に送信する情報送信手段と、を有することを特徴とするオーダリングシステム。
【請求項２】
前記管理サーバ１０は、
さらに、前記会員ＤＢに保存されている前記顧客の属性情報と他の会員の属性情報とを比較して、前記顧客の属性と類似する属性を有する類似会員を抽出する類似会員抽出手段と、
前記注文履歴ＤＢを参照して、前記類似会員抽出手段によって抽出された類似会員の過去の注文情報をもとに、前記料理特定手段により特定された料理と同じ料理を注文した際に、当該注文した料理以外に他の料理を注文した類似会員が存在するか否かを判定し、存在する場合は、当該類似会員の注文した前記他の料理を顧客に推薦する注文候補料理として抽出する推薦料理判定手段と、を備え、
前記情報送信手段は、前記推薦料理判定手段によって抽出された注文候補料理に関する情報を前記顧客の携帯端末に送信することを特徴とする請求項１に記載のオーダリングシステム。
【請求項３】
店舗の厨房内または厨房近傍に設置され、前記携帯端末及び／又は前記管理サーバから送信された注文情報を受信し、受信した注文情報を表示する厨房端末を備えたことを特徴とする請求項１または２に記載のオーダリングシステム。
【請求項４】
前記管理サーバは、店舗名・支店名、住所等の位置情報を含む店舗情報の保存されている店舗ＤＢと、ＧＰＳ機能を有する携帯端末から送られてくる位置情報を受信することによって前記店舗ＤＢにアクセスして、受信した位置情報を用いて現在顧客が利用している店舗を特定する利用店舗特定手段と、を備えたことを特徴とする請求項１乃至３のいずれか一に記載のオーダリングシステム。
【請求項５】
前記画像情報ＤＢには、店舗のマークなど店舗識別可能な画像が店舗ＩＤと関連付けられて保存されており、
さらに、前記管理サーバは、前記携帯端末から送られてくる店舗ごとに備え付けられた店舗識別可能な画像の撮像画像を受信し、当該受信した画像が前記画像情報ＤＢに保存されている店舗識別可能な画像と合致するか否かを判定することによって現在顧客が利用している店舗を特定する利用店舗特定手段を備えたことを特徴とする請求項１乃至３のいずれか一に記載のオーダリングシステム。
【請求項６】
前記画像情報ＤＢには、店舗内のテーブルまたは座席を識別可能な画像が保存されており、
さらに、前記利用店舗特定手段は、前記携帯端末から送られてくるテーブルごとに備え付けられたテーブルまたは座席を識別可能な画像の撮像画像を受信し、当該受信した画像が前記画像情報ＤＢに保存されているテーブルまたは座席を識別可能な画像と合致するか否かを判定することによって現在顧客が利用しているテーブルまたは座席を特定することを特徴とする請求項４または５に記載のオーダリングシステム。
【請求項７】
前記会員ＤＢは、顧客の一回の利用上限金額を保存するようにして、前記管理サーバは、注文候補料理を含めた合計金額と、前記会員ＤＢに記録される利用上限金額とを比較し、合計金額が利用上限金額を上回るか否か判定する上限金額超過判定手段を備えたことを特徴とする請求項１乃至６のいずれか一に記載のオーダリングシステム。
【請求項８】
前記携帯端末はアラーム機能を具備し、前記管理サーバは、メニュー情報として品名・価格・アレルギー等の情報が記録されるメニューＤＢと、当該メニューＤＢにアクセスして、前記注文候補料理に含まれる材料で、摂取する者によってはアレルギー反応を起こす可能性のある材料を特定するアレルギー材料特定手段と、特定したアレルギー材料と一致する材料が前記会員ＤＢの当該顧客の属性情報に記録されている場合は、当該注文候補料理がアレルギー品目に該当すると判定し、前記携帯端末のアラーム機能を起動するよう制御するアラーム起動制御手段と、を備えたことを特徴とする請求項１乃至７のいずれか一に記載のオーダリングシステム。
【請求項９】
前記オーダリングシステムは、一つの料理がＮ個に分割された小料理として注文要求を受け付ける機能を有するオーダリングシステムであって、
前記管理サーバは、小料理の注文数に応じて携帯端末へ表示すべき画像を関連付けて保存する分割メニュー管理テーブルを備え、
所定単位で前記小料理の注文要求を受け付けて、前記分割メニュー管理テーブルを参照して前記小料理の注文数に関連付けられた画像を表示させると共に、前記所定単位の小料理の注文数の合計がＮ個になったときに一つの料理として注文を受け付けることを特徴とする請求項１乃至８のいずれか一に記載のオーダリングシステム。
【請求項１０】
前記オーダリングシステムは、一つの料理が複数に分割された小料理として注文要求を受け付ける機能を有するオーダリングシステムであって、
前記管理サーバは、小料理の注文数に応じて携帯端末へ表示すべき画像を関連付けて保存する分割メニュー管理テーブルを備え、
店舗内の所定単位で注文要求を受け付けて、前記分割メニュー管理テーブルを参照して前記小料理の注文数に関連付けられた画像を表示させると共に、店舗内について前記注文要求の数を集計し、該集計結果に基づいて調理すべき料理の数量を決定する手段を備えたことを特徴とする請求項１乃至８のいずれか一に記載のオーダリングシステム。
【請求項１１】
前記管理サーバから送られてくる顧客の注文した料理の金額情報を受信し、受信した金額情報を顧客に提示するレジ端末を備え、前記管理サーバは、前記携帯端末から送られてくる割勘会計を行う会員Ｎｏ．、および各会員の費用負担割合を含む割勘に関する所定情報を受信して、前記レジ端末に各会員の費用負担割合に応じた会計金額を表示させることを特徴とする請求項１乃至１０のいずれか一に記載のオーダリングシステム。
【請求項１２】
前記管理サーバから送られてくる顧客の注文した料理の金額情報を受信し、受信した金額情報を顧客に提示するレジ端末を備え、前記管理サーバは、前記携帯端末から送られてくる割勘会計を行う会員Ｎｏ．、および各会員の費用負担割合を含む割勘に関する所定情報を受信したときに、割勘会計を行うすべての会員の携帯端末から同じ料理の画像データを受信したか否かを判定し、同じ料理の画像データを受信した場合は該料理の金額を前記費用負担割合に基づいて按分して会員ごとの会計金額を演算し、前記レジ端末に前記演算した会員ごとの会計金額を表示させることを特徴とする請求項１乃至１０のいずれか一に記載のオーダリングシステム。
【請求項１３】
注文された料理、該料理を注文した会員の識別情報、注文を受けてからの経過時間、および該料理の提供を完了したことを示す料理提供完了フラグを関連付けて保存する調理状況管理テーブルと、
顧客の携帯端末から送られてくる注文情報を受信したときに、該注文情報に係る料理を前記調理状況管理テーブルに登録すると共に、前記経過時間のカウントを開始し、該料理の提供完了の入力を検知して前記経過時間のカウントを停止すると共に前記料理提供完了フラグをセットし、少なくとも未提供の料理について該料理の前記経過時間または注文受信時刻と共に前記厨房端末へ表示出力する調理状況管理手段とを備えたことを特徴とする請求項３に記載のオーダリングシステム。
【請求項１４】
前記料理特定手段によって注文候補料理が特定された際に、前記調理状況管理テーブルの経過時間に基づいて料理ごとの待ち時間を演算する待ち時間演算手段と、顧客の携帯端末から前記注文候補情報を受信したとき、前記待ち時間演算手段によって演算された待ち時間を前記携帯端末へ送信する提供状況送信手段と、を備えたことを特徴とする請求項１３に記載のオーダリングシステム。
【請求項１５】
クレジット会社サーバへ前記合計金額その他の必要な情報を通知することによって決済代行処理を実行することを特徴とする請求項７に記載のオーダリングシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、飲食店等において顧客が料理を注文する際にメニュー等に表示されている料理の画像データを取り込んで料理のオーダをすることによって、業務の効率化と顧客サービスの向上を図ることのできるオーダリングシステムに関する。
【背景技術】
【０００２】
現在、ファミリーレストランや居酒屋等では、飲食メニュー等の情報を表示する端末を卓上に設置し、来店者が端末の操作を行って指定した注文情報を厨房等で受信し、飲食物の提供を行うオーダーエントリーシステム（ＯＥＳ）を導入している。
【０００３】
このＯＥＳは、店員を介さずに注文を受付けることが可能であることから、人件費に係るコスト低減を図ることができるというメリットがある。さらに、このＯＥＳに画像処理機能を設けて、顧客サービスの向上を図るシステムが提案されている。たとえば、特許文献１では、カメラによって顧客の注文時の動作や料理の残量を監視して、サービス提供者が迅速に顧客に対応することのできるシステムが提案されている。また、特許文献２では、メニューを電気的に表示する電子メニューに替えて、印刷メニューの所定の領域を注文端末でスキャンすることによって画像を取り込み、予め記憶している管理画像と照合することによってその画像に対応する飲食物の注文を行うシステムが提案されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００４−２１３１２１号公報
【特許文献２】特開２００８−００３７５１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、上述のＯＥＳは店舗内のすべての卓上に注文情報を入力するための電子メニューや注文端末を設置しなければならないほか、注文情報等を電子的に送受信するための基盤（通信回線網）を構築しなければならず、設置コストが高額になるという問題がある。
【０００６】
本発明は、上述の係る事情に鑑みてなされたものであり、従来のＯＥＳに要していたシステム導入時の費用負担を軽減すると共に、顧客に有効な料理情報を提供して顧客サービスの向上を図ることのできるオーダリングシステムを提供することを目的とする。
【課題を解決するための手段】
【０００７】
上記の目的を達成するため、本発明に係わるオーダリングシステムは、撮影手段（カメラ機能）を有する会員登録された顧客の携帯端末と通信回線を介して接続する管理サーバを具備し、携帯端末から送られてくる撮影手段によって撮影された料理の画像データを用いて注文処理を実行すると共に顧客に料理情報を提供するオーダリングシステムであって、管理サーバは、会員の属性情報を保存する会員ＤＢと、料理の画像パターンと料理識別情報とを関連付けて保存する画像情報ＤＢと、会員ごとの注文履歴情報を保存する注文履歴ＤＢと、顧客の携帯端末から送られてくる料理の画像データを受信する情報受信手段と、情報受信手段によって受信した画像データと画像情報ＤＢに保存されている画像パターンとを照合し、合致する画像パターンに関連付けられている料理識別情報を抽出することによって顧客の撮影した料理を特定する料理特定手段と、会員ＤＢに保存されている顧客の属性情報と他の会員の属性情報とを比較して、顧客の属性と類似の属性を有する類似会員を抽出する類似会員抽出手段と、注文履歴ＤＢを参照して、類似会員抽出手段によって抽出された類似会員の過去の注文情報をもとに、料理特定手段により特定された料理と同じ料理を注文した際に、当該注文した料理以外に他の料理を注文した類似会員が存在するか否かを判定し、存在する場合は、当該類似会員の注文した他の料理を顧客に推薦する注文候補料理として抽出する推薦料理判定手段と、料理特定手段によって特定された注文候補料理及び推薦料理判定手段によって抽出された注文候補料理に関する情報を、顧客の携帯端末に送信する情報送信手段と、を有することを特徴とする。
ここで、「画像パターン」とは、判定基準としてパターン化された画像データをいう。
【０００８】
本発明では、顧客の携帯端末の撮影手段（カメラ機能）を利用して、その携帯端末で撮影した料理の画像データと、予めシステムに記憶されている画像パターンとを比較して、注文料理を特定する。また、顧客の属性、特に、年齢、体型、性別、アレルギーその他の嗜好情報が類似している会員を抽出し、抽出した類似会員がその顧客の注文した料理と同じ料理を注文した際に別の料理も注文していた場合は、その別の料理を注文候補料理としてその顧客の携帯端末へ知らせる。これにより、店内のテーブルごとに注文端末や通信設備を設けることなく注文情報を受付けることができ、また、顧客に適した注文候補料理情報を提供することができる。
【０００９】
本発明に係わるオーダリングシステムは、さらに、店舗の厨房内または厨房近傍に設置され、携帯端末及び／又は管理サーバから送信された注文情報を受信し、受信した注文情報を表示する厨房端末を備えたことを特徴とする。
【００１０】
本発明では、厨房端末に注文情報を表示することによって迅速かつ正確に注文を通知することができる。
【００１１】
本発明に係わるオーダリングシステムの管理サーバは、さらに、店舗名・支店名、住所等の位置情報を含む店舗情報の保存されている店舗ＤＢと、ＧＰＳ機能を有する携帯端末から送られてくる位置情報を受信することによって店舗ＤＢにアクセスして、受信した位置情報と一致する住所の店舗が存在するか否かを判定し、存在する場合はその店舗を現在顧客が利用している店舗として特定する利用店舗特定手段と、を備えたことを特徴とする。
【００１２】
本発明では、顧客の携帯電話のＧＰＳ機能を利用して、顧客の居る店舗を特定する。
好ましくは、顧客の携帯端末から送られてきた位置情報を用いて直ちに店舗を特定するのではなく、ＧＰＳの誤差を加味して予め定めた所定範囲にある店舗を抽出し、所定範囲内に店舗が複数存在する場合は、顧客端末から送られてきた画像データを所定範囲内のそれぞれの店舗のメニューの画像パターンと比較して料理を特定し、画像の類似度が所定値以上の店舗名を優先順位順に携帯端末に表示させ、顧客に一の店舗名の選択を促すようにしても良い。なお、優先順位順とは、画像の類似度の高い順、受信した位置情報に近い順、類似度と位置情報に一定の重みを付けて算出した評価値順などがある。
【００１３】
なお、画像情報ＤＢに、店舗のマークなど店舗識別可能な画像が店舗ＩＤと関連付けられて保存しておき、さらに、管理サーバには、携帯端末から送られてくる店舗ごとに備え付けられた店舗識別可能な画像の撮像画像を受信し、当該受信した画像が画像情報ＤＢに保存されている店舗識別可能な画像と合致するか否かを判定することによって現在顧客が利用している店舗を特定する利用店舗特定手段を備えるようにすれば、ＧＰＳ機能を持たない携帯端末でも顧客の利用している店舗を特定することができる。
【００１４】
また、画像情報ＤＢに店舗内のテーブルまたは座席を識別可能な画像を保存しておき、  さらに、前記利用店舗特定手段は、携帯端末から送られてくるテーブルごとに備え付けられたテーブルまたは座席を識別可能な画像の撮像画像を受信し、当該受信した画像が画像情報ＤＢに保存されているテーブルまたは座席を識別可能な画像と合致するか否かを判定することによって現在顧客が利用しているテーブルまたは座席を特定するようにすれば、注文情報の処理と連動させることによって、より利便性の高いサービスが可能となる。
【００１５】
本発明に係わるオーダリングシステムの会員ＤＢは、さらに、顧客の一回の利用上限金額を保存するようにして、管理サーバは、注文候補料理を含めた合計金額と、会員ＤＢに記録される利用上限金額とを比較し、合計金額が利用上限金額を上回るか否か判定する上限金額超過判定手段を備えたことを特徴とする。
さらに、利用上限金額を予め設定しておいて、合計金額が利用上限金額を上回らない場合は、クレジット会社サーバへ合計金額その他の必要な情報を通知することによって決済代行処理を実行することによって、適正なクレジットの利用が可能になる。
【００１６】
また、本発明に係わるオーダリングシステムは、さらに、携帯端末にアラーム機能を設け、管理サーバには、来店者に提供するメニュー情報として品名・価格・アレルギー等の情報が記録されるメニューＤＢを設け、顧客の携帯端末から注文情報を受信したときに、当該メニューＤＢにアクセスして、注文候補料理に含まれる材料で、摂取する者によってはアレルギー反応を起こす可能性のある材料を特定するアレルギー材料特定手段と、特定したアレルギー材料と一致する材料が会員ＤＢの当該顧客の属性情報に記録されている場合、注文候補料理がアレルギー品目に該当すると判定し、携帯端末のアラーム機能を起動するよう制御するアラーム起動制御手段と、を備えたことを特徴とする。
【００１７】
本発明では、顧客が送信した画像データをもとに料理特定手段によって特定した注文候補料理に予め登録された顧客のアレルギー材料が含まれている場合は、顧客の携帯端末を介してアラーム出力をすることにより注意を喚起する。なお、アラーム機能としては、注意メッセージの出力、特定音や振動の発生などがある。
【００１８】
好ましくは、推薦料理判定手段によって抽出された注文候補料理として推薦すべき料理についても当該顧客のアレルギー材料が存在するか否かを判定し、アレルギー材料が含まれている場合は、その料理は注文候補料理から除外するのが良い。
【００１９】
本発明に係わるオーダリングシステムは、さらに、管理サーバから送られてくる顧客の注文した料理の金額情報を受信し、受信した金額情報を顧客に提示するレジ端末を備え、管理サーバは、携帯端末から送られてくる割勘会計を行う会員Ｎｏ．、および各会員の費用負担割合を含む割勘に関する所定情報を受信して、レジ端末に各会員の費用負担割合に応じた会計金額を表示させることを特徴とする。
【００２０】
本発明では、割勘の指示を会員の携帯端末を通して行うことによって、会計時での処理の迅速化を図る。
【００２１】
なお、管理サーバの割勘処理としては、割勘に関する所定情報を受信したときに、割勘会計を行うすべての会員の携帯端末から同じ料理の画像データを受信したか否かを判定し、同じ料理の画像データを受信した場合は該料理の金額を費用負担割合に基づいて按分して会員ごとの会計金額を演算し、レジ端末に演算した会員ごとの会計金額を表示させるようにしても良い。
【００２２】
画像データによる注文と連動させて、同じ料理の画像データについては該料理の金額を按分することによって、簡便に割勘処理を行うことができる。
【００２３】
なお、割勘の比率の指定は、上記のように割勘対象の会員のひとりが代表して管理サーバへ送信するようにしても良いが、割勘会計を行うすべての会員の携帯端末から、同じ料理でかつ予め割り勘比率で分割された画像データが受信され、一つの同じ料理として完成（合計金額が一致）した場合、レジ端末に、各会員の費用負担に応じた会計金額を表示させるようにしても良い。
【００２４】
また、本発明に係わるオーダリングシステムは、注文された料理、該料理を注文した会員の識別情報、注文を受けてからの経過時間、および該料理の提供を完了したことを示す料理提供完了フラグを関連付けて保存する調理状況管理テーブルと、顧客の携帯端末から送られてくる注文情報を受信したときに、該注文情報に係る料理を調理状況管理テーブルに登録すると共に、経過時間のカウントを開始し、該料理の提供完了の入力を検知して経過時間のカウントを停止すると共に料理提供完了フラグをセットし、少なくとも未提供の料理について該料理の経過時間または注文受信時刻と共に厨房端末へ表示出力する調理状況管理手段とを備えたことを特徴とする。
【００２５】
本発明では、注文を受けた料理ごとに経過時間をカウントする調理状況管理テーブルを用いて、未提供の料理を厨房端末へ表示することによって、注文された料理を間違えなく効率的に顧客へ提供することが可能となる。好ましくは、料理ごとに予め設定されたその料理の所要時間を閾値として、経過時間が閾値を超過した料理については識別表示するようにすると良い。また、同じ料理種別ごとにソーティングして表示することによって、注文された料理を効率的にまとめて調理することも可能となる。このとき、トッピングなど調理後の顧客ごとのオプションを区別して記憶することによって、同じ料理種別でも顧客の嗜好に合わせた調理が可能となる。
【００２６】
また、本発明に係わるオーダリングシステムは、さらに、料理特定手段によって注文候補料理が特定された際に、調理状況管理テーブルの経過時間に基づいて料理ごとの待ち時間を演算する待ち時間演算手段と、顧客の携帯端末から注文候補情報を受信したとき、待ち時間演算手段によって演算された待ち時間を携帯端末へ送信する提供状況送信手段と、を備えたことを特徴とする。
【００２７】
本発明では、調理状況管理テーブルの経過時間を利用して顧客が料理を注文しようとしたときに、その時点での当該料理の推定所要時間を顧客へ通知する。これによって、顧客は料理が提供されるまでの時間を予め知ることができるので、店舗とのトラブルを未然に回避することができる。
【発明の効果】
【００２８】
本発明によれば、顧客が携行する携帯端末を利用して、料理の注文受付から会計処理に至る一連の作業を行うことが可能になる。このため、従来のＯＥＳにて要していたシステム導入時の費用負担を軽減することができる。また、顧客の属性情報をもとに推奨すべき料理を選定して顧客の携帯端末へ通知するので、より有効な料理情報を提供することができ、注文時の効率化とサービスの向上を図ることができる。
【００２９】
さらに、アレルギー材料が含有されているか否かを顧客ごとに判定して含有されている場合には通知をするので、店員に都度確認するという煩雑さを回避でき、店員の負担も軽減することができる。
【図面の簡単な説明】
【００３０】
【図１】本発明の第１の実施の形態によるオーダリングシステムの全体構成図である。
【図２】図１のオーダリングシステムの処理手順を示すフローチャートである。
【図３】図１の会員ＤＢ４１のデータ構成図である。
【図４】図１の店舗ＤＢ４６のデータ構成図である。
【図５】図１の注文履歴ＤＢ４３と会計履歴ＤＢ４４の関係を表す説明図であり、図５（ａ）は、注文履歴ＤＢ４３、図５（ｂ）は、会計履歴ＤＢ４４である。
【図６】図１の管理サーバ１０の会計処理の手順を示すフローチャートである。
【図７】図１のメニューＤＢ４５のデータ構成図である。
【図８】図２の他の実施例による処理手順を示すフローチャートである。
【図９】図２のさらに他の実施例による処理手順を示すフローチャートである。
【図１０】図２のさらに他の実施例による処理手順を示すフローチャートである。
【図１１】図２のさらに他の実施例による処理手順を示すフローチャートである。
【図１２】本発明の第２の実施の形態によるオーダリングシステムの全体構成図である。
【図１３】図１２の推薦料理判定手段２５の処理手順を示すフローチャートである。
【図１４】図１２の調理状況管理手段３１の調理情報記録ルーチンの処理手順を示すフローチャートである。
【図１５】図１２の調理状況管理手段３１の料理提供完了処理ルーチンの処理手順を示すフローチャートである。
【図１６】図１２の調理状況管理テーブル４７のデータ構成図である。
【図１７】図１２の待ち時間演算手段３２の平均待ち時間演算ルーチンの処理手順を示すフローチャートである。
【図１８】図１２の待ち時間演算手段３２の料理ごとの待ち時間演算ルーチンの処理手順を示すフローチャートである。
【図１９】図１２の待ち時間演算手段３２の待ち時間通知ルーチンの処理手順を示すフローチャートである。
【図２０】図１２の待ち時間管理テーブル４８のデータ構成図である。
【図２１】図１２の会員ＤＢ４１のデータ構成図である。
【図２２】本発明の第３の実施の形態によるオーダリングシステムの全体構成図である。
【図２３】図２２の分割メニュー管理テーブル４９のデータ構成図である。
【図２４】本発明の第３の実施の形態による分割注文処理の手順を示すフローチャートである。
【図２５】図２２の分割注文管理テーブル５０のデータ構成図である。
【図２６】図２４の他の実施例による分割注文処理の手順を示すフローチャートである。
【図２７】図２５の他の実施例による分割注文管理テーブル５０のデータ構成図である。
【発明を実施するための最良の形態】
【００３１】
以下、本発明の実施の形態を説明する。図１は、本発明の第１の実施の形態によるオーダリングシステムの全体構成図である。この図において、オーダリングシステム１は、料理の注文情報を受け付け、種々の制御処理を実行する管理サーバ１０、料理に関する情報を提供するウェブサーバ１２、厨房に設置される端末装置である厨房端末１３、レジ端末１４で構成され、通信回線５を介して顧客の携帯端末２と接続している。また、通信回線５を介して、決済処理を実行するクレジット会社のサーバ１５と繋がっている。顧客は携帯端末２によってウェブサーバ１２に接続し、ウェブサーバ１２を経由して管理サーバ１０とデータ授受を行って料理の注文や種々の情報の提供を受ける。
【００３２】
管理サーバ１０は、ウェブサーバ１２との間の通信を制御する制御部１１、ＣＰＵを有し種々の演算処理を実行する演算処理部２０、会員情報を記録する会員ＤＢ４１、料理の画像情報を保存する画像情報ＤＢ４２、顧客の注文履歴を保存する注文履歴ＤＢ４３、会計履歴を保存する会計履歴ＤＢ４４、店舗ごとのメニュー情報を保存するメニューＤＢ４５、および、店舗情報を保存する店舗ＤＢ４６を有している。
【００３３】
演算処理部２０は、ウェブサーバ１２を介して携帯端末２から送られてくる情報を受信する情報受信手段２１、携帯端末２に対して情報を送信する情報送信手段２２、管理サーバ１０のＬＡＮを介して各ＤＢ４１〜４６にアクセスして情報の読出し、書き込みを行う情報照会手段２３、携帯端末２から送られてくる料理画像から料理を特定する料理特定手段２４、顧客に対して推薦すべき料理を判定する推薦料理判定手段２５、同一嗜好の会員を抽出する類似会員抽出手段２６、顧客の現在利用している店舗を特定する利用店舗特定手段２７、顧客が予め設定した上限金額に達したか否かを判定する上限金額超過判定手段２８、料理の食材中に顧客の設定したアレルギー材料が含まれているか否かを判定するアレルギー材料特定手段２９、アレルギー材料が含まれている場合には注意メッセージを出力するアラーム起動制御手段３０を有している。各手段２１〜３０はプログラムによって実現可能な機能である。
【００３４】
次に、図２を用いて上記の構成を有するオーダリングシステム１の動作を説明する。
顧客は店舗に入って料理を注文する際、自己の携帯端末２のアプリケーションプログラムを起動して（Ｓ１０１ａ）、オーダリングシステム１の管理サーバ１０と接続して、ＩＤ、パスワードを入力する（Ｓ１０２ａ）。
【００３５】
管理サーバ１０は、情報受信手段２１によって携帯端末２から送られてきたＩＤ、パスワードを受信すると（Ｓ１０３ｂ）、情報照会手段２３によって会員ＤＢ４１にアクセスして（Ｓ１０４ｂ）、会員ＤＢ４１に保存されている会員ＩＤ、パスワード情報によって顧客の認証を行う（Ｓ１０５ｂ）。
【００３６】
図３は、会員ＤＢ４１のデータ構成図である。会員ごとに、顧客の会員ＩＤ、パスワード、氏名、性別等の会員特定情報、クレジットカード番号や有効期限、一回の食費の利用上限金額、アレルギー材料などの設定情報が関連付けられて保存されている。
【００３７】
ステップＳ１０５の認証処理によって、ログインを許可するか否かを判定して、ログインを許可しない場合は（Ｓ１０６ｂで「ＮＯ」）、ステップＳ１０２ａに戻ってＩＤ、パスワードの再入力を促す。一方、ステップＳ１０６ｂで「ＹＥＳ」の場合は、携帯端末２へアプリケーションへのログイン許可指令を送信する。
【００３８】
なお、ステップＳ１０６ｂでは、店舗名を確認する為に、アプリケーションプログラムが起動した時点で携帯端末２に搭載されているＧＰＳ機能で位置確認をする。ＧＰＳ機能が使用できない場合は、(1)テーブルに備え付けられている画像を撮影し送信させる。あるいは、(2)メニューの料理を撮影する毎に判定させることによって店舗を特定する。なお、(2)の場合のメニューはテーブルに備え付けるようにする。
【００３９】
管理サーバ１０の利用店舗特定手段は、ＧＰＳ情報が送られてきた場合には、店舗ＤＢ４６に保存されている店舗の位置情報と照合し、ＧＰＳ情報が店舗位置と所定範囲にある店舗を抽出し、その店舗を顧客が現在利用中の店舗として特定する。なお抽出した店舗が複数存在する場合は、最もＧＰＳ情報に近い店舗を利用店舗として特定する。または、所定範囲にある複数の店舗を顧客のＧＰＳ位置に近い順に顧客の携帯端末２に表示して、顧客に特定するよう入力を促し、特定された店舗を現在利用中の店舗であるとしても良い。
【００４０】
図４は、店舗ＤＢ４６のデータ構成図である。店舗ごとに、店舗ＩＤ、店舗名、支店ＩＤ、支店名などの店舗特定情報や、住所や経度、緯度などの位置情報が保存されている。
【００４１】
なお、画像情報ＤＢ４２に、店舗ごとの料理画像のほか、店舗のマークなど店舗を識別可能な画像を店舗ＩＤ等と関連付けて保存しておいて、顧客がテーブルに備え付けられている店舗マークの画像を携帯端末２で撮影し、管理サーバ１０はその撮影画像が送られてきた場合は、画像情報ＤＢ４２に保存されている店舗マーク等の画像と合致するか否かを判定し、合致する画像の店舗を顧客が現在利用中の店舗であるとしても良い。このとき、テーブルごとに各テーブルを識別できる識別情報や画像を備えておいて、その画像等を一緒に送るようにすれば、店舗とテーブルを同時に識別することができる。なお、さらに座席単位に各座席を識別できる画像をテーブルあるいはメニューに表示して、その画像を顧客の携帯端末２で撮影して管理サーバ１０へ送るようにしても良い。
【００４２】
ステップＳ１０６ｂの処理の結果、携帯端末２は管理サーバ１０からログイン許可指令を受信すると、顧客は携帯端末２の備えているカメラ機能で注文を希望する料理を撮影し、この撮影画像をサーバ１０へ送信する（Ｓ１０７ａ）。なお、料理画像の撮影はメニューに表示されている撮影枠を含む写真あるいは、コード等の撮影によって行う。
【００４３】
管理サーバ１０は、携帯端末２から送られてきた画像データを受信すると（Ｓ１０８ｂ）、情報照会手段２３により画像情報ＤＢ４２にアクセスして（Ｓ１０９ｂ）、料理特定手段２４によって受信した画像データと合致する画像情報を検索する。すなわち、画像情報ＤＢ４２に格納されている料理の画像パターンと、受信した画像データとを照合して、合致する画像パターンが存在するか否かを判定し、存在する場合はその画像が顧客が注文候補として撮影した料理の画像であると判定する。
【００４４】
顧客端末２から受信したが画像と画像情報ＤＢ４２に登録されている画像との照合（マッチング）は既存の技術を用いるものとする。たとえば、特表２００５−５０９２１９号公報に記載されているように、形状比較、グレースケール比較、ウェブレット比較、カラーキューブ比較によってマッチングスコアを計算して、最もマッチした画像を抽出するという技術を用いることができる。
【００４５】
ステップＳ１１１ｂで、合致する画像情報が存在しない場合は（Ｓ１１１ｂで「ＮＯ」）、エラー情報を携帯端末２へ送信して、ステップＳ１０７ａへ戻り、注文を希望する料理の撮影を促す。一方、ステップＳ１１１ｂで、合致する画像情報が存在する場合は（Ｓ１１１ｂで「ＹＥＳ」）、会員ＤＢ４１、注文履歴ＤＢ４３にアクセスして（Ｓ１１２ｂ）、顧客に推薦する料理を判定する（Ｓ１１３ｂ）。
【００４６】
図５（ａ）は、注文履歴ＤＢ４３のデータ構成図である。注文した料理ごとに注文ＩＤが採られ、注文日、店舗ＩＤ、メニューＩＤ、価格、その料理を注文した会員のＩＤなどが関連付けられて保存されている。なお、同ＤＢ４３には、後述するが割勘で料理を注文した場合の割勘比率や割勘相手の会員ＩＤが保存できるようになっている。
【００４７】
ステップＳ１１３ｂの具体的な処理としては、まず類似会員抽出手段２６によって会員ＤＢ４１にアクセスして、顧客の属性情報（年齢・性別・住所・顧客の過去の注文情報）と一致・類似する属性の会員を抽出する。さらに、推薦料理判定手段２５によって注文履歴ＤＢ４３にアクセスして、抽出した会員の中で、過去に顧客の撮影した料理を注文した会員の注文履歴情報を参照し、その注文時で他に注文した料理を、顧客に推薦する料理とする。なお、顧客が過去に同じ料理を注文していた場合には、その注文時で他に注文した料理も併せて推薦するようにしても良い。
【００４８】
推薦料理判定手段２５は上記の処理によって顧客に推薦する料理を判定すると、情報送信手段２２により顧客が撮影した料理の画像情報および推薦する料理の画像情報を顧客端末２へ送信する。
【００４９】
顧客端末２では、これらの情報を受信すると、受信した画像情報を携帯端末２上に表示して、注文の確認を促す（Ｓ１１４ａ）。そして、顧客が注文料理の確定操作を行うと注文情報を管理サーバ１０へ送信する（Ｓ１１５ａ）。
【００５０】
管理サーバ１０は、この注文情報を受信すると（Ｓ１１６ｂ）、会員ＤＢ４１、注文履歴ＤＢ４３を更新して（Ｓ１１７ｂ）、注文情報を顧客の居る店舗の厨房端末１３へ送信する（Ｓ１１８ｂ）。
以上の処理によって、厨房端末１３上に注文情報が表示される。
【００５１】
次に、図６を用いて、管理サーバ１０の会計処理について説明する。管理サーバ１０は、注文情報を受信すると（Ｓ６０１ｂ）、メニューＤＢ４５を照会して（Ｓ６０２ｂ）、それぞれ注文した料理の料金を抽出して（Ｓ６０３ｂ）、抽出した料金の合計金額を算出する（Ｓ６０４ｂ）。なお、注文料理の確定処理としては、管理サーバ１０で受信画像から特定したメニューのＩＤやテーブルＩＤ等を保存しておいて、当該携帯端末２から注文情報によって保存しているメニューＩＤ等を厨房端末１３へ送信するようにしても良いし、ステップＳ１１３ｂで、メニューＩＤや品名を携帯端末２へ送信して、ステップＳ１１５ａで携帯端末２からメニューＩＤを確定した注文情報として管理サーバ１０へ送信するようにしても良い。
【００５２】
図７はメニューＤＢ４５のデータ構成図である。顧客に提供する料理ごとにメニューＩＤが付され、料理名（品名）、価格のほか、アレルギー対象品目に該当する材料を使用している場合は、その情報が保存されている。なお、メニューＩＤは、店舗と料理が識別可能になっている。
【００５３】
そして、顧客の携帯端末２へ決済方法の確認表示を行い、顧客がクレジット会社の会員であって、顧客からクレジット決済する旨を受信した場合は、クレジット会社サーバ１５へ金額その他の必要な情報を通知してクレジット会社による決済代行処理を行う（Ｓ６０９ｄ）。一方、ステップＳ６０６ｂで顧客がクレジット会社の会員でない場合、またはステップＳ６０７ｂで顧客の携帯端末２からクレジット決済する旨を受信していない場合は、レジでの会計処理を実行する（Ｓ６０８ｃ）。会計処理が完了すると、会計ＩＤが発行され、その会員ＩＤに対応する注文履歴ＤＢ４３の一または二以上の料理の注文ＩＤと関連付けて、会計金額や支払方法（クレジット、現金等）、日付等が会計履歴ＤＢ４４に保存される。図５（ｂ）は、会計履歴ＤＢ４４のデータ構成例である。この図で、会計ＩＤと注文ＩＤとの関係付も保存されるようになっている。なお、割勘の場合は、注文履歴ＤＢ４３の割勘比率に料理の価格と掛け合わせた金額と、会計履歴ＤＢ４４の会計金額とが一致するか否かを判定し、一致しない場合は、該当する顧客の携帯端末２へその旨を通知するようにしても良い。
【００５４】
＜他の実施例１＞
図８にオーダリングシステム１の他の実施例による動作手順を示す。図中、図２と同じ処理については同一番号を付している。本実施例は、顧客の料理注文時に予め設定した上限金額内かどうかを判定するというものである。
【００５５】
図２の処理との違いは、管理サーバ１０において、推薦料理判定手段２５で顧客に推薦する料理を判定した後（ステップＳ１１３ｂ）、上限金額超過判定手段２８によって料理の合計金額が会員ＤＢ４１で予め指定した金額以内か否かを判定し（Ｓ２０１）、指定金額以内の場合は（Ｓ２０１で「ＹＥＳ」）、顧客の携帯端末２へ顧客の撮影した料理や推薦する料理の画像情報を送信し、指定金額を超えている場合は（Ｓ２０１で「ＮＯ」）、エラー情報を携帯端末２へ送信して、ステップＳ１０７ａへ戻り、注文を希望する料理の撮影を促すようにしたことである。
【００５６】
この上限金額超過判定手段２８は、会員ＤＢ４１に予め一回で利用できる金額が指定されている場合に起動する。この場合の合計金額は顧客が選んだ料理のみに適用するようにしても良い。
【００５７】
＜他の実施例２＞
図９にオーダリングシステム１の他の実施例による動作手順を示す。図中、図２と同じ処理については同一番号を付している。本実施例は、顧客の料理注文時に注文候補料理中にアレルギー材料が含まれているか否かを判定するというものである。
【００５８】
図２の処理との違いは、管理サーバ１０において、料理特定手段２４によって画像情報ＤＢ４２の中に顧客の携帯端末２から送られてきた画像と合致する画像が存在するか否かを判定して（Ｓ１１１ｂ）、合致する画像情報が存在している場合（Ｓ１１１ｂで「ＹＥＳ」）、情報照会手段２３によって会員ＤＢ４１、注文履歴ＤＢ４３にアクセスして（Ｓ１１２ｂ）、アレルギー材料特定手段２９により注文された料理にアレルギー材料が含まれているか否かを判定し（Ｓ３０１ｂ）、含まれていない場合（Ｓ３０１ｂで「ＹＥＳ」）は、ステップＳ１１４ａへ進み、含まれている場合は（Ｓ３０１ｂで「ＮＯ」）、アラーム起動制御手段３０を起動してアレルギー材料が使用されている旨を携帯端末２へ送信して、ステップＳ１０７ａへ戻り、注文を希望する料理の撮影を促すようにしたことである。なお、ステップＳ１０７ａに戻る替わりに、ステップＳ１１４ａでアレルギー材料が含まれている旨を携帯端末２へ表示して注文料理の指定を促し（Ｓ１１５ａ）、顧客が注文料理の指定を取りやめたときにステップＳ１０７ａへ移行して再度注文を希望する料理を撮影するよう促すようにしても良い。
【００５９】
ステップＳ３０１ｂの処理を具体的に説明すると、アレルギー材料特定手段２９は、まず、会員ＤＢ４１にアクセスして、予め設定されている当該会員のアレルギー材料情報を抽出する一方、メニューＤＢ４５にアクセスして、料理特定手段２４で特定した料理、すなわち、携帯端末２から送られてきた画像と合致する画像の料理に使用されているアレルギー材料情報を抽出して、一致する材料が存在するか否かを判定する。一致する材料が存在する場合は、アレルギー材料が含まれていると判定し、一致する材料が含まれていない場合は、当該顧客のアレルギー材料は含まれていないと判定する。また、注文履歴ＤＢ４３にアクセスして、その顧客が過去にその料理を注文したか否かを検索し、注文したことがある場合は、アレルギー材料は含まれていないとしてステップＳ１１４ａへ移行する。
以上の処理によって、その顧客のアレルギー材料を使用している料理は推薦対象から除外する。
【００６０】
＜他の実施例３＞
図１０にオーダリングシステム１の他の実施例による動作手順を示す。図中、図２と同じ処理については同一番号を付している。本実施例は、割勘による料理の注文を効率的に行うものである。
【００６１】
図１０において、携帯端末２側において、ステップＳ１０７ａで注文を希望する料理を撮影した後、直ちに画像データを、管理サーバ１０へ送信するのではなく、会計を割勘するか否かの入力を促し、顧客の入力に基づいて会計を割勘にしない場合は（４０１ａで「ＮＯ」）、撮影した画像データを管理サーバ１０へ送信し、会計を割勘にする場合は（４０１ａで「ＹＥＳ」）、同じ料理の写真に対し割勘を行う相手方の会員ＩＤを入力すると共に（Ｓ４０２ａ）、割勘の割合（％）を入力する（Ｓ４０３ａ）。そして、撮影した料理画像および入力した割勘を行う会員Ｎｏ．と割勘比率を管理サーバ１０へ送信して、管理サーバ１０のステップＳ１０８ｂの処理へ移行する。
【００６２】
また、管理サーバ１０では、料理特定手段２４によって画像情報ＤＢ４２の中に顧客の携帯端末２から送られてきた画像と合致する画像が存在するか否かを判定して（Ｓ１１１ｂ）、合致する画像情報が存在している場合（Ｓ１１１ｂで「ＹＥＳ」）、情報照会手段２３によって会員ＤＢ４１にアクセスして（Ｓ１１２ｂ）、割勘をする会員Ｎｏ．が全員一致するか否かを判定し（Ｓ４０４ｂ）一致する場合は、次に、割勘をする料理の合計金額が注文候補の料理の金額と一致するか否かを判定する（Ｓ４０５ｂ）。その結果、両者が一致する場合はステップＳ１１４ａへ移行して、注文確認表示を行う。以降の処理は図２と同様である。
【００６３】
一方、ステップＳ４０４ｂで割勘をする会員Ｎｏ．が一致しない場合は、その旨を携帯端末２へ表示すると共にステップＳ４０２ａへ戻って割勘を行う会員Ｎｏ．の入力を促す。
また、ステップＳ４０５ｂで割勘をする料理の合計金額と一致しない場合は、その旨を携帯端末２へ表示すると共にステップＳ４０３ａへ戻って割勘の割合の入力を促す。
以上の処理手順によって、顧客は携帯端末２から割勘の指示を入力することができる。
【００６４】
＜他の実施例４＞
さらに図１０の割勘による注文の手順の他の実施例を図１１を用いて説明する。図１１は、図１０に示した手順のうち、ステップＳ１０７ａ、Ｓ４０１ａ〜Ｓ４０３ａをステップＳ５０１ａ、Ｓ５０２ａに置き換えたものである。
【００６５】
図１１において、ステップＳ１０６ｂでログイン許可された場合、顧客は勘定の割勘を希望する場合、予め割勘にされている料理画像を撮影して（Ｓ５０１ａ）、割勘を行う相手方の会員Ｎｏ．を入力し、撮影した画像データと会員Ｎｏ．を管理サーバ１０へ送信する。管理サーバ１０は、これらのデータを受信するとステップＳ１０８ｂ移行の処理手順を実行する。
【００６６】
なお、本実施例および上記の他の実施例３の割勘処理において、割勘にする料理の画像および割勘を行う会員Ｎｏ．をすべて代表の会員の携帯端末２から送信するようにしても良いし、それぞれの会員の携帯端末２からログインして、夫々自分の割勘比率あるいは割勘料理画像を送信するようにしても良い。前者の場合は、管理サーバ１０は、ステップＳ４０５ｂの後、承認確認メールを割勘を行う他の会員の携帯端末２へ送信して各会員の携帯端末２からの承認入力を受信した時点で注文成立にするのが誤解による間違った注文を排除できて好ましい。
【００６７】
また、ステップＳ１１４において、割勘分の画像、すなわち、一つの料理画像が割勘比率で分割された画像を携帯端末２上へ表示するようにすれば、視認性が向上し注文ミスの発生の可能性を低減させることができる。
【００６８】
上記各実施例で述べた手順は、それぞれ組み合わせて実現することもできる。たとえば、図１０に示す割勘の処理手順のステップ４０５ｂの処理に続いて、図８のステップＳ２０１ｂの利用上限金額の判定を行うようにしても良い。
【００６９】
以上、本実施の形態によれば、顧客が携行する携帯端末のカメラ機能やＧＰＳ機能を利用して、料理の注文受付から会計処理に至る一連の作業を行うことが可能になる。また、顧客の属性情報をもとに推奨すべき料理を選定して顧客の携帯端末へ通知するので、有効な料理情報を提供することができ、顧客にとっても料理選択の負担を軽減することができる。
【００７０】
さらに、アレルギー材料が含有されているか否かを顧客ごとに判定して含有されている場合には通知をするので、店員に都度確認するという煩雑さを回避でき、店員の負担も軽減することができる。また、携帯端末から割勘の指示を可能にすることによって利便性が向上する。
【００７１】
次に本発明の第２の実施の形態を説明する。図１２は、本実施の形態によるオーダリングシステム１の全体構成図である。第１の実施の形態との主な違いは、調理の状況を管理する調理状況管理手段３１、料理の待ち時間を演算する待ち時間演算手段３２、および注文した料理が既に提供されたか否か等の情報を顧客の携帯端末へ送信する提供状況送信手段３３を追加し、また推薦料理判定手段２５の処理手順を以下の如く変更したことである。
【００７２】
以下、本実施の形態のオーダリングシステム１の動作を第１の実施の形態との違いを中心に説明する。
【００７３】
＜推薦料理判定処理＞
まず、図１３を用いて、本実施の形態による推薦料理判定手段２５の動作を説明する。  推薦料理判定手段２５は、料理特定手段２４によって起動されると、図２１に例示する会計履歴ＤＢ４４にアクセスして（Ｓ７０１）、この会計履歴ＤＢ４４に保存されているデータに対して全ての会計ＩＤについて以下の処理を繰り返す（Ｓ７０２ａ、Ｓ７０２ｂ）。まず、その会計ＩＤの最初の注文ＩＤにアクセスして（Ｓ７０３）、料理特定手段２４で特定された注文候補の料理ＩＤと一致するか否かを判定し（Ｓ７０４）、一致する場合は、同一会計ＩＤで他の料理ＩＤが存在するか否かを判定する（Ｓ７０５）。他の料理ＩＤが存在する場合は、メニューＤＢ４５を参照して当該他の料理ＩＤの料理中に会員ＤＢ４１に保存されているその会員のアレルギー材料が存在するか否かを判定し（Ｓ７０６）、存在しない場合は（Ｓ７０６で「ＮＯ」）、次にその会計ＩＤの会員の性別が同じか否か、その会計ＩＤの年齢とは所定範囲内にあるか、その会計ＩＤの会員の体型（サイズ区分等）はログインしている顧客の体型と同じか否か、そのほか必要により、体重の増減方向はログインしている顧客の希望方向と同じか否か等をそれぞれ判定し（Ｓ７０７、Ｓ７０９、Ｓ７１１、Ｓ７１３）、各判定処理ごとにＹＥＳの場合は、ステップＳ７０５で抽出した他の料理ＩＤに対してそれぞれ所定のポイント値（たとえば各条件について１ポイント）を加算する（Ｓ７０８、Ｓ７１０、Ｓ７１２、Ｓ７１４）。
【００７４】
そして、全ての注文ＩＤについて実施済みか否かを判定し（Ｓ７１４）、ＮＯの場合は、次の注文ＩＤにアクセスして（Ｓ７１６）、ステップＳ７０４以降の処理を繰り返す。
【００７５】
なお、ステップＳ７０４、ステップＳ７０５でＮＯの場合、ステップＳ７０６でＹＥＳの場合は、ステップＳ７１５へ移行する。
【００７６】
一方、ステップＳ７１５で全ての注文ＩＤについて実施済みの場合は（Ｓ７１５で「ＹＥＳ」）、次の会計ＩＤについて、ステップＳ７０３〜Ｓ７１６の処理を実行し、全ての会計ＩＤについて終了すると、料理ＩＤをポイント順にソートして、その料理ＩＤの料理情報（画像を含む）を推奨メニューとして顧客の携帯端末２へ表示する。
【００７７】
なお、上記の処理において、会計ＩＤが増えると計算機の負荷が大きくなる。このため、ステップＳ７０２ａ、Ｓ７０２ｂで、たとえば１ヶ月以内など所定期間内の会計ＩＤを抽出して、ループ処理を行うようにしても良い。あるいは計算機の負荷に応じて抽出する会計ＩＤの数を変更することによって負荷調整をするようにしても良い。
【００７８】
＜調理状況管理処理＞
調理状況管理手段３１は、店舗ごとの調理状況管理テーブルに調理情報を登録する調理情報記録ルーチンと、料理の提供完了を入力する料理提供完了処理ルーチンを有している。以下、図１４を用いて各ルーチンの処理手順の説明をする。
【００７９】
（調理情報記録ルーチン）
調理情報記録ルーチンは、周期的に起動されると、店舗およびテーブル（卓）の特定があったか否かを判定し（Ｓ８０１）、特定がなされた場合は、情報照会手段２３を介して当該店舗ＩＤの調理状況管理テーブル４７にアクセスする（Ｓ８０２）。その後、注文情報の受信があった場合は、注文に係るメニューＩＤ等を抽出して、調理状況管理テーブル４７に新たな調理番号を発行し、メニューＩＤ、品名、テーブルＩＤ、料理のトッピング等のオプション等を登録する。また、注文時刻として、現在時刻を登録する。そして、経過時間のカウントを開始して終了する。図１６に、この調理状況管理テーブル４７のデータ構成例を示す。
【００８０】
一方、ステップＳ８０３で注文情報の受信がない場合は、タイムアウトか否かを判定して、タイムアウトでない場合はステップＳ８０３に戻り、タイムアウトの場合はログインしている顧客の携帯端末２へタイムアウト通知を送信する（Ｓ８０８）。
【００８１】
（料理提供完了処理ルーチン）
料理提供完了処理ルーチンは、厨房端末１３から料理の提供が完了したことを示す料理提供完了の入力の有無を検出して（Ｓ９０１）、料理提供完了の入力が有ったときは（Ｓ９０１で「ＹＥＳ」）、調理状況管理テーブル４７にアクセスして、提供を完了した料理に対応する調理番号を抽出して（Ｓ９０２）、その調理番号の経過時間のカウントを停止すると共に（Ｓ９０３）、料理提供完了フラグをセットする（Ｓ９０４）。
【００８２】
調理状況管理手段３１は、以上の処理によって随時更新される調理状況管理テーブル４７の内容のうち、メニュー名、テーブルＩＤ、オプション指定、注文時刻などの所定の情報を厨房端末１３へ表示出力し、料理提供完了フラグのセットを検知して表示対象から除外する。これによって厨房では、未提供の料理や注文を受けた時刻あるいは注文受け後の経過時間を正確に把握でき、注文された料理を間違えなく効率的に顧客へ提供することができる。
【００８３】
＜待ち時間演算処理＞
待ち時間演算手段３２は、平均待ち時間演算ルーチン、料理ごとの待ち時間演算ルーチン、および、待ち時間通知ルーチンの３つのルーチンで構成されている。
【００８４】
以下、各ルーチンの処理手順について図１７〜図１９を用いて説明する。
（平均待ち時間演算ルーチン）
平均待ち時間演算ルーチは、１分周期など周期的に起動され、まず待ち時間管理テーブル４８に保存されている調理番号を抽出する（ＳＡ０１）。この調理番号としては、前回起動時に処理を行った最終の調理番号がセットされ、初期値は０である。待ち時間管理テーブル４８のデータ構成例を図２０に示す。
【００８５】
そして、調理状況管理テーブル４７にアクセスして（ＳＡ０２）、抽出した調理番号から新たに完了フラグのセットされた料理の待ち時間を抽出し、抽出した待ち時間の平均値を演算する（ＳＡ０３）。そして、この演算結果を待ち時間管理テーブル４８の現在時刻の欄にセットする（ＳＡ０４）。また、抽出した完了フラグのセットされた最後の調理番号を待ち時間管理テーブル４８に記録して（ＳＡ０５）、終了する。
【００８６】
（料理ごとの待ち時間演算ルーチン）
料理ごとの待ち時間演算ルーチンは、調理状況管理テーブル４７の料理提供完了フラグのセットによって起動するとまず、その料理の経過時間を待ち時間管理テーブル４８の待ち時間欄にセットする（ＳＢ０１）。また現在時刻を料理提供完了時刻欄に上書き保存する（ＳＢ０２）。
【００８７】
（待ち時間通知ルーチン）
待ち時間通知ルーチンは、料理特定手段２４の注文候補の演算完了（たとえば図２のステップＳ１１ｂおよびステップＳ１１３ｂ）によって起動されると、まず、その注文候補を抽出し（ＳＣ０１）、下記の式（１）によって推定待ち時間を計算する（ＳＣ０２）。そして、この計算した推定待ち時間を顧客の携帯端末２へ送信する（ＳＣ０３）。
【００８８】
その注文候補料理の推定待ち時間
＝現在の平均待ち時間−その料理の最新料理提供完了時刻での平均待ち時間
＋その料理の最新料理提供完了時刻での待ち時間                ・・・（１）
【００８９】
すなわち、平均待ち時間演算ルーチンによって、時刻ごとの平均待ち時間を演算して待ち時間管理テーブルに保存する一方、料理ごとの待ち時間演算ルーチンによって、料理ごとにその料理を提供した最新時刻とそのときの実際に要した待ち時間とを待ち時間管理テーブルに随時保存しておく。そして、顧客から注文候補の受信があったときに、この待ち時間管理テーブル４８を用いて、式（１）によって推定待ち時間を計算して、顧客の携帯端末へ送信するので、精度の良い待ち時間を応答性良く通知することができる。
【００９０】
なお、料理ごとの待ち時間と平均待ち時間との関係を補正係数として求め、これを用いて推定待ち時間を計算するようにしても良い。
【００９１】
＜注文・提供料理確認処理＞
管理サーバ１０の提供状況送信手段３３は、顧客の携帯端末２から料理の提供状況の送信要求があると、その顧客の居る店舗の調理状況管理テーブル４７にアクセスして、その顧客の会員ＩＤを検索し、その会員ＩＤのメニューＩＤとそれに対応する料理提供完了フラグを抽出して一時バッファに格納する。そして、料理提供完了フラグのセットされているメニューＩＤの品名を提供済みの料理として当該顧客の携帯端末上に表示出力する。
【００９２】
また、料理提供完了フラグのセットされていないメニューＩＤの品名を準備中の料理として当該顧客の携帯端末上に表示出力する。
【００９３】
以上、本実施の形態によれば、第１の実施の形態の効果に加えて、料理画像送信時に待ち時間が通知されるので、顧客は待ち時間を考慮して注文するか、しないかの最終決定を行うことができる。また、厨房端末に注文料理や進捗を表示するための調理状況管理テーブルを用いて顧客に注文した料理や提供済みか否かの情報を提供するので、顧客は注文した料理を確認したり、まだ提供されていない料理が注文されているかどうかを容易に確認したりすることができる。
【００９４】
次に本発明の第３の実施の形態を説明する。本実施の形態は、第１の実施の形態の図２、図８、および図９のステップＳ１０７ａの注文処理において、小ピースに分割された料理（小料理）の注文が集まって一つの料理の注文として成立したときに当該注文を有効にするというものである。たとえば、メニューに４分の１のピザの画像（分割画像）があり、同じテーブルの顧客がそれぞれメニュー上の分割画像を撮影して注文要求（以下、仮注文という。）を行う。そして、４回分の仮注文がされると１枚のピザの注文（本注文）として成立させるという機能である。
【００９５】
図２２は、第３の実施の形態によるオーダリングシステム１の機能ブロック図である。図１２との違いは、メニューＤＢ４５に小ピースに分割された料理の情報を管理するための分割メニュー管理テーブル４９を追加し、注文履歴ＤＢ４３に顧客の分割注文を管理するための分割注文管理テーブル５０を追加したことである。
図２３は、分割メニュー管理テーブル４９のデータ構成図である。この分割メニュー管理テーブル４９は、分割メニュー用のメニューＩＤごとに料金分割数を格納し、さらに、それぞれの分割数に応じた画像データへのリンク情報を保存しておく。この分割数に応じた画像データは、画像情報ＤＢ４２に保存する。
【００９６】
以下、図２４を用いて、この分割注文の処理手順を説明する。なお、その他の機能は、第１または第２の実施の形態と同様なので説明を割愛する。
【００９７】
この分割注文の機能は、図２、図８、および図９のフローチャートのステップＳ１１１ｂとステップＳ１１２ｂの間に図２２に示す手順を挿入することによって実現することができる。
【００９８】
すなわち、ステップＳ１０７ａで分割画像が撮影され、その画像が管理サーバ１０に送られ、管理サーバ１０のステップＳ１１１ｂの処理の結果、受信画像と一致する画像が画像情報ＤＢ４２内に存在する場合は（Ｓ１１１ｂで「Ｙｅｓ」）、合致した画像に関連付けられているメニューＩＤに基づいて分割メニュー注文か否かを判定し（ＳＤ０１）、Ｙｅｓの場合は、次に最初の注文か否かを判定する（ＳＤ０２）。そして、最初の注文の場合は、仮注文ＩＤを発行する（ＳＤ０３）。
【００９９】
図２５は、注文履歴ＤＢ４３に作成される注文管理テーブル５０のデータ構成例である。発行された仮注文ＩＤに関連付けられて、注文日、店舗ＩＤ、必要によりテーブルＩＤ、メニューＩＤが格納されるようになっており、さらに、注文フラグとして、分割注文の数に応じて、それぞれ順番にその注文を行った会員のＩＤが保存されるようになっている。なお、同じ会員から複数の分割注文として例えば小ピースのピザ２枚の注文があった場合は、同じ会員番号が２つ分の注文フラグ欄に格納される。すべての注文フラグ欄に会員番号が保存されると、一つの料理（たとえば１枚のピザ）の注文として判定できるようになっている。
【０１００】
仮注文ＩＤは、本注文ＩＤに対して仮番号を示すコード（図２５の例では「Ｍ」）が付され、本注文ＩＤと区別可能になっている。
【０１０１】
図２４のステップＳＤ０３の処理の後、注文者の携帯端末２に注文フラグ欄の最初の空きフラグ欄に対応する分割画像を表示する（ＳＤ０４）。これにより、注文者は仮注文をする前に何番目の注文者であるか、あと幾つの注文があれば有効になるか等を事前に知ることができる。
【０１０２】
そして、注文者の携帯端末上に表示される仮注文ボタンの選択によって、仮注文が当該注文者の携帯端末２から管理サーバ１０へ送信される。管理サーバ１０では仮注文の受信があると（ＳＤ０５で「Ｙｅｓ」）、分割注文管理テーブル５０のその顧客の会員ＩＤを対応する分割フラグ欄に保存する（ＳＤ０７）。所定時間たっても仮注文の受信がない場合はタイムアウト処理によって（ＳＤ０６）、その旨を注文者の携帯端末へ通知して、ステップＳ１０７ａの処理に戻るようにする。
【０１０３】
ステップＳＤ０７の後は、注文フラグ欄の空きの有無を判定し（ＳＤ０８）、注文フラグ欄に空きが有る場合は、ステップＳ１１２ｂへ移行し、注文フラグ欄に空きが無い場合は、本注文ＩＤを生成して、注文を確定してステップＳ１１２ｂへ移行する。これにより、各注文者は注文が確定する前の仮注文段階でも推奨メニュー情報を取得することができる。なお、注文の確定によって、図５ａに示す注文履歴ＤＢ４３の記録に分割注文管理テーブル５０の情報が加えられる。
【０１０４】
図２６に分割注文処理の他の実施例を示す。図２４との違いは、ステップＳＤ０８で、注文フラグ欄の空きが無い場合は、注文者の携帯端末２から注文確定の入力があったか否かを判定し（ＳＤ１０）、注文確定入力が有った場合は、本注文ＩＤを生成して、注文を確定するというものである（ＳＤ０９）。注文の確定により、図２７に示すように注文管理テーブル５０の注文確定フラグ欄が「確定」となり、厨房端末１３に当該メニューの指示が出力される。これにより、注文者は、分割数に到達する前に注文を確定させて、その料理のオーダに繋げることができる。
【０１０５】
なお、厨房端末１３に対する当該メニューの数量の指示は、各テーブルの分割注文の小ピースの数量を店舗内の全テーブルについて合計し、その合計を分割数で除して、その商または余りが生じた場合はその商に１を加算して当該メニューの数量として指示を出すようにすれば、無駄の少ない効率的な注文数量の管理が可能となる。
【０１０６】
また、各テーブルの小ピースの料金は、注文確定時の小ピースの数に応じて変動させるようにしても良い。例えば、小ピース１枚の注文でピザを１枚分作るときは、小ピース３枚でピザを１枚分作るときに比べて、小ピース１枚あたりの料金を割高に設定しておく。そして、テーブル単位で確定した分割注文に対して、他のテーブルからの分割注文も加えて厨房端末への指示を行い、その結果によって余りが生じなくなったような場合は安くするなど、実際の調理数量によって各テーブル単位で注文した小ピースの料金を修正するようにすれば、顧客に適した量の料理を魅力あるサービスで提供することが可能になる。  
【符号の説明】
【０１０７】
１  オーダリングシステム
２  携帯端末
５  通信回線
１０  管理サーバ
１１  制御部
１２  ウェブサーバ
１３  厨房端末
１４  レジ端末
２１  情報受信手段
２２  情報送信手段
２３  情報照会手段
２４  料理特定手段
２５  推薦料理判定手段
２６  類似会員抽出手段
２７  利用店舗特定手段
２８  上限金額超過判定手段
２９  アレルギー材料特定手段
３０  アラーム起動制御手段
３１  調理状況管理手段
３２  待ち時間演算手段
３３  提供状況送信手段
４１  会員ＤＢ
４２  画像情報ＤＢ
４３  注文履歴ＤＢ
４４  会計履歴ＤＢ
４５  メニューＤＢ
４６  店舗ＤＢ
４７  調理状況管理テーブル
４８  待ち時間管理テーブル
４９  分割メニュー管理テーブル
５０  分割注文管理テーブル
【図２】
2010238118.tif 000003
【図６】
2010238118.tif 000004
【図８】
2010238118.tif 000005
【図９】
2010238118.tif 000006
【図１０】
2010238118.tif 000007
【図１１】
2010238118.tif 000008
【図１３】
2010238118.tif 000009
【図１４】
2010238118.tif 000010
【図１５】
2010238118.tif 000011
【図１６】
2010238118.tif 000012
【図１７】
2010238118.tif 000013
【図１８】
2010238118.tif 000014
【図１９】
2010238118.tif 000015
【図２０】
2010238118.tif 000016
【図２３】
2010238118.tif 000017
【図２４】
2010238118.tif 000018
【図２５】
2010238118.tif 000019
【図２６】
2010238118.tif 000020
【図２７】
2010238118.tif 000021
【図１】
2010238118.tif 000022
【図３】
2010238118.tif 000023
【図４】
2010238118.tif 000024
【図５】
2010238118.tif 000025
【図７】
2010238118.tif 000026
【図１２】
2010238118.tif 000027
【図２１】
2010238118.tif 000028
【図２２】
2010238118.tif 000029