(57)【要約】【課題】参加者が会議におけるプライバシーを確保するために、参加者に対して複数のプライバシー設定を行うことができ、各参加者により設定されたプライバシー設定に基づいて会議全体のストリームメディアの送受信設定を迅速に判断し、各参加者のストリームメディアの送受信を迅速に制御すること。【解決手段】  マルチメディア会議システム１は、クライアント端末５において設定された送受信要求に基づいて、アプリケーションサーバ３が混合パターンを決定し、メディアサーバ２が、この混合パターンに基づいてクライアント端末５より受信したストリームメディアを混合し、送受信要求を満たし得るストリームメディアを各クライアント端末５に送信する。【選択図】  図１
2009231949.tif 000002
【特許請求の範囲】
【請求項１】
複数のクライアント端末より発信されるストリームメディアをメディアサーバで受信し、受信された該ストリームメディアを前記メディアサーバで混合して前記各クライアント端末に送信するマルチメディア会議システムであって、
前記メディアサーバにおいて混合される前記ストリームメディアの混合パターンを決定するアプリケーションサーバを有し、
前記クライアント端末は、特定のクライアント端末を指定することにより、当該クライアント端末におけるストリームメディアの送受信要求を設定することができ、
前記アプリケーションサーバは、前記クライアント端末において設定された送受信要求に基づいて、前記混合パターンを決定し、
前記メディアサーバは、前記アプリケーションサーバにおいて決定された前記混合パターンに基づいて、前記クライアント端末より受信した前記ストリームメディアを混合して、前記送受信要求を満たし得るストリームメディアを各クライアント端末に送信する
ことを特徴とするマルチメディア会議システム。
【請求項２】
前記送受信要求を設定するクライアント端末Ｚは、
該クライアント端末Ｚにより指定された特定のクライアント端末Ｘが、前記クライアント端末に対してストリームメディアを発信することを制限する機能を表すミュートと、
前記クライアント端末Ｚが受信するストリームメディアを、指定された前記特定のクライアント端末Ｘにより発信されたストリームメディアのみとし、他のクライアント端末Ｙにより発信されたストリームメディアの受信を制限する機能を表すセレクトとを、
前記送受信要求として設定することができ、
前記アプリケーションサーバは、
（１）前記クライアント端末Ｘがミュートされている場合と、
（２）前記クライアント端末Ｘがミュートされず、
かつ、前記クライアント端末Ｙがセレクトされ、
かつ、前記クライアント端末Ｘがセレクトされていない場合とに、
前記クライアント端末Ｚにおいて前記クライアント端末Ｘの発信したストリームメディアを受信することが不可能であると判断して前記混合パターンを決定すること
を特徴とする請求項１に記載のマルチメディア会議システム。
【請求項３】
前記アプリケーションサーバは、
前記（２）に示したクライアント端末Ｘがミュートされていない場合において、
前記クライアント端末Ｘと前記クライアント端末Ｙとの両方が前記クライアント端末Ｚであるかあるいは両方が前記クライアント端末Ｚでない場合にのみ、
前記クライアント端末Ｙがセレクトされているか否か、
および、前記クライアント端末Ｘがセレクトされているか否かを判断し、
前記クライアント端末Ｘと前記クライアント端末Ｙとの両方が前記クライアント端末Ｚであるかあるいは両方が前記クライアント端末Ｚでなく、
かつ、前記クライアント端末Ｙがセレクトされ、
かつ、前記クライアント端末Ｘがセレクトされていない場合に、
前記クライアント端末Ｚにおいて前記クライアント端末Ｘの発信したストリームメディアを受信することが不可能であると判断して前記混合パターンを決定すること
を特徴とする請求項２に記載のマルチメディア会議システム。
【請求項４】
前記送受信要求を設定するクライアント端末Ｚは、
該クライアント端末Ｚにより指定された特定のクライアント端末Ｘにおいて、前記クライアント端末Ｚにより発信されたストリームメディアの受信を制限する機能を表すデフンと、
前記クライアント端末Ｚが発信するストリームメディアを、指定された前記特定のクライアント端末Ｘのみが受信でき、前記クライアント端末Ｚが発信するストリームメディアを、他のクライアント端末Ｙにおいて受信することを制限する機能を表すアテンドとを、
前記送受信要求として設定することができ、
前記アプリケーションサーバは、
（３）前記クライアント端末Ｘがデフンされている場合と、
（４）前記クライアント端末Ｘがデフンされず、
かつ、前記クライアント端末Ｙがアテンドされ、
かつ、前記クライアント端末Ｘがアテンドされていない場合とに、
前記クライアント端末Ｘにおいて前記クライアント端末Ｚの発信したストリームメディアを受信することが不可能であると判断して前記混合パターンを決定すること
を特徴とする請求項１に記載のマルチメディア会議システム。
【請求項５】
前記アプリケーションサーバは、
前記（４）に示したクライアント端末Ｘがデフンされていない場合において、
前記クライアント端末Ｘと前記クライアント端末Ｙとの両方が前記クライアント端末Ｚであるかあるいは両方が前記クライアント端末Ｚでない場合にのみ、
前記クライアント端末Ｙがアテンドされているか否か、
および、前記クライアント端末Ｘがアテンドされているか否かを判断し、
前記クライアント端末Ｘと前記クライアント端末Ｙとの両方が前記クライアント端末Ｚであるかあるいは両方が前記クライアント端末Ｚでなく、
かつ、前記クライアント端末Ｙがアテンドされ、
かつ、前記クライアント端末Ｘがアテンドされていない場合に、
前記クライアント端末Ｘにおいて前記クライアント端末Ｚの発信したストリームメディアを受信することが不可能であると判断して前記混合パターンを決定すること
を特徴とする請求項４に記載のマルチメディア会議システム。
【請求項６】
複数のクライアント端末より受信したストリームメディアをメディアサーバで混合して前記クライアント端末に送信する処理に用いられる前記ストリームメディアの混合パターンを決定するアプリケーションサーバであって、
前記クライアント端末において特定のクライアント端末を指定することにより設定されたストリームメディアの送受信要求を、前記クライアント端末より受信する送受信要求受信手段と、
前記クライアント端末において設定された送受信要求に基づいて、前記混合パターンを決定する混合パターン決定手段と、
決定された前記混合パターンを前記メディアサーバに送信する送信手段と
を有し、
前記混合パターン決定手段は、
クライアント端末Ｚにより指定された特定のクライアント端末Ｘが、前記クライアント端末に対してストリームメディアを発信することを制限する機能を表すミュートと、
前記クライアント端末Ｚが受信するストリームメディアを、指定された前記特定のクライアント端末Ｘにより発信されたストリームメディアのみとし、他のクライアント端末Ｙにより発信されたストリームメディアの受信を制限する機能を表すセレクトとを、
前記送受信要求より判断し、
（１）前記クライアント端末Ｘがミュートされている場合と、
（２）前記クライアント端末Ｘがミュートされず、
かつ、前記クライアント端末Ｙがセレクトされ、
かつ、前記クライアント端末Ｘがセレクトされていない場合とに、
前記クライアント端末Ｚにおいて前記クライアント端末Ｘの発信したストリームメディアを受信することが不可能であると判断して前記混合パターンを決定すること
を特徴とするアプリケーションサーバ。
【請求項７】
前記混合パターン決定手段は、
前記（２）に示したクライアント端末Ｘがミュートされていない場合において、
前記クライアント端末Ｘと前記クライアント端末Ｙとの両方が前記クライアント端末Ｚであるかあるいは両方が前記クライアント端末Ｚでない場合にのみ、
前記クライアント端末Ｙがセレクトされているか否か、
および、前記クライアント端末Ｘがセレクトされているか否かを判断し、
前記クライアント端末Ｘと前記クライアント端末Ｙとの両方が前記クライアント端末Ｚであるかあるいは両方が前記クライアント端末Ｚでなく、
かつ、前記クライアント端末Ｙがセレクトされ、
かつ、前記クライアント端末Ｘがセレクトされていない場合に、
前記クライアント端末Ｚにおいて前記クライアント端末Ｘの発信したストリームメディアを受信することが不可能であると判断して前記混合パターンを決定すること
を特徴とする請求項６に記載のアプリケーションサーバ。
【請求項８】
複数のクライアント端末より受信したストリームメディアをメディアサーバで混合して前記クライアント端末に送信する処理に用いられる前記ストリームメディアの混合パターンを決定するアプリケーションサーバであって、
前記クライアント端末において特定のクライアント端末を指定することにより設定されたストリームメディアの送受信要求を、前記クライアント端末より受信する送受信要求受信手段と、
前記クライアント端末において設定された送受信要求に基づいて、前記混合パターンを決定する混合パターン決定手段と、
決定された前記混合パターンを前記メディアサーバに送信する送信手段と
を有し、
前記混合パターン決定手段は、
クライアント端末Ｚにより指定された特定のクライアント端末Ｘにおいて、前記クライアント端末Ｚにより発信されたストリームメディアの受信を制限する機能を表すデフンと、
前記クライアント端末Ｚが発信するストリームメディアを、指定された前記特定のクライアント端末Ｘのみが受信でき、前記クライアント端末Ｚが発信するストリームメディアを、他のクライアント端末Ｙにおいて受信することを制限する機能を表すアテンドとを、
前記送受信要求より判断し、
（３）前記クライアント端末Ｘがデフンされている場合と、
（４）前記クライアント端末Ｘがデフンされず、
かつ、前記クライアント端末Ｙがアテンドされ、
かつ、前記クライアント端末Ｘがアテンドされていない場合とに、
前記クライアント端末Ｘにおいて前記クライアント端末Ｚの発信したストリームメディアを受信することが不可能であると判断して前記混合パターンを決定すること
を特徴とするアプリケーションサーバ。
【請求項９】
前記混合パターン決定手段は、
前記（４）に示したクライアント端末Ｘがデフンされていない場合において、
前記クライアント端末Ｘと前記クライアント端末Ｙとの両方が前記クライアント端末Ｚであるかあるいは両方が前記クライアント端末Ｚでない場合にのみ、
前記クライアント端末Ｙがアテンドされているか否か、
および、前記クライアント端末Ｘがアテンドされているか否かを判断し、
前記クライアント端末Ｘと前記クライアント端末Ｙとの両方が前記クライアント端末Ｚであるかあるいは両方が前記クライアント端末Ｚでなく、
かつ、前記クライアント端末Ｙがアテンドされ、
かつ、前記クライアント端末Ｘがアテンドされていない場合に、
前記クライアント端末Ｘにおいて前記クライアント端末Ｚの発信したストリームメディアを受信することが不可能であると判断して前記混合パターンを決定すること
を特徴とする請求項８に記載のアプリケーションサーバ。
【請求項１０】
複数のクライアント端末より受信したストリームメディアをメディアサーバで混合して前記クライアント端末に送信する処理に用いられる前記ストリームメディアの混合パターンを、アプリケーションサーバにおいて決定する混合パターン決定方法であって、
前記クライアント端末において特定のクライアント端末を指定することにより設定されたストリームメディアの送受信要求を、送受信要求受信手段が前記クライアント端末より受信する送受信要求受信ステップと、
前記クライアント端末において設定された送受信要求に基づいて、混合パターン決定手段が前記混合パターンを決定する混合パターン決定ステップと、
決定された前記混合パターンを、送信手段が前記メディアサーバに送信する送信ステップと
を有し、
前記混合パターン決定ステップにおいて、前記混合パターン決定手段が、
クライアント端末Ｚにより指定された特定のクライアント端末Ｘが、前記クライアント端末に対してストリームメディアを発信することを制限する機能を表すミュートと、
前記クライアント端末Ｚが受信するストリームメディアを、指定された前記特定のクライアント端末Ｘにより発信されたストリームメディアのみとし、他のクライアント端末Ｙにより発信されたストリームメディアの受信を制限する機能を表すセレクトとを、
前記送受信要求より判断する要求内容判断ステップと、
前記混合パターン決定手段が、前記要求内容判断ステップにおいて判断された要求内容に基づいて、
（１）前記クライアント端末Ｘがミュートされている場合と、
（２）前記クライアント端末Ｘがミュートされず、
かつ、前記クライアント端末Ｙがセレクトされ、
かつ、前記クライアント端末Ｘがセレクトされていない場合とに、
前記クライアント端末Ｚにおいて前記クライアント端末Ｘの発信したストリームメディアを受信することが不可能であると判断して前記混合パターンを決定する混合パターン判断ステップと
を有することを特徴とする混合パターン決定方法。
【請求項１１】
前記混合パターン判断ステップにおいて、前記混合パターン決定手段は、
前記（２）に示したクライアント端末Ｘがミュートされていない場合であって、
前記クライアント端末Ｘと前記クライアント端末Ｙとの両方が前記クライアント端末Ｚであるかあるいは両方が前記クライアント端末Ｚでない場合にのみ、
前記クライアント端末Ｙがセレクトされているか否か、
および、前記クライアント端末Ｘがセレクトされているか否かを判断し、
前記クライアント端末Ｘと前記クライアント端末Ｙとの両方が前記クライアント端末Ｚであるかあるいは両方が前記クライアント端末Ｚでなく、
かつ、前記クライアント端末Ｙがセレクトされ、
かつ、前記クライアント端末Ｘがセレクトされていない場合に、
前記クライアント端末Ｚにおいて前記クライアント端末Ｘの発信したストリームメディアを受信することが不可能であると判断して前記混合パターンを決定すること
を特徴とする請求項１０に記載の混合パターン決定方法。
【請求項１２】
複数のクライアント端末より受信したストリームメディアをメディアサーバで混合して前記クライアント端末に送信する処理に用いられる前記ストリームメディアの混合パターンを、アプリケーションサーバにおいて決定する混合パターン決定方法であって、
前記クライアント端末において特定のクライアント端末を指定することにより設定されたストリームメディアの送受信要求を、送受信要求受信手段が前記クライアント端末より受信する送受信要求受信ステップと、
前記クライアント端末において設定された送受信要求に基づいて、混合パターン決定手段が前記混合パターンを決定する混合パターン決定ステップと、
決定された前記混合パターンを、送信手段が前記メディアサーバに送信する送信ステップと
を有し、
前記混合パターン決定ステップにおいて、前記混合パターン決定手段が、
クライアント端末Ｚにより指定された特定のクライアント端末Ｘにおいて、前記クライアント端末Ｚにより発信されたストリームメディアの受信を制限する機能を表すデフンと、
前記クライアント端末Ｚが発信するストリームメディアを、指定された前記特定のクライアント端末Ｘのみが受信でき、前記クライアント端末Ｚが発信するストリームメディアを、他のクライアント端末Ｙにおいて受信することを制限する機能を表すアテンドとを、
前記送受信要求より判断する要求内容判断ステップと、
前記混合パターン決定手段が、前記要求内容判断ステップにおいて判断された要求内容に基づいて、
（３）前記クライアント端末Ｘがデフンされている場合と、
（４）前記クライアント端末Ｘがデフンされず、
かつ、前記クライアント端末Ｙがアテンドされ、
かつ、前記クライアント端末Ｘがアテンドされていない場合とに、
前記クライアント端末Ｘにおいて前記クライアント端末Ｚの発信したストリームメディアを受信することが不可能であると判断して前記混合パターンを決定する混合パターン判断ステップと
を有することを特徴とする混合パターン決定方法。
【請求項１３】
前記混合パターン判断ステップにおいて、前記混合パターン決定手段は、
前記（４）に示したクライアント端末Ｘがデフンされていない場合であって、
前記クライアント端末Ｘと前記クライアント端末Ｙとの両方が前記クライアント端末Ｚであるかあるいは両方が前記クライアント端末Ｚでない場合にのみ、
前記クライアント端末Ｙがアテンドされているか否か、
および、前記クライアント端末Ｘがアテンドされているか否かを判断し、
前記クライアント端末Ｘと前記クライアント端末Ｙとの両方が前記クライアント端末Ｚであるかあるいは両方が前記クライアント端末Ｚでなく、
かつ、前記クライアント端末Ｙがアテンドされ、
かつ、前記クライアント端末Ｘがアテンドされていない場合に、
前記クライアント端末Ｘにおいて前記クライアント端末Ｚの発信したストリームメディアを受信することが不可能であると判断して前記混合パターンを決定すること
を特徴とする請求項１２に記載の混合パターン決定方法。
【請求項１４】
複数のクライアント端末より受信したストリームメディアをメディアサーバで混合して前記クライアント端末に送信する処理に用いられる前記ストリームメディアの混合パターンを、アプリケーションサーバにおいて決定する混合パターン決定用プログラムであって、
前記アプリケーションサーバのコンピュータに、
前記クライアント端末において特定のクライアント端末を指定することにより設定されたストリームメディアの送受信要求を、前記クライアント端末より受信する送受信要求受信機能と、
前記クライアント端末において設定された送受信要求に基づいて前記混合パターンを決定する混合パターン決定機能と、
決定された前記混合パターンを、前記メディアサーバに送信する送信機能と
を実現させ、
前記混合パターン決定機能において、前記コンピュータに、
クライアント端末Ｚにより指定された特定のクライアント端末Ｘが、前記クライアント端末に対してストリームメディアを発信することを制限する機能を表すミュートと、
前記クライアント端末Ｚが受信するストリームメディアを、指定された前記特定のクライアント端末Ｘにより発信されたストリームメディアのみとし、他のクライアント端末Ｙにより発信されたストリームメディアの受信を制限する機能を表すセレクトとを、
前記送受信要求より判断させる要求内容判断機能と、
該要求内容判断機能により判断された要求内容に基づいて、
（１）前記クライアント端末Ｘがミュートされている場合と、
（２）前記クライアント端末Ｘがミュートされず、
かつ、前記クライアント端末Ｙがセレクトされ、
かつ、前記クライアント端末Ｘがセレクトされていない場合とに、
前記クライアント端末Ｚにおいて前記クライアント端末Ｘの発信したストリームメディアを受信することが不可能であると判断させて前記混合パターンを決定させる混合パターン判断機能と
を実現させるための混合パターン決定用プログラム。
【請求項１５】
前記混合パターン判断機能において、前記コンピュータに、
前記（２）に示したクライアント端末Ｘがミュートされていない場合であって、
前記クライアント端末Ｘと前記クライアント端末Ｙとの両方が前記クライアント端末Ｚであるかあるいは両方が前記クライアント端末Ｚでない場合にのみ、
前記クライアント端末Ｙがセレクトされているか否か、
および、前記クライアント端末Ｘがセレクトされているか否かを判断させ、
前記クライアント端末Ｘと前記クライアント端末Ｙとの両方が前記クライアント端末Ｚであるかあるいは両方が前記クライアント端末Ｚでなく、
かつ、前記クライアント端末Ｙがセレクトされ、
かつ、前記クライアント端末Ｘがセレクトされていない場合に、
前記クライアント端末Ｚにおいて前記クライアント端末Ｘの発信したストリームメディアを受信することが不可能であると判断させて前記混合パターンを決定させること
を実現させるための請求項１４に記載の混合パターン決定用プログラム。
【請求項１６】
複数のクライアント端末より受信したストリームメディアをメディアサーバで混合して前記クライアント端末に送信する処理に用いられる前記ストリームメディアの混合パターンを、アプリケーションサーバにおいて決定する混合パターン決定用プログラムであって、
前記アプリケーションサーバのコンピュータに、
前記クライアント端末において特定のクライアント端末を指定することにより設定されたストリームメディアの送受信要求を、前記クライアント端末より受信する送受信要求受信機能と、
前記クライアント端末において設定された送受信要求に基づいて前記混合パターンを決定する混合パターン決定機能と、
決定された前記混合パターンを、前記メディアサーバに送信する送信機能と
を実現させ、
前記混合パターン決定機能において、前記コンピュータに、
クライアント端末Ｚにより指定された特定のクライアント端末Ｘにおいて、前記クライアント端末Ｚにより発信されたストリームメディアの受信を制限する機能を表すデフンと、
前記クライアント端末Ｚが発信するストリームメディアを、指定された前記特定のクライアント端末Ｘのみが受信でき、前記クライアント端末Ｚが発信するストリームメディアを、他のクライアント端末Ｙにおいて受信することを制限する機能を表すアテンドとを、
前記送受信要求より判断させる要求内容判断機能と、
該要求内容判断機能により判断された要求内容に基づいて、
（３）前記クライアント端末Ｘがデフンされている場合と、
（４）前記クライアント端末Ｘがデフンされず、
かつ、前記クライアント端末Ｙがアテンドされ、
かつ、前記クライアント端末Ｘがアテンドされていない場合とに、
前記クライアント端末Ｘにおいて前記クライアント端末Ｚの発信したストリームメディアを受信することが不可能であると判断させて前記混合パターンを決定させる混合パターン判断機能と
を実現させるための混合パターン決定用プログラム。
【請求項１７】
前記混合パターン判断機能において、前記コンピュータに、
前記（４）に示したクライアント端末Ｘがデフンされていない場合であって、
前記クライアント端末Ｘと前記クライアント端末Ｙとの両方が前記クライアント端末Ｚであるかあるいは両方が前記クライアント端末Ｚでない場合にのみ、
前記クライアント端末Ｙがアテンドされているか否か、
および、前記クライアント端末Ｘがアテンドされているか否かを判断させ、
前記クライアント端末Ｘと前記クライアント端末Ｙとの両方が前記クライアント端末Ｚであるかあるいは両方が前記クライアント端末Ｚでなく、
かつ、前記クライアント端末Ｙがアテンドされ、
かつ、前記クライアント端末Ｘがアテンドされていない場合に、
前記クライアント端末Ｘにおいて前記クライアント端末Ｚの発信したストリームメディアを受信することが不可能であると判断させて前記混合パターンを決定させること
を実現させるための請求項１６に記載の混合パターン決定用プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、マルチメディア会議システム、アプリケーションサーバ、混合パターン決定方法および混合パターン決定用プログラムに関し、より詳細には、複数のクライアント端末より発信されるストリームメディアをメディアサーバで受信し、受信された各クライアント端末のストリームメディアをメディアサーバで混合して各クライアント端末に送信するマルチメディア会議システム、アプリケーションサーバ、混合パターン決定方法および混合パターン決定用プログラムに関する。
【背景技術】
【０００２】
従来、リアルタイムに意見の交換を行うためには、参加者を物理的に同一の会議場に集める必要があった。しかしながら、今日では、通信技術の高度な発達により、参加者が物理的に集まることなく、ネットワークを介してリアルタイムに意見の交換を行うことが可能となっている。このようなネットワークを利用したマルチメディア会議では、会議に参加したすべての参加者がオンラインで接続されており、各参加者は、ネットワークを介して自分の意見を広く他の参加者に対して発言し、他の参加者の意見を聴取することが可能となっている。
【０００３】
しかしながら、一参加者の発言がすべての他の参加者にそのまま聞こえてしまう状態では、各参加者のプライバシーを確保することできず、また、円滑な会議の進行を妨げる場合があるという問題があった。このため、各参加者のプライバシーを確保する方法がいろいろと考案されている。
【０００４】
例えば、マルチメディア会議システムの一例として、プライバシー機能を備えたインスタント・メッセージング・システムが提案されている（例えば、非特許文献１参照。）。このシステムでは、インターフェースを用いてプライバシーの設定を選択することにより、一部の参加者のみを意見交換の場に招待し、招待された参加者とだけ意見交換を行うことが可能となっている。
【０００５】
しかしながら、プライバシーの確保を行う方法として、参加者を基準としてグループ分けを行って発言（意見）を制限するのではなく、参加者の発言（意見）を基準として特定の発言（意見）のみが聞こえたり（取得することができたり）、特定の意見（発言）のみを聞こえなくしたり（取得を拒否することができたり）する設定を行うことが好ましい。このような発言（意見）を基準としたプライバシーの設定方法として、一般的にミュート機能が用いられている。
【０００６】
マルチメディア会議における一般的なミュート機能として、図１２に示すように、セルフミュート、ＰＢＸミュートおよびナローキャスティング・ミュートの３種類のミュート機能が知られている。
【０００７】
セルフミュートとは、各参加者の意見（以下、この意見に関する情報をメディアという）を集中的に取得し、各参加者に対して配信するサーバ（以下、このようにメディアの取得・配信を行うサーバを、メディアサーバという）に対して、自分のメディアを送信しないことにより他の参加者に自分の意見を聞こえなくする機能である。図１２に示す“メディアの送受信関係”欄の図では、参加者Ｐ１が自分の意見をミュートすることにより、参加者Ｐ１の意見が他の参加者Ｐ２、Ｐ３、Ｐ４に伝わらない状態を示している。
【０００８】
ＰＢＸミュートとは、マルチメディア会議システムの管理権限を有する者が、特定の参加者のメディアを他の参加者において取得できないように制御する機能である。図１２に示す“メディアの送受信関係”欄の図では、参加者Ｐ１の意見が管理者により制限され、他の参加者Ｐ２、Ｐ３、Ｐ４が参加者Ｐ１の意見を聞くことができない状態を示している。
【０００９】
ナローキャスティング・ミュートは、Peer to Peerの形態（不特定多数のコンピュータが相互に接続され、直接ファイルなどの情報を送受信するインターネットの利用形態）を利用して、管理権限を有する参加者が特定の参加者を選択し、その参加者に対してメディアを送信しない機能である。図１２に示す“メディアの送受信関係”欄の図では、参加者Ｐ１が参加者Ｐ２を選択することにより、参加者Ｐ２のメディアが参加者Ｐ１において拒絶された状態を示している。このような場合、参加者Ｐ２は他の参加者Ｐ３、Ｐ４とは意見の交換（メディアの送受信）を行うことは可能であるが、参加者Ｐ１に対しては意見の受信（メディアの受信）だけが可能で送信（メディアの送信）を行うことができない。
【特許文献１】特開２００７−１７２６２５号公報（第８−９頁、第１図〜第３図）
【発明の開示】
【発明が解決しようとする課題】
【００１０】
しかしながら、このようなミュート機能だけでは、参加者の利便性を損なうことなくプライベート機能を確保することが容易ではないという問題があった。例えば、ミュート機能は単に発言を制限するだけである。一方で、より利便性の高いマルチメディア会議システムを実現するためには、参加者が、特定の参加者（自分および他人）により発信されるメディアをブロックする機能（上述したセルフミュートとは異なり、特定の参加者を選択して、選択された参加者のメディアが他の参加者に発信されることを抑制する機能、以下、この機能を「ミュート」といい、この機能を利用（設定）することをミュートするという）、参加者が、他の特定の参加者のメディアを受信できなくする機能（以下、この機能を「デフン」といい、この機能を利用（設定）することをデフンするという）、参加者が、受信するメディアの発信者を制限する機能（以下、この機能を「セレクト」といい、この機能を利用（設定）することをセレクトするという）、特定の受信者に特定の参加者が発信したメディアだけを受信させる機能（以下、この機能を「アテンド」といい、この機能を利用（設定）することをアテンドするという）などを、それぞれ設定することができるとより好ましい。
【００１１】
しかしながら、このような複数の設定を各参加者がそれぞれ設定した場合、メディアサーバが、それぞれの設定に応じてメディアの送受信をコントロールすることは容易ではないという問題があった。さらに、マルチメディア会議システムにおいて、上述したプライバシー設定をリアルタイムで判断して迅速に設定を切り替えることが望ましいが、そのような迅速な設定変更・設定判断をマルチメディア会議において実現することは容易ではないという問題があった。
【００１２】
本発明は上記問題に鑑みてなされたものであり、参加者が会議におけるプライバシーを確保するために、参加者に対して複数のプライバシー設定を行うことができ、各参加者により設定されたプライバシー設定に基づいて会議全体のメディアの送受信設定を迅速に判断し、各参加者のメディアの送受信を迅速に制御することが可能なマルチメディア会議システム、アプリケーションサーバ、混合パターン決定方法および混合パターン決定用プログラムを提供することを課題とする。
【課題を解決するための手段】
【００１３】
上記課題を解決するために、本発明に係るマルチメディア会議システムは、複数のクライアント端末より発信されるストリームメディアをメディアサーバで受信し、受信された該ストリームメディアを前記メディアサーバで混合して前記各クライアント端末に送信するマルチメディア会議システムであって、前記メディアサーバにおいて混合される前記ストリームメディアの混合パターンを決定するアプリケーションサーバを有し、前記クライアント端末は、特定のクライアント端末を指定することにより、当該クライアント端末におけるストリームメディアの送受信要求を設定することができ、前記アプリケーションサーバは、前記クライアント端末において設定された送受信要求に基づいて、前記混合パターンを決定し、前記メディアサーバは、前記アプリケーションサーバにおいて決定された前記混合パターンに基づいて、前記クライアント端末より受信した前記ストリームメディアを混合して、前記送受信要求を満たし得るストリームメディアを各クライアント端末に送信することを特徴とする。
【００１４】
このように、アプリケーションサーバが、クライアント端末において設定された送受信要求に基づいて混合パターンを決定し、メディアサーバが、アプリケーションサーバにおいて決定された混合パターンに基づいてストリームメディアを混合して、送受信要求を満たし得るストリームメディアを各クライアント端末に送信するため、クライアント端末では、クライアント端末毎に設定された送受信要求を満し得るストリームメディアを受信することが可能となる。
【００１５】
例えば、上述したマルチメディア会議システムにおいて、一のクライアント端末に自分のストリームメディアを受信させたくない場合、自分に該当するクライアント端末は、一のクライアント端末を指定して自分のストリームメディアを受信させないように希望する送受信要求を設定することができる。この送受信要求は、クライアント端末毎にそれぞれ異なった設定となっているので、ストリームメディアの混合を行っているメディアサーバが、それぞれの送受信要求の内容を判断して混合方法を変更する処理を行うと、処理負担の増大により円滑なストリームメディアの発信（配信）ができなくなる恐れがある。このため、アプリケーションサーバにおいて、各クライアント端末の送受信要求を受信してその内容を検討し、メディアサーバにおけるストリームメディアの混合方法を混合パターンとして決定することにより、メディアサーバにおける処理負担を低減させることができるとともに、メディアサーバにおける混合処理の変更を迅速かつ確実に行うことが可能となる。
【００１６】
また、本発明に係るマルチメディア会議システムにおいて、前記送受信要求を設定するクライアント端末Ｚは、該クライアント端末Ｚにより指定された特定のクライアント端末Ｘが、前記クライアント端末に対してストリームメディアを発信することを制限する機能を表すミュートと、前記クライアント端末Ｚが受信するストリームメディアを、指定された前記特定のクライアント端末Ｘにより発信されたストリームメディアのみとし、他のクライアント端末Ｙにより発信されたストリームメディアの受信を制限する機能を表すセレクトとを、前記送受信要求として設定することができ、前記アプリケーションサーバは、（１）前記クライアント端末Ｘがミュートされている場合と、（２）前記クライアント端末Ｘがミュートされず、かつ、前記クライアント端末Ｙがセレクトされ、かつ、前記クライアント端末Ｘがセレクトされていない場合とに、前記クライアント端末Ｚにおいて前記クライアント端末Ｘの発信したストリームメディアを受信することが不可能であると判断して前記混合パターンを決定するものであってもよい。
【００１７】
さらに、本発明に係るアプリケーションサーバは、複数のクライアント端末より受信したストリームメディアをメディアサーバで混合して前記クライアント端末に送信する処理に用いられる前記ストリームメディアの混合パターンを決定するアプリケーションサーバであって、前記クライアント端末において特定のクライアント端末を指定することにより設定されたストリームメディアの送受信要求を、前記クライアント端末より受信する送受信要求受信手段と、前記クライアント端末において設定された送受信要求に基づいて、前記混合パターンを決定する混合パターン決定手段と、決定された前記混合パターンを前記メディアサーバに送信する送信手段とを有し、前記混合パターン決定手段は、クライアント端末Ｚにより指定された特定のクライアント端末Ｘが、前記クライアント端末に対してストリームメディアを発信することを制限する機能を表すミュートと、前記クライアント端末Ｚが受信するストリームメディアを、指定された前記特定のクライアント端末Ｘにより発信されたストリームメディアのみとし、他のクライアント端末Ｙにより発信されたストリームメディアの受信を制限する機能を表すセレクトとを、前記送受信要求より判断し、（１）前記クライアント端末Ｘがミュートされている場合と、（２）前記クライアント端末Ｘがミュートされず、かつ、前記クライアント端末Ｙがセレクトされ、かつ、前記クライアント端末Ｘがセレクトされていない場合とに、前記クライアント端末Ｚにおいて前記クライアント端末Ｘの発信したストリームメディアを受信することが不可能であると判断して前記混合パターンを決定することを特徴とする。
【００１８】
また、本発明に係る混合パターン決定方法は、複数のクライアント端末より受信したストリームメディアをメディアサーバで混合して前記クライアント端末に送信する処理に用いられる前記ストリームメディアの混合パターンを、アプリケーションサーバにおいて決定する混合パターン決定方法であって、前記クライアント端末において特定のクライアント端末を指定することにより設定されたストリームメディアの送受信要求を、送受信要求受信手段が前記クライアント端末より受信する送受信要求受信ステップと、前記クライアント端末において設定された送受信要求に基づいて、混合パターン決定手段が前記混合パターンを決定する混合パターン決定ステップと、決定された前記混合パターンを、送信手段が前記メディアサーバに送信する送信ステップとを有し、前記混合パターン決定ステップにおいて、前記混合パターン決定手段が、クライアント端末Ｚにより指定された特定のクライアント端末Ｘが、前記クライアント端末に対してストリームメディアを発信することを制限する機能を表すミュートと、前記クライアント端末Ｚが受信するストリームメディアを、指定された前記特定のクライアント端末Ｘにより発信されたストリームメディアのみとし、他のクライアント端末Ｙにより発信されたストリームメディアの受信を制限する機能を表すセレクトとを、前記送受信要求より判断する要求内容判断ステップと、前記混合パターン決定手段が、前記要求内容判断ステップにおいて判断された要求内容に基づいて、（１）前記クライアント端末Ｘがミュートされている場合と、（２）前記クライアント端末Ｘがミュートされず、かつ、前記クライアント端末Ｙがセレクトされ、かつ、前記クライアント端末Ｘがセレクトされていない場合とに、前記クライアント端末Ｚにおいて前記クライアント端末Ｘの発信したストリームメディアを受信することが不可能であると判断して前記混合パターンを決定する混合パターン判断ステップとを有することを特徴とする。
【００１９】
さらに、本発明に係る混合パターン決定用プログラムは、複数のクライアント端末より受信したストリームメディアをメディアサーバで混合して前記クライアント端末に送信する処理に用いられる前記ストリームメディアの混合パターンを、アプリケーションサーバにおいて決定する混合パターン決定用プログラムであって、前記アプリケーションサーバのコンピュータに、前記クライアント端末において特定のクライアント端末を指定することにより設定されたストリームメディアの送受信要求を、前記クライアント端末より受信する送受信要求受信機能と、前記クライアント端末において設定された送受信要求に基づいて前記混合パターンを決定する混合パターン決定機能と、決定された前記混合パターンを、前記メディアサーバに送信する送信機能とを実現させ、前記混合パターン決定機能において、前記コンピュータに、クライアント端末Ｚにより指定された特定のクライアント端末Ｘが、前記クライアント端末に対してストリームメディアを発信することを制限する機能を表すミュートと、前記クライアント端末Ｚが受信するストリームメディアを、指定された前記特定のクライアント端末Ｘにより発信されたストリームメディアのみとし、他のクライアント端末Ｙにより発信されたストリームメディアの受信を制限する機能を表すセレクトとを、前記送受信要求より判断させる要求内容判断機能と、該要求内容判断機能により判断された要求内容に基づいて、（１）前記クライアント端末Ｘがミュートされている場合と、（２）前記クライアント端末Ｘがミュートされず、かつ、前記クライアント端末Ｙがセレクトされ、かつ、前記クライアント端末Ｘがセレクトされていない場合とに、前記クライアント端末Ｚにおいて前記クライアント端末Ｘの発信したストリームメディアを受信することが不可能であると判断させて前記混合パターンを決定させる混合パターン判断機能とを実現させるための混合パターン決定用プログラムであることを特徴とする。
【００２０】
上述したように、本発明に係るマルチメディア会議システム、アプリケーションサーバ、混合パターン決定方法および混合パターン決定用プログラムにおいて、複数のクライアント端末の内の一のクライアント端末をクライアント端末Ｚ、当該クライアント端末Ｚが設定する送受信要求において要求の対象とする特定のクライアント端末をクライアント端末Ｘ、その他のクライアント端末をクライアント端末Ｙとすると、クライアント端末Ｚは、クライアント端末Ｘによるクライアント端末Ｚへのストリームメディアの発信を制限させる機能を表すミュートと、クライアント端末Ｚが受信するストリームメディアを、クライアント端末Ｘが発信したストリームメディアのみとし、他のクライアント端末Ｙが発信したストリームメディアを受信することを制限する機能を表すセレクトとを送受信要求として設定することができる。
【００２１】
アプリケーションサーバでは、送受信要求よりミュートとセレクトとを判断し、ミュートとセレクトとの対象となったクライアント端末の組み合わせに基づいて、クライアント端末Ｘの発信したストリームメディアがクライアント端末Ｚにおいて受信不可能であるか否かの判断を行い、前記混合パターンを決定することができる。
【００２２】
ここで、クライアント端末Ｘの発信したストリームメディアがクライアント端末Ｚにおいて受信不可能である場合とは、まず、（１）に示すクライアント端末Ｘがミュートされている場合が該当する。クライアント端末Ｚによりクライアント端末Ｘがミュートされている場合には、ミュート機能により、クライアント端末Ｘにおけるクライアント端末Ｚへのストリームメディアの発信が制限されるため、クライアント端末Ｚでは、クライアント端末Ｘの発信したストリームメディアを受信することができない。
【００２３】
また、（２）に示すように、クライアント端末Ｘがミュートされず、かつ、クライアント端末Ｙがセレクトされ、かつ、クライアント端末Ｘがセレクトされていない場合にも、クライアント端末Ｘの発信したストリームメディアがクライアント端末Ｚにおいて受信不可能となる。
【００２４】
ここで、セレクト機能とは、上述したように、クライアント端末Ｚがクライアント端末Ｘを指定する場合において、クライアント端末Ｚが受信するストリームメディアを、クライアント端末Ｘが発信したストリームメディアのみとし、他のクライアント端末Ｙが発信したストリームメディアを受信することを制限する機能を意味する。
【００２５】
従って、クライアント端末Ｚによりクライアント端末Ｘがミュートされず、クライアント端末Ｘにおけるクライアント端末Ｚへのストリームメディアの発信が制限されない場合であっても、クライアント端末Ｚが他のクライアント端末Ｙをセレクトした場合には、クライアント端末Ｚにおいて受信可能なストリームメディアが、クライアント端末Ｙの発信したストリームメディアのみとなってしまい、クライアント端末Ｚにおいてクライアント端末Ｘが発信したストリームメディアを受信することが制限されてしまう恐れがある。
【００２６】
このため、クライアント端末Ｚがクライアント端末Ｙをセレクトした場合には、クライアント端末Ｚによりクライアント端末Ｘがセレクトされたか否かを判断する。クライアント端末Ｚがクライアント端末Ｙをセレクトした場合において、クライアント端末Ｚがクライアント端末Ｘをセレクトした場合には、クライアント端末Ｚは、クライアント端末Ｙのストリームメディアだけでなくクライアント端末Ｘのストリームメディアをも受信することができるので、クライアント端末Ｚにおいて、クライアント端末Ｘの発信したストリームメディアを受信することが可能となる。一方で、クライアント端末Ｚがクライアント端末Ｙをセレクトした場合において、クライアント端末Ｚがクライアント端末Ｘをセレクトしなかった場合には、クライアント端末Ｚは、クライアント端末Ｙのストリームメディアだけしか受信することができないので、クライアント端末Ｚにおいて、クライアント端末Ｘの発信したストリームメディアを受信することが不可能となる。
【００２７】
アプリケーションサーバでは、上述した（１）および（２）の判断条件を、すべてのクライアント端末Ｙについて適用することにより、クライアント端末毎の送受信要求に基づいて、クライアント端末Ｘの発信したストリームメディアがクライアント端末Ｚにおいて受信不可能であるか否かの判断を迅速に行い、一のクライアント端末より受信したストリームメディアをいずれのクライアント端末に送信するかを示す混合パターンを決定することが可能となる。また、アプリケーションサーバでは、上述した条件判断に基づいて混合パターンを決定するため、クライアント端末から異なるタイミングで送受信要求を受信した場合であっても、遅滞なく混合パターンの修正を行うことができ、メディアサーバにおけるストリームメディアの混合を適切に行うことが可能となる。
【００２８】
また、上述したマルチメディア会議システムは、前記（２）に示したクライアント端末Ｘがミュートされていない場合において、前記アプリケーションサーバが、前記クライアント端末Ｘと前記クライアント端末Ｙとの両方が前記クライアント端末Ｚであるかあるいは両方が前記クライアント端末Ｚでない場合にのみ、前記クライアント端末Ｙがセレクトされているか否か、および、前記クライアント端末Ｘがセレクトされているか否かを判断し、前記クライアント端末Ｘと前記クライアント端末Ｙとの両方が前記クライアント端末Ｚであるかあるいは両方が前記クライアント端末Ｚでなく、かつ、前記クライアント端末Ｙがセレクトされ、かつ、前記クライアント端末Ｘがセレクトされていない場合に、前記クライアント端末Ｚにおいて前記クライアント端末Ｘの発信したストリームメディアを受信することが不可能であると判断して前記混合パターンを決定するものであってもよい。
【００２９】
さらに、上述したアプリケーションサーバは、前記（２）に示したクライアント端末Ｘがミュートされていない場合において、前記混合パターン決定手段が、前記クライアント端末Ｘと前記クライアント端末Ｙとの両方が前記クライアント端末Ｚであるかあるいは両方が前記クライアント端末Ｚでない場合にのみ、前記クライアント端末Ｙがセレクトされているか否か、および、前記クライアント端末Ｘがセレクトされているか否かを判断し、前記クライアント端末Ｘと前記クライアント端末Ｙとの両方が前記クライアント端末Ｚであるかあるいは両方が前記クライアント端末Ｚでなく、かつ、前記クライアント端末Ｙがセレクトされ、かつ、前記クライアント端末Ｘがセレクトされていない場合に、前記クライアント端末Ｚにおいて前記クライアント端末Ｘの発信したストリームメディアを受信することが不可能であると判断して前記混合パターンを決定するものであってもよい。
【００３０】
また、上述した混合パターン決定方法は、前記混合パターン判断ステップにおいて、前記混合パターン決定手段が、前記（２）に示したクライアント端末Ｘがミュートされていない場合であって、前記クライアント端末Ｘと前記クライアント端末Ｙとの両方が前記クライアント端末Ｚであるかあるいは両方が前記クライアント端末Ｚでない場合にのみ、前記クライアント端末Ｙがセレクトされているか否か、および、前記クライアント端末Ｘがセレクトされているか否かを判断し、前記クライアント端末Ｘと前記クライアント端末Ｙとの両方が前記クライアント端末Ｚであるかあるいは両方が前記クライアント端末Ｚでなく、かつ、前記クライアント端末Ｙがセレクトされ、かつ、前記クライアント端末Ｘがセレクトされていない場合に、前記クライアント端末Ｚにおいて前記クライアント端末Ｘの発信したストリームメディアを受信することが不可能であると判断して前記混合パターンを決定するものであってもよい。
【００３１】
さらに、上述した混合パターン決定用プログラムは、前記混合パターン判断機能において、前記コンピュータに、前記（２）に示したクライアント端末Ｘがミュートされていない場合であって、前記クライアント端末Ｘと前記クライアント端末Ｙとの両方が前記クライアント端末Ｚであるかあるいは両方が前記クライアント端末Ｚでない場合にのみ、前記クライアント端末Ｙがセレクトされているか否か、および、前記クライアント端末Ｘがセレクトされているか否かを判断させ、前記クライアント端末Ｘと前記クライアント端末Ｙとの両方が前記クライアント端末Ｚであるかあるいは両方が前記クライアント端末Ｚでなく、かつ、前記クライアント端末Ｙがセレクトされ、かつ、前記クライアント端末Ｘがセレクトされていない場合に、前記クライアント端末Ｚにおいて前記クライアント端末Ｘの発信したストリームメディアを受信することが不可能であると判断させて前記混合パターンを決定させることを実現させるための混合パターン決定用プログラムであってもよい。
【００３２】
上述したように、本発明に係るマルチメディア会議システム、アプリケーションサーバ、混合パターン決定方法および混合パターン決定用プログラムでは、（２）に示したクライアント端末Ｘがミュートされていない場合であって、クライアント端末Ｘとクライアント端末Ｙとの両方がクライアント端末Ｚであるかあるいは両方がクライアント端末Ｚでない場合にのみ、クライアント端末Ｙがセレクトされているか否か、および、クライアント端末Ｘがセレクトされているか否かを判断し、クライアント端末Ｘとクライアント端末Ｙとの両方がクライアント端末Ｚであるかあるいは両方がクライアント端末Ｚでなく、かつ、クライアント端末Ｙがセレクトされ、かつ、クライアント端末Ｘがセレクトされていない場合に、クライアント端末Ｚにおいてクライアント端末Ｘの発信したストリームメディアを受信することが不可能であると判断して混合パターンを決定する。
【００３３】
例えば、クライアント端末Ｘとクライアント端末Ｙとの両方が前記クライアント端末Ｚでない場合、クライアント端末Ｚがクライアント端末Ｘをセレクトすることにより、クライアント端末Ｚにおいて受信可能なストリームメディアは、クライアント端末Ｘにより発信されたストリームメディアのみとなり、クライアント端末Ｚにおいてクライアント端末Ｙにより発信されたストリームメディアを受信することが制限される。また、同様に、クライアント端末Ｚがクライアント端末Ｙをセレクトすることにより、クライアント端末Ｚにおいて受信可能なストリームメディアは、クライアント端末Ｙにより発信されたストリームメディアのみとなり、クライアント端末Ｚにおいてクライアント端末Ｘにより発信されたストリームメディアを受信することが制限される。
【００３４】
しかしながら、ストリームメディアの発信者が自分自身であり、自分自身の発信するストリームメディアの受信者も自分である場合には、自分が他のクライアント端末をセレクトしているか否かにかかわらず、自分が発信したストリームメディアを自分自身で受信することができるようにすることが望ましい。つまり、自分自身をストリームメディアの受信者としてとらえた場合には、セレクト機能による制限が行われない構成とすることが望まれる。また、自分自身でない他のクライアント端末に対してセレクトを行った場合であっても、自分自身を表す他のクライアント端末により発信されたストリームメディアは、自分自身において受信できるようにすることが好ましい。
【００３５】
例えば、マルチメディア会議システムに参加する参加者は、複数のクライアント端末（本実施の形態においては複数のアバター）を操作する場合もあり得るため、異なるクライアント端末がそれぞれ参加者自身を表す場合もあり、また自分自身を表すクライアント端末は、それぞれ異なった環境においてストリームメディアの発信および受信を行っている場合があり得る。このように、同一の参加者が複数のクライアント端末を操作した場合であっても、異なる環境における自分が発信したストリームメディアが自分自身を対象とするセレクト機能により制限されず、また、他人を対象としたセレクト機能により、自分自身を表す異なるクライアント端末により発信されたストリームメディアを自分自身において受信する際に制限されない設定にすることがより好ましいと言える。
【００３６】
つまり、クライアント端末Ｘがクライアント端末Ｚ自身であって、クライアント端末Ｙがクライアント端末Ｚ自身でない場合に、クライアント端末Ｚがクライアント端末Ｙをセレクトしても、クライアント端末Ｘは自分自身のストリームメディアであるクライアント端末Ｚのストリームメディアを受信することができように設定することが望ましい。従って、クライアント端末Ｘがクライアント端末Ｚ自身であって、クライアント端末Ｙがクライアント端末Ｚ自身でない場合には、クライアント端末Ｙのセレクトの有無により、クライアント端末Ｚにおいてクライアント端末Ｘの発信したストリームメディアを受信することができるか否かに影響されないようにすることが望ましい。
【００３７】
一方で、クライアント端末Ｘがクライアント端末Ｚ自身でなく、クライアント端末Ｙがクライアント端末Ｚ自身である場合に、クライアント端末Ｚが自分自身であるクライアント端末Ｙをセレクトしても、クライアント端末Ｙのセレクト機能は、自分自身に対して機能しないように設定することが望ましい。従って、クライアント端末Ｘがクライアント端末Ｚ自身でなく、クライアント端末Ｙがクライアント端末Ｚ自身である場合には、クライアント端末Ｙのセレクトの有無により、クライアント端末Ｚにおいてクライアント端末Ｘの発信したストリームメディアを受信することができるか否かに影響されないようにすることが望ましい。
【００３８】
従って、（２）に示したクライアント端末Ｘがミュートされていない場合において、クライアント端末Ｘとクライアント端末Ｙとの両方がクライアント端末Ｚであるかあるいは両方がクライアント端末Ｚでない場合にのみ、クライアント端末Ｙがセレクトされているか否か、および、クライアント端末Ｘがセレクトされているか否かを判断する構成にすることにより、クライアント端末Ｘまたはクライアント端末Ｙのいずれか一方のみがクライアント端末Ｚである場合には、クライアント端末Ｚにおいてクライアント端末Ｘの発信したストリームメディアを受信することが不可能であるか否かの判断に影響を及ぼさないようにすることが可能となる。
【００３９】
一方で、クライアント端末Ｘがクライアント端末Ｚ自身であり、かつ、クライアント端末Ｙがクライアント端末Ｚ自身である場合であっても、上述したように、クライアント端末Ｘの環境とクライアント端末Ｙの環境とは必ずしも一致するものではない。このため、クライアント端末Ｘおよびクライアント端末Ｙがクライアント端末Ｚ自身であって、結果として自分自身を示す発信源が複数存在する場合には、参加者がそれらの発信源を明示的に選択することにより、自分自身において受信可能なストリームメディアを選択（決定）することができるようにすることが好ましい。
【００４０】
従って、（２）に示したクライアント端末Ｘがミュートされていない場合において、クライアント端末Ｘとクライアント端末Ｙとの両方がクライアント端末Ｚである場合に、クライアント端末Ｙがセレクトされているか否か、および、クライアント端末Ｘがセレクトされているか否かを判断する構成にすることにより、クライアント端末Ｙがセレクトされている場合には、クライアント端末Ｘが明示的にセレクトされていなければ、クライアント端末Ｚにおいて受信可能なストリームメディアがクライアント端末Ｙにより発信されたストリームメディアのみに制限されてしまい、クライアント端末Ｘにより発信されたストリームメディアを、クライアント端末Ｚにおいて受信することができなくなる。
【００４１】
一方で、クライアント端末Ｙがセレクトされていない場合には、クライアント端末Ｚにおいて受信可能なストリームメディアは他のクライアント端末Ｙにより発信されたストリームメディアによって制限されることがないため、クライアント端末Ｘにより発信されたストリームメディアを、クライアント端末Ｚにおいて受信することが可能となる。
【００４２】
さらに、クライアント端末Ｙがセレクトされており、かつ、クライアント端末Ｘも明示的にセレクトされる場合には、クライアント端末Ｚにおいて受信可能なストリームメディアが、クライアント端末Ｙにより発信されたストリームメディアと、クライアント端末Ｘにより発信されたストリームメディアとになるため、クライアント端末Ｘにより発信されたストリームメディアを明示的に選択し、クライアント端末Ｚにおいて受信することが可能となる。
【００４３】
なお、クライアント端末Ｘがクライアント端末Ｚ自身でなく、かつ、クライアント端末Ｙがクライアント端末Ｚ自身でない場合には、クライアント端末Ｚにおいてクライアント端末Ｘの発信したストリームメディアを受信することができるか否かは、クライアント端末Ｙに対するセレクトの状態によって左右されることになる。
【００４４】
従って、クライアント端末Ｚがクライアント端末Ｙをセレクトしない場合には、クライアント端末Ｚが受信するストリームメディアがクライアント端末Ｙの発信したストリームメディアのみに限定されることがないため、クライアント端末Ｘがミュートされていなければ、クライアント端末Ｘの発信したストリームメディアをクライアント端末Ｚにおいて受信することができる。
【００４５】
一方で、クライアント端末Ｚがクライアント端末Ｙをセレクトした場合には、クライアント端末Ｚが受信するストリームメディアがクライアント端末Ｙの発信したストリームメディアのみとなってしまい、そのままでは、クライアント端末Ｘの発信したストリームメディアを、クライアント端末Ｚにおいて受信することができない。そのため、クライアント端末Ｚがクライアント端末Ｙをセレクトした場合には、クライアント端末Ｚがクライアント端末Ｘをセレクトすることにより、クライアント端末Ｚにおいてクライアント端末Ｘのストリームメディアを受信することが可能となり、クライアント端末Ｚがクライアント端末Ｘをセレクトしない場合には、クライアント端末Ｚにおいてクライアント端末Ｘのストリームメディアを受信することが不可能となる。
【００４６】
このように、アプリケーションサーバにおいて、（２）に示したクライアント端末Ｘがミュートされていない場合であって、クライアント端末Ｘとクライアント端末Ｙとの両方がクライアント端末Ｚであるかあるいは両方がクライアント端末Ｚでない場合にのみ、クライアント端末Ｙがセレクトされているか否か、および、クライアント端末Ｘがセレクトされているか否かを判断する構成とすることにより、ストリームメディアの発信者が自分自身であり、自分自身の発信するストリームメディアの受信者も自分自身である場合に、自分が他のクライアント端末をセレクトしているか否かにかかわらず、自分のストリームメディアを受信することができる。また、自分自身でない他のクライアント端末に対してセレクトを行った場合であっても、自分自身を表す他のクライアント端末により発言されたストリームメディアを、自分自身において受信できるようにすることが可能となる。
【００４７】
さらに、（２）に示したクライアント端末Ｘがミュートされていない場合であって、クライアント端末Ｘとクライアント端末Ｙとの両方がクライアント端末Ｚである場合に、クライアント端末Ｙがセレクトされているか否か、および、クライアント端末Ｘがセレクトされているか否かを判断する構成とすることにより、自分自身が複数の音源となる場合に参加者がそれらを明示的に選択することによって、自分自身において受信可能なストリームメディアを明示的に決定（選択）することができる。
【００４８】
また、上述したマルチメディア会議システムにおいて、前記送受信要求を設定するクライアント端末Ｚは、該クライアント端末Ｚにより指定された特定のクライアント端末Ｘにおいて、前記クライアント端末Ｚにより発信されたストリームメディアの受信を制限する機能を表すデフンと、前記クライアント端末Ｚが発信するストリームメディアを、指定された前記特定のクライアント端末Ｘのみが受信でき、前記クライアント端末Ｚが発信するストリームメディアを、他のクライアント端末Ｙにおいて受信することを制限する機能を表すアテンドとを、前記送受信要求として設定することができ、前記アプリケーションサーバは、（３）前記クライアント端末Ｘがデフンされている場合と、（４）前記クライアント端末Ｘがデフンされず、かつ、前記クライアント端末Ｙがアテンドされ、かつ、前記クライアント端末Ｘがアテンドされていない場合とに、前記クライアント端末Ｘにおいて前記クライアント端末Ｚの発信したストリームメディアを受信することが不可能であると判断して前記混合パターンを決定するものであってもよい。
【００４９】
さらに、本発明に係るアプリケーションサーバは、複数のクライアント端末より受信したストリームメディアをメディアサーバで混合して前記クライアント端末に送信する処理に用いられる前記ストリームメディアの混合パターンを決定するアプリケーションサーバであって、前記クライアント端末において特定のクライアント端末を指定することにより設定されたストリームメディアの送受信要求を、前記クライアント端末より受信する送受信要求受信手段と、前記クライアント端末において設定された送受信要求に基づいて、前記混合パターンを決定する混合パターン決定手段と、決定された前記混合パターンを前記メディアサーバに送信する送信手段とを有し、前記混合パターン決定手段は、クライアント端末Ｚにより指定された特定のクライアント端末Ｘにおいて、前記クライアント端末Ｚにより発信されたストリームメディアの受信を制限する機能を表すデフンと、前記クライアント端末Ｚが発信するストリームメディアを、指定された前記特定のクライアント端末Ｘのみが受信でき、前記クライアント端末Ｚが発信するストリームメディアを、他のクライアント端末Ｙにおいて受信することを制限する機能を表すアテンドとを、前記送受信要求より判断し、（３）前記クライアント端末Ｘがデフンされている場合と、（４）前記クライアント端末Ｘがデフンされず、かつ、前記クライアント端末Ｙがアテンドされ、かつ、前記クライアント端末Ｘがアテンドされていない場合とに、前記クライアント端末Ｘにおいて前記クライアント端末Ｚの発信したストリームメディアを受信することが不可能であると判断して前記混合パターンを決定することを特徴とする。
【００５０】
また、本発明に係る混合パターン決定方法は、複数のクライアント端末より受信したストリームメディアをメディアサーバで混合して前記クライアント端末に送信する処理に用いられる前記ストリームメディアの混合パターンを、アプリケーションサーバにおいて決定する混合パターン決定方法であって、前記クライアント端末において特定のクライアント端末を指定することにより設定されたストリームメディアの送受信要求を、送受信要求受信手段が前記クライアント端末より受信する送受信要求受信ステップと、前記クライアント端末において設定された送受信要求に基づいて、混合パターン決定手段が前記混合パターンを決定する混合パターン決定ステップと、決定された前記混合パターンを、送信手段が前記メディアサーバに送信する送信ステップとを有し、前記混合パターン決定ステップにおいて、前記混合パターン決定手段が、クライアント端末Ｚにより指定された特定のクライアント端末Ｘにおいて、前記クライアント端末Ｚにより発信されたストリームメディアの受信を制限する機能を表すデフンと、前記クライアント端末Ｚが発信するストリームメディアを、指定された前記特定のクライアント端末Ｘのみが受信でき、前記クライアント端末Ｚが発信するストリームメディアを、他のクライアント端末Ｙにおいて受信することを制限する機能を表すアテンドとを、前記送受信要求より判断する要求内容判断ステップと、前記混合パターン決定手段が、前記要求内容判断ステップにおいて判断された要求内容に基づいて、（３）前記クライアント端末Ｘがデフンされている場合と、（４）前記クライアント端末Ｘがデフンされず、かつ、前記クライアント端末Ｙがアテンドされ、かつ、前記クライアント端末Ｘがアテンドされていない場合とに、前記クライアント端末Ｘにおいて前記クライアント端末Ｚの発信したストリームメディアを受信することが不可能であると判断して前記混合パターンを決定する混合パターン判断ステップとを有することを特徴とする。
【００５１】
さらに、本発明に係る混合パターン決定用プログラムは、複数のクライアント端末より受信したストリームメディアをメディアサーバで混合して前記クライアント端末に送信する処理に用いられる前記ストリームメディアの混合パターンを、アプリケーションサーバにおいて決定する混合パターン決定用プログラムであって、前記アプリケーションサーバのコンピュータに、前記クライアント端末において特定のクライアント端末を指定することにより設定されたストリームメディアの送受信要求を、前記クライアント端末より受信する送受信要求受信機能と、前記クライアント端末において設定された送受信要求に基づいて前記混合パターンを決定する混合パターン決定機能と、決定された前記混合パターンを、前記メディアサーバに送信する送信機能とを実現させ、前記混合パターン決定機能において、前記コンピュータに、クライアント端末Ｚにより指定された特定のクライアント端末Ｘにおいて、前記クライアント端末Ｚにより発信されたストリームメディアの受信を制限する機能を表すデフンと、前記クライアント端末Ｚが発信するストリームメディアを、指定された前記特定のクライアント端末Ｘのみが受信でき、前記クライアント端末Ｚが発信するストリームメディアを、他のクライアント端末Ｙにおいて受信することを制限する機能を表すアテンドとを、前記送受信要求より判断させる要求内容判断機能と、該要求内容判断機能により判断された要求内容に基づいて、（３）前記クライアント端末Ｘがデフンされている場合と、（４）前記クライアント端末Ｘがデフンされず、かつ、前記クライアント端末Ｙがアテンドされ、かつ、前記クライアント端末Ｘがアテンドされていない場合とに、前記クライアント端末Ｘにおいて前記クライアント端末Ｚの発信したストリームメディアを受信することが不可能であると判断させて前記混合パターンを決定させる混合パターン判断機能とを実現させるための混合パターン決定用プログラムであることを特徴とする。
【００５２】
上述したように、本発明に係るマルチメディア会議システム、アプリケーションサーバ、混合パターン決定方法および混合パターン決定用プログラムにおいて、複数のクライアント端末の内の一のクライアント端末をクライアント端末Ｚ、当該クライアント端末Ｚが設定する送受信要求において要求の対象とする特定のクライアント端末をクライアント端末Ｘ、その他のクライアント端末をクライアント端末Ｙとすると、クライアント端末Ｚは、クライアント端末Ｚにより指定された特定のクライアント端末Ｘがクライアント端末Ｚの発信したストリームメディアを受信することを制限する機能を表すデフンと、クライアント端末Ｚが発信するストリームメディアを、指定された前記特定のクライアント端末Ｘのみが受信でき、クライアント端末Ｚが発信するストリームメディアを他のクライアント端末Ｙにおいて受信することを制限する機能を表すアテンドとを、送受信要求として設定することができる。
【００５３】
アプリケーションサーバでは、送受信要求よりデフンとアテンドとを判断し、デフンとアテンドとの対象となったクライアント端末の組み合わせに基づいて、クライアント端末Ｚの発信したストリームメディアがクライアント端末Ｘにおいて受信不可能であるか否かの判断を行い、前記混合パターンを決定することができる。
【００５４】
ここで、クライアント端末Ｚの発信したストリームメディアがクライアント端末Ｘにおいて受信不可能である場合とは、まず、（３）に示すクライアント端末Ｘがデフンされている場合が該当する。クライアント端末Ｚによりクライアント端末Ｘがデフンされている場合には、デフン機能により、クライアント端末Ｚの発信したストリームメディアをクライアント端末Ｘにおいて受信することが制限されるため、クライアント端末Ｘでは、クライアント端末Ｚの発信したストリームメディアを受信することができない。
【００５５】
また、（４）に示すように、クライアント端末Ｘがデフンされず、かつ、他のクライアント端末Ｙがアテンドされ、かつ、前記クライアント端末Ｘがアテンドされていない場合にも、クライアント端末Ｚの発信したストリームメディアをクライアント端末Ｘにおいて受信することが不可能となる。
【００５６】
ここで、アテンド機能とは、上述したように、クライアント端末Ｚがクライアント端末Ｘを指定する場合において、クライアント端末Ｚが発信するストリームメディアをクライアント端末Ｘのみが受信でき、クライアント端末Ｚが発信するストリームメディアを他のクライアント端末Ｙにおいて受信することを制限する機能を意味する。
【００５７】
従って、クライアント端末Ｚによりクライアント端末Ｘがデフンされず、クライアント端末Ｘにおいてクライアント端末Ｚが発信したストリームメディアの受信が制限されない場合であっても、クライアント端末Ｚが他のクライアント端末Ｙをアテンドした場合には、クライアント端末Ｚが発信するストリームメディアを、クライアント端末Ｙのみで受信することができ、クライアント端末Ｘにおいてクライアント端末Ｚにより発信されたストリームメディアを受信することが制限されてしまう恐れがある。
【００５８】
このため、クライアント端末Ｚがクライアント端末Ｙをアテンドした場合には、クライアント端末Ｚによりクライアント端末Ｘがアテンドされたか否かを判断する。クライアント端末Ｚがクライアント端末Ｙをアテンドした場合において、クライアント端末Ｚがクライアント端末Ｘをアテンドした場合には、クライアント端末Ｚにおいて発信されたストリームメディアは、クライアント端末Ｙだけでなくクライアント端末Ｘにおいても受信することができるので、クライアント端末Ｘにおいて、クライアント端末Ｚの発信したストリームメディアを受信することが可能となる。一方で、クライアント端末Ｚがクライアント端末Ｙをアテンドした場合において、クライアント端末Ｚがクライアント端末Ｘをアテンドしなかった場合には、クライアント端末Ｚにより発信されたストリームメディアは、クライアント端末Ｙだけしか受信することができないので、クライアント端末Ｘにおいて、クライアント端末Ｚの発信したストリームメディアを受信することが不可能となる。
【００５９】
アプリケーションサーバでは、上述した（３）および（４）の判断条件を、すべてのクライアント端末Ｙについて適用することにより、クライアント端末毎の送受信要求に基づいて、クライアント端末Ｚの発信したストリームメディアがクライアント端末Ｘにおいて受信可能であるか否かの判断を迅速に行い、一のクライアント端末より受信したストリームメディアをいずれのクライアント端末に送信するかを示す混合パターンを決定することが可能となる。また、アプリケーションサーバでは、上述した条件判断に基づいて混合パターンを決定するため、クライアント端末から異なるタイミングで送受信要求を受信した場合であっても、遅滞なく混合パターンの修正を行うことができ、メディアサーバにおけるストリームメディアの混合を適切に行うことが可能となる。
【００６０】
また、マルチメディア会議システムは、前記（４）に示したクライアント端末Ｘがデフンされていない場合において、前記アプリケーションサーバが、前記クライアント端末Ｘと前記クライアント端末Ｙとの両方が前記クライアント端末Ｚであるかあるいは両方が前記クライアント端末Ｚでない場合にのみ、前記クライアント端末Ｙがアテンドされているか否か、および、前記クライアント端末Ｘがアテンドされているか否かを判断し、前記クライアント端末Ｘと前記クライアント端末Ｙとの両方が前記クライアント端末Ｚであるかあるいは両方が前記クライアント端末Ｚでなく、かつ、前記クライアント端末Ｙがアテンドされ、かつ、前記クライアント端末Ｘがアテンドされていない場合に、前記クライアント端末Ｘにおいて前記クライアント端末Ｚの発信したストリームメディアを受信することが不可能であると判断して前記混合パターンを決定するものであってもよい。
【００６１】
さらに、上述したアプリケーションサーバは、前記（４）に示したクライアント端末Ｘがデフンされていない場合において、前記混合パターン決定手段が、前記クライアント端末Ｘと前記クライアント端末Ｙとの両方が前記クライアント端末Ｚであるかあるいは両方が前記クライアント端末Ｚでない場合にのみ、前記クライアント端末Ｙがアテンドされているか否か、および、前記クライアント端末Ｘがアテンドされているか否かを判断し、前記クライアント端末Ｘと前記クライアント端末Ｙとの両方が前記クライアント端末Ｚであるかあるいは両方が前記クライアント端末Ｚでなく、かつ、前記クライアント端末Ｙがアテンドされ、かつ、前記クライアント端末Ｘがアテンドされていない場合に、前記クライアント端末Ｘにおいて前記クライアント端末Ｚの発信したストリームメディアを受信することが不可能であると判断して前記混合パターンを決定するものであってもよい。
【００６２】
また、上述した混合パターン決定方法は、前記混合パターン判断ステップにおいて、前記混合パターン決定手段が、前記（４）に示したクライアント端末Ｘがデフンされていない場合であって、前記クライアント端末Ｘと前記クライアント端末Ｙとの両方が前記クライアント端末Ｚであるかあるいは両方が前記クライアント端末Ｚでない場合にのみ、前記クライアント端末Ｙがアテンドされているか否か、および、前記クライアント端末Ｘがアテンドされているか否かを判断し、前記クライアント端末Ｘと前記クライアント端末Ｙとの両方が前記クライアント端末Ｚであるかあるいは両方が前記クライアント端末Ｚでなく、かつ、前記クライアント端末Ｙがアテンドされ、かつ、前記クライアント端末Ｘがアテンドされていない場合に、前記クライアント端末Ｘにおいて前記クライアント端末Ｚの発信したストリームメディアを受信することが不可能であると判断して前記混合パターンを決定するものであってもよい。
【００６３】
さらに、上述した混合パターン決定用プログラムは、前記混合パターン判断機能において、前記コンピュータに、前記（４）に示したクライアント端末Ｘがデフンされていない場合であって、前記クライアント端末Ｘと前記クライアント端末Ｙとの両方が前記クライアント端末Ｚであるかあるいは両方が前記クライアント端末Ｚでない場合にのみ、前記クライアント端末Ｙがアテンドされているか否か、および、前記クライアント端末Ｘがアテンドされているか否かを判断させ、前記クライアント端末Ｘと前記クライアント端末Ｙとの両方が前記クライアント端末Ｚであるかあるいは両方が前記クライアント端末Ｚでなく、かつ、前記クライアント端末Ｙがアテンドされ、かつ、前記クライアント端末Ｘがアテンドされていない場合に、前記クライアント端末Ｘにおいて前記クライアント端末Ｚの発信したストリームメディアを受信することが不可能であると判断させて前記混合パターンを決定させることを実現させるための混合パターン決定用プログラムであってもよい。
【００６４】
上述したように、本発明に係るマルチメディア会議システム、アプリケーションサーバ、混合パターン決定方法および混合パターン決定用プログラムでは、（４）に示したクライアント端末Ｘがデフンされていない場合であって、クライアント端末Ｘとクライアント端末Ｙとの両方がクライアント端末Ｚであるかあるいは両方がクライアント端末Ｚでない場合にのみ、クライアント端末Ｙがアテンドされているか否か、および、クライアント端末Ｘがアテンドされているか否かを判断し、クライアント端末Ｘとクライアント端末Ｙとの両方がクライアント端末Ｚであるかあるいは両方がクライアント端末Ｚでなく、かつ、クライアント端末Ｙがアテンドされ、かつ、クライアント端末Ｘがアテンドされていない場合に、クライアント端末Ｘにおいてクライアント端末Ｚの発信したストリームメディアを受信することが不可能であると判断して混合パターンを決定する。
【００６５】
例えば、クライアント端末Ｘとクライアント端末Ｙとの両方が前記クライアント端末Ｚでない場合、クライアント端末Ｚがクライアント端末Ｘをアテンドすることにより、クライアント端末Ｚにおいて発信されたストリームメディアは、クライアント端末Ｘのみで受信され、クライアント端末Ｙにおいて受信することが制限される。また、同様に、クライアント端末Ｚがクライアント端末Ｙをアテンドすることにより、クライアント端末Ｚにおいて発信されたストリームメディアは、クライアント端末Ｙのみで受信され、クライアント端末Ｘにおいて受信することが制限される。
【００６６】
しかしながら、ストリームメディアの発信者が自分自身であり、自分自身の発信するストリームメディアの受信も自分である場合には、自分が他のクライアント端末をアテンドしているか否かにかかわらず、自分が発信したストリームメディアを自分自身で受信することができるようにすることが望ましい。つまり、自分自身をストリームメディアの受信者としてとらえた場合には、アテンド機能による制限が行われない構成とすることが望まれる。また、自分自身でない他のクライアント端末に対してアテンドを行った場合であっても、自分自身を表す他のクライアント端末により発言されたストリームメディアは、自分自身において受信できるようにすることが好ましい。
【００６７】
例えば、マルチメディア会議システムに参加する参加者は、複数のクライアント端末（本実施の形態においては複数のアバター）を操作する場合もあり得るため、異なるクライアント端末がそれぞれ参加者自身を表す場合もあり、また自分自身を表すクライアント端末は、それぞれ異なった環境においてストリームメディアの発信および受信を行っている場合があり得る。このように、同一の参加者が複数のクライアント端末を操作した場合であっても、異なる環境における自分の発言が自分自身を対象とするアテンド機能により制限されず、また、他人を対象としたアテンド機能により、自分自身を表す異なるクライアント端末により発信されたストリームメディアを自分自身が受信する際に制限されない設定とすることがより好ましいと言える。
【００６８】
つまり、クライアント端末Ｘがクライアント端末Ｚ自身であって、クライアント端末Ｙがクライアント端末Ｚ自身でない場合に、クライアント端末Ｚがクライアント端末Ｙをアテンドしても、自分自身を表すクライアント端末Ｘにおいて自分自身を表すクライアント端末Ｚにより発信されたストリームメディアを受信することができるように設定することが望ましい。従って、クライアント端末Ｘがクライアント端末Ｚ自身であって、クライアント端末Ｙがクライアント端末Ｚ自身でない場合には、クライアント端末Ｙのアテンドの有無により、クライアント端末Ｚにおいて発信されたストリームメディアがクライアント端末Ｘにおいて受信できるか否かに影響されないようにすることが望ましい。
【００６９】
一方で、クライアント端末Ｘがクライアント端末Ｚ自身でなく、クライアント端末Ｙがクライアント端末Ｚ自身である場合に、クライアント端末Ｚが自分自身であるクライアント端末Ｙをアテンドしても、クライアント端末Ｙのアテンド機能は、自分自身に対して機能しないように設定することが望ましい。従って、クライアント端末Ｘがクライアント端末Ｚ自身でなく、クライアント端末Ｙがクライアント端末Ｚ自身である場合には、クライアント端末Ｙのアテンドの有無により、クライアント端末Ｚにおいて発信されたストリームメディアがクライアント端末Ｘにおいて受信できるか否かに影響されないようにすることが望ましい。
【００７０】
従って、（４）に示したクライアント端末Ｘがデフンされていない場合において、クライアント端末Ｘとクライアント端末Ｙとの両方がクライアント端末Ｚであるかあるいは両方がクライアント端末Ｚでない場合にのみ、クライアント端末Ｙがアテンドされているか否か、および、クライアント端末Ｘがアテンドされているか否かを判断する構成にすることにより、クライアント端末Ｘまたはクライアント端末Ｙのいずれか一方のみがクライアント端末Ｚである場合には、クライアント端末Ｚにおいて発信されたストリームメディアをクライアント端末Ｘで受信することが不可能であるか否かに影響を及ぼさないようにすることが可能となる。
【００７１】
一方で、クライアント端末Ｘがクライアント端末Ｚ自身であり、かつ、クライアント端末Ｙがクライアント端末Ｚ自身である場合であっても、上述したように、クライアント端末Ｘの環境とクライアント端末Ｙの環境とは必ずしも一致するものではない。このため、クライアント端末Ｘおよびクライアント端末Ｙがクライアント端末Ｚ自身であって、結果として、自分自身の発信したストリームメディアを受信する聴取者が自分自身でありかつ複数存在する場合には、参加者がそれらの聴取者を明示的に選択することにより、自分自身のストリームメディアを受信することが可能なクライアント端末を選択（決定）することができるようにすることが好ましい。
【００７２】
従って、（４）に示したクライアント端末Ｘがデフンされていない場合において、クライアント端末Ｘとクライアント端末Ｙとの両方がクライアント端末Ｚである場合に、クライアント端末Ｙがアテンドされているか否か、および、クライアント端末Ｘがアテンドされているか否かを判断する構成にすることにより、クライアント端末Ｙがアテンドされている場合には、クライアント端末Ｘが明示的にアテンドされていなければ、クライアント端末Ｚにおいて発信されたストリームメディアをクライアント端末Ｘにおいて受信することが制限されてしまい、クライアント端末Ｚにおいて発信されたストリームメディアを、クライアント端末Ｘにおいて受信することができなくなる。
【００７３】
一方で、クライアント端末Ｙがアテンドされていない場合には、クライアント端末Ｚにおいて発信されたストリームメディアは、他のクライアント端末Ｙにより発信されたストリームメディアによって制限されることがないため、クライアント端末Ｘにおいて、クライアント端末Ｚにより発信されたストリームメディアを受信することが可能となる。
【００７４】
さらに、クライアント端末Ｙがアテンドされており、かつ、クライアント端末Ｘも明示的にアテンドされる場合には、クライアント端末Ｚにおいて発信されたストリームメディアを、クライアント端末Ｙとクライアント端末Ｘとにおいて受信することができるため、クライアント端末Ｚにより発信されたストリームメディアを、クライアント端末Ｘにおいて受信することが可能となる。
【００７５】
なお、クライアント端末Ｘがクライアント端末Ｚ自身でなく、かつ、クライアント端末Ｙがクライアント端末Ｚ自身でない場合には、クライアント端末Ｚにおいて発信されたストリームメディアをクライアント端末Ｘで受信することができるか否かは、クライアント端末Ｙに対するアテンドの状態によって左右されることになる。
【００７６】
従って、クライアント端末Ｚがクライアント端末Ｙをアテンドしない場合には、クライアント端末Ｚにおいて発信されたストリームメディアの受信が、クライアント端末Ｙのみに制限されないため、クライアント端末Ｘがデフンされていなければ、クライアント端末Ｚにおいて発信したストリームメディアをクライアント端末Ｘで受信することができる。
【００７７】
一方で、クライアント端末Ｚがクライアント端末Ｙをアテンドした場合には、クライアント端末Ｚにおいて発信されたストリームメディアの受信が、クライアント端末Ｙのみにとなってしまい、そのままでは、クライアント端末Ｘにおいてクライアント端末Ｚのストリームメディアを受信することができない。そのため、クライアント端末Ｚがクライアント端末Ｙをアテンドした場合には、クライアント端末Ｚがクライアント端末Ｘをアテンドすることにより、クライアント端末Ｚにおいて発信されたストリームメディアを、クライアント端末Ｘで受信することが可能となり、クライアント端末Ｚがクライアント端末Ｘをアテンドしない場合には、クライアント端末Ｘにおいてクライアント端末Ｚのストリームメディアを受信することが不可能となる。
【００７８】
このように、アプリケーションサーバにおいて、（４）に示したクライアント端末Ｘがデフンされていない場合であって、クライアント端末Ｘとクライアント端末Ｙとの両方がクライアント端末Ｚであるかあるいは両方がクライアント端末Ｚでない場合にのみ、クライアント端末Ｙがアテンドされているか否か、および、クライアント端末Ｘがアテンドされているか否かを判断する構成とすることにより、ストリームメディアの発信者が自分自身であり、自分自身の発信するストリームメディアを受信する者も自分自身である場合には、自分自身が他のクライアント端末をアテンドしているか否かにかかわらず、自分のストリームメディアを受信することができる。また、自分自身でない他のクライアント端末に対してアテンドを行った場合であっても、自分自身を表す他のクライアント端末により発言されたストリームメディアを、自分自身において受信できるようにすることが可能となる。
【００７９】
さらに、（４）に示したクライアント端末Ｘがデフンされていない場合であって、クライアント端末Ｘとクライアント端末Ｙとの両方がクライアント端末Ｚである場合に、クライアント端末Ｙがアテンドされているか否か、および、クライアント端末Ｘがアテンドされているか否かを判断する構成とすることにより、自分自身が音源となる場合であって自分自身を表す受信者が複数存在する場合において、参加者がそれらの受信者を明示的に選択することにより、自分自身の発信したストリームメディアを受信することが可能なクライアント端末を、明示的に決定（選択）することができる。
【発明の効果】
【００８０】
本発明に係るマルチメディア会議システム、アプリケーションサーバ、混合パターン決定方法および混合パターン決定用プログラムでは、アプリケーションサーバが、クライアント端末において設定された送受信要求に基づいて混合パターンを決定し、メディアサーバが、アプリケーションサーバにおいて決定された前記混合パターンに基づいてストリームメディアを混合して、送受信要求を満たし得るストリームメディアを各クライアント端末に送信するため、クライアント端末では、クライアント端末毎に設定された送受信要求を満し得るストリームメディアを受信することが可能となる。
【００８１】
また、本発明に係るマルチメディア会議システム、アプリケーションサーバ、混合パターン決定方法および混合パターン決定用プログラムでは、アプリケーションサーバが、上述した（１）〜（４）の判断条件を、すべてのクライアント端末Ｙについて適用することにより、一のクライアント端末より受信したストリームメディアをいずれのクライアント端末に送信するかを示す混合パターンを決定することが可能となる。
【００８２】
さらにアプリケーションサーバでは、上述した条件判断に基づいて混合パターンを決定するため、クライアント端末から異なるタイミングで送受信要求を受信した場合であっても、遅滞なく混合パターンの修正を行うことができ、メディアサーバにおけるストリームメディアの混合を適切に行うことが可能となる。
【発明を実施するための最良の形態】
【００８３】
以下、本発明に係るマルチメディア会議システムについて、図面を用いて詳細に説明を行う。
【００８４】
マルチメディア会議システム１は、図１に示すように、メディアサーバ２と、アプリケーションサーバ３と、ＣＶＥ（Collaborative Virtual Environment：協調仮想空間）サーバ４と、クライアント端末５とにより概略構成されている。本実施の形態に係るマルチメディア会議システム１では、クライアント端末５を介して取得されたストリームデータ形式の音声データ（ストリームメディア）をメディアサーバ２で取得し、各クライアント端末５からのプライバシー設定の要求（送受信設定）に応じてアプリケーションサーバ３で音声データの混合処理内容（混合パターン）を決定し、メディアサーバ２で混合処理内容に応じて音声データを混合して、各クライアント端末５に音声データの発信（ストリーム配信）処理を行う。
【００８５】
クライアント端末５は、マルチメディア会議に参加する参加者が操作を行う情報端末を意味しており、具体的には、パーソナルコンピュータ、携帯電話、ＰＤＡ（Personal Digital Assistant、またはPersonal Data Assistance）等が該当する。また、クライアント端末５は、ネットを介して音声データを扱うことが可能な電話機などであってもよい。クライアント端末５は、アプリケーションサーバ３に対してセッションの開始、変更、終了などの操作を行う機能を有している。クライアント端末５によるセッション制御には、ＳＩＰ（Session Initiation Protocol：セッション確立プロトコル）が用いられている。
【００８６】
マルチメディア会議に参加する参加者は、会議に参加するために設けられるＳＩＰ用のＵＲＩ（Uniform Resource Identifier）を用いることにより、クライアント端末５からアプリケーションサーバ３にアクセスし、会議の参加、変更、終了の基本的な制御を行うことが可能となっている。参加者は、会議用ＵＲＩを、ｅ−ｍａｉｌを用いて取得するか、インスタント・メッセージを用いて取得するか、ウェブページにリンクされた情報を用いるか、または、非ＳＩＰ方式を用いて入手すること等により得ることが可能となっている。
【００８７】
クライアント端末５からアプリケーションサーバ３へのアクセスは、Ｘｐａｔｈ（XML Path Language：マークアップ言語ＸＭＬ（Extensible Markup Language）に準拠した文書の特定の部分を指定する言語構文）やＸＣＡＰ（XML Configuration Access Protocol：サーバ上のデータをクライアントから操作するためのプロトコル）を用いたＸＭＬデータベース（XMLを扱うための機能を持つデータベース）や、ＨＴＴＰ（Hypertext Transfer Protocol：ＷｅｂブラウザとＷｅｂサーバの間でコンテンツ送受信に用いられる通信プロトコル）を通して送信されるＪＰＦ（Java（登録商標） Plug-in Framework）／ＪＳＰ（Java（登録商標）Server Pages：ＨＴＭＬ内にJava（登録商標）のコードを埋め込んでおき、Ｗｅｂサーバで動的にＷｅｂページを生成してクライアントに返す技術）コマンドを用いることにより実現される。
【００８８】
また、クライアント端末５は、ＣＶＥサーバ４を介して、アプリケーションサーバ３に４種類のプライバシー設定の要求（送受信要求）を送信することが可能となっている。具体的には、後述する「ミュート」、「デフン」、「セレクト」、「アテンド」の４つの要求を送信することが可能となっている。なお、本実施の形態に係るマルチメディア会議システム１では、ＣＶＥサーバ４により構築される仮想空間においてアバター（仮想空間において参加者を視覚的に示した人形）を操作することにより、この４つの要求をアプリケーションサーバ３に送信する。
【００８９】
ＣＶＥサーバ４は、ＳＩＰの枠組みの中で仮想空間の形成を実現させるためのサーバである。ＣＶＥサーバ４は、ネットワーク上に（より詳細にはサーバ内に）仮想空間を形成し、形成された仮想空間において、各参加者によるアバターの操作を仮想的に実現させる機能を有している。各参加者は、クライアント端末５を用いてＣＶＥサーバ４にアクセスすることによって、仮想空間においてアバターを操作することができ、アバターの状態により視覚的にプライバシー設定を判断することが可能となる。
【００９０】
また、アプリケーションサーバ３には、アバターの操作情報を取得することが可能なＣＶＥクライアント４ａが設けられている。アプリケーションサーバ３は、ＣＶＥクライアント４ａを介して、参加者により操作されたアバターの動作に基づいて（または、参加者によるアバターの操作命令に基づいて）クライアント端末５毎のプライベート設定の要求（送受信要求）を判断する。このため、ＣＶＥクライアント４ａは、クライアント端末５のプライバシー設定の要求（送受信要求）を受信するための送受信要求受信手段に該当する。なお、クライアント端末５からＣＶＥサーバ４へのアクセスおよび、ＣＶＥサーバ４からＣＶＥクライアント４ａへのアクセスは、ＴＣＰ（Transmission Control Protocol：伝送制御プロトコル）ソケットにより行われる。
【００９１】
図２は、クライアント端末５において操作されるアバターのコントロールパネルおよび表示画面を示した図である。クライアント端末５では、ＣＶＥサーバ４により構築される仮想空間上のアバターを、図２に示すコントロールパネル７ｂを用いて操作することが可能となっている。また、参加者は、仮想空間において、少なくとも一体以上のアバターを、自分を示すアバターとして操作することが可能となっている。参加者は、他の参加者とのプライバシーを確保するために、アバターに対して図３に示す次の４つの動作を行わせることが可能である。
【００９２】
（１）「ミュート」
ミュートとは、話者（意見を発言するもの）の発信する音声データをブロックする機能を意味している。例えば、自分の音声データの発信をブロックする場合、つまり、自分の音声データを他の参加者に聞かれないようにする場合には、仮想空間において、自分のアバターの口を自分の手で塞ぐ動作を行う。このようにアバターを操作して、手で口を塞ぐことにより、他の参加者に自分の音声データが伝わってしまうことを防止することができる。
【００９３】
さらに、自分のアバターを操作して、他の参加者の口を自分のアバターの手で塞ぐことによって、口が塞がれた他の参加者の音声データが自分に届かないようにすることができる。図３に示す表の「Ｐ１  ｍｕｔｅｓ  Ｐ２」の”アバターの動作状況”欄では、他の参加者の口を自分のアバターの手で押さえている状態を示している。この図に示すように、他の参加者の口を自分のアバターの手で塞ぐ場合には、親指が下側に位置するようにして手が表示される。一方で、自分の手で自分の口を塞ぐ場合には、親指が上側に位置するようにして手が表示される。
【００９４】
図３の表に示すように、他の参加者Ｐ２の口を自分Ｐ１のアバターの手で押さえることにより、参加者Ｐ２をミュートすると、”音声データの送受信関係”欄に示すベクトルから明らかなように、自分Ｐ１の音声データは他の参加者Ｐ２、Ｐ３、Ｐ４に届くが、参加者Ｐ２の音声データは、自分Ｐ１には届かなくなる。なお、他の参加者Ｐ３、Ｐ４にはミュートを行っていないので、自分Ｐ１は他の参加者Ｐ３、Ｐ４の音声データを受信（聞くこと）ができ、また、参加者Ｐ２の音声データは、他の参加者Ｐ３、Ｐ４に届く。このように、ミュート機能は、参加者Ｐ１が、ミュート対象となる参加者(自分も含む)を特定してミュートすることにより、ミュートされた参加者から参加者Ｐ１への音声データのブロックを行う機能である。
【００９５】
（２）「デフン」
デフンは、音声データの受信に関するプライバシー機能である。具体的には、選択した参加者に、こちら側の音声データを受信させない（聞こえない）ようにする機能を意味している。例えば、自分の意見（音声データ）を特定の参加者に聞かせたくない（受信させたくない）場合、自分のアバターの手で、相手のアバターの耳を塞ぐ動作を行う。このようにアバターを操作して、手で相手の耳を塞ぐことにより、他の参加者に自分の音声データが伝わってしまうことを防止することができる。また、自分のアバターを操作して自分の耳を自分の手で塞ぐことにより、指定された特定の参加者の音声データが自分に届かないようにすることができる。
【００９６】
図３に示す表の「Ｐ１  ｄｅａｆｅｎｓ  Ｐ２」の”アバターの動作状況”欄では、他の参加者の耳を自分のアバターの手で押さえている状態を示している。このように、他の参加者の耳を自分のアバターの手で塞ぐ場合には、親指が上側に位置するようにして手が表示される。一方で、自分の手で自分の耳を塞ぐ場合には、親指が下側に位置するようにして手が表示される。
【００９７】
図３の表に示すように、他の参加者Ｐ２の耳を自分Ｐ１のアバターの手で押さえることにより、参加者Ｐ２をデフンすると、”音声データの送受信関係”欄のベクトルから明らかなように、自分Ｐ１は他の参加者Ｐ２、Ｐ３、Ｐ４の音声データを受信することはできるが、自分Ｐ１の音声データは、デフンした参加者Ｐ２以外の参加者Ｐ３、Ｐ４にしか届かない。つまり、参加者Ｐ２にのみ自分の音声データを聞かせないように制御を行うことが可能となる。なお、このように参加者Ｐ１が参加者Ｐ２をデフンする機能は、参加者Ｐ２が参加者Ｐ１に対してミュートする機能と同じことである。
【００９８】
（３）「セレクト」
セレクトとは、参加者が受信する音声データを特定の参加者により出力された音声データのみに制限する機能を意味している。例えば、参加者が多数おり、それぞれが音声データを出力している場合、特定の参加者の音声データのみを受信したいときにその参加者をセレクトすると、他の参加者の音声データを受信することなく、セレクトされた参加者の音声データのみを受信することができる。このため、セレクト機能とは、音声データの発信者（つまり音声データの音源となる参加者）を選択する機能を意味する。
【００９９】
図３に示す表の「Ｐ１  ｓｅｌｅｃｔｓ  Ｐ２」の”アバターの動作状況”欄に示すように、参加者Ｐ１が特定の参加者Ｐ２をセレクトすると、セレクトされた参加者Ｐ２のアバターの口に、メガホンが表示され、参加者Ｐ１は、メガホンの表示されたアバターからの音声データしか受信されなくなる。なお、セレクトは音源の受信を制御する命令であるため、参加者Ｐ１が参加者Ｐ２をセレクトした場合であっても、参加者Ｐ２、Ｐ３、Ｐ４は、参加者Ｐ１の音声データを受信することができる。
【０１００】
（４）「アテンド」
アテンドとは、特定の参加者にだけ特定の音声データを受信させる機能を意味している。例えば、参加者が多数おり、それぞれが音声データの受信をしている場合、特定の参加者にだけ自分の音声データを受信させたいときにその参加者をアテンドすると、他の参加者は自分の音声データを受信することができず、アテンドした参加者のみが自分の音声データを受信することができるようになる。このため、アテンド機能は、音声データの受信者（つまり音声データを聴かせたい参加者）を発信者が選択する機能を意味している。
【０１０１】
図３に示す表の「Ｐ１  ａｔｔｅｎｄｓ  Ｐ２」の”アバターの動作状況”欄に示すように、参加者Ｐ１が特定の参加者Ｐ２をアテンドすると、アテンドされた参加者Ｐ２のアバターの耳に、メガホンが表示され、参加者Ｐ１の音声データは、メガホンが表示された参加者Ｐ２にしか受信されなくなる。なお、アテンドは、音声データを受信することが可能となる参加者を制限する命令であるため、参加者Ｐ１において受信される他の参加者の音源データは制限されない。このため、参加者Ｐ１が参加者Ｐ２をアテンドした場合、参加者Ｐ１の音声データは参加者Ｐ２以外には伝達されないが、参加者Ｐ１は、参加者Ｐ２、Ｐ３、Ｐ４の音声データを受信することができる。
【０１０２】
対象となる参加者のアバターを選択して「ミュート」「デフン」「セレクト」「アテンド」を選択する場合、参加者は、クライアント端末５のコントロールパネル７ｂの所定項目にチェックを入れる作業を行う。図２に示す表示画面７ａには、三体のアバターが表示されており、表示画面７ａの右側に位置するアバター８は、コントロールパネル７ｂに示される「Ａｖａｔａｒ０」、真ん中に位置するアバター９は、コントロールパネル７ｂに示される「Ａｖａｔａｒ１」、左端に位置するアバター１０は、コントロールパネル７ｂに示される「Ａｖａｔａｒ２」を示している。本実施の形態に係るマルチメディア会議システム１では、図２に示すコントロールパネル７ｂの座標位置項目２０の左欄に設けられる「Ｓｅｌｆ」（セルフ）の操作項目１１をチェックすることによって、自分を表すアバターを設定することが可能となっている。図２に示すコントロールパネル７ｂでは、「Ａｖａｔａｒ０」の「Ｓｅｌｆ」（セルフ）の操作項目１１にチェックが入れられているため、「Ａｖａｔａｒ０」は、操作者自身を表すアバターとして仮想空間に存在することになる。
【０１０３】
参加者がアバターのミュート操作およびデフン操作を行う場合には、その対象が自分（Ｓｅｌｆ）の場合と他人（Ｏｔｈｅｒ）の場合との２パターンを選択することができる。そのため、コントロールパネルの「Ｓｅｌｆ」の操作項目１２には、「Ｍｕｔｅ」（ミュート）のチェック項目１３と「Ｄｅａｆｅｎ」（デフン）のチェック項目１４とが設けられおり、同様にして、「Ｏｔｈｅｒ」の操作項目１５には「Ｍｕｔｅ」のチェック項目１６と「Ｄｅａｆｅｎ」のチェック項目１７とが設けられている。さらに、それらの操作項目の右側には、「Ｓｅｌｅｃｔ」（セレクト）と「Ａｔｔｅｎｄ」（アテンド）の操作を行うための操作項目１８、１９も設けられている。セレクト操作とアテンド操作との対象は、他のアバターだけであるため、セレクト操作およびアテンド操作を行う操作項目１８、１９には、「Ｓｅｌｆ」の操作項目や「Ｏｔｈｅｒ」の操作項目は設けられていない。
【０１０４】
図２に示すコントロールパネル７ｂでは、コントロールパネル７ｂに示すように、アバター１は、アバター０によりミュートされているため、アバター１の口を塞ぐ手はアバター０の手を示し、親指が下側に位置するようにして表示される。また同様に、アバター２は、アバター０によりデフンされているため、アバター２の耳を塞ぐ手はアバター０の手を示し、親指が上側に位置するようにして表示される。
【０１０５】
なお、携帯電話等のように、表示画面７ａを用いてアバターをグラフィカルに表示することが困難な端末においては、図３に示すようなモバイルアイコンを用いてアバターの状態を示す方法が用いられる。このモバイルアイコンを用いる場合には、親指の位置を確認することができない。
【０１０６】
図２に示すコントロールパネル７ｂを用いて、参加者毎に設定されたプライバシー設定の要求（送受信要求）の内容は、ＣＶＥサーバ４およびＣＶＥクライアント４ａを介して、アプリケーションサーバ３に伝達される。
【０１０７】
アプリケーションサーバ３は、ＣＶＥサーバ４を介して取得された各参加者のプライバシー設定の要求に応じて、各アバターに対応したプライバシー設定の評価を行うと共に、評価されたプライバシー設定に応じて、音声データをどの参加者（アバター）に対して混合する必要があるかを決定する役割を有している。ここで、それぞれの参加者におけるプライバシー関係はポリシーと呼ばれている。従って、アプリケーションサーバ３は、ポリシー設定サーバとしての機能を備えることになる。
【０１０８】
アプリケーションサーバ３は、図１に示すように、ポリシーの演算・決定処理、ポリシーの評価処理、音声データの混合決定処理を行う演算処理部３ａと、演算処理部３ａにより実行される制御プログラム（後述する図６〜図８に示すプログラムなど）を記憶する記憶部３ｂと、メディアサーバ２に対して決定された混合パターンを送信するための通信部（送信手段）３ｃとを有している。演算処理部３ａは、記憶部３ｂに記憶されるプログラムに従って、上述したポリシーの演算・決定処理、ポリシーの評価処理、音声データの混合決定処理などを実行する。
【０１０９】
図４は、参加者により要求されたプライバシー設定を集計・演算することにより求められるマトリックスであって、各参加者より送信される音声データと各参加者において受信可能とされる音声データとの関係を示している。図４に示すマトリックスでは、アバターがｎ体存在する場合を示している。マトリックスの縦列は、音声データの発信者を示し横列は音声データの受信者を示している。マトリックスにおいて、例えば、（Ｐ１→Ｐ２）と示される内容は、音声データが参加者Ｐ１から送信されて参加者Ｐ２において受信される場合を示している。マトリックスの同一のセルにＰ１（Ｐ１→Ｐ２）と、Ｐ２（Ｐ１→Ｐ２）の２つの設定が示されているが、Ｐ１（Ｐ１→Ｐ２）は、アバターＰ１が、アバターＰ１から送信されてアバターＰ２において受信される音声データに対して設定したポリシーを示し、Ｐ２（Ｐ１→Ｐ２）は、アバターＰ２が、アバターＰ１から送信されてアバターＰ２において受信される音声データに対して設定したポリシーを示している。
【０１１０】
例えば、アバターが４体である場合、アバターＰ１がアバターＰ２に対してミュートした場合のマトリックスは、図３に示す表の「Ｐ１  ｍｕｔｅｓ  Ｐ２」の”プライバシー設定用マトリックス”欄に示すように設定される。また、アバターＰ１がアバターＰ２に対してデフンした場合のマトリックスは、図３に示す表の「Ｐ１  ｄｅａｆｅｎｓ  Ｐ２」の”プライバシー設定用マトリックス”欄に示すように設定される。さらに、アバターＰ１がアバターＰ２に対してセレクトした場合のマトリックスは、図３に示す表の「Ｐ１  ｓｅｌｅｃｔｓ  Ｐ２」の”プライバシー設定用マトリックス”欄に示すように設定される。また、アバターＰ１がアバターＰ２に対してアテンドした場合のマトリックスは、図３に示す表の「Ｐ１  ａｔｔｅｎｄｓ  Ｐ２」の”プライバシー設定用マトリックス”欄に示すように設定される。
【０１１１】
図５は、ある参加者において特定の参加者の音声データを取得することができるか否かを、アプリケーションサーバ３の演算処理部３ａが、参加者によって設定されたプライバシー設定の要求（送受信要求）に基づいて算出するための論理的な判断式（述語計算記法）を示した図である。
【０１１２】
図５に示す式（１）は、包括的な判断式を示しており、式（２）は式（１）に基づいて、話者・話手（音声データを発信するもの）を主体として設定される命令である「ミュート」と「セレクト」との関係を示した判断式であり、式（３）は、聴取者・聞き手（音声データを受信する者）を主体として設定される命令である「デフン」と「アテンド」との関係を示した判断式である。
【０１１３】
上述したように、「ミュート」は、指定された話者の音声データを明示的に無効にする命令であり、「セレクト」は、指定された話者以外の音声データを明示的に無効にする命令である。このため、「セレクト」は、「セレクト」により指定された話者以外の全ての参加者に対して「ミュート」する命令と等価であるといえる。従って、ミュート命令によりミュートされた参加者がいる場合における音声データの有効性を判断する場合には、セレクトされた参加者の有無を考慮する必要があり、セレクト命令によりセレクトされた参加者がいる場合における音声データの有効性を判断する場合には、ミュートされた参加者の有無を考慮する必要がある。また、同様に、デフン命令によりデフンされた参加者がいる場合における音声データの有効性を判断する場合には、アテンドされた参加者の有無を考慮する必要があり、アテンド命令によりアテンドされた参加者がいる場合における音声データの有効性を判断する場合には、デフンされた参加者の有無を考慮する必要がある。
【０１１４】
上述した包括的な判断式である式（１）をより詳細に説明する。
【０１１５】
式（１）は、対象とするアバター（クライアント端末５、参加者）ｘが有効な状態であるか否かを調べる式である。ここで対象とするｘが有効な状態であるか否かとは、ｘを話者として扱う場合、式（２）に示すように、ｘの音声データが自分に聞こえるかどうか（聞こえる場合は有効）を意味することになり、また、ｘを聴取者として扱う場合、式（３）に示すように、自分の音声データがｘに聞こえるかどうか（聞こえる場合は有効）を意味することになる。
【０１１６】
式（１）〜式（３）では、自分を示すアバターを、仮想空間において複数存在させることを前提としている。つまり、１人の参加者が、２体以上のアバターを自分のアバターとして設定することが可能である。従って、この式を用いて、ある特定のアバターｘに関する音声データの送信または受信が有効であるか否かを判断する場合、ｘと他の全てのアバターｙとが共に自分を示すアバターであるか否かを判断する必要がある。
【０１１７】
また、ｘに関する音声データの送信または受信が有効であると判断される状況は、上述したように、ｘが明示的に有効にされている場合（例えば、ｘが「ミュート」または「デフン」されている場合）に加えて、ｘ以外に明示的に有効にされている参加者がいない場合（例えば、ｘ以外の参加者に明示的に「セレクト」または「アテンド」されている者がいない場合）とが考えられる。
【０１１８】
また、ｘを話者とする場合、ｘの音声データが自分に届くかどうかは、ｘ以外の参加者の状態にも左右されることになる。例えば、ｘ以外の参加者が「セレクト」されている状態の場合、ｘもまた明示的に「セレクト」されていない限り、ｘの音声データは自分に聞こえないことになる。一方で、ｘを聴取者とした場合にも同様に、ｘ以外の参加者に「アテンド」されている者がいた場合、ｘもまた明示的に「アテンド」されていなければ、自分の音声データはｘに届かない。このように、ｘ以外の参加者との関係について判断している部分が、次述する式（４）である。
【数１】
2009231949.tif 000003
式（４）は、式（１）の一部分を構成する式である。
この式（４）を更に分解して説明する。式（４）に含まれる式（５）は、
【数２】
2009231949.tif 000004
“ｘもｙも自分自身である“場合と、”ｘもｙも自分自身でない“場合にのみ真と判断される。また、式（４）に含まれるｉｎｃｌｕｄｅ（ｙ）は、“ｙが明示的に有効にされている”という条件を表しており、この条件はつまり、ｙが話者であるならば、ｙが「セレクト」されている場合に真となり、ｙが聴取者であるならば、ｙが「アテンド」されている場合に真となる。
【０１１９】
さらに、式（４）に示されるヨｙ（・・・）は、（・・・）の条件を満たすｙが存在する場合に真となり、（・・・）の条件を満たすｙが存在しない場合には偽となる。
【０１２０】
また、式（４）に示される記号⇒は、論理包含を表している。
従って、式（４）において、
【数３】
2009231949.tif 000005
“式（６）を満たすようなｙが存在しない場合”には、ｉｎｃｌｕｄｅ（ｘ）の真偽にかかわらず、式（４）は真、つまりｘに関する音声データの送信または受信が有効であると判断され、“式（６）を満たすようなｙが存在する場合”には、ｉｎｃｌｕｄｅ（ｘ）の真偽により、式（４）の真偽が判断される旨を示している。
【０１２１】
式（１）に基づいて、ｘに関する音声データの送信または受信が有効となるか無効となるかの条件は、図６に示すフローチャートにより判断される。
図６のステップＳ．１の判断は、式（１）における式（７）
【数４】
2009231949.tif 000006
の判断を示しており、図６のステップＳ．３の判断は、式（４）に示したヨｙ（・・・）の判断を示しており、図６のステップＳ．４の判断は、式（５）に示した判断を示しており、図６のステップＳ．５の判断は、式（１）における「ｉｎｃｌｕｄｅ（ｙ）」の判断を示しており、図６のステップＳ．６の判断は、式（１）における「ｉｎｃｌｕｄｅ（ｘ）」の判断を示している。
【０１２２】
上述したように、式（１）は、ｘを話者として扱う場合（式（２）に示す場合）と、ｘを聴取者として扱う場合（式（３）に示す場合）とを包括的に示した式である。従って、式（１）に基づいて、ｘを話者として扱う場合の式（２）をフローチャートにすると、図７のように示すことが可能となる。
【０１２３】
図７に示すフローチャートにおいて、図７のステップＳ．１１の判断は、式（２）における式（８）
【数５】
2009231949.tif 000007
の判断を示しており、図７のステップＳ．１３の判断は、式（２）に示したヨｙ（・・・）の判断を示しており、図７のステップＳ．１４の判断は、式（５）に示した判断を示しており、図７のステップＳ．１５の判断は、式（２）における「ｓｅｌｅｃｔ（ｙ）」の判断（ｙをセレクトしている場合に真となる）を示しており、図７のステップＳ．１６の判断は、式（２）における「ｓｅｌｅｃｔ（ｘ）」の判断（ｘをセレクトしている場合に真となる）を示している。
【０１２４】
このフローチャートから明らかなように、ｘを話者として扱う場合、ｘをミュートした場合（ステップＳ．１１においてＮｏの場合）には、ｘからの音声データを自分で受信することができない状態（聞こえない状態）（ステップＳ．１２）となる。また、ｘをミュートしていない場合（ステップＳ．１１においてＹｅｓの場合）であっても、「ｘもｙも自分である、または、ｘもｙも自分でない」場合（ステップＳ．１４においてＹｅｓの場合）であって、「ｙがセレクトされている」場合（ステップＳ．１５においてＹｅｓの場合）であって、さらに、「ｘがセレクトされていない」場合（ステップＳ．１６においてＮｏの場合）には、ｘからの音声データを自分で受信することができない状態（ステップＳ．１２）となる。
【０１２５】
一方で、ｘをミュートしていない場合（ステップＳ．１１においてＹｅｓの場合）において、「ｘもｙも自分である、または、ｘもｙも自分でない」という条件を満たし（ステップＳ．１４においてＮｏの場合）、かつ、「ｙがセレクトされている」場合（ステップＳ．１５においてＹｅｓの場合）であり、かつ、「ｘがセレクトされている」場合（ステップＳ．１６においてＹｅｓの場合）には、ｘからの音声データを自分で受信することが可能な状態（聞こえる状態）（ステップＳ．１７）となる。
【０１２６】
また、ｘをミュートしていない場合（ステップＳ．１１においてＹｅｓの場合）であっても、「ｘもｙも自分である、または、ｘもｙも自分でない」という条件を満たしていない場合（ステップＳ．１４においてＮｏの場合）、または、「ｙがセレクトされていない」場合（ステップＳ．１５においてＮｏの場合）には、ｘからの音声データを自分で受信することができるか否かの判断（ステップＳ．１２またはステップＳ．１７）を行うことなく、他のｙの存在を確認する処理（ステップＳ．１３）を実行する。
【０１２７】
図７に示す処理の内容をより詳細に説明する。自分に該当するアバターをｚ、ｚが設定するプライバシー設定要求（送受信要求）において要求の対象となる特定のアバターをｘ、その他のアバターをｙとすると、ｚは、ｘによるｚへの音声データの発信を制限させる機能を表すミュートと、ｚが受信する音声データを、ｘが発信した音声データのみとし、他のアバターｙが発信した音声データの受信を制限する機能を表すセレクトとをプライバシー設定として設定することができる。
【０１２８】
アプリケーションサーバ３では、プライバシー設定の要求よりミュートとセレクトとを判断し、ミュートとセレクトとの対象となったアバターの組み合わせに基づいて、ｘの発信した音声データがｚにおいて受信不可能であるか否かの判断を行い、混合パターンを決定する。
【０１２９】
ここで、ｘの発信した音声データがｚにおいて受信不可能になる場合とは、まず、ｘがミュートされている場合が該当する（図７に示すステップＳ．１１においてＮｏの場合）。ｚによりｘがミュートされている場合（ステップＳ．１１においてＮｏの場合）には、ミュート機能により、ｘにおけるｚへの音声データの発信が制限されるため、ｚでは、ｘの発信した音声データを受信することができない（ステップＳ．１２）。
【０１３０】
また、ｘがミュートされていない場合（ステップＳ．１１においてＹｅｓの場合）であっても、他のアバターｙがセレクトされている場合に、ｚにおけるｘの音声データの受信が制限される恐れがある。このため、ｘ以外のアバターであるｙが存在するか否かの判断を行う（ステップＳ．１３）。この判断において、ｘ以外のｙが存在しないと判断される場合および、ｘ以外のｙが存在するが、ステップＳ．１４またはステップＳ．１５に示す判断処理を行っていないｙはもう存在しないと判断される場合（ステップＳ．１３においてＮｏの場合）には、ｘの発信した音声データをｚにおいて受信することができる（ステップＳ．１７）。
【０１３１】
一方で、ステップＳ．１４またはステップＳ．１５に示す判断処理を行っていないｙが存在する（ステップＳ．１３においてＹｅｓの場合）には、「ｘとｙとの両方がｚである、あるいは、両方がｚでない」という条件を満たすか否かの判断（ステップＳ．１４）を行う。ここで、ｘまたはｙがｚである状態は、上述したように、自分を示すアバターを、仮想空間において複数存在させることができることを前提としているために生じ得る。
【０１３２】
例えば、ｘとｙとの両方がｚでない場合、ｚがｘをセレクトすることにより、ｚにおいて受信可能な音声データは、ｘにより発信された音声データのみとなり、ｚにおいてｙにより発信された音声データを受信することが制限されてしまう。また、同様に、ｚがｙをセレクトすることにより、ｚにおいて受信可能な音声データは、ｙにより発信された音声データのみとなり、ｚにおいてｘにより発信された音声データを受信することが制限される。
【０１３３】
しかしながら、音声データの発信者が自分自身であり、自分自身の発信する音声データの受信者も自分である場合には、自分が他のアバターをセレクトしているか否かにかかわらず、自分の発信した音声データを自分自身で受信することができるようにすることが望ましい。つまり、自分自身を音声データの受信者としてとらえた場合には、セレクト機能による制限が行われない構成とすることが望まれる。また、自分自身でない他のアバターに対してセレクトを行った場合であっても、自分自身を表す他のアバターにより発信された音声データは、自分自身において受信できるようにすることが好ましい。
【０１３４】
例えば、参加者が、複数のアバターを操作する場合において、各アバターの環境がそれぞれ異なったものとなり、それぞれ異なった音声データの発信および受信を行っている場合もあり得る。このように、同一の参加者が複数のアバターを操作した場合であっても、異なる環境における自分の発言が自分自身を対象とするセレクト機能により制限されず、また、他人を対象としたセレクト機能により、自分自身を表す異なるアバターにより発信された音声データを自分自身で受信する際に制限されない設定とすることがより好ましいと言える。
【０１３５】
つまり、ｘがｚ自身であって、ｙがｚ自身でない場合に、ｚがｙをセレクトしても、ｚは自分自身の音声データであるｘの音声データを受信することができように設定することが望ましい。従って、ｘがｚ自身であって、ｙがｚ自身でない場合には、ｙのセレクトの有無により、ｚにおいてｘの発信した音声データを受信することができるか否かは影響されないようにすることが望ましい。
【０１３６】
一方で、ｘがｚ自身でなく、ｙがｚ自身である場合に、ｚが自分自身であるｙをセレクトしても、ｙのセレクト機能が、自分自身に対して機能しないように設定することが望ましい。従って、ｘがｚ自身でなく、ｙがｚ自身である場合には、ｙのセレクトの有無により、ｚにおいてｘの発信した音声データを受信することができるか否かは影響されないようにすることが望ましい。
【０１３７】
従って、図７に示すように、ｘがミュートされていない場合（ステップＳ．１１においてＹｅｓの場合）であり、さらに、ステップＳ．１４またはステップＳ．１５に示す判断処理を行っていないｙが存在する（ステップＳ．１３においてＹｅｓの場合）において、ｘとｙとの両方がｚであるかあるいは両方がｚでない場合（ステップＳ．１４においてＹｅｓの場合）にのみ、ｙがセレクトされているか否か（ステップＳ．１５）を判断する構成にすることにより、ｘまたはｙのいずれか一方のみがｚである場合には、ｚにおいてｘの発信した音声データを受信することが可能であるか否かの判断（ステップＳ．１２、ステップＳ．１７）に影響を及ぼさないようにすることが可能となる。
【０１３８】
一方で、ｘがｚ自身であり、かつ、ｙがｚ自身である場合であっても、上述したように、ｘの環境とｙの環境とは必ずしも一致するものではない。このため、ｘおよびｙがｚ自身であって、結果として自分自身を示す複数の音源が存在する場合には、参加者がそれらの音源を明示的に選択することにより、自分自身において受信可能な音声データを選択（決定）することができるようにすることが好ましい。
【０１３９】
従って、ｘがミュートされていない場合（ステップＳ．１１においてＹｅｓの場合）であり、さらに、ステップＳ．１４またはステップＳ．１５に示す判断処理を行っていないｙが存在する（ステップＳ．１３においてＹｅｓの場合）において、ｘとｙとの両方がｚである場合（ステップＳ．１４においてＹｅｓの場合）にｙがセレクトされているか否か（ステップＳ．１５）を判断する構成にすることにより、ｙがセレクトされている場合（ステップＳ．１５においてＹｅｓの場合）に、ｘが明示的にセレクトしないことによって（ステップＳ．１６においてＮｏの場合）、ｚにおいて受信可能な音声データをｙにより発信された音声データのみに選択（制限）し、ｘにより発信された音声データをｚにおいて受信できないようにすること（ステップＳ．１２）が可能となる。また、ｙがセレクトされている場合（ステップＳ．１５においてＹｅｓの場合）に、ｘを明示的にセレクトすることによって（ステップＳ．１６においてＹｅｓの場合）、ｚにおいて受信可能な音声データをｙとｘにより発信された音声データに選択することができ、ｘにより発信された音声データをｚにおいて受信できるようにすること（ステップＳ．１７）が可能となる。
【０１４０】
一方で、ｙがセレクトされていない場合（ステップＳ．１５においてＮｏの場合）には、ｚにおいて受信可能な音声データが、他のアバター（他のｙ）により制限されることがないか否かを確認し、確認処理（ステップＳ．１４、ステップＳ．１５）が行われていないｙが存在しない場合（ステップＳ．１３においてＮｏの場合）には、ｘにより発信された音声データが、すべてのｙにより制限されることがないと判断できるため、ｘからの音声データをｚにおいて受信することが可能となる（ステップＳ．１７）。
【０１４１】
なお、ｘがｚ自身でなく、かつ、ｙもｚ自身でない場合には、ｚにおいてｘの発信した音声データを受信することができるか否かは、ｙに対するセレクトの状態によって左右されることになる。
【０１４２】
従って、ｚがｙをセレクトしない場合（ステップＳ．１５においてＮｏの場合）には、上述した場合と同様に、ｚにおいて受信可能な音声データが、他のアバター（他のｙ）により制限されることがないか否かを確認する（ステップＳ．１３）。ステップＳ．１３において、確認処理（ステップＳ．１４、ステップＳ．１５）が行われていないｙが存在しない場合（ステップＳ．１３においてＮｏの場合）には、ｘにより発信された音声データが、すべてのｙにより制限されることがないと判断できるため、ｘからの音声データをｚにおいて受信することが可能となる（ステップＳ．１７）。
【０１４３】
一方で、ｚがｙをセレクトした場合（ステップＳ．１５においてＹｅｓの場合）には、ｚが受信する音声データがｙの発信した音声データのみとなってしまい、そのままでは、ｘの発信した音声データをｚにおいて受信することができない。そのため、ｚがｙをセレクトした場合（ステップＳ．１５においてＹｅｓの場合）には、ｚがｘをセレクトすることにより（ステップＳ．１６においてＹｅｓの場合）、ｚにおいてｘの音声データを受信することが可能となり（ステップＳ．１７）、ｚがｘをセレクトしない場合（ステップＳ．１６においてＮｏの場合）には、ｚにおいてｘの音声データを受信することが不可能となる（ステップＳ．１２）。
【０１４４】
また、式（１）に基づいて、ｘを聴取者として扱う場合の式（３）をフローチャートにすると、図８のように示すことが可能となる。
図８に示すフローチャートにおいて、図８のステップＳ．２１の判断は、式（３）における式（９）
【数６】
2009231949.tif 000008
の判断を示しており、図８のステップＳ．２３の判断は、式（２）に示したヨｙ（・・・）の判断を示しており、図８のステップＳ．２４の判断は、式（５）に示した判断を示しており、図８のステップＳ．２５の判断は、式（３）における「ａｔｔｅｎｄ（ｙ）」の判断（ｙがアテンドされている場合に真となる）を示しており、図８のステップＳ．２６の判断は、式（３）における「ａｔｔｅｎｄ（ｘ）」の判断（ｘがアテンドされている場合に真となる）を示している。
【０１４５】
このフローチャートから明らかなように、ｘを聴取者として扱う場合、ｘがデフンされた場合（ステップＳ．２１においてＮｏの場合）には、ｚの音声データをｘにおいて受信することができない（ステップＳ．２２）ことになる。また、ｘがデフンされていない場合（ステップＳ．２１においてＹｅｓの場合）であっても、「ｘもｙも自分である、または、ｘもｙも自分でない」場合（ステップＳ．２４においてＹｅｓの場合）であって、「ｙがアテンドされている」場合（ステップＳ．２５においてＹｅｓの場合）であって、さらに、「ｘがアテンドされていない」場合（ステップＳ．２６においてＮｏの場合）には、ｚの音声データをｘにおいて受信することができない状態（ステップＳ．２２）となる。
【０１４６】
一方で、ｘをデフンしていない場合（ステップＳ．２１においてＹｅｓの場合）において、「ｘもｙも自分である、または、ｘもｙも自分でない」という条件を満たし（ステップＳ．２４においてＮｏの場合）、かつ、「ｙがアテンドされている」場合（ステップＳ．２５においてＹｅｓの場合）であり、かつ、「ｘがアテンドされている」場合（ステップＳ．２６においてＹｅｓの場合）には、ｚの音声データをｘにおいて受信することが可能な状態（聞こえる状態）（ステップＳ．２７）となる。
【０１４７】
また、ｘをデフンしていない場合（ステップＳ．２１においてＹｅｓの場合）であっても、「ｘもｙも自分である、または、ｘもｙも自分でない」という条件を満たしていない場合（ステップＳ．２４においてＮｏの場合）、または、「ｙがアテンドされていない」場合（ステップＳ．２５においてＮｏの場合）には、ｚの音声データをｘにおいて受信することができるか否かの判断（ステップＳ．２２またはステップＳ．２７）を行うことなく、他のｙの存在を確認する処理（ステップＳ．２３）を実行する。
【０１４８】
図８に示す処理の内容においても、自分に該当するアバターをｚ、ｚが設定するプライバシー設定要求（送受信要求）において要求の対象となる特定のアバターをｘ、その他のアバターをｙとすると、ｚにより発信された音声データの受信をｘにおいて制限させる機能を表すデフンと、ｚが発信する音声データの受信をｘのみとし、ｙにおいて受信することを制限する機能を表すアテンドとをプライバシー設定として設定することができる。
【０１４９】
アプリケーションサーバ３では、プライバシー設定の要求よりデフンとアテンドとを判断し、デフンとアテンドとの対象となったアバターの組み合わせに基づいて、ｚの発信した音声データをｘにおいて受信することができないか否かの判断を行い、混合パターンを決定する。
【０１５０】
ここで、ｚの発信した音声データをｘにおいて受信することができない場合とは、まず、ｘがデフンされている場合が該当する（図８に示すステップＳ．２１においてＮｏの場合）。ｚによりｘがデフンされている場合（ステップＳ．２１においてＮｏの場合）には、デフン機能により、ｘにおけるｚからの音声データの受信が制限されるため、ｘでは、ｚの発信した音声データを受信することができない（ステップＳ．２２）。
【０１５１】
また、ｘがデフンされていない場合（ステップＳ．２１においてＹｅｓの場合）であっても、他のアバターｙがアテンドされている場合には、ｘにおけるｚの音声データの受信が制限される恐れがある。このため、ｘ以外のアバターであるｙが存在するか否かの判断を行う（ステップＳ．２３）。この判断において、ｘ以外のｙが存在しないと判断される場合および、ｘ以外のｙが存在するが、ステップＳ．２４またはステップＳ．２５に示す判断処理を行っていないｙはもう存在しないと判断される場合（ステップＳ．２３においてＮｏの場合）には、ｚの発信した音声データをｘにおいて受信することができる（ステップＳ．２７）。
【０１５２】
一方で、ステップＳ．２４またはステップＳ．２５に示す判断処理を行っていないｙが存在する（ステップＳ．２３においてＹｅｓの場合）には、「ｘとｙとの両方がｚである、あるいは、両方がｚでない」という条件を満たすか否かの判断（ステップＳ．２４）を行う。
【０１５３】
例えば、ｘとｙとの両方がｚでない場合、ｚがｘをアテンドすることにより、ｚの音声データを受信することが可能なアバターは、ｘのみとなり、ｙにおいてｚにより発信された音声データを受信することが制限されてしまう。また、同様に、ｚがｙをアテンドすることにより、ｚにおいて発信された音声データは、ｙのみで受信することが可能となり、ｘにおいてｚにより発信された音声データを受信することが制限される。
【０１５４】
しかしながら、音声データの発信者が自分自身であり、自分自身の発信する音声データの受信者も自分である場合には、自分が他のアバターをアテンドしているか否かにかかわらず、自分の発信した音声データを自分自身で受信することができるようにすることが望ましい。つまり、自分自身を音声データの受信者としてとらえた場合には、アテンド機能による制限が行われない構成とすることが望まれる。また、自分自身でない他のアバターに対してアテンドを行った場合であっても、自分自身を表す他のアバターにより発信された音声データは、自分自身において受信できるようにすることが好ましい。
【０１５５】
例えば、参加者が、複数のアバターを操作する場合において、各アバターの環境がそれぞれ異なったものとなり、それぞれ異なった音声データの発信および受信を行っている場合もあり得る。このように、同一の参加者が複数のアバターを操作した場合であっても、異なる環境における自分の発言が自分自身を対象とするアテンド機能により制限されず、また、他人を対象としたアテンド機能により、自分自身を表す異なるアバターにおいて、自分自身の発信した音声データを受信することが制限されない設定とすることがより好ましいと言える。
【０１５６】
つまり、ｘがｚ自身であって、ｙがｚ自身でない場合に、ｚがｙをアテンドしても、ｘは自分自身の音声データであるｚの音声データを受信することができように設定することが望ましい。従って、ｘがｚ自身であって、ｙがｚ自身でない場合には、ｙのアテンドの有無により、ｘにおいてｚの発信した音声データを受信することができるか否が影響されないようにすることが望ましい。
【０１５７】
一方で、ｘがｚ自身でなく、ｙがｚ自身である場合に、ｚが自分自身であるｙをアテンドしても、ｙのアテンド機能が、自分自身に対して機能しないように設定することが望ましい。従って、ｘがｚ自身でなく、ｙがｚ自身である場合には、ｙのアテンドの有無により、ｘにおいてｚの発信した音声データを受信することができるか否かが影響されないようにすることが望ましい。
【０１５８】
従って、図８に示すように、ｘがデフンされていない場合（ステップＳ．２１においてＹｅｓの場合）であり、さらに、ステップＳ．２４またはステップＳ．２５に示す判断処理を行っていないｙが存在する（ステップＳ．２３においてＹｅｓの場合）において、ｘとｙとの両方がｚであるかあるいは両方がｚでない場合（ステップＳ．２４においてＹｅｓの場合）にのみ、ｙがアテンドされているか否か（ステップＳ．２５）を判断する構成にすることにより、ｘまたはｙのいずれか一方のみがｚである場合には、ｘにおいてｚの発信した音声データを受信することが可能であるか否かの判断（ステップＳ．２２またはステップＳ．２７）に影響を及ぼさないようにすることが可能となる。
【０１５９】
一方で、ｘがｚ自身であり、かつ、ｙがｚ自身である場合であっても、上述したように、ｘの環境とｙの環境とは必ずしも一致するものではない。このため、ｘおよびｙがｚ自身であって、結果として自分自身の発信した音源を受信するためのアバターが自分自身でありかつ複数存在する場合には、参加者がそれらの聴取者を明示的に選択することにより、自分自身の音声データを受信することが可能なアバターを選択（決定）することができるようにすることが好ましい。
【０１６０】
従って、ｘがデフンされていない場合（ステップＳ．２１においてＹｅｓの場合）であり、さらに、ステップＳ．２４またはステップＳ．２５に示す判断処理を行っていないｙが存在する（ステップＳ．２３においてＹｅｓの場合）において、ｘとｙとの両方がｚである場合（ステップＳ．２４においてＹｅｓの場合）にｙがアテンドされているか否か（ステップＳ．２５）を判断する構成にすることにより、ｙがアテンドされている場合（ステップＳ．２５においてＹｅｓの場合）に、ｘが明示的にアテンドしないことによって（ステップＳ．２６においてＮｏの場合）、ｚにおいて発信された音声データをｙのみで発信するように選択（制限）し、ｘにおいて受信できないようにすること（ステップＳ．２２）が可能となる。また、ｙがアテンドされている場合（ステップＳ．２５においてＹｅｓの場合）に、ｘを明示的にアテンドすることによって（ステップＳ．２６においてＹｅｓの場合）、ｚにおいて発信された音声データをｙとｘにおいて受信できるように選択することができ、ｘにおいてｚの音声データを受信できるようにすること（ステップＳ．２７）が可能となる。
【０１６１】
一方で、ｙがアテンドされていない場合（ステップＳ．２５においてＮｏの場合）には、ｚにおいて発信された音声データが、他のアバター（他のｙ）により制限されることがないか否かを確認し、確認処理（ステップＳ．２４、ステップＳ．２５）が行われていないｙが存在しない場合（ステップＳ．２３においてＮｏの場合）には、すべてのｙに対し、ｚにより発信された音声データをｘにおいて受信する際に、ｙによって制限されることがないと判断できるため、ｚからの音声データをｘにおいて受信することが可能となる（ステップＳ．２７）。
【０１６２】
なお、ｘがｚ自身でなく、かつ、ｙもｚ自身でない場合には、ｘにおいてｚの発信した音声データを受信することができるか否かは、ｙに対するアテンドの状態によって左右されることになる。
【０１６３】
従って、ｚがｙをアテンドしない場合（ステップＳ．２５においてＮｏの場合）には、上述した場合と同様に、ｚにおいて受信されるｚの音声データが、他のアバター（他のｙ）により制限されることがないか否かを確認する（ステップＳ．２３）。ステップＳ．２３において、確認処理（ステップＳ．２４、ステップＳ．２５）が行われていないｙが存在しない場合（ステップＳ．２３においてＮｏの場合）には、ｘにおいてｚにより発信された音声データを受信する場合に、ｙにより受信の制限が行われることがないと判断できるため、ｚからの音声データをｘにおいて受信することが可能となる（ステップＳ．２７）。
【０１６４】
一方で、ｚがｙをアテンドした場合（ステップＳ．２５においてＹｅｓの場合）には、ｚが発信する音声データは、ｙでのみ受信されることになってしまい、そのままでは、ｘにおいてｚの発信した音声データを受信することができない。そのため、ｚがｙをアテンドした場合（ステップＳ．２５においてＹｅｓの場合）には、ｚがｘをアテンドすることにより（ステップＳ．２６においてＹｅｓの場合）、ｘにおいてｚの音声データを受信することが可能となり（ステップＳ．２７）、ｚがｘをアテンドしない場合（ステップＳ．２６においてＮｏの場合）には、ｘにおいてｚの音声データを受信することが不可能となる（ステップＳ．２２）。
【０１６５】
このように、アプリケーションサーバ３の演算処理部３ａでは、ＣＶＥサーバ４を介して取得した各クライアント端末５のプライバシー設定要求（送受信要求）に基づいて、どの参加者の音声データをどの参加者に受信可能に設定するかを、式（１）に基づいて判断してマトリックス（ポリシー）を作成する。この式（１）に示す判断式を用いることによって、アプリケーションサーバ３の演算処理部３ａでは、クライアント端末５により設定されるプライバシー設定（送受信要求）が、参加者毎に異なるタイミングで変更された場合であっても、演算負担を増大させることなくポリシーの演算および評価を迅速に行うことが可能となる。
【０１６６】
アプリケーションサーバ３の演算処理部３ａは、作成したポリシーを評価し、クライアント端末５により要求されたプライバシー設定が認められるか（送受信要求を認めることができるか）、または認められないか（送受信要求を認めることができないか）を示すプライバシーの評価レポートを、クライアント端末５に送信する。ＣＶＥサーバ４では、この評価レポートに応じて、アバター操作の可否を判断し、プライバシー設定の要求（送受信要求）が認められた場合に、該当する参加者のアバターの動作を、クライアント端末５の表示画面７ａ上で実現させる。参加者は、クライアント端末５の表示画面７ａ上に表示されるアバターの動作状況を確認することによって、プライバシー設定が実現されているか否かを、簡易かつ確実に判断することが可能となる。
【０１６７】
また、アプリケーションサーバ３の演算処理部３ａは、評価されたポリシーに従って、どの参加者により発信された音声データをどの参加者に対して配信するか、つまり各参加者の音声データをどのように混合・配信するかを決定（混合パターン判断処理）する。そして、設定された内容（混合パターン）は、ＳＩＰの枠組みの中で、ＭＳＣＭＬ（Media Server Control Markup Language）に従って、通信部３ｃによりメディアサーバ２に送信される。
【０１６８】
図９は、参加者が４名（Ｐ１〜Ｐ４）の場合に、参加者（アバター）Ｐ１が参加者（アバター）Ｐ２をデフンしたときのＭＳＣＭＬ設定例（混合パターン例）を示している。参加者Ｐ１が参加者Ｐ２をデフンした場合、参加者Ｐ２は参加者Ｐ１の音声データを受信することができない。従って、参加者Ｐ３および参加者Ｐ４は、参加者Ｐ１の音声を聴取することができるが、参加者Ｐ２は、聴取することができない。なお、参加者Ｐ２、Ｐ３、Ｐ４の音声は、他の参加者に伝達され、制限されることはない。各参加者（Ｐ１〜Ｐ４）が発信する音声データを聴取可能な参加者は、図９の表の“聴取者”欄に示されている。
【０１６９】
参加者（アバター）Ｐ１が参加者（アバター）Ｐ２をデフンした場合、アプリケーションサーバ３の演算処理部３ａは、参加者Ｐ２以外の参加者（参加者Ｐ１と参加者Ｐ３と参加者Ｐ４）によってプライベートグループを作る。図９の表では、参加者Ｐ１の“メンバー”欄に参加者Ｐ３と参加者Ｐ４とが設定され、参加者Ｐ３の“メンバー”欄に参加者Ｐ１と参加者Ｐ４とが設定され、参加者Ｐ４の“メンバー”欄に参加者Ｐ１と参加者Ｐ３とが設定されている。一方で、参加者Ｐ２は、参加者Ｐ１、参加者Ｐ３、参加者Ｐ４のメンバーではないため、参加者Ｐ２の“メンバー”欄には「Ｎｏｎｅ」と設定される。
【０１７０】
そして、それぞれの参加者から発信される音声データに関する混合設定（図９の表における“ミックス”欄参照）は、ＰｒｉｖａｔｅとＦｕｌｌとに分類される。Ｆｕｌｌとは、その参加者により発信された音声データを、他の全ての参加者が受信可能となる場合を示している。図９の表に示すように、Ｆｕｌｌとなる音声データの参加者は、参加者Ｐ２、参加者Ｐ３、参加者Ｐ４であるため、参加者Ｐ２、参加者Ｐ３、参加者Ｐ４の音声データは、他の全ての参加者（Ｐ１〜Ｐ４）において聴取可能に混合される。一方で、Ｐｒｉｖａｔｅとなる参加者Ｐ１の音声データは、プライベートグループの参加者（ここでは、参加者Ｐ３と参加者Ｐ４）だけにしか聴取されないようにして混合される。
【０１７１】
メディアサーバ２は、一の参加者のクライアント端末５より受信した音声データを混合して、マルチメディア会議に参加する参加者のクライアント端末５に送信（配信）する機能を有している。特にメディアサーバ２は、各参加者の音声データを混合する処理において、アプリケーションサーバ３より受信したリクエスト（混合パターン：ＭＳＣＭＬの設定内容）に基づいて混合する音声データを選択し、クライアント端末５毎に、送信する音声データの混合内容を変更する機能を有している。
【０１７２】
図１０は、４人の参加者（クライアント端末５）より受信した音声データを、メディアサーバ２において混合して各参加者（クライアント端末５）に配信する場合の音声データの流れを示した図である。図１０に示す図では、参加者Ｐ１が参加者Ｐ２をミュートし、参加者Ｐ１が参加者Ｐ４をデフンした場合における音声データの流れを示している。
【０１７３】
各参加者Ｐ１〜Ｐ４（クライアント端末５）により発信された音声データは、ＲＴＰ（Real Time Protocol：音声や動画などのデータストリームをリアルタイムに配信するためのデータ転送プロトコル）により、メディアサーバ２で受信され、受信された各音声データは、送信先（配信先）の参加者（クライアント端末５）に応じてそれぞれ混合される。図１０に示す場合では、参加者Ｐ１が参加者Ｐ２をミュートしているので、参加者Ｐ１に送信される音声データには、参加者Ｐ３と参加者Ｐ４との音声データのみが混合され、参加者Ｐ２の音声データは混合されない。また、参加者Ｐ１は、参加者Ｐ４をデフンしているので、参加者Ｐ４は参加者Ｐ１の音声データを受信することがなく、参加者Ｐ４に配信される音声データには、参加者Ｐ２と参加者Ｐ３との音声データのみが混合され、参加者Ｐ１の音声データは混合されない。その他の参加者（参加者Ｐ２と参加者Ｐ３）は、参加者Ｐ１によるプライバシー設定の影響を受けないので、他の参加者の音声データを全て受信することが可能となる。
【０１７４】
図１１は、上述したクライアント端末５、アプリケーションサーバ３およびメディアサーバ２との間の情報の流れを示した図である。
【０１７５】
クライアント端末５がマルチメディア会議に参加する場合には、ＳＩＰを用いてアプリケーションサーバ３にアクセスし、セッションの確立を行う（ステップＳ．３１）。このセッションの確立によりクライアント端末５では、メディアサーバ２を介してＲＴＰによるアクセスが可能となり、音声データの送受信をリアルタイムに行うことが可能となる（ステップＳ．３２）。
【０１７６】
さらに、クライアント端末５では、ＣＶＥサーバ４を介して、アプリケーションサーバ３にプライバシー設定の要求（送受信要求）を行うことができ（ステップＳ．３３）、アプリケーションサーバ３では、設定されたプライバシー設定の要求に応じて、音声データの混合に関するリクエストを、ＭＳＣＭＬによりメディアサーバ２へ送信する（ステップＳ．３４）。メディアサーバ２では、アプリケーションサーバ３から取得したリクエスト（混合パターン）に応じて、クライアント端末５に出力する音声データの混合を行い、各クライアント端末５に対して個別に混合された音声データを出力する（ステップＳ．３５）。このように、クライアント端末５によるプライバシー設定の要求（送受信要求）をアプリケーションサーバ３で判断してメディアサーバ２にリクエスト（混合パターン）を送信することにより、各クライアント端末５の参加者は、プライバシーを確保した状態で、マルチメディア会議に参加することが可能となる。
【０１７７】
以上、説明したように、本実施の形態に係るマルチメディア会議システム１では、アプリケーションサーバ３において、クライアント端末５により設定されたプライバシー設定（送受信要求）に基づいて、どの参加者の音声データをどの参加者に対して発信するかを設定（混合パターンの設定）し、この設定に基づいてメディアサーバ２が音声データの配信制御を行う。このため、マルチメディア会議に参加する参加者は、それぞれのプライバシー設定に応じて、特定の参加者の音声データのみを聴取し、また特定の参加者に対してのみ自分の音声データを聴取させるように制御することができる。従って、従来のマルチメディア会議システムのように、全ての参加者の音声データが全ての参加者に配信されしまう状況を回避することができ、マルチメディア会議システム１におけるプライバシーの確保を実現することが可能となる。
【０１７８】
特に、アプリケーションサーバ３では、図５に示した式（１）を用いることによって、特定された参加者ｘに対するプライバシー設定の可否判断を、参加者ｘの有効性および他の参加者ｙの有効性に基づいて判断することができる。より詳細には、ｘを話者として扱う場合には、式（２）に基づいて、ｘの音声データが特定の参加者に聞こえるかどうかを判断し、ｘを聴取者として扱う場合には、式（３）に基づいて、特定の参加者の音声データがｘに聞こえるかどうか判断する。
【０１７９】
このため、アプリケーションサーバ３の演算処理部３ａでは、クライアント端末５により設定されるプライバシー設定の要求（送受信要求）が、参加者毎に異なるタイミングで変更された場合であっても、演算負担を増大させることなくプライバシー設定の評価および決定を迅速に行うことが可能となる。
【０１８０】
さらに、図７、図８に示すように、参加者のプライバシー設定を行う場合において、プライバシー設定の対象となるｘおよびｙのいずれか一方だけが自分を示す参加者（アバター）である場合には、ｘからの音声データを自分で受信することができるか否か（ステップＳ．１２またはステップＳ．１７）および自分の音声データをｘにおいて受信することができるか否か（ステップＳ．２２またはステップＳ．２７）の判断を行わないため、セレクト機能およびアテンド機能に関して、自分自身が音源となりかつ自分自身が受信者となる場合に生じうる制限を回避することが可能となる。
【０１８１】
また、図７、図８に示すように、参加者のプライバシー設定を行う場合において、プライバシー設定の対象となるｘおよびｙの両方が自分を示す参加者（アバター）である場合には、ｘからの音声データを自分で受信することか否か（ステップＳ．１２またはステップＳ．１７）の判断を、ｘおよびｙを明示的にセレクトすることにより選択（決定）することができ、また、自分の音声データをｘにおいて受信することができるか否か（ステップＳ．２２またはステップＳ．２７）の判断を、ｘおよびｙを明示的にアテンドすることにより選択（決定）することが可能となる。
【０１８２】
さらに、本実施の形態に係るマルチメディア会議システム１では、ＣＶＥサーバ４を用いて仮想空間を形成し、アバターの動作によりプライバシー設定を行うことが可能となっている。このため、参加者は、アバターの状態を視覚的に確認することによって、容易に各参加者に対するプライバシー設定の状態を知ることができる。
【０１８３】
特に、プライバシー設定において「ミュート」命令および「デフン」命令の設定対象として、自分または他の参加者を設定することができる。アバターを用いてプライバシー設定を行うことにより、「ミュート」命令の対象が自分の場合には、アバターの口を塞ぐ手の親指が上側を向き、「ミュート」命令の対象が他の参加者の場合には、アバターの口を塞ぐ手の親指が下側を向くこととなるため、視覚的に「ミュート」の対象を知ることができる。また、同様にして、「デフン」命令の対象が自分の場合には、アバターの耳を塞ぐ手の親指が下側を向き、「デフン」命令の対象が他の参加者の場合には、アバターの耳を塞ぐ手の親指が上側を向くこととなるため、視覚的に「デフン」の対象を知ることができる。
【０１８４】
以上、本発明に係るマルチメディア会議システムについて、図面を用いて詳細に説明を行ったが、本発明に係るマルチメディア会議システムは、上述した実施の形態に係るものに限定されるものではない。いわゆる当業者であれば、特許請求の範囲に記載された範疇内において、各種の変更例または修正例に想到しうることは明らかであり、それらについても当然に本発明の技術的範囲に属するものと了解される。
【０１８５】
例えば、本実施の形態に係るマルチメディア会議システム１では、会議において発信および受信されるストリームメディアとして音声データを一例として示して説明を行ったが、マルチメディア会議システムにおいて送受信されるストリームメディアは音声データのみに限定されるものではなく、他の情報、例えば、動画データであってもよく、また音声データ、動画データ、画像データあるいは文書データ等の様々なデータが混合された情報をストリームメディアとして用いることが可能である。
【０１８６】
また、本実施の形態に係るマルチメディア会議システム１では、ＣＶＥサーバ４を用いることにより仮想空間を形成し、アバターを操作することによりプライバシー設定の要求（送受信要求）を行う場合について説明を行ったが、クライアント端末５によるプライバシー設定は、必ずしもアバターを用いた処理に限定されるものではない。アバターを用いずに、ＳＩＰにより直接クライアント端末５からアプリケーションサーバ３にプライバシー設定の要求を行う構成とすることも可能である。この場合には、ＣＶＥサーバ４およびＣＶＥクライアント４ａを設ける必要が無くなるため、マルチメディア会議システムの構成を簡略化することが可能となる。
【図面の簡単な説明】
【０１８７】
【図１】本実施の形態に係るマルチメディア会議システムの概略構成を示したブロック図である。
【図２】本実施の形態に係るクライアント端末において操作されるアバターのコントロールパネルおよび表示画面を示した図である。
【図３】本実施の形態に係るクライアント端末において設定可能なプライバシー設定の要求（送受信要求）を説明した表である。
【図４】本実施の形態に係るアプリケーションサーバの演算処理部が、参加者により要求されたプライバシー設定を集計し、このプライバシー設定に基づいて各参加者より送信される音声データと各参加者において受信可能とされる音声データとの関係を演算して示したマトリックスの表である。
【図５】本実施の形態に係るアプリケーションサーバの演算処理部が、ある参加者において特定の参加者の音声データを取得することができるか否かを、参加者によって設定されたプライバシー設定（送受信要求）に基づいて算出するための論理的な判断式（述語計算記法）を示した図である。
【図６】図５に示した式（１）に基づいて、ｘが有効となるか無効となるか否かの判断条件を示したフローチャートである。
【図７】図５に示した式（２）に基づいて、ｘを聴取者として扱う場合に、特定の参加者（自分）の音声データが、ｘにおいて受信可能であるか否かの判断条件を示したフローチャートである。
【図８】図５に示した式（３）に基づいて、ｘを話者として扱う場合に、ｘからの音声データが、特定の参加者（自分）で受信することが可能であるか否かの判断条件を示したフローチャートである。
【図９】本実施の形態に係るマルチメディア会議システムにおいて、参加者が４名（Ｐ１〜Ｐ４）であって、参加者Ｐ１が参加者Ｐ２をデフンした場合におけるＭＳＣＭＬ設定例を示した図である。
【図１０】本実施の形態に係るマルチメディア会議システムにおいて、４人の参加者より受信した音声データをメディアサーバにおいて混合して、各参加者に配信する場合の音声データの流れを示した図である。
【図１１】本実施の形態に係るマルチメディア会議システムにおいて、クライアント端末、アプリケーションサーバおよびメディアサーバとの間の情報の流れを示した図である。
【図１２】従来のマルチメディア会議において一般的に用いられるミュート機能を説明するための図面である。
【符号の説明】
【０１８８】
１     …マルチメディア会議システム
２     …メディアサーバ
３     …アプリケーションサーバ
３ａ   …演算処理部（混合パターン決定手段）
３ｂ   …記憶部
３ｃ   …通信部（送信手段）
４     …ＣＶＥサーバ
４ａ   …ＣＶＥクライアント（送受信要求受信手段）
５     …クライアント端末
７ａ    …表示画面
７ｂ    …コントロールパネル
８、９、１０     …アバター
１１   …（自分のアバターを示すセルフの）操作項目
１２   …（ミュートおよびデフンの設定対象となるセルフの）操作項目
１３   …（セルフを対象とするミュートの）チェック項目
１４   …（セルフを対象とするデフンの）チェック項目
１５   …（ミュートおよびデフンの設定対象となる他人の）操作項目
１６   …（他人を対象とするミュートの）チェック項目
１７   …（他人を対象とするデフンの）チェック項目
１８   …（セレクトの）操作項目
１９   …（アテンドの）操作項目
２０   …位置座標項目
【図１】
2009231949.tif 000009
【図２】
2009231949.tif 000010
【図３】
2009231949.tif 000011
【図４】
2009231949.tif 000012
【図５】
2009231949.tif 000013
【図６】
2009231949.tif 000014
【図７】
2009231949.tif 000015
【図８】
2009231949.tif 000016
【図９】
2009231949.tif 000017
【図１０】
2009231949.tif 000018
【図１１】
2009231949.tif 000019
【図１２】
2009231949.tif 000020