(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2022-01-24
(45)【発行日】2022-02-01
(54)【発明の名称】注文管理装置および注文管理方法
(51)【国際特許分類】
G06Q 50/12 20120101AFI20220125BHJP
【FI】
G06Q50/12
(21)【出願番号】P 2017186892
(22)【出願日】2017-09-27
【審査請求日】2020-07-30
(31)【優先権主張番号】P 2017184073
(32)【優先日】2017-09-25
(33)【優先権主張国・地域又は機関】JP
(73)【特許権者】
【識別番号】500227392
【氏名又は名称】株式会社 ジェイテック
(74)【代理人】
【識別番号】100062225
【氏名又は名称】秋元 輝雄
(74)【代理人】
【識別番号】100186060
【氏名又は名称】吉澤 大輔
(74)【代理人】
【識別番号】100145458
【氏名又は名称】秋元 正哉
(72)【発明者】
【氏名】濱島 博和
【審査官】岸 健司
(56)【参考文献】
【文献】特許第5863999(JP,B1)
【文献】国際公開第2015/129040(WO,A1)
【文献】特開2013-069074(JP,A)
【文献】特開2017-021762(JP,A)
(58)【調査した分野】(Int.Cl.,DB名)
G06Q 10/00-99/00
(57)【特許請求の範囲】
【請求項1】
店舗情報と各店舗におけるメニュー情報と店舗を識別するための店舗識別情報とテーブルを識別するためのテーブル識別情報とを含むものであって店舗に応じた所定数の注文URLを含む注文URL情報とを関連付けて記憶する手段と、
顧客端末から前記顧客端末が識別タグを読み込むことにより取得した前記注文URLによるリクエストを受け付ける手段と、
前記メニュー情報と他言語に翻訳された翻訳メニュー情報と
を関連付けて記憶する手段と、
前記顧客端末から言語情報を取得する手段と、
前記言語情報により特定される言語による前記メニュー情報又は前記翻訳メニュー情報に基づき前記顧客端末に送信する注文ページデータを作成する手段
と、
前記翻訳メニュー情報と翻訳管理情報とを関連付けて記憶する手段と、
を備え、
前記翻訳メニュー情報は、前記メニュー情報の機械翻訳による翻訳情報を含むものであり、
更に、前記翻訳メニュー情報のうち対応する情報が前記翻訳管理情報に存在するか否かを判断する手段を備え、
前記翻訳管理情報が存在する場合には、前記翻訳管理情報を優先することを特徴とする注文管理装置。
【請求項2】
注文管理装置が、
店舗情報と各店舗におけるメニュー情報と店舗を識別するための店舗識別情報とテーブルを識別するためのテーブル識別情報とを含むものであって店舗に応じた所定数の注文URLを含む注文URL情報とを関連付けて記憶するステップと、
顧客端末から前記顧客端末が識別タグを読み込むことにより取得した前記注文URLによるリクエストを受け付けるステップと、
前記メニュー情報と他言語に翻訳された翻訳メニュー情報と
を関連付けて記憶するステップと、
前記顧客端末から言語情報を取得するステップと、
前記言語情報により特定される言語による前記メニュー情報又は前記翻訳メニュー情報に基づき前記顧客端末に送信する注文ページデータを作成するステップ
と、
前記翻訳メニュー情報と翻訳管理情報とを関連付けて記憶するステップと、
を実行し、
前記翻訳メニュー情報は、前記メニュー情報の機械翻訳による翻訳情報を含むものであり、
更に、前記注文管理装置が、前記翻訳メニュー情報のうち対応する情報が前記翻訳管理情報に存在するか否かを判断するステップを実行し、
前記翻訳管理情報が存在する場合には、前記翻訳管理情報を優先することを特徴とする注文管理方法。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、例えば飲食店等における注文において、特に、携帯情報端末を用いた注文管理装置および注文管理方法に関する。
【背景技術】
【0002】
従来から、飲食店などにおいて注文を受け付けるにあたって、例えば、各テーブル等に注文用のタッチパネル式端末等の専用端末を設置し、顧客がその端末を操作し、その画面に表示されるメニューや個数を選択し、その結果を注文データとして送信し、管理装置等を介して厨房などに知らせるものが知られている。
【0003】
さらに、そうした専用端末を利用することなく、顧客自身の所有するスマートフォン等の携帯情報端末等を利用してメニューを閲覧し、注文を行うことができる装置および方法が知られている。例えば、特許文献1に示すように、予め二次元コード等による識別タグを飲食店のテーブル毎に設置し、この識別タグを顧客自身の所有のスマートフォン等の携帯情報端末により読み取ることにより注文専用のURLを取得し、その注文専用URLが示す注文管理装置にブラウザを介してアクセスし、メニューなど注文に必要な情報を取得する。これにより、顧客が自身の携帯情報端末の画面に表示されたメニュー情報から所望のメニュー、個数等を選択し、注文仮装置に送信することにより、注文を受け付けるものである。
【先行技術文献】
【特許文献】
【0004】
【発明の概要】
【発明が解決しようとする課題】
【0005】
店舗に訪れる顧客は、その店舗が存在する国の国民だけではなく、様々な国から訪れる可能性があり、特に使用言語が異なる国の顧客が来店した場合には、メニューの説明や注文等の場面において言語の違いよる意思疎通の問題が生ずるおそれがある。
【0006】
この点、特許文献1による手段によっても、メニュー情報等について原言語によるデータは存在するため、これをもとに所定の他言語の翻訳データを用意することで対処可能な場合もある。しかしながら、メニューについて様々な言語への翻訳データを店舗側に用意させるのは、店舗側に負担を強いることとなる。
【0007】
翻訳については、既に機械翻訳によるものが種々知られているので、こうした機械翻訳を利用することで店舗の翻訳用意の負担が期待できるが、機械翻訳の翻訳結果はネイティブにとって不自然、不適切な表現が含まれるおそれがある。最もおすすめや売れ筋の商品など、その店舗で特にその内容を正しくアピールしたいメニューや商品が機械翻訳によって不自然、不適切な翻訳となっていた場合は、新規な顧客獲得の弊害になり機会喪失につながる。
【課題を解決するための手段】
【0008】
本発明は、上記課題に鑑みなされたものであり、以下のような手段もしくはステップを備える装置もしくは方法である。
(1)店舗情報と各店舗におけるメニュー情報と店舗を識別するための店舗識別情報とテーブルを識別するためのテーブル識別情報とを含むものであって店舗に応じた所定数の注文URLを含む注文URL情報とを関連付けて記憶する手段と、顧客端末から前記顧客端末が識別タグを読み込むことにより取得した前記注文URLによるリクエストを受け付ける手段と、前記メニュー情報と他言語に翻訳された翻訳メニュー情報と関連付けて記憶する手段と、前記顧客端末から言語情報を取得する手段と、前記言語情報により特定される言語による前記メニュー情報又は前記翻訳メニュー情報に基づき前記顧客端末に送信する注文ページデータを作成する手段を備える。
(2)前記翻訳メニュー情報と翻訳管理情報とを関連付けて記憶する手段を備え、前記翻訳メニュー情報は、前記メニュー情報の機械翻訳による翻訳情報を含むものであり、前記翻訳メニュー情報のうち対応する情報が前記翻訳管理情報に存在するか否かを判断する手段を備え、前記翻訳管理情報が存在する場合には、前記翻訳管理情報を優先する。
【発明の効果】
【0009】
本願発明によれば、顧客自身のスマートフォン等の携帯情報端末を使用して注文が出来き、かつ、専用のアプリケーションのインストール等事前作業を顧客に強いることがないという利点に加え、店舗側にとっても他言語翻訳を用意する負担を軽減しつつ、店舗側が中でも特に正しく顧客に訴えたいメニューや商品については正しい表示とすることができる。
【0010】
また、本発明によれば、顧客は、事前に顧客端末に専用のアプリケーションの導入作業が必要なく、普及しているブラウザソフトを介して注文等を行うものであるため、ブラウザの言語設定をそのまま用いることで、顧客に言語選択等の手間を与えずに済む。
【図面の簡単な説明】
【0011】
【
図1】本発明に係るハードウェア結び付きの概略図である。
【
図6】注文用URL情報を更新した際の一例を示す図である。
【発明を実施するための形態】
【0012】
以下、実施形態について図面を参照しつつ説明する。
図1は、必要なハードウェアと、それらの結びつきを示す概略図である。顧客からの注文を受け付け管理するためのサーバ1(注文管理装置)と、顧客が注文の際に利用する顧客端末2(顧客端末)、および飲食店等の店舗において接客等を行うスタッフが使用する店舗端末4(店員端末)とが、インターネット等の通信回線3を介して、データの送受信が可能に接続されている。
【0013】
サーバ1、顧客端末2および店舗端末4は、データを処理する処理装置、データを記憶する記憶装置と、データを送受信する送信部および受信部をそれぞれ備えている。サーバ1、顧客端末2および店舗端末4の記憶装置には、本発明を実施するためのコンピュータプログラムや所定のデータがそれぞれ記憶されている。処理装置は、当該コンピュータプログラム等による所定の命令に従ってデータの処理を行う。
【0014】
顧客端末2および店舗端末4は、具体的には、スマートフォンやタブレットPC等の携帯情報端末であってよいが、現在特に広く普及しているという点においてスマートフォンが好適である。これらは、データ表示のための表示手段、データ入力のための入力手段といった、携帯情報端末が一般に備える各種手段を備えているものであればよい。
【0015】
また、店舗における各テーブルには、識別タグ5があらかじめ備え付けられている。ここで、識別タグ5は、NFC(Near Field Communication)規格などによるICタグであってよい。顧客端末2は、識別タグ5に書き込まれている情報を読み取るためのリーダを少なくとも備えており、店舗端末4は、識別タグ5の読み取り・書き込みを行うためのリーダライタを備えているものとする。
【0016】
以下、本発明について、各手段が記憶している情報およびそれらの処理の流れについて説明する。サーバ1には、
図2および
図3に示すような「店舗情報」および「メニュー情報」が関連付けて記憶されている。店舗情報としては、例えば、「店舗識別情報、店名、テーブル数、住所、電話番号、店舗紹介情報」等が含まれ、メニュー情報には、「メニュー識別番号、店舗識別情報、メニュー名、価格」等が含まれる。
【0017】
なお、ここで、店舗情報を所定の言語に翻訳した情報である翻訳店舗情報は、店舗情報と関連付けて記憶されており、また、メニュー情報についても、
図9に示すように、メニュー情報を所定の言語で翻訳した情報である翻訳メニュー情報と関連付けて記憶されているものとする。
【0018】
また、サーバ1は、
図4に示すように、「店舗情報」の、特に店舗識別情報と関連付くようにテーブル単位で「注文URL」を記憶している。「注文URL」の構造は、
図5のとおりである。すなわち、
図5に示すように、「注文URL(https://www.xxx.jp/order/store.html?qr=QR-0001_1)」には、「店舗情報」と関連付くように「店舗識別情報」(
図5に示す例では、「0001」)および「テーブル識別情報」(
図5に示す例では、「1」)が含まれている。このように、「注文URL」は、各店舗におけるテーブル単位でユニークに割り当てられているものである。また、「注文用URL情報」は、これら注文URL各々に対応する情報として「アクセス可否」が含まれる。
【0019】
店舗端末4は、サーバ1から、該当する店舗の注文URL情報を取得し、記憶している。例えば、店舗端末4がサーバ1に該当する店舗識別情報を送信し、サーバ1がこの店舗識別情報に基づいて「注文URL情報」を検索し、抽出された注文URLを店舗端末4に送信するようにすればよい。
【0020】
以下、実際の接客の場面を想定しつつ、具体的な処理の流れについて説明する。ここでは、
図2に示す店舗情報のうち、「店舗識別情報:0001,店名:AA店,テーブル数:5」に示す例に基づいて説明する。
【0021】
<注文前処理>
AA店の店員は、来店した顧客を、店舗内にあるテーブル(1)乃至(5)の全5つのテーブルの中からテーブル(2)に案内した。ここで、このAA店の店員は、自身が持つ店舗端末4を操作し、これに記憶されている注文用URL情報から、その案内したテーブル(2)に対応する注文URLを、すなわち、
図4における例では、「https://www.xxx.jp/order/store.html?qr=QR-0001_2」を、リーダライタを介して、そのテーブルの識別タグ5bに書き込む。
【0022】
店舗端末4を介して、テーブル(2)の識別タグ5bに正しく注文URLが書き込まれたことが確認された場合、店舗端末4は、サーバ1に、この後顧客が自身の顧客端末2から注文を可能とするために、つまり、顧客端末2から当該注文URLが示す注文用ウェブサイトへアクセスを可能にするため、「アクセス可要求データ」を送信する。
【0023】
具体的には、「アクセス可要求データ」は、テーブル(2)の識別タグ5bに書き込んだ注文URL(もしくは、店舗識別情報およびテーブル識別情報のみ)を含むデータであって、店舗端末4は、これを作成し、サーバ1に送信する。
【0024】
「アクセス可要求データ」を受信したサーバ1は、記憶されている「注文用URL情報」を検索し、該当する注文URLに対応する「アクセス可否」情報を、アクセス「不可」からアクセス「可」に更新して記憶する(
図6)。後述するが、これにより顧客が自身の顧客端末2から該当する注文URLが示す注文用ウェブサイトへのアクセスが可能となる。
【0025】
<注文受付処理>
「注文前処理」が完了後、顧客は、自身の持つ顧客端末2を操作して、顧客端末2のNFCリーダを介して、テーブル(2)の識別タグ5bから、店舗端末4により書き込まれた注文URL「https://www.xxx.jp/order/store.html?qr=QR-0001_2」を読み込む。顧客端末2は、読み込んだその注文URLを含む「注文ページ要求データ」をサーバ1に送信し、サーバ1の注文用ウェブサイトにアクセスする。
【0026】
注文ページ要求データのサーバ1への送信により、サーバ1は顧客端末2にインストールされているブラウザソフトの言語情報を取得する。サーバ1の顧客端末2からの言語情報の取得は、既に知られている方法を適宜使用すればよい。例えば、ここでは、顧客端末2は注文URLで特定されるサーバ(ここでは、サーバ1)にリクエストするが、その際のリクエストに含まれる各種ヘッダ情報に含まれる言語情報を取得するようにすればよい。
【0027】
アクセスを受けたサーバ1は、当該注文用URLへのアクセスを許可するか否かを判別する。すなわち、サーバ1は、「注文用URL情報」を検索して、該当する注文URLに関連付けられている「アクセス可否」を参照する。
【0028】
この「アクセス可否」が「可」の場合、サーバ1があらかじめ用意している注文用ウェブサイトを表示させるため、当該注文URLに含まれる「店舗識別情報」に基づき「メニュー情報」検索抽出し、所定のフォームデータと共に注文ページデータを作成し、顧客端末2へ送信する。
【0029】
サーバ1は、前述のように、顧客端末2から言語情報を取得しているので、サーバ1は、この注文ページデータをその言語情報が示す言語を使用し作成する。具体的には、サーバ1は、取得した言語情報により使用言語を特定し、その言語情報を抽出し、注文ページデータを作成する。
【0030】
注文ページデータには、大きく分けて、どの店舗においても使用される画面のフォームデータに含まれる共通データと、店舗によって異なるメニュー情報や店舗情報といった個別データがある。共通データについても予め所定の言語に翻訳された翻訳データを関連付けて記憶しておき、それを言語情報により特定して利用すればよい。
【0031】
個別データについても同様に、言語情報により特定される言語を判別し、その言語によるメニュー情報を利用すればよい。サーバ1は、こうして特定された言語による注文ページデータを作成し、顧客端末2に返す。こうすることで、顧客は、顧客端末2に最初に表示される画面から、その顧客が普段使用している言語による表示とすることができる。
【0032】
なお、「アクセス可否」情報が、「否」の場合は、この処理を行わない。この場合、サーバ1から顧客端末2に対し、単に「表示できません」等のメッセージを送信するようにしてもよい。
【0033】
顧客は、当該注文用ページから、所望のメニューおよび個数などを選択し、注文の操作を行う。顧客端末2は、選択されたメニューおよび指定された個数などの個別の注文情報と注文用URLを含む注文データを作成し、サーバ1に送信する。
図7に示すように、サーバ1は、当該注文データを受信し、注文用URLに含まれる「店舗識別情報」および「テーブル識別情報」と関連付けて「注文管理情報」として、順次記憶する。
【0034】
このように、「注文管理情報」は、「店舗識別情報」および「テーブル識別情報」を記憶するので、店舗ごとだけでなく、各店舗のテーブル単位での注文に関する情報の管理が可能となる。なお、「注文管理情報」、複数人からなる1グループにより複数の顧客端末2から注文や、同一店舗同一テーブルの利用ながら時間の前後による別人もしくは別グループ単位での注文などを集計するために、別途他の識別情報を関連付けて記憶するなどすればよい。
【0035】
<完了処理>
顧客が支払うべき金額は、注文管理情報を基づき算出する。店舗識別情報、テーブル識別情報、もしくは、その他の識別情報に基づき注文した内容および金額等の必要情報を会計単位で適宜抽出し集計する。このとき、集計された金額等の必要情報を顧客端末2や店舗端末4に表示させるようにしてもよい。
【0036】
また、顧客が店舗を後にする際には、店員は、店舗端末4を用いて、そのテーブルの注文URLを利用不可にするための完了処理を行う。店員は、店舗端末4を操作して、サーバ1に「アクセス不可要求データ」をする。この例においては、「アクセス不可要求データ」には、テーブル(2)の「注文URL(https://www.xxx.jp/order/store.html?qr=QR-0001_2)」が含まれる。なお、ここでは、「注文用URL情報」を検索し、該当する注文URLを特定できればよいので、「店舗識別情報」および「テーブル識別情報」のみを送信するようにしてもよい。
【0037】
「アクセス不可要求データ」を受信したサーバ1は、「注文用URL情報」を検索し、該当する「アクセス可否」を「可」から「不可」に更新して記憶する。以後の顧客端末2から同注文URLが示す注文用ウェブサイトへのアクセスは不可となる。これにより、いたずら等による不正な注文を防止できる。
【0038】
<翻訳情報の準備に関する処理>
以上、主に顧客が実際に注文する際の流れについて説明してきたが、以下においては、店舗情報、メニュー情報、および、それらの翻訳情報である翻訳店舗情報および翻訳メニュー情報の準備に関して、特にメニュー情報について説明する。
【0039】
サーバ1には、所定の一の言語によるその店舗のメニューに関する情報が、店舗端末4よりメニュー名やメニューの説明に係る情報を受け付けて、前述のとおりメニュー情報として記憶される。以下、当該一の言語を原言語という。
【0040】
サーバ1は、原言語によるメニュー情報のメニュー名やメニュー説明情報などの必要情報を機械翻訳し、その翻訳結果である翻訳データを原言語によるメニュー情報と関連付けて翻訳メニュー情報として記憶する(
図9)。機械翻訳の手段や方法は要旨ではないので詳説しないが、既知のものを適宜利用すればよい。所定の翻訳プログラムをインストールしてサーバ1に機械翻訳部を備えるようにしてもよいし、通信回線2を介して外部のASPが提供しているサービスを利用するようにしてもよい。
【0041】
機械翻訳による翻訳はネイティブからすると不自然な表現や、そもそも意味的に間違っている表現といった問題のある内容が含まれている可能性がある。そのため、店舗は、こうした問題のある翻訳データを可能な限り排除する必要がある。
【0042】
店舗側は、この機械翻訳による翻訳データを原言語データと逐一比較し確認しながら直接修正するようにしてもよいが、多言語に翻訳されたすべての翻訳データが正しく自然な表現であるかを確認するのは非常に困難であり、また、確認漏等が発生するおそれもある。
【0043】
そのため、店舗は、翻訳管理情報を作成し、翻訳メニュー情報と関連付けて記憶する(
図10)。この翻訳管理情報は、「店舗識別情報、メニュー識別情報、適正翻訳情報」等を関連付けて記憶するものである。翻訳管理情報は、店舗として、おすすめのメニュー、人気のあるメニュー、もしくは機械翻訳によって不適切な表現なっているメニューや、機械翻訳によると不適切な表現になりがちな表現が含まれるメニューなど、店舗として必要と考えるメニュー個別に作成する。
【0044】
サーバ1は、顧客端末2からのリクエストに答えてその店舗のメニュー情報等を提供するために注文ページデータを作成するとき、翻訳管理ファイルに該当するデータがある場合は、その翻訳管理情報に記憶されている対応する適正翻訳情報を優先的に抽出する。抽出に際しては、店舗識別情報、メニュー識別情報、言語情報が関連付けられているので、それらをもとに検索抽出できる。
【0045】
以上のように、表示されるメニュー名等について、機械翻訳と店舗側が自ら作成する翻訳とを利用することによって、店舗側としては、自ら全てのメニュー名等に翻訳を用意する手間が省けると共に、多言語への対応が容易になるというメリットがあり、さらに、機械翻訳では間違った表現になっているものや、おすすめメニュー等の店舗側が特に拘った表現にしたいもの等については個別に適正表現にし、または、店舗側が所望する表現にすることができる。
【0046】
さらに、こうした翻訳メニュー情報、翻訳管理情報等の必要な情報は、店舗識別情報やメニュー識別情報によって互いに関連付けられているので、顧客だけでなく店舗側としても翻訳による利益を享受できる。たとえば、ある店舗において、顧客が中国語による表示を所望し、店舗スタッフが英語による表示を所望するような状況に対しても、顧客端末2には中国語による表示をし、店舗端末4には英語による表示をする、というように、翻訳情報を柔軟に提供することができる。
【0047】
本発明は、以上の例に限定されない。たとえば、サーバ1は単一のハードウェアである必要はなく、複数のハードウェアから構成されるものであってよい。これまで説明した各種データの種類若しくは関連付け方についても、前述の説明で述べたような、データベースにおけるテーブル、ファイル等の構造に限定されるものではなく、必要に応じて各データが参照できる構造になっていればよい。
【0048】
また、識別タグは、NFC等のICタグであるとして説明してきたが、これに限定されない。たとえば、QRコード(登録商標)等の二次元コードを用いてもよい。例えば、店舗の各テーブルに対応した注文URLを内容とする二次元コードを各テーブルに設置する。顧客端末2および店舗端末4については、ICタグ用のリーダライタは不要であり、付属のカメラ機能を介した既知の読み取り手段を用いてよい。店員は、顧客をテーブルに案内した際、店舗端末4により二次元コードを読み取り、サーバ1にアクセスし、該当する「アクセス可否」を「可」に更新させるようにすればよい。
【0049】
なお、前述の説明では、注文前処理として店舗端末4から顧客端末2によるアクセス可否を決定する操作を行うようにしているが、これは必須としなくてよい。また、前述の店舗端末4による注文前処理に代えて別の処理を行うようにしてもよい。例えば、識別タグのすぐ近傍にパスワードを表示しておき、利用開始時に顧客端末2からそのパスワードを送信するよう促し、そのパスワードが適正であると判定された場合に、それ以降のアクセスを可とするようにしてもよい。
【0050】
また、翻訳店舗情報、翻訳メニュー情報は、前述の説明では、機械翻訳により翻訳データを用意するようにしているが、機械翻訳の時間やコスト削減のために、一度行った機械翻訳結果をキャッシュしておき、再度機械翻訳を行う場合には、そのキャッシュを参照し、追加、変更箇所のみ機械翻訳にまわすようにしてもよい。
【0051】
注文URLについては、
図5等において具体的に示したが、こうしたものに限定されない。顧客端末2においてはアクセス先を特定でき、サーバ1においては店舗識別情報とテーブル識別情報を認識できればよい。
【0052】
上記説明については、決済の手段については特に言及していないが、現在知られている各種の手段、例えば、各種電子マネーによる決済を適用するようにしてもよい。
【0053】
これまで、飲食店におけるテーブル単位で説明をしてきたが、これに限られない。例えば、野球場その他のスポーツ競技場などにおいては、識別タグを各座席に設置し、その座席ごとの識別タグに各々注文URLを保持させるようにしてもよい。
【符号の説明】
【0054】
1 サーバ
2 顧客端末
3 通信回線
4 店舗端末
5 識別タグ