(57)【要約】【課題】リモート・サーバにおける相関または学習に基づくクライアント装置の局所的適応化のための技術が開示される。【解決手段】例えば、クライアント装置（１０２）がデータを収集してデータをサーバ（１０８）に送信するデータ収集システム（１００）においてクライアント装置の動作を改変する方法は、次のステップを含む。クライアント装置はデータをサーバに送信（２０４）する。サーバは、クライアント装置の動作に対する改変を表す情報を生成（２０６）するために、クライアント装置から受け取ったデータの少なくとも一部分を使用する。サーバ装置は、生成した情報をクライアント装置に送信（２０８）する。クライアント装置は、その後、サーバから受け取った情報に基づいてクライアント装置の動作を変更する。【選択図】図２
2009540445.tif 000002
【特許請求の範囲】
【請求項１】
データ収集システムにおいて、データを収集してデータをサーバに送信するクライアント装置の動作を改変する方法であって、
前記クライアント装置がデータを前記サーバに送信するステップと、
前記サーバが、前記クライアント装置の動作に対する改変を表す情報を生成するために、前記クライアント装置から受け取った前記データの少なくとも一部分を使用するステップと、
前記サーバが、生成された前記情報を前記クライアント装置に送信するステップと、
前記クライアント装置が、その後、前記サーバから受け取った前記情報に基づいて前記クライアント装置の前記動作を変更するステップと、
を含む方法。
【請求項２】
前記サーバに送信される前記データは１つ以上のデータ・サンプルを含む、請求項１に記載の方法。
【請求項３】
前記サーバに送信される前記データは、前記１つ以上のデータ・サンプルの改変された統計を含む、請求項２に記載の方法。
【請求項４】
前記サーバに送信される前記データは、前記１つ以上のデータ・サンプルの圧縮されたバージョンを含む、請求項２または請求項３に記載の方法。
【請求項５】
前記サーバが、前記クライアント装置から受け取った前記データの少なくとも一部分から少なくとも１つのパターンを判定するステップをさらに含む、前記請求項のうちのいずれか１つに記載の方法。
【請求項６】
前記クライアント装置の動作に対する改変を表す前記生成された情報は、前記クライアント装置にアプリオリに格納されているルールを改変し、アクティブ化し、または非アクティブ化するコマンドを含む、前記請求項のうちのいずれか１つに記載の方法。
【請求項７】
前記クライアント装置の動作に対する改変を表す前記生成された情報は、前記クライアント装置にアプリオリに格納されているルールに影響を及ぼすコンテキスト・データを含む、請求項１ないし５のうちのいずれか１つに記載の方法。
【請求項８】
前記クライアント装置の動作に対する改変を表す前記生成された情報は生成されたルールを含む、請求項１ないし５のうちのいずれか１つに記載の方法。
【請求項９】
前記生成されたルールは、前記クライアント装置により収集されたデータに関連付けられた少なくとも１つの時間的パターンを表現する述語を含む、請求項８に記載の方法。
【請求項１０】
前記生成されたルールは、前記クライアント装置により収集されると期待されるデータの特性を表現する述語を含む、請求項８に記載の方法。
【請求項１１】
前記生成されたルールは、前記クライアント装置のインターフェースに対する改変を表現するアクションを含む、請求項８に記載の方法。
【請求項１２】
前記生成されたルールは、前記クライアント装置における特定のコンテンツの生成を表現するアクションを含む、請求項８に記載の方法。
【請求項１３】
前記生成されたルールは、前記クライアント装置に存在する特定のアプリケーションの動作またはコンテンツに対する改変を表現するアクションを含む、請求項８に記載の方法。
【請求項１４】
前記生成されたルールは、１つ以上の収集されたデータ・サンプルの送信、送信の抑制、または圧縮を表現するアクションを含む、請求項８に記載の方法。
【請求項１５】
前記生成されたルールは、データ変換を表現するアクションを含む、請求項８に記載の方法。
【請求項１６】
前記データ変換は、平均値算出操作、アウトライアー除去操作、圧縮操作、フィルタリング操作、および離散的係数表現のうちの少なくとも１つを含む、請求項１５に記載の方法。
【請求項１７】
前記サーバがルールを生成する前記ステップは、前記クライアント装置により局所的に決定され得ない属性を前記ルールの述語から除去することをさらに含む、請求項８に記載の方法。
【請求項１８】
前記サーバがルールを生成する前記ステップは、現存するルールの除去、現存するルールの洗練、および新しいルールの指定のうちの少なくとも１つを指定することをさらに含む、請求項８に記載の方法。
【請求項１９】
前記サーバは、前記クライアント装置の動作に対する改変を表す情報を生成するためにコンテキスト・データも使用する、前記請求項のうちのいずれか１つに記載の方法。
【請求項２０】
前記コンテキスト・データは、前記クライアント装置に関連付けられたユーザの属性に関連するコンテキストを表すデータを含む、請求項１９に記載の方法。
【請求項２１】
前記コンテキスト・データは、一人以上の他の個人またはエンティティーの外部コンテキストを表すデータを含む、請求項１９に記載の方法。
【請求項２２】
前記クライアント装置が装置リソースを監視し、それに基いて動作を調整することをさらに含む、前記請求項のうちのいずれか１つに記載の方法。
【請求項２３】
クライアント装置がそこにおいてデータを収集してデータをサーバに送信するところのデータ収集システムにおいて前記クライアント装置の動作を改変するために前記クライアント装置において用いられる方法であって、
前記クライアント装置の動作に対する改変を表す情報を生成するために前記クライアント装置から受け取られたデータの少なくとも一部分を前記サーバが使用し得るように前記データを前記サーバに送信するステップと、
その後に、前記サーバから受け取られた前記情報に基づいて前記クライアント装置の前記動作を変更するステップと、
を含む方法。
【請求項２４】
前記クライアント装置の動作に対する改変を表す前記生成された情報は、前記クライアント装置にアプリオリに格納されているルールを改変し、アクティブ化し、または非アクティブ化するコマンドを含む、請求項２３に記載の方法。
【請求項２５】
前記クライアント装置の動作に対する改変を表す前記生成された情報は、前記クライアント装置にアプリオリに格納されているルールに影響を及ぼすコンテキスト・データを含む、請求項２３に記載の方法。
【請求項２６】
前記クライアント装置の動作に対する改変を表す前記生成された情報は生成されたルールを含む、請求項２３に記載の方法。
【請求項２７】
前記クライアントが装置リソースを監視し、それに基いて動作を調整することをさらに含む、請求項２３に記載の方法。
【請求項２８】
クライアント装置がそこにおいてデータを収集してデータをサーバに送信するところのデータ収集システムにおいて前記クライアント装置の動作を改変するために前記サーバにおいて用いられる方法であって、
前記クライアント装置からデータを受け取るステップと、
前記クライアント装置の動作に対する改変を表す情報を生成するために前記クライアント装置から受け取られた前記データの少なくとも一部分を使用するステップと、
前記サーバから受け取られた前記情報に基づいて前記クライアント装置がその後に前記クライアント装置の前記動作を変更し得るように前記情報を前記クライアント装置に送信するステップと、
を含む方法。
【請求項２９】
前記クライアント装置の動作に対する改変を表す前記生成された情報は、前記クライアント装置にアプリオリに格納されているルールを改変し、アクティブ化し、または非アクティブ化するコマンドを含む、請求項２８に記載の方法。
【請求項３０】
前記クライアント装置の動作に対する改変を表す前記生成された情報は、前記クライアント装置にアプリオリに格納されているルールに影響を及ぼすコンテキスト・データを含む、請求項２８に記載の方法。
【請求項３１】
前記クライアント装置の動作に対する改変を表す前記生成された情報は生成されたルールを含む、請求項２８に記載の方法。
【請求項３２】
前記クライアントが装置リソースを監視し、それに基いて動作を調整する、請求項２８ないし３１のうちのいずれか１つに記載の方法。
【請求項３３】
前記サーバは、前記クライアント装置の動作に対する改変を表す情報を生成するためにコンテキスト・データも使用する、請求項２８ないし３２のうちのいずれか１つに記載の方法。
【請求項３４】
データ収集システムにおいて使用される装置であって、
クライアント装置を含み、前記クライアント装置は、
（ｉ）前記クライアント装置の動作に対する改変を表す情報を生成するために前記クライアント装置から受け取られたデータの少なくとも一部分をサーバが使用し得るように前記データを前記サーバに送信し、
（ｉｉ）その後に、前記サーバから受け取られた前記情報に基づいて前記クライアント装置の前記動作を変更するように構成されている、
前記データ収集システムにおいて使用される装置。
【請求項３５】
データ収集システムにおいて使用される装置であって、
サーバを含み、前記サーバは、
（ｉ）クライアント装置からデータを受け取り、
（ｉｉ）前記クライアント装置の動作に対する改変を表す情報を生成するために前記クライアント装置から受け取った前記データの少なくとも一部分を使用し、
（ｉｉｉ）前記サーバから受け取られた前記情報に基づいて前記クライアント装置がその後に前記クライアント装置の前記動作を変更し得るように前記情報を前記クライアント装置に送信するように構成されている、
前記データ収集システムにおいて使用される装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、クライアント／サーバ環境における情報収集および送信の分野に関し、特に、イベントの相関、ダイナミック・コンテキストの解釈または検出されたイベント・パターンの学習に基づくクライアント装置の局所的適応化のための技術に関する。
【背景技術】
【０００２】
多くの新しいコンピューティング・アプリケーションはセンサー装置のグループからのデータ生成およびリモート“シンク”ノードへの送信を必要とし、ここでその様なデータは集積され分析される。このようなアプリケーションは、ヘルスケア（この場合、装着可能なセンサが個人の種々のバイオメトリック測定値を記録し送信する）、車両テレマティックス（この場合、オンボード・センサが種々の車両パラメータを測定し、それらを中央診断サーバに送信する）およびインテリジェントな輸送システム（この場合、ハイウェイ・センサが交通状態を定期的に記録する）などの種々のリモート監視シナリオにおいてありふれてきている。
【発明の開示】
【発明が解決しようとする課題】
【０００３】
このようなデータ収集システムは、２つの重要な目標あるいは関心事を有する。第１に、これらのセンサー装置の多くはそれ自身がリソース制約形であるので（例えば、バッテリーで動作する）、システムは、通信またはデータ収集あるいはその両方のオーバーヘッドを最小にしてその様な装置のエネルギー消費を減らすのに資するべきである。第２に、これらの装置の多くは単なるレポーティング・ノードではなくて、相当の程度の処理パワーと局所インテリジェンスとを有する。構造上、このようなデータ収集システムは、リモート・シンク・ノード（またはサーバ）に（しばしば無線通信インフラストラクチャを用いて）接続されたクライアント・センサ装置のセットを含み、このシンク・ノードは現存する情報技術インフラストラクチャの一部である。
【０００４】
システムにとっては、これらのセンサ装置が通信インフラストラクチャから時折切り離され、従ってリモート・サーバと必ずしも通信しないというシナリオにおいても、該センサまたはクライアント装置において大した計算または通信の複雑さを必要とせずにこれらのセンサ装置が自分たちの動作を適切に適応させることを可能にすることが望ましいであろう。
【課題を解決するための手段】
【０００５】
本発明の諸側面は、リモート・サーバにおける相関または学習に基づくクライアント装置の局所的適応化のための技術を提供する。
【０００６】
例えば、本発明の一側面においては、データ収集システムにおいて、データを収集してデータをサーバに送信するクライアント装置の動作を改変する方法は、次のステップを含む。クライアント装置はデータをサーバに送信する。サーバは、クライアント装置の動作に対する改変を表す情報を生成するために、クライアント装置から受け取ったデータの少なくとも一部を使用する。サーバは、その生成された情報をクライアント装置に送信する。クライアント装置は、その後、サーバから受け取った情報に基づいてクライアント装置の動作を変える。
【０００７】
サーバに送信されるデータは、１つ以上のデータ・サンプルを含むことができる。さらに、サーバに送信されるデータは、その１つ以上のデータ・サンプルの改変された統計を含むことができる。さらに、サーバに送信されるデータは、その１つ以上のデータ・サンプルの圧縮されたバージョンを含むことができる。
【０００８】
該方法は、サーバが、クライアント装置から受け取ったデータの少なくとも一部から少なくとも１つのパターンを判定することをも含むことができる。例えば、一実施態様では、情報を生成するプロセスは、レポートされたデータ内のパターンを学習し、検出し、分析して将来のデータのパターンの確度を推定するための自動アルゴリズムの使用をさらに含むことができる。
【０００９】
クライアント装置の動作に対する改変を表す生成された情報は、クライアント装置にアプリオリに格納されているルールを改変し、アクティブ化しまたは非アクティブ化するコマンドを含むことができる。さらに、生成された情報は、クライアント装置にアプリオリに格納されているルールに影響を及ぼすコンテキスト・データを含むことができる。さらに、生成された情報は、生成されたルールを含むことができる。
【００１０】
生成されたルールは、クライアント装置により収集されたデータに関連付けられた少なくとも１つの時間的パターンを表現する述語を含むことができる。生成されたルールは、クライアント装置により収集されると期待されるデータの特性を表現する述語を含むことができる。さらに、生成されたルールは、クライアント装置のインターフェースに対する改変を表現するアクションを含むことができる。生成されたルールは、クライアント装置における特定のコンテンツの生成を表現するアクションを含むことができる。さらに、生成されたルールは、クライアント装置に存在する特定のアプリケーションの動作またはコンテンツに対する改変を表現するアクションを含むことができる。生成されたルールは、１つ以上の収集されたデータ・サンプルの送信、送信の抑制、または圧縮を表現するアクションを含むことができる。さらに、生成されたルールは、例えば、平均値算出操作、アウトライアー除去操作、圧縮操作、フィルタリング操作、離散的係数表現（例えば、スプライン）などのデータ変換を表現するアクションを含むことができる。
【００１１】
サーバがルールを生成するステップは、クライアント装置により局所的に決定され得ない属性をルールの述語から除去することをさらに含むことができる。さらに、サーバがルールを生成するステップは、現存するルールの除去、現存するルールの洗練、および新しいルールの指定のうちの少なくとも１つを指定することを含むことができる。
【００１２】
サーバは、クライアント装置の動作に対する改変を表す情報を生成するためにコンテキスト・データを使用することもできる。該コンテキスト・データは、クライアント装置に関連付けられたユーザの属性に関連するコンテキストを表すデータを含むことができる。該コンテキスト・データは、一人以上の他の個人またはエンティティーの外部コンテキストを表すデータを含むことができる。
【００１３】
該方法は、クライアント装置が装置リソースを監視し、それに基いて動作を調整することをさらに含むことができる。
【００１４】
有利なことに、本発明の例証となる原理は、別のサーバからクライアント装置に伝達される動的ルールに基づいて、そのデータ伝送速度あるいはローカル・アラートの生成などの、クライアント送信装置の動作の或る側面を動的に変えるための方法を提供する。代わりに、サーバは複数のルールをオフラインまたは静的な仕方で伝達することができ、その様なアプリオリにダウンロードされたルールのセットをアクティブ化しあるいは非アクティブ化するようにクライアント装置に動的に信号することができる。
【００１５】
これらの動的ルールは、普通は、外部コンテキスト・データに基づいて、あるいは装置により前もって送信された情報に基づいて生成されることができ、そして、通例、センサが生成するかあるいは中間のクライアント・ゲートウェイ装置が個々のセンサから受け取るデータ・サンプルの予期されるパターンを（これについては、しばしば、なんらのアクションも必要とされない）、または予期されないデータ・パターンを（これについては特定のアクションが望まれる）装置に知らせることができる。さらに、ルールは、コンテキスト・データ（クライアント装置のリソース、局所的にクライアント装置が利用し得るコンテキスト属性（ｃｏｎｔｅｘｔｕａｌ  ａｔｔｒｉｂｕｔｅｓ）、クライアント装置により収集されたデータを含むが、これらに限定されない）に関連している述語を持つことができ、クライアント装置は、その様な述語が妥当であるときを認識するためにイベントを処理するように期待され得る。同様に、ルールのアクション部分は、センサからのデータ収集動作（そのレポーティング頻度、解像度など）、データ送信動作（送信される統計量のタイプ、使用される損失のあるまたは損失の無い圧縮の量など）、あるいはクライアント装置の動作（カレンダ・エントリ、アラームのセッティングなど）の改変を含むことができる。
【００１６】
本発明のこれらのおよび他の目的、特徴および利点は、その実施例についての以下の詳細な説明から明らかとなろう。それは添付図面と関連して読まれるべきである。
【発明を実施するための最良の形態】
【００１７】
以下ではヘルスケア環境の文脈で本発明が説明されるけれども、本発明がその様には限定されないということが理解されるべきである。むしろ、本発明は、コンテキストに基づいてクライアント装置の動作の局所的適応化を提供することが望ましい任意の環境により広く応用可能である。本書において使用される“コンテキスト”という用語は、ユーザまたはセンサ装置あるいはその両方と、ユーザにより使用される通信装置との物理的なまたは仮想的な環境に関する情報を指すと広く理解される。
【００１８】
本書において例示的に用いられる“クライアント装置”（あるいは単に“クライアント”）という句は１つ以上のセンサ装置と、１つ以上の直接接続されているセンサ装置（図１に関して以下で例証され記載される）のためにクライアント装置として動作する中間のゲートウェイ装置との組み合わせを指すことができるということが認識されるべきである。センサとゲートウェイとは別々の装置であっても良いが、その代わりにこれらは結合されて単一の装置とされても良い。以下の例証的記述において、記述がセンサまたはゲートウェイに言及しているとき、明らかであろう。しかし、時には、記述を容易にするために、センサまたはゲートウェイは単独でクライアントまたはクライアント装置と一般的に称され得る。
【００１９】
装置が通信インフラストラクチャから時折切り離され、従ってリモート・サーバと必ずしも通信しないというシナリオにおいても、センサ装置が、自分が集めるデータに基づいて自分自身の動作を適切に適応させることを情報収集および送信（データ収集）システムが可能にすることがのぞましであろうということが理解される。
【００２０】
しかし、エネルギー効率的適応化および適切なクライアント動作改変の問題は絡み合っているということも理解されるべきである。基本的に、エネルギー効率的通信技術は、周囲動作条件下では、センサ・ネットワークにより集められるデータの多くが“予期される”あるいは“予測可能”である（情報理論の文献では、非常に低い条件付きエントロピーを有する）という観察結果に依拠している。もしこれらの“データの予期されるパターン”がクライアント装置とサーバとの両方にアプリオリに知られていて、何か変則的なことが発生したという稀な場合のためにだけ情報が送信されるならば、エネルギーおよび処理の相当な節約を達成することができる。しかし、多くのアプリケーションにおいて、“予期される”データ・パターンは、時間変化し、またセンサ装置のコンテキスト上の状態だけではなくて、多様な外部入力にも依存する。
【００２１】
従って、クライアント装置の動作に対する適切な時間変化する改変を決定し、その後に、これらの望ましい改変をクライアントに知らせるために、このようなセンサ・ベースのアプリケーションのエネルギー効率的動作がバックエンド情報技術（ＩＴ）インフラストラクチャ内の付加的なインテリジェンスに依存するということがさらに認識される。望ましい特定の改変は、しばしば、（ａ）個々のアプリケーションの特定の特性と、（ｂ）クライアント装置に知られていないかまたはクライアント装置が利用できないか、あるいは通信オーバーヘッドに関して高価すぎるか、あるいは、変化する可能性のあるコンテキスト・ソースとインターフェースすることによってクライアント装置が直接検索するには計算上複雑すぎる、付加的な、動的に変化する可能性のあるコンテキスト上の情報とに依存するので、この付加的なインテリジェンスが必要とされる。
【００２２】
監視される患者が装着する心拍数モニタとグルコース・モニタという２つの医療センサ装置の例を考察する。遠隔監視を可能にするために、装置は、患者の読取り値を毎分１回サンプリングし、このデータを広域無線インターフェース（例えば、ジェネラル・パケット・レディオ・サービスすなわちＧＰＲＳ、ユニバーサル・モバイル・テレコミュニケーションズ・システムすなわちＵＭＴＳ、あるいはＩＥＥＥ８０２．１１など）を介してバックエンド・インフラストラクチャに送信するようにプログラミングされ得る。代わりに、これらの体に装着される装置は、セル電話機などのローカル“ゲートウェイ”装置にこのデータを送信するためにブルートゥースのような低範囲、低電力無線技術を用いることができる。ゲートウェイは、データ収集装置として動作することができ、定期的にサンプリングされたデータをセルラ・インフラストラクチャを用いてサーバに送信することができる。このような取り決めが図１に示され、以下でさらに詳しく記述される。
【００２３】
リモート・サーバは、通例、異常なパターンを検出するためにこのデータを継続的に監視し、必要なときには、この入ってくるデータストリームの分析に基づいて行動上の改変（“あなたのグルコース・レベルが上がっているので、インシュリン注射を受ける”ように音声警報を発生させるなど）をトリガするようにゲートウェイ（または医療装置）に対して実際にコマンドを発することができる。特に、複雑な監視アプリケーションでは、リモート・サーバは、現在の読取り値に基づくだけではなくて、将来のサンプルがとるかもしれない値の推定または予測にも基づいてその様な警報を発生させる（または、クライアント装置の動作を改変するための他の指示を発する）予測コンポーネントを含む。
【００２４】
例えば、本発明のリモート・ヘルスケア監視アプリケーションの一実施態様では、サーバは、グルコース・レベルが実際に臨界の閾値を越えたときに単に“事後”警報を発生させるのではなくて、グルコース・レベルが今後３０分以内に許容可能レベルより上がりそうだということを検出したときに早期可聴警報を発生させるために傾向分析を実行することができる。さらに、この臨界閾値の実際の値は患者に依存するかもしれない。例えば、サーバは、糖レベルの異常な急上昇をもたらす可能性のある薬物治療を患者Ａが現在受けていると知っていることができ、従って、そうでない場合よりも低い閾値で患者Ａのために警報をトリガすることができる。
【００２５】
上記の例は、センサ装置（または集積を行うローカル・ゲートウェイ装置）からリモート・サーバへの定期的送信の必要性と、センサ装置の、またはセンサ・データストリームの中間集積として動作するクライアント装置の適切な動作上の改変をリモート・サーバが発しあるいはトリガする必要性との両方を説明している。しかし、遠隔監視のこのような適用は、（ａ）センサ装置によるその様なデータ・サンプルの継続的送信の高いエネルギー・オーバーヘッドと、（ｂ）（しばしば、変化する無線通達範囲またはクライアント装置の移動の結果としての）サーバとクライアント装置との間の断続的な、そしてしばしば予測不可能な、ネットワーク切断とによってしばしば妨げられる。
【００２６】
センサからシンクへの通信トラフィックを減少させる１つの技術は、各センサに関連付けられた精密範囲または間隔という考えを使用する。このようなアプローチは、本質的に、センサのデータの精密な値に関する不確定性を、指定された値に束縛した。精密範囲は、データ・サンプルがこの指定された範囲の外へ出るまではセンサがそのデータ・サンプルをシンクに伝達しなくても良いように、不確定性の容認可能なレベルを指定する。精密範囲は、環境状態の精密な値を知る必要がなくて、ある量の可変性あるいは不正確さ（そのアプリケーションについての許容範囲基準）を許容することのできる多くの現実のアプリケーションにおいて特に有益である。
【００２７】
例えば、人のグルコース読取り値を監視するアプリケーションは＋／−５の許容誤差を示すことができるが、このことは、センサが例えば１３０の値でサーバに報告した後、その後のデータ・サンプルが１３５を上回るかあるいは１２５より下がるかするまではそれがその後のデータ・サンプルをシンクに伝達しなくても良いということを意味する。明らかに、より広い範囲はセンサの報告頻度を減少させ、通信オーバーヘッドを低下させる。なぜならば、サンプリングされた値の、しばしばノイズまたは環境一過性事象に起因する多くの小さな変動は、指定された間隔の中にあるからである。
【００２８】
“永続的クエリのためのセンサ・レポーティング範囲の効率的で集団的な調整のための方法（Ｍｅｔｈｏｄ  ｆｏｒ  Ｅｆｆｉｃｉｅｎｎｔ  ａｎｄ  Ｃｏｌｌｅｃｔｉｖｅ  Ａｄｊｕｓｔｍｅｎｔ  ｏｆ  Ｓｅｎｓｏｒ  Ｒｅｐｏｒｔｉｎｇ  Ｒａｎｇｅｓ  ｆｏｒ  Ｌｏｎｇ−Ｌｉｖｅｄ  Ｑｕｅｒｉｅｓ）”と題されて２００６年３月１日に出願された出願番号１１／３６５，２１５（代理人整理番号ＹＯＲ９２００６００２５ＵＳ１）として特定される米国特許出願（その開示内容は参照により本書に組み込まれる）は、複数のセンサから計算された総合的統計量（平均値、最大値あるいは最小値など）に関係するアプリケーションにおいて許容誤差を設定するための技術を開示している。各々のセンサにおいてアプリケーションの許容誤差範囲をどの様に精密範囲に分割するかを示しているほかに、上で引用された米国特許出願は、データ・サンプルにおける予測可能な時間的変動を明らかにするためにその様な範囲がどの様に自動的に改変され得るかをも開示している。しかし、上で引用された米国特許出願は、特定のセンサの値についてのアプリケーションの許容範囲が様々な外部コンテキストに起因して動的に変化し得るという可能性を考慮せずにこの精密範囲を作ることに焦点を当てている。
【００２９】
例えば（例えばアクティブ無線周波数ＩＤすなわちＲＦＩＤタグなどの付加的な位置認識技術を用いることによって）患者Ａが現在ジムでトレッドミルの上にいることにサーバが気づいたならば、サーバは、この患者の“標準”心拍数範囲が今は周囲［７０−８５］ではなくて［１２０，１３５］であると判定することができる。さらに、上で引用された米国特許出願において精密範囲は、通信オーバーヘッドを最小にする方法だけに焦点を当てていて、センサ（またはゲートウェイ）装置の他の動作側面自体が生成されたデータと外部コンテキストとの組み合わせに基づいてどの様に変化し得るか（例えば、“インシュリン警報”の発生）というより広範な問題を考慮していない。さらに、上で引用された米国特許出願は、複数のストリームの相関により、またはその様なストリームの損失のある／損失の無い圧縮を通して、個々のセンサにより生成されたデータストリームを中間の中継装置（クライアント装置）がどの様に改変し得るかを定義していない。
【００３０】
上記の例は、センシング装置により生成された過去のデータ・サンプルの値（これに限定はされない）を含むコンテキスト・データと装置ユーザに関連する動的な外部コンテキスト属性との組み合わせに基づいて複数のセンシング装置の通信および他の動作を改変し得ることから生じる利益を説明している。
【００３１】
インテリジェントなクライアント改変という私たちの所望の目標への１つのアプローチは、その様なコンテキスト認識コンピューティング・ミドルウェアを各クライアント装置に配置し、その様なミドルウェアを使用するために特定アプリケーション向けのロジックを書き、各クライアント装置に全ての関連するコンテキスト入力を受け取らせ処理させることであろう。しかし、その様なアプローチは、クライアント装置において相当のコンピューティング・リソース（強力な中央処理装置すなわちＣＰＵ、相当のメモリ）を必要とするだけではなくて、クライアントが今、しばしば連続的に、その様なコンテキスト・データを受け取らなければならないので、高い通信オーバーヘッドをクライアントに負わせる。
【００３２】
例えば、心拍数モニタの精密範囲を、その装着者がジムで運動しているときにインテリジェントに変更するためには、該モニタは、その装着者のＩＤで設定されなければならないだけではなくて、コンテキストの他のソースから他の種々の属性（その人の現在の位置など）を検索するために通信インフラストラクチャに頻繁にアクセスしなければならない。さらに、多くの場合に、コンテキスト・データのうちの或るもの（例えば、ヘルスケア・シナリオでは、患者の薬物治療歴）はプライバシー問題にとって微妙であるかあるいはプライバシー問題に左右されるかも知れず、信頼されている集中サーバにだけ直接利用可能にされ、個人、モバイル、センサ装置あるいは集積ゲートウェイには直接利用可能にされないかもしれない。最後に、コンテキスト・データ属性の値の変化に関する更新を頻繁に受け取るために、上記のアプローチは、個々のセンサ装置がインフラストラクチャ・ネットワークに連続的に接続されることを必要とするであろう。
【００３３】
広く言えば、任意のコンピューティング装置の任意のこのようなコンテキスト依存動作はルールを介して記述されることができ、その各ルールは、次のような構成コンポーネント、すなわち（ａ）該ルールがその下で有効であると考えられるところのコンテキスト条件（例えば、“現在の心拍数が１５０を越える”、“現在位置は１９スカイライン・ドライブである”など）の精密なセットを明示する“述語”コンポーネントと、（ｂ）結果としての装置の動作を明示する“アクション”コンポーネントと、を含む。上記の例は、（ａ）“述語”コンポーネントに対する時間変動する変化（例えば、ユーザがジムにいるときの許容範囲の改変）、または（ｂ）“アクション”コンポーネントに対する時間変動する変化（例えば、後に検索される“標準”サンプルのローカル記憶に対する“臨界”データの即時送信、または、バックエンド・サーバへ送信される前のデータストリームに使用される圧縮レベルの変更）を監視駆動アプリケーションのエネルギー効率的動作がどの様に必要とし得るかを説明していることに注意されたい。
【００３４】
従って、本発明の原理は、（ａ）全データ・サンプルの中央サーバへの連続的送信、（ｂ）センサ装置のネットワーク・インフラストラクチャへの連続的接続、あるいは（ｃ）その様な改変をトリガするために必要とされる全コンテキスト・データのセンサ装置または中間クライアント・ゲートウェイ装置による直接検索を必要とせずに種々のコンテキスト（個々のセンサにより報告されたデータの過去のパターンを含むが、これに限定はされない）に基づいて複数のセンサ装置の動作（その通信オーバーヘッドだけに限定されない）を動的に改変できるシステムおよび方法を提供する。
【００３５】
改変がセンサ・ノードにより報告されたデータ・サンプルの空間時間的変動と、付加的な外部コンテキストとの両方に基づくことができることが認められるべきである。動作改変は、クライアント装置が通信ネットワークを介してサーバに必ず連続的に接続されることを必要とせずに、クライアント・センサ・ノードが自分たちの通信オーバーヘッドを減少させ、かつ、アプリケーションにより要求される応答性のレベルを維持することを可能にする。本発明の例証となる原理は、ここで遠隔相関局所適応化（Ｒｅｍｏｔｅ  Ｃｏｒｒｅｌａｔｉｏｎ  ａｎｄ  Ｌｏｃａｌ  Ａｄａｐｔａｔｉｏｎ（ＲＥＣＯＬＡ））と称されるシステム・アーキテクチャを使用し、これは継続的監視アプリケーションのためのクライアント（センサ）ノード動作のエネルギー効率的適応化のための手段を提供する。
【００３６】
ＲＥＣＯＬＡでは、リモート・サーバ・ノード（代わりに“シンク”と称される）は、クライアント装置の現在の（または将来の）所望の動作を決定する計算ロジックの大半を含み、またクライアント装置の所望の動作に影響を及ぼし得る他の種々のコンテキスト・データをも認識している。個々のクライアント装置は、サーバ・ノードに直接接続することができ、あるいはそのデータが集積ゲートウェイを通してファネリングされ得る。動作改変は、センサ装置においてまたは集積ゲートウェイにおいて影響を受け得る。サーバは、クライアント装置において望まれる将来のアクションを決定する適切な“ルール”を決定するためにクライアント装置の過去のコンテキスト歴と他の環境状態とを分析するオプションの“学習”コンポーネントを含むことができる。
【００３７】
クライアント装置または中間のクライアント・ゲートウェイ装置は、常にネットワーク接続されていないかも知れず、従ってリモート・サーバと連続的に通信していそうもない。従って、システムは１つの方法を提供し、これによってリモート・サーバは、クライアント装置にその期待される動作に対する潜在的変化について知らせることができ、ここで、この動作は、クライアント装置により生成されるデータ・サンプルの処理および送信、あるいはクライアント装置に関連付けられた他のアクション（例えば、可聴警報、データ・サンプリング周波数の変更、サンプリング・プロセスに用いられる量子化レベル）に関連し得る。
【００３８】
図１は、本発明の１つの実施態様に従う、局所的クライアント装置適応化技術をその中で実行できるところのデータ収集システムを示す。
【００３９】
示されているように、システム１００は集積ゲートウェイ１０２（この実施態様ではセル電話機であるが、他のタイプおよび量のゲートウェイを使用することができる）を含み、これは短距離ブルートゥース・リンク１０３を介して複数のセンサ１０４−１ないし１０４−３と通信する（もっと多数の、あるいはもっと少数のセンサを使用できることに注意）。ヘルスケア・シナリオによれば、これらのセンサのうちの１つ以上は、ユーザ（装着者）の、例えば心拍数、グルコース・レベルなどの健康特性を監視するヘルス・モニタであり得る。ＲＥＣＯＬＡアーキテクチャでは、集積ゲートウェイ１０２はＲＥＣＯＬＡクライアントとして知られる。システムがより多くのＲＥＣＯＬＡクライアントを含み得ることが理解されるべきである。しかし、簡単のために、クライアントは１つだけ示されている。
【００４０】
システム１００はリモート・サーバ１０８も含む（再び、システムが２つ以上のリモート・サーバを含み得ることに注意）。クライアント１０２は、ワイド・エリア無線リンク１０５と通信ネットワーク１０６（インターネットまたはワールド・ワイド・ウェブなど）とを介してサーバ１０８と通信する。図１に示されているリンクは単に例証を目的としているだけであり、従ってＲＥＣＯＬＡクライアントとリモート・サーバとを結合するために代わりの通信メカニズムを使用し得ることが理解されるべきである。
【００４１】
図２は、本発明の１つの実施態様に従う、局所的クライアント装置適応化のための方法論を示す。より具体的には、図２は、ＲＥＣＯＬＡクライアント（例えば、図１の集積ゲートウェイ１０２）とＲＥＣＯＬＡサーバ（例えば、図１のリモート・サーバ１０８）とにおいて、またこれらの間で、とられるステップを示す。
【００４２】
示されているように、ステップ２０２で、センサ（例えば、図１の１０４−１，１０４−２，１０４−３のうちの少なくとも１つ）は新しいサンプル・データを報告する。センサ装置は、適切な間隔を置いてセンサ・データ・サンプルを生成する（２０２）。クライアント１０２は、その様なデータを、記憶されているルール・ベース２０３（ルールを包含するデータベース）と突き合わせて、結果として生じたデータ・パターンがルール・ベース中の述語と一致するか否か調べ、一致したルールにおいて明示されている結果としてのアクションを実行する。１つのアクションは、データ・サンプルをサーバ１０８に送信することであり得る（ステップ２０４）。比較はルール・ベース中の“アクティブ”なルールとの比較であって、ルール・ベースがアプリオリにダウンロードされたルールの拡張集合を持つことができるということが認められるべきである。
【００４３】
ステップ２０６において、サーバは、特定のクライアントのために新しいルール、または既存のルールに対する改変を、これらのルールのための述語がクライアントにより局所的に決定され得るコンテキスト条件を含むだけであるように、決定するために、その送信されたデータ・サンプルと付加的なソース２０５からの付加的なコンテキスト・データとを特定アプリケーション向けロジック（図４のコンテキストにおいて以下でさらに記述される）とともに使用する。その様なコンテキスト条件は、センサにより報告された付加的なデータ・イベント、ゲートウェイまたはセンサ装置のリソース・レベル（例えば、ゲートウェイのバッテリ・レベル）、または何らかのローカル・コンテキスト（例えば、ＧＰＳ対応の電話機のためには、その電話機の現在位置）を包含し得る。
【００４４】
ステップ２０８において、サーバはその様な更新されたルールをクライアント装置に伝達し、クライアント装置は、将来の時点でのまたは後に生成されるデータ・サンプルのためのクライアントの動作が適切に改変されるように、これらのルールをそのルール・ベースに格納する。あるいはサーバが更新されたルールをクライアントに伝達するのではなくて、次のステップのうちの１つが存在し得る。１つの代わりの実施態様では、サーバは、アクティブ化された／非アクティブ化されたルールの識別子（ＩＤ）またはその様なルールの変更されたパラメータ／閾値を更新することができる。第２の代わりの実施態様では、サーバは、クライアントにおけるアクティブなルールの述語により要求される所要の“コンテキスト”条件を押し、従ってその後そのルールのうちのどれがこれらの新しい“コンテキスト”条件によりトリガされまたは無効にされるかを局所的に判定するようにクライアントに要求することができる。従って、一般に、サーバは、現在適用可能なルールの改変に関する適切な知識を表す情報をクライアントに送る。その様な情報（完全なまたは部分的なルール、ＩＤ、コンテキスト・データのうちの少なくとも１つ）は動的にあるいはアプリオリにクライアント装置に送られ得る。
【００４５】
例として、ステップ２１０において示されているように、新しいルールが指定することのできるアクションは、クライアント（すなわち、そのセンサのうちの１つ）がそのサンプリング・レートまたは精密範囲［ロー、ハイ］を変更することである。
【００４６】
新しいサンプリング・レートまたは精密範囲のもとで、ステップ２１２で、クライアントはセンサから新しいサンプルを受け取る。そのサンプルに基づいて、もしそのサンプルが精密範囲の外にあるならば、データがサーバに送信される（ステップ２１４ａ）。その代わりに、あるいはそれに加えて、クライアントで局所警報が発生させられ得る（ステップ２１４ｂ）。
【００４７】
従って、本方法は、リモート・サーバ（これは、潜在的に装着可能であるかあるいは移動可能であるクライアント装置と同じリソース制約を被らない）がコンテキスト・ソースの大きな部分集合の上で特定アプリケーション向けロジックの大半を実行し、また、クライアントにとって局所的に利用可能であり得るコンテキスト属性をその述語が単に含むルールを生成するように有利に規定する。例えば、ヘルスケア監視アプリケーションのロジックが次のルールを有すると仮定する。
述語                                      アクション
１．  もし患者が薬物治療Ｍ１を受けて      許容範囲（心拍数）＝［１２０，１３５］
いて、運動しているならば
２．  もし患者が薬物治療Ｍ２を受けて      もし平均グルコース読取り値が（５
いて、過去４時間以内に薬Ｍ２を      分のウィンドウにわたって）＞１５０
飲んでいなければ                    ならば、可聴警報を発生させる
【００４８】
この場合、リモート・サーバは始めにルール１が患者に現在当てはまるかどうか（すなわち、医療データベースがＭ１を患者の薬物治療の一部として記録しているか否か、また患者がジムにいると位置コンテキストが示しているか否か）を判定し、もし肯定であるならば、集積装置として動作するセル電話機に単にルール“許容範囲＝［１２０，１３５］”を送信する。同様に、もしルール２が当てはまるならば、サーバは、“もし最近の５つのグルコース読取り値（毎分サンプリングされると仮定される）の平均値が１５０を上回り、またＭ２が過去４時間以内に飲まれていなければ、可聴警報を発生させる”ようにクライアント装置に指令する。
【００４９】
これら両方の場合に、サーバは、送信されたルールからクライアントにより局所的に判定され得ない述語の部分（その人が薬物治療Ｍ１を受けているか否か、現在ジムにいるか否か、など）を取り除き、これによりクライアントが局所的に判定を行えるようにしている。このような局所的判定を可能にすることによって、ＲＥＣＯＬＡシステムは、たとえローカル装置がネットワークから切り離されているときでもローカル装置が応答性を示すことを許す。例えば、読取り値が所定範囲外に下がったときにセル電話機（集積ゲートウェイ）が実際にネットワーク通達範囲を持っていないときでも、可聴警報が発せられるであろう。
【００５０】
さらに、本発明の例証となる原理は、個々のセンサにより収集された連続するデータ・サンプル間の空間時間的相関を利用し、これから学習することができる。例えば、サーバは、生のデータを分析して、報告されたデータの中のそれまで知られていなかったパターンを判定することのできる１つ以上の学習エンジンを持つことができる。その様な未知のパターン自体は、クライアント装置に伝達される修正された精密範囲または他のタイプのルールに変換され得る。
【００５１】
このような学習は、示された特定のパターンに基づいて、ルールがそれぞれの人のためにカスタマイズされることを可能にする。例えば、Ａさんは標準心拍数８０を有すると観察され、Ｂさんは長時間平均心拍数７０を有すると観察され得るとすれば。この観察結果は、クライアント装置にダウンロードされる適切なルールにおいて使用され得る（例えば、“短期平均値が８５を超えたら、場合によっては異常分析のために、心拍数データをすぐにバックエンド・サーバに送信する”というルールをユーザＡのセル電話機が有し、一方、ユーザＢのための同様のルールは閾値を７４に設定し得る）。
【００５２】
ルールのアクション・コンポーネントの実際の仕様は、コンピューティング装置の具体的な能力に依存し、単純な通信指令（例えば、直ぐに送信せよ、あるいはデータを捨てよ、など）あるいは“警報発生”（例えば、ビープ音を介してユーザに警告する）だけではなくてデータ・サンプルのもっと高度な処理および記憶をも含むことができる。例えば、データが連続的な波形を含む或るアプリケーションでは、変化する個数の別々の係数（例えば、スプライン）を通して波形の特性を実際に補足すること、あるいは実際のデータ値に依存して様々なレベルの損失のある圧縮を適用することは容認できることであり得る。
【００５３】
さらに、クライアント装置が通信インフラストラクチャから切り離されている期間を処理するために、特定コンテキスト向けルール（ジムにおける運動中に適用される高められた心拍数閾値など）は、一時的なものとされることができ、あるいはそのアクティブ期間を局所的に利用可能なコンテキストの直接関数とすることができる（例えば、ＧＰＳ対応電話機では、或るルールは、指定された地域の中に位置があるときに限って適用可能であるようにトリガされ得る）。その様なルールは、或る期間の間適用され、その後にタイムアウトして、クライアント装置が監視の“標準”状態に戻ることを可能にする。
【００５４】
図３は、本発明の１つの実施態様に従う、局所的クライアント装置適応化技術をその中で実行できるところのクライアントを示す。
【００５５】
示されているように、クライアント３００は、データ収集コンポーネント３０２、パターン認識エンジン３０４、アクション・トリガ・メカニズム３０６、インテリジェント・データ送信コンポーネント３０８、予想メカニズム３１０、装置リソース・コンポーネント３１２、およびユーザ・インターフェース・コンポーネント３１４を含む。
【００５６】
データ収集コンポーネント３０２は、センサ１０４−１ないし１０４−３（例えば、心臓モニタ、グルコース・モニタなど）から生のセンサ・データを収集する。そのセンサ・データはパターン認識エンジン３０４に供給される。パターン認識エンジン３０４は、入ってきたセンサ・ストリーム中に既知のパターンが生じたときを検出する。既知のパターンが検出されたとき、エンジン３０４は、アクション・トリガ・メカニズム３０６に警報を出す。
【００５７】
アクション・トリガ・メカニズム３０６は、クライアントのユーザ・インターフェース３１４（例えば、ディスプレイ、スピーカ、警報音、触覚警報など）を介してユーザ通知を中継する。メカニズム３０６はセンサ１０４−１ないし１０４−３を制御することもできる（例えば、これらをオンオフし、これらの収集頻度を変更するなど）。メカニズム３０６は、他の動作を開始させることができる。
【００５８】
データ収集コンポーネント３０２は、また、生のセンサ・データをインテリジェント・データ送信コンポーネント３０８に渡し、その機能は、このデータをサーバ４００（図４と関連して以下で記載される）上のデータ処理ユニット４０２に送るか否かを決定することである。この決定を行うために、情報は、パターン認識エンジン３０４（例えば、このデータ・ストリームが正常か異常かを示す情報など）から、また予想メカニズム３１０からも集められる。
【００５９】
予想メカニズム３１０は、過去の傾向を考慮して装置リソース３１２を監視する。装置リソースが消耗しあるいは減少すると予期されるとき、データ送信についての閾値は増大し、インテリジェント・データ送信コンポーネント３０８は、サーバ４００上のデータ処理コンポーネント４０２に送信されるデータの量を抑える。
【００６０】
パターン認識エンジン３０４がサーバ４００（図４と関連して以下で記載される）のパターン学習エンジン４０６からパターン仕様を受け取るということに留意されたい。１つの代わりの実施態様では、クライアント３００は、サーバ側コンポーネントに取って代わり得るかあるいはこれを強化し得るパターン学習エンジンを含むこともできる。
【００６１】
アクション・トリガ・メカニズム３０６がサーバ４００上のパターン認識エンジン４０８からアクション・トリガを受け取ることもできることにも留意されたい。
【００６２】
一実施態様では、クライアントが装置リソースを監視し、動作を適切に調整し得ることにも留意されたい。例えば、電源が問題であるならば、余分のデータの、多くの電力を必要とする送信を避けるために、装置はデータを局所的に蓄積し、あるいはデータに対する追加の圧縮を行うことができる。
【００６３】
ブロック３００が集積ゲートウェイ１０２とセンサ装置１０４−１ないし１０４−３との組み合わせであると見なされ得るということが認められるべきである。すなわち、これらのコンポーネントは、図１では別々に示されているけれども、１つのクライアント装置において結合されても良い。
【００６４】
図４は、本発明の１つの実施態様に従う、局所的クライアント装置適応化技術をその中で実行できるところのサーバを示す。代わりのデザインも可能であるということが認められるべきである。
【００６５】
示されているように、サーバ４００は、データ処理モジュール４０２、データベース４０４、パターン学習エンジン４０６、パターン認識エンジン４０８、外部コンテキスト・ソース４１０、外部ルール仕様４１２、外部アクション仕様４１４、および外部アクション・トリガ・メカニズム４１６を含む。ブロック４００がリモート・サーバ１０８と外部コンテキスト・ソース２０５との組み合わせであると見なされ得るということが認められるべきである。すなわち、これらのコンポーネントは、図２では別々に示されているけれども、１つのサーバにおいて結合され得る。
【００６６】
データ処理モジュール４０２は、クライアント３００（図３）のインテリジェント・データ送信コンポーネント３０８により送信されたデータを受け取る。モジュール４０２は、このデータをデータベース４０４に送る。同様に、データ処理モジュール４０２は、外部コンテキスト・データ４１０も受け取る。モジュール４０２は、このデータもデータベース４０４に送る。
【００６７】
パターン学習エンジン４０６は、データベース４０４からデータを検索する。パターン学習エンジン４０６は、（新しいデータ・サンプルが到着したならば）オンライン式に動作することができ、あるいは適切な所定の時間間隔で定期的にトリガされることができる。エンジン４０６は、このデータにおけるパターンを特定し、これらのパターンの仕様を明らかにするためにルールを作る。これらのルール仕様は、クライアント３００上のパターン認識エンジン３０４に中継される。それらは、サーバ４００上のパターン認識エンジン４０８にも中継される。パターンが認識されると、外部アクション仕様コンポーネント４１４を介してそのパターンにアクションが関連付けられることができる。上記のように、クライアントのために生成されるルールは、クライアントによって局所的に決定されるコンテキスト条件を有利に含むだけであり、従ってサーバにおいて維持されているものとは異なり得るということが認められるべきである。
【００６８】
パターン学習エンジン４０６とパターン認識エンジン４０８とは、明示的にデータを検索するのではなくて、データベース４０４からのデータベース更新を予約することができるということが認められるべきである。
【００６９】
ルール仕様がパターン学習エンジン４０６によって外部ソース４１２から受け取られ得るということも認められるべきである。これらの外部から指定されたルールは、その後、クライアントのパターン認識エンジン３０４とサーバのパターン認識エンジン４０８との両方に渡されることができる。例えば、医師は、アクションに値するけれども特定の患者において観察されていない医学的に重要なイベントを指定することができる。
【００７０】
パターン認識エンジン４０８は、データベース４０４に前もって格納されていた受け取られたセンサ・データの中のパターンを特定するためにルール仕様を使用する。パターンを特定すると、エンジン４０８は、クライアント上のアクション・トリガ・メカニズム３０６を通してアクションを開始させることができる。同様に、エンジン４０８は外部アクション・トリガ・メカニズム４１６を通して外部アクション（例えば、医師への通知）を開始させることができる。
【００７１】
図５はルール仕様５００を示し、これは一意のルール識別子５０２、パターン仕様５０４およびアクション仕様５０６を含む。パターン仕様５０４は、正規の表現またはエクステンシブル・マークアップ・ランゲージ（Ｅｘｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ  （ＸＭＬ））などの、多くの方法で定義され得る。アクション仕様５０６も、多くの方法で定義され得る。それは、アクション（例えば、通知、可聴警報、可視表示、など）のリポジトリーからの識別子であり得る。それは、ＸＭＬなどの言語を介して実行可能なプログラムの仕様でもあり得る。
【００７２】
図６は、本発明の１つの実施態様に従う、データ収集システムの１つ以上のコンポーネント／ステップ（例えば、図１および５と関連して記載されたコンポーネント／ステップ）がそれに従って実現され得るところのコンピュータ・システムを示す。すなわち、図６に示されているアーキテクチャは、集積ゲートウェイ１０２、センサ１０４−１ないし１０４−３の各々、およびリモート・サーバ１０８のうちの少なくとも１つのコンポーネントの全部または一部を実現するために使用されるアーキテクチャを代表することができる。
【００７３】
さらに、個々のコンポーネント／ステップは１つのその様なコンピュータ・システムにおいて、あるいはより好ましくは２つ以上のその様なコンピュータ・システムにおいて実現され得るということが理解されるべきである。分散型システムでのインプリメンテーションの場合には、個々のコンピュータ・システムまたは装置あるいはその両方は適切なネットワーク（例えば、インターネットまたはワールド・ワイド・ウェブ）を介して接続され得る。しかし、システムは構内ネットワークまたはローカル・ネットワークを介して実現され得る。本発明は、特定のネットワークに限定されない。
【００７４】
示されているように、コンピュータ・システム６００は、コンピュータ・バス６１０または代わりの接続装置を介して結合されたプロセッサ６０２、メモリ６０４、Ｉ／Ｏ装置６０６、およびネットワーク・インターフェース６０８に従って実現され得る。
【００７５】
本書で使われる“プロセッサ”という用語は、例えばＣＰＵ（中央処理装置）または他の処理回路あるいはその両方を含むものなどの、任意の処理装置を含むように意図されているということが認められるべきである。また、“プロセッサ”という用語は２つ以上の処理装置を指すことができ、処理装置に関連付けられた種々のエレメントは他の処理装置によって共有され得るということも理解されるべきである。
【００７６】
本書で使われる“メモリ”という用語は、例えばＲＡＭ、ＲＯＭ、固定メモリ装置（例えば、ハード・ディスク装置）、取り外し可能なメモリ装置（例えば、ディスケット）、フラッシュ・メモリなどの、プロセッサまたはＣＰＵに関連付けられたメモリを含むように意図されている。
【００７７】
さらに、本書で使われる“入出力装置”または“Ｉ／Ｏ装置”という句は、例えば、データを処理ユニットに入力するための１つ以上の入力装置（例えば、キーボード、マウスなど）、または処理ユニットに関連付けられた結果を提示するための１つ以上の出力装置（例えば、スピーカ、ディスプレイなど）あるいはその両方を含むように意図されている。
【００７８】
さらに、本書で使われる“ネットワーク・インターフェース”という句は、例えば、コンピュータ・システムが適切な通信プロトコルを介して他のコンピュータ・システムと通信することを可能にする１つ以上のトランシーバを含むように意図されている。
【００７９】
従って、本書に記載されている方法論を実行するための命令またはコードを含むソフトウェア・コンポーネントは、関連するメモリ装置（例えば、ＲＯＭ、固定されたまたは取り外し可能なメモリ）のうちの１つ以上に格納され、何時でも利用され得る時に一部または全体が（例えばＲＡＭに）ロードされてＣＰＵにより実行されることができる。
【００８０】
本発明がユーザ・データ収集サービスを提供するための技術をも含むことがさらに認められるべきである。例を挙げると、サービス・プロバイダは（例えば、サービス・レベル契約または何らかの非公式の契約若しくは取り決めを介して）サービス・カスタマとユーザ・データ収集サービスを提供するように合意する。すなわち、単なる一例として、サービス・プロバイダはカスタマのウェブ・サイトおよび関連するアプリケーション（例えば、ヘルスケア監視など）を管理することができる。サービス・プロバイダとサービス・カスタマとの間の契約事項に従って、サービス・プロバイダは、本書に記載されている発明の方法論のうちの１つ以上を含み得るユーザ・データ収集サービスを提供する。例を挙げると、これは、（サービス・カスタマの）クライアントからサンプル・データを収集することと、１つ以上の便益をサービス・カスタマに提供するためのクライアント装置の局所的適応化とを含み得る。サービス・プロバイダは、プロセスで用いられるコンテキスト・ソースのうちの１つ以上を提供することもできる。例えば、サービス・プロバイダは位置コンテキスト、または電子カレンダ・サービスを提供することができる。
【００８１】
本発明の実施例が添付図面を参照して本書に記載されたけれども、本発明がこれらの実施例そのものに限定されないこと、また、本発明の範囲から逸脱せずに当業者によって他の種々の変更および改変がなされ得るということが理解されるべきである。
【図面の簡単な説明】
【００８２】
【図１】本発明の１つの実施態様に従う、局所的クライアント装置適応化技術をその中で実行できるところのデータ収集システムを示す。
【図２】本発明の１つの実施態様に従う、局所的クライアント装置適応化のための方法論を示す。
【図３】本発明の１つの実施態様に従う、局所的クライアント装置適応化技術をその中で実行できるところのクライアントを示す。
【図４】本発明の１つの実施態様に従う、局所的クライアント装置適応化技術をその中で実行できるところのサーバを示す。
【図５】本発明の１つの実施態様に従う、ルール仕様を示す。
【図６】本発明の１つの実施態様に従う、データ収集システムに関連付けられたクライアントまたはサーバあるいはその両方がそれで実現できるところのコンピューティング・システム・アーキテクチャを示す。
【図１】
2009540445.tif 000003
【図２】
2009540445.tif 000004
【図３】
2009540445.tif 000005
【図４】
2009540445.tif 000006
【図５】
2009540445.tif 000007
【図６】
2009540445.tif 000008
【国際調査報告】
2009540445.tif 000009
2009540445.tif 000010
2009540445.tif 000011