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

Description

本開示は、情報処理装置、情報処理方法、プログラム及び情報処理システムに関する。

従来、下記の特許文献１には、同じメディア・コンテンツに関心のあるユーザ間で通信媒体を介した共有体験を実現することを想定した技術が記載されている。

特開２００４−６２８１２号公報

しかしながら、同じコンテンツに関心のあるユーザが現実のイベントに参加することを想定した場合、イベント会場からの距離が遠いユーザはイベントに参加できない場合がある。また、ユーザの嗜好は様々であり、あるユーザにとっては有益なイベント情報であっても、他のユーザにとっては有益でない情報もある。上記従来の技術では、ユーザのロケーション、嗜好などの様々な特性に応じて最適な情報を提供することは困難である。

そこで、ユーザの特性に応じてイベントの情報を提供することが求められていた。

本開示によれば、ホストのユーザ端末からイベントの条件情報を受信する受信部と、前記条件情報に基づいて、イベントへ招待可能なユーザを定める招待条件を設定する招待条件設定部と、前記招待条件に基づいて、イベントの情報をユーザの端末へ送信する送信部と、を備える、情報処理装置が提供される。

また、前記招待条件設定部は、ユーザの現在位置とイベントの開催場所及び開催時刻とに基づいて、ユーザのスコアを算出し、前記スコアに基づいて前記ユーザの招待条件を設定するものであっても良い。

また、前記招待条件設定部は、ユーザの嗜好情報とイベントの種類とに基づいて、ユーザのスコアを算出し、前記スコアに基づいて前記ユーザの招待条件を設定するものであっても良い。

また、前記招待条件設定部は、ユーザのプロファイル情報に基づいてユーザのスコアを算出し、前記スコアに基づいて前記ユーザの招待条件を設定するものであっても良い。

また、前記招待条件設定部は、ユーザの過去のイベントの参加履歴に基づいて、ユーザのスコアを算出し、前記スコアに基づいて前記ユーザの招待条件を設定するものであっても良い。

また、前記招待条件設定部は、前記スコアが所定値以上のユーザを参加候補とし、前記送信部は、前記参加候補のユーザに対してイベントの情報を送信するものであっても良い。

また、前記送信部は、ユーザの現在位置とイベントの開催場所及び開催時刻とに基づいて、ユーザが開催時刻に開催場所に到達できないと見込まれる場合は、当該ユーザを参加候補としないものであっても良い。

また、前記イベントの条件情報を前記ユーザ端末上でユーザに入力させるためのメニュー情報を前記ユーザ端末へ送信するメニュー情報送信部を更に備えるものであっても良い。

また、前記メニュー情報は、イベントの種類、開催場所、開始時刻、終了時刻、参加者年齢、性別、ユーザの現在位置、ユーザの今後のスケジュール、又はユーザの嗜好情報をユーザに入力させるための情報であっても良い。

また、前記送信部がイベントの情報を送信したユーザ端末から応答を受信する受信部と、前記応答に基づいて、当該ユーザがイベントの条件情報に合致するか否かを判定する判定部と、を備えるものであっても良い。

また、本開示によれば、ホストのユーザ端末からイベントの条件情報を受信することと、前記条件情報に基づいて、イベントへ招待可能なユーザを定める招待条件を設定することと、前記招待条件に基づいて、イベントの情報をユーザの端末へ送信することと、
を備える、情報処理方法が提供される。

また、本開示によれば、ホストのユーザ端末からイベントの条件情報を受信する手段、前記条件情報に基づいて、イベントへ招待可能なユーザを定める招待条件を設定する手段、前記招待条件に基づいて、イベントの情報をユーザの端末へ送信する手段、としてコンピュータを機能させるためのプログラムが提供される。

また、本開示によれば、イベントの条件情報を送信するユーザ端末と、ホストのユーザ端末からイベントの前記条件情報を受信する受信部と、前記条件情報に基づいて、イベントへ招待可能なユーザを定める招待条件を設定する招待条件設定部と、前記招待条件に基づいて、イベントの情報をユーザの端末へ送信する送信部と、を有する、情報処理装置と、を備える、情報処理システムが提供される。

本開示によれば、ユーザの特性に応じてイベントの情報を提供することが可能となる。

第１の実施形態の概要を説明するための模式図である。 第１の実施形態のシステムの構成を示す模式図である。 サーバにおける処理の流れを示すフローチャートである。 サーバの構成を示すブロック図である。 ユーザ端末の構成を示す模式図である。 第２の実施形態におけるシステムの概略構成を示す模式図である。 第２の実施形態の処理を示すシーケンス図である。 サーバに提供されるユーザＡの時間位置情報（ログ）例を示す模式図である。 サーバが保持する時間位置情報（ログ）データベース例を示す模式図である。 グルーピング情報生成の処理を示すフローチャートである。 サーバの構成を示すブロック図である。 グルーピング情報の例を示す模式図である。 グルーピング情報に基づいた画面表示例を示す模式図である。 ユーザＡの経路を示す模式図である。 図１４に示す経路の情報から、ユーザＡの詳細な時間情報を一定間隔の地点データに間引いた状態を示す模式図である。 位置を所定の範囲に区分して、時間とユーザがいたエリアのデータを生成した状態を示す模式図である。 ユーザ位置を類型化したデータを示す模式図である。 ユーザＡの経路情報とともに、ユーザＢの経路情報を示す模式図である。 ユーザＢの経路情報を間引いた状態を示す模式図である。 図１６と同様に、ユーザＡ，Ｂの位置を所定の範囲に区分した状態を示す模式図である。 図１７と同様に、ユーザＡ，Ｂの位置を所定の範囲に区分して、時間とユーザＡ，Ｂがいたエリアのデータを生成した状態を示す模式図である。 類似度を計算した例を示す模式図である。 エリアが同一か否かの判定以外に、エリアの近接度合いに応じた時間毎類似度を用いた例を示す模式図である。 エリアが同一か否かの判定以外に、エリアの近接度合いに応じた時間毎類似度を用いた例を示す模式図である。 時間経過に応じた補正係数を乗算した例を示す模式図である。 第３の実施形態の処理を示すフローチャートである。 サーバの構成を示すブロック図である。 ユーザ端末の構成を示す模式図である。

以下に添付図面を参照しながら、本開示の好適な実施の形態について詳細に説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。

なお、説明は以下の順序で行うものとする。
１．各実施形態の概要
２．第１の実施形態
２．１．第１の実施形態の概要
２．２．第１の実施形態のシステム構成
２．３．第１の実施形態の処理フロー
２．４．サーバの構成例
２．５．ユーザ端末の構成例
２−６．既に実施予定のあるイベントに基づくコミュニティ形成
３．第２の実施形態
３．１．第２の実施形態の概要
３．２．第２の実施形態のシステム構成
３．３．第２の実施形態の処理
３．４．グルーピング情報生成の処理
３．５．サーバの構成例
３．６．グルーピング情報の例
３．７．経路情報解析の類型化について
４．第３の実施形態
４．１．第３の実施形態の概要
４．２．第３の実施形態の処理
４．３．サーバの構成例
４．４．ユーザ端末の構成例
４．５．グループ化されたユーザへのメッセージ配信手法
４．６．第３の実施形態の利用例

１．各実施形態の概要
本開示に係る自動形成手法は、ユーザのロケーションと時間の情報に基づいて、テンポラリなコミュニテイを形成する。第１の実施形態では、場所と時間の一時的関係を使ってコミュニティを形成する態様を説明する。第２の実施形態では、場所と時間の連続的なパターンを使ってコミュニティを形成する例について説明する。第３の実施形態では、同様の環境にいるユーザをグループ化する例について説明する。

２．第１の実施形態
［２．１．第１の実施形態の概要］
まず、図１を参照して、本開示の第１の実施形態の概要について説明する。第１の実施形態は、場所と時間の一時的関係を使ってコミュニティを形成するものである。ここでは、イベント参加者集めサービスについて説明する。イベント参加者集めサービスでは、ホストユーザ（イベント発起人）が、指定したイベントの条件に応じて自動的に参加者を集め、イベントのホストゲストへ通知を行うサービスである。換言すれば、このサービスはメンバー集めのエージェントに関する。

図１は、イベント参加者集めサービスの処理を示す模式図である。図１において、ステップＳ１０では、ホストユーザがサーバ１００にイベントを設定する。ここでは、ホストユーザがサーバ１００に対して、参加者を集める対象のイベントの場所、日時等を設定する。イベントとしては、例えば、サッカーの試合、コンサート、パーティ等が挙げられる。ステップＳ１２では、サーバ１００がイベント条件に基づいてゲストとネゴシエーションを行う。ステップＳ１４では、サーバ１００が、イベントに参加可能なゲストへイベントの詳細を通知する。

［２．２．第１の実施形態のシステム構成］
図２は、第１の実施形態のシステムの構成を示す模式図である。図２に示すように、第１の実施形態のシステムは、サーバ１００、アクセスポイント１１０、ユーザ端末１２０（ユーザＡ，Ｂ，Ｃ，Ｄ，・・・に対応）を有して構成されている。ユーザは、無線通信ネットワークを介してアクセスポイント１１０と通信を行うことで、サーバ１００と通信を行うことができる。サーバ１００は、一例としてソーシャルネットネットワークを構成するソーシャルネットワークサーバ（ＳＮＳサーバ）から構成することができる。

［２．３．第１の実施形態の処理フロー］
図３は、サーバ１００における処理の流れを示すフローチャートである。先ず、ステップＳ２０では、サーバ１００が、ユーザＡ（ホストユーザ）のユーザ端末１２０からイベント設定通知を受信する。次のステップＳ２２では、サーバ１００が、ユーザＡのユーザ端末１２０に対してイベント条件を設定するためのメニュー情報を送信する。次のステップＳ２４では、サーバ１００が、メニュー情報に応じてユーザＡのユーザ端末１２０で設定されたイベント条件情報を受信する。

より詳細には、ステップＳ２０〜Ｓ２４では、ホストユーザがイベント設定を入力する。先ず、ホストユーザの端末１１０は、ステップＳ２２でサーバ１００から送信されたイベントメニュー情報を受信する。イベントメニュー情報としては、例えば「スポーツ」「飲み会」「フリーイベント」等を含む情報がサーバ１００からユーザ端末１２０へ送信され、イベントメニュー情報はユーザ端末１２０の表示画面に表示される。ホストユーザがイベントメニュー情報の中から「スポーツ」を選択した場合、更に、イベントメニュー情報の中から「サッカー」「野球」「釣り」などのメニューが表示される。

ユーザが更に「サッカー」を選択した場合、開催場所（範囲）、時間（開始時間、終了時間）、参加人数、参加者年齢、性別、ユーザの現在位置、今後の予定経路、今後のスケジュール、ゲストの嗜好情報（どのようなイベント（コンサート、スポーツ観戦）が好みか）などを設定する画面が表示される。ホストユーザは、更にこれらの情報を選択する。このようにしてユーザに設定された情報を「イベント条件情報」とする。イベント条件情報は、ユーザ端末１２０からサーバ１００へ送信される。

次のステップＳ２６では、サーバ１００が、イベント条件情報に基づき、招待条件を設定する。ここでは、各ゲストの現在位置、ゲストの将来のスケジュール等に基づいて、招待条件が設定される。例えば、あるゲストが帰宅経路上であることが検出され、招待のスケジュールから将来イベント開催地の近辺にいることが検出されると、当該ゲストはイベントに参加可能であることが認識される。そして、ユーザの現在位置、将来位置、ゲスト嗜好情報を重み付けして、各ゲスト毎に以下の式からスコアを算出し、参加オーダーを設定する。ユーザの嗜好情報としては、登録済みプロフィール（好きなことに記載された内容）、過去のイベント参加履歴等に基づく。なお、最低条件に当てはまらないゲストは除外する。例えば、現在位置、将来位置等に基づき、イベント開催に参加不可能と想定される場合などは、そのゲストは除外される。

スコアの算出式は以下の通りである。
スコア＝Ｗ１＊Ｐ１＋Ｗ２＊Ｐ２＋Ｗ３＊Ｐ３
ここで、Ｐ１は、ゲストスケジュール上の位置とイベント開催位置の距離である。また、Ｐ２は、ゲストのイベントに対する嗜好度である。また、Ｐ３は、ホストが設定した招待ゲストのプロファイル情報に対する合致度である。また、Ｗ１，Ｗ２，Ｗ３は、各項のそれぞれに対するウエイト（重み付け係数）である。

次のステップＳ２８では、サーバ１００が、招待条件に合致する登録ユーザ（ゲストユーザ）へイベントの詳細を通知する。ここでは、上述したスコアが所定値以上のユーザを招待条件に合致するユーザとして、イベントの詳細を通知する。次のステップＳ３０では、サーバ１００が、招待通知に対するゲストユーザの応答を受信する。次のステップＳ３２では、応答したユーザがイベント条件を満たすか否かを判定する。次のステップＳ３４では、ステップＳ３２の判定結果に応じたメッセージを各ユーザに送信する。

［２．４．サーバの構成例］
図４は、上述した処理を実現するサーバ１００の構成を示すブロック図である。サーバ１００は、受信部１０２ａ，１０２ｂ，１０２ｃ、送信部１０４ａ，１０４ｂ、招待条件設定部１０６、判定部１０８、を有して構成される。受信部１０２ａは、図３のステップＳ２０において、ユーザ端末１２０からイベント設定通知を受信する処理を行う。また、受信部１０２ｂは、ステップＳ２４のイベント条件情報を受信する処理を行う。また、受信部１０２ｃは、ステップＳ３０において、招待条件に合致するユーザからの応答を受信する処理を行う。送信部１０４ａは、ステップＳ２２において、メニュー情報を送信する。また、送信部１０４ｂは、ステップＳ２８において、招待条件に合致する登録ユーザへイベントの情報を通知する処理を行う。招待条件設定部１０６は、ステップＳ２６の招待条件を設定する処理を行う。より具体的には、招待条件設定部１０６は、ユーザの位置情報、嗜好情報とイベントの情報に基づいてスコアを算出し、このスコアに基づいてイベントの参加候補となるユーザを選定する。判定部１０８は、ステップＳ３２において、招待条件に合致するユーザから受信した応答がイベント条件を満たすか否かの判定を行う。なお、図４に示すサーバー１００の各構成要素は、回路（ハードウェア）、またはＣＰＵ（中央演算処理装置）とこれを機能させるためのプログラム（ソフトウェア）によって構成することができる。この場合に、そのプログラムは、サーバー１００が備える記憶部に格納されることができる。なお、図５、図１１、図２７、図２８に示す構成も同様にして構成することができる。

［２．５．ユーザ端末の構成例］
図５は、ユーザ端末１２０の構成を示す模式図である。図５に示すように、ユーザ端末１２０は、通信部１２２、表示部１２４、制御部１２６、入力部１２８、位置検出部１３０を有して構成されている。通信部１２２は、サーバ１００と無線通信ネットワークを介して通信を行う。表示部１２４は、液晶表示パネル等から構成され、制御部１２６に指示に基づき、その表示画面に各種情報を表示する。制御部１２６は、ユーザ端末１２０の全体の制御を行う。入力部１２８は、ボタン、キーボード、タッチセンサ等から構成され、入力部１２８にはユーザによる操作入力が入力される。位置検出部１３０は、一例としてＧＰＳから構成され、ユーザ端末１２０の位置情報を取得する。

図４及び図５に示すサーバ１００とユーザ端末１２０の各構成要素は、ハードウェア（回路）またはＣＰＵなどの中央演算処理装置と、これを機能させるためのプログラム（ソフトウェア）によって構成される。そのプログラムは、サーバ１００またはユーザ端末１２０が備えるメモリなどの記憶部、または外部から挿入される記憶メディアに記憶されることができ、またインターネットなどのネットワークを介してサーバ１００またはユーザ端末１２０にダウンロードされることができる。

［２−６．既に実施予定のあるイベントに基づくコミュニティ形成］
次に、既に実施予定のあるイベントに基づくコミュニティ形成について説明する。例えば、ユーザが同じイベントに参加していた、同じチームを応援していた、などの事実は、イベント条件の一部としてとらえることができる。ホストユーザは、イベント条件として、招待するゲストの条件に過去に行われたイベントの参加者という条件を設定する。その他、詳細には、応援するチームの種別なども設定可能とする。

同じイベントに参加したことを認識する手法として、ユーザから取得した環境音が類似する環境音（応援歌）であれば、環境音を取得したユーザ同士に強い結び付きを設定する。この場合、同じチームを応援している可能性が高いと考えられるためである。また、会場、放送波に可聴域外の音声識別信号を重畳することで認識してもよい。

また、以下の情報に応じて、招待オーダーを定めてもよい。これらの情報は、全てユーザ端末１２０で取得されて、サーバ１００へ送られる。
・試合中、試合に向けたツイートなどの発言に基づき、好きなチーム、選手を認識する。
・事前に応援チーム、さらに選手などを登録する。
・位置（スタジアムでの座席情報）に応じて応援しているチームを認識する
・心拍、発汗、脳波でエキサイトしたポイント（時間的に）が近いと認識する。

以上説明したように第１の実施形態によれば、イベント条件に応じてイベントの招待条件を設定することで、イベントへの参加に適したユーザに対してイベントの詳細情報を伝えることが可能となる。

３．第２の実施形態
［３．１．第２の実施形態の概要］
次に、本開示の第２の実施形態について説明する。第２の実施形態は、時間と場所の連続的なパターンを使ってコミュニティを形成するものである。例えば、旅行の経路が近い人達を自動的にグルーピングする例を挙げることができ、旅行の際、同じ日に同じようなルートで観光した人たちを自動的にグルーピングし、その人達のコミュニケーションを容易にする。これにより、同じ経路で旅行している複数のグループ間での写真の共有を実現したり、「明日どうする？」といった内容を相談するチャットの開催等が実現できる。

これにより、以前からの知り合いでなくても気軽にそのイベント単位でのコミュニケーションが可能となる。また、たまたま一緒に旅行した人とも自動的に繋がることができ、コミュニケーションを可能とすることができる。

［３．２．第２の実施形態のシステム構成］
図６は、第２の実施形態におけるシステムの概略構成を示す模式図である。図６に示すように、第２の実施形態のシステムは、サーバ２００、各ユーザＡ，Ｂ，Ｃ，・・・（ｎ）のユーザ端末２１０を有して構成される。一例として、サーバ２００とユーザ端末２１０とは、３Ｇ／Ｗｉｆｉで接続されている。

［３．３．第２の実施形態の処理］
図７は、第２の実施形態の処理を示すシーケンス図である。先ず、ステップＳ４０では、ユーザＡが自身のユーザ端末２１０からサーバ２００へ時間位置情報を送信する。次のステップＳ４２では、ユーザＢが自身のユーザ端末２１０からサーバ２００へ時間位置情報を送信する。次のステップＳ４４では、ユーザ（ｎ）が自身のユーザ端末２１０からサーバ２００へ時間位置情報を送信する。

次のステップＳ４６では、サーバ２００が、データベースに基づいてグルーピング情報を生成する。次のステップＳ４８では、サーバ２００がユーザＡのユーザ端末２１０へグルーピング情報を送信する。次のステップＳ５０では、サーバ２００がユーザＢのユーザ端末２１０へグルーピング情報を送信する。次のステップＳ５２では、サーバ２００がユーザ（ｎ）のユーザ端末２１０へグルーピング情報を送信する。

図８は、サーバ２００に提供されるユーザＡの時間位置情報（ログ）例を示す模式図である。図８に示すように、時間の経過に伴って変化するユーザＡの位置情報は、時間（時刻）の情報とともにサーバ２００へ送られる。図８の表の最上段の行の例では、Ｕｓｅｒ Ａが時刻ｘｘ時ｙｙ分ｚｚ秒に緯度ａａａ、経度ｂｂｂの位置にいた事を表している。図８には表示していないが、時間の情報は時、分、秒の他に年、日についての情報も含まれる。

図８に示すように、少なくとも時間と位置の組み合わせのログがユーザ端末２１０からサーバ２００へ送信される。送信は１つのログ毎に行うようにしても良いし、複数のログをまとめて送信しても良い。

位置情報は、主としてユーザ端末２１０のＧＰＳにより取得することができ、その他の３Ｇ,Ｗｉｆｉ等によっても取得可能である。また、ユーザ端末２１０は、時間位置情報の他に、移動速度、進行方向、の他、環境情報（周囲の音、光等）の情報を取得してサーバ２００へ送信することもできる。

ユーザ名は事前にサーバ２００に登録しておく。なお、ユーザ名を使用することは必須でなく、例えばユーザ端末２１０の機器のＩＤなどを代わりに使用しても良い。サーバ２００側では、ユーザ端末２１０の機器とユーザ名の紐付けが可能である。

図９は、サーバ２００が保持する時間位置情報（ログ）データベース例を示す模式図である。図９に示すように、図８に示したログの情報は、各ユーザ毎にサーバ２００へ送信される。

［３．４．グルーピング情報生成の処理］
図１０は、グルーピング情報生成の処理を示すフローチャートである。先ずステップＳ６０では、グルーピング対象の時間範囲を決定する。ここでは、グルーピングのために使用する経路情報の時間範囲をユーザ側、又はサーバ２００のいずれかが設定する。グルーピング対象の時間範囲としては、例えば、「今日」（現在時基準とする）に設定することができる。この場合、「今日」同じ経路で旅行等しているユーザがグルーピングされる。このように、基準時間と時間範囲からグルーピング対象を設定することが可能である。

グルーピングの時間は現在、過去で個別に設定することも可能である。例えば「自分」の「今日の経路」について、「他のユーザ」で「一年前の今日」を基準として「その前後１ヶ月」に同じような経路をたどった人等をグルーピングすることもできる。例えば、去年同じように夏にハワイ旅行へ行った人のグループに、今年の夏休み用にハワイや他のマリンリゾート地への旅行を推薦することなども可能である。
また、ステップＳ６０では、グルーピング対象の位置範囲（地理的範囲）を決定する。決定された位置範囲に位置情報が存在するログデータがグルーピングの対象となる。例えば、位置範囲として所定の緯度、経度の範囲や所定の都市、地域、などを指定することができ、世界全体を位置範囲と指定することもできる。

次のステップＳ６２では、経路情報解析を解析する。ここでは、設定した時間範囲情報に基づいて、ユーザの経路情報を解析する。一例として、ログ軌跡情報を整理することが挙げられる。ログ軌跡に基づく観光ポイント巡り情報を形成する。例えば観光ポイントにタグ情報があれば嗜好情報も推測することが可能である（フランス料理のレストラン、世界遺産巡り、ドライブが好みである等）。また、滞在時間を考慮しても良い。一例として、史跡観光は短時間で済ませ、買い物は長時間要する場合は、買い物がより好みであると推測することができる。

訪れた場所、訪れた順番、等から経路を複数のタイプの経路に類型化してもよい。細かい位置まで考慮せずにぼかすことで、情報量圧縮と個人情報隠匿を達成する。進行方向、移動速度等の補助情報も併せて用いることで、より高精度な類型化が可能となる。進行方向が逆であったり、移動速度が違い過ぎる等の状況であれば、目的地や交通手段に違いがあり、または、それぞれの嗜好が離れた経路と推定できる。また、音声によってグルーピングすることもできる。複数ユーザが同じ音楽を聴いていれば、同じ車で音楽かけながらドライブしていると推定できる。

更に、ユーザ端末２１０が検出する光によってグルーピングすることもできる。同じ場所でも明るい場所に入ればアウトドア志向であり、暗い場所に入ればインドア嗜好である等の推定を行うことが可能である。

経路情報の解析は、必ずしもフローの途中で行わなくても良く、サーバ２００が定期的、あるいはユーザーログのアップデートされたタイミングなど任意の時間に行なっていても良い。

次のステップＳ６４では、経路情報の類似度が高いユーザを抽出する。ここでは、解析結果を用いて、経路情報の類似度が所定のしきい値以上のユーザのグループを抽出する。または類似度が上位から所定順位までのユーザのグループを抽出しても良い。

類似度算出の位置範囲の縮尺レベルも複数段階用意しておくことが好ましい。具体的には、ユーザグループを抽出する条件に応じて、グルーピング対象とするログデータを含む位置範囲を変えることができる。例えば所定の位置範囲の中からグループのメンバーとして抽出されるユーザが所定の人数に対して少なすぎる場合、検索対象となる位置範囲（地理的範囲）を拡大する。また、逆にグルーピングされたメンバー数が所定の人数に対して多すぎる場合は位置範囲を縮小してグループのメンバーを抽出することができる。都市地図レベル、行政区レベル、国レベル、世界レベルでそれぞれ類似度が高いユーザを抽出することで、様々なレベルのグループが生成可能である。同じ都市にいる人達が明日何処へ行くか相談したり、去年インドへ行った人達が今年はどこ行くか相談するなどが可能となる。

また、異なる時間範囲、位置範囲を組み合わせてユーザグループを抽出することもできる。例えば、旅行先への飛行機の経路が異なり、都市内の経路は似たような人でグルーピングする等の使い方ができる。また、類似度は、点数化、ランク化、タグ化しておくことで、ユーザにグルーピング情報を提供するときに視覚化を容易にすることができる。

次のステップＳ６６では、経路情報の類似度に基づいて、グルーピング情報を生成する。ここでは、ステップＳ６４でのユーザ抽出の結果に基づいて、グルーピングされたユーザの情報を生成する。

［３．５．サーバの構成例］
図１１は、上述した処理を実現するサーバ２００の構成を示すブロック図である。サーバ２００は、時間範囲設定部２０２、ユーザ位置情報取得部２０４、位置範囲設定部２０５、移動経路解析部２０６、グループ化部２０８、メッセージ受信部２１０、メッセージ送信部２２０、環境情報取得部２２２を有して構成される。時間範囲設定部２０２は、図１０のステップＳ６０において、グルーピング対象の時間範囲を決定する。この時間範囲は、例えばホストとなるユーザのユーザ端末２１０から入力された情報に基づいて決定することができる。ユーザ経路情報取得部２０４は、各ユーザ端末２１０から送られたユーザの経路情報を取得する。ユーザ経路情報取得部２０４は、図８に示したようなユーザの時間位置情報（ログ）例を取得する。位置範囲設定部２０５は、図１０のフローのステップＳ６０において、付加的なグルーピングの条件に応じてグルーピング対象となるログデータの位置範囲を決定する。位置範囲も例えばホストとなるユーザのユーザ端末２１０から入力された情報に基づいて決定することができる。経路情報解析部２０６は、ステップＳ６２において、取得した経路情報を解析する。グループ化部２０８は、ステップＳ６４において、経路情報の解析結果に基づいて、ユーザのグループ分けを行う。

第１の実施形態と同様に、図１１に示すサーバ２００の各構成要素は、ハードウェア（回路）またはＣＰＵなどの中央演算処理装置と、これを機能させるためのプログラム（ソフトウェア）によって構成される。そのプログラムは、サーバ２００が備えるメモリなどの記憶部、または外部から挿入される記憶メディアに記憶されることができ、またインターネットなどのネットワークを介してサーバ２００にダウンロードされることができる。

第２の実施形態において、ユーザ端末２１０の構成は、図５に示した第１の実施形態のユーザ端末１２０と同様である。

［３．６．グルーピング情報の例］
図１２は、グルーピング情報の例を示す模式図である。図１２に示すように、最低限、ユーザ名のリストを提供する。ログデータは個人データなので、承認が得られたユーザのデータのみを送信する。図１２に示す例では、グループ抽出の結果、ユーザＡとユーザＢがグループ１に属し、ユーザＦとユーザＥがグループ２に属している。

図１３は、グルーピング情報に基づいた画面表示例を示す模式図である。図１３では、複数のユーザの経路がドットで示されており、時間範囲内で経路が類似するユーザがグルーピングされる。同じグループに属し、経路の類似度が非常に高いユーザは、旅行の同行者と推定してグループ化し、ユーザ端末２１０同士で「友達？」かどうかを確認するメッセージを交換し、友達であると確認出来れば写真の共有が可能となる。友達でなくとも、写真を提供するユーザが承認した場合も写真を共有することができる。また、同じグループに属するユーザ同士でチャットしながら地図上で明日行く場所を相談することもできる。また、過去に似たような経路で旅行した人に推薦された観光地等も確認可能である。

サーバ２００は、一度行った経路情報単位でイベントとして保存する。ユーザの自宅位置を登録しておき、ユーザが自宅から一定距離以上離れた場所に行ったら、自宅に戻ってくるまでを「旅行」と推定する。イベントを保存することで、過去のイベント毎のグループにアクセスすることができる。あの時一緒に旅行に行った人とまた旅行に行きたい等のメッセージを交換することもできる。過去のグルーピング情報から、新規イベントを過去のグループに向けて提案することができる。新しい観光ポイントができたタイミングなどで、グループにその情報を発信することもできる。

［３．７．経路情報解析の類型化について］
次に、経路情報解析の類型化の例について説明する。図１４は、ユーザＡの経路を示す模式図である。ここでは、ユーザＡの経路情報の類型化を想定し、特定の日の０７：００〜１９：００を時間範囲とする。ユーザ端末２１０からサーバ２００へ、ユーザ端末２１０の位置情報が逐次送信され、サーバ２００にて位置情報が取得される。

図１５に示すように、図１４に示す経路の情報から、ユーザＡの詳細な時間情報を一定間隔の地点データに間引く。この例では、１時間おきのデータが残るようにデータの間引きを行う。

次に、図１６に示すように、位置を所定の範囲に区分して、時間とユーザがいたエリアのデータを生成する。この例では、ユーザＡは０７：００にエリアＤ−２にいた事になる。そして、図１６のデータを全て処理すると、図１７のようなデータを取得することができる。

ユーザ位置を類型化するデータとしては、図１７に示したものを用いることができる。また、他の態様として、特定のエリアを通過したことに応じて、類型化データを特定することできる。例えば、エリアＣ−４に高速道路のサービスエリアがあり、エリアＡ−６が観光地αであった場合、「ユーザーＡは高速道路経由で（自動車利用で）観光地αに行った人物である」とより大きく類型化することもできる。このように大きく類型化した場合は、その類型をタグ情報としても良い。この場合、特定のポイントを絞り込むため、その特定のポイントと判断される地域をエリアの区分より詳細に設定することが望ましい。

以下では、ユーザＡとＢの経路情報の類似度の計算例について説明する。図１８は、ユーザＡの経路情報とともに、ユーザＢの経路情報を示しており、特定の日の０７：００〜１９：００が時間範囲の場合を示している。図１９は、図１５と同様に、ユーザＢの経路情報を間引いた状態を示している。また、図２０及び図２１は、図１６及び図１７と同様に、ユーザＡ，Ｂの位置を所定の範囲に区分して、時間とユーザＡ，Ｂがいたエリアのデータを生成した状態を示している。

図２２は、類似度を計算した例を示す模式図である。基本的にはユーザＡ，Ｂが同じ時間に同じ場所にいると類似度が高くなる。図１８の例では、ユーザＡ，Ｂが同じ時間に同じ場所にいた場合、類似度＋１としている。各時間毎の類似度の総計を、最終的なユーザＡとＢの類似度とする。この場合、ユーザＡとユーザＢの時刻０７：００〜１９：００の類似度は“１＋１＋１＋１＋１＝５”となる。

図２３及び図２４は、エリアが同一か否かの判定以外に、エリアの近接度合いに応じた時間毎類似度を用いた例を示す模式図である。例えば、図２４に示すように、特定のエリア（図２４では、Ｃ−３のエリア）に隣接する８エリアについては、時間毎の類似度を０．５とすることができる。この手法を図２２の例に適用すると、図２３に示すように、時刻０７：００の類似度と時刻１６：００の類似度が“０．５”となる。従って、ユーザＡとユーザＢの時刻０７：００〜１９：００の類似度は“０．５＋１＋１＋０．５＋１＋１＋１＝６”となり、図２２の場合よりも類似度が高くなり、より詳細に類似度を判定することが可能である。同様に、近接する時間（前後１時間など）についても、時間の近接度合いに応じた補正係数を用いても良い。

また、他の例として、図２５に示すように、時間経過に応じた補正係数を乗算してもよい。現在（１９：００とする）に近いほど類似度が高くなるようにする。旅行目的地の近くにいるはずの時間ほど類似度計算に有効とすることで、現在の目的地が近い場所にいるユーザを探し出すことができる。

更に他の例として、これまでのログデータから行き先を推定し、類似度を計算しても良い。例えば７：００〜１４：００の間のデータから１９：００時点の類似度を推定したり、他ユーザの過去データの統計から行き先を推定する等の手法を採ることができる。サーバ２００の経路情報解析部２０６では、上述の図１５〜図２５で示した処理を行う。

サーバ２００のグループ化部２０８は、類似度に基づいてグループを設定する。この場合、時刻０７：００〜１９：００の類似度の合計にしきい値を設け、類似度の合計が閾値を上回った場合に、ユーザＡとユーザＢが同じグループに属するものとすることができる。

以上説明したように第２の実施形態によれば、時間範囲内でユーザの位置情報を取得し、時間範囲内の経路が類似するユーザをグループ化することができる。従って、グループ化されたユーザ同士で情報を交換することが可能となる。

＜４．第３の実施形態＞
［４．１．第３の実施形態の概要］
次に、本開示の第３の実施形態について説明する。第３の実施形態は、現在、同様の環境にいるユーザをグループ化するものである。これにより、グループ化されたユーザに対して情報を発信することができ、または同一グループ内のユーザからの情報を集計することができる。

ここで、同様の環境とは、位置・行動が類似している場合、同じ電車に乗車している場合、同じ交通渋滞に巻き込まれている場合、等が挙げられる。ユーザの自動グループ化は、各ユーザの位置・行動情報に基づいて行う。発信する情報としては、ユーザ間のメッセージ配信、サーバからグループ内ユーザへのメッセージ配信、各車両の現在の混雑度、混雑度予測、渋滞情報などが挙げられる。

第３の実施形態のシステム構成は、図６に示した第２の実施形態と同様であり、サーバ３００とユーザ端末４００を有して構成される。各ユーザＡ，Ｂ，Ｃ，・・・（ｎ）のユーザ端末４００からサーバ３００へ、位置・行動情報が送られる。サーバ３００は、位置・行動情報に基づいてユーザをグループ化する。

［４．２．第３の実施形態の処理］
図２６は、第３の実施形態の処理を示すフローチャートである。先ず、ステップＳ７０では、ユーザの位置・行動情報を取得する。

次のステップＳ７２では、ユーザの位置・行動に基づいてユーザをグループ化する。ここでは、ユーザの行動種別、位置、移動速度、移動方向等に基づいて、ユーザ同士をグループ化する。移動速度、移動方向の算出は、ユーザ端末４００上、またはサーバ３００上のいずれで行ってもよい。

グループ化の単位としては、例えば同じ電車に乗車しているユーザをグループ化する。この場合、行動種別が電車であり、相対的に所定範囲内に位置し、ほぼ同じ移動速度（相対速度がほぼゼロ）で移動しており、相対的に所定範囲内の方向に移動するユーザ同士をグループ化する。

また、同じバス、または車に乗車しているユーザをグループ化することができる。この場合、行動種別がバスまたは車であり、相対的に所定範囲内に位置し、ほぼ同じ移動速度（相対速度がほぼゼロ）で移動しており、相対的に所定範囲内の方向に移動するユーザ同士をグループ化する。

また、同じ交通渋滞に巻き込まれているユーザをグループ化することができる。この場合、行動種別がバスまたは車であり、相対的に所定範囲内に位置し、移動速度が所定速度以下であり、相対的に所定範囲内の方向に移動するユーザ同士をグループ化する。

次のステップＳ７４では、ステップＳ７２でグループ化された同一グループのユーザに向けて情報発信を行う。また、ステップＳ７４では、ステップＳ７２でグループ化された同一グループ内のユーザからの情報を集計する。

［４．３．サーバの構成例］
図２７は、上述した処理を実現するサーバ３００の構成を示すブロック図である。サーバ３００は、ユーザの位置、行動情報を取得する位置・行動情報取得部３０２、グループ化部３０４、移動速度取得部３０６、情報送信部３０８、行動種別取得部３１０、メッセージ受信部３１２、メッセージ送信部３１４、ＩＤ送信部３１６、メッセージ集計部３１８、制御情報送信部３２０、混雑度算出部３２２、ユーザ状態取得部３２４、空席率算出部３２６、を有して構成される。位置・行動情報取得部３０２は、図２３のステップＳ７０において、ユーザの位置・行動情報を取得する。グループ化部３０４は、ステップＳ７２において、ユーザの行動種別、位置、移動速度、移動方向等に基づいて、ユーザをグループ化する。情報送信部３０８は、ステップＳ７４において、グループ化された同一グループのユーザに向けて情報発信を行う。

また、移動速度取得部３０６は、ユーザ端末４００の移動速度を取得する。移動速度は、ユーザの位置情報と時間とから算出することができる。行動種別取得部３１０は、ユーザの行動種別を取得する。行動種別としては、ユーザ端末４００を保有するユーザが利用する交通機関（電車、バス、自動車（車）など）の種別が挙げられる。また、行動種別取得部３１０はユーザ端末４００の行動認識部４１８が認識したユーザの行動を取得する。メッセージ受信部３１２は、ユーザ端末４００からメッセージを受信する。また、メッセージ送信部３１４は、ユーザ端末４００に対してメッセージを送信する。特に、メッセージ送信部３１４は、メッセージを受信したユーザ端末４００と同じグループに属するユーザ端末４００へメッセージを送信する。ＩＤ送信部３１６は、グループ化された複数のユーザ端末へグループＩＤ又はグループに属するユーザ端末のＩＤを送信する。

また、メッセージ集計部３１８は、グループ化された複数のユーザ端末４００から送信されたメッセージを集計する。制御情報送信部３２０は、メッセージ集計部３１８が集計したメッセージに基づいて、グループ化された複数のユーザ端末が位置する交通機関、又は建物等へ制御情報を送信する。混雑度算出部３２２は、グループ化された複数のユーザ端末４００に対応する領域面積とグループ化された複数のユーザ端末４００の数とに基づいて、混雑度を算出する。ユーザ状態取得部３２４は、グループ化されたユーザ端末４００を使用するユーザが、交通機関の車内で起立しているか又は着座しているかを表すユーザ状態を取得する。空席率算出部３２６は、グループ化された複数のユーザ端末４００の数とユーザ状態とに基づいて、空席率を算出する。

［４．４．ユーザ端末の構成例］
図２８は、ユーザ端末４００の構成を示す模式図である。図２５に示すように、ユーザ端末４００は、通信部４０２、表示部４０４、制御部４０６、入力部４０８、センサデータ作成部４１０、行動認識部４１８を有して構成されている。

センサデータ作成部４１０は、ユーザ行動を感知して、当該ユーザの行動に対応する情報であるセンサデータを作成する。なお、ここで言うユーザ行動とは、ユーザが歩行している、走行している、立っている、座っている、跳躍している、静止している、電車に乗っている、エレベータに乗っている、右折もしくは左折しているなどといった情報を指す。上記のユーザ行動に関する情報は、例えば、ユーザ端末４００を付随しているユーザの行動を表した情報である。上記のセンサデータは、ユーザ端末４００を有するユーザの取った行動に基づく。

行動認識部４１８は、センサデータ作成部４１０からセンサデータを取得する。行動認識部４１８は、当該センサデータに対して所定の閾値処理を行ってユーザが行った行動を認識し、ユーザが行った行動を表す情報である行動情報を生成する。行動認識部４１８は、ユーザが行う行動に特化した複数の行動判定部を更に備え、当該複数の行動判定部における判定結果に基づいて上記の行動情報を生成する。なお、センサデータには、例えば、加速度センサデータと、ジャイロセンサデータとが含まれる。

更に、加速度センサデータには、第一加速度センサデータと、第二加速度センサデータと、第三加速度センサデータとが含まれる。第一加速度センサデータとは、所定の座標軸に沿った加速度に関するデータである。また、第二加速度センサデータとは、第一加速度センサデータとは異なる座標軸に沿った加速度に関するデータであり、例えば、第一加速度センサデータの座標軸に直交する座標軸に沿う。また、第三加速度センサデータとは、第一加速度センサデータ及び第二加速度センサデータとは異なる座標軸に沿った加速度に関するデータであり、例えば、第一加速度センサデータ及び第二加速度センサデータの座標軸に直交する座標軸に沿う。

上記の複数の行動判定部には、静止状態判定部４２２と、歩行・走行状態判定部４２４と、跳躍状態判定部４２６と、姿勢変化判定部４２８と、エレベータ搭乗判定部４３０と、電車搭乗判定部４３２と、右折・左折判定部４３４とが含まれる。

静止状態判定部４２２は、ユーザが静止状態にあるか否かを判定する。歩行・走行状態判定部４２４は、ユーザが歩行状態または走行状態にあるかを判定する。跳躍状態判定部４２６は、ユーザが跳躍している状態である跳躍状態にあるか否かを判定する。姿勢変化判定部４２８は、ユーザが座っている状態または立っている状態にあるのか否かを判定する。エレベータ搭乗判定部４３０は、ユーザがエレベータに乗っている状態か否かを判定する。電車搭乗判定部４３２は、ユーザが電車に乗っている状態か否かを判定する。右折・左折判定部４３４は、ユーザが右折したか左折したかを判定する。このように、本実施形態に係るユーザ端末４００によれば、上記の各行動毎に特化した行動認識機能を有しており、当該各行動を精度良く把握することができる。

［４．５．グループ化されたユーザへのメッセージ配信手法］
次に、グループ化されたユーザへのメッセージ配信手法について説明する。グループ化されたユーザへのメッセージ配信手法としては、先ず、サーバ３００経由のメッセージ配信が挙げられる。この場合、サーバ３００がユーザ端末４００から取得したメッセージを配信する。グループ内ユーザのメッセージをサーバ３００で受信し、サーバ経由で同グループ内の他のユーザ端末４００に配信することができる。

また、他の配信手法として、アドホック（Ａｄｈｏｃ）通信によるメッセージ配信が挙げられる。この場合、ユーザがグループ化された際、サーバ３００からグループＩＤまたは同グループに属するユーザのリストをユーザ端末４００に送信しておく。また、ユーザが直接アドホック（Ａｄｈｏｃ）にメッセージを発信してもよいし、サーバ３００からグループ内の少人数にメッセージを配信し、その少人数ユーザを経由して、サーバ３００からのメッセージが周りのユーザに（Ａｄｈｏｃ）で配信されるようにしてもよい。

同一グループ内のユーザからの情報を集計する方法としては、同一グループ内のユーザからのメッセージを、サーバ３００上で集計する。ユーザ端末４００から発信されるメッセージに付与されたユーザＩＤ、またはグループＩＤに基づいて、グループ単位でサーバ３００が集計する。グループ内ユーザに向けてのみ、サーバ３００からメッセージを配信し、その返信のみをサーバ３００上で集計するようにしてもよい。返信に特定のＩＤを付与する、または返信先をグループ毎に特定しておくなどしてもよい。

［４．６．第３の実施形態の利用例］
以下では、第３の実施形態の利用例について説明する。まず、利用例として、渋滞情報のメッセージ交換を行うことができる。同じ渋滞にはまっているグループ内ユーザのうち、先頭の方に位置しているユーザ群を指定して（自動指定含む）、サーバ３００がメッセージを送信することで、渋滞の原因問い合わせをピンポイントに行うことができる。これにより、渋滞の原因をサーバ３００が取得することができ、グループ内の他のユーザへ渋滞の原因の情報を送ることができる。この場合、グループ内ユーザの進行方向に基づいて、グループの先頭を判定することができるので、その先頭位置から所定範囲内に位置するユーザ群を指定すればよい。

また、車内・室内の空調制御を行うことができる。この場合、「暑い」、「寒い」等のユーザメッセージをサーバ３００で受信して集計する。集計に応じて、室内や車両内の空調を制御することができる。

また、現在の混雑度を推定してユーザに提示することができる。グループ化されたユーザ群に対応する位置に対応する領域面積と、グループ内ユーザの人数に基づいて人口密度を算出し、混雑度として、グループ内または外のユーザに情報発信を行う。更に、同一グループ内のユーザ同士の相対位置に基づいて、同一グループ内のユーザ群を所定数（たとえば車両数）のサブグループに分割し、サブグループ単位で混雑度を推定することで、車両ごとの混雑度が推定することが可能となる。また、行動種別で「座っている」の判別が可能な場合は、「座っているユーザ数」と「（サブ）グループに対応する領域に関連付けられた座席数」とに基づいて、空席率の推定も可能となる。

また、今後の混雑度を予測してユーザに提示することができる。ユーザログ（行動履歴、交通系ＩＣカード等の履歴情報など）が取得可能な場合は、ログに基づいて各ユーザの降車駅が予測可能なため、所定時間経過後または所定駅到着時の混雑度を予測できる。

また、ユーザ端末４００上では、混雑度の表示を行うことができる。この場合、グループ毎またはサブグループ毎の人口密度に基づいた数値で表示してもよいし、人口密度を複数レベルに分割してレベル単位で混雑度を表現してもよい。さらに、求めた数値またはレベルに対応付けられた色や、分布図を使用して表示してもよい。

以上説明したように第３の実施形態によれば、ユーザ端末４００から取得した位置情報に基づいて、同じ環境にいるユーザをグループ化することができる。従って、同じ環境にいるユーザ同士で、その環境に関するメッセージを交換することが可能となる。また、同じ環境にいるユーザからのメッセージを集計して、環境条件を最適に制御することも可能となる。

以上、添付図面を参照しながら本開示の好適な実施形態について詳細に説明したが、本開示の技術的範囲はかかる例に限定されない。本開示の技術分野における通常の知識を有する者であれば、特許請求の範囲に記載された技術的思想の範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、これらについても、当然に本開示の技術的範囲に属するものと了解される。

なお、以下のような構成も本開示の技術的範囲に属する。
（１）ホストのユーザ端末からイベントの条件情報を受信する受信部と、
前記条件情報に基づいて、イベントへ招待可能なユーザを定める招待条件を設定する招待条件設定部と、
前記招待条件に基づいて、イベントの情報をユーザの端末へ送信する送信部と、
を備える、情報処理装置。
（２）前記招待条件設定部は、ユーザの現在位置とイベントの開催場所及び開催時刻とに基づいて、ユーザのスコアを算出し、前記スコアに基づいて前記ユーザの招待条件を設定する、前記（１）に記載の情報処理装置。
（３）前記招待条件設定部は、ユーザの嗜好情報とイベントの種類とに基づいて、ユーザのスコアを算出し、前記スコアに基づいて前記ユーザの招待条件を設定する、前記（１）に記載の情報処理装置。
（４）前記招待条件設定部は、ユーザのプロファイル情報に基づいてユーザのスコアを算出し、前記スコアに基づいて前記ユーザの招待条件を設定する、前記（１）に記載の情報処理装置。
（５）前記招待条件設定部は、ユーザの過去のイベントの参加履歴に基づいて、ユーザのスコアを算出し、前記スコアに基づいて前記ユーザの招待条件を設定する、前記（１）に記載の情報処理装置。
（６）前記招待条件設定部は、前記スコアが所定値以上のユーザを参加候補とし、前記送信部は、前記参加候補のユーザに対してイベントの情報を送信する、前記（２）〜（４）のいずれかに記載の情報処理装置。
（７）前記送信部は、ユーザの現在位置とイベントの開催場所及び開催時刻とに基づいて、ユーザが開催時刻に開催場所に到達できないと見込まれる場合は、当該ユーザを参加候補としない、前記（２）に記載の情報処理装置。
（８）前記イベントの条件情報を前記ユーザ端末上でユーザに入力させるためのメニュー情報を前記ユーザ端末へ送信するメニュー情報送信部を更に備える、前記（１）に記載の情報処理装置。
（９）前記メニュー情報は、イベントの種類、開催場所、開始時刻、終了時刻、参加者年齢、性別、ユーザの現在位置、ユーザの今後のスケジュール、又はユーザの嗜好情報をユーザに入力させるための情報である、前記（８）に記載の情報処理装置。
（１０）前記送信部がイベントの情報を送信したユーザ端末から応答を受信する受信部と、
前記応答に基づいて、当該ユーザがイベントの条件情報に合致するか否かを判定する判定部と、
を備える、前記（１）に記載の情報処理装置。
（１１）ホストのユーザ端末からイベントの条件情報を受信することと、
前記条件情報に基づいて、イベントへ招待可能なユーザを定める招待条件を設定することと、
前記招待条件に基づいて、イベントの情報をユーザの端末へ送信することと、
を備える、情報処理方法。
（１２）ホストのユーザ端末からイベントの条件情報を受信する手段、
前記条件情報に基づいて、イベントへ招待可能なユーザを定める招待条件を設定する手段、
前記招待条件に基づいて、イベントの情報をユーザの端末へ送信する手段、
としてコンピュータを機能させるためのプログラム。
（１３）イベントの条件情報を送信するユーザ端末と、
ホストのユーザ端末からイベントの前記条件情報を受信する受信部と、前記条件情報に基づいて、イベントへ招待可能なユーザを定める招待条件を設定する招待条件設定部と、前記招待条件に基づいて、イベントの情報をユーザの端末へ送信する送信部と、を有する、情報処理装置と、
を備える、情報処理システム。
（１４）複数のユーザを経路に基づいてグループ化するための時間範囲を設定する時間範囲設定部と、
前記時間範囲においてユーザ端末の位置情報を取得する位置情報取得部と、
前記位置情報に基づいて、前記ユーザ端末の移動経路を解析する移動経路解析部と、
前記移動経路の解析結果に基づき、前記複数のユーザをグループ分けするグループ化部と、
を備える、情報処理装置。
（１５）前記移動経路解析部は、時間毎の各ユーザ端末の位置に基づいて、各ユーザ端末の移動経路の類似度を算出し、
前記グループ化部は、前記類似度に基づいてグループ化を行う、前記（１４）に記載の情報処理装置。
（１６）複数のユーザを経路に基づいてグループ化するための位置範囲を設定する位置範囲設定部を有し、
前記位置情報取得部は前記位置範囲に基づいてユーザ端末の位置情報を取得する、前記（１４）に記載の情報処理装置。
（１７）グループ化された前記ユーザ端末から、同じグループに属する他のユーザ端末へ送信されたメッセージを受信するメッセージ受信部と、
前記メッセージを前記他のユーザへ送信するメッセージ送信部と、
を備える、前記（１４）に記載の情報処理装置。
（１８）前記移動経路解析部は、前記位置情報に加えて、前記ユーザ端末の移動速度を考慮して前記移動経路を解析する、前記（１４）に記載の情報処理装置。
（１９）前記ユーザ端末から音又は光を含む環境情報を取得する環境情報取得部を備え、
前記経路解析部は、前記位置情報に加えて、前記環境情報を考慮して前記移動経路を解析する、前記（１４）に記載の情報処理装置。
（２０）前記グループ化部は、１のユーザ端末の前記移動経路の解析結果が、他のユーザ端末の過去の前記移動経路の解析結果と類似する場合は、前記１のユーザ端末と前記他のユーザ端末を同一のグループに所属させる、前記（１４）に記載の情報処理装置。
（２１）複数のユーザを経路に基づいてグループ化するための時間範囲を設定することと、
前記時間範囲においてユーザ端末の位置情報を取得することと、
前記位置情報に基づいて、前記ユーザ端末の移動経路を解析することと、
前記移動経路の解析結果に基づき、前記複数のユーザをグループ分けすることと、
を備える、情報処理方法。
（２２）複数のユーザを経路に基づいてグループ化するための時間範囲を設定する手段、
前記時間範囲においてユーザ端末の位置情報を取得する手段、
前記位置情報に基づいて、前記ユーザ端末の移動経路を解析する手段、
前記移動経路の解析結果に基づき、前記複数のユーザをグループ分けする手段、
としてコンピュータを機能させるためのプログラム。
（２３）位置情報を取得する複数のユーザ端末と、
複数のユーザ端末を経路に基づいてグループ化するための時間範囲を設定する時間範囲設定部と、前記時間範囲において前記ユーザ端末の位置情報を取得する経路情報取得部と、前記位置情報に基づいて、前記ユーザ端末の移動経路を解析する移動経路解析部と、前記移動経路の解析結果に基づき、前記複数のユーザをグループ分けするグループ化部と、を有する情報処理装置と、
を備える、情報処理システム。
（２４）複数のユーザ端末から位置情報を取得する位置情報取得部と、
前記位置情報に基づいて、同一の環境下に置かれたユーザ端末をグループ化するグループ化部と、
を備える、情報処理装置。
（２５）前記ユーザ端末の移動速度を取得する移動速度取得部を備え、
前記グループ化部は、前記位置情報及び前記移動速度に基づいて前記グループ化を行う、前記（２４）に記載の情報処理装置。
（２６）グループ化されたユーザ端末に対して、そのグループに特有の情報を送信する情報送信部を備える、前記（２４）に記載の情報処理装置。
（２７）複数のユーザ端末の行動種別を取得する行動種別取得部を備え、
前記グループ化部は、前記位置情報及び前記行動種別に基づいて、ユーザ端末が同一の環境下に置かれているか否かを判定する、前記（２４）に記載の情報処理装置。
（２８）前記行動種別は、前記ユーザ端末を保持するユーザが利用する交通機関の種別である、前記（２７）に記載の情報処理装置。
（２９）前記グループ化部は、前記交通機関が電車であり、複数のユーザ端末が相対的に所定範囲内に位置し、同じ移動速度で相対的に同じ方向に移動する複数のユーザ端末を、電車を利用しているユーザのグループとしてグループ化する、前記（２８）に記載の情報処理装置。
（３０）前記グループ化部は、前記交通機関がバスであり、複数のユーザ端末が相対的に所定範囲内に位置し、同じ移動速度で相対的に同じ方向に移動する複数のユーザ端末を、バスを利用しているユーザのグループとしてグループ化する、前記（２８）に記載の情報処理装置。
（３１）前記グループ化部は、前記交通機関がバス又は車であり、複数のユーザ端末が相対的に所定範囲内に位置し、移動速度が所定値以下であり、相対的に同じ方向に移動する複数のユーザ端末を、渋滞に巻き込まれているユーザのグループとしてグループ化する、前記（２８）に記載の情報処理装置。
（３２）グループ化された前記ユーザ端末から、同じグループに属する他のユーザ端末へ送信されたメッセージを受信するメッセージ受信部と、
前記メッセージを前記他のユーザへ送信するメッセージ送信部と、
を備える、前記（２４）に記載の情報処理装置。
（３３）グループ化された複数のユーザ端末同士が直接通信を行うために、前記複数のユーザ端末へグループＩＤ又はグループに属するユーザ端末のＩＤを送信するＩＤ送信部を備える、前記（２４）に記載の情報処理装置。
（３４）グループ化された複数のユーザ端末から送信されたメッセージを集計するメッセージ集計部を備える、前記（２４）に記載の情報処理装置。
（３５）集計した前記メッセージに基づいて、前記グループ化された複数のユーザ端末が位置する交通機関、又は建物へ制御情報を送信する制御情報送信部を備える、前記（３４）に記載の情報処理装置。
（３６）グループ化された複数のユーザ端末に対応する領域面積とグループ化された複数のユーザ端末の数とに基づいて、混雑度を算出する混雑度算出部を備え、前記特有の情報として前記混雑度を送信する、前記（２６）に記載の情報処理装置。
（３７）グループ化されたユーザ端末を使用するユーザが、前記交通機関の車内で起立しているか又は着座しているかを表すユーザ状態を取得するユーザ状態取得部と、
前記グループ化された複数のユーザ端末の数と前記ユーザ状態とに基づいて、空席率を算出する空席率算出部と、
を備え、前記特有の情報として前記空席率を送信する、前記（２６）に記載の情報処理装置。
（３８）複数のユーザ端末から位置情報を取得することと、
前記位置情報に基づいて、同一の環境下に置かれたユーザ端末をグループ化することと、
を備える、情報処理方法。
（３９）複数のユーザ端末から位置情報を取得する手段、
前記位置情報に基づいて、同一の環境下に置かれたユーザ端末をグループ化する手段、
としてコンピュータを機能させるためのプログラム。
（４０）位置情報を取得するユーザ端末と、
複数の前記ユーザ端末から前記位置情報を取得する位置情報取得部と、
前記位置情報に基づいて、同一の環境下に置かれたユーザ端末をグループ化するグループ化部と、
を備える、情報処理装置。

１００ サーバ
１０２ｂ 受信部
１０６ 招待条件設定部
１０４ｂ 送信部

Claims (12)

1. ホストのユーザ端末からイベントの条件情報を受信する受信部と、
   前記条件情報に基づいて、イベントへ招待可能なユーザを定める招待条件を設定する招待条件設定部と、
   前記招待条件に基づいて、イベントの情報をユーザの端末へ送信する送信部と、
   を備え、
   前記招待条件設定部は、ユーザの将来のスケジュールに基づく将来位置とイベントの開催場所及び開催時刻とに基づいて、ユーザのスコアを算出し、前記スコアに基づいて前記ユーザの前記招待条件を設定する、情報処理装置。
2. 前記招待条件設定部は、ユーザの嗜好情報とイベントの種類とに基づいて、ユーザのスコアを算出し、前記スコアに基づいて前記ユーザの前記招待条件を設定する、請求項１に記載の情報処理装置。
3. 前記招待条件設定部は、ユーザのプロファイル情報に基づいてユーザのスコアを算出し、前記スコアに基づいて前記ユーザの前記招待条件を設定する、請求項１に記載の情報処理装置。
4. 前記招待条件設定部は、ユーザの過去のイベントの参加履歴に基づいて、ユーザのスコアを算出し、前記スコアに基づいて前記ユーザの前記招待条件を設定する、請求項１に記載の情報処理装置。
5. 前記招待条件設定部は、前記スコアが所定値以上のユーザを参加候補とし、前記送信部は、前記参加候補のユーザに対してイベントの情報を送信する、請求項１〜４のいずれかに記載の情報処理装置。
6. 前記送信部は、ユーザの前記将来位置とイベントの開催場所及び開催時刻とに基づいて、ユーザが開催時刻に開催場所に到達できないと見込まれる場合は、当該ユーザを参加候補としない、請求項１に記載の情報処理装置。
7. 前記イベントの前記条件情報を前記ユーザ端末上でユーザに入力させるためのメニュー情報を前記ユーザ端末へ送信するメニュー情報送信部を更に備える、請求項１〜６のいずれかに記載の情報処理装置。
8. 前記メニュー情報は、前記イベントの種類、開催場所、開始時刻、終了時刻、参加者年齢、性別、ユーザの現在位置、ユーザの今後のスケジュール、又はユーザの嗜好情報をユーザに入力させるための情報である、請求項７に記載の情報処理装置。
9. 前記送信部が前記イベントの情報を送信したユーザ端末から応答を受信する受信部と、
   前記応答に基づいて、当該ユーザがイベントの条件情報に合致するか否かを判定する判定部と、
   を備える、請求項１〜８のいずれかに記載の情報処理装置。
10. ホストのユーザ端末からイベントの条件情報を受信することと、
    前記条件情報に基づいて、イベントへ招待可能なユーザを定める招待条件を設定することと、
    前記招待条件に基づいて、イベントの情報をユーザの端末へ送信することと、
    を備え、
    ユーザの将来のスケジュールに基づく将来位置とイベントの開催場所及び開催時刻とに基づいて、ユーザのスコアを算出し、前記スコアに基づいて前記ユーザの前記招待条件を設定する、情報処理方法。
11. ホストのユーザ端末からイベントの条件情報を受信する手段、
    前記条件情報に基づいて、イベントへ招待可能なユーザを定める招待条件を設定する手段、
    前記招待条件に基づいて、イベントの情報をユーザの端末へ送信する手段、
    としてコンピュータを機能させるためのプログラムであって、
    ユーザの将来のスケジュールに基づく将来位置とイベントの開催場所及び開催時刻とに基づいて、ユーザのスコアを算出し、前記スコアに基づいて前記ユーザの前記招待条件を設定する、プログラム。
12. イベントの条件情報を送信するユーザ端末と、
    ホストのユーザ端末からイベントの前記条件情報を受信する受信部と、前記条件情報に基づいて、イベントへ招待可能なユーザを定める招待条件を設定する招待条件設定部と、前記招待条件に基づいて、イベントの情報をユーザの端末へ送信する送信部と、を有し、前記招待条件設定部は、ユーザの将来のスケジュールに基づく将来位置とイベントの開催場所及び開催時刻とに基づいて、ユーザのスコアを算出し、前記スコアに基づいて前記ユーザの前記招待条件を設定する、情報処理装置と、
    を備える、情報処理システム。