JP5863999B1 - 注文管理装置および注文管理方法 - Google Patents

Abstract

【課題】専用端末やプログラムを必要としない顧客にとっては使い勝手のよい、店舗側にとっては導入コストを低減できる注文管理装置および方法の提供。【解決手段】店舗情報と各店舗におけるメニュー情報と店舗識別情報とテーブル識別情報とを含む店舗に応じた所定数の注文ＵＲＬと前記注文ＵＲＬに対応するアクセス可否を含む注文用ＵＲＬ情報を関連付けて記憶し、店員端末から前記店舗識別情報と前記テーブル識別情報とを含むアクセス可要求データを受信し、前記アクセス可否要求データにより特定される前記注文ＵＲＬの前記アクセス可否を可に更新し、顧客端末から前記顧客端末が識別タグから取得した前記注文ＵＲＬを含む注文ページ要求データを受信し、前記注文ＵＲＬ情報を検索し前記注文ページ要求データにより特定される前記アクセス可否が可か否かを判別し、前記アクセス可否が可と判別された場合に前記顧客端末から注文データを受け付ける。【選択図】図６

Description

本発明は、特に、携帯情報端末を用いた注文管理装置および注文管理方法に関する。

従来から、飲食店などにおける注文システムとして、テーブルに備え付けの専用の端末を介して注文を受け付けるシステムが知られている。また、顧客自身が所有する携帯電話等の情報端末を専用のコンピュータプログラムをインストールして用いることにより、注文を行うことができる注文システムが知られている。

特開２０１４−００２６４１

特許文献１にみる、従来の顧客所有の携帯電話等を介して注文するシステムにあっては、事前に専用のアプリケーションをインストールする必要があり、また、その後のユーザー登録手続等も必要であり、実際に使用するまでに面倒な手間が必要であった。

また、従来の注文システムは、注文が一つの伝票単位でまとめられてしまう結果、個別に清算しようとする場合など、伝票から個々の注文したものを抽出して、その分の合計金額を算出するなど面倒であり、柔軟な金額確認ができるものではなかった。

本発明は、上記課題に鑑みなされたものであり、以下のような手段もしくはステップを備えるコンピュータもしくは方法である。
（１）店舗情報と各店舗におけるメニュー情報と店舗に応じた所定数の注文ＵＲＬと前記注文ＵＲＬに対応するアクセス可否を含む注文用ＵＲＬ情報を関連付けて記憶する手段と、店員端末から前記注文ＵＲＬのうち一の注文ＵＲＬを含むアクセス可要求データを受信する手段と、前記アクセス可否要求データに含まれる前記注文ＵＲＬに対応する前記アクセス可否を可に更新する手段と、顧客端末から前記顧客端末が識別タグを読み込むことにより取得した前記注文ＵＲＬを含む注文ページ要求データを受信する手段と、前記注文ＵＲＬ情報を検索し前記注文ページ要求データに含まれる前記注文ＵＲＬに対応する前記アクセス可否が可か否かを判別する手段と、前記アクセス可否が可と判別された場合に前記顧客端末から注文データを受け付ける手段を備えることを特徴とする。
（２）前記識別タグとは、ＮＦＣタグであることを特徴とする。
（３）前記店員端末に該当する店舗における所定数の注文ＵＲＬを送信する手段と、前記識別タグが有する前記注文ＵＲＬは、前記店員端末を介して前記識別タグに書き込まれたものであることを特徴とする。
（４）前記顧客端末ごとに端末識別情報を割り当てて記憶する手段と、前記顧客端末に前記端末識別情報を送信する手段と、前記端末識別情報と前記注文データを関連付けた注文管理情報を記憶する手段と、 前記顧客端末から前記端末識別情報を含む個別確認要求データを受信する手段と、前記個別確認要求データの前記端末識別情報に対応する注文データから個別確認用送信データを作成する手段と、前記個別確認用送信データを顧客端末に送信する手段とを備えることを特徴とする。

本願発明によれば、顧客自身のスマートフォン等の携帯情報端末を使用して注文が出来き、かつ、専用のアプリケーションのインストール等事前作業を顧客に強いることが無く、顧客にとって、面倒な手間が不要となり、簡便で利用しやすいものにすることができる。また、耳が不自由な顧客にとっては、実際に注文する際の店員とのやり取りにおける負担を軽減することができる。

店舗側としては、専用の端末やアプリケーションを用意する必要がなりため、システム導入にあたっての費用を低廉に抑えることができる。また、接客を行う店員が少なくて済むため、人件費を抑えることができる。

また、識別タグとしてＮＦＣタグ等のＩＣタグを用いるため、注文ＵＲＬ（詳細については、後述。）の書き換えが容易であるため、店舗においてテーブルの入れ替えもしくはテーブル数の増減があった場合でも、ＩＣタグおよびサーバ側の情報変更のみで済むため、柔軟に対応できる。

顧客自身の携帯情報端末を識別しつつサーバで注文を管理できるので、グルーブ単位の顧客であっても個別の注文および金額確認が容易である。

本発明に係るハードウェア結び付きの概略図である。 店舗情報の一例を示す図である。 メニュー情報の一例を示す図である。 注文用ＵＲＬ情報の一例を示す図である。 注文ＵＲＬの一例を示す図である。 注文用ＵＲＬ情報を更新した際の一例を示す図である。 注文管理情報の一例を示す図である。 注文データの一例を示す図である。 第２の実施例における注文管理情報の一例を示す図である。 個別金額確認画面の一例を示す図である。

以下、本発明の実施例１について図面を参照しつつ説明する。図１は、本発明に必要なハードウェアと、それらの結びつきを示す概略図である。顧客からの注文を受け付け管理するためのサーバ１（注文管理装置）と、顧客が注文の際に利用する顧客携帯情報端末２（顧客端末）、および飲食店等の店舗において接客等を行うスタッフが使用する店員携帯情報端末４（店員端末）とが、インターネット等の通信回線３を介して、データの送受信が可能なように接続されている。

サーバ１、顧客携帯情報端末２および店員携帯情報端末４は、データを処理する処理装置、データを記憶する記憶装置と、データを送受信する送信部および受信部をそれぞれ備えている。サーバ１、顧客携帯情報端末２および店員携帯情報端末４の記憶装置には、本発明を実施するためのコンピュータプログラムや所定のデータがそれぞれ記憶されている。処理装置は、当該コンピュータプログラム等による所定の命令に従ってデータの処理を行う。

顧客携帯情報端末２および店員携帯情報端末４は、具体的には、スマートフォンやタブレットＰＣ等の携帯情報端末であってよいが、現在特に広く普及しているという点においてスマートフォンが好適である。これらは、データ表示のための表示手段、データ入力のための入力手段といった、携帯情報端末が一般に備える各種手段を備えているものであればよい。

また、店舗における各テーブルには、識別タグ５があらかじめ備え付けられている。ここで、識別タグ５は、ＮＦＣ（Near Field Communication）規格などによるＩＣタグであってよい。顧客携帯情報端末２は、識別タグ５に書き込まれている情報を読み取るためのリーダを少なくとも備えており、店員携帯情報端末４は、識別タグ５の読み取り・書き込みを行うためのリーダライタを備えているものとする。

以下、本発明について、各手段が記憶している情報およびそれらの処理の流れについて説明する。サーバ１には、図２および図３に示すような「店舗情報」および「店舗メニュー情報」が関連付けて記憶されている。店舗情報としては、例えば、「店舗識別情報、店名、テーブル数、住所、電話番号」等が含まれ、店舗メニュー情報には、「店舗識別情報、商品名、価格」等が含まれる。

また、サーバ１は、図４に示すように、「店舗情報」の、特に店舗識別情報と関連付くようにテーブル単位で「注文ＵＲＬ」を記憶している。「注文ＵＲＬ」の構造としては、図５のとおりである。すなわち、図５に示すように、「注文ＵＲＬ（https://www.xxx.jp/Order/OrderMain.php?store_info=0001_1）」には、「店舗情報」と関連付くように「店舗識別情報」（この例においては、「0001」）および「テーブル識別情報」（この例においては、「1」）が含まれている。このように、「注文ＵＲＬ」は、各店舗におけるテーブル単位でユニークに割り当てられているものである。また、「注文用ＵＲＬ情報」は、これら注文ＵＲＬ各々に対応する情報として「アクセス可否」が含まれる。

店員携帯情報端末４は、サーバ１から、該当する店舗の注文ＵＲＬ情報を取得し、記憶している。例えば、店員携帯情報端末４がサーバ１に該当する店舗識別情報を送信し、サーバ１がこの店舗識別情報に基づいて「注文ＵＲＬ情報」を検索し、抽出された注文ＵＲＬを店員携帯情報端末４に送信するようにすればよい。

以下、実際の接客の場面を想定しつつ、具体的な処理の流れについて説明する。ここでは、図２に示す店舗情報のうち、「店舗識別情報：０００１，店名：ＡＡ店，テーブル数：５」に示す例に基づいて説明する。

＜注文前処理＞
ＡＡ店の店員は、来店した顧客を、店舗内にあるテーブル（１）乃至（５）の全５つのテーブルの中からテーブル（２）に案内した。ここで、このＡＡ店の店員は、自身が持つ店員携帯情報端末４を操作し、これに記憶されている注文用ＵＲＬ情報から、その案内したテーブル（２）に対応する注文ＵＲＬを、すなわち、図４における例では、「https://www.xxx.jp/Order/OrderMain.php?store_info=0001_2」を、リーダライタを介して、そのテーブルの識別タグ５ｂに書き込む。

店員携帯情報端末４を介して、テーブル（２）の識別タグ５ｂに正しく注文ＵＲＬが書き込まれたことが確認された場合、店員携帯情報端末４は、サーバ１に、この後顧客が自身の顧客携帯情報端末２から注文を可能とするために、つまり、顧客携帯情報端末２から当該注文ＵＲＬが示す注文用ウェブサイトへアクセスを可能にするため、「アクセス可要求データ」を送信する。

具体的には、「アクセス可要求データ」は、テーブル（２）の識別タグ５ｂに書き込んだ注文ＵＲＬ（もしくは、店舗識別情報およびテーブル識別情報のみ）を含むデータであって、店員携帯情報端末４は、これを作成し、サーバ１に送信する。

「アクセス可要求データ」を受信したサーバ１は、記憶されている「注文用ＵＲＬ情報」を検索し、該当する注文ＵＲＬに対応する「アクセス可否」情報を、アクセス「不可」からアクセス「可」に更新して記憶する（図６）。後述するが、これにより顧客が自身の顧客携帯情報端末２から該当する注文ＵＲＬが示す注文用ウェブサイトへのアクセスが可能となる。

＜注文受付処理＞
「注文前処理」が完了後、顧客は、自身の持つ顧客携帯情報端末２を操作して、顧客携帯情報端末２のＮＦＣリーダを介して、テーブル（２）の識別タグ５ｂから、店員携帯情報端末４により書き込まれた注文ＵＲＬ「https://www.xxx.jp/Order/OrderMain.php?store_info=0001_2」を読み込む。顧客携帯情報端末２は、読み込んだその注文ＵＲＬを含む「注文ページ要求データ」をサーバ１に送信し、サーバ１の注文用ウェブサイトにアクセスする。

アクセスを受けたサーバ１は、当該注文用ＵＲＬへのアクセスを許可するか否かを判別する。すなわち、サーバ１は、「注文用ＵＲＬ情報」を検索して、該当する注文ＵＲＬに関連付けられている「アクセス可否」を参照する。

この「アクセス可否」が「可」の場合、サーバ１があらかじめ用意している注文用ウェブサイトを表示させるため、当該注文ＵＲＬに含まれる「店舗識別情報」に基づき「店舗メニュー情報」検索抽出し、所定のフォームデータと共に注文ページデータを作成し、顧客携帯情報端末２へ送信する。

一方、「アクセス可否」情報が、「否」の場合は、この処理を行わない。この場合、サーバ１から顧客携帯情報端末２に対し、単に「表示できません」等のメッセージを送信するようにしてもよい。

顧客は、当該注文用ページから、所望のメニューおよび個数などを選択し、注文の操作を行う。顧客携帯情報端末２は、選択されたメニューおよび指定された個数などの個別の注文情報と注文用ＵＲＬを含む注文データを作成し、サーバ１に送信する。図７に示すように、サーバ１は、当該注文データを受信し、注文用ＵＲＬに含まれる「店舗識別情報」および「テーブル識別情報」と関連付けて「注文管理情報」として、順次記憶する。

このように、「注文管理情報」は、「店舗識別情報」および「テーブル識別情報」を記憶するので、店舗ごとだけでなく、各店舗のテーブル単位での注文に関する情報の管理が可能となる。

＜完了処理＞
顧客が注文を終えて店舗を後にする際には、店員は、店員携帯情報端末４を用いて、そのテーブルの注文ＵＲＬを利用不可にするための完了処理を行う。店員は、店員携帯情報端末４を操作して、サーバ１に「アクセス不可要求データ」をする。この例においては、「アクセス不可要求データ」には、テーブル（２）の「注文ＵＲＬ（https://www.xxx.jp/Order/OrderMain.php?store_info=0001_2）」が含まれる。なお、ここでは、「注文用ＵＲＬ情報」を検索し、該当する注文ＵＲＬを特定できればよいので、「店舗識別情報」および「テーブル識別情報」のみを送信するようにしてもよい。

「アクセス不可要求データ」を受信したサーバ１は、「注文用ＵＲＬ情報」を検索し、該当する「アクセス可否」を「可」から「不可」に更新して記憶する。以後の顧客携帯情報端末２から同注文ＵＲＬが示す注文用ウェブサイトへのアクセスは不可となる。これにより、いたずら等による不正な注文を防止できる。

実施例１においては、一人で来店する顧客を想定した処理の流れについて説明したが、本実施例においては、特に複数人で来店した場合における例について説明する。また、本実施例における以下の説明は、実施例１と異なる点を中心に説明する。

例えば、３人のグループで来店した顧客（ここでは、顧客Ａ、顧客Ｂおよび顧客Ｃ）が、一つのテーブルに着いたとする。この場合においても、店員は、実施例１と同様、店員携帯情報端末４のリーダライタを介して、そのテーブルに対応する一の注文ＵＲＬを識別タグ５ｂに書き込み、顧客携帯情報端末２から当該注文ＵＲＬが示す注文用ウェブサイトへアクセスを可能にするため、「アクセス可要求データ」を送信する。この「アクセス可要求データ」を受信したサーバ１は、「注文用ＵＲＬ情報」を検索し、該当する注文ＵＲＬの「アクセス可否」を「可」に更新し記憶する。

そして、顧客Ａ、顧客Ｂおよび顧客Ｃは、自身の持つ顧客携帯情報端末２Ａ、２Ｂおよび２Ｃを用いて、テーブルの識別タグ５ｂから注文ＵＲＬを読み取る。顧客携帯情報端末２Ａ、２Ｂおよび２Ｃは読み取った注文ＵＲＬを含む「注文ページ要求データ」をサーバ１に送信し、サーバ１は、その注文ＵＲＬに対応する「アクセス可否」が「可」か「否」かを判別し、「可」の場合は、サーバ１の予め用意され記憶されている注文用ウェブサイトへのアクセスを許可する。

ここで、顧客携帯情報端末２が、注文用ウェブサイトへのアクセスを許可された場合、当該アクセスを受けたサーバ１は、その顧客携帯情報端末２からのアクセスが初めてである場合、その特定の顧客携帯情報端末２に対し端末識別情報を割り当て記憶すると共に、割り当てた端末識別情報をその顧客携帯情報端末２に送信する。顧客携帯情報端末２は、これを受信し記憶する。ここでは、仮に、顧客携帯情報端末２に割り当てられた端末識別情報を「Aaa123Xxx」とする。

具体的には、顧客Ａが操作する顧客携帯情報端末２Ａが、注文ＵＲＬに従ってサーバ１の注文用ウェブサイトにアクセスした場合において、その顧客携帯情報端末２Ａからサーバ１へのアクセスが初めてである場合、サーバ１は、顧客携帯情報端末２Ａに対しユニークな端末識別情報「Aaa123Xxx」を割り当て、記憶すると共に、この端末識別情報を顧客携帯情報端末２Ａへ送信し、これを受信した顧客携帯情報端末２Ａはこれを記憶する。

顧客Ａが顧客携帯情報端末２Ａを用いて注文用ウェブサイトから、所望のメニューおよび個数を指定し注文を行う場合、図９に示すような注文データを作成し、サーバ１に送信する。この注文データには、顧客携帯情報端末２Ａに割り当てられ記憶された端末識別情報が含まれる。顧客携帯情報端末２Ｂおよび２Ｃにおいても、同様である。この注文データを受信したサーバ１は、例えば図８に示すように順次記憶する。

こうすることで、飲食を終え会計を行う場合、顧客グループは、単純に、そのテーブル単位の合計金額の他、以下のように顧客各々の個別の金額を確認することができる。

具体的には、顧客Ａが、自分の注文した分のメニューおよび金額を確認したい場合、自身の顧客携帯情報端末２Ａをからサーバ１に「個別確認要求データ」を送信する。「個別確認要求データ」には、上記のとおり、顧客携帯情報端末２Ａの端末識別情報が含まれる。

顧客携帯情報端末２Ａから「個別確認要求データ」を受信したサーバ１は、顧客携帯情報端末２Ａの端末識別情報をキーに「注文管理情報」を検索し、該当する「商品名，単価，数量」などのデータを抽出し、「個別回答データ」を作成し、これを顧客携帯情報端末２Ａへ送信する。

これにより、顧客携帯情報端末２Ａには、例えば、図１０に示すような個別金額確認画面が表示され、顧客Ａは、自分自身が注文した分、すなわち顧客携帯情報端末２Ａから注文したメニューやその金額等のみを確認することができる。

本発明は、以上の例に限定されない。たとえば、サーバ１は単一のハードウェアである必要はなく、複数のハードウェアから構成されるものであってよい。これまで説明した各種データの種類若しくは関連付け方についても、これまでの説明のとおりに限定されるものでなく、必要に応じて各データが参照できる構造になっていればよい。

また、識別タグは、ＮＦＣ等のＩＣタグであるとして説明してきたが、これに限定されない。たとえば、ＱＲコード等の二次元コードを用いてもよい。例えば、店舗の各テーブルに対応した注文ＵＲＬを内容とする二次元コードを各テーブルに設置する。顧客携帯情報端末２および店員携帯情報端末４については、ＩＣタグ用のリーダライタは不要であり、付属のカメラ機能を介した既知の読み取り手段を用いてよい。店員は、顧客をテーブルに案内した際、店員携帯情報端末４により二次元コードを読み取り、サーバ１にアクセスし、該当する「アクセス可否」を「可」に更新させるようにすればよい。

上記説明については、決済の手段については特に言及していないが、現在知られている各種の手段、例えば、各種電子マネーによる決済を適用するようにしてもよい。

また、顧客の扱いやすい言語を選択できるようにしてもよい。例えば、顧客携帯情報端末２からサーバ１への注文用ページ要求の際に、顧客が扱いやすい言語（例えば、英語）を選択させ、サーバ１が注文用ページのメニュー情報等の必要情報を適宜翻訳して顧客携帯情報端末２へ送信するようにしてもよい。翻訳のための手段については、現在既知のものを適宜用いればよい。

これまで、飲食店におけるテーブル単位で説明をしてきたが、これに限られない。例えば、野球場その他のスポーツ競技場などにおいては、識別タグを各座席に設置し、その座席ごとの識別タグに各々注文ＵＲＬを保持させるようにしてもよい。

１ サーバ
２ 顧客携帯情報端末
３ 通信回線
４ 店員携帯情報端末
５ 識別タグ

Claims (5)

1. 店舗情報と各店舗におけるメニュー情報と店舗を識別するための店舗識別情報とテーブルを識別するためのテーブル識別情報とを含むものであって店舗に応じた所定数の注文ＵＲＬと前記注文ＵＲＬに対応するアクセス可否を含む注文用ＵＲＬ情報を関連付けて記憶する手段と、
   店員端末から前記店舗識別情報と前記テーブル識別情報とを含むアクセス可要求データを受信する手段と、
   前記アクセス可否要求データにより特定される前記注文ＵＲＬに対応する前記アクセス可否を可に更新する手段と、
   顧客端末から前記顧客端末が識別タグを読み込むことにより取得した前記注文ＵＲＬを含む注文ページ要求データを受信する手段と、
   前記注文ＵＲＬ情報を検索し前記注文ページ要求データにより特定される前記注文ＵＲＬに対応する前記アクセス可否が可か否かを判別する手段と、
   前記アクセス可否が可と判別された場合に前記顧客端末から注文データを受け付ける手段、
   を備えることを特徴とする注文管理装置。
2. 前記識別タグとは、ＮＦＣタグであることを特徴とする請求項１に記載の注文管理装置。
3. 前記店員端末に該当する店舗における所定数の注文ＵＲＬを送信する手段と、
   前記識別タグが有する前記注文ＵＲＬは、前記店員端末を介して前記識別タグに書き込まれたものであることを特徴とする請求項２に記載の注文管理装置。
4. 前記顧客端末ごとに端末識別情報を割り当てて記憶する手段と、
   前記顧客端末に前記端末識別情報を送信する手段と、
   前記端末識別情報と前記注文データを関連付けた注文管理情報を記憶する手段と、
   前記顧客端末から前記端末識別情報を含む個別確認要求データを受信する手段と、
   前記個別確認要求データの前記端末識別情報に対応する注文データから個別確認用送信データを作成する手段と、
   前記個別確認用送信データを顧客端末に送信する手段、
   を備えることを特徴とする請求項１乃至３のいずれか１項に記載の注文管理装置。
5. 店舗情報と各店舗におけるメニュー情報と店舗を識別するための店舗識別情報とテーブルを識別するためのテーブル識別情報とを含むものであって店舗に応じた所定数の注文ＵＲＬと前記注文ＵＲＬに対応するアクセス可否を含む注文用ＵＲＬ情報を関連付けて記憶するステップと、
   店員端末から前記店舗識別情報と前記テーブル識別情報とを含むアクセス可要求データを受信するステップと、
   前記アクセス可否要求データにより特定される前記注文ＵＲＬに対応する前記アクセス可否を可に更新するステップと、
   顧客端末から前記顧客端末が識別タグを読み込むことにより取得した前記注文ＵＲＬを含む注文ページ要求データを受信するステップと、
   前記注文ＵＲＬ情報を検索し前記注文ページ要求データにより特定される前記注文ＵＲＬに対応する前記アクセス可否が可か否かを判別するステップと、
   前記アクセス可否が可と判別された場合に前記顧客端末から注文データを受け付けるステップ、
   を有することを特徴とする注文管理方法。
   

Images