JP2023087659A - 情報処理システム、情報処理方法及びプログラム - Google Patents

Abstract

【課題】ユーザの飲食店の利用中に、その飲食店の利用直後に利用可能でユーザに適した他の飲食店をユーザに提案すること。【解決手段】情報処理システムは、サーバと、ユーザ端末のユーザが利用している第１飲食店の各テーブルに設置されたテーブル端末とを有する情報処理システムである。上記テーブル端末は、表示部と、上記第１飲食店のテーブルの利用人数情報と、ジャンル情報及びエリア情報を含む店舗識別情報と、当該第１飲食店の当該利用中のテーブルにおけるメニューの注文情報とを示すコードを生成して上記表示部に表示させる端末制御部と、を有する。上記サーバは、上記ユーザ端末によって読み取られた上記コードが示すコード情報を当該ユーザ端末から受信し、上記受信したコード情報を基に、上記ユーザが上記第１飲食店の利用直後に利用可能な第２飲食店を検索し、上記検索した第２飲食店に関する情報を上記ユーザ端末へ送信する、サーバ制御部を有する。【選択図】図４

Description

本発明は、飲食店においてユーザ端末から送信された注文情報を処理可能な情報処理システム、情報処理方法及びプログラムに関する。

従来から、ある飲食店でユーザが注文した飲食物の情報を基に、他の飲食店の情報を検索してユーザに提案する技術が知られている。

例えば、下記特許文献１には、第１の飲食店において利用客が注文したメニューに応じた注文情報をサーバが受信し、サーバが当該注文情報に基づいて、上記利用客が上記第１の飲食店を退出後に行く第２の飲食店を選択し、選択した上記第２の飲食店を特定する情報と上記第１の飲食店を特定する情報を少なくとも含むコード情報（クーポン等）を生成し、当該注文情報の送信元の第１の飲食店の店舗端末に上記コード情報を送信し、当該店舗端末がコード情報をレシート等に印刷して利用客に手渡すことが記載されている。

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

しかしながら、上記のような従来技術においては、飲食店を利用したユーザに他の飲食店が提案されるのは当該飲食店の利用が終了した時点であり、そうするとユーザはそこから他の飲食店の予約確認等を行う必要があり、また当該他の飲食店に空席が無い場合にはその飲食店を利用することはできない。

以上のような事情に鑑み、本発明の目的は、ユーザの飲食店の利用中に、その飲食店の利用直後に利用可能でユーザに適した他の飲食店をユーザに提案することが可能な情報処理システム、情報処理装置、情報処理方法及びプログラムを提供することにある。

上記目的を達成するため、本発明の一形態に係る情報処理システムは、サーバと、ユーザ端末のユーザが利用している第１飲食店に設置された店舗側端末とを有する情報処理システムである。上記店舗側端末は、上記第１飲食店のテーブルの利用人数情報と、ジャンル情報及びエリア情報を含む店舗識別情報と、当該第１飲食店の当該利用中のテーブルにおけるメニューの注文情報とを示すコードを生成して上記テーブルに設置された表示部に表示させる端末制御部と、を有する。上記サーバは、上記ユーザ端末によって読み取られた上記コードが示すコード情報を当該ユーザ端末から受信し、上記受信したコード情報を基に、上記ユーザが上記第１飲食店の利用直後に利用可能な第２飲食店を検索し、上記検索した第２飲食店に関する情報を上記ユーザ端末へ送信する、サーバ制御部を有する。

この構成により情報処理システムは、ユーザが利用中の飲食店の情報や当該飲食店での注文情報等を示すコードをテーブルの表示部に表示させユーザ端末に読み取らせることで、ユーザの飲食店の利用中に、その飲食店の利用直後に利用可能で（空席を有し）ユーザに適した他の飲食店をユーザに提案することができる。店舗側端末は、店舗内の各テーブルに設置され各テーブル端末と接続された飲食店端末であってもよいし、各テーブルのテーブル端末であってもよい。前者の場合、表示部はテーブル端末が担い、後者の場合、テーブル端末が店舗側端末と表示部を兼ねることになる。当該情報処理システムは、１つまたは複数の情報処理装置によって構成されうる。コードは例えば２次元バーコードであるがこれに限られない。

上記端末制御部は、上記注文情報が更新されるたびに上記コード情報を更新して上記表示部に表示させてもよい。

これにより情報処理システムは、注文情報が更新されるたびに累積的に検索精度を向上させ、よりユーザに適した他の飲食店を提案することが可能となる。

上記端末制御部は、上記注文情報が所定数蓄積された場合に上記コード情報を上記表示部に表示させてもよい。

これにより情報処理システムは、注文情報が所定数蓄積されて初めてコードを表示することで、ユーザに適した他の飲食店を検索するための検索条件としての情報量を確保し、ユーザに適しない他の飲食店が提案されるのを防ぐことができる。

上記端末制御部は、上記注文情報が所定種類蓄積された場合に上記コードを上記表示部に表示させてもよい。

これにより情報処理システムは、注文情報が所定種類蓄積されて初めてコードを表示することで、ユーザに適した他の飲食店を検索するための検索条件としての情報量を確保し、ユーザに適しない他の飲食店が提案されるのを防ぐことができる。

上記端末制御部は、上記第１飲食店の利用開始時刻情報または利用終了予定時刻情報を上記コードに含ませてもよい。

これにより情報処理システムは、ユーザが第１の飲食店の利用終了時刻から間を置かずに利用可能な第２の飲食店を検索してユーザに提案することができる。

上記端末制御部は、上記メニューの注文頻度が所定値以下の場合、または、所定時間以上注文が無い場合に上記コードを上記表示部に表示させてもよい。

これにより情報処理システムは、注文頻度が下がった場合や注文がしばらく無い場合にはユーザがその飲食店のメニューに飽きたかその飲食店の利用終了が近いと考えられることから、そのタイミングで他の飲食店を提案することで提案の効果を高めることができる。

本発明の他の形態に係る情報処理システムは、通信部と制御部とを有する。上記通信部は、第１飲食店に設置された店舗側端末または当該各テーブルを利用するユーザのユーザ端末と通信する。上記制御部は、上記ユーザ端末のユーザが利用している上記第１飲食店のテーブルの利用人数情報と、ジャンル情報及びエリア情報を含む店舗識別情報と、当該第１飲食店の当該利用中のテーブルにおけるメニューの注文情報とを上記店舗側端末または上記ユーザ端末から受信する。そして制御部は、上記受信した情報を基に、上記ユーザが上記第１飲食店の利用直後に利用可能な第２飲食店を検索し、上記検索した第２飲食店に関する情報を上記ユーザ端末へ送信する。

本発明の他の形態に係る情報処理方法は、
ユーザ端末のユーザが利用している第１飲食店のテーブルの利用人数情報と、ジャンル情報及びエリア情報を含む店舗識別情報と、当該第１飲食店の当該利用中のテーブルにおけるメニューの注文情報とを含むコードを生成して、上記テーブルに設置された表示部に表示し、
上記ユーザ端末によって読み取られた上記コードが示すコード情報を当該ユーザ端末から受信し、
上記受信したコード情報を基に、上記ユーザが上記第１飲食店の利用直後に利用可能な第２飲食店を検索し、
上記検索した第２飲食店に関する情報を上記ユーザ端末へ送信する、ことを含む。

本発明の他の形態に係るプログラムは、情報処理装置に、
ユーザが利用している第１飲食店のテーブルの利用人数情報と、ジャンル情報及びエリア情報を含む店舗識別情報と、当該第１飲食店の当該利用中のテーブルにおけるメニューの注文情報とを、上記第１飲食店に設置された店舗側端末または上記ユーザのユーザ端末から受信するステップと、
上記受信した情報を基に、上記ユーザが上記第１飲食店の利用直後に利用可能な第２飲食店を検索するステップと、
上記検索した第２飲食店に関する情報を上記ユーザ端末へ送信するステップと、を実行させる。

以上説明したように、本発明によれば、ユーザの飲食店の利用中に、その飲食店の利用直後に利用可能でユーザに適した他の飲食店をユーザに提案することができる。しかし、当該効果は本発明を限定するものではない。

本発明の一実施形態に係る飲食店提案システムの構成を示した図である。 本発明の一実施形態に係る飲食店情報提供サーバのハードウェア構成を示した図である。る。 本発明の一実施形態に係るテーブル端末のハードウェア構成を示した図である。る。 本発明の一実施形態に係る飲食店情報提供サーバが有するデータベースの構成を示した図である。 本発明の一実施形態に係るテーブル端末によるコード表示処理の流れを示したフローチャートである。 本発明の一実施形態に係るテーブル端末が表示する画面の例を示した図である。 本発明の一実施形態に係る飲食店情報提供サーバによる飲食店検索処理の流れを示したフローチャートである。 本発明の一実施形態に係る飲食店情報提供サーバが生成してユーザ端末に表示される飲食店検索結果表示画面の例を示した図である。

以下、図面を参照しながら、本発明の実施形態を説明する。

［システムの構成］
図１は、本実施形態に係る飲食店提案システムの構成を示した図である。

同図に示すように、このシステムは、インターネット５０上の飲食店情報提供サーバ１００と、複数の飲食店の各テーブルＴに設置されたテーブル端末（ＴＴＯ（Table Top Order）端末）２００と、飲食店の各テーブルＴを利用する複数のユーザのユーザ端末３００と、各飲食店に設置された飲食店端末４００とを含む。

飲食店情報提供サーバ１００は、飲食店に関する情報を掲載したポータルサイトを運営するウェブサーバである。飲食店情報提供サーバ１００は、複数のユーザ端末３００及び複数の飲食店の飲食店端末４００とインターネット５０を介して接続されている。

飲食店情報提供サーバ１００は、上記ポータルサイトにおいて、ユーザ端末３００のユーザ向けに飲食店情報の検索システムを提供する。具体的には、飲食店情報提供サーバ１００は、ユーザ端末３００からの検索要求に基づいて検索条件に合致する飲食店情報を検索し、検索結果を掲載したＷｅｂページを生成してユーザ端末３００へ送信する。また飲食店情報提供サーバ１００は、当該飲食店情報を閲覧したユーザのユーザ端末３００からの、いずれかの飲食店に対する予約受付処理を代行する。

また飲食店情報提供サーバ１００は、上記ポータルサイトに掲載される飲食店（加盟店）向けに、飲食店情報の管理画面（Ｗｅｂページ）を提供している。飲食店端末４００のユーザは、当該管理画面を介して、上記検索結果として一般ユーザに提供されるＷｅｂページ上の飲食店情報（コンテンツ）を編集・更新し、当該Ｗｅｂページを上記ポータルサイト上にアップロードすることができる。

テーブル端末２００（２００Ａ，２００Ｂ，…）は、飲食店の各テーブルＴを利用するユーザから注文を受け付けるための端末であり、例えばタブレットＰＣ（Personal Computer）である。テーブル端末２００は、例えばタッチパネルとしても機能する表示部上に飲食店のメニューの注文画面を表示し、当該注文画面を介してユーザの注文の入力を受け付けると、受け付けた注文情報を飲食店の厨房の端末（図示せず）へ送信する。

またテーブル端末２００は、受け付けた注文情報を蓄積し、ユーザから会計処理の要求を受け付けると、飲食店のＰＯＳ端末（図示せず）と連携して会計処理を実行する。

ユーザ端末３００（２００Ａ，２００Ｂ，２００Ｃ...）は、ユーザにより使用される端末であり、例えばスマートフォン、携帯電話、タブレットＰＣ等である。ユーザ端末３００は、飲食店情報提供サーバ１００へアクセスし、上記Ｗｅｂページを受信してブラウザ等により画面に表示する。

ユーザ端末３００は、ユーザの操作に基づいて飲食店の検索条件を決定し、当該検索条件に基づく飲食店検索要求を飲食店情報提供サーバ１００へ送信する。本実施形態では、飲食店の所在エリア（最寄駅）やジャンル、価格帯等、予め設定された検索条件をユーザ端末３００のユーザが選択することで、予約可能な飲食店の検索要求の送信が可能である。そしてユーザ端末３００は、ユーザの操作に基づいて、上記検索結果として表示されたいずれかの飲食店に対する予約要求を飲食店情報提供サーバ１００へ送信可能である。

飲食店端末４００は、各飲食店に設置されている端末であり、タブレットＰＣ、ノートブックＰＣ、デスクトップＰＣ等である。飲食店端末４００は、管理者の操作に基づいて、上記飲食店情報の編集・更新等、自身の飲食店情報に関する処理を飲食店情報提供サーバ１００との通信により実行することが可能である。

また本実施形態では、テーブル端末２００は、ユーザによるテーブルＴの利用中に、当該ユーザの利用人数情報、当該テーブル端末２００が設置された飲食店のジャンル情報及びエリア情報を含む店舗識別情報、当該テーブルＴにおけるメニューの注文情報と含むコードを生成して、表示部に表示することができる。コード情報は例えば２次元バーコードであるが、これに限られない。

ユーザ端末３００は、当該コード情報を読み取ると、当該コード情報を飲食店情報提供サーバ１００へ送信する。飲食店情報提供サーバ１００は、ユーザ端末３００から受信したコード情報に含まれる情報を基に、当該ユーザが現在利用中の飲食店の利用直後に利用可能な（空席を有する）他の飲食店を検索し、当該検索した飲食店をユーザ端末３００のユーザに提案する。この飲食店検索処理の詳細については後述する。

［飲食店情報提供サーバのハードウェア構成］
図２は、上記飲食店情報提供サーバ１００のハードウェア構成を示した図である。同図に示すように、飲食店情報提供サーバ１００は、ＣＰＵ（Central Processing Unit）１１（サーバ制御部）、ＲＯＭ（Read Only Memory）１２、ＲＡＭ（Random Access Memory）１３、入出力インタフェース１５、及び、これらを互いに接続するバス１４を備える。

ＣＰＵ１１は、必要に応じてＲＡＭ１３等に適宜アクセスし、各種演算処理を行いながら飲食店情報提供サーバ１００の各ブロック全体を統括的に制御する。ＲＯＭ１２は、ＣＰＵ１１に実行させるＯＳ、プログラムや各種パラメータなどのファームウェアが固定的に記憶されている不揮発性のメモリである。ＲＡＭ１３は、ＣＰＵ１１の作業用領域等として用いられ、ＯＳ、実行中の各種アプリケーション、処理中の各種データを一時的に保持する。

入出力インタフェース１５には、表示部１６、操作受付部１７、記憶部１８、通信部１９等が接続される。

表示部１６は、例えばＬＣＤ（Liquid Crystal Display）、ＯＥＬＤ（Organic ElectroLuminescence Display）、ＣＲＴ（Cathode Ray Tube）等を用いた表示デバイスである。

操作受付部１７は、例えばマウス等のポインティングデバイス、キーボード、タッチパネル、その他の入力装置である。操作受付部１７がタッチパネルである場合、そのタッチパネルは表示部１６と一体となり得る。

記憶部１８は、例えばＨＤＤ（Hard Disk Drive）や、フラッシュメモリ（ＳＳＤ；Solid State Drive）、その他の固体メモリ等の不揮発性メモリである。当該記憶部１８には、上記ＯＳや各種アプリケーション、各種データが記憶される。

特に本実施形態では、記憶部１８は、飲食店情報提供サーバ１００が後述する注文受付処理、ユーザ属性判定処理及び通知情報の生成処理を実行するためのアプリケーションその他のプログラムを記憶している。後述するが、記憶部１８は、そのようなデータを含むデータベースとして、飲食店情報データベース、ユーザ情報データベース、コード情報データベース、及びコード情報データベースを有している。

通信部１９は、例えばEthernet用のＮＩＣ（Network Interface Card）や無線ＬＡＮ等の無線通信用の各種モジュールであり、上記ユーザ端末３００及び飲食店端末４００との間の通信処理を担う。

［テーブル端末のハードウェア構成］
図３は、上記テーブル端末２００のハードウェア構成を示した図である。同図に示すように、テーブル端末２００は、飲食店情報提供サーバ１００と同様に、ＣＰＵ２１（端末制御部）、ＲＯＭ２２、ＲＡＭ２３、バス２４、入出力インタフェース２５、表示部２６、操作受付部２７、記憶部２８、通信部２９を備える。

上述のように、表示部２６及び操作受付部２７は例えばタッチパネルである。記憶部２８には、当該テーブル端末２００が設置されたテーブルＴのユーザの利用人数情報や、ユーザによるテーブルＴの利用開始からユーザから受け付けた注文情報等が蓄積される。利用人数情報は例えばユーザにより入力されるが、例えばテーブルＴに設置されたセンサにより検知された人数が利用人数情報として入力されてもよい。また記憶部２８には、上記上記注文情報等からコードを生成するために必要なプログラムも記憶される。通信部２９は、上記キッチン端末やＰＯＳ端末との通信を担う。

図示しないが、ユーザ端末３００及び飲食店端末４００のハードウェア構成も、基本的には飲食店情報提供サーバ１００及びテーブル端末２００と同様である。

［飲食店情報提供サーバのデータベース構成］
図３は、上記飲食店情報提供サーバ１００が有するデータベースの構成を示した図である。

同図に示すように、飲食店情報提供サーバ１００は、記憶部１８に、飲食店情報データベース３１、ユーザ情報データベース３２、ＰＯＳ情報データベース３３、及び通知情報データベース３４を有している。

飲食店情報データベース３１は、飲食店毎に、その飲食店の店名、所在位置（住所または緯度経度）情報、エリア情報、アクセス情報（最寄り駅情報、最寄り駅からの徒歩距離情報）電話番号、その飲食店を識別するＩＤ（店舗ＩＤ）、その飲食店の業態・サービスのカテゴリ情報、その飲食店を紹介する情報（店舗のＰＲ文等の店舗の特徴を示す情報、飲食店が行うイベント情報等）、飲食店に関する（飲食店を紹介する）画像データ、飲食店が提供するメニューに関するメニュー情報、平均予算情報、営業時間、ウェブサイトＵＲＬ等の情報等を記憶している。これらの情報は、各飲食店の飲食店端末４００から、飲食店情報提供サーバ１００が提供する管理画面を介して入力されたものである。

上記メニュー情報は、上記ポータルサイト上の各飲食店のサイトに掲載されるメニューに対応する情報であり、各飲食店が提供可能な複数のメニューのメニュー名を、飲食店毎に記憶している。当該メニュー情報は、例えば前菜／メイン、ランチ／ディナー／コース等のメニューカテゴリ毎に記憶されてもよい。またメニュー情報としては、メニュー名や値段、説明等を示す文字情報の他、当該メニューを撮影した写真等の画像情報も対応付けて記憶される。

上記エリア情報としては、広さ単位の異なる複数のエリアに関する情報が含まれる。広いエリアとしては例えば都道府県や市区町村、狭いエリアとしては例えば駅から数百ｍ以内（例えば、「銀座エリア」）、それらの間の広さのエリアとして、例えば駅から１ｋｍ以内のエリアや、複数の駅周辺エリアがまとまったエリア（例えば、「銀座・新橋・有楽町エリア」）等が挙げられるが、これらに限られない。これにより、同じ飲食店でも、その広さによって複数のエリアに紐付けられていることになる。

上記カテゴリ情報は、例えば和食、中華、イタリアン、フレンチ、焼肉等のメインカテゴリの他、和食における焼き鳥・天ぷら等、イタリアンにおけるパスタ・ピザ等のより詳細なサブカテゴリを含んでいてもよい。

ユーザ情報データベース３２は、ユーザ端末３００を所有する、上記飲食店情報提供サーバ１００が提供する上記ポータルサイトを介した飲食店情報サービスの利用者（会員）であるユーザに関する情報を記憶する。具体的には、ユーザ情報データベース３２は、ユーザＩＤ、パスワード、氏名、メールアドレス（その他、メッセージの宛先となる情報）、電話番号、住所、年齢（層）、性別、誕生日等の情報をユーザ毎に記憶している。

コード情報データベース３３は、各飲食店の各テーブルＴのユーザ端末３００から受信したコード情報を記憶する。コード情報は、上述のように、各テーブルＴのユーザの利用人数情報、当該テーブル端末２００が設置された飲食店のジャンル情報及びエリア情報を含む店舗識別情報、当該テーブルＴにおけるメニューの注文情報を含む。これらの情報が、飲食店を識別する店舗ＩＤごと、及びテーブルＴを識別するテーブルＩＤごとに記憶される。

これら各データベースは、後述する飲食店情報提供サーバ１００による飲食店検索処理において、必要に応じて相互に参照されて用いられる。

［システムの動作］
次に、以上のように構成されたシステム（テーブル端末２００及び飲食店情報提供サーバ１００）の動作について説明する。当該動作は、テーブル端末２００のＣＰＵ２１、飲食店情報提供サーバ１００のＣＰＵ１等のハードウェアと、記憶部２８及び記憶部１８に記憶されたソフトウェアとの協働により実行される。以下の説明では、便宜上、ＣＰＵ２１及びＣＰＵ１１を動作主体とする。

まず、テーブル端末２００による、コード表示処理について説明する。図５は、当該コード表示処理の流れを示したフローチャートである。

同図に示すように、テーブル端末２００のＣＰＵ２１はまず、ユーザにより表示部２６を介して、テーブル端末２００が設置されたテーブルＴの利用開始入力を受け付けた否かを判断する（ステップ５１）。

テーブルＴの利用開始入力には、当該テーブルＴを利用するユーザの利用人数に関する情報が含まれる。ＣＰＵ２１は、上記利用開始入力を受け付けたと判断した場合（ステップ５１のＹｅｓ）、利用人数情報を記憶部２８に記憶する。

続いてＣＰＵ２１は、表示部２６（タッチパネル）を介してユーザからメニューの注文を受け付けたか否かを判断する（ステップ５３）。

注文を受け付けたと判断した場合（ステップ５３のＹｅｓ）、ＣＰＵ２１は、注文対象のメニューを識別するメニューＩＤ、注文数量、及び当該メニューのカテゴリを示すカテゴリＩＤ等を含む注文情報を厨房端末へ送信するとともに、当該注文情報を記憶部２８に記憶する（ステップ５４）。

続いてＣＰＵ２１は、上記記憶部２８に蓄積された、当該テーブルＴにおける利用開始以降の注文数が所定数以上であるか否かを判断する（ステップ５５。）所定数は例えば５個、１０個等であるがこれらに限られない。

注文数が所定数以上であると判断した場合（ステップ５５のＹｅｓ）、ＣＰＵ２１は、上記記憶した利用人数情報、注文情報に加えて、当該テーブル端末２００が設置された飲食店の店舗識別情報（店舗のジャンル情報及び所在エリア情報）を示すコードを生成する（ステップ５６）。上記ジャンル情報及び所在エリア情報は記憶部２８に予め記憶されている。コードは例えば２次元バーコードであるが、これに限られない。

所定数が所定数未満であると判断した場合（ステップ５５のＮｏ）、ＣＰＵ２１は上記ステップ５３に戻り追加の注文を待機する。

続いてＣＰＵ２１は、上記生成したコードＣを表示部２６に表示する（ステップ５７）。

図６は、テーブル端末２００が表示する画面の例を示した図である。同図に示すように、表示部２６には、「本日のおすすめ」「飲み物」等のメニューを表示させるためのボタンや会計処理を実行するためのボタンが表示されるほか、例えばその右下隅に、上記生成されたコードＣが表示される。

当該コードＣとともに、当該コードＣが、ユーザが現在利用中の飲食店（第１飲食店）の利用終了直後に利用可能な他の飲食店（第２飲食店）を検索するためのものであることをユーザに示す、例えば「２軒目を検索」といったテキスト情報が表示されてもよい。

当該コードＣは、ユーザ端末３００のバーコードリーダー等により読み取りが可能であり、後述するように、当該コードＣがユーザ端末３００に読み取られると（または読み取りによりユーザ端末３００に表示される画面上で飲食店検索が指示されると）、当該コードＣが飲食店情報提供サーバ１００へ送信される。

続いてＣＰＵ２１は、上記会計用のボタン等を介して、ユーザからテーブルＴの利用終了（会計要求）を受け付けたか否かを判断する（ステップ５８）。

利用終了を受け付けたと判断した場合（ステップ５８のＹｅｓ）、ＣＰＵ２１は、上記ＰＯＳ端末と連携して会計処理を実行する（ステップ５９）。

利用終了が受け付けられない限りは（ステップ５８のＮｏ）、ＣＰＵ２１は、上記ステップ５３に戻りそれ以降の処理を繰り返す。すなわちＣＰＵ２１は、注文情報が更新されるたびに上記コードＣを更新して上記表示部２６に表示させる。

次に、上記表示されたコード情報に基づく飲食店情報提供サーバ１００による飲食店検索処理について説明する。図７は、当該飲食店検索処理の流れを示したフローチャートである。

同図に示すように、飲食店情報提供サーバ１００のＣＰＵ１１はまず、テーブル端末２００に表示されたコードＣを読み取ったユーザ端末３００から当該コード情報を受信したか否かを判断する（ステップ７１）。

コード情報を受信したと判断した場合（ステップ７１のＹｅｓ）、ＣＰＵ１１は、コード情報が示す利用人数情報、店舗識別情報（ジャンル情報及びエリア情報）、注文情報を基に飲食店検索条件を設定する（ステップ７２）。

具体的には、ＣＰＵ１１は、利用人数情報及びエリア情報はそのまま検索条件として採用する一方、ジャンル情報及び注文情報については、ＮＯＴ検索（マイナス検索）条件として設定してもよい。またそれ以外にＣＰＵ１１は、利用時刻条件として現在時刻または所定時間（１０分後、３０分後等の短い時間）経過後の時刻を設定する。

すなわち、ユーザは、現在利用中の飲食店の利用直後に利用する飲食店としては、現在利用中の飲食店とはジャンルやメニューが異なる飲食店を望む場合が多いと考えられる。したがってＣＰＵ１１は、現在利用中の飲食店のジャンルと、現在利用中の飲食店でユーザが注文したメニューを検索条件から除外することで、現在利用中の飲食店の周辺において、現在利用中の飲食店とは異なるジャンル及び異なるメニューを提供し、現在利用可能な（空席を有する）飲食店を検索しユーザに提案することができる。

ＣＰＵ１１はこれとは逆に、例えばユーザのメニューに対するこだわりが強い場合（例えばワインが飲める店にしか行きたくない等）を考慮して、ジャンル情報及び注文情報についてもそのまま上記利用人数情報及びエリア情報と共にＡＮＤ検索条件に設定してもよい。

またＣＰＵ１１は、注文情報のうち、特定のカテゴリの注文メニュー（例えば飲み物）のみＡＮＤ検索条件に設定し、他の注文メニュー（例えば食べ物）についてはＮＯＴ検索条件に設定してもよい。またＣＰＵ１１は、注文情報のうち特定のカテゴリの注文メニュー（例えば食べ物）のみを検索条件（例えばＮＯＴ検索条件）に設定してもよいし、特定のカテゴリの注文メニュー（例えば飲み物）を除いた注文メニューを検索条件（例えばＡＮＤ検索条件）に設定してもよい。

続いてＣＰＵ１１は、上記設定した検索条件で上記飲食店情報データベース３１内の飲食店を検索する（ステップ７３）。

続いてＣＰＵ１１は、上記検索条件に合致する飲食店が見つかったか否かを判断する（ステップ７４）。

上記検索条件に合致する飲食店が見つかったと判断した場合（ステップ７４のＹｅｓ）、ＣＰＵ１１は、当該飲食店を示す飲食店検索結果情報を生成して（ステップ７５）、当該飲食店検索結果情報をコード情報送信元のユーザ端末３００へ送信する（ステップ７６）。当該飲食店検索結果情報は、検索された飲食店の名称、ジャンル情報、住所、位置情報（緯度・経度情報）、当該飲食店の情報を掲載したウェブページのＵＲＬ等を含む。

一方、上記検索条件に合致する飲食店が見つからなかったと判断した場合（ステップ７４のＮｏ）、ＣＰＵ１１は、検索結果無しの旨を示す情報をユーザ端末３００へ通知する（ステップ７７）。

図８は、上記飲食店検索結果情報を基にユーザ端末３００に表示される表示画面の例を示した図である。

各ユーザ端末３００には、上記飲食店情報提供サーバ１００が提供するシステムに対応するアプリケーションがインストールされている。当該アプリケーションは、同図に示すように、飲食店情報提供サーバ１００から受信した飲食店検索結果情報を基に、ＧＰＳ（Global Positioning System）等から取得される現在位置を示すアイコン８１と、上記検索条件に合致する飲食店の所在位置を示すアイコン８２を重畳した地図データを表示可能である。また例えば画面下部にはアイコン８２に対応する飲食店に関する情報（店名やジャンル等のテキストや画像）も表示される。

そしてユーザがいずれかの飲食店のアイコン８２をタップすると、当該飲食店の詳細情報を掲載するとともに当該飲食店の予約を受け付け可能なページが表示され、ユーザは当該ページを介して当該飲食店を予約することが可能となる。

［まとめ］
以上説明したように、本実施形態によれば、飲食店情報提供サーバ１００及びテーブル端末２００は、ユーザが利用中の飲食店の情報や当該飲食店での注文情報等を示すコードＣをテーブル端末２００に表示させユーザ端末３００に読み取らせることで、ユーザの飲食店の利用中に、その飲食店の利用直後に利用可能で（空席を有し）ユーザに適した他の飲食店をユーザに提案することができる。

飲食店情報提供サーバ１００及びテーブル端末２００は、注文情報が所定数蓄積されて初めてコードを表示することで、ユーザに適した他の飲食店を検索するための検索条件としての情報量を確保し、ユーザに適しない他の飲食店が提案されるのを防ぐことができる。

すなわち、上記端末制御部は、上記注文情報が更新されるたびに上記コード情報を更新して上記表示部に表示させる。

さらに飲食店情報提供サーバ１００及びテーブル端末２００は、注文情報が更新されるたびにコードＣを更新して表示させることで、累積的に飲食店の検索精度を向上させ、よりユーザに適した他の飲食店を提案することが可能となる。

［変形例］
本発明は上述の実施形態にのみ限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々変更され得る。

上述の実施形態において、テーブル端末２００は、注文情報が所定数蓄積された場合にコードＣを表示させていたが、これに代えて、またはこれに加えて注文情報が所定種類（カテゴリ）数分蓄積された場合にコードＣを表示させてもよい。

またテーブル端末２００は、ユーザが現在利用中の飲食店の利用開始時刻情報または利用終了予定時刻情報を上記コードＣに含ませてもよい。当該利用開始時刻情報または利用終了予定時刻情報は、ユーザがテーブル端末２００に入力したものであってもよいし、ユーザが飲食店の予約時に飲食店端末４００に入力されテーブル端末２００に転送されたものであってもよい。この場合飲食店情報提供サーバ１００は、利用開始時刻情報が示す時刻の所定時間後（例えば２時間後または３時間後）を検索条件に設定してもよいし、利用終了時刻情報が示す時刻またはその時刻の所定時間後（例えば１０分後、３０分後）を検索条件に設定してもよい。これにより飲食店情報提供サーバ１００は、ユーザが現在利用中の飲食店の利用が終了した後に間を置かずに利用可能な他の飲食店を検索して提案することができる。

上述の実施形態において、上記テーブル端末２００は、ユーザによるメニューの注文頻度が所定値以下の場合、または、所定時間以上注文が無い場合にコードＣを表示部２６に表示させてもよい。所定値とは例えば２回／時間、１回／時間等であり、所定時間とは３０分、１時間等であるがこれらに限られない。注文頻度が下がった場合やしばらく注文が無い場合にはユーザがその飲食店のメニューに飽きたかその飲食店の利用終了が近いと考えられる。したがってテーブル端末２００及び飲食店情報提供サーバ１００は、そのタイミングで他の飲食店を提案することで提案の効果を高めることができる。

上述の実施形態では、店舗側端末としてのテーブル端末２００が、利用人数情報や注文情報の蓄積処理、注文数が所定数以上であるかの判断処理、コードＣの生成処理及びコードＣの表示処理までの全ての処理を担った。しかし、利用人数情報や注文情報の蓄積処理、上記注文数の判断処理、コードＣの生成処理については、各テーブル端末２００に接続された飲食店端末４００が店舗側端末として担い、テーブル端末２００は当該飲食店端末４００が生成したコードＣを飲食店端末４００から受信して表示する表示部としてのみ機能してもよい。この場合飲食店端末４００は注文情報をテーブル端末２００から受信する上記厨房端末であってもよいし、注文情報を受信するとともにテーブル端末２００との間で会計処理を実行するＰＯＳ端末であってもよい。

上述の実施形態では、利用人数情報、店舗識別情報、注文情報は、テーブル端末２００に表示されたコードＣをユーザ端末３００が読み取ることでユーザ端末３００から飲食店情報提供サーバ１００へコード情報として送信された。しかし、これらの情報は、ユーザ端末３００を介さずにテーブル端末２００または飲食店端末４００からユーザ端末３００を介さずに飲食店情報提供サーバ１００へ直接送信されてもよい。この場合飲食店情報提供サーバ１００は、上記図８に示したような飲食店検索結果画面（飲食店提案画面）をテーブル端末２００に表示させてもよい。

上述の実施形態において、飲食店情報提供サーバ１００は、上記図７において注文情報を基に飲食店検索条件を設定する（ステップ７２）際に、ユーザの満腹度を判定し、当該満腹度に応じて検索条件を設定してもよい。

具体的には、飲食店情報提供サーバ１００は、上記飲食店情報データベース３１において、飲食店ごとの客１人当たりの平均注文数または平均客単価を記憶しておき、コード情報に含まれる注文数または支払金額並びに利用人数の情報を基に、客１人当たりの注文数または客単価を算出し、それを上記平均注文数または平均客単価と比較する。そして飲食店情報提供サーバ１００は、客１人当たりの注文数または客単価が平均注文数または平均客単価よりも大きい場合（または所定割合以上大きい場合）には、ユーザは満腹度が高くこれ以上の食事はほとんど必要ないと判断して、検索条件として、例えば飲食店のジャンル「バー」「バル」「パブ」「ラウンジ」「カラオケ」等、料理がメインで提供されない店のジャンルを設定する。一方、客１人当たりの注文数または客単価が平均注文数または平均客単価よりも小さい場合（または所定割合以上小さい場合）には、まだユーザはまだ満腹ではなくある程度食事が必要であると判断して、検索条件として、例えば飲食店のジャンル「居酒屋」「洋食」「中華」等、料理がメインで提供される一般的なレストランのジャンルを設定する。なお上記注文数または支払金額から、飲み物の分を除外してもよい。

また上記客１人当たりの平均注文数または平均客単価以外にも、例えば、飲食店情報提供サーバ１００は、上記飲食店情報データベース３１において、飲食店ごとに、各メニューの一皿当たりの分量またはカロリーを記憶しておき、上記コード情報に含まれる各メニューについて、当該分量またはカロリーの情報を取得してその総数を算出し、当該算出した総数が所定値以上であるか否かに応じて検索条件を設定してもよい。

このように、ユーザが利用中の飲食店において食べた量が類推できる情報を用いて飲食店を検索することで、当該利用中の飲食店におけるユーザの満腹度に応じて、適切な他の飲食店を提案することができる。

上述の実施形態では、クラウド上の飲食店情報提供サーバ１００が複数のユーザ端末向けに飲食店検索処理を実行する例が示されたが、飲食店毎に、上記飲食店情報提供サーバ１００と同様の機能を有するサーバが設置され、上記飲食店検索処理を実行しても構わない。

本願の特許請求の範囲に記載された発明のうち、「情報処理方法」と記載された発明は、その各ステップを、ソフトウェアによる情報処理によりコンピュータ等の少なくとも１つの装置が自動的に行うものであり、人間がコンピュータ等の装置を用いて行うものではない。すなわち、当該「情報処理方法」は、コンピュータ・ソフトウェアによる情報処理方法であって、コンピュータという計算道具を人間が操作する方法ではない。

１１、２１…ＣＰＵ
１８、２８…記憶部
１９、２９…通信部
３１…飲食店情報データベース
３２…ユーザ情報データベース
３３…コード情報データベース
１００…飲食店情報提供サーバ
２００…テーブル端末
３００…ユーザ端末
４００…飲食店端末
Ｃ…コード（２次元バーコード）

Claims (9)

1. サーバと、ユーザ端末のユーザが利用している第１飲食店に設置された店舗側端末とを具備する情報処理システムであって、
   前記店舗側端末は、
   前記第１飲食店のテーブルの利用人数情報と、ジャンル情報及びエリア情報を含む店舗識別情報と、当該第１飲食店の当該利用中のテーブルにおけるメニューの注文情報とを示すコードを生成して前記テーブルに設置された表示部に表示させる端末制御部、を有し、
   前記サーバは、
   前記ユーザ端末によって読み取られた前記コードが示すコード情報を当該ユーザ端末から受信し、
   前記受信したコード情報を基に、前記ユーザが前記第１飲食店の利用直後に利用可能な第２飲食店を検索し、
   前記検索した第２飲食店に関する情報を前記ユーザ端末へ送信する、
   サーバ制御部を有する
   情報処理システム。
2. 請求項１に記載の情報処理システムであって、
   前記端末制御部は、前記注文情報が更新されるたびに前記コードを更新して前記表示部に表示させる
   情報処理システム。
3. 請求項１または２に記載の情報処理システムであって、
   前記端末制御部は、前記注文情報が所定数蓄積された場合に前記コードを前記表示部に表示させる
   情報処理システム。
4. 請求項１または２に記載の情報処理システムであって、
   前記端末制御部は、前記注文情報が所定種類蓄積された場合に前記コードを前記表示部に表示させる
   情報処理システム。
5. 請求項１乃至４のいずれかに記載の情報処理システムであって、
   前記端末制御部は、前記第１飲食店の利用開始時刻情報または利用終了予定時刻情報を前記コードに含ませる
   情報処理システム。
6. 請求項１乃至５のいずれかに記載の情報処理システムであって、
   前記端末制御部は、前記メニューの注文頻度が所定値以下の場合、または、所定時間以上注文が無い場合に前記コードを前記表示部に表示させる
   情報処理システム。
7. 第１飲食店に設置された店舗側端末または当該第１飲食店の各テーブルを利用するユーザのユーザ端末と通信する通信部と、
   前記ユーザ端末のユーザが利用している前記第１飲食店のテーブルの利用人数情報と、ジャンル情報及びエリア情報を含む店舗識別情報と、当該第１飲食店の当該利用中のテーブルにおけるメニューの注文情報とを示すコード情報を前記店舗側端末または前記ユーザ端末から受信し、
   前記受信したコード情報に含まれる情報を基に、前記ユーザが前記第１飲食店の利用直後に利用可能な第２飲食店を検索し、
   前記検索した第２飲食店に関する情報を前記ユーザ端末へ送信する、
   制御部と
   を具備する情報処理システム。
8. ユーザ端末のユーザが利用している第１飲食店のテーブルの利用人数情報と、ジャンル情報及びエリア情報を含む店舗識別情報と、当該第１飲食店の当該利用中のテーブルにおけるメニューの注文情報とを示すコードを生成して、前記テーブルに設置された表示部に表示し、
   前記ユーザ端末によって読み取られた前記コードが示すコード情報を当該ユーザ端末から受信し、
   前記受信したコード情報を基に、前記ユーザが前記第１飲食店の利用直後に利用可能な第２飲食店を検索し、
   前記検索した第２飲食店に関する情報を前記ユーザ端末へ送信する
   情報処理方法。
9. 情報処理装置に、
   ユーザが利用している第１飲食店のテーブルの利用人数情報と、ジャンル情報及びエリア情報を含む店舗識別情報と、当該第１飲食店の当該利用中のテーブルにおけるメニューの注文情報とを示すコード情報を、前記第１飲食店に設置された店舗側端末または前記ユーザのユーザ端末から受信するステップと、
   前記受信したコード情報に含まれる情報を基に、前記ユーザが前記第１飲食店の利用直後に利用可能な第２飲食店を検索するステップと、
   前記検索した第２飲食店に関する情報を前記ユーザ端末へ送信するステップと
   を実行させるプログラム。

Images