(57)【特許請求の範囲】
【請求項１】
会話形通信システムのサーバとクライアントとの間でコマンド情報の通信をネットワーク上で行う方法であって、
前記サーバと前記クライアントとの間で送信されるコマンドと、前記クライアントによって、又は当該システム内でトリガされるイベントと関連付けられた該コマンドを有するコマンドディスクリプタと、サーバルート及びコマンドルートノードのうちの一方の情報と、を含むコマンドメッセージを前記サーバによって発生させるコマンドメッセージ発生ステップであって、
前記サーバルートは、トリガされたイベント用のノードから前記コマンドディスクリプタまでの経路を形成するための情報であり、
前記コマンドルートノードは、前記クライアントによって、又は当該システム内でトリガされるイベントを受信可能とするイベントシンクとしての役割を果たす実行フィールドと、前記受信したイベントに関連付けられ、且つ前記コマンドディスクリプタの識別に用いられるコマンドディスクリプタＩＤを含むフィールドとを有し、前記コマンドルートノードがＭＰＥＧ−４によってサポートされるノードのリストに追加されて、トリガされたイベント用のノードから前記コマンドディスクリプタまでの経路を形成するための情報である、コマンドメッセージ発生ステップと、
前記クライアントによって、又は当該システム内でイベントがトリガされるとネットワーク上で前記コマンドメッセージに含まれるコマンドを前記サーバに送信し戻すステップとを具えることを特徴とする方法。
【請求項２】
前記会話形通信システムがＭＰＥＧ−４国際基準を用いることを特徴とする請求項１記載の方法。
【請求項３】
前記コマンドメッセージが、ＶＲＭＬ２．０仕様に基づくＭＰＥＧ−４で規定されたローカルインタラクションモデルに適合することを特徴とする請求項２記載の方法。
【請求項４】
前記イベントのトリガをマウスクリックとすることを特徴とする請求項１記載の方法。
【請求項５】
前記イベントのトリガをタイマ信号とすることを特徴とする請求項１記載の方法。
【請求項６】
前記コマンド情報を前記サーバからクライアントに送信することを特徴とする請求項１記載の方法。
【請求項７】
前記コマンド情報を前記クライアントからサーバに送信することを特徴とする請求項１記載の方法。
【請求項８】
サーバとクライアントとの間でコマンド情報の通信をネットワーク上で行う手段を具える会話形通信システムであって、
前記サーバと前記クライアントとの間で送信されるコマンドと、前記クライアントによって、又は当該システム内でトリガされるイベントと関連付けられた該コマンドを有するコマンドディスクリプタと、サーバルート及びコマンドルートノードのうちの一方の情報と、を含むコマンドメッセージを前記サーバによって発生させるコマンドメッセージ発生手段であって、
前記サーバルートは、トリガされたイベント用のノードから前記コマンドディスクリプタまでの経路を形成するための情報であり、
前記コマンドルートノードは、前記クライアントによって、又は当該システム内でトリガされるイベントを受信可能とするイベントシンクとしての役割を果たす実行フィールドと、前記受信したイベントに関連付けられ、且つ前記コマンドディスクリプタの識別に用いられるコマンドディスクリプタＩＤを含むフィールドとを有し、前記コマンドルートノードがＭＰＥＧ−４によってサポートされるノードのリストに追加されて、トリガされたイベント用のノードから前記コマンドディスクリプタまでの経路を形成するための情報である、コマンドメッセージ発生手段と、
前記クライアントによって、又は当該システム内でイベントがトリガされるとネットワーク上で前記コマンドメッセージに含まれるコマンドを前記サーバに送信し戻す手段とを具えることを特徴とするシステム。
【請求項９】
ＭＰＥＧ−４国際基準を用いることを特徴とする請求項８記載のシステム。
【請求項１０】
前記コマンドメッセージが、ＶＲＭＬ２．０仕様に基づくＭＰＥＧ−４で規定されたローカルインタラクションモデルに適合することを特徴とする請求項９記載のシステム。
【請求項１１】
前記イベントのトリガをマウスクリックとすることを特徴とする請求項８記載のシステム。
【請求項１２】
前記イベントのトリガをタイマ信号とすることを特徴とする請求項８記載のシステム。
【請求項１３】
前記コマンド情報を前記サーバからクライアントに送信することを特徴とする請求項８記載のシステム。
【請求項１４】
前記コマンド情報を前記クライアントからサーバに送信することを特徴とする請求項８記載のシステム。
【発明の詳細な説明】
【０００１】
【技術の分野】
本発明は、通信システム特にＭＰＥＧ−４基準に基づく通信システムでクライアント−サーバインタラクションを実行する技術に関するものである。
【０００２】
【背景技術】
インタラクションは、ＭＰＥＧ−４国際基準（ＩＳＯ／ＩＥＣ  １４４９６  Ｐａｒｔ１−６，  Ｃｏｍｍｉｔｔｅｅ  Ｄｒａｆｔ，  Ｏｃｔｏｂｅｒ  ３１，  １９９７，  Ｆｒｉｂｏｕｒｇ，  Ｓｗｉｔｚｅｒｌａｎｄ）の発展において特に関心がある。バックチャネルは、会話形メッセージサポートに対して指定される。しかしながら、そのチャネルを通じて搬送すべきメッセージのシンタックス及びセマンティックは、指定されないままであり、その結果、そのようなメッセージの搬送をトリガする機構もそのままである。ＤＳＭ−ＣＣ（ＩＳＯ／ＩＥＣ  国際基準１３８１８−６）やＲＴＳＰ（ＲＦＣ２３２６）のような現存する基準は、プレイバック中に媒体ストリームを再配置する従来のＶＣＲタイプのインタラクションをサポートするが、これは、更に複雑なインタラクションの制御を必要とするＭＰＥＧ−４アプリケーションに対しては不十分である。
【０００３】
会話メッセージを、所定のユーザ動作又はシステムイベントによって発生させることができる。それは、一つ以上のストリームを変更することができるサーバに送信され、オブジェクトを追加若しくは除去し又は完全に新しいシーンに切り替えることによって配送される。ユーザ動作は、オブジェクトのクリック、テキストストリームの入力等を含む。システムイベントは、タイマ、状態テスト等を含む。
【０００４】
インタラクションは、アプリケーション特有であり、ユーザイベントに関して完全に会話動作を規定することができない。アプリケーション特有の会話をサポートするために、ＣＧＩのようなアプローチを採用する必要がある。特定のユーザイベントによって、アプリケーション特有のコマンドデータはサーバに戻される。サーバは、この場合、典型的にはシーン描写更新コマンドを送信することによって応答することができる。これによって、アプリケーションの要求に応じた完全なインタラクションを完全に自由にサポートすることができる。
【０００５】
ＭＰＥＧ−４は、実際には二つのモデルのインタラクションすなわちローカルなものとリモートのものとを用いる。ローカルインタラクションを、ＭＰＥＧ−４  ＢＩＦＳ（シーンの２値フォーマット）のネイティブイベントアーキテクチャを用いて完全に実現するすることができ、それは、ＶＲＭＬ  ２．０ＲＯＵＴＥ設計（www.vrml.org及び"Ｔｈｅ  ＶＲＭＬ  Ｈａｎｄｂｏｏｋ"，  Ｊ．Ｈａｒｔｍａｎ  ａｎｄ  Ｊ．Ｗｅｒｎｅｃｋｅ，  Ａｄｄｉｓｏｎ−Ｗｅｓｌｅｙ，  １９９６参照）に基づき、ＭＰＥＧ−４仕様のＰａｒｔ１（Ｓｙｓｔｅｍｓ）に記載されている。ＭＰＥＧ−４受信機が他のアプリケーションでホストされる場合、ＭＰＥＧ−４のＰａｒｔ１に規定されているように、アプリケーションによってＭＰＥＧ−４受信機に送信する必要があるイベントを、ＢＩＦＳ更新コマンドに変換することができる。
【０００６】
リモートインタラクションは、現在のところＵＲＬからなる。ＭＰＥＧ−４  Ｓｙｓｔｅｍｓ  Ｃｏｍｍｉｔｔｅｅ  Ｄｒａｆｔに規定されているように、それを、コンテントへのアクセスを取得するためにしか使用することができない。その結果、それを用いてコマンドをトリガすることができない。
【０００７】
ＭＰＥＧ−４システムは既に、シーン描写（ＢＩＦＳ）の一部であるイベントソース／シンクルートの使用を通じたローカルインタラクティブサポートを有し、これによって、完全にローカルインタラクションモデルを統合するサーバインタラクションプロセスを有することが好ましくなる。
【０００８】
【発明の開示】
本発明の目的は、ＭＰＥＧ−４国際基準を用いて、「クライアント」と「サーバ」のような二つのエンティティ間のメッセージの送信を行う技術を提供することである。
【０００９】
本発明の第２の目的は、ＭＰＥＧ−４プレーヤ又はクライアントのコンテキストのそのようなメッセージをユーザ又はシステムによって発生させることかできる技術を提供することである。
【００１０】
第３の目的は、ＶＲＭＬ２．０仕様に基づくＭＰＥＧ−４で規定したローカルインタラクションモデルに適合したそのようなメッセージを発生させる技術を提供することである。
【００１１】
他の目的は、ＭＰＥＧ−４ビットストリーム内のそのようなメッセージを符号化する技術を提供するとともに、符号化メッセージをシーン描写にリンクすることである。
【００１２】
他の目的は、使用のためにそのようなメッセージをクライアントから送信する前にサーバが容易にメッセージを変更することができるように、メッセージを符号化する技術を提供することである。その一例は「クッキー」管理であり、この場合、サーバは、特定のサイトにおけるユーザの動作についての状態情報を格納するコードワードを有するコマンドの内容を迅速に更新できるようにする必要がある。
【００１３】
以下説明する更なる開示を参照することによって明らかになるこられ及び他の目的に適合するために、本発明は、サーバコマンドをＭＰＥＧ−４クライアントに組み込む技術を広く提供する。この技術は、コマンドディスクリプタ、すなわち、シーン描写情報とともに送信されるとともに関連のイベントのトリガに応答してサーバに戻されるコマンドを有するディスクリプタの特定の形態の使用を伴う。シーン描写の所望のイベントソースを、そのコマンドディスクリプタに関連させる。
【００１４】
一例では、関連付けを、サーバルートを用いて行う。それは従来のＭＰＥＧ−４  ＢＩＦＳルートと同様に動作するが、シンクフィールドを用いてソースフィールドをリンクする代わりに、シンクコマンドディスクリプタを用いてソースフィールドをリンクする。サーバルートは、ＭＰＥＧ−４  ＢＩＦＳ  ＲＯＵＴＥシンタックスの拡張を必要とする。
【００１５】
他の例では、関連付けを、コマンドノードを用いて行う。そのようなノードは、シンクフィールドを有し、コマンドディスクリプタに関連させる。この技術は、二つ以上のノードタイプのＭＰＥＧ−４  ＢＩＦＳノードへの追加を伴う。
【００１６】
いずれの場合も、ＭＰＥＧ−４によって規定された通常のインタラクションモデルを、ローカルインタラクション、すなわち、ローカルクライアント上で発生し及び処理したイベント及びサーバインタラクション、すなわち、サーバに戻されるクライアント発生コマンド上で発生したイベントに対して使用することができる。コマンドディスクリプタに関連するイベントをトリガすると、サーバルート又はコマンドモードに対する一定のルートを通じて、クライアントは、コマンドディスクリプタに格納されたコマンド情報を取得し、好適例で設けたシンタックスを用いてコマンド情報をコマンドメッセージにパッケージし、適切なバックチャネルを用いてコマンドメッセージをサーバに戻す。サーバに戻される発生したコマンドによって搬送すべきデータは、コマンドディスクリプタに含まれる。コマンドディスクリプタがＭＰＥＧ−４の全体に亘るディスクリプタフレームワークの一部であるので、それを、タイムスタンプしたオブジェクトディスクリプタ更新を用いて、動的に更新することができる。これによって、例えば「クッキー」管理を実行するカスタマイズコマンドを非常に柔軟にすることができる。
発生したコマンドを処理する際にサーバを更に助長するために、時間のような追加の情報をイベントともに発生させ、ソースノードなどもクライアントのメッセージに含まれる。
【００１７】
【発明を実施するための最良の形態】
詳細な説明
本発明の実施の形態を、図面を参照して詳細に説明する。
ＭＰＥＧ−４は、国際標準化機構（ＩＳＯ）の下で規定した国際規格である。その公式の名称はＩＳＯ／ＩＥＣ１４４９６である。ＭＰＥＧ−１，ＭＰＥＧ−２，Ｈ．２６１又はＨ．２６３のような以前のＩＳＯ又はＩＴＵとの基本的な相違は、オーディオビジュアルオブジェクトの表示が存在するアドレスである。したがって、オーディオビジュアルシーンを具える互いに相違するエレメントは、先ず、仕様のＰａｒｔ２（Ｖｉｓｕａｌ）及びＰａｒｔ３（Ａｕｄｉｏ）に規定したような技術を用いて個別に符号化される。そのオブジェクトは、受信機に送信され、又はオブジェクトを配置する位置及び時間を表現するシーン描写情報とともに大容量記憶装置から読み出されて、ユーザに提供する。
【００１８】
オーディオビジュアルオブジェクトの各々及び適切なシーン描写情報に対する符号化データは、それ自体の「チャネル」内で、すなわち、基本ストリームで送信される。後に説明するように、シーン中で参照したオーディオビジュアルオブジェクトを、符号化データを有する基本ストリームに正確に関連させるよう受信機に許容させるために、他の制御情報も送信する。
【００１９】
ＭＰＥＧ−４の構造を十分に説明するために、図１を参照する。図１の下側に、あり得る種々の配送システムを示し、それは、通信リンク又は大容量記憶装置のＡＴＭ，ＩＰ，ＭＰＥＧ−２転送ストリーム（ＴＳ），ＤＶＢを含むが、それに限定されるものではない。ＭＰＥＧ−２に対して、ＭＰＥＧ−４は、多様な通信環境に亘る配送を許容するために、それ自体のトランスポート層ファシリティを規定しない。適切なマルチプレクサ処理性能、例えば、ＧＳＭ無線データチャネルを有しないすなわち遅延を小さくする必要がある配送システムに対して、ＦｌｅｘＭｕｘと称される簡単なマルチプレクサ処理ツールが規定される。
【００２０】
この下部構造を用いて、基本ストリームのセットをクライアントに配送する。そのストリームは、シーン描写情報、オーディオビジュアルオブジェクトデータ（例えば、ＭＰＥＧ−２又はＭＰＥＧ−４ビデオストリームのような符号化ビデオ）又は制御情報（すなわちオブジェクト描写）のうちのいずれか一つを有する。各基本ストリームは、１タイプのデータのみを有する。
【００２１】
基本ストリームに含まれるデータは、ＭＰＥＧ−４Ｓｙｎｃ層（ＳＬ）に従ってパッケージ化され、そのパッケージは、下にある媒体（例えば、ビデオ又はオーディオのフレーム又はシーン描写コマンド）のユニットにアクセスし、タイミング情報（クロックリファレンス及びタイムスタンプ）、シーケンス番号等を追加する。ＳＬを、図１の中間に示す。
【００２２】
個別のオーディオビジュアルオブジェクトデータの符号化を、ＭＰＥＧ−４仕様のＰａｒｔ２及び３に従って実行する。ＭＰＥＧ−１又はＭＰＥＧ−２のような他の符号化を利用することもできる。シーン描写及び制御情報（オブジェクト描写）は、ＭＰＥＧ−４のＰａｒｔ１に規定されている。
【００２３】
受信機は、シーン描写情報及び復号化されたオーディオビジュアルオブジェクトデータを処理し、合成すなわちオブジェクトを結合して単一ユニットにするプロセス及び描写すなわちユーザのモニタに結果を表示し又はユーザのスピーカを通じて音声を再生するプロセスを実行する。これを図１の上側に示す。
シーン描写に゛含まれる情報に応じて、ユーザは、シーンに連関する機会を有する。さらに、シーン描写は、動的な行為を可能にする情報を有する。換言すれば、シーンそれ自体は、ユーザの介入なくイベントを発生させることができる。
【００２４】
ＭＰＥＧ−４のオブジェクトベース構造は、ＭＰＥＧ−２や他のシステムに比べて更に一般的なシステムデコーダモデルの規定を必要とする。特に、図２に示すように、受信機は、各オブジェクトに対応するデコーダのセットを具えるものと考えられる。各デコーダは、復号化バッファ及び合成バッファを有する。復号化バッファは、ＭＰＥＧ−２と同様な技術すなわちクロックを復元する際のクロックリファレンスを用いる送信機によって管理され、それは、理論的には瞬時の復号化に続く復号化バッファからのデータの復元用のタイムスタンプを復号化する。合成バッファに配置されたデータは、合成器(compositor)によって使用され、以前に配置された任意のデータに上書きされる。復号化バッファは、ＤＭＩＦ（Digital Media Integration Framework, Part 6 of MPEG-4）アプリケーションインタフェース内でカプセル化されたデマルチプレクサによって充填される。これは概念的なインタフェースであり、ここではこれ以上の説明を必要としない。
【００２５】
ＭＰＥＧ−４  シーン描写
ＭＰＥＧ−４のシーン描写情報は、ＶＲＭＬ２．０（virtual reality Modeling Language）仕様の拡張である。ＶＲＭＬは、シーンを規定するツリー構造アプローチを用いる。シーンの各ノードは、実際のビジュアル又はオーディオ情報を有するリーフを用いて、合成及び／又はグループ化動作を実行する。さらに、ノードは、その行為に影響を及ぼすフィールドを有する。例えば、転送ノードは、回転角を規定する回転フィールドを有する。
【００２６】
ＶＬＭＬが純粋な３次元シーン描写言語であるので、ＭＰＥＧ−４は、２次元合成をアドレスするある追加のノードを規定する。これは、低コストシステムに収束するアプリケーションの必要を指摘する。ＶＲＭＬに対して、ＭＰＥＧ−４は、テキストベースシーン描写を使用せず、ＢＩＦＳ（Binary Format for Scenes）と称される帯域効率圧縮表現を規定する。
【００２７】
ＢＩＦＳ符号化は、ＶＲＭＬシーンのテクスチャ仕様に密接に従う。特に、ノード符号化は、テキストベースＶＲＭＬファイルと同様に、デプス−ファーストファッション(depth-first fashion)で実行される。ＶＲＭＬの場合のように、ノードの各タイプのフィールドは、デフォールト値を仮定する。したがって、非デフォールト値を有するフィールドのみ各ノード内で指定される必要がある。ノード内のフィールド符号化は、符号化フィールドの値に従う簡単なインデックスベース法を用いて実行される。ノードタイプの符号化は更に複雑なものとなる。帯域効率を更に増大させるために、（任意の場合の）親フィールドの文脈を考慮する。子ノードを受け入れる各フィールドを、特定のノードデータタイプに関連させる。ノードは、既知のように、このノードデータタイプに対して特別なインデックスを用いて符号化される。
【００２８】
符号化ノードの各々に、ノード識別子（典型的には整数）を割り当てることもできる。これによって、そのノードをシーン中の他の位置で再使用することができる。これは、ＶＲＭＬのＵＳＥ／ＤＥＦ機構と同一である。しかしながら、更に重要なことは、インタラクションプロセスに参加できることである。
【００２９】
ＭＰＥＧ−４で用いられるインタラクションモデルは、ＶＲＭＬのものと同一である。特に、ノードのフィールドは、イベントソース、イベントシンク又はその両方としての役割を果たす。イベントソースを、特定のユーザ動作又はシステムイベントに関連させる。ユーザイベントの例は、マウスをクリックしたときに検出することができるセンサノードである。システムイベントの例は、システムの時間に従ってとりがされるタイマ（タイムセンサノード）である。
【００３０】
ダイナミックシーン行為及び会話は、イベントソースフィールドをイベントシンクフィールドにリンクすることによって行われる。実際のリンクは、ＲＯＵＴＥの機構を用いて行われる。ＭＰＥＧ−４ルート仕様は、場合によっては、シーンノード描写直後に与えられる。その符号化は、ソースノード及びシンクノードに対するノード識別子並びにソースフィールド及びシンクフィールドのフィールドインデックスに基づく。
【００３１】
ＶＲＭＬとＭＰＥＧ-４の重大な区別は、ＭＰＥＧ−４の場合、シーン描写を、タイムスタンプコマンドを用いて動的に更新できることである。それに対して、ＶＲＭＬは、静的な「世界」(world)で動作する。世界をロードした後、それを変更する機構が存在しない。ＭＰＥＧ−４において、オブジェクトを追加し又は削除することができ、シーンの一部（又はシーン全体）を置換することができる。
【００３２】
オブジェクトディスクリプタ
（編集などを容易にする）非常に柔軟な構造を有するために、オーディオビジュアルオブジェクトの成分は、シーン描写それ自体の中には含まれない。換言すれば、ＢＩＦＳは、シーン構造に対する情報と、純粋に合成したオブジェクト例えばＢＩＦＳ／ＶＲＭＬノードを用いて構成した赤色の矩形のみを提供する。符号化情報を必要とするオーディオビジュアルオブジェクトは、ＵＲＬ又はオブジェクトディスクリプタのみを指定するリーフノードによってシーン中で表現される。
【００３３】
オブジェクトディスクリプタは、単一のオーディオビジュアルオブジェクトの符号化表示を具える基本ストリームを表現する階層的に構造された情報である。例えば、ステレオ又は多言語音声、階層的に符号化されたビデオに対して、二つ以上のストリームが要求される。最上位のディスクリプタは、オブジェクトディスクリプタと称され、オブジェクトディスクリプタ識別子（ＯＤＩＤ）を基本ストリームディスクリプタのセットに関連させるのに用いられるシェルである。基本ストリームディスクリプタは、ＥＳ−ＩＤと、特定のＥＳ−ＩＤに関連した基本ストリームに含まれるデータのタイプについての情報とを有する。この情報は、メインレベルでメールプロファイルに従って、例えばストリームがＭＰＥＧ−２ビデオデータを有することを受信機に知らせる。
【００３４】
ＥＳ−ＩＤの実際の基本ストリームへのマッピングは、ストリームマップテーブルを用いて行われる。例えば、それは、ＥＳ−ＩＤ  １０を、サポート番号１０２５に関連させる。このテーブルは、セッションセットアップ中に受信機で利用される。複数レベルの間接行為を用いることによって、ＭＰＥＧ−４成分の操作を容易にする。例えば、再マルチプレクサ処理は、相違するストリームマップテーブルしか必要としない。それ以外の情報を、ＭＰＥＧ−４成分内で変更する必要がない。
【００３５】
オブジェクトディスクリプタは、それ自体の基本ストリーム内で伝送され、Ｓｙｎｃ層構文に従うコマンドにパッケージ化される。これによって、オブジェクトディスクリプタを更新し、追加し又は除去することができる。
図３は、シーンディスクリプタ中のオーディオビジュアルオブジェクトをその基本ストリームに関連させるためにオブジェクトディスクリプタ及び基本ストリームディスクリプタを用いるプロセスを示す。先ず、特定のイニシャルオブジェクトディスクリプタを使用して、オブジェクトディスクリプタストリーム及び選択した成分に関連したシーンディスクリプタストリームを指定することによって、ＭＰＥＧ−４受信機をブートストラップする。このディスクリプタは、セッションセットアップ中に受信機に配送される。
【００３６】
本例のシーンディスクリプタは、オブジェクトディスクリプタのうちの一つを指定するオーディオソースノードを有する。そのディスクリプタは、関連のストリームにＥＳ−ＩＤを提供する基本ストリームディスクリプタを有する。ＥＳ−ＩＤは、ストリームマップテーブルを用いて、実際の転送チャネルに対して決定される。シーンは、ムービーテクスチャノードを有し、この場合、それは、二つのストリームを有するスケール化自在のビデオを用いる。その結果、二つの基本ストリームディスクリプタが含まれ、各々は適切なストリーム（ベース及びエンハンスメント層）を指定する。
【００３７】
ＭＰＥＧ−４クライアント／サーバインタラクション
これまでの説明及びＭＰＥＧ−４シーン描写フレームワークの考察から、十分なローカルインタラクションフレームワークが提供されている間、サーバに基づくインタラクションを行うファシリティが存在しない。特に、サーバに戻すべきメッセージを描写し又はそのようなメッセージの発生をトリガする機構が存在しない。
【００３８】
図４は、クライアント／サーバ環境の一例を示す。図４の右側にＭＰＥＧ−４サーバが存在し、それは、ＳＬパッケージ化ストリームとして読み出されるデータの時限伝送を行うポンプを有し、ＤＭＩＦサービスプロバイダのインスタンスも存在し、この場合、ＭＰＥＧ−４ＦｌｅｘＭｕｘマルチプレクサ処理ツールを利用する。
ＦｌｅｘＭｕｘの仕様は任意である。既知のように、他のサーバ構造を用いることもできる。例えば、データソースを、ＳＬパッケージ化ストリームの代わりにＭＰＥＧ−４ファイルとすることができる。
【００３９】
サーバで発生した情報は、ネットワーク（例えば、ＩＰ又はＡＴＭ）を横切って送信される。受信側には、デマルチプレクサ処理された基本ストリームをプレーヤに配送するＤＭＩＦサービスプロバイダの同様なインスタンスを有する。ＤＭＩＦからＤＭＩＦへの信号送信は、セッションセットアップを実行する方法の一つであり、ＭＰＥＧ-４のＰａｒｔ４で説明されている。既知のように、ＳＩＰ，ＳＤＰ，ＲＴＳＰ等のインターネットに基づくプロトコルを含む他の方法も可能である。
【００４０】
本発明の主要な目的の一つは、最初に、サーバコマンドを表現してそれをサーバからクライアントに送信し、次いで、それを、適切な時間にクライアント側でトリガし、最後に、サーバに戻して他の動作を開始することである。
【００４１】
コマンドディスクリプタ
コマンドディスクリプタフレームワークは、シーングラフのノード内のイベントソースにコマンドを関連させる手段を提供する。ユーザがシーンに連関すると、関連のイベントがトリガされ、次いで、コマンドが処理されるとともにサーバに戻される。
【００４２】
実際のインタラクションそれ自体は、成分クリエータによって指定され、それを、マウスクリック、マウスオーバ又は他の任意の形態のインタラクション（例えばシステムイベント）とする。コマンドディスクリプタフレームワークは、三つのエレメント、すなわち、コマンドディスクリプタ、サーバルート又はコマンドルートノード及びコマンドからなる。
【００４３】
コマンドディスクリプタは、ＩＤ（識別番号）と、関連のイベントがトリガされる際に最終的にサーバに戻される実コマンドとを有する。
ＩＤは、シーン表現情報からこのコマンドディスクリプタを言及するのに用いられる。それが含むコマンドディスクリプタ及びコマンドをシーンそれ自体から分離することによって、同一コマンドを使用するのに１個より多くのイベントを許可する。これによって、任意の方法でシーン描写を変更することなくコマンドの変更を許容する。
【００４４】
コマンドディスクリプタのイベントソースフィールドモードに対する関連を、種々の方法で行うことができる。
先ず、サーバルートを、ＢＩＦＳの規則的なルートファシリティに追加することができる。従来のルートとの差は、ルートのターゲットを他のフィールドではなくコマンドディスクリプタとすることである。この構造を、図５（ａ）に示す。本例では、二つのコマンドディスクリプタに対して、シーンツリーフィールドイベントに二つのノードを有する。センサノードは、ＭＰＥＧ−４技術のフィールドで見られるように、イベントソース、イベントアウト又はイベントソース／シンクによって他のノードに対するイベントをトリガし、それは、サーバルートを通じてコマンドディスクリプタ１に送られる。コマンドディスクリプタ２に対して、ノードからディスクリプタまでの直接のサーバルートが存在する。
【００４５】
第２のアプローチは、新たなコマンドルートノードタイプを、ＭＰＥＧ−４によってサポートされるノードのリストに追加することからなる。このノードは、「実行」イベントシンクフィールドと、コマンドディスクリプタＩＤ
を有するフィールドとを有する。「実行」フィールドがイベントを受信するときには常に、規則的なＭＰＥＧ−４／ＶＲＭＬルートを用いて、そのＩＤに関連したコマンドディスクリプタを用いて、コマンドをサーバに戻す。この構造を、図５（ｂ）に示す。図５（ａ）と比較すると、サーバルートは、コマンドルートノードに置換されている。二つのケースの動作はほぼ同一である。
【００４６】
コマンドディスクリプタシンタックスを図６に示す。ビットストリームシンタックスを表現するためにフレーバ媒体表示(Flavor media representation)を使用し、それは、ＭＰＥＧ−４仕様のＰａｒｔ１でも使用されている（WWW.ee.columbia.edu/flavor or Part 1 of MPEG-4参照）。コマンドディスクリプタは、この特定のタイプのディスクリプタとして識別する特定のタグで開始する。この場合、コマンドＩＤに続くディスクリプタＩＤを有する。コマンドＩＤは、「開始」や、「休止」や、「停止」のような予め規定されたサーバコマンドを信号送信するのに使用される。それに続いて、バイトで計数されるディスクリプタ中の残りのデータの長さ表示を有する。この場合、ＥＳ−ＩＤを計数することによって、メッセージがサーバに戻される。複数の場合において、１対複数の通信を行う、すなわち、単一のコマンドを複数のサーバに送信することを所望する。これは、一連の所望のＥＳ−ＩＤに続く。最後に、アプリケーション固有のパラメータのセットが含まれる。これらは、コマンドがトリガされるとサーバに戻される。コマンドＩＤの値に応じて、そのパラメータのセマンティックを予め規定することができる。
【００４７】
コマンドディスクリプタのバイト適合構造(byte-oriented structure)を、作動中にサーバから非常に容易に発生させることができる。これは、ユーザイベントの各々を処理した後にコマンドパラメータをサーバによって連続的に更新する必要がある場合には特に、「クッキー」管理を伴うアプリケーションに対して重要な形態である。
【００４８】
コマンドディスクリプタを更新するために、サーバ又はコンテントクリエータは、同一ＩＤを有する新たなものに従うだけでよい。
コマンドディスクリプタを除去するために、特別なコマンドを設ける。シンタックスを図７に示す。コマンドは、このディスクリプタをコマンドディスクリプタ除去コマンドとして識別するタグとともに開始する。その後、除去すべきコマンドディスクリプタのＩＤが続く。
コマンドディスクリプタ構造及びコマンドディスクリプタ除去構造の両方とも、オブジェクトディスクリプタストリーム内で実行することができる。オブジェクトディスクリプタフレームワークの構造のために、ディスクリプタを識別するタグを用いて、これらに他のディスクリプタを挟んで変化を持たせることができる。
【００４９】
既に説明したように、コマンドディスクリプタをシーンにリンクする二つの方法がある。それは、図８に示すようなＭＰＥＧ−４のシーン描写のビットストリームシンタックスの拡張を必要とする。特に、主要なＢＩＦＳシーン構造は、サーバＲＯＵＴＥ構造を含むように拡張される。規則的なＲＯＵＴＥとサーバＲＯＵＴＥとの唯一の差は、ターゲットノード／フィールドの代わりにターゲットコマンドディスクリプタのＩＤを指定していることである。サーバＲＯＵＴＥに適合するために他のＲＯＵＴＥコマンド（挿入、削除等）を変更することは、当業者には既知である。全ての場合において、ターゲットノード／フィールド対を、ターゲットコマンドディスクリプタを表示するために変更する必要がある。
【００５０】
コマンドルートノードアプローチを用いると、新たなノードタイプを規定する必要がある。ノードの規定を図９に示し、それは、ＭＰＥＧ−４のＰａｒｔ１で使用した標準的なノード規定テーブルを用いる。ノードは、二つのフィールド、すなわち、イベントシンクとしての役割を果たす「実行」フィールドと、コマンドディスクリプタを指定するＵＲＬ又はこのコマンドルートノードに関連すべきコマンドディスクリプタのＩＤを有する「コマンドディスクリプタ」フィールドのみを有する。全てのＳＦＵｒｌフィールドの場合のように、ＩＤとＵＲＬとの間の選択を、１ビットフラグを用いて行う（ＳＦＵｒｌフィールド符号化は、ＭＰＥＧ−４のＰａｒｔ１で規定される。）。
【００５１】
イベントのコマンドディスクリプタへの関連の変化を、ノード及びその範囲内のフィールドを変化させる標準的なＭＰＥＧ−４  ＢＩＦＳコマンドを用いて実行することができる。
コマンドディスクリプタを、コマンドディスクリプタ中のコマンドに応じて互いに相違する時間に互いに相違するインタラクション動作をサポートするノードを許容するコマンドディスクリプタ更新を用いて更新することができる。コマンドは、ＤＭＩＦによってサポートされるＤＡＩユーザコマンドプリミティブを用いてサーバに送信される。コマンドを伝送するのに用いられるプロトコルを含むためにコマンドディスクリプタを拡張することもできる。例えば、標準的なＭＰＥＧ−４ファシリティではなくＨＴＴＰ  ＰＯＳＴ／ＧＥＴを用いることによって、互いに相違するタグを用いて提案(submission)を表すことができる。
【００５２】
コマンドディスクリプタフレームワークが一般的であり、かつ、アプリケーション特有のユーザインタラクションをサポートするとしても、アプリケーションとサーバとの間の一貫性のあるアプリケーション動作をサポートするために少数の標準的なコマンドが必要とされる。これは、ストリーム制御のような共通のコマンドに対して特に当てはまる。その結果、共通の制御コマンドのセットを指定する。サーバは、それを処理するために任意のアプリケーション特有のコマンドに気付く必要がある。標準的なコマンドのセットによって、任意のサーバとの相互運用が許容される。図１０は、本実施の形態に対するコマンドのセットをそのコマンドＩＤとともに示す。当業者には明らかなように、他の割当ても可能である。
【００５３】
図１１は、クライアントからサーバに送信される際のコマンドのシンタックスを示す。それは、実質的には、コマンドディスクリプタのコピーからディスクリプタＩＤを除外したものである。特に、それは、コマンドＩＤと、このコマンドが送信されたＥＳ−ＩＤのセットと、コマンドディスクリプタで指定されたパラメータのセットとを有する。そのコマンドは、ＳＬパッケージ化ストリームで送信され、したがって、全タイミング及びシーケンス化情報をサーバで利用できる。
【００５４】
ディスパッチサーバコマンドに対する処理イベント
サーバルートの使用によって開始するユーザ又はシステムイベントに基づくコマンドを発生させるプロセスを詳細に説明する。
図１２を参照すると、ユーザ又はシステムイベントが発生すると、受信機は、イベントをＲＯＵＴＥ及びＳｅｒｖｅｒ  ＲＯＵＴＥのネットワークを通じて伝播する。イベントを伝播するために、ＲＯＵＴＥのタイプは重要ではなく、その結果、同一のアルゴリズムを使用することができる。イベントをＳｅｒｖｅｒ  Ｒｏｕｔｅを通じて伝播する場合、システムは、論理的な真の値に関連する状態にイベントが対応するか否か検査する。対応しない場合、サーバコマンド処理を終了する。対応する場合、ディスパッチ処理を実行する。
【００５５】
サーバルートに対するこのプロセスを図１３に示す。このプロセスは、サーバルートからコマンドディスクリプタＩＤを取得する。この場合、それを、締結シーン(tie scene)で利用できるコマンドディスクリプタに有する情報に関連させる。整合が見つからない場合、これは誤りであり、更なる動作は行われない。整合が見つからない場合、システムは、それが既知のセマンティック（予め規定されたコマンドＩＤ）に対応するか否かを知るために、コマンドＩＤを検査する。それが既知のセマンティックに対応する場合、システムは、所望のセマンティックに従ってコマンドパラメータを処理する。それが既知のセマンティックに対応しない場合、システムは、この状態をスキップし、表示したコマンドをパッケージし、それをサーバに送信する。
【００５６】
コマンドルートノードの場合、図１４を参照すると、ユーザ又はシステムイベントが発生すると、受信機は、ＲＯＵＴＥのネットワークを通じてイベントを伝播する。イベントがコマンドルートノードの「実行」フィールドに到達すると、システムは、論理的な真の値に関連した状態にイベントが対応するか否か検査する。対応しない場合、サーバコマンド処理を終了し、対応する場合、ディスパッチプロセスを実行する。
【００５７】
コマンドルートノードの場合のこのプロセスを図１５に示す。ステップのシーケンスは図１３とほぼ同一であり、その違いは、コマンドディスクリプタＩＤに対する基準がサーバルートではなくコマンドルートノードに存在することである。
【図面の簡単な説明】
【図１】  ＭＰＥＧ−４クライアントすなわち端末の全体に亘る構造を示す図である。
【図２】  ＭＰＥＧ−４システムデコーダモデルを示す。
【図３】  オブジェクトディスクリプタ及び基本ストリームディスクリプタを通じてオーディオビジュアルオブジェクトを他のストリームの符号化データに関連させるためにＭＰＥＧ−４で用いられる方法を示す。
【図４】  ＭＰＥＧ−４に基づく通信システムのクライアント／サーバの一般的な形態を示す。
【図５】  （ａ）サーバルート及び（ｂ）コマンドルートノードを用いてシーン描写ノード特にセンサノードをコマンドディスクリプタに関連させる方法を示す。
【図６】  好適な実施の形態で説明したコマンドディスクリプタの２値シンタックスを示す。
【図７】  好適な実施の形態で説明したコマンドディスクリプタ除去コマンドの２値シンタックスを示す。
【図８】  サーバルート構造の２値シンタックス及びそれをメインＭＰＥＧ−４  ＢＩＦＳシーンシンタックスに付加する方法を示す。
【図９】  コマンドルート構造のノードシンタックス及びセマンティックを示す。
【図１０】  予め規定されたコマンドＩＤ及びそれに関連した解釈のリストを示す。
【図１１】  好適な実施の形態に対するコマンドディスクリプタに含まれるコマンドの２値シンタックスを示す。
【図１２】  サーバルートが用いられる場合のＭＰＥＧ−４クライアントのサーバコマンドをトリガするプロセスを示す流れ図である。
【図１３】  サーバルートが用いられる場合のサーバに戻されたコマンドに配置すべきデータのアセンブルのプロセスの流れ図である。
【図１４】  コマンドルートノードが用いられる場合のＭＰＥＧ−４に含まれるサーバコマンドをトリガするプロセスの流れ図である。
【図１５】  コマンドルートノードが用いられる場合のサーバに戻されたコマンドに配置すべきデータのアセンブルのプロセスの流れ図である。
【図１】
0004194240.tif 000002
【図２】
0004194240.tif 000003
【図３】
0004194240.tif 000004
【図４】
0004194240.tif 000005
【図５】
0004194240.tif 000006
【図６】
0004194240.tif 000007
【図７】
0004194240.tif 000008
【図８】
0004194240.tif 000009
【図９】
0004194240.tif 000010
【図１０】
0004194240.tif 000011
【図１１】
0004194240.tif 000012
【図１２】
0004194240.tif 000013
【図１３】
0004194240.tif 000014
【図１４】
0004194240.tif 000015
【図１５】
0004194240.tif 000016