(57)【要約】  ネットワーク上でのテレビ会議セッションの自動開始方法が提供される。本方法は、テレビ会議セッションの時間及びクライアントを特定する予めの選択を受信するステップと、特定された時間にクライアントの少なくとも１つにテレビ会議セッションに関する案内メッセージを送信するステップとを有する。
2005513606.tif 000002
【特許請求の範囲】
【請求項１】
ネットワーク上でテレビ会議セッションを自動的に開始する方法であって、
前記テレビ会議セッションの時間及びクライアントを特定する予めの選択を受信するステップと、
前記特定された時間に前記クライアントの少なくとも１つに前記テレビ会議セッションに関する案内メッセージを送信するステップとを有することを特徴とする方法。
【請求項２】
請求項１記載の方法であって、さらに、
前記特定された時間及びクライアントを表す情報を受信するステップを有することを特徴とする方法。
【請求項３】
請求項２記載の方法であって、さらに、
前記情報を格納するステップを有することを特徴とする方法。
【請求項４】
請求項１記載の方法であって、さらに、
前記クライアントが前記特定された時間に前記テレビ会議セッションのため利用可能であることを確認するステップを有することを特徴とする方法。
【請求項５】
請求項４記載の方法であって、前記確認するステップは前記クライアントのスケジュールに対して前記特定された時間をチェックするステップを有することを特徴とする方法。
【請求項６】
請求項１記載の方法であって、さらに、
前記クライアントの中の拒絶をしたクライアントから拒絶メッセージを受信するステップを有することを特徴とする方法。
【請求項７】
請求項６記載の方法であって、前記拒絶メッセージは前記テレビ会議セッションを拒絶した理由を有することを特徴とする方法。
【請求項８】
請求項１記載の方法であって、さらに、
前記案内メッセージに応答して受け容れメッセージを受信するステップを有することを特徴とする方法。
【請求項９】
ネットワーク上でマルチキャストセッションを自動的に開始する方法であって、
前記マルチキャストセッションのため共通のマルチキャストインターネットプロトコル（ＩＰ）アドレスを割り当てるステップと、
前記共通のマルチキャストＩＰアドレスを特定する前記マルチキャストセッションに関する案内メッセージを予め選択された時間に少なくとも１つのクライアントに送信するステップとを有することを特徴とする方法。
【請求項１０】
請求項９記載の方法であって、さらに、
前記マルチキャストセッションのため前記共通のマルチキャストＩＰアドレスをコンテンツのソースに送信するステップを有することを特徴とする方法。
【請求項１１】
請求項９記載の方法であって、さらに、
前記少なくとも１つのクライアントの対応するクライアント装置に前記コンテンツを記録する能力を提供するステップを有することを特徴とする方法。
【請求項１２】
請求項９記載の方法であって、さらに、
前記マルチキャストセッションが前記予め選択された時間に行われることを、前記予め選択された時間の実際の到来前に前記少なくとも１つのクライアントに通知するステップを有することを特徴とする方法。
【請求項１３】
請求項９記載の方法であって、さらに、
前記案内メッセージに応答して前記少なくとも１つのクライアントの中の受け容れたクライアントからＩＧＭＰ（Ｉｎｔｅｒｎｅｔ  Ｇｒｏｕｐ  Ｍｕｌｔｉｃａｓｔ  Ｐｒｏｔｏｃｏｌ）を受信するステップを有することを特徴とする方法。
【請求項１４】
請求項９記載の方法であって、さらに、
前記予め選択された時間とクライアントを表す情報を受信するステップを有することを特徴とする方法。
【請求項１５】
請求項１４記載の方法であって、さらに、
前記情報を格納するステップを有することを特徴とする方法。
【請求項１６】
ネットワーク上でテレビ会議セッションを自動的に開始するシステムであって、
前記テレビ会議セッションの時間及びクライアントを特定する予めの選択を受信する手段と、
前記特定された時間に前記クライアントの少なくとも１つに前記テレビ会議セッションに関する案内メッセージを送信する手段とを有することを特徴とするシステム。
【請求項１７】
請求項１６記載のシステムであって、さらに、
前記特定された時間及びクライアントを表す情報を受信する手段を有することを特徴とするシステム。
【請求項１８】
請求項１７記載のシステムであって、さらに、
前記情報を格納する手段を有することを特徴とするシステム。
【請求項１９】
請求項１６記載のシステムであって、さらに、
前記クライアントが前記特定された時間に前記テレビ会議セッションのため利用可能であることを確認する手段を有することを特徴とするシステム。
【請求項２０】
請求項１９記載のシステムであって、前記確認する手段は前記クライアントのスケジュールに対して前記特定された時間をチェックする手段を有することを特徴とするシステム。
【請求項２１】
請求項１６記載のシステムであって、さらに、
前記クライアントの中の拒絶をしたクライアントから拒絶メッセージを受信する手段を有することを特徴とするシステム。
【請求項２２】
請求項２１記載のシステムであって、前記拒絶メッセージは前記テレビ会議セッションを拒絶した理由を有することを特徴とするシステム。
【請求項２３】
請求項１６記載のシステムであって、さらに、
前記案内メッセージに応答して受け容れメッセージを受信する手段を有することを特徴とするシステム。
【請求項２４】
ネットワーク上でマルチキャストセッションを自動的に開始するシステムであって、
前記マルチキャストセッションのため共通のマルチキャストインターネットプロトコル（ＩＰ）アドレスを割り当てる手段と、
前記共通のマルチキャストＩＰアドレスを特定する前記マルチキャストセッションに関する案内メッセージを予め選択された時間に少なくとも１つのクライアントに送信する手段とを有することを特徴とするシステム。
【請求項２５】
請求項２４記載のシステムであって、さらに、
前記マルチキャストセッションのため前記共通のマルチキャストＩＰアドレスをコンテンツのソースに送信する手段を有することを特徴とするシステム。
【請求項２６】
請求項２４記載のシステムであって、さらに、
前記少なくとも１つのクライアントの対応するクライアント装置に前記コンテンツを記録する手段を有することを特徴とするシステム。
【請求項２７】
請求項２４記載のシステムであって、さらに、
前記マルチキャストセッションが前記予め選択された時間に行われることを、前記予め選択された時間の実際の到来前に前記少なくとも１つのクライアントに通知する手段を有することを特徴とするシステム。
【請求項２８】
請求項２４記載のシステムであって、さらに、
前記案内メッセージに応答して前記少なくとも１つのクライアントの中の受け容れたクライアントからＩＧＭＰ（Ｉｎｔｅｒｎｅｔ  Ｇｒｏｕｐ  Ｍｕｌｔｉｃａｓｔ  Ｐｒｏｔｏｃｏｌ）を受信する手段を有することを特徴とするシステム。
【請求項２９】
請求項２４記載のシステムであって、さらに、
前記予め選択された時間とクライアントを表す情報を受信する手段を有することを特徴とするシステム。
【請求項３０】
請求項２９記載のシステムであって、さらに、
前記情報を格納する手段を有することを特徴とするシステム。
【請求項３１】
ネットワーク上でテレビ会議セッションに参加する方法であって、
開催される前記テレビ会議セッションに対し予め選択された時間に前記テレビ会議セッションに関する案内メッセージを受信する能力を提供するステップと、
前記案内メッセージに応答して受け容れメッセージを送信する能力を提供するステップと、
前記受け容れメッセージの送信に応答して前記テレビ会議セッションに対応するコンテンツを自動的に受信する能力を提供するステップとを有することを特徴とする方法。
【請求項３２】
請求項３１記載の方法であって、さらに、
該方法が前記コンテンツの受信前に終了されるように、拒絶メッセージを送信する能力を提供するステップを有することを特徴とする方法。
【請求項３３】
請求項３２記載の方法であって、前記拒絶メッセージは前記テレビ会議セッションを拒絶する理由を有することを特徴とする方法。
【請求項３４】
ネットワーク上でマルチキャストセッションに参加する方法であって、
前記マルチキャストセッションのための共通のマルチキャストＩＰアドレスを特定する前記マルチキャストセッションに関する案内メッセージを予め選択された時間に受信する能力を提供するステップと、
前記案内メッセージに応答して受け容れメッセージを送信する能力を提供するステップと、
前記受け容れメッセージの送信に応答して前記マルチキャストセッションに対応するコンテンツを自動的に受信する能力を提供するステップとを有することを特徴とする方法。
【請求項３５】
請求項３４記載の方法であって、さらに、
前記コンテンツを記録する能力を提供するステップを有することを特徴とする方法。
【請求項３６】
請求項３４記載の方法であって、さらに、
前記マルチキャストセッションが前記予め選択された時間に行われることを、前記予め選択された時間の実際の到来前に対応するクライアントに通知する能力を提供するステップを有することを特徴とする方法。
【請求項３７】
請求項３４記載の方法であって、さらに、
前記受け容れメッセージを送信する能力を提供するステップは、ＩＧＭＰメッセージを前記ネットワークに送信する能力を提供するステップを有することを特徴とする方法。
【発明の詳細な説明】
【発明の詳細な説明】
【０００１】
発明の背景
［関連出願の相互参照］
これは、２００１年１２月１５日に出願された仮出願番号第６０／３４１，８１９号（代理人整理番号第ＰＵ０１０３０９号）「サーバ呼び出しタイムスケジューリングテレビ会議（ＳＥＲＶＥＲ  ＩＮＶＯＫＥＤ  ＴＩＭＥ  ＳＣＨＥＤＵＬＥＤ  ＶＩＤＥＯ  ＣＯＮＦＥＲＥＮＣＥ）」の３５Ｕ．Ｓ．Ｃ．§１１９による権利を主張する非仮出願であり、上記仮出願は共通して譲渡され、参照することによりここに含まれる。本出願はまた、２００２年３月２０日に出願された仮出願第６０／３６６，３３１号「テレビ会議システムアーキテクチャ（ＶＩＤＥＯＣＯＮＦＥＲＥＮＣＥ  ＳＹＳＴＥＭ  ＡＲＣＨＩＴＥＣＴＵＲＥ）」に共通に譲渡され、参照することによりここに含まれる。本出願はまた、２００１年１２月１５日に出願された共通に譲渡された仮出願第６０／３４１，７２０号「テレビ会議帯域幅選択機構（ＶＩＤＥＯＣＯＮＦＥＲＥＮＣＩＮＧ  ＢＡＮＤＷＩＤＴＨ  ＳＥＬＥＣＴＩＯＮ  ＭＥＣＨＡＮＩＳＭ）に関連し、参照することによりここに含まれ、また２００１年１２月１５日に出願された共通に譲渡された仮出願第６０／３４１，６７１号「時間予約ベースによるＱｏＳ設定（ＱＵＡＬＩＴＹ  ＯＦ  ＳＥＲＶＩＣＥ  ＳＥＴＵＰ  ＯＮ  Ａ  ＴＩＭＥ  ＲＥＳＥＲＶＡＴＩＯＮ  ＢＡＳＩＳ）」に関連し、参照することによりここに含まれ、また２００１年１２月１５日に出願された共通に譲渡された仮出願第６０／３４１，７９７号「テレビ会議呼出し設定方法（ＶＩＤＥＯ  ＣＯＮＦＥＲＥＮＣＩＮＧ  ＣＡＬＬ  ＳＥＴ  ＵＰ  ＭＥＴＨＯＤ）」に関連し、参照することによりここに含まれ、また２００１年１２月１５日に出願された共通に譲渡された仮出願第６０／３４１，８００号「テレビ会議セッションのユニキャストからマルチキャストへのスイッチ処理（ＶＩＤＥＯＣＯＮＦＥＲＥＮＣＥ  ＳＥＳＳＩＯＮ  ＳＷＩＴＣＨＩＮＧ  ＦＲＯＭ  ＵＮＩＣＡＳＴ  ＴＯ  ＭＵＬＴＩＣＡＳＴ）」に関連し、参照することによりここに含まれ、また２００１年１２月１５日に出願された共通に譲渡された仮出願第６０／３４１，７９９号「テレビ会議システムでのプライベート会話チャンネルを提供する方法及びシステム（ＭＥＴＨＯＤ  ＳＹＳＴＥＭ  ＦＯＲ  ＰＲＯＶＩＤＩＮＧ  Ａ  ＰＲＩＶＡＴＥ  ＣＯＮＶＥＲＳＡＴＩＯＮ  ＣＨＡＮＮＥＬ  ＩＮ  Ａ  ＶＩＤＥＯＣＯＮＦＥＲＥＮＣＩＮＧ  ＳＹＳＴＥＭ）」に関連し、参照することによりここに含まれ、また２００１年１２月１５日に出願された共通に譲渡された仮出願第６０／３４１，８０１号「テレビ会議アプリケーションユーザインタフェース（ＶＩＤＥＯＣＯＮＦＥＲＥＮＣＥ  ＡＰＰＬＩＣＡＴＩＯＮ  ＵＳＥＲ  ＩＮＴＥＲＦＡＣＥ）」に関連し、参照することによりここに含まれる。
【０００２】
［発明の技術分野］
本発明は、一般にテレビ会議に関し、より詳細にはネットワーク上のサーバによりタイムスケジューリングされたテレビ会議セッションを自動的に開始する方法に関する。
［発明の背景］
異なるテレビ会議システムの間でのテレビ会議セッションでは、共通の音声及び映像フォーマットがセッション設定時に決定される。従って、時間の遅延は上記決定が行われるセッション設定時に課せられる。
【０００３】
このため、従来技術における問題点を解決するネットワーク上のサーバによりタイムスケジューリングされたテレビ会議セッションを自動的に開始する方法を有することが望ましく、かつ大いに有益であろう。
［発明の概要］
上記問題点は、従来技術の他の関連する問題点と共に、ネットワーク上のサーバによるタイムスケジューリングテレビ会議セッションの自動開始方法に関する本発明により解決される。
【０００４】
本発明は、ユニキャストまたはマルチキャストされうるタイムスケジューリングテレビ会議セッションのサーバによる自動的な開始を可能にする。さらに、本発明は、マルチキャストを利用することにより、ネットワークを介したタイムスケジューリングされたコンテンツ（音声及び／または映像）の配信のサーバによる自動的な開始を可能にする。
【０００５】
本発明の一特徴によると、ネットワーク上でのテレビ会議セッションの自動開始方法が提供される。本方法は、テレビ会議セッションの時間及びクライアントを特定する予めの選択を受信するステップと、前記特定された時間に前記クライアントの少なくとも１つに前記テレビ会議セッションに関する案内メッセージを送信するステップとを有する。
【０００６】
本発明の他の特徴によると、ネットワーク上でのマルチキャストセッションの自動開始方法が提供される。本方法は、マルチキャストセッションのため共通のマルチキャストインターネットプロトコル（ＩＰ）アドレスを割り当てるステップと、前記共通のマルチキャストＩＰアドレスを特定する前記マルチキャストセッションに関する案内メッセージを予め選択された時間に少なくとも１つのクライアントに送信するステップとを有する。
【０００７】
本発明のさらなる他の特徴によると、ネットワーク上でのテレビ会議セッションの自動開始システムが提供される。本システムは、テレビ会議セッションの時間及びクライアントを特定する予めの選択を受信する手段と、前記特定された時間に前記クライアントの少なくとも１つに前記テレビ会議セッションに関する案内メッセージを送信する手段とを有する。
【０００８】
本発明のさらなる他の特徴によると、ネットワーク上でのマルチキャストセッションの自動開始システムが提供される。本システムは、マルチキャストセッションのため共通のマルチキャストインターネットプロトコル（ＩＰ）アドレスを割り当てる手段と、前記共通のマルチキャストＩＰアドレスを特定する前記マルチキャストセッションに関する案内メッセージを予め選択された時間に少なくとも１つのクライアントに送信する手段とを有する。
【０００９】
本発明のさらなる他の特徴によると、ネットワーク上でのテレビ会議セッションへの参加方法が提供される。本方法は、開催される前記テレビ会議セッションに対し予め選択された時間に前記テレビ会議セッションに関する案内メッセージを受信する能力を提供するステップと、前記案内メッセージに応答して受け容れメッセージを送信する能力を提供するステップと、前記受け容れメッセージの送信に応答して前記テレビ会議セッションに対応するコンテンツを自動的に受信する能力を提供するステップとを有する。
【００１０】
本発明のさらなる他の特徴によると、ネットワーク上でのマルチキャストセッションへの参加方法が提供される。本方法は、マルチキャストセッションのための共通のマルチキャストＩＰアドレスを特定する前記マルチキャストセッションに関する案内メッセージを予め選択された時間に受信する能力を提供するステップと、前記案内メッセージに応答して受け容れメッセージを送信する能力を提供するステップと、前記受け容れメッセージの送信に応答して前記マルチキャストセッションに対応するコンテンツを自動的に受信する能力を提供するステップとを有する。
【００１１】
本発明の上記及び他の様相、特徴及び効果は、添付された図面と共に読まれる好適な実施例の以下の詳細な説明から明らかとなろう。
［発明の詳細な説明］
本発明は、ネットワーク上のサーバによりタイムスケジューリングされたテレビ会議セッションを自動的に開始する方法に関する。ここで使われる「開催参加者（ｉｎｉｔｉａｔｉｎｇ  ｐａｒｔｉｃｉｐａｎｔ）」という用語は、テレビ会議セッションを開始する人をいい、「他の参加者」という用語は、開催参加者が当該テレビ会議への参加を所望するその他の人々をいう。
【００１２】
本発明は、ハードウェア、ソフトウェア、ファームウェア、特定用途プロセッサあるいはそれらを組み合わせたものという様々な形態で実現されるかもしれないということが理解されるべきである。好ましくは、本発明は、ハードウェアとソフトウェアの組み合わせとして実現される。さらに、好ましくは、ソフトウェアはプログラム記憶装置に実体的に具体化されるアプリケーションプログラムとして実現される。アプリケーションプログラムは、任意の適当なアーキテクチャを有するマシーンにロード及び実行されるかもしれない。好ましくは、マシーンは、１つ以上のＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）と、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）と、入出力（Ｉ／Ｏ）インタフェースのようなハードウェアを有するコンピュータプラットフォーム上で実現される。コンピュータプラットフォームはまた、オペレーティングシステムとマイクロ命令コードを有する。ここで説明される様々なプロセス及び機能は、オペレーティングシステムを介し実行されるマイクロ命令コードの一部またはアプリケーションプログラムの一部（あるいはそれらを組み合わせたもの）であってもよい。さらに、他の様々な周辺装置が追加的データ記憶装置及び印刷装置のようなコンピュータプラットフォームに接続されてもよい。
【００１３】
さらに、添付された図面に示されるシステム構成要素及び方法のステップの一部は好ましくはソフトウェアにより実現されるため、システム構成要素（あるいはプロセスステップ）間の実際の接続は、本発明のプログラミング方法に応じて異なるかもしれない。ここで教示が与えられると、当業者は本発明の上記及び類似の実現形態あるいは構成を考えることができるであろう。
【００１４】
図１Ａは、本発明の例示的な一実施例による本発明が適用されるコンピュータシステム１００を示すブロック図である。コンピュータ処理システム１００は、システムバス１０４を介し他の構成要素に動作可能に接続される少なくとも１つのプロセッサ（ＣＰＵ）１０２を有する。ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）１０６と、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）１０８と、ディスプレイアダプタ１１０と、Ｉ／Ｏアダプタ１１２と、ユーザインタフェースアダプタ１１４と、音声アダプタ１９９と、ネットワークアダプタ１９８とが、システムバス１０４に動作可能に接続される。
【００１５】
表示装置１１６は、ディスプレイアダプタ１１０によりシステム部ス１０４に動作可能に接続される。ディスク記憶装置（例えば、磁気または光ディスク記憶装置）１１８は、Ｉ／Ｏアダプタ１１２によりシステムバス１０４に動作可能に接続される。
【００１６】
マウス１２０とキーボード１２２は、ユーザインタフェースアダプタ１１４によりシステムバス１０４に動作可能に接続される。マウス１２０とキーボード１２２は、システム１００に対する情報の入出力に利用される。
【００１７】
少なくとも１つのスピーカー（以降「スピーカー」）１９７が、音声アダプタ１９９によりシステムバス１０４に動作可能に接続される。
【００１８】
（デジタル及び／またはアナログ）モデム１９６が、ネットワークアダプタ１９８によりシステムバス１０４に動作可能に接続される。
【００１９】
本発明の例示的な一実施例によるポリシーベースネットワーク管理（ＰＢＮＭ）が説明される。ＰＢＮＭは、ネットワークを管理するためのポリシーを定義及び配布する能力を提供する技術である（本発明が適用される一例となるネットワークが図２に関していかに説明される）。これらのポリシーにより、帯域幅やセキュリティのような上羽陽名ネットワークリソースの協調的な制御が可能になる。ＰＢＮＭは、ＩＰベーステレビ会議のような、ネットワークに対する識別処理を要するアプリケーションを可能にする。ＰＢＮＭは、異なるタイプのアプリケーションが１つのネットワークに共生し、必要なリソースを各アプリケーションに提供することを可能にする基礎を与えるものである。
【００２０】
さらなる詳細では、ＰＢＮＭは、ネットワークリソースを利用するアプリケーション及びユーザに対するポリシーを定義する。例えば、重要な商用アプリケーションには最も高い優先度とネットワークの帯域幅の一定割合が与えられ、ＩＰを介したテレビ会議及び音声には次に高い優先度が与えられ、最後に、厳しい帯域幅あるいは時間に関する重要な制限を持たないウェブトラフィックやファイル転送には、ネットワークリソースの残りが与えられる。ユーザとアプリケーションのこのような区別が、ＰＢＮＭを利用して実現される。
【００２１】
テレビ会議システムは、テレビ会議アプリケーションに対応するポリシーをネットワークポリシーサーバに問い合わせることにより、ＰＢＮＭシステムと結び付けられる。テレビ会議サーバは、ネットワークポリシーサーバからポリシーを取得し、受け取ったパラメータに基づきテレビ会議のためにネットワーク上で利用可能なリソースを決定する。このポリシーは、典型的には例えば、ある期間においてこのアプリケーションに利用可能な帯域幅、あるいは特定ユーザのみに利用可能な帯域幅に対応する。この構成は、例えば、そのポリシー及び／または部分を追加、削除、置換、修正など行うことにより容易に変更される。この結果、テレビ会議サーバは、当該ポリシーに与えられた情報を利用して、ネットワーク上の会議セッションの管理を行う。
【００２２】
図２は、本発明の例示的な一実施例による本発明が適用されるネットワーク２００を示すブロック図である。ネットワーク２００は、テレビ会議サーバ２０５と、ポリシーＱｏＳマネージャ２１０と、ＭＡＤＣＡＰサーバ２１５と、第１コンピュータ群２２０ａ〜２２０ｆと、第１ローカルエリアネットワーク２２５と、第１ルータ２４０と、第２コンピュータ群２３０ａ〜２３０ｅと、第２ローカルエリアネットワーク２３５と、第２ルータ２４５と、ワイドエリアネットワーク２５０とを有する。
【００２３】
本発明の例示的な一実施例によるサーバアーキテクチャが説明される。図３は、本発明の例示的な一実施例による図２のテレビ会議サーバ２０５を示すブロック図である。テレビ会議サーバ２０５は、以下の３つの基本エンティティ、データベースエンティティ３０２と、ネットワーク通信エンティティ３０４と、セッション管理エンティティ３０６とを有するものと考えられる。
【００２４】
セッション管理エンティティ３０６は、テレビ会議セッションの設置と解消を管理するためのものである。セッション管理エンティティ３０６はまた、テレビ会議サーバ２０５の主要な制御の大部分を提供する。セッション管理エンティティ３０６は、セッション管理エンティティ３０６の機能を実現するセッションマネージャ３２０を有する。
【００２５】
ネットワーク通信エンティティ３０４は、テレビ会議システムに利用される多数の様々なプロトコルをカプセル化するためのものである。これらのプロトコルには、遠隔管理のためのＳＮＭＰ（Ｓｉｍｐｌｅ  Ｎｅｔｗｏｒｋ  Ｍａｎａｇｅｍｅｎｔ  Ｐｒｏｔｏｃｏｌ）と、ＣＯＰＳ（Ｃｏｍｍｏｎ  Ｏｐｅｎ  Ｐｏｌｉｃｙ  Ｓｅｒｖｉｃｅｓ）やポリシー管理のためのＬＤＡＰ（Ｌｉｇｈｔｗｅｉｇｈｔ  Ｄｉｒｅｃｔｏｒｙ  Ａｃｃｅｓｓ  Ｐｒｏｔｏｃｏｌ）のような他のポリシー、マルチキャストアドレス割り当てのためのＭＡＤＣＡＰ（Ｍｕｌｔｉｃａｓｔ  Ａｄｄｒｅｓｓ  Ｄｙｎａｍｉｃ  Ｃｌｉｅｎｔ  Ａｌｌｏｃａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）、テレビ会議セッション管理のためのＳＩＰ（Ｓｅｓｓｉｏｎ  Ｉｎｉｔｉａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）、及び分散テレビ会議サーバ管理のためのサーバ・ツー・サーバ（Ｓｅｒｖｅｒ  ｔｏ  Ｓｅｒｖｅｒ）メッセージ処理が含まれる。このため、ネットワーク通信エンティティ３０４は、ＳＮＭＰモジュール３０４ａと、ＬＤＡＰクライアントモジュール３０４ｂと、ＭＡＤＣＡＰクライアントモジュール３０４ｃと、ＳＩＰモジュール３０４ｄと、サーバ・ツー・サーバ管理モジュール３０４ｅとを有する。さらに、上記構成要素３０４ａ〜３０４ｅは、以下の構成要素、遠隔管理端末３８２と、ネットワークポリシーサーバ（帯域幅ブローカー）３８４と、ＭＡＤＣＡＰサーバ２１５と、デスクトップ会議クライアント３８８と、他のテレビ会議サーバ３９０とそれぞれ通信する。このような通信は、プロトコルモジュール３３０としてまとめて表されるＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）と、ＵＤＰ（Ｕｓｅｒ  Ｄａｔａｇｒａｍ  Ｐｒｏｔｏｃｏｌ）と、ＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）を利用して実現されてもよい。上記プロトコル及び対応する構成要素は単なる例示のためのものであり、他のプロトコル及び対応する構成要素が、本発明の趣旨及び範囲を維持しながら、容易に利用されうるということは理解されるべきである。
【００２６】
さらに、テレビ会議サーバ２０５のアーキテクチャはまた、テレビ会議セッションからのコンテンツの送受信のため、携帯装置のユーザがＶＰＮ（Ｖｉｒｔｕａｌ  Ｐｒｉｖａｔｅ  Ｎｅｔｗｏｒｋ）を介し企業インフラストラクチャに接続するのに適したものであるということが理解されるべきである。
【００２７】
データベースエンティティ３０２は、以下の４つのデータベース、すなわち、スケジューリングデータベース３１０と、アクティブセッションデータベース３１２と、メンバーデータベース３１４と、ネットワークアーキテクチャデータベース３１６とを有する。
【００２８】
テレビ会議システムサーバ２０５はさらに、企業ＬＤＡＰサーバ（ユーザ情報）３４０と選択的な外部データベース３４２とを有するか、あるいは少なくともそれらとのインタフェースを提供する。選択的な外部データベース３４２は、ＬＤＡＰクライアント３０４ｂを有する。
【００２９】
本発明の例示的な一実施例による図３のデータベースエンティティ３０２に含まれるメンバーデータベース３１４が説明される。メンバーデータベース３１４は、テレビ会議システムにログインしている各ユーザに関する情報を有する。一例として、メンバーデータベース３１４には、各ユーザに関する以下の情報、すなわち、ユーザ名と、パスワードと（適用可能である場合）、サポートされている映像コーデック（ｖｉｄｅｏ  ｃｏｄｅｃ）及びキャプチャ解像度と、サポートされている音声コーデックと、現在のＩＰアドレスと、現在の呼出し番号と（現在、アクティブな呼出しのメンバーである場合）、利用可能性（利用可能か利用不可か）と、ビデオカメラのタイプ及びモデルと、ネットワークの位置と（各位置は限定的な帯域幅のワイドエリアネットワークリンクにより接続される）、ＣＰＵのタイプ及び処理能力とが保持されるかもしれない。上記アイテムは単なる例示のためのものであり、上記アイテムの一部またはすべてに加えて、あるいはそれらの代わりに各ユーザに関する他のアイテムが、本発明の趣旨及び範囲を維持しながら、メンバーデータベース３１４に保持されてもよい。
【００３０】
図４は、本発明の例示的な一実施例による図３のデータベースエンティティ３０２に含まれるメンバーデータベース３１４のメンバーデータベースエントリ４００を示す図である。図４の例示的な実施例では、メンバーデータベース３１４は、シンプルなリンクリストを利用して実現される。しかしながら、本発明の他の実施例では、異なる実施形態のメンバーデータベース３１４が、本発明の趣旨及び範囲を維持しながら、利用されるかもしれないということが理解されるであろう。一例として、ＬＤＡＰタイプのデータベースが、メンバー情報を記録するため利用されるかもしれない。
【００３１】
本発明の例示的な一実施例による図３のデータベースエンティティ３０２に含まれるアクティブセッションデータベース３１２が説明される。アクティブセッションデータベース３１２は、現在行われている各テレビ会議セッションに関する情報を有する。一例として、アクティブセッションデータベース３１２には、各呼出しに対する以下の情報、すなわち、呼出しＩＤと、記述と、マルチキャスト（イエス／ノー）と、マルチキャストの場合、マルチキャストＩＰアドレスと、各参加者に対するネットワーク位置と、現在送信解像度と、現在送信ビットレートと、映像及び音声コーデックと、パブリック／プライベート呼出し（他の参加者が加われるか？）と、セッションのスケジューリングされた時間と、セッション開始時刻と、任意の追加的オプションとが維持されるかもしれない。上記アイテムは単なる例示のためのものであり、上記アイテムの一部またはすべてに加えて、あるいはそれらの代わりに各ユーザに関する他のアイテムが、本発明の趣旨及び範囲を維持しながら、アクティブセッションデータベース３１２に保持されてもよい。
【００３２】
図５は、本発明の例示的な一実施例による図３のデータベースエンティティ３０２に含まれるアクティブセッションデータベース３１２のアクティブセッションデータベースエントリ５００を示す図である。図５の例示的な実施例では、アクティブセッションデータベース３１２は、シンプルなリンクリストを利用して実現される。しかしながら、本発明の他の実施例では、異なる実施形態のアクティブセッションデータベース３１２が、本発明の趣旨及び範囲を維持しながら、利用されるかもしれないということが理解されるであろう。
【００３３】
図３を再び参照するに、本発明の例示的な一実施例による図３のデータベースエンティティ３０２に含まれるネットワークアーキテクチャデータベース３１６が説明される。ネットワークアーキテクチャデータベース３１６は、ネットワーク全体の完全なマッピングを有する。ネットワークアーキテクチャデータベース３１６は、各アクティブなネットワーク要素（すなわち、ＩＰルータ、イーサネット（登録商標）スイッチなど）に関する情報と、ルータとスイッチを接続するリンクに関する情報とを有する。ネットワークの帯域幅とＱｏＳを効果的に管理するため、テレビ会議サーバ２０５はこの情報を知る必要がある。
【００３４】
同時に実行可能なテレビ会議セッション数と、テレビ会議セッションビットレートと、帯域幅制限に関するポリシー情報が、ネットワークアーキテクチャデータベース３１６に定義されうる。ネットワークアーキテクチャは、ネットワークアーキテクチャデータベース３１６において重み付けされたグラフとして表すことができる。ネットワークアーキテクチャデータベース３１６は、テレビ会議サーバ２０５においてオプショナルなデータベースであるということが理解されるであろう。ポリシーサーバ２１０から要求されたポリシーをキャッシュするためネットワークアーキテクチャデータベース３１６は利用されるかもしれない。
【００３５】
本発明の例示的な一実施例による図３のデータベースエンティティ３０２に含まれるスケジューリングデータベース３１０が説明される。スケジューリングデータベース３１０は、テレビ会議システムの利用時間をユーザが確保するスケジュールを含む。これは例えば、ワイドエリアネットワーク２５０を介しあるリンクに関して同時に実行可能なテレビ会議セッション数に関して情報システム部門が有するポリシーに依存する。
【００３６】
図３のネットワーク通信エンティティ３０４が説明される。ネットワーク通信エンティティ３０４は、ＳＮＭＰ（Ｓｉｍｐｌｅ  Ｎｅｔｗｏｒｋ  Ｍａｎａｇｅｍｅｎｔ  Ｐｒｏｔｏｃｏｌ）モジュール３０４ａと、ＬＤＡＰ（Ｌｉｇｈｔｗｅｉｇｈｔ  Ｄｉｒｅｃｔｏｒｙ  Ａｃｃｅｓｓ  Ｐｒｏｔｏｃｏｌ）クライアントモジュール３０４ｂと、ＭＡＤＣＡＰ（Ｍｕｌｔｉｃａｓｔ  Ａｄｄｒｅｓｓ  Ｄｙｎａｍｉｃ  Ｃｌｉｅｎｔ  Ａｌｌｏｃａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）クライアントモジュール３０４ｃと、ＳＩＰ（Ｓｅｓｓｉｏｎ  Ｉｎｉｔｉａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）モジュール３０４ｄと、及びサーバ・ツー・サーバ（Ｓｅｒｖｅｒ  ｔｏ  Ｓｅｒｖｅｒ）管理モジュール３０４ｅとを有する。
【００３７】
本発明の例示的な一実施例による図３のネットワーク通信エンティティ３０４に含まれるＳＮＭＰモジュール３０４ａが説明される。図６は、本発明の例示的な一実施例によるＳＮＭＰクライアント−サーバアーキテクチャ６００を示すブロック図である。アーキテクチャ６００はＳＮＭＰモジュール３０４ａの一実施形態を表すが、本発明は図６に示されるアーキテクチャに限定されるものではなく、本発明の趣旨及び範囲を維持しながら、他のＳＮＭＰアーキテクチャがまた利用されてもよい。ＳＮＭＰは、テレビ会議サーバの遠隔管理及び監視に利用される。
【００３８】
ＳＮＭＰクライアント−サーバアーキテクチャ６００は、ＳＮＭＰ管理局６１０とＳＮＭＰ管理エンティティ６２０とを有する。ＳＮＭＰ管理局６１０は、管理アプリケーション６１０ａとＳＮＭＰマネージャ６１０ｂとを有する。ＳＮＭＰ管理エンティティ６２０は、管理リソース６２０ａと、ＳＮＭＰ管理オブジェクト６２０ｂと、ＳＮＭＰエージェント６２０ｃとを有する。さらに、ＳＮＭＰ管理局６１０とＳＮＭＰ管理エンティティ６２０のそれぞれはさらに、ＵＤＰレイヤ６３０と、ＩＰレイヤ６４０と、ＭＡＣ（Ｍｅｄｉｕｍ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ）レイヤ６５０と、物理層６６０とを有する。
【００３９】
ＳＮＭＰエージェント６２０ｃは、ＳＮＭＰ管理局６１０からの監視及び管理を可能にする。ＳＮＭＰエージェント６２０ｃは、基本的に、ＳＮＭＰ管理局６１０からの情報及びアクションのリクエストに応答するためのものである。ＳＮＭＰ管理局６１０は、ＳＮＭＰアーキテクチャ６００のサーバである。ＳＮＭＰ管理局６１０は、ネットワーク上のエージェントを管理する中心的エンティティである。ＳＮＭＰ管理局６１０は、管理者がＳＮＭＰエージェント６２０ｃからの統計データの回収と、ＳＮＭＰエージェント６２０ｃの設定パラメータの変更を行うことを可能にする機能を実行する。
【００４０】
ＳＮＭＰモデルを利用して、テレビ会議サーバ２０５のリソースはこれらのリソースをオブジェクトとして表すことにより管理することができる。各オブジェクトは、管理されているエージェントの一特徴を表すデータ変数である。このオブジェクトの集合体は、ＭＩＢ（Ｍａｎａｇｅｍｅｎｔ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｂａｓｅ）として通常呼ばれている。ＭＩＢは、ＳＮＭＰ管理局６１０のＳＮＭＰエージェント６２０ｃのアクセスポイントの集合体として機能する。ＳＮＭＰ管理局６１０は、ＳＮＭＰエージェント６２０ｃのＭＩＢオブジェクトの値を抽出することにより監視を行うことができる。ＳＮＭＰ管理局６１０はまた、アクションをＳＮＭＰエージェント６２０ｃにおいて実行させることができ、またＳＮＭＰエージェント６２０ｃの設定を変更することができる。
【００４１】
ＳＮＭＰはＩＰレイヤ６４０を介し動作し、それのトランスポートプロトコルのためにＵＤＰレイヤ６３０を利用する。
【００４２】
ＳＮＭＰ管理プロトコルで利用される基本的なメッセージは、ＧＥＴと、ＳＥＴと、ＴＲＡＰである。ＧＥＴメッセージは、ＳＮＭＰ管理局６１０がＳＮＭＰエージェント６２０ｃにおけるオブジェクトの値を抽出するのを可能にする。ＳＥＴメッセージは、ＳＮＭＰ管理局６１０がＳＮＭＰエージェント６２０ｃにおけるオブジェクトの値を設定するのを可能にする。ＴＲＡＰメッセージは、ＳＮＭＰエージェント６２０ｃがＳＮＭＰ管理局６１０に重要なイベントを通知するのを可能にする。
【００４３】
本発明の例示的な一実施例によるＳＮＭＰ管理エンティティ６２０に含まれるＳＮＭＰ管理リソース６２０ａが説明される。遠隔管理は、テレビ会議サーバ２０５内の以下のリソース、すなわち、テレビ会議サーバ２０５と、アクティブセッション及び関連する統計データと、セッションログと、テレビ会議のためのネットワークポリシーと、ＳＩＰ（Ｓｅｓｓｉｏｎ  Ｉｎｉｔｉａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）パラメータ及び統計データと、ＭＡＤＣＡＰパラメータ及び統計データとを監視及び／または制御することができる。
【００４４】
ＳＮＭＰ管理局６１０から、以下の３つのタイプのＳＮＭＰメッセージ、すなわち、ＧｅｔＲｅｑｕｅｓｔと、ＧｅｔＮｅｘｔＲｅｑｕｅｓｔと、ＳｅｔＲｅｑｕｅｓｔとが、管理アプリケーションのために発行される。最初の２つはＧＥＴ機能の変形である。３つすべてのメッセージが、管理アプリケーション６１０ａまでわたされるＧｅｔＲｅｓｐｏｎｓｅメッセージの形式でＳＮＭＰエージェント６２０ｃにより承認される。ＳＮＭＰエージェント６２０ｃはまた、管理リソースにおいて生じたイベントに応答して、ＴＲＡＰメッセージを発行してもよい。
【００４５】
図３を再び参照するに、本発明の例示的な一実施例による図３のネットワーク通信エンティティ３０４に含まれるＬＤＡＰモジュール３０４ｂが説明される。ＬＤＡＰモジュール３０４ｂは、共通のディレクトリ情報にアクセスするための標準的なＩＰベースプロトコルであるＬＤＡＰを利用する。ＬＤＡＰは、例えば、ユーザ特有の基準を満たすエントリの検索、エントリの追加、エントリの削除、エントリの変更、エントリの比較のようなディレクトリエントリに対するアクセス及び変更のための処理を定義する。
【００４６】
本発明の例示的な一実施例による図３のネットワーク通信エンティティ３０４に含まれるＭＡＤＣＡＰクライアントモジュール３０４ｃが説明される。ＭＡＤＣＡＰモジュール３０４ｃは、マルチキャストアドレス割り当てサーバからのマルチキャストアドレス割り当てサービスのホストによるリクエストを可能にするプロトコルであるＭＡＤＣＡＰを利用する。マルチキャストサービスを利用するのにテレビ会議セッションが設定されると、テレビ会議サーバ２０５は当該セッションのクライアントに割り当てられるマルチキャストアドレスを取得する必要がある。テレビ会議サーバ２０５は、ＭＡＤＣＡＰプロトコルを利用して、マルチキャストアドレス割り当てサーバからマルチキャストアドレスを動的に取得することができる。
【００４７】
本発明の例示的な一実施例による図３のネットワーク通信エンティティ３０４に含まれるＳＩＰモジュール３０４ｄが説明される。ＳＩＰモジュール３０４ｄは、ＩＰベースネットワーク上の１以上の参加者とのマルチメディアセッションの生成、変更及び終了を行うためのアプリケーションレイヤ制御プロトコルであるＳＩＰを利用する。ＳＩＰはテキストメッセージベースのプロトコルである。
【００４８】
ＳＩＰベースのテレビ会議システムでは、各クライアント及びサーバは、ＳＩＰＵＲＬにより識別される。ＳＩＰＵＲＬは、電子メールアドレスと同様のフォーマットである「ｕｓｅｒ＠ｈｏｓｔ」の形式をとり、大部分の場合、ＳＩＰＵＲＬはユーザの電子メールアドレスである。
【００４９】
本発明の例示的な一実施例による図３のネットワーク通信エンティティ３０４に含まれるサーバ・ツー・サーバ管理モジュール３０４ｅが説明される。サーバ・ツー・サーバ管理モジュール３０４ｅは、テレビ会議サーバ間において情報を交換するためのメッセージを利用する。好ましくは、サーバ・ツー・サーバ管理モジュール３０４ｅは、一意的なテレビ会議サーバ（例えば、テレビ会議サーバ２０５）がそれによりサポートされているネットワーク（例えば、ＬＡＮ２２５）にローカルに設定される典型的な配置で利用され、これにより、複数のテレビ会議サーバが企業ワイドネットワーク（例えば、ネットワーク２００）に存在することになるかもしれない。情報を交換するためのメッセージの主要な目的には、データベースの同期化やネットワークリソースの利用可能性のチェックが含まれる。
【００５０】
以下のメッセージ、すなわち、ＱＵＥＲＹ（遠隔サーバへのエントリの問い合わせ）と、ＡＤＤ（遠隔サーバへのエントリの追加）と、ＤＥＬＥＴＥ（遠隔サーバからのエントリの削除）と、ＵＰＤＡＴＥ（遠隔サーバ上のエントリの更新）とが定義される。
【００５１】
サーバ・ツー・サーバメッセージ処理は、各サーバ間のＴＣＰベースの接続を利用することができる。１つのサーバの状態が変化すると、残りのサーバは同じ情報により更新される。
【００５２】
本発明の例示的な一実施例によるテレビ会議サーバ２０５の動作シナリオが説明される。始めに、テレビ会議セッションの設定に対応する動作シナリオが説明され、その後、テレビ会議セッションにおける解像度とフレームレートの調整に対応する動作シナリオが説明される。セッション動作シナリオには、ＳＩＰサーバの検出、メンバーの登録、セッションの設定、セッションのキャンセル、及びセッションの終了が含まれる。
【００５３】
本発明の例示的な一実施例によるＳＩＰサーバ検出に対応するセッション動作シナリオが説明される。
【００５４】
予め設定されているテレビ会議サーバ（手動により供給される）により、あるいは開始時にＲＥＧＩＳＴＥＲリクエストを周知の「すべてのＳＩＰサーバ」マルチキャストアドレスである「ｓｉｐ．ｍｃａｓｔ．ｎｅｔ」（２２４．０．１．７５）に送信することにより、ユーザは登録することができる。各ユーザがローカルＳＩＰサーバのアドレスを自らのテレビ会議クライアントアプリケーションにおいて手動により設定することを必要としないため、第２の機構（ＲＥＧＩＳＴＥＲリクエスト）は好ましい。この場合、マルチキャストアドレスは、ユーザがテレビ会議のための正しいＳＩＰサーバに登録しているということを保証するため、ネットワークにおいて正しく検出されねばならないであろう。上記方法に加えて、この供給プロセスをより簡素化する他の方法では、ＳＩＰの仕様は管理者がｓｉｐドメイン名（例えば、ｓｉｐ．ｐｒｉｎｃｅｔｏｎ．ｔｃｅ．ｃｏｍ）を使って、各自のＳＩＰサーバに名前を付けるよう推奨している。
【００５５】
本発明の例示的な一実施例によるメンバーの登録に対応するセッション動作シナリオが説明される。図７は、本発明の例示的な一実施例によるＳＩＰを利用したテレビ会議セッションへの登録方法を示す図である。図７の例は、テレビ会議クライアントアプリケーション（クライアント）７０２と、テレビ会議サーバ（サーバ）２０５とを有する。ここで「クライアントアプリケーション」及び「クライアント」という用語は交互に使用されるということが理解されるであろう。
【００５６】
メンバー登録機能では、クライアント７０２がＳＩＰ  ＲＥＧＩＳＴＥＲリクエストをサーバ２０５に送信する（ステップ７１０）。サーバ２０５は、このメッセージを受信し、クライアント７０２のＩＰアドレスとＳＩＰ  ＵＲＬをメンバーデータベース３１４に格納する。
【００５７】
ＲＥＧＩＳＴＥＲリクエストは、その利用が規格では定義されていないが、メッセージボディーを有するかもしれない。メッセージボディは、サーバ２０５により登録するクライアント７０２の設定オプションに関する追加的な情報を含むことができる。
【００５８】
サーバ２０５は、ＯＫメッセージ２００をクライアント７０２に送り返すことにより登録を承認する（ステップ７２０）。
【００５９】
本発明の例示的な実施例によるユニキャスト及びマルチキャストテレビ会議セッションが説明される。図１Ｂ及び１Ｃは、本発明の例示的な２つの実施例によるユニキャストテレビ会議セッションとマルチキャストテレビ会議セッションをそれぞれ示すブロック図である。図１Ｂ及び１Ｃの例は、第１クライアント１３０と、第２クライアント１３２と、第３クライアント１３４と、イーサネット（登録商標）スイッチ１３６と、ＩＰルータ１３８と、ＩＰルータ１４０と、ＷＡＮ１４２とを有する。
【００６０】
ユニキャストの例では、一意的なストリームが各クライアントから他のそれぞれのクライアントに送信される。このようなアプローチでは、ネットワークに参加する参加者が多くなるほど、大きな帯域幅が消費される。一方、マルチキャストによるアプローチでは、各クライアントから１つのみのストリームが送信される。従って、マルチキャストアプローチでは、ユニキャストアプローチと比較して、帯域幅のようなネットワークリソースの消費を少なくすることができる。
【００６１】
本発明の例示的な一実施例によるユニキャストテレビ会議セッションの設定に対応するセッション動作シナリオが説明される。図８Ａは、本発明の例示的な一実施例によるＳＩＰを利用したユニキャストテレビ会議セッションの設定方法を示す図である。図８Ａの例は、第１テレビ会議クライアントアプリケーション（第１クライアント）８０２と、テレビ会議サーバ（サーバ）２０５と、第２テレビ会議クライアントアプリケーション（第２クライアント）８０６とを有する。
【００６２】
ＩＮＶＩＴＥリクエストが第１クライアント８０２からサーバ２０５に送信される（ステップ８１０）。ＩＮＶＩＴＥリクエストは、サーバ２０５から第２クライアント８０６に転送される（ステップ８１５）。
【００６３】
ＲＩＮＧＩＮＧメッセージ１８０が第２クライアント８０６からサーバ２０５に送信される（ステップ８２０）。ＲＩＮＧＩＮＧメッセージ１８０は、サーバ２０５から第１クライアント８０２に送信される（ステップ８２５）。
【００６４】
ＯＫメッセージ２００が第２クライアント８０６からサーバ２０５に送信される（ステップ８３０）。ＯＫメッセージ２００は、サーバ２０５から第１クライアント８０２に送信される（ステップ８３５）。
【００６５】
承認メッセージＡＣＫが第１クライアント８０２から第２クライアント８０６に送信される（ステップ８４０）。テレビ会議セッション（メディアセッション）がこれら２つのノード（第１クライアント８０２と第２クライアント８０６）との間で行われる（ステップ８４５）。
【００６６】
図８Ｂは、本発明の例示的な一実施例によるＩＮＶＩＴＥリクエストが第１テレビ会議クライアントアプリケーション８０２から受信されるとき（図８Ａのステップ８１０）、テレビ会議サーバ２０５により行われるステップを示す図である。
【００６７】
サーバ２０５は、リクエストを行ったユーザ（第１クライアント８０２）がサーバ２０５に登録されているか確認し、また呼び出されたユーザ（第２クライアント８０６）がサーバ２０５に登録されているか確認する（ステップ８５０）。
【００６８】
サーバ２０５は、ネットワーク上の各ユーザの位置を判断し（ステップ８５５）、（異なる場合）これら２つの場所を接続する低帯域幅ＷＡＮリンク（例えば、ＷＡＮ２５０）が存在するか判断する（ステップ８６０）。
【００６９】
２つの場所を接続する低帯域幅ＷＡＮリンクがない場合、サーバ２０５は呼び出しを続ける（ステップ８６５）。一方、２つの場所を接続する低帯域幅ＷＡＮリンクが存在する場合、ステップ８７０に移行する。
【００７０】
ステップ８７０において、サーバ２０５は、ＷＡＮ２５０上のテレビ会議セッションに関するポリシーをチェックする。すなわち、基本的に、これは「Ｘセッションを最大ビットレートＹで行うことができる」というものに変換する。サーバ２０５は、このポリシーに基づき利用可能性をチェックする（ステップ８７５）。利用可能でない場合、サーバ２０５は以下のメッセージの何れか、すなわち、「あらゆる場所でビジー６００」、「ここではビジー４８６」、「利用不可なサービス５０３」、あるいは「拒絶６０３」を送信することによりＩＮＶＩＴＥリクエストを拒絶し（ステップ８８０）、本方法は終了する（図８Ａの方法のステップ８１５に続くことなく）。しかしながら、利用可能である場合、サーバ２０５は呼び出しを続ける（ステップ８６５）。ステップ８６５は図８Ａの方法のステップ８１５に続くということが理解されるであろう。
【００７１】
図９は、本発明の例示的な一実施例による図８Ａの方法をさらに示す図である。図９の例は、第１クライアントアプリケーション９９８と、第２クライアントアプリケーション９９７と、テレビ会議サーバ２０５と、他のテレビ会議サーバ９８６とを有する。図９に示されるテレビ会議サーバ２０５の構成要素は、メンバーデータベース３１４と、アクティブセッションデータベース３１２と、ネットワークアーキテクチャデータベース３１６に含まれるポリシーデータベース９９９と、セッションマネージャ３２０と、ＳＩＰモジュール３０４ｄと、サーバ・ツー・サーバ管理モジュール３０４ｅとを有する。
【００７２】
図９は、テレビ会議サーバ２０５内の内部相互作用のを示すために与えられ、このため、テレビ会議サーバ２０５のエンティティ間の信号フローの一例を提供するため基本的レベルで示される。
【００７３】
ＩＮＶＩＴＥリクエストは、第１クライアントアプリケーション９９８からテレビ会議サーバ２０５内のＳＩＰモジュール３０４ｄに送信される（ステップ９０３）。ＳＩＰモジュール３０４ｄは、このメッセージを復号化し、ＩＮＶＩＴＥリクエストをセッションマネージャ３２０に転送する（ステップ９０６）。セッションマネージャ３２０は、セッションが正しく設定することができるということを保証するため、アクティブセッションデータベース３１２と、メンバーデータベース３１４と、ネットワークアーキテクチャデータベース３１６内のポリシーデータベース９９９をチェックする（ステップ９０９、９１２及び９１５）。セッションが正しく設定することが可能である場合、アクティブセッションデータベース３１２と、メンバーデータベース３１４と、ポリシーデータベース９９９は、ＯＫメッセージをセッションマネージャ３２０に送信する（ステップ９１８、９２１及び９２４）。このチェックプロセスが完了すると、テレビ会議サーバ２０５は他のテレビ会議サーバにシステム状態の変化を通知する（ステップ９２７と９３０）。
【００７４】
セッションマネージャ３２０は、ＩＮＶＩＴＥメッセージをＳＩＰモジュール３０４ｄに転送し（ステップ９３３）、その後このＩＮＶＩＴＥメッセージは第２クライアントアプリケーション９９７に転送される（ステップ９３６）。ＩＮＶＩＴＥメッセージを受信すると、第２クライアントアプリケーション９９７は、ＳＩＰモジュール３０４ｄがＩＮＶＩＴＥメッセージを受信したことを示すＲＩＮＧＩＮＧメッセージ１８０によりＳＩＰモジュール３０４ｄに応答する（ステップ９３９）。ＲＩＮＧＩＮＧメッセージ１８０は、ＳＩＰモジュール３０４ｄに受信され、復号化された後、セッションマネージャ３２０に転送される（ステップ９４２）。クライアントの状態は、テレビ会議サーバ２０５内の図９に示される各データベースにおいて更新される（ステップ９４５、９４８、９５１、９５４、９５７及び９５８）。
【００７５】
ＲＩＮＧＩＮＧメッセージ１８０は、セッションマネージャ３２０から第１クライアントアプリケーション９９８に転送される（ステップ９６０及び９６３）。その後、ＯＫメッセージ２００が第２クライアントアプリケーション９９７からＳＩＰモジュール３０４ｄに送信され（ステップ９６６）、ＳＩＰモジュール３０４ｄからセッションマネージャ３２０に転送される（ステップ９６９）。ＯＫメッセージ２００は、第２クライアントアプリケーション９９７がテレビ会議セッションへの誘いを受けているということを示す。
【００７６】
クライアントの状態は、テレビ会議サーバ２０５内の図９に示される各データベースにおいて更新される（ステップ９７２、９７５、９７８、９８１、９８４及び９８５）。ＯＫメッセージが、セッションマネージャ３２０からＳＩＰモジュール３０４ｄに送信され、その後ＳＩＰモジュール３０４ｄから第１クライアントアプリケーション９９８に転送される（ステップ９８８及び９９１）。ＡＣＫメッセージが、第１クライアントアプリケーション９９８から第２クライアントアプリケーション９８７に送信され、セッション設定が完了する（ステップ９９４）。
【００７７】
本発明の例示的な一実施例によるマルチキャストテレビ会議セッション設定に対応するセッション動作シナリオが説明される。マルチキャストセッション設定を与えるため、ＳＤＰ（Ｓｅｓｓｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）が利用される。ＳＤＰプロトコルは、マルチキャストアドレスとポート番号を送ることができる。
【００７８】
マルチキャストセッション設定は、マルチキャストアドレスが必要であるという点を除いて、ユニキャストセッション設定と同じである。マルチキャストアドレスはネットワーク上のＭＡＤＣＡＰサーバ２１５により割り当てられる。
【００７９】
図１０は、本発明の例示的な他の実施例によるＳＩＰを利用したマルチキャストテレビ会議セッションの設定方法を示す図である。図１０の例は、第１テレビ会議クライアントアプリケーション（第１クライアント）１００２と、テレビ会議サーバ（サーバ）２０５と、第２テレビ会議クライアントアプリケーション（第２クライアント）１００６と、ＭＡＤＣＡＰサーバ２１５とを有する。
【００８０】
ＩＮＶＩＴＥリクエストが第１クライアント１００２からサーバ２０５に送信される（ステップ１０１０）。ＭＡＤＣＡＰリクエストが、サーバ２０５からＭＡＤＣＡＰサーバ２１５に送信される（ステップ１０１５）。承認メッセージＡＣＫが、ＭＡＤＣＡＰサーバ２１５からサーバ２０５に送信される（ステップ１０２０）。ＩＮＶＩＴＥリクエストが、サーバ２０５から第２クライアント１００６に転送される（ステップ１０２５）。
【００８１】
ＲＩＮＧＩＮＧメッセージ１８０が、第２クライアント１００６からサーバ２０５に送信される（ステップ１０３０）。ＲＩＮＧＩＮＧメッセージ１８０は、サーバ２０５から第１クライアント１００２に転送される（ステップ１０３５）。
【００８２】
ＯＫメッセージ２００が、第２クライアント１００６からサーバ２０５に送信される（ステップ１０４０）。ＯＫメッセージ２００は、サーバ２０５から第１クライアント１００２に転送される（ステップ１０４５）。
【００８３】
承認メッセージＡＣＫが、第１クライアント１００２から第２クライアント１００６に送信される（ステップ１０５０）。テレビ会議セッション（メディアセッション）が、これら２つのノード（第１クライアント１００２と第２クライアント１００６）との間で行われる（ステップ１０５５）。
【００８４】
本発明の例示的な一実施例によるテレビ会議セッションのキャンセル処理に対応するセッション動作シナリオが説明される。保留中のセッション設定を終了させるためＣＡＮＣＥＬメッセージが利用される。クライアントはこのメッセージを利用して、クライアントが以前に開始した保留中のテレビ会議設定をキャンセルする。サーバはＩＮＶＩＴＥが送信されたのと同じ場所に保留中のメッセージと共にＣＡＮＣＥＬメッセージを転送する。クライアントはＯＫメッセージ２００によりこのＣＡＮＣＥＬメッセージに応答すべきではない。ＣＡＮＣＥＬメッセージが不成功である場合、セッション終了シーケンス（すなわち、ＢＹＥメッセージ）を利用することができる。
【００８５】
図１１は、本発明の例示的な一実施例によるＳＩＰを利用したテレビ会議セッションのキャンセル方法を示す図である。図１１の例は、第１テレビ会議クライアントアプリケーション（第１クライアント）１１０２と、テレビ会議サーバ（サーバ）２０５と、第２テレビ会議クライアントアプリケーション（第２クライアント）１１０６とを有する。
【００８６】
ＩＮＶＩＴＥリクエストが、第１クライアント１１０２からサーバ２０５に送信される（ステップ１１１０）。ＩＮＶＩＴＥリクエストが、サーバ２０５から第２クライアント１１０６に転送される（ステップ１１１５）。
【００８７】
ＲＩＮＧＩＮＧメッセージ１８０が、第２クライアント１１０６からサーバ２０５に送信される（ステップ１１２０）。ＲＩＮＧＩＮＧメッセージ１８０が、サーバ２０５から第１クライアント１１０２に転送される（ステップ１１２５）。
【００８８】
ＣＡＮＣＥＬメッセージが、第１クライアント１１０２からサーバ２０５に送信される（ステップ１１３０）。このＣＡＮＣＥＬメッセージは、サーバ２０５から第２クライアント１１０６に転送される（ステップ１１３５）。
【００８９】
本発明の例示的な一実施例によるテレビ会議セッションの終了に対応するセッション動作シナリオが説明される。図１２は、本発明の例示的な一実施例によるＳＩＰを利用した２つのクライアント間のテレビ会議セッションの終了方法を示す図である。図１２の例は、第１クライアント（第１テレビ会議クライアントアプリケーション）１２０２と、テレビ会議サーバ（サーバ）２０５と、第２クライアント（第２テレビ会議クライアントアプリケーション）１２０６とを有する。
【００９０】
第１クライアント１２０２は、第２クライアント１２０６との呼び出しを打ち切ることを決定する。このため、第１クライアント１２０２は、ＢＹＥメッセージをサーバ２０５に送信する（ステップ１２１０）。サーバ２０５は、このＢＹＥメッセージを第２クライアント１２０６に転送する（ステップ１２２０）。
【００９１】
第２クライアント１２０６は、（第２クライアント１２０６が）切断したということを示すＯＫメッセージ２００をサーバ２０５に送り返す（ステップ１２３０）。サーバ２０５は、切断の成功を示すＯＫメッセージ２００を第１クライアント１２０２に転送する（ステップ１２４０）。
【００９２】
図１３は、本発明の例示的な一実施例によるＳＩＰを利用した３つのクライアント間におけるテレビ会議セッションの終了方法を示す図である。図１３の例は、第１クライアント（第１テレビ会議クライアントアプリケーション）１３０２と、テレビ会議サーバ（サーバ）２０５と、第２クライアント（第２テレビ会議クライアントアプリケーション）１３０６と、第３クライアント（第３テレビ会議クライアントアプリケーション）１３０８とを有する。
【００９３】
第１クライアント１３０２は、第２クライアント１３０６と第３クライアント１３０８との呼び出しを打ち切ることを決定する。これは、第２クライアント１３０６と第３クライアント１３０８との切断を意味するものではない。
【００９４】
第１クライアント１３０２は、ＢＹＥメッセージをサーバ２０５に送信する（ステップ１３１０）。サーバ２０５は、このＢＹＥメッセージを解釈し、第２クライアント１３０６と第３クライアント１３０８が第１クライアント１３０２とのテレビ会議セッションに関係していると認識し、ＢＹＥメッセージを第２クライアント１３０６と第３クライアント１３０８の両方に転送する（ステップ１３２０と１３３０）。
【００９５】
第２クライアント１３０６は、ＯＫメッセージ２００をサーバ２０５に送り返す（ステップ１３４０）。サーバ２０５は、このＯＫメッセージ２００をサーバ１３０２に転送する（ステップ１３５０）。第３クライアント１３０８は、ＯＫメッセージ２００をサーバ２０５に送り返す（ステップ１３６０）。サーバ２０５は、このＯＫメッセージを第１クライアント１３０２に転送する（ステップ１３７０）。
【００９６】
図１４は、本発明の例示的な他の実施例によるＳＩＰを利用した３つのクライアントの間のテレビ会議セッションの終了方法を示す図である。図１４の例は、第１クライアント（第１テレビ会議クライアントアプリケーション）１４０２と、テレビ会議サーバ（サーバ）２０５と、第２クライアント（第２テレビ会議クライアントアプリケーション）１４０６と、第３クライアント（第３テレビ会議クライアントアプリケーション）１４０８とを有する。
【００９７】
第１クライアント１４０２は、第２クライアント１４０６と第３クライアント１４０６による呼び出しを打ち切ることを決定する。このことは、第２クライアント１４０６と第３クライアントとの間のセッションを打ち切ることを意味するものではない。
【００９８】
第１クライアント１４０２は、第２クライアント１４０６のためのＢＹＥメッセージをサーバ２０５に送信する（ステップ１４１０）。サーバ２０５は、このＢＹＥメッセージを第２クライアント１４０６に転送する（ステップ１４２０）。第１クライアント１４０２は、第３クライアント１４０８のためのＢＹＥメッセージをサーバ２０５に送信する（ステップ１４３０）。サーバ２０５は、このＢＹＥメッセージを第３クライアント１４０８に転送する（ステップ１４４０）。
【００９９】
第２クライアント１４０６は、ＯＫメッセージ２００をサーバ２０５に送り返す（ステップ１４５０）。サーバ２０５は、このＯＫメッセージを第１クライアント１４０２に転送する（ステップ１４６０）。第３クライアント１４０８は、ＯＫメッセージ２００をサーバ２０５に送り返す（ステップ１４７０）。サーバ２０５は、このＯＫメッセージ２００を第１クライアント１４０２に転送する（ステップ１４８０）。
【０１００】
図１２から１４に関して説明された以前の例に加えて、テレビ会議加入者が属するマルチキャストグループアドレスにＢＹＥメッセージを送信することにより、終了の呼び出しが可能となる。この方法を利用することにより、サーバ及びその他のクライアントアプリケーションはメッセージを受信する。これは、より少ない関連するオーバヘッドによりセッションを終了させるより普遍的かつ効率的機構である。
【０１０１】
本発明の例示的な一実施例による解像度及びフレームレートの調整に対応する動作シナリオを説明する。テレビ会議は、コンピュータネットワーク上の異なる位置の複数のユーザ間の双方向対話型ライブ映像の送信に関する。リアルタイム対話型映像は、限定された遅延での大量の情報の送信を必要とする。このため、テレビ会議システムが結合されているコンピュータネットワークは、セッションに参加している各ユーザに対して、適当なサイズの帯域幅とＱｏＳを提供することができなければならない。帯域幅は時間において限られたリソースであり、ＱｏＳがすべてのネットワークで常に保証することができるとは限らず、ある程度の制限はある。プライベートな企業ネットワークでは、ＱｏＳを保証することはできるが、常に広い帯域幅を確保する保証はできない。
【０１０２】
基本的な企業コンピュータネットワークインフラストラクチャには、低速リンクを介し互いに接続された複数の高速ローカルエリアネットワーク（ＬＡＮ）が含まれている（例えば、図２を参照せよ）。通常、各高速ＬＡＮは１つの空間的領域におけるネットワークインフラストラクチャを表し、低速リンクは複数の空間領域を接続する長めの搬送リンクである。低速リンクが使われる理由は、長めの搬送リンクのコストは比較的大きなものであり、またネットワークトラフィックの大部分は通常ローカルエリアネットワーク内のものであり、そのため大きなサイズのデータは通常これら長めの搬送リンクを介しては交換されないためである。
【０１０３】
ＩＰベースネットワーク上のＱｏＳの最近の進歩は、他のタイプの情報がこれらのネットワークを介し送信されることを可能にする手段を提供している。これは、リアルタイムでないデータトラフィックに加えて、そのようなインフラストラクチャにおけるリアルタイム情報（すなわち、音声及び映像）を送信するための窓口を開くことになる。ネットワークＱｏＳを利用するテレビ会議サービスはこのインフラストラクチャ上に配備されるのに適している。この場合、２箇所の相異なる地理的位置にいる２人のユーザがリアルタイムテレビ会議セッションを行うことができるであろう。テレビ会議セッションの問題点の１つは、リアルタイム映像の送信はきわめて大きな帯域幅を消費し、利用可能なネットワークリソースを容易に枯渇させる。ネットワークを介し送信されるリアルタイム映像のビットレートは、主に利用される映像の解像度と圧縮アルゴリズムに依存する。典型的には、異なる地理的位置にいる２、３あるいは４人のユーザ間における１つのテレビ会議セッションは、妥当な大きさの帯域幅を有するネットワーク上で適切にサポートされうる。しかしながら、一般に、１つのテレビ会議セッションに４人を超えた追加的ユーザをサポートすることができなかったり、あるいは帯域幅の制約上、他のテレビ会議セッションのサポートができなくなるケースがあった。テレビ会議システムの制約となる要素は、これら地理的位置の間の低速な搬送リンクである。
【０１０４】
１つの可能な解法は、システムにおいてサポートできるユーザ数を増やすため、このような２つの地理的位置間の長距離搬送リンクの帯域幅を拡大するというものである。しかしながら、このアプローチの問題点としては、帯域幅がかなりコストがかかるということである。第２の解法は、テレビ会議システムにおいて少数のユーザ（すなわち、アクティブユーザ）のみが高解像度かつ高ビットレートでの送信が許され、当該セッションの残りのユーザ（非アクティブユーザ）は限定的なビットレートかつ限定的解像度での送信しかできないというシステムを有することである。テレビ会議セッションの主催者は、どのユーザが高解像度で送信し、どのユーザが低解像度で送信できるかを制御する。もしあるユーザがセッションにおいて活発には発言しなかったり、積極的なやり取りを行っていなければ、高解像度で映像を送信する必要はない。このようなアプローチはかなりの帯域幅の節約になりうる。
【０１０５】
図１８Ａのテレビ会議クライアントアプリケーションを参照するに、このアプローチでは、様々なウィンドウサイズ（すなわち、高解像度及び低解像度で復号化された映像ストリームを表す様々なサイズの表示ウィンドウ）をサポートするテレビ会議クライアントアプリケーション１８００におけるユーザインタフェース１８０８と、サーバ２０５とその他のクライアントアプリケーションとの通信を特定するメッセージ処理システム１８４２（図１８Ａのテレビ会議クライアントアプリケーション１８００のネットワークエンティティ１８０６に含まれる）とが備えられる。メッセージ処理システム１８４２は、各クライアントアプリケーションの符号化解像度と送信ビットレートを制御するメッセージを含む。
【０１０６】
本発明の例示的な一実施例による解像度及びフレームレートの調整に対応するメッセージが説明される。特に、ＭＳＧ＿ＷＩＮＤＯＷ＿ＳＷＩＴＣＨメッセージとＭＳＧ＿ＡＤＪＵＳＴ＿ＣＯＤＥＣメッセージが説明される。
【０１０７】
アクティブユーザと非アクティブユーザとの切り替えを示すＭＳＧ＿ＷＩＮＤＯＷ＿ＳＷＩＴＣＨメッセージが、クライアントからサーバに送信される。すなわち、アクティブユーザは非アクティブとなり、非アクティブユーザはアクティブとなる。テレビ会議サーバは、クライアントによるこのリクエストを承認する。
【０１０８】
ＭＳＧ＿ＡＤＪＵＳＴ＿ＣＯＤＥＣメッセージはサーバから各クライアントに送信される。ＭＳＧ＿ＡＤＪＵＳＴ＿ＣＯＤＥＣメッセージは、クライアントが送信すべき解像度（すなわち、ＣＩＦまたはＱＣＩＦ）とフレームレートをクライアントに示す。ＭＳＧ＿ＡＤＪＵＳＴ＿ＣＯＤＥＣメッセージは各クライアントにより承認される。
【０１０９】
図１５は、本発明の例示的な一実施例による解像度及びフレームレートを調整するための信号処理方法を示す図である。図１５の例は、テレビ会議サーバ（サーバ）２０５と、第１クライアント１５０４と、第２クライアント１５０６と、第３クライアント１５０８と第４クライアント１５１０とを有する。
【０１１０】
ＭＳＧ＿ＷＩＮＤＯＷ＿ＳＷＩＴＣＨメッセージが、第１クライアント１５０４からサーバ２０５に送信される（ステップ１５２０）。承認メッセージＡＣＫが、サーバ２０５から第１クライアント１５０４に送信される（ステップ１５２５）。
【０１１１】
ＭＳＧ＿ＡＤＪＵＳＴ＿ＣＯＤＥＣ（ｌｏｗ）メッセージが、サーバ２０５から第１クライアント１５０４に送信される（ステップ１５３０）。承認メッセージＡＣＫが、第１クライアント１５０４からサーバ２０５に送信される（ステップ１５３５）。
【０１１２】
ＭＳＧ＿ＡＤＪＵＳＴ＿ＣＯＤＥＣ（ｈｉｇｈ）メッセージが、サーバ２０５から第２クライアント１５０６に送信される（ステップ１５４０）。承認メッセージＡＣＫが、第２クライアント１５０６からサーバ２０５に送信される（ステップ１５４５）。
【０１１３】
ＭＳＧ＿ＡＤＪＵＳＴ＿ＣＯＤＥＣ（ｌｏｗ）メッセージが、サーバ２０５から第３クライアント１５０８に送信される（ステップ１５５０）。承認メッセージＡＣＫが、第３クライアント１５０８からサーバ２０５に送信される（ステップ１５５５）。
【０１１４】
ＭＳＧ＿ＡＤＪＵＳＴ＿ＣＯＤＥＣ（ｌｏｗ）メッセージが、サーバ２０５から第４クライアント１５１０に送信される（ステップ１５６０）。承認メッセージＡＣＫが、第４クライアント１５１０からサーバ２０５に送信される（ステップ１５６５）。
【０１１５】
図１６は、本発明の例示的な一実施例による解像度及びフレームレート調整（クライアント２及び３）前の信号処理を示す図である。図１７は、本発明の例示的な一実施例による解像度及びフレームレート調整（クライアント２及び３）後の信号処理を示す図である。図１７及び１８の例は、第１クライアント１６０２と、第２クライアント１６０４と、ネットワークルータ１６０６と、第３クライアント１６０８と、第４クライアント１６１０とを有する。
【０１１６】
「低ビットレート／解像度での送信」メッセージが、第１クライアント１６０２からネットワークルータ１６０６に送信される（ステップ１６２０）。「高ビットレート／解像度での送信」メッセージが、第３クライアント１６０８からネットワークルータ１６０６に送信される（ステップ１６２５）。「低ビットレート／解像度での送信」メッセージが、第２クライアント１６０４からネットワークルータ１６０６に送信される（ステップ１６３０）。「高ビットレート／解像度での送信」メッセージが、第４クライアント１６１０からネットワークルータ１６０６に送信される（ステップ１６３５）。
【０１１７】
マルチキャストアドレスを使って、データがネットワークルータ１６０６から第２クライアント１６０４と、第３クライアント１６０８と、第１クライアント１６０２と、第４クライアント１６１０とに送信される（それぞれステップ１６４０、１６４５、１６５０及び１６５５）。
【０１１８】
図１７に進んで、「低ビットレート／解像度での送信」メッセージが、第１クライアント１６０２からネットワークルータ１６０６に送信される（ステップ１７２０）。「高ビットレート／解像度での送信」メッセージが、第３クライアント１６０８からネットワークルータ１６０６に送信される（ステップ１７２５）。「高ビットレート／解像度での送信」メッセージが、第２クライアント１６０４からネットワークルータ１６０６に送信される（ステップ１７３０）。「低ビットレート／解像度での送信」メッセージが、第４クライアント１６１０からネットワークルータ１６０６に送信される（ステップ１７３５）。
【０１１９】
マルチキャストアドレスを使って、データがネットワークルータ１６０６から第２クライアント１６０４と、第３クライアント１６０８と、第１クライアント１６０２と、第４クライアント１６１０とに送信される（それぞれステップ１７４０、１７４５、１７５０及び１７５５）。
【０１２０】
本発明の例示的な一実施例によるクライアントアプリケーションアーキテクチャが説明される。クライアントアプリケーションは、ユーザとのやり取り、他のクライアントアプリケーションとのマルチメディアコンテンツの交換、及びサーバアプリケーションによる呼出しの管理を行うためのものである。さらに、クライアントアプリケーションはまた、その中にサーバ機能を有することができると認識されるであろう。図１８Ａは、本発明の例示的な一実施例によるテレビ会議クライアントアプリケーション１８００のブロック図である。テレビ会議クライアントアプリケーション１８００は、コンピュータ２２０ａ〜ｆの何れか及び／またはコンピュータ２３０ａ〜ｃの何れかのような、あるコンピュータ上にあるかもしれないということが認識されるであろう。
【０１２１】
テレビ会議クライアントアプリケーション１８００は、以下の４つの基本機能エンティティ、すなわち、マルチメディアインタフェースレイヤ１８０２と、コーデック１８０４（音声コーデック１８０４ａと映像コーデック１８０４ｂ）と、ネットワークエンティティ１８０６と、ユーザインタフェース１８０８とを有する。
【０１２２】
マルチメディアインタフェースレイヤ１８０２は、テレビ会議クライアントアプリケーション１８００のメインとなる制御インスタンスである。すべてのシステム内通信は、マルチメディアインタフェースレイヤ１８０２を介しルーティング及び制御される。マルチメディアインタフェースレイヤ１８０の主要な基礎となる特徴の１つは、異なる音声及び映像コーデック１８０４の容易なやり取りが可能であるということである。さらに、マルチメディアインタフェースレイヤ１８０２は、オペレーティングシステム（ＯＳ）に依存したユーザ入出力エンティティとネットワークサブシステムとのインタフェースを提供する。マルチメディアインタフェースレイヤ１８０２は、メンバーデータベース１８０２と、メインコントロールモジュール１８２２と、音声ミキサ１８９９と、エコーキャンセルモジュール１８９８とを有する。
【０１２３】
ユーザインタフェース１８０８は、エンドユーザとテレビ会議クライアントアプリケーション１８００とのやり取りの場を提供する。ユーザインタフェース１８０８は、ＯＳ依存モジュールとして実現されることが好ましいが、そうである必要は必ずしもない。多くのグラフィカルユーザインタフェースは、使用される特定のＯＳに依存する。ユーザインタフェース１８０８の４つの主要な機能は、映像キャプチャと、映像表示と、音声キャプチャと、音声再生である。ユーザインタフェース１８０８は、音声／映像キャプチャインタフェース１８３０と、音声／映像再生モジュール１８３２と、メンバー閲覧モジュール１８３４と、チャットモジュール１８３６と、ユーザ選択／メニュー１８３８とを有する。音声／映像キャプチャインタフェース１８３０は、カメラインタフェース１８３０ａと、マイクロフォンインタフェース１８３０ｂと、ファイルインタフェース１８３０ｃとを有する。音声／映像再生モジュール１８３４は、映像ディスプレイ１８３２ａと、音声再生モジュール１８３２ｂと、ファイルインタフェース１８３２ｃとを有する。
【０１２４】
ネットワークエンティティ１８０６は、テレビ会議クライアントアプリケーション１８００の通信サブシステムを表す。ネットワークエンティティ１８０６の機能は、ＳＩＰに基づくクライアント・ツー・サーバメッセージ処理と、音声及び映像ストリームの送受信である。ネットワークエンティティ１８０６はまた、クライアント間のメディアストリームの認証及び暗号通信のための基本的セキュリティ機能を有する。ネットワークエンティティ１８０６は、セキュリティモジュール１８４０と、メッセージ処理システム１８４２と、映像ストリームモジュール１８４４と、音声ストリームモジュール１８４６と、ＩＰソケット１８４８ａ〜ｃを有する。
【０１２５】
音声コーデック１８０４ａと映像コーデック１８０４ｂは、デジタルメディアの圧縮及び解凍を処理するサブシステムである。コーデックとのインタフェースは、容易なやり取りを実現するため、シンプルかつ汎用的なものであるべきである。マルチメディアインタフェースレイヤ１８０２とコーデック１８０４とのシンプルな関係は、実現のための例示的なテンプレートまたはガイドとして以降で定義される。音声コーデック１８０４ａと映像コーデック１８０４ｂはそれぞれエンコーダ１８８０とデコーダ１８９０とを有する。エンコーダ１８８０とデコーダ１８９０はそれぞれキュー１８９５を有する。
【０１２６】
テレビ会議クライアントアプリケーション１８００は、少なくとも、テレビ会議サーバ２０５と他のクライアント１８７０とやり取りする。
【０１２７】
本発明の例示的な一実施例による図１８Ａのマルチメディアインタフェースレイヤ１８０２に含まれるメンバーデータベース１８２０が説明される。メンバーデータベース１８２０は、セッションごとに各参加ユーザに関する情報を記録する。メンバーデータベース１８２０は、送受信ＩＰアドレス関する情報と、クライアント能力と、特定のコーデックに関する情報と、様々なユーザの状態についての詳細とを有する。上記アイテムは単なる例示的なものであり、本発明の趣旨及び範囲を維持しながら、上記アイテムの一部またはすべてに加えた、あるいはそれらの代わりの他のアイテムがメンバーデータベース１８２０に保持されてもよいということが認識されるであろう。メンバーデータベース１８２０に含まれる情報は、音声及び映像デコーダ１８９０への入力情報の制御に利用される。ネットワークから入力されるメディア情報は、正しい音声及び映像デコーダ１８９０にルーティングされる必要がある。同様に重要であるが、音声及び映像エンコーダ１８９０から入力されるメディア情報は、配信のため正しいユニキャストまたはマルチキャストアドレスにルーティングされる必要がある。メンバーデータベース１８２０に含まれる基本情報はまた、エンドユーザがセッションの参加者とその能力を把握できるように、ユーザインタフェース１８０８にルーティングされる。ＩＮＶＩＴＥリクエストがテレビ会議サーバ２０５から受信されるとすぐに、ユーザはメンバーデータベース１８２０に加えられ、ＢＹＥリクエストがテレビ会議サーバ２０５から受信されるとすぐに、ユーザは削除される。メンバーデータベース１８２０は、セッション終了時にフラッシュされる。
【０１２８】
本発明の例示的な一実施例による図１８Ａのマルチメディアインタフェースレイヤ１８０２に含まれるメインコントロールモジュール１８２２が説明される。
【０１２９】
メインコントロールモジュール１８２２は、マルチメディアインタフェースレイヤ１８０２のきわめて重要な部分である。メインコントロールモジュール１８２２は、中心的な管理サブシステムとして機能し、以下の主要な機能、音声及び映像デコーダ及び再生の同期化機構と、記録のためデコーダの宛先の画面またはファイルへの接続と、アプリケーションレイヤＱｏＳとを提供する。
【０１３０】
音声及び映像再生の同期化は、ユーザに対する最適なテレビ会議処理にとって重要なものである。２つのメディアストリームを正確に同期させるため、タイムスタンプが利用され、メディアコンテンツと共に送信される必要がある。ＲＴＰ（Ｒｅａｌ  Ｔｉｍｅ  Ｐｒｏｔｏｃｏｌ）は、上記目的のため、タイムスタンプとシーケンス番号を含む汎用ヘッダを提供する。このタイムスタンプは、２つのネットワークノードのクロックを同期させるためのものではなく、一致した再生のため音声及び映像ストリームを同期させることを目的としている。これらのタイムスタンプは、キャプチャ時に同一ノード上の共通のクロックから導出される必要がある。例えば、映像フレームがキャプチャされるとき、この映像フレームがキャプチャされた時刻が記録されねばならない。同様のことが音声にも適用される。ＲＴＰを利用するための追加的な詳細やガイドラインは他の箇所において説明される。
【０１３１】
音声及び映像の同期化において、メインコントロールモジュール１８２２の機能は、メタデータ（タイムスタンプ及びシーケンス番号を含む）及びマルチメディアデータの適切な送信のため、ネットワークエンティティ１８０６とコーデック１８０４とを接続することである。パケットが遅い場合、システムの現在の状態に応じた符号化前あるいは符号化後にそれらパケットは欠落されうる。ＲＴＰタイムスタンプは、提示及び再生タイムスタンプを生成するため以降において利用される。
【０１３２】
メインコントロールモジュール１８２２はまた、音声及び映像デコーダ１８９０の出力を、再生のために画面に、記録のためにファイルに、あるいはその両方に供給するためのものである。各デコーダ１８９０は独自に処理され、あるデコーダの出力が画面上に表示され、第２のデコーダの出力がファイルに記録され、第３のデコーダの出力がファイルと画面の両方に同時に送られるという状況が可能となる。
【０１３３】
上記機能に加えて、メインコントロールモジュール１８２２はまた、アプリケーションレイヤＱｏＳに関係する。メインコントロールモジュール１８２２は、パケットの欠落や送受信されるバイトに関する情報を収集し、この情報に基づきアクションを実行する。メインコントロールモジュール１８２２は、ネットワークにおいて発生する状況の修復に供するため、他のクライアントやテレビ会議サーバ２０５へのメッセージの送信に関係するかもしれない。ＲＴＣＰ（Ｒｅａｌ  Ｔｉｍｅ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）は、統計データ及びパケット損失の通知に利用され、またアプリケーションに固有の信号処理に利用することもできる。
【０１３４】
図１８Ｂは、本発明の例示的な一実施例による図１８Ａのマルチメディアインタフェースレイヤ１８０２に含まれる音声ミキサ１８９９をさらに示すブロック図である。音声ミキサ１８９９（ここではまた、「ゲインコントロールモジュール」とも呼ばれる）は、複数の音声デコーダ１８９０に動作可能に接続される。複数の音声デコーダ１８８０は、圧縮された音声ストリームを受信し、解凍された音声ストリームを出力する。解凍された音声ストリームは、音声ミキサ１８９９に入力され、合成された音声ストリームとして出力される。
【０１３５】
図１８Ｃは、本発明の例示的な一実施例による図１８Ａのマルチメディアインタフェースレイヤ１８０２に含まれるエコーキャンセルモジュール１８９８をさらに示すブロック図である。エコーキャンセルモジュール１８９８（ここではまた、「エコーキャンセラ」とも呼ばれる）は、スピーカー１８９７（例えば、音声再生モジュール１８３２ｂ）とマイクロフォン１８９６（例えば、マイクロフォンインタフェース１８３０ｂ）に動作可能に接続される。スピーカー１８９７からの音声が全二重または双方向通信システムにおいて生成されるとき、当該音声はローカルなリスナーからのみ聞かれることを意図する。しかしながら、生成された音声はまた、ローカルマイクロフォン１８９６にも拾われ、信号が離れたエンドに送り返されることになり、エコーとして聞こえることになる。このため、テレビ会議クライアントアプリケーション１８００は、エコーキャンセルモジュール１８９８にこの効果を軽減するよう求め、これによって、より良好な状態をユーザに提供することができるようになる。
【０１３６】
本発明の例示的な一実施例によるテレビ会議クライアントアプリケーション１８００のサブシステムに利用可能なインタフェースが説明される。当該インタフェースは、ユーザインタフェース１８０８と、ネットワークエンティティ１８０６と、コーデック１８０４とのやり取りの場所を提供する。ユーザインタフェース１８０８は、キャプチャされた音声及び映像を対応するタイムスタンプと共に受信する機能を提供する。さらに、表示及び再生のため、音声及び映像をユーザインタフェース１８０８に送信する機能が提供されねばならない。ネットワークエンティティ１８０６のインタフェースは、セッションの制御及びセキュリティのため、入出力されるメッセージを信号処理する機能を提供する。音声及び映像コーデック１８０４ａ及び１８０４ｂは、圧縮及び解凍のためのパケットの送受信と共に、構成制御のための基本的なインタフェースを提供する。
【０１３７】
本発明の例示的な一実施例による音声及び映像コーデック１８０４ａ及び１８０４ｂが説明される。
【０１３８】
複数の音声及び映像コーデックがテレビ会議処理において利用可能である。本発明により利用されるコーデックはソフトウェアベースのものであることが好ましいが、必ずしもそうである必要はない。本発明の例示的な一実施例によると、典型的なデスクトップコンピュータの処理能力の制約のため、映像圧縮及び解凍にＨ．２６３が利用される。将来デスクトップコンピュータがより強力になるに従い、Ｈ．２６Ｌのようなより進んだコーデックを利用する能力が実現及び利用されうる。もちろん、本発明は、上記コーデックのタイプに限定されるものではなく、本発明の趣旨および範囲を維持しながら、他のタイプのコーデックが利用されてもよい。
【０１３９】
本発明の例示的な一実施例によるコーデック１８０４ａ及び１８０４ｂとのインタフェースが説明される。この説明では、データイン（ＤａｔａＩｎ）機能、コールバック（ｃａｌｌｂａｃｋ）機能及びコーデックオプションが含まれる。コーデック１８０４ａ及び１８０４ｂとのインタフェースは十分フレキシブルなものであり、コーデック間のやり取りを可能にするだけでなく、将来的に新しいコーデックの追加を可能にするという一般的な意味において定義される。このフレキシブルかつ汎用的インタフェースを実現する提案されたインタフェースは、ユーザに与えられた限定された数の機能とのシンプルなインタフェースである。
【０１４０】
データイン機能は、エンコーダまたはデコーダクラスのフレームやパケットの格納に単に利用される。
【０１４１】
マルチメディアインタフェースレイヤ１８０２とマルチメディアコーデック１８０４とのシンプルな接続を提供するため、データ出力機能がコールバックとして実現される。マルチメディアインタフェースレイヤ１８０２は、このコールバック機能を受信エンティティの入力機能に設定する。例えば、コーデックフレームの符号化または復号化を完了すると、符号化または復号化プロセスから対象となる情報を送信するため、この機能はコーデックにより呼び出される。この呼び出し期間中には、コーデックは何も行うことができないという制約により、システムにおける待機や不要な遅延を回避するため、この機能はできる限り速くリターンすべきである。この機能で実行されるべき唯一の追加的待機は、共有メモリへのアクセス時におけるミューテクス（ｍｕｔｅｘ）のロックである。
【０１４２】
異なるタイプのコーデックに利用可能な選択肢の範囲は変化する。これら選択肢を管理するための要件を満たすため、シンプルなインタフェースが利用されるべきである。提供されるフレキシビリティのため、テキストベースのインタフェースが好ましい（しかし必須ではない）。ＳＴＡＲＴやＳＴＯＰのような共通のコマンド群と、コーデック独自のコマンドが存在すべきである。この方法はシンプルなインタフェースを提供するが、シンプルなインタプリタが必要とされるため、追加的な複雑さをコーデックに追加する。一例として、オプション機能はオプションの読み書きができるだけの十分な汎用性がある。
【０１４３】
例：  Ｒｅｓｕｌｔ＝Ｏｐｔｉｏｎｓ（“ｓｔａｒｔ”）；  Ｒｅｓｕｌｔ＝Ｏｐｔｉｏｎｓ（“ｒｅｓｏｌｕｔｉｏｎ＝ＣＩＦ”）  など
例えば、コーデック間に共通なオプションのいくつかは以下のように、すなわち、スタート、ストップ、ポーズ、クオリティインデックス（０−１００）及び解像度として標準化されるべきである。
【０１４４】
クオリティインデックスは、コーデックの全体的なクオリティを０％から１００％までの値として説明する係数である。これは、この値が高くなるほど映像クオリティはより良好になるという基本的な仮定に従う。
【０１４５】
図１９は、本発明の例示的な一実施例による音声コーデック１８０４ａ及び／または映像コーデック１８０４ｂに含まれるデコーダ１８９０により利用される方法を示す図である。当該方法がデコーダコンテクスト（ｄｅｃｏｄｅｒ  ｃｏｎｔｅｘｔ）１９０１とコーラコンテクスト（ｃａｌｌｅｒ  ｃｏｎｔｅｘｔ）１９０２に関して説明される。当該方法は、少なくとも以下の入力と出力、すなわち、「データイン」１９９９と、「シグナルイン」１９９８と、「シグナルアウトコールバック」１９９７と、「セットコールバックファンクション」１９９６と、「データアウトコールバック」１９９５を利用することにより動作する。入力「データイン」１９９９は、入力キューにデータを格納するため利用される（ステップ１９０５）。
【０１４６】
初期化ステップ（Ｉｎｉｔ）が、デコーダ１８９０を初期化するため実行される（ステップ１９１０）。メインループが実行され、スタートまたはイグジットコマンドを待機する（ステップ１９２０）。イグジットコマンドが受信されると、当該方法は抜け出し（ステップ１９２２）、リターンが、例えば、他の処理になされる（ステップ１９２４）。
【０１４７】
入力キュー１８９５からデータが読み出されるか、あるいは入力キュー１８９５が空の場合、待機条件が課される（ステップ１９３０）。ステップ１９３０においてデータが読み出されると、当該データは復号化される（ステップ１９４０）。「データアウトコールバック」１９９５がステップ１９２０に与えられる。
【０１４８】
本発明の例示的な一実施例によるネットワーク２００により利用される通信が説明される。ここでは、ネットワーク通信に関して前述された説明が補足される。
【０１４９】
メッセージ処理システム１８４２（図１８Ａのネットワークエンティティ１８０６に含まれる）は、テレビ会議クライアントアプリケーション１８００とテレビ会議サーバ２０５との間のインタフェースを提供する。メッセージ処理システム１８４２は、セッション管理（すなわち、セッション設定及び終了）に利用されるためのものである。すべての信号処理メッセージは、クライアントからクライアントに直接でなく、テレビ会議サーバ２０５を介し通信される。マルチメディアコンテンツやプライベートなチャットメッセージのようなデータは、クライアント間で直接送信される唯一の情報である。メッセージ処理システムは、ＳＩＰベースの規格を利用する。
【０１５０】
テレビ会議クライアントアプリケーション１８００の機能を制御するプロトコルには様々なものがある。例えば、ＳＩＰ、ＲＴＰ、ＲＴＣＰ及びＳＤＰ（Ｓｅｓｓｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）が利用されるかもしれない。
【０１５１】
ＳＩＰの目的はセッション管理である。ＳＩＰは、ＩＰベースのネットワーク上の１人以上の参加者によるマルチメディアセッションの生成、変更及び終了を行うためのテキストベースアプリケーションレイヤコントロールプロトコルである。これを実現するため、ＳＩＰがクライアントとサーバとの間で利用される。ＳＩＰはテレビ会議サーバ２０５に関して前述されている。
【０１５２】
ＲＴＰは、リアルタイムマルチメディア（すなわち、音声及び映像）の送信に利用される。ＲＴＰは、それにより搬送されるマルチメディア情報のタイプに関する追加的な詳細を提供するアプリケーションレイヤプロトコルである。ＲＴＰはトランスポートレイヤの上にあり、通常ＵＤＰ（Ｕｓｅｒ  Ｄａｔａｇｒａｍ  Ｐｒｏｔｏｃｏｌ）の上に置かれる。クライアントアプリケーションにおけるＲＴＰの主要な機能は、タイムスタンプ（音声及び映像同期化のための）及びシーケンス番号の送信と共に、カプセル化するペイロードのタイプ（例えば、ＭＰＥＧ４、Ｈ．２６３、Ｇ．７２３など）の特定である。
【０１５３】
図２０は、本発明の例示的な一実施例によるユーザプレーンプロトコルスタック２０００を示す図である。スタック２０００は、１つのレイヤに映像２０１０と音声２０２０、他のレイヤに映像２０１０と音声２０２０の両方のためのＲＴＰ２０３０、さらなる他のレイヤにＵＤＰポート＃Ｘ２０４０とＵＤＰポート＃Ｙ２０５０、ＩＰ層２０６０、リンク層２０７０及び物理層２０８０を有する。汎用的ＲＴＰヘッダに加えて、コーデック特有のＲＴＰヘッダが使われる。
【０１５４】
ＲＴＣＰはＲＴＰ規格の一部である。ＲＴＣＰは、送り手と受け手との間の統計レポートツールとして利用される。各テレビ会議クライアントアプリケーション１８００は、各自の統計データを収集し、このデータを互いに、そしてサーバ２０５にも送信する。テレビ会議サーバ２０５は、このデータに基づきセッションにおいて生じた問題に関する情報を記録する。
【０１５５】
図２１は、本発明の例示的な一実施例によるコントロールプレーンプロトコルスタック２１００を示す図である。スタック２１００は、１つのレイヤにＳＩＰ２１１０、ＵＩコーデック変更メッセージ処理２１２０及びＲＴＣＰと、ＴＣＰ層２１４０と、ＩＰ層２１５０と、リンク層２１６０と、物理層２１７０とを有する。
【０１５６】
ＳＤＰの主たる目的は、セッションのメディアストリームに関する情報を伝えることである。ＳＤＰは、以下に限定されるものではないが、セッション名及び目的と、当該セッションがアクティブである時間と、セッションを構成するメディアと、当該メディアを受信するための情報（例えば、アドレス、ポート、フォーマットなど）と、メディアタイプと、トランスポートプロトコル（ＲＴＰ／ＵＤＰ／ＩＰ）と、メディアフォーマット（Ｈ．２６３など）と、マルチキャストと、当該メディアのマルチキャストアドレスと、当該メディアのトランスポートポートと、ユニキャストと、当該メディアのリモートアドレスとを有する。
【０１５７】
ＳＤＰ情報は、ＳＩＰメッセージのメッセージ本体である。これらは一緒に送信される。
【０１５８】
本発明の例示的な一実施例による図１８Ａのユーザインタフェース１８０８が説明される。ユーザインタフェース１８０８は、テレビ会議クライアントアプリケーション１８００の重要な構成要素である。ユーザインタフェース１８０８は、複数の表示（ディスプレイ／ボタン／メニュー／…）を含み、すべての入力データ（音声／映像キャプチャ、ボタン、キー打ち）を処理することができる。
【０１５９】
図２２は、本発明の例示的な一実施例による図１８Ａのユーザインタフェース１８０８に対応する画面２２００を示すブロック図である。画面２２００は、「大画面表示」２２１０と、「小画面表示」２２２０と、チャット表示部２２３０と、メンバー表示部２２４０と、チャット編集部２２５０とを有する。
【０１６０】
図１８Ａを再び参照するに、映像キャプチャインタフェース１８３０は、以下の何れか、すなわち、ウェブカメラ（図示せず）と、キャプチャカード及び高画質カメラ（図示せず）と、カメラインタフェース１８３０ａと、マイクロフォンインタフェース１８３０ｂと、ファイルインタフェース１８３０ｃなどを含むことができる。
【０１６１】
ウェブカメラは、Ｗｉｎｄｏｗｓ（登録商標）オペレーティングシステムにより提供されるＶＦＷ（Ｖｉｄｅｏ  Ｆｏｒ  Ｗｉｎｄｏｗｓ（登録商標））ＡＰＩを利用したＵＳＢあるいはフィイヤーワイヤ（ＩＥＥＥ１３９４）インタフェース、あるいはＬｉｎｕｘのような他のオペレータイングシステムにおいて利用される他のキャプチャドライバを通じてサポートされるべきである。もちろん、本発明は、上記インタフェース、オペレーティングシステムあるいはドライバに限定されるものでなく、本発明の趣旨および範囲を維持しながら、他のインタフェース、他のオペレーティングシステム及び他のドライバの利用が可能である。
【０１６２】
メンバー表示モジュール１８３４は、継続中の呼出しに参加しているメンバーを示すのに利用される。この呼出しを開始した人（すなわち、マスタ）は、所望でないメンバーを削除したり、アクティブなメンバーを選ぶことができる。すべてのメンバーはプライベートなチャットメッセージ交換のため１人以上のメンバーを選ぶことができる。さらに、メンバーの状態がメンバー表示モジュール１８３４に示される。その後、メンバーは自らの状態を、例えば、「利用不可」に設定し、当該メンバーが現在利用可能ではないが、すぐに戻るということを他のメンバーに示す。
【０１６３】
映像ストリームに加えて、すべてのメンバーは、チャットモジュール１８３６を利用することにより、他のすべて、あるいは一部のメンバーにチャットメッセージを送信する機会を有する。メッセージはチャット表示に表示され、チャット編集表示で編集される。スクロールバーにより、古いメッセージの閲覧が可能となる。
【０１６４】
本発明の例示的な一実施例によるクライアントアプリケーション１８００の動作シナリオが説明される。以下の説明は、クライアントアプリケーション１８００の特徴の一部の基本的ガイドラインに過ぎず、これら特徴の完全なリストを表すものではない。ここでは、ログイン、呼出しの開始、呼出しの受理及びログオフが説明される。
【０１６５】
ログインは、クライアントアプリケーション１８００が初期的に開始されるとき実行される。ログインは、開始時にオペレーティングシステムに与えられるログイン名に基づき自動的に実行されるか、あるいはログインと独立な他のインタフェースの利用が可能である。ログインは、現在使用されているネットワークの好適な認証方法及びポリシーの管理方法に依存する。最もシンプルな方法は、ネーミングの整合性を維持し、（適用可能な場合）既存のユーザデータベースを再利用する能力を有するようにするため、Ｗｉｎｄｏｗｓ（登録商標）オペレーティングシステムで使われているものと同一のログイン名を利用することであろう。
【０１６６】
図２３は、本発明の例示的な一実施例によるログインインタフェース２３００を示す図である。ユーザが現在サーバにアカウントを持っていない場合には、登録２３３０が行われる。アクセスを容易にするため、電子メールアドレスが何れかの電子メールアドレスインプットボックス２３４０に与えられる。
【０１６７】
呼出しを開始するため、クライアントアプリケーション１８００は、利用可能な候補のリストをサーバ２０５から検索する。クライアントは、当該クライアントがテレビ会議セッションへの参加を所望するユーザを選ぶ。２人の参加者が関与するときには、セッションはユニキャストとして設定され、３人以上の参加者が関与する場合には、セッションはマルチキャストとして設定される。
【０１６８】
図２４は、本発明の例示的な一実施例によるセッション開始のためのユーザ選択インタフェース２４００を示すブロック図である。
【０１６９】
ユーザが呼出しを受けると、呼出しを開始した人の名前を示すメッセージが各自の画面に表示される。その後、ユーザはその呼出しの受け容れ、または拒絶を行うことができる。ユーザが呼出しを受け容れると、クライアントアプリケーション１８００はサーバ２０５に受け容れ（または承認）メッセージを送信する。その後、サーバ２０５は当該呼出しに現在参加しているすべてのメンバーにこの新しいメンバーを通知する。サーバ２０５にキャンセルメッセージを送信することによりユーザが呼出しを拒絶すると、他のすべてのユーザにそのことが通知される。図２５は、本発明の例示的な一実施例による入力された呼出しの受け容れまたは拒絶を行うための案内インタフェース２５００を示すブロック図である。
【０１７０】
ログオフは、テレビ会議サーバ２０５のデータベースエンティティ３０２に含まれるメンバーデータベース３１４からユーザを削除する。セッションに参加する各クライアントにＢＹＥメッセージが送信される。これは、マルチキャストまたはユニキャストを通じて実行することができる。このメッセージの送信にとって、マルチキャストは好適な方法である。
【０１７１】
図２６は、本発明の例示的な一実施例による複数の参加者によるテレビ会議セッションの自動開始方法を示すフロー図である。複数の参加者の中には、開催参加者と他の参加者がいる。テレビ会議セッションは、ユニキャストテレビ会議セッションまたはマルチキャストテレビ会議セッションであってもよい。
【０１７２】
テレビ会議セッションの日時と共に、当該テレビ会議セッションのその他の参加者が、開催参加者により選ばれる（ステップ２６１０）。その他の参加者は、例えば、参加者選択機構を利用することにより選ばれてもよい。
【０１７３】
選択された日時に他の参加者がテレビ会議に参加できるか決定される（ステップ２６２０）。ステップ２６２０は、例えば、他の参加者が選択された日時に参加可能か確認するため、他の参加者のスケジュールに対して選択された日時をチェックすることにより行われる。
【０１７４】
選択された日時と参加者リスト（すなわち、開催参加者とその他の参加者）が、開催参加者からサーバに送信され、サーバに格納される（ステップ２６３０）。本発明の他の実施例では、参加者リストは開催参加者を省略してもよく、しかしながらその場合には、開催参加者はサーバにより確認され（例えば、開催参加者のＩＰアドレスから）、サーバにあるリストに自動的に含められるか、あるいはサーバにあるリストに関連付けされるようにしてもよい。もちろん、本発明の趣旨及び範囲を維持しながら、他の構成も可能である。
【０１７５】
開催参加者がテレビ会議を要求したということを示す案内が、選択された日時にサーバから他の参加者に送信される（ステップ２６４０）。
【０１７６】
その他の参加者はこの案内メッセージの受け容れまたは拒絶を行うことができる。この案内の受け容れまたは拒絶を示すメッセージが、これら他の参加者のそれぞれから開催参加者に送信される（ステップ２６５０）。このメッセージにより案内が拒絶される場合には、このメッセージには拒絶理由が含まれるかもしれない。テレビ会議セッションは開催参加者と案内を受け容れた他の参加者により行われる（ステップ２６６０）。
【０１７７】
図２７は、本発明の例示的な一実施例による複数の参加者の間のマルチキャストセッションの自動開始方法を示すフロー図である。複数の参加者には、開催参加者と他の参加者が含まれる。開催する参加者は、ネットワークを介し他の参加者にコンテンツを配信するため、スケジューリングされたマルチキャストセッションの設定を所望する。マルチキャストセッションは、ライブあるいは予め記録されたソースから開始することができる。
【０１７８】
マルチキャストセッションの日時は、当該マルチキャストセッションの他の参加者と共に、開催した参加者により選ばれる（ステップ２７１０）。この日時と、参加者リスト（例えば、開催した参加者と他の参加者）と、マルチキャストアドレスへのコンテンツの配信リクエストとが、開催する参加者からサーバに送信される（ステップ２７２０）。本発明の他の実施例では、この参加者リストは開催する参加者を省略してもよく、しかしながらこの場合には、開催した参加者はサーバにより確認され（例えば、開催した参加者のＩＰアドレスから）、サーバのリストに自動的に含められるか、あるいは少なくともサーバにあるリストと関連付けされる。もちろん、本発明の趣旨及び範囲を維持しながら、他の構成も可能である。
【０１７９】
日時と参加者リスト（例えば、開催した参加者と他の参加者）はサーバにより格納され（ステップ２７３０）、マルチキャストアドレスがサーバにより割り当てられ、マルチキャストソースに送信される（ステップ２７４０）。
【０１８０】
参加者リスト（例えば、開催した参加者と他の参加者）の各参加者に、マルチキャストセッションが（選択された）日時に開催されると通知され、各自のローカルクライアント装置にマルチキャストセッションを記録する選択肢が与えられる（ステップ２７５０）。後者は、対象となっている参加者が当該マルチキャストセッションに参加できない場合、あるいは実際の参加者が参加したにもかかわらず当該マルチキャストセッションの記録を所有したい場合において好ましい。
【０１８１】
（選択された）日時に、案内がサーバから参加者リストの各参加者に送信される。この案内には、当該マルチキャストセッションのマルチキャストアドレスが含まれる（あるいは別に関連付けされるかもしれない）（ステップ２７６０）。
【０１８２】
参加者はこの案内の受け入れ、あるいは拒絶を行うことができる。案内が拒絶されると、拒絶をした参加者は以降の時点での参加を選択することができる。しかしながら、案内が受け容れられると、受け容れた参加者のそれぞれのテレビ会議クライアントアプリケーションは、ＩＧＭＰ（Ｉｎｔｅｒｎｅｔ  Ｇｒｏｕｐ  Ｍｕｌｔｉｃａｓｔ  Ｐｒｏｔｏｃｏｌ）をネットワークに送信する（ステップ２７７０）。その後、マルチキャストセッションは開催した参加者と受け容れた参加者との間で行われ、コンテンツがマルチキャストソースからマルチキャストアドレスに送信される（ステップ２７８０）。特に、コンテンツは、マルチキャスト上のマルチキャストソースからネットワークに送信され、例えば、ネットワークルータにおいてコピーされる。
【０１８３】
例示された実施例が添付された図面を参照して説明されたが、本発明はこれらそのままの実施例に限定されるものではなく、本発明の趣旨及び範囲を逸脱することなく他の様々な変更及び修正が当業者により行われるかもしれないということは理解されるであろう。そのような変更及び修正のすべては、添付されたクレームにより定義されるような本発明の範囲内に含まれる。
【図面の簡単な説明】
【０１８４】
【図１Ａ】図１Ａは、本発明の例示的な一実施例による本発明が適用されるコンピュータシステム１００を示すブロック図である。
【図１Ｂ】図１Ｂは、本発明の例示的な一実施例によるユニキャストテレビ会議セッションを示すブロック図である。
【図１Ｃ】図１Ｃは、本発明の例示的な一実施例によるマルチキャストテレビ会議セッションを示すブロック図である。
【図２】図２は、本発明の例示的な一実施例による本発明が適用されるネットワーク２００を示すブロック図である。
【図３】図３は、本発明の例示的な一実施例による図２のテレビ会議サーバ２０５を示すブロック図である。
【図４】図４は、本発明の例示的な一実施例による図３のデータベースエンティティに含まれるメンバーデータベース３１４のメンバーデータベースエントリ４００を示す図である。
【図５】図５は、本発明の例示的な一実施例による図３のデータベースエンティティ３０２に含まれるアクティブセッションデータベース３１２のアクティブセッションエントリ５００を示すブロック図である。
【図６】図６は、本発明の例示的な一実施例によるＳＮＭＰ（Ｓｉｍｐｌｅ  Ｎｅｔｗｏｒｋ  Ｍａｎａｇｅｍｅｎｔ  Ｐｒｏｔｏｃｏｌ）クライアント−サーバアーキテクチャ６００を示すブロック図である。
【図７】図７は、本発明の例示的な一実施例によるＳＩＰ（Ｓｅｓｓｉｏｎ  Ｉｎｉｔｉａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）を利用したテレビ会議セッションの登録方法を示す図である。
【図８Ａ】図８Ａは、本発明の例示的な一実施例によるＳＩＰを利用した湯にキャストテレビ会議セッションの設定方法を示す図である。
【図８Ｂ】図８Ｂは、本発明の例示的な一実施例によるＩＮＶＩＴＥリクエストが第１クライアント８０２から受信されるとき（図８Ａのステップ８１０）、図２のテレビ会議サーバ２０５により行われるステップを示す図である。
【図９】図９は、本発明の例示的な一実施例による図８Ａの方法をさらに示す図である。
【図１０】図１０は、本発明の例示的な一実施例によるＳＩＰを利用したマルチキャストテレビ会議の設定方法を示す図である。
【図１１】図１１は、本発明の例示的な一実施例によるＳＩＰを利用したテレビ会議セッションのキャンセル方法を示す図である。
【図１２】図１２は、本発明の例示的な一実施例によるＳＩＰを利用した２つのクライアント間のテレビ会議セッションの終了方法を示す図である。
【図１３】図１３は、本発明の例示的な一実施例によるＳＩＰを利用した３つのクライアント間のテレビ会議セッションの終了方法を示す図である。
【図１４】図１４は、本発明の例示的な他の実施例によるＳＩＰを利用した３つのクライアント間のテレビ会議セッションの終了方法を示す図である。
【図１５】図１５は、本発明の例示的な一実施例による解像度及びフレームレート調整のための信号処理方法を示す図である。
【図１６】図１６は、本発明の例示的な一実施例による解像度及びフレームレート調整（クライアント２及び３）前の信号処理を示す図である。
【図１７】図１７は、本発明の例示的な一実施例による解像度及びフレームレート調整（クライアント２及び３）後の信号処理を示す図である。
【図１８Ａ】図１８Ａは、本発明の例示的な一実施例によるテレビ会議クライアントアプリケーション１８００のブロック図である。
【図１８Ｂ】図１８Ｂは、本発明の例示的な一実施例による図１８Ａのマルチメディアインタフェースレイヤ１８０２に含まれる音声ミキサ１８９９をさらに示すブロック図である。
【図１８Ｃ】図１８Ｃは、本発明の例示的な一実施例による図１８Ａのマルチメディアインタフェースレイヤ１８０２に含まれるエコーキャンセルモジュール１８９８をさらに示すブロック図である。
【図１９】図１９は、本発明の例示的な一実施例による音声コーデック１８０４ａ及び／または映像コーデック１８０４ｂに含まれるデコーダ１８９０により利用される方法を示す図である。
【図２０】図２０は、本発明の例示的な一実施例によるユーザプレーンプロトコルスタック２０００を示す図である。
【図２１】図２１は、本発明の例示的な一実施例によるコントロールプレーンプロトコルスタック２１００を示す図である。
【図２２】図２２は、本発明の例示的な一実施例による図１８Ａのユーザインタフェース１８０８に対応する画面２２００を示すブロック図である。
【図２３】図２３は、本発明の例示的な一実施例によるログインインタフェース２３００を示す図である。
【図２４】図２４は、本発明の例示的な一実施例によるセッション開始のためのユーザ選択インタフェース２４００を示すブロック図である。
【図２５】図２５は、本発明の例示的な一実施例による入力された呼出しの受け容れまたは拒絶を行うための案内インタフェース２５００を示すブロック図である。
【図２６】図２６は、本発明の例示的な一実施例による複数の参加者によるテレビ会議セッションの自動開始方法を示すフロー図である。
【図２７】図２７は、本発明の例示的な一実施例による複数の参加者間のマルチキャストセッションの自動開始方法を示すフロー図である。
【図１Ａ】
2005513606.tif 000003
【図１Ｂ】
2005513606.tif 000004
【図１Ｃ】
2005513606.tif 000005
【図２】
2005513606.tif 000006
【図３】
2005513606.tif 000007
【図４】
2005513606.tif 000008
【図５】
2005513606.tif 000009
【図６】
2005513606.tif 000010
【図７】
2005513606.tif 000011
【図８Ａ】
2005513606.tif 000012
【図８Ｂ】
2005513606.tif 000013
【図９】
2005513606.tif 000014
【図１０】
2005513606.tif 000015
【図１１】
2005513606.tif 000016
【図１２】
2005513606.tif 000017
【図１３】
2005513606.tif 000018
【図１４】
2005513606.tif 000019
【図１５】
2005513606.tif 000020
【図１６】
2005513606.tif 000021
【図１７】
2005513606.tif 000022
【図１８Ａ】
2005513606.tif 000023
【図１８Ｂ】
2005513606.tif 000024
【図１８Ｃ】
2005513606.tif 000025
【図１９】
2005513606.tif 000026
【図２０】
2005513606.tif 000027
【図２１】
2005513606.tif 000028
【図２２】
2005513606.tif 000029
【図２３】
2005513606.tif 000030
【図２４】
2005513606.tif 000031
【図２５】
2005513606.tif 000032
【図２６】
2005513606.tif 000033
【図２７】
2005513606.tif 000034
【国際調査報告】
2005513606.tif 000035