JP2005520456A - マルチメディア・コンテンツの事前暗号化のための暗号化、認証および鍵管理 - Google Patents

Abstract

コンテンツ・プロバイダからキャッシング・サーバに、次に、キャッシング・サーバからビューアにコンテンツを送信するための方法およびシステム。上記方法は、コンテンツがキャッシング・サーバに送信される前に、コンテンツを事前暗号化装置アプリケーションにより暗号化するステップを含む。事前暗号化装置アプリケーションは、事前暗号化を行うために、鍵記憶サービスが提供する事前暗号副鍵を使用する。鍵記憶サービスは、システムの自立形構成要素であり、事前暗号副鍵を生成し、記憶し、配布する。

Description

本発明は、コンテンツ・プロバイダからキャッシング・サーバに、コンテンツを送信する方法および装置に関する。

毎日、何十万人もの人々が電子的に交信を行っている。例えば、人は相互に通信し、情報を送るために電子メール（ｅメール）を使用する。人および事業主は、重要な情報を管理し、保護し、および転送するために、コンピュータ・ネットワークまたは他の電子デバイスに大きく依存している。何百万ドルもの通貨が、毎日、銀行ネットワークおよび現金自動預け払い機（ＡＴＭ）を通して電子的に転送される。人々は、毎日情報を伝達し、転送するために、セル方式の携帯電話および他の無線携帯情報端末（ＰＤＡ）を使用する。

何百万もの相互に接続しているコンピュータを備えるインターネットの出現により、電子的交信は劇的に加速された。インターネットを使用すれば、事実上世界の何処へでもほとんど瞬間的に情報を伝達し転送することができる。ワールド・ワイド・ウェブ（ｗｗｗ）は、オンライン・ビジネス、データの配布、マーケティング、株取引、オンライン・バンキング、ゲーム、研究、学習および無数の他の活動のために使用される。

当事者が対面してまたは紙のような物理媒体を使用して相互作用を行う場合には、相互作用を行っている当事者の信用証明の認証を比較的容易に行うことができる。例えば、ある人が銀行に入っていって預金を引き出そうする場合には、銀行の窓口の係員は、要求された金を渡す前にその人の身分証明書を要求し、確認することができる。契約書に人の署名があれば、その契約に対するその人の承認を十分に保証していると見なされる。同様に、ある人が店舗に入っていってクレジット・カードである品物を購入する場合には、その人がそのクレジット・カードの真の所有者であることを合理的に確認するために、レジ係りは容易に予防措置をとることができる。

しかし、電子取引の分野においては、認証のこのような物理的手段を使用することはできない。人および事業主は、自分の電子相互作用が安全で危険がないと考えない限りは、インターネットを通して送金したり、品物を購入することもできないし、または任意の電子デバイスにより、他の方法で秘密情報を管理したり転送することができない。それ故、決定および合意が電子的に伝達される世界では、認証、機密保護およびプライバシーの保護を提供するための電子的技術が必要になる。

暗号作成法は、重要な情報を保護し、通信中のプライバシーを維持し、取引の際にユーザの認証を行い、情報を転送する際に他の機密保護の手段を講じるために使用することができる技術およびその使用するための学問である。暗号解読は、暗号作成機構を処理し、または読み解くための学問である。例えば、ハッカーは、暗号解読を研究し、実際に使用する人である。暗号作成術は、暗号作成と暗号解読とが結合した学問の分野である。

暗号作成法を使用することにより、人は現実の世界の信頼を電子世界に移行することができる。そのため、人々は、詐欺、プライバシーの侵害または機密保護がない状態の不当な干渉を受けずに、電子的にビジネスを行うことができる。電子的に送信される情報が常に増大しているために、暗号作成への依存度も増大している。

例えば、暗号作成技術は、ウェブサイトの機密を保護し、電子送信を安全にするのを助
けている。これにより、人々はオンライン・バンキング、オンライン取引を行うことができ、自分の口座情報が漏れることを心配せずに、自分のクレジット・カードでオンライン購入を行うことができる。暗号作成法は、インターネットおよび電子商取引の今後の発展のために非常に重要なものである。

暗号作成法は、また、電話、テレビおよび種々の他の通常の家庭用品内でも使用されている。暗号作成法がなければ、ハッカーは、誰か他の私的な電子メールにもっと容易にアクセスすることができ、電話での会話をもっと容易に聞くことができ、ケーブル会社をもっと容易に盗聴することができ、ケーブル・サービスを無料でもっと容易に手に入れることができ、銀行口座にもっと容易に入りこむことができる。

暗号作成法の重要な面としては、暗号化と暗号解読がある。暗号化は、データを一見して理解することができず、例えば、電子鍵（鍵）のような適当な知識がないと、妥当な時間内にアクセスするのが不可能でないにしても、非常に難しい形に変換することである。鍵については以下にさらに詳細に説明する。暗号化の目的は、暗号化したデータにアクセスしたにしても、当事者でない人から情報を秘匿することによりプライバシーを確実に保護することである。暗号解読は暗号化の逆である。暗号解読は、暗号化したデータを理解することができる形に変換することである。機密保護対象のウェブサイトの場合には、例えば、データを記憶しているコンピュータとデータを受信するコンピュータとの間で送信されるすべてのデータを暗号化しなければならない。受信コンピュータは、次に、データを解読することができなければならない。

すでに説明したように、暗号化および解読に成功するかしないかは、理想的には、暗号化および解読を行う当事者だけが知っているある種の秘密の知識に依存している。この知識は鍵と呼ばれる。鍵は、通常、一連のランダムなまたは疑似ランダムなビットである。それ故、正しい鍵を持たない人は、他の人の重要な情報を送信することも受信することも解読することもできない。鍵は、また、電子認証、デジタル署名、デジタル・タイムスタンプ、および他の電子的機密保護の目的のために使用される。

電子通信技術が開発されたために、ハイパーテキスト転送プロトコル（ＨＴＴＰ）、リアルタイム・プロトコル（ＲＴＰ）、およびリアルタイム・ストリーミング・プロトコル（ＲＴＳＰ）などのインターネット・プロトコル（ＩＰ）ネットワークによって、インターネットを通してマルチメディア・コンテンツをダウンロードおよび／またはストリーミングする機能および要望が生じた。コンテンツをダウンロードする場合には、コンテンツ全体が、コンテンツ・プロバイダから顧客のデバイスに転送され、その後で顧客が、このコンテンツを閲覧し、使用し、または聞く。一方、コンテンツをストリーミングする場合には、顧客は、コンテンツが完全にダウンロードされる前にコンテンツを閲覧したり、使用したり、聞くことができる。それどころか、ストリーミングされたコンテンツは、到着したときに閲覧したり、使用したり、または聞くことができる一連のパケットとして送信される。ユーザは、ストリーミングされたコンテンツを再生することができる視聴アプリケーションまたは再生アプリケーションを必要とする。インターネットを通して、コンテンツ・プロバイダから顧客の電子デバイス（例えば、パーソナル・コンピュータ）にストリーミングおよび／またはダウンロードすることができるマルチメディア・コンテンツの例としては、ビデオ・オン・デマンド（ＶＯＤ）、ライブ・ビデオおよびオーディオ同報通信、ソフトウェア、電子書籍、映画および音楽がある。以降の説明および添付の特許請求の範囲で使用する場合、特に指定がない限り、「コンテンツ」という用語は、マルチメディア・コンテンツおよび電子文書を含むがこれらに限定されないストリーミングまたはダウンロードすることができるすべての可能なデジタル・コンテンツを広く意味する。

合法的な顧客に対してコンテンツを機密保護状態で配信するための需要が明らかに存在している。それ故、コンテンツ・プロバイダは、自分がインターネットを通して送信するコンテンツを暗号化しなければならない。従来、コンテンツ・プロバイダは、顧客に配信する場合にコンテンツをリアルタイムで暗号化してきた。しかし、コンテンツ・プロバイダにとって、そのコンテンツをリアルタイムで暗号化することはいつでも望ましいことであるとは限らないし、または実行可能というわけではない。それ故、この業界においては、コンテンツのリアルタイムでの暗号化とは逆に、インターネットを通して送信する前に、コンテンツ・プロバイダがコンテンツを暗号化できればという要望がある。ダウンロードまたはストリーミングのために、送信の前に行うコンテンツの暗号化は、オフライン暗号化または事前暗号化と呼ばれる。事前暗号化を行えば、リアルタイム暗号化に関連するコストおよび諸経費を低減することができる。またこの業界においては、事前暗号化に関連する鍵管理および配布も要望されている。

多くの可能な実施形態の中の１つにおいては、本発明は、コンテンツ・プロバイダからキャッシング・サーバに、コンテンツを送信する方法を提供する。キャッシング・サーバは、次に、コンテンツをビューアに配布する。この方法は、コンテンツをキャッシング・サーバに送信する前に、事前暗号化装置アプリケーションによりコンテンツを暗号化するステップを含む。事前暗号化装置アプリケーションは、事前暗号化を行うために、鍵記憶サービスが提供する副鍵を使用する。

本発明のもう１つの実施形態は、コンテンツ・プロバイダからキャッシング・サーバへ、次に、キャッシング・サーバからビューアへのコンテンツの送信を管理するためのインターネット・プロトコル・ライツ管理システムを提供する。このシステムは、キャッシング・サーバに送信する前に、コンテンツを暗号化するための事前暗号化装置アプリケーションを備える。このシステムは、また、副鍵を生成し、記憶し、また配布するための自立形鍵記憶サービスを備える。副鍵は、コンテンツを暗号化するために事前暗号化装置アプリケーションが使用する。副鍵は、また、暗号化され、キャッシング・サーバに送信された後で、コンテンツを解読するために、キャッシング・サーバが使用する。

添付の図面は、本発明の種々の実施形態および本明細書の一部を示す。図の実施形態は、単に本発明のいくつかの例にしか過ぎないし、本発明の範囲を制限するものではない。
図面全体を通して、同じ参照符号は、類似のしかし必ずしも同一ではない要素を示す。

本明細書においては、コンテンツ・プロバイダが、そのストリーミングおよびコンテンツ・ファイル・サーバと一体になっていない別の事前暗号化装置アプリケーションを使用して、そのコンテンツをオフラインで暗号化する方法およびシステムについて記述する。本明細書においては、また、事前暗号化に関連する鍵管理および配布のための方法およびシステムについて記述する。

事前暗号化および鍵管理および配布方法およびシステムは、インターネット・プロトコル・ライツ管理（ＩＰＲＭ）システムで実施される。ＩＰＲＭシステムは、ＩＰプロトコルに基づいて、認証、プライバシー保護、機密保護、保全性、および任意のマルチメディア・ダウンロードまたはストリーミング・ネットワークへのアクセス制御のようなデジタル・ライツ管理機能を提供する。例えば、好適なＩＰＲＭシステムは、ビデオ・オン・デマンド（ＶＯＤ）およびコンテンツのマルチキャスト配信のような二点間配信をサポートする。好適なＩＰＲＭシステムは、また持続アクセス問題を含む。持続アクセスは、顧客が受信し、局所固定記憶装置（例えば、ハード・ディスク）内にセーブしたコンテンツの
ローカル・コピーへのアクセスとして定義される。持続ライツは、再生またはコンテンツの再現（ｒｅｎｄｅｒｉｎｇ）、コピーの保護、他のユーザまたはデバイスへの再配布、印刷権等を含む。

例示としてのＩＰＲＭシステムは、クライアントに対する有期信託を含むソフトウェア保護をベースとしている。しかし、ＩＰＲＭシステムは、オプションとしてのハードウェア・セキュリティ・モジュールにより強化することができる。あるアプリケーションの場合には、このハードウェア・セキュリティ・モジュールは、高い機密保護レベルを必要とする著作権者から高品質のコンテンツへの権利を入手するための強制的なものであってもよい。

図１は、本発明のある実施形態を実施するために使用することができる例示としてのコンテンツ配信アーキテクチャである。図１に示すように、コンテンツ・プロバイダ（１００）は、キャッシング・サーバ（１０１）を通してビューア（１０２）にコンテンツを配信する。本明細書および添付の特許請求の範囲で使用する場合、別段の指定がない場合、「キャッシング・サーバ」という用語は、二点間接続またはマルチキャスト接続を通して、任意の所望のストリーミングまたはファイル転送プロトコルにより、ビューアにコンテンツを配信することができる任意のタイプのサーバを意味する。本発明のある実施形態によれば、この配信は、コンテンツ・ダウンロードまたはコンテンツ・ストリームの形で行うことができる。ビューア（１０２）は、好適には、ダウンロードしたコンテンツまたはストリーミングしたコンテンツを表示し、同報通信し、管理することができるアプリケーションを備えていることが好ましいし、好適には、パーソナル・コンピュータ（ＰＣ）、サーバまたはある種の他のタイプの電子デバイスのようなホスト上で可動することが好ましい。ビューア（１０２）は、好適には、顧客またはクライアントが作動するものであることが好ましい。

図１の例示としてのアーキテクチャ内のコンテンツ・プロバイダ（１００）は、多数のマルチメディア・コンテンツ・サービスの中の任意のものを供給することができる。例えば、コンテンツは、有料テレビ放送（ＶＯＤ）、ペイ・パー・ビュー（ＰＰＶ）、ペイ・バイ・タイム（ＰＢＴ）、ペイ・バイ・クオリティ（ＰＢＱ）、ストリーミング・ビデオまたはオーディオ等であってもよい。本発明のある実施形態によれば、コンテンツ・プロバイダ（１００）は、キャッシング・サーバ（１０１）を通してビューア（１０２）にストリーミングするコンテンツを事前に暗号化する。事前暗号化方法およびその関連する鍵管理および配布方法について、図３および図４を参照しながらさらに詳細に説明する。

図１に示すように、コンテンツ・プロバイダ（１００）は、好適には、ビューア（１０２）にコンテンツを配信するキャッシング・サーバ（１０１）にコンテンツを供給することが好ましい。キャッシング・サーバ（１０１）は、コンテンツをネットワークの縁部のもっと近いところに移動するために使用される。そうすることにより、ストリーミングおよびダウンロードの性能が改善され、もっと小規模なコンテンツ・プロバイダは、媒体ストリーミング用の高価なハードウェアを購入しなくても、自分のコンテンツを販売することができる。またそうすることにより、ＩＰマルチキャストの導入をキャッシング・サーバ（１０１）のところだけに限定することができる。同じコンテンツが同時に１人またはそれ以上の顧客に配信される場合、これをマルチキャストと呼ぶ。キャッシング・サーバ（１０１）を使用することが好ましいが、必ずしもそうする必要はない。本発明のもう１つの実施形態は、コンテンツ・プロバイダ（１００）からビューア（１０２）に直接ストリーミングされるコンテンツ用のものである。しかし、説明のために、本明細書においては、ある種のキャッシング・サーバ（１０１）の存在を仮定している。

図１の好適なコンテンツ配信アーキテクチャは、また、集中型サービス（１０３）の提
供を受けるコンテンツ配信システムの各要素も示す。集中型サービス（１０３）は、好適には、鍵管理および配布サービスを含むことが好ましい。図１に示すように、コンテンツ配信システムの各要素は、好適には、集中型サービス（１０３）と通信することができることが好ましい。例えば、以下にさらに詳細に説明するように、ビューア（１０２）は、自分の認証が行えるように、およびキャッシング・サーバ（１０１）からのコンテンツの受信の許可が得られるように、集中型サービス（１０３）からチケットを要求することができる。

図２は、キャッシング・サーバ（１０１）を通して、コンテンツ・プロバイダ（１００）からビューア（１０２）に、コンテンツを機密保護状態でストリーミングまたはダウンロードする好適なＩＰＲＭアーキテクチャを示す。図２に示すように、コンテンツ・プロバイダ（１００）は、好適には、ＨＴＴＰまたはＲＴＰサーバ（２００）を備えることが好ましい。コンテンツ・プロバイダ（１００）は、また、好適には、コンテンツを含む記憶装置（２０２）を備えることが好ましい。記憶装置（２０２）としては、ハードドライブまたはコンテンツを記憶することができる任意の他のデバイスを使用することができる。ＨＴＴＰまたはＲＴＰサーバ（２００）は、好適には、ビューア（１０２）に送信されるコンテンツを含む記憶装置（２０２）にアクセスすることが好ましい。コンテンツは、本発明の一実施形態によるヒント付きコンテンツであってもよい。ヒント付きコンテンツは、コンテンツをストリーミングできるようにするヒント・トラックまたは情報を含むコンテンツである。しかし、必ずしもコンテンツにヒントを付ける必要はない。

図２に示すように、コンテンツ・プロバイダのＨＴＴＰまたはＲＴＰサーバ（２００）、キャッシング・サーバ（１０１）およびビューア（１０２）は、それぞれ、好適には、ＩＰＲＭ鍵管理インタフェースを使用することにより、集中型サービス（１０３）の一部である、鍵配布センター（ＫＤＣ）（２０１）と通信し、ここからチケットを入手する。以降の説明および添付の特許請求の範囲で使用する場合には、別段の指定がない限り、ＫＤＣは、コンテンツ・プロバイダ（１００）と、キャッシング・サーバ（１０１）と、ビューア（１０２）との間で、安全な通信を可能にする鍵を備えるチケットを生成し、管理しまた配布する任意の集中型サービスを意味する。この安全な通信により、暗号化されたコンテンツの配信および解読が容易になる。図２の場合には、ＩＰＲＭ鍵管理インタフェースは陰影付き矢印で表す。図３に示すように、鍵管理インタフェース（２０４）は、ＨＴＴＰまたはＲＴＰサーバ（２００）とキャッシング・サーバ（１０１）との間の鍵管理である。キャッシング・サーバにおいては、このインタフェースに対して一意である鍵が生成され、コンテンツが、キャッシング・サーバ（１０１）に送信される度に、また同じコンテンツが複数回送信される度に暗号化される。鍵管理インタフェース（２０５）は、キャッシング・サーバ（１０１）とビューア（１０２）との間の鍵管理であり、ビューア（１０２）に送られるコンテンツを暗号化および解読するのに必要な鍵を入手するために使用される。

ＩＰＲＭ鍵管理インタフェースは、潜在的に何百万ものユーザにスケーリングすることができ、ＫＤＣ（２０１）のような集中管理およびおそらく分散型データベースに対して、インタフェースとして機能することができるプロトコルを必要とする。例示としてのしかしこれに限定されないプロトコルとしては、電子セキュリティ・ブローカー（ＥＳＢｒｏｋｅｒ）プロトコルがある。ＥＳＢｒｏｋｅｒプロトコルは、Ｋｅｒｂｅｒｏｓ（ケルベロス）フレームワークをベースとしていて、ＫＤＣ、およびコンテンツ・プロバイダのサーバ（２００）およびキャッシング・サーバ（１０１）のような個々のアプリケーション・サーバとのクライアント相互作用からなる。これらの相互作用は、好適には、公開鍵アルゴリズムおよび対称鍵アルゴリズムの両方を使用することが好ましい。しかし、ＥＳＢｒｏｋｅｒプロトコル以外のプロトコルも使用することができる。ＥＳＢｒｏｋｅｒプロトコルまたは使用する任意の他のプロトコルは、好適には、一般的なもので、分散型環
境で認証および暗号化を必要とする異なるアプリケーションに容易に適合することができるものであることが好ましい。本明細書および添付の特許請求の範囲で使用する場合、別段の指定のないかぎり、ＥＳＢｒｏｋｅｒプロトコルは、ＩＰＲＭ鍵管理インタフェースで使用することができる任意の可能なプロトコルを参照するために使用される。

すでに説明したように、ＫＤＣ（２０１）はチケットを配布する。チケットは、サーバに対してそれ自身の認証を行う際に、クライアントを助ける記録である。好適なチケットは、クライアントの識別、セッション鍵、タイムスタンプ、およびその他の情報を含む。この情報すべては、サーバの秘密鍵により密封される。例えば、ビューア（１０２）は、次に相互認証のためにキャッシング・サーバ（１０１）に提示されるチケットを入手するために、ＫＤＣ（２０１）と通信しなければならない。キャッシング・サーバ（１０１）がそのチケットを有効なチケットであると判断した場合には、コンテンツのビューア（１０２）へのストリーミングを成功させることができる。

本発明のある実施形態によれば、チケットの使用はＥＳＢｒｏｋｅｒ鍵管理プロトコルの主要な部分である。図２の場合には、ビューア（１０２）およびコンテンツ・プロバイダ・サーバ（２００）は、両方ともキャッシング・サーバ（１０１）のクライアントである。さらに、キャッシング・サーバ（１０１）は、キャッシング・サーバ間でコンテンツを移動するための他のキャッシング・サーバのクライアントであってもよい。それ故、図２のすべてのエンティティは、好適には、ＫＤＣ（２０１）からチケットを入手することが好ましい。

図２に示すように、ＥＳＢｒｏｋｅｒ鍵管理プロトコル（２０４，２０５）は、好適には、コンテンツ・プロバイダのサーバ（２００）とキャッシング・サーバ（１０１）との間、およびキャッシング・サーバ（１０１）とビューア（１０２）との間でセキュア・セッションを確立するために使用することが好ましい。セキュア・セッションが確立された後で、コンテンツ・プロバイダのサーバ（２００）とキャッシング・サーバ（１０１）との間、およびキャッシング・サーバ（１０１）とビューア（１０２）との間で転送されるメッセージを暗号化し、および／または認証することができる。新しい各セキュア・セッションは、好適には、例えば、ビューア（１０２）およびキャッシング・サーバ（１０１）のような２つのホスト間だけで共有することができるそれ自身の一意の一組の鍵を有することが好ましい。鍵は、好適には、同じ２つのホスト間においても、複数のセキュア・セッション間で共有しないことが好ましい。

図２は、コンテンツ・プロバイダのサーバ（２００）からキャッシング・サーバ（１０１）への、またキャッシング・サーバ（１０１）からビューア（１０２）への例示としてのＲＴＰストリームである。本発明のある実施形態によれば、これらのＲＴＰストリームは暗号化され、そうしたい場合には、認証を行うことができる。図２は、また、キャッシング・サーバ（１０１）とビューア（１０２）間のＲＴＰストリームに関連するＲＴＣＰおよびＲＴＳＰ制御トラヒックも示す。この制御トラヒックは、また、好適には、サービスの拒否を生じる恐れがあるプロトコル操作攻撃から顧客のプライバシーを守りまた保護を行うために、暗号化および／または認証を行うことが好ましい。図２は、また、コンテンツ・プロバイダのサーバ（２００）からキャッシング・サーバ（１０１）への例示としてのＨＴＴＰダウンロードである。キャッシング・サーバ（１０１）からビューア（１０２）へのＨＴＴＰダウンロードも行うことができる。また、これらのＨＴＴＰダウンロードも、好適には、暗号化および／または認証を行うことが好ましい。

図２は、ビューア（１０２）とコンテンツ・プロバイダ（１００）の間の例示としてのＨＴＴＰインタフェースを示す。このＨＴＴＰインタフェースは、オプションであり、例えば、コンテンツ・ブラウジング、選択、「コンテンツ購入」スクリーン用に使用するこ
とができる。このＨＴＴＰインタフェースは、また、好適には、暗号化および／または認証により保護されることが好ましい。コンテンツへの条件付きアクセスを供給するためには保護は必要ない。しかし、例えば、顧客がコンテンツの購入を確認した後で、その顧客の選択および関連するコンテンツの規則を、顧客が自分の選択またはその関連するコストを変更するのを防止する目的で、暗号化により不正な変更から保護する必要がある。それ故、コンテンツ・プロバイダ（１００）は、好適には、セッション・ライツ・オブジェクト（ＳＲＯ）と呼ばれる暗号化により保護したオブジェクトにより、ユーザ選択およびコンテンツ規則を返送することが好ましい。ＳＲＯを保護するために、コンテンツ・プロバイダ（１００）は、好適には、これら２つのエンティティの間で直接交換した任意の鍵管理メッセージが存在しない場合でも、選択したキャッシング・サーバ（１０１）に対するチケットを入手することが好ましい。

図２は、また、キャッシング・サーバとそのデータベース（２０３）と間の好適なインタフェースも示す。図２に示すように、データベース（２０３）は、好適には、暗号化したコンテンツを記憶またはキャッシュ内に記憶することが好ましい。データベース内に記憶しているすべてのコンテンツは、好適には、暗号化することが好ましい。しかし、図２に示すように、データベース（２０３）のキャッシュ内に記憶している暗号化されたコンテンツは、好適には、キャッシング・サーバ（１０１）により解読し、次にビューア（１０２）に配信する前に、キャッシング・サーバ（１０１）により再度暗号化することが好ましい。

事前暗号化およびその関連する鍵管理および配布の好適な方法について、図３を参照しながら以下に説明する。図３は、事前暗号化機能を有する例示としてのＩＰＲＭアーキテクチャを示す。ＩＰＲＭ鍵管理インタフェースは、陰影付き矢印で示す。図３に示すように、コンテンツ・プロバイダ（１００）は、好適には、ビューア（１０２）にダウンロードまたはストリーミングされるコンテンツを含む記憶装置（２０２）を備えることが好ましい。コンテンツは、最初、好適には、コンテンツ・プロバイダ（１００）により作動されることが好ましい事前暗号化装置アプリケーション（３００）で暗号化される。事前暗号化装置アプリケーション（３００）は、コンテンツ・プロバイダ（１００）内に位置することもできるし、または別のホスト上に位置することもできる。コンテンツが暗号化された後で、そのコンテンツはもう１つの記憶装置（３０２）内に記憶される。いくつかのアプリケーションの場合には、この記憶装置（３０２）は、まだ暗号化されていないコンテンツを記憶するために使用したのと同じ記憶装置（２０２）である。記憶装置（３０２）は、図３に示すように、この時点で、事前暗号化装置アプリケーション（３００）ですでに暗号化されたコンテンツを含む。記憶装置（３０２）としては、ハード・ドライブのような任意のタイプの記憶デバイスを使用することができる。本発明のもう１つの実施形態は、それにより、記憶装置（３０２）内に記憶する前に、事前暗号化装置アプリケーション（３００）がコンテンツを暗号化し、ヒントを付ける方法を提供する。この場合、記憶装置（３０２）は、ヒントの付いた暗号化コンテンツを含む。

図３は、好適には、コンテンツの事前暗号化用に使用される鍵を生成し、記憶するために、鍵記憶サービス（ＫＳＳ）（３０１）でＥＳＢｒｏｋｅｒ鍵管理（３０３）を行うことが好ましい事前暗号化装置アプリケーション（３００）である。ＫＳＳ（３０１）は、好適には、特定のコンテンツの事前暗号化のための鍵を割当て、これらの鍵を永久に記憶し、要求された場合、これらの鍵をキャッシング・サーバ（１０１）に配布することができる自立形構成要素であることが好ましい。キャッシング・サーバ（１０１）は、次に、これらの鍵を使用することにより、事前に暗号化されたコンテンツを解読することができる。事前暗号化に使用するこれらの鍵は、ＥＳＢｒｏｋｅｒプロトコルの場合には、副鍵から入手される。副鍵は、ＥＳＢｒｏｋｅｒ鍵応答メッセージによりサーバが返送する秘密の値である。図３の例示としてのシナリオの場合には、このサーバは、ＫＳＳ（３０１
）である。Ｋｅｒｂｅｒｏｓ（ケルベロス）は、副鍵と類似のコンセプトを有する。この場合、副鍵は、Ｋｅｒｂｅｒｏｓ ＡＰ応答メッセージにより配信することができる。本明細書および添付の特許請求の範囲で使用する場合、別段の指定のない限り、「事前暗号副鍵」および「副鍵」という用語は、コンテンツの事前暗号化および認証、およびこの事前暗号化されたコンテンツの解読および保全性確認の際に使用する鍵を入手するために、ＫＳＳ（３０１）が生成する副鍵を示すために互換性を有して使用される。

ＫＳＳ（３０１）は、コンテンツがある実施形態により記憶され、事前暗号化されるコンテンツ・プロバイダ（１００）のサイト内に位置する。他の実施形態によれば、ＫＳＳ（３０１）は図３には示していない中央部分に位置する。さらに他の実施形態によれば、ＫＳＳ（３０１）は、事前暗号化装置アプリケーション（３００）と同じホスト上に常駐する。コンテンツ・プロバイダ（１００）は、好適には、キャッシング・サーバ（１０１）が、正しい副鍵を何処で入手できるのかが分かるように、ビューア（１０２）に送信されるＳＲＯ内のＫＳＳ（３０１）の位置をコード化することが好ましい。

事前暗号副鍵は、好適には、ＫＳＳ（３０１）内のリレーショナル・データベース内に記憶することが好ましい。データベース・インタフェースは、好適には、種々のリレーショナル・データベース・エンジンと相互運用することができる開放型データベース接続（ＯＤＢＣ）であることが好ましい。データベース内に記憶されている事前暗号副鍵は、好適には、ＫＤＣ（２０１）が、それが生成し配布する鍵の暗号化および認証に使用するのと同じ技術により、暗号化および認証することが好ましい。データベースは、好適には、下記のフィールド、すなわち、（１）コンテンツ識別または識別子（ＩＤ）、（２）暗号化した副鍵、（３）選択した暗号化および認証アルゴリズム、および（４）認証装置に事前暗号化したコンテンツの各部分についての記録を維持することが好ましい。コンテンツＩＤは、特定のＫＳＳ（３０１）に対して一意の識別子である。コンテンツの各部分はそれ自身のコンテンツＩＤを有する。例えば、コンテンツＩＤとしては、そのユニフォーム・リソース・ロケータ（ＵＲＬ）またはユニバーサル・リソース識別子（ＵＲＩ）を使用することができる。コンテンツＩＤを入手する正確な方法は、特定のアプリケーションにより異なり、ここではこれ以上説明しない。他の実施形態によれば、上記フィールドの他に他のフィールドも使用することができる。

図３に示すように、事前暗号化装置アプリケーション（３００）およびキャッシング・サーバ（１０１）は、好適には、ＫＳＳ（３０１）と通信するために、ＫＤＣ（２０１）からチケットを要求することが好ましい。しかし、事前暗号化装置アプリケーション（３００）およびＫＳＳ（３０１）が、同じホスト上に位置する場合には、事前暗号化装置アプリケーション（３００）は、特定のアプリケーションにより、ＫＳＳ（３０１）と通信するために、ＫＤＣ（２０１）からチケットを要求しなければならない場合もあるし、そうしないでもよい場合もある。

事前暗号化されたコンテンツをコンテンツ・プロバイダ（１００）から図３の構成のような構成のキャッシング・サーバ（１０１）に転送する場合には、このコンテンツを事前暗号化以外の他の任意の追加の機密保護を行わないで、従来のファイル転送プロトコルにより転送することができる。キャッシング・サーバ（１０１）は、事前暗号化されたコンテンツをそのまま記憶することができる。何故なら、このコンテンツはすでに暗号化されているからである。キャッシング・サーバ（１０１）がビューア（１０２）とのストリーミングまたはダウンロード・セッションをスタートした場合には、キャッシング・サーバは、ＫＳＳ（３０１）から適当な解読副鍵を入手するために、ＥＳＢｒｏｋｅｒ鍵管理（３０４）を使用する。キャッシング・サーバ（１０１）は、特定のクライアントおよびコンテンツに対して一意である鍵によりセキュア・ストリーミング・セッションをセットアップするために、ビューア（１０２）で同じＥＳＢｒｏｋｅｒ鍵管理（２０５）を依然と
して行うことに留意することが重要である。図２に関連して説明した事前暗号化を行わない場合と丁度同じように、ビューア（１０２）とのストリーミング・セッション中、キャッシング・サーバ（１０１）は、キャッシュ内に記憶している暗号化コンテンツを解読し、次にビューア（１０２）に対してセットアップしたセキュア・セッションによりそれを再度暗号化する。

図３に示すように、コンテンツ・プロバイダのサーバ（２００）とキャッシュ・サーバ（１０１）との間に、事前暗号化するのとは逆に進行中に暗号化されるＲＴＰストリーミング・セッションが存在する場合がある。事前暗号化されたコンテンツおよび進行中に暗号化されたコンテンツの両方を、好適には、同じＩＰＲＭアーキテクチャでサポートすることが好ましい。それは、ライブ・コンテンツのようなある種のコンテンツは、事前暗号化することができず、いつでもコンテンツ・プロバイダのサーバ（２００）により進行中に暗号化しなければならないからである。コンテンツ・プロバイダ（１００）は、好適には、コンテンツを事前暗号化するのか、進行中に暗号化するのかを選択することができることが好ましい。

他の実施形態の場合には、そうしたい場合には、メッセージ認証コード（ＭＡＣ）によりコンテンツの認証を行わなければならない。ＭＡＣは、コンテンツの記憶装置の事前暗号化された各単位に付属している。記憶の単位としては、パケットまたはフレームを使用することができる。

図４は、本発明のある実施形態を実施する際に使用することができる例示としての事前暗号化方法およびその関連する鍵管理および配布方法の詳細なフローチャートである。図４の例の場合には、事前暗号化装置アプリケーションがすでに要求され、ＫＳＳと通信することができるようにするチケットをＫＤＣから既に要求され、入手しているものと仮定する。

図４の事前暗号化方法は、ヒント付けプロセスをコンテンツの事前暗号化と結合することができる。このシナリオで生成された事前暗号化され、ヒントが付けられたコンテンツは、ビューア（１０２）にストリーミングするために、後でキャッシング・サーバ（１０１）にダウンロードすることができる。同様に、コンテンツが事前暗号化されているだけの場合には、事前暗号化されているコンテンツを後でキャッシング・サーバにダウンロードすることができる。本発明のある実施形態によれば、ビューア（１０２）にストリーミングする場合には、コンテンツにヒントを付けなければならない。

図４に示すように、事前暗号化方法は、事前暗号化装置アプリケーションがＫＳＳに鍵要求を送信することによりスタートする（４００）。鍵要求は、好適には、「記憶」行動コマンドを含むＥＳＢｒｏｋｅｒ鍵要求メッセージであることが好ましい。鍵要求は、そこからコンテンツ暗号鍵および認証鍵が入手される新しい事前暗号副鍵の生成を要求する。「記憶」行動コマンドを使用するのは、この場合、ＫＳＳが事前暗号副鍵を生成し、次に、そのデータベース内にその副鍵のコピーを記憶するからである。

しかし、すでに説明したように、ＫＳＳは、事前暗号化装置アプリケーションと同じホスト上に位置することができる。この場合、鍵要求コマンドは、好適には、事前暗号化装置アプリケーションによりＫＳＳに送信しないことが好ましく、ホストが遠隔地のＫＳＳが実行するすべての機能を実行することが好ましい。しかし、ＫＳＳは、図４の例の場合には遠隔地に位置する。ＩＰＲＭシステムは潜在的に複数のＫＳＳを有することができることに留意することが重要である。それ故、コンテンツ・プロバイダは、好適には、その事前暗号化装置アプリケーションを所望のＫＳＳと通信できるように構成することが好ましい。

図４に示すように、鍵要求は、好適には、コンテンツのコンテンツＩＤを含むことが好ましい。ＫＳＳが鍵要求を受信すると、ＫＳＳは最初、送信したコンテンツＩＤをそのデータベース内にすでに記憶しているコンテンツＩＤと比較する（４０１）。送信したコンテンツＩＤが、ＫＳＳデータベース内に既に記憶しているコンテンツＩＤのうちの１つと一致しない場合には、ＫＳＳは、新しい副鍵を生成する（４０３）。ＫＳＳは、次に、その関連する情報と一緒に、そのデータベース内にこの新しい副鍵をセーブする（４０４）。関連情報は、好適には、新しいコンテンツＩＤおよび選択した暗号化および認証アルゴリズムを含むことが好ましい。

しかし、送信したコンテンツＩＤが、ＫＳＳデータベース内にすでに記憶しているコンテンツＩＤのうちの１つと一致する場合には、新しい副鍵は生成されず（４０２）、鍵要求はＫＳＳにより拒否される。その理由は、暗号化されるコンテンツとすでに事前暗号化したコンテンツのもう一方との間にネーミングの衝突があると見なされるからである。コンテンツ・プロバイダが、あるコンテンツを変更して、次に、再度事前暗号化したい場合には、コンテンツ・プロバイダは、新しいコンテンツＩＤ（例えば、コンテンツ・バージョン番号を含むＵＲＬまたはＵＲＩ）を定義することができる。別の方法としては、コンテンツ・プロバイダは、ＫＳＳデータベース内のこのコンテンツに対する現在のエントリを最初に除去するために、管理インタフェースを使用することができる。

図４に示すように、新しい副鍵およびその関連情報をＫＳＳデータベースに記憶した後で、ＫＳＳは事前暗号化装置アプリケーションに新しい事前暗号副鍵を送信する（４０５）。選択した暗号化および認証アルゴリズムも、好適には、この送信に含めることが好ましい。この送信は、好適には、ＥＳＢｒｏｋｅｒ鍵応答メッセージを送信することにより行うことが好ましい。

この時点で、事前暗号化装置アプリケーションは、ＫＳＳから受信した副鍵を用いてコンテンツを事前暗号化する（４０６）。コンテンツを事前暗号化した後で、このコンテンツを、図３のところで説明したように、好適には、記憶装置に記憶することが好ましい（４０７）。この時点で、事前暗号化したコンテンツを、コンテンツ転送中に適用された任意の追加機密保護を使用しないで、標準ファイル・ダウンロード・プロトコルによりキャッシング・サーバにダウンロードすることができる。

図４の鍵管理および配布方法の１つの利点は、事前暗号化装置アプリケーションから独立していることである。そのため、コンテンツと暗号鍵とを同じ場所で管理することもできるし、または暗号鍵を遠隔地で管理することもできる。

本発明のもう１つの利点は、キャッシング・サーバが将来検索することができるように、副鍵をデータベース内にＫＳＳにより永久に記憶することができることである。図５は、それにより、事前暗号化したコンテンツを解読できるように、事前暗号化したコンテンツの特定の部分に関連する副鍵が、キャッシング・サーバにより検索される例示としての方法を示すフローチャートである。

図５の例示としての方法は、キャッシング・サーバが、コンテンツ・プロバイダから事前暗号化したコンテンツをすでにダウンロードしているものと仮定する。さらに、図５の例の場合には、キャッシング・サーバが、ＫＳＳと通信できるようにするＫＤＣからのチケットをすでに要求し、入手しているものと仮定する。

図５の方法は、ビューアが、キャッシング・サーバにビューアのチケットおよびＳＲＯ（セッション・ライツ・オブジェクト）により、鍵要求を送信することによりスタートす
る（５００）。キャッシング・サーバは、ＳＲＯおよびチケットを評価し、このビューアが要求したコンテンツを受信するための許可を得ているものと判断する。次に、キャッシング・サーバは、自分がビューアに配信するコンテンツを再度暗号化するために使用する新しい副鍵を生成し、この副鍵をビューアに返送する（５０１）。しかし、要求したコンテンツが事前暗号化されているために、キャッシング・サーバは現在、対応する事前暗号副鍵を有していない。それ故、キャッシング・サーバは、次に、鍵要求、および解読する事前暗号化されたコンテンツに関連するコンテンツＩＤをＫＳＳに送信する（５０２）。キャッシング・サーバは、好適には、事前暗号鍵をローカルにキャッシュ内に記憶し、そのため次回他のビューアが同じコンテンツを要求した場合、キャッシュ・サーバは、ローカルに記憶している事前暗号副鍵のコピーをすでに有していて、ＫＳＳに再度鍵要求を送信する必要はない。鍵要求は、好適には、「検索」行動コマンドを含むＥＳＢｒｏｋｅｒ鍵要求メッセージであることが好ましい。「検索」行動コマンドが使用されるのは、キャッシング・サーバがＫＳＳから副鍵を検索したがっているからである。

図５に示すように、鍵要求は、好適には、事前暗号化されたコンテンツに関連するコンテンツＩＤを含むことが好ましい。ＫＳＳが鍵要求を受信すると、ＫＳＳは、最初に、送信したコンテンツＩＤをそのデータベース内にすでに記憶しているコンテンツＩＤと比較する（５０３）。送信したコンテンツＩＤが、ＫＳＳデータベース内にすでに記憶しているコンテンツＩＤのうちの１つと一致しない場合には、副鍵はキャッシング・サーバに送信されず（５０４）、事前暗号化されたコンテンツの解読に成功することはできない。

しかし、送信したコンテンツＩＤが、ＫＳＳデータベース内にすでに記憶しているコンテンツＩＤのうちの１つと一致する場合には、ＫＳＳは、好適には、そのデータベース内の一致するコンテンツＩＤに関連する副鍵をキャッシング・サーバに送信することが好ましい（５０５）。この送信は、好適には、ＥＳＢｒｏｋｅｒ鍵応答メッセージを送信することにより行うことが好ましい。キャッシング・サーバは、次に、入手した副鍵を用いて事前暗号化されたコンテンツを解読する（５０６）。好適には、事前暗号化されたコンテンツを解読するために副鍵を直接使用しないことが好ましい。代わりに、コンテンツ解読鍵および認証鍵が最初副鍵から入手され、次にコンテンツを解読し、認証するために使用される。キャッシング・サーバは、次に、コンテンツを再度暗号化し、異なる副鍵から入手したコンテンツ暗号鍵および認証鍵を用いて、メッセージの保全性に対する新しいメッセージ認証コード（ＭＡＣ）を生成することができる（５０７）。このステップで使用する副鍵は、キャッシング・サーバがビューアに送信したのと同じ副鍵である（５０１）。

好適なＩＰＲＭシステムが、事前暗号化および鍵管理および配布を行うことができる例示としてのシナリオについて以下に説明する。このシナリオは、上記実施形態を示す。さらに、このシナリオは、本発明のいくつかの追加の実施形態を必要とする。このシナリオの場合には、顧客はコンテンツ・プロバイダから自分のビューアにストリーミングまたはダウンロードするオンデマンド・コンテンツを要求する。ビューアは、好適には、パーソナル・コンピュータ、またはインターネットからコンテンツをダウンロードすることができる任意の他の電子デバイスであることが好ましい。最初に、顧客は標準インターネット・ウェブ・ブラウザにより検索エンジンに連絡する。顧客は、この検索エンジンにより自分の所望のコンテンツを発見することができる。顧客が所望のコンテンツを発見すると、顧客のビューアはコンテンツ・プロバイダに切り替えられる。

次に、ビューアは、自分が切り替えられたコンテンツ・プロバイダに連絡し、キャッシング・サーバのその好適なリスト、加入者サービスのリスト、コンテンツに対する支払い能力、および特定のアプリケーションが指定する任意の他の関連情報を送る。コンテンツ・プロバイダは、次に、特定の顧客およびサービスのコンテキストによる購入オプションの最適化したサブセットを供給する。例えば、そのサービスにすでに加入している顧客の
場合には、価格選択スクリーンをバイパスすることができる。

コンテンツ・プロバイダは、次に、好適には、顧客が選択した購入オプションを収容するＳＲＯ、オプションとしての一組のコンテンツ・アクセス規則（例えば、ブラックアウト領域）、および選択したコンテンツへの参照を生成することが好ましい。コンテンツ・プロバイダは、次に、ビューアを適当なキャッシング・サーバに切り替える。

ビューアが、関連キャッシング・サーバ・チケットをすでにキャッシュ内に記憶している場合には、ビューアはそのチケットを検索する。ビューアがチケットをキャッシュ内に記憶していない場合には、ビューアはＫＤＣに連絡し、キャッシュ・サーバと通信できるようにするチケットを要求する。いくつかのアプリケーションの場合には、ビューアはＫＤＣにチケット許可チケット（ＴＧＴ）を送信することにより、このチケット要求を行う。ＴＧＴは、キャッシング・サーバのチケットを入手する目的で、ビューアが、チケット許可サービス（例えば、ＫＤＣ）と話をするために選択することができるようにするために、信頼のトークンとして使用される。

ビューアは、次に、キャッシング・サーバ・チケットにより、キャッシング・サーバに対して自分自身の認証を行う。認証に成功した後で、ビューアはコンテンツ・プロバイダから入手したＳＲＯをキャッシング・サーバに転送する。キャッシング・サーバは、次に、ＳＲＯからそのチケット内に含まれるビューアの資格に対してアクセス規則をチェックする。キャッシング・サーバがビューアの要求を承認した場合には、ビューアおよびキャッシング・サーバは、ＥＳＢｒｏｋｅｒ鍵管理によりコンテンツを配信するための鍵について交渉する。

ビューアは、次に、コンテンツ（例えば、そのＲＴＳＰ ＵＲＬ）の記述を入手し、次にコンテンツの再生を要求するために、キャッシング・サーバに対するＲＴＳＰコマンドの発行をスタートする。ＲＴＳＰコマンドは、好適には、暗号化し認証することが好ましい。しかし、いくつかのアプリケーションの場合には、ＲＴＳＰコマンドの暗号化および認証はできない。

キャッシング・サーバは、ＲＴＳＰコマンドを受信し、それを復号し、ＲＴＳＰ応答を返送する。ビューアが、ＲＴＳＰコマンドを暗号化した形で送信した場合には、キャッシング・サーバのＲＴＳＰ応答も、好適には、暗号化することが好ましい。ＲＴＳＰコマンドが特定のＵＲＬの再生を要求している場合には、キャッシング・サーバは、指定ＵＲＬが、特定のセッションに対してＳＲＯ内で指定されたものであることを確認する。

ＲＴＳＰ ＵＲＬの再生に対する要求を受信した後で、キャッシング・サーバは、暗号化したＲＴＰパケットの送信をスタートし、キャッシング・サーバおよびビューアの両方は、周期的にＲＴＣＰ報告パケットを送信する。ＲＴＣＰパケットも、好適には、暗号化し、認証することが好ましい。しかし、いくつかのアプリケーションの場合には、そうすることはできないし、また望ましいことではない。同じＲＴＳＰ ＵＲＬに関連するすべてのＲＴＰおよびＲＴＣＰパケットは、好適には、同じセキュア・セッションにより暗号化することが好ましい。

キャッシング・サーバが、ビューアに暗号化したペイロードを含むＲＴＰパケットの送信をスタートする前に、対応するコンテンツ用の暗号解読鍵を入手しなければならない。コンテンツ・プロバイダのサーバが進行中の暗号化を使用して、キャッシング・サーバにコンテンツを配信した場合には、キャッシング・サーバは、ローカルに生成した鍵を用いて、局所記憶装置に対するコンテンツを事前に再度暗号化する。それ故、この場合、キャッシング・サーバは、コンテンツを解読するのに必要な暗号解読鍵をすでに有している。

しかし、コンテンツが、事前暗号化装置アプリケーションにより事前暗号化されていた場合には、キャッシング・サーバは、コンテンツ解読鍵をまだ有していない場合がある。その場合には、キャッシング・サーバは、このコンテンツ解読鍵を入手するために、下記のステップを行う。最初に、キャッシング・サーバは、事前暗号化されたコンテンツに対するＫＳＳの位置を決定する。この位置は、ビューアから前に入手したＳＲＯ内に含まれているか、キャッシング・サーバ内で手動で予め構成することができる。次に、キャッシング・サーバは、事前暗号化されたコンテンツに対する副鍵を要求するＫＳＳに鍵要求メッセージを送信する。このメッセージはコンテンツＩＤを含む。ＫＳＳは、次に、事前暗号副鍵、および好適には、特定のコンテンツを事前暗号化するために使用した暗号化および認証アルゴリズム用のＩＤを含む鍵応答メッセージで応答する。キャッシング・サーバは、また、好適には、同じコンテンツに対する同じまたは別のビューアからの以降の要求に対して、この事前暗号副鍵のコピーをセーブする。

キャッシング・サーバは、次に、副鍵を用いて、そのローカル記憶装置から読み出した各ＲＴＰパケット・ペイロードを解読する。キャッシング・サーバは、次に、ビューアとＥＳＢｒｏｋｅｒ鍵管理により確立している異なる鍵を用いてこのコンテンツを再度暗号化する。再度暗号化されたペイロードを含むＲＴＰパケットは、次に、ビューアに送られる。

ビューアは、次に、コンテンツを解読し、再生する。同時に、ビューアは、同じセキュア・セッションにより暗号化することができる追加のＲＴＳＰコマンドを発行することができる。これらの追加のＲＴＳＰコマンドは、例えば、コンテンツの再生を一次停止または再開するコマンドを含むことができる。

キャッシング・サーバは、好適には、コンテンツを見た人、コンテンツを見た時間、どの機構でコンテンツが購入されたかを追跡することができることが好ましい。この情報は、次に、課金目的、または特定のアプリケーションが必要であると考える他の目的のために使用することができる。

上記説明は、本発明の実施形態を説明するためだけのものである。開示した任意の正確な形で本発明全部をあますところなく説明するためのものでもなければ、本発明を制限するためのものでもない。上記開示を見れば、多くの修正および変更を行うことができる。本発明の範囲は特許請求の範囲により定義される。

本発明のある実施形態を実施するために使用することができる例示としてのコンテンツ配信アーキテクチャを示す概念図。 キャッシング・サーバを通してコンテンツ・プロバイダからビューアにコンテンツを機密保護状態でストリーミングまたはダウンロードする好適なＩＰＲＭアーキテクチャを示す概念図。 事前暗号化アプリケーションおよびその関連する鍵管理および配布システムを含む例示としてのＩＰＲＭアーキテクチャを示す概念図。 本発明のある実施形態を実施するために使用することができる例示としての事前暗号化方法およびその関連する鍵管理および配布方法の詳細を示すフローチャート。 事前暗号化されたコンテンツを解読することができるように、事前暗号化されたコンテンツの特定の部分と関連する副鍵が、キャッシング・サーバにより検索される例示としての方法を示すフローチャート。

Claims (57)

1. コンテンツ・プロバイダから、ビューアにコンテンツを配布するキャッシング・サーバに、前記コンテンツを送信するための方法であって、前記方法は、前記コンテンツが前記キャッシング・サーバに送信される前に、事前暗号化装置アプリケーションによって前記コンテンツを暗号化するステップを備え、前記事前暗号化装置アプリケーションは鍵記憶サービスが提供する事前暗号副鍵を使用して前記事前暗号化を行う方法。
2. 前記コンテンツ・プロバイダは前記コンテンツが前記キャッシング・サーバに送信される前に、記憶装置に前記事前暗号化装置アプリケーションで暗号化される前記コンテンツを電子的に記憶する、請求項１に記載の方法。
3. 前記コンテンツと関連するコンテンツ識別子を含む鍵要求を前記事前暗号化装置アプリケーションから前記鍵記憶サービスに送信するステップと、
   前記コンテンツ識別子を、前記鍵記憶サービスのデータベース内にすでに存在するコンテンツ識別子と比較するステップとをさらに備え、
   前記コンテンツ識別子が、前記鍵記憶サービスの前記データベース内にすでに存在する前記コンテンツ識別子のうちの１つと一致しない場合、前記鍵記憶サービスが、前記事前暗号副鍵を生成し、前記データベース内に前記事前暗号副鍵および前記コンテンツ識別子のコピーを記憶し、前記事前暗号副鍵を、前記コンテンツの前記事前暗号化の際に使用する前記事前暗号化装置アプリケーションに送信する、請求項１に記載の方法。
4. 前記ビューアに前記コンテンツを配布する前に、前記キャッシング・サーバが前記事前暗号副鍵のコピーにより、前記事前暗号化装置アプリケーションで暗号化される前記コンテンツを解読し、次に、前記キャッシング・サーバと前記ビューアとの間で共有する異なる副鍵を用いて前記コンテンツを再度暗号化する、請求項３に記載の方法。
5. 前記キャッシング・サーバは、前記コンテンツが解読された後再度暗号化され、および前記ビューアに配布される前に、事前暗号化される前記コンテンツを記憶装置に電子的に記憶する、請求項４に記載の方法。
6. 前記コンテンツと関連する前記コンテンツ識別子を含む鍵要求を前記キャッシング・サーバから前記鍵記憶サービスに送信するステップと、
   前記コンテンツ識別子を、前記鍵記憶サービスの前記データベース内にすでに存在する前記コンテンツ識別子と比較するステップとをさらに備え、
   前記コンテンツ識別子が、前記鍵記憶サービスの前記データベース内にすでに存在する前記コンテンツ識別子のうちの１つと一致する場合、前記鍵記憶サービスが、前記コンテンツ識別子に関連する前記事前暗号副鍵のコピーを、前記コンテンツの前記解読の際に使用する前記キャッシング・サーバに送信する、請求項４に記載の方法。
7. 前記キャッシング・サーバは将来のアクセスおよび使用のために記憶装置に前記事前暗号副鍵の前記コピーを記憶する、請求項６に記載の方法。
8. 前記コンテンツ・プロバイダは前記ビューアにセッション・ライツ・オブジェクトを送信し、前記セッション・ライツ・オブジェクトが前記鍵記憶サービスの位置に関する情報を備える、請求項６に記載の方法。
9. 前記事前暗号化装置アプリケーションが、前記コンテンツにヒントを与える、請求項１に記載の方法。
10. 前記コンテンツ・プロバイダと、前記キャッシング・サーバと、前記ビューアとは、それぞれチケットを入手するために鍵配布センターと電子的に通信し、前記チケットが、前記コンテンツ・プロバイダと、前記キャッシング・サーバと、前記ビューアとの間で安全な電子通信を行えるようにするセッション鍵を備える、請求項１に記載の方法。
11. 前記セッション鍵を使用して、前記コンテンツ・プロバイダと、前記キャッシング・サーバと、前記ビューアとの間の前記通信を暗号化するステップをさらに含む、請求項１０に記載の方法。
12. 前記キャッシング・サーバから前記ビューアに、前記コンテンツをストリーミングするステップをさらに含む、請求項１に記載の方法。
13. 前記キャッシング・サーバから前記ビューアに、前記コンテンツをダウンロードするステップをさらに含む、請求項１に記載の方法。
14. 前記コンテンツ・プロバイダから前記キャッシング・サーバに前記コンテンツをストリーミングするステップをさらに含む、請求項１に記載の方法。
15. 前記コンテンツ・プロバイダから前記キャッシング・サーバに前記コンテンツをダウンロードするステップをさらに含む、請求項１に記載の方法。
16. 前記コンテンツの記憶装置の各ユニットに付属しているメッセージ認証コードを用いて前記コンテンツの認証を行うステップをさらに備える、請求項１に記載の方法。
17. 前記ビューアが複数のビューアを備え、それぞれが前記キャッシング・サーバと前記異なる副鍵を共有する、請求項４に記載の方法。
18. コンテンツ・プロバイダからキャッシング・サーバへのコンテンツの送信、およびさらに、前記キャッシング・サーバからビューアへのコンテンツの送信を管理するためのインターネット・プロトコル・ライツ管理システムであって、前記システムは、
    前記コンテンツが前記キャッシング・サーバに送信される前に、前記コンテンツを暗号化するための事前暗号化装置アプリケーションと、
    事前暗号副鍵を生成し、記憶し、配布するための自立形鍵記憶サービスとを備え、
    前記コンテンツを暗号化するために前記事前暗号化装置アプリケーションによって使用され、および、前記コンテンツが暗号化されおよび前記キャッシング・サーバに送信された後で前記コンテンツを解読するために前記キャッシング・サーバによって使用される事前暗号副鍵を、前記鍵記憶サービスが生成するシステム。
19. 前記コンテンツ・プロバイダが、
    前記キャッシング・サーバおよび前記ビューアと電子的に通信するためのサーバと、
    前記事前暗号化装置アプリケーションにより暗号化される前記コンテンツを電子的に記憶するための記憶装置とを備える、請求項１８に記載のシステム。
20. 前記記憶装置がハード・ドライブである、請求項１９に記載のシステム。
21. 前記事前暗号化装置アプリケーションが、鍵要求を前記鍵記憶サービスに送信し、前記鍵要求が、前記コンテンツに関連するコンテンツ識別子を備える、請求項１９に記載のシステム。
22. 前記鍵記憶サービスが、前記コンテンツ識別子を、前記鍵記憶サービスのデータベース
    内にすでに記憶しているコンテンツ識別子と比較する、請求項２１に記載のシステム。
23. 前記コンテンツ識別子が、前記鍵記憶サービスの前記データベース内にすでに記憶している前記コンテンツ識別子のうちの１つと一致しない場合、前記鍵記憶サービスが、前記事前暗号副鍵を生成し、前記データベース内に前記事前暗号副鍵および前記コンテンツ識別子のコピーを記憶し、前記事前暗号副鍵を前記コンテンツの前記事前暗号化の際に使用する前記事前暗号化装置アプリケーションに送信する、請求項２２に記載のシステム。
24. 前記キャッシング・サーバが、事前暗号化される前記コンテンツを電子的に記憶するための記憶装置を備え、前記事前暗号副鍵が、前記事前暗号化されたコンテンツを解読するために使用される、請求項１８に記載のシステム。
25. 前記キャッシング・サーバが、前記ビューアと共有する別の副鍵を用いて前記コンテンツを再度暗号化する、請求項２４に記載のシステム。
26. 記憶装置がハード・ドライブである、請求項２４に記載のシステム。
27. 前記キャッシング・サーバが、鍵要求を前記鍵記憶サービスに送信し、前記鍵要求が、前記コンテンツに関連するコンテンツ識別子を備える、請求項２３に記載のシステム。
28. 前記鍵記憶サービスが、前記キャッシング・サーバから送られる前記コンテンツ識別子を、前記鍵記憶サービスのデータベース内にすでに存在するコンテンツ識別子と比較する、請求項２７に記載のシステム。
29. 前記キャッシング・サーバから送られた前記コンテンツ識別子が、前記鍵記憶サービスの前記データベース内にすでに存在する前記コンテンツ識別子のうちの１つと一致する場合、前記鍵記憶サービスが、前記コンテンツ識別子に関連する前記事前暗号副鍵のコピーを、前記コンテンツの前記解読の際に使用する前記キャッシング・サーバに送信する、請求項２８に記載のシステム。
30. 前記キャッシング・サーバが、前記事前暗号副鍵のコピーをセーブする、請求項２９に記載のシステム。
31. 前記コンテンツ・プロバイダが、前記ビューアにセッション・ライツ・オブジェクトを送信し、前記セッション・ライツ・オブジェクトが、前記鍵記憶サービスの位置に関する情報を備える、請求項２９に記載のシステム。
32. 前記事前暗号化装置アプリケーションが、前記コンテンツにヒントを与える、請求項１８に記載のシステム。
33. 前記システムが、前記コンテンツ・プロバイダと、前記キャッシング・サーバと、前記ビューアに対してチケットを生成し、管理し、配布するための鍵配布センターをさらに備え、前記チケットが、前記コンテンツ・プロバイダと、前記キャッシング・サーバと、前記ビューアとの間の安全な電子通信を可能にするセッション鍵を備える、請求項１８に記載のシステム。
34. コンテンツの送信の前記管理が、電子セキュリティ・ブローカー・プロトコルにより行われる、請求項１８に記載のシステム。
35. 前記コンテンツがビデオ・オン・デマンドを備える、請求項１８に記載のシステム。
36. 前記コンテンツがマルチメディア・ストリーミング・コンテンツである、請求項１８に記載のシステム。
37. 前記コンテンツが、ダウンロードすることができるコンテンツである、請求項１８に記載のシステム。
38. 前記コンテンツ・プロバイダおよび前記キャッシング・サーバが、前記コンテンツの記憶装置の各ユニットに付属しているメッセージ認証コードを用いて前記コンテンツの認証を行う、請求項１８に記載のシステム。
39. 記憶装置の前記ユニットがパケットである、請求項３８に記載のシステム。
40. 記憶装置の前記ユニットがフレームである、請求項３８に記載のシステム。
41. 前記ビューアが、前記コンテンツを表示し、管理し、または使用することができるホストを備える、請求項１８に記載のシステム。
42. 前記鍵記憶サービスが、前記コンテンツ・プロバイダの位置に位置する、請求項１８に記載のシステム。
43. 前記鍵記憶サービスが、前記事前暗号化装置アプリケーションのホスト上に位置する、請求項１８に記載のシステム。
44. 前記キャッシング・サーバが、それぞれが前記コンテンツ・プロバイダからコンテンツを受信することができる複数のキャッシング・サーバを備える、請求項１８に記載のシステム。
45. 前記ビューアが、前記キャッシング・サーバと同時に電子的に通信することができる複数のビューアを備える、請求項１８に記載のシステム。
46. コンテンツ・プロバイダから、コンテンツをビューアに配布するキャッシング・サーバに、前記コンテンツを送信するためのシステムであって、前記システムは、
    前記コンテンツを前記キャッシング・サーバに送信する前に、事前暗号副鍵を使用する事前暗号化装置アプリケーションで前記コンテンツを暗号化するための手段と、
    鍵記憶サービスで前記事前暗号副鍵を生成し、記憶し、配布するための手段とを備えるシステム。
47. 前記コンテンツが前記キャッシング・サーバに送信される前に、前記事前暗号化装置アプリケーションにより暗号化される前記コンテンツを電子的に記憶するための手段をさらに備える、請求項４６に記載のシステム。
48. 前記事前暗号化装置アプリケーションから前記鍵記憶サービスに、前記コンテンツに関連するコンテンツ識別子を含む鍵要求を送信するための手段と、
    前記コンテンツ識別子を、前記鍵記憶サービスのデータベース内にすでに存在するコンテンツ識別子と比較するための手段とをさらに備え、
    前記コンテンツ識別子が、前記鍵記憶サービスの前記データベース内にすでに存在する前記コンテンツ識別子のうちの１つと一致しない場合、前記鍵記憶サービスが、前記事前暗号副鍵を生成し、前記データベース内に前記事前暗号副鍵のコピーおよび前記コンテンツ識別子を記憶し、前記事前暗号副鍵を、前記コンテンツの前記事前暗号化の際に使用す
    る前記事前暗号化装置アプリケーションに送信する、請求項４６に記載のシステム。
49. 前記事前暗号副鍵のコピーを用いて、前記事前暗号化装置アプリケーションで暗号化される前記コンテンツを解読するための手段と、
    前記キャッシング・サーバと前記ビューアとの間で共有する異なる副鍵を用いて前記コンテンツを再度暗号化するための手段とをさらに備える、請求項４８に記載のシステム。
50. 前記コンテンツが解読され、再度暗号化され、前記ビューアに配布される前に、前記キャッシング・サーバ内の記憶装置で事前暗号化される前記コンテンツを電子的に記憶するための手段をさらに備える、請求項４９に記載のシステム。
51. 前記キャッシング・サーバから前記鍵記憶サービスに、前記コンテンツに関連する前記コンテンツ識別子を含む鍵要求を送信するための手段と、
    前記コンテンツ識別子を、前記鍵記憶サービスの前記データベース内にすでに存在する前記コンテンツ識別子と比較する手段とをさらに備え、
    前記コンテンツ識別子が、前記鍵記憶サービスの前記データベース内にすでに存在する前記コンテンツ識別子のうちの１つと一致する場合、前記鍵記憶サービスが、前記コンテンツ識別子に関連する前記事前暗号副鍵のコピーを、前記コンテンツの前記解読の際に使用される前記キャッシング・サーバに送信する、請求項５０に記載のシステム。
52. 前記コンテンツ・プロバイダから前記ビューアに前記鍵記憶サービスの位置に関する情報を送信するための手段をさらに備える、請求項５１に記載のシステム。
53. 前記コンテンツにヒントを与えるための手段をさらに備える、請求項４６に記載のシステム。
54. 鍵配布センターからセッション鍵を備えるチケットを入手するための手段をさらに備える、請求項４６に記載のシステム。
55. 前記キャッシング・サーバから前記ビューアに前記コンテンツをストリーミングするための手段をさらに備える、請求項４６に記載のシステム。
56. 前記キャッシング・サーバから前記ビューアに前記コンテンツをダウンロードするための手段をさらに備える、請求項４６に記載のシステム。
57. 前記コンテンツの記憶装置の各ユニットに付属しているメッセージ認証コードを用いて前記コンテンツの認証を行うための手段をさらに備える、請求項４６に記載のシステム。

Images