JP4472989B2 - ストリーミング・メディア用の使用権管理方法 - Google Patents

Description

本発明は，一般的にはネットワークを介して提供されたデジタル・コンテンツの管理のための使用権管理（デジタル・ライツ・マネジメンツ：ＤＲＭ）に関し，特に，ストリーミング・メディア用の使用権を管理するために使用する方法，装置及びシステムに関する。

現代のデジタル通信テクノロジを使用するデジタル・コンテンツまたはメディア・データの配信は絶えず成長し，更に多くの伝統的な配信方法に取って代わりつつある。特に，コンテンツ・プロバイダからクライアントまたはユーザに対し，ネットワークを介してデジタル・コンテンツをダウンロードまたはストリーミングし，これにより一般的には，そのデジタル・コンテンツに関連したライセンスで明示されたなんらかのユーザの権利または使用規則に従いレンダリング装置を使用してコンテンツをレンダリングする傾向は増大している。配信が高価ではなく迅速かつ容易であるこの形状のコンテンツ配信の利点のために，オーディオ，ビデオ，画像，電子ブック及びソフトウエア，特に，モバイル電話のシーン用のリング信号及び背景画像のようなモバイル電話の特定コンテンツのようなあらゆる種類のコンテンツの配信用のアプリケーションを現在見つけることができる。

しかし，デジタル・メディア・コンテンツの配信のこの新しい方法の場合は，コンテンツ・プロバイダのデジタル資産を権限の無い使用及び不正なコピーから守る必要が生じる。デジタル・コンテンツの著作権保持者及び創作者たちは自分たちの権利の保護の強力な経済的利益を当然有し，これにより，使用権管理の要求（DRM;demand for right management）は増大している。ＤＲＭは，一般的には，デジタル・コンテンツの使用を保護し，監視し，これを制限すること並びに支払いの取り扱いを含む，デジタル・コンテンツ配信システムで，コンテンツ・プロバイダの財産を保護するテクノロジである。従って，ＤＲＭシステムは，暗号化，認証，鍵管理，使用規則の管理及び料金請求のための要素を通常有している。

ＤＲＭシステムに対する最も基本的な恐れには，盗聴，不正コピー，使用規則の改変及びＤＲＭ保護の除去並びに大規模不正使用のための非保護コンテンツの再配信がある。これらの基本的なセキュリティ問題の大部分は，暗号化，認証，完全性保護及び鍵管理を含む標準的な暗号化技術により解決される。しかし，ＤＲＭシステムのセキュリティ問題が他の一般的なセキュリティ問題と基本的に異なる点は，通信の相手側（ユーザ）でさえ完全には信用されないということである。実際，エンド・ユーザは，例えば，自分の支払い回数よりも多くメディア・コンテンツを表現させたり，または他のレンダリング装置に対してデジタル・コンテンツを不正にコピーしたりして，自分の使用権を詐欺により拡張しようとすることを望むかもしれない。従って，クライアントのレンダリング装置では，何らかの形式の規則施行が要求される。このためには，ソフトウエアとして実行されるＤＲＭエージェントまたはモジュール及び／またはレンダリング装置の改ざん防止回路及び使用規則を表現する何らかの正式な言語は，上記の基本的な暗号化技術と共に普通使用される。暗号化の一般的背景については，［ＨＡＣ］を参照する。

上記の全てのメディアの種類は，信頼性のある輸送プロトコルを使用してユーザの装置にダウンロード可能であるが，リアルタイムのアプリケーションのため及び他の理由で，音楽またはビデオのようなメディアをデジタル的にクライアントにストリーミングするということは時々望ましいことである。メディアのストリーミングとは，全メディア・データを受信する前にこのデータの使用を可能にする効率的な方法で連続流の形でクライアントにデータを転送することを意味する。ストリーミングがダウンロードよりも実現の可能性がある例としては，例えば，レンダリングの前に，そのメディアの全部または一部をダウンロードすることがリアルタイム要件または記憶要件のために実現できないような長期間の生のスポーツ・イベントまたはミュージック・コンサートまたは他のメディアがある。

ストリーミングは，通常，エラーまたはデータの一部の喪失を生じる可能性のある信頼できない輸送機構を使用して行われる。（我々は「漸進的なダウンロード」をストリーミングとは考えない，これについては以下更に述べる。）信頼できない輸送機構を使用する理論的根拠は，リアルタイム要件がそんなに厳しいので，喪失したメディア・データを再送する時間が存在しない可能性があり，そして品質喪失の危険は，時々は容認可能であり，及び／またはエラー訂正符号または他の技術手段により管理される。メディアのダウンロード及びストリーミングは，ここで述べた相違が原因で固有のものであり，そして，輸送の相違のため，コンテンツの保護のために異なる手段を必要とし，また使用権管理の場合に特別な処置を必要とする。この相違点は，障害及びデータ喪失が有線ネットワークにおけるよりもしばしば起こるモバイル電話ネットワークのような無線ネットワークで強調される。

本発明は，特に，ダウンロード・コンテンツ用のＤＲＭ及びストリーミング・メディア用のＤＲＭに共通なソリューションを有する。このソリューションは，コンテンツを保護し使用権を管理するダウンロードＤＲＭ用の現存のシステムで事実上衝撃なしに実行することができる。

（最先端技術）
次は，クライアントにより使用される「コンテンツ」に関する使用権管理の本技術の記載である。コンテンツとは，一般にデジタル・データ・オブジェクトのことであって，（ＴＣＰ（これについては後で更に述べる）のような）信頼可能な輸送プロトコルを使用してダウンロード可能である。ダウンロード可能なデジタル・コンテンツの例には，オーディオ，ビデオ，画像，電子ブック及びソフトウエアが含まれ，特に，リング信号及びモバイル電話のスクリーン用の背景画像のようなモバイル電話の特定コンテンツが含まれる。このコンテンツには，クライアントの使用規則及び得られたデジタル・メディアに関する使用権を明示するライセンスが関連している。

ＤＲＭは，デジタル・コンテンツそれ自体を管理することに関し，誰がそれを得るか，どのように送るか，どのように使用（レンダリング，保存，送信，コピー，実行及び／または変形）してよいか，何回使用してよいか，どの位長く使用権が続くのか，誰が支払うのか，どの位支払うのか，そして，方法のような問題を扱う。これらの問題の一部または全ては，ライセンスで明示してもよく，デジタル・コンテンツと共にまたは別々に送ってもよい。使用規則を記載するために，使用権表現言語と呼ばれる特別な言語が開発されている。今日使用されている最も一般的な使用権表現言語の２つは，エックステンシブル・ライツ・マークアップ・ラングウィジ（ＸｒＭＬ）とオープン・デジタル・ライツ・ラングウィジ（ＯＤＲＬ）である。

ＤＲＭの最も困難な部分は，ライセンスに含まれていてデジタル・コンテンツについて規定された使用規則を守らせることである。背景技術に示したように，改ざん防止装置に関連した暗号化技術は，現存するＤＲＭソリューション機構における共通の構成要素である。また，秘密に関するアルゴリズムとプロトコルに依存するような不明化（obfuscation）技術は，この文脈では，主に独占的なソリューションで使用される。それは，セキュリティ評価と，異なるソリューション間の相互運用性との両方がこの手段により妨害されるからである。

ダウンロードＤＲＭ用の最も一般的なデータ構造は，コンテンツとこの使用権との関係を維持しながらコンテンツとこのコンテンツの使用権とを分離することに基づいている。コンテンツと使用権の両方は，このコンテンツの使用のために必要とされる。ＤＲＭダウンロードの一例は，図１に関してまず記載され，その後，主にコンテンツと使用権の保護に関する何らかの変形例を与える。

図１の例では，ダウンロード可能なコンテンツを含む部分は，「コンテンツ・オブジェクト」または「コンテンツ・コンテナ」１と呼ぶことにする。使用権を含む部分は，「権利オブジェクト」２として示す。権利オブジェクトの他の同義語は「チケット」または「ライセンス」である。コンテンツ・オブジェクトは，実際のデジタル・コンテンツ３とメタ・データ４を含んでいる。コンテンツは，非常にしばしば保護された形で記憶され，例えば太い矩形５により象徴されるように暗号化され，完全性が保護される。権利オブジェクトは，一般的には使用権表現言語で表現された使用権６，コンテンツ暗号鍵７及びメタ・データ８を有している。コンテンツ鍵の使用の場合，保護されたデジタル・コンテンツは，真正かどうか及び抽出された明確なテキストのデジタル・コンテンツであるかについてチェックすることができる。

コンテンツ・オブジェクトのメタ・データは，コンテンツ・オブジェクトの本体，実際のコンテンツに関する情報，使用権保持者の名前と場所，関連するアプリケーションまたはコンテンツの種類のようなコンテンツのレンダリングに関する情報，関連する権利オブジェクトをアクセス／購入可能である場所，例えば，コンテンツ・プロバイダ／配信者が主役となるウェブ・サーバに対するユニフォーム・リソース・ロケータ（ＵＬＲ）への言及を含んでもよい。権利オブジェクトのメタ・データは，一般的には，コンテンツ・オブジェクトの本体または（鍵付きの）寄せ集め暗号化コンテンツのような，どのコンテンツ・オブジェクトに権利オブジェクトが適用されるかについての言及を含んでいる。通常，与えられた権利オブジェクトは，特定のコンテンツ・オブジェクトに対し一義的に関連している。ある時は，与えられたコンテンツ・オブジェクトは，幾つかの関連する権利オブジェクトを有してもよい。この１つの理由は，必ずしもコンテンツ・オブジェクトを変更せずに同一コンテンツの異なる使用を可能にするためである。

全く同一のコンテンツは，セキュリティの理由で相異なる暗号化鍵で暗号化されて異なるコンテンツ・オブジェクトに記憶されてもよい。従って，特定の秘密コンテンツ鍵の開示は，その特定のコンテンツでコンテンツ・オブジェクトの全ての所有者に対し，明確なテキストのコンテンツを開示するものではなく，この鍵で暗号化された特定のコンテンツ・オブジェクトを有する人にのみ開示される。

上記の例の変形例は，コンテンツ・オブジェクト全体が全体的に保護され，まさにコンテンツではないということである。また別の変形例は，暗号化鍵で権利オブジェクトのコンテンツ鍵を暗号化することであり，このように暗号化されたコンテンツ鍵は，明確なテキストのコンテンツ鍵の代わりに権利オブジェクトに記憶されるということである。更にまた別の変形例／補足例は，権利オブジェクトが上記のものの他に「認証タグ」をも有するということである。この認証タグは，使用権及び／または明確なテキストとすることができ，または暗合化することができるコンテンツ鍵，及び／またはメタ・データの完全性保護のために含めることができる。少なくとも使用権は完全性保護とすべきほど重要である。それは，さもなければ，詐欺ユーザが与えられた使用権をその使用権の所有者に相談せずまたは別に料金の支払いもせずに自分の好みに変更し得るからである。権利オブジェクトのセキュリティ管理，または，もし該当する場合は，コンテンツ鍵にアクセスし使用権の完全性を実証するなどに必要な暗号鍵のセキュリティ管理は，ＤＲＭ機構のセキュリティにとって極めて重要であるが，本テキストにおいてはこれ以上記載しない。

図２から図４に関し，コンテンツのダウンロード及びＤＲＭ機構が如何に動作するかの例を何らかのデジタル・コンテンツを使用する権利を購入するユーザに関連して記載する。この例はまた，コンテンツが他人には使用できないこと，または，この権利オブジェクトにおいて認められた以外の他の手段によっては使用できないことを保証するために，これらの権利が維持されていることを如何にＤＲＭ機構が動作して実施しているかも示す。メディアの体験を共有する２人以上のユーザの例も与える。

図２に示した例では，ダウンロード可能なコンテンツのＤＲＭ用方式は，配信サーバ９，権利サーバ１０，クライアント１１及びＤＲＭブローカ１２を有している。配信サーバ９は，コンテンツ・オブジェクト及び権利オブジェクトを記憶しそれを送る。権利オブジェクトは，ユーザにより購入されてクライアントに送られる。権利サーバは，以前に得たコンテンツ・オブジェクトの使用権を購入する時に使用されるコンテンツ・オブジェクトに対応する権利オブジェクトを記憶する。クライアント１１は，コンテンツをレンダリングする装置である。クライアント１１においては，使用規則を強制するためのＤＲＭエージェント１３が存在する。ＤＲＭブローカは，恐らく相異なるネットワーク（図示せず）において相異なる権利サーバを相互接続するネットワーク本体であって，クライアントのために単一の接触点を提供する。

図３において，クライアント１１を操作するユーザは，クライアント１１にダウンロード可能なコンテンツについて配信サーバのウェブ・ページを閲覧する。ユーザは，関連するいくつかの使用権を持つ特定のコンテンツについて決定を行い，支払いを行うに必要な情報を提供する。ユーザは，所望のコンテンツに対する要求１４を配信サーバに送る。この特定クライアント及び／またはユーザ用の適切な暗号保護付きのコンテンツ・オブジェクト及び権利オブジェクトは，好ましくは信頼性ある輸送機構を使用してクライアントに矢印１５と１６のように送られる。クライアント１１のＤＲＭエージェント内で，必要な暗号情報は，権利オブジェクト内の使用権に従って，コンテンツ・オブジェクト内のコンテンツを使用するために集められる。

実行の場合，信用されたアプリケーションがコンテンツを確実にレンダリングするために必要である。ＤＲＭエージェントは，権利オブジェクト内の使用権を解析し，コンテンツ（あるいはクライアント１１における局部的な秘密モジュールのような他の信頼された部分からのコンテンツの要求解読）を解読して，明示された使用権に従ってコンテンツをレンダリングまたは使用するために適切な信頼されたアプリケーションに転送する。このアプリケーションは，コンテンツの種類に依存し，例えば，音楽またはビデオのレンダリングはメディア・プレーヤ・アプリケーションに送られて，画像視聴者アプリケーションに画像を表示する等を行う。

所望の別の手続きは，ユーザが，特定の権利オブジェクトなしに，またはこの権利オブジェクト付きでコンテンツ・オブジェクトをクライアント１１にダウンロードすることを許可されていて，この手段によって全コンテンツの有限なバージョンを使用することができるということである。このことは，例えば，ある音楽から取り出した１０秒分のオーディオ抜粋片，画像の低分解能バージョンなどのようなマルチメディア・コンテンツの小さな一部となり得よう。只でまたは減額コストで有限な使用を許可する概念は「プレビュー（preview）」として知られるが，それは，コンテンツを見たりまたは表示したりすることとは関係なくてもよい。

コンテンツに対する完全な使用権は，例えば，コンテンツ・オブジェクトのコンテンツが暗号により保護され，全コンテンツを使用するに必要なコンテンツ鍵が（通常の価格の）権利オブジェクトには配置されているから，この機構により露わになることができないものとすべきである。プレビューの後，ユーザは，そのコンテンツが購入するに望ましく，従って，権利サーバにコンタクトするかどうかを決定することができ（そのＵＲＬは，コンテンツ・オブジェクトからまたはＤＲＭブローカを介して利用してもよい），従って，全コンテンツを利用し得るために，ＤＲＭエージェントで必要とされる権利オブジェクトを購入しダウンロードすることができる。

プレビューで利用したコンテンツと使用権の分離は，以下に概略示す他の所望のコンテンツ配信の例，すなわち，超流通（super-distribution）においても適用される。図４を参照。ユーザが，他のユーザと使用体験を共有することを望む場合を考慮する。コンテンツ・オブジェクトは，それ自体保護されていて輸送中に特定のセキュリティを必要としないので，例えば，ブルートゥース，ＩｒＤＡ，ケーブルのような局部接続を介しまたは任意のネットワークによりその２つのクライアント間で直接コンテンツ・オブジェクトを送信する場合には，セキュリティの危険が存在しない。

ユーザＢは，面白いコンテンツを体験し，クライアントＢに対してコンテンツ・オブジェクトを，矢印１７で示したようにクライアントＡに対し送るよう命令する。受信されたコンテンツ・オブジェクトは，受信ユーザがこれは面白いかどうかを決定することを容易にするためにプレビューを含んでもよい。コンテンツ・オブジェクトは，正しい権利サーバにユーザを向けることができる関連の権利サーバまたはＤＲＭブローカへの言及を含んでいる。クライアントＡは権利サーバに接続されて，権利の取り決めを行い，支払いを受け入れ，矢印１８により示したように権利オブジェクトを要求する。この要求された権利オブジェクトは，クライアントＡに対して矢印１９のようにダウンロードされるので，以前に得られたコンテンツ・オブジェクトはクライアントＡで使用することができる。コンテンツのピア・ツー・ピア配信の概念は，「超流通」と呼ばれ，コンテンツをベースとするビジネスにとって非常に重大なメカニズムと考えられている。潜在的に，望ましくその価格に値するコンテンツは，ユーザ達の中に迅速に広まり，コンテンツ・プロバイダ／配信業者にとって大きな収入源となる。

次に，ダウンロードとストリーミング用の配信機構を記載する。これらの機構は，それぞれの機構で輸送されたメディアに対する使用権の管理から生じる厄介な問題を考慮する時に理解することが重要である。

ＩＰネットワークにおけるダウンロードＤＲＭの場合，コンテンツ・オブジェクト及び権利オブジェクトは，ハイパー・テキスト・トランスポート・プロトコル（ＨＴＴＰ）またはファイル・トランスファー・プロトコル（ＦＴＰ）のような信頼性ある輸送プロトコルを使用してクライアントに送られる。これらは，大部分のウェブ・サーバとウェブ・ブラウザにより使用される標準的なウェブ・プロトコルである。ＨＴＴＰとＦＴＰの両方は全てのデータ転送を扱うトランスミッション・コントロール・プロトコル（ＴＣＰ）上で動作する。ＴＣＰゴールは，ファイル転送及び遠隔ログインのような非リアルタイム・アプリケーション用に最適化されて，データ転送速度を最大にし，全ネットワークの全安定性と高スループットを保障するようにしてある。

これを達成するため，まずＴＣＰは，スロー・スタートと呼ばれるアルゴリズムを使用して低データ速度でデータを送信し，次に，行き先がパケット損失を報告するまで徐々にデータ速度を増大する。次に，ＴＣＰは，それが帯域幅の限界またはネットワークの渋滞に遭遇して，低データ速度でのデータ送信に復帰し，次に，その処理の反復を徐々に増大すると仮定する。ＴＣＰは，喪失したパケットの再送信により信頼性あるデータ転送を達成する。しかし，全ての再送信になるパケットは，例えば，メディア・ストリームで再生できる特定の時間内にクライアントに到達するということを保証することはできない。

次に，ストリーミング技術を述べる。ＨＴＴＰとＦＴＰ（またはＴＣＰに基づく他のプロトコル）は，データの信頼性ある転送には適しているが，ストリーミング・メディアについてはあまりよく機能しない。その主な理由は，ＴＣＰは如何なるタイミング要件にも関係せずに信頼性ある輸送を実施し，ＴＣＰはメディアの必要に従うのではなく，帯域幅の利用可能性に従ってクライアント・サーバ接続のデータ転送速度を変更するからである。リアルタイム・データの輸送の最も一般的で標準化された例は，リアルタイム・トランスポート・プロトコル（ＲＴＰ）であり，これは，ＬＰネットワークにおけるマルチメディア・データ・ストリーム用のパケット・フォーマットである。リアルタイム・データの輸送用の大部分の独自のプロトコルは，ＲＴＰに類似している。

特に，ＲＴＰは，追加の機能に便宜をはかるプロトコル・フレームワークである。このプロトコルを完全に特定するには，ペイロード・フォーマット（例えば，メディア・エンコーディング）のような追加の情報が必要とされる。この情報は，ＲＴＰ用のいわゆる「プロファイル」を構成する。ストリーミング・アプリケーションにおいて，ＲＴＰは，ＴＣＰに比較してストリーミング体験を改善するユーザ・データグラム・プロトコル（ＵＤＰ）上で動作することが望ましい。ＴＣＰと違ってＵＤＰは，例えば，リアルタイムのオーディオ・ビデオ・データを送信するために理想化される，どのような再送信またはデータ速度管理機能のない迅速軽量なプロトコルであり，これにより，喪失データを寛容に取り扱うことができる。ＴＣＰプロトコルに暗に示された上記のスロー・スタート機構のために，ＵＤＰトラフィックは，ネットワークにおけるＴＣＰトラフィックよりも大なる帯域幅の部分を効果的に得る。

完全性のため，「斬新的ダウンロード」の概念を簡述すべきである。斬新的ダウンロードとは，通常ＴＣＰを使用してメディアを確実にダウンロードすることであるが，レンダリングはダウンロードの完了前に開始される。ＴＣＰはこの場合にも使用されるので，同じ制限が上記のダウンロードについて述べたようにリアルタイムのメディア・ストリームの場合に当てはまる。
輸送されたマルチメディア・ストリームの提示の制御のため，リアルタイム・ストリーミング・プロトコル［ＲＴＳＰ］のような制御プロトコルが使用される。ＲＴＳＰは，メディア・ストリーミング・セッションの設定，更にこのメディア・ストリームにおける開始，休止，停止及び移動（「早送り」と「巻き戻し」）のために使用してもよい。

ストリーミング・サーバとクライアントとを同期化するために，（クライアントのソフトウエア部である）メディア・クライアントは，ＲＤＰデータを正確に解釈するために初期化パラメータを有することが要求される。これらの初期化パラメータは，セッション・ディスクリプション・プロトコル［ＳＤＰ］で記載してもよい。このＳＤＰは，特に，セッション名称，このセッションがアクティブである時間，このセッションを含むメディア，これらのメディア（アドレス，ポート，フォーマットなど）を受信するための情報，使用される帯域幅，メディアの種類，コーディック（圧縮及び解凍のアルゴリズム），メディア鍵及びマルチメディア・ストリームの特定メディアまたは全セッションに関する付加的な属性も含むマルチメディア・セッションのための記述プロトコルである。

以下はＳＤＰ記述の例である。

「ｍ＝」フィールドは，ストリームを列挙するために使用され，プレイロードの種類，ＲＴＰプロファイル及び推薦ポートに関する情報を含んでいる。ＲＴＰ／ＡＶＰは，プレイロードはＵＤＰ上のＲＴＰであるということを示す。「ａ＝」フィールドは属性を示し，「ａ＝ｃｏｎｔｒｏｌ：」は，マルチメディア・ストリーム，この場合はオーディオ・ストリームに対するＵＲＬを示す。このＳＤＰの記述における情報に基づいて，メディア・クライアントは，輸送設定（ＩＰアドレス，ポート番号，及び他のパラメータ）を行うためにＲＴＳＰ ＳＥＴＵＰ命令を送り，その確認後，そのメディア・ストリームを開始すべきＲＴＳＰ ＰＬＡＹ命令がストリーミング・サーバにより送られる。更なる詳細は，［ＲＴＳＰ］及び［ＳＤＰ］において見ることができる。
前の例の特別な場合は，メディア・ストリームを開始するためにＲＴＳＰリンクＵＲＬをまさに使用することである。

このようなＵＲＬは，ストリーミング・メディアを一義的に定義し，このデータをＲＴＳＰ ＤＥＳＣＲＩＢＥメッセージで使用することによってストリーミング・セッションが開始され，これにより，前の例と同じストリームが生じる。しかし，輸送とプロトコルの情報は，ＲＴＳＰ ＳＥＴＵＰとＰＬＡＹ命令をクライアントが発生できる前に，サーバとクライアントの間で取り決められなければならない。従って，レンダリングが開始（ＤＥＳＣＲＩＢＥメッセージと返答）できる前にクライアントとサーバとの間におけるメッセージの追加的な往復が生じる。結果として，ＲＴＳＰ ＵＲＬだけでストリーミング・セッションを開始すると，余分な遅延が生じ，従って，第１の場合ほど効率的ではない。

ストリーミング・セッションを記述する他の方法は，マルチメディア・セッションを記述するメディア記述言語であるシンクロナイゼーション・マルチメディア・インテグレーション・ランゲージ（ＳＭＩＬ）を使用することである。ＳＭＩＬは，ウェブ・ページのコンテンツと形態を明示するが，これに対してマルチメディアの表現の時間ベース構造を加え，従って，互いに異なるストリームを明示可能にし，更に，異なる時間で種々のストリームを設定可能（または他のメディア・オブジェクトをレンダリング可能にする）ハイパ・テキスト・マークアップ・ランゲージ（ＨＴＭＬ）として考慮することができる。ＳＭＩＬを使用するには，メッセージの追加の往復も必要とされ，従って，効率はより低い。しかし，ＳＭＩＬは，単一のＳＤＰ記述，例えば，画像のような時間離散オブジェクトにより記述することができるよりも他の種類のマルチメディア・セッションをレンダリング可能にする。

次に，ストリーミング・メディアの保護について述べる。データの暗号化は，ネットワークを介してメディアの秘密性を維持するために通常必要とされる。暗号化されたデータは，原則として任意のプロトコルで輸送することができるが，プロトコルの信頼性がない場合，パケットの喪失によりデータの解読が不可能となり品質の重大な損失，暗号化していないデータのパケットの喪失よりも恐らく更に大きな品質の喪失が生じる可能性がある。暗号化アルゴリズムに依存して，喪失したパケットは，解読中にエラーを生じる可能性があり，このエラーは，他の受信パケットに広がってこれらの解読を不可能にする可能性がある。これは，データ全体の配信が保障されている信頼性のあるプロトコルの使用時に暗号化されたデータの配信とは対照的である。

それ故，特別なストリーミング暗号化プロトコルは無線ネットワーク用に設計されている。一例としては，セキュア・リアルタイム・トランスポート・プロトコル［ＳＲＴＰ］があるが，これは，ＲＴＰのプロファイルである。ＳＲＴＰは，秘密性，メッセージの証明及びＲＴＰ／ＲＴＣＰトラフィックに対する再生保護を提供する。それは，ＲＴＰパケットの喪失または再整理に寛大となるように暗号化されたデータのエラーが原因のエラー伝搬を回避するよう設計されており，暗号化ストリームにおける早送り及び巻戻しを可能にする。従って，ＵＤＰを介して輸送されたＳＲＴＰは，確実ではあるが信頼性のないプロトコルである。

ＳＲＴＰにより暗号化されたストリーミング・オーディオ／ビデオ・セッションに対するＳＤＰ記述の例は，次の通りである：
ｉ＝シーン背後のリングの支配者

前の例との主な相違点は，ＳＲＴＰプロファイルである。これは，「ｍ＝」フィールドにおけるＲＴＰ／ＳＡＶＰにより示される。オーディオ・ストリームとビデオ・ストリーム用の個々の暗号化鍵は，「ｋ＝」フィールドにベース６４エンコーディングで含められている。

上記のダウンロード・テクノロジは，すぐにストリーミング・テクノロジを使用するに適しているものではない。コンテンツとチケットの分離は，ストリーミングに当てはまる。

解決されるべき問題は，すなわち，（ａ）ストリーミング・マルチメディアの送信と，（ｂ）次の事実を考慮する送信されストリーミングされたマルチメディアの確実な使用権管理を可能にするために，ダウンロード・テクノロジとその確実な使用権管理を如何に変更するかである。

・ストリーミングは，メディアを受信する時にこのメディアのリアルタイム・レンダリングを意味する手順であり，ストリーミングは，ダウンロードによる場合のようにメディアのレンダリングを伴う受信メディアの記憶は認めない。
・ダウンロードに使用される現存のネットワーク要素と機構は，可能な最大程度，ストリーミングのためにも使用すべきであり，かくして，それらはダウンロードとストリーミングのために使用することができる。
・ストリーミング・メディアは，ユーザ・データグラム・プロトコル（ＵＤＰ）のような信頼できない輸送プロトコルを使用する。少量のビット・エラーまたは喪失パケットは，メディアの品質に大きな影響を与えずに取り扱うことができ，これが制御することができるか，またはユーザが余りにもノイズのあるメディアに対して金の支払いをする必要がないように少なくとも検証可能な場合には，ユーザに受け入れ可能となる可能性がある。

・しかし，上記のように，ＤＲＭシステムでは幾つかのデータ，例えば，変更が受け入れられない使用規則及び暗号メディア鍵は信頼性なしでは輸送できない。それは，それらデータが制定された規則を侵害したり，または，コンテンツの解読を不可能にすることがあるからである。
・暗号によるストリーミング・メディアの保護のために，暗号鍵はストリーミング・サーバとクライアントとの間で確実に一致させなければならない。

・確実なストリーミング輸送プロトコルが使用される場合に，暗号鍵は，ストリーミングが開始する前に利用可能とならなければならないが，ダウンロードＤＲＭプロトコルは，権利オブジェクトとコンテンツ・オブジェクトの到着順には通常気づかない。
・ストリーミング・データを「巻き戻し」し，「早送り」し得ることは望ましい。
・あるアプリケーション，例えば，リアルタイム・アプリケーションでは，同時にコンテンツ全体に対してアクセスすることはできない（例えば，ウェブ・キャスト）。このことで，メディアの取り扱いは影響を受けるべきではない。

従来技術のＤＲＭシステムでは，ダウンロード・メディア用のＤＲＭとストリーミング・メディア用のＤＲＭの両方に共通のソリューションはない。実際，使用権を管理さえせずに，ある障害付きのチャネルを介して送られたストリーミング・メディアの暗号による保護はほとんど扱われない（１つの例外は，［ＳＲＴＰ］である）。特に，コンテンツのダウンロード用のＤＲＭを提供する現存のシステムが与えられた場合，このシステムにストリーミング用のＤＲＭを透明状態で組み込むためのソリューションは存在しない。また，超流通，コンテンツのプレビュー及び使用権の購入のための機構を含むダウンロード及びストリーミングの両方用に透明状態で作用する他の重要な制限も存在する。
本発明は，上述の問題に対するソリューションを提供する。

本発明の１つの目的は，ストリーミング・メディアを持つＤＲＭを取り扱うソリューションを提供することである。
本発明の他の目的は，メディア・ダウンロードのＤＲＭ用の現存のプロトコル及び保護機構を使用することによりストリーミング・メディアを持つＤＲＭの取り扱いを提供することである。
本発明の更に他の目的は，ストリーミング・メディアの超流通を可能にするストリーミング・メディア付きのＤＲＭの取り扱いを提供することである。
本発明の更に他の目的は，ストリーミング・メディアの使用権を管理する装置及び方法を提供することである。
本発明の更に他の目的は，ストリーミング・メディアの使用権を配信し管理するシステム及び方法を提供することである。
これらの及び他の目的は，請求の範囲に明示した発明により達成される。

本発明の顕著な特徴は，コンテンツ・オブジェクト及び関連する権利オブジェクトを含むＤＲＭ機構を使用することであり，コンテンツ・オブジェクトは，コンテンツではなく，デジタル・メディアがストリーミングによりクライアントに転送される今度のストリーミング・セッションの開始記述である。この特徴により，プレビュー及び超流通が可能となる。セッション開始記述には，未許可の使用からストリーミング・メディアの保護の暗号鍵をオプションで含んでもよい。
以下において，「コンテンツ」なる表現は，従来技術のダウンロードＤＲＭソリューションにおいてコンテンツ・オブジェクト内にコンテンツが配置される場所に置かれたどんなデータをも時には示す。

次に，本発明を示す。理解の簡単化のため，ダウンロード用の最新式のＤＲＭソリューションで記述されたコンテンツ・オブジェクト及び権利オブジェクトを使用する，ダウンロード用の現存の与えられた使用権管理システムを想定する。ストリーミング・メディアの使用権は，次の構成により管理される。

・コンテンツ・オブジェクトの実際のデジタル・コンテンツの代わりに，ストリーミング・メディアの開始記述が記録内の同一場所に配置されている。この開始記述は，例えば，ＳＤＰ記述，特に特定のストリーミング・メディアを示すＲＴＳＰ ＵＲＬ，ＳＭＩＬファイルなどを含んでもよい。
・開始記述は，無許可の使用からのストリーミング・メディアの保護に関する暗号化情報をオプションで含んでもよい。
これとは別に，ダウンロード用のＤＲＭソリューションは，変更なしで再使用される。従って，例えば，権利オブジェクトは，使用規則及び「コンテンツ」を暗号化する暗号化鍵を含んでいる。まさにダウンロードの場合のように，ＤＲＭエージェントは，使用規則を解析し，「コンテンツ」を解読し，レンダリングを行う適切な信頼性あるアプリケーションに対し明確なテキストの「コンテンツ」を送る。ストリーミング・メディアの場合，「コンテンツ」はストリーミング・メディア開始記述である。

特定のコンテンツ配信シナリオにおけるアクタ間のトラスト・モデルに依存するが，それは，ダウンロードＤＲＭシステムにより可能にされたストリーミング開始記述を保護することで十分であり，実際のストリーミング・メディアの保護は行われない。もしある条件のうちの１つ以上が満足されるならば実際のストリーミング・メディアの保護が十分無視できると考えられる場合のその条件のいくつかの例を以下に示す。
・もしストリーミング開始記述が権限のない側へは漏洩せず権限を与えられた側へのみストリーミングが許容される場合。
・権限のない使用を思いとどまらせたり，または制限するために，ストリーミング・メディアを盗み聞きすることが十分に困難な場合。
・もし権限のない使用を思いとどまらせたり，または制限するためにストリーミング・メディアを記憶することが十分に困難な場合。

しかし，一般的な場合，特に上記の条件の一部のみが満足されまたは全部が満足されない場合，ストリーミング・メディア開始記述の保護は十分ではなく，ストリーミング・メディアの追加の保護が必要である。ストリーミング・メディアの暗号による保護は，オープン・システム・インターコネクト（ＯＳＩ）モデルの任意のレベルにおいて適応可能である。以下においては，この一例を記載する。その場合，保護は，輸送レベルへ与えられる。

ストリーミング・メディアのセキュリティの明確な改良は，コンテンツ・プロバイダ／配信者により管理されるストリーミング・サーバとクライアントにおける信頼されたストリーミング・アプリケーションとの間での輸送中のメディアの暗号による保護である。これは，前に述べたＳＲＴＰのような確実で（特に，無線ネットワークの場合）頑丈なストリーミング輸送プロトコルを使用して達成してもよい。この場合，ストリーミング・サーバとクライアントの間でストリーミング・メディアを保護するために使用される暗号鍵は，信任された当事者にとって極秘に保持されるということは，もちろん極めて重要である。これは，ストリーミング・メディア開始記述に含められるよう本発明がオプションで明示する暗号情報であってもよい（または，この暗号情報によって管理されてもよい）。例えば，ＳＤＰ記述は，前の例の１つに示したように，メディア鍵の仕様のためのオプションの属性を有している。

特に，このような情報記述は，１つだけかまたは幾つかのＲＴＳＰ ＵＲＬと，暗号化鍵を含む暗号化鍵属性を含んでいる。あるいは，暗号鍵は，ストリーミング開始記述で，明確なテキストのストリーミング・セッションの任意の開始記述，例えば，暗号鍵（cryptographic key）で束ねられた鍵属性のないＳＤＰ記述と共に，特に１つまたは数個のＲＴＳＰ ＵＲＬと別々の暗号化鍵（encription key）とで輸送することができる。ストリーミング・メディア開始記述の他の具体例は，暗号鍵で束ねられたＳＭＩＬファイルである。
付加的なセキュリティ機構は，ストリーミング・メディア開始記述またはストリーミング・メディア自体を保護するために考慮することもできる。

本発明は，一般的にはストリーミング・メディアの使用権管理（ＤＲＭ）に適応可能である。本発明は，メディア・ダウンロード用のＤＲＭとストリーミング・メディア用のＤＲＭに対し共通のソリューションを提供する。本発明の場合，ストリーミング・メディアを取り扱う互換性あるシステムを可能にするための，ダウンロード・システム用の現存のＤＲＭにおいては変更はほとんど必要とされない。このことと，これらの変更がダウンロード用のＤＲＭのコンセプトに一体となって適合するという特定の方法とのために，使用権管理，超流通，プレビュー，特定のコンテンツに対する権利オブジェクトの購入などのようなＤＲＭダウンロード・システムの全ての特徴は，ストリーミング・メディアに対しもたらされる。例えば，超流通は，一般的にはピア・トゥ・ピア（Peer to Peer）でコンテンツ・オブジェクトを送ることによって行われる。受信ピアは，購入した権利オブジェクトでピア自身のストリーミング・セッションを開始することができる。

ストリーミングのプレビューの概念については，説明語句が必要かもしれない。これは，幾つかの方法で行うことができる。１つの方法は，コンテンツ・オブジェクトに対して実際にクライアントにダウンロードされる全コンテンツまたは関連コンテンツの有限なマルチメディア・サンプルを供給することである。他の方法は，クライアントが，一時的または他の方法で制限された／限定されたストリームをオプションによりバージョン全体よりも低い分解能／品質で設定できる鍵を提供することである。

本発明は，オプションとして，メディア・ストリームの暗号による保護を可能にすると共に，ストリーミング・サーバとストリーミング・クライアントにおいて共通の秘密鍵を如何に確立するかの鍵管理問題を解決もする。この構成は，ＳＲＴＰのような確実で頑丈なストリーミング・プロトコルの使用と両立するので，本発明は，送信の場合にエラーを発生させる障害を伴う無線ネットワークの場合と同様，有線ネットワークにおける使用権の管理にも完全に適するものである。

前述のように，メディア・コンテンツのストリーミングとダウンロードとの間には幾つかの相違点がある。しかし，いずれかの方法によりレンダリングされる同一メディア，例えば，音楽コンサートのビデオに関するユーザ体験は著しく相違する必要はない。すなわち，クライアントにダウンロードされたコンサートは，時々起こる障害のどのような兆候をも示さないという利点を有しており，一方，クライアントにストリーミングされたビデオには，ライブで直接放送されるコンサートの場合がある。

本発明によれば，まったく同一の使用権管理機構は，メディアの輸送とは独立にメディアのダウンロードとストリーミングの両方に使用してもよい。この使用権管理機構は，超流通，重要なビジネスのケースと考えられる使用権の購入などのために働く。超流通がダウンロードに対して働くのみの場合，ストリーミング・サービスの導入により，潜在的にダウンロード・コンテンツの超流通のためにビジネス・ケースを損傷する可能性のあるコンテンツを配信／購入する能力は不安定になる。

同一の使用権管理機構がメディアのダウンロードとストリーミングの両方に使用されるので，ダウンロードとストリーミングのための平行ソリューションを実行することは必要ではない。それは，統合されたユーザの体験を保証することもできる。
本発明は，更なる目的と利点と共に添付図面と共に以下の記載を参照することにより最も良く理解されよう。

図５は，本発明によりストリーミング・メディアのＤＲＭの例のデータ構造とクライアントの図を示す。さしあたり，クライアントは，ストリーミング・セッション中にストリーミング・サーバ２１からクライアントにデータパケット２２で輸送される特定のデジタル・マルチメディアに対するコンテンツ・オブジェクト２０と権利オブジェクト２を受信したと仮定する。この状況がどのように生じるかは更に以下に記載する。
コンテンツ・オブジェクトは，メタ・データ，メディア鍵２４を含む上記の種類のＳＤＰ記述の形式で開始記述２３を有している。開始記述は，太い矩形２５により象徴されるように暗号により保護されている。
コンテンツ・オブジェクトと関連した権利オブジェクトは，まさにダウンロードＤＲＭの場合のように，メタ・データ，使用権及びコンテンツ鍵を有している。

クライアントは，コンテンツ・オブジェクトに設けられたメディア鍵を含む保護された開始記述を解読するために権利オブジェクト内に設けられたコンテンツ鍵を使用する。明確なテキスト・メディア鍵は，保護されたマルチメディア・ストリーム２２の解読のためにクライアントにより使用される。解読されたメディア・ストリームは，アプリケーションによりアクセスされてメディア・プレイヤ（図示せず）上でレンダリングされる。

マルチメディア・ストリームがクライアントに送られる前に，ストリーミング・メディア・セッションが設定されなければならない。このためには，クライアントとストリーミング・サーバとの間に接続（connection）が設定される。この接続を介して，マルチメディアの名称，種類，配置場所，その符号化方法などのようなマルチメディアに関する多くの種類の情報は，ストリーミング・サーバとクライアントの間でマルチメディア・ストリームが開始される前に交換される。開始記述は，これらの目的のために使用される。

図６は，ＤＲＭに対しストリーミング・メディアを提供するための本発明による方法のステップを示す。クライアントは，マルチメディアの要求を矢印２６で示したように配信サーバに送る。要求されたマルチメディアに対する使用権の条件は，取り決められて決定される。矢印２７により示した次のステップは，配信サーバがクライアントに対して保護された開始記述を持つコンテンツ・オブジェクトを送るということである。次に，使用権及びコンテンツ鍵を含む権利オブジェクトは，矢印２８により示したようにクライアントに送られる。

上記のコンテンツ鍵を使用して，クライアントは，セッション開始記述を解読し，そこに与えられた情報を使用してストリーミング・サーバに対するストリーミング・セッションの設定を開始する。これは，二重の向きを示した矢印２９により示してある。この接続を越えて，ストリーミング・セッションで使用される更なるパラメータが交換される。最後のステップで，ストリーミング・セッションが開始され，パケットの保護されたマルチメディア・ストリームは，矢印３０により示されたように，クライアントに対しストリーミングを開始する。

パケットは，開始記述に示されたストリーミング・プロトコル，この場合はＳＲＴＰプロトコルで送られる。信頼性のあるプロトコルは，権利オブジェクト及びコンテンツ・オブジェクト，例えば，ＨＴＴＰまたはＷＡＰを送るために使用される。信頼性あるプロトコルは，ＲＴＳＰ制御のシグナリングのために使用もされる。
クライアントは，ストリーミング・サーバに対し受取通知または確認を送ることによりパケットの受信を証明してもよい。そのような機構はＳＲＴＰ／ＳＲＴＣＰプロトコル［ＳＲＴＰ］の一部である。

図７は，本発明によるストリーミング・メディアのＤＲＭを提供するためのモード及び装置を示すブロック線図である。マルチメディア・ストリームを提供するストリーミング・サーバ３２，メディア鍵と同様コンテンツ鍵も提供する暗号化鍵発生器３３，メディア鍵を記憶するメディア鍵・データベース３４，コンテンツ・オブジェクト発生器３５，権利オブジェクト発生器３６，配信サーバ３７，権利サーバ３８を含むコンテンツ・サーバ３１が存在する。

コンテンツ・オブジェクト発生鍵は，（矢印３９により示される）コンテンツ・サーバ３１からストリーミング・セッションの開始記述で使用される上記の開始パラメータを取り出す。メディア鍵２４は，鍵発生器３３から取り出される。開始記述は，鍵発生器３３により同様に発生されたコンテンツ鍵を使用して暗号により保護される。このコンテンツ鍵は，権利オブジェクト発生器用に利用可能でもある（下記参照）。メタ・データは，同様に取り出され，コンテンツ・オブジェクトに含められる。発生されたコンテンツ・オブジェクトは，配信サーバに記憶され，そのコピーは，図６の矢印２７に従ってクライアントに送られる。

権利オブジェクト発生器は，コンテンツ・オブジェクトに関連した権利オブジェクトを発生し，その内部にコンテンツ・オブジェクトの保護のために使用されたと同じコンテンツ鍵を有する。本体（identity）を有する権利オブジェクトは，配信サーバと権利サーバに記憶される。そのコピーは，図６の矢印２８に従ってクライアントに送られる。
二重頭付き矢印４０は，メディア鍵とコンテンツ鍵のコンテンツ・オブジェクト発生器と権利オブジェクト発生器への配信を示す。

コンテンツ・オブジェクトに挿入されたメディア鍵は，発生されたコンテンツ・オブジェクトに関連した権利オブジェクトの本体と共にメディア鍵・データベースに記憶されもする。これは，図７において矢印４１で示してある。
今までの状況は次の通りである。すなわち，クライアントは，前に記載した（図６の矢印２７，２８）ようにコンテンツ・オブジェクトと権利オブジェクトとを受信している。メディア鍵２４と関連する権利オブジェクトの本体はメディア鍵・データベースに記憶される。

次に，（図６における矢印２９に対応する）図７の矢印２９でクライアントからのセッション設定メッセージは，ストリーミング・サーバにより受信される。このメッセージは，前に述べた情報を含み，クライアントとサーバとの間のその後のシグナリングにより，コンテンツ・オブジェクトに関連した権利オブジェクトの本体が現わされる。ストリーミング・サーバは，矢印４２により示されるメディア鍵要求をメディア鍵・データベースに送り，矢印２９で受信された権利オブジェクトの本体を提供する。この要求に応答して，メディア鍵・データベースは，表示された権利オブジェクトの本体についてサーチされ，対応するメディア鍵を矢印４３により示したようにストリーミング・サーバに戻す。ストリーミング・サーバは，次に（図６の矢印３０に対応する）矢印３０で示すように，クライアントに対して送り始めるメディア・ストリームを暗号により保護するために，そのメディア鍵を使用する。ストリーミング・サーバとクライアントは，両者とも，それぞれ暗号化及び解読のために同一のメディア鍵を使用する。

上記例の多くの変形例が可能である。ストリーミング・サーバでの暗号化用及びクライアントでの解読用に同一のメディア鍵を使用する代わりに，ストリーミング・サーバは，公開メディア鍵を使用してもよく，秘密メディア鍵はコンテンツ・オブジェクトにおいてクライアントに送られる。
他の変形例は，記述される明確なテキストでコンテンツ・オブジェクトを提供する代わりに，このコンテンツ・オブジェクトのメディア鍵を暗号で同様に保護もすることである。
メディア・ストリーム及び／またはコンテンツ・オブジェクトは，暗号化及び／または完全性保護により同様に保護されてもよい。権利オブジェクト及び／またはコンテンツ・オブジェクトは，無防備でクライアントに同様に送られてもよい。

コンテンツと権利オブジェクトがクライアントに送られる順序は，逆転してもよい。すなわち，図６においてステップ２８は，ステップ２７より前にあってもよい。それらは，モバイル通信ネットワークにおいて同様にＳＭＳメッセージの場合のような別々の通信チャネルを介し，そしてＷＡＰプロトコルを使用して，それぞれ送られてもよい。
開始記述は，コンテンツ・オブジェクト発生器により提供する代わりにコンセント・サーバにより提供されてもよい。

図８において，コンテンツ・オブジェクトの種々の実施例が８Ａ〜８Ｄに示してある。図８における全ての実施例に共通な特徴は，暗号情報が開始記述には含まれていないということである。図８Ａにおいて，通常のメタ・データと開始記述ファイルを含む基本的なバージョンが示してあるが，今回はメディア鍵なしである。図８Ｂにおいて，開始記述は，鍵属性を設定せずにＳＤＰ記述として具体化されている。図８Ｃで，開始記述は，鍵なしのＳＭＩＬファイルとして具体化されている。図８Ｄは，図８Ｂの特別な場合であって，ＳＤＰ記述はストリーミング・メディアを取り扱うＲＴＳＰ ＵＲＬである。

図９においては，コンテンツ・オブジェクトの更に異なる実施例が９Ａ〜９Ｆに示してある。全ての実施例に共通な特徴は，暗号情報が開始記述には含まれているということである。図９Ａにおいては，通常のメタ・データとメディア鍵を有する開始記述ファイルを含む基本的なバージョンが示してある。図９Ｂでは，開始記述は設定された鍵属性を含むＳＤＰ記述として具体化されている。図９Ｃでは，開始記述は，設定された鍵属性のないＳＤＰ記述として具体化されている。メディア鍵は，開始記述内に別に含まれている。図９Ｄでは，開始記述は，ＳＭＩＬファイルとメディア鍵として設けられている。図９Ｅは，図９Ｂの特別な場合であって，ＳＤＰ記述はストリーミング・メディアを取り扱うと共に設定されたメディア鍵属性を有するＲＴＳＰ ＵＲＬである。同様に図９Ｆは，図９Ｃの特別な場合であって，ＳＤＰ記述はストリーミング・メディアを取り扱うＲＴＳＰ ＵＲＬである。メディア鍵は，開始記述においてはＲＴＳＰ ＵＲＬとは別に設けられている。

なお，図９に示したメディア鍵は，例えば更なるメディア鍵及び／または他の種類のセキュリティを提供する更なる鍵のような更なる鍵を幾つか含んでもよい。幾つかのメディア鍵を使用する１つの理由は，セキュリティを高めるように完全なメディア・ストリームのまさに一部と各鍵を関連付けることである。この背景にあるアイディアは，盗聴するものが単一鍵を使用してメディア・ストリーム全体を解読することを不可能にすべきであるということである。
上記の実施例は単に例として与えたものであって，本発明はこれに限定されないと理解されるべきである。ここに開示され，かつ請求された基本的根本的原理を保持する更なる変形例，変更及び改良は，本発明の範囲及び主旨内にある。

［ＨＡＣ］Ａ．Ｊ．Ｍｅｎｅｚｅｓ，Ｐ．Ｃ．ｖａｎ Ｏｏｒｓｃｈｏｔ ａｎｄ Ｓ．Ｃ．Ｖａｎｓｔｏｎｅ，"Ｈａｎｄｂｏｏｋ ｏｆ Ａｐｐｌｉｅｄ Ｃｒｙｐｔｏｇｒａｐｈｙ"，ＣＲＣ Ｐｒｅｓｓ． ［ＲＴＰ］Ｖ．Ｊａｃｏｂｓｏｎ，Ｓ．Ｌ．Ｃａｓｎｅｒ，Ｒ．Ｆｒｅｄｅｒｉｃｋ ａｎｄ Ｈ．Ｓｃｈｕｌｚｒｉｎｎｅ，"ＲＴＰ：Ａ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ ｆｏｒ Ｒｅａｌ−Ｔｉｍｅ Ａｐｐｌｉｃａｔｉｏｎｓ"，ＲＦＣ １８８９，ＩＥＴＦ， Ｎｏｖｅｍｂｅｒ ２００１． ［ＲＴＳＰ］Ｈ．Ｓｃｈｕｌｚｒｉｎｎｅ，Ａ．Ｒａｏ，Ｒ．Ｌａｎｐｈｉｅｒ，"Ｒｅａｌ Ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ（ＲＴＳＰ）"，ＲＦＣ ２３２６，ＩＥＴＦ，Ａｐｒｉｌ １９９８． ［ＳＤＰ］Ｍ．Ｈａｎｄｌｅｙ，Ｖ．Ｊａｃｏｂｓｓｏｎ，"ＳＤＰ：Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｏｔｏｃｏｌ"，ＲＦＣ ２３２７，ＩＥＦＴ，Ａｐｒｉｌ １９９８． ［ＳＲＴＰ］Ｍ．Ｂａｕｇｈｅｒ，Ｒ．Ｂｌｏｍ，Ｅ．Ｃａｒｒａｒａ，Ｄ．ＭｃＧｒｅｗ，Ｍ．Ｎａｅｓｌｕｎｄ，Ｋ．Ｎｏｒｒｍａｎ ａｎｄ Ｄ．Ｏｒａｎ"Ｔｈｅ Ｓｅｃｕｒｅ Ｒｅａｌ Ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ"，ｄｒａｆｔ−ｉｅｔｆ−ａｖｔ−ｓｒｉｐ−０５．ｔｘｔ，ＩＥＴＦ，Ｊｕｎｅ ２００２．

従来技術のダウンロード・テクノロジを使用する使用権管理（ＤＲＭ）システムのデータ構造を示す。 従来技術のＤＲＭに含まれるノードを示す。 ダウンロード・テクノロジを使用するＤＲＭシステムにおいて，コンテンツ配信業者からのコンテンツにアクセスするために使用される従来技術の方法ステップを示す図である。 ダウンロード・テクノロジを使用するＤＲＭシステムにおいて，他のクライアント（超流通）からコンテンツへのアクセスに使用される従来技術の方法ステップを示す図である。 本発明によるメディア・ストリーミングの基本的なＤＲＭ機構を概略示す。 ストリーミング・メディアとＤＲＭの送信のための本発明による方法ステップを示す図である。 本発明によるストリーミング・メディアのＤＲＭを提供するノードと装置を示す概略ブロック線図である。 Ａ〜Ｄは本発明によるコンテンツ・オブジェクトにおける開始記述を含む種々の方法を示す。 Ａ〜Ｆは本発明によるコンテンツ・オブジェクトにおける暗号メディア鍵を持つ開始記述を含む種々の方法を示す。

Claims (27)

1. ダウンロードのための，デジタル・コンテンツの著作権管理であるＤＭＲ技術に従って処理されるデジタル・コンテンツをレンダリングするクライアント装置（１１）であって，該装置は，
   コンテンツとしてダウンロード・コンテンツを含む第１のタイプのコンテンツ・オブジェクト（２０）をダウンロードする手段と，
   関連するコンテンツ・オブジェクト（２０）を使用する権利を定義する使用規則（６）を含む権利オブジェクト（２）をダウンロードする手段と，
   関連する受信した権利オブジェクト（２）の使用規則（６）に従って，前記第１のタイプのコンテンツ・オブジェクト（２０）内のコンテンツをレンダリングする手段とを備え，
   前記コンテンツ・オブジェクトをダウンロードする手段はさらに，ストリーミング・セッションのためのセッション開始記述（２３）をコンテンツとして含む第２のタイプのコンテンツ・オブジェクトをダウンロードするために設けられ，
   前記コンテンツをレンダリングする手段はさらに，前記第２のタイプのコンテンツ・オブジェクト（２０）内の受信された前記セッション開始記述（２３）内の情報に従って，且つ関連する受信した権利オブジェクト（２）の前記使用規則（６）に従って，ストリーミング・セッションを設定するようになっており，その間，ストリーミング・メディアはストリーミングにより送られることを特徴としたクライアント装置。
2. 前記セッション開始記述（２３）は，ＳＤＰ記述，前記ストリーミング・メディアに対するＵＲＬまたはＳＭＩＬファイルを有することを特徴とする請求項１記載の装置。
3. 前記権利オブジェクト（２）は，前記第２のタイプのコンテンツ・オブジェクト（２０）内の前記セッション開示記述の暗号による保護に関連する第１の暗号データ（７）を含むことを特徴とする請求項１または２記載の装置。
4. 前記第２のタイプのコンテンツ・オブジェクト（２０）内の前記セッション開始記述（２３）は，前記ストリーミング・メディア（２２）の暗号による保護のための第２の暗号データ（２４）を更に有することを特徴とする請求項３記載の装置。
5. 前記第２の暗号データは，少なくとも１つの暗号鍵（２４）を有することを特徴とする請求項４記載の装置。
6. 前記第２の暗号データは，前記ストリーミング・メディアを保護する幾つかの暗号鍵（２４）を有することを特徴とする請求項４記載の装置。
7. 前記第１または第２のタイプのコンテンツ・オブジェクト（２０）および前記権利オブジェクト（２）をダウンロードする前記手段は，ＨＴＴＰ（ハイパーテキスト・トランスファ・プロトコル）および／またはＷＡＰ（ワイアレス・アプリケーション・プロトコル）および／またはＳＭＳ（ショート・メッセージ・サービス）を使用するようになっていることを特徴とする請求項１記載の方法。
8. ダウンロードのための，ＤＭＲ技術に従って処理されるデジタル・コンテンツをレンダリングする方法であって，該方法は，
   コンテンツを含むコンテンツ・オブジェクト（２０）をダウンロードするステップと，
   前記コンテンツ・オブジェクト（２０）を使用する権利を定義する使用規則（６）を含む権利オブジェクト（２）をダウンロードするステップと，
   前記使用規則（６）に従って，ダウンロードしたコンテンツをレンダリングするステップとを備え，
   前記コンテンツ・オブジェクト（２０）には第１のタイプまたは第２のタイプがあり，前記第１のタイプのコンテンツ・オブジェクトのコンテンツはダウンロード・コンテンツであり，前記第２のタイプのコンテンツ・オブジェクトのコンテンツはストリーミング・セッションのためのセッション開始記述であり，
   前記ダウンロードしたコンテンツをレンダリングするステップは，もしダウンロードしたコンテンツ・オブジェクトが前記第２のタイプのものである場合，前記セッション開始記述（２３）内の情報に従って，且つ受信した前記権利オブジェクト（２）と関連する前記使用規則（６）に従って，ストリーミング・セッションを設定するステップを含み，その間，ストリーミング・メディアはストリーミングにより送られることを特徴とする方法。
9. 前記セッション開始記述（２３）は，ＳＤＰ記述，前記ストリーミング・メディアに対するＵＲＬ，またはＳＭＩＬファイルを含むことを特徴とする請求項８記載の方法。
10. 前記権利オブジェクト（２）は，前記第２のタイプのコンテンツ・オブジェクト（２０）内の前記セッション開示記述の暗号による保護に関連する第１の暗号データ（７）を含むことを特徴とする請求項８または９記載の方法。
11. 前記第１の暗号データは暗号により保護されていることを特徴とする請求項１０記載の方法。
12. 前記ストリーミング・メディア（２２）は，前記第２のタイプのコンテンツ・オブジェクト内の前記セッション開始記述（２３）内の第２の暗号データ（２４）で暗号により保護されていることを特徴とする請求項１０記載の方法。
13. 前記ストリーミング・メディアはセキュリティ・プロトコルを使用して保護されていることを特徴とする請求項１２記載の方法。
14. セキュリティ・プロトコルとしてセキュア・リアルタイム・トランスポート・プロトコル（ＳＲＴＰ）が使用されていることを特徴とする請求項１３記載の方法。
15. 前記第１または第２のタイプのコンテンツ・オブジェクト（２０）及び／または権利オブジェクト（２）は暗号化及び／または完全性保護により保護されることを特徴とする請求項８記載の方法。
16. 前記権利オブジェクトと前記第２のタイプのコンテンツ・オブジェクトを受信すると，クライアント装置は前記コンテンツ・オブジェクトおよびストリーミング・メディアに対し前記権利オブジェクト内の情報に基づいて使用権を実施し，
    前記クライアント装置は前記第１の暗号データ（７）を使用して前記第２のタイプのコンテンツ・オブジェクト内の前記セッション開始記述（２３）にアクセスし，前記クライアント装置とストリーミング・サーバ（３２）との間に接続を設定することによりストリーミング・メディアの送信を開始することを特徴とする請求項１０または１１記載の方法。
17. ストリーミングサーバは，前記第２の暗号データ（２４）を使用して前記ストリーミング・メディア（２２）を暗号により保護し，前記レンダリングするステップは，
    前記第２のタイプのコンテンツ・オブジェクト内の前記第２の暗号データ（２４）にアクセスし，
    前記アクセスされた第２の暗号データ（２４）を使用して前記ストリーミング・メディア（２２）にアクセスし，
    前記使用規則に従って，アクセスされたストリーミング・メディアをレンダリングすることを特徴とする請求項１３記載の方法。
18. 前記セッション開始記述はＳＤＰ記述の形式であり，前記第２の暗号データ（２４）は前記ＳＤＰ記述内に含まれていることを特徴とする請求項１２記載の方法。
19. 前記セッション開始記述はＳＤＰ記述の形式であり，前記第２の暗号データ（２４）は前記ＳＤＰ記述とは別個に提供されていることを特徴とする請求項１２記載の方法。
20. 前記セッション開始記述はＳＭＩＬファイルの形式であり，前記第２の暗号データ（２４）は前記ＳＭＩＬファイルに含まれていることを特徴とする請求項１２記載の方法。
21. 前記セッション開始記述はＳＭＩＬファイルの形式であり，前記第２の暗号データ（２４）は前記ＳＭＩＬファイルとは別個に提供されていることを特徴とする請求項１２記載の方法。
22. 幾つかの第２暗号データアイテム（２４）が前記ストリーミング・メディアの保護のために使用されることを特徴とする請求項１２記載の方法。
23. 前記セッション開始記述（２３）は前記第２の暗号データ（２４）の管理に関する情報を含み，該情報は，前記ストリーミング・メディアの暗号による保護および／または前記最初の第２の暗号データ（２４）から得られた新しい暗号鍵で前記ストリーミング・メディア（２２）のデータの完全性の確認を可能にすることを特徴とする請求項１２記載の方法。
24. 配信サーバ（９）のＵＲＬ（ユニフォーム・リソース・ロケータ）は前記コンテンツ・オブジェクトのメタ・データ部分（８）に含まれていることを特徴とする請求項９記載の方法。
25. 前記第２の暗号データ（２４）は前記ストリーミング・メディアの完全性保護および／または受信確認のために暗号情報を得るために使用されることを特徴とする請求項１２記載の方法。
26. 前記コンテンツ・オブジェクト（２０）と前記権利オブジェクト（２）が，ＨＴＴＰ（ハイパーテキスト・トランスファ・プロトコル）および／またはＷＡＰ（ワイアレス・アプリケーション・プロトコル）および／またはＳＭＳ（ショート・メッセージ・サービス）を使用して前記クライアント装置（１１）に送られることを特徴とする請求項８記載の方法。
27. 前記権利オブジェクト（２）および／または前記コンテンツ・オブジェクト（２０）が前記クライアント装置に保護されていない方法でダウンロードされることを特徴とする請求項８記載の方法。

Images