JP2012510190A - 複数のメディアトラックを介してアクセス可能になるメディアコンテンツを扱う技術 - Google Patents

Abstract

メディアファイルの複数のメディアトラックを介してアクセス可能になるメディアコンテンツを保護する技術が提供される。この技術の方法の実現例は、第１のメディアトラックを介してアクセス可能になる１つ以上の第１の層のデータアイテムの集合を提供するステップであり、第１の層のデータアイテムの各々がメディアコンテンツの一部としてレンダリングされるようにデコード可能であるステップを含む。また、少なくとも１つの第２のメディアトラックを介してアクセス可能になる１つ以上の第２の層のデータアイテムの集合が提供され、第２の層のデータアイテムの各々がメディアコンテンツの強化部分として少なくとも１つのデコードされた第１の層のデータアイテムと組み合わせてレンダリングされるようにデコード可能である。第２の層のデータアイテムの各々とトラックリファレンスインデックスを関連付けることにより、第１の層のデータアイテムをアクセス可能にする第１のメディアトラックを識別できる。その後、次のステップにおいて、第２の層のデータアイテム及び関連付けられたトラックリファレンスインデックス（及びオプションとして第１の層のデータアイテム）は、コンテンツ受信側に送信されるように暗号化される。

Description

本発明は、一般に、ビデオ、オーディオ又はマルチメディアコンテンツ等のメディアコンテンツを扱う技術に関する。特に、本発明は、メディアファイルの複数のメディアトラックを介してアクセス可能になるメディアコンテンツを保護することに関する。

モバイルビデオ送信システム等の現代のメディアコンテンツ配信システムは、益々普及してきている。基礎となるアクセスネットワークは、一般に、変動する接続品質及びメディアコンテンツ受信側として動作する広範な範囲の端末装置により特徴付けられる。変動する接続品質は、特に、変動する数のユーザ端末装置の経時変化するデータスループットに対する要求に対処するこれらのネットワークのアダプティブな資源共用機構の結果によるものである。端末装置が小型画面及び制限された処理能力を含む移動電話から高精細な表示装置を含む高性能のパーソナルコンピュータ（ＰＣ）までの範囲にわたる可能性があるため、端末装置は一般に種々の特性及び要件を有する。

メディアコンテンツに対するビットストリームスケーラビリティは、そのようなメディアコンテンツ配信システムにおいて望ましい機能である。スケーラビリティに対する必要性は、グレースフル・デクラデーション伝送要求、並びに２、３例を挙げると空間フォーマット、ビットレート又は電力に対する適応要求から発生する。これらの要求を満たすために、種々の空間的若しくは時間的な解像度若しくは品質でメディアコンテンツを同時に送信あるいは格納することは有益であり、これがビットストリームスケーラビリティの基本原理である。

スケーラブルビデオコーディング（ＳＶＣ）は、現代のビデオ伝送システムの特徴により提起されたスケーラビリティの必要性に対する１つの解決方法である。Ｈ．２６４／アドバンスド・ビデオ・コーディング（ＡＶＣ）のＡｎｎｅｘ Ｇにおいて特定されたようなＳＶＣ規格により、Ｈ．２６４／ＡＶＣに適合するスケーリング・サブ・ビット・ストリームを含むビットストリームを構成できる。Ｈ．２６４／ＡＶＣは、ＭＰＥＧ（Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅｓ Ｅｘｐｅｒｔ Ｇｒｏｕｐ）−４ ＡＶＣ（ＭＰＥＧ−４ ＡＶＣ）規格と同等のビデオ圧縮規格である。

ＳＶＣ規格は種々のスケーリング手法を含む。時間的ビットストリームスケーラビリティの場合、すなわち元のビットストリームより少ない時間的サンプリングレートでサブビットストリームを生成する場合、完全なアクセスユニットは、サブビットストリームを導出する際にビットストリームから除去される。この場合、ビットストリームにおけるハイレベルな構文及びインター予測リファレンス画像は、それに従って構成される。空間的な及び品質のビットストリームスケーラビリティの場合、すなわち元のビットストリームより低い空間的解像度又は品質でサブビットストリームを生成する場合、ネットワーク抽象化層（ＮＡＬ）ユニットは、サブビットストリームを導出する際にビットストリームから除去される。この場合、層間予測、すなわちより低い空間的解像度又は品質のビットストリームに含まれた情報に基づくより高い空間的解像度又は品質のビットストリームの予測が、一般に効率的にエンコードするために使用される。

ＳＶＣ規格において、より低い空間的解像度の又はより低い品質のサブビットストリームは基本層（ＢＬ）サブビットストリームとも呼ばれ、より高い空間的解像度の又はより高い品質のサブビットストリームは強化層（ＥＬ）サブビットストリームとも呼ばれる。尚、種々のより高い空間的解像度の又はより高い品質の複数のサブビットストリームを含む例において、合計で２つ以上のＥＬサブビットストリームが提供されてもよい。

ＳＶＣビデオ画像列の各画像は、いわゆる「フレーム」として（すなわち、この画像のエンコードされた表現として）示される。各ＳＶＣサブビットストリームは、一連のいわゆる「サブフレーム」として示される。各ＳＶＣサブフレームは、完全なＳＶＣフレーム又は一部のＳＶＣフレームのいずれかを構成する。換言すると、各ＳＶＣフレームは、単一のデータアイテム（すなわち、１つのＢＬ「サブフレーム」又は１つのＥＬ「サブフレーム」）として示されるか、あるいは少なくとも２つの別個のデータアイテムに、すなわちそれぞれのフレームと関連付けられたＢＬ情報のみを含む１つのＢＬ「サブフレーム」及びそれぞれのフレームと関連付けられたＥＬ情報を含む（少なくとも）１つのＥＬ「サブフレーム」とに、細分される。ＳＶＣビットストリームにおいて、ＥＬサブフレームは、時間的にある特定のＢＬサブフレームに対応してもよい。ＢＬサブフレームのみがデコードされる場合、ビデオコンテンツは、基準解像度又は品質で（例えば、１／４ビデオグラフィックスアレイ、すなわちＱＶＧＡ解像度で）レンダリングされる。一方、ＢＬサブフレーム及びＥＬサブフレームの双方がデコードされる場合、ビデオコンテンツはより高い解像度又は品質で（例えば、ＶＧＡ解像度で）レンダリングされる。

ＢＬサブビットストリーム及びＥＬサブビットストリームを格納するＳＶＣファイル形式は、ＭＰＥＧ−４ファイル形式から導出される。すなわち、各ＳＶＣメディアファイルは、メディアデータコンテナ及びトラックコンテナ（ムービーコンテナとも呼ばれる）に分割される。メディアデータコンテナは、いわゆるＢＬサンプルにＢＬサブビットストリームのサブフレーム（「ＢＬサンプルズ」）を格納するために、及び任意的にＥＬサンプルに（少なくとも）１つ以上のＥＬサブビットストリームのサブフレームを格納するために使用される。一方、トラックコンテナは、各々が１つのメディアストリームを示す１つ以上のメディアトラックを特定する。各メディアトラックは、メディアデータコンテナ（例えば、時間／サンプルテーブル）に格納された一連のサンプルに対する参照を含む。

このＳＶＣファイル形式を使用する場合、種々のＳＶＣ層及びＳＶＣ層の組合せへのアクセスは、複数の（すなわち、少なくとも２つの）メディアトラックを使用することにより示される。例えば、ＳＶＣエンコードされたビデオコンテンツがＢＬサブビットストリーム及び１つのＥＬサブビットストリームを含む場合、メディアファイルは、ＢＬサブビットストリームのみ（「ＢＬトラック」）を示す第１のメディアトラックを含み、第２のメディアトラックは、ＢＬサブビットストリーム及びＥＬサブビットストリーム（「ＥＬトラック」）の双方を示す。

メディアデータコンテナにＳＶＣエンコードされたビデオ情報を格納する２つの戦略が存在し、それらは、「効率的な戦略」及び「非効率的な」戦略と呼ばれる。双方の戦略によると、ＢＬサブフレームは、メディアデータコンテナに別個のＢＬサンプルとして格納され、これらのサンプルはＢＬトラックにより参照される。非効率的な戦略及び効率的な戦略は、ＥＬサブフレームを含むＥＬサンプルが、対応するＢＬサブフレームに関連して編成される方法が異なる。

非効率的な戦略によると、特定の時点に対応する（すなわち、特定のフレームを構成する）ＢＬサブフレーム及びＥＬサブフレームの双方は、同一のＥＬサンプルに格納される。これらのサンプルは、ＥＬトラックにおける特定の順序でレンダリングされる。ＢＬトラックにおいて参照されたＢＬサブフレームは、別個のＢＬサンプルに更に格納されるため、実際にはＢＬサブフレームがメディアデータコンテナ内において複製されている必要がある。この複製により、メモリの使用が非効率的になる。

効率的な戦略が使用される場合、ＢＬサブフレームは、ＥＬトラックにおいて参照される対応するＥＬサンプルにおいて、ＥＬサブフレームと共にカプセル化されるように複製されるのではない。むしろ、ＥＬサブフレームを含む各サンプルには、いわゆる「エクストラクタ」内にトラックリファレンスインデックスが与えられる。エクストラクタ内のトラックリファレンスインデックスはＢＬトラックを示し、こうしてこのことは特定のＥＬサブフレームと時間的に関連付けられたＢＬサブフレームを含むメディアコンテナにおいて、ＢＬサンプルを識別することを可能とする。非効率的な戦略のように、ＥＬサブフレームを含むサンプルはＥＬトラックにおいて参照される。従って、関連付けられたＢＬサブフレームは、ＥＬサンプル内のエクストラクタを用いて参照先のデータを取得することにより判定される。このため、更なるメタ情報（いわゆる「「ｓｃａｌ」タイプのトラックリファレンス」）がトラックコンテナに格納される。エクストラクタに含まれたトラックリファレンスインデックスを読み出し、且つ関連付けられたＢＬトラックリファレンスをメタ情報を使用してルックアップすることにより、ＢＬトラックが判定されうる。その後、次のステップにおいて、時間的に関連付けられたＢＬサブフレームを含むＢＬサンプルは、ＢＬトラックの時間／サンプルテーブルを使用して見つけられる。

ＳＶＣエンコードされたビデオコンテンツ等のメディアコンテンツの消費量を制御するために、デジタル権利管理（ＤＲＭ）技術が採用されてもよい。一般に、ＤＲＭ技術は、その消費を制御するためにメディアコンテンツを暗号化することに依存する。そのため、メディアコンテンツ暗号化がＳＶＣエンコードされたメディアコンテンツを更に保護できるかを調査した。これに関連して、暗号化されたメディアコンテンツが受信される時に、メディアコンテンツ受信側にとって復号化鍵が利用可能でない（あるいはメディアコンテンツ受信側とって使用可能でないか又は処理可能でない）場合に問題が発生することが分かっている。

特に、受信端末装置は、ＥＬサンプルを構成するためにエクストラクタを暗号化されたＥＬサブフレームに追加できない（あるいは少なくとも効率的に追加できない）ため、上述の効率的な戦略を使用して暗号化されたＥＬサブビットストリームを格納できない。ＢＬサブビットストリーム及びＥＬサブビットストリームが異なる暗号化鍵を使用して暗号化される場合、問題はより顕著である。そのような状況において、１つのＥＬサンプルを復号化するのに異なる復号化鍵が必要になるため、非効率的な戦略も採用されえない（あるいは少なくとも効率的には採用されえない）。

従って、複数のメディアトラックを介してアクセス可能になるメディアコンテンツを保護する技術が必要である。

第１の態様によると、メディアファイルの複数のメディアトラックを介してアクセス可能になるメディアコンテンツを処理する方法が提供される。方法は、第１のメディアトラックを介してアクセス可能になる１つ以上の第１の層のデータアイテムの集合を提供することであり、第１の層のデータアイテムの各々がメディアコンテンツの一部としてレンダリングされるようにデコード可能であることと；少なくとも１つの第２のメディアトラックを介してアクセス可能になる１つ以上の第２の層のデータアイテムの集合を提供することであり、第２のデータの層項目がメディアコンテンツの強化部分として少なくとも１つのデコードされた第１の層のデータアイテムと組み合わせてレンダリングされるようにデコード可能であることと；第２の層のデータアイテムの各々とトラックリファレンスインデックスを関連付けることにより、第１の層のデータアイテムをアクセス可能にする第１のメディアトラックを識別できることと；少なくとも第２の層のデータアイテム及び関連付けられたトラックリファレンスを暗号化することとを含む。

更なる態様によると、メディアファイルの複数のメディアトラックを介してアクセス可能になるメディアコンテンツを処理する方法が提供される。方法は、１つ以上の第１の層のデータアイテムの集合を受信することであり、第１の層のデータアイテムの各々がメディアコンテンツの一部としてレンダリングされるようにデコード可能であることと；メディアファイルの第１のメディアトラックを介してアクセス可能になる第１の層のデータアイテムを格納することと；１つ以上の暗号化された第２の層のデータアイテムの集合を受信することであり、第２の層のデータアイテムの各々がメディアコンテンツの強化部分として少なくとも１つのデコードされた第１の層のデータアイテムと組み合わせてレンダリングされるようにデコード可能であり、暗号化された第２の層のデータアイテムが関連付けられた暗号化されたトラックリファレンスインデックスと共に受信されることにより、第１の層のデータアイテムで第１のメディアトラックを識別できることと；少なくとも１つの第２のメディアトラックを介してアクセス可能になる暗号化されたトラックリファレンスインデックスと共に暗号化された第２の層のデータアイテムを格納することとを含む。

本明細書において理解されるように、メディアコンテンツは、ビデオコンテンツ、オーディオコンテンツ及びマルチメディアコンテンツ等を含む種々のコンテンツの種類を含む。

トラックリファレンスインデックスにより、第１の層のデータアイテムをアクセス可能にする第１のメディアトラックを直接又は間接的に識別できるようになってもよい。間接的な識別は、例えば、１つ以上の中間トラックリファレンスインデックスを介して（すなわち、１つ以上の中間メディアトラックを介して）実行されてもよく、最後の中間トラックリファレンスインデックスは、第１の層のデータアイテムをアクセス可能にする第１のメディアトラックを指し示す。

１つの変形例によると、個別の層は、１つの基本層及び１つ以上の強化層という意味で階層的に構造化される（例えば、特定の強化層のデコードされたデータアイテムは、基本層のデータアイテム、及び中間階層レベルにある０又は１つ以上の強化層のデータアイテムと組み合わせてのみレンダリングされてもよい）。複数の強化層の場合、強化層は、それらの間に階層関係を更に有してもよい。また、そのような場合、上部強化層のデータアイテムと関連付けられたトラックリファレンスインデックスにより、例えば次の下部強化層のデータアイテムをアクセス可能にするメディアトラックを識別できてもよい。最下部強化層のデータアイテムが最後にトラックリファレンスインデックスと関連付けられることにより、基本層のデータアイテムにアクセス可能であるメディアトラックを識別できてもよい。

別の変形例において、個別の層は、階層構造ではなく平坦な構造を有する。平坦層構造は、例えばいわゆるマルチプル・ディスクリブション・コーディング（ＭＤＣ）により実現される。ＭＤＣの例において、層は互いに改良されるものであるが、個々に（例えば、より低い品質又は解像度で）デコードされ且つレンダリングされてもよいし、共に（例えば、強化された品質又は解像度で）デコードされ且つレンダリングされてもよい。

上述したように、第２の層のデータアイテムは、メディアコンテンツの強化部分として少なくとも１つのデコードされた第１の層のデータアイテムと組み合わせてレンダリングされるようにデコード可能である。オプションとして、第２の層のデータアイテムは、少なくとも１つのデコードされた第１の層のデータアイテムと組み合わせずにレンダリングされるように、例えば個別にレンダリングされるように更にデコード可能であってもよい。

一般に、第１の層のデータアイテム及び第２の層のデータアイテムのいくつかの集合が存在してもよい。例えば、少なくとも１つ以上のデコードされた第１の層のデータアイテムのそれぞれと組み合わせてレンダリングされるようにデコード可能な（従って、トラックリファレンスインデックスのそれぞれと関連付けられた）１つ以上の第２の層のデータアイテムの第１の集合、及び各々が個別にレンダリングされるように（従って、トラックリファレンスインデックスと全く関連付けられない）デコードされることのみを意図する１つ以上の第２の層のデータアイテムの第２の集合が更に存在してもよい。同様に、第１の層のデータアイテムの種々の集合が規定されてもよい。

データアイテムを格納するための種々の手段が存在する。第１のオプションによると、データアイテムは、それぞれのメディアトラックに直接格納されてもよい。第２のオプションとして、データアイテムは、メディアトラックと同一のメディアファイルに格納されてもよいが、論理的にメディアトラックとは別に（例えば、メディアファイルのメディアデータコンテナに）格納されてもよい。更なるオプションとして、トラックは少なくとも１つの第１のメディアファイルに格納され、データアイテムは、メディアトラックを含む第１のメディアファイルとは異なる少なくとも１つの別個の第２のメディアファイルに格納される。第２のメディアファイル（すなわち、データアイテム）は、全く同一のユーザ端末上で第１のメディアファイル（すなわち、メディアトラック）と共に配置されてもよい。あるいは、第１のメディアファイル及び第２のメディアファイルのうちの少なくとも１つは、ケーブル、無線リンク又はネットワーク接続を介してユーザ端末にアクセス可能な外部記憶装置に格納される。これらのオプション及び更なるオプションは、種々の層のデータアイテムの格納に関連して適宜組み合わされてもよい。

１つの実現例において、本明細書において説明された技術は、メディアファイルにおいて少なくとも第１のメディアトラックの構成を示すトラックレイアウト情報を生成することを更に含む。トラックレイアウト情報は、オプションとして、メディアファイルにおいて第２のメディアトラック及び別のあらゆるメディアトラックの構成を更に示してもよい。トラックレイアウト情報は、（例えば、メディアコンテンツを受信することにより、メディアファイルを作成又は変更する際に）メディアファイル内の少なくとも第１のメディアトラックの構成を制御する指示を含む。第２の層のデータアイテムと関連付けられるトラックリファレンスインデックスは、トラックレイアウト情報に従って生成されてもよい。

メディアコンテンツは、ユニキャスト接続、マルチキャスト接続又はブロードキャスト接続を使用して１つ以上のコンテンツ受信側に配信されてもよい。更にメディアコンテンツは、１つ以上のメディアストリームを介して配信されてもよい。１つの実現例において、第１の層のデータアイテムを含む第１のメディアストリーム、及び暗号化されたトラックリファレンスインデックスと共に暗号化された第２の層のデータアイテムを含む第２のメディアストリームが作成される。第１の層のデータアイテムは、暗号化されていない形式又は暗号化された形式でメディアコンテンツ受信側に送信されてもよい。従って、後者の場合、第１のメディアストリームは、暗号化された第１の層のデータアイテムを含む。

メディアストリームは、例えば、メディアストリーム毎に別個のリアルタイムトランスポートプロトコル（ＲＴＰ）又はメディアコンテンツ受信側との他のセッションを確立することにより送信されてもよい。１つの構成において、トラックレイアウト情報はメディアストリームにおいて送信される。別の構成において、トラックレイアウト情報は、１つ以上のメディアストリームとは別に（すなわち、「帯域外」で）送信される。

特に、第１のメディアストリームが暗号化されていない第１の層のデータアイテムを含む場合、第１のメディアストリームを生成することは、第１の層のデータアイテムを最初の形式から第２の層のデータアイテムの第２の層の形式とは異なる第１の層の形式に変換することを含んでもよいがそれに限定されない。最初の形式は、第２の層の形式又はそれに準拠するあらゆる形式であってもよい。

あるいは、第２のメディアストリームを生成することは、第２の層のデータアイテムを最初の形式から（例えば、第１の層の形式又はそれに準拠するあらゆる形式から）第１の層の形式とは異なる第２の層の形式に変換することを含んでもよい。第２の層の形式は、例えば暗号化プロトコル形式であってもよい。一方、第１の層の形式は、暗号化プロトコル形式に準拠しない従来の形式であってもよい。

第１の層のデータアイテム及び第２の層のデータアイテム（トラックリファレンスインデックスと共に）は、全く同一の暗号化鍵を使用して暗号化されてもよい。あるいは、第１の層のデータアイテムは第１の暗号化鍵で暗号化され、第２の層のデータアイテム（トラックリファレンスインデックスと共に）は、第１の暗号化鍵とは異なる第２の暗号化鍵で暗号化される。更に別の方法において、第１の層のデータアイテム及び第２の層のデータアイテムは、それぞれ、第１の暗号化鍵及び第２の暗号化鍵（異なってもよくあるいは同一であってもよい）で暗号化されてもよく、トラックリファレンスインデックスは、第１の暗号化鍵及び第２の暗号化鍵とは異なる第３の暗号化鍵で暗号化されてもよい。

本明細書において説明された技術は、（例えば、第２の方法の態様、すなわち受信すること又は取得することの観点から）メディアファイルにおいて少なくとも第１のメディアトラックの構成を制御するトラックレイアウト情報を提供することを更に含んでもよい。メディアファイルにおいて、データアイテムは、データアイテムがレンダリングされる順序を示すデータアイテムへの参照を有するメディアトラックとともに、メディアトラックの外に格納されてもよい。例えば、メディアファイルの第１のメディアトラックは第１の層のデータアイテムへの参照を有してもよく、メディアファイルの第２のメディアトラックは第２の層のデータアイテムへの参照を有してもよい。第２のメディアトラックは、第１の層のデータアイテムを参照する第１のメディアトラックを指し示す情報（ルックアップテーブル等）と更に関連付けられてもよい。

第２の方法の態様は、少なくとも暗号化された第２の層のデータアイテム及び暗号化されたトラックリファレンスインデックスを復号化することを更に含んでもよい。第１の層のデータアイテムが暗号化された形式で受信される場合、暗号化された第１の層のデータアイテムは更に復号化されてもよい。

１つの例において、少なくとも１つの復号化鍵は外部の供給元から受信される。復号化鍵は、暗号化された第２の層のデータアイテム（暗号化されたトラックリファレンスインデックスと共に）が格納された前又は後に受信されてもよい。第１の層のデータアイテムが更に暗号化される場合、一方で暗号化された第１の層のデータアイテムを復号化し且つ他方で暗号化された第２の層のデータアイテム及び暗号化されたトラックリファレンスインデックスを復号化するのに異なる復号化鍵が必要であってもよい。更に、暗号化された第２の層のデータアイテム及び暗号化されたトラックリファレンスインデックスは、異なる復号化鍵を使用して復号化される必要があってもよい。

本明細書において説明された技術は、メディアトラックのうちの少なくとも１つを読み出すことと、読み出される少なくとも１つのメディアトラックを介してアクセス可能なデコードされたメディアコンテンツをレンダリングすることとを更に含んでもよい。一方の例において、アクセス可能なメディアコンテンツは第１の層のデータアイテムに対応する。換言すると、第１の層のメディアトラックは、デコードされ且つレンダリングされる次のステップにおいて読み出されるこれらの第１の層のデータアイテムを識別するために読み出されてもよい。他方の例において、アクセス可能なメディアコンテンツは、第１の層のデータアイテムと第２の層のデータアイテムとの組合せに対応する。換言すると、第２のメディアトラックは、次のステップにおいて第１の層のデータアイテム及び第２の層のデータアイテムが共にデコードされ且つレンダリングされるために読み出されるように、第２の層のデータアイテムと、例えば第１のメディアトラックへのポインタを介して、関連付けられた第１の層のデータアイテムとを識別するために読み出されてもよい。

第１の層のデータアイテムは、第１の層の形式で第１のメディアストリームを介して受信されてもよく（例えば、暗号化されていない形式で）、暗号化された第２の層のデータアイテム及び暗号化されたトラックリファレンスインデックスは、第１の層の形式に準拠しない第２の層の形式で第２のメディアストリームを介して受信されてもよい。そのような場合、方法は、第１の層のデータアイテムを第２の層の形式に準拠する形式に変換するステップを更に含んでもよい。第２の層の形式は、例えば暗号化プロトコル形式であってもよい。

メディアコンテンツをデコード及び／又はレンダリングすることに加えてあるいはその代りに、データアイテムの受信側は、データアイテム及びトラックリファレンスインデックスを（少なくとも一時的に）格納し、別の受信側に対して転送してもよい。そのように転送することは、例えば、（暗号化された又は暗号化されていない）第１の層のデータアイテム、暗号化された第２の層のデータアイテム及び暗号化されたトラックリファレンスインデックスのうちの少なくとも１つを含む少なくとも１つのメディアストリームを生成するステップを含んでもよい。そのようにして生成された１つ以上のメディアストリームは、更なるステップにおいて更なる受信側に送信されてもよい。

別の態様によると、コンピュータプログラム製品が提供される。コンピュータプログラム製品は、コンピュータプログラム製品が１つ以上の演算装置上で実行される場合に本明細書において説明された１つ以上の方法の態様の１つ以上のステップを実行するプログラムコード部分を含む。コンピュータプログラムは、永久メモリ又は書き換え可能なメモリ、ＣＤ−ＲＯＭ、あるいはＤＶＤ等のコンピュータ可読記録媒体上に格納されてもよい。コンピュータプログラムは、インターネット、セルラ電気通信ネットワーク、あるいは無線又は有線ローカルエリアネットワーク（ＬＡＮ）等の１つ以上のコンピュータネットワークを介してダウンロードされるように更に提供されてもよい。

更なる態様によると、メディアファイルの複数のメディアトラックを介してアクセス可能になるメディアコンテンツを処理する装置が提供される。装置は、第１のメディアトラックを介してアクセス可能になる１つ以上の第１の層のデータアイテムの集合を提供するように構成された第１のユニットであり、第１の層のデータアイテムの各々がメディアコンテンツの一部としてレンダリングされるようにデコード可能である第１のユニットと；少なくとも１つの第２のメディアトラックを介してアクセス可能になる１つ以上の第２の層のデータアイテムの集合を提供するように構成された第２のユニットであり、第２の層のデータアイテムの各々がメディアコンテンツの強化部分として少なくとも１つのデコードされた第１の層のデータアイテムと組み合わせてレンダリングされるようにデコード可能である第２のユニットと；第１の層のデータアイテムをアクセス可能にする第１のメディアトラックを識別できるようにするトラックリファレンスインデックスを第２の層のデータアイテムの各々と関連付けるように構成されたトラックリファレンスインデックス作成モジュールと；少なくとも第２の層のデータアイテム及び関連付けられたトラックリファレンスインデックスを暗号化するように構成された暗号化モジュールとを備える。

更に別の態様によると、メディアファイルの複数のメディアトラックを介してアクセス可能になるメディアコンテンツを処理する装置は、１つ以上の第１の層のデータアイテムの集合及び関連付けられた暗号化されたトラックリファレンスインデックスと共に１つ以上の暗号化された第２の層のデータアイテムの集合を受信するように構成された入力インタフェースであり、第１の層のデータアイテムの各々がメディアコンテンツの一部としてレンダリングされるようにデコード可能であり、第２の層のデータアイテムの各々がメディアコンテンツの強化部分として少なくとも１つのデコードされた第１の層のデータアイテムと組み合わせてレンダリングされるようにデコード可能である入力インタフェースと；メディアファイルの第１のメディアトラックを介してアクセス可能になる第１の層のデータアイテムを格納し且つメディアファイルの少なくとも１つの第２のメディアトラックを介してアクセス可能になる暗号化されたトラックリファレンスインデックスと共に暗号化された第２の層のデータアイテムを格納するように構成されたデータ記憶装置とを備える。

後者の装置は、少なくとも暗号化された第２の層のデータアイテム及び暗号化されたトラックリファレンスインデックスを復号化するように構成された復号化モジュールを更に備えてもよい。あるいは又は更に、装置は、メディアトラックのうちの少なくとも１つを読み出し、且つ読み出される少なくとも１つのメディアトラックを介してアクセス可能なデコードされたメディアコンテンツをレンダリングするように構成されたレンダリングモジュールを備えてもよい。

ストリーミングモジュールが更に提供されてもよい。ストリーミングモジュールは、第１の層のデータアイテム（暗号化された形式又は暗号化されていない形式）、暗号化された第２の層のデータアイテム及び暗号化されたトラックリファレンスインデックスのうちの少なくとも１つを含む少なくとも１つのメディアストリームを生成するように構成される。

以下において、図面に示された例示的な実施形態を参照して、本発明を更に詳細に説明する。

メディアサーバの一実施形態及びメディアクライアントの一実施形態を含むメディアコンテンツ配信システムを概略的に示す図である。 ＳＶＣの一実施形態において、メディアサーバからメディアクライアントにメディアストリームを送信することを概略的に示す図である。 メディアサーバの動作の方法の一実施形態を示す概略的なフローチャートである。 メディアクライアントの動作の方法の一実施形態を示す概略的なフローチャートである。 二層メディアコンテンツのメディアファイルの一実施形態及びメディアクライアントによる処理を示す概略図である。 エクストラクタの一実施形態の構成要素を概略的に示す図である。 二層メディアコンテンツのメディアファイルの一実施形態及びメディアクライアントによる処理を示す概略図である。 三層メディアコンテンツのメディアファイルの一実施形態及びメディアクライアントによる処理を示す概略図である。 更なる一実施形態に従って、専用のメディアストリームを介してメディアサーバからメディアクライアントに部分的に暗号化されていないメディアコンテンツを送信することを示す概略図である。 図９において示されたストリームを生成する第１の実施形態を示す図である。 図９において示されたストリームを生成する第２の実施形態を示す図である。 メディアクライアントにより受信された際の、図１０又は図１１において示されたように生成されたストリームの処理を概略的に示す図である。

以下の説明において、限定するためではなく説明するために、本明細書において開示された技術を完全に理解するために、特定の装置の構成及び特定のストリーミングの例等の特定の詳細が示される。これらの特定の詳細から逸脱する他の実施形態において技術が実施されてもよいことは、当業者には明らかだろう。また、以下の実施形態は、主にビデオコーディング規格ＳＶＣ及び暗号化規格ＩＳＭＡＣｒｙｐに関して説明されるが、本明細書において説明された技術が他のエンコードプロトコル及び暗号化プロトコルと関連して更に実施されてもよいことは、容易に明らかとなるだろう。更に、以下においてＭＰＥＧ４対応のファイル形式及びＲＴＰセッションを参照するが、本明細書において説明された技術は、他のファイル形式及びトランスポートプロトコルを使用して更に実現される。

本明細書において説明された方法、ステップ及び機能が個別のハードウェア回路網を使用して、プログラムされたマイクロプロセッサ又は汎用コンピュータと組み合わせて機能するソフトウェアを使用して、特定用途向け集積回路（ＡＳＩＣ）を使用して且つ／あるいは１つ以上のデジタル信号プロセッサ（ＤＳＰ）を使用して実現されてもよいことは、当業者により更に理解されるだろう。以下の実施形態は主に方法及び装置の形態で説明されるが、本明細書において開示された技術がコンピュータプロセッサ及びプロセッサに接続されたメモリにおいて更に具体化されてもよいことは、更に理解されるだろう。メモリは、プロセッサにより実行された場合に本明細書において説明されたステップを実行する１つ以上のプログラムを格納する。

次に、メディアサーバ１０２、及びメディアサーバ１０２からメディアコンテンツを受信するメディアクライアント１０４を含む例示的なメディアコンテンツ配信システム１００の一実施形態を示す図１を参照する。図１のシステム１００は単一のメディアクライアント１０４のみを示すが、メディアサーバ１０２が実際にはメディアコンテンツを複数のメディアクライアント１０４に配信するように構成されることは、理解されるだろう。また、各メディアクライアント１０４は、２つ以上のメディアサーバ１０２からメディアコンテンツを受信するように構成されてもよい。

メディアサーバ１０２は、メディアコンテンツファイルを格納するメディアコンテンツデータベース１０６を含む。本実施形態において、メディアコンテンツファイルは、モバイルテレビ規格対応のビデオファイルである。別の実施形態において、メディアコンテンツファイルがオーディオファイル又はマルチメディアファイルであってもよいことは、理解されるだろう。

オプションとして、メディアサーバ１０２は、メディアコンテンツファイルを受信する入力インタフェース（不図示）を更に含む。受信したメディアコンテンツファイルは、データベース１０６に格納されてもよく、後の時点で取得されてもよい。あるいは、受信したメディアコンテンツファイルは、データベース１０６において一時的にバッファリングされるだけであってもよく、あるいはライブコンテンツ等の場合はデータベース１０６をバイパスしてもよい。

メディアサーバ１０２は、メディアコンテンツデータベース１０６に含まれる、又は入力インタフェースを介して受信されたメディアコンテンツファイルをエンコードする少なくとも２つのエンコーダ１０８、１１０を更に備える。メディアファイルが圧縮された形式で２つのエンコーダ１０８、１１０に提供される場合、２つのエンコーダ１０８、１１０により実行された動作は、ビデオの中間非圧縮表現を生成する伸張動作を含んでもよい。あるいは又は更に、２つのエンコーダ１０８、１１０により実行された動作は、トランスコーディング動作を含んでもよい。

各エンコーダ１０８、１１０は、専用のメディアコンテンツレンダリング層に対応する専用のサブビットストリームを生成し、各サブビットストリームは、連続した一連の個別のデータアイテム（例えば、サブフレーム）を含む。エンコーダ１０８、１１０の動作は、図１において示されたように外部コントローラからメディアサーバ１０２に提供されるエンコード制御情報（ＳＶＣエンコードされたメディアコンテンツが有する層の数及び依存関係に関する情報を含む）により制御される。あるいは、エンコード制御動作は、メディアサーバ１０２の内部コントローラ（不図示）により生成される。

エンコーダ１０８、１１０により生成されたデータアイテムは、特定のメディア層に関係するデータアイテムがメディアファイルの専用のメディアトラックを介してアクセス可能であるように、メディアクライアント１０４により格納される。第１の層のエンコーダ１０８により生成されたデータアイテムは、メディアファイルの一部分（例えば、画像又は画像列）としてレンダリングされるようにデコード可能である。一方、第２の層のエンコーダ１１０により生成されたデータアイテムは、メディアコンテンツの強化部分として、少なくとも１つのデコードされた第１の層のデータアイテムと組み合わせてレンダリングされるようにデコード可能である。強化部分は、例えば、第１の層のデータアイテムのみに基づいてレンダリングされるメディアコンテンツの部分と比較してより高い品質、より高いサンプリングレート又はより高い解像度でレンダリングされてもよい。尚、第２の層のデータアイテムは、メディアコンテンツの強化部分ではないものとして個々にレンダリングされるように更にデコード可能であってもよい。尚、第２の層のエンコーダ１１０は、個々にレンダリングされることのみを意図する１つ以上のデータアイテムの集合を更に生成してもよい。

上述したように、異なるエンコーダ１０８、１１０により出力された個別のデータアイテムは、メディアファイルの異なるトラックを介してメディアクライアント１０４にアクセス可能になる。エンコーダ１１０により出力された第２の層のデータアイテムのうちの少なくともいくつかが少なくとも１つのデコードされた第１の層のデータアイテムと組み合わせてレンダリングされるようにデコード可能であるため、メディアクライアント１０４が第１の層のデータアイテムにアクセスすることができる第１のメディアトラックを識別することを可能にするトラックリファレンスインデックスを、そのような第２の層のデータアイテムと関連付けることは有利である。そのため、メディアサーバ１０２は、トラックレイアウト生成器１２２と、トラックリファレンスインデックス作成モジュール１１２とを備える。

トラックレイアウト生成器１２２は、エンコード制御情報（ＳＶＣエンコードされたメディアコンテンツが有する層の数及び依存関係に関する情報を含む）を供給される。この情報を使用して、トラックレイアウト生成器１２２は、エンコードされたメディアコンテンツについてメディアクライアント１０４により生成される特定のメディアファイルに対するトラックレイアウトを規定する。この規定に基づいて、トラックレイアウト生成器１２２は、対応するトラックレイアウト情報（例えば、例示的なＳＶＣの例において、一般に、それぞれのトラックの「ｓｃａｌ」メタ情報部分に格納されることを意図した情報）を生成する。トラックレイアウト情報は、メディアクライアント１０４によりメディアストリームがメディアトラックにマッピングされる方法に関する情報を更に含む。トラックレイアウト情報は、メディアクライアント１０４に送信されるようにストリーム生成器１１６に（あるいは、図１において示されたように、出力インタフェース１１８に）供給される。トラックレイアウト情報は、トラックリファレンスインデックス作成モジュール１１２に更に供給される。

トラックリファレンスインデックス作成モジュール１１２は、トラックレイアウト生成器１２２により生成されたトラックリファレンスレイアウトに基づいて、少なくとも第１の層のデータアイテムと組み合わせてレンダリングされることを意図した第２の層のデータアイテムの各々と専用のトラックリファレンスインデックスを関連付ける（例えば、追加するか、付加するか、連結するかあるいは含む）ように構成される。トラックリファレンスインデックスにより、メディアクライアント１０４は、第１の層のデータアイテムをアクセス可能にする第１のメディアトラックを識別できる。

個々にレンダリングされることのみを意図する第２の層のデータアイテムが必ずしもトラックリファレンスインデックスと関連付けられなくてもよいことは、理解されるだろう。また、トラックリファレンスインデックスのコンテンツがいくつか又は全ての第２の層のデータアイテムについて同一であることは、明らかとなるだろう。トラックリファレンスインデックスは、以下において図８を参照して更に詳細に説明されるように、３つ以上の層を含む例において一般的には異なるコンテンツを有する。

第１の層のエンコーダ１０８により出力された第１の層のデータアイテム、及びトラックリファレンスインデックス作成モジュール１１２により出力されたトラックリファレンスインデックスと関連付けられた第２の層のデータアイテムは、暗号化モジュール１１４に入力される。更に暗号化モジュール１１４は、第２の層のエンコーダ１１０により、個々にのみレンダリングされる（従って、トラックリファレンスインデックスと関連付けられていない）第２の層のデータアイテムを直接供給される。暗号化モジュール１１４は、ローカルに格納されてもよくあるいは外部の鍵供給元から取得されてもよい１つ以上の暗号化鍵を使用して第１の層のデータアイテム、第２の層のデータアイテム及びトラックリファレンスインデックスを暗号化するように構成される。

一実現例において、第１の層のデータアイテム、第２の層のデータアイテム及びトラックリファレンスインデックスは、全く同一の暗号化鍵を使用して暗号化される。別の実現例において、第１の層のデータアイテムは第１の暗号化鍵を使用して暗号化され、第２の層のデータアイテム及びトラックリファレンスインデックスは、第１の暗号化鍵とは異なる第２の暗号化鍵を使用して暗号化される。第２の層のデータアイテム及びトラックリファレンスインデックスは、共に又は別個に暗号化されてもよい。第２の層のデータアイテム及びトラックリファレンスが別個に暗号化される場合、異なる暗号化鍵が使用されてもよい。以下において、第１の層のデータアイテムは第１の暗号化鍵で暗号化され、且つ第２の層のデータアイテム及びトラックリファレンスインデックスは、第１の暗号化鍵とは異なる第２の暗号化鍵を使用して共に暗号化されると仮定する。

暗号化モジュール１１４は、暗号化された第１の層のデータアイテム、暗号化された第２の層のデータアイテム及び暗号化されたトラックリファレンスインデックスが、１つ以上のメディアストリームを生成するストリーム生成器１１６に出力されるように、ストリーム生成器１１６に接続される。図１において示されたように、更にストリーム生成器１１６は、第１の層のエンコーダ１０８の出力部に直接接続される。

ストリーム生成器１１６は、２つの異なる動作モードを有する。第１の動作モードにおいて、ストリーム生成器１１６は、暗号化されていない形式の第１の層のデータアイテム、並びに暗号化された第２の層のデータアイテム及び暗号化されたトラックリファレンスインデックスを含む１つ以上のデータストリームを生成する。第２の動作モードにおいて、ストリーム生成器１１６は、暗号化された第１の層のデータアイテム、並びに暗号化された第２の層のデータアイテム及び暗号化されたトラックリファレンスインデックスを含む１つ以上のメディアストリームを生成する。あるいは、ストリーム生成器１１６は、これらのモードのうちの１つのみにおいて動作可能であるように構成されてもよい。

ストリーム生成器１１６により出力された１つ以上のメディアストリームは、メディアサーバ１０２の出力インタフェース１１８に供給される。「帯域外」送信の場合、トラックレイアウト生成器１２２により生成されたようなトラックレイアウト情報は、出力インタフェース１１８に別個に供給される。出力インタフェース１１８は、ユニキャスト接続、マルチキャスト接続又はブロードキャスト接続を介してメディアクライアント１０４とのメディアセッションを確立するように構成される。また、出力インタフェース１１８は、トラックレイアウト生成器１２２により生成されたトラックレイアウト情報をユニキャスト接続、マルチキャスト接続又はブロードキャスト接続を介してメディアクライアント１０４に送信するように更に構成される。

上述したように、トラックレイアウト情報は、メディアセッションにおいて送信されるか、あるいは例えばセッション記述プロトコル（ＳＤＰ）を使用して別個に（「帯域外」）送信されるかのいずれかである。尚、トラックレイアウト情報の送信は、メディアクライアント１０４が異なる方法でトラックレイアウト情報を取得した場合には省略されてもよい。例えばトラックレイアウト情報は、メディアサーバ１０２とメディアクライアント１０４との間で事前に交渉されてもよいか、あるいはメディアクライアント１０４がメディアサーバ１０２とあらゆる通信を開始する前にトラックレイアウト情報を既に認識しているように単に事前に定義されてもよい。

ユニキャストの例において、メディアサーバ１０２は、図１において示されたように１つのメディアクライアント１０４を含む専用の通信リンクを有する。マルチキャスト又は放送の例においては、１つ以上の更なるメディアクライアント１０４がメディアサーバ１０２に接続される。

出力インタフェース１１８により１つ以上のメディアクライアント１０４に出力された各メディアストリームは、別個のＲＴＰストリームであってもよい。一般に、出力インタフェース１１８は、メディアクライアント１０４に送信されるように、インターネットプロトコル（ＩＰ）ヘッダ、ユーザデータグラムプロトコル（ＵＤＰ）ヘッダ又はＲＴＰヘッダ等のヘッダをメディアストリームに追加する。

次に、図１のメディアクライアント１０４を参照すると、メディアサーバ１０２により配信された１つ以上のメディアストリームは、入力インタフェース１３０において受信される。一般に、入力インタフェース１３０は、メディアサーバ１０２からメディアクライアント１０４に送信するために使用されたＩＰヘッダ、ＵＰＤヘッダ及びＲＴＰヘッダ等のヘッダを１つ以上のメディアストリームから除去する。更に、トラックレイアウト生成器１２２により生成されたようなトラックレイアウト情報は、入力インタフェース１３０において受信されてもよい。

入力インタフェース１３０は、データ記憶装置１３２及びトラック構成コントローラ１５０に接続される。データ記憶装置１３２は、種々のデータアイテムがメディアファイルの種々のトラックを介してアクセス可能になるような方法で、暗号化されたかあるいは暗号化されていない第１の層のデータアイテム、暗号化された第２の層のデータアイテム及び暗号化されたトラックリファレンスインデックスを格納するように構成される。データ記憶装置１３２は、トラックレイアウト生成器１２２により生成されたトラックレイアウト情報を格納するように更に構成されてもよい。

トラック構成コントローラ１５０は、メディアファイルにおいて少なくとも第１のメディアトラックの構成を制御するように構成される。特に、トラック構成コントローラ１５０は、第１の層のデータアイテムがメディアファイルの第１のメディアトラックを介してアクセス可能であるように第１の層のデータアイテムを格納することを制御する。暗号化されたトラックリファレンスインデックスと共に暗号化された第２の層のデータアイテムは、メディアファイルの少なくとも１つの第２のメディアトラックを介してアクセス可能になるように格納される。従って、復号化鍵を使用しなくても格納できる。例示的なＳＶＣの例において、トラックレイアウト情報は、メディアファイルの「ｓｃａｌ」メタ情報部分に格納される。

メディアクライアント１０４は、暗号化されたデータアイテム及び暗号化されたメディアトラックリファレンスを復号化する復号化モジュール１３４を更に備える。復号化モジュール１３４は、メディアコンテンツを直接レンダリングするのが望ましい場合には入力インタフェース１３０に接続されてもよく、あるいは遅れてレンダリングするのが望ましい場合にはデータ記憶装置１３２に直接接続されてもよい。復号化モジュール１３４は、ローカルに格納されるかあるいは外部の鍵供給元から取得される１つ以上の復号化鍵へのアクセスを有する。

一般に、復号化モジュール１３４は、暗号化モジュール１１４の逆の動作を実行し、特定の暗号化様式に依存して単一の復号化鍵又は２つ以上の異なる復号化鍵のいずれかを適用する。復号化モジュールは、いずれの場合においても、暗号化されたトラックリファレンスインデックスと共に暗号化された第２の層のデータアイテムを復号化する。第１の層のデータアイテムが暗号化される場合、復号化モジュール１３４は、第１の層のデータアイテムも復号化する。あるいは、第１の層のデータアイテムは、復号化モジュール１３４をバイパスしてもよい。

復号化されたデータアイテム又は暗号化されていないデータアイテムは、デコードモジュール１３６に渡される。デコードモジュール１３６は、選択されたメディアトラックにより制御された順序でデータアイテムをデコードするように構成される。選択されたメディアトラックを読み取ると、個別の第２の層のデータアイテムと関連付けられたトラックリファレンスインデックスは、メディアコンテンツの強化されたレンダリングに必要な第１の層のデータアイテムがアクセス可能であるメディアトラックを更に識別するために、評価される。デコードされたデータアイテムは、少なくとも１つの出力ユニット（不図示）により出力されるようにレンダリングされるために、適切な順序でデコードモジュール１３６からレンダリングモジュール１３８に渡される。出力ユニット（例えば、表示装置及び／又はスピーカ）は、メディアクライアント１０４の一部であってもよくあるいはメディアクライアント１０４に接続可能であってもよい。

メディアクライアント１０４は、メディアサーバの機能を自身で遂行するように更に構成される。このため、メディアクライアント１０４は、データ記憶装置１３２に接続されたストリーム生成器１４０を備える。ストリーム生成器１４０は、第１の層のデータアイテム（暗号化された形式又は暗号化されていない形式）、暗号化された第２の層のデータアイテム及び暗号化されたトラックリファレンスインデックスを含む少なくとも１つのメディアストリームを生成するように構成される。１つの構成において、ストリーム生成器１４０は、データ記憶装置１３２から読み出されたような、第１の層のデータアイテムを含む第１のメディアストリーム及び暗号化されたトラックリファレンスインデックスと共に暗号化された第２の層のデータアイテムを含む、第１のメディアストリームを生成する。メディアストリームは、メディアクライアント１０４の出力インタフェース１４２を介して更なるメディアクライアント（不図示）に出力されてもよい。従って、メディアクライアント１０４は、復号化鍵を使用せずにメディアサーバとして動作できる。

図１を参照して上述した実施形態において、トラックリファレンスインデックスは、メディアファイルを作成する直前にデータアイテムを受信すると、メディアクライアント１０４により生成されない。代わりに、トラックリファレンスインデックスはメディアサーバ１０２により既に生成されており、メディアクライアント１０４に送信される前に関連付けられた第２の層のデータアイテムと共に暗号化されている。データアイテムが暗号化された形式で且つ従来のファイル形式（ＭＰＥＧ−４対応のファイル形式等）に準拠してメディアクライアント１０４により格納されるため、この手法により、暗号処理は容易に実現される。換言すると、トラックリファレンスインデックスがメディアサーバ１０２により事前に生成されているため、対象のファイル形式で個別のデータアイテムを格納する前に個別のデータアイテムを復号化する必要はない。

次に、メディアコンテンツの保護がＩＳＭＡＣｒｙｐ１．０又は２．０プロトコルを使用して実現されるＳＶＣの例に関連して、この手法のいくつかの詳細及び更なる利点を例示的に説明する。ＩＳＭＡＣｒｙｐ仕様に従って、各ＳＶＣ層は、図２において示されるように、専用の暗号化鍵により別個にコンテンツ保護され、別個のＲＴＰメディアストリームにおいて送信される。

図２は、ＳＶＣサーバ１０２からＳＶＣクライアント１０４にメディアコンテンツを配信することを示す。ＳＶＣサーバ１０２及びＳＶＣ１０４の内部構成は、図２において示されないが、一般に、図１のメディアサーバ１０２及びメディアクライアント１０４の構成にそれぞれ対応してもよい。

図２において示されたように、２つの専用のＲＴＰメディアストリーム２００、２０２は、ＳＶＣサーバ１０２の出力インタフェースからＳＶＣクライアント１０４の入力インタフェースへと達する。第１のメディアストリーム２００は、第１の暗号化鍵で暗号化されたＢＬサブフレームを含み、第２のメディアストリーム２０２は、トラックリファレンスインデックス（ＳＶＣエクストラクタに含まれている）及びＥＬサブフレームを含む。エクストラクタ及びＥＬサブフレームは、ＢＬサブフレームを暗号化するために使用された第１の暗号化鍵とは異なる第２の暗号化鍵で共に暗号化されている。暗号化は、ＩＳＭＡＣｒｙｐに準拠して実行される。

図２から分かるように、ＳＶＣサーバ１０２とＳＶＣクライアント１０４との間に、記録メタ情報チャネル２０４が更に張られている。チャネル２０４は、トラックレイアウト情報をＳＶＣクライアント１０４に帯域外で信号伝送するために使用される。トラックレイアウト情報は、メディアストリーム２００、２０２を介して受信したメディアコンテンツを格納するためにＳＶＣクライアント１０４により生成されるメディアファイルにおいて、ＢＬメディアトラック及びＥＬメディアトラックの構成を示す。トラックレイアウト情報は、基本的に、メディアストリーム２０２を介して暗号化されたエクストラクタを介して送信されたトラックリファレンスインデックスに準拠するように、メディアファイルにおいてどのように個別のメディアトラックが配置されるかを制御する。

尚、記録メタ情報チャネル２０４はオプションである。例えば、トラックレイアウト情報は、メディアストリーム２００、２０２のうちのいずれか又は双方を介して帯域内で送信されてもよい。また、トラックレイアウト情報は、ＳＶＣサーバ２０２とＳＶＣクライアント１０４との間で事前に交渉されてもよく、あるいはＳＶＣクライアント１０４がＳＶＣサーバ１０２とあらゆる通信を開始する前にトラックレイアウト情報を既に認識しているように、単に事前に定義されてもよい。

次に、図３のフローチャート３８５を参照して説明されるように、ＢＬストリーム２００及びＥＬストリーム２０２はＳＶＣサーバ１０２により生成される。

第１のステップにおいて、ＳＶＣサーバ１０２は、ＳＶＣエンコードされたメディアコンテンツ（図１のエンコーダ１０８及び１１０により出力されたような）の層の数及び依存関係に関する情報を取得する。今回の例においては、ＢＬ及び１つのＥＬを含む２つの層の例を考える。次に、第２のステップにおいて、ＳＶＣサーバ１０２は、ＳＶＣエンコードされたメディアコンテンツに対してＳＶＣクライアント１０４により生成されるメディアファイルに対する、トラックレイアウトを規定する（あるいはトラックレイアウトについて通知される）。ＳＶＣサーバ１０２は、対応するトラックレイアウト情報（すなわち、一般に、それぞれのトラックの「ｓｃａｌ」メタ情報部分に含まれた情報）を更に生成する。トラックレイアウト情報は、メディアストリームをメディアトラックにマッピングする方法に関する情報を更に含む。第３のステップにおいて、トラックレイアウト情報は、記録メタ情報チャネル２０４を介してＳＶＣクライアント１０４に送出される。例えばトラックレイアウト情報は、ＳＤＰを使用して送信されてもよい。尚、ステップ１〜３は、ＳＶＣクライアント１０４が異なる方法でトラックレイアウト情報を取得した場合には省略されてもよい。

次に、ＳＶＣクライアント１０４の暗号化モジュール１１４は、第４のステップにおいて、エンコーダ１０８、１１０から第１のメディアサブフレーム又は後続する任意のメディアサブフレームを取り出し、第５のステップにおいて、取り出されたサブフレームがＥＬサブフレームであることを判定する。この場合、第６のステップにおいて、エクストラクタ（トラックリファレンスインデックスを含む）は、第２のステップにおいて規定されたトラックレイアウトに基づいて生成される。更に、エクストラクタ及びそれぞれのＥＬサブフレームが連結される。次に、ステップ７ａにおいて、エクストラクタ及びＥＬサブフレームは、ＥＬ暗号化鍵で共に暗号化される。暗号化が行われると、暗号化されたＥＬサブフレームは、暗号化されたエクストラクタと共にＥＬストリーム２０２を介してＳＶＣクライアント１０４に送出される。一方、第５のステップにおいてサブフレームはＥＬサブフレームではない（すなわち、サブフレームはＢＬサブフレームである）と判定される場合、ＳＶＣサーバ１０２は、ＢＬ暗号化鍵でこのサブフレームを暗号化すること（ステップ７ｂ）及び暗号化されたサブフレームをＢＬストリーム２００を介してＳＶＣクライアント１０４に送出すること（ステップ８ｂ）に進む。ステップ８ａ又はステップ８ｂから、処理は、ＳＶＣサーバ１０２が送信される次のメディアサブフレームを取得する第４のステップに戻る。

２つのメディアストリーム２００、２０２（及びオプションとしてトラックレイアウト情報）を受信すると、ＳＶＣクライアント１０４によりメディアコンテンツを処理する２つの主な使用例が存在する。図２において示されたように、第１の使用例はメディアコンテンツを直接レンダリングすることに関係し、第２の使用例は後でレンダリングするかあるいは後で再ストリーミングするためにメディアコンテンツを格納することである。双方の使用例は、図１において示されたメディアクライアント１０４のレンダリングモジュール１３８及びストリーム生成器１４０と関連して既に簡単に説明された。

直接レンダリングする場合、ＳＶＣクライアント１０４は、メディアストリーム２００、２０２を介して配信された暗号化された情報を復号化するのに必要な復号化鍵に迅速にアクセスする必要がある。ＳＶＣクライアント１０４がこれらの復号化鍵を取得する方法は、一般に、デジタル権利管理（ＤＲＭ）又は限定受信（ＣＡ）システムにより管理され、本発明の範囲外である。

復号化されると、ＢＬサブフレームをデコードすること及び直接レンダリングすることは、既存のＳＶＣソリューションとは異ならない。既存のソリューションの主な違いは、ＥＬストリーム２０２が暗号化されたＥＬサブフレームに加えてトラックリファレンスインデックスを搬送する（暗号化された）エクストラクタを更に含むことである。しかし、ＳＶＣ仕様によると、エクストラクタは通常のＳＶＣ ＮＡＬユニットと同一の構造を有し、ＳＶＣ規格において明記されていないヘッダコードを含む。そのため、復号化されたエクストラクタは、デコード動作中に単に無視され且つ破棄される。その結果、ＥＬサブフレームのみがデコードされてレンダリング処理に渡される。換言すると、直接レンダリングする場合、トラックレイアウト情報は必要なく、ＳＶＣクライアント１０４にとって利用可能であったとしても、単に無視されてもよい。

メディアストリーム２００、２０２を介して受信されたメディアコンテンツを直接レンダリングする代わりに又はそれに加えて、メディアコンテンツは、ＳＶＣクライアント１０４の内部データ記憶装置（図１のデータ記憶装置１３２を参照）において、あるいは無線又は有線（例えば、ネットワーク）接続を介してＳＶＣクライアント１０４によりアクセス可能な外部データ記憶装置において、１つ以上のメディアファイルとして格納されてもよい。メディアコンテンツを格納することは、メディアコンテンツを復号化するのに必要な１つ以上の鍵がメディアストリーム２００、２０２を受信した際にまだ使用可能でない場合には、唯一の容易な使用例であるだろう。鍵は、例えば、メタデータの格納が始まった後に、使用可能ではなくなるかもしれない。また、メディアクライアント１０４は、別のメディア受信者に後で転送されるメディアデータを一時的にバッファリングするメディアサーバとして更に動作してもよい。後者の場合、メディアクライアント１０４は、メディアコンテンツを復号化するのに必要な復号化鍵へのアクセスを全く有さなくてもよい。

暗号化されたメディアコンテンツ（エクストラクタを含む）は、一般に図４のフローチャート４００において示されたように、ＳＶＣクライアント１０４により格納され且つ復号化される。図５において示されたように、メディアファイル３００内に格納が行われる。メディアファイル３００はＭＥＰＧ−４仕様に準拠するファイル形式を有する。特に、図５において示され且つ一般に当技術分野において既知であるように、メディアファイル３００は、トラックコンテナ３０２と、メディアデータコンテナ３０４とを備える。メディアコンテンツが基本層及び単一の強化層を介して送信される本実施形態において、２つのメディアトラック３０６、３０８は、ＳＶＣクライアント１０４によりメディアファイル３００が作成されると、トラックコンテナ３０２に配置される。

トラックコンテナ３０２における２つのメディアトラック３０６、３０８の配置は、図２において示された（又はＳＶＣクライアント１０４にとって使用可能な）記録メタ情報チャネル２０４を介して受信されたトラックレイアウト情報により制御される。本質的に、トラックレイアウト情報は、メディアファイル３００内におけるＢＬサンプルを参照するメディアトラック３０６の場所を示す。第２のメディアトラック３０８は、ＥＬサンプルを参照するように構成され、トラックレイアウト情報を考慮して作成され且つＢＬトラック３０６を指し示すいわゆる「ｓｃａｌ」タイプのトラックリファレンスを含むメタ情報部分３１０を含む。

メディアストリーム２００、２０２を介して受信されたメディアコンテンツ（図４の第１のステップを参照）は、別個のＢＬサンプル３１２及び別個のＥＬサンプル３１４の形式でメディアコンテナ３０４に格納される。本実施形態において、メディアデータコンテナ３０４に格納されたサンプルは暗号化されている（図４の第２のステップを参照）ことに留意することが重要である。この事実は、ＢＬサンプル３１２及びＥＬサンプル３１４においてＢＬサブフレーム及びＥＬサブフレームを先行するそれぞれのＩＳＭＡＣｒｙｐヘッダＫから更に明らかとなる。図５において矢印により示されたように、ＢＬトラック３０６は、デコードされたサンプルコンテンツがレンダリングされる順序を示す、複数のＢＬサンプルに対する連続した参照を含む。同様に、ＥＬトラック３０８はＥＬサンプル３１４に対する参照を含む。

上記の説明及び図５において示されたＥＬサンプル３１４の構成から明らかとなったように、ＥＬサンプル３１４は、「効率的な」戦略に従ってメディアデータコンテナ３０４に格納される。すなわち、個別のＥＬサンプル３１４は、単一のＥＬサブフレームを含むが、メディアコンテンツの強化部分としてのＥＬサブフレームと組み合わせてレンダリングされる、対応するＢＬサブフレームは含まない。むしろ、各ＥＬサンプル３１４はエクストラクタＥ_１を備える。エクストラクタは、特にトラックリファレンスインデックスパラメータ（「ｔｒａｃｋ＿ｒｅｆ＿ｉｎｄｅｘ」）を含む図６において示されたようなデータ構造である。次に、図７を参照して更に詳細に説明されるように、トラックリファレンスインデックスパラメータにより、ＥＬトラック３０８のメタ情報部分３１０を介して、ＢＬトラック３０６の場所、すなわち対応するＢＬサンプル３１２を識別できる。

図７は、時間ｔ１における、ＥＬサブフレームに対応するＥＬサンプル３１４の読み出しを示す。最初に、ＳＶＣクライアント１０４は、ＢＬ復号化鍵及びＥＬ復号化鍵を取得する（図４の第３のステップを参照）。次に、ＳＶＣクライアント１０４は、ＥＬサンプル３１４、すなわちエクストラクタＥ_１及びＥＬサブフレームＥＬ（ｔ１）を読み出し且つ復号化する（図４の第４のステップを参照）。次のステップにおいて、ＳＶＣクライアント１０４は、エクストラクタＥ_１から「ｔｒａｃｋ＿ｒｅｆ＿ｉｎｄｅｘ」パラメータを読み出す（図６を参照）。次に、ＥＬトラック３０８のメタ情報部分３１０は、エクストラクタＥ_１に含まれた特定の「ｔｒａｃｋ＿ｒｅｆ＿ｉｎｄｅｘ」パラメータに対応するトラックリファレンスを判定するために読み出される。トラックリファレンスは、トラックレイアウト情報において規定されたように、メディアファイル３００におけるＢＬトラック３０６の場所を指し示す。更なるステップにおいて、ＳＶＣクライアント１０４は、メディアデータコンテナ３０４に格納された対応するＢＬサンプル３１２を判定するために、ＢＬトラック３０６から時間／サンプルテーブルを読み出す。このＢＬサンプル３１２は、更なるステップにおいて読み出され且つ復号化される（図４の第４のステップを参照）。

この手順の結果として、ＥＬサンプル３１４に含まれたＥＬサブフレーム及びＢＬサンプル３１２に格納された時間的に対応するＢＬサブフレームの双方が取得され、それらはメディアコンテンツの強化部分としてレンダリングされるように共にデコードされる。尚、図５において示された実施形態において、ＥＬサンプル３１４及びＢＬサンプル３１２の双方は時間ｔ１に対応する。換言すると、サンプルオフセットはゼロである（図６のエクストラクタにおける「ｓａｍｐｌｅ＿ｏｆｆｓｅｔ」パラメータを参照）と仮定される。

図７の説明から明らかとなったように、ＳＶＣクライアント１０４は、メディアストリームの受信時にエクストラクタを生成する（このことは、ＥＬ層を暗号化するために使用された鍵に対応する復号化鍵へのアクセスを必要とする）必要はない。その結果、ＳＶＣクライアント１０４は、事前に復号化動作せずに、ＩＳＭＡＣｒｙｐ及びＳＶＣ仕様の双方に準拠するファイル形式でＳＶＣエンコードされ且つコンテンツ保護されたメディアコンテンツを記録することができる。従って、コンテンツ保護されたＳＶＣメディアファイルは、既存のＩＳＭＡＣｒｙｐ仕様を全く変更せずに且つ復号化鍵を全く使用せずにＳＶＣクライアント１０４により格納されることができる。図７において例示的に示された手法は、空間スケーラビリティ、時間スケーラビリティ及びＳＮＲスケーラビリティを含む、ＳＶＣ規格によりサポートされた全ての種類のスケーラビリティに適用可能である。

上述したＳＶＣの実施形態は、２つ以上の強化層を含む例にも適用される。例えば、第３（又は第４及び第５等）のメディアストリームが、それぞれのエクストラクタと共に第２（又は第３及び第４等）の強化層の暗号化されたサブフレームを転送する図２の例に追加されてもよい。図８は、基本層及び２つの強化層の形式でＳＶＣクライアント１０４により受信されるようにエンコードされたメディアコンテンツを格納するように構成されたメディアファイル３００の更なる一実施形態を概略的に示す。そのため、第２のＥＬトラック３１６がトラックコンテナ３０２に追加される必要がある。第２のＥＬトラック３１６は、ＥＬトラック３０８を指し示す専用のメタ情報部分３１８と関連付けられる。更なるＥＬメディアストリームを介して受信された更なるＥＬサンプル３２０は、ＥＬストリーム２０２（図２を参照）に関係するＢＬサンプル３１２及びＥＬサンプル３１４と共にメディアデータコンテナ３０４に格納される。

第１のＥＬトラック３０８は、図７において示された例と関連して上述したように読み出される。第２のＥＬトラック３１６は同様に処理される。すなわち、第２のＥＬトラック３１６にアクセスすると、ＳＶＣクライアント１０４は、ＥＬサンプル３２０への参照を見つけ、それを読み出し且つ復号化する。このため、ＢＬサンプル３１２及びＥＬサンプル３１４を復号化するために使用された復号化鍵とは異なる復号化鍵が必要となる。図７において説明された例とは異なり、ＥＬサンプル３２０に含まれたエクストラクタＥ_２はＢＬトラック３０６を指し示さないが、ＥＬサンプル３１４が読み出され且つ復号化されるように第１のＥＬトラック３０８を指し示し、そしてＥＬサンプル３１４のエクストラクタＥ_１はまた、ＢＬサンプル３１２が読み出され且つ復号化されるように、ＢＬトラック３０６を識別できる。この「参照先データ取得(dereference)」処理の終了時、ＳＶＣクライアント１０４は、第２のＥＬサブフレーム、時間的に関連付けられた第１のＥＬサブフレーム、及び時間的に関連付けられたＢＬサブフレームを（この順序で）取得する。これらの３つのサブフレームは、図５において示された例と比較して更に強化される品質又は解像度で、共にデコードされ且つレンダリングされてもよい。

図１において示されたシステム１００等のスケーラブルメディアコンテンツ配信システムの興味深い使用例は、メディアクライアント１０４に対して１つ以上の層が保護されていない形式でストリーミングされ且つ１つ以上の更なる層が保護された形式でストリーミングされる例である。そのような例は１つ以上の保護されていない層へのフリーアクセスを提供するが、１つ以上の更なる層の消費は適宜制御される。そのような例の実現例において、図１のメディアサーバ１０２は、第１の層のエンコーダ１０８の出力が、ストリーム生成器１１６に直接供給されるように、暗号化モジュール１１４を選択的にバイパスしてもよいように構成される。このような構成により、ＢＬストリーム２００が保護されていない形式で配信されるが、（少なくとも１つの）ＥＬストリーム２０２（エクストラクタを含む）がコンテンツ保護される、図９において概略的に示されたような例示的なＳＶＣの実現例が可能になる。ＢＬメディアストリーム２００が暗号化されないで配信されることを除いて、図９の例は図２の例から導出されている。

ＩＳＭＡＣｒｙｐは選択的な暗号化をサポートするから、保護されていないメディアコンテンツを送信するために更に使用されてもよい。しかし、ＩＳＭＡＣｒｙｐ仕様によると、保護されていないメディアコンテンツが後続することを示すＩＳＭＡＣｒｙｐ特有のヘッダを保護されていないサブフレーム毎に送信することが、多層の例においては依然として必要である。図９において示された例において、ＩＳＭＡＣｒｙｐヘッダは、ＢＬストリーム２００を介して送信された各（暗号化されていない）ＢＬサブフレームに付加される必要があるだろう。付加されたＩＳＭＡＣｒｙｐヘッダの結果、ＢＬサブフレームは暗号化されていないにもかかわらず、ＩＳＭＡＣｒｙｐをサポートしない従来のメディアクライアント１０４は、ＢＬサブフレームをデコード及びレンダリングできないかもしれない。この問題は、ＩＳＭＡＣｒｙｐに対するサポートが、モバイル放送サービスについてのオープンモバイルアライアンス（ＯＭＡ）ＢＣＡＳＴ仕様等の多くのコンテンツ保護規格において必須の機能として規定されていないことにより悪化する。

ＩＳＭＡＣｒｙｐ能力を有さない従来のＳＶＣクライアント１０４がＢＬサブフレームをデコードすることを可能にするために、ＢＬサブフレームは原則的に暗号化されないで且つＩＳＭＡＣｒｙｐヘッダを使用せずにストリーミングされてもよく、一方でＥＬサブフレームはＩＳＭＡＣｒｙｐ保護されたメディアストリームとして配信される。しかし、そのような場合、ＢＬサブフレームにはＩＳＭＡＣｒｙｐヘッダがないため、後で消費又は配信されるＥＬメディアコンテンツの格納はできないだろう。

ＩＳＭＡＣｒｙｐに準拠して暗号化されていないＢＬサブフレーム及びＩＳＭＡＣｒｙｐ保護されたＥＬサブフレームを格納するために、ＩＳＭＡＣｒｙｐヘッダは、ＳＶＣクライアント１０４によって受信された際にＢＬサブフレームに追加されてもよい。追加されたＩＳＭＡＣｒｙｐヘッダにおいて、ＩＳＭＡＣｒｙｐ仕様において明記されているような選択的暗号化情報は、ＢＬトラックを介してアクセス可能なメディアコンテンツが保護されていないことを示すために使用される。

図９において示されたストリーミングの例を実現するために、ＳＶＣサーバ１０２は、図１０及び図１１において示されたように構成されてもよい。図１０において示された構成において、ストリーム生成器１１６（図１を参照）は、ＢＬエンコーダ１０８から暗号化されていないＢＬサブフレームを受信し、ＩＳＭＡＣｒｙｐの特定の詳細を考慮せずにＢＬストリーム２００を生成する。一方、トラックリファレンスインデックス作成モジュール１１２、暗号化モジュール１１４は、トラックレイアウト生成器１２２から受信したような記録メタ情報（すなわち、トラックレイアウト情報）、及びＥＬエンコーダ１１０から受信したようなＥＬサブフレーム（及び対応するトラックリファレンスインデックス）を処理する。特に、モジュール１１２、１１４は、ＥＬサブフレームに対応するトラックリファレンスインデックスを生成し、インデックスをＥＬサブフレームと関連付け（例えば、インデックスを追加するか、付加するか、連結するかあるいは含み）、従来の方法でＩＳＭＡＣｒｙｐ特有の暗号化ステップを実行して暗号化されたＥＬストリーム２０２を生成する。記録メタ情報は、記録メタ情報チャネル２０４を介してＢＬストリーム２００、ＥＬストリーム２０２に並列に送信される。

図１１は、図９において示された例を実現するメディアサーバ１０２の別の構成を示す。ＳＶＣサーバ１０２は、ＳＶＣエンコードされ且つＩＳＭＡＣｒｙｐ保護されたメディアファイル３００からのコンテンツをストリーミングすることを、ここでは仮定する。ＢＬサンプル３１２が（ＩＳＭＡＣｒｙｐヘッダを含むが）暗号化されていないことを除いて、メディアファイル３００は図５において示されたような構成を有してもよい。メディアファイル３００は、例えば、メディアコンテンツデータベース１０６に格納されたＩＳＭＡＣｒｙｐファイルから直接図１のストリーム生成器１１６により読み出されてもよい。

メディアファイル３００のコンテンツに基づいて、ストリーム生成器１１６は、従来の方法で（暗号化された）ＥＬメディアストリーム２０２を生成する。ストリーム生成器１１６は、記録メタ情報チャネル２０４を介して送出されるトラックレイアウト情報を、メディアファイル３００から更に導出する。しかし、ストリーム生成器１１６によるＢＬデータの処理は従来の処理とは異なる。特に、図１１において示されたように、ストリーム生成器１１６は、ＩＳＭＡＣｒｙｐから従来のものへの変換器１２０を備える。変換器１２０は、ＳＶＣ ＢＬサブビットストリームの受信をサポートするがＩＳＭＡＣｒｙｐストリーミング形式をサポートしない従来の装置により受信されるのに適したストリーミング形式へと、メディアファイル３００から読み出されたサンプルを変換するように構成される。そのような従来の装置によりサポートされてもよい形式の一例は、Ｈ．２６４／ＡＶＣ（ＲＦＣ３９８４）のためのＲＴＰペイロード形式である。一般に、ＩＳＭＡＣｒｙｐから従来のものへの変換処理は、メディアファイル３００から読み出されたサンプルからＩＳＭＡＣｒｙｐヘッダを除去することを含む。従って、ストリーム生成器１１６は、従来の形式で（すなわち、ＩＳＭＡＣｒｙｐヘッダを使用せずに）、暗号化されていないＢＬサブフレームを含むＢＬストリーム２００を生成してもよい。

ＩＳＭＡＣｒｙｐをサポートしない従来のＳＶＣクライアント１０４は、暗号化されていないＢＬストリーム２００を介して受信されたメディアコンテンツのみをデコードするかあるいは格納するだろう。一方、ＩＳＭＡＣｒｙｐをサポートするＳＶＣクライアント１０４は、ＢＬストリーム２００がＩＳＭＡＣｒｙｐ仕様に準拠しないため、格納する前に別個に処理されなければならないが、迅速なデコード及びレンダリングのために変形は必要とされないことを認識する必要がある。

ＩＳＭＡＣｒｙｐをサポートするＳＶＣクライアント１０４は、ＩＳＭＡＣｒｙｐ対応のファイル形式で図９において示されたようにメディアストリーム２００、２０２を格納できるように図１２において示されたように変形されてもよい。特に、図１２において示されたようなストリームプロセッサ１４４は、ＳＶＣクライアント１０４の入力インタフェース１３０とデータ記憶装置１３２との間に（図１を参照）接続されてもよい。

ストリームプロセッサ１４４は、ＢＬストリーム２００（暗号化されていないＢＬサブフレームを含み、ＳＶＣ ＢＬサブビットストリームの受信をサポートするがＩＳＭＡＣｒｙｐストリーミング形式をサポートしない従来の装置により受信されるのに適したストリーミング形式、例えばＲＦＣ３９８４に従ってフォーマットされ、一般にＩＳＭＡＣｒｙｐヘッダを含まない）を、メディアファイル３００に格納される、ＩＳＭＡＣｒｙｐ対応の形式に変換できる、従来のものからＩＳＭＡＣｒｙｐへの変換器１４６を備える。このため変換器１４６は、ＩＳＭＡＣｒｙｐヘッダを暗号化されていないＢＬサブフレームの各々に付加する。変換器１４６は、ＢＬストリーム２００をＩＳＭＡＣｒｙｐストリーミング形式に準拠する形式に変換する更なる動作を実行してもよい。選択的暗号化というＩＳＭＡＣｒｙｐの機能に従って、従来のものからＩＳＭＡＣｒｙｐへの変換器１４６により出力されたＩＳＭＡＣｒｙｐヘッダは、関連付けられたＢＬサブフレームが暗号化されていないことを示す。ＥＬメディアストリーム２０２はストリーム生成器１４４により特に処理されず、また、記録メタ情報チャネル２０４を介して受信されたトラックレイアウト情報は変形されない。

図９〜図１２の上記の説明から明らかとなったように、本明細書において説明された技術は、部分的にはＩＳＭＡＣｙｒｐ保護されたメディアストリームとして、且つ部分的には保護されていない状態で配信されるＳＶＣエンコードされたメディアコンテンツを記録するように適用されるのが更に有利である。その結果、ＩＳＭＡＣｒｙｐをサポートしない従来のＳＶＣクライアント１０４は、暗号化されていないメディアストリームを依然として格納し且つデコードしてもよく、ＩＳＭＡＣｒｙｐをサポートするＳＶＣクライアント１０４は、実装のためのわずかな追加的な努力によって、ＩＳＭＡＣｒｙｐ仕様に準拠しない保護されていないメディアストリームを格納することができる。

図９〜図１２は、ＢＬストリーム２００が暗号化されていない実施形態を参照するが、ＢＬストリームがオプションとして（例えば、従来の装置が従来のコンテンツ保護機能を搭載する場合、ＩＳＭＡＣｒｙｐとは異なる暗号プロトコルに従って）暗号化されてもよいことは、明らかとなるだろう。ＢＬストリーム２００に対応する暗号化されたＢＬストリームは、暗号化された形式で既に受信されてもよく、あるいは暗号化された形式で取得されてもよい。あるいは、暗号化されていない基本層ストリームは、図９においてストリーム生成器１１６の一部であってもよい更なる暗号化ユニットにより暗号化されてもよい。図１０及び図１１に従って、暗号化ユニットは変換器１２０の一部であってもよく、対応する復号化ユニットは変換器１４６の一部であってもよい。

上記において、本明細書において開示された技術を実現する原理、好適な実施形態及び種々のモードが例示的に説明された。しかし、本発明は、上述した特定の原理、実施形態及びモードに限定されるものとして解釈されるべきではない。以下の請求の範囲により規定されるような本発明の範囲から逸脱することなく、当業者により変形及び変更がなされてもよいことは、理解されるだろう。

Claims (27)

1. メディアファイルの複数のメディアトラックを介してアクセス可能となるメディアコンテンツを扱う方法であって、
   第１のメディアトラックを介してアクセス可能となる、１以上の第１の層のデータアイテムのセットを与える工程と、
   少なくとも１つの第２のメディアトラックを介してアクセス可能となる、１以上の第２の層のデータアイテムのセットを与える工程と、
   前記第１の層のデータアイテムへとアクセスできる前記第１のメディアトラックを識別することを可能とするトラックリファレンスインデックスを、第２の層のデータアイテムのそれぞれに関連付ける工程と、
   少なくとも前記第２の層のデータアイテムと前記関連付けられたトラックリファレンスインデックスとを暗号化する工程と、を含み、
   前記第１の層のデータアイテムのそれぞれは、前記メディアコンテンツの一部分としてレンダリングされるようにデコード可能であり、
   前記第２の層のデータアイテムのそれぞれは、前記メディアコンテンツの強化部分として、デコードされた少なくとも１つの第１の層のデータアイテムと組み合わせてレンダリングされるように、デコード可能である
   ことを特徴とする方法。
2. 少なくとも前記第１のメディアトラックの、前記メディアファイルにおける配置を示す、トラックレイアウト情報を生成する工程をさらに含むことを特徴とする、請求項１に記載の方法。
3. 前記トラックレイアウト情報は、少なくとも前記第１のメディアトラックの、前記メディアファイルにおける配置を制御する指示を含み、
   前記方法はさらに、前記トラックレイアウト情報に従って前記トラックリファレンスインデックスを生成する工程を含む
   ことを特徴とする、請求項２に記載の方法。
4. 前記第１の層のデータアイテムを含む第１のメディアストリームと、前記暗号化されたトラックリファレンスインデックスとともに前記暗号化された第２の層のデータアイテムを含む第２のメディアストリームと、を生成する工程をさらに備えることを特徴とする、請求項１乃至３の何れか１項に記載の方法。
5. 前記第１のメディアストリーム、前記第２のメディアストリーム、及び前記トラックレイアウト情報を送信する工程をさらに含むことを特徴とする、少なくとも請求項２と組み合わせられた請求項４に記載の方法。
6. 前記トラックレイアウト情報は、前記第１のメディアストリーム及び前記第２のメディアストリームとは別個に送信されることを特徴とする、請求項５に記載の方法。
7. 前記第１のメディアストリームを生成する工程が、前記第１の層のデータアイテムを、前記第２の層のデータアイテムの第２の層の形式とは異なる第１の層の形式へと変換する工程を含むか、又は
   前記第２のメディアストリームを生成する工程が、前記第２の層のデータアイテムを、前記第１の層のデータアイテムの前記第１の層の形式とは異なる前記第２の層の形式へと変換する工程を含む
   ことを特徴とする、請求項４乃至６の何れか１項に記載の方法。
8. 前記第２の層の形式は暗号化プロトコル形式であり、前記第１の層の形式は前記暗号化プロトコル形式とは互換性のない従来の形式であることを特徴とする、請求項７に記載の方法。
9. 前記第１の層のデータアイテムを暗号化する工程をさらに含むことを特徴とする、請求項１乃至８の何れか１項に記載の方法。
10. 前記第１のメディアストリームが、前記暗号化された第１の層のデータアイテムを含むことを特徴とする、少なくとも請求項４と組み合わせられる請求項９に記載の方法。
11. 前記第１の層のデータアイテムは第１の暗号化鍵で暗号化され、前記第２の層のデータアイテム及び前記トラックリファレンスインデックスは前記第１の暗号化鍵とは異なる少なくとも１つの第２の暗号化鍵で暗号化されることを特徴とする、請求項９又は１０に記
12. メディアファイルの複数のメディアトラックを介してアクセス可能となるメディアコンテンツを扱う方法であって、
    １以上の第１の層のデータアイテムのセットを受信する工程と、
    前記メディアファイルの第１のメディアトラックを介してアクセス可能となるように、前記第１の層のデータアイテムを格納する工程と、
    １以上の暗号化された第２の層のデータアイテムのセットを受信する工程であって、前記暗号化された第２の層のデータアイテムは、前記第１のメディアトラックを前記第１の層のデータアイテムとともに識別することを可能とする、関連付けられた暗号化されたトラックリファレンスインデックスとともに受信される工程と、
    少なくとも１つの第２のメディアトラックを介してアクセス可能となるように、前記暗号化されたトラックリファレンスインデックスとともに前記暗号化された第２の層のデータアイテムを格納する工程と、を含み、
    前記第１の層のデータアイテムのそれぞれは、前記メディアコンテンツの一部分としてレンダリングされるようにデコード可能であり、
    前記第２の層のデータアイテムのそれぞれは、前記メディアコンテンツの強化部分として、デコードされた少なくとも１つの第１の層のデータアイテムと組み合わせてレンダリングされるように、デコード可能である
    ことを特徴とする方法。
13. トラックレイアウト情報を与える工程をさらに含み、
    少なくとも前記第１のメディアトラックの、前記メディアファイルにおける配置は、前記トラックレイアウト情報によって制御される
    ことを特徴とする、請求項１２に記載の方法。
14. 前記データアイテムは前記メディアトラックの外に格納され、
    前記メディアトラックは、前記データアイテムがレンダリングされる順序を示す、前記データアイテムへの参照を有する
    ことを特徴とする、請求項１２又は１３に記載の方法。
15. 前記暗号化された第２の層のデータアイテムと、前記暗号化されたトラックリファレンスインデックスと、を復号化する工程をさらに含むことを特徴とする、請求項１２乃至１４の何れか１項に記載の方法。
16. 前記暗号化された第２の層のデータアイテムと、前記暗号化されたトラックリファレンスインデックスとを復号化する、少なくとも１つの復号化鍵を受信する工程をさらに含み、
    前記少なくとも１つの復号化鍵は、前記暗号化されたトラックリファレンスインデックスとともに前記暗号化された第２の層のデータアイテムが格納された後に受信されることを特徴とする、請求項１５に記載の方法。
17. 前記受信された第１の層のデータアイテムは暗号化されていることを特徴とする、請求項１２乃至１６の何れか１項に記載の方法。
18. 前記暗号化された第１の層のデータアイテムを、第１の復号化鍵で復号化する工程と、
    前記暗号化された第２の層のデータアイテムと前記暗号化されたトラックリファレンスインデックスとを、前記第１の復号化鍵とは異なる少なくとも１つの第２の復号化鍵で復号化する工程と、
    をさらに含むことを特徴とする、請求項１７に記載の方法。
19. 前記メディアトラックのうちの少なくとも１つを読み出す工程と、
    前記読み出された少なくとも１つのメディアトラックを介してアクセス可能な前記メディアコンテンツをレンダリングする工程と、
    をさらに含むことを特徴とする、請求項１２乃至１８の何れか１項に記載の方法。
20. 第１のメディアストリームを介して、第１の層の形式で前記第１の層のデータアイテムを受信する工程と、
    第２のメディアストリームを介して、第２の層の形式で前記暗号化された第２の層のデータアイテムと前記暗号化されたトラックリファレンスインデックスとを受信する工程と、
    前記第１の層のデータアイテムを前記第２の層の形式と互換性のある形式へと変換する工程と、
    をさらに含むことを特徴とする、請求項１２乃至１９の何れか１項に記載の方法。
21. 前記第１の層のデータアイテム、前記暗号化された第２の層のデータアイテム、及び前記暗号化されたトラックリファレンスインデックスのうちの少なくとも１つを含む、少なくとも１つのメディアストリームを生成する工程と、
    前記少なくとも１つのメディアストリームを送信する工程と、
    を含むことを特徴とする、請求項１２乃至２０の何れか１項に記載の方法。
22. １以上のコンピューティングデバイスによって実行された時に、請求項１乃至２１の何れか１項に記載の各工程を実行するプログラムコード部分を備える、コンピュータプログラム。
23. コンピュータ読み取り可能な媒体に格納された、請求項２２に記載のコンピュータプログラム。
24. メディアファイル（３００）の複数のメディアトラック（３０６，３０８）を介してアクセス可能となるメディアコンテンツを扱うデバイス（１０２）であって、
    第１のメディアトラック（３０６）を介してアクセス可能となる、１以上の第１の層のデータアイテムのセットを与えるように構成された第１のユニット（１０８）と、
    少なくとも１つの第２のメディアトラック（３０８）を介してアクセス可能となる、１以上の第２の層のデータアイテムのセットを与えるように構成された第２のユニット（１１０）と、
    前記第１の層のデータアイテムへとアクセスできる前記第１のメディアトラック（３０６）を識別することを可能とするトラックリファレンスインデックスを、第２の層のデータアイテムのそれぞれに関連付けるように構成された、トラックリファレンスインデックス作成モジュール（１１２）と、
    少なくとも前記第２の層のデータアイテムと、前記関連付けられたトラックリファレンスインデックスと、を暗号化するように構成された暗号化モジュール（１１４）と、を備え、
    前記第１の層のデータアイテムのそれぞれは、前記メディアコンテンツの一部分としてレンダリングされるようにデコード可能であり、
    前記第２の層のデータアイテムのそれぞれは、前記メディアコンテンツの強化部分として、デコードされた少なくとも１つの第１の層のデータアイテムと組み合わせてレンダリングされるように、デコード可能である
    ことを特徴とするデバイス。
25. メディアファイル（３００）の複数のメディアトラックを介してアクセス可能となるメディアコンテンツを扱うデバイス（１０４）であって、
    １以上の第１の層のデータアイテムのセットと、１以上の暗号化された第２の層のデータアイテムのセット及び関連付けられた暗号化されたトラックリファレンスインデックスとを受信するように構成された入力インタフェース（１３０）と、
    前記メディアファイルの第１のメディアトラック（３０６）を介してアクセス可能となるように、前記第１の層のデータアイテムを格納し、かつ少なくとも１つの第２のメディアトラック（３０８）を介してアクセス可能となるように、前記暗号化されたトラックリファレンスインデックスとともに前記暗号化された第２の層のデータアイテムを格納するように構成されたデータ格納部（１３２）と、を備え、
    前記第１の層のデータアイテムのそれぞれは、前記メディアコンテンツの一部分としてレンダリングされるようにデコード可能であり、
    前記第２の層のデータアイテムのそれぞれは、前記メディアコンテンツの強化部分として、デコードされた少なくとも１つの第１の層のデータアイテムと組み合わせてレンダリングされるように、デコード可能である
    ことを特徴とするデバイス。
26. 前記暗号化された第２の層のデータアイテムと前記暗号化されたトラックリファンスインデックスとを少なくとも復号化するように構成された、少なくとも１つの復号化モジュール（１３４）と、
    前記メディアトラックのうち少なくとも１つを読み出し、かつ前記読み出された前記少なくとも１つのメディアトラックを介してアクセス可能な前記メディアコンテンツをレンダリングするように構成された、レンダリングモジュール（１３８）と、
    をさらに備えることを特徴とする、請求項２５に記載のデバイス。
27. 前記第１の層のデータアイテム、前記暗号化された第２の層のデータアイテム、及び前記暗号化されたトラックリファレンスインデックスのうちの少なくとも１つを含む少なくとも１つのメディアストリームを生成するように構成されたストリーミングモジュール（１４０）をさらに備えることを特徴とする、請求項２５又は２６に記載のデバイス。

Images