JPWO2007088589A1 - 電子会議におけるコンテンツ配信方法及び装置 - Google Patents

Abstract

電子会議に参加するユーザにコンテンツデータを適切に配信することを目的とする。そのため、電子会議に参加する参加ユーザに対して配信すべきコンテンツデータのURIを特定の参加ユーザのユーザ端末から受信する工程と、受信したURIに係るサーバから当該URIに対応するコンテンツデータを取得し、コンテンツデータ格納部に格納する工程と、コンテンツデータ格納部に格納されたコンテンツデータを、参加ユーザのユーザ端末に送信する送信工程とを実行する。このようにURIを指定するだけで、電子会議のためのサーバが当該URIに対応するコンテンツデータを取得して送信するので、参加ユーザはアクセス権限にかかわらず当該コンテンツデータを利用できるようになる。

Description

本発明は、電子会議におけるコンテンツ配信技術に関する。

例えば「「コミュニケーション活性化サービス〜プレゼンスクラブ〜の提案」、２００３年電子情報通信学会総合大会、Ｂ−６−１８４、下村道夫、千葉一深、尾尻健」には、プレゼンス情報を利用したネットワークサービスについて以下のような事項が開示されている。すなわち、カメラ付き携帯電話機から写真及びテキストを含むプレゼンス登録要求をメールサーバに送信すると、メールサーバは写真を格納すると共に写真ＵＲＬ（Uniform Resource Locator）及びテキストを含むプレゼンス登録要求をプレゼンスサーバに送信する。プレゼンスサーバは、プレゼンス登録要求の受信に応じて写真ＵＲＬ及びテキストでプレゼンス更新を行う。そうすると、ＰＣ又はＰＤＡ（Personal Digital Assistant）などに写真ＵＲＬ及びテキストをプレゼンス通知として送信する。そうすると、ＰＣ又はＰＤＡは、写真ＵＲＬを用いて写真取得要求をメールサーバに送信し、メールサーバから写真のデータを取得する。

また、特開２００４−１３３０３号公報には、インスタントメッセージング（ＩＭ）技術を電子会議に応用する技術が開示されている。具体的には、ＩＭサーバに、各ＩＭクライアントのプレゼンス情報、利用可能メディア及びユーザ情報を管理させ、各ＩＭクライアントがこれらの情報を取得できるようにする。テキストチャットを行う場合、ＩＭサーバが各参加ＩＭクライアントとＩＭサーバとの間のコネクションを管理し、各参加ＩＭクライアントからのテキストをマージして結果を各参加ＩＭクライアントに配信する。音声チャットを行う場合、ＡＰサーバが各参加ＩＭクライアントとＭＤサーバとの間のコネクションを管理し、ＭＤサーバが注目ＩＭクライアントを除く各参加ＩＭクライアントからの音声をミックスして結果を注目ＩＭクライアントに配信する。この処理を各参加ＩＭクライアントに対して行う。但し、本公報は、プレゼンス技術の一般的な使い方（オフライン、ＩＭ中といったクライアントの状態を示すという使い方）を示すのみであり、プレゼンスデータの使用の仕方に特別なものはない。

また、このほかにプレゼンス技術には、特表２００３−５２６２７６号公報、特表２００４−５３３０４８号公報、特表２００５−５００７１４号公報などが存在する。
「コミュニケーション活性化サービス〜プレゼンスクラブ〜の提案」、２００３年電子情報通信学会総合大会、Ｂ−６−１８４、下村道夫、千葉一深、尾尻健」 特開２００４−１３３０３号公報 特表２００３−５２６２７６号公報 特表２００４−５３３０４８号公報 特表２００５−５００７１４号公報

上で述べた従来技術によれば、プレゼンス技術を利用した電子会議に参加するユーザ間で画像などのコンテンツデータを共有する場合には、各ユーザ端末にＵＲＬは配信されるが、コンテンツデータ自身は送信されないので、ＵＲＬを用いて自らコンテンツデータを取得する必要がある。

しかしながら、コンテンツデータにアクセス権限の設定がなされているが、例えば電子会議の参加ユーザの一部にそのアクセス権限を有していない参加ユーザがいる場合には、ＵＲＬだけではコンテンツデータを参加ユーザ全員で共有することができない。

また、電子会議の参加ユーザのユーザ端末は全て同じ種類であるわけではなく、ユーザ端末によってはコンテンツデータをそのまま取り扱うことができない場合も生ずる。

さらに、画像などのコンテンツデータを取り扱う場合には、サーバ側の負荷が問題になる場合もある。

従って、本発明の目的は、電子会議に参加するユーザにコンテンツデータを適切に配信するための新規な技術を提供することである。

また、本発明の他の目的は、電子会議に参加するユーザにコンテンツデータを受信側ユーザのアクセス権限にかかわらず配信するための新規な技術を提供することである。

さらに、本発明の他の目的は、電子会議に参加するユーザに使用可能なコンテンツデータを配信するための新規な技術を提供することである。

さらに、本発明の他の目的は、電子会議に参加するユーザにコンテンツデータを配信するためのサーバ負荷を減少させるための技術を提供することである。

本発明に係る、電子会議におけるコンテンツ配信方法は、電子会議に参加する参加ユーザに対して配信すべきコンテンツデータのＵＲＩ（Uniform Resource Identifier）を特定の参加ユーザのユーザ端末から受信するステップと、受信したＵＲＩに係るサーバから当該ＵＲＩに対応するコンテンツデータを取得し、コンテンツデータ格納部に格納する取得ステップと、コンテンツデータ格納部に格納されたコンテンツデータを、参加ユーザのユーザ端末に送信する送信ステップとを含む。

このようにコンテンツ送信権を有するユーザについてはＵＲＩを指定するだけで、電子会議のためのサーバが当該ＵＲＩに対応するコンテンツデータを取得して、電子会議の参加ユーザのユーザ端末に当該コンテンツデータを送信するので、アクセス権限にかかわらずコンテンツデータを利用することができるようになる。すなわち、電子会議のユーザの利便性が向上している。なお、コンテンツデータを保持するサーバ及び電子会議のためのサーバの間に所定の信頼関係があれば、完全にアクセス権限については問題なくなる。

なお、特定の参加ユーザがコンテンツ送信権を有することを確認する確認ステップをさらに含み、上で述べた取得ステップを特定の参加ユーザがコンテンツ送信権を有する場合に実行するようにしても良い。

また、上で述べた送信ステップにおいて、電子会議についてのプレゼンスデータとして、コンテンツデータ格納部に格納されたコンテンツデータを参加ユーザのユーザ端末に送信するようにしてもよい。電子会議についてのプレゼンスデータ配信機構を利用するものである。

さらに、本発明において、電子会議への参加に際して参加ユーザのユーザ端末で使用可能なデータに関する情報を受信し、データ格納部に格納するステップと、データ格納部に格納された参加ユーザのユーザ端末で使用可能なデータに関する情報に基づき、コンテンツデータ格納部に格納されたコンテンツデータが、参加ユーザのユーザ端末で使用可能なデータであるか否か判断する判断ステップとをさらに含むようにしてもよい。そして上で述べた送信ステップが、判断ステップにおいて肯定的な判断がなされたユーザ端末に対して実行されるようにしてもよい。このようにすれば、コンテンツデータを使用できないユーザ端末には送信されなくなるので、通信帯域の有効利用が図られる。

また、本発明において、電子会議への参加に際して参加ユーザのユーザ端末で使用可能なデータに関する情報を受信し、データ格納部に格納するステップと、データ格納部に格納された参加ユーザのユーザ端末で使用可能なデータに関する情報に基づき、コンテンツデータ格納部に格納されたコンテンツデータが、参加ユーザのユーザ端末で使用可能なデータであるか否か判断する判断ステップと、判断ステップにおいて否定的な判断がなされた場合、データ格納部に格納された参加ユーザのユーザ端末で使用可能なデータに関する情報に基づき、コンテンツデータについて参加ユーザのユーザ端末で使用可能なデータに変換し、コンテンツデータ格納部に格納するステップとをさらに含むようにしてもよい。

このような変換処理については、配信すべきプレゼンスデータとしてプレゼンス管理部に出力される前に行われる場合、プレゼンス管理部から出力される後に行われる場合、又はプレゼンスデータとは別のデータとして送信する前に行われる場合もある。

これによって参加ユーザのユーザ端末において使用可能なデータを取得できるようになる。なお、変換処理については様々な形態が可能であって、フォーマット変換や解像度変換など、さらにユーザ端末毎に変換を実施したり、参加ユーザのユーザ端末共通のデータ形式に変換するといったことが可能である。

さらに、上で述べた取得ステップが、仮想クライアントに対してＵＲＩを含む取得依頼を送信するステップと、仮想クライアントによって、取得依頼に含まれるＵＲＩに係るサーバから当該ＵＲＩに対応するコンテンツデータを取得するステップと、仮想クライアントからコンテンツデータを受信し、コンテンツデータ格納部に格納されるステップとを含むようにしてもよい。このように仮想クライアントでコンテンツデータの取得を行うようにすれば、主たる処理を実施するスレッドとは別スレッドとして実行することとなるために、電子会議のためのサーバにおける負荷上昇を抑えることができるようになる。また、仮想クライアントについては別サーバで負荷分散を実施することも可能である。

さらに、本発明において、特定のユーザのユーザ端末からＵＲＩに係るサーバに対する認証情報を受信するステップをさらに含むようにしてもよい。その場合、上で述べた取得ステップが、仮想クライアントに対してＵＲＩ及びＵＲＩに係るサーバに対する認証情報を含む取得依頼を送信するステップと、仮想クライアントによって、上記取得依頼に含まれるＵＲＩに係るサーバに認証情報を送信して認証を受けると共に当該ＵＲＩに対応するコンテンツデータを取得するステップと、仮想クライアントからコンテンツデータを受信し、コンテンツデータ格納部に格納されるステップとを含むようにしてもよい。このようにすれば、コンテンツデータを保持するサーバが特定のユーザに対してのみコンテンツデータを利用可能にしている場合においても、このような構成で対処可能となる。

また、本発明において、特定のユーザのユーザ端末から仮想クライアントの指定情報を受信するステップをさらに含むようにしてもよい。参加ユーザは、例えば仮想クライアントの種別を指定する場合もあれば、具体的に仮想クライアントのＩＤを指定する場合もある。さらに、ユーザ端末側でＵＲＩ等から仮想クライアントを自動的に設定する場合もある。またさらに電子会議のためのサーバで仮想クライアントを起動・指定する場合もある。

上で述べたコンテンツ配信方法をコンピュータに実行させるためのプログラム、会議管理サーバ又はプレゼンス・サーバに上で述べた処理を実行させるためのプログラム、及び携帯端末を上で述べたように動作させるためのプログラムを作成することができ、このプログラムは、例えばフレキシブルディスク、ＣＤ−ＲＯＭ、光磁気ディスク、半導体メモリ、ハードディスク等の記憶媒体又は記憶装置に格納される。また、ネットワークなどを介してデジタル信号として配信される場合もある。尚、中間的な処理結果はメモリ等の記憶装置に一時保管される。

図１は本発明の第１の実施例に係るシステム構成図である。 図２はユーザ端末の機能ブロック図である。 図３はユーザＡプレゼンス管理部の機能ブロック図である。 図４は会議Ａプレゼンス管理部の機能ブロック図である。 図５はユーザＡプレゼンス管理部におけるプレゼンスデータ格納部に格納されるデータの模式図である。 図６は会議Ａプレゼンス管理部におけるプレゼンスデータ格納部に格納されるデータの模式図である。 図７はプレゼンスＩＤが”ＦｌｏｏｒＵｓｅｒ”のプレゼンスデータの一例を示す図である。 図８はプレゼンスＩＤが”ＪｏｉｎＵｓｅｒ”のプレゼンスデータの一例を示す図である。 図９はプレゼンスＩＤが”Ｍｅｍｂｅｒ”のプレゼンスデータの一例を示す図である。 図１０はプレゼンスＩＤが”ＳｅｎｄｉｎｇＵｓｅｒ”のプレゼンスデータの一例を示す図である。 図１１は本発明の第１の実施例の処理フローの第１の部分を示す図である。 図１２は本発明の第１の実施例の処理フローの第２の部分を示す図である。 図１３は本発明の第１の実施例の処理フローの第３の部分を示す図である。 図１４は本発明の第１の実施例の処理フローの第４の部分を示す図である。 図１５は本発明の第１の実施例の処理フローの第５の部分を示す図である。 図１６は本発明の第１の実施例の処理フローの第６の部分を示す図である。 図１７は本発明の第１の実施例の処理フローの第７の部分を示す図である。 図１８は本発明の第１の実施例の処理フローの第８の部分を示す図である。 図１９は本発明の第１の実施例の処理フローの第９の部分を示す図である。 図２０は本発明の第１の実施例の処理フローの第１０の部分を示す図である。 図２１は本発明の第１の実施例の処理フローの第１１の部分を示す図である。 図２２は本発明の第１の実施例の処理フローの第１２の部分を示す図である。 図２３は本発明の第１の実施例の処理フローの第１３の部分を示す図である。 図２４は本発明の第１の実施例において会議Ａ管理部におけるユーザデータ格納部に格納されるデータの一例を示す図である。 図２５は本発明の第２の実施例に係るシステム構成図である。 図２６は会議Ａプレゼンス管理部におけるプレゼンスデータ格納部に格納されるデータの模式図である。 図２７はプレゼンスＩＤが”ＦｅｔｃｈＲｅｑｕｅｓｔｉｎｇＵｓｅｒ”のプレゼンスデータの一例を示す図である。 図２８は本発明の第２の実施例におけるコンテンツ配信処理の処理フローの第１の部分を示す図である。 図２９は本発明の第２の実施例におけるコンテンツ配信処理の処理フローの第２の部分を示す図である。 図３０は本発明の第２の実施例におけるコンテンツ配信処理の処理フローの第３の部分を示す図である。 図３１は本発明の第２の実施例におけるコンテンツ配信処理の処理フローの第４の部分を示す図である。 図３２はコンピュータの機能ブロック図を示す図である。

１．第１の実施例
図１に本発明の第１の実施例に係るシステム概要図を示す。例えば携帯電話網であるネットワーク１には、図示しない無線基地局を介して複数の携帯電話機（ここではユーザＡが操作するユーザ端末Ａ及びユーザＢが操作するユーザ端末Ｂ）が接続されている。携帯電話機は、ＰＨＳ（Personal Handyphone System）端末の場合もあり、音声通話機能を有するだけではなく、メール・クライアント、ウェブ（Ｗｅｂ）ブラウザ、本実施例におけるクライアントアプリケーションなどの各種アプリケーションプログラムを実行することができる。また、ユーザ端末Ａ及びＢは、音声通話機能付きのＰＤＡ（Personal Digital Assistant）等の携帯端末であってもよい。本実施例におけるユーザ端末Ａ及びＢについては、後に機能ブロック図を用いて説明する。

ネットワーク１には、ＳＩＰ／ＳＩＭＰＬＥサーバ３と、ＰｏＣ（Push-to-talk over Cellular）管理サーバ５と、ＰｏＣ−ＭＣＵ（Multipoint Communication Unit）サーバ７と、コンテンツサーバ９（又はメディアサーバとも呼ぶ）とが接続されている。ＳＩＰ／ＳＩＭＰＬＥサーバ３とＰｏＣ管理サーバ５とは、それらの機能を備えた１台のサーバコンピュータであってもよい。さらに、ＰｏＣ−ＭＣＵサーバ７をさらに統合するようなサーバ構成を採用する場合もある。

ＳＩＰ／ＳＩＭＰＬＥサーバ３は、ユーザＡのプレゼンス管理部３１ａと、ユーザＢのプレゼンス管理部３１ｂと、会議Ａのプレゼンス管理部３３ａと、会議Ｂのプレゼンス管理部３３ｂと、ルーティング処理部３５とを有する。ここでは説明を簡単にするためユーザＡ及びＢのプレゼンス管理部のみを示しているが、ユーザの数だけプレゼンス管理部は設けられる。また、図１では会議Ａ及びＢのプレゼンス管理部のみを示しているが、会議の数だけプレゼンス管理部は設けられる。また、ＳＩＰ／ＳＩＭＰＬＥサーバ３には、ユーザの認証処理を行う処理部など本実施例と直接関係しない処理部も含まれるが、ここでは図示していない。ユーザのプレゼンス管理部及び会議のプレゼンス管理部については、後に機能ブロック図を用いて説明する。

ＰｏＣ管理サーバ５は、ＰｏＣ制御サーバとも呼ばれ、電子会議の制御及び管理を行うサーバであり、各会議のための処理を行う会議管理部５３（ここでは会議Ａのための処理を行う会議Ａ管理部５３ａ及び会議Ｂのための処理を行う会議Ｂ管理部５３ｂ）と、ＳＩＰ／ＳＩＭＰＬＥサーバ３のルーティング処理部３５から転送されてくるメッセージを担当の会議管理部５３に転送する振分処理を実施するメッセージ振分処理部５１と、ユーザから会議参加者に配信を要求されたコンテンツを取得するコンテンツデータ取得部５５と、コンテンツデータの変換処理を実施するコンテンツ変換部５６とを含む。また、会議管理部５３は、ＭＣＵ情報格納部５３１（ここでは会議ＡのＭＣＵ情報格納部５３１ａ）と、ユーザデータ格納部５３３（ここでは会議Ａのユーザデータ格納部５３３ａ）と、コンテンツデータ格納部５３５（ここでは会議Ａのコンテンツデータ格納部５３５ａ）とを含む。コンテンツデータ格納部５３５ａは、会議Ａの参加者に配信すべきコンテンツデータを格納する。このように、ＰｏＣ管理サーバ５は、会議Ａの参加者に配信すべきデータの管理をも行う。

また、ＰｏＣ−ＭＣＵサーバ７は、各会議のための音声通信を管理及び制御する会議音声通信管理部７１（ここでは会議Ａのための処理を行う会議Ａ音声通信管理部７１ａ及び会議Ｂのための処理を行う会議Ｂ音声通信管理部７１ｂ）を含み、会議音声通信管理部７１は話者及び参加者データ格納部７１１（ここでは会議Ａの話者及び参加者データ格納部７１１ａ）を含む。

また、コンテンツサーバ９は、登録ユーザ又は任意のユーザに対してコンテンツデータ格納部９１に格納されているデータを配信する。コンテンツは、例えば静止画像、動画像、テキストなど、ユーザ端末で閲覧可能なデータを前提とするが、その他のデータであってもよい。なお、第１の実施例では、ＰｏＣ管理サーバ５とコンテンツサーバ９とはその運営者が同一であったり、何らかの提携関係があるなど、登録ユーザに対してのみコンテンツを配信するような場合であっても、ＰｏＣ管理サーバ５からの要求であればコンテンツサーバ９は応答しても問題がないものとする。但し、認証ではなく要求元ユーザのＩＤだけ確認するようにしても良い。

図１において、ユーザ端末は、ネットワーク１を介してＳＩＰ／ＳＩＭＰＬＥサーバ３とＳＩＭＰＬＥ（SIP（Session Initiation Protocol） for Instant Messaging and Presence Leveraging Extensions）／ＴＣＰで通信を行い、ネットワーク１を介してＰｏＣ−ＭＣＵサーバ７とはＲＴＰ（Real-time Transport Protocol）／ＵＤＰで通信を行うようになっている。

次に図２にユーザ端末の機能ブロック図を示す。ユーザ端末は、本実施例における処理を行うためのクライアントアプリケーション９１と、ユーザ端末に設けられているマイクのマイクドライバ９３とを含む。クライアントアプリケーション９１は、音声会議処理部９１１と、コンテンツ処理部９１３と、プレゼンスデータ処理部９１５とを含む。コンテンツ処理部９１３は、ユーザからのコンテンツ配信依頼を受け付け、ＰｏＣ管理サーバ５等に必要な処理を依頼したり、ＵＲＩ（Uniform Resource Indicator）を送信したり、さらにサーバからコンテンツデータを受信して表示装置に表示したりする。なお、本実施例において直接関係のない機能については図示されていない。

また図３にユーザＡのプレゼンス管理部３１ａの機能ブロック図を示す。ユーザＡのプレゼンス管理部３１ａは、プレゼンスデータ管理部３１１ａと、プレゼンスデータ格納部３１３ａと、配信処理部３１５ａとを有している。ユーザＡのプレゼンス管理部３１ａは、ユーザ端末Ａのクライアントアプリケーション９１と協働してプレゼンスデータ格納部３１３ａに格納されたデータの更新を行ったり、プレゼンスデータ格納部３１３ａに格納されたデータの配信処理を行う。

さらに図４に会議Ａのプレゼンス管理部３３ａの機能ブロック図を示す。会議Ａのプレゼンス管理部３３ａは、プレゼンスデータ管理部３３１ａと、プレゼンスデータ格納部３３３ａと、配信処理部３３５ａとを有している。会議Ａのプレゼンス管理部３３ａは、ＰｏＣ管理サーバ５の会議Ａ管理部５３ａ及びユーザ端末のクライアントアプリケーション９１と協働してプレゼンスデータ格納部３３３ａに格納されたデータの更新を行ったり、プレゼンスデータ格納部３３３ａに格納されたデータの配信処理を行う。

図５にユーザＡプレゼンス管理部３１ａに含まれるプレゼンスデータ格納部３１３ａに格納されるデータの一例を示す。図５の例では、プレゼンスデータ格納部３１３ａは、プレゼンス情報格納領域３１３１と、プレゼンスグループ情報格納領域３１３３と、講読者リスト格納領域３１３５とを含む。プレゼンス情報格納領域３１３１は、プレゼンスデータ項目ごとにプレゼンスデータ（ここではユーザ又はユーザ端末の状態情報）を格納するための領域であり、プレゼンスデータ項目のＩＤであるプレゼンスＩＤが”Ｓｔａｔｅ”であるプレゼンスデータ（主にＯＮＬＩＮＥ、ＯＦＦＬＩＮＥ又はＢＵＳＹのいずれか。但し、他の状態（例えば「データ配信中」又は「ＤＡＴＡ Ｓｅｎｄｉｎｇ」など）であってもよい。）を格納するための領域３１６を含む。プレゼンスデータ項目の数に制限はないが、本実施例ではユーザ端末の状態を示すプレゼンスデータ項目のみが示されている。プレゼンスグループ情報格納領域３１３３は、プレゼンスデータ項目（すなわちプレゼンスＩＤ）と配信先ユーザＩＤ（すなわち講読者ＩＤ）を対応付けるためのデータを格納する領域である。ここでは、プレゼンスグループであるグループＩ「デフォルト」に属するプレゼンスＩＤを格納する領域３１７１及びユーザＩＤ（すなわち講読者ＩＤ）を格納する領域３１７２を含む領域３１７が含まれる。デフォルトグループは、講読者が初期的に登録されるグループである。グループ数に限定はなく、任意の数のグループを定義し得る。講読者リスト格納領域３１３５は、ここではＵｓｅｒＢ及びＵｓｅｒＣといった情報配信が許可されたユーザのユーザＩＤ（すなわち講読者ＩＤ）が登録される。講読者数に限定はなく、任意の数の講読者が登録される。

また図６に会議Ａプレゼンス管理部３３ａに含まれるプレゼンスデータ格納部３３３ａに格納されるデータの一例を示す。図６の例では、プレゼンス情報格納領域３３３１と、プレゼンスグループ情報格納領域３３３３と、講読者リスト格納領域３３３５とが含まれる。プレゼンス情報格納領域３３３１は、プレゼンスデータ項目のＩＤであるプレゼンスＩＤが”ＦｌｏｏｒＵｓｅｒ”であるプレゼンスデータ（ここでは話者権（発言権とも呼ぶ）を有するユーザの講読者ＩＤ）を格納するための領域３３６１と、プレゼンスデータ項目のＩＤであるプレゼンスＩＤが”Ｍｅｍｂｅｒ”であるプレゼンスデータ（ここでは音声会議に呼び出されたユーザの講読者ＩＤ）を格納するための領域３３６２と、プレゼンスデータ項目のＩＤであるプレゼンスＩＤが”ＪｏｉｎＵｓｅｒ”であるプレゼンスデータ（ここでは音声会議に参加したユーザの講読者ＩＤ）を格納するための領域３３６３と、プレゼンスデータ項目のＩＤであるプレゼンスＩＤが”ＳｅｎｄｉｎｇＵｓｅｒ”であるプレゼンスデータ（ここではコンテンツ送信権を有する講読者ＩＤ及びコンテンツのＵＲＩ（例えばhttp://photo.fj.com/aa/bb/img.jpg））を格納するための領域３３６４とを含む。

本実施例では、プレゼンスＩＤが”ＦｌｏｏｒＵｓｅｒ”、Ｍｅｍｂｅｒ”及び”ＪｏｉｎＵｓｅｒ”であるプレゼンスデータについては、講読者ＩＤのみが通知され、その講読者ＩＤのユーザがいかなる状態にあるかについては通知していない。状態については、そのユーザの個人のプレゼンスデータを通知するようにしても良い。プレゼンスＩＤが”ＳｅｎｄｉｎｇＵｓｅｒ”であるプレゼンスデータについても、本実施例では講読者ＩＤのみが通知され、その講読者ＩＤのユーザがいかなる状態にあるかについては通知していない。但し、”コンテンツ配信中”といった状態データをプレゼンスデータに含めて、当該状態データも併せて送信するようにしても良い。

また、プレゼンスグループ情報格納領域３３３３は、プレゼンスグループであるグループＩ「デフォルト」に属するプレゼンスＩＤを格納する領域３３７１及びユーザＩＤ（すなわち講読者ＩＤ）を格納する領域３３７３を含む領域３３７と、プレゼンスグループであるグループII「音声会議」に属するプレゼンスＩＤを格納する領域３３８１及びユーザＩＤ（すなわち講読者ＩＤ）を格納する領域３３８２を含む領域３３８と、プレゼンスグループであるグループIII「コンテンツ」に属するプレゼンスＩＤを格納する領域３３９１及びユーザＩＤ（すなわち講読者ＩＤ）を格納する領域３３９２を含む領域３３９とを含む。

音声会議に参加するユーザの講読者ＩＤは領域３３８２に格納され、音声会議に参加するユーザに開示されるデータはプレゼンスＩＤが”ＦｌｏｏｒＵｓｅｒ”と”Ｍｅｍｂｅｒ”と”ＪｏｉｎＵｓｅｒ”であるプレゼンスデータである。すなわち、話者権保持者の講読者ＩＤと、呼び出されたユーザの講読者ＩＤリストと、参加したユーザの講読者ＩＤリストが提示される。また、コンテンツ配信に参加するユーザの講読者ＩＤは領域３３９２に格納され、コンテンツ配信に参加するユーザに開示されるデータはプレゼンスＩＤが”ＳｅｎｄｉｎｇＵｓｅｒ”であるプレゼンスデータである。但し、プレゼンスＩＤが”ＳｅｎｄｉｎｇＵｓｅｒ”であるプレゼンスデータに含まれるＵＲＩ自体については本実施例では配信しない。すなわち、コンテンツ送信権保持者の講読者ＩＤが提示される。

講読者リスト格納領域３３３５には、ここではＵｓｅｒＡ、ＵｓｅｒＢ、ＵｓｅｒＣといった情報配信が許可されたユーザのユーザＩＤ（すなわち講読者ＩＤ）が登録される。

また、ユーザ端末においては、講読者ＩＤではなく各ユーザを表すマークを示し、ＦｌｏｏｒＵｓｅｒに該当するユーザに話者権を表すマークを追加したり、全く別のマークを示すようにしても良い。さらに、ＳｅｎｄｉｎｇＵｓｅｒに該当するユーザにも、コンテンツ送信権又はコンテンツ配信中を表すマークを追加したり、全く別のマークを示すようにしても良い。

なお、コンテンツ配信先のユーザは、音声会議に参加しているユーザの一部であってもよいし、全員であってもよい。以下の説明では、コンテンツ配信先のユーザは、音声会議の会議メンバ又は参加応答を行ったユーザ全員の場合について説明する。すなわち、プレゼンスＩＤが”Ｍｅｍｂｅｒ”又は”ＪｏｉｎＵｓｅｒ”であるプレゼンスデータに併せて講読者ＩＤが領域３３９２に登録される。

図５及び図６は、プレゼンスデータ格納部に格納されるデータを模式的に示したものであり、例えばプレゼンスＩＤが”ＦｌｏｏｒＵｓｅｒ”であるプレゼンスデータのための領域３３６１に、例えば図７に示すようなタグデータ構造のデータを格納する。図７の例は、基本的にはＯＭＡ（Open Mobile Alliance）に準拠した形でＸＭＬ（eXtensible Markup Language）を用いて記述されている。ここで注目すべきは、上から４行目にｅｎｔｉｔｙ＝”ｐｒｅｓ：Ｃｏｎｆｅｒｅｎｃｅ０１＠ｐｏｃ．ｆｊ．ｃｏｍ”というフレーズにて、プレゼンスＩＤが”ＦｌｏｏｒＵｓｅｒ”であるプレゼンスデータの所有者が、Ｃｏｎｆｅｒｅｎｃｅ０１＠ｐｏｃ．ｆｊ．ｃｏｍというＳＩＰ−ＵＲＬ（Uniform Resource Locator）で特定されている点である。ここで、このプレゼンスデータの所有者はＰｏＣ管理サーバ５の会議Ａ管理部５３ａであり、このプレゼンスデータは会議Ａ管理部５３ａにより更新される。また、会議Ａ管理部５３ａのＳＩＰ−ＵＲＬはＣｏｎｆｅｒｅｎｃｅ０１＠ｐｏｃ．ｆｊ．ｃｏｍである。さらに、＜ｎｏｔｅ＞及び＜／ｎｏｔｅ＞タグとの間に話者権保持者のユーザＩＤとしてＳＩＰ−ＵＲＬ”ＵｓｅｒＡ＠ｐｏｃ．ｆｊ．ｃｏｍ”が登録される。図５及び図６では、”ＵｓｅｒＡ＠ｐｏｃ．ｆｊ．ｃｏｍ”を簡略表示して”ＵｓｅｒＡ”と示している。

同様に、プレゼンスＩＤが”ＪｏｉｎＵｓｅｒ”であるプレゼンスデータのための領域３３６３に、例えば図８に示すようなタグデータ構造のデータを格納する。図８の例では、図７と同様に、このプレゼンスデータの所有者が、Ｃｏｎｆｅｒｅｎｃｅ０１＠ｐｏｃ．ｆｊ．ｃｏｍというＳＩＰ−ＵＲＬで特定されており、＜ｎｏｔｅ＞及び＜／ｎｏｔｅ＞タグとの間に音声会議の参加者のＳＩＰ−ＵＲＬ”ＵｓｅｒＡ＠ｐｏｃ．ｆｊ．ｃｏｍ，ＵｓｅｒＢ＠ｐｏｃ．ｆｊ．ｃｏｍ”がユーザＩＤとして登録される。

さらに、プレゼンスＩＤが”Ｍｅｍｂｅｒ”であるプレゼンスデータのための領域３３６２に、例えば図９に示すようなタグデータ構造のデータを格納する。図９の例では、図７と同様に、このプレゼンスデータの所有者が、Ｃｏｎｆｅｒｅｎｃｅ０１＠ｐｏｃ．ｆｊ．ｃｏｍというＳＩＰ−ＵＲＬで特定されており、＜ｎｏｔｅ＞及び＜／ｎｏｔｅ＞タグとの間に音声会議に呼び出されたユーザのＳＩＰ−ＵＲＬ”ＵｓｅｒＡ＠ｐｏｃ．ｆｊ．ｃｏｍ，ＵｓｅｒＢ＠ｐｏｃ．ｆｊ．ｃｏｍ，ＵｓｅｒＣ＠ｐｏｃ．ｆｊ．ｃｏｍ”がユーザＩＤとして登録される。

また、プレゼンスＩＤが”ＳｅｎｄｉｎｇＵｓｅｒ”であるプレゼンスデータのための領域３３６４に格納されるプレゼンスデータは、例えば図１０に示すようなタグデータ構造のデータを格納する。図１０の例では、このプレゼンスデータの所有者が、Ｃｏｎｆｅｒｅｎｃｅ０１＠ｐｏｃ．ｆｊ．ｃｏｍというＳＩＰ−ＵＲＬで特定されており、＜ｎｏｔｅ＞及び＜／ｎｏｔｅ＞タグの間において、＜ＳｅｎｄｉｎｇＵｓｅｒ＞及び＜／ＳｅｎｄｉｎｇＵｓｅｒ＞との間にコンテンツ送信権を有するユーザのユーザＩＤ（ここではＵｓｅｒＡ＠ｐｏｃ．ｆｊ．ｃｏｍ）と、＜ｃｏｎｔｅｎｔ＞及び＜／ｃｏｎｔｅｎｔ＞の間にコンテンツ送信権を有するユーザが指定したＵＲＩ（ここではhttp://photo.fj.com/aa/bb/img.jpg）とが登録される。

プレゼンスデータは原則として所有者により更新され、更新されると当該プレゼンスデータのプレゼンスＩＤが関連付けられているユーザＩＤのユーザに配信処理部により配信される。また、ＰｏＣ管理サーバ５の会議Ａ管理部５３ａ及び会議Ｂ管理部５３ｂなどは、ＳＩＰ／ＳＩＭＰＬＥサーバ３中のプレゼンスデータに対してスーパーバイザ権限を有するようにして、必要なプレゼンスデータの変更を随時行うようにしても良い。

次に、図１１乃至図２４を用いて図１乃至図４に示したシステムの処理フローを説明する。なお、ユーザはすべてＳＩＰ／ＳＩＭＰＬＥサーバ３にログインして、認証が済んでいるものとする。さらに、ユーザ端末のＩＰアドレスとユーザＩＤ（ＳＩＰ−ＵＲＬ）との対応付けは、ＳＩＰ／ＳＩＭＰＬＥサーバ３内で完了しているものとする。まず、ユーザＡは、ユーザ端末Ａを操作して、音声ベースの電子会議を開始するため当該会議に呼び出すメンバを指定して呼出指示を入力する。ユーザ端末Ａにおけるクライアントアプリケーション９１の音声会議処理部９１１は、音声ベースの電子会議に呼び出すメンバの呼出依頼についてのユーザ操作入力を受け付け（ステップＳ１）、会議メンバのリスト（例えばＳＩＰ−ＵＲＬのリスト）を含む呼出依頼をＳＩＰ／ＳＩＭＰＬＥサーバ３に送信する（ステップＳ３）。なお、この呼出依頼には、ＳＤＰ（Session Description Protocol）によるメディア情報（使用可能なデータ（ファイル）形式、圧縮方式の情報、サイズなど）が含まれている。ＳＩＰ／ＳＩＭＰＬＥサーバ３のルーティング処理部３５は、ユーザ端末Ａから会議メンバのリストを含む呼出依頼を受信し、呼出依頼であると判断するとＰｏＣ管理サーバ５に転送する（ステップＳ５）。ＰｏＣ管理サーバ５のメッセージ振分処理部５１は、ＳＩＰ／ＳＩＭＰＬＥサーバ３のルーティング処理部３５から会議メンバのリストを含む呼出依頼を受信する（ステップＳ７）。この受信に応答して、ＰｏＣ管理サーバ５のメッセージ振分処理部５１は、ＯＫレスポンスを返信する（ステップＳ９）。ＳＩＰ／ＳＩＭＰＬＥサーバ３のルーティング処理部３５は、ＰｏＣ管理サーバ５からＯＫレスポンスを受信すると、ユーザ端末Ａに転送する（ステップＳ１１）。ユーザ端末Ａは、ＳＩＰ／ＳＩＭＰＬＥサーバ３からＯＫレスポンスを受信する（ステップＳ１３）。これにより、ユーザ端末Ａは、呼出要求がＰｏＣ管理サーバ５により受信されたことを認識することができる。

ＰｏＣ管理サーバ５のメッセージ振分処理部５１は、会議メンバのリストを含む呼出依頼を受信すると、新規に会議を行うこととなるため、会議管理部５３を新たに起動し（例えば会議Ａ管理部５３ａを新たに起動し）、当該会議Ａ管理部５３ａにＳＩＰ−ＵＲＬを割り当てる（ステップＳ１４）。会議Ａ管理部５３ａは、会議メンバのリストをユーザデータ格納部５３３ａに格納すると共に、会議メンバのリストを含む新規会議作成依頼を、ＰｏＣ−ＭＣＵサーバ７に送信する（ステップＳ１５）。また、会議メンバのリストには、呼出依頼元ユーザのユーザＩＤ及びそのユーザ端末のＩＰアドレスも含まれ、話者権保持者として特定されている。なお、会議Ａ管理部５３ａは、ユーザデータ格納部５３３ａに、呼出依頼に含まれるＳＤＰによるメディア情報について呼出依頼元ユーザに対応して登録しておく。

ＰｏＣ−ＭＣＵサーバ７は、会議メンバのリストを含む新規会議作成依頼を受信すると、新たな会議のためのリソースを確保すべく新たな会議音声通信管理部７１（例えば会議Ａ音声通信管理部７１ａ）を起動する。そして、会議Ａ音声通信管理部７１ａは、会議メンバのリストを話者及び参加者データ格納部７１１ａに格納する（ステップＳ１７）。なお、会議Ａ音声通信管理部７１ａは、会議Ａ管理部５３ａのＳＩＰ−ＵＲＬを保持しておき、会議Ａ管理部５３ａからの指示に応答できるようにする。そして、会議Ａ音声通信管理部７１ａは、呼出依頼に係る会議において使用されるリソース、すなわちＩＰアドレス及びポート番号などを確保し、さらに呼出依頼元ユーザに話者権を設定する（ステップＳ１９）。話者権を有するユーザについては、話者及び参加者データ格納部７１１ａにおいて識別可能なようにデータが保持されている。本実施例では、話者権を有する者のみがＰｏＣ−ＭＣＵサーバ７に音声データを他の参加者へ転送させることができる。この後、処理は端子Ａ乃至Ｄを介して図１２の処理に遷移する。なお、呼出依頼元ユーザのユーザ端末のＩＰアドレスについては、この段階で、話者及び参加者データ格納部７１１ａに登録しておく。

図１２を用いて端子Ａ乃至Ｄ以降の処理について説明する。ＰｏＣ−ＭＣＵサーバ７の会議Ａ音声通信管理部７１ａは、ステップＳ１９で確保したリソースであるＩＰアドレス及びポート番号を音声送信先情報としてＰｏＣ管理サーバ５に送信する（ステップＳ２１）。ＰｏＣ管理サーバ５の会議Ａ管理部５３ａは、ＰｏＣ−ＭＣＵサーバ７から音声送信先情報を受信し、ＭＣＵ情報格納部５３１ａに格納する（ステップＳ２３）。そして、会議Ａ管理部５３ａは、ＭＣＵ情報格納部５３１ａに格納されたデータを用いて、音声送信先情報（ＰｏＣ−ＭＣＵサーバ７のＩＰアドレス及びポート番号）と当該会議Ａ管理部５３ａのＳＩＰ−ＵＲＬを会議情報としてＳＩＰ／ＳＩＭＰＬＥサーバ３に送信する（ステップＳ２５）。ＳＩＰ／ＳＩＭＰＬＥサーバ３のルーティング処理部３５は、ＰｏＣ管理サーバ５から会議情報を受信すると、呼出依頼元のユーザ端末Ａに、当該会議情報を転送する（ステップＳ２７）。なお、このタイミングにて、受信した会議情報に基づき当該会議のプレゼンス管理部（ここでは会議Ａプレゼンス管理部３３ａ）を起動するようにしてもよい。

ユーザ端末Ａにおけるクライアントアプリケーション９１の音声会議処理部９１１は、ＳＩＰ／ＳＩＭＰＬＥサーバ３から会議情報を受信し、記憶装置に格納する（ステップＳ２９）。音声会議処理部９１１は、ＯＫレスポンスをＳＩＰ／ＳＩＭＰＬＥサーバ３に返信する（ステップＳ３１）。ＳＩＰ／ＳＩＭＰＬＥサーバ３のルーティング処理部３５は、ユーザ端末ＡからＯＫレスポンスを受信すると、ＰｏＣ管理サーバ５に転送する（ステップＳ３３）。ＰｏＣ管理サーバ５の会議Ａ管理部５３ａは、ＳＩＰ／ＳＩＭＰＬＥサーバ３からＯＫレスポンスを受信する（ステップＳ３５）。なお、メッセージ振分処理部５１が、ＳＩＰ／ＳＩＭＰＬＥサーバ３からメッセージ（ここではＯＫレスポンス）を受信して、担当の会議Ａ管理部５３ａに転送する。但し、以下の説明では、メッセージ振分処理部５１の受信については、説明を省略する。

またユーザ端末Ａにおけるクライアントアプリケーション９１の音声会議処理部９１１は、会議情報受信に応じて、マイクドライバ９３を起動する（ステップＳ３７）。すなわち、ユーザ端末ＡのマイクはユーザＡの音声を検出して電気信号に変換し、マイクドライバ９３は、マイクによって受け付けた音声を送信するため、音声パケットのデータを生成する。これによりユーザ端末Ａは、受信した会議情報に含まれるＩＰアドレス及びポート番号に従って、ＰｏＣ−ＭＣＵサーバ７に音声パケットを送信することができるようになる。但し、現段階でＰｏＣ−ＭＣＵサーバ７に音声パケットを送信しても、ＰｏＣ−ＭＣＵサーバ７は他の参加者が特定されていないので、音声パケットのコピー及び転送を行うことはない。処理は端子Ｅ及びＦを介して図１３の処理に移行する。

次に図１３を用いて端子Ｅ及びＦ以降の処理を説明する。ＰｏＣ管理サーバ５の会議Ａ管理部５３ａは、ユーザデータ格納部５３３ａに格納されたデータを用いて、呼出依頼元を除く各会議メンバのプレゼンスデータ取得要求をＳＩＰ／ＳＩＭＰＬＥサーバ３に送信する（ステップＳ３９）。プレゼンスデータ取得要求は、会議メンバ毎に送信される。ＳＩＰ／ＳＩＭＰＬＥサーバ３における各会議メンバのプレゼンス管理部３１は、ＰｏＣ管理サーバ５から各会議メンバのプレゼンスデータ取得要求を受信する（ステップＳ４１）。通常、ユーザのプレゼンスデータは当該ユーザのみが更新でき、さらに当該ユーザにより許可された者のみが講読できるようになっている。従って、ＰｏＣ管理サーバ５は、通常であれば会議メンバのプレゼンスデータを取得することはできないが、ＰｏＣ管理サーバ５からの要求であれば、講読許可がなくともプレゼンスデータの参照を可能とするようにプレゼンスデータ管理部３１１に予め設定しておく。または、上で述べたようにＳＩＰ／ＳＩＭＰＬＥサーバ３におけるプレゼンスデータに対してＰｏＣ管理サーバ５にスーパーバイザ権限を与えておくようにしても良い。従って、プレゼンスデータ取得要求を受信したプレゼンス管理部３１のプレゼンスデータ管理部３１１は、プレゼンスデータ格納部３１３から会議メンバのユーザ又はユーザ端末の状態を表すプレゼンスデータを読み出し、ＰｏＣ管理サーバ５に送信する（ステップＳ４３）。

ＰｏＣ管理サーバ５の会議Ａ管理部５３ａは、ＳＩＰ／ＳＩＭＰＬＥサーバ３から各会議メンバのプレゼンスデータを受信し（ステップＳ４５）、当該各会議メンバのプレゼンスデータから呼出可能な会議メンバを抽出する（ステップＳ４７）。すなわち、プレゼンスデータが通話可能という状態（例えばＯＮＬＩＮＥ）を示している会議メンバを抽出する。ＯＦＦＬＩＮＥやＢＵＳＹという状態であれば、音声会議の通話は不可能であるから、以下で説明する呼出処理を実施しないようにする。これにより呼出処理を高速化することができる。但し、ステップＳ３９からステップＳ４７の処理は、オプションである。処理は、端子Ｇ及びＨを介して図１４の処理に移行する。なお、説明を簡単にするため呼び出す会議メンバはユーザ端末Ｂを操作するユーザＢのみであるものとする。

図１４を用いて端子Ｇ及びＨ以降の処理を説明する。ＰｏＣ管理サーバ５の会議Ａ管理部５３ａは、ユーザデータ格納部５３３ａ及びＭＣＵ情報格納部５３１ａに格納されたデータを用いて、会議情報（会議Ａ管理部５３ａのＳＩＰ−ＵＲＬ及びＰｏＣ−ＭＣＵサーバ７のＩＰアドレス及びポート番号）を含む、呼出可能な会議メンバに対する呼出を、ＳＩＰ／ＳＩＭＰＬＥサーバ３に送信する（ステップＳ４９）。なお、本呼出には呼出依頼元ユーザのデータを含める。ＳＩＰ／ＳＩＭＰＬＥサーバ３のルーティング処理部３５は、ＰｏＣ管理サーバ５から、会議情報を含む、呼出可能な会議メンバに対する呼出を受信し、各会議メンバのユーザ端末に当該呼出を転送する（ステップＳ５１）。ここではユーザ端末Ｂの音声会議処理部９１１が、ＳＩＰ／ＳＩＭＰＬＥサーバ３から会議情報を含む呼出を受信し、当該呼出に応じた処理を実施する（ステップＳ５３）。例えば、着信音を鳴らせたり、表示装置に所定の表示を行わせたりして、呼出を受信したことをユーザＢに知らせる。なお、受信した会議情報については記憶装置に格納して、後に参加応答を行う際に用いる。

ユーザ端末Ｂの音声会議処理部９１１は、呼出に対するＯＫレスポンスをＳＩＰ／ＳＩＭＰＬＥサーバ３に送信する（ステップＳ５５）。ＳＩＰ／ＳＩＭＰＬＥサーバ３のルーティング処理部３５は、ユーザ端末ＢからＯＫを受信すると、ＰｏＣ管理サーバ５に転送する（ステップＳ５７）。ＰｏＣ管理サーバ５の会議Ａ管理部５３ａは、ＳＩＰ／ＳＩＭＰＬＥサーバ３からＯＫレスポンスを受信する（ステップＳ５９）。このＯＫレスポンスにも、ＳＤＰによるメディア情報が含まれており、会議Ａ管理部５３ａは、受信したメディア情報をユーザＢのユーザＩＤに対応して保持する。

ユーザＢは、ステップＳ５３における呼出に応じて、音声会議に参加するか否かを判断する。参加する場合には、ユーザ端末Ｂを操作して会議参加指示を入力する。ユーザ端末Ｂの音声会議処理部９１１は、ユーザＢによる会議参加指示入力を受け付け（ステップＳ６１）、参加応答をＳＩＰ／ＳＩＭＰＬＥサーバ３に送信する（ステップＳ６３）。ＳＩＰ／ＳＩＭＰＬＥサーバ３のルーティング処理部３５は、ユーザ端末Ｂから参加応答を受信すると、ＰｏＣ管理サーバ５に転送する（ステップＳ６５）。ＰｏＣ管理サーバ５の会議Ａ管理部５３ａは、ユーザＢからの参加応答をＳＩＰ／ＳＩＭＰＬＥサーバ３から受信する（ステップＳ６７）。会議Ａ管理部５３ａは、参加応答を行ったユーザのユーザＩＤ（すなわちＳＩＰ−ＵＲＬ）及びそのユーザ端末のＩＰアドレスをユーザデータ格納部５３３ａに参加者として登録する。ここでステップＳ５９でユーザ端末Ｂから受信したメディア情報を、ユーザ端末ＢのユーザＩＤに対応してユーザデータ格納部５３３ａに格納しておく。さらに、参加応答を行ったユーザのユーザＩＤ（すなわちＳＩＰ−ＵＲＬ）及びそのユーザ端末のＩＰアドレスを含む参加メンバ追加通知をＰｏＣ−ＭＣＵサーバ７に送信する（ステップＳ６９）。ＰｏＣ−ＭＣＵサーバ７の会議Ａ音声通信管理部７１ａは、ＰｏＣ管理サーバ５から参加者のユーザＩＤ及びＩＰアドレスを含む参加メンバ追加通知を受信し、話者及び参加者データ格納部７１１ａに参加者のユーザＩＤ及びＩＰアドレスを登録する（ステップＳ７１）。

ステップＳ６９の後に、会議Ａ管理部５３ａは、ＯＫレスポンスをＳＩＰ／ＳＩＭＰＬＥサーバ３に送信する（ステップＳ７３）。ＳＩＰ／ＳＩＭＰＬＥサーバ３のルーティング処理部３５は、ＰｏＣ管理サーバ５からＯＫレスポンスを受信し、ユーザ端末Ｂへ転送する（ステップＳ７５）。ユーザ端末Ｂは、ＳＩＰ／ＳＩＭＰＬＥサーバ３からＯＫレスポンスを受信する（ステップＳ７７）。

なお、図１４の処理は、呼出可能な会議メンバ毎に実施される。また、処理は端子Ｉ及びＪを介して図１５の処理に移行する。

図１５を用いて端子Ｉ及びＪ以降の処理について説明する。ＰｏＣ管理サーバ５の会議Ａ管理部５３ａは、ユーザデータ格納部５３３ａに格納されたデータを用いて、話者権を有するユーザのユーザＩＤを含む話者情報のプレゼンス登録要求を生成し、ＳＩＰ／ＳＩＭＰＬＥサーバ３に送信する（ステップＳ７９）。より具体的には、会議Ａ管理部５３ａが所有者であって、プレゼンスＩＤが”ＦｌｏｏｒＵｓｅｒ”であるプレゼンスデータとして話者権を有するユーザのユーザＩＤを登録することを要求する。ＳＩＰ／ＳＩＭＰＬＥサーバ３は、ＰｏＣ管理サーバ５から、話者情報のプレゼンス登録要求を受信する。会議Ａ管理部５３ａのための会議Ａプレゼンス管理部３３ａが起動されていない場合にはこのタイミングにて起動し、会議Ａプレゼンス管理部３３ａのプレゼンスデータ管理部３３１ａは、受信したプレゼンス登録要求に係るプレゼンスＩＤ（”ＦｌｏｏｒＵｓｅｒ”）に対応して話者権を有するユーザのユーザＩＤをプレゼンスデータとしてプレゼンスデータ格納部３３３ａに格納する（ステップＳ８１）。図６に示すように、領域３３６１に話者権を有するユーザのユーザＩＤ”ＵｓｅｒＡ”が登録される。また、会議Ａプレゼンス管理部３３ａは、ＯＫレスポンスをＰｏＣ管理サーバ５に送信する（ステップＳ８３）。ＰｏＣ管理サーバ５の会議Ａ管理部５３ａは、ＳＩＰ／ＳＩＭＰＬＥサーバ３からＯＫレスポンスを受信する（ステップＳ８５）。

さらに、ＰｏＣ管理サーバ５の会議Ａ管理部５３ａは、ユーザデータ格納部５３３ａに格納されたデータを用いて、呼出依頼を行ったユーザを含む会議メンバの情報を含むメンバ情報のプレゼンス登録要求を生成し、ＳＩＰ／ＳＩＭＰＬＥサーバ３に送信する（ステップＳ８７）。より具体的には、会議Ａ管理部５３ａが所有者であって、プレゼンスＩＤが”Ｍｅｍｂｅｒ”であるプレゼンスデータとして、呼出依頼を行ったユーザを含む会議メンバのユーザＩＤを登録することを要求する。ＳＩＰ／ＳＩＭＰＬＥサーバ３の会議Ａプレゼンス管理部３３ａは、ＰｏＣ管理サーバ５からメンバ情報のプレゼンス登録要求を受信し、会議Ａプレゼンス管理部３３ａのプレゼンスデータ管理部３３１ａは、受信したプレゼンス登録要求に係るプレゼンスＩＤ（”Ｍｅｍｂｅｒ”）に対応してプレゼンスデータ（図６の例では”ＵｓｅｒＡ，ＵｓｅｒＢ，ＵｓｅｒＣ”）をプレゼンスデータ格納部３３３ａに格納する（ステップＳ８９）。また、会議Ａプレゼンス管理部３３ａは、ＯＫレスポンスをＰｏＣ管理サーバ５に送信する（ステップＳ９１）。ＰｏＣ管理サーバ５の会議Ａ管理部５３ａは、ＳＩＰ／ＳＩＭＰＬＥサーバ３からＯＫレスポンスを受信する（ステップＳ９３）。

また、ＰｏＣ管理サーバ５の会議Ａ管理部５３ａは、ユーザデータ格納部５３３ａに格納されたデータを用いて、呼出依頼を行ったユーザを含む会議メンバについて代理講読要求を生成し、ＳＩＰ／ＳＩＭＰＬＥサーバ３に送信する（ステップＳ９５）。より具体的には、プレゼンスデータ格納部３３３ａにおける講読者リスト格納領域３３３５及びプレゼンスグループ情報格納領域３３３３におけるグループII「音声会議」の領域３３８内の講読者ＩＤのための領域３３８２に、会議メンバを登録することを要求する。なお、会議メンバではなく呼出依頼を行ったユーザ及び参加応答を行ったユーザを登録するようにＳＩＰ／ＳＩＭＰＬＥサーバ３に要求してもよい。但し、参加応答が行われる毎に、当該参加応答に係るユーザについて代理講読を行う必要がある。会議への参加状況及び話者権保持者等のプレゼンスデータを、参加応答を行ったユーザのみに配信するのか、又は呼出がなされたユーザに配信するのかは、会議の公開ポリシーにかかわることなので、いずれの方式を採用することも可能である。但し、本来、プレゼンスデータの講読については、講読を必要とする各ユーザが要求を行い、プレゼンスデータの所有者の許可を得て講読者として登録するものである。従って、本来ならば、会議に参加する又は呼び出されたユーザの各々がＳＩＰ／ＳＩＭＰＬＥサーバ３にアクセスして、講読登録を要求する必要がある。しかしながら、本実施例では、会議という性格上、会議への参加状況及び話者権保持者等のプレゼンスデータの講読は、参加者（又は呼び出されたユーザ）にとって必要な情報であるという観点と、各ユーザに講読登録を行わせる場合には無線区間におけるデータ通信量が増加して通信帯域が無駄に使用され、会議の進行が遅くなるという観点とから、ＰｏＣ管理サーバ５が代理で講読登録を行うこととしている。なお、会議Ａプレゼンス管理部３３ａのプレゼンスデータ格納部３３３ａの所有者は会議Ａ管理部５３ａであり、所有者が代理で講読登録することは権限上大きな問題はない。

また、本実施例では、プレゼンスデータ格納部３３３ａにおけるプレゼンスグループ情報格納領域３３３３におけるグループIII「コンテンツ」の領域３３９内の講読者ＩＤのための領域３３９２に、会議メンバ又は参加応答を行ったユーザを登録することをＳＩＰ／ＳＩＭＰＬＥサーバ３に要求する。このようにすれば、以下の処理にてコンテンツを会議メンバ又は参加応答を行ったユーザにコンテンツ配信を行うことができる。なお、このような処理を行わず、コンテンツ配信への呼び込みを別途行うようにしても良い。

ＳＩＰ／ＳＩＭＰＬＥサーバ３の会議Ａプレゼンス管理部３３ａは、ＰｏＣ管理サーバ５から呼出依頼を行ったユーザを含む会議メンバについて代理講読要求を受信し、プレゼンスデータ管理部３３１ａは、プレゼンスデータ格納部３３３ａの講読者リスト格納領域３３３５に会議メンバ（又は参加者）を登録し、さらにプレゼンスグループ情報格納領域３３３３におけるグループII「音声会議」の領域３３８内の講読者ＩＤのための領域３３８２に会議メンバ（又は参加者）を登録する（ステップＳ９７）。上でも述べたように、プレゼンスデータ管理部３３１ａは、プレゼンスグループ情報格納領域３３３３におけるグループIII「コンテンツ」の領域３３９内の講読者ＩＤのための領域３３９２に会議メンバ（又は参加者）を登録する。また、会議Ａプレゼンス管理部３３ａは、ＯＫレスポンスをＰｏＣ管理サーバ５に送信する（ステップＳ９９）。ＰｏＣ管理サーバ５の会議Ａ管理部５３ａは、ＳＩＰ／ＳＩＭＰＬＥサーバ３からＯＫレスポンスを受信する（ステップＳ１０１）。処理は端子Ｋ及びＬを介して図１６及び図１７の処理に移行する。

このように会議メンバ（又は参加者）が講読者リスト格納領域３３３５及びプレゼンスグループ情報格納領域３３３３におけるグループII「音声会議」の領域３３８内の講読者ＩＤのための領域３３８２に登録されると、グループII「音声会議」の領域３３８内のプレゼンスＩＤのための領域３３８１に登録されたプレゼンスＩＤのプレゼンスデータが、配信処理部３３５ａにより会議メンバ（又は参加者）に配信されるようになる。なお、プレゼンスグループ情報格納領域３３３３におけるグループIII「コンテンツ」の領域３３９内のプレゼンスＩＤのための領域３３９１に登録されたプレゼンスＩＤのプレゼンスデータが、配信処理部３３５ａにより会議メンバ（又は参加者）に配信されるようになるが、この段階ではまだプレゼンスデータ自体が登録されていないので配信は行われない。

次に図１６を用いて端子Ｋ以降の処理について説明する。ＳＩＰ／ＳＩＭＰＬＥサーバ３における会議Ａプレゼンス管理部３３ａの配信処理部３３５ａは、プレゼンスデータ格納部３３３ａの状態に応じて会議のプレゼンスデータ（話者権保持者のユーザＩＤ、会議メンバのユーザＩＤ及び参加者のユーザＩＤ）の通知処理を実施する（ステップＳ１０３）。ここではユーザ端末Ａ及びユーザ端末Ｂに会議のプレゼンスデータを送信する。ユーザ端末Ｂのプレゼンスデータ処理部９１５は、ＳＩＰ／ＳＩＭＰＬＥサーバ３から会議のプレゼンスデータを受信して、表示装置に表示する（ステップＳ１０５）。同じように、ユーザ端末Ａのプレゼンスデータ処理部９１５は、ＳＩＰ／ＳＩＭＰＬＥサーバ３から会議のプレゼンスデータを受信して、表示装置に表示する（ステップＳ１０７）。

この段階では、まだ参加者はプレゼンスデータ格納部３３３ａに登録されていないので、会議メンバ及び話者権保持者のみが把握可能な表示が行われる。そして、ユーザ端末Ｂのプレゼンスデータ処理部９１５は、ＳＩＰ／ＳＩＭＰＬＥサーバ３にＯＫレスポンスを返信し（ステップＳ１０９）、ユーザ端末Ａのプレゼンスデータ処理部９１５も、ＳＩＰ／ＳＩＭＰＬＥサーバ３にＯＫレスポンスを返信する（ステップＳ１１１）。ＳＩＰ／ＳＩＭＰＬＥサーバ３の会議Ａプレゼンス管理部３３ａは、ＯＫレスポンスをユーザ端末Ａ及びユーザ端末Ｂから受信する（ステップＳ１１３）。処理は、端子Ｍを介して図１７の処理に移行する。

次に図１７を用いて端子Ｌ及びＭ以降の処理について説明する。ＰｏＣ管理サーバ５の会議Ａ管理部５３ａは、ユーザデータ格納部５３３ａに格納されたデータを用いて、この段階までに確定している参加者（参加応答を行ったユーザだけではなく呼出依頼を行ったユーザを含む）のプレゼンス登録要求を生成し、ＳＩＰ／ＳＩＭＰＬＥサーバ３に送信する（ステップＳ１１５）。より具体的には、会議Ａ管理部５３ａが所有者であって、プレゼンスＩＤが”ＪｏｉｎＵｓｅｒ”であるプレゼンスデータとして、参加者のユーザＩＤを登録することを要求する。ＳＩＰ／ＳＩＭＰＬＥサーバ３の会議Ａプレゼンス管理部３３ａは、ＰｏＣ管理サーバ５から参加者のプレゼンス登録要求を受信し、会議Ａプレゼンス管理部３３ａのプレゼンスデータ管理部３３１ａは、受信したプレゼンス登録要求に係るプレゼンスＩＤ（”ＪｏｉｎＵｓｅｒ”）及びプレゼンスデータ（図６の例では”ＵｓｅｒＡ，ＵｓｅｒＢ”）をプレゼンスデータ格納部３３３ａに格納する（ステップＳ１１７）。なお、ステップＳ９７における処理の代わりに、プレゼンスデータ管理部３３１ａが、プレゼンスグループ情報格納領域３３３３におけるグループIII「コンテンツ」の領域３３９内の講読者ＩＤのための領域３３９２に参加メンバを登録するようにしてもよい。また、会議Ａプレゼンス管理部３３ａは、ＯＫレスポンスをＰｏＣ管理サーバ５に送信する（ステップＳ１１９）。ＰｏＣ管理サーバ５の会議Ａ管理部５３ａは、ＳＩＰ／ＳＩＭＰＬＥサーバ３からＯＫレスポンスを受信する（ステップＳ１２１）。

そして、ＳＩＰ／ＳＩＭＰＬＥサーバ３における会議Ａプレゼンス管理部３３ａの配信処理部３３５ａは、プレゼンスデータ格納部３３３ａの状態に応じて会議のプレゼンスデータ（話者権保持者のユーザＩＤ、会議メンバのユーザＩＤ及び参加者のユーザＩＤ）の通知処理を実施する（ステップＳ１２３）。ここではユーザ端末Ａ及びユーザ端末Ｂに会議のプレゼンスデータを送信する。ユーザ端末Ｂのプレゼンスデータ処理部９１５は、ＳＩＰ／ＳＩＭＰＬＥサーバ３から会議のプレゼンスデータを受信して、表示装置に表示する（ステップＳ１２５）。同じように、ユーザ端末Ａのプレゼンスデータ処理部９１５は、ＳＩＰ／ＳＩＭＰＬＥサーバ３から会議のプレゼンスデータを受信して、表示装置に表示する（ステップＳ１２７）。

この段階では、ステップＳ１１７において参加者がプレゼンスデータ格納部３３３ａに登録されているので、会議メンバ、参加者、話者権保持者、及び呼出を受けて参加していないユーザを把握可能な表示がなされる。そして、ユーザ端末Ｂのプレゼンスデータ処理部９１５は、ＳＩＰ／ＳＩＭＰＬＥサーバ３にＯＫレスポンスを返信し（ステップＳ１２９）、ユーザ端末Ａのプレゼンスデータ処理部９１５も、ＳＩＰ／ＳＩＭＰＬＥサーバ３にＯＫレスポンスを返信する（ステップＳ１３１）。ＳＩＰ／ＳＩＭＰＬＥサーバ３の会議Ａプレゼンス管理部３３ａは、ＯＫレスポンスをユーザ端末Ａ及びユーザ端末Ｂから受信する（ステップＳ１３３）。処理は端子Ｎを介して図１８の処理に移行する。また、端子Ｐを介して図１９の処理に移行する。

ステップＳ９７において会議メンバが講読登録されている場合においては、参加者が新たに現れる毎に、ステップＳ１１５乃至Ｓ１３３が実行される。ステップＳ９７において参加者が講読登録されている場合においては、参加者が新たに現れる毎に、ステップＳ１１５乃至Ｓ１３３が実行されて、既に参加者として講読登録されているユーザにプレゼンスデータが配信され、さらにステップＳ９５乃至Ｓ１１３が実行されて新たな参加者にプレゼンスデータが配信される。

図１７に示した処理が完了した時点において、電子会議の各参加者は、他の参加者を認識でき、会議を開始することができるようになる。なお、話者権については呼出依頼を行ったユーザが保持しているので、このユーザのみが発言することができる。

すなわち図１８に示すような処理が実施される。ユーザＡが話者権保持者であるから、ユーザＡはユーザ端末Ａに対して発話する。ユーザ端末Ａは、ユーザＡからの音声入力をマイクで受け付け、音声会議処理部９１１は、マイクドライバ９３が生成した音声データから音声パケットを生成して、ＰｏＣ−ＭＣＵサーバ７に送信する（ステップＳ１３５）。この際、会議情報として受信した、ＰｏＣ−ＭＣＵサーバ７のＩＰアドレス及びポート番号を用いる。すなわち直接ＰｏＣ−ＭＣＵサーバ７に音声パケットを送信する。

ＰｏＣ−ＭＣＵサーバ７の会議Ａ音声通信管理部７１ａは、ユーザ端末Ａから音声パケットを受信し、話者及び参加者データ格納部７１１ａに格納されている参加者ＩＰアドレス宛に、音声パケットのコピーを転送する（ステップＳ１３７）。ユーザ端末Ｂにおけるクライアントアプリケーション９１の音声会議処理部９１１は、ＰｏＣ−ＭＣＵサーバ７から音声パケットを受信し、図示しないスピーカドライバ及びスピーカを介して音声パケットに係る音声を出力する（ステップＳ１３９）。このようにして、音声ベースの電子会議が行われる。なお、話者権の移動については本実施例の主要部ではないので、ここでは説明しない。

次に図１９を用いて端子Ｐ以降の処理を説明する。ＰｏＣ管理サーバ５の会議Ａ管理部５３ａは、ユーザデータ格納部５３３ａに格納されたデータを用いて、参加者（呼出依頼を行ったユーザを含む）毎に、参加者のプレゼンスデータを”ＢＵＳＹ”（又は音声会議中等）に変更するようにプレゼンスデータの更新登録要求を生成し、ＳＩＰ／ＳＩＭＰＬＥサーバ３に送信する（ステップＳ１４１）。より具体的には、参加者がユーザＡ及びユーザＢであるとすると、ユーザＡプレゼンス管理部３１ａのプレゼンスデータ格納部３１３ａにおけるプレゼンス情報格納領域３１３１内の領域３１６（プレゼンスＩＤは”Ｓｔａｔｅ”）に格納されたデータを”ＢＵＳＹ”などに変更するためのプレゼンスデータ更新登録要求、及びユーザＢプレゼンス管理部３１ｂのプレゼンスデータ格納部３１３ｂにおけるプレゼンス情報格納領域３１３１内の領域３１６に格納されたデータを”ＢＵＳＹ”などに変更するためのプレゼンスデータ更新登録要求を生成し、ＳＩＰ／ＳＩＭＰＬＥサーバ３に送信する。

本来であれば、ユーザＡプレゼンス管理部３１ａにおけるプレゼンスデータ格納部３１３ａ内のデータは、ユーザＡにしか変更できない。同じようにユーザＢプレゼンス管理部３１ｂにおけるプレゼンスデータ格納部３１３ｂ内のデータは、ユーザＢにしか変更できない。しかし、本実施例においては、音声会議をスムーズに進め、無線区間における通信量を減らすために、特別にＰｏＣ管理サーバ５に変更を認めるものである。上でも述べたように、ＰｏＣ管理サーバ５にＳＩＰ／ＳＩＭＰＬＥサーバ３におけるプレゼンスデータについてスーパーバイザ権限を与えておけばよい。

ＳＩＰ／ＳＩＭＰＬＥサーバ３のユーザＡプレゼンス管理部３１ａ（及びユーザＢプレゼンス管理部３１ｂ。但し以下重複するので説明を省略する。）は、ＰｏＣ管理サーバ５から参加者のプレゼンスデータの更新登録要求を受信し、ユーザＡプレゼンス管理部３１ａのプレゼンスデータ管理部３１１ａは、プレゼンスＩＤ”Ｓｔａｔｅ”に対応して”ＢＵＳＹ”等のプレゼンスデータをプレゼンスデータ格納部３１３ａに格納する（ステップＳ１４３）。ＳＩＰ／ＳＩＭＰＬＥサーバ３のユーザＡプレゼンス管理部３１ａは、ＯＫレスポンスをＰｏＣ管理サーバ５に送信する（ステップＳ１４５）。ＰｏＣ管理サーバ５の会議Ａ管理部５３ａは、ＳＩＰ／ＳＩＭＰＬＥサーバ３からＯＫレスポンスを受信する（ステップＳ１４７）。

このようなユーザＡ及びユーザＢのプレゼンスデータの更新が行われれば、プレゼンスＩＤ”Ｓｔａｔｅ”の講読者として登録されたユーザには、ユーザＡ又はユーザＢのプレゼンスデータが通知される。すなわち、ＳＩＰ／ＳＩＭＰＬＥサーバ３におけるユーザＡプレゼンス管理部３１ａの配信処理部３１５ａは、プレゼンスデータ格納部３１３ａの状態に応じてユーザＡのプレゼンスデータの通知処理を実施する（ステップＳ１４９）。図５の例では、ユーザＢ及びユーザＣに送信される。なお、ユーザＢプレゼンス管理部３１ｂについても同様の処理が実施される。但し、ユーザＢのプレゼンスデータについてはユーザＡ及びユーザＣに送信されるものとする。

そうすると、ユーザ端末Ｂのプレゼンスデータ処理部９１５は、ＳＩＰ／ＳＩＭＰＬＥサーバ３からユーザＡのプレゼンスデータを受信して、表示装置に表示する（ステップＳ１５１）。同じように、ユーザ端末Ａのプレゼンスデータ処理部９１５は、ＳＩＰ／ＳＩＭＰＬＥサーバ３からユーザＢのプレゼンスデータを受信して、表示装置に表示する（ステップＳ１５３）。他のユーザ端末でも、同じように表示が変更される。これによって、音声ベースの電子会議の参加者の状態を講読している他のユーザは、参加者がＢＵＳＹで連絡が取れないことを認識することができる。

そして、ユーザ端末Ｂのプレゼンスデータ処理部９１５は、ＳＩＰ／ＳＩＭＰＬＥサーバ３にＯＫレスポンスを返信し（ステップＳ１５５）、ユーザ端末Ａのプレゼンスデータ処理部９１５も、ＳＩＰ／ＳＩＭＰＬＥサーバ３にＯＫレスポンスを返信する（ステップＳ１５７）。ＳＩＰ／ＳＩＭＰＬＥサーバ３のユーザＡプレゼンス管理部３１ａ及びユーザＢプレゼンス管理部３１ｂは、ＯＫレスポンスをユーザ端末Ａ及びユーザ端末Ｂから受信する（ステップＳ１５９）。

このような処理を行うことによって、コンテンツ配信の前処理が完了する。

次に、図２０乃至図２３を用いて、第１の実施例に係るコンテンツ配信処理を行う場合の処理について説明する。まず、ユーザ端末Ａのユーザが、ユーザ端末Ａを操作してコンテンツ送信権の取得を指示する。ユーザ端末Ａのクライアントアプリケーション９１におけるプレゼンスデータ処理部９１５は、ユーザからコンテンツ送信権の取得指示を受け付け（ステップＳ１６１）、コンテンツ送信権の取得要求をＳＩＰ／ＳＩＭＰＬＥサーバ３に送信する（ステップＳ１６３）。ＳＩＰ／ＳＩＭＰＬＥサーバ３のルーティング処理部３５は、コンテンツ送信権の取得要求をユーザ端末Ａから受信し、コンテンツ送信権の取得要求であると判断すると、ＰｏＣ管理サーバ５に転送する（ステップＳ１６５）。ＰｏＣ管理サーバ５は、ＳＩＰ／ＳＩＭＰＬＥサーバ３からコンテンツ送信権の取得要求を受信すると（ステップＳ１６７）、ＡＣＫをＳＩＰ／ＳＩＭＰＬＥサーバ３に返信する（ステップＳ１６９）。ＳＩＰ／ＳＩＭＰＬＥサーバ３のルーティング処理部３５は、ＡＣＫを受信すると、ユーザ端末Ａに転送する（ステップＳ１７１）。ユーザ端末Ａのクライアントアプリケーション９１におけるプレゼンスデータ処理部９１５は、ＳＩＰ／ＳＩＭＰＬＥサーバ３からＡＣＫを受信する（ステップＳ１７３）。

また、ＰｏＣ管理サーバ５の会議Ａ管理部５３ａは、ユーザデータ格納部５３３ａに格納されたコンテンツ送信権の設定状況を確認の上、コンテンツ送信権を有しているユーザがいないならば、コンテンツ送信権の取得要求の送信元のユーザＩＤを有する、コンテンツ送信権設定のためのプレゼンス登録要求を生成し、ＳＩＰ／ＳＩＭＰＬＥサーバ３に送信する（ステップＳ１７５）。ＳＩＰ／ＳＩＭＰＬＥサーバ３の会議Ａプレゼンス管理部３３ａは、ＰｏＣ管理サーバ５から、コンテンツ送信権の取得要求の送信元のユーザＩＤを有する、コンテンツ送信権設定のためのプレゼンス登録要求を受信し、プレゼンスデータ格納部３３３ａに登録する（ステップＳ１７７）。具体的には、プレゼンスデータ格納部３３３ａにおいて、プレゼンスＩＤが”ＳｅｎｄｉｎｇＵｓｅｒ”であるプレゼンスデータ（図１０）に、コンテンツ送信権の取得要求の送信元のユーザＩＤ”ＵｓｅｒＡ”を登録する。

そして、会議Ａプレゼンス管理部３３ａは、登録完了通知をＰｏＣ管理サーバ５に返信する（ステップＳ１７９）。ＰｏＣ管理サーバ５の会議Ａ管理部５３ａは、ＳＩＰ／ＳＩＭＰＬＥサーバ３から登録完了通知を受信する（ステップＳ１８１）。

また、ＳＩＰ／ＳＩＭＰＬＥサーバ３の会議Ａプレゼンス管理部３３ａにおける配信処理部３３５ａは、プレゼンスデータ格納部３３３ａの状態に応じて、ユーザＡに対するコンテンツ送信権設定を表すプレゼンスデータ（コンテンツ送信権を有するユーザのユーザＩＤ）の通知処理を実施する（ステップＳ１８３）。ここではユーザ端末Ｂに、プレゼンスデータ格納部３３３ａに格納されている、プレゼンスＩＤが”ＳｅｎｄｉｎｇＵｓｅｒ”であるプレゼンスデータを送信する。ユーザ端末Ｂのプレゼンスデータ処理部９１５は、ＳＩＰ／ＳＩＭＰＬＥサーバ３から、コンテンツ送信権設定を表すプレゼンスデータを受信して、表示装置に表示する（ステップＳ１８５）。

ユーザ端末Ｂのプレゼンスデータ処理部９１５は、ＳＩＰ／ＳＩＭＰＬＥサーバ３にＯＫレスポンスを返信する（ステップＳ１８７）。ＳＩＰ／ＳＩＭＰＬＥサーバ３の会議Ａプレゼンス管理部３３ａは、ユーザ端末ＢからＯＫレスポンスを受信する（ステップＳ１８９）。なお、ユーザ端末Ａにも通知を行うようにしても良い。

一方、ユーザ端末Ａのユーザは、コンテンツデータの配信元ＵＲＩを指定する。これに応じて、ユーザ端末Ａのクライアントアプリケーション９１におけるコンテンツ処理部９１３は、ユーザからコンテンツデータの配信元ＵＲＩの指定入力を受け付ける（ステップＳ１９１）。処理は端子Ｑ，Ｒ及びＳを介して図２１の処理に移行する。

図２１の処理の説明に移行して、ユーザ端末Ａのコンテンツ処理部９１３は、入力されたＵＲＩをＳＩＰ／ＳＩＭＰＬＥサーバ３に送信する（ステップＳ１９３）。ＳＩＰ／ＳＩＭＰＬＥサーバ３のルーティング処理部３５は、ＵＲＩをユーザ端末Ａから受信し、ＰｏＣ管理サーバ５に転送する（ステップＳ１９５）。ＰｏＣ管理サーバ５の会議Ａ管理部５３ａは、ＳＩＰ／ＳＩＭＰＬＥサーバ３からＵＲＩを受信すると（ステップＳ１９７）、ＯＫレスポンスをＳＩＰ／ＳＩＭＰＬＥサーバ３に返信する（ステップＳ１９９）。ＳＩＰ／ＳＩＭＰＬＥサーバ３は、ＯＫレスポンスを受信し、ユーザ端末Ａに転送する（ステップＳ２０１）。ユーザ端末Ａのクライアントアプリケーション９１におけるコンテンツ処理部９１３は、ＳＩＰ／ＳＩＭＰＬＥサーバ３からＯＫレスポンスを受信する（ステップＳ２０３）。

また、ＰｏＣ管理サーバ５の会議Ａ管理部５３ａは、ユーザデータ格納部５３３ａに格納されているコンテンツ送信権の設定状況を確認して、ＵＲＩの送信元がコンテンツ送信権を有していることが確認できれば、ステップＳ１９７で受信したＵＲＩを含むプレゼンス登録要求を生成し、ＳＩＰ／ＳＩＭＰＬＥサーバ３に送信する（ステップＳ２０５）。コンテンツ送信権を有していないユーザからのＵＲＩの指定であれば、当該ＵＲＩを破棄する。ＳＩＰ／ＳＩＭＰＬＥサーバ３の会議Ａプレゼンス管理部３３ａは、ＰｏＣ管理サーバ５からＵＲＩを含むプレゼンス登録要求を受信し、プレゼンスデータ格納部３３３ａに登録する（ステップＳ２０７）。具体的には、プレゼンスデータ格納部３３３ａにおいて、プレゼンスＩＤが”ＳｅｎｄｉｎｇＵｓｅｒ”であるプレゼンスデータ（図１０）にＵＲＩを格納する。会議Ａプレゼンス管理部３３ａは、登録完了通知をＰｏＣ管理サーバ５に返信する（ステップＳ２０９）。ＰｏＣ管理サーバ５の会議Ａ管理部５３ａは、登録完了通知を受信する（ステップＳ２１１）。ＵＲＩはプレゼンスデータとして通知はしない。

そして、会議Ａ管理部５３ａは、コンテンツデータ取得部５５にＵＲＩを出力してコンテンツの取得を要求する。これに応じて、コンテンツデータ取得部５５は、コンテンツ送信権を有するユーザから指定されたＵＲＩに従ってコンテンツデータ要求を送信する（ステップＳ２１３）。例えば、コンテンツ送信権を有するユーザのユーザＩＤをコンテンツデータ要求に含めるようにしても良い。ＵＲＩに対応するコンテンツサーバ９は、ＰｏＣ管理サーバ５からのコンテンツデータ要求を受信し（ステップＳ２１５）、コンテンツデータ格納部９１から要求に係るコンテンツデータを読み出し、コンテンツデータを要求元のＰｏＣ管理サーバ５に送信する（ステップＳ２１７）。コンテンツデータ要求に、コンテンツ送信権を有するユーザのユーザＩＤが含まれる場合には、当該ユーザＩＤを確認するようにしても良い。ＰｏＣ管理サーバ５のコンテンツデータ取得部５５は、コンテンツサーバ９からコンテンツデータを受信し、要求元の会議Ａ管理部５３ａにおけるコンテンツデータ格納部５３５ａに格納する（ステップＳ２１９）。

このようにコンテンツデータ取得部５５によって、ＵＲＩが指定され且つ会議メンバ又は参加者に配信すべきコンテンツをコンテンツサーバ９から取得するようにすれば、例えばＵＲＩに対するアクセス権がないユーザに対しても当該コンテンツを配信することができるようになる。上でも述べたが、ＰｏＣ管理サーバ５とコンテンツサーバ９とが同一の運営者などに管理されていれば、コンテンツサーバ９においてＰｏＣ管理サーバ５からの要求に対して認証などを実施せずとも問題ない。なお、使用権だけを確認するようであれば、上で述べたようなコンテンツ送信権を有するユーザのユーザＩＤを確認するようにすればよい。

以降は、第１の例であれば端子Ｕを介して図２２の処理に移行し、第２の例であれば端子Ｕ及びＴを介して図２３の処理に移行する。

最初に第１の例を説明する。会議Ａ管理部５３ａは、コンテンツデータ格納部５３５ａにコンテンツデータが格納されると、ユーザデータ格納部５３３ａに格納されている会議Ａの参加者（ここではコンテンツ送信権無しの参加ユーザ。ここではユーザＢ。）のＩＰアドレス等を読み出し、コンテンツデータ格納部５３５ａに格納されたコンテンツデータをユーザ端末Ｂに送信する（図２２：ステップＳ２２１）。ユーザ端末Ｂのコンテンツ処理部９１３は、コンテンツデータをＰｏＣ管理サーバ５から受信し、表示装置に表示する（ステップＳ２２３）。ユーザ端末Ｂのクライアントアプリケーション９１におけるコンテンツ処理部９１３は、ＯＫレスポンスをＰｏＣ管理サーバ５に返信する（ステップＳ２２５）。ＰｏＣ管理サーバ５の会議Ａ管理部５３ａは、ユーザ端末ＢからＯＫレスポンスを受信する（ステップＳ２２７）。

このような処理を実施すれば、ＵＲＩではなくコンテンツデータそのものを会議メンバ又は参加者で共有することができ、会議がスムーズに進行することとなる。

次に第２の例を説明する。ＰｏＣ管理サーバ５の会議Ａ管理部５３ａは、コンテンツデータ格納部５３５ａに格納されたコンテンツデータを、指定されたＵＲＩに対応するプレゼンスデータとしてＳＩＰ／ＳＩＭＰＬＥサーバ３に送信する（ステップＳ２３１）。ＳＩＰ／ＳＩＭＰＬＥサーバ３の会議Ａプレゼンス管理部３３ａは、ＰｏＣ管理サーバ５からＵＲＩに対応するコンテンツデータを受信すると（ステップＳ２３３）、プレゼンスデータの更新とみなしてコンテンツデータをプレゼンスデータとして通知する処理を実施する（ステップＳ２３５）。ここではコンテンツ送信権を有するユーザＡのユーザ端末Ａには送信せず、その他の参加ユーザ（ここではユーザＢ）に送信するものとする。ユーザ端末Ｂのクライアントアプリケーション９１におけるプレゼンスデータ処理部９１５は、コンテンツデータをＳＩＰ／ＳＩＭＰＬＥサーバ３から受信し、コンテンツ処理部９１３に出力する。コンテンツ処理部９１３は、受信したコンテンツデータを表示装置に表示する（ステップＳ２３７）。また、ユーザ端末Ｂのクライアントアプリケーション９１におけるプレゼンスデータ処理部９１５は、ＰｏＣ管理サーバ５にＯＫレスポンスを返信する（ステップＳ２３９）。また、ＳＩＰ／ＳＩＭＰＬＥサーバ３の会議Ａプレゼンス管理部３３ａは、ＯＫレスポンスを受信する（ステップＳ２４１）。

このような処理を実施することによってコンテンツデータが会議メンバ又は参加者に自動的に配信され、ＵＲＩを配信するよりユーザの手間が減ぜられる。

なお、上で述べた例では、ＵＲＩで指定されたコンテンツデータが、ユーザ端末Ａ以外の会議メンバ又参加ユーザのユーザ端末において使用可能か否かは分からない。上で述べたように、各参加ユーザのユーザ端末のメディア情報についてはＰｏＣ管理サーバ５側でも取得して、例えばユーザデータ格納部５３３ａに図２４に示すようなデータを保持している。具体的には、会議に参加しているユーザのユーザＩＤ毎に、ＩＰアドレス、話者権の有無、コンテンツ送信権の有無、許容ファイル形式（ＧＩＦ，ＪＰＥＧ，ＴＩＦＦ，ＭＰＥＧなどのファイル形式）が格納されている。取扱可能なファイルサイズ等に関するデータを保持することもある。このようなデータを用いて、会議Ａ管理部５３ａは、コンテンツデータ格納部５３３ａに格納されたデータが、参加ユーザのユーザ端末が使用できるか判断する。例えば受信したコンテンツの形式がＴＩＦＦであって図２４に示すようなデータを保持している場合には、ユーザ端末Ａ（ＵｓｅｒＡ）は使用可能であるが、ユーザ端末Ｂ及びユーザ端末Ｃについては使用不可と判断される場合がある。もし使用不可と判断されるようなユーザ端末については、当該コンテンツデータを送信しないようにする。具体的には、上で述べた第１の例のようにＰｏＣ管理サーバ５からコンテンツデータを送信するようにして、使用不可と判断されたユーザ端末には送信しない。このようにすれば、不要な通信を行わずに済む。無線区間の帯域を無駄に消費することもない。

さらに、図１に示したコンテンツ変換部５６を利用して、（１）全てのユーザ端末が使用可能な形式（例えば図２４の例ではＧＩＦ）でなければ、当該全てのユーザ端末が使用可能な形式に変換して、上で述べた第１の例及び第２の例に従ってコンテンツを配信する。又は、（２）ユーザ端末毎に、受信したコンテンツの使用可否を判断し、使用不可能であれば使用可能な形式に変換して、上で述べた第１の例に従って送信する。

このようにすれば、ユーザ端末側に併せてコンテンツデータを配信できるため、スムーズな会議の進行が可能となる。

なお、上では述べていないが、コンテンツ送信権の破棄又は移転は、通常の話者権と同様に処理する。但し、ＵＲＩについてもコンテンツ送信権の破棄又は移転に応じて、新たに指定されたＵＲＩに変更する必要がある。

２．第２の実施例
本来、サーバはできるだけ負荷を軽くしておく必要があるが、第１の実施例では、ＰｏＣ管理サーバ５は、コンテンツ取得部５５及びコンテンツ変換部５６を含むので、処理負荷が高くなってしまう可能性がある。従って、例えば図２５のようなシステム構成を採用する。

図２５と図１の差は、ＰｏＣ管理サーバ５の構成である。コンテンツ取得部５５の代わりに、１又は複数のコンテンツ取得仮想クライアント５９（図２５ではコンテンツ取得仮想クライアント５９ａ及び５９ｂ）が設けられている。このコンテンツ取得仮想クライアント５９は、コンテンツをコンテンツサーバ９から代理で取得し、ユーザ端末とは別の特殊な仮想的なクライアントとして機能するプログラムである。図２５ではＰｏＣ管理サーバ５内で、会議管理部５３などとは別スレッドで起動・動作させるようにしているが、例えばコンテンツ取得仮想クライアント５９用のサーバを別に用意しても良い。このような構成を採用することによって、よりＰｏＣ管理サーバ５の負荷を低下させることができる。

コンテンツ取得仮想クライアント５９は、例えば、コンテンツサーバ９が複数存在する場合には、当該コンテンツサーバ９毎に用意することもある。また、コンテンツ送信権を有するユーザが、使用するコンテンツ取得仮想クライアント５９を特定するようにしても良い。また、ユーザ自身が意図することなく例えばユーザ端末のクライアントアプリケーション９１におけるコンテンツ処理部９１３がＵＲＩに応じて自動的に設定するか、例えばユーザでも理解できるような選択肢（ユーザＩＤ及びパスワードを必要とするコンテンツサーバ９のためのコンテンツ取得仮想クライアント５９、又は認証が不要なコンテンツ取得仮想クライアント５９）を提示して間接的に指定させるようにしても良い。

また、図２５に示したようなシステム構成の場合には、会議Ａプレゼンス管理部３３ａのプレゼンスデータ格納部３３３ａには、図２６に示すようなデータが格納される。図６との差は、プレゼンス情報格納領域３３３１において、プレゼンスＩＤが”ＦｅｔｃｈＲｅｑｕｅｓｔｉｎｇＵｓｅｒ”であるプレゼンスデータを格納するための領域３３６５が追加されている部分である。この領域３３６５には、コンテンツ取得仮想クライアント５９のＩＤであるＣｏｎｔｅｎｔＨａｎｄｌｅｒＡと、コンテンツ送信権を有するユーザによって指定されたＵＲＩとが格納される。

また、プレゼンスグループ情報領域３３３３内のグループIII「コンテンツ」の領域３４０には、プレゼンスＩＤとして”ＳｅｎｄｉｎｇＵｓｅｒ”に加えて”ＦｅｔｃｈＲｅｑｕｅｓｔｉｎｇＵｓｅｒ”が追加されている。但し、プレゼンスＩＤが”ＦｅｔｃｈＲｅｑｕｅｓｔｉｎｇＵｓｅｒ”であるプレゼンスデータについては配信せずとも良い。

上で述べた領域３３６５に格納されるプレゼンスデータは、例えば図２７に示すようなタグデータ構造のデータを格納する。図２７の例では、このプレゼンスデータの所有者が、Ｃｏｎｆｅｒｅｎｃｅ０１＠ｐｏｃ．ｆｊ．ｃｏｍというＳＩＰ−ＵＲＬで特定されており、＜ｎｏｔｅ＞及び＜／ｎｏｔｅ＞タグの間において、＜ｃｏｎｔｅｎｔｆｅｔｃｈｅｒ＞及び＜／ｃｏｎｔｅｎｔｆｅｔｃｈｅｒ＞との間にコンテンツ取得仮想クライアント５９のＩＤ（ここではＣｏｎｔｅｎｔＨａｎｄｌｅｒＡ＠ｐｏｃ．ｆｊ．ｃｏｍ）と、＜ｃｏｎｔｅｎｔ＞及び＜／ｃｏｎｔｅｎｔ＞の間にコンテンツ送信権を有するユーザが指定したＵＲＩ（ここではhttp://photo.fj.com/aa/bb/img.jpg）とが登録される。

次に、図２８乃至図３１を用いて本実施例の処理フローを説明する。まず、ユーザは、ユーザ端末Ａを操作して、コンテンツ送信権の取得要求を入力すると共に、コンテンツの配信元であるＵＲＩの指定、及び必要なＩＤ及びパスワード並びにコンテンツ取得仮想クライアント５９のＩＤ等を含む付随データの入力を行う。なお、ＩＤ及びパスワードの入力は、コンテンツサーバ９が要求する場合に必要となり、不要であればＩＤ及びパスワードの入力は不要である。また、上で述べたようにユーザ自身が陽にコンテンツ取得仮想クライアント５９のＩＤを入力する場合もあれば、ＵＲＩ等の指定によって自動的に特定される場合もある。ユーザ端末Ａのコンテンツ処理部９１３は、ユーザから、コンテンツ送信権の取得要求の入力、コンテンツ配信元であるＵＲＩの指定、及び必要なＩＤ及びパスワード並びにコンテンツ取得仮想クライアント５９のＩＤ等を含む付随データの入力を受け付け（ステップＳ３０１）、ＵＲＩ及び付随データを含むコンテンツ送信権取得要求を生成し、ＳＩＰ／ＳＩＭＰＬＥサーバ３に送信する（ステップＳ３０３）。

ＳＩＰ／ＳＩＭＰＬＥサーバ３のルーティング処理部３５は、ＵＲＩ及び付随データを含むコンテンツ送信権取得要求をユーザ端末Ａから受信してコンテンツ送信権取得要求であることを認識すると、ＰｏＣ管理サーバ５に転送する（ステップＳ３０５）。ＰｏＣ管理サーバ５の会議Ａ管理部５３ａは、ＵＲＩ及び付随データを含むコンテンツ送信権取得要求をＳＩＰ／ＳＩＭＰＬＥサーバ３から受信すると（ステップＳ３０７）、ＡＣＫレスポンスを返信する（ステップＳ３０９）。ＳＩＰ／ＳＩＭＰＬＥサーバ３は、ＰｏＣ管理サーバ５からＡＣＫレスポンスを受信すると、ユーザ端末Ａに転送する（ステップＳ３１１）。ユーザ端末Ａは、ＳＩＰ／ＳＩＭＰＬＥサーバ３からＡＣＫレスポンスを受信する（ステップＳ３１３）。

また、ＰｏＣ管理サーバ５の会議Ａ管理部５３ａは、ユーザデータ格納部５３３ａを参照してコンテンツ送信権の設定状況を確認し、コンテンツ送信権を取得しているユーザが存在しない場合には、コンテンツ送信権の取得要求元のユーザＩＤ（ここではユーザＡのユーザＩＤ）を含み且つコンテンツ送信権の取得要求元に対するコンテンツ送信権設定のためのプレゼンス登録要求を生成し、ＳＩＰ／ＳＩＭＰＬＥサーバ３に送信する（ステップＳ３１５）。ＳＩＰ／ＳＩＭＰＬＥサーバ３の会議Ａプレゼンス管理部３３ａは、ＰｏＣ管理サーバ５から、コンテンツ送信権の取得要求元のユーザＩＤを含み且つコンテンツ送信権の取得要求元に対するコンテンツ送信権設定のためのプレゼンス登録要求を受信すると、プレゼンスデータ格納部３３３ａに登録する（ステップＳ３１７）。具体的には、プレゼンスデータ格納部３３３ａにおいて、プレゼンスＩＤが”ＳｅｎｄｉｎｇＵｓｅｒ”であるプレゼンスデータ（図１０）に、コンテンツ送信権の取得要求の送信元のユーザＩＤ”ＵｓｅｒＡ”を登録する。

そして、会議Ａプレゼンス管理部３３ａは、登録完了通知をＰｏＣ管理サーバ５に返信する（ステップＳ３１９）。ＰｏＣ管理サーバ５の会議Ａ管理部５３ａは、ＳＩＰ／ＳＩＭＰＬＥサーバ３から登録完了通知を受信する（ステップＳ３２１）。

また、ＰｏＣ管理サーバ５の会議Ａ管理部５３ａは、コンテンツ送信権取得要求の付随データに含まれるコンテンツ取得仮想クライアント５９のＩＤ（ここでは”ＣｏｎｔｅｎｔＨａｎｄｌｅｒＡ＠ｐｏｃ．ｆｊ．ｃｏｍ”）を含むコンテンツ取得仮想クライアント設定のためのプレゼンス登録要求を生成し、ＳＩＰ／ＳＩＭＰＬＥサーバ３に送信する（ステップＳ３２３）。ＳＩＰ／ＳＩＭＰＬＥサーバ３の会議Ａプレゼンス管理部３３ａは、ＰｏＣ管理サーバ５から、コンテンツ取得仮想クライアント５９のＩＤを含むコンテンツ取得仮想クライアント設定のためのプレゼンス登録要求を受信すると、プレゼンスデータ格納部３３３ａに登録する（ステップＳ３２５）。具体的には、プレゼンスデータ格納部３３３ａにおいて、プレゼンスＩＤが”ＦｅｔｃｈＲｅｑｕｅｓｔｉｎｇＵｓｅｒ”であるプレゼンスデータ（図２７）に、コンテンツ取得仮想クライアント５９のＩＤ”ＣｏｎｔｅｎｔＨａｎｄｌｅｒＡ＠ｐｏｃ．ｆｊ．ｃｏｍ”を登録する。

なお、ユーザ端末Ａから受信したコンテンツ送信権取得要求の付随データに、コンテンツ取得仮想クライアント５９のＩＤが含まれない場合には、ＰｏＣ管理サーバ５の会議Ａ管理部５３ａが、適切なコンテンツ取得仮想クライアント５９を起動又は選択する場合もある。また、場合によっては、ユーザ端末Ａから受信したコンテンツ送信権取得要求の付随データに含まれるコンテンツ取得仮想クライアント５９が使用不能な場合には、指定がない場合と同様に、ＰｏＣ管理サーバ５の会議Ａ管理部５３ａが、適切なコンテンツ取得仮想クライアント５９を起動又は選択する場合もある。

そして、会議Ａプレゼンス管理部３３ａは、登録完了通知をＰｏＣ管理サーバ５に返信する（ステップＳ３２７）。ＰｏＣ管理サーバ５の会議Ａ管理部５３ａは、ＳＩＰ／ＳＩＭＰＬＥサーバ３から登録完了通知を受信する（ステップＳ３２９）。処理は端子Ｘ及びＹを介して図２９の処理に移行する。

まず、ＳＩＰ／ＳＩＭＰＬＥサーバ３の会議Ａプレゼンス管理部３３ａにおける配信処理部３３５ａは、プレゼンスデータ格納部３３３ａの状態に応じて、コンテンツ送信権を有するユーザのユーザＩＤ（ユーザＡ）に対するコンテンツ送信権設定を表すプレゼンスデータの通知処理を実施する（ステップＳ３３１）。ここではユーザ端末Ｂに、プレゼンスデータ格納部３３３ａに格納されている、プレゼンスＩＤが”ＳｅｎｄｉｎｇＵｓｅｒ”であるプレゼンスデータを送信する。ユーザ端末Ｂのプレゼンスデータ処理部９１５は、ＳＩＰ／ＳＩＭＰＬＥサーバ３から、コンテンツ送信権設定を表すプレゼンスデータを受信して、表示装置に表示する（ステップＳ３３３）。

ユーザ端末Ｂのプレゼンスデータ処理部９１５は、ＳＩＰ／ＳＩＭＰＬＥサーバ３にＯＫレスポンスを返信する（ステップＳ３３５）。ＳＩＰ／ＳＩＭＰＬＥサーバ３の会議Ａプレゼンス管理部３３ａは、ユーザ端末ＢからＯＫレスポンスを受信する（ステップＳ３３７）。

また、ＰｏＣ管理サーバ５の会議Ａ管理部５３ａは、コンテンツ送信権取得要求の付随データに含まれるコンテンツ取得仮想クライアント５９のＩＤに応じて、当該コンテンツ取得仮想クライアント５９に、コンテンツ送信権取得要求に含まれるコンテンツ配信元のＵＲＩ、並びに付随データに含まれるＩＤ及びパスワード（指定があれば）を送信する（ステップＳ３３９）。コンテンツ取得仮想クライアント５９は、ＰｏＣ管理サーバ５の会議Ａ管理部５３ａから配信元ＵＲＩ並びにＩＤ及びパスワード（指定があれば）を受信する（ステップＳ３４１）。また、コンテンツ取得仮想クライアント５９は、ＯＫレスポンスをＰｏＣ管理サーバ５の会議Ａ管理部５３ａに返信する（ステップＳ３４３）。ＰｏＣ管理サーバ５の会議Ａ管理部５３ａは、コンテンツ取得仮想クライアント５９からＯＫレスポンスを受信する（ステップＳ３４５）。

さらに、コンテンツ取得仮想クライアント５９は、配信元ＵＲＩに従ってＩＤ及びパスワード（指定があれば）を含むコンテンツデータ要求をコンテンツサーバ９に送信する（ステップＳ３４７）。コンテンツサーバ９は、コンテンツ取得仮想クライアント５９からＩＤ及びパスワード（指定があれば）を含むコンテンツデータ要求を受信すると（ステップＳ３４９）、ＩＤ及びパスワードを用いて周知の認証処理を実施し、認証が成功すればコンテンツデータ格納部９１から該当するコンテンツデータを読み出し、当該コンテンツデータをコンテンツ取得仮想クライアント５９に送信する（ステップＳ３５１）。なお、認証に失敗した場合、又は認証が必要なのにＩＤ及びパスワードを受信しない場合にはコンテンツデータを送信することはない。コンテンツ取得仮想クライアント５９は、コンテンツサーバ９からコンテンツデータを受信し（ステップＳ３５３）、さらにＰｏＣ管理サーバ５の会議Ａ管理部５３ａに送信する（ステップＳ３５５）。ＰｏＣ管理サーバ５の会議Ａ管理部５３ａは、コンテンツ取得仮想クライアント５９からコンテンツデータを受信すると、コンテンツデータ格納部５３５ａに格納する（ステップＳ３５７）。ＰｏＣ管理サーバ５の会議Ａ管理部５３ａは、ＯＫレスポンスをコンテンツ取得仮想クライアント５９に返信する（ステップＳ３５９）。コンテンツ取得仮想クライアント５９は、ＯＫレスポンスをＰｏＣ管理サーバ５の会議Ａ管理部５３ａから受信する（ステップＳ３６１）。この段階でコンテンツ取得仮想クライアント５９の処理は完了するので、他の要求に応じることができるようになる。また、スレッドを終了させるようにしても良い。処理は端子Ｚを介して図３０又は図３１に移行する。

このような構成を採用すれば、ＰｏＣ管理サーバ５とコンテンツサーバ９とが提携関係にないなど認証が必要な場合においても、ユーザＡの代わりにコンテンツデータを取得して、会議参加ユーザなどに配信することができる。

図３０は、ＰｏＣ管理サーバ５から、取得したコンテンツデータを配信する場合の処理フローを示す。まず、ＰｏＣ管理サーバ５のコンテンツ変換部５６は、コンテンツデータ格納部５３５ａに格納されたコンテンツデータのデータ・フォーマット（形式）を特定する（ステップＳ３６３）。また、コンテンツ変換部５６は、会議Ａ管理部５３ａから会議参加ユーザが使用可能なフォーマット等（例えば図２４）のデータを取得して、受信したコンテンツデータのフォーマットが適合しているか確認し、適合していない場合には変換処理を実施する（ステップＳ３６５）。変換後のデータについてはコンテンツデータ格納部５３５ａに格納する。会議参加ユーザのユーザ端末で共通して使用可能なフォーマットに変換するような処理を行っても良い。また、受信したコンテンツデータを使用不能と判断されたユーザ端末への送信を不可として設定するようにしても良い。また、ステップＳ３６３及びＳ３６５についてはスキップすることも可能である。

そして、会議Ａ管理部５３ａは、ユーザデータ格納部５３３ａに格納されている会議Ａの参加者のＩＰアドレス等を読み出し、コンテンツデータ格納部５３５ａに格納されたユーザ端末Ａが使用可能なコンテンツデータをユーザ端末Ａに送信する（ステップＳ３６７）。ユーザ端末Ａのコンテンツ処理部９１３は、コンテンツデータをＰｏＣ管理サーバ５から受信し、表示装置に表示する（ステップＳ３６９）。ユーザ端末Ａのクライアントアプリケーション９１におけるコンテンツ処理部９１３は、ＯＫレスポンスをＰｏＣ管理サーバ５に返信する（ステップＳ３７１）。ＰｏＣ管理サーバ５の会議Ａ管理部５３ａは、ユーザ端末ＢからＯＫレスポンスを受信する（ステップＳ３７３）。コンテンツ送信権を有するユーザＡのユーザ端末Ａには送信しない場合もある。

また、会議Ａ管理部５３ａは、コンテンツデータ格納部５３５ａに格納されたユーザ端末Ｂが使用可能なコンテンツデータをユーザ端末Ｂに送信する（ステップＳ３６７）。ユーザ端末Ｂのコンテンツ処理部９１３は、コンテンツデータをＰｏＣ管理サーバ５から受信し、表示装置に表示する（ステップＳ３７５）。ユーザ端末Ａのクライアントアプリケーション９１におけるコンテンツ処理部９１３は、ＯＫレスポンスをＰｏＣ管理サーバ５に返信する（ステップＳ３７７）。ＰｏＣ管理サーバ５の会議Ａ管理部５３ａは、ユーザ端末ＢからＯＫレスポンスを受信する（ステップＳ３７９）。

このようにすれば、会議参加者のユーザ端末においてコンテンツを共有して会議をスムーズに進めることができるようになる。

また、コンテンツデータ取得処理についてはコンテンツ取得仮想クライアント５９に処理を分担させているので、負荷分散が可能な構成となっている。

図３０の処理の代わりに図３１のような処理を実施するようにしても良い。図３１ではＳＩＰ／ＳＩＭＰＬＥサーバ３からコンテンツデータを配信する場合を示す。

まず、ＰｏＣ管理サーバ５のコンテンツ変換部５６は、コンテンツデータ格納部５３５ａに格納されたコンテンツデータのデータ・フォーマット（形式）を特定する（ステップＳ３８１）。また、コンテンツ変換部５６は、会議Ａ管理部５３ａから会議参加者が使用可能なフォーマット等（例えば図２４）のデータを取得して、受信したコンテンツデータのフォーマットが会議参加ユーザのユーザ端末で使用可能か判断し、使用可能でない場合には会議参加ユーザ全員が使用可能な共通のフォーマットに変換する（ステップＳ３８３）。但し、全てのユーザ端末が使用可能な共通のフォーマットが存在しない場合もあるので、より多くのユーザ端末で使用可能なフォーマットに変換するようにしても良い。既に会議参加者全員が使用可能なフォーマットとなっていると判断された場合には、変換処理を実施しない。変換後のデータについてはコンテンツデータ格納部５３５ａに格納する。また、受信したコンテンツデータを使用不能と判断されたユーザ端末への送信を不可として設定するようにしても良い。さらに、ステップＳ３８１及びＳ３８３についてはスキップすることも可能である。

そして、会議Ａ管理部５３ａは、コンテンツデータ格納部５３５ａに格納されたコンテンツデータを、ＵＲＩに対応するプレゼンスデータとしてＳＩＰ／ＳＩＭＰＬＥサーバ３に送信する（ステップＳ３８５）。

ＳＩＰ／ＳＩＭＰＬＥサーバ３の会議Ａプレゼンス管理部３３ａは、ＰｏＣ管理サーバ５からＵＲＩに対応するコンテンツデータを受信すると（ステップＳ３８７）、プレゼンスデータの更新とみなしてコンテンツデータをプレゼンスデータとして通知する処理を実施する（ステップＳ３８９）。ユーザ端末Ａのクライアントアプリケーション９１におけるプレゼンスデータ処理部９１５は、コンテンツデータをＳＩＰ／ＳＩＭＰＬＥサーバ３から受信し、コンテンツ処理部９１３に出力する。コンテンツ処理部９１３は、受信したコンテンツデータを表示装置に表示する（ステップＳ３９１）。また、ユーザ端末Ａのクライアントアプリケーション９１におけるプレゼンスデータ処理部９１５は、ＰｏＣ管理サーバ５にＯＫレスポンスを返信する（ステップＳ３９３）。また、ＳＩＰ／ＳＩＭＰＬＥサーバ３の会議Ａプレゼンス管理部３３ａは、ＯＫレスポンスを受信する（ステップＳ３９５）。なお、ユーザ端末Ａには送信しないようにしても良い。

さらに、ＳＩＰ／ＳＩＭＰＬＥサーバ３の会議Ａプレゼンス管理部３３ａは、プレゼンスデータの更新とみなしてコンテンツデータをプレゼンスデータとしてユーザ端末Ａに通知する（ステップＳ３８９）。ユーザ端末Ｂのクライアントアプリケーション９１におけるプレゼンスデータ処理部９１５は、コンテンツデータをＳＩＰ／ＳＩＭＰＬＥサーバ３から受信し、コンテンツ処理部９１３に出力する。コンテンツ処理部９１３は、受信したコンテンツデータを表示装置に表示する（ステップＳ３９６）。また、ユーザ端末Ｂのクライアントアプリケーション９１におけるプレゼンスデータ処理部９１５は、ＰｏＣ管理サーバ５にＯＫレスポンスを返信する（ステップＳ３９７）。また、ＳＩＰ／ＳＩＭＰＬＥサーバ３の会議Ａプレゼンス管理部３３ａは、ＯＫレスポンスを受信する（ステップＳ３９９）。

もしＰｏＣ管理サーバ５のコンテンツ変換部５６で、特定のユーザ端末については使用不可と判断された場合には、当該特定のユーザ端末のユーザＩＤについて送信しないように指示するデータをＰｏＣ管理サーバ５から通知して、ＳＩＰ／ＳＩＭＰＬＥサーバ３の会議Ａプレゼンス管理部３３ａにおいても配信しないようにするようにしても良い。このようにすれば無線区間の帯域を無駄に消費しないようになる。

図３１に示すような処理を実施すれば、プレゼンスデータの通知機構を用いてコンテンツデータを会議参加者に配信することができる。

以上述べたように、本発明の実施の形態を説明したが、本発明はこれに限定されるものではない。例えば、図１及び図２５の機能ブロック図は一例であって必ずしも実際の構成とは異なる場合もある。サーバ構成だけではなく、機能ブロックについても実際のプログラムモジュールとは対応しない場合もある。

また、上で述べた例ではコンテンツ変換部５６ではフォーマット変換を行う例を示したが、例えばユーザ端末に取り扱い可能なコンテンツデータのデータ・サイズに制限がある場合には、例えば解像度を落としてデータ・サイズを小さくしたり、例えば圧縮率を上げて非可逆圧縮を採用するなどの変換を実施するようにしてもよい。

さらに、ＳＩＰ／ＳＩＭＰＬＥサーバ３においても図２４に示したようなデータを保持しておき、会議Ａプレゼンス管理部３３ａから出力されたコンテンツデータを図２４のようなデータを参照してユーザ端末で使用可能な形式に変換するようにしても良い。

なお、ＳＩＰ／ＳＩＭＰＬＥサーバ３、ＰｏＣ管理サーバ５、ＰｏＣ−ＭＣＵサーバ７及びコンテンツサーバ９は、図３２に示すように、コンピュータ装置であって、メモリ２５０１とＣＰＵ２５０３とハードディスク・ドライブ（ＨＤＤ）２５０５と表示装置２５０９に接続される表示制御部２５０７とリムーバブル・ディスク２５１１用のドライブ装置２５１３と入力装置２５１５とネットワークに接続するための通信制御部２５１７とがバス２５１９で接続されている。オペレーティング・システム（ＯＳ：Operating System）及び本実施例における処理を実施するためのアプリケーション・プログラムは、ＨＤＤ２５０５に格納されており、ＣＰＵ２５０３により実行される際にはＨＤＤ２５０５からメモリ２５０１に読み出される。必要に応じてＣＰＵ２５０３は、表示制御部２５０７、通信制御部２５１７、ドライブ装置２５１３を制御して、必要な動作を行わせる。また、処理途中のデータについては、メモリ２５０１に格納され、必要があればＨＤＤ２５０５に格納される。本発明の実施例では、上で述べた処理を実施するためのアプリケーション・プログラムはリムーバブル・ディスク２５１１に格納されて頒布され、ドライブ装置２５１３からＨＤＤ２５０５にインストールされる。インターネットなどのネットワーク及び通信制御部２５１７を経由して、ＨＤＤ２５０５にインストールされる場合もある。このようなコンピュータ装置は、上で述べたＣＰＵ２５０３、メモリ２５０１などのハードウエアとＯＳ及び必要なアプリケーション・プログラムとが有機的に協働することにより、上で述べたような各種機能を実現する。

また、ユーザ端末についても、ＨＤＤ２５０５及びドライブ装置２５１３の代わりにフラッシュメモリなどの記憶装置を設けることによりほぼ同様な構成で表すことができる。

このようにコンテンツ送信権を有するユーザについてはＵＲＩを指定するだけで、電子会議のためのサーバが当該ＵＲＩに対応するコンテンツデータを取得して、電子会議の参加ユーザのユーザ端末に当該コンテンツデータを送信するので、アクセス権限にかかわらずコンテンツデータを利用することができるようになる。すなわち、電子会議のユーザの利便性が向上している。なお、コンテンツデータを保持するサーバ及び電子会議のためのサーバの間に所定の信頼関係があれば、完全にアクセス権限については問題はなくなる。

さらに、上で述べた取得ステップが、仮想クライアントに対してＵＲＩを含む取得依頼を送信するステップと、仮想クライアントによって、取得依頼に含まれるＵＲＩに係るサーバから当該ＵＲＩに対応するコンテンツデータを取得するステップと、仮想クライアントからコンテンツデータを受信し、コンテンツデータ格納部に格納するステップとを含むようにしてもよい。このように仮想クライアントでコンテンツデータの取得を行うようにすれば、主たる処理を実施するスレッドとは別スレッドとして実行することとなるために、電子会議のためのサーバにおける負荷上昇を抑えることができるようになる。また、仮想クライアントについては別サーバで負荷分散を実施することも可能である。

さらに、本発明において、特定の参加ユーザのユーザ端末からＵＲＩに係るサーバに対する認証情報を受信するステップをさらに含むようにしてもよい。その場合、上で述べた取得ステップが、仮想クライアントに対してＵＲＩ及びＵＲＩに係るサーバに対する認証情報を含む取得依頼を送信するステップと、仮想クライアントによって、上記取得依頼に含まれるＵＲＩに係るサーバに認証情報を送信して認証を受けると共に当該ＵＲＩに対応するコンテンツデータを取得するステップと、仮想クライアントからコンテンツデータを受信し、コンテンツデータ格納部に格納されるステップとを含むようにしてもよい。このようにすれば、コンテンツデータを保持するサーバが特定のユーザに対してのみコンテンツデータを利用可能にしている場合においても、このような構成で対処可能となる。

また、本発明において、特定の参加ユーザのユーザ端末から仮想クライアントの指定情報を受信するステップをさらに含むようにしてもよい。参加ユーザは、例えば仮想クライアントの種別を指定する場合もあれば、具体的に仮想クライアントのＩＤを指定する場合もある。さらに、ユーザ端末側でＵＲＩ等から仮想クライアントを自動的に設定する場合もある。またさらに電子会議のためのサーバで仮想クライアントを起動・指定する場合もある。

図１は本発明の第１の実施例に係るシステム構成図である。 図２はユーザ端末の機能ブロック図である。 図３はユーザＡプレゼンス管理部の機能ブロック図である。 図４は会議Ａプレゼンス管理部の機能ブロック図である。 図５はユーザＡプレゼンス管理部におけるプレゼンスデータ格納部に格納されるデータの模式図である。 図６は会議Ａプレゼンス管理部におけるプレゼンスデータ格納部に格納されるデータの模式図である。 図７はプレゼンスＩＤが”ＦｌｏｏｒＵｓｅｒ”のプレゼンスデータの一例を示す図である。 図８はプレゼンスＩＤが”ＪｏｉｎＵｓｅｒ”のプレゼンスデータの一例を示す図である。 図９はプレゼンスＩＤが”Ｍｅｍｂｅｒ”のプレゼンスデータの一例を示す図である。 図１０はプレゼンスＩＤが”ＳｅｎｄｉｎｇＵｓｅｒ”のプレゼンスデータの一例を示す図である。 図１１は本発明の第１の実施例の処理フローの第１の部分を示す図である。 図１２は本発明の第１の実施例の処理フローの第２の部分を示す図である。 図１３は本発明の第１の実施例の処理フローの第３の部分を示す図である。 図１４は本発明の第１の実施例の処理フローの第４の部分を示す図である。 図１５は本発明の第１の実施例の処理フローの第５の部分を示す図である。 図１６は本発明の第１の実施例の処理フローの第６の部分を示す図である。 図１７は本発明の第１の実施例の処理フローの第７の部分を示す図である。 図１８は本発明の第１の実施例の処理フローの第８の部分を示す図である。 図１９は本発明の第１の実施例の処理フローの第９の部分を示す図である。 図２０は本発明の第１の実施例の処理フローの第１０の部分を示す図である。 図２１は本発明の第１の実施例の処理フローの第１１の部分を示す図である。 図２２は本発明の第１の実施例の処理フローの第１２の部分を示す図である。 図２３は本発明の第１の実施例の処理フローの第１３の部分を示す図である。 図２４は本発明の第１の実施例において会議Ａ管理部におけるユーザデータ格納部に格納されるデータの一例を示す図である。 図２５は本発明の第２の実施例に係るシステム構成図である。 図２６は本発明の第２の実施例における会議Ａプレゼンス管理部におけるプレゼンスデータ格納部に格納されるデータの模式図である。 図２７はプレゼンスＩＤが”ＦｅｔｃｈＲｅｑｕｅｓｔｉｎｇＵｓｅｒ”のプレゼンスデータの一例を示す図である。 図２８は本発明の第２の実施例におけるコンテンツ配信処理の処理フローの第１の部分を示す図である。 図２９は本発明の第２の実施例におけるコンテンツ配信処理の処理フローの第２の部分を示す図である。 図３０は本発明の第２の実施例におけるコンテンツ配信処理の処理フローの第３の部分を示す図である。 図３１は本発明の第２の実施例におけるコンテンツ配信処理の処理フローの第４の部分を示す図である。 図３２はコンピュータの機能ブロック図を示す図である。

次に図２にユーザ端末の機能ブロック図を示す。ユーザ端末は、本実施例における処理を行うためのクライアントアプリケーション９１と、ユーザ端末に設けられているマイクのマイクドライバ９３とを含む。クライアントアプリケーション９１は、音声会議処理部９１１と、コンテンツ処理部９１３と、プレゼンスデータ処理部９１５とを含む。コンテンツ処理部９１３は、ユーザからのコンテンツ配信依頼を受け付け、ＰｏＣ管理サーバ５等に必要な処理を依頼したり、ＵＲＩ（Uniform Resource Identifier）を送信したり、さらにサーバからコンテンツデータを受信して表示装置に表示したりする。なお、本実施例において直接関係のない機能については図示されていない。

図５にユーザＡプレゼンス管理部３１ａに含まれるプレゼンスデータ格納部３１３ａに格納されるデータの一例を示す。図５の例では、プレゼンスデータ格納部３１３ａは、プレゼンス情報格納領域３１３１と、プレゼンスグループ情報格納領域３１３３と、講読者リスト格納領域３１３５とを含む。プレゼンス情報格納領域３１３１は、プレゼンスデータ項目ごとにプレゼンスデータ（ここではユーザ又はユーザ端末の状態情報）を格納するための領域であり、プレゼンスデータ項目のＩＤであるプレゼンスＩＤが”Ｓｔａｔｅ”であるプレゼンスデータ（主にＯＮＬＩＮＥ、ＯＦＦＬＩＮＥ又はＢＵＳＹのいずれか。但し、他の状態（例えば「データ配信中」又は「ＤＡＴＡ Ｓｅｎｄｉｎｇ」など）であってもよい。）を格納するための領域３１６を含む。プレゼンスデータ項目の数に制限はないが、本実施例ではユーザ端末の状態を示すプレゼンスデータ項目のみが示されている。プレゼンスグループ情報格納領域３１３３は、プレゼンスデータ項目（すなわちプレゼンスＩＤ）と配信先ユーザＩＤ（すなわち講読者ＩＤ）を対応付けるためのデータを格納する領域である。ここでは、プレゼンスグループであるグループＩ「デフォルト」に属するプレゼンスＩＤを格納する領域３１７１及びユーザＩＤ（すなわち講読者ＩＤ）を格納する領域３１７２を含む領域３１７が含まれる。デフォルトグループは、講読者が初期的に登録されるグループである。グループ数に限定はなく、任意の数のグループを定義し得る。講読者リスト格納領域３１３５には、ここではＵｓｅｒＢ及びＵｓｅｒＣといった情報配信が許可されたユーザのユーザＩＤ（すなわち講読者ＩＤ）が登録される。講読者数に限定はなく、任意の数の講読者が登録される。

また、プレゼンスＩＤが”ＳｅｎｄｉｎｇＵｓｅｒ”であるプレゼンスデータのための領域３３６４には、例えば図１０に示すようなタグデータ構造のデータを格納する。図１０の例では、このプレゼンスデータの所有者が、Ｃｏｎｆｅｒｅｎｃｅ０１＠ｐｏｃ．ｆｊ．ｃｏｍというＳＩＰ−ＵＲＬで特定されており、＜ｎｏｔｅ＞及び＜／ｎｏｔｅ＞タグの間において、＜ＳｅｎｄｉｎｇＵｓｅｒ＞及び＜／ＳｅｎｄｉｎｇＵｓｅｒ＞との間にコンテンツ送信権を有するユーザのユーザＩＤ（ここではＵｓｅｒＡ＠ｐｏｃ．ｆｊ．ｃｏｍ）と、＜ｃｏｎｔｅｎｔ＞及び＜／ｃｏｎｔｅｎｔ＞の間にコンテンツ送信権を有するユーザが指定したＵＲＩ（ここではhttp://photo.fj.com/aa/bb/img.jpg）とが登録される。

次に第２の例を説明する。ＰｏＣ管理サーバ５の会議Ａ管理部５３ａは、コンテンツデータ格納部５３５ａに格納されたコンテンツデータを、指定されたＵＲＩに対応するプレゼンスデータとしてＳＩＰ／ＳＩＭＰＬＥサーバ３に送信する（ステップＳ２３１）。ＳＩＰ／ＳＩＭＰＬＥサーバ３の会議Ａプレゼンス管理部３３ａは、ＰｏＣ管理サーバ５からＵＲＩに対応するコンテンツデータを受信すると（ステップＳ２３３）、プレゼンスデータの更新とみなしてコンテンツデータをプレゼンスデータとして通知する処理を実施する（ステップＳ２３５）。ここではコンテンツ送信権を有するユーザＡのユーザ端末Ａには送信せず、その他の参加ユーザ（ここではユーザＢ）に送信するものとする。ユーザ端末Ｂのクライアントアプリケーション９１におけるプレゼンスデータ処理部９１５は、コンテンツデータをＳＩＰ／ＳＩＭＰＬＥサーバ３から受信し、コンテンツ処理部９１３に出力する。コンテンツ処理部９１３は、受信したコンテンツデータを表示装置に表示する（ステップＳ２３７）。また、ユーザ端末Ｂのクライアントアプリケーション９１におけるプレゼンスデータ処理部９１５は、ＳＩＰ／ＳＩＭＰＬＥサーバ３にＯＫレスポンスを返信する（ステップＳ２３９）。また、ＳＩＰ／ＳＩＭＰＬＥサーバ３の会議Ａプレゼンス管理部３３ａは、ＯＫレスポンスを受信する（ステップＳ２４１）。

なお、上で述べた例では、ＵＲＩで指定されたコンテンツデータが、ユーザ端末Ａ以外の会議メンバ又参加ユーザのユーザ端末において使用可能か否かは分からない。上で述べたように、各参加ユーザのユーザ端末のメディア情報についてはＰｏＣ管理サーバ５側でも取得して、例えばユーザデータ格納部５３３ａに図２４に示すようなデータを保持している。具体的には、会議に参加しているユーザのユーザＩＤ毎に、ＩＰアドレス、話者権の有無、コンテンツ送信権の有無、許容ファイル形式（ＧＩＦ，ＪＰＥＧ，ＴＩＦＦ，ＭＰＥＧなどのファイル形式）が格納されている。取扱可能なファイルサイズ等に関するデータを保持することもある。このようなデータを用いて、会議Ａ管理部５３ａは、コンテンツデータ格納部５３５ａに格納されたデータが、参加ユーザのユーザ端末が使用できるか判断する。例えば受信したコンテンツの形式がＴＩＦＦであって図２４に示すようなデータを保持している場合には、ユーザ端末Ａ（ＵｓｅｒＡ）は使用可能であるが、ユーザ端末Ｂ及びユーザ端末Ｃについては使用不可と判断される場合がある。もし使用不可と判断されるようなユーザ端末については、当該コンテンツデータを送信しないようにする。具体的には、上で述べた第１の例のようにＰｏＣ管理サーバ５からコンテンツデータを送信するようにして、使用不可と判断されたユーザ端末には送信しない。このようにすれば、不要な通信を行わずに済む。無線区間の帯域を無駄に消費することもない。

２．第２の実施例
本来、サーバはできるだけ負荷を軽くしておく必要があるが、第１の実施例では、ＰｏＣ管理サーバ５は、コンテンツデータ取得部５５及びコンテンツ変換部５６を含むので、処理負荷が高くなってしまう可能性がある。従って、例えば図２５のようなシステム構成を採用する。

図２５と図１の差は、ＰｏＣ管理サーバ５の構成である。コンテンツデータ取得部５５の代わりに、１又は複数のコンテンツ取得仮想クライアント５９（図２５ではコンテンツ取得仮想クライアント５９ａ及び５９ｂ）が設けられている。このコンテンツ取得仮想クライアント５９は、コンテンツをコンテンツサーバ９から代理で取得し、ユーザ端末とは別の特殊な仮想的なクライアントとして機能するプログラムである。図２５ではＰｏＣ管理サーバ５内で、会議管理部５３などとは別スレッドで起動・動作させるようにしているが、例えばコンテンツ取得仮想クライアント５９用のサーバを別に用意しても良い。このような構成を採用することによって、よりＰｏＣ管理サーバ５の負荷を低下させることができる。

そして、会議Ａ管理部５３ａは、ユーザデータ格納部５３３ａに格納されている会議Ａの参加者のＩＰアドレス等を読み出し、コンテンツデータ格納部５３５ａに格納されたユーザ端末Ａが使用可能なコンテンツデータをユーザ端末Ａに送信する（ステップＳ３６７）。ユーザ端末Ａのコンテンツ処理部９１３は、コンテンツデータをＰｏＣ管理サーバ５から受信し、表示装置に表示する（ステップＳ３６９）。ユーザ端末Ａのクライアントアプリケーション９１におけるコンテンツ処理部９１３は、ＯＫレスポンスをＰｏＣ管理サーバ５に返信する（ステップＳ３７１）。ＰｏＣ管理サーバ５の会議Ａ管理部５３ａは、ユーザ端末ＡからＯＫレスポンスを受信する（ステップＳ３７３）。コンテンツ送信権を有するユーザＡのユーザ端末Ａには送信しない場合もある。

また、会議Ａ管理部５３ａは、コンテンツデータ格納部５３５ａに格納されたユーザ端末Ｂが使用可能なコンテンツデータをユーザ端末Ｂに送信する（ステップＳ３６７）。ユーザ端末Ｂのコンテンツ処理部９１３は、コンテンツデータをＰｏＣ管理サーバ５から受信し、表示装置に表示する（ステップＳ３７５）。ユーザ端末Ｂのクライアントアプリケーション９１におけるコンテンツ処理部９１３は、ＯＫレスポンスをＰｏＣ管理サーバ５に返信する（ステップＳ３７７）。ＰｏＣ管理サーバ５の会議Ａ管理部５３ａは、ユーザ端末ＢからＯＫレスポンスを受信する（ステップＳ３７９）。

ＳＩＰ／ＳＩＭＰＬＥサーバ３の会議Ａプレゼンス管理部３３ａは、ＰｏＣ管理サーバ５からＵＲＩに対応するコンテンツデータを受信すると（ステップＳ３８７）、プレゼンスデータの更新とみなしてコンテンツデータをプレゼンスデータとして通知する処理を実施する（ステップＳ３８９）。ユーザ端末Ａのクライアントアプリケーション９１におけるプレゼンスデータ処理部９１５は、コンテンツデータをＳＩＰ／ＳＩＭＰＬＥサーバ３から受信し、コンテンツ処理部９１３に出力する。コンテンツ処理部９１３は、受信したコンテンツデータを表示装置に表示する（ステップＳ３９１）。また、ユーザ端末Ａのクライアントアプリケーション９１におけるプレゼンスデータ処理部９１５は、ＳＩＰ／ＳＩＭＰＬＥサーバ３にＯＫレスポンスを返信する（ステップＳ３９３）。また、ＳＩＰ／ＳＩＭＰＬＥサーバ３の会議Ａプレゼンス管理部３３ａは、ＯＫレスポンスを受信する（ステップＳ３９５）。なお、ユーザ端末Ａには送信しないようにしても良い。

さらに、ＳＩＰ／ＳＩＭＰＬＥサーバ３の会議Ａプレゼンス管理部３３ａは、プレゼンスデータの更新とみなしてコンテンツデータをプレゼンスデータとしてユーザ端末Ｂに通知する（ステップＳ３８９）。ユーザ端末Ｂのクライアントアプリケーション９１におけるプレゼンスデータ処理部９１５は、コンテンツデータをＳＩＰ／ＳＩＭＰＬＥサーバ３から受信し、コンテンツ処理部９１３に出力する。コンテンツ処理部９１３は、受信したコンテンツデータを表示装置に表示する（ステップＳ３９６）。また、ユーザ端末Ｂのクライアントアプリケーション９１におけるプレゼンスデータ処理部９１５は、ＳＩＰ／ＳＩＭＰＬＥサーバ３にＯＫレスポンスを返信する（ステップＳ３９７）。また、ＳＩＰ／ＳＩＭＰＬＥサーバ３の会議Ａプレゼンス管理部３３ａは、ＯＫレスポンスを受信する（ステップＳ３９９）。

Claims (10)

1. 電子会議におけるコンテンツ配信方法であって、
   前記電子会議に参加する参加ユーザに対して配信すべきコンテンツデータのＵＲＩ（Uniform Resource Identifier）を特定の参加ユーザのユーザ端末から受信するステップと、
   受信した前記ＵＲＩに係るサーバから当該ＵＲＩに対応するコンテンツデータを取得し、コンテンツデータ格納部に格納する取得ステップと、
   前記コンテンツデータ格納部に格納されたコンテンツデータを、前記参加ユーザのユーザ端末に送信する送信ステップと、
   を含み、電子会議のためのサーバにより実行されるコンテンツ配信方法。
2. 前記特定の参加ユーザがコンテンツ送信権を有することを確認する確認ステップをさらに含み、
   前記取得ステップを、前記特定の参加ユーザが前記コンテンツ送信権を有する場合に実行する
   請求項１記載のコンテンツ配信方法。
3. 前記送信ステップにおいて、
   前記電子会議についてのプレゼンスデータとして、前記コンテンツデータ格納部に格納された前記コンテンツデータを前記参加ユーザのユーザ端末に送信する
   ことを特徴とする請求項１記載のコンテンツ配信方法。
4. 前記電子会議への参加に際して参加ユーザのユーザ端末で使用可能なデータに関する情報を受信し、データ格納部に格納するステップと、
   前記データ格納部に格納された前記参加ユーザのユーザ端末で使用可能なデータに関する情報に基づき、前記コンテンツデータ格納部に格納された前記コンテンツデータが、前記参加ユーザのユーザ端末で使用可能なデータであるか否か判断する判断ステップと、
   をさらに含み、
   前記送信ステップが、前記判断ステップにおいて肯定的な判断がなされたユーザ端末に対して実行される
   ことを特徴とする請求項１記載のコンテンツ配信方法。
5. 前記電子会議への参加に際して参加ユーザのユーザ端末で使用可能なデータに関する情報を受信し、データ格納部に格納するステップと、
   前記データ格納部に格納された前記参加ユーザのユーザ端末で使用可能なデータに関する情報に基づき、前記コンテンツデータ格納部に格納された前記コンテンツデータが、前記参加ユーザのユーザ端末で使用可能なデータであるか否か判断する判断ステップと、
   前記判断ステップにおいて否定的な判断がなされた場合、前記データ格納部に格納された前記参加ユーザのユーザ端末で使用可能なデータに関する情報に基づき、前記コンテンツデータについて前記参加ユーザのユーザ端末で使用可能なデータに変換し、前記コンテンツデータ格納部に格納するステップと、
   をさらに含む請求項１記載のコンテンツ配信方法。
6. 前記取得ステップが、
   仮想クライアントに対して前記ＵＲＩを含む取得依頼を送信するステップと、
   前記仮想クライアントによって、前記取得依頼に含まれる前記ＵＲＩに係るサーバから前記ＵＲＩに対応するコンテンツデータを取得するステップと、
   前記仮想クライアントから前記コンテンツデータを受信し、前記コンテンツデータ格納部に格納されるステップと、
   を含む請求項１記載のコンテンツ配信方法。
7. 前記特定のユーザのユーザ端末から前記ＵＲＩに係るサーバに対する認証情報を受信するステップ、
   をさらに含み、
   前記取得ステップが、
   仮想クライアントに対して前記ＵＲＩ及び前記ＵＲＩに係るサーバに対する認証情報を含む取得依頼を送信するステップと、
   前記仮想クライアントによって、前記取得依頼に含まれる前記ＵＲＩに係るサーバに前記認証情報を送信して認証を受けると共に前記ＵＲＩに対応するコンテンツデータを取得するステップと、
   前記仮想クライアントから前記コンテンツデータを受信し、前記コンテンツデータ格納部に格納されるステップと、
   を含む請求項１記載のコンテンツ配信方法。
8. 前記特定のユーザのユーザ端末から前記仮想クライアントの指定情報を受信するステップ
   をさらに含む請求項６又は７記載のコンテンツ配信方法。
9. 請求項１乃至８をコンピュータにより実行させるためのコンテンツ配信方法。
10. 電子会議のためのコンピュータであって、
    前記電子会議に参加する参加ユーザに対して配信すべきコンテンツデータのＵＲＩ（Uniform Resource Identifier）を特定の参加ユーザのユーザ端末から受信する手段と、
    受信した前記ＵＲＩに係るサーバから当該ＵＲＩに対応するコンテンツデータを取得し、コンテンツデータ格納部に格納する取得手段と、
    前記コンテンツデータ格納部に格納されたコンテンツデータを、前記参加ユーザのユーザ端末に送信する送信手段と、
    を有するコンピュータ。

Images