JP6678392B2 - ユーザ状態予測システム - Google Patents

Description

本発明は、ユーザ状態予測システムに関する。

従来、ユーザがもつ端末装置からユーザの生体情報や位置情報などのセンシングデータを収集し、収集した位置における現在の盛り上がり度を表示する技術が例えば特開２０１４−１３４９２２号公報（特許文献１）に開示されている。

特開２０１４−１３４９２２号公報

特許文献１の従来の技術では、イベント等のその時その時の盛り上がり度を表示しているだけであり、将来の予測や、お勧めか否かといったことは特に考えられていない。この点で改良の余地がある。

したがって、本発明が解決しようとする課題としては、例えば将来の予測やお勧めかどうかといった精度の高い情報をユーザに提示できる技術を提供することが一例として挙げられる。

請求項１に記載の発明は、ユーザの生体情報と、当該ユーザの位置情報を取得する第１取得部と、複数のユーザから取得した前記生体情報と前記位置情報に基づき、位置毎の前記複数のユーザの興奮度を含むユーザ状態を示す第１状態情報を生成する第１生成部と、過去の第１状態情報を、日時情報とともに履歴情報として取得する第２取得部と、前記履歴情報に基づき、任意の位置及び任意の期間または時刻において予測されるユーザ状態を示す予測状態情報を含む第２状態情報を生成する第２生成部と、前記予測状態情報を前記任意の位置及び前記任意の期間または時刻とともに表示する表示部と、を備えることを特徴とするユーザ状態予測システムである。

請求項５に記載の発明は、複数のユーザから取得した生体情報と位置情報に基づき、位置毎の前記複数のユーザの興奮度を含むユーザ状態を示す第１状態情報を生成する第１生成部を有する情報処理装置と通信を行うユーザ状態予測装置であって、過去の第１状態情報を、日時情報とともに履歴情報として取得する第２取得部と、前記履歴情報に基づき、任意の位置及び任意の期間または時刻において予測されるユーザ状態を示す予測状態情報を含む第２状態情報を生成する第２生成部と、前記予測状態情報を前記任意の位置及び前記任意の期間または時刻とともに表示する表示部と、を備えることを特徴とするユーザ状態予測装置である。

請求項６に記載の発明は、ユーザの生体情報と位置情報を送信する端末装置から、当該生体情報と当該位置情報を受信する受信部と、複数の端末から受信した前記生体情報と前記位置情報に基づき、位置毎の前記複数のユーザの興奮度を含むユーザ状態を示す第１状態情報を生成する第１生成部と、過去の第１状態情報を、日時情報とともに履歴情報として取得する第２取得部と、前記履歴情報に基づき、任意の位置及び任意の期間または時刻において予測されるユーザ状態を示す予測状態情報を含む第２状態情報を生成する第２生成部と、前記予測状態情報を前記任意の位置及び前記任意の期間または時刻とともに表示する情報として出力する出力部と、を備えることを特徴とする情報処理装置である。

請求項７に記載の発明は、ユーザ状態予測システムにおいて実行されるユーザ状態予測方法であって、ユーザの生体情報と、当該ユーザの位置情報を取得する工程と、複数のユーザから取得した前記生体情報と前記位置情報に基づき、位置毎の前記複数のユーザの興奮度を含むユーザ状態を示す第１状態情報を生成する工程と、過去の第１状態情報を、日時情報とともに履歴情報として取得する工程と、前記履歴情報に基づき、任意の位置及び任意の期間または時刻において予測されるユーザ状態を示す予測状態情報を含む第２状態情報を生成する工程と、前記予測状態情報を前記任意の位置及び前記任意の期間または時刻とともに表示する工程と、を含むことを特徴とするユーザ状態予測方法である。

請求項９に記載の発明は、請求項８に記載のユーザ状態予測方法を、コンピュータに実行させることを特徴とするプログラムである。

請求項１０に記載の発明は、請求項９に記載のプログラムを格納したことを特徴とするコンピュータ読み取り可能な記録媒体である。

本発明の実施例に係るユーザ状態予測システムの全体概略構成図である。 本発明の実施例におけるサーバの要部構成を示す機能ブロック図である。 本発明の実施例の情報端末機の要部構成を示す機能ブロック図である。 本発明の実施例における管理テーブルとその具体的な保存例を示すものである。 本発明の実施例１における遊園地内の地点Ａについて管理テーブルに保持した一例を示す図である。 本発明の実施例１の処理に係るフローチャートである。 本発明の実施例１における遊園地内の地点Ｂについて管理テーブルに保持した一例を示す図である。 本発明の実施例２の開始時刻を抽出する第１の処理に係るフローチャートである。 本発明の実施例２の終了時刻を抽出する第２の処理に係るフローチャートである。 本発明の実施例２のユーザ状態平均値を求める第３の処理に係るフローチャートである。 本発明の実施例２における平均値を保存する平均値管理テーブルの構造を示す図である。 本発明の実施例２における平均値管理テーブルの各データの保持イメージを示す図である。 本発明の実施例３における管理テーブルに蓄積したデータの過去の状況との比較例を示す図である。 本発明の実施例３の優先比較対象を用いた判断処理に係るフローチャートである。 本発明の実施例４に係る盛り上がり状態の表示例を示す図である。 本発明の実施例４に係る盛り上がり状態の表示例の操作とその結果の一例を示す図である。

以下、本発明の一実施形態を説明する。本発明の一実施形態に係るユーザ状態予測システムは、ユーザの生体情報と、当該ユーザの位置情報を取得する第１取得部と、複数のユーザから取得した前記生体情報と前記位置情報に基づき、位置毎のユーザ状態を示す第１状態情報を生成する第１生成部と、過去の第１状態情報を、日時情報とともに履歴情報として取得する第２取得部と、前記履歴情報に基づき、任意の位置及び任意の期間または時刻において予測されるユーザ状態を示す予測状態情報、または、所定期間内における前記第１状態情報の平均を示す平均状態情報のうち少なくとも一つを含む第２状態情報を生成する第２生成部と、前記第２状態情報を出力表示する出力部と、を備えている。

また、前記ユーザ状態予測システムは表示部を更に備え、前記第１取得部は地図情報を更に取得し、前記出力部は、前記第２状態情報を前記地図情報とともに表示する表示情報として、前記表示部に出力する、ユーザ状態予測システムである。

また、前記ユーザ状態予測装置は、前記第２取得部は、前記履歴情報として、天候情報、前記任意の位置におけるイベント情報、及び、前記任意の位置における施設の施設情報のうち少なくとも１つをさらに取得する、ユーザ状態予測システムである。

また、前記第２状態情報は前記予測状態情報を含み、前記表示部は、前記予測状態情報を前記任意の位置及び前記任意の期間または時刻とともに表示するユーザ状態予測システムである。

また、前記第１状態情報は、前記複数のユーザの平均的な興奮状態を示す興奮状態情報、及び、当該複数のユーザの人数に基づく密集度情報が含まれる、ユーザ状態予測システムである。

また、本発明の一実施形態に係るユーザ状態予測装置は、複数のユーザから取得した生体情報と位置情報に基づき、位置毎のユーザ状態を示す第１状態情報を生成する第１生成部を有する情報処理装置と通信を行うユーザ状態予測装置であって、過去の第１状態情報を、日時情報とともに履歴情報として取得する第２取得部と、前記履歴情報に基づき、任意の位置及び任意の期間または時刻において予測されるユーザ状態を示す予測状態情報、または、所定期間内における前記第１状態情報の平均を示す平均状態情報のうち少なくとも一つを含む第２状態情報を生成する第２生成部と、前記第２状態情報を出力表示する出力部と、を備えることを特徴とするユーザ状態予測装置である。

また、本発明の一実施形態に係る情報処理装置は、ユーザの生体情報と位置情報を送信する端末装置から、当該生体情報と当該位置情報を受信する受信部と、複数の端末から受信した前記生体情報と前記位置情報に基づき、位置毎のユーザ状態を示す第１状態情報を生成する第１生成部と、過去の第１状態情報を、日時情報とともに履歴情報として取得する第２取得部と、前記履歴情報に基づき、任意の位置及び任意の期間または時刻において予測されるユーザ状態を示す予測状態情報、または、所定期間内における前記第１状態情報の平均を示す平均状態情報のうち少なくとも一つを含む第２状態情報を生成する第２生成部と、を備える情報処理装置である。

また、本発明の一実施形態に係るユーザ状態予測方法は、ユーザの生体情報と、当該ユーザの位置情報を取得し、複数のユーザから取得した前記生体情報と前記位置情報に基づき、位置毎のユーザ状態を示す第１状態情報を生成し、過去の第１状態情報を、日時情報とともに履歴情報として取得し、前記履歴情報に基づき、任意の位置及び任意の期間または時刻において予測されるユーザ状態を示す予測状態情報、または、所定期間内における前記第１状態情報の平均を示す平均状態情報のうち少なくとも一つを含む第２状態情報を生成し、前記第２状態情報を出力表示する、ユーザ状態予測方法である。

また、上述したユーザ状態予測方法をコンピュータにより実行させるプログラムとしてもよい。

また、上述したプログラムをコンピュータ読み取り可能な記録媒体に格納してもよい。

次に本発明の実施例を、図１乃至図１６５に基づいて説明する。

図１は実施例に係るユーザ状態予測システムの全体概略構成図、図２は実施例におけるサーバ１００の要部構成を示す機能ブロック図、図３は実施例の「ユーザ状態予測装置」の一例としての携帯型の情報端末機１０の要部構成を示す機能ブロック図である。なお、図２及び図３に示す各機能ブロックは、図示しないコンピュータの中央処理装置（ＣＰＵ）が制御プログラム（ソフトウエア）を実行することで得られる機能実現手段、及びメモリ装置等のハードウエア資源である。

図１において、送信端末群のセンシング端末Ａは、ユーザのセンシング情報や位置情報などをサーバ１００に送信するための端末である。例えばタッチパネル型形態端末（一例としてスマートフォン）、ノート型パソコン、腕時計型携帯端末、携帯型メディアプレーヤ、携帯型ゲーム機等である。これらのセンシング端末Ａは、それぞれ以下のような機能を有している。ＧＰＳ機能により自機の位置情報を取得可能である。また、これらのセンシング端末Ａは、例えばユーザの身体の一部に装着しうるもので、ユーザの脈拍や、脳波等をセンシングして、このセンシングした脈拍や、脳波等を所定のデータに変換し、この変換したデータを生体情報とする。そして、位置情報と生体情報をネットワークを介してサーバ１００に送信する。

受信端末群の情報端末機１０は、サーバ１００から各種の情報を取得するための端末である。例えばタッチパネル型形態端末（一例としてスマートフォン）、ノート型パソコン、カーナビゲーション等であり、サーバ１００に接続することが可能な端末装置である。

図２に示すように、サーバ１００は、制御部１０１と、通信部１０２と、ユーザ状態検出部１０３と、記憶部１０４等から構成されており、制御部１０１が記憶部１０４をワーキングエリアとして全体の制御を行う。「受信部」としての通信部１０２はセンシング端末Ａからの生体情報を受信する。また、通信部１０１により情報端末機１０との通信を行う。また、ユーザ状態検出部１０３は、複数のユーザの各センシング端末Ａから送信されてくる位置情報と生体情報（各種センシングデータ）を統合する機能を有している。この機能としては、所定の領域（場所）における人の密集度（センシング端末Ａの密集度）を算出する。また、所定の領域にいる複数の人の状態（興奮状態や沈静状態等）を指標値（興奮度、沈静度等）として検出する機能である。このサーバ１００のユーザ状態検出部１０３は「第１生成部」の一例であり、この興奮度、沈静度等の指標値を「ユーザ状態」といい、「第１状態情報」の一例である。

図３に示すように、情報端末機１０は、ユーザ状態受信部１と、ＧＰＳ受信部２と、保存部３と、ストレージ４と、ユーザ操作受信部５と、ユーザ操作処理部６と、ユーザ状態解析部７と、表示部８と、通知部９等から構成されている。ユーザ状態受信部１は、主にサーバから、センシング端末Ａの位置情報、密集度、ユーザ状態の情報を取得する。保存部３は、この受信した位置情報、密集度、ユーザ状態の情報を、ＧＰＳ受信部２で取得した時間と関連付けてストレージ４に蓄積・保存する。また、タッチパネル等によるユーザ操作をユーザ操作受信部５で受け付け、ユーザ操作処理部６でユーザ操作に応じた処理を行う。さらに、ユーザ状態解析部７は、ストレージ４に蓄積・保持してある、位置情報、密集度、ユーザ状態の情報を解析する。この解析結果は、表示部８によりディスプレイ等に表示したり、通知部９によりスピーカ等で通知する。このように、情報端末機１０は、ＧＰＳ機能により自機の位置情報、現在時刻等を取得可能である。また、サーバ１００から受信したセンシング端末Ａについての前記密集度、前記ユーザ状態の各情報を解析し、当該情報端末機１０のユーザに対して、ユーザ状態の解析結果等の各種の情報を表示する。このように、情報端末機１０は、時間と結びつけて、ユーザ状態、密集度を長期にわたり保持することにより、一定期間保持し過去のユーザ状態等から、ユーザに対して新たな情報の提供を行うものである。

また、情報端末機１０が、ユーザ状態受信部１は、例えば1分に一回のように定期的に自動でサーバ１００にアクセスし、いくつかの地点のユーザ状態、密集度の情報の取得を実施する。そして、これらの取得した情報をストレージ４に蓄積・記憶する。なお、取得する時間帯、頻度はユーザが選択できるようにしても良い。ここで言ういくつかの地点とは、主な施設（遊園地等）に加えユーザが独自に登録した地点が含まれる。そして、ここで受信した情報は、ユーザ状態と、地点と、情報を取得した時間とを、例えば図４（Ａ）に示す管理テーブルにして記憶する。このようにユーザ状態と、地点と、情報を取得した時間とは、情報端末機１０のストレージ４に一定期間保持される。例えば１月分の情報が保存される。図４（Ｂ）は管理テーブルにおける具体的な保存例を示すものである。

なお、図４（Ｂ）のように、以下の実施例では、ユーザ状態を、「通常」、「興奮」、「沈静」等で表現し、密集度を「低」、「中」、「高」で表現するが、さらに細かい情報が取得出来る場合などは、その情報の精度に合わせた構造で管理を行う。そして、この保持した情報はいつでも参照が可能であり、以下の各実施例で説明するような用途に用いられる。

（実施例１）実施例１は、過去のデータの活用として、盛り上がり地点の予測を行うものである。図５は、遊園地内の地点Ａ（例えばショ―スペース）についてのユーザ状態、密集度、時刻の情報を、管理テーブルに保持した一例を示す図である。

図５に示すように、2014/11/1 (土曜日)を先頭に一週間毎に時刻で15:00〜16:30の間に毎週盛り上がっていることが分かる。また前日の同時間帯は盛り上がっていないことを考えると、これは土曜日限定で何か事象が発生している可能性が高い、と予測できる。これにより2014/11/22（３週間後）のこの時間帯にも同様になにかイベントが行われる可能性が高いと考えられる。そこで、この情報をユーザの情報端末機１０に「要チェックポイント」であるとして提示する。また 16:30以降は人の数、盛り上がりも下がっていることが見て取れ、これによりイベントの終了時間の予測も可能となる。これにより、例えばこの時間の間は食堂がすいている可能性が高いなどの情報も提供可能である。

図６は実施例１の処理に係るフローチャートである。なお、各実施例に係るフローチャートは、情報端末機１０の制御部１のコンピュータ（そのＣＰＵ）が実行する制御プログラムの要部フローチャートである。この処理では、盛り上がりの状態を示す数値として「連続盛り上がりカウント」という指標（レジスタ値）を用いる。

まず、ステップＳ１で、端末機１０の操作入力を受け付けてユーザが目的とする予測日と予測場所の選択処理及び入力処理を行い、ステップＳ２で、予測日及び予測場所に対応するユーザ状態の情報を取得する。次に、ステップＳ３でユーザ状態が「興奮」の状態であるかを判定し、「興奮」でなければステップＳ１３に進み、「興奮」であればステップＳ４で、現在と同時刻、同曜日の過去４週間のユーザ状態の情報を取得する。次に、ステップＳ５で、上記取得したユーザ状態の情報が全て同じユーザ状態を示しているかを判定し、全て同じユーザ状態でなければステップＳ１３に進み、全て同じユーザ状態であれば、ステップＳ６で、現在と同時刻の過去３日間のユーザ状態の情報を取得する。

次に、ステップＳ７で、上記取得したユーザ状態の情報が全て同じユーザ状態を示しているかを判定し、全て同じユーザ状態であればステップＳ１３に進み、全て同じユーザ状態でなければ、ステップＳ８で、連続盛り上がりカウンタのカウントが“０”であるかを判定する。カウントが“０”でなければステップＳ１０に進み、カウントが“０”であれば、ステップＳ９で、取得時刻を盛り上がり開始時刻として保持し、ステップＳ１０で連続盛り上がりカウンタのカウント値をプラス１する。次に、ステップＳ１１で取得時刻を１分進め、ステップＳ１２で予測日が終わったかを判定する。予測日が終わっていなければステップＳ２に戻り、予測日が終わっていれば処理を終了する。ステップＳ１３では、連続盛り上がりカウンタのカウント値が“１５”を超えているかを判定し、“１５”を超えていなければステップＳ１５に進み、“１５”を超えていればステップＳ１４で、ユーザ端末に開始時刻と取得時刻（終了時刻）を「要チェックポイント」として表示し、ステップＳ１５に進む。ステップＳ１５では、連続盛り上がりカウンタを“０”にリセットしてステップＳ１１に進む。このように、ユーザ状態が「興奮」で同時刻で同曜日であると、連続盛り上がりカウンタを増加させることで、「要チェックポイント」となる区間を検出し、それを提示している。これらのユーザに通知する情報が「第２状態情報」の一例であり、ユーザ状態解析部７が「第２生成部」の一例である。

図７は、遊園地内の地点Ｂについてのユーザ状態、密集度、時刻の情報を、管理テーブルに保持した一例を示す図である。

図７に示すように、現在時刻が2014/11/15 の10:02 として、取得された情報で地点Ｂが盛り上がっている。この時、過去数日と、過去数週と比べて同様の事態は起こっていない。これにより、地点Ｂで本日限定のレアイベントが起きている可能性が高いと考えられる。このようなイベントについては即座にユーザの情報端末機１０で通知をし、そこまでの最短ルートを地図に表示する。以上の例では遊園地を事例としてあげたが、大型ショッピングモール等でも活用可能である。その場合はショップ（店舗）のタイムセールなどの検知も可能である。

（実施例２）実施例２では、同一施設の過去の情報と比較し、ここ一月の盛り上がったイベントを抽出し、それをお薦めとして各種機能に反映させる。また、特定の施設において過去の盛り上がり状況の平均値を算出する。この平均値はデータが残っている直近の一月分でもよいし、もしくは平均値だけ保持しておき一年分を算出しても良い。

一日の平均値の算出方法は以下のとおりとする。まず、算出区間は以下のように定義する。算出開始時間は、密集度が増加していき、ある程度の期間（例えば１５分間）安定したタイミングとする。また、算出終了時間は、密集度が減少するのを検知し、ある程度の期間（例えば１５分間）で順調に減少を続けていったとして、その減少が開始したタイミングとする。なお、この期間に再度増加した場合は終了とは判断しない。

図８は実施例２の開始時刻を抽出する第１の処理に係るフローチャートである。なお、この第１の処理では、開始時刻を決定するために密集度の安定状態を示す数値として「連続安定カウント」という指標（レジスタ値）を用いる。

まず、ステップＳ２１で、端末機１０の操作入力を受け付けてユーザが目的とする抽出開始時間と予測場所の選択処理及び入力処理を行い、ステップＳ２２で、密集度を取得する。次に、ステップＳ２３で密集度が増えたかを判定し、増えていればステップＳ２７で密集度が増加した事実を記憶し、ステップＳ２８で連続安定カウントを“０”にリセットしてステップＳ２９に進む。ステップＳ２３で密集度が増えていなければ、ステップＳ２４で密集度は変化なしかを判定し、密集度に変化があれば、ステップＳ２８で連続安定カウントを“０”にリセットしてステップＳ２９に進む。ステップＳ２４で密集度に変化がなければ、ステップＳ２５で過去に密集度が増加したかを判定し、増加していなければ、ステップＳ２８で連続安定カウントを“０”にリセットしてステップＳ２９に進む。密集度が増加していれば、ステップＳ２６で連続安定カウンタのカウント値をプラス１してステップＳ２９に進む。

ステップＳ２９では、連続安定カウンタのカウント値が“１５”を超えているかを判定し、“１５”を超えていなければステップＳ１５に進み、“１５”を超えていればステップＳ３０で取得時刻を１分進め、ステップＳ２２に戻る。カウント値が“１５”を超えていれば、ステップＳ３１で、取得時刻を密集度の高い期間の開始時刻として保持し、処理を終了する。

図９は実施例２の終了時刻を抽出する第２の処理に係るフローチャートである。なお、この第２の処理では、終了時刻を決定するために密集度の減少状態を示す数値として「連続減少カウント」という指標（レジスタ値）を用いる。

まず、ステップＳ４１で、端末機１０の操作入力を受け付けてユーザが目的とする抽出開始時間と予測場所の選択処理及び入力処理を行い、ステップＳ４２で、密集度を取得する。次に、ステップＳ４３で密集度が増えたかを判定し、増えていればステップＳ４６で連続減少カウントを“０”にリセットしてステップＳ４９に進む。ステップＳ４３で密集度が増えていなければ、ステップＳ４４で密集度が減ったかを判定し、密集度が減ったら、ステップＳ４７で取得時刻を密集度の減少開始時刻として保持し、ステップＳ４８で連続減少カウンタのカウント値をプラス１してステップＳ４９に進む。ステップＳ４４で密集度が減っていなければ、ステップＳ４５で過去に密集度が減少したかを判定し、密集度が過去に減少していなければステップＳ４９に進む。密集度が過去に減少していれば、ステップＳ４８で連続減少カウントのカウント値をプラス１してステップＳ４９に進む。

ステップＳ４９では、連続減少カウンタのカウント値が“１５”を超えているかを判定し、“１５”を超えていればステップＳ５１に進み、“１５”を超えていなければステップＳ５０で取得時刻を１分進め、ステップＳ４２に戻る。カウント値が“１５”を超えていれば、ステップＳ５１で、減少開始時刻を終了時刻として保持し、処理を終了する。

以上にようにして求めた算出開始時間から算出終了時間の間をイベントが行われている時間と判断し、この区間のユーザ状態（興奮、沈静、通常）をサンプリングする。この時、例えば３０分のように、イベント最小時間を設け、それを下回るものは検出対象から除外する。また、ユーザ状態は「興奮」が“＋２０”、「通常」が“＋１０”、「沈静」が“０”というようにポイントを設けておき、サンプリング中は順次足されていき、サンプリング終了時に「総ユーザ状態ポイント」として、値が確定する。

また、サンプリング期間のサンプリング回数は以下の計算式で求められる。
サンプリング回数＝（算出終了時間−算出開始時間）／ 保持間隔
これら総ユーザ状態ポイントを、サンプリング回数で割ることでユーザ状態平均値を求めることができる。
ユーザ状態平均値＝総ユーザ状態ポイント／サンプリング回数

図１０は実施例２のユーザ状態平均値を求める第３の処理に係るフローチャートである。まず、ステップＳ６１で算出した開始時間と終了時間を抽出し、ステップＳ６２で、「終了時間−開始時間」が３０分より大であるかを判定する。３０分より大でなければ処理を終了し、３０分より大であれば、ステップＳ６３でユーザ状態の情報を取得し、ステップＳ６４でユーザ状態に応じて総ユーザ状態ポイントを加算する。次に、ステップＳ６５で、取得時間を１分進めるとともに、サンプリング回数をプラス１してステップＳ６６に進む。ステップＳ６６では、取得時刻が終了時刻をオーバーするかを判定し、オーバーしなければステップＳ６３に戻る。終了時刻をオーバーするのであれば、ステップＳ６７で、「総ユーザ状態ポイント／サンプリング」により平均値を取得し、処理を終了する。

なお、同日に複数のイベントが行われて、対象が複数ある場合もあるが、それらは別々に保持しておく。図１１は平均値を保存する平均値管理テーブルの構造を示す図である。図１２は平均値管理テーブルの各データの保持イメージを示す図である。

以上の計算にて、密集度自体を計算に入れていない。すなわち、施設等のキャパシティに対してどれだけ人が入ったのかという密集度自体は考慮していないが、これは、イベントによっては、どれだけ人が入るのかがバラバラであることと、人数の過多があるにせよその場にいた人の興奮度が高い等で良イベントかどうかが分かるためである。ただし、イベントによっては興奮度は低い方が良いという自体も考えられる。例えばクラシックのコンサート等である。このためには、ユーザに興奮抽出、平静抽出というように選択させる方法も考えられる。また、もし人数の過多を考慮したい場合は、１００人以上〜１０００人未満、１０００人以上〜５０００人未満というようにカテゴリ分けを行い別々の情報として取り扱うのも良い。

ユーザ状態ポイント平均値は、一月の平均値として算出してもよい。また、一月より前の平均値を求めておいて、もっと長い期間の平均値を求めても良い。

平均値の利用方法としては、以下のような例がある。以下の例は、盛り上がりの事例であるが、ユーザによっては平静の場合もある。まず、一月の最大盛り上がりイベントの抽出を行う。これは、ユーザ状態ポイント平均値を比較することで、一月で最大の盛り上がりを見せたイベントの日にちと時間帯が分かる。これに場所を加えた情報をキーワードにしてブラウザなりでネット検索を行う。そして、その検索結果をユーザに表示してもいいし、検索結果から、共通のキーワード（アーチスト名）が分かるようだったらその情報を用いて、例えば情報端末機１０のストレージ４に入っている楽曲の再生順序に反映したり、また、その情報に含まれるアーチストだけで再生リストを作ったりなどを行うことができる。

また、一月の盛り上がり平均値より今のトレンド情報の抽出を行うこともできる。平均値を超えるイベントを優良コンテンツとして扱い、超える回数が多いコンテンツを今のトレンドとして情報を提供する。これは、例えば音楽に限らず野球や、海外アーチスト等、ジャンルに問わないで行うことも可能である。また、平均値の代わりに、ユーザ状態ポイントがある閾値を超えるようなコンテンツを優良と判断する方法でも良い。

（実施例３）実施例３は過去と現在の密集度、ユーザ状態をそれぞれ比較することによりお薦めスポットを提示するものである。以下に例として居酒屋の例を挙げる。

ユーザは候補地点の店を情報端末機１０にいくつか登録しておき、その登録地点のデータを情報端末機１０は定期的に取得する。その情報を現時点の状態と比較し、過去と比べて盛り上がっているかの提示を行う。（これは実施例１とほぼ同じである。）これに加えて、ユーザが過去にその店を訪れた時の情報を優先比較対象として登録することができ、この日時のこの時間帯という登録内容で登録する。

図１３は管理テーブルに蓄積したデータの過去の状況との比較例を示す図である。これはユーザが過去に訪れた店舗等について、その時の状況に比べて今どうかという情報の提示に利用される。例えば一週間前に訪れた店の雰囲気が良かったとする。今回もその店にしようと思ったときに前回の訪れた時に比べて今はどのような状況なのかを知りたい場合がある。図１３に示すように、2014/11/8 18:05〜20:05 をユーザ登録区間とする。これに対して比較が行われ、その結果、2014/11/15が以前訪れた時とほぼ同じ状況と分かる。このため複数候補があった場合に、ユーザが登録したと同じ状況の店舗を優先的に案内するなどの機能をとることができる。逆に2014/11/14の例だと、以前訪れた時より人が少ない（密集度が「低」）にもかかわらず、盛り上がりは高い（ユーザ状態が「興奮」）。これは騒いでいる客がいて、客層が悪いかもしれないなどの判断にも利用可能である。

また、上記例は同時間帯であるが、違う時間帯との比較も可能である。例えば、優先比較時間(18:05 〜 20:05) に対して現在が 16:00だったとする。この場合は現在時刻より例えば15分さかのぼった時点から現在までの状態と、優先比較時間の開始から15分間の状態を比較し、類似点が多い店舗を優先するなども可能である。

図１４は実施例３の優先比較対象を用いた判断処理に係るフローチャートである。まず、ステップＳ７１で管理テーブルから店舗を選択し、ステップＳ７２で、優先比較対象（図１３の一点鎖線）を抽出する。次に、ステップＳ７３で、現在の時刻が優先比較対象の範囲内であるかを判定し、範囲内であれば、ステップＳ７４で、優先比較対象の開始時間から現在時刻までのユーザ状態と、密集度を、それぞれ比較し、ステップＳ７６に進む。現在の時刻が優先比較対象の範囲内でなければ、ステップＳ７５で、「１５分前から現在時刻」の範囲と、「優先比較対象の開始時間から１５分」の範囲との両範囲で、ユーザ状態と、密集度を、それぞれ比較し、ステップＳ７６に進む。ステップＳ７６では比較の結果から合致度を算出し、ステップＳ７７で、全ての店舗を処理したかを判定し、処理していなければステップＳ７１に戻り、処理していれば、ステップＳ７８で、最も合致度が高かった店舗を優先的にユーザに提示し、処理を終了する。

（実施例４）実施例４は主に表示例の実施例である。図１５は実施例４に係る盛り上がり状態の表示例を示す図である。なお、ユーザは、ストレージ４に蓄積された情報を何時でも参照することが可能である。この例では、図１５に示すように、時刻を横軸に、盛り上がりの高さを縦軸にして状態をグラフ表示している。図１５に示す例のように、この球場Ａでは、19:00 近辺にピークを迎えていることが直感的に分かる。また、図１６に示すように、ユーザがここで何が起きたのか知りたいと思った場合は上記画面をタッチすることで、簡単にブラウザ検索ができる機能を有している。このように、タッチするだけで簡単にブラウザ検索ができるので、日本語入力等の煩わしさを無くすことが可能である。なお、検索結果を表示しても良い。

以上の実施例ではサーバ１００から取得した密集度、ユーザ状態、位置情報を、情報端末機１０のストレージ４に蓄積するようにしているが、外部の別サーバに保持することも可能である。この時に送る情報としてはユーザが個別の嗜好により選択した領域において保持した情報を別サーバに送信することにより他のユーザとの情報のシェアが図れる。例えば、急きょあるエリアの情報が欲しくなった場合に、ユーザ単体（一人のユーザ）だとそのタイミングからサーバ１００から情報の取得を開始することになるが、別サーバに接続できれば他のユーザにより蓄積されているデータがある可能性がある。したがって、例えば一月後でなくても、即座に実施例同様の処理を行うことができる。このように、別サーバに情報を保持することにより、他人と情報をシェアすることが可能となり、自分で情報を取得しないでも多数の地点の情報を過去にさかのぼって取得し、利用することができる。

なお、以上の各実施例において、密集度、ユーザ状態、位置情報の他に、「晴天」、「曇り」、「雨」、「雪」等の天候の情報により、その日時における天候に応じて、密集度、ユーザ状態ポイントに重みを付けたりしてもよい。さらに、イベントが行われる施設の各種情報（例えばスペースの広さや、設置場所等）を示すイベント施設情報により、密集度、ユーザ状態ポイントに重みを付けたりしてもよい。

なお、実施例では、スマートフォン等の情報端末機１０にて各処理を行うようにしているが、サーバ１００にて密集度、ユーザ状態の情報、位置情報を蓄積し、このサーバ１００に実施例同様の機能を持たせてもよい。この場合、サーバ１００が「情報処理装置」の一例であり、制御部１０１の処理で実現する機能が、それぞれ、「受信部」、「第１生成部」、「第１取得部」、「第２取得部」、「第２生成部」に相当する。

以上、本発明の実施の形態について図面を参照して詳述してきたが、具体的な構成はこれらの実施の形態に限られるものではなく、本発明の要旨を逸脱しない範囲の設計の変更等があっても本発明に含まれる。上述の各図で示した実施例は、その目的及び構成等に特に矛盾や問題がない限り、互いの記載内容を組み合わせることが可能である。また、各図の記載内容はそれぞれ独立した実施形態になり得るものであり、本発明の実施形態は各図を組み合わせた一つの実施形態に限定されるものではない。

１ ユーザ状態受信部
２ ＧＰＳ受信部
３ 保存部
４ ストレージ
５ ユーザ操作受信部
６ ユーザ操作処理部
７ ユーザ状態解析部
８ 表示部
９ 通知部
１０ 情報端末機（ユーザ状態予測装置の一例）
１００ サーバ（情報処理装置の一例）
１０１ 制御部
１０２ 通信部
１０３ ユーザ状態検出部
１０４ 記憶部

Claims (9)

1. ユーザの生体情報と、当該ユーザの位置情報を取得する第１取得部と、
   複数のユーザから取得した前記生体情報と前記位置情報に基づき、位置毎の前記複数のユーザの興奮度を含むユーザ状態を示す第１状態情報を生成する第１生成部と、
   過去の第１状態情報を、日時情報とともに履歴情報として取得する第２取得部と、
   前記履歴情報に基づき、任意の位置及び任意の期間または時刻において予測されるユーザ状態を示す予測状態情報を含む第２状態情報を生成する第２生成部と、
   前記予測状態情報を前記任意の位置及び前記任意の期間または時刻とともに表示する表示部と、
   を備えることを特徴とするユーザ状態予測システム。
2. 前記第１取得部は地図情報を更に取得し、
   前記表示部には、前記第２状態情報が前記地図情報とともに表示される
   ことを特徴とする請求項１に記載のユーザ状態予測システム。
3. 前記第２取得部は、前記履歴情報として、天候情報、前記任意の位置におけるイベント情報、及び、前記任意の位置における施設の施設情報のうち少なくとも１つをさらに取得することを特徴とする請求項１または２に記載のユーザ状態予測システム。
4. 前記第１状態情報は、前記複数のユーザの平均的な興奮状態を示す興奮状態情報、及び、当該複数のユーザの人数に基づく密集度情報が含まれることを特徴とする請求項１乃至３のいずれか一項に記載のユーザ状態予測システム。
5. 複数のユーザから取得した生体情報と位置情報に基づき、位置毎の前記複数のユーザの興奮度を含むユーザ状態を示す第１状態情報を生成する第１生成部を有する情報処理装置と通信を行うユーザ状態予測装置であって、
   過去の第１状態情報を、日時情報とともに履歴情報として取得する第２取得部と、
   前記履歴情報に基づき、任意の位置及び任意の期間または時刻において予測されるユーザ状態を示す予測状態情報を含む第２状態情報を生成する第２生成部と、
   前記予測状態情報を前記任意の位置及び前記任意の期間または時刻とともに表示する表示部と、
   を備えることを特徴とするユーザ状態予測装置。
6. ユーザの生体情報と位置情報を送信する端末装置から、当該生体情報と当該位置情報を受信する受信部と、
   複数の端末から受信した前記生体情報と前記位置情報に基づき、位置毎の前記複数のユーザの興奮度を含むユーザ状態を示す第１状態情報を生成する第１生成部と、
   過去の第１状態情報を、日時情報とともに履歴情報として取得する第２取得部と、
   前記履歴情報に基づき、任意の位置及び任意の期間または時刻において予測されるユーザ状態を示す予測状態情報を含む第２状態情報を生成する第２生成部と、
   前記予測状態情報を前記任意の位置及び前記任意の期間または時刻とともに表示する情報として出力する出力部と、
   を備えることを特徴とする情報処理装置。
7. ユーザ状態予測システムにおいて実行されるユーザ状態予測方法であって、
   ユーザの生体情報と、当該ユーザの位置情報を取得する工程と、
   複数のユーザから取得した前記生体情報と前記位置情報に基づき、位置毎の前記複数のユーザの興奮度を含むユーザ状態を示す第１状態情報を生成する工程と、
   過去の第１状態情報を、日時情報とともに履歴情報として取得する工程と、
   前記履歴情報に基づき、任意の位置及び任意の期間または時刻において予測されるユーザ状態を示す予測状態情報を含む第２状態情報を生成する工程と、
   前記予測状態情報を前記任意の位置及び前記任意の期間または時刻とともに表示する工程と、
   を含むことを特徴とするユーザ状態予測方法。
8. 請求項７に記載のユーザ状態予測方法を、コンピュータに実行させることを特徴とするプログラム。
9. 請求項８に記載のプログラムを格納したことを特徴とするコンピュータ読み取り可能な記録媒体。

Images