JPH11513212A - マルチメディア・オブジェクトを関連づけるシステムおよび方法 - Google Patents

Abstract

(57)【要約】 セントラル・マルチメディア・ブリッジ（３２）を使用して複数の会議参加者（３４〜３７）からのマルチメディア信号を、各参加者ごとに単一のコンポジット信号に結合するテレビ会議システム（３０）および方法が開示されている。このシステムによれば、各会議参加者はディスプレイの選択した部分をキーイン・キーアウトすることや、表示されるイメージをオーバラップすることを含めて、他の参加者の個別ディスプレイをカスタマイズすることができ、また合成ビデオ・ストリームの中の個別イメージをクリック・アンド・ドラッグ操作などによって特定することができる。このシステムはビデオ合成モジュールのチェインを使用しており、これらのモジュールは任意の数の会議参加者からのビデオ信号ストリームをリアルタイムで結合するように必要に応じて拡張可能である。マルチメディア関連づけソフトウェアは、異種のマルチメディア・タイプを関連づけてマルチメディア用途用にディスプレイ機能と操作機能を強化するためのものである。また、このシステムによれば、各ユーザは会議に提供する情報をだれに受け取らせるかを動的に変更することもできる。

Description

【発明の詳細な説明】 マルチメディア・オブジェクトを関連づけるシステムおよび方法発明の背景 発明の分野 本発明はマルチメディア・オブジェクトの関連づけに関する。さらに具体的に は、本発明はマルチメディア・オブジェクトを関連づけ、例えば、リアルタイム・ テレビ会議（real-time video conferencing）などの、マルチメディア用途用に ディスプレイ機能と操作機能を強化するためのシステムおよび方法に関する。 関連技術の説明 テレビ会議（video teleconferencing）は、異なるロケーションにいる人達が 音声とビデオ・データを相互に送信し合って、参加者の全員が１つの会議室にい るかのようにシミュレートする目的で行われている。マルチポイント会議に参加 している各人は他の参加者の全員または大部分を見たいと望んでいる。従って、 さまざまなビデオ・ストリームは空間的に離れている各参加者に、シングル・ビ デオ・ディスプレイの別々のスクリーンに表示されるか、あるいはシングル・ビ デオ・ディスプレイの別々のエリアに表示されている。ビデオ会議端末の各々は ローカルで生成されたビデオ・イメージ（画像、映像など）を他の参加者の端末 の各々に送信し、ビデオ・イメージを他の参加者の各々から受信している。従来 技術では、このことは３ウェイ会議では、６つのビデオ・ストリームを伝送しな ければならないこと、５ウェイ会議では、１２のビデオ・ストリームを伝送しな ければならないこと、８人が参加する会議では、５６のビデオ・イメージを伝送 しなければならないこと（以下同様）を意味していた。一般的に、Ｎ人の人がテ レビ会議を開いているとすれば、Ｎ×（Ｎ−１）個の伝送チャネルを使用しなけ ればならない。従って、多数の人が参加するテレビ会議のために使用されるチャ ネル数は相対的に多くなるため、従来のシステムではコスト的に問題があった。 さらに、参加者には、異なる参加者から多数のイメージを受信し、表示するため にはそれに見合う数の入力チャネル、デコーダ(復号器)、およびトランスレータ （伝送されるビデオ・フォーマットが異なる場合）が必要であった。そのために 、必要となるチャネル、デコーダ、および／またはトランスレータの数がコスト 的に問題となっていた。 従来のシステムによれば、テレビ会議参加者は表示されたイメージの一部をキ ーインまたはキーアウトすることにより、あるいは参加者のさまざまなイメージ を自然に見えるようにオーバラップさせることによってビデオ・ディスプレイを カスタマイズすることも、イメージを好きなように置いてサイズ変更することも できなかった。また、参加者はビデオ・イメージを他のマルチメディア・オブジ ェクトと関連づけて、享受できるさまざまな会議機能を強化することもできなか った。発明の概要 本発明の目的は複数のユーザで使用され、各ユーザへの所要伝送バンド幅を最 小限にする、フレキシブルなリアルタイム・テレビ会議システムを提供すること にある。 本発明の別の目的は、各参加者が必要とするバンド幅、エンコード（符号化） およびビデオ標準の１つのビデオ（およびオーディオ）ストリームだけを、セン トラル・マルチメディア・ブリッジ(central multimedia bridge)から受信する ようにしたテレビ会議システムを提供することにある。 本発明のさらに別の目的は、各参加者が他の参加者のビデオ・イメージを完全 にカストマイズされたディスプレイに合成できるようにするテレビ会議サービス を提供することにある。 本発明のさらに別の目的は、無限に拡張可能な優先駆動型(priority driven) ビデオ合成ユニットを提供し、任意の数のビデオ信号を単一の優先ビデオ・スト リームに結合するようにしたことにある。 本発明のさらに別の目的は、ビデオ・ディスプレイのイメージを階層構造で関 連づけると共に、マルチメディア・オブジェクトを一緒に関連づけてビデオ会議 および他のマルチメディア・アプリケーションを強化する方法を提供することに ある。 本発明のさらに別の目的は、各ユーザが会議に提供する情報をだれに受信させ るかを動的に変更できるようにしたことにある。 本発明のさらに別の目的は、ユーザが合成ビデオ・ストリームの中の個々のイ メージを、クリック・アンド・ドラッグ操作などによって特定できるようにした ことにある。 本発明のその他の目的、利点および新規な特徴は以下の説明の中で明らかにす るが、これらは以下の説明を読むことにより、あるいは本発明を実施することに よりこの分野の当業者に当然に理解されるものである。本発明の目的および利点 は請求の範囲に明確化されている本発明の特徴事項によって実現し、達成するこ とが可能である。 本発明は、各参加者に対してカストマ・プレゼンテーション・コントロールを もつマルチポイント・マルチメディア・テレビ会議サービスである。先進的マル チメディア・ブリッジは、各参加者用に機能が豊富で、カストマが制御できるメ ディア（主に、ビデオとオーディオ）混合機能を備えている。このマルチメディ ア・ブリッジはユーザが所有する必要も、ユーザと一緒に置いておく必要もなく 、タイムスライス・ベースでレンタルできる共有ネットワーク・リソースである 。「スター形」ネットワーク・トポロジが各ユーザをサーバ(または複数のサー バ)に接続するために使用される。セントラル・ブッリジ・ロケーションには、 異種タイプのコーダとデコーダも用意されているので、異種タイプと異種メーカ の機器をもつカストマは相互に通信し合うことが可能になっている。中央で結合 するので、各参加者のデスクトップに複数の入力チャネルや複数のデコーダを設 ける必要がない。 各ユーザは、必要とするバンド幅、エンコードおよびビデオ標準のビデオ・ス トリームを１つだけ受信する。コード変換(transcoding)と標準変換のすべては マルチメディア・ブリッジで行われる。先進的マルチメディア・ブリッジによれ ば、ユーザは他の会議参加者のディスプレイと異なるビジュアルスペース（視覚 的空間）を自分用に合成することができる。本発明がパーソナル・プレゼンス・ システム（personal presense system - PPS）と呼ばれるのは、この「パーソナ ル」コントロールの特徴があるためである。 本発明のソフトウェアはマルチメディア・ブリッジを制御、管理し、会議のセ ットアップと調整(コーディネート)を行い、使いやすいヒューマン・インタフェ ースを提供している。本発明を使用するマルチメディア会議の各参加者は、さま ざまのビデオ・イメージを自分に都合のようにようにディスプレイに並べ、セッ ション期間の途中でいつでもこれらを並べ替えることができる。 自分のディスプレイを配置するには、会議参加者はウィンドウ操作ワークステ ーション・ディスプレイと同じように、ビデオ・イメージを移動、スケーリング し、これらのビデオ・イメージを優先順にオーバラップ（重ね合わせ）すること ができる。ユーザは自分のビデオ・ディスプレイに表示されているイメージのい ずれかを選択して、そのイメージに操作を加えることができる。ユーザのポイン ティング・デバイス（例えば、マウス）はＰＣ Ｗｉｎｄｏｗ環境でサポートさ れている「クリック・アンド・ドラッグ」操作と同じように、イメージを移動し 、サイズを変えることができる。本発明によれば、この前例のない能力はビデオ ・ワークスペースにもたらされる。さらに、人やチャートのように、各イメージ の種々エレメントはイメージに「キー」インまたはイメージから「キー」アウト できるので、必要とするエレメントを四角の境界に制約されることなくより自然 な形で組み立てることができる。 また、本発明は、ユーザがマルチメディア・ストリームを相互に「関連づける」 ことにより、コンポジットまたはオブジェクト・グループの作成を可能にするプ レゼンテーション・コントロール機能も備えている。このマルチメディア関連づ け機能を使用すると、オーディオとビデオを同時に受信し、その同期をとること も、録音されたオーディオと同期してピクチャ・スライスを配送することもでき る。マルチメディア・プロバイダはこの機能を使用して、異なるサーバからの情 報を同期化することにより、情報記憶容量の制約やある種の情報の著作権による 制約に対処することができる。 ユーザはいくつかの異なるビデオ・イメージを関連づけて１つのビデオ・シー ンを合成することができる。カメラ・アレイから送信されるイメージを関連づけ ると、パノラマビューを生成できるので、このパノラマ・ビューをパンすること をサポートすることができる。また、異なる着信イメージを関連づけると、テレ ビ会議ユーザは他の会議参加者のサブセットを選んで見ることができるので、結 合ビデオ・シーンを左右にパンするだけで異なる会議参加者のイメージに都合の よい方法でアクセスることもできる。 以上のほかに、ユーザはオーディオ・インスタンスとビデオ・インスタンスを 一緒に関連づけると、ビデオ・インスタンスのサイズが変わったときオーディオ ・インスタンスのボリューム(音量)が変化し、ビデオ・インスタンスのロケーシ ョンが変わったときオーディオ・インスタンスのステレオ・パン・ボリュームが 変化するようにすることができる。図面の簡単な説明 以下、本発明の理解を容易にするために、添付図面を参照して本発明の好まし い実施例について詳しく説明するが、図中において同様の参照符号は同様の素子 を参照している。添付図面において、 図１は本発明の主要コンポーネントを示す概要図である。 図２は本発明を使用するテレビ会議セッションを絵で示す図である。 図３は本発明に関連するユーザ・ステーションを絵で示す図である。 図４は、本発明を使用するテレビ会議セッション期間のサンプル・ビデオ・ディ スプレイを示す図である。 図５は本発明で使用される先進的マルチメディア・ブリッジを示す概略図であ る。 図６は図５のマルチメディア・ブリッジのビデオ部分を示す概略図である。 図７は図６のビデオ・ブリッジ部分内のビデオ・コンポーザを示す概略図であ る。 図８は図７のビデオ・コンポーザ・チェイン内のビデオ合成モジュールを示す 概略図である。 図９は本発明で使用されるソフトウェア・コンポーネントを示すビルディング ブロック図である。 図１０は図９に示すクライアント・プログラムのオブジェクト・モデル図であ る。 図１１は図９に示すサービス・セッション・プログラムのオブジェクト・モデ ル図である。 図１２は図９に示すリソース・エージェント・プログラムに関連して使用され るブリッジ・マネージャ・プログラムのオブジェクト・モデル図である。 図１３は本発明のマルチメディア・ブリッジとのセッションを確立するプロセ スを示すフローチャートである。 図１４は本発明を使用するビデオ・イメージ関連づけを絵で示す図である。 図１５は本発明と共に使用されるマルチメディア・オブジェクト関連づけソフ トウェアのオブジェクト・モデル図である。 図１６はビデオ・インスタンス・グループ・オブジェクトを使用するマルチメ ディア・オブジェクト関連づけの例を示すオブジェクト・モデル図である。 図１７はビデオ・インスタンスとオーディオ・インスタンスが一緒に関連づけ られたマルチメディア・オブジェクト関連づけの例を示すオブジェクト・モデル 図である。 図１８は本発明を使用するビデオ・ディスプレイの一部をキーイングアウトす るプロセスを絵で示す図である。好適実施例の詳細な説明 図面に示す本発明の好ましい実施例を説明するに当たり、説明を理解しやすく するために特定の用語が用いられている。しかし、本発明はそこで選択されてい る特定の用語に限定されるものではなく、当然に理解されるように、各特定エレ メントには、同じように動作して類似の目的を達成する技術的に同等の機能がす べて含まれることはもちろんである。 図１に示すように、リアルタイム・テレビ会議システム１０は先進的マルチメ ディア・ブリッジ（advanced multimedia bridge 〜 AMB）３２と、ＡＭＢ ３ ２に接続された複数のユーザ・ステーション３４〜３７とを含んでいる。ユーザ・ ステーション３４〜３７とＡＭＢ ３２の間の接続は電話モデム・リンクやブロ ードバンドＩＳＤＮなどのように、従来の種々電気的／データ接続のどれにす ることも可能である。ユーザ・ステーション３４〜３７の各々はＡＭＢ ３２と の間でビデオ、オーディオおよび／またはその他のデータを送受信する。ＡＭＢ ３２は、ユーザ・ステーション３４〜３７とＡＭＢ ３２の間の従来の種々通信 リンクとのインタフェースとなるように構成され、ユーザ・ステーション３４〜 ３７との間でデータを送受信するように構成されている。 図２は本発明を使用するテレビ会議セッションを示している。ユーザ・ステー ション３４〜３７の各々には一人または複数のユーザが存在し、テレビ会議を見 るためのビデオ端末、オーディオ入出力機能、および／または１つまたは複数の ビデオ・カメラが置かれている。ビデオ・カメラからのデータおよびユーザから のオーディオ・データはユーザ・ステーション３４〜３７の各々からＡＭＢ ３ ２に伝送される。ＡＭＢ ３２はこのデータを以下で詳しく説明するように結合 して操作し、ユーザ・ステーション３４〜３７にいるユーザの各々にリターン信 号を返送する。 図３を参照するに、図１のユーザ・ステーション３４が詳細に示されている。 ユーザ・ステーション３４には、図示のように、シングル・ユーザ４２、シング ル・カメラ４４、およびシングル・ディスプレイ・ステーション４６が置かれて いる。カメラ４４とディスプレイ・ステーション４６は、ユーザ・ステーション ３４をＡＭＢ ３２に接続している通信チャネルに電気的に接続されている。デ ィスプレイ・ステーション４６は従来のスクリーン（画面）４８をもち、他のユ ーザ・ステーション３５〜３７のビデオ信号から受信したイメージが、以下で詳 しく説明するようにそこに表示される。このユーザ・ステーションがテレビジョ ンとセットトップボックス(set-top-box)を含んでいれば、ユーザ４２はリモー トコンロール・デバイス４９を使用してスクリーン４８のディスプレイを制御す ることができる。また、このユーザ・ステーションがＰＣまたはワークステーシ ョンを含んでいれば、ユーザはマウスを使用してビデオ・ディスプレイを制御す ることができる。 ユーザ・ステーション３４は一人のユーザ４２、１つのカメラ４４および１つ のディスプレイ端末４６をもつものとして示されているが、他のユーザ・ステー ション３５〜３７は２人以上のユーザがいて、および／またはカメラが２つ以上 である場合もあり得る。さらに、種々の端末デバイスを使用することも可能であ り、この中には、スタンドアロンＰＣ、ネットワーク・ワークステーション、さ らには別のロケーションに置かれている制御ソフトウェア（下述する）搭載の従 来テレビジョン・モニタが含まれる。エンドユーザ・アプリケーションはセット トップボックスまたはコントロールＰＣで実行される。図３に示すユーザ・ステ ーション３４の具体的構成は単なる例示である。 図４に示すように、図３のスクリーン４８が詳しく示されている。スクリーン ４８にはポップアップ・ウィンドウ５２があり、そこにはテレビ会議の他の参加 者５４〜５８が表示されている。参加者５４〜５８の各々からの別々のビデオ・ イメージは、ユーザ・ステーション３５〜３７の他の各々からの別々のビデオ信 号でＡＭＢ ３２に送ることが可能である。別の方法として、参加者５４〜５６ の一部が同じ部屋にいることもあるので、シングル・ビデオ・イメージ信号でキャ プチャすることも可能である。このようなことが起こるのは、参加者５４〜５６ が実際に、ウィンドウ５２に示すように、シングル・ユーザ・ステーションに一 緒にいる場合である。しかし、参加者５４〜５６の各々からのイメージが別々の ビデオ・カメラからのものであることも起こり得る。以下で詳しく説明するよう に、ＡＭＢ ３２はさまざまな参加者５４〜５８からのイメージをポップアップ ・ウィンドウ５２に表示するように結合し、テレビ会議の参加者のシングル・ビ ジュアル・ディスプレイをユーザに表示できるので、参加者がテレビ会議に一緒 にいるかのような錯覚が生じることになる。 図５に示すように、ＡＭＢ ３２の全体的ハードウェア・アーキテクチャが概 略図で示されている。ＡＭＢ ３２は、ユーザ・ステーション３４〜３７からの 着信信号と送出信号を処理するためのネットワーク・インタフェース７２、７８ を含んでいる。デマルチプレクサ７３は着信信号をデータ、オーディオ、ビデオ 、およびコントロールのそれぞれの信号に分離し、これらの信号をそれぞれのデ ータ、オーディオおよびビデオのそれぞれのブリッジ、およびコントロール・ユ ニット７６に転送する。コントロール・ユニット７６はデータ、オーディオおよ びビデオ・ブリッジの各々の機能を、ユーザ・ステーション３４〜３７から受信 したコントロール信号と指示に基づいて制御する。マルチプレクサ・ユニット７ ７は ブリッジの各々とコントロール・ユニット７６からの送出信号を多重化し、それ らをネットワーク・インタフェース７８を経由してユーザ・ステーション３４〜 ３７に返送する。 図６に示すように、ＡＭＢ ３２のビデオ部分（ＡＶＢ）３２ａが概略図で示 されている。ＡＶＢ ３２ａはＮ人のユーザの各々からコントロール信号Ｃ１、 Ｃ２、..．ＣＮを受信する。また、ＡＶＢ ３２ａはユーザ・ステーション３４〜 ３７に置かれているＫ個のカメラの各々からビデオ入力信号ＶＩＮ１、ＶＩＮ２、 ...ＶＩＮＫも受信する。なお、上述したように、カメラの数は必ずしもユーザ の数と同じである必要はない。ＡＶＢ ３２ａはビデオ信号ＶＯＵＴ１、ＶＯＵ Ｔ２、...ＶＯＵＴＮをＮ人のユーザに出力する。以下で詳しく説明するように、 ビデオ出力信号の各々はユーザの各々からのコントロール入力によって制御され る。例えば、ビデオ出力信号ＶＯＵＴ１は図４のポップアップ・ウィンドウ５２ に示すビデオ・イメージを表すことが可能である。ポップアップ・ウィンドウ５ ２を見ているユーザは、以下で詳しく説明するように、コントロール信号Ｃ１を ＡＶＢ ３２ａに送ることによってビデオ信号ＶＯＵＴ１の内容とプレゼンテー ションを制御することができる。 カメラからのビデオ入力信号はビデオ・インタフェース正規化ユニット７２ａ に送られる。このビデオ・インタフェース・ユニット７２ａは、ＡＭＢ ３２と ユーザ・ステーション３４〜３７の間の接続に用意されている、さまざまの通信 フォーマットを従来と同じ方法で処理する。また、このユニット７２ａは入力ビ デオ信号のカラー成分を正規化し、ビデオ入力信号の各々の各画素（「ペル」また は「ピクセル」）が対応する赤、緑、青の成分をもつようにする。ビデオ・インタ フェース正規化ユニット７２ａの出力信号は正規化入力ビデオ信号である。 ビ デオ合成ユニット（video composing unit - VCU）７４はカメラから正規化入力 ビデオ信号を受信し、その信号を結合する。また、ＶＣＵ ７４にはコントロー ル・ユニット７６から出力されたコントロール信号も入力され、コントロール・ ユニット７６はユーザ・コントロール信号Ｃ１、Ｃ２、.．ＣＮを処理してＶＣＵ ７４の出力の内容とプレゼンテーションを制御する。ＶＣＵ ７４とコントロー ル・ユニット７６のオペレーションは以下で詳しく説明する。ＶＣＵ ７４の出 力は複数の正規化ビデオ信号であり、その各々は図４のポップアップ・ウィンド ウ５２に示すものと同じようなビデオ・イメージを収めている。 ビデオ・インタフェース非正規化ユニット（video interface and denormaliz ation unit）７８ａはＶＣＵ ７４からの出力を受信し、出力信号ＶＯＵＴ１、 ＶＯＵＴ２、...ＶＯＵＴＮをＮユーザの各々に送る。ビデオ・インタフェース非 正規化ユニット７８ａは、入力ビデオ信号を非正規化してユーザ要求の各々に従 って該当のビデオ出力フォーマットを出力する。 図７に示すように、ＶＣＵ ７４の詳細が概略図で示されている。図７の説明 を簡単にするために、ＶＣＵ ７４のコントロール入力とコントロール回路は図 ７の概略図には示されていない。 ＶＣＵ ７４は複数のビデオ合成チェイン(video composing chain - VCC)９ ２〜９４から構成されている。ＶＣＣは各出力ＶＯＵＴ１、ＶＯＵＴ２、...ＶＯ ＵＴＮごとに１つある。すなわち、システムがＮ人のユーザをサポートするため には、ＶＣＵ ７４は少なくともＮ個のＶＣＣ ９２〜９４をもっていなければ ならない。 ＶＣＣ ９２〜９４は複数のビデオ合成モジュール（video composing mojule - VCM）ユニット９６〜１０７から構成されている。ＶＣＣ ９２はＶＣＭ ９ ６〜９９を含み、ＶＣＣ ９３はＶＣＭ １００〜１０３を含み、ＶＣＣ ９４ はＶＣＭ １０４〜１０７を含んでいる。 ＶＣＭ ９６〜１０７の各々は他のＶＣＭ ９６〜１０７の各々と同じである 。ＶＣＭ ９６〜１０７の各々はＡ入力とＢ入力をもち、その各々には別々のビ デオ信号が入力される。ＶＣＭ ９６〜１０７の各々は、以下で詳しく説明する ようにＢ入力からのビデオ信号をＡ入力からのビデオ信号の上に重ねる。その出 力はＢ信号をＡ信号の上に重ねた結果である。 ＶＣＣ ９２〜９４への入力はそれぞれスイッチ１１２〜１１４から与えられ る。スイッチへの入力はカメラＶＩＮ１、ＶＩＮ２、...ＶＩＮＫからのビデオ入 力信号である。コントロール信号（図７に図示せず）はビデオ入力信号の特定の １つひとつをＶＣＣ ９２〜９４のＶＣＭ ９６〜１０７の特定入力に与えるよ うにスイッチ１１２〜１１４を動作させる。スイッチ１１２〜１１４へのコント ロール信号はユーザが与えるコントロール入力に応じて変化する。例えば、ＶＯ ＵＴ１を受信しているユーザがビデオ入力信号の特定サブセットを見ることを望 んでいれば、そのユーザは該当のコントロール信号をＡＶＢ ３２ａに与えるこ とになる。コントロール・ロジック（図７に図示せず）は、スイッチが要求され たビデオ入力信号をＶＣＣ ９２のＶＣＭ ９６〜９９に与えてＶＯＵＴ１が得 られるようにスイッチ１１２を動作させる。 図７に示すＶＣＵ ７４では、ＶＣＣ ９２〜９４は、各々がそれぞれ４つの ＶＣＭ ９６〜９９、１００〜１０３、１０４〜１０７をもつものとして示され ている。従って、ＶＣＣ ９２〜９４は５つの別々のビデオ・イメージを結合す る能力をもっている。これはＶＣＣ ９２を調べると理解できるように、ＶＣＭ ９６はビデオ入力の２つを受信し、これらの入力を結合して出力を得ている。Ｖ ＣＭ ９６の出力はＶＣＭ ９７へのＡ入力として得られ、ＶＣＭ ９７は別の ビデオ信号をそのＢ入力から受信し、その信号をＡ入力と結合してＶＣＭ ９８ への出力が得られ、ＶＣＭ ９８は結合入力をそのＡ入力として受信し、新しい ビデオ信号をそのＢ入力から受信し、これらの信号を結合し、ＶＣＭ ９９のＡ 入力への出力が得られる。ＶＣＭ ９９は結合信号をそのＡ入力から、新しいビ デオ信号をそのＢ入力から受信し、これらの信号を結合し、出力ＶＯＵＴ１が得 られる。図７に示すものとは別に、任意の数のビデオ構成モジュールをもつビデ オ合成チェインを構築することが可能である。重ねることができるイメージの最 大数はＶＣＣ内のＶＣＭの数よりも常に１だけ大きくなっている。 図７には、ＶＣＣ ９２〜９４は各々がそれぞれ４つのＶＣＭ ９６〜９９、 １００〜１０３、１０４〜１０７をもち、一緒にハードワイヤされているものと して示されているが、ＶＣＭ間の接続自体がスイッチングされるようにＶＣＵ７ ４を構成することも可能である。そのようにすると、ユーザが特定の数のＶＣＭ を利用可能ＶＣＭプールから要求し、そのあと、カスタマイズされたＶＣＣ内の スイッチで一緒にワイヤされるようにすることが可能になる。スイッチ構成は公 知のものを使用できるので、そうようなスイッチ構成を実装することはこの分野 の通常知識の範囲に属するものである。 図７に記載されているビデオ合成チェインはセントラル・ネットワーク・ブリッ ジに置かれているものとして示されている。当然に理解されるように、本発明の これらの部分はここで説明しているものと同じ目的のために、一部のユーザ・ス テーションまたは類似の端末機器内で使用することも可能であるので、本発明の これらの部分はセントラル施設内で使用されることに限定されない。 図８に示すように、図７のＶＣＭ ９６の詳細が概略図で示されている。上述 したように、図７のＶＣＭ ９６〜１０７は基本的に同一であり、異なるのはそ こに与えられる入力だけである。 ＶＣＭ ９６はＡ入力からのビデオ・データをＢ入力からのビデオ・データと マージする。出力ラスタ内の各ペル位置ごとに、Ａ入力またはＢ入力からのデー タの１ペルが出力に転送される。どちらの入力が選択されるかはＡおよびＢ入力 ビデオ・ストリームの各々内の各ペルに割り当てられた優先度によって決まる。 図８に示すＶＣＭ ９６のＡ入力では、ビデオの各ペルは各々が２４ビットをも ち(赤、緑、青ごとに８ビット)、優先度を表す８ビットをもつものとして示され ている。従って、Ａ入力の各ペルは３２ビット値で表されている。同様に、Ｂ入 力では、各ペルは２４ビットのビデオ信号(赤、緑、青ごとに８ビット)と８ビッ トの優先度で表されている。従って、Ａ信号とまったく同じように、Ｂ入力の各 ペルは３２ビット値で表されている。 ここで説明し、図面に示されているビット値は単なる例示であり、本発明の範 囲を限定するものではない。ＶＣＭ ９６への入力と出力のビット値として開示 されているものは、いずれも、本発明を変更しない範囲で変えることが可能であ る。例えば、ビデオ入力と出力を１８ビットまたは３０ビットにし、優先度／キ ー入力と出力を６ビットまたは１０ビットにすることが可能であり、以下同様で である。 Ａビデオ入力は優先駆動型マルチプレクサ１２２に直接に与えられる。他方、 Ｂビデオ入力は最初に512K x 32ビットのフレームメモリ１２４に送られ、そこ にはＢ入力ビデオ信号のビデオ・データと優先度データがストアされている。Ｂ 優先度入力とフレームメモリとの間には、以下で詳しく説明するように、フレキ シブルな優先度マスキング・生成システムが置かれており、このシステムはＢ入 力のオリジナル優先度値を変更するものである。フレームメモリ１２４はＢビデ オ入力をＡビデオ入力に対して同期をとり、オフセットし、ミラーリングし、ス ケーリングするために使用できる。 フレームメモリ１２４の出力は優先度駆動型マルチプレクサ１２２に与えられ る。従って、優先度駆動型マルチプレクサ１２２はＡ入力の各ペルの優先度をフ レームメモリ１２４からのＢ入力の各ペルの優先度と比較し、高い方の優先度が 関連づけられているペルを出力する。また、優先度駆動型マルチプレクサ１２２ はＡ入力とＢ入力の各ペルの間で最高優先度をもつペルの優先度も出力する。入 力アドレス・ジェネレータ１２６はＢビデオ入力のＨ、Ｖ、およびクロック信号 を受信する。この入力アドレス・ジェネレータ１２６は、Ｂビデオ入力データに 大きな変更を加えることなくＢ入力の各ペルの２４ビット・ビデオ部分をフレー ムメモリ１２４にストアする。すなわち、入力アドレス・ジェネレータ１２６は 、Ｂビデオ入力をオフセットし、サイズ変更し、または他のイメージ変更をする ことなくＢビデオ入力の各ペルの２４ビット・ビデオ部分をストアする。従って 、フレームメモリ１２４にストアされるＢ入力のビデオ部分はＶＣＭ ９６に与 えられるものとほぼ同じである。 Ｂビデオ入力の８ビット優先度部分はＢ優先度マスク・セレクタ１２８に与え られる。優先度ジェネレータ１３０からもＢ優先度マスク・セレクタ１２８への 入力が与えられる。優先度ジェネレータ１３０のオペレーションは以下で詳しく 説明する。Ｂ優先度マスク・セレクタ１２８は優先度ジェネレータ１３０の出力 からのある種のビットと入力優先度値を選択し、その出力を優先度ルックアップ ・テーブル（Ｐ−ＬＵＴ）１３２に送る。Ｐ−ＬＵＴ １３２は256 x 8のＲＡ Ｍ（または互換性を持つ他のサイズ）であり、そこへの８ビット入力をペル単位 でフレームメモリ１２４にストアされている８ビット優先度値に対応づけている (マッピングしている)。優先度ルックアップ・テーブル１３２の値は以下で詳し く説明するようにＶＣＭ ９６に与えられる。 Ｐ−ＬＵＴ １３２およびフレームメモリ１２４のサイズはＨＤＴＶのように 異なる最大ビデオ・ラスタ・フォーマットに合わせて、また２５６(P-LUT = 256 x 8)または６４（P-LUT = 64 x 6）のように異なる優先度スタッキング・レベル 数に合わせて、本発明を変更することなく変えることが可能である。 優先度ジェネレータ１３０はフレームメモリ１２４にストアされたＢビデオ入 力のペルの各々の優先度値を生成する。１つまたは複数のペル値キーヤ(keyer) セクション１３４はペルの各々の優先度値を２４ビット・ビデオ信号の値に従っ て出力する。すなわち、ペル値キーヤ１３４は各ペルの優先度をそのペルの入力 カラーと輝度に応じて変更する。 図示のペル値キーヤ１３４はＡ、Ｂ、およびＣと名づけた３つのセクションを もっている。各セクションは優先度の１ビットを出力し、そのビット出力はペル が規定カラー範囲内にあればディジタル”１”に等しく、ペルが規定カラー範囲 外にあればディジタル”０”に等しくなっている。例えば、ペル値キーヤＡは６ つの値Ｔ１−Ｔ６をもち、これらの値は以下で詳しく説明するように定数値がロ ードされている。ペル値キーヤＡは入力Ｂビデオ・イメージからの各ペルを検査 し、そのペルの赤部分がＴ１とＴ２の値の間にあるかどうか、緑部分がＴ３とＴ ４の値の間にあるかどうか、青部分がＴ５とＴ６の値の間にあるかどうかを判断 する。これらの条件をすべて満たしていれば、つまり、ペルの赤、緑および青の 値のすべてが、それぞれＴ１とＴ２、Ｔ３とＴ４、およびＴ５とＴ６の間にあれ ば、ペル値キーヤＡは”１”を出力する。そうでなければ、ペル値キーヤＡは” ０”を出力する。ペル値キーヤＢとペル値キーヤＣのオペレーションは同じであ る。このようにして、ペル値キーヤ・ユニット１３４のペル値キーヤの各々は入 力Ｂビデオ・ペルのカラー値に応じて優先度のビットを別々にかつ独立して出力 することができる。 ペル値キーヤ１３４は、公知のようにディジタル・コンパレータ・ハードウェ アを使用して実現することが可能である。目的によっては、３つのビデオ・チャ ネルが、従来のＹＩＱやＹＵＶフォーマットのような、ＲＢＧ（赤緑青）以外の フォーマットで情報を伝搬するようにすると便利な場合がある。このような代替 エンコード（符号化）はペル値キーヤでも使用できるので、カラー空間と必要な しきい値を変更すること以外そのオペレーションは変更されない。 優先度ジェネレータ１３０は１つまたは複数のウィンドウ生成セクション１３ ６も備えている。これらのウィンドウ生成セクション１３６の各々はウィンドウ 生成Ａ部分、ウィンドウ生成Ｂ部分、およびウィンドウ生成Ｃ部分からなってい る。これらの部分の各々は相互に独立して動作する。ウィンドウ生成部分はＢビ デオ入力のＨ、Ｖ、およびクロック（ＣＬＫ）部分を処理し、Ｂビデオ入力のペ ルの各々の水平位置と垂直位置に応じてディジタル”１”ビットまたはディジタ ル”０”ビットを出力する。例えば、ウィンドウ生成Ａ部分はＨ１、Ｈ２、Ｖ１ およびＶ２の４つの個別値をもつことができる。Ｂ入力ビデオ信号のＨ入力で示 された入力値がＨ１とＨ２の間にあり、Ｖ入力で示された入力値がＶ１とＶ２の 間にあれば、ウィンドウ生成セクション１３６のウィンドウ生成Ａ部分はディジ タル”１”ビットを出力する。そうでなければ、ウィンドウ生成Ａ部分はディジ タル”０”ビットを出力する。ウィンドウ生成部分の各々、つまり、ウィンドウ 生成Ａ部分、ウィンドウ生成Ｂ部分およびウィンドウ生成Ｃ部分は相互に独立し て動作する。ウィンドウ生成セクション１３６は公知のようにディジタル・コン パレータ・ハードウェアを使用して実現することが可能である。 各々が１ビットを出力する複数のウィンドウ・ジェネレータ１３６とペル値キ ーヤ１３４を組み合わせると、ピクチャ（画像）の異なる部分における異種カラ ーの複数のオブジェクトに対して異なる優先度を定義することができる。個々の 出力ビットは８ビット・ワードとして扱われる。このワードは数値として定義さ れ、Ｐ−ＬＵＴ １３２をアドレスするために使用される。Ｐ−ＬＵＴ １３２ のメモリ内容に応じて、任意の入力を全ビデオ・ペル・クロックレートで任意の 数値優先度出力に変換することが可能である。この変換が必要になるのは、マル チプレクサ１２２が各ペル位置で最高優先度入力だけを通過させるためである。 優先度ジェネレータ１３０に必要なことは、Ｂ入力ビデオ・ラスタ内の異なるウ ィンドウまたはオブジェクトに異なる数値優先度値を割り当てることだけである 。従って、Ｐ−ＬＵＴ １３２を使用すると、カストマはこれらの優先度の順序 づけを制御することができる。例えば、カストマがユーザ・ステーション３４〜 ３７からグラフィカル・インタラクションによって、合成シーンの中の特定のオ ブジェクトまたはウィンドウを格上げする要求を行うと、ヒューマン・インタフ ェース・プログラムとハードウェア・コントロール・プログラムはその要求をイ メージのそのエリアに付けられた数値優先度を再割り当てしたものに変換し、要 求オブジェクトの優先度を格上げするか、あるいは隠されたオブジェクトの優先 度を 格下げする。 優先度ジェネレータ１３０は、ペル値キーヤ・セクション１３４が３つの独立 ペル値キーヤ部分からなり、ウィンドウ生成セクション１３６が３つの別々で独 立のウィンドウ生成部分からなるものとして図８に示されている。ウィンドウ・ ジェネレータとペル値キーヤの数は、本発明を変更することなく変えることが可 能である。さらに、セクション１３４、１３６で使用される個別部分の数は設計 上の選択項目であり、優先度用に使用されるビットの数、必要とする独立部分の 数およびこの分野の当業者に周知の他の基準を含む、種々の機能上の要因に基づ いて選択できる。従って、本発明は、１つまたは複数のペル値キーヤ・セクショ ン１３４が３つ以外の個数の部分からなり、１つまたは複数のウィンドウ生成セ クション１３６が３つ以外の個数の独立ウィンドウ生成部分からなる場合でも実 施することができる。 優先度ジェネレータ１３０の６ビット出力は優先度マスク・セレクタ１２８に 入力され、このセレクタにはＢビデオ入力からの入力優先度信号も入力される。 従来のコントロール・レジスタ（図示せず）は、優先度マスク・セレクタ１２８ に入力された入力１４ビットのどの８ビットが優先度ルックアップ・テーブル１ ３２に入力されるかを判断している。優先度マスク・セレクタ１２８の出力は８ ビット出力として示され、同様に、優先度ルックアップ・テーブル１３２への入 力は８ビット入力として示されているが、本発明は優先度マスク・セレクタ１２ ８の出力ビットと入力ビットがいくつでも実施可能である。ビット数をいくつに するかは設計上の選択事項であり、必要とする異種優先度の数および所望の優先 度コントロール量を含む、この分野の当業者に知られているの種々の機能上の要 因に基づいてビット数を選択することができる。 上述したように、優先度ルックアップ・テーブル１３２は256 x 8 ＲＡＭであ り、これは優先度マスク・セレクタ１２８から与えられた８ビットをフレームメ モリ１２４に入れられる８ビット値に対応づけている。従って、フレームメモリ １２４にストアされた各ペルに関連づけられた優先度は優先度ルックアップ・テ ーブル１３２から得られる。 優先度マスク・ジェネレータ１２８、優先度ジェネレータ１３０および優先度 ルックアップ・テーブル１３２は一緒に動作して、Ｂビデオ入力の各セルの優先 度が得られるようにする。以下で詳しく説明するように、Ｂビデオ入力の優先度 を変更すると、種々の効果が得られるようになる。例えば、Ｂビデオ入力がクリ ップされたウィンドウで与えられる場合、ウィンドウ生成セクション１３６は、 クリップされたウィンドウの外側にあるペルは低い優先度が与えられ、クリップ されたウィンドウの内側にあるペルは相対的に高い優先度が与えられるようにセ ットすることができる。同様に、ペル値キーヤ・セクション１３４は、例えば、 青のバックグランドの前面に参加者を表示しているテレビ会議参加者のビデオ・ イメージがＢビデオ入力として与えられるように１つまたは複数のカラーをマス クアウトするために使用できるので、ペル値キーヤ・セクション１３４は、青の バックグランドに対応するカラーをもつペルに相対的に低い優先度を与え、Ｂビ デオ入力イメージの他のペルに相対的に高い優先度を与えることによって青のバ ックグランドをマスクアウトするようにセットできる。 読み取りアドレス・ジェネレータ１４０はフレームメモリ１２４からＢ入力デ ータを読み取り、そのデータを優先度駆動型マルチプレクサ１２２に渡す。Ａ入 力とＢ入力で使用されるビデオ標準の違いを埋め合わせるために、読み取りアド レス・ジェネレータ１４０はＡビデオ入力から入力されるデータのレートに対応 するレートでデータを読み取る。すなわち、読み取りアドレス・ジェネレータ１ ４０は優先度駆動型マルチプレクサ１２２への入力の同期をとって、フレームメ モリ１２４からのペルがＡビデオ入力からの対応するペルと同時に優先度駆動型 マルチプレクサ１２２に到着するようにする。 読み取りアドレス・ジェネレータ１４０はＡ入力とＢ入力の間のオフセットお よびＢビデオ入力のスケーリングおよび／またはミラーリングも処理する。Ｘと Ｙオフセットの要求量、拡大量または縮小量、およびフリッピングはすべて、以 下で詳しく説明するようにＶＣＭ ９６に渡される。 読み取りアドレス・ジェネレータ１４０はフレームメモリ１２４からのペル・ データを、Ａビデオ入力からのデータからの指定の垂直および水平オフセットで 与えることによってオフセットを処理する。例えば、Ｂビデオ・イメージをＡビ デオ入力から水平に５ペルだけシフトさせるためには、読み取りアドレス・ジェ ネレータ１４０はＡビデオ入力の左エッジの後５ペルだけ待って、Ｂビデオ入力 の左エッジを得るようにする。Ｂビデオ入力の拡大／縮小およびＢビデオ入力の フリッピングは同じように処理される。なお、ビデオ・イメージにオフセットを 与えること、ビデオ・イメージを拡大または縮小すること、およびビデオ・イメー ジをフリッピングすることはいずれも、この分野の当業者に公知であるので、こ れ以上詳しく説明することは省略する。 コンピュータ・コントロール・インタフェース１４２はＶＣＭ ９６を図５と 図６に示すコントロール・ユニット７６のような、外部コントロール・デバイス に接続している。このコンピュータ・コントロール・インタフェース１４２はア ドレス入力とデータ入力をもっている。アドレス入力は１６ビット値で示され、 データ入力は図８に８ビット値で示されている。しかし、この分野の当業者なら ば理解されるように、アドレス入力とデータ入力のビットの数は変更可能で、設 計上の選択事項であり、この分野の当業者に周知の種々の機能上の要因によって 決まるものである。 アドレス入力は、異なるＶＣＭおよび各ＶＣＭ ９６内の種々レジスタを選択 し、優先度ルックアップ・テーブル１３２をロードするために使用される。アド レス入力が異なるごとに、これらのエレメントは異なるものがロードされる。デ ータ入力は、種々レジスタとルックアップ・テーブル１３２に入力されるデータ である。従って、優先度ルックアップ・テーブル１３２に値を入力したいユーザ は、ここに示す優先度ルックアップ・テーブル１３２内の２５６ロケーションの 各々の該当アドレスを与え、ルックアップ・テーブル１３２にロードしようとす るデータを与えるだけでよい。同様に、ペル値キーヤ・セクション１３４および ／またはウィンドウ生成セクション１３６は、ペル値キーヤ１３４またはウィン ドウ生成セクション１３６のエレメントの各々の該当アドレスを与え、そのため の必要なデータを与えることによってコンピュータ・コントロール・インタフェ ース１４２からロードすることができる。そのほかは、ＶＣＭ ９６は公知のよ うにアクセスされるので、ここで詳しく説明することは省略する。 以下は、ＶＣＭ ９６に与えられる入力パラメータである。 ＨＢＭＡＸ Ｂビデオ入力の水平ライン内のピクセルの数。 ＨＰ Ａビデオ・イメージに対するＢビデオ・イメージの望みの水平位 置。 ＨＳ Ｂビデオ・イメージに適用される水平スケーリング。このスケー リングはＢビデオ・イメージがＡビデオ・イメージに対して縮小 する係数と定義されている。 ＨＦ 水平フリッピングをビデオ・イメージに適用するか否かを示すバ イナリ値。すなわち、ＨＦが１に等しいとき、イメージはミラー ・イメージが得られるようにフリッピングされる。 ＶＢＭＡＸ Ｂビデオ入力の垂直ライン内のピクセルの数。 ＶＰ Ａビデオ・イメージに対するＢビデオ・イメージの望みの垂直位 置。 ＶＳ Ｂビデオ・イメージに適用される垂直スケーリング。このスケー リングはＢビデオ・イメージが縮小する係数と定義されている。 ＶＦ イメージに垂直フリッピングを適用するか否か（つまり、イメー ジを上下反対にフリップするか否か）を示すバイナリ値。 ソフトウェア・アーキテクチャ 図９は本発明のオペレーションをサポートするソフトウェア・プロダクトを示 すビルディングブロック図である。このソフトウェアはネットワーク・ベースの マルチメディア・ブリッジを制御する汎用サービス・プラットフォームを提供し ている。上述したＡＶＢはこのサービス・プログラムによって制御できるビデオ ・ブリッジの例である。他のビデオ・ブリッジもオーディオ・ブリッジと共に、 このサービス・プログラムによって制御可能である。分散処理環境（distribute d processing environment - DPE）のリモートプロシージャコール(remote proc edure call -RPC)メカニズムはＰＰＳクライアントとＰＰＳサービス・セッショ ン・モジュール間の通信メカニズムとして使用することができる。 ＰＰＳクライアント・プログラム２００は、セッションでローカル・ユーザに よって与えられたマルチメディア・オブジェクトと、メディアの受信インスタン スのマルチメディア関連づけをトラッキング（追跡）するアプリケーション・プ ログラミング・インタフェース(application programming interface - API)を 提供している。ＰＰＳサービス・セッション・プログラム２０１はすべてのユー ザ、メディア・オブジェクト、セッションにおけるインスタンス、およびマルチ メイア・ブリッジをトラッキングする。このＰＰＳサービス・セッション・プロ グラム２０１はネットワーク接続マネージャ（これはＰＰＳの一部ではなく、ど のネットワーク管理環境でも必要とされるコア・コンポーネントである）と連絡 をとってすべての参加者の間の接続を確立する。リソース・エージェント・プロ グラム２０２は必要なハードウェアを予約し、ネットワーク・サービス・マネー ジャ２０５(ＰＰＳの一部でない)(以下で説明する)と連絡をとってビリング(請 求書発行)を行う。最後に、リソース・マネージャ・プログラム２０３はハード ウェアを構成し、フィードバックがあればそれを戻す。 ＰＰＳサービスを管理するために必要な４つのソフトウェア・コンポーネント （上述した）(つまり、ＰＰＳリソース・マネージャ２０３、ＰＰＳリソース・エ ージェント２０２、ＰＰＳサービス・セッション２０１、およびＰＰＳクライア ント・プログラム２００)のほかに、接続マネージャ(connection manager-CM)２ ０４とサービス・マネージャ２０５はＰＰＳサービスをサポートするネットワー ク管理環境の一部を構成している。ＣＭ ２０４はユーザが要求するネットワー ク接続性を確立し、維持することを担当している。サービス・マネージャ２０５ はネットワーク・サービスに対しオペレーション・サポート機能を提供すること を担当している。サービス・マネージャ２０５はサービスを構成し、ビリングを 行い、パフォーマンスをモニタし、障害をモニタし、イベントを報告する、とい ったことを行う。 ＰＰＳクライアント・プログラム ＰＰＳクライアント２００は、接続性がＣＭ ２０４を通して確立されると、 ユーザ・ステーション３４〜３７に置かれたエンドユーザ・アプリケーションと 通信する。エンドユーザ・アプリケーションとしては、例えば、マルチパーティ ・コンファレンシング、遠隔学習(distance learning)、遠隔監視、遠隔製造な どを、ユーザ・ステーション３４〜３７からグラフィカル・ユーザ・インタフェ ー ス（ＧＵＩ）を通してユーザに統合ビューを表示することによってサポートする アプリケーションがある。 クライアント・プログラム２００は２つの基本コマンド・タイプをサポートし ている。セッションのネットワーク接続性を確立または変更するためのコマンド （ＣＭ ２０４に送られるコマンド）と、ユーザに送られるプレゼンテーション の制御を目的としたコマンド（ＰＰＳサービス・セッション・マネージャ２０１ に送られる信号はそのあとリソース・エージェント２０２に送られる）である。 図１０に示すように、クライアント・プログラム２００のオブジェクト・モデル はRumbaugh オブジェクト・モデリング表記を使用している。１対多数の関連づ けは２つのクラス・ボックスをラインの多数終端上の「ドット」と結ぶラインで 表されている。継承関係は複数のラインの交点の三角形で表されている。三角形 の頂点につながるラインはスーパクラスに通じている。 ＰＰＳクライアント・プログラム２００はクライアントが表しているユーザか ら与えられるメディア・オブジェクトの記録をとっている。ユーザによって受信 されたメディア・インスタンスは、データ・インスタンス２１０、オーディオ・ インスタンス２１２、およびビデオ・インスタンス２１３のクラスによってリフ ァインされたスーパクラスである、メディア・インスタンス・クラスで表されて いる。各メディア・インスタンスは、ＰＰＳサービス・セッション・プログラム ２０１によって生成されるユニークなInstIDと、そのインスタンスがどのオブジ ェクトから生成されたものかを示すobjectIDをもっている。instIDはビデオ・イ ンスタンスの作成と制御を担当するＶＣＭ ９６〜１０７にクライアント・プロ グラム２００がアクセスできるようにするハンドルである。 ビデオ・フレーム２１５はビデオ・フレーム・アイテム２１６のセットを収め ている。空間関連づけ（マルチメディア関連づけの一種）はビデオ・インスタン スまたは「もっと小さな」空間関連づけから作ることができる。ビデオ・フレー ム２１５が必要になるのは、ユーザが受信しているビデオ・ストリームからどの ビデオ・インスタンスを選択してプレゼンテーション・コントロール・アクショ ンをとったかを判断するためである。ビデオ・フレーム２１５はビデオ・ディス プレイ・ウィンドウで選択されたロケーションを特定のビデオ・インスタンスに 対応づけている(マッピング)。これが必要なのは、特定のイメージに対するアク ション、例えば、ユーザＣのインスタンスのサイズ変更を定義するプレゼンテー ション・コントロール・シグナリングをサポートするためである。ＰＰＳクライ アント・プログラム２００はプレゼンテーション・コントロール信号をリソース・ エージェント２０２に送信し、選択したビデオ・インスタンス（そのmedia_inst ID に基づく）がユーザが望む新しい方法で表示されるようにする。 空間関連づけに対して、例えば、関連づけの移動などのアクションをとると、 は複数のネットワーク信号が送信される。例えば、パンニング・アクションがユ ーザによって要求されると、クライアント・プログラム２００は別々の相互に関 連づけられたプレゼンテーション・コントロール信号を、ユーザのプレゼンテー ションの変更の影響を受けるＶＣＭ ９６〜１０７の各々に送信する。２つのビ デオ・イメージが１つに関連づけられていて、パン要求がユーザによって行われ たときは、２つのイメージのうちユーザが受信するビューはシフトされる。この 変更によって影響を受けたＶＣＭ ９６〜１０７の各々はその表示イメージの起 点がシフトされることになる。 サービス・セッション 図１１には、ＰＰＳサービス・セッション・プログラム２０１のオブジェクト・ モデルが示されている。ＰＰＳサービス・セッションの基底クラス（base class ）はＰＰＳクライアント２００と関連づけられたものとは異なる、独自のメディ ア・オブジェクト・クラス２００と、メディア・オブジェクト・インスタンス２ ２１、ブリッジ２２２およびクライアント２２３とをもっている。どのビデオ・ ブリッジからユーザが出力を受信しているかといったクライアント情報とそのcl ientIDは各クライアント・オブジェクト２２３にストアされている。 メディア・オブジェクト・クラス２２０はそのセッションの参加者が利用でき る、すべてのマルチメディア・オブジェクトを記録しておくために使用される。 これらのオブジェクトの属性としては、それがどのタイプのオブジェクトである か(オーディオ、ビデオ、データ)、オブジェクトの所有者、オブジェクトのアク セスリストなどがある。オブジェクトの所有者はオブジェクトのアクセスリスト のどのユーザを追加できるかを制御する。チェア(Chair)２２４も、オブジェク ト所有者が設定したアクセスリストを制御できる(所有者のセットアップをオー バライドする)。メディア関連づけ(Media Assoc)クラス２２５は、セッション・ レベル関連づけのメディア・オブジェクト相互間の関連づけ関係を記録している 。 メディア・オブジェクト・アクセス・コントロールによると、ユーザまたは他 の権限をもつ個人は、メディア・ストリーム上で自分が所有するメディア・オブ ジェクトをどのユーザに受信させるかをメディア・オブジェクト・ベースで判断 することができる。ユーザが自分のサイトから送信するオブジェクトはユーザが 所有するメディア・オブジェクトであるのが代表的である。しかし、一般的ケー スでは、メディア・オブジェクトを所有することは、ユーザがそのメディア・オ ブジェクトをだれにアクセスさせるかを制御できることを意味する。例えば、チ ェア・セッションでは、セッションのチェアがオブジェクトへのアクセス特権を 別のロケーションから制御できるようになっている。例えば、教師は生徒同士の アクセスをテスト期間中に制御することができる。 ＰＰＳサービス・セッション２０１は各メディア・オブジェクトのアクセス許 可をトラッキング（追跡）することを担当している。メディア・オブジェクト・ クラス２２０のaccess_listパラメータはユーザのアクセス許可を記録する。サ ービス・セッション・プログラムがユーザにメディア・オブジェクトへのアクセ ス権があることを確認すると、そのユーザはそのメディア・オブジェクトのイン スタンスを受信し、そのインスタンスのステート（状態）をＰＰＳクライアント に反映するようにメディア・オブジェクト・インスタンス２２１が作成される。メ ディア・オブジェクトへのアクセス許可が変更されると(例えば、ユーザはサイ ドチャット(side-chat)を始めるために他のユーザが自分のイメージを見るのを 禁止したい場合)、そのメディア・オブジェクトを受信することが制限されたユ ーザにはその変更が通知され、メディア・オブジェクトへのアクセスが打ち切ら れることになる。例えば、メディア・オブジェクトのインスタンスは除去される 。 ブリッジ・クラス２２２は、このセッションの参加者が使用するために予約さ れていたリソースをトラッキングするために使用される。セッションが作成され るとき、最小限のリソース・セットがセッションの参加者が使用するために予約 される場合がある(例えば、ユーザ当たりまたはそのセッション用の複数のビデ オ・インスタンス)。例えば、セッションの参加者は利用できるリソースが十分 にあって、各ユーザが（ビデオの場合）他の参加者全員を見ることができるかど うかを確かめたい場合がある。リソースが予約されていても、セッションの存続 期間にいつでもすべてが使用できるとは限らない。ブリッジ・クラス２２２はネ ットワーク・アドレス情報も収めているので、サービス・セッション・マネージ ャは正しい信号を正しいブリッジに送信することができる。 リソース管理 リソース・エージェント２０２は、ネットワーク・リソースの管理対象オブジェ クトをネットワークに対してベンダから独立した方法で表現するソフトウェア・ コンポーネントである。管理対象オブジェクトはリソースのステートと機能を表 している。一般的に、ネットワークでサービスを提供するどのリソースも、２種 類のインタフェースをもっている。サービスのクライアントで使用されるサービ ス・インタフェースと、サービスの機能を管理、制御するために管理側システム によって使用される管理インタフェースである。 ＰＰＳリソース・エージェント２０２は２つの管理インタフェースと１つのサ ービス・インタフェースをサポートしている。第１のインタフェースはネットワ ーク管理ソフトウェアとのインタフェースとなるもので、リソースのビューをネ ットワークに提示して、ネットワーク接続管理ソフトウェアがトランスポートを そのリソースに接続できるようにする。第２のインタフェースはサービス管理（ 例えば、オペレーションのサポート）機能をサポートしている。最後のインタフ ェースはセッション期間中にリソースを制御するために必要なサービス固有のシ グナリング（プレゼンテーション・コントロール・シグナリング）をサポートし ている(ＰＰＳサービス・セッション・マネージャ２０１のインタフェース)。Ｐ ＰＳリソース・エージェント２０２はＣＭ ２０４、ＰＰＳサービス・セッション ・マネージャ２０１、およびネットワークのサービス管理マネージャ２０５から そこに送られてきたコマンドを受信し、これらのコマンドを社内所有コマンド (internal proprietary command)に変換する。各リソース・エージェントのイン タフェースがサポートするコマンドとプロトコルは異なる場合がある。例えば、 サービス・セッション・マネージャのプレゼンテーション・コントロール・シグ ナリングをサポートするインタフェースはＲＰＣプロトコルをサポートすること ができ、サービス管理インタフェースはＣＭＩＳＥまたはＳＮＭＰインタフェー スをサポートすることができる。ビデオ・ブリッジ・マネージャ（下述）はベン ダ固有の所有コマンドをリソース・エージェント２０２から受信し、リソースの 内部構成を担当する。 図１２には、ビデオ・リソース管理サブシステムのオブジェクト・モデルが示 されている。オーディオおよびデータ・リソース・マネージャにも類似のオブジェ クト・モデル（図示せず）が存在する。ビデオ・ブリッジはネットワークから見 たとき、ある種の機能（サポートされるメディア・タイプ、バンド幅、QoSなど ）をもつ入力ポートと出力ポートがあるブラックボックスとして見える。管理イ ンフォ・ベース（Management Info Base - MIB）２３１はＡＶＢ ３２ａのステ ートと機能をネットワーク管理ソフトウェアが理解できる形式で反映している管 理対象オブジェクトを収めている。 ビデオ・ブリッジ・マネージャ（Video Bridge Manager-VBM）２３０とリソー ス・エージェント２０２との間の通信は企業所有コマンドを通して行われる。例 えば、ＡＭＢ ３２に送られるコマンドは、ＡＭＢハードウェアと通信するため に使用されるコンピュータ・インタフェースのプロコトルに準拠するコマンド言 語を使用している。特定のＶＣＭ ９６〜１０７と通信するために、ハードウェ アＶＣＭに対応するＶＣＭオブジェクト２３２は、ＶＢＭ ２３０から受け取っ たコマンドを、そのコマンドの宛先であるＶＣＭタイプのハードウェア固有の命 令に変換する。各ＶＣＭのステート(ウィンドウ／クロマキー情報、優先度情報 など)、例えば、各ＶＣＭのレジスタに格納された値はＶＣＭオブジェクト２３ ２によってトラッキングされる。 ＶＢＭ ２３０（図１２）はブリッジの内部構成も担当している。ＶＢＭは正 しいＶＣＭ ９６〜１０７を１つに接続してＶＣＣに入れ(対応するＶＣＣオブ ジェクト２３３と一緒に)、ＶＣＣをユーザの出力ポート２３４に接続する。新 し いセッションが要求されると、ＶＣＭとポート・オブジェクト２３２、２３５を 調べて、ＡＶＢ ３２ａに要求セッションに必要なリソースがあるかどうかが確 かめられる。State変数がＶＣＭオブジェクト２３２またはポート・オブジェク ト２３５で使用可能(Available)にセットされていれば、これはポートまたはＶ ＣＭが新しいセッションで使用できることを意味する。このStateが予約(Reserv ed)または使用中（In-Use）にセットされていれば、ポートまたはＶＣＭは使用 不能である。 ＶＣＭエージェント・サブシステム２０６（図９）はＶＣＭのハードウェアＶ ＣＭまたはソフトウェア・エミュレータを制御するための、ＶＢＭ ２３０との シングル・インタフェースを提供している。ＶＣＭエージェント・サブシステム ２０６はインタフェース定義とＶＣＭの基本的機能を提供するＶＣＭ基底クラス からなっている。ＶＣＭハードウェアは書き込みアクセスだけを行うので、ハー ドウェア内の各レジスタのステートをストアし、ＶＢＭ ２３０のために入出力 を行うのはＶＣＭエージェント２０６が担当している。 ＶＣＭ基底クラスには、softVCM ２０７とhardVCM ２０８の２つの派生クラス がある。これらのクラスのインタフェースが異なるのは、コンストラクタだけで ある。softVCM ２０７はコマンドをsoftVCMに書くために使用するファイル名を 表すストリングを受け取る。hardVCM ２０８はハードウェアのベース・アドレス であるアドレス値を受け取る。この設計によれば、ハードウェア・インプリメン テーションを使用しているか、ソフトウェア・インプリメンテーションを使用し ているかに関係なく、タイプＶＣＭのポインタを使用することができる。 セッション初期化 図１３はＡＶＢ ３２ａとのセッションを初期化するステップを示している。 オーディオとデータ・ブリッジの場合も、類似のステップが必要である。初期化 は接続マネージャのインスタンス、または該当のネットワーク管理ソフトウェア がユーザの自発的セッション要求または予約マネージャ２０３からの要求によっ て作成されたとき開始される。そのあと、セッションは以下のステップで確立さ れる。 第１に、ＰＰＳクライアント・プログラム２００はＣＭ ２０４のインタフェ ースを使用して要求セッションをサポートするために必要なリソースが使用可能 であるかどうかを判断する。ＣＭ ２０４はビデオ・リソース・エージェント２ ０２にリソースを要求し、これを受けてエージェント２０２はリソース・マネー ジャ２０３のＶＢＭ ２３０と通信して必要なリソースが使用可能であるかどう かを判断する。 第二に、ＣＭ ２０４は参加者の間で必要なセッション・セットアップ交渉を 処理する。ユーザと接続マネージャとの間で交渉される属性のいくつかを挙げる と、バンド幅アクセス、サービス品質、ビデオ・レート、ビデオ品質、オーディ オ品質、ＡＭＢ ３２に送られるセッション・オブジェクト(ユーザはオーディ オ・データだけを伝送することを要求されても、ビデオも送信したい場合がある) 、受け取ろうとするセッション・オブジェクト（ユーザはオーディオ・データだ けを受け取ることに制限されていても、ビデオ・オブジェクトも受け取りたい場 合がある）などがある。 第三に、セッション交渉が完了すると、各ユーザとのマルチメディア接続がネ ットワーク接続マネージャによって確立される。この中には、各ユーザのカメラ をビデオ・ブリッジに接続すること、各ユーザのビデオ・ブリッジの指定出力ポ ートをユーザの端末に接続することが含まれる。 第四に、接続マネージャはセッションのトランスポートがセットアップされた ことをＰＰＳクライアント・プログラムに通知する。ＰＰＳクライアント・プロ グラムは次に、ＰＰＳサービス・セッション・マネージャを作成する。ＰＰＳク ライアント・プログラムはセッションに係りをもつリソースの初期構成情報をＰ ＰＳサービス・セッション・マネージャに引き渡す。この中には、どのユーザ・ カメラがビデオ・ブリッジのどの入力ポートに接続されているか、どの出力が各 ユーザの結合ビデオ・ストリームを担当しているか、に関する情報がある。 第五に、ＰＰＳサービス・セッション・マネージャはＡＶＢ ３２ａのどの部 分が、リソース・エージェントのサービス・インタフェースを使用して現行セッ ションによって使用中であるかを示すように、ポートとＶＣＭオブジェクト（図 １２）をブリッジ・マネージャ（または複数の）に更新させる。 第六に、セッション参加者のクライアント・オブジェクト２２３がサービス・ セッションでインスタンス生成（インスタンス化）され、次に各ＶＣＭのＶＣＭ ステート情報がリソース・マネージャでインスタンス生成され初期化される。 セッション・オペレーション 通信セッションの期間、ユーザはイメージにアクセスし、イメージ受信方法を 変更し、メディア・オブジェクトを追加、除去する。このプロセスはクライアン ト・プログラム（ＡＰＩ）２００が上述した種々のソフトウェア・コンポーネン トとやりとりすることにより行われる。ＰＰＳクライアント・プログラムはアプ リケーション開発者がＰＰＳプログラムにアクセスできるようにするＡＰＩをも っている。アプリケーション開発者はネットワーク接続マネージャの詳細を知っ ている必要もなければ、新しいアプリケーションをサポートするためにＰＰＳネ ットワーク・ベースのソフトウェアにどのような変更を加える必要もない。この ＡＰＩオペレーションの擬似コード・リストは付録Ａに示されている。 ユーザがビデオ・オブジェクトのインスタンスを受信するためには、ユーザは まずオブジェクトへのアクセス許可を要求しなければならない(ＡＰＩコマンド のaccess_obj_request)。ユーザがビデオ・オブジェクトのインスタンスを受信 する許可をもっていれば、ユーザはそのインスタンスの初期ロケーションとサイ ズを指定し、ＡＰＩコマンドreceive_video_instを使用する。このプロセスの詳 細はユーザから見えないようにし、単一の受信イメージ・メニュー・アイテムを 起動すると、access_obj_requestＡＰＩコマンドがコールされ、そのあと受信ビ デオ・インスタンス・コマンドがコールされるようにすることが好ましい。 初期ロケーションとサイズはアプリケーションによって自動的に与えることが できる。インスタンスの初期ロケーションとサイズはクライアント・ビデオ・イ ンスタンス２１３（図１０）にストアされるので、結合ビデオ・ストリーム内の 各インスタンスのロケーション、サイズ、およびスタッキング順序をトラッキン グすることができる。これが必要になるのは、ユーザに送られるビデオ・ストリ ームがユーザが受信するイメージを結合したものであり、各ユニーク・イメージ がそのコンポジット・ビデオ・ストリーム内のどこにあるかを判断する方法がな い ためである。オーディオ・インスタンスも同じように受信される。 プレゼンテーション・コントロール・コマンド(移動、サイズ変更、クロマキー 、プッシュ、ポップ、ボリューム変更、パン、バス、トレブルなど)を実行する と、該当のクライアント・インスタンスが更新され、メッセージがサービス・セッ ションに送られ、そこからメッセージは該当のリソース・マネージャ（オーディ オまたはビデオ・ブリッジ・マネージャ）に渡される。アプリケーションはコマ ンドを受け取らせるインスタンスの名前を指定しなければならない。 get_instances ＡＰＩコマンドを使用すると、アプリケーション開発者はメデ ィア・インスタンスの属性の現在の設定値を判断することができる。このため、 各アプリケーションはこの情報をトラッキングする必要がなくなる。ユーザが受 信するオーディオ・インスタンスのボリューム属性を変更したい場合は、現在の 設定値がどうなっているかを知っている必要がある。 ビデオ・インスタンスでは、ビデオ・クリックとドラッグ・インタフェースの サポートを向上するために、選択をベースとするプレゼンテーション・コントロ ール・コマンドが用意されている。ユーザは、まず、プレゼンテーション・コン トロール・コマンドを実行しようとする対象のインスタンスがビデオ・ウィンド ウ内に置かれているロケーションをチェックする。API pick_items()コマンドが 起動され、指定したロケーションに置かれているインスタンスのリストが戻され る。インスタンスはオーバラップできるので、これをユーザに表示する最善の方 法を判断することはアプリケーション開発者に任されている(例えば、各インス タンスを循環してそのロケーションでハイライトすることによって、インスタン スのリストとして表示するといったように)。ユーザが希望のインスタンスを選 択すると、API select_itemコマンドが起動され、そのインスタンスが選択され る。インスタンスが選択された後、該当のＡＰＩコマンド、例えば、move_selec tionを指定すると、その選択で異なるプレゼンテーション・コントロール・コマ ンドを利用することができる。 複数のインスタンスを選択してそれらを１つのグループにまとめることができ る。１つのグループにまとめられたビデオ・インスタンスでは、そのグループは シングル・インスタンスであるものとして扱われる。すべてのプレゼンテーショ ン・コントロール・コマンドは、それが個別インスタンスであるかのようにグルー プに対して実行することができる。選択コマンドがあるロケーションでアプリケ ーションから出されたとき、そのロケーションのビデオ・インスタンスがグルー プ内にあれば、そのグループ情報がアプリケーションに戻される。個別インスタ ンス情報は、グループが分解されるまではアプリケーションが再び使用すること ができない。プレゼンテーション・コマンドがグループに対して出されたときは 、ＰＰＳクライアント・プログラムはグループをばらばらにし、個別コマンドを 各インスタンスの生成を担当するビデオ・ブリッジ（ＶＣＭ）のコンポーネント に送付する。言い換えれば、個別プレゼンテーション・コマンド信号はグループ 内の各インスタンスごとにその生成を担当するＶＣＭに送られる。 ユーザがインスタンスを受け取ることを望まなくなったときは、drop_media_i nstanceコマンドが出され、ビデオ・インスタンス・オブジェクトがクライアン ト・プログラムから削除される。 セッションに寄与されているオブジェクトが切り離されたときは、そのオブジ ェクトのすべてのインスタンスも一緒に除去する必要がある。ビデオ／オーディ オ・インスタンスはそれを受け取っていたユーザの各々に送信されることを中止 する。 ユーザが所有しているオブジェクトへのアクセス許可を変更したときは、その オブジェクトへのアクセスを許可されなくなったユーザはそのオブジェクトの受 信していたインスタンスが除去されることになる。サービス・セッションはクラ イアント・プログラムをそれに応じて更新する。プログラムは、オブジェクトが セッションから除去されたかどうか、あるいはそのユーザのアクセス権が変更さ れたかどうかをチェックして確かめる。 マルチメディア・オブジェクト関連づけの制御 本発明の顕著な利点は、マルチメディア・オブジェクト関連づけがセッション ・レベルとユーザ・レベルで行われることである。ビデオ・イメージと他のマル チメディア・オブジェクトとの関連づけをユーザが制御すると、異種マルチメデ ィア・ストリームを１つのグループにまとめて望みのプレゼンテーション目標を 達 成することができる。ユーザは異種ビデオ・イメージを一緒に関連づけてビデオ シーンを構成したい場合がある。この方法を使用すると、カメラ・アレイから送 信されたイメージを関連づけて、パノラマビューを得たり、３次元投影図を得た り、あるいはユーザがテレビ会議の他のユーザを１つのグループにまとめたりす ることができる。 テレビ会議ユーザは、結合ビデオシーンを左右にパンするだけで他の会議参加 者のサブセットを見て、異なる会議参加者のイメージに都合よくアクセスするこ とができる。例えば、図１４に示すように、関連づけられているオブジェクトは パン可能なシーンとしてユーザに提示されている。３つのカメラ・アレイからの イメージは拡大したシングル・イメージ（複合ビュー）が得られるように一列に 並べられる。グループのロケーションはグループ内のビデオ・インスタンスのロ ケーションに影響する。グループが移動すると、グループ内のビデオ・インスタ ンスはそのロケーションが新しいグループ・ロケーションから事前設定量だけオ フセットされる。 本発明のマルチメディア・オブジェクト関連づけソフトウェアは異種タイプの オブジェクトを一緒に関連づけることも可能である。オーディオ・オブジェクト とビデオ・オブジェクトを一緒に関連づけると、いくつかのプレゼンテーション 目標を達成することができる。例えば、オーディオ・オブジェクトのボリューム はビデオ・オブジェクトのサイズと関連づけることができる。ビデオ・オブジェ クトのサイズを大きくすると、関連づけられたオーディオ・オブジェクトのボリ ュームは増加する。ビデオ・オブジェクトのサイズを小さくすると、オーディオ ・オブジェクトのボリュームは減少する。ステレオ・オーディオの２つのストリ ームはディスプレイ上のビデオ・オブジェクトのロケーションと関連づけること ができる。ビデオ・オブジェクトがスクリーンの右に移動されると、オーディオ の右チャネルは音が大きくなり、左チャネルは音が小さくなる。 メディア関連づけはメディア・オブジェクトまたは同種または異種メディアの インスタンスのグループ相互間の関係を定義し、オブジェクト・グループを作成 するものである。メディア関連づけは関連づけ内のインスタンス／オブジェクト の属性の一部または全部を制御するために使用される属性をもっている。メディ ア関連づけの属性が変更されると、関連づけ内のメディア・インスタンス／オブ ジェクトの特定属性の値が変更される。 関連づけの中には、各インスタンス属性値のオフセット、例えば、インスタン ス・ロケーションがグループ・ロケーションから離れているオフセットを必要と するものがある。これが必要になるのは、実際のメディア・インスタンスの属性 値がその属性の絶対値、例えば、スクリーン上のビデオ・インスタンスのロケー ションを反映しているためである。 図１５にはマルチメディア関連づけのオブジェクト・モデルが示されている。 MediaAssociation（メディア関連づけ）オブジェクト３０１はMedia Instance/O bj（メディア・インスタンス／オブジェクト）オブジェクト３０２と１対多数の 関係（多数終端上の「ドット」でオブジェクト間を結ぶライン）をもっている。つ まり、マルチメディア関連づけの中には１つまたは複数のメディア・インスタン スがある。メディア関連づけは１つまたは複数のAssoc属性３０３をももってい る。他方、Assoc属性の各々は関連づけ内の各インスタンスの１つまたは複数の 属性に影響を及ぼす。影響を受ける各属性(Video Inst Attrib ３０７、Audio I nst Attrib ３０８、Data Inst Attrib３０９)は関連づけの中で Assoc Inst 属性（Assoc Vid Inst Attrib ３０４、Assoc Aud Inst Attrib ３０５、Assoc Data Inst Attrib３０６）によって表されている。 Assoc Inst属性はInst属性(Video Inst ３１０、Audio Inst３１１、Data In st３１２)と関連づけとの関係を定義している。ビデオ・インスタンス(Video Ins t ３１０)のロケーション属性は、それがグループ・ロケーションから離れてい るオフセットが関連づけの中で表されている必要がある。Assoc Vid Inst Attri b ３０４はこの目的のために利用される。各Assoc Inst Attribは１つのInst At tribに影響を及ぼす(１対１の関係)。ロケーションの場合のVideo Inst Attrib ３０７はVideo Inst ３１０が端末から表示されるときの実際のロケーションを 反映している。これはビデオ・インスタンスの絶対ロケーションであり、ロケー ションのAssoc Vid Inst Attrib ３０４によって反映される、グループ・ロケー ションに対する相対ロケーションではない。 ユーザ・レベル関連づけの例 図１６と図１７に示すオブジェクト・モデルは図１５に示す一般的オブジェク ト・モデルのサブセットである、具体的ユーザ・レベル関連づけの例を示してい る。一般的に、インスタンスで実行できるオペレーションはすべて関連づけで実 行することができる。ビデオ・インスタンス関連づけでは、ユーザは関連づけを 移動し、スケーリングし、優先順序付けし、クロマキーイングし、ウィンドウ操 作し、フリップすることができる。図１６と図１７には、図１５の一般的オブジ ェクト・モデルのコンポーネントのうち、この例に関係するものだけが示されて いる。なお、すべての例を実際に実現するとき同じソフトウェアが使用されるこ とは当然である。 例１ 最初の例は、ユーザがいくつかのビデオ・インスタンスをビデオ・グループに まとめて、すべてのインスタンスをシーンとして移動し、インスタンスをグルー プでスケーリングする場合のケースである(空間関連づけと呼ばれる)。この例で のオブジェクト・モデルは図１６に示されている。このメディア関連づけはビデ オ・メディア・インスタンスだけを含んでいる。関連づけられるメディア属性( メディア関連づけ属性)はビデオ・インスタンスのスケールとロケーションであ る(Assoc Scale Attrib３１３/Assoc Vid Inst Scale Attrib ３１５およびAsso c Loc Attrib３１４/Assoc Vid Inst Loc Attrib ３１６)。 この例では、関連づけのロケーション属性が変更されると、ビデオ・インスタ ンスのロケーション属性（Video Inst Loc Attrib ３１７）がその変更量だけ関 連づけのロケーションに変更される。各ビデオ・インスタンスは関連づけロケー ション属性をもち、これはそのインスタンス・ロケーションがグループのロケー ションから離れているオフセットを記録している。ビデオ・インスタンス関連づ けロケーション属性のメンバ関数である、update_attribは起動されると、その オフセットをグループ・ロケーションに加えると同時に、ビデオ・インスタンス・ ロケーション属性（Video Inst Loc Attrib ３１７）のchange_attrib メンバ関 数を起動する。ビデオ・インスタンス（Video Inst３１０）が実際にビデオ・フ レーム内に置かれているロケーションは、ビデオ・インスタンス・ロケーション 属性３１７が変更されたとき変更される。 メディア関連づけ３０１のAssocスケール属性３１３が変更されると、ビデオ ・インスタンス３１０の各々のロケーションとスケールが変更される。 グループのスケールが大きくなると、ビデオ・インスタンスの各々のスケール は同じパーセントだけ大きくなる。各インスタンスのロケーション・オフセット も、グループ・スケールの変更と同じパーセントだけ大きくなる。このケースで のメディア関連づけスケール属性３１３はビデオ・インスタンスのスケールだけ でなく、グループ起点からの各インスタンスのロケーション・オフセット属性の 値も変更する。ビデオ・インスタンス・スケール属性３１８はロケーション属性 ３１７で要求されるような、関連づけ「オフセット属性」を必要としない。関連 づけスケール属性３１３のメンバ関数update_attrib()は、グループ・スケール が変更されたのと同じパーセントだけインスタンス・スケール属性３１８を変更 させる。 この例を反映する図１６のオブジェクト・モデルは一般的モデル(図１５))の オブジェクト・モデル・コンポーネントのうち、この例で使用されるものだけを 示している。Assoc Attribオブジェクトは別々に表されている。一般的モデルで は、Assoc Attribオブジェクトはメディア関連づけ３０１との１対多数の関係で 表されている。 例２ 第２の例は、ユーザがビデオ・インスタンスをオーディオ・インスタンスと関 連づけて、ビデオ・インスタンス・グループのスケールがサイズ変更されたとき、 オーディオ・ボリュームも変更されるようにし、ビデオ・インスタンスのロケー ションが変わったとき、オーディオのボリュームとパン・ロケーションも変わる ようにするケースである。この関連づけのオブジェクト・モデルは図１７に示さ れている。このケースでは、ビデオ・インスタンスのスケールが大きくなる、オ ーディオ・ボリュームも大きくなり、スケールが小さくなると、オーディオ・ボリ ュームも小さくなる。 さらに、グループ内のビデオ・インスタンスのロケーションが変わると、ステ レオパン・ボリュームがオーディオ・インスタンス側で変化し、総ボリュームが オーディオ・インスタンス側で変化する。ビデオ・インスタンスがスクリーンの 中央に移動されると、ボリュームは音が大きくなり、そのインスタンスがスクリ ーンのエッジに移動されるか、スクリーンの外に出ると、オーディオ・インスタ ンス・ボリュームは音がソフトになる。 メディア関連づけ３０１は関連づけ内のビデオ・インスタンスの境界ボックス に対応するスケール属性３１８をもっている。メディア関連づけスケールが変更 されると、これは第１の例と同じようにビデオ・インスタンスのスケールに影響 を及ぼす。メディア関連づけオーディオ・ボリュームレベル属性(Audio Inst Vo lAtt)３２１ももっている。 各オーディオ・インスタンス・ボリューム属性３２１はボリューム「オフセッ ト」をもち、これはグループのオーディオ・ボリューム属性に加算（減算）され 、各オーディオ・インスタンスのオーディオ・ボリュームの値が得られる。関連 グループのオーディオ・ボリュームが変更されると、update_volメンバ関数が起 動され、該当のAssoc Vol Inst Attオブジェクト３２０のupdate_attrib(vol) メンバ関数を起動することによってすべての該当オーディオ・インスタンス・ボ リュームを変更する。 ビデオ・グループのスケールが変更されると、関連づけ内の各インスタンスの オーディオ・ボリュームはビデオ・スケール属性が変更されたのと同じパーセン トだけ変更される。これを行うために各Assoc Vol Inst Attオブジェクト３２０ のupdate_attrib(scale)メンバ関数が起動される。オーディオ・インスタンス・ ボリュームレベルはあらかじめ決めたパーセントだけ変更される。Assoc Vol In st Attオブジェクト３２０はビデオ・ロケーション属性が変更されたときも同じ ように変更される。 セッション・レベルのオブジェクト関連づけ セッション・レベルの関連づけの主な用途は同期関連づけとプレゼンテーショ ン関連づけである。同期関連づけの指定はマルチメディア関連づけアーキテク チャによって与えられる。許容配送オフセットも指定される。この情報は端末機 器またはネットワークによって使用され(バッファリング機能があるものと想定) メディア・オブジェクトが同期して配送されることを保証する。 プレゼンテーション関連づけを行うと、グループ内のすべてのビデオ・インス タンスは、グループのあるメンバが選択されたときフォアグラウンドにポップす る。このような関連づけはセッション・レベルで、多分ユーザによって作成され るのが通常である。このグループ化情報は関心のあるユーザのクライアント・プ ログラムに渡される。 メディア関連づけアーキテクチャによってサポートされるメディア関連づけの 可能性はほかにも多数ある。同期化、役割別ビデオ・グループ化(管理者、講師 など)、ピクチャ(vu-graphs)などである。 ＰＰＳクライアント・プログラムおよびセッション・マネージャはどちらも、 関連づけを維持する同じソフトウェアを含んでいる。セッションはオブジェクト 関連づけを維持し、各クライアント・プログラムはそのユーザのためにインスタ ンス関連づけを制御する。 基本オペレーションの特徴 プレゼンテーション・コントロール 本発明のユーザはビュー・ウィンドウ４８内のユーザ独自の好みのビューを使 いやすい（クリック・アンド・ドラッグ）ヒューマン・インタフェースを通して 配置することができる。ユーザは見たいピクチャを選んで、それを好きなように 配置することができる。ユーザはピクチャを望みの位置に移動し、ピクチャを望 みのスケールにスケーリングすることができる。また、ユーザはピクチャを水平 方向および／または垂直方向にフリップすることができる。 ユーザはウィンドウ・エリアおよび／またはクロマキーを指定することでピク チャの部分をカットアウトすることもできる。例えば、図１８はいくつかのウィ ンドウとキー・ジェネレータのアクションを組み合わせて抜き出すべきイメージ の不規則なエリアを定義する例を示している。図示の例では、３つの矩形ウィン ドウ・ジェネレータ１３６（図８）はウィンドウＡ、ＢおよびＣを定義し、その ウィンドウ内の選択をペル値キーヤ１３４の設定値によってさらに変更できるよ うにしている。 ウィンドウＡは最終的シーンから除去すべきエリアのラフなカットである。ウ ィンドウＡの下部エッジの正確なロケーションを不要にするために、ウィンドウ Ｂは男性のスーツのカラーだけが除去される領域をおおざっぱに定義するために 使用されている。マップと女性の姿の間の不規則なボーダは矩形ウィンドウでは 定義できないので、ウィンドウＣは別の全体エリアを定義し、その中でマップの 特定のカラーがキーアウトされ、分離を完了している。 ＡＶＢ ３２ａのビデオ部分はマルチレベル優先度オーバラップ・パラダイム を使用して可視性をピクセル単位で判断する。従って、出力ビューは相互にオー バラップすることを続け、相対的移動が２人の体または頭をスクリーン上で接触 させるようになると、優先度の高い方のイメージは自然に他方の前を通過するよ うになる。各ユーザはディスプレイ・ウィンドウに追加される各オブジェクトの サイズ、形状、および向き（向き合う方向）を制御できるので、異なるフォーマ ットは自然の形で好ましい全体ピクチャにブレンドされることになる。 オブジェクト関連づけ ビデオ・イメージと他のマルチメディア・オブジェクトの関連づけをユーザが 制御すると、異種マルチメディア・ストリームの同期をとってプレゼンテーショ ン目標を達成することができる。メディア・ストリームを相互に関連づけると、 ユーザはコンポジットまたはオブジェクト・グループと考えられるものを作成す ることができる。これらのオブジェクトはアクセスと配置がしやすいように１つ のグループにまとめることができる。 このメカニズムを使用すると、異種マルチメディア・ストリームの配送を同期 化してある種のプレゼンテーション目標を達成することができる。例えば、ピク チャ・スライド・ショーはオーディオ・サーバからの記録されたプレゼンテーショ ンと同期をとることができる。マルチメディア・プロバイダは異なるサーバから の情報を同期化することを望んでいるが、これはプロバイダが必要な情報をすべ てストアするだけの記憶容量をもっていないか、ある種の情報の著作権をもって いないことがあるためである。また、オブジェクト関連づけを使用すると、ビデ オ・カメラのパン移動をシミュレートするようにパン効果を生成し、オーディオ ・インスタンスとビデオ・インスタンスを関連づけることができる。 アクセス・コントロール アクセス・コントロール機能を使用すると、本発明の各ユーザは自分が「所有」 するメディア・オブジェクトをだれにアクセスさせるかを指定することができる 。サイドチャット(side-chat)は、メディア・オブジェクトの所有者がメディア ・オブジェクトへのアクセス許可を変更できるようにすることによりサポートさ れる。サイドチャットの参加者は自分のオーディオおよびビデオ・メディア・オ ブジェクトを他のどのユーザにアクセスさせるかを指定することができ、サイド チャットから除外された参加者はそのサイドチャットにプライベートであるメデ ィア・オブジェクトにアクセスすることが禁止されることになる。 本発明の上述した実施例は、上述した教示事項に照らしてこの分野の当業者に 自明であるように、種々態様に改良および変更することが可能である。従って、 添付の請求の範囲およびその均等の範囲内において、具体的に上述してきた以外 の方法で本発明を実施することが可能であることはもちろんである。

───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.⁶ 識別記号 ＦＩ Ｈ０４Ｎ 7/15 ６３０ Ｈ０４Ｌ 11/20 １０２Ｚ 【要約の続き】 更することもできる。

Claims (1)

1. 【特許請求の範囲】 １． メディア信号ストリームのプレゼンテーションを制御する方法であって 、 複数のメディア信号ストリームであって、該ストリームの各々は複数のメデ ィア・インスタンスを含み、各メディア・インスタンスは該メディア・ストリーム によって表された全体情報の個々の部分であるものを提供するステップと、 異なるメディア信号ストリームからの複数のインスタンスを個々のメディア ・インスタンス・グループに関連づけるステップと、 前記個々のメディア・インスタンス・グループを、それがメディア信号スト リームであるかのように操作するステップとを具えたことを特徴とする方法。 ２． 請求項１に記載のメディア信号ストリームのプレゼンテーションを制御 する方法において、前記メディア・インスタンスはビデオ・インスタンスを有し、 前記方法は前記ビデオ・インスタンスをビデオ・ディスプレイ・デバイスから表 示するステップをさらに具えたことを特徴とする方法。 ３． 請求項２に記載のメディア信号ストリームのプレゼンテーションを制御 する方法において、前記メディア・インスタンスは前記ビデオ・インスタンスの 他にオーディオ・インスタンスを有することを特徴とする方法。 ４． ビュワがマルチポイント・テレビ会議サービスにおいて複数の離散的ソ ースからのビュワへのプレゼンテーションを制御することを可能にする方法であ って、該方法は、 ソースからのイメージをコンポジット・ストリームに結合するステップと、 複数のコンポジット・ストリームからのイメージのサブセットを１つのグループ にまとめるステップと、 １つのグループにまとめたイメージをそれがシングル・ストリームであるか のように操作するステップと、 操作したイメージをビュワに表示するステップとを具えたことを特徴とする 方法。 ５． 個人の各参加者が他の参加者に表示されたビデオ・イメージから切り離 して、その参加者に表示されるビデオ・イメージを合成できるようにするテレビ 会議システムであって、該システムは、 複数の参加者ステーションからの複数のビデオ信号ストリームであって、各 ビデオ信号ストリームは複数のビデオ・インスタンスを含み、各ビデオ・インス タンスはビデオ信号ストリームで表されたビデオ・ピクチャの個々のイメージ・ エレメントであるものを受信する手段と、 前記複数のビデオ信号ストリームを複数のコンポジット・ビデオ・ストリー ムに結合する手段であって、各コンポジット・ビデオ・ストリームは該ビデオ信 号ストリームの２つまたは３つ以上の選択した部分を有する手段と、 前記コンポジット・ビデオ・ストリームの各々をそれぞれの参加者ステーショ ンに出力する手段と、 ソフトウェアによって制御され、異なるビデオ信号ストリームからの複数の インスタンスを個々のビデオ・インスタンス・グループに関連づける手段と、 ソフトウェアによって制御され、前記個々のビデオ・インスタンス・グルー プをそれがビデオ信号ストリームであるかのように操作する手段とを具えたこと を特徴とするテレビ会議システム。 ６． 請求項５に記載のテレビ会議システムにおいて、前記関連づけ手段はビ デオ・インスタンス・グループをグループとしてスケーリングする手段を含むこ とを特徴とするテレビ会議システム。 ７． 請求項５に記載のテレビ会議システムにおいて、前記関連づけ手段はビ デオ・インスタンス・グループをクロマキーイングする手段を含み、グループの カラーまたは輝度範囲を除去できるようにしたことを特徴とするテレビ会議シス テム。 ８． 請求項５に記載のテレビ会議システムにおいて、前記関連づけ手段はビ デオ・インスタンス・グループをグループとしてミラーリングする手段を含むこ とを特徴とするテレビ会議システム。 ９． 請求項５に記載のテレビ会議システムにおいて、前記関連づけ手段はビ デオ・インスタンス・グループの優先度をグループとして変更する手段を含み、 関連するグループのスタッキング順序をグループと関連しないビデオ・インスタ ンスに対して変更できるようにしたことを特徴とするテレビ会議システム。 10． テレビ会議システムであって、 複数のユーザ・ステーションからの複数のビデオ信号ストリームであって、 各ビデオ信号ストリームは１つまたは２つ以上のビデオ・インスタンスを含むも のを受信する手段と、 前記複数のビデオ信号ストリームを複数のコンポジット・ビデオ・ストリー ムに結合する手段であって、各コンポジット・ビデオ・ストリームは該ビデオ信 号ストリームの２つまたは複数の選択した部分を有する手段と、 前記コンポジット・ビデオ・ストリームの各々をそれぞれのユーザ・ステー ションに出力する手段と、 異なるビデオ信号ストリームからの複数のインスタンスをグループとして操 作できる個々のビデオ・インスタンス・グループに関連づける手段とを備え、 前記関連づけ手段はビデオ・インスタンス・グループをグループとしてウィ ンドウ操作する手段を含み、定義されたウィンドウ内の関連グループの部分を除 去できるようにしたことを特徴とするテレビ会議システム。 11． 請求項５に記載のテレビ会議システムにおいて、 複数のユーザ・ステーションからの複数のオーディオ信号ストリームであっ て、オーディオ信号ストリームの各々が複数のオーディオ・インスタンスを含む ものを受信する手段と、 前記オーディオストリームを複数のコンポジット・オーディオ・ストリーム に結合する手段と、 前記コンポジット・オーディオ信号ストリームをそれぞれのユーザ・ステー ションに出力する手段とをさらに具えたことを特徴とするテレビ会議システム。 12． 請求項１１に記載のテレビ会議システムにおいて、前記関連づけ手段は 前記ビデオ・インスタンス・グループをビデオ・インスタンス・グループに対応 するそれぞれのオーディオ信号ストリームのオーディオ・インスタンスと関連づ ける手段を含むことを特徴とするテレビ会議システム。 13． テレビ会議システムであって、 複数のユーザ・ステーションからの複数のビデオ信号ストリームであって、 各ビデオ信号ストリームは１つまたは２つ以上のビデオ・インスタンスを含むも のを受信する手段と、 前記複数のビデオ信号ストリームを複数のコンポジット・ビデオ・ストリー ムに結合する手段であって、各コンポジット・ビデオ・ストリームは該ビデオ信 号ストリームの２つまたは３つ以上の選択した部分を有する手段と、 前記コンポジット・ビデオ・ストリームの各々をそれぞれのユーザ・ステー ションに出力する手段と、 複数のユーザ・ステーションからの複数のオーディオ信号ストリームであっ て、該オーディオ信号ストリームの各々が複数のオーディオ・インスタンスを含 むものを受信する手段と、 前記オーディオ・ストリームを複数のコンポジット・オーディオ・ストリー ムに結合する手段と、 前記コンポジット・オーディオ信号ストリームをそれぞれのユーザ・ステー ションに出力する手段と、 異なるビデオ信号ストリームからの複数のインスタンスをグループとして操 作できるビデオ・インスタンス・グループに関連づける手段と、 前記関連づけ手段は前記ビデオ・インスタンス・グループをビデオ・インス タンス・グループに対応するそれぞれのオーディオ信号ストリームのオーディ オ・インスタンスと関連づける手段を含んでいるものと、 該ビデオ・インスタンス・グループと関連づけられたオーディオ・インスタ ンスのボリュームをグループのサイズと関連づけ、オーディオ・インスタンスの ボリュームがグループのサイズの変化と共に増減するようにする手段とを具えた ことを特徴とするテレビ会議システム。 14． 個人の各参加者が他の参加者に表示されたビデオ・イメージから切り離 して、その参加者に表示されるビデオ・イメージを合成できるようにするテレビ 会議システムであって、該システムは、 複数の参加者ステーションからの複数のビデオ信号ストリームであって、各 ビデオ信号ストリームは複数のビデオ・インスタンスを含み、各ビデオ・インス タンスはビデオ信号ストリームで表されたビデオ・ピクチャの個々のイメージ・ エレメントであるものを受信する手段と、 前記複数のビデオ信号ストリームを複数のコンポジット・ビデオ・ストリー ムに結合する手段であって、各コンポジット・ビデオ・ストリームは該ビデオ信 号ストリームの２つまたは３つ以上の選択した部分を有する手段と、 前記コンポジット・ビデオ・ストリームの各々をそれぞれの参加者ステーショ ンに出力する手段と、 前記複数の参加者ステーションからの複数のオーディオ信号ストリームであ って、各オーディオ信号ストリームは複数のオーディオ・インスタンスを含み、 各オーディオ・インスタンスは個々のサウンド・エレメントであるものを受信す る手段と、 前記複数のオーディオ信号ストリームを複数のコンポジット・オーディオ・ ストリームに結合する手段と、 前記コンポジット・オーディオ・ストリームの各々をそれぞれの参加者ステー ションに出力する手段と、 ソフトウェアによって制御され、それぞれのビデオ信号ストリームのビデオ ・インスタンスをそれぞれのオーディオ信号ストリームのオーディオ・インスタ ントと関連づけて個々の関連オーディオおよびビデオ・インスタンス・グルー プになるようにする手段と、 ソフトウェアによって制御され、前記個々のオーディオおよびビデオ・イン スタンス・グループをそれがシングル・ストリームであるかのように操作する手 段とを具えたことを特徴とするテレビ会議システム。 15． テレビ会議システムであって、 複数のユーザ・ステーションからの複数のビデオ信号ストリームであって、 各ビデオ信号ストリームは１つまたは２つ以上のビデオ・インスタンスを含むも のを受信する手段と、 前記複数のビデオ信号ストリームを複数のコンポジット・ビデオ・ストリー ムに結合する手段であって、各コンポジット・ビデオ・ストリームは該ビデオ信 号ストリームの２つまたは３つ以上の選択した部分を有する手段と、 前記コンポジット・ビデオ・ストリームの各々をそれぞれのユーザ・ステー ションに出力する手段と、 複数のユーザ・ステーションからの複数のオーディオ信号ストリームであっ て、該オーディオ信号ストリームの各々は１つまたは複数のオーディオ・インス タンスを含むものを受信する手段と、 前記複数のオーディオ信号ストリームを複数のコンポジット・オーディオ・ ストリームに結合する手段と、 該コンポジット・オーディオ信号ストリームの各々を前記ユーザ・ステーショ ンに出力する手段と、 それぞれのビデオ信号ストリームのビデオ・インスタンスをそれぞれのオー ディオ信号ストリームのオーディオ・インスタンスと関連づける手段であって、 該関連づけ手段は少なくとも１つの選択されたオーディオ・インスタンスのボリ ュームを少なくとも１つの選択されたビデオ・インスタンスのサイズと関連づけ る手段を含み、選択されたオーディオ・インスタンスのボリュームが選択された ビデオ・インスタンスの変化と共に増減するようにした関連づけ手段とを具えた ことを特徴とするテレビ会議システム。