JPWO2015129040A1 - 多言語対応受注サーバ、多言語対応受注プログラムおよび多言語対応受注方法 - Google Patents

Abstract

【課題】 初期費用を抑えて導入しやすい構成でありながら、ユーザの使用言語を簡単かつ確実に認識し、使用言語が異なる多種多様なユーザから受注することができる多言語対応受注サーバ、多言語対応受注プログラムおよび多言語対応受注方法を提供する。【解決手段】 ユーザ端末１１に設定されている言語コードを含む、所定の店舗における注文画面へのアクセス要求を前記ユーザ端末１１から受信するアクセス要求受信部４１と、前記言語コードに対応する言語で表記されたユーザ側言語対応注文画面を前記ユーザ端末１１へ送信する注文画面送信部４３を有する。

Description

本発明は、飲食店等における商品・役務の受注技術に関し、特に、外国からの旅行者のように使用言語が異なる多種多様なユーザからの受注を可能とする多言語対応受注サーバ、多言語対応受注プログラムおよび多言語対応受注方法に関するものである。

使用言語が異なる言語圏に行った場合、現地での飲食店で料理を食べたり、小売店で商品を購入することは楽しみの一つであるが、言語がわからないために料理の内容が理解できずに希望と異なる料理を食べることになったり、間違った注文をすることもあり、苦労することが多い。このような問題を解決するために、従来、ユーザが使用言語と異なる言語圏に行った場合でも、飲食店等において、ユーザが所望する料理を簡単に選択することができる技術が提案されている。

例えば、特開２０１０−６７１２０号公報には、一つの料理に対応して複数の言語で表記された料理名を記憶する料理名データベースと、料理名データベースに記憶された各料理に対応して、一以上の料理画像を記憶する料理画像データベースと、任意の言語で料理名を手書入力するためのタッチセンサと、入力された手書き文字を認識する文字認識エンジンと、手書き文字の認識結果に基づいて料理名データベースを参照し、任意の言語に相当する入力言語と料理とを特定すると共に、特定した料理に対応する一以上の料理画像を料理画像データベースから読み出して液晶ディスプレイに表示させるＣＰＵと、を備えたメニュー端末が開示されている（特許文献１）。

特開２０１０−６７１２０号公報

しかしながら、特許文献１に記載された発明においては、ユーザにより手書き入力された文字を認識して入力言語を特定するようになっている。このため、文字に癖があったり、他の言語と紛らわしい文字もあり、認識精度が低く誤認識する場合がある。手書き文字の認識に失敗した場合、ユーザが再入力しなければならず、非常に煩わしいし、再入力しても認識精度が高くなるものではなく、再度失敗することもある。また、特許文献１では、上記認識を失敗した旨や、上記再入力を求めるメッセージを表示するとされているが、入力言語を特定できていなければ、そのメッセージ自体理解できないおそれもある。

また、特許文献１では、料理名データベースや料理画像データベースをメニュー端末ごとに記憶させており、かつ、当該メニュー端末を飲食店内の各テーブルごとに設置している。このため、飲食店ごとに各データベースを構築する必要がある上、オーダー受付端末やアクセスポイントの他に、メニュー端末をテーブルの数だけ用意しなければならず、導入時の初期費用として膨大な費用がかかるという問題もある。

本発明は、このような問題点を解決するためになされたものであって、初期費用を抑えて導入しやすい技術でありながら、ユーザの使用言語を簡単かつ確実に認識し、使用言語が異なる多種多様なユーザから受注することができる多言語対応受注サーバ、多言語対応受注プログラムおよび多言語対応受注方法を提供することを目的としている。

本発明に係る多言語対応受注サーバは、ユーザ端末に設定されている言語コードを含む、所定の店舗における注文画面へのアクセス要求を前記ユーザ端末から受信するアクセス要求受信部と、前記言語コードに対応する言語で表記されたユーザ側言語対応注文画面を前記ユーザ端末へ送信する注文画面送信部とを有する。

また、本発明の一態様として、前記アクセス要求には、前記店舗を識別する店舗ＩＤおよび／または前記店舗内のテーブルを識別するテーブルＩＤが、暗号化された状態で含まれており、これら暗号化店舗ＩＤおよび／または暗号化テーブルＩＤを復号化する暗号化ＩＤ復号化部を有していてもよい。

さらに、本発明の一態様として、前記注文画面送信部は、前記ユーザ側言語対応注文画面による注文を可能とする制限時間が設定されたクッキーを前記ユーザ側言語対応注文画面とともに前記ユーザ端末へ送信してもよい。

また、本発明の一態様として、前記ユーザ側言語対応注文画面で選択された注文情報とともに、前記ユーザ端末の位置情報を前記ユーザ端末から受信する注文・位置情報受信部と、前記位置情報が前記店舗を含む所定エリアの範囲内を示す場合のみ、前記注文情報を受け付ける位置情報判定部とを有していてもよい。

さらに、本発明の一態様として、前記ユーザ端末からの前記注文情報に対応する、前記店舗が指定した言語で表記された店舗側言語対応受注画面を店舗端末へ送信する受注画面送信部を有していてもよい。

本発明に係る多言語対応受注プログラムは、ユーザ端末に設定されている言語コードを含む、所定の店舗における注文画面へのアクセス要求を前記ユーザ端末から受信するアクセス要求受信部と、前記言語コードに対応する言語で表記されたユーザ側言語対応注文画面を前記ユーザ端末へ送信する注文画面送信部としてコンピュータを機能させる。

本発明に係る多言語対応受注方法は、ユーザ端末に設定されている言語コードを含む、所定の店舗における注文画面へのアクセス要求を前記ユーザ端末から受信するアクセス要求受信ステップと、前記言語コードに対応する言語で表記されたユーザ側言語対応注文画面を前記ユーザ端末へ送信する注文画面送信ステップとを有する。

本発明によれば、初期費用を抑えて導入しやすい技術でありながら、ユーザの使用言語を簡単かつ確実に認識し、使用言語が異なる多種多様なユーザから受注することができる。

本発明に係る多言語対応受注サーバを用いた多言語対応受注システムの一実施形態を示す全体図である。 本実施形態において、データベース記憶部に記憶されている各種テーブルを示す図である。 本実施形態において、ユーザ側言語対応注文画面の初期画面の一例を示す図である。 本実施形態のユーザ側言語対応注文画面において、「ｓａｋｅ」カテゴリを展開した画面の一例を示す図である。 本実施形態のユーザ側言語対応注文画面において、注文内容を確定し送信する画面の一例を示す図である。 本実施形態における店舗側言語対応受注画面の一例を示す図である。 本発明に係る多言語対応受注サーバおよび多言語対応受注プログラムによる多言語対応受注方法の一実施形態を示すフローチャート図である。

以下、本発明に係る多言語対応受注サーバ、多言語対応受注プログラムおよび多言語対応受注方法の一実施形態について図面を用いて説明する。

なお、以下の実施形態では、飲食店において料理やドリンク等を受注するシステムに適用した例について説明するが、この適用例に限定されるものではなく、使用言語が異なる多種多様なユーザから商品や役務を受注するシステムであれば、どのような受注システムにも適用可能である。

図１に示すように、本実施形態の多言語対応受注システムは、本発明に係る多言語対応受注サービスを提供する会社等によって運営される多言語対応受注サーバ１と、飲食店の客であるユーザ各人が所有する自身のユーザ端末１１と、前記多言語対応受注サービスに加盟した各飲食店に配備される店舗端末１２とから構成されている。そして、主として、以下のステップが実行されるようになっている。
（１）ユーザ端末１１から多言語対応受注サーバ１へアクセス要求を送信
（２）多言語対応受注サーバ１からユーザ端末１１へユーザ側言語対応注文画面を送信
（３）ユーザ端末１１から多言語対応受注サーバ１へ注文情報・位置情報を送信
（４）多言語対応受注サーバ１から店舗端末１２へ店舗側言語対応注文画面を送信

以下、各構成について詳細に説明する。ユーザ端末１１および店舗端末１２は、スマートフォンやタブレット型コンピュータ等のような携帯型のコンピュータから構成されている。本実施形態において、ユーザ端末１１および店舗端末１２には、無線インターフェースが備えられているとともに、ウェブブラウザがインストールされている。このため、Ｗｉ−Ｆｉ（Wireless Fidelity）回線や３Ｇ（3rd Generation）回線を介してインターネット上のウェブサイトにアクセス可能に構成されている。

また、本実施形態において、ユーザ端末１１に搭載されているウェブブラウザは、Ｗ３Ｃ（World Wide Web Consortium）により規格化されたＧｅｏｌｏｃａｔｉｏｎ ＡＰＩ等のように、ユーザ端末１１の位置情報を取得するＡＰＩ（Application Programming Interface）をサポートしている。このため、ユーザ端末１１は、ＧＰＳ（Global Positioning System）、Ｗｉ−Ｆｉアクセスポイント、ＩＰ（Internet Protocol）アドレス、基地局等に基づく位置情報を多言語対応受注サーバ１へ提供するか否かを選択しうるようになっている。本実施形態では、後述するように、セキュリティを確保するため、ユーザ端末１１が位置情報の提供を拒否した場合、注文情報の送信が禁止されるようになっている。

また、ユーザ端末１１には、デジタルカメラ機能が備えられているとともに、ＱＲコード（登録商標）を読み取り可能なアプリケーションがインストールされている。このため、店舗側から提供される注文用ＱＲコード（登録商標）を読み取るだけで、後述する注文画面のＵＲＬ（Uniform Resource Locator）を容易に取得できるようになっている。

つぎに、多言語対応受注サーバ１は、ウェブサーバ等のコンピュータによって構成されており、図１に示すように、ユーザ端末１１や店舗端末１２と通信するための通信手段２と、本実施形態の多言語対応受注プログラム１ａやデータベースを記憶する記憶手段３と、各種の演算処理を実行し後述する各構成部として機能する演算処理手段４とから構成されている。以下、各手段について詳細に説明する。

通信手段２は、通信インターフェース等によって構成されており、インターネット等を介してユーザ端末１１や店舗端末１２との間で各種のデータを送受信するものである。

記憶手段３は、各種のデータベースを記憶するとともに、演算処理手段４が演算処理を行う際のワーキングエリアとして機能するものである。本実施形態において、記憶手段３は、ＲＯＭ（Read Only Memory）、ＲＡＭ（Random Access Memory）およびフラッシュメモリ等によって構成されており、図１に示すように、プログラム記憶部３１と、データベース記憶部３２とを有している。以下、各構成部についてより詳細に説明する。

なお、本実施形態では、データベース記憶部３２を多言語対応受注サーバ１内の記憶手段３に格納しているが、この構成に限定されるものではない。例えば、多言語対応受注サーバ１とは別に設置されたデータベースサーバ等にデータベース記憶部３２を構築し、当該データベースサーバと多言語対応受注サーバ１との間で通信可能に構成してもよい。

プログラム記憶部３１には、本実施形態の多言語対応受注プログラム１ａがインストールされている。そして、演算処理手段４が、多言語対応受注プログラム１ａを実行することにより、多言語対応受注サーバ１としてのコンピュータを後述する各構成部として機能させるようになっている。

なお、多言語対応受注プログラム１ａの利用形態は、上記構成に限られるものではない。例えば、ＣＤ−ＲＯＭやＤＶＤ−ＲＯＭ等のように、コンピュータで読み取り可能な記録媒体に多言語対応受注プログラム１ａを記憶させておき、当該記録媒体から直接読み出して実行してもよい。また、外部サーバ等からＡＳＰ（Application Service Provider）方式やクラウドコンピューティング方式で利用してもよい。

データベース記憶部３２は、多言語対応受注サービスを提供するのに必要な各種のテーブルデータを記憶するものである。本実施形態において、データベース記憶部３２には、図２に示すように、言語テーブル、店舗テーブル、店舗翻訳テーブル、メニューカテゴリテーブル、メニューカテゴリ翻訳テーブル、料理翻訳テーブル、料理テーブル、テーブル（食卓）テーブル、注文情報テーブルが登録されており、互いに他のテーブルを参照可能に構成されている。

具体的には、言語テーブルには、言語ＩＤに対応づけて複数の言語名（日本語、英語、韓国語等）が登録されている。店舗テーブルには、店舗ＩＤに対応づけて加盟店の店舗名が登録されている。店舗翻訳テーブルには、店舗ＩＤに対応する店舗名が、言語ＩＤに対応する言語で表記された店舗名として登録されている。メニューカテゴリテーブルには、カテゴリＩＤに対応づけて店舗ＩＤが登録されている。メニューカテゴリ翻訳テーブルには、カテゴリＩＤごとに、言語ＩＤに対応する言語で表記されたカテゴリ名が登録されている。料理翻訳テーブルには、料理ＩＤごとに、言語ＩＤに対応する言語で表記された料理名が登録されている。料理テーブルには、料理ＩＤに対応する料理のカテゴリＩＤおよび価格が登録されている。テーブル（食卓）テーブルには、テーブルＩＤに対応づけて、店舗ＩＤに対応する店舗で指定された言語で表記されたテーブル名が登録されている。注文情報テーブルには、注文ＩＤに対応づけて、注文主のテーブルに対応するテーブルＩＤ、注文された料理に対応する料理ＩＤ、および注文された料理の数量が登録されるようになっている。

つぎに、演算処理手段４は、本実施形態の多言語対応受注サービスを実現するための各種の演算処理を実行するものである。本実施形態において、演算処理手段４は、ＣＰＵ（Central Processing Unit）等によって構成されており、記憶手段３にインストールされた多言語対応受注プログラム１ａを実行することにより、図１に示すように、アクセス要求受信部４１と、暗号化ＩＤ復号化部４２と、注文画面送信部４３と、注文・位置情報受信部４４と、位置情報判定部４５と、受注画面送信部４６として機能するようになっている。以下、各構成部についてより詳細に説明する。

アクセス要求受信部４１は、ユーザ端末１１に設定されている言語コードを含む、所定の店舗における注文画面へのアクセス要求をユーザ端末１１から受信するものである。本実施形態において、アクセス要求は、多言語対応受注サーバ１で用意した注文画面のＵＲＬに対して、ユーザ端末１１のウェブブラウザからＨＴＴＰリクエストの形式で送信される。このＨＴＴＰリクエストのヘッダーには、ウェブブラウザで使用されている言語を表すアクセプトランゲージ（Accept-Language）ヘッダーが含まれている。このヘッダーを参照することにより、ユーザ端末１１に設定されている言語コードが判別可能となる。

暗号化ＩＤ復号化部４２は、暗号化店舗ＩＤおよび暗号化テーブルＩＤを復号化するものである。本実施形態において、ユーザ端末１１からのアクセス要求には、店舗を識別する店舗ＩＤおよび店舗内のテーブルを識別するテーブルＩＤが、暗号化された状態で含まれている。具体的には、多言語対応受注サーバ１は、予め所定の暗号方式を用いて店舗ＩＤおよびテーブルＩＤを暗号化し、以下に示すとおり、注文画面のＵＲＬに埋め込む。
http://sekaime.nu:1337/menu_main/暗号化店舗ＩＤ/暗号化テーブルＩＤ/

このため、ユーザ端末１１が上記ＵＲＬにアクセス要求すると、アクセス要求受信部４１では暗号化店舗ＩＤおよび暗号化テーブルＩＤが受信される。これら暗号化店舗ＩＤおよび暗号化テーブルＩＤに対して、暗号化ＩＤ復号化部４２が、暗号化の際に用いた暗号方式に従って復号化し、店舗ＩＤおよびテーブルＩＤを取得するようになっている。

なお、もし店舗ＩＤおよびテーブルＩＤを暗号化しない場合、ユーザ端末１１におけるブラウザのアドレスバー・アクセス履歴、ＱＲリーダーアプリケーション内等には上記ＵＲＬが可視できる状態で残ることとなる。このため、仮に店舗ＩＤおよびテーブルＩＤを推測容易な文字列(００１，００２等)にすると、当該文字列を少し変更するだけで、違う店舗や違うテーブルの注文画面にアクセスできてしまうため、なりすましによる悪意の注文がされるおそれがある。そこで、本実施形態では、店舗ＩＤおよびテーブルＩＤを暗号化し、悪意者によるいたずらの注文情報が送信されるのを防止するように対策が取られている。

また、本実施形態では、複数のテーブルを有する複数の店舗に対して、多言語対応受注サービスを同時に提供しているため、店舗ＩＤおよびテーブルＩＤを使用している。しかしながら、多言語対応受注サーバ１が、一つの店舗に対して単独でサービスを行う場合、店舗ＩＤは不要である。また、店舗内のテーブル数が極めて少ない場合等には、テーブルＩＤを用いなくてもよい。すなわち、暗号化ＩＤ復号化部４２は、店舗の状況に応じて暗号化店舗ＩＤまたは暗号化テーブルＩＤのいずれか一方のみを復号化するものであってもよい。

注文画面送信部４３は、ユーザ端末１１の言語コードに対応する言語で表記されたユーザ側言語対応注文画面をユーザ端末１１へ送信するものである。本実施形態において、注文画面送信部４３は、データベース記憶部３２内の各テーブルデータを参照し、アクセス要求受信部４１で受信された言語コードに対応する言語で、暗号化ＩＤ復号化部４２により復号化された店舗ＩＤに対応する店舗のユーザ側言語対応注文画面を生成し、ユーザ端末１１へ送信する。

ここで、ユーザ側言語が英語である場合のユーザ側言語対応注文画面の一例について説明する。図３は、ユーザ側言語対応注文画面の初期画面であり、料理やドリンクのカテゴリが表示されている。また、図４は、図３におけるいずれかのカテゴリをタップすることにより、当該カテゴリに属する商品群が展開された状態である。さらに、図５は、注文内容を確定し送信する画面であり、選択した商品の希望数量を入力した後、注文ボタン（図５の「Place Your Orders」）をタップすることにより、注文情報としての料理ＩＤおよび数量が送信される。

なお、本実施形態において、注文画面送信部４３は、アクセス要求を受けてからユーザ側言語対応注文画面を生成し送信しているが、この構成に限定されるものではない。すなわち、予め各店舗ごとに全言語に対応する注文画面を生成しておき、アクセス要求があった際には、言語コードおよび店舗ＩＤに対応するユーザ側言語対応注文画面を読み出し、送信処理のみを実行するようにしてもよい。

また、本実施形態において、注文画面送信部４３は、ユーザ側言語対応注文画面による注文を可能とする制限時間が設定されたクッキーをユーザ側言語対応注文画面とともにユーザ端末１１へ送信するようになっている。これにより、当該クッキーがユーザ端末１１のウェブブラウザに保存されてからの経過時間が前記制限時間を超えた場合、注文情報の送信が禁止される。これは、注文画面を表示させたまま、しばらく放置された場合に後から誤って注文情報が送信されたり、退店した後にいたずらで注文情報が送信されることを防止するための対策である。

さらに、本実施形態において、ユーザ側言語対応注文画面は、ユーザ端末１１が注文情報を多言語対応受注サーバ１へ送信する際、ユーザ端末１１の位置情報を要求するように構成されている。これにより、ユーザが位置情報の提供を許可した場合、上述したＡＰＩにより取得された位置情報が、多言語対応受注サーバ１へ送信される。一方、ユーザが位置情報の提供を拒否した場合、注文情報の送信が禁止される。

注文・位置情報受信部４４は、ユーザ側言語対応注文画面で選択された注文情報とともに、ユーザ端末１１の位置情報をユーザ端末１１から受信するものである。本実施形態では、ユーザが、図３から図５に示すようなユーザ側言語対応注文画面において、選択・入力操作を行うことにより、注文情報としての料理ＩＤおよび数量がユーザ端末１１へ送信される。なお、注文情報は、上記に限定されるものではなく、注文に関する情報であれば適宜追加してもよい。

また、本実施形態では、上述したとおり、ユーザ端末１１から注文情報を送信するための条件として、位置情報の提供を要件としている。しかしながら、上記構成に限定されるものではなく、ユーザ端末１１の位置情報に基づくセキュリティを用いない場合、注文・位置情報受信部４４は、ユーザ端末１１から注文情報だけを受信してもよい。

位置情報判定部４５は、位置情報が店舗を含む所定エリアの範囲内を示す場合のみ、注文情報を受け付けるものである。所定エリアは、ユーザ端末１１が店舗内にいるか否かを判定する基準となるものであり、例えば、店舗を中心とする半径１００ｍ以内の範囲や、１００ｍ四方の範囲等を設定することができる。

本実施形態において、位置情報判定部４５は、注文・位置情報受信部４４が受信したユーザ端末１１の位置情報に基づいて、ユーザ端末１１が所定エリア内に存在するか否かを判定する。そして、ユーザ端末１１が所定エリア内に存在する場合のみ、注文情報を受け付ける。これにより、明らかに店舗外から送信された注文情報は、いたずらや誤送信の可能性が高いため、破棄されることとなる。

受注画面送信部４６は、ユーザ端末１１からの注文情報に対応する、店舗が指定した言語で表記された店舗側言語対応受注画面を店舗端末１２へ送信するものである。本実施形態において、受注画面送信部４６は、暗号化ＩＤ復号化部４２により復号化された店舗ＩＤに対応する店舗を送信先とする。また、受注画面送信部４６は、データベース記憶部３２内の各テーブルデータを参照し、暗号化ＩＤ復号化部４２により復号化されたテーブルＩＤに対応するテーブル名、および注文・位置情報受信部４４により受信された注文情報に対応する料理名および受注数を、予め店舗側で指定された言語にて店舗側言語対応受注画面として生成し、上記送信先へ送信する。

ここで、図６は、店舗側で指定した言語が日本語である場合の店舗側言語対応受注画面の一例を示すものである。図６に示すとおり、店舗側言語対応受注画面には、テーブルＩＤに対応するテーブル名、料理ＩＤに対応する料理名、および受注数が表示されている。また、図６では、注文ＩＤに対応するオーダーナンバー、および受注時刻が表示されている。

つぎに、本実施形態の多言語対応受注サーバ１、多言語対応受注プログラム１ａおよび多言語対応受注方法による作用について、図７を用いて説明する。

まず、本発明に係る多言語対応受注サービスを受ける飲食店は、店舗内にあるテーブルごとに注文画面へのＵＲＬを埋め込んだＱＲコード（登録商標）を用意しておく。つぎに、外国人のお客様（以下、異国ユーザという）が来店すると、当該異国ユーザが着席したテーブルに対応するＱＲコード（登録商標）を提示する。この際、「あなたのスマートフォンでＱＲコード（登録商標）を読み取り、注文画面へアクセスして下さい」等のメッセージを複数の言語で記載したボード等を合わせて提示することが好ましい。

つづいて、ＱＲコード（登録商標）の提示を受けた異国ユーザが、ユーザ端末１１を用いて当該ＱＲコード（登録商標）を読み込むと（ステップＳ１）、注文画面へのＵＲＬが取得される。このとき、本実施形態では、ＵＲＬ中に含まれる店舗ＩＤおよびテーブルＩＤが暗号化されている。このため、ＵＲＬ中の文字列を多少変更しても、違う店舗や違うテーブルの注文画面にアクセスできてしまうことがなく、いたずら等による注文が防止される。

つぎに、ユーザ端末１１が、多言語対応受注サーバ１に対して注文画面へのアクセス要求を行うと（ステップＳ２）、アクセス要求受信部４１が当該アクセス要求を受信する（ステップＳ３）。このとき、アクセス要求受信部４１は、当該アクセス要求に係るＨＴＴＰリクエストのヘッダーを参照し、ユーザ端末１１に設定されている言語コードを簡単かつ確実に認識する。

つづいて、暗号化ＩＤ復号化部４２が、アクセス要求に係るＵＲＬに含まれている暗号化店舗ＩＤおよび暗号化テーブルＩＤを復号化する（ステップＳ４）。これにより、多言語対応受注サーバ１では、ユーザ端末１１からのアクセス要求に係る店舗ＩＤおよびテーブルＩＤが安全に取得される。

つぎに、注文画面送信部４３が、ユーザ端末１１の言語コードおよび復号化された店舗ＩＤに基づいてユーザ側言語対応注文画面を生成し、ユーザ端末１１へ送信する（ステップＳ５）。これにより、ユーザ端末１１には、図３および図４に示すようなユーザ側言語対応注文画面が表示される（ステップＳ６）。このため、使用言語が異なる多種多様なユーザに対して、当該異国ユーザの使用言語により表記された注文画面が簡単かつ迅速に提供される。また、当該注文画面は、店舗側の専用端末ではなく、異国ユーザ自身のユーザ端末１１に提供できるため、初期費用がかからず導入しやすい。

また、本実施形態では、注文画面送信部４３が、ユーザ側言語対応注文画面を提供する際に、制限時間付きのクッキーをユーザ端末１１側に保存する。このため、ユーザ端末１１では、図５の注文ボタン等がタップされて注文情報が確定されると（ステップＳ７）、当該クッキーに設定されている制限時間内か否かが判定される（ステップＳ８）。

その判定の結果、クッキーがユーザ端末１１のウェブブラウザに保存されてからの経過時間が制限時間を超えている場合（ステップＳ８：ＮＯ）、注文情報の送信が禁止される（ステップＳ１１）。このため、注文画面を表示させたまま、しばらく放置された場合や退店後等に、誤った注文情報が送信される可能性が低減される。一方、上記経過時間が制限時間内である場合（ステップＳ８：ＹＥＳ）、ユーザ端末１１は、異国ユーザに対して位置情報を提供するか否かを選択させる（ステップＳ９）。

その選択の結果、異国ユーザが位置情報の提供を拒否した場合（ステップＳ９：ＮＯ）、注文情報の送信が禁止される（ステップＳ１１）。これにより、実際に店舗内にいるか否かを把握できないユーザ端末１１からは、注文情報が送信されることがなく、セキュリティ性が向上する。一方、異国ユーザが位置情報の提供を許可した場合のみ（ステップＳ９：ＹＥＳ）、当該位置情報とともに注文情報が多言語対応受注サーバ１へ送信される（ステップＳ１０）。

つぎに、注文・位置情報受信部４４が、ユーザ端末１１から注文情報および位置情報を受信すると（ステップＳ１２）、当該位置情報に基づいて、位置情報判定部４５は、ユーザ端末１１が所定エリア内に存在するか否かを判定する（ステップＳ１３）。その判定の結果、ユーザ端末１１が所定エリア内に存在しない場合（ステップＳ１３：ＮＯ）、受信した注文情報を破棄する（ステップＳ１５）。これにより、明らかに店舗外から送信された注文情報は、いたずらや誤送信の可能性が高いため受け付けずに破棄される。

一方、ユーザ端末１１が所定エリア内に存在する場合（ステップＳ１３：ＹＥＳ）、店舗内にいる異国ユーザからの正規の注文情報と推測される。このため、受注画面送信部４６は、店舗が指定した言語で表記された店舗側言語対応受注画面を生成し、店舗端末１２へ送信する（ステップＳ１４）。これにより、店舗端末１２では、図６に示すように、店舗側で指定した言語によって受注内容が表示されるため、店舗側に起因する受注ミスが低減される。

以上のような本実施形態によれば、以下のような効果を奏する。
１．使用言語が異なる多種多様なユーザに対して、当該ユーザの使用言語に対応する注文画面を提供し受注することができる。
２．ユーザの使用言語を簡単かつ確実に認識することができる。
３．ユーザ自身のユーザ端末１１を使用することで初期費用が抑えられ、小規模な飲食店等でも気軽に導入することができる。
４．店舗ＩＤやテーブルＩＤを暗号化することで、いたずら等による注文情報が送信されるのを防止することができる。
５．注文情報を送信するまでの時間に制限を設けることで、誤った注文情報が送信されるのを防止することができる。
６．店舗外に位置するユーザ端末１１からの注文情報を破棄して、いたずら等による注文情報を防止することができる。
７．店舗側で指定した言語で受注内容を確認でき、必ずしも店員が語学に堪能でなくても注文を受け付けることができ、受注ミスを低減することができる。
８．今まで敬遠がちであった外国人に対しても、積極的に商品・役務を提供する機会を増大することができる。
９．外国人観光客も安心して店舗を利用することができ、満足度を向上させてリピーターを増加することができる。
１０．外国人観光客等の経済活動を活発化させて、観光業の発展に寄与することができる。

なお、本発明に係る多言語対応受注サーバ１、多言語対応受注プログラム１ａおよび多言語対応受注方法は、前述した実施形態に限定されるものではなく、適宜変更することができる。

例えば、上述した本実施形態では、ユーザ端末１１および店舗端末１２として携帯型コンピュータを想定しているが、この構成に限定されるものではない。すなわち、多言語対応受注サーバ１との間で通信可能に構成されているものであれば、ノート型パーソナルコンピュータでもよく、店舗端末１２に至ってはデスクトップ型パーソナルコンピュータでもよい。

また、上述した本実施形態では、ユーザ端末１１に注文画面へのＵＲＬを取得させるための手段として、ＱＲコード（登録商標）を用いている。しかしながら、この構成に限定されるものではなく、他のコードに埋め込んでもよいし、短いＵＲＬを用意して直接入力させるようにしてもよい。

さらに、上述した本実施形態では、ユーザ端末１１としてユーザ自身が所有する端末を利用しているが、この構成に限定されるものではない。例えば、老人や子供等のように、自身のユーザ端末１１を所持していないユーザのために、ユーザ端末１１に相当する端末を店舗側で用意しておいてもよい。

１ 多言語対応受注サーバ
１ａ 多言語対応受注プログラム
２ 通信手段
３ 記憶手段
４ 演算処理手段
１１ ユーザ端末
１２ 店舗端末
３１ プログラム記憶部
３２ データベース記憶部
４１ アクセス要求受信部
４２ 暗号化ＩＤ復号化部
４３ 注文画面送信部
４４ 注文・位置情報受信部
４５ 位置情報判定部
４６ 受注画面送信部

Claims (7)

1. ユーザ端末に設定されている言語コードを含む、所定の店舗における注文画面へのアクセス要求を前記ユーザ端末から受信するアクセス要求受信部と、
   前記言語コードに対応する言語で表記されたユーザ側言語対応注文画面を前記ユーザ端末へ送信する注文画面送信部と
   を有する、多言語対応受注サーバ。
2. 前記アクセス要求には、前記店舗を識別する店舗ＩＤおよび／または前記店舗内のテーブルを識別するテーブルＩＤが、暗号化された状態で含まれており、これら暗号化店舗ＩＤおよび／または暗号化テーブルＩＤを復号化する暗号化ＩＤ復号化部を有している、請求項１に記載の多言語対応受注サーバ。
3. 前記注文画面送信部は、前記ユーザ側言語対応注文画面による注文を可能とする制限時間が設定されたクッキーを前記ユーザ側言語対応注文画面とともに前記ユーザ端末へ送信する、請求項１または請求項２に記載の多言語対応受注サーバ。
4. 前記ユーザ側言語対応注文画面で選択された注文情報とともに、前記ユーザ端末の位置情報を前記ユーザ端末から受信する注文・位置情報受信部と、
   前記位置情報が前記店舗を含む所定エリアの範囲内を示す場合のみ、前記注文情報を受け付ける位置情報判定部と
   を有する、請求項１から請求項３のいずれかに記載の多言語対応受注サーバ。
5. 前記ユーザ端末からの前記注文情報に対応する、前記店舗が指定した言語で表記された店舗側言語対応受注画面を店舗端末へ送信する受注画面送信部を有している、請求項４に記載の多言語対応受注サーバ。
6. ユーザ端末に設定されている言語コードを含む、所定の店舗における注文画面へのアクセス要求を前記ユーザ端末から受信するアクセス要求受信部と、
   前記言語コードに対応する言語で表記されたユーザ側言語対応注文画面を前記ユーザ端末へ送信する注文画面送信部と
   してコンピュータを機能させる、多言語対応受注プログラム。
7. ユーザ端末に設定されている言語コードを含む、所定の店舗における注文画面へのアクセス要求を前記ユーザ端末から受信するアクセス要求受信ステップと、
   前記言語コードに対応する言語で表記されたユーザ側言語対応注文画面を前記ユーザ端末へ送信する注文画面送信ステップと
   を有する、多言語対応受注方法。

Images