JP3973966B2 - 多地点会議システム、多地点会議システムの端末装置、および多地点会議システムのデータミキシング処理装置 - Google Patents
多地点会議システム、多地点会議システムの端末装置、および多地点会議システムのデータミキシング処理装置 Download PDFInfo
- Publication number
- JP3973966B2 JP3973966B2 JP2002136913A JP2002136913A JP3973966B2 JP 3973966 B2 JP3973966 B2 JP 3973966B2 JP 2002136913 A JP2002136913 A JP 2002136913A JP 2002136913 A JP2002136913 A JP 2002136913A JP 3973966 B2 JP3973966 B2 JP 3973966B2
- Authority
- JP
- Japan
- Prior art keywords
- data
- packet data
- mixing
- synchronization
- transmission
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Description
【０００１】
【発明の属する技術分野】
この発明は通信網上で３人以上の利用者による会議を実現する技術に関するものである。
【０００２】
【従来の技術】
通信網上で二者が会議を行う場合には、自分が発した音声データを相手に送信し、相手が発した音声データを受信することにより通話することが可能である。しかし、三者以上が通信網上の会議を行う場合、従来は、ミキサーによって参加者の音声を合成してから音声データを各参加者に送信する手順が必要であった。図１４は、従来の三者通話について概念的に表す図である。図１４においては、多地点通信制御装置（Ｍｕｌｔｉｐｏｉｎｔ Ｃｏｎｔｒｏｌ Ｕｎｉｔ：以下、ＭＣＵと略す）１０００を介して、３つの通話用端末装置１００１〜１００３が、音声データをやりとりする場合を示している。
【０００３】
まず、通話用端末装置（端末Ａ〜Ｃ）１００１〜１００３から発話音声データ１００４、１００５、および１００６がそれぞれＭＣＵ１０００へと送信され、ＭＣＵ１０００のデータ受信バッファ１０１０に記憶される。これらの発話音声データ１００４〜１００６は、図示しないミキサーにて各通話用端末装置向けの受話音声データ１００７〜１００９としてミキシングされ、データ送信バッファ１０１１から通話用端末装置１００１〜１００３に対しそれぞれ送信される。このとき、自己が発した音声データが受信する音声データに含まれていると、他者の音声が聞き取りにくくなるため、ミキサーは、それぞれの受話音声データ１００７〜１００９に、当該データを受信する通話用端末装置を使用する各参加者の音声データが含まれないように、参加者ごとの送信キューを作成していた。
【０００４】
【発明が解決しようとする課題】
上記のような従来のＭＣＵには、参加者ごとに異なる音声データをミキシングして送るため、参加者が増えるたびにそのデータ量が増大し、帯域を有効活用できないという問題がある。
【０００５】
ミキサーがマルチキャストで音声データを送信し、参加者全員に同一の音声データを送信することで、帯域の有効活用は行えるが、この場合は自分自身が発した音声まで受信してしまうことになり、音声が聞き取りにくくなって会話がしづらくなるという問題がある。このため、受信した音声データから、自己が発した音声データを消去する必要がある。
【０００６】
また、三者以上で会議を行う場合、会議を開始するには、それぞれの参加者が自らの使用する通話用端末装置をＭＣＵに接続する必要があった。また、ＭＣＵには複数のグループが同時に会議をするための機能も備わっているが、この場合、会議の参加者は、自らのグループが会議を行う会議室名をあらかじめ知っておく必要がある。したがって、従来のＭＣＵを用いた会議では、参加者は、グループのキーワードである会議室名を予め電子メールや口頭で知らされない限り、会議に参加することができないという問題があった。また、帯域および会議システムのリソースが不足して、新たな会議を始めることができないなどの問題があった。
【０００７】
この発明は、上述のような課題を解消するためになされたもので、例えば、発信側から送信した送信データが当該発信側に戻る際の時間差を知ることによって、最適な伝送状態を実現することを目的とする。
【０００８】
また、マルチキャストで音声データを送信した場合において、自己が発した音声データを消去して会話を聞き取りやすくすることを目的とする。
【０００９】
また、参加者が会議に参加する際の利便性の向上や、会議に係るリソースの有効利用を図ることを目的とする。
【００１０】
また、参加者が増えたとしても、ＭＣＵから送信されるデータ量の増加を抑制しながら、帯域の有効利用を図ることを目的とする。
【００１１】
【課題を解決するための手段】
上記課題を解決するため、請求項１の発明は、複数の端末装置からなる端末装置群と、前記端末装置群とネットワークを介して結合されるデータミキシング処理装置と、を備える多地点会議システムであって、前記複数の端末装置のそれぞれがデータ送信装置とデータ受信装置とを備え、a)前記データ送信装置は、a-1)所定の入力手段によって入力された音声データである入力データから原パケットデータを生成するデータ入力処理手段と、a-2)所定の個数の前記原パケットデータのペイロードの一部を同期用情報に書き換えて当該個数の同期パケットデータを生成する同期パケット生成手段と、a-3)当該端末装置における送受信の同期が確立されるまでは前記同期パケットデータを対象パケットデータとし、前記送受信の同期が確立した後は前記原パケットデータを対象パケットデータとして、前記対象パケットデータを当該データ送信装置から送信するタイミングを表現した第１のタイミング指標を付加することにより、第１伝送パケットデータを生成する第１タイミング指標付加手段と、a-4)前記第１タイミング指標が付加された前記第１伝送パケットデータを一定の時間間隔で送出する第１送出手段と、を有してなり、b)前記データミキシング処理装置は、b-1)前記各端末装置から送出される前記第１伝送パケットデータを受信し、そのヘッダ部にその送出元である端末装置を示す識別子を付加する識別子付加手段と、b-2)受信した前記第１伝送パケットデータが前記同期パケットデータであるか否かを判定する判定手段と、b-3)前記同期パケットデータであると判定された前記第１伝送パケットデータのペイロード部を廃棄し、残りをダミーパケットデータとして出力する廃棄手段と、b-4)前記ダミーパケットデータと、前記同期パケットデータでないと判定された前記第１伝送パケットデータとをミキシング対象データとし、前記ミキシング対象データを用いてミキシングパケットデータを生成するミキシング処理を行うミキシング処理手段と、b-5)前記ミキシング処理手段から出力される前記ミキシングパケットデータに、前記ミキシングパケットデータを当該データミキシング処理装置から送出するタイミングを表現する第２のタイミング指標を付加する第２タイミング指標付加手段と、b-6)前記第２タイミング指標付加手段から出力される前記ミキシングパケットデータを一定の時間間隔で前記端末装置群を構成する全ての端末装置に送出する第２送出手段と、を有してなり、c)前記データ受信装置は、c-1)前記データミキシング処理装置から送出される前記ミキシングパケットデータを受信し、前記ミキシングパケットデータに基づいて当該端末装置における送受信の同期を確立する同期確立手段と、c-2)前記同期が確立されるまでは受信した前記ミキシングパケットデータを廃棄すると共に、前記同期が確立された以降に受信した前記ミキシングパケットデータを維持する検査手段と、c-3)前記検査手段に維持された前記ミキシングパケットデータから、前記複数の端末装置において入力された音声データを復元する復元手段と、を有してなり、前記ミキシング処理は、前記ミキシング対象データのそれぞれのヘッダ部に付加されてなる前記識別子の情報を合成することによる識別子情報の生成と、前記同期パケットデータでないと判定された前記第１伝送パケットデータのペイロード部の合成とを含む処理であり、前記同期確立手段は、順次に受信する複数の前記ミキシングパケットデータに当該データ受信装置を含む当該端末装置を特定する情報が前記識別子情報に含まれてなり、かつ、前記複数のミキシングパケットデータのそれぞれに付加されてなる前記第２タイミング指標に所定の一連性があるか否かを判断し、前記一連性がある場合に、前記第１タイミング指標と前記第２タイミング指標を関連付けることによって前記送受信の同期の確立を実現する、ことを特徴とする。
【００１２】
請求項２の発明は、請求項１に記載の多地点会議システムであって、前記同期確立手段が前記所定の一連性の判断を行う場合に、判断対象である前記第２タイミング指標の個数と当該端末装置より送出された前記同期パケットデータの前記所定の個数の一致の有無を判断の対象とすることを特徴とする。
【００１３】
請求項３の発明は、請求項１または請求項２に記載の多地点会議システムであって、所定時間の間に前記送受信の同期が確立できない場合は、前記同期パケット生成手段における前記同期パケットデータの生成を繰り返すことを特徴とする。
請求項４の発明は、請求項１ないし請求項３のいずれかに記載の多地点会議システムであって、前記識別子付加手段が、送出元である前記各端末装置ごとに異なる接続チャネルで前記第１伝送パケットデータを受信するように構成されてなり、前記第１伝送パケットデータを受信した前記接続チャネルを特定する情報に基づいて前記識別子を付加することを特徴とする。
【００１４】
請求項５の発明は、請求項１ないし請求項４のいずれかに記載の多地点会議システムであって、前記第１タイミング指標が、前記第１伝送パケットデータのそれぞれに固有に与えられる第１シーケンス番号であり、前記第２タイミング指標が、前記ミキシングパケットデータのそれぞれに固有に与えられる第２シーケンス番号であることを特徴とする。
【００１７】
請求項６の発明は、請求項１ないし請求項５のいずれかに記載の多地点会議システムであって、前記検査手段が、前記第１タイミング指標と前記第２タイミング指標とに基づいて前記送受信の遅延時間を特定する手段を含み、前記データ受信装置が、前記遅延時間の情報に基づいて、当該端末装置から前記データミキシング処理装置に送信した前記音声データに基づく前記第１伝送パケットデータを、復元された前記音声データから除去するエコーキャンセル手段をさらに備える、ことを特徴とする。
【００１８】
請求項７の発明は、複数の端末装置からなる端末装置群と、前記端末装置群とネットワークを介して結合されるデータミキシング処理装置と、を備える多地点会議システムを構成する端末装置であって、データ送信装置とデータ受信装置とを備え、a)前記データ送信装置は、a-1)所定の入力手段によって入力された入力データから原パケットデータを生成するデータ入力処理手段と、a-2)所定の個数の前記原パケットデータのペイロードの一部を同期用情報に書き換えて当該個数の同期パケットデータを生成する同期パケット生成手段と、a-3)当該端末装置における送受信の同期が確立されるまでは前記同期パケットデータを対象パケットデータとし、前記送受信の同期が確立した後は前記原パケットデータを対象パケットデータとして、前記対象パケットデータを当該データ送信装置から送信するタイミングを表現した第１のタイミング指標を付加することにより、第１伝送パケットデータを生成する第１タイミング指標付加手段と、a-4)前記第１タイミング指標が付加された前記第１伝送パケットデータを一定の時間間隔で送出する第１送出手段と、を有してなり、b)前記データ受信装置は、b-1)前記データミキシング処理装置においてミキシング処理され第２タイミング指標が付加されたうえで一定の時間間隔で前記データミキシング処理装置から送出されるミキシングパケットデータを受信し、前記ミキシングパケットデータに基づいて当該端末装置における送受信の同期を確立する同期確立手段と、b-2)前記同期が確立されるまでは受信した前記ミキシングパケットデータを廃棄すると共に、前記同期が確立された以降に受信した前記ミキシングパケットデータを維持する検査手段と、b-3)前記検査手段に維持された前記ミキシングパケットデータから、前記複数の端末装置において入力された音声データを復元する復元手段と、を有してなり、前記ミキシング処理は、同期パケットデータである前記第１伝送パケットデータのペイロード部を廃棄した残りであるダミーパケットデータと、前記同期パケットデータでない前記第１伝送パケットデータとをミキシング対象データとする、前記ミキシング対象データのそれぞれのヘッダ部に付加されてなる前記複数の端末装置のそれぞれを識別する識別子の情報を合成することによる識別子情報の生成と、前記同期パケットデータでない前記第１伝送パケットデータのペイロード部の合成とを含む処理であり、前記同期確立手段は、順次に受信する複数の前記ミキシングパケットデータに当該データ受信装置を含む当該端末装置を特定する情報が前記識別子情報に含まれてなり、かつ、前記複数のミキシングパケットデータのそれぞれに付加されてなる前記第２タイミング指標に所定の一連性があるか否かを判断し、前記一連性がある場合に、前記第１タイミング指標と前記第２タイミング指標を関連付けることによって前記送受信の同期の確立を実現する、ことを特徴とする。
【００２２】
請求項８の発明は、請求項７に記載の多地点会議システムの端末装置であって、前記検査手段が、前記第１タイミング指標と前記第２タイミング指標とに基づいて前記送受信の遅延時間を特定する手段を含み、前記データ受信装置が、前記遅延時間の情報に基づいて、当該端末装置から前記データミキシング処理装置に送信した前記入力データに基づく前記第１伝送パケットデータを、復元された前記音声データから除去するエコーキャンセル手段をさらに備える、ことを特徴とする。
【００２３】
請求項９の発明は、複数の端末装置からなる端末装置群と、前記端末装置群とネットワークを介して結合されるデータミキシング処理装置と、を備える多地点会議システムを構成するデータミキシング処理装置であって、第１のタイミング指標を付加したうえで前記各端末装置から送出される第１伝送パケットデータを受信し、そのヘッダ部にその送出元である端末装置を示す識別子を付加する識別子付加手段と、受信した前記第１伝送パケットデータが、前記各端末装置において所定の入力手段によって入力された入力データから生成された原パケットデータか、前記原パケットデータのペイロードの一部を同期用情報に書き換えて生成された同期パケットデータであるか否かを判定する判定手段と、前記同期パケットデータであると判定された前記第１伝送パケットデータのペイロード部を廃棄し、残りをダミーパケットデータとして出力する廃棄手段と、前記ダミーパケットデータと、前記同期パケットデータでないと判定された前記第１伝送パケットデータとをミキシング対象データとし、前記ミキシング対象データを用いてミキシングパケットデータを生成するミキシング処理を行うミキシング処理手段と、前記ミキシング処理手段から出力される前記ミキシングパケットデータに、前記ミキシングパケットデータを当該データミキシング処理装置から送出するタイミングを表現する第２のタイミング指標を付加する第２タイミング指標付加手段と、前記第２タイミング指標付加手段から出力される前記ミキシングパケットデータを前記端末装置群を構成する全ての端末装置に送出する第２送出手段と、を有してなり、前記ミキシング処理は、前記ミキシング対象データのそれぞれのヘッダ部に付加されてなる前記識別子の情報を合成することによる識別子情報の生成と、前記同期パケットデータでないと判定された前記第１伝送パケットデータのペイロード部の合成とを含む処理である、ことを特徴とする。
【００４０】
【発明の実施の形態】
＜実施の形態１＞
＜システムの構成概要＞
図１はこの発明の実施の形態１に係る多地点会議システム１００の構成の概要を示す図である。多地点会議システム１００は、通信網を利用して、遠隔地にいる複数人が会議を行うためのシステムであり、複数（通常は３以上）の端末装置１（１ａ、１ｂ、・・・、１ｎ）とからなる端末装置群と、これと通信網を介して接続されるＭＣＵ（Multipoint Control Unit）２０とを主として備える。端末装置１とＭＣＵ２０とはいずれも、所定のプログラムを実行することにより、それぞれのコンピュータ（ＰＣ）においてその機能が実現するものである。多地点会議システム１００においては、それぞれの端末装置１からデータが送信され、ＭＣＵ２０へと送られた後に、ＭＣＵ２０においてこれらが合成されてマルチキャストにてそれぞれの端末装置１へと送信される。これにより、セッションが成立することになる。ただし、マルチキャスト送信においては、全てのデータが全ての端末装置１に送信されるため、それぞれのデータの送信元である端末装置１（例えば端末装置１ａ）には、他の端末装置１（例えば端末装置１ｂ、・・・、１ｎ）から送信されたデータのみを使用者たる会議の参加者に提供すべく、自らが発したデータをキャンセルする機能が備わっている。なお、データの送受信のためのプロトコルとしては、ＲＴＰ（Real-time Transport Protocol）が用いられる。
【００４１】
端末装置１は、多地点会議に参加する参加者ごとに備わるものであり、参加者の発話データや映像データの入力を受け、これに適式な処理を施した後に、データミキシング装置に向けて送信したり、あるいは他の参加者の使用する端末装置１から送信され、後述するように、ＭＣＵ２０にてミキシングされた発話データや映像データを受信して、適式な処理を施し、参加者が視聴可能となるように出力するためのものである。ただし、図示の都合により図１においては１つの端末装置１ａのみその内部構成が示されているが、他の端末装置１ｂ、・・・、１ｎの内部構成も同様である。
【００４２】
端末装置１は、例えばマイクやカメラなどの入力手段２と、入力されたデータを送信可能な形式に変換したり、データの同期を確立するための処理するなど、送信に際し必要な種々の処理を行うデータ送信部１Ｓと、受信したデータを参加者が視聴可能な形式に変換するなど受信後に必要な種々の処理を行うデータ受信部１Ｒと、処理中のデータを一時的に記憶するデータバッファ７と、例えばスピーカやディスプレイなどの出力手段１１とを主として備える。
【００４３】
データ送信部１Ｓは、データ入力処理手段３と、同期パケット生成手段４と、タイミング指標付加手段５と、データ送信手段６とを主として備える。
【００４４】
データ入力処理手段３は、入力手段２から入力されたデータをＡ／Ｄ変換し、一定のデータ長を有するパケット３０（図３）に分割する処理、及びエコーキャンセル処理をする際に必要なデータをデータバッファ７へと記憶する処理、などを担うためのものである。同期パケット生成手段４は、送信するデータの同期を確立するための同期確立過程において能動化されて、同期パケット３５（図３）を、データ入力処理手段３にて生成されたもともとのパケット（原パケット）であるパケット３０をベースに生成する。タイミング指標付加手段５は、シーケンス番号３４（図３）を、パケット３０のヘッダ部分に送信される順に付加するためのものである。シーケンス番号３４は、端末装置１からデータが送信された後、ＭＣＵ２０からマルチキャスト送信されて再び端末装置１に戻ってくるまでの時間的な遅れを知るために与えられる、個々のパケット３０に固有の番号である。また、データミキシング装置２０Ｍにおいては、シーケンス番号３４を参照することで、パケットデータの欠落の有無などの判断も可能である。データ送信手段６は、ＲＴＰに従って、パケット３０をＭＣＵ２０に対し順次送信するためのものである。
【００４５】
以上より、入力手段２およびデータ送信部１Ｓに着目すると、端末装置１はパケットデータの送信を担うデータ送信装置として機能する部分を有するといえる。
【００４６】
データ受信部１Ｒは、データ受信手段８と、ミキシングパケット検査手段９と、データ出力処理手段１０とを主として備える。
【００４７】
データ受信手段８は、データミキシング装置２０Ｍから、ＲＴＰに従ってマルチキャストに送信されたパケットデータを受信するためのものである。ミキシングパケット検査手段９は、データ受信手段８が受信したパケット（以下、「伝送パケット」）が同期パケット３５であるか否か、あるいは同期が確立したか否かなどについて判定するためのものである。データ出力処理手段１０は、同期が確立しないあいだは、受信した同期パケットを廃棄する処理、および出力手段１１においてデータの出力を行わせない処理を、同期が確立した後は、パケット３０に分割されているデータの復元処理、エコーキャンセル処理、Ｄ／Ａ変換処理などを行うためのものである。
【００４８】
以上より、出力手段１１およびデータ受信部１Ｒに着目すると、端末装置１はデータの受信を担うデータ受信装置として機能する部分を有するといえる。
【００４９】
なお、端末装置１におけるそれぞれの処理については後述する。
【００５０】
ＭＣＵ２０は、複数の端末装置１から送信された複数のパケットデータを１つのデータにミキシングして新たなパケットデータであるミキシングパケット３８（図３）を生成し、これを再びそれぞれの端末装置１に対してマルチキャストに送信するためのものである。この目的のため、ＭＣＵ２０は、通信制御装置２０Ｃと、データミキシング装置２０Ｍとを主として備える。このように構成することによって、マルチキャスト送信が可能となり、帯域の有効活用が図れる。
【００５１】
通信制御装置２０Ｃは、データ受信手段２１と、データ送信手段２９とを主として備える。データミキシング装置２０Ｍは、ＣＳＲＣ識別子付加手段２２と、パケットデータ判定手段２３と、ペイロード廃棄手段２４と、ダミーパケット記憶手段２５と、ＣＳＲＣ識別子合成手段２６と、データミキシング手段２７と、タイミング指標付加手段２８とを主として備える。
【００５２】
データ受信手段２１は、端末装置１からＲＴＰに従って送信された伝送パケットを受信するためのものである。データ受信手段２１は、複数の接続チャネルを備えており、データの送信元は、受信した接続チャネルで識別される。また、データ受信手段２１には、それぞれの端末装置１との接続が確立すると、端末装置１ごとの受信スレッド（図示せず）が作成され、それぞれの端末装置１からのデータは対応する受信スレッドに保存される。ＣＳＲＣ識別子付加手段２２は、データを受信した接続チャネルの情報に基づき、どの端末装置１から送信された伝送パケットであるのかを識別するためのＣＳＲＣ識別子（寄与送信元識別子）３６（図３）を、受信した伝送パケットに付加するためのものである。パケットデータ判定手段２３は、受信した伝送パケットが、同期パケット３５であるか否かを判定するためのものである。ペイロード廃棄手段２４は、受信した伝送パケットが同期パケット３５である場合に、そのペイロード３２を廃棄するためのものである。ダミーパケット記憶手段２５は、受信した伝送パケットが同期パケット３５であったことを記憶するためのものである。
【００５３】
ＣＳＲＣ識別子合成手段２６、データミキシング手段２７、およびタイミング指標付加手段２８は、ミキシングパケット３８（図３）を生成するためのものである。このうち、ＣＳＲＣ識別子合成手段２６は、ミキシングパケット３８のヘッダ部分に、ミキシングされたデータの送信元のＣＳＲＣ識別子情報４１（図３）を合成し付与するためのものである。データミキシング手段２７は、複数の端末装置１から送信された伝送パケットのペイロード３２（図３）をミキシングするためのものである。タイミング指標付加手段２８は、端末装置１に備わるタイミング指標付加手段５と同様に、シーケンス番号を、ミキシングパケット３８のヘッダ部分に、送信される順に付加するためのものである。データ送信手段２９は、ＲＴＰに従って、それぞれの端末装置１に対してミキシングパケット３８をマルチキャスト送信する。
【００５４】
なお、ＭＣＵ２０におけるそれぞれの処理については後述する。
【００５５】
＜定常のデータ処理＞
次に、多地点会議システム１００を用いた会議の実行時、いわば定常処理時におけるデータの処理について、音声データを例にして説明する。多地点会議システム１００においては、それぞれの参加者が発する音声は、当該参加者が使用する端末装置１から音声データとしてＭＣＵ２０に送られ、１つの音声データにミキシングされた後、マルチキャスト配信され、再び端末装置１に戻ってくる。以下の説明は、これらの処理に関するものである。なお、端末装置１においては、ミキシングされた音声データから、自らが発した音声を消去するエコーキャンセルを行うが、そのために必要な同期確立処理については後述する。
【００５６】
図２は、多地点会議システム１００における処理の流れを説明するための図である。図２においては、点線で示す矢印ＡＲ５が、データの同期を確立するための処理の流れを示している。なお、図１において点線で示す矢印ＡＲ２は、多地点会議システム１００においてデータが受け渡される様子を、図２と対応させて示したものである。図３は、多地点会議システム１００における種々の処理に伴うデータ構造の変化を、模式的に示す図である。図３（ｂ）が、以下に示す音声データ処理の場合を示している。
【００５７】
多地点会議のある参加者（以降、「参加者Ａ」とする）が使用する端末装置１が、所定の通信網に接続され、多地点会議システムを利用するための所定のプログラムが動作し、会議への参加が可能な状態になると、入力手段２であるマイクを通じて音声入力が可能となる（ステップＳ１）。その後、まずは後述する同期確立処理が施され、エコーキャンセルが可能な状態になると、参加者Ａの会議への実質的な参加が可能となる。
【００５８】
入力手段２から入力された音声データは、データ入力処理手段３においてＡ／Ｄ変換される（ステップＳ３）。そして、後のエコーキャンセル処理のためにデータバッファ７に保存される（ステップＳ４）一方で、所定のデータ長ごとのパケットに分割される（ステップＳ５）。それぞれのパケット３０は、図３（ｂ）の［１］のように、制御信号等が格納されるヘッダ３１と、音声データが格納されるペイロード３２とからなるパケットデータとして構成される。なお、本発明において用いる「パケット」なる用語は、多地点会議システム１００を構成する通信網がデータリンク層に相当するものである場合は「フレーム」と同義である。
【００５９】
次に、タイミング指標付加手段５が、図３（ｂ）の［３］のように、パケット３０を対象パケットとして、そのヘッダ３１にシーケンス番号３４を付加する（ステップＳ７）。シーケンス番号３４は、元の音声データのデータ配列に従ってそれぞれのパケット３０に与えられる、パケットの順序を示すための連続番号である。また、タイミング指標付加手段５は、それぞれのパケット３０に付加したシーケンス番号３４の情報を保持する。保持されたシーケンス番号の情報は、同期の確立およびエコーキャンセルに利用されるが、これらの詳細は後述する。なお、図３（ｂ）においては、図示の都合上シーケンス番号３４をヘッダ３１の末尾のフィールドに付す態様にて示しているが、ヘッダ３１内のデータ構造はこれに限定されない。
【００６０】
シーケンス番号３４が付加されたパケット３０は、伝送パケットとして、データ送信手段６によってＭＣＵ２０へと送信される（ステップＳ８）。すなわち、連続したシーケンス番号３４を有する伝送パケットが順次送信されていることとなる。
【００６１】
ＭＣＵ２０は、端末装置１から送信された伝送パケットを、通信制御装置２０Ｃのデータ受信手段２１によって受信する（ステップＳ９）。データ受信手段２１が受信した接続チャネルの情報から、図３（ｂ）の［４］のように、ヘッダ３１にＣＳＲＣ識別子３６が記録される（ステップＳ１０）。
【００６２】
次に、パケットデータ判定手段２３において、受信した伝送パケットのデータが同期パケット３５（後述）であるか否かが判定される（ステップＳ１１）。いま、判定の対象となっているのは同期が確立した後に受信した伝送パケットデータであるので、直ちにミキシング処理に供される。
【００６３】
ミキシング処理とは、通信制御装置２０Ｃが複数の端末装置１から所定の時間内に受信したパケット３０のデータを、データミキシング装置２０Ｍが新たな１つのミキシングパケット３８にミキシングする処理である。これは、ＣＳＲＣ識別子情報４１を合成しミキシングパケット３８のヘッダ３９に付与するＣＳＲＣ識別子合成処理（ステップＳ１４）と、音声データをミキシングパケット３８のペイロード４２に合成する音声データミキシング処理（ステップＳ１５）とからなる。
【００６４】
図４は、データミキシング装置２０Ｍにおけるデータミキシングの処理フローを示す図である。まず、図３（ｂ）の［６］に示すように、ＣＳＲＣ識別子合成手段２６によって、ミキシングの対象となったそれぞれの伝送パケットの送信元の情報を示すＣＳＲＣ識別子３６から、ＣＳＲＣ識別子情報４１が合成される（ステップＳ３１）。次に、データミキシング手段２７によって、伝送パケットにおいて実質的な音声データを含むペイロード３２の内容がミキシングパケット３８のペイロード４２に合成される（ステップＳ３２、Ｓ３３）。今、ｋ個（ｋ≧３）の端末装置１が用いられ、全ての端末装置１で同期が確立されているとすると、ミキシングパケット３８は、ｋ個の端末装置１についてのＣＳＲＣ識別子情報４１と、ｋ個の端末装置１において発せられた音声をミキシングしたペイロード４２とを備えていることになる。
【００６５】
その後、ミキシングパケット３８にはタイミング指標付加手段２８によってシーケンス番号４０が付加され（ステップＳ１６、Ｓ３４）、データ送信手段２９により、ＲＴＰに従って、それぞれの端末装置１に対しマルチキャスト送信がなされる（ステップＳ１７、Ｓ３５）。
【００６６】
端末装置１は、ＭＣＵ２０からマルチキャスト送信されたミキシングパケット３８を、データ受信手段８で受信する（ステップＳ１８）。
【００６７】
図５は、ミキシングパケット３８を受信した後の端末装置１における処理フローを示す図である。ミキシングパケット３８を受信すると、まず、ミキシングパケット検査手段９によって、後述する同期フラグが端末装置１においてすでに設定されているか否かが確認される（ステップＳ１９、Ｓ４１）。今、対象となっている処理は、定常の音声データ処理、すなわち、同期が確立された後の処理であるので、ステップＳ４１はＹＥＳと判定される。すなわち、ミキシングパケット３８はそのまま維持され、データ出力処理手段１０における音声出力処理へと供される（ステップＳ５２）。
【００６８】
データ出力処理手段１０においては、ミキシングパケット３８に付加されているシーケンス番号４０に基づいて、ミキシングパケット３８から会議の参加者が発する音声が合成された音声データが復元される（ステップＳ２１）。
【００６９】
さらに、後述する同期の確立処理によって定まる、シーケンス番号４０と、端末装置１のタイミング指標付加手段５によって保持されていたシーケンス番号３４の情報との対応関係から、受信したミキシングパケット３８が、先に端末装置１から送り出された伝送パケットうちのどのパケットのデータを含んでいるのかが明らかとなるので、復元された音声データから、当該ミキシングパケット３８を受信した端末装置１の使用者である参加者Ａが発した音声データを消去するための、エコーキャンセル処理が行うことができる（ステップＳ２２）。エコーキャンセルは、データ送信時にデータバッファ７に保存した当該使用者の音声データを、データミキシング装置２０Ｍから送信され復元された音声データと逆位相で合成することで実現する。ここで、同期の確立処理が必要となってくるが、詳細は後述する。
【００７０】
エコーキャンセルされた音声データは、Ｄ／Ａ変換（ステップＳ２３）された後、出力手段１１によって、参加者Ａが聴取可能に音声出力される（ステップＳ２４）。
【００７１】
＜同期の確立＞
次に、多地点会議システム１００において、端末装置１がデータの同期を確立するための処理について説明する。
【００７２】
上述したように、端末装置１においては、ＭＣＵ２０からマルチキャスト送信される音声データを参加者Ａが聴取可能とする際に、参加者Ａが自らが発した音声のデータを消去する、エコーキャンセル処理を行う必要がある。そして、エコーキャンセル処理を効果的なものとするためには、端末装置１から音声データを送信し、ＭＣＵ２０でミキシングされて再び戻ってくるまでの遅延時間を、正確に知る必要がある。端末装置１における同期確立処理とは、定常の音声データ処理に先立って行われる、この遅延時間を得るための処理である。
【００７３】
図２において実線で示す矢印ＡＲ４が、データの同期を確立するための処理の流れを示している。また、図１において実線で示す矢印ＡＲ１は、多地点会議システム１００において同期を確立するためのデータが受け渡される様子を、図２における同期を確立するための処理の流れに対応させて示したものである。また、図３（ａ）が、同期を確立する場合の種々の処理に伴うデータ構造の変化を、模式的に示している。また図６は、同期を確立する際の、端末装置１におけるデータ送信に関する処理フローを示す図である。
【００７４】
参加者Ａが使用する端末装置１が、所定の通信網に接続され、多地点会議システムを利用するための所定のプログラムが動作し、会議への参加が可能な状態になると、入力手段２であるマイクを通じて音声入力が可能となる（ステップＳ１）。ただし、同期が確立されるまでは、後述するように、入力された音声は他の参加者には届かない。また、出力手段１１であるスピーカーからの音声出力は、データ出力処理手段１０によってミュートされる（ステップＳ２、Ｓ５１）。これにより、他の参加者の発する音声は、同期が確立するまでは参加者Ａには聞こえない。
【００７５】
入力された音声データは、定常の処理と同様に、データ入力処理手段３においてＡ／Ｄ変換され（ステップＳ３）、さらに所定のデータ長ごとのパケットに分割される（ステップＳ５）。ただし、データバッファ７への保存はなされない。
【００７６】
パケット３０が得られると、以下のように、同期を確立するために用いる同期パケット３５を生成する処理がなされる。
【００７７】
まず、図３（ａ）の［２］のように、同期パケット生成手段４が、それぞれのパケット３０において、ペイロード３２のうち先頭のＮバイト（Ｎ≧１）を、同期用情報である所定の同期識別パターンデータ３３に書き換える（ステップＳ６）。このように、本実施の形態においては、ペイロード３２の一部を書き換えることで同期パケット３５を生成する。従って、データ形式は本来の音声データと同じ形式を保っていることから、その送受信も本来の音声データと同じＲＴＰによって可能であり、特別なプロトコルを要せずに同期を確立することができる。
【００７８】
次に、タイミング指標付加手段５が、図３（ａ）の［３］のように、同期パケット３５を対象としてそのヘッダ３１にシーケンス番号３４を付加すると共に、付加したシーケンス番号３４についての情報を保持する（ステップＳ７）。
【００７９】
以上のようにしてパケット３０を書き換えた同期パケット３５にシーケンス番号を付加したものが同期確立用の伝送パケットとなる。この伝送パケットは、データ送信手段６によって、ＭＣＵ２０へと送信される（ステップＳ８、Ｓ５４）。
【００８０】
後述するように、同期が確立されたと判断されるまでは、端末装置１においては同期パケット３５の生成と送信とが繰り返されることとなる（ステップＳ５２〜Ｓ５４）。すなわち、連続したシーケンス番号３４を有する複数の同期パケット３５が伝送パケットとして、所定の個数ずつ順次送信されていることとなる。
【００８１】
ＭＣＵ２０の通信制御装置２０Ｃは、端末装置１から送信された同期パケット３５を、データ受信手段２１によって受信する（ステップＳ９）。データ受信手段２１が受信した接続チャネルの情報から、図３（ａ）の［４］のように、ヘッダ３１にＣＳＲＣ識別子３６が記録される（ステップＳ１０）。
【００８２】
次に、パケットデータ判定手段２３において、受信した伝送パケットのデータがペイロード部分に同期識別パターンデータ３３を含む同期パケット３５であることが確認される（ステップＳ１１）と、図３（ａ）の［５］のように、ペイロード廃棄手段２４において同期パケット３５のペイロード部分が廃棄される（ステップＳ１２）。これは、同期が確立されていない時点での音声データを、後段の処理でミキシングしないようにするためである。以降、このようにペイロード部分が廃棄された同期パケット３５を、ダミーパケット３７と称する。
【００８３】
ダミーパケット記憶手段２５において、ダミーパケット３７が生成されたことが記憶される（ステップＳ１３）と、ダミーパケット３７はミキシング処理へと供され、図４の処理フローに従った処理が施されることになる。
【００８４】
ミキシング処理は、上述したように、通信制御装置２０Ｃが複数の端末装置１から所定の時間内に受信した伝送パケットのデータをミキシングして、新たな１つのミキシングパケット３８を生成する処理である。ここで、ペイロードを有さないダミーパケット３７もミキシングの対象となるのは、ミキシングパケット３８のＣＳＲＣ識別子情報４１の内容によって、端末装置１は、自らが発した同期パケット３５がＭＣＵ２０に到達したか否かを判断することになるからである。そのために必要なのは、どこからダミーパケット３７が送出されたのかを表すＣＳＲＣ識別子３６の情報のみであるので、ダミーパケット３７の場合は、図３（ａ）の［６］に示すように、ＣＳＲＣ識別子合成手段２６におけるＣＳＲＣ識別子情報４１の合成の対象とはなるが（ステップＳ３１）、ペイロードにデータを含まないので、データミキシング手段２７におけるペイロードのミキシングの対象とはならない（ステップＳ３２、Ｓ３４）。今、ｋ個の端末装置１が用いられ、ある１つの端末装置１のみ同期が確立していないとすると、ミキシングパケット３８は、ｋ個の端末装置１についてのＣＳＲＣ識別子情報４１と、（ｋ−１）個の端末装置１において発せられた音声をミキシングしたペイロード４２とを備えていることになる。これにより、本来不要なダミーデータをミキシングパケット３８に含まないことから、端末装置１におけるノイズの要因となることを回避することができる。
【００８５】
得られたミキシングパケット３８に、タイミング指標付加手段２８によってシーケンス番号４０が付加され（ステップＳ１６、Ｓ３４）、データ送信手段２９により、ＲＴＰに従って、それぞれの端末装置１に対しマルチキャスト送信がなされる（ステップＳ１７、Ｓ３５）のは、上述の場合と同じである。
【００８６】
端末装置１は、ＭＣＵ２０からマルチキャスト送信されたミキシングパケット３８を、データ受信手段８で受信する（ステップＳ１８）。
【００８７】
上述したように、ミキシングパケット３８を受信すると、図５に示すように、ミキシングパケット検査手段９によって、後述する同期フラグが端末装置１においてすでに設定されているか否かがまず確認される（ステップＳ１９、Ｓ４１）。今、同期確立処理を行っている途中であるので、ステップＳ４１はＮＯと判定される。すると、引き続いて、ミキシングパケット検査手段９によって同期確立条件に適合しているか否かの判断がなされることとなる。
【００８８】
まず、受信したミキシングパケット３８のＣＳＲＣ識別子情報４１に、当該端末装置１についての情報が含まれているか否かを判別する（ステップＳ４２）。これが含まれている場合には、ミキシングパケット検査手段９に備わる図示しないパケットカウンタにおいて引き続きステップＳ４２を満たすパケットをカウントする（ステップＳ４３）。
【００８９】
所定時間内に当該端末装置１自身に係るＣＳＲＣ情報を含むミキシングパケット３８を２個以上受信した場合（ステップＳ４４でＹＥＳ）、タイミング指標である、受信したミキシングパケット３８のシーケンス番号４０の一連性を判別する（ステップＳ４５）。例えば、端末装置１から５つの同期パケット３５が連続して送信された場合に、受信したミキシングパケット３８に「１００１」、「１００２」、・・・、「１００５」なるシーケンス番号４０が付加されていた場合、これらのシーケンス番号は連続している、と判別される。仮に、「１００２」なるシーケンス番号４０が付加されていたミキシングパケット３８が受信されないなど番号に不連続がある場合や、「１００５」なるシーケンス番号４０が付加されたミキシングパケット３８が受信されないなど所定の個数に足りない場合などは、連続しているとは判別されない。シーケンス番号４０が連続していると判別された場合（ステップＳ４５でＹＥＳ）、当該端末装置１から順次送出されたそれぞれの同期パケット３５のデータが、正しくミキシングを受けてミキシングパケット３８として戻ってきているものと判断される。これにより、通信網上で消失し、欠落が生じる状態では、同期が確立されることはない。
【００９０】
次に、タイミング指標付加手段５が保持するシーケンス番号３４の情報と、データミキシング装置２０Ｍにてミキシングパケット３８に付与されたシーケンス番号４０との関連付けが行われる（ステップＳ４６）。例えば、上述の場合に、同期パケット３５に付加されていたシーケンス番号３４が「０００１」「０００２」・・・「０００５」であったとすると、両者のシーケンス番号の値には「１０００」の差があることになる。端末装置１とＭＣＵ２０とからは一定の時間間隔でシーケンス番号が付加されてパケットが送信されるので、端末装置１が送信した伝送パケットとこれに対応するデータを含むミキシングパケット３８との両者にそれぞれ付加されているシーケンス番号の差（上述の場合であれば「１０００」）は、その後も一定に保たれることとなる。すなわち、この番号差は、送信と受信との遅延時間に相当する。言い換えると、この番号差が得られたことで、同期の確立がなされたこととなる。
【００９１】
こうして、同期が確立されると、上記の遅延時間に相当する番号差を用いたエコーキャンセル処理が可能となるため、それまで音声出力のデータ出力処理手段１０においてなされていた音声出力のミュートは解除される（ステップＳ４７）。これにより、有効な音声データのみを参加者Ａが聴取可能とする、いわば頭出し検出が可能となる。
【００９２】
またこのとき、データ送出部１Ｓからの同期パケット３５の送出がストップされる（ステップＳ４８）。そして、ミキシングパケット検査手段９において同期が確立したことを示す同期フラグが設定される（ステップＳ４９）。
【００９３】
一方、当該端末装置１についての情報がＣＳＲＣ識別子情報４１に含まれているミキシングパケット３８を受信しない場合（ステップＳ４２でＮＯ）、所定時間内に２個以上受信できなかった場合（ステップＳ４４でＮＯ）、またはシーケンス番号が連続していなかった場合（ステップＳ４５でＮＯ）は、同期パケット３５の送信が続行され（ステップＳ５０）、パケットカウンタはクリアされる（ステップＳ５２）。
【００９４】
同期が確立されると、以降は、前述したような定常の音声データ処理がなされることとなる。なお、同期が確立された場合も、引き続き同期確立処理が行われる場合も、ミキシングパケット検査手段９において用いられたミキシングパケット３８は、所定の処理が終了した後は廃棄される（ステップＳ２０）。
【００９５】
以上、説明したように、本実施の形態においては、エコーキャンセルに必要なデータの同期の確立に、パケットデータの一部を書き換えた同期パケットを利用しているので、データの送受信に利用するプロトコルをそのまま用いて同期を確立することが可能である。
【００９６】
＜実施の形態２＞
実施の形態１においては、シーケンス番号の番号差を用いて遅延時間を判断していたが、通信網上の端末間で利用可能なＮＴＰ（Network Time Protocol）を利用して、直接に時刻を検出して同期を取る態様も可能である。すなわち、図１のタイミング指標付加手段５および２８がＮＴＰによる時刻情報を同期パケット３５およびミキシングパケット３８に与える態様であってもよい。
【００９７】
例えば、同期パケット３５の送出時に、タイミング指標付加手段５がＮＴＰより時刻情報を取得して、シーケンス番号３４とともにヘッダ３１に記憶させる。また、同時に端末装置１においてもこれを記憶する。ＭＣＵ２０においては、データミキシングの後、マルチキャスト送信の際に、シーケンス番号４０とともに、時刻情報をヘッダ３９に記憶する。端末装置１のミキシングパケット検査手段９は、受信したミキシングパケット３８のヘッダ３９と、送信時に記憶しておいた時刻情報を比較参照することにより、送出した時刻とミキシング後に受信した時刻の差分を取得する。これにより、同期の確立に必要な遅延時間の値を、より正確に知ることができる。本実施の形態は、データ紛失率が高い伝送系において同期を確立する際に、より有効である。
【００９８】
＜実施の形態３＞
従来の多地点会議は、会議の参加者がそれぞれに会議管理装置との接続を確立する必要があり、これがなされた後でないと、会議を開始することができなかったため、限られた会議時間をロスすることが少なくなかった。本実施の形態では、開始予定時刻になると直ちに会議を開始することが可能な、多地点会議システムについて説明する。
【００９９】
＜システムの構成概要＞
図７は、本実施の形態に係る多地点会議システム２００の構成の概要を示す図である。多地点会議システム２００は、端末装置２０１（２０１ａ、２０１ｂ、２０１ｃ、２０１ｄ）と会議管理装置２０２とが通信網ＮＷを介して接続されたものであり、遠隔地にいる複数人が会議を行うためのシステムである。
【０１００】
端末装置２０１は、会議の各参加者が音声等の送受信に使用するものであり、図７においては図示しない会議データを送受信するための会議データ通信手段を備えており、例えば第１の実施の形態にて示した端末装置１を用いることができる。また、それぞれの端末装置２０１には、互いを識別するための端末名が付与されている。図７においては、それぞれの端末装置２０１の使用者の名前が端末名として付与されている場合を例示的に示している。すなわち、端末装置２０１ａには「ＴＡＮＡＫＡ」、端末装置２０１ｂには「ＳＡＴＯ」、端末装置２０１ｃには「ＳＵＺＵＫＩ」、端末装置２０１ｄには「ＮＡＫＡＭＵＲＡ」という端末名が、それぞれに付与されている。なお、端末名に代わって、ＩＰアドレスなど、それぞれの端末装置２０１に固有の情報などによって識別する態様であってもよい。
【０１０１】
会議管理装置２０２は、所定のプログラムが実行されることにより、コンピュータにおいてその機能が実現するものである。会議管理装置２０２は、ＭＣＵ２０３と入力操作手段２１１と、表示手段２１２と、制御手段２１３と、記憶手段２１４とを主として備えている。ただし、多地点会議システム２００において使用される端末装置２０１は４つに限定されず、一般には複数（多地点会議機能の通常の利用対象としては３以上）の端末装置２０１が使用される。
【０１０２】
入力操作手段２１１は、会議管理装置２０２に対し、命令の実行等の指示を行うためのものであり、例えばマウスやキーボードなどである。表示手段２１２は、会議管理装置２０２の動作状況や、会議の予約状況などを可視的に表示するためのものであり、例えばディスプレイである。制御手段２１３とは、会議管理装置を実現するプログラムを動作させるＣＰＵである。記憶手段２１４とは、例えば会議管理装置を実現するプログラムを記憶する記憶媒体やメモリなどである。
【０１０３】
ＭＣＵ２０３は、多地点会議を実現するための種々の処理を実行するためのものである。なお、図７においては、図示の都合により分けて記載しているが、ＭＣＵ２０３の一部の機能は、制御手段２１３および記憶手段２１４により実現されている。ＭＣＵ２０３は、会議情報管理手段２０４と、通信制御手段２０５と、データミキシング手段２０８とを主として備えている。
【０１０４】
会議情報管理手段２０４は、例えば会議の参加予定者情報など、会議の開催に必要な情報を含む会議開催データファイルＤＦ１を作成し、保持するための手段である。
【０１０５】
通信制御手段２０５は、通信網ＮＷを介した、端末装置２０１との間のデータの送受信を制御するためのものである。通信のためのプロトコルとしては、例えばＲＴＰが用いられる。通信制御手段２０５は、複数の接続チャネルを備えており、それぞれの端末装置２０１から送信されたデータは、どの接続チャネルによって受信されるのかにより識別される。また、通信制御手段２０５は、データミキシング手段２０８においてミキシングされたデータを、会議の参加者が使用している端末装置２０１へとマルチキャスト送信する。
【０１０６】
また、通信制御手段２０５は、会議開催制御手段２０６と、帯域制御手段２０７とを備えている。
【０１０７】
会議開催制御手段２０６は、会議の開催時に、会議データＤｉに基づいて参加者の使用する端末装置２０１へと開催を発呼するために備わる。ここで、開催を発呼するとは、具体的には、それぞれの端末装置２０１に対し、会議データ通信手段を能動化させるための能動化指令信号を発信するという処理のことをいう。すなわち、会議開催制御手段２０６は、能動化指令手段として機能する。また、会議開催制御手段２０６は、会議ごとに使用するスレッドを生成する。複数の会議が並行して行われる場合、通信制御手段２０５はそれぞれの会議についての処理は、各スレッドにて並列に行われることとなる。
【０１０８】
帯域制御手段２０７は、会議の開催に際して、参加する端末装置２０１の数や、取り扱うデータの種類（音声のみ、あるいは映像を含む、など）に応じて、使用する帯域を確保し、調整するためのものである。
【０１０９】
データミキシング手段２０８は、多地点会議の開催中に、複数の端末装置２０１から送信され、通信制御手段２０５において受信される、音声データなどのパケットデータを、一定時間ごとにミキシングして、１つのミキシングパケットとするためのものである。生成されたミキシングパケットは、通信制御手段２０５から、端末装置２０１へとマルチキャスト送信される。
【０１１０】
＜会議の開催処理＞
次に、会議の開催に係る処理について説明する。図８は、本実施の形態に係る会議の開催処理の流れを示す図である。
【０１１１】
まず、会議の開催に先立って、会議開催データファイルＤＦ１が作成される（ステップＳ６１）。図９は、本実施の形態に係る会議開催データファイルＤＦ１を例示的に示す図である。会議開催データファイルＤＦ１には、開催を予定している会議についての情報が、会議データＤｉとして登録される（ステップＳ６２）。図９には、３つの会議データＤ１〜Ｄ３が登録された場合を示している。それぞれの会議データＤｉは、開催を予定する多地点会議を表す会議名レコードＲ１と、その会議への参加予定者の使用する端末装置２０１の装置名がカンマで区切られて列挙された参加者レコードＲ２とから構成されている。会議データＤｉの登録・修正などは、会議情報管理手段２０４によって、入力操作手段２１１、あるいは端末装置２０１のいずれからも、会議の開始時刻までの任意の時点で可能とされている。会議情報管理手段２０４は、例えば端末装置２０１からの登録処理要求に従って、端末装置２０１の図示しない表示部に会議登録処理メニューを表示させる。当該メニューに従った入力がなされることで、会議データＤｉの登録は実行される。
【０１１２】
多地点会議を開始するときには、会議の主催者が、入力操作手段２１１、あるいは端末装置２０１の図示しない入力操作手段によって所定の操作を行うことにより、会議開催データファイルＤＦ１に会議データＤｉとして登録されている会議のなかから開催を所望する会議を選択して、会議開始命令を出す（ステップＳ６３）。会議開催制御手段２０６は、会議開始命令を受けて、選択された会議データＤｉの参加者レコードＲ２に列挙されている端末装置名を有する全ての端末装置２０１に対して、会議開始を発呼する（ステップＳ６４）。
【０１１３】
以上、説明したように、本実施の形態においては、ＭＣＵ２０３が通信の制御に加えて、会議の開催に係る処理を担うので、両者を一体のものとして取り扱うことができ、効率的な処理が可能となる。また、ＭＣＵ２０３から端末装置２０１へと会議の開催を発呼するため、それぞれの端末装置２０１は、ほぼ同時に会議開始が可能な状態に達することになる。これにより、開始に手間取ることなく、多地点会議を行うことができ、会議の参加者においては、会議への参加に際して煩雑な接続手続きを行うことが不要となる。さらに、実施の形態１において説明したのと同様に、多地点会議を開始するときの参加者情報をマルチキャストで送信し、受信した端末装置は自分自身の名前があった場合に接続を開始することもできる。
【０１１４】
＜実施の形態４＞
実施の形態３においては、会議の開始は、主催者の会議開始命令に基づくものであったが、ＭＣＵ２０３において会議の予約管理および時間管理を行い、自動的に開始および終了ができ、さらには、開催中の会議の延長が行える態様であってもよい。本実施の形態においては、こうした態様について説明する。
【０１１５】
図１０は、本実施の形態に係る多地点会議システム３００の構成の概要を示す図である。多地点会議システム３００の構成は、ほぼ、実施の形態３における多地点会議システム２００と同様である。よって、図７において示した多地点会議システム２００の構成要素と同一の構成要素については、同一の符号を付してその説明を省略する。
【０１１６】
多地点会議システム３００においては、ＭＣＵ２０３に、会議予定変更手段３０１と、タイマ３０２とがさらに備わっている。会議予定変更手段３０１は、開催中の会議の延長を行うためのものである。タイマ３０２は、会議の時間管理のために必要な実時間情報を取得するために備わるものである。
【０１１７】
次に、会議の開催に係る処理について説明する。図１１は、本実施の形態に係る会議の開催処理の流れを示す図である。
【０１１８】
まず、会議の開催に先立って、会議開催データファイルＤＦ２が作成される（ステップＳ７１）。図１２は、本実施の形態に係る会議開催データファイルＤＦ２を例示的に示す図である。会議開催データファイルＤＦ２には、開催を予定している会議についての情報が、会議データＤｉとして登録される（ステップＳ７２）。図１２には、３つの会議データＤ４〜Ｄ６が登録された場合を示している。それぞれの会議データＤｉは、開催を予定する多地点会議を表す会議名レコードＲ１と、その会議への参加予定者の使用する端末装置２０１の装置名がカンマで区切られて列挙された参加者レコードＲ２と、会議を開催する予定の日を表す開催日レコードＲ３と、開始予定時刻と終了予定時刻とを表す時間レコードＲ４とから構成されている。すなわち、会議データＤｉの登録は、会議の開催を予約していることに相当する。会議データＤｉの登録・修正などは、会議情報管理手段２０４によって、入力操作手段２１１、あるいは端末装置２０１のいずれからも可能とされている。会議データＤｉの登録については、実施の形態３と同様に行われる。
【０１１９】
会議開催制御手段２０６は、会議開催データファイルＤＦ２に登録されたそれぞれの会議データＤｉの会議開始予定時刻と、タイマ３０２により与えられる時刻情報とを絶えず照合して、登録されている会議データＤｉのいずれかの会議開始予定時刻が到来したか否かを判定する（ステップＳ７３）。会議開催制御手段２０６は、いずれかの会議データＤｉの会議開始時刻に達すると、該当する会議データＤｉの参加者レコードＲ２に列挙されている端末装置名を有する全ての端末装置２０１に対して、会議開始を発呼する（ステップＳ７４）。
【０１２０】
そして、会議が開始されると、今度は、現在開催している会議の会議開催データファイルＤＦ２に登録されているその会議の会議終了予定時刻と、タイマ３０２により与えられる時刻情報とを絶えず照合して、会議終了予定時刻が到来したか否かを判断する（ステップＳ７５）。
【０１２１】
会議終了予定時刻に達すると、会議開催制御手段２０６は、会議終了処理信号を送信してそれぞれの端末装置２０１との接続を切断すると同時に、起動していたスレッドを終了する（ステップＳ７８）。さらに会議情報管理手段２０４に会議終了情報を送信する。会議情報管理手段２０４は、会議終了情報を受け取ると、該当する会議についての会議データＤｉを消去する。
【０１２２】
なお、会議の開催されている間も、他の会議データＤｉに登録されている会議開始時刻に達するか否かは常に判断されており、いずれかの会議データＤｉの会議開始時刻に達すると、並行して会議が開催される。
【０１２３】
なお、直ちに会議を行いたい場合、帯域に空きがあれば、予約をすることなく即座に会議を開始できる態様であってもよい。
【０１２４】
また、会議の開催中に、終了予定を変更する場合は、会議参加者のうちの任意のメンバーが自らの使用している端末装置２０１を通じて、あるいは会議管理装置２０２の入力操作手段２１１を通じて、所定の操作を行うことにより会議終了時刻の変更処理が可能である（ステップＳ７６、Ｓ７７）。これを実現するのが、会議予定変更手段３０１である。会議予定変更手段３０１は、例えば端末装置２０１からの変更処理要求に従って、端末装置２０１の図示しない表示部に時刻変更処理メニューを表示させる。端末装置２０１の使用者が所定の操作を行うことで、会議情報管理手段２０４に保持されている会議開催データファイルＤＦ２のなかの、現在開催中の会議に係る会議データＤｉの終了時刻が変更される。これらの処理がなされた後、会議開催制御手段２０６は、変更された終了時刻に基づいて、会議を終了させるか否かを判断することとなる。
【０１２５】
このように、本実施の形態においては、ＭＣＵに対しあらかじめ会議の開催を予約することができる。また、ＭＣＵは、会議開催データに含まれる時間情報に基づくタイミングで、それぞれの会議の開始、および終了を自動的に行うことができるので、並行して複数の会議を開催するなど会議の予定が複雑になる場合であっても、予定の管理が容易になる。さらに、実施の形態１において説明したのと同様に、多地点会議を開始するときの参加者情報をマルチキャストで送信し、受信した端末装置は自分自身の名前があった場合に接続を開始することもできる。
【０１２６】
＜実施の形態５＞
実施の形態４においては、会議の開始・終了時刻を登録し、これを管理することにより、会議の予約開始が可能であった。一方、通信網を用いて多地点会議を行う場合、一般には使用できる帯域が制限されているため、一度に並行して開催できる会議の数には限りがある。よって、多くの会議が並行して開催されるような場合は、会議の予約に際して、帯域に空きがあるか否かを把握する必要がある。本実施の形態においては、実施の形態４において示した多地点会議システム３００において、これを実現する態様について説明する。
【０１２７】
本実施の形態においては、会議情報管理手段２０４が、会議データＤｉの登録の際に、それぞれの会議データＤｉに対して予約帯域幅を設定する。予約帯域幅とは、会議の参加人数や、やりとりされるデータの種類（音声のみ、あるいは映像付き、など）に応じてあらかじめ見積られる、それぞれの会議に占有される帯域幅である。参加者１人あたり数十ｋＢずつの帯域幅を確保する、などの態様がその一例である。会議における通信の品質を保つ必要から、参加人数が多いほど、あるいは音声のみよりも映像を併用した方が、占有される帯域幅が大きくなるので、予約帯域幅も大きくなる。また、通信の安定性を確保するため、実際に必要な最小限度の帯域幅よりは、多少余裕を持たせて設定されるのが望ましい。設定された予約帯域幅は、会議データＤｉの一項目として付加され記憶される。
【０１２８】
新たな会議の予約の要求に際しては、会議情報管理手段２０４が、他の会議予定の登録状況に基づき、予約者の開催希望日時における通信帯域の利用状況を判定する。すなわち、会議データＤｉに付加された予約帯域幅のデータに基づいて、使用可能と判断されている帯域幅が、新たに予約しようとする会議で使用するために必要な帯域幅を超えるか否かを判定して、その予約の可否を判断する。
【０１２９】
図１３は、これを説明するための、ある日の会議予約の登録状況を例示的に示す図である。図１３においては、横軸が時間軸８１、横軸は使用可能な帯域幅８２をパーセンテージで示している。図１３（ａ）は、会議Ａ、Ｂ、Ｃ、およびＤの４つの会議が予約する会議時間と帯域幅とが、それぞれ長方形８３、８４、８５、および８６にて示されている。例えば、会議Ａは、使用可能な帯域幅のうち４０％を予約帯域幅として確保し、４時間の実施が予定されている会議である。また、図１３（ｂ）は、（ａ）で示した登録状況を、予約帯域幅、および帯域の空きがわかりやすくなるように書き換えたものである。
【０１３０】
図１３（ｂ）に示す場合、１０時から１２時までは３つの会議で帯域を１００％利用するので、この時間帯にはこれ以上、会議の予約を行うことはできない。すなわち、この時間帯に会議の予約の要求があったとしても、使用できる帯域に余裕がないとして、会議情報管理手段２０４はこれを拒否する。以降の時間帯については、１２時から１４時の間は２０％の空きがあり、１４時から１６時までは６０％の空きがあり、１６時から１８時は８０％の空きがある。さらに、１８時以降は１００％の空きがある。これらの時間帯であれば、開催を設定しようとする会議の予約帯域幅が、利用可能な帯域幅を超えない範囲で、会議の予約を登録することが可能である。
【０１３１】
なお、すでに予約済の会議について、開催までにその開催の時間帯を変更したい場合（開催時刻の変更、終了時刻時刻の変更）も、同様に予約帯域幅からその可否を判定できる態様であってもよい。変更が認容される場合、会議データＤｉの内容は書き換えられる。
【０１３２】
以上のように、予定登録されている会議のそれぞれの必要帯域幅の合計と、利用可能な帯域幅の最大値との差が、開催を予約をしようとする会議の必要帯域幅を収容可能であるか否かに応じて、予約の可否を判断することによって、通信の品質を確保しつつ、帯域幅を有効活用した会議の予約を行うことができる。
【０１３３】
＜実施の形態６＞
実施の形態５は、予約帯域幅に基づいて、会議の予約の要求の可否を判断する態様であったが、実際に開催されている会議の終了時刻を変更する際にも、予約帯域幅を考慮してその可否を判断する態様であってもよい。以下、これを説明する。
【０１３４】
実施の形態４にて説明したように、会議予定変更手段３０１は、端末装置２０１の図示しない表示部に時刻変更処理メニューを表示させ、参加者はこれに基づいて現在開催中の会議に係る会議データＤｉの終了時刻を変更するが、本実施の形態においては、この変更処理に際して、会議データＤｉに付加された予約帯域幅の情報を参照して、その変更の可否を判断する。
【０１３５】
例えば、図１３の１１時の時点で考えると、この時点では会議Ａ、会議Ｂ、および会議Ｄの３つの会議が開催中である。このとき、会議Ａのいずれかの参加者が、当初の終了予定時刻である１４時以降に会議を延長しようとする場合を考えると、当該参加者は、端末装置２０１において時刻変更処理メニューに従ってその意図する変更内容を入力すると、会議予定変更手段３０１がその変更しようとする時刻の予約帯域幅の情報を取得し、その可否を判断することとなる。いまの場合、会議Ａは４０％の予約帯域幅を有しているが、１１時の時点において、１４時以降には４０％以上の空きの帯域が存在するので、会議予定変更手段３０１が会議Ａの終了時刻の繰り下げは可能と判断し、これを参加者に通知するとともに、会議情報管理手段２０４は、会議データＤｉの終了時刻の情報を書き換える。
【０１３６】
一方、会議Ｂは、４０％の帯域幅を有し１２時に終了予定であるが、１１時の時点では、１２時以降に空きの帯域は２０％しかないので、会議Ｂの参加者が時刻変更処理メニューを利用して会議の終了時刻を繰り下げようとする場合には、会議予定変更手段３０１はこれを不可と判断し、参加者に通知することとなる。ただし、その後、同時に開催されている会議Ｄが１２時までに終了する、あるいは、１２時から開催予定の会議Ｃが予定変更により繰り下げあるいは中止される、などの状況が生じれば、１２時以降に４０％の帯域の空きが生じるので、会議Ｂの延長は、可能となる。
【０１３７】
以上のような態様をとることによって、通信の品質を確保しつつ、帯域幅を有効活用した会議の予約および開催中の会議の予定変更を行うことができる。
【０１３８】
＜変形例＞
実施の形態１においては、音声データを例に同期の確立を図る態様について説明した。映像データに対しても、同期の確立を行う態様であってもよい。音声データの場合、その目的は、エコーキャンセルを精度よく行うためであった。一方、映像データの場合は、例えば、会議の参加者が同一の映像を見ながら会話を行う場合など、その映像データが到達する時間に遅延が生じる際に、その遅延時間を把握し画面表示として出力するなどの態様が好ましい場合がある。これにより、当該遅延時間を考慮した間合いを取りながら、会議を進行することができるからである。従って、図２において入出力の対象を音声データから映像データに置き換え、エコーキャンセルの処理を無視することにより、映像データの場合も、音声データと同様に同期の確立処理を行うことができる。
【０１３９】
実施の形態５および６は、予約帯域幅を設定する態様であったが、予約帯域幅は、会議の開催に必要な最小限度の帯域幅よりも余裕を持たせて設定することが可能であるため、予約帯域幅の総和から判断するとさらに新たな会議を行うことは認められない場合でも、帯域制御手段２０７が実際に使用されている帯域幅の情報をリアルタイムに会議情報管理手段２０４に与えることで、新たな会議の設定が可能となる対応であってもよい。
【０１４０】
実施の形態１および２に示した、同期の確立のためになされるデータ処理の方法が適用される対象は、多地点会議システムに限定されない。ＲＴＰを利用する通信システムであれば、他のシステムであっても、同様の処理態様にて同期の確立が可能である。
【０１４１】
【発明の効果】
以上、説明したように、請求項１の発明によれば、最適な伝送状態を実現できる。例えば、多地点会議の参加者が使用する端末装置におけるデータの遅延時間を知るために必要な、同期の確立を行うことができる。また、同期パケットデータを、通常の会議データと同一のプロトコルを利用して送信できるので、同期の確立のために新たにプロトコルを具備する必要がなく、また、データは書き換えられるのみで新たに付加されることがないので、パケットデータのデータ構造を拡張する必要もない。さらには、不要なペイロード部分のデータをミキシングすることがないので、ミキシングに伴うノイズを発生させることがなく、トラフィックの負荷の低減もできる。また、音声データについて同期が確立されるので、エコーキャンセル処理に供することが可能となり、会議時に聴取する音声を聞き取りやすくすることができる。
【０１４２】
請求項２の発明によれば、一定の時間間隔で送出される同期パケットデータの個数に対応した個数のミキシングパケットデータの受信することで、同期の確立が判断できる。
【０１４３】
請求項３の発明によれば、会議への参加に先立って、同期の確立を優先的にかつ速やかに行うことができる。
請求項４の発明によれば、第１伝送パケットデータを受信した接続チャネルを特定すれば、送信元の端末装置を特定することができるので、端末装置から第１伝送パケットデータを送出するにあたって該端末装置を識別するための情報を該第一伝送パケットデータに記述する必要がない。
【０１４４】
請求項５の発明によれば、データミキシング処理装置における、パケットデータの識別、到達の確認、あるいは欠落の有無の確認が容易になる。
【０１４７】
請求項６の発明によれば、同期の確立により得られた遅延時間に基づいてエコーキャンセルが行えるので、聞き取りやすい音声データを提供することができる。
【０１４８】
請求項７の発明によれば、最適な伝送状態を実現できる。例えば、多地点会議の参加者が使用する端末装置におけるデータの遅延時間を知るために必要な、同期の確立を行うことができる。また、同期パケットデータを、通常の会議データと同一のプロトコルを利用して送信できるので、同期の確立のために新たにプロトコルを具備する必要がなく、また、データは書き換えられるのみで新たに付加されることがないので、パケットデータのデータ構造を拡張する必要もない。また、音声データについて同期が確立されるので、エコーキャンセル処理に供することが可能となり、会議時に聴取する音声を聞き取りやすくすることができる。
【０１５２】
請求項８の発明によれば、同期の確立により得られた遅延時間に基づいてエコーキャンセルが行えるので、聞き取りやすい音声データを提供することができる。
【０１５３】
請求項９の発明によれば、最適な伝送状態を実現できる。例えば、同一のプロトコルにより送信されてきた通常の会議データと同期パケットデータとを判別することができ、さらに到達した同期パケットに関する情報をミキシングパケットに付与することができる。また、不要なペイロードデータをミキシングすることがないので、ミキシングに伴うノイズを発生させることがなく、トラフィックの負荷の低減もできる。
【図面の簡単な説明】
【図１】 この発明の実施の形態１に係る多地点会議システム１００の構成図である。
【図２】 この発明の実施の形態１に係る多地点会議システム１００における処理の流れを示す図である。
【図３】 この発明の実施の形態１に係る多地点会議システム１００におけるデータ構造の変化を示す図である。
【図４】 この発明の実施の形態１に係るデータミキシング装置２０Ｍにおけるミキシング処理の流れを示す図である。
【図５】 この発明の実施の形態１に係る端末装置１におけるミキシングデータ受信後の処理の流れを示す図である。
【図６】 この発明の実施の形態１に係る端末装置１における同期確立の際の処理の流れを示す図である。
【図７】 この発明の実施の形態３に係る多地点会議システム２００の構成の概要を示す図である。
【図８】 この発明の実施の形態３に係る会議の開催処理の流れを示す図である。
【図９】 この発明の実施の形態３に係る会議開催データファイルＤＦ１を例示的に示す図である。
【図１０】 この発明の実施の形態４に係る多地点会議システム３００の構成の概要を示す図である。
【図１１】 この発明の実施の形態４に係る会議の開催処理の流れを示す図である。
【図１２】 この発明の実施の形態４に係る会議開催データファイルＤＦ２を例示的に示す図である。
【図１３】 この発明の実施の形態５に係るある日の会議予約の登録状況を例示的に示す図である。
【図１４】 従来の３者通話の方法を示す図である。
【符号の説明】
１，２０１ 端末装置、１Ｒ データ受信部、１Ｓ データ送信部、２ 入力手段、３ データ入力処理手段、４ 同期パケット生成手段、５ タイミング指標付加手段、６ データ送信手段、７ データバッファ、８ データ受信手段、９ ミキシングパケット検査手段、１０ データ出力処理手段、１１ 出力手段、２０，２０３ ＭＣＵ、２０Ｃ 通信制御装置、２０Ｍ データミキシング装置、２１ データ受信手段、２２ 識別子付加手段、２３ パケットデータ判定手段、２４ ペイロード廃棄手段、２５ ダミーパケット記憶手段、２６ 識別子合成手段、２７ データミキシング手段、２８ タイミング指標付加手段、２９ データ送信手段、３０ パケット、３１，３９ ヘッダ、３２，４２ ペイロード、３３ 同期識別パターンデータ、３４，４０ シーケンス番号、３５ 同期パケット、３６ 識別子、３７ ダミーパケット、３８ ミキシングパケット、４１ 識別子情報、８１ 時間軸、８２ 帯域幅、１００，２００，３００多地点会議システム、２０２ 会議管理装置、２０４ 会議情報管理手段、２０５ 通信制御手段、２０６ 会議開催制御手段、２０７ 帯域制御手段、２０８ データミキシング手段、２１１ 入力操作手段、２１２ 表示手段、２１３制御手段、２１４ 記憶手段、３０１ 会議予定変更手段、３０２ タイマ、Ｄｉ 会議データ、ＤＦ１，ＤＦ２ 会議開催データファイル、ＮＷ 通信網、Ｒ１ 会議名レコード、Ｒ２ 参加者レコード、Ｒ３ 開催日レコード、Ｒ４ 時間レコード。
【発明の属する技術分野】
この発明は通信網上で３人以上の利用者による会議を実現する技術に関するものである。
【０００２】
【従来の技術】
通信網上で二者が会議を行う場合には、自分が発した音声データを相手に送信し、相手が発した音声データを受信することにより通話することが可能である。しかし、三者以上が通信網上の会議を行う場合、従来は、ミキサーによって参加者の音声を合成してから音声データを各参加者に送信する手順が必要であった。図１４は、従来の三者通話について概念的に表す図である。図１４においては、多地点通信制御装置（Ｍｕｌｔｉｐｏｉｎｔ Ｃｏｎｔｒｏｌ Ｕｎｉｔ：以下、ＭＣＵと略す）１０００を介して、３つの通話用端末装置１００１〜１００３が、音声データをやりとりする場合を示している。
【０００３】
まず、通話用端末装置（端末Ａ〜Ｃ）１００１〜１００３から発話音声データ１００４、１００５、および１００６がそれぞれＭＣＵ１０００へと送信され、ＭＣＵ１０００のデータ受信バッファ１０１０に記憶される。これらの発話音声データ１００４〜１００６は、図示しないミキサーにて各通話用端末装置向けの受話音声データ１００７〜１００９としてミキシングされ、データ送信バッファ１０１１から通話用端末装置１００１〜１００３に対しそれぞれ送信される。このとき、自己が発した音声データが受信する音声データに含まれていると、他者の音声が聞き取りにくくなるため、ミキサーは、それぞれの受話音声データ１００７〜１００９に、当該データを受信する通話用端末装置を使用する各参加者の音声データが含まれないように、参加者ごとの送信キューを作成していた。
【０００４】
【発明が解決しようとする課題】
上記のような従来のＭＣＵには、参加者ごとに異なる音声データをミキシングして送るため、参加者が増えるたびにそのデータ量が増大し、帯域を有効活用できないという問題がある。
【０００５】
ミキサーがマルチキャストで音声データを送信し、参加者全員に同一の音声データを送信することで、帯域の有効活用は行えるが、この場合は自分自身が発した音声まで受信してしまうことになり、音声が聞き取りにくくなって会話がしづらくなるという問題がある。このため、受信した音声データから、自己が発した音声データを消去する必要がある。
【０００６】
また、三者以上で会議を行う場合、会議を開始するには、それぞれの参加者が自らの使用する通話用端末装置をＭＣＵに接続する必要があった。また、ＭＣＵには複数のグループが同時に会議をするための機能も備わっているが、この場合、会議の参加者は、自らのグループが会議を行う会議室名をあらかじめ知っておく必要がある。したがって、従来のＭＣＵを用いた会議では、参加者は、グループのキーワードである会議室名を予め電子メールや口頭で知らされない限り、会議に参加することができないという問題があった。また、帯域および会議システムのリソースが不足して、新たな会議を始めることができないなどの問題があった。
【０００７】
この発明は、上述のような課題を解消するためになされたもので、例えば、発信側から送信した送信データが当該発信側に戻る際の時間差を知ることによって、最適な伝送状態を実現することを目的とする。
【０００８】
また、マルチキャストで音声データを送信した場合において、自己が発した音声データを消去して会話を聞き取りやすくすることを目的とする。
【０００９】
また、参加者が会議に参加する際の利便性の向上や、会議に係るリソースの有効利用を図ることを目的とする。
【００１０】
また、参加者が増えたとしても、ＭＣＵから送信されるデータ量の増加を抑制しながら、帯域の有効利用を図ることを目的とする。
【００１１】
【課題を解決するための手段】
上記課題を解決するため、請求項１の発明は、複数の端末装置からなる端末装置群と、前記端末装置群とネットワークを介して結合されるデータミキシング処理装置と、を備える多地点会議システムであって、前記複数の端末装置のそれぞれがデータ送信装置とデータ受信装置とを備え、a)前記データ送信装置は、a-1)所定の入力手段によって入力された音声データである入力データから原パケットデータを生成するデータ入力処理手段と、a-2)所定の個数の前記原パケットデータのペイロードの一部を同期用情報に書き換えて当該個数の同期パケットデータを生成する同期パケット生成手段と、a-3)当該端末装置における送受信の同期が確立されるまでは前記同期パケットデータを対象パケットデータとし、前記送受信の同期が確立した後は前記原パケットデータを対象パケットデータとして、前記対象パケットデータを当該データ送信装置から送信するタイミングを表現した第１のタイミング指標を付加することにより、第１伝送パケットデータを生成する第１タイミング指標付加手段と、a-4)前記第１タイミング指標が付加された前記第１伝送パケットデータを一定の時間間隔で送出する第１送出手段と、を有してなり、b)前記データミキシング処理装置は、b-1)前記各端末装置から送出される前記第１伝送パケットデータを受信し、そのヘッダ部にその送出元である端末装置を示す識別子を付加する識別子付加手段と、b-2)受信した前記第１伝送パケットデータが前記同期パケットデータであるか否かを判定する判定手段と、b-3)前記同期パケットデータであると判定された前記第１伝送パケットデータのペイロード部を廃棄し、残りをダミーパケットデータとして出力する廃棄手段と、b-4)前記ダミーパケットデータと、前記同期パケットデータでないと判定された前記第１伝送パケットデータとをミキシング対象データとし、前記ミキシング対象データを用いてミキシングパケットデータを生成するミキシング処理を行うミキシング処理手段と、b-5)前記ミキシング処理手段から出力される前記ミキシングパケットデータに、前記ミキシングパケットデータを当該データミキシング処理装置から送出するタイミングを表現する第２のタイミング指標を付加する第２タイミング指標付加手段と、b-6)前記第２タイミング指標付加手段から出力される前記ミキシングパケットデータを一定の時間間隔で前記端末装置群を構成する全ての端末装置に送出する第２送出手段と、を有してなり、c)前記データ受信装置は、c-1)前記データミキシング処理装置から送出される前記ミキシングパケットデータを受信し、前記ミキシングパケットデータに基づいて当該端末装置における送受信の同期を確立する同期確立手段と、c-2)前記同期が確立されるまでは受信した前記ミキシングパケットデータを廃棄すると共に、前記同期が確立された以降に受信した前記ミキシングパケットデータを維持する検査手段と、c-3)前記検査手段に維持された前記ミキシングパケットデータから、前記複数の端末装置において入力された音声データを復元する復元手段と、を有してなり、前記ミキシング処理は、前記ミキシング対象データのそれぞれのヘッダ部に付加されてなる前記識別子の情報を合成することによる識別子情報の生成と、前記同期パケットデータでないと判定された前記第１伝送パケットデータのペイロード部の合成とを含む処理であり、前記同期確立手段は、順次に受信する複数の前記ミキシングパケットデータに当該データ受信装置を含む当該端末装置を特定する情報が前記識別子情報に含まれてなり、かつ、前記複数のミキシングパケットデータのそれぞれに付加されてなる前記第２タイミング指標に所定の一連性があるか否かを判断し、前記一連性がある場合に、前記第１タイミング指標と前記第２タイミング指標を関連付けることによって前記送受信の同期の確立を実現する、ことを特徴とする。
【００１２】
請求項２の発明は、請求項１に記載の多地点会議システムであって、前記同期確立手段が前記所定の一連性の判断を行う場合に、判断対象である前記第２タイミング指標の個数と当該端末装置より送出された前記同期パケットデータの前記所定の個数の一致の有無を判断の対象とすることを特徴とする。
【００１３】
請求項３の発明は、請求項１または請求項２に記載の多地点会議システムであって、所定時間の間に前記送受信の同期が確立できない場合は、前記同期パケット生成手段における前記同期パケットデータの生成を繰り返すことを特徴とする。
請求項４の発明は、請求項１ないし請求項３のいずれかに記載の多地点会議システムであって、前記識別子付加手段が、送出元である前記各端末装置ごとに異なる接続チャネルで前記第１伝送パケットデータを受信するように構成されてなり、前記第１伝送パケットデータを受信した前記接続チャネルを特定する情報に基づいて前記識別子を付加することを特徴とする。
【００１４】
請求項５の発明は、請求項１ないし請求項４のいずれかに記載の多地点会議システムであって、前記第１タイミング指標が、前記第１伝送パケットデータのそれぞれに固有に与えられる第１シーケンス番号であり、前記第２タイミング指標が、前記ミキシングパケットデータのそれぞれに固有に与えられる第２シーケンス番号であることを特徴とする。
【００１７】
請求項６の発明は、請求項１ないし請求項５のいずれかに記載の多地点会議システムであって、前記検査手段が、前記第１タイミング指標と前記第２タイミング指標とに基づいて前記送受信の遅延時間を特定する手段を含み、前記データ受信装置が、前記遅延時間の情報に基づいて、当該端末装置から前記データミキシング処理装置に送信した前記音声データに基づく前記第１伝送パケットデータを、復元された前記音声データから除去するエコーキャンセル手段をさらに備える、ことを特徴とする。
【００１８】
請求項７の発明は、複数の端末装置からなる端末装置群と、前記端末装置群とネットワークを介して結合されるデータミキシング処理装置と、を備える多地点会議システムを構成する端末装置であって、データ送信装置とデータ受信装置とを備え、a)前記データ送信装置は、a-1)所定の入力手段によって入力された入力データから原パケットデータを生成するデータ入力処理手段と、a-2)所定の個数の前記原パケットデータのペイロードの一部を同期用情報に書き換えて当該個数の同期パケットデータを生成する同期パケット生成手段と、a-3)当該端末装置における送受信の同期が確立されるまでは前記同期パケットデータを対象パケットデータとし、前記送受信の同期が確立した後は前記原パケットデータを対象パケットデータとして、前記対象パケットデータを当該データ送信装置から送信するタイミングを表現した第１のタイミング指標を付加することにより、第１伝送パケットデータを生成する第１タイミング指標付加手段と、a-4)前記第１タイミング指標が付加された前記第１伝送パケットデータを一定の時間間隔で送出する第１送出手段と、を有してなり、b)前記データ受信装置は、b-1)前記データミキシング処理装置においてミキシング処理され第２タイミング指標が付加されたうえで一定の時間間隔で前記データミキシング処理装置から送出されるミキシングパケットデータを受信し、前記ミキシングパケットデータに基づいて当該端末装置における送受信の同期を確立する同期確立手段と、b-2)前記同期が確立されるまでは受信した前記ミキシングパケットデータを廃棄すると共に、前記同期が確立された以降に受信した前記ミキシングパケットデータを維持する検査手段と、b-3)前記検査手段に維持された前記ミキシングパケットデータから、前記複数の端末装置において入力された音声データを復元する復元手段と、を有してなり、前記ミキシング処理は、同期パケットデータである前記第１伝送パケットデータのペイロード部を廃棄した残りであるダミーパケットデータと、前記同期パケットデータでない前記第１伝送パケットデータとをミキシング対象データとする、前記ミキシング対象データのそれぞれのヘッダ部に付加されてなる前記複数の端末装置のそれぞれを識別する識別子の情報を合成することによる識別子情報の生成と、前記同期パケットデータでない前記第１伝送パケットデータのペイロード部の合成とを含む処理であり、前記同期確立手段は、順次に受信する複数の前記ミキシングパケットデータに当該データ受信装置を含む当該端末装置を特定する情報が前記識別子情報に含まれてなり、かつ、前記複数のミキシングパケットデータのそれぞれに付加されてなる前記第２タイミング指標に所定の一連性があるか否かを判断し、前記一連性がある場合に、前記第１タイミング指標と前記第２タイミング指標を関連付けることによって前記送受信の同期の確立を実現する、ことを特徴とする。
【００２２】
請求項８の発明は、請求項７に記載の多地点会議システムの端末装置であって、前記検査手段が、前記第１タイミング指標と前記第２タイミング指標とに基づいて前記送受信の遅延時間を特定する手段を含み、前記データ受信装置が、前記遅延時間の情報に基づいて、当該端末装置から前記データミキシング処理装置に送信した前記入力データに基づく前記第１伝送パケットデータを、復元された前記音声データから除去するエコーキャンセル手段をさらに備える、ことを特徴とする。
【００２３】
請求項９の発明は、複数の端末装置からなる端末装置群と、前記端末装置群とネットワークを介して結合されるデータミキシング処理装置と、を備える多地点会議システムを構成するデータミキシング処理装置であって、第１のタイミング指標を付加したうえで前記各端末装置から送出される第１伝送パケットデータを受信し、そのヘッダ部にその送出元である端末装置を示す識別子を付加する識別子付加手段と、受信した前記第１伝送パケットデータが、前記各端末装置において所定の入力手段によって入力された入力データから生成された原パケットデータか、前記原パケットデータのペイロードの一部を同期用情報に書き換えて生成された同期パケットデータであるか否かを判定する判定手段と、前記同期パケットデータであると判定された前記第１伝送パケットデータのペイロード部を廃棄し、残りをダミーパケットデータとして出力する廃棄手段と、前記ダミーパケットデータと、前記同期パケットデータでないと判定された前記第１伝送パケットデータとをミキシング対象データとし、前記ミキシング対象データを用いてミキシングパケットデータを生成するミキシング処理を行うミキシング処理手段と、前記ミキシング処理手段から出力される前記ミキシングパケットデータに、前記ミキシングパケットデータを当該データミキシング処理装置から送出するタイミングを表現する第２のタイミング指標を付加する第２タイミング指標付加手段と、前記第２タイミング指標付加手段から出力される前記ミキシングパケットデータを前記端末装置群を構成する全ての端末装置に送出する第２送出手段と、を有してなり、前記ミキシング処理は、前記ミキシング対象データのそれぞれのヘッダ部に付加されてなる前記識別子の情報を合成することによる識別子情報の生成と、前記同期パケットデータでないと判定された前記第１伝送パケットデータのペイロード部の合成とを含む処理である、ことを特徴とする。
【００４０】
【発明の実施の形態】
＜実施の形態１＞
＜システムの構成概要＞
図１はこの発明の実施の形態１に係る多地点会議システム１００の構成の概要を示す図である。多地点会議システム１００は、通信網を利用して、遠隔地にいる複数人が会議を行うためのシステムであり、複数（通常は３以上）の端末装置１（１ａ、１ｂ、・・・、１ｎ）とからなる端末装置群と、これと通信網を介して接続されるＭＣＵ（Multipoint Control Unit）２０とを主として備える。端末装置１とＭＣＵ２０とはいずれも、所定のプログラムを実行することにより、それぞれのコンピュータ（ＰＣ）においてその機能が実現するものである。多地点会議システム１００においては、それぞれの端末装置１からデータが送信され、ＭＣＵ２０へと送られた後に、ＭＣＵ２０においてこれらが合成されてマルチキャストにてそれぞれの端末装置１へと送信される。これにより、セッションが成立することになる。ただし、マルチキャスト送信においては、全てのデータが全ての端末装置１に送信されるため、それぞれのデータの送信元である端末装置１（例えば端末装置１ａ）には、他の端末装置１（例えば端末装置１ｂ、・・・、１ｎ）から送信されたデータのみを使用者たる会議の参加者に提供すべく、自らが発したデータをキャンセルする機能が備わっている。なお、データの送受信のためのプロトコルとしては、ＲＴＰ（Real-time Transport Protocol）が用いられる。
【００４１】
端末装置１は、多地点会議に参加する参加者ごとに備わるものであり、参加者の発話データや映像データの入力を受け、これに適式な処理を施した後に、データミキシング装置に向けて送信したり、あるいは他の参加者の使用する端末装置１から送信され、後述するように、ＭＣＵ２０にてミキシングされた発話データや映像データを受信して、適式な処理を施し、参加者が視聴可能となるように出力するためのものである。ただし、図示の都合により図１においては１つの端末装置１ａのみその内部構成が示されているが、他の端末装置１ｂ、・・・、１ｎの内部構成も同様である。
【００４２】
端末装置１は、例えばマイクやカメラなどの入力手段２と、入力されたデータを送信可能な形式に変換したり、データの同期を確立するための処理するなど、送信に際し必要な種々の処理を行うデータ送信部１Ｓと、受信したデータを参加者が視聴可能な形式に変換するなど受信後に必要な種々の処理を行うデータ受信部１Ｒと、処理中のデータを一時的に記憶するデータバッファ７と、例えばスピーカやディスプレイなどの出力手段１１とを主として備える。
【００４３】
データ送信部１Ｓは、データ入力処理手段３と、同期パケット生成手段４と、タイミング指標付加手段５と、データ送信手段６とを主として備える。
【００４４】
データ入力処理手段３は、入力手段２から入力されたデータをＡ／Ｄ変換し、一定のデータ長を有するパケット３０（図３）に分割する処理、及びエコーキャンセル処理をする際に必要なデータをデータバッファ７へと記憶する処理、などを担うためのものである。同期パケット生成手段４は、送信するデータの同期を確立するための同期確立過程において能動化されて、同期パケット３５（図３）を、データ入力処理手段３にて生成されたもともとのパケット（原パケット）であるパケット３０をベースに生成する。タイミング指標付加手段５は、シーケンス番号３４（図３）を、パケット３０のヘッダ部分に送信される順に付加するためのものである。シーケンス番号３４は、端末装置１からデータが送信された後、ＭＣＵ２０からマルチキャスト送信されて再び端末装置１に戻ってくるまでの時間的な遅れを知るために与えられる、個々のパケット３０に固有の番号である。また、データミキシング装置２０Ｍにおいては、シーケンス番号３４を参照することで、パケットデータの欠落の有無などの判断も可能である。データ送信手段６は、ＲＴＰに従って、パケット３０をＭＣＵ２０に対し順次送信するためのものである。
【００４５】
以上より、入力手段２およびデータ送信部１Ｓに着目すると、端末装置１はパケットデータの送信を担うデータ送信装置として機能する部分を有するといえる。
【００４６】
データ受信部１Ｒは、データ受信手段８と、ミキシングパケット検査手段９と、データ出力処理手段１０とを主として備える。
【００４７】
データ受信手段８は、データミキシング装置２０Ｍから、ＲＴＰに従ってマルチキャストに送信されたパケットデータを受信するためのものである。ミキシングパケット検査手段９は、データ受信手段８が受信したパケット（以下、「伝送パケット」）が同期パケット３５であるか否か、あるいは同期が確立したか否かなどについて判定するためのものである。データ出力処理手段１０は、同期が確立しないあいだは、受信した同期パケットを廃棄する処理、および出力手段１１においてデータの出力を行わせない処理を、同期が確立した後は、パケット３０に分割されているデータの復元処理、エコーキャンセル処理、Ｄ／Ａ変換処理などを行うためのものである。
【００４８】
以上より、出力手段１１およびデータ受信部１Ｒに着目すると、端末装置１はデータの受信を担うデータ受信装置として機能する部分を有するといえる。
【００４９】
なお、端末装置１におけるそれぞれの処理については後述する。
【００５０】
ＭＣＵ２０は、複数の端末装置１から送信された複数のパケットデータを１つのデータにミキシングして新たなパケットデータであるミキシングパケット３８（図３）を生成し、これを再びそれぞれの端末装置１に対してマルチキャストに送信するためのものである。この目的のため、ＭＣＵ２０は、通信制御装置２０Ｃと、データミキシング装置２０Ｍとを主として備える。このように構成することによって、マルチキャスト送信が可能となり、帯域の有効活用が図れる。
【００５１】
通信制御装置２０Ｃは、データ受信手段２１と、データ送信手段２９とを主として備える。データミキシング装置２０Ｍは、ＣＳＲＣ識別子付加手段２２と、パケットデータ判定手段２３と、ペイロード廃棄手段２４と、ダミーパケット記憶手段２５と、ＣＳＲＣ識別子合成手段２６と、データミキシング手段２７と、タイミング指標付加手段２８とを主として備える。
【００５２】
データ受信手段２１は、端末装置１からＲＴＰに従って送信された伝送パケットを受信するためのものである。データ受信手段２１は、複数の接続チャネルを備えており、データの送信元は、受信した接続チャネルで識別される。また、データ受信手段２１には、それぞれの端末装置１との接続が確立すると、端末装置１ごとの受信スレッド（図示せず）が作成され、それぞれの端末装置１からのデータは対応する受信スレッドに保存される。ＣＳＲＣ識別子付加手段２２は、データを受信した接続チャネルの情報に基づき、どの端末装置１から送信された伝送パケットであるのかを識別するためのＣＳＲＣ識別子（寄与送信元識別子）３６（図３）を、受信した伝送パケットに付加するためのものである。パケットデータ判定手段２３は、受信した伝送パケットが、同期パケット３５であるか否かを判定するためのものである。ペイロード廃棄手段２４は、受信した伝送パケットが同期パケット３５である場合に、そのペイロード３２を廃棄するためのものである。ダミーパケット記憶手段２５は、受信した伝送パケットが同期パケット３５であったことを記憶するためのものである。
【００５３】
ＣＳＲＣ識別子合成手段２６、データミキシング手段２７、およびタイミング指標付加手段２８は、ミキシングパケット３８（図３）を生成するためのものである。このうち、ＣＳＲＣ識別子合成手段２６は、ミキシングパケット３８のヘッダ部分に、ミキシングされたデータの送信元のＣＳＲＣ識別子情報４１（図３）を合成し付与するためのものである。データミキシング手段２７は、複数の端末装置１から送信された伝送パケットのペイロード３２（図３）をミキシングするためのものである。タイミング指標付加手段２８は、端末装置１に備わるタイミング指標付加手段５と同様に、シーケンス番号を、ミキシングパケット３８のヘッダ部分に、送信される順に付加するためのものである。データ送信手段２９は、ＲＴＰに従って、それぞれの端末装置１に対してミキシングパケット３８をマルチキャスト送信する。
【００５４】
なお、ＭＣＵ２０におけるそれぞれの処理については後述する。
【００５５】
＜定常のデータ処理＞
次に、多地点会議システム１００を用いた会議の実行時、いわば定常処理時におけるデータの処理について、音声データを例にして説明する。多地点会議システム１００においては、それぞれの参加者が発する音声は、当該参加者が使用する端末装置１から音声データとしてＭＣＵ２０に送られ、１つの音声データにミキシングされた後、マルチキャスト配信され、再び端末装置１に戻ってくる。以下の説明は、これらの処理に関するものである。なお、端末装置１においては、ミキシングされた音声データから、自らが発した音声を消去するエコーキャンセルを行うが、そのために必要な同期確立処理については後述する。
【００５６】
図２は、多地点会議システム１００における処理の流れを説明するための図である。図２においては、点線で示す矢印ＡＲ５が、データの同期を確立するための処理の流れを示している。なお、図１において点線で示す矢印ＡＲ２は、多地点会議システム１００においてデータが受け渡される様子を、図２と対応させて示したものである。図３は、多地点会議システム１００における種々の処理に伴うデータ構造の変化を、模式的に示す図である。図３（ｂ）が、以下に示す音声データ処理の場合を示している。
【００５７】
多地点会議のある参加者（以降、「参加者Ａ」とする）が使用する端末装置１が、所定の通信網に接続され、多地点会議システムを利用するための所定のプログラムが動作し、会議への参加が可能な状態になると、入力手段２であるマイクを通じて音声入力が可能となる（ステップＳ１）。その後、まずは後述する同期確立処理が施され、エコーキャンセルが可能な状態になると、参加者Ａの会議への実質的な参加が可能となる。
【００５８】
入力手段２から入力された音声データは、データ入力処理手段３においてＡ／Ｄ変換される（ステップＳ３）。そして、後のエコーキャンセル処理のためにデータバッファ７に保存される（ステップＳ４）一方で、所定のデータ長ごとのパケットに分割される（ステップＳ５）。それぞれのパケット３０は、図３（ｂ）の［１］のように、制御信号等が格納されるヘッダ３１と、音声データが格納されるペイロード３２とからなるパケットデータとして構成される。なお、本発明において用いる「パケット」なる用語は、多地点会議システム１００を構成する通信網がデータリンク層に相当するものである場合は「フレーム」と同義である。
【００５９】
次に、タイミング指標付加手段５が、図３（ｂ）の［３］のように、パケット３０を対象パケットとして、そのヘッダ３１にシーケンス番号３４を付加する（ステップＳ７）。シーケンス番号３４は、元の音声データのデータ配列に従ってそれぞれのパケット３０に与えられる、パケットの順序を示すための連続番号である。また、タイミング指標付加手段５は、それぞれのパケット３０に付加したシーケンス番号３４の情報を保持する。保持されたシーケンス番号の情報は、同期の確立およびエコーキャンセルに利用されるが、これらの詳細は後述する。なお、図３（ｂ）においては、図示の都合上シーケンス番号３４をヘッダ３１の末尾のフィールドに付す態様にて示しているが、ヘッダ３１内のデータ構造はこれに限定されない。
【００６０】
シーケンス番号３４が付加されたパケット３０は、伝送パケットとして、データ送信手段６によってＭＣＵ２０へと送信される（ステップＳ８）。すなわち、連続したシーケンス番号３４を有する伝送パケットが順次送信されていることとなる。
【００６１】
ＭＣＵ２０は、端末装置１から送信された伝送パケットを、通信制御装置２０Ｃのデータ受信手段２１によって受信する（ステップＳ９）。データ受信手段２１が受信した接続チャネルの情報から、図３（ｂ）の［４］のように、ヘッダ３１にＣＳＲＣ識別子３６が記録される（ステップＳ１０）。
【００６２】
次に、パケットデータ判定手段２３において、受信した伝送パケットのデータが同期パケット３５（後述）であるか否かが判定される（ステップＳ１１）。いま、判定の対象となっているのは同期が確立した後に受信した伝送パケットデータであるので、直ちにミキシング処理に供される。
【００６３】
ミキシング処理とは、通信制御装置２０Ｃが複数の端末装置１から所定の時間内に受信したパケット３０のデータを、データミキシング装置２０Ｍが新たな１つのミキシングパケット３８にミキシングする処理である。これは、ＣＳＲＣ識別子情報４１を合成しミキシングパケット３８のヘッダ３９に付与するＣＳＲＣ識別子合成処理（ステップＳ１４）と、音声データをミキシングパケット３８のペイロード４２に合成する音声データミキシング処理（ステップＳ１５）とからなる。
【００６４】
図４は、データミキシング装置２０Ｍにおけるデータミキシングの処理フローを示す図である。まず、図３（ｂ）の［６］に示すように、ＣＳＲＣ識別子合成手段２６によって、ミキシングの対象となったそれぞれの伝送パケットの送信元の情報を示すＣＳＲＣ識別子３６から、ＣＳＲＣ識別子情報４１が合成される（ステップＳ３１）。次に、データミキシング手段２７によって、伝送パケットにおいて実質的な音声データを含むペイロード３２の内容がミキシングパケット３８のペイロード４２に合成される（ステップＳ３２、Ｓ３３）。今、ｋ個（ｋ≧３）の端末装置１が用いられ、全ての端末装置１で同期が確立されているとすると、ミキシングパケット３８は、ｋ個の端末装置１についてのＣＳＲＣ識別子情報４１と、ｋ個の端末装置１において発せられた音声をミキシングしたペイロード４２とを備えていることになる。
【００６５】
その後、ミキシングパケット３８にはタイミング指標付加手段２８によってシーケンス番号４０が付加され（ステップＳ１６、Ｓ３４）、データ送信手段２９により、ＲＴＰに従って、それぞれの端末装置１に対しマルチキャスト送信がなされる（ステップＳ１７、Ｓ３５）。
【００６６】
端末装置１は、ＭＣＵ２０からマルチキャスト送信されたミキシングパケット３８を、データ受信手段８で受信する（ステップＳ１８）。
【００６７】
図５は、ミキシングパケット３８を受信した後の端末装置１における処理フローを示す図である。ミキシングパケット３８を受信すると、まず、ミキシングパケット検査手段９によって、後述する同期フラグが端末装置１においてすでに設定されているか否かが確認される（ステップＳ１９、Ｓ４１）。今、対象となっている処理は、定常の音声データ処理、すなわち、同期が確立された後の処理であるので、ステップＳ４１はＹＥＳと判定される。すなわち、ミキシングパケット３８はそのまま維持され、データ出力処理手段１０における音声出力処理へと供される（ステップＳ５２）。
【００６８】
データ出力処理手段１０においては、ミキシングパケット３８に付加されているシーケンス番号４０に基づいて、ミキシングパケット３８から会議の参加者が発する音声が合成された音声データが復元される（ステップＳ２１）。
【００６９】
さらに、後述する同期の確立処理によって定まる、シーケンス番号４０と、端末装置１のタイミング指標付加手段５によって保持されていたシーケンス番号３４の情報との対応関係から、受信したミキシングパケット３８が、先に端末装置１から送り出された伝送パケットうちのどのパケットのデータを含んでいるのかが明らかとなるので、復元された音声データから、当該ミキシングパケット３８を受信した端末装置１の使用者である参加者Ａが発した音声データを消去するための、エコーキャンセル処理が行うことができる（ステップＳ２２）。エコーキャンセルは、データ送信時にデータバッファ７に保存した当該使用者の音声データを、データミキシング装置２０Ｍから送信され復元された音声データと逆位相で合成することで実現する。ここで、同期の確立処理が必要となってくるが、詳細は後述する。
【００７０】
エコーキャンセルされた音声データは、Ｄ／Ａ変換（ステップＳ２３）された後、出力手段１１によって、参加者Ａが聴取可能に音声出力される（ステップＳ２４）。
【００７１】
＜同期の確立＞
次に、多地点会議システム１００において、端末装置１がデータの同期を確立するための処理について説明する。
【００７２】
上述したように、端末装置１においては、ＭＣＵ２０からマルチキャスト送信される音声データを参加者Ａが聴取可能とする際に、参加者Ａが自らが発した音声のデータを消去する、エコーキャンセル処理を行う必要がある。そして、エコーキャンセル処理を効果的なものとするためには、端末装置１から音声データを送信し、ＭＣＵ２０でミキシングされて再び戻ってくるまでの遅延時間を、正確に知る必要がある。端末装置１における同期確立処理とは、定常の音声データ処理に先立って行われる、この遅延時間を得るための処理である。
【００７３】
図２において実線で示す矢印ＡＲ４が、データの同期を確立するための処理の流れを示している。また、図１において実線で示す矢印ＡＲ１は、多地点会議システム１００において同期を確立するためのデータが受け渡される様子を、図２における同期を確立するための処理の流れに対応させて示したものである。また、図３（ａ）が、同期を確立する場合の種々の処理に伴うデータ構造の変化を、模式的に示している。また図６は、同期を確立する際の、端末装置１におけるデータ送信に関する処理フローを示す図である。
【００７４】
参加者Ａが使用する端末装置１が、所定の通信網に接続され、多地点会議システムを利用するための所定のプログラムが動作し、会議への参加が可能な状態になると、入力手段２であるマイクを通じて音声入力が可能となる（ステップＳ１）。ただし、同期が確立されるまでは、後述するように、入力された音声は他の参加者には届かない。また、出力手段１１であるスピーカーからの音声出力は、データ出力処理手段１０によってミュートされる（ステップＳ２、Ｓ５１）。これにより、他の参加者の発する音声は、同期が確立するまでは参加者Ａには聞こえない。
【００７５】
入力された音声データは、定常の処理と同様に、データ入力処理手段３においてＡ／Ｄ変換され（ステップＳ３）、さらに所定のデータ長ごとのパケットに分割される（ステップＳ５）。ただし、データバッファ７への保存はなされない。
【００７６】
パケット３０が得られると、以下のように、同期を確立するために用いる同期パケット３５を生成する処理がなされる。
【００７７】
まず、図３（ａ）の［２］のように、同期パケット生成手段４が、それぞれのパケット３０において、ペイロード３２のうち先頭のＮバイト（Ｎ≧１）を、同期用情報である所定の同期識別パターンデータ３３に書き換える（ステップＳ６）。このように、本実施の形態においては、ペイロード３２の一部を書き換えることで同期パケット３５を生成する。従って、データ形式は本来の音声データと同じ形式を保っていることから、その送受信も本来の音声データと同じＲＴＰによって可能であり、特別なプロトコルを要せずに同期を確立することができる。
【００７８】
次に、タイミング指標付加手段５が、図３（ａ）の［３］のように、同期パケット３５を対象としてそのヘッダ３１にシーケンス番号３４を付加すると共に、付加したシーケンス番号３４についての情報を保持する（ステップＳ７）。
【００７９】
以上のようにしてパケット３０を書き換えた同期パケット３５にシーケンス番号を付加したものが同期確立用の伝送パケットとなる。この伝送パケットは、データ送信手段６によって、ＭＣＵ２０へと送信される（ステップＳ８、Ｓ５４）。
【００８０】
後述するように、同期が確立されたと判断されるまでは、端末装置１においては同期パケット３５の生成と送信とが繰り返されることとなる（ステップＳ５２〜Ｓ５４）。すなわち、連続したシーケンス番号３４を有する複数の同期パケット３５が伝送パケットとして、所定の個数ずつ順次送信されていることとなる。
【００８１】
ＭＣＵ２０の通信制御装置２０Ｃは、端末装置１から送信された同期パケット３５を、データ受信手段２１によって受信する（ステップＳ９）。データ受信手段２１が受信した接続チャネルの情報から、図３（ａ）の［４］のように、ヘッダ３１にＣＳＲＣ識別子３６が記録される（ステップＳ１０）。
【００８２】
次に、パケットデータ判定手段２３において、受信した伝送パケットのデータがペイロード部分に同期識別パターンデータ３３を含む同期パケット３５であることが確認される（ステップＳ１１）と、図３（ａ）の［５］のように、ペイロード廃棄手段２４において同期パケット３５のペイロード部分が廃棄される（ステップＳ１２）。これは、同期が確立されていない時点での音声データを、後段の処理でミキシングしないようにするためである。以降、このようにペイロード部分が廃棄された同期パケット３５を、ダミーパケット３７と称する。
【００８３】
ダミーパケット記憶手段２５において、ダミーパケット３７が生成されたことが記憶される（ステップＳ１３）と、ダミーパケット３７はミキシング処理へと供され、図４の処理フローに従った処理が施されることになる。
【００８４】
ミキシング処理は、上述したように、通信制御装置２０Ｃが複数の端末装置１から所定の時間内に受信した伝送パケットのデータをミキシングして、新たな１つのミキシングパケット３８を生成する処理である。ここで、ペイロードを有さないダミーパケット３７もミキシングの対象となるのは、ミキシングパケット３８のＣＳＲＣ識別子情報４１の内容によって、端末装置１は、自らが発した同期パケット３５がＭＣＵ２０に到達したか否かを判断することになるからである。そのために必要なのは、どこからダミーパケット３７が送出されたのかを表すＣＳＲＣ識別子３６の情報のみであるので、ダミーパケット３７の場合は、図３（ａ）の［６］に示すように、ＣＳＲＣ識別子合成手段２６におけるＣＳＲＣ識別子情報４１の合成の対象とはなるが（ステップＳ３１）、ペイロードにデータを含まないので、データミキシング手段２７におけるペイロードのミキシングの対象とはならない（ステップＳ３２、Ｓ３４）。今、ｋ個の端末装置１が用いられ、ある１つの端末装置１のみ同期が確立していないとすると、ミキシングパケット３８は、ｋ個の端末装置１についてのＣＳＲＣ識別子情報４１と、（ｋ−１）個の端末装置１において発せられた音声をミキシングしたペイロード４２とを備えていることになる。これにより、本来不要なダミーデータをミキシングパケット３８に含まないことから、端末装置１におけるノイズの要因となることを回避することができる。
【００８５】
得られたミキシングパケット３８に、タイミング指標付加手段２８によってシーケンス番号４０が付加され（ステップＳ１６、Ｓ３４）、データ送信手段２９により、ＲＴＰに従って、それぞれの端末装置１に対しマルチキャスト送信がなされる（ステップＳ１７、Ｓ３５）のは、上述の場合と同じである。
【００８６】
端末装置１は、ＭＣＵ２０からマルチキャスト送信されたミキシングパケット３８を、データ受信手段８で受信する（ステップＳ１８）。
【００８７】
上述したように、ミキシングパケット３８を受信すると、図５に示すように、ミキシングパケット検査手段９によって、後述する同期フラグが端末装置１においてすでに設定されているか否かがまず確認される（ステップＳ１９、Ｓ４１）。今、同期確立処理を行っている途中であるので、ステップＳ４１はＮＯと判定される。すると、引き続いて、ミキシングパケット検査手段９によって同期確立条件に適合しているか否かの判断がなされることとなる。
【００８８】
まず、受信したミキシングパケット３８のＣＳＲＣ識別子情報４１に、当該端末装置１についての情報が含まれているか否かを判別する（ステップＳ４２）。これが含まれている場合には、ミキシングパケット検査手段９に備わる図示しないパケットカウンタにおいて引き続きステップＳ４２を満たすパケットをカウントする（ステップＳ４３）。
【００８９】
所定時間内に当該端末装置１自身に係るＣＳＲＣ情報を含むミキシングパケット３８を２個以上受信した場合（ステップＳ４４でＹＥＳ）、タイミング指標である、受信したミキシングパケット３８のシーケンス番号４０の一連性を判別する（ステップＳ４５）。例えば、端末装置１から５つの同期パケット３５が連続して送信された場合に、受信したミキシングパケット３８に「１００１」、「１００２」、・・・、「１００５」なるシーケンス番号４０が付加されていた場合、これらのシーケンス番号は連続している、と判別される。仮に、「１００２」なるシーケンス番号４０が付加されていたミキシングパケット３８が受信されないなど番号に不連続がある場合や、「１００５」なるシーケンス番号４０が付加されたミキシングパケット３８が受信されないなど所定の個数に足りない場合などは、連続しているとは判別されない。シーケンス番号４０が連続していると判別された場合（ステップＳ４５でＹＥＳ）、当該端末装置１から順次送出されたそれぞれの同期パケット３５のデータが、正しくミキシングを受けてミキシングパケット３８として戻ってきているものと判断される。これにより、通信網上で消失し、欠落が生じる状態では、同期が確立されることはない。
【００９０】
次に、タイミング指標付加手段５が保持するシーケンス番号３４の情報と、データミキシング装置２０Ｍにてミキシングパケット３８に付与されたシーケンス番号４０との関連付けが行われる（ステップＳ４６）。例えば、上述の場合に、同期パケット３５に付加されていたシーケンス番号３４が「０００１」「０００２」・・・「０００５」であったとすると、両者のシーケンス番号の値には「１０００」の差があることになる。端末装置１とＭＣＵ２０とからは一定の時間間隔でシーケンス番号が付加されてパケットが送信されるので、端末装置１が送信した伝送パケットとこれに対応するデータを含むミキシングパケット３８との両者にそれぞれ付加されているシーケンス番号の差（上述の場合であれば「１０００」）は、その後も一定に保たれることとなる。すなわち、この番号差は、送信と受信との遅延時間に相当する。言い換えると、この番号差が得られたことで、同期の確立がなされたこととなる。
【００９１】
こうして、同期が確立されると、上記の遅延時間に相当する番号差を用いたエコーキャンセル処理が可能となるため、それまで音声出力のデータ出力処理手段１０においてなされていた音声出力のミュートは解除される（ステップＳ４７）。これにより、有効な音声データのみを参加者Ａが聴取可能とする、いわば頭出し検出が可能となる。
【００９２】
またこのとき、データ送出部１Ｓからの同期パケット３５の送出がストップされる（ステップＳ４８）。そして、ミキシングパケット検査手段９において同期が確立したことを示す同期フラグが設定される（ステップＳ４９）。
【００９３】
一方、当該端末装置１についての情報がＣＳＲＣ識別子情報４１に含まれているミキシングパケット３８を受信しない場合（ステップＳ４２でＮＯ）、所定時間内に２個以上受信できなかった場合（ステップＳ４４でＮＯ）、またはシーケンス番号が連続していなかった場合（ステップＳ４５でＮＯ）は、同期パケット３５の送信が続行され（ステップＳ５０）、パケットカウンタはクリアされる（ステップＳ５２）。
【００９４】
同期が確立されると、以降は、前述したような定常の音声データ処理がなされることとなる。なお、同期が確立された場合も、引き続き同期確立処理が行われる場合も、ミキシングパケット検査手段９において用いられたミキシングパケット３８は、所定の処理が終了した後は廃棄される（ステップＳ２０）。
【００９５】
以上、説明したように、本実施の形態においては、エコーキャンセルに必要なデータの同期の確立に、パケットデータの一部を書き換えた同期パケットを利用しているので、データの送受信に利用するプロトコルをそのまま用いて同期を確立することが可能である。
【００９６】
＜実施の形態２＞
実施の形態１においては、シーケンス番号の番号差を用いて遅延時間を判断していたが、通信網上の端末間で利用可能なＮＴＰ（Network Time Protocol）を利用して、直接に時刻を検出して同期を取る態様も可能である。すなわち、図１のタイミング指標付加手段５および２８がＮＴＰによる時刻情報を同期パケット３５およびミキシングパケット３８に与える態様であってもよい。
【００９７】
例えば、同期パケット３５の送出時に、タイミング指標付加手段５がＮＴＰより時刻情報を取得して、シーケンス番号３４とともにヘッダ３１に記憶させる。また、同時に端末装置１においてもこれを記憶する。ＭＣＵ２０においては、データミキシングの後、マルチキャスト送信の際に、シーケンス番号４０とともに、時刻情報をヘッダ３９に記憶する。端末装置１のミキシングパケット検査手段９は、受信したミキシングパケット３８のヘッダ３９と、送信時に記憶しておいた時刻情報を比較参照することにより、送出した時刻とミキシング後に受信した時刻の差分を取得する。これにより、同期の確立に必要な遅延時間の値を、より正確に知ることができる。本実施の形態は、データ紛失率が高い伝送系において同期を確立する際に、より有効である。
【００９８】
＜実施の形態３＞
従来の多地点会議は、会議の参加者がそれぞれに会議管理装置との接続を確立する必要があり、これがなされた後でないと、会議を開始することができなかったため、限られた会議時間をロスすることが少なくなかった。本実施の形態では、開始予定時刻になると直ちに会議を開始することが可能な、多地点会議システムについて説明する。
【００９９】
＜システムの構成概要＞
図７は、本実施の形態に係る多地点会議システム２００の構成の概要を示す図である。多地点会議システム２００は、端末装置２０１（２０１ａ、２０１ｂ、２０１ｃ、２０１ｄ）と会議管理装置２０２とが通信網ＮＷを介して接続されたものであり、遠隔地にいる複数人が会議を行うためのシステムである。
【０１００】
端末装置２０１は、会議の各参加者が音声等の送受信に使用するものであり、図７においては図示しない会議データを送受信するための会議データ通信手段を備えており、例えば第１の実施の形態にて示した端末装置１を用いることができる。また、それぞれの端末装置２０１には、互いを識別するための端末名が付与されている。図７においては、それぞれの端末装置２０１の使用者の名前が端末名として付与されている場合を例示的に示している。すなわち、端末装置２０１ａには「ＴＡＮＡＫＡ」、端末装置２０１ｂには「ＳＡＴＯ」、端末装置２０１ｃには「ＳＵＺＵＫＩ」、端末装置２０１ｄには「ＮＡＫＡＭＵＲＡ」という端末名が、それぞれに付与されている。なお、端末名に代わって、ＩＰアドレスなど、それぞれの端末装置２０１に固有の情報などによって識別する態様であってもよい。
【０１０１】
会議管理装置２０２は、所定のプログラムが実行されることにより、コンピュータにおいてその機能が実現するものである。会議管理装置２０２は、ＭＣＵ２０３と入力操作手段２１１と、表示手段２１２と、制御手段２１３と、記憶手段２１４とを主として備えている。ただし、多地点会議システム２００において使用される端末装置２０１は４つに限定されず、一般には複数（多地点会議機能の通常の利用対象としては３以上）の端末装置２０１が使用される。
【０１０２】
入力操作手段２１１は、会議管理装置２０２に対し、命令の実行等の指示を行うためのものであり、例えばマウスやキーボードなどである。表示手段２１２は、会議管理装置２０２の動作状況や、会議の予約状況などを可視的に表示するためのものであり、例えばディスプレイである。制御手段２１３とは、会議管理装置を実現するプログラムを動作させるＣＰＵである。記憶手段２１４とは、例えば会議管理装置を実現するプログラムを記憶する記憶媒体やメモリなどである。
【０１０３】
ＭＣＵ２０３は、多地点会議を実現するための種々の処理を実行するためのものである。なお、図７においては、図示の都合により分けて記載しているが、ＭＣＵ２０３の一部の機能は、制御手段２１３および記憶手段２１４により実現されている。ＭＣＵ２０３は、会議情報管理手段２０４と、通信制御手段２０５と、データミキシング手段２０８とを主として備えている。
【０１０４】
会議情報管理手段２０４は、例えば会議の参加予定者情報など、会議の開催に必要な情報を含む会議開催データファイルＤＦ１を作成し、保持するための手段である。
【０１０５】
通信制御手段２０５は、通信網ＮＷを介した、端末装置２０１との間のデータの送受信を制御するためのものである。通信のためのプロトコルとしては、例えばＲＴＰが用いられる。通信制御手段２０５は、複数の接続チャネルを備えており、それぞれの端末装置２０１から送信されたデータは、どの接続チャネルによって受信されるのかにより識別される。また、通信制御手段２０５は、データミキシング手段２０８においてミキシングされたデータを、会議の参加者が使用している端末装置２０１へとマルチキャスト送信する。
【０１０６】
また、通信制御手段２０５は、会議開催制御手段２０６と、帯域制御手段２０７とを備えている。
【０１０７】
会議開催制御手段２０６は、会議の開催時に、会議データＤｉに基づいて参加者の使用する端末装置２０１へと開催を発呼するために備わる。ここで、開催を発呼するとは、具体的には、それぞれの端末装置２０１に対し、会議データ通信手段を能動化させるための能動化指令信号を発信するという処理のことをいう。すなわち、会議開催制御手段２０６は、能動化指令手段として機能する。また、会議開催制御手段２０６は、会議ごとに使用するスレッドを生成する。複数の会議が並行して行われる場合、通信制御手段２０５はそれぞれの会議についての処理は、各スレッドにて並列に行われることとなる。
【０１０８】
帯域制御手段２０７は、会議の開催に際して、参加する端末装置２０１の数や、取り扱うデータの種類（音声のみ、あるいは映像を含む、など）に応じて、使用する帯域を確保し、調整するためのものである。
【０１０９】
データミキシング手段２０８は、多地点会議の開催中に、複数の端末装置２０１から送信され、通信制御手段２０５において受信される、音声データなどのパケットデータを、一定時間ごとにミキシングして、１つのミキシングパケットとするためのものである。生成されたミキシングパケットは、通信制御手段２０５から、端末装置２０１へとマルチキャスト送信される。
【０１１０】
＜会議の開催処理＞
次に、会議の開催に係る処理について説明する。図８は、本実施の形態に係る会議の開催処理の流れを示す図である。
【０１１１】
まず、会議の開催に先立って、会議開催データファイルＤＦ１が作成される（ステップＳ６１）。図９は、本実施の形態に係る会議開催データファイルＤＦ１を例示的に示す図である。会議開催データファイルＤＦ１には、開催を予定している会議についての情報が、会議データＤｉとして登録される（ステップＳ６２）。図９には、３つの会議データＤ１〜Ｄ３が登録された場合を示している。それぞれの会議データＤｉは、開催を予定する多地点会議を表す会議名レコードＲ１と、その会議への参加予定者の使用する端末装置２０１の装置名がカンマで区切られて列挙された参加者レコードＲ２とから構成されている。会議データＤｉの登録・修正などは、会議情報管理手段２０４によって、入力操作手段２１１、あるいは端末装置２０１のいずれからも、会議の開始時刻までの任意の時点で可能とされている。会議情報管理手段２０４は、例えば端末装置２０１からの登録処理要求に従って、端末装置２０１の図示しない表示部に会議登録処理メニューを表示させる。当該メニューに従った入力がなされることで、会議データＤｉの登録は実行される。
【０１１２】
多地点会議を開始するときには、会議の主催者が、入力操作手段２１１、あるいは端末装置２０１の図示しない入力操作手段によって所定の操作を行うことにより、会議開催データファイルＤＦ１に会議データＤｉとして登録されている会議のなかから開催を所望する会議を選択して、会議開始命令を出す（ステップＳ６３）。会議開催制御手段２０６は、会議開始命令を受けて、選択された会議データＤｉの参加者レコードＲ２に列挙されている端末装置名を有する全ての端末装置２０１に対して、会議開始を発呼する（ステップＳ６４）。
【０１１３】
以上、説明したように、本実施の形態においては、ＭＣＵ２０３が通信の制御に加えて、会議の開催に係る処理を担うので、両者を一体のものとして取り扱うことができ、効率的な処理が可能となる。また、ＭＣＵ２０３から端末装置２０１へと会議の開催を発呼するため、それぞれの端末装置２０１は、ほぼ同時に会議開始が可能な状態に達することになる。これにより、開始に手間取ることなく、多地点会議を行うことができ、会議の参加者においては、会議への参加に際して煩雑な接続手続きを行うことが不要となる。さらに、実施の形態１において説明したのと同様に、多地点会議を開始するときの参加者情報をマルチキャストで送信し、受信した端末装置は自分自身の名前があった場合に接続を開始することもできる。
【０１１４】
＜実施の形態４＞
実施の形態３においては、会議の開始は、主催者の会議開始命令に基づくものであったが、ＭＣＵ２０３において会議の予約管理および時間管理を行い、自動的に開始および終了ができ、さらには、開催中の会議の延長が行える態様であってもよい。本実施の形態においては、こうした態様について説明する。
【０１１５】
図１０は、本実施の形態に係る多地点会議システム３００の構成の概要を示す図である。多地点会議システム３００の構成は、ほぼ、実施の形態３における多地点会議システム２００と同様である。よって、図７において示した多地点会議システム２００の構成要素と同一の構成要素については、同一の符号を付してその説明を省略する。
【０１１６】
多地点会議システム３００においては、ＭＣＵ２０３に、会議予定変更手段３０１と、タイマ３０２とがさらに備わっている。会議予定変更手段３０１は、開催中の会議の延長を行うためのものである。タイマ３０２は、会議の時間管理のために必要な実時間情報を取得するために備わるものである。
【０１１７】
次に、会議の開催に係る処理について説明する。図１１は、本実施の形態に係る会議の開催処理の流れを示す図である。
【０１１８】
まず、会議の開催に先立って、会議開催データファイルＤＦ２が作成される（ステップＳ７１）。図１２は、本実施の形態に係る会議開催データファイルＤＦ２を例示的に示す図である。会議開催データファイルＤＦ２には、開催を予定している会議についての情報が、会議データＤｉとして登録される（ステップＳ７２）。図１２には、３つの会議データＤ４〜Ｄ６が登録された場合を示している。それぞれの会議データＤｉは、開催を予定する多地点会議を表す会議名レコードＲ１と、その会議への参加予定者の使用する端末装置２０１の装置名がカンマで区切られて列挙された参加者レコードＲ２と、会議を開催する予定の日を表す開催日レコードＲ３と、開始予定時刻と終了予定時刻とを表す時間レコードＲ４とから構成されている。すなわち、会議データＤｉの登録は、会議の開催を予約していることに相当する。会議データＤｉの登録・修正などは、会議情報管理手段２０４によって、入力操作手段２１１、あるいは端末装置２０１のいずれからも可能とされている。会議データＤｉの登録については、実施の形態３と同様に行われる。
【０１１９】
会議開催制御手段２０６は、会議開催データファイルＤＦ２に登録されたそれぞれの会議データＤｉの会議開始予定時刻と、タイマ３０２により与えられる時刻情報とを絶えず照合して、登録されている会議データＤｉのいずれかの会議開始予定時刻が到来したか否かを判定する（ステップＳ７３）。会議開催制御手段２０６は、いずれかの会議データＤｉの会議開始時刻に達すると、該当する会議データＤｉの参加者レコードＲ２に列挙されている端末装置名を有する全ての端末装置２０１に対して、会議開始を発呼する（ステップＳ７４）。
【０１２０】
そして、会議が開始されると、今度は、現在開催している会議の会議開催データファイルＤＦ２に登録されているその会議の会議終了予定時刻と、タイマ３０２により与えられる時刻情報とを絶えず照合して、会議終了予定時刻が到来したか否かを判断する（ステップＳ７５）。
【０１２１】
会議終了予定時刻に達すると、会議開催制御手段２０６は、会議終了処理信号を送信してそれぞれの端末装置２０１との接続を切断すると同時に、起動していたスレッドを終了する（ステップＳ７８）。さらに会議情報管理手段２０４に会議終了情報を送信する。会議情報管理手段２０４は、会議終了情報を受け取ると、該当する会議についての会議データＤｉを消去する。
【０１２２】
なお、会議の開催されている間も、他の会議データＤｉに登録されている会議開始時刻に達するか否かは常に判断されており、いずれかの会議データＤｉの会議開始時刻に達すると、並行して会議が開催される。
【０１２３】
なお、直ちに会議を行いたい場合、帯域に空きがあれば、予約をすることなく即座に会議を開始できる態様であってもよい。
【０１２４】
また、会議の開催中に、終了予定を変更する場合は、会議参加者のうちの任意のメンバーが自らの使用している端末装置２０１を通じて、あるいは会議管理装置２０２の入力操作手段２１１を通じて、所定の操作を行うことにより会議終了時刻の変更処理が可能である（ステップＳ７６、Ｓ７７）。これを実現するのが、会議予定変更手段３０１である。会議予定変更手段３０１は、例えば端末装置２０１からの変更処理要求に従って、端末装置２０１の図示しない表示部に時刻変更処理メニューを表示させる。端末装置２０１の使用者が所定の操作を行うことで、会議情報管理手段２０４に保持されている会議開催データファイルＤＦ２のなかの、現在開催中の会議に係る会議データＤｉの終了時刻が変更される。これらの処理がなされた後、会議開催制御手段２０６は、変更された終了時刻に基づいて、会議を終了させるか否かを判断することとなる。
【０１２５】
このように、本実施の形態においては、ＭＣＵに対しあらかじめ会議の開催を予約することができる。また、ＭＣＵは、会議開催データに含まれる時間情報に基づくタイミングで、それぞれの会議の開始、および終了を自動的に行うことができるので、並行して複数の会議を開催するなど会議の予定が複雑になる場合であっても、予定の管理が容易になる。さらに、実施の形態１において説明したのと同様に、多地点会議を開始するときの参加者情報をマルチキャストで送信し、受信した端末装置は自分自身の名前があった場合に接続を開始することもできる。
【０１２６】
＜実施の形態５＞
実施の形態４においては、会議の開始・終了時刻を登録し、これを管理することにより、会議の予約開始が可能であった。一方、通信網を用いて多地点会議を行う場合、一般には使用できる帯域が制限されているため、一度に並行して開催できる会議の数には限りがある。よって、多くの会議が並行して開催されるような場合は、会議の予約に際して、帯域に空きがあるか否かを把握する必要がある。本実施の形態においては、実施の形態４において示した多地点会議システム３００において、これを実現する態様について説明する。
【０１２７】
本実施の形態においては、会議情報管理手段２０４が、会議データＤｉの登録の際に、それぞれの会議データＤｉに対して予約帯域幅を設定する。予約帯域幅とは、会議の参加人数や、やりとりされるデータの種類（音声のみ、あるいは映像付き、など）に応じてあらかじめ見積られる、それぞれの会議に占有される帯域幅である。参加者１人あたり数十ｋＢずつの帯域幅を確保する、などの態様がその一例である。会議における通信の品質を保つ必要から、参加人数が多いほど、あるいは音声のみよりも映像を併用した方が、占有される帯域幅が大きくなるので、予約帯域幅も大きくなる。また、通信の安定性を確保するため、実際に必要な最小限度の帯域幅よりは、多少余裕を持たせて設定されるのが望ましい。設定された予約帯域幅は、会議データＤｉの一項目として付加され記憶される。
【０１２８】
新たな会議の予約の要求に際しては、会議情報管理手段２０４が、他の会議予定の登録状況に基づき、予約者の開催希望日時における通信帯域の利用状況を判定する。すなわち、会議データＤｉに付加された予約帯域幅のデータに基づいて、使用可能と判断されている帯域幅が、新たに予約しようとする会議で使用するために必要な帯域幅を超えるか否かを判定して、その予約の可否を判断する。
【０１２９】
図１３は、これを説明するための、ある日の会議予約の登録状況を例示的に示す図である。図１３においては、横軸が時間軸８１、横軸は使用可能な帯域幅８２をパーセンテージで示している。図１３（ａ）は、会議Ａ、Ｂ、Ｃ、およびＤの４つの会議が予約する会議時間と帯域幅とが、それぞれ長方形８３、８４、８５、および８６にて示されている。例えば、会議Ａは、使用可能な帯域幅のうち４０％を予約帯域幅として確保し、４時間の実施が予定されている会議である。また、図１３（ｂ）は、（ａ）で示した登録状況を、予約帯域幅、および帯域の空きがわかりやすくなるように書き換えたものである。
【０１３０】
図１３（ｂ）に示す場合、１０時から１２時までは３つの会議で帯域を１００％利用するので、この時間帯にはこれ以上、会議の予約を行うことはできない。すなわち、この時間帯に会議の予約の要求があったとしても、使用できる帯域に余裕がないとして、会議情報管理手段２０４はこれを拒否する。以降の時間帯については、１２時から１４時の間は２０％の空きがあり、１４時から１６時までは６０％の空きがあり、１６時から１８時は８０％の空きがある。さらに、１８時以降は１００％の空きがある。これらの時間帯であれば、開催を設定しようとする会議の予約帯域幅が、利用可能な帯域幅を超えない範囲で、会議の予約を登録することが可能である。
【０１３１】
なお、すでに予約済の会議について、開催までにその開催の時間帯を変更したい場合（開催時刻の変更、終了時刻時刻の変更）も、同様に予約帯域幅からその可否を判定できる態様であってもよい。変更が認容される場合、会議データＤｉの内容は書き換えられる。
【０１３２】
以上のように、予定登録されている会議のそれぞれの必要帯域幅の合計と、利用可能な帯域幅の最大値との差が、開催を予約をしようとする会議の必要帯域幅を収容可能であるか否かに応じて、予約の可否を判断することによって、通信の品質を確保しつつ、帯域幅を有効活用した会議の予約を行うことができる。
【０１３３】
＜実施の形態６＞
実施の形態５は、予約帯域幅に基づいて、会議の予約の要求の可否を判断する態様であったが、実際に開催されている会議の終了時刻を変更する際にも、予約帯域幅を考慮してその可否を判断する態様であってもよい。以下、これを説明する。
【０１３４】
実施の形態４にて説明したように、会議予定変更手段３０１は、端末装置２０１の図示しない表示部に時刻変更処理メニューを表示させ、参加者はこれに基づいて現在開催中の会議に係る会議データＤｉの終了時刻を変更するが、本実施の形態においては、この変更処理に際して、会議データＤｉに付加された予約帯域幅の情報を参照して、その変更の可否を判断する。
【０１３５】
例えば、図１３の１１時の時点で考えると、この時点では会議Ａ、会議Ｂ、および会議Ｄの３つの会議が開催中である。このとき、会議Ａのいずれかの参加者が、当初の終了予定時刻である１４時以降に会議を延長しようとする場合を考えると、当該参加者は、端末装置２０１において時刻変更処理メニューに従ってその意図する変更内容を入力すると、会議予定変更手段３０１がその変更しようとする時刻の予約帯域幅の情報を取得し、その可否を判断することとなる。いまの場合、会議Ａは４０％の予約帯域幅を有しているが、１１時の時点において、１４時以降には４０％以上の空きの帯域が存在するので、会議予定変更手段３０１が会議Ａの終了時刻の繰り下げは可能と判断し、これを参加者に通知するとともに、会議情報管理手段２０４は、会議データＤｉの終了時刻の情報を書き換える。
【０１３６】
一方、会議Ｂは、４０％の帯域幅を有し１２時に終了予定であるが、１１時の時点では、１２時以降に空きの帯域は２０％しかないので、会議Ｂの参加者が時刻変更処理メニューを利用して会議の終了時刻を繰り下げようとする場合には、会議予定変更手段３０１はこれを不可と判断し、参加者に通知することとなる。ただし、その後、同時に開催されている会議Ｄが１２時までに終了する、あるいは、１２時から開催予定の会議Ｃが予定変更により繰り下げあるいは中止される、などの状況が生じれば、１２時以降に４０％の帯域の空きが生じるので、会議Ｂの延長は、可能となる。
【０１３７】
以上のような態様をとることによって、通信の品質を確保しつつ、帯域幅を有効活用した会議の予約および開催中の会議の予定変更を行うことができる。
【０１３８】
＜変形例＞
実施の形態１においては、音声データを例に同期の確立を図る態様について説明した。映像データに対しても、同期の確立を行う態様であってもよい。音声データの場合、その目的は、エコーキャンセルを精度よく行うためであった。一方、映像データの場合は、例えば、会議の参加者が同一の映像を見ながら会話を行う場合など、その映像データが到達する時間に遅延が生じる際に、その遅延時間を把握し画面表示として出力するなどの態様が好ましい場合がある。これにより、当該遅延時間を考慮した間合いを取りながら、会議を進行することができるからである。従って、図２において入出力の対象を音声データから映像データに置き換え、エコーキャンセルの処理を無視することにより、映像データの場合も、音声データと同様に同期の確立処理を行うことができる。
【０１３９】
実施の形態５および６は、予約帯域幅を設定する態様であったが、予約帯域幅は、会議の開催に必要な最小限度の帯域幅よりも余裕を持たせて設定することが可能であるため、予約帯域幅の総和から判断するとさらに新たな会議を行うことは認められない場合でも、帯域制御手段２０７が実際に使用されている帯域幅の情報をリアルタイムに会議情報管理手段２０４に与えることで、新たな会議の設定が可能となる対応であってもよい。
【０１４０】
実施の形態１および２に示した、同期の確立のためになされるデータ処理の方法が適用される対象は、多地点会議システムに限定されない。ＲＴＰを利用する通信システムであれば、他のシステムであっても、同様の処理態様にて同期の確立が可能である。
【０１４１】
【発明の効果】
以上、説明したように、請求項１の発明によれば、最適な伝送状態を実現できる。例えば、多地点会議の参加者が使用する端末装置におけるデータの遅延時間を知るために必要な、同期の確立を行うことができる。また、同期パケットデータを、通常の会議データと同一のプロトコルを利用して送信できるので、同期の確立のために新たにプロトコルを具備する必要がなく、また、データは書き換えられるのみで新たに付加されることがないので、パケットデータのデータ構造を拡張する必要もない。さらには、不要なペイロード部分のデータをミキシングすることがないので、ミキシングに伴うノイズを発生させることがなく、トラフィックの負荷の低減もできる。また、音声データについて同期が確立されるので、エコーキャンセル処理に供することが可能となり、会議時に聴取する音声を聞き取りやすくすることができる。
【０１４２】
請求項２の発明によれば、一定の時間間隔で送出される同期パケットデータの個数に対応した個数のミキシングパケットデータの受信することで、同期の確立が判断できる。
【０１４３】
請求項３の発明によれば、会議への参加に先立って、同期の確立を優先的にかつ速やかに行うことができる。
請求項４の発明によれば、第１伝送パケットデータを受信した接続チャネルを特定すれば、送信元の端末装置を特定することができるので、端末装置から第１伝送パケットデータを送出するにあたって該端末装置を識別するための情報を該第一伝送パケットデータに記述する必要がない。
【０１４４】
請求項５の発明によれば、データミキシング処理装置における、パケットデータの識別、到達の確認、あるいは欠落の有無の確認が容易になる。
【０１４７】
請求項６の発明によれば、同期の確立により得られた遅延時間に基づいてエコーキャンセルが行えるので、聞き取りやすい音声データを提供することができる。
【０１４８】
請求項７の発明によれば、最適な伝送状態を実現できる。例えば、多地点会議の参加者が使用する端末装置におけるデータの遅延時間を知るために必要な、同期の確立を行うことができる。また、同期パケットデータを、通常の会議データと同一のプロトコルを利用して送信できるので、同期の確立のために新たにプロトコルを具備する必要がなく、また、データは書き換えられるのみで新たに付加されることがないので、パケットデータのデータ構造を拡張する必要もない。また、音声データについて同期が確立されるので、エコーキャンセル処理に供することが可能となり、会議時に聴取する音声を聞き取りやすくすることができる。
【０１５２】
請求項８の発明によれば、同期の確立により得られた遅延時間に基づいてエコーキャンセルが行えるので、聞き取りやすい音声データを提供することができる。
【０１５３】
請求項９の発明によれば、最適な伝送状態を実現できる。例えば、同一のプロトコルにより送信されてきた通常の会議データと同期パケットデータとを判別することができ、さらに到達した同期パケットに関する情報をミキシングパケットに付与することができる。また、不要なペイロードデータをミキシングすることがないので、ミキシングに伴うノイズを発生させることがなく、トラフィックの負荷の低減もできる。
【図面の簡単な説明】
【図１】 この発明の実施の形態１に係る多地点会議システム１００の構成図である。
【図２】 この発明の実施の形態１に係る多地点会議システム１００における処理の流れを示す図である。
【図３】 この発明の実施の形態１に係る多地点会議システム１００におけるデータ構造の変化を示す図である。
【図４】 この発明の実施の形態１に係るデータミキシング装置２０Ｍにおけるミキシング処理の流れを示す図である。
【図５】 この発明の実施の形態１に係る端末装置１におけるミキシングデータ受信後の処理の流れを示す図である。
【図６】 この発明の実施の形態１に係る端末装置１における同期確立の際の処理の流れを示す図である。
【図７】 この発明の実施の形態３に係る多地点会議システム２００の構成の概要を示す図である。
【図８】 この発明の実施の形態３に係る会議の開催処理の流れを示す図である。
【図９】 この発明の実施の形態３に係る会議開催データファイルＤＦ１を例示的に示す図である。
【図１０】 この発明の実施の形態４に係る多地点会議システム３００の構成の概要を示す図である。
【図１１】 この発明の実施の形態４に係る会議の開催処理の流れを示す図である。
【図１２】 この発明の実施の形態４に係る会議開催データファイルＤＦ２を例示的に示す図である。
【図１３】 この発明の実施の形態５に係るある日の会議予約の登録状況を例示的に示す図である。
【図１４】 従来の３者通話の方法を示す図である。
【符号の説明】
１，２０１ 端末装置、１Ｒ データ受信部、１Ｓ データ送信部、２ 入力手段、３ データ入力処理手段、４ 同期パケット生成手段、５ タイミング指標付加手段、６ データ送信手段、７ データバッファ、８ データ受信手段、９ ミキシングパケット検査手段、１０ データ出力処理手段、１１ 出力手段、２０，２０３ ＭＣＵ、２０Ｃ 通信制御装置、２０Ｍ データミキシング装置、２１ データ受信手段、２２ 識別子付加手段、２３ パケットデータ判定手段、２４ ペイロード廃棄手段、２５ ダミーパケット記憶手段、２６ 識別子合成手段、２７ データミキシング手段、２８ タイミング指標付加手段、２９ データ送信手段、３０ パケット、３１，３９ ヘッダ、３２，４２ ペイロード、３３ 同期識別パターンデータ、３４，４０ シーケンス番号、３５ 同期パケット、３６ 識別子、３７ ダミーパケット、３８ ミキシングパケット、４１ 識別子情報、８１ 時間軸、８２ 帯域幅、１００，２００，３００多地点会議システム、２０２ 会議管理装置、２０４ 会議情報管理手段、２０５ 通信制御手段、２０６ 会議開催制御手段、２０７ 帯域制御手段、２０８ データミキシング手段、２１１ 入力操作手段、２１２ 表示手段、２１３制御手段、２１４ 記憶手段、３０１ 会議予定変更手段、３０２ タイマ、Ｄｉ 会議データ、ＤＦ１，ＤＦ２ 会議開催データファイル、ＮＷ 通信網、Ｒ１ 会議名レコード、Ｒ２ 参加者レコード、Ｒ３ 開催日レコード、Ｒ４ 時間レコード。
Claims (9)
- 複数の端末装置からなる端末装置群と、前記端末装置群とネットワークを介して結合されるデータミキシング処理装置と、を備える多地点会議システムであって、
前記複数の端末装置のそれぞれがデータ送信装置とデータ受信装置とを備え、
a)前記データ送信装置は、
a-1)所定の入力手段によって入力された音声データである入力データから原パケットデータを生成するデータ入力処理手段と、
a-2)所定の個数の前記原パケットデータのペイロードの一部を同期用情報に書き換えて当該個数の同期パケットデータを生成する同期パケット生成手段と、
a-3)当該端末装置における送受信の同期が確立されるまでは前記同期パケットデータを対象パケットデータとし、前記送受信の同期が確立した後は前記原パケットデータを対象パケットデータとして、前記対象パケットデータを当該データ送信装置から送信するタイミングを表現した第１のタイミング指標を付加することにより、第１伝送パケットデータを生成する第１タイミング指標付加手段と、
a-4)前記第１タイミング指標が付加された前記第１伝送パケットデータを一定の時間間隔で送出する第１送出手段と、
を有してなり、
b)前記データミキシング処理装置は、
b-1)前記各端末装置から送出される前記第１伝送パケットデータを受信し、そのヘッダ部にその送出元である端末装置を示す識別子を付加する識別子付加手段と、
b-2)受信した前記第１伝送パケットデータが前記同期パケットデータであるか否かを判定する判定手段と、
b-3)前記同期パケットデータであると判定された前記第１伝送パケットデータのペイロード部を廃棄し、残りをダミーパケットデータとして出力する廃棄手段と、
b-4)前記ダミーパケットデータと、前記同期パケットデータでないと判定された前記第１伝送パケットデータとをミキシング対象データとし、前記ミキシング対象データを用いてミキシングパケットデータを生成するミキシング処理を行うミキシング処理手段と、
b-5)前記ミキシング処理手段から出力される前記ミキシングパケットデータに、前記ミキシングパケットデータを当該データミキシング処理装置から送出するタイミングを表現する第２のタイミング指標を付加する第２タイミング指標付加手段と、
b-6)前記第２タイミング指標付加手段から出力される前記ミキシングパケットデータを一定の時間間隔で前記端末装置群を構成する全ての端末装置に送出する第２送出手段と、
を有してなり、
c)前記データ受信装置は、
c-1)前記データミキシング処理装置から送出される前記ミキシングパケットデータを受信し、前記ミキシングパケットデータに基づいて当該端末装置における送受信の同期を確立する同期確立手段と、
c-2)前記同期が確立されるまでは受信した前記ミキシングパケットデータを廃棄すると共に、前記同期が確立された以降に受信した前記ミキシングパケットデータを維持する検査手段と、
c-3)前記検査手段に維持された前記ミキシングパケットデータから、前記複数の端末装置において入力された音声データを復元する復元手段と、
を有してなり、
前記ミキシング処理は、前記ミキシング対象データのそれぞれのヘッダ部に付加されてなる前記識別子の情報を合成することによる識別子情報の生成と、前記同期パケットデータでないと判定された前記第１伝送パケットデータのペイロード部の合成とを含む処理であり、
前記同期確立手段は、順次に受信する複数の前記ミキシングパケットデータに当該データ受信装置を含む当該端末装置を特定する情報が前記識別子情報に含まれてなり、かつ、前記複数のミキシングパケットデータのそれぞれに付加されてなる前記第２タイミング指標に所定の一連性があるか否かを判断し、前記一連性がある場合に、前記第１タイミング指標と前記第２タイミング指標を関連付けることによって前記送受信の同期の確立を実現する、
ことを特徴とする多地点会議システム。 - 請求項１に記載の多地点会議システムであって、
前記同期確立手段が前記所定の一連性の判断を行う場合に、判断対象である前記第２タイミング指標の個数と当該端末装置より送出された前記同期パケットデータの前記所定の個数の一致の有無を判断の対象とすることを特徴とする多地点会議システム。 - 請求項１または請求項２に記載の多地点会議システムであって、
所定時間の間に前記送受信の同期が確立できない場合は、前記同期パケット生成手段における前記同期パケットデータの生成を繰り返すことを特徴とする多地点会議システム。 - 請求項１ないし請求項３のいずれかに記載の多地点会議システムであって、
前記識別子付加手段が、送出元である前記各端末装置ごとに異なる接続チャネルで前記第１伝送パケットデータを受信するように構成されてなり、前記第１伝送パケットデータを受信した前記接続チャネルを特定する情報に基づいて前記識別子を付加することを特徴とする多地点会議システム。 - 請求項１ないし請求項４のいずれかに記載の多地点会議システムであって、
前記第１タイミング指標が、前記第１伝送パケットデータのそれぞれに固有に与えられる第１シーケンス番号であり、前記第２タイミング指標が、前記ミキシングパケットデータのそれぞれに固有に与えられる第２シーケンス番号であることを特徴とする多地点会議システム。 - 請求項１ないし請求項５のいずれかに記載の多地点会議システムであって、
前記検査手段が、前記第１タイミング指標と前記第２タイミング指標とに基づいて前記送受信の遅延時間を特定する手段を含み、
前記データ受信装置が、前記遅延時間の情報に基づいて、当該端末装置から前記データミキシング処理装置に送信した前記入力データに基づく前記第１伝送パケットデータを、復元された前記音声データから除去するエコーキャンセル手段をさらに備える、
ことを特徴とする多地点会議システム。 - 複数の端末装置からなる端末装置群と、前記端末装置群とネットワークを介して結合されるデータミキシング処理装置と、を備える多地点会議システムを構成する端末装置であって、
データ送信装置とデータ受信装置とを備え、
a) 前記データ送信装置は、
a-1) 所定の入力手段によって入力された音声データである入力データから原パケットデータを生成するデータ入力処理手段と、
a-2) 所定の個数の前記原パケットデータのペイロードの一部を同期用情報に書き換えて当該個数の同期パケットデータを生成する同期パケット生成手段と、
a-3) 当該端末装置における送受信の同期が確立されるまでは前記同期パケットデータを対象パケットデータとし、前記送受信の同期が確立した後は前記原パケットデータを対象パケットデータとして、前記対象パケットデータを当該データ送信装置から送信するタイミングを表現した第１のタイミング指標を付加することにより、第１伝送パケットデー タを生成する第１タイミング指標付加手段と、
a-4) 前記第１タイミング指標が付加された前記第１伝送パケットデータを一定の時間間隔で送出する第１送出手段と、
を有してなり、
b) 前記データ受信装置は、
b-1) 前記データミキシング処理装置においてミキシング処理され第２タイミング指標が付加されたうえで前記データミキシング処理装置から一定の時間間隔で送出されるミキシングパケットデータを受信し、前記ミキシングパケットデータに基づいて当該端末装置における送受信の同期を確立する同期確立手段と、
b-2) 前記同期が確立されるまでは受信した前記ミキシングパケットデータを廃棄すると共に、前記同期が確立された以降に受信した前記ミキシングパケットデータを維持する検査手段と、
b-3) 前記検査手段に維持された前記ミキシングパケットデータから、前記複数の端末装置において入力された音声データを復元する復元手段と、
を有してなり、
前記ミキシング処理は、同期パケットデータである前記第１伝送パケットデータのペイロード部を廃棄した残りであるダミーパケットデータと、前記同期パケットデータでない前記第１伝送パケットデータとをミキシング対象データとする、前記ミキシング対象データのそれぞれのヘッダ部に付加されてなる前記複数の端末装置のそれぞれを識別する識別子の情報を合成することによる識別子情報の生成と、前記同期パケットデータでない前記第１伝送パケットデータのペイロード部の合成とを含む処理であり、
前記同期確立手段は、順次に受信する複数の前記ミキシングパケットデータに当該データ受信装置を含む当該端末装置を特定する情報が前記識別子情報に含まれてなり、かつ、前記複数のミキシングパケットデータのそれぞれに付加されてなる前記第２タイミング指標に所定の一連性があるか否かを判断し、前記一連性がある場合に、前記第１タイミング指標と前記第２タイミング指標を関連付けることによって前記送受信の同期の確立を実現する、
ことを特徴とする多地点会議システムの端末装置。 - 請求項７に記載の多地点会議システムの端末装置であって、
前記検査手段が、前記第１タイミング指標と前記第２タイミング指標とに基づいて前記送受信の遅延時間を特定する手段を含み、
前記データ受信装置が、前記遅延時間の情報に基づいて、当該端末装置から前記データミキシング処理装置に送信した前記入力データに基づく前記第１伝送パケットデータを、復元された前記音声データから除去するエコーキャンセル手段をさらに備える、
ことを特徴とする多地点会議システムの端末装置。 - 複数の端末装置からなる端末装置群と、前記端末装置群とネットワークを介して結合されるデータミキシング処理装置と、を備える多地点会議システムを構成するデータミキシング処理装置であって、
第１のタイミング指標を付加したうえで一定の時間間隔で前記各端末装置から送出される第１伝送パケットデータを受信し、そのヘッダ部にその送出元である端末装置を示す識別子を付加する識別子付加手段と、
受信した前記第１伝送パケットデータが、前記各端末装置において所定の入力手段によって入力された入力データから生成された原パケットデータか、前記原パケットデータのペイロードの一部を同期用情報に書き換えて生成された同期パケットデータであるか否かを判定する判定手段と、
前記同期パケットデータであると判定された前記第１伝送パケットデータのペイロード部を廃棄し、残りをダミーパケットデータとして出力する廃棄手段と、
前記ダミーパケットデータと、前記同期パケットデータでないと判定された前記第１ 伝送パケットデータとをミキシング対象データとし、前記ミキシング対象データを用いてミキシングパケットデータを生成するミキシング処理を行うミキシング処理手段と、
前記ミキシング処理手段から出力される前記ミキシングパケットデータに、前記ミキシングパケットデータを当該データミキシング処理装置から送出するタイミングを表現する第２のタイミング指標を付加する第２タイミング指標付加手段と、
前記第２タイミング指標付加手段から出力される前記ミキシングパケットデータを一定の時間間隔で前記端末装置群を構成する全ての端末装置に送出する第２送出手段と、
を有してなり、
前記ミキシング処理は、前記ミキシング対象データのそれぞれのヘッダ部に付加されてなる前記識別子の情報を合成することによる識別子情報の生成と、前記同期パケットデータでないと判定された前記第１伝送パケットデータのペイロード部の合成とを含む処理である、
ことを特徴とする多地点会議システムのデータミキシング処理装置。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002136913A JP3973966B2 (ja) | 2002-05-13 | 2002-05-13 | 多地点会議システム、多地点会議システムの端末装置、および多地点会議システムのデータミキシング処理装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002136913A JP3973966B2 (ja) | 2002-05-13 | 2002-05-13 | 多地点会議システム、多地点会議システムの端末装置、および多地点会議システムのデータミキシング処理装置 |
Publications (3)
| Publication Number | Publication Date |
|---|---|
| JP2003333560A JP2003333560A (ja) | 2003-11-21 |
| JP2003333560A5 JP2003333560A5 (ja) | 2004-12-24 |
| JP3973966B2 true JP3973966B2 (ja) | 2007-09-12 |
Family
ID=29698817
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002136913A Expired - Fee Related JP3973966B2 (ja) | 2002-05-13 | 2002-05-13 | 多地点会議システム、多地点会議システムの端末装置、および多地点会議システムのデータミキシング処理装置 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3973966B2 (ja) |
Families Citing this family (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| NO322875B1 (no) * | 2004-04-23 | 2006-12-18 | Tandberg Telecom As | System og fremgangsmate for a inkludere deltakere i en konferansesamtale |
| JP5242927B2 (ja) * | 2007-03-19 | 2013-07-24 | Ｎｅｃパーソナルコンピュータ株式会社 | コンテンツ配信装置 |
| EP2597850A1 (en) * | 2011-11-24 | 2013-05-29 | Alcatel Lucent | Method and arrangement for echo cancellation in conference systems |
| JP5700700B2 (ja) * | 2012-05-18 | 2015-04-15 | 日本電信電話株式会社 | 会議サーバ装置、およびプログラム |
-
2002
- 2002-05-13 JP JP2002136913A patent/JP3973966B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2003333560A (ja) | 2003-11-21 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP5185631B2 (ja) | マルチメディア会議方法および信号 | |
| KR101486607B1 (ko) | 적극적인 화자 식별 | |
| EP0739558B1 (en) | Method and apparatus for multiple media digital communication system | |
| US7075924B2 (en) | Methods for multiple media digital communication | |
| JP3984929B2 (ja) | ＶｏＩＰシステム、ＶｏＩＰサーバ、及びマルチキャストパケット通信方法 | |
| JP4738058B2 (ja) | リアルタイムマルチメディア情報の効率的なルーティング | |
| KR20040062991A (ko) | 시간 스케줄링된 화상회의를 호출하는 서버 | |
| JP4700977B2 (ja) | 多地点会議システム | |
| JP3368833B2 (ja) | 会議システムにおける資料配布方法及びコンピュータ可読記録媒体 | |
| JP2001298545A (ja) | 電話利用型マルチメディア会議サービス提供システム | |
| JP4858441B2 (ja) | 同報送信システムおよびデータ送信方法 | |
| EP1978652A1 (en) | PoC DATA TRANSMITTING METHOD, PoC TELEPHONE COMMUNICATION SYSTEM AND APPARATUS | |
| JP2009016907A (ja) | 会議システム | |
| Gong | Multipoint audio and video control for packet-based multimedia conferencing | |
| TW200301058A (en) | Method and apparatus for an audio bridge | |
| US20020057333A1 (en) | Video conference and video telephone system, transmission apparatus, reception apparatus, image communication system, communication apparatus, communication method | |
| JP3973966B2 (ja) | 多地点会議システム、多地点会議システムの端末装置、および多地点会議システムのデータミキシング処理装置 | |
| JP2009194661A (ja) | 会議端末装置 | |
| JP2004527156A (ja) | パケット交換クライアント及び回線交換クライアントをリンクするためのシステムアーキテクチャ | |
| JP2007135108A (ja) | ネットワーク会議支援プログラムおよびネットワーク会議支援サーバ | |
| JP2003283672A (ja) | 電話会議装置 | |
| JP2003274023A (ja) | 通信会議システムと通信会議方法と通信会議プログラム | |
| WO2019080309A1 (zh) | 音视频文件共享方法、装置及系统、存储介质、终端设备 | |
| JPH0965313A (ja) | 遠隔会議システム | |
| JP2004336160A (ja) | マルチキャスト通信方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040123 |
|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20040123 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20051025 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20051220 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20060418 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060605 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070508 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070522 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20070612 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20070613 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100622 Year of fee payment: 3 |
|
| LAPS | Cancellation because of no payment of annual fees |