(57)【要約】      （修正有）【課題】Ｅｕｒｏｐｅａｎ  ＤＶＢネットワークにおいてＭＰＥＧ−４データ放送受信のためにＵＲＩポインタシステムを伝送する。【解決手段】ＤＶＢ−Ｍｕｌｔｉｍｅｄｉａ  Ｈｏｍｅ  Ｐｌａｔｅｆｏｒｍ（ＭＨＰ）ターミナルで、パケット化されたＤＳＭ−ＣＣ  Ｕ−Ｕ  ＯＣを備えたＭＰＥＧ−２ＴＳを受信し、ＴＳ内のＵＲＩを探し出し、そのＵＲＩに応じて、そのＤＳＭ−ＣＣ  Ｕ−Ｕ  ＯＣ内のアドレスにアクセスし、そのアドレスへのアクセスに応じて、そのＤＳＭ−ＣＣ  Ｕ−Ｕ  ＯＣからＦＳＭＰＥＧ−４リソースを検索し、そのＭＰＥＧ−４リソースを復号する。ｌｉｄＵＲＩはバインディングネームとアクセススキームをそのＤＳＭ−ＣＣ  Ｕ−Ｕ  ＯＣ内のオブジェクトに提供する。すなわち、ｌｉｄＵＲＩは、ＢＩＦＳシーン記述ストリーム又はオブジェクト記述ストリームなどのＭＨＰ  ＯＣ内のリソースを探し出し、初期オブジェクト記述子（ＩＯＲ）が埋め込まれる。【選択図】  図８
2005167981.tif 000002
【特許請求の範囲】
【請求項１】
Ｅｕｒｏｐｅａｎ  Ｄｉｇｉｔａｌ  Ｖｉｄｅｏ  Ｂｒｏａｄｃａｓｔｉｎｇ（ＤＶＢ）ネットワークで放送されるＭＰＥＧ−４データリソースを受信するための方法であって、
ＤＶＢ−マルチメディアホームプラットホーム（ＭＨＰ）ターミナルで、パケット化されたＤＳＭ−ＣＣユーザ対ユーザ（Ｕ−Ｕ）オブジェクトカルーセル（ＯＣ）を備えたＭＰＥＧ−２トランスポートストリーム（ＴＳ）を受信し、
前記ＴＳ内のユニバーサルリソース識別子（ＵＲＩ）を探し出し、
前記ＵＲＩに応じて、前記ＤＳＭ−ＣＣ  Ｕ−Ｕ  ＯＣ内のアドレスにアクセスし、
前記アドレスにアクセスすることに応じて、ＭＰＥＧ−４リソースを前記ＤＳＭ−ＣＣ  Ｕ−Ｕ  ＯＣから検索し、
前記ＭＰＥＧ−４リソースを復号する、
ことを有する方法。
【請求項２】
前記ＵＲＩに応じてアドレスにアクセスすることが、ローカル識別子（ｌｉｄ）及び前記ＤＳＭ−ＣＣ  Ｕ−Ｕ  ＯＣ内のｈｔｔｐアドレスを含むグループから選択されたアドレスにアクセスすることを含む請求項１に記載の方法。
【請求項３】
アドレスにアクセスすることが、ＭＨＰプロトコル（ＭＨＰ  ＯＣ）によって規定且つ制限されるように、前記ＤＳＭ−ＣＣ  Ｕ−Ｕ  ＯＣ中のオブジェクトにバインディングネーム及びアクセススキームを提供するｌｉｄＵＲＩにアクセスすることを含む請求項２に記載の方法。
【請求項４】
ｌｉｄＵＲＩを使用して、前記ＭＨＰ  ＯＣ中のオブジェクトにバインディングネーム及びアクセススキームを提供することが、初期オブジェクト記述子（ＩＯＤ）に埋め込まれたｌｉｄ  ＵＲＩを使用して、ＢＩＦＳシーン記述ストリーム及びオブジェクト記述ストリームを含むグループから選択された前記ＭＨＰ  ＯＣ中のリソースを探し出すことを含む請求項３に記載の方法。
【請求項５】
パケット化されたＭＨＰ  ＯＣを備えたＭＰＥＧ−２ＴＳを受信することが、階層ディレクトリ構造にＭＰＥＧ−４リソースを形成することを含む請求項４に記載の方法。
【請求項６】
階層ディレクトリ構造を形成することが、ＤＳＭ：：ＳｅｒｖｉｃｅＧａｔｅｗａｙ、ＤＳＭ：：Ｄｉｒｅｃｔｏｒｙ、ＤＳＭ：：Ｓｔｒｅａｍ及びＤＳＭ：：Ｆｉｌｅを含むＢＩＯＰオブジェクトの階層ディレクトリ構造を形成することを含む請求項５に記載の方法。
【請求項７】
前記アドレスにアクセスすることに応じて、前記ＭＨＰ  ＯＣからＭＰＥＧ−４リソースを検索するこが、
ＤＳＩメッセージを探し出し、
前記Ｓｅｒｖｉｃｅ  ＧａｔｅｗａｙのためのＩＯＲを抽出し、
Ｓｅｒｖｉｃｅ  Ｇａｔｅｗａｙオブジェクトを解析し、
Ｓｅｒｖｉｃｅ  Ｇａｔｅｗａｙバインディング構造からＤｉｒｅｃｔｏｒｙオブジェクト、Ｓｔｒｅａｍオブジェクト、及びＦｉｌｅオブジェクトのためのＩＯＲを抽出し、
前記ＳｔｒｅａｍオブジェクトとＦｉｌｅオブジェクトからＭＰＥＧ−４リソースを獲得することを含む請求項６に記載の方法。
【請求項８】
請求項３に記載の方法であって、
パケット化されたＭＨＰ  ＯＣを備えたＭＰＥＧ−２ＴＳを受信することが、第１のＭＰＥＧ−２ＴＳ及びパケット化されたＭＨＰ  ＯＣを備えた第２のＭＰＥＧ−２ＴＳを受信することを含み、
前記ＴＳ内のＵＲＩを探し出すことが、前記第１のＭＰＥＧ−２ＴＳ内のｌｉｄＵＲＩを検索することを含み、
前記ｌｉｄＵＲＩにアクセスすることに応じて、前記ＭＨＰ  ＯＣから前記ＭＰＥＧ−４リソースを検索することが、前記第２のＭＰＥＧ−２ＴＳ  ＭＨＰ  ＯＣからＭＰＥＧ−４リソースを検索することを含む請求項６に記載の方法。
【請求項９】
前記アドレスにアクセスすることに応じて、ＭＨＰ  ＯＣからＭＰＥＧ−４リソースを検索することが、オーディオデータ、ビデオデータ及びシステムデータを含むグループから選択されたＭＰＥＧ−４リソースを検索することを含む請求項１に記載の方法。
【請求項１０】
前記ＭＰＥＧ−４リソースを復号することが、前記ＭＰＥＧ−２ＴＳ内のオーディオデータをエンハンスすること、ＭＰＥＧ−２ＴＳ内のビデオデータをエンハンスすること並びにシステムデータを使用して、対話型オーディオビジュアルシーン及び通信リンクを確立することを含むグループから選択された処理を含む請求項９に記載の方法。
【請求項１１】
ＭＰＥＧ−４システムデータを復号することに応じて、対話型オーディオビジュアルシーン及び通信リンクを確立することをさらに有する請求項１０に記載の方法。
【請求項１２】
前記検索されたＭＰＥＧ−４リソースをキャッシュ保持することをさらに有する請求項１に記載の方法。
【請求項１３】
請求項３に記載の方法であって、
前記ＵＲＩに応じて、アドレスにアクセスすることが、ローカルキャッシュアドレス及びウェブプロトコル識別子を含むグループから選択されたアドレスにさらにアクセスすることを含み、
前記方法が、さらに、
前記アドレスにアクセスすることに応じて、ローカルキャッシュ及びウェッブサイトを含むグループから選択されたソースからＭＰＥＧ−４リソースを検索することを有する請求項３に記載の方法。
【請求項１４】
Ｅｕｒｏｐｅａｎ  Ｄｉｇｉｔａｌ  Ｖｉｄｅｏ  Ｂｒｏａｄｃａｓｔｉｎｇ（ＤＶＢ）ネットワークでＭＰＥＧ−４データへのポインターを放送するための方法であって、
ＤＳＭ−ＣＣユーザ対ユーザ（Ｕ−Ｕ）オブジェクトカルーセル（ＯＣ）にＭＰＥＧ−４リソースを埋め込み、
前記ＤＳＭ−ＣＣ  Ｕ−Ｕ  ＯＣをＭＰＥＧ−２トランスポートストリーム（ＴＳ）にパケット化し、
前記ＤＳＭ−ＣＣ  Ｕ−Ｕ  ＯＣ中のアドレスに存在するＭＰＥＧ−４リソースにアクセスするためのユニバーサルリソース識別子（ＵＲＩ）を生成し、
前記ＵＲＩをＭＰＥＧ−２ＴＳに埋め込み、
パケット化されたＤＳＭ−ＣＣ  Ｕ−Ｕ  ＯＣを備えたＭＰＥＧ−２ＴＳを放送する
ことを有する前記方法。
【請求項１５】
前記ＭＰＥＧ−４リソースにアクセスするためのＵＲＩを生成することが、ｈｔｔｐアドレス及びローカル識別子（ｌｉｄ）を含むグループから選択されたＵＲＩを生成することを含む請求項１４に記載の方法。
【請求項１６】
アドレスに存在するＭＰＥＧ−４リソースにアクセスするためのＵＲＩを生成することが、ＭＨＰプロトコル（ＭＨＰ  ＯＣ）によって規定及び制限されるように、前記ＤＳＭ−ＣＣ  Ｕ−Ｕ  ＯＣ中のオブジェクトにバインディングネーム及びアクセススキームを供給するためにｌｉｄＵＲＩを生成することを含む請求項１５に記載の方法。
【請求項１７】
前記ＤＳＭ−ＣＣ  Ｕ−Ｕ  ＯＣ中のオブジェクトにバインディングネーム及びアクセススキームを供給するためにｌｉｄＵＲＩを生成することが、ＢＩＦＳシーン記述ストリーム及びオブジェクト記述子ストリームを含むグループから選択された、前記ＭＨＰ  ＯＣ中のリソースを探し出すために初期オブジェクト記述子（ＩＯＤ）に埋め込まれたｌｉｄＵＲＩを生成することを含む請求項１６に記載の方法。
【請求項１８】
ＭＨＰ  ＯＣにＭＰＥＧ−４リソースを埋め込むことが、ＭＰＥＧ−４リソース階層ディレクトリ構造を形成することを含む請求項１７に記載の方法。
【請求項１９】
階層ディレクトリ構造を形成することが、ＤＳＭ：：ＳｅｒｖｉｃｅＧａｔｅｗａｙ、ＤＳＭ：：Ｄｉｒｅｃｔｏｒｙ、ＤＳＭ：：Ｓｔｒｅａｍ及びＤＳＭ：：Ｆｉｌｅを含むＢＩＯＰオブジェクトの階層ディレクトリ構造を形成することを含む請求項１８に記載の方法。
【請求項２０】
前記ＭＨＰ  ＯＣにＭＰＥＧ−４リソースを埋め込むことが、
Ｆｉｌｅオブジェクト及びＳｔｒｅａｍオブジェクトに前記ＭＰＥＧ−４リソースをロードすること、
Ｄｉｒｅｃｔｏｒｙオブジェクト、Ｓｔｒｅａｍオブジェクト及びＦｉｌｅオブジェクトのためのＩＯＲを作成すること、
前記ＩＯＲをＳｅｒｖｉｃｅ  Ｇａｔｅｗａｙにおいてバインドすること、
前記Ｓｅｒｖｉｃｅ  ＧａｔｅｗａｙのためのＩＯＲを作成すること、及び
前記Ｓｅｒｖｉｃｅ  Ｇａｔｅｗａｙ  ＩＯＲをＤＳＩメッセージで探し出すことを含む請求項２０に記載の方法。
【請求項２１】
前記ＵＲＩをＭＰＥＧ−２ＴＳ中に埋め込むことが、第１のＭＰＥＧ−２ＴＳ内のｌｉｄＵＲＩを探し出すことを含み、
ＭＰＥＧ−２ＴＳ中に前記ＭＨＰ  ＯＣをパケット化することが、第２のＭＰＥＧ−２ＴＳによって伝送されたＭＨＰ  ＯＣ中の前記ＭＰＥＧ−４リソースをパケット化することを含み、
前記ＭＰＥＧ−２ＴＳを放送することが、前記第１及び第２のＭＰＥＧ−２ＴＳを放送することを含む請求項１７に記載の方法。
【請求項２２】
ＭＨＰ  ＯＣにＭＰＥＧ−４リソースを埋め込むことが、オーディオデータ、ビデオデータ及びシステムデータを含むグループから選択されたＭＰＥＧ−４リソースを埋め込むことを含む請求項１４に記載の方法。
【請求項２３】
ＭＨＰ  ＯＣにＭＰＥＧ−４リソースを埋め込むことが、前記ＭＰＥＧ−２ＴＳ中のエンハンスされたオーディオデータ、前記ＭＰＥＧ−２ＴＳ中のエンハンスされたビデオデータ並びに対話型オーディオビジュアルシーン及び通信リンクを確立するためのシステムデータを含むグループから選択された目的のために使用されるリソースを含む請求項２２に記載の方法。
【請求項２４】
ウェッブサイト及びローカル（受信機）キャッシュからそれぞれＭＰＥＧ−４リソースにアクセスするためのｈｔｔｐアドレス及びローカル（受信機）キャッシュアドレスを含むグループから選択された追加のＵＲＩアドレスを生成することをさらに有する請求項１４に記載の方法。
【請求項２５】
放送ＭＰＥＧ−４データリソースを受信するためのＥｕｒｏｐｅａｎ  Ｄｉｇｉｔａｌ  Ｖｉｄｅｏ  Ｂｒｏａｄｃａｓｔｉｎｇ（ＤＶＢ）マルチメディアホームプラットホーム（ＭＨＰ）ターミナルであって、前記システムは、
埋め込まれたユニホームリソース識別子（ＵＲＩ）及びパケット化されたＤＳＭ−ＣＣ  ユーザ対ユーザ（Ｕ−Ｕ）オブジェクトカルーセル（ＯＣ）を備えたＭＰＥＧ−２トランスポートストリーム（ＴＳ）を受け入れるためのインタフェースを有する受信機と、
前記受信機から前記ＭＰＥＧ−２ＴＳを受け入れるためのインタフェースを有するアドレスアクセスユニットであって、該アドレスアクセスユニットは、前記ＴＳ中のＵＲＩを探し出し、アドレスにアクセスし、ＭＰＥＧ−４リソースを該ＤＳＭ−ＣＣ  Ｕ−Ｕ  ＯＣから検索する該アドレスアクセスユニットと、
前記ＭＰＥＧ−４リソースを受信する前記アドレスアクセスユニットに接続されたインタフェース及び復号化されたＭＰＥＧ−４情報を供給するインタフェースを有する復号器と、
を有するシステム。
【請求項２６】
前記アドレスアクセスユニットが、ｈｔｔｐアドレス及びローカル識別子（ｌｉｄ）を含むグループから選択されたＵＲＩを探し出す請求項２５に記載のシステム。
【請求項２７】
前記アドレスアクセスユニットが、ＭＨＰプロトコル（ＭＨＰ  ＯＣ）によって規定及び制限されているように、前記ＤＳＭ−ＣＣ  Ｕ−Ｕ  ＯＣ中のオブジェクトにバインディングネーム及びアクセススキームを提供するｌｉｄＵＲＩにアクセスする請求項２６に記載のシステム。
【請求項２８】
前記アドレスアクセスユニットが、初期オブジェクト記述子（ＩＯＤ）中に埋め込まれたｌｉｄＵＲＩを使用して、ＢＩＦＳシーン記述ストリーム及びオブジェクト記述子ストリームを含むグループから選択された前記ＭＨＰ  ＯＣ中のリソースを探し出す請求項２７に記載のシステム。
【請求項２９】
前記アドレスアクセスユニットが、階層ディレクトリ中のＭＰＥＧ−４リソースにアクセスする請求項２８に記載のシステム。
【請求項３０】
前記アドレスアクセスユニットが、ＤＳＭ：：ＳｅｒｖｉｃｅＧａｔｅｗａｙ、ＤＳＭ：：Ｄｉｒｅｃｔｏｒｙ、ＤＳＭ：：Ｓｔｒｅａｍ及びＤＳＭ：：Ｆｉｌｅを含むＢＩＯＰオブジェクトの階層ディレクトリ構造を形成する請求項２９に記載のシステム。
【請求項３１】
前記アドレスアクセスユニットが、前記ＭＨＰ  ＯＣからＭＰＥＧ−４リソースを下記のように検索する請求項３０に記載のシステムであって、
ＤＳＩメッセージを探し出し、
前記Ｓｅｒｖｉｃｅ  Ｇａｔｅｗａｙのための前記ＩＯＲを抽出し、
前記Ｓｅｒｖｉｃｅ  Ｇａｔｅｗａｙオブジェクトを解析し、
前記Ｓｅｒｖｉｃｅ  Ｇａｔｅｗａｙバインディング構造からＤｉｒｅｃｔｏｒｙオブジェクト、Ｓｔｒｅａｍオブジェクト及びＦｉｌｅオブジェクトのためのＩＯＲを抽出し、
前記Ｓｔｒｅａｍオブジェクト及びＦｉｌｅオブジェクトからＭＰＥＧ−４リソースを獲得する請求項３０に記載のシステム。
【請求項３２】
前記受信機が、パケット化されたＭＨＰ  ＯＣを備えた第１のＭＰＥＧ−２ＴＳ及び第２のＭＰＥＧ−２ＴＳを受信し、
前記アドレスアクセスユニットが、前記第１のＭＰＥＧ−２ＴＳからｌｉｄＵＲＩを検索し、前記第２のＭＰＥＧ−２ＴＳ中の前記ＭＨＰ  ＯＣからＭＰＥＧ−４リソースを検索する請求項２７に記載のシステム。
【請求項３３】
前記アドレスアクセスユニットが、オーディオ、ビデオ及びシステムデータを含むグループから選択されたＭＰＥＧ−４リソースを検索する請求項２５に記載のシステム。
【請求項３４】
前記復号器が、前記ＭＰＥＧ−２ＴＳ中のオーディオデータをエンハンスすること、前記ＭＰＥＧ−２ＴＳ中のビデオデータをエンハンスすること並びに対話型オーディオビジュアルシーン及び通信リンクを確立するための前記システムデータを使用することを含むグループから選択されたＭＰＥＧ−４情報を供給する請求項３５に記載のシステム。
【請求項３５】
さらに、送信インタフェースを有する送信機を有し、
前記送信機及び受信機が、ＭＰＥＧ−４システムデータを復号することに応じて、対話型オーディオビジュアルシーン及び通信リンクを形成する請求項３４に記載のシステム。
【請求項３６】
保存のための検索されたＭＰＥＧ−４リソースを受信するためのインタフェースを有するローカルキャッシュをさらに有する請求項２５に記載のシステム。
【請求項３７】
前記アドレスアクセスユニットが、ローカルキャッシュアドレス及びウェッブプロトコル識別子を含むグループから選択されたアドレスにアクセスし、該アドレスにアクセスすることに応じて、ローカルキャッシュ及びネットワーク接続されたウェッブサイトを含むグループから選択されたソースからＭＰＥＧ−４リソースを検索する請求項２６に記載のシステム。
【請求項３８】
ＭＰＥＧ−４リソースを送信するためのＥｕｒｏｐｅａｎ  Ｄｉｇｉｔａｌ  Ｖｉｄｅｏ  Ｂｒｏａｄｃａｓｔｉｎｇ（ＤＶＢ）システムであって、前記システムは、
ＤＳＭ−ＣＣ  ユーザ対ユーザ（Ｕ−Ｕ）オブジェクトカルーセル（ＯＣ）に埋め込まれたＭＰＥＧ−４リソースをアクセスするためのユニホームリソース識別子（ＵＲＩ）をＭＰＥＧ−２トランスポートストリーム（ＴＳ）に供給し、前記パケット化されたＤＳＭ−ＣＣ  Ｕ−Ｕ  ＯＣをＭＰＥＧ−２ＴＳに供給するためのインタフェースを有するアドレスポインターユニット（ＡＰＵ）と、
前記アドレスポインターユニットから前記パケット化されたＤＳＭ−ＣＣ  Ｕ−Ｕ  ＯＣを備えた前記ＭＰＥＧ−２ＴＳを受け入れるインタフェース及び前記ＭＰＥＧ−２ＴＳを放送するためのインタフェースを有する送信機と、
を有するシステム。
【請求項３９】
前記ＡＰＵが、ｈｔｔｐアドレス及びローカル識別子（ｌｉｄ）を含むグループから選択されたＵＲＩを備えたＭＰＥＧ−２ＴＳを供給する請求項３８に記載のシステム。
【請求項４０】
前記ＡＰＵが、ＭＨＰプロトコル（ＭＨＰ  ＯＣ）によって規定及び制限されるように、前記ＤＳＭ−ＣＣ  Ｕ−Ｕ  ＯＣ中のオブジェクトにバインディングネーム及びアクセススキームを供給するためのｌｉｄＵＲＩを生成する請求項３９に記載のシステム。
【請求項４１】
前記ＡＰＵが、初期オブジェクト記述子（ＩＯＤ）中に埋め込まれたｌｉｄＵＲＩを生成して、ＢＩＦＳシーン記述ストリーム及びオブジェクト記述子ストリームを含むグループから選択された前記ＭＨＰ  ＯＣ中のリソースを探し出す請求項４０に記載のシステム。
【請求項４２】
前記ＡＰＵが、階層ディレクトリ構造にＭＰＥＧ−４リソースを形成することにより、ＭＨＰ  ＯＣにＭＰＥＧ−４リソースを埋め込む請求項４１に記載のシステム。
【請求項４３】
前記ＡＰＵが、ＤＳＭ：：ＳｅｒｖｉｃｅＧａｔｅｗａｙ、ＤＳＭ：：Ｄｉｒｅｃｔｏｒｙ、ＤＳＭ：：Ｓｔｒｅａｍ及びＤＳＭ：：Ｆｉｌｅを含むＢＩＯＰオブジェクトの階層ディレクトリ構造を形成する請求項４２に記載の方法。
【請求項４４】
前記ＡＵＰが、前記ＭＨＰ  ＯＣにＭＰＥＧ−４リソースを下記のように埋め込む請求項４３に記載のシステムであって、
Ｆｉｌｅオブジェクト及びＳｔｒｅａｍオブジェクトに前記ＭＰＥＧ−４リソースをロードし、
Ｄｉｒｅｃｔｏｒｙオブジェクト、Ｓｔｒｅａｍオブジェクト、及びＦｉｌｅオブジェクトのためのＩＯＲを作成し、
Ｓｅｒｖｉｃｅ  Ｇａｔｅｗａｙ中に前記ＩＯＲをバインドし、
Ｓｅｒｖｉｃｅ  ＧａｔｅｗａｙのためのＩＯＲを作成し、
ＤＳＩメッセージ中の前記Ｓｅｒｖｉｃｅ  Ｇａｔｅｗａｙ  ＩＯＲを探し出す請求項４３に記載のシステム。
【請求項４５】
前記ＡＵＰが、第１のＭＰＥＧ−２ＴＳ中のｌｉｄＵＲＩを探し出し、第２のＭＰＥＧ−２ＴＳ中にパケット化されたＭＨＰ  ＯＣにＭＰＥＧ−４リソースを埋め込み、
前記送信機が、前記第１及び第２のＭＰＥＧ−２ＴＳを放送する請求項３９に記載のシステム。
【請求項４６】
前記ＡＵＰが、オーディオデータ、ビデオデータ及びシステムデータを含むグループから選択されたＭＨＰ  ＯＣにＭＰＥＧ−４リソースを埋め込む請求項３８に記載のシステム。
【請求項４７】
前記ＡＵＰが、ウェッブサイト及びローカル（受信機）キャッシュからそれぞれＭＰＥＧ−４リソースにアクセスするためのｈｔｔｐアドレス及びローカル（受信機）キャッシュアドレスを含むグループから選択された、前記ＭＰＥＧ−２ＴＳに埋め込まれた追加のＵＲＩアドレスを生成する請求項３８に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般的には、ディジタル画像及びデータトランスポートプロセスに関し、より詳細には、ユニフォームリソース表示子（ＵＲＩ）システム及びＭＰＥＧ−４データをＥｕｒｏｐｅａｎ  Ｄｉｇｉｔａｌ  Ｖｉｄｅｏ  Ｂｒｏａｄｃａｓｔｉｎｇ  ＭＰＥＧ−２トランスポートストリーム（ＴＳ）で伝送する方法に関する。
【０００２】
［関連出願］
本願は、代理人整理願号Ｎｏ．ＳＬＡ１３２５、２００３年９月２５日に提出された、願番Ｎｏ．１０／６７０，９４６、カイ−チェー  リァンにより発明された、発明の名称が、ＵＲＩポインターシステム及びＭＰＥＧ−４データをＭＰＥＧ−２トランスポートストリームで伝送する方法、である、係属中の出願の一部継続出願である。
【背景技術】
【０００３】
ディジタルビデオ放送システムは、例えば、Ｅｕｒｏｐｅａｎ  Ｄｉｇｉｔａｌ  Ｖｉｄｅｏ  Ｂｒｏａｄｃａｓｔｉｎｇ（ＤＶＢ）及びＡｍｅｒｉｃａｎ  Ａｄｖａｎｃｅｄ  Ｔｅｌｅｖｉｓｉｏｎ  Ｓｙｓｔｅｍｓ  Ｃｏｍｍｉｔｔｅｅ（ＡＴＳＣ）のように、共通のＭＰＥＧ−２符号化システムに基づくものである。ＭＰＥＧ−２は、高解像ビデオ、マルチチャンネルオーディオ、また、画期的な新しいマルチメディアデータ及び対話型サービスなどの機能さえ提供するものである。
【０００４】
一方、ＩＳＯ及びＩＥＣが、次世代オーディオビジュアル規格として、ＩＳＯ／ＩＥＣ１４４９６  ＭＰＥＧ−４を共同開発している。ＭＰＥＧ−４は、ＭＰＥＧ−２よりも優れた圧縮効率と、オーディオビジュアル対話機能、著作権保護、及び、ディジタルテレビジョン放送を向上させることができかつ新しいアプリケーションを実現するその他の機能などの新しい機能とを提供する。ＤＶＢなどの放送規格に基づいたＭＰＥＧ−２とＭＰＥＧ−４技術との調和は、今後のディジタルテレビジョン放送を向上させるためには重要である。ＭＰＥＧ−２放送とＭＰＥＧ−４規格との調和は、トランスポートレイヤ及びアプリケーションレイヤなどのレイヤの調和を含まなければならない。
【０００５】
トランスポートレイヤの整合化は、この試みの基礎をなすものである。具体的には、シーン及びそれに関連するストリームを含めたＭＰＥＧ−４データエレメントを、ＭＰＥＧ−２放送が指定するトランスポートレイヤプロトコルによって伝送するのを可能にするための手段を見つけ出さなければならない。ヨーロッパのＤＶＢまたはアメリカのＡＴＳＣなどのＭＰＥＧ−２放送システムは、いくつかを挙げれば、ＭＰＥＧ−２トランスポートストリーム、ＤＳＭ−ＣＣデータカルーセル、ＤＳＭ−ＣＣユーザ対ユーザ（Ｕ−Ｕ）オブジェクトカルーセル及びインターネットプロトコルなどを含むトランスポートプロトコルを定義している。ＭＰＥＧ−２トランスポートストリームは、その他のほとんどのプロトコルの基礎となるレイヤである。したがって、ＭＰＥＧ−２トランスポートを使用してＭＰＥＧ−４データを伝送することは、解決すべき重要な問題である。
【０００６】
ＩＳＯ／ＩＥＣは、ＩＳＯ／ＩＥＣ１３８１８−１の仕様において、ＭＰＥＧ−４コンテンツをＭＰＥＧ−２トランスポートストリームで伝送するための方法（４ｏｎ２として知られている）を指定している。ＭＰＥＧ−４コンテンツは、オブジェクト記述子ストリーム、シーン記述ストリーム、オーディオストリーム、ビデオストリーム、ＩＰＭＰストリームなどの初期オブジェクト記述子及び可変数ストリームからなる。仕様（ＩＳＯ／ＩＥＣ１３８１８−１）は、それぞれのＭＰＥＧ−４ストリームが、ＳＬパケット化ストリーム内に含まれ、また、オプションとして、ＦｌｅｘＭｕｘストリーム内に多重化されてもよいことを要求しており、ＳＬパケット化ストリーム及びＦｌｅｘＭｕｘストリームの両方とも、ＩＳＯ／ＩＥＣ１４４９６−１に定義されている。ＳＬパケット化ストリームまたはＦｌｅｘＭｕｘストリームは、トランスポートストリームパケット化及び多重化される前に、ＭＰＥＧ−２パケット化エレメンタリーストリーム（ＰＥＳ）パケット内かまたはＩＳＯ＿ＩＥＣ＿１４４９６＿ｓｅｃｔｉｏｎ内のいずれかにカプセル化される。
【０００７】
ＩＳＯ／ＩＥＣ１３８１８−１は、ＩＳＯ／ＩＥＣ１３８１８−１トランスポートストリームで伝送されたＩＳＯ／ＩＥＣ１４４９６オーディオビジュアルシーン及びそれに関連するストリームのためのカプセル化及び信号伝達アプローチを指定している。その手順を以下に要約する。
【０００８】
トランスポートストリームで伝送されたプログラムに関連するＭＰＥＧ−４コンテンツは、そのプログラムのプログラムマップテーブルによって参照されなければならない。プログラムマップテーブルは、表１に示されている。
【０００９】
初期オブジェクト記述子（ＩＯＤ）は、ＩＳＯ／ＩＥＣ１４４９６−１シーンを定義するために使用されなければならない。関連するすべてのＭＰＥＧ−４ストリームへの初期アクセスポイントの役割を果たす初期オブジェクト記述子は、そのシーンが関連されたプログラムのプログラムマップテーブル内のｐｒｏｇｒａｍ＿ｉｎｆｏ＿ｌｅｎｇｔｈフィールドのすぐ後に続く記述子ループ内に配置されたＩＯＤ記述子によって運ばれなければならない。
【００１０】
ＩＯＤは、プログラムを構成するシーン記述及びオブジェクト記述子ストリームを識別するＥＳ＿Ｄｅｓｃｒｉｐｔｏｒを含む。また、ＩＯＤは、例えば１つ以上の関連するＩＰＭＰまたはＯＣＩストリームを識別するＥＳ＿Ｄｅｓｃｒｉｐｔｏｒを含んでもよい。
【００１１】
ＩＳＯ／ＩＥＣ１４４９６コンテンツのエレメントは、トランスポートストリーム内の固有のＰＩＤ値によって参照される１つ以上のＩＳＯ／ＩＥＣ１３８１８−１  ＭＰＥＧ−２プログラムエレメントによって運ばれてもよい。
【００１２】
ＰＩＤでＩＳＯ／ＩＥＣ１４４９６コンテンツを伝送することは、そのＰＩＤ値に関連するプログラムマップテーブル内の０ｘ１２または０ｘ１３のｓｔｒｅａｍ＿ｔｙｐｅ値によって信号伝達される。
【００１３】
ＳＬ記述子及びＦＭＣ記述子は、カプセル化されたＩＳＯ／ＩＥＣ１４４９６ストリームごとにＥＳ＿ＩＤを指定するために使用されなければならない。
【表１】
2005167981.tif 000003
【００１４】
図１は、ＭＰＥＧ−４コンテンツを再生するための手順（従来技術）を説明する図である。ＩＳＯ／ＩＥＣ１３８１８−１の仕様に従って、１３８１８−１トランスポートから受信されたＭＰＥＧ−４コンテンツを再生する、上述した手順を以下に説明する。
【００１５】
１．ＢＩＦＳシーンストリーム、オブジェクト記述子ストリーム、などのためのＥＳ＿Ｄｅｓｃｒｉｐｔｏｒを含む初期オブジェクト記述子（ＩＯＤ）を得る。
【００１６】
２．ＢＩＦＳ  ＥＳ＿Ｄｅｓｃｒｉｐｔｏｒは、検索すべきＢＩＦＳストリームのためのＥＳ＿ＩＤ及びオプションのユニバーサルリソースロケータ（ＵＲＬ）を含む。したがって、ＢＩＦＳストリームを検索するには、２つの方法がある。
【００１７】
ａ．ＥＳ＿ＩＤ及びＳＬ＿Ｄｅｓｃｒｉｐｔｏｒを使用する。ＥＳ＿ＩＤは、そのネームの範囲内にあるエレメンタリーストリームの固有のラベルの役割を果たし、ＳＬ＿Ｄｅｓｃｒｉｐｔｏｒは、ＥＳ＿ＩＤのためのＰＩＤを含む。ＰＩＤに関連するパケットからＢＩＦＳストリームを検索することができる。
【００１８】
ｂ．あるいは、ＥＳ＿Ｄｅｓｃｒｉｐｔｏｒが、ＵＲＬを含んでいれば、ＵＲＬによって指定されるロケーションからＢＩＦＳストリームを検索することができる。そして、検索されたストリームは、ＥＳ＿ＩＤに関連付けられる。
【００１９】
３．オブジェクト記述子ストリームに対してステップ２を反復する。
【００２０】
４．検索されたＢＩＦＳストリームを使用してＢＩＦＳシーンを組み立てる。
【００２１】
５．いくつかのＢＩＦＳノードが、オブジェクト記述子を介して、対応するエレメンタリーストリームリソースに関連付けられる。この関連付けは、オブジェクト記述子内のｏｂｊｅｃｔＤｅｓｃｒｉｐｔｏｒＩＤによって達成される。
【００２２】
ａ．オブジェクト記述子ストリーム内のオブジェクト記述子を探し出すためにｏｂｊｅｃｔＤｅｓｃｒｉｐｔｏｒＩＤを使用する。
【００２３】
ｂ．オブジェクト記述子は、エレメンタリーストリームのためのＥＳ＿Ｄｅｓｃｒｉｐｔｏｒを含まなければならない。
【００２４】
ステップ２を反復する。すなわち、エレメンタリーストリームを検索するために、ＥＳ＿ＩＤまたはＵＲＬを使用する。
【発明の開示】
【発明が解決しようとする課題】
【００２５】
指定されたＩＳＯ／ＩＥＣの手順の複雑さのために、ＭＰＥＧ−４システムをＭＰＥＧ−２トランスポートで伝送するために利用することのできる有効かつ完璧な手段は、これまでのところ存在しない。したがって、ＭＰＥＧ−４コンテンツをＭＰＥＧ−２トランスポートプロトコルに基づいて配信するための新しい方法を定義する必要がある。
【００２６】
既存のＤＶＢの方法論を使用してＭＰＥＧ−４データをＭＰＥＧ−２ＴＳで伝送するための手段が開発されれば、それは都合のよいことである。
【課題を解決するための手段】
【００２７】
本発明は、ユニフォーム参照表示子（ＵＲＩ）及びＤＳＭ−ＣＣユーザ対ユーザ（Ｕ−Ｕ）オブジェクトカルーセル（ＯＣ）に基づき、ＭＰＥＧ−４データをＭＰＥＧ−２ＴＳで伝送するための新しい方法を定義する。ユニフォーム参照ロケータ（ＵＲＬ）の参照が、ＭＰＥＧ−４データを送信するための代替となるアプローチとして、ＩＳＯ／ＩＥＣ１３８１８−１仕様に定義されているが、ＵＲＬを使用するための具体的な手段は、その仕様書には定義されていない。本発明は、その手段を定義し、ＩＳＯ／ＩＥＣ１３８１８−１規格に完全に適合する解決方法を提案する。この解決方法は、ＭＰＥＧ−４コンポーネントをＭＰＥＧ−２放送インフラストラクチャ内に取り込みかつ関連付けるのに順応性がありかつ効率的である。さらに、元来のＩＳＯ／ＩＥＣ方法及び新しく発明された方法は、同時に使用することができる。また、受信機は、獲得プロセスを迅速化し、かつ、データの再生を改善するために、取り込まれたデータをキャッシュすることも選択できる。
【００２８】
要約すれば、本発明は、ＭＰＥＧ−２規格とＭＰＥＧ−４規格とを調和し、ＭＰＥＧ−２ＯＣトランスポートプロトコルを使用することによって、シーン及びそれに関連するストリームを含むＭＰＥＧ−４データを伝送するためのアプローチを実現する。
【００２９】
したがって、Ｅｕｒｏｐｅａｎ  ＤＶＢネットワークで放送されたＭＰＥＧ−４データリソースを受信するために、方法が提供される。この方法は、ＤＶＢマルチ・ホーム・プラットホーム（ＭＨＰ）ターミナルでパケット化されたＤＳＭ−ＣＣ  Ｕ−Ｕ  ＯＣを備えたＭＰＥＧ−２ＴＳを受信し；前記ＴＳ中のＵＲＩを探し出し；前記ＵＲＩに応じて、ＤＳＭ−ＣＣ  Ｕ−Ｕ  ＯＣ内のアドレスにアクセスし；前記アドレスにアクセスすることに応じて、ＭＰＥＧ−４リソースをＤＳＭ−ＣＣ  Ｕ−Ｕ  ＯＣから検索し；及び、そのＭＰＥＧ−４リソースを復号することを有する。
【００３０】
アドレスをアクセスすることに関して、ｌｉｄＵＲＩは、ＭＨＰプロトコル（以下、ＭＨＰ  ＯＣと示す）によって規定および制限されるように、ＤＳＭ−ＣＣ  Ｕ−Ｕ  ＯＣ中のオブジェクトにバインディングネーム及びアクセススキームを提供する。うなわち、ＢＩＦＳシーン記述ストリーム又はオブジェクト記述子ストリームなどのＭＨＰ  ＯＣ中のリソースを探し出すために、ｌｉｄＵＲＩが初期オブジェクト記述子（ＩＯＤ）に埋め込まれる。そのＨＰＥＧ−４リソースは、ＤＳＭ：：ＳｅｒｖｉｃｅＧａｔｅｗａｙ、ＤＳＭ：：Ｄｉｒｅｃｔｏｒｙ、ＤＳＭ：：Ｓｔｒｅａｍ及びＤＳＭ：：Ｆｉｌｅを含むＢＩＯＰオブジェクトの階層ディレクトリ構造に形成される。
【００３１】
検索されたＭＰＥＧ−４リソースは、オーディオ、ビデオ及び／又はシステムデータであり得る。さらに、もしＭＰＥＧ−４オーディオ／ビデオストリームがＩＳＯ／ＩＥＣ１３８１８−１カプセル化規格に従ってＭＰＥＧ−２ＴＳに埋め込まれているなら、前記方法が使用されて、ＭＰＥＧ−４オーディオ／ビデオデータにアクセスすることができる。前記方法は、さらに、ＭＰＥＧ−２方法論を使用して、ＭＰＥＧ−２ＴＳからＭＰＥＧ−４オーディオ／ビデオストリームを検索すること、及び、前記検索されたＭＰＥＧ−４オーディオ／ビデオストリームと共にＡＴＳＣ  ＴＳＦＳから検索されたリソースを復号化することを有する。
【００３２】
上述した方法、放送方法、加えて対応受信機及び及び放送システムを以下に詳細に説明する。
【発明を実施するための最良の形態】
【００３３】
図２は、放送ＭＰＥＧ−４データリソースを受信するための本発明によるＥｕｒｏｐｅａｎ  Ｄｉｇｉｔａｌ  Ｖｉｄｅｏ  Ｂｒｏａｄｃａｓｔｉｎｇ（ＤＶＢ）Ｍｕｌｔｉｍｅｄｉａ  Ｈｏｍｅ  Ｐｌａｔｆｏｒｍ（ＭＨＰ）ターミナルの概略ブロック図である。システム２００は、パケット化されたＤＳＭ−ＣＣ  Ｕ−Ｕ  ＯＣと共に埋め込まれたＵＲＩを備えたＭＰＥＧ−２ＴＳを受け入れるための回線２０４に関するインタフェースを有する受信機２０２を備える。該図は単一のＴＳを示しているが、多数のＴＳも受信されることに注意されたい。また、該ＵＲＩが典型的には該ＤＳＭ−ＣＣ  Ｕ−Ｕ  ＯＣに埋め込まれていないことにも注意されたい。アドレスアクセスユニット２０６は、受信機２０２からＭＰＥＧ−２ＴＳを受け入れるために回線２０４に関するインタフェースを有する。アドレスアクセスユニット２０６（ＡＡＵ）は、ＴＳ中のＵＲＩを探し出し、アドレスにアクセスし、ＤＳＭ−ＣＣ  Ｕ−Ｕ  ＯＣからＭＰＥＧ−４リソースを検索する。復号器２０８は、ＭＰＥＧ−４リソースを受信するための、回線２１０に関してアドレスアクセスユニット２０６に連結したインタフェースと、復号化されたＭＰＥＧ−４情報を供給するための回線２１２に関するインタフェースとを有する。
【００３４】
本発明の脈絡において、アドレスアクセスユニット２０６は、ｈｔｔｐアドレス又はローカル識別子（ｌｉｄ）などのＵＲＩを探し出す。典型的には、ｌｉｄアドレスがアクセスされる。しかし、ｈｔｔｐアドレスをｌｉｄとして使用することは可能である。すなわち、もしファイルがｈｔｔｐアドレスでインデックスされている場合、ＤＳＭ−ＣＣ  Ｕ−Ｕ  ＯＣ中のファイルにアクセスするのにｈｔｔｐを使用することができる。ｌｉｄアドレスとしてｈｔｔｐアドレスを使用する利点は、もし何かの理由でＤＳＭ−ＣＣ  Ｕ−Ｕ  ＯＣが利用できないか、又は都合が悪い場合、システム２００は、例えばバックアップとしてウェッブサイトにアクセスすることを選択できる。
【００３５】
ＵＲＩが、形成されると、それらのＵＲＩは、ＭＰＥＧ−２ＴＳ内に埋め込まれる。形成されたこれらのＵＲＩは、ＭＰＥＧ−４システムを構築するために使用される。また、ＭＰＥＧ−４システムは、ＵＲＩなどの、様々なオーディオオブジェクト／ビデオオブジェクト／グラフィックオブジェクト（リソース）へのあらゆる種類のポインターを備えた対話型シーンも含むことができる。ＵＲＩは、ＤＳＭ−ＣＣ  Ｕ−Ｕ  ＯＣを用いて放送トランスポート内に埋め込まれた、あるいは、リモートサイトに配置された、キャッシュ内にすでに存在するリソース（オーディオ、ビデオ、システムデータ）を参照することができる。
【００３６】
コーデックシステムは、通常、システムデータリソース、ビデオリソース、及び、オーディオリソースを含む。ＭＰＥＧ−４において、システムデータ部分は、対話型オーディオビジュアルシーンを組み立てるために使用される。シーンは、オーディオ、ビデオ、グラフィック、ｈｔｍｌなどの（異なる形状を有する）多くのオブジェクトからなる。１つの例は、ソファーオブジェクト、椅子オブジェクト、テーブルオブジェクトなどからなる家のシーンである。ＭＰＥＧ−４システムは、対話型シーンを組み立てるのに使用されるので、シーンが１つのオブジェクトしか含まない場合でも、ＭＰＥＧ−４システムは必要とされる。
【００３７】
図３は、ｌｉｄＵＲＩを使用してＭＰＥＧ−４リソースにアクセスする手順を示す図である。ｌｉｄＵＲＩは、ＭＨＰプロトコルによって規定及び制限されているように、ＤＳＭ−ＣＣ  Ｕ−Ｕ  ＯＣ中のオブジェクトにバインディングネーム及びアクセススキームを提供する。ＭＨＰプロトコルをＭＨＰ  ＯＣとして参照する。もっと具体的には、アドレスアクセスユニットは、初期オブジェクト記述子（ＩＯＤ）に埋め込まれたｌｉｄＵＲＩを使用して、ＭＨＰ  ＯＣ中のリソースを探し出す。ＢＩＦＳシーン記述ストリーム及びオブジェクト記述子ストリームがアクセスされるのが示されている。
【００３８】
図４は、ＢＩＯＰディレクトリ及びファイルオブジェクトを示す図である。図を見て分かるように、アドレスアクセスユニットは、ＤＳＭ：：ＳｅｒｖｉｃｅＧａｔｅｗａｙ、ＤＳＭ：：Ｄｉｒｅｃｔｏｒｙ、ＤＳＭ：：Ｓｔｒｅａｍ及びＤＳＭ：：Ｆｉｌｅを含む放送インター−オブジェクトリクエストブローカープロトコル（ＢＩＯＰ：Ｉｎｔｅｒ−Ｏｂｊｅｃｔ  Ｒｅｑｕｅｓｔ  Ｂｒｏｋｅｒ  Ｐｒｏｔｏｃｏｌ）の階層ディレクトリ中のＭＰＥＧ−４リソースにアクセスする。
【００３９】
図５は、単純なＭＨＰ  ＯＣファイル構造を説明する図である。ＳＧは、Ｓｅｒｖｉｃｅ  Ｇａｔｅｗａｙで、ＤはＤｉｒｅｃｔｏｒｙで、ＳはＳｔｒｅａｍで、ＦはＦｉｌｅであることに注意されたい。アドレスアクセスユニットは、次のようにＭＨＰ  ＯＣからＭＰＥＧ−４リソースを検索する。第一に、ＤＳＩメッセージが探し出される。ＤＳＩはＤｏｗｎｌｏａｄＳｅｒｖｅｒＩｎｉｔｉａｔｅ（）である。ＤＳＩは、ＤＳＭ−ＣＣ  Ｕ−Ｕ  ＯＣに使用されるメッセージで、Ｓｅｒｖｉｃｅ  Ｇａｔｅｗａｙ（ファイルシステムのルートディレクトリ）のＩＯＲ（ポインターの一種）を放送する。次に、Ｓｅｒｖｉｃｅ  Ｇａｔｅｗａｙのためのインターオパラブルオブジェクトレファランス（ＩＯＲ）が抽出される。ＤＳＩからＳＧのＩＯＲが抽出されると、ＳＧが探し出され、検索される。Ｓｅｒｖｉｃｅ  Ｇａｔｅｗａｙオブジェクトが解析され、Ｓｅｒｖｉｃｅ  Ｇａｔｅｗａｙバインディング構造からＤｉｒｅｃｔｏｒｙオブジェクト、Ｓｔｒｅａｍオブジェクト、及びＦｉｌｅオブジェクトのためのＩＯＲが抽出される。最後に、ＭＰＥＧ−４リソースがＦｉｌｅオブジェクト及びＳｔｒｅａｍオブジェクトから獲得される。
【００４０】
図６は、ＭＨＰ  ＯＣファイルディレクトリの例を示す図である。
【００４１】
図２に戻り、アドレスアクセスユニットは、オーディオデータ、ビデオデータ、システムデータを含むＭＰＥＧ−４リソースをＭＨＰ  ＯＣから検索する。これらのリソースにより、復号器２０８は、ＭＰＥＧ−２ＴＳ中のエンハンスされたオーディオデータ及び／又はＭＰＥＧ−２ＴＳ中のエンハンスされたビデオデータなどのＭＰＥＧ−４情報を提供することができる。システムデータは、対話型オーディオビジュアルシーン及び通信リンクを確立するために使用される。
【００４２】
ＵＲＩ及びＭＰＥＧ−４リソースは、必ずしも同じＴＳで伝送される必要はないことを理解されるべきである。いくつかの態様において、受信機２０２は、第１のＭＰＥＧ−２ＴＳ及びパケット化されたＭＨＰ  ＯＣを備えた第２のＭＰＥＧ−２ＴＳを受信する。アドレスアクセスユニット２０６は、第１のＭＰＥＧ−２ＴＳからｌｉｄＵＲＩを検索し、第２のＭＰＥＧ−２ＴＳ中のＭＨＰ  ＯＣからＭＰＥＧ−４リソースを検索する。第１及び第２のＴＳは、同時に受信される必要はないことを理解されるべきである。他の態様において、両方のＴＳが、埋め込まれたＭＰＥＧ−４リソースと共にパケット化されたＭＨＰ  ＯＣを伝送する。すると、第１及び第２の両方のＴＳ中のＭＰＥＧ−４リソースを検索するのに第１のＴＳ中のＵＲＩが使用される。
【００４３】
他の態様において、システム２００は、さらに、回線２２２に関する送信インタフェースを有する送信機２２０を有する。送信機２２０及び受信機２０２は、ＭＰＥＧ−４システムデータを復号することに応じて、対話型オーディオビジュアルシーン及び通信リンクを形成するのに使用される。
【００４４】
他の態様において、システムは、さらに、ストレージから検索されたＭＰＥＧ−４リソースを受信するために回線２１０に関するインタフェースを有するローカルキャッシュ２２４を有する。これらのリソースは、引き続いて受信されたＴＳ中のＵＲＩ又は同じＴＳ中の引き続いて受信されたＵＲＩを使用してアクセスすることができる。例えば、アドレスアクセスユニット２０６は、ｌｉｄアドレスの代わりに又は追加して、ローカルキャッシュアドレス又はウェッブプロトコル識別子にアクセスすることができる。すると、ローカルキャッシュアドレスにアクセスすることに応じて、ＭＰＥＧ−４リソースがローカルキャッシュ２２４から検索される。もしＴＳに新しいＭＨＰ  ＯＣデータが受信されるたびに、ＡＡＵ２０６がディレクトリ全体を構築しなくてもいい場合、リソースを処理することが維持される。別には、ネットワークに連結されたウェッブサイトからＭＰＥＧ−４リソースをアクセスするのにウェッブプロトコル識別子又はｈｔｔｐアドレスが使用される。
【００４５】
図７は、ＭＰＥＧ−４データを送信するための本発明によるＥｕｒｏｐｅａｎ  Ｄｉｇｉｔａｌ  Ｖｉｄｅｏ  Ｂｒｏａｄｃａｓｔｉｎｇ（ＢＶＤ）システムの概略ブロック図である。システム６００は、ＤＳＭ−ＣＣ  Ｕ−Ｕ  ＯＣに埋め込まれたＭＰＥＧ−４リソースにアクセスするためのＵＲＩをＭＰＥＧ−２ＴＳに供給し、パケット化されたＤＳＭ−ＣＣ  Ｕ−Ｕ  ＯＣをＭＰＥＧ−２ＴＳに供給するために回線６０４に関するインタフェースを有するアドレスポインターユニット（ＡＰＵ）６０２を有する。ＡＰＵ６０２は、符号化されたＭＰＥＧ−２ＴＳ及びＭＰＥＧ−４リソースを回線６０５で受信する。いくつかの態様において、同じＴＳがＵＲＩ及びＤＳＭ−ＣＣ  Ｕ−Ｕ  ＯＣの両方を伝送する。送信機６０６は、アドレスポインターユニット６０２からパケット化されたＤＳＭ−ＣＣ  Ｕ−Ｕ  ＯＣと共にＭＰＥＧ−２ＴＳを受け入れるのに回線６０４に関するインタフェースを有する。送信機６０６は、ＭＰＥＧ−２ＴＳを放送するのに回線６０８に関するインタフェースを有する。
【００４６】
ＡＰＵ６０２は、ｈｔｔｐアドレス又はｌｉｄＵＲＩのいずれかをＭＰＥＧ−２ＴＳに供給する。上記のように、いくつかの態様において、（もしリソースファイルにラベルが適切に付けられているなら）ＤＳＭ−ＣＣ  Ｕ−Ｕ  ＯＣ中のＭＰＥＧ−４リソースにアクセスするのにｈｔｔｐアドレスがｌｉｄとして使用される。このように、ＡＰＵ６０２は、ＭＨＰプロトコル（ＭＨＰ  ＯＣ）によって強制かつ禁止されているように、ＤＳＭ−ＣＣ  Ｕ−Ｕ  ＯＣ中のオブジェクトにバインディングネーム及びアクセススキームを供給するのにｌｉｄＵＲＩを生成する。すなわち、ＡＰＵ６０２は、ＭＨＰ  ＯＣ中のＢＩＦＳシーン記述ストリーム及び／又はオブジェクト記述子ストリームリソースを探し出すのに初期オブジェクト記述子（ＩＯＤ）中に埋め込まれたｌｉｄＵＲＩを生成する（図３を参照）。
【００４７】
ＡＰＵ６０２は、ＤＳＭ：：ＳｅｒｖｉｃｅＧａｔｅｗａｙ、ＤＳＭ：：Ｄｉｒｅｃｔｏｒｙ、ＤＳＭ：：Ｓｔｒｅａｍ及びＤＳＭ：：Ｆｉｌｅを含むＢＩＯＰオブジェクトの階層ディレクトリ構造にＭＰＥＧ−４リソースを形成することによってＭＨＰ  ＯＣ中にＭＰＥＧ−４リソースを埋め込む（図４を参照）。ＡＰＵ６０２は、ＭＨＰ  ＯＣにＭＰＥＧ−４リソースを次のように埋め込む：  ＭＰＥＧ−４リソースがＳｔｒｅａｍオブジェクト及びＦｉｌｅオブジェクト中にロードされる；  Ｄｉｒｅｃｔｏｒｙオブジェクト、Ｓｔｒｅａｍオブジェクト及びＦｉｌｅオブジェクト用のＩＯＲが作成される；  ＩＯＲがＳｅｒｖｉｃｅ  Ｇａｔｅｗａｙ中にバインドされる；  Ｓｅｒｖｉｃｅ  Ｇａｔｅｗａｙ用にＩＯＲが作成される；  Ｓｅｒｖｉｃｅ  ＧａｔｅｗａｙＩＯＲがＤＳＩメッセージにおいて探し出される（図５を参照）。
【００４８】
典型的には、ＡＰＵ６０２は、オーディオ、ビデオ及びシステムデータなどのＭＰＥＧ−４リソースをＭＨＰ  ＯＣに埋め込む。いくつかの態様において、ＡＰＵ６０２は、第１のＭＰＥＧ−２ＴＳ中にｌｉｄＵＲＩを探し出し、第２のＭＰＥＧ−２ＴＳ中にパケット化されたＭＨＰ  ＯＣにＭＰＥＧ−４リソースを埋め込む。すると、送信機６０８は、第１及び第２のＭＰＥＧ−２ＴＳを放送する。上記に記したように、送信機６０８は、必ずしも、第１及び第２のＴＳを同時に放送する必要はない。さらに、第１のＴＳ中のＵＲＩは、（パケット化されたＭＨＰ  ＯＣを備えた）１つ以上のＴＳ中のリソースをポイントする。
【００４９】
別な態様において、ＡＰＵ６０２は、ウェッブサイト及びローカル（受信機）キャッシュのそれぞれからＭＰＥＧ−４リソースにアクセスするために、ｈｔｔｐアドレス及びローカル（受信機）キャッシュアドレスなどの、ＭＰＥＧ−２ＴＳに埋め込まれた追加のＵＲＩアドレスを生成する。
【００５０】
［機能説明］
図３に戻り説明すると、図示されていないが、オブジェクト記述子は、どこかほかの場所にある別のオブジェクト記述子を指示するオプションとしてのＵＲＩ（例えば、ｌｉｄアドレス）を有してもよいことに注意されたい。新しいオブジェクト記述子は、参照され、ＵＲＩストリングを伝送する元来のオブジェクト記述子のｏｂｊｅｃｔＤｅｓｃｒｉｐｔｏｒＩＤと関連付けられる。この技術は、エレメンタリーストリーム及びオブジェクト記述子の両方に適用することができる。
【００５１】
上述したように、エレメンタリーストリームを検索するための２つのＭＰＥＧ−４規格適合アプローチは、（１）トランスポートパケットで伝送されたデータのＥＳ＿ＩＤ及びそれに関連するＰＩＤを介するものであり、また、（２）ＩＰネットワークに関するような、どこかほかの場所に伝送されたストリームを参照するためのＵＲＩを介するものである。本発明は、ＩＳＯ／ＩＥＣ１３８１８−１仕様と適合性のあるＵＲＩポインター手段を定義する。本発明は、組織された組の中に存在するＭＰＥＧ−４プログラムエレメントを配信するためにオブジェクトカルーセルを使用し、トランスポートファイルシステムを構成する。ＯＣの１つの例は、ＤＳＭ−ＣＣ  ＯＣである。本発明は、ファイルシステムにおいて送信されるそれぞれのＭＰＥＧ−４リソースごとに固有のラベル（ＵＲＩアドレス）を関連付ける。ＵＲＩアドレス（ポインター）及びファイル構造は、送信されたＭＰＥＧ−４エレメントを検索するために使用される。
【００５２】
ＩＳＯ／ＩＥＣ１３８１８−６  ＤＳＭ−ＣＣ  Ｕ−Ｕオブジェクトカルーセルは、ＤＶＢ−ＭＨＰなどのＭＰＥＧ−２放送システムで使用するように指定されたいくつかのトランスポートプロトコルの中の１つである。それは、放送ネットワークにおいてＵ−Ｕオブジェクトの集合体（例えば、ディレクトリ、ファイル、ストリーム、など）を送信するための標準メカニズムを提供する。Ｕ−Ｕオブジェクトの組は、共同して、階層トランスポートファイルシステムを構成し、本発明において、その階層トランスポートファイルシステムは、シーン及び／またはストリームなどのＭＰＥＧ−４データをＭＰＥＧ−２ネットワークにおいて配信するための方法として使用される。
【００５３】
Ｕ−Ｕオブジェクトカルーセルのそれぞれのインスタンスは、個々のサービスドメインを表現し、カルーセルＮＳＡＰアドレス（ＩＳＯ／ＩＥＣ１３８１８−６仕様に定義されるように）と呼ばれる識別子によって一意的に識別される。それぞれのサービスドメインは、ファイルシステムのルートディレクトリを提供するためのサービスゲートウェイを有する。そのようなサービスドメインをサポートするために、ＤＳＭ−ＣＣは、放送ＯＲＢ間プロトコル（ＢＩＯＰ：Ｂｒｏａｄｃａｓｔ  Ｉｎｔｅｒ−ＯＲＢ  Ｐｒｏｔｏｃｏｌ）と呼ばれるプロトコルを使用し、そのＢＩＯＰは、以下の３つの重要な部分からなる。
【００５４】
［ＢＩＯＰプロファイル本体の定義］
ＢＩＯＰは、ネットワークにおいて放送されるそれぞれのオブジェクトごとに固有のオブジェクト参照を構築するのに使用されるプロファイル本体を定義する。ＢＩＯＰオブジェクト参照は、ＣＯＲＢＡ（Ｃｏｍｍｏｎ  Ｏｂｊｅｃｔ  Ｒｅｑｕｅｓｔ  Ｂｒｏｋｅｒ  Ａｒｃｈｉｔｅｃｔｕｒｅ）規格によって定義されたインターオペラブルオブジェクト参照（ＩＯＲ：Ｉｎｔｅｒ−ｏｐｅｒａｂｌｅ  Ｏｂｊｅｃｔ  Ｒｅｆｅｒｅｎｃｅ）フォーマットを使用する。それぞれのＩＯＲは、ＩＳＯ／ＩＥＣ１３８１８−６に定義されているようなＢＩＯＰＰｒｏｆｉｌｅＢｏｄｙを含む。それは、ＮＳＡＰアドレスによって指定されたサービスドメイン内においてオブジェクトを一意的に識別しかつ該オブジェクトを探し出すために必要なそのオブジェクトに関係するすべての情報を伝送する。
【００５５】
［ＢＩＯＰメッセージフォーマット］
Ｕ−Ｕオブジェクトカルーセルは、Ｕ−ＵオブジェクトをいわゆるＢＩＯＰメッセージとして放送する。サポートされたそれぞれのＵ−Ｕオブジェクトは、ジェネリックメッセージフォーマットから組み立てられた専用ＢＩＯＰメッセージで符号化される。ＢＩＯＰメッセージフォーマットについては、以下に詳細に説明する。
【００５６】
［ＢＩＯＰトランスポート定義］
放送ネットワークにおいてＵ−Ｕオブジェクトにアクセスするのを容易にするために、ＢＩＯＰメッセージは、放送ネットワークにおいて繰り返し放送されなければならない。したがって、Ｕ−Ｕオブジェクトカルーセルプロトコルは、その機能を実現するＵ−Ｎダウンロードプロトコルのデータカルーセルシナリオに基づくものである。ＢＩＯＰメッセージは、データカルーセルのモジュールで伝送される。そのモジュールは、ブロック（Ｕ−Ｎダウンロードによって定義されているように）に細分化され、ＤｏｗｎｌｏａｄＤａｔａＢｌｏｃｋ（）メッセージによって転送される。モジュールの関連した配信パラメータ（ｍｏｄｕｌｅＳｉｚｅ、ｂｌｏｃｋＳｉｚｅ、Ｔｉｍｅ−ｏｕｔ）は、関連したＤｏｗｎｌｏａｄＩｎｆｏＩｎｄｉｃａｔｉｏｎ（）（ＤＩＩ）メッセージに指定される。Ｕ−Ｕオブジェクトカルーセルは、カルーセルのサービスゲートウェイのＩＯＲを放送するために、Ｕ−ＮダウンロードのＤｏｗｎｌｏａｄＳｅｒｖｅｒＩｎｉｔｉａｔｅ（）（ＤＳＩ）メッセージを使用する。
【００５７】
［ＤＳＭ−ＣＣ  ＢＩＯＰメッセージ］
ＤＳＭ−ＣＣ  Ｕ−Ｕオブジェクトカルーセルは、４つのタイプのＵ−Ｕオブジェクト、すなわち、ＤＳＭ：：ＳｅｒｖｉｃｅＧａｔｅｗａｙ、ＤＳＭ：：Ｄｉｒｅｃｔｏｒｙ、ＤＳＭ：：Ｓｔｒｅａｍ、及び、ＤＳＭ：：Ｆｉｌｅを使用する。それぞれの種類のＵ−Ｕオブジェクトは、専用のタイプのＢＩＯＰメッセージで符号化される。すなわち、ＢＩＯＰは、以下の４つのメッセージを定義する。
【００５８】
［１．ＳｅｒｖｉｃｅＧａｔｅｗａｙメッセージ］
ＳｅｒｖｉｃｅＧａｔｅｗａｙメッセージは、タイプがＳｅｒｖｉｃｅＧａｔｅｗａｙであるＵ−Ｕオブジェクトを運ぶのに使用される。それは、他のディレクトリ、ファイル、ストリーム、及び、ＳｅｒｖｉｃｅＧａｔｅｗａｙオブジェクトへの参照を含む。ＳｅｒｖｉｃｅＧａｔｅｗａｙメッセージは、１つのＵ−Ｕオブジェクトカルーセル内に１つしか存在しない。
【００５９】
［２．ディレクトリメッセージ］
ディレクトリメッセージは、タイプがディレクトリであるＵ−Ｕオブジェクトを運ぶのに使用される。それは、他のディレクトリ、ファイル、ストリーム、及び、ＳｅｒｖｉｃｅＧａｔｅｗａｙオブジェクトへの参照を含む。
【００６０】
［３．ファイルメッセージ］
ファイルメッセージは、タイプがファイルであるＵ−Ｕオブジェクトを運ぶのに使用される。それは、ファイルのデータだけを含む。
【００６１】
［４．ストリームメッセージ］
ストリームメッセージは、タイプがストリームであるＵ−Ｕオブジェクトを運ぶのに使用される。それは、放送ネットワークにおけるストリームへの参照を含む。
【００６２】
［ＤＳＭ−ＣＣ  ＢＩＯＰジェネリックメッセージフォーマット］
４つのタイプのＢＩＯＰメッセージのすべては、単一オブジェクトのデータ及び属性をカプセル化するのに使用されるジェネリックオブジェクトフォーマットから得られる。メッセージは、ヘッダー、サブヘッダー、及び、メッセージ本体からなる。ジェネリックオブジェクトメッセージのシンタックス及びセマンティクスは、ＩＳＯ／ＩＥＣ１３８１８−６仕様に定義されており、参考のために、以下に繰り返し説明する。
【表２】
2005167981.tif 000004
【００６３】
ＢＩＯＰ：：ＭｅｓｓａｇｅＨｅａｄｅｒのフィールドのセマンティクスは、以下の通りである。
【００６４】
・  ｍａｇｉｃフィールドは、ＢＩＯＰメッセージを識別する。このフィールドの値は、常に、ＩＳＯ  Ｌａｔｉｎ−１で符号化された“ＢＩＯＰ”である。
【００６５】
・  ｂｉｏｐ＿ｖｅｒｓｉｏｎフィールドは、このメッセージに使用されたＢＩＯＰプロトコルのバージョン番号を含む。
【００６６】
・  ｂｙｔｅ＿ｏｒｄｅｒフィールドは、メッセージの次に続くエレメントに使用されるバイト順を示す（ｍｅｓｓａｇｅ＿ｓｉｚｅを含む）。ＦＡＬＳＥ（０）の値は、ビッグエンディアン（Ｂｉｇ−ｅｎｄｉａｎ）バイト順を示し、ＴＲＵＥ（１）は、リトルエンディアン（Ｌｉｔｔｌｅ−ｅｎｄｉａｎ）バイト順を示す。
【００６７】
・  ｍｅｓｓａｇｅ−ｔｙｐｅフィールドは、メッセージのタイプを示す。このフィールドの値は、０ｘ００にセットされなければならない。０ｘ０１から０ｘＦＦまでの範囲にある値は、ＩＳＯ／ＩＥＣ１３８１８−６のために予約されている。
【００６８】
・  ｍｅｓｓａｇｅ＿ｓｉｚｅフィールドは、メッセージヘッダーに続くメッセージの長さをバイト単位で含む。この数は、データ符号化規格によって挿入されるかかもしれないすべてのアライメントギャップを含む。
【００６９】
ＢＩＯＰ：：ＭｅｓｓａｇｅＳｕｂＨｅａｄｅｒのフィールドのセマンティクスは、以下の通りである。
【００７０】
・  ｏｂｊｅｃｔＫｅｙフィールドは、このメッセージ中に運ばれているオブジェクトを識別する。ｏｂｊｅｃｔＫｅｙの値は、放送サーバーに対してのみ意味を有し、クライアントによって解釈されることはない。
【００７１】
・  ｏｂｊｅｃｔＫｉｎｄフィールドは、メッセージ中に運ばれているオブジェクトの種類を識別する。ｏｂｊｅｃｔＫｉｎｄの値は、ｏｂｊｅｃｔＩｎｆｏフィールド及びｍｅｓｓａｇｅＢｏｄｙフィールドのシンタックス及びセマンティクスを定義する。
【００７２】
・  ｏｂｊｅｃｔＩｎｆｏフィールドは、このオブジェクトの属性の中のいくつかまたはすべてを含む。このフィールドのシンタックス及びセマンティクスは、ｏｂｊｅｃｔＫｉｎｄフィールドの値に依存する。
【００７３】
・  ｓｅｒｖｉｃｅＣｏｎｔｅｘｔフィールドは、放送サーバーからクライアントへ伝達されるＯＲＢサービスデータを含む。このフィールドの使用は、ＩＳＯ／ＩＥＣ１３８１８−６仕様の範囲外である。
【００７４】
ｍｅｓｓａｇｅＢｏｄｙフィールドのセマンティクスは、以下の通りである。
【００７５】
・  ｍｅｓｓａｇｅＢｏｄｙフィールドのシンタックス及びセマンティクスは、ｏｂｊｅｃｔＫｉｎｄフィールドの値に依存する。
【００７６】
［ＤＳＭ−ＣＣ  ＢＩＯＰディレクトリメッセージ］
ジェネリックオブジェクトメッセージフォーマットを専用オブジェクトメッセージにインスタス生成するために、ｏｂｊｅｃｔＩｎｆｏフィールド及びｍｅｓｓａｇｅＢｏｄｙフィールドのセマンティクスが定義されなければならない。ｏｂｊｅｃｔＩｎｆｏフィールドは、オブジェクトの属性を伝送することを目的とし、ｍｅｓｓａｇｅＢｏｄｙは、オブジェクトのデータを伝送することを目的とする。以下の規則は、ＢＩＯＰディレクトリメッセージのインスタンシエーションを定義する。  
【００７７】
１．ｏｂｊｅｃｔＫｉｎｄフィールドは、ストリング“ＤＳＭ：：Ｄｉｒｅｃｔｏｒｙ”または“ｄｉｒ”を含まなければならない。
【００７８】
２．ｍｅｓｓａｇｅＢｏｄｙフィールドは、ＢＩＯＰ：：ＤｉｒｅｃｔｏｒｙＭｅｓｓａｇｅＢｏｄｙ構造を含まなければならない。ＢＩＯＰ：：ＤｉｒｅｃｔｏｒｙＭｅｓｓａｇｅＢｏｄｙのシンタックス及びセマンティクスは、以下に定義される。
【００７９】
ＢＩＯＰ：：ＤｉｒｅｃｔｏｒｙＭｅｓｓａｇｅＢｏｄｙ構造は、バインディングのループからなる。バインディングは、オブジェクトネーム（すなわち、ｂｉｎｄｉｎｇＮａｍｅ）とＩＯＲとをお互いに相関させ、オブジェクトに関する付加的情報を提供する。参照されたオブジェクトがカルーセルに属する場合、ＩＯＲは、ＢＩＯＰ  Ｐｒｏｆｉｌｅ  Ｂｏｄｙを含まなければならない。ＢＩＯＰ：：ＤｉｒｅｃｔｏｒｙＭｅｓｓａｇｅＢｏｄｙのセマンティクスは、以下に定義される。
【００８０】
・  ｂｉｎｄｉｎｇＮａｍｅフィールド（すなわち、ｉｄ及びｋｉｎｄ）は、オブジェクトのパス仕様を含む。
【００８１】
・  ｂｉｎｄｉｎｇＴｙｐｅフィールドは、オブジェクトバインディングのタイプを示す。バインディングは、ネームがディレクトリにバインドされない場合のタイプ‘ｎｏｂｊｅｃｔ’か、または、ネームがディレクトリオブジェクトにバインドされる場合のタイプ‘ｎｃｏｎｔｅｘｔ’のいずれであってもよい。‘ｃｏｍｐｏｓｉｔｅ’は、ユーザ対ユーザコンポジットバインディングとの互換性のために定義される。
【００８２】
・  ｏｂｊｅｃｔＲｅｆフィールドは、オブジェクトのＩＯＲを含む。
【００８３】
ｏｂｊｅｃｔＩｎｆｏフィールドは、オブジェクトに関するユーザプライベート情報とともに、バインドされたオブジェクトのいくつかの属性を含んでもよい。バインドされたオブジェクトの属性がこのフィールドに伝送される場合、それらは、このフィールド内にカプセル化される第１の構造でなければならない。
【表３】
2005167981.tif 000005
【００８４】
［ＤＳＭ−ＣＣ  ＢＩＯＰファイルメッセージ］
ＢＩＯＰファイルメッセージは、ジェネリックオブジェクトメッセージフォーマットのインスタンシエーションである。以下の規則は、オブジェクトインスタンシエーションを定義する。
【００８５】
１．ｏｂｊｅｃｔＫｉｎｄフィールドは、ストリング“ＤＳＭ：：Ｆｉｌｅ”または“ｆｉｌ”を含まなければならない。
【００８６】
２．ｍｅｓｓａｇｅＢｏｄｙフィールドは、ＢＩＯＰ：：ＦｉｌｅＭｅｓｓａｇｅＢｏｄｙ構造を含まなければならない。ＢＩＯＰ：：ＦｉｌｅＭｅｓｓａｇｅＢｏｄｙのシンタックス及びセマンティクスは、以下に定義される。表のＦｉｌｅＭｅｓｓａｇｅＢｏｄｙフィールドは、ファイルデータをオクテットストリームとして含む。
【表４】
2005167981.tif 000006
【００８７】
［ＤＳＭ−ＣＣ  ＢＩＯＰストリームメッセージ］
ＢＩＯＰストリームメッセージは、ジェネリックオブジェクトメッセージフォーマットのインスタンシエーションである。以下の規則は、このインスタンシエーションを定義する。
１．ｏｂｊｅｃｔＫｉｎｄフィールドは、ストリング“ＤＳＭ：：Ｓｔｒｅａｍ”または“ｓｔｒ”を含む。
２．ｍｅｓｓａｇｅＢｏｄｙフィールドは、ＢＩＯＰ：：ＳｔｒｅａｍＭｅｓｓａｇｅＢｏｄｙ構造を含む。ＢＩＯＰ：：ＳｔｒｅａｍＭｅｓｓａｇｅＢｏｄｙのシンタックス及びセマンティクスは、以下に定義される。
【表５】
2005167981.tif 000007
【００８８】
ＢＩＯＰ：：ＳｔｒｅａｍＭｅｓｓａｇｅＢｏｄｙは、ストリームオブジェクトに関連付けられた一連のタップからなる。タップは、ＢＩＯＰがネットワーク独立を達成するのに使用する構造である。タップは、基本的には、関連するタグによる特定のネットワークコネクションへの参照である。ｓｔｒｅａｍフィールドは、ストリームオブジェクトに関連付けられた１つ以上のタップを含む。
【００８９】
［ＤＳＭ−ＣＣ  ＢＩＯＰサービスゲートウェイメッセージ］
ＢＩＯＰサービスゲートウェイメッセージは、ジェネリックオブジェクトフォーマットのインスタンシエーションである。以下の規則が、このインスタンシエーションを定義する。
１．ｏｂｊｅｃｔＫｉｎｄフィールドは、ストリング“ＤＳＭ：：ＳｅｒｖｉｃｅＧａｔｅｗａｙ”または“ｓｒｇ”を含まなければならない。
２．ｍｅｓｓａｇｅＢｏｄｙフィールドは、表３に説明されているようなＢＩＯＰ：：ＤｉｒｅｃｔｏｒｙＭｅｓｓａｇｅＢｏｄｙ構造を含まなければならない。
【００９０】
［ＤＳＭ−ＣＣ  ＢＩＯＰメッセージの概要］
ＤＳＭ：：Ｄｉｒｅｃｔｏｒｙ及びＤＳＭ：：Ｆｉｌｅが、図５に例として示されている。それぞれのＢＩＯＰオブジェクトは、それの固有のオブジェクトキー及びタイプ情報（ディレクトリ、ファイル、ストリーム、または、サービスゲートウェイ）をヘッダー内に有する。また、それぞれのＢＩＯＰオブジェクトは、ＢＩＯＰオブジェクトのタイプに応じてファイルサイズ、コンテンツタイプ（ＭＩＭＥタイプ）、タイムスタンプ、などの情報を提供する付加的なｏｂｊｅｃｔＩｎｆｏ構造を有する。ＤＳＭ：：Ｆｉｌｅオブジェクトの本体は、ファイルコンテンツである。ＤＳＭ：：Ｄｉｒｅｃｔｏｒｙオブジェクトの本体は、バインディングのリストからなる。上述したように、バインディングは、バインディングネーム、参照されたオブジェクトのオブジェクトタイプ（ディレクトリ、ファイル、ストリーム、または、サービスゲートウェイ）、及び、参照されたオブジェクトのロケーションを提供するＩＯＲを含む。
【００９１】
ＤＳＭ：：ＳｅｒｖｉｃｅＧａｔｅｗａｙオブジェクトについては、それが、ＤＳＭ：：Ｄｉｒｅｃｔｏｒｙオブジェクトに類似することに特に注意すべきである。ただ単に、バインディングネームのシンタックスが、異なるだけである。ＤＳＭ：：ＳｅｒｖｉｃｅＧａｔｅｗａｙオブジェクトの場合、ネームは、常に、ベースＵＲＩであり、ＤＳＭ：：Ｄｉｒｅｃｔｏｒｙオブジェクトの場合、ネームは、相対的なパスである。それぞれのＵ−Ｕオブジェクトカルーセルは、ＤＳＭ−ＣＣ  Ｕ−Ｕオブジェクトカルーセルの最上位ディレクトリの役割を果たす１つのサービスゲートウェイオブジェクトを必ず有する。サービスゲートウェイから開始して、ディレクトリパス、すなわち、一連のディレクトリリンクを辿ることによって、ＤＳＭ−ＣＣ  Ｕ−Ｕオブジェクトカルーセル内のオブジェクトに到達することができる。ＤＳＭ−ＣＣ  Ｕ−Ｕオブジェクトカルーセル内のオブジェクトは、複数のディレクトリから参照することができ、そのために、サービスゲートウェイからオブジェクトまで、多数のパスが、存在する場合もある。
【００９２】
［ＤＳＭ−ＣＣ  Ｕ−Ｕオブジェクトカルーセルを用いたファイルシステムのトランスポート］
上記したように図５は、単純ディレクトリ構造におけるオブジェクト獲得を説明する図である。放送トランスポートファイルシステムは、ＤＳＭ−ＣＣ  Ｕ−Ｕオブジェクトカルーセルプロトコルに基づいて構築できる。図５は、そのようなファイルシステムの例、及び、単純な階層ディレクトリ構造によって、ＤＳＭ−ＣＣ  Ｕ−Ｕオブジェクトカルーセル内のすべてのオブジェクトを獲得するための手順を説明する。まず最初に、サービスゲートウェイオブジェクトのＩＯＲが、ＤＳＩメッセージから抽出される。サービスゲートウェイのＩＯＲが与えられると、そのＩＯＲを伝送するデータモジュールからサービスゲートウェイオブジェクトが解析される。サービスゲートウェイオブジェクト内部のバインディング構造から、ディレクトリオブジェクトＤ０及びファイルオブジェクトＦ２のＩＯＲが抽出される。Ｆ２のＩＯＲが与えられると、Ｆ２オブジェクトを伝送するデータモジュールからＦ２のファイルデータが獲得される。Ｄ０のＩＯＲが与えられると、ディレクトリオブジェクトＤ０を抽出することができ、そのディレクトリオブジェクトＤ０から、Ｆ０及びＦ１のＩＯＲが得られる。同様に、Ｆ０のＩＯＲ及びＦ１のＩＯＲが与えられると、Ｆ０及びＦ１のファイルデータが獲得される。したがって、ディレクトリ構造におけるオブジェクトのＩＯＲが、ＩＯＲ−ＳＧ、ＩＯＲ−Ｄ０、ＩＯＲ−Ｆ２、ＩＯＲ−Ｆ０、及び、ＩＯＲ−Ｆ１の順序で得られる。一旦オブジェクトのＩＯＲが得られると、次に対応するデータモジュールからオブジェクトが検索される。
【００９３】
ＤＳＭ−ＣＣ  Ｕ−Ｕオブジェクトカルーセルのオブジェクトは、通常、単一の仮想チャンネルで伝送されることに注意されたい。しかし、同一又は異なる仮想チャンネル内に存在してもよい他のＤＳＭ−ＣＣ  Ｕ−Ｕオブジェクトカルーセル内のオブジェクトへの参照を含むバインディングを有することが可能である。ＤＳＭ−ＣＣ  Ｕ−Ｕオブジェクトカルーセルが異なる仮想チャンネル内に存在する場合、それは、同一のトランスポートストリーム内に存在するかもしれないし、又は、同一のトランスポートストリーム内に存在しないかもしれない。したがって、ＤＳＭ−ＣＣ  Ｕ−Ｕオブジェクトカルーセルの論理ネーム空間は、多数の仮想チャンネルにわたることが可能であり、多数のトランスポートストリームにわたることさえ可能である。異なるＤＳＭ−ＣＣ  Ｕ−Ｕオブジェクトカルーセル内に存在するオブジェクトを参照するＩＯＲは、そのオブジェクトを含むＤＳＭ−ＣＣ  Ｕ−Ｕオブジェクトカルーセルを識別し、かつ、そのＤＳＭ−ＣＣ  Ｕ−Ｕオブジェクトカルーセルのサービスゲートウェイからそのオブジェクトへ導くそのＤＳＭ−ＣＣ  Ｕ−Ｕオブジェクトカルーセル内のディレクトリパスを提供しなければならない。
【００９４】
実際においては、受信機は、すべてかまたは一部分のディレクトリオブジェクト及びファイルオブジェクトをそれのローカル記憶装置にキャッシュ保存し、オブジェクトへの（ＵＲＩ）インデックスをセットアップすることを選択できる。そうすると、放送トランスポート内のＤＳＭ−ＣＣ  Ｕ−Ｕオブジェクトカルーセルをすべて調べることなく、どのようなオブジェクトでもローカルメモリーからきわめて迅速に獲得することができる。
【００９５】
［ヨーロッパのデジタルビデオ放送（ＤＶＢ）ネットワークにおけるＭＰＥＧ−４データの配信］
以下の段落においては、ユニバーサル（または、ユニフォーム）リソース識別子（ＵＲＩ）をＵ−Ｕオブジェクトのバインディングネームに使用することについて説明する。適切なＵＲＩスキーム及びＵ−Ｕオブジェクトカルーセルによって、ＭＰＥＧ−２に基づいた放送ネットワークにおいてＭＰＥＧ−４データを配信するためのメカニズムを構築することができる。
【００９６】
ＲＦＣ２３９６に定義されているように、ＵＲＩは、リソースを識別するための単純な統一された拡張可能なメカニズムである。ＵＲＩは、ユニバーサルリソースロケータ（ＵＲＬ）のジェネリック形態（スーパーセット）である。ＵＲＩは、既存のインターネットプロトコルに限定されるものではなく、新しいアクセス技術と共に拡張することができる。ＩＳＯ／ＩＥＣ１３８１８−１仕様は、まだ定義されていないが、ＭＰＥＧ−４データエレメントを参照するための代替のアプローチとしてＵＲＬを使用する。本発明は、アクセスフレームワーク及びより広い範囲のデータ参照のために、ＵＲＬの概念をよりジェネリックなＵＲＩフォーマットにまで拡張する。
【００９７】
ローカル識別子（ｌｉｄ）と呼ばれる特定のＵＲＩが、本発明において使用される。ＳＭＰＴＥ  ３４３Ｍ−２００２に定義されているように、ｌｉｄＵＲＩスキームは、リソース、例えば、テレビジョン放送などの一方向手段を介して送信されるＨＴＭＬページ及びグラフィックファイルを識別するように設計されている。本発明においてｌｉｄスキームを使用することによって、ＭＰＥＧ−４シーン及びそれに関連するストリームなどのリソースは、一方向放送チャンネルにおいて、送信され、識別される。インターネットを介してなされるような、遠隔からリソースにアクセスするためのリターンチャンネルは必要ではない。ｌｉｄ参照を解析するとき、受信機は、まず最初に、キャッシュ内のリソースを探すことができる（受信機においてキャッシュが使用されていれば）。もしリソースが見つからなければ、受信機は、リソースが得られないことをただ単に通知してもよく、あるいは、リソースが放送ストリーム内に現れるのを待ってもよい。ある時間が経過しても、リソースが現れなければ、受信機は、タイムアウトにして、リソースが得られないことを通知してもよい。
【００９８】
図６に戻り、Ｕ−Ｕ  ＯＣ及びＵＲＩを用いて、ＭＰＥＧ−４データをＭＰＥＧ−２で伝送することが示されている。トランスポートプロトコルとしてのＤＳＭ−ＣＣ  Ｕ−Ｕオブジェクトカルーセル、及び、Ｕ−Ｕオブジェクトのバインディングネーム及びアクセススキームを提供するｌｉｄＵＲＩによって、ＭＰＥＧ−２放送ネットワークにおいてＭＰＥＧ−４データを伝送するためのメカニズムが得られる。ｌｉｄＵＲＩをＤＳＭ−ＣＣ  Ｕ−Ｕオブジェクトカルーセルと統合する例が図６に示されている。ｌｉｄまたはｈｔｔｐスキームで開始する絶対ＵＲＩアドレスのバインディングのリストを含むサービスゲートウェイオブジェクトが示されている。バインディングネームが、それぞれのディレクトリリンクの隣に示される。それぞれのファイルに関連する、結果として生じたＵＲＩは、ファイルの下に示され、本発明においては、そのＵＲＩは、ＭＰＥＧ−２に基づくＤＶＢネットワークを介して送信されるＭＰＥＧ−４データである。
【００９９】
ｌｉｄＵＲＩは、トランスポートにおいてリソースを参照するための主要なスキームであることに注意されたい。しかし、ｈｔｔｐスキームなどのその他のＵＲＩスキームが、本発明のフレームワークにおいて使用できる。図６に示されているように、いくつかのＵＲＩアドレスは、ｈｔｔｐスキームを使用している。ＤＣＭ−ＣＣ  オブジェクトカルーセルは、ベース（絶対）ＵＲＩとなるべきＤＳＭ：：ＳｅｒｖｉｃｅＧａｔｅｗａｙオブジェクトのバインディングネームだけを必要とする。ベースＵＲＩは、ｌｉｄかまたはｈｔｔｐのいずれであってもよく、あるいは、その他の考えられるＵＲＩスキームであってもよい。しかし、異なるＵＲＩスキームを使用及び解析する場合、いくつかの相違点が存在する。放送ストリームにおいてｌｉｄＵＲＩだけしか得ることができない場合、ｌｉｄＵＲＩは、放送リソースにラベルを付けるのに使用される。ウェブサーバーにおいてｈｔｔｐＵＲＩも得ることができる場合、ｈｔｔｐＵＲＩが放送リソースにラベルを付けるのに使用される。ＭＰＥＧ−４ストリームなどのリソースは、ｈｔｔｐ、ｌｉｄ、などの多数のＵＲＩによって参照することができることに注意されたい。一方、限られたキャッシュ空間及びインターネットコネクションを備えた受信機は、ｌｉｄＵＲＩをラベルとして付けられたリソースを保存できるが、ｈｔｔｐＵＲＩをラベルとして付けられたリソースは保存できない。
【０１００】
［本発明とＩＳＯ／ＩＥＣ１３８１８−１で定義された４ｏｎ２方法との互換性］
上述したように、ＩＳＯ／ＩＥＣは、ＩＳＯ／ＩＥＣ１３８１８−１の仕様において、ＭＰＥＧ−４コンテンツをＭＰＥＧ−２トランスポートストリームで伝送するための方法（４ｏｎ２として知られている）を指定している。この仕様（ＩＳＯ／ＩＥＣ１３８１８−１）は、ＭＰＥＧ−４ストリームのそれぞれがＳＬパケット化ストリーム内に含まれ、かつ、オプションとして、ＦｌｅｘＭｕｘストリームとして多重化されることを要求しており、それらの両方が、ＩＳＯ／ＩＥＣ１４４９６−１に定義されている。次に、ＳＬパケット化ストリームまたはＦｌｅｘＭｕｘストリームは、ＭＰＥＧ−２パケット化エレメンタリーストリーム（ＰＥＳ）パケット内かまたはＩＳＯ＿ＩＥＣ＿１４４９６＿ｓｅｃｔｉｏｎ内のいずれかにカプセル化され、そして、ＭＰＥＧ−２トランスポートストリームパケットの中へカプセル化される。上述したアプローチに基づいて送信されない、ストリーム及び／または記述子などのＭＰＥＧ−４エレメントの場合、仕様（ＩＳＯ／ＩＥＣ１３８１８−１）は、ＵＲＬ参照に基づいた代替の（定義されていない）アプローチを提供する。本発明は、それらのＭＰＥＧ−４エレメントを、ローカル識別子（Ｌｉｄ）によってアクセスされるＵＲＩでラベル付けし、ＤＳＭ−ＣＣオブジェクトカルーセルによってデータを送信する。ＤＳＭ−ＣＣオブジェクトカルーセルは、また、ＭＰＥＧ−２トランスポートストリームに基づいている。したがって、アプローチ４ｏｎ２かまたは本発明による方法のいずれかによって送信されるＭＰＥＧ−４データは、ＭＰＥＧ−２トランスポートで伝送される。２つのアプローチは、互換性があり、同時に使用することができる。実際には、ユーザは、送信するアプローチをデータの性質に基づいて決定する自由を有する。
【０１０１】
放送オーディオ及びビデオデータなどの大きなサイズを有するＭＰＥＧ−４プログラムエレメントまたは連続性を有するＭＰＥＧ−４プログラムエレメントの場合、データをパケット化し、元来のＩＳＯ／ＩＥＣアプローチに従って、そのパケットを連続的に送信する（流す）ことが、より効率的であるかもしれない。限定されたファイルサイズを有し、あるいは、コンテンツを頻繁に更新しなくてもよいその他のタイプのプログラムエレメントの場合、本発明によるアプローチが、より効率的に動作するであろう。
【０１０２】
要約すれば、本発明によるアプローチは、ＭＰＥＧ−２ネットワークにおいて、以下のＭＰＥＧ−４配信シナリオを可能にする。
【０１０３】
・  リソースは、ＰＩＤのＭＰＥＧ−２トランスポートパケット内に配信され、ＰＩＤの関連するＥＳ＿ＩＤによって参照される（元来のＩＳＯ／ＩＥＣ１３８１８−１が定義した４ｏｎ２アプローチ）。
【０１０４】
・  リソースは、ｈｔｔｐアドレスなどのＵＲＩでラベル付けられ、インターネットを介してアクセスされる。
【０１０５】
・  リソースは、ＵＲＩでラベル付けられ、ＤＳＭ−ＣＣ  Ｕ−Ｕオブジェクトカルーセルによって配信される。リソースは、同じ仮想チャンネルにおける同じかまたは異なるＤＳＭ−ＣＣ  Ｕ−Ｕオブジェクトカルーセルで配信され、あるいは、異なる仮想チャンネルのＤＳＭ−ＣＣ  Ｕ−Ｕオブジェクトカルーセルで配信される。リソースが異なる仮想チャンネルで配信される場合、該リソースは、異なるトランスポートで送信される。
【０１０６】
・  リソースは、メモリーに記憶または保存され、ＵＲＩスキームによってアクセスされる。
【０１０７】
図８は、ヨーロッパのデジタルビデオ放送（ＤＶＢ）ネットワークで放送されるＭＰＥＧ−４リソースを受信するための本発明による方法のフローチャートである。方法は、わかりやすいように、一連の番号が付されたステップとして示されているが、明示的に述べない限り、順序は、番号から推測すべきではない。これらのステップのいくつかは、スキップされ、並行して実行され、あるいは、厳密な順序を維持せずに実行されてもよいことを理解すべきである。方法は、ステップ８００から開始する。
【０１０８】
ステップ８０２は、パケット化されたＤＳＭ−ＣＣ  Ｕ−Ｕ  ＯＣを備えるＭＰＥＧ−２ＴＳをＤＶＢ−マルチメディアホームプラットホーム（ＭＨＰ）ターミナルで受信する。ステップ８０４は、ＴＳ内のＵＲＩを探し出す。ステップ８０６は、ＵＲＩに応じて、アドレスにアクセスする。典型的には、ステップ８０６のアドレスへのアクセスにはローカル識別子（ｌｉｄ）及び／又はｈｔｔｐアドレスへのアクセスを含んでいる。ステップ８０８は、アドレスへのアクセスに応じて、ＤＳＭ−ＣＣ  Ｕ−Ｕ  ＯＣからＭＰＥＧ−４リソースを検索する。ステップ８１０は、ＭＰＥＧ−４リソースを復号する。ある１つの態様において、ステップ８１２は、検索されたＭＰＥＧ−４リソースをキャッシュする。
【０１０９】
この方法のいくつかの態様においては、ステップ８０６のアドレスへのアクセスには、ＭＨＰプロトコル（ＭＨＰ  ＯＣ）によって強制かつ禁止されているように、ＤＳＭ−ＣＣ  Ｕ−Ｕ  ＯＣ内のオブジェクトへのバインディリングネームとアクセススキームを提供するｌｉｄ  ＵＲＩのアクセスを含む。より具体的には、初期オブジェクト記述子（ＩＯＤ）に埋め込まれたｌｉｄ  ＵＲＩは、ＢＩＦＳシーン記述ストリーム及び／またはオブジェクト記述子ストリームなどのＭＨＰ  ＯＣ内のリソースを探し出すのに用いられる。
【０１１０】
ステップ８０２でパケット化されたＭＨＰ  ＯＣを備えるＭＰＥＧ−２ＴＳを受信することには、階層ディレクトリ構造内にＭＰＥＧ−４リソースを形成することを含む。すなわち、階層ディレクトリ構造は、ＤＳＭ：：ＳｅｒｖｉｃｅＧａｔｅｗａｙ、ＤＳＭ：：Ｄｉｒｅｃｔｏｒｙ、ＤＳＭ：：Ｓｔｒｅａｍ及びＤＳＭ：：Ｆｉｌｅを含んでいるＢＩＯＰオブジェクトで形成される。
【０１１１】
いくつかの態様においては、ステップ８０８においてＭＨＰ  ＯＣからＭＰＥＧ−４リソースを検索することは、下位のステップを含む。ステップ８０８ａはＤＳＩメッセージを探し出す。ステップ８０８ｂは、Ｓｅｒｖｉｃｅ  ＧａｔｅｗａｙのためのＩＯＲを抜き出す。ステップ８０８ｃは、Ｓｅｒｖｉｃｅ  Ｇａｔｅｗａｙオブジェクトを解析する。ステップ８０８ｄは、Ｄｉｒｅｃｔｏｒｙオブジェクト、Ｓｔｒｅａｍオブジェクト及びＦｉｌｅオブジェクトのためのＩＯＲをＳｅｒｖｉｃｅ  Ｇａｔｅｗａｙバインディング構造から抜き出す。ステップ８０８ｅは、ＭＰＥＧ−４リソースをＦｉｌｅオブジェクト及びＳｔｒｅａｍオブジェクトから獲得する。
【０１１２】
典型的には、ステップ８０８においてＭＨＰ  ＯＣからＭＰＥＧ−４リソースを検索することは、オーディオデータ、ビデオデータ、及び、システムデータを含むグレームから選択されたＭＰＥＧ−４リソースを検索することを含む。また、ステップ８１０でのＭＰＥＧ−４リソースの復号は、ＭＰＥＧ−２ＴＳ内のオーディオデータをエンハンスすること、ＭＰＥＧ−２ＴＳ内のビデオデータをエンハンスすること、または、対話型オーディオビジュアルシーン及び通信リンクを確立するためにシステムデータを使用するなどの動作を含む。ある１つの態様において、さらなるステップ８１４は、復号化ＭＰＥＧ−４システムデータに応じて、対話型オーディオビジュアルシーン及び通信リンクを確立する。
【０１１３】
いくつかの態様の中には、ステップ８０２でのパケット化されたＭＨｐ  ＯＣを備えるＭＰＥＧ−２ＴＳを受信することは、第１のＭＰＥＧ−２ＴＳとパケット化されたＭＨＰ  ＯＣを備える第２のＭＰＥＧ−２ＴＳを受信することを含む。そして、ステップ８０４でのＴＳ内のＵＲＩを探し出すことは、第１のＭＰＥＧ−２ＴＳ内のｌｉｄＵＲＩを検索することを含み、及びステップ８０８でのＭＨＰ  ＯＣからＭＰＥＧ−４リソースを検索することには、第２のＭＰＥＧ−２ＴＳ  ＭＨＰ  ＯＣからＭＰＥＧ−４リソースを検索することを含む。
【０１１４】
１つの態様においては、ステップ８０４においてＵＲＩに応じてアドレスにアクセスすることは、さらにローカルキャッシュアドレス及び／又はウェブプロトコル識別子などのアドレスをアクセスすることを含む。そして、さらなるステップ８１６は、そのアドレスへのアクセスに応じて、ローカルキャッシュ及び／又はウェブサイトを含んでいるグループから選択されたソースからＭＰＥＧ−４リソースを検索する。
【０１１５】
図９は、ヨーロッパのデジタルビデオ放送（ＤＶＢ）ネットワーク内に存在するＭＰＥＧ−４データへのポインターを放送するための本発明の方法を説明するフローチャートである。この方法は、ステップ９００で開始する。ステップ９０２は、ＭＰＥＧ−４リソースをＤＳＭ−ＣＣ  Ｕ−Ｕ  ＯＣに埋め込む。ステップ９０４は、そのＤＳＭ−ＣＣ  Ｕ−Ｕ  ＯＣをＭＰＥＧ−２ＴＳ内にパケット化する。ステップ９０６は、そのＤＳＭ−ＣＣ  Ｕ−Ｕ  ＯＣ内のあるアドレスに配置されたＭＰＥＧ−４リソースをアクセスするためのＵＲＩを生成する。ステップ９０８は、ＭＰＥＧ−２ＴＳ内にそのＵＲＩを埋め込む。ステップ９１０はパケット化されたＤＳＭ−ＣＣ  Ｕ−Ｕ  ＯＣを備えるＭＰＥＧ−２ＴＳを放送する。
【０１１６】
典型的には、ステップ９０６は、ｈｔｔｐアドレス及び／又はローカル識別子（ｌｉｄ）などのＵＲＩを生成する。１つの形態においては、さらなるステップ９０７は、ウェブサイトとローカル（受信機）キャッシュからＭＰＥＧ−４リソースをアクセスするための各々のｈｔｔｐアドレスとローカル（受信機）キャッシュアドレスなどの追加のＵＲＩアドレスを生成する。
【０１１７】
ステップ９０６の１例においては、ＭＨＰ（ＭＨＰ  ＯＣ）によって強制や禁止されているように、ｌｉｄＵＲＩはバインディングネームやアクセススキームをＤＳＭ−ＣＣ  Ｕ−Ｕ  ＯＣ内のオブジェクトに供給するために生成され得る。さらに、生成されたｌｉｄＵＲＩは、ＢＩＦＳシーン記述ストリーム及び／又はオブジェクト記述ストリームなどのＭＨＰ  ＯＣ内のリソースを探し出すためにＩｎｉｔｉａｌ  Ｏｂｊｅｃｔ  Ｄｅｓｃｒｉｐｔｅｒ（ＩＯＲ）内に埋め込まれ得る。
【０１１８】
ステップ９０２でのＭＰＥＧ−４リソースをＭＨＰ  ＯＣに埋め込むことは、ＤＳＭ：：ＳｅｒｖｉｃｅＧａｔｅｗａｙ、ＤＳＭ：：Ｄｉｒｅｃｔｏｒｙ、ＤＳＭ：：Ｓｔｒｅａｍ及びＤＳＭ：：Ｆｉｌｅを含んでいるＢＩＯＰオブジェクトのＭＰＥＧ−４リソース階層ディレクトリ構造を形成することを含む。いくつかの態様においては、ステップ９０２は下位のステップを含む。ステップ９０２ａは、ＭＰＥＧ−４リソースをＦｉｌｅオブジェクトとＳｔｒｅａｍオブジェクト内にロードする。ステップ９０２ｂは、ＤｉｒｅｃｔｏｒｙＯｂｊｅｃｔ、ＳｔｒｅａｍＯｂｊｅｃｔ及びＦｉｌｅＯｂｊｅｃｔのためのＩＯＲを生成する。ステップ９０２ｃは、そのＩＯＲをＳｅｒｖｉｃｅＧａｔｅｗａｙにバインドする。ステップ９０２ｄはそのＳｅｒｖｉｃｅＧａｔｅｗａｙ用のＩＯＲを生成する。ステップ９０２ｅは、ＤＳＩメッセージ内のそのＳｅｒｖｉｃｅＧａｔｅｗａｙＩＯＲを探し出す。
【０１１９】
１つの態様においては、ＭＰＥＧ−４リソースをＭＨＰ  ＯＣに埋め込むことは（ステップ９０２）、ＭＰＥＧ−２ＴＳ内のオーディオデータをエンハンスすること、ＭＰＥＧ−２ＴＳ内のビデオデータをエンハンスすること、及び／または、対話型オーディオビジュアルシーンと通信リンクを確立するためのシステムデータなどの目的のために使用されうる、オーディオデータ、ビデオデータ及び／又はシステムデータなどのＭＰＥＧ−４リソースを埋め込むことを含む。
【０１２０】
別の態様においては、ステップ９０８でのＭＰＥＧ−２ＴＳ内へのそのＵＲＩを埋め込むことは、第１のＭＰＥＧ−２ＴＳ内のｌｉｄＵＲＩを探し出すことを含み、且つ、ステップ９０８でのＭＰＥＧ−２ＴＳ内でそのＭＨＰ  ＯＣをパケット化することは、第２のＭＰＥＧ−２ＴＳで伝送されるＭＨＰ  ＯＣ内でＭＰＥＧ−４リソースをパケット化することを含む。そして、ステップ９１０は、第１、第２のＭＰＥＧ−２ＴＳを放送する。
【０１２１】
ＭＰＥＧ−４リソースにアクセスするために、ＭＰＥＧ−２ＴＳに埋め込まれたＵＲＩを使用するために、システム及び方法が提供された。どのようにＵＲＩを使用することができるかを説明するために、いくつかの例が示されたが、これらの例は、すべてを網羅するものではない。同様に、ＭＰＥＧ−４リソースを探し出すことを説明するために、いくつかの例が示されたが、その他の方法で探し出すことも可能である。当業者は、別の様々な実施形態を考え出すことができる。
【図面の簡単な説明】
【０１２２】
【図１】ＭＰＥＧ−４コンテンツを再生する手順を説明する図である（従来技術）。
【図２】放送ＭＰＥＧ−４データリソースを受信するための本発明によるＥｕｒｏｐｅａｎ  Ｄｉｇｉｔａｌ  Ｖｉｄｅｏ  Ｂｒｏａｄｃａｓｔｉｎｇ（ＤＶＢ）Ｍｕｌｔｉｍｅｄｉａ  Ｈｏｍｅ  Ｐｌａｔｆｏｒｍ（ＭＨＰ）ターミナルの概略ブロック図である。
【図３】ｌｉｄＵＲＩを用いてＭＰＥＧ−４リソースにアクセスする手順を示す図である。
【図４】ＢＩＯＰ  Ｄｉｒｅｃｔｏｒｙオブジェクト及びＦｉｌｅオブジェクトを示す図である。
【図５】単純ＭＨＰ  ＯＣファイル構造を説明する図である。
【図６】ＭＨＰ  ＯＣファイルディレクトリの例を示す図である。
【図７】ＭＰＥＧ−４リソースを送信するための本発明によるＥｕｒｏｐｅａｎ  Ｄｉｇｉｔａｌ  Ｖｉｄｅｏ  Ｂｒｏａｄｃａｓｔｉｎｇ（ＤＶＢ）システムの概略ブロック図である。
【図８】Ｅｕｒｏｐｅａｎ  Ｄｉｇｉｔａｌ  Ｖｉｄｅｏ  Ｂｒｏａｄｃａｓｔｉｎｇ（ＤＶＢ）ネットワークで放送された受信ＭＰＥＧ−４リソースのための本発明方法を説明するフローチャートである。
【図９】Ｅｕｒｏｐｅａｎ  Ｄｉｇｉｔａｌ  Ｖｉｄｅｏ  Ｂｒｏａｄｃａｓｔｉｎｇ（ＤＶＢ）ネットワーク中のＭＰＥＧ−４データへのポインターを放送するための本発明方法を説明するフローチャートである。
【図１】
2005167981.tif 000008
【図２】
2005167981.tif 000009
【図３】
2005167981.tif 000010
【図４】
2005167981.tif 000011
【図５】
2005167981.tif 000012
【図６】
2005167981.tif 000013
【図７】
2005167981.tif 000014
【図８】
2005167981.tif 000015
【図９】
2005167981.tif 000016
【外国語明細書】
2005167981.tif 000017
2005167981.tif 000018
2005167981.tif 000019
2005167981.tif 000020
2005167981.tif 000021
2005167981.tif 000022
2005167981.tif 000023
2005167981.tif 000024
2005167981.tif 000025
2005167981.tif 000026
2005167981.tif 000027
2005167981.tif 000028
2005167981.tif 000029
2005167981.tif 000030
2005167981.tif 000031
2005167981.tif 000032
2005167981.tif 000033
2005167981.tif 000034
2005167981.tif 000035
2005167981.tif 000036
2005167981.tif 000037
2005167981.tif 000038
2005167981.tif 000039
2005167981.tif 000040
2005167981.tif 000041
2005167981.tif 000042
2005167981.tif 000043
2005167981.tif 000044
2005167981.tif 000045
2005167981.tif 000046
2005167981.tif 000047
2005167981.tif 000048
2005167981.tif 000049
2005167981.tif 000050
2005167981.tif 000051
2005167981.tif 000052
2005167981.tif 000053
2005167981.tif 000054
2005167981.tif 000055
2005167981.tif 000056
2005167981.tif 000057
2005167981.tif 000058
2005167981.tif 000059
2005167981.tif 000060
2005167981.tif 000061
2005167981.tif 000062
【図１】
2005167981.tif 000063
【図２】
2005167981.tif 000064
【図３】
2005167981.tif 000065
【図４】
2005167981.tif 000066
【図５】
2005167981.tif 000067
【図６】
2005167981.tif 000068
【図７】
2005167981.tif 000069
【図８】
2005167981.tif 000070
【図９】
2005167981.tif 000071