(57)【要約】サーバフェデレーションは、スキーマによって通信データの意味が示唆されるスキーマに準拠するデータ構造を使用して通信を行うことにより、協調的にインタラクトしてサービス要求を満たす。したがって、データを通信するのに加えてデータの意味も通信され、データの意味に基づいてインテリジェントな決定および推論を行うことが可能になる。協調的なインタラクションは、複数のトランスポート機構をサポートする共通のＡＰＩを通じてメッセージングを行うことにより、各種のネットワーク上で容易になる。また、スキーマとトランスポートに依存しないメッセージング構造とによって、セッション中にクライアントデバイス間を移動することも容易になる。クライアントデバイスのユーザインタフェースは、それらのクライアントデバイスが異なるユーザインタフェース機能を備える場合であっても一貫性のある表示になる。
2004531780.tif 000002
【特許請求の範囲】
【請求項１】
ソフトウェアアプリケーションであって、
クライアントデバイスにユーザインタフェースをプロジェクトするように構成されたページコンポーネントと、
前記ページコンポーネントによってプロジェクトされた前記ユーザインタフェース上に表すことのできるライブデータをホストするように構成されたフィーフダムコンポーネントと、
前記フィーフダムコンポーネントに対して前記ページコンポーネントを表すエミッサリコンポーネントとを備えることを特徴とするソフトウェアアプリケーション。
【請求項２】
請求項１に記載のソフトウェアアプリケーションであって、前記ページコンポーネント、前記エミッサリコンポーネント、および前記フィーフダムコンポーネントはサーバに実装されることを特徴とするソフトウェアアプリケーション。
【請求項３】
請求項１に記載のソフトウェアアプリケーションであって、前記ページコンポーネントは前記クライアントデバイスに実装され、前記フィーフダムコンポーネントはサーバに実装されることを特徴とするソフトウェアアプリケーション。
【請求項４】
第１のデバイスと第２のデバイスとの間の通信方法であって、
前記第１のデバイスが、前記第２のデバイスにより認識されるスキーマを利用して情報を構造化するステップであって、前記情報の意味が前記スキーマによって示唆されるステップと、
前記第１のデバイスが、前記情報を前記第２のデバイスに送信するステップとを備えることを特徴とする方法。
【請求項５】
ユーザインタフェースであって、
デバイスのユーザインタフェース機能を判定する手段と、
前記デバイスのユーザインタフェース機能にマッチするユーザインタフェースを提供する手段とを備えることを特徴とするユーザインタフェース。
【請求項６】
請求項５に記載のユーザインタフェースであって、前記デバイスは第１のデバイスであり、前記ユーザインタフェースは、ユーザが、異なるユーザインタフェース機能を有する第２のデバイスに切り替えた場合に、ユーザインタフェース機能に合わせてスケーリングする手段をさらに備えることを特徴とするユーザインタフェース。
【請求項７】
ユーザインタフェースであって、
ユーザの状態または近接度を判定する手段と、
前記ユーザの状態または近接度に基づいて入力または出力の方式を調節する手段とを備えることを特徴とするユーザインタフェース。
【請求項８】
ユーザインタフェースであって、
スキーマに従っているユーザ入力を認識する手段と、
前記スキーマによって示唆される前記ユーザ入力の意味を認識する手段と、
前記ユーザ入力の意味に適した機能を実行する手段とを備えることを特徴とするユーザインタフェース。
【請求項９】
統一されたコマンドラインを備えるユーザインタフェースであって、
前記統一されたコマンドラインにユーザが入力したクエリを受け取る手段と、
前記クエリのあいまい性を識別する手段と、
前記あいまい性を少なくとも部分的に明確にする情報を要求する応答クエリを作成し、前記ユーザに伝える手段とを備えることを特徴とするユーザインタフェース。
【請求項１０】
ソフトウェアであって、
複数の既存のイベントから新しいイベントを構築するように構成されたイベントコンポジション機構と、
前記新しいイベントをルーティングするように構成されたイベントルーティング機構とを備えることを特徴とするソフトウェア。
【請求項１１】
第１のデバイスが第２のデバイスと通信する方法であって、
前記第１のデバイスがメッセージを構築するステップと、
前記第１のデバイスが、トランスポートに依存しない機構を使用して、前記メッセージを前記第２のデバイスに送信するステップとを備えることを特徴とする方法。
【請求項１２】
統一されたストレージ機構であって、
離れたユーザインタフェースから情報に対する要求を受け取る手段と、
前記情報がどこに離れて記憶されているかを判定するように構成されたディレクトリコンポーネントと、
前記情報を取り出し、前記情報をユーザインタフェースに提供するように構成されたストレージコンポーネントとを備えることを特徴とするストレージ機構。
【請求項１３】
ディレクトリ構造であって、
ユーザの複数のアイデンティティに関連する情報を含む適合されたディレクトリと、
前記ユーザの認証情報を記憶し、前記適合されたディレクトリへのアクセスを管理するポータルとを備えることを特徴とするディレクトリ構造。
【請求項１４】
マニフェストであって、
複数のコードコンポーネントを記述する手段と、
コードコンポーネント間の関係を記述する手段と、
前記複数のコードコンポーネントの少なくとも一部によって構成されるアプリケーションを記述する手段とを備えることを特徴とするマニフェスト。
【請求項１５】
複数のクライアントデバイスと通信する複数のサーバを含むサーバフェデレーションにおいて、要求を満たす方法であって、
前記複数のサーバの中の第１のサーバが、サービス要求を受信するステップと、
前記第１のサーバが、前記サービス要求に応答するために、少なくとも第２のサーバからのさらなる情報が必要であると判断するステップと、
前記第１のサーバが、前記第１のサーバおよび前記第２のサーバの両方で認識されるスキーマを利用して前記さらなる情報の要求を構造化するステップであって、前記さらなる情報の要求の意味が前記スキーマによって示唆されるステップと、
前記第１のサーバが、トランスポートに依存しないメッセージングインフラストラクチャを使用して、前記さらなる情報の要求を前記第２のサーバに送信するステップと、
前記第１のサーバが、前記第２のサーバから前記さらなる情報を含む応答を受信するステップと
前記第１のサーバが、前記さらなる情報を使用して前記サービス要求に応答するステップとを備えることを特徴とする方法。
【請求項１６】
請求項１５に記載の方法であって、前記第１のサーバが前記さらなる情報の要求を構造化するステップが、
前記第１のサーバが、エクステンシブルマークアップ言語（ＸＭＬ）に従って前記要求を構造化するステップを備えることを特徴とする方法。
【請求項１７】
請求項１５に記載の方法であって、前記第１のサーバが前記第２のサーバから応答を受信するステップが、
前記第１のサーバが、エクステンシブルマークアップ言語（ＸＭＬ）に従って構造化されたデータ構造の形で前記第２のサーバから前記応答を受信するステップを備えることを特徴とする方法。
【請求項１８】
請求項１５に記載の方法であって、前記第１のサーバが、トランスポートに依存しないメッセージングインフラストラクチャを使用して前記さらなる情報の要求を前記第２のサーバに送信するステップが、
前記第１のサーバが、シンプルオブジェクトアクセスプロトコル（ＳＯＡＰ）を使用して前記さらなる情報の要求を送信するステップを備えることを特徴とする方法。
【請求項１９】
請求項１８に記載の方法であって、前記第１のサーバが前記さらなる情報の要求を構造化するステップが、
前記第１のサーバが、エクステンシブルマークアップ言語（ＸＭＬ）に従って前記要求を構造化するステップを備えることを特徴とする方法。
【請求項２０】
請求項１５に記載の方法であって、前記第１のサーバが前記第２のサーバから応答を受信するステップが、
前記第１のサーバが、シンプルオブジェクトアクセスプロトコル（ＳＯＡＰ）を使用して前記第２のサーバから前記応答を受信するステップを備えることを特徴とする方法。
【請求項２１】
請求項２０に記載の方法であって、前記第１のサーバが前記第２のサーバから応答を受信するステップが、
前記第１のサーバが、エクステンシブルマークアップ言語（ＸＭＬ）に従って構造化されたデータ構造の形で前記第２のサーバから前記応答を受信するステップをさらに備えることを特徴とする方法。
【請求項２２】
請求項１５に記載の方法であって、前記第１のサーバが、トランスポートに依存しないメッセージングインフラストラクチャを使用して前記さらなる情報の要求を前記第２のサーバに送信するステップが、
メッセージングコンポーネントが、複数のトランスポートをサポートする共通アプリケーションプログラムインタフェースと通信するステップを備えることを特徴とする方法。
【請求項２３】
請求項２２に記載の方法であって、前記第１のサーバが、トランスポートに依存しないメッセージングインフラストラクチャを使用して前記さらなる情報の要求を前記第２のサーバに送信するステップが、
前記メッセージングコンポーネントが前記共通アプリケーションプログラムインタフェースと通信するのに応答して、前記共通アプリケーションプログラムインタフェースが、前記複数のトランスポートのうちの適切な１つと通信するステップを備えることを特徴とする方法。
【請求項２４】
請求項２３に記載の方法であって、前記共通アプリケーションプログラムインタフェースが前記複数のトランスポートのうちの適切な１つと通信するステップが、
前記共通アプリケーションプログラミングインタフェースが、ハイパーテキストトランスポートプロトコル（ＨＴＴＰ）トランスポートと通信するステップを備えることを特徴とする方法。
【請求項２５】
請求項２３に記載の方法であって、前記共通アプリケーションプログラムインタフェースが前記複数のトランスポートのうちの適切な１つと通信するステップが、
前記共通アプリケーションプログラムインタフェースが、ＭＳＭＱバイナリトランスポートと通信するステップを備えることを特徴とする方法。
【請求項２６】
請求項２３に記載の方法であって、前記共通アプリケーションプログラムインタフェースが前記複数のトランスポートのうちの適切な１つと通信するステップが、
前記共通アプリケーションプログラムインタフェースが、マルチキャストトランスポートと通信するステップを備えることを特徴とする方法。
【請求項２７】
請求項２３に記載の方法であって、前記共通アプリケーションプログラムインタフェースが前記複数のトランスポートのうちの適切な１つと通信するステップが、
前記共通アプリケーションプログラムインタフェースがＳＭＴＰトランスポートと通信するステップを備えることを特徴とする方法。
【請求項２８】
請求項１５に記載の方法であって、前記複数のサーバの中の前記第１のサーバがサービス要求を受信するステップが、
前記複数のサーバの中の前記第１のサーバが、第３のサーバから前記サービス要求を受信するステップを備えることを特徴とする方法。
【請求項２９】
請求項１５に記載の方法であって、前記複数のサーバの中の前記第１のサーバがサービス要求を受信するステップが、
前記複数のサーバの中の前記第１のサーバが、クライアントから前記サービス要求を受信するステップを備えることを特徴とする方法。
【請求項３０】
複数のクライアントデバイスと通信する複数のサーバを含むサーバフェデレーションの中の第１のサーバで使用されるコンピュータプログラム製品であって、当該コンピュータプログラム製品はコンピュータ可読媒体を含み、当該コンピュータ可読媒体は、
サービス要求の受信を検出するためのコンピュータ実行可能命令と、
前記サービス要求に応答するために、少なくとも第２のサーバからのさらなる情報が必要であることを判断するためのコンピュータ実行可能命令と、
前記第１のサーバおよび前記第２のサーバの両方で認識されるスキーマを利用して、前記さらなる情報の要求を構造化するためのコンピュータ実行可能命令であって、前記さらなる情報の要求の意味が前記スキーマによって示唆されるコンピュータ実行可能命令と、
トランスポートに依存しないメッセージングインフラストラクチャを使用して前記さらなる情報の要求が前記第２のサーバに送信されるようにするためのコンピュータ実行可能命令と、
前記第２のサーバからの応答の受信を検出するためのコンピュータ実行可能命令と
前記さらなる情報を使用して前記サービス要求に応答するためのコンピュータ実行可能命令とを記憶していることを特徴とするコンピュータプログラム製品。
【請求項３１】
請求項３０に記載のコンピュータプログラム製品であって、前記コンピュータ可読媒体が物理的な記憶媒体であることを特徴とするコンピュータプログラム製品。
【請求項３２】
請求項３０に記載のコンピュータプログラム製品であって、前記第１のサーバおよび前記第２のサーバの両方で認識されるスキーマを利用して前記さらなる情報の要求を構造化するためのコンピュータ実行可能命令が、
エクステンシブルマークアップ言語（ＸＭＬ）に従って前記要求を構造化するためのコンピュータ実行可能命令を備えることを特徴とするコンピュータプログラム製品。
【請求項３３】
請求項３０に記載のコンピュータプログラム製品であって、トランスポートに依存しないメッセージングインフラストラクチャを使用して前記さらなる情報の要求が前記第２のサーバに送信されるようにするためのコンピュータ実行可能命令が、
複数のトランスポートをサポートする共通アプリケーションプログラムインタフェースと通信するためのコンピュータ実行可能命令を備えることを特徴とするコンピュータプログラム製品。
【請求項３４】
請求項３３に記載のコンピュータプログラム製品であって、トランスポートに依存しないメッセージングインフラストラクチャを使用して前記さらなる情報の要求が前記第２のサーバに送信されるようにするためのコンピュータ実行可能命令が、
前記共通アプリケーションプログラムインタフェースと通信するためのコンピュータ実行可能命令の実行に応答して、前記共通アプリケーションプログラムインタフェースが前記複数のトランスポートのうちの適切な１つと通信するように、前記共通アプリケーションプログラムインタフェースを実現するためのコンピュータ実行可能命令をさらに備えることを特徴とするコンピュータプログラム製品。
【請求項３５】
第１のクライアントデバイスおよび第２のクライアントデバイスを含む複数のクライアントデバイスと通信する複数のサーバを含むネットワークにおいて、前記第１のクライアントデバイスと前記第２のクライアントデバイスとの間のセッション中の移行を容易にする方法であって、
少なくとも１つのサーバに記憶された状態情報を取り出すステップと、
セッションにおいて前記第１のクライアントデバイスとインタラクトして、前記状態情報を更新するステップと、
前記更新された情報を前記少なくとも１つのサーバに記憶するステップと、
前記セッションが前記第２のクライアントデバイスで継続されているときに、前記更新された状態情報を取り出すステップと、
前記継続されているセッションにおいて、前記更新された情報に基づいて前記第２のクライアントデバイスとインタラクトするステップとを備えることを特徴とする方法。
【請求項３６】
請求項３５に記載の方法であって、
前記セッションにおける前記第１のクライアントデバイスとのインタラクションに応答して前記状態情報が更新されることを許可する前に、前記第１のクライアントデバイスのユーザを認証するステップをさらに備えることを特徴とする方法。
【請求項３７】
請求項３６に記載の方法であって、
前記継続されているセッションにおいて前記第２のクライアントデバイスとインタラクトする前に、前記第２のクライアントデバイスのユーザが前記第１のクライアントデバイスのユーザと同じユーザであることを認証するステップをさらに備えることを特徴とする方法。
【請求項３８】
請求項３５に記載の方法であって、前記状態情報は、前記複数のサーバで認識されるスキーマに準拠したデータ構造を利用して、前記少なくとも１つのサーバに記憶され、前記状態情報の意味は、前記スキーマによって示唆されることを特徴とする方法。
【請求項３９】
請求項３８に記載の方法であって、前記データ構造が、エクステンシブルマークアップ言語（ＸＭＬ）に従って構造化されることを特徴とする方法。
【請求項４０】
請求項３５に記載の方法であって、前記少なくとも１つのサーバがサーバフェデレーションを構成することを特徴とする方法。
【請求項４１】
請求項３５に記載の方法であって、前記状態情報の少なくとも一部がユーザインタフェース情報を含み、セッションにおいて前記第１のクライアントデバイスとインタラクトするステップが、
前記第１のクライアントデバイスの第１のユーザインタフェース特性を判定するステップと、
前記第１のユーザインタフェース特性に合わせて特化された前記ユーザインタフェース情報の第１のセットを前記第１のクライアントデバイスに提供するステップとを備えることを特徴とする方法。
【請求項４２】
請求項４１に記載の方法であって、前記継続されているセッションにおいて前記第２のクライアントデバイスとインタラクトするステップが、
前記第２のクライアントデバイスの第２のユーザインタフェース特性を判定するステップと
前記第２のユーザインタフェース特性に合わせて特化された前記ユーザインタフェース情報の第２のセットを前記第２のクライアントデバイスに提供するステップとを備えることを特徴とする方法。
【請求項４３】
請求項４２に記載の方法であって、前記第１および第２のクライアントデバイスが同じユーザインタフェース機能を有し、前記第１および第２の状態情報のセットが実質的に同じユーザインタフェース情報を備え、それにより前記第１および第２のクライアントデバイスが同じ情報を表示することが可能になることを特徴とする方法。
【請求項４４】
請求項４２に記載の方法であって、前記第１および第２のクライアントデバイスが異なるユーザインタフェース機能を有し、前記第１および第２のユーザインタフェース情報のセットが異なることを特徴とする方法。
【請求項４５】
請求項４４に記載の方法であって、セッションにおいて第１のクライアントデバイスとインタラクトするステップが、
前記セッションにおいてパーソナルコンピュータとインタラクトするステップを備えることを特徴とする方法。
【請求項４６】
請求項４５に記載の方法であって、前記パーソナルコンピュータが第１のパーソナルコンピュータを備え、前記継続されているセッションにおいて前記第２のクライアントデバイスとインタラクトするステップが、
前記継続されているセッションにおいて第２のパーソナルコンピュータとインタラクトするステップを備えることを特徴とする方法。
【請求項４７】
請求項４５に記載の方法であって、前記継続されているセッションにおいて前記第２のクライアントデバイスとインタラクトするステップが、
前記継続されているセッションにおいて携帯電話とインタラクトするステップを備えることを特徴とする方法。
【請求項４８】
請求項４４に記載の方法であって、セッションにおいて前記第１のクライアントデバイスとインタラクトするステップが、
前記セッションにおいて携帯電話とインタラクトするステップを備えることを特徴とする方法。
【請求項４９】
請求項４８に記載の方法であって、前記携帯電話が第１の携帯電話を備え、前記継続されているセッションにおいて前記第２のクライアントデバイスとインタラクトするステップが、
前記継続されているセッションにおいて第２の携帯電話とインタラクトするステップを備えることを特徴とする方法。
【請求項５０】
請求項４８に記載の方法であって、前記継続されているセッションにおいて前記第２のクライアントデバイスとインタラクトするステップが、
前記継続されているセッションにおいてパーソナルコンピュータとインタラクトするステップを備えることを特徴とする方法。
【請求項５１】
請求項３５に記載の方法であって、
前記セッションにおける前記第１のクライアントデバイスとのインタラクションを少なくとも一時的に中止するステップであって、前記継続されているセッションにおける前記第２のクライアントデバイスとのインタラクションは、当該中止の後に行われるステップをさらに備えることを特徴とする方法。
【請求項５２】
請求項３５に記載の方法であって、少なくとも１つのサーバに記憶された状態情報を取り出すステップが、
前記少なくとも１つのサーバに記憶されたプレファランス情報を取り出すステップを備えることを特徴とする方法。
【請求項５３】
請求項３５に記載の方法であって、前記更新された情報を前記少なくとも１つのサーバに記憶するステップが、
前記セッションのセッションステータス情報を前記少なくとも１つのサーバに記憶するステップを備えることを特徴とする方法。
【請求項５４】
請求項３５に記載の方法であって、前記複数のサーバがサーバフェデレーションを構成し、前記状態情報を取り出すステップ、前記セッションにおいて前記第１のクライアントデバイスとインタラクトするステップ、前記更新された情報を記憶するステップ、前記更新された状態情報を取り出すステップ、および前記継続されているセッションにおいてインタラクトするステップが、前記サーバフェデレーションの２つ以上のサーバによって協調的に行われることを特徴とする方法。
【請求項５５】
第１のクライアントデバイスおよび第２のクライアントデバイスを含む複数のクライアントデバイスと通信する複数のサーバを含むネットワークで使用されるコンピュータプログラム製品であり、前記第１のクライアントデバイスと前記第２のクライアントデバイスとの間のセッション中の移行を容易にする方法を実現するためのコンピュータプログラム製品であって、当該コンピュータプログラム製品はコンピュータ可読媒体を備え、当該コンピュータ可読媒体は、
少なくとも１つのサーバに記憶された状態情報の受信を検出するためのコンピュータ実行可能命令と、
セッションにおいて前記第１のクライアントデバイスとのインタラクションが行われるようにするためのコンピュータ実行可能命令と、
前記セッションにおける前記第１のクライアントデバイスとのインタラクションに応答して、前記状態情報が更新されるようにするためのコンピュータ実行可能命令と、
前記更新された情報が前記少なくとも１つのサーバに記憶されるようにするためのコンピュータ実行可能命令と、
前記セッションが前記第２のクライアントデバイスで継続されているときに、前記更新された状態情報の受信を検出するためのコンピュータ実行可能命令と、
前記更新された状態情報に基づいて、前記継続されているセッションにおいて前記第２のクライアントデバイスとのインタラクションが行われるようにするためのコンピュータ実行可能命令とを記憶していることを特徴とするコンピュータプログラム製品。
【請求項５６】
請求項５５に記載のコンピュータプログラム製品であって、前記コンピュータ可読媒体が物理的な記憶媒体であることを特徴とするコンピュータプログラム製品。
【発明の詳細な説明】
【０００１】
（発明の背景）
（１．発明の分野）
本発明は、通信の分野に関する。より詳細には、本発明は、コンピュータネットワーク（インターネットなど）における改良された通信と連携を容易にする分散型コンピューティングサービスプラットフォームを説明する。
【０００２】
（２．技術の従来の状態）
インターネットは人々の通信方法に革命的な変化をもたらし、人類の歴史にしばしば「情報化時代」と呼ばれる新時代をもたらした。インターネットは、基本的に、世界中の多くの地域に普及したネットワーク化コンピュータの大規模な集合体を含む。高度なコンピュータ、ソフトウェア、およびネットワーキング技術により、エンドユーザの視点から見るとインターネットを通じた通信はかなり容易なものになった。
【０００３】
例えば、ユーザは、一般に普及した電子メールソフトウェアを用いて電子メール、すなわち「ｅメール」メッセージを作成することができる。ユーザは、受信者のアドレスを指定すると、単に例えばコンピュータディスプレイ上の「送信」アイコンをマウスで起動することによりそのメッセージを送信する。メッセージはインターネット上で１つのコンピュータシステムから次のコンピュータシステムへとルーティングされ、宛先のコンピューティングデバイスに到達する。
【０００４】
また、従来のブラウザソフトウェアにより、ユーザは遠隔のコンピュータにウェブページなどの情報を要求することができる。ユーザがウェブページのアドレスを入力すると、ブラウザはユーザのコンピュータに、例えばハイパーテキスト転送プロトコル（ＨＴＴＰ： ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）などの広く認識される通信プロトコルを用いてその要求を送信させる。要求はその後、宛先アドレスを用いて宛先のコンピュータ、すなわちウェブサイトまでルーティングされる。
【０００５】
遠隔のウェブサイトは要求を評価し、多くの場合は要求された情報を含む適切な応答を戻す。要求されるウェブページは、ハイパーテキストマークアップ言語（「ＨＴＭＬ」： ＨｙｐｅｒＴｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）など、ウェブブラウザが解釈できるフォーマットで戻される。そして解釈されたウェブページは、レンダリングされ、コンピュータディスプレイ上でユーザに提示される。
【０００６】
ウェブブラウザソフトウェアは、汎用パーソナルコンピュータ（ＰＣ）、テレビジョンのセットトップボックス、携帯情報端末、携帯電話など広く市販される多種のコンピュータで使用することができる。さらに、そのような従来のブラウザソフトウェアとインターネット接続を備えていれば誰でも公的に利用できる何百万ものウェブサイトがある。これらの要因があいまって、かつてないほど多くの人々がこれまでになく多くの情報にアクセスすることができるようになっている。
【０００７】
要約すると、インターネットは、多数のユーザに単純な地球規模の接続性をもたらしている。現在のインターネット使用は、情報へのアクセスを提供することにおいてビジネス面でも個人にも同様に多くの利点をもたらしているが、インターネットは、より柔軟性な方式で情報にアクセスし、その情報を使用するために現在よりも効率的に使用することができるはずである。例えばインターネットの主要な使用法の１つは、一般に「読み取り専用」と特徴づけることができる。パブリッシャがウェブページを作成しパブリッシュすると、インターネットは基本的にユーザがそのページの情報を読むことを可能にする提示ツールとして機能する。インターネット自体は、ユーザがウェブページを書く、編集する、あるいはその他の形でウェブページとインタラクト（ｉｎｔｅｒａｃｔ）するための機能はほとんど、あるいは全く提供しない。
【０００８】
また、インターネットは個人が何百万ものウェブサイトに直接アクセスすることを可能にしているが、ウェブサイト同士が通信する、あるいは情報を共有するのを可能にする規格はあるにしてもほとんど存在しない。各ウェブサイトは通例、異なるＩＤ、プレファランス（ｐｒｅｆｅｒｅｎｃｅ）、データ形式、およびスキーマ、接続性などを保持している。この理由により、多数のウェブサイトはおろか２つのウェブサイト間のインタラクション（ｉｎｔｅｒａｃｔｉｏｎ）を可能にするにも著しい時間と費用がかかりうる。したがって、ウェブサイトは通例、インターネット上の他のウェブサイトから提供される膨大で広範囲の情報を取り込まない。多くのウェブサイトは、その情報が他のウェブサイトからすでに入手することができるにも関わらず、独自に情報を収集し、それを編集してやや静的な形態にすることを余儀なくされている。このため、膨大な数のサイト間とコンピュータ間にはインターネットを介した広範な接続性があるにも関わらず、自動化されたインタラクションの形でその接続性を活用するための策はほとんどなされておらず、可能にすることができるはずの革命的な進歩も大半は実現されていない。
【０００９】
インターネットの効率性と柔軟性は、情報やサービスへのユーザアクセスを制約する他の要因によっても制限されている。例えば、パーソナルコンピュータを所有するユーザは、例えば基礎となるプラットフォームに関連する制約のために、携帯電話のユーザよりもはるかに多いインターネット資源のセットにアクセスすることができる。プラットフォームの制約が問題ではない場合には、他の問題（セキュリティやストレージ）により、１人のユーザによる複数のプラットフォームにわたるインターネット資源へのアクセスがなお制限され、複数のユーザであればなおさら制限される可能性がある。同じ情報とサービスにアクセスできる場合であっても、その資源にアクセスするのに例えばユーザが大きく異なるユーザインタフェースとネゴシエートしなければならない場合、あるいは異なるプロトコルに従わなければならない場合には、全体的な効率性と柔軟性が低下する。
【００１０】
さらに、インターネットユーザはしばしば、より分けて組織化するのが容易でない過剰な情報に直面することがある。例えば、ウェブ検索エンジンが単純な問合せに対して何千もの可能な「ヒット」を戻すのはよくあることである。ユーザは手動でそれらのヒットをより分けて適切な情報を見つけなければならない。またユーザの電子メールの受信箱がしばしば、ユーザにとって関係がないか、あるいは優先度の低いジャンク電子メールや「スパム」で攻撃されることがある。受信箱フィルタはいくつか存在するが、ユーザはやはり優先度の高いメッセージや重要なメッセージを見つけるために残りのメッセージに目を通さなければならない。
【００１１】
したがって、インターネットを通じたより多大でより一貫性のあるユーザインタラクションおよび連携と、ウェブサイト間の通信を容易にするシステムおよび方法が必要とされる。また、過剰な情報でユーザを当惑させることなく、より個人化された関連性のある情報をユーザに提供することも必要とされる。
【００１２】
（発明の概要）
上述の従来技術における諸問題は本発明によって克服される。本発明は、より多大なインターネットを利用した連携と、より多くのウェブサイト間の通信を容易にする分散型コンピューティングサービスプラットフォームである。まずこのプラットフォームの概略的な概念アーキテクチャを要約して説明する。次いで、このプラットフォームの統合された技術コンポーネントについて要約して述べる。このコンポーネントには、プログラミングモデル、スキーマ、ユーザインタフェース、イベント、メッセージング、ストレージ、ディレクトリ、セキュリティ、およびコード管理が含まれる。最後に、職場や家庭における人々の日常生活で、改良された連携と通信が本発明によってどのように容易になるかを表すシナリオを記載する。
【００１３】
本発明の分散型コンピューティングサービスプラットフォームは、クライアントデバイスとサーバフェデレーション間、およびサーバフェデレーション内のサーバ間の通信を容易にする。サーバフェデレーションは、例えば、インターネットおよび／または企業イントラネット上のサーバとサービスからなる。クライアントとサーバは、ある程度の自律性を保持しながら、有意味の通信と情報交換を通じて統合される。有意味の交換は、トランスポートに依存しないメッセージングインフラストラクチャを介し、共通のスキーマを通じて情報を交換することによって可能になる。
【００１４】
プラットフォームは、分散しながらも統合された複数の技術コンポーネントとサービスを含み、これらにはプログラミングモデル、スキーマ、ユーザインタフェース、イベント、メッセージング、ストレージ、ディレクトリ、セキュリティ、およびコード管理が含まれる。プログラミングモデルは、クライアントとサーバフェデレーション間に柔軟に分散することのできるアプリケーションの構造を定義する。このプログラミングモデルに準拠するアプリケーションは、ページコンポーネント、エミッサリ（ｅｍｉｓｓａｒｙ）コンポーネント、およびフィーフダム（ｆｉｅｆｄｏｍ）コンポーネントを含む。ページコンポーネントは、サーバフェデレーションと通信する特定のクライアントデバイスのユーザインタフェースをプロジェクト（ｐｒｏｊｅｃｔ）するのに通例使用されるコントロールをホスト（ｈｏｓｔ）する。エミッサリコンポーネントは、一般に、サーバフェデレーションに対してクライアントを表す。フィーフダムコンポーネントは、アプリケーションの主要な資源を構成するデータを所有する。一般にこれらのコンポーネントは、非同期メッセージングを通じて互いに通信する。このメッセージは、コンポーネントにとって内部のロジックによって、コンポーネントの内部で生成されるイベントによって、または他のコンポーネントから受信したメッセージに応答して生成することができる。
【００１５】
プラットフォームはスキーマに依存して通信を有意味にする。スキーマは、特定タイプのデータをどのように構造化するかを定義する規則または規格のセットである。したがって、フェデレーションのコンピュータシステムはスキーマを使用して、特定の構造に準拠するデータが、そのフェデレーションで用いられる特定のタイプの項目を表すことを認識する。したがって、コンピュータシステム間で単にデータ自体だけでなくデータの意味を通信することができる。例えば、あるコンピュータデバイスは、特定のアドレススキーマに準拠するデータ構造がアドレスを表すと認識することができ、そのコンピュータがアドレスのコンポーネント部分を「理解する」ことを可能にする。コンピュータデバイスはその後、そのデータ構造がアドレスを表すという理解に基づいてインテリジェントな動作を行うことができる。この動作には、例えば、アドレスを用いて行うことのできる事柄を表す動作メニューをユーザに提示することが挙げられる。スキーマは、ローカルにデバイス上に記憶するか、かつ／またはグローバルにフェデレーションの「メガストア」に記憶することができる。デバイスは、スキーマが更新されるとそのデバイスに自動的にメッセージを送るイベント通知サービス（この場合はスキーマ更新サービス）をサブスクライブすることにより、ローカルに記憶されたスキーマを最新の状態に保つことができる。グローバルに記憶されたスキーマへのアクセスは、セキュリティインフラストラクチャによって制御される。
【００１６】
デバイスとユーザのインタラクションは主にユーザインタフェースを通じて行われる。本発明のユーザインタフェース（ＵＩ）は、マルチモーダル、インテリジェントで、応答型である。このユーザインタフェースは、様々なクライアントおよびサーバデバイスの技術的能力に合わせて適切にスケーリングする。このユーザインタフェースはまた、複数デバイスにわたるユーザの状態、セッション、および設定ステータスを記憶する。したがって、ユーザは、セッション中にすべての状態とプレファランスの情報の整合性を保ったままあるデバイスから別のデバイスに切り替えることができ、あるいは、複数のユーザが同じデバイスを共用し、それぞれのユーザに各自のプレファランスに基づく異なるインタフェースを提示することができる。ユーザは、セキュリティインフラストラクチャを介して適切に認証を行うと、スキーマによって指定されるユーザ固有の情報（お気に入りや連絡先など）を記憶するディレクトリサービスを通じてユーザのプレファランス情報にアクセスすることができる。このユーザインタフェースはマルチモーダルでもあり、ユーザは複数のモードでＵＩとインタラクトすることができる。例えば、ユーザ入力は、キーボード入力やマウスのクリックなど「伝統的な」方式で行うことができる。ＵＩはまた、マイクロフォンを備えるデバイスへのオーディオ／音声入力や、タッチスクリーンやパッドを備えるデバイスへのスタイラス／タッチ入力など、他の入力方式も可能にする。
【００１７】
プラットフォーム内のイベントは、特定のアクティビティについての通知を同期、報告、あるいは提供するために使用される。プラットフォームのイベントコンポーネントは、フェデレーション全体のイベントシンクに通信されるイベントを生成するイベントソースを含んでいる。このシステムは、アトミックイベントを変換して漸進的にレベルが高くなるイベントにするイベントコンポジション機構を含み、さらには入力イベントについての論理的または確率的な推論により、入力イベントをより高いレベルのイベントに変換する推論機械をも含む。イベントコンポジション機構は、利用可能なアトミックイベントのセットを適合して観察（ｏｂｓｅｒｖａｔｉｏｎ）にし、それをソフトウェアコンポーネントの情報的要件と適切にマッチさせて、適切な判断が行われるように適正レベルで抽象化した情報をコンポーネントに提供する。ソフトウェアコンポーネントはいくつかの機構を介してイベントにアクセスすることができ、この機構には、（１）１以上のイベントソースから提供される特定クラスのイベントをソフトウェアコンポーネントがサブスクライブする、（２）１以上のソースを時折ポーリングする、（３）イベントソースによるより広いイベントのブロードキャストをリッスンする、がある。これらのイベントへのアクセス方法のいずれでも、イベントにはメッセージングインフラストラクチャを介してアプリケーションからアクセスすることができるが、メッセージ転送のタイプはイベントのタイプに依存する可能性がある。例えば、イベントを様々な待ち時間の許容範囲と関連付けて、送信の遅れに伴うコストによってイベントの通信を誘導することができる。この理由により、基幹サーバがダウンしたというイベント通知には、その宛先にただちに配信する保証が必要となる。ユーザの概略的な位置の更新など他のイベントは、それより低い遅延コストと関連付けることができる。また、ユーザインタフェースは、ユーザに、その通知の緊急性に比例する方式で特定のイベントを通知することができる。例えば、ネットワーク管理者は、サーバがダウンしたことを知らせる緊急のポップアップメッセージを受け取り、十代の若者はインスタントメッセンジャーやチャットインタフェースを通じて自分の友達がエリア内にいるという通知を受信することができる。イベント通知は、認証と承認のセキュリティ機構によっても制御される。
【００１８】
メッセージングコンポーネント１６０は、イベントやその他の情報をプラットフォーム内で交換するための機構である。メッセージングサービスは、ＨＴＴＰを含む各種のトランスポートを用い、インターネットを通じて効率的かつ信頼できるメッセージングを提供する。メッセージングインフラストラクチャは、アプリケーション開発者が、メッセージングサービスのアーキテクチャ全体と本発明に関連するその他の機能を活用するアプリケーションを書くための標準インタフェースを確立する。メッセージングは非同期に行うことができ、これによりユーザ側で開始するページの更新を必要とせずに常にページを更新することが可能になる。
【００１９】
ストレージサービスは、サーバフェデレーション中にストレージを分散することを可能にする。上述のように、ユーザプレファランスとファイルをフェデレーションの「メガストア」に記憶することができ、ユーザは、適切な認証を行うと任意のデバイスを用いて任意の位置からその情報にアクセスすることができる。「メガストア」は必ずしもすべてが単一のサーバにある必要はなく、ストレージは、効率性、メモリアロケーション、アクセス頻度などに応じてフェデレーション内のサーバに分散することができる。サーバフェデレーションに記憶された情報はローカルに複製することもでき、ユーザはオフラインで作業することができる。ユーザが再びオンラインに戻ると、オフライン時のデータとオンライン時のデータの自動的な同期をトリガするイベントが生成される。ストレージサービスは、従来のファイルシステムに基づいて構築されるデータエンジンを含む。ローカルにキャッシュする情報に優先度をつけ、状況の変化および／またはキャッシュされた情報の古さに基づいてキャッシュされた情報を削除できるようにする方法を用いることにより、キャッシュされた情報の価値を最大に保つことができる。
【００２０】
各種のサービスにユーザが知られ、容易に識別されるという概念をサポートするためにディレクトリコンポーネントが提供される。本発明のディレクトリサービスは、企業単位またはウェブサイト単位のメタディレクトリを備え、メタディレクトリ間を同期することによってフェデレーションを支援する。この同期は、ディレクトリ間の通信に使用する規格化されたスキーマによって容易になる。このメタディレクトリは、より詳細な情報を得ることのできる固有の適合ディレクトリへの参照を提供する。ディレクトリは、例えばユーザのアイデンティティ（ｉｄｅｎｔｉｔｙ）情報（名前、アドレスなど）、セキュリティ情報（そのユーザがアクセスを許可されている情報）などを含むことができる。
【００２１】
本発明のセキュリティインフラストラクチャは、サーバフェデレーション間に改良されたセキュリティを提供する。ユーザの可動性とプライバシーを保証するために、セキュリティインフラストラクチャは複数のアイデンティティを有する単一の個人を規定する。例えば、１人の個人が仕事上のアイデンティティと私的なアイデンティティを有することが可能である。本発明は、こうした複数のエンティティを単一のエンティティとして扱う認証と承認を容易にする。さらに、個人ファイアウォール、周辺ファイアウォール、およびセキュリティゲートウェイが互いに無関係に動作する改良されたファイアウォール技術を記載する。セキュリティは、パスワード、スマートカード、バイオメトリクス（指紋、網膜スキャンなど）、鍵の交換、暗号化などの技術の任意の組合せによって実装することができる。
【００２２】
プラットフォームの目的の１つは、ユーザが最も更新されるアプリケーションとそのアプリケーションに必要なコードへのアクセスを透過に有することを保証することである。本発明のコード管理システムは、アプリケーションとその構成コンポーネントのコード、リソース、エントリーポイント、構成情報を含むアプリケーションの構造を記述するマニフェスト（ｍａｎｉｆｅｓｔ）を含む。コード管理システムにより、プログラミングモデルに準拠するアプリケーションを効率的な方式でフェデレーション内に配置し、更新することが可能になる。
【００２３】
本発明のこの他の機能と利点は、以下の説明で明らかにし、部分的には以下の説明から明らかになり、あるいは本発明を実施することによって知ることができる。本発明の機能と利点は、頭記の特許請求の範囲に具体的に示す機器と組合せを用いて実現し、得ることができる。本発明の上記の機能およびその他の機能は、以下の説明と頭記の特許請求の範囲からより完全に明らかになり、あるいは以下に述べるように本発明を実施することによって知ることができよう。
【００２４】
本発明の上述およびその他の利点と機能を得る方式について、上記で簡単に説明した本発明のより詳細な説明を、添付の図面に図示するその特定の実施形態を参照して提供する。この図面は本発明の典型的な実施形態のみを示し、したがって本発明の範囲を制限するものとみなすべきではないことを理解した上で、添付の図面を用いて本発明についてより具体的かつ詳細に記載し、説明する。
【００２５】
（発明の詳細な説明）
（Ａ．序論）
本発明は、より多大なインターネットを利用した連携とウェブサイト間の通信を容易にする分散型ネットワークサービスプラットフォームを含む、方法、システム、およびコンピュータプログラム製品に関する。本発明の各種のアーキテクチャコンポーネントは、下記でさらに詳しく述べるように、パーソナルコンピュータ、サーバ、ラップトップ、携帯型デバイス、携帯電話など各種のハードウェアコンポーネントを含む各種の特殊目的または汎用のコンピューティングデバイスに分散することができる。
【００２６】
本発明の範囲に含まれる実施形態は、記憶されたコンピュータ実行可能命令またはデータ構造を担持する、あるいは有するコンピュータ可読媒体も含む。このコンピュータ可読媒体は、汎用または特殊目的のコンピューティングデバイスからアクセスすることができる任意の入手可能な媒体でよい。例えばそのようなコンピュータ可読媒体は、これらに限定しないが、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭ、あるいはその他の光ディスクストレージ、磁気ディスクストレージまたはその他の磁気ディスク記憶装置などの物理的な記憶媒体か、あるいはコンピュータ実行可能命令またはデータ構造の形で所望のプログラムコード手段を担持または記憶するのに使用でき、かつ汎用または特殊目的のコンピューティングデバイスからアクセスすることのできる任意の他の媒体でよい。ネットワークまたはその他の通信接続（配線、無線、または配線と無線の組合せ）を通じて情報をコンピューティングデバイスに転送または提供する場合、コンピューティングデバイスはその接続を適切にコンピュータ可読媒体とみなす。したがって、そのような接続はいずれも適切にコンピュータ可読媒体と呼ぶ。上記の組合せもコンピュータ可読媒体の範囲に含めるべきである。コンピュータ実行可能命令は、例えば、任意の汎用または特殊目的のコンピューティングデバイスに特定機能または複数機能のグループを実行させる命令およびデータを含む。
【００２７】
この説明では、まず、実施が可能な本発明の全般的なアーキテクチャを「アーキテクチャ」の項で説明する。次いで、そのアーキテクチャのいくつかの技術コンポーネントをそれぞれ説明する項を続ける。この項には、「プログラミングモデル」、「スキーマ」、「ユーザインタフェース」、「イベント」、「メッセージング」、「ストレージ」、「ディレクトリ」、「セキュリティ」、および「コード管理」が含まれる。最後に「シナリオ」の項に、このアーキテクチャと技術がどのように改良されたインターネット通信と連携を容易にするのかを実例を挙げて説明する各種のシナリオを記載する。
【００２８】
（Ｂ．アーキテクチャ）
図１は、本発明を実施することが可能な動作環境１００の概略図である。クライアントデバイス１１０は、各種の幅広い処理能力と記憶能力を有する。クライアントデバイス１１０には、例えば、デスクトップ型のパーソナルコンピュータ（ＰＣ）など高度のデータ処理を実行することができる「リッチ」クライアント（例えばリッチクライアント１１２）と、携帯電話やページャなどデータ処理能力が低い「シン（ｔｈｉｎ）クライアント」１１４がある。リッチクライアントとシンクライアントの間の差異は一定範囲のスペクトルと考えられる。すなわち、例えばそのスペクトルの中間に位置する数多くのデバイス（ハンドヘルドＰＣやタブレットＰＣ）がある。
【００２９】
デバイスのタイプやクライアントの処理能力に関係なく、大半のクライアントデバイスは、オンライン状態およびオフライン状態のどちらでもユーザによって操作することができる。オンライン時には、各クライアントデバイスは、本発明の分散コンピューティングサービスプラットフォーム１１５を介してサーバフェデレーション１２０と通信することができる。概念上サーバフェデレーション１２０は、例えば、企業イントラネット１３０など１以上の私的なコンピュータネットワークと、一般に「インターネット」１２５と称される世界規模のコンピュータシステムネットワークを含む。フェデレーション内のサーバ（すなわちインターネット１２５のサーバ１４０ａ、１４０ｂと、企業イントラネット１３０内のサーバ１４０ｃ、１４０ｄ）も、プラットフォーム１１５を介して相互に通信する。
【００３０】
概念上、プラットフォーム１１５は、技術とサービスを備えるいくつかのプラットフォームコンポーネントを含み、これには、プログラミングモデルコンポーネント１３５、ユーザインタフェースコンポーネント１４０、ストレージコンポーネント１４５、ディレクトリコンポーネント１５０、イベントコンポーネント１５５、メッセージングコンポーネント１６０、セキュリティコンポーネント１６５、スキーマコンポーネント１７０、およびコード管理コンポーネント１７５が含まれる。図１では概念上別個に示しているが、プラットフォームコンポーネント１３５、１４０、１４５、１５０、１５５、１６０、１６５、１７０、および１７５はそれぞれ、サーバフェデレーション１２０とクライアントデバイス１１０に分散させてよいことを理解されたい。さらに、プラットフォームコンポーネントの多くは、クライアントデバイス１１０とサーバフェデレーション１２０にサービスを提供する。各プラットフォームコンポーネントは、矢印１８０で示すように他のプラットフォームコンポーネントと疎結合されており、プラットフォーム１１５が統合された技術とサービスを提供することが可能になる。プラットフォームコンポーネントによる支援サービスおよび統合と併せて、プラットフォーム１１５が分散している性質が、本発明の高度の機能と利点に寄与し、それを容易にしている。
【００３１】
クライアント１１０とサーバフェデレーション１２０のサーバ１４０は、ある程度の自律性を保持しながら、下記でより詳細に述べるスキーマプラットフォームコンポーネント１７０とメッセージングプラットフォームコンポーネント１６０によって提供される、トランスポートに依存しないメッセージングインフラストラクチャにわたる共通スキーマを使用した有意味の通信と情報の交換を通じて統合される。双方向の矢印１９０は、サーバとクライアント間で行われるこの通信を表す。双方向の通信により、クライアントデバイス１１０は、サーバフェデレーション１２０から読み出し、フェデレーションに書き込み、またその他の形でインタラクションをすることができる。本発明は、スキーマに従ってデータを双方向に通信することが可能な任意の通信機構を使用して実施することができる。一例では、名前／値の対の通信が可能なエクステンシブルマークアップ言語（「ＸＭＬ」：ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）を介して通信を行う。
【００３２】
いくつかの例では、クライアントデバイス１１０とサーバフェデレーション１２０間の通信は、単方向すなわち「読み取り専用」であってもよい。この単方向通信は、今日のインターネットで主流の通信形態である。この種の「読み取り専用」の通信では、パブリッシャがウェブページを作成してパブリッシュした後、インターネットは基本的に、ユーザがそのページ上の情報を読むことを可能にする提示ツールの役割を果たす。この提示を可能にする技術には、無線デバイスへの通信を可能にする無線アプリケーションプロトコル（「ＷＡＰ」）がある。また、ハイパーテキストマークアップ言語（「ＨＴＭＬ」）と呼ばれるウェブページ形式は、ネットワークサイトから情報をダウンロードすることを可能にする。情報はその後解釈され、レンダリングされて、クライアントのディスプレイに提示される。ただし、本発明のプラットフォーム１１５は従来のウェブ提示モデルを拡張して、リッチで、インタラクション型の双方向通信を可能にする。
【００３３】
プラットフォーム１１５は、フェデレーション１２０中のサーバ１４０が協調して情報を共有し、かつ／または諸機能を行うことを可能にする。各サーバが独自に情報を収集し編集しなければならないのではなく、これらサーバは情報を容易に入手できるさらに別のサーバのサービスに依存して、仕事の効率的な分割を実施することができる。そしてユーザには豊富な情報が与えられ、ユーザは、その豊富な情報を生成するためにサーバフェデレーションで行われた複雑なサーバ間通信を気にかけずに済む。例えば、サーバフェデレーション１２０中のサーバ１４０は、あるサーバ中の株価をクライアントデバイス１１０のユーザインタフェースの一部に表示し、別のサーバのニュース記事をクライアントデバイスのユーザインタフェースの別の部分に表示し、さらに別のサーバからのインスタントメッセージをクライアントデバイスのユーザインタフェースの別の部分に表示することを可能にする情報を交換することができる。
【００３４】
サーバフェデレーション１２０中のサーバ１４０は、スキーマプラットフォームコンポーネント１７０から提供される規格化されたデータ構造あるいはスキーマを用いて通信し、その他の方法で情報を共有する。スキーマにより、単にサーバ間で情報を交換するのではなく、サーバとアプリケーション間でより意味を持つインタラクションを行うことが可能になる。この意味の認識により、サーバは認識された情報の意味に基づいて諸機能を実行することができる。アプリケーションが、ある情報が例えば所与のエンティティの住所を意味すると認識した場合、アプリケーションはその認識された意味に基づいて特定の機能を行うことができる。例えば、アプリケーションは、その所与のエンティティに対応するテンプレートの住所フィールドに住所情報を自動的に記入することができる。アプリケーションはまた、住所に郵便番号や州がないことを検出して、欠けている情報を自動的に他のサーバに照会し、ユーザを介在させずにすべての住所フィールドに自動的に記入することもできる。このように、各サーバがデータと関連付けられた意味を認識し、人間の介在を必要とせずにその情報に基づいて行動することができる点でインテリジェントであるために、サーバ間の連携がさらに生産的なものになる。
【００３５】
（Ｃ．プログラミングモデル）
図２は、プラットフォーム１１５の多層プログラミングモデルコンポーネント１３５を表す。このプログラミングモデルは、図１のクライアントデバイス１１０とサーバフェデレーション１２０にアプリケーション２００を異なる程度に分散する仕組みを示している。「アプリケーション」は、ある機能を実行するソフトウェア本体と定義され、ウェブサイトを含むことができる。分散されたアプリケーションの場合、アプリケーションのあるコンポーネントはクライアントデバイスに記憶することができ、他のコンポーネントはウェブサイトの一部になる。一般に、アプリケーション２００は、ページコンポーネント２１０、エミッサリコンポーネント２２０、およびフィーフダムコンポーネント２３０を含む複数のアプリケーションコンポーネントからなる。ページコンポーネント２１０は、ユーザインタフェースまたは体験を適切なクライアントデバイス１１０にプロジェクトするコントロールをホストする。エミッサリコンポーネント２２０は、一般的に、サーバフェデレーションに対してクライアントを表し、したがってクライアントとサーバフェデレーション間のエミッサリ（使者）として機能する。フィーフダムコンポーネント２３０は、アプリケーション２００の重要なリソースを構成するライブデータを最も直接的に制御する。単一のアプリケーションに、異なる数のこれらコンポーネント（例えば複数のページコンポーネント）があってよい。また、アプリケーションによってはすべてのコンポーネントを備えなくともよい。
【００３６】
クライアントの能力に応じて、ページコンポーネントとエミッサリコンポーネントは、クライアントでもサーバフェデレーションでも実行することができる。処理能力をほとんど持たないか全く持たないシンクライアントでは、ページコンポーネントとエミッサリコンポーネントは、サーバフェデレーションで実行される可能性が高い。デスクトップ型パーソナルコンピュータ（ＰＣ）など処理能力がより高いリッチクライアントでは、ページコンポーネントとエミッサリコンポーネントはクライアントで実行される可能性が高い。
【００３７】
これらページ、エミッサリ、フィーフダムのアプリケーションコンポーネントは、それぞれ、メッセージングコンポーネント１６０を介してあるコンポーネントから別のコンポーネントに非同期メッセージを送受信する際に使用されるロジック本体２４０（すなわちコンピュータ実行可能命令）を含んでいる。例えば、ページレベルのロジック２４０ａは、ページコンポーネント２１０からメッセージングキュー２５０ａを通じてエミッサリコンポーネント２２０に非同期にメッセージを送信するのに使用される。エミッサリレベルのロジック２４０ｂは、エミッサリコンポーネント２２０からメッセージングキュー２５０ｂを通じてページコンポーネント２１０に非同期にメッセージを送信するのに使用される。エミッサリレベルのロジック２４０ｂも、エミッサリコンポーネント２２０からメッセージングキュー２５０ｃを通じてフィーフダムコンポーネント２３０に非同期にメッセージを送信するのに使用される。フィーフダムレベルのロジック２４０ｃは、フィーフダムコンポーネント２３０からメッセージングキュー２５０ｄを通じてエミッサリコンポーネント２２０に非同期にメッセージを送信するのに使用される。このように、アプリケーション２００のページコンポーネント、エミッサリコンポーネント、およびフィーフダムコンポーネント間で非同期の情報交換が行われる。メッセージキューは、メッセージングコンポーネント１６０に従い、コンポーネント間でメッセージを送信するための信頼できる経路を提供し、各種の伝送セマンティックス（すなわち、保証された確実に１回の配信、トランザクション配信、および保証なしの配信）をサポートする。メッセージはスキーマ（例えばＸＭＬスキーマ）を介して定義される。
【００３８】
各アプリケーションコンポーネント内のロジック本体２４０は、コントロール２６０のホストにも使用される。一般に、コントロールは、プログラムコンポーネントの機能からアクセスすることができ、その一部をなしうる機能を表す。例えば、ページレベルロジック２４０ａはコントロール２６０ａをホストし、エミッサリレベルロジック２４０ｂはコントロール２６０ｂをホストし、フィーフダムレベルロジック２４０ｃはコントロール２６０ｃをホストする。各コントロール２６０は、呼び出し可能メソッド、同期の読み出しまたは書き込みが可能なプロパティ、および非同期に発生してページコンポーネント、エミッサリコンポーネント、および／またはフィーフダムコンポーネント中のロジックを実行させることのできるイベントを公開する。一般に、このコントロールによってトリガされるイベントは、オブジェクトのメソッド呼び出しなど低レベルのイベントである。したがって、コンポーネントがメッセージを受け取ると、そのメッセージがイベントを生成して、そのコンポーネント中のコードを実行させる。
【００３９】
ページコンポーネント２１０は、ページレベルロジック２４０ａを使用して、コントロール２６０ａを直接かつ同期に操作してユーザインタフェースまたは体験をプロジェクトする。ページコンポーネントは、クライアントのユーザインタフェース能力に応じて、呼び出しを、そのクライアントと互換性のある特定バージョンのページに密かにリダイレクトすることができる。例えば、あるページはリッチクライアントに適しており、別のページは電話機やその他同様のデバイスなどのシンクライアントで使用するのに適している場合がある。ページコンポーネント２１０は、クライアントのユニフォームリソースロケータすなわちＵＲＬを使用することによりクライアントのアイデンティティを認識し、従って適切なバージョンのページにリダイレクトすることができる。ただし、ユーザインタフェースは、そのページバージョンに関係なく幅広いクライアントデバイスにわたって同じ表示を保つが、下記でユーザインタフェースコンポーネント１４０との関連で説明するように、よりリッチなバージョンのページではいくつかの機能が存在するか、あるいはより完全に展開（ｄｅｖｅｌｏｐ）されることがある。
【００４０】
ページコンポーネントは、クライアントで利用できるユーザインタフェースに関係なく、そのページコンポーネントを実装しようとするデバイスの処理能力に応じて様々に異なるページバージョンを起動することもできる。例えば、高い処理能力を有するクライアントパーソナルコンピュータまたはサーバでページコンポーネントを実装する場合、ページコンポーネントは、そのページとの広範なユーザインタラクションを可能にするリッチなコントロールページにリダイレクトすることができる。一方、堅牢性が低いシンクライアントでページコンポーネントを実装する場合、ページコンポーネントは、通例はユーザとページとのインタラクションを可能にするコントロール機能があるにしてもほとんど含んでいないＨＴＭＬのみのバージョンのページにリダイレクトすることができる。
【００４１】
エミッサリコンポーネント２２０は、同期してコントロール２６０ｂとインタラクトすることができるロジック本体２４０ｂをカプセル化している。ロジック２４０ｂは、クライアントデバイスのタイプに関係なく、クライアントをサーバに対して規格化された方式で抽象的に表すようにも設計される。エミッサリコンポーネントは、フィーフダムコンポーネントによってパブリッシュされる読み取り専用データにアクセスすることができ、そのデータを複製データストレージ２７１に記憶する。エミッサリコンポーネントは、ユーザ単位Ｒ／Ｗデータストレージ２７２に記憶されるショッピングカートデータなどのユーザ単位の読み取り／書き込み（Ｒ／Ｗ）データも含む。ロジック本体２４０ｂは、メッセージキュー２５０ａまたは２５０ｄからの受信メッセージに応答して実行することができる。
【００４２】
フィーフダムコンポーネント２３０は、ライブデータストレージ２８０に記憶されるライブデータを論理的に「所有」するロジック本体２４０ｃをカプセル化している。ロジック本体２４０ｃは、フィーフダムコンポーネントと関連付けられたエミッサリコンポーネント２２０などのエミッサリコンポーネントから受信するメッセージに応答して実行される。フィーフダムコンポーネント２３０は、サービスへのアクセスを要求するどのエミッサリコンポーネントにもセキュリティサービスを実行する。
【００４３】
アプリケーション中の各コンポーネントは、明示的なユーザとセッションの状態に関する状態情報を保持する。したがって、各コンポーネントは、そのようなユーザとセッションの状態情報の複製に用いられるオブジェクトをサポートする。この状態情報は、そうした状態情報の通信をサポートする非同期メッセージングによりアプリケーション中の他のコンポーネントと共有することができる。したがって、各コンポーネントに、セッション中のどの時点においてもユーザインタフェースの状態を認識させることができる。さらに、各コンポーネントにユーザのプレファランスを認識させることができる。
【００４４】
次いでプログラミングモデルコンポーネント１３５の利点について述べる。アプリケーション中のコンポーネントは非同期メッセージングが可能である。このため、コンポーネントはメッセージを受信するために明示的に情報を要求する必要がない。また、コンポーネントは、そのような情報を含むメッセージを送信するのに明示的な情報の要求を受信する必要もない。したがって、プログラミングモデルは、ユーザが明示的にウェブサイトを更新する必要なしに、ページコンポーネントへのメッセージ送信（およびしたがってユーザインタフェースの更新）をサポートする。したがって、ページは、ページコンポーネントがエミッサリコンポーネントからメッセージを受け取ると自動的にページが更新される非同期のユーザインタフェースを表すことができる。またこのような状況では、フィーフダムを通じてライブデータを入手することができるので、エミッサリは複製データにアクセスする必要がない。
【００４５】
さらに、プログラミングモデルは、定義されたイベントが生じると非同期に発生してコンポーネント中のロジックを実行させるコントロールを含む。このロジックは、イベントに応答して他のコンポーネントに非同期メッセージを送信するので、アプリケーション中のどのコンポーネントも定義されたイベントに応答して実行することができる。したがって、このアプリケーションは高度にイベント駆動型である。これらのイベントは、アプリケーションの任意のコンポーネント中でメソッドを非同期に実行させることができる。
【００４６】
例えば、フィーフダムコンポーネントは、事前定義された単語を含む新しい記事がデータベースに追加されると発生するように構成されたコントロールをホストすることができる。イベントがトリガされると、フィーフダムは、エミッサリコンポーネントを通じて非同期メッセージをページコンポーネントに送信する。ページコンポーネントは、この非同期メッセージに応答して、クライアントで提示する通信メッセージをレンダリングし、それによりユーザに新しい記事を知らせる。例えば、クライアントデバイスがシンクライアントである場合、ユーザインタフェースは、そのような新しい記事の存在を知らせる小さな通知ウィンドウを含むことができる。クライアントデバイスがリッチクライアントである場合、ユーザインタフェースは、画面上に新しい記事を完全に表示することができる。ページコンポーネント、エミッサリコンポーネント、またはフィーフダムコンポーネントのいずれあるいはすべては、事前定義された単語を含む記事に関心を持つ関係者にその記事を転送する電子メールを作成するなど、同じイベントに基づいて他の動作を行うこともできる。このように、プログラミングモデルは、複雑なイベント駆動型のアプリケーションを可能にする。
【００４７】
プログラミングモデルはまた、クライアントとサーバフェデレーション間にこれらコンポーネントを柔軟に配置するのを容易にし、アプリケーションのオフラインでの使用とオンラインでの使用を可能にする。例えば、アプリケーションは、オフラインおよびオンラインのどちらでも実行できるように構築することができる。これは、ページコンポーネントを直接クライアントでホストできるようにし、そのページコンポーネントが、同じくそのクライアントでホストされるエミッサリコンポーネントと直接通信することにより行うことができる。オフライン時には、アプリケーションは、ライブデータストレージ２８０のライブデータではなく、複製データストレージ２７１の複製データにアクセスする。オンラインになるとアクセスが復旧し、エミッサリコンポーネントがキューにある更新をフィーフダムに送信すると、複製データが更新されて、フィーフダムコンポーネントが管理するライブデータの現在の状態を反映する。
【００４８】
アプリケーションは、ページコンポーネント、エミッサリコンポーネント、およびフィーフダムコンポーネントをすべてサーバフェデレーションでホストするように構築してもよい。この場合、クライアントは、ページコンポーネント、エミッサリコンポーネント、および／またはフィーフダムコンポーネントのサービスにアクセスするために、サーバフェデレーションとオンラインの状態になければならない。
【００４９】
さらに、アプリケーションの一部はオフライン時に利用できるようにし（以下「オフライン部分」）、アプリケーションのその他の部分はそのクライアントがオンライン状態にある時にのみ利用できる（以下「オンライン部分」）ようにすることが可能である。アプリケーションのオフラインコンポーネントを可能にするページコンポーネントとエミッサリコンポーネントはクライアントでホストされ、一方、アプリケーションのオンライン部分を可能にするページコンポーネントとエミッサリコンポーネントはサーバフェデレーションでホストされる。
【００５０】
このように、本発明の分散コンピューティング１１５サービスプラットフォームのその他の技術コンポーネントの多くは、プログラミングモデルコンポーネント１３５に従って実装することができる。
【００５１】
（Ｄ．スキーマ）
より多大なインターネットを利用した連携とウェブサイト間の通信を可能にする一方法は、より有意味のデータ通信を利用するものである。この有意味あるいはインテリジェントな通信は単なるデータ以上のものを提供するだけでなく、どのようなデータを、かつ／またはなぜそのデータを通信するのかについての推論も提供する。これは、標準的なデータ構造、プロトコル、通信トランスポート、およびその他のデータ交換によるなど、標準的な方式または「スキーマ」でデータを構造化することによって実現することができる。クライアントデバイス１１０に記憶された情報、サーバ１４０に記憶された情報、および／またはストレージコンポーネント１４５に従って記憶された情報は、スキーマに基づいて記憶することができる。スキーマは、サーバ間およびサーバフェデレーション１２０中で、サーバフェデレーション１２０とクライアント１１０の間で、そしてプラットフォームコンポーネント間で情報を通信する際にも使用される。さらに、図２のアプリケーションの各種コンポーネント２１０、２２０、および２３０間で通信する非同期メッセージも、スキーマを使用して通信することができる。
【００５２】
多くの状況で、ユーザは報告の作成、推移の分析、ニーズの予測、動作状況の変化の検出などのために複数のアプリケーションとデータソースにあるデータの使用を望む。不都合なのは、現在この種のデータは入手可能であることが多いものの、通例は各アプリケーションが各自のスキーマセットを使用しているために形式が全く異なっていることである。換言すると、アプリケーションは連絡先や時刻など類似性のあるデータタイプを記述するが、これらのデータタイプはしばしば異なる語彙を使用し、アプリケーションごとに異なる属性を有することがある。したがって、従来は、異なるスキーマに準拠するアプリケーション同士の通信を可能にするために、特殊化した翻訳またはインポート／エクスポート機能が必要とされている。
【００５３】
サーバフェデレーション１２０内の通信と連携を促進するために、本発明のスキーマとスキーマサービスコンポーネントは、日付、アドレス、処方、ショーの開始時間、製品の説明、価格、受領書、プレファランス、医療記録、映画評、あるいはその他の関連するデータタイプなど各種のデータ構造について、サーバフェデレーション１２０におけるインタラクションと連携の基盤を提供する。
【００５４】
異なるアプリケーションには異なるニーズがあり、またレガシーアプリケーションとクロスプラットフォームアプリケーションをサポートする必要があるので、世界共通のスキーマはおそらく現実的でない。これに対し、本発明のスキーマコンポーネント１７０は「コアスキーマ」の定義を試みる。「コアスキーマ」は、大半のアプリケーションが共通に有する事柄のみを定義する最小限の共通スキーマである。コアスキーマは拡張が可能であり、データインタラクションと連携を容易にするのに有用な重要性の高いデータエンティティを記述する新しいスキーマを定義して、下記で説明するコアスキーマに追加することができる。さらに、スキーマは、図１のクライアントデバイスのオペレーティングシステムまたはユーザインタフェースとサーバフェデレーションを含むネットワークと数層で機能することができる。
【００５５】
コアスキーマには、（ｉ）基本タイプ、（ｉｉ）社会タイプ、（ｉｉｉ）ビジネスタイプ、（ｉｖ）システムタイプ、および（ｖ）アプリケーションタイプ、を含むいくつかのタイプがある。
【００５６】
（ｉ）基本タイプは、他タイプのための基本的な構築ブロックとして使用される。例示的な基本タイプには、オブジェクト、項目、コンテナ、データベース、フォルダ、メッセージ、テキスト、またはその他のデータ構造などのタイプがある。種々のアプリケーションで使用される各種スキーマの基本タイプスキーマへの変換は、下記で説明する変換フィルタによって行うことができる。
【００５７】
（ｉｉ）社会タイプは、日常的なタスクとインタラクションに用いられる項目を表すか、または記述する。例示的な社会タイプには、連絡先、プロフィール、予定表（カレンダー）、タスク、時刻、場所、財政、およびその他の社会的に交換される情報や識別情報などの項目が含まれる。基本タイプと同様に、互換性のないデータ構造を社会タイプのスキーマに変える変換フィルタを作成することができる。
【００５８】
（ｉｉｉ）ビジネスタイプは、ビジネス環境およびビジネス間（Ｂ２Ｂ）の取引における共通の事柄を記述するのに用いる。例示的なビジネスタイプには、製品、会計、顧客、従業員、流通業者、小売業者、納入業者、およびその他のビジネスデータなどのタイプが含まれる。
【００５９】
（ｉｖ）システムタイプは、システム管理に用いられる情報の構造を定義する。例示的なシステムタイプには、ポリシー、スケジュール、サービス、デバイス、およびその他のシステム関連情報などのタイプが含まれる。
【００６０】
（ｖ）アプリケーションタイプは、アプリケーションとサービスの構造を定義する。例示的なアプリケーションタイプには、アプリケーションマニフェスト、アセンブリマニフェスト、ＣＯＭ＋のタイプ記述などのタイプが含まれる。システムタイプとアプリケーションタイプは、システムとハードウェアの構成に固有の情報に基づく。
【００６１】
スキーマコンポーネント１７０は、スキーマ情報とデータの記憶、発見、照会、パブリッシュ、および共有に使用されるいくつかのスキーマサービス２９２も提供する。図３を参照すると、スキーマストア２９０はスキーマ情報を収集し共有する場所である。例えば、スキーマストア２９０は、コアスキーマタイプの記述と、知られるスキーマとコアスキーマタイプとのマッピングを含むことができる。本発明の一実施形態では、スキーマはＸＭＬスキーマであり、スキーマ記述言語によってスキーマストア２９０に記述される。（スキーマ記述言語の一例はＸＳＤであり、これを拡張して本発明に使用することができる。）スキーマストア２９０は、本発明のストレージコンポーネント１４５の一例である（これについては下記でより詳しく説明する）。このように、スキーマストア２９０はサーバフェデレーション１２０中に分散することができる。スキーマストア２９０は、アプリケーションがスキーマを記憶することのできる唯一の場所ではないが、アプリケーションは、スキーマをこの場所に記憶することにより、スキーマサービス２９２とそのサービスを使用するアプリケーションがスキーマを見つけ、それを用いて動作することを保証することができる。また下記でより詳細に説明するように、アプリケーションはスキーマストア２９０とスキーマサービス２９２を使用して、スキーマをローカルに複製および記憶し、更新することができる。スキーマストア２９０およびスキーマサービス２９２へのアクセスは、セキュリティコンポーネント１６５によって提供される各種のセキュリティ認証、承認、およびファイアウォールサービスによって制御することができる。
【００６２】
スキーマサービス２９２は一般に、アプリケーションがスキーマ情報を記憶、発見、照会、およびパブリッシュするための機構であるスキーマ登録サービスを含む。例えば、スキーマストア２９０は、例えばスキーマ登録ＡＰＩ（アプリケーションプログラミングインタフェース）を含むスキーマ登録サービスを介して各種のスキーマを収集し参照することができる。スキーマ登録サービスにより、アプリケーションはスキーマストアにスキーマ情報を追加し、ストアからスキーマ情報を削除することができる。
【００６３】
スキーマサービス２９２は、管理者、オペレーティングシステム、あるいは他の背景に存在するスキーマ仲介者がスキーマを更新することを可能にするスキーマ更新サービスも含むことができる。スキーマサービス２９２はまた、インスタンスデータ中の参照を追跡することによってストアに保持されていないスキーマを持ってくる分散スキーマサービスも含むことができる。このサービスを容易にするために、ストレージコンポーネント１４５に従ってサーバフェデレーション１２０にスキーマを記憶することができ、新しいスキーマがパブリッシュされるとイベンティングコンポーネント１５５を使用してアプリケーションに通知することができ、したがってスキーマの世界的な分散が可能になる。スキーマサービス２９２はさらに、ストア内のスキーマおよびマッピングの保全性と一貫性を維持するスキーマ有効性確認サービスを含むことができる。このサービスは、スキーマ記述言語の構造的な有効性の確認を提供し、冗長なエンティティあるいは矛盾するエンティティと、スキーマ間の関連付けの一貫性検査をチェックする。スキーマストア２９０は、本発明のイベントコンポーネント１５５に依存してスキーマの変更の通知を提供する。スキーマストア２９０は、更新、イベント、サブスクリプション、および通知を分散するためのトランスポートとしての本発明のメッセージングコンポーネント１６０に依存することもできる。
【００６４】
例えば、ローカルのスキーマストアは、スキーマ更新サービスをサブスクライブしてコアタイプとスキーマを更新することができる。一構成ではオブジェクトマネジャを使用してスキーマイベントの登録をサポートし、何らかの関連性のあるスキーマの変更が行われたときに関心のあるユーザがそれを検出できるようにする。ローカルのスキーマストアは、更新のために１以上のソースをサブスクライブすることができる。更新サービスは、人々や時間などのコアタイプと、そのコアタイプとＭＡＰＩ、ｖＣａｒｄ、ＬＤＡＰ、およびＷＭＩなどの共通スキーマとのマッピングをスキーマストアに事前に取り込んでおく。企業は、同様の更新サービスをホストして各自の組織ネットワーク内のスキーマストアを維持することができる。
【００６５】
スキーマ変換サービス（これもスキーマサービス２９２の一部である）は、異なるスキーマを使用するアプリケーションが意味を共有することを可能にする。スキーマ変換サービスの例には、スキーマアダプタサービス、スキーマレコグナイザサービス、およびスキーママッピングサービスがある。スキーマ変換サービスはデータを認識する共用機構を提供し、あるスキーマのデータを別のスキーマに変換することにより、アプリケーションが新しいスキーマを動的にサポートすることを可能にする。スキーマ変換サービスは、データを認識し、あるスキーマのデータを別のスキーマに変換する共用機構を提供することにより、アプリケーションがより容易に幅広いスキーマを理解できるようにし、アプリケーション間の堅牢性と一貫性を増し、アプリケーションが新しいスキーマを動的にサポートすることを可能にする。
【００６６】
スキーマアダプタサービスは、例えば、ＸＭＬなどの規格化された言語で構造化されていないデータを扱うことを可能にする。スキーマアダプタサービスは、非ＸＭＬデータを受け取り、それをＸＭＬデータ、またはスキーマとの通信に用いられるその他のデータタイプに変換する。
【００６７】
スキーマレコグナイザサービスは、データの処理の仕方がアプリケーションに分かるように、データインスタンスのスキーマタイプを識別する。スキーマレコグナイザサービスは、入力としてＸＭＬデータまたはプレーンテキストを受け取る。ＸＭＬの場合、スキーマレコグナイザサービスは、標準のストレージ照会サービス２９４を使用してスキーマストア２９０に照会し、スキーマタイプを判定し、ＸＭＬの名前空間を使用して可能性のリストを絞る。プレーンテキストからスキーマタイプを推論するために、スキーマレコグナイザサービスは自然言語サービスに依存し、自然言語サービスはスキーマストア２９０を使用する。スキーマタイプが分かると、アプリケーションはその情報を使用して独自のユーザインタフェースを提供するか、またはシステム全体で用いるユーザインタフェースを可能にする。
【００６８】
スキーママッピングサービスはあるスキーマのＸＭＬデータを受け取り、スキーマストア２９０で定義されるマッピングに基づいてそのデータを変換し、別のスキーマのＸＭＬ表現でそのデータを戻す。一構成では、スキーママッピングサービスは、しばしばスキーマアダプタサービスと併せて、書き込みのインポートまたはエクスポート機能を有するアプリケーションによって使用される。
【００６９】
スキーマストア２９０に保持されるスキーマは、特定のスキーマタイプに作用する、または特定のスキーマタイプを表すために使用できるアプリケーション、スクリプト、コンポーネント、メソッドバインディング、またはデータソースを記述することができる。例えば、あるアプリケーションは、特定のスキーマタイプのデータを表示する標準的なユーザインタフェースを提供することができ、一方別のアプリケーションはそのデータに作用するためのビジネスロジックを有することが可能である。所与のシナリオに対してどの動作が適切であるかは、ユーザのコンテクストプレファランスによって決まる。これらのスキーマサービスはユーザインタフェースコンポーネント１４０と協働して、動作メニュー、オートコンプリート、およびスマートクリップボードのドラッグ／ドロップ（下記で説明する）などのいくつかのエンドユーザ機能を可能にする。
【００７０】
動作メニュー機能は、任意のアプリケーションにおいてあるデータに対して利用可能な動作の選択肢を提示する。一構成では、この利用可能な動作は「擬似事実（ｆａｃｔｏｉｄ）」方式で提示され、ユーザはそれを選択しても無視してもよい。アプリケーションは、ストレージ照会サービス２９４を用いて、特定のデータタイプに関連する登録された動作をスキーマストア２９０に照会する。取り出された動作は、動作メニューの生成に使用される。例えばユーザがある住所をクリックすると、アプリケーションは、「住所」のタイプについて照会を行い、スキーマストア２９０は、「封筒に印刷」や「この住所の地図を作成」などの動作を戻し、それがコンテクストメニューに取り込まれる。動作メニューのＡＰＩにより、開発者は、このメニューと他のアプリケーション固有の動作を各自のアプリケーションに公開することができる。スキーマストア内の各コアタイプについてのあらかじめ取り込まれた動作メニューは、オペレーティングシステム、インターネットブラウザ、および各種のアクティブなアプリケーションで公開することができる。
【００７１】
スキーマサービスは、データソースから可能な値を列挙して選択肢を提示することによりユーザがウェブフォームやドキュメント中のデータフィールドに記入するのを容易にする、既存の「オートコンプリート」機能も強化することができる。ユーザに提示される可能な値のリストは、スキーマストア２９０への登録に基づく。例えば、友人をパーティに招待するのに「Ｅｖｉｔｅ」すなわち「電子的な招待（ｅｌｅｃｔｒｏｎｉｃ ｉｎｖｉｔａｔｉｏｎ）」に記入する際には、電子メールのアドレスフィールドは、スキーマストア２９０への登録を通じて電子メールアドレスのプロパティと結びつけられた、ユーザの連絡先リストにあるアドレスのリストを提供することになる。これと同じ機能を他のアプリケーションを通じて公開して、手紙、送り状、表計算、メーリングリスト、データベース、あるいはその他のドキュメントにオートコンプリートを提供することができる。これと同じ値のリストは、その機能を公開することを選択したどのアプリケーションでも表示される。
【００７２】
スマートクリップボードのドラッグ／ドロップは、スキーマ変換サービスを使用して、異なるスキーマを使用するアプリケーション間でデータを交換することを可能にする。したがって、スキーマ変換サービスは、既存のドラッグアンドドロップとクリップボードルーチンを強化して、異なるスキーマをサポートするアプリケーション間でデータを移動し、一方、そのデータが何を表すかについては共通の理解を維持する。
【００７３】
このように、スキーマコンポーネントは、イベント、メッセージング、ストレージ、スキーマ、セキュリティなどプラットフォーム１１５の他の技術コンポーネントと協働して動作し、クライアントデバイスとサーバデバイス間で有意味の情報を共有する機構を提供する。
【００７４】
（Ｅ．ユーザインタフェース）
図１のプラットフォーム１１５のユーザインタフェースコンポーネント１４０は、各種のクライアントデバイスにわたって、マルチモーダル、応答型で、かつインテリジェントなユーザインタフェースを提供する。図４に、ユーザインタフェースコンポーネント１４０を概略的に示す。
【００７５】
ユーザインタフェースコンポーネント１４０は、マルチモーダルのユーザインタフェース（ＵＩ）を提供する。つまり、ユーザは複数のモードでＵＩとインタラクトすることができ、そのモードはオンザフライで継ぎ目なく変更することができる。ユーザインタフェースコンポーネント１４０は、マルチモーダルの入出力を可能にする高度の入出力コンポーネント４００を含む。入出力コンポーネント４００は、キーボード入力やマウスクリックなど「伝統的な」方式を使用したユーザ入力を受け取ることができる。入出力コンポーネントは例えばテキスト４０２を受け取る。ただしＵＩは、これ以外にも、マイクロフォンを備えるデバイスにはオーディオ／音声入力（例えばオーディオ／音声４０４）、タッチスクリーンまたはパッドを備えるデバイスにはスタイラス／タッチ入力、手書き入力機能のあるデバイスには手書き入力（例えば手書き４０６）など他の入力方式も可能にする。双方向の矢印４０８で表すように、入出力コンポーネント４００は、テキスト４０２など従来の出力に加えて、オーディオ／音声４０４や手書き４０６などの従来型ではないコンピュータ化された出力も提供することができる。
【００７６】
入出力コンポーネント４００はまた、特にデバイスに情報を入力する際に有用な各種の変換技術も組み込んでいる。この変換には、ユーザのオーディオ／音声入力をテキストに変換する音声テキスト変換技術が含まれる。この変換は、ユーザが乗り物の運転中であるか、その他の理由でタイプする能力を欠くときなど、従来のタイピングを用いてテキストを入力することができないか、あるいはそのような入力が不都合である際に有用である。入力に有用な別の変換には、ユーザの手書きによるスタイラス／タッチ入力をテキストに変換する手書きテキスト変換技術がある。この変換により、キーボードなどのテキスト入力デバイスがデバイスに備わっていない場合にテキストを入力することが可能になる。
【００７７】
例えば、タブレット型のパーソナルコンピュータ（すなわち「タブレットＰＣ」）は、例えばスタイラスを用いて直接画面に書くことによる手書き入力が可能なデバイスである。タブレットＰＣは、入出力コンポーネント４００を使用して、紙への手書きでは不可能な方式でテキストを編集できるように手書きをテキストに変換することができる。例えば、段落間にスペースを挿入して注釈を加えることができる。タブレットＰＣは、必要に応じて、手書き自体を表示することも、手書きのテキスト内容を表示することもできる。
【００７８】
入出力コンポーネント４００はまた、「伝統的な」テキストとグラフィックによる表示を超える複数のモードでユーザにデータを提示することができる。例えば、ＵＩは、テキスト（タイプされた電子メールメッセージなど）をオーディオ（デバイスのスピーカを通じてそのメッセージを「読みあげる」）に変換する、テキスト音声変換技術を組み込むことができる。また、テキストによる電子メールメッセージと併せてボイスメールを統一されたメッセージングシェルに組み込むこともできる。必要な場合は、音声テキスト変換によりこのボイスメールをテキストに変換することができる。
【００７９】
マルチモーダルのユーザインタフェースは、ユーザが、ユーザの状態とデバイスとの近接度（ｐｒｏｘｉｍｉｔｙ）に応じて各種のデバイスとインタラクトすることを可能にする。例えば、ＰＣなどのリッチクライアントを使用している際には、ユーザはビデオ／オーディオで自分宛てのメッセージを表示させ、テキストで返信することを選ぶことができる。しかし、車内では自分のメッセージをオーディオだけで再生させ、返信もオーディオによることを選択することができる。
【００８０】
この自然言語によるやり取りは、ユーザ固有の統一されたユーザインタフェースポータルの概念に基づいて可能になる。統一されたユーザインタフェースポータル概念の例には、入力ストリングの分析、論理形式の照合を介したマッチングの概念、結果を伴う適切な言語様の文章の生成、ユーザ向けにカスタマイズされた検索パラメータに基づく有用なフィードバック、および、ユーザの従来のストレージ位置を優先的に検索するように設定した、複数の異なるデータベースストアにわたってスマートに実行することが可能な検索インフラストラクチャが含まれる。
【００８１】
ユーザインタフェースコンポーネント１４０は、マルチモーダルであるのに加えて、ユーザの状態と複数のクライアントデバイス１１０にわたるコンテクストに基づいて適合する、かつ／または変化するという意味で応答型である。例えば、このユーザインタフェースは、ユーザのプレファランスとセッションステータスに応じて構成およびレンダリングされ、ユーザがセッション中にあるクライアントデバイスから別のクライアントデバイスに切り替えると、ユーザはもう一方のクライアントデバイスを使ってそのセッションを継続することができ、ユーザインタフェースは複数のクライアントデバイスにわたって一貫性のある表示になる（ただし下記で述べるように変更される可能性はある）。
【００８２】
図４を参照すると、プレファランス情報は、サーバフェデレーション１２０中のマイステート（ＭｙＳｔａｔｅ）適合ディレクトリ９０５に記憶することができる。ユーザがクライアントデバイスで作業をすると、マイステートディレクトリ９０５でセッションステータス情報が定期的に更新される。ユーザが別のクライアントデバイスに切り替えると、セキュリティコンポーネント１６５を用いた適切な認証の後に、プレファランスおよびセッション情報が新しいクライアントデバイスに提供される。プレファランス情報により、新しいクライアントの表示を前のクライアントと一致するように表示することができる。さらに、セッション状態情報により、新しいクライアントデバイスは、前のクライアントデバイスが中断した箇所からセッションを継続することができる。
【００８３】
ユーザインタフェースはまた、クライアントデバイスの技術的機能に合わせて適切かつ円滑にスケーリングする。例えば、携帯電話は、入力キーや表示領域に空間的制限があることから、そのユーザインタフェースに明らかに技術的な制限がある。こうした携帯電話用のユーザインタフェースは、ユーザインタフェースの重要性の高い機能だけを強調するように縮小される。したがって、ユーザは、セッション中にリッチクライアントであるパーソナルコンピュータからシンクライアントである携帯電話に移行することができるが、携帯電話のユーザインタフェースが提供するそのセッションのユーザ体験はより制限されたものになる。このクライアントデバイス間の円滑なスケーリングは、コード管理コンポーネント１７５から供給される、下記で詳細に説明するマニフェストを使用して実現することができる。マニフェストは、例えば、クライアントデバイスに表示する必要のある最小限のユーザインタフェース機能を記述し、そしてクライアントですべてのコンポーネントを表示することができない場合に表示すべきユーザインタフェース機能の優先度を記述することができる。
【００８４】
図４を参照すると、クライアントデバイスの機能に応じてクライアントデバイスが利用することのできるユーザインタフェースの全範囲４１２がある。この範囲には、高度に開発されたマルチモーダル機能と利用可能な処理能力を有するクライアントデバイス向けの非常にリッチなインタラクション型ＵＩページコンポーネント（例えばページコンポーネントＲ）が含まれる。ライブラリは、それほど高度でないユーザインタフェースを有し処理能力が低いクライアント向けのシンページコンポーネント（例えばページコンポーネントＴ）も備える。図４に示すユーザインタフェースＵＩは、この範囲４１２のいずれかの位置にあるページコンポーネント４１４から描いている。
【００８５】
また、ユーザインタフェースはユーザアクティビティにインテリジェントに応答する。例えば上述のように、ユーザインタフェースコンポーネント１４０はスキーマコンポーネント１７０（およびスキーマサービス２９２）と協働して「スマートタグ」の動作メニューをユーザに提供する。ユーザが（ウェブページ、ドキュメント、あるいは連絡先リストで）アドレスをタイプした場合、スキーマサービス２９２によりそのアドレスをアドレスとして認識することができ、したがってホットタグを提供する。スマートタグは、例えば、認識された項目に青い破線の下線などの識別マークを付けることによって表すことができる。
【００８６】
ユーザは、例えばマウスの右クリックでマークのついたアドレスを選択して、認識された項目のタイプに適した動作メニューを得ることができる。例えば、住所と認識される項目の動作メニューは、地図を見る、住所ラベルを印刷する、連絡先リストに追加するなどの機能を提供することができる。適切な動作の１つとして、その住所を使用して、例えばその住所を包含する地図などより多くの情報を見つけることが挙げられる。この際に、ユーザインタフェースは、ディレクトリサービスコンポーネント１５０を通じて利用可能になるマッピングサービスを調べることができる。
【００８７】
また、ユーザインタフェースはユーザがタイプしていることを検出することができ、したがってユーザインタフェース機能をワードプロセッシングのアクティビティに絞ることができる。例えば、タイプすることにより、ユーザがワードプロセッシングを行うものとユーザインタフェースが判断するイベントがトリガされる。このようなイベントのトリガと推論の構築はイベントコンポーネント１５５によって提供される。
【００８８】
ユーザインタフェースは統一されたコマンドラインも有することができ、これを使用して検索を行う、ウェブサイトに行く、ファイルシステムのファイルにアクセスする、あるいは自然言語の照会またはコマンドを行うことができる。好ましい実施形態では、統一されたコマンドラインは、何らかの形態であらゆるタイプのデバイスに提供される。照会を行う際、ユーザインタフェースコンポーネント１４０はインテリジェントなフィードバックプロセスを使用して、コマンド、コントロール、あるいは論理的プロセスの実行の解釈を行わせるか、あるいは確認を求める。例えば、ユーザが統一されたコマンドラインに「今日の市場はどんな具合か」とタイプする。この問いには多少多義性および／またはあいまいさがある。するとユーザインタフェースコンポーネント１４０は、「興味のある指標は？」と音声で応答することができる。するとユーザはコマンドボックスに「ダウジョーンズ」とタイプする。ユーザインタフェースコンポーネント１４０はこれにより、応答を音声で返すのに十分な情報を得たことになる。コマンドラインで要求される情報を戻すために、ユーザインタフェースコンポーネント１４０はストレージコンポーネントおよびメッセージングコンポーネントと協働して情報を取り出さなければならない。
【００８９】
統一されたコマンドラインは、自然言語のコマンドを行う際にも使用することができる。例えば、ユーザが「Ｊｏｅ Ｄｏｅとの面会を３：００に予定」とタイプする。ユーザインタフェースコンポーネント１４０は、日付、継続時間、および面会の場所を明らかにすると、そのようなアクセスがＪｏｈｎ Ｄｏｅによって承諾されている場合にはＪｏｅ Ｄｏｅの予定表を調べる。Ｊｏｈｎ Ｄｏｅが確立した規則とプレファランスにより、要求される時間、場所、および要求される継続時間で面会を予定することが可能な場合は、その面会をＪｏｈｎ Ｄｏｅと要求者双方の予定表に予定する。
【００９０】
統一されたコマンド／検索ラインは、照会またはコマンドを解釈し、ローカルに提供されるサービスとネットワーク上で提供されるサービスの両方に仲介として提供（ｂｒｏｋｅｒ ｏｕｔ）する。このコマンド／検索ラインはユーザインタフェース中のある場所にあり、その位置に関係なく同じ方式でアクセスされ、タイプ（キーボード）、音声、手書きなどあらゆる形態の入力をユーザインタフェースによって受け取ることができる。キーボード、ブール演算、および自然言語（断片、名詞句、および／または形式の整った文章）などあらゆるレベルのインテリジェンスもユーザインタフェースで受け取り、処理することができる。
【００９１】
ユーザインタフェースコンポーネント１４０は、エンドユーザが、例えば学生、従業員、経営者、投資家、患者、親、消費者、およびピアニストなど多数の役割を持った者であることを認識する単一の統一されたシェルを提供することができる。ユーザインタフェースはこの単一の統一シェルを介して、これらのすべての役目をまとめてリッチで継ぎ目のない体験を作り出す。
【００９２】
ユーザインタフェースコンポーネント１４０の統一ポータルにより、エンドユーザは、プロジェクトの優先度の設定を含む統一ポータルの設定をカスタマイズし、制御することができ、これによりオペレーティングシステム、ドキュメント、および各種のアクティビティに使用されるアプリケーション間の視覚的な分離が最小限になる。
【００９３】
このカスタマイズを通じて、ユーザインタフェースコンポーネント１４０はインテリジェントにページを埋め、レイアウトする。このカスタマイズは、プレファランスの形でマイステートディレクトリ９０５に記憶される。ユーザがクライアントデバイスにログオンし、セキュリティコンポーネント１６５で認証されると、サーバフェデレーション１２０は協調してそのプレファランスに準拠する個人設定された情報（おそらくはストレージコンポーネント１４５のメガストアに記憶されている）を入手し、リンク４１０を介してその情報をユーザインタフェースに提供する。
【００９４】
ユーザは、ユーザインタフェースコンポーネント１４０の設定をカスタマイズし、制御することによりユーザの作業状態の認識を含めさせ、それに応じてユーザインタフェースの外観を調整することも許される。異なるユーザインタフェースが必要とされる作業状態の例には、ユーザがＰＣで作業をしているとき、ユーザがオフィスを去ったとき、ユーザがＰＤＡや無線電話を介してデータにアクセスするとき、ユーザが自宅、あるいは他の場所、あるいはサーバフェデレーション１２０に接続された電子デバイスから作業しているとき、などがある。
【００９５】
またユーザインタフェースにより、エンドユーザは、メッセージと優先度設定の確定を含むユーザの優先度設定に関連するデータを収集することをデバイスに指示することができる。例えば、ユーザは自分の上司からのメッセージに常に高い優先度を与え、上司からのメッセージを受信する際には割り込みを行わせるというプレファランスをセットすることができる。したがって、メッセージの受信を知らせるイベントコンポーネント１５５からの通知は、このプレファランスに基づいてフィルタリングすることができる。統一されたシェルにより、ウェブベースのコミュニティが個々のＰＣのデータをコミュニティプロジェクトに提供することも可能になる。これは、マネジャが自分のＰＣポータルからコンテンツを制御する能力を持つことを可能にするので、特にワークコミュニティに有用である。
【００９６】
ウィンドウの共有とドキュメントの共有も可能になり、ユーザが通信リストにある誰かと通信状態にある際、どちらかの者がウィンドウの共有またはドキュメントの共有を活動化すると、もう一方の者は当該のウィンドウまたはドキュメントを閲覧することができる。このようなウィンドウの共有は、サーバフェデレーションのメガストアにあるドキュメントにアクセスし、他の者がセキュリティコンポーネント１６５を通じてそのドキュメントに適切にアクセスすることができるようにセキュリティ設定を構成することによって実現することができる。
【００９７】
ユーザインタフェースはまた、ユーザが既存のリポートやその他のデータ構造を迅速に再利用することを可能にする非定型のテンプレートも作成する。このテンプレートは、パブリッシュする、分散する、または統一ポータルを介してワークコミュニティの他のメンバー間で共用するか、あるいはイントラネットやインターネット上にパブリッシュすることができる。テンプレートの生成は、各関係者が最終的な製品に寄与することができる電子的なワークコミュニティで作業する際に有用な機能である。特定のテンプレートは、各ワークコミュニティの関係者にリポートを完成するための特定の情報を要求する。
【００９８】
ユーザインタフェースはまた、リストにある個人の連絡方法や、接触方法について事前に決定された設定を用いる「バディ（仲間）リスト」の使用も可能にする。連絡方法の例には、電子メール、電話、ファクシミリ、アドレス情報、テレビ会議の必要性、無線通信ポータル、あるいはその他の通信機構が含まれる。この「バディリスト」は、個人が特定のデバイスにログオンするとイベントをトリガするイベントコンポーネント１５５によって生成される。ユーザインタフェースコンポーネント１４０はこのイベントを受信し、ユーザに提示する。そして、ユーザインタフェースは、異なるシステム同士が継ぎ目なく通信することができるように、標準の個人的なカレンダリングスキーマを利用できるようにする。
【００９９】
ユーザインタフェースは、パーソナルデバイスの使用、関連付けられたセキュリティ設定におけるユーザオブジェクトの会議の認識、ローカルな関係者および分散した関係者両方とのドキュメントの共有、ウェブを介して迅速にアクセスできるようにローカルデバイス上のドキュメントを移動する能力、統一されたユーザインタフェースポータルで行われる手書きの注釈に対する応答、そして、イベントのカレンダリングの結果行われる通知のトリガ、をサポートする。
【０１００】
ユーザインタフェースは、ユーザがアプリケーション間および通信間を継ぎ目なく移動するための中心となる場所である。単一の統一された編集／コントロール、あるいは編集とコントロールにより、同じ場所で特定の構造化データベースへの照会をホストすることができる。このシステムには、アプリケーション状態の認識と、適切なアプリケーションモデルにアクセスする能力が与えられる。
【０１０１】
このシステムは、ＰＣ上のアプリケーションとサービスへのアクセスを提供する「個人ポータル」を提供する。例えば、このシステムはユーザスキーマの知識を使用してインテリジェントにページを埋め、レイアウトする。このシステムは、個人的な情報、共有された情報、および世界的な情報をナビゲートし、そして各自のコンピュータを動作させるというユーザのニーズにキーリンケージを提供する。
【０１０２】
このようにこのユーザインタフェースはマルチモーダルであり、ユーザから入力を受け取り、ユーザに出力を提供する際の柔軟性を可能にする。このユーザインタフェースは、クライアントデバイスの機能に合わせて適切にスケーリングし、ユーザがセッション中にクライアントデバイスを切り替えることを可能にするという点で応答型でもある。このユーザインタフェースは、ユーザの行動の裏にある意図を推論し、ユーザインタフェースが特定の項目を認識すると、その項目に適した関連付けられた動作メニューを備えるスマートタグを提供するなど、適切な動作をとる点でインテリジェントである。
【０１０３】
（Ｆ．イベント）
本発明のイベントコンポーネント１５５は、イベントをパブリッシュすなわち生成する任意のソフトウェアコンポーネント（「イベントソース」）と、イベント通知をサブスクライブすなわち受信する任意のソフトウェアコンポーネント（「イベントシンク」）間の分散したイベントの通信を透過な形で容易にする。この説明および特許請求の範囲で、イベントとは、例えばシステムコンポーネントのステータス、ユーザのアクティビティ、環境の測定など、１以上の状態についての観察である。イベントシステムは、ソフトウェアコンポーネントとアーキテクチャが、各自のコンテクストについての絶えず更新される情報にアクセスすることを可能にする。
【０１０４】
図５は、１以上のイベントソースと１以上のイベントシンク間に例示的なイベントの通信を提供するイベントコンポーネント１５５の概略図である。イベントはイベントソース６０２で各種の方式で生成される。イベントは、イベントシンク６０４へのブロードキャスト、または有向の通信としてイベントソース６０２で生成することができる。イベントシンク６０４はイベントを受信するために、イベントソース６０２をリッスンするか、または積極的にポーリングすることができる。さらに、イベントシンク６０４は、イベントソース６０２をサブスクライブするか、あるいはサーバフェデレーション１２０中の中間点から転送されるイベントをリッスンすることができる。
【０１０５】
イベントコンポーネント１５５は、イベントコンポジション機構６０８を通じて、イベントソース６０２から提供される基本イベントまたはアトミックイベント６０６を、漸進的にレベルが高くなるイベントに変換する。イベントコンポジションのプロセスは、１セットの観察されたイベントおよび／または記憶されたイベントデータから新しいイベントまたは動作を構築することである。イベントコンポジションは、規則、フィルタによって、また、精巧度が一定の範囲にわたり最上位にリッチな推論機械が位置する、より高度なパターンレコグナイザによって駆動することができる。したがって、イベントコンポジションは、利用可能なアトミックイベントのセット６０６を適合して、ソフトウェアコンポーネントの情報要件に適宜マッチさせる観察６１０にし、適正な判断ができるように適正レベルで抽象化した情報をソフトウェアコンポーネントに提供する。
【０１０６】
イベントコンポジション６０８は、低レベルのイベント（アトミックイベント６０６）を集約、フィルタリング、および変換してより高いレベルのイベント６１２にし、時にはそのイベントを直接ワールドアクション６１４などの動作にマッピングする。動作には、現実世界のアクション６１４と、積極的なポーリングまたはリスニングを介して新しいイベントを収集する機能を果たす情報収集アクション６１６が含まれる。イベントコンポジション６０８は、イベントが時間的に近接して観察されるか全く異なる時間に観察されるかに関係なく、イベントとデータを組み合わせる方法を提供する。コンポジションコンポーネントの構築には、イベント固有の言語６１８とコンポジションコンパイラ６２０を使用することができる。イベントコンポジション６０８は各種の方法を用いることができ、この方法は、イベントとデータを組み合わせるための、単純な規則およびフィルタから、よりリッチな時間的なパターンマッチングおよび直截な論理的、確率的な推論におよぶ一定範囲の精巧度にわたる。
【０１０７】
例えばイベントストア６２２などのイベントの消費側は、低レベルイベントのセット（アトミックイベント６０６）またはより高いレベルのイベント６１２から推論６２４を行い、その推論に基づいて行動をとる。推論６２４は、単純な情報の再送から、論理的推論、ベイズ推定、および決定理論的推論にわたる。例えば、ユーザの位置、アクティビティ、およびアクティブなデバイスについてのイベントストリームをベイズモデルで分析して、ユーザの目的についての確率のセットを提供し、それを使用して、ユーザに提供する最も重要なサービスと通知について理想的な決定を行うことができる。図５ではイベントコンポジション６０８はイベントに基づく推論６２４と分離しているが、低レベルのイベントから高レベルのイベントを構成する高度なコンポジション機構は概念上は意思決定のための推論と融合する。
【０１０８】
イベントコンポーネント１５５は、サーバフェデレーション１２０とクライアントデバイス１００にイベントを分散し、登録し、アクセスすることができるようにし、また、イベントシステム全体および下位システムの様々な側面について「メタ推論（ｍｅｔａｒｅａｓｏｎｉｎｇ）」を行い、それによりイベントの通信と受信の自己監視、制御、およびスロットルを行う能力をシステムに与える。メタ推論とは、イベントシステムの正常性と維持を保証する方法と推論機械を言う。
【０１０９】
イベントコンポーネント１５５は、どのイベントソースまたはシンクも、広くブロードキャストされるイベント、あるいは範囲の定まった領域内でブロードキャストされるイベントをパブリッシュ、サブスクライブ、あるいはリッスンすることができるようにする。これには、コンポジションのサブスクリプション、デコンポジション（ｄｅｃｏｍｐｏｓｉｔｉｏｎ）、および配置をネットワーク中の中間ノードにインテリジェントに分散させることと、ルーティングが必要となる。イベントコンポーネントは、セキュリティコンポーネント１６５のセキュリティサービスを使用して、イベントソース、イベントシンク、および中間ノードが諸機能を委託できるようにする。
【０１１０】
イベントコンポーネント１５５は、本来は互換性のないイベントソースとイベントシンク間の相互運用可能な通信と優先度設定を容易にし、一方で個々のシンク／ソースの最高度のプライバシーとシステム全体のセキュリティを維持するように設計される。イベントコンポーネント１５５には、これらに限定しないがパブリケーションおよびサブスクリプションのシステム、イベントコンポジション機構、イベントルーティング機構、イベントのストレージおよび記録の機構、イベントシステムのメタ推論が含まれる。イベントコンポーネント１５５はまた、スキーマコンポーネント１７０によって提供されるスキーマおよびスキーマサービスと、メッセージングコンポーネント１６０によって提供される通信プロトコルおよびサービス品質も使用する。
【０１１１】
イベントスキーマは、クラス記述と、物理的なイベント構造を定義するそれらクラス間の関係の集合である。このクラス間の関係には、イベントクラス、ソース、ターゲット、セマンティック、存在論的なコンテンツ情報、観察に基づく信頼度、およびイベントソースに知られたサービス品質の属性が含まれる。好ましい実施形態では、クラスの記述はＸＭＬベースのスキーマクラスである。
【０１１２】
イベントの記述には、イベントの構造と制約を表現するスキーマ記述言語と、予定される振る舞いとコンポジション的な特性を表す宣言型のパターン言語を使用する。スキーマ言語では、イベント構造は単純である。イベントは、パターンマッチングとルーティングで用いられるパブリックエンベロップと、終端間のデータをプライベートに搬送するのに使用されるプライベートボディを有する。この構造により、パターン言語は、派生的なイベントを作成するためのより高いレベルのセマンティックと規則を取り込むために、インスタンスデータとスキーマ情報を使用することができる。
【０１１３】
スキーマ言語を使用することにより、単純な名前に基づく変換に比べてより幅広い表現が可能になる。個々のイベントをフィルタリングして変換し、複数のイベントをまとめてコンポジションしてより高いレベルのイベントにする。パターン言語は、コンポジションおよびカプセル化のための演算子、時間的関係、論理的関係、ストリング操作およびＸＭＬ演算子、エンドポイントネーミングおよびトポロジの記述、および数学的関係を含んでいる。この言語は、パラメータ化を介してコンポジション仕様の再使用を容易にする。
【０１１４】
イベントスキーマは拡張することができる。継承に基づく強力な関係モデルにより、下位互換性のあるバージョニングが可能になる。イベントタイプは、強力な拡張可能タイプのシステムに基づく明確な特徴を備える。モデルは、標準的なＸＭＬの語彙を使用して記述され、プロトコルに依存しない。イベントスキーマに加えて、各種のサービス（例えば、パブリッシャ機能スキーマ、サブスクライバ機能スキーマ、イベント転送スキーマ、トポロジ、イベントストアスキーマ、コンポジションおよびフィルタリングなど）がモデル化され、分散イベントシステムを構成する。
【０１１５】
イベントサービスのサービス／コンポーネントを図式化することにより、イベントサービスの全コンポーネントの相互運用性の実現と発見、および全コンポーネントをブラウズする能力を実現することができる。図式化はまた、コンポジションシナリオを統計的に分析／最適化し、長期間にわたるコンポジションシナリオの状態を調査／保存し、イベントサービスの動作を監視する能力も可能にし、メタ推論の主要な基盤として機能する。
【０１１６】
イベントシステムは、モデルベースのサブスクリプションの登録によって推進される、高度に最適化されたパブリケーションとサブスクリプションのサービスを含む。イベントシステムは、例えば、カーネルドライバのプログラミングモデルを利用するカーネルイベント（例えばＷＤＭドライバイベント）、低レベルのオペレーティングシステムサービスのプログラミングモデルを利用するイベントをパブリッシュするためのＣＯＭ ＡＰＩ（例えばセキュリティ監査イベント、ディレクトリ、サービスコントロールマネジャ）、通常アプリケーション用の従来型のＣＯＭインタフェース、および、ネイティブＣＯＭ＋プログラミングモデルを利用する高レベルのＣＯＭ＋クラス、などのイベントをパブリッシュするサービスの柔軟性と選択を可能にする。
【０１１７】
「イベントのサブスクリプション」は、特定の条件が発生したときにそれをイベントインフラストラクチャがサブスクライブコンポーネントに通知することを求める要求である。この条件の例は、「ＣＰＵの利用率が９０％を超える」、「プロセスＡが中断した」などである。これらの命令は、構成オブジェクトとしてスキーマリポジトリに記憶される。
【０１１８】
各命令は２部分からなる。第１の部分は対象イベントを指定する（フィルタ）。第２の部分は、そのイベントに応答して実行する動作を指定する。フィルタは、対象となるイベントを定義するステートメントを含む。単一のフィルタで複数の動作をトリガすることができる。動作は、ユーザ定義の規則セットによって駆動することができる。例えば、ユーザは、特定の高優先度の送信者から電子メールを受信する場合にのみ電話での会話中に割り込みを行ってもよいと指定することができる。これにより、このユーザは、自分から割り込みを希望しない限りは割り込みを受けることなく電話の会話を続けることができる。このように、ユーザは、仕事の時間が私的な時間に入り込む、あるいはその逆の規則を指定することにより仕事の時間と私的な時間のバランスをとることができる。割り込みが妥当である場合には、電子メールメッセージがメガストアから提供される。このようにしてユーザは自分の情報と時間に対するコントロールを維持する。
【０１１９】
サブスクリプションは、賃貸の概念に基づき設定可能な寿命を有することができる。システムの再起動後も継続する必要があるサブスクリプションは、スキーマリポジトリに記憶される。ただし、安価で寿命が短いイベントサブスクリプションもサポートすべきである。これは、持続可能なバインディングをサブスクライバが実装する必要なしに、単純なコールバックとフィルタを用いて設定することができる。
【０１２０】
サブスクリプションは、ポイントツーポイントでもポイントツーグループであってもよい。分散したサービスは、「ドメインＸ内の任意のサーバに障害が起こったら教えてほしい」あるいは「アプリケーションＹがインストールされたドメインＸ内のすべてのマシンへのすべてのセキュリティ妨害の記録をとってほしい」というシナリオに関係する。このため、分散型アプリケーションは、個々のマシンで発生するイベントではなく、サーバフェデレーション１２０の一部であるマシン群で発生するイベントに関係する。これらのシナリオでは、サブスクリプションを一度定義してグループ内のすべてのマシンあるいは一部のマシンに自動的に分散させ、新しいマシンがグループに入ってきたときにはサブスクリプションがそのマシンに自動的に適用されることが必要とされる。
【０１２１】
グループにおける分散したイベントのサブスクリプションは、ディレクトリコンポーネント１５０によって提供される分散した名前空間にあるオブジェクトによって表される。このオブジェクトは、転送サービスにイベントの送信先を指示するルーティング設定も含むことができる。新しいマシンが集団に入ってくると、分散した名前空間の可用性により、すべてのサブスクリプションが配置され、イベントがサブスクライバに流入し始めることが保証される。
【０１２２】
サブスクリプションの構築者は、各自のサブスクリプションに必要とされるサービス品質（「ＱｏＳ」）を指定することができなくてはならない。イベントコンポーネント１５５はメッセージングコンポーネント１６０と協働して、適切な搬送パラメータを使用し、そのビジネスの残りをそれに応じて実施することによりそのＱｏＳが満たされることを保証する（例えば、保証された配信が指定される場合は、すべての内部キューはＱｏＳに固執しなければならないなど）。
【０１２３】
この環境で生成されるイベントの数はかなり多くなる可能性がある。このため、イベント配信のコストにより著しい動作上のオーバーヘッドが生じる恐れがある。パブリケーションサービスがシステムのスケーリングを行うために、要求する者がないイベントはイベント寿命の可能な限り早い段階で破棄しなければならない。これを行うために、効率的なフィルタリングサービスが、存在する（ｏｕｔｓｔａｎｄｉｎｇ）サブスクリプションに照らしてイベントの妥当性を迅速に確認する。しかし、既存のサブスクリプションの数も非常に多い可能性がある。このため、フィルタリングサービスは、決定木などの機構に基づく効率的な逆クエリエンジンを使用する。
【０１２４】
フィルタリングイベントに加えて、イベントフィルタリングエンジンは、サブスクリプションの分析サービスをパブリッシャに提供する。このサービスは、サブスクライバがそのパブリッシャのイベントに興味を示したとき、およびもはや興味を示す者がいなくなったときにパブリッシャに通知する。パブリッシャが、無用なイベントを供給する代わりに、実行可能な任意のフィルタリングを行うための対策がなされる。
【０１２５】
分散したイベント駆動型のサービスには、イベントが特定の順序で起こるか、特定のデータ状態と重ならない限り、個々のイベントにほとんど重要性がないシナリオが含まれる。こうしたシナリオの例は、「すべてのバックアップコントローラがダウンしたら通知する」、「低負荷時にサーバが５回停止したら通知する」、あるいは「ユーザが約５秒以内に選択をせずに６個以上のメニューを訪れる状況を識別する」などである。これらの組合せを検出するために、システムはイベントとデータをコンポーズする。
【０１２６】
イベントコンポジションサービス６０８は、イベントとデータ条件によって駆動される状態機械でよい。一実施形態では、状態遷移を記述するオブジェクトの組合せとして各コンポジションサービスを内部で設定する。サービスの一部はかなり複雑であることが考えられるので、コンポジション言語またはテンプレートを提供してコンポジションサービスの設定タスクを簡略化することができる。次に挙げるのは例示的なシナリオである。同様のイベントの集約（例：「サーバのシャットダウンから５分未満に発生したものを除いて、自分の企業のいずれのＳＱＬサーバで発生するすべての処理障害イベントをページャで知らせてほしい」）；イベントとデータのコンポジション（例：「別の電子メールを読んでいるときに電子メールが届いた場合はそれを知らせないでほしい」）；時間の経過にわたりイベントから状態を計算する（例：「前日の自分の電子メールキューはどんな動向だったか」）；計数とハートビート監視（例：「５分以内にマウスの動きがなく、キーが押されなかったら通知してほしい」）。
【０１２７】
（Ｇ．メッセージング）
本発明のメッセージングコンポーネント１６０は、クライアントデバイス１１０とサーバ１４０が通信することを可能にする。用語「メッセージ」は、動作環境１００のアプリケーション間またはその他のコンポーネント間で交換される構造化データを指す。メッセージングの例には、アプリケーション間のメッセージング、個人間のメッセージング（電子メール）、および連携的アプリケーションが含まれる。好ましい実施形態によれば、メッセージングコンポーネント１６０はＨＴＴＰに対応しており、ＤＭＺ、負荷バランシングサーバ、およびＮＡＴサービスを含むファイアウォール設定と互換性がある。
【０１２８】
相互運用性を容易にするために、メッセージングコンポーネント１６０は、ＨＴＴＰ、ＳＭＴＰおよび／またはその他のトランスポートの最上層に位置する共通のメッセージングアプリケーションプログラムインタフェース（ＡＰＩ）とサービスのセットを提供して、基礎となるトランスポートに関係なくメッセージングアプリケーションに共通のセマンティクスを提供する。このようにして、トランスポートが共通のメッセージングＡＰＩと互換性がある限り、特定のデバイスと関連付けられたトランスポートプロトコルに実質的に関係なく、インターネットと他の広域ネットワークを活用して効率的でユビキタスなメッセージングを提供する。
【０１２９】
さらに、メッセージングコンポーネント１６０は、ユーザ数と、サポートできる接続デバイス数の両方において、またこのコンポーネントの使用が可能なデバイスまたはネットワークのタイプにおいても高度な拡張性がある。すなわち、メッセージングコンポーネント１６０は、小型の無線デバイスから「メガスケール」のネットワークおよびメッセージングシステムにわたるデバイスやシステムでの使用に容易に適合する。この拡張性機能の特徴は、小型のデバイスが高度な分散サービスだけでなく高いサービス品質（ＱＯＳ）のメッセージ交換に参加することを可能にするメッセージングアプリケーションをメッセージングプラットフォームに構築できる点である。すなわち、メッセージングコンポーネント１６０は、サーバ上で高度な拡張性を持ち、また小型のデバイスに合わせて縮小することも可能であることから、適当な「スモールフットプリント」のサブセットを構築することができる。
【０１３０】
従来のメッセージングシステムと異なり、本発明のメッセージングコンポーネント１６０はプラットフォームメッセージングアーキテクチャを利用する。このメッセージングサービスは、階層的な製品ではなく、本発明のメッセージングサービスを操作するエンティティ、あるいはサードパーティが、例えばイベントコンポーネント１５５によって提供される分散イベンティングなど新しいアプリケーションとメッセージベースのサービスを書くことができる基本プラットフォーム基盤として存在する。メッセージングコンポーネント１６０は、インターネットベースのプロトコルを認識および包含して、新しいプロトコルと既存のプロトコルを共通の方式で利用するような形で定義される。さらに、メッセージングコンポーネント１６０は、確実に１回限りの順序に従ったメッセージ配信を行う、非同期、コネクションレス型、ストアアンドフォワード型の信頼性できるメッセージングを提供する。
【０１３１】
メッセージングシステムが特定のメッセージタイプ、メッセージ内容、あるいはサービスプロトコルを認識する、または依存するのと対照的に、メッセージングコンポーネント１６０は、アプリケーションまたはサービスによって定義されるメッセージ「ブロブ（ｂｌｏｂｓ）」を確実に配信することを目標とする。メッセージングコンポーネント１６０は、データに依存するルーティングスキーマや、トピックまたは主題に基づくパブリッシュ／サブスクライブのインフラストラクチャ、他のメッセージング変換サービスを直接には実装しない。
【０１３２】
メッセージングコンポーネント１６０は、分散されたイベントサポートのトランスポート層に適切な基盤を提供する。メッセージングサービスにはさらに追加機能を補うことができるが、本発明は、メッセージングサービスが完全な統合されたイベントシステムを定義しなくとも実施することができる。さらに、メッセージングサービスは、統合された高レベルの発見メッセージエンドポイント発見サービスを定義する必要がない。
【０１３３】
次いでメッセージングコンポーネント１６０の一実施形態について図６を参照してより詳細に説明する。アプリケーション、ユーザ、ハードウェアなどのための信頼性があり柔軟なメッセージングに対する必要性を満たすために、メッセージングコンポーネントはすべてのメッセージングアクティビティのための共通のＡＰＩ７０２を含む。ＡＰＩ７０２は、共通の開発者インタフェースを公開し、認証、アクセス制御、およびサービス品質の保証など共有される機能の共通の実装を提供する。メッセージングコンポーネント１６０はまた、メッセージングアプリケーション７０４、ゲートウェイ７０６、ルーティング７０８、ＨＴＴＰ通信サービス７１０、およびトランスポート７１２を含むことが好ましい。これについては下記で詳細に説明する。
【０１３４】
図６にキューベースのＡＰＩ＆サービス７０２と示す層（以降ＡＰＩ７０２または層７０２）は、異なるトランスポートと共通のサービスにわたり共通インタフェースを提供する。ＡＰＩ７０２は、開発者が、いくつかのＵＲＬ名前空間の１つにあるＵＲＬによって識別できる宛先にメッセージを配信することを可能にする単純なプログラミングモデルを確立する。好ましい実施形態では、ＡＰＩ７０２の基本的な宛先の構築は、本出願人（ワシントン州レドモンド）の開発による既存のＭＩＣＲＯＳＯＦＴ（登録商標）Ｍｅｓｓａｇｅ Ｑｕｅｕｅ（ＭＳＭＱ：マイクロソフトメッセージキュー）キューベースのＡＰＩと同様にキューにすることができる。
【０１３５】
本質的に各種のトランスポート７１２には同じレベルのサービスが内蔵されていないので、サービスの多くは層７０２で実装する。各種のトランスポート７１２は異なるレベルの統合サービスを有するので、層７０２と固有のトランスポート７１２との間のインタフェースはかなり高度なものになる。これは、トランスポートが認証やより高いサービス品質などの機能のための独自の機構を有する際には、それを使用することが望ましいからである。ただし、単に任意メッセージのベストエフォット型の配信をサポートする任意のトランスポート７１２の上部にはすべての基本的機能も提供される。
【０１３６】
本発明の一実施形態によると、層７０２には、メッセージ配信に対する一定範囲のサービス品質を関連付けることが好ましい。例えば、エクスプレスＱＯＳは、メッセージホストの再起動に対して回復力のない、高性能のインメモリベースのメッセージングとして定義される。持続性のＱＯＳは、少なくとも１回の配信の保証を提供するディスクベースのメッセージングである。確実に１回／順序付きのＱＯＳは、確実に１回の順序付けられた配信（複製は識別して削除し、順序外れの到着は拒否する）を提供する持続性のメッセージングに関連する。
【０１３７】
層７０２のセキュリティサービスは、セキュリティコンポーネント１６５に基づく認証、アクセス制御、および／または秘密保持サービスを可能にすることができる。例えば、認証は、ユーザベースあるいはマシンベースの終端間モデルに従った証明書に基づくことができ、あるいは、ＸＭＬＤＳＩＧや、ＭＳＭＱ、Ｓｅｃｕｒｅ Ｍｕｌｔｉｐｕｒｐｏｓｅ Ｉｎｔｅｒｎｅｔ Ｍａｉｌ Ｅｘｔｅｎｓｉｏｎｓ（Ｓ／ＭＩＭＥ）、他の適切な認証システムを含む他のモデルに従って提供することができる。アクセス制御（すなわち、どの者に配信とキューの操作を許可するか）は、メッセージ認証で確立されたクリデンシャルに基づいてユーザ指向型の方式で制御することができる。秘密保持サービス（すなわち暗号化と解読）は、ＨＴＴＰＳを通じて可能になるホップツーホップの秘密保持を用いて確立することができ、これは中間サーバを信頼することを示唆する。終端間の秘密保持は鍵交換プロトコルを用いることにより可能にすることができる。
【０１３８】
本発明のメッセージングコンポーネント１６０は、各種の既存のトランスポートおよび今後開発されるトランスポートのいずれとも動作するように適合することができる。実際、異なるトランスポートと相互運用する能力は、ＡＰＩの設計と存在の主要目的である。他のトランスポートを使用してもよいが、図７では、４つのトランスポート７１２と併せてＡＰＩ７０２を使用するものと具体的に示している。これらは、到達と機能性を最大にするトランスポートプロトコルの例である。ＨＴＴＰ／ＨＴＴＰＳ ７１２ａは、ＳＯＡＰベースのメッセージ表現を使用するトランスポートプロトコルである。ＭＳＭＱバイナリトランスポート７１２ｂは、豊富なＱＯＳのセットをサポートする。ＭＳＭＱは例えば、圧縮され、メッセージ内容への構造化されたアクセスを可能にする高度に最適化されたバイナリ形式を提供する。マルチキャストトランスポート７１２ｃは、多大な受信者の拡張性により、単純なメッセージングを必要とするアプリケーションをサポートする。ＳＭＴＰトランスポート７１２ｄは、従来のＳＭＴＰモデルと十分な適合性のあるアプリケーションのために提供される。より大きなメッセージサイズや、電子メールトラフィックに典型的な他のシナリオもＳＭＴＰに適している。さらに、ＳＭＴＰには、既存のインフラストラクチャを使用することが望ましいビジネス間（「Ｂ２Ｂ」）アプリケーションにとって有用となる特性（プロトコルと配置の現実性の両方において）がある。ＳＭＴＰはすぐれた性能を備え、基本的な「少なくとも１回」のサービス品質と単純な認証をサポートするが、追加機能のレベルはかなり低い。
【０１３９】
ゲートウェイ７０６は、組み込み型のトランスポート７１２とは多少異なる扱いを受ける。トランスポート７１２は一般に、サードパーティが新しいコンポーネントを追加することができる完全にプラグ可能なモデルはサポートしない。ゲートウェイ７０６は代わりに、ＵＲＬ名前空間の一部についてのメッセージトラフィックを受信する。ゲートウェイ７０６は次いで、ＭＱＳＥＲＩＥＳ（登録商標）やＧＲＯＵＰＷＩＳＥ（登録商標）電子メールコネクタなど他タイプの通信システムに接続することができる。
【０１４０】
メッセージングコンポーネント１６０は、相互運用が可能で安全かつ透過な方式で複数パーティ間のメッセージ交換を可能にする。これを行うために、共通の自己記述型の言語がメッセージングのメタデータとペイロードをカプセル化する。好ましい実施形態では、これらの要件に対応する記述言語としてＸＭＬを使用する。
【０１４１】
メッセージングアプリケーション７０４が基礎となるメッセージングコンポーネント１６０に継ぎ目のない形で価値を付加することを可能にするには拡張性が重要である。例えば、プロトコルは、アプリケーション固有のモジュールを導入するための汎用機構を備えていなければならない。この例には、メッセージの追跡、ロギング、およびデータ変換がある。これは、メッセージをカプセル化するＸＭＬドキュメントにアプリケーション固有の要素を挿入するための規格として公開されているはずである。
【０１４２】
好ましい実施形態では、メッセージングコンポーネント１６０はトランスポートとしてＨＴＴＰを使用し、これによりローカルの「ＨＴＴＰプロキシ」サービスが利用できるようになる。同様に、標準的なＨＴＴＰのセキュリティ機構（ＳＳＬ）もメッセージングコンポーネント１６０により使用することができる。
【０１４３】
スケーリングのために、メッセージングコンポーネント１６０は利用可能な負荷バランシングサービスを利用することができる。より低いサービス品質では、メッセージングは基本的にステートレスで、したがって用いられる基礎的な負荷バランシング機構は透過である。しかしより高いＱＯＳは本質的にステートフルなので、メッセージングサービスは、外部機構（アプリケーション固有）と内部機構（メッセージングインフラストラクチャによって生成される）の両者を含む、複数のメッセージ交換にわたって状態を保持する機構を提供する。これを行うために、メッセージングコンポーネント１６０は、終端間の配信セマンティクスがそれに対して保存される単一のバックエンドメッセージストアと、外部アドレスから内部メッセージストアアドレスへのマッピング機能を使用することができる。このマッピング機能は、イントラネットに配置することができ、同時にインターネットの存在を提供する「着信メッセージングプロキシ」サービスによって提供することができることに留意されたい。
【０１４４】
一般に、トランスポートとしてＨＴＴＰを使用するメッセージングホストには、メッセージを送受信する能力が必要である。これは、そのようなホストがＨＴＴＰの「リスニング」サービスと「トーキング」サービスの両方を有することを意味する。好ましい実施形態では、汎用のリスナが、基本的なサーバサイドのＨＴＴＰプロトコルサポートを提供する。汎用リスナは、マシン上のすべてのＨＴＴＰサーバが共有するシステムコンポーネントであり、汎用リスナＡＰＩ（ＵＬ ＡＰＩ）を介してすべてのサーバアプリケーションに代わってポート８０を管理し、受信する要求をアプリケーションに提供（ｓｕｒｆａｃｅ）する。サービスとアプリケーションは、ＵＬ ＡＰＩを使用して直接各自の処理環境中に要求を受信することができる。システムによって管理されるプロセス内で要求にサービスすることを希望するサーバアプリケーション（例えばアクティブサーバページ）には、任意選択のプロセス管理機能が提供される。
【０１４５】
汎用リスナは、マシン上のすべてのＨＴＴＰベースのサーバアプリケーションが共有するカーネルモードリスナを提供する。すべてのアプリケーションは効率的にポート８０を共有することができる。汎用リスナは解釈を要求し、静的な内容と「不変の」動的な内容を高性能配信するための応答のキャッシュを提供することもできる。アプリケーションは、構成とＵＬ ＡＰＩを介してキャッシングを制御することができる。キャッシュされた応答は、ユーザモードに入らずに配信することができる。
【０１４６】
汎用リスナはさらに、最も長くマッチするＵＲＬのプレフィクスに基づいて、ユーザモードの「ワーカープロセス」に要求を送信することができる。このユーザモードのアプリケーションは、コアリスナコンポーネントと完全に分離している。ワーカープロセスは、「ＵＬ ＡＰＩ」を使用して要求を受信し、それに応答することができる。さらに、ワーカープロセスは、ＵＲＬ名前空間の複数の部分にサービスする。複数のワーカープロセス（「ガーデン」）が同じアプリケーションセットにサービスすることができ、拡張性、可用性、およびアプリケーション間の分離を高める。
【０１４７】
ＨＴＴＰサーバプロセスマネジャは、ワーカープロセスの管理のためにＵＬと併せて任意選択で使用することのできるシステムコンポーネントである。プロセスマネジャは、ワーカープロセスのオンデマンドの起動（すなわち着信する要求によってトリガされる）を提供する。プロセスマネジャはまた、ワーカープロセスの「正常性の監視」と、ワーカープロセスの「サイクリング」（シャットダウン／再起動）を確立して、漏洩、サーバのハングアップなどから回復することもできる。サイクリングは、時間、受信した要求の数、あるいは正常性モニタリングの結果によってトリガすることができる。さらに、プロセスマネジャは、構成とコントロールのための管理インタフェースと持続性のある構成を提供することができる。
【０１４８】
一実施形態では、ＨＴＴＰクライアントはカーネルモードで実装される。カーネルモードで実装する理由には、１）性能、２）カーネルコンポーネントとの通信、および３）リスナ／トーカの統合、が含まれる。リスナ／トーカの統合の利点としては、性能の最適化と実装の共有が挙げられる。
【０１４９】
メッセージングシステムは任意選択でＨＴＴＰプロトコルの拡張を実装することができ、これに対するサポートはリスナとトーカ双方の実装で確立することができる。拡張の１つは、ＨＴＴＰ接続管理を強化してより効率的な接続の多重化をサポートする「ｗｅｂ ｍｕｘ」に関連し、これは特に高容量のＢ２Ｂシナリオで有用である。
【０１５０】
上述のように、メッセージングコンポーネント１６０は、ＨＴＴＰを含む各種のトランスポートのいずれを使用して、効率的で信頼できるメッセージングを提供する。メッセージングコンポーネント１６０は、情報を渡すために他の技術プラットフォームコンポーネントによって使用される。メッセージングコンポーネント１６０は、開発者がアプリケーションを書き、メッセージングサービスのアーキテクチャ全体と本発明に関連する他の機能を活用することができる標準インタフェースを確立する。
【０１５１】
（Ｈ．ストレージ）
分散コンピューティングサービスプラットフォーム１５５のストレージコンポーネント１４５の説明では用語「データエンジン」を参照するが、これは、汎用または特殊目的のコンピューティングデバイスからのアクセスが可能な、コンピュータ実行可能命令またはデータ構造の形で所望のプログラムコード手段を担持または記憶するのに使用できる任意の媒体を指す。
【０１５２】
データエンジンは、多種のデバイスと関連付けることができる。例として、データエンジンは、任意のクライアントデバイス１１０（図１に関連して上記で挙げたデスクトップＰＣ、ラップトップコンピュータ、携帯情報端末（「ＰＤＡ」）、携帯電話、ページャクライアントなど）と関連付けることができる。データエンジンはまた、例えばアプリケーション、オーディオ、データベース、ファックス、ファイル、イントラネット、メール、商人、モデム、ネットワークアクセス、印刷、プロキシ、リモートアクセス、電話機、端末、ビデオ、あるいはウェブサーバなどのサーバデバイス１４０とも関連付けることができる。これらのサーバは、サーバフェデレーション１２０内に配置することができる。
【０１５３】
図７は、ストレージコンポーネント１４５の例示的なアーキテクチャを示し、ここではデータエンジンの使用、データのアクセス可能性、および１以上のアプリケーションの実行を扱っている。ストレージコンポーネント１４５は、一般には各特定の領域を利用するエンティティのタイプに従って特徴付けられる３つの領域に分けることができる。図７では、この領域を領域８０２、８０４、および８０６と示している。例として、ユーザは一般に領域８０２を利用し、開発者は一般に領域８０４を利用し、管理者は一般に領域８０６を利用する。
【０１５４】
ストレージコンポーネント１４５の基礎は、例えばＭＩＣＲＯＳＯＦＴ（登録商標）のＷＩＮＤＯＷＳ（登録商標）オペレーティングシステムなどのオペレーティングシステムのファイルシステムである。図８では、このファイルシステムをファイルシステム８０８と示している。
【０１５５】
データエンジン８１０はストレージコンポーネントの中心である。好ましい実施形態では、データエンジン８１０は、マイクロソフト社製のＳＱＬ Ｓｅｒｖｅｒに基づくＳＱＬサーバストレージエンジンである。データエンジン８１０の上部には、例えばマイクロソフト社製のＥｘｃｈａｎｇｅ Ｓｅｒｖｅｒに基づくＥｘｃｈａｎｇｅ Ｄａｔａ Ｍｏｄｅｌ（図示せず）など、例えばＸＭＬデータモデル、リレーショナルデータモデル、メッセージングデータモデル（電子メール、カレンダー、グループ生産性）などの各種データモデルが構築されている。データエンジンは、最も効率的な形式でデータを記憶する。データエンジンの上層に位置するデータモデルやエンジンは、どのように記憶データにアクセスし、正しいビューを開発者に提示するかを理解している。データは、例えば表、階層、あるいは一連の名前／値の対など、複数の形式で提示することができる。データモデルは１以上のエンジンを含むことができる。例として、ＸＭＬデータモデルはＸＭＬエンジン８１２を含む。同様に、リレーショナルデータモデルはリレーショナルエンジン８１４を含む。
【０１５６】
開発者は、データベースプログラミング言語（「ＤＢＰＬ」）技術を使用して、共通の照会システムを通じて各種のデータモデルと通信する。ＤＢＰＬ技術は、アプリケーションプログラムがシステムとの通信に使用する形式であるデータアクセス用アプリケーションプログラミングインタフェース（「ＡＰＩ」）８１６を含む。この形式は、実行のために必要とされるサブルーチンへのリンクを提供する関数呼び出しを用いる。好ましい実施形態では、ＤＢＰＬ技術はＸＭＬ（ＸＭＬ８１８）に基づき、リレーショナルモデル（リレーショナル８２０）を使用することができ、オブジェクト技術（オブジェクト８２２）を利用する。
【０１５７】
領域８０２として図に示す最上層は、ユーザ／消費者が使用する各種のアプリケーション８４０ａ、８４０ｂなどを含む。これらのアプリケーションは、例えばドキュメント、メール、予定表項目、連絡先、株のポートフォリオ、消費者、その他、媒体ベースの製品カタログなどの統合を行わせる。これらのアプリケーションは、各種のデータモデルの上部に位置し、固有のプロトコル８２４を使用してシステムと通信する。好ましい実施形態では、プロトコル８２４はシンプルオブジェクトアクセスプロトコル（ＳＯＡＰ： Ｓｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）８２４である。
【０１５８】
好ましい実施形態では、ストレージコンポーネント１４５のコンポーネントは、統一技術としてのＸＭＬに基づき、すべてのタイプのデータがＸＭＬドキュメントとして扱われる。サーバフェデレーション１２０と、本発明の分散コンピューティングサービスプラットフォーム１１５に関連する通信は、ＸＭＬを基盤として構築される。メッセージ、メソッド呼び出し、オブジェクトの記述、およびデータエンジンにはすべてＸＭＬを使用する。クエリ（ｑｕｅｒｙ）言語は階層に機能し、階層的なＸＭＬを戻す。ストレージコンポーネント１４５はＸＭＬに基づくので、ストレージと照会動作は、表形式からドキュメントまでデータの範囲全体にわたって同じものになる。
【０１５９】
ストレージコンポーネント１４５は、本明細書で「メガストア」と称するストレージ機構を可能にする主要コンポーネントである。メガストアでは、図１のサーバフェデレーション１２０は、エンドユーザから見て統一されたストレージ機構として機能する。メガストアについては下記のシナリオで実例を挙げて説明する。ユーザはＰＣに近づき、ログオンする。このログオンにより、セキュリティコンポーネント１６５によって提供されるインターネット認証サービスでユーザが認証される。ユーザが認証されると、ディレクトリコンポーネント１５０を使用してそのユーザの情報がどこに記憶されているかを判定することができる。ストレージコンポーネント１４５は次いでデータを取り出し、それをユーザインタフェースコンポーネント１４０に提供する。したがって、それ以上のユーザの介在を必要とせずに、パーソナライズされた情報が履歴のリスト、お気に入りのリスト、受信箱などのユーザインタフェースに表示される。このように、ユーザがデバイスからデバイスに移動すると、そのデータとアプリケーションがその後を追っていく。
【０１６０】
メガストアは、エンドユーザコンポーネントと開発者コンポーネントを含む。エンドユーザは単に、あるサイトにログオンすると、自分のために記憶されている自分の個人データと情報が自動的にアクセス可能になると理解している。このように、ユーザは、自分の個人データと情報が例えばクッキーやサーバフェデレーション１２０中のいずれかのサーバに記憶されているかどうかを気にかける、あるいは理解する必要がない。ユーザは、自宅、職場、あるいはその他の場所であろうと、どこへ行っても自分の個人データと情報に容易にアクセスできることを理解していればよい。
【０１６１】
（Ｉ．ディレクトリ）
ディレクトリは従来、実際にはデータがしばしば企業中に分散されている際に、組織化された構造にデータが区分されているという錯覚を生み出す企業規模の命名機関である。ディレクトリが含むことのできるデータの例には、エンティティ（例えばユーザ、コンピュータ、ユーザのグループなど）に関する連絡先情報などのアドレス帳データ、エンティティの認証に使われる認証データ、およびエンティティ単位でオブジェクトへのアクセスを制御するのに使用される承認データがある。２種類のディレクトリには、適合ディレクトリとメタディレクトリがある。
【０１６２】
適合ディレクトリは、多くの場合１以上の特定の目的に合わせて適合されるデータストアである。しばしば、このディレクトリの機能はアプリケーションに固有のものになる。適合ディレクトリに記憶された情報は、信頼できるデータ、すなわち「真実」データ（すなわち他のソースから同期されていないデータ）であるが、適合ディレクトリは冗長データ（すなわち他のソースから同期されたデータ）も記憶することができる。適合ディレクトリの例は下記で挙げる。
【０１６３】
メタディレクトリは、適合ディレクトリまたはその他のメタディレクトリにあるオブジェクトのサブセットを含む、あるいは保持するデータストアである。メタディレクトリは、オブジェクトごとに、そのオブジェクトの属性のサブセットを保持する。メタディレクトリは、オブジェクトについてのより完全な情報を含むディレクトリへの参照も含む。メタディレクトリの例も下記で挙げる。
【０１６４】
明確なスキーマを有する適合ディレクトリとメタディレクトリは、明確なスキーマを持たないディレクトリに比べて同期が容易である。メタディレクトリに記憶された情報はしばしば、各種の適合ディレクトリの関連項目間の関連付けに関係するので、適合ディレクトリとメタディレクトリの同期は有用である。多くの場合、メタディレクトリに記憶されたデータは誰でも利用する、あるいは読み出すことができる。ただし、事例によっては、より高いセキュリティが必要とされ、メタディレクトリへのアクセスをより制御することがある。
【０１６５】
サーバフェデレーション１２０全域にわたる連携と通信を可能にするために、ディレクトリコンポーネント１５０は、ポータル単位またはウェブサイト単位のメタディレクトリに、メタディレクトリ間の同期を提供することが好ましい。ディレクトリコンポーネント１５０は、適合ディレクトリとメタディレクトリ両方の使用を含む。
【０１６６】
図８は、本発明によるディレクトリコンポーネント１５０を示す。ディレクトリコンポーネント１５０は、個人またはエンティティに固有の、ここで「マイステート」ディレクトリと称する適合ディレクトリ９０５を含む。マイステート適合ディレクトリ９０５は、名前、アドレス、電話番号など個人またはエンティティについての情報を記憶するために使用される。
【０１６７】
個人は複数のアイデンティティを有する場合があるので（例えば家庭／私的なアイデンティティと、職場／仕事上のアイデンティティ）、マイステートディレクトリは、所与のユーザについて複数のアイデンティティの情報を含むことができる。例えば、ユーザは、家庭用または私的なアイデンティティに固有の適合ディレクトリと、そのユーザの職場または仕事上のアイデンティティに固有の適合ディレクトリを持つことができる。家庭用のアイデンティティに固有の適合ディレクトリの一例を図８にホームプレゼンス（ｈｏｍｅ ｐｒｅｓｅｎｃｅ）ディレクトリ９１０として示す。
【０１６８】
これらの適合ディレクトリ９０５および９１０はスキーマに従って構造化する。スキーマコンポーネント１７０によって提供されるサービスを使用することにより、外部のサービスとアプリケーションはこれらの適合ディレクトリにアクセスし、拡張することができる。スキーマは、セキュリティコンポーネント１６５と協働して、ユーザが、異なるエンティティに適合ディレクトリの特定の部分または固有の部分へのアクセスを許すことも可能にする。イベントコンポーネント１５５とメッセージングコンポーネント１６０の使用により、マイステートディレクトリは、マイステートディレクトリへの変更と更新を他のエンティティに通知するだけでなく、あるエンティティとマイステートディレクトリとの関係を終了することもできる。
【０１６９】
ディレクトリコンポーネント１５０は、例えば企業ポータル９１５および９２０などのメタディレクトリを有するポータルも含んでいる。一例では、ポータルを業界規模のウェブサイトとみなすことができる。したがって、健康管理ポータル、ショッピングポータル、音楽ポータルなどがある。各ポータルは、１以上のメタディレクトリを実装して、関連するビジネスとエンティティからの情報を保持する。例えば、健康管理ポータルのメタディレクトリの一部は、これらに限定しないが医師、医院、薬局、および患者など、関連するエンティティまたは個人についての情報を含む。ポータルのメタディレクトリは、認証されたユーザごとにオブジェクトを保持または記憶する。各オブジェクトは例えば、それらのメタディレクトリにアクセスするユーザはしばしば認証することになるため、ユーザから提供される承認情報を含むことができる。ポータルはまた、他のポータルと適合ディレクトリとの関係を同期する。例えば医師の適合ディレクトリは、その個々のメタディレクトリを通じて、または健康管理ポータルにより、患者の適合ディレクトリと同期することができる。
【０１７０】
ディレクトリコンポーネント１５０は各種の企業を包含することが好ましい。図を簡潔にするために、図９にはその企業の１つ（企業９２５）のみを示している。企業９２５は、内部メタディレクトリ９３０と、現在の企業が従来含んでいるような内部適合ディレクトリ９３５を含む。したがって、企業がディレクトリコンポーネント１５０から提供される膨大なディレクトリサービスを利用するには、企業ポータル９２５などのポータルの使用に移行するだけでよい。内部企業が移行して企業ポータルになることを可能にすることにより、サードパーティがより容易にそのエンティティの情報にアクセスできるようになる。
【０１７１】
ディレクトリコンポーネント１５０は、インターネットメタディレクトリサービス９４０も含む。インターネットメタディレクトリサービスは、特定スキーマを有するデータやドキュメントをインターネットで検索することができる。このディレクトリは、ある会社が販売する製品、ある会社が提供するサービスなどの情報を含むことができる。各ドキュメント（またはそのサブセット）は、そのドキュメントのＵＲＬとともにメタディレクトリに組み込まれる。したがって、インターネットメタディレクトリ９４０にアプリケーションやサービスがアクセスすると、それらが必要とする情報やサービスにそのアプリケーションやサービスを差し向けることができる。
【０１７２】
ディレクトリコンポーネント１５０は、必要に応じてポータルに認証サービスを提供するインターネット認証サービス９４５（セキュリティコンポーネント１６５によって提供される）を使用することができる。インターネット認証サービス９４５の一例は、マイクロソフト社提供のＰａｓｓｐｏｒｔと称されるものである。
【０１７３】
図９は、各種の適合ディレクトリとメタディレクトリ間のインタラクションを例示する。この例は、本発明の範囲を制限するものと解釈すべきでなく、本発明によって可能になる機能の一部の一例である。この例は、新しい従業員が新しい雇用主のもとで働き始める場合である。雇用主は、雇用主のメタディレクトリ１０２４を含む企業ポータル１０２２を有する。従業員が勤務を開始すると、従業員の記録ディレクトリ１００２が、これもこの例では雇用主によって維持される適合ディレクトリ１０００に追加される。したがって、従業員の記録ディレクトリ１００２は、その従業員についての信頼できるデータをスキーマに従って含む適合ディレクトリである。
【０１７４】
従業員の記録ディレクトリ１００２は、従業員を雇用主のメタディレクトリ１０２４に追加し、雇用主のメタディレクトリ１０２４に複数の属性を供給（ｐｒｏｍｏｔｅ）する。これらディレクトリ間の情報は、Ａｕｔｏｍａｔｅｄ Ａｔｔｒｉｂｕｔｅ Ａｇｒｅｅｍｅｎｔ（ＡＡＡ）によって同期する。したがって、雇用主のメタディレクトリ１０２４は、関連付けられた属性１０２０を有する従業員オブジェクト１０１８を有し、この属性は従業員記録ディレクトリ１００２に記憶された信頼できるデータに関連する冗長データを含んでいる。雇用主メタディレクトリ１０２４は、同じく適合ディレクトリであるメールディレクトリ（図示せず）、ワークカレンダーディレクトリ１０１０、およびワークプレゼンス（ｗｏｒｋ ｐｒｅｓｅｎｃｅ）ディレクトリ１００４を設定する。
【０１７５】
次いで、新しい従業員はセキュリティオフィスに行き社員証をもらう。従業員は携帯情報端末（ＰＤＡ）または他のデバイスを使用して、例えばパスポートキーを有する別の適合ディレクトリである既存の認証ディレクトリ１００８に登録する。すると認証ディレクトリ１００８が、雇用主のメタディレクトリ１０２４にあるその従業員のアイデンティティすなわちオブジェクト１０１８にリンクされる。
【０１７６】
従業員は、ＰＤＡデバイスに、常に最新のアドレス、電話番号などの個人情報を雇用主に提供するように指示する。これは、マイステートディレクトリ１００６と雇用主メタディレクトリ１０２４との間にＡＡＡを確立することによって行う。マイステートディレクトリ１００６も適合ディレクトリである。この結合により、従業員のＰＤＡは雇用主のメタディレクトリ１０２４を使用して、ワークプレゼンスディレクトリ１００４のプレゼンスサーバを見つけ、とそのプレゼンスサーバとインタフェースをとる、あるいはそのサーバに登録して、従業員のユニバーサルな受信箱へのアクセス権を得ることができる。
【０１７７】
これらの関連付けと接続を行うと、従業員は従業員の記録ディレクトリ１００２から、健康業者を選択するよう要求する電子メールを受信することができる。従業員の選択は、雇用主のメタディレクトリ１０２４に記憶される。次いで、雇用主のメタディレクトリ１０２４は、健康業者のポータル１０１６と健康業者のメタディレクトリ１０２６に接続して、その従業員の項目を作成する。したがって、健康業者のメタディレクトリは、その従業員のオブジェクト１０１２と属性１０１４を備える。雇用主のメタディレクトリ１０２４と健康業者のメタディレクトリ１０２６間のＡＡＡの取り決めは様々な項目を含むことができる。例えば、この取り決めは、定期的な会計検査や、健康業者のメタディレクトリに変更を転送するという雇用主のメタディレクトリの同意を含むことができる。
【０１７８】
健康業者のメタディレクトリ１０２６は、主要な自動車の提供業者を選択するように求めるウェブページを従業員に送信する。これに対して、従業員は医師のリストを提供するように健康業者のメタディレクトリ１０２６に要求する。医師が選択されると、健康業者のメタディレクトリ１０２６はその医院または医師のポータルに接触して、医院のメタディレクトリ１０２８にその従業員の項目を作成する。医院のメタディレクトリ１０２８は、従業員の医療記録を要求する電子メールを従業員に送信する。従業員は、マイステートディレクトリ１００６の医療情報の部分だけを医院のメタディレクトリ１０２８に公表することができる。これにより、従業員と医院の双方が完全な記録のセットを保持することが可能になる。これと同時に、従業員は予定表を医師と共有することを許可し、医師もそれに賛同することができる。最後に、医院のメタディレクトリ１０２８はその相互にアクセス可能な予定表を使用して、その従業員の最初の予約を予定するようにワークフローサービスに通知することができる。
【０１７９】
したがってこの例でも、適合ディレクトリによって記憶された信頼できる情報がメタディレクトリにリンクされる。医院、雇用主、および健康業者は各種の適合ディレクトリも有することが理解される。その適合ディレクトリと、それとメタディレクトリとのインタラクションは図１０には示していない。メタディレクトリは、信頼できる情報に関連する冗長な情報または示唆情報を記憶することができる。適合ディレクトリのスキーマは、他のメタディレクトリが、適合ディレクトリの特定部分にアクセスすることを可能にすることができる。信頼できる情報と冗長な情報を同期して、データが確実に最新のものになるようにする。
【０１８０】
図９で、適合ディレクトリ１０００の各適合ディレクトリは、特定の目的または目的のセットを有する。従業員の記録ディレクトリ１００２は職場でのアイデンティティを表し、一方マイステートディレクトリ１００６は私的あるいは家庭用のアイデンティティを表す。認証ディレクトリ１００８の適合ディレクトリは、個人を認証する際に用いるパスワード等などの情報を含むことができる。ワークカレンダーディレクトリ１０１０は予定表または連絡先リストである。この例に示すように適合ディレクトリとメタディレクトリを使用することにより、エンティティ間の通信を改良することができる。従業員は各個別のポータルとインタラクトする必要がないので、この例では通信が強化される。ディレクトリコンポーネント１５０は、それらがすべてメッセージングコンポーネント１６０を介して接続され、リンクされているので、通信が自動的に行われることを可能にする。
【０１８１】
（Ｊ．セキュリティ）
前述のように、過去数年の間に消費者、ビジネス同様にインターネットを急速に採用するようになっており、それに伴ってインターネットを利用したサービスの使用が急激に増加している。本発明は、ウェブサイト間の通信を増加させ、より多大なインターネットの接続性と連携を可能にする。遺憾なことに、インターネットとインターネットを利用したサービスのユーザ数が増加するのにつれて、消費者とビジネスはセキュリティとプライバシーの問題について懸念を深めている。例えば、多くの消費者とビジネスは、消費者とビジネスのオンラインでの行動をかなり詳細に追跡することができる各種のインターネットサービスプロバイダ（ＩＳＰ）に依存している。多くの消費者はまた、複数のサービスプロバイダを使用し、それらに対して広く異なるビジネス関係や暗黙の信頼（サブスクリプション、一時的な取引、なし）を有している。さらに、「常時接続」のインターネット接続（デジタル加入者回線（ＤＳＬ）、ケーブルモデム）の使用の増加と、複数のインターネット対応デバイス（パーソナルコンピュータ（ＰＣ）、携帯電話、携帯情報端末（ＰＤＡ））、および、インターネットによるインタラクションとは大きく異なる方式で相互とインタラクトする複数の家庭用のネットワークデバイスの使用の増加に伴い、消費者とビジネスはより多くの接続性を得ているが、一方で悪意のある個人やビジネスが個人情報および／または機密情報を「入手」するためのアクセスポイントの数も増加している。
【０１８２】
上記の制限を最小にするために、本発明は、例えば認証、プライバシー、およびファイアウォールのセキュリティ境界などいくつかのセキュリティ保護ツールを提供するセキュリティコンポーネント１６５を任意選択で含む。図１０は、本発明のセキュリティコンポーネント１６５の一実施形態を概略的に表す。図１０の概略的な表現はセキュリティコンポーネント１６５の任意選択機能を表すもので、本明細書に含まれる教示により当業者に理解される他の機能の応用性を制限するものではない。
【０１８３】
本発明の一態様によれば、セキュリティコンポーネント１６５は、サーバフェデレーション１２０とクライアントデバイス１１０（図１）内の情報およびデータにアクセスするエンティティの認証プロセスを行うのに使用される各種のハードウェアおよび／またはソフトウェアコンポーネントを含む認証モジュール１１０２を含む。エンティティは、例えば、幅広い設定と取引関係者を含む、消費者対ビジネスあるいはビジネス対ビジネスなど複数者間のインタラクションに関与する際に、記憶された情報とデータにアクセスすることができる。
【０１８４】
より具体的には、一実施形態で、認証モジュール１１０２は、ページコンポーネント２１０、エミッサリコンポーネント２２０、および／またはフィーフダムコンポーネント２３０（図２）へのエンティティよるアクセスを制御するハードウェアおよび／またはソフトウェアモジュールを含み、同時にそれらのエンティティのアイデンティティをシステム１００の他のユーザまたはエンティティに対して「拒絶」する、あるいは隠すことができないようにする。ここで使用する用語「エンティティ」は、ユーザ（個人あるいはグループ）だけでなく、マシン、許可を受けたソフトウェアアービター、サーバおよびプロキシサービス、各種の他のハードウェアおよび／またはソフトウェアモジュールとコンポーネントなども含む。
【０１８５】
あるエンティティが、消費者、ビジネス、ハードウェアモジュール、あるいはソフトウェアモジュールであっても、それが名乗るエンティティであるかどうかを判断するために、各エンティティは「グローバルＩＤ」と称する識別子を備えなければならない。各グローバルＩＤは、個人または他のエンティティが使用することを選択できる各種「アイデンティティ」の１つに対応する。大半の人々（他のエンティティも含む）は、少なくとも２つのアイデンティティを有する。すなわち、各自の職業（学生、何らかの組織の従業員など）に関係し、ビジネス関連の行動を行う際に使用するアイデンティティと、その他のインタラクションに使用する私的なアイデンティティである。プライバシーを守るため、あるいは自分のインタラクションの一部に関連してより高いレベルの保証を求める必要性に対応するために、ユーザは追加的なアイデンティティも使用することができる。
【０１８６】
セキュリティコンポーネント１６５は、システム１００および／またはアプリケーション２００と協働して上記のアイデンティティとそのアイデンティティに関連付けられた認証クリデンシャルを管理し、アイデンティティを個別に保つことを保証し、同時に、エンドユーザが、自分のアイデンティティが使用される方式と、各アイデンティティと関連付けられたプライバシーおよび機密性のレベルとを完全に制御することができるユーザ体験を提供する。
【０１８７】
次いで図１１を参照すると、ユーザのグローバルＩＤと各種の他の例示的サービスおよび情報との間のインタラクションを概略的に表している。一般に、セキュリティコンポーネント１６５は、様々な個人、ビジネス、マシンなどが所有する各種のグローバルＩＤ１２２０ａ−１２２０ｎと通信することができる。各グローバルＩＤ１２２０ａ−１２２０ｎは、システム１００の一部にアクセスするエンティティを認証するために使用される。グローバルＩＤ１２２０ａ−１２２０ｎは、そのＩＤが表すエンティティのプロファイルプロパティは含むことになっていない。一実施形態では、プロファイルは、ディレクトリコンポーネント１５０によって提供される上述の「マイステート」の適合ディレクトリ９０５を使用して記憶される。「マイステート」適合ディレクトリ９０５は、任意選択で、参照符号９０５ａ−９０５ｎで示す各種の部分を含むことができる。マイステート適合ディレクトリ９０５は、同意されたスキーマに従ってユーザデータを含むユーザプロファイルを記憶する場所を提供する。一般に、各グローバルＩＤ１２２０ａ−１２２０ｎは、アプリケーション内で、あるいはサイト固有のデータストアで、マイステートサービスの個々の部分に記憶されたプロファイル情報の索引を提供する。したがって、エンティティは、それぞれに異なるプロファイルが関連付けられた複数のグローバルＩＤ１２２０ａ−１２２０ｎを持つことができる。
【０１８８】
あるいは、セキュリティコンポーネント１６５の一実施形態では、ここで「グループメンバーシップ」サービス１２２４と称する、アーキテクチャが異なる別のサービスに各グローバルＩＤ１２２０ａ−１２２０ｎを関連付けることができる。サービス１２２４は、任意選択で各種の下位部分を含むことができるが、グループメンバーシップサービス１２２４の一部分だけを図に示し、参照符号１２２４ｃで表している。下位部分１２２４ｃは、１つのグローバルＩＤ、例えばグローバルＩＤ１２２０ｂが、ユーザの各カテゴリ１２２６ａ−１２２６ｎについてのプロファイルリスト内に１以上のプロファイルを有することを可能にする。あるいは、各カテゴリ１２２６ａ−１２２６ｎは、要求されるプロファイルまたは定義されたプロファイルへの１以上のポインタを含むこともできる。例えば、ビジネス間のシナリオでは、グループメンバーシップサービス１２２４を使用して、多くの業者が検討することのできる許可された購買者のリストを含めることができる。連携のシナリオでは、グループメンバーシップサービスは、プロジェクトの機密ドキュメントへのアクセスが許可された別の団体のプロジェクトメンバーを含むことができる。さらに別の実例的な例では、各グローバルＩＤ１２２０ａ−１２２０ｎが、キーをアイデンティティと結びつけアイデンティティの拒否を妨げる、１以上のデジタル署名、Ｘ．５０９証明書、ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ（ＸＭＬ）証明書あるいは「ライセンス」、またはその他の証明書フォーマットを含むことが可能である。このような場合は、これらに限らないがＭｉｃｒｏｓｏｆｔ（登録商標）のＰａｓｓｐｏｒｔ、Ｍｉｃｒｏｓｏｆｔ（登録商標）のＨｏｔｍａｉｌ、および／または各種の他のサードパーティビジネスなど各種の証明機関（ＣＡ）が上記のような証明書を発行する。
【０１８９】
再度図１０を参照すると、本発明の別の態様によれば、セキュリティコンポーネント１６５は認証モジュール１１０４を含む。認証モジュール１１０４は、各エンティティのグループメンバーシップ、役割、および権利の委託を変更することができる動的な環境で、認証されたエンティティが行うことが可能な動作を決定する各種のハードウェアおよび／またはソフトウェアモジュールとコンポーネントを含む。このため、セキュリティコンポーネント１６５の認証モジュール１１０４は、これらに限定しないがプライベートなデータや、著作権のある本、歌、および映画などの「使用許可を受けたコンテンツ」などの、規制された内容に対するエンティティの使用制限の施行を、従来の「ユーザベース」の許可モデルよりも複雑な方式でコントロールすることができる。さらに、より広く柔軟性のある認証モジュール１１０４の委託およびコントロールの機構により、従来の認証の役割が拡大される。
【０１９０】
認証モジュール１１０４が、任意選択でセキュリティコンポーネント１６５の他のモジュールと協同して認証の分野と技術で進展を達成する方法の１つは、デジタル権利の管理を用いるものである。デジタル権利管理（ＤＲＭ）は、情報とコンテンツの使用と分配に対する自動化された規則と条件の強制を伴う。ＤＲＭの中核をなすのは、従来のシステムセキュリティについての直感的な概念とは反対の前提である。典型的なシステムセキュリティでは、データや情報にアクセスする権限の起点はユーザにある。ユーザが認証されると、サービスへのアクセスはユーザのアイデンティティに基づいて許可される。このため、基礎となるユーザに権利を付与する程度までソフトウェアに権限を与える。一般には、認証されたスーパーユーザ（または管理者）には基本的にあらゆる資源への無限のアクセス権を付与する。ＤＲＭはこの前提をいくつかの点で変える。ＤＲＭでは、権限の起点はコンテンツまたは情報の所有者にある。所有者の権利（およびユーザに与えられる許可）には、標準的な言語で名前をつける。権利は、これに限定しないが、信頼されるソフトウェア、すなわち以前に認証されており所有者が指定する権利と制限を施行する義務のあるソフトウェアだけに情報へのアクセス権を与えることを保証する、各種のハードウェアおよび／またはソフトウェアモジュールやコンポーネントなどの「デバイス」によって施行される。これにより、コンテンツの所有者が、ユーザではなく、その所有者が定義する条件に基づいてコンテンツへのアクセスを制限するソフトウェアに権利を委託することが可能になる。
【０１９１】
ＤＲＭを実現することが可能な例示的な「デバイス」の１つは、Ａｕｔｈｅｎｔｉｃａｔｅｄ Ｂｏｏｔ／Ｉｓｏｌａｔｅｄ Ｅｘｅｃｕｔｉｏｎ対応型パーソナルコンピュータと呼ばれる信頼されるデバイスである。この「デバイス」は、そのハードウェアコンポーネントに固有の１以上の秘密鍵を保持する、信頼される（かつ改ざん防止型の）ハードウェアコンポーネントを含むことができる。Ａｕｔｈｅｎｔｉｃａｔｅｄ Ｂｏｏｔ／Ｉｓｏｌａｔｅｄ Ｅｘｅｃｕｔｉｏｎ対応型パーソナルコンピュータの動作では、クライアントソフトウェアが、信頼されるデバイスがそのソフトウェアのアイデンティティを認証することを要求する（例えば、そのコードをハッシュして、そのハッシュと、そのハードウェアによって「信頼される」権限者が署名したハッシュを示す証明書とを比較することによる）。認証の付随的な効果として、要求側のソフトウェアが使用する物理アドレスが分離され、他のプログラム（ＯＳを含む）は、それ以降その物理的メモリへのアクセスを拒否される。最後に、ハードウェアに固有の秘密鍵の操作を（この時点では信頼される）ソフトウェアが行えるようにする。当業者には、ハードウェアであるか、ソフトウェア、あるいはその組合せであるかに関係なく各種の他のデバイスが、ＤＲＭに用いられるデバイスの所望の機能を実行できることが理解されよう。
【０１９２】
本発明の別の態様によれば、セキュリティコンポーネント１６５はプライバシーモジュール１１０６を含む。プライバシーモジュール１１０６は、システム１００とアプリケーション２００の有用な特性を利用する各種エンティティによって送信され、取り出される情報の機密性とプライバシーを保持する各種のハードウェアおよび／またはソフトウェアモジュールとコンポーネントを含む。一般に、セキュリティコントロールのプライバシーモジュール１１０６は、公衆ネットワークを横断し、サーバフェデレーション１２０内の共有パブリックサーバに記憶される個人的あるいは高価値の情報が、許可を受けたエンティティのみに開示されることを保証する。さらにプライバシーモジュール１１０６は、横断する、かつ／またはパブリックサーバに記憶されるすべてのタイプのデータと情報の保全性を保持し、それにより１以上のエンティティ間を移動する送信データが不正に修正されることを防止する。図でプライバシーモジュール１１０６はセキュリティコンポーネント１６５の独立モジュールとして示しているが、当業者には、プライバシーモジュール１１０６の機能は、認証モジュール１１０２、承認モジュール１１０４、セキュリティサービス１１００を形成する１以上の各種の他のモジュールに組み込んでも、あるいは、単に固有の独立したモジュール形態を持たないセキュリティコンポーネント１６５の一機能であってよいことが理解されよう。
【０１９３】
上述の内容および本明細書に含まれるその他の教示に照らすと、プライバシーモジュール１１０６の機能は各種の方式で実現することができる。例えば一実施形態では、デジタル署名と、プライバシーモジュール１１０６および／またはセキュリティコンポーネント１６５が備えるアイデンティティの拒否を管理する能力を使用することにより、デジタル的な整合性を保持することができる。別の例示的実施形態では、暗号化したトランスポートを使用して、複数のホストまたはクライアントデバイス１１０の複数の点とサーバフェデレーション１２０との間でデータと情報を送信する。暗号化されたトランスポートがホスト間であるかポイントツーポイントであるかは、その通信がオンライン通信であるかオフライン通信（ストアアンドフォワード）であるかによって決まる。本発明の一実施形態の暗号化トランスポートプロセスの一態様は、送信されるデータと情報を任意選択で部分的または完全に暗号化するものである。データと情報内でアプリケーション固有の処理のためのメッセージ（ｅｎｄ−ｅｎｄ）などを選択的に暗号化することにより、セキュリティコンポーネント１６５は、すべてのネットワークトラフィックを暗号化するコストを必要とせずに安全なプライベート情報を提供する。
【０１９４】
ホスト間のトランスポートには、仮想私設網（ＶＰＮ）トンネルを実装し、参加システムのネットワーク接続を認証するために、インターネットプロトコルセキュリティ（ＩＰＳＥＣ）と称されるセキュリティプロトコルが必要である。低レベルのネットワークサービスでは通例各アプリケーションに固有の機密性ポリシーを実施しないので、ホスト間のトランスポートに用いられる中間サーバ（これらに限定しないが、キャッシュ、エアストリーム、コンテンツベースのルータなど）は、選択的なメッセージの暗号化を使用するように設計する。そこから益を受けるのが、キャッシュの性能的な利益を得るか中間サーバによる内容のフィルタリングを必要とするアプリケーションコンテンツだけなので、選択的なメッセージの暗号化の使用は任意選択である。これに対し、個人的な情報や高価値の情報は機密性のために暗号化され、一般には、中間ハードウェアおよび／またはソフトウェアモジュール、コンポーネントなどの中間ネットワークデバイスのサービスからは利益を得ない。
【０１９５】
ポイントツーポイント通信では、選択的なメッセージベースの暗号化を使用するように設計されていないアプリケーションにとって最低の共通性を有するレガシーとしてセキュアソケットレイヤ（ＳＳＬ）プロトコルが用いられ、存続している。当業者は、任意選択でポイントツーポイントのトランスポートとしてＩＰＳＥＣを使用してもよいことを認識されよう。一般に、搬送されるデータと情報の機密性とプライバシーは、既知の方法の組合せを使用して実現することができる。
【０１９６】
本発明のさらに別の実施形態では、セキュリティコンポーネント１６５は任意選択で、インターネットを介して送信されるすべてのデータを暗号化された形態に保つ。現在、今日のインターネットで送信される情報の大部分は暗号化されていない。ハードウェアとシステムによる適切なサポートにより、本発明のセキュリティコンポーネント１６５は任意選択で、情報およびデータの搬送を現在の「（限られた）要求に応じた暗号化」から「常時暗号化」のソリューションに移行することができる。暗号化は情報やデータを保護する有用な方法であるが、それ自体は、すべてのセキュリティ需要にとって完全な解決策ではない。このため、本発明のセキュリティコンポーネント１６５は、有用な特性内にある搬送可能なデータの完全な暗号化という特性と、認証および／または承認用のハードウェアおよび／またはソフトウェアモジュール、コンポーネント、および機能の特性を組み合わせることができる。
【０１９７】
本発明の別の態様によれば、セキュリティコンポーネント１６５はサーバフェデレーション１２０中に分散され、それにより分散したネットワークセキュリティを提供する。一般に、セキュリティコンポーネント１６５の分散した性質により、ホスト間であってもポイントツーポイントであってもメッセージ内容の終端間の機密性と整合性が得られ、一方で中間のプロキシサーバがイベントとメッセージを正確にルーティングできるようになる。ネットワーク全体のセキュリティがデータフローを制御して、コンピューティングノードに対する悪意ある妨害（例えばフラッディング、破壊的ウィルスなど）と、機密性の高い内容の不正な流布を防止する。通例、これらの機能の多くはファイアウォールによって行われる。不都合なのは、ハイパーテキスト転送プロトコル（ＨＴＴＰ）によるＸＭＬメッセージングの出現により、従来のファイアウォールがエンティティからの要求を区別する効力が低下したことである。上述のようにメッセージストリーム内で選択的に暗号化を使用することにより、機密性のある個人データが損失することなくメッセージ内容をフィルタリングすることが可能になる。ただし、これによりファイアウォールが提供できる保護の種類も制限される。
【０１９８】
現在ファイアウォールは主にトランスポート層に作用し、送信元と宛先のインターネットプロトコル（ＩＰ）アドレスや、伝送制御プロトコル／ユーザデータグラムプロトコル（ＴＣＰ／ＵＤＰ）ポートなどトランスポートレベルの情報を確認する。有用ではあるが、従来のファイアウォールの多くはすでに、バイナリ中のウィルスがないかアクセスされたデータをスキャンする、あるいは違法の内容がないかテキストをスキャンすることにも応用されている。したがって従来のファイアウォールモデルは２つの別個の動向、すなわち、暗号化の使用によりデータの検査あるいはポートの検査までが妨げられることと、単一のＴＣＰポートを共用するＸＭＬベースのアプリケーションによるＨＴＴＰの使用により、ＴＣＰレベルのフィルタの価値が低下することによって疑問が呈されている。このように、現在のファイアウォールは、外部攻撃からの保護とポリシーの強制という２つの機能を混合するため、その効果が限られている。このため、本発明は、単一のハードウェアおよび／またはソフトウェアモジュール内に集中させるか、あるいはサーバフェデレーション１２０内に分散させることのできる３つ以上の異なるモジュールおよびコンポーネントに機能を分担させることによりファイアウォールの効果を高めるファイアウォールモジュール１１０８を含む。
【０１９９】
次いで、ファイアウォールモジュール１１０８の例示的な要素を示す図１２を参照する。改良されたファイアウォールモジュール１１０８の一部分は、個人ファイアウォール１３１０である。個人ファイアウォール１３１０は、暗号解読後にデータ検査をローカルに実行し、各種の他の保護機能を実行する。例えば、個人ファイアウォール１３１０は「ウィルスチェック」システムの各種機能を実行するが、新たな攻撃が検出されると、その攻撃の署名をすべての個人ファイアウォールに迅速に伝播させ、それにより次のシステムあるいはアプリケーションのアップグレードを待つことなく攻撃を阻止する。個人ファイアウォールがあらゆる内部ホストにインストールされている場合は、ホストは、システム１００など、ネットワーク上の、または他のホストからのトロイアクティビティを検出することができる。これにより、周辺ファイアウォールによって監視されることなく直接ローカルホストに向けられる可能性のあるトロイ攻撃の可能性を低減する。
【０２００】
改良型ファイアウォールモジュール１１０８の第２の部分は、サーバフェデレーション１２０を形成する特定のハードウェアおよび／またはソフトウェアモジュールとコンポーネントを所有するエンティティのエンティティポリシーを実施するセキュリティゲートウェイ１３１２である。各セキュリティゲートウェイ１３１２は、送信元と宛先のユニフォームリソースロケータ（ＵＲＬ）とＨＴＴＰメソッド：ＧＥＴ、ＰＯＳＴ、ＮＯＴＩＦＹに基づいてチェックを行う。セキュリティゲートウェイ１３１２はＨＴＴＰプロキシとして明示的にアプリケーション２００に挿入され、どの外部ページがどの時刻に容易にアクセスできるか、あるいはどのユーザが外部通知を受信できるかなどを判断することができる。セキュリティゲートウェイ１３１２はホストであり、したがってＩＰＳＥＣまたはＳＳＬのエンドポイントとなることができる。さらに、各セキュリティゲートウェイ１３１２はＸＭＬの構造化データにアクセスすることができ、したがって特定ホストから送信されるメッセージの内容にアクセスすることができる。
【０２０１】
セキュリティゲートウェイ１３１２の任意選択機能の１つは、終端間のメディアストリームを許可するなどのために、周辺ファイアウォールすなわちトランスポートレベルのファイアウォール１３１４（下記で述べる）に「穴を開ける」ことである。ストリームは、セキュリティゲートウェイ１３１２で監視されるＨＴＴＰまたはＳＩＰの交換によってセットアップすることができるが、ＨＴＴＰではなくユーザデータグラムプロトコル／リアルタイム伝送プロトコル（ＵＤＰ／ＲＴＰ）を使用して送信される。セキュリティゲートウェイ１３１２は、許可されたＩＰアドレスとＴＣＰ／ＵＤＰポートの対を決定する。各セキュリティゲートウェイ１３１２は、２対のＩＰアドレス間におけるＩＰＳＥＣの使用を許可する能力も有する。
【０２０２】
改良されたファイアウォールの第３の部分は、可能性としてはセキュリティゲートウェイ１３１２の制御下で、システム１００のローカルネットワークへのアクセスを付与または拒否する周辺（トランスポート層）ファイアウォール１３１４である。トランスポート層ファイアウォール１３１４は、どの「外側」のトラフィックが内側のマシンに到達するかを制御し、そのアクセスを、適切に管理されている「外側」ソースだけに制限する責任を有する。規定の構成では、許可されたマシンにはセキュリティゲートウェイ１３１２が含まれる。
【０２０３】
一般に、周辺制御機能を「トランスポートレベルのファイアウォール」と「セキュリティゲートウェイ」間で分割することにより、システム１００および／またはアプリケーション２００の性能と拡張性が可能になる。トランスポートレベルのファイアウォール１３１４は性質的にルータと類似性があり、並列に接続することによりスケーリングを実現することができ、一方、アプリケーションサーバであるセキュリティゲートウェイ１３１２は、ウェブサーバのスケーリングに使用されるスケーリング技術を利用することができる。
【０２０４】
図１２ではファイアウォールモジュール１３０８の各部分１３１０、１３１２、および１３１４をファイアウォールモジュールに組み込んでいるが、各部分１３１０、１３１２、および１３１４はサーバフェデレーション１２０中に分散してもよいことが理解される。さらに、セキュリティサービスコンポーネント１６５は、複数のファイアウォールモジュール１１０８と複数の部分１３１０、１３１２、および１３１４を含むことができる。
【０２０５】
本発明の別の態様によれば、セキュリティコンポーネント１６５は、デジタル署名、時間スタンプ、および公証サービスの使用を可能にする各種のハードウェアおよび／またはソフトウェアモジュールとコンポーネントを含むことができる。デジタル署名を使用すると、これらに限らないが、起点（ｏｒｉｇｉｎ）の証明、承認の証明、後の紛争時の法的遡及権など、物理的な署名の利点の多くが電子取引においてユーザに提供される。さらに、ドキュメントの保全性を封印する能力（修正が加えられると署名が無効になる）も、情報がしばしば信頼できない通信および処理経路を通る電子世界では有用である。
【０２０６】
本発明のセキュリティコンポーネント１６５は、これらに限らないがデジタル署名アルゴリズム（ＤＳＡ）、楕円曲線、およびＲＳＡ Ｄａｔａ Ｓｅｃｕｒｉｔｙ社開発の暗号化技術（ＲＳＡ）など、現在デジタル署名に用いられる技術をサポートするように構成することができる。さらに、セキュリティコンポーネント１６５は、ＸＭＬおよびＸＭＬスキーマとともに使用する安全なデジタル署名を生成するように操作することができる点で柔軟性がある。例えば、一般的な署名電子メールシステム（Ｓｅｃｕｒｅ／Ｍｕｌｔｉｐｕｒｐｏｓｅ Ｉｎｔｅｒｎｅｔ Ｍａｉｌ Ｅｘｔｅｎｓｉｏｎｓ（Ｓ／ＭＩＭＥ）やＰｒｅｔｔｙ Ｇｏｏｄ Ｐｒｉｖａｃｙ（ＰＧＰ）技術）では、ユーザは暗黙的にその電子メールプログラムを信頼して自分が作成した電子メールの電子メール符号化を署名する。不都合なのは、価値が高く、したがって責任が伴う可能性のあるドキュメントにはより多くの保護が必要とされる可能性があることである。そうした重要なドキュメントを表すのにＸＭＬまたは一般的なＸＭＬスキーマを使用すると、そのＸＭＬドキュメントの基準的な表現を提供する汎用ツールの作成が可能になる。ドキュメントの基準的な表現の生成は、デジタル署名を作成し、検証するための要件である。
【０２０７】
セキュリティコンポーネント１６５はさらに、デジタル署名の機能とサービスを行うハードウェアおよび／またはソフトウェアモジュールに任意選択で組み込まれるタイムスタンプと公証サービスを含むことができる。タイムスタンプサービスはデジタル署名と同様に、（最も一般的な意味の）あるドキュメントがある時点に存在していたことの強力な証拠を提供する。同様に、デジタル公証サービスは、誰かがある時点に所与のドキュメントにデジタル的に署名をしたという証拠を提供する。セキュリティサービス３００に組み込むことが可能なこれらの種のサービスの例には、これらに限らないが、Ｘ．５０９およびＰＧＰ両方に基づく信頼モデルを使用したＳｕｒｅｔｙ、Ｅｎｔｒｏｐｉｃ、ｅ−ＴｉｍｅＳｔａｍｐなどがある。また、そのようなサービスへのインタフェースを包含する標準草案のタイムスタンププロトコルが提案される。本発明のセキュリティサービスは、既存サービスの相互運用性を可能にし、同時に現在発展中の関連サービスに準拠するためのハードウェアおよび／またはソフトウェアの柔軟性を提供する。
【０２０８】
一般に、セキュリティコンポーネント１６５は、デバイスのプラットフォームのコアであるオペレーティングシステム（ＯＳ）に組み込むことができ、それによりそのプラットフォームのＯＳ、サービス、アプリケーション、およびツールのすべての他のモジュールと機能に影響を与える。あるいは、セキュリティコンポーネント１６５、モジュール１１０２、１１０４、１１０６、および１１０８、およびそれらに提供される機能をサーバフェデレーション１２０、クライアントデバイス１１０および／またはアプリケーション２００内の様々な位置に配置してもよく、あるいは全体に分散してもよい。さらに別の構成では、セキュリティコンポーネント１６５はアプリケーション２００のエミッサリコンポーネント２２０とフィーフダムコンポーネント２３０の間に配置してもよい。さらに、図１０に点線で示すように、セキュリティコンポーネント１６５の各モジュールは、その中に含まれる他のモジュール１１０２、１１０４、１１０６、および１１０８の１以上と通信してもしなくともよい。
【０２０９】
セキュリティコンポーネント１６５は、ウェブサイト間の通信を増大して、消費者、ビジネス、政府などに、より多くのインターネット接続性と連携を可能にすることを支援する各種の通信シナリオで利用することができる。例えば、第１のシナリオは、消費者対サービスの環境、またはビジネスの環境におけるものである。本発明のセキュリティコンポーネント１６５は、「常時接続」のデジタル加入者回線（ＤＳＬ）および／またはケーブルモデムシステムを備える家庭のコンピュータのセキュリティについても、他の家庭におけるネットワーキングシナリオについても、より多くの通信、通知、ストリーミングメディア、ゲーム、および連携サービスを可能にする。セキュリティコンポーネント１６５は、消費者対サービスの環境において消費者を次のことから保護する。（ｉ）玄関のベルを無作為に鳴らすのに等しい、インスタントメッセージやインターネット電話などインターネットによるインターネット通知メッセージの乱用、（ｉｉ）ユーザアクティビティのアクティビティ追跡を行い、それにより広告者やその他によるユーザの「正確なターゲット」を低下させる、（ｉｉｉ）第３者にしかけられる攻撃の一部として個人のコンピュータを使用するトロイプロセスを通じた個人資源の不正使用、（ｉｖ）インターネットサービスの拒否、（ｖ）文字通り消費者から盗みを働く、結果として金銭の転送や要求しない購入を伴う個人コンピュータへの不正アクセスなどの犯罪行為。
【０２１０】
別のシナリオは、アプリケーションサービスプロバイダ（ＡＳＰ）をホストするための小規模ビジネス指向のサービスプラットフォームである。本発明のセキュリティコンポーネント１６５は、メッセージング、ファイルおよびプリントのサービス、企業資源プランニング（ＥＲＰ）アプリケーションや、統合された電子ドキュメント管理とオンラインのビジネスサービス、従業員の個人なウェブストレージなどのオンラインのビジネス活動などに対してより高い保護を提供する。さらに、セキュリティコンポーネント１６５は、各種のビジネスが、ホストされるウェブでの存在、委託された役割に基づく管理、およびバニティドメインを有することを可能にする。このように、本発明、より具体的にはセキュリティコンポーネント１６５は、小規模なビジネスが各自のビジネスアプリケーションのあらゆる必要性に対処するために複数のＡＳＰに安全にアクセスすることができるようにする。
【０２１１】
また別のシナリオは消費者対ビジネス対ビジネスの環境である。このシナリオには、消費者対サービスのシナリオに関連して上記で述べた要件の多くが含まれ、同時にビジネス対ビジネスの関係に伴う問題と要件が含まれる。このため、セキュリティコンポーネント１６５は異質の環境にある複数のエンティティにセキュリティを提供することになる。セキュリティコンポーネント１６５は、通信線上における（ｏｎ−ｗｉｒｅ）持続性のある情報の保護を提供し、一方で消費者情報の否認防止機能を提供する。さらにセキュリティコンポーネント１６５は、中層のトランザクション、クライアント−サーバアクティビティを認証および承認し、ピアーツーピアの信頼性を交渉することができる。
【０２１２】
最後の例示的シナリオは、ビジネス対ビジネスの環境である。セキュリティコンポーネント１６５は、サプライチェーンのアプリケーション、ビジネス間の連携を支援するように構成することができる。さらに、特定の認証機構に依存しない企業間の信頼関係の管理が提供される。また、セキュリティコンポーネント１６５は、次の可能性を低減する。（ｉ）不正な取引の結果金銭的損失が生じること、（ｉｉ）クリデンシャルが意図せず開示されたために取引の要求が信頼できるものではなかったという取引先からの不正な主張、（ｉｉｉ）無許可の人員によるサーバ１４０またはクライアント１１０への不正アクセス、（ｉｖ）データアクセスの要求と応答を観察し機密データを入手した競合者への情報漏えい、（ｖ）攻撃者がデータの取り出しに際して提携相手を装って不正確なデータを要求し、戻すことにより、不正確な決定を行わせること、（ｖｉ）データを記憶したサイトの信用できないシステムオペレータが、ネットワークを通じて貴重なデータを送信することにより共犯者に漏洩すること、（ｖｉｉ）部内者がインターネットを使用して不適切な情報を部外者に送信すること、（ｖｉｉｉ） 結果として情報の漏洩、不正な取引、あるいは許可された取引への妨害を引き起こす、誤解される、あるいは誤って適用されるポリシーの作成。
【０２１３】
（Ｋ．コード管理）
コード管理コンポーネント１７５は、ユーザが最新のアプリケーションとそれに必要なコードに透過にアクセスできることを確実にする。図１３は、コード管理の各種の態様におけるマニフェストの使用を説明する。コード管理は主に、相互運用するコンポーネント間、サービス間、およびアプリケーション間の抽象化とインタラクションを形式化することに関連する。この形式化により、これら基礎となる構築ブロックで構成されるソフトウェアを管理するために各レベルに一層の分離がもたらされる。マニフェストは基本的に、コンポーネント、サービス、あるいはアプリケーションをある程度詳細に記述するデータベースである。マニフェストは、コードコンポーネント、コードコンポーネント間の関係、およびそのコンポーネントからなるアプリケーションを記述することにより、あるアプリケーションが何であるかをシステムが理解し、したがって効果的にそのアプリケーションを管理できるようにする。アプリケーションまたはサービスは、そのアプリケーションまたはサービスを実行するための開始点を含むこと以外はコードコンポーネントのマニフェストに類似するルートマニフェストによって定義される。
【０２１４】
マニフェスト１４００は、そのマニフェストと関連付けられたソフトウェアを記述するための各種カテゴリの情報を含んでいる。識別したカテゴリは例示的なものに過ぎず、必ずしも本発明をなんら制限するものではないことを理解されたい。同様に、各カテゴリにおける情報の記述も例示的なものである。特定カテゴリに関連した情報の記述は、その情報がそのカテゴリだけに含める必要がある、あるいはそもそも含める必要があると解釈すべきではない。用語「ソフトウェア」を図１３に関して使用する場合、この用語はコンポーネント、サーバ、アプリケーションなどを含むものと広く解釈すべきであることに留意されたい。
【０２１５】
マニフェスト１４００は、それに関連付けられたソフトウェアを１以上のコンピューティング環境で使用できるようにするための情報のスーパーセットである。例えば、マニフェスト１４００は、そのソフトウェアの一部である実行可能コード１４１０とリソース１４２０を識別する。関連付けられたソフトウェアの動作上のニーズと要件に応じて、実行可能コード１４１０とリソース１４２０はプライベート（ローカル）または外部の依存関係を参照することができる。マニフェスト１４００はすべてのソフトウェアと関連付けられ、すべてのマニフェストは外部の依存関係を記述するので、従来技術のように共有されるＤＬＬのための参照カウントを管理することなく、ソフトウェアオブジェクトをガーベジコレクションすることができる。
【０２１６】
依存型のマニフェスト１４３０は、マニフェスト１４００の外部の依存関係を識別する。これは、マニフェスト１４００にとってローカルでないソフトウェアおよびマニフェストへの参照である。例えば、マニフェストはカスケードすることができ、この場合は１つのソフトウェアオブジェクトが単に何らかの他のソフトウェアオブジェクトの拡張となる。これにより、単純なカスタマイズアプリケーションを容易に構築することができる。カスタマイズアプリケーションは、基本アプリケーションがアプリケーションの外観とその振る舞いを変更するのに使用される何らかの設定やリソースを無効にすることができる。基本アプリケーションは、それ自体のどの部分をその種の変更に対してオープンにするかについての制約を提供して、カスタマイズの範囲を意図する領域に適切に制限することができる。こうしたマニフェスト１４００にとって外部の他のソフトウェアとマニフェストの参照は、依存型マニフェスト１４３０に記憶される。依存型マニフェスト１４３０はまた、マニフェスト１４００にとってローカルであるが個々に定義されたマニフェストも識別することができる。あるいは、依存型マニフェスト１４３０は、論理的にマニフェスト１４００に含まれるか、あるいはマニフェスト１４００にリンクされた、個別に記憶されたマニフェストを含むこともできる。このような構成は、そのソフトウェアの開発など限られた目的だけについて情報に関連性があり、通常の動作時には必要とされない場合に有用である。
【０２１７】
エントリーポイント１４４０は、マニフェスト１４００とそれに関連付けられたソフトウェアが外部のソフトウェアに対して利用可能にするソフトウェアオブジェクト（エントリーポイント、リソース、サービスなど）のパブリック名を公開する。マニフェスト１４００にとってローカルなソフトウェアオブジェクト名も、エントリーポイント１４４０にあることが可能である。名前とメタデータは、特定のソフトウェアオブジェクトと、そのソフトウェアオブジェクトが使用するすべての他のソフトウェアオブジェクトを識別するのに使用される。（メタデータはバージョン、ロケール、およびプラットフォームなどの情報を含む。）バインディングは、名前の依存関係を解決するプロセスである。名前を解決してその結果得られるオブジェクトにすると、そのオブジェクトをアプリケーションで使用することができる。ソフトウェアオブジェクト間のバインディングはすべてマニフェストを通過し、コンピューティング環境自体、管理者、あるいは独立したソフトウェア開発者によってそのマニフェストに適用されるポリシーの影響を受ける。したがって、名前の解決により、ポリシーとセキュリティの決定を挿入する機会が得られる。名前は実際にはコードやデータを提供せず、解決することによってコードおよびデータにアクセスするための間接化技法なので、バインディングプロセス中に必要に応じてアクセスをリダイレクトまたは制限することが可能である。
【０２１８】
例えば、あるアプリケーションのマニフェスト１４００は、バージョン１を要求するメタデータを有する特定のランタイムソフトウェアオブジェクトの使用を要求することができる。しかし、管理者は、その特定のランタイムソフトウェアオブジェクトのより新しいバージョンをすべての要求に対して使用するようにポリシーを設定している可能性がある。メタデータ情報により、アプリケーションが新しいバージョンの使用を中断した場合、管理者はポリシーを変更して、そのアプリケーションと動作することが分かっているバージョンのランタイムをアプリケーションに使用させることができることに留意されたい。名前の解決は、システム中のセキュリティポリシーに応じて特定の名前の解決を許可しないことによりプロセスにセキュリティを加える機会も提供する。
【０２１９】
構成情報１４５０は、ソフトウェアに必要なデータテーブルとプラットフォームサービスを識別する。構成情報１４５０は、マニフェスト１４００と関連付けられたソフトウェアをどのように使用できるか、あるいはどのように振る舞うかも記述することができる。例えば、ソフトウェアはクレジットカードの清算サービスを提供することができる。クレジットカードによるトランザクションを管理するには２つの選択肢がある。（１）サービス提供者がトランザクションの制御権を保持する、または（２）サービス提供者が、そのサービスを組み込んだ開発者にその開発者自身のクレジットカードトランザクションを管理させる。サービス提供者がこれら選択肢の１つを実装するだけである場合、その情報はそのサービスを実行するのに用いられる構成情報１４５０中に取り込むことができる。開発者に性能とデバッグ情報を与えるために、構成情報１４５０にモニタも含めることができる。
【０２２０】
上述のように、マニフェスト１４００により各種バージョンのソフトウェアを保持することが容易になる。この機能は、新しいソフトウェアを配置する際に非常に有用である。マニフェスト１４００の性質は、各種コンポーネント、サービス、およびアプリケーションの種々の状態と構成情報を互いから分離することを可能にする。この分離は、異なるバージョンのコンポーネント、サービス、およびアプリケーションを並行に実行することができ、他のソフトウェアオブジェクトが、それについて設計され、テストされた特定バージョンのソフトウェアにアクセスできることを意味する。この結果、複数層の配置（フロントエンドサーバからバックサーバまで）、分離され共有される配置、および古いバージョンが作業を終えるのと同時に新しいバージョンが起動する段階的な配置が可能になる。
【０２２１】
マニフェスト１４００などのマニフェストは、コード管理について大きな利点をもたらす。例えばマニフェストは、（１）コンポーネント、サービス、およびアプリケーションの自己記述を可能にする、（２）開発者および管理者による、コンポーネント、サービス、あるいはその他のアプリケーションからのアプリケーションコンポジションを可能にする、（３）コンポーネント／サービス／アプリケーションの実行時のネーミング、発見、およびバインディングを容易にする、（４）ライセンシング、バージョニング、配布、およびドキュメント化を追加的に発行して、時間シナリオの開発／設計を可能にする、（５）レガシーシステムの相互運用性を可能にする、（６）コンポーネント、サービス、およびアプリケーションの容易な配布／インストール、（７）アプリケーション／サービス／コンポーネントの正常性の継続的な管理を可能にする。
【０２２２】
上述のコード管理ではマニフェストを使用して、開発者、管理者およびエンドユーザが図１および２に示すクライアントとサーバの層にわたってアプリケーションを書き、消費し、配置し、更新し、命名し、見つけることを可能にする。下記の例では、図１および２を参照して、マニフェストを使用してクライアントからアプリケーションをインストールし、実行する仕組みを説明する。
【０２２３】
この例では、ユーザは検索エンジンまたはその他のシェルを介し、図１のクライアント１１０の１つを使用して、サーバフェデレーション１２０内に位置する、特定のワードプロセッシングアプリケーションのユニフォームリソースロケータ（ＵＲＬ）に行く。そのアプリケーションがすでにクライアントに「インストール」されている（すなわち以前にそのクライアントで実行したことがある）場合には、そのＵＲＬに行くとアプリケーションがローカルキャッシュから実行される。アプリケーションがクライアントに「インストール」されていない（すなわちそのクライアントでこれまでに実行されたことがない）場合は、アプリケーションをダウンロードして、以下に述べるプロセスを用いて実行することになる。
【０２２４】
インストーラモジュールは、このアプリケーションと関連付けられたマニフェストをダウンロードする。次いでインストーラは、プラットフォームの要件と既知の互換性のないアセンブリの両方について、そのマニフェストとクライアントの構成とを比較する。そのアプリケーションをそのクライアントで実行できない場合は、クライアントにエラーメッセージが示される。そのクライアントでそのアプリケーションを実行できる場合は、インストーラはＵＲＬを使用してサーバフェデレーション１２０内のサイトに接続する。そしてクライアントは、エンドユーザライセンス同意（ＥＵＬＡ）と併せて、購入／賃貸／認証の決定など何らかのユーザインタフェースを表示する。そして、要求に応じて、あるいは典型機能のパッケージとしてそのアプリケーションをダウンロードする。アプリケーションの自動的なサービスは、本発明による非同期メッセージングを用いたインストールＵＲＬからのマニフェストの定期的な更新を通じて駆動される。
【０２２５】
（Ｌ．シナリオ）
以下のシナリオでは、本発明の分散型コンピューティングサービスプラットフォーム１１５が、より容易な連携と通信を可能にすることによりユーザの能力を高める様子を例を挙げて説明する。このシナリオは、（１）知識労働者、（２）消費者、（３）開発者、の３種類のユーザに分かれている。
【０２２６】
（知識労働者／ビジネスのシナリオ）
７Ｃｙｃｌｅｓという名の小企業の自転車製造業がアレックスによって所有されている。７Ｃｙｃｌｅｓは新しい高性能自転車を設計したばかりで、この新製品の自転車をスポーツ用品の流通業者に売り込む必要がある。このシナリオでは、いくつかのビジネス課題（例えば任意の時間／場所における情報の統合と情報へのアクセス）および技術的課題（例えば、スキーマに基づく統合、次世代の生産性ツール、複数デバイスにわたるフェデレーション）について説明する。
【０２２７】
アレックスのパーソナルコンピュータ（ＰＣ）は、メッセージ、予定表、連絡先／「バディリスト」などを示す「スタートページ」あるいは「ホームページ」を含む、彼女に合わせて設定されたユーザインタフェースを表示する。このユーザインタフェースは、単一のインタフェース内にボイスメッセージと電子メールメッセージを含むという点でマルチモーダルである。必要に応じて、ボイスメッセージをテキストメッセージに変換し、電子メールメッセージをボイスメッセージに変換することができる。また、このユーザインタフェースはアプリケーションベースではなくコンテンツベースである。例えば、スタートページは、従来は各種のアプリケーションによって提供される情報（すなわちボイスメールメッセージ、予定表、連絡先など）を含む。
【０２２８】
アレックスは自分のＰＣを用いて、ビジネス管理を支援するように設計されたサービス（例えば本出願人提供のｂＣｅｎｔｒａｌ（商標））にログオンし、そのサービスを利用して新製品の自転車を７Ｃｙｃｌｅｓのオンラインカタログに追加する。このサービスは、カタログ入力用のテンプレートを提示する。アレックスは次いで７Ｃｙｃｌｅｓの企業イントラネット（アレックスの個人データストアと他のソースの両方を含んでいる）で、新しい自転車についての情報（写真、販売の見積価格、製品仕様など）を検索し、適当な情報をカタログテンプレートにドラッグアンドドロップする。自転車の製品仕様は共通の記述言語（すなわちＸＭＬ）で提供され、スキーマに準拠している（上記の「スキーマ」の項を参照）ので、カタログテンプレートサービスは仕様中の情報を理解し、テンプレートに適切な情報を取り込む。アレックスは更新されたカタログページを確認し、パブリッシュする。これにより新しい自転車が７Ｃｙｃｌｅｓのウェブサイトに掲載される。
【０２２９】
アレックスは次いで上記のサービスを使用して、新製品の自転車を扱ってくれる可能性のある他のサイト／企業の一覧をディレクトリに照会する。ディレクトリサービス（上記の「ディレクトリ」の項を参照）は、スキーマによって容易になる企業レベルのメタディレクトリの同期を通じてインターネット規模のディレクトリサービスを提供するので、この種の堅牢性があり、インターネット全体にわたるディレクトリの一覧が大幅に容易になる。これでアレックスは新しい自転車についての情報をそれら他の企業と共有することになる。
【０２３０】
アレックスはまた、このサービスを使用して新しい自転車についてのキーワードのリストを自動的に生成し、それを数個の検索エンジンに分配して、人々が新しい自転車についての情報をすぐに見つけられるようにする。
【０２３１】
アレックスは、ウェブ上で７Ｃｙｃｌｅｓの新しい自転車を見たスポーツ用品の流通業者に勤めるサンドラから電子メールを受信する。サンドラは、アレックスに見本市で会うことを提案する。アレックスはこのメッセージを携帯電話など携帯型のクライアントデバイスで受信する。このクライアントデバイスのユーザインタフェースはＰＣに比べて小さいが、そのユーザインタフェースによって提供される機能は、ＰＣのユーザインタフェースで提供されるものと整合性がある。例えば、携帯電話は、例えば連絡先や緊急のメッセージを示す、カスタマイズされたハイライトページを備えるアレックスのスタートページを縮小したバージョンを表示する。
【０２３２】
アレックスは連絡先管理のページに行き、ここでサンドラの予定にアレックスを結びつけることができ、また見本市のサンドラのブースを示す地図を得る。サンドラの予定には、そのような予定のパブリッシュを可能にするためにアレックスのマイステートディレクトリにリンクされた適合ディレクトリ（「ディレクトリ」の項を参照）を通じてアクセスすることができる。アレックスは音声テキスト変換を使用してサンドラのメッセージに返信することにより、電子メールメッセージを口述作成することができる。アレックスはサンドラの予定表を調べ、２時前後に会うことを提案する。
【０２３３】
アレックスは見本市に到着し、近接性／位置認識サービスを使用して、自分の位置とサンドラのブースの位置を示す地図を自分の携帯電話に取り出す。この地図は、アレックスがブースに接近するのに従ってその位置を追跡する。
【０２３４】
アレックスとサンドラが出会うと、サンドラは新しい自転車の仕様を見られるか尋ねる。アレックスは、その情報はすべて７Ｃｙｃｌｅｓの企業イントラネットに置いてあると告げる。アレックスはサンドラのタブレットＰＣを借りて、ゲストユーザとしてログインする。すると自分のスタートページが（自分の仕事用ＰＣと同じように）表示され、地理に関連する情報（例えばアレックスにとって関心のあるローカルな事柄）が下部に表示される。このように、上述のストレージ、ディレクトリ、およびセキュリティのコンポーネントにより、アレックスは新たなクライアントデバイスに自己を認証し、すべての個人化された情報をそのクライアントデバイスを通じて利用できるようにすることができる。アレックスは自転車の仕様を見つけ、自分の最近の連絡先リストからその情報をサンドラと共有するよう要求する。サンドラがログインすると、連携した（ｆｅｄｅｒａｔｅｄ）セキュリティドメインを通じた安全な方式で自転車の仕様をサンドラのタブレットＰＣで利用することができる。
【０２３５】
サンドラは見本市から戻り、自分の職場ＰＣを使用してボイスメッセージと電子メールメッセージの両方にアクセスする。サンドラのスタートページは、私的な情報、仕事関係の情報、およびウェブの情報を合わせて表示する。サンドラは、スポーツ用品チェーンの小売業者に対する新製品の自転車についての企画書を準備する必要があることを知らせるメッセージを同僚に送る。サンドラがタイプすると、システムは、例えば別の同僚の名前やその企画書の期日など、特定の内容が動作メニューに適していることを認識する。システムは、このデータタイプの関連性を認識し、それらを連絡先および予定表情報に自動的かつ適切にリンクすることを可能にする。この有意味の通信は、「スキーマ」の項で説明している。
【０２３６】
サンドラは次いで企画書のための「プロジェクトページ」を作成する。このページは、「スキーマ」の項で説明したオートコンプリート機能を自動的に使用して電子メールのすべての名前を含み、情報／連携を共有するためのウェブページをセットアップし、諸ドキュメントをそのプロジェクトに含めるように提案する。（異なる企業／セキュリティドメインにいる）アレックスもそのプロジェクトに含まれる。サンドラが企画書を書き始めると、その企画書はリアルタイムに他のチームメンバーと共有される。これは、「メッセージング」の項で説明した非同期メッセージングを用いて実現することができる。メンバーは、インスタントメッセージング／チャットを使用して変更を行いながら変更を検討する。この企画書は、テキスト、グラフィック、ビデオなどを含むマルチメディアドキュメントである。第３者によるコンテンツ（例えばイメージハウスによる写真など）を直接シェルに組み込むことができる。ビデオコンテンツには注釈をつけることができる。
【０２３７】
職場から車で帰宅する途中、サンドラは自動車電話で夫と話している時に、企画書に関連するメッセージがあることを自分のＡｕｔｏＰＣから通知される（これについては割り込みを指定している）。この通知は、「イベント」の項で説明したように所定のイベントに応答して発行される。この所定のイベントの一部には、ユーザ定義の規則が含まれる。例えば、サンドラは、自動車電話でこの割り込みを行わせた条件を指定している。電子メールは、企画書に追加的な人口統計学の情報を含めたいという小売業者からのメッセージである。自宅に到着すると、サンドラは自宅用ＰＣ（スタートページは個人的な「スキン」を備え、ここではサンドラのプロファイルはわずかに異なる場合もある）を使用する。個人的な「スキン」を形成するためのプレファランス情報は、「ディレクトリ」の項で説明したＨｏｍｅ Ｐｒｅｓｅｎｃｅまたはマイステートの適合ディレクトリに記憶することができる。サンドラは、外部のウェブサイトと自社のデータベースにある情報をドキュメントの中にフィルタリング／合併／マッピングすることにより、追加の人口統計的な情報を企画書に組み込む。この異なるウェブサイトにある情報の合併はスキーマによって容易になる。
【０２３８】
次の日、アレックスはサンドラから、当初処理したようにサンドラの会社に自転車を発送するのではなく、一晩で３０の異なる小売店に自転車を発送するように注文を変更する必要があるというメッセージを受け取る。アレックスがビジネスサービスにログオンすると、サンドラによって変更後の購入注文がテンプレートに記入されており、またアレックスのためにそれが通知フォームによって通知されて（ｆｌａｇ）いる。アレックスがツールバーの「変更を認める」を確認して押すと、システムがスキーマを使用して、ＵＰＳによる発送をアレックスが確認したいかどうか尋ねるべきであると認識する。アレックスが承諾すると、システムは新しい発送イベントを作成し、アレックスとＵＰＳを結びつけて発送を手配する。ＵＰＳと７Ｃｙｃｌｅ間の予定表の折衝により集配の時刻が決定され、この時刻が自動的にアレックスの予定表に表示される。サンドラは、注文の変更が処理されたという通知を受け取る。このビジネスサービスは、分散したイベントシステムを使用してユーザのためにイベントを追跡する（注文の受け取り、注文の発送など）ことができる。ビジネスサービスは通知マネジャを介してサンドラに通知を送信する。通知マネジャは、状況に応じた通知サービスをサンドラに提供する通知システム全体の一部であり、送られてくる各種の通知を監視する機能を果たす。通知マネジャは、サンドラのその時点における状況、注意の対象、場所、およびデバイスの可用性についての推論に応じて、重要で状況に応じたメッセージをサンドラに転送する。
【０２３９】
（消費者のシナリオ）
このシナリオは、一般的なユーザや消費者にとっての本発明の利点を対象とする。このシナリオでは、休暇に出かけた家族と十代の娘の生活のある一日について説明する。
【０２４０】
このシナリオは、本発明によって提供される改良されたメッセージング、日常的な仕事の単純化、および改良された娯楽について述べる。主要な機能の一部には、いたるところに存在する所与の者に共通の人格、複数のデバイス空間にわたる一貫性のあるインタラクションのセット、一貫性のあるデータ捕捉、デジタル時代のあらゆる資源へのアクセス（プライバシー、複数のデバイス空間にわたる自然な双方向通信、一貫性のあるユーザ体験、個人化された娯楽、ｗｅｂ、人々の生活の自然な一部分）がある。
【０２４１】
この家族の父親は、自宅ＰＣを使用して家族の休暇にロサンジェルスとサンディエゴ動物園に出かけることを計画する。父親があるサービスを使用していくつかの鍵となるデータをＰＣに与えると、システムは、一度だけの情報の入力により飛行機の便、ホテル、自動車を提案して予約を取り、動物園の入場券を入手する。サーバ同士は、スキーマに基づくメッセージングを通じて有意味に情報を交換することができるので、１つのユーザ要求を使用して、飛行機の便、ホテル、および車の予約データや動物園の入場券の入手可能性といった種々のデータを入手する際に１つのサーバフェデレーションとして通信することができる。したがって、父親は各サーバに接続してこの情報を独力で得ずに済む。
【０２４２】
システムはさらに一日早く出発すると代金を節約できることを知らせ、家族各自の予定表を調べてそれが可能であるかを確認する。予定表情報はＸＭＬ形式で記憶されるので、システムは皆の予定表を同期して都合の良い時間を調べることができる。システムはさらに、割引に関する情報（例えばＰｒｉｍｅ ＣａｒｄやＡＡＡの会員など）を示すことによって代金を節約する。このサービスは、保存されている個人のプレファランスに基づいて、家族が休暇に出かけている間に新聞の配達を止め、隣人に電子メールを送信して猫に餌をやってもらう。これは、このシステムの、プロファイルと規則に基づいて日常的な作業を自動化する能力を実証している。「イベント」の項で説明したイベンティングを使用してイベントを検知し、そのイベントに基づいてタスクを実行することができる。
【０２４３】
母親と父親は、その日が祖父母の記念日であること知らせる通知をＰＣで受け取る。２人は、テレビ会議を使用してレストランの予約をとり特別なケーキを注文する。これは、ユーザインタフェースのマルチモーダルな性質を示している。祖父母は（ＷｅｂＴＶユニットまたはＰＣを介して）招待を受け取り、それに応じる。
【０２４４】
子供たちは、バスでの通学中に計画された旅行についての通知を受け取る。この通知は、「メッセージング」の項で説明した非同期メッセージングを介して行うことができる。子供たちは、動物園のアプリケーション／サービスへのリンクを使用して動物園の地図、ショーの時間などを調べることができる。
【０２４５】
家族が飛行場でレンタカーを受け取ると、その車には各家族員のためにダウンロードされた音楽／ビデオのプレファランスが備えられている（父親は車を予約した際にこのオプションを指定し、料金を払っている）。各個人のプレファランス情報には、上記の「ストレージ」の項で説明したようにメガストアからアクセスする。したがって、利用できるプレファランスはレンタカー内で直ちに利用することができる。
【０２４６】
車内で娘が空腹になり、近接性／場所認識サービスを使用して、車から一定範囲内にある自分の好きなファーストフードレストランの１つを見つけ、そこまでの道順を入手し、家族のために食べ物を予約注文する。近接性／場所認識アプリケーションは、「ディレクトリ」の項で説明したディレクトリアーキテクチャを通じて適合ディレクトリにアクセスする。この家族は、通常よりも短い、予約した客用の列で食べ物を受け取るという選択肢を有する。支払いはスマートカードで行う。
【０２４７】
動物園の入り口で、息子は動物園のアプリケーションのコピーを自分のＰＤＡにダウンロードする。この動物園のアプリケーションには、地図、イベント（動物の餌やり）、動物園の個々の展示動物についてのデータ（例えばチンパンジーについての詳細）、買い物の宣伝などが含まれる。息子は、学校の友達も動物園に来ているという通知を受信し、互いにメッセージを交換し、後に会う予定を立てる。この通知を容易にするために、ＰＤＡと関連付けられた位置センサが、位置認識アプリケーションプログラムにデータを提供することができる。このアプリケーションは、「ディレクトリ」の項で説明したインターネット全体のディレクトリに位置を提供する。友達も、その位置をインターネット全体のディレクトリサービスに転送するアプリケーションを備えている。その友達が息子から特定の距離内にいる、または息子と共通の領域（例えば動物園）にいると、位置認識プログラムによってホストされるイベントがトリガされる。このイベントは、非同期メッセージングを通じてアプリケーションのフィーフダムコンポーネントから、そのアプリケーションのページコンポーネントに通信される。そしてこのイベントにより通知がトリガされてＰＤＡのユーザインタフェースを通じて息子に通信される。
【０２４８】
母親は動物園で家族のデジタル写真をとり、それを自分たちのコミュニティウェブサイトに掲示する。祖父母はテレビを見ている時に、新しい写真があるという通知をテレビのインターネットブラウザで受け取る。２人は写真が気に入り、家中の電子フレームにその写真をダウンロードする。祖父母は、新しい写真がないかウェブサイトを監視するイベントをホストするフィーフダム層を有するアプリケーションを実行している。このイベントは新しい写真が掲示されるとトリガされ、その結果メッセージが祖父母に送信される。このメッセージは、例えば、イベントに応答してフィーフダムコンポーネント中のコード本体によって生成することができる（「プログラミングモデル」の項を参照）。
【０２４９】
休暇から戻ると、十代の娘ジェンナは自室にある自分のＰＣを使用して留守中のメッセージを取り出す。ジェンナは自分のＵＩを「十代の女性」のスキンにしている。ある友人が、コンサートに行く事に関するメッセージを残しているが券が売り切れだと言う。メッセージを聞いている間に、ジェンナは関連するメッセージがある旨の通知を受け取る。そのメッセージを開くと、２枚の券が自分のために予約してあることを通知される（幸いジェンナは、好きなバンドが町に来た際に券を自動的に購入してくれる音楽サービスに加入していた）。このサービスは、ジェンナの好きなバンドの新作のミュージッククリップも提供する。「イベント」の項で説明したイベンティングにより、ジェンナは自動的に券を購入し、新しいミュージッククリップを入手することができた。
【０２５０】
ジェンナはコンサートの券について友人とテレビ会議をし、これはしたがってＵＩのマルチモーダル機能を実証している。それから２人は協力して宿題（熱帯雨林問題についてのビデオリポートを作成する）に取り組む。２人はプロジェクトサイトにリンクして、テレビ会議を行いながらビデオ／テキストのリアルタイムの編集を行う。ジェンナは動物園で撮ったビデオを提供する。宿題を終えると、２人はリポートを学校のウェブサイトに提出する。
【０２５１】
ジェンナは学校のウェブサイトを使用して自分が休んだ授業のビデオをダウンロードし、宿題があればそれをアップロードする。ジェンナは、現在の環境問題についてのリポートを出さなければならないことを知る。ジェンナはインテリジェントなニュースエージェントに、選択された情報源から最近の環境に関するニュースクリップを見つけ、起きたときに利用できる状態にしておくことを指示する。環境に関するニュースクリップの検索は、「ディレクトリ」の項で説明した適合ディレクトリのインターネット規模の同期によって容易になる。
【０２５２】
起床すると、ジェンナは自分の頼んだニュースクリップが準備されている旨の通知を受け取る。この通知は、ニュースクリップが利用可能になるとトリガされるイベントによって生成されたものである。ジェンナはそのクリップに目を通し始めるが、時間が遅くなってきたので、通学途中に聞き終えることができるようにそのオーディオを自分のＡｕｔｏＰＣに転送する。車内でジェンナはクリップを選択して、それを自分のＴａｂｌｅｔＰＣにダウンロードする。これは、ジェンナが「ストレージ」の項で説明したメガストアを使用してオーディオをサーバフェデレーションに記憶し、別のクライアントデバイスでそのオーディオをサーバフェデレーションから再び入手したことを実証している。学校に到着すると、ジェンナは自分のＴａｂｌｅｔＰＣで学校のウェブサイトを確認して学校新聞を読み、昼食のメニューを調べる。
【０２５３】
放課後、ジェンナは自分のＰＣを使用して友人とビデオゲームを遠隔プレイする。このゲームは顔のマッピング／スキャンニングの技術を含んでおり、ジェンナの顔がビデオゲームキャラクターの上に表示される。ゲーム中にジェンナは教師からリポートを褒めるインスタントメッセージを受信する。また、好きな映画の１本をダウンロードすることができるという通知も受信する。この通知は、好きな映画が入手可能になるとトリガされるイベントに応答して生成されたものである。
【０２５４】
（開発者）
このシナリオでは、出張中に事故を起こすことが多い男性（スティーブ）について説明する。このシナリオの主要点は、メガストアあるいは「クラウド」にある個人情報への全世界的な安全なアクセス、情報への段階的なユーザアクセス、および容易な情報の交換である。
【０２５５】
スティーブは空港のレンタル電話の窓口にいるが、自宅にスマートフォンを忘れ、自分の情報にアクセスする必要があることから非常に動揺している。幸運なことにスティーブはスマートカードを携帯しており、電話機を借りて、スマートカードを使用してサーバフェデレーションのメガストアから自分の個人情報をすべてダウンロードすることができる。これは、情報にアクセスするただ１つの方法としてのスキーマの使用、「セキュリティ」の項で説明したインターネット認証の使用、および、どこからでも「メガストア」にある情報にアクセスできることを示している。スマートカードはスティーブを認証し、スティーブの情報がどこに位置するか（すなわち、予定表情報はＸに記憶され、連絡情報はＹに記憶されているなど）をレンタル電話に知らせる。電話機はこの情報を取り出し、それをスティーブのためにダウンロードする。
【０２５６】
空港から出た後、スティーブは途中でバイクメッセンジャーと衝突し、足首を怪我してしまう。スティーブは初めての町におり、どこに行って治療を受けたらよいのか分からない。スティーブはかかりつけの医者に電話し、自分の保険が効く近隣の医院を尋ねる。受付は、より効率的な情報の集合を求めて医院の紹介サービスを使用し、スティーブの近くにある医院と、スティーブと妻の既存の保険計画による適用範囲率を見つける。受付はまた予定表の共有を使用してスティーブのために即時の予約を取り、その医院に直接接触する。これは、ビジネスと個人スキーマの自動的なマッピングを実証している。また、医院のリストアップと医院の予定表は、「ディレクトリ」の項で説明したディレクトリアーキテクチャを通じて利用可能にすることができる。
【０２５７】
受付は、スティーブの医療記録をその新しい医院と共有することに同意するようにスティーブに求める。スティーブは（スマートフォンで）自分を認証し、医療記録のリストを受信する。そして、どの記録をその医院で利用できるようにするかを確認する。これは、「段階的なアクセス」、すなわち任意のアプリケーションによる情報へのアクセスの、規則に基づく妥当性の確認および拒否を実証するものであり、システムレベルでセキュリティが組み込まれ、リッチなスキーマとデータストレージ／アクセスによってセキュリティがサポートされている。新しい医院で、スティーブは足首を捻挫していると診断される。医院はスティーブの普段の医師に通知を送信する。また、その医師が診断を確認できるようにレントゲン写真も送信する。
【０２５８】
（Ｍ．結論）
プログラミングモデル、スキーマ、ユーザインタフェース、イベント、メッセージング、ストレージ、ディレクトリ、セキュリティ、およびコード管理コンポーネントを備える分散したコンピューティングサービスプラットフォームは、インターネットを利用したより多くの連携と、より多くのウェブサイト間の通信を容易にする。
【０２５９】
本発明は、その精神または基本的な特性から逸脱することなく、他の特定の形態で実施することができる。ここに記載する実施形態は、あらゆる点で例示的なものに過ぎず、制限的なものではないとみなすべきである。したがって、本発明の範囲は、上記の説明ではなく頭記の特許請求の範囲によって示される。特許請求の範囲の均等物の意味と範囲に該当する変更はすべて特許請求の範囲に包含される。
【図面の簡単な説明】
【図１】
本発明に適した動作環境を提供するアーキテクチャの図である。
【図２】
図１のアーキテクチャにわたって分散させた方式で実装することが可能なアプリケーションのプログラミングモデルの図である。
【図３】
本発明によるスキーマストアおよびスキーマサービスの図である。
【図４】
本発明によるユーザインタフェースコンポーネントの略図である。
【図５】
本発明による複数のイベントソースと複数のイベントシンク間にイベント通知を提供するイベントシステムの略図である。
【図６】
本発明で使用するメッセージングアーキテクチャの略図である。
【図７】
本発明で使用するストレージアーキテクチャの略図である。
【図８】
本発明で使用するディレクトリアーキテクチャの略図である。
【図９】
図８のディレクトリアーキテクチャを使用する通信フローの例の図である。
【図１０】
本発明で使用するセキュリティサービスの略図である。
【図１１】
グローバル識別子を使用してプロフィール情報を保持する仕組みを示すデータ構造の図である。
【図１２】
本発明で使用する改良したファイアウォール構成の図である。
【図１３】
ソフトウェア開発で使用するコード管理マニフェストの図である。
【図１】
2004531780.tif 000003
【図２】
2004531780.tif 000004
【図３】
2004531780.tif 000005
【図４】
2004531780.tif 000006
【図５】
2004531780.tif 000007
【図６】
2004531780.tif 000008
【図７】
2004531780.tif 000009
【図８】
2004531780.tif 000010
【図９】
2004531780.tif 000011
【図１０】
2004531780.tif 000012
【図１１】
2004531780.tif 000013
【図１２】
2004531780.tif 000014
【図１３】
2004531780.tif 000015
【国際公開パンフレット】
2004531780.tif 000016
2004531780.tif 000017
2004531780.tif 000018
2004531780.tif 000019
2004531780.tif 000020
2004531780.tif 000021
2004531780.tif 000022
2004531780.tif 000023
2004531780.tif 000024
2004531780.tif 000025
2004531780.tif 000026
2004531780.tif 000027
2004531780.tif 000028
2004531780.tif 000029
2004531780.tif 000030
2004531780.tif 000031
2004531780.tif 000032
2004531780.tif 000033
2004531780.tif 000034
2004531780.tif 000035
2004531780.tif 000036
2004531780.tif 000037
2004531780.tif 000038
2004531780.tif 000039
2004531780.tif 000040
2004531780.tif 000041
2004531780.tif 000042
2004531780.tif 000043
2004531780.tif 000044
2004531780.tif 000045
2004531780.tif 000046
2004531780.tif 000047
2004531780.tif 000048
2004531780.tif 000049
2004531780.tif 000050
2004531780.tif 000051
2004531780.tif 000052
2004531780.tif 000053
2004531780.tif 000054
2004531780.tif 000055
2004531780.tif 000056
2004531780.tif 000057
2004531780.tif 000058
2004531780.tif 000059
2004531780.tif 000060
2004531780.tif 000061
2004531780.tif 000062
2004531780.tif 000063
2004531780.tif 000064
2004531780.tif 000065
2004531780.tif 000066
2004531780.tif 000067
2004531780.tif 000068
2004531780.tif 000069
2004531780.tif 000070
2004531780.tif 000071
2004531780.tif 000072
2004531780.tif 000073
2004531780.tif 000074
2004531780.tif 000075
2004531780.tif 000076
2004531780.tif 000077
2004531780.tif 000078
2004531780.tif 000079
2004531780.tif 000080
2004531780.tif 000081
2004531780.tif 000082
2004531780.tif 000083
2004531780.tif 000084
2004531780.tif 000085
2004531780.tif 000086
2004531780.tif 000087
2004531780.tif 000088
2004531780.tif 000089
2004531780.tif 000090
2004531780.tif 000091
2004531780.tif 000092
2004531780.tif 000093
2004531780.tif 000094
2004531780.tif 000095
2004531780.tif 000096
2004531780.tif 000097
2004531780.tif 000098
2004531780.tif 000099
2004531780.tif 000100
2004531780.tif 000101
2004531780.tif 000102
2004531780.tif 000103
2004531780.tif 000104
2004531780.tif 000105
2004531780.tif 000106
2004531780.tif 000107
2004531780.tif 000108
2004531780.tif 000109
2004531780.tif 000110
2004531780.tif 000111
2004531780.tif 000112
2004531780.tif 000113
2004531780.tif 000114
2004531780.tif 000115
2004531780.tif 000116
【国際公開パンフレット（コレクトバージョン）】
2004531780.tif 000117
2004531780.tif 000118
【国際調査報告】
2004531780.tif 000119
2004531780.tif 000120
2004531780.tif 000121
2004531780.tif 000122
2004531780.tif 000123