(57)【要約】  本発明は、コンテンツ対象及び著作権対象に基づく管理機構を使用して、ストリーミング・メディアに対する著作権を管理する装置、システム及び方法に関する。本発明により、コンテンツ対象は、ストリーミング・メディアの開始のための手段を有し、前記著作権対象は、前記ストリーミング・メディアを使用する権利を明示する使用規則を有している。本発明は、デジタル・ストリーミング・メディアを送り保護する方法にも関する。本発明は、前記ストリーミング・メディアのセッション記述、ＳＤＰ記述、前記ストリーミング・メディアに対するＵＲＬまたはＳＭＩＬファイルを有してもよい。下見及び超流通が行われる。コンテンツ対象は、ダウンロード用の著作権管理システムにおいて、ダウンロード可能な対象のように送られ、それによりストリーミング・メディアの送信システムにおいて、著作権管理のための前記著作権管理システムの著作権管理機構を再使用する。
2005513664.tif 000002
【特許請求の範囲】
【請求項１】
コンテンツ対象と著作権対象に基づき管理機構を使用してストリーミング・メディアに対する著作権を管理する装置であって、前記コンテンツ対象は、前記ストリーミング・メディアの開始のための開始手段を有し、前記著作権対象は、前記コンテンツ対象及び／または前記ストリーミング・メディアを使用する権利を定義する使用規則を有している装置。
【請求項２】
前記開始手段は、前記ストリーミング・メディアのセッション記述、ＳＤＰ記述、前記ストリーミング・メディアに対するＵＲＬまたはＳＭＩＬファイルを有する請求項１記載の装置。
【請求項３】
前記著作権対象は、前記コンテンツ対象の少なくとも一部の暗号による保護に関連する第１の暗号データを含む請求項１または２記載の装置。
【請求項４】
前記コンテンツ対象は、前記ストリーミング・メディアの暗号による保護のための第２の暗号データを更に有する請求項３記載の装置。
【請求項５】
前記第２の暗号データは、少なくとも１つの暗号鍵を有する請求項４記載の装置。
【請求項６】
前記第２の暗号データは、前記ストリーミング・メディアを保護する幾つかの暗号鍵を有する請求項４記載の装置。
【請求項７】
著作権対象と、これに関連するコンテンツ対象との分離に基づき管理機構を使用してストリーミング・メディアに対する著作権を管理する方法であって、前記著作権対象が前記コンテンツ対象及び／または前記ストリーミング・メディアを使用する権利を定義する使用規則を有し、前記方法は、更に前記コンテンツ対象に前記ストリーミング・メディア用の開始記述を提供するステップを有する方法。
【請求項８】
前記ストリーミング・メディアのセッション記述の形で、ＳＤＰ記述の形で、前記ストリーミング・メディアのＵＲＬの形で、またはＳＭＩＬファイルの形で前記開始記述を提供する請求項７記載の方法。
【請求項９】
前記コンテンツ対象の少なくとも一部を暗号で保護し、この保護のために使用される第１の暗号データを前記著作権対象に提供する請求項７または８記載の方法。
【請求項１０】
前記第１の暗号データを暗号で保護する更なるステップを有する請求項９記載の方法。
【請求項１１】
前記ストリーミング・メディアを暗号で保護し、前記ストリーミング・メディアの保護のために使用される第２の暗号データを前記コンテンツ対象に提供する請求項９記載の方法。
【請求項１２】
セキュリティ・プロトコルを使用して前記ストリーミング・メディアを更に保護するステップを有する請求項１１記載の方法。
【請求項１３】
前記セキュリティ・プロトコルは、前記確実なリアルタイム輸送プロトコル（ＳＲＴＰ）である請求項１２記載の方法。
【請求項１４】
ダウンロード用の著作権管理システムにおいてダウンロード可能な対象として前記コンテンツ対象を送信するステップを更に有し、それにより、ストリーミング・メディアの送信用のシステムにおいて著作権管理のための前記著作権管理システムの前記著作権管理用の機構を再使用する請求項７記載の方法。
【請求項１５】
前記デジタル・メディアの一部を前記コンテンツ対象に提供するステップと、前記デジタル・メディアに対し権利を有しないまたは制限された権利を有するユーザに対し、そのように供給されたコンテンツ対象を送信するステップとを有する請求項７記載の方法。
【請求項１６】
前記コンテンツ対象及び／または前記著作権対象を暗号化及び／または完全性保護により保護する請求項７記載の方法。
【請求項１７】
デジタル・ストリーミング・メディアを配信すると共に、著作権対象とこれに関連するコンテンツ対象に基づきある機構を使用して前記デジタル・メディアに関する著作権を管理するシステムであって、
前記ストリーミング・メディアを提供するサーバ手段と、
コンテンツ対象を発生する手段と、
著作権対象を発生する手段と、
前記コンテンツ対象の少なくとも一部の暗号による保護で使用されるコンテンツ鍵手段を発生すると共にストリーミング時に前記メディアの暗号による保護で使用されるメディア鍵手段を発生する手段とを有するシステムにおいて、
前記ストリーミング・メディアのための開始記述を発生する手段と、
前記メディア鍵手段を記憶すると共に前記ストリーミング・メディアの前記暗号による保護で使用される前記記憶されたメディア鍵手段の検索を可能にする手段とを有するシステム。
【請求項１８】
前記開始記述手段は、前記ストリーミング・メディアのセッション記述、ＳＤＰ記述、前記ストリーミング・メディアに対するＵＲＬまたはＳＭＩＬファイルを発生する請求項１７記載のシステム。
【請求項１９】
コンテンツ対象と著作権対象に基づき管理機構を使用して、デジタル・メディアを配信し保護する方法であって、前記デジタル・メディアは、ストリーミング・サーバからクライアントにストリーミングされ、このストリーミングされたデジタル・メディアの著作権管理及び／または前記コンテンツ対象の管理をも可能にする方法において、
前記クライアントが前記デジタル・メディアに関する情報を含む配信サーバで前記デジタル・メディアの配信を要求するステップと、
前記配信サーバがこの要求に応答してメディア・データを含む第１の部分、並びに前記ストリーミング・メディアの開始記述と前記ストリーミング・メディアの保護に使用される暗号メディア鍵手段を含む第２の部分を有するコンテンツ対象であって暗号コンテンツ鍵手段で保護されたコンテンツ対象を前記クライアントに対して配信するステップと、
前記配信サーバが前記要求に応答して前記クライアントに対して前記コンテンツ対象及び／または前記ストリーミング・メディアを使用する権利を定義する使用規則と前記コンテンツ鍵手段とを含む著作権対象を同様に配信するステップと、
前記クライアントが前記著作権対象と前記コンテンツ対象の受信時に前記著作権対象に含まれる情報に基づいて前記コンテンツ対象及び／またはストリーミング・メディアに対する権利を執行すると共に前記開始記述を読み取るように前記コンテンツ鍵手段を使用して前記コンテンツ対象にアクセスするステップと、
前記開始記述の読み取りに応答して前記クライアントがこのクライアントと前記ストリーミング・サーバとの間に通信手段を設定することによりメディアのストリーミングを開始するステップと、
前記通信手段の設定に続いて前記ストリーミング・サーバが前記メディア鍵手段を使用して前記ストリーミング・メディアを保護し、このように保護されたストリーミング・メディアを前記クライアントに送るステップと、
前記保護されたストリーミング・メディアの受信時に前記クライアントが前記メディア鍵手段を使用して前記デジタル・メディアにアクセスし、前記使用規則に従って前記アクセスされたストリーミング・メディアをレンダリングするステップとを有する方法。
【請求項２０】
前記開始記述には、
前記ストリーミング・メディアのＵＲＬ、及び／または
前記サーバと前記クライアントの間の通信手段の設定に関するメタ・データ、及び／または
前記サーバから前記クライアントへの前記ストリーミング・メディアの輸送のためのストリーミング・メディア・プロトコルに対する言及、及び／または
前記ストリーミング・メディアに関するコーデック情報とを含める更なるステップを有する請求項１９記載の方法。
【請求項２１】
セキュリティ・プロトコルを使用して前記ストリーミング・メディアを保護する請求項１９記載の方法。
【請求項２２】
前記ストリーミング・メディアのストリーミング・セッションを記述するＳＤＰ記述（セッション・ディスクリプション・プロトコル）の形で前記開始記述を提供する請求項１９記載の方法。
【請求項２３】
前記ＳＤＰ記述に前記暗号メディア鍵手段を含める請求項２２記載の方法。
【請求項２４】
前記ＳＤＰ記述とは別に前記暗号メディア鍵手段を提供する請求項２２記載の方法。
【請求項２５】
ＳＭＩＬファイルの形で前記開始記述を提供する請求項１９記載の方法。
【請求項２６】
前記ＳＭＩＬファイルに前記暗号メディア鍵手段を含めることを特徴とする請求項２５記載の方法。
【請求項２７】
前記暗号メディア鍵手段を前記ＳＭＩＬファイルとは別に設ける請求項２５記載の方法。
【請求項２８】
前記ストリーミング・メディアのＵＲＬの形で前記開始記述を提供する請求項１９記載の方法。
【請求項２９】
前記ストリーミング・メディアの保護のため幾つかの暗号メディア鍵手段を使用する請求項１９記載の方法。
【請求項３０】
前記暗号メディア鍵手段の管理の情報を前記開始記述に含める更なるステップを有し、前記情報は、前記ストリーミング・メディアの暗号による保護及び／または前記最初の鍵から得られた新しい鍵で前記ストリーミング・メディアのデータの完全性の確認を可能にする請求項１９記載の方法。
【請求項３１】
前記コンテンツ対象のメタ・データ部分に配信サーバのＵＲＬ（ユニフォーム・リソース・ロケータ）を含める更なるステップを有する請求項１９記載の方法。
【請求項３２】
前記クライアントのユーザは、前記コンテンツ対象を別のユーザに送信する請求項１９記載の方法。
【請求項３３】
ストリーミング輸送プロトコルとして確実なリアルタイム輸送プロトコル（ＳＲＴＰ）を使用する更なるステップを有する請求項１９記載の方法。
【請求項３４】
暗号情報を得て前記ストリーミング・デジタル・メディアの完全性保護及び／または受信確認のために前記暗号メディア鍵手段を使用する請求項１９記載の方法。
【請求項３５】
ＨＴＴＰ（ハイパーテキスト・トランスファ・プロトコル）及び／またはＷＡＰ（ワイアレス・アプリケーション・プロトコル）及び／またはＳＭＳ（ショート・メッセージ・サービス）を使用して前記コンテンツ対象と著作権対象を前記クライアントに送る請求項１９記載の方法。
【請求項３６】
暗号化及び／または完全性保護により前記コンテンツ対象及び／またはストリーミング・デジタル・メディアを保護する請求項１９記載の方法。
【請求項３７】
前記著作権対象及び／または前記コンテンツ対象を前記クライアントに無防備で送る請求項１９記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般的にはネットワークを介して提供されたデジタル・コンテンツの管理のための著作権管理（デジタル・ライツ・マネジメンツ：ＤＲＭ）に関し、特に、ストリーミング・メディア用の著作権を管理するために使用する方法、装置及びシステムに関する。
【背景技術】
【０００２】
現代のデジタル通信テクノロジを使用するデジタル・コンテンツまたはメディア・データの配信は絶えず成長し、更に多くの伝統的な配信方法に取って代わりつつある。特に、コンテンツ・プロバイダからクライアントまたはユーザに対し、ネットワークを介してデジタル・コンテンツをダウンロードまたはストリーミングし、これにより一般的には、そのデジタル・コンテンツに関連したライセンスで明示されたなんらかのユーザの権利または使用規則に従いレンダリング装置を使用してコンテンツをレンダリングする傾向は増大している。配信が高価ではなく迅速かつ容易であるこの形状のコンテンツ配信の利点のために、オーディオ、ビデオ、画像、電子ブック及びソフトウエア、特に、モバイル電話のシーン用のリング信号及び背景画像のようなモバイル電話の特定コンテンツのようなあらゆる種類のコンテンツの配信用のアプリケーションを現在見つけることができる。
【０００３】
しかし、デジタル・メディア・コンテンツの配信のこの新しい方法の場合は、コンテンツ・プロバイダのデジタル資産を権限の無い使用及び不正なコピーから守る必要が生じる。デジタル・コンテンツの著作権保持者及び著者は自分たちの著作権の保護の強力な経済的利益を当然有し、これにより、著作権管理の要求（DRM;demand for right management）は増大している。ＤＲＭは、一般的には、デジタル・コンテンツの使用を保護し、監視し、これを制限すること並びに支払いの取り扱いを含む、デジタル・コンテンツ配信システムで、コンテンツ・プロバイダの財産を保護するテクノロジである。従って、ＤＲＭシステムは、暗号化、認証、鍵管理、使用規則の管理及び料金請求のための要素を通常有している。
【０００４】
ＤＲＭシステムに対する最も基本的な恐れには、盗聴、不正コピー、使用規則の改変及びＤＲＭ保護の除去並びに大規模不正使用のための非保護コンテンツの再配信がある。これらの基本的なセキュリティ問題の大部分は、暗号化、認証、完全性保護及び鍵管理を含む標準的な暗号化技術により解決される。しかし、ＤＲＭシステムのセキュリティ問題が他の一般的なセキュリティ問題と基本的に異なる点は、通信の相手側（ユーザ）でさえ完全には信用されないということである。実際、エンド・ユーザは、例えば、自分の支払い回数よりも多くメディア・コンテンツを表現させたり、または他のレンダリング装置に対してデジタル・コンテンツを不正にコピーしたりして、自分の使用著作権を詐欺により拡張しようとすることを望むかもしれない。従って、クライアントの奉仕装置では、何らかの形式の規則施行が要求される。このためには、ソフトウエアとして実行されるＤＲＭエージェントまたはモジュール及び／またはレンダリング装置の改ざん防止回路及び使用規則を表現する何らかの正式な言語は、上記の基本的な暗号化技術と共に普通使用される。暗号化の一般的背景については、［ＨＡＣ］を参照する。
【０００５】
上記の全てのメディアの種類は、信頼性のある輸送プロトコルを使用してユーザの装置にダウンロード可能であるが、リアルタイムのアプリケーションのため及び他の理由で、音楽またはビデオのようなメディアをデジタル的にクライアントにストリーミングするということは時々望ましいことである。メディアのストリーミングとは、全メディア・データを受信する前にこのデータの使用を可能にする効率的な方法で連続流の形でクライアントにデータを転送することを意味する。ストリーミングがダウンロードよりも実現の可能性がある例としては、例えば、レンダリングの前に、そのメディアの全部または一部をダウンロードすることがリアルタイム要件または記憶要件のために実現できないような長期間の生のスポーツ・イベントまたはミュージック・コンサートまたは他のメディアがある。
【０００６】
ストリーミングは、通常、エラーまたはデータの一部の喪失を生じる可能性のある信頼できない輸送機構を使用して行われる。（我々は「漸進的なダウンロード」をストリーミングとは考えない、これについては以下更に述べる。）信頼できない輸送機構を使用する理論的根拠は、リアルタイム要件がそんなに厳しいので、喪失したメディア・データを再送する時間が存在しない可能性があり、そして品質喪失の危険は、時々は容認可能であり、及び／またはエラー訂正符号または他の技術手段により管理される。メディアのダウンロード及びストリーミングは、ここで述べた相違が原因で固有のものであり、そして、輸送の相違のため、コンテンツの保護のために異なる手段を必要とし、また著作権管理の場合に特別な処置を必要とする。この相違点は、障害及びデータ喪失が有線ネットワークにおけるよりもしばしば起こるモバイル電話ネットワークのような無線ネットワークで強調される。
【０００７】
本発明は、特に、ダウンロード・コンテンツ用のＤＲＭ及びストリーミング・メディア用のＤＲＭに共通なソリューションを有する。このソリューションは、コンテンツを保護し著作権を管理するダウンロードＤＲＭ用の現存のシステムで事実上衝撃なしに実行することができる。
【０００８】
（最先端技術）
次は、クライアントにより使用される「コンテンツ」に関する著作権管理の本技術の記載である。コンテンツとは、一般にデジタル・データ対象のことであって、（ＴＣＰ（これについては後で更に述べる）のような）信頼可能な輸送プロトコルを使用してダウンロード可能である。ダウンロード可能なデジタル・コンテンツの例には、オーディオ、ビデオ、画像、電子ブック及びソフトウエアが含まれ、特に、リング信号及びモバイル電話のスクリーン用の背景画像のようなモバイル電話の特定コンテンツが含まれる。このコンテンツには、クライアントの使用規則及び得られたデジタル・メディアに関する著作権を明示するライセンスが関連している。
【０００９】
ＤＲＭは、デジタル・コンテンツそれ自体を管理することに関し、誰がそれを得るか、どのように送るか、どのように使用（レンダリング、保存、送信、コピー、実行及び／または変形）してよいか、何回使用してよいか、どの位長く著作権が続くのか、誰が支払うのか、どの位支払うのか、そして、方法のような問題を扱う。これらの問題の一部または全ては、ライセンスで明示してもよく、デジタル・コンテンツと共にまたは別々に送ってもよい。使用規則を記載するために、著作権表現言語と呼ばれる特別な言語が開発されている。今日使用されている最も一般的な著作権表現言語の２つは、エックステンシブル・ライツ・マークアップ・ラングウィジ（ＸｒＭＬ）とオープン・デジタル・ライツ・ラングウィジ（ＯＤＲＬ）である。
【００１０】
ＤＲＭの最も困難な部分は、ライセンスに含まれていてデジタル・コンテンツについて規定された使用規則を守らせることである。背景技術に示したように、改ざん防止装置に関連した暗号化技術は、現存するＤＲＭソリューション機構における共通の構成要素である。また、秘密に関するアルゴリズムとプロトコルに依存するような不明化（obfuscation）技術は、この文脈では、主に独占的なソリューションで使用される。それは、セキュリティ評価と、異なるソリューション間の相互運用性との両方がこの手段により妨害されるからである。
【００１１】
ダウンロードＤＲＭ用の最も一般的なデータ構造は、コンテンツとこの使用権との関係を維持しながらコンテンツとこのコンテンツの使用権とを分離することに基づいている。コンテンツと著作権の両方は、このコンテンツの使用のために必要とされる。ＤＲＭダウンロードの一例は、図１に関してまず記載され、その後、主にコンテンツと著作権の保護に関する何らかの変形例を与える。
【００１２】
図１の例では、ダウンロード可能なコンテンツを含む部分は、「コンテンツ対象」または「コンテンツ容器」１と呼ぶことにする。使用権を含む部分は、「権利対象」２として示す。権利対象の他の同義語は「チケット」または「ライセンス」である。コンテンツ対象は、実際のデジタル・コンテンツ３とメタ・データ４を含んでいる。コンテンツは、非常にしばしば保護された形で記憶され、例えば大長方形５により象徴されるように暗号化され、完全性が保護される。著作権の対象は、一般的には著作権表現言語で表現された使用権６、コンテンツ暗号鍵７及びメタ・データ８を有している。コンテンツ鍵の使用の場合、保護されたデジタル・コンテンツは、真正かどうか及び抽出された明確なテキストのデジタル・コンテンツであるかについてチェックすることができる。
【００１３】
コンテンツ対象のメタ・データは、コンテンツ対象の本体、実際のコンテンツに関する情報、著作権保持者の名前と場所、関連するアプリケーションまたはコンテンツの種類のようなコンテンツのレンダリングに関する情報、関連する著作権の対象をアクセス／購入可能である場所、例えば、コンテンツ・プロバイダ／配信者が主役となるウェブ・サーバに対するユニフォーム・リソース・ロケータ（ＵＬＲ）への言及を含んでもよい。著作権対象のメタ・データは、一般的には、コンテンツ対象の本体または（鍵付きの）寄せ集め暗号化コンテンツのような、どのコンテンツ対象に著作権対象が適用されるかについての言及を含んでいる。通常、与えられた著作権対象は、特定のコンテンツ対象に対し一義的に関連している。ある時は、与えられたコンテンツ対象は、幾つかの関連する著作権対象を有してもよい。この１つの理由は、必ずしもコンテンツ対象を変更せずに同一コンテンツの異なる使用を可能にするためである。
【００１４】
全く同一のコンテンツは、セキュリティの理由で相異なる暗号化鍵で暗号化されて異なるコンテンツ対象に記憶されてもよい。従って、特定の秘密コンテンツ鍵の開示は、その特定のコンテンツでコンテンツ対象の全ての所有者に対し、明確なテキストのコンテンツを開示するものではなく、この鍵で暗号化された特定のコンテンツ対象を有する人にのみ開示される。
【００１５】
上記の例の変形例は、コンテンツ対象全体が全体的に保護され、まさにコンテンツではないということである。また別の変形例は、暗号化鍵で著作権対象のコンテンツ鍵を暗号化することであり、このように暗号化されたコンテンツ鍵は、明確なテキストのコンテンツ鍵の代わりに著作権対象に記憶されるということである。更にまた別の変形例／補足例は、著作権対象が上記のものの他に「認証タグ」をも有するということである。この認証タグは、使用権及び／または明確なテキストとすることができ、または暗合化することができるコンテンツ鍵、及び／またはメタ・データの完全性保護のために含めることができる。少なくとも著作権は完全性保護とすべきほど重用である。それは、さもなければ、詐欺ユーザが与えられた著作権をその著作権の所有者に相談せずまたは別に料金の支払いもせずに自分の好みに変更し得るからである。著作権対象のセキュリティ管理、または、もし該当する場合は、コンテンツ鍵にアクセスし著作権の完全性を実証するなどに必要な暗号鍵のセキュリティ管理は、ＤＲＭ機構のセキュリティにとって極めて重要であるが、本テキストにおいてはこれ以上記載しない。
【００１６】
図２から図４に関し、コンテンツのダウンロード及びＤＲＭ機構が如何に動作するかの例を何らかのデジタル・コンテンツを使用する権利を購入するユーザに関連して記載する。この例は、コンテンツが他人には使用できず、または、この著作権対象において与えられた以外の他の手段によっては使用できないということを保証するこれらの権利の支持を強制するために如何にＤＲＭ機構が動作するかも示す。メディアの経験を共有する２人以上のユーザの例も与える。
【００１７】
図２に示した例では、ダウンロード可能なコンテンツのＤＲＭ用方式は、配信サーバ９、著作権サーバ１０、クライアント１１及びＤＲＭブローカ１２を有している。配信サーバ９は、コンテンツ対象及び著作権対象を記憶しそれを送る。著作権対象は、ユーザにより購入されてクライアントに送られる。著作権サーバは、以前に得たコンテンツ対象の著作権を購入する時に使用されるコンテンツ対象に対応する著作権対象を記憶する。クライアント１１は、コンテンツをレンダリングする装置である。クライアント１１においては、使用規則を強制するためのＤＲＭエージェント１３が存在する。ＤＲＭブローカは、恐らく相異なるネットワーク（図示せず）において相異なる著作権サーバを相互接続するネットワーク本体であって、クライアントのために単一の接触点を提供する。
【００１８】
図３において、クライアント１１を操作するユーザは、クライアント１１にダウンロード可能なコンテンツについて配信サーバのウェブ・ページを閲覧する。ユーザは、関連するいくつかの著作権を持つ特定のコンテンツについて決定を行い、支払いを行うに必要な情報を提供する。ユーザは、所望のコンテンツに対する要求１４を配信サーバに送る。この特定クライアント及び／またはユーザ用の適切な暗号保護付きのコンテンツ対象及び著作権対象は、好ましくは信頼性ある輸送機構を使用してクライアントに矢印１５と１６のように送られる。クライアント１１のＤＲＭエージェント内で、必要な暗号情報は、著作権対象の使用権に従って、コンテンツ対象内のコンテンツを使用するために集められる。
【００１９】
実行の場合、信用されたアプリケーションがコンテンツを確実にレンダリングするために必要である。ＤＲＭエージェントは、著作権対象内の著作権を解析し、コンテンツ（あるいはクライアント１１における局部的な秘密モジュールのような他の信頼された部分からのコンテンツの要求解読）を解読して、明示された著作権に従ってコンテンツをレンダリングまたは使用するために適切な信頼されたアプリケーションに転送する。このアプリケーションは、コンテンツの種類に依存し、例えば、音楽またはビデオのレンダリングはメディア・プレーヤ・アプリケーションに送られて、画像視聴者アプリケーションに画像を表示する等を行う。
【００２０】
所望の別の手続きは、ユーザが、特定の著作権対象なしに、またはこの権利付きでコンテンツ対象をクライアント１１にダウンロードすることを許可されていて、この手段によって全コンテンツの有限なバージョンを使用することができるということである。このことは、例えば、ある音楽から取り出した１０秒分のオーディオ抜粋片、画像の低分解能バージョンなどのようなマルチメディア・コンテンツの小さな一部となり得よう。只でまたは減額コストで有限な使用を許可する概念は「下見（preview）」として知られるが、それは、コンテンツを見たりまたは表示したりすることとは関係なくてもよい。
【００２１】
コンテンツに対する完全な著作権は、例えば、コンテンツ対象のコンテンツが暗号により保護され、全コンテンツを使用するに必要なコンテンツ鍵が（通常の価格の）著作権対象には配置されているから、この機構により露わになることができないものとすべきである。下見の後、ユーザは、そのコンテンツが購入するに望ましく、従って、著作権サーバにコンタクトするかどうかを決定することができ（そのＵＲＬは、コンテンツ対象からまたはＤＲＭブローカを介して利用してもよい）、従って、全コンテンツを利用し得るために、ＤＲＭエージェントで必要とされる著作権対象を購入しダウンロードすることができる。
【００２２】
下見で利用したコンテンツと使用権の分離は、以下に概略示す他の所望のコンテンツ配信の例、すなわち、超流通においても適用される。図４を参照。ユーザが、他のユーザと使用経験を共有することを望む場合を考慮する。コンテンツ対象は、それ自体保護されていて輸送中に特定のセキュリティを必要としないので、例えば、ブルートゥース、ＩｒＤＡ、ケーブルのような局部接続を介しまたは任意のネットワークによりその２つのクライアント間で直接コンテンツ対象を送信する場合には、セキュリティの危険が存在しない。
【００２３】
ユーザＢは、面白いコンテンツを経験し、クライアントＢに対してコンテンツ対象を、矢印１７で示したようにクライアントＡに対し送るよう命令する。受信されたコンテンツ対象は、受信ユーザがこれは面白いかどうかを決定することを容易にするために下見を含んでもよい。コンテンツ対象は、正しい著作権サーバにユーザを向けることができる関連の著作権サーバまたはＤＲＭブローカへの言及を含んでいる。クライアントＡは著作権サーバに接続されて、権利の取り決めを行い、支払いを受け入れ、矢印１８により示したように著作権対象を要求する。この要求された著作権対象は、クライアントＡに対して矢印１９のようにダウンロードされるので、以前に得られたコンテンツ対象はクライアントＡで使用することができる。コンテンツのピア・ツー・ピア配信の概念は、「超流通」と呼ばれ、コンテンツをベースとするビジネスにとって非常に重大なメカニズムと考えられている。潜在的に、望ましくその価格に値するコンテンツは、ユーザ達の中に迅速に広まり、コンテンツ・プロバイダ／配信業者にとって大きな収入源となる。
【００２４】
次に、ダウンロードとストリーミング用の配信機構を記載する。これらの機構は、それぞれの機構で輸送されたメディアに対する著作権の管理から生じる厄介な問題を考慮する時に理解することが重要である。
【００２５】
ＩＰネットワークにおけるダウンロードＤＲＭの場合、コンテンツ対象及び著作権対象は、ハイパー・テキスト・トランスポート・プロトコル（ＨＴＴＰ）またはファイル・トランスファー・プロトコル（ＦＴＰ）のような信頼性ある輸送プロトコルを使用してクライアントに送られる。これらは、大部分のウェブ・サーバとウェブ・ブラウザにより使用される標準的なウェブ・プロトコルである。ＨＴＴＰとＦＴＰの両方は全てのデータ転送を扱うトランスミッション・コントロール・プロトコル（ＴＣＰ）上で動作する。ＴＣＰゴールは、ファイル転送及び遠隔ログインのような非リアルタイム・アプリケーション用に最適化されて、データ転送速度を最大にし、全ネットワークの全安定性と高スループットを保障するようにしてある。
【００２６】
これを達成するため、まずＴＣＰは、スロー・スタートと呼ばれるアルゴリズムを使用して低データ速度でデータを送信し、次に、行き先がパケット損失を報告するまで徐々にデータ速度を増大する。次に、ＴＣＰは、それが帯域幅の限界またはネットワークの渋滞に遭遇して、低データ速度でのデータ送信に復帰し、次に、その処理の反復を徐々に増大すると仮定する。ＴＣＰは、喪失したパケットの再送信により信頼性あるデータ転送を達成する。しかし、全ての再送信になるパケットは、例えば、メディア・ストリームで再生できる特定の時間内にクライアントに到達するということを保証することはできない。
【００２７】
次に、ストリーミング技術を述べる。ＨＴＴＰとＦＴＰ（またはＴＣＰに基づく他のプロトコル）は、データの信頼性ある転送には適しているが、ストリーミング・メディアについてはあまりよく機能しない。その主な理由は、ＴＣＰは如何なるタイミング要件にも関係せずに信頼性ある輸送を実施し、ＴＣＰはメディアの必要に従うのではなく、帯域幅の利用可能性に従ってクライアント・サーバ接続のデータ転送速度を変更するからである。リアルタイム・データの輸送の最も一般的で標準化された例は、リアルタイム・トランスポート・プロトコル（ＲＴＰ）であり、これは、ＬＰネットワークにおけるマルチメディア・データ・ストリーム用のパケット・フォーマットである。リアルタイム・データの輸送用の大部分の独自のプロトコルは、ＲＴＰに類似している。
【００２８】
特に、ＲＴＰは、追加の機能に便宜をはかるプロトコル・フレームワークである。このプロトコルを完全に特定するには、ペイロード・フォーマット（例えば、メディア・エンコーディング）のような追加の情報が必要とされる。この情報は、ＲＴＰ用のいわゆる「プロファイル」を構成する。ストリーミング・アプリケーションにおいて、ＲＴＰは、ＴＣＰに比較してストリーミング経験を改善するユーザ・データグラム・プロトコル（ＵＤＰ）上で動作することが望ましい。ＴＣＰと違ってＵＤＰは、例えば、リアルタイムのオーディオ・ビデオ・データを送信するために理想化される、どのような再送信またはデータ速度管理機能のない迅速軽量なプロトコルであり、これにより、喪失データを寛容に取り扱うことできる。ＴＣＰプロトコルに暗に示された上記のスロー・スタート機構のために、ＵＤＰトラフィックは、ネットワークにおけるＴＣＰトラフィックよりも大なる帯域幅の部分を効果的に得る。
【００２９】
完全性のため、「斬新的ダウンロード」の概念を簡述すべきである。斬新的ダウンロードとは、通常ＴＣＰを使用してメディアを確実にダウンロードすることであるが、レンダリングはダウンロードの完了前に開始される。ＴＣＰはこの場合にも使用されるので、同じ制限が上記のダウンロードについて述べたようにリアルタイムのメディア・ストリームの場合に当てはまる。
輸送されたマルチメディア・ストリームの提示の制御のため、リアルタイム・ストリーミング・プロトコル［ＲＴＳＰ］のような制御プロトコルが使用される。ＲＴＳＰは、メディア・ストリーミング・セッションの設定、更にこのメディア・ストリームにおける開始、休止、停止及び移動（「早送り」と「巻き戻し」）のために使用してもよい。
【００３０】
ストリーミング・サーバとクライアントとを同期化するために、（クライアントのソフトウエア部である）メディア・クライアントは、ＲＤＰデータを正確に解釈するために初期化パラメータを有することが要求される。これらの初期化パラメータは、セッション・ディスクリプション・プロトコル［ＳＤＰ］で記載してもよい。このＳＤＰは、特に、セッション名称、このセッションがアクティブである時間、このセッションを含むメディア、これらのメディア（アドレス、ポート、フォーマットなど）を受信するための情報、使用される帯域幅、メディアの種類、コーディック（圧縮及び解凍のアルゴリズム）、メディア鍵及びマルチメディア・ストリームの特定メディアまたは全セッションに関する付加的な属性も含むマルチメディア・セッションのための記述プロトコルである。
【００３１】
以下はＳＤＰ記述の例である。
2005513664.tif 000003
【００３２】
「ｍ＝」フィールドは、ストリームを列挙するために使用され、プレイロードの種類、ＲＴＰプロファイル及び推薦ポートに関する情報を含んでいる。ＲＴＰ／ＡＶＰは、プレイロードはＵＤＰ上のＲＴＰであるということを示す。「ａ＝」フィールドは属性を示し、「ａ＝ｃｏｎｔｒｏｌ：」は、マルチメディア・ストリーム、この場合はオーディオ・ストリームに対するＵＲＬを示す。このＳＤＰの記述における情報に基づいて、メディア・クライアントは、輸送設定（ＩＰアドレス、ポート番号、及び他のパラメータ）を行うためにＲＴＳＰ  ＳＥＴＵＰ命令を送り、その確認後、そのメディア・ストリームを開始すべきＲＴＳＰ  ＰＬＡＹ命令がストリーミング・サーバにより送られる。更なる詳細は、［ＲＴＳＰ］及び［ＳＤＰ］において見ることができる。
前の例の特別な場合は、メディア・ストリームを開始するためにＲＴＳＰリンクＵＲＬをまさに使用することである。
2005513664.tif 000004
【００３３】
このようなＵＲＬは、ストリーミング・メディアを一義的に定義し、このデータをＲＴＳＰ  ＤＥＳＣＲＩＢＥメッセージで使用することによってストリーミング・セッションが開始され、これにより、前の例と同じストリームが生じる。しかし、輸送とプロトコルの情報は、ＲＴＳＰ  ＳＥＴＵＰとＰＬＡＹ命令をクライアントが発生できる前に、サーバとクライアントの間で取り決められなければならない。従って、レンダリングが開始（ＤＥＳＣＲＩＢＥメッセージと返答）できる前にクライアントとサーバとの間におけるメッセージの追加的な往復が生じる。結果として、ＲＴＳＰ  ＵＲＬだけでストリーミング・セッションを開始すると、余分な遅延が生じ、従って、第１の場合ほど効率的ではない。
【００３４】
ストリーミング・セッションを記述する他の方法は、マルチメディア・セッションを記述するメディア記述言語であるシンクロナイゼーション・マルチメディア・インテグレーション・ランゲージ（ＳＭＩＬ）を使用することである。ＳＭＩＬは、ウェブ・ページのコンテンツと形態を明示するが、これに対してマルチメディアの表現の時間ベース構造を加え、従って、互いに異なるストリームを明示可能にし、更に、異なる時間で種々のストリームを設定可能（または他のメディア対象をレンダリング可能にする）ハイパ・テキスト・マークアップ・ランゲージ（ＨＴＭＬ）として考慮することができる。ＳＭＩＬを使用するには、メッセージの追加の往復も必要とされ、従って、効率はより低い。しかし、ＳＭＩＬは、単一のＳＤＰ記述、例えば、画像のような時間離散対象により記述することができるよりも他の種類のマルチメディア・セッションをレンダリング可能にする。
【００３５】
次に、ストリーミング・メディアの保護について述べる。データの暗号化は、ネットワークを介してメディアの秘密性を維持するために通常必要とされる。暗号化されたデータは、原則として任意のプロトコルで輸送することができるが、プロトコルの信頼性がない場合、パケットの喪失によりデータの解読が不可能となり品質の重大な損失、暗号化していないデータのパケットの喪失よりも恐らく更に大きな品質の喪失が生じる可能性がある。暗号化アルゴリズムに依存して、喪失したパケットは、解読中にエラーを生じる可能性があり、このエラーは、他の受信パケットに広がってこれらの解読を不可能にする可能性がある。これは、データ全体の配信が保障されている信頼性のあるプロトコルの使用時に暗号化されたデータの配信とは対照的である。
【００３６】
それ故、特別なストリーミング暗号化プロトコルは無線ネットワーク用に設計されている。一例としては、セキュア・リアルタイム・トランスポート・プロトコル［ＳＲＴＰ］があるが、これは、ＲＴＰのプロファイルである。ＳＲＴＰは、秘密性、メッセージの証明及びＲＴＰ／ＲＴＣＰトラフィックに対する再生保護を提供する。それは、ＲＴＰパケットの喪失または再整理に寛大となるように暗号化されたデータのエラーが原因のエラー伝搬を回避するよう設計されており、暗号化ストリームにおける早送り及び巻戻しを可能にする。従って、ＵＤＰを介して輸送されたＳＲＴＰは、確実ではあるが信頼性のないプロトコルである。
【００３７】
ＳＲＴＰにより暗号化されたストリーミング・オーディオ／ビデオ・セッションに対するＳＤＰ記述の例は、次の通りである：
ｉ＝シーン背後のリングの支配者
2005513664.tif 000005
【００３８】
前の例との主な相違点は、ＳＲＴＰプロファイルである。これは、「ｍ＝」フィールドにおけるＲＴＰ／ＳＡＶＰにより示される。オーディオ・ストリームとビデオ・ストリーム用の個々の暗号化鍵は、「ｋ＝」フィールドにベース６４エンコーディングで含められている。
【発明の開示】
【発明が解決しようとする課題】
【００３９】
上記のダウンロード・テクノロジは、直接ストリーミング・テクノロジと使用するに適しているものではない。コンテンツとチケットの分離は、ストリーミングに当てはまる。
【００４０】
解決されるべき問題は、すなわち、（ａ）ストリーミング・マルチメディアの送信と、（ｂ）次の事実を考慮する送信されストリーミングされたマルチメディアの確実な著作権管理を可能にするために、ダウンロード・テクノロジとその確実な著作権管理を如何に変更するかである。
【００４１】
・ストリーミングは、メディアを受信する時にこのメディアのリアルタイム・レンダリングを意味する手順であり、ストリーミングは、ダウンロードによる場合のようにメディアのレンダリングを伴う受信メディアの記憶は認めない。
・ダウンロードに使用される現存のネットワーク要素と機構は、可能な最大程度、ストリーミングのためにも使用すべきであり、かくして、それらはダウンロードとストリーミングのために使用することができる。
・ストリーミング・メディアは、ユーザ・データグラム・プロトコル（ＵＤＰ）のような信頼できない輸送プロトコルを使用する。少量のビット・エラーまたは喪失パケットは、メディアの品質に大きな影響を与えずに取り扱うことができ、これが制御することができるか、またはユーザが余りにもノイズのあるメディアに対して金の支払いをする必要がないように少なくとも検証可能な場合には、ユーザに受け入れ可能となる可能性がある。
【００４２】
・しかし、上記のように、ＤＲＭシステムでは幾つかのデータ、例えば、変更が受け入れられない使用規則及び暗号メディア鍵は信頼性なしでは輸送できない。それは、それらデータが制定された規則を侵害したり、または、コンテンツの解読を不可能にすることがあるからである。
・暗号によるストリーミング・メディアの保護のために、暗号鍵はストリーミング・サーバとクライアントとの間で確実に一致させなければならない。
【００４３】
・確実なストリーミング輸送プロトコルが使用される場合に、暗号鍵は、ストリーミングが開始する前に利用可能とならなければならないが、ダウンロードＤＲＭプロトコルは、著作権対象とコンテンツ対象の到着順には通常気づかない。
・ストリーミング・データを「巻き戻し」し、「早送り」し得ることは望ましい。
・あるアプリケーション、例えば、リアルタイム・アプリケーションでは、同時にコンテンツ全体に対してアクセスすることはできない（例えば、ウェブ・キャスト）。このことで、メディアの取り扱いは影響を受けるべきではない。
【００４４】
従来技術のＤＲＭシステムでは、ダウンロード・メディア用のＤＲＭとストリーミング・メディア用のＤＲＭの両方に共通のソリューションはない。実際、著作権を管理さえせずに、ある障害付きのチャネルを介して送られたストリーミング・メディアの暗号による保護はほとんど扱われない（１つの経験は、［ＳＲＴＰ］である）。特に、コンテンツのダウンロード用のＤＲＭを提供する現存のシステムが与えられた場合、このシステムにストリーミング用のＤＲＭを透明状態で組み込むためのソリューションは存在しない。また、超流通、コンテンツの下見及び著作権の購入のための機構を含むダウンロード及びストリーミングの両方用に透明状態で作用する他の重要な制限も存在する。
本発明は、上述の問題に対するソリューションを提供する。
【課題を解決するための手段】
【００４５】
本発明の１つの目的は、ストリーミング・メディアを持つＤＲＭを取り扱うソリューションを提供することである。
本発明の他の目的は、メディア・ダウンロードのＤＲＭ用の現存のプロトコル及び保護機構を使用することによりストリーミング・メディアを持つＤＲＭの取り扱いを提供することである。
本発明の更に他の目的は、ストリーミング・メディアの超流通を可能にするストリーミング・メディア付きのＤＲＭの取り扱いを提供することである。
本発明の更に他の目的は、ストリーミング・メディアの著作権を管理する装置及び方法を提供することである。
本発明の更に他の目的は、ストリーミング・メディアの著作権を配信し管理するシステム及び方法を提供することである。
これらの及び他の目的は、請求の範囲に明示した発明により達成される。
【００４６】
本発明の顕著な特徴は、コンテンツ対象及び関連する著作権対象を含むＤＲＭ機構を使用することであり、コンテンツ対象は、コンテンツではなく、デジタル・メディアがストリーミングによりクライアントに転送される今度のストリーミング・セッションの開始記述である。この特徴により、下見及び超流通が可能となる。セッション開始記述には、未許可の使用からストリーミング・メディアの保護の暗号鍵をオプションで含んでもよい。
以下において、「コンテンツ」なる表現は、従来技術のダウンロードＤＲＭソリューションにおいてコンテンツ対象内にコンテンツが配置される場所に置かれたどんなデータをも時には示す。
【００４７】
次に、本発明を示す。理解の簡単化のため、ダウンロード用の最新式のＤＲＭソリューションで記述されたコンテンツ対象及び著作権対象を使用する、ダウンロード用の現存の与えられた著作権管理システムを想定する。ストリーミング・メディアの著作権は、次の構成により管理される。
【００４８】
・コンテンツ対象の実際のデジタル・コンテンツの代わりに、ストリーミング・メディアの開始記述が記録内の同一場所に配置されている。この開始記述は、例えば、ＳＤＰ記述、特に特定のストリーミング・メディアを示すＲＴＳＰ  ＵＲＬ、ＳＭＩＬファイルなどを含んでもよい。
・開始記述は、無許可の使用からのストリーミング・メディアの保護に関する暗号化情報をオプションで含んでもよい。
これとは別に、ダウンロード用のＤＲＭソリューションは、変更なしで再使用される。従って、例えば、著作権対象は、使用規則及び「コンテンツ」を暗号化する暗号化鍵を含んでいる。まさにダウンロードの場合のように、ＤＲＭエージェントは、使用規則を解析し、「コンテンツ」を解読し、レンダリングを行う適切な信頼性あるアプリケーションに対し明確なテキストの「コンテンツ」を送る。ストリーミング・メディアの場合、「コンテンツ」はストリーミング・メディア開始記述である。
【００４９】
特定のコンテンツ配信シナリオにおけるアクタ間のトラスト・モデルに依存するが、それは、ダウンロードＤＲＭシステムにより可能にされたストリーミング開始記述を保護することで十分であり、実際のストリーミング・メディアの保護は行われない。もしある条件のうちの１つ以上が満足されるならば実際のストリーミング・メディアの保護が十分無視できると考えられる場合のその条件のいくつかの例を以下に示す。
・もしストリーミング開始記述が権限のない側へは漏洩せず権限を与えられた側へのみストリーミングが許容される場合。
・権限のない使用を思いとどまらせたり、または制限するために、ストリーミング・メディアを盗み聞きすることが十分に困難な場合。
・もし権限のない使用を思いとどまらせたり、または制限するためにストリーミング・メディアを記憶することが十分に困難な場合。
【００５０】
しかし、一般的な場合、特に上記の条件の一部のみが満足されまたは全部が満足されない場合、ストリーミング・メディア開始記述の保護は十分ではなく、ストリーミング・メディアの追加の保護が必要である。ストリーミング・メディアの暗号による保護は、オープン・システム・インターコネクト（ＯＳＩ）モデルの任意のレベルにおいて適応可能である。以下においては、この一例を記載する。その場合、保護は、輸送レベルへ与えられる。
【００５１】
ストリーミング・メディアのセキュリティの明確な改良は、コンテンツ・プロバイダ／配信者により管理されるストリーミング・サーバとクライアントにおける信頼されたストリーミング・アプリケーションとの間での輸送中のメディアの暗号による保護である。これは、前に述べたＳＲＴＰのような確実で（特に、無線ネットワークの場合）頑丈なストリーミング輸送プロトコルを使用して達成してもよい。この場合、ストリーミング・サーバとクライアントの間でストリーミング・メディアを保護するために使用される暗号鍵は、信任された当事者にとって極秘に保持されるということは、もちろん極めて重要である。これは、ストリーミング・メディア開始記述に含められるよう本発明がオプションで明示する暗号情報であってもよい（または、この暗号情報によって管理されてもよい）。例えば、ＳＤＰ記述は、前の例の１つに示したように、メディア鍵の仕様のためのオプションの属性を有している。
【００５２】
特に、このような情報記述は、１つだけかまたは幾つかのＲＴＳＰ  ＵＲＬと、暗号化鍵を含む暗号化鍵属性を含んでいる。あるいは、暗号鍵は、ストリーミング開始記述で、明確なテキストのストリーミング・セッションの任意の開始記述、例えば、暗号鍵（cryptographic key）で束ねられた鍵属性のないＳＤＰ記述と共に、特に１つまたは数個のＲＴＳＰ  ＵＲＬと別々の暗号化鍵（encription key）とで輸送することができる。ストリーミング・メディア開始記述の他の具体例は、暗号鍵で束ねられたＳＭＩＬファイルである。
付加的なセキュリティ機構は、ストリーミング・メディア開始記述またはストリーミング・メディア自体を保護するために考慮することもできる。
【発明の効果】
【００５３】
本発明は、一般的にはストリーミング・メディアの著作権管理（ＤＲＭ）に適応可能である。本発明は、メディア・ダウンロード用のＤＲＭとストリーミング・メディア用のＤＲＭに対し共通のソリューションを提供する。本発明の場合、ストリーミング・メディアを取り扱う互換性あるシステムを可能にするための、ダウンロード・システム用の現存のＤＲＭにおいては変更はほとんど必要とされない。このことと、これらの変更がダウンロード用のＤＲＭのコンセプトに一体となって適合するという特定の方法とのために、著作権管理、超流通、下見、特定のコンテンツに対する著作権対象の購入などのようなＤＲＭダウンロード・システムの全ての特徴は、ストリーミング・メディアに対しもたらされる。例えば、超流通は、一般的にはピア・トゥ・ピア（Peer to Peer）でコンテンツ対象を送ることによって行われる。受信ピアは、購入した著作権対象でピア自身のストリーミング・セッションを開始することができる。
【００５４】
ストリーミングの下見の概念については、説明語句が必要かもしれない。これは、幾つかの方法で行うことができる。１つの方法は、コンテンツ対象に対して実際にクライアントにダウンロードされる全コンテンツまたは関連コンテンツの有限なマルチメディア・サンプルを供給することである。他の方法は、クライアントが、一時的または他の方法で制限された／限定されたストリームをオプションによりバージョン全体よりも低い分解能／品質で設定できる鍵を提供することである。
【００５５】
本発明は、オプションとして、メディア・ストリームの暗号による保護を可能にすると共に、ストリーミング・サーバとストリーミング・クライアントにおいて共通の秘密鍵を如何に確立するかの鍵管理問題を解決もする。この構成は、ＳＲＴＰのような確実で頑丈なストリーミング・プロトコルの使用と両立するので、本発明は、送信の場合にエラーを発生させる障害を伴う無線ネットワークの場合と同様、有線ネットワークにおける著作権の管理にも完全に適するものである。
【００５６】
前述のように、メディア・コンテンツのストリーミングとダウンロードとの間には幾つかの相違点がある。しかし、いずれかの方法によりレンダリングされる同一メディア、例えば、音楽コンサートのビデオに関するユーザ経験は著しく相違する必要はない。すなわち、クライアントにダウンロードされたコンサートは、時々起こる障害のどのような兆候をも示さないという利点を有しており、一方、クライアントにストリーミングされたビデオには、ライブで直接放送されるコンサートの場合がある。
【００５７】
本発明によれば、まったく同一の著作権管理機構は、メディアの輸送とは独立にメディアのダウンロードとストリーミングの両方に使用してもよい。この著作権管理機構は、超流通、重要なビジネスのケースと考えられる著作権の購入などのために働く。超流通がダウンロードに対して働くのみの場合、ストリーミング・サービスの導入により、潜在的にダウンロード・コンテンツの超流通のためにビジネス・ケースを損傷する可能性のあるコンテンツを配信／購入する能力は不安定になる。
【００５８】
同一の著作権管理機構がメディアのダウンロードとストリーミングの両方に使用されるので、ダウンロードとストリーミングのための平行ソリューションを実行することは必要ではない。それは、統合されたユーザの経験を保証することもできる。
本発明は、更なる目的と利点と共に添付図面と共に以下の記載を参照することにより最も良く理解されよう。
【実施例１】
【００５９】
図５は、本発明によりストリーミング・メディアのＤＲＭの例のデータ構造とクライアントの図を示す。さしあたり、クライアントは、ストリーミング・セッション中にストリーミング・サーバ２１からクライアントにデータパケット２２で輸送される特定のデジタル・マルチメディアに対するコンテンツ対象２０と著作権対象２を受信したと仮定する。この状況がどのように生じるかは更に以下に記載する。
コンテンツ対象は、メタ・データ、メディア鍵２４を含む上記の種類のＳＤＰ記述の形式で開始記述２３を有している。開始記述は、大矩形２５により象徴されるように暗号により保護されている。
コンテンツ対象と関連した著作権対象は、まさにダウンロードＤＲＭの場合のように、メタ・データ、使用権及びコンテンツ鍵を有している。
【００６０】
クライアントは、コンテンツ対象に設けられたメディア鍵を含む保護された開始記述を解読するために著作権対象内に設けられたコンテンツ鍵を使用する。明確なテキスト・メディア鍵は、保護されたマルチメディア・ストリーム２２の解読のためにクライアントにより使用される。解読されたメディア・ストリームは、アプリケーションによりアクセスされてメディア・プレイヤ（図示せず）上でレンダリングされる。
【００６１】
マルチメディア・ストリームがクライアントに送られる前に、ストリーミング・メディア・セッションが設定されなければならない。このためには、クライアントとストリーミング・サーバとの間に接続（connection）が設定される。この接続を介して、マルチメディアの名称、種類、配置場所、その符号化方法などのようなマルチメディアに関する多くの種類の情報は、ストリーミング・サーバとクライアントの間でマルチメディア・ストリームが開始される前に交換される。開始記述は、これらの目的のために使用される。
【００６２】
図６は、ＤＲＭに対しストリーミング・メディアを提供するための本発明による方法のステップを示す。クライアントは、マルチメディアの要求を矢印２６で示したように配信サーバに送る。要求されたマルチメディアに対する著作権の条件は、取り決められて決定される。矢印２７により示した次のステップは、配信サーバがクライアントに対して保護された開始記述を持つコンテンツ対象を送るということである。次に、使用権及びコンテンツ鍵を含む著作権対象は、矢印２８により示したようにクライアントに送られる。
【００６３】
上記のコンテンツ鍵を使用して、クライアントは、セッション開始記述を解読し、そこに与えられた情報を使用してストリーミング・サーバに対するストリーミング・セッションの設定を開始する。これは、二重の向きを示した矢印２９により示してある。この接続を越えて、ストリーミング・セッションで使用される更なるパラメータが交換される。最後のステップで、ストリーミング・セッションが開始され、パケットの保護されたマルチメディア・ストリームは、矢印３０により示されたように、クライアントに対しストリーミングを開始する。
【００６４】
パケットは、開始記述に示されたストリーミング・プロトコル、この場合はＳＲＴＰプロトコルで送られる。信頼性のあるプロトコルは、著作権対象及びコンテンツ対象、例えば、ＨＴＴＰまたはＷＡＰを送るために使用される。信頼性あるプロトコルは、ＲＴＳＰ制御のシグナリングのために使用もされる。
クライアントは、ストリーミング・サーバに対し受取通知または確認を送ることによりパケットの受信を証明してもよい。そのような機構はＳＲＴＰ／ＳＲＴＣＰプロトコル［ＳＲＴＰ］の一部である。
【００６５】
図７は、本発明によるストリーミング・メディアのＤＲＭを提供するためのモード及び装置を示すブロック線図である。マルチメディア・ストリームを提供するストリーミング・サーバ３２、メディア鍵と同様コンテンツ鍵も提供する暗号化鍵発生器３３、メディア鍵を記憶するメディア鍵・データベース３４、コンテンツ対象発生器３５、著作権対象発生器３６、配信サーバ３７、著作権サーバ３８を含むコンテンツ・サーバ３１が存在する。
【００６６】
コンテンツ対象発生鍵は、（矢印３９により示される）コンテンツ・サーバ３１からストリーミング・セッションの開始記述で使用される上記の開始パラメータを取り出す。メディア鍵２４は、鍵発生器３３から取り出される。開始記述は、鍵発生器３３により同様に発生されたコンテンツ鍵を使用して暗号により保護される。このコンテンツ鍵は、著作権対象発生器用に利用可能でもある（下記参照）。メタ・データは、同様に取り出され、コンテンツ対象に含められる。発生されたコンテンツ対象は、配信サーバに記憶され、そのコピーは、図６の矢印２７に従ってクライアントに送られる。
【００６７】
著作権対象発生器は、コンテンツ対象に関連した著作権対象を発生し、その内部にコンテンツ対象の保護のために使用されたと同じコンテンツ鍵を有する。本体（identity）を有する著作権対象は、配信サーバと著作権サーバに記憶される。そのコピーは、図６の矢印２８に従ってクライアントに送られる。
二重頭付き矢印４０は、メディア鍵とコンテンツ鍵のコンテンツ対象発生器と著作権対象発生器への配信を示す。
【００６８】
コンテンツ対象に挿入されたメディア鍵は、発生されたコンテンツ対象に関連した著作権対象の本体と共にメディア鍵・データベースに記憶されもする。これは、図７において矢印４１で示してある。
今までの状況は次の通りである。すなわち、クライアントは、前に記載した（図６の矢印２７、２８）ようにコンテンツ対象と著作権対象とを受信している。メディア鍵２４と関連する著作権対象の本体はメディア鍵・データベースに記憶される。
【００６９】
次に、（図６における矢印２９に対応する）図７の矢印２９でクライアントからのセッション設定メッセージは、ストリーミング・サーバにより受信される。このメッセージは、前に述べた情報を含み、クライアントとサーバとの間のその後のシグナリングにより、コンテンツ対象に関連した著作権対象の本体が現わされる。ストリーミング・サーバは、矢印４２により示されるメディア鍵要求をメディア鍵・データベースに送り、矢印２９で受信された著作権対象の本体を提供する。この要求に応答して、メディア鍵・データベースは、表示された著作権対象の本体についてサーチされ、対応するメディア鍵を矢印４３により示したようにストリーミング・サーバに戻す。ストリーミング・サーバは、次に（図６の矢印３０に対応する）矢印３０で示すように、クライアントに対して送り始めるメディア・ストリームを暗号により保護するために、そのメディア鍵を使用する。ストリーミング・サーバとクライアントは、両者とも、それぞれ暗号化及び解読のために同一のメディア鍵を使用する。
【００７０】
上記例の多くの変形例が可能である。ストリーミング・サーバでの暗号化用及びクライアントでの解読用に同一のメディア鍵を使用する代わりに、ストリーミング・サーバは、公開メディア鍵を使用してもよく、秘密メディア鍵はコンテンツ対象においてクライアントに送られる。
他の変形例は、記述される明確なテキストでコンテンツ対象を提供する代わりに、このコンテンツ対象のメディア鍵を暗号で同様に保護もすることである。
メディア・ストリーム及び／またはコンテンツ対象は、暗号化及び／または完全性保護により同様に保護されてもよい。著作権対象及び／またはコンテンツ対象は、無防備でクライアントに同様に送られてもよい。
【００７１】
コンテンツと著作権対象がクライアントに送られる順序は、逆転してもよい。すなわち、図６においてステップ２８は、ステップ２７より前にあってもよい。それらは、モバイル通信ネットワークにおいて同様にＳＭＳメッセージの場合のような別々の通信チャネルを介し、そしてＷＡＰプロトコルを使用して、それぞれ送られてもよい。
開始記述は、コンテンツ対象発生器により提供する代わりにコンセント・サーバにより提供されてもよい。
【００７２】
図８において、コンテンツ対象の種々の実施例が８Ａ〜８Ｄに示してある。図８における全ての実施例に共通な特徴は、暗号情報が開始記述には含まれていないということである。図８Ａにおいて、通常のメタ・データと開始記述ファイルを含む基本的なバージョンが示してあるが、今回はメディア鍵なしである。図８Ｂにおいて、開始記述は、鍵属性を設定せずにＳＤＰ記述として具体化されている。図８Ｃで、開始記述は、鍵なしのＳＭＩＬファイルとして具体化されている。図８Ｄは、図８Ｂの特別な場合であって、ＳＤＰ記述はストリーミング・メディアを取り扱うＲＴＳＰ  ＵＲＬである。
【００７３】
図９においては、コンテンツ対象の更に異なる実施例が９Ａ〜９Ｆに示してある。全ての実施例に共通な特徴は、暗号情報が開始記述には含まれているということである。図９Ａにおいては、通常のメタ・データとメディア鍵を有する開始記述ファイルを含む基本的なバージョンが示してある。図９Ｂでは、開始記述は設定された鍵属性を含むＳＤＰ記述として具体化されている。図９Ｃでは、開始記述は、設定された鍵属性のないＳＤＰ記述として具体化されている。メディア鍵は、開始記述内に別に含まれている。図９Ｄでは、開始記述は、ＳＭＩＬファイルとメディア鍵として設けられている。図９Ｅは、図９Ｂの特別な場合であって、ＳＤＰ記述はストリーミング・メディアを取り扱うと共に設定されたメディア鍵属性を有するＲＴＳＰ  ＵＲＬである。同様に図９Ｆは、図９Ｃの特別な場合であって、ＳＤＰ記述はストリーミング・メディアを取り扱うＲＴＳＰ  ＵＲＬである。メディア鍵は、開始記述においてはＲＴＳＰ  ＵＲＬとは別に設けられている。
【００７４】
なお、図９に示したメディア鍵は、例えば更なるメディア鍵及び／または他の種類のセキュリティを提供する更なる鍵のような更なる鍵を幾つか含んでもよい。幾つかのメディア鍵を使用する１つの理由は、セキュリティを高めるように完全なメディア・ストリームのまさに一部と各鍵を関連付けることである。この背景にあるアイディアは、盗聴するものが単一鍵を使用してメディア・ストリーム全体を解読することを不可能にすべきであるということである。
上記の実施例は単に例として与えたものであって、本発明はこれに限定されないと理解されるべきである。ここに開示され、かつ請求された基本的根本的原理を保持する更なる変形例、変更及び改良は、本発明の範囲及び主旨内にある。
【００７５】
【非特許文献１】［ＨＡＣ］Ａ．Ｊ．Ｍｅｎｅｚｅｓ，Ｐ．Ｃ．ｖａｎ  Ｏｏｒｓｃｈｏｔ  ａｎｄ  Ｓ．Ｃ．Ｖａｎｓｔｏｎｅ，“Ｈａｎｄｂｏｏｋ  ｏｆ  Ａｐｐｌｉｅｄ  Ｃｒｙｐｔｏｇｒａｐｈｙ”，ＣＲＣ  Ｐｒｅｓｓ．
【非特許文献２】［ＲＴＰ］Ｖ．Ｊａｃｏｂｓｏｎ，Ｓ．Ｌ．Ｃａｓｎｅｒ，Ｒ．Ｆｒｅｄｅｒｉｃｋ  ａｎｄ  Ｈ．Ｓｃｈｕｌｚｒｉｎｎｅ，“ＲＴＰ：Ａ  Ｔｒａｎｓｐｏｒｔ  Ｐｒｏｔｏｃｏｌ  ｆｏｒ  Ｒｅａｌ−Ｔｉｍｅ  Ａｐｐｌｉｃａｔｉｏｎｓ”，ＲＦＣ  １８８９，ＩＥＴＦ，  Ｎｏｖｅｍｂｅｒ  ２００１．
【非特許文献３】［ＲＴＳＰ］Ｈ．Ｓｃｈｕｌｚｒｉｎｎｅ，Ａ．Ｒａｏ，Ｒ．Ｌａｎｐｈｉｅｒ，“Ｒｅａｌ  Ｔｉｍｅ  Ｓｔｒｅａｍｉｎｇ  Ｐｒｏｔｏｃｏｌ（ＲＴＳＰ）”，ＲＦＣ  ２３２６，ＩＥＴＦ，Ａｐｒｉｌ  １９９８．
【非特許文献４】［ＳＤＰ］Ｍ．Ｈａｎｄｌｅｙ，Ｖ．Ｊａｃｏｂｓｓｏｎ，“ＳＤＰ：Ｓｅｓｓｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ  Ｐｒｏｔｏｃｏｌ”，ＲＦＣ  ２３２７，ＩＥＦＴ，Ａｐｒｉｌ  １９９８．
【非特許文献５】［ＳＲＴＰ］Ｍ．Ｂａｕｇｈｅｒ，Ｒ．Ｂｌｏｍ，Ｅ．Ｃａｒｒａｒａ，Ｄ．ＭｃＧｒｅｗ，Ｍ．Ｎａｅｓｌｕｎｄ，Ｋ．Ｎｏｒｒｍａｎ  ａｎｄ  Ｄ．Ｏｒａｎ“Ｔｈｅ  Ｓｅｃｕｒｅ  Ｒｅａｌ  Ｔｉｍｅ  Ｔｒａｎｓｐｏｒｔ  Ｐｒｏｔｏｃｏｌ”，ｄｒａｆｔ−ｉｅｔｆ−ａｖｔ−ｓｒｉｐ−０５．ｔｘｔ，ＩＥＴＦ，Ｊｕｎｅ  ２００２．
【図面の簡単な説明】
【００７６】
【図１】従来技術のダウンロード・テクノロジを使用する著作権管理（ＤＲＭ）システムのデータ構造を示す。
【図２】従来技術のＤＲＭに含まれるノードを示す。
【図３】ダウンロード・テクノロジを使用するＤＲＭシステムにおいて、コンテンツ配信業者からのコンテンツにアクセスするために使用される従来技術の方法ステップを示す図である。
【図４】ダウンロード・テクノロジを使用するＤＲＭシステムにおいて、他のクライアント（超流通）からコンテンツへのアクセスに使用される従来技術の方法ステップを示す図である。
【図５】本発明によるメディア・ストリーミングの基本的なＤＲＭ機構を概略示す。
【図６】ストリーミング・メディアとＤＲＭの送信のための本発明による方法ステップを示す図である。
【図７】本発明によるストリーミング・メディアのＤＲＭを提供するノードと装置を示す概略ブロック線図である。
【図８】Ａ〜Ｄは本発明によるコンテンツ対象における開始記述を含む種々の方法を示す。
【図９】Ａ〜Ｆは本発明によるコンテンツ対象における暗号メディア鍵を持つ開始記述を含む種々の方法を示す。
【図１】
2005513664.tif 000006
【図２】
2005513664.tif 000007
【図３】
2005513664.tif 000008
【図４】
2005513664.tif 000009
【図５】
2005513664.tif 000010
【図６】
2005513664.tif 000011
【図７】
2005513664.tif 000012
【図８】
2005513664.tif 000013
【図９】
2005513664.tif 000014
【手続補正書】
【提出日】平成16年9月9日(2004.9.9)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
コンテンツ対象（２０）と著作権対象（２）の分離に基づきダウンロード管理機構を使用してストリーミング・メディア（２２）に対する著作権を管理する装置であって、前記著作権対象が前記コンテンツ対象及び／または前記ストリーミング・メディアを使用する権利を定義する使用規則（６）を有している装置において、前記コンテンツ対象は、前記ストリーミング・メディアの開始手段（２３）を有し、これにより、前記ダウンロード管理機構は、ストリーミング・メディアの送信システムにおいて著作権管理のために再使用することが可能となり、それにより、ダウンロードとストリーミングの両方のために前記ダウンロード管理機構が使用されることを特徴とする装置。
【請求項２】
前記開始手段は、前記ストリーミング・メディアのセッション記述、ＳＤＰ記述、前記ストリーミング・メディアに対するＵＲＬまたはＳＭＩＬファイルを有することを特徴とする請求項１記載の装置。
【請求項３】
前記著作権対象（２）は、前記コンテンツ対象の少なくとも一部（２３）の暗号による保護に関連する第１の暗号データ（７）を含むことを特徴とする請求項１または２記載の装置。
【請求項４】
前記コンテンツ対象（２０）は、前記ストリーミング・メディア（２２）の暗号による保護のための第２の暗号データを更に有することを特徴とする請求項３記載の装置。
【請求項５】
前記第２の暗号データは、少なくとも１つの暗号鍵（２４）を有することを特徴とする請求項４記載の装置。
【請求項６】
前記第２の暗号データは、前記ストリーミング・メディアを保護する幾つかの暗号鍵（２４）を有することを特徴とする請求項４記載の装置。
【請求項７】
著作権対象（２）と、これに関連するコンテンツ対象（２０）との分離に基づきダウンロード管理機構を使用してストリーミング・メディアに対する著作権を管理する方法であって、前記著作権対象が前記コンテンツ対象及び／または前記ストリーミング・メディアを使用する権利を定義する使用規則（６）を有している方法において、前記コンテンツ対象（２０）に前記ストリーミング・メディア用の開始記述（２３）を提供するステップを有し、これにより、前記ダウンロード管理機構は、ストリーミング・メディアの送信システムにおいて著作権管理のために再使用可能となり、それにより、メディアのダウンロードとストリーミングの両方のために前記ダウンロード管理機構が使用されることを特徴とする方法。
【請求項８】
前記ストリーミング・メディアのセッション記述の形で、ＳＤＰ記述の形で、前記ストリーミング・メディアのＵＲＬの形で、またはＳＭＩＬファイルの形で前記開始記述（２３）を提供することを特徴とする請求項７記載の方法。
【請求項９】
前記コンテンツ対象の少なくとも一部を暗号で保護し（２５）、この保護のために使用される第１の暗号データ（７）を前記著作権対象に提供することを特徴とする請求項７または８記載の方法。
【請求項１０】
前記第１の暗号データを暗号で保護することを特徴とする請求項９記載の方法。
【請求項１１】
前記ストリーミング・メディアを暗号で保護し、前記ストリーミング・メディアの保護のために使用される第２の暗号データ（２４）を前記コンテンツ対象に提供することを特徴とする請求項９記載の方法。
【請求項１２】
セキュリティ・プロトコルを使用して前記ストリーミング・メディアを保護することを特徴とする請求項１１記載の方法。
【請求項１３】
セキュリティ・プロトコルとして確実なリアルタイム輸送プロトコル（ＳＲＴＰ）を使用することを特徴とする請求項１２記載の方法。
【請求項１４】
ダウンロード用の著作権管理システムにおいてダウンロード可能な対象として前記コンテンツ対象（２０）を送信し、それにより、ストリーミング・メディアの送信システムにおいて著作権管理のための前記著作権管理システムの著作権管理用の機構を再使用することを特徴とする請求項７記載の方法。
【請求項１５】
前記デジタル・メディアの一部を前記コンテンツ対象に提供し、前記デジタル・メディアに対し権利を有しないまたは制限された権利を有するユーザに対し、そのように供給されたコンテンツ対象を送信することを特徴とする請求項７記載の方法。
【請求項１６】
前記コンテンツ対象（２０）及び／または前記著作権対象（２）を暗号化及び／または完全性保護により保護することを特徴とする請求項７記載の方法。
【請求項１７】
著作権対象（２）とこれに関連するコンテンツ対象（２０）の分離に基づきダウンロード管理機構を使用してデジタル・ストリーミング・メディアを配信し、このデジタル・ストリーミング・メディアに関する著作権を管理するシステムであって、
コンテンツ対象を発生する手段（３５）と、
著作権対象を発生する手段（３６）と、
前記コンテンツ対象（２０）の少なくとも一部の暗号による保護で使用されるコンテンツ鍵手段を発生すると共にストリーミング時に前記メディアの暗号による保護で使用されるメディア鍵手段（２４）を発生する手段（３３）とを有するシステムにおいて、
前記ストリーミング・メディアを提供するサーバ手段（３２）と、
前記ストリーミング・メディアに関する開始記述を発生する手段（３５）と、
前記メディア鍵手段を記憶すると共に前記ストリーミング・メディアの暗号による保護で使用される前記記憶されたメディア鍵手段の検索を可能にする手段（３４）とを有し、これにより、前記ダウンロード管理機構は、ストリーミング・メディアの送信システムにおいて著作権管理のために再使用可能となり、それにより、メディアのダウンロードとストリーミング・メディアの両方のために前記ダウンロード管理機構が使用されることを特徴とするシステム。
【請求項１８】
前記開始記述手段（３５）は、前記ストリーミング・メディアのセッション記述、ＳＤＰ記述、前記ストリーミング・メディアに対するＵＲＬまたはＳＭＩＬファイルを発生することを特徴とする請求項１７記載のシステム。
【請求項１９】
コンテンツ対象（２０）と著作権対象（２）の分離に基づくダウンロード管理機構を使用して、デジタル・メディア（２２）を配信し保護する方法であり、前記デジタル・メディアは、ストリーミング・サーバ（３２）からクライアント（１１）にストリーミングされ、このストリーミングされたデジタル・メディアの著作権管理及び／または前記コンテンツ対象の管理をも可能にする方法であって、
前記クライアントが前記デジタル・メディアに関する情報を含む配信サーバ（９）において前記デジタル・メディアの配信を要求するステップ（２６）と、
前記配信サーバが前記要求に応答して前記クライアントに対してメディア・データ（４）を含む第１の部分を備えているコンテンツ対象（２０）であって暗号コンテンツ鍵手段（２５）で保護されたコンテンツ対象（２０）を配信するステップ（２７）と、
前記配信サーバが前記要求に応答して前記クライアントに対して前記コンテンツ対象及び／または前記ストリーミング・メディアを使用する権利を定義する使用規則（６）と、更に前記コンテンツ鍵手段（７）とを含む著作権対象（２）を同様に配信するステップ（２８）と、
前記クライアントが前記著作権対象と前記コンテンツ対象の受信時に前記著作権対象に含まれる情報に基づいて前記コンテンツ対象及び／またはストリーミング・メディアに対する権利を執行するステップとを有する方法において、
前記ストリーミング・メディアの開始記述と、前記ストリーミング・メディアの保護の場合に使用される暗号メディア鍵手段（２４）とを含む前記コンテンツ対象内に設けられた第２の部分（２３）を読み取るように前記コンテンツ鍵手段（７）を使用して前記コンテンツ対象にアクセスし、
前記開始記述の読み取りに応答して前記クライアントは、このクライアントと前記ストリーミング・サーバとの間に通信手段を設定することによりメディアのストリーミングを開始し（２９）、
前記通信手段の設定に続いて前記ストリーミング・サーバは、前記メディア鍵手段を使用して前記ストリーミング・メディアを保護し、このように保護されたストリーミング・メディアを前記クライアントに送り（３０）、
前記保護されたストリーミング・メディアの受信時に、前記クライアント（１１）は、前記メディア鍵手段（２４）を使用して前記デジタル・メディアにアクセスし、前記使用規則に従って前記アクセスされたストリーミング・メディアをレンダリングし、これにより、前記ダウンロード管理機構は、ストリーミング・メディアの送信システムにおいて著作権管理のために再使用が可能となり、それにより、メディアのダウンロードとストリーミング・メディアの両方のために前記ダウンロード管理機構が使用されることを特徴とする方法。
【請求項２０】
前記開始記述には、
前記ストリーミング・メディアのＵＲＬ、及び／または
前記サーバと前記クライアントの間に通信手段の設定に関するメタ・データ、及び／または
前記サーバから前記クライアントへの前記ストリーミング・メディアの輸送のためのストリーミング・メディア・プロトコルに対する言及、及び／または
前記ストリーミング・メディアに関するコーデック情報とを含める更なるステップを有する請求項１９記載の方法。
【請求項２１】
セキュリティ・プロトコルを使用して前記ストリーミング・メディアを保護することを特徴とする請求項１９記載の方法。
【請求項２２】
前記ストリーミング・メディアのストリーミング・セッションを記述するＳＤＰ記述（セッション・ディスクリプション・プロトコル）の形で前記開始記述を提供することを特徴とする請求項１９記載の方法。
【請求項２３】
前記ＳＤＰ記述に前記暗号メディア鍵手段（２４）を含めることを特徴とする請求項２２記載の方法。
【請求項２４】
前記ＳＤＰ記述とは別に前記暗号メディア鍵手段（２４）を提供することを特徴とする請求項２２記載の方法。
【請求項２５】
ＳＭＩＬファイルの形で前記開始記述を提供することを特徴とする請求項１９記載の方法。
【請求項２６】
前記ＳＭＩＬファイルに前記暗号メディア鍵手段（２４）を含めることを特徴とする請求項２５記載の方法。
【請求項２７】
前記暗号メディア鍵手段を前記ＳＭＩＬファイルとは別に設けることを特徴とする請求項２５記載の方法。
【請求項２８】
前記ストリーミング・メディアのＵＲＬの形で前記開始記述（２３）を提供することを特徴とする請求項１９記載の方法。
【請求項２９】
前記ストリーミング・メディアの保護のため幾つかの暗号メディア鍵手段（２４）を使用することを特徴とする請求項１９記載の方法。
【請求項３０】
前記暗号メディア鍵手段の管理の情報を前記開始記述（２３）に含め、前記情報は、前記ストリーミング・メディアの暗号による保護及び／または前記最初の鍵（２４）から得られた新しい鍵で前記ストリーミング・メディアのデータの完全性の確認を可能にすることを特徴とする請求項１９記載の方法。
【請求項３１】
前記コンテンツ対象のメタ・データ部分（８）に配信サーバ（９）のＵＲＬ（ユニフォーム・リソース・ロケータ）を含めることを特徴とする請求項１９記載の方法。
【請求項３２】
ストリーミング輸送プロトコルとして確実なリアルタイム輸送プロトコル（ＳＲＴＰ）を使用することを特徴とする請求項１９記載の方法。
【請求項３３】
暗号情報を得て前記ストリーミング・デジタル・メディアの完全性保護及び／または受信確認のために前記暗号メディア鍵手段（２４）を使用することを特徴とする請求項１９記載の方法。
【請求項３４】
ＨＴＴＰ（ハイパーテキスト・トランスファ・プロトコル）及び／またはＷＡＰ（ワイアレス・アプリケーション・プロトコル）及び／またはＳＭＳ（ショート・メッセージ・サービス）を使用して前記コンテンツ対象（２０）と著作権対象（２）を前記クライアント（１１）に送ることを特徴とする請求項１９記載の方法。
【請求項３５】
暗号化及び／または完全性保護により前記コンテンツ対象及び／またはストリーミング・デジタル・メディアを保護することを特徴とする請求項１９記載の方法。
【請求項３６】
前記著作権対象（２）及び／または前記コンテンツ対象（２０）を前記クライアントに無防備で送ることを特徴とする請求項１９記載の方法。
【国際調査報告】
2005513664.tif 000015
2005513664.tif 000016