ストリーミングデータを配給する方法、該方法に用いるクライアントデバイスおよびオーダサーバ
【課題】ストリーミングデータ、特に著作権により保護されたストリーミングデータの、耐性及び安全性のあるダウンロードを行う方法及び装置を提供する。
【解決手段】ストリーミングメディアを配給する手続において、第１に、クライアントがオーダサーバからメディアをリクエストする。該オーダサーバはクライアントを認証し、該クライアントにチケットを送付する。続いて、クライアントは該チケットをストリーミングサーバに送付する。ストリーミングサーバは該チケットの有効性を照合し、有効である場合、ＳＲＴＰといった標準リアルタイムプロトコルを使用してストリーミングデータを暗号化し、暗号化データをクライアントに送信する。クライアントは該データを受信して復号する。本プロトコルは、携帯電話やＰＤＡといった低容量のワイヤレスクライアント及び同等の装置等に適している。
【解決手段】ストリーミングメディアを配給する手続において、第１に、クライアントがオーダサーバからメディアをリクエストする。該オーダサーバはクライアントを認証し、該クライアントにチケットを送付する。続いて、クライアントは該チケットをストリーミングサーバに送付する。ストリーミングサーバは該チケットの有効性を照合し、有効である場合、ＳＲＴＰといった標準リアルタイムプロトコルを使用してストリーミングデータを暗号化し、暗号化データをクライアントに送信する。クライアントは該データを受信して復号する。本プロトコルは、携帯電話やＰＤＡといった低容量のワイヤレスクライアント及び同等の装置等に適している。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ストリーミングサーバからクライアントに対してストリーミングデータを配給する方法及びネットワークと、ストリーミングデータの配給に使用される装置及びサーバとに関するものである。
【背景技術】
【０００２】
ディジタル通信技術は、データ配布及び複製に便利な方法を提供しているが、殆どの手段は不正アクセス又は再配布に対して著作権が規制されているメディアの保護を講じていない。
【０００３】
一部の著作権所有者は自分自身の権利保護に対して強い経済的な関心を持っており、これによりディジタル著作権管理DRM(Digital Rights Management)に対する要求が高まった。一般的に、不安定なチャネル上で伝送される著作権が規制されたデータの保護には、正当なユーザ認証及びデータの暗号化といった暗号化方式が必要となる。著作権の管理には、信頼関係の確立、暗号化鍵の管理、及び課金の他、許可されるメディアの利用明細を伴う。（例としてインターネットサイトhttp://www.cselt.it/mpeg/を参照。）
【０００４】
妨害に曝されるワイヤレスネットワーク又は他の通信システムでは特殊な問題が発生している。無線放送の性質により、非常に容易に盗聴される可能性があり暗号化が求められている。しかし、この場合、秘密認証情報及び／又は暗号データは伝送中の誤りにより不正となる場合があり、それにより通信が切断されるか又は歪む可能性がある。特に秘密データは、リアルタイム又は他のストリーミングメディアを有し、そのような場合、不正データを修復又は再送する時間は殆ど或いは全くない。さらに、暗号化は、広い帯域幅を使用することとなり、携帯電話といった小型軽量クライアントのコンピュータに過負荷をかけることがある。
【０００５】
携帯電話又はいわゆる「パーソナルディジタルアシスタント」（ＰＤＡ）といった受信装置の記憶容量が非常に制限されている場合、大記憶容量が必要なＤＲＭソリューションを含むことはできない。同様の理由で、一の装置に複数の異なるＤＲＭソリューションを有することは不適切又は不可能である。したがって、ＤＲＭソリューションは、何らかの既存のセキュリティ構造をできるだけ利用すべきである。他方、このような装置における制限された環境は、ＤＲＭソリューションで活用されるべき利益も有している。第１に、容量が制限されているという制約により、ストリーミングデータ全体が保存され、後で摘出されることが防止される。第２に、任意の他形態でデバイスからディジタルコンテンツを容易に摘出できない。つまり、当該デバイスをいわゆる「耐タンパーモジュール」と考えることができるか、または簡単な手段により「耐タンパーモジュール」に変更するか、又はそれを含むものにすることが可能である。
【０００６】
既存のＤＲＭソリューションの殆どが部分的に「セキュリティ・バイ・オブスキュリティ("security by obscurity")」に基づいている。つまり、使用される方法がユーザに知らされない。これでは、ユーザの視点から見てソリューションに対する信頼を確立することは困難である。第２に、このオブスキュリティにより、攻撃を仕掛けることが明らかにより困難になっているが、それはオブスキュリティが維持されている間のみである。いずれ何者かが当該ソリューションを解析調査するか、或いは「漏洩」が存在すると、システムセキュリティが即座に危ぶまれるといった歴史が繰り返されている。それゆえ、できる限り公知のアルゴリズム及びプロトコルに基づいたソリューションが大いに役立つ。
【０００７】
従来技術
コンテンツ保護や権利管理の様々な方法が存在しているが、妨害に曝された不安定なメディア上でストリーミングデータを伝送するにはいずれも適していない。本対象に関連性を有するソリューションを列挙し、以下に簡潔に論評する。
【０００８】
共通に使用される用語及び略語は以下のものを含む。
−ＤＲＭ(Digital Rights Management)（ディジタル著作権管理）： 以下の１以上の技術を包含する一般的なフレームワーク。
−暗号法(Cryptography)： A Menezes, P. van Oorschot, and S. Vanstoneによる "Handbook of Applied Cryptography", CRC Press, 1997及びインターネットサイトhttp://www.cacr.math.uwaterloo.ca/hac/.を参照。
−電子透かし(Watermarking)： データ作成時に実際のデータにディジタルマークを上書きすることにより、該合成データをデータ作成者に結付け、マーキングを改ざんに対して耐性にするプロセス。つまり、特定のデータ「品質」を維持しつつ当該マークを完全に消去することが難しくなければならない。通常、電子透かしはソフトウェア技術である。
−複製保護(Copy protection)： 品質を保持しながら複製することが難しくなるように、及び／又は、複製者に遡ることができるように、データが保存及び配布されるプロセス。通常、完全な保護には特殊目的のハードウェアが要求される。
【０００９】
リアルタイムメディアを輸送するプロトコルを以下に説明する。
−ＲＴＰ(Real time transport Protocol)： リアルタイム及びストリーミングデータを輸送するためのＩＥＴＦが提起した規格。Schulzrinne, H., Casner, S., Frederick, R., Jacobson, V.による "RTP: A Transport Protocol for Real-Time Applications", IETF Request For Comments RFC 1889, 及びインターネットサイトhttp://www.ietf.org/rfc/rfc/1889.txt参照。
−ＳＲＴＰ(Secure RTP or The Secure Real Time Transport Protocol)： ＩＥＴＦ起案；暗号化のために余剰ヘッダを付加しない比較的軽量なエラーロバストなストリーム暗号文を用いた暗号化を包含するＲＴＰのためのセキュリティプロトコル。当該セキュリティプロトコルは、ＳＲＴＰを用いた伝送の使用帯域幅を減らし、ＩＰｓｅｃ等と比較して妨害を受けにくいものにする。インターネットサイトhttp://search/ietf.org/internet-drafts/draft-ietf-avt-srtp-00.txt参照。
−ＲＴＳＰ(Real Time Streaming Protocol)： オーディオ／ビデオ装置の「リモコン操作」と同様の方法でディジタルストリームを操作するための、ＩＥＴＦが提起した規格。インターネットサイトhttp://www.ietf.org/rfc/rfc2326.txt参照。
−ＲＯＨＣ(Robust Header Compression)： ＵＤＰ及びＲＴＰヘッダ等の圧縮のためのＩＥＴＦが提起した規格（２００１年３月５日付け）。インターネットサイトhttp://www.ietf.org/rfc/rfc3095.txt、http://www.ietf.org/rfc/rfc3096.txt、及びhttp://search.ietf.org/internet-drafts/draft-ietf-rohc-rtp-09.txt参照。圧縮とは、パケットサイズを低減し、それによりビット誤りの確率を低下させ、雑音チャネル上の輸送に適応させる。ＳＲＴＰはＲＴＰペイロードを暗号化するだけなので、ＲＯＨＣ及びＳＲＴＰが完全な互換性を有する。
【００１０】
規格化ソリューション
ＤＲＭ及びストリーミングメディアを議論する複数の規格化団体があり、中でも最も成熟した規格化の研究は、Moving Picture Experts Group（ＭＰＥＧ）の知的財産管理保護(Intellectual Property Management and Protection)(ＩＰＭＰ）である。インターネットサイトhttp://www.cselt.it/mpeg/standards/ipmp参照。ＭＰＥＧ ＩＰＭＰはＤＲＭのフレームワークを提供しているが、それ自身にＤＲＭを含むものではない；意図的に専用ソリューションに向けて開示している。
【００１１】
ＯＰＩＭＡ(Open Platform Initiative for Multimedia Access)（インターネットサイトhttp://drogo.cselt.it/leonardo/opima/参照）は、アクセス制御、コンテンツ管理及び保護ツールに関するフレームワークの規格化に取組んでいる。該規格化は、ダウンロード可能及び／又は置換可能なインターネットセキュリティ及び有料ＴＶアプリケーションに取組んでいるが、ワイヤレス環境には対応していない。
【００１２】
ＩＥＴＦ（又は、より具体的にはその調査グループのＩＲＴＦ）は、目下、ＤＲＭの研究グループを創設している（インターネットサイトhttp://www.idrm.org参照）。
【００１３】
専用ソリューション
マイクロソフト社は、Windows Media Rights Manager 7を擁する（インターネットサイトhttp://www.microsoft.com/windows/windowsmedia/en/wm7/drm.asp参照）。このソリューションでは、ユーザはいわゆるクリアリングハウスでライセンスを購入することができ、それをＣＤ、電子メール又はストリーミングサーバに保存可能な特定のメディアの再生に使用できる。当該ライセンスはユーザにではなくコンピュータに結びついている。当該ソリューションでは、保存及び処理リソースが制限されていないので特殊目的のソフトウェアをダウンロード及び再生実行することができるＰＣ市場を標的としている。
【００１４】
Verance（インターネットサイトhttp://www.verance.com/verance/technology.html参照）は、特殊なワイヤレスＤＲＭを所有すると公表しているが、当該システムは、単に電子透かしに基づいているだけのようである。そのソリューションは、ストリーミングメディアの暗号化を含んではいないようである。
【００１５】
E-vue（インターネットサイトhttp://www.e-vue.com参照）は、ＭＰＥＧ４準拠コード化及びオーサリングツールを製造している。サイトでは詳細を開示していないが、当該ネットワークソリューションは、トランスポートプロトコルに依存しておらず、より高水準で個別の暗号化を含むことを必要とする。
【００１６】
東芝による特許文献１では、安全にＭＰＥＧ４を配布するシステムが開示されている。しかし、実在のＤＲＭソリューションを提供しておらず、主にＭＰＥＧ４を暗号化し、ＲＴＰフレーム内に包含させる方法を特定している。ＭＰＥＧ４の暗号化の後、余剰の暗号ヘッダがペイロードに付加される。該暗号化はトランスポートレイヤで行われず、特殊目的のソフトウェア及び／又はハードウェアを必要とする。
【００１７】
Intertrustによる特許文献２では、ストリーミングメディアを保存可能ないわゆるセキュアコンテナ、制御情報及び該コンテナを開いて暗号鍵を摘出する装置を用いた一般的なＤＲＭソリューションが開示されている。しかし、妨害に曝された環境での使用のためのソリューションは、はっきりと示されていない。また、当該鍵がコンテナ内にあるため、ストリーミングを継続する前に当該鍵を摘出して確認しなければならず、これがリアルタイムでの要件に与える影響は多大である。
【００１８】
Audible社による特許文献３では、ストリーミングデータを再生するための再生装置を認証するためのフレームワークが開示されているが、安全な媒体を介しての輸送を前提としていないにもかかわらず、暗号化及び暗号文化に言及していない。
【特許文献１】欧州特許公報第１０４１８２３号
【特許文献２】欧州特許公報第１０６２８１２号
【特許文献３】国際特許出願公報第２０００／５２５８３号
【発明の開示】
【発明が解決しようとする課題】
【００１９】
課題
妨害に曝された環境においてリアルタイムでの要件に準拠するＤＲＭソリューションは存在していない。また、既存のソリューションは、クライアントにおける拡張用記憶装置及び／又は、特殊目的のソフトウェア及び／又はハードウェアを必要とする。既存のＤＲＭソリューションは一般的に私有であり、標準的なプロトコルを使用しておらず、それにより、クライアントにおいて複数のＤＲＭソリューションを実施する必要がある。これでは、記憶容量が不十分な場合は不可能である。さらに、使用されるアルゴリズムが非開示であり、大部分のユーザを信頼させることはできない。
【００２０】
既存のソリューションに付随する別の問題は、特定ユーザに対して発行される場合と対照的に、ＰＣ等の特定のハードウェア又は少数のハードウェアデバイス向けのディジタル著作権が発行され、メディアがＣＤにコピー可能である点である。
【００２１】
要旨
本発明の目的は、ストリーミングデータ、特に著作権により保護されたストリーミングデータの、耐性及び安全性のあるダウンロードを行う方法及び装置を提供することである。
【００２２】
本明細書に開示される方法では、既存の安全なトランスポートプロトコルが使用され、これによりＤＲＭが容易に拡張できる利点を提供する。データコンテンツの暗号化保護は既に定着しているので、基本的に、適応するＡＡＡ (Authentication, Authorization and Accounting) に類するメカニズムによるプログラムの拡張のみを必要とする。
【００２３】
当該方法及びネットワークでは、以下の構成要素を使用することができる。
−耐久性があり、軽量で、安全性のある標準化リアルタイムトランスポートプロトコル
−鍵配布システム
−課金サービス
−改ざん防止モジュール
【００２４】
一般的に、著作権により保護されたデータ等のストリーミングデータにアクセスする方法及びネットワークでは、以下の順序に限らず、次の事象を行うことができる。
−ストリーミングデータに対するクライアント又はクライアント装置からの要求又はオーダー
−クライアント認証
−課金
−ストリーミングデータの送信
【００２５】
ストリーミングメディアのアクセスで双方向に作用する部分は、一般的に、クライアント又はクライアント装置、オーダサーバ（ＯＳ）、及びストリーミングサーバ（ＳＳ）を含んでおり、該クライアントはオーダサーバにメディアをオーダーし、該オーダサーバは該メディアオーダを処理し、該ストリーミングサーバがストリーミングメディアをクライアントに配給する。
【００２６】
当該方法及びネットワークは、ストリーミング目的、リアルタイム、できれば特殊な場合の双方向性のデータ転送に適応する著作権により保護されたマテリアルを配布する単純な方法を提供する。当該方法及びネットワークに耐性のあるプロトコルを使用することにより、該方法及びネットワークは、既存のソリューションと比べてワイヤレスクライアント及び不均一な環境に十分に適している。ＳＲＴＰ、ＷＴＬＳ等のような標準化プロトコルを使用する利点は、該標準化プロトコルがディジタル著作権管理目的のみならず、様々な装置において実施することができるので、再利用により記憶容量を大幅に節約できることである。これは、携帯電話及びＰＤＡ等の低容量のクライアントデバイスには重要である。
【００２７】
提起した方法及びネットワーク並びにその構成要素、クライアントデバイスに実装可能な耐タンパーモジュールでさえ、オープンスタンダード及び公知のアルゴリズムに基づいているか、或いは基づくことができる。他のＤＲＭソリューションを評価することは、それらが秘密手続及び実施に依存する「セキュリティ・バイ・オブスキュリティ」に部分的に基づいているため困難である。所望の対象物を保護する秘密アルゴリズムは、いずれは公知となる傾向がある。例えば、ＧＳＭ暗号化アルゴリズム、ＤＶＤ暗号化アルゴリズムなど、そのようなソリューションは、一般的に暗号分野では不十分とみなされる：前記ソリューションは実施前に公の調査に対して公開されていない。この場合、現代の一般的な暗号法の全てにおいて見られるように、一度評価された手続の強度は、鍵及び鍵の管理に頼ることになる。
【００２８】
公開され大部分が標準化されたソリューションの別の利点は、自身のデータの保護及び配布のために誰でも該ソリューションを利用できることである。例えば、比較的知られていない「ガレージロックグループ」或いは独立していない映画製作会社や作家は、安全な方法で自分の著作物をより多くの対象者に単純で低コストな方法で配布することができる。そのような著作物のウェブポータルホスティング手続を想定することができる。
【００２９】
本明細書に記載された方法及びネットワークを使用する際、特殊目的の小型軽量クライアントについての別の利点は、受信機がより一般的なパーソナルコンピュータ等の大型装置である場合に比べて「ハッカー」によるストリーミングデータのアクセス及び保存が殆ど実行できないことである。アナログ出力信号を記録することはできても、高品質ディジタル信号は装置内に確実に保護されなければならない。即ち、小型軽量クライアントは、それ自体の多くの実用的な趣旨のため、耐タンパー装置とみなすことができる。ハードウェアの複製保護を迂回することが潜在的に非常に簡単である自己構築のパーソナルコンピュータ環境とは対照的に、携帯電話や他の携帯型装置の製造をコントロールすることにより、セキュリティを容易に得ることができる。実際に、製造者はその製品のセキュリティ保証を得ることができる。
【００３０】
これに加えてＤＲＭモジュール及び電子透かしを結合すれば、著作権保護の水準はいずれの既存ソリューションにも劣らない。
【００３１】
オーダサーバがオペレータにより管理され、クライアントがこのオペレータのサブスクリプションを有する場合、この信頼関係は認証及び課金を目的として行使することができる。さらに、ストリーミングサーバがコンテンツプロバイダであることを前提として、オペレータとコンテンツプロバイダが音楽のダウンロードポータルの形態等で相互に協力する場合、オペレータを信頼するユーザは、海賊版又はなりすましのコンテンツプロバイダの不正行為に対してより安全性を感じる根拠を有する。
【００３２】
当該方法及びネットワークは、実際の実施に応じて異なるレベルのクライアントの無記名性を提供できるという意味で非常に柔軟である。例えば、アクセス及びコンテンツの決済に対してアノニマスディジタルペイメント(anonymous digital payment)を使用することにより、ストリーミングサーバ、オーダサーバ、及びそれに関連する金融機関に対して全体的なアノニマスソリューションを達成することができる。逆に、ＩＤモジュール及びできれば電子透かし技術を用いることにより、ユーザに対して非常に緊密な関係を築くことができる。不法コピーを突き止めるためのより適切な手段がそのコピーを提供したユーザに提供されるため、オペレータ又はコンテンツプロバイダの視点から見ると、これは非常に魅力的である。
【００３３】
ストリーミングサーバはメディアを収容しており、データ送信の前にリクエストの最終的な検証を行うこともできるため、ストリーミングサーバは、メディアを最大限制御する。
【００３４】
リクエストが開始されたオーダサーバは、インターネットＴＶ、ビデオ／ラジオ放送等のマルチキャスティングにおいても特別な利点を提供する。
【００３５】
本発明の更なる目的及び利点は以下の詳細な説明で詳述されており、本発明の実施形態により理解される。本発明の目的及び利点は、特に特許請求の範囲に示された方法、プロセス、手段及びその組み合わせにより理解及び獲得することができる。
【００３６】
本発明の新しい特徴は特に特許請求の範囲に記載されているが、本発明の構成及び内容、並びにそれらの上記及びその他の特徴は、添付図を参照して以下に記載される非限定的な実施形態の詳細な説明を検討して完全に理解され、それらを考慮することにより本発明に対する理解が深まる。
【発明を実施するための最良の形態】
【００３７】
詳細な説明
ストリーミングメディアをオーダーしそれを受信するシステムにおいて、基本ネットワークを形成する３つのノードであるクライアント１、オーダサーバ（ＯＳ）３及びストリーミングサーバ（ＳＳ）５の相互関係を説明する（図１参照）。
【００３８】
クライアント１は、従来のマニュアル入力手段と、ディスプレイ上で及び／又はラウドスピーカによりストリーミングデータを提供するための手段とを有する携帯電話、ＰＤＡ等の、制限された処理能力及び記憶容量を有する装置とすることができる（図６のブロックダイヤグラムも参照）。当該クライアントには、特殊目的のＤＲＭの耐タンパーソフトウェア又はハードウェアモジュールを随意的に組み入れることもできる。該モジュールは、コンテンツプロバイダ、金融機関又はネットワークオペレータに関連付けられてもよい。当該クライアントは、ＳＩＭカード、スマートカード等のユーザ又はサブスクリプションデータを保存する耐タンパー装置であるＩＤモジュール（ＩＭ）を随意的に内蔵するか、又はそれに接続されてもよい。ＩＤは、コンテンツプロバイダ、ネットワークオペレータまたは銀行といった第３機関により発行されてもよい。
【００３９】
オーダサーバＯＳ ３は、クライアントからのリクエストを処理し、主にリクエストされたメディアに関する料金管理を行う（図７のブロックダイヤグラムも参照）。ストリーミングサーバ５（図８のブロックダイヤグラムも参照）は、オーダサーバ及びクライアントにより設定された条件に応じてストリーミングデータの保存及び管理を行う。
【００４０】
現実的な状況では、オーダサーバ３とストリーミングサーバＳＳ ５は統合されてもよいし、或いは、オーダサーバ及びストリーミングサーバのいずれかにおいて実施される本明細書に記載のタスクは２以上のサーバに割当てられてもよい。
【００４１】
ストリーミングメディアを取得／配給する手続は、クライアント１が、ストリーミングメディアの特定の対象物に対するリクエストをオーダサーバ３に提供することから開始される。このリクエストは、決済の手段、クレジットカード番号又は他の金銭情報及び存続期間、メディア形式といったストリーミングデータの所望の使用法等の、課金のための追加情報を含むこともできる。クライアントのリクエストに対する応答として、オーダサーバ３は、クライアント認証、課金及びリクエストされたメディア対象物の転送準備の類のタスクを実施することができる。該準備には、ユーザがサービスに対して支払うべき金額に関わるＱｏＳ（サービス品質）割当額を含めることができる。課金には、例えば、クライアント１とオーダサーバ３間のオペーレータ−加入者の既存の関係、クライアントが提示するクレジットカード番号、又は、例えば電子的な無記名式の決済システム(Anonymous payment system)を利用することができる。なお、何らかの前払い式メカニズムを使用してもよい。リクエストが認可される場合、ストリーミングサーバ５は、ＳＲＴＰ、ＷＴＬＳ等の耐性及び安全性がある標準化プロトコル、又は、本目的に適した他のプロトコルを介してメディア対象物をクライアントにストリームすることができる。メディアの利用同意書がそのように定めていれば、ユーザは、ＲＴＳＰに類するプロトコルを介して該ストリーミングを管理することができる。このユーザの例は、アイスホッケーの試合のリプレイを複数の異なる角度からスローモーションで見ることを望むスポーツアリーナにいる観客であってもよい。このような制御信号経路は、ストリームの受信対象者だけがそれを制御することができるように認証される必要がある。
【００４２】
標準化プロトコルを使用することにより既存装備を再利用することができる。これは保存用リソースが制限された小型軽量のクライアント１に欠かせない。
【００４３】
耐性のある輸送により比較的高いビット誤り率が許容され、ストリーミングデータの動作にはあまり影響しない。
【００４４】
ストリーミングデータは、そこにアクセスする無許可のエンティティからデータのコンテンツを保護できるように暗号化される。
【００４５】
認証、鍵管理及び課金に注目して、ディジタル著作権管理用の高水準なプロトコルをより詳細に説明する。上述したように、特殊目的のソフトウェア又はハードウェアが存在する場合は、その設備においてそれを利用することができる。よって、図４を参照してディジタル著作権管理用の高水準なプロトコルを説明する。プロトコルで実施される様々なステップは、クライアント１とオーダサーバ３を相互に接続する矢印、及びクライアントとストリーミングサーバ５を相互に接続する矢印で表示されている。
【００４６】
ステップ Ｎｏ．１の矢印１１：プレオーダー
クライアント１が実際に何らかのメディア対象物をオーダーする前に、メディアの種類、品質、価格、プレビュー等に関する情報を検出する等、クライアントとオーダサーバ３間の通信において何らかの行為が行われる。この情報の一部分は、ストリーミングサーバ５から取得されることも可能で、入手可能なメディア対象物のリスト、該対象物がオーダサーバ３を通じて取得可能か否かの情報、データの種類、プレビューファイルといったものである。
【００４７】
ステップ Ｎｏ．２の矢印１２：オーダー
クライアント１はオーダサーバ３と通信し、その結果何らかの特定のメディア対象物の正式なオーダー又はオーダーリクエストがクライアントからオーダサーバに対して、例えば、ＷＡＰ、ＨＴＴＰ又はＩ−ｍｏｄｅを介して送信され、該オーダーには特定の権利が付随している。オーダーリクエストの受信により、オーダープロセス、及び／又は、課金プロセス、及び／又は、後述のチケット作成プロセスで使用される、クライアント認証などのセキュリティ情報交換を含めた一連の行為が開始される。
【００４８】
ステップ Ｎｏ．３の矢印１３：決算／課金
ステップ Ｎｏ．２のリクエストは、メディア対象物、実質的にはそのコンテンツが課金される通常の場合に決算又は課金行為を開始する。クライアント１は、オーダーメッセージ又は何らかの事前取決めによりオーダーの決済方法を指定し、オーダサーバ３に課金権利を付与する。オーダサーバは、随意的にクリアリングハウス／ブローカーと接触し、ユーザの口座の残高が十分にあることを照合する等、課金リクエストの処理を行うことができる。
【００４９】
ステップ Ｎｏ．４の矢印１４：チケット配給
オーダサーバ３は、クライアント１に返戻するディジタル署名されたチケットを作成する。このようなチケットは、オーダーの受領書であり、クライアントがリクエストしたメディア対象物をストリーミングサーバ５から取得し、そのコンテンツを読み出すために必要な取決め情報を含んでいる。これは、ストリーミングサーバ及びリクエストされたメディアに関する情報、鍵及びストリーミングデータの他のパラメータ等の暗号情報、許可されたアクセス数、開始及び終了時間等のリクエストされたメディアの認可情報である利用権利及び条件であってもよい。当該チケットを受信すると、クライアント１は、チケットのコンテンツが以前に行われたオーダーと一致することを照合することができる。
【００５０】
ステップ Ｎｏ．５：チケットの発送
メディアの配給を開始するため、チケット全体又は好ましくはチケットの特殊部分がクライアント１からストリーミングサーバ５に対して送信される。そのようにせず、受信チケットから取得される何らかの不可欠情報をストリーミングサーバに送信することもできる。随意的に、クライアントは、付与された権利の特性に関する情報を後述のメディアセッション設定ステップでリクエストするメディアに追加してもよい。この情報をクライアントに暗号で結び付けるため、オーダサーバ３がチケットに付加した暗号情報を介して追加データを加えてもよい。ストリーミングサーバは、例えば、チケットがまだ有効であること、チケットが正当なオーダサーバから発行されたこと、クライアントからリクエストされた権利がチケット内に書込まれた権利と適合すること等の、チケットの正当性を照合する。
【００５１】
ステップ Ｎｏ．６：セキュリティ設定
チケットに含まれる暗号情報は、直接的、或いは、認証を拡張するため、及び／又は、セッション（ＳＲＴＰ）鍵、独立型の暗号化及び完全保護鍵等の追加暗号情報を取得するために使用することもできる。このような鍵は、鍵管理プロトコルの使用等により取得することができる。
【００５２】
ステップ Ｎｏ．７：メディアセッション設定
チケットが有効である場合は、実際のメディアストリーミングの準備が行われる。このように、メディアを提供するため、コーデックの設定、発信元及び宛先ネットワークアドレス及びポートの送信、所望の指定区域への高速転送等、特定の設定及び操作手続が必要となる。これはＲＴＳＰなどの制御プロトコルにより処理される。
【００５３】
ステップ Ｎｏ．８：ストリーミング／課金
準備を全て行った後、ストリーミングサーバ５は、オーダーに従ってクライアント１に対してメディアのストリーミングを開始する。クライアントはデータを受信し、以前に取得した鍵を用いてリアルタイムに、一般には「オンザフライ」でその暗号解読を行う。随意的に、取決めで許可されている場合は、クライアント１は、思いのままメディアフローを制御するためにＲＴＳＰ等を使用してストリーミングサーバと双方向通信することができる。容量又は時間単位でメディアの価格設定等を行って料金を追徴することができる。この料金方式は、クライアント１から何ら追加的な決済を必要とせず、その権利を消費するごとにチケットの消費を記録する。例えば、時間単位での課金の場合では、チケットは任意のメディアのセットに割り当てられた一定の合計時間を保存することができる。ストリーミングサーバ５は、使用時間を記録し、受領証をクライアントに送信することができる。同様に、容量単位での価格設定については、ストリーミングサーバは、時間の代わりにストリーミングされるデータ量を記録することができる。
【００５４】
チケットの使用が終了した場合、クライアントは、そのストリーミングの継続を希望する場合には、随意的にオーダサーバ３に再度連絡することができる。この再ネゴシエーションでは、以前に交換した情報を使用してもよいので、より高速でより軽量なトランザクションが可能で、データフローの中断を減少させることができる。その後、当該プロトコルはステップ Ｎｏ．５から開始される。
【００５５】
チケットコンテンツの例
ディジタルチケットは、オーダサーバ３、ストリーミングサーバ５及びクライアント１間の関係、公開鍵基盤（ＰＫＩ）、及び（例えばクライアントの）メディアプレーヤーのハードウェアＩＤに応じて各種情報を保存することができる。チケットは、リクエストされたメディアや許可された使用条件に関する情報を保存することができ、それらの情報は、かかる経済取引の受領書又はバウチャーとしての役割も果たす。
【００５６】
１．オーダサーバ３とクライアント１がオペレータ／加入者の関係を有する場合、１チケットは、オーダサーバに認知された、クライアント内のＩＤモジュールに保存することが可能な暗号鍵等、前記関係を明示する何らかの秘密データを使って暗号化されたＳＲＴＰ鍵等のセッション鍵を保存することができる。別のチケットは、ストリーミングサーバ５に帰属する公開鍵を使って暗号化されたセッション鍵を保存することができる。前者のチケットがクライアント用の受領書としての役割を果たすのに対し、後者のチケットは、メディアに対する最終リクエストでストリーミングサーバに示される又は渡されるトークンとしての役割を果たす。
【００５７】
２．クライアント１が公知の公開鍵を有する場合、オーダサーバ３はストリーミングサーバ５にセッション鍵の作成を任せることができ、チケットはこの情報を搬送しない場合がある。
【００５８】
いずれの場合も、チケットは、随意的に、ＩＰアドレス、ハードウェアＩＤといった、（クライアントの）再生装置のＩＤを保存することができる。チケットは、例えば、チケットの新しさを示す、又は不正な再生を予防する等のため、タイムスタンプ、対価他を保存することができる。オーダサーバ３からストリーミングサーバ５に向けて送信されたチケットは、クライアント識別子を保存することができ、それによりストリーミングサーバはメディアに透かし等を入れることができる。当該識別子は、著作権侵害の場合以外はクライアントに匿名性を提供することができ、著作権侵害の場合、オーダサーバがこの識別子に結び付くＩＤを明らかにする。
【００５９】
また、チケットは、例えばなりすましに対する保護のため、オーダーサーバに帰属する完全性保護の公開鍵を使う等して随意的にオーダサーバによりディジタル署名されてもよい。
【００６０】
チケットは、例えば以下の領域を有することができる（図５参照）。
− 一般的なパラメータのための領域３１。当該パラメータは、クライアント１とストリーミングサーバ５の両方が受信しなければならない情報、例えばＩＤ、権利情報、認証及び暗号化アルゴリズムを含むことができる。
− ストリーミングサーバの固有パラメータのための領域３２。その領域のコンテンツにはクライアントがアクセスできず、ストリーミングサーバ５がクライアント１と暗号関係を確立するのに必要な情報を含むことができる。必須部分は、オーダサーバ３により暗号化され、ストリーミングサーバにより解読される暗号鍵である。これは、ストリーミングサーバの公開鍵又はストリーミングサーバとオーダサーバ間で事前に共有された鍵を用いて行うことができる。また、同一の必須の鍵はクライアントパラメータにも含まれている（以下参照）。必須の鍵の特別な実施形態がＳＲＴＰ鍵又はＳＲＴＰ鍵を得るために使用できる鍵である。
− クライアントの固有パラメータのための領域３３。この領域は、クライアント１がストリーミングサーバ５と暗号関係を確立するのに必要な情報を含むことができる。上述のように、必須の部分は、オーダサーバ３により暗号化されクライアントにより解読される暗号鍵である。これは、クライアント公開鍵又はクライアントとオーダサーバ間で事前に共有された鍵を使用することにより行うことができる。
− 認証情報のための領域３４。この領域は、ストリーミングサーバ及びクライアント１がチケットの有効性を実証するための情報を有している。当該領域は、ストリーミングサーバ５及びクライアントの両方が照合できるオーダサーバ公開鍵を使って行われる署名を含むか、或いは、一方がストリーミングサーバにより照合可能で、他方がクライアントにより照合可能な２つの部分を含む。後者は、オーダサーバとストリーミングサーバ、及び、オーダサーバとクライアントの各々により事前に共有された鍵を用いたメッセージ認証コード(Message Authentication Code)を用いて達成することができる。
【００６１】
上記手続を用いると、メディアに対するアクセス権を、ダウンロードを行うハードウェアでなく、ユーザであるＩＤに非常に容易に結び付けることができることが分かる。これは、例えば、トランザクションに伴う携帯端末のＳＩＭカード等のＩＤモジュールを使用することにより達成することができる。或いは、クレジットカード番号が本目的を果たすことができる。無記名の電子決済を使用することにより、そのアクセスはユーザＩＤを明かさずにユーザに結付けられる。
【００６２】
不法なコピーまたは再生に対するセキュリティを更に強化するため、携帯端末の制御環境を随意的なハードウェアセキュリティモジュールにより容易に拡張することができる。このようなモジュールは、外部のディジタル装置に対するデータ送信を防止又は制御し、及び／又は、ユーザを突き止めることができるようにユーザＩＤに基づいて信号に電子透かしを付加することができる。このようなモジュールの例を説明する。
【００６３】
ＤＲＭモジュール
特殊目的の耐タンパー集積回路又は物理的に保護されたデバイスといったＤＲＭモジュールを、メディアへの不正アクセスを防止するためにクライアント１に随意的に組み込むことができる。図２のブロックダイヤグラムでは、ＳＲＴＰに基づくソリューションに対応した前記モジュール４１の機能が図示されている。
【００６４】
当該モジュールは、暗号鍵等、セキュアメモリ４３に保存される何らかの秘密データＫ１を少なくとも保存している必要があり（１）、該セキュアメモリは、ＩＭに共有の又は内蔵されるリソースであってよい。当該データは、使用権利を加入者ＩＤ又はデバイスに結び付けるために利用することができる。当該モジュールは、同様に、復号アルゴリズム又は暗号単方向機能を実行するデバイスＦ１，４５を具備し、当該デバイスＦ１は、インターフェースＡ，４６を備えるライン４４を介してセキュアメモリ４３から配給される秘密データＫ１と、モジュール４１の入力ライン４７を介して提供される暗号化されたＳＲＴＰ鍵とを入力として受入れ、ライン４９に復号化されたＳＲＴＰ鍵を出力として生成することもできる（２）。第３番目（３）として、当該モジュール４１は、同様にブロック５１で図示されたＳＲＴＰの復号化の全体的な機能性を内蔵することができ、それに対する復号ＳＲＴＰ鍵がライン４９を介して提供される。ＳＲＴＰ復号ブロック５１は、暗号化されたメディアストリームのデータをモジュールの入力部であるライン５２を介して受信し、データの復号化されたストリームをライン５２を介してモジュール４１の出力として配給する。このように、ライン４９内の５３におけるインターフェースＢを介してクリアテキストで通過するＳＲＴＰ鍵は、モジュール４１内で完全に保護される。この場合、モジュールへの入力ライン５７におけるインターフェースＣの５５は、他の目的のために当該ＳＲＴＰの実行(implementation)を再利用できるように、鍵をインターフェースＢ ５３に挿入できると有利である。そのような場合に、何者かがＤＲＭの機能性を無効にしようとすると、ブロック４５の機能Ｆ１は不正使用を防止する。
【００６５】
例えば、ＤＲＭモジュール４１を以下の通りに使用することができる。まず、ディジタルチケットがクライアント１により受信され、ストリーミングセッションが設定される（ステップＮｏ．５ないし７）
− 暗号化されたＳＲＴＰ鍵は入力ライン４７を介してＤＲＭモジュール４１に提供される。当該鍵は、該鍵とセキュアメモリ４３に保存される秘密情報Ｋ１とを使用する機能ブロックＦ１ ４５により受信されて、ライン４９に提供され、かつＢインターフェース５３上に現出する普通テキストのＳＲＴＰ鍵を生成し、ＳＲＴＰ復号ブロック５１によりアクセスされる。
− 入力される暗号化されたＳＲＴＰストリームは、ここで入力ライン５２を介してＤＲＭモジュール４１に提供され、ブロック５１により復号化される。そして、普通テキストＲＴＰパケットは出力ライン５２を介して復号化ブロックから配給される。
− ＤＲＭモジュール４１の外部でＢインタフェース５３を介して有効な鍵を摘出することはできない。しかし、普通テキストＳＲＴＰ鍵が分かっている場合、入力ライン５７のＣインターフェース５５を介して普通テキストＳＴＲＰ鍵を入力することにより、ＳＲＴＰストリームを復号化するのにもＤＲＭモジュールを使用することができる。ＳＲＴＰによる復号化及び暗号化を同じ方法で行うことができることと、普通テキストＳＲＴＰ鍵が分かっている場合に暗号化及び復号化するのにＤＲＭモジュール４１を使用することができることとに注意されたい。
【００６６】
図示されていない最も極端な場合、クライアントは、アンテナ入力及び、例えば、接続間の全てが耐タンパー方式で処理されるアナログオーディオ出力を有するワイヤレス装置とすることができる。
【００６７】
信頼管理
既存の関係及び／又は通信機関間に認証がない場合の信頼管理を提供するため、図３のブロックダイヤグラムに図示されたように、以下の随意的な「証明書」構造を使用することができる。証明書とは、特定機関又は設備のＩＤ及び／又は権利を確認する何らかのデータを意味する。
【００６８】
オーダサーバ３は、ストリーミングサーバ５が、オーダサーバが課金を行っているストリーミングメディアに対する権利を保証することを要望し、これは、権利者により発行される証明書６１を利用することにより実証される。当該証明書の所有権を、適時オーダサーバに明示することができる。また、当該証明書は、オーダープロセスにおいて動的に取得することもできる。
【００６９】
それに対して、ストリーミングサーバ５は、クライアント１が付与された権利を侵すことなくメディアを処理する正当な設備を有することと、さらに、該設備が誤動作しないこと及び／又は盗用或いは別に不正取得されたものでないことを認知することを要望する。このため、クライアントの設備は、該設備が原物であること、関連のＤＲＭモジュール４１を内蔵すること等を実証するため、該設備の製造者により発行される証明書６３又はトークンを随意的に保存することができる。オーダサーバ３がオペレータにより管理される場合、オーダサーバは、盗用、無許可又は欠陥設備の軌跡を保存する、GSM network's Equipment Identity Register (EIR) 65（"GSM System Survey", Ericsson Student Text, EN/LZT 123 3321 R3Aを参照）等のデータベースに登録されているかどうかを確認することができる。
【００７０】
さらに、ストリーミングサーバ５は、「虚偽のオーダサーバ」の攻撃からの保護を要望し、ここで、クライアント１は、そのようなことが行われることなく特定のメディア対象物の費用を支払ったとする承認を要求される。オーダサーバとストリーミングサーバ間に確立された取り決めが存在する（図３の矢印６７）場合は、上記メカニズムにより解決することができる。このような取り決めは、例えばストリーミングサーバが信頼する機関により発行されるクリアリングハウスの証明書（図番６９参照）の使用により作成することができ、該証明書は、オーダサーバが信頼された機関であるべきことを示す。また、この証明書は、オーダープロセスにおいて動的に取得することができる。
【００７１】
ここで、好ましい方法の実施例を説明する。
【００７２】
クライアント１は、ワイヤレス端末からWorld Wide Webサーフィンにより、３０分間の時間などの規制付きで使用されるロックビデオクリップの購買／視見するための申し込みを検出する。また、クライアントは、ＨＩＦＩ品質オーディオ用に多少の超過分の支払いも決定する。クライアントは所望のメディア及びその使用権を指定し、料金に同意する。オーダサーバ３は、当該情報を受信して電話又はインターネット申し込み等のクライアントとの先の契約取り決めに基づいて課金する。また、オーダサーバは、ストリーミングサーバ５とのステータスも照合し、リクエストされたメディアが指定された条件に従って配給可能であること、又はそのためにストリーミングサーバが容量を確保しているかを調べる。オーダサーバはチケットを作成し、暗号化済み及び署名済み／認証済みの該チケットをファイル名等要求データに対するリファレンス、ＳＲＴＰストリームに対するセッション暗号鍵、再生保護のためのフレッシュネストークン、有効期限（つまり３０分間）に関する情報、ＱｏＳデータ、及びクライアントとストリーミングサーバのＩＤ及びアドレスといったコンテンツと共にクライアントに送信する。該チケットからクライアント１は、データ、中でも最も重要なものとしてセッション鍵のデータを摘出し、オーダサーバの認証（オーダサーバの署名／認証タグ）と共に暗号化形式で前記データをストリーミングサーバ５に送出する。ストリーミングサーバは、チケットのコンテンツを摘出し、オーダサーバ３で作成されたクライアントのフレッシュネス及び許可を照合する。最後に、ストリーミングサーバは、クライアント宛てに暗号化されたストリームの送出を開始する。クライアント内のＤＲＭモジュール４１は、図１、２及び４で説明したようにデバイス上で再生される復号化ストリームを生成する。映像の途中でクライアントは局所的な雑音により妨害される。ＲＴＳＰを介して、クライアントは当該ストリームを少し巻き戻し、ストリーミングサーバ５から送出されたメディアストリームを該当する時点から再開する。ストリーミングサーバが正当性を照合することができるように、クライアントはチケットに制御リクエスト、又はそこから取得された情報を添付する必要がある。また、ＲＴＳＰメッセージは、クライアントにより認証されることもできるので、当事者以外がストリーミングを介して制御することも、サービスの拒絶を行うこともできない。
【００７３】
さらに、ストリーミングサーバ５は、メディアが実際に配給されるまでは課金が行われないように、オーダサーバ３によるメディアのトランザクション（取引）を確認することができる。或いは、トランザクションの前又は最中に、配給の通知がストリーミングサーバからオーダサーバに対して送信されてもよく、例えば、消費時間又は実際に配給されたデータ量に比例して柔軟に課金することができる。
【００７４】
本明細書では、本発明の特定の実施形態が図示及び説明されているが、多数の追加的な長所、変更及び変形が可能であることは当業者に明らかである。従って、広義の本発明は、本明細書で図示及び記載された詳細な説明、代表的なデバイス及び図例に限定されない。よって、特許請求の範囲及びその等価物により規定される本発明の一般的技術思想の精神又は範囲から逸脱することなく、様々な変形が可能である。よって、前記特許請求の範囲は、このような変更及び変形をすべて本発明の精神及び範囲内とすることを意図している。
【図面の簡単な説明】
【００７５】
【図１】図１は、オーダサーバからのメディアを要求するクライアントに対してストリーミングサーバからストリーミングメディアを配給する手続に必要とされる部分を有する基本ネットワークを図示した一般的なブロックダイヤグラムである。
【図２】図２は、クライアントのＤＲＭモジュール機能を図示したブロックダイヤグラムである。
【図３】図３は、図１のネットワークにおける随意的な信頼管理を図示したブロックダイヤグラムである。
【図４】図４は、ストリーミングデータを配給するときに実行されるステップを図示した情報伝達ダイヤグラムである。
【図５】図５は、ディジタルチケットの基本部分を示した概略図である。
【図６】図６は、一部分は随意的で一部分は選択的な複数の基本構成要素を示したクライアントの概略ブロックダイヤグラムである。
【図７】図７は、一部分は随意的で一部分は選択的な複数の基本構成要素を示したオーダサーバの概略ブロックダイヤグラムである。
【図８】図８は、一部分は随意的で一部分は選択的な複数の基本構成要素を示したストリーミングサーバの概略ブロックダイヤグラムである。
【技術分野】
【０００１】
本発明は、ストリーミングサーバからクライアントに対してストリーミングデータを配給する方法及びネットワークと、ストリーミングデータの配給に使用される装置及びサーバとに関するものである。
【背景技術】
【０００２】
ディジタル通信技術は、データ配布及び複製に便利な方法を提供しているが、殆どの手段は不正アクセス又は再配布に対して著作権が規制されているメディアの保護を講じていない。
【０００３】
一部の著作権所有者は自分自身の権利保護に対して強い経済的な関心を持っており、これによりディジタル著作権管理DRM(Digital Rights Management)に対する要求が高まった。一般的に、不安定なチャネル上で伝送される著作権が規制されたデータの保護には、正当なユーザ認証及びデータの暗号化といった暗号化方式が必要となる。著作権の管理には、信頼関係の確立、暗号化鍵の管理、及び課金の他、許可されるメディアの利用明細を伴う。（例としてインターネットサイトhttp://www.cselt.it/mpeg/を参照。）
【０００４】
妨害に曝されるワイヤレスネットワーク又は他の通信システムでは特殊な問題が発生している。無線放送の性質により、非常に容易に盗聴される可能性があり暗号化が求められている。しかし、この場合、秘密認証情報及び／又は暗号データは伝送中の誤りにより不正となる場合があり、それにより通信が切断されるか又は歪む可能性がある。特に秘密データは、リアルタイム又は他のストリーミングメディアを有し、そのような場合、不正データを修復又は再送する時間は殆ど或いは全くない。さらに、暗号化は、広い帯域幅を使用することとなり、携帯電話といった小型軽量クライアントのコンピュータに過負荷をかけることがある。
【０００５】
携帯電話又はいわゆる「パーソナルディジタルアシスタント」（ＰＤＡ）といった受信装置の記憶容量が非常に制限されている場合、大記憶容量が必要なＤＲＭソリューションを含むことはできない。同様の理由で、一の装置に複数の異なるＤＲＭソリューションを有することは不適切又は不可能である。したがって、ＤＲＭソリューションは、何らかの既存のセキュリティ構造をできるだけ利用すべきである。他方、このような装置における制限された環境は、ＤＲＭソリューションで活用されるべき利益も有している。第１に、容量が制限されているという制約により、ストリーミングデータ全体が保存され、後で摘出されることが防止される。第２に、任意の他形態でデバイスからディジタルコンテンツを容易に摘出できない。つまり、当該デバイスをいわゆる「耐タンパーモジュール」と考えることができるか、または簡単な手段により「耐タンパーモジュール」に変更するか、又はそれを含むものにすることが可能である。
【０００６】
既存のＤＲＭソリューションの殆どが部分的に「セキュリティ・バイ・オブスキュリティ("security by obscurity")」に基づいている。つまり、使用される方法がユーザに知らされない。これでは、ユーザの視点から見てソリューションに対する信頼を確立することは困難である。第２に、このオブスキュリティにより、攻撃を仕掛けることが明らかにより困難になっているが、それはオブスキュリティが維持されている間のみである。いずれ何者かが当該ソリューションを解析調査するか、或いは「漏洩」が存在すると、システムセキュリティが即座に危ぶまれるといった歴史が繰り返されている。それゆえ、できる限り公知のアルゴリズム及びプロトコルに基づいたソリューションが大いに役立つ。
【０００７】
従来技術
コンテンツ保護や権利管理の様々な方法が存在しているが、妨害に曝された不安定なメディア上でストリーミングデータを伝送するにはいずれも適していない。本対象に関連性を有するソリューションを列挙し、以下に簡潔に論評する。
【０００８】
共通に使用される用語及び略語は以下のものを含む。
−ＤＲＭ(Digital Rights Management)（ディジタル著作権管理）： 以下の１以上の技術を包含する一般的なフレームワーク。
−暗号法(Cryptography)： A Menezes, P. van Oorschot, and S. Vanstoneによる "Handbook of Applied Cryptography", CRC Press, 1997及びインターネットサイトhttp://www.cacr.math.uwaterloo.ca/hac/.を参照。
−電子透かし(Watermarking)： データ作成時に実際のデータにディジタルマークを上書きすることにより、該合成データをデータ作成者に結付け、マーキングを改ざんに対して耐性にするプロセス。つまり、特定のデータ「品質」を維持しつつ当該マークを完全に消去することが難しくなければならない。通常、電子透かしはソフトウェア技術である。
−複製保護(Copy protection)： 品質を保持しながら複製することが難しくなるように、及び／又は、複製者に遡ることができるように、データが保存及び配布されるプロセス。通常、完全な保護には特殊目的のハードウェアが要求される。
【０００９】
リアルタイムメディアを輸送するプロトコルを以下に説明する。
−ＲＴＰ(Real time transport Protocol)： リアルタイム及びストリーミングデータを輸送するためのＩＥＴＦが提起した規格。Schulzrinne, H., Casner, S., Frederick, R., Jacobson, V.による "RTP: A Transport Protocol for Real-Time Applications", IETF Request For Comments RFC 1889, 及びインターネットサイトhttp://www.ietf.org/rfc/rfc/1889.txt参照。
−ＳＲＴＰ(Secure RTP or The Secure Real Time Transport Protocol)： ＩＥＴＦ起案；暗号化のために余剰ヘッダを付加しない比較的軽量なエラーロバストなストリーム暗号文を用いた暗号化を包含するＲＴＰのためのセキュリティプロトコル。当該セキュリティプロトコルは、ＳＲＴＰを用いた伝送の使用帯域幅を減らし、ＩＰｓｅｃ等と比較して妨害を受けにくいものにする。インターネットサイトhttp://search/ietf.org/internet-drafts/draft-ietf-avt-srtp-00.txt参照。
−ＲＴＳＰ(Real Time Streaming Protocol)： オーディオ／ビデオ装置の「リモコン操作」と同様の方法でディジタルストリームを操作するための、ＩＥＴＦが提起した規格。インターネットサイトhttp://www.ietf.org/rfc/rfc2326.txt参照。
−ＲＯＨＣ(Robust Header Compression)： ＵＤＰ及びＲＴＰヘッダ等の圧縮のためのＩＥＴＦが提起した規格（２００１年３月５日付け）。インターネットサイトhttp://www.ietf.org/rfc/rfc3095.txt、http://www.ietf.org/rfc/rfc3096.txt、及びhttp://search.ietf.org/internet-drafts/draft-ietf-rohc-rtp-09.txt参照。圧縮とは、パケットサイズを低減し、それによりビット誤りの確率を低下させ、雑音チャネル上の輸送に適応させる。ＳＲＴＰはＲＴＰペイロードを暗号化するだけなので、ＲＯＨＣ及びＳＲＴＰが完全な互換性を有する。
【００１０】
規格化ソリューション
ＤＲＭ及びストリーミングメディアを議論する複数の規格化団体があり、中でも最も成熟した規格化の研究は、Moving Picture Experts Group（ＭＰＥＧ）の知的財産管理保護(Intellectual Property Management and Protection)(ＩＰＭＰ）である。インターネットサイトhttp://www.cselt.it/mpeg/standards/ipmp参照。ＭＰＥＧ ＩＰＭＰはＤＲＭのフレームワークを提供しているが、それ自身にＤＲＭを含むものではない；意図的に専用ソリューションに向けて開示している。
【００１１】
ＯＰＩＭＡ(Open Platform Initiative for Multimedia Access)（インターネットサイトhttp://drogo.cselt.it/leonardo/opima/参照）は、アクセス制御、コンテンツ管理及び保護ツールに関するフレームワークの規格化に取組んでいる。該規格化は、ダウンロード可能及び／又は置換可能なインターネットセキュリティ及び有料ＴＶアプリケーションに取組んでいるが、ワイヤレス環境には対応していない。
【００１２】
ＩＥＴＦ（又は、より具体的にはその調査グループのＩＲＴＦ）は、目下、ＤＲＭの研究グループを創設している（インターネットサイトhttp://www.idrm.org参照）。
【００１３】
専用ソリューション
マイクロソフト社は、Windows Media Rights Manager 7を擁する（インターネットサイトhttp://www.microsoft.com/windows/windowsmedia/en/wm7/drm.asp参照）。このソリューションでは、ユーザはいわゆるクリアリングハウスでライセンスを購入することができ、それをＣＤ、電子メール又はストリーミングサーバに保存可能な特定のメディアの再生に使用できる。当該ライセンスはユーザにではなくコンピュータに結びついている。当該ソリューションでは、保存及び処理リソースが制限されていないので特殊目的のソフトウェアをダウンロード及び再生実行することができるＰＣ市場を標的としている。
【００１４】
Verance（インターネットサイトhttp://www.verance.com/verance/technology.html参照）は、特殊なワイヤレスＤＲＭを所有すると公表しているが、当該システムは、単に電子透かしに基づいているだけのようである。そのソリューションは、ストリーミングメディアの暗号化を含んではいないようである。
【００１５】
E-vue（インターネットサイトhttp://www.e-vue.com参照）は、ＭＰＥＧ４準拠コード化及びオーサリングツールを製造している。サイトでは詳細を開示していないが、当該ネットワークソリューションは、トランスポートプロトコルに依存しておらず、より高水準で個別の暗号化を含むことを必要とする。
【００１６】
東芝による特許文献１では、安全にＭＰＥＧ４を配布するシステムが開示されている。しかし、実在のＤＲＭソリューションを提供しておらず、主にＭＰＥＧ４を暗号化し、ＲＴＰフレーム内に包含させる方法を特定している。ＭＰＥＧ４の暗号化の後、余剰の暗号ヘッダがペイロードに付加される。該暗号化はトランスポートレイヤで行われず、特殊目的のソフトウェア及び／又はハードウェアを必要とする。
【００１７】
Intertrustによる特許文献２では、ストリーミングメディアを保存可能ないわゆるセキュアコンテナ、制御情報及び該コンテナを開いて暗号鍵を摘出する装置を用いた一般的なＤＲＭソリューションが開示されている。しかし、妨害に曝された環境での使用のためのソリューションは、はっきりと示されていない。また、当該鍵がコンテナ内にあるため、ストリーミングを継続する前に当該鍵を摘出して確認しなければならず、これがリアルタイムでの要件に与える影響は多大である。
【００１８】
Audible社による特許文献３では、ストリーミングデータを再生するための再生装置を認証するためのフレームワークが開示されているが、安全な媒体を介しての輸送を前提としていないにもかかわらず、暗号化及び暗号文化に言及していない。
【特許文献１】欧州特許公報第１０４１８２３号
【特許文献２】欧州特許公報第１０６２８１２号
【特許文献３】国際特許出願公報第２０００／５２５８３号
【発明の開示】
【発明が解決しようとする課題】
【００１９】
課題
妨害に曝された環境においてリアルタイムでの要件に準拠するＤＲＭソリューションは存在していない。また、既存のソリューションは、クライアントにおける拡張用記憶装置及び／又は、特殊目的のソフトウェア及び／又はハードウェアを必要とする。既存のＤＲＭソリューションは一般的に私有であり、標準的なプロトコルを使用しておらず、それにより、クライアントにおいて複数のＤＲＭソリューションを実施する必要がある。これでは、記憶容量が不十分な場合は不可能である。さらに、使用されるアルゴリズムが非開示であり、大部分のユーザを信頼させることはできない。
【００２０】
既存のソリューションに付随する別の問題は、特定ユーザに対して発行される場合と対照的に、ＰＣ等の特定のハードウェア又は少数のハードウェアデバイス向けのディジタル著作権が発行され、メディアがＣＤにコピー可能である点である。
【００２１】
要旨
本発明の目的は、ストリーミングデータ、特に著作権により保護されたストリーミングデータの、耐性及び安全性のあるダウンロードを行う方法及び装置を提供することである。
【００２２】
本明細書に開示される方法では、既存の安全なトランスポートプロトコルが使用され、これによりＤＲＭが容易に拡張できる利点を提供する。データコンテンツの暗号化保護は既に定着しているので、基本的に、適応するＡＡＡ (Authentication, Authorization and Accounting) に類するメカニズムによるプログラムの拡張のみを必要とする。
【００２３】
当該方法及びネットワークでは、以下の構成要素を使用することができる。
−耐久性があり、軽量で、安全性のある標準化リアルタイムトランスポートプロトコル
−鍵配布システム
−課金サービス
−改ざん防止モジュール
【００２４】
一般的に、著作権により保護されたデータ等のストリーミングデータにアクセスする方法及びネットワークでは、以下の順序に限らず、次の事象を行うことができる。
−ストリーミングデータに対するクライアント又はクライアント装置からの要求又はオーダー
−クライアント認証
−課金
−ストリーミングデータの送信
【００２５】
ストリーミングメディアのアクセスで双方向に作用する部分は、一般的に、クライアント又はクライアント装置、オーダサーバ（ＯＳ）、及びストリーミングサーバ（ＳＳ）を含んでおり、該クライアントはオーダサーバにメディアをオーダーし、該オーダサーバは該メディアオーダを処理し、該ストリーミングサーバがストリーミングメディアをクライアントに配給する。
【００２６】
当該方法及びネットワークは、ストリーミング目的、リアルタイム、できれば特殊な場合の双方向性のデータ転送に適応する著作権により保護されたマテリアルを配布する単純な方法を提供する。当該方法及びネットワークに耐性のあるプロトコルを使用することにより、該方法及びネットワークは、既存のソリューションと比べてワイヤレスクライアント及び不均一な環境に十分に適している。ＳＲＴＰ、ＷＴＬＳ等のような標準化プロトコルを使用する利点は、該標準化プロトコルがディジタル著作権管理目的のみならず、様々な装置において実施することができるので、再利用により記憶容量を大幅に節約できることである。これは、携帯電話及びＰＤＡ等の低容量のクライアントデバイスには重要である。
【００２７】
提起した方法及びネットワーク並びにその構成要素、クライアントデバイスに実装可能な耐タンパーモジュールでさえ、オープンスタンダード及び公知のアルゴリズムに基づいているか、或いは基づくことができる。他のＤＲＭソリューションを評価することは、それらが秘密手続及び実施に依存する「セキュリティ・バイ・オブスキュリティ」に部分的に基づいているため困難である。所望の対象物を保護する秘密アルゴリズムは、いずれは公知となる傾向がある。例えば、ＧＳＭ暗号化アルゴリズム、ＤＶＤ暗号化アルゴリズムなど、そのようなソリューションは、一般的に暗号分野では不十分とみなされる：前記ソリューションは実施前に公の調査に対して公開されていない。この場合、現代の一般的な暗号法の全てにおいて見られるように、一度評価された手続の強度は、鍵及び鍵の管理に頼ることになる。
【００２８】
公開され大部分が標準化されたソリューションの別の利点は、自身のデータの保護及び配布のために誰でも該ソリューションを利用できることである。例えば、比較的知られていない「ガレージロックグループ」或いは独立していない映画製作会社や作家は、安全な方法で自分の著作物をより多くの対象者に単純で低コストな方法で配布することができる。そのような著作物のウェブポータルホスティング手続を想定することができる。
【００２９】
本明細書に記載された方法及びネットワークを使用する際、特殊目的の小型軽量クライアントについての別の利点は、受信機がより一般的なパーソナルコンピュータ等の大型装置である場合に比べて「ハッカー」によるストリーミングデータのアクセス及び保存が殆ど実行できないことである。アナログ出力信号を記録することはできても、高品質ディジタル信号は装置内に確実に保護されなければならない。即ち、小型軽量クライアントは、それ自体の多くの実用的な趣旨のため、耐タンパー装置とみなすことができる。ハードウェアの複製保護を迂回することが潜在的に非常に簡単である自己構築のパーソナルコンピュータ環境とは対照的に、携帯電話や他の携帯型装置の製造をコントロールすることにより、セキュリティを容易に得ることができる。実際に、製造者はその製品のセキュリティ保証を得ることができる。
【００３０】
これに加えてＤＲＭモジュール及び電子透かしを結合すれば、著作権保護の水準はいずれの既存ソリューションにも劣らない。
【００３１】
オーダサーバがオペレータにより管理され、クライアントがこのオペレータのサブスクリプションを有する場合、この信頼関係は認証及び課金を目的として行使することができる。さらに、ストリーミングサーバがコンテンツプロバイダであることを前提として、オペレータとコンテンツプロバイダが音楽のダウンロードポータルの形態等で相互に協力する場合、オペレータを信頼するユーザは、海賊版又はなりすましのコンテンツプロバイダの不正行為に対してより安全性を感じる根拠を有する。
【００３２】
当該方法及びネットワークは、実際の実施に応じて異なるレベルのクライアントの無記名性を提供できるという意味で非常に柔軟である。例えば、アクセス及びコンテンツの決済に対してアノニマスディジタルペイメント(anonymous digital payment)を使用することにより、ストリーミングサーバ、オーダサーバ、及びそれに関連する金融機関に対して全体的なアノニマスソリューションを達成することができる。逆に、ＩＤモジュール及びできれば電子透かし技術を用いることにより、ユーザに対して非常に緊密な関係を築くことができる。不法コピーを突き止めるためのより適切な手段がそのコピーを提供したユーザに提供されるため、オペレータ又はコンテンツプロバイダの視点から見ると、これは非常に魅力的である。
【００３３】
ストリーミングサーバはメディアを収容しており、データ送信の前にリクエストの最終的な検証を行うこともできるため、ストリーミングサーバは、メディアを最大限制御する。
【００３４】
リクエストが開始されたオーダサーバは、インターネットＴＶ、ビデオ／ラジオ放送等のマルチキャスティングにおいても特別な利点を提供する。
【００３５】
本発明の更なる目的及び利点は以下の詳細な説明で詳述されており、本発明の実施形態により理解される。本発明の目的及び利点は、特に特許請求の範囲に示された方法、プロセス、手段及びその組み合わせにより理解及び獲得することができる。
【００３６】
本発明の新しい特徴は特に特許請求の範囲に記載されているが、本発明の構成及び内容、並びにそれらの上記及びその他の特徴は、添付図を参照して以下に記載される非限定的な実施形態の詳細な説明を検討して完全に理解され、それらを考慮することにより本発明に対する理解が深まる。
【発明を実施するための最良の形態】
【００３７】
詳細な説明
ストリーミングメディアをオーダーしそれを受信するシステムにおいて、基本ネットワークを形成する３つのノードであるクライアント１、オーダサーバ（ＯＳ）３及びストリーミングサーバ（ＳＳ）５の相互関係を説明する（図１参照）。
【００３８】
クライアント１は、従来のマニュアル入力手段と、ディスプレイ上で及び／又はラウドスピーカによりストリーミングデータを提供するための手段とを有する携帯電話、ＰＤＡ等の、制限された処理能力及び記憶容量を有する装置とすることができる（図６のブロックダイヤグラムも参照）。当該クライアントには、特殊目的のＤＲＭの耐タンパーソフトウェア又はハードウェアモジュールを随意的に組み入れることもできる。該モジュールは、コンテンツプロバイダ、金融機関又はネットワークオペレータに関連付けられてもよい。当該クライアントは、ＳＩＭカード、スマートカード等のユーザ又はサブスクリプションデータを保存する耐タンパー装置であるＩＤモジュール（ＩＭ）を随意的に内蔵するか、又はそれに接続されてもよい。ＩＤは、コンテンツプロバイダ、ネットワークオペレータまたは銀行といった第３機関により発行されてもよい。
【００３９】
オーダサーバＯＳ ３は、クライアントからのリクエストを処理し、主にリクエストされたメディアに関する料金管理を行う（図７のブロックダイヤグラムも参照）。ストリーミングサーバ５（図８のブロックダイヤグラムも参照）は、オーダサーバ及びクライアントにより設定された条件に応じてストリーミングデータの保存及び管理を行う。
【００４０】
現実的な状況では、オーダサーバ３とストリーミングサーバＳＳ ５は統合されてもよいし、或いは、オーダサーバ及びストリーミングサーバのいずれかにおいて実施される本明細書に記載のタスクは２以上のサーバに割当てられてもよい。
【００４１】
ストリーミングメディアを取得／配給する手続は、クライアント１が、ストリーミングメディアの特定の対象物に対するリクエストをオーダサーバ３に提供することから開始される。このリクエストは、決済の手段、クレジットカード番号又は他の金銭情報及び存続期間、メディア形式といったストリーミングデータの所望の使用法等の、課金のための追加情報を含むこともできる。クライアントのリクエストに対する応答として、オーダサーバ３は、クライアント認証、課金及びリクエストされたメディア対象物の転送準備の類のタスクを実施することができる。該準備には、ユーザがサービスに対して支払うべき金額に関わるＱｏＳ（サービス品質）割当額を含めることができる。課金には、例えば、クライアント１とオーダサーバ３間のオペーレータ−加入者の既存の関係、クライアントが提示するクレジットカード番号、又は、例えば電子的な無記名式の決済システム(Anonymous payment system)を利用することができる。なお、何らかの前払い式メカニズムを使用してもよい。リクエストが認可される場合、ストリーミングサーバ５は、ＳＲＴＰ、ＷＴＬＳ等の耐性及び安全性がある標準化プロトコル、又は、本目的に適した他のプロトコルを介してメディア対象物をクライアントにストリームすることができる。メディアの利用同意書がそのように定めていれば、ユーザは、ＲＴＳＰに類するプロトコルを介して該ストリーミングを管理することができる。このユーザの例は、アイスホッケーの試合のリプレイを複数の異なる角度からスローモーションで見ることを望むスポーツアリーナにいる観客であってもよい。このような制御信号経路は、ストリームの受信対象者だけがそれを制御することができるように認証される必要がある。
【００４２】
標準化プロトコルを使用することにより既存装備を再利用することができる。これは保存用リソースが制限された小型軽量のクライアント１に欠かせない。
【００４３】
耐性のある輸送により比較的高いビット誤り率が許容され、ストリーミングデータの動作にはあまり影響しない。
【００４４】
ストリーミングデータは、そこにアクセスする無許可のエンティティからデータのコンテンツを保護できるように暗号化される。
【００４５】
認証、鍵管理及び課金に注目して、ディジタル著作権管理用の高水準なプロトコルをより詳細に説明する。上述したように、特殊目的のソフトウェア又はハードウェアが存在する場合は、その設備においてそれを利用することができる。よって、図４を参照してディジタル著作権管理用の高水準なプロトコルを説明する。プロトコルで実施される様々なステップは、クライアント１とオーダサーバ３を相互に接続する矢印、及びクライアントとストリーミングサーバ５を相互に接続する矢印で表示されている。
【００４６】
ステップ Ｎｏ．１の矢印１１：プレオーダー
クライアント１が実際に何らかのメディア対象物をオーダーする前に、メディアの種類、品質、価格、プレビュー等に関する情報を検出する等、クライアントとオーダサーバ３間の通信において何らかの行為が行われる。この情報の一部分は、ストリーミングサーバ５から取得されることも可能で、入手可能なメディア対象物のリスト、該対象物がオーダサーバ３を通じて取得可能か否かの情報、データの種類、プレビューファイルといったものである。
【００４７】
ステップ Ｎｏ．２の矢印１２：オーダー
クライアント１はオーダサーバ３と通信し、その結果何らかの特定のメディア対象物の正式なオーダー又はオーダーリクエストがクライアントからオーダサーバに対して、例えば、ＷＡＰ、ＨＴＴＰ又はＩ−ｍｏｄｅを介して送信され、該オーダーには特定の権利が付随している。オーダーリクエストの受信により、オーダープロセス、及び／又は、課金プロセス、及び／又は、後述のチケット作成プロセスで使用される、クライアント認証などのセキュリティ情報交換を含めた一連の行為が開始される。
【００４８】
ステップ Ｎｏ．３の矢印１３：決算／課金
ステップ Ｎｏ．２のリクエストは、メディア対象物、実質的にはそのコンテンツが課金される通常の場合に決算又は課金行為を開始する。クライアント１は、オーダーメッセージ又は何らかの事前取決めによりオーダーの決済方法を指定し、オーダサーバ３に課金権利を付与する。オーダサーバは、随意的にクリアリングハウス／ブローカーと接触し、ユーザの口座の残高が十分にあることを照合する等、課金リクエストの処理を行うことができる。
【００４９】
ステップ Ｎｏ．４の矢印１４：チケット配給
オーダサーバ３は、クライアント１に返戻するディジタル署名されたチケットを作成する。このようなチケットは、オーダーの受領書であり、クライアントがリクエストしたメディア対象物をストリーミングサーバ５から取得し、そのコンテンツを読み出すために必要な取決め情報を含んでいる。これは、ストリーミングサーバ及びリクエストされたメディアに関する情報、鍵及びストリーミングデータの他のパラメータ等の暗号情報、許可されたアクセス数、開始及び終了時間等のリクエストされたメディアの認可情報である利用権利及び条件であってもよい。当該チケットを受信すると、クライアント１は、チケットのコンテンツが以前に行われたオーダーと一致することを照合することができる。
【００５０】
ステップ Ｎｏ．５：チケットの発送
メディアの配給を開始するため、チケット全体又は好ましくはチケットの特殊部分がクライアント１からストリーミングサーバ５に対して送信される。そのようにせず、受信チケットから取得される何らかの不可欠情報をストリーミングサーバに送信することもできる。随意的に、クライアントは、付与された権利の特性に関する情報を後述のメディアセッション設定ステップでリクエストするメディアに追加してもよい。この情報をクライアントに暗号で結び付けるため、オーダサーバ３がチケットに付加した暗号情報を介して追加データを加えてもよい。ストリーミングサーバは、例えば、チケットがまだ有効であること、チケットが正当なオーダサーバから発行されたこと、クライアントからリクエストされた権利がチケット内に書込まれた権利と適合すること等の、チケットの正当性を照合する。
【００５１】
ステップ Ｎｏ．６：セキュリティ設定
チケットに含まれる暗号情報は、直接的、或いは、認証を拡張するため、及び／又は、セッション（ＳＲＴＰ）鍵、独立型の暗号化及び完全保護鍵等の追加暗号情報を取得するために使用することもできる。このような鍵は、鍵管理プロトコルの使用等により取得することができる。
【００５２】
ステップ Ｎｏ．７：メディアセッション設定
チケットが有効である場合は、実際のメディアストリーミングの準備が行われる。このように、メディアを提供するため、コーデックの設定、発信元及び宛先ネットワークアドレス及びポートの送信、所望の指定区域への高速転送等、特定の設定及び操作手続が必要となる。これはＲＴＳＰなどの制御プロトコルにより処理される。
【００５３】
ステップ Ｎｏ．８：ストリーミング／課金
準備を全て行った後、ストリーミングサーバ５は、オーダーに従ってクライアント１に対してメディアのストリーミングを開始する。クライアントはデータを受信し、以前に取得した鍵を用いてリアルタイムに、一般には「オンザフライ」でその暗号解読を行う。随意的に、取決めで許可されている場合は、クライアント１は、思いのままメディアフローを制御するためにＲＴＳＰ等を使用してストリーミングサーバと双方向通信することができる。容量又は時間単位でメディアの価格設定等を行って料金を追徴することができる。この料金方式は、クライアント１から何ら追加的な決済を必要とせず、その権利を消費するごとにチケットの消費を記録する。例えば、時間単位での課金の場合では、チケットは任意のメディアのセットに割り当てられた一定の合計時間を保存することができる。ストリーミングサーバ５は、使用時間を記録し、受領証をクライアントに送信することができる。同様に、容量単位での価格設定については、ストリーミングサーバは、時間の代わりにストリーミングされるデータ量を記録することができる。
【００５４】
チケットの使用が終了した場合、クライアントは、そのストリーミングの継続を希望する場合には、随意的にオーダサーバ３に再度連絡することができる。この再ネゴシエーションでは、以前に交換した情報を使用してもよいので、より高速でより軽量なトランザクションが可能で、データフローの中断を減少させることができる。その後、当該プロトコルはステップ Ｎｏ．５から開始される。
【００５５】
チケットコンテンツの例
ディジタルチケットは、オーダサーバ３、ストリーミングサーバ５及びクライアント１間の関係、公開鍵基盤（ＰＫＩ）、及び（例えばクライアントの）メディアプレーヤーのハードウェアＩＤに応じて各種情報を保存することができる。チケットは、リクエストされたメディアや許可された使用条件に関する情報を保存することができ、それらの情報は、かかる経済取引の受領書又はバウチャーとしての役割も果たす。
【００５６】
１．オーダサーバ３とクライアント１がオペレータ／加入者の関係を有する場合、１チケットは、オーダサーバに認知された、クライアント内のＩＤモジュールに保存することが可能な暗号鍵等、前記関係を明示する何らかの秘密データを使って暗号化されたＳＲＴＰ鍵等のセッション鍵を保存することができる。別のチケットは、ストリーミングサーバ５に帰属する公開鍵を使って暗号化されたセッション鍵を保存することができる。前者のチケットがクライアント用の受領書としての役割を果たすのに対し、後者のチケットは、メディアに対する最終リクエストでストリーミングサーバに示される又は渡されるトークンとしての役割を果たす。
【００５７】
２．クライアント１が公知の公開鍵を有する場合、オーダサーバ３はストリーミングサーバ５にセッション鍵の作成を任せることができ、チケットはこの情報を搬送しない場合がある。
【００５８】
いずれの場合も、チケットは、随意的に、ＩＰアドレス、ハードウェアＩＤといった、（クライアントの）再生装置のＩＤを保存することができる。チケットは、例えば、チケットの新しさを示す、又は不正な再生を予防する等のため、タイムスタンプ、対価他を保存することができる。オーダサーバ３からストリーミングサーバ５に向けて送信されたチケットは、クライアント識別子を保存することができ、それによりストリーミングサーバはメディアに透かし等を入れることができる。当該識別子は、著作権侵害の場合以外はクライアントに匿名性を提供することができ、著作権侵害の場合、オーダサーバがこの識別子に結び付くＩＤを明らかにする。
【００５９】
また、チケットは、例えばなりすましに対する保護のため、オーダーサーバに帰属する完全性保護の公開鍵を使う等して随意的にオーダサーバによりディジタル署名されてもよい。
【００６０】
チケットは、例えば以下の領域を有することができる（図５参照）。
− 一般的なパラメータのための領域３１。当該パラメータは、クライアント１とストリーミングサーバ５の両方が受信しなければならない情報、例えばＩＤ、権利情報、認証及び暗号化アルゴリズムを含むことができる。
− ストリーミングサーバの固有パラメータのための領域３２。その領域のコンテンツにはクライアントがアクセスできず、ストリーミングサーバ５がクライアント１と暗号関係を確立するのに必要な情報を含むことができる。必須部分は、オーダサーバ３により暗号化され、ストリーミングサーバにより解読される暗号鍵である。これは、ストリーミングサーバの公開鍵又はストリーミングサーバとオーダサーバ間で事前に共有された鍵を用いて行うことができる。また、同一の必須の鍵はクライアントパラメータにも含まれている（以下参照）。必須の鍵の特別な実施形態がＳＲＴＰ鍵又はＳＲＴＰ鍵を得るために使用できる鍵である。
− クライアントの固有パラメータのための領域３３。この領域は、クライアント１がストリーミングサーバ５と暗号関係を確立するのに必要な情報を含むことができる。上述のように、必須の部分は、オーダサーバ３により暗号化されクライアントにより解読される暗号鍵である。これは、クライアント公開鍵又はクライアントとオーダサーバ間で事前に共有された鍵を使用することにより行うことができる。
− 認証情報のための領域３４。この領域は、ストリーミングサーバ及びクライアント１がチケットの有効性を実証するための情報を有している。当該領域は、ストリーミングサーバ５及びクライアントの両方が照合できるオーダサーバ公開鍵を使って行われる署名を含むか、或いは、一方がストリーミングサーバにより照合可能で、他方がクライアントにより照合可能な２つの部分を含む。後者は、オーダサーバとストリーミングサーバ、及び、オーダサーバとクライアントの各々により事前に共有された鍵を用いたメッセージ認証コード(Message Authentication Code)を用いて達成することができる。
【００６１】
上記手続を用いると、メディアに対するアクセス権を、ダウンロードを行うハードウェアでなく、ユーザであるＩＤに非常に容易に結び付けることができることが分かる。これは、例えば、トランザクションに伴う携帯端末のＳＩＭカード等のＩＤモジュールを使用することにより達成することができる。或いは、クレジットカード番号が本目的を果たすことができる。無記名の電子決済を使用することにより、そのアクセスはユーザＩＤを明かさずにユーザに結付けられる。
【００６２】
不法なコピーまたは再生に対するセキュリティを更に強化するため、携帯端末の制御環境を随意的なハードウェアセキュリティモジュールにより容易に拡張することができる。このようなモジュールは、外部のディジタル装置に対するデータ送信を防止又は制御し、及び／又は、ユーザを突き止めることができるようにユーザＩＤに基づいて信号に電子透かしを付加することができる。このようなモジュールの例を説明する。
【００６３】
ＤＲＭモジュール
特殊目的の耐タンパー集積回路又は物理的に保護されたデバイスといったＤＲＭモジュールを、メディアへの不正アクセスを防止するためにクライアント１に随意的に組み込むことができる。図２のブロックダイヤグラムでは、ＳＲＴＰに基づくソリューションに対応した前記モジュール４１の機能が図示されている。
【００６４】
当該モジュールは、暗号鍵等、セキュアメモリ４３に保存される何らかの秘密データＫ１を少なくとも保存している必要があり（１）、該セキュアメモリは、ＩＭに共有の又は内蔵されるリソースであってよい。当該データは、使用権利を加入者ＩＤ又はデバイスに結び付けるために利用することができる。当該モジュールは、同様に、復号アルゴリズム又は暗号単方向機能を実行するデバイスＦ１，４５を具備し、当該デバイスＦ１は、インターフェースＡ，４６を備えるライン４４を介してセキュアメモリ４３から配給される秘密データＫ１と、モジュール４１の入力ライン４７を介して提供される暗号化されたＳＲＴＰ鍵とを入力として受入れ、ライン４９に復号化されたＳＲＴＰ鍵を出力として生成することもできる（２）。第３番目（３）として、当該モジュール４１は、同様にブロック５１で図示されたＳＲＴＰの復号化の全体的な機能性を内蔵することができ、それに対する復号ＳＲＴＰ鍵がライン４９を介して提供される。ＳＲＴＰ復号ブロック５１は、暗号化されたメディアストリームのデータをモジュールの入力部であるライン５２を介して受信し、データの復号化されたストリームをライン５２を介してモジュール４１の出力として配給する。このように、ライン４９内の５３におけるインターフェースＢを介してクリアテキストで通過するＳＲＴＰ鍵は、モジュール４１内で完全に保護される。この場合、モジュールへの入力ライン５７におけるインターフェースＣの５５は、他の目的のために当該ＳＲＴＰの実行(implementation)を再利用できるように、鍵をインターフェースＢ ５３に挿入できると有利である。そのような場合に、何者かがＤＲＭの機能性を無効にしようとすると、ブロック４５の機能Ｆ１は不正使用を防止する。
【００６５】
例えば、ＤＲＭモジュール４１を以下の通りに使用することができる。まず、ディジタルチケットがクライアント１により受信され、ストリーミングセッションが設定される（ステップＮｏ．５ないし７）
− 暗号化されたＳＲＴＰ鍵は入力ライン４７を介してＤＲＭモジュール４１に提供される。当該鍵は、該鍵とセキュアメモリ４３に保存される秘密情報Ｋ１とを使用する機能ブロックＦ１ ４５により受信されて、ライン４９に提供され、かつＢインターフェース５３上に現出する普通テキストのＳＲＴＰ鍵を生成し、ＳＲＴＰ復号ブロック５１によりアクセスされる。
− 入力される暗号化されたＳＲＴＰストリームは、ここで入力ライン５２を介してＤＲＭモジュール４１に提供され、ブロック５１により復号化される。そして、普通テキストＲＴＰパケットは出力ライン５２を介して復号化ブロックから配給される。
− ＤＲＭモジュール４１の外部でＢインタフェース５３を介して有効な鍵を摘出することはできない。しかし、普通テキストＳＲＴＰ鍵が分かっている場合、入力ライン５７のＣインターフェース５５を介して普通テキストＳＴＲＰ鍵を入力することにより、ＳＲＴＰストリームを復号化するのにもＤＲＭモジュールを使用することができる。ＳＲＴＰによる復号化及び暗号化を同じ方法で行うことができることと、普通テキストＳＲＴＰ鍵が分かっている場合に暗号化及び復号化するのにＤＲＭモジュール４１を使用することができることとに注意されたい。
【００６６】
図示されていない最も極端な場合、クライアントは、アンテナ入力及び、例えば、接続間の全てが耐タンパー方式で処理されるアナログオーディオ出力を有するワイヤレス装置とすることができる。
【００６７】
信頼管理
既存の関係及び／又は通信機関間に認証がない場合の信頼管理を提供するため、図３のブロックダイヤグラムに図示されたように、以下の随意的な「証明書」構造を使用することができる。証明書とは、特定機関又は設備のＩＤ及び／又は権利を確認する何らかのデータを意味する。
【００６８】
オーダサーバ３は、ストリーミングサーバ５が、オーダサーバが課金を行っているストリーミングメディアに対する権利を保証することを要望し、これは、権利者により発行される証明書６１を利用することにより実証される。当該証明書の所有権を、適時オーダサーバに明示することができる。また、当該証明書は、オーダープロセスにおいて動的に取得することもできる。
【００６９】
それに対して、ストリーミングサーバ５は、クライアント１が付与された権利を侵すことなくメディアを処理する正当な設備を有することと、さらに、該設備が誤動作しないこと及び／又は盗用或いは別に不正取得されたものでないことを認知することを要望する。このため、クライアントの設備は、該設備が原物であること、関連のＤＲＭモジュール４１を内蔵すること等を実証するため、該設備の製造者により発行される証明書６３又はトークンを随意的に保存することができる。オーダサーバ３がオペレータにより管理される場合、オーダサーバは、盗用、無許可又は欠陥設備の軌跡を保存する、GSM network's Equipment Identity Register (EIR) 65（"GSM System Survey", Ericsson Student Text, EN/LZT 123 3321 R3Aを参照）等のデータベースに登録されているかどうかを確認することができる。
【００７０】
さらに、ストリーミングサーバ５は、「虚偽のオーダサーバ」の攻撃からの保護を要望し、ここで、クライアント１は、そのようなことが行われることなく特定のメディア対象物の費用を支払ったとする承認を要求される。オーダサーバとストリーミングサーバ間に確立された取り決めが存在する（図３の矢印６７）場合は、上記メカニズムにより解決することができる。このような取り決めは、例えばストリーミングサーバが信頼する機関により発行されるクリアリングハウスの証明書（図番６９参照）の使用により作成することができ、該証明書は、オーダサーバが信頼された機関であるべきことを示す。また、この証明書は、オーダープロセスにおいて動的に取得することができる。
【００７１】
ここで、好ましい方法の実施例を説明する。
【００７２】
クライアント１は、ワイヤレス端末からWorld Wide Webサーフィンにより、３０分間の時間などの規制付きで使用されるロックビデオクリップの購買／視見するための申し込みを検出する。また、クライアントは、ＨＩＦＩ品質オーディオ用に多少の超過分の支払いも決定する。クライアントは所望のメディア及びその使用権を指定し、料金に同意する。オーダサーバ３は、当該情報を受信して電話又はインターネット申し込み等のクライアントとの先の契約取り決めに基づいて課金する。また、オーダサーバは、ストリーミングサーバ５とのステータスも照合し、リクエストされたメディアが指定された条件に従って配給可能であること、又はそのためにストリーミングサーバが容量を確保しているかを調べる。オーダサーバはチケットを作成し、暗号化済み及び署名済み／認証済みの該チケットをファイル名等要求データに対するリファレンス、ＳＲＴＰストリームに対するセッション暗号鍵、再生保護のためのフレッシュネストークン、有効期限（つまり３０分間）に関する情報、ＱｏＳデータ、及びクライアントとストリーミングサーバのＩＤ及びアドレスといったコンテンツと共にクライアントに送信する。該チケットからクライアント１は、データ、中でも最も重要なものとしてセッション鍵のデータを摘出し、オーダサーバの認証（オーダサーバの署名／認証タグ）と共に暗号化形式で前記データをストリーミングサーバ５に送出する。ストリーミングサーバは、チケットのコンテンツを摘出し、オーダサーバ３で作成されたクライアントのフレッシュネス及び許可を照合する。最後に、ストリーミングサーバは、クライアント宛てに暗号化されたストリームの送出を開始する。クライアント内のＤＲＭモジュール４１は、図１、２及び４で説明したようにデバイス上で再生される復号化ストリームを生成する。映像の途中でクライアントは局所的な雑音により妨害される。ＲＴＳＰを介して、クライアントは当該ストリームを少し巻き戻し、ストリーミングサーバ５から送出されたメディアストリームを該当する時点から再開する。ストリーミングサーバが正当性を照合することができるように、クライアントはチケットに制御リクエスト、又はそこから取得された情報を添付する必要がある。また、ＲＴＳＰメッセージは、クライアントにより認証されることもできるので、当事者以外がストリーミングを介して制御することも、サービスの拒絶を行うこともできない。
【００７３】
さらに、ストリーミングサーバ５は、メディアが実際に配給されるまでは課金が行われないように、オーダサーバ３によるメディアのトランザクション（取引）を確認することができる。或いは、トランザクションの前又は最中に、配給の通知がストリーミングサーバからオーダサーバに対して送信されてもよく、例えば、消費時間又は実際に配給されたデータ量に比例して柔軟に課金することができる。
【００７４】
本明細書では、本発明の特定の実施形態が図示及び説明されているが、多数の追加的な長所、変更及び変形が可能であることは当業者に明らかである。従って、広義の本発明は、本明細書で図示及び記載された詳細な説明、代表的なデバイス及び図例に限定されない。よって、特許請求の範囲及びその等価物により規定される本発明の一般的技術思想の精神又は範囲から逸脱することなく、様々な変形が可能である。よって、前記特許請求の範囲は、このような変更及び変形をすべて本発明の精神及び範囲内とすることを意図している。
【図面の簡単な説明】
【００７５】
【図１】図１は、オーダサーバからのメディアを要求するクライアントに対してストリーミングサーバからストリーミングメディアを配給する手続に必要とされる部分を有する基本ネットワークを図示した一般的なブロックダイヤグラムである。
【図２】図２は、クライアントのＤＲＭモジュール機能を図示したブロックダイヤグラムである。
【図３】図３は、図１のネットワークにおける随意的な信頼管理を図示したブロックダイヤグラムである。
【図４】図４は、ストリーミングデータを配給するときに実行されるステップを図示した情報伝達ダイヤグラムである。
【図５】図５は、ディジタルチケットの基本部分を示した概略図である。
【図６】図６は、一部分は随意的で一部分は選択的な複数の基本構成要素を示したクライアントの概略ブロックダイヤグラムである。
【図７】図７は、一部分は随意的で一部分は選択的な複数の基本構成要素を示したオーダサーバの概略ブロックダイヤグラムである。
【図８】図８は、一部分は随意的で一部分は選択的な複数の基本構成要素を示したストリーミングサーバの概略ブロックダイヤグラムである。
【特許請求の範囲】
【請求項１】
ＩＤを有するクライアントがストリーミングデータを安全にダウンロードする方法であって、
クライアントがオーダサーバからのストリーミングデータの配給をオーダーするステップと、
オーダサーバが前記オーダーを受け、クライアントを認証し、セッション鍵を有する１つのディジタルチケットと、ストリーミングサーバに属するパブリック鍵によって暗号化されたセッション鍵を少なくとも含む他のチケットをクライアントに送信し、
クライアントがストリーミングサーバに、ストリーミングデータの最終要求において前記他のチケットを送信し、
ストリーミングサーバが前記他のチケットと暗号化されたセッション鍵を有する最終要求を受け、復号された前記セッション鍵を用いてストリーミングデータを暗号化し、該暗号化されたストリーミングデータをクライアントに、耐性および安全性のあるトランスポートプロトコルで送信し、
クライアントが暗号化されたストリーミングデータを受信し、それを前記受け取った１つのデジタルチケットに含まれていたセッション鍵で復号化する、
一連のステップを特徴とする方法。
【請求項２】
クライアントがストリーミングデータの配給をオーダーするステップにおいて、クライアントからサーバに対して課金情報を送信することを含む請求項１に記載の方法。
【請求項３】
前記耐性及び安全性のあるトランスポートプロトコルが標準リアルタイムプロトコルを含むことを特徴とする請求項１に記載の方法。
【請求項４】
伝送中に発生する誤りに対する感度が低いように、耐性及び安全性のあるトランスポートプロトコルを選択する追加ステップを含むことを特徴とする請求項１に記載の方法。
【請求項５】
前記耐性および安全性のあるトランスポートプロトコルが安全性のあるリアルタイムプロトコルを含むことを特徴とする請求項１に記載の方法。
【請求項６】
前記耐性および安全性のあるトランスポートプロトコルがロバストヘッダ圧縮プロトコルを含むことを特徴とする請求項１に記載の方法。
【請求項７】
耐タンパーＩＤモジュールにクライアントＩＤを保存する追加ステップを含むことを特徴とする請求項１に記載の方法。
【請求項８】
耐タンパーＩＤモジュールにユーザの使用権利も保存する追加ステップを含むことを特徴とする請求項１に記載の方法。
【請求項９】
前記送信ステップにおいて、送信がワイヤレスで行われることを特徴とする請求項１に記載の方法。
【請求項１０】
ＩＤをユーザと対応させる追加ステップを含むことを特徴とする請求項１に記載の方法。
【請求項１１】
ＩＤをユーザのＩＰアドレスと対応させる追加ステップを含むことを特徴とする請求項１に記載の方法。
【請求項１２】
ストリーミングサーバとオーダーサーバとに通信を行って、ストリーミングサーバからストリーミングデータを安全に取得するＩＤを有するクライアントデバイスであって、
ストリーミングデータの対象物を配給するために、オーダーを準備してオーダサーバに送信するオーダー手段と、
オーダサーバから、セッション鍵を含む１つのデジタルチケットと、ストリーミングサーバに属する公開鍵によって暗号化されたセッション鍵を少なくとも含む他のデジタルチケットを受信するチケット受信手段と、
ストリーミングデータの対象物をクライアントデバイスにダウンロードさせるリクエストに、前記他のデジタルチケットを含めてストリーミングサーバに送信するチケット送出手段と、
対象物のストリーミングデータを受信し、前記１つのデジタルチケットに含まれていたセッション鍵を用いて復号化するストリーミングデータ受信手段と
を有することを特徴とするクライアントデバイス。
【請求項１３】
ＩＤを有するクライアントデバイスに、ストリーミングサーバからストリーミングデータを安全に取得させるためにクライアントデバイスと通信するオーダサーバであって、
クライアントデバイスからストリーミングデータの対象物のオーダーを受信するオーダー受信手段と、
セッションキーを含む１つのデジタルチケットと、ストリーミングサーバに属する公開鍵を用いて暗号化されたセッション鍵を少なくとも含む他のデジタルチケットを作成し、該ディジタルチケットをクライアントデバイスに送信するチケット手段と、
を有することを特徴とするオーダサーバ。
【請求項１４】
ストリーミングデータのオーダー対象物についてクライアントデバイス又はそれに対応するユーザに課金するために、課金手段がオーダー受信手段に接続されていることを特徴とする請求項１３に記載のオーダサーバ。
【請求項１】
ＩＤを有するクライアントがストリーミングデータを安全にダウンロードする方法であって、
クライアントがオーダサーバからのストリーミングデータの配給をオーダーするステップと、
オーダサーバが前記オーダーを受け、クライアントを認証し、セッション鍵を有する１つのディジタルチケットと、ストリーミングサーバに属するパブリック鍵によって暗号化されたセッション鍵を少なくとも含む他のチケットをクライアントに送信し、
クライアントがストリーミングサーバに、ストリーミングデータの最終要求において前記他のチケットを送信し、
ストリーミングサーバが前記他のチケットと暗号化されたセッション鍵を有する最終要求を受け、復号された前記セッション鍵を用いてストリーミングデータを暗号化し、該暗号化されたストリーミングデータをクライアントに、耐性および安全性のあるトランスポートプロトコルで送信し、
クライアントが暗号化されたストリーミングデータを受信し、それを前記受け取った１つのデジタルチケットに含まれていたセッション鍵で復号化する、
一連のステップを特徴とする方法。
【請求項２】
クライアントがストリーミングデータの配給をオーダーするステップにおいて、クライアントからサーバに対して課金情報を送信することを含む請求項１に記載の方法。
【請求項３】
前記耐性及び安全性のあるトランスポートプロトコルが標準リアルタイムプロトコルを含むことを特徴とする請求項１に記載の方法。
【請求項４】
伝送中に発生する誤りに対する感度が低いように、耐性及び安全性のあるトランスポートプロトコルを選択する追加ステップを含むことを特徴とする請求項１に記載の方法。
【請求項５】
前記耐性および安全性のあるトランスポートプロトコルが安全性のあるリアルタイムプロトコルを含むことを特徴とする請求項１に記載の方法。
【請求項６】
前記耐性および安全性のあるトランスポートプロトコルがロバストヘッダ圧縮プロトコルを含むことを特徴とする請求項１に記載の方法。
【請求項７】
耐タンパーＩＤモジュールにクライアントＩＤを保存する追加ステップを含むことを特徴とする請求項１に記載の方法。
【請求項８】
耐タンパーＩＤモジュールにユーザの使用権利も保存する追加ステップを含むことを特徴とする請求項１に記載の方法。
【請求項９】
前記送信ステップにおいて、送信がワイヤレスで行われることを特徴とする請求項１に記載の方法。
【請求項１０】
ＩＤをユーザと対応させる追加ステップを含むことを特徴とする請求項１に記載の方法。
【請求項１１】
ＩＤをユーザのＩＰアドレスと対応させる追加ステップを含むことを特徴とする請求項１に記載の方法。
【請求項１２】
ストリーミングサーバとオーダーサーバとに通信を行って、ストリーミングサーバからストリーミングデータを安全に取得するＩＤを有するクライアントデバイスであって、
ストリーミングデータの対象物を配給するために、オーダーを準備してオーダサーバに送信するオーダー手段と、
オーダサーバから、セッション鍵を含む１つのデジタルチケットと、ストリーミングサーバに属する公開鍵によって暗号化されたセッション鍵を少なくとも含む他のデジタルチケットを受信するチケット受信手段と、
ストリーミングデータの対象物をクライアントデバイスにダウンロードさせるリクエストに、前記他のデジタルチケットを含めてストリーミングサーバに送信するチケット送出手段と、
対象物のストリーミングデータを受信し、前記１つのデジタルチケットに含まれていたセッション鍵を用いて復号化するストリーミングデータ受信手段と
を有することを特徴とするクライアントデバイス。
【請求項１３】
ＩＤを有するクライアントデバイスに、ストリーミングサーバからストリーミングデータを安全に取得させるためにクライアントデバイスと通信するオーダサーバであって、
クライアントデバイスからストリーミングデータの対象物のオーダーを受信するオーダー受信手段と、
セッションキーを含む１つのデジタルチケットと、ストリーミングサーバに属する公開鍵を用いて暗号化されたセッション鍵を少なくとも含む他のデジタルチケットを作成し、該ディジタルチケットをクライアントデバイスに送信するチケット手段と、
を有することを特徴とするオーダサーバ。
【請求項１４】
ストリーミングデータのオーダー対象物についてクライアントデバイス又はそれに対応するユーザに課金するために、課金手段がオーダー受信手段に接続されていることを特徴とする請求項１３に記載のオーダサーバ。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【公開番号】特開２００９−３７６００（Ｐ２００９−３７６００Ａ）
【公開日】平成２１年２月１９日（２００９．２．１９）
【国際特許分類】
【外国語出願】
【出願番号】特願２００８−１６２０１３（Ｐ２００８−１６２０１３）
【出願日】平成２０年６月２０日（２００８．６．２０）
【分割の表示】特願２００２−５８２５８６（Ｐ２００２−５８２５８６）の分割
【原出願日】平成１４年４月１０日（２００２．４．１０）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ｉ−ｍｏｄｅ
【出願人】（５９８０３６３００）テレフオンアクチーボラゲット エル エム エリクソン（パブル） (2,266)
【Ｆターム（参考）】
【公開日】平成２１年２月１９日（２００９．２．１９）
【国際特許分類】
【出願番号】特願２００８−１６２０１３（Ｐ２００８−１６２０１３）
【出願日】平成２０年６月２０日（２００８．６．２０）
【分割の表示】特願２００２−５８２５８６（Ｐ２００２−５８２５８６）の分割
【原出願日】平成１４年４月１０日（２００２．４．１０）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ｉ−ｍｏｄｅ
【出願人】（５９８０３６３００）テレフオンアクチーボラゲット エル エム エリクソン（パブル） (2,266)
【Ｆターム（参考）】
[ Back to top ]