JP2004192652A - ネットワークコンピューティング環境においてコンテキストプロパティメタデータを利用するための方法、装置およびプログラム製品 - Google Patents

Abstract

【課題】ある環境において、各コンポーネントが、それが何かを明らかにすることのできるコンポーネントコンテキストを有するコンポーネント間の相互作用のコンテキスト履歴を累積する。
【解決手段】コンポーネントは、リクエスタコンポーネントとサービスコンポーネントを含む。リクエスタコンポーネントは、サービスコンポーネントによって実行される動作を要求する。リクエスタコンポーネントは、動作要求と一緒にそのコンテキストをサービスコンポーネントに渡す。リクエスタコンポーネントのコンテキストは、サービスコンポーネントのコンテキストメタデータとして記録され、コンテキスト履歴の一部となる。
【選択図】図３

Description

本発明は一般に、メタデータを使用し、共有するシステムと方法に関する。

データ通信環境において、さまざまなベンダが特定のサービスのための製品を提供している。これまで、環境内の任意のコンポーネントが相互に通信できるよう、ドメインごとに異なる所定のプロトコル一式が必要とされてきた。ベンダによって必要な所定のプロトコルが異なるという問題は、既存のプロトコル基準を採用することで一部対処されている。しかしながら、プロトコルの基準も異なる。

米国特許出願公開第２００２／０１５６７９５号

任意のコンポーネントが互いの優先されるべき知識（アプリオリ・ナレッジ:a priori knowledge）を持たずに通信しようとする場合、両当事者は特にドメイン別のプロトコルを優先的に知っていなければならない。ひとつの任意のコンポーネントは、標準化されたプロトコルのひとつまたはいくつかを理解するよう特にプログラムされている必要がある。このように、新しい、未知のコンポーネントが方程式に入った場合、アプリケーションは、その新規コンポーネントと通信するのに使用される新たな標準化されたプロトコルを理解するようプログラムし直さなければならない。このように、各アプリケーションは、先ず特定の標準化されたプロトコル一式を使用するよう明確に書かなければ、そのプロトコルと関連するコンポーネントと通信することができない。

ドメイン別のインタフェースを用いるＪｉｎｉ^TM等のシステムにおいて、ＰＤＡシステム等のコンポーネントがプリンタ等の他のコンポーネントと通信するために、ＰＤＡシステムはプリンタのプログラムインタフェースの意味規則に関する優先知識を持っていなければならない。つまり、印刷の方法を知っているコンポーネントでも、特定のコンポーネントのためのインタフェースと通信する方法がわかるように明確にプログラムされないかぎり、ファイルシステム、スキャナデバイスまたはネットワーク翻訳サービス間のデータ転送方法がわからないかもしれない。

現在、ユビキタスコンピューティング環境は、ネットワークの効果を見込んでいない。つまり、環境に新たなコンポーネントが加えられた場合、追加されたコンポーネントの機能を環境に加えること以上の能力はない。

さらに、システムの中には、システム内のコンポーネントに関して、コンテキスト情報を臨時に保持するものもある。このようなコンテキスト情報はしばしば、そのコンポーネントがユーザか、ドキュメントか、アプリケーションか等、それが代表するコンポーネントの種類に応じて、各種のフォーマットで表現される。その結果、システム内の任意のコンポーネントは、特にその任意のコンポーネントが相互に関する優先知識を持っていない場合、現在のコンテキスト情報を相互に提供することが困難または不可能となることが多い。

コンテキストシステムのひとつの問題は、信頼性を確保することである（たとえば、あるプロパティ値が不適当に変更されていないか検証する）。別の問題は、ユビキタスコンピューティング環境は非常に流動的であるため、その環境内のシステムの挙動を理解することが非常に困難である点である。どのようにプロパティ値が変化したか、およびなぜそのシステムが特定の方法で行動したかを検証することができれば有利である。

ユビキタスコンピューティング環境において検索メカニズムを使用するひとつの問題は、これらのメカニズムが検索されたコンポーネントの非常に長いリストを戻してきながら、ユーザが現在の状況にとって有益なコンポーネントを理解し、選択するのに役立つ情報を提供しない場合が多いことである。ユーザに対し、現状に関係のある情報を優先的に提供できれば有利である。

本明細書では、各コンポーネントが、それが何かを明らかにすることのできるコンポーネントコンテキストを持つ環境におけるコンポーネント間の相互作用のコンテキスト履歴を累積するための方法とシステムの実施形態を開示する。このコンポーネントは、リクエスタコンポーネントとサービスコンポーネントを備える。リクエスタコンポーネントは、そのコンテキストを動作要求と一緒にサービスコンポーネントに渡す。リクエスタコンポーネントのコンテキストは、サービスコンポーネントのコンテキストメタデータとして記録され、コンテキスト履歴の一部となる。

また、それが何かを明らかにすることのできるコンポーネントコンテキストにおける変更のコンテキスト履歴を累積するために使用される方法、装置、プログラム製品の実施形態も開示される。この装置とプログラム製品は、コンポーネントコンテキストの一部を変更する動作を検出し、その部分をコンテキスト履歴と結合する。次に、この装置とプログラム製品は、その動作に応答してその部分を変更する。

さらに、コンポーネントが要求を受け取り、その要求にコンテキストアクセス方針を適用する方法、装置、プログラム製品の別の実施形態が開示される。コンテキストアクセス方針を要求に適用した後、コンポーネントは、その要求が一連のコンテキストアクセス許可のひとつを満足するかを確認し、満足する場合は、その要求を満たす。

本発明の実施の形態（以下、実施形態）によるコンテキスト情報を提供するためのシステム１０が図１に示されている。システム１０は、コンピュータ１２、プリンタ１４（多機能デバイスを含む）、携帯情報端末機器（ＰＤＡ）１６およびサーバ１８（以下、「コンポーネント１２−１８」とする）を含み、これらがネットワーク２０によって相互に連結されている。本実施形態により、同じ、または異なる通信プロトコルおよび／またはデータタイプを使うコンポーネントは、そのコンポーネントがドメイン別のインタフェース、プロトコルまたはデータフォーマットを使用することなく、相互にコンテキスト情報を転送することが可能となる。さらに、本実施形態は、ユーザ、デバイスまたはアプリケーションが、相互の優先知識を持つコンポーネントを必要とすることなく、直接相互を呼び出し、現在のコンテキスト情報およびその他のデータを提供することを可能とする手立てとなる。

図２に示すように、本発明の実施形態では、コンピュータ１２は中央処理ユニット（ＣＰＵ）２２、メモリ２４、Ｉ／Ｏユニット２６で構成され、これらが１つまたは複数のバスによって相互に連結されている。

図３において、図１に関連して上述したように、コンピュータ１２がＰＤＡ１６に連結されている。ＰＤＡ１６は、コンテキストインタフェース、通知（ｎｏｔｉｆｉｃａｔｉｏｎ）インタフェース、ユーザインタフェースおよびデータソースインタフェースからなる汎用インタフェースセット１６ａをメモリに保存しているか、あるいはこれにアクセスできる。これを以下、「関連している」と表現する。具体的なインタフェースの数および／または組み合わせは異なってもよく、デバイスＰＤＡ１６の種類や、それが望む、または提供する能力および／またはサービスに依存する。また、ＰＤＡ１６、したがって汎用インタフェースセット１６ａはいつでも、インタフェースの追加、削除または変更を行うよう更新できる。

汎用インタフェースセット１６ａ内の各インタフェースは、ＰＤＡ１６に特有でありながら、コンピュータ１２が理解、実行し、それがＰＤＡ１６とコンテキストデータを通信、転送し、ＰＤＡ１６に関するコンテキストデータの変化について、コンピュータ１２にイベント通知を送り、コンピュータ１２がユーザインタフェースを受け取って、コンピュータ１２のユーザが変更後のコンテキストデータを見ることができるようにし、あるいはコンピュータ１２がＰＤＡ１６からのデータを受けることができるようにする命令、動作セットおよび／またはその他のデータによって構成される。

特に、コンテキストインタフェースは、コンテキストオブジェクト１６ｃを要求し、これにアクセスするｇｅｔＣｏｎｔｅｘｔ（）動作によって構成されている。コンテキストデータには、ＰＤＡ１６に関する情報、たとえばその種類、所有者、使用履歴、ＰＤＡ１６が現在使用中か、あるいはその他の動作状態情報、アイデンティティ、ネットワーク２０上のロケーション、物理的ロケーション、管理ドメイン、ＰＤＡ１６またはＰＤＡ１６に記憶記されたファイルの一人または複数のユーザに関する情報、あるいはその他、ＰＤＡ１６が提供するその他の種類の環境情報等が含まれる。さらに、コンテキストデータには、コンピュータ１２が理解し、実行することのできる、ＰＤＡ１６に特有のコンピュータ言語の命令も含まれる。

本発明の実施形態において、ＰＤＡ１６に関連するコンテキストオブジェクト１６ｃは、ｇｅｔＣｏｎｔｅｘｔ（）動作を通じてコンピュータ１２によって取得されるようにすることができる。コンテキストオブジェクト１６ｃは、ｇｅｔＣｏｎｔｅｘｔ（）動作によって戻されるひとつまたは複数の動作、たとえばｇｅｔＰｒｏｐｅｒｔｙ（）やｓｅｔＰｒｏｐｅｒｔｙ（）動作をサポートするオブジェクトのライブでのリモートリファレンスおよびその他、コンピュータ１２がＰＤＡ１６に関連する現在および／またはこれまでのコンテキストデータにアクセスすることを可能にする命令等である。ただし、オブジェクト１６ｃは、コンテキストデータを直接含んでもよい。ｇｅｔＰｒｏｐｅｒｔｙ（）動作は、コンテキストデータをＰＤＡ１６からコンピュータ１２に戻すよう要求する命令を含むことができるため、コンピュータ１２はＰＤＡ１６に関連するコンテキストデータを読み取れる。ｓｅｔＰｒｏｐｅｒｔｙ（）動作は、ＰＤＡ１６にコンテキストデータを提供するためにコンピュータ１２が実行する命令とデータを含むため、コンピュータ１２はＰＤＡ１６のコンテキストデータを更新または変更できる。

通知インタフェース（たとえば、プロキシオブジェクトによって提供される）はｒｅｇｉｓｔｅｒ（）動作によって構成され、これには、コンピュータ１２が、ＰＤＡ１６のコンテキストデータへの変更に関する通知を受け取るための、ＰＤＡ１６に関する聞き手（リスナー: listener）としてコンピュータ自身を登録することができるようにするために実行する命令、動作およびデータを含めることができる。通知インタフェースには、コンポーネントパラメータとコンテキストパラメータを含むひとつまたは複数のパラメータを渡すことができる。コンポーネントパラメータは、通知の受信者としてコンピュータ１２を識別する。コンテキストパラメータは、コンピュータ１２に関する現在および／または現在までのコンテキストデータであり、これは、コンピュータ１２に通知を送信すべきか否かを決定するための、ＰＤＡ１６に関するひとつまたは複数のプロパティを表す。

ユーザインタフェースは、ユーザウィンドウを生成するためのｇｅｔＵＩ（）動作によって構成される。特に、ｇｅｔＵＩ（）動作は、コンピュータ１２のユーザがＰＤＡ１６の機能（ＰＤＡ１６に関連するコンテキストデータへのアクセスを含む）にアクセスすることを可能にするユーザインタフェースウィンドウを生成し、表示するためにコンピュータ１２が実行できる命令を有するオブジェクトを、コンピュータ１２に戻す。

データソースインタフェースは、コンピュータ１２がＰＤＡ１６からデータを受信できるようにするデータ転送セッションを確立するためのｂｅｇｉｎＴｒａｎｓｆｅｒＳｅｓｓｉｏｎ（）動作によって構成される。さらに、ｂｅｇｉｎＴｒａｎｓｆｅｒＳｅｓｓｉｏｎ（）動作は、コンテキストパラメータ等のパラメータを受け取ることができる。本発明の実施形態において、コンピュータ１２は、そのアイデンティティをＰＤＡ１６に知らせるためにそのコンテキストオブジェクトを呼ぶと、これをパラメータとしてｂｅｇｉｎＴｒａｎｓｆｅｒＳｅｓｓｉｏｎ（）動作に渡す。ＰＤＡ１６は、コンテキストパラメータの中で提供されるコンテキストデータに基づき、コンピュータ１２にデータを転送するか、データ転送中にその挙動を変更するかを決定する。

上記のインタフェースと関連する動作は各々、モバイルコードで構成することができる。本発明の実施形態において、汎用インタフェースセット１６ａがコンピュータ１２に提供されると、本明細書で説明したように、コンピュータ１２が特定のインタフェースに関連する一連の命令およびその他のデータにアクセスし、これを実行することが可能となる。またさらに、インタフェースは他のインタフェースへの一連の命令またはリファレンスで構成することもでき、この場合、コンピュータ１２はそれに応じてデータを利用し、あるいは命令を実行する。

本発明の実施形態において、上記のモバイルコードを使用するか否かは任意である。

データオブジェクト１６ｂは、ＰＤＡ１６のプロキシオブジェクトであり、ＰＤＡ１６から受信され、コンピュータ１２に保存される。コンピュータ１２はデータオブジェクト１６ｂを通じて汎用インタフェースセット１６ａにアクセスできる。より具体的には、データオブジェクト１６ｂは、コンピュータ１２が知り、理解できると想定される、ＰＤＡ１６に関連する汎用インタフェースセット１６ａの中のインタフェースによって定義される各種の動作をサポートする。たとえば、データオブジェクト１６ｂは、ＰＤＡ１６の開発者が決定したプロトコルおよび／またはデータフォーマットを使ったＰＤＡ１６との通信を専門とするコンテキストインタフェースのカスタム実装を提供する。

図４において、はじめにステップ３０で、コンピュータ１２は探索プロセスを実行し、ＰＤＡ１６がコンピュータにコンテキストデータを供給できるか判断する。

次に、ステップ３２で、探索されたＰＤＡ１６は、データオブジェクト１６ｂをコンピュータ１２に戻す。コンピュータ１２は、受け取ったデータオブジェクト１６ｂを点検し、どの汎用インタフェース（ひとつまたは複数）がＰＤＡ１６に関連しているか判断する。コンピュータ１２は、ＰＤＡ１６が少なくともコンテキストインタフェースと関連していると判断し、したがって、ＰＤＡ１６はコンピュータにコンテキストデータを提供できる。

次に、ステップ３４で、コンピュータ１２はデータオブジェクト１６ｂにおいて定義された手順、命令および／またはデータを使い、ＰＤＡ１６と関連するｇｅｔＣｏｎｔｅｘｔ（）インタフェースを呼び出し、コンテキストオブジェクト１６ｃをＰＤＡ１６に要求する。コンピュータ１２がコンテキストオブジェクト１６ｃを通じてコンテキストデータへのアクセスを要求するため、オブジェクト１６ｃに含まれる命令は、その要求をＰＤＡ１６によってサポートされる第一のプロトコルに翻訳して、コンテキストデータへのアクセスを実現することができる。

次に、ステップ３６で、コンピュータ１２はコンテキストオブジェクト１６ｃを受け取り、関連するｇｅｔＰｒｏｐｅｒｔｙ（）動作を呼び出して、ＰＤＡ１６からコンテキストデータを取り出す。さらに、コンピュータ１２がｇｅｔＰｒｏｐｅｒｔｙ（）動作を実行する時、ＰＤＡ１６は命令、動作またはデータを直接コンピュータ１２に戻し、コンピュータが、ＰＤＡ１６から転送されているコンテキストデータを理解することができるようにすることもできる。また、コンテキストオブジェクト１６ｃはコンテキストデータの要求をＰＤＡ１６に送信するものの、オブジェクト１６ｃがコンテキストデータを含むこともあり、この場合、コンピュータ１２はその中のデータにアクセスする。いずれの場合も、コンピュータ１２はＰＤＡ１６からコンテキストデータを受け取る。

別の実施形態において、ステップ３０−３６は、ステップ３０−３２でデータオブジェクト１６ｂを点検し、ＰＤＡ１６が通知インタフェースおよびユーザインタフェースとも関連していることを判断する点を除き、本発明の実施形態について先に説明したものと同じ方法で実行される。コンピュータ１２は、したがって、ＰＤＡ１６と関連するコンテキストデータの変化に関するイベント通知を受信するリスナーとしてＰＤＡ１６に登録できる。

別の実施形態において、ステップ３０−３６は、ステップ３０−３２でコンピュータ１２が受信したデータオブジェクト１６ｂを点検し、ＰＦＡ１６がデータソースインタフェースとも関連していることを判断する点を除き、本発明の実施形態について先に説明したものと同じ方法で実行される。このように、ＰＤＡ１６は連続するデータストリーム（たとえば、ストリーミングビデオ）等、それが関連するコンテキストデータのほかに、コンピュータ１２の他のタイプのデータを送信することができる。

図５に示すとおり、プリンタ１４はコンテキストインタフェースを含む汎用インタフェースセット１４ａと関連している。この実施形態におけるコンテキストインタフェースは、図３−５に関して上述したコンテキストインタフェースと同じであるが、この実施形態の場合、コンピュータ１２によって実行されるプリンタ１４専用の命令がある点だけが異なる。

図６において、はじめにステップ５０で、コンピュータ１２は図３のステップ３０−３２について上述した探索プロセスを実行するが、ステップ５０ではデータオブジェクト１４ｂを探索する。さらに、コンピュータ１２は、プリンタ１４が少なくともコンテキストインタフェースと関連していると判断し、プリンタ１４はコンピュータ１２にコンテキストデータを供給することができる。

次に、ステップ５２で、コンピュータ１２は、図３のステップ３４についてすでに説明したように、データオブジェクト１４ｂで定義された手順、命令および／またはデータを使い、プリンタ１４と関連するｇｅｔＣｏｎｔｅｘｔ（）インタフェースを呼び出して、コンテキストオブジェクト１４ｃを要求する。このようにして、コンピュータ１２はデータオブジェクト１４ｂを通じてプリンタ１４からコンテキストオブジェクト１４ｃを受け取る。

次に、ステップ５４で、コンピュータ１２はデータオブジェクト１４ｂに含まれるｇｅｔＰｒｏｐｅｒｔｙ（）動作を呼び出して、プリンタ１４と関連するコンテキストデータを取り出す。この実施形態において、プリンタ１４と関連するコンテキストデータは、サーバ１８等の中央ロケーションに保存することができるが、コンピュータ１２またはＰＤＡ１６等、別の場所にコンテキストデータを保存することも可能である。このようにして、ｇｅｔＰｒｏｐｅｒｔｙ（）動作に含まれ、コンピュータ１２によって実行される命令、動作またはデータは、プリンタ１４に関連するコンテキストデータをサーバ１８から取り出すようプリンタ１２に命令する。さらに、命令、動作またはデータは、ネットワーク２０上でのコンテキストデータのロケーション（つまり、サーバ１８）やその他、コンピュータ１２が実行し、それがサーバ１８から転送されているコンテキストデータを取り出して理解することができるようにする色々な命令を含むことがある。

コンポーネントがコンテキストデータを記録する能力により、そのコンポーネントは、そのコンポーネントによって、またはそのコンポーネントのために実行される動作のコンテキスト履歴を得ることができる。このコンテキスト履歴は、ユビキタスコンピューティング環境におけるコンポーネントの使用を簡素化するために使用できる。

コンポーネントは、そのコンポーネントを操作することのできる人またはその他の生物学的創造物と強力に関連させることが可能であり、これらのコンポーネントをエンティティと呼ぶ。その他のコンポーネントは人との強い関連を持たず、単純にコンポーネントと呼ばれる。

コンポーネントには、コンテキストを持ち、そのコンテキストを明らかにすることができるデバイスが含まれる。リクエスタコンポーネント（requester component）は、そのリクエスタコンポーネントのコンテキストを動作の要求と一緒にサービスコンポーネントに送信することにより、サービスコンポーネントと相互作用する。サービスコンポーネントはリクエスタコンポーネントのコンテキストを受信するため、サービスコンポーネントはリクエスタコンポーネントのコンテキストと要求された動作の識別とを保存することができる。サービスコンポーネントが任意データを任意で含めることを可能にする任意拡張可能なデータ構造を使用する能力を有する場合、サーバコンポーネントは他のコンポーネントとの相互作用のコンテキスト履歴を、メタデータとして維持することができる。リクエスタコンポーネントのコンテキストは、サービスコンポーネントのコンテキストからの情報と組み合わせ、サービスコンポーネントのコンテキスト履歴に、何が行われたかだけでなく、どのエンティティ／コンポーネントがその動作を要求したか、いつ、どこでその動作が要求されたか、および要求された動作の結果も含めることができる。

さらに、コンポーネントは、コンポーネント自身が行ったコンテキストの変更（たとえば、プロパティ変更）の履歴も維持できる。

コンテキストメタデータにはプロパティメタデータが含まれ、アクセス管理（許可）、アクセス方針、履歴も含めることができる。アクセス管理は、どのコンポーネント／エンティティがそのコンテキスト（またはコンテキストの中の特定のコンテキストプロパティ）にアクセスできるか、あるいはコンポーネント／エンティティに動作を実行するよう要求できるかを決定する。アクセス方針は、サービスコンポーネントにアクセスして要求を出すコンポーネント／アイデンティティを特定するのに必要な認証のレベルを決定し、コンテキスト履歴は、コンテキストレベルで実行された動作の履歴とコンテキストプロパティレベルで実行された動作の履歴の両方を含む。コンテキストプロパティレベルの履歴は、プロパティについて行われたアップデートの全部またはその中から選択されたもののログを維持する。このように、プロパティを前の状態まで辿ることができる。プロパティ履歴記録のひとつの実施形態を、以下に、図１１に関して説明する。

ユビキタスコンピューティング環境のひとつの問題は、この環境においてユーザがコンポーネントを選択することが面倒で、エラーを招きやすい点である。過去のコンポーネントの使用の履歴（使用履歴）を維持することにより、ユーザは簡単に以前の構成を呼び出して再利用または変更できる。さらに、履歴メタデータを使い、過去の使用パターンを検出し、意味形成（センスメイキング: sensemaking）のための情報を収集し、これらのパターンに基づく推論を確立することも可能である。

実施形態のひとつの面は、コンテキスト情報に関するメタデータを保持することである。このコンテキスト情報は、信頼性とシステム挙動の説明を提供することができる。つまり、信頼性は、誰が所与のプロパティを更新したか、それが更新されたのはどれだか最近か、および現在値は何に基づいて決定されたかを知ることによって改善される。システム挙動の説明は、コンテキストプロパティの現在値の根拠およびコンテキストプロパティを変更するためにとられた動作の説明を知ることによって提供される。

デバイスおよび／または動作からのコンテキストは、積み重ねることができる。つまり、特定のコンポーネント／エンティティは、それと相互作用したことのあるその他のコンポーネント／エンティティのコンテキストを含むことができる。

コンポーネント／エンティティからのコンテキストは、連鎖させることもできる。つまり、各コンポーネントのコンテキストをコンポーネント間のデータフローに追加できる。たとえば、リクエスタエンティティがプレゼンテーションコンポーネントに情報を提供するよう要求した場合を考える。プレゼンテーションコンポーネントによって提供されたプレゼンテーション情報は、プレゼンテーションコンポーネントのコンテキストを含むであろう。そこで、エンティティがストレージコンポーネントにその情報を保存したいとすると、ストレージコンポーネントのコンテキストもプレゼンテーション情報と一緒に含めることができる。さらに、エンティティのコンテキストも含めることができる。このように、プレゼンテーション情報の中のメタデータは、そのデータの由来を提供する。

メタデータの連鎖により、コンポーネントはそれがアクセスするデータの履歴全体を判断できる。この情報には、どのコンポーネントがそのデータの供給源か、どのコンポーネントがそのデータにアクセスし、および／またはそのデータについて動作したか、いつ、どこでそのデータが保存されたか等がある。各コンポーネントがデータを提供するため、提供するコンポーネントは既存のメタデータとともにそのメタデータを提供し、したがって、これを受け取るコンポーネントは、そのコンポーネント自身のメタデータと、既存のメタデータおよび提供するコンポーネントのメタデータを統合することができる。

履歴メタデータの結合は、ｇｅｔＰｒｏｐｅｒｔｙ（）およびｓｅｔＰｒｏｐｅｒｔｙ（）方式にフィールドを追加し、ｇｅｔＰｒｏｐｅｒｔｙＨｉｓｔｏｒｙ（）方式を追加することによってサポートされる。

ｒｅｑｕｅｓｔｅｒの引数は、認証可能または不可能なコンポーネント、エンティティまたはアプリケーションとすることができる。ｃａｕｓｅの引数は、リクエスタによって定義され、アップデートの理由に関するより詳しい情報を得るためにリクエスタに戻されるトークンとすることができる。さらに、ｇｅｔＰｒｏｐｅｒｔｙとｓｅｔＰｒｏｐｅｒｔｙはどちらも、リクエスタのアイデンティティを提供する証明を含めるよう拡張できる。

リクエスタコンポーネントは、他のコンポーネントの履歴メタデータを取得して、他のコンポーネントのコンテキスト履歴を取得するか、あるいは特定の信頼性基準を満たす数値を得ることができる。したがって、リクエスタコンポーネントは、信頼できない、あるいは認証されていないエンティティ／コンポーネントが行った他のコンポーネントのプロパティへのアップデートや、認証メカニズムを迂回しながら行われたアップデート、あるいは古くなった数値を拒否できる。

コンポーネントはまた、そのコンテキスト履歴に、自分から行ったコンテキスト変更も追加できる。

図７から図１１は、メタデータを保存するために考えられるひとつの方法を示す。当業界で周知の別のメカニズムも使用できる。
たとえば、以下の形態による記憶メタデータ：

あるいは上記以外の表現でもよい。

図７は、プロパティ集合７０３を含むコンテキスト集合７０１を表すコンテキスト図７００を示し、これには、オプションのコンテキストアクセス方針７０５、オプションのアクセス管理集合７７、オプションの履歴集合７０９を含めることができる。プロパティ集合７０３は、コンテキスト集合７０１に関連するコンポーネント／エンティティのプロパティに関するメタデータを含み、これについて、図１０を参照しながら説明する。

コンテキスト集合７０１には、オプションのコンテキストアクセス方針７０５を含めることができる。オプションのコンテキストアクセス方針７０５は、そのコンポーネントへのアクセスを許可するためのメカニズムを特定するために使用される。この方針の一部は、コンポーネントに対し、アクセスを要求しているエンティティ／コンポーネントの認証を行うよう要求することができ、また、特定されたエンティティ／コンポーネントがコンテキスト集合７０１を含むコンポーネントにアクセスできるか否かを実行またはその他の方法で指示することができる。方針の例として、サービスコンポーネントと異なるロケーションにある、他の方法で認証されたエンティティへのアクセスを否認する方針や、瑕疵のある方針にかかわらず、特定のエンティティ／コンポーネントのアクセスを許可するバイパス方針、および／またはコンテキストモニタ等へのアクセスを許可する方針がある。

さらに、コンテキスト集合７０１は、オプションのアクセス管理集合７０７を含むことができる。オプションのアクセス管理集合７０７は、アクセス許可を特定のエンティティまたは特定の種類のエンティティに関連付けるメタデータを含むことができる。オプションのアクセス管理集合７０７については、図９を参照しながらさらに詳しく説明する。

さらに、コンテキスト集合７０１は、コンテキスト集合７０１と関連するコンポーネントへの過去の動作を表す履歴メタデータを含むオプションの履歴集合７０９を含んでもよい。オプションの履歴集合７０９については、図８を参照しながらさらに詳しく説明する。他のプロパティ関係のデータ履歴は、プロパティ集合７０３の中で維持される。

図８は、コンテキスト履歴集合７０９を表すコンテキスト履歴図７２０を示す。オプションの履歴集合７０９は、少なくともひとつのコンテキスト履歴エントリ７２３を含む。コンテキスト履歴エントリ７２３は、動作フィールド７２５、リクエスタフィールド７２７、時間フィールド７２９、理由フィールド７３１および状態フィールド７３３を含むことができる。

動作フィールド７２５には、コンテキスト集合７０１にどの動作が加えられたか（あるいは加えられようとしたか）を示す情報が含まれる。これらの動作には、たとえば、コンテキストのプロパティ、アクセス管理、履歴の追加、削除、維持、変更等がある。

リクエスタフィールド７２７には、動作フィールド７５に示される動作を呼び出したエンティティおよび／またはコンポーネントを特定する情報が含まれる。時間フィールド７２９には、その動作が要求され、および／または実行された時のタイムスタンプが含まれる。理由フィールド７３１には、要求するコンポーネント／エンティティによって明示される動作の理由を示す情報が含まれる。状態フィールド７３３には、コンテキスト履歴エントリ７２３の管理を助ける各種の状態が含まれる。

コンテキスト履歴集合７０９は、エンティティ／コンポーネントのコンテキストの使用履歴をまとめるのに使用できる。オプションの履歴集合７０９は、プロパティの削除と追加に関する履歴だけを含めばよい。特定のプロパティに関する履歴（またはコンテキスト集合７０１の中の他のエントリ）は、プロパティコンテキストの一部として保持できる（たとえば、図１０、図１１参照）。

図９は、アクセスエントリ７４３を含むアクセス管理集合７４１を表すアクセス管理図７４０を示す。アクセスエントリ７４３は、アクセス管理集合７４１に関連するコンテキストまたはプロパティ（図１０参照）にアクセスするための許可を有する（許可記録７４７の中に保存されている）エンティティまたはコンポーネントを特定するエンティティ／コンポーネント記録７４５を含む。ある実施形態において、コンテキストおよびコンテキストプロパティに関するアクセス管理集合は同様の構造を有する。

エンティティ／コンポーネント記録７４５によって特定されるエンティティ／コンポーネントは、単独のユーザ、ユーザグループ、コンポーネント、コンポーネントの種類あるいはその他特定可能なエンティティおよび／またはコンポーネントのいずれであってもよい。

図１０は、プロパティエントリ７５３を含むプロパティ集合７０３を表すコンテキストプロパティ図７５０を示す。プロパティエントリ７５３は、そのプロパティの識別を含むキーフィールド７５５と、そのプロパティの数値を含む現在値フィールド７５７を含むことができる。プロパティエントリ７５３にはまた、オプションの有効期限フィールド７５９とオプションのプロパティアクセス方針フィールド７６１を含めてもよい。

キーフィールド７５５は、プロパティ識別子（一般に、人間が判読可能なテキストで、おそらくは国際化の対象となっている）を含む。

オプションの有効期限フィールド７５９により、プロパティ値を設定しているコンポーネントは、その数値が古くなる（信頼できないものとなる）と予想される時期を示すことができる。

プロパティエントリ７５３は、エンティティ／コンポーネントがオプションのプロパティアクセス方針フィールド７６１を含むプロパティにアクセスし、および／またはこれについて動作することができるか否かを指示するのに使用できるオプションのプロパティアクセス方針フィールド７６１を含むことができる。方針の例としては、サービスコンポーネントと異なるロケーションにある、他の方法で認証されたエンティティへのアクセスを否認する方針や、既存の方針にかかわらず、特定のエンティティ／コンポーネントのアクセスを許可するバイパス方針、および／またはコンテキストモニタ等へのアクセスを許可する方針がある。

主要キー／数値プロパティに加え、プロパティエントリ７５３には、オプションのプロパティ履歴集合７６３および／またはオプションのアクセス管理集合７６５を含めることができる。

オプションのアクセス管理集合７６５の構造は、アクセス管理集合７４１と同じにすることができ（ただし、同じにする必要はない）、これをコンテキストではなくプロパティに適用する。

オプションのプロパティ履歴集合７６３は一般に、コンテキスト履歴集合７０９とは異なり、使用および／または変更履歴を特定のプロパティとまとめるのに使用される。オプションのプロパティ履歴集合７６３については、図１１を参照しながら説明する。

図１１は、プロパティ履歴エントリ７７３を含むプロパティ履歴集合７６３を表すプロパティ履歴図７７０を示す。プロパティ履歴エントリ７７３は、特定のプロパティに加えられた変更履歴を維持するのに使用できる。プロパティ履歴エントリ７７３には、新数値フィールド７７５、旧数値フィールド７７７、リクエスタフィールド７７９、時間フィールド７８１および理由フィールド７８３を含めることができる。

新数値フィールド７７５は、時間フィールド７８１内に示される時刻の時点で現在値フィールド７５７に設定される数値を記憶する。旧数値フィールド７７７は、時間フィールド７８１に示された時刻の直前の、現在値フィールド７５７の数値を記憶する。リクエスタフィールド７７９は、プロパティの変化の原因となったコンポーネント／エンティティを特定する数値を記憶する。理由フィールド７８３は、なぜそのプロパティが変更されたかを示す数値を含むことができる。

コンテキスト履歴集合７０９とプロパティ履歴集合７６３を維持することにより、コンポーネントはそのコンポーネントと他のコンポーネントとの間の相互作用のコンテキスト履歴を累積する。さらに、コンテキストモニタも、そのコンテキストモニタが使用されている環境内でのコンポーネント間の相互作用のコンテキスト履歴を累積できる。各コンポーネントが有するコンポーネントコンテキストは、他のコンポーネントまたはコンテキストモニタによって明らかにできる。コンポーネント間の動作は、リクエストコンポーネントが動作要求とリクエスタコンポーネントのコンテキストをサービスコンポーネントに送信することによって誘発される。サービスコンポーネントは、リクエスタコンポーネントのコンテキストをサービスコンポーネントのコンテキストメタデータとして記録することができる。動作とリクエスタコンポーネントのコンテキストは、他のコンポーネントまたはコンテキストモニタによっても記録されることが可能である。記録されたメタデータを結合することにより履歴メタデータが得られ、これを使ってコンポーネント間の将来の相互作用を簡略化できる。

このほか、コンポーネントは自分のプロパティを変更でき、これらの変更もまたそのコンポーネントのコンテキスト履歴の中に累積される。

図１２は、コンテキストアクセスプロセス１２００を示しており、「開始」１２０１から始まり、「要求受取」手順１２０３へと続く。「要求受取」手順１２０３は、利用可能な通信メカニズムを使い、リクエスタコンポーネントからの動作およびコンテキストを受け取る。この動作には、プロパティをコンテキスト集合７０１の抽出レベルにおいて定義、削除されるようにする動作、プロパティをプロパティ集合７０３の抽出レベルにおいて変更、アクセスされるようにする動作、コンテキスト履歴をコンテキスト集合７０１の抽出レベルでアクセスされるようにする動作、およびコンポーネントのコンテキストにアクセスし、これを保持する動作が含まれる。

要求が受け取られると、コンテキストアクセスプロセス１２００は、不完全な状態（状態フィールド７３３に記憶できる）を有するコンテキスト履歴エントリ７２３を保存する「試行履歴保存」手順１２０５に続く。次に、「コンテキストアクセスチェック」決定手順１２０７がオプションのコンテキストアクセス方針７０５とオプションのアクセス管理集合７０７を使い、リクエスタコンポーネントのアイデンティティを検証し、そのリクエスタコンポーネントがコンテキスト集合７０１の抽象レベルで要求された動作を実行することを許可されているかを検証する。

「コンテキストアクセスチェック」決定手順１２０７は、その動作を要求したエンティティ／コンポーネント上でさまざまなチェックを実行する。これらのチェックには、１）あらゆるエンティティ／コンポーネントによるすべての動作を許可する、２）エンティティ／コンポーネントの識別を認証する、３）エンティティ／コンポーネントが要求された動作を実行する許可を持っていることを検証する、４）特定のエンティティ／コンポーネントについてユーザが指定した無効化（オーバーライド: override）があるか否かをチェックする、およびその他、オプションのコンテキストアクセス方針７０５によって定義される、あるいはオプションによるアクセス管理集合７０７によって要求されるその他のチェックのうちの少なくともひとつまたは複数が含まれる。

「コンテキストアクセスチェック」決定手順１２０７がリクエスタコンポーネント／エンティティへのアクセスを拒否すると、コンテキストアクセスプロセス１２００は、試行された動作をログ（記録）し、状態フィールド７３３を更新する「コンテキスト拒絶履歴保存」手順１２１１に続く。さらに、リクエスタコンポーネント／エンティティにも、アクセスの拒否を知らせることができる。

これに対し、「コンテキストアクセスチェック」決定手順１２０７がリクエスタコンポーネント／エンティティによるコンテキスト集合７０１へのアクセスを許可した場合、「コンテキスト動作」決定手順１２１５が、要求された動作はコンテキスト集合７０１の抽象レベルで実行されるべきかを決定する。そうであれば、コンテキストアクセスプロセス１２００は、「コンテキスト動作実行」手順１２１７に進み、ここで要求された動作が実行される。

要求された動作が完了すると、コンテキストアクセスプロセス１２００は、「コンテキスト履歴保存」手順１２１８に進み、この手順は「試行履歴保存」手順１２０５によって保存される履歴記録の中のオプションの履歴集合７０９に動作の結果を保存し、これに従って状態フィールド７３３を更新する。

しかしながら、「コンテキスト動作」決定手順１２１５において、要求された動作がプロパティ集合７０３の抽象レベルで実行されることになった場合、コンテキストアクセスプロセス１２００は「プロパティアクセスチェック」決定手順１２１９に進み、これがキーフィールド７１５５を使って特定されたプロパティをプロパティエントリ７５３の中に位置づけ、「コンテキストアクセスチェック」決定手順１２０７によって実行されたものと同様のチェックを行うことができる（ただし、オプションのプロパティアクセス方針フィールド７６１および／またはオプションのアクセス管理集合７６５を使い、プロパティ集合７０３の抽象レベルとプロパティエントリ７５３そのものの中で、チェックを行うことができる）。要求された動作が許可されないと、コンテキストアクセスプロセス１２００は「プロパティ拒絶履歴保存」手順１２２３に進み、ここで、新たなプロパティ履歴エントリ７７３がオプションのプロパティ履歴集合７６３に追加され、そのプロパティについて要求された動作が拒否されたことが示される。次に、コンテキストアクセスプロセス１２００は、「コンテキスト履歴保存」手順１２１８に進み、状態フィールド７３３が更新される。

「プロパティアクセスチェック」決定手順１２１９において、要求された動作が許可されると、コンテキストアクセスプロセス１２００は「プロパティについて動作」手順１２２５に進み、特定された製品について要求された動作が試みられる。要求された動作の結果の状態は「プロパティ履歴保存」手順１２２７に送られ、これが新規のプロパティ履歴エントリ７７３をオプションのプロパティ履歴集合７６３に追加し、このようにして要求されたプロパティ動作の状態と結果が得られる。次に、コンテキストアクセスプロセス１２００は「コンテキスト履歴保存」手順１２１８に進み、状態フィールド７３３が更新される。

あるコンポーネントのコンテキストについて許可される動作には、プロパティ集合７０３にプロパティを追加する、あるいはここからプロパティを削除すること、オプションの履歴集合７０９へのアクセスを読み取ること、およびオプションのアクセス管理集合７０７への変更を許可することが含まれる。特定のプロパティの変更履歴は、そのプロパティそのものとともに、オプションのプロパティ履歴集合７６３の中に保存される。

あるプロパティについて許可される動作には、現在値フィールド７５７の数値および／またはオプションの有効期限フィールド７５９を変更すること、これらの数値にアクセスすること、あるいはオプションのプロパティ履歴集合７６３にアクセスすることが含まれる。

前述の説明に基づき、当業者はまた、オプションによる履歴集合７０９にアクセスする方法や、あるエンティティに個別で自己の履歴を更新させる方法を理解できるであろう。

図１３は、サービスコンポーネントがその履歴メタデータを提供するのに使用できる履歴供給プロセス１３００を示す。履歴供給プロセス１３００は、リクエスタコンポーネント（たとえば、ｇｅｔＰｒｏｐｅｒｔｙＨｉｓｔｏｒｙ（）方式の呼び出しによる履歴検索メカニズム等）から呼び出された履歴要求を受け取ったところで、「開始」１３０１から始まる。履歴供給プロセス１３００は、要求が十分に形成されていることを検証できる「履歴要求点検」手順１３０３に続く。「履歴供給」手順１３０７は、要求された履歴メタデータを組み立て、組み立てられたメタデータをリクエスタコンポーネントに送信する。

エンティティ／コンポーネントのコンテキストに履歴およびアクセス情報が含まれると、リクエスタコンポーネント／エンティティは他のエンティティ／コンポーネントに履歴および許可情報を要求し、これらのコンポーネントのうちどれにリクエスタコンポーネント／エンティティがアクセスできるかを判断して、利用可能な履歴コンテキストに基づき、ユーザにとってのオプションの優先順位を付けることができる。この優先順位付けは、コンポーネントのエンティティのアイデンティティおよび／またはコンテキストモニタから利用できる情報に基づいて行われる。この情報は、環境内のコンポーネントに要求し、ふるいにかけて使用できないコンポーネントを排除し、エンティティの選好に基づいて、また環境の状況に応じて変更する。この情報は、構成再構築メカニズムにより、構成確立メカニズムによってどのようなコンポーネント構成が確立できるかを判断するために使用される。

コンポーネント探索サービスは通常、探索コンポーネントがアクセスしたすべてのエンティティ／コンポーネントに関する情報を戻す。これはしばしば、大量の情報を探索コンポーネントのユーザに提供することになる。ユーザは、自分にとって関心のないコンポーネントをふるい落とすためのテンプレートを提供することができる。

本発明のひとつの実施形態は、リクエスタコンポーネント／エンティティおよび検索されているコンポーネントの両方の背景コンテキスト情報に基づいて、コンポーネント検索結果の優先順位付けとフィルタリングを行う方法を提供する。あるエンティティに関するコンテキスト情報には、アイデンティティ、ロケーション、優先性、利用履歴等の情報が含まれる。コンポーネントに関するコンテキスト情報には、サポートされているデータのタイプ、ロケーション（これを持っている場合）、ロケーション要件、利用履歴、セキュリティ方針等の情報が含まれる。エンティティとコンポーネントの情報を組み合わせ、アクセス管理上の制限によって、所与のエンティティ／コンポーネントが使用できないコンポーネントを排除することができる。この情報を組み合わせることにより、現状においてそのユーザにとって最も有益なものは何かに基づき、利用可能なコンポーネント／エンティティを提示する優先順位も付けることができる。

コンテキスト情報は、２つの方法で分類される。つまり、動的対静的および状態対要求である。コンテキスト状態は、あるコンポーネント／エンティティのプロパティの数値を表す。要求コンテキストは、あるコンポーネント／エンティティのユーザにとっての前提条件を表す。動的コンテキストは、コンテキスト情報が実行中に更新されているときのものである。静的コンテキストは、定義されたときに特定され、定義し直されるまで変更されない。このようなコンテキストの表現は、そのコンテキストが実際にどのように取得され、検証されるかに無関係である。

本発明のひとつの実施形態は、これらの属性を、データタイプ、アイデンティティアクセス制御、ロケーションアクセス制御等、他の静的コンテキスト要件で補うことができる。特定された要件のすべてを満たすことができないコンポーネントは、ユーザに提示されるコンポーネントのリストから直ちに除外される。つまり、コンポーネントはコンテキスト要件を持ち、エンティティ（人）は静的および動的コンテキスト状態を持ち、フィルタリング時にこれらの状態と要件を組み合わせることができる。

本発明のさらに別の面は、エンティティの使用履歴をコンポーネントの使用履歴と組み合わせ、戻されたコンポーネントを人気（またはその他のメトリクス）によって優先順位付けする。人気のメトリクスは、過去において使用されたコンポーネントが将来においても再び使用される可能性が高いため、興味深い。

利用可能なコンポーネント／エンティティおよび／またはコンポーネントの相互作用をフィルタにかけ、これに優先順位を付ける方法のひとつは、その履歴情報をフィルタにかけ、これに優先順位を付けるプロセスを適用することである。

図１４は、環境内のコンポーネントから履歴コンテキストを収集するために使用できるフィルタ／優先順位付けプロセス１４００を示す。フィルタ／優先順位付けプロセス１４００は、ユーザ、エンティティの要求、環境の変化の検出あるいはその他のトリガにより、「開始」１４０１から始まる。フィルタ／優先順位付けプロセス１４００は、「初期化」手順１４０３に進み、ここで、要求された初期化が行われ、次に、「履歴要求」手順１４０５に進む。「履歴要求」手順１４０５はまず、どのコンポーネントが環境内にあるかを検出し、履歴要求コマンドならびに創出（オリジネーティング: originating）コンポーネントのコンテキストとともに、環境内の関係するコンポーネント／エンティティの各々に送信する。「履歴受取」手順１４０７は、コンポーネント／エンティティが「履歴要求」手順１４０５からの要求に応える際（図１３参照）に、そこから履歴を受け取る。リクエスタコンポーネントは次に、「履歴に基づくコンポーネントフィルタ」手順１４０９を使い、指定されたフィルタプロパティによる特定に従って、コンポーネントの履歴情報および／または受け取った履歴情報に基づき、コンポーネントをフィルタにかけ、これに優先順位を付ける。「履歴に基づくコンポーネントフィルタ」手順１４０９の結果は「履歴に基づくコンポーネント優先順位付け」手順１４１１に送られ、これが優先順位決定パラメータに応じてその結果を順番に並べる。コンポーネントを特定する優先順位付けされた情報は次に、「結果提示」手順１４１３によってコンポーネントの順位リストとして提示され、これにより、エンティティ／コンポーネントは、たとえばその過去のコンテキスト履歴およびその他利用可能な情報に基づいて、どのコンポーネントを使用するかを選択できる。

フィルタリングと優先順位付けがコンポーネント選択の援助を提供するのに不十分な場合がある。

多数のエンティティ／コンポーネントが各々のコンテキスト履歴を保持しているユビキタスコンピューティング環境において、エンティティ／コンポーネントが位置する環境またはその環境の使用に関する推論を建てることは可能である。したがって、その環境の中の状況が変化した場合、エンティティ／コンポーネントの相対的重要性もまた変化する可能性がある。たとえば、プレゼンテーション中、プレゼンターにとってはおそらくメディアデバイスがその部屋の中で最も高い関心の的であり、一方、画像変換サービスやキャラクタ認識コンポーネント等のコンポーネントはそれほどの重要性を持たないであろう。反対に、室内で、その他のデバイスより後者のコンポーネントのほうが容易により大きな重要性を持つことになる状況もある。

本発明のひとつの実施形態は、環境、コンポーネント／エンティティのグループおよび／または情報を観察することのできるコンテキストモニタまたはコンテキストモニタシステムである。これらのモニタは、コンポーネントと組み合わせる必要がないという点でコンポーネントを必要とせず、コンテキストモニタの機能は、どのコンポーネント／エンティティが、そのコンテキストモニタが担当するモニタ対象の環境に入ってきたかを観察し、環境の状況的評価を提供することである。

たとえば、会議室用のコンテキストモニタは、そのドメイン内に、その会議室内のすべてのプレゼンテーション媒体を有することができる。このコンテキストモニタはまた、室内のエンティティならびに照明、室温といった環境管理を監視することもできる。このコンテキストモニタはさらに、以前の事象の履歴も保持できる。このコンテキストモニタは、特定の数の人が室内にいることを検出し、情報を分析して環境の状況的評価を推定することが可能である。

このコンテキストモニタは、室内のコンポーネントについて行われた動作を観察、記録し、この情報は推論エンジンに供給される。コンテキストモニタによって収集された、コンポーネントに対する動作に関するデータは、フィルタにかけ、コンポーネント／エンティティおよび推論エンジンに供給することができる。コンポーネントは、複数のコンテキストモニタで監視してもよい（エンティティは、そのエンティティのオフィスのためのコンテキストモニタおよびそのエンティティのプロジェクトグループのためのコンテキストモニタと関連することができる）。

図１５は、コンテキストモニタを開始するのに使用されるコンテキストモニタ初期化プロセス１５００を示す。コンテキストモニタ初期化プロセス１５００は、コンテキストモニタサービスが開始されると「開始」１５０１から始まり、必要な初期化を実施する「初期化」手順１５０３に進む。次に、コンテキストモニタ初期化プロセス１５００は、「探索スレッド開始」手順１５０５と「推論エンジンスレッド開始」手順１５０７を使って、さまざまなスレッドを開始する。当業者は、図１５にはこれらのスレッドによって特定の順序で開始されることが示されているものの、他の同等の実施形態でも別の順序でそのスレッドを開始することが可能であることを理解できる。

図１６は、「探索スレッド開始」手順１５０５によって呼び出すことができ、「開始」１５１３から始まる探索スレッド１５１２を示す。一旦開始されると、「初期化」手順１５１５はそのスレッドについての初期化を実施し、探索スレッド１５１２は「コンポーネント検出」手順１５１７に続く。「コンポーネント検出」手順１５１７は、環境内の他のエンティティ／コンポーネントを探索する。各エンティティ／コンポーネントが探索されると、探索スレッド１５１２は「コンポーネントに関するモニタスレッド開始」手順１５１９を開始し、探索されたコンポーネントと、監視対象となる環境内の他のコンポーネントとの間の通信と動作を監視するスレッドを始める。探索スレッド１５１２は次に、「コンポーネント検出」手順１５１７に戻り、環境内の別のエンティティ／コンポーネントを探索する。

「コンポーネント検出」手順１５１７は、各種の方法でエンティティ／コンポーネントを検出できる。

図１７は、「推論エンジンスレッド開始」手順１５０７によって呼び出すことのできる推論エンジンスレッド１５２０を示す。推論エンジンスレッド１５２０は「開始」１５２１から始まり、「初期化」手順１５２３に進んで必要な初期化機能を実行する。次に、推論エンジンスレッド１５２０は「環境安定性判断」手順１５２５に進み、探索スレッド１５１２の活動を監視して、そのコンテキストモニタによって監視される環境がいつ、合理的推論をサポートするのに十分安定するかを判断する。推論エンジンそのものは、この判断を下すのに役立てるために使用でき、禁止対象の環境の過去における使用、ネットワーク接続されたカレンダリングシステムの日付、時刻、状態およびその他、推論エンジンが利用できる情報を考慮することができる。

「環境安定性判断」手順１５２５が満たされると、推論エンジンスレッド１５２０は「予備推論分析」手順１５２７に進み、環境内にあると検出されたエンティティ／コンポーネントを分析し、環境状況の予備評価を行う。

次に、「エンティティ／コンポーネント要求受取」手順１５２９は、リクエスタコンポーネントからの要求を待つ。要求を受け取ると、推論エンジンスレッド１５２０は「各要求分析」手順１５３１に進み、その要求に照らして、おそらく「予備推論分析」手順１５２７の結果を使って、その状況に推論エンジンを適用する。この分析結果は、「要求への応答」手順１５３３においてコンポーネント／エンティティ／コンピュータに戻され、推論エンジンスレッド１５２０は「エンティティ／コンポーネント要求受取」手順１５２９に戻り、次の要求を処理する。

図１８は、「コンポーネント検出」手順１５１７によって呼び出すことができるコンポーネント監視スレッド１５５０を示し、これは「開始」１５５１から始まり、「初期化」手順１５５３に進んで必要な初期化を行う。次に、コンポーネント監視スレッド１５５０は「履歴収集」手順１５５５に進み、ここでコンポーネント／エンティティからのコンテキスト履歴を取得し、コンテキスト履歴のどの部分が現在の環境に関係があるかを判断する。コンポーネント／エンティティからの関係するコンテキスト履歴は、「関係履歴の推論データベースとの併合」手順１５５７によって推論データベースと併合される。次に、コンポーネント監視スレッド１５５０は、「コンポーネント相互作用監視および推論データベース更新」手順１５５９に進み、これがエンティティ／コンポーネントの他のエンティティ／コンポーネントとの相互作用を監視し、推論データベースを更新する。「コンポーネント相互作用監視および推論データベース更新」手順１５５９は、継続的にコンポーネント／エンティティの相互作用を監視し、更新を実行する。

「コンポーネント相互作用監視および推論データベース更新」手順１５５９が、監視対象のエンティティ／コンポーネントがある期間にわたり、他のコンポーネントと相互作用していないと判断した場合、コンポーネント監視スレッド１５５０はその監視対象のエンティティ／コンポーネントに休眠とマークする。定期的に、コンポーネント監視スレッド１５５０は「コンポーネント休眠」決定手順１５６１に進み、エンティティ／コンポーネントについて、それが休眠とマークされているか否かチェックする。そのエンティティ／コンポーネントが休眠とマークされていない場合、コンポーネント監視スレッド１５５０は「コンポーネント相互作用監視および推論データベース更新」手順１５５９に戻る。

しかしながら、「コンポーネント休眠」決定手順１５６１において、禁止対称のエンティティ／コンポーネントが休眠とマークされていると、監視対象のエンティティ／コンポーネントは、そのコンテキストモニタによって監視される環境内にはなくなっている可能性がある。すると、コンポーネント監視スレッド１５５０は「タイマスタート」手順１５６３に進み、タイムアウトタイマをスタートさせ、次に「休眠コンポーネントポーリング」手順１５６５に進んで監視対象のエンティティ／コンポーネントにメッセージを送り、応答を呼び出す。「タイマスタート」手順１５６３によってセットされたタイマが切れると、「コンポーネント応答」決定手順１５６７は、監視対象のモニタ／コンポーネントが応答したか否かを判断する。監視対象のエンティティ／コンポーネントが応答していれば、コンポーネント監視スレッド１５５０は「コンポーネントに非休眠とマーク」手順１５６９に進み、これがその監視対象のエンティティ／コンポーネントに非休眠とマークする。次に、コンポーネント監視スレッド１５５０は「コンポーネント相互作用監視および推論データベース更新」手順１５５９に進み、監視対象のエンティティ／コンポーネントの監視を続ける。

これに対し、「コンポーネント応答」決定手順１５６７において、監視対称のエンティティ／コンポーネントが応答していないと、コンポーネント監視スレッド１５５０は「スレッド終了」手順１５７１に進み、リソースを解除してスレッドを終了する。

実施形態の別の面は、コンテキスト情報を使ってセキュリティ情報にアクセスし、これに使用することである。つまり、セキュリティデータは、（先行技術において行われているように）プログラムインタフェースを通じてセキュリティ情報を明確に表現することを要求するのではなく、コンテキストプロパティとして維持することができる。コンポーネントが相互からデータを得る、あるいは相互に対する動作を要求すると、そのコンテキストによって提供されるセキュリティ情報をどのように使用するか（またはこのセキュリティ情報を使用するか否か）は関係者に任せられる。したがって、異なるセキュリティモデルおよびテクニックについて、均一なプログラムインタフェースを使用することができる。

リクエスタコンポーネント／エンティティが、サービスコンポーネントに対する動作を実行したい場合、リクエスタコンポーネントはセキュリティ情報（たとえば証明書、パスワードまたはそのアイデンティティのその他の証明）をサービスコンポーネントに伝えなければならない。このセキュリティ情報は、コンテキストプロパティとすることができる。コンポーネント間のすべての通信において、コンテキストをパラメータとして渡すことが必要となるため、リクエスタコンポーネントからのセキュリティ情報をサービスコンポーネントに提供することができる。サービスコンポーネントがセキュリティ情報を使用すると決定した場合、これは、リクエスタコンポーネント／エンティティの証明を認証機関に送り、検証を受けることができる。また、エンティティは、リクエスタコンポーネント／エンティティによるその後の改良のために、ゲスト証明を提供することも可能である。

他のコンポーネントが「知る」ことのできるプロパティキーを有する、きわめて一般的使用されると特定のコンテキストパラメータがある。同様に、確実な証明で認証されるコンポーネントは、よく知られたキーを持つコンテキストプロパティを有する。セキュリティプロパティは単なるコンテキスト情報であるため、セキュリティプロパティは、他のコンテキストプロパティと同様に、コンポーネントのニーズに応じて要求してもしなくてもよい。さらに、証明プロパティをコンポーネントの残りのプロパティとともに提供することができる。

サービスコンポーネント／エンティティに、セキュリティ情報を使用するか否かを決定させることにより、サービスコンポーネントは、特定の状況におけるアクセス方針の例外を容易に作ることができる。

オプションのコンテキストアクセス方針７０５とオプションのプロパティアクセス方針フィールド７６１はそれぞれ、オプションのアクセス管理集合７０７およびオプションのアクセス管理集合７６５（プロパティ用）とともに使用することができる。これらの方針には、どのような種類の認証が必要で、どのような状況において認証を無効化できるかを決定するルールが含まれる。

さらに、本発明の実施形態のこの面により、そのコンポーネントによって使用されるプログラムインタフェースを変更することを必要とせずに、認証戦略を変更する柔軟性が得られる。相互に信用される証明付与／認証機関が適当な場合もあれば、エンティティが相互に関する公開鍵を保有する、「公開鍵暗号方式」を使用するコンポーネントもある。さらに別のケースでは、ひとつのコンポーネントを別のコンポーネントに「ログオン」できるようにするパスワードを必要とする。これらのケースはいずれも、そのコンポーネントのコンテキストを使用する、同じプログラムインタフェースによって扱われる。

本発明の実施形態によるコンテキスト情報を提供するためのシステムの斜視図である。 コンテキスト情報を提供するためのシステムにおいて利用される任意コンポーネントの一例のブロック図である。 本発明の実施形態によるコンテキスト情報を提供するためのシステムの部分斜視図である。 コンテキスト情報を提供するプロセスのフローチャートである。 本発明の実施形態によるコンテキスト情報を提供するためのシステムの部分斜視図である。 コンテキスト情報を提供するプロセスのフローチャートである。 本発明の実施形態によるコンポーネントのコンテキストの組成を示す図である。 本発明の実施形態によるコンポーネントのコンテキスト履歴の組成を示す図である。 本発明の実施形態によるコンポーネントのコンテキストアクセス制御の組成を示す図である。 本発明の実施形態によるコンポーネントのプロパティの組成を示す図である。 本発明の実施形態によるコンポーネントのプロパティ履歴の組成を示す図である。 ある実施形態によるコンテキストアクセスプロセスを示す図である。 ある実施形態によるコンテキスト履歴を提供するプロセスを示す図である。 ある実施形態によるフィルタ／優先順位付けプロセスを示す図である。 ある実施形態によるコンテキストモニタを初期化するプロセスを示す図である。 ある実施形態によるコンテキストモニタの探索スレッドを示す図である。 ある実施形態による推論エンジンスレッドを示す図である。 ある実施形態によるコンポーネントモニタスレッドを示す図である。

符号の説明

１０ システム、１２ コンピュータ、１４ａ 汎用インタフェースセット、１４ｂ データオブジェクト、１４ｃ コンテキストオブジェクト、１４ プリンタ、１６ａ 汎用インタフェースセット、１６ｂ データオブジェクト、１６ｃ コンテキストオブジェクト、１８ サーバ、２０ ネットワーク、２２ 中央処理ユニット、２４ メモリ、２６ Ｉ／Ｏユニット。

Claims (10)

1. 複数のコンポーネント間の相互作用のコンテキスト履歴を累積するためのコンピュータ制御による方法であって、
   前記複数のコンポーネントは、リクエスタコンポーネントとサービスコンポーネントを含み、
   前記リクエスタコンポーネントにより、前記サービスコンポーネントの動作を要求するステップと、前記リクエスタコンポーネントは、リクエスタコンポーネントのコンテキストを前記サービスコンポーネントに渡すよう構成されており、
   前記リクエスタコンポーネントのコンテキストを、サービスコンポーネントのコンテキストメタデータとして記録するステップと、
   を含むことを特徴とする方法。
2. 請求項１に記載のコンピュータ制御による方法であって、
   前記サービスコンポーネントのコンテキストメタデータは、履歴メタデータと結合されることを特徴とする方法。
3. 相互作用のコンテキスト履歴を累積するためのコンピュータ制御によるシステムであって、
   複数のコンポーネントと、前記複数のコンポーネントは、それが何かを明らかにすることのできるコンポーネントコンテキストを有し、前記複数のコンポーネントは、リクエスタコンポーネントとサービスコンポーネントを備え、
   前記リクエスタコンポーネントの中にあり、前記サービスコンポーネントの動作を要求するよう構成された要求メカニズムと、前記要求メカニズムはリクエスタコンポーネントのコンテキストを前記サービスコンポーネントに渡すよう構成され、
   前記要求メカニズムに応答し、前記リクエスタコンポーネントのコンテキストをサービスコンポーネントのコンテキストメタデータとして記録するよう構成された記録メカニズムと、
   を備えることを特徴とするシステム。
4. 請求項３に記載のコンピュータ制御によるシステムであって、
   前記記録メカニズムは前記サービスコンポーネントの中にあることを特徴とするシステム。
5. 請求項３に記載のコンピュータ制御によるシステムであって、
   前記サービスコンポーネントコンテキストメタデータは、履歴メタデータと結合されることを特徴とする方法。
6. それが何かを明らかにすることのできるコンポーネントコンテキストにおける変更のコンテキスト履歴を累積するための装置であって、
   前記コンポーネントコンテキストの一部を変更する動作を検出するよう構成された検出メカニズムと、
   前記検出メカニズムに応答し、前記部分を前記コンテキスト履歴と結合するよう構成されている結合メカニズムと、
   前記動作に応答して前記部分を変更するよう構成された変更メカニズムと、
   を備えることを特徴とする装置。
7. 請求項６に記載の装置であって、
   さらに、前記コンテキスト履歴を提示するよう構成された提示メカニズムを備えることを特徴とする装置。
8. 請求項６に記載の装置であって、
   前記部分は履歴メタデータとして結合されることを特徴とする装置。
9. コンピュータ制御による方法であって、
   要求を受け取るステップと、
   前記要求にコンテキストアクセス方針を適用するステップと、
   前記要求が、一連のコンテキストアクセス許可のひとつを満足することを確認するステップと、
   前記確認ステップに応答して前記要求を満たすステップと、
   を含むことを特徴とする方法。
10. 装置であって、
    要求を受け取るよう構成された受信メカニズムと、
    前記受信メカニズムによって受け取られた前記要求にコンテキストアクセス方針を適用するよう構成された第一のセキュリティメカニズムと、
    前記要求が一連のコンテキストアクセス許可のひとつを満足していることを確認するよう構成された第一の許可メカニズムと、
    前記第一の許可メカニズムに応答して前記要求を満たすよう構成された動作メカニズムと、
    を備えることを特徴とする装置。

Images