JP2012079014A - 注文管理システム、注文管理方法、注文管理装置 - Google Patents

Abstract

【課題】料金が支払われた場合でも、注文を受けてから商品を提供するまでに時間を要した場合、返金に応じることができる技術を提供する。
【解決手段】注文管理システムは、商品の注文を、料金の支払いを前払いで受付ける受付け部と、受付け部で注文を受付けた注文時刻を少なくとも含む情報を記憶する記憶部と、商品の生産の進捗状況を管理するとともに、商品の生産が完了した場合、完成時刻を含む情報を送信する進捗管理部と、記憶部に記憶された注文時刻、および、進捗管理部から送信された完成時刻に基づき、商品の注文から生産完了までの実測時間を算出し、実測時間が想定時間よりも大きい場合に返金額を算出する算出部と、返金額を商品の注文者に返金する返金部とを有する。
【選択図】図２

Description

本発明は、注文や発生料金を管理する技術に関する。

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

また、フードコート内が混雑しているとき等、飲食客が注文してから料理が提供されるまでに時間を要する場合がある。

飲食客によって注文された後、料理が提供されるまで時間を要した場合、飲食客から返金を求められる場合がある。しかしながら、従来のシステムでは、一旦決済が確定した後に返金に対応するためには、手動でデータを変更したり、紙面等にこのことを書きとめ、後に清算したりする必要がある。

本発明は上述した問題点を解決するためになされたものであり、返金が発生した場合でも柔軟に対応することができる技術を提供することを目的とする。

上記課題を解決するため、本発明の一態様は、商品の注文を、料金の支払いを前払いで受付ける受付け部と、受付け部で注文を受付けた注文時刻を少なくとも含む情報を記憶する記憶部と、商品の生産の進捗状況を管理するとともに、商品の生産が完了した場合、完成時刻を含む情報を送信する進捗管理部と、記憶部に記憶された注文時刻、および、進捗管理部から送信された完成時刻に基づき、商品の注文から生産完了までの実測時間を算出し、実測時間が想定時間よりも大きい場合に返金額を算出する算出部と、返金額を商品の注文者に返金する返金部とを有する注文管理システムに関する。

また、本発明の一態様は、注文端末と、管理サーバと、進捗管理サーバとを有するシステムが実行する注文管理方法であって、注文端末が、商品の注文を、料金の支払いを前払いで受付け、管理サーバが、注文を受付けた注文時刻を少なくとも含む情報を記憶部に記憶し、進捗管理サーバが、商品の生産の進捗状況を管理するとともに、商品の生産が完了した場合、完成時刻を含む情報を送信し、管理サーバが、記憶部に記憶された注文時刻、および、進捗管理サーバから送信された完成時刻に基づき、商品の注文から生産完了までの実測時間を算出し、実測時間が想定時間よりも大きい場合に返金額を算出し、注文端末が、返金額を商品の注文者に返金する注文管理方法に関する。

また、本発明の一態様は、商品に対する料金の支払いを前払いで受付けた時刻である注文時刻を少なくとも含む情報を記憶する記憶部と、商品の生産が完了したときの完成時刻を含む情報を取得し、記憶部に記憶された注文時刻、および、取得した完成時刻に基づき、商品の注文から生産完了までの実測時間を算出し、実測時間が想定時間よりも大きいかを判定する時間判定部と、時間判定部によって大きいと判定された場合に、返金額を算出する返金額算出部とを有する注文管理装置に関する。

以上に詳述したように、本発明によれば、料金が支払われた場合でも、注文を受けてから商品を提供するまでに時間を要した場合、返金に応じることができる。

実施形態に係る注文管理システムの構成例を示す図である。 実施形態に係る注文管理システムの機能ブロックの一例を示す図である。 実施形態に係る注文管理システムにおける、注文発生時の処理シーケンスの一例を示す図である。 実施形態に係る注文管理システムにおける、調理進捗状況をオーダー端末に表示するときの処理シーケンスの一例を示す図である。 実施形態に係る注文管理システムにおける、時間超過による一部返金が発生するときの処理シーケンスの一例を示す図である。 実施形態に係る注文管理システムにおける、キャンセルが発生した場合の処理シーケンスの一例を示す図である（調理直前、調理中以外）。 実施形態に係る注文管理システムにおける、キャンセルが発生した場合の処理シーケンスの一例を示す図である（調理直前）。 実施形態に係る注文管理システムにおける、キャンセルが発生した場合の処理シーケンスの一例を示す図である（調理中）。 実施形態に係る注文管理システムにおける、キャンセルが発生した場合の処理シーケンスの一例を示す図である（調理中且つ時間超過）。

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

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

中央管理サーバ１は、注文管理システム１００の基幹コンピュータであり、注文された料理名や、その発注時刻、調理サーバ３から送信された調理の進捗状況等を保持する発注料理管理ＤＢ（Database）１５を有し、また、各店舗で扱っている料理に関する基本情報を保持する料理基本情報ＤＢ１６を有する。

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

調理サーバ３は、料理を提供する各店舗に設置されたサーバであり、オーダー端末２で注文された料理を調理者が確認するためのコンピュータである。また調理サーバ３は、料理の注文順番や、調理の進捗状況を調理中、調理直前、それ以外の区分に分けて管理する。

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

中央管理サーバ１は、時間判定部１１、返金額算出部１２、キャンセル判定部１３、ＤＢ操作部１４、発注料理管理ＤＢ１５、料理基本情報ＤＢ１６を有する。これら各ユニットの動作については後に詳説する。これら各ユニットも、ＣＰＵ１０１、メモリ１０２のハードウェア資源と、予め導入されているソフトウェアとが協働することで実現される。

調理サーバ３は、キュー状態通知部３１、キュー操作部３２、調理キュー３３を有する。キュー状態通知部３１は、調理キュー３３のキュー状態を監視し、調理中、またはその１つ前の状態（すなわち、調理直前の状態）のデータを調理キュー３３から取得し、中央管理サーバ１へ送信する。

キュー操作部３２は、中央管理サーバ１から送信された注文情報を調理キュー３３に新規にエントリし、また、調理が完了した料理に対応したデータを調理キュー３３から削除する。調理が完了したときの調理キュー３３からの削除は、本実施形態では、調理者がキュー操作部３２内の所定のボタンを押下した場合に行われるものとする。尚、この実装以外にも、ＲＦＩＤ(Radio Frequency Identification)を用いた方法であってもよい。例えば、食器の底面にＲＦタグを組み込んでおき、リーダが組み込まれた調理用カウンターに、調理者が料理を盛り付ける前に食器を置き、盛り付けが完了した後に、調理者もしくは配膳者が、リーダが組み込まれたカウンター（別のカウンターであってもよい）に当該食器を置くことで、調理キュー３３からデータが削除される実装であってもよい。この実装の場合、キュー操作部３２にはＲＦタグとリーダも含まれる。

調理キュー３３は、注文のデータを順次格納し、ＦＩＦＯ（First In, First Out）方式でデータを扱う。調理サーバ３内のこれら各ユニットも、ＣＰＵ３０１、メモリ３０２、上記各ハードウェアと、予め導入されているソフトウェアとが協働することで実現される。尚、演算処理を行うユニットや調理キュー３３の実装はＡＳＩＣ（Application Specific Integrated Circuit）であってもよい。

次に、注文管理システム１００の動作例について、図３から図９を参照しつつ、ケース分けして説明する。まず、注文発生時の注文管理システム１００の動作ついて、図３を用いて説明する。

オーダー端末２は、飲食客から前払いで注文を受付け、注文情報を中央管理サーバ１へ送信する（ＡＣＴ１）。このとき、端末ＩＤ、会員情報、店舗ＩＤ、料理名、決済金額の情報が送信される。中央管理サーバ１のＤＢ操作部１４は、送信された注文情報を発注料理管理ＤＢ１５に登録する（ＡＣＴ２）。このとき、端末ＩＤ、料理単位の注文チケット番号（中央管理サーバ１がユニークに払い出す）、店舗ＩＤ、会員情報、料理名、発注時刻、調理状態フラグ（初期値）の各データを含んだレコードが発注料理管理ＤＢ１５に登録される。

中央管理サーバ１は、店舗ＩＤを参照して該当する店舗の調理サーバ３へ注文情報を送信する（ＡＣＴ３）。このときに送信されるデータは、注文チケット番号、料理名であり、調理サーバ３のキュー操作部３２は、この注文チケット番号、料理名のセットを調理キュー３３に新規オーダーとして登録する。

次に、調理の進捗状況を飲食客に通知する動作について、図４を用いて説明する。調理サーバ３のキュー状態通知部３１は、調理キュー３３の状態が更新された場合、調理中の料理、または次に調理する料理に関するデータ（注文チケット番号、料理名のセット）を調理キュー３３から取得する。キュー状態通知部３１は、取得した注文チケット番号、料理名のセットに、調理中、または調理直前を意味する値（調理状態フラグ）を付与して中央管理サーバ１へ送信する（ＡＣＴ１１）。中央管理サーバ１のＤＢ操作部１４は、送信された注文チケット番号、料理名に基づき発注料理管理ＤＢ１５内のレコードを検索し、該当するレコードの調理状態フラグの値を、取得した調理状態フラグの値に更新する（ＡＣＴ１２）。ＤＢ操作部１４は、発注料理管理ＤＢ１５内の該当するレコードから端末ＩＤを取得し、対応するオーダー端末２へ店舗ＩＤ、料理名、調理状態フラグを送信する（ＡＣＴ１３）。オーダー端末２のＵＩ部２１は、調理状態フラグに応じた表示をする。ＵＩ部２１は、例えば調理状態フラグが調理中である旨の値である場合は「ただいま調理中です。」と表示し、調理直前である旨の値である場合は「まもなく調理開始します。」と表示する。

次に、時間超過による払戻し金額が発生した場合の動作について、図５を用いて説明するが、ここで料理基本情報ＤＢ１６に登録されているデータや、その扱い方について説明する。

料理基本情報ＤＢ１６には、店舗ＩＤ、料理名、および、その料理を調理するのに必要な時間（基本調理時間）の各データを含んだレコードが予め登録されている。中央管理サーバ１は、オーダー端末２から注文情報を取得する毎に、その注文情報内の店舗ＩＤ、料理名に基づき料理基本情報ＤＢ１６から基本調理時間を取得し、基本調理時間を店舗ＩＤごとに累積加算する（以下、この基本調理時間を累積加算した時間をノルマ時間（想定時間）と称す）。また中央管理サーバ１は、調理サーバ３から調理完了である旨のデータ、すなわち、注文チケット番号、料理名、調理状態フラグ、完成時刻の要素で構成されたデータレコードを取得したときに、該当する店舗ＩＤのノルマ時間に、完成した料理名の基本調理時間を減算させる。このようにしてノルマ時間は注文を受付ける毎に、また調理が完了する毎に更新される。中央管理サーバ１は、注文を受付ける毎に今現在のノルマ時間に注文された料理の基本調理時間を加算し、注文チケット番号と加算後のノルマ時間とを対応付けて、別テーブル上で管理する。

以上を踏まえ、時間超過による払戻し金額が発生した場合の動作について説明する。調理が完了した場合、調理サーバ３のキュー操作部３２は、調理キュー３３内の最も古いデータ（注文チケット番号、料理名のセット）を取得して、調理キュー３３から当該データを削除する。その後、調理サーバ３は、取得した注文チケット番号、料理名に、調理状態フラグ（調理完了である旨の値）、完成時刻を付与し、これらを１つのデータレコードとして中央管理サーバ１へ送信する（ＡＣＴ２１）。

データレコードを取得した中央管理サーバ１は、発注料理管理ＤＢ１５を参照し（ＡＣＴ２２）、払戻しが発生するかを判定し、発生する場合は返金額を算出する（ＡＣＴ２３）。

ＡＣＴ２２、ＡＣＴ２３の処理について説明する。中央管理サーバ１のＤＢ操作部１４は、調理サーバ３から取得したデータレコードに基づき、発注料理管理ＤＢ１５内の該当エントリを検索する。ＤＢ操作部１４は、該当エントリから発注時刻を取得し、また、別テーブル上で管理されているノルマ時間を取得する。時間判定部１１は、調理サーバ３から送信された完成時刻から、取得された発注時刻を減算し、この減算時間（以下、実測時間）とノルマ時間とを比較する。実測時間が明らかにノルマ時間よりも大きい場合（例えば実測時間とノルマ時間との差分が所定閾値を上回った場合）、時間判定部１１は、払戻しが発生すると判定する。

返金額算出部１２は、以下の式を用いて返金額を算出する。返金額の算出方法には様々な手法があるが、本実施形態では以下の式を用いる。
（式１）返金額（円） ＝ （料理の単価／定数Ｋ）×（実測時間／ノルマ時間）
（定数Ｋは、店舗毎に予め定義された定数であり、例えばＫ＝１０）

中央管理サーバ１は、算出した返金額をオーダー端末２へ送信する（ＡＣＴ２４）。返金額を取得したオーダー端末２は、ＵＩ部２１に、例えば「払戻し金額はＸＸ円です。金額をカードに戻します。カードをかざしてください。」と表示することで、飲食客に払戻しが発生することを通知する。ここで、カード情報取得／書込み部２２は、飲食客が所有するカードの金額データを、返金額分増加するように更新し、決済したことを中央管理サーバ１へ通知する（ＡＣＴ２５）。通知を受けた中央管理サーバ１のＤＢ操作部１４は、該当するレコードを発注料理管理ＤＢ１５から削除する（ＡＣＴ２６）。

次に、キャンセルが発生したときの動作について説明する。キャンセルは、基本的に飲食客の都合によって行われるが、今現在調理中の料理がキャンセルされる場合や調理直前にキャンセルされる場合、店舗側の不利益となる。また一方、調理の遅延に起因するキャンセルは、たとえ調理中であろうとも飲食客に配慮をする必要がある。以下、図６から図９を参照しつつ、このような各ケースを考慮した実装例を説明する。

まず、調理中や調理直前以外の注文にキャンセルが発生した場合の動作を、図６を用いて説明する。オーダー端末２は、会員情報、店舗ＩＤ、料理名のデータとともにキャンセル依頼を中央管理サーバ１へ送信する（ＡＣＴ３１）。中央管理サーバ１のＤＢ操作部１４は、発注料理管理ＤＢ１５を参照し、該当レコードの調理状態フラグを取得する（ＡＣＴ３２）。次にキャンセル判定部１３は、取得された調理状態フラグに基づき、キャンセルを受付けるかを判定する。

キャンセル判定部１３の動作について説明する。キャンセル判定部１３は、調理状態フラグが初期値であるか（すなわち、上述のＡＣＴ１２による更新がなされていないか）を判定する。初期値である場合、キャンセル依頼を受けた料理は調理中もしくは調理直前ではないため、キャンセル判定部１３は、キャンセルをそのまま受付けると判定する。

次に中央管理サーバ１は、注文チケット番号、料理名のセットとともに、削除命令を調理サーバ３に送信する（ＡＣＴ３３）。調理サーバ３のキュー操作部３２は、該当するデータを調理キュー３３から削除する。また一方、中央管理サーバ１は、全額返金通知をオーダー端末２へ送信する（ＡＣＴ３４）。オーダー端末２のＵＩ部２１は、例えば「キャンセルされた料理につき、全額返金致します。カードをかざしてください。」と表示する。ここで、飲食客によってカードがかざされた場合、カード情報取得／書込み部２２は、カード内のチャージ金額を返金額分増加するように更新し、決済したことを中央管理サーバ１へ通知する（ＡＣＴ３５）。通知を受けた中央管理サーバ１のＤＢ操作部１４は、該当するレコードを削除する（ＡＣＴ３６）。

次に、調理直前の注文にキャンセルが発生した場合の動作を、図７を用いて説明する。調理直前の場合、食材の用意等の前準備が既に行われている場合もあるため、本実施形態では、キャンセルには応じるが、全額返金せず一部のみ返金することとする。尚、キャンセル依頼（ＡＣＴ４１）、参照処理（ＡＣＴ４２）は、図６と同様の処理であるため、説明を割愛する。

キャンセル判定部１３は、調理状態フラグを確認する。調理状態フラグが調理直前である旨の値である場合、キャンセル判定部１３はキャンセルを受理すると判定し、返金額算出部１２は返金額を算出する（ＡＣＴ４４）。返金額の算出方法は様々あるが、本実施形態では、料理単価に対し所定の割合（例えば半額）を返金するものとする。

中央管理サーバ１は、返金額とともに、一部返金通知をオーダー端末２へ送信する（ＡＣＴ４５）。オーダー端末２のＵＩ部２１は、例えば「キャンセルされた料理につき、一部返金致します。返金金額はＸＸ円です。カードをかざしてください。」と表示する。以降のＡＣＴ４６、ＡＣＴ４７の処理、およびＡＣＴ４３の処理は、図６と同様であるため、説明を割愛する。

次に、調理中の注文にキャンセルが発生した場合の動作を、図８を用いて説明する。調理中の場合、本実施形態では、原則キャンセルには応ないものとする（例外については後ほど説明する）。

上述の図６、図７と同様に、注文管理システム１００は、キャンセル依頼（ＡＣＴ５１）、参照処理（ＡＣＴ５２）の各処理を実行する。キャンセル判定部１３は、調理状態フラグを確認する。調理状態フラグが調理中である旨の値である場合、キャンセル判定部１３は、キャンセル不受理であると判定する。このとき、中央管理サーバ１は、再度調理サーバ３に確認してもよい（ＡＣＴ５３）。

キャンセル判定部１３によってキャンセル不受理と判定された場合、次は時間判定部１１の処理となり、時間超過の有無の判定がなされるが、この動作については後に説明する。中央管理サーバ１は、キャンセル不受理通知をオーダー端末２へ送信する（ＡＣＴ５４）。オーダー端末２のＵＩ部２１は、例えば「ご指定の料理は現在調理中です。申し訳ありませんがキャンセルできません。」と表示する。

本実施形態では、調理中の注文にキャンセルが発生した場合、上述通り原則キャンセルを不受理としているが、調理が遅延している場合については、例外的にキャンセルを受付け、一部返金するものとする。この動作について、図９を参照しつつ説明する。

上述の図６、図７と同様に、注文管理システム１００は、キャンセル依頼（ＡＣＴ６１）、参照処理（ＡＣＴ６２）の各処理を実行する。キャンセル判定部１３は、調理状態フラグを確認することで、キャンセル対象の料理が調理中であると判定する。このとき、中央管理サーバ１は、再度調理サーバ３に確認してもよい。

キャンセル判定部１３によって調理中と判定された場合、時間判定部１１は、時間超過の有無を判定する。時間判定部１１は、ＤＢ操作部１４を介して発注料理管理ＤＢ１５のキャンセル対象のレコードから発注時刻を取得し、現在時刻から発注時刻を減算する。時間判定部１１は、この減算時間と、別テーブルで管理されたノルマ時間とを比較し、減算時間が明らかにノルマ時間よりも大きい場合（例えば減算時間とノルマ時間との差分が所定閾値を上回った場合）、返金が発生すると判定する。返金額算出部１２は、例えば上述の式１を用いたり、また料理単価の一定割合を求めたりすることで、返金額を算出する（ＡＣＴ６４）。

中央管理サーバ１は、特例返金通知をオーダー端末２へ送信する（ＡＣＴ６５）。オーダー端末２のＵＩ部２１は、例えば「キャンセルされた料理につき、一部返金致します。返金金額はＸＸ円です。カードをかざしてください。」と表示する。以降のＡＣＴ６６、ＡＣＴ６７の処理、および調理サーバ３の削除処理（ＡＣＴ６３）は、前述と同様であるため説明を割愛する。

また、衛生上の安全性を考慮する必要があるが、図９で示した例外のほか、同じ料理の注文を別途受けている場合に限り、キャンセルを認めるとする実装も可能である。この場合、上述のキャンセル依頼、参照処理の後に、キャンセル判定部１３は、発注料理管理ＤＢ１５内に、発注時刻がキャンセルを受けた注文のものより後のレコードであり、且つオーダー端末２から送信された店舗ＩＤ、料理名と同じ店舗ＩＤ、料理名のレコードが有るかを、ＤＢ操作部１４を用いて判定する。ここで該当するレコードがある場合は、本実施形態ではキャンセルを認め、全額もしくは一部返金される。

本実施形態では、複数店舗と店舗共有の飲食スペースとを有するフードコートを一例として説明したが、態様を限定するものではない。１つの店舗内で本実施形態の注文管理システムが用いられてもよい。また、料理の注文やその料金を例として説明し、業として料理を提供する分野に特化して説明したが、様々な製造分野にも本実施形態は適用可能である。

また、オーダー端末、調理サーバはそれぞれ複数あるものとして説明したが、片方が単数、また両方とも単数の構成であってもよい。

以上説明したように、本実施形態では、料金が支払われた場合でも、注文を受けてから料理を提供するまでに時間を要した場合、返金に応じることができる。

また、本実施形態では、料金が支払われた後にキャンセルが発生した場合でも、調理の進捗状況に応じた返金をすることができる。

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

１ 中央管理サーバ、２ オーダー端末、３ 調理サーバ、１１ 時間判定部、１２ 返金額算出部、１３ キャンセル判定部、１４ ＤＢ操作部、１５ 発注料理管理ＤＢ、１６ 料理基本情報ＤＢ、２１ ＵＩ部、２２ カード情報取得／書込み部、３１ キュー状態通知部、３２ キュー操作部、３３ 調理キュー、１００ 注文管理システム。

Claims (11)

1. 商品の注文を、料金の支払いを前払いで受付ける受付け部と、
   前記受付け部で注文を受付けた注文時刻を少なくとも含む情報を記憶する記憶部と、
   前記商品の生産の進捗状況を管理するとともに、前記商品の生産が完了した場合、該完成時刻を含む情報を送信する進捗管理部と、
   前記記憶部に記憶された注文時刻、および、前記進捗管理部から送信された完成時刻に基づき、前記商品の注文から生産完了までの実測時間を算出し、該実測時間が想定時間よりも大きい場合に返金額を算出する算出部と、
   前記返金額を前記商品の注文者に返金する返金部と、
   を有する注文管理システム。
2. 請求項１に記載の注文管理システムにおいて、
   前記算出部は、前記実測時間と前記想定時間とに基づき前記返金額を算出する注文管理システム。
3. 請求項１または２に記載の注文管理システムにおいて、
   前記進捗管理部は、前記受付け部で受付けた注文順に商品が生産されるように進捗状況を管理し、
   前記算出部は、前記受付け部で注文を受付けたときに、商品ごとに予め定義された基準時間を想定時間に加算し、完成時刻が含まれた情報が前記進捗管理部から送信されたときに、前記基準時間を想定時間から減算する注文管理システム。
4. 請求項１から３のいずれか１つに記載の注文管理システムにおいて、
   前記受付け部での料金の支払いの決済、および前記返金部での返金の決済は、電子マネー対応のカード、または携帯端末で行われる注文管理システム。
5. 請求項１から４のいずれか１つに記載の注文管理システムにおいて、
   前記商品は、店舗が提供する料理であり、
   前記進捗管理部は、ＲＦタグが組み込まれた食器が、リーダが組み込まれた所定位置に置かれることで、前記商品の生産が完了したことを検知する注文管理システム。
6. 注文端末と、管理サーバと、進捗管理サーバとを有するシステムが実行する注文管理方法であって、
   前記注文端末が、商品の注文を、料金の支払いを前払いで受付け、
   前記管理サーバが、注文を受付けた注文時刻を少なくとも含む情報を記憶部に記憶し、
   前記進捗管理サーバが、前記商品の生産の進捗状況を管理するとともに、前記商品の生産が完了した場合、該完成時刻を含む情報を送信し、
   前記管理サーバが、前記記憶部に記憶された注文時刻、および、前記進捗管理サーバから送信された完成時刻に基づき、前記商品の注文から生産完了までの実測時間を算出し、該実測時間が想定時間よりも大きい場合に返金額を算出し、
   前記注文端末が、前記返金額を前記商品の注文者に返金する
   注文管理方法。
7. 請求項６に記載の注文管理方法において、
   前記管理サーバは、前記実測時間と前記想定時間とに基づき前記返金額を算出する注文管理方法。
8. 請求項６または７に記載の注文管理方法において、
   前記進捗管理サーバは、前記注文端末で受付けた注文順に商品が生産されるように進捗状況を管理し、
   前記管理サーバは、前記注文端末で注文を受付けたときに、商品ごとに予め定義された基準時間を想定時間に加算し、完成時刻が含まれた情報が前記進捗管理サーバから送信されたときに、前記基準時間を想定時間から減算する注文管理方法。
9. 請求項６から８のいずれか１つに記載の注文管理方法において、
   前記注文端末での料金の支払いの決済、および返金の決済は、電子マネー対応のカード、または携帯端末で行われる注文管理方法。
10. 請求項６から９のいずれか１つに記載の注文管理方法において、
    前記商品は、店舗が提供する料理であり、
    前記進捗管理サーバは、ＲＦタグが組み込まれた食器が、リーダが組み込まれた所定位置に置かれることで、前記商品の生産が完了したことを検知する注文管理方法。
11. 商品に対する料金の支払いを前払いで受付けた時刻である注文時刻を少なくとも含む情報を記憶する記憶部と、
    前記商品の生産が完了したときの完成時刻を含む情報を取得し、前記記憶部に記憶された注文時刻、および、前記取得した完成時刻に基づき、前記商品の注文から生産完了までの実測時間を算出し、該実測時間が想定時間よりも大きいかを判定する時間判定部と、
    前記時間判定部によって大きいと判定された場合に、返金額を算出する返金額算出部と、
    を有する注文管理装置。
    

Images