JP2022050649A - 注文管理装置及びそのプログラム - Google Patents

Abstract

【課題】店舗内で受け付けられた注文と、店舗外からの注文とを識別可能な状態で統一的に取り扱う注文管理装置及びそのプログラムを提供する。【解決手段】注文管理装置は、管理手段及び通知手段として機能するプロセッサを中枢部分とするコンピュータを備える。管理手段は、店舗内で受け付けられた注文に関する注文データと、店舗外からの注文に関する注文データとを、店舗外からの注文に関するものを識別可能に管理する。通知手段は、注文データに関する処理が終了したことに応じて、該当する注文データが店舗外からの注文に関するとして管理手段により管理されているならば、予め定められた通知先へと処理の終了を通知する。【選択図】図４

Description

本発明の実施形態は、注文管理装置及びそのプログラムに関する。

近年、来店予定客が来店前に自身の情報通信端末を操作することで、来店時に提供される品物の注文を行えるサービスが提供されている。このようなサービスは、例えば飲食店を営む店舗が提供している。この種のサービスは、通常、自店舗の既存システムに当該サービスに対応する機能を新たに追加することで、提供されている。しかしながら、このような機能を独自に追加、構築するのはコストが係るので、自店舗の既存システムに取り込むのでなく、第三者から提供される当該サービスを併用することが多くなっている。このように第三者から提供されるサービスを既存システムと併用している店舗においては、当該サービスを提供している第三者が管理運営しているサーバに、タブレット端末など既存システムから独立した情報端末を用いてアクセスし、来店予定客からの注文の内容を確認することになるので、注文の管理が煩雑になる。
そこで、ＰＯＳ（point-of-sale）システムなどのような商品販売データ管理装置に接続された、旧来からの既存の受注管理システムでの注文データと同じように、第三者が提供する上記サービスのデータを利用することができるように、データ変換するものが考えられている。
しかしながら、単に注文データの形式を既存の受注管理システムのものに変換しただけでは、第三者から提供されたサービスを介して受けた注文の調理や商品提供を、当該店舗で直接受け付けた注文のものと同じように行えるようになるだけであり、当該店舗における商品販売のデータ処理を適切に行うには不十分である。したがって、第三者から提供されたサービスを介して受けた注文に係る商品販売のデータ処理と、当該店舗で直接受け付けた注文に係る商品販売のデータ処理とを適切に取り扱えるものが望まれていた。
そのためには、注文管理装置において、店舗で直接受け付けられた注文と、店舗外から間接的に受け付けた注文とを識別可能な状態で統一的に取り扱えると都合が良い。

特開２０１５－３２１２２号公報

本発明が解決しようとする課題は、店舗で直接受け付けた注文と、店舗外から間接的に受け付けた注文とを識別可能名状態で統一的に取り扱えることを可能とする注文管理装置及びそのプログラムを提供することである。

実施形態の注文管理装置は、管理手段及び通知手段を備える。管理手段は、店舗内で受け付けられた注文に関する注文データと、店舗外からの注文に関する注文データとを、店舗外からの注文に関するものを識別可能に管理する。通知手段は、注文データに関する処理が終了したことに応じて、該当する注文データが店舗外からの注文に関するとして管理手段により管理されているならば、予め定められた通知先へと処理の終了を通知する。

一実施形態に係る注文管理装置が適用されるシステムの概略構成を示す図。 図１中の注文管理装置の要部構成を示すブロック図。 図２中の注文データ領域に記憶される注文データの構成例を模式的に示す図。 図２中のプロセッサによる情報処理のフローチャート。 図２中のプロセッサによる情報処理のフローチャート。

以下、実施の形態の一例について図面を用いて説明する。なお、本実施の形態では、飲食物を、客の注文に応じて調理した上で来店客に提供する店舗での注文管理を行う注文管理装置を例に説明する。なお、この種の装置は、オーダーステーションとも称される。

図１は本実施形態に係る注文管理装置が適用されるシステムの概略構成を示す図である。
このシステムは、店舗システム１０、受注サーバ２０及び情報端末３０を含む。そして店舗システム１０及び情報端末３０と受注サーバ２０とは、それぞれ通信ネットワーク４０を介して通信可能とされている。

店舗システム１０は、上記の店舗に設けられるもので、ハンディ端末１、注文管理装置２、伝票プリンタ３及びＰＯＳ端末４を、ＬＡＮ（local area network）５にそれぞれ接続して構成される。ただし、ハンディ端末１は、無線アクセスポイント６を介してＬＡＮ５に接続される。注文管理装置２、伝票プリンタ３及びＰＯＳ端末４についても、無線アクセスポイント６を介してＬＡＮ５に接続されてもよい。ハンディ端末１、伝票プリンタ３、ＰＯＳ端末４及び無線アクセスポイント６は、図１においては１つずつのみを示すが、複数台を含んでいてもよく、その数はそれぞれに任意である。ＬＡＮ５は、ルータ７を介して通信ネットワーク４０に接続されている。ルータ７は、ＬＡＮ５と通信ネットワーク４０とを相互接続する。注文管理装置２は、本部又はデータセンタ等の店舗外に設けられてもよい。

ハンディ端末１は、店員によって操作される端末装置であり、例えば当該店舗に来店した客から受けた注文に関するデータが入力される。ハンディ端末１は、例えば注文された飲食物を識別するメニューコード、当該飲食物を注文した客の席を識別するテーブル番号等を無線送信する。ハンディ端末１から無線送信されたメニューコード等は、無線アクセスポイント６及びＬＡＮ５を介して注文管理装置２に伝送される。

注文管理装置２は、例えば店舗のバックヤードに設置される。注文管理装置２は、ハンディ端末１から送信されたメニューコード等に基づいて注文データを生成し、管理する。また、注文管理装置２は、受注サーバ２０から送られた注文データも管理する。

伝票プリンタ３は、注文内容を調理人に通知するための調理伝票をプリントする。このため伝票プリンタ３は、典型的には調理場に設置されるのであり、キッチンプリンタと称されることもある。伝票プリンタ３に代えて、あるいは伝票プリンタ３に加えて、注文内容を調理人に通知するための画面表示を行うキッチンディスプレイが用いられてもよい。

ＰＯＳ端末４は、例えば店舗のチェックアウトカウンタに設置され、注文データに基づき、客への飲食物提供に関する代金を決済し、店舗で提供した商品の売上データや販売データ等を管理する。

受注サーバ２０は、店舗システム１０が設けられている店舗における飲食物提供に関する注文を、情報端末３０からの客の指示に応じて受け付ける。つまり受注サーバ２０は、客が店舗に出向くのに先立っての注文を受け付ける。このような注文を以下においては、事前注文と称することとする。受注サーバ２０の管理運営は、複数の異なった店舗からそれぞれの事前注文サービスの提供依頼を受けた第三者が行う。受注サーバ２０は、事前注文サービスを提供する各店舗で事前注文を受けることが可能な品物のリストを店舗ごとに記憶、管理している。なお、上記のリストは、メニュー名及び単価等を表す。

情報端末３０は、来店予定客が自由に操作することができるものであり、スマートフォン、タブレット端末、あるいはその他のタイプのコンピュータ端末などのような、通信ネットワーク４０を介してのデータ通信が可能な任意の端末である。情報端末３０は、事前注文のための受注サーバ２０が提供するサービスを利用するためのアプリケーションプログラムがインストールされているものとする。

通信ネットワーク４０は、典型的には、移動体通信網とインターネットとを組み合わせたものである。しかしながら通信ネットワーク４０は、例えば無線ＬＡＮとＶＰＮ（virtual private network）とを組み合わせたものなど、他のどのようなものであってもよい。

図２は注文管理装置２の要部構成を示すブロック図である。
注文管理装置２は、プロセッサ２１、メインメモリ２２、補助記憶デバイス２３、通信インタフェース２４及び伝送路であるバス２５を含む。この注文管理装置２は、例えば汎用のサーバ装置を用いて実現することができる。

注文管理装置２においては、プロセッサ２１、メインメモリ２２及び補助記憶デバイス２３をバス２５によって接続することにより、注文管理装置２を制御するコンピュータを構成する。

プロセッサ２１は、上記コンピュータの中枢部分に相当する。プロセッサ２１は、オペレーティングシステムやアプリケーションプログラムに従って、注文管理装置２としての各種の機能を実現するべく各部を制御する。

メインメモリ２２は、上記コンピュータの主記憶部分に相当する。メインメモリ２２は、不揮発性のメモリ領域と揮発性のメモリ領域とを含む。メインメモリ２２は、不揮発性のメモリ領域ではオペレーティングシステムやアプリケーションプログラムを記憶する。またメインメモリ２２は、プロセッサ２１が各種の情報処理を実行する上で必要なデータを不揮発性または揮発性のメモリ領域で記憶する場合もある。メインメモリ２２は、揮発性のメモリ領域を、プロセッサ２１によってデータが適宜書き換えられるワークエリアとして使用する。

補助記憶デバイス２３は、上記コンピュータの補助記憶部分に相当する。補助記憶デバイス２３は、例えばＥＥＰＲＯＭ（electric erasable programmable read-only memory）、ＨＤＤ（hard disc drive）、ＳＳＤ（solid state drive）などである。補助記憶デバイス２３は、プロセッサ２１が各種の情報処理を行う上で使用するデータや、プロセッサ２１での処理によって生成されたデータを保存する。補助記憶デバイス２３は、上記のアプリケーションプログラムを記憶する場合もある。

補助記憶デバイス２３が記憶するアプリケーションプログラムの１つは、注文データの管理のための後述する情報処理について記述したプログラムである注文管理アプリ２３ａである。また補助記憶デバイス２３の記憶領域の一部は、注文データを記憶するための注文データ領域２３ｂとして利用される。注文データ領域２３ｂは、複数の注文データを記憶可能である。

注文管理装置２のハードウェアと、当該ハードウェア上で実行される注文データの管理等の所定の情報処理の手順である注文管理アプリ２３ａとは、同じ事業者が注文管理装置２の使用者に譲渡しても良いし、異なった事業者がそれぞれ個別に譲渡しても良い。注文管理装置２のハードウェアと注文管理アプリ２３ａとを同じ事業者が注文管理装置２の使用者に譲渡する場合、注文管理アプリ２３ａは、一般的には注文管理装置２のハードウェアであるメインメモリ２２や補助記憶デバイス２３に記憶された状態で譲渡される。しかしながら、このような譲渡の場合であったとしても、注文管理アプリ２３ａは、注文管理装置２のハードウェアであるメインメモリ２２や補助記憶デバイス２３に記憶された状態である必然性はない。例えば注文管理装置２のハードウェアでない、磁気ディスク、光磁気ディスク、光ディスク、半導体メモリなどのようなリムーバブルな記録媒体に記録された状態で譲渡されても良いし、あるいはネットワーク資源からダウンロードにより譲渡されても良い。

通信インタフェース２４は、ＬＡＮ５を介したデータ通信のインタフェースである。

図３は注文データ領域２３ｂに記憶される注文データの構成例を模式的に示す図である。
図３に示すように注文データは、伝票番号、テーブル番号、注文通番、メニューコード、数量、単価、ステータス、事前注文フラグ及び決済フラグを含む。なお注文データは、例えば注文された日時などの別の情報を含んでいてもよい。また注文データは、例えば単価などの一部の情報を含まなくてもよい。

伝票番号は、一括での決済の対象となる複数の注文に共通して割り当てられ、かつ別の決済の対象となる注文とは別に割り当てられる番号である。テーブル番号は上記の店舗において客が利用するテーブルに割り当てられた番号である。注文通番は、同じ伝票番号が割り当てられた複数の注文の個々に割り当てられる番号である。メニューコードは、注文の対象となった飲食物を識別するコードである。数量は、上記のメニューコードで識別される飲食物の注文数である。単価は、上記のメニューコードで識別される飲食物の１つ当たりの価格である。ステータスは、当該注文データが表す注文への対応状況を表す。事前注文フラグは、該当する注文が事前注文であるか否かを表すフラグである。本実施形態において事前注文フラグは、セット状態であるときに事前注文であることを示すこととする。決済フラグは、事前注文の際に決済が終了しているか否かを表すフラグである。本実施形態において決済フラグは、セット状態であるときに決済が終了していることを示すこととする。事前注文の際に決済可能な決済種別は、例えばクレジットカード決済である。事前注文の際に決済が行われる場合には、各店舗の代わりに、受注サーバ２０を管理運営する、あるいは事前注文サービスを店舗に提供する第三者がクレジットカード決済を代行する。したがって、事前注文の際に決済が終了している飲食物の代金は、受注サーバ２０を管理運営する、或いは事前注文サービスを店舗に提供する第三者から、後日、振込等で各店舗へ支払われる。

次に以上のように構成された注文管理装置２の動作について説明する。
プロセッサ２１は、注文管理装置２が注文の管理を行うべき通常の動作状態にあるときには、注文管理アプリ２３ａに従って注文管理のための情報処理を実行する。

図４及び図５はプロセッサ２１による情報処理のフローチャートである。なお、以下に説明する処理の内容は一例であって、同様な結果を得ることが可能な様々な処理を適宜に利用できる。例えば、一部の動作は、その順番を入れ替えることができる。また、一部の動作は、省略することもできるし、別の動作を追加して実行することもできる。

Ａｃｔ１としてプロセッサ２１は、新規の注文が発生したか否かを確認する。そしてプロセッサ２１は、新規の注文が発生していないならばＮｏと判定し、Ａｃｔ２へと進む。
Ａｃｔ２としてプロセッサ２１は、調理が終了したか否かを確認する。そしてプロセッサ２１は、調理が終了していないならばＮｏと判定し、Ａｃｔ３へと進む。
Ａｃｔ３としてプロセッサ２１は、調理済みの飲食物の客への提供が終了したか否かを確認する。そしてプロセッサ２１は、提供が終了していないならばＮｏと判定し、Ａｃｔ４へと進む。
Ａｃｔ４としてプロセッサ２１は、後述する店舗決済が終了したか否かを確認する。そしてプロセッサ２１は、店舗決済が終了していないならばＮｏと判定し、Ａｃｔ５へと進む。
Ａｃｔ５としてプロセッサ２１は、伝票番号が照会されたか否かを確認する。そしてプロセッサ２１は、伝票番号が照会されていないならばＮｏと判定し、Ａｃｔ６へと進む。
Ａｃｔ６としてプロセッサ２１は、注文のキャンセルが指示されたか否かを確認する。そしてプロセッサ２１は、当該指示がなされていないならばＮｏと判定し、Ａｃｔ１へと戻る。
かくしてプロセッサ２１はＡｃｔ１－Ａｃｔ６としては、新規注文、調理終了、提供終了、店舗決済終了、伝票番号照会及びキャンセル指示のいずれかのイベントが生じるのを待ち受ける。

店舗内又は店頭における客の注文は、店員により聞き取られた上で、当該店員による操作によってハンディ端末１に入力される。そうするとハンディ端末１は、上記の操作に従って受注データを生成し、無線アクセスポイント６及びＬＡＮ５を介して注文管理装置２へと送信する。ハンディ端末１は、伝票番号、テーブル番号及びメニューコードを受注データに少なくとも含める。なおハンディ端末１は、同一の伝票番号に関する注文として複数の飲食物が注文される場合、それら複数のメニューコードを個々に含んだ複数の受注データを順次に送信してもよいし、複数のメニューコードを含んだ１つの受注データを送信してもよい。

一方、受注サーバ２０が提供するサービスを利用して事前注文する客は、情報端末３０で専用のアプリケーションを起動し、情報端末３０における操作により注文を行う。例えば、客は、起動させた専用アプリケーションにおいて、事前注文しようとする店舗を指定し、当該店舗が事前注文を受け付ける飲食物のメニューの中から、自分が注文したい飲食物を選択する。受注サーバ２０は、この注文の内容を示した受注データを生成し、注文管理装置２に宛てて通信ネットワーク４０へと送出する。受注サーバ２０は、店舗のテーブルに割り当てられたテーブル番号とは重複しないように予め定められたテーブル番号を受注データに含める。受注サーバ２０は、事前注文を行う客がクレジットによる支払いを要求したならば、クレジット決済を行う。受注サーバ２０は、事前注文を行う客が、飲食物の受け取り時に決済することを要求したならば、決済を行わない。そして受注サーバ２０は、決済済みであるか否かを表す決済情報を受注データに含める。この受注データの通信を始めとする注文管理装置２と受注サーバ２０との間の通信には、例えばソケット通信が利用できる。受注サーバ２０は、受注データをデータ送信先の注文管理装置２０で取り扱われる注文データに適合させた形式に変換し、注文管理装置２に送信している。

受注データがＬＡＮ５により注文管理装置２へと伝送されると、この受注データを通信インタフェース２４が受信する。そしてこれに応じてプロセッサ２１は、新規の注文が発生したとしてＡｃｔ１にてＹｅｓと判定し、Ａｃｔ７へと進む。

Ａｃｔ７としてプロセッサ２１は、上記の受信された受注データに基づく新たな注文データを注文データ領域２３ｂに追加する。プロセッサ２１は具体的には、通信インタフェース２４により受信された受注データを通信インタフェース２４から取得する。ここに注文管理アプリ２３ａに基づく情報処理をプロセッサ２１が実行することによって、プロセッサ２１を中枢部分とするコンピュータは取得手段として機能する。そしてプロセッサ２１は、伝票番号、テーブル番号、注文通番、メニューコード、数量及び単価に関しては、取得した受注データの内容を反映した注文データを生成する。なおプロセッサ２１は、当該注文データにおけるステータスとしては、「受注済み」をセットする。またプロセッサ２１は、当該注文データにおける事前注文フラグ及び決済フラグは初期状態としてリセット状態とする。

Ａｃｔ８としてプロセッサ２１は、調理伝票をプリントするように伝票プリンタ３に指示する。
Ａｃｔ９としてプロセッサ２１は、今回の注文が事前注文であるか否かを確認する。そしてプロセッサ２１は、今回受信された受注データが受注サーバ２０から送信されたものであるならばＹｅｓと判定し、Ａｃｔ１０へと進む。

Ａｃｔ１０としてプロセッサ２１は、上記の追加した注文データにおける事前注文フラグをセットする。
Ａｃｔ１１としてプロセッサ２１は、受注データに含まれた決済情報に基づいて決済フラグを設定する。つまりプロセッサ２１は、決済情報が決済済みを示すならば決済フラグをセット状態とし、そうでなければ決済フラグをリセット状態とする。
Ａｃｔ１２としてプロセッサ２１は、受注データを受けた旨の通知を受注サーバ２０に対して行う。そしてプロセッサ２１はこののち、Ａｃｔ１－Ａｃｔ６の待受状態に戻る。

なおプロセッサ２１は、今回受信された受注データがハンディ端末１から送信されたものであるならばＡｃｔ９にてＮｏと判定し、Ａｃｔ１０及びＡｃｔ１２をパスしてＡｃｔ１－Ａｃｔ６の待受状態に戻る。この場合、今回追加した注文データにおける事前注文フラグ及び決済フラグは、リセット状態のままとされる。かくしてプロセッサ２１は、店舗内で受け付けられた注文に関する注文データと、店舗外からの注文に関する注文データとを、店舗外からの注文に関するものを事前注文フラグにより識別可能に、注文データ領域２３ｂを利用して管理していることになる。つまり、注文管理アプリ２３ａに基づく情報処理をプロセッサ２１が実行することによって、プロセッサ２１を中枢部分とするコンピュータは管理手段として機能する。

調理人は、上記のようにプリントされた調理伝票に基づいて注文内容を確認し、注文されている飲食物を調理する。そして調理を終了したならば、調理人又は別の店員は、どの注文に対する調理であるかの通知を伴って、調理の終了を注文管理装置２へと通知する。この通知は例えば、ハンディ端末１又は図示しない別の端末から、調理人又は別の店員の操作に応じて行われる。そしてプロセッサ２１は、このように調理終了が通知されたならばＡｃｔ２にてＹｅｓと判定し、Ａｃｔ１３へと進む。
Ａｃｔ１３としてプロセッサ２１は、調理が終了した注文に関する注文データにおけるステータスを「調理終了」に変更する。

Ａｃｔ１４としてプロセッサ２１は、調理が終了した注文に関する注文データにおける事前注文フラグに基づき、該当する注文が事前注文であるか否かを確認する。そしてプロセッサ２１は、事前注文であるならばＹｅｓと判定し、Ａｃｔ１５へと進む。

Ａｃｔ１５としてプロセッサ２１は、受注サーバ２０に対して、調理終了通知を行う。そしてプロセッサ２１はこののち、Ａｃｔ１－Ａｃｔ６の待受状態に戻る。なおプロセッサ２１は、該当する注文が事前注文ではないならばＡｃｔ１４にてＮｏと判定し、Ａｃｔ１５をパスしてＡｃｔ１－Ａｃｔ６の待受状態に戻る。

店内又は店頭での注文に関する調理が終了したのであるならば、調理人は、調理済みの飲食物を、接客を担当する店員に対して引き渡す。当該店員は、当該飲食物を客に提供する。そして店員は、このように提供を終了したならば、どの注文に対する飲食物の提供であるかの通知を伴って、提供の終了を注文管理装置２へと通知する。この通知は例えば、ハンディ端末１又は図示しない別の端末から、店員の操作に応じて行われる。そしてプロセッサ２１は、このように提供終了が通知されたならばＡｃｔ３にてＹｅｓと判定し、Ａｃｔ１６へと進む。

Ａｃｔ１６としてプロセッサ２１は、提供が終了した注文に関する注文データにおけるステータスを「提供終了」に変更する。そしてプロセッサ２１はこののち、Ａｃｔ１－Ａｃｔ６の待受状態に戻る。

店内又は店頭での注文に関する決済を客が店員に申し出ると、店員はＰＯＳ端末４を操作して、注文に関する代金の決済を客に行わせる。この代金の決済として選択可能な決済種別は、当該店舗で決済可能なものである。当該店舗での決済可能な決済種別の中に、クレジット決済が含まれている場合には、受注サーバ２０を管理運営する、或いは事前注文サービスを店舗に提供する第三者ではなく、当該店舗がクレジット決済を行なう。そして決済が終了したならばＰＯＳ端末４は、どの注文に関する決済であるかの通知を伴って、決済の終了を注文管理装置２へと通知する。そしてプロセッサ２１は、このように決済終了が通知されたならばＡｃｔ４にてＹｅｓと判定し、Ａｃｔ１７へと進む。
Ａｃｔ１７としてプロセッサ２１は、決済が終了した注文に関する注文データにおけるステータスを「決済終了」に変更する。そしてプロセッサ２１はこののち、Ａｃｔ１－Ａｃｔ６の待受状態に戻る。

受注サーバ２０は、前述の調理終了通知を受けると、情報端末３０に対して調理の完了をプッシュ通知する。あるいは受注サーバ２０は、調理の完了を通知するための電子メールを、上記の調理が完了した注文に関して通知先として定められたアドレスに宛てて送信する。客は、このプッシュ通知又は電子メールにより調理の完了を認識したならば、店舗へと出向く。そして客は、上記の調理が終了した飲食物の注文に関する伝票番号をハンディ端末１又はＰＯＳ端末４に入力するよう、店員に要求する。これは、客が口頭で伝票番号を伝えるのであってもよいし、伝票番号を示したコードシンボルを専用のアプリケーションの機能により情報端末３０に表示させて提示するのであってもよい。そして店員は、キー入力又はスキャナ入力によって、伝票番号をハンディ端末１又はＰＯＳ端末４に入力する。ハンディ端末１又はＰＯＳ端末４は、入力された伝票番号を、注文管理装置２に照会する。

このように伝票番号の照会を受けるとプロセッサ２１は、Ａｃｔ５にてＹｅｓと判定し、図５中のＡｃｔ１８へと進む。
Ａｃｔ１８としてプロセッサ２１は、照会元の端末に対して、提供確認画面の表示を指示する。提供確認画面は、客が提供を受けようとしているのがどの注文に関する飲食物であるかを表すとともに、その飲食物の提供が終了したことの確認操作を店員に行わせるための画面である。店員は、この提供確認画面に基づいて飲食物を客に提供する。そして予め定められた確認操作を、ハンディ端末１又はＰＯＳ端末４にて行う。ハンディ端末１又はＰＯＳ端末４は、このように確認操作が行われたならば、その旨を注文管理装置２に通知する。

Ａｃｔ１９としてプロセッサ２１は、上記の確認操作が行われるのを待ち受ける。そしてプロセッサ２１は、上記のように確認操作が行われたことが通知されたならばＹｅｓと判定し、Ａｃｔ２０へと進む。

Ａｃｔ２０としてプロセッサ２１は、上記のように飲食物の提供が終了した注文についての決済が完了しているか否か、決済フラグに基づいて確認する。そしてプロセッサ２１は、決済が終了していないならばＮｏと判定し、Ａｃｔ２１へと進む。
Ａｃｔ２１としてプロセッサ２１は、ＰＯＳ端末４に対して、決済を指示する。

ＰＯＳ端末４は、上記の指示と、店員による操作とに応じて決済のための処理を行う。このときに行なう決済は、店内又は店頭での注文に関する決済と同じである。そしてＰＯＳ端末４は、決済を終了したならば、その旨を注文管理装置２に通知する。

Ａｃｔ２２としてプロセッサ２１は、決済が終了するのを待ち受ける。そしてプロセッサ２１は、上記のようにＰＯＳ端末４から決済の終了が通知されたならばＹｅｓと判定し、Ａｃｔ２３へと進む。
Ａｃｔ２３としてプロセッサ２１は、受注サーバ２０に対して、決済終了通知を行う。
Ａｃｔ２４としてプロセッサ２１は、決済が終了した注文に関する注文データにおけるステータスを「決済終了」に変更する。そしてプロセッサ２１はこののち、図４中のＡｃｔ１－Ａｃｔ６の待受状態に戻る。

プロセッサ２１は、事前注文の受け付けの際に受注サーバ２０にて決済が終了しているならばＡｃｔ２０にてＹｅｓと判定し、Ａｃｔ２５へと進む。
Ａｃｔ２５としてプロセッサ２１は、受注サーバ２０に対して、提供終了通知を行う。
Ａｃｔ２６としてプロセッサ２１は、提供が終了した注文に関する注文データにおけるステータスを「提供終了」に変更する。そしてプロセッサ２１はこののち、図５中のＡｃｔ１－Ａｃｔ６の待受状態に戻る。

客は、事前注文を飲食物の提供を受ける前にキャンセルしたい場合には、例えば電話などによって店員に対してその旨を申し出る。店員は、調理の状況などを確認し、キャンセルすることが可能であるかどうかを判断する。そして店員は、キャンセルすることが可能であると判断したならば、キャンセル対象の注文の指定を伴って、キャンセルを指示する操作をハンディ端末１又はＰＯＳ端末４にて行う。ハンディ端末１又はＰＯＳ端末４は、このように操作が行われたならば、注文管理装置２にキャンセル対象の注文の通知を伴ってキャンセルを要求する。プロセッサ２１は、この要求を受けると図４中のＡｃｔ６にてＹｅｓと判定し、図５中のＡｃｔ２７へと進む。

Ａｃｔ２７としてプロセッサ２１は、キャンセル要求元の端末に対して、キャンセル確認画面の表示を指示する。キャンセル確認画面は、キャンセルの対象がどの注文であるかを表すとともに、キャンセルの実行の指示を店員に行わせるための画面である。店員は、このキャンセル確認画面に基づいて、本当にキャンセルするかどうかを確認し、キャンセルする場合には実行を指示するための操作をハンディ端末１又はＰＯＳ端末４にて行う。ハンディ端末１又はＰＯＳ端末４は、このように実行を指示する操作が行われたならば、その旨を注文管理装置２に通知する。

Ａｃｔ２８としてプロセッサ２１は、上記の通知が行われるのを待ち受ける。そしてプロセッサ２１は、上記のように実行を指示する操作が行われたことが通知されたならばＹｅｓと判定し、Ａｃｔ２９へと進む。なお、図示は省略しているが、キャンセルの取り止めを指定する操作が店員により行われた場合にも、ハンディ端末１又はＰＯＳ端末４はその旨を注文管理装置２に通知する。そしてこの場合にはプロセッサ２１は、以降に説明する処理をパスして図４中のＡｃｔ１－Ａｃｔ６の待受状態に戻る。

Ａｃｔ２９としてプロセッサ２１は、キャンセルの対象となっている注文が事前注文であるか否かを確認する。そしてプロセッサ２１は、事前注文であるならばＹｅｓと判定し、Ａｃｔ３０へと進む。

Ａｃｔ３０としてプロセッサ２１は、受注サーバ２０に対して、キャンセル対象となっている注文の伝票番号の通知を伴って、キャンセル通知を行う。なおプロセッサ２１は、キャンセルの対象が事前注文ではないならばＡｃｔ２９にてＮｏと判定し、このＡｃｔ３０をパスしてＡｃｔ３１へと進む。

Ａｃｔ３１としてプロセッサ２１は、キャンセルした注文に関する注文データにおけるステータスを「キャンセル」に変更する。そしてプロセッサ２１はこののち、図５中のＡｃｔ１－Ａｃｔ６の待受状態に戻る。なお、このときにプロセッサ２１は、キャンセルした注文に関する注文データを注文データ領域２３ｂから削除してもよい。

以上に説明したプロセッサ２１の処理のうち、Ａｃｔ１２、Ａｃｔ１５、Ａｃｔ２３、Ａｃｔ２５及びＡｃｔ３０については、事前注文に関する受け付け、調理、決済、提供、あるいはキャンセルの各処理の終了を受注サーバ２０に対して通知する処理である。つまりプロセッサ２１は、店舗外からの注文に関する処理が終了したことを、予め定められた通知先としての受注サーバ２０へと通知する。かくして注文管理アプリ２３ａに基づく情報処理をプロセッサ２１が実行することによって、プロセッサ２１を中枢部分とするコンピュータは、そのような通知を行う通知手段として機能する。

以上のように注文管理装置２においては、店舗内で受け付けられた注文と、店舗外から受注サーバ２０により受け付けられた事前注文とのうち、店舗外からの事前注文については、それに関する処理が終了したことに応じて、その旨を受注サーバ２０に通知する。これにより、事前注文に関するサービスについては受注サーバ２０との連携により提供することが可能でありながら、その事前注文と店舗内で受け付けられた注文とを統一的に取り扱うことが可能である。

また注文管理装置２によれば、事前注文に関する受け付け、調理、決済、提供、あるいはキャンセルの各処理の終了を受注サーバ２０に対して通知している。このため、飲食物を、客の注文に応じて調理した上で、店舗において客に提供する業態における注文管理を適切に行える。

この実施形態は、次のような種々の変形実施が可能である。
受注サーバ２０への通知は、受け付け、調理、決済、提供及びキャンセルの全てに関して必須な訳ではなく、それらのうちの一部の通知のみを行ってもよい。例えば、店舗での決済については受注サーバ２０では管理しないのであれば、決済の終了を通知しなくてもよい。また、例えば、上記の処理とは別の任意の処理の終了を通知してもよい。

何らかの処理を伴う注文であれば、どのような注文を管理する場合であっても上記実施形態の技術的思想の下に実施が可能である。この場合、通知の対象とする処理についても、管理する注文に適応したものとする。例えば、ネットスーパーにおける店頭受け取りサービスに関する注文を管理するのであれば、「調理」に代えて「受け渡し準備」の終了に関する通知を行うことが想定される。

販売データを管理する機能を注文管理装置２に備えてもよい。この場合に注文管理装置２は、店内又は店頭で注文を受けた飲食物の代金と、第三者が管理運営する事前注文サービスで注文を受けた飲食物の代金とは、別々に集計してもよい。そしてこの場合に注文管理装置２は、それらの代金をそれぞれ区別して確認することを可能とするレポートを出力する。また注文管理装置２は、第三者が管理運営する事前注文サービスで注文を受けた飲食物の代金は、事前注文の際に決済が終了している場合と、事前注文の際に決済が終了しておらず、店舗で決済を行なった場合とで分けて集計してもよい。そしてこの場合に注文管理装置２は、それらの代金をそれぞれ区別して確認することを可能とするレポートを出力する。また注文管理装置２は、事前注文を受けながらもキャンセルされた注文の明細及び、事前決済済み金額又は事前決済なし金額等の合計金額を集計し、レポート出力してもよい。これらのレポートは、事前注文サービスを当該店舗に提供している第三者との決済時に確認用として、あるいは請求支払処理のデータとして利用できる。なお、各レポートの出力は、紙媒体への印刷又は、記憶媒体への記憶等の任意の形態であってよい。

受注サーバ２０は、情報端末３０での注文操作を受け付けるためのＧＵＩ（graphical user interface）画面を情報端末３０で表示させるためのＷｅｂページを情報端末３０に与えるようにしてもよい。そして受注サーバ２０は、ＧＵＩ画面における客の操作に基づいて事前注文を受け付けるようにする。そうすれば、情報端末３０は、上記のＷｅｂページを閲覧するための汎用の閲覧アプリケーションを備えていれば良く、事前注文のための受注サーバが提供するサービスを利用するための専用のアプリケーションプログラムを必要としない。

制御処理によりプロセッサ２１が実現する各機能は、その一部または全てをロジック回路などのようなプログラムに基づかない情報処理を実行するハードウェアにより実現することも可能である。また上記の各機能のそれぞれは、上記のロジック回路などのハードウェアにソフトウェア制御を組み合わせて実現することも可能である。

本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。

１…ハンディ端末、２…注文管理装置、３…伝票プリンタ、４…ＰＯＳ端末、５…ＬＡＮ、６…無線アクセスポイント、７…ルータ、１０…店舗システム、２０…受注サーバ、２１…プロセッサ、２２…メインメモリ、２３…補助記憶デバイス、２３ａ…注文管理アプリ、２３ｂ…注文データ領域、２４…通信インタフェース、２５…バス、３０…情報端末、４０…通信ネットワーク。

実施形態の注文管理装置は、店舗での商品提供に関する店舗外からの注文に関する注文データを生成する生成手段と、生成手段により生成された注文データを注文管理装置に送信する送信手段と、注文管理装置からの通知を受けると、該当の注文の注文者に対して来店を促すための通知を行う第２の通知手段と、を具備した受注サーバとともに受注システムを構成する上記の注文管理装置であって、取得手段、管理手段及び第１の通知手段を備える。取得手段は、送信手段により送信された注文データを取得する。管理手段は、商品提供に関する注文データを、店舗内で受け付けられた注文に関する注文データであるか、取得手段により取得された注文データであるかを識別可能に管理する。第１の通知手段は、注文データに関する商品提供のための処理が終了したことに応じて、該当する注文データが取得手段により取得された注文データとして管理手段により管理されているならば、受注サーバへと処理の終了を通知し、該当する注文データが店舗内で受け付けられた注文に関する注文データとして管理手段により管理されているならば、受注サーバへと処理の終了を通知しない。

一方、受注サーバ２０が提供するサービスを利用して事前注文する客は、情報端末３０で専用のアプリケーションを起動し、情報端末３０における操作により注文を行う。例えば、客は、起動させた専用アプリケーションにおいて、事前注文しようとする店舗を指定し、当該店舗が事前注文を受け付ける飲食物のメニューの中から、自分が注文したい飲食物を選択する。受注サーバ２０は、この注文の内容を示した受注データを生成し、注文管理装置２に宛てて通信ネットワーク４０へと送出する。受注サーバ２０は、店舗のテーブルに割り当てられたテーブル番号とは重複しないように予め定められたテーブル番号を受注データに含める。受注サーバ２０は、事前注文を行う客がクレジットによる支払いを要求したならば、クレジット決済を行う。受注サーバ２０は、事前注文を行う客が、飲食物の受け取り時に決済することを要求したならば、決済を行わない。そして受注サーバ２０は、決済済みであるか否かを表す決済情報を受注データに含める。この受注データの通信を始めとする注文管理装置２と受注サーバ２０との間の通信には、例えばソケット通信が利用できる。受注サーバ２０は、受注データをデータ送信先の注文管理装置２で取り扱われる注文データに適合させた形式に変換し、注文管理装置２に送信している。

なおプロセッサ２１は、今回受信された受注データがハンディ端末１から送信されたものであるならばＡｃｔ９にてＮｏと判定し、Ａｃｔ１０－Ａｃｔ１２をパスしてＡｃｔ１－Ａｃｔ６の待受状態に戻る。この場合、今回追加した注文データにおける事前注文フラグ及び決済フラグは、リセット状態のままとされる。かくしてプロセッサ２１は、店舗内で受け付けられた注文に関する注文データと、店舗外からの注文に関する注文データとを、店舗外からの注文に関するものを事前注文フラグにより識別可能に、注文データ領域２３ｂを利用して管理していることになる。つまり、注文管理アプリ２３ａに基づく情報処理をプロセッサ２１が実行することによって、プロセッサ２１を中枢部分とするコンピュータは管理手段として機能する。

本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。
以下に、本願の当初の特許請求の範囲に記載された発明を付記する。
［付記１］ 店舗内で受け付けられた注文に関する注文データと、店舗外からの注文に関する注文データとを、店舗外からの注文に関するものを識別可能に管理する管理手段と、
前記注文データに関する処理が終了したことに応じて、該当する注文データが店舗外からの注文に関するとして前記管理手段により管理されているならば、予め定められた通知先へと前記処理の終了を通知する通知手段と、を具備する注文管理装置。
［付記２］ 店舗外からの注文に関する前記注文データを、店舗外からの注文を受け付けて注文データを生成する受注サーバから取得する取得手段、をさらに備え、
前記通知手段は、前記処理の終了を前記受注サーバに対して通知する、
付記１に記載の注文管理装置。
［付記３］ 前記通知手段は、前記注文に関する注文者への対応のための準備が終了したことを通知する、付記１又は付記２に記載の注文管理装置。
［付記４］ 前記通知手段は、前記注文に関する注文者への対応が終了したことを通知する、付記１－付記３のいずれか一項に記載の注文管理装置。
［付記５］ 前記通知手段は、前記注文に関する決済が終了したことを通知する、付記１－付記４のいずれか一項に記載の注文管理装置。
［付記６］ 注文管理装置に備えられたコンピュータを、
店舗内で受け付けられた注文に関する注文データと、店舗外からの注文に関する注文データとを、店舗外からの注文に関するものを識別可能に管理する管理手段と、
前記注文データに関する処理が終了したことに応じて、該当する注文データが店舗外からの注文に関するとして前記管理手段により管理されているならば、予め定められた通知先へと前記処理の終了を通知する通知手段と、して機能させるためのプログラム。

Claims (6)

1. 店舗内で受け付けられた注文に関する注文データと、店舗外からの注文に関する注文データとを、店舗外からの注文に関するものを識別可能に管理する管理手段と、
   前記注文データに関する処理が終了したことに応じて、該当する注文データが店舗外からの注文に関するとして前記管理手段により管理されているならば、予め定められた通知先へと前記処理の終了を通知する通知手段と、
   を具備する注文管理装置。
2. 店舗外からの注文に関する前記注文データを、店舗外からの注文を受け付けて注文データを生成する受注サーバから取得する取得手段、
   をさらに備え、
   前記通知手段は、前記処理の終了を前記受注サーバに対して通知する、
   請求項１に記載の注文管理装置。
3. 前記通知手段は、前記注文に関する注文者への対応のための準備が終了したことを通知する、
   請求項１又は請求項２に記載の注文管理装置。
4. 前記通知手段は、前記注文に関する注文者への対応が終了したことを通知する、
   請求項１－請求項３のいずれか一項に記載の注文管理装置。
5. 前記通知手段は、前記注文に関する決済が終了したことを通知する、
   請求項１－請求項４のいずれか一項に記載の注文管理装置。
6. 注文管理装置に備えられたコンピュータを、
   店舗内で受け付けられた注文に関する注文データと、店舗外からの注文に関する注文データとを、店舗外からの注文に関するものを識別可能に管理する管理手段と、
   前記注文データに関する処理が終了したことに応じて、該当する注文データが店舗外からの注文に関するとして前記管理手段により管理されているならば、予め定められた通知先へと前記処理の終了を通知する通知手段と、
   して機能させるためのプログラム。
   
   

Images