(57)【要約】【課題】専用端末や専用プログラムを必要としない顧客にとっては使い勝手のよい注文管理装置および方法において店舗側に負担を抑えつつ多言語への対応を可能にする。【解決手段】店舗情報と各店舗におけるメニュー情報と店舗を識別するための店舗識別情報とテーブルを識別するためのテーブル識別情報とを含むものであって店舗に応じた所定数の注文ＵＲＬを含む注文ＵＲＬ情報とを関連付けて記憶し、顧客端末から前記顧客端末が識別タグを読み込むことにより取得した前記注文ＵＲＬによるリクエストを受け付け、前記メニュー情報と他言語に翻訳された翻訳メニュー情報と関連付けて記憶し、前記顧客端末から言語情報を取得し、前記言語情報により特定される言語による前記メニュー情報又は前記翻訳メニュー情報に基づき前記顧客端末に送信する注文ページデータを作成する。翻訳メニュー情報のうち対応する情報が店舗端末から受け付けた翻訳管理情報に存在する場合には、翻訳管理情報を優先する。【選択図】図１
2019061566.tif 000002
【特許請求の範囲】
【請求項１】
店舗情報と各店舗におけるメニュー情報と店舗を識別するための店舗識別情報とテーブルを識別するためのテーブル識別情報とを含むものであって店舗に応じた所定数の注文ＵＲＬを含む注文ＵＲＬ情報とを関連付けて記憶する手段と、
顧客端末から前記顧客端末が識別タグを読み込むことにより取得した前記注文ＵＲＬによるリクエストを受け付ける手段と、
前記メニュー情報と他言語に翻訳された翻訳メニュー情報と関連付けて記憶する手段と、
前記顧客端末から言語情報を取得する手段と、
前記言語情報により特定される言語による前記メニュー情報又は前記翻訳メニュー情報に基づき前記顧客端末に送信する注文ページデータを作成する手段を備えることを特徴とする注文管理装置。
【請求項２】
前記翻訳メニュー情報と翻訳管理情報とを関連付けて記憶する手段を備え、
前記翻訳メニュー情報は、前記メニュー情報の機械翻訳による翻訳情報を含むものであり、
前記翻訳メニュー情報のうち対応する情報が前記翻訳管理情報に存在するか否かを判断する手段を備え、
前記翻訳管理情報が存在する場合には、前記翻訳管理情報を優先することを特徴とする請求項１に記載の注文管理装置。
【請求項３】
店舗情報と各店舗におけるメニュー情報と店舗を識別するための店舗識別情報とテーブルを識別するためのテーブル識別情報とを含むものであって店舗に応じた所定数の注文ＵＲＬを含む注文ＵＲＬ情報とを関連付けて記憶するステップと、
顧客端末から前記顧客端末が識別タグを読み込むことにより取得した前記注文ＵＲＬによるリクエストを受け付けるステップと、
前記メニュー情報と他言語に翻訳された翻訳メニュー情報と関連付けて記憶するステップと、
前記顧客端末から言語情報を取得するステップと、
前記言語情報により特定される言語による前記メニュー情報又は前記翻訳メニュー情報に基づき前記顧客端末に送信する注文ページデータを作成するステップを含むことを特徴とする注文管理方法。
【請求項４】
前記翻訳メニュー情報と翻訳管理情報とを関連付けて記憶するステップを含み、
前記翻訳メニュー情報は、前記メニュー情報の機械翻訳による翻訳情報を含むものであり、
前記翻訳メニュー情報のうち対応する情報が前記翻訳管理情報に存在するか否かを判断するステップを含み、
前記翻訳管理情報が存在する場合には、前記翻訳管理情報を優先することを特徴とする請求項３に記載の注文管理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、例えば飲食店等における注文において、特に、携帯情報端末を用いた注文管理装置および注文管理方法に関する。
【背景技術】
【０００２】
従来から、飲食店などにおいて注文を受け付けるにあたって、例えば、各テーブル等に注文用のタッチパネル式端末等の専用端末を設置し、顧客がその端末を操作し、その画面に表示されるメニューや個数を選択し、その結果を注文データとして送信し、管理装置等を介して厨房などに知らせるものが知られている。
【０００３】
さらに、そうした専用端末を利用することなく、顧客自身の所有するスマートフォン等の携帯情報端末等を利用してメニューを閲覧し、注文を行うことができる装置および方法が知られている。例えば、特許文献１に示すように、予め二次元コード等による識別タグを飲食店のテーブル毎に設置し、この識別タグを顧客自身の所有のスマートフォン等の携帯情報端末により読み取ることにより注文専用のＵＲＬを取得し、その注文専用ＵＲＬが示す注文管理装置にブラウザを介してアクセスし、メニューなど注文に必要な情報を取得する。これにより、顧客が自身の携帯情報端末の画面に表示されたメニュー情報から所望のメニュー、個数等を選択し、注文仮装置に送信することにより、注文を受け付けるものである。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特許第５８６３９９９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
店舗に訪れる顧客は、その店舗が存在する国の国民だけではなく、様々な国から訪れる可能性があり、特に使用言語が異なる国の顧客が来店した場合には、メニューの説明や注文等の場面において言語の違いよる意思疎通の問題が生ずるおそれがある。
【０００６】
この点、特許文献１による手段によっても、メニュー情報等について原言語によるデータは存在するため、これをもとに所定の他言語の翻訳データを用意することで対処可能な場合もある。しかしながら、メニューについて様々な言語への翻訳データを店舗側に用意させるのは、店舗側に負担を強いることとなる。
【０００７】
翻訳については、既に機械翻訳によるものが種々知られているので、こうした機械翻訳を利用することで店舗の翻訳用意の負担が期待できるが、機械翻訳の翻訳結果はネイティブにとって不自然、不適切な表現が含まれるおそれがある。最もおすすめや売れ筋の商品など、その店舗で特にその内容を正しくアピールしたいメニューや商品が機械翻訳によって不自然、不適切な翻訳となっていた場合は、新規な顧客獲得の弊害になり機会喪失につながる。
【課題を解決するための手段】
【０００８】
本発明は、上記課題に鑑みなされたものであり、以下のような手段もしくはステップを備える装置もしくは方法である。
（１）店舗情報と各店舗におけるメニュー情報と店舗を識別するための店舗識別情報とテーブルを識別するためのテーブル識別情報とを含むものであって店舗に応じた所定数の注文ＵＲＬを含む注文ＵＲＬ情報とを関連付けて記憶する手段と、顧客端末から前記顧客端末が識別タグを読み込むことにより取得した前記注文ＵＲＬによるリクエストを受け付ける手段と、前記メニュー情報と他言語に翻訳された翻訳メニュー情報と関連付けて記憶する手段と、前記顧客端末から言語情報を取得する手段と、前記言語情報により特定される言語による前記メニュー情報又は前記翻訳メニュー情報に基づき前記顧客端末に送信する注文ページデータを作成する手段を備える。
（２）前記翻訳メニュー情報と翻訳管理情報とを関連付けて記憶する手段を備え、前記翻訳メニュー情報は、前記メニュー情報の機械翻訳による翻訳情報を含むものであり、前記翻訳メニュー情報のうち対応する情報が前記翻訳管理情報に存在するか否かを判断する手段を備え、前記翻訳管理情報が存在する場合には、前記翻訳管理情報を優先する。
【発明の効果】
【０００９】
本願発明によれば、顧客自身のスマートフォン等の携帯情報端末を使用して注文が出来き、かつ、専用のアプリケーションのインストール等事前作業を顧客に強いることがないという利点に加え、店舗側にとっても他言語翻訳を用意する負担を軽減しつつ、店舗側が中でも特に正しく顧客に訴えたいメニューや商品については正しい表示とすることができる。
【００１０】
また、本発明によれば、顧客は、事前に顧客端末に専用のアプリケーションの導入作業が必要なく、普及しているブラウザソフトを介して注文等を行うものであるため、ブラウザの言語設定をそのまま用いることで、顧客に言語選択等の手間を与えずに済む。
【図面の簡単な説明】
【００１１】
【図１】本発明に係るハードウェア結び付きの概略図である。
【図２】店舗情報の一例を示す図である。
【図３】メニュー情報の一例を示す図である。
【図４】注文用ＵＲＬ情報の一例を示す図である。
【図５】注文ＵＲＬの一例を示す図である。
【図６】注文用ＵＲＬ情報を更新した際の一例を示す図である。
【図７】注文管理情報の一例を示す図である。
【図８】注文データの一例を示す図である。
【図９】翻訳メニュー情報の一例を示す図である。
【図１０】翻訳管理情報の一例を示す図である。
【発明を実施するための形態】
【００１２】
以下、実施形態について図面を参照しつつ説明する。図１は、必要なハードウェアと、それらの結びつきを示す概略図である。顧客からの注文を受け付け管理するためのサーバ１（注文管理装置）と、顧客が注文の際に利用する顧客端末２（顧客端末）、および飲食店等の店舗において接客等を行うスタッフが使用する店舗端末４（店員端末）とが、インターネット等の通信回線３を介して、データの送受信が可能に接続されている。
【００１３】
サーバ１、顧客端末２および店舗端末４は、データを処理する処理装置、データを記憶する記憶装置と、データを送受信する送信部および受信部をそれぞれ備えている。サーバ１、顧客端末２および店舗端末４の記憶装置には、本発明を実施するためのコンピュータプログラムや所定のデータがそれぞれ記憶されている。処理装置は、当該コンピュータプログラム等による所定の命令に従ってデータの処理を行う。
【００１４】
顧客端末２および店舗端末４は、具体的には、スマートフォンやタブレットＰＣ等の携帯情報端末であってよいが、現在特に広く普及しているという点においてスマートフォンが好適である。これらは、データ表示のための表示手段、データ入力のための入力手段といった、携帯情報端末が一般に備える各種手段を備えているものであればよい。
【００１５】
また、店舗における各テーブルには、識別タグ５があらかじめ備え付けられている。ここで、識別タグ５は、ＮＦＣ（Near Field Communication）規格などによるＩＣタグであってよい。顧客端末２は、識別タグ５に書き込まれている情報を読み取るためのリーダを少なくとも備えており、店舗端末４は、識別タグ５の読み取り・書き込みを行うためのリーダライタを備えているものとする。
【００１６】
以下、本発明について、各手段が記憶している情報およびそれらの処理の流れについて説明する。サーバ１には、図２および図３に示すような「店舗情報」および「メニュー情報」が関連付けて記憶されている。店舗情報としては、例えば、「店舗識別情報、店名、テーブル数、住所、電話番号、店舗紹介情報」等が含まれ、メニュー情報には、「メニュー識別番号、店舗識別情報、メニュー名、価格」等が含まれる。
【００１７】
なお、ここで、店舗情報を所定の言語に翻訳した情報である翻訳店舗情報は、店舗情報と関連付けて記憶されており、また、メニュー情報についても、図９に示すように、メニュー情報を所定の言語で翻訳した情報である翻訳メニュー情報と関連付けて記憶されているものとする。
【００１８】
また、サーバ１は、図４に示すように、「店舗情報」の、特に店舗識別情報と関連付くようにテーブル単位で「注文ＵＲＬ」を記憶している。「注文ＵＲＬ」の構造は、図５のとおりである。すなわち、図５に示すように、「注文ＵＲＬ（https://www.xxx.jp/order/store.html?qr=QR-0001_1）」には、「店舗情報」と関連付くように「店舗識別情報」（図５に示す例では、「0001」）および「テーブル識別情報」（図５に示す例では、「1」）が含まれている。このように、「注文ＵＲＬ」は、各店舗におけるテーブル単位でユニークに割り当てられているものである。また、「注文用ＵＲＬ情報」は、これら注文ＵＲＬ各々に対応する情報として「アクセス可否」が含まれる。
【００１９】
店舗端末４は、サーバ１から、該当する店舗の注文ＵＲＬ情報を取得し、記憶している。例えば、店舗端末４がサーバ１に該当する店舗識別情報を送信し、サーバ１がこの店舗識別情報に基づいて「注文ＵＲＬ情報」を検索し、抽出された注文ＵＲＬを店舗端末４に送信するようにすればよい。
【００２０】
以下、実際の接客の場面を想定しつつ、具体的な処理の流れについて説明する。ここでは、図２に示す店舗情報のうち、「店舗識別情報：０００１，店名：ＡＡ店，テーブル数：５」に示す例に基づいて説明する。
【００２１】
＜注文前処理＞
ＡＡ店の店員は、来店した顧客を、店舗内にあるテーブル（１）乃至（５）の全５つのテーブルの中からテーブル（２）に案内した。ここで、このＡＡ店の店員は、自身が持つ店舗端末４を操作し、これに記憶されている注文用ＵＲＬ情報から、その案内したテーブル（２）に対応する注文ＵＲＬを、すなわち、図４における例では、「https://www.xxx.jp/order/store.html?qr=QR-0001_2」を、リーダライタを介して、そのテーブルの識別タグ５ｂに書き込む。
【００２２】
店舗端末４を介して、テーブル（２）の識別タグ５ｂに正しく注文ＵＲＬが書き込まれたことが確認された場合、店舗端末４は、サーバ１に、この後顧客が自身の顧客端末２から注文を可能とするために、つまり、顧客端末２から当該注文ＵＲＬが示す注文用ウェブサイトへアクセスを可能にするため、「アクセス可要求データ」を送信する。
【００２３】
具体的には、「アクセス可要求データ」は、テーブル（２）の識別タグ５ｂに書き込んだ注文ＵＲＬ（もしくは、店舗識別情報およびテーブル識別情報のみ）を含むデータであって、店舗端末４は、これを作成し、サーバ１に送信する。
【００２４】
「アクセス可要求データ」を受信したサーバ１は、記憶されている「注文用ＵＲＬ情報」を検索し、該当する注文ＵＲＬに対応する「アクセス可否」情報を、アクセス「不可」からアクセス「可」に更新して記憶する（図６）。後述するが、これにより顧客が自身の顧客端末２から該当する注文ＵＲＬが示す注文用ウェブサイトへのアクセスが可能となる。
【００２５】
＜注文受付処理＞
「注文前処理」が完了後、顧客は、自身の持つ顧客端末２を操作して、顧客端末２のＮＦＣリーダを介して、テーブル（２）の識別タグ５ｂから、店舗端末４により書き込まれた注文ＵＲＬ「https://www.xxx.jp/order/store.html?qr=QR-0001_2」を読み込む。顧客端末２は、読み込んだその注文ＵＲＬを含む「注文ページ要求データ」をサーバ１に送信し、サーバ１の注文用ウェブサイトにアクセスする。
【００２６】
注文ページ要求データのサーバ１への送信により、サーバ１は顧客端末２にインストールされているブラウザソフトの言語情報を取得する。サーバ１の顧客端末２からの言語情報の取得は、既に知られている方法を適宜使用すればよい。例えば、ここでは、顧客端末２は注文ＵＲＬで特定されるサーバ（ここでは、サーバ１）にリクエストするが、その際のリクエストに含まれる各種ヘッダ情報に含まれる言語情報を取得するようにすればよい。
【００２７】
アクセスを受けたサーバ１は、当該注文用ＵＲＬへのアクセスを許可するか否かを判別する。すなわち、サーバ１は、「注文用ＵＲＬ情報」を検索して、該当する注文ＵＲＬに関連付けられている「アクセス可否」を参照する。
【００２８】
この「アクセス可否」が「可」の場合、サーバ１があらかじめ用意している注文用ウェブサイトを表示させるため、当該注文ＵＲＬに含まれる「店舗識別情報」に基づき「メニュー情報」検索抽出し、所定のフォームデータと共に注文ページデータを作成し、顧客端末２へ送信する。
【００２９】
サーバ１は、前述のように、顧客端末２から言語情報を取得しているので、サーバ１は、この注文ページデータをその言語情報が示す言語を使用し作成する。具体的には、サーバ１は、取得した言語情報により使用言語を特定し、その言語情報を抽出し、注文ページデータを作成する。
【００３０】
注文ページデータには、大きく分けて、どの店舗においても使用される画面のフォームデータに含まれる共通データと、店舗によって異なるメニュー情報や店舗情報といった個別データがある。共通データについても予め所定の言語に翻訳された翻訳データを関連付けて記憶しておき、それを言語情報により特定して利用すればよい。
【００３１】
個別データについても同様に、言語情報により特定される言語を判別し、その言語によるメニュー情報を利用すればよい。サーバ１は、こうして特定された言語による注文ページデータを作成し、顧客端末２に返す。こうすることで、顧客は、顧客端末２に最初に表示される画面から、その顧客が普段使用している言語による表示とすることができる。
【００３２】
なお、「アクセス可否」情報が、「否」の場合は、この処理を行わない。この場合、サーバ１から顧客端末２に対し、単に「表示できません」等のメッセージを送信するようにしてもよい。
【００３３】
顧客は、当該注文用ページから、所望のメニューおよび個数などを選択し、注文の操作を行う。顧客端末２は、選択されたメニューおよび指定された個数などの個別の注文情報と注文用ＵＲＬを含む注文データを作成し、サーバ１に送信する。図７に示すように、サーバ１は、当該注文データを受信し、注文用ＵＲＬに含まれる「店舗識別情報」および「テーブル識別情報」と関連付けて「注文管理情報」として、順次記憶する。
【００３４】
このように、「注文管理情報」は、「店舗識別情報」および「テーブル識別情報」を記憶するので、店舗ごとだけでなく、各店舗のテーブル単位での注文に関する情報の管理が可能となる。なお、「注文管理情報」、複数人からなる１グループにより複数の顧客端末２から注文や、同一店舗同一テーブルの利用ながら時間の前後による別人もしくは別グループ単位での注文などを集計するために、別途他の識別情報を関連付けて記憶するなどすればよい。
【００３５】
＜完了処理＞
顧客が支払うべき金額は、注文管理情報を基づき算出する。店舗識別情報、テーブル識別情報、もしくは、その他の識別情報に基づき注文した内容および金額等の必要情報を会計単位で適宜抽出し集計する。このとき、集計された金額等の必要情報を顧客端末２や店舗端末４に表示させるようにしてもよい。
【００３６】
また、顧客が店舗を後にする際には、店員は、店舗端末４を用いて、そのテーブルの注文ＵＲＬを利用不可にするための完了処理を行う。店員は、店舗端末４を操作して、サーバ１に「アクセス不可要求データ」をする。この例においては、「アクセス不可要求データ」には、テーブル（２）の「注文ＵＲＬ（https://www.xxx.jp/order/store.html?qr=QR-0001_2）」が含まれる。なお、ここでは、「注文用ＵＲＬ情報」を検索し、該当する注文ＵＲＬを特定できればよいので、「店舗識別情報」および「テーブル識別情報」のみを送信するようにしてもよい。
【００３７】
「アクセス不可要求データ」を受信したサーバ１は、「注文用ＵＲＬ情報」を検索し、該当する「アクセス可否」を「可」から「不可」に更新して記憶する。以後の顧客端末２から同注文ＵＲＬが示す注文用ウェブサイトへのアクセスは不可となる。これにより、いたずら等による不正な注文を防止できる。
【００３８】
＜翻訳情報の準備に関する処理＞
以上、主に顧客が実際に注文する際の流れについて説明してきたが、以下においては、店舗情報、メニュー情報、および、それらの翻訳情報である翻訳店舗情報および翻訳メニュー情報の準備に関して、特にメニュー情報について説明する。
【００３９】
サーバ１には、所定の一の言語によるその店舗のメニューに関する情報が、店舗端末４よりメニュー名やメニューの説明に係る情報を受け付けて、前述のとおりメニュー情報として記憶される。以下、当該一の言語を原言語という。
【００４０】
サーバ１は、原言語によるメニュー情報のメニュー名やメニュー説明情報などの必要情報を機械翻訳し、その翻訳結果である翻訳データを原言語によるメニュー情報と関連付けて翻訳メニュー情報として記憶する（図９）。機械翻訳の手段や方法は要旨ではないので詳説しないが、既知のものを適宜利用すればよい。所定の翻訳プログラムをインストールしてサーバ１に機械翻訳部を備えるようにしてもよいし、通信回線２を介して外部のＡＳＰが提供しているサービスを利用するようにしてもよい。
【００４１】
機械翻訳による翻訳はネイティブからすると不自然な表現や、そもそも意味的に間違っている表現といった問題のある内容が含まれている可能性がある。そのため、店舗は、こうした問題のある翻訳データを可能な限り排除する必要がある。
【００４２】
店舗側は、この機械翻訳による翻訳データを原言語データと逐一比較し確認しながら直接修正するようにしてもよいが、多言語に翻訳されたすべての翻訳データが正しく自然な表現であるかを確認するのは非常に困難であり、また、確認漏等が発生するおそれもある。
【００４３】
そのため、店舗は、翻訳管理情報を作成し、翻訳メニュー情報と関連付けて記憶する（図１０）。この翻訳管理情報は、「店舗識別情報、メニュー識別情報、適正翻訳情報」等を関連付けて記憶するものである。翻訳管理情報は、店舗として、おすすめのメニュー、人気のあるメニュー、もしくは機械翻訳によって不適切な表現なっているメニューや、機械翻訳によると不適切な表現になりがちな表現が含まれるメニューなど、店舗として必要と考えるメニュー個別に作成する。
【００４４】
サーバ１は、顧客端末２からのリクエストに答えてその店舗のメニュー情報等を提供するために注文ページデータを作成するとき、翻訳管理ファイルに該当するデータがある場合は、その翻訳管理情報に記憶されている対応する適正翻訳情報を優先的に抽出する。抽出に際しては、店舗識別情報、メニュー識別情報、言語情報が関連付けられているので、それらをもとに検索抽出できる。
【００４５】
以上のように、表示されるメニュー名等について、機械翻訳と店舗側が自ら作成する翻訳とを利用することによって、店舗側としては、自ら全てのメニュー名等に翻訳を用意する手間が省けると共に、多言語への対応が容易になるというメリットがあり、さらに、機械翻訳では間違った表現になっているものや、おすすめメニュー等の店舗側が特に拘った表現にしたいもの等については個別に適正表現にし、または、店舗側が所望する表現にすることができる。
【００４６】
さらに、こうした翻訳メニュー情報、翻訳管理情報等の必要な情報は、店舗識別情報やメニュー識別情報によって互いに関連付けられているので、顧客だけでなく店舗側としても翻訳による利益を享受できる。たとえば、ある店舗において、顧客が中国語による表示を所望し、店舗スタッフが英語による表示を所望するような状況に対しても、顧客端末２には中国語による表示をし、店舗端末４には英語による表示をする、というように、翻訳情報を柔軟に提供することができる。
【００４７】
本発明は、以上の例に限定されない。たとえば、サーバ１は単一のハードウェアである必要はなく、複数のハードウェアから構成されるものであってよい。これまで説明した各種データの種類若しくは関連付け方についても、前述の説明で述べたような、データベースにおけるテーブル、ファイル等の構造に限定されるものではなく、必要に応じて各データが参照できる構造になっていればよい。
【００４８】
また、識別タグは、ＮＦＣ等のＩＣタグであるとして説明してきたが、これに限定されない。たとえば、ＱＲコード（登録商標）等の二次元コードを用いてもよい。例えば、店舗の各テーブルに対応した注文ＵＲＬを内容とする二次元コードを各テーブルに設置する。顧客端末２および店舗端末４については、ＩＣタグ用のリーダライタは不要であり、付属のカメラ機能を介した既知の読み取り手段を用いてよい。店員は、顧客をテーブルに案内した際、店舗端末４により二次元コードを読み取り、サーバ１にアクセスし、該当する「アクセス可否」を「可」に更新させるようにすればよい。
【００４９】
なお、前述の説明では、注文前処理として店舗端末４から顧客端末２によるアクセス可否を決定する操作を行うようにしているが、これは必須としなくてよい。また、前述の店舗端末４による注文前処理に代えて別の処理を行うようにしてもよい。例えば、識別タグのすぐ近傍にパスワードを表示しておき、利用開始時に顧客端末２からそのパスワードを送信するよう促し、そのパスワードが適正であると判定された場合に、それ以降のアクセスを可とするようにしてもよい。
【００５０】
また、翻訳店舗情報、翻訳メニュー情報は、前述の説明では、機械翻訳により翻訳データを用意するようにしているが、機械翻訳の時間やコスト削減のために、一度行った機械翻訳結果をキャッシュしておき、再度機械翻訳を行う場合には、そのキャッシュを参照し、追加、変更箇所のみ機械翻訳にまわすようにしてもよい。
【００５１】
注文ＵＲＬについては、図５等において具体的に示したが、こうしたものに限定されない。顧客端末２においてはアクセス先を特定でき、サーバ１においては店舗識別情報とテーブル識別情報を認識できればよい。
【００５２】
上記説明については、決済の手段については特に言及していないが、現在知られている各種の手段、例えば、各種電子マネーによる決済を適用するようにしてもよい。
【００５３】
これまで、飲食店におけるテーブル単位で説明をしてきたが、これに限られない。例えば、野球場その他のスポーツ競技場などにおいては、識別タグを各座席に設置し、その座席ごとの識別タグに各々注文ＵＲＬを保持させるようにしてもよい。
【符号の説明】
【００５４】
１  サーバ
２  顧客端末
３  通信回線
４  店舗端末
５  識別タグ
【図１】
2019061566.tif 000003
【図２】
2019061566.tif 000004
【図３】
2019061566.tif 000005
【図４】
2019061566.tif 000006
【図５】
2019061566.tif 000007
【図６】
2019061566.tif 000008
【図７】
2019061566.tif 000009
【図８】
2019061566.tif 000010
【図９】
2019061566.tif 000011
【図１０】
2019061566.tif 000012