(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2023-05-08
(45)【発行日】2023-05-16
(54)【発明の名称】注文管理装置及びそのプログラム
(51)【国際特許分類】
G06Q 30/0601 20230101AFI20230509BHJP
【FI】
G06Q30/0601 304
(21)【出願番号】P 2022005673
(22)【出願日】2022-01-18
(62)【分割の表示】P 2017030864の分割
【原出願日】2017-02-22
【審査請求日】2022-01-18
(73)【特許権者】
【識別番号】000003562
【氏名又は名称】東芝テック株式会社
(74)【代理人】
【識別番号】110003708
【氏名又は名称】弁理士法人鈴榮特許綜合事務所
(74)【代理人】
【識別番号】100108855
【氏名又は名称】蔵田 昌俊
(74)【代理人】
【識別番号】100179062
【氏名又は名称】井上 正
(74)【代理人】
【識別番号】100075672
【氏名又は名称】峰 隆司
(74)【代理人】
【識別番号】100153051
【氏名又は名称】河野 直樹
(74)【代理人】
【識別番号】100162570
【氏名又は名称】金子 早苗
(72)【発明者】
【氏名】高橋 勲
【審査官】毛利 太郎
(56)【参考文献】
【文献】特開2013-137778(JP,A)
【文献】特開2012-27731(JP,A)
【文献】特開2007-193669(JP,A)
【文献】特開2002-133516(JP,A)
【文献】特開2012-234368(JP,A)
(58)【調査した分野】(Int.Cl.,DB名)
G06Q 10/00-99/00
G07G 1/00- 1/14
(57)【特許請求の範囲】
【請求項1】
店舗での商品提供に関する店舗外からの注文に関する注文データを生成する生成手段と、
前記生成手段により生成された注文データを注文管理装置に送信する送信手段と、
前記注文管理装置からの通知を受けると、該当の注文の注文者に対して来店を促すための通知を行う第2の通知手段と、
を具備した受注サーバとともに受注システムを構成する前記注文管理装置であって、
前記送信手段により送信された注文データを取得する取得手段と、
商品提供に関する注文データを、店舗内で受け付けられた注文に関する注文データ
であるか、
前記取得手段により取得された注文データ
であるかを識別可能に管理する管理手段と、
注文データに関する
商品提供のための処理が終了したことに応じて、該当する注文データが
前記取得手段により取得された注文データとして前記管理手段により管理されているならば、
前記受注サーバへと処理の終了を通知
し、該当する注文データが店舗内で受け付けられた注文に関する注文データとして前記管理手段により管理されているならば、前記受注サーバへと処理の終了を通知しない第1の通知手段と、
を具備する注文管理装置。
【請求項2】
前記
第1の通知手段は、
注文データに関する注文者への商品提供が終了したことに応じて、該当する注文データが前記取得手段により取得された注文データとして前記管理手段により管理されているならば、前記受注サーバへと提供終了を通知する、
請求項
1に記載の注文管理装置。
【請求項3】
前記
第1の通知手段は、
注文データに関する商品提供に関する決済が終了したことに応じて、該当する注文データが前記取得手段により取得された注文データとして前記管理手段により管理されているならば、前記受注サーバへと決済終了を通知する、
請求項1
又は請求項2に記載の注文管理装置。
【請求項4】
店舗での商品提供に関する店舗外からの注文に関する注文データを生成する生成手段と、
前記生成手段により生成された注文データを注文管理装置に送信する送信手段と、
前記注文管理装置からの通知を受けると、該当の注文の注文者に対して来店を促すための通知を行う第2の通知手段と、
を具備した受注サーバとともに受注システムを構成する前記注文管理装置に備えられたコンピュータを、
前記送信手段により送信された注文データを取得する取得手段と、
商品提供に関する注文データを、店舗内で受け付けられた注文に関する注文データ
であるか、
前記取得手段により取得された注文データ
であるかを識別可能に管理する管理手段と、
注文データに関する
商品提供のための処理が終了したことに応じて、該当する注文データが
前記取得手段により取得された注文データとして前記管理手段により管理されているならば、
前記受注サーバへと処理の終了を通知
し、該当する注文データが店舗内で受け付けられた注文に関する注文データとして前記管理手段により管理されているならば、前記受注サーバへと処理の終了を通知しない第1の通知手段と、
して機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明の実施形態は、注文管理装置及びそのプログラムに関する。
【背景技術】
【0002】
近年、来店予定客が来店前に自身の情報通信端末を操作することで、来店時に提供される品物の注文を行えるサービスが提供されている。このようなサービスは、例えば飲食店を営む店舗が提供している。この種のサービスは、通常、自店舗の既存システムに当該サービスに対応する機能を新たに追加することで、提供されている。しかしながら、このような機能を独自に追加、構築するのはコストが係るので、自店舗の既存システムに取り込むのでなく、第三者から提供される当該サービスを併用することが多くなっている。このように第三者から提供されるサービスを既存システムと併用している店舗においては、当該サービスを提供している第三者が管理運営しているサーバに、タブレット端末など既存システムから独立した情報端末を用いてアクセスし、来店予定客からの注文の内容を確認することになるので、注文の管理が煩雑になる。
そこで、POS(point-of-sale)システムなどのような商品販売データ管理装置に接続された、旧来からの既存の受注管理システムでの注文データと同じように、第三者が提供する上記サービスのデータを利用することができるように、データ変換するものが考えられている。
しかしながら、単に注文データの形式を既存の受注管理システムのものに変換しただけでは、第三者から提供されたサービスを介して受けた注文の調理や商品提供を、当該店舗で直接受け付けた注文のものと同じように行えるようになるだけであり、当該店舗における商品販売のデータ処理を適切に行うには不十分である。したがって、第三者から提供されたサービスを介して受けた注文に係る商品販売のデータ処理と、当該店舗で直接受け付けた注文に係る商品販売のデータ処理とを適切に取り扱えるものが望まれていた。
そのためには、注文管理装置において、店舗で直接受け付けられた注文と、店舗外から間接的に受け付けた注文とを識別可能な状態で統一的に取り扱えると都合が良い。
【先行技術文献】
【特許文献】
【0003】
【発明の概要】
【発明が解決しようとする課題】
【0004】
本発明が解決しようとする課題は、店舗で直接受け付けた注文と、店舗外から間接的に受け付けた注文とを識別可能名状態で統一的に取り扱えることを可能とする注文管理装置及びそのプログラムを提供することである。
【課題を解決するための手段】
【0005】
実施形態の注文管理装置は、店舗での商品提供に関する店舗外からの注文に関する注文データを生成する生成手段と、生成手段により生成された注文データを注文管理装置に送信する送信手段と、注文管理装置からの通知を受けると、該当の注文の注文者に対して来店を促すための通知を行う第2の通知手段と、を具備した受注サーバとともに受注システムを構成する上記の注文管理装置であって、取得手段、管理手段及び第1の通知手段を備える。取得手段は、送信手段により送信された注文データを取得する。管理手段は、商品提供に関する注文データを、店舗内で受け付けられた注文に関する注文データであるか、取得手段により取得された注文データであるかを識別可能に管理する。第1の通知手段は、注文データに関する商品提供のための処理が終了したことに応じて、該当する注文データが取得手段により取得された注文データとして管理手段により管理されているならば、受注サーバへと処理の終了を通知し、該当する注文データが店舗内で受け付けられた注文に関する注文データとして管理手段により管理されているならば、受注サーバへと処理の終了を通知しない。
【図面の簡単な説明】
【0006】
【
図1】一実施形態に係る注文管理装置が適用されるシステムの概略構成を示す図。
【
図2】
図1中の注文管理装置の要部構成を示すブロック図。
【
図3】
図2中の注文データ領域に記憶される注文データの構成例を模式的に示す図。
【
図4】
図2中のプロセッサによる情報処理のフローチャート。
【
図5】
図2中のプロセッサによる情報処理のフローチャート。
【発明を実施するための形態】
【0007】
以下、実施の形態の一例について図面を用いて説明する。なお、本実施の形態では、飲食物を、客の注文に応じて調理した上で来店客に提供する店舗での注文管理を行う注文管理装置を例に説明する。なお、この種の装置は、オーダーステーションとも称される。
【0008】
図1は本実施形態に係る注文管理装置が適用されるシステムの概略構成を示す図である。
このシステムは、店舗システム10、受注サーバ20及び情報端末30を含む。そして店舗システム10及び情報端末30と受注サーバ20とは、それぞれ通信ネットワーク40を介して通信可能とされている。
【0009】
店舗システム10は、上記の店舗に設けられるもので、ハンディ端末1、注文管理装置2、伝票プリンタ3及びPOS端末4を、LAN(local area network)5にそれぞれ接続して構成される。ただし、ハンディ端末1は、無線アクセスポイント6を介してLAN5に接続される。注文管理装置2、伝票プリンタ3及びPOS端末4についても、無線アクセスポイント6を介してLAN5に接続されてもよい。ハンディ端末1、伝票プリンタ3、POS端末4及び無線アクセスポイント6は、
図1においては1つずつのみを示すが、複数台を含んでいてもよく、その数はそれぞれに任意である。LAN5は、ルータ7を介して通信ネットワーク40に接続されている。ルータ7は、LAN5と通信ネットワーク40とを相互接続する。注文管理装置2は、本部又はデータセンタ等の店舗外に設けられてもよい。
【0010】
ハンディ端末1は、店員によって操作される端末装置であり、例えば当該店舗に来店した客から受けた注文に関するデータが入力される。ハンディ端末1は、例えば注文された飲食物を識別するメニューコード、当該飲食物を注文した客の席を識別するテーブル番号等を無線送信する。ハンディ端末1から無線送信されたメニューコード等は、無線アクセスポイント6及びLAN5を介して注文管理装置2に伝送される。
【0011】
注文管理装置2は、例えば店舗のバックヤードに設置される。注文管理装置2は、ハンディ端末1から送信されたメニューコード等に基づいて注文データを生成し、管理する。また、注文管理装置2は、受注サーバ20から送られた注文データも管理する。
【0012】
伝票プリンタ3は、注文内容を調理人に通知するための調理伝票をプリントする。このため伝票プリンタ3は、典型的には調理場に設置されるのであり、キッチンプリンタと称されることもある。伝票プリンタ3に代えて、あるいは伝票プリンタ3に加えて、注文内容を調理人に通知するための画面表示を行うキッチンディスプレイが用いられてもよい。
【0013】
POS端末4は、例えば店舗のチェックアウトカウンタに設置され、注文データに基づき、客への飲食物提供に関する代金を決済し、店舗で提供した商品の売上データや販売データ等を管理する。
【0014】
受注サーバ20は、店舗システム10が設けられている店舗における飲食物提供に関する注文を、情報端末30からの客の指示に応じて受け付ける。つまり受注サーバ20は、客が店舗に出向くのに先立っての注文を受け付ける。このような注文を以下においては、事前注文と称することとする。受注サーバ20の管理運営は、複数の異なった店舗からそれぞれの事前注文サービスの提供依頼を受けた第三者が行う。受注サーバ20は、事前注文サービスを提供する各店舗で事前注文を受けることが可能な品物のリストを店舗ごとに記憶、管理している。なお、上記のリストは、メニュー名及び単価等を表す。
【0015】
情報端末30は、来店予定客が自由に操作することができるものであり、スマートフォン、タブレット端末、あるいはその他のタイプのコンピュータ端末などのような、通信ネットワーク40を介してのデータ通信が可能な任意の端末である。情報端末30は、事前注文のための受注サーバ20が提供するサービスを利用するためのアプリケーションプログラムがインストールされているものとする。
【0016】
通信ネットワーク40は、典型的には、移動体通信網とインターネットとを組み合わせたものである。しかしながら通信ネットワーク40は、例えば無線LANとVPN(virtual private network)とを組み合わせたものなど、他のどのようなものであってもよい。
【0017】
図2は注文管理装置2の要部構成を示すブロック図である。
注文管理装置2は、プロセッサ21、メインメモリ22、補助記憶デバイス23、通信インタフェース24及び伝送路であるバス25を含む。この注文管理装置2は、例えば汎用のサーバ装置を用いて実現することができる。
【0018】
注文管理装置2においては、プロセッサ21、メインメモリ22及び補助記憶デバイス23をバス25によって接続することにより、注文管理装置2を制御するコンピュータを構成する。
【0019】
プロセッサ21は、上記コンピュータの中枢部分に相当する。プロセッサ21は、オペレーティングシステムやアプリケーションプログラムに従って、注文管理装置2としての各種の機能を実現するべく各部を制御する。
【0020】
メインメモリ22は、上記コンピュータの主記憶部分に相当する。メインメモリ22は、不揮発性のメモリ領域と揮発性のメモリ領域とを含む。メインメモリ22は、不揮発性のメモリ領域ではオペレーティングシステムやアプリケーションプログラムを記憶する。またメインメモリ22は、プロセッサ21が各種の情報処理を実行する上で必要なデータを不揮発性または揮発性のメモリ領域で記憶する場合もある。メインメモリ22は、揮発性のメモリ領域を、プロセッサ21によってデータが適宜書き換えられるワークエリアとして使用する。
【0021】
補助記憶デバイス23は、上記コンピュータの補助記憶部分に相当する。補助記憶デバイス23は、例えばEEPROM(electric erasable programmable read-only memory)、HDD(hard disc drive)、SSD(solid state drive)などである。補助記憶デバイス23は、プロセッサ21が各種の情報処理を行う上で使用するデータや、プロセッサ21での処理によって生成されたデータを保存する。補助記憶デバイス23は、上記のアプリケーションプログラムを記憶する場合もある。
【0022】
補助記憶デバイス23が記憶するアプリケーションプログラムの1つは、注文データの管理のための後述する情報処理について記述したプログラムである注文管理アプリ23aである。また補助記憶デバイス23の記憶領域の一部は、注文データを記憶するための注文データ領域23bとして利用される。注文データ領域23bは、複数の注文データを記憶可能である。
【0023】
注文管理装置2のハードウェアと、当該ハードウェア上で実行される注文データの管理等の所定の情報処理の手順である注文管理アプリ23aとは、同じ事業者が注文管理装置2の使用者に譲渡しても良いし、異なった事業者がそれぞれ個別に譲渡しても良い。注文管理装置2のハードウェアと注文管理アプリ23aとを同じ事業者が注文管理装置2の使用者に譲渡する場合、注文管理アプリ23aは、一般的には注文管理装置2のハードウェアであるメインメモリ22や補助記憶デバイス23に記憶された状態で譲渡される。しかしながら、このような譲渡の場合であったとしても、注文管理アプリ23aは、注文管理装置2のハードウェアであるメインメモリ22や補助記憶デバイス23に記憶された状態である必然性はない。例えば注文管理装置2のハードウェアでない、磁気ディスク、光磁気ディスク、光ディスク、半導体メモリなどのようなリムーバブルな記録媒体に記録された状態で譲渡されても良いし、あるいはネットワーク資源からダウンロードにより譲渡されても良い。
【0024】
通信インタフェース24は、LAN5を介したデータ通信のインタフェースである。
【0025】
図3は注文データ領域23bに記憶される注文データの構成例を模式的に示す図である。
図3に示すように注文データは、伝票番号、テーブル番号、注文通番、メニューコード、数量、単価、ステータス、事前注文フラグ及び決済フラグを含む。なお注文データは、例えば注文された日時などの別の情報を含んでいてもよい。また注文データは、例えば単価などの一部の情報を含まなくてもよい。
【0026】
伝票番号は、一括での決済の対象となる複数の注文に共通して割り当てられ、かつ別の決済の対象となる注文とは別に割り当てられる番号である。テーブル番号は上記の店舗において客が利用するテーブルに割り当てられた番号である。注文通番は、同じ伝票番号が割り当てられた複数の注文の個々に割り当てられる番号である。メニューコードは、注文の対象となった飲食物を識別するコードである。数量は、上記のメニューコードで識別される飲食物の注文数である。単価は、上記のメニューコードで識別される飲食物の1つ当たりの価格である。ステータスは、当該注文データが表す注文への対応状況を表す。事前注文フラグは、該当する注文が事前注文であるか否かを表すフラグである。本実施形態において事前注文フラグは、セット状態であるときに事前注文であることを示すこととする。決済フラグは、事前注文の際に決済が終了しているか否かを表すフラグである。本実施形態において決済フラグは、セット状態であるときに決済が終了していることを示すこととする。事前注文の際に決済可能な決済種別は、例えばクレジットカード決済である。事前注文の際に決済が行われる場合には、各店舗の代わりに、受注サーバ20を管理運営する、あるいは事前注文サービスを店舗に提供する第三者がクレジットカード決済を代行する。したがって、事前注文の際に決済が終了している飲食物の代金は、受注サーバ20を管理運営する、或いは事前注文サービスを店舗に提供する第三者から、後日、振込等で各店舗へ支払われる。
【0027】
次に以上のように構成された注文管理装置2の動作について説明する。
プロセッサ21は、注文管理装置2が注文の管理を行うべき通常の動作状態にあるときには、注文管理アプリ23aに従って注文管理のための情報処理を実行する。
【0028】
図4及び
図5はプロセッサ21による情報処理のフローチャートである。なお、以下に説明する処理の内容は一例であって、同様な結果を得ることが可能な様々な処理を適宜に利用できる。例えば、一部の動作は、その順番を入れ替えることができる。また、一部の動作は、省略することもできるし、別の動作を追加して実行することもできる。
【0029】
Act1としてプロセッサ21は、新規の注文が発生したか否かを確認する。そしてプロセッサ21は、新規の注文が発生していないならばNoと判定し、Act2へと進む。
Act2としてプロセッサ21は、調理が終了したか否かを確認する。そしてプロセッサ21は、調理が終了していないならばNoと判定し、Act3へと進む。
Act3としてプロセッサ21は、調理済みの飲食物の客への提供が終了したか否かを確認する。そしてプロセッサ21は、提供が終了していないならばNoと判定し、Act4へと進む。
Act4としてプロセッサ21は、後述する店舗決済が終了したか否かを確認する。そしてプロセッサ21は、店舗決済が終了していないならばNoと判定し、Act5へと進む。
Act5としてプロセッサ21は、伝票番号が照会されたか否かを確認する。そしてプロセッサ21は、伝票番号が照会されていないならばNoと判定し、Act6へと進む。
Act6としてプロセッサ21は、注文のキャンセルが指示されたか否かを確認する。そしてプロセッサ21は、当該指示がなされていないならばNoと判定し、Act1へと戻る。
かくしてプロセッサ21はAct1-Act6としては、新規注文、調理終了、提供終了、店舗決済終了、伝票番号照会及びキャンセル指示のいずれかのイベントが生じるのを待ち受ける。
【0030】
店舗内又は店頭における客の注文は、店員により聞き取られた上で、当該店員による操作によってハンディ端末1に入力される。そうするとハンディ端末1は、上記の操作に従って受注データを生成し、無線アクセスポイント6及びLAN5を介して注文管理装置2へと送信する。ハンディ端末1は、伝票番号、テーブル番号及びメニューコードを受注データに少なくとも含める。なおハンディ端末1は、同一の伝票番号に関する注文として複数の飲食物が注文される場合、それら複数のメニューコードを個々に含んだ複数の受注データを順次に送信してもよいし、複数のメニューコードを含んだ1つの受注データを送信してもよい。
【0031】
一方、受注サーバ20が提供するサービスを利用して事前注文する客は、情報端末30で専用のアプリケーションを起動し、情報端末30における操作により注文を行う。例えば、客は、起動させた専用アプリケーションにおいて、事前注文しようとする店舗を指定し、当該店舗が事前注文を受け付ける飲食物のメニューの中から、自分が注文したい飲食物を選択する。受注サーバ20は、この注文の内容を示した受注データを生成し、注文管理装置2に宛てて通信ネットワーク40へと送出する。受注サーバ20は、店舗のテーブルに割り当てられたテーブル番号とは重複しないように予め定められたテーブル番号を受注データに含める。受注サーバ20は、事前注文を行う客がクレジットによる支払いを要求したならば、クレジット決済を行う。受注サーバ20は、事前注文を行う客が、飲食物の受け取り時に決済することを要求したならば、決済を行わない。そして受注サーバ20は、決済済みであるか否かを表す決済情報を受注データに含める。この受注データの通信を始めとする注文管理装置2と受注サーバ20との間の通信には、例えばソケット通信が利用できる。受注サーバ20は、受注データをデータ送信先の注文管理装置2で取り扱われる注文データに適合させた形式に変換し、注文管理装置2に送信している。
【0032】
受注データがLAN5により注文管理装置2へと伝送されると、この受注データを通信インタフェース24が受信する。そしてこれに応じてプロセッサ21は、新規の注文が発生したとしてAct1にてYesと判定し、Act7へと進む。
【0033】
Act7としてプロセッサ21は、上記の受信された受注データに基づく新たな注文データを注文データ領域23bに追加する。プロセッサ21は具体的には、通信インタフェース24により受信された受注データを通信インタフェース24から取得する。ここに注文管理アプリ23aに基づく情報処理をプロセッサ21が実行することによって、プロセッサ21を中枢部分とするコンピュータは取得手段として機能する。そしてプロセッサ21は、伝票番号、テーブル番号、注文通番、メニューコード、数量及び単価に関しては、取得した受注データの内容を反映した注文データを生成する。なおプロセッサ21は、当該注文データにおけるステータスとしては、「受注済み」をセットする。またプロセッサ21は、当該注文データにおける事前注文フラグ及び決済フラグは初期状態としてリセット状態とする。
【0034】
Act8としてプロセッサ21は、調理伝票をプリントするように伝票プリンタ3に指示する。
Act9としてプロセッサ21は、今回の注文が事前注文であるか否かを確認する。そしてプロセッサ21は、今回受信された受注データが受注サーバ20から送信されたものであるならばYesと判定し、Act10へと進む。
【0035】
Act10としてプロセッサ21は、上記の追加した注文データにおける事前注文フラグをセットする。
Act11としてプロセッサ21は、受注データに含まれた決済情報に基づいて決済フラグを設定する。つまりプロセッサ21は、決済情報が決済済みを示すならば決済フラグをセット状態とし、そうでなければ決済フラグをリセット状態とする。
Act12としてプロセッサ21は、受注データを受けた旨の通知を受注サーバ20に対して行う。そしてプロセッサ21はこののち、Act1-Act6の待受状態に戻る。
【0036】
なおプロセッサ21は、今回受信された受注データがハンディ端末1から送信されたものであるならばAct9にてNoと判定し、Act10-Act12をパスしてAct1-Act6の待受状態に戻る。この場合、今回追加した注文データにおける事前注文フラグ及び決済フラグは、リセット状態のままとされる。かくしてプロセッサ21は、店舗内で受け付けられた注文に関する注文データと、店舗外からの注文に関する注文データとを、店舗外からの注文に関するものを事前注文フラグにより識別可能に、注文データ領域23bを利用して管理していることになる。つまり、注文管理アプリ23aに基づく情報処理をプロセッサ21が実行することによって、プロセッサ21を中枢部分とするコンピュータは管理手段として機能する。
【0037】
調理人は、上記のようにプリントされた調理伝票に基づいて注文内容を確認し、注文されている飲食物を調理する。そして調理を終了したならば、調理人又は別の店員は、どの注文に対する調理であるかの通知を伴って、調理の終了を注文管理装置2へと通知する。この通知は例えば、ハンディ端末1又は図示しない別の端末から、調理人又は別の店員の操作に応じて行われる。そしてプロセッサ21は、このように調理終了が通知されたならばAct2にてYesと判定し、Act13へと進む。
Act13としてプロセッサ21は、調理が終了した注文に関する注文データにおけるステータスを「調理終了」に変更する。
【0038】
Act14としてプロセッサ21は、調理が終了した注文に関する注文データにおける事前注文フラグに基づき、該当する注文が事前注文であるか否かを確認する。そしてプロセッサ21は、事前注文であるならばYesと判定し、Act15へと進む。
【0039】
Act15としてプロセッサ21は、受注サーバ20に対して、調理終了通知を行う。そしてプロセッサ21はこののち、Act1-Act6の待受状態に戻る。なおプロセッサ21は、該当する注文が事前注文ではないならばAct14にてNoと判定し、Act15をパスしてAct1-Act6の待受状態に戻る。
【0040】
店内又は店頭での注文に関する調理が終了したのであるならば、調理人は、調理済みの飲食物を、接客を担当する店員に対して引き渡す。当該店員は、当該飲食物を客に提供する。そして店員は、このように提供を終了したならば、どの注文に対する飲食物の提供であるかの通知を伴って、提供の終了を注文管理装置2へと通知する。この通知は例えば、ハンディ端末1又は図示しない別の端末から、店員の操作に応じて行われる。そしてプロセッサ21は、このように提供終了が通知されたならばAct3にてYesと判定し、Act16へと進む。
【0041】
Act16としてプロセッサ21は、提供が終了した注文に関する注文データにおけるステータスを「提供終了」に変更する。そしてプロセッサ21はこののち、Act1-Act6の待受状態に戻る。
【0042】
店内又は店頭での注文に関する決済を客が店員に申し出ると、店員はPOS端末4を操作して、注文に関する代金の決済を客に行わせる。この代金の決済として選択可能な決済種別は、当該店舗で決済可能なものである。当該店舗での決済可能な決済種別の中に、クレジット決済が含まれている場合には、受注サーバ20を管理運営する、或いは事前注文サービスを店舗に提供する第三者ではなく、当該店舗がクレジット決済を行なう。そして決済が終了したならばPOS端末4は、どの注文に関する決済であるかの通知を伴って、決済の終了を注文管理装置2へと通知する。そしてプロセッサ21は、このように決済終了が通知されたならばAct4にてYesと判定し、Act17へと進む。
Act17としてプロセッサ21は、決済が終了した注文に関する注文データにおけるステータスを「決済終了」に変更する。そしてプロセッサ21はこののち、Act1-Act6の待受状態に戻る。
【0043】
受注サーバ20は、前述の調理終了通知を受けると、情報端末30に対して調理の完了をプッシュ通知する。あるいは受注サーバ20は、調理の完了を通知するための電子メールを、上記の調理が完了した注文に関して通知先として定められたアドレスに宛てて送信する。客は、このプッシュ通知又は電子メールにより調理の完了を認識したならば、店舗へと出向く。そして客は、上記の調理が終了した飲食物の注文に関する伝票番号をハンディ端末1又はPOS端末4に入力するよう、店員に要求する。これは、客が口頭で伝票番号を伝えるのであってもよいし、伝票番号を示したコードシンボルを専用のアプリケーションの機能により情報端末30に表示させて提示するのであってもよい。そして店員は、キー入力又はスキャナ入力によって、伝票番号をハンディ端末1又はPOS端末4に入力する。ハンディ端末1又はPOS端末4は、入力された伝票番号を、注文管理装置2に照会する。
【0044】
このように伝票番号の照会を受けるとプロセッサ21は、Act5にてYesと判定し、
図5中のAct18へと進む。
Act18としてプロセッサ21は、照会元の端末に対して、提供確認画面の表示を指示する。提供確認画面は、客が提供を受けようとしているのがどの注文に関する飲食物であるかを表すとともに、その飲食物の提供が終了したことの確認操作を店員に行わせるための画面である。店員は、この提供確認画面に基づいて飲食物を客に提供する。そして予め定められた確認操作を、ハンディ端末1又はPOS端末4にて行う。ハンディ端末1又はPOS端末4は、このように確認操作が行われたならば、その旨を注文管理装置2に通知する。
【0045】
Act19としてプロセッサ21は、上記の確認操作が行われるのを待ち受ける。そしてプロセッサ21は、上記のように確認操作が行われたことが通知されたならばYesと判定し、Act20へと進む。
【0046】
Act20としてプロセッサ21は、上記のように飲食物の提供が終了した注文についての決済が完了しているか否か、決済フラグに基づいて確認する。そしてプロセッサ21は、決済が終了していないならばNoと判定し、Act21へと進む。
Act21としてプロセッサ21は、POS端末4に対して、決済を指示する。
【0047】
POS端末4は、上記の指示と、店員による操作とに応じて決済のための処理を行う。このときに行なう決済は、店内又は店頭での注文に関する決済と同じである。そしてPOS端末4は、決済を終了したならば、その旨を注文管理装置2に通知する。
【0048】
Act22としてプロセッサ21は、決済が終了するのを待ち受ける。そしてプロセッサ21は、上記のようにPOS端末4から決済の終了が通知されたならばYesと判定し、Act23へと進む。
Act23としてプロセッサ21は、受注サーバ20に対して、決済終了通知を行う。
Act24としてプロセッサ21は、決済が終了した注文に関する注文データにおけるステータスを「決済終了」に変更する。そしてプロセッサ21はこののち、
図4中のAct1-Act6の待受状態に戻る。
【0049】
プロセッサ21は、事前注文の受け付けの際に受注サーバ20にて決済が終了しているならばAct20にてYesと判定し、Act25へと進む。
Act25としてプロセッサ21は、受注サーバ20に対して、提供終了通知を行う。
Act26としてプロセッサ21は、提供が終了した注文に関する注文データにおけるステータスを「提供終了」に変更する。そしてプロセッサ21はこののち、
図5中のAct1-Act6の待受状態に戻る。
【0050】
客は、事前注文を飲食物の提供を受ける前にキャンセルしたい場合には、例えば電話などによって店員に対してその旨を申し出る。店員は、調理の状況などを確認し、キャンセルすることが可能であるかどうかを判断する。そして店員は、キャンセルすることが可能であると判断したならば、キャンセル対象の注文の指定を伴って、キャンセルを指示する操作をハンディ端末1又はPOS端末4にて行う。ハンディ端末1又はPOS端末4は、このように操作が行われたならば、注文管理装置2にキャンセル対象の注文の通知を伴ってキャンセルを要求する。プロセッサ21は、この要求を受けると
図4中のAct6にてYesと判定し、
図5中のAct27へと進む。
【0051】
Act27としてプロセッサ21は、キャンセル要求元の端末に対して、キャンセル確認画面の表示を指示する。キャンセル確認画面は、キャンセルの対象がどの注文であるかを表すとともに、キャンセルの実行の指示を店員に行わせるための画面である。店員は、このキャンセル確認画面に基づいて、本当にキャンセルするかどうかを確認し、キャンセルする場合には実行を指示するための操作をハンディ端末1又はPOS端末4にて行う。ハンディ端末1又はPOS端末4は、このように実行を指示する操作が行われたならば、その旨を注文管理装置2に通知する。
【0052】
Act28としてプロセッサ21は、上記の通知が行われるのを待ち受ける。そしてプロセッサ21は、上記のように実行を指示する操作が行われたことが通知されたならばYesと判定し、Act29へと進む。なお、図示は省略しているが、キャンセルの取り止めを指定する操作が店員により行われた場合にも、ハンディ端末1又はPOS端末4はその旨を注文管理装置2に通知する。そしてこの場合にはプロセッサ21は、以降に説明する処理をパスして
図4中のAct1-Act6の待受状態に戻る。
【0053】
Act29としてプロセッサ21は、キャンセルの対象となっている注文が事前注文であるか否かを確認する。そしてプロセッサ21は、事前注文であるならばYesと判定し、Act30へと進む。
【0054】
Act30としてプロセッサ21は、受注サーバ20に対して、キャンセル対象となっている注文の伝票番号の通知を伴って、キャンセル通知を行う。なおプロセッサ21は、キャンセルの対象が事前注文ではないならばAct29にてNoと判定し、このAct30をパスしてAct31へと進む。
【0055】
Act31としてプロセッサ21は、キャンセルした注文に関する注文データにおけるステータスを「キャンセル」に変更する。そしてプロセッサ21はこののち、
図5中のAct1-Act6の待受状態に戻る。なお、このときにプロセッサ21は、キャンセルした注文に関する注文データを注文データ領域23bから削除してもよい。
【0056】
以上に説明したプロセッサ21の処理のうち、Act12、Act15、Act23、Act25及びAct30については、事前注文に関する受け付け、調理、決済、提供、あるいはキャンセルの各処理の終了を受注サーバ20に対して通知する処理である。つまりプロセッサ21は、店舗外からの注文に関する処理が終了したことを、予め定められた通知先としての受注サーバ20へと通知する。かくして注文管理アプリ23aに基づく情報処理をプロセッサ21が実行することによって、プロセッサ21を中枢部分とするコンピュータは、そのような通知を行う通知手段として機能する。
【0057】
以上のように注文管理装置2においては、店舗内で受け付けられた注文と、店舗外から受注サーバ20により受け付けられた事前注文とのうち、店舗外からの事前注文については、それに関する処理が終了したことに応じて、その旨を受注サーバ20に通知する。これにより、事前注文に関するサービスについては受注サーバ20との連携により提供することが可能でありながら、その事前注文と店舗内で受け付けられた注文とを統一的に取り扱うことが可能である。
【0058】
また注文管理装置2によれば、事前注文に関する受け付け、調理、決済、提供、あるいはキャンセルの各処理の終了を受注サーバ20に対して通知している。このため、飲食物を、客の注文に応じて調理した上で、店舗において客に提供する業態における注文管理を適切に行える。
【0059】
この実施形態は、次のような種々の変形実施が可能である。
受注サーバ20への通知は、受け付け、調理、決済、提供及びキャンセルの全てに関して必須な訳ではなく、それらのうちの一部の通知のみを行ってもよい。例えば、店舗での決済については受注サーバ20では管理しないのであれば、決済の終了を通知しなくてもよい。また、例えば、上記の処理とは別の任意の処理の終了を通知してもよい。
【0060】
何らかの処理を伴う注文であれば、どのような注文を管理する場合であっても上記実施形態の技術的思想の下に実施が可能である。この場合、通知の対象とする処理についても、管理する注文に適応したものとする。例えば、ネットスーパーにおける店頭受け取りサービスに関する注文を管理するのであれば、「調理」に代えて「受け渡し準備」の終了に関する通知を行うことが想定される。
【0061】
販売データを管理する機能を注文管理装置2に備えてもよい。この場合に注文管理装置2は、店内又は店頭で注文を受けた飲食物の代金と、第三者が管理運営する事前注文サービスで注文を受けた飲食物の代金とは、別々に集計してもよい。そしてこの場合に注文管理装置2は、それらの代金をそれぞれ区別して確認することを可能とするレポートを出力する。また注文管理装置2は、第三者が管理運営する事前注文サービスで注文を受けた飲食物の代金は、事前注文の際に決済が終了している場合と、事前注文の際に決済が終了しておらず、店舗で決済を行なった場合とで分けて集計してもよい。そしてこの場合に注文管理装置2は、それらの代金をそれぞれ区別して確認することを可能とするレポートを出力する。また注文管理装置2は、事前注文を受けながらもキャンセルされた注文の明細及び、事前決済済み金額又は事前決済なし金額等の合計金額を集計し、レポート出力してもよい。これらのレポートは、事前注文サービスを当該店舗に提供している第三者との決済時に確認用として、あるいは請求支払処理のデータとして利用できる。なお、各レポートの出力は、紙媒体への印刷又は、記憶媒体への記憶等の任意の形態であってよい。
【0062】
受注サーバ20は、情報端末30での注文操作を受け付けるためのGUI(graphical user interface)画面を情報端末30で表示させるためのWebページを情報端末30に与えるようにしてもよい。そして受注サーバ20は、GUI画面における客の操作に基づいて事前注文を受け付けるようにする。そうすれば、情報端末30は、上記のWebページを閲覧するための汎用の閲覧アプリケーションを備えていれば良く、事前注文のための受注サーバが提供するサービスを利用するための専用のアプリケーションプログラムを必要としない。
【0063】
制御処理によりプロセッサ21が実現する各機能は、その一部または全てをロジック回路などのようなプログラムに基づかない情報処理を実行するハードウェアにより実現することも可能である。また上記の各機能のそれぞれは、上記のロジック回路などのハードウェアにソフトウェア制御を組み合わせて実現することも可能である。
【0064】
本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。
以下に、本願の当初の特許請求の範囲に記載された発明を付記する。
[付記1] 店舗内で受け付けられた注文に関する注文データと、店舗外からの注文に関する注文データとを、店舗外からの注文に関するものを識別可能に管理する管理手段と、
前記注文データに関する処理が終了したことに応じて、該当する注文データが店舗外からの注文に関するとして前記管理手段により管理されているならば、予め定められた通知先へと前記処理の終了を通知する通知手段と、を具備する注文管理装置。
[付記2] 店舗外からの注文に関する前記注文データを、店舗外からの注文を受け付けて注文データを生成する受注サーバから取得する取得手段、をさらに備え、
前記通知手段は、前記処理の終了を前記受注サーバに対して通知する、
付記1に記載の注文管理装置。
[付記3] 前記通知手段は、前記注文に関する注文者への対応のための準備が終了したことを通知する、付記1又は付記2に記載の注文管理装置。
[付記4] 前記通知手段は、前記注文に関する注文者への対応が終了したことを通知する、付記1-付記3のいずれか一項に記載の注文管理装置。
[付記5] 前記通知手段は、前記注文に関する決済が終了したことを通知する、付記1-付記4のいずれか一項に記載の注文管理装置。
[付記6] 注文管理装置に備えられたコンピュータを、
店舗内で受け付けられた注文に関する注文データと、店舗外からの注文に関する注文データとを、店舗外からの注文に関するものを識別可能に管理する管理手段と、
前記注文データに関する処理が終了したことに応じて、該当する注文データが店舗外からの注文に関するとして前記管理手段により管理されているならば、予め定められた通知先へと前記処理の終了を通知する通知手段と、して機能させるためのプログラム。
【符号の説明】
【0065】
1…ハンディ端末、2…注文管理装置、3…伝票プリンタ、4…POS端末、5…LAN、6…無線アクセスポイント、7…ルータ、10…店舗システム、20…受注サーバ、21…プロセッサ、22…メインメモリ、23…補助記憶デバイス、23a…注文管理アプリ、23b…注文データ領域、24…通信インタフェース、25…バス、30…情報端末、40…通信ネットワーク。