(57)【要約】  プレゼンス・プロトコルを用いた一般的な要求／応答プロトコルを提供するための方法およびシステムが説明される。典型的な実施形態によれば、要求エンティティから、応答エンティティに付随するリソースの記述子とリソースに関係する要求とを受け取ることに対するプレゼンス・プロトコルを用いるための方法が説明される。記述子および要求を、プレゼンス・プロトコルを用いて応答エンティティへ送る。プレゼンス・プロトコルを用いて、要求に返答する応答を、応答エンティティから受け取る。応答を要求エンティティへ、プレゼンス・プロトコルを用いて送る。
2008546356.tif 000002
【特許請求の範囲】
【請求項１】
一般的な要求／応答プロトコルを提供するための方法であって、
要求エンティティから、応答エンティティに付随するリソースの記述子と前記リソースに関係する要求とを受け取り、
前記記述子および前記要求を前記応答エンティティへ送り、
前記応答エンティティから、前記要求に返答する応答を受け取り、
前記応答を前記要求エンティティへ送る
ためのプレゼンス・プロトコルを用いることを備える方法。
【請求項２】
前記応答エンティティから前記リソースの記述子を受け取るために前記プレゼンス・プロトコルを用いることを含む、請求項１に記載の方法。
【請求項３】
前記要求エンティティに対して設定された、前記応答エンティティの少なくとも一部のプレゼンス情報へのサブスクリプションに基づいて、前記リソースの記述子を前記要求エンティティへ送るために、前記プレゼンス・プロトコルを用いることを含む、請求項２に記載の方法。
【請求項４】
応答エンティティのプレゼンス情報へのサブスクリプションを要求エンティティに対して設定するときに、要求エンティティの少なくとも一部のプレゼンス情報へのサブスクリプションを応答エンティティに対して自動的に設定するために前記プレゼンス・プロトコルを用いることを備え、
要求を前記応答エンティティへ送ることは、前記応答エンティティに対して自動的に設定される前記サブスクリプションに基づく、請求項３に記載の方法。
【請求項５】
前記応答エンティティの少なくとも一部の前記プレゼンス情報へのサブスクリプションが前記要求エンティティに対して設定されることを示す通知を、前記応答エンティティへ送り、
前記要求エンティティの少なくとも一部のプレゼンス情報へのサブスクリプションに対して、通知に応答して前記応答エンティティから送られるサブスクリプション要求を受け取り、
前記受け取ったサブスクリプション要求に基づいて、前記要求エンティティのプレゼンス情報へのサブスクリプションを、応答エンティティに対して設定する
ために前記プレゼンス・プロトコルを用いることを備え、
前記要求を前記応答エンティティへ送ることは、前記応答エンティティに対して設定される前記サブスクリプションに基づく、請求項３に記載の方法。
【請求項６】
前記応答エンティティの少なくとも一部のプレゼンス情報に対する前記要求エンティティによるフェッチングまたはポーリング要求に応答して、前記リソースの記述子を前記要求エンティティへ送るために、前記プレゼンス・プロトコル用いることを含む、請求項３に記載の方法。
【請求項７】
前記要求を前記応答エンティティへ送ることは、応答エンティティに対して設定された、前記要求エンティティの少なくとも一部のプレゼンス情報へのサブスクリプションに基づく、請求項１に記載の方法。
【請求項８】
前記要求は、前記要求エンティティのプレゼンス情報に含まれる前記応答エンティティの識別子を用いて前記応答エンティティへ送られる、請求項１に記載の方法。
【請求項９】
前記要求は、応答エンティティにより、前記要求エンティティの少なくとも一部のプレゼンス情報に対するフェッチングまたはポーリング要求に応答して前記応答エンティティへ送られる、請求項１に記載の方法。
【請求項１０】
前記応答を前記要求エンティティへ送ることは、前記要求エンティティに対して設定された、前記応答エンティティの少なくとも一部のプレゼンス情報へのサブスクリプションに基づく、請求項１に記載の方法。
【請求項１１】
前記応答は、前記応答エンティティのプレゼンス情報に含まれる前記要求エンティティの識別子を用いて前記要求エンティティへ送られる、請求項１に記載の方法。
【請求項１２】
前記応答は、前記要求エンティティにより、前記応答エンティティの少なくとも一部のプレゼンス情報に対するフェッチングまたはポーリング要求に応答して前記要求エンティティへ送られる、請求項１に記載の方法。
【請求項１３】
前記要求は、前記要求エンティティに付随するプレゼンス情報には含まれるが、前記応答エンティティに付随するプレゼンス情報には含まれず、前記応答は、前記応答エンティティに付随する前記プレゼンス情報には含まれるが、前記要求エンティティに付随する前記プレゼンス情報には含まれない、請求項１に記載の方法。
【請求項１４】
前記応答エンティティに付随する前記プレゼンス情報は、前記リソースのプレゼンス情報または前記リソースのオーナのプレゼンス情報に対応する、請求項１３に記載の方法。
【請求項１５】
前記応答エンティティに付随する前記プレゼンス情報が前記リソースのプレゼンス情報に対応するとき、前記リソースのプレゼンス情報には、前記リソースのオーナのプレゼンス情報へのリンクが含まれる、請求項１４に記載の方法。
【請求項１６】
前記要求エンティティに付随する前記プレゼンス情報は、前記要求エンティティに付随する第２のリソースのプレゼンス情報または前記第２のリソースのオーナのプレゼンス情報に対応し、前記第２のリソースは、前記要求を形成するように構成される、請求項１３に記載の方法。
【請求項１７】
前記要求および応答の各エンティティの識別子を認証すること、
前記要求または応答を対応するエンティティへ送る前に、前記各エンティティが前記要求または応答を受け取ることを認証すること、
を備える、請求項１に記載の方法。
【請求項１８】
前記要求を前記応答エンティティへ前記応答エンティティに付随するファイアウォールを介して送るか、または前記応答を前記要求エンティティへ前記要求エンティティに付随するファイアウォールを介して送るように構成されたプロキシ・サービスを提供すること
を備える、請求項１に記載の方法。
【請求項１９】
前記リソースは、前記応答エンティティに付随するサービス、アプリケーション・プログラム、ファイル、およびデータのうちの少なくとも１つである、請求項１に記載の方法。
【請求項２０】
前記記述子は前記要求に含まれる、請求項１に記載の方法。
【請求項２１】
前記記述子は、前記要求を前記要求エンティティから受け取ることと、前記要求を前記応答エンティティへ送ることにおいて使用される対応するプレゼンス・プロトコル・コマンドのそれぞれに含まれる、請求項１に記載の方法。
【請求項２２】
前記応答エンティティから、第２の応答エンティティに付随する第２のリソースの第２の記述子と第２のリソースに関係する第２の要求とを受け取り、かつ
前記第２の記述子と前記第２の要求とを前記第２の応答エンティティへ送るための前記プレゼンス・プロトコルを用いることを備え、
前記第２の要求は、前記要求エンティティからの前記要求に返答する前記応答に関係する、請求項１に記載の方法。
【請求項２３】
一般的な要求／応答プロトコルを提供するための方法であって、
要求エンティティから、応答エンティティに付随するリソースの記述子と前記リソースに関係する要求とを受け取ること、
前記記述子を用いて、前記応答エンティティのプレゼンス情報を、前記要求を含むように更新すること、
前記要求に返答する応答を含む前記応答エンティティからの前記プレゼンス情報を受け取ること、
前記応答を前記要求エンティティへ送ること
を備える方法。
【請求項２４】
一般的な要求／応答プロトコルを提供するための方法であって、
プレゼンス・サーバを介してリソースの記述子および前記リソースに関係する要求を受け取るためにプレゼンス・プロトコルを用いること、
前記リソースによる前記要求を処理して、前記要求に返答する応答を形成すること、
前記プレゼンス・プロトコルを用いて、前記応答を前記プレゼンス・サーバへ送ること
を含む方法。
【請求項２５】
前記リソースの記述子を前記プレゼンス・サーバへ送るために前記プレゼンス・プロトコルを用いることを含む、請求項２４に記載の方法。
【請求項２６】
一般的な要求／応答プロトコルを提供するための方法であって、
リソースの記述子および前記リソースに関係する要求をプレゼンス・サーバへ送り、
前記プレゼンス・サーバを介して、前記要求に返答する応答を受け取る
ためにプレゼンス・プロトコルを用いる、方法。
【請求項２７】
前記リソースの記述子を前記プレゼンス・サーバから受け取るために前記プレゼンス・プロトコルを用いることを含む、請求項２６に記載の方法。
【請求項２８】
一般的な要求／応答プロトコルを提供するときに、プレゼンス・プロトコルとともに用いるためのデータ構造を含むコンピュータ読取可能な媒体であって、
前記データ構造は、
応答エンティティに付随するリソースの記述子を記憶するための要素を含む、リソース・データ・オブジェクトと、
前記リソースに関係する要求エンティティからの要求を記憶するための要素を含む、要求データ・オブジェクトと、
前記要求に返答する前記応答エンティティからの応答を記憶するための要素を含む、応答データ・オブジェクトと
を含む、コンピュータ読取可能な媒体。
【請求項２９】
前記要求データ・オブジェクトは、前記応答エンティティに付随する前記リソースの記述子に記憶するための要素を含む、請求項２８に記載のコンピュータ読取可能な媒体。
【請求項３０】
前記リソース・データ・オブジェクトは、前記リソースによってサポートされる要求を記述する情報と、前記サポートされた要求に返答するための応答を記述する情報とを記憶するための少なくとも１つの要素を含む、請求項２８に記載のコンピュータ読取可能な媒体。
【請求項３１】
前記要求データ・オブジェクトは、前記応答エンティティの識別子を記憶するための要素を含む、請求項２８に記載のコンピュータ読取可能な媒体。
【請求項３２】
前記応答データ・オブジェクトは、前記要求エンティティの識別子を記憶するための要素を含む、請求項２８に記載のコンピュータ読取可能な媒体。
【請求項３３】
前記要求および応答はそれぞれ、ＳＯＡＰメッセージの構造で形成されるＸＭＬベースのメッセージを含む、請求項２８に記載のコンピュータ読取可能な媒体。
【請求項３４】
前記リソースおよび応答データ・オブジェクトは、前記リソースまたは前記リソースのオーナに付随するプレゼンス・タプルに含まれる、請求項２８に記載のコンピュータ読取可能な媒体。
【請求項３５】
前記リソースおよび応答データ・オブジェクトが、前記リソースに付随するプレゼンス・タプルに含まれるときに、前記リソースに付随する前記プレゼンス・タプルは、前記リソースに付随する前記プレゼンス・タプルを前記リソースのオーナに付随するプレゼンス・タプルにリンクさせるデータ・オブジェクトを含む、請求項３４に記載のコンピュータ読取可能な媒体。
【請求項３６】
前記要求データ・オブジェクトは、前記リソースに付随するプレゼンス・タプルまたは前記要求エンティティに付随する主体に含まれる、請求項２８に記載のコンピュータ読取可能な媒体。
【請求項３７】
前記要求データ・オブジェクトが、前記リソースに付随するプレゼンス・タプルに含まれるときに、前記リソースに付随する前記プレゼンス・タプルは、前記リソースに付随するプレゼンス・タプルを、前記要求エンティティに付随する前記主体に付随するプレゼンス・タプルにリンクさせるデータ・オブジェクトを含む、請求項３６に記載のコンピュータ読取可能な媒体。
【請求項３８】
一般的な要求／応答プロトコルを提供するためのシステムであって、
プレゼンス・プロトコルを用いて情報を受け取り、記憶し、かつ配布するように構成された、プレゼンス・サーバと、
前記プレゼンス・プロトコルを用いて情報を前記プレゼンス・サーバと交換するように構成された、応答装置であって、
少なくとも１つのリソースに対するアクセスと、
前記プレゼンス・サーバを介して、前記リソースの記述子と前記リソースに関係する要求とを受け取るように構成された、応答ウォッチャ・コンポーネントと、
前記要求に返答して、応答を前記プレゼンス・サーバに送るように構成された、応答プレゼンティティ・コンポーネントと
を含む、応答装置と、
前記プレゼンス・プロトコルを用いて情報を前記プレゼンス・サーバと交換するように構成された、要求装置であって、
前記記述子および前記リソースに関係する前記要求を、前記プレゼンス・サーバへ送るように構成された、要求プレゼンティティ・コンポーネントと、
前記プレゼンス・サーバを介して、前記要求に返答する前記応答を受け取るように構成された、要求ウォッチャ・コンポーネントと、
を含む、要求装置と
を備えるシステム。
【請求項３９】
前記応答プレゼンティティ・コンポーネントは、前記リソースの記述子を前記プレゼンス・サーバへ送るようにさらに構成され、前記要求ウォッチャ・コンポーネントは、前記リソースの記述子を前記プレゼンス・サーバから受け取るようにさらに構成される、請求項３８に記載のシステム。
【請求項４０】
前記応答装置は、前記リソースと応答しているプレゼンティティおよびウォッチャ・コンポーネントとに結合される応答ユーザ・エージェント・コンポーネントを含み、前記応答ユーザ・エージェント・コンポーネントは、前記リソースの記述子を前記応答プレゼンティティ・コンポーネントによって送ること、前記応答ウォッチャ・コンポーネントによって受け取られる前記要求のリソースによって処理すること、及び前記応答プレゼンティティ・コンポーネントによって前記応答を送ることを容易にするように構成される、請求項３９に記載のシステム。
【請求項４１】
前記要求装置は、前記要求プレゼンティティおよびウォッチャ・コンポーネントに結合される要求ユーザ・エージェント・コンポーネントを含み、前記要求ユーザ・エージェントは、前記要求ウォッチャ・コンポーネントによって受け取られる前記記述子の提示と、前記要求プレゼンティティ・コンポーネントによる前記要求の送信と、前記要求ウォッチャ・コンポーネントによって受け取られる応答の提示とを容易にするように構成される、請求項３９に記載のシステム。
【請求項４２】
前記プレゼンス・サーバは、前記要求を前記応答ウォッチャ・コンポーネントへ、前記応答装置に付随するファイアウォールを介して送るか、または前記応答を前記要求ウォッチャ・コンポーネントへ、前記要求装置に付随するファイアウォールを介して送るように構成されたプロキシ・サービスを含む、請求項３８に記載のシステム。
【請求項４３】
前記プレゼンス・サーバは、前記要求および応答の各装置の識別子を認証し、かつ要求または応答を対応する装置へ送る前に、前記要求または応答各前記装置による受け取りを認証するように構成されるアカウント・サービスを含む、請求項３８に記載のシステム。
【請求項４４】
前記要求または応答の各前記装置による受け取りを認証するために前記アカウント・サービスによって用いられるロスタおよび／またはプライバシ・リスト情報を含む前記アカウント・サービスに結合されるデータベースを含む、請求項４３に記載のシステム。
【請求項４５】
一般的な要求／応答プロトコルを提供するためのコンピュータ・プログラムを含むコンピュータ読取可能な媒体であって、
前記コンピュータ・プログラムは、
要求エンティティから、応答エンティティに付随するリソースの記述子と前記リソースに関係する要求とを受け取り、
前記記述子および前記要求を前記応答エンティティへ送り、
前記応答エンティティから、前記要求に返答する応答を受け取り、
前記応答を前記要求エンティティへ送る
ためにプレゼンス・プロトコルを用いるための実行可能命令を含むコンピュータ・プログラムを備える、コンピュータ読み取り可能な媒体。
【請求項４６】
前記コンピュータ・プログラムは、前記リソースの記述子を前記応答エンティティから受け取り、かつ前記リソースの記述しを前記要求エンティティへ送るために、前記プレゼンス・プロトコルを用いるための実行可能命令を含む、請求項４５に記載のコンピュータ読取可能な媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、プレゼンス・プロトコルを用いた一般的な要求／応答メッセージング・プロトコルを提供するための方法、システム、およびデータ構造に関する。
【背景技術】
【０００２】
人または物体が存在しているか、そしてやり取りまたは使用に対して利用できるかどうか否かを判定することは、これまで社会において日々行なわれてきた事柄であり、おそらくこの先もそうであろう。技術の発展に伴い、やり取りすべき人または物体のプレゼンスを判定する方法も発展してきた。たとえば、過去２０年間に、コンピュータを用いることおよびワイド・エリア・ネットワーク（ＷＡＮ）（たとえばインターネット）を介してコンピュータのインターネットワーキングを行なうことが爆発的に成長したが、その結果、プレゼンス・サービスが開発されて利用されるようになってきた。プレゼンス・サービスを用いれば、ユーザのプレゼンスをネットワーク上で他のネットワーク・ユーザに伝えることが、コンピューティングおよび／または通信装置を介してのネットワークに対するユーザの接続性に基づいて可能となる。ネットワーク上でのユーザのプレゼンスを説明する情報をアプリケーションおよび／または他のサービスが用いることによって、本明細書において「プレゼンス認識アプリケーション」と言われるものが得られる。
【０００３】
現在、より一般的なプレゼンス認識アプリケーションの１つは、インスタント・メッセージ・ング（またはＩＭ）である。一般的なＩＭアプリケーションとしては、ヤフーのヤフー・メッセンジャ、マイクロソフトのＭＳＮメッセンジャ、およびアメリカ・オンラインのＡＯＬインスタント・メッセンジャ（またはＡＩＭ）がある。ＩＭアプリケーションでは、プレゼンス・サービスを用いることで、ユーザが、他のユーザ（これらのアプリケーションでは「友人」または「仲間」と言われる）が、ネットワーク上に存在する（たとえば接続されている）かどうかを判定できるようになっている。またプレゼンス・サービスを用いると、ユーザのステータス（たとえば、利用可能か、利用可能でないか等）およびユーザと通信するための通信アドレスを決定することもできる。通信アドレスには、ユーザと通信する手段（たとえば、電話機または電子メールを介して）と、対応するコンタクト・アドレス（たとえば、電話番号または電子メール・アドレス）との両方を含めることができる。
【０００４】
一般的にプレゼンス・サービスに付随するアーキテクチャ、モデル、およびプロトコルは、「Ｒｅｑｕｅｓｔ  ｆｏｒ  Ｃｏｍｍｅｎｔｓ」（またはＲＦＣ）の、Ｄａｙらによる、「Ａ  Ｍｏｄｅｌ  ｆｏｒ  Ｐｒｅｓｅｎｃｅ  ａｎｄ  Ｉｎｓｔａｎｔ  Ｍｅｓｓａｇｉｎｇ」と題された２０００年２月に発行の文献ＲＦＣ２７７８、およびＤａｙらによる、「Ｉｎｓｔａｎｔ  Ｍｅｓｓａｇｉｎｇ／Ｐｒｅｓｅｎｃｅ  Ｐｒｏｔｏｃｏｌ」と題された２０００年２月に発行の文献ＲＦＣ２７７９に説明されている。これらはそれぞれ、インターネット協会によって刊行および所有されている。前述した種々のプレゼンス認識ＩＭアプリケーションでは、固有のアーキテクチャおよびプロトコルを用いて、それらのプレゼンス・サービス・コンポーネントを実施する場合があるが、各アプリケーションが用いるプレゼンス・アーキテクチャおよびプロトコルは、ＲＦＣ２７７８およびＲＦＣ２７７９で説明されるプレゼンス・モデルおよびプロトコルと、特徴および機能の点で一致している。
【０００５】
ＲＦＣ２７７８において説明されるプレゼンス・サービス・モデルでは、プレゼンス・サービスの２つの異なるユーザ（プレゼンス「クライアント」と言われる）が説明されている。これらのクライアントの第１は、プレゼンティティ（用語「プレゼンス」と「エンティティ」との組み合わせである）と呼ばれ、記憶しかつプレゼンス・サービスの全体を通して配布すべきプレゼンス情報を提供する。プレゼンス情報には、プレゼンス・サービスのユーザのステータスが含まれ、サービスによって使用される付加情報が含まれる場合もある。この付加情報には、たとえば、通信手段およびユーザの契約アドレスが含まれる（前述している）。プレゼンス情報は、プレゼンス・サービスが利用できるような任意の形態で記憶または維持することができるが、通常は、プレゼンス・タプルと言われる部分にまとめられている。当業者であれば理解するように、タプル（その最も広い意味において）は、２つ以上のコンポーネントを含むデータ・オブジェクトである。こうして、プレゼンス・タプルには、ユーザの識別子およびユーザのステータス、コンタクト・アドレス、またはプレゼンス・サービスによって使用される他の情報が含まれる。
【０００６】
プレゼンス・クライアントの第２のタイプは、「ウォッチャ」と言われる。ウォッチャは、プレゼンス・サービスからプレゼンス情報を受け取る。ＲＦＣ２７７８のプレゼンス・モデルで説明されるウォッチャのタイプは、「サブスクライバ」および「フェッチャ」と言われるものである。サブスクライバが、プレゼンス・サービスからプレゼンティティの一部のプレゼンス情報の変化の通知を要求する。プレゼンス・サービスは、サブスクライバの代わりに、プレゼンティティのプレゼンス情報へのサブスクリプションを設定して、プレゼンティティのプレゼンス情報の将来の変化がサブスクライバに「押し出される」ようにする。対照的に、ウォッチャのフェッチャ・クラスは、プレゼンティティの一部のプレゼンス情報の現在値を、プレゼンス・サービスから要求（または取得）する。したがってプレゼンス情報は、プレゼンス・サービスからプレゼンティティへ「引き出される」ということができる。特別な種類のフェッチャ（「ポーラ」と言われる）が、モデルにおいて規定されている。これは、定期的（またはポーリング）ベースで情報を取得するものである。
【０００７】
またプレゼンス・サービスは、ウォッチャに付随するプレゼンス情報を管理し、記憶し、かつ配布することができるだけでなく、プレゼンス・サービスを用いて他のプレゼンス・クライアントのプレゼンス情報に対して取得またはサブスクライブすることに関してのウォッチャの活動度を管理し、記憶し、かつ配布することができる。この「ウォッチャ情報」は、プレゼンス・サービスによって他のウォッチャに配布することができる。その際に用いられるメカニズムは、プレゼンティティのプレゼンス情報を配布する際に利用できるメカニズムと同じものである。当然のことながら、モデルでは、プレゼンティティとウォッチャとは別個のエンティティとして説明されているが、これらのエンティティを機能的に組み合わせて、プレゼンティティおよびウォッチャの両方の特性を有する単一のプレゼンス・エンティティとすることができる。したがって、語句「プレゼンス・エンティティ」（用語「プレゼンティティ」とは異なる）またはより単純に用語「エンティティ」に、適切な修飾語（たとえば、応答、要求、受け取り、または送り）を付けたものを、この文献全体を通して使用して、プレゼンティティ、ウォッチャ、サブスクライバ、フェッチャ、またはポーラ・エンティティ（前記した）のすべてのうちの任意の１つまたは任意の組み合わせを記載することにする。
【０００８】
プレゼンス・サービスのユーザは、ＲＦＣ２７７８において説明されるプレゼンス・モデルでは、主体といわれる。通常、主体は、プレゼンス・モデルの外側に存在する人またはグループであるが、プレゼンス・サービスとやり取りすることができるソフトウェアまたは他のリソースをも表わす。モデルは、主体の必要条件も機能も規定しないが、２つの異なる主体は別個であること、また２つの同一の主体は同一であることを記載している。この文献の目的上、この主体の厳密な解釈は採用すべきではない。すなわち、２つの異なる主体は別個である必要はなく、また２つの同一の主体は同一である必要はない。たとえば、第３世代パートナーシップ・プロジェクト（３ＧＰＰ）には、プレゼンス・サービスをそのユニバーサル移動体通信システム（ＵＭＴＳ）へ組み込むための標準として、ＵＭＴＳのユーザに対して「公開識別子」の使用を規定するものが含まれている。特定のＵＭＴＳユーザが、複数の公開識別子を有する場合もある。結果として、以上のような公開識別子を主体と解釈すべき場合には、主体としての公開識別子は、複数のプレゼンス・クライアントに付随させることができる。
【０００９】
ＲＦＣ２７７８で説明される一般的なプレゼンス・モデルによれば、主体はプレゼンス・システムとのやり取りを、プレゼンス・ユーザ・エージェント（ＰＵＡ）またはウォッチャ・ユーザ・エージェント（ＷＵＡ）を通して行なわれる。これらのユーザ・エージェントがやり取りするプレゼンティティおよびウォッチャ・クライアントに場合と同様に、プレゼンスおよびウォッチャ・ユーザ・エージェントを機能的に組み合わせて、プレゼンスおよびウォッチャ・ユーザ・エージェントの両方の特性を有する単一のユーザ・エージェントとすることができる。ユーザ・エージェントは、それらの機能がプレゼンス・サービスの内部に、プレゼンス・サービスの外部に、またはプレゼンス・サービスの内部および外部の組み合わせまたは両方に存在するように、実施することができる。
【００１０】
ほとんどのプレゼンス認識アプリケーション（たとえばＩＭ）では、プレゼンス・サービスを用いるのは、アプリケーション・ユーザのプレゼンス、ステータス、および通信アドレスを決定するためだけである。たとえば、ＩＭアプリケーションでは、プレゼンス・サービス自体を用いて、コアとなるアプリケーション・サービスおよび情報（たとえばインスタント・メッセージ自体）をそのユーザへ送出することはしない。より具体的には、ＩＭアプリケーションでは、ベース・プレゼンス・プロトコル・メッセージ（またはコマンド）を用いて、インスタント・メッセージ情報を交換することはしないが、その代わりに、別個で明確なインスタント・メッセージ・プロトコル（たとえば、ＲＦＣ２７７８およびＲＦＣ２７７９を参照）に基づいて、この情報を交換する。
【００１１】
同様に、他のプレゼンス認識アプリケーションおよびプレゼンス・サービスに対する拡張機能の場合は、新しいプロトコルを用いてこれらのアプリケーションまたは拡張サービスをサポートするであろうことが予想される。たとえば、要求／応答サービスを提供することができるプレゼンス認識アプリケーションを形成するために、開発者は、特定の要求／応答プロトコル（プレゼンス・プロトコルとは別個に）を用いて、要求／応答サービスをサポートすることが予想される。要求／応答プロトコルの例としては、ハイパーテキスト・トランスファー・プロトコル（ＨＴＴＰ）（たとえば、クライアントとサーバとの間でインターネットを介して情報を交換するために使用される）、および簡易メール転送プロトコル（ＳＭＴＰ）（電子メール・メッセージをネットワーク上で交換するために使用される）が挙げられる。
【００１２】
実際には、Ｓａｉｎｔ−Ａｎｄｒｅによる、「Ｅｘｔｅｎｓｉｂｌｅ  Ｍｅｓｓａｇｉｎｇ  ａｎｄ  Ｐｒｅｓｅｎｃｅ  Ｐｒｏｔｏｃｏｌ（ＸＭＰＰ）：コア（Ｃｏｒｅ）」と題された、２００４年１０月に発行された標準化過程刊行物であるＲＦＣ３９２０、およびサン・タンドレにより、「Ｅｘｔｅｎｓｉｂｌｅ  Ｍｅｓｓａｇｉｎｇ  ａｎｄ  Ｐｒｅｓｅｎｃｅ  Ｐｒｏｔｏｃｏｌ（ＸＭＰＰ）：Ｉｎｓｔａｎｔ  Ｍｅｓｓａｇｉｎｇ  ａｎｄ  Ｐｒｅｓｅｎｃｅ」と題された２００４年１０月に発行されたＲＦＣ３９２１（それぞれインターネット協会の刊行および所有）では、プレゼンスおよび要求／応答サービスをサポートするために別個のプロトコルを用いることが想定されている。これらの刊行物では、任意の２つのネットワーク・エンド・ポイント間でリアル・タイムに近いところで構造化情報を交換するための拡張可能マークアップ言語（ＸＭＬ）要素をストリーミングするためのプロトコルを説明している。プレゼンス情報および要求／応答情報の両方を組み合わせて、プレゼンス・プロトコルのみを用いて伝えられる共通のＸＭＬスタンザにするのではなく、ＸＭＰＰによって、プレゼンス情報を伝えるための第１のＸＭＬスタンザ（「／ｐｒｅｓｅｎｃｅ」スタンザ）と、要求／応答情報を伝えるための別個の第２のＸＭＬスタンザ（「／ｉｑ」スタンザ）との使用を規定する（たとえば、ＲＦＣ３９２０；セクション９を参照のこと）。そしてこれらの別個のスタンザは、対応するプレゼンスおよび要求／応答プロトコル層によって伝えられる。
【００１３】
他の文献においても、プレゼンス・サービスを用いてアプリケーション情報を送るための構成が説明されているが、プレゼンス・プロトコルを用いて一般的な要求／応答サービスを提供することは扱われていない。たとえば、Ｇｏｕｒｒａｕｄによる「ＴＲＡＮＳＭＩＳＳＩＯＮ  ＯＦ  ＡＰＰＬＩＣＡＴＩＯＮ  ＩＮＦＯＲＭＡＴＩＯＮ  ＡＮＤ  ＣＯＭＭＡＮＤＳ  ＵＳＩＮＧ  ＰＲＥＳＥＮＣＥ  ＴＥＣＨＮＯＬＯＧＹ」と題された米国特許出願第２００４１０１２２８９６Ａ１号明細書では、特定のアプリケーション用のアプリケーション情報またはコマンドをプレゼンス・タプルの形態で公開するプレゼンス・エンティティが説明されている。ウォッチャは、特定のアプリケーションに付随するプレゼンス情報にサブスクライブし、そしていったん許可されると、アプリケーション情報またはコマンドとともにタプルを受け取る。
【００１４】
第１の実施形態では、Ｇｏｕｒｒａｕｄの構成において、アプリケーション識別子がユーザ機器からアプリケーション・サーバへ、プレゼンス・サービスを用いて送られる。そしてアプリケーション・サーバは、所定の情報をユーザ機器へ、プレゼンス・サービスを用いて送る。この構成では、ユーザ機器は、特定の情報またはサービスをアプリケーション・サーバから得ることは要求できない。所定の情報を受け取ることができるだけである。実際には、Ｇｏｕｒｒａｕｄの第１の実施形態では、要求をユーザ機器からアプリケーションへプレゼンス・サービスまたはプレゼンス・プロトコルを用いて送るためのメカニズムは何ら説明されていない。第２の実施形態では、Ｇｏｕｒｒａｕｄの構成において、コマンドをユーザ機器からアプリケーション・サーバへ、プレゼンス・サービスを用いて送ることができる。コマンドがサーバによって実行されたという確認応答だけが、ユーザ機器へ送られる。また確認応答は、プレゼンス・プロトコルとは別個のプロトコルを用いて送られる。すなわちインスタント・メッセージ確認が、セッション開始プロトコル（ＳＩＰ）を用いて送られる。したがって、Ｇｏｕｒｒａｕｄの第２の実施形態では、アプリケーション・サーバからユーザ機器へ送られる応答はなく、また実施形態では、プレゼンス・サービスまたはプレゼンス・プロトコルを用いてこのような応答を送るためのメカニズムは何ら説明されていない。
【発明の開示】
【発明が解決しようとする課題】
【００１５】
要求／応答サービスを提供することができるプレゼンス認識アプリケーションを、複数のプロトコルを用いてサポートするのではなくて、プレゼンス・サービスおよびその下にあるプレゼンス・プロトコルを用いて、一般的な要求／応答メッセージング・プロトコルを提供するための構成がより効率的で望ましい。
【課題を解決するための手段】
【００１６】
したがって、プレゼンス・プロトコルを用いて一般的な要求／応答プロトコルを提供するための方法およびシステムが開示される。典型的な実施形態によれば、要求エンティティから、応答エンティティに付随するリソースの記述子とリソースに関係する要求とを受け取ることと、記述子および要求を応答エンティティへ送ることと、応答エンティティから、要求メッセージに返答する応答を受け取ることと、応答を要求エンティティへ送ることと、に対するプレゼンス・プロトコルを用いるための方法が説明される。
【００１７】
別の典型的な実施形態によれば、プレゼンス・プロトコルを用いて一般的な要求／応答プロトコルを提供するための方法が開示される。本方法は、プレゼンス・サーバを介してリソースの記述子およびリソースに関係する要求を受け取ることと、リソースによって要求を処理して、要求に返答する応答を形成することと、要求メッセージに返答する応答をプレゼンス・サーバへ送ることと、を含む。
【００１８】
さらに別の典型的な実施形態によれば、プレゼンス・プロトコルを用いて一般的な要求／応答プロトコルを提供するための方法が開示される。本方法は、リソースの記述子およびリソースに関係する要求をプレゼンス・サーバへ送ることと、プレゼンス・サーバを介して、要求メッセージに返答する応答を受け取ることとを含む。
【００１９】
さらに他の典型的な実施形態によれば、一般的な要求／応答プロトコルを提供するときにプレゼンス・プロトコルとともに用いるためのデータ構造を含むコンピュータ読取可能な媒体が開示される。データ構造は、応答エンティティに付随するリソースの記述子を記憶するための要素を含むリソース・データ・オブジェクトと、要求エンティティからの、リソースに関係する要求を記憶するための要素を含む要求データ・オブジェクトと、応答エンティティからの、要求メッセージに返答する応答を記憶するための要素を含む応答データ・オブジェクトと、を含む。
【００２０】
別の典型的な実施形態によれば、一般的な要求／応答プロトコルを提供するためのシステムが説明される。本システムは、プレゼンス・プロトコルを用いて情報を受け取り、記憶し、配布するように構成されたプレゼンス・サーバを含む。応答装置が、プレゼンス・プロトコルを用いて情報をプレゼンス・サーバと交換するように構成される。応答装置は、少なくとも１つのリソースに対するアクセスと、プレゼンス・サーバを介して、リソースの記述子とリソースに関係する要求とを受け取るように構成された応答ウォッチャ・コンポーネントと、要求メッセージに返答する応答をプレゼンス・サーバに送るように構成された応答プレゼンティティ・コンポーネントと、を含む。またシステムは、プレゼンス・プロトコルを用いて情報をプレゼンス・サーバと交換するように構成された要求装置を含む。要求装置は、記述子およびリソースに関係する要求をプレゼンス・サーバへ送るように構成された要求プレゼンティティ・コンポーネントと、プレゼンス・サーバを介して、要求メッセージに返答する応答を受け取るように構成された要求ウォッチャ・コンポーネントと、を含む。
【発明を実施するための最良の形態】
【００２１】
添付の図面による視覚表現は、本明細書で開示される典型的な実施形態をより十分に説明するために使用されるものであり、また当業者によって、典型的な実施形態およびそれらの固有の利点をより良好に理解するために使用されるものである。これらの図面において、同じ参照番号は、対応する要素を特定している。
【００２２】
次に、種々の態様について、典型的な実施形態に関連して説明する。この実施形態には、コンピュータ・システムの要素が行なう動作の手順という形で記述される特定の態様が含まれる。たとえば、次のことが分かる。すなわち、各実施形態において、種々の動作の実施は、専門の回路または回路構成（たとえば、専門の機能を行なうように接続された別個のおよび／または集積化された論理ゲート）によって、プログラム命令を１つまたは複数のプロセッサによって実行することによって、または両方の組み合わせによって、行なわれる。こうして、種々の態様を多くの異なる形態で具体化される。なお、このような形態はすべて、説明の範囲内であることが意図されている。
【００２３】
プレゼンス・サービスに付随するアーキテクチャ、モデル、およびプロトコルを説明する際、この文献では、ＲＦＣ２７７８およびＲＦＣ２７７９で説明される用語を用いる。現在使用されている種々のプレゼンス・サービスおよびプレゼンス・プロトコル実施形態には違いがあるが、これらの実施形態はすべて、使用するプレゼンス・アーキテクチャおよびプロトコルが、ＲＦＣ２７７８およびＲＦＣ２７７９で説明されるプレゼンス・モデルおよびプロトコルと、特徴および機能の点で一致している。したがって、本明細書で使用される用語は、現在使用されているプレゼンス・モデル、サービス、および／またはプロトコル実施形態のいずれか１つに限定してはならない。
【００２４】
たとえば、現在のプレゼンス・プロトコルはそれぞれ、機能上の点から一群の共通のメッセージ（またはコマンド）をサポートする（たとえば、ＲＦＣ２７７９を参照）。これらの機能上のコマンドには、
公開：プレゼンス・エンティティ（ＰＵＡ／プレゼンティティを通して）が、その自身のプレゼンス情報（たとえばそのステータスまたはコンタクト情報）を、プレゼンス・サーバに対して更新／提供するコマンドと、
通知：プレゼンス・サーバが、プレゼンス・タプルからの情報をＷＵＡ／ウォッチャに提供するコマンドであって、通知は、ポイント・ツー・ポイント（たとえば、次の段落で説明するような宛て先の公開／通知コマンド）であっても良いし、一斉送信であっても良いコマンドと、
サブスクライブ（アンサブスクライブ）：ＷＵＡ／ウォッチャが、特定のプレゼンス情報に関係する通知をサブスクライブまたはアンサブスクライブするコマンドと
が含まれる。語句「プレゼンス・プロトコル」には、本明細書で用いる場合、少なくとも次のようなコマンドが含まれる。すなわち、エンティティが、プレゼンス情報を公開し、エンティティに他のエンティティのプレゼンス情報を通知することができるコマンド、およびエンティティが、他のエンティティのプレゼンス情報にサブスクライブ（アンサブスクライブ）するコマンドである。
【００２５】
また複数の任意的な、機能的に等価なプレゼンス・コマンドが存在する。これらの任意的なコマンドには、
精査：プレゼンス・サービスがプレゼンス・エンティティに付随する情報を得るコマンドであって、これは、プレゼンス・サービスが、プレゼンス・クライアントに要求外の情報を送らせることを要求するのではなくてプレゼンス情報を要求することを除いて、通知／公開コマンドの組み合わせと同等であるコマンドと、
宛て先の公開／通知：クライアントが公開コマンドを出すことができる結果、通知コマンドが特定のプレゼンス・クライアントに送られるために、サブスクリプション機能がバイパスされるコマンドと
が含まれる。
【００２６】
またプレゼンス・サービスに関係する「友人リスト」（または「ロスタ」）を管理するための機能的に等価なコマンドの組が存在する。このコマンドの組には、
要求：クライアントが特定のまたはデフォルトのロスタを要求するコマンドと、
付加：クライアントが、プレゼンス・エンティティに対する項目をロスタに加えるコマンドと、
更新：クライアントが、ロスタ項目を更新するコマンドと、
削除：クライアントが、ロスタから項目を削除するコマンドと
が含まれる。プライバシ・リストが、ロスタに関係する。プライバシ・リストは一般的に、ロスタ／プライバシ・リストのオーナとのやり取りを妨げるべきプレゼンス・クライアントを特定するように構成されたロスタを用いて記述される。
【００２７】
次に、図１を参照すると、プレゼンス・プロトコルを用いて一般的な要求／応答プロトコルを提供するシステム１００が示されている。システムには、プレゼンス・サービス１２０を介して情報を受け取り、記憶し、および配布するように構成されたプレゼンス・サーバ１１８が含まれる。システムにはさらに、プレゼンス・プロトコルを用いてネットワーク１１６を介してプレゼンス・サーバ１１８と情報を交換するように構成された応答および要求装置１０２が含まれる。応答および要求装置１０２には、パーソナル・コンピュータ（ＰＣ）、携帯情報端末（ＰＤＡ）、ネットワーク対応カメラ、カメラ付き携帯電話、携帯電話などのうちの何れかが含まれる。
【００２８】
図１ではスタンド・アローンのサーバとして示しているが、プレゼンス・サーバ１１８は複数のサーバ（図示せず）を含むことができ、これらが全体としてプレゼンス・サービス１２０として機能する。また、プレゼンス・サーバ１１８の機能は、全部または一部を、図示した装置１２０およびサーバ１１８の何れかに組み込むことができ、その結果、図示した要素のネットワーク全体に渡って配布することができる。したがって、本明細書で用いられる「プレゼンス・サーバ」の意味は、プレゼンス・サービスの不可分の単位としてＲＦＣ２７７８に含まれる「サーバ」の定義には、厳密には適合しない。しかしながら、プレゼンス・サーバ１１８およびプレゼンス・サービス１２０は、互いに密接にリンクしており、同じ１つの機能を行なうものと考えることができる。しかし本明細書で用いる場合、プレゼンス・サーバ１１８には、付加的なサービスが含まれていても良い。たとえば、図１に示すアカウント・サービス１２２およびプロキシ・サービス１２４である。ただし、これらの付加的なサービスは、サーバ１１８に含まれている必要はない。当然のことながら、これらの付加的なサービスも、ネットワーク１１６を介して接続された１つまたは複数のサーバまたは装置１０２に渡って配布することができる。
【００２９】
応答装置は、たとえばＰＣ（たとえば図１に示すＰＣ１０２ｂ）である。応答装置１０２ｂには、少なくとも１つのリソースに対するアクセスが含まれる。リソースは、応答装置に付随する任意のサービス、アプリケーション、ファイル、または他の情報であって、ネットワーク１１６を介して要求装置（カメラ１０２ａまたはカメラ付き携帯電話１０２ｃなど）での利用または要求装置とのやり取りに利用できる情報である。たとえば、図１に示すのは、応答装置１０２ｂが、サービス１０４（たとえば、写真を共有するウェブサイトなどのウェブ・サービス）、ソフトウェア・アプリケーション１０８、およびファイル１１２（たとえば画像ファイル）を含むリソースを提供する場合である。要求装置（たとえばカメラ１０２ａまたはカメラ付き携帯電話１０２ｃ）は、これらのリソースに関連する情報またはサービスを、ネットワーク１１６を介してプレゼンス・サービス１２０を用いて、要求することができる。
【００３０】
図２は、応答および／または要求ネットワーク装置１０２を構成する種々のコンポーネントを例示するブロック図である。便宜上、図２に示す配置は、応答装置および要求装置の両方として機能するネットワーク装置を表わしている。しかしながら、当業者であれば理解するように、応答装置には、要求装置として機能するために必要なコンポーネントが含まれている必要はなく、逆もまた同様である。また、図には、応答／要求プレゼンティティ・コンポーネント２０２および応答／要求ウォッチャ・コンポーネント２０４が含まれている。当然のことながら、これらのコンポーネントをそれぞれ組み合わせて、対応する単一のプレゼンティティ２０２もしくはウォッチャ２０４コンポーネントにすることもできるし、別個の応答および要求エンティティとして実施することもできる。これについては後に記載する。
【００３１】
最初に、図２の配置を、応答装置（たとえばＰＣ１０２ｂ）の点から考える。この点から、配置には、応答プレゼンティティ・コンポーネント２０２が含まれる。典型的な実施形態によれば、応答プレゼンティティ・コンポーネント２０２は、リソース１０４、１０８、１１２の記述子をプレゼンス・サーバ１１８へ送るように構成される。記述子は、応答装置が利用できるリソース１０４、１０８、１１２の何れかを記載および／または特定する任意の情報を含む。また記述子は、要求を処理するために要求装置がこれらのリソースを利用できるということを宣伝するために用いられる。
【００３２】
たとえば、図２には、応答装置１０２ｂが、ウェブ・サービス１０４（写真を共有するウェブ・サービス１０４ａおよび他のウェブ・サービス１０４ｂを含む）、ファイル・システム１１２、印刷サービス１０４ｃ、およびカメラ・サービス１０４ｄにアクセスできる状態を示す。記述子は、単にリソースを名前によって特定することもできるし、ネットワーク１１６に結合された他のプレゼンス・エンティティに対してリソースを記述または特定するための他の情報を含むこともできる。応答プレゼンティティ・コンポーネント２０２は、リソースの記述子をプレゼンス・サーバ１１８に送ることが、記述子をプレゼンス情報に含むことによって可能である。これについては、以下に図４〜６に関連して説明する。記述子を含むプレゼンス情報は、公開コマンドを用いてプレゼンス・プロトコルを介して、プレゼンス・サーバ１１８に送ることができる。こうして、記述子を用いて、応答装置のプレゼンス情報にサブスクライブされた他のプレゼンス・エンティティに対してリソースが利用できることを、宣伝する。
【００３３】
代替的な実施形態では、応答プレゼンティティ・コンポーネント２０２が、リソース１０４、１０８、１１２の記述子をプレゼンス・サーバ１１８に送って要求の処理にリソースが利用できることを宣伝する必要はない。その代わりに、プレゼンス・サーバ１１８に結合された要求装置が、記述子を伴わない標準化された要求を一斉送信して、プレゼンス・サーバ１１８に結合された応答装置に付随するリソース１０４、１０８、１１２のすべてのうちの何れかを用いてネットワーク１１６を介して処理するようにする。
【００３４】
図２の配置を、応答装置１０２ｂの点から引き続き考えると、配置にはさらに、応答ウォッチャ・コンポーネント２０４が含まれる。応答ウォッチャ・コンポーネント２０４は、要求装置（たとえば、カメラ付き携帯電話１０２ｃ）から、プレゼンス・サーバ１１８を介して、リソース１０４、１０８、１１２の記述子およびリソースに関係する要求を受け取るように構成されている。プレゼンス・サーバ１１８は、記述子および要求を応答ウォッチャ・コンポーネント２０４に、プレゼンス・プロトコルを介して、通知コマンドを用いて送られる。記述子および要求を含む通知コマンドは、要求装置１０２ｃのプレゼンス情報へのサブスクリプションに基づいて、応答ウォッチャ・コンポーネント２０４へ送っても良い。これは、応答装置１０２ｂへ送出するために要求装置１０２ｃが送る宛て先の公開／通知コマンドの結果として、または応答装置１０２ｂが起こすフェッチまたはポーリング要求に応答して、行なっても良い。
【００３５】
図４〜６に関連して後に記載するように、リソースの記述子は、要求自体に含めることもできるし、要求を要求装置から応答装置へ伝えるために用いるプレゼンス・プロトコル・コマンド（たとえば前述の通知コマンド）に含めることもできる。記述子は、要求を、応答装置１０２ｂが利用できる特定のリソース１０４、１０８、１１２に関連付けるために用いられる。また要求メッセージは、リソース要求を伝えるために用いられる。したがって応答装置１０２ｂは、異なるリソース１０４、１０８、１１２に対する複数の要求の処理、ネットワーク１１６に接続される種々の要求装置１０２ｃに対応して行なわれる。
【００３６】
再び図２の配置を、応答装置１０２ｂの点から考えると、応答プレゼンティティ・コンポーネント２０２はさらに、プレゼンス・サーバ１１８に応答を送って要求メッセージに返答するように構成される。応答プレゼンティティ・コンポーネント２０２は、プレゼンス・サーバ１１８に応答を送ることが、プレゼンス情報に応答を含むことによって可能である。これについては、図４〜６に関連して後に記載する。応答を含むプレゼンス情報は、一斉送信または宛て先の公開コマンドの何れかを用いてプレゼンス・プロトコルを介して、プレゼンス・サーバ１１８に送られる。
【００３７】
典型的な実施形態によれば、応答装置は、応答ユーザ・エージェント（ＲＳＵＡ）を含む。ＲＳＵＡコンポーネントは、リソース１０４、１０８、１１２に、および応答プレゼンティティ２０２およびウォッチャ２０４コンポーネントに、結合される。前記したＰＵＡおよびＷＵＡコンポーネントと同様に、ＲＳＵＡは、応答プレゼンティティ２０２およびウォッチャ２０４コンポーネントと、主体の代わりにやり取りする。一般的に、ＲＳＵＡは、リソース１０４、１０８、１１２と、その主体としてやり取りするが、ＲＳＵＡは、リソースのオーナだけでなく他の主体ともやり取りすることができる。
【００３８】
ＲＳＵＡコンポーネントは、応答プレゼンティティ・コンポーネント２０２がリソースの記述子を送ってネットワーク１１６に結合される他のプレゼンス・エンティティにリソースを宣伝することが容易になるように、構成される。ＲＳＵＡコンポーネントは、リソース１０４、１０８、１１２と直接やり取りして記述子を決定および公開することもできるし、リソースのオーナがプレゼンス・プロトコルを用いてリソースの記述子を公開するのに適切なインターフェースを提供することもできる。リソースのオーナに対してインターフェースを提供するために、ＲＳＵＡを、ユーザ通信クライアント１１０または任意の数の付随する通信クライアントに結合する。通信クライアントは、たとえば、ＩＭ通信クライアント１１０ｂ、電話クライアント１１０ｃ、電子メール・クライアント１１０ｄ、マルチメディア・メッセージング・サービス（ＭＭＳ）クライアント１１０ｄ、およびブラウザ・クライアント１１０ｆ（一括して、通信クライアント１１０）である（図２に示す）。
【００３９】
たとえば、図３では、リソース１０４、１０８、１１２のオーナが用いるインターフェースが例示されている。オーナは、このインターフェースを用いて応答プレゼンティティ・コンポーネント２０２とやり取りして、リソースの記述子を公開する。ＩＭクライアント１１０ｂを用いて、典型的なインターフェースは、ディスプレイ３００上に「友人リスト」３０２の形式で示される。これは、ＩＭアプリケーションに詳しい者にはすぐに分かるものである。友人リスト３０２には、人的資源オーナの名前（たとえば、ジョン、ポール、ジョージ、およびリンゴ）、および／または非人的資源オーナの名前（たとえば、サーバ１）が含まれる。また友人リスト３０２には、以下のものを特定する情報が含まれる。すなわち、表示された各オーナに付随するリソース（許可された要求エンティティに提供される）とともに、提供されたリソースのステータスである。たとえば、典型的なリスト３０２におけるジョンに付随するリソースには、以下のものを含めることができる。印刷サービス（利用可能でない（Ｎ／Ａ））、ウェブ・サービス（写真共有サービス（利用可能）を含む）、ＩＭサービス（利用可能）、およびファイル・システム（利用可能でない（Ｎ／Ａ））。
【００４０】
またインターフェース３０２には、動作メニュー項目３０６が含まれる。この動作メニューは、リソースに付随するコマンドを呼び出すのに好適である。動作メニューは、以下のものを行なうために、エントリ３０６ａを含むことができる。すなわち、リソースを公開する、要求に対する応答を公開する、リソースに付随する要求を公開する、リソースに付随する情報にサブスクライブする、およびリソースに関係する要求に付随する情報にサブスクライブする、である。対応するダイアログ・ボックス（図示せず）を示して、選択された動作を行なうために必要な情報を収集する。
【００４１】
ＲＳＵＡはさらに、応答ウォッチャ・コンポーネント２０４が受け取る要求を、リソース１０４、１０８、１１２が容易に処理できるように構成される。ＲＳＵＡは、要求を適切なリソース１０４、１０８、１１２へ転送して処理するように構成されてもよいし、要求を、それがリソースへ転送される前に、インタープリットおよび／または前処理してもよい。たとえば、要求が、写真を共有するウェブ・サービス１０４ａ（図２に例示する）へのアクセスに関係づけられていた場合、ＲＳＵＡは、要求を適切なＨＴＴＰゲット要求に変換した後、要求をウェブ・サービスへ転送して処理する（たとえば、要求されるフォト・ウェブ・ページを提供する）。
【００４２】
ＲＳＵＡは、何らユーザ介入がない状態で要求を容易に処理してもよいし、または適切であれば、情報（たとえば許可）をリソースのオーナから収集するための好適なインターフェースとなってもよい。たとえば、図３に示すインターフェース３０２は、ユーザであるジョージが、印刷サービス（たとえば、図２のサービス１０４ｃ）へのアクセスを、印刷ジョブ要求を出すことによって要求したことを表示するダイアログ・ボックス３０４の例として示されている。印刷サービスのオーナは、適切なダイアログ・ボックス制御を選択することによって、要求を受け入れるかまたは拒否することができる。要求が、印刷サービスのオーナによって受け入れられた場合には、ＲＳＵＡは、要求を印刷サービスへ転送して、要求の何らかのトランスレーションを必要に応じて行なうことができる。
【００４３】
加えて、ＲＳＵＡはさらに、要求に対する応答を応答プレゼンティティ・コンポーネント２０２が容易に送れるように、構成される。記述子を公開する場合と同様に、ＲＳＵＡコンポーネントは、リソース１０４、１０８、１１２と直接やり取りして、要求に対する応答を決定および公開するし、リソースのオーナがプレゼンス・プロトコルを用いて応答を公開するのに適切なインターフェースを提供する。たとえば、図３の動作エントリ・リスト３０６ａに含まれる「応答を公開する」エントリを選択すると、適切なダイアログ・ボックス（図示せず）を示して、要求に対する応答の形成に必要な情報を収集する。次にＲＳＵＡは、応答を応答プレゼンティティ・コンポーネント２０２へ転送して公開し（おそらくは適切なＰＵＡの支援を伴って）、必要に応じて応答の任意の変換を行なう。
【００４４】
応答プレゼンティティ２０２およびウォッチャ２０４コンポーネント、リソース１０４、１０８、１１２、ならびに通信クライアント１１０の間での情報の交換を容易にする際に、ＲＳＵＡは、適切なＰＵＡおよび／またはＷＵＡとともに動作してもよいし、これらのエージェントの動作をバイパスしてもよい。また、当然のことながら、特定のリソースに対するＲＳＵＡを、そのリソースに付随するＰＵＡおよび／またはＷＵＡと組み合わせることもできるし、特定の装置および／またはオーナに付随するすべてのリソースに対する応答ユーザ・エージェントの機能を果たすように構成することもできる。ＰＵＡおよびＷＵＡの場合と同様に、ＲＳＵＡは、その機能が、プレゼンス・サービスの内部に、プレゼンス・サービスの外部に、またはプレゼンス・サービスの内部および外部の組み合わせまたは両方に存在するように、実施することができる。
【００４５】
次に、図２の配置を要求装置（たとえば図１に示すカメラ付き携帯電話１０２ｃ）の観点から、考える。この観点から、配置には、要求ウォッチャ・コンポーネント２０４が含まれる。要求ウォッチャ・コンポーネント２０４は、リソース１０４、１０８、１１２の記述子を、プレゼンス・サーバ１１８から送られた場合に、受け取るように構成される。プレゼンス・サーバ１１８は、記述子を要求ウォッチャ・コンポーネント２０４に、通知コマンドを用いてプレゼンス・プロトコルを介して、送られる。記述子を含む通知コマンドを、要求ウォッチャ・コンポーネント２０４へ、応答装置１０２ｂのプレゼンス情報へのサブスクリプションに基づいて送ってもよい。これは、要求装置１０２ｃへ送出するために応答装置１０２ｂが送る宛て先の公開／通知コマンドの結果として、または要求装置１０２ｃが起こすフェッチまたはポーリング要求に応答して、行なってもよい。リソースの記述子は、応答装置に付随するプレゼンス情報に含めることもできるし、応答装置から要求装置へプレゼンス情報を伝えるために用いられるプレゼンス・プロトコル・コマンド（たとえば前述の通知コマンド）に含めることもできる。
【００４６】
引き続いて図２の配置を要求装置１０２ｃの観点から考えると、配置にはさらに、記述子およびリソースに関係する要求をプレゼンス・サーバ１１８へ送るように構成された要求プレゼンティティ・コンポーネント２０２が含まれる。要求プレゼンティティ・コンポーネント２０２は、要求をプレゼンス・サーバ１１８へ送ることを、要求をプレゼンス情報に含めることによって、行なう。これについては、図４〜６に関連して後に記載する。リソースの記述子は、要求自体に含めることもできるし、要求を含むプレゼンス情報を要求装置から応答装置へ伝えるために用いられるプレゼンス・プロトコル・コマンドに含めることもできる。要求を含むプレゼンス情報をプレゼンス・サーバ１１８へ送ることは、プレゼンス・プロトコルを介して、一斉送信または宛て先の公開コマンドの何れかを用いて、行なうことができる。
【００４７】
再び図２の配置を要求装置１０２ｃの観点から考えると、要求ウォッチャ・コンポーネント２０４はさらに、要求メッセージに返答する応答を、プレゼンス・サーバ１１８を介して受け取るように構成される。プレゼンス・サーバ１１８は、応答を要求ウォッチャ・コンポーネント２０４へ、通知コマンドを用いてプレゼンス・プロトコルを介して、送る。応答を含む通知コマンドを、応答装置１０２ｂのプレゼンス情報へのサブスクリプションに基づいて、要求ウォッチャ・コンポーネント２０４へ送ってもよい。これは、要求装置１０２ｃへ送出するために応答装置１０２ｂが送る宛て先の公開／通知コマンドの結果として、または要求装置１０２ｃが起こすフェッチまたはポーリング要求に応答して、行なってもよい。
【００４８】
典型的な実施形態によれば、要求装置は、要求プレゼンティティ２０２およびウォッチャ２０４コンポーネントに結合される要求ユーザ・エージェント（ＲＱＵＡ）コンポーネントを含む。ＲＳＵＡと同様に、ＲＱＵＡも、図２に示す通信クライアント１１０ａ〜１１０ｆに結合して、要求装置１０２ｃのユーザ主体とやり取りする。ＲＱＵＡは、要求ウォッチャ・コンポーネント２０４が受け取る記述子を容易に提示できるように構成される。たとえば、ＩＭクライアント１１０ｂを用いて、ＲＱＵＡは、要求ウォッチャ・コンポーネント２０４が受け取るリソースの記述子を示す。リソースはたとえば、ジョンが所有すると示されている写真を共有するウェブ・サービス、またはサーバ１が所有すると示されているプログラムおよびサービス（図２）である。記述子は、インターフェース３０２において、リソースのオーナおよびリソースのステータスを記述する情報とともに示される。
【００４９】
またＲＱＵＡは、要求プレゼンティティ・コンポーネント２０２が要求を容易に送れるように構成される。要求は、リソースに関連して行なわれる何らかの他の動作に応答して、ＲＱＵＡが自動的に生成する。動作はたとえば、要求装置１０２ｃ上で実行される関連するプログラムによる動作である。あるいは、インターフェース（たとえば図３に示すインターフェース３０２）を、要求装置１０２ｃのユーザ／主体に示して、要求の形成に必要な情報を集める。たとえば、「要求を公開する」動作エントリ３０６ａを選択した場合、対応するダイアログ・ボックス（図示せず）をユーザ主体に示して、要求を形成するために必要な情報を収集する。次にＲＱＵＡは、要求を要求プレゼンティティ・コンポーネント２０２へ転送して公開し（おそらくは適切なＰＵＡの支援を伴って）、必要に応じて要求の任意の変換を行なう。
【００５０】
またＲＱＵＡは、要求ウォッチャ・コンポーネント２０４が受け取る応答を容易に提示する構成される。たとえば、応答が、図２に例示する応答装置１０２ｂの写真共有ウェブ・サービス１０４ａからサービスされるウェブ・ページを含む場合、ＲＱＵＡは、図に示す要求装置１０２ｃのブラウザ・クライアント１１０ｆを呼び出して、サービスされるウェブ・ページを表示することができる。こうしてＲＱＵＡは、自身を、プレゼンス・サーバ１１８へ送る要求とプレゼンス・サーバ１１８から受け取る応答とを処理するためのプロキシとして、効果的に設定される。あるいはＲＱＵＡは、応答に作用する前にユーザ主体から許可または付加情報を受け取るためのダイアログ・ボックスを示す。
【００５１】
要求プレゼンティティ２０２およびウォッチャ２０４コンポーネントと通信クライアント１１０との間での情報の交換を容易にする際に、ＲＱＵＡは、適切なＰＵＡおよび／またはＷＵＡとともに動作してもよいし、これらのエージェントの動作をバイパスしてもよい。ＰＵＡおよびＷＵＡの場合と同様に、ＲＱＵＡは、その機能が、プレゼンス・サービスの内部に、プレゼンス・サービスの外部に、またはプレゼンス・サービスの内部および外部の組み合わせまたは両方に存在するように、実施することができる。
【００５２】
再び図１を参照して、プレゼンス・サーバ１１８にはプロキシ・サービス１２４を含めることができる。プロキシ・サービス１２４は、要求を応答ウォッチャ・コンポーネント２０４へ、応答装置１０２ｂに付随するファイアウォール１１４を通して送るように構成することもできるし、応答を要求ウォッチャ・コンポーネントへ、要求装置１０２ｃに付随するファイアウォール（図示せず）を通して送るように構成することもできる。別の典型的な実施形態によれば、プレゼンス・サーバ１１８は、アカウント・サービス１２２を含む。アカウント・サービス１２２は、要求および応答の各装置の素性を認証するように、また装置が要求または応答の受け取りを、要求または応答を対応するエンティティへ送る前に行なうことを許可するように、構成される。
【００５３】
ロスタおよび／またはプライバシ・リストをアカウント・サービス１２２が用いることで、特定のリソースへのアクセスを許可および認証してもよいしまたはプロバイダが特定のリソースをサブスクライバに宣伝することがないようにしてもよい。この意味において、ロスタおよび／またはプライバシ・リストは、プレゼンス・エンティティ間でのリソース使用法を認証および許可するためのアクセス制御リスト（ＡＣＬ）として動作する。ロスタおよび／またはプライバシ・リスト・データは、データベース（たとえばアカウント・サービス１２２に結合されるアカウントおよび許可情報データベース１２８）に記憶される。複数のロスタおよび／またはプライバシ・リストを、データベース１２８に保持してもよく、またサービス１２２が用いてもよい。ロスタ・マネージメント用のアカウント・サービス・プロトコルに対する新しい拡張機能が、ロスタまたはリストを保持するために必要とはならないが、その代わりに、ロスタ・データを、プレゼンス情報に含めて、プレゼンス・プロトコルによって伝えられる。
【００５４】
次に、図４を参照して、一般的な要求／応答プロトコルを提供する際にプレゼンス・プロトコルとともに用いられるデータ構造が例示される。便宜上、図４に示すデータ構造には、応答エンティティおよび要求エンティティの両方のプレゼンス情報を記憶するためのデータ・オブジェクトおよび要素が含まれる。しかしながら、当業者であれば理解するように、応答装置に付随するプレゼンス情報を記憶するためのデータ構造には、要求装置のプレゼンス情報を記憶するために必要な物体および要素が含まれている必要はなく、逆もまた同様である。
【００５５】
もし図４のデータ構造に、応答および要求エンティティの両方のプレゼンス情報を記憶するためのデータ・オブジェクトおよび要素が含まれているならば、１）応答および要求エンティティは、同じ主体に付随するとともに、異なるリソースに応答しおよびそれらに関係する要求を起こすか、または２）応答および要求エンティティは、異なる主体に付随するとともに、共通のリソースに応答しおよびそれらに関係する要求を起こす、いずれかの配置のうちの１つが存在する。この第２の配置では、標準的なプレゼンス・サービス・アクセス制御ポリシに対する変更が必要であり、より複雑なアクセス制御システムとなる。しかしながら、要求／応答取引の全体を、リソースまたはリソースのオーナに付随する単一のプレゼンス・タプルに記憶される情報を用いて行なえば、データ記憶の使用状況およびデータ交換における効率を高める。
【００５６】
図４に示すデータ構造は、好適であればどんなコンピュータ読取可能な媒体に含まれていてもよい。たとえば、命令実行システム、設備、または装置によって使用されるかまたはそれらとともに使用されるプログラムを収容し、記憶し、伝達し、伝搬し、または輸送することができる任意の手段である。コンピュータ読取可能な媒体は、たとえば（これらに限定されないが）、電子的な、磁気的な、光学的な、電磁気の、赤外線の、または半導体のシステム、設備、装置、または伝搬媒体、たとえばリムーバブルの記憶装置である。コンピュータ読取可能な媒体のより具体的な例（非網羅的なリスト）には、以下のものが含まれる。すなわち、１つまたは複数のワイヤを有する電気的接続、携帯型コンピュータ・ディスケット、ランダム・アクセス・メモリ（ＲＡＭ）、読み出し専用メモリ（ＲＯＭ）、消去可能なプログラマブル読み出し専用メモリ（ＥＰＲＯＭまたはフラッシュ・メモリ）、光ファイバ、および携帯型コンパクト・ディスク読み出し専用メモリ（ＣＤＲＯＭ）である。
【００５７】
図４に示すデータ構造は、拡張されたプレゼンス・タプル４０２を含むプレゼンス情報４００を表わしている。プレゼンス情報４００は、図１に示すプレゼンス・サーバ１１８に結合されたデータベース（たとえばプレゼンス情報データベース１２６）に記憶される。図１では単一のデータベース１２６を示しているが、当業者であれば理解するように、プレゼンス情報は、ネットワーク１１６全体を通して複数のデータベースにまたがって分布してもよいし、および／または、少なくとも部分的に、図１に示す要求および／または応答装置１０２に付随するメモリに記憶されてもよい。
【００５８】
図４に示すプレゼンス・タプル４０２には、ＲＦＣ２７７８およびＲＦＣ２７７９において記述されるステータス４０２および通信アドレス４０４情報を記憶するための標準的なデータ・オブジェクトが含まれる。またプレゼンス・タプル４０２には、コンタクト手段４０８およびコンタクト・アドレス４１０を記憶するためのデータ・オブジェクトだけでなく、他のマークアップ４１８を記憶するためのデータ・オブジェクトも含まれる。その結果、プレゼンス標準に基づくタプル４０２の拡張性が維持される。プレゼンス・タプル４０２は、ＲＦＣ２７７８およびＲＦＣ２７７９において記述されるプレゼンス情報に対する標準的な形式を保っているため、プレゼンス情報４００は、標準的なプレゼンス・プロトコル・コマンドを用いてネットワーク１１６全体に伝えられる。プレゼンス・サーバ１１８は、サーバ１１８に含まれる情報をネットワーク１１６に結合される種々のプレゼンス・エンティティに送るために、タプル４０２の内容を把握している必要はない。
【００５９】
最初に図４のデータ構造を、プレゼンス・プロトコルを用いて一般的な要求／応答プロトコルを提供する上で、応答エンティティの点から考える。プレゼンス・タプル４０２には、リソース・データ・オブジェクト４１２が含まれる。オブジェクト４１２には、応答エンティティに付随するリソースの記述子を記憶するための要素（明示せず）が含まれる。図１〜３に関連して前に記載したように、記述子には、応答エンティティが利用できるリソース（たとえば図１に示すリソース１０４、１０８、１１２の何れか）を記述および／または特定する任意の情報を含めることができる。応答エンティティは、たとえば、図２に示す応答プレゼンティティ・コンポーネント２０２とすることができる。典型的な実施形態によれば、リソース・データ・オブジェクト４１２にはまた、リソースによってサポートされる要求を記述する情報を記憶するための少なくとも１つの要素（明示せず）を含めることができる。この情報はたとえば、リソースがサポートすることができる機能および要求のタイプを記述する情報、および要求を書式設定する方法を記述する情報である。またリソース・データ・オブジェクト４１２には、リソースによってサポートされる要求に返答するために利用できる応答を記述する情報を記憶するための少なくとも１つの要素（明示せず）を含めることもできる。
【００６０】
次に図４のデータ構造を要求エンティティの点から考える。プレゼンス・タプル４０２には、要求データ・オブジェクト４１６も含まれている。要求データ・オブジェクトには、リソースに関係する要求エンティティからの要求を記憶するための要素が含まれる。要求エンティティは、たとえば、図２に示す要求プレゼンティティ・コンポーネント２０２とすることができる。
【００６１】
図５Ａに、典型的な実施形態による要求データ・オブジェクト４１６の拡大図を示す。図示するように、要求データ・オブジェクト４１６の拡大図には、リソースに関係する要求メッセージ５０４を記憶するための要素を含めることができる。また要求データ・オブジェクト４１６には、応答エンティティに付随するリソースの記述子を記憶するための記述子要素５０２を含めることもできる。記述子要素５０２は、リソースのみを記述または特定する情報を含めることもできるし、は、応答エンティティおよびその付随するリソースの両方を記述または特定する情報（たとえば統一リソース識別子（ＵＲＩ））を含めることもできる。
【００６２】
たとえば、要求エンティティ（「ｃｕｓｔｏｍｅｒ＠ｉｓｐ．ｎｅｔ」）によって公開される以下のＸＭＬベースのメッセージを考える。このメッセージは、本を注文するサービス（またはリソース）を含むオンライン・ストア「ｏｎｌｉｎｅ．ｃｏｍ」へ通知するためのものである。
＜ｐｒｅｓｅｎｃｅ
ｆｒｏｍ＝’ｃｕｓｔｏｍｅｒ＠ｉｓｐ．ｎｅｔ’
ｔｏ＝’ｓａｌｅｓ＠ｏｎｌｉｎｅ．ｃｏｍ’
ｘｍｌ：ｌａｎｇ＝’ｅｎ’＞
＜ｒｅｑｕｅｓｔ＞
＜ｄｅｓｃｒｉｐｔｏｒ＞ｂｏｏｋｓ＜／ｄｅｓｃｒｉｐｔｏｒ＞
＜／ｒｅｑｕｅｓｔ＞
＜／ｐｒｅｓｅｎｃｅ＞
要素５０２に記憶される記述子は、リソースを特定するために単純に「ｂｏｏｋｓ」（表示した通り）とすることもできるし、または記述子は、応答エンティティの特定（たとえばノードおよびドメイン名前により）およびリソースの特定の両方を行なうために、完全なＵＲＩ１たとえば、「ｓａｌｅｓ＠ｏｎｌｉｎｅ．ｃｏｍ／ｂｏｏｋｓ」とすることもできる。次のことを理解されたい。すなわち、応答エンティティはリソース自体に対応することができるため、記述子は、応答エンティティリソースを、より単純なＵＲＩ、たとえばＵＲＩ「ｂｏｏｋｓ＠ｏｎｌｉｎｅ．ｃｏｍ」を用いて記述または特定することができる。プレゼンス・サーバ１１８は、要素５０２に記憶された記述子を用いて、要素５０４に記憶された要求メッセージを要求エンティティ／リソースへ送ること（たとえば、ＵＲＩ記述子のノードおよびドメイン部分を用いて）、および要求を処理するためにリソースを記述または特定すること（たとえば、ＵＲＩ記述子の識別子部分を用いて）の両方を行なうことができる。
【００６３】
要求の中に記述子を含むことは、次のような状況の下では有用であり得る。すなわち、要求エンティティの特定用情報が、要求にサブスクライブしても良いすべてのウォッチング・エンティティへ送られている状況、または要求を含むプレゼンス情報が、ネットワーク１１６に結合されるすべてのウォッチング・エンティティへ一斉送信されている状況（すなわち、宛て先の公開／通知コマンドが使用されていない状況）である。たとえば、要求エンティティ（「ｃｕｓｔｏｍｅｒ＠ｉｓｐ．ｎｅｔ」）によって公開される以下のＸＭＬベースのメッセージを考える。このメッセージは、利用できる任意の応答エンティティ／リソースへ一斉送信するためのものである。
＜ｐｒｅｓｅｎｃｅ
ｆｒｏｍ＝’ｃｕｓｔｏｍｅｒ＠ｉｓｐ．ｎｅｔ’
ｘｍｌ：ｌａｎｇ＝’ｅｎ’＞
＜ｒｅｑｕｅｓｔ＞
＜ｄｅｓｃｒｉｐｔｏｒ＞ｓａｌｅｓ＠ｏｎｌｉｎｅ．ｃｏｍ／ｂｏｏｋｓ＜／ｄｅｓｃｒｉｐｔｏｒ＞
＜／ｒｅｑｕｅｓｔ＞
＜／ｐｒｅｓｅｎｃｅ＞
すべてのエンティティへ一斉送信することは、応答エンティティが、要求を含む要求エンティティの少なくともプレゼンス情報へサブスクライブしていないときには、有用である。
【００６４】
図５Ｂに、代替的な実施形態による要求データ・オブジェクト４１６の拡大図を示す。この実施形態では、要求データ・オブジェクト４１６には、応答エンティティに付随するリソースの記述子を記憶するための要素（たとえば、図５Ａに示す要素５０２）が含まれない。その代わりに、リソースの記述子は、要求を要求装置から応答装置へ伝えるために使用されるプレゼンス・プロトコル・コマンドに含める。たとえば、要求エンティティ（「ｃｕｓｔｏｍｅｒ＠ｉｓｐ．ｎｅｔ」）によって公開される以下のＸＭＬベースのメッセージを考える。このメッセージは、前述したオンライン・ストアへ通知するためのものである。
＜ｐｒｅｓｅｎｃｅ
ｆｒｏｍ＝’ｃｕｓｔｏｍｅｒ＠ｉｓｐ．ｎｅｔ’
ｔｏ＝’ｓａｌｅｓ＠ｏｎｌｉｎｅ．ｃｏｍ／ｂｏｏｋｓ’
ｘｍｌ：ｌａｎｇ＝’ｅｎ’＞
＜ｒｅｑｕｅｓｔ＞．．．＜／ｒｅｑｕｅｓｔ＞
＜／ｐｒｅｓｅｎｃｅ＞
オンライン・ストアが提供する「ｂｏｏｋｓ」サービスに対する記述子を、要求メッセージ自体（たとえば、メッセージの＜ｒｅｑｕｅｓｔ＞要素と＜／ｒｅｑｕｅｓｔ＞要素との間）に含むのではなくて、記述子を、プレゼンス属性「ｓａｌｅｓ＠ｏｎｌｉｎｅ．ｃｏｍ／ｂｏｏｋｓ」に含める。プレゼンス属性は、プレゼンス・サーバ１１８によって、宛て先の公開／通知コマンドの通知部分を応答エンティティへ送るために使用されるものである。
【００６５】
また要求エンティティが、特定のリソース記述子を含まない規格化された要求を一斉送信することも、要求エンティティが、要求を処理および応答する応答エンティティリソースに関して好みがない場合には、有用である。その結果、要求を、利用できる任意の応答エンティティ／リソースが処理することができる。たとえば、要求エンティティ（「ｃｕｓｔｏｍｅｒ＠ｉｓｐ．ｎｅｔ」）によって公開される以下のＸＭＬベースのメッセージを考える。このメッセージは、利用できる任意の応答エンティティ／リソースへ一斉送信するためのものである。
＜ｐｒｅｓｅｎｃｅ
ｆｒｏｍ＝’ｃｕｓｔｏｍｅｒ＠ｉｓｐ．ｎｅｔ’
ｘｍｌ：ｌａｎｇ＝’ｅｎ’＞
＜ｒｅｑｕｅｓｔ＞．．．＜／ｒｅｑｕｅｓｔ＞
＜／ｐｒｅｓｅｎｃｅ＞
要求を含む一斉送信メッセージには、要求を処理するためのリソースの記述子が（メッセージのプレゼンス属性にも要求自体にも）含まれていないため、任意のウォッチング・エンティティ／リソースは、適切な場合には、要求を評価すること、ならびに要求を処理および応答することができる。
【００６６】
関連する実施形態においては、要求データ・オブジェクトはまた、応答エンティティの識別子を記憶するための要素を含むこともできる。たとえば、図５Ｂに示す典型的な要求データ・オブジェクト４１６の拡大図応答エンティティの識別子を記憶するための識別子要素５０６が含まれる。識別子は、応答エンティティ、たとえば「ｓａｌｅｓ＠ｏｎｌｉｎｅ．ｃｏｍ」のノードおよびドメインを含むＵＲＩとすることができる。このような識別子を要求エンティティが使用できるのは、要求をすべてのウォッチング・エンティティに一斉送信するが（たとえば通知目的で）、要求を、識別子に対応する応答エンティティのみによって処理すべき場合である。
【００６７】
たとえば、要求エンティティ（「ｃｕｓｔｏｍｅｒ＠ｉｓｐ．ｎｅｔ」）によって公開される以下のＸＭＬベースのメッセージを考える。このメッセージは、利用できる任意の応答エンティティ／リソースへ一斉送信するためのものであるが、要求の処理に利用できるリソースを有する応答エンティティを特定するために要求中に識別子を含むためのものである。
＜ｐｒｅｓｅｎｃｅ
ｆｒｏｍ＝’ｃｕｓｔｏｍｅｒ＠ｉｓｐ．ｎｅｔ’
ｘｍｌ：ｌａｎｇ＝’ｅｎ’＞
＜ｒｅｑｕｅｓｔ＞
＜ｉｄｅｎｔｉｆｉｅｒ＞ｓａｌｅｓ＠ｏｎｌｉｎｅ．ｃｏｍ＜／ｉｄｅｎｔｉｆｉｅｒ＞
＜／ｒｅｑｕｅｓｔ＞
＜／ｐｒｅｓｅｎｃｅ＞
この意味において、要素５０６に記憶される識別子は、図５Ａに示す配置の要素５０２に記憶される記述子と同様の機能をサービスする。しかし識別子には、要求を処理するために用いられるリソースの記述子が含まれている必要はない。したがって、識別子に対応する応答エンティティが多くのリソースにアクセスできる場合、これらのリソースの何れか１つを、要求を処理するために用いられる。
【００６８】
別の典型的な実施形態においては、要素５０４に記憶される要求メッセージは、ＳＯＡＰメッセージの構造で形成されるＸＭＬベースのメッセージとすることができる。ＳＯＡＰは、ＸＭＬベースのメッセージを、コンピュータ・ネットワーク上で（通常、ｈｔｔｐを用いて）交換するための規格である。ＳＯＡＰは、ウェブ・サービスを提供するためのプロトコル・スタックの基層を形成する。規格では、スタック内のより抽象的な層が構築可能な基本的なメッセージング・フレームワークが提供される。
【００６９】
複数の異なるタイプのメッセージング・パターンが、ＳＯＡＰにおいて利用できるが、もっとも一般的なものは、遠隔手続き呼び出し（ＲＰＣ）パターンである。このパターンでは、あるネットワーク・ノード（クライアント）が、要求メッセージを別のノード（サーバ）へ送り、サーバは即座に、応答メッセージをクライアントへ送る。ＳＯＡＰは本来、シンプル・オブジェクト・アクセス・プロトコルに対する頭文字であったが、頭文字は、ＳＯＡＰ仕様書のバージョン１．２では削除されている。このバージョンの規格に対する手引き書が、ワールド・ワイド・ウェブ・コンソーシアム（ＷｏｒｌｄＷｉｄｅＷｅｂＣｏｎｓｏｒｔｉｕｍ）（Ｗ３Ｃ）ＸＭＬプロトコル・ワーキング・グループから刊行されており、これは、以下においてダウンロードまたは閲覧することができる。ｈｔｔｐ：／ｗｗｗ．ｗ３．ｏｒｇ／ＴＲ／２００３／ＲＥＣ−ｓｏａｐ１２−ｐａｒｔ０−２００３０６２４／（本出願の出願時）。
【００７０】
再度、図４のデータ構造を、応答エンティティの点から参照すると、プレゼンス・タプル４０２にはまた、応答データ・オブジェクト４１４が含まれる。オブジェクト４１４には、応答エンティティからの、要求に返答する応答メッセージを記憶するための要素が含まれる。応答エンティティは、たとえば、図２に示す応答プレゼンティティ・コンポーネント２０２とすることができる。次のことに注意されたい。すなわち図４では、２つの応答データ・オブジェクト４１４が、プレゼンス・タプル４０２においてリソース・データ・オブジェクト４１２にリンクされる場合を示している。このような配置では、共通のリソースに関係する複数の要求（たとえば、複数のプレゼンス・エンティティからの）に応答するために必要な情報を、効率的に記憶および管理することができる。しかしながら、図４に示す配置は典型に過ぎず、リソース、要求、および応答情報を記憶および管理するための他の配置も、本明細書で説明する技術の範囲内である。
【００７１】
図６に、典型的な実施形態による応答データ・オブジェクト４１４の拡大図を示す。図示するように、応答データ・オブジェクト４１４の拡大図には、要素５０４に記憶される要求メッセージに返答する応答メッセージ６０４を記憶するための要素を含むことができる。要求メッセージと同様に、要素６０４に記憶される応答メッセージは、ＳＯＡＰメッセージの構造で形成されるＸＭＬベースのメッセージである。
【００７２】
また応答データ・オブジェクト４１４には、要求エンティティの識別子（たとえばＵＲＩ）を記憶するための識別子要素６０２（図５Ｂに示す識別子要素５０６と同様）を含めることもできる。プレゼンス・サーバ１１８は、要素６０２に記憶される識別子を用いて、プレゼンス・タプル４０２の要素６０４に記憶される応答メッセージを要求エンティティへ送られる。プレゼンス・サーバ１１８がこの識別子を用いることは、次のような状況の下では有用である。すなわち、応答エンティティのプレゼンス情報が、ネットワーク１１６に結合されるすべてのプレゼンス・エンティティへ一斉送信されている状況（すなわち、宛て先の公開／通知コマンドが使用されていない状況）、および要求エンティティが、応答メッセージを含む応答エンティティの少なくともプレゼンス情報にサブスクライブしていない状況の両方の場合、または、他のサブスクライブされるウォッチャに応答を通知する必要がある状況である。
【００７３】
たとえば、応答エンティティ（「ｓａｌｅｓ＠ｏｎｌｉｎｅ．ｃｏｍ」）によって公開される以下のＸＭＬベースのメッセージを考える。このメッセージは、利用できる任意の要求エンティティへ一斉送信するためのものである。
＜ｐｒｅｓｅｎｃｅ
ｆｒｏｍ＝’ｓａｌｅｓ＠ｏｎｌｉｎｅ．ｃｏｍ’
ｘｍｌ：ｌａｎｇ＝’ｅｎ’＞
＜ｒｅｓｐｏｎｓｅ＞
＜ｉｄｅｎｔｉｆｉｅｒ＞ｃｕｓｔｏｍｅｒ＠ｉｓｐ．ｎｅｔ＜／ｉｄｅｎｔｉｆｉｅｒ＞
＜／ｒｅｓｐｏｎｓｅ＞
＜／ｐｒｅｓｅｎｃｅ＞
メッセージはすべてのウォッチング・エンティティに一斉送信されているにもかかわらず、識別子を要求エンティティ（「ｃｕｓｔｏｍｅｒ＠ｉｓｐ．ｎｅｔ」）が用いて、応答がその自身の要求に答えていることを決定することができる。他のサブスクライブされるウォッチャに応答を通知する必要がない場合、要求エンティティへの応答の宛て先の公開／通知を用いることができるため、要求エンティティの識別子を応答データ・オブジェクト４１４に記憶する必要がなくなる。
【００７４】
ほとんどのプレゼンス・プロトコルは、ＸＭＬベース（たとえば、テキスト・ベース）のプロトコルである。もし要求または応答メッセージにバイナリ・データを含む必要がある場合には、バイナリ・データは、アタッチメントを用いることでサポートすることができる。たとえば、文献「アタッチメントを用いるＳＯＡＰ（ＳＯＡＰｗｉｔｈａｔｔａｃｈｍｅｎｔｓ）」がＷ３Ｃから刊行されており、以下においてダウンロードまたは閲覧することができる。ｈｔｔｐ：／ｗｗｗ．ｗ３．ｏｒｇ／ＴＲ／２００４／ＮＯＴＥ−ｓｏａｐ１２−ａｆ−２００４０６０８／（本出願時）。この文献では、バイナリ・アタッチメントに対するＳＯＡＰサポートが説明されている。あるいはバイナリ・データを、要求／応答メッセージにおいて参照により引き渡しても良い。すなわち、ＵＲＩをＸＭＬベースの要求／応答メッセージにおいて引き渡すことを、どのプレゼンス・エンティティおよび／またはエージェントがバイナリ・データを回収しても良いかを用いて、行なっても良い。好ましくは、バイナリ・データが、テキスト形式でエンコードされるプレゼンス・タプルを通りおよび／またはそこに記憶される。そうすることで、プレゼンス・サーバ１１８が、セキュリティ、トラッキング、およびマネージメント・サービスをこのタイプのデータに適用することが、他の任意のタプル・データの場合と同様に処理することによって、可能となる。
【００７５】
典型的な実施形態においては、リソース４１２および応答４１４データ・オブジェクトは、リソースまたはリソースのオーナに付随するプレゼンス・タプルに含まれる。リソース４１２および応答４１４データ・オブジェクトが、リソースに付随するプレゼンス・タプルに含まれる場合には、リソースに付随するプレゼンス・タプルは、リソースに付随するプレゼンス・タプルを、リソースのオーナに付随するプレゼンス・タプルにリンクさせるデータ・オブジェクトを、含む。
【００７６】
たとえば、図７は、ＩＭリソース（たとえば図２に示すＩＭクライアント１１０ｂ）に付随するプレゼンス情報を記憶するためのデータ構造を示す。プレゼンス情報４００には、ＩＭクライアント１１０ｂに対応するＩＭプレゼンス・タプル７０２、およびネットワーク１１６に結合される他のＩＭクライアント（図示せず）に対応する他のＩＭプレゼンス・タプル７０２が含まれる。ＩＭプレゼンス・タプル７０２には、以下のものが含まれている。すなわち、サービス・ステータス７０４、通信アドレス７０６（コンタクト手段７０８およびコンタクト・アドレス７１０を記憶するための要素を含む）を記憶するための標準的なデータ・オブジェクト、および他のマークアップ情報４１８を記憶するためのデータ・オブジェクトである。ステータス７０４および通信アドレス７０６データ・オブジェクトに記憶される情報は、ＩＭクライアント１１０ｂに付随するオーナもしくは主体のステータスおよび通信アドレスならびに／またはＩＭクライアント１１０ｂのステータスおよび通信アドレスを表わすことができる。
【００７７】
ＩＭプレゼンス・タプル７０２は、リソース（たとえばＩＭクライアント１１０ｂ）には付随し、リソースのオーナには付随していないため、ＩＭプレゼンス・タプル７０２は、オーナ／主体のプレゼンス・タプル（図示せず）における情報をＩＭプレゼンス・タプル７０２にリンクする情報を記憶するためのデータ・オブジェクト７１２を含むこともできる。また、ＩＭプレゼント・タプル７０２自体はリソースに付随するため、リソース・データ・オブジェクト（たとえば図４に示すリソース・データ・オブジェクト４１２）は、必須ではない。その代わりに、ＩＭサービスの記述子は、サービスについての任意の他の情報（たとえばサービスがサポートする機能および要求のタイプならびにサービスに対する要求のフォーマットの方法）とともに、ＩＭプレゼンス・タプル７０２の他のデータ・オブジェクトおよび／または要素（明示せず）に記憶することができる。
【００７８】
またＩＭプレゼンス・タプル７０２には、要求データ・オブジェクト７１４も含めることができる。オブジェクト７１４には、識別子７１６およびメッセージ７１８要素が含まれるだけでなく、サブジェクト７２０およびボディ７２２のサブ要素も含まれる。これは、ネットワーク１１６に結合された他のプレゼンス・エンティティに送るＩＭメッセージ情報を記憶するためである。ＩＭクライアント１１０ｅに付随するプレゼンティティは、宛て先の公開／通知コマンドを用いてメッセージを特定のエンティティへ送ることもできるし、メッセージを、ＩＭプレゼンス・タプル７０２情報へのすべてのサブスクライバへ、一斉送信することもできる。ＩＭプレゼンス・タプル７０２は、ＲＦＣ２７７８およびＲＦＣ２７７９で記述されるプレゼンス情報に対する標準的な形式を保つため、プレゼンス情報４００は、標準的なプレゼンス・プロトコル・コマンドを用いてネットワーク１１６に渡って伝えることができる。プレゼンス・サーバ１１８は、サーバ１１８に含まれる情報をネットワーク１１６に結合される種々のプレゼンス・エンティティに送るために、タプル４０２の内容を把握している必要はない。また図７に示す配置によって、従来のプレゼンス情報およびＩＭメッセージング情報の両方とも、プレゼンス・プロトコルだけで伝えることができるため、別個のメッセージング・プロトコルを用いてＩＭメッセージ内容を送る必要はない。
【００７９】
関係する典型的な実施形態においては、要求データ・オブジェクト４１６は、リソースに付随するプレゼンス・タプルに含めることもできるし、要求エンティティに付随する主体に含めることもできる。要求データ・オブジェクト４１６が、リソースに付随するプレゼンス・タプルに含まれる場合には、リソースに付随するプレゼンス・タプルは、リソースに付随するプレゼンス・タプルを、要求エンティティに付随する主体に付随するプレゼンス・タプルにリンクさせるデータ・オブジェクトを含む。
【００８０】
図８は、プレゼンス・プロトコルを用いて一般的な要求／応答プロトコルを提供するための方法を例示するフローチャートである。本方法は、図１〜３に関連して説明した配置および図４〜６に関連してすでに説明したデータ構造を用いて行なうことができる。その一部は以下の説明において参照される。特に、本方法は、プレゼンス・サーバ１１８を用いて行なわれる。当然のことながら、他の配置および／またはデータ構造を用いても、説明した方法を、説明した技術の範囲から逸脱することなく行なうことができる。特定の用語については、その意味はすでに図１〜６に関連して詳細に説明しており、その説明はここでは繰り返さない。
【００８１】
また、プレゼンス・プロトコルを用いて一般的な要求／応答プロトコルを提供するための図８に例示したようなコンピュータ・プログラムの実行可能命令は、命令実行システム、設備、または装置によって使用またはそれらとともに使用される任意のコンピュータ読取可能な媒体において、具体化される。命令実行システム、設備、または装置は、たとえば、コンピュータ・ベースのシステム、プロセッサ内蔵システム、または命令を、命令実行システム、設備、または装置からフェッチして、命令を実行することができる他のシステムである。
【００８２】
本方法はブロック８０２で始まる。ここでは、プレゼンス・プロトコルを用いて、要求エンティティから、応答エンティティに付随するリソースの記述子とリソースに関係する要求とを受け取る。たとえば、プレゼンス・サーバ１１８は、記述子および要求を、図２に示す要求プレゼンティティ・コンポーネント２０２から受け取る。ブロック８０４では、記述子および要求を、たとえば、プレゼンス・サーバ１１８から応答エンティティ（たとえば応答ウォッチャ・コンポーネント２０４）へ送る。記述子は、前に記載したように、図５Ａに示す要求データ・オブジェクト４１６とともに、要求に含まれる。あるいは、記述子を、要求を要求エンティティから受け取る際におよび要求を応答エンティティへ送る際に用いられる、対応するプレゼンス・プロトコル・コマンド（たとえば公開および通知コマンド）のそれぞれに含めることができる。
【００８３】
ブロック８０６において、応答エンティティ（たとえば図２の応答プレゼンティティ・コンポーネント２０２）からの応答が、たとえばプレゼンス・サーバ１１８によって受け取られる。応答には、要求メッセージに返答する応答メッセージ（たとえば図６に示すデータ構造の要素６０４に記憶される）、および要求エンティティの識別子（たとえばデータ構造の要素６０２に記憶される）が含まれる。ブロック８０８では、応答が、たとえばプレゼンス・サーバ１１８によって、要求エンティティ（たとえば、図２に示す要求ウォッチャ・コンポーネント２０４）に送られる。したがって一般的な要求／応答プロトコルは、プレゼンス・プロトコルのコマンドを用いて形成される。
【００８４】
典型的な実施形態によれば、プレゼンス・プロトコルは、たとえばプレゼンス・サーバ１１８によって、応答エンティティ（たとえば、図２に示す応答プレゼンティティ・コンポーネント２０２）から、リソースの記述子を受け取るために、用いられる。リソースの記述子を要求エンティティに送ることは、要求エンティティに対して設定された、応答エンティティの少なくとも一部のプレゼンス情報（たとえば、リソース・データ・オブジェクト４１２に記憶されるプレゼンス情報）へのサブスクリプションに基づいて、行なわれる。プレゼンス・プロトコルは、応答エンティティのプレゼンス情報へのサブスクリプションが要求エンティティ１０２に対して設定されるときに、応答エンティティに対して、要求エンティティの少なくとも一部のプレゼンス情報（たとえば、要求データ・オブジェクト４１６に記憶されるプレゼンス情報）へのサブスクリプションを自動的に設定するために、用いられる。応答エンティティに送られる要求は、応答エンティティに対して自動的に設定されるサブスクリプションに基づく。自動サブスクリプションによって、応答エンティティに、リソースに付随する情報にサブスクライブした要求エンティティからの要求を通知することができる効率的なメカニズムが得られる。
【００８５】
サブスクリプションを自動的に設定することが望ましくない場合には、プレゼンス・プロトコルは以下のような代替的な実施形態において用いられる。すなわち、応答エンティティに、通知として、応答エンティティの少なくとも一部のプレゼンス情報（たとえば、リソース・データ・オブジェクト４１２に記憶されるプレゼンス情報）へのサブスクリプションを、要求エンティティに対して設定するという通知を送る実施形態である。通知に応答して、サブスクリプション要求を応答エンティティから受け取って、要求エンティティの少なくとも一部のプレゼンス情報（たとえば、要求データ・オブジェクト４１６に記憶されるプレゼンス情報）へのサブスクリプションを要求することができる。そして、要求エンティティのプレゼンス情報へのサブスクリプションは、応答エンティティに対して、受け取ったサブスクリプション要求に基づいて設定される。したがって、応答エンティティに送られる要求は、応答エンティティに対して設定されるサブスクリプションに基づく。
【００８６】
別の実施形態では、プレゼンス・プロトコルは、要求エンティティによる、応答エンティティの少なくとも一部のプレゼンス情報に対するフェッチングまたはポーリング要求に応答して、リソースの記述子を要求エンティティへ送るために、用いられる。たとえば、新しいリソースがいつ利用可能となるかが通知されるべき応答エンティティのプレゼンス情報へサブスクライブするのではなくて、要求エンティティは、以下のことを要求する。すなわち、プレゼンス・サーバ１１８が応答エンティティのプレゼンス情報を周期的に精査することで、新しいリソースが公開されたかどうかを判定し、要求エンティティにこのような公開を通知することである。
【００８７】
応答エンティティに送られる要求は、応答エンティティに対して設定される、要求エンティティの少なくとも一部のプレゼンス情報（たとえば、要求データ・オブジェクト４１６に含まれるプレゼンス情報）へのサブスクリプションに基づく。あるいは、要求を応答エンティティへ送ることを、要求エンティティのプレゼンス情報に含まれる応答エンティティの識別子を用いて行なわれる。こうして、応答エンティティに、サブスクリプション要求に基づいて要求を通知するのではなくて、プレゼンス・サーバ１１８は、応答エンティティに、要求エンティティから送られる情報要求の宛て先の公開／通知に基づいて要求を通知する。また要求を応答エンティティに送ることを、要求エンティティの少なくとも一部のプレゼンス情報に対する応答エンティティによるフェッチングまたはポーリング要求に応答して、行なう。したがってプレゼンス・サーバ１１８は、要求エンティティのプレゼンス情報を周期的に精査して、応答エンティティから受け取るポーリングまたはフェッチ要求に従って要求情報を調べる。そしてプレゼンス・サーバ１１８は、精査コマンドによって検出されたときに、応答エンティティに要求を通知する。
【００８８】
同様に、要求エンティティに送られる応答は、要求エンティティに対して設定される、応答エンティティの少なくとも一部のプレゼンス情報（たとえば、応答データ・オブジェクト４１４に含まれるプレゼンス情報）へのサブスクリプションに基づく。あるいは、応答を要求エンティティへ送ることを、応答エンティティのプレゼンス情報に含まれる要求エンティティの識別子を用いて行なわれる。こうして、要求エンティティに、サブスクリプション要求に基づいて応答を通知するのではなくて、プレゼンス・サーバ１１８は、要求エンティティに、応答エンティティから送られる応答情報の宛て先の公開／通知に基づいて応答を通知する。また応答を要求エンティティに送ることを、応答エンティティの少なくとも一部のプレゼンス情報に対する要求エンティティによるフェッチングまたはポーリング要求に応答して、行なう。したがって、プレゼンス・サーバ１１８は、応答エンティティのプレゼンス情報を周期的に精査して、要求エンティティから受け取るポーリングまたはフェッチ要求に従って応答情報を調べる。そしてプレゼンス・サーバ１１８は、精査コマンドによって検出されたときに、要求エンティティに応答を通知する。
【００８９】
典型的な実施形態によれば、要求は、要求エンティティに付随するプレゼンス情報に含めることができるが、応答エンティティに付随するプレゼンス情報には含まれない。同様に、応答は、応答エンティティに付随するプレゼンス情報に含めることができるが、要求エンティティに付随するプレゼンス情報には含まれない。その結果として、要求および応答の各エンティティは、プレゼンス情報を、それらの対応するプレゼンス・タプルに対してのみ公開する。このような配置の場合、プレゼンス・サービス１２０およびその下にあるプレゼンス・プロトコルを変更してプレゼンス・タプルに含まれる要求／応答情報が交換できるようにする必要はない。
【００９０】
関連する実施形態においては、応答エンティティに付随するプレゼンス情報は、リソースのプレゼンス情報またはリソースのオーナのプレゼンス情報に対応する。応答エンティティに付随するプレゼンス情報がリソースのプレゼンス情報に対応するときには、リソースのプレゼンス情報は、リソースのオーナのプレゼンス情報へのリンクを含む。別の関連する実施形態においては、要求エンティティに付随するプレゼンス情報は、要求エンティティに付随する第２のリソースのプレゼンス情報または第２のリソースのオーナのプレゼンス情報に、対応する。なお第２のリソースは、要求を形成するように構成される。読者は図７を参照されたい。図に示すのは、ＩＭリソースに付随するプレゼンス情報とその付随するテキストとを記憶するためのデータ構造であり、テキストは、リソースのプレゼンス情報とリソースのオーナ／主体のプレゼンス情報とのリンキングに関する詳細に対するものである。
【００９１】
典型的な実施形態によれば、要求および応答の各エンティティの素性を認証し、また要求または応答の各エンティティによる受け取りを、要求または応答を対応するエンティティへ送る前に許可する。たとえば、前述したように、プレゼンス・サーバ１１８は、アカウント・サービス１２２として、要求および応答の各装置の素性を認証するように、また要求または応答の各装置による受け取りを、要求または応答を対応するエンティティへ送る前に許可するように、構成されたアカウント・サービス１２２を、含める。加えて、ロスタおよび／またはプライバシ・リストをアカウント・サービス１２２が用いることで、特定のリソースへのアクセスを許可および認証しても良いしまたはプロバイダが特定のリソースをサブスクライバに宣伝することがないようにしてもよい。
【００９２】
別の典型的な実施形態においては、プロキシ・サービスは、応答エンティティに付随するファイアウォールを介して、要求を応答エンティティへ送るために、または要求エンティティに付随するファイアウォールを介して応答を要求エンティティへ送るために設けられる。たとえば、図１および２を参照すると、プレゼンス・サーバ１１８は、プロキシ・サービス１２４を含む。プロキシ・サービス１２４は、応答装置１０２ｂに付随するファイアウォール１１４を介して要求を応答ウォッチャ・コンポーネント２０４へ送るように、または要求装置１０２ｃに付随するファイアウォール（図示せず）を介して応答を要求ウォッチャ・コンポーネントへ送るように、構成されている。
【００９３】
別の実施形態によれば、プレゼンス・プロトコルは、応答エンティティから、第２の応答エンティティに付随する第２のリソースの第２の記述子と第２のリソースに関係する第２の要求とを受け取るために用いられる。第２の要求は、要求エンティティからの要求に返答する応答に関係づけられる。またプレゼンス・プロトコルは、第２の記述子および第２の要求を第２の応答エンティティへ送るために用いられる。その結果、当初の応答エンティティは、要求エンティティとして機能し、また当初の受け取った要求を処理するときに他の応答エンティティの要求を生成することができる。このような構成が、種々のプレゼンス・エンティティ間のワークフローをサポートするために用いられて、複雑なマルチ・エンティティ取引を効率的に行なう。
【００９４】
たとえば、図９に、マルチ・エンティティ・オンライン購入取引を行なうときに生じるプレゼンス・エンティティ間の情報の流れを例示する。図９の構成に含まれるものは、プレゼンス・サーバ９０２およびプレゼンス・エンティティ（顧客９０６およびオンライン・ストア９０４を表す）である。付加的なプレゼンス・エンティティ（発送プロバイダ９０８およびクレジット・プロバイダ９１０を表す）も示す。顧客エンティティ９０６は、取引の開始を、プレゼンス・サーバ９０２にプレゼンス情報９１２を公開することによって行なうことができる。プレゼンス情報９１２には、オンライン・ストア・エンティティ９０４からの本の購入を要求することが含まれている。プレゼンス情報９１２には、顧客エンティティ９０６の識別子（「ｃｕｓｔｏｍｅｒ＠ｉｓｐ．ｎｅｔ」）が、「ｆｒｏｍ」プレゼンス属性として含まれ、またオンライン・ストア・エンティティ９０４に付随するリソースの識別子／記述子（「ｓａｌｅｓ＠ｏｎｌｉｎｅ．ｃｏｍ／ｂｏｏｋｓ」）が、宛て先の公開／通知コマンドの「ｔｏ」プレゼンス属性として含まれる。あるいは、プレゼンス情報９１２をプレゼンス・サーバ９０２へ、顧客エンティティ９０６によって一斉に送信される。
【００９５】
プレゼンス情報９１２に含まれる要求には、以下のものを指定する情報を含めることができる。すなわち、本のタイトル（「ＭｙＢｏｏｋ」）、オーダーする量（「１」）、支払い情報（支払いタイプを含む。たとえばクレジット・カード（「カード」））、ならびに他の関連する支払い情報（カード番号（「９９９９９９９９９」）および有効期限（「０８０８」）を含む）である。また要求には以下のものを含めることもできる。すなわち、発送情報（発送タイプを含む。たとえば小包郵便（「Ｐａｒｃｅｌ」））、および他の関連する発送情報（発送アドレス（「１２３４  Ｓｔｒｅｅｔ  Ｃｉｔｙ，ＳＴ，０００００」）を含む。
【００９６】
公開されたらすぐに、要求を含むプレゼンス情報９１２を、プレゼンス・サーバ９０２によってオンライン・ストア・エンティティ９０４へ送る。要求を含むプレゼンス情報９１２は、オンライン・ストア・エンティティ９０４へ、宛て先の公開／通知コマンド（図示した通り）の通知部分を介して送ることもできるし、オンライン・ストア・エンティティ９０４による顧客エンティティ９０６のプレゼンス情報９１２へのサブスクリプションに応答して、通知コマンドを介して送ることもできる。そして要求を、オンライン・ストアの「ｂｏｏｋｓ」サービスによって処理される。顧客エンティティ９０６からの要求を処理する際に、オンライン・ストア・エンティティ９０４は、要求をプレゼンス・サーバ９０２へ一斉送信して、他の応答エンティティ（たとえば発送９０８およびクレジット９１０プロバイダ・エンティティ）へ通知するようにしてもよい。これらのエンティティはそれぞれ、オンライン・ストア・エンティティ９０４のプレゼンス情報９１４にサブスクライブされる（図に含まれる点線によって示す）。オンライン・ストア９０４エンティティによって一斉送信されるプレゼンス情報９１４には、発送９０８およびクレジット９１０のプロバイダ・エンティティに対する要求が含まれる。
【００９７】
発送９０８およびクレジット９１０のプロバイダ・エンティティはそれぞれ、オンライン・ストア・エンティティ９０４のプレゼンス情報９１４へのそれらのサブスクリプションに従って、プレゼンス・サーバ９０２から通知を受け取る。たとえば、発送プロバイダ・エンティティ９０８は、オンライン・ストアの発送要求を含むプレゼンス情報９１６を受け取る。発送要求の結果、本の１つのタイトル「ＭｙＢｏｏｋ」が、顧客エンティティ９０６のプレゼンス情報９１２に含まれるアドレスに発送される。加えて、クレジット・プロバイダ・エンティティ９１０は、オンライン・ストアのクレジット要求を含むプレゼンス情報９１８を受け取る。クレジット要求の結果、アカウント「９９９９９９９９９」からのクレジットが、顧客エンティティ９０６の代わりにクレジット・プロバイダ・エンティティ９１０によって、本の購入価格に対して提供される。
【００９８】
なおクレジット・プロバイダ・エンティティ９１０は、顧客エンティティ９０６のプレゼンス情報９１２へもサブスクライブすることができる（再び、図の破線によって示される）。サブスクリプションの結果、クレジット・プロバイダ・エンティティ９１０は、本の購入に対する要求を顧客エンティティ９０６が起こしたときに、オンライン・ストア９０４からのクレジットに対する要求を、顧客エンティティ９０６の代わりに事前に処理することができる。その結果、クレジットを、注文がオンライン・ストアによって実現されたときに購入に対して事前に承認することができ、その結果、全体として取引の効率が上がる。
【００９９】
代替的な実施形態においては、オンライン・ストア・エンティティ９０４が、前述したように発送プロバイダ９０８およびクレジット・プロバイダ９１０のエンティティに向けた要求を出すのではなくて、発送プロバイダ９０８およびクレジット・プロバイダ９１０エンティティが、それらのサービスに関係する通知を、オンライン・ストア・エンティティ９０４によって公開された、それらのサービスを指定するすべての応答への未処理のサブスクリプションに従って、受け取る。このような配置によって、発送プロバイダ９０８およびクレジット・プロバイダ９１０のエンティティは、当該の取引情報に対する顧客エンティティ９０６とオンライン・ストア・エンティティ９０４との間の要求／応答取引を監視する。
【０１００】
たとえば、オンライン・ストア・エンティティ９０４が、本の購入への顧客エンティティ９０６の要求に対する応答を公開するときを考えると、顧客は、注文は「進行中」であるという通知を受け取る。発送プロバイダ９０８およびクレジット・プロバイダ９１０エンティティは、公開された応答にサブスクライブされているが、これらは、それらの既存のサブスクリプションに従って第１の通知を受け取る。クレジット・プロバイダ・エンティティ９１０は、たとえば、発送コストが計算されておらず公開済みのプレゼンス情報に含まれていない場合には、この第１の通知を無視してもよい。発送プロバイダ・エンティティ９０８は、オンライン・ストア９０４に対して、送料およびおそらくは積み込み日を示すデータを公開する（またはプレゼンス・サービスの外側または「帯域外」のデータを送る）。
【０１０１】
そしてオンライン・ストア９０４エンティティは、その応答タプルを新しい発送情報を用いて更新し、またこの情報をプレゼンス・サーバ９０２へ公開する。この時点で、顧客９０６エンティティは、新しい発送情報およびおそらくは新しい取引ステータス表示（たとえば「発送確認済み」）を伴う通知を受け取る。クレジット・プロバイダ・エンティティ９１０は、オンライン・ストア・エンティティ９０４の応答へのそのサブスクリプションに基づいて、第２の通知を受け取る。クレジット・プロバイダ・エンティティ９１０は、通知から、全体的な取引コスト（たとえば、本のコストに新しい送料を加えたもの）が明らかとなったことを決定する。そしてクレジット・プロバイダ・エンティティ９１０は、手数料を承認し、また手数料が承認されたことを示すデータを、オンライン・ストア・エンティティ９０４へ公開する（または帯域外データを送る）。そしてオンライン・ストア・エンティティ９０４は、取引のステータスは「注文完了」であることを示す新しいステータス情報を、既存の応答タプルへ公開する。そして顧客エンティティ９０６は、プレゼンス・サーバ９０２から、新しいステータス情報を伴う通知を受け取る。
【０１０２】
要求および応答エンティティが、プレゼンス情報をそれらの対応するプレゼンス・タプルのみへ公開する代わりとして、以下のような方法について説明する。すなわち要求エンティティが、応答エンティティのプレゼンス情報を、リソースに関係する要求を応答エンティティのプレゼンス・タプルへ加えることによって、更新できるという方法である。この方法を用いれば、要求／応答取引の全体を、単一のプレゼンス・タプルに記憶される情報を用いて行なうことができる。たとえば、図４に示すデータ構造は、応答および要求エンティティの両方のプレゼンス情報を記憶するように構成される。しかし応答および要求エンティティが、同じ主体に付随して、異なるリソースに関係する要求を起こしてそれに応答するように構成されている（図８に例示した方法に関連して説明したように）のではなくて、応答および要求エンティティが、異なる主体に付随して、共通のリソースに関係する要求を起こしてそれに応答するように構成される。
【０１０３】
前述したように、このような方法の場合、標準的なプレゼンス・サービス・アクセス制御ポリシに変更を加える必要があり、より複雑なアクセス制御システムとなる。しかしながら、要求／応答取引の全体を、リソースまたはリソースのオーナに付随する単一のプレゼンス・タプルに記憶される情報を用いて行なえば、データ記憶の使用状況およびデータ交換において効率を高めることができる。
【０１０４】
典型的な方法には、応答エンティティから、応答エンティティに付随するリソースの記述子を含むプレゼンス情報を受け取ることが含まれる。要求を、リソースに関係する記述子とともに、要求エンティティから受け取る。要求には、リソースに関係する要求メッセージが含まれる。応答エンティティのプレゼンス情報を、要求メッセージを含むように更新する。要求メッセージに返答する応答メッセージを含むプレゼンス情報を、応答エンティティから受け取る。そして応答メッセージを、要求エンティティに送る。
実施例
以下の実施例は、前述した考え方を明確にするために、図１０に示す信号フロー図とともに与える。例において行なわれる動作は、説明を目的としたものであり、決して限定するものとして解釈してはならない。ステップの番号順は、以下のテキストにおいてまたは図１０に示す場合も、決して限定するものとしてまたは必要なものとして解釈してはならない。例において、ユーザ（それらのプレゼンス・エンティティおよびエージェントを通して）は、それら自身のプレゼンス・タプルのみを更新することができる。このアプローチによって、プレゼンス・プロトコルを用いて要求応答プロトコルを提供することが、その下にあるプレゼンス・サービスの構造を変化させることなく、可能となる。
【０１０５】
例は、標準的なプレゼンス・タプルが、ウェブ・サービス・リソース（たとえば図２に示す写真を共有するウェブ・サービス１０４ａ）をサポートするように拡張されている構成向けである。写真を共有するサービスは、ウェブ・サイトからアクセス可能とすることもできるし、応答エンティティ（たとえばＰＣ１０２ｂ）によってホスティングすることもできる。ＰＣ１０２ｂには、プレゼンティティ・コンポーネント／ＰＵＡ、ウォッチャ・コンポーネント／ＷＵＡ、および種々の通信クライアント１１０が含まれる。ＰＣ１０２ｂは、ファイアウォール１１４によって保護される。
【０１０６】
最初に、リソース・データ・オブジェクト４１２を、標準的なプレゼンス・タプル４０２の拡張データ用の部分に加える（図４に示す）。例において、プレゼンス・タプル４０２は、ウェブ・サービスのオーナであるゼナに対応するが、ウェブ・サーバ自体にも対応する。リソース・データ・オブジェクト４１２は、写真を共有するサービスに関係する情報（たとえば記述子）を記憶するために用いられる。加えて、１つまたは複数の応答データ・オブジェクト４１４が、サービスに対して起こした要求に対する応答を記憶するために、プレゼンス・タプル４０２に加えられる。
【０１０７】
リソース４１２および応答４１４データ・オブジェクトは、写真を共有するサービス付随するＲＳＵＡを用いてプレゼンス・タプル４０２に加えられる。ＲＳＵＡは、ゼナのプレゼンティティに対する拡張部分であるとともに、ゼナのプレゼンス・タプル４０２のリソース４１２および応答４１６のデータ・オブジェクトを、対応するサービスおよび応答情報を用いて更新するように構成されている。たとえば、ＲＳＵＡは、ウェブ・サイトの活動状態をＰＣ１０２ｂ上で検出し、また動作１００２において、サービス・オーナ（ゼナ）のプレゼンス・タプル４０２を、ウェブ・サービスに関係する情報（たとえばサービス記述子）を用いて更新する。そしてＲＳＵＡは、写真を共有するサービスを他のプレゼンス・エンティティに容易に宣伝する（動作１００４）。これは、ゼナのプレゼンティティ（および任意の付随するＰＵＡ）に、写真を共有するサービスの記述子を含むプレゼンス情報を公開するように指示を出すことによって行なわれる。
【０１０８】
例において、ゼナの友人であるマイクが、要求装置（たとえばカメラ付き携帯電話１０２ｃ）を動作させる。カメラ付き携帯電話１０２ｃには、プレゼンティティ・コンポーネント／ＰＵＡ、ウォッチャ・コンポーネント／ＷＵＡ、および種々の通信クライアント１１０（たとえばＩＭクライアント１０２ｂおよびブラウザ１１０ｆクライアント）を含む。ブラウザ・クライアント１１０ｆは、ウェブ・サービス（たとえば、ゼナの写真を共有するサービス）と情報を交換するために用いられる。またカメラ付き携帯電話１０２ｃを、ファイアウォール（図示せず）によって保護することもできる。
【０１０９】
マイクは、ゼナのプレゼンス・タプル４０２にサブスクライブする（動作１００６）。マイクのサブスクリプションによって、ゼナのプレゼンティティの代わりにマイクのプレゼンス・タプルへのサブスクリプションを自動的に設定する（動作１００８）。あるいは、マイクのプレゼンティティ・コンポーネントは、ゼナに、マイクのサブスクリプションを通知し、その結果、ゼナは、マイクのプレゼンス・タプルへのサブスクリプションを要求する。マイクのプレゼンス・タプルへのサブスクリプションによって、ゼナのウォッチャ・コンポーネントに、マイクのプレゼンス・タプルによって公開される写真共有サービスの要求を通知する。アカウント・サービス１２２を、プレゼンス・サーバ１１８に含めて、マイクおよびゼナの素性を他に対して認証すること、およびプレゼンス・サービス１１８からの情報の受け取りを許可することを行なうようにする。
【０１１０】
動作１０１０において、マイクのウォッチャは、通知メッセージをプレゼンス・サーバ１１８から、動作１００６で設定されるサブスクリプションに応答して受け取る。プロキシ・サービス１２４を用いて、通知メッセージをマイクのファイアウォール（図示せず）通して送ることができる。動作１００６において送られる通知メッセージには、ゼナの写真を共有するサービスの記述子が含まれる。カメラ付き携帯電話１０２ｃには、ＷＵＡと協力してゼナのプレゼンス情報を処理するように構成されたＲＱＵＡを含めることができる。動作１０１２において、ＲＱＵＡは、プレゼンス情報（写真を共有するサービスの記述子を含む）を、適切な通信クライアント（たとえば図２に示すＩＭクライアント１０２ｂ）を用いて示すことができる。
【０１１１】
またＲＱＵＡは、要求データ・オブジェクト４１６をマイクのプレゼンス・タプルへ加えるように構成することもできる。要求データ・オブジェクト４１６は、プレゼンス・タプル４０２の拡張データ用の部分に加えることができる（図４に示す）。マイクがゼナのウェブ・サービスをＩＭクライアント１１０ｆを用いて選択することに応答して、ＲＱＵＡは（おそらくＰＵＡと協力して）、ゼナのプレゼンス・タプルのリソース・データ・オブジェクト４１２に含まれる他の情報（たとえばサービス要求の形式を記述する情報）を用いて、要求メッセージを、マイクのプレゼンス・タプルの要求データ・オブジェクト４１６の中に、写真を共有するサービスの記述子とともに含むことができる。要求は、ゼナの写真を共有するサーバを通して利用できると宣伝されるウェブ・ページに対するものとすることができる。そしてＲＱＵＡは、カメラ付き携帯電話のプレゼンティティに、要求を公開するように指示を出す（動作１０１６）。
【０１１２】
動作１０１８において、プレゼンス・サーバ１１８は、動作１００８で設定されたサブスクリプション要求に従って、通知コマンドをゼナのウォッチャ・コンポーネントに送る。この場合も、プロキシ・サービス１２４を用いて、通知メッセージをゼナのファイアウォール１１４を通して送ることができる。ゼナに要求を通知することもできるし、要求をＰＣのＲＳＵＡおよび／またはＷＵＡを用いて自動的に処理することもできる（動作１０２０）。たとえば、ＲＳＵＡは、特定のウェブ・ページに対する要求を適切なｈｔｔｐ要求に変換して、これを、写真を共有するサービスに送って処理することができる。そしてＲＳＵＡは、写真を共有するサービスから応答を受け取り、そしておそらくは、応答を送信用の適切なメッセージ形式に変換する。動作１０２２において、応答メッセージを、ゼナのプレゼンス・タプルの応答データ・オブジェクト４１４に記憶する。そしてＲＳＵＡは、ゼナのプレゼンティティに、プレゼンス・タプル（応答を含む）をプレゼンス・サーバ１１８へ公開するように指示を出す（動作１０２４）。
【０１１３】
動作１０２６において、プレゼンス・サーバは、通知コマンドをマイクのウォッチャ・コンポーネントに、動作１００６で設定されたサブスクリプション要求に従って送る（この場合もおそらく、プロキシ・サービス１２４を用いる）。マイクに応答を通知することもできるし、応答をカメラ付き携帯電話のＲＱＵＡおよび／またはＷＵＡを用いて自動的に処理することもできる（動作１０２８）。たとえば、ＲＱＵＡは、要求されたウェブ・ページを含む応答メッセージを適切なｈｔｔｐ応答に変換して、これを、マイクのブラウザ・クライアント１１０ｆに送り、要求されたウェブ・ページをマイクのカメラ付き携帯電話１０２ｃのディスプレイ上に表示する。
【０１１４】
プレゼンス・プロトコルを用いて一般的な要求／応答メッセージング・プロトコルを提供するための方法、システム、およびデータ構造について説明してきた。本明細書で説明した技術を用いれば、プレゼンス・プロトコルの公開サブスクライブ・メカニズムを、一般的な要求／応答サービスを提供するように拡張することができる。こうして得られる一般的な要求／応答プロトコルには、プレゼンス・サービスの優位な特徴、たとえば、ファイアウォール通過のための認証、許可、セキュリティ、およびプロキシが含まれる。本明細書で説明した技術によって、プレゼンス・プロトコルまたは要求／応答プロトコルを単独で用いる従来のアプリケーション、サービス、およびワークフローには存在しない特性を有する拡張されたアプリケーション、サービス、およびワークフローを開発することができる。加えて、プレゼンス・サービスは、このような拡張されたアプリケーション、サービス、およびワークフローを実施するための集中型、分散型、ピア・トゥ・ピア、および混合されたアーキテクチャをサポートする。
【０１１５】
当業者であれば理解するように、本明細書で説明した考え方および技術は、その本質的な特性から逸脱することなく、種々の具体的な形態で具体化することができる。現時点で開示されている実施形態は、すべての点において例示的なものであって限定的なものではないと考えられる。本発明の範囲は、前述の説明ではなくて添付の請求項によって示され、その意味および均等物の範囲内に入る変更はすべて包含されることが意図されている。
【図面の簡単な説明】
【０１１６】
【図１】典型的な実施形態によるプレゼンス・プロトコルを用いた一般的な要求／応答プロトコルを提供するシステムを説明する図である。
【図２】典型的な実施形態による応答および／または要求ネットワーク装置を形成することが可能な種々のコンポーネントを説明するブロック図である。
【図３】典型的な実施形態による応答および／または要求エンティティとやり取りするためにリソースのオーナによって使用され得るインターフェースを説明する図である。
【図４】典型的な実施形態により一般的な要求／応答プロトコルを提供する際にプレゼンス・プロトコルとともに用いるためのデータ構造を説明する図である。
【図５Ａ】典型的な実施形態により図４のデータ構造に含まれる要求データ・オブジェクトの拡大図を示す図である。
【図５Ｂ】典型的な実施形態により図４のデータ構造に含まれる要求データ・オブジェクトの拡大図を示す図である。
【図６】典型的な実施形態により図４のデータ構造に含まれる応答データ・オブジェクトの拡大図を示す図である。
【図７】典型的な実施形態によりＩＭリソースに付随するプレゼンス情報を記憶するためのデータ構造を示す図である。
【図８】典型的な実施形態によりプレゼンス・プロトコルを用いて一般的な要求／応答プロトコルを提供するための方法を説明するフローチャートである。
【図９】マルチ・エンティティ取引を行なう際にプレゼンス・エンティティ間で起こる情報の典型的な流れを説明する図である。
【図１０】典型的な実施形態による例示的な要求／応答シナリオに対するシグナル・フロー図である。
【図１】
2008546356.tif 000003
【図２】
2008546356.tif 000004
【図３】
2008546356.tif 000005
【図４】
2008546356.tif 000006
【図５Ａ】
2008546356.tif 000007
【図５Ｂ】
2008546356.tif 000008
【図６】
2008546356.tif 000009
【図７】
2008546356.tif 000010
【図８】
2008546356.tif 000011
【図９】
2008546356.tif 000012
【図１０】
2008546356.tif 000013
【手続補正書】
【提出日】平成19年12月27日(2007.12.27)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
一般的な要求／応答プロトコルを提供するための方法であって、
要求エンティティから、応答エンティティに付随するリソースの記述子と前記リソースに関係する要求とを受け取り、
前記記述子および前記要求を前記応答エンティティへ送り、
前記応答エンティティから、前記要求に返答する応答を受け取り、
前記応答を前記要求エンティティへ送る
ためのプレゼンス・プロトコルを用いることを備える方法。
【請求項２】
前記要求エンティティに対して設定された、前記応答エンティティの少なくとも一部のプレゼンス情報へのサブスクリプションに基づいて、前記リソースの記述子を前記要求エンティティへ送るために、前記プレゼンス・プロトコルを用いることを含む、請求項1に記載の方法。
【請求項３】
応答エンティティのプレゼンス情報へのサブスクリプションを要求エンティティに対して設定するときに、要求エンティティの少なくとも一部のプレゼンス情報へのサブスクリプションを応答エンティティに対して自動的に設定するために前記プレゼンス・プロトコルを用いることを備え、
要求を前記応答エンティティへ送ることは、前記応答エンティティに対して自動的に設定される前記サブスクリプションに基づく、請求項２に記載の方法。
【請求項４】
前記応答エンティティの少なくとも一部の前記プレゼンス情報へのサブスクリプションが前記要求エンティティに対して設定されることを示す通知を、前記応答エンティティへ送り、
前記要求エンティティの少なくとも一部のプレゼンス情報へのサブスクリプションに対して、通知に応答して前記応答エンティティから送られるサブスクリプション要求を受け取り、
前記受け取ったサブスクリプション要求に基づいて、前記要求エンティティのプレゼンス情報へのサブスクリプションを、応答エンティティに対して設定する
ために前記プレゼンス・プロトコルを用いることを備え、
前記要求を前記応答エンティティへ送ることは、前記応答エンティティに対して設定される前記サブスクリプションに基づく、請求項２に記載の方法。
【請求項５】
前記応答エンティティの少なくとも一部のプレゼンス情報に対する前記要求エンティティによるフェッチングまたはポーリング要求に応答して、前記リソースの記述子を前記要求エンティティへ送るために、前記プレゼンス・プロトコル用いることを含む、請求項２に記載の方法。
【請求項６】
前記要求を前記応答エンティティへ送ることは、応答エンティティに対して設定された、前記要求エンティティの少なくとも一部のプレゼンス情報へのサブスクリプションに基づき、前記要求は、前記要求エンティティのプレゼンス情報に含まれる前記応答エンティティの識別子を用いて前記応答エンティティへ送られる、請求項１に記載の方法。
【請求項７】
前記要求は、応答エンティティにより、前記要求エンティティの少なくとも一部のプレゼンス情報に対するフェッチングまたはポーリング要求に応答して前記応答エンティティへ送られ、前記応答は、前記要求エンティティにより、前記応答エンティティの少なくとも一部のプレゼンス情報に対するフェッチングまたはポーリング要求に応答して前記要求エンティティへ送られる、請求項１に記載の方法。
【請求項８】
前記応答を前記要求エンティティへ送ることは、前記要求エンティティに対して設定された、前記応答エンティティの少なくとも一部のプレゼンス情報へのサブスクリプションに基づき、前記応答は、前記応答エンティティのプレゼンス情報に含まれる前記要求エンティティの識別子を用いて前記要求エンティティへ送られる、請求項１に記載の方法。
【請求項９】
前記要求は、前記要求エンティティに付随するプレゼンス情報には含まれるが、前記応答エンティティに付随するプレゼンス情報には含まれず、前記応答は、前記応答エンティティに付随する前記プレゼンス情報には含まれるが、前記要求エンティティに付随する前記プレゼンス情報には含まれない、請求項１に記載の方法。
【請求項１０】
前記応答エンティティに付随する前記プレゼンス情報は、前記リソースのプレゼンス情報または前記リソースのオーナのプレゼンス情報に対応する、請求項９に記載の方法。
【請求項１１】
前記応答エンティティに付随する前記プレゼンス情報が前記リソースのプレゼンス情報に対応するとき、前記リソースのプレゼンス情報には、前記リソースのオーナのプレゼンス情報へのリンクが含まれる、請求項１０に記載の方法。
【請求項１２】
前記要求エンティティに付随する前記プレゼンス情報は、前記要求エンティティに付随する第２のリソースのプレゼンス情報または前記第２のリソースのオーナのプレゼンス情報に対応し、前記第２のリソースは、前記要求を形成するように構成される、請求項９に記載の方法。
【請求項１３】
前記要求および応答の各エンティティの識別子を認証すること、
前記要求または応答を対応するエンティティへ送る前に、前記各エンティティが前記要求または応答を受け取ることを認証すること、
を備える、請求項１に記載の方法。
【請求項１４】
前記要求を前記応答エンティティへ前記応答エンティティに付随するファイアウォールを介して送るか、または前記応答を前記要求エンティティへ前記要求エンティティに付随するファイアウォールを介して送るように構成されたプロキシ・サービスを提供すること
を備える、請求項１に記載の方法。
【請求項１５】
前記記述子は前記要求に含まれる、請求項１に記載の方法。
【請求項１６】
前記記述子は、前記要求を前記要求エンティティから受け取ることと、前記要求を前記応答エンティティへ送ることにおいて使用される対応するプレゼンス・プロトコル・コマンドのそれぞれに含まれる、請求項１に記載の方法。
【請求項１７】
前記記述子を用いて、前記応答エンティティのプレゼンス情報を、前記要求を含むように更新すること、
前記要求に返答する応答を含む前記応答エンティティからの前記プレゼンス情報を受け取ること、
を備える，請求項１に記載の方法。
【請求項１８】
一般的な要求／応答プロトコルを提供するための方法であって、
プレゼンス・サーバを介してリソースの記述子および前記リソースに関係する要求を受け取るためにプレゼンス・プロトコルを用いること、
前記リソースによる前記要求を処理して、前記要求に返答する応答を形成すること、
前記プレゼンス・プロトコルを用いて、前記応答を前記プレゼンス・サーバへ送ること
を含む方法。
【請求項１９】
第２のリソースの第２の記述子および前記第２のリソースに関係する第２の要求をプレゼンス・サーバへ送り、
前記プレゼンス・サーバを介して、前記第２の要求に返答する第２の応答を受け取る
ためにプレゼンス・プロトコルを用いる、
請求項１８に記載の方法。
【請求項２０】
一般的な要求／応答プロトコルを提供するためのシステムであって、
プレゼンス・プロトコルを用いて情報を受け取り、記憶し、かつ配布するように構成された、プレゼンス・サーバと、
前記プレゼンス・プロトコルを用いて情報を前記プレゼンス・サーバと交換するように構成された、応答装置であって、
少なくとも１つのリソースに対するアクセスと、
前記プレゼンス・サーバを介して、前記リソースの記述子と前記リソースに関係する要求とを受け取るように構成された、応答ウォッチャ・コンポーネントと、
前記要求に返答して、応答を前記プレゼンス・サーバに送るように構成された、応答プレゼンティティ・コンポーネントと
を含む、応答装置と、
前記プレゼンス・プロトコルを用いて情報を前記プレゼンス・サーバと交換するように構成された、要求装置であって、
前記記述子および前記リソースに関係する前記要求を、前記プレゼンス・サーバへ送るように構成された、要求プレゼンティティ・コンポーネントと、
前記プレゼンス・サーバを介して、前記要求に返答する前記応答を受け取るように構成された、要求ウォッチャ・コンポーネントと、
を含む、要求装置と
を備えるシステム。
【請求項２１】
前記応答プレゼンティティ・コンポーネントは、前記リソースの記述子を前記プレゼンス・サーバへ送るようにさらに構成され、前記要求ウォッチャ・コンポーネントは、前記リソースの記述子を前記プレゼンス・サーバから受け取るようにさらに構成される、請求項２０に記載のシステム。
【請求項２２】
前記応答装置は、前記リソースと応答しているプレゼンティティおよびウォッチャ・コンポーネントとに結合される応答ユーザ・エージェント・コンポーネントを含み、前記応答ユーザ・エージェント・コンポーネントは、前記リソースの記述子を前記応答プレゼンティティ・コンポーネントによって送ること、前記応答ウォッチャ・コンポーネントによって受け取られる前記要求のリソースによって処理すること、及び前記応答プレゼンティティ・コンポーネントによって前記応答を送ることを容易にするように構成される、請求項２１に記載のシステム。
【請求項２３】
前記要求装置は、前記要求プレゼンティティおよびウォッチャ・コンポーネントに結合される要求ユーザ・エージェント・コンポーネントを含み、前記要求ユーザ・エージェントは、前記要求ウォッチャ・コンポーネントによって受け取られる前記記述子の提示と、前記要求プレゼンティティ・コンポーネントによる前記要求の送信と、前記要求ウォッチャ・コンポーネントによって受け取られる応答を提示とを容易にするように構成される、請求項２１に記載のシステム。
【請求項２４】
前記プレゼンス・サーバは、前記要求を前記応答ウォッチャ・コンポーネントへ、前記応答装置に付随するファイアウォールを介して送る、または前記応答を前記要求ウォッチャ・コンポーネントへ、前記要求装置に付随するファイアウォールを介して送るように構成されたプロキシ・サービスを含む、請求項２０に記載のシステム。
【請求項２５】
前記プレゼンス・サーバは、前記要求および応答の各装置の識別子を認証し、要求または応答を対応する装置へ送る前に、前記要求または応答各前記装置による受け取りを認証するように構成されるアカウント・サービスを含み、前記要求または応答の各前記装置による受け取りを認証するために前記アカウント・サービスによって用いられるロスタおよび／またはプライバシ・リスト情報を含む前記アカウント・サービスに結合されるデータベースを含む、請求項２０に記載のシステム。
【国際調査報告】
2008546356.tif 000014