(57)【特許請求の範囲】
【請求項１】
統計サーバがユーザ端末へ情報プッシュの要否判定用の判定係数を提供し、ユーザ端末が前記判定係数に基づいて情報プッシュの要否を判定する情報プッシュ装置において、
前記ユーザ端末が、
情報プッシュの対象物に対するユーザ状況を検知する手段と、
前記対象物に関する判定係数を統計サーバから取得する手段と、
前記ユーザ状況および判定係数を所定の識別関数に適用して当該対象物に関する情報プッシュの要否を判定する手段と、
要判定の結果に応じて情報プッシュを実行する手段とを含み、
前記統計サーバが、
対象物ごとに、情報プッシュに対するユーザ評価および当該情報プッシュの要否判定に用いられたユーザ状況を情報プッシュ履歴として管理する手段と、
対象物ごとに前記情報プッシュ履歴に基づいて判定係数を計算する手段と、
ユーザ端末からのリクエストに対して前記判定係数を含む前記対象物のプロファイルを応答する手段とを含むことを特徴とする情報プッシュ装置。
【請求項２】
前記ユーザ端末が、前記情報プッシュに対するユーザ評価およびユーザ状況を統計サーバへフィードバックする手段を更に具備し、
前記統計サーバが、前記フィードバックされたユーザ評価およびユーザ状況を情報プッシュ履歴として管理することを特徴とする請求項１に記載の情報プッシュ装置。
【請求項３】
前記ユーザ状況を検知する手段は、対象物が出力するiBeacon電波の受信強度に基づいて当該対象物に対する位置を検知することを特徴とする請求項１または２に記載の情報プッシュ装置。
【請求項４】
前記ユーザ状況を検知する手段は、対象物に対するユーザの顔向きを検知することを特徴とする請求項１ないし３のいずれかに記載の情報プッシュ装置。
【請求項５】
前記ユーザ状況を検知する手段は、ユーザが滞留中であるか否かを検知することを特徴とする請求項１ないし４のいずれかに記載の情報プッシュ装置。
【請求項６】
前記情報プッシュの要否を判定する手段は、ユーザ端末が対象物のプッシュエリア内へ入域すると情報プッシュの要否判定を繰り返すことを特徴とする請求項１ないし５のいずれかに記載の情報プッシュ装置。
【請求項７】
前記対象物のプロファイルが、判定係数、対象物の設置向きおよび対象物の関連情報を記述したURLを含むことを特徴とする請求項１ないし６のいずれかに記載の情報プッシュ装置。
【請求項８】
前記情報プッシュの要否を判定する手段は、ユーザの顔向きと対象物の設置向きとの関係をユーザ状況の一つとして情報プッシュの要否を判定することを特徴とする請求項１ないし７のいずれかに記載の情報プッシュ装置。
【請求項９】
前記ユーザ端末は、情報プッシュが要判定されると、前記プロファイルに記述されているURLにアクセスして対象物の関連情報をプッシュ通信により取得することを特徴とする請求項７に記載の情報プッシュ装置。
【請求項１０】
統計サーバがユーザ端末へ情報プッシュの要否判定用の判定係数を提供し、ユーザ端末が前記判定係数に基づいて実行した情報プッシュに対するユーザ評価を統計サーバへフィードバックして前記判定係数に反映する情報プッシュ方法において、
ユーザ端末が対象物との距離を検知し、所定のプッシュエリア内への入域を検知して統計サーバへリクエストメッセージを送信する手順と、
統計サーバが前記リクエストメッセージに応答して、当該対象物の判定係数を含むプロファイルを応答する手順と、
ユーザ端末がユーザ状況と前記判定係数とに基づいて情報プッシュの要否を判定し、要判定されると情報プッシュを実行する手順と、
ユーザ端末が前記情報プッシュに対するユーザ評価およびユーザ状況を検知して統計サーバへフィードバックする手順と、
統計サーバが前記フィードバックされたユーザ評価およびユーザ状況を基づいて前記判定係数を更新する手順とを含むことを特徴とする情報プッシュ方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、街頭、駅あるいはイベント会場などの公共施設において、ユーザが注目している対象物のユーザ状況に基づき推定し、その関連情報をユーザ端末へプッシュ通信により提供する情報プッシュ方法および装置に関する。
【背景技術】
【０００２】
スマートフォンの普及に伴い、ユーザはいつでもどこでも情報を手軽に取得できる。しかしながら、スマートフォンの操作は簡単ではあるものの、情報を確認するたびに一々スマートフォンの画面ロックを解除したり、アプリケーションを起動したりするなどの操作が必要である。そこで、不必要なインタラクションを減らすため、これまでにいくつかの情報プッシュ技術が提案されている。
【０００３】
特許文献1には、ユーザの予定情報や位置と連動して適切な広告をユーザに提供する技術が開示されている。特許文献1では、サーバのデータベースにユーザの予定およびGPS位置を広告情報と関連づけて登録しておき、時間、場所に関する条件が一致すると、データベースがそれに対応付けられた広告情報を決定してユーザ端末にプッシュする。
【０００４】
非特許文献１には、美術館、博物館などのイベント会場において、複数のWi-Fiアクセスポイント(AP)を利用することで、ユーザが所持する端末の位置を推定し、特定の場所に入ると関連情報をユーザ端末にプッシュする技術が開示されている。
【０００５】
特許文献２には、複数のWi-Fi APによる位置推定ではなく、単独のWi-Fi APもしくはＢｌｕｅｔｏｏｔｈ(登録商標) APにより圏内のユーザ端末を検出する技術が開示されている。特許文献２では、APおよびユーザ端末に同じSSID（Service SetIdentifier）を設定し、このSSIDの探知と該当SSIDの電波強度測定を通じて無線通信範囲に存在するユーザ端末を検出すると、自動的に接続を確立して関連情報をユーザ端末にプッシュする。
【０００６】
特許文献３には、RFIDなどの無線タグが付与された物品からユーザ行動を推定し、ユーザに適切な関連情報を提供する技術が開示されている。特許文献３では、物品を識別するための物品識別子と、物品の情報および物品の情報に関する名詞とを当該物品に関連する動詞をそれぞれ対応付けて保持する。
【０００７】
ユーザが、無線タグリーダが搭載されたユーザ端末を用いて、物品に付与された無線タグIDを検出すると、無線タグが付与された物品からユーザ行動を推定し、ユーザに適切な関連情報を提供する。例えば、ユーザがユーザ端末をジャケットにかざすと、タグIDに関連づけられた名詞「jacket」と動詞「wear」を取得できる。従って、サービスプロバイダは、そのユーザがジャケットを着ようとしていることを推定し、ユーザに対してファッション広告を提供することができる。
【０００８】
特許文献４には、HMDを着用したユーザに対して、ユーザの位置および進行方向に応じた情報を提示する技術が開示されている。特許文献４では、GPSによりユーザ位置を特定したうえで、進行方向の直行方向を含まない第一の判定エリアおよび進行方向の直行方向を含む第二の判定エリアのそれぞれに対して情報を提供することができる。
【先行技術文献】
【特許文献】
【０００９】
【特許文献１】特開2010-055352号公報
【特許文献２】特願2006-543074号公報
【特許文献３】特開2007-041923号公報
【特許文献４】特開2012-78224号公報
【非特許文献】
【００１０】
【非特許文献１】暦本純一、塩野崎敦、末吉隆彦、味八木崇「PlaceEngine:実世界集合知に基づくWi-Fi位置情報基盤」インターネットコンファレンス2006, pp.95-104, 2006
【発明の概要】
【発明が解決しようとする課題】
【００１１】
特許文献１では、GPSにより端末位置を推定するため、施設内では位置特定が困難である。また、GPSによる測位は消費電力が多いことから、バッテリ容量の小さいモバイル端末への実装には適さない。
【００１２】
非特許文献１では、施設内でもユーザの位置を推定できるが、場所によって電波伝搬特性が違うため、推定位置の精度を高めるためのキャリブレーションが必要となり、設置・設定のコストが高くなる。また、端末の位置推定に対象物と端末との簡単な条件マッチングを利用するため、ユーザが対象物のそばを通りかかると、注目しているか否かに関わらずその関連情報がプッシュされてしまう。
【００１３】
特許文献２は、単独のWi-Fi APの圏内検知によって非特許文献１よりも設置・設定のコストを低く抑えられるが、非特許文献１と同様に、対象物の場所によってキャリブレーションが必要になり、またユーザが対象物に注目していなくても関連情報をプッシュされてしまうことがある。
【００１４】
特許文献３では、無線タグを利用して対象物を確実に特定できるが、ユーザからそれぞれの対象物に関連づけられたタグを携帯でかざしたり、タッチしたりする操作が必要であった。
【００１５】
特許文献４では、位置情報に加えてユーザの進行方向を利用することで、ユーザの視線に応じて直感的な情報を提供することができる。ただし、ユーザが対象物のそばを通りかかったり、無意識に覘いたりすると、ユーザが実際に対象物に興味関心がなくても関連情報がプッシュされてしまう。また、特許文献４もGPSによる位置測定を前提にしているため、施設内での利用が難しく、また消費電力が大きいのでモバイル端末への実装に適さない。
【００１６】
本発明の目的は、上記の技術課題を解決し、少ない電力消費でモバイル端末の位置を屋内でも正確に測位でき、ユーザが興味を持って注目した対象物の関連情報のみを正確に取得できる情報プッシュ方法および装置を提供することにある。
【課題を解決するための手段】
【００１７】
上記の目的を達成するために、本発明は、関連情報がプッシュされる対象物に対するユーザ状況として、ユーザの各対象物に対する相対位置、動静状態あるいは顔向きの検知し、これらに基づいて、ユーザが関連情報を欲しているであろう対象物、あるいはユーザにとって関連情報の取得が有益な対象物を推定し、当該対象物の関連情報のみが自動的にユーザ端末へプッシュされるようにした。
【００１８】
また、ユーザ端末の位置推定に要する電力消費を低減するために、対象物ごとにiBeaconタグを設置し、iBeaconタグがブロードキャストするiBeacon電波の受信強度に基づいて、ユーザの各対象物に対する相対位置を推定するようにした。
【００１９】
さらに、情報プッシュが実行されたときのユーザ状況と当該情報プッシュに対するユーザ評価とを統計サーバへフィードバックしてユーザ状況とユーザ評価との関係を対象物ごとに学習し、これに基づいて、任意のユーザに対する情報プッシュの要否を、そのユーザ状況に基づいて対象物ごとに判定するようにした。
【発明の効果】
【００２０】
本発明によれば、以下のような効果が達成される。
(1) 対象物に対するユーザ状況を検知し、これに基づいて当該対象物の関連情報をユーザにプッシュするか否かが判定されるので、ユーザにとって有益な関連情報あるいはユーザが欲している関連情報のみを正確にプッシュできるようになる。
【００２１】
(2) ユーザの各対象物に対する相対位置を推定するために、各対象物に設けたiBeaconタグがブロードキャストするiBeacon電波の受信強度を検知するようにしたので、GPSやWi-Fiを用いた位置推定に比べて電力消費量を抑えられるのみならず、屋内外を問わず正確な位置推定が可能になる。
【００２２】
(3) ユーザ状況とユーザ評価との関係を対象物ごとに学習し、これに基づいて、任意のユーザに対する情報プッシュの要否を、そのユーザ状況に基づいて対象物ごとに判定するようにしたので、情報プッシュの要否判定を対象物ごとに正確に行えるようになる。また、情報プッシュの要否判定の汎用性を高めることができる。
【図面の簡単な説明】
【００２３】
【図１】本発明の一実施形態に係る情報プッシュシステムの機能ブロック図である。
【図２】SVMによる判定係数の算出方法を示した図である。
【図３】iBeacon電波のフォーマットを示した図である。
【図４】歩行時のパワースペクトルを示した図である。
【図５】停留中のパワースペクトルを示した図である。
【図６】地磁気センサで計測された地磁気の情報に基づいて磁方位を算出する方法を模式的に表現した図である。
【図７】ユーザの顔向きの推定方法を示した図である。
【図８】ユーザ端末の動作を示したフローチャートである。
【図９】統計サーバの動作を示したフローチャートである。
【図１０】挟み角に関連したユーザ状況の検知方法を示した図である。
【発明を実施するための形態】
【００２４】
以下、図面を参照して本発明の実施の形態について詳細に説明する。図１は、本発明の一実施形態に係る情報プッシュシステムの構成を示した機能ブロック図であり、可搬性のユーザ端末１、統計サーバ２およびコンテンツサーバ３から構成される。
【００２５】
ユーザ端末１としては、スマートフォンに加えて、眼鏡型デバイスや腕時計型の情報端末（スマートウォッチ）などのウェアラブルデバイスも利用できる。Google Glass（登録商標）をはじめとする眼鏡型デバイスは、ユーザの視界に情報を常時かつ直接にプッシュできるため、本発明の適用にもっとも効果的なデバイスである。そこで、本実施形態ではユーザ端末１が眼鏡型デバイスであるものとして説明する。
【００２６】
ユーザ端末１において、センシング部１０１は、対象物に対するユーザの位置を検知する位置センサ機能１０１ａおよびユーザの動静を検知する動静センサ機能１０１ｂを備え、本実施形態ではさらに、ユーザの顔向きを検知する顔向きセンサ機能１０１ｃを備えている。
【００２７】
情報プッシュ決定部１０２は、センシング部１０１によるユーザ状況の検知結果および統計サーバ２から提供される判定係数に基づいて、ユーザが注目していると推定される対象物に関する関連情報のプッシュ通信による取得（情報プッシュ）の要否を決定する。
【００２８】
表示部１０３は、情報プッシュにより取得した関連情報を眼鏡型デバイスのディスプレイに出力する。対話操作部１０４は、実行された情報プッシュに対するユーザ評価を統計サーバ２へフィードバックするための音声対話機能や入出力操作機能を提供する。
【００２９】
外部コンテンツ取得部１０５は、前記情報プッシュ決定部１０２により情報プッシュの実行が決定されると、対象物の関連情報をコンテンツサーバ３から情報プッシュにより取得する。このようなコンテンツ取得は、統計サーバ２から関連情報の記述先として提供されるURLをHTTP GETまたはHTTP POSTのリクエストにパラメータとして組み込み、ネットワーク上のコンテンツサーバ３に送信することで実現される。
【００３０】
統計サーバ２において、プッシュ履歴DB２０１には、各ユーザ端末１において実行された情報プッシュに対してユーザからフィードバックされた評価値（肯定／否定など）が、当該情報プッシュの要否判定に用いられたユーザ状況と対応付けられて、対象物ごとにプッシュ履歴としてデータベース化されている。本実施形態では、以下のような情報がプッシュ履歴DB２０１に蓄積されており、その詳細は詳述する。
【００３１】
(1) 対象物ID：UUID+Major+Minor
(2) フィードバック：+1[肯定]  -1[否定]
(3) プッシュ時のRSSI：0[最強(0-2m)]  1[強(2-5m)]  2[中(5m-10m)]  3[弱(10m以上)]
(4) 入域時間: 0[0〜2s]  1[2〜5s]  2[5s以上]
(5) ユーザ視界との挟み角：0[-30°〜30°]  1[-60°〜60°]  2[-90°〜90°]  3[それ以上]
(6) ユーザと対象物の相対位置：0[接近]  1[離反]
(7) 現在の動静状態：0[停止]  1[移動]
(8) 現在の動静状態の維持時間：0[0〜2s]  1[2〜5s]  2[5s以上]
【００３２】
判定係数計算部２０２は、前記プッシュ履歴の各フィールド値（ユーザ評価および各ユーザ状況）を入力として集計処理を行い、ユーザが対象物に注目しているか否か、あるいはユーザに対して対象物の関連情報を提供する必要があるか否かを判定する際の指標となる判定係数を、周知の統計的機械学習により対象物ごとに計算する。
【００３３】
本実施形態では、機械学習方式として、線形入力素子を利用して２クラス（情報プッシュの肯定／否定）のパターン識別器であるサポートベクターマシン(Support Vector Machine：SVM)を利用する。SVMは、現在知られている多くの手法の中で一番認識性能が優れた学習モデルの一つであり、未学習データに対して高い識別性能を得られている。ちなみに、あらかじめ与えられた状態ログのサンプリングレコードを用いて、情報プッシュの肯定／否定をどのように分類したらよいかをSVMで学習すれば、実際のユーザ利用時に未知のユーザ状況（コンテキスト）に対して、情報プッシュの判定を確度が高く分類させることが可能である。
【００３４】
すなわち、システムは取り得る全ての挙動を示すあらゆる入力を含めることは現実的ではなく、判定係数計算部２０２が算出した判定係数を通して統計学習に用いなかった未知のユーザ状況が入力されたとしても情報プッシュの要否を判断できるようになる。
【００３５】
例えば、ある対象物に対して、プッシュ時のRSSIが「3[弱(10m以上)]」、入域時間が「2[5s以上]」、ユーザ視界との挟み角が「2[(-90°〜90°)]」、ユーザと対象物の相対位置が「1[離反]」、現在の動静状態が「0：走行」、現在の動静状態の維持時間が「0：0〜2s」といったユーザ状況は未学習であるが、この未知のユーザ状況と判定係数を識別関数に入力すれば、情報プッシュの要否を推定できる。
【００３６】
SVMによる判定係数の算出では、図２に示したように、ラグランジュの未定乗数法を用いることにより、各データ点との距離が最大となるマージン最大化超平面を求めるという基準で線形入力素子の判定係数w*, b*を決定する。実際の利用時に情報プッシュの要否を判定する際は、判定係数とユーザの状況の特徴量を、次式の識別関数に入力して要否の２値結果を出力する。
【００３７】
【数１】
0006282960.tif 000002
【００３８】
なお、上記のような機械学習に代えて、単純な条件マッチング手法を採用しても良い。例えば、初期時の利用においてデフォルトは「対象物と離れた距離強(2-5m)、入域時間は3秒以上、ユーザの視界との角度差分は130°〜230°、現在の動静状態は停止」に設定し、その後、ユーザの利用履歴を集計して条件マッチングの平均値を算出し、これに基づいて各パラメータを更新するようにしても良い。
【００３９】
対象物管理部２０３は、各対象物のプロファイルとして、前記判定係数、対象物の設置向きおよび当該対象物の関連情報を記述しているURLを管理する。また、ユーザ端末１の情報プッシュ決定部１０２から、実行された情報プッシュに対するユーザ評価およびそのときのユーザ状況を取得して前記プッシュ履歴DB２０１に登録する。
【００４０】
次いで、ユーザ端末１の位置センサ機能１０１ａ、動静センサ機能１０１ｂおよび顔向きセンサ機能１０１ｃについて詳細に説明する。
【００４１】
位置センサ機能１０１ａは、各対象物に張り付けられたiBeaconタグが発信するiBeacon電波を受信し、その電波強度(RSSI)を計測することにより、ユーザ（ユーザ端末）が各対象物の関連情報をプッシュ通信により取得できるプッシュエリアに入域し、または出域したことを検知する。
【００４２】
iBeaconはBLE(Bluetooth Low Energy)の規格に準拠し、省電力でシンプルなブロードキャスト・スキャン方式を実現している。ユーザ端末１の位置センサ機能１０１ａは、各対象物のiBeaconタグからブロードキャスティングされたビーコン電波を解析することができる。
【００４３】
iBeacon電波は、図３に示したように128ビットの「UUID」、16ビットの整数である「Major」および「Minor」、ならびに16ビットの1m離れたときの電波強度参考値「Tx Power」から構成され、「UUID」、「Major」、「Minor」に基づいて、事前に登録された対象物や場所を容易に特定できる。
【００４４】
各対象物のプッシュエリアは、事前に設定する電波強度の閾値によって定義されるが、ユーザ端末１がプッシュエリアの境界近傍に滞在すると、電波の揺らぎで入域および出域の検知が頻繁に繰り返されてしまう。このため本実施形態では、入域の閾値は境界の値より高めに、出域の閾値は境界の値より低めに設定することにより、入出域の推定が安定して行われるようにしている。
【００４５】
なお、本実施形態では単一のiBeaconタグに基づいて入出域が検出されるが、複数のiBeaconタグがそれぞれブロードキャストする電波の強度に基づいて入出域が検出されるようにしても良い。具体的には、あらかじめ既知の位置で測定した各iBeaconタグの電波強度から構成された受信特徴量と、実際に測定した受信特徴量とのユークリッド距離を算出し、ユークリッド距離が一番小さく、かつユークリッド距離が閾値より小さい既知の位置にユーザが位置していることを推定しても良い。
【００４６】
動静センサ機能１０１ｂは、加速度センサの測定値からユーザが停留中（静）および歩行中（動）のいずれであるかを推定する。本実施形態で利用する加速度センサは、スマートフォンをはじめとして、最近のウェアラブルデバイスでも広く搭載されている３軸加速度センサであり、数ミリ秒周期でx，y，z軸の加速度を取得するものである。この３つの動静状態の特徴を表したモデルデータを用意し、一定時間ごとに計測されたN個の加速度の平均値とモデルデータとの類似度を比較することでユーザの動静状態を推定する。
【００４７】
一方、加速度センサで観測された加速度の波形をそのまま比較するとお互いの位相を合わせるなどの操作が必要となる。このため、本実施形態では加速度データをフーリエ変換して周波数ごとの強さ(パワースペクトル：動静状態によってスペクトルが高くなる周波数や大きさなどの特徴が異なる)を求める。そして、各動静状態のモデルデータをリアルタイムで観測された加速度のスペクトルと比較し、各周波数帯の値のユークリッド距離が最も少ないモデルデータを動静状態とする。
【００４８】
図４は、歩行時のパワースペクトルを示した図であり、パワースペクトル値が３Hz近くで飛び抜けて大きく、他の周波数帯域では小さな値を示していることが判る。一方、図５は、停留中のパワースペクトルを示した図であり、パワースペクトルがほとんどの帯域でゼロを示していることが判る。
【００４９】
顔向きセンサ機能１０１ｃは、地磁気センサを用いてユーザの顔向きを推定する。ユーザがGoogle Glass（登録商標）を掛ける場合、その移動は平面となるため、２軸の地磁気センサを利用できる。したがって、本実施形態は２軸の地磁気センサの利用を例にして説明するが、ピッチング・ローリングを含む３軸の地磁気センサを利用しても良い。
【００５０】
図６は、地磁気センサで計測された地磁気の情報に基づいて磁方位を算出する方法を模式的に表現した図である。
【００５１】
磁気センサからは、X軸成分（HX）およびY軸成分（HY）が出力される。地域によって磁気環境が異なるため、デバイスの初期設定で基準値のHXref、HYrefを予め求める。このとき、地磁気センサの方位を一回りに変化させ、円の中心に相当する地磁気をそれぞれ、HXref、HYrefとして算出する。これにより、実際に測定したHXとHYの値からユーザの顔の向きは、図７のようにして推定できる。
【００５２】
次いで、本実施形態の動作をフローチャートに沿って説明する。図８は、前記ユーザ端末１の動作を示したフローチャートであり、図９は、前記統計サーバ２の動作を示したフローチャートである。
【００５３】
図８において、ステップS１では、ユーザ端末１の位置センサ機能１０１ａにおいて、各対象物から送出されるiBeacon電波を一定時間間隔で探知することにより、ユーザがある対象物のプッシュエリアに入域したか否かが判定される。本実施形態では、所定の閾値を上回る強度(RSSI)のiBeacon電波が受信されると、情報プッシュ決定部１０２の入出域検知部１０２ａにより、ユーザがある対象物のプッシュエリアに入域したと判定されてステップS２へ進む。
【００５４】
このように、本実施形態では省電力であるiBeaconの圏内通知を情報プッシュ判定のトリガーとしてシステムの動作を開始する手法を利用することで、バッテリの消費量を抑えながら本発明の最適化効果を得られるようにしている。
【００５５】
ステップＳ２では、受信中のiBeacon電波から対象物のID（UUID、Major、Minor）が抽出される。ステップS３では、前記対象物IDの記述されたリクエストメッセージが、情報プッシュ決定部１０２のリクエスト部１０２ｂから統計サーバ２へ送信される。
【００５６】
統計サーバ２は、図９のステップS２１において前記リクエストメッセージを受信すると、ステップS２２では、対象物IDに対応する情報プッシュ履歴をプッシュ履歴DB２０１から検索して判定係数計算部２０２へ提供する。ステップS２３では、判定係数計算部２０２が前記情報プッシュ履歴（ユーザ評価および各ユーザ状況）を所定の関数に適用して判定係数を計算する。ステップS２４では、前記判定係数、対象物の向きおよび当該対象物の関連情報が記述されているURLを含むプロファイルが、対象物管理部２０３からユーザ端末１へ応答される。
【００５７】
ユーザ端末１では、図８のステップS４において、前記リクエストメッセージに対して統計サーバ２が応答した対象物のプロファイル情報を受信すると、ステップS５では、情報プッシュ決定部１０２により、前記動静センサ機能１０１ｂのセンシング結果に基づいてユーザの動静状態が判定され、さらに挟み角検知部１０２ｃにより、前記顔向きセンサ機能１０１ｃにより検知された顔向きと、前記対象物のプロファイル情報に記述されていた対象物の設置向きとの挟み角が検知される。
【００５８】
図１０は、挟み角に関連したユーザ状況の検知方法を示した図であり、初めにiBeacon電波の受信強度の時系列変化を参照し、ユーザと対象物との相対位置が推定される。すなわち、iBeacon電波の受信強度が漸増傾向にあれば「接近」、漸減傾向にあれば「離反」と推定する。ユーザが対象物に接近中であれば、顔向きセンサ機能１０１ｃにより検知された方位O1および統計サーバ２から提供される該当対象物の正面の反対側の垂線向きを示す方位O2の角度差（挟み角）を算出する[同図(ａ)]。
【００５９】
挟み角が所定の範囲内（-θref〜+θref）であれば、対象物がユーザの視界に入っていると推定できる（同図(b)の1，3，5）。それ以外の場合は、対象物がユーザの視界に入っていないと推定できる（同図(b)の2，4）。これに対して、同図(c)に示したように、ユーザが対象物から離反中であれば、対象物がユーザの視界に入っていないと推定できる。
【００６０】
一方、本実施形態で想定している対象物は、美術館や博物館などにおいて、壁に貼り付けられる絵やポスター、あるいは壁付近の展示コーナーに設置された展示品などである。しかしながら、対象物が壁際ではなく開放的な空間に置いてある場合、例えばユーザが対象物の脇を通過するように接近すると（同図(d)の1）、対象物が視界の正面でない場合でも情報プッシュされる可能性がある。
【００６１】
このような場合の情報プッシュを防止するためには、iBeacon電波に指向性を持たせて正面方向にしか電波を出せなくするか、あるいは複数のiBeaconタグを設けて対象物の表裏を推定できるようにしても良い。
【００６２】
このように、前ユーザの顔向きと対象物の設置向きとの挟み角や、ユーザと対象物との相対位置が「接近」および「離反」のいずれであるかを情報プッシュの要否判定パラメータとして採用すれば、ユーザが対象物のそばを通りかかったりするなど、注目していない対象物の情報をプッシュされてしまう問題を回避することが可能である。
【００６３】
ステップS６では、前記iBeacon電波の受信状況に基づいて、ユーザが対象物のプッシュエリアから出域したか否かが判例される。未だ出域していないと判定されれば、ステップS７へ進んで情報プッシュの要否判定が行われる。本実施形態では、センシング部１０１により検知されたユーザ状況（RSSI、入域時間、現在の動静状態、動静状態の維持時間）および前記挟み角やユーザと対象物との相対位置、ならびに受信したプロファイルから取得した判定係数を所定の識別関数１０２ｄに適用することにより、情報プッシュの要否判定が行われる。
【００６４】
ここで、情報プッシュが不要と判定されるとステップS５へ戻るが、情報プッシュが必要と判定されると、ステップS８へ進んで情報プッシュが実行される。ステップS９では、今回の情報プッシュに対する評価が対話操作部１０４により受け付けられる。
【００６５】
ユーザは、自身が興味を持って注目した対象物の情報がプッシュされれば肯定応答し、興味が無く注目していない対象物の情報がプッシュされれば否定応答する。また、興味を持って注目したにもかかわらず情報がプッシュされない場合に否定応答しても良い。
【００６６】
ステップS１０では、前記ユーザ評価が当該情報プッシュの際のユーザ状況と共に、フィードバック部１０２ｅにより統計サーバ２へフィードバックされる。
【００６７】
統計サーバ２は、図９のステップS２５において前記フィードバックを受信するとステップS２６へ進み、前記ユーザ評価およびユーザ状況が前記プッシュ履歴DB２０１において前記対象物と対応付けられた情報プッシュ履歴情報に追加される。
【００６８】
情報プッシュ後は、ユーザが対象物のプッシュエリアからの出域したことが検知されるまで、プッシュされた情報を表示部１０３に表示し続けてもよいが、このとき近くにある他の対象物の方向や距離などのナビ情報を表示するようにしても良い。
【００６９】
本実施形態によれば、対象物に対するユーザ状況を検知し、これに基づいて当該対象物の関連情報をユーザにプッシュするか否かが判定されるので、ユーザにとって有益な関連情報あるいはユーザが欲している関連情報のみを正確にプッシュできるようになる。
【００７０】
また、本実施形態によれば、ユーザの各対象物に対する相対位置を推定するために、各対象物に設けたiBeaconタグがブロードキャストするiBeacon電波の受信強度を検知するので、GPSやWi-Fiを用いた位置推定に比べて電力消費量を抑えられるのみならず、屋内外を問わず正確な位置推定が可能になる。
【００７１】
さらに、本実施形態によれば、ユーザ状況とユーザ評価との関係を対象物ごとに学習し、これに基づいて、任意のユーザに対する情報プッシュの要否を、そのユーザ状況に基づいて対象物ごとに判定するので、情報プッシュの要否判定を対象物ごとに正確に行えるようになる。また、情報プッシュの要否判定の汎用性を高めることができる。
【符号の説明】
【００７２】
１…ユーザ端末，２…統計サーバ，３…コンテンツサーバ，１０１…センシング部，１０１ａ…位置センサ機能，１０１ｂ…動静センサ機能，１０１ｃ…顔向きセンサ機能，１０２…情報プッシュ決定部，１０２ａ…入出域検知部，１０２ｂ…リクエスト部，１０２ｃ…挟み角検知部，１０２ｄ…識別関数，１０２ｅ…フィードバック部，１０３…表示部，１０４…対話操作部，１０５…外部コンテンツ取得部，２０１…プッシュ履歴DB，２０２…判定係数計算部，２０３…対象物管理部
【図１】
0006282960.tif 000003
【図２】
0006282960.tif 000004
【図３】
0006282960.tif 000005
【図４】
0006282960.tif 000006
【図５】
0006282960.tif 000007
【図６】
0006282960.tif 000008
【図７】
0006282960.tif 000009
【図８】
0006282960.tif 000010
【図９】
0006282960.tif 000011
【図１０】
0006282960.tif 000012