(57)【要約】【課題】料金が支払われた後にキャンセルが発生した場合でも、そのキャンセルや返金を柔軟に対応することができる技術を提供する。【解決手段】注文管理システムであって、商品の注文を、料金の支払いを前払いで受付け、且つ、注文のキャンセル依頼を受付ける受付け部と、商品の生産の進捗を、状況ごとに区分して管理するとともに、商品の区分情報を含む情報を送信する進捗管理部と、進捗管理部によって区分情報が送信された場合、送信された区分情報を記憶する記憶部と、記憶部に記憶された区分情報に基づき、注文のキャンセル依頼を受理するか否かを判定するキャンセル判定部と、キャンセル判定部によってキャンセル受理と判定された場合、返金額を算出する返金額算出部と、返金額を商品の注文者に返金する返金部とを有する。【選択図】図２
2012079013.tif 000002
【特許請求の範囲】
【請求項１】
商品の注文を、料金の支払いを前払いで受付け、且つ、前記注文のキャンセル依頼を受付ける受付け部と、
商品の生産の進捗を、状況ごとに区分して管理するとともに、前記商品の区分情報を含む情報を送信する進捗管理部と、
前記進捗管理部によって区分情報が送信された場合、該送信された区分情報を記憶する記憶部と、
前記記憶部に記憶された区分情報に基づき、前記注文のキャンセル依頼を受理するか否かを判定するキャンセル判定部と、
前記キャンセル判定部によってキャンセル受理と判定された場合、返金額を算出する返金額算出部と、
前記返金額を前記商品の注文者に返金する返金部と、
を有する注文管理システム。
【請求項２】
前記キャンセル判定部は、前記記憶部に記憶された区分情報が生産中または生産直前以外を示す情報である場合、キャンセル受理と判定し、
前記返金額算出部は、前払いとして支払われた料金の全額を、返金額として算出することを特徴とする請求項１に記載の注文管理システム。
【請求項３】
前記キャンセル判定部は、前記記憶部に記憶された区分情報が生産直前を示す情報である場合、キャンセル受理と判定し、
前記返金額算出部は、前払いとして支払われた料金よりも少ない額を、返金額として算出することを特徴とする請求項１または２に記載の注文管理システム。
【請求項４】
前記キャンセル判定部は、前記記憶部に記憶された区分情報が生産中を示す情報である場合、キャンセル不受理と判定することを特徴とする請求項１乃至３のいずれか１項に記載の注文管理システム。
【請求項５】
さらに、注文を受付けた注文時刻を前記受付け部から取得し、前記商品の生産が完了したときの完成時刻を前記進捗管理部から取得し、前記注文時刻、および、前記完成時刻に基づき、前記商品の注文から生産完了までの実測時間を算出し、該実測時間が想定時間よりも大きいかを判定する時間判定部を有し、
前記返金額算出部は、さらに、前記キャンセル判定部によってキャンセル不受理と判定された場合、且つ、前記時間判定部によって前記実測時間が前記想定時間よりも大きいと判定された場合、返金額を算出することを特徴とする請求項１乃至４のいずれか１項に記載の注文管理システム。
【請求項６】
前記キャンセル判定部は、さらに、キャンセル対象の商品と同じ商品が既に前記受付け部で注文されている場合、キャンセル受理と判定することを特徴とする請求項１乃至５のいずれか１項に記載の注文管理システム。
【請求項７】
注文端末と、管理サーバと、進捗管理サーバとを有するシステムが実行する注文管理方法であって、
前記注文端末が、商品の注文を、料金の支払いを前払いで受付け、且つ、前記注文のキャンセル依頼を受付け、
前記進捗管理サーバが、商品の生産の進捗を、状況ごとに区分して管理するとともに、前記商品の区分情報を含む情報を送信し、
前記管理サーバが、前記進捗管理サーバによって区分情報が送信された場合、該送信された区分情報を記憶部に記憶し、
前記記憶部に記憶された区分情報に基づき、前記注文のキャンセル依頼を受理するか否かを判定し、
キャンセル受理と判定した場合、返金額を算出し、
前記注文端末が、前記返金額を前記商品の注文者に返金する
注文管理方法。
【請求項８】
前記管理サーバは、前記記憶部に記憶された区分情報が生産中または生産直前以外を示す情報である場合、キャンセル受理と判定し、前払いとして支払われた料金の全額を、返金額として算出することを特徴とする請求項７に記載の注文管理方法。
【請求項９】
前記管理サーバは、前記記憶部に記憶された区分情報が生産直前を示す情報である場合、キャンセル受理と判定し、前払いとして支払われた料金よりも少ない額を、返金額として算出することを特徴とする請求項７または８に記載の注文管理方法。
【請求項１０】
前記管理サーバは、前記記憶部に記憶された区分情報が生産中を示す情報である場合、キャンセル不受理と判定することを特徴とする請求項７乃至９のいずれか１項に記載の注文管理方法。
【請求項１１】
前記管理サーバは、さらに、注文を受付けた注文時刻を前記注文端末から取得し、前記商品の生産が完了したときの完成時刻を前記進捗管理サーバから取得し、前記注文時刻、および、前記完成時刻に基づき、前記商品の注文から生産完了までの実測時間を算出し、該実測時間が想定時間よりも大きいかを判定し、
キャンセル不受理と判定した場合、且つ、前記実測時間が前記想定時間よりも大きいと判定した場合、返金額を算出することを特徴とする請求項７乃至１０のいずれか１項に記載の注文管理方法。
【請求項１２】
前記管理サーバは、さらに、キャンセル対象の商品と同じ商品が既に前記注文端末で注文されている場合、キャンセル受理と判定することを特徴とする請求項７乃至１１のいずれか１項に記載の注文管理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態は、注文や発生料金を管理する技術に関する。
【背景技術】
【０００２】
大型ショッピングセンターや高速道路の大規模なサービスエリアには、料理を提供する複数の店舗と、これら複数店舗の共有スペースである飲食用スペースとで構成されたフードコートがある。フードコート内で発生した飲食客の注文やその料金等を、店舗毎、または一元的に管理するシステムが存在する。またフードコートでは、料金の支払いは飲食客が料理を注文する際に前払いで行われるのが一般的である。
【発明の概要】
【発明が解決しようとする課題】
【０００３】
飲食客によって注文された後、飲食客からキャンセルを求められる場合がある。しかしながら、従来のシステムでは、一旦決済が確定した後にキャンセルに対応するためには、手動でデータを変更したり、紙面等にこのことを書きとめ、後に清算したりする必要がある。
【０００４】
この明細書は上述した問題点を解決するためになされたものであり、キャンセルが発生した場合でも柔軟に対応することができる技術を提供することを目的とする。
【課題を解決するための手段】
【０００５】
上記課題を解決するため、この明細書は、商品の注文を、料金の支払いを前払いで受付け、且つ、注文のキャンセル依頼を受付ける受付け部と、商品の生産の進捗を、状況ごとに区分して管理するとともに、商品の区分情報を含む情報を送信する進捗管理部と、進捗管理部によって区分情報が送信された場合、送信された区分情報を記憶する記憶部と、記憶部に記憶された区分情報に基づき、注文のキャンセル依頼を受理するか否かを判定するキャンセル判定部と、キャンセル判定部によってキャンセル受理と判定された場合、返金額を算出する返金額算出部と、返金額を商品の注文者に返金する返金部とを有する注文管理システムに関する。
【０００６】
また、この明細書は、注文端末と、管理サーバと、進捗管理サーバとを有するシステムが実行する注文管理方法であって、注文端末が、商品の注文を、料金の支払いを前払いで受付け、且つ、注文のキャンセル依頼を受付け、進捗管理サーバが、商品の生産の進捗を、状況ごとに区分して管理するとともに、商品の区分情報を含む情報を送信し、管理サーバが、進捗管理サーバによって区分情報が送信された場合、送信された区分情報を記憶部に記憶し、記憶部に記憶された区分情報に基づき、注文のキャンセル依頼を受理するか否かを判定し、キャンセル受理と判定した場合、返金額を算出し、注文端末が、返金額を前記商品の注文者に返金する注文管理方法に関する。
【図面の簡単な説明】
【０００７】
【図１】実施形態に係る注文管理システムの構成例を示す図である。
【図２】実施形態に係る注文管理システムの機能ブロックの一例を示す図である。
【図３】実施形態に係る注文管理システムにおける、注文発生時の処理シーケンスの一例を示す図である。
【図４】実施形態に係る注文管理システムにおける、調理進捗状況をオーダー端末に表示するときの処理シーケンスの一例を示す図である。
【図５】実施形態に係る注文管理システムにおける、時間超過による一部返金が発生するときの処理シーケンスの一例を示す図である。
【図６】実施形態に係る注文管理システムにおける、キャンセルが発生した場合の処理シーケンスの一例を示す図である（調理直前、調理中以外）。
【図７】実施形態に係る注文管理システムにおける、キャンセルが発生した場合の処理シーケンスの一例を示す図である（調理直前）。
【図８】実施形態に係る注文管理システムにおける、キャンセルが発生した場合の処理シーケンスの一例を示す図である（調理中）。
【図９】実施形態に係る注文管理システムにおける、キャンセルが発生した場合の処理シーケンスの一例を示す図である（調理中且つ時間超過）。
【図１０】第２実施形態に係る注文管理システムの構成例を示す図である。
【図１１】第２実施形態に係る注文管理システムのキャンセル依頼に対する応答処理を示すフローチャートである。
【図１２】第２実施形態に係る注文管理システムのキャンセル依頼に対する応答処理を示すフローチャートである。
【発明を実施するための形態】
【０００８】
（第１実施形態）
以下、本実施形態について図面を参照しつつ説明する。以下の説明において、飲食客は電子マネーに対応した接触型の磁気カードや、非接触型のＩＣカードを所有しており、このカードを用いて支払いや入金（チャージ）が行われるものとする。尚、同等機能を有する携帯端末が用いられても構わない。
【０００９】
図１は、本実施形態に係る注文管理システムの構成例を示す図である。注文管理システム１００は、中央管理サーバ１、複数のオーダー端末２、複数の調理サーバ３を有し、中央管理サーバ１とオーダー端末２との間、および、中央管理サーバ１と調理サーバ３との間では、互いに通信可能なネットワーク（有線、無線は問わない）が構築されている。
【００１０】
中央管理サーバ１は、注文管理システム１００の基幹コンピュータであり、注文された料理名や、その発注時刻、調理サーバ３から送信された調理の進捗状況等を保持する発注料理管理ＤＢ（Database）１５を有し、また、各店舗で扱っている料理に関する基本情報を保持する料理基本情報ＤＢ１６を有する。
【００１１】
オーダー端末２は、フードコート内の共有スペースの各テーブル、カウンターに設置された端末であり、飲食客からの注文を受付け、支払い、入金を行うとともに、飲食客へ調理状況、その他必要な情報を通知する。オーダー端末２は、本実施形態ではタッチパネルやカードリーダライタを有する。
【００１２】
調理サーバ３は、料理を提供する各店舗に設置されたサーバであり、オーダー端末２で注文された料理を調理者が確認するためのコンピュータである。また調理サーバ３は、料理の注文順番や、調理の進捗状況を調理中、調理直前、それ以外の区分に分けて管理する。
【００１３】
図２に、注文管理システム１００の機能ブロックの一例を示す。オーダー端末２は、ＵＩ（User Interface）部２１、カード情報取得／書込み部２２を有する。ＵＩ部２１は、タッチパネルを有し、店舗ごとのメニューを表示し、飲食客が選択した店舗のＩＤや注文料理の名前を取得する。カード情報取得／書込み部２２は、飲食客が所持しているカードに記憶されている会員情報を読み取り、またチャージ金額を更新する接触型または非接触型のカードリーダライタを有する。これらの各ユニットは、例えば、ＣＰＵ（Central Processing Unit）２０１、メモリ２０２、および上述の各ハードウェアと、予め導入されているソフトウェアとが協働して実現される。尚、例えば、演算処理を行うユニットはＡＳＩＣ（Application Specific Integrated Circuit）での実装でも構わない。
【００１４】
中央管理サーバ１は、時間判定部１１、返金額算出部１２、キャンセル判定部１３、ＤＢ操作部１４、発注料理管理ＤＢ１５、料理基本情報ＤＢ１６を有する。これら各ユニットの動作については後に詳説する。これら各ユニットも、例えば、ＣＰＵ１０１、メモリ１０２のハードウェア資源と、予め導入されているソフトウェアとが協働することで実現される。
【００１５】
調理サーバ３は、キュー状態通知部３１、キュー操作部３２、調理キュー３３を有する。キュー状態通知部３１は、調理キュー３３のキュー状態を監視し、調理中、またはその１つ前の状態（すなわち、調理直前の状態）のデータを調理キュー３３から取得し、中央管理サーバ１へ送信する。
【００１６】
キュー操作部３２は、中央管理サーバ１から送信された注文情報を調理キュー３３に新規にエントリし、また、調理が完了した料理に対応したデータを調理キュー３３から削除する。調理が完了したときの調理キュー３３からの削除は、本実施形態では、調理者がキュー操作部３２内の所定のボタンを押下した場合に行われるものとする。尚、この実装以外にも、ＲＦＩＤ(Radio Frequency Identification)を用いた方法であってもよい。例えば、食器の底面にＲＦタグを組み込んでおき、リーダが組み込まれた調理用カウンターに、調理者が料理を盛り付ける前に食器を置き、盛り付けが完了した後に、調理者もしくは配膳者が、リーダが組み込まれたカウンター（別のカウンターであってもよい）に当該食器を置くことで、調理キュー３３からデータが削除される実装であってもよい。この実装の場合、キュー操作部３２にはＲＦタグとリーダも含まれる。
【００１７】
調理キュー３３は、注文のデータを順次格納し、ＦＩＦＯ（First In, First Out）方式でデータを扱う。調理サーバ３内のこれら各ユニットも、ＣＰＵ３０１、メモリ３０２、上記各ハードウェアと、予め導入されているソフトウェアとが協働することで実現される。尚、演算処理を行うユニットや調理キュー３３の実装はＡＳＩＣ（Application Specific Integrated Circuit）であってもよい。
【００１８】
次に、注文管理システム１００の動作例について、図３から図９を参照しつつ、ケース分けして説明する。まず、注文発生時の注文管理システム１００の動作について、図３を用いて説明する。
【００１９】
オーダー端末２は、飲食客から前払いで注文を受付け、注文情報を中央管理サーバ１へ送信する（ＡＣＴ１）。このとき、端末ＩＤ、会員情報、店舗ＩＤ、料理名、決済金額の情報が送信される。中央管理サーバ１のＤＢ操作部１４は、送信された注文情報を発注料理管理ＤＢ１５に登録する（ＡＣＴ２）。このとき、端末ＩＤ、料理単位の注文チケット番号（中央管理サーバ１がユニークに払い出す）、店舗ＩＤ、会員情報、料理名、発注時刻、調理状態フラグ（初期値）の各データを含んだレコードが発注料理管理ＤＢ１５に登録される。
【００２０】
中央管理サーバ１は、店舗ＩＤを参照して該当する店舗の調理サーバ３へ注文情報を送信する（ＡＣＴ３）。このときに送信されるデータは、注文チケット番号、料理名であり、調理サーバ３のキュー操作部３２は、この注文チケット番号、料理名のセットを調理キュー３３に新規オーダーとして登録する。
【００２１】
次に、調理の進捗状況を飲食客に通知する動作について、図４を用いて説明する。調理サーバ３のキュー状態通知部３１は、調理キュー３３の状態が更新された場合、調理中の料理、または次に調理する料理に関するデータ（注文チケット番号、料理名のセット）を調理キュー３３から取得する。キュー状態通知部３１は、取得した注文チケット番号、料理名のセットに、調理中、または調理直前を意味する値（調理状態フラグ）を付与して中央管理サーバ１へ送信する（ＡＣＴ１１）。中央管理サーバ１のＤＢ操作部１４は、送信された注文チケット番号、料理名に基づき発注料理管理ＤＢ１５内のレコードを検索し、該当するレコードの調理状態フラグの値を、取得した調理状態フラグの値に更新する（ＡＣＴ１２）。ＤＢ操作部１４は、発注料理管理ＤＢ１５内の該当するレコードから端末ＩＤを取得し、対応するオーダー端末２へ店舗ＩＤ、料理名、調理状態フラグを送信する（ＡＣＴ１３）。オーダー端末２のＵＩ部２１は、調理状態フラグに応じた表示をする。ＵＩ部２１は、例えば調理状態フラグが調理中旨の値である場合は「ただいま調理中です。」と表示し、調理直前旨の値である場合は「まもなく調理開始します。」と表示する。
【００２２】
次に、時間超過による払戻し金額が発生した場合の動作について、図５を用いて説明するが、ここで料理基本情報ＤＢ１６に登録されているデータや、その扱い方について説明する。
【００２３】
料理基本情報ＤＢ１６には、店舗ＩＤ、料理名、および、その料理を調理するのに必要な時間（基本調理時間）の各データを含んだレコードが予め登録されている。中央管理サーバ１は、オーダー端末２から注文情報を取得する毎に、その注文情報内の店舗ＩＤ、料理名に基づき料理基本情報ＤＢ１６から基本調理時間を取得し、基本調理時間を店舗ＩＤごとに累積加算する（以下、この基本調理時間を累積加算した時間をノルマ時間（想定時間）と称す）。また中央管理サーバ１は、調理サーバ３から調理完了旨のデータ、すなわち、注文チケット番号、料理名、調理状態フラグ、完成時刻の要素で構成されたデータレコードを取得したときに、該当する店舗ＩＤのノルマ時間に、完成した料理名の基本調理時間を減算させる。このようにしてノルマ時間は注文を受付ける毎に、また調理が完了する毎に更新される。中央管理サーバ１は、注文を受付ける毎に今現在のノルマ時間に注文された料理の基本調理時間を加算し、注文チケット番号と加算後のノルマ時間とを対応付けて、別テーブル上で管理する。
【００２４】
以上を踏まえ、時間超過による払戻し金額が発生した場合の動作について説明する。調理が完了した場合、調理サーバ３のキュー操作部３２は、調理キュー３３内の最も古いデータ（注文チケット番号、料理名のセット）を取得して、調理キュー３３から当該データを削除する。その後、調理サーバ３は、取得した注文チケット番号、料理名に、調理状態フラグ（調理完了旨の値）、完成時刻を付与し、これらを１つのデータレコードとして中央管理サーバ１へ送信する（ＡＣＴ２１）。
【００２５】
データレコードを取得した中央管理サーバ１は、発注料理管理ＤＢ１５を参照し（ＡＣＴ２２）、払戻しが発生するかを判定し、発生する場合は返金額を算出する（ＡＣＴ２３）。
【００２６】
ＡＣＴ２２、ＡＣＴ２３の処理について説明する。中央管理サーバ１のＤＢ操作部１４は、調理サーバ３から取得したデータレコードに基づき、発注料理管理ＤＢ１５内の該当エントリを検索する。ＤＢ操作部１４は、該当エントリから発注時刻を取得し、また、別テーブル上で管理されているノルマ時間を取得する。時間判定部１１は、調理サーバ３から送信された完成時刻から、取得された発注時刻を減算し、この減算時間（以下、実測時間）とノルマ時間とを比較する。実測時間が明らかにノルマ時間よりも大きい場合（例えば実測時間とノルマ時間との差分が所定閾値を上回った場合）、時間判定部１１は、払戻しが発生すると判定する。
【００２７】
返金額算出部１２は、以下の式を用いて返金額を算出する。返金額の算出方法には様々な手法があるが、本実施形態では以下の式を用いる。
（式１）返金額（円）  ＝  （料理の単価／定数Ｋ）×（実測時間／ノルマ時間）
（定数Ｋは、店舗毎に予め定義された定数であり、例えばＫ＝１０）
【００２８】
中央管理サーバ１は、算出した返金額をオーダー端末２へ送信する（ＡＣＴ２４）。返金額を取得したオーダー端末２は、ＵＩ部２１に、例えば「払戻し金額はＸＸ円です。金額をカードに戻します。カードをかざしてください。」と表示することで、飲食客に払戻しが発生することを通知する。ここで、カード情報取得／書込み部２２は、飲食客が所有するカードの金額データを、返金額分増加するように更新し、決済したことを中央管理サーバ１へ通知する（ＡＣＴ２５）。通知を受けた中央管理サーバ１のＤＢ操作部１４は、該当するレコードを発注料理管理ＤＢ１５から削除する（ＡＣＴ２６）。
【００２９】
次に、キャンセルが発生したときの動作について説明する。キャンセルは、基本的に飲食客の都合によって行われるが、今現在調理中の料理がキャンセルされる場合や調理直前にキャンセルされる場合、店舗側の不利益となる。また一方、調理の遅延に起因するキャンセルは、たとえ調理中であろうとも飲食客に配慮をする必要がある。以下、図６から図９を参照しつつ、このような各ケースを考慮した実装例を説明する。
【００３０】
まず、調理中や調理直前以外の注文にキャンセルが発生した場合の動作を、図６を用いて説明する。オーダー端末２は、会員情報、店舗ＩＤ、料理名のデータとともにキャンセル依頼を中央管理サーバ１へ送信する（ＡＣＴ３１）。中央管理サーバ１のＤＢ操作部１４は、発注料理管理ＤＢ１５を参照し、該当レコードの調理状態フラグを取得する（ＡＣＴ３２）。次にキャンセル判定部１３は、取得された調理状態フラグに基づき、キャンセルを受付けるかを判定する。
【００３１】
キャンセル判定部１３の動作について説明する。キャンセル判定部１３は、調理状態フラグが初期値であるか（すなわち、上述のＡＣＴ１２による更新がなされていないか）を判定する。初期値である場合、キャンセル依頼を受けた料理は調理中もしくは調理直前ではないため、キャンセル判定部１３は、キャンセルをそのまま受付けると判定する。
【００３２】
次に中央管理サーバ１は、注文チケット番号、料理名のセットとともに、削除命令を調理サーバ３に送信する（ＡＣＴ３３）。調理サーバ３のキュー操作部３２は、該当するデータを調理キュー３３から削除する。また一方、中央管理サーバ１は、全額返金通知をオーダー端末２へ送信する（ＡＣＴ３４）。オーダー端末２のＵＩ部２１は、例えば「キャンセルされた料理につき、全額返金致します。カードをかざしてください。」と表示する。ここで、飲食客によってカードがかざされた場合、カード情報取得／書込み部２２は、カード内のチャージ金額を返金額分増加するように更新し、決済したことを中央管理サーバ１へ通知する（ＡＣＴ３５）。通知を受けた中央管理サーバ１のＤＢ操作部１４は、該当するレコードを削除する（ＡＣＴ３６）。
【００３３】
次に、調理直前の注文にキャンセルが発生した場合の動作を、図７を用いて説明する。調理直前の場合、食材の用意等の前準備が既に行われている場合もあるため、本実施形態では、キャンセルには応じるが、全額返金せず一部のみ返金することする。尚、キャンセル依頼（ＡＣＴ４１）、参照処理（ＡＣＴ４２）は、図６と同様の処理であるため、説明を割愛する。
【００３４】
キャンセル判定部１３は、調理状態フラグを確認する。調理状態フラグが調理直前旨の値である場合、キャンセル判定部１３はキャンセルを受理すると判定し、返金額算出部１２は返金額を算出する（ＡＣＴ４４）。返金額の算出方法は様々あるが、本実施形態では、料理単価に対し所定の割合（例えば半額）を返金するものとする。
【００３５】
中央管理サーバ１は、返金額とともに、一部返金通知をオーダー端末２へ送信する（ＡＣＴ４５）。オーダー端末２のＵＩ部２１は、例えば「キャンセルされた料理につき、一部返金致します。返金金額はＸＸ円です。カードをかざしてください。」と表示する。以降のＡＣＴ４６、ＡＣＴ４７の処理、およびＡＣＴ４３の処理は、図６と同様であるため、説明を割愛する。
【００３６】
次に、調理中の注文にキャンセルが発生した場合の動作を、図８を用いて説明する。調理中の場合、本実施形態では、原則キャンセルには応ないものとする（例外については後ほど説明する）。
【００３７】
上述の図６、図７と同様に、注文管理システム１００は、キャンセル依頼（ＡＣＴ５１）、参照処理（ＡＣＴ５２）の各処理を実行する。キャンセル判定部１３は、調理状態フラグを確認する。調理状態フラグが調理中旨の値である場合、キャンセル判定部１３は、キャンセル不受理であると判定する。このとき、中央管理サーバ１は、再度調理サーバ３に確認してもよい（ＡＣＴ５３）。
【００３８】
キャンセル判定部１３によってキャンセル不受理と判定された場合、次は時間判定部１１の処理となり、時間超過の有無の判定がなされるが、この動作については後に説明する。中央管理サーバ１は、キャンセル不受理通知をオーダー端末２へ送信する（ＡＣＴ５４）。オーダー端末２のＵＩ部２１は、例えば「ご指定の料理は現在調理中です。申し訳ありませんがキャンセルできません。」と表示する。
【００３９】
本実施形態では、調理中の注文にキャンセルが発生した場合、上述通り原則キャンセルを不受理としているが、調理が遅延している場合については、例外的にキャンセルを受付け、一部返金するものとする。この動作について、図９を参照しつつ説明する。
【００４０】
上述の図６、図７と同様に、注文管理システム１００は、キャンセル依頼（ＡＣＴ６１）、参照処理（ＡＣＴ６２）の各処理を実行する。キャンセル判定部１３は、調理状態フラグを確認することで、キャンセル対象の料理が調理中であると判定する。このとき、中央管理サーバ１は、再度調理サーバ３に確認してもよい。
【００４１】
キャンセル判定部１３によって調理中と判定された場合、時間判定部１１は、時間超過の有無を判定する。時間判定部１１は、ＤＢ操作部１４を介して発注料理管理ＤＢ１５のキャンセル対象のレコードから発注時刻を取得し、現在時刻から発注時刻を減算する。時間判定部１１は、この減算時間と、別テーブルで管理されたノルマ時間とを比較し、減算時間が明らかにノルマ時間よりも大きい場合（例えば減算時間とノルマ時間との差分が所定閾値を上回った場合）、返金が発生すると判定する。返金額算出部１２は、例えば上述の式１を用いたり、また料理単価の一定割合を求めたりすることで、返金額を算出する（ＡＣＴ６４）。
【００４２】
中央管理サーバ１は、特例返金通知をオーダー端末２へ送信する（ＡＣＴ６５）。オーダー端末２のＵＩ部２１は、例えば「キャンセルされた料理につき、一部返金致します。返金金額はＸＸ円です。カードをかざしてください。」と表示する。以降のＡＣＴ６６、ＡＣＴ６７の処理、および調理サーバ３の削除処理（ＡＣＴ６３）は、前述と同様であるため説明を割愛する。
【００４３】
また、衛生上の安全性を考慮する必要があるが、図９で示した例外のほか、同じ料理の注文を別途受けている場合に限り、キャンセルを認めるとする実装も可能である。この場合、上述のキャンセル依頼、参照処理の後に、キャンセル判定部１３は、発注料理管理ＤＢ１５内に、発注時刻がキャンセルを受けた注文のものより後のレコードであり、且つオーダー端末２から送信された店舗ＩＤ、料理名と同じ店舗ＩＤ、料理名のレコードが有るかを、ＤＢ操作部１４を用いて判定する。ここで該当するレコードがある場合は、本実施形態ではキャンセルを認め、全額もしくは一部返金される。
【００４４】
（第２実施形態）
以下、前記実施形態と同一機能部位には同一符号を付し、その説明を省略する。
本実施形態が特に第１実施形態と異なる点は、キャンセル依頼に対して全額を払い戻すと予め決められている料理がある点と、全額払い戻しするか否かをキャンセル対象料理の調理開始までに余裕があるか否かで判定する場合がある点である。
【００４５】
図１０は、本実施形態の注文管理システムの構成例を示す図である。
本実施形態では、料理基本情報ＤＢは、料理ごとに、その料理がキャンセル料金発生対象であるか否かを示すデータが対応付けられる。本実施形態では、調理時間や手間のかかる料理は、キャンセル料金発生対象であることを示すデータが対応付けられ、調理時間や手間のかからない料理は、キャンセル料金発生対象でないことを示すデータが対応付けられる。また、中央管理サーバ１のメモリ１０２には、予めフードコート側により設定される閾値Ｔ、Ｑ、および係数Ｋが記憶される。閾値Ｔは、キャンセル対象料理の調理開始までに余裕があるか否かを判定する処理に用いられる。閾値Ｑは、キャンセル料を発生させる境界の品数である。本実施形態では、図１０の調理キューデータに参照されるように、閾値Ｑ内にキャンセル対象料理が入っているか否かで、すなわちキャンセル対象料理前にある未調理済みの料理数ｑがＱより小さいか否かで、キャンセル料を発生させるか否かを判定する場合がある。係数Ｋは、キャンセル料金の額を大小させる係数として用いられる場合がある。
【００４６】
以下、図１１、１２のフローチャートを用いて、キャンセル依頼に対する本実施形態の注文管理システムの応答処理を、前記実施形態と同一の処理部分の説明は省略しながら簡単に説明する。
【００４７】
本実施形態では、ある料理についてオーダー端末２からキャンセル依頼があると（ＡＣＴ７１）、中央管理サーバ１のＤＢ操作部１４は、料理基本情報ＤＢを参照して該当レコードからキャンセル対象料理の基本調理時間と、該料理がキャンセル料金発生対象か否かを示すデータとを取得するとともに、発注料理管理ＤＢを参照し、該当レコードからキャンセル対象料理の発注時刻を取得する（ＡＣＴ７２）。
【００４８】
ＡＣＴ７２の後、キャンセル判定部１３は、ＤＢ操作部１４が取得したデータが、キャンセル対象料理がキャンセル料金発生対象であることを示すデータであれば、キャンセル依頼を受理すると判定する（ＡＣＴ７３）。該ＡＣＴ７３では、キャンセル判定部１３は、実質的には、キャンセル料が発生するキャンセル依頼か否かを判定する。
ＡＣＴ７３において、キャンセル判定部１３がキャンセル依頼を受理すると判定した場合（キャンセル料が発生しないキャンセル依頼と判定した場合）（ＡＣＴ７３：ＮＯ）、返金額算出部１２は、キャンセル対象料理に支払われた代金の全額を返金額として算出し、全額返金通知をオーダー端末２に送信する（ＡＣＴ７４）。
【００４９】
ＡＣＴ７４の後、オーダー端末２は、全額返金通知を受信することにより、キャンセル対象料理の代金を返金すると判定し（ＡＣＴ７５）、全額返金する旨の表示Ａ（図１０）、返金額の全額決済、および中央管理サーバ１への返済済み通知を行う（ＡＣＴ７６）。返済済み通知を受けた中央管理サーバ１は、キャンセル対象料理に関するレコードを料理基本情報ＤＢおよび発注料理管理ＤＢから削除する（ＡＣＴ７７）。
【００５０】
一方、ＡＣＴ７２の後、キャンセル判定部１３は、ＤＢ操作部１４が取得したデータが、キャンセル対象料理がキャンセル料金発生対象でないことを示すデータであれば、後の処理で改めてキャンセル依頼を受理するか否かを判定するので、ここではキャンセル依頼を受理するとは判定しない（キャンセル料が発生するキャンセル依頼と判定）（ＡＣＴ７３：ＹＥＳ）。ＡＣＴ７３の後、キャンセル判定部１３が調理キューデータの出力要求を調理サーバ３に出力し（ＡＣＴ７８）、これを受けて調理サーバ３のキュー状態通知部３１が調理キューデータを中央管理サーバ１に出力する（ＡＣＴ７９）。
【００５１】
ＡＣＴ７９の後、中央管理サーバ１のキャンセル判定部１３は、受信した調理キューデータに基づいて、キャンセル対象料理が調理開始されるまでの想定時間を示す余裕時間ｔを算出する（ＡＣＴ８０）。余裕時間ｔは、例えばキャンセル対象料理の前にある未調理済みの料理数ｑ（図１０）に所定の時間を乗算して算出する。また、余裕時間ｔは、例えばキャンセル対象料理前にある各料理の基本調理時間をＤＢ操作部１４が取得し、キャンセル判定部１３が前記各基本調理時間を加算することで算出する。
【００５２】
ＡＣＴ８０の後、キャンセル判定部１３は、キャンセル対象料理の調理開始まで余裕があるか否かを判定する（ＡＣＴ８１）。具体的にキャンセル判定部１３は、余裕時間ｔがフードコート側に設定された閾値Ｔより大きいか否かを判定する。キャンセル判定部１３がｔ＞Ｔと判定した場合、すなわちキャンセル判定部１３がキャンセル対象料理の調理開始までに余裕があると判定した場合（ＡＣＴ８１：ＹＥＳ）、全額返金通知の送信等の処理ＡＣＴ７４〜ＡＣＴ７７が行われる。
【００５３】
一方、キャンセル判定部１３がｔ＞Ｔでないと判定した場合（ＡＣＴ８１：ＮＯ）、キャンセル判定部１３は、今度はキャンセル対象料理の前にある未調理済み料理数ｑが、フードコート側に設定された閾値Ｑより小さいか否か、すなわちｑ＜Ｑであるか否かにより、キャンセル対象料理の調理開始までに余裕があるか否かを判定する（ＡＣＴ８２）。キャンセル判定部１３がｑ＜Ｑでないと判定した場合（ＡＣＴ８２：ＮＯ）、すなわちキャンセル対象料理の調理開始までに余裕があると判定した場合にも、やはり全額返金通知の送信等の処理ＡＣＴ７４〜ＡＣＴ７７が行われる。
【００５４】
ＡＣＴ８２においてキャンセル判定部１３は、ｑ＜Ｑと判定した場合（ＡＣＴ８２：ＹＥＳ）、すなわちキャンセル対象料理の調理開始までに余裕が無いと判定した場合、キャンセル判定部１３は、キャンセル対象料理が調理中であるか否か、すなわちｑ＝０か否かを判定する（ＡＣＴ８３）。
【００５５】
キャンセル判定部１３は、ｑ＝０と判定した場合（ＡＣＴ８３：ＹＥＳ）、現在時刻から、ＡＣＴ７２にて取得されたキャンセル対象料理の発注時刻を減算し、実測調理経過時間（減算時刻）を算出する。なお、現在時刻をキャンセル依頼があった時刻に代えて実測調理経過時間を算出してもよい。そして、キャンセル判定部１３は、実測調理経過時間が、ＡＣＴ７２にて取得されたキャンセル対象料理の基本調理時間を超えるか否か判定する。（ＡＣＴ８４）。
【００５６】
キャンセル判定部１３は、実測調理経過時間が基本調理時間を超えないと判定する場合（ＡＣＴ８４：ＮＯ）、キャンセル依頼を受理しないと判定し、キャンセル依頼不受理通知をオーダー端末２に送信する（ＡＣＴ８５）。キャンセル依頼不受理通知を受信したオーダー端末２は、代金返金決済を行わないと判定し（ＡＣＴ７５：ＮＯ）、代金返金決済を行わない旨の表示Ｂ（図１０）を行う（ＡＣＴ８６）。
【００５７】
キャンセル判定部１３が、ｑ＝０と判定しない場合（ＡＣＴ８３：ＮＯ）および実測調理経過時間が基本調理時間を超えると判定する場合（ＡＣＴ８４：ＹＥＳ）、返金額算出部１２がキャンセル料金ｐを算出する（ＡＣＴ８７）。返金額算出部１２は、ｑ＝０でない場合、キャンセル対象料理の定価をＰとし、該Ｐおよびキャンセル料金を発生させる境界の品数である前述した閾値Ｑを用いてキャンセル料金ｐを以下のように算出する。
【数１】
2012079013.tif 000003
また、返金額算出部１２は、ｑ＝０の場合、キャンセル対象料理の定価Ｐ、フードコート側が定めた係数Ｋ、実測調理経過時間、および基本調理時間を用いてキャンセル料金ｐを以下のように算出する。
【数２】
2012079013.tif 000004
【００５８】
ＡＣＴ８７の後、返金額算出部１２は、キャンセル対象料理の定価Ｐからキャンセル料金ｐを減算して返金額を算出し（ＡＣＴ８８）、該返金額を含んだ一部返金通知をオーダー端末２に送信する（ＡＣＴ８９）。
ＡＣＴ８９の後、オーダー端末２は、一部返金通知を受信することにより、キャンセル対象料理の代金を返金すると判定し（ＡＣＴ７５：ＹＥＳ）、一部返金する旨の表示Ｃ（図１０）等を行う（ＡＣＴ７６）。ＡＣＴ７６の後、中央管理サーバ１は、キャンセル対象料理に関するレコードを料理基本情報ＤＢおよび発注料理管理ＤＢから削除する（ＡＣＴ７７）。
【００５９】
本実施形態では、キャンセル依頼に対する応答処理における最初の段階で、ＤＢを利用して、調理時間や手間のかからない料理に対しては全額返金すると処理するので、計算資源（計算時間やメモリ使用量）の消費を抑制できる。
また、本実施形態では、キャンセル対象料理の調理開始までにゆとりがあれば全額返金とし、ゆとりがなければ、一部はキャンセル依頼を不受理とし、一部はキャンセル料を発生させて一部返金とするので、きめ細やかにキャンセル依頼に対して対応できる。
【００６０】
前記各実施形態では、複数店舗と店舗共有の飲食スペースとを有するフードコートを一例として説明したが、態様を限定するものではない。１つの店舗内で前記各実施形態の注文管理システムが用いられてもよい。また、料理の注文やその料金を例として説明し、業として料理を提供する分野に特化して説明したが、様々な製造分野にも前記各実施形態は適用可能である。
【００６１】
また、オーダー端末、調理サーバはそれぞれ複数あるものとして説明したが、片方が単数、また両方とも単数の構成であってもよい。
【００６２】
以上説明したように、前記各実施形態では、料金が支払われた場合でも、注文を受けてから料理を提供するまでに長時間要した場合、返金に応じることができる。
【００６３】
また、前記各実施形態では、料金が支払われた後にキャンセルが発生した場合でも、調理の進捗状況に応じた返金をすることができる。
【００６４】
本発明は、その精神または主要な特徴から逸脱することなく、他の様々な形で実施することができる。そのため、前述の実施の形態はあらゆる点で単なる例示に過ぎず、限定的に解釈してはならない。本発明の範囲は、特許請求の範囲によって示すものであって、明細書本文には、なんら拘束されない。さらに、特許請求の範囲の均等範囲に属する全ての変形、様々な改良、代替および改質は、すべて本発明の範囲内のものである。
【００６５】
以上に詳述したように、本実施形態によれば、料金が支払われた後にキャンセルが発生した場合でも、そのキャンセルや返金を柔軟に対応することができる。
【符号の説明】
【００６６】
１  中央管理サーバ、２  オーダー端末、３  調理サーバ、１１  時間判定部、１２  返金額算出部、１３  キャンセル判定部、１４  ＤＢ操作部、１５  発注料理管理ＤＢ、１６  料理基本情報ＤＢ、２１  ＵＩ部、２２  カード情報取得／書込み部、３１  キュー状態通知部、３２  キュー操作部、３３  調理キュー、１００  注文管理システム。
【図１】
2012079013.tif 000005
【図２】
2012079013.tif 000006
【図３】
2012079013.tif 000007
【図４】
2012079013.tif 000008
【図５】
2012079013.tif 000009
【図６】
2012079013.tif 000010
【図７】
2012079013.tif 000011
【図８】
2012079013.tif 000012
【図９】
2012079013.tif 000013
【図１０】
2012079013.tif 000014
【図１１】
2012079013.tif 000015
【図１２】
2012079013.tif 000016