(57)【特許請求の範囲】
【請求項１】
通信ネットワークにおいてグループ管理を実行する方法であって、
ネットワークノードにおいて、複数のグループメンバーを含むグループを監視する要求であって、監視すべき少なくとも１つの基準を含む前記要求を要求ノードから受信するステップと、
どのグループメンバーが前記基準を満たすかを判定するステップと、
前記基準を満たす少なくとも１人のグループメンバーの識別子を含む通知メッセージであって、当該満たされる基準の識別子を含む更なる基準満足情報を含む前記通知メッセージを前記要求ノードへ送信するステップと、
を備えることを特徴とする方法。
【請求項２】
前記要求ノードからの前記要求は、セッション開始プロトコル  ＳＵＢＳＣＲＩＢＥメッセージの中で送信され、前記通知メッセージは、セッション開始プロトコル  ＮＯＴＩＦＹメッセージの中で送信される
ことを特徴とする請求項１に記載の方法。
【請求項３】
前記通知メッセージは、セッション開始プロトコル  ＮＯＴＩＦＹメッセージのボディの中の拡張マークアップ言語エレメントの中に、更なる基準満足情報を含む
ことを特徴とする請求項１又は２に記載の方法。
【請求項４】
前記通知メッセージは、セッションが確立される前に送信され、前記基準を満たす全てのグループメンバーの識別子を含む
ことを特徴とする請求項１、２、又は３に記載の方法。
【請求項５】
前記通知メッセージは、グループメンバーの状態が変化した場合に送信され、当該グループメンバーの識別子を含む
ことを特徴とする請求項１、２、又は３に記載の方法。
【請求項６】
前記更なる基準満足情報は、下記の任意のものから選択される情報を含む
ことを特徴とする請求項１乃至５のいずれか１項に記載の方法。
・グループメンバーの状態の変化を判定するために使用される位置情報
・グループメンバーの状態の変化を判定するために使用されるプレゼンス情報
・前記基準を満たす、前記グループの中のグループメンバーの数
・グループメンバーの状態の変化の理由
・グループメンバーの状態の変化が発生した時に関するタイムスタンプ
・動的情報又は静的情報を使用してグループメンバーが発見されたか否か
【請求項７】
通信ネットワークにおいて使用される要求ノードであって、
複数のグループメンバーを含むグループの監視を要求する要求メッセージであって、監視すべき少なくとも１つの基準を含む前記要求メッセージを生成するプロセッサと、
前記要求メッセージをネットワークノードへ送信する送信機と、
前記基準を満たす少なくとも１人のグループメンバーの識別子を含む通知メッセージであって、当該満たされる基準の識別子を含む更なる基準満足情報を含む前記通知メッセージを受信する受信機と、
を備えることを特徴とする要求ノード。
【請求項８】
前記プロセッサは、セッション開始プロトコル  ＳＵＢＳＣＲＩＢＥ要求メッセージを生成するように構成され、前記通知メッセージは、セッション開始プロトコル  ＮＯＴＩＦメッセージとして受信される
ことを特徴とする請求項７に記載の要求ノード。
【請求項９】
通信ネットワークにおいて使用されるネットワークノードであって、
複数のグループメンバーを含むグループを監視する要求であって、監視すべき少なくとも１つの基準を含む前記要求を要求ノードから受信する受信機と、
どのグループメンバーが前記基準を満たすかを判定するプロセッサと、
前記基準を満たす少なくとも１人のグループメンバーの識別子を含む通知メッセージであって、更なる基準満足情報を含む前記通知メッセージを前記要求ノードへ送信する送信機と、
を備えることを特徴とするネットワークノード。
【請求項１０】
前記送信機は、セッションが確立される前に前記通知メッセージを送信するように構成され、前記通知メッセージは、前記基準を満たす全てのグループメンバーの識別子を含む
ことを特徴とする請求項９に記載のネットワークノード。
【請求項１１】
前記プロセッサは、グループメンバーの状態が変化した場合に前記通知メッセージの前記送信を開始するように構成され、前記通知メッセージは、当該グループメンバーの識別子を含む
ことを特徴とする請求項９又は１０に記載のネットワークノード。
【請求項１２】
前記更なる基準満足情報は、下記の任意のものから選択される情報を含む
ことを特徴とする請求項９、１０、又は１１に記載のネットワークノード。
・前記基準を満たす、前記グループの中のグループメンバーの数
・グループメンバーの状態の変化の理由
・グループメンバーの状態の変化が発生した時に関するタイムスタンプ
・動的情報又は静的情報を使用してグループメンバーが発見されたか否か
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信ネットワークにおけるグループ管理の分野に関する。
【背景技術】
【０００２】
通信ネットワークにおいて、グループとは、ユーザ又はデバイスのグループ化を意味する。ユーザグループの例を挙げると、１人のユーザは、グループに所属しない場合もあるし、単数又は複数のグループに所属する場合もある。グループは、グループの個々のメンバーに対してアクセス又はサービスを提供することを単純化するために使用される。例えば、企業が２０人の従業員を持ち、また、共有ネットワーク内に２つのディレクトリ構造を持つ場合を考える。５人のユーザは、両方のディレクトリにアクセスすることを許可されており、他の１５人のユーザは、１つのディレクトリにアクセスすることを許可されているだけである。グループが無いと、管理者は、各個人ユーザのためにパーミッションを設定しなければならないであろう。しかしながら、ユーザをグループ化して各グループに対してパーミッションを許可することにより、パーミッションを許可することができる。この極めて単純な例は、ユーザをグループ化することがサービス及びネットワークに対するアクセスを許可するためのいかに効率的な方法であるかを示している。
【０００３】
多くのグループは静的であり、何らかの基準に基づいてグループメンバーを個々に選択することにより定義される。しかしながら、動的なグループも使用可能である。例えば、動的なグループは、特定の時に特定のネットワークにログオンしているユーザを含むかもしれない。ネットワークにログオンしていることがグループのメンバーシップに関する基準であり、それゆえ、グループは明らかに、任意の一時点においてグループのどのメンバーがログオンしているかに依存して、変化するであろう。
【０００４】
Open Mobile Alliance (www.openmobilealliance.org)は、動的なグループ管理のためのアーキテクチャ上のソリューションに取り組んでいる。アーキテクチャの一部として、何らかの条件又は基準に基づいてＵＲＩ(Uniform Resource Identifier)の選択を実行する、論理ノードが特定される。このＵＲＩは、グループメンバーを特定する。選択機能は、基準（適合条件）に基づいてグループメンバーの選択を行い、続いて、基準を満たすグループメンバーの集合を要求ノードに対して提供するように意図されている。
【０００５】
選択機能は、選択を行うために様々な情報源にアクセスすることができる。情報には、データベース（例えば、XML Document Management、アドレス帳、及びユーザプロファイル）から入手可能な静的な情報（頻繁には変化しない情報）が含まれてもよい。また、情報には、より頻繁に変化する動的な情報も含まれてもよい。動的な情報の例には、プレゼンスサーバ又は位置サーバからの情報が含まれる。
【０００６】
基準／条件に基づくＵＲＩの選択は、（例えば、セッションが開始すると１回だけ実行される）１回限りの操作(one-time operation)としても実行可能であるし、（例えば、セッション実行中の）ユーザ情報の継続的な監視としても実行可能である。
【０００７】
基準／条件ベースのＵＲＩの選択機能は、多くのサービス（例えば、プッシュ・トゥ・トーク・オーバー・セルラ（ＰｏＣ）サービス又はインスタントメッセージング（ＩＭ）サービス）によって活用可能である。任意のセッションベースのグループ通信が、グループメンバーの管理（例えば、セッションのセットアップ時にグループメンバーを選択すること、アクティブなセッションに対して個々のメンバーを追加又は削除すること、選択された個々のメンバーに対してメッセージを送信することなど、選択結果に基づくもの全て）のためにこの機能を活用可能である。
【０００８】
ＯＭＡによって規定される基準／条件ベースのＵＲＩの選択機能は、選択が行われる度に、基準／条件を満たすグループメンバーのＵＲＩのリストを提供する。この情報は、多くの場合、エンドユーザ又はサービスイネーブラにとって、グループに所属する決定を行うには不十分である。例えば、「なぜＭａｒｙがリストに入っていてＪｏｈｎがリストに入っていないのか」といった情報や、そのような状況においてどのような行動（アクション）を実行すべきかという提案は、提供されない。
【０００９】
更に、（静的なものであれ動的なものであれ）ソースの情報が変化する場合、変化が発生する度に要求ノードに対して新しいＵＲＩリストを送信することは非効率である。要求ノードにとってもっと有用なことは、どのグループメンバーが追加又は削除されたか、これらのアクションがいつ発生したか、そのアクションがどうして発生したか、そして、この変化に応えてどのようなアクションを取るべきかを知ることであろう。セッション中に変化し得る種類の情報の例には、プロファイル又はプリファレンスの変化、グループメンバーに関する事前定義されたリストに対する変更、動的なプレゼンス情報の変化、などが含まれる。
【発明の概要】
【００１０】
発明者達は、先行技術のグループ管理の通知メカニズムに関する制限に気づき、新しい方法及び装置を考案した。
【００１１】
本発明の第１の態様によれば、通信ネットワークにおいてグループ管理を実行する方法が提供される。ネットワークノードは、複数のグループメンバーを含むグループを監視する要求を要求ノードから受信する。前記要求は、監視すべき少なくとも１つの基準も含む。前記ネットワークノードは、どのグループメンバーが前記基準を満たすかを判定し、前記基準を満たす少なくとも１人のグループメンバーの識別子を含む通知メッセージを前記要求ノードへ送信する。前記通知メッセージは、当該満たされる基準の識別子を含む更なる基準満足情報も含む。
【００１２】
オプションとして、前記要求は、セッション開始プロトコル  ＳＵＢＳＣＲＩＢＥメッセージの中で送信され、前記通知メッセージは、セッション開始プロトコル  ＮＯＴＩＦＹメッセージの中で送信される。
【００１３】
前記通知メッセージは、オプションとして、セッション開始プロトコル  ＮＯＴＩＦＹメッセージのボディの中の拡張マークアップ言語エレメントの中に、更なる基準満足情報を含む。
【００１４】
前記通知メッセージは、オプションとして、セッションが確立される前に送信され、前記基準を満たす全てのグループメンバーの識別子を含む。これにより、前記要求ノードに対して、セッション開始時に前記基準を満たすグループメンバーのリストが提供される。或いは、前記通知メッセージは、セッションが確立された後にグループメンバーの状態が変化した場合に送信される。当該通知メッセージは、当該グループメンバーの識別子を含む。これにより、全てのグループメンバーの状態を報告する必要なしに、前記要求ノードに対して変化を動的に報告することができる。
【００１５】
前記更なる基準満足情報のオプションとしての例には、下記の任意のものから選択される情報が含まれる。
・前記基準を満たす、前記グループの中のグループメンバーの数
・グループメンバーの状態の変化を判定するために使用される位置情報
・グループメンバーの状態の変化を判定するために使用されるプレゼンス情報
・グループメンバーの状態の変化の理由
・グループメンバーの状態の変化が発生した時に関するタイムスタンプ
・動的情報又は静的情報を使用してグループメンバーが発見されたか否か
【００１６】
本発明の第２の態様によれば、通信ネットワークにおいて使用される要求ノードが提供される。複数のグループメンバーを含むグループの監視を要求する要求メッセージを生成するプロセッサが提供される。前記要求メッセージは、監視すべき少なくとも１つの基準を含む。送信機は、前記要求メッセージをネットワークノードへ送信するように構成され、受信機は、通知メッセージを受信するように構成される。前記通知メッセージは、前記基準を満たす少なくとも１人のグループメンバーの識別子を含み、更に、当該満たされる基準の識別子を含む更なる基準満足情報も含む。
【００１７】
前記プロセッサは、オプションとして、セッション開始プロトコル  ＳＵＢＳＣＲＩＢＥ要求メッセージを生成するように構成され、前記通知メッセージは、オプションとして、セッション開始プロトコル  ＮＯＴＩＦメッセージとして受信される。
【００１８】
第３の態様によれば、通信ネットワークにおいて使用されるネットワークノードが提供される。複数のグループメンバーを含むグループを監視する要求であって、監視すべき少なくとも１つの基準を含む前記要求を要求ノードから受信する受信機が提供される。プロセッサは、どのグループメンバーが前記基準を満たすかを判定するために使用される。送信機は、前記基準を満たす少なくとも１人のグループメンバーの識別子を含む通知メッセージを前記要求ノードへ送信するように構成される。前記通知メッセージは、更なる基準満足情報を含む。
【００１９】
前記送信機は、オプションとして、セッションが確立される前に前記通知メッセージを送信するように構成され、前記通知メッセージは、前記基準を満たす全てのグループメンバーの識別子を含む。或いは、前記プロセッサは、グループメンバーの状態が変化した場合に前記通知メッセージの前記送信を開始するように構成され、前記通知メッセージは、当該グループメンバーの識別子を含む。前記更なる基準満足情報のオプションとしての例には、下記の任意のものから選択される情報が含まれる。
・前記基準を満たす、前記グループの中のグループメンバーの数
・グループメンバーの状態の変化の理由
・グループメンバーの状態の変化が発生した時に関するタイムスタンプ
・動的情報又は静的情報を使用してグループメンバーが発見されたか否か
【図面の簡単な説明】
【００２０】
【図１】本発明の実施形態を示すシグナリング図である。
【図２】本発明の実施形態に従うサービスイネーブラノードをブロック図で概略的に示す。
【図３】本発明の実施形態に従う動的グループイネーブラノードをブロック図で概略的に示す。
【発明を実施するための形態】
【００２１】
要求ノードがグループメンバーの状態に対する更新を要求すると、基準満足に関する情報が、要求側ノードへ送信される通知の中で送信される。要求される場合、基準／条件ベースのＵＲＩ選択機能を実行する論理ノードは、例えば以下のようなエレメントを含むことができる。
・基準／条件を満たすグループメンバーの全体数
・静的な情報（例えば、リスト内で事前定義されたメンバー、データベース（アドレス帳、プロファイル）からの検索結果、及び、静的な情報に対するあらゆる変更の理由及び時刻）を用いて発見されたグループメンバー
・動的な基準／条件を満たすグループメンバーの状態、どの（単数又は複数の）条件が満たされたかに関する詳細（グループメンバーは幾つかの条件を満たす場合がある）、及び、静的な情報に対するあらゆる変更の理由及び時刻
【００２２】
要求ノードに対して基準満足の更新を提供するために、RFC 4575, "A SIP Event Package for Conference State"において説明されるようなＳＩＰイベントパッケージを拡張することができる。ＳＩＰイベントパッケージは、例えば、カンファレンス通知サービスによって使用可能である。カンファレンス通知サービスのためのＳＩＰイベントパッケージは、主に、購読者(subscribers)のセットに対してカンファレンス参加者の状態を通知するために使用されている。なお、本発明の適用分野が直接的にはカンファレンスサービスに関連していない場合であってさえも、購読者に対して他のエンティティの状態を定義された基準セット（例えば、地理的位置、プレゼンス状態、又はユーザやエンティティに関連する他の情報）に基づいて通知するためにこのイベントパッケージを使用することができる。カンファレンスのシナリオはそれゆえ、以下の説明において例として使用されるが、理解されるであろうこととして、本発明は、エンティティの状態が評価される任意のシナリオに対して同様に適用される。基準／条件ベースの選択機能は、カンファレンスを確立したり、どのユーザが所与の基準を満たすかに関する情報を取得したりする前に、使用可能である。
【００２３】
本発明の実施形態では、評価すべき基準は、RFC 4745, "Common Policy: A Document Format for Expressing Privacy Preferences"に記述されたポリシーの拡張を使用して説明される。共通ポリシー(common policy)は、条件セット、アクションセット、及び、１つのオプションではトランスフォーメーションセット(a set of transformations)、から構成されるルールセットを定義する。条件は、アクション及び／又はトランスフォーメーションが誰に対して適用されるかを指定する。このルールセットは、最初のＳＩＰ  ＳＵＢＳＣＲＩＢＥ要求メッセージのボディの中で送信される。
【００２４】
ＵＲＩ選択機能は、使用される評価基準に依存して、カンファレンス状態のためのＳＩＰイベントパッケージの拡張を使用して更新の通知を送信する。更新は、ＳＩＰ  ＮＯＴＩＦＹ要求のボディの中で送信される。様々なＸＭＬエレメント及び属性に関するマッピング及び使用法を以下に示す。
【００２５】
●<conference-info>: 要求される評価サービスに関する様々な情報を含む。
○entity: この属性は、グループＵＲＩ、リストＵＲＩ，又はアドホックの一意のＵＲＩを含む。これは、動的な基準に関する情報を取得するために要求エンティティが購読しなければならないＳＩＰ  ＵＲＩである。
○state: 通知が、カンファレンスに参加している全エンティティに関する情報を含む("full")か否か、最後の通知が発行されてから変化した情報を含む("partial")だけであるか、或いは購読が存在を中止したり目標のエンティティグループが削除されたりしたか("deleted")を示す。
●<conference-description>: サービスグループ又はリソースリストに関する情報を与える（そのようなグループが事前定義されている場合に）。
○<display-text>: サービスグループ又はリソースリストの表示テキストである。
○<subject>, <free-text>. <keywords> これらの中には、RFC4575に記述される情報がサービスグループ又はリソースリストから抽出可能である場合に、その情報を入れることができる。
○<conf-uris>: 評価されるセッションを特定するＵＲＩのセットを含む。
○<service-uris>: 評価サービスにコンタクトするために使用可能なＵＲＩのセットを含む（即ち、アドホックの評価サービスをそこへ対して発行可能なＳＩＰ  ＵＲＩ）。
○<maximum-user-count>: サービスがセッションごとに処理可能なユーザの最大数を既定する。この数を超過した場合、サービスがどのユーザに与えられるかを決定するために、サービスはローカルポリシーを適用することになる。
○<available-media>: これは使用されない。
●<host-info>: RFC4575におけるのと同じ方法で使用される。
●<conference-state>: 評価セッションの状態を記述する。
○<user-count>: ユーザが何らかの基準を満たすか否かとは無関係に、購読要求が受信された際に評価のために考慮されるユーザの数である。
○<active>: 評価セッションがアクティブか否かを示す。
●<users>/<user>: 対称グループの一部であるユーザを記述する。このユーザは、このユーザが何らかの基準を満たすか否かを判定するために監視される。
○entity: この属性は、評価セッションにおけるユーザのためのＵＲＩを含む。このＵＲＩは、対象グループ中の他の全ての参加者の中で一意でなければならない。
○state: この属性は、エレメントがユーザ全体の情報を含むということか("full")、以前の通知から変化した情報だけを含むということか("partial")、又はユーザが評価に関してもはや考慮されないということを示す。
○<display-text>: このエレメントは、エンドユーザに対して表示すべきユーザフレンドリーなテキストを含む。これは、サービスグループ又はリソースリストから抽出可能である。
○<associated-aors>: このエレメントは、ユーザに関連付けられている追加のＵＲＩを含むことができる（即ち、ＴＥＬ  ＵＲＩやＥメールアドレス）。
●<user>/<endpoint>: このエレメントは、ユーザによって使用される複数のデバイスのうちの１つを規定する。通常、ユーザエレメントは１つだけエンドポイントエレメントを含むことになる。
○entity: これは、このエンドポイントに関連付けられたＵＲＩであり、ユーザコンテキストの中で一意でなければならない。ＳＩＰの用語では、これはコンタクトＵＲＩとなるであろう
○state: この属性は、エレメントがエンドポイント全体の情報を含むということか("full")、以前の通知から変化した情報だけを含むということか("partial")、又はエンドポイントが評価に関してもはや考慮されないということを示す。
○<display-text>: このエレメントは、エンドポイントのための表示テキストを含む。
○<status>: RFC4575と同様であるが、‘connected’、‘disconnected’、及び‘pending’だけが、ユーザが所与の基準のうち少なくとも１つを満たすか否かで使用される。
○<referred>、<joining-method>、<joining-info>、<disconnection-method>、<disconnection-info>、及び<media>のエレメントは、使用されない。
○<call-info> RFC4575に記述されるのと同じ方法で使用される。
●<sidebar-by-ref>及び<sidebar-by-val>は使用されない。
【００２６】
追加で、１つの新しいエレメントが、<endpoint>エレメントの下で定義される。
●<rule-info>: 通知が発行される時点でユーザがどの基準を満たすかに関する情報を含む。
【００２７】
例として、本発明を説明するために、図１は、本発明の実施形態を示すシグナリング図である。図１は、カンファレンス参加者の状態に関する情報を要求する要求ノードであるサービスイネーブラ１を示す。（図１においてＤｙｎ−Ｇイネーブラと示される）動的グループイネーブラ２は、基準を評価し、どのユーザが要求された基準を満たすか、及びどのユーザが要求された基準を満たすかに対する変化を、サービスイネーブラ１に対して通知する機能を実行する。プレゼンスサーバ３も提示されており、Ｄｙｎ−Ｇイネーブラ２はこれに対して購読を行う。共有ＸＤＭＳサーバ４は、Ｄｙｎ−Ｇイネーブラ２に対してリソースリストを提供するために使用され、検索プロキシノード５は、ＸＤＭ検索を実行するために使用される。検索プロキシノード５は、ＸＤＭ検索クエリを、ネットワーク中の、要求された情報を含むであろう特定のＸＤＭサーバへ転送し、受信した全ての応答を組み合わせる。するとＤｙｎ−Ｇイネーブラ２は、共有ＸＤＭサーバから取得したリソースリストからのＵＲＩを取得し、ＸＤＭ検索の結果からのＵＲＩを評価基準の対象として使用することができる。以下の番号付けは、図１に示す番号付けに対応する。
【００２８】
Ｓ１．  ＳＩＰ  ＳＵＢＳＣＲＩＢＥ要求が、サービスイネーブラ１から動的グループイネーブラ２へ送信される。このＳＵＢＳＣＲＩＢＥメッセージは、ＯＭＡ動的グループを購読するためのものである。グループは、sip:alice@example.comに関するエントリとＸＤＭ検索クエリとを伴うリストを含む。このＸＤＭ検索は、sip:bob@example.comを得る(resolve)。ＳＵＢＳＣＲＩＢＥメッセージの例は、以下の通りである。
【００２９】
0005486005.tif 000002
0005486005.tif 000003
0005486005.tif 000004
【００３０】
Ｓ２．  動的グループイネーブラ２が、ＳＩＰ  ２００  ＯＫ応答をサービスイネーブラ１へ送信する。ＳＩＰ  ２００  ＯＫメッセージの例は以下の通りである。
【００３１】
0005486005.tif 000005
【００３２】
Ｓ３．  リソースリストを変換(resolve)する。動的グループイネーブラ２は、共有ＸＤＭＳサーバ４からリソースリストを取得する。
【００３３】
Ｓ４．  動的グループイネーブラが<list-service>/<list>エレメントを分析する際に、<drl:xsearch>エントリを発見する。これは、ＸＤＭ検索が必要とされているということを示す。動的グループイネーブラは、プロキシ検索５を使用して、<drl:xsearch>エントリの中で提供されたクエリを用いて検索を実行する。検索は、単一のＵＲＩであるsip:bob@example.comを得る(resolve)。
【００３４】
Ｓ５．  ＳＩＰ  ＳＵＢＳＣＲＩＢＥ要求が、<list-service>/<list>エレメントの中のエントリによって提供された各対象ＵＲＩに関して、動的グループイネーブラ２からプレゼンスイネーブラ３へ送信される。この例では、sip:alice@example.comは静的に指定されており、sip:bob@example.comはＸＤＭ検索クエリの結果である。ＳＵＢＳＣＲＩＢＥ要求の例は、以下の通りである。
【００３５】
0005486005.tif 000006
【００３６】
Ｓ６．  ＳＩＰ  ２００  ＯＫ応答が、プレゼンスイネーブラ３から動的グループイネーブラ２へ送信される。ＳＩＰ  ２００  ＯＫの例は、以下の通りである。
【００３７】
0005486005.tif 000007
【００３８】
Ｓ７．  ＳＩＰ  ＮＯＴＩＦＹメッセージが、プレゼンスイネーブラ３から動的グループイネーブラ２へ送信される。ＮＯＴＩＦＹメッセージは、ユーザの状態に対する購読が行われたことを確認するものであり、基準に合致するグループメンバーの初期リストを含む。ＳＩＰ  ＮＯＴＩＦＹ要求の例は、以下の通りである。
【００３９】
0005486005.tif 000008
【００４０】
Ｓ８．  ＳＩＰ  ２００  ＯＫ応答が、動的グループイネーブラ２からプレゼンスイネーブラへ送信される。この例におけるＳＩＰ  ２００  ＯＫ応答の例は、以下の通りである。
【００４１】
0005486005.tif 000009
【００４２】
Ｓ９．  ＳＩＰ  ＮＯＴＩＦＹ要求が、動的グループイネーブラ２からサービスイネーブラ１へ送信される。ＳＩＰ  ＮＯＴＩＦＹ要求の例は、以下の通りである。
【００４３】
0005486005.tif 000010
0005486005.tif 000011
0005486005.tif 000012
【００４４】
Ｓ１０．  ＳＩＰ  ２００  ＯＫ応答が、サービスイネーブラ１から動的グループイネーブラ２へ送信される。ＳＩＰ  ２００  ＯＫ応答の例は、以下の通りである。
【００４５】
0005486005.tif 000013
【００４６】
Ｓ１１．  対象グループメンバーのプレゼンス状態が変化する（この場合、対象グループメンバーはプレゼンティティ<sip:ann@example.com>である）。
【００４７】
Ｓ１２．  状態の変化が、プレゼンスイネーブラ３から動的グループイネーブラ２へのＳＩＰ  ＮＯＴＩＦＹ要求の送信をトリガーする。ＳＩＰ  ＮＯＴＩＦＹ要求の例は、以下の通りである。
【００４８】
0005486005.tif 000014
【００４９】
Ｓ１３．  ＳＩＰ  ２００  ＯＫ応答が、動的グループイネーブラ２からプレゼンスイネーブラ３へ送信される。ＳＩＰ  ２００  ＯＫ応答の例は、以下の通りである。
【００５０】
0005486005.tif 000015
【００５１】
Ｓ１４．  サービスイネーブラに対して対象グループメンバーの状態の変化を通知するために、ＳＩＰ  ＮＯＴＩＦＹ要求が、動的グループイネーブラ２からサービスイネーブラ１へ送信される。ＳＩＰ  ＮＯＴＩＦＹ要求の例は、以下の通りである。
【００５２】
0005486005.tif 000016
0005486005.tif 000017
0005486005.tif 000018
0005486005.tif 000019
【００５３】
Ｓ１５．  ＳＩＰ  ２００  ＯＫ応答が、以下のように、サービスイネーブラ１から動的グループイネーブラ２へ送信される。
【００５４】
0005486005.tif 000020
【００５５】
ここで図２を参照すると、サービスイネーブラノード１には、ステップＳ１で説明したＳＩＰ  ＳＵＢＳＣＲＩＢＥメッセージを生成するプロセッサ６と、ＳＩＰ  ＳＵＢＳＣＲＩＢＥメッセージを動的グループイネーブラ２へ送信する送信機７と、上のＳ９又はＳ１４で説明したＳＩＰ  ＮＯＴＩＦＹメッセージを受信する受信機８と、が備えられる。
【００５６】
ここで図３を参照すると、動的グループイネーブラ２には、ステップＳ１で説明したＳＩＰ  ＳＵＢＳＣＲＩＢＥメッセージを受信する受信機９と、どのグループメンバーが基準を満たすかを判定するプロセッサ１０と、ステップＳ９及びＳ１４で説明したＳＩＰ  ＮＯＴＩＦＹメッセージをサービスイネーブラ１へ送信する送信機１１と、が備えられる。
【００５７】
本発明は、条件ベースのＵＲＩ選択機能の要求側にとって、意思決定(decision making)をより柔軟にする。要求側がエンドユーザ（人間）である場合、結果として得られる情報は、より豊かで、柔軟な意思決定により適している。要求側がサービスイネーブラ（自動装置）である場合、サービスの性質と追加の<rule-info>エレメントとの組み合わせに依存して、様々な意思決定モデルを使用することができる。本発明は、要求側での処理をより効率的にする。なぜなら、部分的通知メカニズムが、要求側に対して、対象グループメンバーの状態のどの側面が変化したかを通知するからである。通知の中で提供される豊かな情報は、セッション管理以外の他の目的にも使用可能である。一例は、統計レポートを生成することであろう。
【００５８】
ＯＭＡリストグループの拡張
以下は、ＸＤＭ検索及びＳＩＭＰＬＥプレゼンス検索のような動的エントリを伴う拡張されたリソースリストを提供する、ＯＭＡ共有グループスキーマ(schema)に対する拡張例である。
【００５９】
0005486005.tif 000021
0005486005.tif 000022
0005486005.tif 000023
【００６０】
共通ポリシーの拡張
以下は、プレゼンス及びgeo-priv位置ベース情報のための追加のＳＩＰイベントパッケージベースの動的条件を提供するために共通ポリシースキーマに対してなされる拡張例を説明する。<dynamic-condition>エレメントは、基準セットを定義し、以下のものを含むことができる。
【００６１】
●<xpath-condition>: 所与のイベントパッケージに対して発行される、購読に関して受信されたＮＯＴＩＦＹ要求のボディに対して適用されるであろうＸＰａｔｈ表現に基づく条件を記述する。この条件は、ＸＰａｔｈ表現が空のシーケンスを返さない場合に、満たされる。
●<location-condition>: 地理上の形状(shape)を記述する。位置ノードから取得された地理上の形状が条件によって提供されるものとオーバーラップする場合に、この条件は満たされる。
【００６２】
0005486005.tif 000024
0005486005.tif 000025
0005486005.tif 000026
【００６３】
カンファレンスパッケージの拡張
以下は、カンファレンスパッケージに対する拡張例を提供する。この拡張は、新しいエレメントである<rule-info>を提供する。<rule-info>は、どの動的ルールが各特定のユーザに合致したかに関する情報を含む。
【００６４】
0005486005.tif 000027
【００６５】
以下の省略形が使用されている。
【００６６】
ＩＭ  インスタントメッセージング
ＰＡＧ  プレゼンス及び利用可能性(Presence and Availability)ワーキンググループ
ＰｏＣ  プッシュ・トゥ・トーク・オーバー・セルラ
ＵＲＩ  ユニフォーム・リソース・アイデンティファイア
Ｄｙｎ−Ｇ  動的グループ
geo-priv  地理的位置／プライバシー(Geographic Location/Privcy)
ＸＰａｔｈ  ＸＭＬパス言語
ＳＩＭＰＬＥ  SIP for Instant Messaging and Presence Leveraging Extensions
【００６７】
当業者によって理解されるであろうこととして、添付の請求の範囲において規定される本発明の範囲から逸脱することなしに、上述の実施形態に対して様々な変更を加えることができる。
【図１】
0005486005.tif 000028
【図２】
0005486005.tif 000029
【図３】
0005486005.tif 000030