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

クライアント管理方法及び装置 Download PDF

Info

Publication number
JP2007115271A
JP2007115271A JP2006339294A JP2006339294A JP2007115271A JP 2007115271 A JP2007115271 A JP 2007115271A JP 2006339294 A JP2006339294 A JP 2006339294A JP 2006339294 A JP2006339294 A JP 2006339294A JP 2007115271 A JP2007115271 A JP 2007115271A
Authority
JP
Japan
Prior art keywords
client
identifier
notification destination
presence information
user agent
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2006339294A
Other languages
English (en)
Other versions
JP4536708B2 (ja
Inventor
Takashi Ono
敬史 大野
Shingo Fujimoto
真吾 藤本
Ariteru Yamamoto
有輝 山本
Jun Tsunoda
潤 角田
Masahiko Murakami
雅彦 村上
Sumiyo Okada
純代 岡田
Akinori Iwakawa
明則 岩川
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fujitsu Ltd filed Critical Fujitsu Ltd
Priority to JP2006339294A priority Critical patent/JP4536708B2/ja
Publication of JP2007115271A publication Critical patent/JP2007115271A/ja
Application granted granted Critical
Publication of JP4536708B2 publication Critical patent/JP4536708B2/ja
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Images

Landscapes

  • Information Transfer Between Computers (AREA)

Abstract

【課題】ユーザエージェントに負担をかけることなく識別子の変更を通知。
【解決手段】ユーザエージェントAが操作するクライアント2aの識別子“A1”を変更した場合、新たな識別子“A2”の通知先を自動的に決定し、通知する。新たな識別子の通知先は、ユーザエージェントAとの関係を考慮し、不要な通知先が含まれないように決定することが好ましい。そのため、識別子通知先の範囲は、ユーザエージェントAのウォッチャーを最大範囲とする。ウォッチャーは、ユーザエージェントAのプレゼンス情報の通知先であるから、それ以上に識別子を通知する必要性に乏しいと推定できるからである。
【選択図】図1

Description

本発明は、ネットワーク上のユーザが他のユーザのプレゼンス情報を参照するためのプレゼンスシステムに関する。
本発明において、プレゼンスシステムは、サーバとクライアントとを含む。サーバは、クライアントを操作するユーザエージェントのプレゼンス情報を蓄積し、他のクライアントに通知する。通知されるプレゼンス情報の所有者を、プレゼンティティと呼ぶ。プレゼンティティのプレゼンス情報を受信するクライアントの操作者を、ウォッチャーと呼ぶ。ここでプレゼンス情報とは、プレゼンティティに関する任意の情報であり、例えば状態を表すテキストメッセージ(以下、インスタントメッセージという)やアイコンファイル、住所や通信アドレスなどの個人情報が挙げられる。
インスタントメッセージは、送信したい相手の識別子さえわかれば送信可能である。近年、電子メール環境では、スパムと呼ばれる迷惑メールが問題となっている。プレゼンスシステムにおけるインスタントメッセージにも同様の問題がある。大抵の迷惑メッセージ送信者は、識別子をランダムに生成し、一度メッセージを送ってみる。成功したら、その識別子が有効なことを記憶し、次回送信時に利用する。そのため、通常のユーザエージェントにとっては、一度でも迷惑メッセージを受け取ってしまうと、次々に送られてくることになる。
この問題の第1の解決案としてアクセス制御機能を用いることが考えられる。この機能は基本的に、許可リスト、拒否リストの2種類のリストを用いる。許可リストには、ユーザエージェント自身へのメッセージの送信が許可されている他のユーザエージェントの識別子が登録される。この場合、許可リストに登録されていないユーザエージェントからのインスタントメッセージの受信は拒否される。従って迷惑なインスタントメッセージの量は軽減される。また、拒否リストには、ユーザエージェント自身へのメッセージの送信が拒否されている他のユーザエージェントの識別子が登録される。従って、例えば迷惑メッセージを送信してきたユーザエージェントを拒否リストに登録しておくことで、そこからの迷惑メッセージを以後は受信せずにすむ。
しかし、前述の第1の方法では、メッセージをもらう可能性のあるユーザエージェント全員を許可リストに登録しなければならない。また、大抵の迷惑メッセージ送信者は次々識別子を変えてくるので、拒否リストが意味をなさなくなってしまう。
そこで第2の方法として、ユーザエージェント自身の識別子を変更し、新規登録としてプレゼンスシステムの新たな識別子をもらうとともに、今まで使っていた識別子についてのサービス利用停止手続きを行う方法が考えられる。この方法を用いれば、ユーザエージェント自身の識別子の変更により迷惑メッセージの受信を防止できる利点がある。その一方で、プレゼンスシステム上で古い識別子に関連づけられていた様々な情報、例えばプレゼンス情報、バディリスト、アクセスレベルなどを、サービス利用停止処理により全て破棄することは好ましくない。
具体的には、プレゼンスシステム上のユーザエージェントAが識別子を変更した場合、他のユーザエージェントBから見ると古い識別子は使用不可能になり、新しい識別子を知る手段が存在しない。そのため、ユーザエージェントBから識別子を変更したユーザエージェントAを特定する手段がなくなってしまう。識別子を変更したユーザエージェントAは、必要なユーザエージェント一人一人に識別子の変更を通知すれば良いが、手間と時間がかかり負担が大きい。
本発明では、プレゼンスシステムにおいてユーザエージェントの識別子を変更した場合に、ユーザエージェントに負担をかけることなくその変更を通知することを目的とする。
また本発明は、プレゼンスシステムにおいてユーザエージェントの識別子を変更した場合に、必要なユーザエージェントに変更後の識別子を自動的に通知することを目的とする。
発明1は、プレゼンス情報を提供するクライアント群を管理するクライアント管理方法であって、以下のA〜Eステップを含むクライアント管理方法を提供する。
A:第1クライアントを含む前記クライアント群のプレゼンス情報の設定を受け付け、クライアント毎に記憶するプレゼンス記憶ステップ、
B:前記クライアント群のプレゼンス情報の通知先であるクライアント(以下、単に監視クライアントという)の識別子を、プレゼンス情報を提供するクライアント毎に記憶する通知先記憶ステップ、
C:前記第1クライアントの識別子の変更を受け付ける識別子変更ステップ、
D:前記第1クライアントの識別子の変更に応じ、前記第1クライアントの監視クライアントを識別子通知先に決定する決定ステップ、
E:前記識別子通知先に、前記第1クライアントの新たな識別子を通知する識別子送信ステップ、
F:前記識別子通知先から前記第1クライアントのプレゼンス情報の変更通知の依頼を受け付け、前記第1クライアントの新たな識別子と前記識別子通知先の識別子とを対応付けて記憶する通知先更新ステップ
発明2は、前記発明1において、前記決定ステップは、前記第1クライアントの識別子の変更に応じ、前記第1クライアントの監視クライアントの一部を抽出して識別子通知先に決定するクライアント管理方法を提供する。
発明3は、プレゼンス情報を提供するクライアント群を管理するクライアント管理装置であって、
第1クライアントを含む前記クライアント群のプレゼンス情報の設定を受け付け、クライアント毎に記憶するプレゼンス記憶手段と、
前記クライアント群のプレゼンス情報の通知先であるクライアント(以下、単に監視クライアントという)の識別子を、プレゼンス情報を提供するクライアント毎に記憶する通知先記憶手段と、
前記第1クライアントの識別子の変更を受け付ける識別子変更手段と、
前記第1クライアントの識別子の変更に応じ、前記第1クライアントの監視クライアントを識別子通知先に決定する決定手段と、
前記識別子通知先に、前記第1クライアントの新たな識別子を通知する識別子送信手段と、
前記識別子通知先から前記第1クライアントのプレゼンス情報の変更通知の依頼を受け付け、前記第1クライアントの新たな識別子と前記識別子通知先の識別子とを対応付けて記憶する通知先更新手段と、
を備えるクライアント管理装置を提供する。
発明4は、プレゼンス情報を提供するクライアント群を管理するクライアント管理プログラムを記録した、コンピュータ読み取り可能な記録媒体であって、
第1クライアントを含む前記クライアント群のプレゼンス情報の設定を受け付け、クライアント毎に記憶するプレゼンス記憶ステップと、
前記クライアント群のプレゼンス情報の通知先であるクライアント(以下、単に監視クライアントという)の識別子を、プレゼンス情報を提供するクライアント毎に記憶する通知先記憶ステップと、
前記第1クライアントの識別子の変更を受け付ける識別子変更ステップと、
前記第1クライアントの識別子の変更に応じ、前記第1クライアントの監視クライアントを識別子通知先に決定する決定ステップと、
前記識別子通知先に、前記第1クライアントの新たな識別子を通知する識別子送信ステップと、
前記識別子通知先から前記第1クライアントのプレゼンス情報の変更通知の依頼を受け付け、前記第1クライアントの新たな識別子と前記識別子通知先の識別子とを対応付けて記憶する通知先更新ステップと、
を実行するクライアント管理プログラムを記録した、コンピュータ読み取り可能な記録媒体を提供する。
発明5は、プレゼンス情報を提供するクライアント群を管理するクライアント管理方法であって、以下のステップを含むクライアント管理方法を提供する。
・第1クライアントを含む前記クライアント群のプレゼンス情報の設定を受け付け、クライアント毎に記憶するプレゼンス記憶ステップ、
・あるクライアントのプレゼンス情報の提供に関係する他のクライアントの識別子及び/または前記クライアントからのプレゼンス情報の提供要求に関係する他のクライアントの識別子を含むクライアント関係情報を、クライアント毎に記憶する情報記憶ステップ、
・前記第1クライアントの識別子の変更を受け付ける識別子変更ステップ、
・前記第1クライアントの識別子の変更に応じ、第1クライアントに対応づけて記憶されているクライアント関係情報に含まれるクライアントを、識別子通知先に決定する決定ステップ、
・前記識別子通知先に、前記第1クライアントの新たな識別子を送信する識別子送信ステップ、
前記識別子通知先から前記第1クライアントのプレゼンス情報の変更通知の依頼を受け付け、前記第1クライアントの新たな識別子と前記識別子通知先の識別子とを対応付けて記憶する通知先更新ステップ
本発明を用いれば、プレゼンスシステムにおけるユーザエージェントの識別子を変更した場合、新たな識別子の適切な通知先を自動的に決定するので、新たな識別子をユーザエージェントの負担無く自動的に他のユーザエージェントに通知することができる。
<第1実施形態例>
(1)基本構成
次に、本発明のクライアント管理方法をプレゼンスシステムのサーバに適用した場合を例に取り、説明する。図1は、本発明の第1実施形態例に係るサーバを含むプレゼンスシステムの全体構成例である。プレゼンスシステムは、ネットワーク3で接続されるサーバ1とクライアント2a、2b、2c・・・とを含んでいる。各クライアント2a、2b、2c・・・(以下、まとめてクライアント2)はユーザエージェントA、B、C・・・により操作される。また各クライアント2は、アカウント(識別子)により識別される。
サーバ1は、クライアント2のプレゼンス情報を管理している。このサーバ1は、プレゼンステーブル11(プレゼンス記憶手段)、ウォッチャーテーブル12(通知先記憶手段)、設定モジュール21(プレゼンス記憶手段)、変更モジュール24(識別子変更手段)、決定モジュール25(決定手段)及び通知モジュール26(識別子送信手段)を有している。
プレゼンステーブル11は、クライアント毎にプレゼンス情報を記憶する。図2は、プレゼンステーブルの概念説明図である。
設定モジュール21は、クライアント2からプレゼンス情報の設定を受け付け、プレゼンステーブル11に登録する。
ウォッチャーリストテーブル12は、クライアント2のプレゼンス情報の通知先クライアント(以下、単に監視クライアントという)のアカウントを、クライアント毎に記憶する。図3(a)、(b)は、クライアント2aを操作するユーザエージェントAのウォッチャーリストを例示している。ここで、ユーザエージェントAのアカウントは、同図(a)では“A1”であるが、同図(b)では“A2”に変更されている。
変更モジュール24は、クライアント2のアカウントの変更を受け付ける。例えば変更モジュール24は、図4に例示するアカウント変更画面をクライアント2に提供し、アカウントの変更を受け付ける。図4は、クライアント2aのアカウント“A1”を“A2”に変更する例を示している。以下、説明を容易にするために、ユーザエージェントAが操作するクライアント2aのアカウントを、“A1”から“A2”に変更する場合を例に取り説明する。
変更モジュール24は、アカウントの変更に加えてそれに関連する他の属性情報の登録をさらに受け付けてもよい。例えば、変更モジュール24は、図7に例示する画面をクライアント2aに提供し、新アカウントの設定及びアカウントの変更理由の設定を受け付ける。また変更モジュール24は、受け付けた属性情報を、新アカウントとともに通知先に通知することができる。図8は、この通知により通知先クライアントが表示する属性情報の表示画面例である。この画面は、新たなアカウント“A2”と変更理由とを表示している。
また変更モジュール24は、ユーザエージェントAが設定していない属性情報を、通知先クライアントに送信しても良い。図9は、このような属性情報の表示画面例である。この例では、属性情報として、通知先クライアントがユーザエージェントAのウォッチャーであったために新アカウントが通知されたことが表示されている。通知先クライアントを操作するユーザエージェントは、なぜアカウントが変更されたかや、なぜ自分に新アカウントが通知されたかなどを知ることができる利点がある。
決定モジュール25は、クライアント2aのアカウントの変更に応じ、ユーザエージェントAのウォッチャーが操作するクライアント(以下、監視クライアントという)の全部または一部を、新アカウント“A2”の通知先とし、通知先リスト(図示せず)を生成する。決定モジュール25は、通知先リストに含まれている監視クライアントを操作するウォッチャーだけを含むように、ウォッチャーリストテーブル12を更新しても良い。そのようなウォッチャーは、ユーザエージェントAとの関係が密であると考えられるからである。
通知モジュール26は、通知先リストに含まれているクライアントにアカウント変更通知を送信することにより、クライアント2aの新アカウント“A2”を通知する。図5は、アカウント変更通知を受けたクライアントが表示する画面例を示す。この例では、ユーザエージェントA(図中、Aさんと表示)のアカウントの表記が、“A1”から“A2”に変更されている。通知モジュール26は、前記通知先クライアントに、クライアント2aのアカウントが変更されたことを表示する画面データを提供してもよい。図6は、この画面データに基づいて通知先クライアントが表示する画面例を示す。この画面例では、クライアント2aのアカウントの変更及び新アカウント“A2”が表示されている。
このサーバ1は、ユーザエージェントAが自分のアカウントを変更した場合、新アカウントの通知先を自動的に決定及び通知する。新アカウントの通知先の範囲は、ユーザエージェントAのウォッチャーが操作する監視クライアントを最大範囲とする。新アカウントの通知先は、ユーザエージェントAと通知先のユーザエージェントとの人間関係を考慮し、不要な通知先が含まれないように決定することが好ましい。ユーザエージェントAのウォッチャーは、ユーザエージェントAのプレゼンス情報の通知先であるから、ユーザエージェントAが信用しており、新アカウントを通知したいと思っていると推定できる。また、ユーザエージェントAのプレゼンス情報を見せるウォッチャー以外に新アカウントを通知する必要性は乏しいと推定できる。
(2)ウォッチャーの一部に通知する構成
決定モジュール25は、クライアント2aのアカウントの変更に応じ、クライアント2aの監視クライアントの一部を抽出して通知先リストを生成しても良い。
ユーザエージェントAは、必ずしもウォッチャー全員に新アカウントを通知したくない場合がある。そこで新アカウントの通知が不要と推定できるウォッチャーを除いた一部のウォッチャーを抽出し、通知先リストを生成しても良い。抽出方法としては、例えば、a)ユーザエージェントAのプレゼンス情報を頻繁に通知しているウォッチャーを抽出する方法、b)ユーザエージェントAにプレゼンス情報を頻繁に通知しているウォッチャーを抽出する方法、が挙げられる。いかに、一部のウォッチャーを抽出する方法について、再び図1〜3を参照しながら具体例を挙げて説明する。
(2−1)バディであるウォッチャーを抽出
図1に例示するように、サーバ1にバディリストテーブル13を設けてもよい。決定モジュール25は、クライアント2aの監視クライアントでありかつユーザエージェントAのバディが操作するクライアント(以下、購読クライアントという)であるクライアントを、新アカウントの通知先としてもよい。ここでユーザエージェントAのバディとは、ユーザエージェントAがそのプレゼンス情報の通知を希望しているユーザエージェントである。
バディリストテーブル13は、各クライアント毎にバディリストを蓄積している。図3は、ユーザエージェントAのバディリストを例示している。ここでは、ユーザエージェントAは、アカウント“C1”及び“D1”で識別されるクライアントをバディに指定している。
例えば図3では、ユーザエージェントAのウォッチャーでありバディであるユーザエージェントが操作するクライアント2のアカウントは“C1”である。この場合、決定モジュール25は、“C1”で識別されるクライアントを、新アカウント“A2”の通知先とする。
バディは、ユーザエージェントAが興味を持つユーザエージェントであると考えられる。ウォッチャーかつバディであるユーザエージェントを新アカウントの通知先とすれば、ユーザエージェントAとの人的関係が強いユーザエージェントを、ウォッチャーから選択的に抽出できる可能性が高いと期待できる。これにより、新アカウントの通知先として不適切なウォッチャーに、新アカウントを通知せずにすむ。例えば、ユーザエージェントAに自分のプレゼンス情報の通知を許可していないウォッチャーには新アカウントを通知せずにすむ。
(2−2)プレゼンス通知履歴に基づいてウォッチャーを抽出
図1に例示するように、配信モジュール22と、抽出情報テーブル14と、をサーバ1にさらに設けてもよい。
配信モジュール22は、クライアント2からプレゼンス情報の設定を受け付け、そのクライアントの監視クライアントに新たなプレゼンス情報を配信する(以下、プレゼンス通知という)。プレゼンス通知を受信した監視クライアント2は、前記図5に例示するように、プレゼンス情報を表示したり、プレゼンス情報の表示を更新する。
抽出情報テーブル14は、ウォッチャーの一部を抽出するための情報を蓄積している。図3に示すように、抽出情報テーブル14は、例えばプレゼンス通知を送受信した履歴を示すプレゼンス受信リスト142やプレゼンス送信リスト143を蓄積している。プレゼンス受信リスト142は、クライアント2aが、そこからプレゼンス情報を受信したクライアント(以下、プレゼンス受信クライアントという)のアカウント、受信回数、受信時刻など、プレゼンス通知の受信履歴を示すデータを含む。プレゼンス送信リスト143は、クライアント2aが、自己のプレゼンス情報を送信したクライアント(以下、プレゼンス送信クライアントという)のアカウント、送信回数、送信時刻など、プレゼンス通知の送信履歴を示すデータを含む。
決定モジュール25は、クライアント2aの監視クライアントでありかつプレゼンス受信クライアントであるクライアントを前記プレゼンス受信リスト142に基づいて抽出し、新アカウントの通知先としてもよい。また、監視クライアントであって、しかもプレゼンス通知の受信回数や受信頻度が高いプレゼンス受信クライアントだけを、通知先としても良い。さらに、そのようなプレゼンス受信クライアントであって、かつ購読クライアントであるクライアントを通知先とすることも考えられる。
同様に、決定モジュール25は、クライアント2aの監視クライアントであってプレゼンス送信クライアントであるクライアントを前記プレゼンス送信リスト142に基づいて抽出し、新アカウントの通知先としてもよい。また、監視クライアントであって、しかもプレゼンス通知の送信回数や送信頻度が高いプレゼンス送信クライアントだけを、通知先としても良い。さらに、そのようなプレゼンス送信クライアントであって、かつ購読クライアントであるクライアントを通知先とすることも考えられる。さらに前述のプレゼンス受信クライアントであることを、通知先の要件に加えることも可能である。
図3の例では、抽出情報テーブル14は判断基準値リスト141をさらに含んでいる。決定モジュール25は、例えば、ウォッチャーリスト12、プレゼンス通知の送受信履歴142,143及び判断基準値リスト141に基づいて、通知先リストを生成する。判断基準値リスト141には各種のしきい値が蓄積されている。例えば、回数、頻度などのしきい値である。この例では、「回数」のしきい値は10回である。プレゼンス受信クライアントのうち受信回数が10回以上であり、かつ監視クライアントであるクライアント“C1”を、決定モジュール25は通知先として抽出することができる。また、プレゼンス送信クライアントのうち送信回数が10回以上であり、かつ監視クライアントであるクライアント“C1”を、決定モジュール25は通知先として抽出することができる。なお、図3の例では、抽出された通知先からなる通知先リストを、新たなウォッチャーリスト12に置き換えている。
プレゼンス通知の送受信履歴をウォッチャーの抽出に用いれば、不要なクライアントへ新アカウントを通知することを防止できる。例えばユーザエージェントXがユーザエージェントAのウォッチャーかつバディであっても、そのプレゼンス情報が変化しない場合、ユーザエージェントXのプレゼンス通知はユーザエージェントAに送信されない。このようなユーザエージェントXには新アカウントを通知する必要性が比較的低いと想定できる。
(2−3)メッセージング履歴に基づいてウォッチャーを抽出
図1に例示するように、IM(Instant Message)モジュール23と、抽出情報テーブル14と、をサーバ1にさらに設けてもよい。
IMモジュール23は、クライアント2からテキストメッセージの設定とその送信先の指定とを受け付け、送信先にテキストメッセージを配信する。
抽出情報テーブル14は、ウォッチャーの一部を抽出するための情報を蓄積している。図3に示すように、抽出情報テーブル14は、例えばテキストメッセージを送受信した履歴を示すメッセージ受信リスト144やメッセージ送信リスト145を蓄積している。メッセージ受信リスト144は、クライアント2aが、そこからのテキストメッセージを受信したクライアント(以下、メッセージ受信クライアントという)のアカウント、受信回数、受信時刻など、テキストメッセージの受信履歴を示すデータを含む。メッセージ送信リスト145は、クライアント2aがテキストメッセージを送信したクライアント(以下、メッセージ送信クライアントという)のアカウント、送信回数、送信時刻など、テキストメッセージの送信履歴を示すデータを含む。
決定モジュール25は、クライアント2aの監視クライアントであってメッセージ受信クライアントであるクライアントを前記メッセージ受信リスト144に基づいて抽出し、新アカウントの通知先としてもよい。また、監視クライアントであって、しかもテキストメッセージの受信回数や受信頻度が高いメッセージ受信クライアントだけを、通知先としても良い。さらに、そのようなメッセージ受信クライアントであって、かつ購読クライアントであるクライアントを通知先とすることも考えられる。
同様に、決定モジュール25は、クライアント2aの監視クライアントであってメッセージ送信クライアントであるクライアントを前記メッセージ送信リスト145に基づいて抽出し、新アカウントの通知先としてもよい。また、監視クライアントであって、しかもテキストメッセージの送信回数や送信頻度が高いメッセージ送信クライアントだけを、通知先としても良い。さらに、そのようなメッセージ送信クライアントであって、かつ購読クライアントであるクライアントを通知先とすることも考えられる。
図3の例では、抽出情報テーブル14に判断基準値リスト141が含まれている。決定モジュール25は、ウォッチャーリスト12、メッセージの送受信履歴144,145及び判断基準値リスト141に基づいて、通知先リストを生成する。判断基準値リスト141には各種のしきい値、例えば回数のしきい値“10”が蓄積されている。この例では、メッセージ受信クライアントのうち受信回数が10回以上であり、かつ監視クライアントであるクライアント“C1”、“Y1”を、決定モジュール25が通知先として抽出することができる。またメッセージ送信クライアントのうち送信回数が10回以上であり、かつ監視クライアントであるクライアント“C1”を、決定モジュール25が通知先として抽出することができる。
ユーザエージェントAとテキストメッセージを送受信したことのあるユーザエージェントは、ユーザエージェントAと関係が比較的密であると推定できる。そこで、このようなユーザエージェントであってユーザエージェントのウォッチャーでもあるユーザエージェントには、新アカウントを通知することが適当と推察できる。
(2−4)アクセスレベルに応じてウォッチャーを抽出
図2に例示するように、プレゼンステーブル11は、クライアント2のプレゼンス情報の通知先を制限するアクセスレベルと関連づけてプレゼンス情報を記憶してもよい。アクセスレベルとは、プレゼンス情報の開示度を示す。図2では、クライアント2はアクセスレベル毎にプレゼンス情報を設定することができる。
プレゼンステーブル11にアクセスレベルが設定される場合、図3に例示するように、ウォッチャーリストテーブル12は各ウォッチャーのアクセスレベルをさらに記憶することが好ましい。各ウォッチャーのアクセスレベルは、プレゼンス情報をウォッチャーに提供するプレゼンティティにより設定される。図3では、ユーザエージェントAがプレゼンティティである。
この場合、決定モジュール25は、各ウォッチャーのアクセスレベルに基づいて、クライアント2aの監視クライアントの全部または一部を新アカウントの通知先に決定することができる。例えば、図3に示すように抽出情報テーブル14に判断基準値リスト141を持たせ、ここにアクセスレベルのしきい値「2」を登録しておく。図3の例では、決定モジュール25は、アクセスレベルの値が2以下のウォッチャーが操作するクライアント“B1”、“C1”、“Y1”を、新アカウントの通知先として抽出する。
アクセスレベルは、ユーザエージェントAの信頼度を示すと推定できる。アクセスレベルが高いユーザエージェントのクライアントを新アカウントの通知先とするなど、アクセスレベルに基づいて通知先を制御することにより、アカウントの不要な通知を防止することができる。
(2−5)その他の抽出
ウォッチャーリストテーブル12に応じて抽出情報テーブル14に様々な値を設定すれば、様々な方法で適正なウォッチャーを通知先として抽出可能である。図3に例示するように、ウォッチャーリストテーブル12が、「表示フラグ」、「表示順序」、「表示色」を記憶している場合、抽出情報テーブル14の判断基準値リスト141にこれらに対応する基準値を設定することができる。図3は、判断基準値リスト141の設定の一例を示す。この図は、「表示フラグ」がオンの監視クライアントを通知先として抽出する設定を示している。この例では、表示順序及び表示色に基づく抽出を行っていないが、これらによる通知先の抽出も可能である。例えば表示順序を2番までに設定すれば、この例ではクライアント“B1”、“C1”が通知先になる。また表示色を青に設定すれば、この例ではクライアント“B1”が通知先になる。
また別の方法として、ウォッチャーリストテーブル12が、前記図3に示すように「経過時間」を記憶している場合、抽出情報テーブル14の判断基準値リスト141に経過時間のしきい値を設定することができる(図示せず)。例えば、「経過時間」がクライアント2aの監視クライアントとなってからの時間を示している場合、経過時間が一定以上の監視クライアントを通知先として抽出することができる。経過時間が長い監視クライアントのユーザエージェントは、ユーザエージェントAと古くからつきあいがあると推測できる。そこで古くからの監視クライアントにアカウントを通知し、つきあいの浅いと考えられる監視クライアントを通知対象から除外しても良い。
さらに別の方法として、ウォッチャーリストテーブル12が、前記図3に示すように「回数」を記憶している場合、抽出情報テーブル14の判断基準値リスト141に回数のしきい値を設定することができる。例えば、「回数」がクライアント2aのプレゼンス情報の通知回数を示している場合、通知回数が一定以上の監視クライアントを通知先として抽出することができる。このようなクライアントは、ユーザエージェントAとの人的関係が比較的強いと考えられるからである。
以上は、新アカウントの通知先として適切なウォッチャーを抽出する判断基準及び抽出方法の一例である。これらの判断基準及び抽出方法は適宜組み合わせて用いることができる。またニーズに応じて適宜他の判断基準及び抽出方法を適用してもよい。
(3)変更通知先のクライアント
アカウントの変更通知を受けたクライアントは例えば次のように動作する。クライアント2aのアカウントの変更通知を、ユーザエージェントBが操作するクライアント2bが受けたとする。クライアント2bは、記憶している各種情報に、アカウントの変更通知に含まれる変更前のアカウント“A1”が含まれているか否かを検索する。ここでは、ユーザエージェントBは、ユーザエージェントAのアカウント“A1”をバディリストに登録しており、さらにアクセスレベルを設定していたとする。
クライアント2bは、アカウントの変更通知を受信した際に、バディリストやアクセスレベルに登録されているアカウント“A1”を、自動的に通知された新しいアカウント“A2”に変更してもよい。また、クライアント2bは、前記図6に示すように、変更通知があったアカウント“A1”が含まれている情報種別を画面に表示してもよい。クライアント2bは、この画面上で、変更を反映する情報種別の選択をユーザエージェントBから受け付けた後、画面にて指示された情報についてのみアカウント“A2”に変更してもよい。
(4)処理の流れ
図10は、サーバ1が行う通知処理の流れの一例を示すフローチャートである。説明を容易にするために、ここでは抽出情報テーブル14が図3に例示する内容であり、前記に例示したいずれかの判断基準を満たすウォッチャーを通知先とする処理を例に挙げて説明する。
ステップS1:変更モジュール24は、任意のクライアントアカウントの変更要求があった場合、ステップS2に移行する。ここではクライアント2aからアカウントの変更要求があったと仮定する。
ステップS2:決定モジュール25は、ウォッチャーリストテーブル12から、クライアント2aのウォッチャーリストを読み出す。
ステップS3:決定モジュール25は、ウォッチャーリストに含まれている監視クライアントのいずれかを、カレントウォッチャーとする。
ステップS4:決定モジュール25は、カレントウォッチャーがいずれかの判断基準を満たしているかどうかを判断する。カレントウォッチャーが、ユーザエージェントのバディである、アクセスレベルの値が2以下である、などの判断基準のいずれかを満たす場合、ステップS5に移行する。カレントウォッチャーがいずれの判断基準も満たさない場合、ステップS3に戻り、他のウォッチャーをカレントウォッチャーとして前記判断を繰り返す。
ステップS5:決定モジュール25は、カレントウォッチャーを通知先リストに追加する。
ステップS6:決定モジュール25は、ユーザエージェントAの全てのウォッチャーの監視クライアントについて、ステップS4の判断を行ったか否かを判断する。“Yes”と判断するとステップS7に移行する。“No”と判断するとステップS3に戻り、他の監視クライアントをカレントウォッチャーとして前記のステップS3〜S5を繰り返す。
ステップS7:決定モジュール25は、通知先リストに含まれるクライアントだけを含むように、ウォッチャーリストテーブル12を更新する。
ステップS8:通知モジュール26は、更新されたウォッチャーリストに含まれるクライアントに対し、クライアント2aの新アカウントを通知する。このとき、通知の理由などの属性情報を合わせて通知することも可能である。
<その他の実施形態例>
(A)次のようにしてユーザエージェントAの新アカウント“A2”の通知先を決定しても良い。まず、サーバ1にテキストメッセージの転送機能を持たせ、ユーザエージェント毎の転送先リストをサーバ1に蓄積しておく(図示せず)。ユーザエージェントAのアカウントが変更されると、ユーザエージェントAの転送先として登録されているユーザエージェントを、新たなアカウント“A2”の通知先に決定する。
(B)ユーザエージェントAの新アカウントを通知されたユーザエージェントBは、新たなアカウント“A2”に対し、再度プレゼンス情報の通知を依頼しても良い。ユーザエージェントAのプレゼンス情報を、アカウント変更後も確実に取得することができる。
(C)新アカウントの通知先を、ウォッチャーリストの中から、あるいはウォッチャーでありバディでもあるユーザエージェントリストの中から、手動で選択可能にしても良い。この選択は、個人単位でも、またグループ単位でも可能である。図11(a)は、ウォッチャーリストの中から新アカウントの通知先を選択するための画面例である。図11(b)は、ウォッチャーでもありバディでもあるユーザグループの中から、新アカウントの通知先を選択するための画面例である。
(D)前述のプレゼンスシステムは、一般にサーバ−クライアント構成を取るが、本発明はその構成に依存しない。クライアント同士がプレゼンス情報を交換する、いわゆるP2P構成にも適用可能である。
(E)上記実施形態例では、ウォッチャーリストに登録された情報に基づいて、アカウントの通知先を決定している。しかし、バディリストを参照し、バディリストに登録されているクライアントのアカウントをアカウント通知先に決定してもよい。
これにより、クライアント2aのプレゼンスを参照している如何に関わらず、クライアントAが認知している他のクライアント2b,2c・・・のみに、クライアント2aのアカウントの変更通知を行うことが可能となる。不当にクライアント2aのプレゼンス情報を参照していた他のクライアント2x(図示せず)には、アカウントの変更通知は行われないので、クライアント2aにとって不当なウォッチャーの排除が可能となる。
また、クライアント2aが自己のプレゼンス情報の参照を許可する他のクライアント2d,2e・・・を登録している許可リストを利用することにより、バディリストに登録されていない他のクライアント2d,2e・・・(図示せず)に対しても、アカウントの変更を通知することが可能となる。許可リストに登録されているクライアント2d,2e・・・は、クライアント2aが自己のプレゼンス情報の参照を認めているクライアントであるから、クライアント2a自身のアカウントを認識していてもよいクライアントとなる。プレゼンス情報の参照関係の有無に関わらず、クライアント2aが自己のアカウントを知らせてよいクライアントが、アカウントの変更通知先として選定されることになる。
クライアントA自身のプレゼンス情報の通知を拒否する拒否リストに登録されているクライアント2y,2z・・・(図示せず)は、アカウントの変更通知先にはなりえないクライアントの集合と言える。拒否リストは、様々な情報に基づいて抽出された変更通知先のクライアントに、通知すべきでないクライアントが含まれていないかをチェックするために利用すると有効である。変更通知先として抽出されたクライアントが拒否リストに含まれていないを確認し、含まれている場合は、変更通知先から除外する。これにより、変更通知すべきでないクライアントを自動的に排除することが可能となる。
過去のプレゼンス情報やメッセージの送受信相手のクライアントを記憶した履歴情報は、クライアントと通信相手のクライアントとの関係の親密度を推測可能なデータであると言える。履歴情報から、プレゼンス情報やメッセージの送信あるいは受信の頻度や時間間隔を分析し、例えば、頻度の多いクライアント、時間間隔の狭いクライアントを、変更通知先として抽出する。これにより、アカウントの変更通知時点でのクライアントと通信相手のクライアントとの関係に応じて、変更通知先の選定が可能となる。
(F)前述した本発明の方法を実行するプログラムを記録した記録媒体は、本発明に含まれる。ここで記録媒体としては、コンピュータが読み書き可能なフレキシブルディスク、ハードディスク、半導体メモリ、CD−ROM、DVD、光磁気ディスク(MO)、その他のものが挙げられる。
<付記>
(付記1)
プレゼンス情報を提供するクライアント群を管理するクライアント管理方法であって、
第1クライアントを含む前記クライアント群のプレゼンス情報の設定を受け付け、クライアント毎に記憶するプレゼンス記憶ステップと、
前記クライアント群のプレゼンス情報の通知先であるクライアント(以下、単に監視クライアントという)の識別子を、プレゼンス情報を提供するクライアント毎に記憶する通知先記憶ステップと、
前記第1クライアントの識別子の変更を受け付ける識別子変更ステップと、
前記第1クライアントの識別子の変更に応じ、前記第1クライアントの監視クライアントを識別子通知先に決定する決定ステップと、
前記識別子通知先に、前記第1クライアントの新たな識別子を送信する識別子送信ステップと、
を含むクライアント管理方法。
ユーザエージェントAが操作するクライアントの識別子を変更した場合、新たな識別子の通知先を自動的に決定し、通知する。新たな識別子の通知先は、ユーザエージェントAとの関係を考慮し、不要な通知先が含まれないように決定することが好ましい。そのため、識別子通知先の範囲は、ユーザエージェントAのウォッチャーを最大範囲とする。ウォッチャーは、ユーザエージェントAのプレゼンス情報の通知先であるから、それ以上に識別子を通知する必要性に乏しいと推定できるからである。
(付記2)
前記決定ステップは、前記第1クライアントの識別子の変更に応じ、前記第1クライアントの監視クライアントの一部を抽出して識別子通知先に決定する、付記1に記載のクライアント管理方法。
ユーザエージェントAは、必ずしもウォッチャー全員に新識別子を通知したくない場合がある。そこで識別子の通知が不要と推定できるウォッチャーを除いた一部のウォッチャーを抽出し、識別子通知先とする。抽出方法としては、例えば、a)ユーザエージェントAのプレゼンス情報を頻繁に通知しているウォッチャーを抽出する方法、b)ユーザエージェントAにプレゼンス情報を頻繁に通知しているウォッチャーを抽出する方法、が挙げられる。
(付記3)
プレゼンス情報の提供元となるクライアント(以下、購読クライアントという)の識別子を、前記プレゼンス情報の提供先となるクライアントに対応付けて記憶する購読クライアント記憶ステップをさらに含み、
前記決定ステップは、前記第1クライアントの監視クライアントであって、かつ前記第1クライアントの購読クライアントであるクライアントを、識別子通知先に決定する、
付記2に記載のクライアント管理方法。
ユーザエージェントAは、必ずしもウォッチャー全員に新識別子を通知したくない場合がある。そこで、ユーザエージェントAのバディかつウォッチャーであるユーザエージェントを、識別子通知先とする。これにより、識別子通知先として不適切なウォッチャーに新識別子を通知せずにすむ。不適切なウォッチャーとは、例えばユーザエージェントAに自分のプレゼンス情報の通知を許可していないウォッチャーが挙げられる。
(付記4)
前記プレゼンス情報の設定に応じ、前記第1クライアントの監視クライアントに新たなプレゼンス情報を通知するプレゼンス通知ステップと、
プレゼンス情報の通知履歴を記憶する通知履歴ステップと、をさらに含み、
前記決定ステップは、前記第1クライアントの監視クライアントの一部を前記通知履歴に基づいて抽出し、識別子通知先に決定する、
付記2に記載のクライアント管理方法。
この方法において、前記決定ステップは、前記第1クライアントの監視クライアントの一部を前記通知履歴に基づいて抽出し、識別子通知先に決定する。
例えば、ユーザエージェントAのウォッチャーであるユーザエージェントのうち、過去にプレゼンス情報を通知してくれているユーザエージェントに、新識別子を通知する。例えばユーザエージェントXのプレゼンス情報が変化しない場合、仮にこのユーザエージェントXがユーザエージェントAのバディであってもそのプレゼンス情報はユーザエージェントAに送信されない。このようなユーザエージェントXには、識別子を通知する必要性が比較的低いと想定できる。
(付記5)
前記クライアント群で送受信されるテキストメッセージの配信を管理するメッセージングステップと、
配信されるテキストメッセージの配信履歴を記憶する配信履歴ステップと、をさらに含み、
前記決定ステップは、前記第1クライアントの監視クライアントの一部を前記配信履歴に基づいて抽出し、識別子通知先に決定する、
付記2に記載のクライアント管理方法。
ユーザエージェントAは、必ずしもウォッチャー全員に新識別子を通知したくない場合がある。そこで例えば、ウォッチャーであって、テキストメッセージをユーザエージェントAとやりとりしたことのあるユーザエージェントのクライアントを、識別子通知先とする。このようなユーザエージェントは、ユーザエージェントAと関係が比較的密であると推定できるからである。ユーザエージェントAとテキストメッセージをやりとりしている頻度や回数に応じ、識別子通知先とするかどうかを決定することもできる。
(付記6)
前記プレゼンス記憶ステップは、前記クライアント群のプレゼンス情報の通知先を制限するアクセスレベルと関連づけて前記プレゼンス情報を記憶し、
前記通知先記憶ステップは、各通知先クライアントのアクセスレベルをさらに記憶し、
前記決定ステップは、各監視クライアントのアクセスレベルに基づいて、前記第1クライアントの監視クライアントの一部を識別子通知先に決定する、
付記2に記載のクライアント監視方法。
ユーザエージェントAは、必ずしもウォッチャー全員に新識別子を通知したくない場合がある。そこで、ウォッチャーであって、例えばアクセスレベルが高いユーザエージェントのクライアントを、識別子通知先とすることが考えられる。アクセスレベルに応じて識別子を通知するか否かを調整することにより、不要な識別子の通知を防止することができる。
(付記7)
前記識別子送信ステップは、前記識別子通知先のクライアントに、前記第1クライアントの識別子が変更されたことを表示するための表示データをさらに送信する、付記1に記載のクライアント管理方法。
識別子通知先のクライアントを操作するユーザエージェントに、そのユーザエージェントが監視しているユーザエージェントAの識別子が変更したことを知らしめることができる。
(付記8)
前記識別子送信ステップは、前記識別子通知先のクライアントに、識別子の変更に関連する属性情報をさらに送信する、付記1に記載のクライアント管理方法。
属性情報としては、例えばアカウントを変更する理由を述べたテキストメッセージや、通知先として抽出した理由を述べたテキストメッセージが挙げられる。識別子通知先となったクライアントを操作するユーザエージェントは、なぜ識別子が変更されたかや、なぜ自分に新識別子が通知されたかなどを知ることができる。
(付記9)
前記識別子変更ステップは、前記属性情報の登録をさらに受け付ける、付記8に記載のクライアント管理方法。
識別子を変更するユーザエージェントは、例えば変更の理由などを、新識別子とともに自分の知り合いに通知することができる。
(付記10)
プレゼンス情報を提供するクライアント群を管理するクライアント管理装置であって、
第1クライアントを含む前記クライアント群のプレゼンス情報の設定を受け付け、クライアント毎に記憶するプレゼンス記憶手段と、
前記クライアント群のプレゼンス情報の通知先であるクライアント(以下、単に監視クライアントという)の識別子を、プレゼンス情報を提供するクライアント毎に記憶する通知先記憶手段と、
前記第1クライアントの識別子の変更を受け付ける識別子変更手段と、
前記第1クライアントの識別子の変更に応じ、前記第1クライアントの監視クライアントを識別子通知先に決定する決定手段と、
前記識別子通知先に、前記第1クライアントの新たな識別子を送信する識別子送信手段と、
を備えるクライアント管理装置。
この発明は、前記第1発明と同様の作用効果を奏する。
(付記11)
プレゼンス情報を提供するクライアント群を管理するクライアント管理プログラムを記録した、コンピュータ読み取り可能な記録媒体であって、
第1クライアントを含む前記クライアント群のプレゼンス情報の設定を受け付け、クライアント毎に記憶するプレゼンス記憶ステップと、
前記クライアント群のプレゼンス情報の通知先であるクライアント(以下、単に監視クライアントという)の識別子を、プレゼンス情報を提供するクライアント毎に記憶する通知先記憶ステップと、
前記第1クライアントの識別子の変更を受け付ける識別子変更ステップと、
前記第1クライアントの識別子の変更に応じ、前記第1クライアントの監視クライアントを識別子通知先に決定する決定ステップと、
前記識別子通知先に、前記第1クライアントの新たな識別子を送信する識別子送信ステップと、
を実行するクライアント管理プログラムを記録した、コンピュータ読み取り可能な記録媒体。
この発明は、前記第1発明と同様の作用効果を奏する。
(付記12)
プレゼンス情報を提供するクライアント群を管理するコンピュータが実行するクライアント管理プログラムであって、
第1クライアントを含む前記クライアント群のプレゼンス情報の設定を受け付け、クライアント毎に記憶するプレゼンス記憶手段、
前記クライアント群のプレゼンス情報の通知先であるクライアント(以下、単に監視クライアントという)の識別子を、プレゼンス情報を提供するクライアント毎に記憶する通知先記憶手段、
前記第1クライアントの識別子の変更を受け付ける識別子変更手段、
前記第1クライアントの識別子の変更に応じ、前記第1クライアントの監視クライアントを識別子通知先に決定する決定手段、及び
前記識別子通知先に、前記第1クライアントの新たな識別子を送信する識別子送信手段、
として前記コンピュータを機能させるクライアント管理プログラム。
この発明は、前記第1発明と同様の作用効果を奏する。
(付記13)
プレゼンス情報を提供するクライアント群を管理するクライアント管理方法であって、
第1クライアントを含む前記クライアント群のプレゼンス情報の設定を受け付け、クライアント毎に記憶するプレゼンス記憶ステップと、
あるクライアントのプレゼンス情報の提供に関係する他のクライアントの識別子及び/または前記クライアントからのプレゼンス情報の提供要求に関係する他のクライアントの識別子を含むクライアント関係情報を、クライアント毎に記憶する情報記憶ステップと、
前記第1クライアントの識別子の変更を受け付ける識別子変更ステップと、
前記第1クライアントの識別子の変更に応じ、第1クライアントに対応づけて記憶されているクライアント関係情報に含まれるクライアントを、識別子通知先に決定する決定ステップと、
前記識別子通知先に、前記第1クライアントの新たな識別子を送信する識別子送信ステップと、
を含むクライアント管理方法。
クライアント間でのプレゼンス情報の提供に関する情報とは、例えば、クライアントが自己のプレゼンス情報の参照を許可するまたは拒否する他のクライアントの識別子が登録される許可リストまたは拒否リストが挙げられる。また別の例としては、クライアントの過去のプレゼンス情報の送信先クライアントや、過去に受信したプレゼンス情報の送信元クライアントを記憶した履歴情報が挙げられる。さらに別の例としては、クライアントが過去にメッセージを送受信した他のクライアントを記憶した履歴情報が挙げられる。クライアント間でのプレゼンス情報の提供要求に関する情報としては、例えば、クライアントがプレゼンス情報の参照を要求する他のクライアントの識別子を登録するバティリストが挙げられる。
これらの情報は、クライアントが自ら認識している他のクライアントとの関係を示している。従って、これらの情報により特定されるユーザエージェントは、新たな識別子を通知する必要性の高いユーザエージェントである可能性が高い。いずれかの情報に含まれるクライアントの識別子を識別子変更先とすることにより、通知先の選択が容易に行えるようになる。
本発明の第1実施形態例に係るサーバを含むプレゼンスシステムの全体構成例 プレゼンステーブルの概念説明図 (a)、(b):図1のクライアント2aを操作するユーザエージェントAのウォッチャーリスト アカウント変更画面例 アカウント変更通知を受けたクライアントが表示する画面例 通知先クライアントが表示する画面例 新アカウントの設定及びアカウントの変更理由の設定を受け付ける画面例 アカウント変更通知により通知先クライアントが表示する属性情報の表示画面例 変更通知画面例 サーバ1が行う通知処理の流れの一例を示すフローチャート (a)ウォッチャーリストの中から新アカウントの通知先を選択するための画面例(個人の選択) (b)ウォッチャーリストの中から新アカウントの通知先を選択するための画面例(グループの選択
符号の説明
1:サーバ
2:クライアント

Claims (5)

  1. プレゼンス情報を提供するクライアント群を管理するクライアント管理方法であって、
    第1クライアントを含む前記クライアント群のプレゼンス情報の設定を受け付け、クライアント毎に記憶するプレゼンス記憶ステップと、
    前記クライアント群のプレゼンス情報の通知先であるクライアント(以下、単に監視クライアントという)の識別子を、プレゼンス情報を提供するクライアント毎に記憶する通知先記憶ステップと、
    前記第1クライアントの識別子の変更を受け付ける識別子変更ステップと、
    前記第1クライアントの識別子の変更に応じ、前記第1クライアントの監視クライアントを識別子通知先に決定する決定ステップと、
    前記識別子通知先に、前記第1クライアントの新たな識別子を送信する識別子送信ステップと、
    を含むクライアント管理方法。
  2. 前記決定ステップは、前記第1クライアントの識別子の変更に応じ、前記第1クライアントの監視クライアントの一部を抽出して識別子通知先に決定する、請求項1に記載のクライアント管理方法。
  3. プレゼンス情報を提供するクライアント群を管理するクライアント管理装置であって、
    第1クライアントを含む前記クライアント群のプレゼンス情報の設定を受け付け、クライアント毎に記憶するプレゼンス記憶手段と、
    前記クライアント群のプレゼンス情報の通知先であるクライアント(以下、単に監視クライアントという)の識別子を、プレゼンス情報を提供するクライアント毎に記憶する通知先記憶手段と、
    前記第1クライアントの識別子の変更を受け付ける識別子変更手段と、
    前記第1クライアントの識別子の変更に応じ、前記第1クライアントの監視クライアントを識別子通知先に決定する決定手段と、
    前記識別子通知先に、前記第1クライアントの新たな識別子を送信する識別子送信手段と、
    を備えるクライアント管理装置。
  4. プレゼンス情報を提供するクライアント群を管理するクライアント管理プログラムを記録した、コンピュータ読み取り可能な記録媒体であって、
    第1クライアントを含む前記クライアント群のプレゼンス情報の設定を受け付け、クライアント毎に記憶するプレゼンス記憶ステップと、
    前記クライアント群のプレゼンス情報の通知先であるクライアント(以下、単に監視クライアントという)の識別子を、プレゼンス情報を提供するクライアント毎に記憶する通知先記憶ステップと、
    前記第1クライアントの識別子の変更を受け付ける識別子変更ステップと、
    前記第1クライアントの識別子の変更に応じ、前記第1クライアントの監視クライアントを識別子通知先に決定する決定ステップと、
    前記識別子通知先に、前記第1クライアントの新たな識別子を送信する識別子送信ステップと、
    を実行するクライアント管理プログラムを記録した、コンピュータ読み取り可能な記録媒体。
  5. プレゼンス情報を提供するクライアント群を管理するクライアント管理方法であって、
    第1クライアントを含む前記クライアント群のプレゼンス情報の設定を受け付け、クライアント毎に記憶するプレゼンス記憶ステップと、
    あるクライアントのプレゼンス情報の提供に関係する他のクライアントの識別子及び/または前記クライアントからのプレゼンス情報の提供要求に関係する他のクライアントの識別子を含むクライアント関係情報を、クライアント毎に記憶する情報記憶ステップと、
    前記第1クライアントの識別子の変更を受け付ける識別子変更ステップと、
    前記第1クライアントの識別子の変更に応じ、第1クライアントに対応づけて記憶されているクライアント関係情報に含まれるクライアントを、識別子通知先に決定する決定ステップと、
    前記識別子通知先に、前記第1クライアントの新たな識別子を送信する識別子送信ステップと、
    を含むクライアント管理方法。
JP2006339294A 2006-12-18 2006-12-18 クライアント管理方法及び装置及び記録媒体 Expired - Fee Related JP4536708B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2006339294A JP4536708B2 (ja) 2006-12-18 2006-12-18 クライアント管理方法及び装置及び記録媒体

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2006339294A JP4536708B2 (ja) 2006-12-18 2006-12-18 クライアント管理方法及び装置及び記録媒体

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
JP2002254828A Division JP3985954B2 (ja) 2002-08-30 2002-08-30 クライアント管理方法及び装置

Publications (2)

Publication Number Publication Date
JP2007115271A true JP2007115271A (ja) 2007-05-10
JP4536708B2 JP4536708B2 (ja) 2010-09-01

Family

ID=38097324

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2006339294A Expired - Fee Related JP4536708B2 (ja) 2006-12-18 2006-12-18 クライアント管理方法及び装置及び記録媒体

Country Status (1)

Country Link
JP (1) JP4536708B2 (ja)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009110255A (ja) * 2007-10-30 2009-05-21 Nec Commun Syst Ltd 通信端末、そのコンピュータプログラム、そのデータ配信方法、これを用いたデータ配信システム
JP2016066917A (ja) * 2014-09-25 2016-04-28 Kddi株式会社 コンテンツ共有システム及びコンテンツ共有方法
JP2016116100A (ja) * 2014-12-16 2016-06-23 Kddi株式会社 管理サーバ、コンテンツ共有システム及びコンテンツ共有方法

Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH04196848A (ja) * 1990-11-28 1992-07-16 Hitachi Ltd 電子メールシステム
JPH07183890A (ja) * 1993-12-24 1995-07-21 Fuji Xerox Co Ltd ネームサービスシステム
JPH113316A (ja) * 1997-06-13 1999-01-06 Sony Corp 伝送媒体、情報処理方法および装置
JP2000032033A (ja) * 1998-07-08 2000-01-28 Fujitsu Ltd 情報交換方法、情報管理流通装置、情報管理装置、情報流通装置、情報管理流通プログラムを記録したコンピュータ読み取り可能な記録媒体、情報管理プログラムを記録したコンピュータ読み取り可能な記録媒体及び情報流通プログラムを記録したコンピュータ読み取り可能な記録媒体
JP2000149063A (ja) * 1998-11-17 2000-05-30 Sony Corp 情報処理装置および方法、並びに提供媒体
JP2001075887A (ja) * 1999-09-06 2001-03-23 Matsushita Electric Ind Co Ltd ユーザ情報管理装置
JP2003030362A (ja) * 2001-04-26 2003-01-31 Square Co Ltd ユーザ名称切替方法及びシステム、端末、記録媒体並びにプログラム
JP2003340161A (ja) * 2002-05-31 2003-12-02 Konami Co Ltd サーバ装置及びプログラム
JP2004127247A (ja) * 2002-06-10 2004-04-22 Microsoft Corp 情報の管理および通信を行うためのプレゼンスおよび通知システム

Patent Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH04196848A (ja) * 1990-11-28 1992-07-16 Hitachi Ltd 電子メールシステム
JPH07183890A (ja) * 1993-12-24 1995-07-21 Fuji Xerox Co Ltd ネームサービスシステム
JPH113316A (ja) * 1997-06-13 1999-01-06 Sony Corp 伝送媒体、情報処理方法および装置
JP2000032033A (ja) * 1998-07-08 2000-01-28 Fujitsu Ltd 情報交換方法、情報管理流通装置、情報管理装置、情報流通装置、情報管理流通プログラムを記録したコンピュータ読み取り可能な記録媒体、情報管理プログラムを記録したコンピュータ読み取り可能な記録媒体及び情報流通プログラムを記録したコンピュータ読み取り可能な記録媒体
JP2000149063A (ja) * 1998-11-17 2000-05-30 Sony Corp 情報処理装置および方法、並びに提供媒体
JP2001075887A (ja) * 1999-09-06 2001-03-23 Matsushita Electric Ind Co Ltd ユーザ情報管理装置
JP2003030362A (ja) * 2001-04-26 2003-01-31 Square Co Ltd ユーザ名称切替方法及びシステム、端末、記録媒体並びにプログラム
JP2003340161A (ja) * 2002-05-31 2003-12-02 Konami Co Ltd サーバ装置及びプログラム
JP2004127247A (ja) * 2002-06-10 2004-04-22 Microsoft Corp 情報の管理および通信を行うためのプレゼンスおよび通知システム

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009110255A (ja) * 2007-10-30 2009-05-21 Nec Commun Syst Ltd 通信端末、そのコンピュータプログラム、そのデータ配信方法、これを用いたデータ配信システム
JP2016066917A (ja) * 2014-09-25 2016-04-28 Kddi株式会社 コンテンツ共有システム及びコンテンツ共有方法
JP2016116100A (ja) * 2014-12-16 2016-06-23 Kddi株式会社 管理サーバ、コンテンツ共有システム及びコンテンツ共有方法

Also Published As

Publication number Publication date
JP4536708B2 (ja) 2010-09-01

Similar Documents

Publication Publication Date Title
JP3985954B2 (ja) クライアント管理方法及び装置
US10397788B2 (en) Multimedia message service method and system
JP5049438B2 (ja) 存在管理システム及び方法
JP5416877B2 (ja) 存在管理システム、多重アクセスネットワーク及び処理方法
JP4668503B2 (ja) 存在管理システム、コンピュータ・プログラム、多重アクセス通信ネットワーク及び方法
US8458272B2 (en) Presence system and information processing equipment, dynamic buddy list generation method in presence system, and presence notification destination controlling method and its program for use with presence system
US9462046B2 (en) Degrees of separation for handling communications
US8200755B2 (en) Presence administration method and device
US7836126B2 (en) Business presence system and method
JP4431000B2 (ja) 送信者のプレゼンスを示す指示を伴う電子メール・メッセージを配信する方法および機器
KR20050121222A (ko) 사용자에게 알려진 것으로 간주되는 식별자를 식별 및사용하는 방법
WO2007048339A1 (fr) Procede de notification d'information de presence, serveur de presence, client et systeme
JP4536708B2 (ja) クライアント管理方法及び装置及び記録媒体
JP2004013824A (ja) プレゼンス管理方法及び装置
JP2014147128A (ja) 存在管理システム、格納媒体、多重アクセス通信ネットワーク及び動作方法
JP4046534B2 (ja) プレゼンス管理方法及びプレゼンス設定方法
JP4427957B2 (ja) プレゼンスシステム及びそれに用いるプレゼンス通知先制御方法並びにそのプログラム
JP4288410B2 (ja) プレゼンスシステム、プレゼンスサーバおよびプログラム
JP4504396B2 (ja) プレゼンス管理方法及び装置
JP2005184437A (ja) 電子メール送受信装置およびそのプログラム
JP2001147891A (ja) 状態管理方法及び状態管理システム
JP2005275755A (ja) 状態情報通知方法及びそのシステム

Legal Events

Date Code Title Description
RD02 Notification of acceptance of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7422

Effective date: 20080929

RD04 Notification of resignation of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7424

Effective date: 20080930

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20090526

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20090727

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20100413

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20100531

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20100615

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20100616

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130625

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130625

Year of fee payment: 3

LAPS Cancellation because of no payment of annual fees