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