特許 6855812 情報処理装置、情報処理方法及びプログラム

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

(12)【公報種別】特許公報(B2)

(11)【特許番号】6855812

(24)【登録日】2021年3月22日

(45)【発行日】2021年4月7日

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

(51)【国際特許分類】

   G06Q 10/02 20120101AFI20210329BHJP

   G06Q 50/12 20120101ALI20210329BHJP

   G06F 13/00 20060101ALI20210329BHJP

【ＦＩ】

   G06Q10/02

   G06Q50/12

   G06F13/00 560C

   G06F13/00 510G

【請求項の数】9

【全頁数】14

(21)【出願番号】特願2017-12667(P2017-12667)

(22)【出願日】2017年1月27日

(65)【公開番号】特開2018-120493(P2018-120493A)

(43)【公開日】2018年8月2日

【審査請求日】2019年10月23日

(73)【特許権者】

【識別番号】500175565

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

(74)【代理人】

【識別番号】100104215

【弁理士】

【氏名又は名称】大森 純一

(74)【代理人】

【識別番号】100196575

【弁理士】

【氏名又は名称】高橋 満

(74)【代理人】

【識別番号】100168181

【弁理士】

【氏名又は名称】中村 哲平

(74)【代理人】

【識別番号】100117330

【弁理士】

【氏名又は名称】折居 章

(74)【代理人】

【識別番号】100160989

【弁理士】

【氏名又は名称】関根 正好

(74)【代理人】

【識別番号】100168745

【弁理士】

【氏名又は名称】金子 彩子

(74)【代理人】

【識別番号】100176131

【弁理士】

【氏名又は名称】金山 慎太郎

(74)【代理人】

【識別番号】100197398

【弁理士】

【氏名又は名称】千葉 絢子

(74)【代理人】

【識別番号】100197619

【弁理士】

【氏名又は名称】白鹿 智久

(72)【発明者】

【氏名】山田 篤史

【審査官】 久慈 渉

(56)【参考文献】

【文献】 特開２０１４−２１５７８３（ＪＰ，Ａ）

【文献】 特開２０１２−０９０３３９（ＪＰ，Ａ）

【文献】 特開２００６−２６８７２０（ＪＰ，Ａ）

【文献】 米国特許出願公開第２０１５／０１７８７８２（ＵＳ，Ａ１）

【文献】 特開２００８−０７７２５１（ＪＰ，Ａ）

【文献】 特開２０１０−１７６６３７（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｑ １０／００ − ９９／００

Ｇ０６Ｆ １３／００

(57)【特許請求の範囲】

【請求項1】

複数のユーザ端末と通信可能な通信手段と、
前記ユーザ端末のうちいずれかのユーザ端末から、当該ユーザ端末のユーザを含むグループによる会合への参加者を募集するための募集開始操作が入力されたことを示す募集開始通知を、当該ユーザ端末の位置情報と共に受信し、
前記募集開始通知の受信から所定時間内に、複数の前記ユーザ端末から、前記募集開始通知の送信元のユーザ端末と共通の位置情報を受信した場合に、当該位置情報の送信元のユーザ端末の数を前記会合の参加者の人数としてカウントし、
前記募集開始通知の受信から前記所定時間内に、いずれかのユーザ端末から、当該ユーザ端末の位置情報と共に他の募集開始通知を受信し、当該位置情報が前記募集開始通知と共に送信された位置情報と共通する場合、当該他の募集開始通知の送信元のユーザ端末へ、前記参加者の募集処理を留保するよう要求する留保要求を送信する
ことが可能な制御手段と
を具備する情報処理装置。

【請求項2】

請求項１に記載の情報処理装置であって、
前記制御手段は、前記所定時間経過後に、前記他の募集開始通知の送信元のユーザ端末へ、前記募集処理を許可する許可通知を送信し、前記カウントを開始する
情報処理装置。

【請求項3】

請求項１または２に記載の情報処理装置であって、
前記制御手段は、前記所定時間経過時点までにカウントされた数を、前記会合の参加者の人数として、前記位置情報の送信元のユーザ端末へ送信する
情報処理装置。

【請求項4】

請求項１乃至３のいずれかに記載の情報処理装置であって、
前記制御手段は、前記カウントした数で予約可能なサービス施設に関する情報を、前記位置情報を基に検索し、検索結果を前記参加者の端末へ送信する
情報処理装置。

【請求項5】

請求項４に記載の情報処理装置であって、
前記制御手段は、前記検索結果の送信後に、いずれかのサービス施設の予約要求を受信した場合、当該サービス施設を、前記カウントした数を予約人数とし、前記位置情報と前記サービス施設の位置情報から算出される時間の経過後の時刻を予約時刻として予約処理する
情報処理装置。

【請求項6】

請求項１乃至５のいずれかに記載の情報処理装置であって、
前記受信された募集開始通知に含まれる、当該募集開始通知の送信元のユーザ端末を識別する第１ユーザ識別情報を記憶するとともに、前記受信された位置情報に含まれる、当該位置情報の送信元のユーザ端末を識別する第２ユーザ識別情報を、前記第１ユーザ識別情報と対応付けて記憶する記憶手段をさらに具備し、
前記制御手段は、前記第１ユーザ識別情報を含む前記募集開始通知を再度受信し、当該募集開始通知の受信から前記所定時間内にユーザ端末から位置情報を受信した場合に、当該位置情報に含まれる第２ユーザ識別情報のうち、前記第１ユーザ識別情報に対応付けられていない第２ユーザ識別情報を有するユーザ端末の数と、前記第１ユーザ識別情報と対応付けられた数との合計数を、前記参加者の人数としてカウントする
情報処理装置。

【請求項7】

請求項６に記載の情報処理装置であって、
前記制御手段は、前記合計数で予約可能なサービス施設に関する情報を、前記位置情報を基に検索し、検索結果を前記参加者の端末へ送信する
情報処理装置。

【請求項8】

複数のユーザ端末のうちいずれかのユーザ端末から、当該ユーザ端末のユーザを含むグループによる会合への参加者を募集するための募集開始操作が入力されたことを示す募集開始通知を、当該ユーザ端末の位置情報と共に受信し、
前記募集開始通知の受信から所定時間内に、複数の前記ユーザ端末から、前記募集開始通知の送信元のユーザ端末と共通の位置情報を受信した場合に、当該位置情報の送信元のユーザ端末の数を前記会合の参加者の数としてカウントし、
前記募集開始通知の受信から前記所定時間内に、いずれかのユーザ端末から、当該ユーザ端末の位置情報と共に他の募集開始通知を受信し、当該位置情報が前記募集開始通知と共に送信された位置情報と共通する場合、当該他の募集開始通知の送信元のユーザ端末へ、前記参加者の募集処理を留保するよう要求する留保要求を送信する
コンピュータが実行する情報処理方法。

【請求項9】

情報処理装置に、
複数のユーザ端末のうちいずれかのユーザ端末から、当該ユーザ端末のユーザを含むグループによる会合への参加者を募集するための募集開始操作が入力されたことを示す募集開始通知を、当該ユーザ端末の位置情報と共に受信するステップと、
前記募集開始通知の受信から所定時間内に、複数の前記ユーザ端末から、前記募集開始通知の送信元のユーザ端末と共通の位置情報を受信した場合に、当該位置情報の送信元のユーザ端末の数を前記会合の参加者の数としてカウントするステップと、
前記募集開始通知の受信から前記所定時間内に、いずれかのユーザ端末から、当該ユーザ端末の位置情報と共に他の募集開始通知を受信し、当該位置情報が前記募集開始通知と共に送信された位置情報と共通する場合、当該他の募集開始通知の送信元のユーザ端末へ、前記参加者の募集処理を留保するよう要求する留保要求を送信するステップと
を実行させるプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、飲食店等のサービス施設において開かれる会合の参加者に関する情報を処理することが可能な情報処理装置、情報処理方法及びプログラムに関する。

【背景技術】

【0002】

従来から、インスタントメッセージングアプリケーションにおいて、サーバによる位置情報の認識に基づいて、隣接する端末が（端末を振ることで）互いを友だちに追加する機能が知られている。

【先行技術文献】

【特許文献】

【0003】

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

【発明の概要】

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

【0004】

しかしながら、上記特許文献１の技術を応用して、ユーザが端末を振る動作に基づいて、ある場所に集合しているユーザグループの中から、端末を振っているユーザの数を、開催予定の会合へ参加するユーザの人数として認識しようとする場合、上記位置情報の精度が低く、かつ、上記ユーザグループ以外のユーザがたまたま同時に端末を振った場合には、上記人数をご認識してしまうおそれがある。

【0005】

以上のような事情に鑑み、本発明の目的は、飲食店等のサービス施設における会合への参加者を容易かつ高精度に認識することが可能な情報処理装置、情報処理方法及びプログラムを提供することにある。

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

【0006】

上記目的を達成するため、本発明の一形態に係る情報処理装置は、通信手段と制御手段とを有する。上記通信手段は、複数のユーザ端末と通信可能である。上記制御手段は、上記ユーザ端末のうちいずれかのユーザ端末から、当該ユーザ端末のユーザを含むグループによる会合への参加者を募集するための募集開始操作が入力されたことを示す募集開始通知を受信する。また制御手段は、上記募集開始通知の受信から所定時間内に、複数の上記ユーザ端末から、共通の位置情報を受信した場合に、当該位置情報の受信元のユーザ端末の数を上記会合の参加者の数としてカウントする。さらに制御手段は、上記募集開始通知の受信から上記所定時間内に、いずれかのユーザ端末から他の募集開始通知を受信した場合、当該他の募集開始通知の受信元のユーザ端末へ、上記参加者の募集処理を留保するよう要求する留保要求を送信する。

【0007】

これにより情報処理装置は、端末からの位置情報の受信を参加者のカウントの条件とすることで、参加者を容易に認識できるとともに、あるグループの端末から募集開始通知を受信してから所定時間内に他のグループの端末から募集開始通知を受信した場合には、当該他のグループの募集処理を留保させることで、ほぼ同じ位置に存在する異なるグループの端末から同時期に変位情報及び位置情報を受信して参加者の人数を誤認してしまうのを防ぎ、当該参加者を高精度に認識することができる。ここで、上記位置情報は、上記所定時間内においてユーザ端末の変位（例えばユーザが端末を振る動作による変位）が検出されることで送信されてもよい。

【0008】

上記制御手段は、上記所定時間経過後に、上記他の募集開始通知の受信元のユーザ端末へ、上記募集処理を許可する許可通知を送信し、上記カウントを開始してもよい。

【0009】

これにより情報処理装置は、他のグループの端末からの募集開始通知については、所定時間経過後に募集処理を許可することで、上記募集処理の留保時間を最低限に留めることができる。

【0010】

上記制御手段は、上記所定時間経過時点までにカウントされた数を、上記会合の参加者の人数として、上記位置情報の受信元のユーザ端末へ送信してもよい。

【0011】

これにより情報処理装置は、上記会合の参加の意思表示（例えば、上記位置情報送信のための、ユーザ端末を変位させる動作）をしたユーザに、会合の参加者の人数を把握させることができる。

【0012】

上記制御手段は、上記カウントした数で予約可能なサービス施設に関する情報を、上記位置情報を基に検索し、検索結果を参加者の端末へ送信してもよい。

【0013】

これにより情報処理装置は、上記会合の人数を決定するだけでなく、その人数で会合場所として利用可能なサービス施設に関する情報を提供することができる。

【0014】

上記制御手段は、上記検索結果の送信後に、いずれかのサービス施設の予約要求を受信した場合、当該サービス施設を、上記カウントした数を予約人数とし、上記位置情報と上記サービス施設の位置情報から算出される時間の経過後の時刻を予約時刻として予約処理してもよい。

【0015】

これにより情報処理装置は、例えば、あるサービス施設（例えば飲食店）で開かれた会合の終了直後に２次会が開かれる場合に、当該２次会の人数確定から予約処理までの一連の処理を自動化することができる。

【0016】

上記受信された募集開始通知に含まれる、当該募集開始通知の受信元のユーザ端末を識別する第１ユーザ識別情報を記憶するとともに、上記受信された位置情報に含まれる、当該位置情報の受信元のユーザ端末を識別する第２ユーザ識別情報を、上記第１ユーザ識別情報と対応付けて記憶する記憶手段をさらに有してもよい。この場合上記制御手段は、上記第１ユーザ識別情報を含む上記募集開始通知を再度受信し、当該募集開始通知の受信から上記所定時間内にユーザ端末から位置情報を受信した場合に、当該位置情報に含まれる第２ユーザ識別情報のうち、上記第１ユーザ識別情報に対応付けられていない第２ユーザ識別情報を有するユーザ端末の数と、上記第１ユーザ識別情報と対応付けられた数との合計数を、上記参加者の人数としてカウントしてもよい。

【0017】

これにより情報処理装置は、例えば会合への参加意思を有しながら、募集開始通知の時点でたまたまその場にいなかったユーザや、何らかの不具合等により位置情報が送信できなかったユーザを、参加者として容易に追加することができる。

【0018】

またこの場合、上記制御手段は、上記合計数で予約可能なサービス施設に関する情報を、上記位置情報を基に検索し、検索結果を上記参加者の端末へ送信してもよい。

【0019】

これにより、参加者が追加された場合には、追加後の人数で予約可能なサービス施設を検索することで、追加された参加者が利用できないサービス施設が検索結果としてユーザに把握されてしまうのを防ぐことができる。

【0020】

本発明の他の形態に係る情報処理方法は、
複数のユーザ端末のうちいずれかのユーザ端末から、当該ユーザ端末のユーザを含むグループによる会合への参加者を募集するための募集開始操作が入力されたことを示す募集開始通知を受信し、
上記募集開始通知の受信から所定時間内に、複数の上記ユーザ端末から、共通の位置情報を受信した場合に、当該位置情報の受信元のユーザ端末の数を上記会合の参加者の数としてカウントし、
上記募集開始通知の受信から上記所定時間内に、いずれかのユーザ端末から他の募集開始通知を受信した場合、当該他の募集開始通知の受信元のユーザ端末へ、上記参加者の募集処理を留保するよう要求する留保要求を送信することを含む。

【0021】

本発明の他の形態に係るプログラムは、情報処理装置に、
複数のユーザ端末のうちいずれかのユーザ端末から、当該ユーザ端末のユーザを含むグループによる会合への参加者を募集するための募集開始操作が入力されたことを示す募集開始通知を受信するステップと、
上記募集開始通知の受信から所定時間内に、複数の上記ユーザ端末から、共通の位置情報を受信した場合に、当該位置情報の受信元のユーザ端末の数を上記会合の参加者の数としてカウントするステップと、
上記募集開始通知の受信から上記所定時間内に、いずれかのユーザ端末から他の募集開始通知を受信した場合、当該他の募集開始通知の受信元のユーザ端末へ、上記参加者の募集処理を留保するよう要求する留保要求を送信するステップとを実行させる。

【発明の効果】

【0022】

以上説明したように、本発明によれば、飲食店等のサービス施設における会合への参加者を容易かつ高精度に認識することができる。しかし、当該効果は本発明を限定するものではない。

【図面の簡単な説明】

【0023】

【図1】本発明の一実施形態に係る会合参加者募集システムの構成を示した図である。

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

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

【図4】本発明の一実施形態に係る飲食店情報提供サーバによる、会合参加者募集処理の流れを示したフローチャートである。

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

【0024】

以下、図面を参照しながら、本発明を、飲食店で開催される会合の参加者募集システムに適用した実施形態を説明する。

【0025】

［システムの構成］
図１は、本実施形態に係る会合参加者募集システムの構成を示した図である。

【0026】

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

【0027】

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

【0028】

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

【0029】

飲食店端末３００（３００Ａ，３００Ｂ，...）は、各飲食店の例えば管理者によって使用される端末であり、例えばスマートフォン、携帯電話、タブレットＰＣ（Personal Computer）、ノートブックＰＣ、デスクトップＰＣ等である。飲食店端末３００は、飲食店情報提供サーバ１００との間で、例えば上記ユーザ端末２００のユーザによる飲食店のテーブルまたは席の予約に関する情報をやり取り可能である。

【0030】

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

【0031】

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

【0032】

また本実施形態では、複数のユーザ端末２００のユーザが、ある位置に集まってグループＧを形成する場合もある。同図の例では、飲食店内のある位置（テーブル）に、５機のユーザ端末２００Ａ〜２００Ｅの各ユーザが集まってグループＧ１を形成し会合（飲み会）を開いており、また当該飲食店内の別の位置に５機のユーザ端末２００Ｆ〜２００Ｊが集まってグループＧ２を形成し別の会合を開いている。

【0033】

これらグループの数及びグループに含まれるユーザ（ユーザ端末）の数は一例であり、これらに限られるものではない。

【0034】

上記グループのユーザの少なくとも一部は、上記飲食店における会合が終了した後、そのまま異なる飲食店に移動して会合（二次会等）を開く場合がある。本実施形態では、飲食店情報提供サーバ１００は、上記グループを形成しているユーザのユーザ端末２００から、次の会合（二次会等）への参加者を募集し、参加者を特定する処理、及び、当該参加者によって開催される会合の会場となる飲食店の予約処理を実行することが可能である。

【0035】

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

【0036】

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

【0037】

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

【0038】

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

【0039】

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

【0040】

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

【0041】

特に本実施形態では、記憶部１８は、各飲食店の飲食店情報、各ユーザ端末２００のユーザに関するユーザ情報、当該ユーザ端末２００によって開催される会合に関する情報等を記憶するとともに、これらのデータを用いて飲食店情報提供サーバ１００が会合参加者募集処理を実行するためのアプリケーションその他のプログラムを記憶している。後述するが、記憶部１８は、そのようなデータを含むデータベースとして、飲食店情報データベース、ユーザ情報データベース、予約情報データベース、及び会合情報データベースを有している。

【0042】

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

【0043】

なお、図示しないが、ユーザ端末２００及び飲食店端末３００の基本的なハードウェア構成も上記飲食店情報提供サーバ１００のハードウェア構成と略同様である。なお、ユーザ端末２００には、飲食店情報提供サーバ１００による会合参加者募集処理と協働して動作するアプリケーションがインストールされているものとする。

【0044】

当該アプリケーションは、例えばＧＰＳ（Global Positioning System）やモバイル通信網（３Ｇ，４Ｇ等）の基地局の位置等を利用して各ユーザ端末２００の位置情報を取得し、当該位置情報を飲食店情報提供サーバ１００へ送信することが可能である。また、ユーザ端末２００は、例えば加速度センサやジャイロセンサ等の、ユーザ端末２００の変位を検出するセンサを有し、上記アプリケーションは、それらセンサによって当該ユーザ端末２００の変位が検出されたことをトリガとして、上記位置情報を飲食店情報提供サーバ１００へ送信可能である。

【0045】

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

【0046】

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

【0047】

飲食店情報データベース３１は、飲食店毎に、その飲食店の店名や所在位置情報、その飲食店を識別するＩＤ（店舗ＩＤ）の他、その飲食店の業態・サービスのカテゴリ情報、その飲食店を紹介する内容、すなわち、店舗のＰＲ文等の店舗の特徴を示す情報、飲食店が行うイベント情報、飲食店が立地しているエリア情報、飲食店の住所（位置情報）、電話番号、飲食店に関する（飲食店を紹介する）画像データ、飲食店が提供するメニューに関するメニュー情報、営業時間、ウェブサイトＵＲＬ等の情報を記憶している。

【0048】

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

【0049】

上記エリア情報は、例えば都道府県単位のものであるが、市区町村等のより狭い範囲の単位でも情報が記憶されてもよい。上記カテゴリ情報は、例えば和食、中華、イタリアン、フレンチ、焼肉等のメインカテゴリの他、和食における焼き鳥・天ぷら等、イタリアンにおけるパスタ・ピザ等のより詳細なサブカテゴリを含んでいてもよい。

【0050】

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

【0051】

会合情報データベース３３は、上記ユーザ端末２００から受信した位置情報を、受信日時及びユーザＩＤ等の識別情報と対応付けて記憶することで、共通の（ほぼ同一を含む）位置情報及び受信日時に対応付けられたユーザに関する情報を、各グループによる会合の参加者情報として、グループ毎に記憶する。また、会合情報データベース３３は、当該グループに属するユーザ端末２００の数及び位置情報を基に検索され、ユーザ端末２００からの予約要求に基づいて、上記会合の開催場所として予約処理された飲食店に関する予約情報（飲食店名（店舗ＩＤ）、予約名（ユーザＩＤ）、予約日時、予約人数等）も記憶している。

【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】

１１…ＣＰＵ
１８…記憶部
１９…通信部
３１…飲食店情報データベース
３２…ユーザ情報データベース
３３…会合情報データベース
１００…飲食店情報提供サーバ
２００…ユーザ端末
３００…飲食店端末

【図1】

【図2】

【図3】

【図4】