(57)【要約】【課題】受信側に対して同期送信するために暗号化済みコンテンツにタイトル鍵を添付する方法、システム、およびプログラム製品を提供すること。【解決手段】受信側への同期送信または受信側による保管のために、暗号化済みコンテンツにタイトル鍵を添付する方法およびシステムを提供する。具体的には、本発明の下で、基本メディア・ストリームが、それぞれがコンテンツ・パケットおよびヘッダを含むコンテンツ・ユニットに区分される。コンテンツ・パケットは、１つまたは複数のタイトル鍵を用いて暗号化される。コンテンツ・パケットが暗号化された後に、タイトル鍵自体が、鍵暗号化鍵を用いて暗号化される。その後、暗号化済みタイトル鍵が受信側に対して同期送信するために、対応する暗号化済みコンテンツ・パケットに添付される。【選択図】　図１
2004048676.tif 000002
【特許請求の範囲】
【請求項１】
受信側に対して同期送信するために、暗号化済みコンテンツにタイトル鍵を添付する方法であって、
タイトル鍵を用いてコンテンツを暗号化するステップと、
鍵暗号化鍵を用いてタイトル鍵を暗号化するステップと、
受信側に対して同期送信するために、前記暗号化済みコンテンツに前記暗号化済みタイトル鍵を添付するステップと
を含む方法。
【請求項２】
前記暗号化済みコンテンツおよび前記添付された暗号化済みタイトル鍵を受信側に同期送信するステップをさらに含む、請求項１に記載の方法。
【請求項３】
基本コンテンツ・ストリームを受け取るステップと、
前記コンテンツを暗号化する前に、前記基本コンテンツ・ストリームをコンテンツ・ユニットに区分するステップであって、各コンテンツ・ユニットが、コンテンツおよびヘッダを含む、ステップと
をさらに含む、請求項１に記載の方法。
【請求項４】
前記コンテンツを暗号化する前に、前記コンテンツから前記ヘッダを構文解析するステップをさらに含む、請求項３に記載の方法。
【請求項５】
識別子情報およびベリファイヤを前記暗号化済みコンテンツに添付するステップをさらに含む、請求項１に記載の方法。
【請求項６】
前記ベリファイヤが、前記タイトル鍵を用いて暗号化された既知の値を含む、請求項５に記載の方法。
【請求項７】
前記識別子情報が、予約されたビット・パターンのエイリアシングを防ぐ、請求項５に記載の方法。
【請求項８】
受信側に対して同期送信するために、暗号化済みコンテンツにタイトル鍵を添付する方法であって、
コンテンツ・パケットおよびヘッダを含むコンテンツ・ユニットを提供するステップと、
タイトル鍵を用いて前記コンテンツ・パケットを暗号化するステップと、
鍵暗号化鍵を用いて前記タイトル鍵を暗号化するステップと、
前記暗号化済みタイトル鍵を含むヘッダ拡張を前記暗号化済みコンテンツ・パケットに添付するステップと、
前記ヘッダ、前記ヘッダ拡張、および前記暗号化済みコンテンツを受信側に同期送信するステップと
を含む方法。
【請求項９】
前記ヘッダ拡張が、さらに、ベリファイヤおよび識別子情報を含む、請求項８に記載の方法。
【請求項１０】
前記ベリファイヤが、前記タイトル鍵を用いて暗号化された既知の値を含む、請求項９に記載の方法。
【請求項１１】
前記受信側が、前記暗号化済みコンテンツおよび前記ヘッダ拡張を保管するステップと、
前記受信側が、鍵管理ブロックを使用して前記鍵暗号化鍵を判定するステップと、
前記受信側が、前記鍵暗号化鍵を用いて前記タイトル鍵を解読するステップと、
前記受信側が、前記タイトル鍵を用いて前記既知の値を解読するステップと、
前記受信側が、前記コンテンツ・パケットを解読するステップと
をさらに含む、請求項１０に記載の方法。
【請求項１２】
受信側に対して同期送信するために、暗号化済みコンテンツにタイトル鍵を添付するシステムであって、
タイトル鍵を用いてコンテンツ・パケットを暗号化するシステムと、
鍵暗号化鍵を用いて前記タイトル鍵を暗号化するシステムと、
前記暗号化済みコンテンツ・パケットに、前記暗号化済みタイトル鍵を含むヘッダ拡張を添付するシステムと
を含むシステム。
【請求項１３】
前記暗号化済みコンテンツおよび前記添付されたヘッダ拡張を受信側に同期送信するシステムをさらに含む、請求項１２に記載のシステム。
【請求項１４】
前記ヘッダ拡張が、さらに、識別子情報およびベリファイヤを含む、請求項１２に記載のシステム。
【請求項１５】
前記ベリファイヤが、前記タイトル鍵を用いて暗号化された既知の値を含む、請求項１４に記載のシステム。
【請求項１６】
前記識別子情報が、予約されたビット・パターンのエイリアシングを防ぐマスク値を含む、請求項１４に記載のシステム。
【請求項１７】
受信側に対して同期送信するために、暗号化済みコンテンツにタイトル鍵を添付する、記録可能媒体に保管されたプログラムであって、該プログラムがコンピュータに、
タイトル鍵を用いてコンテンツ・パケットを暗号化する機能と、
鍵暗号化鍵を用いて前記タイトル鍵を暗号化する機能と、
前記暗号化済みタイトル鍵を含むヘッダ拡張を前記暗号化済みコンテンツ・パケットに添付する機能と
を実現させるプログラム。
【請求項１８】
前記ヘッダ拡張および前記暗号化済みコンテンツを受信側に同期送信する機能をさらに含む、請求項１７に記載のプログラム。
【請求項１９】
前記ヘッダ拡張が、さらに、識別子情報およびベリファイヤを含む、請求項１７に記載のプログラム。
【請求項２０】
前記ベリファイヤが、前記タイトル鍵を用いて暗号化された既知の値を含み、前記識別子情報が、予約されたビット・パターンのエイリアシングを防ぐマスク値を含む、請求項１９に記載のプログラム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、一般に、受信側に対して同期送信するために、暗号化済みコンテンツにタイトル鍵を添付する方法、システム、およびプログラム製品に関する。具体的には、コンテンツの暗号化に使用されたタイトル鍵自体が暗号化され、暗号化済みコンテンツに添付され、その結果、両方を受信側に同期送信することができる。
【０００２】
【従来の技術】
デジタル信号の送信では、ビデオ・データおよびオーディオ・データなどのコンテンツが、信号ソースから受信器にしばしば送信される。しかし、そのようなコンテンツを送信する際には、そのセキュリティを保証しなければならない。一般に、コンテンツのセキュリティは、鍵を用いてコンテンツを暗号化し、次いで、暗号化済みコンテンツを受信器に送信することによって実現される。準拠している場合に、受信器は、コンテンツを受信し、解読することができる。この形でコンテンツを保護する際に、複数の鍵を使用することができる。たとえば、第１のコンテンツ・パケットを、第１の鍵を用いて暗号化することができ、第２のコンテンツ・パケットを、第２の鍵を用いて暗号化することができる。複数の鍵を使用することによって、コンテンツ・ストリーム全体を単一の鍵によってアクセスできなくすることによって、セキュリティが強化される。しかし、そのようなシナリオでは、暗号化済みコンテンツと対応する鍵との同期を維持することが必須である。すなわち、受信器は、コンテンツを正しい鍵と一致させることができなければならない。一致が維持されない場合には、不正な鍵が使用される可能性があり、コンテンツを解読できない。
【０００３】
鍵に基づくセキュリティの実施を利用する現在の技術には、パーソナル・コンピュータに基づくデジタル著作権管理システム（ＤＲＭＳ）および限定受信システム（ＣＡＳ）が含まれる。前者の場合に、コンテンツは、パッケージ化され、ウェブ・サーバにロードされる。コンテンツの暗号化／解読に使用される鍵は、パーソナル・コンピュータにダウンロードされるが、コンテンツの一体化された部分としてダウンロードされるのではない。そうではなく、ダウンロード時またはレンダリング時のいずれかに、受信器が、ライセンス・サーバにアクセスして、コンテンツおよび対応する使用法規則の説明にアクセスする許可を受け取る。
【０００４】
テレビジョンに基づくＣＡＳでは、コンテンツおよび鍵が、適当な加入者情報に基づいてヘッドエンド・サーバで作成される。暗号化済みコンテンツおよび鍵は、さまざまなビット・フラグを介して互いに同期化されなければならない別々のデータ・エンティティとして、多重化されたストリームで配信される。レンダリング時に、受信器は一般に、ローカル・スマート・カード・プロセッサを使用してコンテンツにアクセスする許可を受け、その結果、サーバとの直接通信が不要になる。したがって、ＣＡＳでは、ビット・フラグに依拠して鍵と暗号化済みコンテンツを同期化する。さらに、ＣＡＳでは、一般に、交互する鍵（奇数および偶数と称する）が使用される。すなわち、コンテンツのスクランブル解除は、鍵対の受取から開始される。第１の鍵（たとえば偶数）は、所定の期間にコンテンツを解読するのに使用され、その後に、第２の鍵が使用される。第２の鍵が使用され始めた時に、新しい鍵対を受信器に送信することができる。しかし、この形で受信器に別の鍵セットを送信する際に、コンテンツと鍵の同期が失われる危険性がある。さらに、ＤＲＭＳもＣＡＳも、保護されたコンテンツのランダム・アクセスを提供する際に固有の待ち時間を有する可能性がある。
【０００５】
前述に鑑みて、受信器に対して同期送信する、または受信器によって保管するために、暗号化済みコンテンツに鍵を添付する方法、システム、およびプログラム製品が必要とされている。すなわち、コンテンツの暗号化に使用された鍵自体を暗号化し、コンテンツの一体化された部分として送信することが必要とされている。暗号化済みコンテンツの一体部分として暗号化された鍵を送信することによって、受信器が、暗号化済みコンテンツならびにそのコンテンツを解読するのに必要なすべての情報を単一のストリームで受信する。さらに、暗号化された鍵および暗号化済みコンテンツを単一のストリームとして送信することによって、既存のフロントエンド規格およびバックエンド規格との互換性およびそれらへの準拠が維持される。さらに、受信器への同期式送信（および受信器による保管）は、コンテンツへのランダム・アクセスに好都合である。
【０００６】
【発明が解決しようとする課題】
一般に、本発明は、受信側に対して同期送信するために暗号化済みコンテンツにタイトル鍵を添付する方法、システム、およびプログラム製品を提供する。具体的には、本発明の下で、コンテンツ・パケットおよびヘッダを含むコンテンツ・ユニットが、受信され、構文解析される。タイトル鍵は、コンテンツ・パケットを暗号化するのに使用される。コンテンツ・パケットを暗号化した後に、タイトル鍵自体を、鍵暗号化鍵を用いて暗号化する。その後、暗号化済みタイトル鍵が、受信器に対して同期送信する、または受信器によって保管するために、コンテンツ・パケットおよびヘッダに添付される。
【０００７】
【課題を解決するための手段】
本発明の第１の態様によれば、受信側に対して同期送信するために、暗号化済みコンテンツにタイトル鍵を添付する方法が提供される。この方法は、（１）タイトル鍵を用いてコンテンツを暗号化するステップと、（２）鍵暗号化鍵を用いてタイトル鍵を暗号化するステップと、（３）受信側に対して同期送信するために、前記暗号化済みコンテンツに前記暗号化済みタイトル鍵を添付するステップとを含む。
【０００８】
本発明の第２の態様によれば、受信側に対して同期送信するために、暗号化済みコンテンツにタイトル鍵を添付する方法が提供される。この方法は、（１）コンテンツ・パケットおよびヘッダを含むコンテンツ・ユニットを提供するステップと、（２）タイトル鍵を用いて前記コンテンツ・パケットを暗号化するステップと、（３）鍵暗号化鍵を用いて前記タイトル鍵を暗号化するステップと、（４）前記暗号化済みタイトル鍵を含むヘッダ拡張を前記暗号化済みコンテンツ・パケットに添付するステップと、（５）前記ヘッダ、前記ヘッダ拡張、および前記暗号化済みコンテンツを受信側に同期送信するステップとを含む。
【０００９】
本発明の第３の態様によれば、受信側に対して同期送信するために、暗号化済みコンテンツにタイトル鍵を添付するシステムが提供される。このシステムは、（１）タイトル鍵を用いてコンテンツ・パケットを暗号化するシステムと、（２）鍵暗号化鍵を用いてタイトル鍵を暗号化するシステムと、（３）前記暗号化済みコンテンツ・パケットに、前記暗号化済みタイトル鍵を含むヘッダ拡張を添付するシステムとを含む。
【００１０】
本発明の第４の態様によれば、受信側に対して同期送信するために、暗号化済みコンテンツにタイトル鍵を添付する、記録可能媒体に保管されたプログラム製品が提供される。実行される時に、このプログラム製品は、（１）タイトル鍵を用いてコンテンツ・パケットを暗号化するプログラム・コードと、（２）鍵暗号化鍵を用いて前記タイトル鍵を暗号化するプログラム・コードと、（３）前記暗号化済みタイトル鍵を含むヘッダ拡張を前記暗号化済みコンテンツ・パケットに添付するプログラム・コードとを含む。
【００１１】
したがって、本発明は、受信側に対して同期送信するために暗号化済みコンテンツにタイトル鍵を添付する方法、システム、およびプログラム製品を提供する。
【００１２】
図面は、単に概略を表したものであって、本発明の特定のパラメータを表現することを意図されたものではない。図面は、本発明の通常の実施形態だけを示すことを意図され、したがって、本発明の範囲を制限するものとみなすべきではない。図では、同様の符号が同様の要素を表す。
【００１３】
【発明の実施の形態】
わかりやすくするために、本発明の詳細な説明は、次の２つのセクションを有する。
Ｉ．定義
ＩＩ．詳細な説明
【００１４】
Ｉ．定義
本明細書で使用される時に、下記の用語は、下記の定義を有する。
【００１５】
コンテンツ　デジタル・イメージ、サウンド、またはバイナリ・データなどの、ソースから受信側に配信可能なすべてのデータ。
【００１６】
コンテンツ所有者　映画スタジオなどの、コンテンツを所有する実体。
【００１７】
コンテンツ・サービス・プロバイダ　ケーブル・サービス・プロバイダなどの、コンテンツ所有者から消費者へコンテンツを配信する「パイプライン」を提供する実体。
【００１８】
受信器　セットトップ・ボックス、ＤＶＤプレイヤなどの、コンテンツ所有者、コンテンツ・サービス、または消費者家庭ネットワーク内の別の受信器から直接にコンテンツを受信する、消費者デバイス。
【００１９】
受信側　コンテンツ・サービス・プロバイダまたは受信器などの、送信を受信することができる実体。
【００２０】
ソース　コンテンツ所有者、コンテンツ・サービス・プロバイダ、または受信器（消費者家庭ネットワーク内）などの、送信を送ることができる実体。
【００２１】
タイトル鍵　コンテンツの暗号化に使用される鍵。
【００２２】
コンテンツ使用条件　コピー・コントロールなどの、コンテンツの使用または利用あるいはその両方を管理するガイドライン。
【００２３】
鍵暗号化鍵　タイトル鍵またはタイトル鍵とコンテンツ使用条件の組合せを暗号化するのに使用される鍵。
【００２４】
鍵管理ブロック（ＫＭＢ：Ｋｅｙ　Ｍａｎａｇｅｍｅｎｔ　Ｂｌｏｃｋ）　鍵暗号化鍵の複数の暗号化を含み、準拠しない装置を排除するデータ構造。ＫＭＢは、当技術分野で、セッション鍵ブロック、メディア鍵ブロック、鍵メディア・ブロック、または管理鍵ブロックとも称する。
【００２５】
ＩＩ．詳細な説明
本発明は、タイトル鍵（暗号化された）の送信または保管を、暗号化済みコンテンツと固有に同期化させる方法、システム、およびプログラム製品を提供する。具体的には、本発明の下で、コンテンツが、タイトル鍵を用いて暗号化される。その後、タイトル鍵が、鍵暗号化鍵を用いて暗号化され、ヘッダ拡張として暗号化済みコンテンツに添付される。この添付によって、タイトル鍵および暗号化済みコンテンツを、受信側に同期送信する、または受信側によって保管することができるようになる。前のシステムは、そのような同期送信ができなかった。さらに、暗号化済みコンテンツとタイトル鍵を同期送信することによって、本発明では、現在のフロントエンド規格およびバックエンド規格との互換性およびそれらへの準拠が維持される。
【００２６】
図１を参照すると、デジタル著作権管理システム（ＤＲＭＳ）の図が示されている。図からわかるように、コンテンツ１０が、アクセス権／コンテンツ使用条件１２と共にパッケージ化され、メディア・サーバ１４にロードされる。コンテンツにアクセスするのに使用される鍵は、コンテンツとは別のコンポーネントとしてＰＣ１８にダウンロードされる。具体的には、ダウンロード時またはレンダリング時のいずれかに、ライセンス・サーバ１６にアクセスして、コンテンツおよび対応する使用条件の説明へのアクセスの許可を受け取らなければならない。
ウェブ・サーバ２０は、メディア・サーバ１４のコンテンツにアクセスするステップを顧客に進ませるウェブ・ページを提供する。図からわかるように、コンテンツは、ストリーミング配信を介して（たとえばファイルが大きい場合に）配信される。
【００２７】
上で示したように、ＤＲＭＳは、コンテンツと、そのコンテンツを暗号化するのに使用された鍵との同期配信ができない。すなわち、ライセンス・サーバ１６に、別途アクセスしなければならない。そのような形で鍵を提供する時に、適当な鍵が暗号化済みコンテンツと一致しない、あるいは単一の鍵が使用され、セキュリティが弱まる可能性がある。さらに、ライセンス・サーバ１６から鍵を提供するために、バック・チャネルが必要である。
【００２８】
図２を参照すると、ケーブル・テレビジョン・システムまたは衛星テレビジョン・システムなどの限定受信システム（ＣＡＳ）が、詳細に示されている。ＣＡＳでは、２つの権利付与メッセージが、受信器５２８（たとえばセットトップ・ボックス）に配信される。第１のメッセージは、加入者がアクセスを許可されるサービス（たとえばどのチャンネルか）をリストする権利付与管理メッセージと称する。権利付与管理メッセージは、第２の権利付与メッセージより受信器５２８に配信される頻度が低いが、この第２の権利付与メッセージを、権利付与制御メッセージと称する。権利付与制御メッセージは、受信器５２８に頻繁に配信され、これには、スマート・カード５３４によって鍵に変換することができる制御ワードが含まれる。暗号化済みコンテンツの受信時に、権利付与管理メッセージから、加入者があるチャンネルへのアクセスを許可されることが示される場合に、権利付与制御メッセージ内の制御ワードが鍵に変換され、デスクランブラ５３６に渡される。鍵は、その後、デスクランブラ５３６によってコンテンツを解読するのに使用される。したがって、ＤＲＭＳに似て、ＣＡＳも、暗号化済みコンテンツと鍵の同期配信ができない。具体的には、図２からわかるように、コンテンツ５２２が、ヘッドエンド・サーバ５２４に提供され、鍵を使用して暗号化される。この鍵は、制御ワードに基づき、制御ワードは、制御ワード・ジェネレータ５３０を介して生成される。制御ワードは、通常は、加入者許可を示す加入者情報５２６に基づく。暗号化済みコンテンツおよび権利付与制御メッセージ（制御ワードを含む）が、マルチプレクサ５３２を介して多重化され、別々のデータ実体として受信器５２８に配信される。別々のデータ実体は、さまざまなビット・フラグを介して互いに同期化されなければならない。レンダリング時に、受信器５２８が、スマート・カード５３４を使用して、制御ワードを処理して、鍵に到達する。その後、デスクランブラ５３６が、その鍵を使用して、コンテンツを解読する。ＤＲＭＳに似て、ＣＡＳは、鍵と暗号化済みコンテンツの同期配信ができない。さらに、鍵と保護されたコンテンツの配信が、ＣＡＳでは同期化されないので、遅延などのある種の待ち時間が、コンテンツへのランダム・アクセスを得る試みに固有である。
【００２９】
図３を参照すると、タイトル鍵２４を使用するコンテンツ２２の暗号化が、詳細に示されている。図からわかるように、コンテンツ２２が、タイトル鍵２４を使用して暗号化されて、暗号化済みコンテンツ２６が作られる。その後、タイトル鍵２４自体が、鍵暗号化鍵２８を用いて暗号化される。その後、暗号化済みタイトル鍵３０を、暗号化済みコンテンツ２６と共に受信側に送信することができる。
【００３０】
図４に、暗号化済みタイトル鍵３０を、暗号化済みコンテンツ２６を再暗号化する必要なしに、異なる鍵暗号化鍵３２を用いて再暗号化できることを示す。図からわかるように、暗号化済みタイトル鍵３０が受信され、鍵暗号化鍵２８を用いて解読される。その後、タイトル鍵２４が、新しい鍵暗号化鍵３２を用いて再暗号化される。その後、再暗号化済みタイトル鍵３４が、乱されていない暗号化済みコンテンツ２６と共に送信される。タイトル鍵２４を再暗号化することによって、コンテンツ自体を再暗号化する必要なしにコンテンツの保護を変更することができ、コンテンツ自体の再暗号化は、タイトル鍵２４の再暗号化よりはるかに時間を消費するか、多くのリソースを消費するか、その両方である可能性がある。
【００３１】
鍵暗号化鍵２８が、一般に、鍵管理ブロック（ＫＭＢ）に基づいて決定され、ＫＭＢが、通常は、暗号化済みコンテンツ２６の配信と並行にまたはその前に（下で詳細に説明するように）受信側に配信されることを理解されたい。具体的には、上で定義されたように、ＫＭＢは、準拠する受信側によって回復可能な鍵暗号化鍵２８の複数の暗号化を含むデータ構造である。暗号化済みコンテンツが受信される時に、受信側は、前に提供された鍵（たとえば、装置鍵、コンテンツ所有者鍵、サービス・プロバイダ鍵など）を使用して、ＫＭＢを処理し、鍵暗号化鍵２８を回復する。たとえば、コンテンツがＤＶＤプレイヤによって受け取られる場合に、ＤＶＤプレイヤ内の内部装置鍵が、ＫＭＢ内の鍵暗号化鍵２８の暗号化の１つを解読するのに使用される。回復された後で、鍵暗号化鍵２８がタイトル鍵２４の回復に使用され、このタイトル鍵２４がコンテンツの解読に使用される。しかし、ＤＶＤプレイヤが既知の準拠しない装置または迂回装置である場合には、ＫＭＢがその装置を排除するように変更されているので、その内部装置鍵によって正しい鍵暗号化鍵２８を回復することはできない。したがって、正しいタイトル鍵を回復することができず、コンテンツを解読することができない。したがって、鍵暗号化鍵は、本来タイトル鍵より安全であり、頻繁に交換する必要がない。
【００３２】
上で示したように、ＫＭＢは、暗号化済みコンテンツにアクセスするのに必要なので、ＫＭＢを、暗号化済みコンテンツと同期して、またはその前に、配信しなければならない。この条件が満たされない場合には、暗号化済みコンテンツが受信される時と、それがアクセスされる時の間（たとえば、チャンネルが変更された時とイメージが表示される時の間）に遅延が生じる可能性がある。
【００３３】
ＫＭＢとコンテンツの同期配信を容易にするために、多数の技法を実施することができる。一例では、ＫＭＢを、別々のストリームに含めることができる。これによって、タイム・スタンプまたは類似物を挿入し、その結果、ＫＭＢのタイミングを、コンテンツの配信と調整できるようになる。そのような技法を用いると、コンテンツのアクセスに必要なすべての情報を、システム要件に基づいて、異なる形で多重化することができるストリームの集合に含めることができるようになる。
【００３４】
同期でのわずかな差に対処するために、受信器が、メモリ内で複数のＫＭＢ（または対応する鍵暗号化鍵）をキャッシュに入れることができる。たとえば、２つの鍵暗号化鍵をキャッシュに入れることができる。第１の鍵は、現在受信されつつあるコンテンツに対応し、第２の鍵は、まだ到着し始めていないコンテンツに対応する。第２の鍵は、暗号化済みコンテンツの前に送信されたＫＭＢの処理から生じる。複数の鍵暗号化鍵のどれを使用するかを決定するために、複数の代替案を実施することができる。第１の代替案では、バージョン番号を、ヘッダ内のプライベート・データ・フィールドに含める。第２の代替案では、ベリファイヤを使用することができる。しかし、後者の場合に、複数の鍵暗号化鍵をキャッシュに入れるならば、複数の検証が必要になる可能性がある。
【００３５】
どの場合でも、本発明は、ＫＭＢの不要な処理を避ける能力も有することができる。具体的には、受信器への送信の前に、ＫＭＢの前にハッシュを付加することができる。ＫＭＢの受信時に、受信器が、対応するハッシュと既に処理された／キャッシュに入れられたＫＭＢのハッシュとを比較し、その結果、新しいハッシュを有するＫＭＢだけが処理されるようにする。したがって、既存のＫＭＢを、同一の受信器が複数回処理する必要がなくなる。
【００３６】
図５を参照すると、流れ図に、コンテンツ使用条件３６のタイトル鍵２４へのバインディングが示されている。図からわかるように、コンテンツ使用条件３６が提供される（たとえば、コンテンツ所有者などのコンテンツ・ソースによって）。その後、コンテンツ使用条件３６が、ダイジェスト３８（たとえばハッシュ）に圧縮され、このハッシュが、タイトル鍵２４と組み合わされて（たとえば排他論理和演算を介して）、組合せ４０が作られる。その後、結果の組合せ４０が、鍵暗号化鍵２８を用いて暗号化されて、暗号化された組合せ４２が作られる。
暗号化された時に、暗号化された組合せ４２を、暗号化されないコンテンツ使用条件３６と共に受信側に送信することができる。暗号化された組合せ４２が、メッセージ確認コード（ＭＡＣ）と見なされることを理解されたい。しかし、ＭＡＣの多数の変形形態が、既知であり、本発明の下で実施できることを、さらに理解されたい。たとえば、ＭＡＣを、鍵暗号化鍵２８を用いて暗号化されるダイジェスト３８のみとすることができる。
【００３７】
図６に、受信側（たとえばコンテンツ・サービス・プロバイダまたは消費者）による受信の後の図５の送信を示す。図からわかるように、受信側は、暗号化された組合せ４２（すなわちＭＡＣ）およびコンテンツ使用条件３６をソースから受信する。鍵管理ブロック（ＫＭＢ）（たとえば有効な装置鍵）を処理することによって、鍵暗号化鍵２８が回復される。鍵暗号化鍵２８を決定した後に、暗号化された組合せ４２を解読することができる。その後、受信されたコンテンツ使用条件３６を使用して、ダイジェスト３８を再作成し、タイトル鍵２４を回復する。具体的には、ダイジェスト３８を再作成した時に、組合せ４０内にダイジェストされたコンテンツ使用条件が、タイトル鍵２４を得るために「除去」される（たとえば、逆排他論理和演算を介して）。回復された時に、タイトル鍵２４を使用して、コンテンツを解読する。したがって、受信側は、送信側との両方向通信を保持する必要なしに、保護されたコンテンツおよび使用条件のダイジェストを受信し、解読することができる。
【００３８】
タイトル鍵２４を回復するためのダイジェスト３８の再生成のほかに、ダイジェスト３８を、コンテンツ使用条件３６の保全性を検証するために再作成することができることを理解されたい。具体的には、使用条件が危険にさらされた場合に、再作成されたダイジェスト３８は、ソースで計算されたダイジェストと異なるものになり、受信器が、タイトル鍵２４を正しく計算できなくなる。
【００３９】
図７を参照すると、暗号ブロック・チェーン・モードの流れ図が示されている。暗号ブロック・チェーン・モードでは、一連のコンテンツ・ブロックが、受信側への送信のために別々に暗号化される。具体的には、図からわかるように、コンテンツが、コンテンツ・ブロック５０Ａから５０Ｄにセグメント化され、コンテンツ・ヘッダ５２が付随する。コンテンツ・ヘッダ５２には、通常は、コンテンツを識別できるようにするタイム・スタンプなどの情報が含まれる。セグメント化された後に、種値５４Ａから５４Ｃおよび鍵値５５Ａから５５Ｃを使用して、コンテンツ・ブロック５０Ａから５０Ｃを暗号化して、暗号化済みコンテンツ・ブロック５６Ａから５６Ｃを作る。その後、暗号化済みコンテンツ・ブロック５６Ａから５６Ｃ、コンテンツ・ヘッダ５２、および暗号化されないコンテンツ・ブロック５６Ｄを、受信側に送信することができる。しかし、図１および２に示されたＤＲＭＳおよびＣＡＳに似て、保護されたコンテンツは、コンテンツを暗号化するのに使用されたオブジェクト（たとえば鍵値）とは別に送信される。
そのようなシナリオでは、暗号化済みコンテンツ・ブロック５６Ａから５６Ｃの解読でのエラーまたは遅延あるいはその両方が発生する可能性がある。さらに、鍵値５５Ａから５５Ｃを別に送信する時には、コンテンツのランダム・アクセスが可能でない。具体的には、任意のコンテンツ・ブロックからコンテンツ・ストリームにアクセスすることが不可能である。
【００４０】
図８を参照すると、本発明の下での、タイトル鍵の暗号化および暗号化済みコンテンツへの添付が示されている。図からわかるように、圧縮されたコンテンツからなる基本コンテンツ・ストリーム１００が、コンテンツ・ユニット１０２に区分される。各コンテンツ・ユニットに、ヘッダ１０４およびコンテンツ・パケット１０６が含まれる。ヘッダ１０４には、タイム・スタンプ、コンテンツの種類すなわちビデオ、オーディオ、またはそれ以外など、コンテンツを識別するのに役立つ情報が含まれる。ヘッダ１０４は、たとえば、サウンド・データとビデオ・データの同期化に特に役立つ。区分された時に、各コンテンツ・ユニット１０２のヘッダ１０４が、コンテンツ・パケット１０６から構文解析され、コンテンツ・パケット１０６が、タイトル鍵１０８を用いて暗号化されて、暗号化済みコンテンツ・パケット１１４が作られる。その後、鍵暗号化鍵１１０を使用して、タイトル鍵１０８を暗号化し、ヘッダ１０４と共にコンテンツ・パケット１０６に添付する。その後、結果の処理されたコンテンツ・ユニット１１６を、受信側に送信することができる。すなわち、暗号化済みコンテンツ・ユニット、ヘッダ、およびヘッダ拡張（暗号化済みタイトル鍵を含む）を、単一の一体化されたデータ・ストリームとして受信側に配信するか、受信側が保管することができる。したがって、受信側は、コンテンツを解読するのに必要なすべての情報と一緒に、暗号化済みコンテンツを受信または保管する。これによって、前のシステムに関連する同期化問題が回避されるだけではなく、コンテンツのランダム・アクセスも提供される。上で示したように、ＤＲＭＳとＣＡＳの両方が、コンテンツのランダム・アクセスを提供する際に固有の待ち時間（たとえば遅延）を有する。具体的には、本発明の下で送信される各コンテンツ・パケットは、それを暗号化するのに使用されたタイトル鍵と共に「パッケージ化」されるので、受信側は、どのパケットでも、コンテンツ・ストリームにアクセスし、解読することができる。
【００４１】
本発明は、コンテンツ・ユニットに区分されなければならない基本コンテンツ・ストリームの受信に制限されないことを理解されたい。そうではなく、本発明の教示は、コンテンツがコンテンツ・ユニットとして（たとえば事前に区分されて）受信されるシナリオに適用することができる。また、図８に、図を明瞭にするだけのために１つのコンテンツ・ユニット１０２だけの処理が示されていることと、通常の実施形態で、複数のコンテンツ・ユニット１０２がこの形で処理されることを理解されたい。さらに、複数のコンテンツ・ユニット１０２が処理される時に、各コンテンツ・パケットの暗号化に同一のタイトル鍵を使用する必要がないことを諒解されたい。そうではなく、各コンテンツ・パケットを、異なるタイトル鍵を用いて暗号化することができる。この範囲で、基本コンテンツ・ストリーム１００の暗号化に使用されるタイトル鍵の量は、問題にはならない。というのは、各タイトル鍵が、対応する暗号化済みコンテンツ・パケットに添付される（たとえば暗号化された形で）からである。さらに、図示されてはいないが、図５および６に図示し、それに関して説明したように、コンテンツ使用条件を、暗号化の前にタイトル鍵と組み合わせることができることを諒解されたい。そのような場合には、コンテンツ使用条件およびタイトル鍵の暗号化された組合せが、ヘッダ拡張として暗号化済みコンテンツに添付される。
【００４２】
図９を参照すると、ヘッダ拡張１１８が詳細に示されている。図からわかるように、ヘッダ拡張１１８には、暗号化済みタイトル鍵１１２、任意選択の識別子情報１２０、および任意選択のベリファイヤ１２２が含まれる。識別子情報１２０は、暗号化済みコンテンツを示す固定された値、バージョン番号、または予約済みビット・パターンのエイリアシングを防ぐのに使用されるマスク値、あるいはこれらの組合せなどの平文情報である。マスク値は、ヘッダ拡張内の鍵情報または他のデータが既知のコードのエイリアスにならないようにするのに使用される。具体的には、マスク値は、特殊化された目的を有する可能性がある既知のコードから区別するために、鍵情報の一部またはすべてを修正（たとえば逆転）することを示す。これによって、可能な誤ったコード検出が回避される。ベリファイヤ１２２は、使用される場合に、受信側が正しいタイトル鍵が回復されたことを検証できるようにする値である。
【００４３】
図１０に、ベリファイヤ１２２の第１の実施形態を示す。図からわかるように、ベリファイヤ１２２は、タイトル鍵１０８を用いて暗号化される、既知の値１２４およびランダムな値１２６に基づく。既知の値１２４およびランダムな値１２６が暗号化された時に、タイトル鍵１０８が、鍵暗号化鍵１１０を用いて暗号化されて、暗号化済みタイトル鍵１１２が、作られ、ベリファイヤ１２２と共にヘッダ拡張１１８にパッケージ化される。その後、ヘッダ拡張１１８が、受信側に送信される（たとえば暗号化済みコンテンツ・パケットに添付されて）。受信された時に、受信側は、暗号化済みタイトル鍵１１２からベリファイヤ１２２を分離する。その後、鍵暗号化鍵１１０（すなわち、上で説明したようにＫＭＢから回復される鍵）を使用して、暗号化済みタイトル鍵１１２を解読して、タイトル鍵１０８を作る。その後、タイトル鍵１０８を使用して、ベリファイヤ１２２を解読して、既知の値１２４およびランダムな値１２６を作る。ランダムな値１２６は、破棄され、既知の値１２４だけが残される。既知の値１２４が正しい場合には、受信器は、正しいタイトル鍵１０８を使用したことになり、このタイトル鍵１０８を使用して、対応する暗号化済みコンテンツ・パケットを解読することができる。したがって、ベリファイヤを使用することによって、タイトル鍵１０８を検証する手短な形が提供される。具体的には、ベリファイヤ１２２は、一般に、暗号化済みコンテンツよりビット・サイズがかなり小さいので、タイトル鍵１０８が正しいかどうかを判定するすばやい方法を提供する（かなり長い時間を要する可能性がある、タイトル鍵１０８を使用してコンテンツを解読する試みに対して）。
【００４４】
ベリファイヤ１２２の暗号化に使用されるタイトル鍵１０８は、ヘッダ拡張１１８が添付されるコンテンツ・パケットの暗号化に使用されたものと同一のタイトル鍵でなければならないことを理解されたい。したがって、上で説明したように、タイトル鍵１０８は、コンテンツ・ユニット１０２に基づいて変更することができる（図８）。
【００４５】
図１１を参照すると、ベリファイヤ１２２のもう１つの実施形態が示されている。図からわかるように、第１の既知の値１２８を、タイトル鍵１０８を用いて暗号化して、仮の値１３０を作る。図１０に似て、タイトル鍵１０８を、鍵暗号化鍵１１０を用いて暗号化して、暗号化済みタイトル鍵１１２を作る。仮の値１３０を切り捨てて、切り捨てられた値１３２を作り、これを第２の既知の値１３４と組み合わせて（たとえばＸＯＲ演算を介して）、ベリファイヤ１２２を作る。その後、ベリファイヤ１２２を、暗号化済みタイトル鍵１１２と共にヘッダ拡張１１８にパッケージ化し、受信側への送信のためにコンテンツ・パケットに添付する。受信側は、これらのステップを逆に実行する。具体的には、受信側は、コンテンツ・パケットからヘッダ拡張１１８を分離し、ヘッダ拡張１１８から暗号化済みタイトル鍵１１２を回復する。その後、逆ＸＯＲ演算を実行して、切り捨てられた値１３２から第２の既知の値１３４を分離する。切り捨てられた値１３２を展開して、仮の値１３０を作る。鍵暗号化鍵１１０（ＫＭＢから回復された）を使用して暗号化済みタイトル鍵１１２を処理することによって、タイトル鍵１０８が、回復され、仮の値１３０の解読に使用される。第１の既知の値１２８が回復された場合に、正しいタイトル鍵１０８が回復され、これを使用して、対応するコンテンツ・パケットを解読することができる。図１２を参照すると、本発明の下でのコンテンツ・ユニット１０２および２０２の受信および処理が詳細に示されている。図からわかるように、ヘッダ１０４および２０４と、ヘッダ拡張１１８および２１８と、コンテンツ・パケット１０６および２０６を含むコンテンツ・ユニット１０２および２０２が受信される。暗号化済みタイトル鍵１１２および２１２が、それぞれヘッダ拡張１１８および２１８から回復される。
その後、鍵暗号化鍵１１０を使用して、暗号化済みタイトル鍵１１２および２１２の両方を解読して、タイトル鍵１０８および２０８を作る。回復された時に、タイトル鍵１０８および２０８を使用して、対応するコンテンツ・パケット１０６および２０６を解読して、コンテンツ１４０および２４０を作る。
【００４６】
タイトル鍵１０８および２０８は、それを使用して暗号化済みコンテンツ・パケットに添付され、送信されるので、本発明の下での同期化は、固有である。対照的に、関連するシステムは、一般に、同期に関して別々の送信またはビット・フラグあるいはその両方に頼る。さらに、暗号化済みコンテンツとのタイトル鍵の同期送信および配信によって、コンテンツのランダム・アクセスが可能になる。具体的には、各コンテンツ・パケットに、正しいタイトル鍵が付随し、コンテンツ・ストリームに、どのパケットからでもアクセスすることができる。関連するシステムは、そのような特徴を提供することができない。さらに、各コンテンツ・パケットを、異なるタイトル鍵を用いて暗号化することができるので、タイトル鍵を不正に取得した当事者は、ストリーム全体にアクセスすることができない。対照的に、剽窃された鍵は、それが添付されたコンテンツ・パケットの解読だけに有効である。また、タイトル鍵および暗号化済みコンテンツが、単一のストリームとして送信されるので、本発明は、現在のフロントエンド規格およびバックエンド規格との互換性があり、これらに準拠する。
【００４７】
図１３を参照すると、本発明の例示的ＭＰＥＧ実施形態が示されている。図からわかるように、ＭＰＥＧパケット化された基本ストリーム３００が、ＰＥＳ（パケット）ユニット３０２に区分される（明瞭にするために１つだけを図示）。
ＰＥＳユニット３０２には、パケット化された基本ストリーム（ＰＥＳ）パケット・ペイロード３０６、任意選択のＰＥＳヘッダ３０４、パケット長３０８、ストリーム識別子３１０、および開始コード・プレフィックス３１２が含まれる。ＰＥＳパケット・ペイロード３０６は、タイトル鍵を用いて暗号化され、このタイトル鍵は、その後、鍵暗号化鍵を用いて暗号化され、ヘッダ拡張３２１としてＰＥＳユニット３０２に組み込まれる。図からわかるように、任意選択のＰＥＳヘッダ３０４には、任意選択のスタッフィング・バイト３１３、任意選択フィールド３１４、ＰＥＳヘッダ・データ長３１６、フラグ３１８、インジケータ・ビット３２０、および固定された数値３２２が含まれる。フラグは、任意選択フィールド３１４の存在を示す。ヘッダ拡張３２１が、任意選択フィールド３１４内に示されており、これには、任意選択フィールド３２４、フラグ３２６、および時刻／速度（または他の）情報３２８が含まれる。任意選択フィールド３２４内に、ＰＥＳプライベート・データ３３０、追加情報３３２、ＰＥＳ拡張フィールド長３３４、およびＰＥＳ拡張フィールド・データ３３６が含まれる。暗号化済みタイトル鍵は、ＰＥＳ拡張フィールド・データ３３６として、またはＰＥＳプライベート・データ３３０として含めることができる。
【００４８】
暗号化された鍵（および任意選択の識別子情報またはベリファイヤあるいはその両方）がＰＥＳパケット・ペイロード３０６に添付された後に、結果のＰＥＳユニット３０２を、２つの異なるシステム・オプションで多重化することができる。第１のオプションは、図１４に示されており、トランスポート・ストリームとして既知である。トランスポート・ストリームは、通常は、デジタル・テレビジョンなどのエラーの多いブロードキャスト環境で使用される。図からわかるように、トランスポート・ストリーム・パケット３５０Ａから３５０Ｆは、比較的小さく、単一のビデオのＰＥＳユニット３０２を含めるために、通常は複数のトランスポート・ストリーム・パケット３５０Ａから３５０Ｃが必要である。第２のオプションは、図１５に示されたプログラム・ストリームである。プログラム・ストリームは、一般に、誤り訂正コードを有するものまたは固定記憶装置内などの、より信頼性のある伝送に使用される。しかし、トランスポート・ストリーム・パケットと異なって、単一のプログラム・ストリーム・パケット３６０が、複数のビデオのＰＥＳユニット３０２および３６２を保持することができる。伝送の送信／受信、コンテンツまたは鍵あるいはその両方の暗号化／解読、コンテンツへの鍵の添付などに使用される、図１から図１５の要素を、ハードウェア、ソフトウェア、あるいはハードウェアまたはソフトウェアの組み合わせとして実施できることを理解されたい。したがって、すべての種類のコンピュータ／サーバ・システム、または本明細書に記載の方法を実行するように適合された他の装置が、適する。ハードウェアとソフトウェアの通常の組合せは、ロードされ実行される時に本明細書に記載の方法を実行するコンピュータ・プログラムを有する汎用（コンピュータ）システムとすることができる。代替案では、本発明の機能的作業の１つまたは複数を実行するために特殊化されたハードウェアを含む特定用途（コンピュータ）システムを使用することができる。本発明は、本明細書に記載の方法の実施形態を可能にするすべての特徴を含み、（コンピュータ）システムにロードされた時にこれらの方法を実行することができる、コンピュータ・プログラム製品で実施することもできる。コンピュータ・プログラム、ソフトウェア・プログラム、プログラム、またはソフトウェアは、この文脈では、（ａ）別の言語、コード、または表記への変換、または（ｂ）異なる材料形態での再生のいずれかまたは両方の後にあるいは直接にのいずれかで、情報処理能力を有するシステムに特定の機能を実行させることを意図された命令の組の、すべての言語、コード、または表記での表現を意味する。
【００４９】
図１６を参照すると、本発明の例示的なコンピュータ化された実施形態が示されている。図からわかるように、コンピュータ・システム４００には、全般的に、メモリ４０２、入出力インターフェース４０４、中央処理装置（ＣＰＵ）４０６、外部装置／リソース４０８、バス４１０、およびデータベース４２６が含まれる。メモリ４０２には、磁気媒体、光学媒体、ランダム・アクセス・メモリ（ＲＡＭ）、読取専用メモリ（ＲＯＭ）、データ・キャッシュ、データ・オブジェクトなどを含む、すべての既知のタイプのデータ記憶媒体またはデータ伝送媒体あるいはこの両方を含めることができる。さらに、メモリ４０２は、１つまたは複数のタイプのデータ・ストレージを含めて単一の物理的位置に常駐するか、さまざまな形で複数の物理的システムにまたがって分散させることができる。ＣＰＵ４０６には、同様に、単一の処理装置を含めるか、たとえばクライアントおよびサーバ上など、１つまたは複数の位置の１つまたは複数の処理装置にまたがって分散させることができる。入出力インターフェース４０４には、外部ソースから情報を交換するすべてのシステムを含めることができる。外部装置／リソース４０８には、スピーカ、ＣＲＴ、ＬＥＤスクリーン、ハンドヘルド・デバイス、キーボード、マウス、音声認識システム、読み上げシステム、プリンタ、モニタ、ファクシミリ、ポケットベルなどを含む、すべての既知のタイプの外部装置を含めることができる。バス４１０は、コンピュータ・システム４００内の構成要素のそれぞれの間の通信リンクを提供し、同様に、バス４１０に、電気リンク、光学リンク、無線リンクなどを含むすべての既知のタイプの伝送リンクを含めることができる。さらに、図示されてはいないが、キャッシュ・メモリ、通信システム、システム・ソフトウェアなどの追加の構成要素を、コンピュータ・システム４００に組み込むことができる。
【００５０】
データベース４２６は、ＫＭＢ、コンテンツ使用条件、ベリファイヤ、識別子情報などの、本発明を実行するのに必要な情報のストレージを提供することができる。したがって、データベース４２６には、磁気ディスク・ドライブまたは光ディスク・ドライブなどの１つまたは複数のストレージ・デバイスが含まれる。もう１つの実施形態では、データベース４２６に、たとえばローカル・エリア・ネットワーク（ＬＡＮ）、広域ネットワーク（ＷＡＮ）、またはストレージ・エリア・ネットワーク（ＳＡＮ）（図示せず）などにまたがって分散されたデータが含まれる。データベース４２６は、当業者が、１つまたは複数のストレージ・デバイスを含めるために解釈することができる形で構成することもできる。
【００５１】
コンピュータ・システム４００が、ソース４２８から受信される基本コンテンツ・ストリームのコンテンツ・ユニットを処理することができ、処理されたコンテンツ・ユニットを受信側４３０に送信することができる、すべてのシステムを表すことを意図されていることを理解されたい。メモリ４０２に保管されるのが、添付システム４１２であり、この添付システム４１２には、構文解析システム４１４、暗号化システム４１６、鍵システム４１８、指定システム４２０、組合せシステム４２２、および送信システム４２４が含まれる。
【００５２】
上で説明したように、それぞれにヘッダおよびコンテンツ・パケットが含まれるコンテンツ・ユニットを有する基本コンテンツ・ストリームが、ソース４２８から受信される。受信時に、構文解析システム４１４が、コンテンツ・パケットからヘッダを構文解析または分離する。構文解析された後に、暗号化システム４１６が、タイトル鍵を使用してコンテンツ・パケットを暗号化する。その後、鍵システム４１８が、鍵暗号化鍵（たとえばＫＭＢで暗号化された）を使用して、ヘッダ拡張として暗号化済みコンテンツ・パケットに添付するために、タイトル鍵を暗号化する。指定システム４２０を用いると、コンテンツ使用条件、識別子情報、またはベリファイヤあるいはこれらの組合せ（集合的に「データ」と称する）を、任意選択として指定できるようになる。指定された場合に、データが、組合せシステム４２２を介してヘッダ拡張内で暗号化された鍵と組み合わされる。どの場合でも、暗号化済みコンテンツ・パケット、ヘッダ、およびヘッダ拡張が、組合せシステム４２２によって単一の処理されたコンテンツ・ユニットに組み合わされ、送信システム４２４を介して受信側４３０に同期送信される。受信された後に、受信側４３０が、暗号化済みコンテンツおよび添付されたタイトル鍵を同期式に保管することができる。
【００５３】
図１６に示されたさまざまなシステムが、例示だけを意図されていることを理解されたい。たとえば、添付システム４１２に、基本コンテンツ・ストリーム（コンテンツ・ユニットではなく）を受け取り、これをコンテンツ・ユニットに区分する区分システムを含めることができる。
【００５４】
本発明の前述の説明は、例示および説明のために提示されたものである。網羅的であることまたは本発明を開示された正確な形態に制限することは意図されておらず、明らかに、多数の修正形態および変形形態が可能である。そのような、当業者に明らかな修正形態および変更形態は、添付の特許請求の範囲によって定義される本発明の範囲内に含むものとする。
【００５５】
まとめとして、本発明の構成に関して以下の事項を開示する。
【００５６】
（１）受信側に対して同期送信するために、暗号化済みコンテンツにタイトル鍵を添付する方法であって、
タイトル鍵を用いてコンテンツを暗号化するステップと、
鍵暗号化鍵を用いてタイトル鍵を暗号化するステップと、
受信側に対して同期送信するために、前記暗号化済みコンテンツに前記暗号化済みタイトル鍵を添付するステップと
を含む方法。
（２）前記暗号化済みコンテンツおよび前記添付された暗号化済みタイトル鍵を受信側に同期送信するステップをさらに含む、上記（１）に記載の方法。
（３）基本コンテンツ・ストリームを受け取るステップと、
前記コンテンツを暗号化する前に、前記基本コンテンツ・ストリームをコンテンツ・ユニットに区分するステップであって、各コンテンツ・ユニットが、コンテンツおよびヘッダを含む、ステップと
をさらに含む、上記（１）に記載の方法。
（４）前記コンテンツを暗号化する前に、前記コンテンツから前記ヘッダを構文解析するステップをさらに含む、上記（３）に記載の方法。
（５）識別子情報およびベリファイヤを前記暗号化済みコンテンツに添付するステップをさらに含む、上記（１）に記載の方法。
（６）前記ベリファイヤが、前記タイトル鍵を用いて暗号化された既知の値を含む、上記（５）に記載の方法。
（７）前記識別子情報が、予約されたビット・パターンのエイリアシングを防ぐ、上記（５）に記載の方法。
（８）受信側に対して同期送信するために、暗号化済みコンテンツにタイトル鍵を添付する方法であって、
コンテンツ・パケットおよびヘッダを含むコンテンツ・ユニットを提供するステップと、
タイトル鍵を用いて前記コンテンツ・パケットを暗号化するステップと、
鍵暗号化鍵を用いて前記タイトル鍵を暗号化するステップと、
前記暗号化済みタイトル鍵を含むヘッダ拡張を前記暗号化済みコンテンツ・パケットに添付するステップと、
前記ヘッダ、前記ヘッダ拡張、および前記暗号化済みコンテンツを受信側に同期送信するステップと
を含む方法。
（９）前記ヘッダ拡張が、さらに、ベリファイヤおよび識別子情報を含む、上記（８）に記載の方法。
（１０）前記ベリファイヤが、前記タイトル鍵を用いて暗号化された既知の値を含む、上記（９）に記載の方法。
（１１）前記受信側が、前記暗号化済みコンテンツおよび前記ヘッダ拡張を保管するステップと、
前記受信側が、鍵管理ブロックを使用して前記鍵暗号化鍵を判定するステップと、
前記受信側が、前記鍵暗号化鍵を用いて前記タイトル鍵を解読するステップと、
前記受信側が、前記タイトル鍵を用いて前記既知の値を解読するステップと、
前記受信側が、前記コンテンツ・パケットを解読するステップと
をさらに含む、上記（１０）に記載の方法。
（１２）受信側に対して同期送信するために、暗号化済みコンテンツにタイトル鍵を添付するシステムであって、
タイトル鍵を用いてコンテンツ・パケットを暗号化するシステムと、
鍵暗号化鍵を用いて前記タイトル鍵を暗号化するシステムと、
前記暗号化済みコンテンツ・パケットに、前記暗号化済みタイトル鍵を含むヘッダ拡張を添付するシステムと
を含むシステム。
（１３）前記暗号化済みコンテンツおよび前記添付されたヘッダ拡張を受信側に同期送信するシステムをさらに含む、上記（１２）に記載のシステム。
（１４）前記ヘッダ拡張が、さらに、識別子情報およびベリファイヤを含む、上記（１２）に記載のシステム。
（１５）前記ベリファイヤが、前記タイトル鍵を用いて暗号化された既知の値を含む、上記（１４）に記載のシステム。
（１６）前記識別子情報が、予約されたビット・パターンのエイリアシングを防ぐマスク値を含む、上記（１４）に記載のシステム。
（１７）受信側に対して同期送信するために、暗号化済みコンテンツにタイトル鍵を添付する、記録可能媒体に保管されたプログラムであって、該プログラムがコンピュータに、
タイトル鍵を用いてコンテンツ・パケットを暗号化する機能と、
鍵暗号化鍵を用いて前記タイトル鍵を暗号化する機能と、
前記暗号化済みタイトル鍵を含むヘッダ拡張を前記暗号化済みコンテンツ・パケットに添付する機能と
を実現させるプログラム。
（１８）前記ヘッダ拡張および前記暗号化済みコンテンツを受信側に同期送信する機能をさらに含む、上記（１７）に記載のプログラム。
（１９）前記ヘッダ拡張が、さらに、識別子情報およびベリファイヤを含む、上記（１７）に記載のプログラム。
（２０）前記ベリファイヤが、前記タイトル鍵を用いて暗号化された既知の値を含み、前記識別子情報が、予約されたビット・パターンのエイリアシングを防ぐマスク値を含む、上記（１９）に記載のプログラム。
【図面の簡単な説明】
【図１】デジタル著作権管理システム（ＤＲＭＳ）の流れ図である。
【図２】限定受信システム（ＣＡＳ）の流れ図である。
【図３】鍵暗号化鍵を用いるタイトル鍵の暗号化の流れ図である。
【図４】異なる鍵暗号化鍵を用いる図３のタイトル鍵の解読および再暗号化の流れ図である。
【図５】コンテンツ使用条件とタイトル鍵との組合せと、鍵暗号化鍵を用いる組合せの暗号化の流れ図である。
【図６】受信側による図５のタイトル鍵の回復の流れ図である。
【図７】暗号ブロック・チェーン・モードの流れ図である。
【図８】基本コンテンツ・ストリームの本発明に従う処理の流れ図である。
【図９】本発明によるヘッダ拡張を示す図である。
【図１０】本発明の下で実施されるベリファイヤの第１の流れ図である。
【図１１】本発明の下で実施されるベリファイヤの第２の流れ図である。
【図１２】本発明による、受信側によるコンテンツ・パケットの処理の流れ図である。
【図１３】本発明のＭＰＥＧ実施態様を示す図である。
【図１４】トランスポート・ストリーム・システムによるＰＥＳユニットの多重化を示す図である。
【図１５】プログラム・ストリーム・システムによるＰＥＳユニットの多重化を示す図である。
【図１６】本発明による添付システムを有するコンピュータ・システムを示す図である。
【符号の説明】
１０　コンテンツ
１２　アクセス権／コンテンツ使用条件
１４　メディア・サーバ
１６　ライセンス・サーバ
１８　ＰＣ
２０　ウェブ・サーバ
４００　コンピュータ・システム
４０２　メモリ
４０４　入出力インターフェース
４０６　中央処理装置（ＣＰＵ）
４０８　外部装置／リソース
４１０　バス
４１２　添付システム
４１４　構文解析システム
４１６　暗号化システム
４１８　鍵システム
４２０　指定システム
４２２　組合せシステム
４２４　送信システム
４２６　データベース
４２８　ソース
４３０　受信側
【図１】
2004048676.tif 000003
【図２】
2004048676.tif 000004
【図３】
2004048676.tif 000005
【図４】
2004048676.tif 000006
【図５】
2004048676.tif 000007
【図６】
2004048676.tif 000008
【図７】
2004048676.tif 000009
【図８】
2004048676.tif 000010
【図９】
2004048676.tif 000011
【図１０】
2004048676.tif 000012
【図１１】
2004048676.tif 000013
【図１２】
2004048676.tif 000014
【図１３】
2004048676.tif 000015
【図１４】
2004048676.tif 000016
【図１５】
2004048676.tif 000017
【図１６】
2004048676.tif 000018