JP3985954B2 - クライアント管理方法及び装置 - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明は、ネットワーク上のユーザが他のユーザのプレゼンス情報を参照するためのプレゼンスシステムに関する。
本発明において、プレゼンスシステムは、サーバとクライアントとを含む。サーバは、クライアントを操作するユーザエージェントのプレゼンス情報を蓄積し、他のクライアントに通知する。通知されるプレゼンス情報の所有者を、プレゼンティティと呼ぶ。プレゼンティティのプレゼンス情報を受信するクライアントの操作者を、ウォッチャーと呼ぶ。ここでプレゼンス情報とは、プレゼンティティに関する任意の情報であり、例えば状態を表すテキストメッセージ（以下、インスタントメッセージという）やアイコンファイル、住所や通信アドレスなどの個人情報が挙げられる。
【０００２】
【従来の技術】
インスタントメッセージは、送信したい相手の識別子さえわかれば送信可能である。近年、電子メール環境では、スパムと呼ばれる迷惑メールが問題となっている。プレゼンスシステムにおけるインスタントメッセージにも同様の問題がある。大抵の迷惑メッセージ送信者は、識別子をランダムに生成し、一度メッセージを送ってみる。成功したら、その識別子が有効なことを記憶し、次回送信時に利用する。そのため、通常のユーザエージェントにとっては、一度でも迷惑メッセージを受け取ってしまうと、次々に送られてくることになる。
【０００３】
この問題の第１の解決案としてアクセス制御機能を用いることが考えられる。この機能は基本的に、許可リスト、拒否リストの２種類のリストを用いる。許可リストには、ユーザエージェント自身へのメッセージの送信が許可されている他のユーザエージェントの識別子が登録される。この場合、許可リストに登録されていないユーザエージェントからのインスタントメッセージの受信は拒否される。従って迷惑なインスタントメッセージの量は軽減される。また、拒否リストには、ユーザエージェント自身へのメッセージの送信が拒否されている他のユーザエージェントの識別子が登録される。従って、例えば迷惑メッセージを送信してきたユーザエージェントを拒否リストに登録しておくことで、そこからの迷惑メッセージを以後は受信せずにすむ。
【０００４】
【発明が解決しようとする課題】
しかし、前述の第１の方法では、メッセージをもらう可能性のあるユーザエージェント全員を許可リストに登録しなければならない。また、大抵の迷惑メッセージ送信者は次々識別子を変えてくるので、拒否リストが意味をなさなくなってしまう。
【０００５】
そこで第２の方法として、ユーザエージェント自身の識別子を変更し、新規登録としてプレゼンスシステムの新たな識別子をもらうとともに、今まで使っていた識別子についてのサービス利用停止手続きを行う方法が考えられる。この方法を用いれば、ユーザエージェント自身の識別子の変更により迷惑メッセージの受信を防止できる利点がある。その一方で、プレゼンスシステム上で古い識別子に関連づけられていた様々な情報、例えばプレゼンス情報、バディリスト、アクセスレベルなどを、サービス利用停止処理により全て破棄することは好ましくない。
【０００６】
具体的には、プレゼンスシステム上のユーザエージェントＡが識別子を変更した場合、他のユーザエージェントＢから見ると古い識別子は使用不可能になり、新しい識別子を知る手段が存在しない。そのため、ユーザエージェントＢから識別子を変更したユーザエージェントＡを特定する手段がなくなってしまう。識別子を変更したユーザエージェントＡは、必要なユーザエージェント一人一人に識別子の変更を通知すれば良いが、手間と時間がかかり負担が大きい。
【０００７】
本発明では、プレゼンスシステムにおいてユーザエージェントの識別子を変更した場合に、ユーザエージェントに負担をかけることなくその変更を通知することを目的とする。
また本発明は、プレゼンスシステムにおいてユーザエージェントの識別子を変更した場合に、必要なユーザエージェントに変更後の識別子を自動的に通知することを目的とする。
【０００８】
【課題を解決するための手段】
発明１は、プレゼンス情報を提供するクライアント群を管理するクライアント管理方法であって、以下のＡ〜Ｈの要素を含むクライアント管理方法を提供する。
Ａ：第１クライアントを含む前記クライアント群のプレゼンス情報の設定を受け付け、クライアント毎に記憶するプレゼンス記憶ステップ、
Ｂ：前記クライアント群のプレゼンス情報の通知先であるクライアント（以下、単に監視クライアントという）の識別子を、プレゼンス情報を提供するクライアント毎に記憶する通知先記憶ステップ、
Ｃ：前記第１クライアントの識別子の変更を受け付ける識別子変更ステップ、
Ｄ：前記第１クライアントの識別子の変更に応じ、前記第１クライアントの監視クライアントの一部を抽出して識別子通知先に決定する決定ステップ、
Ｅ：前記識別子通知先に、前記第１クライアントの新たな識別子を通知する識別子送信ステップ、
Ｆ：前記クライアント群で送受信されるテキストメッセージの配信を管理するメッセージングステップ、
Ｇ：配信されるテキストメッセージの配信履歴を記憶する配信履歴ステップ、
Ｈ：前記決定ステップは、前記第１クライアントの監視クライアントの一部を前記配信履歴に基づいて抽出し、識別子通知先に決定する。
【０００９】
発明２は、プレゼンス情報を提供するクライアント群を管理するクライアント管理装置であって、
第１クライアントを含む前記クライアント群のプレゼンス情報の設定を受け付け、クライアント毎に記憶するプレゼンス記憶手段と、
前記クライアント群のプレゼンス情報の通知先であるクライアント（以下、単に監視クライアントという）の識別子を、プレゼンス情報を提供するクライアント毎に記憶する通知先記憶手段と、
前記第１クライアントの識別子の変更を受け付ける識別子変更手段と、
前記第１クライアントの識別子の変更に応じ、前記第１クライアントの監視クライアントの一部を抽出して識別子通知先に決定する決定手段と、
前記識別子通知先に、前記第１クライアントの新たな識別子を通知する識別子送信手段と、
前記クライアント群で送受信されるテキストメッセージの配信を管理するメッセージング手段と、
配信されるテキストメッセージの配信履歴を記憶する配信履歴手段と、を備え、
前記決定手段は、前記第１クライアントの監視クライアントの一部を前記配信履歴に基づいて抽出し、識別子通知先に決定する、を備えるクライアント管理装置を提供する。
【００１０】
発明３は、プレゼンス情報を提供するクライアント群を管理するクライアント管理プログラムを記録した、コンピュータ読み取り可能な記録媒体であって、
第１クライアントを含む前記クライアント群のプレゼンス情報の設定を受け付け、クライアント毎に記憶するプレゼンス記憶ステップと、
前記クライアント群のプレゼンス情報の通知先であるクライアント（以下、単に監視クライアントという）の識別子を、プレゼンス情報を提供するクライアント毎に記憶する通知先記憶ステップと、
前記第１クライアントの識別子の変更を受け付ける識別子変更ステップと、
前記第１クライアントの識別子の変更に応じ、前記第１クライアントの監視クライアントの一部を抽出して識別子通知先に決定する決定ステップと、
前記識別子通知先に、前記第１クライアントの新たな識別子を通知する識別子送信ステップと、
前記クライアント群で送受信されるテキストメッセージの配信を管理するメッセージングステップと、
配信されるテキストメッセージの配信履歴を記憶する配信履歴ステップと、を実行し、
前記決定ステップは、前記第１クライアントの監視クライアントの一部を前記配信履歴に基づいて抽出し、識別子通知先に決定する、クライアント管理プログラムを記録した、コンピュータ読み取り可能な記録媒体を提供する。
【００１１】
発明４は、前記発明３において、プレゼンス情報の提供元となるクライアント（以下、購読クライアントという）の識別子を、前記プレゼンス情報の提供先となるクライアントに対応付けて記憶する購読クライアント記憶ステップをさらに含み、前記決定ステップは、前記第１クライアントの監視クライアントであって、かつ前記第１クライアントの購読クライアントであるクライアントを識別子通知先に決定する、クライアント管理プログラムを記録したコンピュータ読み取り可能な記録媒体を提供する。
【００１２】
発明５は、前記発明３において、前記プレゼンス情報の設定に応じ、前記第１クライアントの監視クライアントに新たなプレゼンス情報を通知するプレゼンス通知ステップと、プレゼンス情報の通知履歴を記憶する通知履歴ステップと、をさらに含み、前記決定ステップは、前記第１クライアントの監視クライアントの一部を前記通知履歴に基づいて抽出し、識別子通知先に決定するクライアント管理プログラムを記録したコンピュータ読み取り可能な記録媒体を提供する。
【００１３】
発明６は、前記発明３において、前記プレゼンス記憶ステップは、前記クライアント群のプレゼンス情報の通知先を制限するアクセスレベルと関連づけて前記プレゼンス情報を記憶し、前記通知先記憶ステップは、各通知先クライアントのアクセスレベルをさらに記憶し、前記決定ステップは、各監視クライアントのアクセスレベルに基づいて、前記第１クライアントの監視クライアントの一部を識別子通知先に決定するクライアント管理プログラムを記録したコンピュータ読み取り可能な記録媒体を提供する。
【００１４】
発明７は、前記発明３において、前記識別子送信ステップが、前記識別子通知先のクライアントに、前記第１クライアントの識別子が変更されたことを表示するための表示データをさらに送信するクライアント管理プログラムを記録したコンピュータ読み取り可能な記録媒体を提供する。
発明８は、プレゼンス情報を提供するクライアント群を管理するクライアント管理方法であって、以下の要素を含むクライアント管理方法を提供する。
・第１クライアントを含む前記クライアント群のプレゼンス情報の設定を受け付け、クライアント毎に記憶するプレゼンス記憶ステップ、
・あるクライアントのプレゼンス情報の提供に関係する他のクライアントの識別子及び／またはその識別子を含むクライアント関係情報を、クライアント毎に記憶する情報記憶ステップ、
・前記第１クライアントの識別子の変更を受け付ける識別子変更ステップ、
・前記第１クライアントの識別子の変更に応じ、第１クライアントに対応づけて記憶されているクライアント関係情報に含まれるクライアントの一部を抽出して、識別子通知先に決定する決定ステップ、
・前記識別子通知先に、前記第１クライアントの新たな識別子を送信する識別子送信ステップ
・前記クライアント群で送受信されるテキストメッセージの配信を管理するメッセージングステップ、
・配信されるテキストメッセージの配信履歴を記憶する配信履歴ステップ、
・前記決定ステップは、前記第１クライアントの監視クライアントの一部を前記配信履歴に基づいて抽出し、識別子通知先に決定する。
【００１５】
【発明の実施の形態】
＜第１実施形態例＞
（１）基本構成
次に、本発明のクライアント管理方法をプレゼンスシステムのサーバに適用した場合を例に取り、説明する。図１は、本発明の第１実施形態例に係るサーバを含むプレゼンスシステムの全体構成例である。プレゼンスシステムは、ネットワーク３で接続されるサーバ１とクライアント２ａ、２ｂ、２ｃ・・・とを含んでいる。各クライアント２ａ、２ｂ、２ｃ・・・（以下、まとめてクライアント２）はユーザエージェントＡ、Ｂ、Ｃ・・・により操作される。また各クライアント２は、アカウント（識別子）により識別される。
【００１６】
サーバ１は、クライアント２のプレゼンス情報を管理している。このサーバ１は、プレゼンステーブル１１（プレゼンス記憶手段）、ウォッチャーテーブル１２（通知先記憶手段）、設定モジュール２１（プレゼンス記憶手段）、変更モジュール２４（識別子変更手段）、決定モジュール２５（決定手段）及び通知モジュール２６（識別子送信手段）を有している。
【００１７】
プレゼンステーブル１１は、クライアント毎にプレゼンス情報を記憶する。図２は、プレゼンステーブルの概念説明図である。
設定モジュール２１は、クライアント２からプレゼンス情報の設定を受け付け、プレゼンステーブル１１に登録する。
ウォッチャーリストテーブル１２は、クライアント２のプレゼンス情報の通知先クライアント（以下、単に監視クライアントという）のアカウントを、クライアント毎に記憶する。図３（ａ）、（ｂ）は、クライアント２ａを操作するユーザエージェントＡのウォッチャーリストを例示している。ここで、ユーザエージェントＡのアカウントは、同図（ａ）では“Ａ１”であるが、同図（ｂ）では“Ａ２”に変更されている。
【００１８】
変更モジュール２４は、クライアント２のアカウントの変更を受け付ける。例えば変更モジュール２４は、図４に例示するアカウント変更画面をクライアント２に提供し、アカウントの変更を受け付ける。図４は、クライアント２ａのアカウント“Ａ１”を“Ａ２”に変更する例を示している。以下、説明を容易にするために、ユーザエージェントＡが操作するクライアント２ａのアカウントを、“Ａ１”から“Ａ２”に変更する場合を例に取り説明する。
【００１９】
変更モジュール２４は、アカウントの変更に加えてそれに関連する他の属性情報の登録をさらに受け付けてもよい。例えば、変更モジュール２４は、図７に例示する画面をクライアント２ａに提供し、新アカウントの設定及びアカウントの変更理由の設定を受け付ける。また変更モジュール２４は、受け付けた属性情報を、新アカウントとともに通知先に通知することができる。図８は、この通知により通知先クライアントが表示する属性情報の表示画面例である。この画面は、新たなアカウント“Ａ２”と変更理由とを表示している。
【００２０】
また変更モジュール２４は、ユーザエージェントＡが設定していない属性情報を、通知先クライアントに送信しても良い。図９は、このような属性情報の表示画面例である。この例では、属性情報として、通知先クライアントがユーザエージェントＡのウォッチャーであったために新アカウントが通知されたことが表示されている。通知先クライアントを操作するユーザエージェントは、なぜアカウントが変更されたかや、なぜ自分に新アカウントが通知されたかなどを知ることができる利点がある。
【００２１】
決定モジュール２５は、クライアント２ａのアカウントの変更に応じ、ユーザエージェントＡのウォッチャーが操作するクライアント（以下、監視クライアントという）の全部または一部を、新アカウント“Ａ２”の通知先とし、通知先リスト（図示せず）を生成する。決定モジュール２５は、通知先リストに含まれている監視クライアントを操作するウォッチャーだけを含むように、ウォッチャーリストテーブル１２を更新しても良い。そのようなウォッチャーは、ユーザエージェントＡとの関係が密であると考えられるからである。
【００２２】
通知モジュール２６は、通知先リストに含まれているクライアントにアカウント変更通知を送信することにより、クライアント２ａの新アカウント“Ａ２”を通知する。図５は、アカウント変更通知を受けたクライアントが表示する画面例を示す。この例では、ユーザエージェントＡ（図中、Ａさんと表示）のアカウントの表記が、“Ａ１”から“Ａ２”に変更されている。通知モジュール２６は、前記通知先クライアントに、クライアント２ａのアカウントが変更されたことを表示する画面データを提供してもよい。図６は、この画面データに基づいて通知先クライアントが表示する画面例を示す。この画面例では、クライアント２ａのアカウントの変更及び新アカウント“Ａ２”が表示されている。
【００２３】
このサーバ１は、ユーザエージェントＡが自分のアカウントを変更した場合、新アカウントの通知先を自動的に決定及び通知する。新アカウントの通知先の範囲は、ユーザエージェントＡのウォッチャーが操作する監視クライアントを最大範囲とする。新アカウントの通知先は、ユーザエージェントＡと通知先のユーザエージェントとの人間関係を考慮し、不要な通知先が含まれないように決定することが好ましい。ユーザエージェントＡのウォッチャーは、ユーザエージェントＡのプレゼンス情報の通知先であるから、ユーザエージェントＡが信用しており、新アカウントを通知したいと思っていると推定できる。また、ユーザエージェントＡのプレゼンス情報を見せるウォッチャー以外に新アカウントを通知する必要性は乏しいと推定できる。
【００２４】
（２）ウォッチャーの一部に通知する構成
決定モジュール２５は、クライアント２ａのアカウントの変更に応じ、クライアント２ａの監視クライアントの一部を抽出して通知先リストを生成しても良い。
ユーザエージェントＡは、必ずしもウォッチャー全員に新アカウントを通知したくない場合がある。そこで新アカウントの通知が不要と推定できるウォッチャーを除いた一部のウォッチャーを抽出し、通知先リストを生成しても良い。抽出方法としては、例えば、ａ）ユーザエージェントＡのプレゼンス情報を頻繁に通知しているウォッチャーを抽出する方法、ｂ）ユーザエージェントＡにプレゼンス情報を頻繁に通知しているウォッチャーを抽出する方法、が挙げられる。いかに、一部のウォッチャーを抽出する方法について、再び図１〜３を参照しながら具体例を挙げて説明する。
【００２５】
（２−１）バディであるウォッチャーを抽出
図１に例示するように、サーバ１にバディリストテーブル１３を設けてもよい。決定モジュール２５は、クライアント２ａの監視クライアントでありかつユーザエージェントＡのバディが操作するクライアント（以下、購読クライアントという）であるクライアントを、新アカウントの通知先としてもよい。ここでユーザエージェントＡのバディとは、ユーザエージェントＡがそのプレゼンス情報の通知を希望しているユーザエージェントである。
【００２６】
バディリストテーブル１３は、各クライアント毎にバディリストを蓄積している。図３は、ユーザエージェントＡのバディリストを例示している。ここでは、ユーザエージェントＡは、アカウント“Ｃ１”及び“Ｄ１”で識別されるクライアントをバディに指定している。
例えば図３では、ユーザエージェントＡのウォッチャーでありバディであるユーザエージェントが操作するクライアント２のアカウントは“Ｃ１”である。この場合、決定モジュール２５は、“Ｃ１”で識別されるクライアントを、新アカウント“Ａ２”の通知先とする。
【００２７】
バディは、ユーザエージェントＡが興味を持つユーザエージェントであると考えられる。ウォッチャーかつバディであるユーザエージェントを新アカウントの通知先とすれば、ユーザエージェントＡとの人的関係が強いユーザエージェントを、ウォッチャーから選択的に抽出できる可能性が高いと期待できる。これにより、新アカウントの通知先として不適切なウォッチャーに、新アカウントを通知せずにすむ。例えば、ユーザエージェントＡに自分のプレゼンス情報の通知を許可していないウォッチャーには新アカウントを通知せずにすむ。
【００２８】
（２−２）プレゼンス通知履歴に基づいてウォッチャーを抽出
図１に例示するように、配信モジュール２２と、抽出情報テーブル１４と、をサーバ１にさらに設けてもよい。
配信モジュール２２は、クライアント２からプレゼンス情報の設定を受け付け、そのクライアントの監視クライアントに新たなプレゼンス情報を配信する（以下、プレゼンス通知という）。プレゼンス通知を受信した監視クライアント２は、前記図５に例示するように、プレゼンス情報を表示したり、プレゼンス情報の表示を更新する。
【００２９】
抽出情報テーブル１４は、ウォッチャーの一部を抽出するための情報を蓄積している。図３に示すように、抽出情報テーブル１４は、例えばプレゼンス通知を送受信した履歴を示すプレゼンス受信リスト１４２やプレゼンス送信リスト１４３を蓄積している。プレゼンス受信リスト１４２は、クライアント２ａが、そこからプレゼンス情報を受信したクライアント（以下、プレゼンス受信クライアントという）のアカウント、受信回数、受信時刻など、プレゼンス通知の受信履歴を示すデータを含む。プレゼンス送信リスト１４３は、クライアント２ａが、自己のプレゼンス情報を送信したクライアント（以下、プレゼンス送信クライアントという）のアカウント、送信回数、送信時刻など、プレゼンス通知の送信履歴を示すデータを含む。
【００３０】
決定モジュール２５は、クライアント２ａの監視クライアントでありかつプレゼンス受信クライアントであるクライアントを前記プレゼンス受信リスト１４２に基づいて抽出し、新アカウントの通知先としてもよい。また、監視クライアントであって、しかもプレゼンス通知の受信回数や受信頻度が高いプレゼンス受信クライアントだけを、通知先としても良い。さらに、そのようなプレゼンス受信クライアントであって、かつ購読クライアントであるクライアントを通知先とすることも考えられる。
【００３１】
同様に、決定モジュール２５は、クライアント２ａの監視クライアントであってプレゼンス送信クライアントであるクライアントを前記プレゼンス送信リスト１４２に基づいて抽出し、新アカウントの通知先としてもよい。また、監視クライアントであって、しかもプレゼンス通知の送信回数や送信頻度が高いプレゼンス送信クライアントだけを、通知先としても良い。さらに、そのようなプレゼンス送信クライアントであって、かつ購読クライアントであるクライアントを通知先とすることも考えられる。さらに前述のプレゼンス受信クライアントであることを、通知先の要件に加えることも可能である。
【００３２】
図３の例では、抽出情報テーブル１４は判断基準値リスト１４１をさらに含んでいる。決定モジュール２５は、例えば、ウォッチャーリスト１２、プレゼンス通知の送受信履歴１４２，１４３及び判断基準値リスト１４１に基づいて、通知先リストを生成する。判断基準値リスト１４１には各種のしきい値が蓄積されている。例えば、回数、頻度などのしきい値である。この例では、「回数」のしきい値は１０回である。プレゼンス受信クライアントのうち受信回数が１０回以上であり、かつ監視クライアントであるクライアント“Ｃ１”を、決定モジュール２５は通知先として抽出することができる。また、プレゼンス送信クライアントのうち送信回数が１０回以上であり、かつ監視クライアントであるクライアント“Ｃ１”を、決定モジュール２５は通知先として抽出することができる。なお、図３の例では、抽出された通知先からなる通知先リストを、新たなウォッチャーリスト１２に置き換えている。
【００３３】
プレゼンス通知の送受信履歴をウォッチャーの抽出に用いれば、不要なクライアントへ新アカウントを通知することを防止できる。例えばユーザエージェントＸがユーザエージェントＡのウォッチャーかつバディであっても、そのプレゼンス情報が変化しない場合、ユーザエージェントＸのプレゼンス通知はユーザエージェントＡに送信されない。このようなユーザエージェントＸには新アカウントを通知する必要性が比較的低いと想定できる。
【００３４】
（２−３）メッセージング履歴に基づいてウォッチャーを抽出
図１に例示するように、ＩＭ（Instant Message）モジュール２３と、抽出情報テーブル１４と、をサーバ１にさらに設けてもよい。
ＩＭモジュール２３は、クライアント２からテキストメッセージの設定とその送信先の指定とを受け付け、送信先にテキストメッセージを配信する。
【００３５】
抽出情報テーブル１４は、ウォッチャーの一部を抽出するための情報を蓄積している。図３に示すように、抽出情報テーブル１４は、例えばテキストメッセージを送受信した履歴を示すメッセージ受信リスト１４４やメッセージ送信リスト１４５を蓄積している。メッセージ受信リスト１４４は、クライアント２ａが、そこからのテキストメッセージを受信したクライアント（以下、メッセージ受信クライアントという）のアカウント、受信回数、受信時刻など、テキストメッセージの受信履歴を示すデータを含む。メッセージ送信リスト１４５は、クライアント２ａがテキストメッセージを送信したクライアント（以下、メッセージ送信クライアントという）のアカウント、送信回数、送信時刻など、テキストメッセージの送信履歴を示すデータを含む。
【００３６】
決定モジュール２５は、クライアント２ａの監視クライアントであってメッセージ受信クライアントであるクライアントを前記メッセージ受信リスト１４４に基づいて抽出し、新アカウントの通知先としてもよい。また、監視クライアントであって、しかもテキストメッセージの受信回数や受信頻度が高いメッセージ受信クライアントだけを、通知先としても良い。さらに、そのようなメッセージ受信クライアントであって、かつ購読クライアントであるクライアントを通知先とすることも考えられる。
【００３７】
同様に、決定モジュール２５は、クライアント２ａの監視クライアントであってメッセージ送信クライアントであるクライアントを前記メッセージ送信リスト１４５に基づいて抽出し、新アカウントの通知先としてもよい。また、監視クライアントであって、しかもテキストメッセージの送信回数や送信頻度が高いメッセージ送信クライアントだけを、通知先としても良い。さらに、そのようなメッセージ送信クライアントであって、かつ購読クライアントであるクライアントを通知先とすることも考えられる。
【００３８】
図３の例では、抽出情報テーブル１４に判断基準値リスト１４１が含まれている。決定モジュール２５は、ウォッチャーリスト１２、メッセージの送受信履歴１４４，１４５及び判断基準値リスト１４１に基づいて、通知先リストを生成する。判断基準値リスト１４１には各種のしきい値、例えば回数のしきい値“１０”が蓄積されている。この例では、メッセージ受信クライアントのうち受信回数が１０回以上であり、かつ監視クライアントであるクライアント“Ｃ１”、“Ｙ１”を、決定モジュール２５が通知先として抽出することができる。またメッセージ送信クライアントのうち送信回数が１０回以上であり、かつ監視クライアントであるクライアント“Ｃ１”を、決定モジュール２５が通知先として抽出することができる。
【００３９】
ユーザエージェントＡとテキストメッセージを送受信したことのあるユーザエージェントは、ユーザエージェントＡと関係が比較的密であると推定できる。そこで、このようなユーザエージェントであってユーザエージェントのウォッチャーでもあるユーザエージェントには、新アカウントを通知することが適当と推察できる。
【００４０】
（２−４）アクセスレベルに応じてウォッチャーを抽出
図２に例示するように、プレゼンステーブル１１は、クライアント２のプレゼンス情報の通知先を制限するアクセスレベルと関連づけてプレゼンス情報を記憶してもよい。アクセスレベルとは、プレゼンス情報の開示度を示す。図２では、クライアント２はアクセスレベル毎にプレゼンス情報を設定することができる。
【００４１】
プレゼンステーブル１１にアクセスレベルが設定される場合、図３に例示するように、ウォッチャーリストテーブル１２は各ウォッチャーのアクセスレベルをさらに記憶することが好ましい。各ウォッチャーのアクセスレベルは、プレゼンス情報をウォッチャーに提供するプレゼンティティにより設定される。図３では、ユーザエージェントＡがプレゼンティティである。
【００４２】
この場合、決定モジュール２５は、各ウォッチャーのアクセスレベルに基づいて、クライアント２ａの監視クライアントの全部または一部を新アカウントの通知先に決定することができる。例えば、図３に示すように抽出情報テーブル１４に判断基準値リスト１４１を持たせ、ここにアクセスレベルのしきい値「２」を登録しておく。図３の例では、決定モジュール２５は、アクセスレベルの値が２以下のウォッチャーが操作するクライアント“Ｂ１”、“Ｃ１”、“Ｙ１”を、新アカウントの通知先として抽出する。
【００４３】
アクセスレベルは、ユーザエージェントＡの信頼度を示すと推定できる。アクセスレベルが高いユーザエージェントのクライアントを新アカウントの通知先とするなど、アクセスレベルに基づいて通知先を制御することにより、アカウントの不要な通知を防止することができる。
（２−５）その他の抽出
ウォッチャーリストテーブル１２に応じて抽出情報テーブル１４に様々な値を設定すれば、様々な方法で適正なウォッチャーを通知先として抽出可能である。図３に例示するように、ウォッチャーリストテーブル１２が、「表示フラグ」、「表示順序」、「表示色」を記憶している場合、抽出情報テーブル１４の判断基準値リスト１４１にこれらに対応する基準値を設定することができる。図３は、判断基準値リスト１４１の設定の一例を示す。この図は、「表示フラグ」がオンの監視クライアントを通知先として抽出する設定を示している。この例では、表示順序及び表示色に基づく抽出を行っていないが、これらによる通知先の抽出も可能である。例えば表示順序を２番までに設定すれば、この例ではクライアント“Ｂ１”、“Ｃ１”が通知先になる。また表示色を青に設定すれば、この例ではクライアント“Ｂ１”が通知先になる。
【００４４】
また別の方法として、ウォッチャーリストテーブル１２が、前記図３に示すように「経過時間」を記憶している場合、抽出情報テーブル１４の判断基準値リスト１４１に経過時間のしきい値を設定することができる（図示せず）。例えば、「経過時間」がクライアント２ａの監視クライアントとなってからの時間を示している場合、経過時間が一定以上の監視クライアントを通知先として抽出することができる。経過時間が長い監視クライアントのユーザエージェントは、ユーザエージェントＡと古くからつきあいがあると推測できる。そこで古くからの監視クライアントにアカウントを通知し、つきあいの浅いと考えられる監視クライアントを通知対象から除外しても良い。
【００４５】
さらに別の方法として、ウォッチャーリストテーブル１２が、前記図３に示すように「回数」を記憶している場合、抽出情報テーブル１４の判断基準値リスト１４１に回数のしきい値を設定することができる。例えば、「回数」がクライアント２ａのプレゼンス情報の通知回数を示している場合、通知回数が一定以上の監視クライアントを通知先として抽出することができる。このようなクライアントは、ユーザエージェントＡとの人的関係が比較的強いと考えられるからである。
【００４６】
以上は、新アカウントの通知先として適切なウォッチャーを抽出する判断基準及び抽出方法の一例である。これらの判断基準及び抽出方法は適宜組み合わせて用いることができる。またニーズに応じて適宜他の判断基準及び抽出方法を適用してもよい。
（３）変更通知先のクライアント
アカウントの変更通知を受けたクライアントは例えば次のように動作する。クライアント２ａのアカウントの変更通知を、ユーザエージェントＢが操作するクライアント２ｂが受けたとする。クライアント２ｂは、記憶している各種情報に、アカウントの変更通知に含まれる変更前のアカウント“Ａ１”が含まれているか否かを検索する。ここでは、ユーザエージェントBは、ユーザエージェントAのアカウント“Ａ１”をバディリストに登録しており、さらにアクセスレベルを設定していたとする。
【００４７】
クライアント２ｂは、アカウントの変更通知を受信した際に、バディリストやアクセスレベルに登録されているアカウント“Ａ１”を、自動的に通知された新しいアカウント“Ａ２”に変更してもよい。また、クライアント２ｂは、前記図6に示すように、変更通知があったアカウント“Ａ１”が含まれている情報種別を画面に表示してもよい。クライアント２ｂは、この画面上で、変更を反映する情報種別の選択をユーザエージェントＢから受け付けた後、画面にて指示された情報についてのみアカウント“Ａ２”に変更してもよい。
【００４８】
（４）処理の流れ
図１０は、サーバ１が行う通知処理の流れの一例を示すフローチャートである。説明を容易にするために、ここでは抽出情報テーブル１４が図３に例示する内容であり、前記に例示したいずれかの判断基準を満たすウォッチャーを通知先とする処理を例に挙げて説明する。
【００４９】
ステップＳ１：変更モジュール２４は、任意のクライアントアカウントの変更要求があった場合、ステップＳ２に移行する。ここではクライアント２ａからアカウントの変更要求があったと仮定する。
ステップＳ２：決定モジュール２５は、ウォッチャーリストテーブル１２から、クライアント２ａのウォッチャーリストを読み出す。
【００５０】
ステップＳ３：決定モジュール２５は、ウォッチャーリストに含まれている監視クライアントのいずれかを、カレントウォッチャーとする。
ステップＳ４：決定モジュール２５は、カレントウォッチャーがいずれかの判断基準を満たしているかどうかを判断する。カレントウォッチャーが、ユーザエージェントのバディである、アクセスレベルの値が２以下である、などの判断基準のいずれかを満たす場合、ステップＳ５に移行する。カレントウォッチャーがいずれの判断基準も満たさない場合、ステップＳ３に戻り、他のウォッチャーをカレントウォッチャーとして前記判断を繰り返す。
【００５１】
ステップＳ５：決定モジュール２５は、カレントウォッチャーを通知先リストに追加する。
ステップＳ６：決定モジュール２５は、ユーザエージェントＡの全てのウォッチャーの監視クライアントについて、ステップＳ４の判断を行ったか否かを判断する。“Ｙｅｓ”と判断するとステップＳ７に移行する。“Ｎｏ”と判断するとステップＳ３に戻り、他の監視クライアントをカレントウォッチャーとして前記のステップＳ３〜Ｓ５を繰り返す。
【００５２】
ステップＳ７：決定モジュール２５は、通知先リストに含まれるクライアントだけを含むように、ウォッチャーリストテーブル１２を更新する。
ステップＳ８：通知モジュール２６は、更新されたウォッチャーリストに含まれるクライアントに対し、クライアント２ａの新アカウントを通知する。このとき、通知の理由などの属性情報を合わせて通知することも可能である。
【００５３】
＜その他の実施形態例＞
（Ａ）次のようにしてユーザエージェントＡの新アカウント“Ａ２”の通知先を決定しても良い。まず、サーバ１にテキストメッセージの転送機能を持たせ、ユーザエージェント毎の転送先リストをサーバ１に蓄積しておく（図示せず）。ユーザエージェントＡのアカウントが変更されると、ユーザエージェントＡの転送先として登録されているユーザエージェントを、新たなアカウント“Ａ２”の通知先に決定する。
【００５４】
（Ｂ）ユーザエージェントＡの新アカウントを通知されたユーザエージェントＢは、新たなアカウント“Ａ２”に対し、再度プレゼンス情報の通知を依頼しても良い。ユーザエージェントＡのプレゼンス情報を、アカウント変更後も確実に取得することができる。
（Ｃ）新アカウントの通知先を、ウォッチャーリストの中から、あるいはウォッチャーでありバディでもあるユーザエージェントリストの中から、手動で選択可能にしても良い。この選択は、個人単位でも、またグループ単位でも可能である。図１１（ａ）は、ウォッチャーリストの中から新アカウントの通知先を選択するための画面例である。図１１（ｂ）は、ウォッチャーでもありバディでもあるユーザグループの中から、新アカウントの通知先を選択するための画面例である。
【００５５】
（Ｄ）前述のプレゼンスシステムは、一般にサーバ−クライアント構成を取るが、本発明はその構成に依存しない。クライアント同士がプレゼンス情報を交換する、いわゆるP2P構成にも適用可能である。
（Ｅ）上記実施形態例では、ウォッチャーリストに登録された情報に基づいて、アカウントの通知先を決定している。しかし、バディリストを参照し、バディリストに登録されているクライアントのアカウントをアカウント通知先に決定してもよい。
【００５６】
これにより、クライアント２ａのプレゼンスを参照している如何に関わらず、クライアントＡが認知している他のクライアント２ｂ，２ｃ・・・のみに、クライアント２ａのアカウントの変更通知を行うことが可能となる。不当にクライアント２ａのプレゼンス情報を参照していた他のクライアント２ｘ（図示せず）には、アカウントの変更通知は行われないので、クライアント２ａにとって不当なウォッチャーの排除が可能となる。
【００５７】
また、クライアント２ａが自己のプレゼンス情報の参照を許可する他のクライアント２ｄ，２ｅ・・・を登録している許可リストを利用することにより、バディリストに登録されていない他のクライアント２ｄ，２ｅ・・・（図示せず）に対しても、アカウントの変更を通知することが可能となる。許可リストに登録されているクライアント２ｄ，２ｅ・・・は、クライアント２ａが自己のプレゼンス情報の参照を認めているクライアントであるから、クライアント２ａ自身のアカウントを認識していてもよいクライアントとなる。プレゼンス情報の参照関係の有無に関わらず、クライアント２ａが自己のアカウントを知らせてよいクライアントが、アカウントの変更通知先として選定されることになる。
【００５８】
クライアントＡ自身のプレゼンス情報の通知を拒否する拒否リストに登録されているクライアント２ｙ，２ｚ・・・（図示せず）は、アカウントの変更通知先にはなりえないクライアントの集合と言える。拒否リストは、様々な情報に基づいて抽出された変更通知先のクライアントに、通知すべきでないクライアントが含まれていないかをチェックするために利用すると有効である。変更通知先として抽出されたクライアントが拒否リストに含まれていないを確認し、含まれている場合は、変更通知先から除外する。これにより、変更通知すべきでないクライアントを自動的に排除することが可能となる。
【００５９】
過去のプレゼンス情報やメッセージの送受信相手のクライアントを記憶した履歴情報は、クライアントと通信相手のクライアントとの関係の親密度を推測可能なデータであると言える。履歴情報から、プレゼンス情報やメッセージの送信あるいは受信の頻度や時間間隔を分析し、例えば、頻度の多いクライアント、時間間隔の狭いクライアントを、変更通知先として抽出する。これにより、アカウントの変更通知時点でのクライアントと通信相手のクライアントとの関係に応じて、変更通知先の選定が可能となる。
【００６０】
（Ｆ）前述した本発明の方法を実行するプログラムを記録した記録媒体は、本発明に含まれる。ここで記録媒体としては、コンピュータが読み書き可能なフレキシブルディスク、ハードディスク、半導体メモリ、ＣＤ−ＲＯＭ、ＤＶＤ、光磁気ディスク（ＭＯ）、その他のものが挙げられる。
＜付記＞
（付記１）
プレゼンス情報を提供するクライアント群を管理するクライアント管理方法であって、
第１クライアントを含む前記クライアント群のプレゼンス情報の設定を受け付け、クライアント毎に記憶するプレゼンス記憶ステップと、
前記クライアント群のプレゼンス情報の通知先であるクライアント（以下、単に監視クライアントという）の識別子を、プレゼンス情報を提供するクライアント毎に記憶する通知先記憶ステップと、
前記第１クライアントの識別子の変更を受け付ける識別子変更ステップと、
前記第１クライアントの識別子の変更に応じ、前記第１クライアントの監視クライアントを識別子通知先に決定する決定ステップと、
前記識別子通知先に、前記第１クライアントの新たな識別子を送信する識別子送信ステップと、
を含むクライアント管理方法。
【００６１】
ユーザエージェントＡが操作するクライアントの識別子を変更した場合、新たな識別子の通知先を自動的に決定し、通知する。新たな識別子の通知先は、ユーザエージェントＡとの関係を考慮し、不要な通知先が含まれないように決定することが好ましい。そのため、識別子通知先の範囲は、ユーザエージェントＡのウォッチャーを最大範囲とする。ウォッチャーは、ユーザエージェントＡのプレゼンス情報の通知先であるから、それ以上に識別子を通知する必要性に乏しいと推定できるからである。
【００６２】
（付記２）
前記決定ステップは、前記第１クライアントの識別子の変更に応じ、前記第１クライアントの監視クライアントの一部を抽出して識別子通知先に決定する、付記１に記載のクライアント管理方法。
ユーザエージェントＡは、必ずしもウォッチャー全員に新識別子を通知したくない場合がある。そこで識別子の通知が不要と推定できるウォッチャーを除いた一部のウォッチャーを抽出し、識別子通知先とする。抽出方法としては、例えば、ａ）ユーザエージェントＡのプレゼンス情報を頻繁に通知しているウォッチャーを抽出する方法、ｂ）ユーザエージェントＡにプレゼンス情報を頻繁に通知しているウォッチャーを抽出する方法、が挙げられる。
【００６３】
（付記３）
プレゼンス情報の提供元となるクライアント（以下、購読クライアントという）の識別子を、前記プレゼンス情報の提供先となるクライアントに対応付けて記憶する購読クライアント記憶ステップをさらに含み、
前記決定ステップは、前記第１クライアントの監視クライアントであって、かつ前記第１クライアントの購読クライアントであるクライアントを、識別子通知先に決定する、
付記２に記載のクライアント管理方法。
【００６４】
ユーザエージェントＡは、必ずしもウォッチャー全員に新識別子を通知したくない場合がある。そこで、ユーザエージェントＡのバディかつウォッチャーであるユーザエージェントを、識別子通知先とする。これにより、識別子通知先として不適切なウォッチャーに新識別子を通知せずにすむ。不適切なウォッチャーとは、例えばユーザエージェントＡに自分のプレゼンス情報の通知を許可していないウォッチャーが挙げられる。
【００６５】
（付記４）
前記プレゼンス情報の設定に応じ、前記第１クライアントの監視クライアントに新たなプレゼンス情報を通知するプレゼンス通知ステップと、
プレゼンス情報の通知履歴を記憶する通知履歴ステップと、をさらに含み、
前記決定ステップは、前記第１クライアントの監視クライアントの一部を前記通知履歴に基づいて抽出し、識別子通知先に決定する、
付記２に記載のクライアント管理方法。
【００６６】
この方法において、前記決定ステップは、前記第１クライアントの監視クライアントの一部を前記通知履歴に基づいて抽出し、識別子通知先に決定する。
例えば、ユーザエージェントＡのウォッチャーであるユーザエージェントのうち、過去にプレゼンス情報を通知してくれているユーザエージェントに、新識別子を通知する。例えばユーザエージェントＸのプレゼンス情報が変化しない場合、仮にこのユーザエージェントＸがユーザエージェントＡのバディであってもそのプレゼンス情報はユーザエージェントＡに送信されない。このようなユーザエージェントＸには、識別子を通知する必要性が比較的低いと想定できる。
【００６７】
（付記５）
前記クライアント群で送受信されるテキストメッセージの配信を管理するメッセージングステップと、
配信されるテキストメッセージの配信履歴を記憶する配信履歴ステップと、をさらに含み、
前記決定ステップは、前記第１クライアントの監視クライアントの一部を前記配信履歴に基づいて抽出し、識別子通知先に決定する、
付記２に記載のクライアント管理方法。
【００６８】
ユーザエージェントＡは、必ずしもウォッチャー全員に新識別子を通知したくない場合がある。そこで例えば、ウォッチャーであって、テキストメッセージをユーザエージェントＡとやりとりしたことのあるユーザエージェントのクライアントを、識別子通知先とする。このようなユーザエージェントは、ユーザエージェントＡと関係が比較的密であると推定できるからである。ユーザエージェントＡとテキストメッセージをやりとりしている頻度や回数に応じ、識別子通知先とするかどうかを決定することもできる。
【００６９】
（付記６）
前記プレゼンス記憶ステップは、前記クライアント群のプレゼンス情報の通知先を制限するアクセスレベルと関連づけて前記プレゼンス情報を記憶し、
前記通知先記憶ステップは、各通知先クライアントのアクセスレベルをさらに記憶し、
前記決定ステップは、各監視クライアントのアクセスレベルに基づいて、前記第１クライアントの監視クライアントの一部を識別子通知先に決定する、
付記２に記載のクライアント監視方法。
【００７０】
ユーザエージェントＡは、必ずしもウォッチャー全員に新識別子を通知したくない場合がある。そこで、ウォッチャーであって、例えばアクセスレベルが高いユーザエージェントのクライアントを、識別子通知先とすることが考えられる。アクセスレベルに応じて識別子を通知するか否かを調整することにより、不要な識別子の通知を防止することができる。
【００７１】
（付記７）
前記識別子送信ステップは、前記識別子通知先のクライアントに、前記第１クライアントの識別子が変更されたことを表示するための表示データをさらに送信する、付記１に記載のクライアント管理方法。
識別子通知先のクライアントを操作するユーザエージェントに、そのユーザエージェントが監視しているユーザエージェントＡの識別子が変更したことを知らしめることができる。
【００７２】
（付記８）
前記識別子送信ステップは、前記識別子通知先のクライアントに、識別子の変更に関連する属性情報をさらに送信する、付記１に記載のクライアント管理方法。
属性情報としては、例えばアカウントを変更する理由を述べたテキストメッセージや、通知先として抽出した理由を述べたテキストメッセージが挙げられる。識別子通知先となったクライアントを操作するユーザエージェントは、なぜ識別子が変更されたかや、なぜ自分に新識別子が通知されたかなどを知ることができる。
【００７３】
（付記９）
前記識別子変更ステップは、前記属性情報の登録をさらに受け付ける、付記８に記載のクライアント管理方法。
識別子を変更するユーザエージェントは、例えば変更の理由などを、新識別子とともに自分の知り合いに通知することができる。
【００７４】
（付記１０）
プレゼンス情報を提供するクライアント群を管理するクライアント管理装置であって、
第１クライアントを含む前記クライアント群のプレゼンス情報の設定を受け付け、クライアント毎に記憶するプレゼンス記憶手段と、
前記クライアント群のプレゼンス情報の通知先であるクライアント（以下、単に監視クライアントという）の識別子を、プレゼンス情報を提供するクライアント毎に記憶する通知先記憶手段と、
前記第１クライアントの識別子の変更を受け付ける識別子変更手段と、
前記第１クライアントの識別子の変更に応じ、前記第１クライアントの監視クライアントを識別子通知先に決定する決定手段と、
前記識別子通知先に、前記第１クライアントの新たな識別子を送信する識別子送信手段と、
を備えるクライアント管理装置。
【００７５】
この発明は、前記第１発明と同様の作用効果を奏する。
（付記１１）
プレゼンス情報を提供するクライアント群を管理するクライアント管理プログラムを記録した、コンピュータ読み取り可能な記録媒体であって、
第１クライアントを含む前記クライアント群のプレゼンス情報の設定を受け付け、クライアント毎に記憶するプレゼンス記憶ステップと、
前記クライアント群のプレゼンス情報の通知先であるクライアント（以下、単に監視クライアントという）の識別子を、プレゼンス情報を提供するクライアント毎に記憶する通知先記憶ステップと、
前記第１クライアントの識別子の変更を受け付ける識別子変更ステップと、
前記第１クライアントの識別子の変更に応じ、前記第１クライアントの監視クライアントを識別子通知先に決定する決定ステップと、
前記識別子通知先に、前記第１クライアントの新たな識別子を送信する識別子送信ステップと、
を実行するクライアント管理プログラムを記録した、コンピュータ読み取り可能な記録媒体。
【００７６】
この発明は、前記第１発明と同様の作用効果を奏する。
（付記１２）
プレゼンス情報を提供するクライアント群を管理するコンピュータが実行するクライアント管理プログラムであって、
第１クライアントを含む前記クライアント群のプレゼンス情報の設定を受け付け、クライアント毎に記憶するプレゼンス記憶手段、
前記クライアント群のプレゼンス情報の通知先であるクライアント（以下、単に監視クライアントという）の識別子を、プレゼンス情報を提供するクライアント毎に記憶する通知先記憶手段、
前記第１クライアントの識別子の変更を受け付ける識別子変更手段、
前記第１クライアントの識別子の変更に応じ、前記第１クライアントの監視クライアントを識別子通知先に決定する決定手段、及び
前記識別子通知先に、前記第１クライアントの新たな識別子を送信する識別子送信手段、
として前記コンピュータを機能させるクライアント管理プログラム。
【００７７】
この発明は、前記第１発明と同様の作用効果を奏する。
（付記１３）
プレゼンス情報を提供するクライアント群を管理するクライアント管理方法であって、
第１クライアントを含む前記クライアント群のプレゼンス情報の設定を受け付け、クライアント毎に記憶するプレゼンス記憶ステップと、
あるクライアントのプレゼンス情報の提供に関係する他のクライアントの識別子及び／または前記クライアントからのプレゼンス情報の提供要求に関係する他のクライアントの識別子を含むクライアント関係情報を、クライアント毎に記憶する情報記憶ステップと、
前記第１クライアントの識別子の変更を受け付ける識別子変更ステップと、
前記第１クライアントの識別子の変更に応じ、第１クライアントに対応づけて記憶されているクライアント関係情報に含まれるクライアントを、識別子通知先に決定する決定ステップと、
前記識別子通知先に、前記第１クライアントの新たな識別子を送信する識別子送信ステップと、
を含むクライアント管理方法。
【００７８】
クライアント間でのプレゼンス情報の提供に関する情報とは、例えば、クライアントが自己のプレゼンス情報の参照を許可するまたは拒否する他のクライアントの識別子が登録される許可リストまたは拒否リストが挙げられる。また別の例としては、クライアントの過去のプレゼンス情報の送信先クライアントや、過去に受信したプレゼンス情報の送信元クライアントを記憶した履歴情報が挙げられる。さらに別の例としては、クライアントが過去にメッセージを送受信した他のクライアントを記憶した履歴情報が挙げられる。クライアント間でのプレゼンス情報の提供要求に関する情報としては、例えば、クライアントがプレゼンス情報の参照を要求する他のクライアントの識別子を登録するバティリストが挙げられる。
【００７９】
これらの情報は、クライアントが自ら認識している他のクライアントとの関係を示している。従って、これらの情報により特定されるユーザエージェントは、新たな識別子を通知する必要性の高いユーザエージェントである可能性が高い。いずれかの情報に含まれるクライアントの識別子を識別子変更先とすることにより、通知先の選択が容易に行えるようになる。
【００８０】
【発明の効果】
本発明を用いれば、プレゼンスシステムにおけるユーザエージェントの識別子を変更した場合、新たな識別子の適切な通知先を自動的に決定するので、新たな識別子をユーザエージェントの負担無く自動的に他のユーザエージェントに通知することができる。
【図面の簡単な説明】
【図１】 本発明の第１実施形態例に係るサーバを含むプレゼンスシステムの全体構成例
【図２】 プレゼンステーブルの概念説明図
【図３】 （ａ）、（ｂ）：図１のクライアント２ａを操作するユーザエージェントＡのウォッチャーリスト
【図４】 アカウント変更画面例
【図５】 アカウント変更通知を受けたクライアントが表示する画面例
【図６】 通知先クライアントが表示する画面例
【図７】 新アカウントの設定及びアカウントの変更理由の設定を受け付ける画面例
【図８】 アカウント変更通知により通知先クライアントが表示する属性情報の表示画面例
【図９】 変更通知画面例
【図１０】 サーバ１が行う通知処理の流れの一例を示すフローチャート
【図１１】 （ａ）ウォッチャーリストの中から新アカウントの通知先を選択するための画面例（個人の選択）
（ｂ）ウォッチャーリストの中から新アカウントの通知先を選択するための画面例（グループの選択）
【符号の説明】
１：サーバ
２：クライアント

Claims (8)

1. プレゼンス情報を提供するクライアント群を管理するクライアント管理方法であって、
   第１クライアントを含む前記クライアント群のプレゼンス情報の設定を受け付け、クライアント毎に記憶するプレゼンス記憶ステップと、
   前記クライアント群のプレゼンス情報の通知先であるクライアント（以下、単に監視クライアントという）の識別子を、プレゼンス情報を提供するクライアント毎に記憶する通知先記憶ステップと、
   前記第１クライアントの識別子の変更を受け付ける識別子変更ステップと、
   前記第１クライアントの識別子の変更に応じ、前記第１クライアントの監視クライアントの一部を抽出して識別子通知先に決定する決定ステップと、
   前記識別子通知先に、前記第１クライアントの新たな識別子を送信する識別子送信ステップと、
   前記クライアント群で送受信されるテキストメッセージの配信を管理するメッセージングステップと、
   配信されるテキストメッセージの配信履歴を記憶する配信履歴ステップと、を含み、
   前記決定ステップは、前記第１クライアントの監視クライアントの一部を前記配信履歴に基づいて抽出し、識別子通知先に決定する、クライアント管理方法。
2. プレゼンス情報を提供するクライアント群を管理するクライアント管理装置であって、
   第１クライアントを含む前記クライアント群のプレゼンス情報の設定を受け付け、クライアント毎に記憶するプレゼンス記憶手段と、
   前記クライアント群のプレゼンス情報の通知先であるクライアント（以下、単に監視クライアントという）の識別子を、プレゼンス情報を提供するクライアント毎に記憶する通知先記憶手段と、
   前記第１クライアントの識別子の変更を受け付ける識別子変更手段と、
   前記第１クライアントの識別子の変更に応じ、前記第１クライアントの監視クライアントの一部を抽出して識別子通知先に決定する決定手段と、
   前記識別子通知先に、前記第１クライアントの新たな識別子を送信する識別子送信手段と、
   前記クライアント群で送受信されるテキストメッセージの配信を管理するメッセージング手段と、
   配信されるテキストメッセージの配信履歴を記憶する配信履歴手段と、を備え、
   前記決定手段は、前記第１クライアントの監視クライアントの一部を前記配信履歴に基づいて抽出し、識別子通知先に決定する、クライアント管理装置。
3. プレゼンス情報を提供するクライアント群を管理するクライアント管理プログラムを記録した、コンピュータ読み取り可能な記録媒体であって、
   第１クライアントを含む前記クライアント群のプレゼンス情報の設定を受け付け、クライアント毎に記憶するプレゼンス記憶ステップと、
   前記クライアント群のプレゼンス情報の通知先であるクライアント（以下、単に監視クライアントという）の識別子を、プレゼンス情報を提供するクライアント毎に記憶する通知先記憶ステップと、
   前記第１クライアントの識別子の変更を受け付ける識別子変更ステップと、
   前記第１クライアントの識別子の変更に応じ、前記第１クライアントの監視クライアントの一部を抽出して識別子通知先に決定する決定ステップと、
   前記識別子通知先に、前記第１クライアントの新たな識別子を送信する識別子送信ステップと、
   前記クライアント群で送受信されるテキストメッセージの配信を管理するメッセージングステップと、
   配信されるテキストメッセージの配信履歴を記憶する配信履歴ステップと、を実行し、
   前記決定ステップは、前記第１クライアントの監視クライアントの一部を前記配信履歴に基づいて抽出し、識別子通知先に決定する、
   クライアント管理プログラムを記録した、コンピュータ読み取り可能な記録媒体。
4. プレゼンス情報の提供元となるクライアント（以下、購読クライアントという）の識別子を、前記プレゼンス情報の提供先となるクライアントに対応付けて記憶する購読クライアント記憶ステップをさらに含み、
   前記決定ステップは、前記第１クライアントの監視クライアントであって、かつ前記第１クライアントの購読クライアントであるクライアントを、識別子通知先に決定する、
   請求項３に記載のクライアント管理プログラムを記録した、コンピュータ読み取り可能な記録媒体。
5. 前記プレゼンス情報の設定に応じ、前記第１クライアントの監視クライアントに新たなプレゼンス情報を通知するプレゼンス通知ステップと、
   プレゼンス情報の通知履歴を記憶する通知履歴ステップと、をさらに含み、
   前記決定ステップは、前記第１クライアントの監視クライアントの一部を前記通知履歴に基づいて抽出し、識別子通知先に決定する、
   請求項３に記載のクライアント管理プログラムを記録した、コンピュータ読み取り可能な記録媒体。
6. 前記プレゼンス記憶ステップは、前記クライアント群のプレゼンス情報の通知先を制限するアクセスレベルと関連づけて前記プレゼンス情報を記憶し、
   前記通知先記憶ステップは、各通知先クライアントのアクセスレベルをさらに記憶し、
   前記決定ステップは、各監視クライアントのアクセスレベルに基づいて、前記第１クライアントの監視クライアントの一部を識別子通知先に決定する、
   請求項３に記載のクライアント管理プログラムを記録した、コンピュータ読み取り可能な記録媒体。
7. 前記識別子送信ステップは、前記識別子通知先のクライアントに、前記第１クライアントの識別子が変更されたことを表示するための表示データをさらに送信する、請求項３に記載のクライアント管理プログラムを記録した、コンピュータ読み取り可能な記録媒体。
8. プレゼンス情報を提供するクライアント群を管理するクライアント管理方法であって、
   第１クライアントを含む前記クライアント群のプレゼンス情報の設定を受け付け、クライアント毎に記憶するプレゼンス記憶ステップと、
   あるクライアントのプレゼンス情報の提供に関係する他のクライアントの識別子及び／またはその識別子を含むクライアント関係情報を、クライアント毎に記憶する情報記憶ステップと、
   前記第１クライアントの識別子の変更を受け付ける識別子変更ステップと、
   前記第１クライアントの識別子の変更に応じ、第１クライアントに対応づけて記憶されているクライアント関係情報に含まれるクライアントの一部を抽出して、識別子通知先に決定する決定ステップと、
   前記識別子通知先に、前記第１クライアントの新たな識別子を送信する識別子送信ステップと、
   前記クライアント群で送受信されるテキストメッセージの配信を管理するメッセージングステップと、
   配信されるテキストメッセージの配信履歴を記憶する配信履歴ステップと、を含み、
   前記決定ステップは、前記第１クライアントの監視クライアントの一部を前記配信履歴に基づいて抽出し、識別子通知先に決定する、クライアント管理方法。

Images