(57)【要約】  基本ストリーム・メディア・コンテンツの保護が記述される。１つの態様において、基本ストリーム・メディア・コンテンツ内のデータ・セグメントが識別される。各データ・セグメントは単一のビデオ又はオーディオ・フレームを含む。ペイロード・パケットを保護するための暗号化境界が、データ・セグメント境界に対応するよう選択される。次いで、基本ストリーム・メディア・コンテンツが、選択された暗号化境界を用いて保護される。
2009505515.tif 000002
【特許請求の範囲】
【請求項１】
コンピュータにより実施する方法であって、
基本ストリーム・コンテンツのデータ・セグメントであって単一のビデオ・フレーム又はオーディオ・フレームを含むデータ・セグメントを識別するステップと、
前記基本ストリーム・コンテンツの保護のために、前記データ・セグメントに対応する暗号化境界を選択するステップと、
前記暗号化境界を用いて前記基本ストリーム・コンテンツを保護するステップと、
を備える方法。
【請求項２】
前記基本ストリーム・コンテンツがトランスポート・ストリームによって運ばれる、請求項１に記載の方法。
【請求項３】
保護する前記ステップが、カウンタ・モードでの改良型暗号化標準により前記データ・セグメントのそれぞれを暗号化するステップを更に含む、請求項１に記載の方法。
【請求項４】
保護する前記ステップが、トランスポート・ストリームを分析して、前記トランスポート・ストリームのうち暗号化されずに通過すべき部分を決定するステップを更に含み、
保護する前記ステップが、前記トランスポート・ストリームの共通にスクランブリングされた部分を迂回する処理のために前記トランスポート・ストリームを用意するステップを更に含む、
請求項１に記載の方法。
【請求項５】
前記基本ストリーム・コンテンツの基本ストリームがメディア・アクセス・ユニット（ＭＡＵ）を含み、
保護する前記ステップが、ＭＡＵ毎に、前記ＭＡＵに関連する１つ以上のデータ・セグメントの各データ・セグメントに対して、それぞれの組の暗号化パラメータを適用するステップを更に含み、
それぞれの組の暗号化パラメータが各個別のデータ・セグメントに適用されるように、それぞれの前記暗号化パラメータが前記データ・セグメントを暗号化し又は明文のままにする、
請求項１に記載の方法。
【請求項６】
前記データ・セグメントが前記ＭＡＵの連続したセクションである、請求項５に記載の方法。
【請求項７】
前記ＭＡＵの一部が明文のままである、請求項５に記載の方法。
【請求項８】
前記トランスポート・プロトコルがリアルタイム・トランスポート・プロトコル（ＲＴＰ）である、請求項５に記載の方法。
【請求項９】
トランスポート・プロトコルへカプセル化するために、前記ＭＡＵをＭＡＵペイロード・フォーマットへマッピングするステップを更に含む、請求項５に記載の方法。
【請求項１０】
前記ＭＡＵペイロード・フォーマットが、それぞれの前記ＭＡＵに関連した、パケット特有情報を含む、請求項９に記載の方法。
【請求項１１】
前記ＭＡＵペイロード・フォーマットが、
前記ＭＡＵのうちの特定のＭＡＵを記述するためのＭＡＵ特性セクションと、
前記ＭＡＵが断片化されるならば、前記ＭＡＵの一部が失われたときに受信側が前記ＭＡＵを構文解析できるようにする情報を含む前記特性セクションと、
を備える、請求項９に記載の方法。
【請求項１２】
前記ＭＡＵペイロード・フォーマットが、前記ＭＡＵのうちのＭＡＵに関連するタイムスタンプに関する情報を提供するＭＡＵタイミング・セクションを備える、請求項９に記載の方法。
【請求項１３】
前記情報が、前記ＭＡＵに関連するノーマル・プレイ時間（ＮＰＴ）タイムラインを含み、該ＮＰＴが、受信機により仕様即ち位置をプレゼンテーション内で探索するのを助ける、請求項１２に記載の方法。
【請求項１４】
前記情報が、前記受信機が前記ＭＡＵのコンテンツを提示するときを示すプレゼンテーション時間を含む、請求項１２に記載の方法。
【請求項１５】
コンピュータによって実施する方法であって、
基本ストリーム（ＥＳ）の暗号化された部分を受信するステップであって、前記ＥＳが複数のメディア・アクセス・ユニット（ＭＡＵ）で表され、各ＭＡＵが前記ＥＳのビデオ又はオーディオの単一のフレームに対応しており、前記ＥＳが、当該ＥＳを他の任意のＥＳから独立に処理できるようにする情報と関連しており、各ＭＡＵが、当該ＭＡＵを他の任意のＭＡＵから独立に処理できるようにする情報と関連しているステップと、
前記ＥＳ又は前記ＭＡＵのうちの少なくとも１つのＭＡＵを処理するステップと、
を備える方法。
【請求項１６】
前記基本ストリームが、共通にスクランブリングされたトランスポート・プロトコルによって運ばれる、請求項１５に記載の方法。
【請求項１７】
前記ＥＳがリアルタイム・トランスポート・プロトコル（ＲＴＰ）によってカプセル化される、請求項１５に記載の方法。
【請求項１８】
前記基本ストリームがトランスポート・ストリームによって運ばれ、
前記処理するステップが、前記トランスポート・ストリームをデマルチプレックスして基本ストリームを導出するステップを含む、
請求項１５に記載の方法。
【請求項１９】
コンピュータにより実施する方法であって、
基本ストリーム・コンテンツのメディア・アクセス・ユニット（ＭＡＵ）を識別するステップと、
前記ＭＡＵのうちの各ＭＡＵ毎に、当該ＭＡＵを、単一のビデオ又はオーディオ・フレームを表す１つ以上のデータ・セグメントで構成し、前記単一のビデオ・フレーム及び関連するヘッダの保護のために１つ以上の前記データ・セグメントに基づいて暗号化境界を選択するステップと、
他のデータ・セグメントの対応する暗号化パラメータから独立であるそれぞれの組の暗号化パラメータに、それぞれの前記データ・セグメントが関連するように、前記暗号化境界に基づいて前記基本ストリーム・コンテンツを保護するステップと、
を備える方法。
【請求項２０】
前記基本ストリーム・コンテンツがトランスポート・ストリームによって運ばれ、
保護する前記ステップが、前記トランスポート・ストリームを共通にスクランブリングして、暗号化されたコンテンツを迂回する処理のために前記トランスポート・ストリームを用意するステップを更に含む、
請求項１９に記載の方法。
【発明の詳細な説明】
【背景技術】
【０００１】
典型的には、メディア・センタは、メディア・コンテンツを運ぶ保護されたトランスポート・ストリームから暗号化を除去し、その後の暗号化のため及びネットワーク接続を介してメディア加入者（例えば消費者やクライアント）に送るためにトランスポート・ストリーム（ＴＳ）を基本ストリーム（ＥＳ）へデマルチプレックスする。メディア・センタによるこうした復号化及び暗号化操作はセキュリティを危うくする。復号されたコンテンツは海賊行為その他のセキュリティ違反を受け易いからである。「メディア・コンテンツ」は「コンテンツ」及び「メディア信号」と同義であり、ビデオ、オーディオ、映画、アニメーション、テキスト等を含む。
【発明の開示】
【発明が解決しようとする課題】
【０００２】
セットトップ・ボックス（ＳＴＢ）、デジタル・メディア受信機（ＤＭＲ）、パーソナル・コンピュータ等のメディア加入者は、典型的には、保護されたメディア・コンテンツをメディア・センタ又はメディア・ソースから受信する。保護されたメディア・コンテンツは、ネットワーク接続を介して送信された又は記憶媒体からダウンロードされた暗号化されたオーディオ／ビデオを含む。暗号化されたメディア・コンテンツを処理（例えば、指標付け）するために、典型的には、メディア加入者はメディア・コンテンツ保護を除去する（例えば、メディア・コンテンツを復号化する）必要がある。典型的には、こうした復号化操作は実質的なデバイス・リソースを消費し、デバイス性能を低減させるので、デバイスの応答性と機能性を低下させる。
【課題を解決するための手段】
【０００３】
この概要は概念の選択を簡単な形で紹介するために提供されるが、これについては以下の詳細な説明において更に詳述される。この概要は、特許請求された主題の重要な特徴又は本質的な特徴を識別することを意図しておらず、特許請求された主題の範囲を決定する助けとして用いられることをも意図していない。
【０００４】
上記に鑑みて、基本ストリーム（ＥＳ）・メディア・コンテンツの保護が記述される。１つの態様において、ＥＳメディア・コンテンツ内のデータ・セグメントが識別される。各データ・セグメントは単一のビデオ又はオーディオ・フレームを含む。ペイロード・パケットを保護するための暗号化境界が、データ・セグメント境界に対応するよう選択される。次いで、選択された暗号化境界を用いてＥＳメディア・コンテンツが保護される。
【０００５】
詳細な説明は、添付図面を参照して記述される。
【発明を実施するための最良の形態】
【０００６】
概観
メディア・コンテンツ特有の特性に基づいて暗号化境界を選択することによってＥＳコンテンツを保護するシステム及び方法が記述される。具体的には、このシステム及び方法は、ＥＳのメディア・アクセス・ユニット（ＭＡＵ）の一部を（例えば，ＭＰＥＧ−２等を用いて）暗号化する。それぞれのＭＡＵは単一のビデオ又はオーディオ・フレーム（基本ストリーム・フレーム）及び関連のヘッダである。ＭＡＵは１つ以上のデータ・セグメントを含む。各データ・セグメントは、コンテンツ暗号化パラメータの同じ組が適用されるＭＡＵの連続したセクションである。データ・セグメントは完全に暗号化されているか、又は完全に明文のままである（すなわち、暗号化されていない）。ＥＳはＴＳから発生してはいないが、こうしたＥＳ保護操作は、ＴＳストリームに適用される共通スクランブリング操作と両立する。
【０００７】
保護されたＥＳコンテンツをＴＳが含むならば、存在する暗号化を保留しながら、ＴＳはＥＳへデマルチプレックスされる（即ち、ＴＳは復号化されない）。ＥＳはＭＡＵペイロード・フォーマット（ＭＰＦ）へマッピングされ、ＰＣやセットトップ・ボックス等のメディア消費者とのその後の通信のために、ＥＳのＭＡＵをトランスポート・プロトコル（例えばリアルタイム・トランスポート・プロトコル（ＲＴＰ））へカプセル化する。それぞれのＭＡＵをＭＰＦへマッピングすると、メディア消費者には、任意の他のＥＳから独立に各ＥＳを処理（例えば、デマルチプレックス、指標付け、記憶等）するための、及び、任意の他のＭＡＵから独立に各ＭＡＵを処理するための十分な情報が提供される。こうした技術は、１つ以上のデータ・セグメントから成るＭＡＵ部分に暗号化を適用することによってＥＳを保護することはしない従来のシステムとは対照的である。
【０００８】
ここで、ＥＳコンテンツを保護するシステム及び方法のこれらの及び他の態様を、図１〜図１４を参照して詳細に説明する。
例示の装置
検討のために、必要ではないけれども、ＥＳコンテンツの保護を、パーソナル・コンピュータのようなコンピュータ装置によって実行されるコンピュータ実行可能命令の一般的な文脈で説明する。一般的に、プログラム・モジュールは、特定のタスクを実行する又は特定の抽象データ・タイプを実施するルーチン、プログラム、オブジェクト、コンポーネント、データ構造等を含む。システム及び方法を前記の文脈で記述するが、以下に記述する動作及び操作はハードウェアにおいても実施され得る。
【０００９】
図１は、ＥＳコンテンツを保護するための例示のシステム１００を示している。システム１００は汎用コンピュータ装置１０２を含む。コンピュータ装置１０２は、パーソナル・コンピュータ、ラップトップ、サーバ、携帯型又は移動型コンピュータ装置等の任意の形式のコンピュータ装置を表す。コンピュータ装置１０２はコンピュータ読み取り可能媒体１０６に結合されたプロセッサ１０４を備える。コンピュータ読み取り可能媒体１０６はコンピュータ装置１０２によってアクセス可能な任意の利用可能な媒体であり、取り外し可能又は取り外し不可能な揮発性媒体及び不揮発性媒体（リードオンリメモリ（ＲＯＭ）及びランダムアクセスメモリ（ＲＡＭ）等）を含む。コンピュータ読み取り可能媒体１０６のＲＡＭ部分は、プロセッサ１０４によって即座にアクセスできる及び／又は現在操作されているプログラム・モジュール及びプログラム・データを含む。
【００１０】
例えば、コンピュータ読み取り可能媒体１０６はプログラム・モジュール１０８とプログラム・データ１１０とを含む。プログラム・モジュール１０８は、例えば、ＥＳ保護モジュール１１２、保護済みＥＳコンテンツ・マッピング・モジュール１１４及び他のプログラム・モジュール（例えば、オペレーティング・システム）を含む。ＥＳ保護モジュール１１２は、メディア・コンテンツ特有の特性に基づいて暗号化境界を選択することによりＥＳコンテンツを保護する。特に、ＥＳ保護モジュール１１２は、例えばＭＰＥＧ−２を用いて、ＥＳコンテンツ１１８を暗号化して保護済みＥＳコンテンツ１２０を生成する。このために、ＥＳ保護モジュール１１２は、ＥＳを含む、メディア・アクセス・ユニット（ＭＡＵ）の一部（即ち、データ・セグメント）に暗号化を適用する。１つの実現例においては、暗号化操作はカウンタ・モードにおける改良型暗号化標準（アドバンスト・エンクリプション・スタンダード、ＡＥＳ）である。各ＭＡＵは単一のビデオ又はオーディオ・フレーム（基本ストリーム・フレーム）であり、該フレームはヘッダ（例えば、開始コード及び付加ビット）とその後に関連付けられる。各ＭＡＵは１つ以上のデータ・セグメントを含む。各データ・セグメントは、ＥＳ保護モジュール１１２によってコンテンツ暗号化パラメータの同一の組が適用されるＭＡＵの連続したセクションである。ＥＳ保護モジュール１１２はデータ・セグメントを完全に暗号化し、又は、データ・セグメントを完全に明文のままにする。ＥＳはＴＳから発したものではない。しかし、ＥＳ保護操作はＴＳストリーム（例えば、「他のデータ」１２２参照）に適用される共通スクランブリング操作と両立する。
【００１１】
保護済みＥＳコンテンツ・マッピング・モジュール１１４（マッピング・モジュール１１４）は、トランスポート・パケット１２４へカプセル化するために、保護済みＥＳコンテンツ１２０をＭＡＵペイロード・フォーマット（ＭＰＦ）へマッピングする。ＭＰＦはＭＡＵの一部が暗号化されずに（明文のままに）通過することを許容する。また、ＭＰＦは、パーソナル・コンピュータやセットトップ・ボックス（例えば、図２参照）のようなメディア消費者が任意の他のＥＳから独立に各保護済みＥＳ１２０を処理すること、及び、任意の他のＭＡＵから独立に保護済みＥＳにおいて各ＭＡＵを処理することを可能にするに足る情報を提供する。ＭＰＦについては、「トランスポート・プロトコル・カプセル化のための保護済みＥＳのマッピング」という名称のセクションを参照して、以下に詳述する。１つの実現例においては、トランスポート・パケットはリアルタイム・トランスポート・プロトコル（ＲＴＰ）に基づくパケットに対応する。
【００１２】
１つの実施の形態においては、ＥＳコンテンツ（例えば、ＥＳコンテンツ１１８）はメディア・コンテンツ・トランスポート・ストリームにおいては生じていない。他の実施の形態においては、例えば、図２を参照して後述するように、ＥＳコンテンツはトランスポート・ストリームにおいて生じる。更に、例示のシステム１００は保護済みＥＳコンテンツ・マッピング・モジュール１１４がＥＳ保護モジュール１１２と同じコンピュータ装置に実装されていることを示しているが、マッピング・モジュール１１４は保護モジュール１１２を実装するコンピュータ装置とは異なるコンピュータ装置に実装されてもよい。こうした代替の実現例については、図２を参照して以下に述べる。図２においては、保護モジュール１１２の動作はコンテンツ・ソースによって実現され、マッピング・モジュール１１４の動作はメディア・センタによって実現される。
【００１３】
例示のシステム
図２は、ＥＳコンテンツを保護するための例示のシステム２００を示している。ＥＳコンテンツは、１つに実施の形態においては、トランスポート・ストリームにおいて生じる。トランスポート・ストリームはメディア・コンテンツをカプセル化する。例えば、システム２００は、コンテンツ・ソース２０２と、１つ以上のメディア加入者２０８にネットワーク２０６を介して結合されたメディア・センタ２０４とを含む。コンテンツ・ソース１００はビデオ・ゲーム・サーバ、ウェブサイト、ビデオ・サーバ、ミュージック・サーバ、ソフトウェア・アーカイブ、データベース、テレビジョン網等と関連する。コンテンツ・ソース２０２のＴＳスクランブリング・モジュール２１０はトランスポート・ストリームを暗号化する。１つの実現例においては、トランスポート・ストリーム暗号化２１０はトランスポート・ストリームを共通スクランブリングする。共通スクランブリングにより、暗号化されたトランスポート・ストリームは、復号化されるべきストリームの暗号化された部分を必要とすることなく処理（デマルチプレックス、指標付け等）されることができる。ＴＳスクランブリング・モジュール２１０は、図１のＥＳ保護モジュール１１２に関して上述したように、トランスポート・ストリームから生じるＥＳコンテンツを保護する。モジュールの関連する動作はＴＳストリームに適用される共通スクランブリング操作と両立するからである。
【００１４】
メディア・センタ２０４は中心に位置するコンピュータ装置であり、例えば伝送制御プロトコル／インターネット・プロトコル（ＴＣＰ／ＩＰ）又は他の標準通信プロトコルを用いてネットワーク２０６を介して又は直接にコンテンツ・ソース２０２と結合される。ネットワーク２０６の例は、ＩＰネットワーク、ケーブルテレビジョン（ＣＡＴＶ）ネットワーク及び直接放送衛星（ＤＢＳ）ネットワークを含む。メディア・センタ２０４はデマルチプレックス及びマッピング・モジュール２１２を含む。モジュール２１２は図では単一のコンピュータ・プログラム・モジュールとして示されているが、任意の数のコンピュータ・プログラム・モジュールにより実現してもよい。プログラム・モジュール２１２のデマルチプレックス動作は、ＴＳの暗号化された部分を復号化することなく、ＴＳを各ＥＳへデマルチプレックスする。
【００１５】
プログラム・モジュール２１２のマッピング動作は、メディア消費者への通信のためにトランスポート・パケットへその後にカプセル化するために、図１の保護済みＥＳコンテンツ・マッピング・モジュール１１４の既述の動作どおり、デマルチプレックスされた保護済みＥＳコンテンツをＭＰＦへマッピングする。上記のとおり、ＭＰＦは、トランスポート・パケットにカプセル化されるとき、ＭＡＵのデータ・セグメントが明文のままであることを許容する。また、ＭＰＦは、メディア消費者が、受信した保護済みＥＳを任意の他のＥＳから独立に処理することができ、保護済みＥＳにおける関連のＭＡＵを任意の他のＭＡＵから独立に処理することができるのに十分な情報を提供する。ＭＰＦについては、「トランスポート・プロトコル・カプセル化のための保護済みＥＳのマッピング」という名称のセクションを参照して以下に詳述する。１つの実現例においては、トランスポート・パケットはリアルタイム・トランスファ・プロトコル（ＲＴＰ）に基づくパケットに対応する。
【００１６】
メディア・センタ２０４は、カプセル化された保護済みメディア・コンテンツをネットワーク２０６を介して１つ以上の加入者２０８へ通信し、ＰＣ２１４及びＳＴＢ２１６はメディア・コンテンツを受信する。ＰＣ２１４上で処理されレンダリングされたメディア・コンテンツはＰＣ２１４に関連するモニタに表示される。ＳＴＢ２１６上で処理されレンダリングされたメディア信号はテレビジョン（ＴＶ）２１８又は同様の表示装置に表示される。１つの実現例においては、ＴＶ２１８はＳＴＢ２１６を内蔵する能力を有する。
【００１７】
トランスポート・ストリーム共通スクランブリングの分析
１つの実現例においては、ＥＳコンテンツはトランスポート・ストリームによって運ばれる。このシナリオでは、コンテンツ・ソース２０２のＴＳスクランブリング・モジュール２１０は、共通スクランブリングのためにトランスポート・ストリームを分析する。特に、トランスポート・ストリームは、トランスポート・ストリームが暗号化後に受け得る少なくとも１つの処理に対するデータ要求を考慮して分析される。少なくとも１つのプロセスに対応する統計モデルに基づいて決定がなされるならば、最も広い（即ち、閾値の）データ要求を持つ特定のプロセスに対して、閾値データ要求が決定される。この分析は、トランスポート・ストリームのどの部分が暗号化されずに通過するべきかを決定するために実行される。
【００１８】
共通スクランブリング分析は、任意のヘッダ情報を含むトランスポート・ストリーム内の任意のパケットが暗号化されずに通過されるべきであることの承認を組み込む。こうしたパケット及びヘッダ情報の記述は、図６を参照して以下に提供される。ＰＥＳヘッダ情報の任意の部分又は「追加ヘッダ・データ」の任意の部分を含むパケットは暗号化されずに通過されるべきである。更に、完全な又は部分的なストリーム・マークを含むパケットは暗号化されずに通過する。
【００１９】
【表１】
2009505515.tif 000003
【００２０】
表１を参照すると、この実現例において明文のままにされるべきデータの量は、ストリーム・マークの長さと最大データ・ペイロード長との和に対応する。明文のままのセクションはストリーム・マークの前に開始し、ストリーム・マークと最大データ・ペイロード長との和が例えば２つの連続するＴＳパケット・ペイロードを越えない限り、ストリーム・マークと最大データ・ペイロード長との和の後に終了する。例えば、送信側（例えば、図２のコンテンツ・ソース２０２等）は、シーケンス・ヘッダを示すストリーム・マークに対して１６バイト（ストリーム・マークのための４バイトに最大データ・ペイロード長のための１２バイトを加えたもの）〜３６８バイトを明文のままにする。
【００２１】
ストリーム・マークが現在のＭＡＵの先頭の近くに現れる場合には、以前のＭＡＵからの若干の量のデータを明文のままにすることができる。１つの実現例においては、これは、自由なセクションの長さが３６８バイトを超えないときに許容される。
【００２２】
トランスポート・ストリームの任意の部分が暗号化されずに通過し得るので、他の代替の実施の形態は、共通スクランブリングが適用されるフレーム・ヘッダやＰＥＳヘッダを想定するが、これには、これらのヘッダに含まれるデータが、デスクランブリングせずにトランスポート・ストリームを処理するのには使用されないことが前提となる。
【００２３】
暗号化
図３は、ＥＳメディア・コンテンツを暗号化するための、カウンタ・モードにおける改良型暗号化標準（ＡＥＳ）の動作の例示的な態様を示すブロック図である。図３を参照して以下に説明する種々のデータ及び動作は、図１のＥＳ保護モジュール１１２及び図２のＴＳスクランブリング・モジュール２１０の例示の動作を表している。データ・セグメントは、保護されているコンテンツの形式に基づいて異なる定義を持つけれども、ＥＳを暗号化するときには、任意の数のデータ・セグメントを有するＭＡＵは、ビデオ又はオーディオの単一のフレームを表す。
【００２４】
図３を参照すると、カウンタ・モードにおけるＡＥＳは、トランスポート・ストリームにおけるそれぞれのデータ・セグメントに基づいて、バイトのストリームを作る。バイトのストリームは、コンテンツのテキスト・バイトとＸＯＲされて、暗号化されたコンテンツを生成する。キー・ストリーム生成器は、ＡＥＳラウンドを用いてキー・ストリームの１６バイトのブロックを同時に生成する。ＡＥＳラウンドへの入力は、データ・セグメントＩＤと新たなセグメント内のブロックＩＤとの１２８バイトの連結とコンテンツ暗号化キー（ＫＣ）である。キー・ストリーム生成器の出力は、データ・セグメントの対応のブロック（ｉ）からのデータでバイト毎にＸＯＲされる。データ・セグメントが１６バイトで均等に割れないならば、最後のブロックからのデータ・セグメントの残りのバイトが、キー・ストリームでＸＯＲされて、暗号化されたデータ・セットに対して保持される。ＭＡＵとその関連のヘッダは更に多くのデータ・セグメントを表す。
【００２５】
図４は、保護済みＥＳを運ぶトランスポート・ストリームへの挿入のための例示の暗号化方法（「ＴＡＧ」）パケットを示している。図４を参照すると、
adaptation_field_control_bit（適応フィールド制御ビット）は１０ｂにセットされる（適応フィールドのみであり、ペイロードなし）ので、連続性カウンタを増分する必要はない。
【００２６】
ＡＦヘッダはＭＰＥＧ仕様に準拠するよう４バイトを含み、
第１バイト＝適応フィールド長
第２バイト＝適応フィールド存在フラグ（私的データ＝０ｘ０２）
第３バイト＝私的データ長（ＤＲＭ長）
第４バイト＝バージョン数（現在は０ｘ００）
である。
【００２７】
DrmGuidはGUIDを{B0AA4966-3B39-400A-AC35-44F41B46C96B}にセットする。
base_counter（ベース・カウンタ）は、以後の暗号化パケットに対するＡＥＳカウンタを再同期する。
【００２８】
ＳＭバイト（ストリーム・マーク）は、以降のパケットがストリーム・マークの先頭を含むが、そこから最初の幾つかのバイトが失われていることを示す。
ＳＭ＝０は、次のパケットがＰＥＳヘッダの先頭又はＰＥＳヘッダ全体を運ぶことを示す。
【００２９】
ＳＭ＝１は、次のパケットがストリーム・マークの先頭を含むことを示す。
ＳＭ＝２は、次のパケットがストリーム・マークの先頭を含むが、最初のバイト（００）が失われていることを示す。
【００３０】
ＳＭ＝３は、次のパケットがストリーム・マークの先頭を含むが、最初の２バイト（００  ００）が失われていることを示す。
ＳＭ＝４は、次のパケットがストリーム・マークの先頭を含むが、最初の３バイト（００  ００  ００）が失われていることを示す。
【００３１】
ＳＭ＝その他は保留を示す。
Privte_DRM_parameters（専用ＤＲＭパラメータ）はデータ・セグメント記述子を含み、データ・セグメント記述子は対応のキーＩＤ値を持つキーＩＤ拡張セットを含む。ＡＥＳ１２８初期化ベクトル拡張は存在せず、これは、データ・セグメントＩＤがＴＡＧパケットのbase_counterセクションに示されるからである。
【００３２】
パケットには０ｘＦＦが付加される。
したがって、ＴＡＧパケットは、それぞれの保護済みＥＳユニットの前に挿入されるキー識別子（ＫＩＤ）を持つ単一のＴＳパケットである。この実現例においては、ＴＡＧパケットは、コンテンツがメディア消費者へ配信されたときに、一致するデジタル・ライト・マネージメント（ＤＲＭ、デジタル権利管理）を検索するために用いられる。コンテンツ保護レイヤはカウンタ・モードにおいてＡＥＳ１２８ビット・キーを含み、以下の要件、即ち、１２８ビット・カウンタは２つの６４ビット・フィールドであるbase_counter(MSB)及びminor_counter(LSB)に分割されることが適用される。base_counter及びminor_counterは、上記のデータ・セグメントＩＤ及びブロックＩＤと等価である。ＴＡＧパケットは、トランスポート・ストリームの暗号化された部分で用いられる暗号化アルゴリズムに対する識別を提供し、復号化キーを推論するための許可された復号器に必要なデータを提供し、暗号化されずに又は暗号化されて通過するトランスポート・ストリームの部分を識別する。ＴＡＧパケットは、暗号化されたストリームのどの部分がそれぞれの処理（デマルチプレックス、又はトリック・モード又はサムネール抽出のための指標付け）に用いられるかを識別する更なるデータを含む。更に、ＴＡＧパケットは多重化されたトランスポート・ストリームにしたがって挿入される。
【００３３】
ＴＡＧパケットは、トランスポート・ストリームの全部の暗号化された部分に対応して生成される。代わりに、暗号化法パケットは、暗号化されたＰＥＳペイロード・データの個々のパケット又はバイトに対応して生成される。こうして、ＴＡＧパケットは、トランスポート・ストリームにおける各ＰＥＳヘッダに対応して、トランスポート・ストリームにおけるＰＥＳヘッダの所定の数に対応して、又は、他の処理に対して暗号化されずに通過するパケットの所定のパターンにしたがって生成される。
【００３４】
図５は、１つの実施の形態に係る、（ＥＳコンテンツがトランスポート・ストリームによって運ばれないときと比較しての）トランスポート・ストリーム内のＥＳコンテンツを保護するための送信側の動作の例示的な流れを示している。以下のリストは図５の態様を記述している。
【００３５】
・  scr：この変数は、現在のＴＳパケットが共通にスクランブリングされるべきであるときには「イエス（yes）」にセットされ、その他の場合には「ノー（no）」にセットされる。
【００３６】
・  key_sync：この変数は、送信側がＡＥＳキーを更新しているときには「yes」にセットされ、その他の場合には「no」にセットされる。
・  PID（１３ビット）：選択された基本ストリームのＰＩＤ値である。
【００３７】
・  base_counter：この６４ビットのフィールドは、送信側のライフタイム全体を通して送信側によって一義的に定義される。１つの実施形態においては、ビット０〜５０はsection_counter（セクション・カウンタ）を表し、ビット５１〜６３はＰＩＤに対して保留される。
【００３８】
・  section_counter（５１ビット）：ｓｃｒ状態変数のｎｏからｙｅｓへの変位毎に増分される循環カウンタである。
・  minor_counter：スクランブリングされた１６バイトのブロックごとに増分される６４ビット・カウンタである。
【００３９】
・  i：スクランブリングされたバイト毎に増分される６４ビット・カウンタである。
・  scramble16：AESKEY[base_counter ｜ minor_counter]。
ＡＥＳキー置換のイベントが生じた後、送信側は、各ＰＥＳコンポーネントと再同期するまで、全部のＰＩＤをスクランブリングするのを停止する。この遷移は、同じプログラムからの全部のＰＩＤが同一のキーでスクランブリングされることを保証する。scrステータスを定義するとき、下記の条件、即ち、
・  key_sync＝yes
・  ＴＳパケットがＰＥＳヘッダの全部又は一部を含む
・  ＴＳパケットが、下表に挙げられた１つ以上のストリーム・マークの全部又は一部を含む（ストリーム・マークは、ＭＰＥＧ開始コードと、それに続くデータ・ペイロード（表１に示す）とからなる）
のうちのいずれかが適用されるならば、それぞれの受信されたＴＳパケット毎に、scr状態変数を「no」にセットする。
【００４０】
図６は、１つの実施の形態に係る例示のトランスポート・ストリームを示している。送信側は、明文のままになっている任意のＴＳパケットの前にＴＡＧパケットを挿入する。図６に示すように、ＰＥＳヘッダの全部又は一部を含むパケットの前にＴＡＧパケットが挿入される場合（ケースＡ）と、ストリーム・マークの全部又は一部を含むパケットの前にＴＡＧパケットが挿入される場合（ケースＢ）という２つの可能なシナリオが生じる。
【００４１】
また、実施の形態は、ＴＡＧパケットがトランスポート・ストリームに挿入されることを必要とはしない。ＴＡＧパケットは復号化の時点まで必要ではないので、復号化の時点までにプロセッサに届く限りは、ＴＡＧパケットは帯域内又は帯域外で（例えば、専用ケーブルによって）プロセッサへ送信される。更に、ＴＡＧパケットはコンテンツ使用ライセンスへ送信され、次いで、帯域内又は帯域外でプロセッサへ送信される。
【００４２】
保護済みＥＳのＭＡＵペイロード・フォーマットへのマッピング
保護済みＥＳは、共通にスクランブリングされたトランスポート・ストリームが明文のままであるように、ＭＰＦへマッピングされる。このマッピングにより、メディア消費者は各ＭＡＵを独立に処理することができる。１つの実現例においては、コンテンツ・ソース２０２のような送信側がこうしたマッピング動作を実施する。
【００４３】
従来のＲＴＰヘッダの構文がＲＦＣ−３５５０において定義され、また図１１に示されている。ＲＴＰヘッダとともに、図１のシステム１００及び図２のシステム２００は保護済みＥＳコンテンツ（例えば、図１の保護済みＥＳコンテンツ）をＭＡＵペイロード・フォーマット（ＭＰＦ）へマッピングする。しかし、マルチメディア・プレゼンテーションにおける全部のメディア・ストリームは同じＭＰＦを使わず、異なるペイロード・フォーマットが用いられる。ここで、どのようにＭＡＵがＭＰＦにカプセル化されるかを説明する。
【００４４】
図７は、１つの実施の形態に係る、ＭＰＦヘッダの例示のハイレベル構造を示している。ヘッダは標準のＲＴＰヘッダに関係させて図示されている。ＭＰＦヘッダは送信側（例えば、図１のコンピュータ１０２及び／又は図２のメディア・センタ）によってトランスポート・パケットにおける各ＭＡＵ又はその一部の前に挿入される。図７に示すように、この例示の実現例におけるＭＰＦヘッダは３つのセクションへ分割される。各セクションは１バイトのビット・フィールドで始まり、その後に１つ以上のオプションのフィールドが続く。場合によっては、２つまでのセクションがＭＰＦヘッダから省略される。こうして、ＭＰＦヘッダは１バイト程度の小ささである。
【００４５】
ＭＰＦヘッダの後に「ペイロード」が続く。ペイロードは完全なＭＡＵ又はその一部を含む。ペイロードは部分的なＭＡＵを含み、大きなＭＡＵは複数のトランスポート・パケットにおいて複数のペイロードにわたって寸断される。第１のペイロードの後には、トランスポート・パケットのサイズによって許容される、ＭＰＦヘッダ及びペイロードの追加の対が続く。
【００４６】
ＭＰＦヘッダの第１のセクションは、図７では「パケット特有情報」と呼ばれ、トランスポート・パケットにおける全部のペイロードに特有の情報を含む。「パケット特有情報」のセクションは各トランスポート・パケットにおいて一度だけ、ＲＴＰヘッダの末尾の直後に現れる第１のＭＰＦヘッダにのみ含まれる。第２のセクションは「ＭＡＵ特性」と呼ばれ、ペイロードを記述する情報を含む。例えば、このセクションはビデオＩ−フレームのような同期点であるＭＡＵをペイロードが含むかどうかを指定するとともに、ペイロードのサイズを決定する方法を特定する。更に、このセクションは、先のパケットが失われていた場合に受信側がトランスポート・パケットを構文解析できるようにする情報を含んでいる。これは、ＭＡＵが複数のトランスポート・パケットにわたって寸断される場合に有用である。
【００４７】
第３のセクションは「ＭＡＵタイミング」と呼ばれ、ペイロードにおけるＭＡＵに関連する種々のタイムスタンプに関する情報を提供する。例えば、このセクションはＭＡＵのプレゼンテーション時間を決定する方法を特定する。また、このセクションは、追加の情報がＭＰＦヘッダに含まれるようにする拡張機構を含む。
【００４８】
図８は、１つの実施形態に係る、図７のＭＰＦヘッダの例示の詳細なレイアウトを示している。図８の３つのセクション８０２〜８０６のそれぞれは、複数の個別のヘッダ・フィールドを含む。これらのフィールドが図８にボックスとして図示されている。ボックスの高さはヘッダ・フィールドの相対的なサイズの指示を与える。しかし、図は完全に一定の比率で描かれてはいないので、「拡張」フィールドは可変サイズであることに留意されたい。
【００４９】
図８を参照すると、３つのセクションにおける第１のヘッダ・フィールドはビット・フィールドである。或るセクションにおける他のヘッダ・フィールドは、当該セクションのビット・フィールドによって指示される場合にのみ存在する。場合によっては、ビット・フィールドを含む完全なセクションが省略され得る。パケット仕様情報（Ｉｎｆｏ）セクションは「ビット・フィールド１」を含み、また、図８に示す他の任意のフィールドを含む。同じトランスポート・パケットにおける追加のＭＰＦヘッダは「ビット・フィールド２」で始まり、「ＭＡＵ特性」のセクション及び「ＭＡＵタイミング」のセクションにおけるフィールドを含む。
【００５０】
最も簡単で可能なケースにおいては、トランスポート・パケットは単一の完全なＭＡＵを含む。この場合、全部のヘッダ・フィールドを含むことができる。しかし、必要でないフィールドは省略され得る。ＭＰＦヘッダの３つのセクションのそれぞれは、セクションのどのフィールドが存在するかを示すビット・フィールドを有する。
【００５１】
例えば、「オフセット」フィールドは、現在のペイロードの末尾からのバイト・オフセットを特定するが、パケットが単一のペイロードを含むときには不要である。これはペイロードの長さがトランスポート・パケットのサイズによって推測できるからである。「ビット・フィールド２」における「ＯＰ」ビットは「オフセット」フィールドが存在するかどうかを示す。「ビット・フィールド３」における全部のビットがゼロであれば、「ビット・フィールド３」自体が省略され、これは「ビット・フィールド２」における「Ｂ３Ｐ」ビットをゼロにセットすることによって示される。
【００５２】
単一のトランスポート・パケットにおける複数のペイロードを結合することが可能である。これは「グルーピング」と呼ばれる。「オフセット」フィールドは「グルーピング」の使用を示す。「オフセット」フィールドが存在すれば、別のＭＰＦヘッダと別のペイロードが、そのときのペイロードの末尾の後に続く。「オフセット」フィールドは、「オフセット」フィールド自体の末尾からカウントした、そのときのペイロードの末尾までのバイト数を特定する。別のＭＰＦヘッダがそのときのペイロードの末尾に続くかどうかを決定するためには、実装には、「オフセット」フィールドの値ばかりでなくトランスポート・パケットのサイズをも考慮することが必要であり、ＲＴＰがトランスポート・プロトコルとして用いられている場合にはＲＴＰ付加領域のサイズも考慮する必要がある。
【００５３】
単一のＭＡＵを複数のペイロードへ分割することができる。これは「断片化」と呼ばれる。断片化の主な利用は、単一のトランスポート・パケット内に適合するものよりＭＡＵの方が大きいときである。「ビット・フィールド２」における「Ｆ」フィールドは、ペイロードが完全なＭＡＵ又はその断片を含むかどうかを示す。
【００５４】
「ＭＡＵタイミング」セクションにおけるフィールドは、ＭＡＵの第１の断片を含むペイロードに対するＭＰＦヘッダにおいてのみ指定される。これに対する唯一の例外は、「ＭＡＵタイミング」」セクションにおける「拡張」フィールドが、同じＭＡＵの異なる断片に対する異なる拡張を含む場合である。ＭＡＵが断片化されると、「ビット・フィールド２」におけるビット「Ｓ」、「Ｄ１」及び「Ｄ２」は、第１の断片を含むペイロードに対するＭＰＦヘッダにおいてのみ意味を有する。したがって、これらのビットは、「Ｆ」フィールドの値がゼロ又は２の場合、受信側（メディア消費者）によって無視される。
【００５５】
この実現例においては、ＭＡＵは、単一のトランスポート・パケット内に適合しないほど大きくなければ、断片化されない。この実現例において、１つのＭＡＵの断片は単一のトランスポート・パケットにおける他のＭＡＵ又は他のＭＡＵの断片とは組み合わされない。しかし、受信側はこれらの場合を取り扱う。これの一例を図９に示す。
【００５６】
図９は、１つの実施の形態に係る、ＭＰＦを用いる３つのリアルタイム・トランスポート・パケットの例示のシーケンスを示している。３つのトランスポート・パケットは４つのＭＡＵのデータを運ぶ。第４のＭＡＵは第４のトランスポート・パケット（図示せず）に含まれる。図は、所望の場合に、固定サイズのトランスポート・パケットを作成するためにＭＡＵの断片化をどう利用するかを示している。図から分かるように、ＭＡＵ２は２つのトランスポート・パケットにわたって断片化されている。第１のトランスポート・パケットにおいて、ＭＡＵ２に対するＭＰＦヘッダは、ＭＡＵ２が次のトランスポート・パケットにおいて継続されることを指定する（これはビット・フィールド２における「Ｆ」ビットを用いて伝えられる）。
【００５７】
第２のトランスポート・パケットは「ＭＡＵタイミング」フィールドを省略したＭＰＦヘッダで開始する。これは、ＭＡＵ２に対する「ＭＡＵタイミング」フィールドが第１のトランスポート・パケットにおいて既に指定されているからである。「ＭＡＵ特性」セクションにおける「オフセット」フィールドは，ＭＡＵ３に対するペイロード・フィーマット・ヘッダの先頭を見つけるために使用される。これにより、先のトランスポート・パケットが失われたときでさえ、クライアントはＭＡＵ３を復号することができる。同様に、図は、どのようにＭＡＵ４が第２のトランスポート・パケットと第３のトランスポート・パケットとにわたって断片化されるかを示している。しかし、ＭＡＵ４は大きすぎるので、追加のＭＡＵを第３のトランスポート・パケットに挿入することができない。この例では、ＭＡＵ４は第４のトランスポート・パケット（図示せず）に継続される。このような状況において、第３のトランスポート・パケットのペイロード・フォーマット・ヘッダは「オフセット」フィールドを含む必要が無いので、「ＭＡＵ特性」セクション全体を省略することができる。ＭＰＦヘッダの残りの部分は「パケット特有情報」セクションを含むのみであり、単一のバイトと同程度に小さい。
【００５８】
ＭＡＵが複数のペイロードへ断片化されるならば、ペイロードは個別のトランスポート・パケットにおいて通常は運ばれる。しかし、ＭＰＦは、同じＭＡＵに対する複数のペイロードを単一のトランスポート・パケット内で運ぶことを許容する。トランスポート・パケットにおけるペイロードがＭＡＵの断片を含むならば、これは「ビット・フィールド２」における「Ｆ」フィールドによって指示される。
【００５９】
図１０は、１つの実施の形態に係る、単一のＭＡＵが同一のＲＴＰパケットにおける３つの断片へ分割された例を示している。この例においては、第１のＭＰＦヘッダにおける「Ｆ」フィールドは１にセットされ、第１のペイロードがＭＡＵの第１の断片を含むことを示す。「ＭＡＵタイミング」セクションはこの第１のペイロードにのみ存在する。第２のＭＰＦヘッダにおける「Ｆ」フィールドはゼロにセットされ、そのペイロードが、ＭＡＵの最初の断片でも最後の断片でもない断片を含むことを示す。第３のＭＰＦヘッダにおける「Ｆ」フィールドは２にセットされ、そのペイロードがＭＡＵの最後の断片を含むことを示す。
【００６０】
通常のＲＴＰサンプリング・クロック及びウォールクロック（wallclock）に加えて、ＭＰＦは若干の追加のタイムスタンプと時間観念を提供するが、これについて説明する。ＲＴＰヘッダは、パケットにおけるデータがサンプリングされた時間を指定する単一のタイムスタンプを有する。このタイムスタンプはサンプリング・クロックと呼ばれることがある。異なるメディア・ストリームに所属するパケットのＲＴＰタイムスタンプは比較され得ないことに留意することは有用である。その理由は、サンプリング・クロックが、異なるメディア・ストリームに対して異なる周波数で走るからである。例えば、オーディオ・ストリームのサンプリング・クロックは４４１００Ｈｚで走るが、ビデオ・ストリームのサンプリング・クロックは９００００Ｈｚで走る。更に、ＲＦＣ−３５５０は初期ＲＴＰタイムスタンプがランダムに選択されるべきであることを指定している。実際、各メディア・ストリームはそれ自体のタイムスタンプを有する。本明細書においては、こうした各タイムラインは「メディア・タイムライン」と呼ばれる。
【００６１】
ＲＴＰは、異なるメディア・ストリームに対するタイムラインを基準クロック（ウォールクロックと呼ばれる）のタイムラインと同期させることができるようにする。ＲＴＰの送出側は、ＲＴＣＰセンダ・レポート・パケットにおいてサンプリング・クロックとウォールクロックとの間のマッピングを送信することにより、受信側がこの同期を実施できるようにする。各メディア・ストリーム毎にＲＴＣＰセンダ・レポートが送出されなければならない。これは、メディア・ストリームが異なるサンプリング・クロックを用いるからである。
【００６２】
マッピングは、受信側がウォールクロックとサンプリング・クロックと間の可能なドリフトを訂正できるよう、或る間隔で更新され再送信される。送出側のウォールクロックが受信側のウォールクロックに関係してドリフトする場合には、クロック・ドリフトは問題である。２つのクロックは例えばＮＴＰプロトコルを用いて同期を取ることができる。しかし、ＲＴＰ仕様は特定の同期方法を指定していない。ウォールクロックは符号器から発せられることに留意されたい。ＲＴＰの送出側と符号器が別個のエンティティであれば、典型的には、ウォールクロックは送出側での任意の物理的クロックとは無関係である。
【００６３】
このＭＰＦは、ノーマル・プレイ時間（ＮＰＴ）タイムラインと呼ばれる第３のタイムラインを用いる。ＮＰＴタイムラインは、ＲＴＰがメディア「プレゼンテーション」を送信するために用いられるときに主に有用である。ＮＰＴタイムラインからのタイムスタンプはプレゼンテーションの開始時に普通はゼロで始まる。ＮＰＴタイムスタンプは、予め記録されたプレゼンテーションを送るときに特に有用である。これは、受信側がプレゼンテーション内で探すべき位置を特定するのをタイムスタンプが助けるからであり、受信側が新たな位置をＲＴＰの送出側へ伝えるための何等かの機構の存在を仮定する。
【００６４】
ＲＴＰはマルチメディア会議の応用のために設計されたので、ＲＴＰ仕様はＮＰＴタイムラインを検討していない。しかし、ＲＴＳＰ（ビデオ・オンデマンド・アプリケーションのための制御プロトコル）のような、ＲＴＰの上に作られる他のプロトコルは、ＮＰＴタイムラインの概念を含んでいる。ＲＴＳＰにおいて、制御プロトコルはＮＰＴタイムラインと各メディア・ストリームに対するメディア・タイムラインとの間のマッピングを提供する。
【００６５】
ＭＰＦは、ＭＡＵに関連付けられたＮＰＴタイムライン・タイムスタンプを指定する機構を定義する。しかし、実際には、メディア・タイムラインとＲＴＳＰによって定義されたようなＮＰＴタイムラインとの間の帯域外マッピングは、ＭＰＦヘッダのオーバーヘッドを低減するが故に好ましい。
【００６６】
ＲＴＰに準拠する全部のシステムはタイムスタンプの循環（wrap around）を取り扱う。９００００Ｈｚという典型的なクロック周波数において、ＲＴＰタイムスタンプはほぼ１３時間毎に循環する。しかし、サンプリング・クロックに対してランダムなオフセットを追加すべきであることをＲＴＰ仕様が述べているので、受信側は１３時間よりもかなり短い時間で第１の循環を経験することになる。ＲＴＰタイムスタンプの循環は、モジュラー演算（modular arithmetic）を用いることによって通常は取り扱われる。モジュラー演算が用いられるとき、タイムスタンプ間の差を取って、その結果が正であるか負であるかを観察することによって、タイムスタンプは通常は比較される。
【００６７】
ＭＰＦにおいて、各ＭＡＵは「復号時間」と「プレゼンテーション時間」とを有する。復号時間は，ＭＡＵを受信側の復号器へ配信すべき時間であり、プレゼンテーション時間は、受信側によってＭＡＵが提示（表示又は再生）されるべき時間である。両方の時間はメディア・タイムラインに属する。ネットワーク及び復号器での遅延は典型的にはＲＴＰ送出側には分からないので、受信側は復号タイムスタンプ又はプレゼンテーション・タイムスタンプの絶対値を用いない。受信側は復号タイムスタンプの対の間又はプレゼンテーション・タイムスタンプの対の間の相対的な差のみを考慮する。
【００６８】
場合によっては、ビデオ・コーデックが双方向ビデオ・フレームを生成する場合などにおいては、ＭＡＵは、提示されるのとは異なる順序で復号される。この実現例においては、ＲＴＰの送出側は復号されるべき順序でＭＡＵを送信する。
【００６９】
ＲＴＰヘッダにおける「タイムスタンプ」フィールドは、トランスポート・パケットにおける第１のＭＡＵのプレゼンテーション時間にマッピングされる。トランスポート・パケットは復号順序で送信されるので、連続するＭＡＵのプレゼンテーション時間タイムスタンプは非単調減少ではない。
【００７０】
ＭＰＦヘッダはオプションの「復号時間」フィールドを含み、このフィールドはペイロードにおけるＭＡＵの復号時間を指定するために用いられる。また、ＭＰＦヘッダは「プレゼンテーション時間」フィールドを含み、このフィールドは、トランスポート・パケットが複数のＭＡＵを含むときにＭＡＵのプレゼンテーション時間を指定するために用いられる。トランスポート・パケットに唯一つのＭＡＵが含まれているときには、「プレゼンテーション時間」フィールドは不要である。「タイムスタンプ」フィールドがパケットでの第１のＭＡＵにおける当該フィールドの代わりとなるからである。この実現例においては、「復号時間」フィールド及び「プレゼンテーション時間」フィールドは、「タイムスタンプ」フィールドと同じクロック解像度を用いて表わされる。
【００７１】
用語「トリック・プレイ」は、受信側が非実時間速度でメディア・プレゼンテーションを行うことを意味する。トリック・プレイの例は、プレゼンテーションの早送り及び巻き戻しを含む。ＲＴＰの送出側がトリック・プレイ・モードで送信しているならば、各ＭＡＵに対する復号タイムスタンプ及びプレゼンテーション・タイムスタンプは実時間速度で増分されるべきである。これにより、復号器は、トリック・プレイが用いられることを知ることなくＭＡＵを復号することができる。ＭＰＦヘッダにおける「復号時間」フィールド及び「プレゼンテーション時間」フィールドはトリック・プレイによって影響されないが、「ＮＰＴ」フィールドは（存在する場合には）影響される。例えば、メディア・プレゼンテーションが巻き戻されているならば、ＭＡＵの「プレゼンテーション時間」タイムスタンプ・フィールドは増加しており、「ＮＰＴ」フィールドの値は減少している。
【００７２】
ＭＰＦヘッダにおける「ＮＰＴ」フィールドは、ＭＡＵが所属するノーマル・プレイ時間タイムラインにおける位置を指定する。「ＮＰＴ」フィールドが存在しない場合には、２つのタイムライン間のマッピングが利用可能であれば、受信側はプレゼンテーション時間からＭＡＵのノーマル・プレイ時間を計算することができる。ＲＴＰの送出側はメディア・タイムラインにおけるタイムスタンプにランダムなオフセットを追加するので、プレゼンテーション時間タイムスタンプはＮＰＴタイムラインの直接的な置換としては用いられない。このランダムなオフセットが受信側で知られているとしても、メディア・タイムライン・タイムスタンプの循環は問題である。
【００７３】
こうした問題に対する可能な解決法は、ノーマル・プレイ時間タイムスタンプとメディア・タイムラインとの間のマッピングを提供する帯域外の機構を送信側が使うことである。このマッピングは、送信の開始時に一度だけ、又は必要によっては反復して提供される。更に、トリック・プレイが可能であれば、送信側はトリック・プレイ速度を伝える。例えば、プレゼンテーションが巻き戻されている場合、トリック・プレイ速度は負である。受信側はトリック・プレイ速度を用いて、プレゼンテーション時間の増加とともに減少するＮＰＴタイムスタンプを生成する。
【００７４】
マッピングが送信の開始時に１度だけ提供されるならば、受信側はノーマル・プレイ時間タイムラインとウォールクロック・タイムラインとの間のマッピングを確立する。これは、通常、適切なＲＴＣＰセンダ・レポートが受信されると直ちに可能である。ＭＡＵのウォールクロック時間に基づいて各ＭＡＵに対するＮＰＴタイムスタンプを計算することが望ましい。メディア・タイムラインからのタイムスタンプはウォールクロック・タイムラインに対してドリフトするからである。
【００７５】
ＲＴＳＰプロトコルは、送信の開始時にノーマル・プレイ時間タイムラインとメディア・タイムラインとの間のマッピングを提供する制御プロトコルの一例である。複雑さとオーバーヘッドの間の適切なトレードオフを提供する別の解決法は、同期点ＭＡＵ上のみの「ＮＰＴ」フィールドを含むことである。「ＮＰＴ」フィールドはノーマル・プレイ時間タイムラインとプレイ時間タイムライン又はウォールクロック・タイムラインとの間のマッピングを確立するのに用いられる。非同期点ＭＡＵに対しては、受信側は先に確立したマッピングを用いてＮＰＴタイムスタンプを計算する。トリック・プレイが用いられると、送信側はＭＡＵ毎に「ＮＰＴ」フィールドを含める。
【００７６】
ＭＰＦヘッダにおける「送出時間」フィールドはトランスポート・パケットの送信時間を指定する。これは、一連のトランスポート・パケットが１つのサーバから他のサーバへ転送されるときに有用である。第１のサーバのみがパケットに対する送信スケジュールを計算する必要がある。第２のサーバは、「送出時間」フィールドの値に基づいて他のクライアントへトランスポート・パケットを送る。トランスポート・パケットをクライアントへ送るとき、「送出時間」フィールドを含むことが不要である。しかし、クライアントは「送出時間」フィールドを用いて、一連のパケットにおける「送出時間」フィールドの値間の差とパケット到着時間の差とを比較することによってネットワークの混雑状態を検知することができる。「送出時間」フィールドはメディア・タイムラインと同じ単位を用いる。
【００７７】
「対応」フィールドはウォールクロック・タイムラインと現在のメディア・タイムラインとの間のマッピングを提供する。ＲＴＰが転送プロトコルであるとき、これはＲＴＣＰセンダ・レポートにおいて提供される同じマッピングである。トランスポート・パケットにマッピングを含めることは、個別のＲＴＣＰパケットを送信するより効率的である。これにより、送出側はＲＴＣＰセンダ・レポートの周波数を低減しながらも、所望の周波数でマッピングを送信することができる。
【００７８】
図１１は、標準の１２バイトＲＴＰヘッダを参照のために示している。図１１を参照すると、
・  「バージョン」（Ｖ）フィールド：２ビットであり、このフィールドは２にセットされる。
【００７９】
・  「付加」（Ｐ）ビット：このビットはＲＴＰパケットの末尾に付加を追加するために用いられる。
・  「拡張」（Ｘ）ビット：このビットはＲＴＰヘッダ拡張が存在するとき１にセットされる。ＲＴＰプロファイルはヘッダ拡張をどう使うかを定義する。受信側は、ＲＴＰヘッダが非ゼロの「拡張」ビットを持つならばヘッダ拡張を分析し又は飛び越すことができる。
【００８０】
・  「寄与ソース」（ＣＣ）フィールド：４ビットである。受信側は、ＲＴＰヘッダが非ゼロの寄与ソース・フィールドを持つ場合に、寄与ソース・フィールのリストを分析し又は飛び越すことができる。
【００８１】
・  「マーカー」（Ｍ）ビット：このビットは、トランスポート・パケットにおける任意のペイロードが完全なＭＡＵ又はＭＡＵの最後の断片を含む場合に１にセットされる。
・  「ペイロード・タイプ」（ＰＴ）フィールド：７ビットである。ＲＴＰペイロード・タイプの割り当ては本明細書の範囲外である。該フィールドは、このペイロード・フォーマットが用いられ又は動的に帯域外で（例えばＳＤＰを用いて）伝えられるＲＴＰプロトコルによって指定される。
【００８２】
・  「シーケンス番号」フィールド：１６ビットである。このフィールドは、同じＳＳＲＣ値とともに送出されるトランスポート・パケット毎に１だけ増分する数である。ＲＴＰシーケンス番号の初期値は非ＲＴＰ手段を介してクライアントへ伝えられる。
【００８３】
・  「タイムスタンプ」フィールド：３２ビットである。このフィールドは、トランスポート・パケットに含まれる最初のペイロードに適用されるタイムスタンプである。デフォルトで、このフィールドはプレゼンテーション時間と解釈される。「タイムスタンプ」フィールドのクロック周波数は９０ｋＨｚ即ち１／９００００の解像度であることが推奨される。送出側及び受信側は非ＲＴＰ手段により別のクロック周波数を交渉してもよい。
【００８４】
・  「同期ソース」（ＳＳＣＲ）フィールド：３２ビットである。ＳＳＣＲフィールドと同じ値を持つトランスポート・パケットは、同じタイムラインを「タイムスタンプ」フィールドと共有し、同じ番号空間を「シーケンス番号」フィールドと共有する。
【００８５】
ＲＴＰヘッダの後にＭＰＦヘッダが続く。唯一の例外は、付加のみを含むトランスポート・パケットである。この場合、ＭＰＦヘッダは存在しない。トランスポート・パケットが複数のＭＡＵからのデータを含むならば、ＭＰＦヘッダは各ＭＡＵの前に、及び各断片化された（部分的）ＭＡＵの前に現れる。こうして、このペイロード・フォーマットを用いるトランスポート・パケットは１つ以上のＭＰＦヘッダを含む。ＭＰＦヘッダのレイアウトは図７に図示されている。ＭＰＦヘッダが標準の１２バイトＲＴＰヘッダに直接従うならば、ＭＰＦヘッダは「ビット・フィールド１」と呼ばれる１バイト・フィールドで始まり、その後に一連のオプションのフィールドが続く。ヘッダの後にペイロードが続く。ペイロードは完全なＭＡＵ又は断片の（部分的な）ＭＡＵを含む。
【００８６】
第１のデータ・ペイロードの後に、他のＭＰＦヘッダが現れ、その後に他のデータ・ペイロードが続く。データ・ペイロードの後に他のＭＰＦヘッダを追加するプロセスは複数回反復される。各ＭＰＦヘッダは、「ビット・フィールド２」を持つ第１のデータ・ペイロードの後に続く。
【００８７】
以下は、フィールド「ビット・フィールド１」のレイアウトを説明している。即ち、
・  「送出時間存在」（ＳＴ）ビット：このビットが１であれば、３２ビットの「送出時間」フィールドが「ビット・フィールド１」の直後に挿入される。
【００８８】
・  「対応存在」（ＣＰ）ビット：このビットが１であれば、９６ビットの「対応」フィールドが「送出時間」フィールドの後に挿入される。
・  Ｒ１、Ｒ２、Ｒ３（それぞれ１ビット）：１にセットされているこれらのビットのそれぞれに対して、受信側は「対応」フィールドと「ビット・フィールド２」との間に３２ビットのフィールドが挿入されたと仮定する。こうした３２ビットのフィールドの意味は本明細書では定義されない。３２ビットのフィールドの意味を知らない受信側はこのフィールドを無視する。
【００８９】
・  Ｒ４、Ｒ５（各１ビット）：現在はゼロにセットされており、将来の使用のために保留されている。
・  「ビット・フィールド２存在」（Ｂ２Ｐ）ビット：このビットが１であれば、１バイトの「ビット・フィールド２」フィールドが「対応」フィールドの後に挿入される。
【００９０】
・  「送出時間」フィールド：３２ビットである。このフィールドは、ＲＴＰヘッダにおける「タイムスタンプ」フィールドに対して用いられるのと同じ時間単位を用いて、トランスポート・パケットの送信時間を指定する。
【００９１】
・  「対応」フィールド：９６ビットである。このフィールドは２つのタイムスタンプを含む。ＮＴＰフォーマットにおける６４ビットのウォールクロック・タイムスタンプと３２ビットの復号時間タイムスタンプである。２つのフィールドは、ＲＦＣ−３５５０のセクション６．４．１で定義されているＲＴＣＰ送出者レポートにおける「ＮＴＰタイムスタンプ」と「ＲＴＰタイムスタンプ」と同じように使用される。
【００９２】
「ビット・フィールド１」が存在するとき、「ビット・フィールド２」はオプションである。「ビット・フィールド１」における「Ｂ２Ｐ」ビットは「ビット・フィールド２」が存在するかどうかを決定する。「ビット・フィールド２」に対する全部のビットのデフォルト値はゼロである。「断片化」フィールド（Ｆ）はデータ・ペイロードが部分的なＭＡＵを含むかどうかを示す。１つ以上のこうしたペイロードは結合されて完全なＭＡＵを再構成する。また、「Ｆ」フィールドはペイロードがＭＡＵの第１の又は最後の断片を含むかどうかを示す。以下の「Ｓ」、「Ｄ１」及び「Ｄ２」ビットは、「Ｆ」フィールドの値がゼロ又は３のときにのみ有効である。
【００９３】
表２はＦフィールド値の例示の意味を示す。
【００９４】
【表２】
2009505515.tif 000004
【００９５】
「オフセット存在」（ＯＰ）ビット：このビットが１であれば、１６ビットの「オフセット」フィールドは「ビット・フィールド２」の直後に挿入される。「オフセット」フィールドはそのときのペイロードの末尾を見つけるのに使われる。「ビット・フィールド２」で始まる別のＭＰＦヘッダは、そのときのペイロードの末尾の後に続く。「オフセット存在」ビットがゼロであれば、「オフセット」フィールドは存在しない。ＭＰＦがＲＴＰとともに使用されるとき、そのときのペイロードはトランスポート・パケットの末尾まで延び、ＲＴＰヘッダにおける「付加」ビットが１であればＲＴＰ付加領域の先頭まで延びる。
【００９６】
「同期点」ビット（Ｓ）：このビットは、ＭＡＵが同期点ＭＡＵであるとき、１にセットされる。
「不連続」ビット（Ｄ１）：このビットは１にセットされて、トランスポート・パケットのシーケンス番号（例えば、ＲＴＰが用いられるならばＲＴＰシーケンス番号）が「ギャップ」を示していないとしても、１つ以上のＭＡＵが失われていることを示す。
【００９７】
「削除可能」ビット（Ｄ２）：このビットが１であり、幾つかのＭＡＵを削除することが必要であれば、このＭＡＵは、ゼロにセットされたＤ２ビットを有するＭＡＵよりも小さな悪影響で削除される。
【００９８】
「暗号化」ビット（Ｅ）：このビットは１にセットされて、ペイロードが暗号化されたデータを含むことを示す。このビットは、ペイロードが暗号化されたデータを含まないならばゼロでなければならない。
【００９９】
「ビット・フィールド３存在」（Ｂ３Ｐ）ビット：このビットが１であれば、１バイトの「ビット・フィールド３」フィールドが「長さ」フィールドの後に挿入される。
「オフセット」：１６ビットのフィールドであり、そのときのペイロードの末尾に対するオフセット（「オフセット」フィールドに続く第１のバイトから計数される）をバイトで指定する。換言すると、「オフセット」フィールドの値は「ＭＡＵタイミング」セクションのサイズとそのときのペイロードのサイズとの和である。
【０１００】
「ビット・フィールド２」における「Ｂ３Ｐ」ビットの値は「ビット・フィールド３」が存在するかどうかを決定する。「ビット・フィールド３」における全部のビットに対するデフォルト値はゼロである。
【０１０１】
図１２は、ＭＰＦにおけるビット・フィールド３の例示のレイアウトを示している。即ち、
「復号時間存在」ビット（Ｄ３）：このビットが１であれば、３２ビットの「復号時間」フィールドが「ビット・フィールド３」の後で「プレゼンテーション時間」フィールドの前に挿入される。
【０１０２】
「プレゼンテーション時間存在」ビット（Ｐ）：このビットが１であれば、３２ビットの「プレゼンテーション時間」フィールドが「復号時間」フィールドの後で「ＮＰＴ」フィールドの前に挿入される。
【０１０３】
「ＮＰＴ存在」ビット（Ｎ）：このビットが１であれば、６４ビットの「ＮＰＴ」フィールドが「プレゼンテーション時間」フィールドの直後に挿入される。
Ｒ６、Ｒ７、Ｒ８、Ｒ９：１にセットされたこれらのビットのそれぞれに対して、受信側は３２ビットのフィールドが「ＮＴＰ」フィールドと「拡張」フィールドとの間に追加されたと仮定する。こうした３２ビットのフィールドの意味は本明細書では定義されない。３２ビットのフィールドの意味を知らない受信側はこのフィールドを無視する。
【０１０４】
「拡張存在」ビット（Ｘ）：このビットが１であれば、可変サイズの「拡張」フィールドが「ＮＴＰ」フィールドの後に挿入される。
「復号時間」：３２ビットのフィールドである。このフィールドはＭＡＵの復号時間を指定する。ＲＴＰが用いられるとき、このフィールドは、ＲＴＰヘッダにおける「タイムスタンプ」フィールドに対して用いられるのと同じ時間単位を用いてＭＡＵの復号時間を指定する。
【０１０５】
「プレゼンテーション時間」：３２ビットのフィールドである。このフィールドはＭＡＵのプレゼンテーション時間を指定する。
「ＮＰＴ」フィールド：６４ビットのタイムスタンプである。ＮＰＴフィールドは、ＭＡＵが所属するノーマル・プレイ時間タイムスタンプにおける位置を指定する。
【０１０６】
図１３は、１つの実施の形態に係る、ＭＰＦヘッダの拡張フィールドの例示のレイアウトを示している。「拡張」フィールドはフィールドの１つ以上の集合を含む。図１３は、こうした１つの集合に含まれるフィールドのレイアウトを示している。即ち、
「Ｌ」ビット：このビットが１であれば、これは「拡張」フィールドの再度の集合であることを示す。このビットがゼロであれば、「拡張データ」フィールドの末尾の後に「拡張」フィールドの少なくとも１つの集合が続く。
【０１０７】
「拡張型式」：「拡張データ」フィールドのコンテンツを識別するために用いられる７ビットのフィールドである。加えて、値ゼロ及び１２７は将来の使用のために保留されている。
【０１０８】
「拡張の長さ」：このフィールドの直後に現れる「拡張データ」フィールドのサイズをバイトで与える８ビットの数である。
「拡張データ」：可変長のフィールドである。このフィールドのサイズは「拡張の長さ」フィールドによって与えられる。
【０１０９】
「拡張」フィールドにおける諸フィールドは、初期化ベクトル拡張が用いられるとき、以下の値を持つ。即ち、
・  「拡張型式」：この値は２である。
【０１１０】
・  「拡張の長さ」：「拡張データ」フィールドのサイズであり、バイトで表される。
・  「拡張データ」：そのときのＭＡＵに対する初期化ベクトルの一部として用いられる、一連の１以上のバイトである。この拡張が存在すると、暗号化単位は完全なＭＡＵである。ＭＡＵが複数のペイロードへ断片化されると、初期化ベクトル拡張は第１のペイロードにのみ存在する。
【０１１１】
「拡張」フィールドにおけるフィールドは、キーＩＤ拡張が用いられるとき、以下の値を持つ。即ち、
・  「拡張型式」：この値は３である。
【０１１２】
・  「拡張の長さ」：「拡張データ」フィールドのサイズであり、バイトで表される。
・  「拡張データ」：そのときのペイロードを復号化するために用いられる復号化キーを識別する、一連の１以上のバイトである。
【０１１３】
キーＩＤ拡張は、別のキーＩＤ拡張によって置換されるまで有効である。したがって、拡張が用いられるのは、先のペイロードの復号化キーとは異なる復号化キーの使用をペイロードが必要とするときのみである。しかし、先のペイロードが、失われたトランスポート・パケットに含まれていたならば、受信側は復号化キーの変更の必要性に気付かない。ペイロードが誤ったキーによって復号化され、この状況が検知されないならば、レンダリング上の不所望な誤差を生じることになる。
【０１１４】
この問題の重大性を低減する１つのアプローチは、同期点であるＭＡＵ毎の第１のペイロードに対するキーＩＤ拡張を指定することである。これは、受信側が次の同期点ＭＡＵを受信するまで、失われたＭＡＵによって受信側は全部のＭＡＵを廃棄させられることが分かっている場合には優れた解法である。より堅実な解法は、複数ペイロードのトランスポート・パケットのそれぞれにおける第１のペイロードに対してキーＩＤ拡張を指定することである。この解法はパケットの喪失に対して堅固である。これは、独立したペイロードが単一のトランスポート・パケット内に含まれるからである。
【０１１５】
ＭＰＥＧビデオ・ヘッダが存在するとき、これらヘッダはその後のフレームに先行する。具体的には、
・  MPEG_Video_Sequence_Hederは、存在するとき、ＭＡＵの先頭にある。
【０１１６】
・  MPEG GOP_headerは、存在するとき、ＭＡＵの先頭にあり又はVideo_Sequence_Headerに続く。
・  MPEG Picture_Header  GOP_headerは、存在するとき、ＭＡＵの先頭にあり又はGOP_headerに続く。
【０１１７】
ＲＦＣ２２５０とは違って、ビデオを含むＭＡＵが断片化されると、スライス境界において断片化を実行する必要性はない。
ＭＡＵは、異なる理由で、複数のトランスポート・パケットにわたって断片化される。例えば、ＭＡＵは、トランスポート・パケットのサイズに制約が存在するとき、及び、ＭＡＵの特定の部分に対する暗号化パラメータに差が存在するときに断片化される。ＲＴＰヘッダ・フィールドが解釈されるとき、ＲＴＰヘッダにおける「タイムスタンプ」フィールドは９０ｋＨｚの精度でサンプルのＲＴＰにセットされ、「ペイロード型式」（ＰＴ）フィールドは帯域外の交渉機構（例えば、ＳＤＰを用いる）にしたがってセットされる。ＭＰＦのパケット仕様情報セクションに関しては、「送出時間」フィールドの存在はオプションであり、「対応」フィールドの存在はオプションであり、「ビット・フィールド２存在」ビット（Ｂ２Ｐ）は、暗号化されたＭＡＵの一部又は暗号化されたＭＡＵの断片をペイロードが含む場合にセットされる。
【０１１８】
上記に鑑みて、ＭＰＦは、異なる暗号化パラメータによって単一のＭＡＵを暗号化することができるようにする。これは、単一のＭＡＵの断片を暗号化し、他の断片を明文のままとする能力を含む。こうした場合、ＭＡＵは異なる暗号化パラメータによって複数のペイロードへ断片化される。例えば、ＭＡＵ又は暗号化されたＭＡＵの断片は、以下の基準に基づく値とフィールド・セットとを有する。即ち、
・  パケット情報セクションにおける「ビット・フィールド２存在」ビット（Ｂ２Ｐ）は１にセットされて、「ビットのフィールド２」が存在することを示す。
【０１１９】
・  ＭＡＵ特性セクションにおける「暗号化」ビット（Ｅ）は１にセットされて、ペイロードが暗号化されることを示す。
・  「ＭＡＵタイミン」セクションにおける「拡張存在」ビット（Ｘ）は１にセットされて、拡張フィールドの存在を示す。
【０１２０】
・  「初期化ベクトル」拡張が含まれ、以下の値がセットされる。
ｏ  「拡張型式」は２にセットされる。
ｏ  「拡張の長さ」は、「拡張データ」フィールドがデータ・セグメントＩＤのみを含む場合には８（６４ビットを意味する）にセットされ、「拡張データ」フィールドがデータ・セグメントＩＤとブロックＩＤとを含む場合には１６（１２８ビットを意味する）にセットされる。
【０１２１】
ｏ  初期ブロックＩＤがゼロの場合には、「拡張データ」は上記のようにデータ・セグメントＩＤ値でセットされる。初期ブロックＩＤがゼロ以外であれば、「拡張データ」は初期ブロックＩＤが後続するデータ・セグメントＩＤにセットされる。
【０１２２】
ｏ  この拡張はＭＡＵの各暗号化されたペイロード毎に含まれる。
・  「キーＩＤ」拡張が含まれ、以下の値がセットされる。
ｏ  「拡張型式」は３にセットされる。
【０１２３】
ｏ  「拡張の長さ」は１６（１２８ビットを意味する）にセットされる。
ｏ  「拡張データ」は、このＭＡＵに対応するライセンスからのキーＩＤ値でセットされる。
【０１２４】
「初期化ベクトル」拡張及び「キーＩＤ」拡張は、複数のＭＡＵを含む複数ペイロードのトランスポート・パケットのそれぞれにおける新たなＭＡＵの第１のペイロードに対して含まれる。これにより、たとえ幾つかのトランスポート・パケットが失われた場合であっても受信側はそのときのキーＩＤを知ることが保証される。
【０１２５】
ＭＡＵ特性セクションは以下のとおりに解釈される。即ち、
・  「同期点」ビット（Ｓ）は、ＭＡＵがビデオＩ−フレーム又はオーディオ・フレームを含むときにセットされる。
【０１２６】
・  「不連続生」ビット（Ｄ１）は、１つ以上のＭＡＵが失われているとき、例えば、フレーム削除トランスレータによってビデオ・フレームが削除されたとき、セットされる。
【０１２７】
・  「削除可能」ビット（Ｄ２）の利用はオプションである。これをどの場合に使用すべきかの定義は本明細書の範囲外である。
・  「暗号化」ビット（Ｅ）は、暗号化されたＭＡＵの一部又は暗号化されたＭＡＵの断片をペイロードが含む場合にセットされる。
【０１２８】
ＭＡＵタイミング・セクションは以下のように解釈される。即ち、
・  「復号時間」フィールドはオプションである。用いられると、このフィールドはＭＡＵのＤＴＳを含む。
【０１２９】
・  「プレゼンテーション時間」フィールドはオプションである。
・  「ＮＰＴ」フィールドはオプションである。
ｏ  「拡張存在」ビット（Ｘ）は、１つ以上の拡張ヘッダが存在するときにセットされる。
【０１３０】
例示の手順
図１４は、１つの実施の形態に係る、ＥＳコンテンツを保護するための例示の手順１４００を示している。例示的な説明の目的で、手順１４００の動作は、図１の１つ以上のＥＳ保護モジュール１１２、マッピング・モジュール１１４、図２のトランスポート・ストリーム・スクランブリング・モジュール２１０及び／又はデマルチプレックス・パッケージング・モジュール２１２によって実施される。当業者には、動作順序の変更及び修正を含む、本記述からの変更及び修正は明らかであろう。
【０１３１】
図１４を参照すると、コンピュータ装置１０２又はコンテンツ・ソース２０２によって、基本ストリーム（ＥＳ）が受信され又はアクセスされる。アクセスされたＥＳはトランスポート・ストリームから独立であり、又はトランスポート・ストリームによって運ばれる。ブロック１４１０において、手順１４００はＥＳのＭＡＵ部分を保護する。１つの実現例においては、こうした保護動作は共通スクランブリングとは独立に実施される。他の実現例においては、こうした保護動作は共通スクランブリングを用いて、例えば、トランスポート・ストリームを共通にスクランブリングするときに実施される。ブロック１４１５において、トランスポート・ストリームがブロック１４０５においてアクセスされたならば、元の暗号化が維持されるようにトランスポート・ストリームはＥＳへデマルチプレックスされる。モジュール２１２のデマルチプレックス動作は、トランスポート・ストリームのデマルチプレックス動作を実施する例示のコンポーネントを示している。
【０１３２】
ブロック１４２０において、手順１４００は保護済みＥＳをＭＡＵペイロード・フォーマット（ＭＰＦ）へマッピングする。各ＭＡＵをＭＰＦへマッピングすると、マッピングされたＥＳをカプセル化するトランスポート・パケットを受信するメディア消費者には、それぞれのＥＳを他の任意のＥＳから独立に処理するとともに各ＭＡＵを他の任意のＭＡＵから独立に処理することができるに足る情報が提供される。ブロック１４３０において、手順１４００は、ＭＰＦへマッピングされたＥＳをトランスポート・プロトコルへカプセル化する。１つの実現例においては、トランスポート・プロトコルはリアルタイム・トランスポート・プロトコル（ＲＴＰ）である。ブロック１４４０において、手順１４００はトランスポート・プロトコルに基づくトランスポート・パケットを、処理のためにメディア消費者へ伝達する。復号化を含む、こうした処理により、メディア消費者はトランスポート・パケットに含まれるペイロード・データを経験することができる。
【０１３３】
結論
ＥＳコンテンツの保護について、構造的特徴及び／又は方法論的動作又は行為に特有の言語で説明してきたが、理解されるように、特許請求の範囲において定義されている実現例は、上記の特有の特徴又は動作を限定するものではない。特定の特徴及び動作は、特許請求された主題を実現するための例示の形態として開示されている。
【図面の簡単な説明】
【０１３４】
【図１】１つの実施の形態に係る、ＥＳコンテンツを保護するための例示のコンピュータ・システムを示す図である。
【図２】１つの実施の形態に係る、トランスポート・ストリームによって運ばれるＥＳコンテンツを保護するための例示の実施の形態が実施される例示のネットワーク環境を示す図である。
【図３】ＥＳメディア・コンテンツを暗号化するための、カウンタ・モードでの改良型暗号化標準を用いた動作の例示的な態様を示す図である。
【図４】１つの実施の形態に係る、トランスポート・ストリームへ保護済みＥＳコンテンツとともに挿入される例示の暗号化方法（ＴＡＧ）パケットを示す図である。
【図５】１つの実施の形態に係る、トランスポート・ストリーム内のＥＳを保護するための送信側の例示の手順を示す図である。
【図６】１つの実施の形態に係る、例示の共通スクランブリングされたトランスポート・ストリームを示す図である。
【図７】１つの実施の形態に係る、メディア・アクセス・ユニット（ＭＡＵ）・ペイロード・フォーマット（ＭＰＦ）の例示のハイレベル構造を示す図である。
【図８】１つの実施の形態に係る、図７のＭＰＦヘッダの例示の詳細を示す図である。
【図９】１つの実施の形態に係る、ＭＰＦを使用する３つのリアルタイム・トランスポート・パケット（ＲＴＰ）の例示のシーケンスを示す図である。
【図１０】１つの実施の形態に係る、単一のメディア・アクセス・ユニット（ＭＡＵ）が同じＲＴＰパケットにおける３つの断片へ分割される例を示す図である。
【図１１】標準の１２バイトのＲＴＰヘッダを示す図である。
【図１２】ＭＰＦのビット・フィールド３の例示のレイアウトを示す図である。
【図１３】１つの実施の形態に係る、ＭＰＦヘッダの拡張フィールドの例示のレイアウトを示す図である。
【図１４】１つの実施の形態に係る、ＥＳコンテンツを保護するための例示の手順を示す図である。
【図１】
2009505515.tif 000005
【図２】
2009505515.tif 000006
【図３】
2009505515.tif 000007
【図４】
2009505515.tif 000008
【図５】
2009505515.tif 000009
【図６】
2009505515.tif 000010
【図７】
2009505515.tif 000011
【図８】
2009505515.tif 000012
【図９】
2009505515.tif 000013
【図１０】
2009505515.tif 000014
【図１１】
2009505515.tif 000015
【図１２】
2009505515.tif 000016
【図１３】
2009505515.tif 000017
【図１４】
2009505515.tif 000018
【国際調査報告】
2009505515.tif 000019
2009505515.tif 000020