JP5583790B2 - プレゼンス情報の認可のための方法及びシステム - Google Patents

Description

本発明は、プレゼンス情報のサブスクリプション（購読：subscription）をリクエストしているウォッチャーを認可する分野に関するものであり、また、そのような認可のプロセスを実行するように構成されているプレゼンスシステムに関するものである。

プレゼンスサービスは、周知のネットワークサービスのグループを表しており、これは、第１のユーザ、典型的には、プレゼンティティ（Presentity）と呼ばれる第１のユーザに関連付けられている情報を、１人以上の他のユーザ、典型的には、ウォッチャー（Watchers）と呼ばれる他のユーザへ配信することを主目的とする、様々なタイプの無線通信及び固定通信に適用することができる。この適用には、プレゼンティティが、リクエストされているプレゼンス情報へのウォッチャーによるアクセスを最初に認可することを条件としている。本明細書全体と通して、プレゼンティティとウォッチャーは、それぞれユーザとそれに関連するユーザ機器として参照されるものであり、ここで、ユーザ機器は、プレゼンス対応通信ネットワークへアクセスすることによってプレゼンスサービスを提供するように構成されている。

プレゼンスサービスは、典型的には、ウォッチャーに、プレゼンティティの様々な状態を通知することを可能にし、これには、例えば、到達可能性、可用性、及び他のユーザと通信するプレゼンティティの意向の少なくとも１つがある。プレゼンスサービスは、また、プレゼンティティが現在オンラインであるかどうかを示すために使用され、オンラインである場合は、プレゼンティティがアイドルであるかビジーであるかも示すために使用される。加えて、プレゼンスサービスは、認可済のウォッチャーのアクセスに、通信手段の詳細情報を与え、かつプレゼンティティが登録されている各通信手段それぞれのケイパビリティを与える。

インターネットエンジニアリングタスクフォース（ＩＥＴＦ）ＳＩＰインスタントメッセージング及びプレゼンス活用の拡張（ＳＩＭＰＬＥ）（SIP Instant Messaging and Presence Leveraging Extensions）技術は、周知のプレゼンス対応アプリケーションの１つのタイプを記述する技術であり、このアプリケーションはＳＩＰイベント通知フレームワークの最上部で構築され、また、様々な産業フォーラムで使用するのに適している。この産業フォーラムには、例えば、オープンモバイルアライアンス（ＯＭＡ）、及び第３世代パートナシッププロジェクト（３ＧＰＰ）がある。

図１は、ＳＩＭＰＬＥベースのプレゼンスシステム１００の状況の図であり、このシステムは、従来技術に従って、プレゼンティティＰについてのプレゼンス情報をウォッチャーＷへ提供するように構成されている。プレゼンスシステム１００は、プレゼンスサーバ（ＰＳ）１０１と、プレゼンスサーバＸＭＬ文書管理サーバ（ＰＳ ＸＤＭＳ）１０２とを備えている。従来、周知のように、ＰＳ ＸＤＭＳは、ＰＳに統合されている機能として構成されていても良く、あるいは、ＰＳと相互に接続される別機能として構成されていても良い。

ウォッチャーＷによる自身のプレゼンス情報へのアクセスを許可するあるいは拒否することを可能にするために、プレゼンティティＰは、ＰＳ１０１からの関連するプレゼンス関連情報で更新されることを確実にすることを必要とする、即ち、プレゼンティティにとって関心のあるイベントが発生するときはいつでも必要とする。それゆえ、プレゼンティティＰは、最初に、リクエストをＰＳ１０１へ送信して、関連する更新情報を購読（サブスクライブ）する。ここでは、この関連更新情報は、最初のステップ１：１で示される、自身が所有するウォッチャー情報（Ｗｉｎｆｏ）である。

次のステップ１：２では、ウォッチャーＷは、プレゼンティティＰに関連するプレゼンス情報の購読を要求して、そのような購読をリクエストするためのリクエストをプレゼンスサーバ１０１へ送信する。ステップ１：３で示されるように、ＰＳ１０１は、ＰＳ ＸＤＭＳ１０２からプレゼンティティＰの認可ルールを取得することによってこのリクエストに応答する。この認可ルールが、ステップ１：２のリクエストに対して有効であるルールを備えている場合、ＰＳ１０１は、プレゼンティティＰにそのリクエストを通知し、これにより、ステップ１：５で示されるように、リクエストを認可するか否かの決定を行い、そして、その決定をＰＳ ＸＤＭＳ１０２へ送信する。次に、ステップ１：６で、ＰＳ ＸＤＭＳ１０２は、ＰＳ１０１へその決定を通知する、即ち、認証ルールの更新を通知し、ステップ１：７で、ＰＳ１０１は、その決定をウォッチャーＷへ通知する。その後、ＰＳ１０１は、関連プレゼンス情報をウォッチャーＷへ配信することが可能になる。これは、ステップ１：５において、リクエストがプレゼンティティＰによって許可された場合である。

上述の認可モデルは、認可の責任を有するユーザが、認可を実際に実行するための権限を有しているという事実に基づいている。しかしながら、このような構造が最も適切なものの１つであるとは限らない状況が存在する。ある状況として、例えば、プレゼンティティが未成年である場合がある。別の状況には、プレゼンス情報が複数のプレゼンティティに関連付けられている場合である。

本発明の目的は、少なくとも上述の課題に向けられている。より詳しくは、本発明の目的は、より動的な認可方法を提供することであり、これは、プレゼンス情報の購読を要望するウォッチャーを認可する権利が与えられているエンティティだけとする、プレゼンティティのみに依存しない方法である。本発明は、更に、提案される方法を実行するように構成されているプレゼンスシステムも言及する。

提案される方法は、プレゼンスサービスのアドミニストレータに、プレゼンティティ以外の１つ以上の認可エンティティを単独であるいはプレゼンティティと一緒に定義することを可能にし、また、所定の順序で認可プロセスに関与することを可能にする。これによって、プレゼンス情報の配信に関連付けられているセキュリティの態様を改善することができる。提案される方法は、例えば、プレゼンスに対する並列制御機能を導入することを可能にする。これは、プレゼンティティよりもより上位の認可優先度を有する両親あるいは他の当事者を、認可プロセスにおける検証インスタンスとして含めることができる。そうすることで、検証インスタンス／群が承認する場合に、あるプレゼンティティと関連付けられているプレゼンティティ情報の購読に対するリクエストだけが許可されることになる。

上述の目的に加えて、それに関連する目的は、本明細書の独立請求項に従う、方法及びプレゼンスシステムを提供することによって達成することができる。

一態様に従えば、プレゼンスシステムに適用されるべき、プレゼンティティ（Ｐ）に関連付けられているプレゼンス情報へのアクセスをウォッチャー（Ｗ）へ認可する方法が提供される。

この認可する方法は、ウォッチャー（Ｗ）からのプレゼンティティに関連付けられているプレゼンス情報に対するリクエストの受信によってトリガーされる。そのようなリクエストの受信に応じて、前記プレゼンスシステムは、前記プレゼンティティ（Ｐ）以外の認可インスタンス（Ｃ）に、前記プレゼンス情報に対するリクエストに関連付けられている認可ルールを設定する、変更するあるいは検証するための機会が与えられるべきであることを示す命令を取得する。この段階で、認可ルールは、既に、前記プレゼンスシステムに設定され、かつ記憶されていても良い。あるいは、認可ルールは、前記認可インスタンスによって設定されていなければならない場合がある。

この命令に従って、前記プレゼンスシステムは、前記認可インスタンス（Ｃ）に、前記プレゼンス情報に対するリクエストを通知することによって、前記認可インスタンス（Ｃ）に、前記認可ルールを、設定する変更するあるいは検証することを可能にする。前記認可インスタンス（Ｃ）に通知した後、前記プレゼンスシステムは、前記認可ルールの設定、変更あるいは検証を示す通知が前記認可インスタンスから受信される場合には、前記命令と該通知に基づいて該認可ルールの最終決定を行い、前記通知が受信されない場合には、前記命令のデフォルトの認可ルールに基づいて、該認可ルールの最終決定を行う。

別の実施形態に従えば、認可インスタンスを通知するステップは、前記認可ルールの最終決定を実行する前に、前記命令に従って、前記プレゼンティティ（Ｐ）以外の少なくとも１つの更なる認可インスタンス（Ｄ、Ｅ）に対して、認可インスタンスへ通知するステップが繰り返される。

複数の認可インスタンスが認可プロセスに関与している場合、複数の認可インスタンス（Ｃ、Ｄ、Ｅ）の順序が、命令に含まれる権限リストに基づいて判定され、そうすることで、最高権限が与えられている前記認可インスタンス（Ｃ、Ｄ、Ｅ）が、最初に通知される認可インスタンスとなる。

通知される認可インスタンス（Ｃ、Ｄ、Ｅ、Ｐ）は、前記認可プロセスに関与しないことを決定する場合があるので、前記プレゼンスシステムはいくつかのタイプの制御メカニズムを必要とする場合がある。これは、前記プレゼンスシステムに前記認可プロセスを継続することを可能にするものである。このようなメカニズムは、タイマー機能をプレゼンスシステムに導入することによって取得することができる。通知が認可インスタンス（Ｃ、Ｄ、Ｅ、Ｐ）に一旦送信されると、認可インスタンスに関連付けられているタイマーが開始される。

認可インスタンスを通知するステップは、前記タイマーのタイムアウトの前に、あるいは前記タイマーのタイムアウト時に、前記認可インスタンス（Ｃ、Ｄ、Ｅ、Ｐ）の通知に応じて、設定された、変更されたあるいは検証された認可ルールの通知が受信される場合、別の認可インスタンス（Ｄ、Ｅ、Ｐ）に対して繰り返される。

前記タイマーを適用することによって、前記プレゼンスシステムは、制御可能なプロセスを動作させることができる。これは、一連の認可インスタンスに、前記最高権限を有する前記認可インスタンス（Ｃ、Ｄ、Ｅ、Ｐ）が対応する通知に応答するまで、あるいは該認可インスタンスに関連付けられている前記タイマーがタイムアウトするまで連続的に通知される。

認可中に使用されるべき前記命令は、前記プレゼンスシステムのプレゼンスルールで定義されても良く、あるいは、別の文書で構成設定されていても良い。

ウォッチャーがプレゼンス情報を購読することをリクエストしていることを認可インスタンスに通知するために、認可インスタンスに送信される通知は、典型的には、ウォッチャー（Ｗ）が前記プレゼンティティ（Ｐ）に関連付けられているプレゼンス情報をリクエストしていることを示す指示と、どんな種類のプレゼンス情報をウォッチャー（Ｗ）がリクエストしているかについての情報を含んでいる。

認可プロセス中には、通知される認可インスタンスは、ウォッチャーとプレゼンティティとを識別することができるようになっている。これらの識別情報は、Ｔｏヘッダ、Ｆｒｏｍヘッダ、あるいは、前記通知の通知本体に含まれていても良い。選択的には、これらの識別情報は、前記通知の新規の専用のアイデンティティヘッダに含まれていても良い。

認可インスタンスに対して、認可すべきウォッチャーとプレゼンス情報のリクエストを通知するために、認可インスタンスは、ウォッチャー情報あるいは認可ルールの更新を購読することをリクエストしても良い。ウォッチャー情報は、例えば、ウォッチャー情報通知メッセージをプレゼンスシステムに提供することによって購読することができ、一方、認可ルールの更新は、例えば、ＸＣＡＰ変更通知メッセージをプレゼンスシステムに提供することによって購読することができる。選択的には、フィルタ処理された情報を購読することができ、例えば、そうすることで、適用可能な命令に従う認可プロセスに対して関連する認可ルールの変更だけを受信するようにする。これによって、通知の量を制限することができる。

認可ルールを設定、検証及び更新するために認可される認可インスタンスだけに通知されることを保証するために、プレゼンスシステムは、購読リクエストが認可インスタンスから受信される段階で、認可インスタンスが認可されるかどうかを判定するように構成することもできる。選択的には、そのような判定は、通知の前に実行されても良い。この判定は、典型的には、プレゼンティティのアクセスルールに基づいて実行される。

別の態様に従えば、上述の方法を実行するために適しているプレゼンスシステムが提案される。このプレゼンスシステムは、典型的には、プレゼンスサーバとＰＳ ＸＤＭＳ機能を備え、ＰＳ ＸＤＭＳ機能はプレゼンスサーバに統合されている、あるいは、プレゼンスサーバと対話する別のエンティティとして構成されている。

プレゼンシステムは、前記プレゼンス情報に対するリクエストを、前記ウォッチャー（Ｗ）から受信するための通信ユニットと、前記プレゼンティティ（Ｐ）以外の認可インスタンス（Ｃ）に、前記プレゼンス情報に対するリクエストに関連付けられている認可ルールを設定する、変更するあるいは検証するための機会が与えられるべきであることを示す命令を取得するための認可ユニットとを備える。プレゼンスシステムは、更に、前記認可インスタンス（Ｃ）に、前記プレゼンス情報に対するリクエストを通知することによって、前記認可インスタンス（Ｃ）に、前記認可ルールを設定する、変更するあるいは検証することを可能にする通知ユニットも備える。

前記認可ユニットは、また、前記認可ルールの設定、変更あるいは検証を示す通知が前記認可インスタンス（Ｃ）から受信される場合には、前記命令と該通知に基づいて該認可ルールの最終決定を行い、前記通知が受信されない場合には、前記命令のデフォルトの認可ルールに基づいて、該認可ルールの最終決定を行うように構成されている。

プレゼンスシステムには、タイマーユニットが提供されても良い。このような場合、認可ユニットは、前記認可インスタンス（Ｃ、Ｄ、Ｅ、Ｐ）を通知することを前記通知ユニットへ指示する時にタイマを開始し、該指示に従って、最終決定を行うように、あるいは、前記タイマーのタイムアウト前にあるいはタイムアウト時に、設定された、変更されたあるいは検証された認可ルールが前記認可インスタンス（Ｃ、Ｄ、Ｅ）の前記通知に応じて、前記通信ユニットによって受信される場合に、別の認可インスタンスを通知することを前記通知ユニットへ指示し、別の関連付けられているタイマーを開始するように、構成されている。

前記通知ユニットは、典型的には、ウォッチャー（Ｗ）が前記プレゼンティティ（Ｐ）に関連付けられているプレゼンス情報をリクエストしていることを示す指示と、どんな種類のプレゼンス情報をウォッチャー（Ｗ）がリクエストしているかについての情報とを、認可インスタンスに送信されるべき通知へ追加するように構成されている。前記通知ユニットは、前記ウォッチャー（Ｗ）のアイデンティティと前記プレゼンティティ（Ｐ）のアイデンティティとを追加するように構成されている。それゆえ、前記通知ユニットは、これらのアイデンティティを、Ｔｏヘッダ、Ｆｒｏｍヘッダ、あるいは、前記通知の通知本体のいずれか１つに追加するように構成されていても良い。

提案される認可プロセスに関与する権限が与えられている認可インスタンスだけに通知を提供するために、認可ユニットは、更に、前記認可インスタンス（Ｃ、Ｄ、Ｅ、Ｐ）から、前記認可ルールの更新あるいはウォッチャー情報を購読するためのリクエストを受信するように構成され、そのようなリクエストに応じて、前記認可ユニットは、例えば、プレゼンティティ（Ｐ）のアクセスルールを問い合わせることによって、認可をチェックし、そして、認可されるべきことが判定される認可インスタンスだけに通知するように構成されている。選択的には、認可ユニットは、通知に応じて権限をチェックするように構成されていても良い。

本発明の更なる特徴と利点は、以下の詳細説明から理解することができる。

従来技術に従う、プレゼンティティに関連付けられているプレゼンス情報をリクエストするウォッチャーを認可するための状況を示す図である。 例示の実施形態に従う、プレゼンティティのプレゼンス情報へのアクセスをリクエストするウォッチャーを認可するための認可手順に関与することを、プレゼンティティ以外の認可インスタンスに可能にする方法を示すフローチャートである。 プレゼンティティ以外の認可インスタンスによって認可の決定が行われる一実施形態に従う状況を示す図である。 複数の認可インスタンスが関与した後に認可の決定が行われる別の実施形態に従う状況を示す図である。 プレゼンティティによって行われる認可の決定が、別の認可インスタンスによって検証されなければならない第３の実施形態に従う状況を示す図である。 図２−図３ｃのいずれか１つを参照して提案される認可方法を実行するために適している例示のプレゼンスシステムを示すブロック図である。 図４を参照して説明される実施形態のような、プレゼンスシステムの一部である例示のＰＳ ＸＤＭＳを示すブロック図である。

本明細書は、プレゼンティティ以外の、以下では、サードパーティ認可インスタンスと呼ぶ、ユーザあるいは認可インスタンスに、認可ルールを更新する、即ち、プレゼンティティの認可ルールを、設定する、変更するあるいは検証することを可能にする方法について言及する。ここで、ルールは、プレゼンティティＰに関連付けられているプレゼンス情報を購読（サブスクライブ：subscribe）することをリクエストするウォッチャーに関連付けられている。あるいは、この方法は、別の認可インスタンスによって既に特定されている認可ルールを検証することを可能にするものであり、この別の認可インスタンスは、プレゼンティティ自身であっても良く、あるいは、別の認可インスタンスであっても良い。

以下では、認可インスタンスは、プレゼンス情報を購読することをリクエストするウォッチャーを認可するためのプロセスに関与することが認可されているユーザであり、かつユーザが登録されているユーザデバイスとして言及する。ユーザデバイスは、任意のタイプのプレゼンスサービス対応無線あるいは固定ユーザデバイスであっても良く、即ち、ユーザデバイスは、プレゼンスシステムへアクセスするように構成されている。

どの認可インスタンスあるいは認可インスタンス群が認可プロセスに関与することが許可されているか、加えて、認可プロセスに含まれるべき２つ以上の認可インスタンスがある場合に、認可手順に関与することが許可されるべき様々な認可インスタンスの順序は、所定の認可命令に基づいて判定されることになる。以下では、この所定の認可命令を命令と呼ぶことにする。典型的な状況では、プレゼンス情報に対する特別なリクエストに対して適用可能な命令は、ウォッチャーとプレゼンティティに依存する。この命令は、プレゼンティティＰの承認書の拡張部分を構築することができる、あるいは、別の文書として構成することができる。この命令は、永久的な基準として特定されていても良く、あるいは、より動的な性質を持っていても良く、そうすることで、この命令は、例えば、日時、あるいはプレゼンスに関連するトラフィック量のような基準に依存することになる。

上述の一般的な原理に従う、プレゼンティティに関連付けられているプレゼンス情報へのアクセスをウォッチャーに認可するためのプレゼンスシステムの方法を、図２のフローチャートを参照して更に詳細に説明する。

必要条件として、プレゼンティティとそれぞれの認可インスタンスがプレゼンス関連更新を購読することをリクエストしていると想定する。ここで、プレゼンス関連更新は、潜在的な認可インスタンスを指示するためのトリガーとして機能することになり、認可インスタンスは、特別なリクエストにおいて認可の決定を行うことが予期されている。このようなリクエストは、例えば、プレゼンティティウォッチャー情報の更新のリクエストであっても良く、あるいは、ウォッチャー情報の選択された部分、即ち、リクエストに従ってフィルタにかけられているウォッチャー情報のリクエストであっても良い。

ウォッチャー情報は、ウォッチャー情報通知として、認可インスタンスに提供されても良い。選択的には、ウォッチャーは、プレゼンティティに関連付けられているＸＣＡＰ変更通知をリクエストすることによって、購読ルールの更新についてのみ購読するためのリクエストを選択することができる。また、購読ルールの更新を購読する場合には、そのような購読（サブスクリプション）が登録されることで、例えば、「許可」から「ブロック」への変更あるいはその反対を示す認可ルールを更新することに制限することができる。フィルタにかけられている購読リクエストは、認可インスタンスに提供される通知の数を制限するための理由から好ましい場合があり、そうすることで、認可インスタンスに関連する重要な通知だけが認可インスタンスに提供される。

図２の第１のステップ２００において、プレゼンティティに関連付けられているプレゼンス情報のリクエストがウォッチャーから受信される。このリクエストは、ウォッチャーＷがプレゼンティティＰに関連付けられているプレゼンス情報を購読することをリクエストしていることと、ウォッチャーＷが取得することに関心のあるプレゼンス情報のタイプを示している。このリクエストは、更に、ウォッチャーＷのアイデンティティとプレゼンティティＰのアイデンティティとを含んでいる。そのようなリクエストを受信することに応じて、プレゼンスサーバは、次のステップ２１０で示されるように、受信したリクエストを認可する場合に適用される条件における所定の命令を取得する。典型的な状況では、この命令はＰＳ ＸＤＭＳからアクセス可能に記憶されているが、代替としては、関連する命令がＰＳに記憶されていても良い。

従来の認可手順に従えば、プレゼンス情報のリクエストの認可は、認可ルールに基づいて実行され、これは、各プレゼンティティと購読リクエストに対して適用可能である。一旦設定されると、認可ルールは、関連するウォッチャーの購読リクエストが許可されるべきかあるいは拒否／ブロックされるべきかを指示する。即ち、リクエストを行っているウォッチャーが配信されるリクエストされたプレゼンス情報を有することになるか、あるいはリクエストされたプレゼンス情報へのアクセスが拒否されることになるかを指示する。この命令は、ＰＳに、どのようにして、受信したリクエストについて最終的な認可の決定を行うかを指示する。

提案の命令を導入することによって、プレゼンティティ以外の１つ以上の認可インスタンスは、既に設定されている認可ルールを変更するための機会が与えられることになる、あるいは、プレゼンス情報のリクエストに関連付けられている認可ルールを検証するための機会が与えられることになる。

この命令は、典型的には、適用可能な認可ルールが各ウォッチャーと受信したリクエストに対して存在していない状況、及び従前のエンティティ、即ち、プレゼンティティ以外の１つ以上の認可インスタンスが、プレゼンスサーバによって最終的な認可の決定を行うことができる前に、認可プロセスに関与する機会が与えられるべきである場合の少なくとも一方に対する特別な命令を有する。また、この命令は、典型的には、最終的な決定で使用されるデフォルトの命令あるいは決定を含んでいて、これは、特定のリクエストの認可プロセスに関与することが許可されている１つ以上の認可インスタンスが認可ルールを変更しないあるいは検証しない場合である。

例として、所定の命令に従う、プレゼンティティであるアリスに関連付けられているプレゼンス情報に対するリクエストが、少なくとも２つの認可インスタンス、例えば、彼女の両親の少なくとも一方からの検証を要求するとする。彼女の両親のどちらもがそのリクエストを許可することができない場合、認可ルールはデフォルトによってブロックに設定される。即ち、リクエストされる購読は拒否される。

別の例に従えば、ウォッチャーは、複数の認可インスタンスの大多数がリクエストを許可している場合にのみ認可される。このような条件の場合では、デフォルトの条件は、十分な数の認可インスタンスがそれぞれの通知に応答しない場合にはリクエストはブロックされるべきであることを提示すべきである。

この段階では、プレゼンスサーバも、認可インスタンスに、プレゼンティティに適用可能なアクセスルールを取得することによって各認可ルールを更新する権利が与えられているかどうかを検証することができる。選択的には、プレゼンスルールが、ウォッチャーからのリクエストを受信することに関連付けて既に検証されていても良い。どのような場合でも、認可インスタンスに認可ルールを更新する権利が与えられている場合には、これは、ＰＳが認可インスタンスに通知することができることを示す、ＰＳへの指示にもなる。

次のステップ２２０で、ＰＳは、例えば、ウォッチャー情報あるいは他の対応する情報を認可インスタンスへ提供することによって、認可インスタンスへ通知する。

通知の受信に続いて、認可インスタンスは、そのような通知を、ＰＳ ＸＤＭＳへ送信されるＸＣＡＰ ＰＵＴの形式で転送することによって購読リクエストに対する決定を行うことができる。ここで、ＰＳ ＸＤＭＳは、そのような通知に対して、オプションのステップ２３０で示されるように、認可ルールの更新／変更をＰＳへ通知することによって応答する。

認可ルールの変更を指示する通知に基づいて、あるいは認可ルールに対して適用可能なデフォルトの指示に基づいて、認可ルールの現在の内容が、認可済の認可インスタンス／認可インスタンス群によって検証されるものとして見なすことができるかどうかが判定され、あるいは、１つ以上の追加の認可インスタンスが最終決定を行う前に通知されるべきかどうかが判定され、そうすることで、最終的な認可の決定をＰＳによって行うことができる。この条件ステップは、図２のステップ２４０で示され、一方、最終決定は、ステップ２５０で行われる。

更新済の認可ルールに基づいて、認可プロセスの次のステップは、ステップ２４０における命令から確認することができる。しかしながら、認可インスタンスは、認可プロセスに関与しなくて済ますことができる場合があり、これは、例えば、意図的に認可決定を別のパーティに委ねることによるものである。あるいは、そのよう気になれない場合である。

典型的な状況では、プレゼンティティは認可プロセスに関与することになり、また、上述のような決定を、プレゼンティティ以外の認可インスタンスによる検証前の早い段階で、あるいはプレゼンティティが認可ルールを更新した後で、行うことができる。この場合、ステップ２４０において、プレゼンティティ以外の認可インスタンスによって更新される認可ルールはまだ検証することができないと判定され、この認可インスタンスに決定を変更するための機会、つまり、認可ルールを更新するための機会を与えるために、あるいは、決定を承認する機会を与えるために、その認可インスタンスへ通知するプロセスが、図２に示されるようにステップ２２０から繰り返される。

認可インスタンスが認可ルールを更新しないイベントに対しては、ステップ２２０はタイマーの使用を含むことができる。そうすることで、認可インスタンスへの通知を送信することに関連付けられているタイマーが開始される。それに応じて、タイマーのタイムアウトの前に通知が受信されない場合、認可プロセスが、ステップ２４０における命令の次の段階に従って継続される。一方、タイムアウト前に通知が受信される場合、その通知は、それに応じて、ステップ２４０において処理される。ステップ２２０−２４０は、その命令に依存して、１つ以上の認可インスタンスに対して繰り返される。

一方、ステップ２５０において、最終決定を行うことができると判定される場合、ステップ２６０で示されるように、ＰＳは認可ルールをウォッチャーへ通知し、そして、認可プロセスが終了される。ステップ２５０において、ウォッチャーが認可されている場合、ＰＳは、この段階から、関連するプレゼンス情報を、従来のプレゼンス配信手順に従って、ウォッチャーへ提供する。

上述のように、ステップ２２０からステップ２４０は、ステップ２６０及びステップ２７０の前に、プレゼンティティ以外の少なくとも１つの別の認可インスタンスに対して繰り返し実行される場合がある。このような状況は、例えば、プレゼンティティ以外の少なくとも１つの別の認可インスタンスが、肯定的な最終決定で終了するために認可ルールを検証しなければならない、即ち、「許可」に設定される認可ルールを検証しなければならない場合に適用することができる。選択的には、複数の認可インスタンスのすべて、あるいはその大多数からの許可が要求される場合がある。

第１の実施形態に従えば、ステップ２２０からステップ２４０は、プレゼンティティ（Ｐ）以外の１つ以上の認可インスタンスに対して同一のステップが実行される前に、認可インスタンスであるプレゼンティティに対して最初に実行される場合がある。この状況では、プレゼンティティによって行われる更新／決定は、プレゼンティティ以外の認可インスタンスによって検証され、ここで、この認可インスタンスは、典型的には、そのプレゼンティティより高い優先度と、プレゼンティティによって行われる決定に関係なく、そのような決定を変更すること、あるいは、より以前の認可インスタンスによって与えられる決定に同意するための権限を有している。

別の実施形態に従えば、ステップ２２０からステップ２４０は、代わりに、プレゼンティティ以外の１つ以上の認可インスタンスに、認可ルールを更新するための機会が通知され、かつ与えられた後に、認可インスタンスとするプレゼンティティで繰り返されても良い。この状況では、プレゼンティティは、別の認可インスタンスによって与えられる決定を検証し、かつ、典型的には、決定を拒否する、あるいはリクエストを許可する従前の決定で承認するための権限だけを有する場合がある。一方、リクエストを拒否する決定は、プレゼンティティによって許可する決定を変更することができない。これは、プレゼンティティは、典型的には、より低い優先度を有しているからである。

上述の方法は、いくつかの異なる実施形態に従って適用することができる。提案される認可方法を実現する異なる３種類の方法を、図３ａ−図３ｃを参照して以下でそれぞれ説明する。この例は、インターネットエンジニアリングタスクフォース（ＩＥＩＦ）のインスタントメッセージングとプレゼンスに基づくプレゼンス活用拡張（Presence Leveraging Extensions）用のＳＩＰ（ＳＩＭＰＬＥ）に基づいているとしても、提案される方法は、プレゼンス対応規格あるいはプロトコルに基づいているプレゼンスシステムにも使用することができることを理解するべきである。このプロトコルは、例えば、オープンモバイルアライアンス（ＯＭＡ）、第３世代パートナシッププロジェクト（３ＧＰＰ）、リッチ通信スイート（ＲＣＳ）、あるいは拡張メッセージング及びプレゼンスプロトコル（ＸＭＰＰ）がある。

第１の実施形態に従う認可プロセスは、プレゼンティティ（Ｐ）以外の認可インスタンス（Ｃ）だけがプレゼンティティ（Ｐ）に関連付けられているプレゼンス情報へアクセスするために、ウォッチャー（Ｗ）の認可に関与し、以下で、図３ａを参照して詳細に説明する。

必須条件として、ステップ３：１ａと３：１ｂそれぞれで示される、認可インスタンスＣとプレゼンティティＰは、プレゼンティティＰ ウォッチャー情報を購読している。そうすることで、認可インスタンスＣは、ウォッチャーＷがプレゼンティティＰに関連付けられているプレゼンス情報を購読することをリクエストするときはいつでも通知されるようになる。このプレゼンティティＰは、関連認可インスタンスとして、認可インスタンスＣが認可に関与することを可能にする。

次のステップ３：２で、ＰＳ３００は、ウォッチャーＷから、プレゼンティティＰに関連付けられているプレゼンス情報に対するリクエストを受信する。そのリクエストに応じて、ＰＳ３００は、プレゼンティティＰのＰＳ ＸＤＭＳ３０１からプレゼンティティＰに対して適用可能な命令を取得する。選択的には、この命令は、ＰＳ３００の記憶装置から取得されても良い。この命令に基づいて、ＰＳ３００は、ウォッチャーＷに対する認可ルールが存在しない場合を判定して、それに応じて、命令から、プレゼンティティＰでない認可インスタンスＣが、ウォッチャーＷのリクエストを認可することが判定される。

ステップ３：４で示されるように、ＰＳ３００は、認可インスタンスＣに期待認可タスクを通知する。この例では、ステップ３：５で示されるように、認可インスタンスＣは、ウォッチャーＷの購読リクエストを、ＰＳ ＸＤＭＳ３０１の各認可ルールを設定するあるいは更新することによって、典型的には、ＸＣＡＰ ＰＵＴをＰＳ ＸＤＭＳ３０１へ送信することによって許可することを決定する。ステップ３：６で示されるように、Ｃによって決定される認可ルールの更新に応じて、ＰＳ ＸＤＭＳ３０１は、更新通知をＰＳ３００へ送信する。

認可プロセスが完了すると、ステップ３：７ａにおいて、ＰＳ３００はプレゼンティティＰに決定／更新を通知することができる。これは、プレゼンティティＰに、いかなる影響もその決定に与えることを許可することなく行うことができる。次に、ステップ３：７ｂにおいて、ウォッチャーＷは、決定／更新に気付くことができる。選択的には、プレゼンティティＰに認可ルールの更新が通知される。即ち、この更新とは、通知を介して認可インスタンスＣによって行われる決定であり、この通知には、例えば、ＰＳ ＸＤＭＳから提供されるＸＣＡＰ変更ＳＩＰ ＮＯＴＩＦＹ（通知）がある。後者の場合、プレゼンティティＰは、ステップ３：１ｂにおいて、ウォッチャー情報に代えて、ＸＣＡＰ変更の購読をリクエストしているべきである。

プレゼンティティＰとサードパーティエンティティＣを含む複数の認可インスタンスが認可プロセスに関与している、別の認可プロセスを、図３ｂを参照して更に詳細に説明する。

この実施形態に従えば、命令は、通知されるべき認可インスタンスの順序を記述することができ、この順序は、最高権限が与えられている認可インスタンスから開始する。本例では、認可インスタンスＣが最高権限を有しているので、従って、最初のステップ４：１ａ−４：６は、図１を参照して説明される上述の実施形態の最初のステップ群に対応する。即ち、認可インスタンスＣには、まず、リクエストが通知され、そして、そのリクエストとウォッチャーＷを認可するための機会が与えられる。

認可インスタンスＣによって行われる決定に依存して、ＰＳ３００は、認可ルールを検証すること、あるいはプレゼンティティＰに通知することを決定し、これによって、プレゼンティティＰにも決定を行うことを可能にする。即ち、認可ルールを設定するあるいは更新することを可能にする。但し、これには、権限の制限がある。このリクエストが、最高権限を有する認可インスタンスである認可インスタンスＣによってブロックされる場合、プレゼンティティＰの意見は無意味なものとなり、ステップ４：７及び４：１０で示されるように、ＰＳ３００は、認可インスタンスによって行われる決定を最終決定として検証し、リクエストの拒否をウォッチャーＷとプレゼンティティＰへ通知することができる。拒否の場合、ステップ４：８とステップ４：９は実行されない。

一方、図で例示されるように、リクエストがＣによってブロックされない場合、ステップ４：７において、プレゼンティティＰに、認可ルールの更新が通知され、そして、認可インスタンスＣによって更新される認可ルールを検証することによって、認可ルールをブロックする、即ち、認可ルールを更新するための、あるいは、リクエストを受け付けるための機会が与えられる。この処理は、ステップ４：８で実行され、一方、ステップ４：９において、更新がＰＣ３００に通知される。この場合、ステップ４：１０で示されるように、ここでは、命令は、各リクエストに対して通知されるべきすべての認可インスタンスに通知されていて、また、最終決定がＰＳ３００によって行われ、ウォッチャーＷへ転送できることを特定する。

別の実施形態に従えば、プレゼンティティによって行われる認可の決定は、最終決定が行われる前に、サードパーティ認可インスタンスによって許可されなければならなくなり、一方、サードパーティ認可インスタンスによって許可されない場合、リクエストは拒否されることになる。代替の実施形態を、図３ｃを参照して更に詳細に説明する。

上述の実施形態との類似点は、特定のプレゼンティティに関連付けられている認可手順に関与すべき認可インスタンスは、最初に、プレゼンティティに関連付けられているプレゼンス関連情報で更新することを可能にするための準備を行うことである。図３ｃでは、これは、ステップ５：１ａで示される、ＸＣＡＰ変更購読をリクエストするサードパーティ認可インスタンスＣと、ステップ５：１ｂで示される、Ｗ情報に対する購読をリクエストするプレゼンティティによって達成される。選択的には、プレゼンティティＰは、ＰＳ ＸＤＭＳ３０１からＸＣＡＰ変更を購読することができる。ここでも、これらの購読リクエストは、ＰＳ３００によって許可されると想定する。

次のステップ５：２では、プレゼンティティＰに関連付けられているプレゼンス情報に対する購読リクエストがウォッチャーＷから受信され、これは、ステップ５：３で示されるように、ＰＳ３００が、ＰＳ ＸＤＭＳ３０１からのリクエストに対する認可プロセスをどのように処理するかについての命令を取得する結果となる。ＰＳ３００はこの命令に従うことになり、この命令は、この場合、プレゼンティティＰが、ステップ５：２で受信されるリクエストが許可されるかあるいはブロックされるかについて決定するための第１の機会が与えられることを示していて、また、一旦、プレゼンティティＰが認可を決定すると、認可インスタンスＣがその決定を検証するための機会が与えられることを示している。より詳しくは、認可インスタンスＣが、常に、認可の最終結果を判定するインスタンスになるということである。

その結果、ステップ５：４で示されるように、プレゼンティティＰは、ウォッチャー情報の通知を有するリクエストが通知される。その通知に応じて、プレゼンティティＰは、認可ルールを設定しあるいは更新し、そして、その結果をＰＳ ＸＤＭＳ３０１へ送信することによって、典型的には、ＸＣＡＰ ＰＵＴをＰＳ ＸＤＭＳ３０１へ送信することによって、リクエストの認可についての決定を行うことを選択することができる。図３ｃでは、このような決定は、ステップ５：５で示されている。ＰＳ ＸＤＭＳ３０１で、決定が登録される。即ち、関連する認可ルールがそれに従って更新され、その結果、ステップ５：６で示されるように、ＰＳ ＸＤＭＳ３０１は、ＸＣＡＰ変更通知を生成する。ここで、このＸＣＡＰ変更通知は、ＸＣＡＰ変更を購読する認可インスタンスＣに送信される。図には示されていないが、ステップ５：５における認可ルールの更新は、ＰＳ３００へ送信される通知をもたらすことになり、これは、図３ｂでは、ステップ４：９に対応する。

上述のように、購読リクエスト５：１ａと関係して、認可インスタンスＣは、例えば、許可する認可ルールの変更のみの購読を選択することができる。このような場合、ＰＳ ＸＤＭＳ３０１は、そのような変更がＰＳ ＸＤＭＳ３０１に登録される場合に、ＸＣＡＰ変更通知を認可インスタンスＣへ提供することだけを行うことになる。

本例では、ステップ５：７で示されるように、認可インスタンスＣが決定を行う。ＰＳ ＸＤＭＳ３０１は、ステップ５：１ａで開始される購読に従って、応答を行い、ステップ５：８で示されるように、ＰＳ３００に認可ルールの更新を通知する。図では示されていないが、プレゼンティティＰにも、図３ｂのステップ４：７に対応する、ウォッチャー情報の通知を介して、その決定が通知されても良い。命令により、ＰＳ３００は、この段階で、少なくとも１つの決定が、認可に対して決定的なものであることに気付く場合がある。つまり、最終決定をこの段階で行うことができることに気付くことができる。このような最終決定の結果は、典型的には、ステップ５：９で示されるように、ウォッチャーＷへ送信される。認可手順は、ここで、完了して、そして、適切なときはいつでも、関連プレゼンス情報をＰＳ３００からウォッチャーＷへ配信することができる。

ＰＳ３００とＰＳ ＸＤＭＳ２０１は図３ａ−図３ｃにおいては個別のエンティティとして示されているとしても、これらのエンティティは、選択的には１つの単一のエンティティとして構成されても良いことが理解されるべきである。記載される状況は、提案される認可方法を実行することができるいくつかの方法を例示のために簡略されていて、従来のプレゼンスプロセスで通常に実行されるステップ群の内、提案される方法の理解に必要のないものは、簡略化のために省略されていることが理解されるべきである。

提案される認可方法を適用することを可能にするために、プレゼンスシステムのＰＳ３００は、それに応じて適合されていて、一方で、ＰＳ ＸＤＭＳ３０１は、機能的に、従来の手順に従って構成されていても良い。提案される機能ユニットの命名についても同様であり、記載される包括的な機能は、提案される認可メカニズムの理解を簡単にすることを主要な目的として命名している。

図４は、ＰＳ３００とＰＳ ＸＤＭＳ機能３０１を有するプレゼンスシステム４００の簡略化ブロック図であり、これは、上述の任意の実施形態に従う方法を実行するように構成されている。本発明は、図４に示されるプレゼンスシステムに限定されないことが理解されるべきである。むしろ、プレゼンスシステムは、提案される方法のステップ群を実行することができるように、構成されかつ相互に接続されている他の機能エンティティ群を備えていても良い。図４の破線で示されるようにＰＳ ＸＤＭＳ機能３０１は、ＰＳ３００の一部として、あるいはＰＳ３００と相互に接続されている別のエンティティとして構成されていても良い。ＰＳとＰＳ ＸＤＭＳとの間の情報を交換し、それに関係して、プレゼンス関連サービスを認可して実行するための手順は、従来から広く知られており、プレゼンスシステムで通常に実行することができるステップ群の内、提案される認可メカニズムの理解に対して必要のないステップは簡略化のために省略している。加えて、プレゼンスサーバは、通常、いくつかの追加の機能ユニットを備えているが、提案される認可メカニズムの理解に対して必要なユニットだけを記載していて、他の取り得るユニット群は簡略化のために省略している。

図４のＰＳ３００は通信ユニット４０１を備え、これは、従来の手順に従って、ウォッチャー（Ｗ）からプレゼンティ（Ｐ）のプレゼンス情報に対するリクエストを受信するように構成されている。通信ユニット４０１に接続される認可ユニット４０２は、通信ユニット４０１を介してＰＳ ＸＤＭＳ３０１から適用可能な認可手順４０３ａにおける命令群を取得して、その取得した命令群をＰＳ３００のメモリ４０５に記憶するように構成することができる。これは、例えば、その命令群が、プレゼンティティに関連付けられているプレゼンスルールの一部として構成されている場合である。選択的には、これらの命令群は、最初に、メモリ４０５に記憶されていても良い。命令群の取得に関連して、ＰＳ３００は、適用可能な認可ルールへアクセスすることができるようになる。周知のプレゼンスアプリケーションに従って、認可ルールは記憶され、ＰＳ ＸＤＭＳからアクセス可能になる。提案されるソリューションに従えば、ＰＳ３００は、提案される任意の通知を介して関連する認可ルールを関知することになり、更新される認可ルールは、メモリ４０５に記憶され、そして、そのメモリ４０５から認可ユニット４０２によってアクセス可能になる。認可ユニット４０２は、典型的には、ＰＳ ＸＤＭＳ３０１からアクセス権を取得するようにも構成することができ、これは、認可ルール３０４ｂのような、プレゼンティティ（Ｐ）の認可ルールを更新する権限が与えられている認可インスタンス４０７を示している。

認可ユニット４０２は、ウォッチャー情報／ＸＣＡＰの変更の購読に対するリクエストを受信することに関連して、プレゼンティティのアクセス権４０４を取得するように構成することができ、これにより、購読リクエストを受け付けるか拒否するかを判定する。命令４０３ａとアクセス権４０４は、別の文書として、あるいは１つの文書として提供されても良い。どのような環境でも、プレゼンティティ（Ｐ）に適用可能な命令４０３ａは、ウォッチャーＷに対して特定されている認可ルールへのリンクに加えて、プレゼンティティに対して適用可能なアクセス権へのリンクを備えることができる。

認可装置４００も、通知ユニット４０５を備え、これは、通信ユニット４０１を介して認可インスタンス４０７へ送信するための、例えば、ウォッチャー情報ＳＩＰ ＮＯＴＩＦＹ（通知）のような通知を生成し、そして、認可ルールの変更を示す通知を認識するように構成されている。この認可ルールは、ＰＳ ＸＤＭＳ４０６から送信され、そして、通信ユニット４０１によって受信される。

取得した命令に基づいて、通知ユニット４０５によって受信され認識された任意の通知と組み合わせて、認可ユニット４０２は、認可ルール３０４ｂを検証することができるか否かを判定するように構成され、そうすることで、プレゼンス情報に対するリクエストの認可についての最終決定の通知を行うことができる、あるいは、更にまた別の認可インスタンスに最終決定を行う前に通知されるべきことを、認可ルールに対する命令が特定しているかを判定するように構成される。認可ルールは、別の文書として構成することができる、ここで、ルールの更新では、１つの文書を別の文書にオーバライド（上乗せ）することができ、これは、いずれも権限のレベルに依存する。

ＰＳ３００に接続されている、あるいはその一部として統合されている、ＰＳ ＸＤＭＳ３０１の機能ユニットの簡略図を、図５を参照して説明する。記載されるＰＳ ＸＤＭＳ３０１は、従来のＰＳ ＸＤＭＳを構築し、これは、この場合には、命令４０３ａ、認可命令４０３ｂ及びアクセス権４０４を、記憶装置５０２内のプレゼンスルールの一部としてあるいは１つ以上の個別の文書として記憶することができるようになる。通信ユニット５００は、ＰＳ ＸＤＭＳ３０１へのアクセスを、プレゼンティティとサードパーティ認可インスタンスに提供する一方で、通知ユニット５０１は、任意の承認済の購読に従って、これらのエンティティへのＸＣＡＰ変更の通知を生成するように構成されている。

加えて、ＰＳ３００には、タイマー機能４０６が提供されても良い。ＰＳあるいはＰＳ ＸＤＭＳによって通知される認可ユニットは、進行中の認可プロセスに関与しないことを選択することができ、認可ユニット４０２は、認可インスタンスの通知に関連してタイマー機能を開始するように構成されている。認可ルールの更新を示す通知が、タイマのタイムアウト前に認可ユニット４０２によって認識される場合、継続中の認可プロセスに対する更新が検討されることになる。一方、タイムアウト前に、そのような通知がＰＳ３００によって受信されない場合、認可ユニット４０２は、例えば、更なる認可インスタンスを通知することによって、あるいは、リクエストに対して適用可能な所定のデフォルトの命令に基づく最終認可決定を行うことによって、命令に従うプロセスを継続するように構成される。

購読リクエストの承認に対する手順と、ＰＳ ＸＤＭＳから認可インスタンスを通知するための手順は一般に知られているので、これらの手順は、本明細書では更に詳細には説明しないことが理解されるべきである。

本発明は例示の実施形態を参照して説明されているが、この説明は、一般的には、本発明の概念を例示することを意図されているだけであり、本発明の範囲を制限するものとして解釈されるべきではなく、本発明の範囲は添付の請求項に定義されるものである。

略語表
３ＧＰＰ 第３世代パートナシッププロジェクト
ＩＥＴＦ インターネットエンジニアリングタスクフォース
ＩＥＴＦ ＳＩＭＰＬＥ インターネットエンジニアリングタスクフォースＳＩＰインスタントメッセージング及びプレゼンス活用拡張
ＯＭＡ オープンモバイルアライアンス
ＰＳ プレゼンスサーバ
ＰＳ ＸＤＭＳ プレゼンスサーバＸＭＬ文書管理サーバ
ＲＣＳ リッチ通信スイート
ＳＩＰ セッション開始プロトコル
Ｗｉｎｆｏ ウォッチャー情報
ＸＣＡＰ 拡張マークアップ言語コンフィグレーションアクセスプロトコル
ＸＭＰＰ 拡張メッセージング及びプレゼンスプロトコル
ＸＭＬ 拡張マークアップ言語

Claims (24)

1. プレゼンティティ（Ｐ）に関連付けられているプレゼンス情報へのアクセスをウォッチャー（Ｗ）へ認可するためのプレゼンスシステムにおける方法であって、
   ａ）前記プレゼンス情報に対するリクエストを、前記ウォッチャー（Ｗ）から受信するステップと、
   ｂ）前記プレゼンティティ（Ｐ）以外の認可インスタンス（Ｃ）に、前記プレゼンス情報に対するリクエストに関連付けられている認可ルールを変更するあるいは検証するための機会が与えられるべきことを示す命令を取得するステップと、
   ｃ）前記認可インスタンス（Ｃ）に、前記プレゼンス情報に対するリクエストを通知することによって、前記認可インスタンス（Ｃ）に、前記認可ルールを変更するあるいは検証することを可能にするステップと、
   ｄ）前記認可ルールの変更あるいは検証を示す通知が前記認可インスタンスから受信される場合には、前記命令と該通知に基づいて該認可ルールの最終決定を行い、前記通知が受信されない場合には、前記命令のデフォルトの認可ルールに基づいて、該認可ルールの最終決定を行うステップとを有し、
   前記ｃ）ステップで送信される前記通知は、ウォッチャー（Ｗ）が前記プレゼンティティ（Ｐ）に関連付けられているプレゼンス情報をリクエストしていることを示す指示と、どんな種類のプレゼンス情報をウォッチャー（Ｗ）がリクエストしているかについての情報を含んでいる
   ことを特徴とする方法。
2. 前記ｄ）ステップを実行する前に、前記命令に従って、前記プレゼンティティ（Ｐ）以外の少なくとも１つの更なる認可インスタンス（Ｄ、Ｅ）に対して前記ｃ）ステップを繰り返すステップを更に有する
   ことを特徴とする請求項１に記載の方法。
3. 複数の前記認可インスタンス（Ｃ、Ｄ、Ｅ）の順序が、前記命令に含まれる権限リストに基づいて判定され、そうすることで、最高権限が与えられている前記認可インスタンス（Ｃ、Ｄ、Ｅ）に最初に通知される
   ことを特徴とする請求項２に記載の方法。
4. 前記ｃ）ステップにおいて、認可インスタンス（Ｃ、Ｄ、Ｅ、Ｐ）の通知に応じてタイマーを開始するステップと、
   前記タイマーのタイムアウトの前に、あるいは前記タイマーのタイムアウト時に、前記認可インスタンス（Ｃ、Ｄ、Ｅ、Ｐ）の通知に応じて、設定された、変更されたあるいは検証された認可ルールの通知が受信される場合、別の認可インスタンス（Ｄ、Ｅ、Ｐ）に対して前記ｃ）ステップを繰り返すステップと
   を更に有することを特徴とする請求項３に記載の方法。
5. 前記繰り返すステップは、前記最高権限を有する前記認可インスタンス（Ｃ、Ｄ、Ｅ、Ｐ）が通知に応答するまで、あるいは該認可インスタンスに関連付けられている前記タイマーがタイムアウトするまで、繰り返される
   ことを特徴とする請求項４に記載の方法。
6. 認可インスタンスを示すプレゼンティティ（Ｐ）以外の認可インスタンスに対する前記ｃ）ステップを実行する前に、前記プレゼンティティ（Ｐ）に対して、最初に、該ｃ）ステップが実行される
   ことを特徴とする請求項２乃至５のいずれか１項に記載の方法。
7. 認可インスタンスを示すプレゼンティティ（Ｐ）に対する前記ｃ）ステップを実行する前に、前記認可インスタンス（Ｃ）以外の前記認可インスタンス（Ｄ、Ｅ）に対して、最初に、該ｃ）ステップが実行される
   ことを特徴とする請求項２乃至５のいずれか１項に記載の方法。
8. 前記認可ルールは、前記プレゼンスシステムのプレゼンスルールで定義される前記命令に従って更新される
   ことを特徴とする請求項１乃至７のいずれか１項に記載の方法。
9. 前記ウォッチャー（Ｗ）のアイデンティティと前記プレゼンティティ（Ｐ）のアイデンティティは、Ｔｏヘッダ、Ｆｒｏｍヘッダ、あるいは、前記ｃ）ステップで送信される前記通知の通知本体のいずれか１つに含まれる
   ことを特徴とする請求項１乃至８のいずれか１項に記載の方法。
10. 前記ウォッチャー（Ｗ）のアイデンティティと前記プレゼンティティ（Ｐ）のアイデンティティは、前記ｃ）ステップで送信される前記通知の新規のアイデンティティヘッダに含まれる
    ことを特徴とする請求項１乃至９のいずれか１項に記載の方法。
11. 前記認可インスタンス（Ｃ、Ｄ、Ｅ、Ｐ）から、前記認可ルールの更新あるいはウォッチャー情報を購読するためのリクエストを受信するステップと、
    前記購読するためのリクエストを送信する認可インスタンス（Ｃ、Ｄ、Ｅ、Ｐ）が、前記認可ルールを設定、変更あるいは検証するために認可されるかどうかを判定するステップと、
    前記認可ルールを設定、変更あるいは検証するために認可される認可インスタンス（Ｃ、Ｄ、Ｅ、Ｐ）を、前記ｃ）ステップで通知するステップと
    を更に有することを特徴とする請求項４または５に記載の方法。
12. 前記判定するステップは、前記プレゼンティティ（Ｐ）のアクセスルールに基づいて判定される
    ことを特徴とする請求項１１に記載の方法。
13. 前記認可インスタンス（Ｃ、Ｄ、Ｅ、Ｐ）が、ウォッチャー情報の購読をリクエストしている場合に、前記ｃ）ステップの通知は、ウォッチャー情報通知メッセージとして提供される
    ことを特徴とする請求項１１または１２に記載の方法。
14. 前記認可インスタンス（Ｃ、Ｄ、Ｅ、Ｐ）が前記認可ルールの更新の購読をリクエストしている場合に、前記ｃ）ステップの通知は、ＸＣＡＰ変更通知メッセージとして提供される
    ことを特徴とする請求項１１または１２に記載の方法。
15. プレゼンティティ（Ｐ）に関連付けられているプレゼンス情報へのアクセスをウォッチャー（Ｗ）へ認可するためのプレゼンスシステムであって、
    前記プレゼンス情報に対するリクエストを、前記ウォッチャー（Ｗ）から受信するための通信ユニットと、
    前記プレゼンティティ（Ｐ）以外の認可インスタンス（Ｃ）に、前記プレゼンス情報に対するリクエストに関連付けられている認可ルールを、設定する、変更するあるいは検証するための機会が与えられるべきことを示す命令を取得するための認可ユニットと、
    前記認可インスタンス（Ｃ）に、前記プレゼンス情報に対するリクエストを通知することによって、前記認可インスタンス（Ｃ）に、前記認可ルールを、設定する、変更するあるいは検証することを可能にする通知ユニットとを有し、
    前記認可ユニットは、前記認可ルールの設定、変更あるいは検証を示す通知が前記認可インスタンス（Ｃ）から受信される場合には、前記命令と該通知に基づいて、該認可ルールの最終決定を行い、前記通知が受信されない場合には、前記命令のデフォルトの認可ルールに基づいて、該認可ルールの最終決定を行うように構成されていて、
    前記通知ユニットは、ウォッチャー（Ｗ）が前記プレゼンティティ（Ｐ）に関連付けられているプレゼンス情報をリクエストしていることを示す指示と、どんな種類のプレゼンス情報をウォッチャー（Ｗ）がリクエストしているかについての情報とを、認可インスタンス（Ｃ、Ｄ、Ｅ、Ｐ）に送信されるべき通知へ追加するように構成されている
    ことを特徴とするプレゼンスシステム。
16. 前記認可ユニットによって前記最終決定が行われる前に、前記命令に従って、前記プレゼンティティ（Ｐ）以外の少なくとも１つの更なる認可インスタンス（Ｄ、Ｅ）に対して、認可インスタンスの前記通知が繰り返されるように、前記認可ユニットは、前記通知ユニットを制御するように構成されている
    ことを特徴とする請求項１５に記載のプレゼンスシステム。
17. タイマーユニットを更に備え、
    前記認可ユニットは、前記認可インスタンス（Ｃ、Ｄ、Ｅ、Ｐ）を通知することを前記通知ユニットへ指示する時にタイマーを開始し、該指示に従って、最終決定を行うように、あるいは、前記タイマーのタイムアウト前にあるいはタイムアウト時に、変更されたあるいは検証された認可ルールが前記認可インスタンス（Ｃ、Ｄ、Ｅ）の前記通知に応じて、前記通信ユニットによって受信される場合に、別の認可インスタンスを通知することを前記通知ユニットへ指示し、別の関連付けられているタイマーを開始するように、構成されている
    ことを特徴とする請求項１５または１６に記載のプレゼンスシステム。
18. 前記認可ユニットは、最高権限を有する前記認可インスタンス（Ｃ、Ｄ、Ｅ）が通知に応答するまで、あるいは該認可インスタンスに関連付けられている前記タイマーがタイムアウトするまで、認可インスタンス（Ｃ、Ｄ、Ｅ）の前記通知を繰り返すように構成されている
    ことを特徴とする請求項１７に記載のプレゼンスシステム。
19. 前記認可ユニットは、認可インスタンスを示すプレゼンティティ（Ｐ）以外の認可インスタンス（Ｃ、Ｄ、Ｅ）が通知される前に、前記プレゼンティティ（Ｐ）を通知することを前記通知ユニットへ指示するように構成されている
    ことを特徴とする請求項１５乃至１８のいずれか１項に記載のプレゼンスシステム。
20. 前記認可ユニットは、認可インスタンスを示すプレゼンティティ（Ｐ）を通知する前に、前記プレゼンティティ（Ｐ）以外の認可インスタンス（Ｃ、Ｄ、Ｅ）を通知することを前記通知ユニットに指示するように構成されている
    ことを特徴とする請求項１５乃至１８のいずれか１項に記載のプレゼンスシステム。
21. 前記認可ユニットは、前記プレゼンスシステムのプレゼンスルールで定義される前記命令に従って前記認可ルールを更新するように構成されている
    ことを特徴とする請求項１５乃至２０のいずれか１項に記載のプレゼンスシステム。
22. 前記通知ユニットは、前記ウォッチャー（Ｗ）のアイデンティティと前記プレゼンティティ（Ｐ）のアイデンティティとを、前記認可インスタンス（Ｃ、Ｄ、Ｅ、Ｐ）に送信されるべき通知へ追加するように構成されていて、
    前記ウォッチャー（Ｗ）のアイデンティティと前記プレゼンティティ（Ｐ）のアイデンティティは、Ｔｏヘッダ、Ｆｒｏｍヘッダ、あるいは前記通知の通知本体のいずれか１つに含まれる
    ことを特徴とする請求項１５乃至２１のいずれか１項に記載のプレゼンスシステム。
23. 前記通知ユニットは、前記ウォッチャー（Ｗ）のアイデンティティと前記プレゼンティティ（Ｐ）のアイデンティティとを、認可インスタンスへの前記通知へ追加するように構成されていて、
    前記ウォッチャー（Ｗ）のアイデンティティと前記プレゼンティティ（Ｐ）のアイデンティティは、前記通知の新規の識別ヘッダに含まれる
    ことを特徴とする請求項１５乃至２１のいずれか１項に記載のプレゼンスシステム。
24. 前記認可ユニットは、更に、
    前記認可インスタンス（Ｃ、Ｄ、Ｅ、Ｐ）から、前記認可ルールの更新あるいはウォッチャー情報を購読するためのリクエストを受信し、
    前記購読するためのリクエストを送信する認可インスタンス（Ｃ、Ｄ、Ｅ、Ｐ）が、前記認可ルールを変更すること及び検証することの少なくとも一方を行うことが認可されるかどうかを判定し、
    前記認可ルールを変更すること及び検証することの少なくとも一方を行うことが認可されることが判定される場合に、前記認可インスタンス（Ｃ、Ｄ、Ｅ、Ｐ）を通知することを前記通知ユニットに指示する
    ように構成されている
    ことを特徴とする請求項１５乃至２３のいずれか１項に記載のプレゼンスシステム。

Images