JP2006004406A - 分散マルチパーティ会議を制御する機構 - Google Patents

Abstract

【課題】 フルメッシュアーキテクチャをサポートする分散マルチパーティ会議の会議メンバの間の通信パスを制御する技法および機構を提供する。
【解決手段】 並列性の問題を処理し、サービス品質を保証するために、複数のチェックポイントをテストする。第１に、２つのシステムの間に保留中の通信パスが存在するかどうかを判定する検査を行う。第２に、システムの１つがマルチパーティ会議からの退去の過程にあるかどうかを判定する検査を行う。第３に、最大数の会議メンバが既に会議に存在するかどうかを判定する検査を行う。これらの検査のいずれかに合格しない場合に、２つのシステムの間の通信パスがエラーになる。成功の場合には、新しいシステムが、フルメッシュアーキテクチャを維持するために、会議の他のメンバのそれぞれとの参加プロセスを開始する。
【選択図】 図５

Description

本文書は、全般的にはコンピュータ実施される会議システムに関し、具体的には、分散マルチパーティ会議システム（ｄｅｃｅｎｔｒａｌｉｚｅｄ ｍｕｌｔｉ−ｐａｒｔｙ ｃｏｎｆｅｒｅｎｃｉｎｇ ｓｙｓｔｅｍ）に関する。

現在、人々は、一般に、インターネットを介するメッセージングサービスを使用して互いに通信する。例えば、ある人が、通信したい友人のリストを作成する場合がある。各友人は、そのリストに現れる一意のユーザＩＤを有する。友人がオンラインのとき、その友人のユーザＩＤが、その友人が通信に応えられることがその人にわかる形で表示される。その人は、友人との「チャット」セッションを開始し、メッセージを交換することができ、これを一般にインスタントメッセージ（ＩＭ）と称する。追加の友人をその「チャット」セッションに追加することができ、複数の人が互いに通信するマルチパーティ「チャット」セッションがもたらされる。

マルチパーティ「チャット」セッションをもつことは便利であるが、ユーザは、メッセージをタイプするのではなく、他の人を見られることとと、より「現実」的な経験をすることに関心を持つようになりつつある。残念ながら、マルチパーティビデオ会議システムは、多くの課題を提示する。課題の１つは、ビデオ会議アプリケーションの高帯域幅の需要とインターネットユーザの不均一性の両方を扱えるシステムを設計することである。もう１つの課題が、複数の当事者の間での通信の管理である。

マルチパーティビデオ会議システムの多くが、ローカルエリアネットワーク（ＬＡＮ）でのみ動作する。以下のものは、ＬＡＮで動作する２つのマルチパーティビデオ会議システムである（非特許文献１、非特許文献２）。これらのシステムは、ＬＡＮで動作するので、帯域幅はそれほど問題ではない。というのは、システムが、ハードウェアのマルチキャスト機能を使用して、ＬＡＮを介して送信されるデータの量を減らすことができるからである。残念ながら、ＩＰマルチキャスト対応ルータは、インターネットであまねく配備されてはいない。

ハードウェアマルチキャスト機能は、インターネットであまねく配備されてはいないが、広域ネットワーク（ＷＡＮ）でマルチパーティビデオ会議システムを実装する試みが行われてきた。一般にＩＶＩＳＩＴと称する、米国カリフォルニア州サンタモニカのｉＶｉｓｉｔ ＬＬＣ社が製造するシステムは、サーバベースの通信ツールである。ＩＶＩＳＩＴは、いつでもユーザによってアクセス可能な中央サーバを必要とする。中央サーバは、メンバシップ登録および検証を実行する。ユーザは、そのユーザの友人のリストで識別される他のユーザとのオーディオ／ビデオセッションをセットアップするときに、中央サーバと対話する。ＩＶＩＳＩＴは、ユーザが同時に複数の接続を行い、複数のビデオを見ることを可能にするが、このシステムは理想的ではない。あるモードでは、ユーザが、所望の接続のそれぞれを手動で行わなければならない。もう１つのモードでは、複数の当事者が、単一のチャットルーム内で互いにインスタントメッセージを送信することができるが、ビデオが望まれるときには、ビデオ通信が独立の１対１接続に基づく。したがって、ＩＶＩＳＩＴは、一般大衆が望むタイプのマルチパーティビデオ会議システムを提供しない。

一般にＷＥＢＥＸと称する、米国カリフォルニア州サンノゼのＷｅｂＥｘ Ｃｏｍｍｕｎｉｃａｔｉｏｎ，ＩＮＣ．社が製造するもう１つのシステムは、グローバルビジネス用のオンライン会議サービスを提供する。このサービスには、アプリケーション共有、ホワイトボード、およびビデオ会議が含まれる。ＷＥＢＥＸには、エンドユーザの間で通信をルーティングする、全世界の複数のスイッチングセンタが含まれる。この戦略は、多数の同時ビデオ会議があるときに効率的であるが、ＷｅｂＥｘは、小規模の個人的通信にはコストが高すぎる。

K. Watanabe et al. entitled "Distributed Multiparty Desktop Conferencing System: MERMAID" published in Proceedings of the Conference on Computer-Supported Cooperative Work, Los Angeles, CA, September 1990 Mike Macedonia and Don Bruzman entitled "MBONE, the Multicast Backbone" published in IEEE Computer, April 1994 J. Lennox and H. Schulzrinne, entitled "A protocol for reliable decentralized conferencing", In Proc of 13th International Workshop on Network and Operating Systems Support for Digital Audio and Video, pp. 72-81, 2003

上で説明したように、サーバに通信を処理させることは、大企業には効率的であるが、サーバベースシステムは、小規模の個人通信と共に動作するには複数の支障がある。支障の１つが、サーバを購入し、維持する費用である。もう１つの不利益が、中央サーバを使用することによって生じるボトルネックである。したがって、これまで、一般大衆による使用に適するマルチパーティビデオ会議システムの満足な解決策はなかった。

本明細書に記載の技法および機構は、フルメッシュアーキテクチャをサポートする分散マルチパーティ会議の会議メンバの間での通信パスの制御を対象とする。並列性（ｃｏｎｃｕｒｒｅｎｃｙ）の問題を処理し、サービス品質を保証するために、複数のチェックポイントをテストする。第１に、２つのシステムの間に保留中の通信パスが存在するかどうかを判定する検査を行う。第２に、システムの１つがマルチパーティ会議を退去する過程にあるかどうかを判定する検査を行う。第３に、最大数の会議メンバが既に会議に存在するかどうかを判定する検査を行う。これらの検査のいずれかに合格しない場合に、２つのシステムの間の通信パスがエラーになる。成功の場合に、新しいシステムが、フルメッシュアーキテクチャを維持するために、会議の他のメンバのそれぞれとの参加プロセスを開始する。

図面を参照して、非制限的で非網羅的な実施形態を説明するが、図面では、同一の符号が、特に指定されない限り様々な図面を通じて同一の部分を指す。

手短に言えば、本発明の機構は、分散マルチパーティビデオ会議システムを確立し、実施する会議制御プロトコルを提供する。このプロトコルは、複数のチェックポイントを使用して、並列性の問題を処理し、サービス品質を保証する。以下で詳細に説明するように、本発明の会議制御プロトコルは、ダイヤルアップ、ブロードバンド、ケーブルなど、異なるタイプのインターネット接続で効果的に動作する。上記および他の利益は、次の詳細な説明を読んだ後に明白になる。

図１に、本発明の分散ビデオ会議機構を実施する１つの例示的なシステムを示す。このシステムには、コンピューティングデバイス１００などのコンピューティングデバイスが含まれる。非常に基本的な構成で、コンピューティングデバイス１００に、通常は、少なくとも１つの処理ユニット１０２およびシステムメモリ１０４が含まれる。コンピューティングデバイスの正確な構成およびタイプに応じて、システムメモリ１０４を、揮発性（ＲＡＭなど）、不揮発性（ＲＯＭ、フラッシュメモリなど）、またはこの２つのある組合せとすることができる。システムメモリ１０４に、通常は、オペレーティングシステム１０５、１つまたは複数のプログラムモジュール１０６が含まれ、プログラムデータ１０７を含めることができる。プログラムモジュール１０６に、本発明の分散マルチパーティ会議機構を実施するモジュール１３０が含まれる。この基本構成は、図１では破線１０８内のコンポーネントによって示されている。

コンピューティングデバイス１００は、追加の特徴または機能性を有することができる。例えば、コンピューティングデバイス１００に、例えば磁気ディスク、光学ディスク、またはテープなどの追加のデータストレージデバイス（取り外し可能および／または固定）を含めることもできる。そのような追加ストレージは、図１では、取り外し可能ストレージ１０９および固定ストレージ１１０によって示されている。コンピュータ記憶媒体に、コンピュータ可読命令、データ構造、プログラムモジュール、または他のデータなどの情報のストレージの方法またはテクノロジで実施された、揮発性および不揮発性の、取り外し可能および固定の媒体を含めることができる。システムメモリ１０４、取り外し可能ストレージ１０９、および固定ストレージ１１０のすべてが、コンピュータ記憶媒体の例である。したがって、コンピュータ記憶媒体に、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、または他のメモリテクノロジ、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）、または他の光学ストレージ、磁気カセット、磁気テープ、磁気ディスクストレージ、または他の磁気ストレージデバイス、あるいは、所望の情報の記憶に使用でき、コンピューティングデバイス１００によってアクセスできる他のすべての媒体が含まれるが、これらに制限はされない。そのようなコンピュータ記憶媒体のすべてを、デバイス１００の一部とすることができる。コンピューティングデバイス１００は、キーボード、マウス、ペン、音声入力デバイス、接触入力デバイスなどの入力デバイス１１２も有することができる。ディスプレイ、スピーカ、プリンタなどの出力デバイス１１４も、含めることができる。これらのデバイスは、当技術分野で周知であり、本明細書で長々と説明はしない。

コンピューティングデバイス１００に、このデバイスが、ネットワークを介するなど、他のコンピューティングデバイス１１８と通信できるようにする通信接続１１６も含めることができる。通信接続１１６は、通信媒体の１つの例である。通信媒体は、通常は、搬送波または他のトランスポート機構などの変調されたデータ信号内のコンピュータ可読命令、データ構造、プログラムモジュール、または他のデータによって実施でき、すべての情報配信媒体が含まれる。用語「変調されたデータ信号」は、信号内で情報をエンコードする形でその特性の１つまたは複数を設定または変更された信号を意味する。制限ではなく例として、通信媒体に、有線ネットワークまたは直接配線接続などの有線媒体と、音響、ＲＦ、赤外線、および他の無線媒体などの無線媒体が含まれる。本明細書で使用される用語コンピュータ可読媒体に、記憶媒体と通信媒体の両方が含まれる。

プログラムモジュールなど、１つまたは複数のコンピュータまたは他のデバイスによって実行されるコンピュータ実行可能命令の全般的な文脈で、本明細書で様々なモジュールおよび技法を説明する場合がある。一般に、プログラムモジュールに、特定のタスクを実行するか特定の抽象データ型を実施する、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造などが含まれる。これらのプログラムモジュール等は、ネイティブコードとして実行することができ、あるいは、仮想マシンまたは他のジャストインタイムコンパイル実行環境内などで、ダウンロードし、実行することができる。通常、プログラムモジュールの機能性は、様々な実施形態で望み通りに組み合わせ、あるいは分散することができる。

これらのモジュールおよび技法の実装は、ある形のコンピュータ可読媒体に記憶するか、これを介して伝送することができる。コンピュータ可読媒体は、コンピュータによってアクセスできるすべての使用可能な媒体とすることができる。制限ではなく例として、コンピュータ可読媒体に、「コンピュータ記憶媒体」および「通信媒体」が含まれる。

図２は、図１に示された複数のコンピュータデバイスをその中で構成できる例示的なネットワークである。ネットワーク２００は、フルメッシュ会議アーキテクチャを使用する分散アーキテクチャである。フルメッシュ会議アーキテクチャを説明する追加情報は、その全体を参照によって本明細書に特に組み込まれる非特許文献３から得ることができる。上の文献で、この文献に記載のフルメッシュ会議アーキテクチャが、無線デバイスおよび５６ｋｂｐｓモデムを有するユーザなど、帯域幅制限されたエンドシステムに適さないと述べられていることに留意されたい。対照的に、本発明の会議制御プロトコルは、この制限を克服する。さらに、本発明の会議制御プロトコルは、接続プロセス中のネットワークコストを減らし、より高速の参加プロセスを提供し、過渡的ネットワークエラーによって引き起こされる参加プロセス中の障害の可能性を減らす、効率的なプロトコルを提供する。

一般に、フルメッシュ会議アーキテクチャでは、各会議メンバ（例えば、会議メンバ２０２〜２１０）が、他の会議メンバとの直接通信チャネル（２つの会議メンバの間の矢印によって表される）を有する。各会議メンバ２０２〜２１０は、図１に示されたコンピューティングデバイス１００などのコンピューティングデバイスである。各会議メンバ２０２〜２１０は、フルメッシュ会議アーキテクチャの確立および維持に、本明細書に記載の会議制御プロトコルを使用する。以下で詳細に説明するように、本発明の会議制御プロトコルは、小規模のシステムに適する単純な会議制御プロトコルを提供する。従来のマルチパーティビデオ会議システムと異なって、本発明のアーキテクチャは、中央サーバを必要としない。したがって、中央サーバに関して上で述べた支障は、本発明のアーキテクチャにはあてはまらない。

フルメッシュ会議アーキテクチャ２００では、各会議メンバ２０２〜２１０が、等しい地位を有する。したがって、どの会議メンバも、他の会議メンバと比較して特別な機能性または特権を有しない。さらに、各会議メンバは、いつでも会議に新しいユーザを勧誘する、等しい能力を有する。同様に、各会議メンバは、いつでも会議から退去することができる。各会議メンバが、いつでも、追加のユーザを勧誘し、退去することができるが、以下で詳細に説明するように、フルメッシュ会議アーキテクチャ２００の安定性が維持される。

図３は、本明細書に記載の技法および機構を実施する、図１に示されたコンピューティングデバイス１００内のモジュール１３０の一実施形態を示す機能ブロック図である。当業者が諒解するように、いくつかの実施形態において、１モジュールの機能性全体または１モジュールの機能性の一部を、請求の範囲から逸脱せずに別のモジュールに組み込むことができる。このマルチパーティビデオ会議システムに、ユーザインターフェース３０２、メディアストリームエンジン３１０、伝送モジュール３１２、会議制御モジュール３０４、メッセージングサービスインターフェース３０８、および伝送制御プロトコル（ＴＣＰ）／ユーザデータグラムプロトコル（ＵＤＰ）インターフェース３０６が含まれる。

ユーザインターフェース３０２は、メディアストリームエンジン３１０および会議制御モジュール３０４と通信する。メディアストリームエンジン３１０は、伝送モジュール３１２と通信し、伝送モジュール３１２は、ＴＣＰ／ＵＤＰインターフェース３０６と通信する。会議制御モジュール３０４は、メッセージングサービスインターフェース３０８を介して、メッセージングサービス（図示せず）と通信する。さらに、会議制御モジュール３０４は、ＴＣＰ／ＵＤＰインターフェース３０６を介して他のコンピューティングデバイスと通信する。メッセージングサービス３０８が、オープンプログラミングインターフェースを使用する時に、会議制御モジュール３０４は、当業者に既知の標準的なプログラミング技法を使用して、メッセージングサービスと通信することができる。

ユーザインターフェース３０２、メディアストリームエンジン３１０、および伝送モジュール３１２の動作は、本発明の会議制御プロトコルが動作する形を変更せずに、様々な形で行うことができる。したがって、次では、これらの他のモジュールの１つの例示的な動作を説明し、その後、会議制御モジュール３０４を詳細に説明する。前者に関して、ユーザインターフェース３０２は、会議中にオーディオ／ビデオをオンまたはオフに切り替える、会議に参加する、会議から退去するなど、ユーザ要求を処理する。メディアストリームエンジン３１０は、オーディオ／ビデオを取り込み、オーディオ／ビデオを再生する。メディアストリームエンジン３１０によって取り込まれるオーディオ／ビデオは、伝送モジュール３１２によって、ＴＣＰ／ＵＤＰインターフェースを介して他の会議メンバに送信される。会議制御モジュール３０４は、新しいユーザが参加する時および現在のメンバがメッシュ会議アーキテクチャから退去するときに、会議メンバの間の通信を処理する。この説明では、マルチパーティビデオ会議システムに関してメッシュ会議アーキテクチャおよび会議制御プロトコルを説明するが、以下で説明する機構は、グループテキストメッセージングなど、他の環境でも実施することができる。

図４は、図２に示されたメッシュ会議ネットワークを確立し、維持する責任を負う本発明の会議制御プロトコルを実施するメッセージタイプを示す表４００である。上で述べたように、メッシュ会議ネットワークの各会議メンバは、ネットワーク内の他の会議メンバのそれぞれへの通信チャネルを有する。表４００には、２つの列があり、第１列４０２は、会議制御プロトコルによって使用されるメッセージのタイプを識別する。第２列４０４は、メッセージの各タイプに関連するアクションを説明する。図からわかるように、本発明の会議制御プロトコルは、非常に簡潔であり、４つのメッセージタイプすなわち、ＪＯＩＮ（参加）メッセージ４１０、ＡＣＣＥＰＴ（受入）メッセージ４１２、ＲＥＪＥＣＴ（拒絶）メッセージ４１４、およびＬＥＡＶＥ（退去）メッセージ４１６を使用する。本発明の会議制御プロトコルは、簡潔なプロトコルを実施するので、接続セットアッププロセス中のネットワークコストが減り、メンバを参加させるプロセスが高速であり、過渡的ネットワークエラーに起因する参加プロセス中の障害の可能性が減る。

ＪＯＩＮメッセージ４１０は、第１コンピューティングデバイスがマルチパーティ会議の確立または参加を望むことを示すために、第１コンピューティングデバイスから別のコンピューティングデバイスに送信される。ＡＣＣＥＰＴメッセージ４１２は、ＪＯＩＮメッセージ４１０に応答して別のコンピューティングデバイスから送信され、その別のコンピューティングデバイスがＪＯＩＮメッセージ４１０を受け入れたことを示す。ＲＥＪＥＣＴメッセージ４１４は、ＪＯＩＮメッセージ４１０に応答して別のコンピューティングデバイスから送信され、その別のコンピューティングデバイスがＪＯＩＮメッセージ４１０を受け入れなかったことを示す。以下で説明するように、図５に関して、ＪＯＩＮメッセージが受け入れられない複数のシナリオがある。ＬＥＡＶＥメッセージ４１６は、現在マルチパーティ会議に加わっている第１コンピューティングデバイスがそのマルチパーティ会議から離脱することを示すために、第１コンピューティングデバイスからそのマルチパーティ会議の他のコンピューティングデバイスに送信される。

本発明の会議制御プロトコルは、マルチパーティビデオ会議システムに適するサービス品質（ＱＯＳ）を提供する。このプロトコルは、参加プロセスおよび離脱プロセス中に要件（例えばチェックポイント）を課すことによって、このサービス品質を達成する。一般に、チェックポイントは、メッシュ会議アーキテクチャが危険にさらされない形で並列性の問題が処理されることを保証する。並列アクションとは、会議が、別の既存のメンバのアクションによって引き起こされる不安定状態であるときに、１つの既存メンバによって実行されるアクションである。したがって、並列性は、必ずしも正確な一致を意味しない。

図５は、図２に示されたメッシュ会議ネットワークに新しいユーザを追加する参加プロセス５００中の会議制御プロトコルの動作を示す順次流れ図である。参加プロセス５００は、フルメッシュアーキテクチャを完全に保つために、必要な接続ごとに実行される。勧誘された新しいユーザは、必要な通信チャネルのそれぞれを作る責任を負う。例えば、現在３つの既存メンバがある場合に、新しいユーザは、既存の３つのメンバのそれぞれについて１回、合計３回だけ参加プロセス５００を実行する。一点鎖線５０１の上のアクションは、ＴＣＰ接続を作成するのに必要な処理を表す。一点鎖線５０１の下のアクションは、通信ダイアログを作成するのに必要な処理を表す。通信ダイアログは、既存会議メンバのオーディオ／ビデオストリームへの加入要求など、会議制御メッセージを送信するのに使用される。

参加プロセス５００に、４つのチェックポイント５０２、５０４、５０６、および５０８が含まれる。以下で説明するように、これらのチェックポイントのどれかに合格しない場合に、参加プロセス５００が終了し、新しいユーザは、会議に参加することができない。この図の左側の行は、マルチパーティビデオ会議の既存の参加者（例えばメンバＭ）を表す。この図の右側の行は、そのマルチパーティビデオ会議のメンバになることを望む新しいユーザ（例えば新規ユーザＮ）を表す。あるときに、新規ユーザＮがＣＯＮＮＥＣＴＩＯＮ ＲＥＱＵＥＳＴ（接続要求）メッセージを送信する前に、新規ユーザＮが、マルチパーティビデオ会議を知るようになる。新規ユーザＮは、既存メンバＭからインターネットメッセージングサービスを介して送信されたインターネットインスタントメッセージ（ＩＭ）を介してマルチパーティビデオ会議を知るようになる可能性がある。このインターネットメッセージングサービスは、複数の周知のメッセージングサービスの１つとすることができる。これらのメッセージングサービスは、当技術分野で周知であり、本発明の会議制御プロトコルとの対話を説明するのに必要な範囲を除いて、本明細書で長々と述べる必要はない。インターネットメッセージに、ＩＰアドレスが含まれ、新規ユーザＮは、参加プロセス５００全体を通じてこのＩＰアドレスを使用する。さらに、インスタントメッセージに、一意の会議ＩＤを含めることができる。新規ユーザＮが、マルチパーティ会議を知るようになり、会議に参加するように勧誘されたならば、会議制御プロトコルが開始される。上の例では、新規ユーザＮは、インスタントメッセージ内で供給されたリンクをクリックすることによって、会議への参加を開始することができる。

チェックポイント５０２で、図３に示されたマルチパーティビデオ会議モジュールのインスタンスが、新規ユーザＮに関連するコンピューティングデバイスに前にロードされたかどうかかを、新規ユーザＮが判定する。マルチパーティビデオ会議モジュールが、前にロードされていない場合に、この時にこのモジュールをロードし、その結果、処理を継続できるようにする。マルチパーティビデオ会議モジュールが、ロードされ、実行に使用可能になったならば、新規ユーザＮは、新規ユーザＮを会議に勧誘したインスタントメッセージなど、帯域外機構から受け取ったＩＰアドレスに従って、既存メンバＭにＣＯＮＮＥＣＴＩＯＮ ＲＥＱＵＥＳＴメッセージを送信する。このＣＯＮＮＥＣＴＩＯＮ ＲＥＱＵＥＳＴメッセージによって、既存メンバＭと新規ユーザＮとの間のＴＣＰ接続チャネルの作成が開始される。処理は、チェックポイント５０４に続く。

チェックポイント５０４で、既存メンバＭが、同一の２つのコンピューティングデバイスの間で２つの通信チャネルが作られないようにする並列性検査を実行する。２つの通信チャネルは、フルメッシュアーキテクチャを損なわないが、各通信チャネルが、リソースを使用し、これによって、最終的に、他のコンピューティングデバイスによってそれを使用できるようにしないことによってリソースが浪費される。したがって、２つの通信チャネルを有することは、望ましくない。

本発明の会議制御プロトコルは、重複する通信チャネルを防ぐために、コンピューティングデバイスのそれぞれで、メンバリスト（例えば、メンバリスト５１２および５２２）と共に保留中リスト（例えば、保留中リスト５１０および５２０）を実施する。保留中リスト５１０および５２０ならびにメンバリスト５１２および５２２は、別々のリストとして図示されているが、当業者は、コンピューティングデバイスが、保留中リストおよびメンバリストの両方に必要な情報を含む１つのリストを有することができることを諒解するであろう。保留中リスト５１０および５２０は、ＣＯＮＮＥＣＴＩＯＮ ＲＥＱＵＥＳＴメッセージが送信される時に、そのＣＯＮＮＥＣＴＩＯＮ ＲＥＱＵＥＳＴを送信するコンピュータデバイスで更新される。

したがって、図５を参照すると、保留中リスト５２０は、新規ユーザＮがＣＯＮＮＥＣＴＩＯＮ ＲＥＱＵＥＳＴを送信する時に更新される。図からわかるように、既存メンバＭは、新規ユーザＮに関連する保留中リスト５２０にリストされている。メンバリスト５２２は、コンピューティングデバイスが、マルチパーティビデオ会議モジュールをロードするときに、メンバであるものとしてそのコンピューティングデバイスを反映するために更新される。したがって、上のメンバリスト５２２は、メンバであるものとして新規ユーザＮを反映する。既存メンバＭも、保留中リスト５１０を有することに留意されたい。保留中リスト５１０には、既存メンバＭがＣＯＮＮＥＣＴＩＯＮ ＲＥＱＵＥＳＴを送信した先のコンピューティングデバイスがリストされる。図５に示された例のフローでは、既存メンバＭが、新規ユーザＮにＣＯＮＮＥＣＴＩＯＮ ＲＥＱＵＥＳＴを送信しておらず、したがって、新規ユーザＮは、保留中リスト５１０にない。ＣＯＮＮＥＣＴＩＯＮ ＲＥＱＵＥＳＴが送信されたコンピューティングデバイスの一意の識別子が、そのメンバを識別するために保留中リスト５２０に追加される。

したがって、チェックポイント５０４で、既存メンバＭが、新規ユーザＮからＣＯＮＮＥＣＴＩＯＮ ＲＥＱＵＥＳＴを受信するときに、既存メンバＭは、その保留中リスト（例えば保留中リスト５１０）を検査する。新規ユーザＮが、保留中リスト５１０にない場合に、既存メンバＭは、ＣＯＮＮＥＣＴＩＯＮ ＡＣＫＮＯＷＬＥＤＧＥ（ＡＣＫ、接続肯定応答）メッセージを新規ユーザＮに送信する。しかし、新規ユーザＮが、既に保留中リストにある場合に、既存メンバＭは、保留中リストの新規ユーザＮの識別を、ＣＯＮＮＥＣＴＩＯＮ ＲＥＱＵＥＳＴメッセージから受け取った新規ユーザＮの識別と比較する。この比較に基づいて、既存メンバＭは、ＣＯＮＮＥＣＴＩＯＮ ＲＥＪＥＣＴ（接続拒否）メッセージまたはＣＯＮＮＥＣＴＩＯＮ ＡＣＫメッセージのいずれかを新規ユーザＮに送信する。一実施形態において、この比較に、新規ユーザＮのドット区切りＩＰアドレスを比較することが用いられる。この実施形態では、コンピューティングデバイスのドット区切りＩＰアドレスが、保留中リストに記憶されたローカルＩＤより大きい時に、ＣＯＮＮＥＣＴＩＯＮ ＡＣＫが送信される。したがって、チェックポイント５０４を実行することによって、メンバＭと新規ユーザＮの間の冗長パスが、確立されない。

新規ユーザＮが、ＣＯＮＮＥＣＴＩＯＮ ＡＣＫメッセージを受信する場合に、これによって、ＴＣＰ接続が確立されたことが知らされる。新規ユーザＮは、次に、既存メンバＭにＪＯＩＮメッセージを送信する。既存メンバＭは、もう１つの検証を実行する（チェックポイント５０６参照）。チェックポイント５０６で、存在フラグを検査して、既存メンバＭが、実際に会議を退去する過程にあるかどうかを判定する。以下で図６に関して説明するように、既存メンバＭが、退去を試みているときには、既存メンバＭは、その意志を示すために存在フラグをセットする。したがって、チェックポイント５０６で、既存メンバＭは、その存在フラグを検査して、新規ユーザＮから受信したＪＯＩＮメッセージを拒否するか否かを決定する。存在フラグから、既存メンバＭが会議を退去する過程にあることが示される場合に、既存メンバＭは、ＪＯＩＮメッセージを拒否する。そうでない場合に、既存メンバＭは、チェックポイント５０８に進む。

チェックポイント５０８で、既存メンバＭが、そのメンバリスト５１２および保留中リスト５１０を検査して、会議に別のメンバを追加できるかどうかを判定する。マルチパーティビデオ会議システムで互いに通信できるメンバの数は、ユーザに最大の接続性を提供すると同時に、インターネットの現在の帯域幅条件の下でサービス品質が劣化しないように選択される。一実施形態において、会議メンバのこの限度は５をデフォルトとする。別の実施形態では、会議メンバの最大数は会議イニシエータ（すなわち、会議に関する最初のＣＯＮＮＥＣＴＩＯＮ ＲＥＱＵＥＳＴメッセージを送信するユーザ）によって構成可能である。会議メンバの所定の数に既に達している場合には、ＪＯＩＮメッセージがエラーになり、新規ユーザＮは、メッシュアーキテクチャに含まれない。しかし、チェックポイント５０８に合格する場合に、既存メンバＭは、ＡＣＣＥＰＴメッセージを新規ユーザＮに送信する。ＡＣＣＥＰＴメッセージは、既存メンバＭが見るマルチパーティ会議に現在加わっているすべての会議メンバ（例えば、メンバＡ、Ｂ、Ｍ、およびＮ）を識別する。この時点で、既存メンバＭが、新規ユーザＮをメンバとみなし、新規ユーザＮをメンバリスト５１２に含めることに留意されたい。これが完了したならば、既存メンバＭと新規ユーザＮとの間で、このどちらかが退去するまで、通信ダイアログが使用可能である。

新規ユーザＮは、ＡＣＣＥＰＴメッセージを受信するときに、既存メンバＭを保留中リスト５２０からメンバリスト５２２に移動する。次に、新規ユーザＮは、ＡＣＣＥＰＴメッセージで識別されたメンバのそれぞれ（例えばメンバＡおよびＢ）について参加プロセス５００を実行する責任を負う。メンバＡおよびＢは、新規ユーザＮがこれらにＣＯＮＮＥＣＴＩＯＮ ＲＥＱＵＥＳＴメッセージを送信するまで、保留中リスト５２０に追加されない。

図６は、図２に示されたメッシュ会議ネットワークからメンバを除去する退去プロセス６００中の会議制御プロトコルの動作を示す順次流れ図である。退去プロセス６００について、退去するメンバ（例えばメンバＡ）は、会議の他の既存メンバのそれぞれ（例えばメンバＢ）にＬＥＡＶＥメッセージを送信する。したがって、退去プロセス６００は、既存メンバごとに１回実行される。少なくとも１つのＬＥＡＶＥメッセージの後に、好ましくは最初の退去メッセージを送信した後に、退去するメンバＡは、その存在フラグを更新して、会議から退去する過程にあることを示す。上で説明したように、参加プロセス５００は、チェックポイント５０６中にこの存在フラグを使用して、退去するメンバが再参加を「強制」されないことを保証する。

図５に示された参加プロセス５００中のチェックポイント５０２〜５０６のそれぞれの、図６に示された退去プロセス６００とあいまっての重要性は、以下のある例のシナリオによって最もよく理解することができる。

チェックポイント５０２に関して、チェックポイント５０２は、分散マルチパーティプログラムモジュールの１つのインスタンスだけが、１つのコンピューティングデバイスにロードされることを保証する。チェックポイント５０２は、ユーザが再参加すると判断する少し前にユーザが会議から退去する状況を処理する手段になる。この状況では、ＪＯＩＮメッセージが、ＬＥＡＶＥメッセージを追い越す可能性がある。チェックポイント５０２がなければ、これが発生した場合に、他のメンバが、先に到着したＪＯＩＮメッセージを無視し、ＬＥＡＶＥが到着したときに接続をクローズする可能性がある。これは、非常に望ましくない結果である。しかし、チェックポイント５０２を実行することによって、既にメンバリストにあるメンバからＪＯＩＮメッセージを受信する既存メンバが、前の接続をクローズし、現在の要求を受け入れるようになる。

チェックポイント５０４に関して、チェックポイント５０４は、２つのメンバの間の通信チャネルが１つだけあることを保証する。２つの既存会議メンバ（例えば会議メンバＡおよびＢ）のそれぞれが、異なる新規ユーザ（例えば新規ユーザＣおよびＤ）をそれぞれ勧誘する場合に、同一のコンピューティングデバイスの間で２つの通信チャネルが作られる可能性がある。メッシュ会議ネットワークを実施する時に、会議メンバＡが会議に新規ユーザＣを勧誘するときに、会議メンバＡは、メンバＡおよびＢが現在の既存メンバであることを新規ユーザＣに知らせる。同様に、会議メンバＢが、新規ユーザＤを会議に勧誘する時に、会議メンバＢは、ＡおよびＢがメンバであることを新規ユーザＤに知らせる。メンバＣが、メンバＢとの参加プロセスを開始する時に、その最後に、メンバＢは、Ａ、Ｂ、およびＤがメンバであることをメンバＣに知らせる。同様に、メンバＤが、メンバＡとの参加プロセスを開始するときに、その最後に、メンバＡは、Ａ、Ｂ、およびＣがメンバであることをメンバＤに知らせる。したがって、メンバＣおよびＤの両方が、お互いの間の通信ダイアログを確立するために参加プロセスを開始する。チェックポイント５０４は、この通信ダイアログのうちの１つだけが確立されることを保証する。

チェックポイント５０６に関して、チェックポイント５０６は、退去しようとしているメンバが、フルメッシュ会議アーキテクチャを維持するために会議への再参加を強制されないことを保証する。例えば、マルチパーティ会議に３つのメンバ（メンバＡ、Ｂ、およびＣ）がいると仮定する。メンバＡは、マルチパーティ会議から退去すること望み、メンバＢおよびＣの両方にＬＥＡＶＥメッセージを送信する。メンバＡが、退去の過程にある間に、メンバＢが、このマルチパーティ会議にメンバＤを勧誘する。この状況で、Ａが、マルチパーティ会議から成功裡に退去する前に、メンバＤのＣＯＮＮＥＣＴＩＯＮ ＲＥＱＵＥＳＴを受信する場合がある。チェックポイント５０６がなければ、メンバＡは、ＤのＣＯＮＮＥＣＴＩＯＮ ＲＥＱＵＥＳＴに応答して会議に再参加することになる。しかし、チェックポイント５０６で、退去の時に存在フラグを使用することによって、Ａは、それが退去の過程にあると判断し、新規ユーザＮにＲＥＪＥＣＴメッセージを送信する。

チェックポイント５０８に関して、チェックポイント５０８は、すべてのマルチパーティ会議についてサービス品質が維持されることを保証する。ユーザの数を所定の数までに制限することによって、会議制御プロトコルは、会議が大きくなりすぎ、サービス品質を危険にさらすことを許容しない。早期のメンバは、後から参加するメンバに対する優先権を有する。

ある状況で、新規ユーザＮが、既に新しいメンバとして受け入れられており、あるコンピューティングデバイスのメンバリストに既に現れている可能性があることに留意することは重要である。新規ユーザＮが、異なる既存メンバからＣＯＮＮＥＣＴＩＯＮ ＲＥＪＥＣＴメッセージを受信する場合に、参加プロセス５００がエラーになり、新規ユーザＮは、会議に参加しない。したがって、新規ユーザＮは、それとの接続が既に確立されているすべての既存会議メンバにＬＥＡＶＥメッセージを送信しなければならない。

どの会議制御プロトコルの検証も難しいが、本発明のマルチパーティ会議制御プロトコルの検証は、さらに難しい。というのは、このプロトコルの挙動が、イベントが発生する順序に強く依存し、可能な順序が、実際に、会議のサイズおよびアクションの数に対して指数関数的であるからである。これを知ってのうえで、本発明のマルチパーティ会議プロトコルの検証は、すべての可能な並行シナリオでこのプロトコルの動作を検証することによって実行された。上で述べたように、メッシュ会議アーキテクチャの安定性は、メンバが同時に参加し、退去する場合であっても常に保護されなければならない。同時の参加および退去は、２つの異なるメンバについて発生する可能性があり、あるいは、同一のメンバについて発生する場合がある。

したがって、４タイプのイベントが、定義され、検証された。下の表に示された、この４つのイベントに、ＪＯＩＮ（Ｊ）、ＬＥＡＶＥ（Ｌ）、ＢＲＩＥＦ ＪＯＩＮ（ＢＪ）、およびＢＲＩＥＦ ＬＥＡＶＥ（ＢＬ）が含まれる。ＪＯＩＮおよびＬＥＡＶＥは、上で説明した。ＢＲＩＥＦ ＪＯＩＮは、メンバが参加し、即座に退去する状況を指す。ＢＲＩＥＦ ＬＥＡＶＥは、メンバが退去し、即座に再参加する状況を指す。この４つのイベントに基づいて、本発明の会議制御プロトコルをテストした。テストの結果を、表１に示す。

表１からわかるように、１５個のシナリオをテストした。各行が、テストシナリオの１つを表す。初期状態は、会議の既存メンバを識別する。アクション列は、同時に発生したアクション、ＪＯＩＮ（Ｊ）、ＬＥＡＶＥ（Ｌ）、ＢＲＩＥＦ ＪＯＩＮ（ＢＪ）、およびＢＲＩＥＦ ＬＥＡＶＥ（ＢＬ）を識別する。例えば、テスト１では、ＥおよびＦの両方が、ＪＯＩＮメッセージを送信した。最後の状態列は、生じなければならない最終的な状態を識別する。通常、許容可能な最後の状態が、１つだけある。しかし、テスト１では、本発明の会議プロトコルが、メンバの数を５までに制限するので、２つの参加者のうちの１つだけが、出席を許容され、あるいはその代わりに、両方が参加を許可されない。表１の情報は、自己説明的なので、表１のこれ以上の分析は説明しない。本発明の会議プロトコルが、１５個のテストのそれぞれに合格し、すべての会議メンバが、他のメンバのそれぞれとの正確に１つの単一アクティブ通信チャネルにより安定したことに留意することが重要である。

本発明のマルチパーティビデオ会議システムは、セキュリティ保護も提供する。一実施形態において、セキュリティ保護には、各会議に一意の１２８ビット会議ＩＤを割り当てることが含まれる。この１２８ビット会議ＩＤは、グローバル一意識別子（ＧＵＩＤ）に類似する。会議ＩＤは、会議に出席するように新規ユーザを勧誘する会議イニシエータによって生成される。同一の会議への勧誘のそれぞれが、インスタントメッセージ内に同一の会議ＩＤを有する。会議ＩＤは、会議を識別するため、および新規ユーザが識別された会議に適当に勧誘されたことを保証するために、ＪＯＩＮメッセージと共に送信される。

したがって、説明したように、本発明のマルチパーティビデオ会議システム用の会議制御プロトコルは、フルメッシュ会議アーキテクチャで構成されたネットワーク化されたコンピュータを使用して動作する。したがって、１つまたは複数の中央サーバを有することに関連するコストおよび支障が回避される。本発明の会議制御プロトコルは、低コストでもある、マルチパーティビデオ会議の信頼性があり柔軟な代替案を提供する。

本明細書全体を通じて、「一実施形態」、「実施形態」、または「例の実施形態」に言及したが、これは、特定の説明される特徴、構造、または特性が、本発明の少なくとも１つの実施形態に含まれることを意味する。したがって、そのような句の使用は、単に１つの実施形態以上のものを指す場合がある。さらに、説明された特徴、構造、または特性を、１つまたは複数の実施形態において、適当な形で組み合わせることができる。

しかし、当業者は、１つまたは複数の特定の詳細なしで、または他の方法、リソース、材料などを用いて、本発明を実践できることを認めるであろう。他の場合に、本発明の諸態様を不明瞭にしないようにするだけのために、周知の構造、リソース、または動作を、詳細には図示せず、説明しなかった。

例の実施形態および応用例を図示し、説明したが、本発明が、上で説明した正確な構成およびリソースに制限されないことを理解されたい。当業者に明白な様々な修正、変更、および変形を、請求される発明の範囲から逸脱せずに、本明細書で開示された本発明の方法およびシステムの配置、動作、および詳細において行うことができる。

本明細書で説明する技法および機構を実施するのに使用することができる例示的コンピューティングデバイスを示す図である。 図１に示された複数のコンピュータデバイスをその中で構成できる例示的ネットワークを示す図である。 本明細書で説明する技法および機構を実施する、図１に示されたコンピューティングデバイス内の構成要素を示す機能ブロック図である。 図２に示されたネットワークを確立し、維持する会議制御プロトコルを示す表図である。 図２に示されたネットワークに新しいユーザを追加するときの会議制御プロトコルの動作を示す順次流れ図である。 メンバが図２に示されたネットワークから退去するときの会議制御プロトコルの動作を示す順次流れ図である。

符号の説明

１００ コンピューティングデバイス
１０４ システムメモリ
１０５ オペレーティングシステム
１０６ プログラムモジュール
１０７ プログラムデータ
１０２ 処理ユニット
１０９ 取り外し可能ストレージ
１１０ 固定ストレージ
１１２ 入力デバイス
１１４ 出力デバイス
１１６ 通信接続
１１８ 他のコンピューティングデバイス
２０２ コンピューティングデバイスＡ
２０４ コンピューティングデバイスＢ
２０６ コンピューティングデバイスＣ
２０８ コンピューティングデバイスＤ
２１０ コンピューティングデバイスＥ
３０２ ユーザインターフェース
３１０ メディアストリームエンジン
３１２ 伝送モジュール
３０４ 会議制御モジュール
３０８ メッセージングサービスインターフェース
３０６ ＴＣＰ／ＵＤＰインターフェース

Claims (29)

1. フルメッシュアーキテクチャをサポートする分散マルチパーティ会議の会議メンバの間の通信パスを制御する方法であって、
   第２システムから送信された接続要求メッセージを第１システムで受信すること、
   前記第１システムと前記第２システムとの間に保留中の通信パスが存在しない場合に、接続肯定応答を前記第２システムに送信すること、
   前記第２システムから参加メッセージを受信すること、および
   前記第１システムが前記マルチパーティ会議から退去する過程にない場合に、前記第２システムに参加受入メッセージを送信すること
   を備えることを特徴とする方法。
2. 前記参加受入メッセージは、現在前記マルチパーティ会議にいる会議メンバを識別するメンバリストを含むことを特徴とする請求項１に記載の方法。
3. 前記メンバリストは、前記会議メンバの１つとして前記第２システムを含むことを特徴とする請求項２に記載の方法。
4. 前記第１システムは、前記第１システムの保留中リストを検査することによって、前記第１システムと前記第２システムとの間に保留中通信パスがあるかどうかを判定し、前記保留中リストは、前記第１システムが既に前の接続要求メッセージを送信した先のシステムのそれぞれの識別子を記憶することを特徴とする請求項１に記載の方法。
5. 前記第１システムは、前記第１システムの存在フラグを検査することによって、前記第１システムが退去の過程にあるかどうかを判定し、前記存在フラグは、退去メッセージが前記第１システムから送信されるときに更新されることを特徴とする請求項１に記載の方法。
6. 前記参加受入メッセージの送信は、さらに、前記会議が最大数の会議メンバをまだ有していないことの判定に基づくことを特徴とする請求項１に記載の方法。
7. 会議メンバの前記最大数は、会議イニシエータによって構成されることを特徴とする請求項６に記載の方法。
8. 前記最大数は、現在のインターネット帯域幅状態に基づくことを特徴とする請求項６に記載の方法。
9. 前記会議が最大数の会議メンバをまだ有していないことの判定は、メンバリストおよび保留中リストの両方にリストされたメンバの数を、会議メンバの前記最大数と比較することを含むことを特徴とする請求項６に記載の方法。
10. 前記最大数は、デフォルト値であることを特徴とする請求項６に記載の方法。
11. 前記接続要求メッセージを送信することによって、前記会議のメンバになり、参加プロセスを開始するように前記第２システムを勧誘するために、インターネットインスタントメッセージを前記第２システムに送信することをさらに備えることを特徴とする請求項１に記載の方法。
12. 前記インターネットインスタントメッセージは、会議識別子を含むことを特徴とする請求項１１に記載の方法。
13. 前記接続要求メッセージおよび前記参加メッセージは、前記会議識別子を含むことを特徴とする請求項１２に記載の方法。
14. 請求項１に記載の処理を実行するコンピュータ実行可能命令を有することを特徴とするコンピュータ可読媒体。
15. フルメッシュアーキテクチャをサポートする分散マルチパーティ会議の会議メンバの間の通信パスを制御する方法であって、
    第１システムから第２システムに接続要求メッセージを送信することであって、前記第２システムは、前記マルチパーティ会議の既存メンバであること、
    前記第２システムから受信された接続肯定応答に応答して、前記第２システムに関連する識別子を用いて、前記第１システムで保留中リストを更新することであって、前記保留中リストは、前記第１システムと前記第２システムとの間で重複するチャネルが確立されないようにするのに使用されること、
    前記第１システムから前記第２システムに参加メッセージを送信すること、
    前記第１システムと前記第２システムとの間の通信パスが確立されたことを示す参加受入メッセージを前記第２システムから受信すること、および
    前記第２システムとの前記通信パスがもはや保留中でないことを反映するように、前記第１システムで前記保留中リストを更新すること
    を備えることを特徴とする方法。
16. 前記参加受入メッセージは、現在前記マルチパーティ会議にいる会議メンバを識別するメンバリストを含むことを特徴とする請求項１５に記載の方法。
17. 前記第１システムは、前記メンバリスト内で識別される前記会議メンバのそれぞれに別々の接続要求メッセージを送信することによって、各会議メンバとの参加プロセスを開始し、これにより前記分散マルチパーティ会議のフルメッシュアーキテクチャを維持することを特徴とする請求項１６に記載の方法。
18. 前記接続要求メッセージを送信することによって、前記会議のメンバになり、参加プロセスを開始するように前記第１システムを勧誘するインターネットインスタントメッセージを前記第２システムから受信することをさらに備えることを特徴とする請求項１５に記載の方法。
19. 前記インターネットインスタントメッセージは、会議識別子を含むことを特徴とする請求項１８に記載の方法。
20. 前記接続要求メッセージおよび前記参加メッセージは、前記会議識別子を含むことを特徴とする請求項１９に記載の方法。
21. 請求項１５に記載の処理を実行するコンピュータ実行可能命令を有することを特徴とするコンピュータ可読媒体。
22. プロセッサと、
    １つまたは複数のプログラムモジュールがロードされるメモリと
    を備えるシステムであって、前記プログラムモジュールは、メッシュアーキテクチャを使用する分散マルチパーティ会議を制御することを担い、
    会議制御プロトコルをサポートする会議制御モジュールを含み、前記会議制御プロトコルは、
    マルチパーティ会議に参加する許可を求める接続要求メッセージと、
    前記接続要求メッセージを許可する接続肯定応答メッセージと、
    ２つのシステムの間の通信パスを開始する参加メッセージと、
    前記２つのシステムの間の前記通信パスを最終的に承認する参加受入メッセージと
    を有することを特徴とするシステム。
23. 前記会議制御モジュールは、さらに、保留中リストを維持することをサポートし、前記保留中リストは、前記接続要求メッセージが既存システムに送信されるときに、前記既存システムの識別子を前記保留中リストに追加することによって更新されることを特徴とする請求項２２に記載のシステム。
24. 前記保留中リストに対する更新は、前記接続肯定応答メッセージおよび接続拒絶メッセージに基づいて行われることを特徴とする請求項２３に記載のシステム。
25. 前記会議制御モジュールは、さらに、メンバリストを維持することをサポートし、前記メンバリストは、前記マルチパーティ会議の各会議メンバをリストし、前記メンバリストは、退去メッセージを受信する時または前記通信パスを最終的に承認する前記参加受入メッセージを受信する際に更新されることを特徴とする請求項２２に記載のシステム。
26. 前記会議制御モジュールは、さらに、システムが前記マルチパーティ会議から退去する過程にあることを示す存在フラグを維持することをサポートし、前記存在フラグは、前記退去メッセージに関連して更新されることを特徴とする請求項２２に記載のシステム。
27. 前記プログラムモジュールは、前記マルチパーティ会議への参加または退去に関するユーザ要求を処理するように構成されたユーザインターフェースをさらに含むことを特徴とする請求項２２に記載のシステム。
28. 前記プログラムモジュールは、前記会議制御モジュールがメッセージングサービスと通信できるようにするメッセージングサービスインターフェースをさらに含むことを特徴とする請求項２２に記載のシステム。
29. 前記ユーザインターフェースは、前記メッセージングサービスからインスタントメッセージを受信するように構成され、前記インスタントメッセージは、前記会議制御プロトコルを開始するようにシステムを勧誘することを特徴とする請求項２８に記載のシステム。
    

Images