JP2005513875A - テレビ会議システムにおいて非公開会話チャネルを提供するための方法およびシステム - Google Patents

Abstract

少なくとも３人の参加者（１３０、１３２、１３４）間のテレビ会議セッションにおいて、非公開会話チャネルを提供する方法は、非公開招待に応答した非公開受諾を受信するステップと、非公開会話のメンバでない者を、非公開会話に対応する非公開メッセージを受信できないように除外するステップとを含んでいる。

Description

（関連出願の相互参照）
本明細書は、２００１年１２月１５日出願の「ＭＥＴＨＯＤ ＡＮＤ ＳＹＳＴＥＭ ＦＯＲ ＰＲＯＶＩＤＩＮＧ Ａ ＰＲＩＶＡＴＥ ＣＯＮＶＥＲＳＡＴＩＯＮ ＣＨＡＮＮＥＬ ＩＮ Ａ ＶＩＤＥＯＣＯＮＦＥＲＥＮＣＩＮＧ ＳＹＳＴＥＭ」という名称の仮出願第６０／３４１，７９９号、ＰＵ０１０３１０号の利益を、米国特許法第１１９条に従って請求する本出願である。また、本願は、本願の譲受人に譲渡された２００１年１２月１５日出願の「ＶＩＤＥＯ ＣＯＮＦＥＲＥＮＣＩＮＧ ＢＡＮＤＷＩＤＴＨ ＳＥＬＥＣＴＩＯＮ ＭＥＣＨＡＮＩＳＭ」という名称の仮出願第６０／３４１，７２０号と、本願の譲受人に譲渡された２００１年１２月１５日出願の「ＱＵＡＬＩＴＹ ＯＦ ＳＥＲＶＩＣＥ ＳＥＴＵＰ ＯＮ Ａ ＴＩＭＥ ＲＥＳＥＲＶＡＴＩＯＮ ＢＡＳＩＳ」という名称の仮出願第６０／３４１，６７１号と、本願の譲受人に譲渡された２００１年１２月１５日出願の「ＶＩＤＥＯ ＣＯＮＦＥＲＥＮＣＩＮＧ ＣＡＬＬ ＳＥＴＵＰ ＭＥＴＨＯＤ」という名称の仮出願第６０／３４１，７９７号と、本願の譲受人に譲渡された２００１年１２月１５日出願の「ＶＩＤＥＯＣＯＮＦＥＲＥＮＣＥ ＳＥＳＳＩＯＮ ＳＷＩＴＣＨＩＮＧ ＦＲＯＭ ＵＮＩＣＡＳＴ ＴＯ ＭＵＬＴＩＣＡＳＴ」という名称の仮出願第６０／３４１，８００号と、本願の譲受人に譲渡された２００１年１２月１５日出願の「ＳＥＲＶＥＲ ＩＮＶＯＫＥＤ ＴＩＭＥ ＳＣＨＥＤＵＬＥＤ ＶＩＤＥＯ ＣＯＮＦＥＲＥＮＣＥ」という名称の仮出願第６０／３４１，８１９号と、本願の譲受人に譲渡された２００１年１２月１５日出願の「ＶＩＤＥＯＣＯＮＦＥＲＥＮＣＥ ＡＰＰＬＩＣＡＴＩＯＮ ＵＳＥＲ ＩＮＴＥＲＦＡＣＥ」という名称の仮出願第６０／３４１，８０１号と、２００２年３月２０日出願の「ＶＩＤＥＯＣＯＮＦＥＲＥＮＣＥ ＳＹＳＴＥＭ ＡＲＣＨＩＴＥＣＴＵＲＥ」という名称の仮出願第６０／３６６，３３１号にも関連する。

本発明は一般にテレビ会議（ｖｉｄｅｏｃｏｎｆｅｒｅｎｃｅ）に関し、より詳細には、テレビ会議システムにおいて非公開会話チャネルを提供するための方法およびシステムに関する。

複数ユーザー（例えば、３人以上のユーザー）による従来のテレビ会議システムでは、１つの参加者ノードからの音声ストリームおよびビデオ・ストリームが、会議通話に関与している他の参加者全員に送信される。全ての参加者ノードからの音声ストリームは、システム内で重ねられて参加者全員に送信されるものとしてもよく、或いは、合成は各受信機で行われてもよい。一方、ビデオ・ストリームは、別個の伝送チャネル上で参加者全員に伝送される。参加者は、視聴のために復号するビデオ・ストリームを選択する。このような場合、参加者には、自分自身を含めた全ての参加者の会話が聞こえることになる。

しかし、少数の参加者が内輪で非公開の（ｐｒｉｖａｔｅ：秘密の）会話をしたい場合は、非常に多い。これらの参加者は、様々な場所、位置からテレビ会議に加わる。従って、通常の音声チャネルを介して搬送される全員の声が聞こえてしまうことから、これらの参加者は、テレビ会議の音声／ビデオ・チャネルを自分たちの非公開会話に使用することはできない。

従って、テレビ会議通話における選択された参加者のための非公開音声チャネルを提供することが望ましく、また非常に有利である。

（発明の概要）
上述の問題並びに従来技術におけるその他の関連する問題は、本発明、即ちテレビ会議システムにおいて非公開会話チャネルを提供するための方法およびシステムにより解決される。

有利なことに、本発明は、テレビ会議セッションの参加者の何人かの間に、チャット・ルーム（ｃｈａｔ ｒｏｏｍ）ベースの非公開会話チャネルを提供する。テレビ会議アプリケーション内の組込みチャット・ルームは、公開（ｐｕｂｌｉｃ:パブリック）と非公開（ｐｒｉｖａｔｅ：プライベート）の２つの通信チャネルを有する。公開チャネルは、全ての音声ストリームおよびビデオ・ストリームを搬送し、テレビ会議セッションの参加者全員に利用可能である。参加者には、他のどの参加者からの音声も聞こえ、そのビデオが見える。参加者全員の間で行われる会話を、公開会話と呼ぶ。対照的に、参加者全員のうちの一部（サブセット）の間で行われる会話は、非公開会話と呼ぶ。テレビ会議セッション中に非公開会話を実現するために、幾つかのチャット・ルーム・ベースの非公開会話チャネルをテレビ会議セッション中に生成することができる。参加者は、自分の好きなように選択ユーザー間で情報を伝えることができる。

本発明の一態様によれば、少なくとも３人の参加者間のテレビ会議セッションにおいて非公開会話チャネルを生成する方法が提供される。この方法は、非公開会話に加わるよう誘う非公開招待を送信するステップと、非公開招待に応答した非公開受諾を受信するステップと、非公開会話のメンバでない者を、非公開会話に対応する非公開メッセージを受信できないように除外するステップとを含んでいる。

本発明の別の態様によれば、少なくとも３人の参加者間のテレビ会議セッションにおいて非公開会話チャネルを生成するためのシステムが提供される。このシステムは、非公開会話に加わるよう誘う非公開招待を送信する手段と、非公開招待に応答して非公開受諾を送信する手段と、非公開会話のメンバでない者を、非公開会話に対応する非公開メッセージを受信できないように除外する手段とを備えている。

本発明のこれらおよび他の態様、特徴、および利点は、添付の図面と共に読むべき、好ましい実施例に関する以下の詳細な説明から明らかになるであろう。

本発明は、テレビ会議システムにおいて非公開会話チャネルを提供するための方法およびシステムを対象とする。

本発明は、様々な形式のハードウェア、ソフトウェア、ファームウェア、専用処理回路、またはこれらの組合せにおいて実現できることを理解されたい。好ましくは、本発明はハードウェアとソフトウェアの組合せとして実現される。更に、ソフトウェアは、プログラム記憶装置上に有形に具体化されたアプリケーション・プログラムとして実現されることが好ましい。アプリケーション・プログラムは、任意の適当なアーキテクチャを構成するコンピュータにアップロードして実行する。コンピュータは、１つまたは複数の中央処理装置（ＣＰＵ）、ランダム・アクセス・メモリ（ＲＡＭ）、入出力（Ｉ／Ｏ）インタフェースなどのハードウェアを有するコンピュータ・プラットフォーム上で実現されることが好ましい。また、コンピュータ・プラットフォームは、オペレーティング・システムおよびマイクロ命令コードも備えている。本明細書に述べる様々な処理および機能は、マイクロ命令コードの一部またはアプリケーション・プログラムの一部（或いはこれらの組合せ）とすることができ、これはオペレーティング・システムを介して実行される。更に、コンピュータ・プラットフォームには、追加のデータ記憶装置や印刷装置など、その他の様々な周辺装置を接続できる。

更に、添付の図に示す、構成要素をなすシステム構成要素および方法ステップの幾つかはソフトウェアで実現することが好ましいので、システム構成要素（または処理ステップ）間の実際の接続関係は、本発明がプログラムされる方式に応じて異なる場合があることを理解されたい。本明細書の開示があれば、当業者なら、本発明に関するこれらおよび類似の実現形態または構成を考案することができるであろう。

図１Ａは、本発明の説明に役立つ一実施例による、本発明を適用することのできるコンピュータ・システム１００を示すブロック図である。コンピュータ処理システム１００は、システム・バス１０４を介して他の構成要素に動作可能になるように結合された少なくとも１つの処理回路（ＣＰＵ）１０２を備えている。システム・バス１０４には、読出し専用メモリ（ＲＯＭ）１０６、ランダム・アクセス・メモリ（ＲＡＭ）１０８、表示アダプタ１１０、入出力（Ｉ／Ｏ）アダプタ１１２、ユーザー・インタフェース・アダプタ１１４、音声アダプタ１９９、ネットワーク・アダプタ１９８が動作可能になるように結合されている。

表示装置１１６が、表示アダプタ１１０によりシステム・バス１０４に動作可能になるように結合されている。ディスク記憶装置（例えば磁気または光ディスク記憶装置）１１８が、Ｉ／Ｏアダプタ１１２によりシステム・バス１０４に動作可能になるように結合されている。

マウス１２０およびキーボード１２２が、ユーザー・インタフェース・アダプタ１１４によりシステム・バス１０４に動作可能になるように結合されている。マウス１２０およびキーボード１２２は、システム１００との間で情報を入出力するのに使用される。

少なくとも１つのスピーカ（以下、「スピーカ」とする）１９７が、音声アダプタ１９９によりシステム・バス１０４に動作可能になるように結合されている。

（ディジタルおよび／またはアナログ）モデム１９６が、ネットワーク・アダプタ１９８によりシステム・バス１０４に動作可能になるように結合されている。

次に、本発明の説明に役立つ一実施例による、ポリシー・ベース・ネットワーク管理（ＰＢＮＭ：Ｐｏｌｉｃｙ Ｂａｓｅｄ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ）について述べる。ＰＢＮＭは、ネットワークを管理するためのポリシーを定義および配布する機能をもたらす技術である（本発明を適用することのできる例示的なネットワークについては図２に関連して後述する）。これらのポリシーにより、帯域幅やセキュリティなどのクリティカル（ｃｒｉｔｉｃａｌ：重大な、重要な、決定的な）なネットワーク・リソース（資源）を協調的に制御する。ＰＢＮＭは、ＩＰベースのテレビ会議など、ネットワーク上で差別化して扱う必要のあるアプリケーションを利用可能にする。ＰＢＮＭは、種々のタイプのアプリケーションが単一のネットワーク上で共存できるようにするための基盤を提供し、必要なリソースをこれらの各アプリケーションに提供する。

更に詳細には、ポリシー・ベース・ネットワーク管理（ＰＢＮＭ）は、ネットワーク・リソースを消費するアプリケーションおよびユーザーに対してポリシーを定義する。例えば、ビジネス・クリティカルなアプリケーションには、ネットワーク上で最高の優先順位および帯域幅割合を与え、テレビ会議およびボイス・オーバーＩＰ（ＶｏＩＰ）には、次に高い優先順位を与え、最後に、厳しい帯域幅クリティカルなまたは時間クリティカルな制約を持たないウェブ（Ｗｅｂ）トラフィックおよびファイル転送には、ネットワーク上の残りのリソース量を与えることができる。ＰＢＮＭを使用して、このようなユーザーおよびアプリケーションの差別化を達成する。

テレビ会議システムは、テレビ会議アプリケーションに対応するポリシーをネットワーク・ポリシー・サーバに照会することにより、ポリシー・ベース・ネットワーク管理（ＰＢＮＭ）システムに繋がる。テレビ会議サーバは、ネットワーク・ポリシー・サーバからポリシーを入手し、受け取ったパラメータに基づいて、テレビ会議に利用可能なネットワーク中のリソースを決定する。通常、ポリシーは、例えば、一日のうちの一定の時間帯にこのアプリケーションに利用可能な帯域幅、または一定のユーザーだけに利用可能な帯域幅に対応するものになる。この構成は、例えばポリシーおよび／またはその一部を追加、削除、置換、変更することなどにより、容易に変更される。この結果、テレビ会議サーバは、ポリシー中で提供された情報を使用してネットワーク上の会議セッションを管理することになる。

図２は、本発明の説明に役立つ一実施例による、本発明を適用することのできるネットワーク２００を示すブロック図である。ネットワーク２００は、テレビ会議サーバ２０５、ポリシーおよびサービス品質（ＱｏＳ：Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）マネージャ２１０、ＭＡＤＣＡＰサーバ２１５、第１の複数のコンピュータ２２０ａ〜ｆ、第１のローカル・エリア・ネットワーク２２５、第１のルータ２４０、第２の複数のコンピュータ２３０ａ〜ｅ、第２のローカル・エリア・ネットワーク２３５、第２のルータ２４５、広域ネットワーク２５０を含んでいる。

次に、本発明の説明に役立つ一実施例によるサーバ・アーキテクチャについて述べる。図３は、本発明の説明に役立つ一実施例による、図２のテレビ会議サーバ２０５を示すブロック図である。テレビ会議サーバ２０５は、３つの基本構成要素、即ちデータベース構成要素３０２、ネットワーク通信構成要素３０４、セッション管理構成要素３０６を備えるものと考えることができる。

セッション管理構成要素３０６は、テレビ会議セッションのセットアップおよび終了を管理することを担う。また、セッション管理構成要素３０６は、テレビ会議サーバ２０５に関する主要な制御のほとんどを提供する。セッション管理構成要素３０６は、セッション管理構成要素３０６の機能を実施するためのセッション・マネージャ３２０を備えている。

ネットワーク通信構成要素３０４は、テレビ会議システムに使用される多くの様々なプロトコルをカプセル化することを担う。プロトコルには、リモート監理および管理のためのシンプル・ネットワーク管理プロトコル（ＳＮＭＰ：Ｓｉｍｐｌｅ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）、ポリシー管理のためのコモン・オープン・ポリシー・サービス（ＣＯＰＳ、Ｃｏｍｍｏｎ Ｏｐｅｎ Ｐｏｌｉｃｙ Ｓｅｒｖｉｃｅｓ）または別のプロトコル（簡易（ライトウェイト）ディレクトリ・アクセス・プロトコル（ＬＤＡＰ、Ｌｉｇｈｔｗｅｉｇｈｔ Ｄｉｒｅｃｔｏｒｙ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）など）、同報通信割振りのための同報通信アドレス動的クライアント割振りプロトコル（ＭＡＤＣＡＰ：Ｍｕｌｔｉｃａｓｔ Ａｄｄｒｅｓｓ Ｄｙｎａｍｉｃ Ｃｌｉｅｎｔ Ａｌｌｏｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）、テレビ会議セッション管理のためのセッション開始プロトコル（ＳＩＰ、Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）、分散テレビ会議サーバ管理のためのサーバ間メッセージングを含めることができる。従って、ネットワーク通信構成要素３０４は、ＳＮＭＰモジュール３０４ａ、ＬＤＡＰクライアント・モジュール３０４ｂ、ＭＡＤＣＡＰクライアント・モジュール３０４ｃ、ＳＩＰモジュール３０４ｄ、サーバ間管理（ｓｅｒｖｅｒ−ｔｏ−ｓｅｒｖｅｒ ｍａｎａｇｅｍｅｎｔ）モジュール３０４ｅを備えている。更に、これらの要素３０４ａ〜ｅはそれぞれ、リモート監理端末３８２、ネットワーク・ポリシー・サーバ（帯域幅ブローカ）３８４、ＭＡＤＣＡＰサーバ２１５、デスクトップ会議クライアント３８８、他のテレビ会議サーバ３９０の各要素と通信する。このような通信は、伝送制御プロトコル（ＴＣＰ）、ユーザー・データグラム・プロトコル（ＵＤＰ）、インターネット・プロトコル（ＩＰ）も使用して実現することができ、これらは一括してプロトコル・モジュール３３０で表す。これらのプロトコルおよび対応する要素は例示にすぎず、従って、本発明の趣旨および範囲を維持しながら、その他のプロトコルおよび対応する要素も容易に採用することができることを理解されたい。

更に、テレビ会議サーバ２０５のアーキテクチャは、ポータブル・デバイス上のユーザーが仮想私設ネットワーク（ＶＰＮ）を介して企業インフラストラクチャに接続し、テレビ会議セッションに対してコンテンツを送受信するのにも適していることを理解されたい。

データベース構成要素３０２は、４つのデータベース、即ちスケジューリング・データベース３１０、アクティブ・セッション・データベース３１２、メンバ・データベース３１４、およびネットワーク・アーキテクチャ・データベース３１６を備えている。

テレビ会議システム・サーバ２０５は更に、会社の簡易ディレクトリ・アクセス・プロトコル（ＬＤＡＰ）サーバ（ユーザー情報）３４０およびオプション外部データベース３４２を備えるか、または少なくともこれらとインタフェースする。オプション外部データベース３４２は、ＬＤＡＰクライアント３０４ｂを備えている。

次に、本発明の説明に役立つ一実施例による、図３のデータベース構成要素３０２に備わるメンバ・データベース３１４について述べる。メンバ・データベース３１４は、テレビ会議システムにログインした各ユーザーに関する情報を含んでいる。例えば、メンバ・データベース３１４中には、各ユーザーについて以下の情報を保持する。即ち、ユーザー名、パスワード（適用可能なら）、サポートされるビデオ・コーデックおよびキャプチャ解像度、サポートされる音声コーデック、現在のＩＰアドレス、現在の呼番号（現在アクティブな呼のメンバである場合）、利用可能性（利用可能か利用不可能か）、ビデオ・カメラのタイプおよびモデル、ネットワーク上の位置（各位置は限られた帯域幅の広域ネットワーク・リンクで接続される）、ＣＰＵのタイプおよび処理能力である。これらの項目は例示にすぎず、従って、本発明の趣旨および範囲を維持しながら、これらの項目の幾つかまたは全てに加えて、またはそれに代えて、他の項目を各ユーザーについてメンバ・データベース３１４中に保持することもできることを理解されたい。

図４は、本発明の説明に役立つ一実施例による、図３のデータベース構成要素３０２に備わるメンバ・データベース３１４のメンバ・データベース項目４００を示す図である。説明に役立つ図４の実施例では、メンバ・データベース３１４は単純なリンクリストを使用して実現されている。ただし、本発明の他の実施例では、本発明の趣旨および範囲を維持しながら、メンバ・データベース３１４の異なる実現形態を採用することもできることを理解されたい。例えば、ＬＤＡＰタイプのデータベースを使用してメンバ情報を記憶してもよい。

次に、本発明の説明に役立つ一実施例による、図３のデータベース構成要素３０２に備わるアクティブ・セッション・データベース３１２について述べる。アクティブ・セッション・データベース３１２は、現在行われている各テレビ会議セッションに関する情報を含んでいる。例えば、アクティブ・セッション・データベース３１２中には、各呼について以下の情報を保持する。即ち、呼ＩＤ、説明、同報通信（ｙｅｓ／ｎｏ）、同報通信の場合は同報通信ＩＰアドレス、各参加者についてのネットワーク位置、現在の伝送解像度、現在の伝送ビット・レート、ビデオ・コーデックおよび音声コーデック、公開呼（ｐｕｂｌｉｃ ｃａｌｌ）／秘密呼（ｐｒｉｖａｔｅ ｃａｌｌ）（他者が参加できるかどうか）、セッション予定時間、セッション開始時間、任意の追加オプションである。これらの項目は例示にすぎず、従って、本発明の趣旨および範囲を維持しながら、これらの項目の幾つかまたは全てに加えて、またはそれに代えて、他の項目をアクティブ・セッション・データベース３１２中に保持することもできることを理解されたい。

図５は、本発明の説明に役立つ一実施例による、図３のデータベース構成要素３０２に備わるアクティブ・セッション・データベース３１２中のアクティブ・セッション項目５００を示すブロック図である。説明に役立つ図５の実施例では、アクティブ・セッション・データベース３１２は単純なリンクリストを使用して実現されている。ただし、本発明の他の実施例では、本発明の趣旨および範囲を維持しながら、アクティブ・セッション・データベース３１２の異なる実現形態を採用することもできることを理解されたい。

次に、再び図３を参照しながら、本発明の説明に役立つ一実施例による、図３のデータベース構成要素３０２に備わるネットワーク・アーキテクチャ・データベース３１６について述べる。ネットワーク・アーキテクチャ・データベース３１６は、ネットワーク全体の完全なマッピングを含んでいる。ネットワーク・アーキテクチャ・データベース３１６は、アクティブな各ネットワーク要素（即ち、ＩＰルータやイーサネット（登録商標）スイッチなど）に関する情報と、ルータおよびスイッチを共に接続するリンクに関する情報を含んでいる。ネットワーク中の帯域幅およびサービス品質を効果的に管理するために、テレビ会議サーバ２０５はこの情報を知る必要がある。

ネットワーク・アーキテクチャ・データベース３１６中では、同時に行うことが許容されるテレビ会議セッションの数、テレビ会議セッションのビット・レート、帯域幅制限に関して、ポリシー情報を定義することもできる。ネットワーク・アーキテクチャ・データベース３１６内では、ネットワーク・アーキテクチャを重み付きグラフとして表すことができる。ネットワーク・アーキテクチャ・データベース３１６は、テレビ会議サーバ２０５中のオプションのデータベースであることを理解されたい。ネットワーク・アーキテクチャ・データベース３１６を使用して、ポリシー・サーバ２１０に要求されるポリシーをキャッシュする。

次に、本発明の説明に役立つ一実施例による、図３のデータベース構成要素３０２に備わるスケジューリング・データベース３１０について述べる。スケジューリング・データベース３１０は、テレビ会議システムを使用する時間をユーザーが予約するためのスケジュールを含んでいる。これはポリシーに依存する。例えば、広域ネットワーク２５０を介した一定のリンク上で同時に行うことのできるテレビ会議セッションの数に関して情報システム部門が適所で有するポリシーに依存する。

次に、図３のネットワーク通信構成要素３０４について述べる。ネットワーク通信構成要素３０４は、シンプル・ネットワーク管理プロトコル（ＳＮＭＰ）モジュール３０４ａ、簡易ディレクトリ・アクセス・プロトコル（ＬＤＡＰ）クライアント・モジュール３０４ｂ、同報通信アドレス動的クライアント割振りプロトコル（ＭＡＤＣＡＰ）クライアント・モジュール３０４ｃ、セッション開始プロトコル（ＳＩＰ）モジュール３０４ｄ、サーバ間管理モジュール３０４ｅを備えている。

次に、本発明の説明に役立つ一実施例による、図３のネットワーク通信構成要素３０４に備わるシンプル・ネットワーク管理プロトコル（ＳＮＭＰ）モジュール３０４ａについて述べる。図６は、本発明の説明に役立つ一実施例による、シンプル・ネットワーク管理プロトコル（ＳＮＭＰ）クライアント−サーバ・アーキテクチャ６００を示すブロック図である。アーキテクチャ６００はＳＮＭＰモジュール３０４ａの一実現形態を表すが、本発明は図６に示すアーキテクチャに限定されず、従って、本発明の趣旨および範囲を維持しながら、他のＳＮＭＰアーキテクチャを採用することもできることを理解されたい。ＳＮＭＰは、テレビ会議サーバのリモート監理および監視に使用される。

シンプル・ネットワーク管理プロトコル（ＳＮＭＰ）クライアント−サーバ・アーキテクチャ６００は、ＳＮＭＰ管理局６１０およびＳＮＭＰ被管理構成要素６２０を含んでいる。ＳＮＭＰ管理局６１０は、管理アプリケーション６１０ａおよびＳＮＭＰマネージャ６１０ｂを備えている。ＳＮＭＰ被管理構成要素６２０は、被管理リソース６２０ａ、ＳＮＭＰ被管理オブジェクト６２０ｂ、ＳＮＭＰエージェント６２０ｃを備えている。更に、ＳＮＭＰ管理局６１０およびＳＮＭＰ被管理構成要素６２０はそれぞれ、ＵＤＰ層６３０、ＩＰ層６４０、媒体アクセス制御（ＭＡＣ）層６５０、物理層６６０も備えている。

シンプル・ネットワーク管理プロトコル（ＳＮＭＰ）エージェント６２０ｃは、ＳＮＭＰ管理局６１０からの監視および監理を可能にする。ＳＮＭＰエージェント６２０ｃは、ＳＮＭＰアーキテクチャ６００中のクライアントである。ＳＮＭＰエージェント６２０ｃは基本的に、情報およびアクションを求めるＳＮＭＰ管理局６１０からの要求に応答する役割を担う。ＳＮＭＰ管理局６１０は、ＳＮＭＰアーキテクチャ６００中のサーバである。ＳＮＭＰ管理局６１０は、ネットワーク中のエージェントを管理する中央構成要素である。ＳＮＭＰ管理局６１０は、管理者がＳＮＭＰエージェント６２０ｃから統計を収集し、ＳＮＭＰエージェント６２０ｃの構成パラメータを変更することを可能にする。

シンプル・ネットワーク管理プロトコル（ＳＮＭＰ）モデルを使用した場合、テレビ会議サーバ２０５中のリソース（資源）をオブジェクトとして表すことにより、これらのリソースを管理する。各オブジェクトは、被管理エージェントの特徴の１つを表すデータ変数である。このオブジェクト集合は、一般に管理情報ベース（ＭＩＢ：Ｍａｎａｇｅｍｅｎｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｂａｓｅ）と呼ばれる。ＭＩＢは、ＳＮＭＰ管理局６１０に対する、ＳＮＭＰエージェント６２０ｃにおけるアクセス・ポイントの集合として機能する。ＳＮＭＰ管理局６１０は、ＳＮＭＰエージェント６２０ｃ中のＭＩＢオブジェクトの値を取り出すことにより監視を行うことができる。ＳＮＭＰ管理局６１０はまた、ＳＮＭＰエージェント６２０ｃにおいてアクションが行われるようにすることができ、或いはＳＮＭＰエージェント６２０ｃにおける構成設定を変更する。

シンプル・ネットワーク管理プロトコル（ＳＮＭＰ）は、ＩＰ層６４０を介して動作し、そのトランスポート・プロトコルのためにＵＤＰ層６３０を使用する。

シンプル・ネットワーク管理プロトコル（ＳＮＭＰ）で使用される基本的なメッセージは、ＧＥＴ、ＳＥＴ、ＴＲＡＰである。ＧＥＴメッセージは、ＳＮＭＰ管理局６１０がＳＮＭＰエージェント６２０ｃにおけるオブジェクトの値を取り出すことを可能にする。ＳＥＴメッセージは、ＳＮＭＰ管理局６１０がＳＮＭＰエージェント６２０ｃにおけるオブジェクトの値を設定することを可能にする。ＴＲＡＰメッセージは、ＳＮＭＰエージェント６２０ｃがＳＮＭＰ管理局６１０に重要なイベントを通知することを可能にする。

次に、本発明の説明に役立つ一実施例による、シンプル・ネットワーク管理プロトコル（ＳＮＭＰ）構成要素６２０に備わるＳＮＭＰ被管理リソース６２０ａについて述べる。リモート監理は、テレビ会議サーバ２０５内の以下のリソースを監視および／または制御する。即ち、アクティブ・セッションおよび関連する統計と、セッション・ログと、テレビ会議のためのネットワーク・ポリシーと、セッション開始プロトコル（ＳＩＰ）パラメータおよび統計と、同報通信アドレス動的クライアント割振りプロトコル（ＭＡＤＣＡＰ）パラメータおよび統計である。

シンプル・ネットワーク管理プロトコル（ＳＮＭＰ）管理局６１０から、管理アプリケーションに代わってＧｅｔＲｅｑｕｅｓｔ、ＧｅｔＮｅｘｔＲｅｑｕｅｓｔ、ＳｅｔＲｅｑｕｅｓｔの３つのタイプのＳＮＭＰメッセージが発行される。最初の２つは、ＧＥＴ関数の変形である。３つのメッセージは全て、ＳＮＭＰエージェント６２０ｃによりＧｅｔＲｅｓｐｏｎｓｅメッセージの形式で肯定応答され、このメッセージは、上方の管理アプリケーション６１０ａに渡される。また、ＳＮＭＰエージェント６２０ｃは、被管理リソース中で生じたイベントに応答してＴＲＡＰメッセージを発行することもできる。

次に、再び図３を参照しながら、本発明の説明に役立つ一実施例による、図３のネットワーク通信構成要素３０４に備わる簡易ディレクトリ・アクセス・プロトコル（ＬＤＡＰ）クライアント・モジュール３０４ｂについて述べる。ＬＤＡＰモジュール３０４ｂは、共通ディレクトリ情報にアクセスするための標準的なＩＰベースのプロトコルであるＬＤＡＰを利用する。ＬＤＡＰは、ユーザー特有の基準を満たす項目の検索、項目の追加、項目の削除、項目の変更、項目の比較など、ディレクトリ項目に対するアクセスおよび変更を行うための動作を定義する。

次に、本発明の説明に役立つ一実施例による、図３のネットワーク通信構成要素３０４に備わる同報通信アドレス動的クライアント割振りプロトコル（ＭＡＤＣＡＰ）クライアント・モジュール３０４ｃについて述べる。ＭＡＤＣＡＰモジュール３０４ｃは、ホストが同報通信アドレス割振りサーバに同報通信アドレス割振りサービスを要求することを可能にするプロトコルであるＭＡＤＣＡＰを利用する。同報通信サービスを利用するためにテレビ会議セッションがセットアップされるとき、テレビ会議サーバ２０５は、セッション内のクライアントに割り振るための同報通信アドレスを得る必要がある。テレビ会議サーバ２０５は、ＭＡＤＣＡＰプロトコルを使用して、同報通信アドレスを同報通信アドレス割振りサーバから動的に得ることができる。

次に、本発明の説明に役立つ一実施例による、図３のネットワーク通信構成要素３０４に備わるセッション開始プロトコル（ＳＩＰ）モジュール３０４ｄについて述べる。ＳＩＰモジュール３０４ｄは、ＩＰベースのネットワーク上にいる１人または複数の参加者とのマルチメディア・セッションを生成、変更、終了するためのアプリケーション層制御プロトコルであるＳＩＰを利用する。ＳＩＰは、文字メッセージ・ベースのプロトコルである。

セッション開始プロトコル（ＳＩＰ）ベースのテレビ会議システムでは、クライアントおよびサーバはそれぞれ、ＳＩＰ ＵＲＬで識別される。ＳＩＰ ＵＲＬはｕｓｅｒ＠ｈｏｓｔの形式をとるが、これは電子メール・アドレスと同じフォーマットであり、ほとんどの場合、ＳＩＰ ＵＲＬはユーザーの電子メール・アドレスである。

次に、本発明の説明に役立つ一実施例による、図３のネットワーク通信構成要素３０４に備わるサーバ間管理モジュール３０４ｅについて述べる。サーバ間管理モジュール３０４ｅは、テレビ会議サーバ間で情報を交換するためのメッセージを利用する。サーバ間管理モジュール３０４ｅは、固有のテレビ会議サーバ（例えばテレビ会議サーバ２０５）がそのサポートするネットワーク（例えばＬＡＮ２２５）にローカルにセットアップされている典型的な配置で利用されることが好ましく、それにより、複数のテレビ会議サーバが会社全体のネットワーク（例えばネットワーク２００）中に存在する。情報交換用メッセージの主な目的の幾つかには、データベースの同期をとること、およびネットワーク・リソースの利用可能性をチェックすることが含まれる。

次のようなメッセージが定義される。
ＱＵＥＲＹ：リモート・サーバ中の項目を照会する。
ＡＤＤ：リモート・サーバに項目を追加する。
ＤＥＬＥＴＥ：リモート・サーバから項目を削除する。
ＵＰＤＡＴＥ：リモート・サーバ上の項目を更新する。

サーバ間メッセージングでは、各サーバ間のＴＣＰベースの接続を使用する。あるサーバの状態が変化したとき、残りのサーバは同じ情報で更新される。

次に、本発明の説明に役立つ一実施例による、テレビ会議サーバ２０５の動作手順について述べる。最初に、テレビ会議セッションのセットアップに対応する動作手順について述べ、その後で、テレビ会議セッションの間の解像度およびフレーム・レート調整に対応する動作手順について述べる。セッション動作手順には、ＳＩＰサーバ発見、メンバ登録、セッション・セットアップ、セッション・キャンセル、セッション終了が含まれる。

次に、本発明の説明に役立つ一実施例による、セッション開始プロトコル（ＳＩＰ）サーバ発見に対応するセッション動作手順について述べる。ユーザー（テレビ会議クライアント・アプリケーション）は、事前構成済みのテレビ会議サーバ（手動でプロビジョニングされた）に登録するか、または起動時にＲＥＧＩＳＴＥＲ要求を周知の「全てのＳＩＰサーバ」の同報通信アドレス「ｓｉｐ．ｍｃａｓｔ．ｎｅｔ」（２２４．０．１．７５）に送信することにより登録する。第２の機構（ＲＥＧＩＳＴＥＲ要求）は、各ユーザーが自分のテレビ会議クライアント・アプリケーション中でローカルＳＩＰサーバのアドレスを手動で構成する必要がないので、好ましい。この場合、ユーザーがテレビ会議のための正しいＳＩＰサーバに登録中であることを保証するために、同報通信アドレスがネットワーク中で正しく探される必要がある。これらの方法に加えて、プロビジョニング処理をより単純にするための別の方法では、管理者が「ｓｉｐ．ドメイン名」規定を使用して自分のＳＩＰサーバに名前を付けることが、ＳＩＰ仕様で推奨されている（例えばｓｉｐ．ｐｒｉｎｃｅｔｏｎ．ｔｃｅ．ｃｏｍ）。

次に、本発明の説明に役立つ一実施例による、メンバ登録に対応するセッション動作手順について述べる。図７は、本発明の説明に役立つ一実施例による、セッション開始プロトコル（ＳＩＰ）を使用してテレビ会議に登録する方法を示す図である。図７の例は、テレビ会議クライアント・アプリケーション（クライアント）７０２、およびテレビ会議サーバ（サーバ）２０５を含んでいる。本明細書では、「クライアント・アプリケーション」と「クライアント」という語句を交換可能に使用することを理解されたい。

メンバ登録機能において、クライアント７０２は、ＳＩＰ ＲＥＧＩＳＴＥＲ要求をサーバ２０５に送信する（ステップ７１０）。サーバ２０５は、このメッセージを受信し、クライアント７０２のＩＰアドレスおよびＳＩＰ ＵＲＬをメンバ・データベース３１４に記憶する。

ＲＥＧＩＳＴＥＲ要求はメッセージ本体を含むことができるが、この使用法は標準方式で定められているわけではない。メッセージ本体は、サーバ２０５に登録中であるクライアント７０２の構成オプションに関係のある追加情報を含んでいてもよい。

サーバ２０５は、クライアント７０２に２００ ＯＫメッセージを返信することにより登録を承認する（ステップ７２０）。

次に、本発明の説明に役立つ実施例による、単一通信および同報通信テレビ会議セッションについて述べる。図１Ｂおよび１Ｃは、本発明の説明に役立つ２つの実施例による、単一通信テレビ会議セッションおよび同報通信テレビ会議セッションをそれぞれ示すブロック図である。図１Ｂおよび１Ｃの例は、クライアント１ １３０、クライアント２ １３２、クライアント３ １３４、イーサネット（登録商標）スイッチ１３６、ＩＰルータ１３８およびＩＰルータ１４０、ＷＡＮ１４２を含んでいる。

単一通信の例では、各クライアントから他方の各クライアント毎に、固有のストリームが送信される。このような手法は、ネットワークに加わる参加者が多くなるにつれて多量の帯域幅を消費する可能性がある。対照的に、同報通信手法では、各クライアントから１つのストリームだけが送信される。従って同報通信手法は、単一通信手法と比較して、帯域幅などのネットワーク・リソースの使用量がより少ない。

次に、本発明の説明に役立つ一実施例による、単一通信テレビ会議セッションのセットアップに対応するセッション動作手順について述べる。図８Ａは、本発明の説明に役立つ一実施例による、セッション開始プロトコル（ＳＩＰ）を使用して単一通信テレビ会議セッションをセットアップする方法を示す図である。図８Ａの例は、テレビ会議クライアント・アプリケーション＃１（クライアント＃１）８０２、テレビ会議サーバ（サーバ）２０５、テレビ会議クライアント・アプリケーション＃２（クライアント＃２）８０６を含んでいる。

ＩＮＶＩＴＥ要求が、クライアント＃１ ８０２からサーバ２０５に送信される（ステップ８１０）。ＩＮＶＩＴＥ要求は、サーバ２０５からクライアント＃２ ８０６に転送される（ステップ８１５）。

１８０Ｒｉｎｇｉｎｇメッセージが、クライアント＃２ ８０６からサーバ２０５に送信される（ステップ８２０）。１８０Ｒｉｎｇｉｎｇメッセージは、サーバ２０５からクライアント＃１ ８０２に転送される（ステップ８２５）。

２００ ＯＫメッセージが、クライアント＃２ ８０６からサーバ２０５に送信される（ステップ８３０）。２００ ＯＫメッセージは、サーバ２０５からクライアント＃１ ８０２に転送される（ステップ８３５）。

肯定応答メッセージＡＣＫが、クライアント＃１ ８０２からクライアント＃２ ８０６に送信される（ステップ８４０）。テレビ会議セッション（メディア・セッション）が、２つのノード（クライアント＃１ ８０２と＃２ ８０６）との間で行われる（ステップ８４５）。

図８Ｂは、本発明の説明に役立つ一実施例による、ＩＮＶＩＴＥ要求がテレビ会議クライアント・アプリケーション＃１ ８０２から受信されたときに（図８Ａのステップ８１０）テレビ会議サーバ２０５により実施されるステップを示す図である。

サーバ２０５はまず、要求元ユーザー（クライアント＃１ ８０２）がサーバ２０５に登録しているかどうかをチェックし、また、呼び出されているユーザー（クライアント＃２ ８０６）がサーバ２０５に登録しているかどうかをチェックする（ステップ８５０）。

サーバ２０５は、ネットワーク上の各ユーザーの位置を決定し（ステップ８５５）、それらの２つの位置（異なる場合）を接続する低帯域幅ＷＡＮリンク（例えばＷＡＮ２５０）があるかどうかを決定する（ステップ８６０）。

２つの位置を共に接続する低帯域幅リンクのＷＡＮがない場合は、サーバ２０５は呼を続行する（ステップ８６５）。しかし、２人のユーザー間に低帯域幅リンクがある場合は、ステップ８７０に進む。

ステップ８７０で、サーバ２０５は、ＷＡＮ２５０上のテレビ会議セッションに対するポリシーをチェックする。これは基本的に、「Ｘ個のセッションを最大ビット・レートＹで実施することができる」と言い換えられる。サーバ２０５は、このポリシーに基づいて利用可能性をチェックする（ステップ８７５）。利用可能性がない場合は、サーバ２０５は、「６００−Ｂｕｓｙ Ｅｖｅｒｙｗｈｅｒｅ（どこもビジー）」、「４８６−Ｂｕｓｙ Ｈｅｒｅ（ここはビジー）」、「５０３−Ｓｅｒｖｉｃｅ Ｕｎａｖａｉｌａｂｌｅ（サービス利用不可）」、「６０３−Ｄｅｃｌｉｎｅ（拒否）」の何れかのメッセージを送信することによりＩＮＶＩＴＥ要求を拒否し（ステップ８８０）、本方法は終了する（図８Ａの方法のステップ８１５に進まない）。しかし、利用可能性がある場合は、サーバ２０５は呼を続行する（ステップ８６５）。ステップ８６５の後に、図８Ａの方法のステップ８１５が続くことを理解されたい。

図９は、本発明の説明に役立つ一実施例による、図８Ａの方法を更に示す図である。図９の例は、クライアント・アプリケーション１ ９９８、クライアント・アプリケーション２ ９９７、テレビ会議サーバ２０５、他のテレビ会議サーバ９８６を含んでいる。図９にはテレビ会議サーバ２０５の要素も示されており、これらには、メンバ・データベース３１４と、アクティブ・セッション・データベース３１２と、ネットワーク・アーキテクチャ・データベース３１６に備わるポリシー・データベース９９９と、セッション・マネージャ３２０と、ＳＩＰモジュール３０４ｄと、サーバ間管理モジュール３０４ｅが含まれる。

図９は、テレビ会議サーバ２０５内の内部対話を示すために提供するものであり、従って、テレビ会議サーバ２０５の構成要素間の情報伝送フローの例を提供するために基本的なレベルでのみ示す。

ＩＮＶＩＴＥ要求が、クライアント・アプリケーション１ ９９８から、テレビ会議サーバ２０５内のＳＩＰモジュール３０４ｄに送信される（ステップ９０３）。ＳＩＰモジュール３０４ｄは、メッセージを復号し、ＩＮＶＩＴＥ要求をセッション・マネージャ３２０に転送する（ステップ９０６）。セッション・マネージャ３２０は、アクティブ・セッション・データベース３１２と、メンバ・データベース３１４と、ネットワーク・アーキテクチャ・データベース３１６内のポリシー・データベース９９９とをチェックして、セッションを正しくセットアップできることを確認する（それぞれステップ９０９、９１２、９１５）。セッションを正しくセットアップすることができる場合は、アクティブ・セッション・データベース３１２、メンバ・データベース３１４、およびポリシー・データベース９９９は、ＯＫメッセージをセッション・マネージャ３２０に送信する（ステップ９１８、９２１、９２４）。この検証処理が完了すると、テレビ会議サーバ２０５は、システム状態の変更を他のテレビ会議サーバに通知する（ステップ９２７および９３０）。

セッション・マネージャ３２０は、ＩＮＶＩＴＥメッセージをＳＩＰモジュール３０４ｄに転送し（ステップ９３３）、次いでＳＩＰモジュール３０４ｄは、ＩＮＶＩＴＥメッセージをクライアント・アプリケーション２ ９９７に転送する（ステップ９３６）。クライアント・アプリケーション２ ９９７は、ＩＮＶＩＴＥメッセージを受信すると、ＳＩＰモジュール３０４ｄがＩＮＶＩＴＥメッセージを受信したことを示す１８０Ｒｉｎｇｉｎｇメッセージにより、ＳＩＰモジュール３０４ｄに応答する（ステップ９３９）。１８０Ｒｉｎｇｉｎｇメッセージは、ＳＩＰモジュール３０４ｄにより受信され、復号され、次いでセッション・マネージャ３２０に転送される（ステップ９４２）。図９に示すテレビ会議サーバ２０５内の各データベース中で、クライアント状態が更新される（ステップ９４５、９４８、９５１、９５４、９５７、９５８）。

１８０Ｒｉｎｇｉｎｇメッセージは、セッション・マネージャ３２０からクライアント・アプリケーション１ ９９８に転送される（ステップ９６０および９６３）。次いで、２００ ＯＫメッセージが、クライアント・アプリケーション２ ９９７からＳＩＰモジュール３０４ｄに送信され（ステップ９６６）、ＳＩＰモジュール３０４ｄからセッション・マネージャ３２０に転送される（ステップ９６９）。２００ ＯＫメッセージは、クライアント・アプリケーション２ ９９７がテレビ会議セッションへの招待を受諾していることを示す。

図９に示すテレビ会議サーバ２０５内の各データベース中で、クライアント状態が更新される（ステップ９７２、９７５、９７８、９８１、９８４、９８５）。ＯＫメッセージが、セッション・マネージャ３２０からＳＩＰモジュール３０４ｄに送信され、ＳＩＰモジュール３０４ｄからクライアント・アプリケーション１ ９９８に転送される（ステップ９８８および９９１）。ＡＣＫメッセージが、クライアント・アプリケーション１ ９９８からクライアント・アプリケーション２ ９９７に送信され、セッションのセットアップが終了する（ステップ９９４）。

次に、本発明の説明に役立つ一実施例による、同報通信テレビ会議セッションのセットアップに対応するセッション動作手順について述べる。同報通信セッションのセットアップを提供するためには、セッション記述プロトコル（ＳＤＰ、Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｏｔｏｃｏｌ）を使用する。ＳＤＰプロトコルは、同報通信アドレスおよびポート番号を搬送する。

同報通信セッションのセットアップは、同報通信アドレスが必要なことを除いては、単一通信セッションのセットアップと同様である。同報通信アドレスは、ネットワーク中のＭＡＤＣＡＰサーバ２１５により割り振られる。

図１０は、本発明の説明に役立つ別の実施例による、セッション開始プロトコル（ＳＩＰ）を使用して同報通信テレビ会議セッションをセットアップする方法を示す図である。図１０の例は、テレビ会議クライアント・アプリケーション＃１（クライアント＃１）１００２、テレビ会議サーバ（サーバ）２０５、テレビ会議クライアント・アプリケーション＃２（クライアント＃２）１００６、ＭＡＤＣＡＰサーバ２１５を含んでいる。

ＩＮＶＩＴＥ要求が、クライアント＃１ １００２からサーバ２０５に送信される（ステップ１０１０）。ＭＡＤＣＡＰ要求が、サーバ２０５からＭＡＤＣＡＰサーバ２１５に送信される（ステップ１０１５）。肯定応答メッセージＡＣＫが、ＭＡＤＣＡＰサーバ２１５からサーバ２０５に送信される（ステップ１０２０）。ＩＮＶＩＴＥ要求は、サーバ２０５からクライアント＃２ １００６に転送される（ステップ１０２５）。

１８０Ｒｉｎｇｉｎｇ（呼出し）メッセージが、クライアント＃２ １００６からサーバ２０５に送信される（ステップ１０３０）。１８０Ｒｉｎｇｉｎｇメッセージは、サーバ２０５からクライアント＃１ １００２に転送される（ステップ１０３５）。

２００ ＯＫメッセージが、クライアント＃２ １００６からサーバ２０５に送信される（ステップ１０４０）。２００ ＯＫメッセージは、サーバ２０５からクライアント＃１ １００２に転送される（ステップ１０４５）。

肯定応答メッセージＡＣＫが、クライアント＃１ １００２からクライアント＃２ １００６に送信される（ステップ１０５０）。テレビ会議セッション（メディア・セッション）が、２つのノード（クライアント＃１ １００２と＃２ １００６）との間で行われる（ステップ１０５５）。

次に、本発明の説明に役立つ一実施例による、テレビ会議セッションのキャンセルに対応するセッション動作手順について述べる。ＣＡＮＣＥＬ（キャンセル）メッセージを使用して、未成立のセッション・セットアップの試みを終了する。クライアントはこのメッセージを使用して、前に開始させてまだ成立させていないテレビ会議セッション・セットアップの試みをキャンセルする。サーバは、ＩＮＶＩＴＥ（招待）が送信されたのと同じ位置に、ＣＡＮＣＥＬメッセージを未成立要求と共に転送する。クライアントは、ＣＡＮＣＥＬメッセージに「２００ ＯＫ」メッセージで応答すべきではない。ＣＡＮＣＥＬメッセージが失敗した場合は、セッション終了シーケンス（即ち、ＢＹＥ（さよなら）メッセージ）を使用する。

図１１は、本発明の説明に役立つ別の実施例による、セッション開始プロトコル（ＳＩＰ）を使用してテレビ会議セッションをキャンセルする方法を示す図である。図１１の例は、テレビ会議クライアント・アプリケーション＃１（クライアント＃１）１１０２、テレビ会議サーバ（サーバ）２０５、テレビ会議クライアント・アプリケーション＃２（クライアント＃２）１１０６を含んでいる。

ＩＮＶＩＴＥ（招待）要求が、クライアント＃１ １１０２からサーバ２０５に送信される（ステップ１１１０）。ＩＮＶＩＴＥ要求は、サーバ２０５からクライアント＃２ １１０６に転送される（ステップ１１１５）。

１８０Ｒｉｎｇｉｎｇ（呼出し）メッセージが、クライアント＃２ １１０６からサーバ２０５に送信される（ステップ１１２０）。１８０Ｒｉｎｇｉｎｇメッセージは、サーバ２０５からクライアント＃１ １１０２に転送される（ステップ１１２５）。

ＣＡＮＣＥＬ（キャンセル）メッセージが、クライアント＃１ １１０２からサーバ２０５に送信される（ステップ１１３０）。ＣＡＮＣＥＬメッセージは、サーバ２０５からクライアント＃２ １１０６に転送される（ステップ１１３５）。

次に、本発明の説明に役立つ一実施例による、テレビ会議セッションの終了に対応するセッション動作手順について述べる。図１２は、本発明の説明に役立つ一実施例による、セッション開始プロトコル（ＳＩＰ）を使用して２つのクライアント間のテレビ会議セッションを終了する方法を示す図である。図１２の例は、第１のクライアント（テレビ会議クライアント・アプリケーション＃１）１２０２、テレビ会議サーバ（サーバ）２０５、第２のクライアント（テレビ会議クライアント・アプリケーション＃２）１２０６を含んでいる。

クライアント＃１ １２０２は、クライアント＃２ １２０６との呼を停止することを決定する。従って、クライアント＃１ １２０２は、サーバ２０５にＢＹＥ（さよなら）メッセージを送信する（ステップ１２１０）。サーバ２０５は、クライアント＃２ １２０６にＢＹＥ（さよなら）メッセージを転送する（ステップ１２２０）。

クライアント＃２ １２０６は、２００ ＯＫメッセージをサーバ２０５に返信して、それ（クライアント＃２ １２０６）が切断されたことを示す（ステップ１２３０）。サーバ２０５は、２００ ＯＫメッセージをクライアント＃１ １２０２に転送して、切断の成功を示す（ステップ１２４０）。

図１３は、本発明の説明に役立つ一実施例による、セッション開始プロトコル（ＳＩＰ）を使用して３つのクライアント間のテレビ会議セッションを終了する方法を示す図である。図１３の例は、第１のクライアント（テレビ会議クライアント・アプリケーション＃１）１３０２、テレビ会議サーバ（サーバ）２０５、第２のクライアント（テレビ会議クライアント・アプリケーション＃２）１３０６、第３のクライアント（テレビ会議クライアント・アプリケーション＃３）１３０８を含んでいる。

クライアント＃１ １３０２は、クライアント＃２ １３０６およびクライアント＃３ １３０８との呼を停止することを決定する。これは、クライアント＃２ １３０６とクライアント＃３ １３０８との間のセッションは終了しない。

クライアント＃１ １３０２は、ＢＹＥ（さよなら）メッセージをサーバ２０５に送信する（ステップ１３１０）。サーバ２０５は、ＢＹＥメッセージを解釈し、クライアント＃２ １３０６およびクライアント＃３ １３０８がクライアント＃１ １３０２とのテレビ会議セッションに関わっていることを理解し、ＢＹＥメッセージをクライアント＃２ １３０６とクライアント＃３ １３０８の両方に転送する（ステップ１３２０および１３３０）。

クライアント＃２ １３０６は、２００ ＯＫメッセージをサーバ２０５に返信する（ステップ１３４０）。サーバ２０５は、２００ ＯＫメッセージをクライアント＃１ １３０２に転送し返す（ステップ１３５０）。クライアント＃３ １３０８は、２００ ＯＫメッセージをサーバ２０５に返信する（ステップ１３６０）。サーバ２０５は、２００ ＯＫメッセージをクライアント＃１ １３０２に転送し返す（ステップ１３７０）。

図１４は、本発明の説明に役立つ別の実施例による、セッション開始プロトコル（ＳＩＰ）を使用して３つのクライアント間のテレビ会議セッションを終了する方法を示す図である。図１４の例は、第１のクライアント（テレビ会議クライアント・アプリケーション＃１）１４０２、テレビ会議サーバ（サーバ）２０５、第２のクライアント（テレビ会議クライアント・アプリケーション＃２）１４０６、第３のクライアント（テレビ会議クライアント・アプリケーション＃３）１４０８を含んでいる。

クライアント＃１ １４０２は、クライアント＃２ １４０６およびクライアント＃３ １４０８との呼を停止することを決定する。これは、クライアント＃２ １４０６とクライアント＃３ １４０８との間のセッションは終了しない。

クライアント＃１ １４０２は、クライアント＃２ １４０６に向けたＢＹＥ（さよなら）メッセージをサーバ２０５に送信する（ステップ１４１０）。サーバ２０５は、ＢＹＥメッセージをクライアント＃２ １４０６に転送する（１４２０）。クライアント＃１ １４０２は、クライアント＃３ １４０８に向けたＢＹＥメッセージをサーバ２０５に送信する（１４３０）。サーバ２０５は、ＢＹＥメッセージをクライアント＃３ １４０８に転送する（ステップ１４４０）。

クライアント＃２ １４０６は、２００ ＯＫメッセージをサーバ２０５に返信する（ステップ１４５０）。サーバ２０５は、２００ ＯＫメッセージをクライアント＃１ １４０２に転送し返す（ステップ１４６０）。クライアント＃３ １４０８は、２００ ＯＫメッセージをサーバ２０５に返信する（ステップ１４７０）。サーバ２０５は、２００ ＯＫメッセージをクライアント＃１ １４０２に転送し返す（ステップ１４８０）。

図１２〜１４に関して先に述べた例に加えて、テレビ会議の加入者が属する同報通信グループ・アドレスにＢＹＥ（さよなら）メッセージを送信することにより終了を引き起こすこともできる。この方法を使用した場合、サーバおよび他のクライアント・アプリケーションはこのメッセージを受信することになる。これは、関連するオーバーヘッドがより少ないため、より全般的で効率的なセッション終了機構である。

次に、本発明の説明に役立つ一実施例による、解像度およびフレーム・レート調整に対応する動作手順について述べる。テレビ会議は、コンピュータ・ネットワーク上の異なる位置にいる複数のユーザー間で、生の双方向対話式ビデオを伝送することを含んでいる。リアルタイムの対話式ビデオは、制約された遅延で多量の情報を伝送することを必要とする。このために、テレビ会議システムが結合しているコンピュータ・ネットワークは、セッションに関わっている各ユーザーに十分な帯域幅量およびサービス品質を提供できなければならない。帯域幅は、時として限られたリソースである可能性があり、サービス品質は、全てのネットワークで常に保証できるわけではない。従って、幾つかの制限が存在することになる。私設の企業ネットワークでは、サービス品質を保証することは可能だが、多量の帯域幅を常に保証できるわけではない。

基本的な企業コンピュータ・ネットワーク設備は、低速リンクを介して共に接続された幾つかの高速ローカル・エリア・ネットワーク（ＬＡＮ）を含む（例えば図２参照）。各高速ＬＡＮは通常、単一の地理的位置におけるネットワーク設備を表し、低速リンクは、複数の地理的位置を共に接続する長距離リンクである。低速リンクを使用する理由は、長距離リンクのコストが相対的に高いからであり、また、ほとんどのネットワーク・トラフィックが通常はローカル・エリア・ネットワーク内で局在化され、従って一般には多量のデータがこれらの長距離リンクを介して交換されることはないからである。

ＩＰベースのネットワークを介したサービス品質における最近の進歩により、現在、これらのネットワークを介して他のタイプの情報を伝送することのできる手段が提供されつつある。これは、リアルタイムでないデータ・トラフィックに加えて、このインフラストラクチャを介してリアルタイムの情報（即ち、音声およびビデオ）を伝送するための扉を開くものである。ネットワークのサービス品質を利用したテレビ会議サービスは、このインフラストラクチャの上に載せるのによく適している。今や、異なる２つの地理的位置にいる２人のユーザーが、リアルタイムのテレビ会議セッションに参加することが可能である。テレビ会議の欠点の１つは、リアルタイム・ビデオの伝送が極度に帯域幅を消費する可能性があり、状況によりは、利用可能なネットワーク・リソースを容易に使い尽くす可能性があることである。ネットワークを介して伝送されるリアルタイム・ビデオのビット・レートは、主に、使用されるビデオ解像度および圧縮アルゴリズムにより決まる。通常、異なる地理的位置にいる２人、３人、または４人のユーザー間における１つのテレビ会議セッションは、妥当な量の帯域幅を有するネットワーク上で適切にサポートする。しかし一般に、４人を超えるユーザーをテレビ会議セッションに加えることはサポートできておらず、また、第２のテレビ会議セッションも、帯域幅制約が原因でサポートできていない。テレビ会議システムの制限要因は、地理的位置間の低速長距離リンクである。

可能な解決法の１つは、より多くのユーザーをシステム中でサポートするために、２つの地理的位置間の長距離リンクの帯域幅を増大させることである。この手法の欠点は、帯域幅が非常に高価なことである。第２の解決法は、テレビ会議セッション内の限られた人数のユーザー（即ち、能動的なユーザー）だけが高解像度および高ビット・レートで伝送することが許され、セッション内の残りのユーザー（即ち、受動的なユーザー）は制限されたビット・レートおよび解像度でしか伝送することができないシステムを有することである。テレビ会議セッションの組織者は、どのユーザーが高解像度で伝送し、どのユーザーが低解像度で伝送するかに関する制御権を有することになる。ユーザーがセッションで能動的に会話または対話していない場合は、このユーザーのビデオを高解像度で送信する必要はない。このような手法は、非常に大きな帯域幅節約をもたらすことができる。

先に進んで図１８Ａのテレビ会議クライアント・アプリケーション１８００を参照すると、この手法は、テレビ会議クライアント・アプリケーション１８００中の、様々なウィンドウ・サイズ（即ち、高解像度と低解像度の復号済みビデオ・ストリームを表示するための各種サイズの表示ウィンドウ）をサポートするユーザー・インタフェース１８０８と、サーバ２０５および他のクライアントのアプリケーションとの間の通信を指定するメッセージング・システム１８４２（ネットワーク構成要素１８０６に含まれる。ネットワーク構成要素１８０６は図１８Ａのテレビ会議クライアント・アプリケーション１８００に含まれる）とを有することを含んでいる。メッセージング・システム１８４２は、各クライアント・アプリケーションの符号化解像度および伝送ビット・レートを制御するメッセージを含むことになる。

次に、本発明の説明に役立つ一実施例による、解像度およびフレーム・レート調整に対応するメッセージについて述べる。特に、ＭＳＧ＿ＷＩＮＤＯＷ＿ＳＷＩＴＣＨメッセージおよびＭＳＧ＿ＡＤＪＵＳＴ＿ＣＯＤＥＣメッセージについて述べる。

ＭＳＧ＿ＷＩＮＤＯＷ＿ＳＷＩＴＣＨメッセージは、クライアントからサーバに送信され、能動的なユーザーと受動的なユーザーとの切替えを示す。即ち、能動的なユーザーは受動的になり、受動的なユーザーは能動的になる。テレビ会議サーバは、クライアントによるこの要求を承認することになる。

ＭＳＧ＿ＡＤＪＵＳＴ＿ＣＯＤＥＣメッセージは、サーバから各クライアントに送信される。ＭＳＧ＿ＡＤＪＵＳＴ＿ＣＯＤＥＣメッセージは、クライアントがどの解像度（即ち、ＣＩＦかＱＣＩＦか）およびどのフレーム・レートで送信すべきかを、クライアントに示すことになる。ＭＳＧ＿ＡＤＪＵＳＴ＿ＣＯＤＥＣメッセージは、各クライアントにより肯定応答される。

図１５は、本発明の説明に役立つ一実施例による、解像度およびフレーム・レート調整のための情報伝送方法を示す図である。図１５の例は、テレビ会議サーバ（サーバ）２０５、クライアント１ １５０４、クライアント２ １５０６、クライアント３ １５０８、クライアント４ １５１０を含んでいる。

ＭＳＧ＿ＷＩＮＤＯＷ＿ＳＷＩＴＣＨ（メッセージ・ウィンドウ切換え）メッセージが、クライアント１ １５０４からサーバ２０５に送信される（ステップ１５２０）。肯定応答メッセージＡＣＫが、サーバ２０５からクライアント１ １５０４に送信される（ステップ１５２５）。

ＭＳＧ＿ＡＤＪＵＳＴ＿ＣＯＤＥＣ（メッセージ調整コーデック）（低）メッセージが、サーバ２０５からクライアント１ １５０４に送信される（ステップ１５３０）。肯定応答メッセージＡＣＫが、クライアント１ １５０４からサーバ２０５に送信される（ステップ１５３５）。

ＭＳＧ＿ＡＤＪＵＳＴ＿ＣＯＤＥＣ（高）メッセージが、サーバ２０５からクライアント２ １５０６に送信される（ステップ１５４０）。肯定応答メッセージＡＣＫが、クライアント２ １５０６からサーバ２０５に送信される（ステップ１５４５）。

ＭＳＧ＿ＡＤＪＵＳＴ＿ＣＯＤＥＣ（低）メッセージが、サーバ２０５からクライアント３ １５０８に送信される（ステップ１５５０）。肯定応答メッセージＡＣＫが、クライアント３ １５０８からサーバ２０５に送信される（ステップ１５５５）。

ＭＳＧ＿ＡＤＪＵＳＴ＿ＣＯＤＥＣ（高）メッセージが、サーバ２０５からクライアント４ １５１０に送信される（ステップ１５６０）。肯定応答メッセージＡＣＫが、クライアント４ １５１０からサーバ２０５に送信される（ステップ１５６５）。

図１６は、本発明の説明に役立つ一実施例による、解像度およびフレーム・レート調整（クライアント２および３）の前の情報伝送を示す図である。図１７は、本発明の説明に役立つ一実施例による、解像度およびフレーム・レート調整（クライアント２および３）の後の情報伝送を示す図である。図１６および図１７の例は、クライアント１ １６０２、クライアント２ １６０４、ネットワーク・ルータ１６０６、クライアント３ １６０８、クライアント４ １６１０を含んでいる。

「低ビット・レート／解像度で送る」メッセージが、クライアント１ １６０２からネットワーク・ルータ１６０６に送信される（ステップ１６２０）。「高ビット・レート／解像度で送る」メッセージが、クライアント３ １６０８からネットワーク・ルータ１６０６に送信される（ステップ１６２５）。「低ビット・レート／解像度で送る」メッセージが、クライアント２ １６０４からネットワーク・ルータ１６０６に送信される（ステップ１６３０）。「高ビット・レート／解像度で送る」メッセージが、クライアント４ １６１０からネットワーク・ルータ１６０６に送信される（ステップ１６３５）。

同報通信アドレスを使用して、データがネットワーク・ルータ１６０６からクライアント２ １６０４、クライアント３ １６０８、クライアント１ １６０２、クライアント４ １６１０に送信される（それぞれステップ１６４０、１６４５、１６５０、１６５５）。

図１７に進むと、「低ビット・レート／解像度で送る」メッセージが、クライアント１ １６０２からネットワーク・ルータ１６０６に送信される（ステップ１７２０）。「高ビット・レート／解像度で送る」メッセージが、クライアント３ １６０８からネットワーク・ルータ１６０６に送信される（ステップ１７２５）。「高ビット・レート／解像度で送る」メッセージが、クライアント２ １６０４からネットワーク・ルータ１６０６に送信される（ステップ１７３０）。「低ビット・レート／解像度で送る」メッセージが、クライアント４ １６１０からネットワーク・ルータ１６０６に送信される（ステップ１７３５）。

同報通信アドレスを使用して、データがネットワーク・ルータ１６０６からクライアント２ １６０４、クライアント３ １６０８、クライアント１ １６０２、クライアント４ １６１０に送信される（それぞれステップ１７４０、１７４５、１７５０、１７５５）。

次に、本発明の説明に役立つ一実施例によるクライアント・アプリケーション・アーキテクチャについて述べる。クライアント・アプリケーションは、ユーザーとの対話、他のクライアント・アプリケーションとのマルチメディア・コンテンツ交換、サーバ・アプリケーションとの呼の管理を担う。図１８Ａは、本発明の説明に役立つ一実施例による、テレビ会議クライアント・アプリケーション１８００のブロック図である。テレビ会議クライアント・アプリケーション１８００は、コンピュータ２２０ａ〜ｆの何れか、および／またはコンピュータ２３０ａ〜ｅの何れかなどのコンピュータ上に見られるものとすることができることを理解されたい。

テレビ会議クライアント・アプリケーション１８００は、４つの基本的な機能構成要素、即ちマルチメディア・インタフェース層１８０２、コーデック１８０４（音声コーデック１８０４ａおよびビデオ・コーデック１８０４ｂ）、ネットワーク構成要素１８０６、ユーザー・インタフェース１８０８を備えている。

マルチメディア・インタフェース層１８０２は、テレビ会議クライアント・アプリケーション１８００の主制御インスタンスである。全てのシステム内通信は、マルチメディア・インタフェース層１８０２を介して経路指定され、マルチメディア・インタフェース層１８０２により制御される。マルチメディア・インタフェース層１８０２の基礎をなす重要な特徴の１つは、異なる音声コーデックおよびビデオ・コーデック１８０４を容易に交換できることである。これに加えて、マルチメディア・インタフェース層１８０２は、オペレーティング・システム（ＯＳ）依存のユーザー入出力構成要素およびネットワーク・サブシステムへの、インタフェースも提供する。マルチメディア・インタフェース層１８０２は、メンバ・データベース１８２０、主制御モジュール１８２２、音声ミクサー１８９９、エコー・キャンセル・モジュール１８９８を備えている。

ユーザー・インタフェース１８０８は、テレビ会議クライアント・アプリケーション１８００との対話ポイントをエンド・ユーザーに提供する。必須ではないが、ユーザー・インタフェース１８０８は、ＯＳ依存のモジュールとして実現することが好ましい。多くのグラフィカル・ユーザー・インタフェース（ＧＵＩ）は、それらが使用している特定のＯＳに依存する。ユーザー・インタフェース１８０８の４つの主要機能は、ビデオ取込み、ビデオ表示、音声取込み、音声再生である。ユーザー・インタフェース１８０８は、音声／ビデオ・キャプチャ・インタフェース１８３０、音声／ビデオ再生モジュール１８３２、メンバ・ビュー・モジュール１８３４、チャット・モジュール１８３６、ユーザー選択／メニュー１８３８を備えている。音声／ビデオ・キャプチャ・インタフェース１８３０は、カメラ・インタフェース１８３０ａ、マイクロホン・インタフェース１８３０ｂ、ファイル・インタフェース１８３０ｃを備えている。音声／ビデオ再生モジュール１８３２は、ビデオ表示１８３２ａ、音声再生モジュール１８３２ｂ、ファイル・インタフェース１８３２ｃを備えている。

ネットワーク構成要素１８０６は、テレビ会議クライアント・アプリケーション１８００の通信サブシステムを表す。ネットワーク構成要素１８０６の機能は、セッション開始プロトコル（ＳＩＰ）に基づくクライアント−サーバ・メッセージングと、音声およびビデオ・ストリームの送受信である。ネットワーク構成要素１８０６はまた、クライアント間のメディア・ストリームを認証および暗号化通信するための基本的なセキュリティ機能も備えている。ネットワーク構成要素１８０６は、セキュリティ・モジュール１８４０、メッセージング・システム１８４２、ビデオ・ストリーム・モジュール１８４４、音声ストリーム・モジュール１８４６、ＩＰソケット１８４８ａ〜ｃを備えている。

音声コーデック１８０４ａおよびビデオ・コーデック１８０４ｂは、ディジタル・メディアの圧縮および圧縮解除を扱うサブシステムである。コーデックを交換しやすくするために、コーデックへのインタフェースは単純で一般的なものであるべきである。以下では、マルチメディア・インタフェース層１８０２とコーデック１８０４との間の単純な関係を、実施のための例示的なテンプレートまたはガイドとして定義する。音声コーデック１８０４ａおよびビデオ・コーデック１８０４ｂはそれぞれ、エンコーダ１８８０およびデコーダ１８９０を備えている。エンコーダ１８８０およびデコーダ１８９０はそれぞれ、キュー１８９５を備えている。

テレビ会議クライアント・アプリケーション１８００は、少なくとも、テレビ会議サーバ２０５および他のクライアント１８７０とインタフェースする。

次に、本発明の説明に役立つ一実施例による、図１８Ａのマルチメディア・インタフェース層１８０２に備わるメンバ・データベース１８２０について述べる。メンバ・データベース１８２０は、各参加ユーザーに関する情報をセッション毎に記憶する。メンバ・データベース１８２０は、ＩＰアドレスの送受信に関連する情報、クライアントの機能、特定のコーデックに関する情報、種々のユーザーの状態に関する詳細を含んでいる。これらの項目は例示にすぎず、従って、本発明の趣旨および範囲を維持しながら、これらの項目の幾つかまたは全てに加えて、またはそれに代えて、他の項目をメンバ・データベース１８２０中に保持することもできることを理解されたい。メンバ・データベース１８２０に含まれる情報を使用して、音声デコーダおよびビデオ・デコーダ１８９０に向けられた入来情報が制御される。ネットワークから入来したメディア情報は、正しい音声デコーダおよびビデオ・デコーダ１８９０に経路指定される必要がある。等しく重要なことだが、音声エンコーダおよびビデオ・エンコーダ１８９０から来たメディア情報は、配信のために正しい単一通信または同報通信アドレスに経路指定される必要がある。メンバ・データベース１８２０に含まれる基本的な情報はまた、エンド・ユーザーがセッションへの参加者および参加者機能を認識できるように、ユーザー・インタフェース１８０８にも経路指定される。ＩＮＶＩＴＥ要求がテレビ会議サーバ２０５から受信されるとすぐに、ユーザーがメンバ・データベース１８２０に追加され、ＢＹＥ要求がテレビ会議サーバ２０５から受信されるとすぐに、ユーザーが削除される。セッションが終了したときは、メンバ・データベース１８２０はフラッシュされる。

次に、本発明の説明に役立つ一実施例による、図１８Ａのマルチメディア・インタフェース層１８０２に備わる主制御モジュール１８２２について述べる。

主制御モジュール１８２２は、マルチメディア・インタフェース層１８０２の非常に重要な部分である。主制御モジュール１８２２は、中央管理サブシステムとして働き、以下の重要な機能を提供する。即ち、音声デコーダとビデオ・デコーダのためおよび再生のための同期機構と、記録のためにデコーダの宛先をスクリーンまたはファイルに接続することと、アプリケーション層のサービス品質である。

最適なテレビ会議ユーザー体験のためには、音声とビデオの再生を同期させることが非常に重要である。２つのメディア・ストリームを正確に同期させるために、タイムスタンプを使用して、これをメディア・コンテンツと共に送信することが必要になる。リアルタイム・プロトコル（ＲＴＰ：Ｒｅａｌ Ｔｉｍｅ Ｐｒｏｔｏｃｏｌ）は、この目的で、タイムスタンプおよびシーケンス番号を含めるための包括的なヘッダを提供する。提供されるタイムスタンプは、２つのネットワーク・ノード・クロックを同期させるように意図されたものではなく、一貫した再生のために音声とビデオのストリームを同期させるように意図されたものである。これらのタイムスタンプは、取込み時に同じノード上の共通クロックから得る必要がある。例えば、ビデオ・フレームが取り込まれるときは、ビデオ・フレームが取り込まれた時間が記録されなければならない。同じことが音声にも当てはまる。ＲＴＰを使用するためのその他の詳細およびガイドラインについては、本明細書の別の箇所で述べる。

音声とビデオを同期させる際の主制御モジュール１８２２の機能は、メタデータ（タイムスタンプおよびシーケンス番号を含む）とマルチメディア・データが正しく伝送されるように、ネットワーク構成要素１８０６とコーデック１８０４との間の接続を生成することである。パケットが遅れた場合は、システムの現状態に応答して、復号の前または後でこれらのパケットをドロップする。その後、ＲＴＰタイムスタンプを使用して、提示および再生タイムスタンプを生成する。

主制御モジュール１８２２はまた、音声デコーダおよびビデオ・デコーダ１８９０の出力を、再生のためにスクリーンに向けて送るか、記録のためにファイルに向けて送るか、この両方を行うことを担う。各デコーダ１８９０は独立して扱われ、従ってこれにより、例示的な状況では、あるデコーダの出力はスクリーンに表示され、第２のデコーダの出力はファイルに記録され、第３のデコーダからの出力はファイルとスクリーンの両方に向かうことが、同時に可能である。

上述の任務に加えて、主制御モジュール１８２２は、アプリケーション層のサービス品質にも関与する。主制御モジュール１８２２は、パケット・ドロップや送受信されたバイトに関する情報を収集し、この情報に基づいて動作する。これは、ネットワーク中で発生している状況を修復するのを助けるために、別のクライアントまたはテレビ会議サーバ２０５にメッセージを送信することを含む可能性がある。リアルタイム制御プロトコル（ＲＴＣＰ：Ｒｅａｌ Ｔｉｍｅ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）を、統計およびパケット損失を報告するのに使用することができ、また、アプリケーション特有の情報伝送のためにも使用する。

図１８Ｂは、本発明の説明に役立つ一実施例による、図１８Ａのマルチメディア・インタフェース層１８０２に備わる音声ミクサー１８９９を更に示すブロック図である。音声ミクサー１８９９（本明細書では「利得制御モジュール」とも呼ぶ）は、複数の音声デコーダ１８９０に動作可能になるように結合される。複数の音声デコーダ１８９０は、圧縮音声ストリームを受け取り、圧縮解除済み音声ストリームを出力する。圧縮解除済み音声ストリームは、音声ミクサー１８９９に入力され、合成音声ストリームとして出力される。

図１８Ｃは、本発明の説明に役立つ一実施例による、図１８Ａのマルチメディア・インタフェース層１８０２に備わるエコー・キャンセル・モジュール１８９８を更に示すブロック図である。エコー・キャンセル・モジュール（本明細書では「エコー・キャンセラ」とも呼ぶ）１８９８は、スピーカ１８９７（例えば音声再生モジュール１８３２ｂ）およびマイクロホン１８９６（例えばマイクロホン・インタフェース１８３０ｂ）に動作可能になるように結合される。スピーカ１８９７からの音声が全二重または双方向通信システムで生成されるとき、音声はローカルの聴取者だけに聞こえるように意図される。しかし、生成された音声はローカル・マイクロホン１８９６にも聞こえ、次いでマイクロホン１８９６により、信号は遠方端に返信されてエコーとして聞こえる。このため、この効果を緩和して、それにより、よりよいユーザー体験を生み出すために、テレビ会議クライアント・アプリケーション１８００はエコー・キャンセル・モジュール１８９８を必要とする。

次に、本発明の説明に役立つ一実施例による、テレビ会議クライアント・アプリケーション１８００のサブシステムに利用可能なインタフェースについて述べる。インタフェースには、ユーザー・インタフェース１８０８、ネットワーク構成要素１８０６、コーデック１８０４との、対話ポイントが含まれる。ユーザー・インタフェース１８０８は、取り込まれた音声およびビデオをそれらに対応するタイムスタンプと共に受け取るための機能を提供する。これに加えて、音声およびビデオを表示再生のためにユーザー・インタフェース１８０８に送るための機能が提供されなければならない。ネットワーク構成要素１８０６インタフェースは、セッション制御およびセキュリティのための入来および送出メッセージを情報伝送するための機能を提供する。音声コーデックおよびビデオ・コーデック１８０４ａ、ｂは、構成制御のための、並びに圧縮または圧縮解除に向けたパケット送受信のための、基本的なインタフェースを提供する。

次に、本発明の説明に役立つ一実施例による、音声コーデックおよびビデオ・コーデック１８０４ａ、ｂについて述べる。

テレビ会議で使用するために入手できる音声コーデックおよびビデオ・コーデックには、幾つかのものがある。必須ではないが、本発明により採用されるコーデックはソフトウェアベースであることが好ましい。本発明の説明に役立つ一実施例によれば、一般的なデスクトップ・コンピュータの処理力の制約により、ビデオ圧縮および圧縮解除にはＨ．２６３を使用する。将来、デスクトップ・コンピュータがより強力になるのに伴って、Ｈ．２６Ｌなどのより高度なコーデックを使用する機能を実現してこれを利用する。当然、本発明はこれらのタイプのコーデックに限定されるわけではなく、従って、本発明の趣旨および範囲を維持しながら、他のタイプのコーデックを使用することもできる。

次に、本発明の説明に役立つ一実施例による、コーデック１８０４ａ、ｂへのインタフェースについて述べる。この記述は、ＤａｔａＩｎ関数、コールバック関数、コーデック・オプションを含んでいる。コーデック１８０４ａ、ｂへのインタフェースは、コーデックを交換できるようにする共にと共に新しいコーデックを将来追加できるように、十分にフレキシブルであるべきであり、且つ一般的に定義されるべきである。このフレキシブルで一般的なインタフェースを実現するための提案インタフェースは、ユーザーに提供される機能の数が限られた、非常に単純なインタフェースである。

ＤａｔａＩｎ関数は、単純に、エンコーダ・クラスまたはデコーダ・クラスのフレームまたはパケットを記憶するのに使用される。

マルチメディア・インタフェース層１８０２とマルチメディア・コーデック１８０４との間の単純な接続を提供するために、データ出力関数はコールバックとして実現すべきである。マルチメディア・インタフェース層１８０２は、このコールバック関数を、受信構成要素の入力関数に設定する。例えば、コーデックがフレームの符号化または復号を完了したとき、コーデックは、意図された情報を符号化プロセスまたは復号プロセスから伝送するためにこの関数を呼び出す。コーデックはこのコールバック中に何もできないという制約があるので、この関数は、システム中の待機および不要な遅延を防止するためにできるだけ早く返すべきである。この関数で行われるべき唯一の追加の待機は、共有リソースにアクセスするときの相互排除ロックだけであるべきである。

種々のタイプのコーデックに利用可能なオプションの範囲は、様々となる。これらのオプションを管理するための要件を満たすために、単純なインタフェースを使用すべきである。文字ベースのインタフェースは、フレキシビリティをもたらすので好ましい（ただし必須ではない）。ＳＴＡＲＴ（スタート）やＳＴＯＰ（ストップ）などの共通コマンド・セットがあるべきであり、更にコーデック特有のコマンドがあるべきである。この方法は単純なインタフェースを提供するが、単純なインタープリタが必要なので、コーデックに更に複雑さが加わる。例えば、Ｏｐｔｉｏｎｓ関数は、オプションを読み書きできるよう十分に一般的なものとする。
例：Ｒｅｓｕｌｔ＝Ｏｐｔｉｏｎｓ（“ｓｔａｒｔ”）、Ｒｅｓｕｌｔ＝Ｏｐｔｉｏｎｓ（“ｒｅｓｏｌｕｔｉｏｎ＝ＣＩＦ”）など。

例えば、コーデック間の共通オプションの幾つかは、開始、停止、一時停止、品質指数（０〜１００）、解像度として標準化されるべきである。

品質指数（ｑｕａｌｉｔ ｉｎｄｅｘ）は、コーデックの全体的な品質を０％と１００％の間の値として記述する因子である。これは、値が大きいほどビデオ品質が高いという基本的な前提に従う。

図１９は、本発明の説明に役立つ一実施例による、音声コーデック１８０４ａおよび／またはビデオ・コーデック１８０４ｂに備わるデコーダ１８９０により採用される方法を示す図である。この方法を、デコーダ・コンテキスト１９０１および発呼側コンテキスト１９０２に関して述べる。この方法は、少なくとも以下の入力および出力を使用して動作する。即ち、「データ・イン」１９９９、「信号イン」１９９８、「信号アウト・コールバック」１９９７、「セット・コールバック関数」１９９６、「データ・アウト・コールバック」１９９５である。入力「データ・イン」１９９９を使用して、データを入力キューに記憶する（ステップ１９０５）。

初期化ステップ（Ｉｎｉｔ）を実施して、デコーダ１８９０を初期化する（ステップ１９１０）。主ループを実行し、開始コマンドまたは終了コマンドを待機する（ステップ１９２０）。終了コマンドを受け取った場合、方法は終了し（ステップ１９２２）、例えば別の動作に戻る（１９２４）。

入力キュー１８９５からデータを読み出すか、或いは入力キュー１８９５が空の場合は待機状態になる（ステップ１９３０）。ステップ１９３０でデータを読み出した場合、データを復号する（ステップ１９４０）。「データ・アウト・コールバック」１９９５がステップ１９２０に提供される。

次に、本発明の説明に役立つ一実施例による、ネットワーク２００により採用される通信について述べる。この記述は、ネットワーク通信に関して上述したことを補足するものである。

メッセージング・システム１８４２（図１８Ａのネットワーク構成要素１８０６に備わる）は、テレビ会議クライアント・アプリケーション１８００とテレビ会議サーバ２０５との間のインタフェースを提供する。これは、セッション管理（即ち、セッションのセットアップおよび終了）に使用されるように意図されている。全ての情報伝送メッセージは、テレビ会議サーバ２０５を介して通信され、クライアントからクライアントに直接通信されることはない。マルチメディア・コンテンツや非公開チャット・メッセージなどのデータは、クライアント間で直接送信される情報だけを含んでいる。メッセージング・システムは、標準方式に基づくセッション開始プロトコル（ＳＩＰ）を使用する。

テレビ会議クライアント・アプリケーション１８００の機能を統制するプロトコルには、幾つかの異なるプロトコルがある。例えば、セッション開始プロトコル（ＳＩＰ）、リアルタイム・プロトコル（ＲＴＰ）、リアルタイム制御プロトコル（ＲＴＣＰ）、セッション記述プロトコル（ＳＤＰ：Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｏｔｏｃｏｌ）を採用する。

セッション開始プロトコル（ＳＩＰ）の目的は、セッション管理である。ＳＩＰは、ＩＰベースのネットワーク上の１人または複数の参加者とのマルチメディア・セッションを生成、変更、終了するための、文字ベースのアプリケーション層制御プロトコルである。ＳＩＰをクライアントとサーバの間で使用して、これを達成する。ＳＩＰについては、上にテレビ会議サーバ２０５に関して更に述べてある。

リアルタイム・プロトコル（ＲＴＰ）は、リアルタイム・マルチメディア（即ち、音声およびビデオ）の伝送に使用される。ＲＴＰは、搬送中のマルチメディア情報のタイプに関連する追加の詳細を提供するためのアプリケーション層・プロトコルである。ＲＴＰは、トランスポート層の上にあり、通常はユーザー・データグラム・プロトコル（ＵＤＰ）の最上部で搬送される。クライアント・アプリケーション中でのＲＴＰの主な機能は、タイムスタンプ（音声とビデオの同期をとるため）、シーケンス番号、並びにそれがカプセル化しているペイロードのタイプ（例えばＭＰＥＧ４、Ｈ．２６３、Ｇ．７２３など）の識別をトランスポートすることである。

図２０は、本発明の説明に役立つ一実施例による、ユーザー・プレーン・プロトコル・スタック２０００を示す図である。スタック２０００は、１つの層上にビデオ２０１０および音声２０２０を含み、別の層上にビデオ２０１０と音声２０２０の両方についてのＲＴＰ２０３０を含み、別の層上にＵＤＰポート＃Ｘ２０４０およびＵＤＰポート＃Ｙ２０５０を含み、更に、ＩＰ層２０６０、リンク層２０７０、物理層２０８０を含んでいる。包括的なＲＴＰヘッダに加えて、コーデック特有のＲＴＰヘッダが使用される。

リアルタイム制御プロトコル（ＲＴＣＰ）は、ＲＴＰ標準方式の一部である。ＲＴＣＰは、送信側と受信側の間の統計報告ツールとして使用される。各テレビ会議クライアント・アプリケーション１８００は、その統計を収集し、相互に送信すると共にサーバ２０５に送信する。テレビ会議サーバ２０５は、このデータに基づいて、セッション中に生じた問題に関する情報を記録する。

図２１は、本発明の説明に役立つ一実施例による、制御プレーン・プロトコル・スタック２１００を示す図である。スタック２１００は、１つの層上にＳＩＰ２１１０、ＵＩコーデック変更メッセージング２１２０、ＲＴＣＰ２１３０を含み、更にＴＣＰ層２１４０、ＩＰ層２１５０、リンク層２１６０、物理層２１７０を含んでいる。

ＳＤＰの主な目的は、セッションのメディア・ストリームに関する情報を搬送することである。ＳＤＰは、限定しないが以下の項目を含んでいる。即ち、セッション名および目的、セッションがアクティブな時間、セッションを含むメディア、メディアを受信するための情報（即ち、アドレス、ポート、フォーマットなど）、メディアのタイプ、トランスポート・プロトコル（ＲＴＰ／ＵＤＰ／ＩＰ）、メディアのフォーマット（Ｈ．２６３など）、同報通信、メディアの同報通信アドレス、メディアのトランスポート・ポート、単一通信、メディアのリモート・アドレスである。

セッション記述プロトコル（ＳＤＰ）情報は、ＳＩＰメッセージのメッセージ本体である。これらは共に伝送される。

次に、本発明の説明に役立つ一実施例による、図１８Ａのユーザー・インタフェース１８０８について更に述べる。ユーザー・インタフェース１８０８は、テレビ会議クライアント・アプリケーション１８００の非常に重要な要素である。ユーザー・インタフェース１８０８は、複数のビュー（表示装置／ボタン／メニュー／．．．）を含み、全ての入力データ（音声／ビデオ・キャプチャ、ボタン、キーストローク）を扱うことができる。

図２２は、本発明の説明に役立つ一実施例による、図１８Ａのユーザー・インタフェース１８０８に対応するスクリーン・ショット２２００を示すブロック図である。スクリーン・ショット２２００は、「大きいビュー」２２１０、「小さいビュー」２２２０、チャット・ビュー部分２２３０、メンバ・ビュー部分２２４０、チャット編集部分２２５０を含んでいる。

再び図１８Ａを参照すると、ビデオ・キャプチャ・インタフェース１８３０は、ウェブ・カム（図示せず）、キャプチャ・カードおよび高品質カメラ（図示せず）、カメラ・インタフェース１８３０ａ、マイクロホン・インタフェース１８３０ｂ、ファイル・インタフェース１８３０ｃなどのうちの何れかを備えるものとする。

ウェブ・カムは、Ｗｉｎｄｏｗｓ（登録商標）オペレーティング・システムにより提供されるビデオ・フォー・ウィンドウズ（登録商標）（ＶＦＷ：Ｖｉｄｅｏ Ｆｏｒ Ｗｉｎｄｏｗｓ（登録商標））アプリケーション・プログラミング・インタフェース（ＡＰＩ）を使用して、或いはＬｉｎｕｘなどの異なるオペレーティング・システムの下で使用される他のキャプチャ・ドライバにより、ＵＳＢまたはＦｉｒｅＷｉｒｅ（ＩＥＥＥ１３９４）インタフェースを介してサポートされるべきである。当然ながら本発明は、これらのインタフェース、オペレーティング・システム、またはドライバに限定されるわけではなく、従って、本発明の趣旨および範囲を維持しながら、他のインタフェース、オペレーティング・システム、およびドライバを使用することもできる。

メンバ・ビュー・モジュール１８３４は、進行中の呼に参加しているメンバを表示するのに使用される。呼の開始者（即ち、マスタ）は、不要なメンバをドロップするか、または能動的なメンバを選択する。あらゆるメンバは、非公開チャット・メッセージを交換するために１人または複数のメンバを選択する。更に、メンバ・ビュー・モジュール１８３４中では、メンバの状態が信号で伝えられる。この場合、メンバは自分自身の状態を設定する。例えば、「退席中」に設定して、現在は参加できないがすぐに戻ることを他者に信号で伝えることができる。

ビデオ・ストリームに加えて、あらゆるメンバは、チャット・モジュール１８３６を使用して他のメンバの全員または何人かだけにチャット・メッセージを送信する機会も有する。メッセージは、チャット・ビュー中に表示され、チャット編集ビュー中で編集される。スクロールバーで、より古いメッセージを見ることができる。

次に、本発明の説明に役立つ一実施例による、クライアント・アプリケーション１８００についての動作手順について述べる。以下の記述は、単にクライアント・アプリケーション１８００の幾つかの機能の基本的なガイドラインであり、全ての機能を列挙して表すものではない。この記述は、ログイン、呼の開始、呼の受諾、ログオフを含んでいる。

ログインは、クライアント・アプリケーション１８００が最初に起動されたときに行われる。ログインは、起動時にオペレーティング・システムに提供されたログイン名に基づいて自動的に行われるものとしてもよく、ログインから独立した別のインタフェースを使用してもよい。これは、現在使用中のネットワークに対して好ましい認証方法、およびどのようにポリシーが管理されるかにより決まる。最も単純な方法は、ウィンドウズ（登録商標）・オペレーティング・システムで使用されるのと同じログイン名を使用して、名前付けの一貫性を維持し、また既存のユーザー・データベースを再利用（適切なら）できるようにすることであろう。

図２３は、本発明の説明に役立つ一実施例による、ログイン・インタフェース２３００を示す図である。ユーザーが現在、サーバ上にアカウントを持っていない場合は、サインアップ機能２３３０を使用する。アクセスを容易にするために、任意の電子メール・アドレス入力ボックス２３４０に電子メール・アドレスを提供する。

呼を開始するために、クライアント・アプリケーション１８００は、参加可能な候補のリストをサーバ２０５に照会する。クライアントは、テレビ会議セッションに参加させたいと思うユーザーを選択する。２人の参加者が関与する場合は、セッションは単一通信としてセットアップされる。そうではなく、３人以上の参加者が関与する場合は、セッションは同報通信としてセットアップされる。

図２４は、本発明の説明に役立つ一実施例による、セッションを開始するためのユーザー選択インタフェース２４００を示すブロック図である。

ユーザーが呼に招待されると、開始者の名前を示すメッセージがユーザーのスクリーンに表示される。次いでユーザーは、呼を受諾するか拒否する。ユーザーが呼を受諾した場合、次いでクライアント・アプリケーション１８００は、受諾（または肯定応答）メッセージをサーバ２０５に送信する。次いでサーバ２０５は、呼に現在参加しているあらゆるメンバに、新しいメンバを通知する。ユーザーがキャンセル・メッセージをサーバ２０５に送信することにより呼を拒否した場合は、他の全てのメンバにもこのイベントが通知される。図２５は、本発明の説明に役立つ一実施例による、入来呼を受諾または拒否するための招待インタフェース２５００を示すブロック図である。

ログオフの場合、テレビ会議サーバ２０５のデータベース構成要素３０２に備わるメンバ・データベース３１４からユーザーを削除する。ＢＹＥメッセージが、セッションの各参加クライアントに送信される。これは、同報通信と単一通信のどちらかにより行うことができる。このメッセージを送信するのに好ましい方法は、同報通信である。

従来のテレビ会議システムでは、共通のビデオ・チャネルおよび音声チャネルが生成され、全ての参加者クライアントの間で共有される。テレビ会議の開始者（ｉｎｉｔｉａｔｏｒ：イニシエータ）（以下、「開始参加者」とも呼ぶ）が、他のユーザー（以下、「他の参加者」とも呼ぶ）をテレビ会議通話に加わるように招待する。他のユーザーは、この招待を受諾することもできるし、受諾しないこともできる。ユーザーが招待を受諾すると、ユーザーはテレビ会議の参加者になる。本発明では、テレビ会議の参加者数Ｎが３人以上（Ｎ＞２）であると仮定する。本発明では、３人以上の参加者を同時にサポートするテレビ会議システムを、複数ユーザー・テレビ会議システムと呼ぶことにする。

テレビ会議システムが、共有ビデオ・チャネルおよび音声チャネルを生成することができるモードには、単一通信と同報通信の２つのモードがある。単一通信モードでは、１人の参加者は残りの参加者へのチャネル（Ｎ−１個）を生成しなければならない。対照的に、同報通信モードでは、各参加者は１つのチャネルを生成し、音声およびビデオはネットワーク・エッジ・ノードで複製される。

テレビ会議通話の間、ユーザーＡは、ユーザーＢとの非公開会話を開始したいと思うが、他のどのユーザーにもこの会話を聞かれたくない。ユーザーＡとユーザーＢとの間の非公開音声会話は、他のユーザーが依然としてビデオを介して非公開会話の口唇の動きを見ることができるので、意図された効果をもたらさない。

有利なことに本発明は、ユーザーＡとユーザーＢが非公開会話をすることができるように、これらのユーザー間に非公開チャット・ルームを提供する。チャット・ルームは、例えば、テレビ会議アプリケーション内に統合されたチャット・ルーム・アプリケーションにより実現する。当然ながら上述のように、ハードウェア、ソフトウェア、またはこれらの任意の組合せを含めて、本発明の他の実現形態も可能である。

図２６は、本発明の説明に役立つ一実施例による、少なくとも３人の参加者間のテレビ会議セッションにおいて非公開会話チャネルを提供する方法を示す流れ図である。

３人の参加者のうちの第１の参加者が、３人の参加者のうちの第２の参加者を、非公開会話に参加するよう選択する（ステップ２６１０）。本発明の説明に役立つ一実施例によれば、第１の参加者は、テレビ会議セッションの参加者全員のリストから第２の参加者を選択する。

第１の参加者は、テレビ会議セッションが行われている間に、非公開チャット・ルーム会話に加わるよう誘う招待を含む非公開メッセージを第２の参加者に送信する（ステップ２６２０）。この招待は、第２の参加者に対して（例えば、第２の参加者の表示装置上に）表示される（ステップ２６３０）。ステップ２６２０は、ステップ２６１０でユーザーが最初に第２の参加者を選択すると自動的に行われるようにしてもよいことを理解されたい。

第２の参加者が招待を受諾すると決定した場合、受諾メッセージが第２の参加者から第１の参加者に送信される（ステップ２６４０）。第１の参加者と第２の参加者により非公開チャット・ルーム会話チャネルが確立され、第１の参加者と第２の参加者との間でメッセージが直接（サーバを介してではなく）送信される（ステップ２６５０）。第１の参加者と第２の参加者は、自分のコンピュータ端末上でメッセージを入力し、非公開会話の存在をテレビ会議セッションへの他の参加者（ここでは第３の参加者）に気付かれることなく、相互にメッセージを送信する。更に、１人または複数の追加の参加者を非公開会話に加えることもできる（ステップ２６６０）。

このように、３人以上のユーザー間で非公開チャット・ルームを生成することができることを理解されたい。例えば、ＡＢＣ社からの第１の参加者グループ（様々な場所に分散している）と、ＸＹＺ社からの第２の参加者グループとの間のテレビ会議交渉セッションにおいて、ＡＢＣ社からの第１のグループ間で非公開チャット・ルーム・チャネルを確立する。更に、複数の非公開会話チャネルを生成して同時に共存させることができることも理解されたい。

図２７は、本発明の説明に役立つ別の実施例による、Ｎ人の参加者（Ｎ＞３）がいるテレビ会議セッションにおいて３人の参加者間の非公開会話を提供する方法を示す流れ図である。非公開会話チャネルを使用して非公開セッションに参加しようとする３人の参加者には、テレビ会議クライアント＃１（クライアント＃１）２７０２、テレビ会議クライアント＃２（クライアント＃２）２７０４、テレビ会議クライアント＃３（クライアント＃３）２７０６が含まれる。非公開セッションに加わらないテレビ会議セッション参加者は図示されていない。

クライアント＃１２７０２は最初に、非公開会話に参加するようにクライアント＃２ ２７０４を選択し、クライアント＃２ ２７０４に非公開会話への招待を送信する（ステップ２７０５）。非公開会話への招待を受諾したことを示す受諾メッセージが、クライアント＃２ ２７０４からクライアント＃１ ２７０２に送信される（ステップ２７１０）。

クライアント＃１ ２７０２はまた、非公開会話に参加するようクライアント＃３ ２７０６を選択し、クライアント＃３ ２７０６に非公開会話への招待を送信する（ステップ２７１５）。非公開会話への招待を受諾したことを示す受諾メッセージが、クライアント＃３ ２７０６からクライアント＃１ ２７０２に送信される（ステップ２７２０）。

更新メッセージが、クライアント＃１ ２７０２からクライアント＃２ ２７０４に送信される（ステップ２７２５）。別の更新メッセージが、クライアント＃１ １７０２からクライアント＃３ ２７０６に送信される（ステップ２７３０）。更新メッセージを使用して、非公開会話に追加／選択されたユーザーが指定され、例えばユーザー識別子やＩＰアドレスなどの識別情報が含められる。

第１の非公開メッセージであるメッセージ１が、クライアント＃１ ２７０２からクライアント＃２ ２７０４に送信され（ステップ２７３５）、またクライアント＃１ ２７０２からクライアント＃３ ２７０６にも送信される（ステップ２７４０）。第２の非公開メッセージであるメッセージ２が、クライアント＃２ ２７０４からクライアント＃１ ２７０２に送信され（ステップ２７４５）、またクライアント＃２ ２７０４からクライアント＃３ ２７０６にも送信される（ステップ２７５０）。このように、本発明の方法を使用して、クライアント＃１、＃２、＃３は、テレビ会議セッションの他の参加者から検出不可能であり非公開である会話において相互に通信する。

本明細書では、説明に役立つ実施例を添付の図面に関連して述べたが、本発明は、これらの正確な実施例に限定されるわけではなく、当業者なら本発明の範囲または趣旨を逸脱することなく他の様々な変更および変形を加えることができることを理解されたい。このような変更および変形も全て、特許請求の範囲により定められる本発明の範囲に含まれるものとする。

本発明の説明に役立つ一実施例による、本発明を適用することのできるコンピュータ・システム１００を示すブロック図である。 本発明の説明に役立つ一実施例による、単一通信テレビ会議セッションを示すブロック図である。 本発明の説明に役立つ一実施例による、同報通信テレビ会議セッションを示すブロック図である。 本発明の説明に役立つ一実施例による、本発明を適用することのできるネットワーク２００を示すブロック図である。 本発明の説明に役立つ一実施例による、図２のテレビ会議サーバ２０５を示すブロック図である。 本発明の説明に役立つ一実施例による、図３のデータベース構成要素に備わるメンバ・データベース３１４のメンバ・データベース項目４００を示す図である。 本発明の説明に役立つ一実施例による、図３のデータベース構成要素３０２に備わるアクティブ・セッション・データベース３１２のアクティブ・セッション項目５００を示すブロック図である。 本発明の説明に役立つ一実施例による、シンプル・ネットワーク管理プロトコル（ＳＮＭＰ）クライアント−サーバ・アーキテクチャ６００を示すブロック図である。 本発明の説明に役立つ一実施例による、セッション開始プロトコル（ＳＩＰ）を使用してテレビ会議に登録する方法を示す図である。 本発明の説明に役立つ一実施例による、セッション開始プロトコル（ＳＩＰ）を使用して単一通信テレビ会議セッションをセットアップする方法を示す図である。 本発明の説明に役立つ一実施例による、ＩＮＶＩＴＥ要求がテレビ会議クライアント・アプリケーション＃１ ８０２から受け取られたとき（図８Ａのステップ８１０）に図２のテレビ会議サーバ２０５により実施されるステップを示す図である。 本発明の説明に役立つ一実施例による、図８Ａの方法を更に示す図である。 本発明の説明に役立つ別の実施例による、セッション開始プロトコル（ＳＩＰ）を使用して同報通信テレビ会議セッションをセットアップする方法を示す図である。 本発明の説明に役立つ別の実施例による、セッション開始プロトコル（ＳＩＰ）を使用してテレビ会議セッションをキャンセルする方法を示す図である。 本発明の説明に役立つ一実施例による、セッション開始プロトコル（ＳＩＰ）を使用して２つのクライアント間のテレビ会議セッションを終了する方法を示す図である。 本発明の説明に役立つ一実施例による、セッション開始プロトコル（ＳＩＰ）を使用して３つのクライアント間のテレビ会議セッションを終了する方法を示す図である。 本発明の説明に役立つ別の実施例による、セッション開始プロトコル（ＳＩＰ）を使用して３つのクライアント間のテレビ会議セッションを終了する方法を示す図である。 本発明の説明に役立つ一実施例による、解像度およびフレーム・レート調整のための情報伝送方法を示す図である。 本発明の説明に役立つ一実施例による、解像度およびフレーム・レート調整（クライアント２および３）の前の情報伝送を示す図である。 本発明の説明に役立つ一実施例による、解像度およびフレーム・レート調整（クライアント２および３）の後の情報伝送を示す図である。 本発明の説明に役立つ一実施例による、テレビ会議クライアント・アプリケーション１８００のブロック図である。 本発明の説明に役立つ一実施例による、図１８Ａのマルチメディア・インタフェース層１８０２に含まれる音声ミクサー１８９９を更に示すブロック図である。 本発明の説明に役立つ一実施例による、図１８Ａのマルチメディア・インタフェース層１８０２に含まれるエコー・キャンセル・モジュール１８９８を更に示すブロック図である。 本発明の説明に役立つ一実施例による、音声コーデック１８０４ａおよび／またはビデオ・コーデック１８０４ｂに備わるデコーダ１８９０により採用される方法を示す図である。 本発明の説明に役立つ一実施例による、ユーザー・プレーン・プロトコル・スタック２０００を示す図である。 本発明の説明に役立つ一実施例による、制御プレーン・プロトコル・スタック２１００を示す図である。 本発明の説明に役立つ一実施例による、図１８Ａのユーザー・インタフェース１８０８に対応するスクリーン・ショット２２００を示すブロック図である。 本発明の説明に役立つ一実施例による、ログイン・インタフェース２３００を示す図である。 本発明の説明に役立つ一実施例による、セッションを開始するためのユーザー選択インタフェース２４００を示すブロック図である。 本発明の説明に役立つ一実施例による、入来呼を受諾または拒否するための招待インタフェース２５００を示すブロック図である。 本発明の説明に役立つ一実施例による、少なくとも３人の参加者間のテレビ会議セッションにおいて非公開会話チャネルを提供する方法を示す流れ図である。 本発明の説明に役立つ別の実施例による、Ｎ人の参加者（Ｎ＞３）がいるテレビ会議セッションにおいて３人の参加者間の非公開会話を提供する方法を示す流れ図である。

Claims (18)

1. 少なくとも３人の参加者間のテレビ会議セッションにおいて非公開会話チャネルを提供する方法であって、
   非公開会話に加わるよう誘う非公開招待を送信するステップと、
   前記非公開招待に応答した非公開受諾を受信するステップと、
   前記非公開会話のメンバでない者を、前記非公開会話に対応する非公開メッセージを受信できないように除外するステップとを含む方法。
2. 除外する前記ステップが、前記メンバのうちの１人から前記メンバのうちの他の少なくとも１人に直接に非公開メッセージを送信するステップを含む、請求項１に記載の方法。
3. 前記非公開会話の前記メンバの間だけで前記非公開メッセージを交換するステップを更に含む、請求項１に記載の方法。
4. 前記非公開会話に追加のメンバを加えるステップを更に含む、請求項１に記載の方法。
5. 追加のメンバを加える前記ステップが、前記非公開会話に前記追加のメンバが加わることを示す更新メッセージを前記メンバに送信するステップを含む、請求項４に記載の方法。
6. 前記更新メッセージが、前記追加のメンバのインターネット・プロトコル（ＩＰ）アドレスを少なくとも含む、請求項５に記載の方法。
7. 前記更新メッセージが、前記追加のメンバのユーザー識別子を少なくとも含む、請求項５に記載の方法。
8. 前記非公開招待を表示するステップを更に含む、請求項１に記載の方法。
9. 前記非公開受諾を表示するステップを更に含む、請求項１に記載の方法。
10. 少なくとも３人の参加者間のテレビ会議セッションにおいて非公開会話チャネルを提供するためのシステムであって、
    非公開会話に加わるよう誘う非公開招待を送信する手段と、
    前記非公開招待に応答して非公開受諾を送信する手段と、
    前記非公開会話のメンバでない者を、前記非公開会話に対応する非公開メッセージを受信できないように除外する手段とを備えるシステム。
11. 前記除外する手段が、前記メンバのうちの１人から前記メンバのうちの他の少なくとも１人に直接に非公開メッセージを送信する手段を含む、請求項１０に記載のシステム。
12. 前記非公開会話の前記メンバの間だけで前記非公開メッセージを交換する手段を更に備える、請求項１０に記載のシステム。
13. 前記非公開会話に追加のメンバを加える手段を更に備える、請求項１０に記載のシステム。
14. 前記加える手段が、前記非公開会話に前記追加のメンバが加わることを示す更新メッセージを前記メンバに送信する手段を含む、請求項１３に記載のシステム。
15. 前記更新メッセージが、前記追加のメンバのインターネット・プロトコル（ＩＰ）アドレスを少なくとも含む、請求項１４に記載のシステム。
16. 前記更新メッセージが、前記追加のメンバのユーザー識別子を少なくとも含む、請求項１４に記載のシステム。
17. 前記非公開招待を表示する手段を更に備える、請求項１０に記載のシステム。
18. 前記非公開受諾を表示する手段を更に備える、請求項１０に記載のシステム。

Images