JP4231698B2 - 多地点マルチメディア／音声システムの制御ユニット - Google Patents

Description

発明の詳細な説明

［発明の背景］
発明の技術分野
本発明は、一般に会議システムに関し、より詳細には多地点音声及び／またはマルチメディア会議のための制御ユニットに関する。
従来技術の説明
現在の音声会議あるいはビデオ会議では、参加者は１つの会議に参加できる実体である（すなわち、参加者は１つの会議で発言及び／または聴取を行うことができる）。しかしながら、しばしば参加者は１つのグループに対し発言し、それと同じ時間帯に関連した会議あるいは関連のない会議の他のグループの話を聞く必要があるかもしれない。

そのような必要性に対する例として、共通の言語を使わず、通訳を必要とする２つのグループによる会議がある。例えば、そのようなシナリオとして、Ｅ１からＥｎまでの英語を話す人々のグループ、Ｆ１からＦｍまでのフランス語を話す人々のグループ、英語からフランス語への通訳（ＥＦ）及びフランス語から英語への通訳（ＦＥ）からなるものがあるとする。そのような場合、会議の参加者は以下の関連する会議：Ｅ１からＥｎ、Ｆ１からＦｍ及びＦＥによる会議Ａと、Ｅ１からＥｎ、Ｆ１からＦｍ及びＥＦによる会議Ｂを持つことを望むかもしれない。

フランス語を話す人々は会議Ｂを聞くことを望み、英語を話す人々は会議Ａを聞くことを望むかもしれない。その結果、英語を話す人々だけがＦＥ通訳を聞き、フランス語を話す人々は通訳ＥＦを聞くことになるであろう。会議参加者が複数の会議を持つことを望む他の例は、参加者の中の数人が「プライベートルーム」（仮想的なプライベートルーム）を望み、そこでは参加者の第１のグループは、第２のグループの話を聞きことができるが、第１グループにおける話し合いは第２グループには聞かれない。

多地点接続装置（ＭＣＵ）とは会議を制御するものである。ＭＣＵは、アクセスポートから複数のチャンネルを受信し、特定の基準に従い音声あるいはオーディオビジュアル信号を処理し、それらを接続チャンネルに配信するネットワークのノードあるいは端末に設置される装置であるかもしれない。音声信号は、以下に限定されるものではないが、例えば、ＰＳＴＮ（Ｐｕｂｌｉｃ Ｓｗｉｔｃｈｅｄ Ｔｅｌｅｐｈｏｎｅ Ｎｅｔｗｏｒｋ）、ＩＳＤＮ（Ｉｎｔｅｇｒａｔｅｄ Ｓｅｒｖｉｃｅｓ Ｄｉｇｉｔａｌ Ｎｅｔｗｏｒｋ）、ＡＴＭ（Ａｓｙｎｃｈｒｏｎｏｕｓ Ｔｒａｎｓｆｅｒ Ｍｏｄｅ）、ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）、ＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）、Ｈ．３２０、Ｈ．３２３あるいは他の類似のプロトコルのような回路スイッチあるいはパケットスイッチネットワークにおける信号処理プロトコルに従い処理される。ＭＣＵの一例としてはＰｏｌｙｃｏｍ， ＩｎｃによるＭＧＣ−１００が挙げられる。ＭＣＵが音声／マルチメディア会議に利用される場合、ＭＣＵは音声信号を処理し、それを接続チャンネルに配信したり、会議の制御のために利用することができる。しかしながら、現在のＭＣＵは上述の例のような複数の会議に参加したい人々の要求を満たすことはできない。

従って、明らかに、１人以上の参加者が複数の会議に参加することを可能にするシステム及び方法の必要性がある。
［発明の概要］
本発明は、各参加者が複数の会議に参加することを可能にする音声またはマルチメディア会議の制御システム及び方法を提供する。本発明は、ＭＣＵの音声セクション及び管理制御システム（ＭＣＳ）セクションにおいて動作しうる。

本発明において、ブリッジは会議により特定される論理ユニットであってもよい。ブリッジは、ストリーム解析・エンハンス論理ユニット、制御ユニット、スイッチ及びミキサを含んでもよい。解析・エンハンス論理ユニットは、参加者の音声ストリームの解析及びその質の向上を行うアルゴリズム群を含んでもよい。この解析及びエンハンス処理には、以下に限定されるものではないが、例えば、ＩＴＵ Ｇ．１６５（エコー除去）、ＤＴＭＦ抑制、ＶＡＤ（Ｖｏｉｃｅ Ａｃｔｉｖｉｔｙ Ｄｅｔｅｃｔｉｏｎ）を含みうる。制御ユニットは、会議の主要な制御ユニットであり、ストリーム解析・エンハンス論理ユニットからすべての情報信号を受信してもよい。制御ユニットは、ミキシングのためルーティングされる参加者を選択してもよい。スイッチは、会議のすべての参加者から復号化ストリームを受信するセレクタであってもよく、選択されたストリームをミキサに送信する。この選択は制御ユニットの決定に基づき行われる。ミキシングユニットは、選択された参加者のすべてからストリームを受信し、各参加者に選択された参加者からの圧縮されていないミキシングされた音声ストリームを提供する。接続パラメータは、各参加者と各会議に配分されるリソースを示すものかもしれない。例えば、接続パラメータは、参加者に関連付けされているＣＯＤＥＣに関するパラメータ、及び／あるいは会議に関連付けされているブリッジに関するパラメータであるかもしれない。本記述においては、圧縮（ｃｏｍｐｒｅｓｓ）と符号化（ｅｎｃｏｄｅ）の単語は置き換え可能なものとして利用される。同様に、オープンデータの復号化（ｄｅｃｏｄｅ）及び解凍（ｕｎｃｏｍｐｒｅｓｓ）のフレーズも置き換え可能なものとして利用される。

さらに、本発明において、相互会議データベース（ＣＣＤＢ）は、少なくとも１人の参加者による複数の会議への同時参加を可能にする管理ツールである。ＣＣＤＢは、ＭＣＵにより現在管理されているすべての会議の各参加者の接続状況、及び／あるいはＭＣＵに現在接続されているすべての会議及び／あるいはすべての参加者の接続パラメータを保持するデータベースである。接続状況は、会議における参加者の状況を定義するものであるかもしれない。接続状況の例として、ノーマル（Ｎｏｒｍａｌ）、ミュート（Ｍｕｔｅ）、強制（Ｆｏｒｃｅ）、発言（Ｓｐｅａｋ）、聴取（Ｌｉｓｔｅｎｉｎｇ）及びＮｏｎｅなどがある。ミュート（Ｍ）の接続状況は、参加者の発言が会議において聴取できないという状況を意味するものである。ノーマル（Ｎ）の接続状況は、参加者の発言が会議において聴取され、かつ会議を聴取できるという状況を意味するものである。発言（Ｓ）の接続状況は、参加者の発言が会議において聴取されるが、会議を聴取することはできないという状況を意味するものである。オプションとして、Ｎ及び／あるいはＳの接続状況に対し、参加者の声を表す信号が、例えば、このエネルギーレベルがある値を上回るかどうかというようなある基準を満たす場合にのみ、参加者の発言が聴取されるというものであってもよい。強制（Ｆ）の接続状況は、対応する参加者の声が聴取に関する基準を満たさない場合でも、参加者の発言が聴取されねばならないという状況を意味している。Ｆの接続状況でもまた、参加者が会議を聴取することが可能であるかもしれない。排除（Ｅ）の接続状況は、参加者が会議における唯一の聴取される人であるという状況を意味している。聴取（Ｌ）またはミュート（Ｍ）の接続状況は、参加者が発言することなく会議を聴取することができるという状況を意味している。最後に、Ｎｏｎｅの接続状況は、参加者が当該会議に無関係であるという状況を意味している。

本発明によるＭＣＳは、相互会議データベース（ＣＣＤＢ）を利用することにより、少なくとも１人の参加者による複数の会議への参加を制御するものである。ＭＣＵは、ＣＣＤＢに保持される情報に基づき、参加者や会議の接続変更を実行するようにしてもよい。接続変更は現状に関する任意の変更であってもよい。接続変更は、例えば、会議の開始、会議の終了、会議への参加者の追加、あるいは参加者のミュート化などであるかもしれない。ＣＣＤＢは、１つのデータベースで実現されてよいし、あるいは複数のデータベースにより実現されてもよい。例えば、各参加者に対し、ＭＣＵにより現在制御及び／あるいは管理されているすべての会議における当該参加者の接続状況及び／あるいは接続パラメータを含むデータベースであってもよい。他の例として、ＭＣＵにより現在制御されている各会議のデータベースであってもよい。ここで当該データベースには、会議の参加者すべての接続状況及び／あるいは会議の接続パラメータが含まれてもよい。

一実施例において、ＭＣＳは、ある会議における変更のその他の会議の一部あるいはそのすべてに対する効果、及び／あるいはある参加者の接続状況の変更のその他の会議の一部あるいはそのすべてに対する効果を管理する１つ以上のルーチンを備えていてもよい。本出願においては、エンコーダは、以下に限定されるものではないが、Ｇ．７２３．１、Ｇ．７２８、Ｇ．７２９あるいはＭＰＥＧのような通信規格に基づき、参加者の音声信号を圧縮するエンハンス・符号化論理ユニットであってもよい。デコーダは、以下に限定されるものではないが、Ｇ．７２３．１、Ｇ．７２８、Ｇ．７２９あるいはＭＰＥＧのような通信規格に基づき、圧縮音声ストリームを復号化するための論理ユニットであってもい。「ＣＯＤＥＣ」という単語は、論理ユニットとして構成されてもよく、デコーダあるいは復号化セクション、及びエンコーダあるいは符号化セクションを含むユニットをいう。また本出願では、「ブリッジ」という単語は、論理ユニットとして構成されてもよく、会議に関連付けられたユニットをいう。本発明の一実施例による音声セクションは、各参加者のＣＯＤＥＣからの復号化出力のすべての会議のブリッジへの配信を可能にするアーキテクチャを有する。さらに、音声セクションは、任意のブリッジあるいは任意のブリッジグループの出力を、任意の参加者あるいは任意の参加者グループへのルーティングを可能にするよう構成されてもよい。

本発明の他の目的、特徴及び効果は、添付された図面とクレームと共に、以下の実施例に関する詳細な説明を読むことにより明らかになるであろう。
［実施例の説明］
同一の番号により同一の構成要素が表されている図面を参照し、本発明の実施例が説明される。

図１Ａは、複数のエンドポイント（ｅｎｄｐｏｉｎｔ）１１１０ａａ−ｎｋ、オペレータ１１１５、マルチメディア信号１１２０ａａ−ｎｋ、マルチメディア通信１１２２ａ−ｋ、複数のネットワーク１１３０ａ−ｋ及びＭＣＣＵ（Ｍｕｌｔｉｍｅｄｉａ Ｃｏｎｆｅｒｅｎｃｅ Ｃｏｎｔｒｏｌ Ｕｎｉｔ）１１４０からなる会議環境１００の全体を示す一例となるブロック図である。一実施例において、ＭＣＣＵ１１４０は、ＮＩ（Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ）１１４２、ＣＡＣＩ（Ｃｏｍｐｒｅｓｓｅｄ Ａｕｄｉｏ Ｃｏｍｍｏｎ Ｉｎｔｅｒｆａｃｅ）１１０、音声ユニット１１６０、ＭＣＳ（Ｍａｎａｇｅｍｅｎｔ ａｎｄ Ｃｏｎｔｒｏｌ Ｓｙｓｔｅｍ）１１７０、制御信号１１７４、ホスト１２００及び映像ユニット１３００を備える。他の実施例では、映像セクションを備えていないかもしれないし、また音声会議のみのために利用されるかもしれない。

複数のエンドポイント１１１０ａａ−ｎｋが、複数のネットワーク１１３０ａ−ｋを介しＭＣＣＵ１１４０に接続される。ＭＣＣＵ１１４０は、例えば、ＭＣＵあるいは音声のみの多地点接続装置（音声ブリッジ）であってもよい。ＭＣＣＵ１１４０及び／あるいはその構成要素の少なくとも一部は、ハードウェア及び／あるいはソフトウェアにより実現される論理ユニットである。ＭＣＳ１１７０は、制御モジュールであってもよいし、ＭＣＣＵ１１４０の動作を制御する論理ユニットであってもよい。

エンドポイントは、ネットワーク上の端末であり、他の端末あるいはＭＣＣＵ１４４０に一方向または双方向の音声及び／またはビジュアル通信を提供することができる。端末間及び／あるいは端末とＭＣＣＵ１４４０との間で通信される情報は、制御信号、インジケータ、音声情報、映像情報及びデータを含む。端末は、音声のみ、音声とデータ、音声と映像の組み合わせ、あるいは音声、データと映像の組み合わせのような複数のタイプの入力及び／あるいは出力の任意の組み合わせを提供してもよい。

ＮＩ１１４２は、複数のネットワーク１１３０ａ−ｋとマルチメディア信号１１２０ａａ−ｎｋを介し複数のエンドポイント１１１０ａａ−ｎｋからマルチメディア通信１１２２ａ−ｋを受信し、以下に限定されるものではないが、Ｈ．３２３、Ｈ．３２１、ＳＩＰ及び／あるいはＨ．３２０のような各ネットワークタイプにより利用される通信規格に従い当該マルチメディア通信を処理する。ＮＩ１１４２は、その後、ＭＣＵ１１４０の適当な論理モジュールに、圧縮音声、圧縮映像、圧縮データ及び制御ストリームを送信する。通信規格の中には、ＮＩ１１４２の処理に、入力マルチメディア通信を圧縮音声、圧縮映像、圧縮データ及び制御ストリームに逆多重化する処理が含まれることを要求するものもある。その反対方向において、ＮＩ１１４２は、様々なユニット（例えば、ＭＣＳ１１７０、音声ユニット１１６０及び／あるいは映像ユニット１３００）からストリームを受信し、適当な通信規格に従い当該ストリームを処理する。その後、ＮＩ１１４２は処理されたストリームを適当なネットワーク１１３０ａ−ｋに送信する。

音声ユニット１１６０は、ＮＩ１１４２及びＣＡＣＩ１１０を介し複数のエンドポイント１１１０ａａ−ｎｋの圧縮された音声ストリームを受信し、受信した音声ストリームを処理し、関連する音声ストリームをミキシングし、ＣＡＣＩ（Ｃｏｍｐｒｅｓｓｅｄ Ａｕｄｉｏ Ｃｏｍｍｏｎ Ｉｎｔｅｒｆａｃｅ）１１０とＮＩ１１４２を介しエンドポイント１１１０ａａ−ｎｋに圧縮された合成信号を送信する。音声ユニット１１６０は論理ユニットであってよく、図１Ｂに関し以下で説明される。

映像ユニット１３００は、圧縮映像ストリームを送受信する論理ユニットであってよい。映像ユニット１３００は、参加エンドポイントからの映像ストリーム１３０２の入力部分を扱う少なくとも１つの映像入力モジュールと、ＣＶＣＩ（Ｃｏｍｐｒｅｓｓｅｄ Ｖｉｄｅｏ Ｃｏｍｍｏｎ Ｉｎｔｅｒｆａｃｅ）１３０２を介しＮＩ１１４２から送信され、そこから指定されたエンドポイント１１１０ａａ−ｎｋに送信される圧縮映像出力ストリームを生成する少なくとも１つの映像出力モジュールを備える。

解凍された映像データは、以下に限定されるものではないが、ＴＤＭ（Ｔｉｍｅ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅｘｉｎｇ）、ＡＴＭ（Ａｓｙｎｃｈｒｏｎｏｕｓ Ｔｒａｎｓｆｅｒ Ｍｏｄｅ）及び／あるいは共有メモリのような共有インタフェース上で入出力モジュールにより共有される。共有インタフェースでのデータは、完全に解凍されていてもよいし、部分的に圧縮されていてもよい。そのような映像ユニットの一例となる処理が、米国特許第６，３００，９７３号に記述され、その内容は参照することによりここに含まれる。

ホスト１２００は、ＭＣＣＵ１１４０のオペレータ１１１５と通信することが好ましい。ここで、オペレータ１１１５はホスト１２００と通信するためのオペレータステーションを備えてもよい。ホスト１２００は、オペレータ１１１５からの指示に従ってＭＣＳ１１７０を介しＭＣＣＵ１１４０を制御する。

図１Ｂは、概略説明を含む本発明の一実施例による音声ユニット１１６０の一例となるブロック図である。図１Ｂの実施例は、ＣＡＣＩ（Ｃｏｍｐｒｅｓｓｅｄ Ａｕｄｉｏ Ｃｏｍｍｏｎ Ｉｎｔｅｒｆａｃｅ）１１０、制御バス１３５、ＭＣＳ１１７０、圧縮信号１１５と１１７、ＣＯＤＥＣ１２０、復号情報１２６、合成出力１２８、ＤＡＣＩ（Ｄｅｃｏｄｅｄ Ａｕｄｉｏ Ｃｏｍｍｏｎ Ｉｎｔｅｒｆａｃｅ）１４０及びブリッジ１５０を有する音声ユニット１１６０を備える。ＣＯＤＥＣ１２０はデコーダ１２２とエンコーダ１２４を備え、ブリッジ１５０は解析・エンハンスユニット１５２、情報信号１５３、制御ユニット１５４、スイッチ１５６、制御信号１５７、選択信号１５９、ミキサ１６０及び合成信号１６１を備える。図１Ｂは、本発明の一例における音声ストリームのフローを示す。圧縮音声ストリームは、ＭＣＵに接続されているすべてのエンドポイントからＣＡＣＩ（Ｃｏｍｐｒｅｓｓｅｄ Ａｕｄｉｏ Ｃｏｍｍｏｎ Ｉｎｔｅｒｆａｃｅ）１１０上に送信される。ＭＣＳ１１７０は、ＣＯＤＥＣ１２０をエンドポイント１１１０ａａ−ｎｋ（図１Ａ）の各々に割り当てる。

さらに、ＣＡＣＩ１１０は、エンドポイント１１１０ａａ−ｎｋ間で信号の搬送を行う。例えば、エンドポイント１１１０ａａ−ｎｋの１つからの圧縮信号１１５が、ＣＡＣＩ１１０を介し以前に制御バス１３５を介しＭＣＳ１１７０により当該エンドポイントに割り当てられたＣＯＤＥＣ１２０のデコーダ１２２に送信される。デコーダ１２２は論理ユニットであってよく、以下に限定されるものではないが、Ｇ．７２３．１、Ｇ．７２８、Ｇ．７２９及びＭＰＥＧのような通信規格に基づき圧縮音声ストリームを復号化してもよい。その後デコーダ１２２は圧縮信号１１５のような圧縮音声ストリームを復号化し、この復号化された信号１２６をＤＡＣＩ（Ｄｅｃｏｄｅｄ Ａｕｄｉｏ Ｃｏｍｍｏｎ Ｉｎｔｅｒｆａｃｅ）１４０上に配信する。ＤＡＣＩ１４０は、配信（ｂｒｏａｄｃａｓｔｉｎｇ）機能を有するバスである。ＤＡＣＩ１４０は、例えば、ＴＤＭ（Ｔｉｍｅ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅｘｉｎｇ）、ＡＴＭ（Ａｓｙｎｃｈｒｏｎｏｕｓ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｍｏｄｅ）、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、無線技術、または共有メモリの何れかあるいは任意の組み合わせにより実現されてもよい。その後、ブリッジ１５０は、ＤＡＣＩ１４０から復号化信号を取得し、当該信号を解析、向上及び／あるいはミキシングし、その出力１６１をＤＡＣＩ１４０に返すようにしてもよい。

エンコーダ１２４は、論理ユニットであって、エンハンス及び／または符号化ユニットであってもよい。エンコーダ１２４は、以下に限定されるものではないが、Ｇ．７２３．１、Ｇ．７２８、Ｇ．７２９及び／あるいはＭＰＥＧ（Ｍｏｔｉｏｎ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔ Ｇｒｏｕｐ）のような通信規格に基づき、圧縮信号１１７のような圧縮音声ストリームを形成する適切なブリッジ１５０の出力１２８を圧縮してもよい。

ＭＣＳ１１７０は、ＭＣＵに現在あるすべての参加者及びすべての会議の必要な設定に基づきＣＣＤＢ（Ｃｒｏｓｓ−Ｃｏｎｆｅｒｅｎｃｅｓ Ｄａｔａｂａｓｅ）を生成する。ＣＣＤＢは、ＭＣＵにより現在管理されているすべての会議において、ＭＣＵに現在接続されている各エンドポイントの接続パラメータ（例えば、ＣＯＤＥＣ及びブリッジなど）と接続状況（例えば、ノーマル、ミュートなど）を保持する相互会議データベース（Ｃｒｏｓｓ−Ｃｏｎｆｅｒｅｎｃｅ Ｄａｔａｂａｓｅ）である。ＣＣＤＢは、少なくとも１人の参加者の複数の会議への参加を可能にする。ＣＣＤＢは図２に関し以下で説明される。ＣＣＤＢによると、ＭＣＳ１１７０は１つ以上のブリッジ１５０をプログラムし、ＤＡＣＩ１４０からこれらのブリッジ１５０に割り当てられた会議に関するすべての参加者の復号化された信号を取得する。

任意のＣＯＤＥＣ１２０の復号化された出力は、参加者を複数の会議に関連付けることを可能にする複数のブリッジ１５０により取得される。ＤＡＣＩ１４０におけるデコーダ１２２からの復号化ストリームは、ブリッジ１５０により取得され、その後解析・エンハンスユニット１５２により解析及び向上される。解析・エンハンスユニット１５２は、論理ユニットであってよく、以下に限定されるものではないが、ＩＴＵ（Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｕｎｉｏｎ）Ｇ．１６５（エコー除去）、ＤＴＭＦ（Ｄｕａｌ Ｔｏｎｅ Ｍｕｌｔｉ−Ｆｒｅｑｕｅｎｃｙ）抑制、及び／あるいはＶＡＤ（Ｖｏｉｃｅ Ａｃｔｉｖｉｔｙ Ｄｅｔｅｃｔｏｒ）のような参加者の音声ストリームの解析及び／あるいはその質の向上のためのアルゴリズム群を備えていてもよい。

ブリッジ１５０は、各解析・エンハンスユニット１５２が１人の参加者に割り当てられ、会議における当該参加者の接続状況に応じプログラムされる。制御ユニット１５４は、解析・エンハンスユニット１５２からのすべての信号を受信し、スイッチ１５６を介しミキサ１６０にルーティングされる参加者を選択する会議を制御する。ミキサ１６０は、選択された参加者すべてからエンハンスストリームを受信し、この選択された参加者の解凍された合成音声ストリームを各参加者に供給する。解析・エンハンスユニット１５２からの信号は制御ユニット１５４に送信され、エンハンス復号化音声信号が解析・エンハンスユニット１５２からスイッチユニット１５６に送信される。スイッチユニット１５６は、会議の参加者すべてから復号化ストリームを受信し、選択されたストリームをミキサ１６０に送信するセレクタである。この選択は、制御ユニット１５４の決定に基づく。ブリッジ１５０に割り当てられた会議の参加者の接続状況と、解析・エンハンスユニット１５２からの情報信号１５３を定義するＭＣＳ１１７０からの受信コマンドに基づき、制御ユニット１５４は制御信号１５７を介しスイッチ１５６とミキサ１６０を制御する。例えば、参加者の接続状況がノーマル（Ｎ）である場合、当該参加者に関する解析・エンハンスユニット１５２は、音声信号がＶＡＤ（例えば、ある値を上回るエネルギーレベルのような）のようなある基準を満たすということを示してもよい。その後、制御ユニット１５４は、スイッチ１５６を介し、この参加者に割り当てられる解析・エンハンスユニット１５２の出力をミキサ１６０への入力の１つとして選ぶ。ミキサ１６０は、選ばれた音声信号をミキシングし、合成信号１６１を生成し、ＤＡＣＩ１４０上に配信する。ブリッジ１５０の実施例の中には、発言者の声を当該発言者のエンドポイントに向けられた合成信号から除去することができるものもある。

ＣＣＤＢに保持された接続状況に基づき、ＭＣＳ１１７０は１つ以上のＣＯＤＥＣ１２０に会議を聴取するためＤＡＣＩ１４０から合成出力１２８を取得するよう指示する。ＤＡＣＩ１４０から合成出力１２８の取得後、エンコーダ１２４は、適当なブリッジ１５０から復号化信号を符号化し、ＣＡＣＩ１１０を介し圧縮信号１１７を適当な参加者に送信する。

ＣＯＤＥＣ１２０とブリッジ１５０は、以下に限定されるものではないが、Ｔｅｘａｓ Ｉｎｓｔｒｕｍｅｎｔｓ ＤＳＰ，やＴＭＳ３２０Ｃ３１のようなデジタル信号プロセッサ（ＤＳＰ）により実現されてもよい。１つのＤＳＰには、複数のユニット（例えば、複数のＣＯＤＥＣ及び／またはブリッジ）が含まれうる。上記例では、ＣＯＤＥＣ１２０は１人の参加者の音声信号を扱い、ブリッジ１５０は１つの会議を扱う。

図１Ｃを参照するに、図１Ｂのシステムの動作方法１７０を示すフローチャートが示される。方法１７０において、合成信号はエンドポイント１１１０ａａ−ｎｋ（図１Ａ）に配信される。具体的には、方法１７０はステップ１７２から開始され、ＭＣＳ１１７０（図１Ａ）は、ホスト１２００（図１Ａ）あるいは１つ以上のエンドポイント１１１０ａａ−ｎｋ（図１Ａ）から、進行中あるいは開始される必要のある会議の構成に関する信号を受信する。エンドポイント１１１０ａａ−ｎｋは、マルチメディア信号１１２０ａａ−ｎｋ（図１Ａ）をネットワークａ−ｋに送信し、その後マルチメディア通信１１２２ａ−ｋ（図１Ａ）をＮＩ１１４２（図１Ａ）に送信することにより、間接的にＭＣＳ１１７０を通信する。その後、ＮＩ１１４２は、会議の設定のため制御信号１１７４をＭＣＳ１１７０に送信することによりマルチメディア通信１１２２ａ−ｋに応答する。一実施例では、音声ユニット１１６０（図１Ａ）及び／あるいは映像ユニット１３００（図１Ａ）は、会議の設定のため、制御信号１１７４（図１Ａ）に加えて、あるいはそれの代わりにＭＣＳ１１７０に制御信号を送信してもよい。

次に、ステップ１７４において、ＭＣＳ１１７０は、会議がどのように設定されるかについての情報が保持されている１つ以上のＣＣＤＢの構築及び／あるいは更新を実行し、制御信号を制御バス１３５（図１Ｂ）に配信する。その後、ステップ１７６において、ＣＯＤＥＣ１２０は、ＣＣＤＢの中の当該会議の構成に従って、各ＣＯＤＥＣ１２０をエンドポイント及び／あるいは参加者と関連付ける制御信号を制御バス１３５から受信及び／あるいは取得する。その後、ステップ１７８において、ブリッジ１５０（図１Ｂ）は、各解析・エンハンスユニット１５２をエンドポイント及び／あるいは参加者と関連付ける制御信号を制御バス１３５から受信及び／あるいは取得する。次に、ステップ１８０において、１つ以上のエンドポイントからの圧縮音声信号がＣＡＣＩ１１０（図１Ｂ）に配置あるいは配信される。その後、ステップ１８２において、ＣＯＤＥＣ１２０の対応するデコーダ１２２（図１Ｂ）がＣＡＣＩ１１０から圧縮信号の取得及び／あるいは受信を行い、復号化信号１２６（図１Ｂ）を生成するため圧縮信号１１５を復号化し、この復号化信号１２６をＤＡＣＩ１４０（図１Ｂ）に配信する。

その後、ステップ１８４において、解析・エンハンスユニット１５２（図１Ｂ）は、ＣＣＤＢから駆動されるＭＣＳ１１７０からの制御信号に従って、ＤＡＣＩ１４０から（復号化信号１２６から導出されうる）復号化信号１４１（図１Ｂ）の取得及び／あるいは受信を行う。また、ステップ１８４において、解析・エンハンスユニット１５２は、復号化信号１４１を向上させ、エンハンス信号１５５（図１Ｂ）を生成し、制御情報１５３（図１Ｂ）を抽出する。その後、エンハンス信号１５５はスイッチ１５６（図１Ｂ）に送信され、制御情報１５３は制御ユニット１５４（図１Ｂ）に送信される。

ステップ１９０において、制御ユニット１５４は、（ステップ１７４においてＣＣＤＢから駆動される）ＭＣＳ１１７０及び／あるいは制御情報１５３に基づき制御信号１５７（図１Ｂ）を生成する。ステップ１９１において、制御信号１５７及び／あるいはＭＣＳ１１７０からの制御信号に基づき、スイッチ１５６はどのエンハンス信号１５５が選択信号１５９（図１Ｂ）としてミキサ１６０（図１Ｂ）に送信されるか選ぶ。これに応答して、ステップ１９２において、ミキサ１６０は選択信号１５９をミキシングし、ＭＣＳ１１７０からの制御信号に従い合成信号１６１（図１Ｂ）を生成し、ＤＡＣＩ１４０に配信する。ステップ１９４において、ＣＣＤＢ（ステップ１７４）に基づき、１つ以上のエンコーダ１２４は、（合成信号１６１から導出されうる）合成出力１２８の取得及び／あるいは受信を行い、この合成出力１２８を符号化し、圧縮音声信号１１７（図１Ｂ）を生成する。その後、圧縮音声信号１１７はＣＡＣＩ１１０に配信される。最後に、ステップ１９６において、エンドポイント１１１０ａａ−ｎｋはＮＩ１１４２及びネットワーク１１３０ａ−ｋを介し合成された圧縮音声信号の取得及び／あるいは受信を行う。

方法１７０の各ステップが、それの理解を容易にする順序で提供された。しかしながら、方法１７０の各ステップは任意の順序により実行されてもよい。ＣＣＤＢ（ステップ１７４）に保持されている情報に従い、あるエンドポイントは発言のみ可能で、また他のエンドポイントは聞くことのみ可能であるかもしれないので、（発言のみのエンドポイントに関連する）あるＣＯＤＥＣ１２０は特定のエンドポイントからの圧縮信号１１５の取得及び／あるいは受信を行い、この圧縮信号１１７を（聴取する他のエンドポイントのために）配信し、他のＣＯＤＥＣ１２０は圧縮信号１１５の（それに関連するエンドポイントから）取得及び／あるいは受信を行わず、合成された圧縮信号１１７をそれに関連するエンドポイントに送信してもよい。

図２は、ＣＣＤＢの一例である。各列は会議及び当該会議に関連付けされたブリッジ１５０（図１Ａ）を表す。図２で、参加者は１からＮ＋２にラベル付けされ、会議はＡからＸにラベル付けされる。会議に利用されるブリッジはＢ１からＢｚにラベル付けされる。フランス語を話す参加者は「Ｆ」、英語を話す参加者は「Ｅ」が付けられる。英語からフランス語への通訳は「ＥＦ」、フランス語から英語への通訳は「ＦＥ」が付けられる。利用されるＣＯＤＥＣ」はＣ０１からＣｋにラベル付けされる。「Ｎ」の付いたセルはノーマル状況を、「Ｓ」の付いたセルは発言状況を、空のセルは「Ｎｏｎｅ」状況を表す。

例えば、列Ａ２０２（すなわち、会議Ａ）はブリッジ＃３（すなわち、Ｂ３）を使い、第１行はＣＯＤＥＣ＃１１（Ｃ１１）２０６を使っている参加者＃１である。現在の例は５つの会議を有するケースを示している。第１会議は会議Ａであり、ブリッジとしてＢ３を利用する。会議Ａは１、２、３、４、５、６とラベル付けされた６人の参加者を有し、それぞれＣ１１、Ｃ２１、Ｃ１３、Ｃ０５、Ｃ０７及びＣ０６を有するＣＯＤＥＣ１２０（図１Ｂ）を利用する。この会議では、（英語を話す人々）参加者１、３、５と（フランス語から英語への通訳）６の接続状況は「ノーマル」（Ｎ）である。Ｎの接続状況は、参加者が会議において発言及び聴取が可能であるということを意味する。会議に関連付けされるブリッジ１５０、この場合ブリッジＢ３は、参加者１、２、３、４、５、６の１人と関連付けされる各デコーダ１２２（図１Ｂ）から復号化情報１２６を取得し、その結果、参加者の復号化情報が当該会議の他の音声信号とミキシングされ、参加者１、２、３、４、５、６は聴取される。１、３、５及び６の各参加者に対し、参加者に関連付けされるエンコーダ１２４（図１Ｂ）は、参加者１、３、５及び６が会議を聴取できるようブリッジ（Ｂ３）の合成出力１２８（図１Ｂ）を取得する。

会議Ａにおいて、（フランス語を話す）参加者２と４の接続状況は「発言」（Ｓ）である。Ｓの接続状況は、参加者２と４が会議において聴取されうるが、その会議を聞くことはできないということを意味している。参加者２と４の各々に対し、会議に関連付けられるブリッジ１５０、この場合ブリッジＢ３は、復号化情報が会議の他の音声信号とミキシングされ、参加者２と４が聴取されることが可能になるよう参加者に関連付けされたデコーダ１２２から復号化情報１２６を取得する。

第２の一例となる会議である会議ＢはブリッジＢ１を利用する。会議Ｂは、１、２、３、４、５及び７の６人の参加者からなり、それぞれがＣＯＤＥＣ番号Ｃ１１、Ｃ２１、Ｃ１３、Ｃ０５、Ｃ０７及びＣ１７を利用し、会議に接続されている。この会議では、（英語を話す）参加者１、３及び５の接続状況はＳである。従って、参加者１、３及び５は会議においてその発言が聴取されるが、聞くことはできない。会議に関連付けられるブリッジ１５０、ここではブリッジＢ１は、参加者１、３及び５のデコーダ１２２から、これらの参加者の音声信号が会議の残りの音声信号とミキシングされるよう復号化情報を取得する。

会議Ｂに関して、さらに、（フランス語を話す）参加者２と４、及び（英語からフランス語への通訳）参加者７の接続状況は「ノーマル」（Ｎ）である。従って、参加者２、４及び７は、当該会議での発言及び聴取の両方が可能である。参加者２、４及び７の各々の発言は、これらの参加者に関連付けされているデコーダ１２２から復号化情報を取得するブリッジＢ１により可能にされ、これらの参加者の復号化情報は当該会議の他の音声信号とミキシングされ、参加者２、４及び７の発言は聴取可能となる。参加者の１人に関する聴取処理は、ブリッジ（Ｂ１）の合成出力１２８を取得する参加者に関連づくされているエンコーダ１２４により可能にされる。

第３の一例となる会議である会議ＣはブリッジＢ５を利用し、それぞれが番号Ｃ０８とＣ０１のＣＯＤＥＣを利用している２人の参加者８と９を有する。この会議において、２人の参加者の接続状況は「ノーマル」（Ｎ）である。

第４の一例となる会議である会議Ｄでは、ブリッジＢ４が利用される。会議Ｄは、ＣＯＤＥＣ番号Ｃ０８、Ｃ０１、Ｃ１０及びＣ０４を使用している４人の参加者８、９、１０及び１１を有する。会議Ｄでは、参加者８と９の接続状況は「発言」（Ｓ）である。Ｓの接続状況は、参加者８と９が当該会議においてその発言を聴取されるが、当該会議を聴取することはできないということを意味している。参加者８と９のそれぞれに対し、会議に関連付けられるブリッジ１５０、この場合ブリッジＢ４は、当該参加者に関連付けられるデコーダ１２２から、復号化情報が会議の他の音声信号とミキシングされ、参加者８と９が聴取されうるよう復号化情報１２６を取得する。参加者１０と１１の接続状況は「ノーマル」（Ｎ）である。従って、参加者１０と１１のそれぞれに対し、ブリッジＢ４は、当該参加者に関連付けられているデコーダ１２２から復号化情報１２６を取得し、当該参加者のエンコーダ１２４はブリッジＢ４の合成出力１２８を取得する。

最後の一例となる実施例である会議Ｘは、ブリッジＢｚを利用し、それぞれＣＯＤＥＣ番号Ｃｍ、Ｃｌ及びＣｋを利用している３人の参加者Ｎ、Ｎ＋１及びＮ＋２を有する。会議Ｘは、すべての参加者の接続状況が「ノーマル」（Ｎ）である共有会議である。

上記の例は少なくとも２つの特殊ケースを示している。第１のケースは、２つの関連する会議ＡとＢを組み合わせたものであり、フランス語から英語への通訳（ＦＥ）を伴う３人の英語を話す人々と、英語からフランス語への通訳（ＥＦ）を伴うフランス語を話す人からなる会議である。

第２のケースは、２つの関連する会議ＣとＤを組み合わせたものであり、２人の参加者８と９が互いにある問題を論じる一方、他の参加者１０と１１がその議論を聞くことができるというケースである。参加者１０と１１は、参加者８と９に聞かれることなく互いの内部的な議論を行うことができる。

会議の参加者のインスタンスは、特定の参加者を表すオブジェクト（あるいはこのオブジェクトのインスタンス化）への呼び出しであってもよい。参加者のインスタンスの存在は、当該会議におけるこの参加者の接続状況が「Ｎｏｎｅ」ではないということを意味している。他の実施例では、会議は、以下に限定されるものではないが、「排除（Ｅｘｃｌｕｓｉｖｅ）」（Ｅ）と「聴取（Ｌｉｓｔｅｎｉｎｇ）」（Ｌ）のような接続状況を利用してもよい。Ｅの接続状況では、参加者は会議においてその発言を聴取される唯一の参加者である。また、Ｌの接続状況では、参加者は発言なしで会議を聞くことができる。

接続状況ＥとＬの一方あるいは両方が、接続状況Ｍ、Ｎ及びＮｏｎｅの少なくとも１つとともに利用されてもよい。例えば、一例として、接続状況Ｎ、Ｅ、Ｌ及びＮｏｎｅが含まれる場合と、他の例として、接続状況Ｍ、Ｎ、Ｅ、Ｓ及びＮｏｎｅが含まれるケースがある。

本明細書では、接続変更とは、会議の現在の状況や構成に関する任意の変更である。この接続変更は、例えば、会議の開始、会議の終了、参加者の追加、あるいは参加者のミュート化などである。ＣＣＤＢに収められている情報に基づき、ＭＣＳ１１７０（図１Ａ）は、ＣＯＤＥＣ１２０のデコーダ１２２及びエンコーダ１２４にどの情報がＣＡＣＩ１１０（図１Ａ）及び／あるいはＤＡＣＩ１４０（図１Ｂ）から取得されるべきかを決定するコマンドを送信することにより、及び／あるいはブリッジ１５０にどの情報がＤＡＣＩ１４０から取得されるべきかを決定するコマンドを送信することにより、接続変更を実行するようにしてもよい。

本発明は、特定タイプのデータベースに制限されるものでなく、上記開示されたもの以外のタイプのデータベースを利用してもよい。例えば、データベースＣＣＤＢは、各参加者に対し１つのデータベースを有するデータベース群を含むよう構成されてもよい。このような各参加者のデータベースは、各会議における当該参加者の接続状況を有するよう構成されてもよい。また、このようなデータベース群に加え、ＣＣＤＢは、各会議に対し１つのデータベースを有するデータベース群を含むよう構成されてもよい。各データベースは、当該会議に関係する参加者を有するよう構成されてもよい。またコントローラが１つのデータベースから他のデータベースに移ることができるようデータベース間で関連付けがなされていてもよい。

図３は、参加者の接続を解除する一例となる方法３００の各ステップを示すフローチャートである。方法３００は、参加者の接続を解除することにより影響を受ける会議接続を更新する。さらに、方法３００は参加者がもはやどの会議にも接続されていないという状態にすることができる。また、接続を解除される参加者は、会議を終了させる状態にすることができる（なぜなら、例えば、その会議に残っている参加者がたった１人であるため）。これにより、方法３００はまた、接続解除により終了させられるべき会議を確実に終了させることができる。

ステップ３１０において、ＭＣＳ１１７０（図１Ａ）がホスト１２００（図１Ａ）あるいはＮＩ１１４２（図１Ａ）から参加者の接続が解除されたという制御信号１１７４（図１Ａ）を受信すると、ＭＣＳ１１７０は方法３００の接続解除ルーチンを開始する。ステップ３２０において、ＭＣＳ１１７０は接続を解除された参加者に関するＣＣＤＢへのエントリを検索する。このステップにおいて、例えば、図２のＣＣＤＢの適当な行が検出される。

その後、ステップ３３０において、ＭＣＳ１１７０は、ＭＣＵにより現在管理されているすべての会議を含むループである会議ループを開始する。このループは会議ごとに検索されるかもしれない。例えば、ＭＣＳ１１７０は、ＭＣＵにより現在いくつの会議が管理されているかをチェックし、そのパラメータＫを保存するかもしれない。その後、ＭＣＳ１１７０は、変数ｊを１として、例えば、図２のＣＣＤＢの適当な行に沿って検出された第１会議に移動する。

ステップ３４０において、ＭＣＳ１１７０は、会議において接続解除されている参加者の接続状況が「Ｎｏｎｅ」であるかチェックする。もし「Ｎｏｎｅ」でなければ、ＭＣＳ１１７０はステップ３５０に進む。他方もし「Ｎｏｎｅ」であれば、ＭＣＳ１１７０はステップ３８５に進む。ステップ３５０において、ＭＣＳ１１７０は、例えば、新しい状況により図２のＣＣＤＢを更新する（例えば、参加者の接続状況を「Ｎｏｎｅ」に変更する）。その後、ステップ３６０において、ＭＣＳ１１７０は、参加者の１人が接続解除されたということを示す信号を、会議の残りの参加者に送信する。

その後、ステップ３７０において、ＭＣＳ１１７０は、終了条件が満たされているかチェックする。この終了条件は、会議への参加者が２人未満になると発生する。あるいは、参加者の人数が所定の閾値を下回ると終了条件が発生する。この所定の閾値は、例えば、財政あるいはその他の事情により決定される。終了条件には、参加人数が所定の人数を下回ることに加え、あるいはその代わりに必要とされる会議を終了させるリクエストが含まれてもよい。会議の終了は図４に関し説明される方法により実行することができる。終了条件は、複数の終了条件からなる論理関数であってもよいし、ある終了方針に従い動的に変更されるものであってもよい。終了条件が満たされると、ＭＣＳ１１７０はステップ３６５に移り、会議を終了させる。しかしながら、もし終了条件が満たされなければ（例えば、２人より多く参加者がいる場合）、ＭＣＳ１１７０は会議を継続することができ、ステップ３８５に移る。

ステップ３８５において、ＭＣＳ１１７０は、変数ｊを１だけ増やし、ステップ３９０において、ループを抜け出るための脱出条件が満たされているかチェックする。例えば、脱出条件はすべての会議がチェックされたかを示す条件であるかもしれない（すなわち、ｊ＝Ｋ）。その後、ＭＣＳ１１７０は、ステップ３９５に移行し、ループを抜け出し、接続解除方法を終了させる。脱出条件が満たされていない場合、ステップ３９７において、ＭＣＳ１１７０は次の行の会議に移行し、ステップ３４０に戻る。方法３００の例による参加者はすべての会議から接続解除されているが、１つ以上の特定の会議を除くすべての会議から参加者を接続解除する類似の方法が使われてもよい。

図４は、会議を終了させる（すなわち、図３のステップ３６５）ための一例となる方法４００の各ステップを示すフロー図である。方法４００は、会議の参加者すべてに当該会議が終了処理にあるということを通知する。参加者がこの会議に接続し、かつ参加者の状況が接続解除基準を満たしていない場合、方法４００は当該参加者を接続解除する。会議終了後、ＣＣＤＢは、ＭＣＳ１１７０（図１Ａ）が終了された会議に関する制御信号を送信しないよう更新される必要がある。参加者への通知及び接続解除後、方法４００はＣＣＤＢを更新し、会議が接続解除されたことを反映させる。

ステップ４１０において、ＭＣＳ１１７０が会議を終了させるコマンドを受信すると、ＭＣＳ１１７０は方法４００の終了ルーチンを開始する。ステップ４２０において、ＭＣＳ１１７０は終了予定の会議に関するＣＣＤＢエントリを検索する。例えば、このステップでは、図２のＣＣＤＢの中から適当な列が検出される。

その後、ステップ４３０において、ＭＣＳ１１７０は、当該会議に現在接続されているすべての参加者含む参加者ループを開始する。ＭＣＳ１１７０は、会議に何人の参加者が現在接続されているかをチェックし、参加人数（パラメータＰ）を記憶する。ＭＣＳ１１７０（図１）は、変数ｊを１とし、適当な列（あるいは会議）に沿って第１参加者に移行する。その後、ステップ４３５において、ＭＣＳ１１７０は新たな会議状況によりＣＣＤＢを更新する（例えば、変数ｊの参加者の接続状況を「Ｎｏｎｅ」に変更する）。

ステップ４４０において、ＭＣＳ１１７０は参加者ｊに対し終了条件をチェックする。例えば、終了条件は、この参加者が他のどの会議にも接続されていない場合に関するものであるかもしれない。ＣＣＤＢのこの参加者の対応する行を観察することによりこのチェックは実行されるかもしれない。この参加者が他のどの会議とも関係ないか、あるいは他のどの会議のインスタンスも有していなければ、参加者ｊの終了条件は満足される。この例で、この参加者が他の会議においてインスタンスを有している場合、ＭＣＳ１１７０はステップ４４５に進み、そうでない場合、ＭＣＳ１１７０はステップ４５０に進む。ステップ４５０において、ＭＣＳ１１７０は当該会議が終了されるという表示を参加者ｊに送信し、ステップ４５５において、参加者ｊの接続を解除する。他の例による方法では、ＭＣＳ１１７０は他の終了条件あるいは参加者を接続解除する他の方針を持っていてもよい。この接続条件は動的なものであってもよいし、当該参加者及び」／あるいはすべての会議において「Ｎｏｎｅ」状況を有する参加者に加えて、あるいはその代わりの他の者に対する終了リクエストを要求してもよい。もし終了条件が満たされなければ、例えば、当該参加者が他の会議４４０に接続されている場合、ステップ４４５において、ＭＣＳ１１７０はオペレータ及び／あるいは参加者に当該会議が終了されるという表示を送り、ステップ４６５において、方法４００はステップ４６５に移行する。

ステップ４６５において、ＭＣＳ１１７０は変数ｊを１だけ増やし、ステップ４７０において、ｊ＝Ｐであるかチェックする。ｊ＝Ｐが成り立っている場合、ＭＣＳ１１７０はステップ４７７に進み、ＣＣＤＢから適当な列を削除する。次に、方法４００は、ステップ４８０に進み、会議終了処理を終える。そうでなければ（もしｊ≠Ｐ）、ＭＣＳ１１７０はステップ４３５に進み、次の列の参加者を処理する。

ＭＣＳ１１７０がソフトウェア、ハードウェア及び／あるいはファームウェアの何れか
またはそれらを組み合わせたものとして構成されうるということは当業者には理解されるであろう。もしＭＣＳ１１７０がソフトウェアである場合、ＭＣＳ１１７０は関連するＭＣＵのホストコンピュータ内に設置されていてもよい。あるいは、ＭＣＳ１１７０がハードウェアである場合、ＭＣＳ１１７０はＭＣＵ内の追加ユニットとして構成されてもよい。

さらに、ＣＣＤＢが１つのデータベースあるいは複数の関連し合うデータベースにおいて実現されうるということは当業者には理解されるであろう。例えば、ＣＣＤＢは、各参加者に対し、ＭＣＵ及び／あるいは当該参加者の接続パラメータにより現在制御されているすべての会議における参加者の接続状況を含むデータベースからなるデータベース群に配置されていてもよい。

本出願の説明及びクレームにおいて、「構成する（ｃｏｍｐｒｉｓｅ）」、「含む（ｉｎｃｌｕｄｅ）」、「有する（ｈａｖｅ）」の各動詞、及びそれらの活用形を使って、当該動詞の目的語が必ずしも主語のメンバー、構成要素、要素あるいは部分の完結したリストではないということを示す。本発明は、実施例を通じ与えられ、本発明の範囲を制限するものでない本発明による方法の詳細な説明を使って記述された。説明された方法は、様々な特徴から構成され、そのすべてが本発明のすべての実施例において要求されるものではない。本発明のいくつかの実施例は、これらの特徴のいくつか、あるいはそれらの可能な組み合わせを利用している。説明された本発明の実施例の変形や、上述の実施例において示された他の特徴の組み合わせを有する本発明の実施例が、当業者には思い付くかもしれない。本発明の範囲は、以下のクレームによってのみ制限される。

図１Ａは、会議環境を示すブロック図である。 図１Ｂは、音声ユニットの概略説明を含む本発明の一実施例のブロック図である。 図１Ｃは、図１Ｂの実施例の動作方法のフローチャートである。 図２は、相互会議データベース（ＣＣＤＢ）の一例である。 図３は、参加者の接続解除のための一例となる方法の各ステップを示すフロー図である。 図４は、会議を終了させるための一例となる方法の各ステップを示すフロー図である。

Claims (6)

1. 複数の参加者の複数の同時的なビデオ会議を制御する方法であって、
   各参加者及び各ビデオ会議に割り当てられるリソースを示す接続パラメータと特定のビデオ会議において参加者が送受信可能な音声及び映像を示す接続状況とを有する情報から構成される前記複数の参加者のための相互会議データベースを構築するステップと、
   多地点接続装置によって、前記相互会議データベースの前記情報に従って、前記複数の参加者のビデオ会議を確立するステップと、
   を有し、
   少なくとも１人の参加者が、２以上のビデオ会議に同時に参加し、前記ビデオ会議の少なくとも２つにおいて、前記相互会議データベースによって規定される異なる接続状況を有することが可能である方法。
2. 前記相互会議データベースの前記情報に基づき、接続変更を実行するステップをさらに有し、
   該接続変更を実行するステップは、
   前記接続変更に関係するすべての参加者及びすべてのビデオ会議を検出するステップと、
   前記接続変更が前記複数のビデオ会議と前記複数の参加者のそれぞれにどのような影響を及ぼすか判断するステップと、
   前記判断の結果に従い前記相互会議データベースを更新するステップと、
   前記更新の結果を実現するステップと、
   を有する、請求項１記載の方法。
3. 複数の参加者の複数の同時的なビデオ会議を実行する方法であって、
   複数のエンドポイントから音声信号を受信するステップと、
   前記音声信号を音声共有インタフェース上に配信するステップと、
   各参加者及び各ビデオ会議に割り当てられるリソースを示す接続パラメータと特定のビデオ会議において参加者が送受信可能な音声及び映像を示す接続状況とを有する情報から構成される前記複数の参加者のための相互会議データベースを利用して、ミキシング対象となる少なくとも１つの音声信号を選択するステップと、
   前記選択された音声信号をミキシングするステップと、
   前記相互会議データベースの前記情報に従って、前記ミキシングされた信号を少なくとも１つのエンドポイントに送信するステップと、
   を有し、
   少なくとも１人の参加者が、２以上のビデオ会議に同時に参加し、前記ビデオ会議の少なくとも２つにおいて、前記相互会議データベースによって規定される異なる接続状況を有することが可能である方法。
4. 複数の参加者の複数の同時的なビデオ会議への参加を管理する管理制御システムを有する多地点制御ユニットであって、
   該管理制御システムは、各参加者及び各ビデオ会議に割り当てられるリソースを示す接続パラメータと特定のビデオ会議において参加者が送受信可能な音声及び映像を示す接続状況とを有する情報から構成される前記複数の参加者のための相互会議データベースを有し、前記複数のビデオ会議の２つ以上が互いに関連する多地点制御ユニット。
5. 複数の関連するビデオ会議を管理及び制御する管理制御システムを有する多地点制御ユニットを有するシステムであって、
   前記複数のビデオ会議の２つは、該２つのビデオ会議に参加する少なくとも１人の参加者を有することにより関連付けられ、
   当該システムは、各参加者及び各ビデオ会議に割り当てられるリソースを示す接続パラメータと特定のビデオ会議において参加者が送受信可能な音声及び映像を示す接続状況とを有する情報から構成される前記複数の参加者のための相互会議データベースを構築するシステム。
6. 前記接続状況は、ノーマル、Ｎｏｎｅ、排除、ミュート、強制、発言及び聴取の少なくとも１つに関する状況を備える、請求項１記載の方法。

Images