JP4420955B2

JP4420955B2 - プレゼンス通信システム及び方法

Info

Publication number: JP4420955B2
Application number: JP2007537514A
Authority: JP
Inventors: 潤前田; 新也山村; 正明高瀬
Original assignee: Fujitsu Ltd
Current assignee: Fujitsu Ltd
Priority date: 2005-09-29
Filing date: 2005-09-29
Publication date: 2010-02-24
Anticipated expiration: 2025-09-29
Also published as: WO2007037018A1; US8484337B2; US20080183866A1; JPWO2007037018A1

Description

本発明は、プレゼンス通信システムに関し、特に通信前の相手状態を確認するプレゼンス（Presence）を行って通信を行うプレゼンス通信システムに関する。

近年、通信可能な環境内で、ユーザがどこにいようとも通信を望む相手を発見し、エンドツーエンド間で論理コネクションを設定して通信を開始するユビキタスネットワークの開発が急速に進められている。

ユビキタスネットワークにおいては、通信相手が不在の可能性があることや、通信環境が必ずしも常時接続でないことから、相手が今現在通信可能な状態にあるのか否かを事前に知ることは、通信を促進する上で非常に有効である。

この機能は通信相手の存在を示す意味でプレゼンス機能として標準化されている。プレゼンスとは、通信相手の存在や状態を事前に通知・把握する機能であり、これにより通信相手の状況に応じた通信手段の選択や通信の開始を可能とするものである。

通信前の相手状態が確認できるプレゼンス技術は、ＩＥＴＦ（Internet Engineering Task Force）のＲＦＣ（Request For Comment）２７７８で規定されており、今後のユビキタスネットワークのキー技術になるものとして、現在注目されているものである。

図３６はプレゼンスサービスシステムの概要を示す図である。プレゼンスサービスシステム１００は主に、プレゼンスサーバ１１０、プレゼンティティ（Presentity）１２０、ウォッチャー（Watcher）１３０から構成され、プレゼンスサーバ１１０を介して、プレゼンス情報の要求、提供が行われる。なお、プレゼンティティ１２０は、プレゼンス情報を見せる側であり、ウォッチャー１３０は、プレゼンス情報を見る側となる（一般にプレゼンティティがユーザ、ウォッチャーがサービス事業者となる）。

基本的なプレゼンス情報の流れとして、まず、ウォッチャー１３０は、プレゼンス情報要求をプレゼンスサーバ１１０へ送信する。プレゼンスサーバ１１０は、プレゼンス情報要求をプレゼンティティ１２０に送信し、プレゼンティティ１２０はプレゼンス情報（例えば、現在通信可能か否かのユーザ状態）を返信する。

ウォッチャー１３０は、プレゼンスサーバ１１０を介して受信したプレゼンス情報からプレゼンティティ１２０の状態を認識し、サービス提供が可能な状態であれば、プレゼンティティ１２０に対して何らかのサービスを実行する。

プレゼンスサービスの従来技術としては、あるプレゼンティティのプレゼンス情報を、他のプレゼンティティのプレゼンス情報の変化をトリガにして自動的に更新する技術が提案されている（例えば、特許文献１）。
特開２００４−２２８８３３号公報（段落番号〔００２０〕〜〔００４６〕，第１図）

ＲＦＣ２７７８によるプレゼンスサービスでは、プレゼンティティ１２０は、自身の識別子であるＵＲＩ（Uniform Resource Identifiers）を用いてプレゼンスサーバ１１０にプレゼンス情報を提供し、ウォッチャー１３０は、プレゼンスサーバ１１０に対して、プレゼンティティ１２０のＵＲＩを指定してプレゼンス情報を取得する。これにより、ウォッチャー１３０は、プレゼンティティ１２０の状態を認識することができ、その後、プレゼンティティ１２０に対して何らかのサービスを実行する。しかし、このような従来の仕組みでは、システム規模が大きくなるにつれて、通知すべきメッセージの数が膨大になるといった問題があった。

図３７はＲＦＣ２７７８による従来のプレゼンスサービスの問題点を示す図である。プレゼンティティが１００個、ウォッチャーが１００個あるシステムを考える。このとき例えば、１００個のプレゼンティティ１２０−１〜１２０−１００に対して、１００個のウォッチャー１３０−１〜１３０−１００が、それぞれのプレゼンティティのプレゼンス情報を収集する場合、プレゼンティティ１２０−１〜１２０−１００からプレゼンスサーバ１１０へのプレゼンス情報の提供は、各プレゼンティティがすべてのウォッチャー１３０−１〜１３０−１００に対して行うため、１００×１００＝１００００個の通知メッセージ（プレゼンス情報）が必要となる（１つのプレゼンティティは、１００個のウォッチャーそれぞれに同じプレゼンス情報を送り、またプレゼンティティが１００個あるので１００×１００となる）。

同様に、プレゼンスサーバ１１０からウォッチャー１３０−１〜１３０−１００へのプレゼンス情報の通知は、同じく１００×１００＝１００００個必要であり、合計２００００個のプレゼンス情報の通知メッセージの交換が必要となる。

このように、従来のＲＦＣ２７７８によるプレゼンスサービスでは、プレゼンティティ及びウォッチャーの数が多くなると、通知すべきメッセージの数が膨大になってしまい、通信品質を低下させるといった問題があった。

本発明はこのような点に鑑みてなされたものであり、プレゼンティティとウォッチャー間のメッセージ数を効率よく削減して通信品質の低下を防止したプレゼンス通信システムを提供することを目的とする。

上記課題を解決するために、プレゼンス通信システムが提供される。プレゼンス通信システムは、複数のプレゼンス情報を含むグループに対応するグループ識別子を階層化構造とし、プレゼンス情報を、最上位階層のグループ識別子ですべてのプレゼンス情報が集約されるように、下位階層のグループ識別子に対応するプレゼンス情報を、下位階層から上位階層へ向けて階層毎に順に集約して蓄積し、かつ要求されたプレゼンス情報をグループ識別子毎に配信するプレゼンスサーバと、プレゼンスサーバへ、グループ識別子毎にプレゼンス情報を提供するプレゼンス情報の提供クライアントと、グループ識別子毎に要求したプレゼンス情報を、プレゼンスサーバから受信するプレゼンス情報の要求クライアントとを有する。

通信品質の低下を防止することが可能になる。

本発明の上記および他の目的、特徴および利点は本発明の例として好ましい実施の形態を表す添付の図面と関連した以下の説明により明らかになるであろう。

プレゼンス通信システムの構成例を示す図である。プレゼンスサーバの概略構成を示す図である。複数のグループＵＲＩに対してプレゼンス情報を提供している様子を示す図である。プレゼンスサーバがプレゼンス情報を中継する場合の様子を示す図である。グループＵＲＩの階層化構造を示す図である。上位階層へ行くほどプレゼンス情報量を少なくさせる階層化構造を持つプレゼンスサーバの具体的な使用例を示す図である。グループＵＲＩディレクトリサーバを示す図である。プレゼンスサービス方法の動作を示すフローチャートである。概念モデルを示す図である。システム構成を示す図である。機能ブロックのＤＢ構成を示す図である。グループＵＲＩディレクトリの構成を示す図である。グループＵＲＩ情報ＤＢの構成を示す図である。グループＵＲＩプレゼンスキャッシュの構成を示す図である。開示ポリシＤＢの構成を示す図である。購読メンバー情報ＤＢの構成を示す図である。配信ポリシＤＢの構成を示す図である。メンバー情報ＤＢの構成を示す図である。ネスト情報ＤＢの構成を示す図である。クライアントの処理フローを示す図である。グループＵＲＩディレクトリサーバの処理フローを示す図である。グループＵＲＩの購読処理を示すフローである。グループＵＲＩへのプレゼンス登録処理を示すフローである。プレゼンス情報通知処理のフローを示す図である。グループウォッチャーＵＡの処理フローを示す図である。グループＵＲＩの生成の処理シーケンスを示す図である。グループＵＲＩの購読の処理シーケンスを示す図である。グループＵＲＩへのプレゼンス登録の処理シーケンスを示す図である。グループＵＲＩのプレゼンス通知の処理シーケンスを示す図である。時刻表配信サービスを示す図である。イベントの登録例を示す図である。モードによるプレゼンス情報の通知先の切り替えサービスを示す図である。コミュニケーショングループへの適用例を示す図である。家電状態モニタへの適用例を示す図である。ホットスポットと連携した予約サービスへの適用例を示す図である。プレゼンスサービスシステムの概要を示す図である。ＲＦＣ２７７８による従来のプレゼンスサービスの問題点を示す図である。

以下、本発明の実施の形態を図面を参照して説明する。図１はプレゼンス通信システムの構成例を示す図である。プレゼンス通信システム１ａは、プレゼンスサーバ１０ａ、プレゼンティティ（Presentity）２０−１〜２０−ｎ及びウォッチャー（Watcher）３０−１〜３０−ｎから構成されて、通信前の相手状態（通信前のプレゼンティティの状態）を確認するプレゼンスを行ってからサービスを実行するシステムである。

プレゼンスサーバ１０ａは、複数のプレゼンス情報を１つのグループに束ね、この場合、プレゼンス情報の利用ポリシに同意したグループに付けられた識別子をグループ識別子（以下、グループＵＲＩと呼ぶ）とし、グループＵＲＩ毎にプレゼンス情報を集約、蓄積して、グループＵＲＩ毎に要求されるプレゼンス情報を配信する。

なお、プレゼンス情報とは、サービスを要求している人または端末装置などの状態（例えば、人が在席しているか否か、または端末装置が通信可能か否かなど）を表す情報のことである。

プレゼンティティ２０−１〜２０−ｎは、プレゼンス情報提供クライアントであって、プレゼンスサーバ１０ａへ、グループＵＲＩ毎にプレゼンス情報を提供する。また、プレゼンティティ２０−１〜２０−ｎは、プレゼンス情報を提供するグループＵＲＩを選択し、グループＵＲＩに送信すべきプレゼンス情報を選別、編集して、グループＵＲＩを宛先としてプレゼンス情報を提供する。

ウォッチャー３０−１〜３０−ｎは、プレゼンス情報要求クライアントであって、グループＵＲＩ毎にプレゼンティティ２０−１〜２０−ｎが提供したプレゼンス情報を要求し、プレゼンスサーバ１０ａから配信されたプレゼンス情報を受信する。

また、ウォッチャー３０−１〜３０−ｎは、プレゼンス情報を受信すると、プレゼンティティ２０−１〜２０−ｎに対して何らかのサービスを行う。例えば、プレゼンス情報からプレゼンティティ２０−１〜２０−ｎが通信可能な状態であることを知ると、プレゼンティティ２０−１〜２０−ｎへコンテンツを配信したりする。

プレゼンス通信システム１ａでは、ＵＲＩと呼ばれるプレゼンティティの識別子の他に、複数のプレゼンティティ２０−１〜２０−ｎから登録される複数のプレゼンス情報を何らかの共通の目的で束ねるグループＵＲＩを設けることで、プレゼンティティ２０−１〜２０−ｎが、目的に応じて自発的にグループＵＲＩを選択して、プレゼンス情報を通知することを特徴としている。

ここで、プレゼンティティ２０−１とウォッチャー３０−１〜３０−ｍとの間でプレゼンス情報（例えば、プレゼンティティ２０−１が在席しているか否かの情報）の要求、提供が行われる場合を考える。

ウォッチャー３０−１〜３０−ｍのそれぞれが、プレゼンティティ２０−１の在席を知るためには、従来では、ウォッチャー３０−１〜３０−ｍのそれぞれからプレゼンス情報要求をプレゼンティティ２０−１へ向けて送信し（ｍ個のプレゼンス情報要求メッセージを送信）、プレゼンティティ２０−１は、ウォッチャー３０−１〜３０−ｍのそれぞれに対して、プレゼンス情報を返信する必要があった（ｍ個のプレゼンス情報の返信）。

一方、プレゼンス通信システム１ａは、グループＵＲＩを設けてプレゼンス情報の要求、提供を制御する。例えば、プレゼンティティ２０−１と、ウォッチャー３０−１〜３０−ｍとがプレゼンス情報の利用ポリシに同意した同じグループであり、これらグループにグループＵＲＩ＃１を設けるとする。

このとき、プレゼンティティ２０−１がグループＵＲＩ＃１を宛先として、プレゼンスサーバ１０ａにプレゼンス情報を１度だけ送信し、プレゼンスサーバ１０ａは、このプレゼンス情報をグループＵＲＩ＃１で蓄積・管理する。

ウォッチャー３０−１〜３０−ｍは、プレゼンティティ２０−１〜２０−ｎの在席を確認したい場合、プレゼンスサーバ１０ａに対して、グループＵＲＩ＃１にアクセスすることで、プレゼンティティ２０−１のプレゼンス情報を取得し、在席状態を認識できる。

すなわち、プレゼンティティ２０−１では、１回だけプレゼンス情報をグループＵＲＩ＃１宛てに送信すれば、ウォッチャー３０−１〜３０−ｍからプレゼンス情報の要求があったときは、プレゼンスサーバ１０ａからプレゼンス情報がまとめてウォッチャー３０−１〜３０−ｍへ配信されることになり、従来のように何回もプレゼンス情報要求がきて、その度にプレゼンス情報を返信するといった面倒な通信を行わずにすみ、通信品質の低下を防止することができる。

さらにここで、図３７で示した従来技術と比較する意味で、プレゼンス通信システム１ａにおいて、１００個のプレゼンティティ２０−１〜２０−１００に対して１００個のウォッチャー３０−１〜３０−１００が、それぞれのプレゼンティティのプレゼンス情報を収集する場合を考える。

プレゼンティティ２０−１〜２０−１００からプレゼンスサーバ１０ａへのプレゼンス情報の通知は、各プレゼンティティが、情報共有を前提として、プレゼンス情報の利用ポリシに同意したグループＵＲＩに向けて行われる。このため、ウォッチャーの数に無関係に各プレゼンティティが１回のみ通知を行えばよい。したがって、必要な通知メッセージの数は１００個である。

また、プレゼンスサーバ１０ａからウォッチャー３０−１〜３０−１００へのプレゼンス情報の通知に必要な通知メッセージの数も、同じく複数のプレゼンティティのプレゼンス情報がリストとして集約されているため１００回で済む。したがって、合計２００個のプレゼンス情報の通知メッセージの交換で済むことになる。

これは、従来の方式に比べて、はるかに少ない通知メッセージの交換で、プレゼンス情報の収集、配信システムを実現していることになる。この効果は、対象とするプレゼンティティとウォッチャーの数が増加するにしたがって顕著になる。

また、プレゼンティティ２０−１〜２０−ｎは、ディレクトリで公開されている利用ポリシにもとづいて、提供するプレゼンス情報が公開されることに同意しているので（グループＵＲＩは、ディレクトリサーバにより公開されている。図７で後述）、プレゼンス情報の安全性が問題になることはない（また、プレゼンス情報の公開に同意しているので、プレゼンティティが直接ウォッチャーの適否を判断する必要もない）。

なお、上記ではプレゼンスサーバ１０ａとウォッチャー３０−１〜３０−ｎを構成上分けて示したが、プレゼンスサーバ１０ａ内にウォッチャーの機能を持たせる構成にしても構わない。

図２はプレゼンスサーバ１０ａの概略構成を示す図である。プレゼンスサーバ１０ａは、受信部１１ａ、グループＵＲＩデータベース１２ａ、配信部１３ａから構成される。受信部１１ａは、複数のプレゼンティティ２０−１〜２０−ｎからグループＵＲＩに提供されるプレゼンス情報を受信する。

グループＵＲＩデータベース１２ａは、受信したプレゼンス情報を、プレゼンティティ２０−１〜２０−ｎの識別子（ＵＲＩ）とプレゼンス情報との組で表したリスト形式で蓄積する。配信部１３ａは、グループＵＲＩに対してウォッチャー３０−１〜３０−ｎから要求されるプレゼンス情報の受信要求を受信して、プレゼンス情報の受信要求を行ったウォッチャーに対して、リスト形式のプレゼンス情報を配信する。

次にプレゼンス通信システム１ａの他の特徴について図３〜図８を用いて説明する。図３は複数のグループＵＲＩに対してプレゼンス情報を提供している様子を示す図である。プレゼンスサーバ１０ａは、複数の異なるグループＵＲＩ＃１〜＃ｎを有し、プレゼンティティ２０−１〜２０−ｎは、グループＵＲＩ＃１〜＃ｎそれぞれにプレゼンス情報を提供する。

また、プレゼンティティ２０−１〜２０−ｎは、グループＵＲＩの選択機能を持ち、プレゼンス情報の内容と、グループＵＲＩへのプレゼンス情報の提供方針とにもとづき、プレゼンスサーバ１０ａに対して、プレゼンス情報の提供の有無、またはプレゼンス情報の通知間隔を決定する。

例えば、プレゼンティティ２０−１がコンテンツＡの配信を望むならグループＵＲＩ＃１へ現在在席していることを示すプレゼンス情報を提供し、コンテンツＢの配信を望むならグループＵＲＩ＃２へ現在在席していることを示すプレゼンス情報を提供したりする。また、プレゼンス情報の提供の有無や通知間隔はプレゼンティティ２０−１〜２０−ｎ側で任意に決定可能である。

次に複数のウォッチャー３０−１〜３０−ｎを介してのプレゼンス情報の中継動作について説明する。図４はプレゼンスサーバがプレゼンス情報を中継する場合の様子を示す図である。

プレゼンスサーバ１０ａは、グループＵＲＩ＃１ａを、プレゼンスサーバ１０ｂは、グループＵＲＩ＃１ｂを有している。グループＵＲＩ＃１ａとグループＵＲＩ＃１ｂは、より大きなグループのサブセットであり、互いにプレゼンス情報を共用するものとする。

プレゼンティティ２０−１ａ〜２０−ｎａは、グループＵＲＩ＃１ａへプレゼンス情報を提供し、プレゼンスサーバ１０ａは、グループＵＲＩ＃１ａで複数のプレゼンス情報を集約して、集約したプレゼンス情報群をプレゼンスサーバ１０ｂへ配信する。

プレゼンティティ２０−１ｂ〜２０−ｎｂは、グループＵＲＩ＃１ｂへプレゼンス情報を提供し、プレゼンスサーバ１０ｂは、グループＵＲＩ＃１ｂで複数のプレゼンス情報を集約して、集約したプレゼンス情報群をプレゼンスサーバ１０ａへ配信する。

ウォッチャー３０−１ａ〜３０−ｎａは、プレゼンスサーバ１０ａのグループＵＲＩ＃１ａを介して、ウォッチャー３０−１ｂ〜３０−ｎｂは、プレゼンスサーバ１０ｂのグループＵＲＩ＃１ｂを介して、プレゼンティティ２０−１ａ〜２０−ｎａ、２０−１ｂ〜２０−ｎｂの両方のプレゼンス情報を知ることができる。

上記では、グループＵＲＩ＃１ａ、グループＵＲＩ＃１ｂを中継して互いにプレゼンス情報を配信する構成を示しているが、同様な制御により、複数のプレゼンスサーバを介してプレゼンス情報を中継すること、または１つのプレゼンスサーバ内の複数のグループＵＲＩでプレゼンス情報を中継することも可能である。

このように複数のグループＵＲＩを連携させて、プレゼンス情報を収集することにより、プレゼンティティが、同種のサービスに複数加入しているときに、個々のグループＵＲＩにプレゼンス情報を個別に登録する必要がなくなるため、よりトラフィックの削減が期待できる。

次にグループＵＲＩの階層化構造について説明する。図５はグループＵＲＩの階層化構造を示す図である。プレゼンスサーバ１０ａは、複数のグループＵＲＩを階層化構造とし、最上位層グループＵＲＩですべてのプレゼンス情報が集約、蓄積するように、最下位層グループＵＲＩに蓄積されたプレゼンス情報を、下位から上位へ向けて階層毎に順に集約、蓄積していく。

図では、グループＵＲＩ＃１−１〜＃１−４が最下位層に位置しており、グループＵＲＩ＃１−１、＃１−２で蓄積されているプレゼンス情報は、グループＵＲＩ＃２−１へ集約されて蓄積され、グループＵＲＩ＃１−３、＃１−４で蓄積されているプレゼンス情報は、グループＵＲＩ＃２−２へ集約されて蓄積される。さらに、グループＵＲＩ＃２−１、＃２−２で蓄積されているプレゼンス情報は、グループＵＲＩ＃３で集約され蓄積される。

このような階層化構造のグループＵＲＩに対して、プレゼンティティは最下位のグループＵＲＩ＃１−１〜＃１−４に対してプレゼンス情報を提供し、プレゼンスサーバ１０ａは、所定の階層のグループＵＲＩのプレゼンス情報をウォッチャーへ送信する。

このような構成にすることにより、大規模システムを構築する場合でも、多くのプレゼンス情報を簡潔に管理することができ、ウォッチャーに対して各階層に応じたプレゼンス情報を柔軟に提供することが可能になる。

一方、プレゼンス情報を下位から上位へ向けて階層毎に順に集約、蓄積していく場合に、上位階層に提供するプレゼンス情報を絞り込んで、上位階層へ行くほどプレゼンス情報量を少なくさせてもよい。

図６は上位階層へ行くほどプレゼンス情報量を少なくさせる階層化構造を持つプレゼンスサーバの具体的な使用例を示す図である。グループＵＲＩ＃１を第１開発課で使用する識別子とし、グループＵＲＩ＃２を第２開発課で使用する識別子とする。また、グループＵＲＩ＃３をグループＵＲＩ＃１、＃２よりも上位の階層に位置させて、第１開発課と第２開発課とを統括する統括開発部が使用する識別子とする。

ここで、第１開発課の社員は、例えば、自分の在席状態や、社外にいるなら自分がいる位置や、自分が使用する端末の通信状態等をプレゼンス情報としてグループＵＲＩ＃１へ提供する。第２開発課の社員も同様にして、プレゼンス情報をグループＵＲＩ＃２へ提供する。

そして、プレゼンスサーバ１０ａでは、グループＵＲＩ＃１、＃２のそれぞれで集約したプレゼンス情報に対して必要な情報だけを絞り込んで、グループＵＲＩ＃３に登録する。例えば、プレゼンス情報の中の端末通信状態のみに限定してグループＵＲＩ＃３に登録する。

次にグループＵＲＩディレクトリサーバについて説明する。図７はグループＵＲＩディレクトリサーバを示す図である。グループＵＲＩディレクトリサーバ４０は、グループＵＲＩの情報をプレゼンティティが検索可能なグループＵＲＩディレクトリ４１を含むサーバであり、グループＵＲＩのサービス利用案内をプレゼンティティ２０−１〜２０−ｎに公開する。プレゼンティティ２０−１〜２０−ｎは、グループＵＲＩディレクトリ４１を電話帳のように使用して、所望のグループＵＲＩを検索することができる。

例えば、プレゼンティティ２０−１が、コンテンツＡを配信するサービスを受けたいとすると、グループＵＲＩディレクトリ４１を検索すれば、グループＵＲＩ＃１に自分のプレゼンス情報を提供すればよいことがわかる（グループＵＲＩ＃１に対して、プレゼンティティ２０−１がサービスを受け入れ可能な状態であることをプレゼンス情報として提供すれば、グループＵＲＩ＃１に登録されているウォッチャーから、プレゼンティティ２０−１へコンテンツＡが配信されることになる）。

次にプレゼンスサービス方法について説明する。図８はプレゼンスサービス方法の動作を示すフローチャートである。
〔Ｓ１〕プレゼンスサーバ１０ａは、プレゼンス情報を収集するためのグループＵＲＩを生成する。

〔Ｓ２〕グループＵＲＩディレクトリサーバ４０は、サービスの案内情報と共にグループＵＲＩのディレクトリを登録する。
〔Ｓ３〕プレゼンティティ２０−１〜２０−ｎは、グループＵＲＩディレクトリサーバ４０を用いてグループＵＲＩを検索し、所望するサービスのグループＵＲＩにプレゼンス情報を提供する。

〔Ｓ４〕プレゼンスサーバ１０ａは、プレゼンティティ２０−１〜２０−ｎから提供されたプレゼンス情報をグループＵＲＩ毎に集約、蓄積する。
〔Ｓ５〕ウォッチャー３０−１〜３０−ｎは、グループＵＲＩ毎にプレゼンティティ２０−１〜２０−ｎが提供したプレゼンス情報を要求する。

〔Ｓ６〕プレゼンスサーバ１０ａは、グループＵＲＩ毎に要求されるプレゼンス情報をウォッチャー３０−１〜３０−ｎに配信する。
〔Ｓ７〕ウォッチャー３０−１〜３０−ｎは、配信されたプレゼンス情報を受信して、プレゼンティティ２０−１〜２０−ｎの状態を認識し、サービス提供可能なプレゼンティティに対してサービスを実行する。

次にプレゼンス通信システム１ａの詳細構成及び動作について説明する。図９は概念モデルを示す図である。
・プレゼンス情報１
プリンシパルの状態を示す情報である。プリンシパルは、ＲＦＣ２７７８で実世界の人間やプログラムを表すものとして定義されている。プレゼンス情報のフォーマットは、ＲＦＣ２７７８に一例が示されている。図９でプレゼンス情報は、ＰＩ−１Ａのような記号で示されている。例えば、ＰＩ−１Ａは、プリンシパル１が収集するタイプＡのプレゼンス情報であることを示す。

・グループプレゼンスユーザエージェント：グループプレゼンスＵＡ２
グループプレゼンティティ５に、プレゼンス情報を通知するためにプリンシパルが利用する手段であり、プリンシパルがグループＵＲＩディレクトリ３から必要な情報を取り出すことにより、動的に生成する。ここでグループＡプレゼンスＵＡは、グループＡのプレゼンスＵＡであることを示し、グループＢプレゼンスＵＡは、グループＢのプレゼンスＵＡであることを示す。

・グループＵＲＩディレクトリ３
プリンシパルがプレゼンス情報の通知先とプレゼンス情報の通知依頼の依頼先を調べる時に参照するグループプレゼンティティ５とグループウォッチャー６の識別子であるグループＵＲＩのＵＲＩアドレス、グループが必要とするプレゼンス情報、グループＵＲＩの公開ポリシ、配信ポリシ等が登録されたディレクトリサーバ。ここでは、説明のためグループＡは、タイプＡのプレゼンス情報を収集するグループであり、グループＢはタイプＢのプレゼンス情報を収集するグループであるとする。

・プレゼンスサービス４
プレゼンスサービス４（図１のプレゼンスサーバ１０ａに該当）は、グループプレゼンティティ５が通知する最新のプレゼンス情報を管理し、グループプレゼンティティ５のプレゼンス情報の通知依頼を登録しているグループウォッチャー６にプレゼンス情報を通知する。

・グループプレゼンティティ５
グループプレゼンティティ５は、グループプレゼンスＵＡ２から通知されるプレゼンス情報をリスト形式で束ねて、プレゼンスサービス４にプレゼンスプロトコルを用いて通知するエンティティである。グループプレゼンティティ５が生成される時に、グループプレゼンティティ５にプレゼンス情報を通知するために必要な情報が、グループＵＲＩディレクトリ３にも登録される。ここでグループＡプレゼンティティは、グループＡのプレゼンティティであることを示し、グループＢプレゼンティティは、グループＢのプレゼンティティであることを示す。

・グループウォッチャー６
プレゼンスサービス４に対して、グループプレゼンティティ５の識別子であるグループＵＲＩを用いてプレゼンス情報の通知依頼を行うエンティティである。プレゼンスサービスからは、リスト形式で記述されたプレゼンス情報を受信する。この通知に関しては、ｄｒａｆｔ−ｉｅｔｆ−ｓｉｍｐｌｅ−ｅｖｅｎｔ−ｌｉｓｔ−０７に１つのアイデアが示されている。ここでグループＡウォッチャーは、グループＡのウォッチャーであることを示し、グループＢウォッチャーは、グループＢのウォッチャーであることを示す。

・グループウォッチャーユーザエージェント：グループウォッチャーＵＡ７
プリンシパルがプレゼンスサービス４からグループプレゼンティティ５のプレゼンス情報を通知してもらうために利用する手段であり、プリンシパルがグループＵＲＩディレクトリ３を検索し、該当のグループウォッチャー６と交渉し、交渉が成功した場合に動的に生成する。ここでグループＡウォッチャーＵＡは、グループＡのウォッチャーＵＡであることを示し、グループＢウォッチャーＵＡは、グループＢのウォッチャーＵＡであることを示す。

・プレゼンスサービス４へのプレゼンス情報登録処理
プリンシパル１は、グループＡに対して、プレゼンス情報を通知するプリンシパルである。プリンシパル２は、グループＡとグループＢに、プレゼンス情報を通知するプリンシパルである。プリンシパル１と２は、共にタイプＡとタイプＢのプレゼンス情報を収集しているとする。プリンシパル１と２は、グループＡ、ＢのそれぞれのグループプレゼンスＵＡをグループＵＲＩディレクトリ３の検索情報にもとづいて作成する。グループＡは、タイプＡのプレゼンス情報を収集するグループであり、グループＢは、タイプＢのプレゼンス情報を収集するグループであるから、プリンシパル１のグループＡプレゼンスＵＡは、ＰＩ−１Ａ、ＰＩ−１Ｂの２つのプレゼンス情報のうち、ＰＩ−１Ａのプレゼンス情報を選別し、グループＡプレゼンティティに通知する。プリンシパル２のグループＡプレゼンスＵＡは、ＰＩ−２Ａ、ＰＩ−２Ｂの２つのプレゼンス情報のうち、ＰＩ−２Ａのプレゼンス情報を選別し、グループＡプレゼンティティに通知する。プリンシパル２のグループＢプレゼンスＵＡは、ＰＩ−２Ａ、ＰＩ−２Ｂの２つのプレゼンス情報のうち、ＰＩ−２Ｂのプレゼンス情報を選別し、グループＢプレゼンティティに通知する。

・プレゼンスサービス４からのプレゼンス情報通知処理
プリンシパル３は、タイプＡのプレゼンス情報を収集している任意のプリンシパルの情報を欲している。グループＵＲＩディレクトリ３を検索してタイプＡの情報を収集しているグループＡを抽出して、グループＡウォッチャーにプレゼンス情報の通知依頼を行い、グループＡウォッチャーＵＡを生成する。

プリンシパル４は、タイプＡとタイプＢのプレゼンス情報を判断し特定の条件を満たしたプリンシパルにサービスを提供する。グループＵＲＩディレクトリを検索してタイプＡとタイプＢの情報をそれぞれ収集しているグループＡとグループＢを抽出して、グループＡウォッチャーとグループＢウォッチャーにプレゼンス情報の通知依頼を行い、グループＡウォッチャーＵＡとグループＢウォッチャーＵＡを生成する。

グループＡプレゼンティティは、プリンシパル１のグループＡプレゼンスＵＡと、プリンシパル２のグループＡプレゼンスＵＡから通知された、プレゼンス情報ＰＩ−１Ａ、ＰＩ−２Ａをリスト形式にしてグループＡのプレゼンス情報として、プレゼンスサービス４に通知する。

グループＢプレゼンティティは、プリンシパル２のグループＢプレゼンスＵＡから通知された、プレゼンス情報ＰＩ−２Ｂをリスト形式にしてグループＢのプレゼンス情報として、プレゼンスサービス４に通知する。

グループＡウォッチャーは、プレゼンスサービスよりプレゼンス情報ＰＩ−１Ａ、ＰＩ−２Ａがリスト形式にされたグループＡのプレゼンス情報を通知される。グループＡウォッチャーは、プリンシパル３のグループＡウォッチャーＵＡとプリンシパル４のグループＡウォッチャーＵＡに対して同じ形式でグループＡのプレゼンス情報を通知する。

グループＢウォッチャーは、プレゼンスサービスよりプレゼンス情報ＰＩ−２Ｂがリスト形式にされたグループＢのプレゼンス情報を通知される。グループＢウォッチャーは、プリンシパル４のグループＢウォッチャーＵＡに対して同じ形式でグループＢのプレゼンス情報を通知する。

次にシステム機能概要について説明する。図１０はシステム構成を示す図である。
・クライアント８
グループプレゼンスユーザエージェント機能を実装するＰＣ、ＰＤＡ、携帯電話等の通信機器。この実装例では、プリンシパルは、サービスを受けるユーザであると定義し、それぞれのユーザは１台のクライアント端末を使用していると想定する。

・グループＵＲＩディレクトリサーバ９
グループＵＲＩディレクトリ機能を実装したディレクトリサーバ。
・プレゼンスサービスサーバ１０
プレゼンスサービス４と、グループプレゼンティティ５と、グループウォッチャー６の機能を実装したサーバ。

・アプリケーションサーバ１１
グループウォッチャーユーザエージェント機能を実装したサーバ。プレゼンス情報を参照して何らかのサービスをユーザに提供する。

・オペレータ１２
プレゼンスサービスサーバ上にグループＵＲＩを作成し、グループＵＲＩディレクトリサーバに登録するグループＵＲＩの管理者。管理者は、アプリケーションサーバや、クライアントと連携した、グループＵＲＩ管理ソフトであるように構成することもできる。

次にデータについて説明する。図１１は機能ブロックのＤＢ構成、図１２〜図１９はデータ構成を示す図である。図１２はグループＵＲＩディレクトリ３の構成を示す図である。グループＵＲＩディレクトリ３は、グループＵＲＩの情報を利用者が検索できるようにするための電話帳に対応するようなＤＢでありグループＵＲＩで索引されるグループＵＲＩ情報から構成される。グループＵＲＩ情報は、グループプレゼンティティ、グループウォッチャーを指定する識別子であるグループＵＲＩと、このグループの使用目的等の人間が用途を理解できるような情報を含む説明記述と、このグループＵＲＩが必要とするプレゼンス情報と、グループＵＲＩの作成者が、誰にどのようなポリシで収集した情報を公開するかを示す公開ポリシと、グループＵＲＩがネスト構造を持つ場合、グループプレゼンティティにプレゼンス情報を通知した場合に、通知メッセージを回送する宛先である関連ＵＲＩで構成される。

図１３はグループＵＲＩ情報ＤＢ８−１の構成を示す図である。グループＵＲＩ情報ＤＢ８−１は、グループＵＲＩディレクトリのサブセットであり、クライアントに蓄積されるグループＵＲＩディレクトリの索引情報のキャッシュである。グループＵＲＩ情報ＤＢ８−１は、プレゼンス通知時の宛先の識別子であるグループＵＲＩと、このグループＵＲＩが必要とするプレゼンス情報とで構成される。

図１４はグループＵＲＩプレゼンスキャッシュ４−１の構成を示す図である。グループＵＲＩプレゼンスキャッシュ４−１は、複数のクライアントから通知されるプレゼンス情報を蓄積するためのキャッシュであり、グループＵＲＩで索引されるリソースリストエントリから構成される。リソースリストエントリはこのリストを構成するプレゼンス登録メンバーの現在のプレゼンス情報を示すメンバー情報で構成される。メンバー情報は、メンバーの識別を示すメンバーＵＲＩとメンバーのプレゼンス情報から構成される。

図１５は開示ポリシＤＢ６−１の構成を示す図である。開示ポリシＤＢ６−１は、アプリケーションサーバからプレゼンス通知依頼要求があった場合、通知を許可（認可）するかどうかを判断する情報であり、グループＵＲＩで索引されるグループＵＲＩ認可情報から構成される。グループＵＲＩ認可情報は開示先毎に規定される情報である開示先情報で構成される。開示先情報は、開示先情報の公開先を示す開示許可ドメインと、プレゼンス情報の公開の粒度や、公開するリスト情報にグループＵＲＩ登録メンバーの全体を含めるか一部を含めるかの情報を示す開示範囲とで構成される。

図１６は購読メンバー情報ＤＢ６−２の構成を示す図である。購読メンバー情報ＤＢ６−２は、グループＵＲＩの購読者を管理するＤＢであり、グループＵＲＩで索引される購読メンバー情報で構成される。購読メンバー情報は、グループＵＲＩを購読中のメンバーのＵＲＩを示すメンバーＵＲＩで構成される。

図１７は配信ポリシＤＢ６−３の構成を示す図である。配信ポリシＤＢ６−３は、グループＵＲＩプレゼンスキャッシュが更新された場合、どのようなタイミングでアプリケーションサーバに通知するか、通知方法は、どのようなものであるかを規定するＤＢであり、グループＵＲＩで索引される配信ポリシで構成される。配信ポリシは、例えば、グループＵＲＩプレゼンスキャッシュの蓄積条件を規定するキャッシュ条件、アプリケーションサーバに対して、全リソースを通知するか、差分のみを追加するかというような通知条件で構成される。

図１８はメンバー情報ＤＢ５−３の構成を示す図である。メンバー情報ＤＢ５−３は、グループＵＲＩに対してプレゼンスを通知してくるメンバーを管理するためのＤＢであり、グループＵＲＩで索引されるグループＵＲＩメンバー情報で構成される。グループＵＲＩメンバー情報は、プレゼンス登録者の識別を示すメンバーＵＲＩで構成される。

図１９はネスト情報ＤＢ５−４の構成を示す図である。ネスト情報ＤＢ５−４は、グループＵＲＩが他のＵＲＩの代表ＵＲＩとして定義された場合に、次の回送先を示すＤＢであり、グループＵＲＩで索引される回送先情報で構成される。回送先情報は、複数の回送先エントリで構成され、それぞれの回送先エントリは、回送先の識別を示すＵＲＩと、回送の可否を判定するための回送ポリシとで構成される。

次に図１１に示した機能ブロックの詳細について図２０〜図２５を用いて説明する。各機能ブロックの実体はプログラムであり、メモリ（ＲＡＭ等）上に展開され、本発明の機能を実装したＰＣ、サーバ等の中央演算処理装置（ＣＰＵ）により実行される。

・クライアント８（図１１）
クライアント８は、プレゼンスサーバに対してプレゼンス情報を通知するエンティティである。グループＵＲＩ毎に必要なプレゼンス情報を仕分けし、グループプレゼンティティを表すグループＵＲＩに向けてプレゼンス情報の通知を行なう。

クライアント８は、グループＵＲＩ情報ＤＢ８−１と、ディレクトリ連携機能８−２と、グループプレゼンスＵＡ２と、プレゼンス収集機能８−３から構成される。グループＵＲＩ情報ＤＢ８−１については、既に説明済みである。

ディレクトリ連携機能８−２は、グループＵＲＩディレクトリサーバ９から必要とするグループＵＲＩの検索を行い、グループＵＲＩディレクトリ３から該当グループＵＲＩのＵＲＩや、必須プレゼンス等の登録に必要な情報を抽出し、グループＵＲＩ情報ＤＢ８−１に登録を行い、グループプレゼンスＵＡ２を生成する。

グループプレゼンスＵＡ２は、プレゼンス収集機能８−３によりプレゼンス情報が収集されると、グループＵＲＩ情報ＤＢ８−１を参照し、記録されているグループＵＲＩに送信するプレゼンス情報通知メッセージを作成する。この時、収集された複数のプレゼンス情報の中から必要なプレゼンス情報を選別してメッセージに設定する。また、グループプレゼンスＵＡ２は、グループＵＲＩ情報に登録された複数のグループＵＲＩ毎に作成し、プレゼンス情報を複数のグループプレゼンティティに同時にプレゼンス情報を通知するように構成することもできる。更に、この時に状況に応じてグループプレゼンスへの通知メッセージの送出可否を決定するように構成することもできる。

図２０はクライアントの処理フローを示す図である。
Ｓ８０１：グループＵＲＩディレクトリサーバ９より、ユーザがサービスを享受するために必要なグループＵＲＩを選択し、必要な情報をグループＵＲＩディレクトリサーバ９よりダウンロードする。

Ｓ８０２:グループＵＲＩにプレゼンスを通知するために必要な情報をグループＵＲＩ情報ＤＢ８−１に登録する。
Ｓ８０３:プレゼンス収集機能８−３は、プレゼンス情報の変化を監視する。プレゼンス情報は、例えば、クライアント端末の通信状態（オンライン、オフライン）、プリンシパル（ユーザ）から手動入力されるユーザの状態（会議中等）、センサーが収集する情報（無線タグの読み込みによる周辺機器の情報、ＧＰＳによる位置情報）等が考えられる。監視対象のプレゼンス情報に変化があった場合は、グループプレゼンスＵＡ２を起動し、Ｓ８０４に進む、変化が無い場合は、監視処理を続行する。

Ｓ８０４：グループプレゼンスＵＡ２は、グループＵＲＩ情報ＤＢ８−１を参照して、送出先のグループＵＲＩと、通知する必要のあるプレゼンス情報を特定する。
Ｓ８０５：Ｓ８０４の情報にもとづいて、プレゼンス情報通知メッセージを編集し、プレゼンスサービスサーバ１０に送出する。

Ｓ８０６：グループＵＲＩ情報ＤＢ８−１に記録されているすべてのグループＵＲＩに対して、プレゼンス情報通知が終了するまで、プレゼンス通知処理を続行する。プレゼンス通知処理が完了すると、Ｓ８０３に戻りプレゼンス情報の監視を行う。

・グループＵＲＩディレクトリサーバ９（図１１）
グループＵＲＩディレクトリサーバ９は、グループＵＲＩの情報をクライアントに公開することを目的としたサーバである。グループＵＲＩディレクトリサーバ９は、ディレクトリ管理機能９−１と、グループＵＲＩディレクトリ３と、ディレクトリ検索機能９−２から構成される。

ディレクトリ管理機能９−１は、オペレータに対して、グループＵＲＩの生成、登録のためのＧＵＩを提供し、入力された情報をグループＵＲＩディレクトリ３に登録する。グループＵＲＩディレクトリ３については、既に説明済みである。

ディレクトリ検索機能９−２は、クライアント８に対してグループＵＲＩ検索用のＡＰＩを提供し、クライアント８からの検索指示にしたがってグループＵＲＩディレクトリ３を検索し、クライアント８が特定したグループＵＲＩの情報をクライアント８に送信する。

図２１はグループＵＲＩディレクトリサーバの処理フローを示す図である。
Ｓ９０１：オペレータは、グループＵＲＩディレクトリサーバ９の管理画面より、グループＵＲＩを作成し、必要な情報を入力する。

Ｓ９０２：入力された情報をグループＵＲＩディレクトリ３に登録する。
Ｓ９０３：クライアント８は、グループＵＲＩ検索画面より、所望するグループＵＲＩを検索するための情報を入力する。

Ｓ９０４：グループＵＲＩディレクトリを入力された情報にしたがって検索する。
Ｓ９０５：特定したグループＵＲＩの情報をクライアント８に通知する。
・プレゼンスサービスサーバ１０（図１１）
プレゼンスサービスサーバ１０は、グループＵＲＩ宛に行われる複数のクライアント８からのプレゼンス通知メッセージを受け付け、グループＵＲＩプレゼンスキャッシュ４−１にリスト情報として登録し、グループＵＲＩにプレゼンス情報の通知依頼を行うアプリケーションサーバ１１に対して、複数のクライアント８のプレゼンス情報を束ねたプレゼンス情報のリストを通知する機能を持つ。

プレゼンスサービスサーバ１０は、グループプレゼンティティ５と、プレゼンスサービス４と、グループウォッチャー６から構成される。
グループウォッチャー６は、グループＵＲＩへのプレゼンス情報の通知依頼を受け付け、アプリケーションへのプレゼンス情報の通知を管理するエンティティであり、プレゼンス情報の通知依頼を認可する時に参照される開示ポリシＤＢ６−１と、グループＵＲＩに対するプレゼンス情報の通知依頼者の一覧を管理する購読メンバー情報ＤＢ６−２と、プレゼンス情報を通知する時の方法を定義した配信ポリシＤＢ６−３と、グループＵＲＩへのプレゼンス情報の通知依頼メッセージの受付処理を行う購読受付機能６−４と、グループＵＲＩプレゼンスキャッシュ４−１が更新された場合に、アプリケーションサーバ１１にプレゼンス情報通知を行う通知制御機能６−５で構成される。グループＵＲＩプレゼンスキャッシュ４−１については、既に説明済みである。

グループプレゼンティティ５は、クライアントからグループＵＲＩに行われるプレゼンス情報の通知メッセージを受け付けるエンティティであり、プレゼンス情報通知メッセージを受け付け、グループＵＲＩに向けて送出された複数のクライアントからのプレゼンス情報を集約して、グループＵＲＩプレゼンスキャッシュ４−１及び、メンバー情報ＤＢ５−３に登録するプレゼンス受信機能５−１と、グループＵＲＩが他のＵＲＩと関係を持っている場合に、プレゼンス情報通知メッセージを他のプレゼンスサービスサーバに向けて回送するメッセージ回送機能５−２と、グループＵＲＩと他のＵＲＩとの関係を記録したネスト情報ＤＢ５−４とで構成される。

図２２〜図２４はプレゼンスサービスサーバの処理フローを示す図である。図２２はグループＵＲＩの購読処理を示すフローである。
Ｓ１００１：アプリケーションサーバ１１は、グループＵＲＩに対してプレゼンス情報通知依頼メッセージを投げることで、プレゼンス情報の通知依頼を行う。

Ｓ１００２：グループウォッチャー６、開示ポリシＤＢ６−１を参照して、プレゼンス情報通知依頼者の認証及び、通知の認可を決定する。
Ｓ１００３：通知が許可された場合、購読メンバー情報ＤＢ６−２にアプリケーションサーバ１１の識別（ＵＲＩ）を登録する。

図２３はグループＵＲＩへのプレゼンス登録処理を示すフローである。
Ｓ１００４：クライアント８は、プレゼンス情報が更新されるとプレゼンスサーバのグループＵＲＩを宛先としたプレゼンス情報通知メッセージを送信する。グループプレゼンティティ５は、プレゼンス情報通知メッセージを受信する。

Ｓ１００５：プレゼンス情報通知メッセージを送信してきたクライアントの識別（ＵＲＩ）をメンバー情報ＤＢ５−３に登録する。
Ｓ１００６：グループＵＲＩプレゼンスキャッシュ４−１の該当グループＵＲＩの該当メンバー情報をクライアントから通知されたプレゼンス情報で更新する。リアルタイム性が求められる場合は、この時点で、グループウォッチャーに更新通知を行うように構成しても良い。

Ｓ１００７：ネスト情報ＤＢ５−４を参照し、グループＵＲＩが他のＵＲＩと関係を持っていれば、ネスト情報ＤＢ５−４に登録されているＵＲＩに向けて、プレゼンス情報通知メッセージを回送する。この場合、グループプレゼンティティ５は、回送先のＵＲＩのエンティティに対してはクライアントとして動作する。通知するプレゼンス情報は、グループＵＲＩで集約されたリソースリスト情報であるように構成することもできる。

図２４はプレゼンス情報通知処理のフローを示す図である。
Ｓ１００８：グループウォッチャー６は、配信ポリシＤＢ６−３からプレゼンス情報通知の頻度や、通知方法を参照する。

Ｓ１００９：グループウォッチャー６は、配信ポリシの指定にしたがって、グループＵＲＩプレゼンスキャッシュ４−１を参照する。プレゼンスキャッシュ４−１の参照の仕方は、例えば１分に一回、グループＵＲＩに登録されている全メンバー（クライアント）のプレゼンス情報を通知するとか、グループプレゼンティティと連携して、グループＵＲＩの個々のメンバーに対してプレゼンス情報通知が行われた場合、そのメンバーのプレゼンス情報だけを通知するといった方法が考えられる。

Ｓ１０１０：購読メンバー情報６−２を参照し、登録されている購読者（アプリケーションサーバ１１）の識別（ＵＲＩ）へ、プレゼンス情報通知メッセージを送信する。
・グループウォッチャーＵＡ７（図１１）
グループウォッチャーＵＡ７は、グループＵＲＩに対してプレゼンス情報の通知依頼を行い、プレゼンスサーバから通知される複数のクライントのプレゼンス情報をリスト形式にしたプレゼンス情報を受信するエンティティである。
グループウォッチャーＵＡ７はグループＵＲＩに対してプレゼンス情報通知依頼メッセージを送出する購読依頼機能７−１と、グループＵＲＩの購読の結果としてリスト形式で通知されるプレゼンス情報を受信するプレゼンス受信機能７−２から構成される。

図２５はグループウォッチャーＵＡの処理フローを示す図である。
Ｓ７０１：アプリケーションサーバ１１は、プレゼンス情報を取得するためにグループウォッチャーＵＡ７を起動し、グループＵＲＩに対してプレゼンス情報通知依頼を行う。グループＵＲＩは、アプリケーションサーバ１１のサービスの提供者が情報収集のために作成して、登録することができる。グループＵＲＩがサービスの提供者により作成されたものでない場合は、グループＵＲＩディレクトリサーバ９を索引して、適切なグループＵＲＩを発見するように構成することもできる。

Ｓ７０２：プレゼンスサービスサーバ１０からのプレンゼンス情報通知メッセージを監視し、プレゼンスサービスサーバ１０からプレゼンス情報の通知があった場合、リスト形式で通知されたプレゼンス情報をメッセージより抽出し、アプリケーションに通知する。複数のクライアントのプレゼンス情報を束ねて通知する方法は、例えばｄｒａｆｔ−ｉｅｔｆ−ｓｉｍｐｌｅ−ｅｖｅｎｔ−ｌｉｓｔ−０７のドラフトで定義されている。リストを構成するメンバーの数が膨大な場合は、ビット形式で情報を伝達する、またはリストを何らかの方式で圧縮して送信する方法も考えられる。また、初回のみ完全なリストを通知し、以降は差分のみを通知するといった方法も効果的である。

次にプレゼンス通信システム１ａの処理概要シーケンスと、上述の機能ブロックの処理フローについて説明する。図２６はグループＵＲＩの生成の処理シーケンスを示す図である。

（１）サービスの提供者（情報配信業者または、情報提供業者）は、プレゼンスサービスのオペレータ１２（管理者）に、グループＵＲＩの作成依頼を行う。依頼方式は、サービス契約を取り交わす方式でも良いし、オペレータの機能をソフトウェアで構成し、依頼者が直接ＷＥＢ画面から入力するように構成、または、メールに必要な情報を記入し、送信することでグループＵＲＩが作成可能なように構成しても良い。尚、ここで情報配信業者は、クライアントのプレゼンス情報を参照、加工してクライアントへ情報を配信する業者、情報提供業者は、クライアントからのプレゼンス情報を収集し、情報配信業者へプレゼンス情報を提供する業者のことを示す。

（２）オペレータ１２は、プレゼンスサービスサーバ１０の各ＤＢ（開示ポリシＤＢ６−１、購読メンバー情報ＤＢ６−２、配信ポリシＤＢ６−３、グループＵＲＩプレゼンスキャッシュ４−１、メンバー情報ＤＢ５−３、ネスト情報ＤＢ５−４）に申請されたグループＵＲＩのエントリを作成し、初期値を設定する。ＤＢへの登録方法は、保守画面を介して管理者が入力する方法等が考えられる。

（３）オペレータ１２は、新設したグループＵＲＩを、クライアント８が利用可能なようにするために、グループＵＲＩディレクトリサーバ９にアクセスして、管理画面より必要情報を入力して、グループＵＲＩを登録する。

（４）グループＵＲＩディレクトリサーバ９のディレクトリ管理機能９−１は、グループＵＲＩディレクトリ３を更新する（図２１：Ｓ９０１〜９０２）。
図２７はグループＵＲＩの購読の処理シーケンスを示す図である。

（１）サービス提供者は、アプリケーションサーバ１１のグループウォッチャーＵＡ７を起動する。購読対象のグループＵＲＩの指定方法は、グループウォッチャーＵＡ７起動（生成）時にパラメータとして渡す方法や、グループＵＲＩディレクトリサーバ９と連携する方法が考えられる。

（２）グループウォッチャーＵＡ７の購読依頼機能７−１は、指定されたグループＵＲＩを管理しているプレゼンスサービスサーバにプレゼンス情報通知依頼メッセージを生成し送信する。プレゼンス情報通知依頼メッセージは、ＲＦＣ２７７８で規定されているＳＵＢＳＣＲＩＢＥメッセージを利用することができる。またｄｒａｆｔ−ｉｅｔｆ−ｓｉｍｐｌｅ−ｅｖｅｎｔ−ｌｉｓｔ−０７のドラフトで定義されているリスト形式のＵＲＩをサポートしているか否かの拡張を用いて相互接続性の交渉を行うこともできる（図２５:Ｓ７０１）。

（３）プレゼンスサービスサーバ１０のグループウォッチャー６は、グループＵＲＩを宛先として送出されたプレゼンス情報通知依頼メッセージを受け付け、開示ポリシＤＢ６−１を参照して、プレゼンス情報通知依頼が受付可能かどうか判断する。プレゼンス情報通知依頼メッセージの認可処理については、ＳＵＢＳＣＲＩＢＥメッセージを用いている場合は、送信者のＵＲＩとメッセージダイジェストを利用可能である。開示ポリシの最も単純な例は、購読者をグループＵＲＩの作成者に限定する場合である（図２２：Ｓ１００１〜Ｓ１００２）。

（４）プレゼンス情報通知依頼を受付可能である場合は、購読メンバー情報ＤＢ６−２にプレゼンス情報通知依頼者（アプリケーションサーバ）のＵＲＩを登録する（図２２：Ｓ１００３）。

図２８はグループＵＲＩへのプレゼンス登録の処理シーケンスを示す図である。
（１）ユーザは、クライアント８のグループプレゼンスＵＡ２を起動する。
（２）ユーザは、クライアント８が提供するグループＵＲＩ検索画面を利用して、所望するサービスのグループＵＲＩを特定する。この選択のイメージは、イエローページを検索することと類似である。ディレクトリ連携機能の例として、メッセンジャー、メーラー、チャットのようにそのグループＵＲＩを利用して配信される情報（インスタントメッセージ、メール、ＷＥＢ画面等）の表示ブラウザとを一体化したクライアントソフトを提供し、選択したグループＵＲＩをＧＵＩ画面に表示し、有効かそうでないかを選択可能にする、または時間に応じて自動的にグループＵＲＩを選択して、送出先を切り替えるような機能を持たせるようなことが考えられる（図２０：Ｓ８０１〜Ｓ８０２、図２１：Ｓ９０３〜Ｓ９０５）。

（３）クライアント８は、プレゼンス情報を監視する。プレゼンスの監視方法としては、例えば特開２００４−２２８８３３で開示されているように他のプレゼンティティのプレゼンス情報を購読する、人が手動で入力する、センサー等と連携して自動的に数値の変化を通知させることなどが考えられる。また、このプレゼンス情報自体を、本発明を用いて、他のエンティティから登録されるプレゼンス情報のリストであるように構成することもできる（図２０：Ｓ８０３）。

（４）プレゼンス情報の更新を検知すると、グループＵＲＩ情報ＤＢ８−１からグループＵＲＩを抽出し、指定されたプレゼンス情報を設定したプレゼンス情報通知メッセージを作成する。このプレゼンス情報通知メッセージは、例えばＲＦＣ３２６１で規定されているＲＥＧＩＳＴＲＡＴＩＯＮメッセージを利用することが可能である。または、ｄｒａｆｔ−ｉｅｔｆ−ｓｉｍｐｌｅ−ｅｖｅｎｔ−ｌｉｓｔ−０７のドラフトで定義されているバックエンド購読のような処理を流用することも可能である。但しこの場合、プレゼンス情報の購読者は、グループプレゼンティティ（または、グループウォッチャー）でなければならず、プレゼンス情報通知メッセージは、購読者であるグループウォッチャーに通知されるようにしなければならず、ｄｒａｆｔ−ｉｅｔｆ−ｓｉｍｐｌｅ−ｅｖｅｎｔ−ｌｉｓｔ−０７のようにＲＬＳ（リソースリストサーバ）の購読者に通知するようにしてはならない。この差分は、グループＵＲＩが束ねている情報が、個人向けの情報なのか、情報共有を目的としているかの違いにより生じる（図２０：Ｓ８０４〜Ｓ８０６）。

（５）プレゼンスサービスサーバ１０のグループプレゼンティティ５は、クライアント８からグループＵＲＩ宛に送出されたプレゼンス情報通知メッセージを受信し、プレゼンス情報通知メッセージの送信者を該当グループＵＲＩの登録メンバーとしてメンバー情報ＤＢ５−３に追加する。尚、グループＵＲＩの生成時に、登録可能メンバー情報をメンバー情報ＤＢ５−３に登録しておき、許可されたメンバーのみがプレゼンス情報通知を可能なように構成することもできる（図２２：Ｓ１００４〜Ｓ１００５）。

（６）プレゼンスサービスサーバ１０のグループプレゼンティティ５は、プレゼンス情報通知メッセージからプレゼンス情報を抽出し、グループＵＲＩプレゼンスキャッシュ４−１の該当グループＵＲＩのメンバーエントリ情報のプレゼンス情報を更新する（図２３：Ｓ１００６）。

（７）プレゼンスサービスサーバ１０のグループプレゼンティティ５は、メッセージ回送機能５−２にプレゼンス情報通知メッセージを通知する。
（８）プレゼンスサービスサーバ１０のグループプレゼンティティ５は、ネスト情報ＤＢ５−４を索引し、該当グループＵＲＩに関連付けされているＵＲＩがあるか参照する。このＵＲＩは、通常の単一のプレゼンティティを示すＵＲＩでも良いし、他のグループＵＲＩであっても良い（図２３：Ｓ１００７）。

（９）プレゼンスサービスサーバ１０のグループプレゼンティティ５は、関連するＵＲＩがある場合、それらのＵＲＩに向けてプレゼンス情報通知メッセージを回送する。回送先は、同じプレゼンスサービスサーバの他のプレゼンティティと、他の管理ドメインのプレゼンスサービスサーバのプレゼンティティの両方が可能である。

図２９はグループＵＲＩのプレゼンス通知の処理シーケンスを示す図である。
（１）プレゼンスサービスサーバ１０のグループウォッチャー６は、プレゼンス情報が購読されているそれぞれのグループＵＲＩに関して、配信ポリシＤＢ６−３から該当グループＵＲＩの配信方法の規定情報を抽出する。配信ポリシは、リアルタイム性の低いサービスであれば、３０分に一回の通知を規定しているかもしれず、リアルタイム性の高いものは、プレゼンス情報が変更されたら即時に通知することを規定しているかもしれない。配信ポリシの例としては、複数のメンバーのプレゼンス情報を蓄積していることの特性を活かして、例えばキーとなるメンバーのプレゼンス情報に合わせて配信ポリシを動的に変更するように構成するようなことも考えられる。具体的な例をあげると、場所のプレゼンス情報を収集するグループＵＲＩであれば、メンバーの中でキーとなるユーザと同じプレゼンス情報を持つメンバー（同じ場所にいる）のプレゼンス通知をリアルタイムに、それ以外のメンバーの通知は３０分に１回というように動的に配信方法を変更することで、全体のトラフィックを削減するようなことも考えられる。更に、本発明では、グループＵＲＩに対して、クライアント８が直接プレゼンス情報を登録するように構成するため、プレゼンスサービスサーバ１０の通知制御機能と、クライアント８のグループプレゼンスＵＡ２との間にプレゼンス情報通知間隔の交渉機能を持たせプレゼンス情報通知メッセージの送出レートを変更させるように構成することも考えられる。例えば、１分毎に更新されるプレゼンス情報があっても、グループＵＲＩの配信ポリシが３０分に１回であれば、２９回分のプレゼンス情報通知処理は無駄となるので、このグループＵＲＩに対しては３０回に１回のみプレゼンス登録を行うように変更するようなことが可能になる。このように構成することで、更に全体のトラフィックを削減するようなことが可能になる（図２４：Ｓ１００８）。

（２）プレゼンスサービスサーバ１０のグループウォッチャー６は、配信ポリシＤＢ６−３で指定される配信方法にしたがってグループＵＲＩプレゼンスキャッシュ４−１をクエリーし、プレゼンス通知メッセージを生成する。これは、例えば配信間隔が３０分に１回であれば、３０分おきにクエリーすればよいことを意味する。逆にリアルタイムな通知が必要な場合は、グループプレゼンティティ５のプレゼンス受信機能５−１にグループＵＲＩプレゼンスキャッシュ４−１を更新したらグループウォッチャー６の通知制御機能６−５にも更新を通知するように構成し、即時通知を可能なように構成しなければならないことを意味する（図２４：Ｓ１００９）。

（３）プレゼンスサービスサーバ１０のグループウォッチャー６は、購読メンバー情報６−２を参照して、グループＵＲＩを購読しているメンバーを特定する（図２４：Ｓ１０１０）。

（４）プレゼンスサービスサーバ１０のグループウォッチャー６は、購読メンバーに対してプレゼンス情報通知メッセージを送出する。プレゼンス情報通知メッセージは、例えばＲＦＣ２７７８で規定されているＮＯＴＩＦＹメッセージを、複数のプレゼンス情報の通知方法として、イベントリストのドラフトで定義されているＲＬＭＩ等を用いることができる（図２５：Ｓ７０２）。

次にプレゼンス通信システム１ａを利用したサービス例について説明する。図３０は時刻表配信サービスを示す図である。サービスのサンプルとして、ユーザの携帯端末に、公共交通機関の情報を配信し、ユーザの通勤や旅行をサポートするサービスを考える。バスや電車の時刻表や運行状況等は、利用予定時間の少し前にリアルタイムに通知されると非常に利便性が向上する。また、バスと鉄道、複数の鉄道を利用する等の場合には、目的の乗り物に乗車したあとは、自動的に次に利用する乗り物の案内が配信される、または、自動的に情報配信が停止すると便利である。

この例のようなサービスは、ユーザの状態と意思を反映させて情報配信を行う必要があるが、ＲＦＣ２７７８で規定されるプレゼンスサービスは、プレゼンスを欲する側（このサービス例では、情報を配信するサービス提供者側）が、ユーザにプレゼンス情報の通知を依頼することにより、プレゼンス情報の通知が開始されるため、ユーザの状態や意思を反映させるためには、サービス提供者側は、ユーザのプレゼンス情報を常に受信し、ユーザに指定された条件を満たした時にのみ情報を配信するようにシステムを構成する必要がある。

このようなシステム構成をとった場合、サービス提供者にとっては、個々のユーザのプレゼンス情報の収集管理は、管理面、システムでの処理負荷が高くなり、利用ユーザが多い場合、情報を収集するために膨大なリソースを必要とする。またユーザの意思は、それぞれのサービス提供業者に分散させて反映させる必要があるため、鉄道に乗車したら、次はバスの情報を配信してもらうといった連携が難しいという欠点もある。

これと同じ機能を持つシステムを本発明の機能を用いて構成してみる。鉄道とバスを利用して、会社に出勤しているユーザをサポートする例を考える。ユーザは、ＧＰＳと電子マネー機能を持った携帯電話を、このサービスを享受するために利用すると想定する。情報配信業者は、鉄道会社Ａとバス会社Ｂであり、それぞれサービスを提供するために情報収集グループtimescadule@raiway.comとtimescadule@buscompany.comを作成し、情報収集業者（携帯電話キャリヤ）のディレクトリサーバで公開しているとする。情報収集業者は、携帯電話のソフトとして、または、携帯電話にプレゼンスサービスを提供するプレゼンスサーバの機能として、本発明のグループＵＲＩのクライアント機能を提供しているとする。このクライアントは、このサンプルサービスをサポートするために、ユーザの指定した時間と、現在位置、及び電子マネーの使用履歴とを判断してグループＵＲＩへのプレゼンス登録を制御する機能を持つものとする。ユーザは、午前８：００ごろ自宅を出て、電車、バスの順番で乗り物を利用して会社へ通勤するとする。また、午後８：００ごろ、会社を出てバス、電車の順番で乗り物を利用して自宅へ帰宅するとする。この場合、ユーザは、午前８：００から直近１０分程度の電車の時刻表と運行状況を配信してもらうことを欲し、電車に乗り込んだ後は、バスの時刻表と運行状況を配信してもらうことを欲する。同様に、午後８：００から直近１０分程度のバスの時刻表と運行状況を配信してもらうことを欲し、バスに乗り込んだ後は、電車の時刻表と運行状況を配信してもらうことを欲する。

このようなサービスでは、自宅や会社を出発する時刻がいつもと異なる、または、出張等でいつもと違う場所にいる場合に柔軟に対応することが、単なる情報配信サービスとは異なるプレゼンスを利用した情報配信サービスのメリットとして期待される。以下に、サービスの手順を示す。

（１）ユーザは、携帯電話キャリヤの提供するディレクトリサービスから、鉄道会社Ａとバス会社ＢのグループＵＲＩを検索し、グループＵＲＩクライアントに取り込む。例えば、このグループＵＲＩクライアントは、ＪＡＶＡ（登録商標）アプリケーションであり、ｉモード（登録商標）のような携帯電話用ブラウザから、ディレクトリサービスと連携したＷＥＢサービス画面上で操作することによりグループＵＲＩの情報の取り込みを実現する。

（２）グループＵＲＩクライアントは、それぞれの情報配信を始めるための条件を登録、参照可能なように構成する。例えば、条件として、開始時刻、場所、イベント等を設定できるようにする。ユーザは、自分の行動スケジュールに合わせて、図３１のように登録する。

図３１はイベントの登録例を示す図である。この例では、開始及び終了イベントは、電子マネーの支払いを利用する。電子マネーで駅の改札を通過または、バスでの支払いを行った時に、電子マネーのアプリケーションと連動して、電子マネーの読み取り機や、購入履歴のログから支払先を特定し、鉄道やバスを利用したことを検知できるようにグループＵＲＩクライアントを構成する。また、ＧＰＳや基地局のセルから特定できる位置情報から自宅や会社といった指定を検知できるように、グループＵＲＩクライアントを構成する。グループＵＲＩクライアントがプレゼンス情報（この例では、電子マネーの利用履歴や位置情報）の収集方法と、ユーザの条件の指定方法については、様々なバリエーションが考えられる。ここで示したのはあくまでも１つの実施方法に過ぎず、この方式に特定するものではない。言い換えると、グループＵＲＩクライアントは、時刻、電子マネー利用、位置の３つをプレゼンスとして収集するように構成されており、プレゼンスの収集手段を、本発明は、限定しない。

（３）グループＵＲＩクライアントは、収集したプレゼンスとユーザから登録された条件の比較を常に行う。時刻がAM8：00で、位置が自宅であれば、（ａ）の条件に一致するので、グループＵＲＩtimescadule@raiway.comを宛先として、現在位置の送信を開始する。グループＵＲＩクライアントは、位置が変わるたび、または定期的に現在位置をtimescadule@raiway.comに送信する。

（４）鉄道会社Ａの情報配信アプリケーションは、timescadule@raiway.comに集められる情報を定期的に参照している。AM8：00になるとユーザのプレゼンスがtimescadule@raiway.comのプレゼンスリストに反映され始めるので、情報配信アプリケーション（サービスの実行も兼ねたプレゼンスサーバに該当）は、プレゼンスリストに示されるユーザのＩＤと、位置情報と、ユーザが鉄道会社Ａの情報配信アプリケーションに予め登録している利用路線の情報をもとに、最寄駅と、電車を求めて、時刻表ＤＢを参照して時刻表を配信する。鉄道会社Ａが時刻表ＤＢに電車の運行状況を反映するように構成していれば、運行状況等も合わせて配信しても良い。

（５）グループＵＲＩクライアントは、ユーザが駅の改札を、電子マネーを利用して通過すると、改札通過というイベントを発生させる。これは、例えば、改札が電子マネーを読み取った時に、鉄道会社へ支払われる乗車料金の利用履歴を利用することが考えられる。改札通過イベントの発生により（ａ）の終了条件と（ｂ）の開始条件が満たされるため、グループＵＲＩクライアントは、プレゼンスを通知する宛先を鉄道会社ＡのグループＵＲＩtimescadule@raiway.comからバス会社Ｂのtimescadule@buscompay.comに変更する。鉄道会社ＡのグループＵＲＩtimescadule@raiway.comに対しては、グループＵＲＩクライアントがプレゼンスサーバに明示的にプレゼンス情報の通知停止を通知するか、プレゼンスサーバを、リフレッシュ周期までに登録がこない場合は、公開停止にするように構築する。このようにすることで、鉄道会社ＡのグループＵＲＩtimescadule@raiway.comへのユーザのプレゼンス登録は、非活性となるので、鉄道会社Ａからの情報配信は停止される。即ち、改札を通過すると電車の時刻表は配信されなくなる。一方、バス会社ＢのグループＵＲＩtimescadule@buscompay.comに対してはプレゼンス登録が開始されるので、鉄道会社Ａからの鉄道の時刻表配信で説明したのと同じように、バス会社Ｂからユーザに対してバスの時刻表の配信が開始される。また、既に述べたのと同じ原理にもとづいて、ユーザがバスに乗車すると（バスの改札機に電子マネーをかざすと）、バスの時刻表の配信が停止される。

（６）帰宅時の動作も、既に説明したのと同じように行われ、PM8:00に会社にいると、バスの時刻表が配信され、バスに乗車すると鉄道の時刻表が配信される。
（７）このように構成することにより、情報提供側が逐一ユーザの状態を監視する代わりに、ユーザが自分の意思で、情報が欲しい時にのみ情報提供者に自分の状態を通知し、サービスを受けることが可能になる。この例では、情報提供者がユーザの状態を知らなければならないのは、１日に２回のみである。しかしＲＦＣ２７７８で規定される方式では、情報提供者がユーザの状態を監視する必要があるため、情報配信が行われる２回以外の、情報提供者にとって無関係なユーザの状態通知を処理し続けなければならない。本発明の機能を利用してシステムを構成することで、サービス提供とは無関係なユーザの状態を監視する労力から解放され、ネットワークの無駄なリソースの消費も抑制することが可能になる。

図３２はモードによるプレゼンス情報の通知先の切り替えサービスを示す図である。別のサービス例として、ユーザが自分の勤める企業と、家族に連絡の便宜のために、自分の状態を通知している例を考える。サービス例１と同様に、ユーザは、携帯電話を、プレゼンスを通知するための機器として所有していると想定する。ＲＦＣ２７７８で規定される方式でこのサービスを実現した場合、携帯電話キャリヤが、プレゼンスサービスを提供し、家族のメンバーと、企業の業務管理アプリケーションがユーザのプレゼンス情報の通知を依頼し、ユーザからプレゼンス情報を通知してもらうことになる。ユーザは、勤務時間以外には、会社に自分のプレゼンス情報を通知したくないかもしれないが、企業の業務管理アプリケーションがユーザの状態を見て、プレゼンス情報通知を依頼したり、通知依頼を中止したりするように構成するのは難しく、プレゼンス情報の通知を停止している間は、ユーザがプライベートな状態であるかどうか知る術はない。クライアントソフト上で、ユーザの状況とプレゼンス情報の通知先を判断して、通知先が企業と家族で異なる状態を送信する（即ち、勤務時間以外には、企業にはダミー情報を通知する）ように構成することは可能であるが、サービス例１の場合と同じように、必要でない時にも通知されるプレゼンス情報を処理し続けなければならないのは同じである。

次に、本発明の機能を用いてこのサービスの提供システムを構成することを考える。
（１）ユーザは、家族との連絡用のためのグループＵＲＩfamily@telephone.comを作成する。例えば、これは、携帯電話キャリヤが提供する付加サービスであり、家族間では無償で、お互いの状態を参照できるサービスとして提供されるかもしれない。携帯電話キャリヤは、ユーザとの契約にもとづき、このようなグループＵＲＩを作成し、管理する。

（２）企業は、企業内の内線電話と連動して、ユーザの状態を管理するプレゼンスサーバを独自に持っているかもしれない。または、ユーザが所有している携帯電話を企業内の内線電話としても利用できるように、携帯電話キャリヤが、プレゼンスサーバとして企業にアウトソーシングしているかもしれない。いずれの場合も、企業は、携帯電話から通知されるプレゼンスの受け口として、グループＵＲＩcompany@telephone.comを作成し、携帯電話キャリヤに登録する。

（３）携帯電話キャリヤは、プレゼンスサービス提供の実現方式として、例えば電波によるユーザの携帯電話の位置確認時に、ユーザが登録した状態を携帯電話から応答させることで、ユーザのプレゼンス情報を収集するようにプレゼンスサーバを構成する。携帯電話キャリヤの管理するプレゼンスサーバは、本発明のグループＵＲＩクライアントの機能を有しているとする。ユーザは、携帯電話キャリヤと契約する時に、家族用プレゼンスサービス提供の有無を選択し、自分の勤めている企業のグループＵＲＩへの転送依頼を行う。プライベートモードと、ビジネスモードの切り替えは、例えば携帯電話にモードボタンを配置し、モードボタンの押下によりプレゼンスサーバにモードを通知するようにする。あるいはモードそのものをプレゼンス情報としてプレゼンス情報通知時に一緒に登録するように構成する。

（４）ビジネスモード時は、プライベートなグループＵＲＩfamily@telephone.comと、企業のグループＵＲＩcompany@telephone.comの両方にプレゼンス情報を通知し、プライベートモード時は、プライベートなグループＵＲＩfamily@telephone.comにのみプレゼンス情報を通知するようなロジックを持つように、プレゼンスサーバのグループＵＲＩクライアント機能を構成する。

（５）ユーザが所有する携帯電話は、プレゼンスを提供するためのアプリケーションが起動しており、画面に表示されるステータスの中から選択または、ステータスボタンのようなものを配置し、ステータスボタン押下のたびに状態が変化するように構成する。

（６）今、ユーザがモードをビジネスモードにし、状態を打ち合わせ中にしたとする。モードと、状態は、携帯電話のメモリ上に記録され携帯電話がどこの基地局にいるかの電波による位置確認時に、メモリ上から参照され応答情報として返される。

（７）携帯電話キャリヤのロケーションサーバは、これらの応答を取り出し、ユーザのプレゼンスサービスクライアントとしてプレゼンスの登録を行う。
（８）携帯電話キャリヤのプレゼンスサーバは、（２）で示したグループＵＲＩの振り分けロジックにしたがって、グループＵＲＩへのプレゼンス通知を行う。この場合、モードはビジネスモードであるので、プライベートなグループＵＲＩfamily@telephone.comと、企業のグループＵＲＩcompany@telephone.comの両方に打ち合わせ中という状態の通知を行う。プライベートなグループＵＲＩfamily@telephone.comは、ユーザの家族のみがプレゼンスを共有するグループであり、家族全員のプレゼンスが集められている。家族のメンバーはこのグループＵＲＩにプレゼンス通知依頼を行うことで、家族全員の状態を知ることができる。ユーザの家族は、ユーザが打ち合わせ中であることを知り、緊急でない私的な通信を控えるべきだという判断を行うことができる。また、企業のグループＵＲＩcompany@telephone.comは仕事の仲間のプレゼンスを共有するグループである。ビジネスのパートナーは、常に変化するため、互いにプレゼンスの通知を依頼しあう形式では、メンバーの保守が煩雑な作業となる。グループＵＲＩcompany@telephone.comは、情報共有のためのＵＲＩであり、このグループＵＲＩ宛にプレゼンスを登録し、このグループＵＲＩにプレゼンスの通知依頼を行えば、関係者全員の情報を取得可能となるため、煩わしいメンバーの保守作業をユーザが行う必要がなくなる。

（９）ユーザがモードをプライベートモードにし、状態を空きにしたとする。
（１０）既に説明したように、プレゼンスサーバにプレゼンスが通知され、プライベートなグループＵＲＩfamily@telephone.comにのみ空きという状態が通知される。企業のグループＵＲＩcompany@telephone.comには、例えば、業務終了といった状態を送信し、再びユーザがモードをビジネスモードに変更するまで、プレゼンスを通知しないように構成する。

以上、２つのサービス例で示したように、情報配信や、情報共有を目的としたプレゼンスの通知先であるグループＵＲＩを設け、ユーザが目的に応じてグループＵＲＩにプレゼンスを通知するように構成することにより、既存の情報配信サービスのシステムでは、実現しがたい、ユーザの状況を考慮しつつ、軽量でフレキシブルな情報配信、情報共有が可能となる。

また、プレゼンス情報の提供者自らが自発的に、プレゼンス情報の登録先を選べる仕組みを導入することにより、プレゼンス情報の参照者が購読を行うことによりサービスを実行する既存の仕組みと違って、プレゼンス情報の共用に関してあらかじめユーザの同意を取ることが可能となるため、プレゼンス情報を複数のユーザで共用することが可能となり大規模イベント通知システムにおいて効率的にメッセージの交換数を減らすことが可能になる。その結果、何らかのプレゼンス情報を公開する見返りとして、プレゼンス情報を利用して何らかの付加価値サービスを享受するといった、単なるアウェアネスでの利用に限定されない、大規模な情報配信サービスの展開が可能となる。

また、その他のサービスへの適用として、以下に３つのサービスを示す。図３３はコミュニケーショングループへの適用例を示す図である。家族、自治体、ＰＴＡ、会社でそれぞれグループＵＲＩを作成する。ユーザは例えば、引越しなどで生活環境が変化した場合、自治体、ＰＴＡ、会社といったグループＵＲＩに加入するだけで、容易に関係者の情報等の連絡を受けることができる。

図３４は家電状態モニタへの適用例を示す図である。家電と家族のメンバでグループＵＲＩを構築し、家族の外出状況と、家電の状態とを同時に知ることができる。これにより、例えば、家族が全員外出しているのに、ポットや暖房機器のスイッチが入ったままといった情報を知ることができる。

図３５はホットスポットと連携した予約サービスへの適用例を示す図である。いくつかの無線ＬＡＮの設置場所（ホットスポット）でグループＵＲＩを作成し、各ホットスポットから登録されるプレゼンス情報をもとに、ユーザに様々なサービスを提供する。これにより、例えば、インターネットで予約し、その場所に到着したら決済され、行かなかったら自動的に予約がキャンセルされるといったサービスが可能になる。

上記については単に本発明の原理を示すものである。さらに、多数の変形、変更が当業者にとって可能であり、本発明は上記に示し、説明した正確な構成および応用例に限定されるものではなく、対応するすべての変形例および均等物は、添付の請求項およびその均等物による本発明の範囲とみなされる。

符号の説明

１ａプレゼンス通信システム
１０ａプレゼンスサーバ
２０−１〜２０−ｎプレゼンティティ
３０−１〜３０−ｎウォッチャー

Claims

複数のプレゼンス情報を含むグループに対応するグループ識別子を階層化構造とし、プレゼンス情報を、最上位階層のグループ識別子ですべてのプレゼンス情報が集約されるように、下位階層のグループ識別子に対応するプレゼンス情報を、下位階層から上位階層へ向けて階層毎に順に集約して蓄積し、かつ要求されたプレゼンス情報をグループ識別子毎に配信するプレゼンスサーバと、
前記プレゼンスサーバへ、グループ識別子毎にプレゼンス情報を提供するプレゼンス情報の提供クライアントと、
グループ識別子毎に要求したプレゼンス情報を、前記プレゼンスサーバから受信するプレゼンス情報の要求クライアントと、
を有することを特徴とするプレゼンス通信システム。
前記プレゼンスサーバは、プレゼンス情報を下位階層から上位階層へ向けて階層毎に順に集約する場合に、プレゼンス情報を絞り込んで、上位階層へ行くほど情報量を少なくさせることを特徴とする請求項１記載のプレゼンス通信システム。
プレゼンス通信方法において、
プレゼンスサーバは、複数のプレゼンス情報を含むグループに対応するグループ識別子を階層化構造とし、プレゼンス情報を、最上位階層のグループ識別子ですべてのプレゼンス情報が集約されるように、下位階層のグループ識別子に対応するプレゼンス情報を、下位階層から上位階層へ向けて階層毎に順に集約して蓄積し、かつ要求されたプレゼンス情報をグループ識別子毎に配信し、
提供クライアントは、前記プレゼンスサーバへ、グループ識別子毎にプレゼンス情報を提供し、
要求クライアントは、グループ識別子毎に要求したプレゼンス情報を、前記プレゼンスサーバから受信する、
ことを特徴とするプレゼンス通信方法。