(57)【要約】  【課題】ユーザの過去の行動に基づいて、ユーザ間の交流の有無をより正確に推定することができる交流推定装置を提供することを目的とする。  【解決手段】ユーザ毎の位置ログと、ユーザ毎のアプリログとに基づいて、ユーザ間における交流の有無が推定される。従って、例えば、共通するアプリが使用されたことが考慮されて交流の有無が推定される。これにより、ユーザの過去の行動に基づいて、ユーザ間の交流の有無をより正確に推定することができる。【選択図】  図１
2017194907.tif 000002
【特許請求の範囲】
【請求項１】
ユーザが所持する端末の位置を示す位置情報と、当該位置に係る時刻とを対応付けた位置対応情報をユーザ毎に取得する位置取得手段と、
ユーザによるプログラムの使用状態を示す情報と、当該使用時の時刻とを対応付けたプログラム使用情報をユーザ毎に取得するプログラム使用情報取得手段と、
ユーザ毎の位置対応情報と、ユーザ毎のプログラム使用情報とに基づいて、ユーザ間における交流の有無を推定する推定手段と、
前記推定手段により推定された結果を出力する出力手段と、
を備える交流推定装置。
【請求項２】
前記推定手段は、第１ユーザの位置対応情報の位置と第２ユーザの位置対応情報の位置とが対応している期間と、第１ユーザのプログラム使用情報のプログラム使用状態と第２ユーザのプログラム使用情報のプログラム使用状態とが対応している期間とが共通している期間に基づいて、ユーザ間の交流の有無を推定する、請求項１に記載の交流推定装置。
【請求項３】
所定位置毎におけるユーザ数に基づいた混雑度を時刻毎に取得する混雑度取得手段をさらに備え、
前記推定手段は、前記混雑度取得手段により取得された混雑度にさらに基づいて、ユーザ間における交流の有無を推定する、請求項１又は２に記載の交流推定装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ユーザ間の交流の有無を推定する交流推定装置に関する。
【背景技術】
【０００２】
複数のユーザの位置情報を用いて、ユーザ間の交流の有無を推定する技術がある（例えば、特許文献１参照）。具体的には、一の携帯端末の移動履歴情報（位置情報の履歴情報）と、他の携帯端末の移動履歴情報とを、同一の時間区間同士で比較し、その距離に基づいて同行の有無を判定し、移動履歴情報に含まれる位置情報とその時刻から時間帯別の速度と加速度を求め、移動手段を判定する。続いて、一の携帯端末は、移動手段判定結果を表す情報と、同行の有無の判定結果を表す情報とを用いて、一の携帯端末のユーザと他の携帯端末のユーザとの人間関係が友人関係にあるか否かを判定し、この判定結果に基づいてユーザ間の交流有無を推定する。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０１０−２５７０３６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
特許文献１に記載されているように移動履歴情報に基づいて、ある程度正確にユーザ同士の友人関係を推定できるものと考えられる。しかしながら、位置情報のみに基づいて推定すると、必ずしも正確に交流関係を推定することができないおそれがある。例えば、互いに交流関係が無いユーザが、偶然一緒に移動している場合、誤って交流があると推定してしまうことがある。
【０００５】
本発明は、上記に鑑みてなされたものであり、ユーザの過去の行動に基づいて、ユーザ間の交流の有無をより正確に推定することができる交流推定装置を提供することを目的とする。
【課題を解決するための手段】
【０００６】
上述の課題を解決するために、本発明の交流推定装置は、ユーザが所持する端末の位置を示す位置情報と、当該位置に係る時刻とを対応付けた位置対応情報をユーザ毎に取得する位置取得手段と、ユーザによるプログラムの使用状態を示す情報と、当該使用時の時刻とを対応付けたプログラム使用情報をユーザ毎に取得するプログラム使用情報取得手段と、ユーザ毎の位置対応情報と、ユーザ毎のプログラム使用情報とに基づいて、ユーザ間における交流の有無を推定する推定手段と、推定手段により推定された結果を出力する出力手段と、を備える。
【０００７】
この発明によれば、ユーザ毎の位置対応情報と、ユーザ毎のプログラム使用情報とに基づいて、ユーザ間における交流の有無が推定される。従って、例えば、共通するプログラムが使用されたことが考慮されて交流の有無が推定される。これにより、本発明に係る交流推定装置によれば、ユーザの過去の行動に基づいて、ユーザ間の交流の有無をより正確に推定することができる。
【０００８】
また、この交流推定装置において、推定手段は、第１ユーザの位置対応情報の位置と第２ユーザの位置対応情報の位置とが対応している期間と、第１ユーザのプログラム使用情報のプログラム使用状態と第２ユーザのプログラム使用情報のプログラム使用状態とが対応している期間とが共通している期間に基づいて、ユーザ間の交流の有無を推定してもよい。
【０００９】
この発明によれば、互いのユーザの位置とプログラム使用状態とが共通している期間に基づいて交流の有無を推定するので、一緒にいて、同じプログラムを使用しているような交流がある可能性が高い状態を特定することにより、ユーザ間の交流を正確に推定することができる。
【００１０】
また、この交流推定装置において、所定位置毎におけるユーザ数に基づいた混雑度を時刻毎に取得する混雑度取得手段をさらに備え、推定手段は、混雑度取得手段により取得された混雑度にさらに基づいて、ユーザ間における交流の有無を推定してもよい。
【００１１】
この発明によれば、混雑度を用いて推定するので、例えば、互いに交流が無いユーザが混雑している箇所に偶然近くにいる場合に、当該ユーザ間に交流があると誤って推定してしまう可能性を低減させることができる。
【発明の効果】
【００１２】
本発明によれば、ユーザの過去の行動に基づいて、ユーザ間の交流の有無をより正確に推定することができる。
【図面の簡単な説明】
【００１３】
【図１】本発明の実施形態に係る交流推定装置であるサーバの構成を示す図である。
【図２】生位置情報テーブルのテーブル構成を示す図である。
【図３】生アプリ利用テーブルのテーブル構成を示す図である。
【図４】加工位置情報テーブルのテーブル構成を示す図である。
【図５】混雑度テーブルのテーブル構成を示す図である。
【図６】加工アプリ利用テーブルのテーブル構成を示す図である。
【図７】交流指標テーブルのテーブル構成を示す図である。
【図８】本発明の実施形態に係る交流推定装置であるサーバのハードウェア構成を示す図である。
【図９】本発明の実施形態に係る交流推定装置で、実行される処理を示すフローチャートである。
【発明を実施するための形態】
【００１４】
以下、図面と共に本発明に係る交流推定装置の実施形態について詳細に説明する。なお、図面の説明においては同一要素には同一符号を付し、重複する説明を省略する。
【００１５】
図１に本実施形態に係る交流推定装置であるサーバ１０を示す。サーバ１０は、ユーザの過去の行動に基づいて、ユーザ間の交流の有無を推定する装置である。本実施形態において、過去の行動とは、ユーザの過去の位置及びユーザが過去に利用（使用）したプログラム（アプリケーション、ソフトウェア）を含む。また、交流とは、ユーザ間が知り合い、友人関係、血縁関係等何らかの関わりがあることをいう。ユーザ間の交流の有無の推定結果は、例えば、広告情報等の情報配信に利用される。例えば、サーバ１０は、交流のあるユーザ同士が共通の趣味嗜好を有していると推定して、互いに交流があると推定されるユーザに同一の広告情報を配信する。
【００１６】
ユーザ端末３０は、ユーザによって携帯されて用いられる装置である。ユーザ端末３０は、具体的には、携帯電話機やスマートフォン等に相当する。ユーザ端末３０は、移動体通信網等のネットワークＮに接続して無線通信を行う機能を有している。ユーザ端末３０とサーバ１０とは、ネットワークＮを介して通信を行うことができ、互いに情報の送受信を行えるようになっている。
【００１７】
また、ユーザ端末３０は、測位機能を有しており、ユーザ端末３０の位置を測位することができる。この測位機能は、例えば、ＧＰＳ（Global Positioning System）受信機を用いる等、周知技術により実現される。ユーザ端末３０は、予めユーザ端末３０で定められた測位周期（例えば、数分）で測位を実行する。ユーザ端末３０は、測位を実行すると、測位した結果の情報である位置ログを生成する。位置ログには、測位点ＩＤと、ユーザＩＤと、緯度と、経度と、位置取得時刻とが含まれる。測位点ＩＤは、上記位置ログの識別子であり、例えば、位置ログを生成する度に生成される。ユーザＩＤは、ユーザ端末３０の識別子である。このユーザＩＤは、予めユーザ端末３０に記憶されている。緯度及び経度は、ユーザ端末３０の位置（例えば、ユーザ端末３０により測位された位置）を示す情報である。位置取得時刻は、ユーザ端末３０の位置に対応する時刻（例えば、測位した時刻）である。ユーザ端末３０は、これらの情報を位置ログとして生成する。このように、位置ログは、ユーザ端末３０の位置履歴（ユーザの過去の位置）を示す情報である。また、位置ログには、位置取得時刻を含むので、位置ログが示す位置毎に時刻が対応付けられている。ユーザ端末３０は、生成した位置ログをサーバ１０へ送信する。ユーザ端末３０は、位置ログを生成する度に位置ログをサーバ１０へ送信するようにしてもよいし、予め定められた期間経過後にまとめてサーバ１０へ送信するようにしてもよい。
【００１８】
また、ユーザ端末３０には、アプリケーション（アプリ）がインストールされている。ユーザ端末３０がインストールしているアプリには、アプリの利用ログを取る対象となるアプリが含まれる。このアプリは、交流のあるユーザ同士でコミュニケーションを取りながら利用されるアプリである。例えば、ゲームアプリ等である。ユーザ端末３０は、ユーザ操作に応じて、アプリケーションを起動すると、起動対象のアプリケーションの識別子であるアプリＩＤと、利用開始時刻とを記憶する。また、ユーザ端末３０は、ユーザ操作に応じて、上記アプリケーションの起動を終了すると、利用終了時刻を記憶する。そして、ユーザ端末３０は、ログＩＤ、ユーザＩＤ、アプリＩＤ、利用開始時刻、及び利用終了時刻を対応付けたアプリ利用ログ（プログラム使用情報）を生成する。このアプリ利用ログは、ユーザＩＤが示すユーザが、アプリＩＤが示すアプリを利用開始時刻から利用終了時刻まで使用したことを示す。よって、アプリ利用ログのアプリＩＤがプログラムの使用状態を示す情報となる。ユーザ端末３０は、生成したアプリ利用ログをサーバ１０へ送信する。ユーザ端末３０は、アプリ利用ログを生成する度にアプリ利用ログをサーバ１０へ送信するようにしてもよいし、予め定められた期間経過後にまとめてサーバ１０へ送信するようにしてもよい。
【００１９】
続いて、サーバ１０の説明をする。サーバ１０は、位置取得部１１（位置取得手段）と、生位置情報テーブル１２と、アプリ使用情報取得部１３（プログラム使用情報取得手段）と、生アプリ利用テーブル１４と、推定部１５（推定手段、混雑度取得手段）と、加工位置情報テーブル１６と、混雑度テーブル１７と、加工アプリ利用テーブル１８と、交流指標テーブル１９と、出力部２０（出力手段）とを備えて構成される。
【００２０】
位置取得部１１は、ユーザが所持するユーザ端末３０の位置を示す位置情報と、当該位置に係る時刻とを対応付けた位置対応情報（位置ログ）をユーザ毎に取得する部分である。位置取得部１１は、ユーザ端末３０から送信された位置ログを受信して取得し、生位置情報テーブル１２へ出力する。生位置情報テーブル１２は、位置ログを記憶するテーブルである。ここで、生位置情報テーブル１２が記憶する情報の例を図２に示す。図２に示すように、生位置情報テーブル１２は、「測位点ＩＤ」欄と、「ユーザＩＤ」欄と、「緯度」欄と、「経度」欄と、「位置取得時刻」欄とを含むテーブルである。位置取得部１１は、「測位点ＩＤ」、「ユーザＩＤ」、「緯度」、「経度」、及び「位置取得時刻」のそれぞれの欄に、位置ログの測位点ＩＤ、位置ログのユーザＩＤ、位置ログの緯度、位置ログの経度、及び位置ログの位置取得時刻をそれぞれ出力する。
【００２１】
アプリ使用情報取得部１３は、ユーザによるアプリの使用状態を示す情報と、当該使用時の時刻とを対応付けたアプリ使用情報をユーザ毎に取得する部分である。アプリ使用情報取得部１３は、ユーザ端末３０から送信されたアプリログを受信して取得し、生アプリ利用テーブル１４へ出力する。生アプリ利用テーブル１４は、アプリログを記憶するテーブルである。ここで、生アプリ利用テーブル１４が記憶する情報の例を図３に示す。図３に示すように、生アプリ利用テーブル１４は、「ログＩＤ」欄と、「ユーザＩＤ」欄と、「アプリＩＤ」欄と、「利用開始時刻」欄と、「利用終了時刻」欄とを含むテーブルである。アプリ使用情報取得部１３は、「ログＩＤ」、「ユーザＩＤ」、「アプリＩＤ」、「利用開始時刻」、及び「利用終了時刻」のそれぞれの欄に、アプリログのログＩＤ、アプリログのユーザＩＤ、アプリログのアプリＩＤ、アプリログの利用開始時刻、及びアプリログの利用終了時刻をそれぞれ出力する。
【００２２】
推定部１５は、ユーザ毎の位置ログと、ユーザ毎のアプリ使用ログとに基づいて、ユーザ間における交流の有無を推定する部分である。推定部１５は、予め定めているタイミング（例えば、１週間又は１ヶ月に一回）になると、ユーザ間における交流の有無を推定する処理（推定処理）を行なう。
【００２３】
推定部１５は、推定処理のタイミングになると、生位置情報テーブル１２に記憶されている位置ログを編集し、編集したデータを加工位置情報テーブル１６へ出力する（位置ログ編集処理）。また、推定部１５は、加工位置情報テーブル１６に記憶されている情報を用いて、各位置の混雑度を算出して、算出した結果を混雑度テーブル１７へ入力する（混雑度算出処理）。ここで、混雑度とは、ある位置（例えば、メッシュ）におけるユーザの密集度合を示す情報である。また、メッシュとは、公知の地域メッシュである。この地域メッシュとは、緯度及び経度に基づいて地域をほぼ同じ大きさの網の目（メッシュ）に分けたものである。また、この地域メッシュのそれぞれには、予め識別情報（メッシュコード）が設定されている。また、推定部１５は、生アプリ利用テーブル１４に記憶されている情報と、加工位置情報テーブル１６に記憶されている情報と、混雑度テーブルに記憶されている情報とを用いて、アプリログを編集し、編集した情報を加工アプリ利用テーブル１８へ出力する（アプリログ編集処理）。
【００２４】
推定部１５は、加工位置情報テーブル１６に記憶されている情報と、加工アプリ利用テーブル１８に記憶されている情報とを用いて、ユーザ間の交流有無を推定する。位置ログ編集処理、混雑度算出処理、及びアプリログ編集処理の詳細を説明して、推定処理の詳細を説明する。
【００２５】
まず、位置ログ編集処理の詳細を説明する。推定部１５は、同一ユーザの位置ログが１分毎に存在するように、位置ログ編集処理として新たな位置ログを内挿する。例えば、図２に示したように、ユーザＩＤ「００１」のユーザの位置ログの位置取得時刻が「２０１５−０８−０７の１０：００」の位置ログ（レコードＲ１の位置ログ）と、位置取得時刻が「２０１５−０８−０７の１０：０５」の位置ログ（レコードＲ２の位置ログ）とがある。また、上記２つの位置ログの間の位置取得時刻の位置ログが存在していない。この場合、推定部１５は、レコードＲ１及びレコードＲ２における位置取得時刻間の差分値と、緯度間の差分値と、経度間の差分値とを算出する。
【００２６】
推定部１５は、上記の位置取得時刻間の差分値と、緯度間の差分値と、経度間の差分値とに基づいて、ユーザＩＤ「００１」のユーザの位置ログが１分毎に存在するように、位置ログを内挿する。すなわち、推定部１５は、位置取得時刻が、１０時２分、１０時３分、及び１０時４分の位置ログを生成する。なお、推定部１５は、全てのユーザの位置ログに対して、上記の処理を行なう。このように、推定部１５は、各ユーザの位置ログに基づいて、それぞれのユーザの位置ログが１分毎に存在する状態にする（位置ログを内挿する）ので、それぞれのユーザのユーザ端末３０の測位タイミングによらずに、同時刻の複数のユーザの位置を比較することができる。
【００２７】
推定部１５は、ユーザ端末３０から取得した位置ログ（生位置情報テーブル１２に記憶されている位置ログ）と、上記のように推定部１５が生成した位置ログ（内挿した位置ログ）とを、加工位置情報テーブル１６へ出力する。具体的には、推定部１５は、上記の位置ログ（生位置情報テーブル１２に記憶されている位置ログ及び内挿した位置ログ）が一意となる識別子（内挿点ＩＤ）を生成し、当該内挿点ＩＤと、上記位置ログとを対応付けた情報を加工位置情報テーブル１６へ出力する。
【００２８】
ここで、加工位置情報テーブル１６が記憶する情報の例を図４に示す。図４に示すように、加工位置情報テーブル１６は、「内挿点ＩＤ」欄と、「ユーザＩＤ」欄と、「緯度」欄と、「経度」欄と、「位置取得時刻」欄とを含むテーブルである。推定部１５は、「内挿点ＩＤ」、「ユーザＩＤ」、「緯度」、「経度」、及び「位置取得時刻」のそれぞれの欄に、上記で生成した内挿点ＩＤ、位置ログのユーザＩＤ、位置ログの緯度、位置ログの経度、及び位置ログの位置取得時刻をそれぞれ出力する。
【００２９】
続いて、混雑度算出処理について説明する。推定部１５は、上記位置情報編集処理をした後に、加工位置情報テーブル１６に記憶された情報を参照して、位置取得時刻（加工位置情報テーブル１６の「位置取得時刻」欄に記憶されている時刻）毎におけるメッシュ内の人数を算出し、算出した人数に基づいて混雑度を算出する。推定部１５は、加工位置情報テーブル１６に記憶された情報を参照し、各レコードの緯度及び経度からメッシュを特定する。具体的には、推定部１５は、当該緯度及び経度に対応するメッシュコードを公知技術により特定する。例えば、推定部１５が、緯度経度とメッシュコードとの対応表を記憶しておき、当該対応表を参照してメッシュコードを特定する。
【００３０】
続いて、推定部１５は、同一メッシュコードであり、且つ同一位置取得時刻である加工位置情報テーブル１６のレコードを特定することにより、位置取得時刻毎のメッシュ内の人数を算出する。また、推定部１５は、当該位置取得時刻である加工位置情報テーブルのレコードを特定することにより、当該位置取得時刻の全ユーザ数を算出する。続いて、推定部１５は、位置取得時刻毎のメッシュ内の人数を当該位置取得時刻の全ユーザ数で除算し、当該除算により算出された値を混雑度とする。推定部１５は、加工位置情報テーブル１６内の全てのレコードを参照して、メッシュコード及び位置取得時刻毎に、上記のように混雑度を算出する。このように、推定部１５は、位置毎におけるユーザ数に基づいた混雑度を位置取得時刻毎に算出（取得）する。推定部１５は、位置取得時刻及びメッシュ毎に混雑度を算出して、メッシュコード、位置取得時刻、及び混雑度を対応付けた情報を混雑度テーブル１７へ出力する。
【００３１】
ここで、混雑度テーブル１７が記憶する情報の例を図５に示す。図５に示すように、混雑度テーブル１７は、「メッシュコード」欄と、「位置取得時刻」欄と、「混雑度」欄とを含むテーブルである。推定部１５は、「メッシュコード」、「位置取得時刻」、及び「混雑度」のそれぞれの欄に、上記で対応付けた情報の内のメッシュコード、位置取得時刻、及び上述のように算出した混雑度をそれぞれ出力する。
【００３２】
続いて、アプリログ編集処理について説明する。推定部１５は、混雑度算出処理を終了すると、アプリログ編集処理を開始する。推定部１５は、生アプリ利用テーブル１４に記憶されている情報を参照し、「ユーザＩＤ」欄、「アプリＩＤ」欄、「利用開始時刻」欄、及び「利用終了時刻」欄に記憶されている情報を取得する。推定部１５は、当該アプリログの利用開始時刻から利用終了時刻まで１分毎のデータ（時刻別アプリ利用情報）を生成する。例えば、図３に示したように、ユーザＩＤが「００１」で、アプリＩＤが「Ａｐｐ＿００１」であるレコードの利用開始時刻が「２０１５−０８−０７の１０：００」であり、当該レコードの利用終了時刻が「２０１５−０８−０７の１０：１０」である。この場合、推定部１５は、ユーザＩＤが「００１」で、アプリＩＤが「Ａｐｐ＿００１」である点が共通であり、利用時刻が「２０１５−０８−０７の１０：００」〜「２０１５−０８−０７の１０：１０」である時刻別アプリ利用情報を生成する。
【００３３】
このように、推定部１５は、アプリの利用開始時刻から利用終了時刻まで１分刻みで離散化する。続いて、推定部１５は、加工位置情報テーブル１６を参照して、当該時刻別アプリ利用情報のユーザＩＤ及び利用時刻に対応する緯度及び経度（アプリ利用時位置情報）を取得する。続いて、推定部１５は、当該アプリ利用時位置情報（緯度経度）に対応するメッシュコードを特定する。続いて、推定部１５は、混雑度テーブル１７を参照し、当該メッシュコードと、時刻別アプリ利用情報の利用時刻とに対応する混雑度を取得する（アプリ利用時混雑度情報）。推定部１５は、上記時刻別アプリ利用情報に、アプリ利用時位置情報及びアプリ利用時混雑度情報を対応付けた情報を加工アプリ利用テーブル１８へ出力する。
【００３４】
ここで、加工アプリ利用テーブル１８が記憶する情報の例を図６に示す。図６に示すように、加工アプリ利用テーブル１８は、「ユーザＩＤ」欄と、「アプリＩＤ」欄と、「利用時刻」欄と、「緯度」欄と、「経度」欄と、「メッシュコード」欄と、「混雑度」欄とを含むテーブルである。推定部１５は、「ユーザＩＤ」、「アプリＩＤ」、「利用時刻」、「緯度」、「経度」、「メッシュコード」、及び「混雑度」のそれぞれの欄に、時刻別アプリ利用情報のユーザＩＤ、時刻別アプリ利用情報のアプリＩＤ、時刻別アプリ利用情報の利用時刻、アプリ利用時位置情報の緯度、アプリ利用時位置情報の経度、アプリ利用時位置情報から特定されたメッシュコード、及びアプリ利用時混雑度情報の混雑度を出力する。このように、推定部１５は、生アプリ利用テーブル１４、加工位置情報テーブル１６、及び混雑度テーブル１７に記憶されている情報をマージした情報を加工アプリ利用テーブル１８へ出力する。
【００３５】
続いて、推定部１５は、場所に基づく指標値と、アプリに基づく指標値とを算出する。場所に基づく指標値とは、互いのユーザが近い位置（場所）にいたことを示す指標値である。アプリに基づく指標値とは、互いのユーザが近い位置にいた期間における共通のアプリの使用度合を示す指標値である。まず、推定部１５は、加工位置情報テーブル１６を参照して、互いのユーザが近い位置にいた時間を場所に基づく指標値として算出する。具体的に、推定部１５は、加工位置情報テーブル１６の「ユーザＩＤ」欄を参照して、２人のユーザの組み合わせ毎に上記指標値の算出を行う。推定部１５は、２人のユーザの組み合わせ全てについて当該指標値の算出を行う。この組み合わせの一のユーザを基準となるユーザである基準ユーザ（第１ユーザ）に決定する。また、推定部１５は、上記組み合わせにおける基準ユーザとは異なるユーザＩＤを、基準ユーザの交流候補のユーザである候補ユーザ（第２ユーザ）に決定する。
【００３６】
続いて、推定部１５は、加工位置情報テーブル１６を参照し、互いのユーザ（基準ユーザ及び候補ユーザ）の位置取得時刻が同一であり、互いのユーザの緯度の差及び経度の差がそれぞれ０．０００１以内である情報を特定し、この特定した情報の位置取得時刻が連続する期間を特定する。推定部１５は、この特定した期間の内、最も長い期間を示す値を場所に基づく指標値とする。この場所に基づく指標値が示す期間が長ければ長いほど互いのユーザが長く近い位置にいたことを示し、交流がある可能性が高いことを示す。なお、推定部１５は、連続する期間を合算した期間を示す値を場所に基づく指標値とするようにしてもよい。
【００３７】
続いて、推定部１５は、アプリに基づく指標値を算出する。具体的に、推定部１５は、加工アプリ利用テーブル１８を参照して、上述の特定した情報の位置取得時刻が連続する期間内において、互いに共通するアプリを使用している期間を特定する。具体的に、推定部１５は、上記期間中における、基準ユーザ及び候補ユーザに対応するアプリＩＤを特定し、双方のユーザのアプリＩＤが共通している期間を特定する。
【００３８】
推定部１５は、この期間における各時刻の混雑度を特定し、特定した混雑度の逆数を合算した値をアプリに基づく指標値とする。例えば、図６に示すように、ユーザＩＤが「００１」であるユーザが、利用時刻欄に示す２０１５年８月７日１０時１分〜１０時５分までアプリＩＤ「Ａｐｐ＿００１」のアプリを利用している。また、ユーザＩＤが「００２」であるユーザもユーザＩＤが「００１」であるユーザ付近に上記期間に位置しており、アプリＩＤ「Ａｐｐ＿００１」のアプリを利用していたとする。この場合、推定部１５は、この期間における混雑度の逆数を合算して、アプリに基づく指標値を算出する。
【００３９】
このように、互いのユーザが近い位置にいる時に、共通のアプリを利用していた期間における混雑度の逆数を合算する。よって、長い期間共通のアプリを利用しているほど、アプリに基づく指標値が高くなる。従って、アプリに基づく指標値が高いほど、ユーザ間の交流がある可能性が高いことを示す。また、推定部１５は、混雑度の逆数を合算しているので、混雑している場所で共通のアプリを利用している場合に、アプリに基づく指標値がそれほど高くならない。すなわち、混雑している箇所で、交流の無いユーザ同士が、偶然同一のアプリを利用していたとしても、アプリに基づく指標値が高くならない。従って、交流の無いユーザを誤って交流があると推定してしまうことを防止している。
【００４０】
上述のように、推定部１５は、当該アプリに基づく指標値を用いて、交流の有無を推定するので、混雑度に基づいて、ユーザ間における交流の有無を推定する。また、推定部１５は、基準ユーザの位置と候補ユーザの位置とが対応している期間と、基準ユーザのアプリ使用状態と候補ユーザのアプリ使用状態とが対応している期間とが共通している期間に基づいて、ユーザ間の交流の有無を推定することになる。
【００４１】
続いて、推定部１５は、場所に基づく指標値と、アプリに基づく指標値とを用いて、交流の有無を判断するための値（判断値）を算出する。例えば、場所に基づく指標値に係数を乗算した値と、アプリに基づく指標値に係数を乗算した値とを加算した値を判断値とする。これらの係数は、予め記憶している値であり、正の値である。
【００４２】
推定部１５は、予め交流有無を判定するための閾値を記憶しており、この閾値と、判断値とを比較して、交流の有無を推定する。具体的に、推定部１５は、判断値が閾値を超える場合、基準ユーザと候補ユーザとは、交流があると推定する。また、推定部１５は、判断値が閾値以下である場合、基準ユーザと候補ユーザとは、交流が無いと推定する。なお、推定部１５は、２人のユーザの組み合わせ全てに対して、上記交流の有無を推定する。続いて、推定部１５は、推定した結果を含む情報を出力部２０へ送出する。具体的に、推定部１５は、基準となるユーザのユーザＩＤと、候補ユーザのユーザＩＤと、場所に基づく指標値と、アプリに基づく指標値と、推定結果とを出力部２０へ送出する。
【００４３】
出力部２０は、推定部１５によって推定された結果を出力する部分である。出力部２０は、推定部１５から基準となるユーザのユーザＩＤと、候補ユーザのユーザＩＤと、場所に基づく指標値と、アプリに基づく指標値と、推定結果とを取得すると、これらの情報を交流指標テーブル１９へ出力する。
【００４４】
ここで、交流指標テーブル１９が記憶する情報の例を図７に示す。図７に示すように、交流指標テーブル１９は、「ユーザＩＤ」欄と、「対ユーザＩＤ」欄と、「場所に基づく指標値」欄と、「アプリに基づく指標値」欄と、「交流指標」欄とを含むテーブルである。出力部２０は、「ユーザＩＤ」、「対ユーザＩＤ」、「場所に基づく指標値」、「アプリに基づく指標値」、及び「交流指標」のそれぞれの欄に、基準ユーザのユーザＩＤ、候補ユーザのユーザＩＤ、推定部１５によって算出された場所に基づく指標値、推定部１５によって推定されたアプリに基づく指標値、及び推定部１５によって推定された結果（交流有の場合、「１」、交流無しの場合「０」）のそれぞれを出力する。
【００４５】
図８に本実施形態に係るサーバ１０のハードウェア構成を示す。図８に示すようにサーバ１０は、１つ以上のＣＰＵ（Central Processing Unit）１０１、主記憶装置であるＲＡＭ（RandomAccess Memory）１０２及びＲＯＭ（Read Only Memory）１０３、通信を行うための通信モジュール１０４、並びにハードディスク等の補助記憶装置１０５等のハードウェアを備えるコンピュータを含むものとして構成される。これらの構成要素がプログラム等により動作することにより、上述したサーバ１０の機能が発揮される。以上が、本実施形態に係るサーバ１０の構成である。
【００４６】
引き続いて、図９のフローチャートを用いて、本実施形態に係るサーバ１０で実行される処理を説明する。まず、位置取得部１１によって、位置ログが取得される（ステップＳ１）。この位置ログは、位置取得部１１から生位置情報テーブル１２に出力される。続いて、アプリ使用情報取得部１３によって、アプリログが取得される（ステップＳ２）。このアプリログは、アプリ使用情報取得部１３から生アプリ利用テーブル１４へ出力される。交流を推定するタイミングになると、推定部１５によって、生位置情報テーブル１２に記憶されている情報を用いて位置ログ編集処理が行われる（ステップＳ３）。編集された位置ログは、推定部１５から加工位置情報テーブル１６へ出力される。位置ログ編集処理が行われた後に、推定部１５によって、加工位置情報テーブル１６に記憶されている情報を用いて混雑度算出処理が行われる（ステップＳ４）。算出された混雑度は、推定部１５から混雑度テーブル１７へ出力される。
【００４７】
混雑度算出処理が行われた後に、推定部１５によって、生アプリ利用テーブル１４、加工位置情報テーブル１６、及び混雑度テーブル１７に記憶されている情報を用いてアプリログ編集処理が行われる（ステップＳ５）。編集された情報は、推定部１５から加工アプリ利用テーブル１８へ出力される。
【００４８】
続いて、推定部１５によって、加工位置情報テーブル１６に記憶されている情報を用いて場所に基づく指標値が算出される（ステップＳ６）。また、推定部１５によって、加工アプリ利用テーブル１８に記憶されている情報を用いてアプリに基づく指標値が算出される（ステップＳ７）。
【００４９】
続いて、推定部１５によって、場所に基づく指標値とアプリに基づく指標値とに基づいてユーザ間の交流有無が推定される（ステップＳ８）。この推定結果を含む情報が推定部１５から出力部２０へ送出される。続いて、上記推定結果を含む情報は、出力部２０から交流指標テーブル１９へ出力される（ステップＳ９）。
【００５０】
上述したように、本実施形態では、ユーザ毎の位置ログと、ユーザ毎のアプリログとに基づいて、ユーザ間における交流の有無が推定される。従って、例えば、共通するアプリが使用されたことが考慮されて交流の有無が推定される。これにより、ユーザの過去の行動に基づいて、ユーザ間の交流の有無をより正確に推定することができる。
【００５１】
例えば、位置情報を用いて頻繁に同じ場所にいるユーザ同士を交流ありと特定してしまうと、大学などいつも同じ場所に交流のない人同士が集まる場合も、交流があると判断してしまう。本実施形態では、アプリに基づく指標値を用いることで、交流があるユーザ間ならではの行動（共通のアプリ操作）を示す情報を用いて判断しているので、より正確にユーザ間の交流の有無をより正確に推定することができる。
【００５２】
また、本実施形態のように、基準ユーザの位置と候補ユーザの位置とが対応している期間と、基準ユーザが使用していたアプリと候補ユーザが使用していたアプリとが対応している期間とが共通している期間に基づいて、ユーザ間の交流の有無が推定されてもよい。この場合、互いのユーザの位置と使用したアプリとが共通している期間に基づいて交流の有無を推定するので、一緒にいて、同じアプリを使用しているような交流がある可能性が高い状態を特定することにより、ユーザ間の交流を正確に推定することができる。
【００５３】
また、本実施形態のように、位置毎におけるユーザ数に基づいた混雑度を時刻毎に取得して、当該混雑度に基づいてユーザ間における交流の有無を推定するようにしてもよい。この場合、混雑度を用いて推定するので、例えば、互いに交流が無いユーザが混雑している箇所に偶然近くにいる場合に、偶然居合わせたユーザが同じアプリ（例えば、駅で乗り換えのアプリや空港で飛行機のアプリ等）を使用していた結果、当該ユーザ間に交流があると誤って推定してしまう可能性を低減させることができる。
【００５４】
なお、本実施形態では、場所に基づく指標値とアプリに基づく指標値とに基づいてユーザ間の交流有無を推定する場合について述べたが、上述のアプリに基づく指標値のみに基づいてユーザ間の交流有無を推定するようにしてもよい。
【００５５】
また、本実施形態では、アプリに基づく指標値として混雑度を用いる場合について述べたが、共通するアプリを使用していた期間を示す値をアプリに基づく指標値とするようにしてもよい。
【００５６】
また、本実施形態では、互いのユーザが近くの位置にいる期間における、同一アプリを利用している期間を特定する場合について述べたが、互いのユーザが近くの位置にいる期間であるかに関係なく、同一アプリを利用している期間を特定するようにしてもよい。
【００５７】
また、本実施形態では、アプリに基づく指標値に混雑度を適用する場合について述べたが、場所に基づく指標値に混雑度を用いるようにしてもよい。
【００５８】
上述の実施形態では、メッシュ内に位置していたユーザ数と、全ユーザ数とから混雑度を算出する場合について述べたが、一般的に開示されている混雑度データを用いるようにしてもよい。
【００５９】
上述の実施形態では、出力部２０が、推定結果を交流指標テーブル１９へ出力する場合について述べたが、サーバ１０においてプロファイル情報（各ユーザの属性を示す情報）を記憶している場合、基準ユーザのプロファイル情報に交流があると推定されたユーザのユーザＩＤを出力するようにしてもよい。
【００６０】
上述の実施形態では、ＧＰＳ受信機により測位結果を得る場合について述べたが、ＷｉＦｉやＢＬＥ（Bluetooth（登録商標） Low Energy）による公知の位置測位方法や、これらの組み合わせにより測位結果を得るようにしてもよい。
【符号の説明】
【００６１】
１０…サーバ、１１…位置取得部、１２…生位置情報テーブル、１３…アプリ使用情報取得部、１４…生アプリ利用テーブル、１５…推定部、１６…加工位置情報テーブル、１７…混雑度テーブル、１８…加工アプリ利用テーブル、１９…交流指標テーブル、２０…出力部、３０…ユーザ端末。
【図１】
2017194907.tif 000003
【図２】
2017194907.tif 000004
【図３】
2017194907.tif 000005
【図４】
2017194907.tif 000006
【図５】
2017194907.tif 000007
【図６】
2017194907.tif 000008
【図７】
2017194907.tif 000009
【図８】
2017194907.tif 000010
【図９】
2017194907.tif 000011