エレメンタリストリームコンテンツの保護
エレメンタリストリームメディアコンテンツを保護することが説明される。一態様では、エレメンタリストリームコンテンツのメディアアクセスユニット（ＭＡＵ）が識別される。それぞれのＭＡＵは、単一のビデオまたはオーディオフレームを表す１つまたは複数のデータセグメントを含む。暗号境界は、ＭＡＵ毎に選択される。暗号境界は、それぞれのＭＡＵに関連付けられている１つまたは複数のデータセグメントに基づく。それぞれのＭＡＵの一部が、対応する暗号境界に基づいて暗号化される。それぞれのＭＡＵは、ＭＡＵペイロードフォーマットにマッピングされる。ＭＡＵペイロードフォーマットにより、メディアコンシューマは、どの異なるエレメンタリストリームとも無関係にエレメンタリストリームコンテンツに関連付けられているそれぞれのエレメンタリストリームを処理することができる。ＭＡＵペイロードフォーマットでも、メディアコンシューマは、他のどのＭＡＵとも無関係にエレメンタリストリーム内のそれぞれのＭＡＵを処理することができる。
【発明の詳細な説明】
【技術分野】
【０００１】
メディアセンターは、典型的には、メディアコンテンツを配送する保護されたトランスポートストリームから暗号化を除去し、トランスポートストリーム（ＴＳ）を逆多重化（demultiplex）してエレメンタリストリーム（ＥＳ）にし、その後、再暗号化し、ネットワーク接続を介してメディアサブスクライバ（コンシューマ、クライアントなど）に配信する。復号化されたコンテンツは、著作権侵害およびその他の機密保護違反に対し脆弱であるため、メディアセンターによるそのような復号化および再暗号化オペレーションは機密保護を危険に晒す可能性がある。「メディアコンテンツ」は、ビデオ、オーディオコンテンツ、画像、アニメーション、テキストなどの１つまたは複数を含みうる「コンテンツ」、および「メディア信号」と同義である。
【背景技術】
【０００２】
セットトップボックス（ＳＴＢ）、デジタルメディア受信機（ＤＭＲ）、およびパーソナルコンピュータ（ＰＣ）などのメディアサブスクライバは、典型的には、メディアセンター、またはコンテンツソースから保護されたメディアコンテンツを受信する。保護されたメディアコンテンツは、ネットワーク接続を介して伝送される、または記憶媒体からダウンロードされる、暗号化されたオーディオ／ビデオデータを含む。
【発明の開示】
【発明が解決しようとする課題】
【０００３】
暗号化されたメディアコンテンツを（例えば、インデックス作成のため）処理する場合、メディアサブスクライバは、典型的には、メディアコンテンツ保護を除去する（つまり、メディアンコンテンツを復号化する）必要がある。このような復号化オペレーションは、典型的には、かなりのデバイスリソースを消費し、デバイスの性能を低下させ、その結果、デバイスの応答性および機能性を損なう可能性がある。
【０００４】
この「発明の開示」では、以下の「発明を実施するための最良の形態」でさらに説明される簡素化された形式の概念の選択を導入する。この「発明の開示」は、請求されている主題の鍵となる特徴または本質的特徴を明示することを意図しておらず、また請求されている主題の範囲を確定する補助として使用されることも意図していない。
【課題を解決するための手段】
【０００５】
上記に照らして、エレメンタリストリームメディアコンテンツを保護することについて説明される。一態様では、ＥＳコンテンツのメディアアクセスユニット（ＭＡＵ）が識別される。それぞれのＭＡＵは、単一のビデオまたはオーディオフレームを表す１つまたは複数のデータセグメントを含む。暗号境界は、ＭＡＵ毎に選択される。暗号境界は、それぞれのＭＡＵに関連付けられている１つまたは複数のデータセグメントに基づく。それぞれのＭＡＵの一部が、対応する暗号境界に基づいて暗号化される。それぞれのＭＡＵは、ＭＡＵペイロードフォーマットにマッピングされる。ＭＡＵペイロードフォーマットにより、メディアコンシューマは、どの異なるＥＳとも無関係にＥＳコンテンツに関連付けられているそれぞれのＥＳを処理することができる。ＭＡＵペイロードフォーマットでも、メディアコンシューマは、他のどのＭＡＵとも無関係にＥＳ内のそれぞれのＭＡＵを処理することができる。
【０００６】
詳細な説明は、付属の図面を参照しつつ説明される。
【発明を実施するための最良の形態】
【０００７】
概要
メディアコンテンツ固有の特性に基づいて暗号境界を選択することによりＥＳコンテンツを保護するシステムおよび方法が説明される。より具体的には、これらのシステムおよび方法では、ＥＳのメディアアクセスユニット（ＭＡＵ）の一部を（例えば、ＭＰＥＧ−２などを使用して）暗号化する。それぞれのＭＡＵは、単一のビデオまたはオーディオフレーム（エレメンタリストリームフレーム）および関連するヘッダである。ＭＡＵは、１つまたは複数のデータセグメントを含む。それぞれのデータセグメントは、コンテンツ暗号化パラメータの同じ集合が適用されるＭＡＵの連続するセクションである。データセグメントは、完全に暗号化されているか、または完全に平文である（つまり、暗号化されていない）。ＥＳは、ＴＳに由来していない場合がある。しかし、これらのＥＳ保護オペレーションは、ＴＳストリームに適用される共通スクランブルオペレーションと互換性を持つ。
【０００８】
ＴＳが保護されたＥＳコンテンツを含む場合、ＴＳは、既存の暗号化を維持しながらＥＳに逆多重化される（つまり、ＴＳは、復号化されない）。ＥＳは、ＭＡＵペイロードフォーマット（ＭＰＦ）にマッピングされ、これにより、ＥＳのＭＡＵがトランスポートプロトコル（例えば、リアルタイムトランスポートプロトコル（ＲＴＰ））の中にカプセル化され、その後ＰＣおよびセットトップボックスなどのメディアコンシューマに伝達される。それぞれのＭＡＵをＭＰＦにマッピングすることで、他のＥＳと無関係にそれぞれのＥＳを処理（例えば、逆多重化、インデックス作成、格納など）し、他のＭＡＵとは無関係にそれぞれのＭＡＵを処理するのに十分な情報がメディアコンシューマに与えられる。これらの技術は、１つまたは複数のデータセグメントからなるＭＡＵ部分に暗号化を適用することによりＥＳコンテンツを保護しない従来のシステムとは対照的である。
【０００９】
ＥＳコンテンツを保護するシステムおよび方法のこれらの態様および他の態様について、図１から１４を参照しつつさらに詳しく説明することにする。
例示的な装置
説明のため、また必要というわけではないが、パーソナルコンピュータなどのコンピューティングデバイスによって実行されるコンピュータ実行可能命令の一般的背景状況においてＥＳコンテンツの保護について説明する。一般に、プログラムモジュールは、特定のタスクを実行する、または特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。これらのシステムおよび方法は、前記の文脈において説明されているが、以下で説明される活動およびオペレーションは、ハードウェアでも実装することができる。
【００１０】
図１は、ＥＳコンテンツを保護する例示的なシステム１００を示している。システム１００は、汎用コンピューティングデバイス１０２を含む。コンピューティングデバイス１０２は、パーソナルコンピュータ、ラップトップ、サーバー、ハンドヘルドまたはモバイルコンピューティングデバイスなどのどれかのタイプのコンピューティングデバイスを表す。コンピューティングデバイス１０２は、コンピュータ可読媒体１０６に結合されたプロセッサ１０４を備える。コンピュータ可読媒体１０６は、コンピューティングデバイス１０２によってアクセス可能な媒体であればどのような媒体でも使用可能であり、揮発性および不揮発性媒体（例えば、読み取り専用メモリ（ＲＯＭ）およびランダムアクセスメモリ（ＲＡＭ））、取り外し可能および取り外し不可能媒体を含む。コンピュータ可読媒体１０６のＲＡＭ部分は、プロセッサ１０４から直接アクセス可能な、および／またはプロセッサ１０４によって現在操作されているプログラムモジュールおよびプログラムデータを格納する。
【００１１】
例えば、限定はしないが、コンピュータ可読媒体１０６は、プログラムモジュール１０８およびプログラムデータ１１０を格納する。例えば、プログラムモジュール１０８は、ＥＳ保護モジュール１１２、保護ＥＳコンテンツマッピングモジュール１１４、および他のプログラムモジュール１１６（例えば、オペレーティングシステム）を含む。ＥＳ保護モジュール１１２は、メディアコンテンツ固有の特性に基づいて暗号境界を選択することによりＥＳコンテンツを保護する。より具体的には、ＥＳ保護モジュール１１２は、ＥＳコンテンツ１１８を（例えば、ＭＰＥＧ−２などを使用して）暗号化して、保護されたＥＳコンテンツ１２０を生成する。この目的のために、ＥＳ保護モジュール１１２は、ＥＳを含むメディアアクセスユニット（ＭＡＵ）の部分（つまり、データセグメント）に暗号化を適用する。一実装では、暗号化オペレーションは、カウンタモードの高度暗号化標準（ＡＥＳ）である。それぞれのＭＡＵは、単一のビデオまたはオーディオフレーム（エレメンタリストリームフレーム）であり、これは、その後、ヘッダ（例えば、開始コードおよびパディングビット）と関連付けられる。それぞれのＭＡＵは、１つまたは複数のデータセグメントを含む。それぞれのデータセグメントは、ＥＳ保護モジュール１１２がコンテンツ暗号化パラメータの同じ集合を適用するＭＡＵの連続するセクションである。ＥＳ保護モジュール１１２は、データセグメントを完全に暗号化するか、またはそのデータセグメントを完全に平文として残す。ＥＳは、ＴＳに由来していない場合がある。しかし、これらのＥＳ保護オペレーションは、ＴＳストリームに適用される共通スクランブルオペレーションと互換性を持つ（例えば、「他のデータ」１２２を参照）。
【００１２】
保護ＥＳコンテンツマッピングモジュール１１４（「マッピングモジュール１１４」）は、保護されたＥＳコンテンツ１２０をＭＡＵペイロードフォーマット（ＭＰＦ）にマッピングし、トランスポートパケット１２４内にカプセル化する。ＭＰＦでは、ＭＡＵの一部分が暗号化されないまま渡せる（平文に残される）。また、ＭＰＦは、パーソナルコンピュータまたはセットトップボックス（例えば図２を参照）などのメディアコンシューマが他のＥＳと無関係にそれぞれの保護されているＥＳ １２０を処理し、他のＭＡＵと無関係に保護されているＥＳ中のそれぞれのＭＡＵを処理するのに十分な情報を提供する。ＭＰＦは、「トランスポートプロトコルカプセル化のための保護されているＥＳのマッピング」という表題の節を参照しつつ以下で詳しく説明される。一実装では,トランスポートパケットは、リアルタイム転送プロトコル（ＲＴＰ）に基づくパケットに対応する。
【００１３】
一実施形態では、ＥＳコンテンツ（例えば、ＥＳコンテンツ１１８）は、メディアコンテンツトランスポートストリームに由来しない。例えば、他の実施形態では、図２を参照しつつ以下で説明されるように、ＥＳコンテンツはトランスポートストリームに由来する。さらに、例示的なシステム１００は、ＥＳ保護モジュール１１２と同じコンピューティングデバイス内に実装されている保護ＥＳコンテンツマッピングモジュール１１４を示しているが、マッピングモジュール１１４は、保護モジュール１１２を実装するコンピューティングデバイスと異なるコンピューティングデバイスに実装することができる。このような代替え実装は、図２に関して以下で説明されるが、保護モジュール１１２のオペレーションは、コンテンツソースにより実行され、マッピングモジュール１１４のオペレーションは、メディアセンターにより実行される。
例示的なシステム
図２は、一実施形態により、ＥＳコンテンツがトランスポートストリームに由来する、ＥＳコンテンツを保護する例示的なシステム２００を示している。トランスポートストリームは、メディアコンテンツをカプセル化する。例えば、システム２００は、ネットワーク２０６を介して１つまたは複数のメディアサブスクライバ２０８に結合されているコンテンツソース２０２およびメディアセンター２０４を含む。コンテンツソース１００は、ビデオゲームサーバー、Ｗｅｂサイト、ビデオサーバー、ミュージックサーバー、ソフトウェアアーカイブ、データベース、テレビネットワークなどに関連付けることができる。コンテンツソース２０２のＴＳスクランブルモジュール２１０は、トランスポートストリームを暗号化する。一実装では、トランスポートストリーム暗号化２１０では、トランスポートストリームを共通スクランブルする。共通スクランブルにより、ストリームの暗号化された部分を復号化しなくても、暗号化されたトランスポートストリームを処理（例えば、逆多重化、インデックス作成など）することができる。ＴＳスクランブルモジュール２１０は、図１のＥＳ保護モジュール１１２に関して上で説明されているように、モジュールの関連するオペレーションがＴＳストリームに適用される共通スクランブルオペレーションと互換性を有するので、トランスポートストリームに由来するＥＳコンテンツを保護する。
【００１４】
メディアセンター２０４は、例えば、伝送制御プロトコル／インターネットプロトコル（ＴＣＰ／ＩＰ）または他の標準的な通信プロトコルを使用して、コンテンツソース２０２に、直接またはネットワーク２０６を介して結合できる中央集中配置コンピューティングデバイスである。ネットワーク２０６の実施例は、ＩＰネットワーク、ケーブルテレビ（ＣＡＴＶ）ネットワーク、および直接放送衛星（ＤＢＳ）ネットワークを含む。メディアセンター２０４は、逆多重化およびマッピングモジュール２１２を備える。モジュール２１２は、単一のコンピュータプログラムモジュールとして示されているが、任意の数のコンピュータプログラムモジュールにより実装することができる。プログラムモジュール２１２の逆多重化オペレーションは、ＴＳの暗号化部分を復号化することなく、ＴＳをそれぞれのＥＳに逆多重化する。
【００１５】
プログラムモジュール２１２のマッピングオペレーションは、逆多重化された保護されているＥＳコンテンツをＭＰＦに、図１の保護ＥＳコンテンツマッピングモジュール１１４の説明されているオペレーションによりマッピングし、その後、トランスポートパケットにカプセル化してメディアコンシューマに伝達する。上述のように、ＭＰＦを使用すると、（複数の）トランスポートパケットにカプセル化されたときに、ＭＡＵのデータセグメントを平文のままに残すことができる。また、ＭＰＦは、メディアサブスクライバ２０８が他のＥＳと無関係に受け取った、保護されているＥＳを処理し、他のＭＡＵと無関係に保護されているＥＳ内のそれぞれの関連するＭＡＵを処理するのに十分な情報を提供する。ＭＰＦは、「トランスポートプロトコルカプセル化のための保護されているＥＳのマッピング」という表題の節を参照しつつ以下で詳しく説明される。一実装では,トランスポートパケットは、リアルタイム転送プロトコル（ＲＴＰ）に基づくパケットに対応する。
【００１６】
メディアセンター２０４は、ネットワーク２０６上でカプセル化され保護されているＥＳコンテンツを１つまたは複数のサブスクライバ２０８に伝達し、ＰＣ ２１４および／またはＳＴＢ ２１６は、メディアコンテンツを受信する。ＰＣ ２１４上で処理され、レンダリングされたメディアコンテンツは、ＰＣ ２１４に関連付けられているモニタに表示させることができ、ＳＴＢ ２１６上で処理され、レンダリングされたメディア信号は、テレビ（ＴＶ）２１８または類似の表示デバイス上に表示させることができる。一実装では、ＴＶ ２１８は、ＳＴＢ ２１６の機能が内蔵されている。
トランスポートストリーム共通スクランブル分析
一実装では、ＥＳコンテンツは、トランスポートストリームにより配送される。このシナリオでは、コンテンツソース２０２のＴＳスクランブルモジュール２１０は、共通スクランブルを行うためにトランスポートストリームを分析する。特に、トランスポートストリームは、暗号化された後にトランスポートストリームに適用されうる少なくとも１つのプロセスに対するデータ要件に照らして分析される。プロセスの１つまたは複数に対応する統計モデルに基づいて決定がなされる場合、最も広範な（つまり、閾値）データ要件を有する特定のプロセスについて閾値データ要件を決定することができる。この分析は、トランスポートストリームのどの部分が暗号化されないまま通るかを決定するために実行される。
【００１７】
共通スクランブル分析は、ヘッダ情報を含むトランスポートストリーム内のパケットが暗号化されないまま通ることの確認を組み込むことができる。このようなパケットおよびヘッダ情報については、図６を参照しつつ以下で説明される。ＰＥＳヘッダ情報の一部または「追加ヘッダデータ」の一部を含むパケットは、暗号化されずに通る。さらに、完全な、または部分的なストリームマークを含むパケットも、暗号化されずに通る。
【００１８】
【表１】
【００１９】
表１を参照すると、この実装において平文のまま残されるデータの量は、ストリームマークの長さに最大データペイロード長を加えた値に対応することがわかる。平文セクションは、ストリームマークの前から始まり、ストリームマークと最大データペイロード長とを組み合わせた長さ分の後のところで終わるが、ただし組み合わされた長さが、例えば、２つの連続するＴＳパケットペイロードの長さを超えない場合に限ることに留意されたい。例えば、送信機（例えば、図２のコンテンツソース２０２など）は、シーケンスヘッダを表すストリームマークに対し平文中に１６から３６８バイトを残すことができる（ストリームマークに対する４バイトと最大データペイロード長に対する１２バイト）。
【００２０】
また、ストリームマークが現在のＭＡＵの始まりの近くに出現する場合に、前のＭＡＵからのある量のデータを平文中に残すことも可能である。一実装において、これは、平文セクションの長さが３６８バイトを超えない場合に許容される。
【００２１】
トランスポートストリームの一部が暗号化されないまま通るので、他の代替え実施形態では、中に含まれるデータが、逆スクランブルなしでトランスポートストリームを処理するのに使用されない場合に共通スクランブルが適用されるフレームヘッダおよびＰＥＳヘッダを考慮する。
暗号化
図３は、カウンタモードで高度暗号化標準（ＡＥＳ）を使用してＥＳメディアコンテンツを暗号化するオペレーションの例示的な態様を示すブロック図である。図３に関して以下で説明されるさまざまなデータおよびオペレーションは、図１のＥＳ保護モジュール１１２の例示的なオペレーションおよび図２のＴＳスクランブルモジュール２１０の例示的なオペレーションを表している。データセグメントは、ＥＳを暗号化するときに、保護されるコンテンツのタイプに基づき異なる定義を有する場合があるが、任意の数のデータセグメントを含むＭＡＵは、ビデオまたはオーディオの単一のフレームを表す。
【００２２】
図３を参照すると、カウンタモードのＡＥＳは、トランスポートストリームのそれぞれのデータセグメントに基づいて複数のバイトからなるストリームを生成する。バイトのストリームとコンテンツの平文部分のバイトとのＸＯＲを取り、暗号化されたコンテンツを作成する。キーストリーム生成器は、ＡＥＳラウンドを使用して、キーストリームの１６バイトブロックを一度に生成する。ＡＥＳラウンドへの入力は、コンテンツ暗号化キー（ＫＣ）およびデータセグメントＩＤと新しいセグメント内のブロックＩＤとの１２８ビット連結である。キーストリーム生成器の出力とデータセグメントの対応するブロック（ｉ）からのデータとのＸＯＲが、バイト毎に取られる。データセグメントが１６バイトで均等に分割可能でない場合、最後のブロックからのデータセグメントの残りのバイトのみと、キーストリームとのＸＯＲが取られ、中の暗号化されたデータ集合について保持される。ＭＡＵ、および関連するヘッダは、さらに多くのデータセグメントである。
【００２３】
図４は、保護されたＥＳを配送するトランスポートストリーム内に挿入する例示的な暗号方式（「ＴＡＧ」）パケットを示す。図４を参照すると、
● ａｄａｐｔａｔｉｏｎ＿ｆｉｅｌｄ＿ｃｏｎｔｒｏｌビットは、１０ｂに設定され（適応フィールドのみ、ペイロードなし）、したがって、連続カウンタを増分する必要はない。
● ＡＦヘッダは、ＭＰＥＧ規格に準拠する４バイトを含む。
【００２４】
○ 第１バイト＝適応フィールド長
○ 第２バイト＝適応フィールド存在フラグ（プライベートデータ＝０ｘ０２）
○ 第３バイト＝プライベートデータ長（ＤＲＭ長）
○ 第４バイト＝バージョン番号（現在は、０ｘ００）
● ＤｒｍＧｕｉｄは、｛Ｂ０ＡＡ４９６６−３Ｂ３９−４００Ａ−ＡＣ３５−４４Ｆ４１Ｂ４６Ｃ９６Ｂ｝に設定されたＧＵＩＤを含む。
● ｂａｓｅ＿ｃｏｕｎｔｅｒは、続く暗号化されたパケットについてＡＥＳカウンタの再同期処理を行う。
● ＳＭバイト（ストリームマーク）は、続くパケットが最初の数バイトが欠けている可能性のある、ストリームマークの先頭を含むことを示す。
【００２５】
○ ＳＭ＝０−次のパケットは、ＰＥＳヘッダの先頭またはＰＥＳヘッダ全体を配送する。
○ ＳＭ＝１−次のパケットは、ストリームマークの先頭を含む。
【００２６】
○ ＳＭ＝２−次のパケットは、第１バイト（００）が欠けている、ストリームマークの先頭を含む。
○ ＳＭ＝３−次のパケットは、最初の２バイト（００ ００）が欠けている、ストリームマークの先頭を含む。
【００２７】
○ ＳＭ＝４−次のパケットは、最初の３バイト（００ ００ ０１）が欠けている、ストリームマークの先頭を含む。
○ ＳＭ＝その他−予約。
● Ｐｒｉｖａｔｅ＿ＤＲＭ＿ｐａｒａｍｅｔｅｒｓは、対応するキーＩＤ値とともにキーＩＤ拡張集合を含む、データセグメント記述子を含む。データセグメントＩＤがＴＡＧパケットのｂａｓｅ＿ｃｏｕｎｔｅｒセクション内に示されているので、ＡＥＳ １２８初期化ベクトル拡張は、存在しない。
● パケットは、０ｘＦＦをパディングされる。
【００２８】
したがって、ＴＡＧパケットは、それぞれの保護されているＰＥＳユニットの前に挿入されるキー識別子（ＫＩＤ）を持つ単一のＴＳパケットである。この実装では、ＴＡＧパケットは、コンテンツがメディアコンシューマに配信されたときに一致するデジタル権利管理（ＤＲＭ）ライセンスを取り出すために使用される。コンテンツ保護レイヤは、カウンタモードでＡＥＳ １２８ビットキーを含み、その場合次の要件が適用される。１２８ビットカウンタは、ｂａｓｅ＿ｃｏｕｎｔｅｒ（ＭＳＢ）とｍｉｎｏｒ＿ｃｏｕｎｔｅｒ（ＬＳＢ）の２つの６４ビットフィールドに分割される。ｂａｓｅ＿ｃｏｕｎｔｅｒおよびｍｉｎｏｒ＿ｃｏｕｎｔｅｒは、上述のデータセグメントＩＤおよびブロックＩＤと同等である。ＴＡＧパケットは、トランスポートストリームの暗号化された部分で使用される暗号化アルゴリズムの識別を行い、復号化キーを推論するために権限のある暗号解読器に必要なデータを提供し、暗号化されないまま、または暗号化されて通るトランスポートストリームの部分を識別することができる。ＴＡＧパケットは、それぞれのプロセスに使用される暗号化されたストリームの部分を識別する他のデータを含むことができる（トリックモードまたはサムネイル抽出のための逆多重化またはインデックス作成）。さらに、ＴＡＧパケットは、多重化されたトランスポートストリームに従って挿入される。
【００２９】
ＴＡＧパケットは、トランスポートストリームのすべての暗号化された部分に対応する形で生成されうる。それとは別に、暗号方式パケットは、暗号化されたＰＥＳペイロードデータの個々のパケットまたはバイトに対応する形で生成されうる。そのため、ＴＡＧパケットは、トランスポートストリーム内のそれぞれのＰＥＳヘッダと対応する形で、またはトランスポートストリーム内の所定の数のＰＥＳヘッダに対応する形で、または他のプロセスについては暗号化されないまま通る所定のパターンのパケットに対応する形で生成されうる。
【００３０】
図５は、一実施形態により、送信機側でトランスポートストリーム内のＥＳコンテンツを保護するオペレーションの例示的な流れを示している（ＥＳコンテンツがトランスポートストリームにより配送されない場合と比べて）。以下のリストは、図５の態様を説明したものである。
● ｓｃｒ−この変数は、現在のＴＳパケットが共通スクランブルされる場合に「ｙｅｓ」に設定され、それ以外の場合には「ｎｏ」に設定される。
● ｋｅｙ＿ｓｙｎｃ−この変数は、送信機がＡＥＳキーを更新する場合に「ｙｅｓ」に設定され、それ以外の場合には「ｎｏ」に設定される。
● ＰＩＤ（１３ビット）−選択されたエレメンタリストリームのＰＩＤ値。
● ｂａｓｅ＿ｃｏｕｎｔｅｒ−この６４ビットフィールドは、送信機の存続期間全体にわたって送信機により一意に定義される。一実装では、ビット０から５０は、セクションカウンタを表し、ビット５１から６３は、そのＰＩＤについて予約されている。
● Ｓｅｃｔｉｏｎ＿ｃｏｕｎｔｅｒ（５１ビット）−ｓｃｒ状態変数のそれぞれのｎｏからｙｅｓへの遷移に対してインクリメントされる循環カウンタ。
● ｍｉｎｏｒ＿ｃｏｕｎｔｅｒ−１６個のスクランブルされたバイトからなるそれぞれのブロックに対しインクリメントされる６４ビットカウンタ。
● ｉ−それぞれスクランブルされたバイトに対しインクリメントされる４ビットカウンタ。
● ｓｃｒａｍｂｌｅ１６−ＡＥＳＫＥＹ［ｂａｓｅ＿ｃｏｕｎｔｅｒ ｜ ｍｉｎｏｒ＿ｃｏｕｎｔｅｒ］。
【００３１】
Ｒｅｐｌａｃｅ ＡＥＳ Ｋｅｙイベントが発生した後、送信機は、即座に、すべてのＰＩＤをスクランブルすることを停止し、それぞれのＰＥＳコンポーネントと再同期するまで停止したままになる。この遷移により、同じプログラムからのすべてのＰＩＤが同じキーでスクランブルされることが保証される。ｓｃｒステータスを定義するときに、送信機は、以下の条件のどれかが適用される場合に、受信されたＴＳパケット毎に、ｓｃｒ状態変数を「ｎｏ」に設定する。
● ｋｅｙ＿ｓｙｎｃ＝ｙｅｓ
● ＴＳパケットが、ＰＥＳヘッダの全部または一部を含む。
● ＴＳパケットが、以下の表に記載されているストリームマークの１つまたは複数の全部または一部を含む。ストリームマークは、上の表１に示されているように、ＭＰＥＧ開始コードとその続くデータペイロードからなる。
【００３２】
図６は、一実施形態による、例示的なトランスポートストリームを示している。送信機は、ＴＡＧパケットを平文中に残されているＴＳパケットの前に挿入する。図６に示されているように、以下の２つのシナリオが考えられる。ケースＡ：ＴＡＧパケットが、ＰＥＳヘッダの全部または一部を含むパケットの前に挿入される。ケースＢ：ＴＡＧパケットが、ストリームマークの全部または一部を含むパケットの前に挿入される。
さらに、実施形態では、ＴＡＧパケットがトランスポートストリーム内に挿入されることを必要としない。復号化の時点までＴＡＧパケットは必要ないため、復号化の時点にプロセッサにより受信される限り、ＴＡＧパケットは、プロセッサに帯域内または帯域外で（例えば、プライベートテーブルにより）送信することができる。それに加えて、ＴＡＧパケットは、その後帯域内または帯域外でプロセッサに送信されるコンテンツ利用ライセンスに送信されうる。
保護されているＥＳのＭＡＵペイロードフォーマットへのマッピング
保護されているＥＳは、共通スクランブルされたトランスポートストリーム内のＭＡＵのセクションが平文中に残されるようにＭＰＦにマッピングされる。このマッピングにより、メディアコンシューマはそれぞれのＭＡＵを独立に処理することができる。一実装では、コンテンツソース２０２などの送信機がこれらのマッピングオペレーションを実行する。
【００３３】
従来のＲＴＰヘッダの構文は、ＲＦＣ−３５５０において定義されており、また図１１に示されている。ＲＴＰヘッダとともに、図１のシステム１００および図２のシステム２００は、保護されているＥＳコンテンツ（例えば、図１の保護ＥＳコンテンツ１２０）をＭＡＵペイロードフォーマット（ＭＰＦ）にマッピングする。しかし、マルチメディアプレゼンテーションにおけるすべてのメディアストリームが、同じＭＰＦを使用する必要はなく、異なるペイロードフォーマットを使用することもできる。そこで、ＭＡＵがＭＰＦにおいてどのようにカプセル化されるかについて説明する。
【００３４】
図７は、一実施形態による、ＭＰＦヘッダの例示的な高水準構造を例示している。ヘッダは、標準ＲＴＰヘッダに関して示されている。ＭＰＦヘッダは、送信機（例えば、図１のコンピュータ１０２および／または図２のメディアセンター）により、トランスポートパケット内のそれぞれのＭＡＵ、またはそのフラグメントの前に挿入される。図７に示されているように、この例示的な実装におけるＭＰＦヘッダは、３つのセクションに分割される。それぞれのセクションは、１バイトビットフィールドから始まり、その後に１つまたは複数のオプションフィールドが続く。いくつかの場合において、ＭＰＦヘッダから、最大２つまでのセクションを丸ごと省くことができる。そのため、ＭＰＦヘッダは、１バイトと小さくすることができる。
【００３５】
ＭＰＦヘッダの後に、「ペイロード」が続く。ペイロードは、完全なＭＡＵ、またはそのフラグメントを含む。ペイロードは、部分的ＭＡＵを含み、複数のトランスポートパケット中の複数のペイロードにわたって大きなＭＡＵを断片化（フラグメント化）することができる。トランスポートパケットのサイズにより許されれば、第１のペイロードの後に、ＭＰＦヘッダとペイロードの追加の対を続けることができる。
【００３６】
図７において「Ｐａｃｋｅｔ Ｓｐｅｃｉｆｉｃ Ｉｎｆｏ（パケット指定情報）」と呼ばれる、ＭＰＦヘッダの第１のセクションは、トランスポートパケット内のすべてのペイロードに固有の情報を含む。「Ｐａｃｋｅｔ Ｓｐｅｃｉｆｉｃ Ｉｎｆｏ」セクションは、ＲＴＰヘッダの終わりの直後に出現する、第１のＭＰＦヘッダにおいて、それぞれのトランスポートパケット内に１回だけ含まれる。「ＭＡＵ Ｐｒｏｐｅｒｔｉｅｓ（ＭＡＵプロパティ）」と呼ばれる第２のセクションは、ペイロードを説明する情報を含む。例えば、このセクションでは、ペイロードがビデオＩフレームなどの同期点であるＭＡＵを含むかどうかを指定し、さらに、ペイロードのサイズがどのように決定されるかも指定する。さらに、このセクションは、前のパケットが失われた場合にトランスポートパケットを受信機側で解析するために使用される情報を含む。これは、ＭＡＵが複数のトランスポートパケット上に断片化されている場合に有用である。
【００３７】
「ＭＡＵ Ｔｉｍｉｎｇ（ＭＡＵタイミング）」と呼ばれる第３のセクションは、ペイロード中のＭＡＵに関連付けられているさまざまなタイムスタンプに関する情報を提供する。例えば、このセクションでは、ＭＡＵのプレゼンテーション時間がどのように決定されるかを指定する。このセクションは、さらに、追加の情報をＭＰＦヘッダに入れるための拡張機構も備える。
【００３８】
図８は、一実施形態による、図７のＭＰＦヘッダの例示的な詳細レイアウトを示している。図８の３つのセクション８０２から８０６はそれぞれ、複数の個別ヘッダフィールドを備える。これらのフィールドは、図８にボックスとして示されている。これらのボックスの高さは、ヘッダフィールドの相対的サイズを示すものとなっている。しかし、図は、完全に縮尺通りには描かれておらず、「Ｅｘｔｅｎｓｉｏｎ（拡張）」フィールドは可変長サイズを有することに留意されたい。
【００３９】
図８を参照すると、３つのセクションのそれぞれの中の第１のヘッダフィールドは、ビットフィールドである。セクション内の他のヘッダフィールドは、そのセクションのビットフィールドにより示された場合にのみ存在する。いくつかの場合において、そのビットフィールドを含む、１つのセクション全体を省くことができる。パケット指定情報（Ｉｎｆｏ）セクションは、「Ｂｉｔ Ｆｉｅｌｄ １（ビットフィールド１）」を含み、また図８に示されている他のフィールドのどれかも含みうる。同じトランスポートパケット内の追加のＭＰＦヘッダは、「Ｂｉｔ Ｆｉｅｌｄ ２（ビットフィールド２）」から始まり、「ＭＡＵ Ｐｒｏｐｅｒｔｉｅｓ」セクションおよび「ＭＡＵ Ｔｉｍｉｎｇ」セクション内にフィールドを備える。
【００４０】
可能な最も単純な場合には、トランスポートパケットは、単一の完全なＭＡＵを含む。この場合、ヘッダフィールドのすべてを含めることが可能である。しかし、必要のないフィールドは省くことができる。ＭＰＦヘッダの３つのセクションのそれぞれは、もし存在する場合、そのセクション内のフィールドのどれが存在するかを示すビットフィールドを有する。
【００４１】
例えば、現在のペイロードの終わりに対するバイトオフセットを指定する「Ｏｆｆｓｅｔ（オフセット）」フィールドは、パケットが単一のペイロードを含む場合には必要ないが、それは、ペイロードの長さが、トランスポートパケットのサイズにより推論できるからである。「Ｂｉｔ Ｆｉｅｌｄ ２」内の「ＯＰ」は、「Ｏｆｆｓｅｔ」フィールドが存在するかどうかを示す。「Ｂｉｔ Ｆｉｅｌｄ ３（ビットフィールド３）」内のビットのすべてが０である場合、「Ｂｉｔ Ｆｉｅｌｄ ３」それ自体を省くことができ、これは、「Ｂｉｔ Ｆｉｅｌｄ ２」内の「Ｂ３Ｐ」を０に設定することにより示される。
【００４２】
複数のペイロードを単一のトランスポートパケット内にまとめることが可能である。これは、「グルーピング」と呼ばれる。「Ｏｆｆｓｅｔ」フィールドは、「グルーピング」の使用を示す。「Ｏｆｆｓｅｔ」フィールドが存在する場合、他のＭＰＦヘッダおよび他のペイロードは、現在のペイロードの終わりの後から続くことができる。「Ｏｆｆｓｅｔ」フィールドは、「Ｏｆｆｓｅｔ」フィールド自体の終わりから数えた、現在のペイロードの終わりまでのバイトの個数を指定する。他のＭＰＦヘッダが現在のペイロードの終わりの後に続くかどうかを判定するために、いくつかの実装において、「Ｏｆｆｓｅｔ」フィールドの値だけでなく、トランスポートパケットのサイズをも考慮する必要があり、またＲＴＰがトランスポートプロトコルとして使用される場合に、もしあれば、ＲＴＰパディング領域のサイズも考慮する必要がある。
【００４３】
単一のＭＡＵを分割して複数のペイロードに分けることができる。これは、「断片化」と呼ばれる。断片化は、ＭＡＵが単一のトランスポートパケット内に収まることのできるものの大きさを超えた場合に主に使用される。「Ｂｉｔ Ｆｉｅｌｄ ２」内の「Ｆ」フィールドは、ペイロードが完全なＭＡＵまたはそのフラグメントを含むかどうかを示す。
【００４４】
「ＭＡＵ Ｔｉｍｉｎｇ」セクション内のフィールドは、ＭＡＵの第１のフラグメントを含むペイロードに対するＭＰＦヘッダ内でのみ指定すべきである。これに対する唯一の例外は、「ＭＡＵ Ｔｉｍｉｎｇ」セクション内の「Ｅｘｔｅｎｓｉｏｎ」フィールドが同じＭＡＵの異なるフラグメントに対し異なる拡張を含む場合である。ＭＡＵが断片化された場合に、「Ｂｉｔ Ｆｉｅｌｄ ２」内のビット「Ｓ」、「Ｄ１」、および「Ｄ２」は、第１のフラグメントを含むペイロードに対するＭＰＦヘッダでのみ有意である。したがって、受信機（メディアコンシューマ）は、「Ｆ」フィールドの値が０または２の場合にこれらのビットを無視する。
【００４５】
この実装では、ＭＡＵは、大きすぎて単一のトランスポートパケットに収まらないというのでない限り断片化されない。この実装では、ＭＡＵのフラグメントは、単一のトランスポートパケットにおいて、他のＭＡＵと、または他のＭＡＵのフラグメントと組み合わされることはない。しかし、受信機は、そのまま、これらのケースも取り扱える。これの実施例は、図９に示されている。
【００４６】
図９は、一実施形態により、ＭＰＦを使用するリアルタイムトランスポートパケットという３つのパケットの例示的シーケンスを示している。この３つのトランスポートパケットは、４つのＭＡＵからなるデータを配送する。第４のＭＡＵは、第４のトランスポートパケット（図示せず）内で続けられる。図は、もし必要ならば、固定サイズのトランスポートパケットを作成するためにＭＡＵの断片化をどのように使用できるかを示している。図からわかるように、ＭＡＵ ２は、２つのトランスポートパケットにわたって断片化されている。第１のトランスポートパケットでは、ＭＡＵ ２に対するＭＰＦヘッダは、次のトランスポートパケット内でＭＵＡ ２が継続されることを指定する。（これは、「Ｂｉｔ Ｆｉｅｌｄ ２」内の「Ｆ」フィールドを使用して知らされる）。
【００４７】
第２のトランスポートパケットは、「ＭＡＵ Ｔｉｍｉｎｇ」フィールドを省いたＭＰＦヘッダから始まるが、それは、ＭＡＵ２に対する「ＭＡＵ Ｔｉｍｉｎｇ」フィールドが、すでに、第１のトランスポートパケット内で指定されているからである。「ＭＡＵ Ｐｒｏｐｅｒｔｉｅｓ」セクションの「Ｏｆｆｓｅｔ」フィールドは、ＭＡＵ ３に対するペイロードフォーマットヘッダの先頭を見つけるために使用される。これにより、クライアントは、前のトランスポートパケットが失われたとしても、ＭＡＵ ３を復号化することができる。同様に、図は、ＭＡＵ ４が第２および第３のトランスポートパケット上にどのように断片化されるかを示している。しかし、ＭＡＵ ４は、大きくて、追加のＭＡＵを第３のトランスポートパケット内に挿入することができない。この実施例では、ＭＡＵ ４は、図に示されていない、第４のトランスポートパケット内で続けられる。このような状況では、第３トランスポートパケットのペイロードフォーマットヘッダは、「Ｏｆｆｓｅｔ」フィールドを含む必要はなく、「ＭＡＵ Ｐｒｏｐｅｒｔｉｅｓ」セクション全体を省くことが可能な場合がある。次いで、ＭＰＦヘッダの残り部分は、「Ｐａｃｋｅｔ Ｓｐｅｃｉｆｉｃ Ｉｎｆｏ」セクションのみを含み、単一のバイトと同じくらい小さくできる。
【００４８】
ＭＡＵが複数のペイロードに断片化される場合、それらのペイロードは、通常、別々のトランスポートパケットで配送される。しかし、このＭＰＦでは、さらに、同じＭＡＵに対する複数のペイロードを単一のトランスポートパケット内で配送することもできる。
【００４９】
トランスポートパケット内のペイロードがＭＡＵのフラグメントを含む場合、これは、「Ｂｉｔ Ｆｉｅｌｄ ２」内の「Ｆ」フィールドにより示される。
図１０は、一実施形態により、単一のＭＡＵが同じＲＴＰパケット内の３つのフラグメントに分割されている一実施例を示している。この実施例では、第１のＭＰＦヘッダ内の「Ｆ」フィールドは、１に設定され、第１のペイロードがＭＡＵの第１のフラグメントを含むことを示す。「ＭＡＵ Ｔｉｍｉｎｇ」セクションは、この第１のペイロードにしか存在しない。第２のＭＰＦヘッダ内の「Ｆ」フィールドは、０に設定され、そのペイロードが、ＭＡＵの最初のフラグメントでも最後のフラグメントでもないフラグメントを含むことを示す。第３のＭＰＦヘッダ内の「Ｆ」フィールドは、２に設定され、そのペイロードがＭＡＵの最後のフラグメントを含むことを示す。
【００５０】
通常のＲＴＰサンプリングクロックおよびウォールクロックに加えて、ＭＰＦは、これから説明する、いくつかの追加のタイムスタンプおよび時間の概念を示す。ＲＴＰヘッダは、パケット内のデータがサンプリングされた時間を指定する、単一のタイムスタンプを有する。このタイムスタンプは、ときには、サンプリングクロックとも呼ばれる。異なるメディアストリームに属すパケットのＲＴＰタイムスタンプは、比較することができないことに留意されたい。なぜなら、サンプリングクロックは、異なるメディアストリームについては異なる周波数で動作する可能性があるからである。例えば、オーディオストリームのサンプリングクロックは４４１００Ｈｚで動作するが、ビデオストリームのサンプリングクロックは、９００００Ｈｚで動作しうる。さらに、ＲＦＣ−３５５０では、初期ＲＴＰタイムスタンプの値は、ランダムに選択されなければならないと規定している。実際、それぞれのメディアストリームは、それ専用の時系列を有する。本明細書では、それぞれのこのような時系列は、「メディア時系列」と呼ばれる。
【００５１】
ＲＴＰにより、異なるメディアストリームに対する時系列を「ウォールクロック」と呼ばれる基準クロックの時系列と同期させることができる。ＲＴＰ送信機側では、受信機がサンプリングクロックとＲＴＣＰ送信機レポートパケット内のウォールクロックとの間のマッピングを送信することによりこのような同期を取ることを許可する。メディアストリームが異なるサンプリングクロックを使用する場合があるため、メディアストリーム毎に異なるＲＴＣＰ送信機レポートが送信されなければならない。
【００５２】
マッピングは、何らかの間隔で再び更新および送信され、これにより、受信機側は、ウォールクロックとサンプリングクロックとの間で発生しうるドリフトを補正することができる。クロックドリフトは、送信機のウォールクロックが受信機のウォールクロックに関してドリフトする場合には依然として問題となりうる。２つのクロックを同期させるために、例えば、ＮＴＰプロトコルを使用することが可能であろうが、ＲＴＰ規格では、特定の同期方法を規定していない。ウォールクロックは、符号器から供給されることに留意されたい。ＲＴＰ送信機および符号器が、別々の要素である場合、ウォールクロックは、典型的には、送信機側のどの物理的クロックとも無関係である。
【００５３】
このＭＰＦは、通常再生時間（ＮＰＴ）時系列と呼ばれる第３の時系列を使用する。ＮＰＴ時系列は、主にＲＴＰがメディアの「プレゼンテーション」を送信するために使用される場合に有用である。ＮＰＴ時系列から得られるタイムスタンプは、ふつう、プレゼンテーションの先頭の０から始まる。ＮＰＴタイムスタンプは、特に、事前に記録されているプレゼンテーションを送信する場合に有用であるが、それは、タイムスタンプを使用すると受信機側がプレゼンテーション内で探索すべき位置をユーザーが指定するのを補助するからである。この場合、受信機が新しい位置をＲＴＰ送信機に伝達するための何らかの機構の存在を仮定する。
【００５４】
ＲＴＰは、マルチメディア会議アプリケーション向けに設計されていたため、ＲＴＰ規格では、ＮＰＴ時系列を規定しない。しかし、ＲＴＳＰ（ビデオオンデマンドアプリケーション用の制御プロトコル）などのＲＴＰの上に構築された他のプロトコルは、ＮＰＴ時系列の概念を含む。ＲＴＳＰでは、制御プロトコルは、メディアストリーム毎にＮＰＴ時系列とメディア時系列との間のマッピングを行う。
【００５５】
ＭＰＦは、ＭＡＵに関連付けられているＮＰＴ時系列タイムスタンプを指定する機構を定義する。しかし、実用的であれば、ＲＴＳＰによって定義されたものなどのメディア時系列とＮＰＴ時系列との間の帯域外マッピングは、ＭＰＦヘッダのオーバーヘッドを低減するので、好ましい場合がある。
【００５６】
すべてのＲＴＰ準拠システムは、タイムスタンプのラップアラウンドを処理する。典型的なクロック周波数９００００Ｈｚでは、ＲＴＰタイムスタンプは、ほぼ１３時間おきにラップアラウンドする。しかし、ＲＴＰ規格では、ランダムオフセットをサンプリングクロックに加えなければならないと規定しているため、受信機で生じる第１のラップアラウンドは、１３時間よりも著しく短いものとなりうる。ＲＴＰタイムスタンプのラップアラウンドは、通常、合同演算を使用することにより処理される。合同演算が使用される場合、タイムスタンプは、通常、一方のタイムスタンプを他方のタイムスタンプから減算し、その結果が正であるか、または負であるかを観察することにより比較される。
【００５７】
ＭＰＦでは、それぞれのＭＡＵは、「復号化時間」および「プレゼンテーション時間」を有する。復号化時間は、ＭＡＵが受信機の復号器に送られなければならない期限であり、プレゼンテーション時間は、ＭＡＵが受信機により提示（表示または再生）されなければならない時間である。時間は両方とも、メディア時系列に属する。ネットワークおよび復号器内の遅延が典型的にはＲＴＰ送信機側に知られていないため、受信機側では、復号化タイムスタンプまたはプレゼンテーションタイムスタンプの絶対値を使用しない。受信機側では、復号化タイムスタンプの対またはプレゼンテーションタイムスタンプの対の間の相対的差のみを考慮する。
【００５８】
ビデオコーデックが双方向ビデオフレームを生成する場合などいくつかの場合において、ＭＡＵは、提示される異なる順序で復号化することができる。この実装では、ＲＴＰ送信機は、ＭＡＵを、それらが復号化されなければならない順序で送信する。
【００５９】
ＲＴＰヘッダ内の「Ｔｉｍｅｓｔａｍｐ（タイムスタンプ）」フィールドは、トランスポートパケットを第１のＭＡＵのプレゼンテーション時間にマッピングされる。トランスポートパケットは、復号化順序で送信されるため、連続するＭＡＵのプレゼンテーション時間スタンプは、単調非減少とはなりえない。
【００６０】
ＭＰＦヘッダは、オプションの「Ｄｅｃｏｄｅ Ｔｉｍｅ（復号化時間）」フィールドを含み、これは、ペイロード中のＭＡＵの復号化時間を指定するために使用される。ＭＰＦヘッダは、さらに、「Ｐｒｅｓｅｎｔａｔｉｏｎ Ｔｉｍｅ」フィールドを含み、これは、トランスポートパケットが複数のＭＡＵを含む場合に、ＭＡＵのプレゼンテーション時間を指定するために使用される。単一のＭＡＵのみがトランスポートパケットに含まれる場合、「Ｐｒｅｓｅｎｔａｔｉｏｎ Ｔｉｍｅ（プレゼンテーション時間）」フィールドであるが、それは、「Ｔｉｍｅｓｔａｍｐ」フィールドがパケット内の第１のＭＡＵのそのフィールドの代替えとして使用されるからである。この実装では、「Ｄｅｃｏｄｅ Ｔｉｍｅ」および「Ｐｒｅｓｅｎｔａｔｉｏｎ Ｔｉｍｅ」の両方フィールドが、「Ｔｉｍｅｓｔａｍｐ」フィールドと同じクロック分解能を使用して表される。
【００６１】
「トリックプレイ」という用語は、受信機が非リアルタイム速度でメディアンプレゼンテーションをレンダリングすることを意味する。トリックプレイの実施例は、プレゼンテーションの早送りおよび巻き戻しを含む。ＲＴＰ送信機が、トリックプレイモードで送信している場合、それぞれのＭＡＵに対する復号化タイムスタンプおよびプレゼンテーションタイムスタンプは、リアルタイム速度でインクリメントしなければならない。これにより、復号器は、トリックプレイが使用されることを知らずにＭＡＵを復号化することができる。ＭＰＦヘッダ内の「Ｄｅｃｏｄｅ Ｔｉｍｅ」および「Ｐｒｅｓｅｎｔａｔｉｏｎ Ｔｉｍｅ」フィールドは、トリックプレイの影響を受けず、「ＮＰＴ」フィールドは、存在する場合、影響を受けないということはない。例えば、メディアプレゼンテーションが巻き戻しされている場合、ＭＡＵの「Ｐｒｅｓｅｎｔａｔｉｏｎ Ｔｉｍｅ」タイムスタンプフィールドは、増加するが、「ＮＰＴ」フィールドの値は、減少する。
【００６２】
ＭＰＦヘッダ内の「ＮＰＴ」フィールドでは、ＭＡＵが属する通常再生時間時系列内の位置を指定する。「ＮＰＴ」フィールドが存在していない場合、受信機は、２つの時系列の間のマッピングが利用可能とした場合に、プレゼンテーション時間からＭＡＵの通常再生時間を計算することができる。このマッピングを設定するさまざまなアプローチについて、以下で説明する。ＲＴＰ送信機は、メディア時系列内のタイムスタンプにランダムオフセットを加えるので、プレゼンテーション時間タイムスタンプは、ＮＰＴタイムスタンプの直接的代替えとして使用されない。このランダムオフセットが受信機側に知られているとしても、メディア時系列タイムスタンプのラップアラウンドは、問題となる可能性がある。
【００６３】
これらの問題に対し考えられる解決策として、送信機側で帯域側機構を使用して通常再生時間時系列とメディア時系列との間のマッピングを行うという方法がある。このマッピングは、伝送の開始時に１回だけ、または必要に応じて繰り返し行うことも可能である。さらに、トリックプレイが可能であれば、送信機側でトリックプレイ速度を伝達する。例えば、プレゼンテーションが巻き戻しされている場合、トリックプレイ速度は負である。受信機では、トリックプレイ速度を使用して、プレゼンテーション時間が長くなると減少するＮＰＴタイムスタンプを生成する。
【００６４】
マッピングが、伝送の始めに１回だけ行われる場合、受信機側で、通常再生時間時系列とウォールクロック時系列との間のマッピングを確立する。これは、通常、適切なＲＴＣＰ送信機レポートパケットが受信されると直ちに可能になる。メディア時系列からのタイムスタンプは、ウォールクロック時系列に対してドリフトする可能性があるため、ＭＡＵのウォールクロック時間に基づいてそれぞれのＭＡＵについてＮＰＴタイムスタンプを計算することが好ましい。
【００６５】
ＲＴＳＰプロトコルは、通常再生時間時系列と伝送の始めのメディア時系列との間のマッピングを行う制御プロトコルの一実施例である。複雑度とオーバーヘッドとの間の適当なトレードオフの関係をもたらす他の解決策では、同期点ＭＡＵでのみ「ＮＰＴ」フィールドを含む。「ＮＰＴ」フィールドは、通常再生時間時系列とプレゼンテーションまたはウォールクロック時系列との間のマッピングを確立するために使用される。非同期点ＭＡＵについては、受信機は、すでに確立されているマッピングを使用してＮＰＴタイムスタンプを計算する。トリックプレイが使用される場合、送信機は、すべてのＭＡＵについて「ＮＰＴ」フィールドを含む。
【００６６】
ＭＰＦヘッダ内の「Ｓｅｎｄ Ｔｉｍｅ（伝送時間）」フィールドでは、トランスポートパケットの伝送時間を指定する。これは、トランスポートパケットのシーケンスが、一方のサーバーから第２のサーバーに転送される場合に有用と考えられる。第１のサーバーのみが、パケットに対する伝送スケジュールを計算する必要がある。第２のサーバーは、「Ｓｅｎｄ Ｔｉｍｅ」フィールドの値に基づいてトランスポートパケットを他のクライアントに転送する。トランスポートパケットをクライアントに転送するときに、「Ｓｅｎｄ Ｔｉｍｅ」フィールドを含んでいる必要はない。しかし、クライアントは、一連のパケット内の「Ｓｅｎｄ Ｔｉｍｅ」フィールドの値の差をパケット到着時間の差と突き合わせて比較することにより「Ｓｅｎｄ Ｔｉｍｅ」フィールドを使用して、ネットワークの混雑を検出することができる。「Ｓｅｎｄ Ｔｉｍｅ」フィールドでは、メディア時系列と同じユニットを使用する。
【００６７】
「Ｃｏｒｒｅｓｐｏｎｄｅｎｃｅ（対応）」フィールドは、ウォールクロック時系列と現在のメディア時系列との間のマッピングを規定する。ＲＴＰが転送プロトコルの場合、これは、ＲＴＣＰ送信機レポート内にもたらされるのと同じマッピングである。トランスポートパケット内にマッピングを含めることは、別のＲＴＣＰパケットを伝送するのよりも効率的である。これにより、送信機は、ＲＴＣＰ送信機レポートの頻度を下げ、そのまま、必要な頻度でマッピングを送信することができる。
【００６８】
図１１は、参照を目的として標準的な１２バイトＲＴＰヘッダを例示している。図１１を参照すると、
● 「Ｖｅｒｓｉｏｎ」（Ｖ）フィールド：２ビット。このフィールドは、２に設定される。
● 「Ｐａｄｄｉｎｇ」（Ｐ）ビット：このビットは、ＲＴＰパケットの末尾にパディングを加えるために使用される。
● 「Ｅｘｔｅｎｓｉｏｎ」（Ｘ）ビット：このビットは、ＲＴＰヘッダ拡張が存在している場合に１に設定される。ＲＴＰプロファイルで、ヘッダ拡張がどのように使用されるかが定義される。受信機は、ＲＴＰヘッダが非ゼロの「Ｅｘｔｅｎｓｉｏｎ」ビットを有している場合にヘッダ拡張を解析するか、またはスキップすることができる。
● 「Ｃｏｎｔｒｉｂｕｔｉｎｇ Ｓｏｕｒｃｅ」（ＣＣ）フィールド：４ビット。受信機は、ＲＴＰヘッダが非ゼロの「ｃｏｎｔｒｉｂｕｔｉｎｇ ｓｏｕｒｃｅ」フィールドを有している場合に寄与するソースのリストを正しく解析するか、またはスキップすることができる。
● 「Ｍａｒｋｅｒ」（Ｍ）ビット：このビットは、トランスポートパケット内のペイロードが完全なＭＡＵまたはＭＡＵの最後のフラグメントを含む場合に１に設定される。
● 「Ｐａｙｌｏａｄ Ｔｙｐｅ」（ＰＴ）フィールド：７ビット。ＲＴＰペイロードタイプの割り当ては、本明細書の範囲を外れている。これは、このペイロードフォーマットが使用されるか、または動的に帯域外に信号伝送される際に基づくＲＴＰプロファイルにより指定される（例えば、ＳＤＰを使用して）。
● 「Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒ」フィールド：１６ビット。このフィールドは、同じＳＳＲＣ値とともにトランスポートパケットが送信される毎に１だけインクリメントされる数を含む。ＲＴＰシーケンス番号の初期値は、非ＲＴＰ手段を通じてクライアントに伝達することができる。
● 「Ｔｉｍｅｓｔａｍｐ」フィールド：３２ビット。このフィールドでは、トランスポートパケットに含まれる第１のペイロードに適用されるタイムスタンプを指定する。デフォルトでは、このフィールドは、プレゼンテーション時間として解釈される。「Ｔｉｍｅｓｔａｍｐ」フィールドのクロック周波数は、９０ｋＨｚとすることが推奨される、つまり、分解能は、１／９００００秒である。送信機および受信機は、非ＲＴＰ手段を通じて異なるクロック周波数をネゴシエートすることができる。
● 「Ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ Ｓｏｕｒｃｅ」（ＳＳＲＣ）フィールド：３２ビット。ＳＳＲＣフィールドに対し同じ値を持つトランスポートパケットは、「Ｔｉｍｅｓｔａｍｐ」フィールドに対する同じ時系列および「Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒ」フィールドに対する同じ数空間を共有する。
【００６９】
ＲＴＰヘッダの後に、ＭＰＦヘッダが続く。唯一の例外は、パディングしか含まないトランスポートパケットである。その場合、ＭＰＦヘッダは、存在しない。トランスポートパケットが、複数のＭＡＵからのデータを含む場合、ＭＰＦヘッダは、それぞれのＭＡＵの前、およびそれぞれの断片化された（部分的）ＭＡＵの前に現れる。したがって、このペイロードフォーマットを使用するトランスポートパケットは、１つまたは複数のＭＰＦヘッダを含むことができる。ＭＰＦヘッダのレイアウトは、図７に示されている。ＭＰＦヘッダが標準１２バイトＲＴＰヘッダの直後に来る場合、これは、「Ｂｉｔ Ｆｉｅｌｄ １」という１バイトフィールドから始まり、その後に一連のオプションフィールドが続く。このヘッダの後に、ペイロードが続く。ペイロードは、完全なＭＡＵ、またはフラグメント（部分的）ＭＡＵのいずれかを含む。
【００７０】
第１のデータペイロードの後に、他のＭＰＦヘッダが現れ、他のデータペイロードが続く。データペイロードの後に他のＭＰＦヘッダを加えるプロセスは、複数回繰り返すことができる。「Ｂｉｔ Ｆｉｅｌｄ ２」フィールドを持つ第１のデータペイロードに続くそれぞれのＭＰＦヘッダ。
【００７１】
以下に、「Ｂｉｔ Ｆｉｅｌｄ １」フィールドのレイアウトを示す。
● 「Ｓｅｎｄ Ｔｉｍｅ Ｐｒｅｓｅｎｔ」（ＳＴ）ビット：このビットが１の場合、３２ビットの「Ｓｅｎｄ Ｔｉｍｅ」フィールドが、「Ｂｉｔ Ｆｉｅｌｄ １」フィールドの末尾の直後に挿入される。
● 「Ｃｏｒｒｅｓｐｏｎｄｅｎｃｅ Ｐｒｅｓｅｎｔ」（ＣＰ）ビット：このビットが１の場合、９６ビットの「Ｃｏｒｒｅｓｐｏｎｄｅｎｃｅ」フィールドが、「Ｓｅｎｄ Ｔｉｍｅ」フィールドの後に挿入される。
● Ｒ１、Ｒ２、Ｒ３（それぞれ１ビット）：１に設定されているこれらのビットのそれぞれについて、受信機側では、３２ビットフィールドが「Ｃｏｒｒｅｓｐｏｎｄｅｎｃｅ」フィールドと「Ｂｉｔ Ｆｉｅｌｄ ２」との間に追加されていると想定する。これらの３２ビットフィールドの意味は、本明細書では定義されていない。３２ビットフィールドの意味を認識しない受信機は、それらを無視する。
● Ｒ４、Ｒ５（それぞれ１ビット）：将来使用するために予約されており、現在は、０に設定されている。
● 「Ｂｉｔ Ｆｉｅｌｄ ２ Ｐｒｅｓｅｎｔ」（Ｂ２Ｐ）ビット：このビットが１の場合、１バイトの「Ｂｉｔ Ｆｉｅｌｄ ２」フィールドが、「Ｃｏｒｒｅｓｐｏｎｄｅｎｃｅ」フィールドの後に挿入される。
● 「Ｓｅｎｄ Ｔｉｍｅ」フィールド：３２ビット。このフィールドは、ＲＴＰヘッダ内の「Ｔｉｍｅｓｔａｍｐ」フィールドに使用されるのと同じ時間単位を使用して、トランスポートパケットの伝送時間を指定する。
● 「Ｃｏｒｒｅｓｐｏｎｄｅｎｃｅ」フィールド：９６ビット。フィールドは、２つのタイムスタンプを含む。ＮＴＰフォーマットの６４ビットウォールクロックタイムスタンプ、および３２ビット復号化時間タイムスタンプ。２つのフィールドは、ＲＦＣ−３５５０の６．４．１で定義されている、ＲＴＣＰ送信機レポートの「ＮＴＰ ｔｉｍｅｓｔａｍｐ」および「ＲＴＰ ｔｉｍｅｓｔａｍｐ」フィールドと同じようにして使用される。
【００７２】
「Ｂｉｔ Ｆｉｅｌｄ １」が存在する場合、「Ｂｉｔ Ｆｉｅｌｄ ２」はオプションである。「Ｂｉｔ Ｆｉｅｌｄ １」の「Ｂ２Ｐ」ビットは、「Ｂｉｔ Ｆｉｅｌｄ ２」が存在するかどうかを判定する。「Ｂｉｔ Ｆｉｅｌｄ ２」のすべてのビットに対するデフォルト値は、０である。「Ｆｒａｇｍｅｎｔａｔｉｏｎ」フィールド（Ｆ）は、データペイロードが部分的ＭＡＵを含むかどうかを示す。１つまたは複数のそのようなペイロードが組み合わされ、完全なＭＡＵを再構成する。「Ｆ」フィールドは、さらに、ペイロードが、ＭＡＵの最初または最後のフラグメントを含むかどうかも示す。「Ｓ」、「Ｄ １」、および「Ｄ２」ビット（以下）は、「Ｆ」フィールドの値が０または３の場合にのみ有効である。表２は、Ｆフィールド値の例示的な意味を示す。
【００７３】
【表２】
【００７４】
「Ｏｆｆｓｅｔ Ｐｒｅｓｅｎｔ」ビット（ＯＰ）：このビットが１の場合、１６ビットの「Ｏｆｆｓｅｔ」フィールドが、「Ｂｉｔ Ｆｉｅｌｄ ２」の直後に挿入される。「Ｏｆｆｓｅｔ」フィールドは、現在のペイロードの末尾を見つけるために使用される。「Ｂｉｔ Ｆｉｅｌｄ ２」から始まる他のＭＰＦヘッダは、現在のペイロードの末尾の後に続きうる。「Ｏｆｆｓｅｔ Ｐｒｅｓｅｎｔ」ビットが０の場合、「Ｏｆｆｓｅｔ」フィールドは存在せず、ＭＰＦがＲＴＰとともに使用される場合、現在のペイロードはトランスポートパケットの末尾まで、またはＲＴＰヘッダ内の「Ｐａｄｄｉｎｇ」ビットが１の場合にＲＴＰパディング領域の始めまで伸びる。
【００７５】
「Ｓｙｎｃ Ｐｏｉｎｔ」ビット（Ｓ）：このビットは、ＭＡＵが同期点ＭＡＵの場合に１に設定される。「Ｄｉｓｃｏｎｔｉｎｕｉｔｙ」ビット（Ｄ１）：このビットは１に設定され、トランスポートパケットのシーケンス番号（例えば、ＲＴＰが使用されている場合に、ＲＴＰシーケンス番号）が「ギャップ」を示していないとしても、１つまたは複数のＭＡＵが欠落していることを示す。「Ｄｒｏｐｐａｂｌｅ」ビット（Ｄ２）：このビットが１であり、いくつかのＭＡＵを落とす必要がある場合、このＭＡＵは、Ｄ２ビットが０に設定されているＭＡＵほどマイナスの影響を及ぼすことなく落とすことができる。「Ｅｎｃｒｙｐｔｉｏｎ」ビット（Ｅ）：このビットは１に設定され、ペイロードが暗号化されたデータを含むことを示す。このビットは、ペイロードが暗号化されたデータを含まない場合に０に設定されなければならない。「Ｂｉｔ Ｆｉｅｌｄ ３ Ｐｒｅｓｅｎｔ」（Ｂ３Ｐ）ビット：このビットが１の場合、１バイトの「Ｂｉｔ Ｆｉｅｌｄ ３」フィールドが、「Ｌｅｎｇｔｈ」フィールドの後に挿入される。「Ｏｆｆｓｅｔ」：「Ｏｆｆｓｅｔ」フィールドの後に続く最初のバイトから数えた、現在のペイロードの終わりまで、バイト数でオフセットを指定する１６ビットフィールド。言い換えると、「Ｏｆｆｓｅｔ」フィールドの値は、もしあれば「ＭＡＵ Ｔｉｍｉｎｇ」セクションのサイズに、現在のペイロードのサイズを加えた値である。
【００７６】
「Ｂｉｔ Ｆｉｅｌｄ ２」の「Ｂ３Ｐ」ビットの値は、「Ｂｉｔ Ｆｉｅｌｄ ３」が存在するかどうかを判定する。「Ｂｉｔ Ｆｉｅｌｄ ３」のすべてのビットに対するデフォルト値は、０である。図１２は、ＭＰＦのビットフィールド３の例示的なレイアウトを示す。「Ｄｅｃｏｄｅ Ｔｉｍｅ Ｐｒｅｓｅｎｔ」ビット（Ｄ３）：このビットが１の場合、３２ビット「Ｄｅｃｏｄｅ Ｔｉｍｅ」フィールドが、「Ｂｉｔ Ｆｉｅｌｄ ３」の後から、「Ｐｒｅｓｅｎｔａｔｉｏｎ Ｔｉｍｅ」フィールドの前までの間に挿入される。「Ｐｒｅｓｅｎｔａｔｉｏｎ Ｔｉｍｅ Ｐｒｅｓｅｎｔ」ビット（Ｐ）：このビットが１の場合、３２ビット「Ｐｒｅｓｅｎｔａｔｉｏｎ Ｔｉｍｅ」フィールドが、「Ｄｅｃｏｄｅ Ｔｉｍｅ」の後から、「ＮＰＴ」フィールドの前までの間に挿入される。「ＮＰＴ Ｐｒｅｓｅｎｔ」ビット（Ｎ）：このビットが１の場合、６４ビットの「ＮＰＴ」フィールドが、「Ｐｒｅｓｅｎｔａｔｉｏｎ Ｔｉｍｅ」フィールドの直後に挿入される。Ｒ６、Ｒ７、Ｒ８、Ｒ９：１に設定されているこれらのビットのそれぞれについて、受信機側では、３２ビットフィールドが「ＮＰＴ」フィールドと「Ｅｘｔｅｎｓｉｏｎ」との間に追加されていると想定する。これらの３２ビットフィールドの意味は、本明細書では定義されていない。３２ビットフィールドの意味を認識しない受信機は、それらを無視する。
【００７７】
「Ｅｘｔｅｎｓｉｏｎ Ｐｒｅｓｅｎｔ」ビット（Ｘ）：このビットが１の場合、可変サイズ「Ｅｘｔｅｎｓｉｏｎ」フィールドが、「ＮＰＴ」フィールドの後に挿入される。「Ｄｅｃｏｄｅ Ｔｉｍｅ」：３２ビットフィールド。このフィールドで、ＭＡＵの復号化時間を指定する。ＲＴＰが使用される場合、このフィールドで、ＲＴＰヘッダ内の「Ｔｉｍｅｓｔａｍｐ」フィールドに使用されるのと同じ時間単位を使用して、ＭＡＵの復号化時間を指定する。「Ｐｒｅｓｅｎｔａｔｉｏｎ Ｔｉｍｅ」：３２ビットフィールド。このフィールドで、ＭＡＵのプレゼンテーション時間を指定する。「ＮＰＴ」フィールド：６４ビットタイムスタンプ。「ＮＰＴ」フィールドでは、ＭＡＵが属する通常再生時間時系列内の位置を指定する。
【００７８】
図１３は、一実施形態による、ＭＰＦヘッダの拡張フィールドの例示的レイアウトを示している。「Ｅｘｔｅｎｓｉｏｎ」フィールドは、フィールドの１つまたは複数の集まりを含む。図１３は、そのような１つの集まりに含まれるフィールドのレイアウトを例示している。「Ｌ」ビット：このビットが１の場合、これは、「Ｅｘｔｅｎｓｉｏｎ」ビットの最後の集まりである。このビットが０の場合、「Ｅｘｔｅｎｓｉｏｎ Ｄａｔａ」フィールドの末尾の後に、「Ｅｘｔｅｎｓｉｏｎ」フィールドの少なくとももう１つの集まりが続く。
【００７９】
「Ｅｘｔｅｎｓｉｏｎ Ｔｙｐｅ」：「Ｅｘｔｅｎｓｉｏｎ Ｄａｔａ」フィールドの内容を識別するために使用される７ビットフィールド。それに加えて、値０と１２７は、将来使用するために予約されている。「Ｅｘｔｅｎｓｉｏｎ Ｌｅｎｇｔｈ」：このフィールドの直後に出現する「Ｅｘｔｅｎｓｉｏｎ Ｄａｔａ」フィールドのバイト数によるサイズを示す８ビットの数値。「Ｅｘｔｅｎｓｉｏｎ Ｄａｔａ」：可変長フィールド。このフィールドのサイズは、「Ｅｘｔｅｎｓｉｏｎ Ｌｅｎｇｔｈ」フィールドにより与えられる。
【００８０】
「Ｅｘｔｅｎｓｉｏｎ」フィールド内のフィールドは、初期化ベクトル拡張が使用される場合に以下の値を有する。
● 「Ｅｘｔｅｎｓｉｏｎ Ｔｙｐｅ」：２である。
● 「Ｅｘｔｅｎｓｉｏｎ Ｌｅｎｇｔｈ」：バイト数による「Ｅｘｔｅｎｓｉｏｎ Ｄａｔａ」フィールドのサイズ。
● 「Ｅｘｔｅｎｓｉｏｎ Ｄａｔａ」：現在のＭＡＵに対する初期化ベクトルの一部として使用される、１つまたは複数のバイトのシーケンス。この拡張が存在する場合、暗号化ユニットは、完全なＭＡＵである。ＭＡＵが複数のペイロードに断片化される場合、初期化ベクトル拡張は、第１のペイロード内にのみ存在する。
【００８１】
「Ｅｘｔｅｎｓｉｏｎ」フィールド内のフィールドは、キーＩＤ拡張が使用される場合に以下の値を有する。
● 「Ｅｘｔｅｎｓｉｏｎ Ｔｙｐｅ」：３である。
● 「Ｅｘｔｅｎｓｉｏｎ Ｌｅｎｇｔｈ」：バイト数による「Ｅｘｔｅｎｓｉｏｎ Ｄａｔａ」フィールドのサイズ。
● 「Ｅｘｔｅｎｓｉｏｎ Ｄａｔａ」：現在のペイロードを復号化するために使用する復号化キーを識別する、１つまたは複数のバイトのシーケンス。
【００８２】
キーＩＤ拡張は、異なるキーＩＤ拡張により置き換えられるまで有効である。したがって、この拡張は、前のペイロードの復号化キーと異なる復号化キーの使用をペイロードが必要とする場合にのみ使用される。しかし、前のペイロードが失われたトランスポートパケット内に含まれていた場合、受信機は、復号化キーの変更が必要であることを認識しない場合がある。ペイロードが誤ったキーで復号化され、この状況が検出されない場合、望ましくないレンダリングアーチファクトが生じる可能性がある。
【００８３】
このような問題の重大さを軽減するアプローチの１つは、同期点であるすべてのＭＡＵの第１のペイロードに対しキーＩＤ拡張を指定することである。これは、ＭＡＵが失われることで、受信機が次の同期点ＭＡＵを受け取るまですべてのＭＡＵを強制的に破棄することが知られている場合にはよい解決策である。より控え目な解決策は、それぞれの複数ペイロードトランスポートにおける第１のペイロードに対しキーＩＤ拡張を指定することである。この解決策は、パケット喪失に対しロバストであるが、それは、相互依存ペイロードが、すべて、単一のトランスポートパケット内に含まれるからである。
【００８４】
ＭＰＥＧビデオヘッダが存在する場合、それらは、後続フレームの前に来る。特に、
● ＭＰＥＧ Ｖｉｄｅｏ＿Ｓｅｑｕｅｎｃｅ＿Ｈｅａｄｅｒは、存在する場合、ＭＡＵの先頭にある。
● ＭＰＥＧ ＧＯＰ＿ｈｅａｄｅｒは、存在する場合、ＭＡＵの先頭にあるか、またはＶｉｄｅｏ＿Ｓｅｑｕｅｎｃｅ＿Ｈｅａｄｅｒの後に続く。
● ＭＰＥＧ Ｐｉｃｔｕｒｅ＿Ｈｅａｄｅｒは、存在する場合、ＭＡＵの先頭にあるか、またはＧＯＰ＿ｈｅａｄｅｒの後に続く。
ＲＦＣ ２２５０とは異なり、ビデオを含むＭＡＵが断片化された場合、スライス境界で断片化を実行する必要はない。
【００８５】
ＭＡＵは、さまざまな理由から複数のトランスポートパケットにまたがって断片化される可能性がある。例えば、ＭＡＵは、トランスポートパケットサイズの制限が存在し、ＭＡＵの特定の部分に対する暗号化パラメータに違いがある場合に断片化される可能性がある。ＲＴＰヘッダフィールドが解釈される場合、ＲＴＰヘッダ内の「Ｔｉｍｅｓｔａｍｐ」フィールドは、９０ｋＨｚの精度でサンプルのＰＴＳに設定され、「Ｐａｙｌｏａｄ Ｔｙｐｅ（ＰＴ）」フィールドは、帯域外ネゴシエーション機構に従って（例えば、ＳＤＰを使用して）設定される。ＭＰＦ、パケット指定情報セクションに関して、「Ｓｅｎｄ Ｔｉｍｅ」フィールドの存在はオプションであり、「Ｃｏｒｒｅｓｐｏｎｄｅｎｃｅ」フィールドの存在はオプションであり、「Ｂｉｔ Ｆｉｅｌｄ ２ Ｐｒｅｓｅｎｔ」ビット（Ｂ２Ｐ）は、ペイロードが、暗号化されたＭＡＵの一部、または暗号化されたＭＡＵのフラグメントを含む場合に設定される。
【００８６】
上記に照らして、ＭＰＦにより、異なる暗号化パラメータに従って単一のＭＡＵを暗号化することができる。これは、暗号化された単一のＭＡＵのフラグメントを備え、他を平文中に残す機能を備える。このような場合、ＭＡＵは、複数のペイロードに断片化することができ、それぞれ異なる暗号化パラメータを有する。例えば、暗号化されたＭＡＵまたはＭＡＵのフラグメントは、以下の基準に従って値およびフィールドを設定される。
● Ｐａｃｋｅｔ Ｉｎｆｏセクション内の「Ｂｉｔ Ｆｉｅｌｄ ２ Ｐｒｅｓｅｎｔ」ビット（Ｂ２Ｐ）は、１に設定され、「Ｂｉｔ Ｆｉｅｌｄ ２」が存在することを示す。
● ＭＡＵ Ｐｒｏｐｅｒｔｉｅｓセクション内の「Ｅｎｃｒｙｐｔｉｏｎ」ビット（Ｅ）は、１に設定され、ペイロードが暗号化されることを示す。
● 「ＭＡＵ Ｔｉｍｉｎｇ」セクション内の「Ｅｘｔｅｎｓｉｏｎ Ｐｒｅｓｅｎｔ」ビット（Ｘ）は、１に設定され、拡張フィールドが存在することを示す。
● 「Ｉｎｉｔｉａｌｉｚａｔｉｏｎ Ｖｅｃｔｏｒ」拡張が含まれる。以下の値が設定される。
【００８７】
○ 「Ｅｘｔｅｎｓｉｏｎ Ｔｙｐｅ」は２に設定される。
○ 「Ｅｘｔｅｎｓｉｏｎ Ｌｅｎｇｔｈ」は、「Ｅｘｔｅｎｓｉｏｎ Ｄａｔａ」フィールドがデータセグメントＩＤのみを含む場合に８（６４ビットを意味する）に、「Ｅｘｔｅｎｓｉｏｎ Ｄａｔａ」フィールドがデータセグメントＩＤとブロックＩＤの両方を含む場合に１６ （１２８ビットを意味する）に設定される。
【００８８】
○ 「Ｅｘｔｅｎｓｉｏｎ Ｄａｔａ」は、初期ブロックＩＤが０の場合に上述のようなデータセグメントＩＤ値で設定される。初期ブロックＩＤが０と異なる場合に、「Ｅｘｔｅｎｓｉｏｎ Ｄａｔａ」は、初期ブロックＩＤが後に続くデータセグメントＩＤに設定される。
【００８９】
○ この拡張は、ＭＡＵのそれぞれの暗号化されたペイロードに関して含まれる。
● 「Ｋｅｙ ＩＤ」拡張が含まれる。以下の値が設定される。
○ 「Ｅｘｔｅｎｓｉｏｎ Ｔｙｐｅ」は３に設定される。
【００９０】
○ 「Ｅｘｔｅｎｓｉｏｎ Ｌｅｎｇｔｈ」は１６（１２８ビットを意味する）に設定される。
○ 「Ｅｘｔｅｎｓｉｏｎ Ｄａｔａ」は、このＭＡＵに対応するライセンスから得たキーＩＤ値で設定される。
● 「Ｉｎｉｔｉａｌｉｚａｔｉｏｎ Ｖｅｃｔｏｒ」および「Ｋｅｙ ＩＤ」拡張は、複数のＭＡＵを含むそれぞれの複数ペイロードトランスポートパケット内の新しいＭＡＵの第１のペイロードについて含まれる。これにより、受信機は、いくつかのトランスポートパケットが失われた場合でも、現在のキーＩＤについて認識することが保証される。
【００９１】
ＭＡＵ Ｐｒｏｐｅｒｔｉｅｓセクションは、以下のように解釈される。
● 「Ｓｙｎｃ Ｐｏｉｎｔ」ビット（Ｓ）は、ＭＡＵがビデオＩ−フレームまたはオーディオフレームを含む場合にセットされる。
● 「Ｄｉｓｃｏｎｔｉｎｕｉｔｙ」ビット（Ｄｌ）は、１つまたは複数のＭＡＵが欠損している場合にセットされる。例えば、ビデオフレームが、フレームドロップトランスレータにより落とされた場合。
● 「Ｄｒｏｐｐａｂｌｅ」ビット（Ｄ２）の利用はオプションである。それが使用されるべき場合の定義は、本明細書の範囲を外れている。
● 「Ｅｎｃｒｙｐｔｉｏｎ」ビット（Ｅ）は、ペイロードが、暗号化されたＭＡＵの一部、または暗号されたＭＡＵのフラグメントを含む場合にセットされる。
【００９２】
ＭＡＵ Ｔｉｍｉｎｇセクションは、以下のように解釈される。
● 「Ｄｅｃｏｄｅ Ｔｉｍｅ」フィールドは、オプションである。使用される場合、ＭＡＵのＤＴＳを含む。
● 「Ｐｒｅｓｅｎｔａｔｉｏｎ Ｔｉｍｅ」フィールドは、オプションである。
● 「ＮＰＴ」フィールドは、オプションである。
【００９３】
○ 「Ｅｘｔｅｎｓｉｏｎ Ｐｒｅｓｅｎｔ」ビット（Ｘ）は、１つまたは複数の拡張ヘッダが存在する場合にセットされる。
例示的な手順
図１４は、一実施形態により、ＥＳコンテンツを保護する例示的な手順１４００を示している。例示することを目的として、図１のＥＳ保護モジュール１１２、マッピングモジュール１１４、図２のトランスポートストリームスクランブルモジュール２１０、および／または逆多重化およびパッケージ化モジュール２１２のうちの１つまたは複数により手順１４００のオペレーションが実行される。アクションの順序の変更および修正を含む、さまざまな変更および修正は、当業者にとっては、本明細書の説明から明らかであろう。
【００９４】
図１４を参照すると、ブロック１４０５において、エレメンタリストリーム（ＥＳ）は、コンピューティングデバイス１０２またはコンテンツソース２０２により受信されるか、または他の何らかの方法でアクセスされる。アクセスされたＥＳは、トランスポートストリームと無関係であるか、またはトランスポートストリームにより配送することができる。ブロック１４１０における手順１４００で、ＥＳのＭＡＵ部分を保護する。一実装では、これらの保護オペレーションは、共通スクランブルとは無関係に実行される。他の実装では、これらの保護オペレーションは、例えば、トランスポートストリームを共通スクランブルした場合に、共通スクランブルを使用して実行される。ブロック１４１５において、トランスポートストリームがブロック１４０５でアクセスされた場合、元の暗号化が保持されるようにトランスポートストリームがＥＳに逆多重化される。モジュール２１２の逆多重化オペレーションは、トランスポートストリーム逆多重化オペレーションを実行する例示的なコンポーネントを示している。
【００９５】
ブロック１４２０における手順１４００で、保護されているＥＳがＭＡＵペイロードフォーマット（ＭＰＦ）にマッピングされる。それぞれのＭＡＵをＭＰＦにマッピングすることで、メディアコンシューマが他のＥＳと無関係にそれぞれのＥＳを処理し、他のＭＡＵとは無関係にそれぞれのＭＡＵを処理するのに十分な情報が、マッピングされたＥＳをカプセル化するトランスポートパケットを受け取るメディアコンシューマに与えられる。ブロック１４３０における手順１４００で、ＭＰＦにマッピングされたＥＳがトランスポートプロトコルにカプセル化される。一実装では、トランスポートプロトコルは、リアルタイム転送プロトコル（ＲＴＰ）である。ブロック１４４０における手順１４００で、トランスポートプロトコルに基づくトランスポートパケットをメディアコンシューマに伝達し、処理する。復号化を含む、このような処理により、メディアコンシューマは、トランスポートパケットに含まれるペイロードデータを受け取ることができる。
結論
ＥＳコンテンツを保護することは構造的特徴および／または方法論的なオペレーションまたはアクションに固有の言語で説明されているが、付属の請求項で定められている実装は、説明された特定の特徴またはアクションに必ずしも限られないことは理解されるであろう。むしろ、特定の特徴およびオペレーションは請求されている主題を実施するための複数の実施形態の例として開示されている。
【図面の簡単な説明】
【００９６】
【図１】一実施形態による、ＥＳコンテンツを保護する例示的なコンピューティングシステムを示す図である。
【図２】一実施形態による、トランスポートストリームにより配送されるＥＳコンテンツを保護する例示的な実施形態を実装することができる例示的なネットワーク接続環境を示す図である。
【図３】カウンタモードで高度暗号化標準を使用してＥＳメディアコンテンツを暗号化するオペレーションの例示的な態様を示す図である。
【図４】一実施形態による、保護されたＥＳコンテンツとともにトランスポートストリーム内に挿入する例示的な暗号方式（ＴＡＧ）パケットを示す図である。
【図５】一実施形態による、送信機側でトランスポートストリーム内のＥＳを保護する例示的な手順を示す図である。
【図６】一実施形態による、例示的な共通スクランブルされたトランスポートストリームを示す図である。
【図７】一実施形態による、メディアアクセスユニット（ＭＡＵ）ペイロードフォーマット（ＭＰＦ）ヘッダの例示的な高水準構造を例示する図である。
【図８】一実施形態による、図７のＭＰＦヘッダの例示的な詳細を示す図である。
【図９】一実施形態による、ＭＰＦを使用する３つのリアルタイムトランスポートパケット（ＲＴＰ）パケットの例示的なシーケンスを示す図である。
【図１０】一実施形態による、単一のメディアアクセスユニット（ＭＡＵ）が同じＲＴＰパケット内の３つのフラグメントに分割されている一実施例を示す図である。
【図１１】標準的な１２バイトＲＴＰヘッダを例示する図である。
【図１２】ＭＰＦのビットフィールド３の例示的なレイアウトを示す図である。
【図１３】一実施形態による、ＭＰＦヘッダの拡張フィールドの例示的なレイアウトを示す図である。
【図１４】一実施形態による、ＥＳコンテンツを保護する例示的な手順を示す図である。
【技術分野】
【０００１】
メディアセンターは、典型的には、メディアコンテンツを配送する保護されたトランスポートストリームから暗号化を除去し、トランスポートストリーム（ＴＳ）を逆多重化（demultiplex）してエレメンタリストリーム（ＥＳ）にし、その後、再暗号化し、ネットワーク接続を介してメディアサブスクライバ（コンシューマ、クライアントなど）に配信する。復号化されたコンテンツは、著作権侵害およびその他の機密保護違反に対し脆弱であるため、メディアセンターによるそのような復号化および再暗号化オペレーションは機密保護を危険に晒す可能性がある。「メディアコンテンツ」は、ビデオ、オーディオコンテンツ、画像、アニメーション、テキストなどの１つまたは複数を含みうる「コンテンツ」、および「メディア信号」と同義である。
【背景技術】
【０００２】
セットトップボックス（ＳＴＢ）、デジタルメディア受信機（ＤＭＲ）、およびパーソナルコンピュータ（ＰＣ）などのメディアサブスクライバは、典型的には、メディアセンター、またはコンテンツソースから保護されたメディアコンテンツを受信する。保護されたメディアコンテンツは、ネットワーク接続を介して伝送される、または記憶媒体からダウンロードされる、暗号化されたオーディオ／ビデオデータを含む。
【発明の開示】
【発明が解決しようとする課題】
【０００３】
暗号化されたメディアコンテンツを（例えば、インデックス作成のため）処理する場合、メディアサブスクライバは、典型的には、メディアコンテンツ保護を除去する（つまり、メディアンコンテンツを復号化する）必要がある。このような復号化オペレーションは、典型的には、かなりのデバイスリソースを消費し、デバイスの性能を低下させ、その結果、デバイスの応答性および機能性を損なう可能性がある。
【０００４】
この「発明の開示」では、以下の「発明を実施するための最良の形態」でさらに説明される簡素化された形式の概念の選択を導入する。この「発明の開示」は、請求されている主題の鍵となる特徴または本質的特徴を明示することを意図しておらず、また請求されている主題の範囲を確定する補助として使用されることも意図していない。
【課題を解決するための手段】
【０００５】
上記に照らして、エレメンタリストリームメディアコンテンツを保護することについて説明される。一態様では、ＥＳコンテンツのメディアアクセスユニット（ＭＡＵ）が識別される。それぞれのＭＡＵは、単一のビデオまたはオーディオフレームを表す１つまたは複数のデータセグメントを含む。暗号境界は、ＭＡＵ毎に選択される。暗号境界は、それぞれのＭＡＵに関連付けられている１つまたは複数のデータセグメントに基づく。それぞれのＭＡＵの一部が、対応する暗号境界に基づいて暗号化される。それぞれのＭＡＵは、ＭＡＵペイロードフォーマットにマッピングされる。ＭＡＵペイロードフォーマットにより、メディアコンシューマは、どの異なるＥＳとも無関係にＥＳコンテンツに関連付けられているそれぞれのＥＳを処理することができる。ＭＡＵペイロードフォーマットでも、メディアコンシューマは、他のどのＭＡＵとも無関係にＥＳ内のそれぞれのＭＡＵを処理することができる。
【０００６】
詳細な説明は、付属の図面を参照しつつ説明される。
【発明を実施するための最良の形態】
【０００７】
概要
メディアコンテンツ固有の特性に基づいて暗号境界を選択することによりＥＳコンテンツを保護するシステムおよび方法が説明される。より具体的には、これらのシステムおよび方法では、ＥＳのメディアアクセスユニット（ＭＡＵ）の一部を（例えば、ＭＰＥＧ−２などを使用して）暗号化する。それぞれのＭＡＵは、単一のビデオまたはオーディオフレーム（エレメンタリストリームフレーム）および関連するヘッダである。ＭＡＵは、１つまたは複数のデータセグメントを含む。それぞれのデータセグメントは、コンテンツ暗号化パラメータの同じ集合が適用されるＭＡＵの連続するセクションである。データセグメントは、完全に暗号化されているか、または完全に平文である（つまり、暗号化されていない）。ＥＳは、ＴＳに由来していない場合がある。しかし、これらのＥＳ保護オペレーションは、ＴＳストリームに適用される共通スクランブルオペレーションと互換性を持つ。
【０００８】
ＴＳが保護されたＥＳコンテンツを含む場合、ＴＳは、既存の暗号化を維持しながらＥＳに逆多重化される（つまり、ＴＳは、復号化されない）。ＥＳは、ＭＡＵペイロードフォーマット（ＭＰＦ）にマッピングされ、これにより、ＥＳのＭＡＵがトランスポートプロトコル（例えば、リアルタイムトランスポートプロトコル（ＲＴＰ））の中にカプセル化され、その後ＰＣおよびセットトップボックスなどのメディアコンシューマに伝達される。それぞれのＭＡＵをＭＰＦにマッピングすることで、他のＥＳと無関係にそれぞれのＥＳを処理（例えば、逆多重化、インデックス作成、格納など）し、他のＭＡＵとは無関係にそれぞれのＭＡＵを処理するのに十分な情報がメディアコンシューマに与えられる。これらの技術は、１つまたは複数のデータセグメントからなるＭＡＵ部分に暗号化を適用することによりＥＳコンテンツを保護しない従来のシステムとは対照的である。
【０００９】
ＥＳコンテンツを保護するシステムおよび方法のこれらの態様および他の態様について、図１から１４を参照しつつさらに詳しく説明することにする。
例示的な装置
説明のため、また必要というわけではないが、パーソナルコンピュータなどのコンピューティングデバイスによって実行されるコンピュータ実行可能命令の一般的背景状況においてＥＳコンテンツの保護について説明する。一般に、プログラムモジュールは、特定のタスクを実行する、または特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。これらのシステムおよび方法は、前記の文脈において説明されているが、以下で説明される活動およびオペレーションは、ハードウェアでも実装することができる。
【００１０】
図１は、ＥＳコンテンツを保護する例示的なシステム１００を示している。システム１００は、汎用コンピューティングデバイス１０２を含む。コンピューティングデバイス１０２は、パーソナルコンピュータ、ラップトップ、サーバー、ハンドヘルドまたはモバイルコンピューティングデバイスなどのどれかのタイプのコンピューティングデバイスを表す。コンピューティングデバイス１０２は、コンピュータ可読媒体１０６に結合されたプロセッサ１０４を備える。コンピュータ可読媒体１０６は、コンピューティングデバイス１０２によってアクセス可能な媒体であればどのような媒体でも使用可能であり、揮発性および不揮発性媒体（例えば、読み取り専用メモリ（ＲＯＭ）およびランダムアクセスメモリ（ＲＡＭ））、取り外し可能および取り外し不可能媒体を含む。コンピュータ可読媒体１０６のＲＡＭ部分は、プロセッサ１０４から直接アクセス可能な、および／またはプロセッサ１０４によって現在操作されているプログラムモジュールおよびプログラムデータを格納する。
【００１１】
例えば、限定はしないが、コンピュータ可読媒体１０６は、プログラムモジュール１０８およびプログラムデータ１１０を格納する。例えば、プログラムモジュール１０８は、ＥＳ保護モジュール１１２、保護ＥＳコンテンツマッピングモジュール１１４、および他のプログラムモジュール１１６（例えば、オペレーティングシステム）を含む。ＥＳ保護モジュール１１２は、メディアコンテンツ固有の特性に基づいて暗号境界を選択することによりＥＳコンテンツを保護する。より具体的には、ＥＳ保護モジュール１１２は、ＥＳコンテンツ１１８を（例えば、ＭＰＥＧ−２などを使用して）暗号化して、保護されたＥＳコンテンツ１２０を生成する。この目的のために、ＥＳ保護モジュール１１２は、ＥＳを含むメディアアクセスユニット（ＭＡＵ）の部分（つまり、データセグメント）に暗号化を適用する。一実装では、暗号化オペレーションは、カウンタモードの高度暗号化標準（ＡＥＳ）である。それぞれのＭＡＵは、単一のビデオまたはオーディオフレーム（エレメンタリストリームフレーム）であり、これは、その後、ヘッダ（例えば、開始コードおよびパディングビット）と関連付けられる。それぞれのＭＡＵは、１つまたは複数のデータセグメントを含む。それぞれのデータセグメントは、ＥＳ保護モジュール１１２がコンテンツ暗号化パラメータの同じ集合を適用するＭＡＵの連続するセクションである。ＥＳ保護モジュール１１２は、データセグメントを完全に暗号化するか、またはそのデータセグメントを完全に平文として残す。ＥＳは、ＴＳに由来していない場合がある。しかし、これらのＥＳ保護オペレーションは、ＴＳストリームに適用される共通スクランブルオペレーションと互換性を持つ（例えば、「他のデータ」１２２を参照）。
【００１２】
保護ＥＳコンテンツマッピングモジュール１１４（「マッピングモジュール１１４」）は、保護されたＥＳコンテンツ１２０をＭＡＵペイロードフォーマット（ＭＰＦ）にマッピングし、トランスポートパケット１２４内にカプセル化する。ＭＰＦでは、ＭＡＵの一部分が暗号化されないまま渡せる（平文に残される）。また、ＭＰＦは、パーソナルコンピュータまたはセットトップボックス（例えば図２を参照）などのメディアコンシューマが他のＥＳと無関係にそれぞれの保護されているＥＳ １２０を処理し、他のＭＡＵと無関係に保護されているＥＳ中のそれぞれのＭＡＵを処理するのに十分な情報を提供する。ＭＰＦは、「トランスポートプロトコルカプセル化のための保護されているＥＳのマッピング」という表題の節を参照しつつ以下で詳しく説明される。一実装では,トランスポートパケットは、リアルタイム転送プロトコル（ＲＴＰ）に基づくパケットに対応する。
【００１３】
一実施形態では、ＥＳコンテンツ（例えば、ＥＳコンテンツ１１８）は、メディアコンテンツトランスポートストリームに由来しない。例えば、他の実施形態では、図２を参照しつつ以下で説明されるように、ＥＳコンテンツはトランスポートストリームに由来する。さらに、例示的なシステム１００は、ＥＳ保護モジュール１１２と同じコンピューティングデバイス内に実装されている保護ＥＳコンテンツマッピングモジュール１１４を示しているが、マッピングモジュール１１４は、保護モジュール１１２を実装するコンピューティングデバイスと異なるコンピューティングデバイスに実装することができる。このような代替え実装は、図２に関して以下で説明されるが、保護モジュール１１２のオペレーションは、コンテンツソースにより実行され、マッピングモジュール１１４のオペレーションは、メディアセンターにより実行される。
例示的なシステム
図２は、一実施形態により、ＥＳコンテンツがトランスポートストリームに由来する、ＥＳコンテンツを保護する例示的なシステム２００を示している。トランスポートストリームは、メディアコンテンツをカプセル化する。例えば、システム２００は、ネットワーク２０６を介して１つまたは複数のメディアサブスクライバ２０８に結合されているコンテンツソース２０２およびメディアセンター２０４を含む。コンテンツソース１００は、ビデオゲームサーバー、Ｗｅｂサイト、ビデオサーバー、ミュージックサーバー、ソフトウェアアーカイブ、データベース、テレビネットワークなどに関連付けることができる。コンテンツソース２０２のＴＳスクランブルモジュール２１０は、トランスポートストリームを暗号化する。一実装では、トランスポートストリーム暗号化２１０では、トランスポートストリームを共通スクランブルする。共通スクランブルにより、ストリームの暗号化された部分を復号化しなくても、暗号化されたトランスポートストリームを処理（例えば、逆多重化、インデックス作成など）することができる。ＴＳスクランブルモジュール２１０は、図１のＥＳ保護モジュール１１２に関して上で説明されているように、モジュールの関連するオペレーションがＴＳストリームに適用される共通スクランブルオペレーションと互換性を有するので、トランスポートストリームに由来するＥＳコンテンツを保護する。
【００１４】
メディアセンター２０４は、例えば、伝送制御プロトコル／インターネットプロトコル（ＴＣＰ／ＩＰ）または他の標準的な通信プロトコルを使用して、コンテンツソース２０２に、直接またはネットワーク２０６を介して結合できる中央集中配置コンピューティングデバイスである。ネットワーク２０６の実施例は、ＩＰネットワーク、ケーブルテレビ（ＣＡＴＶ）ネットワーク、および直接放送衛星（ＤＢＳ）ネットワークを含む。メディアセンター２０４は、逆多重化およびマッピングモジュール２１２を備える。モジュール２１２は、単一のコンピュータプログラムモジュールとして示されているが、任意の数のコンピュータプログラムモジュールにより実装することができる。プログラムモジュール２１２の逆多重化オペレーションは、ＴＳの暗号化部分を復号化することなく、ＴＳをそれぞれのＥＳに逆多重化する。
【００１５】
プログラムモジュール２１２のマッピングオペレーションは、逆多重化された保護されているＥＳコンテンツをＭＰＦに、図１の保護ＥＳコンテンツマッピングモジュール１１４の説明されているオペレーションによりマッピングし、その後、トランスポートパケットにカプセル化してメディアコンシューマに伝達する。上述のように、ＭＰＦを使用すると、（複数の）トランスポートパケットにカプセル化されたときに、ＭＡＵのデータセグメントを平文のままに残すことができる。また、ＭＰＦは、メディアサブスクライバ２０８が他のＥＳと無関係に受け取った、保護されているＥＳを処理し、他のＭＡＵと無関係に保護されているＥＳ内のそれぞれの関連するＭＡＵを処理するのに十分な情報を提供する。ＭＰＦは、「トランスポートプロトコルカプセル化のための保護されているＥＳのマッピング」という表題の節を参照しつつ以下で詳しく説明される。一実装では,トランスポートパケットは、リアルタイム転送プロトコル（ＲＴＰ）に基づくパケットに対応する。
【００１６】
メディアセンター２０４は、ネットワーク２０６上でカプセル化され保護されているＥＳコンテンツを１つまたは複数のサブスクライバ２０８に伝達し、ＰＣ ２１４および／またはＳＴＢ ２１６は、メディアコンテンツを受信する。ＰＣ ２１４上で処理され、レンダリングされたメディアコンテンツは、ＰＣ ２１４に関連付けられているモニタに表示させることができ、ＳＴＢ ２１６上で処理され、レンダリングされたメディア信号は、テレビ（ＴＶ）２１８または類似の表示デバイス上に表示させることができる。一実装では、ＴＶ ２１８は、ＳＴＢ ２１６の機能が内蔵されている。
トランスポートストリーム共通スクランブル分析
一実装では、ＥＳコンテンツは、トランスポートストリームにより配送される。このシナリオでは、コンテンツソース２０２のＴＳスクランブルモジュール２１０は、共通スクランブルを行うためにトランスポートストリームを分析する。特に、トランスポートストリームは、暗号化された後にトランスポートストリームに適用されうる少なくとも１つのプロセスに対するデータ要件に照らして分析される。プロセスの１つまたは複数に対応する統計モデルに基づいて決定がなされる場合、最も広範な（つまり、閾値）データ要件を有する特定のプロセスについて閾値データ要件を決定することができる。この分析は、トランスポートストリームのどの部分が暗号化されないまま通るかを決定するために実行される。
【００１７】
共通スクランブル分析は、ヘッダ情報を含むトランスポートストリーム内のパケットが暗号化されないまま通ることの確認を組み込むことができる。このようなパケットおよびヘッダ情報については、図６を参照しつつ以下で説明される。ＰＥＳヘッダ情報の一部または「追加ヘッダデータ」の一部を含むパケットは、暗号化されずに通る。さらに、完全な、または部分的なストリームマークを含むパケットも、暗号化されずに通る。
【００１８】
【表１】
【００１９】
表１を参照すると、この実装において平文のまま残されるデータの量は、ストリームマークの長さに最大データペイロード長を加えた値に対応することがわかる。平文セクションは、ストリームマークの前から始まり、ストリームマークと最大データペイロード長とを組み合わせた長さ分の後のところで終わるが、ただし組み合わされた長さが、例えば、２つの連続するＴＳパケットペイロードの長さを超えない場合に限ることに留意されたい。例えば、送信機（例えば、図２のコンテンツソース２０２など）は、シーケンスヘッダを表すストリームマークに対し平文中に１６から３６８バイトを残すことができる（ストリームマークに対する４バイトと最大データペイロード長に対する１２バイト）。
【００２０】
また、ストリームマークが現在のＭＡＵの始まりの近くに出現する場合に、前のＭＡＵからのある量のデータを平文中に残すことも可能である。一実装において、これは、平文セクションの長さが３６８バイトを超えない場合に許容される。
【００２１】
トランスポートストリームの一部が暗号化されないまま通るので、他の代替え実施形態では、中に含まれるデータが、逆スクランブルなしでトランスポートストリームを処理するのに使用されない場合に共通スクランブルが適用されるフレームヘッダおよびＰＥＳヘッダを考慮する。
暗号化
図３は、カウンタモードで高度暗号化標準（ＡＥＳ）を使用してＥＳメディアコンテンツを暗号化するオペレーションの例示的な態様を示すブロック図である。図３に関して以下で説明されるさまざまなデータおよびオペレーションは、図１のＥＳ保護モジュール１１２の例示的なオペレーションおよび図２のＴＳスクランブルモジュール２１０の例示的なオペレーションを表している。データセグメントは、ＥＳを暗号化するときに、保護されるコンテンツのタイプに基づき異なる定義を有する場合があるが、任意の数のデータセグメントを含むＭＡＵは、ビデオまたはオーディオの単一のフレームを表す。
【００２２】
図３を参照すると、カウンタモードのＡＥＳは、トランスポートストリームのそれぞれのデータセグメントに基づいて複数のバイトからなるストリームを生成する。バイトのストリームとコンテンツの平文部分のバイトとのＸＯＲを取り、暗号化されたコンテンツを作成する。キーストリーム生成器は、ＡＥＳラウンドを使用して、キーストリームの１６バイトブロックを一度に生成する。ＡＥＳラウンドへの入力は、コンテンツ暗号化キー（ＫＣ）およびデータセグメントＩＤと新しいセグメント内のブロックＩＤとの１２８ビット連結である。キーストリーム生成器の出力とデータセグメントの対応するブロック（ｉ）からのデータとのＸＯＲが、バイト毎に取られる。データセグメントが１６バイトで均等に分割可能でない場合、最後のブロックからのデータセグメントの残りのバイトのみと、キーストリームとのＸＯＲが取られ、中の暗号化されたデータ集合について保持される。ＭＡＵ、および関連するヘッダは、さらに多くのデータセグメントである。
【００２３】
図４は、保護されたＥＳを配送するトランスポートストリーム内に挿入する例示的な暗号方式（「ＴＡＧ」）パケットを示す。図４を参照すると、
● ａｄａｐｔａｔｉｏｎ＿ｆｉｅｌｄ＿ｃｏｎｔｒｏｌビットは、１０ｂに設定され（適応フィールドのみ、ペイロードなし）、したがって、連続カウンタを増分する必要はない。
● ＡＦヘッダは、ＭＰＥＧ規格に準拠する４バイトを含む。
【００２４】
○ 第１バイト＝適応フィールド長
○ 第２バイト＝適応フィールド存在フラグ（プライベートデータ＝０ｘ０２）
○ 第３バイト＝プライベートデータ長（ＤＲＭ長）
○ 第４バイト＝バージョン番号（現在は、０ｘ００）
● ＤｒｍＧｕｉｄは、｛Ｂ０ＡＡ４９６６−３Ｂ３９−４００Ａ−ＡＣ３５−４４Ｆ４１Ｂ４６Ｃ９６Ｂ｝に設定されたＧＵＩＤを含む。
● ｂａｓｅ＿ｃｏｕｎｔｅｒは、続く暗号化されたパケットについてＡＥＳカウンタの再同期処理を行う。
● ＳＭバイト（ストリームマーク）は、続くパケットが最初の数バイトが欠けている可能性のある、ストリームマークの先頭を含むことを示す。
【００２５】
○ ＳＭ＝０−次のパケットは、ＰＥＳヘッダの先頭またはＰＥＳヘッダ全体を配送する。
○ ＳＭ＝１−次のパケットは、ストリームマークの先頭を含む。
【００２６】
○ ＳＭ＝２−次のパケットは、第１バイト（００）が欠けている、ストリームマークの先頭を含む。
○ ＳＭ＝３−次のパケットは、最初の２バイト（００ ００）が欠けている、ストリームマークの先頭を含む。
【００２７】
○ ＳＭ＝４−次のパケットは、最初の３バイト（００ ００ ０１）が欠けている、ストリームマークの先頭を含む。
○ ＳＭ＝その他−予約。
● Ｐｒｉｖａｔｅ＿ＤＲＭ＿ｐａｒａｍｅｔｅｒｓは、対応するキーＩＤ値とともにキーＩＤ拡張集合を含む、データセグメント記述子を含む。データセグメントＩＤがＴＡＧパケットのｂａｓｅ＿ｃｏｕｎｔｅｒセクション内に示されているので、ＡＥＳ １２８初期化ベクトル拡張は、存在しない。
● パケットは、０ｘＦＦをパディングされる。
【００２８】
したがって、ＴＡＧパケットは、それぞれの保護されているＰＥＳユニットの前に挿入されるキー識別子（ＫＩＤ）を持つ単一のＴＳパケットである。この実装では、ＴＡＧパケットは、コンテンツがメディアコンシューマに配信されたときに一致するデジタル権利管理（ＤＲＭ）ライセンスを取り出すために使用される。コンテンツ保護レイヤは、カウンタモードでＡＥＳ １２８ビットキーを含み、その場合次の要件が適用される。１２８ビットカウンタは、ｂａｓｅ＿ｃｏｕｎｔｅｒ（ＭＳＢ）とｍｉｎｏｒ＿ｃｏｕｎｔｅｒ（ＬＳＢ）の２つの６４ビットフィールドに分割される。ｂａｓｅ＿ｃｏｕｎｔｅｒおよびｍｉｎｏｒ＿ｃｏｕｎｔｅｒは、上述のデータセグメントＩＤおよびブロックＩＤと同等である。ＴＡＧパケットは、トランスポートストリームの暗号化された部分で使用される暗号化アルゴリズムの識別を行い、復号化キーを推論するために権限のある暗号解読器に必要なデータを提供し、暗号化されないまま、または暗号化されて通るトランスポートストリームの部分を識別することができる。ＴＡＧパケットは、それぞれのプロセスに使用される暗号化されたストリームの部分を識別する他のデータを含むことができる（トリックモードまたはサムネイル抽出のための逆多重化またはインデックス作成）。さらに、ＴＡＧパケットは、多重化されたトランスポートストリームに従って挿入される。
【００２９】
ＴＡＧパケットは、トランスポートストリームのすべての暗号化された部分に対応する形で生成されうる。それとは別に、暗号方式パケットは、暗号化されたＰＥＳペイロードデータの個々のパケットまたはバイトに対応する形で生成されうる。そのため、ＴＡＧパケットは、トランスポートストリーム内のそれぞれのＰＥＳヘッダと対応する形で、またはトランスポートストリーム内の所定の数のＰＥＳヘッダに対応する形で、または他のプロセスについては暗号化されないまま通る所定のパターンのパケットに対応する形で生成されうる。
【００３０】
図５は、一実施形態により、送信機側でトランスポートストリーム内のＥＳコンテンツを保護するオペレーションの例示的な流れを示している（ＥＳコンテンツがトランスポートストリームにより配送されない場合と比べて）。以下のリストは、図５の態様を説明したものである。
● ｓｃｒ−この変数は、現在のＴＳパケットが共通スクランブルされる場合に「ｙｅｓ」に設定され、それ以外の場合には「ｎｏ」に設定される。
● ｋｅｙ＿ｓｙｎｃ−この変数は、送信機がＡＥＳキーを更新する場合に「ｙｅｓ」に設定され、それ以外の場合には「ｎｏ」に設定される。
● ＰＩＤ（１３ビット）−選択されたエレメンタリストリームのＰＩＤ値。
● ｂａｓｅ＿ｃｏｕｎｔｅｒ−この６４ビットフィールドは、送信機の存続期間全体にわたって送信機により一意に定義される。一実装では、ビット０から５０は、セクションカウンタを表し、ビット５１から６３は、そのＰＩＤについて予約されている。
● Ｓｅｃｔｉｏｎ＿ｃｏｕｎｔｅｒ（５１ビット）−ｓｃｒ状態変数のそれぞれのｎｏからｙｅｓへの遷移に対してインクリメントされる循環カウンタ。
● ｍｉｎｏｒ＿ｃｏｕｎｔｅｒ−１６個のスクランブルされたバイトからなるそれぞれのブロックに対しインクリメントされる６４ビットカウンタ。
● ｉ−それぞれスクランブルされたバイトに対しインクリメントされる４ビットカウンタ。
● ｓｃｒａｍｂｌｅ１６−ＡＥＳＫＥＹ［ｂａｓｅ＿ｃｏｕｎｔｅｒ ｜ ｍｉｎｏｒ＿ｃｏｕｎｔｅｒ］。
【００３１】
Ｒｅｐｌａｃｅ ＡＥＳ Ｋｅｙイベントが発生した後、送信機は、即座に、すべてのＰＩＤをスクランブルすることを停止し、それぞれのＰＥＳコンポーネントと再同期するまで停止したままになる。この遷移により、同じプログラムからのすべてのＰＩＤが同じキーでスクランブルされることが保証される。ｓｃｒステータスを定義するときに、送信機は、以下の条件のどれかが適用される場合に、受信されたＴＳパケット毎に、ｓｃｒ状態変数を「ｎｏ」に設定する。
● ｋｅｙ＿ｓｙｎｃ＝ｙｅｓ
● ＴＳパケットが、ＰＥＳヘッダの全部または一部を含む。
● ＴＳパケットが、以下の表に記載されているストリームマークの１つまたは複数の全部または一部を含む。ストリームマークは、上の表１に示されているように、ＭＰＥＧ開始コードとその続くデータペイロードからなる。
【００３２】
図６は、一実施形態による、例示的なトランスポートストリームを示している。送信機は、ＴＡＧパケットを平文中に残されているＴＳパケットの前に挿入する。図６に示されているように、以下の２つのシナリオが考えられる。ケースＡ：ＴＡＧパケットが、ＰＥＳヘッダの全部または一部を含むパケットの前に挿入される。ケースＢ：ＴＡＧパケットが、ストリームマークの全部または一部を含むパケットの前に挿入される。
さらに、実施形態では、ＴＡＧパケットがトランスポートストリーム内に挿入されることを必要としない。復号化の時点までＴＡＧパケットは必要ないため、復号化の時点にプロセッサにより受信される限り、ＴＡＧパケットは、プロセッサに帯域内または帯域外で（例えば、プライベートテーブルにより）送信することができる。それに加えて、ＴＡＧパケットは、その後帯域内または帯域外でプロセッサに送信されるコンテンツ利用ライセンスに送信されうる。
保護されているＥＳのＭＡＵペイロードフォーマットへのマッピング
保護されているＥＳは、共通スクランブルされたトランスポートストリーム内のＭＡＵのセクションが平文中に残されるようにＭＰＦにマッピングされる。このマッピングにより、メディアコンシューマはそれぞれのＭＡＵを独立に処理することができる。一実装では、コンテンツソース２０２などの送信機がこれらのマッピングオペレーションを実行する。
【００３３】
従来のＲＴＰヘッダの構文は、ＲＦＣ−３５５０において定義されており、また図１１に示されている。ＲＴＰヘッダとともに、図１のシステム１００および図２のシステム２００は、保護されているＥＳコンテンツ（例えば、図１の保護ＥＳコンテンツ１２０）をＭＡＵペイロードフォーマット（ＭＰＦ）にマッピングする。しかし、マルチメディアプレゼンテーションにおけるすべてのメディアストリームが、同じＭＰＦを使用する必要はなく、異なるペイロードフォーマットを使用することもできる。そこで、ＭＡＵがＭＰＦにおいてどのようにカプセル化されるかについて説明する。
【００３４】
図７は、一実施形態による、ＭＰＦヘッダの例示的な高水準構造を例示している。ヘッダは、標準ＲＴＰヘッダに関して示されている。ＭＰＦヘッダは、送信機（例えば、図１のコンピュータ１０２および／または図２のメディアセンター）により、トランスポートパケット内のそれぞれのＭＡＵ、またはそのフラグメントの前に挿入される。図７に示されているように、この例示的な実装におけるＭＰＦヘッダは、３つのセクションに分割される。それぞれのセクションは、１バイトビットフィールドから始まり、その後に１つまたは複数のオプションフィールドが続く。いくつかの場合において、ＭＰＦヘッダから、最大２つまでのセクションを丸ごと省くことができる。そのため、ＭＰＦヘッダは、１バイトと小さくすることができる。
【００３５】
ＭＰＦヘッダの後に、「ペイロード」が続く。ペイロードは、完全なＭＡＵ、またはそのフラグメントを含む。ペイロードは、部分的ＭＡＵを含み、複数のトランスポートパケット中の複数のペイロードにわたって大きなＭＡＵを断片化（フラグメント化）することができる。トランスポートパケットのサイズにより許されれば、第１のペイロードの後に、ＭＰＦヘッダとペイロードの追加の対を続けることができる。
【００３６】
図７において「Ｐａｃｋｅｔ Ｓｐｅｃｉｆｉｃ Ｉｎｆｏ（パケット指定情報）」と呼ばれる、ＭＰＦヘッダの第１のセクションは、トランスポートパケット内のすべてのペイロードに固有の情報を含む。「Ｐａｃｋｅｔ Ｓｐｅｃｉｆｉｃ Ｉｎｆｏ」セクションは、ＲＴＰヘッダの終わりの直後に出現する、第１のＭＰＦヘッダにおいて、それぞれのトランスポートパケット内に１回だけ含まれる。「ＭＡＵ Ｐｒｏｐｅｒｔｉｅｓ（ＭＡＵプロパティ）」と呼ばれる第２のセクションは、ペイロードを説明する情報を含む。例えば、このセクションでは、ペイロードがビデオＩフレームなどの同期点であるＭＡＵを含むかどうかを指定し、さらに、ペイロードのサイズがどのように決定されるかも指定する。さらに、このセクションは、前のパケットが失われた場合にトランスポートパケットを受信機側で解析するために使用される情報を含む。これは、ＭＡＵが複数のトランスポートパケット上に断片化されている場合に有用である。
【００３７】
「ＭＡＵ Ｔｉｍｉｎｇ（ＭＡＵタイミング）」と呼ばれる第３のセクションは、ペイロード中のＭＡＵに関連付けられているさまざまなタイムスタンプに関する情報を提供する。例えば、このセクションでは、ＭＡＵのプレゼンテーション時間がどのように決定されるかを指定する。このセクションは、さらに、追加の情報をＭＰＦヘッダに入れるための拡張機構も備える。
【００３８】
図８は、一実施形態による、図７のＭＰＦヘッダの例示的な詳細レイアウトを示している。図８の３つのセクション８０２から８０６はそれぞれ、複数の個別ヘッダフィールドを備える。これらのフィールドは、図８にボックスとして示されている。これらのボックスの高さは、ヘッダフィールドの相対的サイズを示すものとなっている。しかし、図は、完全に縮尺通りには描かれておらず、「Ｅｘｔｅｎｓｉｏｎ（拡張）」フィールドは可変長サイズを有することに留意されたい。
【００３９】
図８を参照すると、３つのセクションのそれぞれの中の第１のヘッダフィールドは、ビットフィールドである。セクション内の他のヘッダフィールドは、そのセクションのビットフィールドにより示された場合にのみ存在する。いくつかの場合において、そのビットフィールドを含む、１つのセクション全体を省くことができる。パケット指定情報（Ｉｎｆｏ）セクションは、「Ｂｉｔ Ｆｉｅｌｄ １（ビットフィールド１）」を含み、また図８に示されている他のフィールドのどれかも含みうる。同じトランスポートパケット内の追加のＭＰＦヘッダは、「Ｂｉｔ Ｆｉｅｌｄ ２（ビットフィールド２）」から始まり、「ＭＡＵ Ｐｒｏｐｅｒｔｉｅｓ」セクションおよび「ＭＡＵ Ｔｉｍｉｎｇ」セクション内にフィールドを備える。
【００４０】
可能な最も単純な場合には、トランスポートパケットは、単一の完全なＭＡＵを含む。この場合、ヘッダフィールドのすべてを含めることが可能である。しかし、必要のないフィールドは省くことができる。ＭＰＦヘッダの３つのセクションのそれぞれは、もし存在する場合、そのセクション内のフィールドのどれが存在するかを示すビットフィールドを有する。
【００４１】
例えば、現在のペイロードの終わりに対するバイトオフセットを指定する「Ｏｆｆｓｅｔ（オフセット）」フィールドは、パケットが単一のペイロードを含む場合には必要ないが、それは、ペイロードの長さが、トランスポートパケットのサイズにより推論できるからである。「Ｂｉｔ Ｆｉｅｌｄ ２」内の「ＯＰ」は、「Ｏｆｆｓｅｔ」フィールドが存在するかどうかを示す。「Ｂｉｔ Ｆｉｅｌｄ ３（ビットフィールド３）」内のビットのすべてが０である場合、「Ｂｉｔ Ｆｉｅｌｄ ３」それ自体を省くことができ、これは、「Ｂｉｔ Ｆｉｅｌｄ ２」内の「Ｂ３Ｐ」を０に設定することにより示される。
【００４２】
複数のペイロードを単一のトランスポートパケット内にまとめることが可能である。これは、「グルーピング」と呼ばれる。「Ｏｆｆｓｅｔ」フィールドは、「グルーピング」の使用を示す。「Ｏｆｆｓｅｔ」フィールドが存在する場合、他のＭＰＦヘッダおよび他のペイロードは、現在のペイロードの終わりの後から続くことができる。「Ｏｆｆｓｅｔ」フィールドは、「Ｏｆｆｓｅｔ」フィールド自体の終わりから数えた、現在のペイロードの終わりまでのバイトの個数を指定する。他のＭＰＦヘッダが現在のペイロードの終わりの後に続くかどうかを判定するために、いくつかの実装において、「Ｏｆｆｓｅｔ」フィールドの値だけでなく、トランスポートパケットのサイズをも考慮する必要があり、またＲＴＰがトランスポートプロトコルとして使用される場合に、もしあれば、ＲＴＰパディング領域のサイズも考慮する必要がある。
【００４３】
単一のＭＡＵを分割して複数のペイロードに分けることができる。これは、「断片化」と呼ばれる。断片化は、ＭＡＵが単一のトランスポートパケット内に収まることのできるものの大きさを超えた場合に主に使用される。「Ｂｉｔ Ｆｉｅｌｄ ２」内の「Ｆ」フィールドは、ペイロードが完全なＭＡＵまたはそのフラグメントを含むかどうかを示す。
【００４４】
「ＭＡＵ Ｔｉｍｉｎｇ」セクション内のフィールドは、ＭＡＵの第１のフラグメントを含むペイロードに対するＭＰＦヘッダ内でのみ指定すべきである。これに対する唯一の例外は、「ＭＡＵ Ｔｉｍｉｎｇ」セクション内の「Ｅｘｔｅｎｓｉｏｎ」フィールドが同じＭＡＵの異なるフラグメントに対し異なる拡張を含む場合である。ＭＡＵが断片化された場合に、「Ｂｉｔ Ｆｉｅｌｄ ２」内のビット「Ｓ」、「Ｄ１」、および「Ｄ２」は、第１のフラグメントを含むペイロードに対するＭＰＦヘッダでのみ有意である。したがって、受信機（メディアコンシューマ）は、「Ｆ」フィールドの値が０または２の場合にこれらのビットを無視する。
【００４５】
この実装では、ＭＡＵは、大きすぎて単一のトランスポートパケットに収まらないというのでない限り断片化されない。この実装では、ＭＡＵのフラグメントは、単一のトランスポートパケットにおいて、他のＭＡＵと、または他のＭＡＵのフラグメントと組み合わされることはない。しかし、受信機は、そのまま、これらのケースも取り扱える。これの実施例は、図９に示されている。
【００４６】
図９は、一実施形態により、ＭＰＦを使用するリアルタイムトランスポートパケットという３つのパケットの例示的シーケンスを示している。この３つのトランスポートパケットは、４つのＭＡＵからなるデータを配送する。第４のＭＡＵは、第４のトランスポートパケット（図示せず）内で続けられる。図は、もし必要ならば、固定サイズのトランスポートパケットを作成するためにＭＡＵの断片化をどのように使用できるかを示している。図からわかるように、ＭＡＵ ２は、２つのトランスポートパケットにわたって断片化されている。第１のトランスポートパケットでは、ＭＡＵ ２に対するＭＰＦヘッダは、次のトランスポートパケット内でＭＵＡ ２が継続されることを指定する。（これは、「Ｂｉｔ Ｆｉｅｌｄ ２」内の「Ｆ」フィールドを使用して知らされる）。
【００４７】
第２のトランスポートパケットは、「ＭＡＵ Ｔｉｍｉｎｇ」フィールドを省いたＭＰＦヘッダから始まるが、それは、ＭＡＵ２に対する「ＭＡＵ Ｔｉｍｉｎｇ」フィールドが、すでに、第１のトランスポートパケット内で指定されているからである。「ＭＡＵ Ｐｒｏｐｅｒｔｉｅｓ」セクションの「Ｏｆｆｓｅｔ」フィールドは、ＭＡＵ ３に対するペイロードフォーマットヘッダの先頭を見つけるために使用される。これにより、クライアントは、前のトランスポートパケットが失われたとしても、ＭＡＵ ３を復号化することができる。同様に、図は、ＭＡＵ ４が第２および第３のトランスポートパケット上にどのように断片化されるかを示している。しかし、ＭＡＵ ４は、大きくて、追加のＭＡＵを第３のトランスポートパケット内に挿入することができない。この実施例では、ＭＡＵ ４は、図に示されていない、第４のトランスポートパケット内で続けられる。このような状況では、第３トランスポートパケットのペイロードフォーマットヘッダは、「Ｏｆｆｓｅｔ」フィールドを含む必要はなく、「ＭＡＵ Ｐｒｏｐｅｒｔｉｅｓ」セクション全体を省くことが可能な場合がある。次いで、ＭＰＦヘッダの残り部分は、「Ｐａｃｋｅｔ Ｓｐｅｃｉｆｉｃ Ｉｎｆｏ」セクションのみを含み、単一のバイトと同じくらい小さくできる。
【００４８】
ＭＡＵが複数のペイロードに断片化される場合、それらのペイロードは、通常、別々のトランスポートパケットで配送される。しかし、このＭＰＦでは、さらに、同じＭＡＵに対する複数のペイロードを単一のトランスポートパケット内で配送することもできる。
【００４９】
トランスポートパケット内のペイロードがＭＡＵのフラグメントを含む場合、これは、「Ｂｉｔ Ｆｉｅｌｄ ２」内の「Ｆ」フィールドにより示される。
図１０は、一実施形態により、単一のＭＡＵが同じＲＴＰパケット内の３つのフラグメントに分割されている一実施例を示している。この実施例では、第１のＭＰＦヘッダ内の「Ｆ」フィールドは、１に設定され、第１のペイロードがＭＡＵの第１のフラグメントを含むことを示す。「ＭＡＵ Ｔｉｍｉｎｇ」セクションは、この第１のペイロードにしか存在しない。第２のＭＰＦヘッダ内の「Ｆ」フィールドは、０に設定され、そのペイロードが、ＭＡＵの最初のフラグメントでも最後のフラグメントでもないフラグメントを含むことを示す。第３のＭＰＦヘッダ内の「Ｆ」フィールドは、２に設定され、そのペイロードがＭＡＵの最後のフラグメントを含むことを示す。
【００５０】
通常のＲＴＰサンプリングクロックおよびウォールクロックに加えて、ＭＰＦは、これから説明する、いくつかの追加のタイムスタンプおよび時間の概念を示す。ＲＴＰヘッダは、パケット内のデータがサンプリングされた時間を指定する、単一のタイムスタンプを有する。このタイムスタンプは、ときには、サンプリングクロックとも呼ばれる。異なるメディアストリームに属すパケットのＲＴＰタイムスタンプは、比較することができないことに留意されたい。なぜなら、サンプリングクロックは、異なるメディアストリームについては異なる周波数で動作する可能性があるからである。例えば、オーディオストリームのサンプリングクロックは４４１００Ｈｚで動作するが、ビデオストリームのサンプリングクロックは、９００００Ｈｚで動作しうる。さらに、ＲＦＣ−３５５０では、初期ＲＴＰタイムスタンプの値は、ランダムに選択されなければならないと規定している。実際、それぞれのメディアストリームは、それ専用の時系列を有する。本明細書では、それぞれのこのような時系列は、「メディア時系列」と呼ばれる。
【００５１】
ＲＴＰにより、異なるメディアストリームに対する時系列を「ウォールクロック」と呼ばれる基準クロックの時系列と同期させることができる。ＲＴＰ送信機側では、受信機がサンプリングクロックとＲＴＣＰ送信機レポートパケット内のウォールクロックとの間のマッピングを送信することによりこのような同期を取ることを許可する。メディアストリームが異なるサンプリングクロックを使用する場合があるため、メディアストリーム毎に異なるＲＴＣＰ送信機レポートが送信されなければならない。
【００５２】
マッピングは、何らかの間隔で再び更新および送信され、これにより、受信機側は、ウォールクロックとサンプリングクロックとの間で発生しうるドリフトを補正することができる。クロックドリフトは、送信機のウォールクロックが受信機のウォールクロックに関してドリフトする場合には依然として問題となりうる。２つのクロックを同期させるために、例えば、ＮＴＰプロトコルを使用することが可能であろうが、ＲＴＰ規格では、特定の同期方法を規定していない。ウォールクロックは、符号器から供給されることに留意されたい。ＲＴＰ送信機および符号器が、別々の要素である場合、ウォールクロックは、典型的には、送信機側のどの物理的クロックとも無関係である。
【００５３】
このＭＰＦは、通常再生時間（ＮＰＴ）時系列と呼ばれる第３の時系列を使用する。ＮＰＴ時系列は、主にＲＴＰがメディアの「プレゼンテーション」を送信するために使用される場合に有用である。ＮＰＴ時系列から得られるタイムスタンプは、ふつう、プレゼンテーションの先頭の０から始まる。ＮＰＴタイムスタンプは、特に、事前に記録されているプレゼンテーションを送信する場合に有用であるが、それは、タイムスタンプを使用すると受信機側がプレゼンテーション内で探索すべき位置をユーザーが指定するのを補助するからである。この場合、受信機が新しい位置をＲＴＰ送信機に伝達するための何らかの機構の存在を仮定する。
【００５４】
ＲＴＰは、マルチメディア会議アプリケーション向けに設計されていたため、ＲＴＰ規格では、ＮＰＴ時系列を規定しない。しかし、ＲＴＳＰ（ビデオオンデマンドアプリケーション用の制御プロトコル）などのＲＴＰの上に構築された他のプロトコルは、ＮＰＴ時系列の概念を含む。ＲＴＳＰでは、制御プロトコルは、メディアストリーム毎にＮＰＴ時系列とメディア時系列との間のマッピングを行う。
【００５５】
ＭＰＦは、ＭＡＵに関連付けられているＮＰＴ時系列タイムスタンプを指定する機構を定義する。しかし、実用的であれば、ＲＴＳＰによって定義されたものなどのメディア時系列とＮＰＴ時系列との間の帯域外マッピングは、ＭＰＦヘッダのオーバーヘッドを低減するので、好ましい場合がある。
【００５６】
すべてのＲＴＰ準拠システムは、タイムスタンプのラップアラウンドを処理する。典型的なクロック周波数９００００Ｈｚでは、ＲＴＰタイムスタンプは、ほぼ１３時間おきにラップアラウンドする。しかし、ＲＴＰ規格では、ランダムオフセットをサンプリングクロックに加えなければならないと規定しているため、受信機で生じる第１のラップアラウンドは、１３時間よりも著しく短いものとなりうる。ＲＴＰタイムスタンプのラップアラウンドは、通常、合同演算を使用することにより処理される。合同演算が使用される場合、タイムスタンプは、通常、一方のタイムスタンプを他方のタイムスタンプから減算し、その結果が正であるか、または負であるかを観察することにより比較される。
【００５７】
ＭＰＦでは、それぞれのＭＡＵは、「復号化時間」および「プレゼンテーション時間」を有する。復号化時間は、ＭＡＵが受信機の復号器に送られなければならない期限であり、プレゼンテーション時間は、ＭＡＵが受信機により提示（表示または再生）されなければならない時間である。時間は両方とも、メディア時系列に属する。ネットワークおよび復号器内の遅延が典型的にはＲＴＰ送信機側に知られていないため、受信機側では、復号化タイムスタンプまたはプレゼンテーションタイムスタンプの絶対値を使用しない。受信機側では、復号化タイムスタンプの対またはプレゼンテーションタイムスタンプの対の間の相対的差のみを考慮する。
【００５８】
ビデオコーデックが双方向ビデオフレームを生成する場合などいくつかの場合において、ＭＡＵは、提示される異なる順序で復号化することができる。この実装では、ＲＴＰ送信機は、ＭＡＵを、それらが復号化されなければならない順序で送信する。
【００５９】
ＲＴＰヘッダ内の「Ｔｉｍｅｓｔａｍｐ（タイムスタンプ）」フィールドは、トランスポートパケットを第１のＭＡＵのプレゼンテーション時間にマッピングされる。トランスポートパケットは、復号化順序で送信されるため、連続するＭＡＵのプレゼンテーション時間スタンプは、単調非減少とはなりえない。
【００６０】
ＭＰＦヘッダは、オプションの「Ｄｅｃｏｄｅ Ｔｉｍｅ（復号化時間）」フィールドを含み、これは、ペイロード中のＭＡＵの復号化時間を指定するために使用される。ＭＰＦヘッダは、さらに、「Ｐｒｅｓｅｎｔａｔｉｏｎ Ｔｉｍｅ」フィールドを含み、これは、トランスポートパケットが複数のＭＡＵを含む場合に、ＭＡＵのプレゼンテーション時間を指定するために使用される。単一のＭＡＵのみがトランスポートパケットに含まれる場合、「Ｐｒｅｓｅｎｔａｔｉｏｎ Ｔｉｍｅ（プレゼンテーション時間）」フィールドであるが、それは、「Ｔｉｍｅｓｔａｍｐ」フィールドがパケット内の第１のＭＡＵのそのフィールドの代替えとして使用されるからである。この実装では、「Ｄｅｃｏｄｅ Ｔｉｍｅ」および「Ｐｒｅｓｅｎｔａｔｉｏｎ Ｔｉｍｅ」の両方フィールドが、「Ｔｉｍｅｓｔａｍｐ」フィールドと同じクロック分解能を使用して表される。
【００６１】
「トリックプレイ」という用語は、受信機が非リアルタイム速度でメディアンプレゼンテーションをレンダリングすることを意味する。トリックプレイの実施例は、プレゼンテーションの早送りおよび巻き戻しを含む。ＲＴＰ送信機が、トリックプレイモードで送信している場合、それぞれのＭＡＵに対する復号化タイムスタンプおよびプレゼンテーションタイムスタンプは、リアルタイム速度でインクリメントしなければならない。これにより、復号器は、トリックプレイが使用されることを知らずにＭＡＵを復号化することができる。ＭＰＦヘッダ内の「Ｄｅｃｏｄｅ Ｔｉｍｅ」および「Ｐｒｅｓｅｎｔａｔｉｏｎ Ｔｉｍｅ」フィールドは、トリックプレイの影響を受けず、「ＮＰＴ」フィールドは、存在する場合、影響を受けないということはない。例えば、メディアプレゼンテーションが巻き戻しされている場合、ＭＡＵの「Ｐｒｅｓｅｎｔａｔｉｏｎ Ｔｉｍｅ」タイムスタンプフィールドは、増加するが、「ＮＰＴ」フィールドの値は、減少する。
【００６２】
ＭＰＦヘッダ内の「ＮＰＴ」フィールドでは、ＭＡＵが属する通常再生時間時系列内の位置を指定する。「ＮＰＴ」フィールドが存在していない場合、受信機は、２つの時系列の間のマッピングが利用可能とした場合に、プレゼンテーション時間からＭＡＵの通常再生時間を計算することができる。このマッピングを設定するさまざまなアプローチについて、以下で説明する。ＲＴＰ送信機は、メディア時系列内のタイムスタンプにランダムオフセットを加えるので、プレゼンテーション時間タイムスタンプは、ＮＰＴタイムスタンプの直接的代替えとして使用されない。このランダムオフセットが受信機側に知られているとしても、メディア時系列タイムスタンプのラップアラウンドは、問題となる可能性がある。
【００６３】
これらの問題に対し考えられる解決策として、送信機側で帯域側機構を使用して通常再生時間時系列とメディア時系列との間のマッピングを行うという方法がある。このマッピングは、伝送の開始時に１回だけ、または必要に応じて繰り返し行うことも可能である。さらに、トリックプレイが可能であれば、送信機側でトリックプレイ速度を伝達する。例えば、プレゼンテーションが巻き戻しされている場合、トリックプレイ速度は負である。受信機では、トリックプレイ速度を使用して、プレゼンテーション時間が長くなると減少するＮＰＴタイムスタンプを生成する。
【００６４】
マッピングが、伝送の始めに１回だけ行われる場合、受信機側で、通常再生時間時系列とウォールクロック時系列との間のマッピングを確立する。これは、通常、適切なＲＴＣＰ送信機レポートパケットが受信されると直ちに可能になる。メディア時系列からのタイムスタンプは、ウォールクロック時系列に対してドリフトする可能性があるため、ＭＡＵのウォールクロック時間に基づいてそれぞれのＭＡＵについてＮＰＴタイムスタンプを計算することが好ましい。
【００６５】
ＲＴＳＰプロトコルは、通常再生時間時系列と伝送の始めのメディア時系列との間のマッピングを行う制御プロトコルの一実施例である。複雑度とオーバーヘッドとの間の適当なトレードオフの関係をもたらす他の解決策では、同期点ＭＡＵでのみ「ＮＰＴ」フィールドを含む。「ＮＰＴ」フィールドは、通常再生時間時系列とプレゼンテーションまたはウォールクロック時系列との間のマッピングを確立するために使用される。非同期点ＭＡＵについては、受信機は、すでに確立されているマッピングを使用してＮＰＴタイムスタンプを計算する。トリックプレイが使用される場合、送信機は、すべてのＭＡＵについて「ＮＰＴ」フィールドを含む。
【００６６】
ＭＰＦヘッダ内の「Ｓｅｎｄ Ｔｉｍｅ（伝送時間）」フィールドでは、トランスポートパケットの伝送時間を指定する。これは、トランスポートパケットのシーケンスが、一方のサーバーから第２のサーバーに転送される場合に有用と考えられる。第１のサーバーのみが、パケットに対する伝送スケジュールを計算する必要がある。第２のサーバーは、「Ｓｅｎｄ Ｔｉｍｅ」フィールドの値に基づいてトランスポートパケットを他のクライアントに転送する。トランスポートパケットをクライアントに転送するときに、「Ｓｅｎｄ Ｔｉｍｅ」フィールドを含んでいる必要はない。しかし、クライアントは、一連のパケット内の「Ｓｅｎｄ Ｔｉｍｅ」フィールドの値の差をパケット到着時間の差と突き合わせて比較することにより「Ｓｅｎｄ Ｔｉｍｅ」フィールドを使用して、ネットワークの混雑を検出することができる。「Ｓｅｎｄ Ｔｉｍｅ」フィールドでは、メディア時系列と同じユニットを使用する。
【００６７】
「Ｃｏｒｒｅｓｐｏｎｄｅｎｃｅ（対応）」フィールドは、ウォールクロック時系列と現在のメディア時系列との間のマッピングを規定する。ＲＴＰが転送プロトコルの場合、これは、ＲＴＣＰ送信機レポート内にもたらされるのと同じマッピングである。トランスポートパケット内にマッピングを含めることは、別のＲＴＣＰパケットを伝送するのよりも効率的である。これにより、送信機は、ＲＴＣＰ送信機レポートの頻度を下げ、そのまま、必要な頻度でマッピングを送信することができる。
【００６８】
図１１は、参照を目的として標準的な１２バイトＲＴＰヘッダを例示している。図１１を参照すると、
● 「Ｖｅｒｓｉｏｎ」（Ｖ）フィールド：２ビット。このフィールドは、２に設定される。
● 「Ｐａｄｄｉｎｇ」（Ｐ）ビット：このビットは、ＲＴＰパケットの末尾にパディングを加えるために使用される。
● 「Ｅｘｔｅｎｓｉｏｎ」（Ｘ）ビット：このビットは、ＲＴＰヘッダ拡張が存在している場合に１に設定される。ＲＴＰプロファイルで、ヘッダ拡張がどのように使用されるかが定義される。受信機は、ＲＴＰヘッダが非ゼロの「Ｅｘｔｅｎｓｉｏｎ」ビットを有している場合にヘッダ拡張を解析するか、またはスキップすることができる。
● 「Ｃｏｎｔｒｉｂｕｔｉｎｇ Ｓｏｕｒｃｅ」（ＣＣ）フィールド：４ビット。受信機は、ＲＴＰヘッダが非ゼロの「ｃｏｎｔｒｉｂｕｔｉｎｇ ｓｏｕｒｃｅ」フィールドを有している場合に寄与するソースのリストを正しく解析するか、またはスキップすることができる。
● 「Ｍａｒｋｅｒ」（Ｍ）ビット：このビットは、トランスポートパケット内のペイロードが完全なＭＡＵまたはＭＡＵの最後のフラグメントを含む場合に１に設定される。
● 「Ｐａｙｌｏａｄ Ｔｙｐｅ」（ＰＴ）フィールド：７ビット。ＲＴＰペイロードタイプの割り当ては、本明細書の範囲を外れている。これは、このペイロードフォーマットが使用されるか、または動的に帯域外に信号伝送される際に基づくＲＴＰプロファイルにより指定される（例えば、ＳＤＰを使用して）。
● 「Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒ」フィールド：１６ビット。このフィールドは、同じＳＳＲＣ値とともにトランスポートパケットが送信される毎に１だけインクリメントされる数を含む。ＲＴＰシーケンス番号の初期値は、非ＲＴＰ手段を通じてクライアントに伝達することができる。
● 「Ｔｉｍｅｓｔａｍｐ」フィールド：３２ビット。このフィールドでは、トランスポートパケットに含まれる第１のペイロードに適用されるタイムスタンプを指定する。デフォルトでは、このフィールドは、プレゼンテーション時間として解釈される。「Ｔｉｍｅｓｔａｍｐ」フィールドのクロック周波数は、９０ｋＨｚとすることが推奨される、つまり、分解能は、１／９００００秒である。送信機および受信機は、非ＲＴＰ手段を通じて異なるクロック周波数をネゴシエートすることができる。
● 「Ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ Ｓｏｕｒｃｅ」（ＳＳＲＣ）フィールド：３２ビット。ＳＳＲＣフィールドに対し同じ値を持つトランスポートパケットは、「Ｔｉｍｅｓｔａｍｐ」フィールドに対する同じ時系列および「Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒ」フィールドに対する同じ数空間を共有する。
【００６９】
ＲＴＰヘッダの後に、ＭＰＦヘッダが続く。唯一の例外は、パディングしか含まないトランスポートパケットである。その場合、ＭＰＦヘッダは、存在しない。トランスポートパケットが、複数のＭＡＵからのデータを含む場合、ＭＰＦヘッダは、それぞれのＭＡＵの前、およびそれぞれの断片化された（部分的）ＭＡＵの前に現れる。したがって、このペイロードフォーマットを使用するトランスポートパケットは、１つまたは複数のＭＰＦヘッダを含むことができる。ＭＰＦヘッダのレイアウトは、図７に示されている。ＭＰＦヘッダが標準１２バイトＲＴＰヘッダの直後に来る場合、これは、「Ｂｉｔ Ｆｉｅｌｄ １」という１バイトフィールドから始まり、その後に一連のオプションフィールドが続く。このヘッダの後に、ペイロードが続く。ペイロードは、完全なＭＡＵ、またはフラグメント（部分的）ＭＡＵのいずれかを含む。
【００７０】
第１のデータペイロードの後に、他のＭＰＦヘッダが現れ、他のデータペイロードが続く。データペイロードの後に他のＭＰＦヘッダを加えるプロセスは、複数回繰り返すことができる。「Ｂｉｔ Ｆｉｅｌｄ ２」フィールドを持つ第１のデータペイロードに続くそれぞれのＭＰＦヘッダ。
【００７１】
以下に、「Ｂｉｔ Ｆｉｅｌｄ １」フィールドのレイアウトを示す。
● 「Ｓｅｎｄ Ｔｉｍｅ Ｐｒｅｓｅｎｔ」（ＳＴ）ビット：このビットが１の場合、３２ビットの「Ｓｅｎｄ Ｔｉｍｅ」フィールドが、「Ｂｉｔ Ｆｉｅｌｄ １」フィールドの末尾の直後に挿入される。
● 「Ｃｏｒｒｅｓｐｏｎｄｅｎｃｅ Ｐｒｅｓｅｎｔ」（ＣＰ）ビット：このビットが１の場合、９６ビットの「Ｃｏｒｒｅｓｐｏｎｄｅｎｃｅ」フィールドが、「Ｓｅｎｄ Ｔｉｍｅ」フィールドの後に挿入される。
● Ｒ１、Ｒ２、Ｒ３（それぞれ１ビット）：１に設定されているこれらのビットのそれぞれについて、受信機側では、３２ビットフィールドが「Ｃｏｒｒｅｓｐｏｎｄｅｎｃｅ」フィールドと「Ｂｉｔ Ｆｉｅｌｄ ２」との間に追加されていると想定する。これらの３２ビットフィールドの意味は、本明細書では定義されていない。３２ビットフィールドの意味を認識しない受信機は、それらを無視する。
● Ｒ４、Ｒ５（それぞれ１ビット）：将来使用するために予約されており、現在は、０に設定されている。
● 「Ｂｉｔ Ｆｉｅｌｄ ２ Ｐｒｅｓｅｎｔ」（Ｂ２Ｐ）ビット：このビットが１の場合、１バイトの「Ｂｉｔ Ｆｉｅｌｄ ２」フィールドが、「Ｃｏｒｒｅｓｐｏｎｄｅｎｃｅ」フィールドの後に挿入される。
● 「Ｓｅｎｄ Ｔｉｍｅ」フィールド：３２ビット。このフィールドは、ＲＴＰヘッダ内の「Ｔｉｍｅｓｔａｍｐ」フィールドに使用されるのと同じ時間単位を使用して、トランスポートパケットの伝送時間を指定する。
● 「Ｃｏｒｒｅｓｐｏｎｄｅｎｃｅ」フィールド：９６ビット。フィールドは、２つのタイムスタンプを含む。ＮＴＰフォーマットの６４ビットウォールクロックタイムスタンプ、および３２ビット復号化時間タイムスタンプ。２つのフィールドは、ＲＦＣ−３５５０の６．４．１で定義されている、ＲＴＣＰ送信機レポートの「ＮＴＰ ｔｉｍｅｓｔａｍｐ」および「ＲＴＰ ｔｉｍｅｓｔａｍｐ」フィールドと同じようにして使用される。
【００７２】
「Ｂｉｔ Ｆｉｅｌｄ １」が存在する場合、「Ｂｉｔ Ｆｉｅｌｄ ２」はオプションである。「Ｂｉｔ Ｆｉｅｌｄ １」の「Ｂ２Ｐ」ビットは、「Ｂｉｔ Ｆｉｅｌｄ ２」が存在するかどうかを判定する。「Ｂｉｔ Ｆｉｅｌｄ ２」のすべてのビットに対するデフォルト値は、０である。「Ｆｒａｇｍｅｎｔａｔｉｏｎ」フィールド（Ｆ）は、データペイロードが部分的ＭＡＵを含むかどうかを示す。１つまたは複数のそのようなペイロードが組み合わされ、完全なＭＡＵを再構成する。「Ｆ」フィールドは、さらに、ペイロードが、ＭＡＵの最初または最後のフラグメントを含むかどうかも示す。「Ｓ」、「Ｄ １」、および「Ｄ２」ビット（以下）は、「Ｆ」フィールドの値が０または３の場合にのみ有効である。表２は、Ｆフィールド値の例示的な意味を示す。
【００７３】
【表２】
【００７４】
「Ｏｆｆｓｅｔ Ｐｒｅｓｅｎｔ」ビット（ＯＰ）：このビットが１の場合、１６ビットの「Ｏｆｆｓｅｔ」フィールドが、「Ｂｉｔ Ｆｉｅｌｄ ２」の直後に挿入される。「Ｏｆｆｓｅｔ」フィールドは、現在のペイロードの末尾を見つけるために使用される。「Ｂｉｔ Ｆｉｅｌｄ ２」から始まる他のＭＰＦヘッダは、現在のペイロードの末尾の後に続きうる。「Ｏｆｆｓｅｔ Ｐｒｅｓｅｎｔ」ビットが０の場合、「Ｏｆｆｓｅｔ」フィールドは存在せず、ＭＰＦがＲＴＰとともに使用される場合、現在のペイロードはトランスポートパケットの末尾まで、またはＲＴＰヘッダ内の「Ｐａｄｄｉｎｇ」ビットが１の場合にＲＴＰパディング領域の始めまで伸びる。
【００７５】
「Ｓｙｎｃ Ｐｏｉｎｔ」ビット（Ｓ）：このビットは、ＭＡＵが同期点ＭＡＵの場合に１に設定される。「Ｄｉｓｃｏｎｔｉｎｕｉｔｙ」ビット（Ｄ１）：このビットは１に設定され、トランスポートパケットのシーケンス番号（例えば、ＲＴＰが使用されている場合に、ＲＴＰシーケンス番号）が「ギャップ」を示していないとしても、１つまたは複数のＭＡＵが欠落していることを示す。「Ｄｒｏｐｐａｂｌｅ」ビット（Ｄ２）：このビットが１であり、いくつかのＭＡＵを落とす必要がある場合、このＭＡＵは、Ｄ２ビットが０に設定されているＭＡＵほどマイナスの影響を及ぼすことなく落とすことができる。「Ｅｎｃｒｙｐｔｉｏｎ」ビット（Ｅ）：このビットは１に設定され、ペイロードが暗号化されたデータを含むことを示す。このビットは、ペイロードが暗号化されたデータを含まない場合に０に設定されなければならない。「Ｂｉｔ Ｆｉｅｌｄ ３ Ｐｒｅｓｅｎｔ」（Ｂ３Ｐ）ビット：このビットが１の場合、１バイトの「Ｂｉｔ Ｆｉｅｌｄ ３」フィールドが、「Ｌｅｎｇｔｈ」フィールドの後に挿入される。「Ｏｆｆｓｅｔ」：「Ｏｆｆｓｅｔ」フィールドの後に続く最初のバイトから数えた、現在のペイロードの終わりまで、バイト数でオフセットを指定する１６ビットフィールド。言い換えると、「Ｏｆｆｓｅｔ」フィールドの値は、もしあれば「ＭＡＵ Ｔｉｍｉｎｇ」セクションのサイズに、現在のペイロードのサイズを加えた値である。
【００７６】
「Ｂｉｔ Ｆｉｅｌｄ ２」の「Ｂ３Ｐ」ビットの値は、「Ｂｉｔ Ｆｉｅｌｄ ３」が存在するかどうかを判定する。「Ｂｉｔ Ｆｉｅｌｄ ３」のすべてのビットに対するデフォルト値は、０である。図１２は、ＭＰＦのビットフィールド３の例示的なレイアウトを示す。「Ｄｅｃｏｄｅ Ｔｉｍｅ Ｐｒｅｓｅｎｔ」ビット（Ｄ３）：このビットが１の場合、３２ビット「Ｄｅｃｏｄｅ Ｔｉｍｅ」フィールドが、「Ｂｉｔ Ｆｉｅｌｄ ３」の後から、「Ｐｒｅｓｅｎｔａｔｉｏｎ Ｔｉｍｅ」フィールドの前までの間に挿入される。「Ｐｒｅｓｅｎｔａｔｉｏｎ Ｔｉｍｅ Ｐｒｅｓｅｎｔ」ビット（Ｐ）：このビットが１の場合、３２ビット「Ｐｒｅｓｅｎｔａｔｉｏｎ Ｔｉｍｅ」フィールドが、「Ｄｅｃｏｄｅ Ｔｉｍｅ」の後から、「ＮＰＴ」フィールドの前までの間に挿入される。「ＮＰＴ Ｐｒｅｓｅｎｔ」ビット（Ｎ）：このビットが１の場合、６４ビットの「ＮＰＴ」フィールドが、「Ｐｒｅｓｅｎｔａｔｉｏｎ Ｔｉｍｅ」フィールドの直後に挿入される。Ｒ６、Ｒ７、Ｒ８、Ｒ９：１に設定されているこれらのビットのそれぞれについて、受信機側では、３２ビットフィールドが「ＮＰＴ」フィールドと「Ｅｘｔｅｎｓｉｏｎ」との間に追加されていると想定する。これらの３２ビットフィールドの意味は、本明細書では定義されていない。３２ビットフィールドの意味を認識しない受信機は、それらを無視する。
【００７７】
「Ｅｘｔｅｎｓｉｏｎ Ｐｒｅｓｅｎｔ」ビット（Ｘ）：このビットが１の場合、可変サイズ「Ｅｘｔｅｎｓｉｏｎ」フィールドが、「ＮＰＴ」フィールドの後に挿入される。「Ｄｅｃｏｄｅ Ｔｉｍｅ」：３２ビットフィールド。このフィールドで、ＭＡＵの復号化時間を指定する。ＲＴＰが使用される場合、このフィールドで、ＲＴＰヘッダ内の「Ｔｉｍｅｓｔａｍｐ」フィールドに使用されるのと同じ時間単位を使用して、ＭＡＵの復号化時間を指定する。「Ｐｒｅｓｅｎｔａｔｉｏｎ Ｔｉｍｅ」：３２ビットフィールド。このフィールドで、ＭＡＵのプレゼンテーション時間を指定する。「ＮＰＴ」フィールド：６４ビットタイムスタンプ。「ＮＰＴ」フィールドでは、ＭＡＵが属する通常再生時間時系列内の位置を指定する。
【００７８】
図１３は、一実施形態による、ＭＰＦヘッダの拡張フィールドの例示的レイアウトを示している。「Ｅｘｔｅｎｓｉｏｎ」フィールドは、フィールドの１つまたは複数の集まりを含む。図１３は、そのような１つの集まりに含まれるフィールドのレイアウトを例示している。「Ｌ」ビット：このビットが１の場合、これは、「Ｅｘｔｅｎｓｉｏｎ」ビットの最後の集まりである。このビットが０の場合、「Ｅｘｔｅｎｓｉｏｎ Ｄａｔａ」フィールドの末尾の後に、「Ｅｘｔｅｎｓｉｏｎ」フィールドの少なくとももう１つの集まりが続く。
【００７９】
「Ｅｘｔｅｎｓｉｏｎ Ｔｙｐｅ」：「Ｅｘｔｅｎｓｉｏｎ Ｄａｔａ」フィールドの内容を識別するために使用される７ビットフィールド。それに加えて、値０と１２７は、将来使用するために予約されている。「Ｅｘｔｅｎｓｉｏｎ Ｌｅｎｇｔｈ」：このフィールドの直後に出現する「Ｅｘｔｅｎｓｉｏｎ Ｄａｔａ」フィールドのバイト数によるサイズを示す８ビットの数値。「Ｅｘｔｅｎｓｉｏｎ Ｄａｔａ」：可変長フィールド。このフィールドのサイズは、「Ｅｘｔｅｎｓｉｏｎ Ｌｅｎｇｔｈ」フィールドにより与えられる。
【００８０】
「Ｅｘｔｅｎｓｉｏｎ」フィールド内のフィールドは、初期化ベクトル拡張が使用される場合に以下の値を有する。
● 「Ｅｘｔｅｎｓｉｏｎ Ｔｙｐｅ」：２である。
● 「Ｅｘｔｅｎｓｉｏｎ Ｌｅｎｇｔｈ」：バイト数による「Ｅｘｔｅｎｓｉｏｎ Ｄａｔａ」フィールドのサイズ。
● 「Ｅｘｔｅｎｓｉｏｎ Ｄａｔａ」：現在のＭＡＵに対する初期化ベクトルの一部として使用される、１つまたは複数のバイトのシーケンス。この拡張が存在する場合、暗号化ユニットは、完全なＭＡＵである。ＭＡＵが複数のペイロードに断片化される場合、初期化ベクトル拡張は、第１のペイロード内にのみ存在する。
【００８１】
「Ｅｘｔｅｎｓｉｏｎ」フィールド内のフィールドは、キーＩＤ拡張が使用される場合に以下の値を有する。
● 「Ｅｘｔｅｎｓｉｏｎ Ｔｙｐｅ」：３である。
● 「Ｅｘｔｅｎｓｉｏｎ Ｌｅｎｇｔｈ」：バイト数による「Ｅｘｔｅｎｓｉｏｎ Ｄａｔａ」フィールドのサイズ。
● 「Ｅｘｔｅｎｓｉｏｎ Ｄａｔａ」：現在のペイロードを復号化するために使用する復号化キーを識別する、１つまたは複数のバイトのシーケンス。
【００８２】
キーＩＤ拡張は、異なるキーＩＤ拡張により置き換えられるまで有効である。したがって、この拡張は、前のペイロードの復号化キーと異なる復号化キーの使用をペイロードが必要とする場合にのみ使用される。しかし、前のペイロードが失われたトランスポートパケット内に含まれていた場合、受信機は、復号化キーの変更が必要であることを認識しない場合がある。ペイロードが誤ったキーで復号化され、この状況が検出されない場合、望ましくないレンダリングアーチファクトが生じる可能性がある。
【００８３】
このような問題の重大さを軽減するアプローチの１つは、同期点であるすべてのＭＡＵの第１のペイロードに対しキーＩＤ拡張を指定することである。これは、ＭＡＵが失われることで、受信機が次の同期点ＭＡＵを受け取るまですべてのＭＡＵを強制的に破棄することが知られている場合にはよい解決策である。より控え目な解決策は、それぞれの複数ペイロードトランスポートにおける第１のペイロードに対しキーＩＤ拡張を指定することである。この解決策は、パケット喪失に対しロバストであるが、それは、相互依存ペイロードが、すべて、単一のトランスポートパケット内に含まれるからである。
【００８４】
ＭＰＥＧビデオヘッダが存在する場合、それらは、後続フレームの前に来る。特に、
● ＭＰＥＧ Ｖｉｄｅｏ＿Ｓｅｑｕｅｎｃｅ＿Ｈｅａｄｅｒは、存在する場合、ＭＡＵの先頭にある。
● ＭＰＥＧ ＧＯＰ＿ｈｅａｄｅｒは、存在する場合、ＭＡＵの先頭にあるか、またはＶｉｄｅｏ＿Ｓｅｑｕｅｎｃｅ＿Ｈｅａｄｅｒの後に続く。
● ＭＰＥＧ Ｐｉｃｔｕｒｅ＿Ｈｅａｄｅｒは、存在する場合、ＭＡＵの先頭にあるか、またはＧＯＰ＿ｈｅａｄｅｒの後に続く。
ＲＦＣ ２２５０とは異なり、ビデオを含むＭＡＵが断片化された場合、スライス境界で断片化を実行する必要はない。
【００８５】
ＭＡＵは、さまざまな理由から複数のトランスポートパケットにまたがって断片化される可能性がある。例えば、ＭＡＵは、トランスポートパケットサイズの制限が存在し、ＭＡＵの特定の部分に対する暗号化パラメータに違いがある場合に断片化される可能性がある。ＲＴＰヘッダフィールドが解釈される場合、ＲＴＰヘッダ内の「Ｔｉｍｅｓｔａｍｐ」フィールドは、９０ｋＨｚの精度でサンプルのＰＴＳに設定され、「Ｐａｙｌｏａｄ Ｔｙｐｅ（ＰＴ）」フィールドは、帯域外ネゴシエーション機構に従って（例えば、ＳＤＰを使用して）設定される。ＭＰＦ、パケット指定情報セクションに関して、「Ｓｅｎｄ Ｔｉｍｅ」フィールドの存在はオプションであり、「Ｃｏｒｒｅｓｐｏｎｄｅｎｃｅ」フィールドの存在はオプションであり、「Ｂｉｔ Ｆｉｅｌｄ ２ Ｐｒｅｓｅｎｔ」ビット（Ｂ２Ｐ）は、ペイロードが、暗号化されたＭＡＵの一部、または暗号化されたＭＡＵのフラグメントを含む場合に設定される。
【００８６】
上記に照らして、ＭＰＦにより、異なる暗号化パラメータに従って単一のＭＡＵを暗号化することができる。これは、暗号化された単一のＭＡＵのフラグメントを備え、他を平文中に残す機能を備える。このような場合、ＭＡＵは、複数のペイロードに断片化することができ、それぞれ異なる暗号化パラメータを有する。例えば、暗号化されたＭＡＵまたはＭＡＵのフラグメントは、以下の基準に従って値およびフィールドを設定される。
● Ｐａｃｋｅｔ Ｉｎｆｏセクション内の「Ｂｉｔ Ｆｉｅｌｄ ２ Ｐｒｅｓｅｎｔ」ビット（Ｂ２Ｐ）は、１に設定され、「Ｂｉｔ Ｆｉｅｌｄ ２」が存在することを示す。
● ＭＡＵ Ｐｒｏｐｅｒｔｉｅｓセクション内の「Ｅｎｃｒｙｐｔｉｏｎ」ビット（Ｅ）は、１に設定され、ペイロードが暗号化されることを示す。
● 「ＭＡＵ Ｔｉｍｉｎｇ」セクション内の「Ｅｘｔｅｎｓｉｏｎ Ｐｒｅｓｅｎｔ」ビット（Ｘ）は、１に設定され、拡張フィールドが存在することを示す。
● 「Ｉｎｉｔｉａｌｉｚａｔｉｏｎ Ｖｅｃｔｏｒ」拡張が含まれる。以下の値が設定される。
【００８７】
○ 「Ｅｘｔｅｎｓｉｏｎ Ｔｙｐｅ」は２に設定される。
○ 「Ｅｘｔｅｎｓｉｏｎ Ｌｅｎｇｔｈ」は、「Ｅｘｔｅｎｓｉｏｎ Ｄａｔａ」フィールドがデータセグメントＩＤのみを含む場合に８（６４ビットを意味する）に、「Ｅｘｔｅｎｓｉｏｎ Ｄａｔａ」フィールドがデータセグメントＩＤとブロックＩＤの両方を含む場合に１６ （１２８ビットを意味する）に設定される。
【００８８】
○ 「Ｅｘｔｅｎｓｉｏｎ Ｄａｔａ」は、初期ブロックＩＤが０の場合に上述のようなデータセグメントＩＤ値で設定される。初期ブロックＩＤが０と異なる場合に、「Ｅｘｔｅｎｓｉｏｎ Ｄａｔａ」は、初期ブロックＩＤが後に続くデータセグメントＩＤに設定される。
【００８９】
○ この拡張は、ＭＡＵのそれぞれの暗号化されたペイロードに関して含まれる。
● 「Ｋｅｙ ＩＤ」拡張が含まれる。以下の値が設定される。
○ 「Ｅｘｔｅｎｓｉｏｎ Ｔｙｐｅ」は３に設定される。
【００９０】
○ 「Ｅｘｔｅｎｓｉｏｎ Ｌｅｎｇｔｈ」は１６（１２８ビットを意味する）に設定される。
○ 「Ｅｘｔｅｎｓｉｏｎ Ｄａｔａ」は、このＭＡＵに対応するライセンスから得たキーＩＤ値で設定される。
● 「Ｉｎｉｔｉａｌｉｚａｔｉｏｎ Ｖｅｃｔｏｒ」および「Ｋｅｙ ＩＤ」拡張は、複数のＭＡＵを含むそれぞれの複数ペイロードトランスポートパケット内の新しいＭＡＵの第１のペイロードについて含まれる。これにより、受信機は、いくつかのトランスポートパケットが失われた場合でも、現在のキーＩＤについて認識することが保証される。
【００９１】
ＭＡＵ Ｐｒｏｐｅｒｔｉｅｓセクションは、以下のように解釈される。
● 「Ｓｙｎｃ Ｐｏｉｎｔ」ビット（Ｓ）は、ＭＡＵがビデオＩ−フレームまたはオーディオフレームを含む場合にセットされる。
● 「Ｄｉｓｃｏｎｔｉｎｕｉｔｙ」ビット（Ｄｌ）は、１つまたは複数のＭＡＵが欠損している場合にセットされる。例えば、ビデオフレームが、フレームドロップトランスレータにより落とされた場合。
● 「Ｄｒｏｐｐａｂｌｅ」ビット（Ｄ２）の利用はオプションである。それが使用されるべき場合の定義は、本明細書の範囲を外れている。
● 「Ｅｎｃｒｙｐｔｉｏｎ」ビット（Ｅ）は、ペイロードが、暗号化されたＭＡＵの一部、または暗号されたＭＡＵのフラグメントを含む場合にセットされる。
【００９２】
ＭＡＵ Ｔｉｍｉｎｇセクションは、以下のように解釈される。
● 「Ｄｅｃｏｄｅ Ｔｉｍｅ」フィールドは、オプションである。使用される場合、ＭＡＵのＤＴＳを含む。
● 「Ｐｒｅｓｅｎｔａｔｉｏｎ Ｔｉｍｅ」フィールドは、オプションである。
● 「ＮＰＴ」フィールドは、オプションである。
【００９３】
○ 「Ｅｘｔｅｎｓｉｏｎ Ｐｒｅｓｅｎｔ」ビット（Ｘ）は、１つまたは複数の拡張ヘッダが存在する場合にセットされる。
例示的な手順
図１４は、一実施形態により、ＥＳコンテンツを保護する例示的な手順１４００を示している。例示することを目的として、図１のＥＳ保護モジュール１１２、マッピングモジュール１１４、図２のトランスポートストリームスクランブルモジュール２１０、および／または逆多重化およびパッケージ化モジュール２１２のうちの１つまたは複数により手順１４００のオペレーションが実行される。アクションの順序の変更および修正を含む、さまざまな変更および修正は、当業者にとっては、本明細書の説明から明らかであろう。
【００９４】
図１４を参照すると、ブロック１４０５において、エレメンタリストリーム（ＥＳ）は、コンピューティングデバイス１０２またはコンテンツソース２０２により受信されるか、または他の何らかの方法でアクセスされる。アクセスされたＥＳは、トランスポートストリームと無関係であるか、またはトランスポートストリームにより配送することができる。ブロック１４１０における手順１４００で、ＥＳのＭＡＵ部分を保護する。一実装では、これらの保護オペレーションは、共通スクランブルとは無関係に実行される。他の実装では、これらの保護オペレーションは、例えば、トランスポートストリームを共通スクランブルした場合に、共通スクランブルを使用して実行される。ブロック１４１５において、トランスポートストリームがブロック１４０５でアクセスされた場合、元の暗号化が保持されるようにトランスポートストリームがＥＳに逆多重化される。モジュール２１２の逆多重化オペレーションは、トランスポートストリーム逆多重化オペレーションを実行する例示的なコンポーネントを示している。
【００９５】
ブロック１４２０における手順１４００で、保護されているＥＳがＭＡＵペイロードフォーマット（ＭＰＦ）にマッピングされる。それぞれのＭＡＵをＭＰＦにマッピングすることで、メディアコンシューマが他のＥＳと無関係にそれぞれのＥＳを処理し、他のＭＡＵとは無関係にそれぞれのＭＡＵを処理するのに十分な情報が、マッピングされたＥＳをカプセル化するトランスポートパケットを受け取るメディアコンシューマに与えられる。ブロック１４３０における手順１４００で、ＭＰＦにマッピングされたＥＳがトランスポートプロトコルにカプセル化される。一実装では、トランスポートプロトコルは、リアルタイム転送プロトコル（ＲＴＰ）である。ブロック１４４０における手順１４００で、トランスポートプロトコルに基づくトランスポートパケットをメディアコンシューマに伝達し、処理する。復号化を含む、このような処理により、メディアコンシューマは、トランスポートパケットに含まれるペイロードデータを受け取ることができる。
結論
ＥＳコンテンツを保護することは構造的特徴および／または方法論的なオペレーションまたはアクションに固有の言語で説明されているが、付属の請求項で定められている実装は、説明された特定の特徴またはアクションに必ずしも限られないことは理解されるであろう。むしろ、特定の特徴およびオペレーションは請求されている主題を実施するための複数の実施形態の例として開示されている。
【図面の簡単な説明】
【００９６】
【図１】一実施形態による、ＥＳコンテンツを保護する例示的なコンピューティングシステムを示す図である。
【図２】一実施形態による、トランスポートストリームにより配送されるＥＳコンテンツを保護する例示的な実施形態を実装することができる例示的なネットワーク接続環境を示す図である。
【図３】カウンタモードで高度暗号化標準を使用してＥＳメディアコンテンツを暗号化するオペレーションの例示的な態様を示す図である。
【図４】一実施形態による、保護されたＥＳコンテンツとともにトランスポートストリーム内に挿入する例示的な暗号方式（ＴＡＧ）パケットを示す図である。
【図５】一実施形態による、送信機側でトランスポートストリーム内のＥＳを保護する例示的な手順を示す図である。
【図６】一実施形態による、例示的な共通スクランブルされたトランスポートストリームを示す図である。
【図７】一実施形態による、メディアアクセスユニット（ＭＡＵ）ペイロードフォーマット（ＭＰＦ）ヘッダの例示的な高水準構造を例示する図である。
【図８】一実施形態による、図７のＭＰＦヘッダの例示的な詳細を示す図である。
【図９】一実施形態による、ＭＰＦを使用する３つのリアルタイムトランスポートパケット（ＲＴＰ）パケットの例示的なシーケンスを示す図である。
【図１０】一実施形態による、単一のメディアアクセスユニット（ＭＡＵ）が同じＲＴＰパケット内の３つのフラグメントに分割されている一実施例を示す図である。
【図１１】標準的な１２バイトＲＴＰヘッダを例示する図である。
【図１２】ＭＰＦのビットフィールド３の例示的なレイアウトを示す図である。
【図１３】一実施形態による、ＭＰＦヘッダの拡張フィールドの例示的なレイアウトを示す図である。
【図１４】一実施形態による、ＥＳコンテンツを保護する例示的な手順を示す図である。
【特許請求の範囲】
【請求項１】
コンピュータに実装される方法であって、
エレメンタリストリームコンテンツのメディアアクセスユニット（ＭＡＵ）を識別するステップと、
単一のビデオまたはオーディオフレームを表す１つまたは複数のデータセグメントを含む前記複数のＭＡＵのうちのそれぞれのＭＡＵ毎に、
前記単一のビデオまたはオーディオフレームおよび関連するヘッダの保護のため前記１つまたは複数のデータセグメントに基づいて暗号境界を選択するステップと、
前記ＭＡＵを保護するステップを含み、保護するステップは、
前記暗号境界に基づいて前記ＭＡＵの一部を暗号化するステップと、
前記ＭＡＵを、ＭＡＵペイロードフォーマットにマッピングするステップとを含み、
前記ＭＡＵペイロードフォーマットは、前記エレメンタリストリームの異なるどの１つとも無関係に前記エレメンタリストリーム処理を規定し、また他のどのＭＡＵとも無関係に前記ＭＡＵの処理を規定する方法。
【請求項２】
前記エレメンタリストリームコンテンツは、トランスポートストリームにより配送され、保護するステップは、さらに、前記複数のＭＡＵのうちの１つのＭＡＵを構成するデータセグメントのそれぞれが、完全に暗号化されているか、またはまったく暗号化されていないかのいずれかであるように前記トランスポートストリームを共通スクランブルするステップを含む請求項１に記載の方法。
【請求項３】
保護するステップは、さらに、カウンタモードの高度暗号化標準により前記１つまたは複数のデータセグメントのうちの別々のセグメントを暗号化するステップを含む請求項１に記載の方法。
【請求項４】
前記ＭＡＵの一部は、平文中に残される請求項１に記載の方法。
【請求項５】
前記ＭＡＵをマッピングするステップは、さらに、複数のトランスポートプロトコルペイロードにまたがって前記ＭＡＵを断片化するステップを含む請求項１に記載の方法。
【請求項６】
前記ＭＡＵをマッピングするステップは、さらに、単一トランスポートプロトコルパケット内の前記ＭＡＵについて複数のペイロードを関連付けるステップを含む請求項１に記載の方法。
【請求項７】
さらに、
単一のトランスポートプロトコルパケット内の前記ＭＡＵに対する複数のペイロードを関連付けるステップを含み、
前記複数のペイロードのうちの２つまたはそれ以上が、異なるそれぞれの暗号化パラメータを有する請求項１に記載の方法。
【請求項８】
前記ＭＡＵペイロードフォーマットは、トランスポートプロトコルパケット内のすべてのＭＡＵに関連付けられているパケット固有の情報を含む請求項１に記載の方法。
【請求項９】
前記ＭＡＵペイロードフォーマットは、
特定のＭＡＵを記述するためのＭＡＵ ｐｒｏｐｅｒｔｉｅｓセクションと、
前記ＭＡＵが断片化された場合に、前記ＭＡＵの断片化された部分が失われたときに受信機側で前記ＭＡＵを解析するのに使用できる情報を含む前記プロパティセクションとを含む請求項１に記載の方法。
【請求項１０】
前記ＭＡＵペイロードフォーマットは、前記ＭＡＵに関連付けられているタイムスタンプに関する情報を提供するＭＡＵ ｔｉｍｉｎｇセクションを含む請求項１に記載の方法。
【請求項１１】
前記情報は、受信機により、プレゼンテーション内でシークする位置指定を補助するための、前記ＭＡＵに関連付けられている通常再生時間（ＮＰＴ）時系列を含む請求項１０に記載の方法。
【請求項１２】
前記情報は、前記ＭＡＵのコンテンツを前記受信機が提示する時期を指示するプレゼンテーション時間を含む請求項１０に記載の方法。
【請求項１３】
前記プレゼンテーション時間は、トリックプレイが使用されることを意識せずに復号器が前記ＭＡＵを復号化できるリアルタイム速度でインクリメントする請求項１２に記載の方法。
【請求項１４】
保護するステップは、さらに、
トランスポートストリームを分析して、暗号化されずに通る前記トランスポートストリームの部分を決定するステップを含み、
保護するステップは、さらに、前記トランスポートストリームの共通スクランブルされた部分をバイパスする処理を行うように前記トランスポートストリームを準備するステップを含む請求項１に記載の方法。
【請求項１５】
コンピュータに実装される方法であって、
エレメンタリストリームを受信し、それぞれのエレメンタリストリーム（ＥＳ）は複数のメディアアクセスユニット（ＭＡＵ）で表され、それぞれのＭＡＵは前記ＥＳのビデオまたはオーディオの単一フレームに対応し、それぞれのエレメンタリストリームはＭＡＵペイロードフォーマット（ＭＰＦ）をカプセル化するトランスポートプロトコルにマッピングされるステップと、
前記トランスポートストリームを処理し、前記ＭＰＦによりそれぞれのＥＳは他のどのＥＳとも無関係に処理することができ、それぞれのＭＡＵを他のどのＭＡＵとも無関係に処理することができるステップとを含む方法。
【請求項１６】
前記トランスポートプロトコルは、リアルタイム転送プロトコル（ＲＴＰ）である請求項１５に記載の方法。
【請求項１７】
前記複数のＭＡＵのうちの１つのＭＡＵの一部は、平文中に残される請求項１５に記載の方法。
【請求項１８】
前記複数のＭＡＵのうちの１つのＭＡＵが、複数のトランスポートプロトコルペイロードにまたがって断片化されるか、または前記ＭＡＵに対する複数のペイロードが、単一のトランスポートプロトコルパケット内にある請求項１５に記載の方法。
【請求項１９】
前記複数のペイロードのうちの２つまたはそれ以上が、異なるそれぞれの暗号化パラメータを有する請求項１８に記載の方法。
【請求項２０】
コンピューティングデバイスであって、
エレメンタリストリームコンテンツのメディアアクセスユニット（ＭＡＵ）を識別する識別手段と、
単一のビデオまたはオーディオフレームを表す１つまたは複数のデータセグメントを含む前記複数のＭＡＵのうちのそれぞれのＭＡＵ毎に、
前記単一のビデオまたはオーディオフレームおよび関連するヘッダの保護のため前記１つまたは複数のデータセグメントに基づいて暗号境界を選択する選択手段と、
前記ＭＡＵを保護する保護手段とを含み、保護手段は、
前記暗号境界に基づいて前記ＭＡＵの一部を暗号化する暗号化手段と、
前記ＭＡＵを、ＭＡＵペイロードフォーマットにマッピングするマッピング手段とを含み、
前記ＭＡＵペイロードフォーマットは、前記エレメンタリストリームの異なるどの１つとも無関係に前記エレメンタリストリーム処理を規定し、また他のどのＭＡＵとも無関係に前記ＭＡＵの処理を規定するコンピューティングデバイス。
【請求項１】
コンピュータに実装される方法であって、
エレメンタリストリームコンテンツのメディアアクセスユニット（ＭＡＵ）を識別するステップと、
単一のビデオまたはオーディオフレームを表す１つまたは複数のデータセグメントを含む前記複数のＭＡＵのうちのそれぞれのＭＡＵ毎に、
前記単一のビデオまたはオーディオフレームおよび関連するヘッダの保護のため前記１つまたは複数のデータセグメントに基づいて暗号境界を選択するステップと、
前記ＭＡＵを保護するステップを含み、保護するステップは、
前記暗号境界に基づいて前記ＭＡＵの一部を暗号化するステップと、
前記ＭＡＵを、ＭＡＵペイロードフォーマットにマッピングするステップとを含み、
前記ＭＡＵペイロードフォーマットは、前記エレメンタリストリームの異なるどの１つとも無関係に前記エレメンタリストリーム処理を規定し、また他のどのＭＡＵとも無関係に前記ＭＡＵの処理を規定する方法。
【請求項２】
前記エレメンタリストリームコンテンツは、トランスポートストリームにより配送され、保護するステップは、さらに、前記複数のＭＡＵのうちの１つのＭＡＵを構成するデータセグメントのそれぞれが、完全に暗号化されているか、またはまったく暗号化されていないかのいずれかであるように前記トランスポートストリームを共通スクランブルするステップを含む請求項１に記載の方法。
【請求項３】
保護するステップは、さらに、カウンタモードの高度暗号化標準により前記１つまたは複数のデータセグメントのうちの別々のセグメントを暗号化するステップを含む請求項１に記載の方法。
【請求項４】
前記ＭＡＵの一部は、平文中に残される請求項１に記載の方法。
【請求項５】
前記ＭＡＵをマッピングするステップは、さらに、複数のトランスポートプロトコルペイロードにまたがって前記ＭＡＵを断片化するステップを含む請求項１に記載の方法。
【請求項６】
前記ＭＡＵをマッピングするステップは、さらに、単一トランスポートプロトコルパケット内の前記ＭＡＵについて複数のペイロードを関連付けるステップを含む請求項１に記載の方法。
【請求項７】
さらに、
単一のトランスポートプロトコルパケット内の前記ＭＡＵに対する複数のペイロードを関連付けるステップを含み、
前記複数のペイロードのうちの２つまたはそれ以上が、異なるそれぞれの暗号化パラメータを有する請求項１に記載の方法。
【請求項８】
前記ＭＡＵペイロードフォーマットは、トランスポートプロトコルパケット内のすべてのＭＡＵに関連付けられているパケット固有の情報を含む請求項１に記載の方法。
【請求項９】
前記ＭＡＵペイロードフォーマットは、
特定のＭＡＵを記述するためのＭＡＵ ｐｒｏｐｅｒｔｉｅｓセクションと、
前記ＭＡＵが断片化された場合に、前記ＭＡＵの断片化された部分が失われたときに受信機側で前記ＭＡＵを解析するのに使用できる情報を含む前記プロパティセクションとを含む請求項１に記載の方法。
【請求項１０】
前記ＭＡＵペイロードフォーマットは、前記ＭＡＵに関連付けられているタイムスタンプに関する情報を提供するＭＡＵ ｔｉｍｉｎｇセクションを含む請求項１に記載の方法。
【請求項１１】
前記情報は、受信機により、プレゼンテーション内でシークする位置指定を補助するための、前記ＭＡＵに関連付けられている通常再生時間（ＮＰＴ）時系列を含む請求項１０に記載の方法。
【請求項１２】
前記情報は、前記ＭＡＵのコンテンツを前記受信機が提示する時期を指示するプレゼンテーション時間を含む請求項１０に記載の方法。
【請求項１３】
前記プレゼンテーション時間は、トリックプレイが使用されることを意識せずに復号器が前記ＭＡＵを復号化できるリアルタイム速度でインクリメントする請求項１２に記載の方法。
【請求項１４】
保護するステップは、さらに、
トランスポートストリームを分析して、暗号化されずに通る前記トランスポートストリームの部分を決定するステップを含み、
保護するステップは、さらに、前記トランスポートストリームの共通スクランブルされた部分をバイパスする処理を行うように前記トランスポートストリームを準備するステップを含む請求項１に記載の方法。
【請求項１５】
コンピュータに実装される方法であって、
エレメンタリストリームを受信し、それぞれのエレメンタリストリーム（ＥＳ）は複数のメディアアクセスユニット（ＭＡＵ）で表され、それぞれのＭＡＵは前記ＥＳのビデオまたはオーディオの単一フレームに対応し、それぞれのエレメンタリストリームはＭＡＵペイロードフォーマット（ＭＰＦ）をカプセル化するトランスポートプロトコルにマッピングされるステップと、
前記トランスポートストリームを処理し、前記ＭＰＦによりそれぞれのＥＳは他のどのＥＳとも無関係に処理することができ、それぞれのＭＡＵを他のどのＭＡＵとも無関係に処理することができるステップとを含む方法。
【請求項１６】
前記トランスポートプロトコルは、リアルタイム転送プロトコル（ＲＴＰ）である請求項１５に記載の方法。
【請求項１７】
前記複数のＭＡＵのうちの１つのＭＡＵの一部は、平文中に残される請求項１５に記載の方法。
【請求項１８】
前記複数のＭＡＵのうちの１つのＭＡＵが、複数のトランスポートプロトコルペイロードにまたがって断片化されるか、または前記ＭＡＵに対する複数のペイロードが、単一のトランスポートプロトコルパケット内にある請求項１５に記載の方法。
【請求項１９】
前記複数のペイロードのうちの２つまたはそれ以上が、異なるそれぞれの暗号化パラメータを有する請求項１８に記載の方法。
【請求項２０】
コンピューティングデバイスであって、
エレメンタリストリームコンテンツのメディアアクセスユニット（ＭＡＵ）を識別する識別手段と、
単一のビデオまたはオーディオフレームを表す１つまたは複数のデータセグメントを含む前記複数のＭＡＵのうちのそれぞれのＭＡＵ毎に、
前記単一のビデオまたはオーディオフレームおよび関連するヘッダの保護のため前記１つまたは複数のデータセグメントに基づいて暗号境界を選択する選択手段と、
前記ＭＡＵを保護する保護手段とを含み、保護手段は、
前記暗号境界に基づいて前記ＭＡＵの一部を暗号化する暗号化手段と、
前記ＭＡＵを、ＭＡＵペイロードフォーマットにマッピングするマッピング手段とを含み、
前記ＭＡＵペイロードフォーマットは、前記エレメンタリストリームの異なるどの１つとも無関係に前記エレメンタリストリーム処理を規定し、また他のどのＭＡＵとも無関係に前記ＭＡＵの処理を規定するコンピューティングデバイス。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【公表番号】特表２００９−５０５５１６（Ｐ２００９−５０５５１６Ａ）
【公表日】平成２１年２月５日（２００９．２．５）
【国際特許分類】
【出願番号】特願２００８−５２６２６７（Ｐ２００８−５２６２６７）
【出願日】平成１８年８月１０日（２００６．８．１０）
【国際出願番号】ＰＣＴ／ＵＳ２００６／０３１５５６
【国際公開番号】ＷＯ２００７／０２２０３８
【国際公開日】平成１９年２月２２日（２００７．２．２２）
【出願人】（５０００４６４３８）マイクロソフト コーポレーション (3,165)
【Ｆターム（参考）】
【公表日】平成２１年２月５日（２００９．２．５）
【国際特許分類】
【出願日】平成１８年８月１０日（２００６．８．１０）
【国際出願番号】ＰＣＴ／ＵＳ２００６／０３１５５６
【国際公開番号】ＷＯ２００７／０２２０３８
【国際公開日】平成１９年２月２２日（２００７．２．２２）
【出願人】（５０００４６４３８）マイクロソフト コーポレーション (3,165)
【Ｆターム（参考）】
[ Back to top ]