JP6030664B2 - ルールに基づくコンテキスト取得のための方法 - Google Patents

Description

携帯電話のような多くのモバイル・コンピューティング・デバイスは、動的フィードバックをユーザに提供するために、様々なコンテキスト・アウェア・アプリケーションを使用するように構成されている。本明細書で使用されるとき、「コンテキスト・アウェア」という用語は、変化する環境を検出又は検知して適切に反応するように、モバイル・コンピューティング・デバイスに実装される、特定のアプリケーション又はプログラムの機能を指す。このようなコンテキスト・アウェア・アプリケーションは、多くの場合、ユーザのコンテキストを連続して、又は頻繁に検知することに依拠する。ユーザのコンテキストには、例えば特に、場所、交通手段（transportation mode）、ユーザのグループ状態又はユーザの作業状態のような情報が含まれることがある。しかしながら、ユーザのコンテキストを検知することは大量の電池残量を消費する可能性があるので、コンテキスト情報を取得することは、バッテリで動作するモバイル・デバイスにおいて高価なものである可能性がある。

以下は、本明細書に記載される幾つかの態様の基本的な理解を提供するために、本革新の簡単な要約を提示するものである。この要約は、特許請求に係る主題の包括的な概要ではない。特許請求に係る主題の重要な又は本質的な要素を特定することも、本革新の範囲を画定することも意図されていない。その唯一の目的は、後に提示するより詳細な説明の前置きとして、特許請求に係る主題の幾つか概念を簡単な形で提示することである。

一実施形態は、ルールに基づくコンテキスト取得のための方法を提供する。この方法は、コンテキスト取得システムにおいてアプリケーションからターゲット・コンテキストの要求を受け取ることと、ルールベースの推論のキャッシュを使用して、ターゲット・コンテキストに関連するコンテキスト・ルールを識別することとを含む。この方法はまた、以前取得したコンテキスト及び上記コンテキスト・ルールに基づいて、ターゲット・コンテキストの推論値を決定することを含む。ターゲット・コンテキストの推論値が、以前取得したコンテキスト及び上記コンテキスト・ルールに基づいて決定できない場合、この方法は、ルールベースの取得プランナを使用してターゲット・コンテキストの推論値を取得するための検知プラン（sensing plan）の第１のステップを実行することを更に含む。検知プランの第１のステップは、コンテキスト・ルール又はコスト又はその任意の組合せに基づいて決定される。この方法はまた、ターゲット・コンテキストの推論値が得られるまで、検知プランの複数の後続ステップのいずれかを実行することを含む。後続ステップのそれぞれは、コンテキスト・ルール、コスト又は検知プランの前のステップの結果又はその任意の組合せに基づいて個々に決定される。

別の実施形態は、ルールに基づくコンテキスト取得のためのシステムを提供する。このシステムは、アプリケーションからターゲット・コンテキストの要求を受け取り、ターゲット・コンテキストに関連するコンテキスト・ルールを識別するように構成されるルールベースの推論のキャッシュを含み、コンテキスト・ルールは、ルールベースの推論のキャッシュ内に格納される。このシステムはまた、ターゲット・コンテキストの推論値を取得するための検知プランの第１のステップを実行するように構成されたルールベースの取得プランナを含む。検知プランの第１のステップは、コンテキスト・ルール又はコスト又はその任意の組合せに基づいて決定される。ルールベースの取得プランナは更に、検知プランの第２のステップを実行するように構成され、この第２のステップは、コンテキスト・ルール、コスト又は検知プランの第１のステップの結果又はその任意の組合せに基づいて決定される。

さらに、別の実施形態は、コンピュータ読取可能命令を格納するための１つ又は複数の非一時的なコンピュータ読取可能記憶媒体を提供する。コンピュータ読取可能命令は、１つ又は複数の処理デバイスによって実行されるとき、ルールに基づくコンテキスト取得システムを提供する。コンピュータ読取可能命令は、アプリケーションからターゲット・コンテキストの要求を受け付け、ルールベースの推論のキャッシュを使用してターゲット・コンテキストに関連するコンテキスト・ルールに従ってターゲット・コンテキストの推論値を決定しようと試みるように構成されたコードを含む。コンピュータ読取可能命令はまた、コンテキスト・ルールに従って推論値が決定されない場合、ルールベースの取得プランナを使用して検知プランの複数のステップのそれぞれを展開して実行するように構成されるコードを含む。

この「発明の概要」の記載は、以下の「発明を実施するための形態」において更に説明される概念の選択を簡略化した形で紹介するのに提供されている。この「発明の概要」の記載は、特許請求に係る主題の主要な特徴又は本質的な特徴を特定するようには意図されておらず、また、特許請求に係る主題の範囲を限定するように用いられるようにも意図されていない。

ルールに基づくコンテキスト取得方法を実装することができる例示システムのブロック図である。

コンピューティング・システム内に実装することができるコンテキスト取得システムの一実施形態を示す図である。

コンテキスト情報を推論するためのルールを作成するのにコンテキスト取得システム内で使用することができるコンテキスト・ルール・マイナ（context rule miner）の一実施形態を示す図である。

推論によりコンテキスト情報を提供するためにコンテキスト取得システム内で使用することができるルールベースの推論のキャッシュの一実施形態を示す図である。

特定のコンテキスト情報を推論するためのルールを定義するルールベースの推論のキャッシュによって利用可能なＡＮＤ／ＯＲツリーを示す概略図である。

コンテキスト情報を取得するための検知プランを作成するためにコンテキスト取得システム内で使用することができるルールベースの取得プランナの一実施形態を示す図である。

モバイル・コンピューティング環境内のルールに基づくコンテキスト取得のための方法を示すプロセス・フロー図である。

コンピューティング環境内のコンテキスト・アウェア・アプリケーションによって使用されるコンテキスト情報を取得するように適合されたコードを格納する有形のコンピュータ読取可能媒体を示すブロック図である。

コンテキスト取得システムの例示的実施形態を示すブロック図である。

本開示及び図を通して、同様の構成要素及び特徴を指すのに同じ参照符号が使用される。１００番台の数字は最初に図１に見られる特徴を指し、２００番台の数字は最初に図２で見られる特徴を指し、３００番台の数字は最初に図３で見られる特徴を指し、他も同様である。

本明細書に開示される実施形態は、コンテキスト取得システムを使用してコンテキスト情報を決定するための方法及びシステムを示す。コンピューティング・デバイスのユーザが、コンテキスト取得システムにコンテキスト情報を決定する権限を与えることができる。様々な実施形態では、コンテキスト情報は、バイナリ値、すなわち真（ｔｒｕｅ）又は偽（ｆａｌｓｅ）の形とすることができる。例えば特定のコンテキストが、ユーザが運転しているかどうかに関連する場合、ユーザが運転していると判断されると、コンテキストの値は真である。そうでない場合、コンテキストの値は偽である。さらに、一部の実施形態では、コンテキスト情報は、実際の価値（real value）の形とすることができる。

コンテキスト情報は、特定のコンテキスト・アウェア・アプリケーションによって要求される特定のターゲット・コンテキストを含むことができる。ターゲット・コンテキストを、ルールベースの推論のキャッシュ及びルールベースの取得プランナを使用して、コンテキスト取得システムにより決定することができる。ルールベースの推論のキャッシュを使用して、特定のターゲット・コンテキストに関連するコンテキスト・ルールを識別することができる。ここで、コンテキスト・ルールは、特定のターゲット・コンテキストの値を決定するための推論プロシージャを定義する論理式のツリーへと結合され得る。コンテキスト・ルールは、例えばユーザが屋外にいるかどうかを、ユーザが運転中であるか、自宅にいるか又は会議中であるかのような複数の他の条件に基づいて判断するために使用される、論理式を含むことができる。様々な実施形態では、コンテキスト・ルールは、特定のターゲット・コンテキストに応じて、例えばユーザが電話で話しているかどうかなどの一般的なものであってよく、あるいは例えば特定のユーザが特定の連絡相手と電話で話しているかどうかなどの特定的なものであってもよい。ルールベースの推論のキャッシュは、コンテキスト取得システムによって利用されるコンテキスト・ルールを作成するように構成されたコンテキスト・ルール・マイナを含むこともできる。さらに、ルールベースの取得プランナを使用して、ターゲット・コンテキストの推論値を取得するための検知プランを決定して実行することができる。推論値は、コンテキスト・ルールと、可能な複数の検知プロシージャのうちのいずれかから得られる検知されたコンテキストとの双方に基づくものとすることができる。

予備的な事項として、図面の一部は、機能、特徴、モジュール、要素等と様々に呼ばれる１つ又は複数の構造的構成要素のコンテキストにおける概念を説明する。図面に示される様々な構成要素を、例えばソフトウェア、ハードウェア（例えば個別の論理構成要素等）、ファームウェア等によって又はこれらの実装の任意の組合せによって任意の手法で実装することができる。一実施形態では、様々な構成要素は、実際の実装における対応する構成要素の使用を反映してもよい。他の実施形態では、図面に示される任意の単一の構成要素を、複数の実際の構成要素によって実装することが可能である。図面における任意の２つ又はそれ以上の別個の構成要素の描写が、単一の実際の構成要素によって実行される異なる機能を反映してもよい。以下で検討される図１は、図に示す機能を実装するのに使用され得る１つのシステムに関する詳細を提供する。

他の図は、フローチャート形式で概念を説明する。この形式では、ある動作が、ある順序で行われる別個のブロックを構成するものとして説明される。このような実装は例示であって、限定ではない。本明細書に記載される幾つかのブロックを一緒にまとめて単一の動作で実行することができ、幾つかのブロックを、複数の構成要素ブロックに分割することができ、また幾つかのブロックは、並列にブロックを実行することを含め、本明細書に示す順序とは異なる順序で実行されることも可能である。フローチャートに示されるブロックを、ソフトウェア、ハードウェア、ファームウェア、手動処理等又はこれらの実装の任意の組合せによって実装することができる。本明細書で使用されるとき、ハードウェアは、コンピュータ・システム、特定用途向け集積回路（ＡＳＩＣ）のような個別の論理構成要素等、並びにその組合せを含むことができる。

用語に関して、「ように構成される」という文言は、特定された動作を実行するように任意の種類の機能を構築することができる任意の方法を含む。その機能は、例えばソフトウェア、ハードウェア、ファームウェア等又はその任意の組合せを使用して動作を実行するように構成されることが可能である。

「論理」という用語は、タスクを実行するための任意の機能を含む。例えばフローチャートに示される各動作は、その動作を実行するための論理に対応する。動作は、例えばソフトウェア、ハードウェア、ファームウェア等又はその任意の組合せを使用して実行されることが可能である。

本明細書で使用されるとき、「構成要素」、「システム」、「クライアント」等の用語は、コンピュータ関連のエンティティ、すなわちハードウェア、（例えば実行中の）ソフトウェア及び／又はファームウェアのいずれか、あるいはその組合せを指すように意図される。例えば構成要素は、プロセッサで実行中のプロセス、オブジェクト、実行ファイル、プログラム、関数、ライブラリ、サブルーチン及び／又はコンピュータ、あるいはソフトウェアとハードウェアの組合せとすることができる。

例として、サーバで実行中のアプリケーションと、そのサーバの双方を構成要素とすることができる。１つ又は複数の構成要素がプロセス内に存在する可能性があり、１つの構成要素が、１つのコンピュータに局在化されるか、及び／又は２つ若しくはそれ以上のコンピュータ間で分散される可能性がある。「プロセッサ」という用語は、一般的に、コンピュータ・システムの処理ユニットのようなハードウェア構成要素を指すと理解される。

さらに、特許請求に係る主題は、標準的なプログラミング及び／又はエンジニアリング技法を使用して方法、装置又は製品として実装されて、開示する主題を実装するようにコンピュータを制御するソフトウェア、ファームウェア、ハードウェア又はそのいずれかの組合せをもたらすことがある。本明細書で使用されるとき、「製品」という用語は、任意の非一時的なコンピュータ読取可能デバイス又は媒体からアクセス可能なコンピュータ・プログラムを含むように意図される。

非一時的なコンピュータ読取可能媒体には、これらには限られないが、磁気記憶デバイス（例えば特に、ハードディスク、プロッピーディスク及び磁気ストライプ）、光ディスク（例えば特に、コンパクトディスク（ＣＤ）及びディジタル多用途ディスク（ＤＶＤ））、スマートカード、及びフラッシュ・メモリ・デバイス（例えば特に、カード、スティック及びキー・ドライブ）が含まれ得る。対照的に、概してコンピュータ読取可能媒体は、無線信号等のための伝送媒体のような通信媒体を更に含むことがある（すなわち、必ずしも記憶媒体ではない）。

図１は、ルールに基づくコンテキスト取得方法を実装し得る例示的システム１００のブロック図である。ルールに基づくコンテキスト取得方法を使用して、コンテキスト・アウェア・アプリケーションを実行するコストを低減することができる。様々な実施形態において、システム１００は、特に携帯電話、タブレット、携帯情報端末（ＰＤＡ）、電子リーダ又はメディア・プレーヤのような、モバイル・コンピューティング・デバイス内に組み込まれることがある。さらに、一部の実施形態において、システム１００は、コンピューティング・デバイスによって実行されるコンテキスト・アウェア・アプリケーション又はプログラムで使用するためのコンテキスト情報を検知することができる任意のタイプのコンピューティング・デバイスに組み込まれることもある。コンテキスト・アウェア・アプリケーションの一例は、ユーザが特定の場所にいるとき、ある特定のタスクを実行するようにユーザにリマインドするよう構成される「位置ベースのリマインダ」アプリケーションである。別の例は、ユーザが一日を通してどのくらいの運動を行うかをログに記録するように構成される「ランニング・トラッカー」アプリケーションである。さらに別の例は、ユーザの現在の位置、交通手段及びグループ化状態を利用して、ローカル検索の結果又は電話に配信されるクーポンを個人化するように構成される「ローカル検索／クーポン」アプリケーションである。

システム１００は、格納された命令を実行するように適合されたプロセッサ１０２並びにプロセッサ１０２によって実行可能な命令を格納するメモリ・デバイス１０４を含むことができる。プロセッサ１０２は、シングルコア・プロセッサ、マルチコア・プロセッサ、コンピューティング・クラスタ又は任意の数の他の構成とすることができる。メモリ・デバイス１０４は、ランダム・アクセス・メモリ（ＲＡＭ）、読取専用メモリ（ＲＯＭ）、フラッシュ・メモリ又は任意の他の適切なメモリ・システムを含むことがある。これらの命令は、コンテキスト・アウェア・アプリケーションによる使用のため、コンテキスト情報を取得するためにルールベースの方法を実行する。プロセッサ１０２は、バス１０６を介して１つ又は複数の入力デバイス及び出力デバイスに接続され得る。

システム１００はまた、コンテキスト・ルール１１０と、コンテキスト履歴１１２と、コンテキスト取得モジュール１１４とを格納するように適合された記憶デバイス１０８も含むことができる。コンテキスト・ルール１１０及びコンテキスト履歴１１２を使用して、様々なコンテキスト・アウェア・アプリケーションの関連するターゲット・コンテキストを効率的に取得することができる。さらに、コンテキスト取得モジュール１１４を使用して、このようなターゲット・コンテキストを取得するための方法を実行することができる。記憶デバイス１０８はまた、アプリケーション・プログラミング・インタフェース（ＡＰＩ）１１６と、任意の数のアプリケーション１１８とを格納するようにも適合され得る。アプリケーション１１８は、ＡＰＩ１１６を介して互いに通信するコンテキスト・アウェア・アプリケーションとすることができる。記憶デバイス１０８は、ハード・ドライブ、光学式ドライブ、サムドライブ、ドライブのアレイ又はその任意の組合せを含むことができる。

システム１００内のユーザ・インタフェース（ＵＩ）１２０は、システム１００を、特にタッチスクリーン、スピーカ又はポインティング・デバイスのような任意の数のユーザ・インタフェース・デバイス１２２に接続することができる。システム１００は、バス１０６を介して、システム１００をディスプレイデバイス１２６に接続するのに適合されたディスプレイ・インタフェース１２４にリンクされることがあり、ディスプレイデバイス１２６は、特にコンピュータのモニタ又はモバイル・デバイスのディスプレイ画面を含むことができる。さらに、ネットワーク・インタフェース・コントローラ（ＮＩＣ）１２８は、バス１０６を介してシステム１００をネットワーク１３０に接続するように適合されることが可能である。ネットワーク１３０を通じて、ウェブベースのアプリケーション１３２をコンピュータの記憶デバイス１０８内にダウンロードし、格納することができる、又はウェブ・ブラウザを通じてこれにアクセスすることができる。様々な実施形態では、ウェブベースのアプリケーション１３２は、コンテキスト・アウェア・アプリケーションとすることができる。さらに、システム１００による使用のために、ネットワーク１３０を介して電子テキスト及び画像ドキュメント１３４をダウンロードすることができる。

図２は、コンピューティング・システム２０２内に実装され得るコンテキスト取得システム２００の一実施形態である。コンピューティング・システム２０２のユーザは、コンテキスト取得システム２００が固有のコンテキスト情報を決定することを許可することがある。様々な実施形態では、コンピューティング・システム２０２は、コンテキスト情報を検知してコンテキスト・アウェア・アプリケーション若しくはプログラムを実装するように構成されるモバイル・コンピューティング・デバイス内又は任意のタイプのコンピューティング・デバイス内に組み込まれることがある。例えば一部の実施形態では、コンピューティング・システム２０２は、図１に関して説明したシステム１００とすることができる。さらに、コンテキスト取得システム２００は、任意の数のコンテキスト・アウェア・アプリケーション２０４に通信可能に結合されることがある。コンテキスト取得システム２００を使用して、ルールベースのコンテキスト取得プロシージャを通じて、コンテキスト・アウェア・アプリケーション２０４に所望のコンテキスト情報を提供することができる。

様々な実施形態では、ルールベースのコンテキスト取得プロシージャは、コンテキスト取得システム２００によって様々な構成要素を使用して実装され得る。このような構成要素には、特に、ルールベースの推論のキャッシュ２０６、コンテキスト・ルール・マイナ２０８、ルールベースの取得プランナ２１０、分類子格納モジュール２１２、生センサ・データのキャッシュ２１４が含まれ得る。ルールベースの推論のキャッシュ２０６を使用して、コンテキスト・ルールに基づいて所望のコンテキスト情報を推論しようと試みることができる。コンテキスト・ルールは、例えばユーザが運転中であるか、屋外にいるか、屋内にいるか、自宅にいるか又は会議中であるかのような、特定のターゲット・コンテキストの値を定義するのに使用される論理式を含むことができる。

コンテキスト・ルールは、相関ルール・マイニング（association rule mining）アルゴリズムのような複数のデータ・マイニング・アルゴリズムのうちのいずれかを使用して導出され得る。例えば一部の実施形態では、相関ルール・マイニング技法を使用してコンテキスト・ルールを決定するのに、アプリオリ・アルゴリズム（Apriori algorithm）を用いることができる。さらに、このようなコンテキスト・ルールは、コンテキスト履歴に基づいてコンテキスト・ルール・マイナ２０８によって作成することができる。ここで、コンテキスト履歴は、コンテキスト取得プロシージャの以前のインスタンスからデータを検知することを含んでよい。さらに、コンテキスト・ルールは、コンテキスト取得システム２００の開発者からの入力に応答して、あるいは一部の実施形態ではコンピューティング・システム２０２のユーザからの入力に応答して、コンテキスト・ルール・マイナ２０８によって作成されることもある。

コンテキスト取得システム２００は、コンテキスト・ルール・マイナ２０８内のコンテキスト・ルールを生成するために、コンテキスト・アウェア・アプリケーション２０４からの入力に依拠することがある。例えば様々な実施形態では、「ｐｕｔ関数」２１６を使用して、コンテキスト履歴をコンテキスト取得システム２００内に投入することができる。ｐｕｔ関数２１６は、矢印２１８によって示されるように、ルールベースの推論のキャッシュ２０６において、特定のコンテキスト情報に関連する情報、並びにこのようなコンテキスト情報の対応する値を受け取ることを含むことができる。ルールベースの推論のキャッシュ２０６は、将来の利用のために、特定のコンテキスト情報の値を記録することができる。さらに、ルールベースの推論のキャッシュ２０６はまた、新しいコンテキスト・ルールの生成に使用される特定のコンテキスト情報の値を、コンテキスト・ルール・マイナ２０８へ送信することもできる。様々な実施形態では、ｐｕｔ関数２１６から得られる特定のコンテキスト情報は、「コンテキスト履歴」と呼ばれることがある。

ルールベースの推論のキャッシュ２０６は、「ｇｅｔ関数」２２０に応答してコンテキスト取得プロシージャを開始することができる。ｇｅｔ関数２２０は、矢印２１８によって示されるように、ルールベースの推論のキャッシュ２０６においてコンテキスト・アウェア・アプリケーション２０４からの特定のコンテキスト情報の要求を受け取ることを含むことができる。ｇｅｔ関数２２０は、所望のコンテキスト情報又は「ターゲット・コンテキスト」に関連する情報を含むことができる。ルールベースの推論のキャッシュ２０６は、ターゲット・コンテキストの値がルールベースの推論のキャッシュ２０６内に既に存在するかどうかを判断するために、ローカル・ファイルを検索することができる。ターゲット・コンテキストの正確な値がルールベースの推論のキャッシュ２０６内で識別される場合、これはコンテキスト・アウェア・アプリケーション２０４に自動的に返される。しかしながら、ターゲット・コンテキストの正確な値がルールベースの推論のキャッシュ２０６内で見つからない場合、ルールベースの推論のキャッシュ２０６は、矢印２２２によって示されるように、コンテキスト・ルール・マイナ２０８に直接問い合わせて、適切なコンテキスト・ルールがターゲット・コンテキストを取得するために利用可能であるかどうかを判断することができる。さらに、ルールベースの推論のキャッシュ２０６は、矢印２２４によって示されるように、ターゲット・コンテキストの要求を、ルールベースの取得プランナ２１０に転送することもできる。

ルールベースの取得プランナ２１０は、コンテキスト履歴と、コンピューティング・システム内の利用可能なセンサとに基づいて特定のターゲット・コンテキストを取得するためのプランを展開することができる。ルールベースの取得プランナ２１０は、コンテキスト・ルール・マイナ２０８に通信可能に結合され、矢印２２６によって示されるように、ターゲット・コンテキストに関連するコンテキスト・ルールを得るためにコンテキスト・ルール・マイナ２０８と通信することができる。ルールベースの取得プランナ２１０は、ターゲット・コンテキストを取得する検知プランを作成するため、適切なコンテキスト・ルールを使用することができる。一部の実施形態では、矢印２２８によって示されるように、検知プランを分類子格納モジュール２１２に送信し、これにより、検知プランによって指定された各検知プロシージャについて、対応する分類子を識別することができる。例えば検知プランによって指定される分類子は、「Ｉｓ Ｗａｌｋｉｎｇ」分類子２３０又は「Ｉｓ Ａｔ Ｈｏｍｅ」分類子２３２とすることができる。さらに、分類子格納モジュール２１２は、様々なコンテキスト情報に関連する分類子のライブラリを含むことができる。

分類子格納モジュール２１２及び生センサ・データのキャッシュ２１４は、矢印２３４によって示されるように、通信可能に結合され、分類子に関連する情報を交換するように構成され得る。例えば適切な分類子を、分類子格納モジュール２１２から生センサ・データのキャッシュ２１４へ送信することができる。生センサ・データのキャッシュ２１４は、要求された検知プロシージャの結果が、キャッシュ２１４内に既に含まれているかどうかを判断することができる。要求された検知プロシージャの結果が見つかった場合、この結果は、ルールベースの取得プランナ２１０に返され、検知プランの次のステップを決定するのに使用され得る。しかしながら、要求された検知プロシージャの結果が見つからない場合、コンピューティング・システム２０２は、様々なセンサのいずれかを用いて、特定の分類子に関連するコンテキスト情報を得ることができる。例えばＩｓ Ｗａｌｋｉｎｇ分類子２３０がルールベースの取得プランナ２１０によって指定されている場合、加速度計又は全地球測位システム（ＧＰＳ）を調べて、コンピューティング・システム２０２のユーザが歩行中であるかどうかを推定することができる。別の例として、Ｉｓ Ａｔ Ｈｏｍｅ分類子２３２が指定されている場合、マイクロフォン、ＧＰＳ又は加速度計を調べて、コンピューティング・システム２０２のユーザが自宅にいるかどうかを推定することができる。さらに、様々な実施形態では、分類子格納モジュール２１２又は生センサ・データのキャッシュ２１４又はその双方が、ルールベースの取得プランナ２１０内に含まれることがある。

様々な実施形態において、ターゲット・コンテキストの値がコンテキスト取得システム２００によって決定されると、この値は、ｇｅｔ関数２２０を開始したコンテキスト・アウェア・アプリケーション２０４に返されることがある。ターゲット・コンテキストは、コンテキスト・アウェア・アプリケーション２０４の機能を助けるのに用いられることがあり、コンテキスト・アウェア・アプリケーション２０４が動的なフィードバックをコンピューティング・システム２０２のユーザに提供できるようにすることができる。さらに、コンテキスト・アウェア・アプリケーション２０４の挙動は、特定のアプリケーション又は環境に従ってターゲット・コンテキストの値に応じて変更されることがある。

コンテキスト取得システム２００は、図２に示される構成に限定されないことを理解されたい。むしろ、コンテキスト取得システム２００の構成要素は、複数の可能な構成のいずれかの構成で配置されてよい。例えば様々な実施形態では、コンテキスト・ルール・マイナ２０８を、ルールベースの推論のキャッシュ２０６内に含めることができる。一部の実施形態において、ｐｕｔ関数２１６及びｇｅｔ関数２２０は、アプリケーション・プログラミング・インタフェース（ＡＰＩ）を介してコンピューティング・システム２０２内に実装され得る。さらに、図２に関して述べたコンテキスト取得システム２００の構成要素の必ずしもすべてが、あらゆる場合に存在するというわけではなく、任意の数の追加構成要素がシステム２００内に含まれることがある。

図３は、コンテキスト情報を推論するためのルールを作成するのにコンテキスト取得システム２００内で使用され得る、コンテキスト・ルール・マイナ２０８の一実施形態である。同じ番号の項目は、図２に関して述べた通りである。コンテキスト・ルール・マイナ２０８を使用して、コンピューティング・システム２０２によって得られるコンテキスト情報に関連する様々なコンテキスト・ルール３００を作成することができる。このようなコンテキスト情報をコンテキスト履歴３０２と呼ぶことができる。コンテキスト履歴３０２を、コンピューティング・システム２０２によって、特にＧＰＳ、加速度計、マイクロフォン、Ｗｉ−Ｆｉ接続又はタッチスクリーンを含む、様々なセンサのいずれかを使用して得ることができる。さらに、様々な実施形態では、コンテキスト履歴３０２は、矢印３０４によって示されるように、コンテキスト・ルール・マイナ２０８の入力とすることができ、コンテキスト・ルール３００は、矢印３０６によって示されるようにコンテキスト・ルール・マイナ２０８の出力とすることができる。

さらに、一部の実施形態では、コンテキスト・ルール３００は、コンテキスト・ルール・マイナ２０８によって、コンテキスト取得システム２００の開発者の入力に応答して、あるいはコンピューティング・システム２０２のユーザからの直接入力に応答して作成され得る。コンテキスト取得システム２００の開発者によってプログラムされるコンテキスト・ルールは、「汎用コンテキスト・ルール（universal context rule）」と呼ばれ、特定のユーザの入力に応じて作成されるルールは、「個人コンテキスト・ルール（personal context rule）」と呼ばれることがある。さらに、様々な実施形態において、特定のコンピューティング・システムは、製造工程中に汎用コンテキスト・ルールを用いてブーストトラップされることがあり、個人コンテキスト・ルールは、そのコンピューティング・システムによって、ユーザの特徴、環境又は好みが確立されるにつれて時間とともに学習されることがある。

図４は、推論によるコンテキスト情報を提供するためにコンテキスト取得システム２００内で使用され得るルールベースの推論のキャッシュ２０６の一実施形態である。同じ番号の項目は、図２及び図３に関して述べた通りである。図２に関して述べたように、ルールベースの推論のキャッシュ２０６は、矢印４００によって示されるように、ｐｕｔ関数２１６から得られるコンテキスト情報を用いることができる。このようなコンテキスト情報には、コンピューティング・システム２０２内で見つかった複数のセンサのいずれかから取得される、検知コンテキスト４０２を含むことができる。様々な実施形態では、検知コンテキスト４０２の値は、矢印４０６によって示されるように、推論エンジン４０４内に格納され、これにより、同じ値を有する後続のターゲット・コンテキストを自動的に返すことが可能になる。さらに、検知コンテキスト４０２は、矢印４０８によって示されるように、ルールベースの推論のキャッシュ２０６内にコンテキスト履歴３０２として格納され得る。様々な実施形態では、コンテキスト・ルール・マイナ２０８は、ルールベースの推論のキャッシュ２０６内に組み込まれることがあり、矢印４１０によって示されるようにコンテキスト履歴３０２を入力として直接受け取り、矢印４１２によって示されるようにコンテキスト・ルール３００を出力として作成することができる。

図２に関連して述べたように、ルールベースの推論のキャッシュ２０６は、ｇｅｔ関数２２０から得られる特定のターゲット・コンテキストの要求に応答してコンテキスト取得プロシージャを開始することができる。様々な実施形態では、ｇｅｔ関数２２０は、矢印４１４によって示されるように、特定のターゲット・コンテキストの要求をルールベースの推論のキャッシュ２０６へ直接送信することができる。ルールベースの推論のキャッシュ２０６は、検知されたコンテキストを検索して、ターゲット・コンテキストの正確な値が既に得られたかどうかを判断することができる。ターゲット・コンテキストの正確な値が見つからない場合、ルールベースの推論のキャッシュ２０６は、要求を推論エンジン４０４に転送することができる。様々な実施形態において、推論エンジン４０４は、矢印４１６によって示されるように、コンテキスト・ルール・マイナ２０８によって生成されるコンテキスト・ルール３００を利用するように構成され得る。推論エンジン４０４を使用して、矢印４２０によって示されるように、コンテキスト・ルール３００と検知されたコンテキスト４０２とに基づいて、推論コンテキスト４１８を生成することができる。様々な実施形態において、推論コンテキスト４１８は、ターゲット・コンテキストの推論値に等しい可能性がある。さらに、推論エンジン４０４によって生成される推論コンテキスト４１８は、矢印４２２によって示されるように、ｇｅｔ関数２２０によって要求されるターゲット・コンテキストの値として出力され得る。

様々な実施形態において、ルールベースの推論のキャッシュ２０６は、コンテキスト・ルール・マイナ２０８によって生成されるコンテキスト・ルール３００を使用して、可能な各コンテキスト値について特定のコンテキスト・ルールを定義する、論理式又は論理演算のツリーを作成することができる。例えば特定の論理式のツリーは、ターゲット・コンテキストの特定の推論値に対するコンテキスト・ルールを指定することができる。各論理式のツリーは、複数の関連するコンテキスト・ルール３００の組合せを含むことができる。さらに、論理式のツリーは、ブール式に基づくものとすることができ、ブール式は、評価されるとき真（ｔｒｕｅ）又は偽（ｆａｌｓｅ）の値を生成する論理式である。一部の実施形態では、論理式のツリーは、図５に関して以下に述べるように、ＡＮＤ／ＯＲツリーとすることができる。

図５は、特定のコンテキスト情報を推論するためのルールを定義するために、ルールベースの推論のキャッシュ２０６によって利用可能であるＡＮＤ／ＯＲツリー５００の概略図である。同じ番号の項目は、図２、図３及び図４に関して述べた通りである。ＡＮＤ／ＯＲツリー５００を使用して、「Ｉｎｄｏｏｒ（屋内）：Ｔｒｕｅ」というターゲット・コンテキスト値５０２を定義することができ、Ｉｎｄｏｏｒ：Ｔｒｕｅというターゲット・コンテキスト値５０２は、ユーザが屋内にいることを示す。しかしながら、ルールベースの推論のキャッシュは、各ターゲット・コンテキスト値について同様のＡＮＤ／ＯＲツリーを含んでもよい。例えば「Ｉｎｄｏｏｒ：Ｆａｌｓｅ」というターゲット・コンテキスト値に対して別個のＡＮＤ／ＯＲツリーが存在し得る。

ＡＮＤ／ＯＲツリー５００は、論理演算に基づいてＩｎｄｏｏｒ：Ｔｒｕｅというターゲット・コンテキスト値５０２の論理定義を提供することができる。論理演算は、ＡＮＤ演算子５０４及びＯＲ演算子５０６を含む、論理演算子を使用して実行され得る。ＡＮＤ演算子５０４は、２つの可能な値の双方について肯定的、すなわち「真」の結果が、ＡＮＤ演算の肯定的、すなわち真の結果を確立することを示すことができる。例えば「Ｄｒｉｖｉｎｇ（運転中）：Ｆａｌｓｅ」というコンテキスト値５０８及び「Ｗａｌｋｉｎｇ（歩行中）：Ｆａｌｓｅ」というコンテキスト値５１０は、ＡＮＤ演算の肯定的な結果を構成する。別の例として、「Ａｌｏｎｅ（１人）：Ｆａｌｓｅ」というコンテキスト値５１２及び「Ｗａｌｋｉｎｇ：Ｆａｌｓｅ」というコンテキスト値５１４もまた、図５に示すように、ＡＮＤ演算の肯定的な結果を構成することができる。

ＯＲ演算子５０６は、２つまたはそれ以上の可能な値のいずれかに対する肯定的すなわち真の結果が、ＯＲ演算に対する肯定的すなわち真の結果を確立することを示すことができる。したがって、ＯＲ演算子５０６から分岐している可能なコンテキスト値のうちの１つが真である場合、Ｉｎｄｏｏｒ：Ｔｒｕｅというターゲット・コンテキスト値５０２もまた真であることが確認され得る。例えばＩｎｄｏｏｒ：Ｔｒｕｅというコンテキスト値５１６が真である場合、Ｉｎｄｏｏｒ：Ｔｒｕｅというターゲット・コンテキスト値５０２は真であるという結果になる。さらに、「Ａｔ Ｈｏｍｅ（自宅にいる）：Ｔｒｕｅ」というコンテキスト値５１８、「Ｉｎ Ｍｅｅｔｉｎｇ（会議中）：Ｔｒｕｅ」というコンテキスト値５２０又は「Ｉｎ Ｏｆｆｉｃｅ（オフィスにいる）：Ｔｒｕｅ」というコンテキスト値５２２が真である場合、Ｉｎｄｏｏｒ：Ｔｒｕｅというターゲット・コンテキスト値５０２もまた真であると推論することができる。この推論は、ユーザが自宅にいる、会議中である又はオフィスにいるということと、屋外にいるということは、同時にはありそうにない又はあり得ないという事実に基づくことができる。したがって、ユーザは屋内にいる（indoor）と推論することができる。さらに、ユーザは、ユーザが運転中でもなく歩行中でもないか、又は１人でもなく歩行中でもない場合も、屋内にいると推論され得る。

様々な実施形態では、ＡＮＤ／ＯＲツリー５００を、特定の個人及び各ユーザの環境特性に合わせることができる。さらに、ＡＮＤ／ＯＲツリー５００内の一部の論理要素を、普遍的であると想定することができ、いずれかの検知されるコンテキスト４０２の収集の前にユーザのコンピューティング・デバイスにあらかじめプログラムすることができる。例えばユーザが運転中である場合、ユーザが歩行中でもあることはないと普遍的に想定され得る。

一部の実施形態では、ＡＮＤ／ＯＲツリー５００のような論理式のツリーを正規化して、短縮バージョンの論理式のツリーを作成することができる。例えばブール式の標準的なルールを利用して、論理式のツリー内の冗長を取り除くことができる。これは、論理式のツリー内でＡＮＤレベルとＯＲレベルを交互にすることによって、あるいは論理式のツリー内で冗長式を吸収するか又は折り畳むことによって、実現され得る。

図６は、コンテキスト情報を取得するための検知プランを作成するコンテキスト取得システム２００内で使用され得るルールベースの取得プランナ２１０の一実施形態である。同じ番号の項目は、図２、図３、図４及び図５に関して述べた通りである。ルールベースの取得プランナ２１０は、ルールベースの推論のキャッシュ２０６から又は直接コンテキスト・アウェア・アプリケーション２０４から、特定のターゲット・コンテキスト６００の要求を受け取ることができる。さらに、ルールベースの取得プランナ２１０は、キャッシュされたセンサ・データ６０２、キャッシュされたコンテキスト６０４、コンテキスト履歴３０２、検知コスト６０６又はコンテキスト・ルール３００、又はそのいずれかの組合せのような様々な入力を受け取ることができる。キャッシュされたセンサ・データ６０２は、ｐｕｔ関数２１６の複数のインスタンスから得られる検知されたコンテキスト４０２に関連する格納されたデータを含むことができる。キャッシュされたコンテキスト６０４は、ｇｅｔ関数２２０の複数のインスタンスから得られる推論されたコンテキスト４１８に関連するデータを含むことができる。検知コスト６０６は、様々な可能な検知プロシージャのそれぞれの計算コスト又はバッテリコストを含むことがある。さらに、各センサは、指定された動作コストを有することがある。様々な実施形態では、例えばＧＰＳセンサの計算コストは、マイクロフォン・センサの計算コストよりも高い可能性がある。

ルールベースの取得プランナ２１０は、動的な検知プランを提供するために、条件付きプランニング技法を利用することがある。一部の実施形態では、ルールベースの取得プランナ２１０は、例えば相関ルール・マイニング・アルゴリズムのような動的プログラミングに基づくソリューションに従って、検知プランを展開することができる。検知プランは、ルールベースの取得プランナ２１０に通信可能に結合された検知プラン実行モジュール６０８によって実装され得る。検知プラン実行モジュール６０８は、コンピューティング・システム２０２内の検知プロシージャを実行するように構成され得る。検知プロシージャには、例えばＧＰＳデバイスを使用してＧＰＳ位置を決定すること、加速度計を使用して加速度を測定すること又はマイクロフォンを使用して室内に複数の人々がいるかどうかを判断することが含まれる。

さらに、条件付きプランニング技法は、「次のテスト（ｎｅｘｔ ｔｅｓｔ）」関数６１０を含むことがあり、次のテスト関数６１０は、検知プランの次のステップを指定することができる。一部の実施形態では、検知プランの各ステップを、検知コスト６０６と、コンテキスト・ルール３００と検知プランの前のステップの結果とに基づいて、ルールベースの取得プランナ２１０によって決定することができる。検知プランの前のステップの結果は、「テスト結果（ｔｅｓｔ ｒｅｓｕｌｔ）」関数６１２によってルールベースの取得プランナ２１０に提供されることがある。さらに、キャッシュされたセンサ・データ６０２、キャッシュされたコンテキスト６０４又はコンテキスト履歴３０２、又はそのいずれかの組合せを、ルールベースの取得プランナ２１０によって利用して、検知プランの各ステップを決定することもできる。一部の実施形態では、次のテスト関数６１０及び次の結果関数６１２は、検知プラン実行モジュール６０８によって実行されることがある。

図７は、モバイル・コンピューティング環境内におけるルールに基づくコンテキスト取得の方法７００を示すプロセス・フロー図である。モバイル・コンピューティング環境は、コンテキスト・アウェア・アプリケーション又はプログラムを実行することができる任意のタイプのモバイル・デバイス又はシステムを含んでよい。さらに、一部の実施形態では、方法７００は、特に家庭内のコンピューティング・システム、テレビ又はデスクトップ・コンピュータのような、非モバイル・コンピューティング環境内におけるルールに基づくコンテキスト取得に使用することができる。

様々な実施形態において、方法７００に従って取得又は推論され得るコンテキストは、特定のユーザの環境、特徴又は好みに関連する任意のタイプの非決定的な、すなわち可変の情報を含むことがある。方法７００を使用して、特定のアプリケーションに所望のターゲット・コンテキストを提供することができる。例えばアプリケーションが、ユーザが屋内にいるか屋外にいるか、自宅にいるか会議中であるか、あるいは運転中であるか歩行中であるかを知りたいことがある。アプリケーションは、各特定のターゲット・コンテキストの要求を送信することによって、方法７００に従ってこのようなコンテキスト情報を取得することができる。例えばあるターゲット・コンテキストは、ユーザが屋外にいるかどうかについてのものとし、別のターゲット・コンテキストは、ユーザが会議中であるかどうかについてのものとすることができる。さらに、各ターゲット・コンテキストの値は、真又は偽とすることができる。例えばユーザが屋外にいる場合、対応するターゲット・コンテキストの値を真とすることができる。様々な実施形態では、方法７００は、ターゲット・コンテキストの正確な値を利用できないことがあるので、ターゲット・コンテキストの推論値を生成することがある。ターゲット・コンテキストの推論値は、ターゲット・コンテキストに関連する特定のコンテキスト・ルールに基づくものとすることができる。

方法７００はブロック７０２で開始し、ブロック７０２では、コンテキスト取得システムにおいてアプリケーションからターゲット・コンテキストの要求を受け取る。この要求は、アプリケーションが望む特定のターゲット・コンテキストを指定することがある。様々な実施形態において、アプリケーションは、アプリケーション・プログラミング・インタフェース（ＡＰＩ）を介してコンテキスト取得システムと通信することができる。ＡＰＩを、モバイル・コンピューティング環境内に格納することができる。具体的には、アプリケーションは、ＡＰＩを介して、ルールベースの推論のキャッシュ又はルールベースの取得プランナ、又はその双方と直接に通信することができる。

ブロック７０４において、ターゲット・コンテキストに関連するコンテキスト・ルールが、ルールベースの推論のキャッシュを使用して識別され得る。ターゲット・コンテキストに関連するコンテキスト・ルールは、コンテキスト・ルール・マイナによって生成され、かつルールベースの推論のキャッシュによってターゲット・コンテキストに関するコンテキスト・ルールのそれぞれの間の関係に従って編成される、複数のコンテキスト・ルールを含むことがある。さらに、ルールベースの推論のキャッシュは、コンテキスト取得システム内の構成要素とすることができ、コンテキスト・ルール・マイナ及び推論エンジンを含むことができる。コンテキスト・ルール・マイナを使用して、コンテキスト履歴に基づいてコンテキスト・ルールを生成することができ、コンテキスト履歴は、検知されたコンテキストを使用して決定されることがある。検知されたコンテキストは、検知プロシージャから得られたデータを含むことができる。様々な実施形態では、検知プロシージャは、モバイル・コンピューティング環境内のセンサの使用を含む任意のプロシージャを含むことができる。センサの例には、特にＧＰＳデバイス、加速度計、スピーカ、マイクロフォン、タッチスクリーン、カメラ、光インジケータ又はＷｉ−Ｆｉ接続が含まれる。

一部の実施形態において、ルールベースの推論のキャッシュは、コンテキスト・ルール・マイナによって生成されたコンテキスト・ルールを利用して、可能な各ターゲット・コンテキストの論理式のツリーを作成することができる。論理式のツリーは、論理演算に基づいて特定のターゲット・コンテキストを定義するフローチャートとすることができる。論理演算を使用して、推論に基づいてターゲット・コンテキストの値を決定することができる。ターゲット・コンテキストの値を推論することで、実行される検知プロシージャの数を減らすことによって、ターゲット・コンテキストを決定するための計算コスト又はバッテリコストを低減することができる。一部の実施形態では、ターゲット・コンテキストの正確な値がルールベースの推論のキャッシュ内に含まれる場合、正確な値をアプリケーションに自動的に返すことができる。

ブロック７０６において、ターゲット・コンテキストの推論値を、以前取得したコンテキスト及びターゲット・コンテキストに関連するコンテキスト・ルールに基づいて決定することができる。以前取得したコンテキストには、例えばコンテキスト履歴と、開発者によって組み込まれたあらかじめプログラムされたコンテキストとが含まれる。いずれの検知プロシージャも実行することなくターゲット・コンテキストの推論値を得ることができる場合、方法７００はブロック７０６において終了し、ターゲット・コンテキストの推論値をアプリケーションに返すことができる。一部の実施形態において、ターゲット・コンテキストの正確な値又は推論値は、コンテキスト取得システムからアプリケーションへＡＰＩを介して送信され得る。しかしながら、ターゲット・コンテキストの正確な値又は推論値が、ルールベースの推論のキャッシュによって直接決定されない場合、方法７００はブロック７０８において継続する。

ブロック７０８において、検知プランの第１のステップが、ルールベースの取得プランナによって実行され得る。検知プランの第１のステップを、ターゲット・コンテキストに関連するコンテキスト・ルール又はコスト、又はその任意の組合せに基づいて決定することができる。コストは、計算コスト、又はターゲット・コンテキストに関連するセンサ・データを取得するエネルギー若しくはバッテリコストを含むことがある。第１のステップは、ターゲット・コンテキストに関連するセンサ・データを獲得するために実行され得る第１の検知プロシージャを含むことがある。さらに、第１のステップは、ターゲット・コンテキストの推論値を得る可能性を高めるように、ターゲット・コンテキストに関連する特定されたコンテキスト・ルールを増補することができるように選択され得る。さらに、第１のステップは、少なくとも部分的に、いずれの検知プロシージャが低コストであるかに従って選択され得る。様々な実施形態では、ターゲット・コンテキストの推論値が、検知プランの第１のステップから決定される場合、推論値をアプリケーションに返すことができる。そうでない場合、方法７００はブロック７１０において継続する。

ブロック７１０において、ターゲット・コンテキストの推論値が得られるまで、ルールベースの取得プランナによって、検知プランの複数の後続ステップのいずれかを実行することができる。各ステップは、モバイル・コンピューティング環境又はコンピューティング・デバイス内で実装される複数のセンサのいずれかを使用してターゲット・コンテキストに関連する検知されたコンテキストを獲得するために実行され得る、検知プロシージャを含んでよい。各後続ステップを、ターゲット・コンテキストに関連するコンテキスト・ルール、コスト、又は検知プランの前のステップの結果、又はその任意の組合せに基づいて、個々に決定することができる。一部の実施形態では、例えばターゲット・コンテキストの論理式のツリーを利用して、検知プランの次のステップを決定することができる。各々の前のステップの結果は、ルールベースの取得プランナによって、ターゲット・コンテキストの推論値を得る可能性を高めるように、前の検知プロシージャからのセンサ・データを増補する次の検知プロシージャを決定するために使用され得る。さらに、一部の実施形態では、最も低コストのステップから始まる昇順のコストに従ってステップが実行されるように、検知プランの第１のステップ及び後続ステップを選択することができる。

様々な実施形態において、コンテキスト取得システムは、検知プランの各ステップの後にターゲット・コンテキストの推論値を決定しようと試みることがある。さらに、ルールベースの取得プランナは、推論値が決定されるまで検知プランの次のステップを生成し続けることができる。推論値が得られると、方法７００のインスタンスを開始したアプリケーションに、この推定値を出力することができる。

一部の実施形態では、検知プランの２つの連続したステップ、例えば第１のステップ及び第２のステップが、指定された時間枠内で実行される場合、これらのステップは並列であるか又は同時に起こると考えることができる。指定された時間枠を「バスケット・サイズ」と呼ぶことができる。バスケット・サイズを、特定のターゲット・コンテキストに従って又はステップによって指定された特定の検知プロシージャに従って、動的に変更してもよい。例えばユーザが過去５分以内に歩行していた場合、ユーザは歩行中であると推論され得る。しかしながら、ユーザが過去５分以内に電話で話していたからといって、ユーザが電話で話し中であると推論されないことがある。

様々な実施形態では、ルールベースの取得プランナは、次の擬似コードに基づいて検知プランの各ステップを決定することができる：

上記の擬似コードによると、「Ｉｎｉｔ（Ｘ）」プロシージャを利用して、所望のターゲット属性又はターゲット・コンテキスト Ｘを求めて、ルールベースの取得プランナを開始する（initiate）ことができる。検知プランのトレースは、「Ｕｐｄａｔｅ」プロシージャを使用して、検知プランの前のステップの検知されたコンテキスト（ａｔｔｒｉｂ）の戻り値を含むように更新され得る。次いで「Ｎｅｘｔ」プロシージャを使用して、検知されたコンテキスト（ａｔｔｒｉｂ）の戻り値と、次のステップを取得するコスト（ｃｏｓｔ）とに基づいて検知プランの次のステップを決定することができる。さらに、「ＮｅｘｔＨｅｌｐｅｒ」プロシージャが、検知プランの次のステップを決定するのを助けるのに使用される。特定の検知されたコンテキストの状態（ｓ）を決定するのに使用することができる可能なステップのそれぞれに対して、「ＮｅｘｔＨｅｌｐｅｒ」プロシージャを使用して、特定のトレースの値が既にわかっていて、キャッシュ内にあるかどうかを判断することができる。トレースの値がわかっている場合、トレースによって定義されるターゲット・コンテキストを決定するコストはゼロである。反対に、トレースの値がわかっていない場合、「ＮｅｘｔＨｅｌｐｅｒ」プロシージャは、検知プロシージャに基づいて、最も低コスト（ｍｉｎＣｏｓｔ）で最も有益な検知されたコンテキスト（ｂｅｓｔＡｔｔｒｉｂ）を生じると予測される検知プランの次のステップを決定することができる。様々な実施形態において、ルールベースの取得プランナは、ターゲット・コンテキストの式のツリーが満たされ、ターゲット・コンテキストが推論され得るまで、検知プランのステップを継続的に計画し、実行することができる。

方法７００は、方法７００のステップがいずれかの特定の順序で行われなければならないこと、あるいはあらゆる場合に全てのステップが含まれなければならないことを示すように意図されていない。さらに、具体的な適用に従って、方法７００にステップを追加してもよい。例えば一部の実施形態では、方法７００を単純化するために、冗長なコンテキスト・ルールが、ルールベースの推論のキャッシュ内で抑制されてもよい。このような冗長なルールの抑制は、特定のターゲット・コンテキストの論理式のツリーから特定の論理式又は演算を削除することによって実現され得る。さらに、論理式のツリーを、ルールベースの推論のキャッシュ内のコンテキスト・ルール・マイナによって生成された新しいコンテキスト・ルールに従って、連続的に又は定期的に更新又は変更することができる。

図８は、コンピューティング環境内のコンテキスト・アウェア・アプリケーションによって使用されるコンテキスト情報を取得するように構成されたコードを格納する有形のコンピュータ読取可能媒体８００を示すブロック図である。有形のコンピュータ読取可能媒体８００は、プロセッサ８０２によってコンピュータ・バス８０４を通じてアクセスされ得る。さらに、有形のコンピュータ読取可能媒体８００は、プロセッサ８０２にこの方法のステップを実行させるように構成されたコードを含むことができる。本明細書で説明される様々なソフトウェア構成要素は、図８に示されるように、有形のコンピュータ読取可能媒体８００に格納され得る。例えばコンテキスト取得モジュール８０６は、複数のコンテキスト・ルールのいずれかに基づいてコンテキスト情報を推論するか、又はルールベースの取得プランに基づいてコンテキスト情報を取得するための方法を実行するように構成され得る。様々な実施形態において、ルールベースの取得プランは、推論と検知技法の双方に依拠して、所望のコンテキスト情報を効率的に決定することができる。さらに、有形のコンピュータ読取可能媒体８００は、図８には示されていない任意の数の追加ソフトウェア構成要素を含むこともできる。

図９は、コンテキスト取得システム２００の例示的実施形態のブロック図である。同じ番号の項目は、図２及び図３に関して述べた通りである。様々な実施形態において、図３に関して述べたコンテキスト・ルール・マイナ２０８は、コンテキスト履歴３０２及びコンテキスト・ルール３００を格納するように構成される記憶デバイス又はメモリ・デバイスを含むことがある。コンテキスト・ルール・マイナ２０８は、ブロック９００によって示されるように、マイニングプロシージャを実行することによって、コンテキスト履歴３０２を利用してコンテキスト・ルール３００を生成するように構成され得る。

様々な実施形態において、ｇｅｔ関数２２０は、図２に関して述べたように、ルールベースの推論のキャッシュ２０６においてコンテキスト・アウェア・アプリケーション２０４から特定のコンテキスト情報の要求を受け取ることを含み得る。ブロック９０２において、ルールベースの推論のキャッシュ２０６は、所望のターゲット・コンテキストがキャッシュ９０４に置かれているかどうかを判断することができる。ターゲット・コンテキストがキャッシュ９０４内で見つかる場合、このターゲット・コンテキストを結果９０６として出力することができる。一部の実施形態では、結果９０６は、ターゲット・コンテキストを要求した特定のコンテキスト・アウェア・アプリケーション２０４へ直接送信され得る。

ターゲット・コンテキストが、キャッシュ９０４内で見つからない場合、ルールベースの推論のキャッシュ２０６は、ブロック９０８において、キャッシュ９０４及びコンテキスト・ルール３００からターゲット・コンテキストを推論しようと試みることができる。ブロック９１０において、ルールベースの推論のキャッシュ２０６は、所望のターゲット・コンテキストがブロック９０８において正常に推論されたかどうかを判断することができる。ターゲット・コンテキストが推論された場合、ターゲット・コンテキストを結果９０６として出力することができる。

ターゲット・コンテキストが推論されていない場合、ブロック９１２において、ルールベースの取得プランナ２１０内でプロキシ・センサを選択し、これを使用して検知プランのステップを行う。様々な実施形態では、ブロック９１２において、センサ、分類子及びコスト９１４、並びにコンテキスト・ルール３００を使用して、プロキシ・センサを決定することができる。検知プランのステップの出力は、コンテキスト取得システム２００の次のインスタンスのための追加のコンテキスト情報として使用されるように、キャッシュ９０４に送信することができる。

ブロック９１６において、ルールベースの推論のキャッシュ２０６は、所望のターゲット・コンテキストの値が検知プランのステップから正常に決定されたかどうかを判断することができる。ターゲット・コンテキストが決定された場合、ターゲット・コンテキストを結果９０６として出力することができる。ターゲット・コンテキストが決定されない場合、ブロック９１２において、ルールベースの取得プランナ２１０内で次のプロキシ・センサを選択し、これを使用して検知プランの次のステップを行うことができる。ターゲット・コンテキストがコンテキスト取得システム２００によって正常に決定されるまで、検知プランの任意の数のステップに対してこれを繰り返すことができる。

本主題を、構造的特徴及び／又は方法論的動作に特有の言語で説明してきたが、添付の特許請求の範囲において定義される主題は、そのような具体的な特徴又は動作に必ずしも限定されないことを理解されたい。むしろ、上述の具体的な特徴及び動作は、特許請求の範囲を実装する例示的な形態として開示されている。

Claims (10)

1. ルールに基づくコンテキスト取得のための方法であって、
   コンテキスト取得システムにおいてアプリケーションからターゲット・コンテキストの要求を受け取る工程と、
   ルールベースの推論のキャッシュを使用して、前記ターゲット・コンテキストに関連するコンテキスト・ルールを識別する工程と、
   前記要求の結果として検知プロシージャを開始せずに、以前取得したコンテキスト及び前記コンテキスト・ルールに基づいて、前記ターゲット・コンテキストの推論値を決定する工程と
   前記以前取得したコンテキスト及び前記コンテキスト・ルールに基づいて、前記ターゲット・コンテキストの前記推論値を決定することができない場合、ルールベースの取得プランナを使用して前記ターゲット・コンテキストの前記推論値を取得するための検知プランの第１のステップを実行する工程であって、前記第１のステップが、前記コンテキスト・ルール又はコスト又はその任意の組合せに基づいて決定される、工程と、
   前記ターゲット・コンテキストの前記推論値が得られるまで、前記検知プランの複数の後続ステップのいずれかを実行する工程であって、前記複数の後続ステップの各々が、前記コンテキスト・ルール、前記コスト又は前記検知プランの先行するステップの結果、又はその任意の組合せに基づいて個々に決定される、工程と
   を含む、方法。
2. 前記コンテキスト取得システム内で前記ターゲット・コンテキストの正確な値が見つかる場合、前記正確な値を前記アプリケーションに出力する工程を含む、請求項１に記載の方法。
3. 前記ターゲット・コンテキストの前記推論値を前記アプリケーションに出力する工程を含む、請求項１に記載の方法。
4. 前記アプリケーションが、モバイル・コンピューティング・デバイス内に実装されるコンテキスト・アウェア・アプリケーションを備える、請求項１に記載の方法。
5. コンテキスト・ルール・マイナ内において前記コンテキスト・ルールを作成する工程と、前記ルールベースの推論のキャッシュ内の前記ターゲット・コンテキストに関連する前記コンテキスト・ルールを結合して、前記ターゲット・コンテキストの論理式のツリーを作成する工程を含む、請求項１に記載の方法。
6. 前記論理式のツリーを使用して、前記ターゲット・コンテキストの前記推論値を取得するための前記検知プランを決定する工程を含む、請求項５に記載の方法。
7. 前記検知プランの前記第１のステップを実行する工程又は前記検知プランの前記複数の後続ステップのいずれかを実行する工程が、コンピューティング・デバイス内で実装されるセンサを使用して前記ターゲット・コンテキストに関連する検知されたコンテキストを得る工程を含む、請求項１に記載の方法。
8. 前記コストは、前記ターゲット・コンテキストに関連するセンサ・データを取得する計算コスト又はバッテリコスト又はその双方を含み、前記検知プランの前記第１のステップ及び前記複数の後続ステップは、前記コストに従って昇順で実行されるように選択される、請求項１に記載の方法。
9. コンテキスト・ルール・マイナを使用して前記ルールベースの推論のキャッシュ内の検知されたコンテキストから得られるコンテキスト履歴に従って、前記コンテキスト・ルールを生成する工程を含む、請求項１に記載の方法。
10. ルールに基づくコンテキスト取得のためのシステムにおいて、
    ルールベースの推論のキャッシュであって、
    アプリケーションからターゲット・コンテキストの要求を受け取り、
    前記ターゲット・コンテキストに関連するコンテキスト・ルールであって、当該ルールベースの推論のキャッシュ内に格納されるコンテキスト・ルールを識別し、
    前記要求の結果として検知プロシージャを開始せずに、以前取得したコンテキスト及び前記コンテキスト・ルールに基づいて、前記ターゲット・コンテキストの推論値を決定する
    ように構成される、ルールベースの推論のキャッシュと、
    ルールベースの取得プランナであって、
    前期以前取得したコンテキスト及び前記コンテキスト・ルールに基づいて、前記ターゲット・コンテキストの前記推論値を決定することができない場合、前記ターゲット・コンテキストの前記推論値を取得するための検知プランの第１のステップであって、前記コンテキスト・ルール又はコスト又はその任意の組合せに基づいて決定される検知プランの第１のステップを実行し、
    前記コンテキスト・ルール、前記コスト又は前記検知プランの前記第１のステップの結果又はその任意の組合せに基づいて決定される、前記検知プランの第２のステップを実行する、
    ように構成される、ルールベースの取得プランナと
    を備える、システム。

Images