JP4151356B2 - プログラム、情報処理方法および装置 - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明はプログラム、情報処理方法および装置に関し、特に、通信相手の装置との間で利用可能な機能の状態に関する情報の授受に必要な負荷を軽減することができるようにしたプログラム、情報処理方法および装置に関する。
【０００２】
【従来の技術】
最近、インターネットが普及し、インターネットを利用して各種のデータを相手側と授受するユーザが増えてきた。データの授受を行うシステムとしては、例えば、インターネットを介してテキスト情報の授受を行い、リアルタイムに相手との通信を行うインスタントメッセージ通信システム等が存在する。
【０００３】
インスタントメッセージ通信システムは、通常、IMPP（Instant Messaging and presence protocol）を用いて構築されており、相手のプレゼンス情報の受信、および相手へのプレゼンス情報の送信が可能となっている。
【０００４】
このプレゼンス情報は、通常、インスタントメッセージサービスを提供するサーバで管理される情報であり、通信相手によって変えることのできない唯一の情報である。すなわち、プレゼンス情報を送信する場合、友達（通信相手）として登録されている全ての人の装置に対して、同じプレゼンス情報が送信される。
【０００５】
図１は、従来のIMPPを用いたインスタントメッセージ通信システムの例を示す図である。
【０００６】
図１において、サーバ１は、インターネットに代表されるネットワーク５に接続されており、同様にネットワーク５に接続されているクライアント２乃至４に対して、インスタントメッセージサービスを提供している。
【０００７】
サーバ１は、インスタントメッセージサービスを提供しているクライアントに関する情報をリスト１１として保持し、クライアント２乃至４に対して、ID（IDentification）として、それぞれ、A@imsg，B@imsg，C@imsgを割り当てて、それらの状態を管理している。
【０００８】
図１に示されるように、リスト１１には、クライアント２乃至４（またはそれらのユーザ）の状態を示すプレゼンス情報リスト１１−１、並びに、各クライアントが友達（通信相手）として指定するクライアントのリストである友達リスト１１−２，１１−３、および１１−４が含まれている。
【０００９】
図１の例においては、A@imsg（クライアント２）は、B@imsg（クライアント３）およびC@imsg（クライアント４）を友達（通信相手）として予め指定しており、B@imsgおよびC@imsgは、いずれもA@imsgを友達として予め指定している。また、A@imsgはオンライン中であり、B@imsgは食事中であり、C@imsgは仕事中である。
【００１０】
プレゼンス情報は、各クライアントがログイン後、サーバ１に供給する情報であり、サーバ１は、取得したプレゼンス情報をプレゼンス情報リスト１１−１としてリスト１１に含めて保持し、管理する。
【００１１】
プレゼンス情報に関する通信は、全てサーバ１とクライアント２乃至４との間に生成される１つのTCP/IPセッションで行われる。
【００１２】
例えば、B@imsgのみがログインしている場合にA@imsgがログインすると、このときにA@imsg（クライアント２）がサーバ１に送信したプレゼンス情報は、プレゼンス情報リスト１１−１に記録される。サーバ１は、さらに、このプレゼンス情報を、A@imsgの友達として登録されており、かつ、ログイン中であるB@imsg（クライアント３）に供給する。
【００１３】
図２は、A@imsgがサーバ１に供給するプレゼンス情報の例を示す図である。図２において、プレゼンス情報はタグ<presence>に囲まれて定義されており、タグ<status>に囲まれた情報「オンライン」がプレゼンス情報リスト１１−１に記録される。
【００１４】
そしてさらに、サーバ１は、プレゼンス情報リスト１１−１に記録されているB@imsgのプレゼンス情報である「食事中」をA@imsgに供給する。
【００１５】
この状態から更に、C@imsgがログインすると、サーバ１は、その際にC@imsgより供給されたプレゼンス情報（「仕事中」）を、プレゼンス情報リスト１１−１に記録するとともに、友達リスト１１−４に基づいて、A@imsgに供給し、さらに、プレゼンス情報リスト１１−１に記録されているA@imsgのプレゼンス情報（「オンライン」）をC@imsgに供給する。
【００１６】
図３は、図１のインスタントメッセージ通信システムにおけるプレゼンス情報の更新の様子を示す図である。
【００１７】
図３に示すように、A@imsg（クライアント２）が新たなプレゼンス情報２１−１「退席中」を、ネットワーク５を介してサーバ１に供給すると、この情報は、サーバ１により、リスト１１のプレゼンス情報リスト１１−１に上書き記録される。
【００１８】
サーバ１は、さらに、A@imsgの友達リスト１１−２に基づいて、B@imsgおよびC@imsgに、そのプレゼンス情報「退席中」を、それぞれA@imsgのプレゼンス情報２１−２および２１−３として供給する。
【００１９】
以上のようなインスタントメッセージ通信システムに関する概念は、IMPPに開示されている（例えば、非特許文献１参照）。このようなインスタントメッセージ通信システムを用いることにより、クライアント間でリアルタイムにテキスト情報を送受信するだけでなく、各クライアントが提供するサービスの状態等の情報を他のクライアントに提供することもできる。
【００２０】
【非特許文献１】
H. Sugano、外４名、“Common Presence and Instant Messaging (CPIM) Presence Information Data Format”、[online]、２００２年５月、INTERNET-DRAFT、［平成１４年８月２７日検索］、インターネット,<URL: http://search.ietf.org/internet-drafts/draft-ietf-impp-cpim-pidf-05.txt>
【００２１】
【発明が解決しようとする課題】
しかしながら、以上のような方法においては、各クライアントが提供するサービスの状態等の情報はクライアント毎の情報として提供されており、各クライアントが提供するサービス毎にアナウンスすることができなかった。従って、インスタントメッセージ通信システムを用いて各クライアント間で提供されるサービスに関する情報の授受を行う場合、不要な情報も供給されてしまい、情報の授受の負荷が大きくなってしまう場合があるという課題があった。
【００２２】
本発明はこのような状況に鑑みてなされたものであり、通信相手の装置との間で利用可能な機能の状態に関する情報の授受に必要な負荷を軽減することができるようにしたものである。
【００２３】
【課題を解決するための手段】
本発明のプログラムは、ネットワークを介して、予め通信相手として登録されている複数の他の情報処理装置と情報を授受する情報処理装置を制御するコンピュータに、情報処理装置が有する機能を示す機能毎の情報のそれぞれに、情報処理装置が有する機能に対応する他の情報処理装置が有する機能およびその状態を示す機能毎の情報を関連付けて登録する登録ステップと、情報処理装置が有する機能の状態を示す機能毎の情報を、登録ステップにより登録された情報に基づいて、情報処理装置が有する機能に対応する機能を有する他の情報処理装置に対して供給する第１の供給ステップとを実行させることを特徴とする。
【００２４】
前記他の情報処理装置が有する機能を示す機能毎の情報を取得する第１の取得ステップと、他の情報処理装置が有する機能の状態を示す機能毎の情報を取得する第２の取得ステップとをさらに実行させ、登録ステップは、第１の取得ステップにより取得された他の情報処理装置が有する機能を示す機能毎の情報と、他の情報処理装置が有する機能に対応する、第２の取得ステップにより取得された状態を示す情報を、他の情報処理装置が有する機能に対応する情報処理装置が有する機能を示す情報に関連付けて登録するようにすることができる。
【００２５】
前記情報処理装置が有する機能を示す機能毎の情報を、各情報処理装置が有する機能を示す情報を管理する情報管理装置に供給する第２の供給ステップをさらに実行させるようにすることができる。
【００２７】
本発明の情報処理方法は、情報処理装置が有する機能を示す機能毎の情報のそれぞれに、情報処理装置が有する機能に対応する他の情報処理装置が有する機能およびその状態を示す機能毎の情報を関連付けて登録する登録ステップと、情報処理装置が有する機能の状態を示す機能毎の情報を、登録ステップにより登録された情報に基づいて、情報処理装置が有する機能に対応する機能を有する他の情報処理装置に対して供給する第１の供給ステップとを含むことを特徴とする。
【００２８】
前記他の情報処理装置が有する機能を示す機能毎の情報を取得する第１の取得ステップと、他の情報処理装置が有する機能の状態を示す機能毎の情報を取得する第２の取得ステップとをさらに含み、登録ステップは、第１の取得ステップにより取得された他の情報処理装置が有する機能を示す機能毎の情報と、他の情報処理装置が有する機能に対応する、第２の取得ステップにより取得された状態を示す情報を、他の情報処理装置が有する機能に対応する情報処理装置が有する機能を示す情報に関連付けて登録するようにすることができる。
【００２９】
前記情報処理装置が有する機能を示す機能毎の情報を、各情報処理装置が有する機能を示す情報を管理する情報管理装置に供給する第２の供給ステップをさらに含むようにすることができる。
【００３１】
本発明の情報処理装置は、情報処理装置が有する機能を示す機能毎の情報のそれぞれに、情報処理装置が有する機能に対応する他の情報処理装置が有する機能およびその状態を示す機能毎の情報を関連付けて登録する登録手段と、情報処理装置が有する機能の状態を示す機能毎の情報を、登録手段により登録された情報に基づいて、情報処理装置が有する機能に対応する機能を有する他の情報処理装置に対して供給する第１の供給手段とを備えることを特徴とする。
【００３２】
前記他の情報処理装置が有する機能を示す機能毎の情報を取得する第１の取得手段と、他の情報処理装置が有する機能の状態を示す機能毎の情報を取得する第２の取得手段とをさらに実行させ、登録手段は、第１の取得手段により取得された他の情報処理装置が有する機能を示す機能毎の情報と、他の情報処理装置が有する機能に対応する、第２の取得手段により取得された状態を示す情報を、他の情報処理装置が有する機能に対応する情報処理装置が有する機能を示す情報に関連付けて登録するようにすることができる。
【００３３】
前記情報処理装置が有する機能を示す機能毎の情報を、各情報処理装置が有する機能を示す情報を管理する情報管理装置に供給する第２の供給手段をさらに備えるようにすることができる。
【００６８】
本発明においては、情報処理装置が有する機能を示す機能毎の情報のそれぞれに、情報処理装置が有する機能に対応する他の情報処理装置が有する機能およびその状態を示す機能毎の情報が関連付けて登録され、情報処理装置が有する機能の状態を示す機能毎の情報が、登録された情報に基づいて、情報処理装置が有する機能に対応する機能を有する他の情報処理装置に対して供給される。
【００７２】
【発明の実施の形態】
図４は、本発明を適用したインスタントメッセージ通信システムの例を示す図である。
【００７３】
図４において、サーバ３１は、インターネットに代表されるネットワーク３５に接続されており、同様に接続されているクライアント３２乃至３４に対してインスタントメッセージサービスを提供している。
【００７４】
サーバ３１は、クライアント３２乃至３４に対して、IDとして、それぞれ、A@imsg，B@imsg，C@imsgを割り当てている。図１の場合と同様に、A@imsg（クライアント２）は、B@imsg（クライアント３）およびC@imsg（クライアント４）を友達（通信相手）として予め指定しており、B@imsgおよびC@imsgは、いずれもA@imsgを友達として予め指定しており、それらの情報はサーバ３１に登録されている。
【００７５】
クライアント３２は、機能リスト４２に示されるように、MPEG４（Moving Picture Expert Group４）ストリーミング送信機能（MPEG４ Streaming Tx）と、MPEG２ストリーミング送信機能（MPEG２ Streaming Tx）とを備えるパーソナルコンピュータである。クライアント３３は、機能リスト４３に示されるように、MPEG４ストリーミング受信機能（MPEG４ Streaming Rx）と、MPEG２ストリーミング受信機能（MPEG２ Streaming Rx）とを備えるパーソナルコンピュータであり、クライアント３４は、機能リスト４４に示されるように、MPEG４ストリーミング受信機能（MPEG４ Streaming Rx）を備えるパーソナルコンピュータである。
【００７６】
クライアント３２が有するMPEG４ストリーミング送信機能（MPEG４ Streaming Tx）は、MPEG４データを同時に１チャンネル送信することができ、MPEG２ストリーミング送信機能（MPEG２ Streaming Tx）は、MPEG２データを同時に１チャンネル送信することができる。
【００７７】
同様に、クライアント３３および３４が有する、MPEG４ストリーミング受信機能（MPEG４ Streaming Rx）は、MPEG４データを同時に１チャンネル受信することができ、クライアント３３が有するMPEG２ストリーミング受信機能（MPEG２ Streaming Rx）は、MPEG２データを同時に１チャンネル受信することができる。
【００７８】
これらの機能を用いて、クライアント３２は、クライアント３３に対してMPEG4データおよびMPEG２データを、ネットワーク３５を介して、それぞれ1チャンネルずつ同時に送信することができる。また、クライアント３２は、クライアント３４に対してMPEG4データを、ネットワーク３５を介して、1チャンネル送信することもできる。
【００７９】
クライアント３２乃至３４は、通信相手の利用可能な機能の状態を取得するために、サーバ３１が提供するインスタントメッセージ通信サービスを利用する。すなわち、クライアント３２乃至３４は、インスタントメッセージ通信サービスのプレゼンス情報を用いて自分の有する機能の状態を通信相手となるクライアントに供給するとともに、通信相手となるクライアントの機能の状態を取得する。
【００８０】
なお、クライアント間で授受されるプレゼンス情報は、実際には、サーバ３１を介して授受されるが、特に必要がない場合は適宜その説明を省略する。
【００８１】
図５は、図４に示すサーバ３１の構成例を示す図である。
【００８２】
図５において、CPU（Central Processing Unit）５１は、ROM（Read Only Memory）５２に記憶されているプログラム、または記憶部７３からRAM（Random Access Memory）５３にロードされたプログラムに従って各種の処理を実行する。RAM５３にはまた、CPU５１が各種の処理を実行する上において必要なデータなども適宜記憶される。
【００８３】
ユーザ管理部５４は、CPU５１の制御に基づいて、インスタントメッセージ通信サービスを提供するクライアントに関する情報を管理する。例えば、ユーザ管理部５４は、各クライアントの友達リストや、各クライアントの状態を管理しており、サーバ３１は、その情報に基づいて、クライアントより供給されるプレゼンス情報を友達（通信相手）であるクライアントに供給する。
【００８４】
CPU５１、ROM５２、RAM５３、およびユーザ管理部５４は、バス６０を介して相互に接続されている。このバス６０にはまた、入出力インタフェース７０も接続されている。
【００８５】
入出力インタフェース７０には、キーボード、マウスなどよりなる入力部７１、CRT（Cathode Ray Tube）、LCD（Liquid Crystal Display）などよりなるディスプレイ、並びにスピーカなどよりなる出力部７２、ハードディスクなどにより構成される記憶部７３、モデム、ターミナルアダプタ、またはLANアダプタなどにより構成される通信部７４が接続されている。
【００８６】
記憶部７３には、インスタントメッセージ通信サービスを提供するためのプログラムやデータの他に、予めクライアントが登録した友達リストなどの情報を記憶しており、必要に応じて、CPU５１、RAM５３、およびユーザ管理部５４等に供給する。
【００８７】
通信部２４は、モデムやターミナルアダプタ等を用いた通信の他にも、例えば、USB（Universal Serial Bus）、IEEE１３９４（Institute of Electrical and Electronic Engineers）、RS‐２３２C（Recommended Standard 232 revision C）、またはSCSI（Small Computer System Interface）等の各種の規格を用いた通信処理を行う機能を有している。
【００８８】
入出力インタフェース７０にはまた、必要に応じてドライブ８０が接続され、磁気ディスク８１、光ディスク８２、光磁気ディスク８３、或いは半導体メモリ８４などが適宜装着され、それらから読み出されたコンピュータプログラムが、必要に応じて記憶部７３にインストールされる。
【００８９】
図６は、図４に示すクライアント３２の構成例を示す図である。
【００９０】
図６において、CPU１０１は、ROM１０２に記憶されているプログラム、または記憶部１２３からRAM１０３にロードされたプログラムに従って各種の処理を実行する。RAM１０３にはまた、CPU１０１が各種の処理を実行する上において必要なデータなども適宜記憶される。
【００９１】
MPEG４ストリーミング送信処理部４２−１は、CPU１０１に制御され、通信部１２４を介してMPEG４データのストリーミング送信に関する処理を行い、図４の機能リスト４２のMPEG４ Streaming Txの機能を実現する。同様に、MPEG２ストリーミング送信処理部４２−２は、CPU１０１に制御され、通信部１２４を介してMPEG２データのストリーミング送信に関する処理を行い、図４の機能リスト４２のMPEG２ Streaming Txの機能を実現する。
【００９２】
CPU１０１は、通信部１２４、MPEG４ストリーミング送信処理部４２−１およびMPEG２ストリーミング送信処理部４２−２を制御して、ネットワーク３５を介して、クライアント３３または３４に対して、MPEG４データまたはMPEG２データのストリーミング送信を行う。
【００９３】
CPU１０１、ROM１０２、RAM１０３、MPEG４ストリーミング送信処理部４２−１、およびMPEG２ストリーミング送信処理部４２−２は、バス１１０を介して相互に接続されている。このバス１１０にはまた、入出力インタフェース１２０も接続されている。
【００９４】
入出力インタフェース１２０には、キーボード、マウスなどよりなる入力部１２１、CRTや、LCDなどよりなるディスプレイ、並びにスピーカなどよりなる出力部１２２、ハードディスクなどにより構成される記憶部１２３、モデム、ターミナルアダプタ、またはLANアダプタなどにより構成される通信部１２４が接続されている。
【００９５】
入出力インタフェース１２０にはまた、必要に応じてドライブ１３０が接続され、磁気ディスク１３１、光ディスク１３２、光磁気ディスク１３３、或いは半導体メモリ１３４などが適宜装着され、それらから読み出されたコンピュータプログラムが、必要に応じて記憶部１２３にインストールされる。
【００９６】
図７は、図４に示すクライアント３３の構成例を示す図である。
【００９７】
図７において、CPU１５１乃至RAM１５３、並びに、バス１６０乃至半導体メモリ１８４は、図６に示されるクライアント３２のCPU１０１乃至RAM１０３、並びに、バス１１０乃至半導体メモリ１３４にそれぞれ対応しており、図６の場合と同様の構成であるので、その説明は省略する。
【００９８】
バス１６０に接続されているMPEG４ストリーミング受信処理部４３−１は、CPU１５１に制御され、通信部１７４を介してMPEG４データのストリーミング受信に関する処理を行い、図４の機能リスト４３のMPEG４ Streaming Rxの機能を実現する。同様に、バス１６０に接続されているMPEG２ストリーミング受信処理部４２−２は、CPU１０１に制御され、通信部１７４を介してMPEG２データのストリーミング受信に関する処理を行い、図４の機能リスト４３のMPEG２ Streaming Rxの機能を実現する。
【００９９】
CPU１５１は、通信部１７４、MPEG４ストリーミング受信処理部４３−１およびMPEG２ストリーミング受信処理部４３−２を制御して、ネットワーク３５を介して、クライアント３２より供給されるMPEG４データまたはMPEG２データのストリーミング受信を行う。
【０１００】
図８は、図４に示すクライアント３４の構成例を示す図である。
【０１０１】
図８において、CPU２０１乃至RAM２０３、並びに、バス２１０乃至半導体メモリ２３４は、図６に示されるクライアント３２のCPU１０１乃至RAM１０３、並びに、バス１１０乃至半導体メモリ１３４にそれぞれ対応しており、図６の場合と同様の構成であるので、その説明は省略する。
【０１０２】
バス２１０に接続されているMPEG４ストリーミング受信処理部４４−１は、CPU２０１に制御され、通信部２２４を介してMPEG４データのストリーミング受信に関する処理を行い、図４の機能リスト４４のMPEG４ Streaming Rxの機能を実現する。
【０１０３】
CPU２０１は、通信部２２４およびMPEG４ストリーミング受信処理部４４−１を制御して、ネットワーク３５を介して、クライアント３２より供給されるMPEG４データのストリーミング受信を行う。
【０１０４】
図４に戻り、MPEG４データおよびMPEG２データをストリーミング送信する機能（プロバイダとしての機能）を有するA@imsg（クライアント３２）は、サーバ３１の提供するインスタントメッセージ通信サービスを利用して、MPEG４データまたはMPEG２データをストリーミング受信する機能（コンスーマとしての機能）を有するB@imsg（クライアント３３）およびC@imsg（クライアント３４）に対して、プロバイダとしての機能に関するプレゼンス情報を供給する。
【０１０５】
なお、以下においては、MPEG４データまたはMPEG２データをストリーミング送信する機能を有する装置（図４の場合、クライアント３２）をプロバイダと称し、MPEG４データまたはMPEG２データをストリーミング受信する機能を有する装置（図４の場合、クライアント３３および３４）をコンスーマと称する。
【０１０６】
図４の例におけるプロバイダ（クライアント３２）による、自分自身が有する機能のプレゼンス情報をコンスーマ（クライアント３３およびクライアント３４）に供給する処理を、図９のフローチャートを参照して説明する。
【０１０７】
最初に、プロバイダであるクライアント３２のCPU１０１は、ステップＳ１において、各部を制御して、クライアント３２が有する機能（MPEG4 Streaming TxおよびMPEG2 Streaming Tx）に関するプレゼンス情報であるサービス情報を作成し、友達（通信相手）であるクライアント３３および３４に供給する。
【０１０８】
クライアント３３および３４は、そのサービス情報を取得すると、そのサービス情報に基づいて、通信可能な機能を判断する。これにより、コンスーマであるクライアント３３および３４は、プロバイダであるクライアント３２が提供する機能およびその状態を知ることができ、サービス情報の供給元であるクライアント３２とそれらの機能を用いて通信を行うことができる。
【０１０９】
ステップＳ１の処理を終了したCPU１０１は、ステップＳ２において、MPEG4 Streaming TxおよびMPEG2 Streaming Txの状態を監視し、サービスの状態が変化したか否かを判定する。例えば、MPEG4 Streaming Txの機能を用いてコンスーマであるクライアント３３との通信（MPEG４データのストリーミング送信）が開始されると、MPEG4 Streaming Txの機能はこれ以上の利用は不可能となる。CPU１０１は、MPEG４ストリーミング送信処理部４２−１およびMPEG２ストリーミング送信処理部４２−２を制御し、MPEG4 Streaming TxおよびMPEG2 Streaming Txの状態が変化したか否かを判定する。
【０１１０】
サービスの状態が変化したと判定した場合、CPU１０１は、ステップＳ３において、サービス情報を更新し、通信部１２４を制御してコンスーマにサービス情報を供給し、処理をステップＳ４に進める。
【０１１１】
また、ステップＳ２において、サービスの状態が変化していないと判定した場合、CPU１０１は、ステップＳ３の処理を省略し、ステップＳ４に処理を進める。
【０１１２】
ステップＳ４において、CPU１０１は、プレゼンス情報供給処理を終了するか否かを判定し、終了しないと判定した場合、処理をステップＳ２に戻し、それ以降の処理を繰り返す。
【０１１３】
また、サービスの提供が終了される等してプレゼンス情報供給処理を終了すると判定した場合、CPU１０１は、処理をステップＳ５に進め、終了処理を行い、プレゼンス情報供給処理を終了する。
【０１１４】
すなわち、CPU１０１は、クライアント３２がインスタントメッセージ通信サービスにログインした後、クライアント３２が有する機能の状態のプレゼンス情報であるサービス情報を友達であるクライアント３３および３４に供給する。また、CPU１０１は、サービスの状態が変化した場合、更新されたサービス情報を供給する。
【０１１５】
以上のようにしてプロバイダであるクライアント３２は、自分自身の有する機能のプレゼンス情報をコンスーマに供給することができる。
【０１１６】
以上において、プロバイダであるクライアント３２は、サービス情報を、サーバ３１を介してクライアント３２および３３に供給する。このとき、サーバ３１は、サービス情報を保持し、管理する。そして、クライアント３２の友達である新たなクライアントがログインした場合、サーバ３１は、保持しているクライアント３２のサービス情報をそのクライアントに供給する。
【０１１７】
すなわち、クライアント３２は、サービスの状態が変化した場合のみ新たなサービス情報を供給するだけで、クライアント３２の友達であり、ログインしている全てのクライアントに最新のサービス情報を提供することができる。
【０１１８】
具体的な例として、図４のクライアント３２が、クライアント３３および３４が既にログインしているインスタントメッセージ通信サービスにログインした場合のプレゼンス情報に関する処理の流れを、図１０のタイミングチャートを参照して説明する。
【０１１９】
最初に、ステップＳ４１において、インスタントメッセージ通信サービスにログインしたクライアント３２は、図９のステップＳ１の処理により、サービス情報を作成し、友達であるクライアント３３および３４に供給する。ステップＳ３１においてそのサービス情報を取得したクライアント３３は、ステップＳ３２においてサービス情報を解析する。同様に、クライアント３４は、ステップＳ５１においてクライアント３２が供給したサービス情報を取得し、ステップＳ５２において解析する。これにより、クライアント３３および３４は、クライアント３２が提供する機能およびその状態を知ることができる。
【０１２０】
図１１は、クライアント３２がクライアント３３および３４にプレゼンス情報を提供する様子を示す図である。
【０１２１】
図１１において、クライアント３２が有するMPEG４ストリーミング送信機能（MPEG４ Streaming Tx）４２−１およびMPEG２ストリーミング送信機能（MPEG２ Streaming Tx）４２−２には、それぞれプロバイダとしての機能の通し番号（provider_ep）が割り当てられている。すなわち、MPEG４ストリーミング送信機能４２−１は、「provider_ep=１」であり、MPEG２ストリーミング送信機能４２−２は、「provider_ep=２」である。
【０１２２】
クライアント３２は、矢印２５１および２５３のように、クライアント３３および３４に、図１２に示すようなプレゼンス情報を供給する。
【０１２３】
図１２において、プレゼンス情報は、タグ<presence>とタグ</presence>に囲まれており、タグ<status>およびタグ</status>に囲まれた情報（オンライン）は、A@imsg（クライアント３２）の状態を示し、タグ<service>とタグ</service>に囲まれた情報は、クライアント３２が有するプロバイダとしての機能（MPEG４ Streaming TxおよびMPEG２ Streaming Tx）に関する情報である。
【０１２４】
タグ<announce provider_ep=”１” profile=”MPEG4 Steraming”>とタグ<announce>に囲まれた情報は、図１１のMPEG４ストリーミング送信機能４２−１に関する情報であり、機能の状態を示す情報は、タグ<show>とタグ</show>に囲まれている。図１２の例の場合、MPEG４ストリーミング送信機能４２−１の状態は「available」であり、MPEG４データを送信可能な状態である。
【０１２５】
同様に、タグ<announce provider_ep=”２” profile=”MPEG２ Steraming”>とタグ<announce>に囲まれた情報は、MPEG２ストリーミング送信機能４２−２に関する情報である。図１２の例の場合、機能の状態は「available」であり、MPEG２データを送信可能な状態である。
【０１２６】
図１０に戻り、サービス情報を解析した結果、クライアント３２のプロバイダとしての機能を利用して通信を行う場合、クライアント３３は、ステップＳ３３において通信開始要求をクライアント３２に供給する。ステップＳ４２において、その通信開始要求を取得したクライアント３２は、ステップＳ４３において通信準備処理を行い、プロバイダとしての機能を用いてストリーミング送信を開始する。
【０１２７】
ストリーミング送信が開始されるとサービスの状態が変化するので、ステップＳ４４において、クライアント３２は、図９のステップＳ３の処理により、サービス情報を更新し、クライアント３３および３４に更新されたサービス情報を供給する。
【０１２８】
クライアント３３は、ステップＳ３４においてそのサービス情報を取得すると、ステップＳ３５においてそのサービス情報を解析する。同様に、クライアント３５もステップＳ５３においてクライアント３２より供給されたサービス情報を取得すると、ステップＳ５４においてそのサービス情報を解析する。これにより、クライアント３３および３４は、クライアント３２が有するプロバイダとしての機能の最新の状態を把握することができる。
【０１２９】
そして、クライアント３２は、ステップＳ４５において、要求された送信処理を開始し、クライアント３３は、ステップＳ３６において、その送信処理に対応する受信処理を開始する。
【０１３０】
図１３は、クライアント３２および３３の間でストリーミングが開始された場合の様子を示す図である。
【０１３１】
図１０のステップＳ３３の処理によるクライアント３３の要求により、クライアント３２のMPEG４ストリーミング送信機能４２−１を利用したストリーミング通信が開始されると、MPEG４ストリーミング送信機能４２−１の状態が利用不可になり、クライアント３２は、図１０のステップＳ４４の処理によりサービス情報を更新し、矢印２６１および２６３のように、図１４に示されるようなプレゼンス情報を、クライアント３３および３４に供給する。
【０１３２】
図１４に示されるように、このプレゼンス情報においては、MPEG４ストリーミング送信機能４２−１の状態は「unavailable」であり、利用不可能であることが示されている。
【０１３３】
以上のように、各クライアントが有する機能を利用して通信を行う場合に、それらの機能の状態を、インスタントメッセージ通信サービスのプレゼンス情報を利用して授受することにより、処理に必要な負荷を軽減することができる。
【０１３４】
なお、図１４のプレゼンス情報には、MPEG２ストリーミング送信機能４２−２の状態に関する情報も含まれているが、図１４のプレゼンス情報は、本来、図１３に示されるように、MPEG４ストリーミング送信機能（MPEG４ Streaming Tx）４２−１が利用不可になったことを伝えるための情報であり、MPEG２ストリーミング送信機能４２−２に関する情報は不要である。
【０１３５】
しかしながら、クライアント３２は最新のプレゼンス情報のみを供給するため、クライアント３２が図１５に示されるデータのような、MPEG４ストリーミング送信機能４２−１に関する情報だけの、必要最小限のプレゼンス情報を供給するようにプレゼンス情報を更新すると、新たにログインされたユーザに対しても図１５に示されるようなプレゼンス情報を供給してしまう場合がある。従って、クライアント３２は、図１４のプレゼンス情報を供給するように、プレゼンス情報を更新する。
【０１３６】
図１６は、クライアント３２および３３の間でストリーミングが開始された場合の様子の他の例を示す図である。
【０１３７】
図１６においては、クライアント３２とクライアント３３の間で、MPEG２ストリーミングが開始されている。
【０１３８】
この場合、クライアント３２は、本来、MPEG２ストリーミング受信機能を有するクライアント３３に対してのみ、MPEG２ストリーミング送信機能４２−２が利用不可になったことを伝えるだけでよい。
【０１３９】
しかしながら、図１３の場合と同様に、クライアント３２は、図１７に示されるようにMPEG４ストリーミング送信機能４２−１に関する情報とMPEG２ストリーミング送信機能４２−２に関する情報との両方を含むプレゼンス情報をクライアント３３および３４に供給する。
【０１４０】
この場合、クライアント３３および３４にとって、MPEG４ストリーミング送信機能４２−１の状態に関する情報は、以前に取得した情報と同じであり不要である。さらに、クライアント３４にとっては、MPEG２ストリーミング送信機能４２−２の状態に関する情報も不要である。
【０１４１】
このような冗長な情報を無くすために、図１８のように、プレゼンス情報の概念を２種類に分割した構造にする。
【０１４２】
プレゼンス情報３０１は、「オンライン」や「仕事中」等、クライアントの状態に関する情報や、クライアントが有する機能の情報等を含むメインプレゼンス情報３０２、機能の状態に関する情報等を含む、機能ごとの情報であるサブプレゼンス情報３０３Ａ乃至３０３Ｎにより構成される。
【０１４３】
メインプレゼンス情報は、ログインした場合や、状態が変化した場合にサーバ３１に供給され、サーバ３１によって管理され、供給する必要のあるクライアントに適宜、自動的に供給される。
【０１４４】
サブプレゼンス情報３０３Ａは、プロバイダとしての機能に関する情報であるプロバイダサブプレゼンス情報３０４Ａとコンスーマとしての機能に関する情報であるコンスーマサブプレゼンス情報３０５Ａにより構成されている。なお、サブプレゼンス情報３０３Ｂ乃至３０３Ｎについても同様である。
【０１４５】
サブプレゼンス情報３０３Ａ乃至３０３Ｎは、そのクライアントが有する機能ごとの情報であり、機能の通し番号の数だけ存在する。
【０１４６】
例えば、クライアント３２は、プロバイダとしての機能であるMPEG４ストリーミング送信機能４２−１とMPEG２ストリーミング送信機能４２−２を有しており、プレゼンス情報には、それぞれの機能に対応した２つのサブプレゼンス情報３０３Ａおよび３０３Ｂが含まれる。そして、サブプレゼンス情報３０３Ａは、プロバイダサブプレゼンス情報３０４Ａで構成され、サブプレゼンス情報３０３Ｂは、プロバイダサブプレゼンス情報３０４Ｂで構成される。
【０１４７】
また、クライアント３３は、コンスーマとしての機能であるMPEG４ストリーミング受信機能４３−１とMPEG２ストリーミング受信機能４３−２を有しており、プレゼンス情報には、それぞれの機能に対応した２つのサブプレゼンス情報３０３Ａおよび３０３Ｂが含まれる。そして、サブプレゼンス情報３０３Ａは、コンスーマサブプレゼンス情報３０５Ａで構成され、サブプレゼンス情報３０３Ｂは、コンスーマサブプレゼンス情報３０５Ｂで構成される。
【０１４８】
さらに、クライアント３４は、コンスーマとしての機能であるMPEG４ストリーミング受信機能４４−１を有しており、プレゼンス情報には、この機能に対応した１つのサブプレゼンス情報３０３Ａが含まれる。そして、そのサブプレゼンス情報３０３Ａは、コンスーマサブプレゼンス情報３０５Ａで構成される。
【０１４９】
なお、以下において、各機能に分けて説明する必要のない場合は、サブプレゼンス情報３０３と称する。同様に、プロバイダサブプレゼンス情報およびコンスーマサブプレゼンス情報についても、特に分けて説明する必要のない場合は、それぞれプロバイダサブプレゼンス情報３０４およびコンスーマサブプレゼンス情報３０５と称する。
【０１５０】
後述するように、プロバイダであるクライアントは、コンスーマであるクライアントを登録（レジストレーション）しており、コンスーマに関する情報を保持している。サブプレゼンス情報３０３は、このレジストレーション情報に基づいて、目的のコンスーマに供給される。
【０１５１】
次に、図１８に示されるプレゼンス情報を管理する処理について、図４のインスタントメッセージ通信システムの例を用いて、システムプロバイダとコンスーマに分けて説明する。最初に、図１９のフローチャートを参照して、プロバイダがメインプレゼンス情報を管理する処理について説明する。
【０１５２】
プロバイダである図４のクライアント３２は、インスタントメッセージ通信サービスにログインすると、図１９に示されるようなメインプレゼンス管理処理を実行する。
【０１５３】
最初に、クライアント３２のCPU１０１は、ステップＳ７１において、RAM１０３または記憶部１２３に予め記憶されているメインプレゼンス情報を取得し、通信部１２４を制御して、ネットワーク３５を介してサーバ３１に供給する。
【０１５４】
サーバ３１は、後述するように、供給されたメインプレゼンス情報をA@imsg（クライアント３２）の情報として管理するとともに、A@imsgの友達（通信相手）であり、ログイン中のB@imsg（クライアント３３）およびC@imsg（クライアント３４）に供給する。
【０１５５】
また、サーバ３１は、予め供給され、管理しているB@imsgおよびC@imsgのメインプレゼンス情報をA@imsgに供給する。さらに、サーバ３１は、A@imsgの新たな友達がログインした場合も、その友達のメインプレゼンス情報をA@imsgに供給する。
【０１５６】
ステップＳ７２において、CPU１０１は、通信部１２４を制御して、サーバ３１より送信されたメインプレゼンス情報を取得したか否かを判定し、取得したと判定した場合、取得したメインプレゼンス情報を解析し、RAM１０３に保持されている、友達であるB@imsgおよびC@imsgの状態に関する情報であるステータス情報を更新し、処理をステップＳ７４に進める。
【０１５７】
ステップＳ７２において、メインプレゼンス情報を取得していないと判定した場合は、CPU１０１は、ステップＳ７３の処理を省略し、ステップＳ７４に処理を進める。
【０１５８】
サーバ３１は、クライアントがログオフすると、その情報を、関係のある他のクライアントに供給する。
【０１５９】
ステップＳ７４において、CPU１０１は、通信部１２４を制御して、サーバ３１からその情報を供給されたか否かを判定し、他のクライアントがログオフしたか否かを判定する。ログオフしたと判定した場合、CPU１０１は、ステップＳ７５において、その情報に基づいて、ステータス情報を更新し、処理をステップＳ７６に進める。
【０１６０】
ステップＳ７４において、他のクライアントがログオフしていないと判定した場合、CPU１０１は、ステップＳ７５の処理を省略し、ステップＳ７６に処理を進める。
【０１６１】
CPU１０１は、ステップＳ７６において、ユーザの指示等に基づいて、メインプレゼンス情報管理処理を終了するか否かを判定する。終了しないと判定した場合、CPU１０１は、処理をステップＳ７２に戻し、それ以降の処理を繰り返す。
【０１６２】
また、ログオフするなどして、メインプレゼンス情報管理処理を終了すると判定した場合、CPU１０１は、ステップＳ７７において終了処理を行い、メインプレゼンス情報管理処理を終了する。
【０１６３】
すなわち、インスタントメッセージ通信サービスにログインすると、CPU１０１は、通信部１２４を制御して、メインプレゼンス情報をサーバ３１に供給した後、ログオフするまで他のクライアントのステータス情報を保持し、メインプレゼンス情報を取得したり、友達である他のクライアントがログオフしたりした場合は、そのステータス情報を更新する。
【０１６４】
次に、図２０のフローチャートを参照して、プロバイダによるレジストレーションの管理に関する処理について説明する。
【０１６５】
後述するように、プロバイダのメインプレゼンス情報を取得したコンスーマはユーザの指示等に基づいて、プロバイダにレジストレーション要求を供給する。
【０１６６】
プロバイダであるクライアント３２のCPU１０１は、ステップＳ９１において、通信部１２４を制御して、コンスーマよりレジストレーション要求を取得したか否かを判定する。取得したと判定した場合、CPU１０１は、ステップＳ９２において、そのレジストレーションを許可するか否かを判定する。許可すると判定した場合、CPU１０１は、処理をステップＳ９３に進め、RAM１０３に保持されており、レジストレーションを管理するための情報であるレジストレーション情報を更新し、ステップＳ９４において、通信部１２４を制御して、レジストレーション要求の供給元であるコンスーマにレジストレーションしたことを通知する応答を供給する。応答したCPU１０１は、処理をステップＳ９６に進める。
【０１６７】
ステップＳ９２において、レジストレーションを許可しないと判定した場合、CPU１０１は、ステップＳ９５において、レジストレーション要求の供給元であるコンスーマに、レジストレーションを拒否したことを通知する拒否応答を供給し、処理をステップＳ９６に進める。
【０１６８】
ステップＳ９１において、レジストレーション要求を取得していないと判定した場合、CPU１０１は、上述した処理を省略し、ステップＳ９６に処理を進める。
【０１６９】
ステップＳ９６において、CPU１０１は、通信部１２４を制御して、コンスーマより、コンスーマサブプレゼンス情報を取得したか否かを判定する。コンスーマは、コンスーマの機能の状態が変化するなどして、コンスーマサブプレゼンス情報を更新すると、更新されたコンスーマサブプレゼンス情報をプロバイダに供給する。
【０１７０】
コンスーマサブプレゼンス情報を取得したと判定した場合、CPU１０１は、ステップＳ９７において、その情報に基づいて、レジストレーション情報を更新した後、ステップＳ９８に処理を進める。
【０１７１】
ステップＳ９６において、コンスーマサブプレゼンス情報を取得していないと判定した場合、CPU１０１は、ステップＳ９７の処理を省略し、ステップＳ９８に処理を進める。
【０１７２】
ステップＳ９８において、CPU１０１は、通信部１２４を制御して、レジストレーション解除要求を取得したか否かを判定する。プロバイダによるレジストレーションを解除したい場合、コンスーマは、レジストレーション解除要求をそのプロバイダに供給する。
【０１７３】
レジストレーション解除要求を取得したと判定した場合、CPU１０１は、ステップＳ９９において、その情報をレジストレーション情報に反映させて更新し、ステップＳ１００において、レジストレーションを解除したことを通知するために、その応答をレジストレーション解除要求の供給元であるコンスーマに供給する。ステップＳ１００の処理が完了すると、CPU１０１は、処理をステップＳ１０１に進める。
【０１７４】
ステップＳ９８において、レジストレーション解除要求を取得していないと判定した場合、CPU１０１は、上述したステップＳ９９およびステップＳ１００の処理を省略し、ステップＳ１０１に処理を進める。
【０１７５】
CPU１０１は、ステップＳ１０１において、通信部１２４を制御して、サーバ３１より供給される情報に基づいて、コンスーマがログオフしたか否かを判定する。ログオフしたと判定した場合、CPU１０１は、ステップＳ１０２において、レジストレーション情報を更新し、処理をステップＳ１０３に進める。
【０１７６】
ステップＳ１０１において、コンスーマがログオフしていないと判定した場合、CPU１０１は、ステップＳ１０２の処理を省略し、ステップＳ１０３に処理を進める。
【０１７７】
ステップＳ１０３において、CPU１０１は、レジストレーション管理処理を終了するか否かを判定する。レジストレーション管理処理を終了しないと判定した場合、CPU１０１は、処理をステップＳ９１に戻し、それ以降の処理を繰り返す。
【０１７８】
ステップＳ１０３において、ユーザの指示等に基づいて、レジストレーション管理処理を終了すると判定した場合、CPU１０１は、ステップＳ１０４において終了処理を行い、レジストレーション管理処理を終了する。
【０１７９】
次に、図２１のフローチャートを参照して、プロバイダによるサブプレゼンス情報の管理に関する処理について説明する。
【０１８０】
最初に、プロバイダであるクライアント３２のCPU１０１は、ステップＳ１２１において、MPEG４ストリーミング送信処理部４２−１およびMPEG２ストリーミング送信処理部４２−２を制御し、サービスの状態が変化したか否かを判定する。MPEG４ストリーミング送信機能４２−１を用いた通信処理が開始されるなどして、サービスの状態が変化したと判定した場合、CPU１０１は、ステップＳ１２２において、その変化をプロバイダサブプレゼンス情報に反映させ更新した後、ステップＳ１２３に処理を進める。
【０１８１】
ステップＳ１２１において、サービスの状態が変化していないと判定した場合、CPU１０１は、上述したステップＳ１２２の処理を省略し、ステップＳ１２３に処理を進める。
【０１８２】
ステップＳ１２３において、CPU１０１は、レジストレーション情報に基づいて、新たにレジストレーションされたコンスーマが存在するか否かを判定し、存在すると判定した場合、ステップＳ１２４において、レジストレーションされたコンスーマにプロバイダサブプレゼンス情報を供給し、ステップＳ１２５に処理を進める。
【０１８３】
ステップＳ１２３において、新たにレジストレーションされたコンスーマは存在しないと判定した場合、CPU１０１は、ステップＳ１２４を省略し、ステップＳ１２５に処理を進める。
【０１８４】
ステップＳ１２５において、CPU１０１は、ステップＳ１２２の処理などにより、プロバイダサブプレゼンス情報が変化したか否かを判定し、変化したと判定した場合、ステップＳ１２６において、レジストレーション情報に基づいて、プロバイダサブプレゼンス情報を供給し、処理をステップＳ１２７に進める。
【０１８５】
ステップＳ１２５において、プロバイダサブプレゼンス情報が変化していないと判定した場合、CPU１０１は、ステップＳ１２６の処理を省略して、ステップＳ１２７に処理を進める。
【０１８６】
ステップＳ１２７において、CPU１０１は、サブプレゼンス情報管理処理を終了するか否かを判定し、終了しないと判定した場合、処理をステップＳ１２１に戻し、それ以降の処理を繰り返す。
【０１８７】
ステップＳ１２７において、ユーザの指示等に基づいて、サブプレゼンス情報管理処理を終了すると判定した場合、CPU１０１は、ステップＳ１２８において終了処理を行った後、サブプレゼンス情報管理処理を終了する。
【０１８８】
以上のようにして、プロバイダは、図１８に示されるプレゼンス情報３０１を管理し、コンスーマのレジストレーションを行う。これにより、プロバイダは、後述するように、冗長な情報を送信することなく、コンスーマにプロバイダとしての機能に関する情報を供給することができる。
【０１８９】
次に、上述したプロバイダによる処理に対応するコンスーマによるプレゼンス情報の管理に関する処理について説明する。
【０１９０】
最初に、図２２のフローチャートを参照して、コンスーマによるメインプレゼンス情報の管理に関する処理について説明する。ここでは、コンスーマの例として、図４のクライアント３３を用いて説明する。
【０１９１】
サーバ３１により提供されるインスタントメッセージ通信サービスにログインしたコンスーマであるクライアント３３のCPU１５１は、RAM１５３に保持されている、または記憶部１７３に記憶されているメインプレゼンス情報を、通信部１７４を制御して、ネットワーク３５を介してサーバ３１に供給する。
【０１９２】
サーバ３１は、供給されたメインプレゼンス情報をB@imsg（クライアント３３）の情報として管理するとともに、そのメインプレゼンス情報を、予め登録されている友達リストに基づいて、B@imsgの友達であるA@imsg（クライアント３２）に供給する。また、サーバ３１は、予め供給され、管理されているA@imsgのメインプレゼンス情報をB@imsgに供給する。
【０１９３】
クライアント３３のCPU１５１は、ステップＳ１４２において、通信部１７４を制御し、そのサーバ３１より供給されるメインプレゼンス情報を取得したか否かを判定する。
【０１９４】
メインプレゼンス情報を取得したと判定した場合、CPU１５１は、ステップＳ１４３において、取得したメインプレゼンス情報を解析し、RAM１５３等に保持している他のクライアントの状態に関する情報であるステータス情報を更新し、処理をステップＳ１４４に進める。
【０１９５】
また、ステップＳ１４２において、メインプレゼンス情報を取得していないと判定した場合、CPU１５１は、ステップＳ１４３の処理を省略し、処理をステップＳ１４４に進める。
【０１９６】
ステップＳ１４４において、CPU１５１は、通信部１７４を制御して、サーバ３１より供給される情報に基づいて、他のクライアントがログオフしたか否かを判定する。
【０１９７】
ログオフしたと判定した場合、CPU１５１は、ステップＳ１４５において、ログオフしたことをステータス情報に反映させて更新し、ステップＳ１４６に処理を進める。
【０１９８】
ステップＳ１４４において、他のクライアントがログオフしていないと判定した場合、CPU１５１は、ステップＳ１４５の処理を省略し、ステップＳ１４６に処理を進める。
【０１９９】
CPU１５１は、ステップＳ１４６において、メインプレゼンス情報管理処理を終了するか否かを判定し、終了しないと判定した場合、ステップＳ１４１に処理を戻し、それ以降の処理を繰り返す。
【０２００】
また、ユーザの指示等に基づいて、メインプレゼンス情報管理処理を終了すると判定した場合、CPU１５１は、ステップＳ１４７において、終了処理を行った後、メインプレゼンス情報管理処理を終了する。
【０２０１】
次に、図２３のフローチャートを参照して、コンスーマによるレジストレーションの管理に関する処理について説明する。
【０２０２】
コンスーマであるクライアント３３のCPU１５１は、ステップＳ１６１において、通信部１７４を制御して、プロバイダであるクライアント３２より送信されたプロバイダサブプレゼンス情報を取得したか否かを判定する。
【０２０３】
プロバイダサブプレゼンス情報を取得したと判定した場合、CPU１５１は、ステップＳ１６２において、そのプロバイダサブプレゼンス情報に基づいて、RAM１５３に保持されているレジストレーション情報を更新し、処理をステップＳ１６３に進める。
【０２０４】
ステップＳ１６１において、プロバイダサブプレゼンス情報を取得していないと判定した場合、CPU１５１は、ステップＳ１６２の処理を省略し、ステップＳ１６３に処理を進める。
【０２０５】
ステップＳ１６３において、CPU１５１は、レジストレーション情報に基づいて、プロバイダであるクライアント３２に対して、レジストレーション要求を供給するか否かを判定する。
【０２０６】
レジストレーションがまだ行われておらず、ユーザの指示等に基づいて、レジストレーション要求を供給すると判定した場合、CPU１５１は、ステップＳ１６４において、通信部１７４を制御して、プロバイダであるクライアント３２にレジストレーション要求を供給する。供給されたレジストレーション要求は、図２０のＳ９１において、クライアント３２に取得される。レジストレーション要求の供給が完了すると、CPU１５１は、処理をステップＳ１６５に進める。
【０２０７】
ステップＳ１６３において、レジストレーションが既に行われている等して、レジストレーション要求を供給しないと判定した場合、CPU１５１は、ステップＳ１６４の処理を省略し、ステップＳ１６５に処理を進める。
【０２０８】
ステップＳ１６５において、CPU１５１は、ユーザの指示等に基づいて、レジストレーション解除要求を供給するか否かを判定し、供給すると判定した場合、ステップＳ１６６において、通信部１７４を制御して、レジストレーション解除要求をプロバイダであるクライアント３２に供給した後、ステップＳ１６７に処理を進める。
【０２０９】
ステップＳ１６５において、レジストレーション解除要求を供給しないと判定した場合、CPU１５１は、ステップＳ１６６の処理を省略し、ステップＳ１６７に処理を進める。
【０２１０】
ステップＳ１６７において、CPU１５１は、ユーザの指示等に基づいて、レジストレーション管理処理を終了するか否かを判定し、終了しないと判定した場合、ステップＳ１６１に処理を戻し、それ以降の処理を繰り返す。
【０２１１】
また、レジストレーション管理処理を終了すると判定した場合、CPU１５１は、ステップＳ１７８において、終了処理を行った後、レジストレーション管理処理を終了する。
【０２１２】
次に、図２４のフローチャートを参照して、コンスーマによるサブプレゼンス情報の管理に関する処理について説明する。
【０２１３】
コンスーマであるクライアント３３のCPU１５１は、ステップＳ１８１において、レジストレーション情報に基づいて、プロバイダにより新たにレジストレーションされたか否かを判定し、新たにレジストレーションされたと判定した場合、ステップＳ１８２において、通信部１７４を制御して、コンスーマサブプレゼンス情報をそのプロバイダに供給し、ステップＳ１８３に処理を進める。
【０２１４】
ステップＳ１８１において、新たにレジストレーションされていないと判定した場合、CPU１５１は、ステップＳ１８２の処理を省略し、ステップＳ１８３に処理を進める。
【０２１５】
ステップＳ１８３において、CPU１５１は、MPEG４ストリーミング受信処理部４３−１およびMPEG２ストリーミング受信処理部４３−２を制御して、機能の状態が変化したか否かを判定する。
【０２１６】
上述した機能を用いた通信が開始されるなどして、機能の状態が変化したと判定した場合、CPU１５１は、ステップＳ１８４において、コンスーマサブプレゼンス情報を更新し、ステップＳ１８５において、更新したコンスーマサブプレゼンス情報を、レジストレーションしているプロバイダに供給し、ステップＳ１８６に処理を進める。
【０２１７】
ステップＳ１８３において、機能の状態が変化していないと判定した場合、CPU１５１は、上述したステップＳ１８４およびステップＳ１８５の処理を省略し、ステップＳ１８６に処理を進める。
【０２１８】
ステップＳ１８６において、CPU１５１は、サブプレゼンス情報管理処理を終了するか否かを判定し、終了しないと判定した場合、処理をステップＳ１８１に戻し、それ以降の処理を繰り返す。
【０２１９】
サブプレゼンス情報管理処理を終了すると判定した場合、CPU１５１は、ステップＳ１８７において、終了処理を行った後、サブプレゼンス情報管理処理を終了する。
【０２２０】
以上のようにして、コンスーマは、図１８に示されるプレゼンス情報３０１を管理する。
【０２２１】
次に、具体的な例として、図４のシステムにおいて、B@imsg（クライアント３３）およびC@imsg（クライアント３４）がログインしているインスタントメッセージ通信サービスにA@imsg（クライアント３２）がログインする場合の処理の流れを説明する。
【０２２２】
最初に、図２５のタイミングチャートを参照して、メインプレゼンス情報の授受に関する処理の流れについて説明する。必要に応じて図２６および図２７を参照して説明する。
【０２２３】
インスタントメッセージ通信サービスにログインしたクライアント３２は、ステップＳ２２１において、メインプレゼンス情報をサーバ３１に供給する。
【０２２４】
サーバ３１は、そのメインプレゼンス情報をステップＳ２０１において取得すると、その情報を管理するとともに、ステップＳ２０２において、A@imsg（蔵案と３２）の友達であるB@imsg（クライアント３３）およびC@imsg（クライアント３４）のメインプレゼンス情報をA@imsgに供給する。
【０２２５】
クライアント３２は、ステップＳ２２２において、B@imsgおよびC@imsgのメインプレゼンス情報取得すると、そのメインプレゼンス情報を解析し、ステータス情報を更新して保持する。
【０２２６】
また、サーバ３１は、ステップＳ２０３において、A@imsgのメインプレゼンス情報をA@imsgの友達であるB@imsgに供給する。クライアント３３は、ステップＳ２１１において、そのメインプレゼンス情報を取得し、解析し、ステータス情報を更新して保持する。
【０２２７】
同様に、サーバ３１は、ステップＳ２０４において、A@imsgのメインプレゼンス情報をA@imsgの友達であるC@imsgに供給する。クライアント３４は、ステップＳ２３１において、そのメインプレゼンス情報を取得し、解析し、ステータス情報を更新して保持する。
【０２２８】
すなわち、図２６に示されるように、A@imsg（クライアント３２）は、ログインすると、サーバ３１を介して、既にログインしている友達であるB@imsg（クライアント３３）およびC@imsg（クライアント３４）に、自分自身のステータス情報および自分自身が有する機能に関する情報を含むメインプレゼンス情報を、供給する。（矢印３１１および３１３）
【０２２９】
図２７は、クライアント３２が図２５のステップＳ２２１において、サーバ３１に供給するメインプレゼンス情報のデータの例を示す図である。
【０２３０】
図２７において、メインプレゼンス情報（タグ<presence>とタグ</presence>に囲まれた情報）には、自分自身の状態に関する情報（タグ<status>とタグ</status>に囲まれた情報）と、自分自身が有する機能に関する情報（タグ<service>とタグ</service>に囲まれた情報）が含まれている。
【０２３１】
図２７においては、A@imsg（クライアント３２）の状態は「オンライン」であり、「provider_ep=１」として「MPEG４ Streaming」送信機能４２−１を、「provider_ep=２」として「MPEG４ Streaming」送信機能４２−２を有していることが示されている。
【０２３２】
以上のように、メインプレゼンス情報は、サーバ３１により管理され、必要に応じて各クライアントに供給される。
【０２３３】
次に、図２８のタイミングチャートを参照して、プロバイダであるクライアント３２がコンスーマであるクライアント３３および３４が有する機能をレジストレーションする場合の処理の流れを説明する。
【０２３４】
クライアント３２のメインプレゼンス情報を解析したクライアント３３は、ステップＳ２４１において、ユーザの指示等に基づいて、クライアント３２のMPEG４ストリーミング送信機能（MPEG４ Streaming Tx）４２−１に対するレジストレーション要求をクライアント３２に供給する。
【０２３５】
クライアント３２は、そのレジストレーション要求をステップＳ２５１において取得すると、ステップＳ２５２において、レジストレーション情報を更新し、レジストレーションを行い、ステップＳ２５３においてクライアント３３に応答を供給する。
【０２３６】
クライアント３３は、その応答をステップＳ２４２において取得すると、ステップＳ２４３においてレジストレーション情報を更新する。
【０２３７】
以上のようにしてレジストレーションが行われるが、レジストレーションは、クライアント３２の機能ごとに行われる。従って、クライアント３３は、この状態からさらに、クライアント３２のMPEG２ストリーミング送信機能（MPEG２ Streaming Tx）４２−２に対するレジストレーションを行うこともできる。
【０２３８】
その場合、クライアント３３は、ステップＳ２４４において、レジストレーション要求を再度クライアント３２に供給し、ステップＳ２５４においてその要求を取得したクライアント３２は、ステップＳ２５５においてレジストレーション情報を更新した後、ステップＳ２５６において、レジストレーションを行ったことを通知するために、応答をクライアント３３に供給する。
【０２３９】
クライアント３３は、ステップＳ２４５においてその応答を取得すると、その応答に基づいて、レジストレーション情報を更新する。
【０２４０】
以上のようにして、クライアント３２は、クライアント３３を、機能ごとにレジストレーションすることができる。
【０２４１】
また、クライアント３２は、さらに、クライアント３３の場合と同様に、クライアント３４をレジストレーションすることもできる。
【０２４２】
その場合、ステップＳ２６１において、クライアント３４がクライアント３２のMPEG４ストリーミング送信機能（MPEG４ Streaming Tx）４２−１に対するレジストレーション要求をクライアント３２に供給する。
【０２４３】
クライアント３２は、ステップＳ２５７においてその要求を取得すると、ステップＳ２５８において、レジストレーション情報を更新し、ステップＳ２５９において、クライアント３４に応答を供給する。
【０２４４】
その応答をステップＳ２６２において取得したクライアント３４は、ステップＳ２６３において、レジストレーション情報を更新する。
【０２４５】
以上のようにして、クライアント３２は、機能ごとに友達である各クライアントをレジストレーションすることができる。
【０２４６】
図２９は、クライアント３２が機能ごとにクライアント３３および３４をレジストレーションする様子の例を示す図である。
【０２４７】
図２９に示されるように、クライアント３３および３４は、クライアント３２のメインプレゼンス情報に基づいて、クライアント３２の有する機能ごとにレジストレーション要求を供給する。（矢印３２１乃至３２３）
【０２４８】
図３０乃至３２は、そのときのレジストレーション要求のデータの例を示す図である。
【０２４９】
例えば、図３０のレジストレーション要求は、「A@imsg」（クライアント３２）に供給されており、A@imsgの「provider_ep=”１”」（MPEG４ストリーミング送信機能４２−１）に、B@imsg（クライアント３３）の「consumer_ep=”１”」（MPEG４ストリーミング受信機能４３−１）をレジストレーションすることを要求している。
【０２５０】
同様に、図３１のレジストレーション要求は、「A@imsg」に供給されており、A@imsgの「provider_ep=”２”」（MPEG２ストリーミング送信機能４２−２）に、B@imsgの「consumer_ep=”２”」（MPEG２ストリーミング受信機能４３−２）をレジストレーションすることを要求している。
【０２５１】
さらに、図３２のレジストレーション要求は、「A@imsg」に供給されており、A@imsgの「provider_ep=”１”」（MPEG４ストリーミング送信機能４２−１）に、C@imsgの「consumer_ep=”１”」（MPEG４ストリーミング受信機能４４−１）をレジストレーションすることを要求している。
【０２５２】
図３３は、レジストレーション要求を受け付けたクライアント３２より供給される応答のデータの例を示す図である。
【０２５３】
上述した図３０のようなレジストレーション要求に対して、レジストレーションを行う場合、クライアント３２は、レジストレーション情報を更新した後、要求元である「B@imsg」（クライアント３３）に対して、図３３Ａに示されるような応答を供給する。
【０２５４】
また、クライアント３２は、図３１のレジストレーション要求に応じてレジストレーションを行うと、図３３Ｂに示されるような応答を、要求元の「B@imsg」（クライアント３３）に供給する。
【０２５５】
同様に、クライアント３２は、図３２のレジストレーション要求に応じてレジストレーションを行うと、図３３Ｃに示されるような応答を、要求元の「C@imsg」（クライアント３４）に供給する。
【０２５６】
また、クライアント３２は、レジストレーション要求に対して、レジストレーションを拒否することもできる。例えば、図３２のレジストレーション要求に対して、レジストレーションを拒否する場合、図３３Ｄに示されるような応答を、要求元の「C@imsg」に供給する。
【０２５７】
以上のようにレジストレーションを行うことにより、プロバイダであるクライアント３２は、コンスーマであるクライアント３３および３４が有する機能の内、自分自身が有する機能を利用可能な機能について把握することができる。
【０２５８】
図３４は、各クライアントが管理するレジストレーション情報の例を示す図である。
【０２５９】
図３４Ａは、プロバイダであるクライアント３２が管理するレジストレーション情報の例であり、図３４Ｂは、コンスーマであるクライアント３３が管理するレジストレーション情報の例であり、図３４Ｃは、コンスーマであるクライアント３３が管理するレジストレーション情報の例である。いずれも、機能ごとにレジストレーションしたコンスーマの機能およびその状態が管理されている。なお、各機能の状態は、後述するように、サブプレゼンス情報により授受が行われる。
【０２６０】
以上に説明したレジストレーションは、コンスーマ（クライアント３３および３４）が、その解除を要求することもできる。例えば、クライアント３４がクライアント３２に対して、レジストレーションの解除を要求する場合、図３５Ａに示すようなデータのレジストレーション解除要求をクライアント３２に供給する。
【０２６１】
図３５Ａのレジストレーション解除要求は、「A@imsg」（クライアント３２）に供給されており、A@imsgの「provider_ep=”１”」（MPEG４ストリーミング送信機能４２−１）に対する、C@imsg（クライアント３４）の「consumer_ep=”１”」（MPEG４ストリーミング受信機能４４−１）のレジストレーションの「unregistration」（解除）を要求している。
【０２６２】
そして、クライアント３２は、この解除要求に基づいて、レジストレーション情報を更新して、指定されたレジストレーションを解除し、図３５Ｂに示されるようなデータの応答を「C@imsg」（クライアント３４）に供給する。
【０２６３】
さらに、プロバイダ（クライアント３２）がログオフすると、図３５Ｃに示されるようなメインプレゼンスがコンスーマ（クライアント３３および３４）に供給され、それまで行われていたレジストレーションがすべて解除される。
【０２６４】
以上に説明したようなレジストレーションが行われると、レジストレーション情報に基づいて、各クライアント間でサブプレゼンス情報を用いて各機能の状態に関する情報が授受される。
【０２６５】
図３６のタイミングチャートを参照して、サブプレゼンス情報の授受に関する処理の流れを説明する。必要に応じて、図３７乃至図４０を参照して説明する。
【０２６６】
レジストレーションが行われると、クライアント３２は、ステップＳ２９１において、レジストレーション情報に基づいて、図３８に示されるようなデータ構造のMPEG４ストリーミング送信機能４２−１に関するプロバイダサブプレゼンス情報３０４Ａを、レジストレーションしているクライアント３３に供給する（図３７の矢印３３１）。
【０２６７】
サブプレセンス情報３０３においては、機能の状態は、タグ<show>と、タグ</show>に囲まれており、図３８の場合、情報のタイプが「provider」で、「B@imsg」（クライアント３３）に供給されるデータであり、A@imsg（クライアント３２）の「provider_ep=”１”」（MPEG４ストリーミング送信機能４２−１）の状態が「available」であることが示されている。
【０２６８】
クライアント３３は、図３６のステップＳ２８１において、そのプロバイダサブプレゼンス情報３０４Ａを取得すると、ステップＳ２８２において、レジストレーション情報を更新する。
【０２６９】
そして、クライアント３３は、ステップＳ２８３において、MPEG４ストリーミング受信機能４３−１に関するコンスーマサブプレゼンス情報３０５Ａをクライアント３２に供給し（図３７の矢印３３２）、クライアント３２は、ステップＳ２９２において、その情報を取得すると、ステップＳ２９３において、レジストレーション情報を更新する。
【０２７０】
また、クライアント３２は、ステップＳ２９４において、図３９に示されるようなデータ構造のMPEG２ストリーミング送信機能４２−２に関するプロバイダサブプレゼンス情報３０４Ｂを供給し（図３７の矢印３３３）、クライアント３３は、その情報をステップＳ２８４において取得すると、ステップＳ２８５において、レジストレーション情報を更新する。
【０２７１】
図３９の例においては、情報のタイプが「provider」で、「B@imsg」（クライアント３３）に供給されるデータであり、A@imsg（クライアント３２）の「provider_ep=”２”」（MPEG２ストリーミング送信機能４２−２）の状態が「available」であることが示されている。
【０２７２】
そして、クライアント３３は、図３６のステップＳ２８６において、MPEG２ストリーミング受信機能４３−２に関するコンスーマサブプレゼンス情報３０５Ｂをクライアント３２に供給し（図３７の矢印３３４）、クライアント３２は、ステップＳ２９５において、その情報を取得すると、ステップＳ２９６において、レジストレーション情報を更新する。
【０２７３】
さらに、クライアント３２は、レジストレーションしたクライアント３４に対しても同様に、ステップＳ２９４において、図４０に示されるようなデータ構造のMPEG４ストリーミング送信機能４２−１に関するプロバイダサブプレゼンス情報３０４Ａを供給し（図３７の矢印３３５）、クライアント３４は、その情報をステップＳ３０１において取得すると、ステップＳ３０２において、レジストレーション情報を更新する。
【０２７４】
図４０の例においては、情報のタイプが「provider」で、「C@imsg」（クライアント３４）に供給されるデータであり、A@imsg（クライアント３２）の「provider_ep=”１”」（MPEG４ストリーミング送信機能４２−１）の状態が「available」であることが示されている。
【０２７５】
そして、クライアント３４は、ステップＳ３０３において、MPEG４ストリーミング受信機能４４−１に関するコンスーマサブプレゼンス情報３０５Ａをクライアント３２に供給し（矢印３３６）、クライアント３２は、ステップＳ２９８において、その情報を取得すると、ステップＳ２９９において、レジストレーション情報を更新する。
【０２７６】
以上のようにして、プロバイダであるクライアント３２は、各プロバイダサブプレゼンス情報３０４を、レジストレーション情報に基づいて、コンスーマであるクライアント３３および３４に供給し、コンスーマであるクライアント３３および３４は、コンスーマサブプレゼンス情報を、レジストレーション情報に基づいて、プロバイダであるクライアント３２に供給する。
【０２７７】
これにより、各クライアントは、レジストレーションされた友達の機能の状態を把握することができる。
【０２７８】
また、各クライアントは、自分自身が有する機能の状態が変化した場合も、対応するサブプレゼンス情報を供給する。
【０２７９】
図４１のタイミングチャートを参照して、クライアント３２とクライアント３３がMPEG４ストリーミング通信を開始した場合の処理の流れを説明する。また、必要に応じて、図４２乃至４４を参照して説明する。
【０２８０】
クライアント３２がステップＳ３３１において、MPEG４ストリーミング送信機能４２−１を利用してMPEG４データのストリーミング送信を開始し、それに対応して、クライアント３３がステップＳ３２１において、MPEG４ストリーミング受信機能４３−１を利用してMPEG４データのストリーミング受信を開始すると、クライアント３２のMPEG４ストリーミング送信機能４２−１は、利用不可になるので、クライアント３２は、ステップＳ３３２において、プロバイダサブプレゼンス情報３０４Ａを更新し、MPEG４ストリーミング送信機能４２−１の状態の変化を反映させる。
【０２８１】
そして、ステップＳ３３３において、図４３に示されるようなデータ構造の更新されたプロバイダサブプレゼンス情報３０４Ａをクライアント３３に供給する（図４２の矢印３４１）。
【０２８２】
図４３の例においては、情報のタイプが「provider」で、「B@imsg」（クライアント３３）に供給されるデータであり、A@imsg（クライアント３２）の「provider_ep=”１”」（MPEG４ストリーミング送信機能４２−１）の状態が「unavailable」であることが示されている。
【０２８３】
クライアント３３は、そのプロバイダサブプレゼンス情報３０４ＡをステップＳ３２２において取得すると、ステップＳ３２３において、その情報に基づいて、レジストレーション情報を更新する。
【０２８４】
また、クライアント３３も、クライアント３２と同様に、ストリーミング受信を開始したことにより、MPEG４ストリーミング受信機能４３−１が利用不可になるので、ステップＳ３２４においてコンスーマサブプレゼンス情報３０５Ａを更新し、クライアント３２に供給する（図４２の矢印３４２）。
【０２８５】
クライアント３２は、その情報をステップＳ３３４において取得すると、ステップＳ３３５において、そのコンスーマサブプレゼンス情報３０５Ａに基づいて、レジストレーション情報を更新する。
【０２８６】
クライアント３２のレジストレーション情報において、MPEG４ストリーミング送信機能４２−１には、クライアント３３の他に、クライアント３４もレジストレーションされている。
【０２８７】
従って、クライアント３２は、ステップＳ３３６において、図４４に示されるようなデータ構造の更新されたプロバイダサブプレゼンス情報３０４Ａをクライアント３４に供給する（図４２の矢印３４３）。
【０２８８】
図４４の例においては、情報のタイプが「provider」で、「C@imsg」（クライアント３４）に供給されるデータであり、A@imsg（クライアント３２）の「provider_ep=”１”」（MPEG４ストリーミング送信機能４２−１）の状態が「unavailable」であることが示されている。
【０２８９】
クライアント３４は、その情報をステップＳ３４１において取得すると、ステップＳ３４２において、そのプロバイダサブプレゼンス情報３０４Ａに基づいて、レジストレーション情報を更新する。
【０２９０】
以上のようにして、各クライアントは、レジストレーションされた友達の機能の状態を把握することができる。
【０２９１】
次に、クライアント３２とクライアント３３の間で、MPEG２ストリーミング通信が行われた場合の処理の流れを、図４５のタイミングチャートを参照して説明する。また、必要に応じて、図４６乃至４８を参照して説明する。
【０２９２】
クライアント３２がステップＳ３７１において、MPEG２ストリーミング送信機能４２−２を利用して、MPEG２データのストリーミング送信を開始すると、それに対応して、クライアント３３は、ステップＳ３６１において、MPEG２ストリーミング受信機能４３−２を利用して、MPEG２データのストリーミング受信を開始する。
【０２９３】
MPEG２データのストリーミング送信が開始されると、クライアント３２のMPEG２ストリーミング送信機能４２−２の状態は利用不可になる。クライアント３２は、ステップＳ３７２において、プロバイダサブプレゼンス情報３０４Ｂを更新し、その状態の変化を反映させる。
【０２９４】
そして、ステップＳ３７３において、クライアント３２は、図４７に示されるようなデータ構造の更新したプロバイダサブプレゼンス情報３０４Ｂを、レジストレーション情報に基づいて、クライアント３３に供給する（図４６の矢印３５１）。
【０２９５】
図４７の例においては、情報のタイプが「provider」で、「B@imsg」（クライアント３４）に供給されるデータであり、A@imsg（クライアント３２）の「provider_ep=”２”」（MPEG２ストリーミング送信機能４２−２）の状態が「unavailable」であることが示されている。
【０２９６】
クライアント３３は、その情報をステップＳ３６２において取得すると、ステップＳ３６３において、そのプロバイダサブプレゼンス情報３０４Ｂに基づいて、レジストレーション情報を更新する。
【０２９７】
また、MPEG２データのストリーミング受信が開始されたことにより、クライアント３３のMPEG２ストリーミング受信機能４３−２の状態も利用不可になる。クライアント３３は、ステップＳ３６４において、コンスーマサブプレゼンス情報３０５Ｂを更新し、その状態の変化を反映させ、レジストレーション情報に基づいて、図４８に示されるようなデータ構造のコンスーマサブプレゼンス情報３０５Ｂをクライアント３２に供給する（図４６の矢印３５２）。
【０２９８】
図４８の例においては、情報のタイプが「consumer」で、「A@imsg」（クライアント３２）に供給されるデータであり、B@imsg（クライアント３３）の「consumer_ep=”２”」（MPEG２ストリーミング受信機能４２−２）の状態が「unavailable」であることが示されている。
【０２９９】
クライアント３２は、その情報をステップＳ３７４において取得すると、ステップＳ３７５において、そのコンスーマサブプレゼンス情報３０５Ｂに基づいて、レジストレーション情報を更新する。
【０３００】
このとき、クライアント３４は、クライアント３２のMPEG２ストリーミング送信機能４２−２を利用する機能を有しておらず、クライアント３２のMPEG２ストリーミング送信機能４２−２に対してレジストレーションされていない。従って、クライアント３２は、MPEG２ストリーミング送信機能４２−２の状態が変化してもクライアント３４にプロバイダサブプレゼンス情報３０４Ｂを供給しない。
【０３０１】
以上により、プロバイダ側、コンスーマ側のどちらも機能に関する最低限、かつ必要十分なプレゼンス情報を知ることができ、情報の授受に必要な負荷を軽減することができる。
【０３０２】
以上の説明においては、ストリーミング送信機能をプロバイダの機能とし、ストリーミング受信機能をコンスーマの機能として説明したが、これに限らず、例えば、逆に、ストリーミング受信機能をプロバイダの機能とし、ストリーミング送信機能をコンスーマの機能としてもよい。
【０３０３】
その場合、上述した場合とは逆に、ストリーミング送信機能を有するクライアント３２より、ストリーミング受信機能を有するクライアント３３および３４にレジストレーション要求が供給される。
【０３０４】
図４９は、ストリーミング受信機能をプロバイダの機能とし、ストリーミング送信機能をコンスーマの機能とした場合のメインプレゼンス情報の授受の様子を示す図である。
【０３０５】
上述した場合と同様に、B@imsg（クライアント３３）とC@imsg（クライアント３４）が既にログインしているインスタントメッセージ通信サービスにA@imsg（クライアント３２）がログインすると、コンスーマであるクライアント３２は、図５０に示すようなデータ構造のメインプレゼンス情報３０２をサーバ３１に供給する。
【０３０６】
図５０においては、A@imsgの状態が「オンライン」であることが示されている。サーバ３１は、A@imsgの友達リストに基づいて、このメインプレゼンス情報３０２をB@imsgおよびC@imsgに供給する。
【０３０７】
また、サーバ３１は、図５１および５２に示されるようなデータ構造のB@imsgとC@imsgのメインプレゼンス情報３０２をA@imsgに供給する。図５１に示されるように、B@imsgのメインプレゼンス情報３０２には、B@imsgが有するプロバイダとしての機能（MPEG４ストリーミング受信機能４３−１およびMPEG２ストリーミング受信機能４３−２）に関する情報が含まれている。同様に、図５２に示されるように、C@imsgのメインプレゼンス情報３０２には、C@imsgが有するプロバイダとしての機能（MPEG４ストリーミング受信機能４４−１）に関する情報が含まれている。
【０３０８】
なお、以上のようなメインプレゼンス情報の授受に関する処理の流れは、図２５のタイミングチャートを参照して説明した場合と同様であり、図２５のタイミングチャートを適用することができるので、その説明は省略する。
【０３０９】
また、このときプロバイダ（クライアント３３および３４）により実行されるメインプレゼンス情報管理処理は、図１９のフローチャートを参照して説明した場合と同様であり、図１９のフローチャートを適用することができる。同様に、コンスーマ（クライアント３２）により実行されるメインプレゼンス情報管理処理も、図２２を参照して説明した場合と同様であり、図２２のフローチャートを適用することができる。
【０３１０】
次に、レジストレーションに関する処理について説明する。
【０３１１】
コンスーマであるA@imsg（クライアント３２）は、取得したメインプレゼンス情報に基づいて、プロバイダであるB@imsgおよびC@imsg（クライアント３３および３４）が有する機能のうち、利用可能な機能に対してレジストレーション要求を供給する（図５３の矢印３７１乃至３７３）。
【０３１２】
図５４は、A@imsgが図５３の矢印３７１において、B@imsgのMPEG４ストリーミング受信機能４３−１に対して供給するレジストレーション要求のデータ構造の例を示す図である。このレジストレーション要求は「B@imsg」に供給され、B@imsgの「provider_ep=”１”」（MPEG４ストリーミング受信機能４３−１）に対して、A@imsgの「consumer_ep=”１”」（MPEG４ストリーミング送信機能４２−１）のレジストレーションを要求している。
【０３１３】
図５５は、A@imsgが図５３の矢印３７２において、B@imsgのMPEG２ストリーミング受信機能４３−２に対して供給するレジストレーション要求のデータ構造の例を示す図である。このレジストレーション要求は「B@imsg」に供給され、B@imsgの「provider_ep=”２”」（MPEG２ストリーミング受信機能４３−２）に対して、A@imsgの「consumer_ep=”２”」（MPEG２ストリーミング送信機能４２−２）のレジストレーションを要求している。
【０３１４】
図５６は、A@imsgが図５３の矢印３７３において、C@imsgのMPEG４ストリーミング受信機能４４−１に対して供給するレジストレーション要求のデータ構造の例を示す図である。このレジストレーション要求は「C@imsg」に供給され、C@imsgの「provider_ep=”１”」（MPEG４ストリーミング受信機能４４−１）に対して、A@imsgの「consumer_ep=”１”」（MPEG４ストリーミング送信機能４２−１）のレジストレーションを要求している。
【０３１５】
なお、以上のようなレジストレーションに関する処理において、コンスーマであるクライアント３２が図２８のクライアント３３および３４の処理を行い、プロバイダであるクライアント３３および３４が図２８のクライアント３２の処理を行う。
【０３１６】
従って、コンスーマであるクライアント３２は、図２３に示されるようなレジストレーション管理処理を実行し、プロバイダであるクライアント３３および３４は、図２０に示されるようなレジストレーション管理処理を実行する。
【０３１７】
また、サブプレゼンス情報の授受についても同様であり、コンスーマであるクライアント３２が図３６、４１、および４５のクライアント３３および３４の処理を行い、プロバイダであるクライアント３３および３４が図３６、４１、および４５のクライアント３２の処理を行う。
【０３１８】
従って、コンスーマであるクライアント３２は、図２４に示されるようなサブプレゼンス情報管理処理を実行し、プロバイダであるクライアント３３および３４は、図２１に示されるようなサブプレゼンス情報管理処理を実行する。
【０３１９】
以上のようにして、ストリーミング受信機能をプロバイダの機能とし、ストリーミング送信機能をコンスーマの機能とした場合においても、プロバイダ側、コンスーマ側のどちらも機能に関する最低限、かつ必要十分なプレゼンス情報を知ることができ、情報の授受に必要な負荷を軽減することができる。
【０３２０】
以上においては、プロバイダとコンスーマがクライアントごとに分かれているように説明したが、プロバイダやコンスーマは装置によって決定されるのではなく、機能によって決定されるものであり、上述した以外にも、１つのクライアントが、プロバイダとしての機能とコンスーマとしての機能の両方を有するようにしてもよい。
【０３２１】
図５７は、本発明を適用したインスタントメッセージ通信システムの他の例を示す図である。
【０３２２】
図５７において、図４のインスタントメッセージ通信システムと比較して、A@imsg（クライアント３８２）とB@imsg（クライアント３８３）がプロバイダとしての機能とコンスーマとしての機能の両方を有していることが異なっている。
【０３２３】
クライアント３８２は、機能リスト３９２のように、プロバイダとしての機能としてMPEG４ストリーミング送信機能（MPEG４ Streaming Tx）３９２−１を有するとともに、コンスーマとしての機能としてMPEG２ストリーミング受信機能（MPEG２ Streaming Rx）３９２−２を有している。
【０３２４】
クライアント３８３は、機能リスト３９３のように、コンスーマとしての機能としてMPEG４ストリーミング受信機能（MPEG４ Streaming Rx）３９３−１を有するとともに、プロバイダとしての機能としてMPEG２ストリーミング送信機能（MPEG２ Streaming Tx）３９３−２を有している。
【０３２５】
図５８は、クライアント３８２の構成例を示す図である。図５８に示されるように、クライアント３８２は、図６のクライアント３２と異なり、MPEG４ストリーミング送信処理部３９２−１とMPEG２ストリーミング受信処理部３９２−２を有している。
【０３２６】
MPEG４ストリーミング送信処理部３９２−１とMPEG２ストリーミング受信処理部３９２−２は、ともにバス１１０に接続されている。MPEG４ストリーミング送信処理部３９２−１は、図６のMPEG４ストリーミング送信処理部４２−１と同様の構成であり、CPU１０１に制御されて、MPEG４データのストリーミング送信に関する処理を実行する。MPEG２ストリーミング受信処理部３９２−２は、図７のMPEG２ストリーミング受信処理部４３−２と同様の構成であり、CPU１０１に制御されて、MPEG２データのストリーミング受信に関する処理を実行する。
【０３２７】
図５９は、クライアント３８３の構成例を示す図である。図５９に示されるように、クライアント３８３は、図７のクライアント３３と異なり、MPEG４ストリーミング受信処理部３９３−１とMPEG２ストリーミング送信処理部３９３−２を有している。
【０３２８】
MPEG４ストリーミング受信処理部３９３−１とMPEG２ストリーミング送信処理部３９３−２は、ともにバス１６０に接続されている。MPEG４ストリーミング受信処理部３９３−１は、図７のMPEG４ストリーミング受信処理部４３−１と同様の構成であり、CPU１５１に制御されて、MPEG４データのストリーミング受信に関する処理を実行する。MPEG２ストリーミング送信処理部３９３−２は、図６のMPEG２ストリーミング送信処理部４２−２と同様の構成であり、CPU１５１に制御されて、MPEG２データのストリーミング送信に関する処理を実行する。
【０３２９】
なお、この場合におけるプレゼンス情報の構成も、図１８に示されるプレゼンス情報と同様の構成であるが、クライアント３８２および３８３のサブプレゼンス情報３０３には、プロバイダサブプレゼンス情報３０４と、コンスーマサブプレゼンス情報３０５の両方が含まれることになる。
【０３３０】
次に、メインプレゼンス情報の授受について説明する。この場合においても、上述した他の場合と同様に、プロバイダが機能に関する情報を、メインプレゼンス情報を用いて、コンスーマに供給する。すなわち、図６０に示されるように、クライアント３８２は、矢印４０１および４０３のように、クライアント３８３および３４にメインプレゼンス情報を供給することによって、プロバイダとしての機能であるMPEG４ストリーミング送信機能（MPEG４ Streaming Tx）３９２−１を有していることをクライアント３８３および３４に通知し、クライアント３８３は、矢印４０２のように、クライアント３８２にメインプレゼンス情報を供給することによって、プロバイダとしての機能であるMPEG２ストリーミング送信機能（MPEG２ Streaming Tx）３９３−２を有していることをクライアント３８２に通知する。
【０３３１】
従って、クライアント３８２および３８３は、図１９に示されるようなプレゼンス情報管理処理と、図２２に示されるようなプレゼンス情報管理処理の両方を実行する。
【０３３２】
なお、クライアント３４は、コンスーマとしての機能であるMPEG４ストリーミング受信機能（MPEG４ Streaming Rx）のみを有しているので、矢印４０４のように、クライアント３８２にメインプレゼンス情報を供給することによって、クライアント３４の状態に関する情報のみを通知する。
【０３３３】
次に、このような場合におけるレジストレーションについて説明する。レジストレーションは、コンスーマがプロバイダに要求することによりプロバイダによって行われるので、図６１に示されるように、機能ごとに行われる。
【０３３４】
すなわち、図６１に示されるように、コンスーマとしての機能であるMPEG４ストリーミング受信機能３９３−１を有するクライアント３８３は、クライアント３８２のプロバイダとしての機能であるMPEG４ストリーミング送信機能３９２−１に対して、矢印４１１のように、レジストレーションを要求し、コンスーマとしての機能であるMPEG２ストリーミング受信機能３９２−２を有するクライアント３８２は、クライアント３８３のプロバイダとしての機能であるMPEG２ストリーミング送信機能３９３−２に対して、矢印４１２のように、レジストレーションを要求する。
【０３３５】
また、コンスーマとしての機能であるMPEG４ストリーミング受信機能４４−１のみを有するクライアント３４は、クライアント３８２のプロバイダとしての機能であるMPEG４ストリーミング送信機能３９２−１に対して、矢印４１３のように、レジストレーションを要求する。
【０３３６】
従って、クライアント３８２は、MPEG４ストリーミング送信機能３９２−１に、クライアント３８３のMPEG４ストリーミング受信機能３９３−１と、クライアント３４のMPEG４ストリーミング受信機能４４−１をレジストレーションし、クライアント３８３は、MPEG２ストリーミング送信機能３９３−２に、クライアント３８２のMPEG２ストリーミング受信機能３９２−２をレジストレーションする。
【０３３７】
すなわち、クライアント３８２および３８３は、ともに、図２０に示されるようなレジストレーション管理処理と、図２３に示されるようなレジストレーション管理処理の両方を実行する。
【０３３８】
また、クライアント３８２および３８３は、サブプレゼンス情報についても同様に、図２１に示されるようなサブプレゼンス情報管理処理と図２４に示されるようなサブプレゼンス情報管理処理の両方を実行し、プロバイダとしての処理とコンスーマとしての処理をそれぞれの機能ごとに独立して実行する。
【０３３９】
以上のようにして、１つのクライアントが、プロバイダとしての機能と、コンスーマとしての機能の両方を有する場合においても、各クライアントは、プロバイダ側、コンスーマ側のどちらも機能に関する最低限、かつ必要十分なプレゼンス情報を知ることができ、情報の授受に必要な負荷を軽減することができる。
【０３４０】
以上においては、図１８のサブプレゼンス情報３０３は、各クライアントが、自分自身が管理しているレジストレーション情報に基づいて、供給先を選択し、供給するように説明したが、これに限らず、サーバが各クライアントのレジストレーション情報を管理し、図６２に示されるようなプレゼンス情報５０１のサブプレゼンス情報５０３を、適切なクライアントに供給するようにしてもよい。
【０３４１】
その場合のサーバ５２０は、図６３に示されるように、図５に示されるサーバ３１の構成の他に、バス６０に接続されたプレゼンス情報管理部５２５を有している。
【０３４２】
プレゼンス情報管理部５２５は、CPU５１に制御され、図６４に示されるようなリスト５３０を管理している。リスト５３０には、各クライアントの状態の情報を含むメインプレゼンス情報５３１、各クライアントが有する機能の状態およびレジストレーションの情報を含むサブプレゼンス情報５３２、各クライアントが予め登録している友達リスト５３３乃至５３５が含まれる。
【０３４３】
例えば、コンスーマとしての機能を２つ有するB@imsgが、プロバイダとしての機能を２つ有するA@imsgのそれぞれの機能に対して、サーバ５２０を介して、レジストレーションを行おうとすると、サーバ５２０は、そのレジストレーション要求に基づいて、図６５に示されるようなレジストレーション情報を作成し、サブプレゼンス情報５３２として、リスト５３０に記録する。
【０３４４】
また、A@imsgが供給するプロバイダサブプレゼンス情報やB@imsgが供給するコンスーマサブプレゼンス情報を取得すると、サーバ５２０は、図６６に示されるような情報として、サブプレゼンス情報５３２に記録した後、適切な友達に供給する。
【０３４５】
以上のような処理を行うサーバ５２０が実行するプレゼンス情報管理処理を、図６７のフローチャートを参照して説明する。
【０３４６】
ステップＳ４０１において、サーバ５２０のCPU５１は、通信部７４を制御して、クライアントよりメインプレゼンス情報５０２を取得したか否かを判定する
。
【０３４７】
メインプレゼンス情報５０２を取得したと判定した場合、ステップＳ４０２において、プレゼンス情報管理部５２５を制御して、取得したメインプレゼンス情報５０２に基づいて、リスト５３０のメインプレゼンス情報５３１を更新し、通信部７４を制御して、その情報を適切なクライアントに供給する。そして、その処理が完了するとCPU５１は、処理をステップＳ４０３に進める。
【０３４８】
ステップＳ４０１において、メインプレゼンス情報５０２を取得していないと判定した場合、CPU５１は、ステップＳ４０２の処理を省略し、ステップＳ４０３に処理を進める。
【０３４９】
ステップＳ４０３において、CPU５１は、通信部７４を制御して、クライアントよりレジストレーション要求を取得したか否かを判定し、取得したと判定した場合、処理をステップＳ４０４に進め、プレゼンス情報管理部５２５を制御して、取得したレジストレーション要求に基づいて、リスト５３０のサブプレゼンス情報５３２を更新し、処理をステップＳ４０５に進める。
【０３５０】
ステップＳ４０３において、レジストレーション要求を取得していないと判定した場合、CPU５１は、ステップＳ４０４の処理を省略し、ステップＳ４０５に処理を進める。
【０３５１】
ステップＳ４０５において、CPU５１は、通信部７４を制御して、クライアントよりレジストレーション解除要求を取得したか否かを判定し、取得したと判定した場合、処理をステップＳ４０６に進め、プレゼンス情報管理部５２５を制御して、取得したレジストレーション解除要求に基づいて、リスト５３０のサブプレゼンス情報５３２を更新し、処理をステップＳ４０７に進める。
【０３５２】
ステップＳ４０５において、レジストレーション解除要求を取得していないと判定した場合、CPU５１は、ステップＳ４０６の処理を省略し、ステップＳ４０７に処理を進める。
【０３５３】
ステップＳ４０７において、CPU５１は、通信部７４を制御して、クライアントよりサブプレゼンス情報５０３を取得したか否かを判定し、取得したと判定した場合、処理をステップＳ４０８に進め、プレゼンス情報管理部５２５を制御して、取得したサブプレゼンス情報５０３に基づいて、リスト５３０のサブプレゼンス情報５３２を更新し、通信部７４を制御して、その情報を適切なクライアントに供給する。そして、その処理が完了するとCPU５１は、処理をステップＳ４０９に進める。
【０３５４】
ステップＳ４０９において、CPU５１は、通信部７４を制御して、クライアントがログオフしたか否かを判定し、ログオフしたと判定した場合、ステップＳ４１０において、プレゼンス情報管理部５２５を制御して、ログオフしたクライアントに関係のある情報について、リスト５３０のメインプレゼンス情報５３１およびサブプレゼンス情報５３２を更新し、通信部７４を制御して、その情報を適切なクライアントに供給する。そして、その処理が完了すると、CPU５１は、ステップＳ４１１に処理を進める。
【０３５５】
ステップＳ４０９において、クライアントがログオフしていないと判定した場合、CPU５１は、ステップＳ４１０の処理を省略し、ステップＳ４１１に処理を進める。
【０３５６】
ステップＳ４１１において、CPU５１は、ユーザの指示などに基づいて、プレゼンス情報管理処理を終了するか否かを判定し、終了しないと判定した場合、処理をステップＳ４０１に戻し、それ以降の処理を繰り返す。
【０３５７】
ステップＳ４１１において、プレゼンス情報管理処理を終了すると判定した場合、CPU５１は、ステップＳ４１２において、終了処理を行った後、プレゼンス情報管理処理を終了する。
【０３５８】
以上のようにして、サーバ５２０は、各クライアントより供給されるプレゼンス情報を管理する。これにより、各クライアントがプレゼンス情報の送信相手を管理する必要がなくなるので、機能の状態に関する情報の授受に必要な負荷をさらに軽減することができる。
【０３５９】
なお、以上においては、サブプレゼンス情報３０３および５０３に含まれる、タグ<show>とタグ</show>に囲まれた情報は、クライアントが有する機能の状態、すなわち、「avaiable」と「unavailable」であるように説明したが、タグ<show>とタグ</show>に囲まれた情報は、これに限らず、ストリーミングのタイトルおよびコメント、位置情報、または天気等の付加情報を含むようにしてもよい。
【０３６０】
また、以上においては、インスタントメッセージ通信システムのクライアントがパーソナルコンピュータにより構成されるように説明したが、これに限らず、ネットワーク３５を介して通信を行うことができる通信機能を有する装置であれば何でもよく、例えば、デジタルスチルカメラ、カムコーダ、携帯電話機、またはPDA（Personal Digital Assistants）であってもよい。
【０３６１】
さらに、上述したインスタントメッセージ通信システムは、サーバが1台、並びに、クライアントが３台で構成されているが、これに限らず、クライアントおよびサーバが何台で構成されていてもよい。また、インスタントメッセージ通信システムに複数のネットワークが構成されていてもよい。
【０３６２】
また、以上においては、各クライアントが有し、インスタントメッセージ通信サービスのプレゼンス情報を用いて情報の授受を行う機能として、MPEG４ストリーミング送信機能、MPEG４ストリーミング受信機能、MPEG２ストリーミング送信機能、およびMPEG２ストリーミング受信機能を例として説明したが、これに限らず、クライアントが有する機能であれば何でも良い。
【０３６３】
なお、以上において、システムとは、複数の装置により構成される装置全体を表すものである。
【０３６４】
以上の処理は、ハードウェアにより実行することができるが、ソフトウェアにより実行させることもできる。一連の処理をソフトウェアにより実行させる場合には、そのソフトウェアを構成するプログラムが、専用のハードウェアに組み込まれているコンピュータ、または、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば汎用のパーソナルコンピュータなどに、ネットワークや記録媒体からインストールされる。
【０３６５】
この記録媒体は、図５乃至図８に示すように、装置本体とは別に、ユーザにプログラムを提供するために配布される、プログラムが記録されている磁気ディスク８１，１３１，１８１、または２３１（フロッピディスクを含む）、光ディスク８２，１３２，１８２、または２３２（CD-ROM(Compact Disk-Read Only Memory),DVD(Digital Versatile Disk)を含む）、光磁気ディスク８３，１３３，１８３、または２３３（MD(Mini-Disk)を含む）、もしくは半導体メモリ８４，１３４，１８４、または２３４などよりなるパッケージメディアにより構成されるだけでなく、装置本体に予め組み込まれた状態でユーザに提供される、プログラムが記録されているCPU５１，１０１，１５１、または２０１に内蔵されているROMなどで構成される。
【０３６６】
なお、本明細書において、記録媒体に記録されるプログラムを記述するステップは、記載された順序に沿って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的あるいは個別に実行される処理をも含むものである。
【０３６７】
【発明の効果】
以上の如く、本発明によれば、情報処理装置の間で情報を授受することが可能となる。特に、情報処理装置の間で利用可能な機能の状態に関する情報の授受に必要な負荷を軽減することが可能となる。
【図面の簡単な説明】
【図１】従来のIMPPを用いたインスタントメッセージ通信システムの例を示す図である。
【図２】図１のクライアントがサーバに供給するプレゼンス情報の例を示す図である。
【図３】図１のインスタントメッセージ通信システムにおけるプレゼンス情報の更新の様子を示す図である。
【図４】本発明を適用したインスタントメッセージ通信システムの例を示す図である。
【図５】図４のサーバの構成例を示すブロック図である。
【図６】図４のクライアント３２の構成例を示すブロック図である。
【図７】図４のクライアント３３の構成例を示すブロック図である。
【図８】図４のクライアント３４の構成例を示すブロック図である。
【図９】プロバイダによるプレゼンス情報供給処理を説明するフローチャートである。
【図１０】プレゼンス情報に関する処理の流れを説明するタイミングチャートである。
【図１１】図１０の例において、図４のクライアント３２がクライアント３３および３４にプレゼンス情報を提供する様子を示す図である。
【図１２】図１１の例において、クライアント３２より供給されるプレゼンス情報の例を示す図である。
【図１３】クライアント３２および３３の間でストリーミングが開始された場合の様子を示す図である。
【図１４】図１３の例において、クライアント３２より供給されるプレゼンス情報の例を示す図である。
【図１５】プレゼンス情報の他の例を示す図である。
【図１６】クライアント３２および３３の間でストリーミングが開始された場合の様子の他の例を示す図である。
【図１７】図１６の例において、クライアント３２より供給されるプレゼンス情報の例を示す図である。
【図１８】本発明を適用したプレゼンス情報のデータ構成の例を示す図である。
【図１９】プロバイダによるメインプレゼンス情報管理処理を説明するフローチャートである。
【図２０】プロバイダによるレジストレーション管理処理を説明するフローチャートである。
【図２１】プロバイダによるサブプレゼンス情報管理処理を説明するフローチャートである。
【図２２】コンスーマによるメインプレゼンス情報管理処理を説明するフローチャートである。
【図２３】コンスーマによるレジストレーション管理処理を説明するフローチャートである。
【図２４】コンスーマによるサブプレゼンス情報管理処理を説明するフローチャートである。
【図２５】メインプレゼンス情報の授受に関する処理の流れについて説明するタイミングチャートである。
【図２６】各クライアント間でメインプレゼンス情報を授受する様子を示す図である。
【図２７】メインプレゼンス情報のデータの例を示す図である。
【図２８】レジストレーションに関する処理の流れを説明するタイミングチャートである。
【図２９】コンスーマがプロバイダにレジストレーション要求を供給する様子を示す図である。
【図３０】レジストレーション要求のデータの例を示す図である。
【図３１】レジストレーション要求のデータの他の例を示す図である。
【図３２】レジストレーション要求のデータのさらに他の例を示す図である。
【図３３】レジストレーション要求に対する応答のデータの例を示す図である。
【図３４】各クライアントが管理するレジストレーション情報の例を示す図である。
【図３５】レジストレーションを解除する際に授受されるデータの例を示す図である。
【図３６】サブプレゼンス情報の授受に関する処理の流れを説明するタイミングチャートである。
【図３７】各クライアント間でサブプレゼンス情報を授受する様子を示す図である。
【図３８】プロバイダサブプレゼンス情報のデータの例を示す図である。
【図３９】プロバイダサブプレゼンス情報のデータの他の例を示す図である。
【図４０】プロバイダサブプレゼンス情報のデータのさらに他の例を示す図である。
【図４１】 MPEG４ストリーミング通信が開始された場合の処理の流れを説明するタイミングチャートである。
【図４２】図４１の場合において、各クライアント間でサブプレゼンス情報を授受する様子の例を示す図である。
【図４３】プロバイダサブプレゼンス情報の例を示す図である。
【図４４】プロバイダサブプレゼンス情報の他の例を示す図である。
【図４５】 MPEG２ストリーミング通信が開始された場合の処理の流れを説明するタイミングチャートである。
【図４６】図４５の場合において、各クライアント間でサブプレゼンス情報を授受する様子の例を示す図である。
【図４７】プロバイダサブプレゼンス情報の例を示す図である。
【図４８】プロバイダサブプレゼンス情報の他の例を示す図である。
【図４９】メインプレゼンス情報の授受の様子の他の例を示す図である。
【図５０】メインプレゼンス情報のデータの例を示す図である。
【図５１】メインプレゼンス情報のデータの他の例を示す図である。
【図５２】メインプレゼンス情報のデータのさらに他の例を示す図である。
【図５３】コンスーマがプロバイダにレジストレーションを要求する様子の例を示す図である。
【図５４】レジストレーション要求のデータの例を示す図である。
【図５５】レジストレーション要求のデータの他の例を示す図である。
【図５６】レジストレーション要求のデータのさらに他の例を示す図である。
【図５７】本発明を適用したインスタントメッセージ通信システムの他の例を示す図である。
【図５８】図５７のクライアント３８２の構成例を示すブロック図である。
【図５９】図５７のクライアント３８３の構成例を示すブロック図である。
【図６０】各クライアント間でメインプレゼンス情報を授受する様子を示す図である。
【図６１】コンスーマの機能をプロバイダの機能にレジストレーションする様子を示す図である。
【図６２】本発明を適用したプレゼンス情報の他の例を示す図である。
【図６３】図６２のプレゼンス情報を管理するサーバの構成例を示すブロック図である。
【図６４】図６３のサーバが管理するリストの例を示す図である。
【図６５】更新されたサブプレゼンス情報の例を示す図である。
【図６６】更新されたサブプレゼンス情報の他の例を示す図である。
【図６７】図６３のサーバによるプレゼンス情報管理処理を説明するフローチャートである。
【符号の説明】
３１ サーバ， ３２乃至３４ クライアント， ３５ ネットワーク， ３０１ プレゼンス情報， ３０２ メインプレゼンス情報， ３０３A乃至３０３Ｎ サブプレゼンス情報， ３０４A乃至３０４Ｎ プロバイダサブプレゼンス情報， ３０５A乃至３０５Ｎ コンスーマサブプレゼンス情報， ３８２および３８３ クライアント， ５０１ プレゼンス情報， ５０２ メインプレゼンス情報， ５０３Ａ乃至５０３Ｎ サブプレゼンス情報， ５０４Ａ乃至５０４Ｎ プロバイダサブプレゼンス情報， ５０５Ａ乃至５０５Ｎ コンスーマサブプレゼンス情報， ５２０ サーバ， ５２５ プレゼンス情報， ５３０リスト， ５３１ メインプレゼンス情報， ５３２ サブプレゼンス情報

Claims (9)

1. ネットワークを介して、予め通信相手として登録されている複数の他の情報処理装置と情報を授受する情報処理装置を制御するコンピュータに、
   前記情報処理装置が有する機能を示す機能毎の情報のそれぞれに、前記情報処理装置が有する前記機能に対応する前記他の情報処理装置が有する機能およびその状態を示す機能毎の情報を関連付けて登録する登録ステップと、
   前記情報処理装置が有する機能の状態を示す機能毎の情報を、前記登録ステップにより登録された情報に基づいて、前記情報処理装置が有する前記機能に対応する機能を有する他の情報処理装置に対して供給する第１の供給ステップと
   を実行させることを特徴とするプログラム。
2. 前記他の情報処理装置が有する機能を示す機能毎の情報を取得する第１の取得ステップと、
   前記他の情報処理装置が有する機能の状態を示す機能毎の情報を取得する第２の取得ステップと
   をさらに実行させ、
   前記登録ステップは、前記第１の取得ステップにより取得された前記他の情報処理装置が有する前記機能を示す機能毎の情報と、前記他の情報処理装置が有する前記機能に対応する、前記前記第２の取得ステップにより取得された状態を示す情報を、前記他の情報処理装置が有する前記機能に対応する前記情報処理装置が有する機能を示す情報に関連付けて登録する
   ことを特徴とする請求項１に記載のプログラム。
3. 前記情報処理装置が有する機能を示す機能毎の情報を、各情報処理装置が有する機能を示す情報を管理する情報管理装置に供給する第２の供給ステップをさらに実行させる
   ことを特徴とする請求項１に記載のプログラム。
4. ネットワークを介して、予め通信相手として登録されている複数の他の情報処理装置と情報を授受する情報処理装置の情報処理方法において、
   前記情報処理装置が有する機能を示す機能毎の情報のそれぞれに、前記情報処理装置が有する前記機能に対応する前記他の情報処理装置が有する機能およびその状態を示す機能毎の情報を関連付けて登録する登録ステップと、
   前記情報処理装置が有する機能の状態を示す機能毎の情報を、前記登録ステップにより登録された情報に基づいて、前記情報処理装置が有する前記機能に対応する機能を有する他の情報処理装置に対して供給する第１の供給ステップと
   を含むことを特徴とする情報処理方法。
5. 前記他の情報処理装置が有する機能を示す機能毎の情報を取得する第１の取得ステップと、
   前記他の情報処理装置が有する機能の状態を示す機能毎の情報を取得する第２の取得ステップと
   をさらに含み、
   前記登録ステップは、前記第１の取得ステップにより取得された前記他の情報処理装置が有する前記機能を示す機能毎の情報と、前記他の情報処理装置が有する前記機能に対応する、前記前記第２の取得ステップにより取得された状態を示す情報を、前記他の情報処理装置が有する前記機能に対応する前記情報処理装置が有する機能を示す情報に関連付けて登録する
   ことを特徴とする請求項４に記載の情報処理方法。
6. 前記情報処理装置が有する機能を示す機能毎の情報を、各情報処理装置が有する機能を示す情報を管理する情報管理装置に供給する第２の供給ステップをさらに含む
   ことを特徴とする請求項４に記載の情報処理方法。
7. ネットワークを介して、予め通信相手として登録されている複数の他の情報処理装置と情報を授受する情報処理装置において、
   前記情報処理装置が有する機能を示す機能毎の情報のそれぞれに、前記情報処理装置が有する前記機能に対応する前記他の情報処理装置が有する機能およびその状態を示す機能毎の情報を関連付けて登録する登録手段と、
   前記情報処理装置が有する機能の状態を示す機能毎の情報を、前記登録手段により登録された情報に基づいて、前記情報処理装置が有する前記機能に対応する機能を有する他の情報処理装置に対して供給する第１の供給手段と
   を備えることを特徴とする情報処理装置。
8. 前記他の情報処理装置が有する機能を示す機能毎の情報を取得する第１の取得手段と、
   前記他の情報処理装置が有する機能の状態を示す機能毎の情報を取得する第２の取得手段と
   をさらに実行させ、
   前記登録手段は、前記第１の取得手段により取得された前記他の情報処理装置が有する前記機能を示す機能毎の情報と、前記他の情報処理装置が有する前記機能に対応する、前記前記第２の取得手段により取得された状態を示す情報を、前記他の情報処理装置が有する前記機能に対応する前記情報処理装置が有する機能を示す情報に関連付けて登録する
   ことを特徴とする請求項７に記載の情報処理装置。
9. 前記情報処理装置が有する機能を示す機能毎の情報を、各情報処理装置が有する機能を示す情報を管理する情報管理装置に供給する第２の供給手段をさらに備える
   ことを特徴とする請求項７に記載の情報処理装置。

Images