JP2012068749A - 注文管理システム、注文管理方法、注文端末 - Google Patents

Abstract

【課題】複数のテーブルに分かれて着席した場合でも、まとめ役の人が注文内容を把握することができる技術を提供する。
【解決手段】注文管理システムは、記憶部と、表示部とを有する。記憶部は、複数テーブルのうちの、一のテーブルに関する情報と、一のテーブルとは別の、一つまたは複数のテーブルに関する情報とを、一のテーブルに着席した者に関する情報で関連付けて記憶する。表示部は、関連付けられた情報に基づき、別のテーブルで注文される商品に関する情報を、一のテーブルで表示する。
【選択図】図２

Description

本発明は、注文を管理し、注文内容を表示する技術に関する。

大型ショッピングセンターや高速道路の大規模なサービスエリアには、料理を提供する複数の店舗と、これら複数店舗の共有スペースである飲食用スペースとで構成されたフードコートがあり、フードコート内で発生した飲食客の注文やその料金等を管理するシステムがある。

また、飲食客が団体で来店した場合、１つのテーブルでは収まらない場合は複数テーブルに分かれて着席する。

フードコートでは、注文を行う際に飲食客は各店舗まで行き、注文をする必要がある。このとき、混雑時などでは注文をするまで長時間立ち続け、順番が来るまで待たなければならない。

また、子供と大人で構成された団体が、子供と大人とでテーブルが分かれた場合や、幹事がいる団体で複数のテーブルに分かれた場合などでは、まとめ役の人が注文内容を把握したい場合がある。また会計を一つにまとめたい場合がある。

この明細書に記載の技術は、上述した問題点を解決するためになされたものであり、飲食客の着席したテーブルで注文ができ、また団体で来店した飲食客が複数のテーブルに分かれて着席したときでも、他テーブルでの注文内容を把握できる技術を提供することを目的とする。

実施形態の注文管理システムは、記憶部と、表示部とを有する。記憶部は、複数テーブルのうちの、一のテーブルに関する情報と、一のテーブルとは別の、一つまたは複数のテーブルに関する情報とを、一のテーブルに着席した者に関する情報で関連付けて記憶する。表示部は、関連付けられた情報に基づき、別のテーブルで注文される商品に関する情報を、一のテーブルで表示する。

また、実施形態の注文端末は、テーブルごとに備えられ、料理の注文を受付ける注文端末であって、表示部と、受付部とを有する。表示部は、決済担当者の識別情報と、決済担当者が着席しているテーブルの識別情報と、決済担当者が着席しているテーブルとは別のテーブルの識別情報とが関連付けられた情報である関連情報に基づき、自己のテーブルで注文される料理一覧と、自己のテーブルとは別のテーブルで注文される料理一覧とを表示する。受付部は、自己のテーブルに決済権限が付与されている場合、関連情報で関連付けられた別のテーブルで注文された料理につき、決済するかキャンセルするかを受付ける。

実施形態に係る注文管理システムの構成例を示す図である。 実施形態に係る注文管理システムの機能ブロックの一例を示す図である。 実施形態に係る注文管理システムにおける、認証処理のシーケンスの一例を示す図である。 実施形態に係るオーダー端末の認証前後の表示例と、席管理ＤＢ内の認証後のデータ状態の一例を示す図である。 実施形態に係る注文管理システムにおける、他テーブルでの認証時のシーケンスの一例を示す図である。 実施形態に係るオーダー端末の、他テーブルでの認証が完了したときの表示例と、席管理ＤＢ内のデータ状態の一例を示す図である。 実施形態に係る注文管理システムにおける、注文が発生したときの処理シーケンスの一例を示す図である。 実施形態に係るオーダー端末の注文時の表示例と、席管理ＤＢ内のデータ状態の一例を示す図である。 実施形態に係る注文管理システムにおける、他テーブルで注文が発生したときの処理シーケンスの一例を示す図である。 実施形態に係るオーダー端末の、他テーブルで注文が発生したときの表示例と、席管理ＤＢ内のデータ状態の一例を示す図である。 実施形態に係る注文管理システムにおける、調理の進捗情報をオーダー端末まで送信するときの処理シーケンスの一例を示す図である。 実施形態に係るオーダー端末の、注文をした後の表示例を示す図である。 実施形態に係る注文管理システムにおける、退席時の処理シーケンスの一例を示す図である。 実施形態に係るオーダー端末の、退席するときの表示例と、他テーブルで退席した場合の、席管理ＤＢ内のデータ状態の一例を示す図である。 実施形態に係る注文管理システムにおける、テーブルの移動が発生したときの処理シーケンスの一例を示す図である。 実施形態に係るオーダー端末の、他テーブルに移動するときの表示例と、他テーブルに移動するときの、席管理ＤＢ内のデータ状態の一例を示す図である。

以下、本実施形態について図面を参照しつつ説明する。以下の説明において、飲食客は、電子マネーに対応した接触型の磁気カードや、非接触型のＩＣカードを所有しており、このカードを用いて支払いや入金（チャージ）が行われるものとする。尚、同等機能を有する携帯端末が用いられても構わない。

図１は、本実施形態に係る注文管理システムの構成例を示す図である。注文管理システム１００は、中央管理サーバ１、複数のオーダー端末２、複数の調理サーバ３を有し、中央管理サーバ１とオーダー端末２との間、中央管理サーバ１と調理サーバ３との間、およびそれぞれのオーダー端末２の間では、互いに通信可能なネットワーク（有線、無線は問わない）が構築されている。

中央管理サーバ１は、注文管理システム１００の基幹コンピュータである。中央管理サーバ１は、注文がされたときに使用されたカードのＩＤや、テーブルのＩＤ、注文された料理名、調理サーバ３から送信された調理の進捗状況を保持する席管理ＤＢ（Database）１５を有する。

オーダー端末２は、フードコート内の共有スペースのテーブルごとに設置された端末であり、飲食客からの注文を受付け、支払い、入金を行うとともに、調理状況やその他必要な情報を飲食客へ通知する。オーダー端末２は、本実施形態ではタッチパネルやカードリーダライタを有する。

調理サーバ３は、料理を提供する各店舗に設置されたサーバであり、オーダー端末２で注文された料理を調理者が確認するためのコンピュータである。また調理サーバ３は、料理の注文順番や、調理の進捗状況を管理し、進捗状況を中央管理サーバ１に通知する。

図２に、注文管理システム１００の機能ブロックの一例を示す。オーダー端末２は、ＵＩ（User Interface）部２１、カード情報取得／書込み部２２、通信部２３を有する。ＵＩ部２１は、タッチパネルを有し、店舗ごとのメニューを表示し、飲食客が選択した注文料理の名前を取得する。カード情報取得／書込み部２２は、飲食客が所持しているカードに記憶されている会員情報を読み取り、またチャージ金額を更新する接触型または非接触型のカードリーダライタを有する。通信部２３は、中央管理サーバ１、および他のオーダー端末２との間でデータの受け渡しを行う。これらの各ユニットは、ＣＰＵ（Central Processing Unit）２０１、メモリ２０２、および上述の各ハードウェアと、予め導入されているソフトウェアとが協働して実現される。尚、演算処理を行うユニットに関してはＡＳＩＣ（Application Specific Integrated Circuit）での実装でも構わない。

中央管理サーバ１は、オーダー端末２との間や調理サーバ３との間でのデータの受け渡しを行う通信部１１を有する。また、中央管理サーバ１は、オーダー端末２で読み取られた会員情報が有効かを認証する認証部１２を有する。また、席管理ＤＢ１５へのレコードの登録、レコード内のデータの登録、更新を操作するＤＢ操作部１３を有する。これら各ユニットも、ＣＰＵ１０１、メモリ１０２のハードウェア資源と、予め導入されているソフトウェアとが協働することで実現される。

調理サーバ３は、中央管理サーバ１との間でデータの受け渡しを行う通信部３１を有し、また、調理の進捗状況を管理する進捗管理部３２を有する。調理サーバ３内のこれら各ユニットも、ＣＰＵ３０１、メモリ３０２、予め導入されているソフトウェアとが協働することで実現される。尚、演算処理を行うユニットの実装はＡＳＩＣであってもよい。

次に、注文管理システム１００の動作例について説明する。以下の説明では、複数のオーダー端末２が登場し、これらを別端末として説明する必要があるため、オーダー端末２自身、およびオーダー端末２内の各ユニットの符号に、テーブルの符号も付けて説明する。例えばテーブルＡのオーダー端末２、ＵＩ部２１は、オーダー端末２Ａ、ＵＩ部２Ａとなる。

まず、飲食客がテーブル（本例ではテーブルＡ）に着き、認証をするまでの動作を図３に示す。飲食客により、設置されたカードリーダライタ２０Ａにカードがかざされた場合（ＡＣＴ１）、カード情報取得／書込み部２２Ａは、カードから会員情報（カードＩＤ）を取得する。オーダー端末２Ａは、通信部２３Ａを介して取得されたカードＩＤ、およびテーブルＩＤを含む使用要求を中央管理サーバ１へ送信する（ＡＣＴ２）。

中央管理サーバ１の認証部１２は、通信部１１経由でカードＩＤを取得し、かざされたカードが有効かを判定する（ＡＣＴ３）。有効である場合、ＤＢ操作部１３は、当該カードＩＤが席管理ＤＢ１５に既に登録されているかを確認し、未登録の場合、カードＩＤおよびテーブルＩＤをセットとして席管理Ｄ１５に新規登録をする。また、中央管理サーバ１は、使用を許可する旨の情報をオーダー端末２Ａに送信する（ＡＣＴ４）。

このときのオーダー端末２Ａの表示例を図４（Ａ）に示す。オーダー端末２ＡのＵＩ部２１Ａは、まず、ログイン用の画面として、飲食客にカードをかざすように促すメッセージを表示する。カードがかざされ認証が済んだ場合、ＵＩ部２１Ａは注文を促すメッセージと「注文」ボタン、および「退席／席移動」ボタンを表示する。

また、認証が完了したときの席管理ＤＢ１５内のデータ状態を図４（Ｂ）に示す。席管理ＤＢ１５には、飲食客の会員情報を示すカードＩＤ、飲食客の着席テーブルのＩＤ、注文を受付けたときの料理名、注文の調理状況の各データが１つのレコードとして登録される。認証が完了した状態では、ＤＢ操作部１３によってカードＩＤ、テーブルＩＤのデータが登録される。

次に、飲食客が複数のテーブル（本例ではテーブルＡ、Ｃ）に分かれたときの認証処理の動作を、図５を参照しつつ説明する。まず、図３と同様に、テーブルＡについての認証が行われる（ＡＣＴ１１〜ＡＣＴ１４）。その後、飲食客（まとめ役の人）が、テーブルＡで使用したカードと同一のカードをテーブルＣのカードリーダライタ２０Ｃにかざす（ＡＣＴ１５）。このとき、カード情報取得／書込み部２２Ｃは、カードからカードＩＤを取得する。オーダー端末２Ｃは、通信部２３Ｃを用いて取得したカードＩＤ、およびテーブルＩＤを含む使用要求を中央管理サーバ１へ送信する（ＡＣＴ１６）。

中央管理サーバ１の認証部１２は、通信部１１経由でカードＩＤを取得し、かざされたカードが有効かを判定する（ＡＣＴ１７）。有効である場合、ＤＢ操作部１３は、カードＩＤが席管理ＤＢ１５に既に登録されているかを確認する。登録されている場合、ＤＢ操作部１３は、その登録されているレコードにテーブルＣのテーブルＩＤを追加する。

このとき、中央管理サーバ１のＤＢ操作部１３は、いずれのテーブルが注文の管理をするかの管理権限を決定する（ＡＣＴ１７）。この決定方法として、本実施形態では最初に登録されたテーブルが管理権限を有するものと一意に決定し、席管理ＤＢ１５内の別テーブルにこの管理権限の情報を記憶させるものとするが、飲食客に決定させ、その決定情報を取得して管理権限の情報を記憶させる方法でもよい。

中央管理サーバ１は、その後、通信部１１を用いて使用を許可する旨の情報をオーダー端末２Ｃに送信する（ＡＣＴ１８）。このとき、中央管理サーバ１は、管理権限が付与されたテーブルのＩＤ、および、既に登録されている他テーブルのＩＤも送信する。また、管理サーバ１は、席管理ＤＢ１５に同一カードＩＤとして既に登録されているテーブルのオーダー端末２（本例ではオーダー端末２Ａ）に、管理権限が付与されたテーブルＩＤ（本例ではテーブルＡのＩＤ）、および今回新規に登録されたテーブルＩＤ（本例ではテーブルＣのＩＤ）を通知する（ＡＣＴ１９）。

このときのオーダー端末２Ａ、２Ｃでの表示例を図６（Ａ）に示す。ＵＩ部２１Ａ、２１Ｃは、図４（Ａ）で示した表示に加え、いずれが管理権限を有する決済テーブルであり、またいずれが決済テーブルに所属しているテーブルであるかの情報を表示する。

他テーブルでの認証が完了したときの席管理ＤＢ１５内のデータ状態を図６（Ｂ）に示す。席管理ＤＢ１５には、ＤＢ操作部１３によって、同一カードＩＤ内に新たなテーブルＩＤのレコードが追加される。

テーブルが追加するごとに、上記ＡＣＴ１５からＡＣＴ１９が繰り返し実行されることで、３つ、４つ、・・・のテーブルを１つのカードＩＤに関連付けることができる。また、上記以外にも、オーダー端末２ＡのＵＩ部２１Ａ上にフロアマップ等を表示し、手入力でテーブルが選択されることで複数テーブル同士が関連付けられてもよい。

次に、管理権限が付与されたテーブルでの注文時の動作例を図７に示す。尚、複数のテーブルに分けられていない場合、すなわち１つのテーブルに収まった場合の注文時の動作も図７の例と同様である。まず、ＵＩ部２１Ａは、飲食客によって画面上の「注文」ボタン（図４、図６参照）が押下された場合、店舗ごとの一覧メニューを表示する。その後、注文が確定し、カードがカードリーダライタ２０Ａにかざされる。カード情報取得／書込み部２２Ａは、カード内の現在のチャージ料金を更新することで決済を行い（ＡＣＴ２１）、カードＩＤ、テーブルＩＤ、注文料理名を含んだ注文情報が通信部２３Ａを介して中央管理サーバ１に送信される（ＡＣＴ２２）。

中央管理サーバ１は、注文を受付ける（ＡＣＴ２３）。このときの処理について説明する。通信部１１は注文情報を受信し、ＤＢ操作部１３は、注文情報内のカードＩＤ、テーブルＩＤで席管理ＤＢ１５を検索し、該当するレコード内に、注文情報内の注文料理名を登録する。

その後、中央管理サーバ１は、注文ごとにユニークな番号である注文チケット番号を発行し、注文チケット番号と、注文料理名とを含んだ情報を該当店舗の調理サーバ３に送信する（ＡＣＴ２４）。調理サーバ２３は、通信部３１を用いて注文チケット番号、注文料理名を取得し、進捗管理部３２の待ちキューに登録する。

注文時のオーダー端末２Ａの表示例を図８（Ａ）に示す。注文内容が確定した場合、ＵＩ部２１Ａは、確定した注文料理名を一覧表示するとともに、「注文（決済）」ボタンを表示する。「注文（決済）」ボタンが飲食客によって押下された場合、ＵＩ部２１Ａは、カードをかざすように促すメッセージを表示する。

注文処理が完了したときの席管理ＤＢ１５の状態を図８（Ｂ）に示す。ＤＢ操作部１３は、オーダー端末２Ａから送信された注文料理名を、テーブルＩＤと関連付けて席管理ＤＢ１５に新たに登録する。またＤＢ操作部１３は、料理状況の項を初期値（準備中を示す値）に更新する。

次に、管理権限が付与されていないテーブル（本例ではテーブルＣ）から注文を受付けるときの動作を図９に示す。ＵＩ部２１Ｃは、飲食客によって画面上の「注文」ボタン（図６参照）が押下され、飲食客の選択で注文料理が確定した場合、注文料理名、テーブルＩＤを含んだ注文情報がテーブルＡのオーダー端末２Ａに送信される（ＡＣＴ３１）。オーダー端末２ＡのＵＩ部２１Ａは、テーブルＣでの注文内容を表示し、許可して決済するかキャンセルするかを飲食客（まとめ役の人）に判断させる。

このときのＵＩ部２１Ａの表示例を図１０（Ａ）に示す。ＵＩ部２１Ａは、いずれのテーブルがどの料理を注文したかの情報と金額を表示する。このとき、確認のため決済担当者（まとめ役の人）に関する情報も表示する。「注文（決済）」ボタンが押下された場合、ＵＩ部２１Ａは、カードをかざすようにメッセージを表示し、一方、「注文取消」ボタンが押下された場合、注文はキャンセルされる。

注文を許可し、カードリーダライタ２０Ａにカードがかざされた場合、カード情報取得／書込み部２２Ａは、カード内の現在のチャージ料金を更新することで決済を行う（ＡＣＴ３２）。オーダー端末２Ａは、通信部２３Ａを用いてカードＩＤ、テーブルＣのテーブルＩＤ、注文料理名を含んだ注文情報を中央管理サーバ１へ送信する（ＡＣＴ３３）。中央管理サーバ１は、注文情報を取得することで注文を受付ける（ＡＣＴ３４）。

ＡＣＴ３４の動作について説明する。通信部１１は注文情報を取得し、ＤＢ操作部１３は、カードＩＤ、テーブルＩＤで席管理ＤＢ１５を検索する。該当するレコードが検索された場合、ＤＢ操作部１３は当該レコードに注文料理名を登録する。このときの席管理ＤＢ１５内の状態を図１０（Ｂ）に示す。席管理ＤＢ１５には、新たに注文された料理名がテーブルＩＤに関連付けて登録され、さらに、注文状況には初期値（準備中を示す値）が登録される。

その後、中央管理サーバ１は、上述同様に注文チケット番号を発行し、注文チケット番号と、注文料理名とを含んだ情報を、該当店舗の調理サーバ３に送信する（ＡＣＴ３５）。調理サーバ２３は、通信部３１を用いて注文チケット番号、注文料理名を取得し、進捗管理部３２はこれらの情報を組として待ちキューに登録する。

次に、調理状況の更新、通知の動作について図１１を参照しつつ説明する。調理サーバ３の進捗管理部３２は、中央管理サーバ１から送信される注文チケット番号、注文料理名の組を、ＦＩＦＯ（First In First Out）のデータ構造（キュー）で保持している。また、進捗管理部３は、キュー内の最も古い組を「調理中」、その一つ前の組を「調理直前」、その他の組を「準備中」として、区分に分けて調理の進捗を管理している。調理中の料理が出来次第、「調理中」の組は削除され、キュー内が更新される。

調理サーバ３は、注文チケット番号および進捗の区分を組とした進捗情報を、定期的に、またはキューが更新されたときに中央管理サーバ１へ送信する（ＡＣＴ４１）。中央管理サーバ１の通信部１１は、進捗情報を受信し、ＤＢ操作部１３は、進捗情報内の注文チケット番号に基づき、席管理ＤＢ１５内の該当レコードを特定し、該当レコード内の「調理状況」のデータを、進捗情報内の進捗区分の値に更新する（ＡＣＴ４２）。その後、中央管理サーバ１は、通信部１１を用いて管理権限が付与されているテーブルのオーダー端末２（本例ではオーダー端末２Ａ）に、テーブルＩＤ、注文料理名、進捗区分をセットとした進捗情報を送信する（ＡＣＴ４３）。

オーダー端末２Ａの通信部２３Ａは、進捗情報を受信し、ＵＩ部２１Ａ上に表示されている内容（後に図１２を用いて説明する）を更新するとともに、その他のテーブルのオーダー端末２（本例ではオーダー端末２Ｃ）に、受信した進捗情報を転送する（ＡＣＴ４４）。オーダー端末２Ｃも同様に、ＵＩ部２１Ｃ上の表示内容を更新する。

図１２は、注文処理が行われた後のＵＩ部２１の表示例を示す図である。ＵＩ部２１は、テーブルごとに、注文料理名、およびその進捗状況を表示する（図１２（Ａ）参照）。進捗状況の欄は、進捗情報が受信されるごとに更新される。尚、図１２（Ｂ）に示すように、自テーブルの注文と他テーブルの注文とで、背景色を異ならせるように表示してもよい。またＵＩ部２１の表示では、「注文」ボタン、「退席／席移動」ボタンの２つのボタンが用意されている。「注文」ボタンが押下された場合は追加注文となり、図７から図１０にかけて説明したものと同様の処理が行われる。

次に、飲食客が退席するときの動作を図１３に示す。本例では、管理権限が付されていないテーブルＣの飲食客が退席する場合について説明する。

オーダー端末２ＣのＵＩ部２１Ｃで「退席」ボタンが押下された場合（ＡＣＴ５１）、テーブルＩＤと退席する旨の情報とを含む退席情報が中央管理サーバ１へ送信される（ＡＣＴ５２）。この動作について説明する。飲食客によって図１２（または図６）で示された表示上の「退席／席移動」ボタンが押下された場合、ＵＩ部２１Ｃは、次に図１４（Ａ）上段の表示に切り替える。この表示上の「退席」ボタンが押下された場合に退席情報がオーダー端末２Ｃから中央管理サーバ１へ送信される。

中央管理サーバ１の通信部１１は退席情報を受信し、ＤＢ操作部１３は席管理ＤＢ１５に登録されているテーブルＩＤを更新する（ＡＣＴ５３）。このとき、ＤＢ操作部１３は、送信された退席情報内のテーブルＩＤに対応付けられていた注文料理名、調理状況を、管理権限の付されたテーブルＩＤに関連付ける（送信された退席情報内のテーブルＩＤ（テーブルＣ）を、管理権限の付されたテーブルＩＤ（テーブルＡ）に書き換える）。このときの席管理ＤＢ１５のデータ状態を図１４（Ｂ）に示す。

中央管理サーバ１は、席管理ＤＢ１５の更新が終了した場合、ログオフ指示をオーダー端末２Ｃに送信する（ＡＣＴ５４）。ログオフ指示を受信したオーダー端末２Ｃは、図１４（Ａ）下段で示すように表示するとともに、所定の終了処理（初期化処理）を実行する。

尚、本実施形態では、管理権限が付されたテーブルでは、グループ内の他テーブルの退席処理が終了するまでは退席を認めないものとするが、他テーブルに管理権限を移行させる手続きをすることで、退席可能とする実装であってもよい。また、退席したテーブルＩＤの情報は全て管理権限の付されたテーブルＩＤに引き継がせるものとしたが、ＵＩ部２１上で表示される選択画面から手入力で他のテーブルに引き継がせる実装であってもよい。

次に、テーブルの移動時の動作について、図１５を参照しつつ説明する。テーブルが離れている場合において、近くのテーブルが空いたとき等、飲食客は席を移動したい場合がある。本実施形態は、このテーブルの移動も可能である。以下の説明では、初期の段階では飲食客はテーブルＡ、Ｃに着席しており、テーブルＢが空いた場合を例に説明する。

まず、オーダー端末２ＣのＵＩ部２１Ｃで「席移動」ボタンが押下された場合（ＡＣＴ６１）、テーブルＩＤと席を移動する旨の情報とを含む移動情報が中央管理サーバ１へ送信される（ＡＣＴ６２）。この動作について説明する。図１２（または図６）で示された表示上の「退席／席移動」ボタンが飲食客によって押下される。ＵＩ部２１Ｃは、次に図１６（Ａ）の上段の表示に切り替える。このとき、「席移動」ボタンが選択された場合に移動情報がオーダー端末２Ｃから中央管理サーバ１へ送信される。

中央管理サーバ１の通信部１１は、移動情報を受信する。ＤＢ操作部１３は、席管理ＤＢ１５に登録されているテーブルＩＤを更新する（ＡＣＴ６３）。このとき、ＤＢ操作部１３は、移動情報内のテーブルＩＤを席管理ＤＢ１５から削除する。このときの席管理ＤＢ１５のデータ状態を図１６（Ｂ）上段に示す。またこのとき、ＵＩ部２１Ｃ上の表示は図１６（Ａ）下段のものとなる。

次に、飲食客（まとめ役の人）は、ＵＩ部２１Ｃで表示された指示に応じて、移動先であるテーブルＢのカードリーダライタ２０Ｂにカードをかざす（ＡＣＴ６４）。カード情報取得／書込み部２２Ｂは、カードから会員情報（カードＩＤ）を取得する。オーダー端末２Ｂは、通信部２３Ｂを用いて、取得したカードＩＤ、およびテーブルＩＤを含む使用要求を中央管理サーバ１へ送信する（ＡＣＴ６５）。

中央管理サーバ１の認証部１２は、上述と同様に認証を行い、かざされたカードが有効かを判定する。有効である場合、ＤＢ操作部１３は、カードＩＤが席管理ＤＢ１５に既に登録されているかを確認する。ここで、同一のカードＩＤが既に登録されており、且つ、テーブルＩＤが空欄（ＮＵＬＬ）のものがあるため、ＤＢ操作部１３は席の移動であるとみなし、送信されたテーブルＩＤ（Ｂ席）をこの空欄に書き込む（ＡＣＴ６６）。

その後、中央管理サーバ１は、使用許可の情報をオーダー端末２Ｂに送信し（ＡＣＴ６７）、ログオフ指示をオーダー端末２Ｃに送信し（ＡＣＴ６８）、テーブルＣをテーブルＢに変更する旨の表示更新指示をその他のオーダー端末２（本例ではオーダー端末２Ａ）に送信する（ＡＣＴ６９）。オーダー端末２ＡのＵＩ部２１Ａは、表示状態が１２（Ａ）である場合、「Ｃ席」を「Ｂ席」に変更して表示する。以降、Ｃ席として注文されていた表示内容は、Ｂ席に引き継がれる。

上述した本実施形態に対し、ＲＦＩＤ（Radio Frequency Identification）の技術を適用させてもよい。例えば、来店者の個々人にＲＦタグを所持させ、各人の席の移動に応じて、テーブルに対するメニューの紐付けを変更するという実装が考えられる。

本実施形態では、複数店舗と店舗共有の飲食スペースとを有するフードコートを一例として説明したが、態様を限定するものではない。１つの店舗内で本実施形態の注文管理システムが用いられてもよい。

また、オーダー端末、調理サーバはそれぞれ複数あるものとして説明したが、片方が単数、また両方とも単数の構成であってもよい。また、テーブルは、カウンターも含む。本実施形態では、注文の対象を料理としたが、料理以外のどのような商品であっても本実施形態の態様は適用可能である。

以上説明したように、本実施形態では、複数のテーブルに分かれて着席した場合でも、まとめ役の人が注文内容を把握することができる。

本発明は、その精神または主要な特徴から逸脱することなく、他の様々な形で実施することができる。そのため、前述の実施の形態はあらゆる点で単なる例示に過ぎず、限定的に解釈してはならない。本発明の範囲は、特許請求の範囲によって示すものであって、明細書本文には、なんら拘束されない。さらに、特許請求の範囲の均等範囲に属する全ての変形、様々な改良、代替および改質は、すべて本発明の範囲内のものである。

１ 中央管理サーバ、２ オーダー端末、３ 調理サーバ、１１ 通信部、１２ 認証部、１３ ＤＢ操作部、２１ ＵＩ部、２２ カード情報取得／書込み部、２３ 通信部、３１ 通信部、３２ 進捗管理部、１００ 注文管理システム。

Claims (8)

1. 複数テーブルのうちの、一のテーブルに関する情報と、前記一のテーブルとは別の、一つまたは複数のテーブルに関する情報とを、前記一のテーブルに着席した者に関する情報で関連付けて記憶する記憶部と、
   前記関連付けられた情報に基づき、前記別のテーブルで注文される商品に関する情報を、前記一のテーブルで表示する表示部と、
   を有する注文管理システム。
2. さらに、前記複数テーブルごとに備えられ、テーブルに着席した者に関する情報を取得する取得部と、
   前記取得部によって取得された前記テーブルに着席した者に関する情報が有効かを認証する認証部と、を有し、
   前記一のテーブルに備えられた取得部と、前記別のテーブルに備えられた取得部とが、前記一のテーブルに着席した者に関する情報をそれぞれ取得し、前記認証部がそれぞれの認証結果を肯定とした場合、前記一のテーブルに関する情報と前記別のテーブルに関する情報とが、前記一のテーブルに着席した者に関する情報に関連付けられる請求項１に記載の注文管理システム。
3. 前記取得部は、さらに、前記表示部に表示される前記別のテーブルで注文される商品につき、決済するかキャンセルするかを受付ける請求項２に記載の注文管理システム。
4. さらに、前記記憶部に記憶されている関連付けの情報を更新する更新部を有し、
   前記一のテーブルを第１テーブル、前記別のテーブルを第２テーブルとした場合、前記第１、第２テーブルとは別のテーブルである第３テーブルへ前記第２テーブルに着席している者が移動する場合、前記更新部は、前記記憶部の前記第２テーブルに関する情報を前記第３テーブルに関する情報に更新し、
   前記表示部は、さらに、前記第２テーブルで注文される商品に関する情報を前記第３テーブルで注文される商品に関する情報に更新して表示する請求項１乃至３のいずれか１項に記載の注文管理システム。
5. さらに、前記記憶部に記憶されている関連付けの情報を更新する更新部を有し、
   前記記憶部は、さらに、前記テーブルに関する情報と、該テーブルで注文された商品に関する情報を関連付けて記憶し、
   前記別のテーブルに着席している者が退席する場合、前記更新部は、前記別のテーブルに関する情報に関連付けられた商品に関する情報を、前記一のテーブルに関する情報に関連付けるように前記関連付けの情報を更新する請求項１乃至４のいずれか１項に記載の注文管理システム。
6. 前記表示部は、さらに、前記複数テーブルごとに備えられ、関連付けられた他のテーブルが注文した商品に関する情報を表示するとともに、前記表示した商品それぞれの生産状況を表示する請求項１乃至５のいずれか１項に記載の注文管理システム。
7. コンピュータが、
   複数テーブルのうちの、一のテーブルに関する情報と、前記一のテーブルとは別の、一つまたは複数のテーブルに関する情報とを、前記一のテーブルに着席した者に関する情報で関連付けて記憶部に記憶させ、
   前記関連付けられた情報に基づき、前記一のテーブルで前記別のテーブルで注文される商品に関する情報を表示する
   注文管理方法。
8. テーブルごとに備えられ、料理の注文を受付ける注文端末であって、
   決済担当者の識別情報と、前記決済担当者が着席しているテーブルの識別情報と、前記決済担当者が着席しているテーブルとは別のテーブルの識別情報とが関連付けられた情報である関連情報に基づき、自己のテーブルで注文される料理一覧と、自己のテーブルとは別のテーブルで注文される料理一覧とを表示する表示部と、
   自己のテーブルに決済権限が付与されている場合、前記関連情報で関連付けられた別のテーブルで注文された料理につき、決済するかキャンセルするかを受付ける受付部と、
   を有する注文端末。