特開 2023-114974 情報処理システム、情報処理方法及びプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2023114974

(43)【公開日】2023-08-18

(54)【発明の名称】情報処理システム、情報処理方法及びプログラム

(51)【国際特許分類】

   G06Q 50/10 20120101AFI20230810BHJP

【ＦＩ】

G06Q50/10

【審査請求】未請求

【請求項の数】12

【出願形態】ＯＬ

(21)【出願番号】P 2022190444

(22)【出願日】2022-11-29

(31)【優先権主張番号】P 2022017012

(32)【優先日】2022-02-07

(33)【優先権主張国・地域又は機関】JP

(71)【出願人】

【識別番号】500175565

【氏名又は名称】株式会社ぐるなび

(74)【代理人】

【識別番号】110003339

【氏名又は名称】弁理士法人南青山国際特許事務所

(72)【発明者】

【氏名】森口 智生

【テーマコード（参考）】

5L049

【Ｆターム（参考）】

5L049CC24

(57)【要約】

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

【特許請求の範囲】

【請求項1】

ユーザのユーザ端末と通信する通信部と、
前記ユーザが利用している第１飲食店のテーブルの利用人数情報と、ジャンル情報及びエリア情報を含む店舗識別情報と、当該第１飲食店の当該利用中のテーブルにおけるメニューの注文情報とを含む喫食情報を前記ユーザ端末から受信し、
前記受信された喫食情報を基に、前記ユーザが前記第１飲食店の利用直後に利用可能な第２飲食店を検索し、
前記検索した第２飲食店に関する飲食店情報を前記ユーザ端末へ送信する、
制御部と
を具備し、
前記制御部は、前記ユーザからメニューが新たに注文されるたびに前記ユーザ端末から前記注文情報を受信して蓄積し、前記検索時点までに蓄積されている注文情報を基に前記第２飲食店を検索する
情報処理システム。

【請求項2】

請求項１に記載の情報処理システムであって、
前記制御部は、前記ユーザ端末に対するユーザの操作に基づく検索要求を前記ユーザ端末から受信した場合に前記第２飲食店を検索して前記飲食店情報を送信する
情報処理システム。

【請求項3】

請求項１または２に記載の情報処理システムであって、
前記制御部は、前記注文情報が更新されるたびに、前記第２飲食店を検索して前記飲食店情報を送信する
情報処理システム。

【請求項4】

請求項１乃至３に記載の情報処理システムであって、
前記制御部は、前記注文情報が所定数蓄積された場合に前記第２飲食店を検索して前記飲食店情報を送信する
情報処理システム。

【請求項5】

請求項１乃至４のいずれかに記載の情報処理システムであって、
前記制御部は、前記注文情報が所定種類蓄積された場合に前記第２飲食店を検索して前記飲食店情報を送信する
情報処理システム。

【請求項6】

請求項１乃至５のいずれかに記載の情報処理システムであって、
前記制御部は、前記ユーザ端末から前記メニューの注文の開始時刻を示す情報を受信し、当該開始時刻から所定時間後の時刻を利用時刻に関する検索条件として前記第２飲食店を検索する
情報処理システム。

【請求項7】

請求項１乃至６のいずれかに記載の情報処理システムであって、
前記制御部は、前記メニューの注文頻度が所定値以下の場合、または、所定時間以上注文が無い場合に前記第２飲食店を検索して前記飲食店情報を送信する
情報処理システム。

【請求項8】

請求項７に記載の情報処理システムであって、
前記制御部は、１つの前記テーブルについて複数のユーザ端末から前記喫食情報を受信した場合、前記注文頻度の最も高いユーザの注文頻度が所定値以下の場合に前記第２飲食店を検索して前記飲食店情報を送信する
情報処理システム。

【請求項9】

請求項１乃至８のいずれかに記載の情報処理システムであって、
前記制御部は、１つの前記テーブルについて複数のユーザ端末から前記注文情報を受信した場合、複数の注文情報を合わせたテーブル注文情報を基に検索条件を決定する
情報処理システム。

【請求項10】

請求項１乃至９のいずれかに記載の情報処理システムであって、
前記制御部は、前記テーブルの利用人数が不明な場合、前記テーブルについて前記喫食情報の受信元のユーザ端末の数に所定の数を乗じた数を利用人数情報として前記第２飲食店を検索して前記飲食店情報を送信する
情報処理システム。

【請求項11】

ユーザが利用している第１飲食店のテーブルの利用人数情報と、ジャンル情報及びエリア情報を含む店舗識別情報と、当該第１飲食店の当該利用中のテーブルにおけるメニューの注文情報とを含む喫食情報を前記ユーザのユーザ端末から受信し、
前記受信された喫食情報を基に、前記ユーザが前記第１飲食店の利用直後に利用可能な第２飲食店を検索し、
前記検索した第２飲食店に関する飲食店情報を前記ユーザ端末へ送信する、
情報処理方法であって、
前記ユーザからメニューが新たに注文されるたびに前記ユーザ端末から前記注文情報を受信して蓄積し、前記検索時点までに蓄積されている注文情報を基に前記第２飲食店を検索する
情報処理方法。

【請求項12】

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

【発明の詳細な説明】

【技術分野】

【0001】

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

【背景技術】

【0002】

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

【0003】

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

【先行技術文献】

【特許文献】

【0004】

【特許文献1】特開２０２０－５７３１０号公報

【発明の概要】

【発明が解決しようとする課題】

【0005】

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

【0006】

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

【課題を解決するための手段】

【0007】

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

【0008】

この構成により、情報処理システムは、ユーザによる飲食店の利用中に注文があるたびにユーザ端末から喫食情報を受信しそれを基に飲食店を検索して検索結果をユーザ端末へ送信することで、ユーザによる飲食店の利用中に、その飲食店の利用直後に利用可能でユーザに適した他の飲食店をユーザに提案することができる。当該情報処理システムは、１または複数の情報処理装置で構成される。

【0009】

上記制御部は、上記ユーザ端末に対するユーザの操作に基づく検索要求を上記ユーザ端末から受信した場合に上記第２飲食店を検索して上記飲食店情報を送信してもよい。

【0010】

これにより情報処理システムは、ユーザが他の飲食店に行くことを所望したタイミングで適切な他の飲食店の候補をユーザに提示することができる。

【0011】

上記制御部は、上記注文情報が更新されるたびに、上記第２飲食店を検索して上記飲食店情報を送信してもよい。

【0012】

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

【0013】

上記制御部は、上記注文情報が所定数蓄積された場合に上記第２飲食店を検索して上記飲食店情報を送信してもよい。

【0014】

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

【0015】

上記制御部は、上記注文情報が所定種類蓄積された場合に上記第２飲食店を検索して上記飲食店情報を送信してもよい。

【0016】

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

【0017】

上記制御部は、上記ユーザ端末から上記メニューの注文の開始時刻を示す情報を受信し、当該開始時刻から所定時間後の時刻を利用時刻に関する検索条件として上記第２飲食店を検索してもよい。

【0018】

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

【0019】

上記制御部は、上記メニューの注文頻度が所定値以下の場合、または、所定時間以上注文が無い場合に上記第２飲食店を検索して上記飲食店情報を送信してもよい。

【0020】

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

【0021】

上記制御部は、１つの上記テーブルについて複数のユーザ端末から上記喫食情報を受信した場合、上記注文頻度の最も高いユーザの注文頻度が所定値以下の場合に上記第２飲食店を検索して上記飲食店情報を送信してもよい。

【0022】

これにより情報処理システムは、１つのテーブルで複数のユーザがそれらのユーザ端末から別個に注文している場合でも、テーブル全体としての利用終了に近いタイミングで他の飲食店を提案することができる。

【0023】

上記制御部は、１つの上記テーブルについて複数のユーザ端末から上記注文情報を受信した場合、複数の注文情報を合わせたテーブル注文情報を基に検索条件を決定してもよい。

【0024】

これにより情報処理システムは、１つのテーブルで複数のユーザがそれらのユーザ端末から別個に注文している場合でも、それらユーザに平均的に適した他の飲食店を提案することができる。

【0025】

上記制御部は、上記テーブルの利用人数が不明な場合、上記テーブルについて上記喫食情報の受信元のユーザ端末の数に所定の数を乗じた数を利用人数情報として上記第２飲食店を検索して上記飲食店情報を送信してもよい。

【0026】

これにより情報処理システムは、１つのテーブルを利用している人数が不明な場合でも、一般的に複数人で１つのテーブルで飲食する場合に注文を行うユーザは限られていることに鑑みて、注文元のユーザ端末の数に所定数を乗じた値をそのテーブルの利用人数とみなすことで、当該人数で利用可能な他の飲食店を提案することができる。所定の数とは例えば２～４等であるが、これに限られない。

【0027】

本発明の他の形態に係る情報処理方法は、
ユーザが利用している第１飲食店のテーブルの利用人数情報と、ジャンル情報及びエリア情報を含む店舗識別情報と、当該第１飲食店の当該利用中のテーブルにおけるメニューの注文情報とを含む喫食情報を上記ユーザのユーザ端末から受信し、
上記受信された喫食情報を基に、上記ユーザが上記第１飲食店の利用直後に利用可能な第２飲食店を検索し、
上記検索した第２飲食店に関する飲食店情報を上記ユーザ端末へ送信する、
情報処理方法であって、
上記ユーザからメニューが新たに注文されるたびに上記ユーザ端末から上記注文情報を受信して蓄積し、上記検索時点までに蓄積されている注文情報を基に上記第２飲食店を検索する。

【0028】

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

【発明の効果】

【0029】

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

【図面の簡単な説明】

【0030】

【図1】本発明の一実施形態に係る飲食店提案システムの構成を示した図である。

【図2】本発明の一実施形態に係る飲食店情報提供サーバのハードウェア構成を示した図である。

【図3】本発明の一実施形態に係る飲食店情報提供サーバが有するデータベースの構成を示した図である。

【図4】本発明の一実施形態に係る飲食店情報提供サーバによるモバイルオーダー受付処理の流れを示したフローチャートである。

【図5】本発明の一実施形態に係る飲食店情報提供サーバによる飲食店検索・予約処理の流れを示したフローチャートである。

【図6】本発明の一実施形態に係る飲食店情報提供サーバが生成してユーザ端末に表示される飲食店検索結果表示画面の例を示した図である。

【発明を実施するための形態】

【0031】

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

【0032】

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

【0033】

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

【0034】

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

【0035】

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

【0036】

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

【0037】

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

【0038】

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

【0039】

一方で飲食店情報提供サーバ１００は、飲食店の各テーブルＴを利用するユーザからユーザ端末２００を介して各飲食店の各テーブルにおける飲食物の注文を受け付け可能である。飲食店情報提供サーバ１００は、例えば飲食店の各テーブルにカード、プレート、スタンド等として置かれた２次元バーコードＣをユーザ端末２００が読み取り、読み取った情報（ＵＲＬ）を基に飲食店情報提供サーバ１００にアクセスした場合に、ユーザ端末２００の表示部上に飲食店のメニューの注文画面を表示する。

【0040】

そして飲食店情報提供サーバ１００は、当該注文画面を介してユーザの注文の入力を受け付けると、受け付けた注文情報を飲食店の飲食店端末３００へ送信する。当該注文情報は飲食店端末３００から厨房の端末（図示せず）へ転送される。また飲食店情報提供サーバ１００は、受け付けた注文情報を蓄積し、ユーザから会計処理の要求を受け付けると、飲食店端末３００を介して当該飲食店のＰＯＳ端末（図示せず）と連携して会計処理を実行する。

【0041】

この場合ユーザ端末２００は、飲食店の各テーブルＴを利用するユーザから注文を受け付け、注文情報を飲食店情報提供サーバ１００へ送信するためのモバイルオーダー端末としても機能する。ユーザ端末２００には、飲食店情報提供サーバ１００と連携してモバイルオーダーに関する処理を実行可能なアプリケーション（以下、ＭＯアプリともいう）がインストールされていてもよい。

【0042】

飲食店端末３００は、各飲食店に設置されている端末であり、タブレットＰＣ、ノートブックＰＣ、デスクトップＰＣ等である。飲食店端末３００は、管理者の操作に基づいて、上記飲食店情報の編集・更新等、自身の飲食店情報に関する処理を飲食店情報提供サーバ１００との通信により実行することが可能である。また飲食店端末３００は、上記モバイルオーダー処理において飲食店提供サーバ１００と厨房端末やＰＯＳ端末との間の通信を仲介する。もちろん、飲食店端末３００が上記厨房端末やＰＯＳ端末を兼ねており飲食店情報提供サーバ１００と直接通信してもよい。

【0043】

また本実施形態では、飲食店情報提供サーバ１００は、ユーザによるテーブルＴの利用中に、当該ユーザの利用人数情報、当該テーブル端末２００が設置された飲食店のジャンル情報及びエリア情報を含む店舗識別情報、及び当該テーブルＴにおけるメニューの注文情報を含む喫食情報をユーザ端末２００から受信して、当該喫食情報を基に、当該ユーザが現在利用中の飲食店の利用直後に（例えば２次会の店として）利用可能な（空席を有する）他の飲食店を検索し、当該検索した飲食店に関する情報をユーザ端末２００へ送信する。この飲食店検索処理の詳細については後述する。

【0044】

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

【0045】

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

【0046】

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

【0047】

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

【0048】

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

【0049】

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

【0050】

特に本実施形態では、記憶部１８は、飲食店情報提供サーバ１００が後述するモバイルオーダー処理や飲食店情報検索処理を実行するためのアプリケーションその他のプログラムを記憶している。後述するが、記憶部１８は、そのようなデータを含むデータベースとして、飲食店情報データベース、ユーザ情報データベース、及び喫食情報データベースを有している。

【0051】

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

【0052】

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

【0053】

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

【0054】

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

【0055】

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

【0056】

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

【0057】

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

【0058】

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

【0059】

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

【0060】

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

【0061】

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

【0062】

まず、飲食店情報提供サーバ１００によるモバイルオーダー受付処理について説明する。図４は、当該モバイルオーダー受付処理の流れを示したフローチャートである。

【0063】

飲食店情報提供サーバ１００のＣＰＵ１１はまず、ユーザ端末２００からテーブルＴの利用開始要求（モバイルオーダー開始要求）を受信したか否かを判断する（ステップ４１）。

【0064】

テーブルＴの利用開始要求には、当該テーブルＴを利用するユーザの利用人数に関する情報が含まれる。ＣＰＵ１１は、上記利用開始要求を受け付けたと判断した場合（ステップ４１のＹｅｓ）、利用人数情報を記憶部１８の喫食情報データベース３３に記憶するとともに、ユーザ端末２００へ、モバイルオーダー用の注文画面を送信する（ステップ４２）。

【0065】

続いてＣＰＵ１１は、ユーザ端末２００からメニューの注文を受け付けたか否かを判断する（ステップ４３）。

【0066】

注文を受け付けたと判断した場合（ステップ４３のＹｅｓ）、ＣＰＵ１１は、注文対象のメニューを識別するメニューＩＤ、注文数量、及び当該メニューのカテゴリを示すカテゴリＩＤ等を含む注文情報を飲食店端末３００を介して（または介さずに）厨房端末へ送信するとともに、当該注文情報を記憶部１８の喫食情報データベース３３に記憶する（ステップ４４）。注文を受け付けていないと判断した場合（ステップ４３のＮｏ）、ＣＰＵ１１は、そのまま注文を待機する。

【0067】

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

【0068】

利用終了を受け付けたと判断した場合（ステップ４５のＹｅｓ）、ＣＰＵ１１は、飲食店端末３００を介して（または介さずに）上記ＰＯＳ端末と連携して会計処理を実行する（ステップ４６）。

【0069】

利用終了が受け付けられない限りは（ステップ４５のＮｏ）、ＣＰＵ１１は、上記ステップ４３に戻りそれ以降の処理を繰り返す。

【0070】

次に、飲食店情報提供サーバ１００による、上記モバイルオーダーの処理中における飲食店情報検索・予約処理について説明する。図５は、当該飲食店検索・予約処理の流れを示したフローチャートである。

【0071】

同図に示すように、まずＣＰＵ１１は、ユーザ端末２００から、現在利用中の飲食店（第１飲食店）の利用直後に利用可能な飲食店（第２飲食店）の検索要求を受け付けたか否かを判断する（ステップ５１）。当該検索要求は、例えば上記注文画面上に「次の店を検索」等の文字と共に次の飲食店の検索用のボタン等が表示され、当該ボタンユーザが操作することで送信される。なお、発明において、ステップ５１は省略可能であり、ステップ５２から処理が開始されてもよい。ここで、利用直後に利用可能な飲食店は、空席が確実にあり、飲食店による空席有無の確認を要さない予約が可能な店舗であることが好ましい。一方、飲食店による空席確認を必要とする店舗であっても本発明は、適応可能である。

【0072】

上記検索要求を受け付けたと判断した場合（ステップ５１のＹｅｓ）、ＣＰＵ１１は、上記喫食情報データベース３３に現時点までに蓄積された、当該テーブルＴにおける利用開始以降の注文数が所定数以上であるか否かを判断する（ステップ５２。）所定数は例えば５個、１０個等であるがこれらに限られない。上記検索要求を受け付けていないと判断した場合（ステップ５１のＮｏ）、ＣＰＵ１１は、当該検索要求を受け付けるまで待機する。

【0073】

注文数が所定数以上であると判断した場合（ステップ５２のＹｅｓ）、ＣＰＵ１１は、上記喫食情報データベース３３に記憶された喫食情報（利用人数情報、当該飲食店の店舗識別情報（店舗のジャンル情報及び所在エリア情報）及び注文情報）を基に飲食店検索条件を設定する（ステップ５３）。

【0074】

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

【0075】

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

【0076】

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

【0077】

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

【0078】

一方、注文数が所定数未満であると判断した場合（ステップ５２のＮｏ）、ＣＰＵ１１は、注文数が所定数に満たないため有効な検索ができない旨のメッセージ等、検索不可をユーザ端末２００へ通知して（ステップ５４）、ステップ５１へ戻る。

【0079】

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

【0080】

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

【0081】

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

【0082】

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

【0083】

続いてＣＰＵ１１は、上記飲食店検索結果情報を基にユーザ端末２００からいずれかの飲食店の予約要求を受信したか否かを判断する（ステップ６０）。

【0084】

飲食店予約要求を受信したと判断した場合（ステップ６０のＹｅｓ）、ＣＰＵ１１は、当該予約要求対象の飲食店（第２飲食店）の飲食店端末３００へ、予約要求を送信する（ステップ６１）。飲食店予約要求を受信していないと判断した場合（ステップ６０のＮｏ）、ＣＰＵ１１は当該予約要求を受信するまで待機する。

【0085】

なお、本発明は、飲食店検索結果情報をユーザ端末２００へ送信する（ステップ５８）処理までで完結してもよい。その場合、所定時間ユーザによりユーザ端末２００への操作が確認できない場合に、処理がステップ５１またはステップ５２に戻る。

【0086】

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

【0087】

各ユーザ端末２００にインストールされたＭＯアプリは、上記モバイルオーダーを処理するのとは別に、同図に示すように、飲食店情報提供サーバ１００から受信した飲食店検索結果情報を基に、現在空席のある飲食店の位置情報を、ユーザ端末２００の現在位置を中心とした地図画面上で表示可能である。

【0088】

すなわち当該ＭＯアプリは、ＧＰＳ（Global Positioning System）等から取得される現在位置を示すアイコン７１と、上記検索条件に合致する飲食店の所在位置を示すアイコン７２を重畳した地図データを表示可能である。また例えば画面下部にはアイコン７２に対応する飲食店に関する情報（店名やジャンル等のテキストや画像）も表示される。

【0089】

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

【0090】

［まとめ］
以上説明したように、本実施形態によれば、飲食店情報提供サーバ１００は、ユーザによる飲食店の利用中に注文があるたびにユーザ端末２００から喫食情報を受信しそれを基に飲食店を検索して検索結果をユーザ端末２００へ送信することで、ユーザによる飲食店の利用中に、その飲食店の利用直後に利用可能でユーザに適した他の飲食店をユーザに提案することができる。

【0091】

また飲食店情報提供サーバ１００は、注文情報が所定数蓄積されて初めて飲食店検索を実行することで、ユーザに適した他の飲食店を検索するための検索条件としての情報量を確保し、ユーザに適しない他の飲食店が提案されるのを防ぐことができる。

【0092】

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

【0093】

上述の実施形態において、飲食店情報提供サーバ１００は、注文情報が所定数蓄積された場合に飲食店検索を実行していたが、これに代えて、またはこれに加えて注文情報が所定種類（カテゴリ）数分蓄積された場合に飲食店検索を実行してもよい。これによっても、ユーザに適した他の飲食店を検索するための検索条件としての情報量を確保し、ユーザに適しない他の飲食店が提案されるのを防ぐことができる。

【0094】

また飲食店情報提供サーバ１００は、ユーザ端末２００からメニューの注文の開始時刻（テーブルＴの利用開始時刻）を示す情報を受信し、当該開始時刻から所定時間後の時刻を利用時刻に関する検索条件として他の飲食店を検索してもよい。これにより飲食店情報提供サーバ１００は、ユーザが利用中の飲食店の利用終了時刻から間を置かずに利用可能な他の飲食店を検索してユーザに提案することができる。

【0095】

上述の実施形態において、飲食店情報提供サーバ１００は、ユーザ端末２００からの明示的な検索要求があった場合に飲食店検索処理を実行した。これに代えて飲食店情報提供サーバ１００は、ユーザ端末２００からの注文情報が更新されるたびにその時点までの注文情報等を基に他の飲食店を検索して検索結果情報をユーザ端末２００へ送信してもよい。これにより飲食店情報提供サーバ１００は、ユーザからの検索要求を待つことなく、注文情報が更新されるたびに累積的に検索精度を向上させ、よりユーザに適した他の飲食店を提案することが可能となる。

【0096】

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

【0097】

また上述の実施形態においては、１つのテーブルＴについて注文情報を送信するユーザ端末２００は１つであることを前提に説明がなされた。しかし、１つのテーブルＴにおいて複数のユーザ端末２００から注文情報が送信される場合もあり得る。そこで飲食店情報提供サーバ１００は、１つのテーブルＴについて複数のユーザ端末２００から上記喫食情報を受信した場合、そのうち注文頻度の最も高いユーザの注文頻度が所定値以下の場合に他の飲食店を検索して検索結果情報を当該テーブルＴの各ユーザ端末２００へ送信してもよい。これにより飲食店情報提供サーバ１００は、１つのテーブルＴで複数のユーザがそれらのユーザ端末２００から別個に注文している場合でも、テーブルＴ全体としての利用終了に近いタイミングで他の飲食店を提案することができる。この場合、複数のユーザ端末２００は、上記喫食情報データベース３３において、それらの各ユーザＩＤが、共通するテーブルＩＤにより関連付けられることで同じグループとして認識されることになる。

【0098】

また上述の実施形態において、飲食店情報提供サーバ１００は、１つの上記テーブルＴについて複数のユーザ端末２００から上記注文情報をそれぞれ受信した場合、当該複数の注文情報を合わせたテーブル注文情報を基に検索条件を決定してもよい。すなわち飲食店情報提供サーバ１００は、複数の注文情報を合わせた注文情報を当該テーブルＴの注文情報とみなして上述の実施形態における検索条件を設定する。これにより飲食店情報提供サーバ１００は、１つのテーブルＴで複数のユーザがそれらのユーザ端末２００から別個に注文している場合でも、それらユーザに平均的に適した他の飲食店を提案することができる。

【0099】

上述の実施形態において、飲食店情報提供サーバ１００は、ユーザによるテーブルＴの利用開始時に当該テーブルＴの利用人数情報をユーザ端末２００から受信して把握していた。しかし、当該利用開始時に利用人数情報が得られず、利用人数が不明な場合、飲食店情報提供サーバ１００は、テーブルＴについて喫食情報の受信元のユーザ端末２００の数に、所定の数を乗じた数を利用人数情報として他の飲食店を検索して検索結果情報を送信してもよい。これにより飲食店情報提供サーバ１００は、１つのテーブルＴを利用している人数が不明な場合でも、一般的に複数人で１つのテーブルで飲食する場合に上記ＭＯアプリで注文を行うユーザは限られていることに鑑みて、１つのテーブルＴ（テーブルＩＤ）について注文元のユーザ端末２００の数に所定数を乗じた値をそのテーブルＴの利用人数とみなすことで、当該人数で利用可能な他の飲食店を提案することができる。所定の数とは例えば２～４等であるが、これに限られない。例えば、前述の通り、１つのテーブルＴで複数のユーザがそれらのユーザ端末２００から別個に注文している場合には、注文しているユーザ端末２００の数を利用人数と仮定してもよい。

【0100】

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

【0101】

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

【0102】

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

【0103】

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

【0104】

上述の実施形態において、ユーザ端末２００を介したモバイルオーダー処理は、テーブルＴに設置された２次元バーコードＣをユーザ端末２００が読み取ることで開始されたが、当該モバイルオーダーの開始のトリガはこれに限られず、例えばＭＯアプリがテーブルＴに設置されたＩＣタグ等の通信機と所定の通信に成功したことが開始のトリガとなってもよい。

【0105】

上述の実施形態における飲食店情報提供サーバ１００の処理は、複数のサーバによって分散されて実行されてもよい。例えば、モバイルオーダーに関する処理と、飲食店情報の検索・予約処理とは別個のサーバで実行されてもよい。その際、モバイルオーダーに関する処理を実行するアプリケーション（上記ＭＯアプリ）と飲食店情報の検索・予約処理を実行するアプリケーションとが別個にユーザ端末２００にインストールされており、両アプリケーションが連携することでモバイルオーダー処理の実行中の飲食店情報検索処理が実現されてもよい。

【0106】

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

【0107】

上述の通り、ステップ５１およびステップ５９以降は、省略することが可能である。その場合は、注文数が所定数以上であると判断した場合（ステップ５２のＹｅｓ）に、現在利用中の飲食店の利用直後に利用可能な飲食店の検索結果情報（ステップ５３～ステップ５７によって得られる）をユーザ端末２００へ送信する（ステップ５８）処理となる。具体的には、ユーザ端末２００にプッシュ通知等の形態で飲食店検索結果情報を送信することが考えられる。

【0108】

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

【符号の説明】

【0109】

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

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】