JP2010152890A

JP2010152890A - コンテキスト・アウェア・プラットホーム内でのセンサの取扱い

Info

Publication number: JP2010152890A
Application number: JP2009280506A
Authority: JP
Inventors: James Lester Memmott; メモット，ジェイムズ，レスター; Atul N Hatalkar; ハタルカー，アトゥル，エヌ
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2008-12-19
Filing date: 2009-12-10
Publication date: 2010-07-08
Anticipated expiration: 2029-12-10
Also published as: EP2214381A1; US8402174B2; US20100161953A1; CN101754437B; EP2214381B1; JP5179463B2; CN101754437A

Abstract

【課題】異種のセンサを取り扱う能力を具備するコンテキスト・アウェア・プラットホームを提供する。
【解決手段】コンテキスト・アウェア・プラットホームのコンテキスト・エンジンは、コンテキスト・プロバイダに結合されたプロバイダ・マネージャを備えており、アプリケーション・プログラミング・インターフェイス（ＡＰＩ）を使用して、コンテキスト・プロバイダと通信する。システム資源の使用を最適化するために、プロバイダ・マネージャは、ヒント信号のロード領域の値に基づいて、または予測値に基づいて、コンテキスト・プロバイダをロード／アンロードする。
【選択図】図１

Description

本発明は、コンテキスト・アウェア・プラットホーム内でのセンサの取扱いに関する。

コンテキスト・アウェア・プラットホーム（状況認識プラットホーム）は、プラットホーム自体、そのユーザ、およびその周囲を認識し、また明示的なユーザ入力を受け取らないでも、その挙動に適応し、判断し、またはユーザの代わりに動作することができる。コンテキスト・アウェア・プラットホームは、コンテキスト（状況）情報を生成することができ、またそのコンテキスト情報に基づいて、コンテキスト・アウェア・プラットホームは、明示的なユーザ入力を受け取らないでも適応することができる。コンテキスト情報は、センサによって提供されるデータを使用して生成することができる。センサは、そのセンサが検出した入力に基づいて、データを生成してもよい。

市場で入手可能なセンサの種類および格差はますます増大している。現在のコンテキスト・アウェア・プラットホームには、異種のセンサを取り扱う能力が欠けている。また、センサおよび関連するフロントエンド処理モジュールは、電池の電力、ネットワーク帯域幅、処理サイクルのような資源、および他の類似した資源を大量に消費することがある。現在のコンテキスト・アウェア・プラットホームには、そのような資源を節約するようにセンサを取り扱う能力が欠けている。

本明細書に記載の本発明について例として説明するが、添付の図に限定されるものではない。説明を簡単にかつ分かりやすくするために、図に示す要素は必ずしも原寸に比例して描かれてはいない。たとえば、いくつかの要素の寸法は、見やすいように、他の要素に対して誇張されることがある。さらに、適切と考えられる場合、対応するまたは類似の要素を示すために、複数の図の中で参照表示を繰り返している。

一実施例に従って、異種のセンサによって消費される資源を節約しながら異種のセンサを取り扱うことができるコンテキスト・アウェア・プラットホーム１００を図示する。一実施例に従って、異種のセンサによって消費される資源を節約しながら異種のセンサを取り扱うことができるプラットホーム１００のコンテキスト・エンジンを図示する。一実施例に従って、異種のセンサをコンテキスト・アウェア・プラットホームに結合させる統一された手法を提供するために異種のセンサを活性化／非活性化できるコンテキスト・プロバイダの動作を示すフローチャートである。一実施例に従って、コンテキスト・プロバイダのロードまたはアンロードを行うことができるプロバイダ・マネージャの動作を示すフローチャートである。プロバイダ・アプリケーション・プログラミング・インターフェイス（ＡＰＩ）の一実施例を示す図である。一実施例に従って、コンテキスト・エンジンのコンテキスト・プロバイダとプロバイダ・マネージャの間の同期通信モードを示す図である。一実施例に従って、コンテキスト・エンジンのコンテキスト・プロバイダとプロバイダ・マネージャの間の非同期通信モードを示す図である。一実施例に従って、センサを取扱いながらコンテキスト・アウェアネスに対応することができるコンピュータ・システム図である。

以下の説明では、コンテキスト・アウェア・プラットホーム内でセンサを取り扱う技術の実施例について述べる。以下の説明では、論理回路の実行、資源の仕切りもしくは共用または複製の実行、システム構成要素の種類および相互関係、ならびに論理回路の仕切りまたは一体化の選択などの多数の具体的な詳細について、本発明のより完全な理解を提供するために述べる。しかし、そのような具体的な詳細がなくても本発明を実施できることが、当業者には理解されるであろう。他の例では、本発明を曖昧にしないために、制御構造、ゲートレベル回路、および完全なソフトウェア命令シーケンスを詳細に示していない。当業者であれば、過度の実験なしに、包含された説明を用いて適切な機能を実施することができるであろう。

本明細書中の「一実施例（ｏｎｅｅｍｂｏｄｉｍｅｎｔ）」、「実施例（ａｎｅｍｂｏｄｉｍｅｎｔ）」、「例示的な実施例（ａｎｅｘａｍｐｌｅｅｍｂｏｄｉｍｅｎｔ）」への言及は、記載された実施例が特定の特徴、構造、または特性を含み得るが、すべての実施例が必ずしもこの特定の特徴、構造、または特性を含むわけではないことを示す。さらに、そのような語句は、必ずしも同じ実施例に言及しているわけではない。さらに、特定の特徴、構造、または特性について一実施例に関連して説明するとき、明示的に記載されているか否かにかかわらず、他の実施例に関連するそのような特徴、構造、または特性にも影響を及ぼすことは当業者の知識の範囲内であることが提起される。

本発明の実施例は、ハードウェア、ファームウェア、ソフトウェア、またはこれらの任意の組合せ内で実施することができる。本発明の実施例は、また、機械読取り可能な媒体上に格納された命令として実施することができ、これらの命令は、１つまたは複数のプロセッサによって読取りかつ実行することができる。機械読取り可能な媒体は、機械（たとえば、演算デバイス）によって読取り可能な形で情報を格納または伝送する任意の機構を含むことができる。

たとえば、機械読取り可能な媒体には、リード・オンリ・メモリ（ＲＯＭ）、ランダム・アクセス・メモリ（ＲＡＭ）、磁気ディスク記憶媒体、光学記憶媒体、フラッシュ・メモリ・デバイス、電気信号、光学信号、音響信号、または他の類似の信号が含み得る。さらに本明細書では、ファームウェア、ソフトウェア、ルーチン、および命令について、特定の動作を実行するものとして説明することがある。しかし、そのような説明は単に便宜上のものであること、そしてそのような動作は実際には、演算デバイス、プロセッサ、制御装置、および他のデバイスがこれらのファームウェア、ソフトウェア、ルーチン、および命令を実行した結果であることを理解されたい。

異種のセンサによって消費される資源を節約しながら異種のセンサを取り扱うことができるコンテキスト・アウェア・プラットホーム１００の一実施例を図１に示す。一実施例では、コンテキスト・アウェア・プラットホーム１００は、センサ複合体１１０、コンテキスト・エンジン１５０、およびクライアント１８０を備えることができる。

一実施例では、クライアント１８０は、クライアント１８０−１〜１８０−Ｎなどの１つまたは複数のクライアント・エンティティを含むことができる。一実施例では、クライアント・エンティティ１８０−１〜１８０−Ｎは、ユーザレベル・アプリケーション、オペレーティング・システム、プラットホーム・ユーティリティ、およびツールを含むことができる。一実施例では、クライアント１８０は、コンテキスト・エンジン１５０から受け取ったコンテキスト情報を使用して、実行すべき決定および動作に達することができる。一実施例では、クライアント１８０は、コンテキスト・エンジン１５０から同期的にまたは非同期的にコンテキスト情報を受け取ることができる。一実施例では、クライアント１８０は、コンテキスト・エンジン１５０によって実行されるコンテキスト処理をカスタマイズすることができる。

一実施例では、センサ複合体１１０は、異種のセンサのアレイを備えることができる。このアレイは、物理センサおよび論理センサを含むことができる。一実施例では、これらのセンサは、そこからコンテキスト情報を生成できるデータを提供することができる。一実施例では、これらのセンサは、コンテキスト・アウェア・プラットホーム１００内に埋め込まれたハードウェア構成要素、または有線／無線ネットワークなどの構成要素を使用してコンテキスト・アウェア・プラットホーム１００に結合されたハードウェア構成要素とすることができる。一実施例では、センサ複合体１１０をコンテキスト・エンジン１５０に結合させることができる。一実施例では、これらのセンサは、バッテリの充電、動作中の無線、位置、湿度、コンテキスト・アウェア・プラットホーム１００のユーザの血圧および活動レベル、メモリおよびプロセッサの使用量、ならびに他のパラメータなどの検知に基づいて、データを生成することができる。一実施例では、センサ複合体１１０のセンサは、コンテキスト・アウェア・プラットホーム１００がセンサからのコンテキスト情報を要求しかつ受け取るため、そしてセンサによって消費される資源を節約するための統一された方法を提供するように、動的に活性化および／または非活性化することができる。

一実施例では、コンテキスト・エンジン１５０は、コンテキスト・アウェア・プラットホーム１００からセンサ複合体１１０のセンサを動的に活性化および非活性化させることができる。一実施例では、コンテキスト・エンジン１５０は、クライアント１８０によるセンサの使用を示す標識を含む情報を使用して、ヒント信号を生成することができる。一実施例では、コンテキスト・エンジン１５０は、また、コンテキスト・エンジン１５０によるセンサの使用を示す標識を含む情報に基づいて、ヒント信号を生成することができる。一実施例では、コンテキスト・エンジン１５０は、ヒント信号に基づいて、センサ複合体１１０の１つまたは複数のセンサを活性化させることができる。一実施例では、コンテキスト・エンジン１５０は、また、ヒント信号を使用して、コンテキスト・アウェア・プラットホーム１００に結合された１つまたは複数のセンサを非活性化させることができる。

一実施例では、ヒント信号に基づくセンサの活性化および／または非活性化は、センサをコンテキスト・アウェア・プラットホーム１００に結合させる統一された手法を提供することができる。一実施例では、コンテキスト・エンジン１５０は、センサが使用されていない可能性のある経過期間を追跡することができ、その経過期間が第１のアイドル閾値を上回った場合、コンテキスト・エンジン１５０は、そのセンサを非活性化させて、資源を節約することができる。一実施例では、コンテキスト・エンジン１５０は、また、センサが使用され得る将来時点を予測することができ、その将来時点が第２のアイドル閾値を上回った場合、コンテキスト・エンジン１５０は、そのセンサを非活性化させて、センサによって消費される資源を節約することができる。

一実施例では、センサ２１０のうちの１つまたは複数のセンサ・データのために、クライアント１８０からの要求に直接応答して、ヒント信号を生成することができる。一実施例では、この直接応答は、少なくともクライアント１８０−１がセンサ２１０−Ａを使用する間はセンサ２１０−Ａを活性化でき、また最後のクライアント１８０−Ｋがたとえばセンサ２１０−Ａの使用を完了したときはセンサ２１０−Ａを非活性化できるような基準カウントを含めることができる。

他の実施例では、クライアント１８０による各センサ２１０の使用を監視することに加えて、コンテキスト・エンジン１５０は、さらなる発見的もしくは推論的分析、または履歴傾向分析を使用して、センサ２１０を活性化または非活性化できる時点を決定することができる。さらに他の実施例では、コンテキスト・エンジン１５０は、あらゆるクライアント活動から独立して、他の機構を使用して、センサ２１０の最善の使用を予想し、センサ２１０をそれぞれ活性化または非活性化させることができる。

センサによって消費される資源の節約を行いながらセンサを活性化および／または非活性化させる統一された手法に対応できるコンテキスト・エンジン１５０の一実施例を図２に示す。一実施例では、コンテキスト・エンジン１５０は、クライアント・インターフェイス２２０、制御論理回路２４０、１つまたは複数のコンテキスト・プロバイダ２５０−１〜２５０−Ｋ、およびプロバイダ・マネージャ２８０を備えることができる。

一実施例では、クライアント・インターフェイス２２０は、クライアント１８０をコンテキスト・エンジン１５０に結合させることができる。一実施例では、クライアント・インターフェイス２２０は、制御論理回路２４０からの指示を受け取った後、プロバイダ・マネージャ２８０からコンテキスト情報を受け取ることができる。一実施例では、クライアント・インターフェイス２２０は、制御論理回路２４０によって提供される制御値に基づいて、適切なクライアント１８０−１〜１８０−ｍのうちの１つまたは複数にコンテキスト情報を転送することができる。一実施例では、クライアント・インターフェイス２２０は、また、クライアント１８０によって生成される制御データをコンテキスト・エンジン１５０に転送することができる。一実施例では、この制御データは、規則、センサ使用の指示、およびそのような他の類似のデータを含むことができる。

一実施例では、制御論理回路２４０は、プロバイダ・マネージャ２８０からの指示を受け取ることができ、またコンテキスト情報をプロバイダ・マネージャ２８０からクライアント・インターフェイス２２０へ転送させることができる。一実施例では、制御論理回路２４０は、プロバイダ・マネージャ２８０から受け取った入力に基づいて、制御値を生成することができる。一実施例では、制御論理回路２４０は、クライアント・インターフェイス２２０に制御値を提供することができる。

一実施例では、プロバイダ・マネージャ２８０は、センサ２１０の好ましい活動レベルまたはセンサ２１０の予測される活動レベルに基づいて、コンテキスト・プロバイダ２５０−１〜２５０−Ｋをロードおよび／またはアンロードすることができる。一実施例では、プロバイダ・マネージャ２８０は、ヒント信号のロード領域に特有の論理値、たとえばコンテキスト・プロバイダ２５０−１をロードするには「１」、またアンロードするには「０」をプログラムすることができる。一実施例では、プロバイダ・マネージャ２８０は、また、コンテキスト・プロバイダ２５０に結合されたセンサ２１０−Ａ，２１０−Ｂを活性化または非活性化させるように、ヒント信号の活動レベル領域を第１の論理レベルまたは第２の論理値でプログラムすることができる。一実施例では、プロバイダ・マネージャ２８０は、コンテキスト・プロバイダ２５０−１〜２５０−Ｋと通信するためのプロバイダ・アプリケーション・プログラム・インターフェイス（ＡＰＩ）に対応することができる。一実施例では、プロバイダＡＰＩは、プロバイダ・マネージャ２８０がコンテキスト・プロバイダ２５０−１〜２５０−Ｋの初期化、登録、ロード、コンテキスト情報の取得、アンロード、アンインストールなどの活動に対応することを可能にすることができる。一実施例では、プロバイダ・マネージャ２８０は、制御エンジン１５０が非活性状態であるときでも、コンテキスト・プロバイダ２５０−１〜２５０−Ｋのインストール、登録、およびアンインストールなどの活動に対応することができる。

一実施例では、プロバイダ・マネージャ２８０は、プロバイダＡＰＩを使用して、コンテキスト・プロバイダ２５０−１〜２５０−Ｋにヒント信号を提供することができる。一実施例では、プロバイダ・マネージャ２８０は、コンテキスト・プロバイダ２５０−１〜２５０−Ｋを始動させてから、プロバイダＡＰＩを使用して、コンテキスト・プロバイダ２５０−１〜２５０−Ｋからコンテキスト情報を取得することができる。一実施例では、プロバイダ・マネージャ２８０は、コンテキスト・プロバイダ２５０−１〜２５０−Ｋから同期的にまたは非同期的にコンテキスト情報を取得することができる。一実施例では、プロバイダ・マネージャ２８０は、制御論理回路２４０から制御信号を受け取るのに応答して、コンテキスト情報をクライアント・インターフェイス２２０に提供することができる。一実施例では、プロバイダ・マネージャ２８０は、制御論理回路２４０がコンテキスト情報を適切なクライアント１８０−１〜１８０−ｍへ転送することを許可する指示を制御論理回路２４０に提供することができる。

一実施例では、コンテキスト・プロバイダ２５０−１がセンサ２１０−Ａ，２１０−Ｂに対応することができ、コンテキスト・プロバイダ２５０−２がセンサ２１０−Ｃ，２１０−Ｄに対応することができ、またコンテキスト・プロバイダ２５０−Ｋがセンサ２１０−Ｎに対応することができる。一実施例では、コンテキスト・プロバイダ２５０−１〜２５０−Ｋは、センサ２１０−Ａ〜２１０−Ｎをコンテキスト・エンジン１５０に結合させることができる。一実施例による、コンテキスト・プロバイダ２５０−１がセンサ２１０−Ａ，２１０−Ｂを活性化および／または非活性化させる動作について、以下に説明する。しかし、他のコンテキスト・プロバイダ２５０−２〜２５０−Ｋも、類似のモードで動作してセンサ２１０−Ｃ〜２１０−Ｎを活性化および／または非活性化させることができる。センサ２１０−Ａ，２１０−Ｂをコンテキスト・エンジン１５０に結合させるために、一実施例では、コンテキスト・プロバイダ２５０−１は、センサ２１０−Ａ，２１０−Ｂによって使用されるプロトコル、インターフェイス、および信号機構に対応することができる。一実施例では、コンテキスト・プロバイダ２５０−１は、また、共通データ・アクセスおよび制御プロトコルに対応することができる。このプロトコルは、プロバイダＡＰＩ（アプリケーション・プログラム・インターフェイス）の形で提供することができる。

一実施例では、ヒント信号のロード／アンロード領域値が特有の値（たとえば、論理１）に等しい場合、コンテキスト・プロバイダ２５０−１をロードすることができる。一実施例では、ロードされたコンテキスト・プロバイダ２５０−１は、コンテキスト・プロバイダ２５０−１に結合されたセンサ２１０−Ａ，２１０−Ｂに対する活動レベル領域を取り出すことができる。一実施例では、コンテキスト・プロバイダ２５０−１は、ヒント信号の２１０−Ａに対する活動レベル領域が第１の論理レベル（たとえば、１）を表す場合、センサ２１０−Ａを活性化させることができ、またヒント信号の２１０−Ｂに対する活動レベル領域が第２の論理レベル（たとえば、０）を表す場合、センサ２１０−Ｂを非活性化させることができる。一実施例では、コンテキスト・プロバイダ２５０−１は、センサ２１０−Ａ，２１０−Ｂの活動レベル領域に基づいて、センサ２１０−Ａ，２１０−Ｂを活性化させ、もしくはセンサ２１０−Ａ，２１０−Ｂを非活性化させ、またはセンサ２１０−Ａを活性化させかつセンサ２１０−Ｂを非活性化させ、もしくはセンサ２１０−Ａを非活性化させかつセンサ２１０−Ｂを活性化させることができる。コンテキスト・プロバイダ２５０−１〜２５０−Ｋとプロバイダ・マネージャ２８０の間の通信に使用されるプロバイダＡＰＩの一実施例について、以下に説明する。

異種のセンサを活性化／非活性化して異種のセンサをコンテキスト・アウェア・プラットホーム１００に結合させる統一された手法を提供できるコンテキスト・プロバイダ２５０−１の動作の一実施例を図３に示す。

ブロック３１０で、コンテキスト・プロバイダ２５０−１は、異種のセンサの好ましい活動レベルを示すことができるヒント信号を受け取ることができる。一実施例では、このヒント信号をプロバイダ・マネージャ２８０から受け取ることができる。一実施例では、ヒント信号は、たとえば、センサ２１０−Ａを活性化でき、またセンサ２１０−Ｂを非活性化できることを示すことができる。

ブロック３４０で、コンテキスト・プロバイダ２５０−１は、活性化できるセンサ（第１の組）と非活性化できるセンサ（第２の組）を識別することができる。一実施例では、コンテキスト・プロバイダ２５０−１は、センサ２１０−Ａ（第１の組）を活性化でき、またセンサ２１０−Ｂ（第２の組）を非活性化できることを識別することができる。

ブロック３６０で、コンテキスト・プロバイダ２５０−１は、第１の組（センサ２１０−Ａ）を活性化させることができる。一実施例では、コンテキスト・プロバイダ２５０−１は、センサ２１０−Ａに信号を送ってセンサ２１０−Ａを活性化させることができる。

ブロック３８０で、コンテキスト・プロバイダ２５０−１は、第２の組のセンサ（センサ２１０−Ｂ）を非活性化させることができる。一実施例では、コンテキスト・プロバイダ２５０−１は、センサ２１０−Ｂに信号を送ってセンサ２１０−Ｂを非活性化させることができる。

ブロック３９０で、コンテキスト・プロバイダ２５０−１は、プロバイダ・マネージャ２８０に状況更新信号を送ることができる。

コンテキスト・プロバイダ２５０−１と通信して、異種のセンサ２１０によって消費される資源を節約しながら異種のセンサを取り扱う統一された手法を提供できるプロバイダ・マネージャ２８０の動作の一実施例を図４に示す。

ブロック４２０で、プロバイダ・マネージャ２８０は、クライアント１８０によって提供される入力に基づいて、センサの使用レベルを追跡することができる。一実施例では、センサの使用レベルは、期間Ｘの範囲内でクライアント１８０−２がセンサ２１０−Ａを使用できることを示すことができる。また、クライアント１８０−ｍによって提供されるセンサの使用レベルは、次の「Ｙ」時間単位の間、センサ２１０−Ｂを使用できないことを示すことができる。

ブロック４３０で、プロバイダ・マネージャ２８０は、クライアント１８０によって提供される入力を使用して追跡されるセンサの使用レベルを使用して、センサ２１０−Ａ，２１０−Ｂに対する好ましい活動レベルを決定することができる。一実施例では、プロバイダ・マネージャ２８０は、センサ２１０−Ａに対する好ましい活動レベルを「活性化」（第１の論理レベル）に等しくし、またセンサ２１０−Ｂに対する好ましい活動レベルを「非活性化」（第２の論理レベル）に等しくすることを決定することができる。

ブロック４４０で、プロバイダ・マネージャ２８０は、これらの活動レベルに基づいてヒント信号を生成することができる。ブロック４５０で、プロバイダ・マネージャ２８０は、プロバイダＡＰＩを使用して、このヒント信号をコンテキスト・プロバイダ２５０−１に送ることができる。ブロック４６０で、プロバイダ・マネージャ２８０は、ヒント信号を送った後、状況更新信号を受け取ることができる。

ブロック４７０で、プロバイダ・マネージャ２８０は、コンテキスト・プロバイダに結合されたセンサがすべて非活性化されているかどうかを確認することができる。一実施例では、プロバイダ・マネージャ２８０は、コンテキスト・プロバイダ２５０−１に結合されたセンサ２１０−Ａ，２１０−Ｂが非活性化されているかどうかを確認することができ、コンテキスト・プロバイダ２５０−１に結合されたセンサ（２１０−Ａ，２１０−Ｂ）が非活性化されていない場合、制御はブロック４８０へ進み、そうでない場合、制御はブロック４９０へ進む。

ブロック４８０で、プロバイダ・マネージャ２８０は、コンテキスト・プロバイダ２５０−１に結合された少なくとも１つのセンサ２１０−Ａが活性化状態にあるとき、コンテキスト・プロバイダ２５０−１のロードされた状態を維持することができる。

ブロック４９０で、プロバイダ・マネージャ２８０は、コンテキスト・プロバイダ２５０−１に結合されたセンサ２１０−Ａ，２１０−Ｂが非活性化されている場合、コンテキスト・プロバイダ２５０−１をアンロードすることができる。

他の実施例では、プロバイダ・マネージャ２８０は、クライアント・エンティティ１８０−１〜１８０−ｍによるセンサ２１０の使用パターンに基づいて、コンテキスト・プロバイダ２５０を推測によりロードまたはアンロードすることができる。一実施例では、プロバイダ・マネージャ２８０は、クライアント１８０によるセンサ２１０の使用を推測することができ、またそのようなセンサをコンテキスト・アウェア・プラットホーム１００に結合できるコンテキスト・プロバイダ２５０をロードすることができる。他の実施例では、プロバイダ・マネージャ２８０は、たとえばコンテキスト・プロバイダ２５０を頻繁にロードおよびアンロードすることを避けるために、コンテキスト・プロバイダ２５０をロードされた状態に維持し続けることができる。

一実施例では、先の使用パターンは、クライアント・エンティティによって複数のセンサが使用される確率を示す確率値を含むことができ、使用パターンは、クライアント・エンティティによって複数のセンサが使用される頻度を示す頻度値を含むことができる。

プロバイダＡＰＩの一実施例を図５に示す。一実施例では、プロバイダＡＰＩは、登録インターフェイスＩＰｒｏｖｉｄｅｒＲｅｇｉｓｔｒａｔｉｏｎ５１０を含み、ＩＰｒｏｖｉｄｅｒＲｅｇｉｓｔｒａｔｉｏｎインターフェイス５１０を使用して、コンテキスト・プロバイダ２５０−１〜２５０−Ｋをコンテキスト・アウェア・プラットホーム１００に登録することができる。

一実施例では、コンテキスト・プロバイダ２５０−１〜２５０−Ｋがコンテキスト・アウェア・プラットホーム１００にインストールされかつ登録された後、プロバイダ・マネージャ２８０は、コンテキスト・プロバイダ２５０−１〜２５０−Ｋを使用することができる。一実施例では、インストール処理は、ハード・ドライブなどのメモリ上へファイルをコピーするステップと、コンテキスト・プロバイダ２５０が対応するセンサ２１０に特有の任意の環境設定を設定するステップとを含むことができる。インストール後、プロバイダ・マネージャ２８０は、コンテキスト・プロバイダ２５０をコンテキスト・アウェア・プラットホーム１００に登録することができる。

一実施例では、ＲｅｇｉｓｔｅｒＰｒｏｖｉｄｅｒ（）を使用して、コンテキスト・プロバイダ２５０がインストールされて使用する準備ができたことを示すことができる。一実施例では、ＲｅｍｏｖｅＰｒｏｖｉｄｅｒ（）を使用して、コンテキスト・アウェア・プラットホーム１００からコンテキスト・プロバイダ２５０を除去することができる。これは、アンインストール処理中（すなわち、ファイルがシステムから削除される前）に行うことができる。一実施例では、コンテキスト・エンジン１５０が能動的に動作していないときでも、ＩＰｒｏｖｉｄｅｒＲｅｇｉｓｔｅｒを使用することができる。一実施例では、ＰｒｏｖｉｄｅｒＲｅｇｉｓｔａｔｉｏｎＩｎｆｏインターフェイスを使用して、登録できるコンテキスト・プロバイダ２５０について記述することができ、またＲｅｇｉｓｔｒａｔｉｏｎＤｅｔａｉｌｓパラメータとして渡すことができるＸＭＬＤｏｃは、コンテキスト・プロバイダ２５０が対応するすべてのコンテキスト識別子について記述することができる。

一実施例では、プロバイダ・マネージャ２８０は、ＩＰｒｏｖｉｄｅｒＣｏｎｔｒｏｌインターフェイス５２０を使用して、ＩＰｒｏｖｉｄｅｒＤａｔａインターフェイスへのアクセスを取得することに加えて、初期化処理を完了させることができ、またコンテキスト・プロバイダ２５０が対応する個々の識別子を「活性化」させることができる。一実施例では、プロバイダ・マネージャ２８０は、ＳｔａｒｔＰｒｏｖｉｄｅｒ（）インターフェイスおよびＳｔｏｐＰｒｏｖｉｄｅｒ（）インターフェイスを使用して、初期化を完了させることができる。これは、コンテキスト・プロバイダ２５０を最初に初期化している間に行うことはできない。一実施例では、プロバイダ・マネージャ２８０は、ＩＰｒｏｖｉｄｅｒＲｅｇｉｓｔｒａｔｉｏｎインターフェイス５１０を呼び出してからコンテキスト・プロバイダ２５０を使用することができ、またＩＰｒｏｖｉｄｅｒＣｏｎｔｒｏｌインターフェイス５２０を呼び出してからコンテキスト・プロバイダ２５０をアンロードすることができる。

一実施例では、プロバイダ・マネージャ２８０は、ＡｃｔｉｖａｔｅＣｏｎｔｅｘｔ（）を使用して、コンテキスト・アウェア・プラットホーム１００が使用できる識別子をコンテキスト・プロバイダ２５０に示すことができる。一実施例では、コンテキスト・プロバイダ２５０は、センサ２１０によって消費される資源を節約する電力を含めて、プラットホーム資源に電源を投入することができる。一実施例では、コンテキスト・プロバイダ２５０は、ハードウェア資源の一部に電源を投入し、またソフトウェア資源の一部をロードして、活性化させたハードウェア資源およびソフトウェア資源に対する情報を提供する。一実施例では、コンテキスト・プロバイダ２５０を非活性化させた後、センサ２１０の電源を切って、使用されていないハードウェア資源およびソフトウェア資源をアンロードすることができる。一実施例では、プロバイダ・マネージャ２８０は、コンテキスト・プロバイダ２５０の単一のインスタンスの寿命中に、コンテキスト・プロバイダ２５０が個々の識別子を複数回活性化および／または非活性化することを可能にすることができる。一実施例では、ＧｅｔＰｒｏｖｉｄｅｒＤａｔａ（）は、コンテキスト・プロバイダ２５０からコンテキスト情報を取得するために使用できるＩＰｒｏｖｉｄｅｒＤａｔａインターフェイス５３０への参照を返すことができる。

一実施例では、プロバイダ・マネージャ２８０は、ＩＰｒｏｖｉｄｅｒＤａｔａインターフェイス５３０を使用して、ＧｅｔＤａｔａ（）メソッドを呼び出すことによってコンテキスト情報を「オン・デマンド」で取得することができる。一実施例では、プロバイダ・マネージャ２８０は、ＧｅｔＤａｔａ（）メソッドを頻繁に使用することができ、また迅速に動作するようにＧｅｔＤａｔａ（）を最適化することができる。一実施例では、非同期通知の場合、ＩＰｒｏｖｉｄｅｒＤａｔａインターフェイス５３０を使用して、ＧｅｔＰｒｏｖｉｄｅｒＮｏｔｉｆｉｅｒ（）を呼び出すことによって、ＩＰｒｏｖｉｄｅｒＮｏｔｉｆｉｅｒインターフェイス５４０への参照を取得することができる。

一実施例では、プロバイダ・マネージャ２８０は、ＩＰｒｏｖｉｄｅｒＮｏｔｉｆｉｅｒインターフェイス５４０を使用して、データ変更の事前通知を登録することができる。この事前通知により、変更に対してコンテキスト・プロバイダ２５０にポーリングする必要を回避することができる。一実施例では、プロバイダ・マネージャ２８０は、ＩＰｒｏｖｉｄｅｒＤａｔａＯｂｓｅｒｖｅｒインターフェイスへのポインタをＲｅｇｉｓｔｅｒＯｂｓｅｒｖｅｒ（）およびＲｅｍｏｖｅＯｂｓｅｒｖｅｒ（）に渡して事象通知を開始し、また通知を終了できるように、ＩＰｒｏｖｉｄｅｒＤａｔａＯｂｓｅｒｖｅｒを実施するオブジェクトをインスタンス化することができる。一実施例では、コンテキスト・プロバイダ２５０は、複数のオブザーバに対応することができる。

一実施例では、登録中にＩＰｒｏｖｉｄｅｒＮｏｔｉｆｉｅｒが使用される場合、コンテキスト・プロバイダ２５０は、ＩＰｒｏｖｉｄｅｒＤａｔａＯｂｓｅｒｖｅｒインターフェイス５５０を使用して、オブザーバ・オブジェクトにデータ変更を通知することができる。一実施例では、コンテキスト・プロバイダ２５０は、ＥｖｅｎｔＣｏｎｔｅｘｔＵｐｄａｔｅＡｖａｉｌａｂｌｅ（）を呼び出して、コンテキスト・プロバイダ２５０によって提供された以前の報告後のａＣｏｎｔｅｘｔＮａｍｅに関連するデータの変更について、プロバイダ・マネージャ２８０に知らせることができる。一実施例では、制御論理回路２４０は、データを待ち行列内に配置して、制御をコンテキスト・プロバイダ２５０に返すことができる。一実施例では、この待ち行列は、内部のスレッドによって、ＩＰｒｏｖｉｄｅｒＤａｔａ：：ＧｅｔＤａｔａ（）を呼び出してａＣｏｎｔｅｘｔＮａｍｅに関連する最新のデータを取得し、新しいコンテキスト項目をコンテキスト・ストア内に入れることによって補修することができる。

一実施例では、コンテキスト・プロバイダ２５０は、ＥｖｅｎｔＩｄｅｎｔｉｆｉｅｒＯｎｌｉｎｅ（）オブジェクトおよびＥｖｅｎｔＩｄｅｎｔｉｆｉｅｒＯｆｆｌｉｎｅ（）オブジェクトを使用して、コンテキスト・プロバイダ２５０が対応する識別子を一時的に利用できないかどうかをプロバイダ・マネージャ２８０に通知することができる。一実施例では、この識別子は、様々な理由で利用できなくなる可能性がある。たとえば、センサ２１０は、シリアル・バス・ケーブルまたはユニバーサル・シリアル・バス・ケーブルを使用してプラットホーム１００に接続されることがあり、ユーザが、センサ２１０をプラットホーム１００から切り離す可能性がある。一実施例では、コンテキスト・プロバイダ２５０は、そのような事象をＥｖｅｎｔＩｄｅｎｔｉｆｅｒＯｆｆｌｉｎｅ（）として報告することができる。一実施例では、コンテキスト・プロバイダ２５０は、また、ＥｖｅｎｔＩｄｅｎｔｉｆｉｅｒＯｎｌｉｎｅ（）を使用して、センサ２１０が再接続された事象を報告することができる。センサ２１０の切離しおよび結合は、たとえば、無線接続性の損失および確立のために生じることがあり、それによって、ＥｖｅｎｔＩｄｅｎｔｉｆｉｅｒＯｆｆｌｉｎｅ（）およびＥｖｅｎｔＩｄｅｎｔｉｆｉｅｒＯｎｌｉｎｅ（）が引き起こされる可能性がある。コンテキスト・プロバイダ２５０内の識別子がオフライン状態であるとき、プロバイダ・マネージャ２８０は、ＧｅｔＤａｔａ（）メソッドを呼び出してコンテキスト情報を取得することができない。

コンテキスト・プロバイダ２５０−１とプロバイダ・マネージャ２８０の間の通信を可能にする同期機構の一実施例を図６に示す。一実施例では、ＬｏａｄＰｒｏｖｉｄｅｒ（）６０１およびＵｎｌｏａｄＰｒｏｖｉｄｅｒ（）６９９は、コンテキスト・アウェア・プラットホーム１００が対応するオペレーティング・システムによって実施することができる。一実施例では、プロバイダ・マネージャ２８０は、ＬｏａｄＰｏｖｉｄｅｒ（）６０１を呼び出して、特有のコンテキスト・プロバイダ２５０をロードすることができ、またＵｎｌｏａｄＰｒｏｖｉｄｅｒ（）６９９を呼び出して、以前にロードしたコンテキスト・プロバイダ２５０をアンロードすることができる。一実施例では、プロバイダ・マネージャ２８０によって決定される通り、コンテキスト・プロバイダ２５０をロードおよびアンロード、ならびに再ロードすることができる。一実施例では、ＬｏａｄＰｒｏｖｉｄｅｒ（）６０１およびＵｎｌｏａｄＰｒｏｖｉｄｅｒ（）６９９というメソッドがプロバイダＡＰＩの一部分ではないことを示すために、ＬｏａｄＰｒｏｖｉｄｅｒ（）６０１およびＵｎｌｏａｄＰｒｏｖｉｄｅｒ（）６９９を、２５０を表す線の外側に示す。

一実施例では、プロバイダ・マネージャ２８０は、ＳｔａｒｔＰｒｏｖｉｄｅｒ（）メソッド６１０を呼び出して、コンテキスト・プロバイダ２５０−１に初期化を実行させることができる。これは、最初の初期化段階中に実行することはできない。一実施例では、プロバイダ・マネージャ２８０は、ＡｃｔｉｖａｔｅＣｏｎｔｅｘｔ（ｓｔｒｉｎｇ）メソッド６２０を実行することができる。メソッド６２０は、コンテキスト・プロバイダ２５０−１に対して、コンテキスト・アウェア・プラットホーム１００が使用できる識別子を示すことができる。一実施例では、プロバイダ・マネージャ２８０は、ＧｅｔＤａｔａ（Ｓｔｒｉｎｇ，Ｌｏｃａｔｉｏｎ，ＤａｔｅＴｉｍｅ）を複数回呼び出して、コンテキスト・プロバイダ２５０−１からコンテキスト情報を取得することができる。一実施例では、ＧｅｔＤａｔａ（）は、（文字列型の）コンテキスト情報、位置の詳細、および日時の詳細とともに戻ることができる。一実施例では、ＧｅｔＤａｔａ（）メソッドへの複数の呼出しを、呼出し６３０，６５０，６６０によって表すことができる。ＧｅｔＤａｔａ（Ｓｔｒｉｎｇ，Ｌｏｃａｔｉｏｎ，ＤａｔｅＴｉｍｅ）メソッド６５０，６６０の複数の呼出し間に、プロバイダ・マネージャ２８０は、ＤｅａｃｔｉｖａｔｅＣｏｎｔｅｘｔ（Ｓｔｒｉｎｇ）６５２を呼び出してセンサ２１０を非活性化させることができ、またＡｃｔｉｖａｔｅＣｏｎｔｅｘｔ（Ｓｔｒｉｎｇ）６５８を呼び出してセンサ２１０を活性化させることができる。

一実施例では、次いでプロバイダ・マネージャ２８０は、ＤｅａｃｔｉｖａｔｅＣｏｎｔｅｘｔ（ｓｔｒｉｎｇ）メソッド６８０を実行して識別子を非活性化させることができ、これらの識別子は、コンテキスト・アウェア・プラットホーム１００には使用することができなくなる。一実施例では、次いでプロバイダ・マネージャ２８０は、ＳｔｏｐＰｒｏｖｉｄｅｒ（）６９０を呼び出してから、コンテキスト・プロバイダ２５０−１をアンロードすることができる。一実施例では、ＩＰｒｏｖｉｄｅｒＣｏｎｔｒｏｌインターフェイス５２０は、ＳｔａｒｔＰｒｏｖｉｄｅｒ（）６１０、ＡｃｔｉｖａｔｅＣｏｎｔｅｘｔ（）６２０、ＧｅｔＤａｔａ（）６３０，６５０，６６０、ＤｅａｃｔｉｖａｔｅＣｏｎｔｅｘｔ（）６８０、ならびにＳｔｏｐＰｒｏｖｉｄｅｒ（）６９０というメソッドを含むことができる。

コンテキスト・プロバイダ２５０−１とプロバイダ・マネージャ２８０の間の通信を可能にする非同期機構の一実施例を図７に示す。一実施例では、ＬｏａｄＰｒｏｖｉｄｅｒ（）７０１およびＵｎｌｏａｄＰｒｏｖｉｄｅｒ（）７９９は、コンテキスト・アウェア・プラットホーム１００が対応するオペレーティング・システムによって実施することができる。一実施例では、プロバイダ・マネージャ２８０は、ＬｏａｄＰｏｖｉｄｅｒ（）７０１−１，７０１−２を呼び出して、特有のコンテキスト・プロバイダ２５０をロードすることができ、またＵｎｌｏａｄＰｒｏｖｉｄｅｒ（）７９９−１，７９９−２を呼び出して、以前にロードしたコンテキスト・プロバイダ２５０をアンロードすることができる。一実施例では、プロバイダ・マネージャ２８０によって決定される通り、コンテキスト・プロバイダ２５０をロードおよびアンロード、ならびに再ロードすることができる。一実施例では、ＬｏａｄＰｒｏｖｉｄｅｒ（）７０１−１，７０１−２ならびにＵｎｌｏａｄＰｒｏｖｉｄｅｒ（）７９９−１，７９９−２というメソッドがプロバイダＡＰＩの一部分ではないことを示すために、ＬｏａｄＰｒｏｖｉｄｅｒ（）７０１−１，７０１−２ならびにＵｎｌｏａｄＰｒｏｖｉｄｅｒ（）７９９−１，７９９−２を、２５０を表す線の外側に示す。

一実施例では、プロバイダ・マネージャ２８０は、ＳｔａｒｔＰｒｏｖｉｄｅｒ（）メソッド７０５を呼び出して、コンテキスト・プロバイダ２５０−１に初期化を実行させることができる。これは、最初の初期化段階中に実行することはできない。一実施例では、プロバイダ・マネージャ２８０は、ＡｃｔｉｖａｔｅＣｏｎｔｅｘｔ（ｓｔｒｉｎｇＡ）メソッド７１０−１およびＡｃｔｉｖａｔｅＣｏｎｔｅｘｔ（ｓｔｒｉｎｇＡ）メソッド７１０−２を実行することができる。これらのメソッドは、コンテキスト・プロバイダ２５０−１に対して、コンテキスト・アウェア・プラットホーム１００が使用できる識別子を示すことができる。一実施例では、プロバイダ・マネージャ２８０は、非同期データ通知の場合に使用できるＧｅｔＰｒｏｖｉｄｅｒＮｏｔｉｆｉｅｒ（Ｓｔｒｉｎｇ）７２０を呼び出すことができる。一実施例では、プロバイダ・マネージャ２８０は、ＲｅｇｉｓｔｅｒＯｂｓｅｒｖｅｒ（ＰｒｏｖｉｄｅｒＤａｔａＯｂｓｅｒｖｅｒ^＊）メソッド７２５を使用することができ、その結果、メソッド７２５へのポインタをＲｅｇｉｓｔｅｒＯｂｓｅｒｖｅｒ（）に渡して、事象通知を開始することができる。

一実施例では、コンテキスト・プロバイダ２５０−１は、ＥｖｅｎｔＣｏｎｔｅｘｔＵｐｄａｔｅＡｖａｉｌａｂｌｅ（ＳｔｒｉｎｇＡ）７３０−１およびＥｖｅｎｔＣｏｎｔｅｘｔＵｐｄａｔｅＡｖａｉｌａｂｌｅ（ＳｔｒｉｎｇＢ）７３０−２を呼び出して、コンテキスト・プロバイダ２５０−１によって提供された以前の報告後のａＣｏｎｔｅｘｔＮａｍｅに関連するデータの変更について、プロバイダ・マネージャ２８０に知らせることができる。一実施例では、コンテキスト・プロバイダ２５０−１は、ＥｖｅｎｔＣｏｎｔｅｘｔＵｐｄａｔｅＡｖａｉｌａｂｌｅ（ＳｔｒｉｎｇＡ）７３０−１およびＥｖｅｎｔＣｏｎｔｅｘｔＵｐｄａｔｅＡｖａｉｌａｂｌｅ（ＳｔｒｉｎｇＢ）７３０−２を複数回呼び出すことができ、図７では、コンテキスト・プロバイダ２５０−１がＥｖｅｎｔＣｏｎｔｅｘｔＵｐｄａｔｅＡｖａｉｌａｂｌｅ（Ｓｔｒｉｎｇ）を３回、７３０−１，７３０−２ならびに７５９を呼び出すことを示す。

一実施例では、プロバイダ・マネージャ２８０は、ＧｅｔＤａｔａ（ＳｔｒｉｎｇＢ，Ｌｏｃａｔｉｏｎ，ＤａｔｅＴｉｍｅ）７５０−１およびＧｅｔＤａｔａ（ＳｔｒｉｎｇＡ，Ｌｏｃａｔｉｏｎ，ＤａｔｅＴｉｍｅ）７５０−２を複数回呼び出して、コンテキスト・プロバイダ２５０−１からコンテキスト情報を取得することができる。一実施例では、ＧｅｔＤａｔａ（）は、（文字列型の）コンテキスト情報、位置の詳細、および日時の詳細とともに戻ることができる。一実施例では、ＧｅｔＤａｔａ（）メソッドへの複数の呼出しを、呼出し７５０−１，７５０−２，７６０によって表すことができる。

一実施例では、プロバイダ・マネージャ２８０は、ＩＰｒｏｖｉｄｅｒＤａｔａＯｂｓｅｒｖｅｒインターフェイスへのポインタをＲｅｍｏｖｅＯｂｓｅｒｖｅｒ（）へ渡すようにＲｅｍｏｖｅＯｂｓｅｒｖｅｒ（ＩＰｒｏｖｉｄｅｒＯｂｓｅｒｖｅｒ^＊）７５２を使用して、通知を終了することができる。一実施例では、次いでプロバイダ・マネージャ２８０は、ＤｅａｃｔｉｖａｔｅＣｏｎｔｅｘｔ（ｓｔｒｉｎｇＡ）メソッド７５３−１およびＤｅａｃｔｉｖａｔｅＣｏｎｔｅｘｔ（ｓｔｒｉｎｇＡ）メソッド７５３−２を実行して識別子を非活性化させることができ、これらの識別子は、コンテキスト・アウェア・プラットホーム１００には使用することができなくなる。一実施例では、次いでプロバイダ・マネージャ２８０は、ＳｔｏｐＰｒｏｖｉｄｅｒ（）７５４を呼び出してから、ＵｎｌｏａｄＰｒｏｖｉｄｅｒ（）７９９−１を使用してコンテキスト・プロバイダ２５０−１をアンロードすることができる。一実施例では、ＡｃｔｉｖａｔｅＣｏｎｔｅｘｔ（ＳｔｒｉｎｇＡ）７１０−１およびＡｃｔｉｖａｔｅＣｏｎｔｅｘｔ（ＳｔｒｉｎｇＢ）７１０−２は、たとえば、それぞれセンサ２１０−Ａ，２１０−Ｂを活性化させることができる。一実施例では、ＤｅａｃｔｉｖａｔｅＣｏｎｔｅｘｔ（ＳｔｒｉｎｇＡ）７５３−１およびＤｅａｃｔｉｖａｔｅＣｏｎｔｅｘｔ（ＳｔｒｉｎｇＢ）７５３−２は、たとえば、それぞれセンサ２１０−Ａ，２１０−Ｂを非活性化させることができる。

ＵｎｌｏａｄＰｒｏｖｉｄｅｒ（）７９９−１とＬｏａｄＰｒｏｖｉｄｅｒ（）７０１−２の間は、プロバイダ・マネージャ２８０およびコンテキスト・プロバイダ２５０は、それぞれＧｅｔＤａｔａ（）およびＥｖｅｎｔＣｏｎｔｅｘｔＵｐｄａｔｅＡｖａｉｌａｂｌｅ（）７３０というメソッドを呼び出すことができない。一実施例では、ＬｏａｄＰｒｏｖｉｄｅｒ（）７０１−２を実行することによってコンテキスト・プロバイダ２５０を再ロードできるようになった後、ＳｔａｒｔＰｒｏｖｉｄｅｒ（）７５５、ＡｃｔｉｖａｔｅＣｏｎｔｅｘｔ（ＳｔｒｉｎｇＡ）７５６−１、ＡｃｔｉｖａｔｅＣｏｎｔｅｘｔ（ＳｔｒｉｎｇＢ）７５６−２、ＧｅｔＰｒｏｖｉｄｅｒＮｏｔｉｆｉｅｒ（ＳｔｒｉｎｇＡ）７５７、ＲｅｇｉｓｔｅｒＯｂｓｅｒｖｅｒ（ＩＰｒｏｖｉｄｅｒＤａｔａＯｂｓｅｒｖｅｒ^＊）７５８、ＥｖｅｎｔＣｏｎｔｅｘｔＵｐｄａｔｅＡｖａｉｌａｂｌｅ（ＳｔｒｉｎｇＡ）７５９、ＧｅｔＤａｔａ（ＳｔｒｉｎｇＡ，Ｌｏｃａｔｉｏｎ，ＤａｔｅＴｉｍｅ）７６０、ＲｅｍｏｖｅＯｂｓｅｒｖｅｒ（ＩＰｒｏｖｉｄｅｒＯｂｓｅｒｖｅｒ^＊）７８０、ＤｅａｃｔｉｖａｔｅＣｏｎｔｅｘｔ（ＳｔｒｉｎｇＡ）７８５−１およびＤｅａｃｔｉｖａｔｅＣｏｎｔｅｘｔ（ＳｔｒｉｎｇＢ）７８５−２、ならびにＳｔｏｐＰｒｏｖｉｄｅｒ（）７９０などの事象シーケンスを呼び出してから、ＵｎｌｏａｄＰｒｏｖｉｄｅｒ（）７９９−２によってコンテキスト・プロバイダ２５０−１をアンロードすることができる。

図８を参照すると、コンテキスト・アウェア・プラットホーム１００に対応するコンピュータ・システム８００は、プロセッサ８０２およびグラフィックス・プロセッサ・ユニット（ＧＰＵ）８０５を備えることができる。プロセッサ８０２は、単一命令複数データ（ＳＩＭＤ）、縮小命令セット（ＲＩＳＣ）、およびそのような他の類似の汎用プロセッサを含むことができる。一実施例では、プロセッサ８０２は、命令シーケンスを処理して、コンテキスト・プロバイダ２５０、プロバイダ・マネージャ２８０、およびクライアント１８０に対するコードを提供しかつ実行することができる。これらのコードは、機械読取り可能な記憶媒体８２５内に格納することができる。しかし、この命令シーケンスは、また、メモリ８２０内または任意の他の適切な記憶媒体内に格納することもできる。

コンピュータ・システム８００を動作させるプロセッサ８０２は、論理回路８３０に結合された１つまたは複数のプロセッサ・コアとすることができる。一実施例では、プロセッサ８１０は、中央演算処理装置およびメモリ・サブシステムを備えることができる。一実施例では、コンテキスト・プロバイダ２５０およびプロバイダ・マネージャ２８０はともに、コンテキスト・プロバイダ２５０を動的にロードおよび／またはアンロードする統一された手法を提供することができ、この手法は、センサ２１０、およびセンサ２１０をコンテキスト・アウェア・プラットホーム１００に結合させるロードされた状態のコンテキスト・プロバイダ２５０によって消費される電力、メモリ空間などの資源を節約しながら、センサ２１０を活性化および／または非活性化させることができる。

一実施例では、論理回路８３０は、たとえば、チップセット論理回路とすることができる。論理回路８３０はメモリ８２０に結合される。メモリ８２０は、光学、磁気、または半導体記憶装置を含む任意の種類の記憶装置とすることができる。入出力デバイス８６０は、コンピュータ・システム８００をセンサ２１０−Ａ〜２１０−Ｎなどのデバイスに接続させることができる。

本発明の特定の特徴について、例示的な実施例を参照して説明した。しかし、この説明は、限定的な意味で解釈されるものではない。本発明が関係する当業者には明らかである例示的な実施例の様々な修正、ならびに本発明の他の実施例は、本発明の思想および範囲内に入るものと見なされる。

１００コンテキスト・アウェア・プラットホーム
１１０センサ複合体
１５０制御エンジン
１８０クライアント
２１０センサ
２２０クライアント・インターフェイス
２４０制御論理回路
２５０コンテキスト・プロバイダ
２８０プロバイダ・マネージャ
８００コンピュータ・システム
８０２プロセッサ
８２０メモリ
８３０論理回路
８６０入出力デバイス

Claims

コンテキスト・アウェア・プラットホーム内で複数のセンサを取り扱う方法において、
プロバイダ・マネージャと複数のコンテキスト・プロバイダとの間の通信を可能にするアプリケーション・プログラミング・インターフェイスを提供する段階と、
前記複数のセンサの予測される使用レベルに基づいてヒント信号を生成する段階であって、前記ヒント信号は前記複数のセンサの好ましい活動レベルを指定する、段階と、
前記ヒント信号のロード領域内に第１の値が格納されている場合、前記複数のコンテキスト・プロバイダのうちの１つのコンテキスト・プロバイダをロードする段階と、
前記ヒント信号の前記ロード領域内に第２の値が格納されている場合、前記コンテキスト・プロバイダをアンロードする段階と、
を含むことを特徴とする方法。
前記第１の組のセンサに対する前記好ましい活動レベルが前記ヒント信号内で活性化状態に設定されている場合、前記コンテキスト・プロバイダに結合された第１の組のセンサを活性化させる段階であって、前記複数のセンサは前記第１の組のセンサを含む、段階を含むことを特徴とする請求項１記載の方法。
前記第２の組のセンサに対する前記好ましい活動レベルが前記ヒント信号内で非活性化状態に設定されている場合、前記コンテキスト・プロバイダに結合された第２の組のセンサを非活性化させる段階であって、前記複数のセンサは前記第２の組のセンサを含む、段階を含むことを特徴とする請求項２記載の方法。
前記アプリケーション・プログラミング・インターフェイスを使用して、前記第１の組のセンサからコンテキスト情報を取得する段階をさらに含むことを特徴とする請求項２記載の方法。
前記コンテキスト・プロバイダと前記プロバイダ・マネージャとの間の前記通信は、同期アクセス機構を含むことを特徴とする請求項４記載の方法。
前記コンテキスト・プロバイダと前記プロバイダ・マネージャの間の前記通信は、非同期アクセス機構を含むことを特徴とする請求項４記載の方法。
前記第１の組のセンサのうちの１つのセンサに関する前記コンテキスト情報をクライアント・エンティティのうちの第１のクライアントに転送する段階であって、前記センサは前記第１のクライアントに論理的に結合される、段階をさらに含むことを特徴とする請求項４記載の方法。
前記第１の組のセンサおよび前記第２の組のセンサの前記好ましい活動レベルが前記ヒント信号内で非活性化状態に設定されている場合、前記コンテキスト・プロバイダをアンロードする段階をさらに含むことを特徴とする請求項３記載の方法。
前記クライアント・エンティティによる前記第１および第２の組のセンサの使用パターンを追跡することによって、前記第１および第２の組のセンサに対する前記予測される使用レベルを決定する段階をさらに含むことを特徴とする請求項１記載の方法。
前記使用パターンに基づいて、推測により、センサを活性化させてすでに活性化させた状態を保つ段階であって、前記使用パターンは、前記クライアント・エンティティによって前記複数のセンサが使用される確率を示す確率値と前記クライアント・エンティティによって前記複数のセンサが使用される頻度を示す頻度値とをさらに含む、段階からなることを特徴とする請求項９記載の方法。
コンテキスト・アウェア・プラットホーム内でセンサを取り扱うシステムにおいて、
複数のコンテキスト・プロバイダに結合されたプロバイダ・マネージャを含むコンテキスト・エンジンであって、前記プロバイダ・マネージャは、前記プロバイダ・マネージャと前記複数のコンテキスト・プロバイダとの間の通信を可能にするアプリケーション・プログラミング・インターフェイスを提供する、コンテキスト・エンジンを備え、
前記プロバイダ・マネージャは、前記センサの予測される使用レベルに基づいて、前記センサの好ましい活動レベルを指定するヒント信号を生成し、
前記ヒント信号のロード領域内に第１の値が格納されている場合、前記プロバイダ・マネージャは、前記複数のコンテキスト・プロバイダのうちの１つのコンテキスト・プロバイダをロードし、
前記ヒント信号の前記ロード領域内に第２の値が格納されている場合、前記プロバイダ・マネージャは、前記コンテキスト・プロバイダをアンロードし、
第１の組および第２の組の前記センサは、前記コンテキスト・プロバイダに結合される、
ことを特徴とするシステム。
前記第１の組のセンサに対する前記好ましい活動レベルが前記ヒント信号内で活性化状態に設定されている場合、前記コンテキスト・プロバイダは、前記複数のセンサのうちの前記第１の組のセンサを活性化させ、前記第１の組のセンサは、前記コンテキスト・プロバイダに結合されることを特徴とする請求項１１記載のシステム。
前記第２の組のセンサの前記好ましい活動レベルが前記ヒント信号内で非活性化状態に設定されている場合、前記コンテキスト・プロバイダは、前記複数のセンサのうちの前記第２の組のセンサを非活性化させ、前記第２の組のセンサは、前記コンテキスト・プロバイダに結合されることを特徴とする請求項１２記載のシステム。
前記コンテキスト・プロバイダは、前記第１の組のセンサからコンテキスト情報を獲得し、その後前記コンテキスト情報を前記プロバイダ・マネージャに提供することを特徴とする請求項１２記載のシステム。
前記プロバイダ・マネージャおよび前記コンテキスト・プロバイダは、同期アクセス機構を使用して通信することを特徴とする請求項１４記載のシステム。
前記プロバイダ・マネージャおよび前記コンテキスト・プロバイダは、非同期アクセス機構を使用して通信することを特徴とする請求項１４記載のシステム。
制御論理回路およびクライアント・インターフェイスをさらに備えるシステムであって、前記制御論理回路は、前記プロバイダ・マネージャおよび前記クライアント・インターフェイスに結合され、前記クライアント論理回路は、前記プロバイダ・マネージャから受け取った前記コンテキスト情報および前記制御論理回路から受け取った制御信号に基づいて、前記第１の組のセンサのうちの１つのセンサに関する前記コンテキスト情報をクライアント・エンティティのうちの第１のクライアントに転送し、前記センサは、前記第１のクライアントに論理的に結合されることを特徴とする請求項１４記載のシステム。
前記第１の組のセンサおよび前記第２の組のセンサの前記好ましい活動レベルが非活性化状態に設定されている場合、前記プロバイダ・マネージャは、第１のコンテキスト・プロバイダをアンロードすることを特徴とする請求項１３記載のシステム。
前記プロバイダ・マネージャは、前記クライアント・エンティティの使用パターンを追跡することによって、前記センサの前記予測される使用レベルを決定することを特徴とする請求項１１記載のシステム。
前記プロバイダ・マネージャは、前記使用パターンに基づいて、推測により、センサを活性化させてすでに活性化させた状態を保ち、前記使用パターンは、前記クライアント・エンティティによって前記複数のセンサが使用される確率を示す確率値と前記クライアント・エンティティによって前記複数のセンサが使用される頻度を示す頻度値とを含む、段階からなることを特徴とする請求項１９記載のシステム。
コンテキスト・アウェア・プラットホーム内で複数のセンサを取り扱う複数の命令を含む機械読取り可能な記憶媒体であって、プロセッサ内で実行された結果に応答して、
プロバイダ・マネージャと複数のコンテキスト・プロバイダとの間の通信を可能にするアプリケーション・プログラミング・インターフェイスを提供する段階と、
前記複数のセンサの予測される使用レベルに基づいて、前記複数のセンサの好ましい活動レベルを指定するヒント信号を生成する段階と、
前記ヒント信号のロード領域内に第１の値が格納されている場合、前記複数のコンテキスト・プロバイダのうちの１つのコンテキスト・プロバイダをロードする段階と、
前記ヒント信号の前記ロード領域内に第２の値が格納されている場合、前記コンテキスト・プロバイダをアンロードする段階と、
を実行する命令を含むことを特徴とする機械読取り可能な記憶媒体。
前記ヒント信号内で第１の組のセンサに対する前記好ましい活動レベルが活性化状態に設定されている場合、前記コンテキスト・プロバイダに結合された第１の組のセンサを活性化させる段階を含む機械読取り可能な記憶媒体であって、前記複数のセンサは、前記第１の組のセンサを含むことを特徴とする請求項２１記載の機械読取り可能な記憶媒体。
前記ヒント信号内で第２の組のセンサに対する前記好ましい活動レベルが非活性化状態に設定されている場合、前記コンテキスト・プロバイダに結合された第２の組のセンサを非活性化させる段階を含む機械読取り可能な記憶媒体であって、前記複数のセンサは、前記第２の組のセンサを含むことを特徴とする請求項２２記載の機械読取り可能な記憶媒体。
前記アプリケーション・プログラミング・インターフェイスを使用して、前記第１の組のセンサからコンテキスト情報を取得する段階をさらに含むことを特徴とする請求項２２記載の機械読取り可能な記憶媒体。
前記コンテキスト・プロバイダと前記プロバイダ・マネージャの間の前記通信は、同期アクセス機構を含むことを特徴とする請求項２４記載の機械読取り可能な記憶媒体。
前記コンテキスト・プロバイダと前記プロバイダ・マネージャとの間の前記通信は、非同期アクセス機構を含むことを特徴とする請求項２４記載の機械読取り可能な記憶媒体。
前記第１の組のセンサのうちの１つのセンサに関する前記コンテキスト情報をクライアント・エンティティのうちの第１のクライアントに転送する段階をさらに含む機械読取り可能な記憶媒体であって、前記センサは、前記第１のクライアントに論理的に結合されることを特徴とする請求項２４記載の機械読取り可能な記憶媒体。
前記第１の組のセンサおよび前記第２の組のセンサの前記好ましい活動レベルが前記ヒント信号内で非活性化状態に設定されている場合、前記コンテキスト・プロバイダをアンロードする段階をさらに含むことを特徴とする請求項２３記載の機械読取り可能な記憶媒体。
前記クライアント・エンティティによる前記第１および第２の組のセンサの使用パターンを追跡することによって、前記第１および第２の組のセンサに対する前記予測される使用レベルを決定する段階をさらに含むことを特徴とする請求項２１記載の機械読取り可能な記憶媒体。
前記使用パターンに基づいて、推測により、センサを活性化させてすでに活性化させた状態を保つ段階をさらに含む機械読取り可能な記憶媒体であって、前記使用パターンは、前記クライアント・エンティティによって前記複数のセンサが使用される確率を示す確率値と前記クライアント・エンティティによって前記複数のセンサが使用される頻度を示す頻度値とを含む、段階からなることを特徴とする請求項２９記載の機械読取り可能な記憶媒体。