(57)【要約】【課題】センサ毎の生データ形式の差異を吸収することができ、また、汎用的に多様なステータスを推定可能とする。【解決手段】識別情報生成装置３００は、緯度経度や、温度、湿度、閲覧ＵＲＬなどといったユーザのステータスを表す生データを取得し、生データをステータスに変換する。ステータス推定装置２００は、識別情報取得部２３０により上記ステータスを取得し、受信したステータスをステータステーブル２４１に保存するとともに、ステータス推定部２２０を用いて、ステータステーブル２４１に保存されたステータスを用いて、受信されていないその他のステータスのステータス値を推定する。ステータス提供部２１０は、この推定されたステータスを必要とするアプリケーションサーバ１００にステータスＩＤとステータス値とを送信する。【選択図】図１
2010044680.tif 000002
【特許請求の範囲】
【請求項１】
ユーザのステータスを表す生データを取得する識別情報取得手段と、
前記ステータスの種別を識別するステータスＩＤと、該ステータスの励起確率を示すステータス値とを前記生データに応じて生成する識別手段と、
前記識別手段によって生成された、前記ステータスＩＤとステータス値とを保持するステータステーブルと、
前記ステータステーブルに保持されている前記ステータスＩＤとステータス値とに基づいて、前記ステータスと相関関係にある他のステータスのステータス値を推定するステータス推定手段と、
を備えることを特徴とするステータス推定システム。
【請求項２】
前記ステータス推定手段により推定されたステータス値を、前記ユーザのステータスに応じたサービスを提供するアプリケーションサーバに提供するステータス提供手段をさらに備えることを特徴とする請求項１記載のステータス推定システム。
【請求項３】
前記ステータステーブルは、前記ステータスＩＤとステータス値に加え、登録された時刻を表すステータス登録時刻を合わせて保持し、
前記ステータス推定手段は、ステータス推定時に前記ステータス登録時刻を参照し、該ステータス登録時刻が予め設定された値以前の時刻であった場合には、当該ステータスのステータスＩＤとステータス値を削除することを特徴とする請求項１記載のステータス推定システム。
【請求項４】
アプリケーションサーバからのステータスＩＤと該アプリケーションサーバのＵＲＬとを登録する購読者テーブルと、
前記ステータス推定手段により前記購読者テーブルに登録されているステータスＩＤに対応するステータス値が推定された場合、前記ステータスＩＤに対応付けて登録されているＵＲＬに基づいて、当該ステータス値を通知するステータス通知手段と
を更に備えることを特徴とする請求項１記載のステータス推定システム。
【請求項５】
ユーザのステータスを表す生データを取得するステップと、
前記ステータスの種別を識別するステータスＩＤと、該ステータスの励起確率を示すステータス値とを前記生データに応じて生成するステップと、
生成した前記ステータスＩＤとステータス値とを保持するステップと、
前記ステータスＩＤとステータス値とに基づいて、前記ステータスと相関関係にある他のステータスのステータス値を推定するステップと
を含むことを特徴とするステータス推定方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、センシング情報を用いてユーザのステータスを推定する情報処理システムに係り、特に、センシング情報を識別する装置と、識別された情報を用いてステータスを確率的に推定する装置からなるステータス推定システム、及びステータス推定方法に関する。
【背景技術】
【０００２】
従来、複数のセンサを用いてユーザの状況を推定する技術が提案されている（例えば、特許文献１参照）。該従来技術では、例えば、ユーザが椅子を利用しているかどうかを推定するために、ユーザに４つの加速度センサを付与し、４つの加速度センサの値の直積から、まずは部分状況として「静止」や、「移動」、「着席」等に分類し、その後、加速度センサから抽出された部分状況の時系列から、最尤検定等の手法を用いて、椅子利用如何（椅子を利用しているか否か）という状況を推定している。
【特許文献１】特開２００７−１８７５５２号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
上述した従来技術では、特定のセンサや、サービスの存在を前提とし、それらを用いて取得できる生データから可能な限り高い精度でプレゼンスや、コンテキストといったステータスを推定していた。しかしながら、ユーザの「移動」、「静止」のような低次のステータスを、例えば、加速度センサを用いて推定する場合には、センサ数が十分であれば１００％に近い高精度にて推定することができるが、同じく加速度センサのみを用いて、「椅子を利用しているかどうか」等の高次のステータスを推定する場合には、その精度が著しく低下する。
【０００４】
この精度低下は、推定に必要な情報が足りないために、代替のステータスを推定しているために起こる。例えば、椅子利用如何というステータスの場合、これを「着席」から「離席」までとし、さらに、「着席」を「静止→移動→着席→静止」等とステータスで代替するものとし、その推定が行われる。この推定精度が１００％であり、ステータスが「静止→移動→着席→静止」のように遷移したとしても、「椅子を利用している」ことは成り立たないことがあるため（例えば、「屋外」と分かれば自転車に乗っている等）、結局、「椅子を利用している」かどうかの推定ができたとはならない。
【０００５】
上述した問題は、根本的には、推定に用いる情報の不足に起因している。そこで必要な全てのセンサを用いて推定を行うことが必要になる。しかしながら、多数のセンサを用いるためには、以下の課題を解決しなければならない。
【０００６】
１つ目には、センサ毎の生データ形式の差異の吸収方法の確立である。例えば、ユーザのステータスとして、Ｗｅｂ上でのホームページ閲覧履歴取得機能も含まれるものと考えると、多種多様なセンサが必要となるため、そのデータをそのまま集約・利用する機能の確立は、困難であるという問題があった。
【０００７】
２つ目は、不特定多数のセンサ類からの情報を収容し、それら情報から汎用的に多様なステータスを推定する方法の確立である。従来技術においては、複雑なロジックを用いて生データをステータスに加工しているが、不特定多数のセンサ類からの情報を用いる場合には、生データ固有の推定ロジックを実装することが困難であるため、汎用的な推定ロジックを構築することが非常に困難であるという問題があった。
【０００８】
本発明は、このような事情を考慮してなされたものであり、その目的は、センサ毎の生データ形式の差異を吸収することができ、また、汎用的に多様なステータスを推定することができるステータス推定システム、及びステータス推定方法を提供することにある。
【課題を解決するための手段】
【０００９】
上述した課題を解決するために、本発明は、ユーザのステータスを表す生データを取得する識別情報取得手段と、前記ステータスの種別を識別するステータスＩＤと、該ステータスの励起確率を示すステータス値とを前記生データに応じて生成する識別手段と、前記識別手段によって生成された、前記ステータスＩＤとステータス値とを保持するステータステーブルと、前記ステータステーブルに保持されている各ステータスの励起確率を参照し、前記ステータスＩＤとステータス値とに基づいて、前記ステータスと相関関係にある他のステータスのステータス値を推定するステータス推定手段とを備えることを特徴とするステータス推定システムである。
【００１０】
本発明は、上記の発明において、前記ステータス推定手段により推定されたステータス値を、前記ユーザのステータスに応じたサービスを提供するアプリケーションサーバに提供するステータス提供手段をさらに備えることを特徴とする。
【００１１】
本発明は、上記の発明において、前記ステータステーブルは、前記ステータスＩＤとステータス値に加え、登録された時億を表すステータス登録時刻を合わせて保持し、前記ステータス推定手段は、ステータス推定時に前記ステータス登録時刻を参照し、該ステータス登録時刻が予め設定された値以前の時刻であった場合には、当該ステータスのステータスＩＤとステータス値を削除することを特徴とする。
【００１２】
本発明は、上記の発明において、アプリケーションサーバからのステータスＩＤと該アプリケーションサーバのＵＲＬとを登録する購読者テーブルと、前記ステータス推定手段により前記購読者テーブルに登録されているステータスＩＤに対応するステータス値が推定された場合、前記ステータスＩＤに対応付けて登録されているＵＲＬに基づいて、当該ステータス値を通知するステータス通知手段とを更に備えることを特徴とする。
【００１３】
また、上述した課題を解決するために、本発明は、ユーザのステータスを表す生データを取得するステップと、前記ステータスの種別を識別するステータスＩＤと、該ステータスの励起確率を示すステータス値とを前記生データに応じて生成するステップと、生成した前記ステータスＩＤとステータス値とを保持するステップと、前記ステータスＩＤとステータス値とに基づいて、前記ステータスと相関関係にある他のステータスのステータス値を推定するステップとを含むことを特徴とするステータス推定方法である。
【発明の効果】
【００１４】
この発明によれば、推定に多数の生データを必要とするステータスの推定においても、多様な生データ形式をステータスの励起如何という形式に統一して収集し、そのステータス励起間の条件付確率を用いて統一的・汎用的に推論を行うようにしたので、センサ毎の生データ形式の差異を吸収することができ、また、汎用的に多様なステータスを推定することができる。
【発明を実施するための最良の形態】
【００１５】
以下、本発明の一実施形態を、図面を参照して説明する。
図１は、本発明の実施形態によるステータス推定システムの構成を示すブロック図である。図において、本実施形態によるステータス推定システムは、ステータス推定装置２００と識別情報生成装置３００とからなり、それぞれの間でステータスを一致させておく。その上で、まず、識別情報生成装置３００が緯度経度や、閲覧ＵＲＬといった生データを、生データ取得機能３３１によって取得し、これを識別機能３２１によってステータスに変換する。これを識別情報提供部３１０がステータス推定装置２００に送信する。
【００１６】
ステータス推定装置２００では、識別情報取得部２３０により上記ステータスを取得し、受信したステータスをステータステーブル２４１に保存するとともに、ステータス推定部２２０を用いて、ステータステーブル２４１に保存された０以上の受信したステータスを用いて、受信されていないその他のステータスを推定する。ステータス提供部２１０は、この推定されたステータスを必要とするアプリケーションサーバ１００に必要な情報を送信する。これによって、ステータス（ステータスＩＤ、ステータス値）を受信したアプリケーションサーバ１００は、コンテクストアウェアなアプリケーション等をユーザに向けて提供可能となる。
【００１７】
なお、本実施形態の一例として、ステータスとしては、位置や、温度・湿度等を想定し、該位置や、温度・湿度等に応じて、ユーザのステータスを推定し、該ステータスでユーザに推薦するサービス、例えば、サッパリとした料理などを決定し、このような料理をする店舗を推薦する場合について説明する。該一例は、あくまでも実施の一形態を示すものであり、特許請求の範囲を限定するものではない。
【００１８】
図１において、アプリケーションサーバ１００は、ステータス推定装置２００で推定されたユーザのステータス（位置や、温度・湿度等）に応じて提供されるサービスをユーザに提供する。より具体的には、アプリケーションサーバ１００は、購読者テーブル２１１に、購読したいステータスＩＤと自らのステータス受信部のＵＲＬを登録することで、ステータス変化の通知購読を行う。ステータスＩＤとは、ユーザのステータス（位置や、温度・湿度等）を識別するための識別情報である。なお、アプリケーションサーバ１００内の購読者テーブル操作インタフェースや、ステータス受信部は、一般的なものを想定しているため、ここでは言及しない。
【００１９】
ステータス推定装置２００は、後述する識別情報生成装置３００から受信する受信ステータスＩＤ、及び、それを用いて推定した推定ステータスＩＤ（受信ステータスＩＤ、推定ステータスＩＤを区別せずステータスＩＤと呼ぶ）を定義し、さらに、図２に示すようなステータス間の相関を表すグラフ（各ノードがステータスを表し、リンクの存在が相関の存在を示す。本実施形態では、ベイジアンネットワークを想定）と、図３（ａ）〜（ｃ）に（一部を）示すようなステータス間の条件付確率表とを作成し、後述する確率グラフＤＢ２２２に設定して記憶させる。
【００２０】
なお、図３（ａ）〜（ｃ）に示す条件付確率表の値は、リンクの元側のステータスが励起している際に、値が０に近いほど、リンク先のステータスが励起している確率（そのステータスが真である確率）が低く、１に近いほど励起している確率が高いことを示している。図３（ａ）には、仕事中の確率表であり、仕事中の確率は、「平日」の「昼」では、「０．９８」であり、「平日」の「ｎｏｔ昼」では、「０．４」、「ｎｏｔ平日」の「昼」では、「０．１」であり、「ｎｏｔ平日」の「ｎｏｔ昼」では、「０．０１」であることを表している。
【００２１】
同様に、図３（ｂ）には、コッテリしたものが食べたい確率表であり、コッテリしたものが食べたい確率は、「空腹」で「乾燥」では、「０．９５」で、「空腹」で「ｎｏｔ乾燥」では、「０．７」、「ｎｏｔ空腹」で「乾燥」では、「０．１」、「ｎｏｔ空腹」で「ｎｏｔ乾燥」では、「０」であることを表している。すなわち、空腹で乾燥している場合には、コッテリしたものが食べたい確率が高いことを表している。また、図３（ｃ）には、サッパリしたものが食べたい確率表であり、サッパリしたものが食べたい確率は、「空腹」で「暑い」では、「０．７」で、「空腹」で「ｎｏｔ暑い」では、「０．２」、「ｎｏｔ空腹」で「暑い」では、「０．０１」、「ｎｏｔ空腹」で「ｎｏｔ暑い」では、「０．１５」であることを表している。すなわち、空腹で暑い場合には、サッパリしたものが食べたい確率が高いことを表している。
【００２２】
ステータス推定装置２００は、ステータス提供部２１０、ステータス推定部２２０、識別情報取得部２３０、及びステータステーブル２４１を備えている。ステータス提供部２１０は、購読者テーブル２１１、ステータス通知機能２１２、及びステータス提供機能２１３からなる。購読者テーブル２１１は、上記アプリケーションサーバ１００からの購読したいステータスＩＤと通知先ＵＲＬ（対応するアプリケーションサーバ１００のＵＲＬ）とを対応付けて記憶する。ステータス通知機能２１２は、後述するステータス推定機能２２１からステータス値の更新通知を受けると、購読者テーブル２１１にステータスＩＤが登録されたステータスについて、ステータステーブル２４１から対応するステータス値を取得し、購読者テーブル２１１に登録されている、ステータスＩＤに対応付けられた通知先ＵＲＬにステータス値を通知する。ステータス提供機能２１３は、アプリケーションサーバ１００からのステータスＩＤを受信し、対応するステータス値をステータステーブル２４１から取得し、アプリケーションサーバ１００に送信する。
【００２３】
ステータス推定部２２０は、ステータス推定機能２２１、及び確率グラフＤＢ（データベース）２２２からなる。ステータス推定機能２２１は、後述する識別情報受信機能２３２からの通知を受けると、確率グラフＤＢ２２２の条件付確率表を用いて、ステータステーブル２４１に保存されたステータス値を観測値としてベイジアンネットワークを用いた通常の確率伝搬アルゴリズムを実行する。これによって、ステータス推定機能２２１は、受信ステータスＩＤに対応するステータス値に加え、推定ステータスＩＤに対応するステータス値を取得し、推定ステータスＩＤに対応するステータス値をステータステーブル２４１に登録するとともに、ステータス提供部２１０にステータス値の更新を通知する。
なお、ステータス値は、そのステータスの状態にない場合に、「０（励起せず）」、そのステータスの状態である場合に、「１（励起）」となる。
【００２４】
識別情報取得部２３０は、識別情報取得機能２３１、及び識別情報受信機能２３２からなる。識別情報取得機能２３１は、ステータステーブル２４１のステータスが削除される際に、ステータス登録者からステータスを取得する。識別情報受信機能２３２は、識別情報生成装置３００から送信されるステータスＩＤとステータス値を受信し、ステータステーブル２４１に登録して記憶させる。登録の際、ステータスＩＤに対応するステータス値が一致する場合には、タイムスタンプだけを更新し、以降の処理は行わない。一致しない場合には、上書きし、上述したステータス推定機能２２１に対し、ステータスの登録を行ったことを通知する。なお、ステータステーブル２４１への登録の詳細については後述する。
【００２５】
識別情報生成装置３００は、ユーザの持つ時計、ＧＰＳ（Global Positioning System）、温度計、湿度計等を想定しており、ステータス推定装置２００に定義されたステータスＩＤのうち、管理している生データ取得機能３３１が取得可能な生データと対応するステータスＩＤを抽出し、このステータスＩＤ毎に０（励起せず）や、１（励起）に対応する生データ集合を定義する。例えば、ＧＰＳでは、図４に示すように、緯度経度とステータスＩＤとを対応付け、観測された緯度経度に対応するステータスＩＤのステータス値が１、それ以外のステータスＩＤのステータス値が０となる。
【００２６】
識別情報生成装置３００は、識別情報提供部３１０、識別機能３２１、及び生データ取得機能３３１を備えている。識別情報提供部３１０は、識別情報通知機能３１１、識別情報提供機能３１２、及び識別情報キャッシュ３１３からなる。識別情報通知機能３１１には、識別したステータスＩＤとステータス値とを通知する先のステータス推定装置２００が設定されている。該識別情報通知機能３１１は、後述する識別機能３２１から送信されるステータス値を、識別情報キャッシュ３１３に保存された前回のステータス値と比較し、前回のステータス値と一致すれば、次の生データ取得まで処理を休止し、ステータス値が前回と異なれば、識別情報キャッシュ３１３に保存されたステータス値を上書きするとともに、ステータスの登録を通知する。識別情報提供機能３１２は、設定されたステータス推定装置２００にステータスＩＤとステータス値とを提供する。
【００２７】
生データ取得機能３３１は、逐次、生データ（時計、ＧＰＳ、温度計、湿度計などの値）を取得し、識別機能３２１に送信する。識別機能３２１は、生データを受信すると、生データと関連するステータス値を求め、上述する識別情報提供部３１０に送信する。例えば、ここで想定する識別情報生成装置３００のそれぞれの識別機能３２１では、以下のステータス値が計算される。
【００２８】
・時計：「ＡＭ１２時」という生データから「昼」：「１」、「朝」等：「０」
・ＧＰＳ：「３５．８２０１，１３９．５７」という生データから「外出中」：「０」、「会社」等：「０」
・温度計：「２７℃」という生データから「暑い」：「１」、「快適」等：「０」
・湿度計：「８０％」という生データから「乾燥」：「０」、「快適」等：「０or１」
【００２９】
なお、上述した説明では、識別情報生成装置３００内の識別機能３２１が「朝」と「昼」など、複数のステータスの間でステータス値が「１」となるものが排他的なステータスの処理を、識別機能３２１内でステータス値が「０」となる生データの集合も定義することで対応している。実際には、これらの機能をステータス推定装置２００が備え、ステータス推定装置２００に送信される情報は、ステータス値が「１」のもの、すなわち、識別されたステータスＩＤのみに限定してもよい。
【００３０】
また、図１では、アプリケーションサーバ１００とステータス推定装置２００、識別情報生成装置３００とがそれぞれの外部に書かれているが、図５、図６、図７に示すように、それぞれが他の装置を包含する形態も考えられる。例えば、図５に示す構成例では、ステータス推定装置２００を複数とし、それぞれのステータス推定装置２００、２００に対して、アプリケーションサーバ１００、１００、１００、識別情報生成装置３００、３００、３００が重畳して接続されている。また、図６に示す構成例では、アプリケーションサーバ１００内にステータス推定装置２００を包含する構成としている。また、図７に示す構成例では、識別情報生成装置３００内にステータス推定装置２００を包含する構成としている。なお、以下では、説明の簡略化のため、図１の場合についてのみ説明する。
【００３１】
また、本発明のステータス推定システムは、本来複数のユーザを収容するものであるが、説明の簡略化のため、以降では、１ユーザのみを収容しているものとして説明する。実際のステータス推定システムを構築する際には、以降で送受信されるステータスＩＤにユーザＩＤも含まれるとすればよい。
【００３２】
次に、本実施形態の動作について説明する。
まず、ステータス推定装置２００の設定について説明する。
ステータス推定装置２００では、識別情報生成装置３００から受信する受信ステータスＩＤ、及び、それを用いて推定する推定ステータスＩＤを定義し、さらに、図２に示すようなステータス間の相関を表すグラフと、図３に示すようなステータス間の条件付確率表とを作成し、確率グラフＤＢ２２２に設定する。
【００３３】
一方、識別情報生成装置３００では、ステータス推定装置２００が定義したステータスＩＤのうち、管理している生データ取得機能３３１が取得可能な生データと対応するステータスＩＤを抽出し、このステータスＩＤ毎に「０（励起せず）」や、「１（励起）」に対応する生データ集合を定義する。また、識別情報通知機能３１１には、識別したステータスＩＤとステータス値とを通知する先のステータス推定装置２００を設定する。
上記設定によって、ステータス推定装置２００が、ステータスを推定する準備が整うので、以下、ステータスがアプリケーションサーバ１００に通知される様子を説明する。
【００３４】
まず、アプリケーションサーバ１００は、購読者テーブル２１１に、購読したいステータスＩＤと自らのステータス受信部のＵＲＬを登録することで、ステータス変化の通知購読を行う。例えば、「サッパリしたものが食べたい」状況を知りたければ、そのステータスＩＤと自らのＵＲＬとを対応付けて登録すればよい。
一方、識別情報生成装置３００、３００、３００では、各々、生データ取得機能３３１により逐次生データを取得し、識別機能３２１に送信する。識別機能３２１は、生データを受信すると、生データと関連するステータス値を求める。
【００３５】
識別情報通知機能３１１では、識別機能３２１から受信したステータスＩＤ、ステータス値を識別情報キャッシュ３１３に保存された前回のステータス値と比較する。前回のステータス値と一致すれば、次の生データ取得まで、処理は休止し、ステータス値が前回と異なれば、識別情報キャッシュ３１３に保存されたステータス値を上書きするとともに、ステータス推定装置２００へステータスの登録を通知する。例えば、「ＡＭ１２時」の場合には、識別情報キャッシュ３１３の「朝」が０に、「昼」が１に書き換えられ、ステータス推定装置２００に送信される。
【００３６】
ここで、図８は、上述した識別情報生成装置３００での処理の流れを説明するためのフローチャートである。まず、定期的な生データを取得し（ステップＳ１）、生データが含まれるカテゴリを識別し、対応するステータスＩＤのステータス値を「１」とし（ステップＳ２）、上記ステータスＩＤとステータス値が排他的なもののステータス値を「０」とする（ステップＳ３）。次に、上記２つのステータス値が全てキャッシュと一致するか否かを判断し（ステップＳ４）、一致した場合には、次の生データ取得まで、処理は休止し、ステップＳ１の生データの取得に戻る。一方、一致しない場合には、不一致のステータス値（新たなステータス値）で識別情報キャッシュ３１３のキャッシュ（前回のステータス値）に上書きし（ステップＳ５）、不一致のステータス値を、事前に設定されたステータス推定装置２００に送信する（ステップＳ６）。その後、ステップＳ１の生データの取得に戻る。
【００３７】
次に、ステータス推定装置２００の識別情報受信機能２３２では、識別情報生成装置３００からのステータス値を受信し、ステータステーブル２４１に登録する（テーブル構造とともに図９に示す）。登録の際、ステータスＩＤに対応するステータス値が一致する場合には、タイムスタンプだけを更新し、以降の処理は行わない。そうでない場合には、上書きし、ステータス推定機能２２１に対し、ステータスの登録を行ったことを通知する。
【００３８】
ステータス推定機能２２１は、この通知を受けると、確率グラフＤＢ２２２の情報を用いて、ステータステーブル２４１に保存されたステータス値を観測値としてベイジアンネットワークを用いた通常の確率伝搬アルゴリズムを実行し、受信ステータスＩＤに対応するステータス値に加え、推定ステータスＩＤに対応するステータス値を取得する。その後、ステータス推定機能２２１は、推定ステータスＩＤに対応するステータス値をステータステーブル２４１に登録するとともに、ステータス提供部２１０にステータス値の更新を通知する。
【００３９】
例えば、時刻「ＡＭ１２時」、緯度経度「３５．８２０１，１３９．５７」、温度「２７℃」、湿度「８０％」の場合には、推定装置２００は、「昼＝１」、「外出中＝１」、「暑い＝１」、「乾燥＝０」などを受信し、図２、図３のベイジアンネットワークから「サッパリしたものが食べたい」や、「空腹」のステータス値が高く、「コッテリしたものが食べたい」や、「プライベート」のステータス値が低く計算され、ステータステーブル２４１に登録される。
【００４０】
ステータス値の更新通知を受けたステータス提供部２１０内のステータス通知機能２１２は、購読者テーブル２１１にステータスＩＤが登録されたステータスについて、ステータステーブル２４１から対応するステータス値を取得し、購読者テーブル２１１に登録される、ステータスＩＤと対応付けられた通知先ＵＲＬへステータス値を通知する。この例では、「サッパリしたものが食べたい」というステータスが０．８等の高い値であることが通知される。
アプリケーションサーバ１００では、「サッパリしたものが食べたい」と判断すると、対応する店舗をユーザに推薦すればよい。
【００４１】
上述した例は、アプリケーションが「サッパリしたものを出す店」を推薦するものであったが、実際には、グルメ系だけでなく、地域の店舗全般を推薦するアプリケーションが考え得る。この場合には、上記と同様に、「空腹」等のステータスが通知されたのち、実際、どんなものを食べたいかを知ることが考えられる。
そこで、以下では、アプリケーションサーバ１００からステータス推定装置２００に「サッパリしたものが食べたい」、及び「コッテリしたものが食べたい」を要求した場合の処理の流れを説明する。
【００４２】
上述した説明と異なる点は、アプリケーションサーバ１００とステータス推定装置２００との間の送受信、ステータス推定装置２００と識別情報生成装置３００との間の送受信である。これまでの説明では、ステータス推定装置２００からアプリケーションサーバ１００へ、識別情報生成装置３００からステータス推定装置２００へと通知していたが、以降では、逆側から要求し、それに対して提供する形態となる。そこで、ステータス提供機能２１３と識別情報提供機能３１２との動作についてのみ説明する。残りの機能の動作は、上述した説明と同様である。
【００４３】
まず、アプリケーションサーバ１００から「サッパリしたものが食べたい」、「コッテリしたものが食べたい」を要求されると、ステータス提供機能２１３は、ステータステーブル２４１からステータスＩＤに対応するタイムスタンプを参照する。このタイムスタンプが事前に設定された値域（例えば、現在時刻から５時間以内）に含まれる場合には、その値をステータステーブル２４１から取得し、アプリケーション１００に提供し、以降の処理は行わない。
【００４４】
しかしながら、タイムスタンプが事前の値域に含まれない場合には、例えば、そのステータス値が過去の値であり、現在は信用できないと判断され、その値を推定するか、取得してくることが必要となる。推定する場合には、まず、ステータステーブル２４１から先のステータスＩＤに対応するステータス値を削除し、確率グラフＤＢ２２２から、アプリケーションサーバ１００に要求されたステータスＩＤとリンクパスを示すＵＲＬとが存在するステータスＩＤを元に、ステータステーブル２４１内のタイムスタンプを同様に確認する。結果、有効なタイムスタンプを持つレコードのみを残し、ステータス推定機能２２１に対し、アプリケーションサーバ１００から要求されたステータスを推定するように要求し、結果をアプリケーションサーバ１００に提供する。
【００４５】
上述した処理のいずれかにおいて、タイムスタンプが有効でないとされた場合には、該当する識別情報生成装置３００から取得することもできる。ステータステーブル２４１には、識別情報受信機能２３２が登録した、ステータス値を登録した識別情報生成装置３００のＵＲＬが登録されているので、この情報を用いて識別情報生成装置３００に、ステータスＩＤを用いてステータス値を要求する。識別情報生成装置３００がステータスの要求を受けた場合には、先の説明と同様の処理によって、ステータス値を生成し、ステータス生成装置２００に応答する。以上によって、アプリケーションサーバ１００からの個別のステータス取得要求に応じることができる。
【００４６】
なお、上述した実施形態では、識別情報生成装置３００の例にセンサドライバを挙げたが、実際には、生データがＷｅｂ上での検索キーワード（「Ａ株式会社」等）や、閲覧ＵＲＬ、ステータスが「Ａ株式会社について知りたい」等であってもよい。
【００４７】
上述した実施形態によれば、推定に多数の生データを必要とするステータスの推定においても、多様な生データ形式をステータスの励起如何という形式に統一して収集し、そのステータス励起間の条件付確率を用いて統一的・汎用的に推論を行うことによって、該当ステータスを推定することができるようになる。これによって、利用可能なステータスが多様化し、いわゆるコンテキストアウェアアプリケーションや、プレゼンスサービスが実現できるようになる。
【００４８】
すなわち、上述した実施形態によれば、センサ類からの生データ形式の差異吸収については、センサ類内に存在する、もしくは、密に結合された（もちろん、ネットワークを経由してもよい）センサ情報処理機能の存在を前提とする。この機能には、予め生データのカテゴリ（複数カテゴリへ属することを許す）が設定されており、センサ類によって取得された生データがどのカテゴリ（複数でもよい）に属するかを識別する。これによって、取得された生データによって、あるカテゴリに対応するステータスが励起したという考え方をする。例えば、生データとして緯度経度が「３５．４２０１，１３９．５６３３０２」と得られた場合に、これが会社というカテゴリに分類されることが識別され、結果、会社にいるというステータスが現在励起しているということが判定される。すなわち、生データの形式差異の吸収のためには、センサ毎に存在するセンサ情報処理機能によってステータスの励起如何という統一形式に変換するという手法をとる。
【００４９】
また、不特定多数のセンサ類を用いた推定ロジックについては、ステータス間の確率的相関を用いた推定ロジックを用いる。既存の推定ロジックでは、データ毎に写像を定義し、その写像の値域を分割し、どの分割に属するかによって推定されるのが主流であった。しかし、これは、データ毎の事前知識がなければ写像が定義できない。そこで、本実施形態では、各ステータスの励起如何がセンサ類から取得できるものとしたので、それぞれのステータスが励起したときに、その他のステータスが励起する条件付確率を定義し、この確率分布によって推論ロジックを定義したものとする。この場合、それぞれのセンサ類を意識することなく、汎用的に同様のロジックを用いたステータス推論を実現することができる。
【図面の簡単な説明】
【００５０】
【図１】本発明の実施形態によるステータス推定システムの構成を示すブロック図である。
【図２】本実施形態による、ステータス間の相関を表すグラフの一例を示す概念図である。
【図３】本実施形態による、ステータス間の条件付確率表の一例を示す概念図である。
【図４】センサとしてＧＰＳを想定した場合の緯度経度とステータスＩＤとの対応例を示す概念図である。
【図５】本実施形態によるステータス推定システムの他の構成例を示すブロック図である。
【図６】本実施形態によるステータス推定システムの他の構成例を示すブロック図である。
【図７】本実施形態によるステータス推定システムの他の構成例を示すブロック図である。
【図８】本実施形態による識別情報生成装置の動作を説明するためのフローチャートである。
【図９】本実施形態による、ステータス推定システムにイベント情報が入力された際のステータステーブルの構造を示す概念図である。
【符号の説明】
【００５１】
１００  アプリケーションサーバ
２００  ステータス推定装置
２１０  ステータス提供部
２１１  購読者テーブル
２１２  ステータス通知機能
２１３  ステータス提供機能
２２０  ステータス推定部
２２１  ステータス推定機能
２２２  確率グラフＤＢ
２３０  識別情報取得部
２３１  識別情報取得機能
２３２  識別情報受信機能
２４１  ステータステーブル
３００  識別情報生成装置
３１０  識別情報提供部
３１１  識別通知機能
３１２  識別提供機能
３１３  識別情報キャッシュ
３２１  識別機能
３３１  生データ取得機能
【図１】
2010044680.tif 000003
【図２】
2010044680.tif 000004
【図３】
2010044680.tif 000005
【図４】
2010044680.tif 000006
【図５】
2010044680.tif 000007
【図６】
2010044680.tif 000008
【図７】
2010044680.tif 000009
【図８】
2010044680.tif 000010
【図９】
2010044680.tif 000011