(57)【要約】【課題】望ましい程度のフレキシブルなセキュリティを提供しながら、レンダリング可能なコンテンツを処理すること。【解決手段】本発明は、レンダリング・デバイスに保護されていないコンテンツが届いた後の不正アクセス又は複製を防止し、一般的なメディア・ソースに対して、実質的にあらゆる種類のマルチメディア・コンテンツを適切に構成されたレンダリング・デバイスに送信可能なアーキテクチャを備える。コンテンツの保護およびレンダリングは、ローカル／ネットワーク上で実施可能である。これは、第三者がコンポーネントを作成し、それを安全にかつ柔軟に処理連鎖に組み込みことを可能とする。コンポーネントの信頼性検証は、コンポーネントの連鎖を辿る１つ又は複数のオーセンティケータを生成して行う。多種多様のレンダリング環境、コンテンツ・タイプ、ＤＲＭ手法にわたって、コンテンツ保護に活用できる標準プラットフォームを提供する。【選択図】図３
2010114919.tif 000002
【特許請求の範囲】
【請求項１】
方法であって、
デジタル・データを処理しレンダリングするコンポーネントであって、認証可能なインターフェースおよび認証プロキシ・インターフェースのうち１つまたは複数をそれぞれがサポートするコンポーネント、についての１つまたは複数の経路を確立すること、
前記１つまたは複数の経路にある個々のコンポーネントを認証する第１のオーセンティケータを作成すること、
１つまたは複数の各コンポーネント上で１つまたは複数の認証可能なインターフェースに対して、前記第１のオーセンティケータを含むコールを実行し、コールされた前記コンポーネントからのダウンストリームにあるコンポーネントを確認すること、
１つまたは複数のダウンストリーム・コンポーネントを前記第１のオーセンティケータを使用して認証すること、
認証プロキシ・インターフェースおよび認証インターフェースをサポートするコンポーネントに関して、別々のオーセンティケータを作成すること、および
前記第１のオーセンティケータと前記別々のオーセンティケータのうちの１つまたは複数との間で暗号化されたチャネルを確立すること、および
前記別々のオーセンティケータを使用して追加コンポーネントを認証すること
を備えることを特徴とする方法。
【請求項２】
前記１つまたは複数の経路は、オーディオ経路とビデオ経路を含むことを特徴とする請求項１に記載の方法。
【請求項３】
さらに、暗号化されていないデータを処理するコンポーネント間に暗号化されたチャネル・サービスを、前記オーセンティケータを使用して実現することを備えることを特徴とする請求項１に記載の方法。
【請求項４】
さらに、暗号化されていないデータを処理するコンポーネント間に暗号化されたチャネル・サービスを、前記オーセンティケータを使用して実現し、前記チャネルを使用してデータの暗号化および復号化を行うコンポーネントの間でセッション鍵の配列のネゴシエーションを行うことを備えることを特徴とする請求項１に記載の方法。
【請求項５】
さらに、前記認証プロキシ・インターフェースのうち１つまたは複数を使用して、認証されていないコンポーネントも共によりリンクされている認証済みコンポーネント同士の間で認証を行うことを備えることを特徴とする請求項１に記載の方法。
【請求項６】
前記認証可能インターフェースは、ダウンストリーム・コンポーネントの認証インターフェースのリスト、ダウンストリーム・コンポーネントの認証プロキシ・インターフェースのリスト、署名を検証すべき従属コンポーネントのリスト、およびオーセンティケータの前記連鎖に対する鍵セッション番号、のうち１つまたは複数を返すことを特徴とする請求項１に記載の方法。
【請求項７】
さらに、コンポーネントが前記暗号化されたチャネル上で情報を渡すための方法を、前記オーセンティケータに使用して実現することを特徴とする請求項１に記載の方法。
【請求項８】
さらに、必要ならば、前記デジタル・データに関連付けられたデジタル権利管理データを変換すること、および前記レンダリング・プロセス実行時に前記変換されたデジタル権利管理データを使用して前記デジタル・データを保護することを備えることを特徴とする請求項１に記載の方法。
【請求項９】
請求項１の方法を実装するようにプログラムされていることを特徴とするコンピューティング・デバイス。
【請求項１０】
コンピュータ読み取り可能命令を有する１つまたは複数のコンピュータ読み取り可能記憶媒体であって、１つまたは複数のプロセッサによって命令が実行されると、
デジタル・データを処理しレンダリングするコンポーネントであって、認証可能なインターフェースおよび認証プロキシ・インターフェースのうちの１つまたは複数をそれぞれがサポートするコンポーネントについての、デジタル・ビデオ・データを処理するビデオ経路と、デジタル・オーディオ・データを処理するオーディオ経路を備える複数の経路を確立すること、
必要ならば、前記デジタル・データと関連するデジタル権利管理データを変換し、前記デジタル・データの処理中に前記変換されたデジタル権利管理データを使用して前記デジタル・データを保護すること、
第１のオーセンティケータを作成して前記経路の１つまたは複数の個々のコンポーネントを認証すること、
前記第１のオーセンティケータを使用し、１つまたは複数の各コンポーネント上で１つまたは複数の認証可能なインターフェースを呼び出して、呼び出された前記コンポーネントからのダウンストリームにあるコンポーネントを確認すること、
１つまたは複数のダウンストリーム・コンポーネントを前記第１のオーセンティケータを使用して認証すること、
認証プロキシ・インターフェースおよび認証インターフェースをサポートするコンポーネントに関して、別々のオーセンティケータを作成すること、
前記第１のオーセンティケータと前記別々のオーセンティケータのうちの１つまたは複数との間に暗号化されたチャネルを確立し、前記チャネルを使用して、データの暗号化および復号化で使用するコンポーネントに暗号／復号鍵を送ること、および
前記別々のオーセンティケータを使用して追加コンポーネントを認証すること
を前記１つまたは複数のプロセッサにさせることを特徴とするコンピュータ読み取り可能記憶媒体。
【請求項１１】
前記認証可能インターフェースは、ダウンストリーム・コンポーネントの認証インターフェースのリスト、ダウンストリーム・コンポーネントの認証プロキシ・インターフェースのリスト、署名を検証すべき従属コンポーネントのリスト、およびオーセンティケータの前記連鎖に対する鍵セッション番号、のうち１つまたは複数を返すことを特徴とする請求項１０に記載の１つまたは複数のコンピュータ読み取り可能記憶媒体。
【請求項１２】
請求項１０に記載の前記コンピュータ読み取り可能記憶媒体を実装することを特徴とするコンピューティング・デバイス。
【請求項１３】
コンピューティング・デバイスであって、
メモリと、
１つまたは複数のプロセッサと、
前記メモリ内の命令群であって、前記１つまたは複数のプロセッサにより実行されると、
デジタル・データを処理しレンダリングするコンポーネントで、それぞれが、
ダウンストリーム・コンポーネントの認証インターフェースのリスト、
ダウンストリーム・コンポーネントの認証プロキシ・インターフェースのリスト、
署名を検証する依存コンポーネントのリスト、および
認証の連鎖の鍵セッション番号
のうちの１つまたは複数を返す認証可能なインターフェースと、
認証プロキシ・インターフェースと
のうちの１つまたは複数をサポートするコンポーネントについての、デジタル・ビデオ・データを処理するビデオ経路と、デジタル・オーディオ・データを処理するオーディオ経路を備える複数の経路を確立すること、
必要ならば、前記デジタル・データに関連付けられたデジタル権利管理データを変換し、前記デジタル・データの処理中に前記変換されたデジタル権利管理データを使用して前記デジタル・データを保護すること、
第１のオーセンティケータを作成して前記経路の１つまたは複数の個々のコンポーネントを認証すること、
前記第１のオーセンティケータを使用し、１つまたは複数の各コンポーネント上で１つまたは複数の認証可能なインターフェースを呼び出して、呼び出された前記コンポーネントからのダウンストリームにあるコンポーネントを確認すること、
１つまたは複数のダウンストリーム・コンポーネントを前記第１のオーセンティケータを使用して認証すること、
認証プロキシ・インターフェースおよび認証インターフェースをサポートするコンポーネントに関して、別々のオーセンティケータを作成すること、
前記第１のオーセンティケータと前記別々のオーセンティケータのうちの１つまたは複数との間に暗号化されたチャネルを確立し、前記チャネルを使用して、データの暗号化および復号化で使用する前記コンポーネントに暗号／復号鍵を送ること、および
前記別々のオーセンティケータを使用して追加コンポーネントを認証すること
を前記１つまたは複数のプロセッサにさせる命令群と
を備えることを特徴とするコンピューティング・デバイス。
【請求項１４】
方法であって、
デジタル・データを処理しレンダリングするコンポーネントについての１つまたは複数の経路を確立すること、
前記１つまたは複数の経路により処理される暗号化されたデータで、前記暗号化されたデータを処理する方法を定義したライセンスが適用されるデータを受信すること、
前記１つまたは複数の経路に沿ってコンポーネントを認証する複数のオーセンティケータを作成することであって、複数のオーセンティケータのうちの少なくとも１つをリモート・デバイス上のデバイス境界をまたいで作成すること、
前記複数のオーセンティケータの間に１つの安全な通信チャネルを用意すること、
前記１つまたは複数の経路の個々のコンポーネントに、前記オーセンティケータを含むクエリを実行して、前記クエリが実行されたコンポーネントのデータの渡し先コンポーネントを確認すること、
前記クエリが実行されたコンポーネントと前記クエリが実行されたコンポーネントがデータを渡す先のコンポーネントを、前記オーセンティケータを使用して認証することを試みること、および
データの暗号化および復号化に使用する前記コンポーネントについての前記１つまたは複数の経路にある複数のコンポーネントで暗号／復号鍵を確立すること
を備えることを特徴とする方法。
【請求項１５】
前記ライセンスは、個々のコンポーネントが危ういかどうかを確認するために使用できる１つまたは複数の取り消しリストを指定することを特徴とする請求項１４に記載の方法。
【請求項１６】
前記ライセンスは、前記暗号化されたデータを保護するために使用されるセキュリティのレベルを指定することを特徴とする請求項１４に記載の方法。
【請求項１７】
前記暗号／復号鍵を確定することは、前記オーセンティケータ間の前記安全な通信チャネルを使用して前記暗号／復号鍵を確定することを備えること特徴とする請求項１４に記載の方法。
【請求項１８】
前記暗号／復号鍵を確定することは、セッション・ベースの鍵を確定することを備えることを特徴とする請求項１４に記載の方法。
【請求項１９】
さらに、前記複数のオーセンティケータを使用して前記コンポーネントの再認証を繰り返し実行することを備えることを特徴とする請求項１４に記載の方法。
【請求項２０】
前記複数のオーセンティケータを作成することは、ユーザ・モードのコンポーネントを認証する少なくとも１つのユーザ・モード・オーセンティケータと、カーネル・モードのコンポーネントを認証する少なくとも１つのカーネル・モード・オーセンティケータとを作成することを備えることを特徴とする請求項１４に記載の方法。
【請求項２１】
さらに、必要ならば、前記暗号化されたデータに関連付けられたＤＲＭデータを変換すること、および前記レンダリング・プロセス期間中に前記変換されたＤＲＭデータを使用して前記暗号化データを保護することを備えることを特徴とする請求項１４に記載の方法。
【請求項２２】
コンピュータ読み取り可能命令を有する１つまたは複数のコンピュータ読み取り可能記憶媒体であって、１つまたは複数のプロセッサが前記命令を実行したときに、前記プロセッサが請求項１４に記載の方法を実行することを特徴とするコンピュータ読み取り可能記憶媒体。
【請求項２３】
請求項１４の方法を実行するように構成されていることを特徴とする少なくとも２つのコンピューティング・デバイス。
【請求項２４】
システムであって、
ユーザ向けにレンダリングされる保護されているコンテンツを処理するコンポーネントの処理連鎖内で使用されるように構成されているコンポーネントで、認証可能なインターフェースおよび認証プロキシ・インターフェースの１つまたは複数をサポートする１つまたは複数のコンポーネント
を備え、
前記認証可能インターフェースは、オーセンティケータにより呼び出し可能であって、前記オーセンティケータに対して、
ダウンストリーム・コンポーネントの認証インターフェースのリスト、
ダウンストリーム・コンポーネントの認証プロキシ・インターフェースのリスト、および
署名を検証する従属コンポーネントのリスト
を返し、
前記認証プロキシ・インターフェースは、前記オーセンティケータとの間でデータを読み書きする方法を提供することを特徴とするシステム。
【請求項２５】
前記認証可能インターフェースは、オーセンティケータの前記連鎖に、鍵セッション番号を返すことを特徴とする請求項２４に記載のシステム。
【請求項２６】
少なくとも１つのコンポーネントは、レンダラを備えることを特徴とする請求項２５に記載のシステム。
【請求項２７】
少なくとも１つのコンポーネントは、前記両方のインターフェースをサポートするレンダラを備えることを特徴とする請求項２４に記載のシステム。
【請求項２８】
少なくとも１つのコンポーネントは、デマルチプレクサを備えることを特徴とする請求項２４に記載のシステム。
【請求項２９】
少なくとも１つのコンポーネントは、デコーダを備えることを特徴とする請求項２４に記載のシステム。
【請求項３０】
少なくとも１つのコンポーネントは、ビデオ・デコーダを備えることを特徴とする請求項２４に記載のシステム。
【請求項３１】
少なくとも１つのコンポーネントは、オーディオ・デコーダを備えることを特徴とする請求項２４に記載のシステム。
【請求項３２】
少なくとも１つのコンポーネントは、エンクリプタを備えることを特徴とする請求項２４に記載のシステム。
【請求項３３】
少なくとも１つのコンポーネントは、オーディオ・エンクリプタを備えることを特徴とする請求項２４に記載のシステム。
【請求項３４】
少なくとも１つのコンポーネントは、ビデオ・エンクリプタを備えることを特徴とする請求項２４に記載のシステム。
【請求項３５】
少なくとも１つのコンポーネントは、ネットワーク・レンダラを備えることを特徴とする請求項２４に記載のシステム。
【請求項３６】
システムであって、
少なくとも１つがホスト・コンピューティング・デバイスを備え、少なくとも１つがリモート・コンピューティング・デバイスを備えた、複数のコンピューティング・デバイスであって、前記複数のコンピューティング・デバイスのそれぞれは、
ユーザ向けにレンダリングされる保護されているコンテンツを処理するコンポーネントの処理連鎖で使用するように構成されているコンポーネントで、認証可能なインターフェースおよび認証プロキシ・インターフェースの１つまたは複数をそれぞれがサポートする１つまたは複数のコンポーネントを備え、
前記認証可能インターフェースは、オーセンティケータにより呼び出し可能であって、前記オーセンティケータに対して、
ダウンストリーム・コンポーネントの認証インターフェースのリスト、
ダウンストリーム・コンポーネントの認証プロキシ・インターフェースのリスト、および
署名を検証する依存コンポーネントのリスト
のうちの１つまたは複数を返し、
前記認証プロキシ・インターフェースは、前記オーセンティケータとの間でデータを読み書きする方法を提供することを特徴とするシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ビデオ・データ、オーディオ／ビデオ・データなどのレンダリング可能な（renderable）デジタル・データを処理するための方法とシステムに関するものである。特に、本発明はデジタルのデータを保護するための方法とシステムに関する。
【背景技術】
【０００２】
マルチメディア・コンテンツなどのデジタル・コンテンツの所有権およびこのようなコンテンツについての正当な権限を有するユーザの使用権を保護することが、近年、非常に重要になってきている。このようなコンテンツの保護の重要性は、特にインターネットなどのコンピューティング・ネットワークの環境においてコンテンツの配布が容易になるにつれ、ますます高まることは避けられない。
【０００３】
コンテンツ保護手法から利益を得る、成功することができるシナリオは多数ある。例えば、映画コンテンツ・プロバイダ（movie content providers）は、自社のコンテンツが保護されることが保証されれば、コンテンツを直接個人に販売することが容易になる。さらに、ユーザは、予約購読スタイルのサービス（subscription style services）（ケーブル・プロバイダ、ペイ・パー・ビュー方式デジタル衛星放送など）からコンテンツを受信することがより容易に、都合良く行える。さらに、ユーザはコンテンツを格納しておき、後日そのコンテンツを再生したり、自分専用にコピーを作成したりすることができ、しかもコンテンツ所有者の権利は必ず保持される。さらに、ユーザは独自のコンテンツを作成し、閲覧者を制限できることがわかる。例えば、ユーザはプライベートのホームビデオをＷｅｂサイトにポスト（post）して、家族だけに限定された期間、閲覧を許可することできる。
【０００４】
コンテンツがデバイスに送られ、ユーザに対しそのコンテンツが再生される場合、通常、再生を整合させ、デジタル権利が保護され、維持されることを確実にするために、適切に定義されたアーキテクチャ（ソフトウェア・コンポーネントとハードウェア・コンポーネントの両方を含む）が必要である。多くの場合、保護されているコンテンツはビデオＷｅｂサーバなどのコンテンツ・ソースから、さらにはローカルのハードディスクからも、ユーザのデバイス（例えば、コンピューティング・デバイス、セットトップボックスなど）に転送される。そのコンテンツは、通常、コンテンツ・ソース側でエンコードまたは圧縮され暗号化されている。その後、ユーザのデバイスでコンテンツを復号し、展開し（圧縮解除し）、例えばモニタおよび／またはスピーカでユーザ対して、そのコンテンツを表示し、またはその他の方法でレンダリングする。
【０００５】
コンテンツは、通常、今も発展と進化が続いているデジタル権利管理（digital rights management）（ＤＲＭ）手法を使用して保護される。ＤＲＭ手法では通常、Ｗｅｂなどのネットワーク上で有料コンテンツについて、セキュアな配信（secure distribution）を有効にし、またさらに重要なことと思われるが、その違法な配信を無効にする、ソフトウェアを使用する。現在のＤＲＭ開発作業は、オーディオ・コンテンツを守ること（securing audio content）に重点が置かれている。しかし、ネットワークの帯域幅が広がれば、ビデオを直接エンド・ユーザに配信する方法は、技術的に効率的で実現可能なものになるであろう。価値のあるデジタル・コンテンツも、デジタルＴＶ、デジタル・ケーブルなどの他のソースから、あるいはデジタル・メディアを介してますます利用できるようになってきている。
【先行技術文献】
【非特許文献】
【０００６】
【非特許文献１】"Systems and Methods For Securing Video Card Output", naming as inventors, Glenn Evans and Paul England, bearing Attorney Docket Number ms1-1115us, filed on June 24, 2002
【非特許文献２】"Methods and Systems Providing Per Pixel Functionality", naming as inventors, Glenn Evans and Paul England, bearing Attorney Docket Number ms1-1025us, filed on June 24, 2002
【発明の概要】
【発明が解決しようとする課題】
【０００７】
将来的には、ユーザがデジタル・コンテンツを体験することを可能にするアーキテクチャは、ユーザおよび敵対的グループの両方からの迂回および不正アクセスを防止することに、存在していなければならないことになる。それと同時に、こうしたアーキテクチャは、信頼できるコンポーネントへの合法的アクセスを許す十分な柔軟性を備え、新しいアプリケーション、ソフトウェア・コンポーネントおよびハードウェア・デバイスが保護されたコンテンツに関して使用することを可能にし、さまざまな種類のメディアに対応し、ハンドヘルドＰＤＡなどのリモート・ハードウェア・デバイス上でコンテンツの認証および再生を行う何らかのメカニズムを備え、リモート・デジタル・スピーカへの再生を行うといったものでなければならない。
【０００８】
さらに、アーキテクチャは、下位インフラストラクチャ層のみが信頼できるものであればよく、信頼できないアプリケーションでもコンテンツが保護されていることを意識せずに保護されているコンテンツを再生できる十分な柔軟性と抽象性を持つ必要である。
【課題を解決するための手段】
【０００９】
以上の理由から、本発明は、柔軟なセキュリティを十分に確保しながらレンダリング可能なデジタル・データを処理する改良された方法およびシステムを実現することと関連する課題から生まれた。
【００１０】
レンダリング可能なコンテンツを処理するための方法、システム、およびアーキテクチャについて説明する。さまざまな実施形態で、保護されていないコンテンツ（つまり、復号化されたコンテンツ）、それがユーザのコンピュータなどのレンダリング・デバイスに届いた後に、そのコンテンツに対する不正アクセスまたはその複製を防止することができる。柔軟なフレームワークは、一般的なメディア・ソース（media sources)に対して、実質的にあらゆる種類のマルチメディア・コンテンツを適切に構成されたレンダリング・デバイスに送ることを可能とするアーキテクチャを備える。コンテンツの保護およびレンダリングは、ローカルでかつ／またはインターネットなどのネットワーク上で行うことができる。
【００１１】
本発明のアーキテクチャを使用すると、第三者がコンポーネントを作成し、それらのコンポーネントを安全にかつ柔軟に処理連鎖（processing chain）に組み込むことができる。コンポーネントが信頼できるものであることを検証するため、コンポーネントの連鎖を辿るのに使用される１つまたは複数のオーセンティケータ（authenticator）を生成し、これによってコンポーネントを検証することができる。さまざまな実施形態が、多種多様のレンダリング環境、コンテンツ・タイプ、およびＤＲＭ手法にわたって、コンテンツを保護することに活用できる標準プラットフォームを提供することができる。
【図面の簡単な説明】
【００１２】
【図１】本発明のさまざまな原理が使用されるシステムの高水準のブロック図である。
【図２】説明されている実施形態の原理が実装可能なコンピューティング環境の例のブロック図である。
【図３】１つまたは複数の実施形態を実装するために利用できるシステム例を示すブロック図である。
【図３ａ】一実施形態による方法のステップを説明する流れ図である。
【図４】１つまたは複数の実施形態を実装するために利用できるシステム例を示すブロック図である。
【図５】一実施形態による認証設計のさまざまな態様を示すブロック図である。
【図６】ネットワーク環境と関連する１つまたは複数の実施形態を実装するために利用できるシステム例を示すブロック図である。
【図７】ネットワーク環境と関連する１つまたは複数の実施形態を実装するために利用できるシステム例を示すブロック図である。
【発明を実施するための形態】
【００１３】
概要
後述の方法、システム、およびアーキテクチャは、保護されているコンテンツのある種のソース（例えば、ＤＲＭサーバ、ＤＶＤサーバ（通常はＤＶＤディスク・ドライブ）、ＨＤＴＶサーバ（通常はＴＶ局であり、ここからＰＣ上のチューナ・カードに放送内容を送る）、または特定の種類のコンテンツ・サーバ）から、保護されたコンテンツを、ユーザに対してレンダリングまたはその他の方法により再生することができるデバイス（デバイスのソフトウェアおよびハードウェアを含む）への保護されているメディア・パスを提供することを目指している。
【００１４】
例えば、図１を考察する。この図では、システム１００は、いくつか例を挙げるとＤＶＤサーバ１０２、コンテンツ・サーバ１０４（オーディオ・コンテンツ、オーディオ／ビデオ・コンテンツなどを供給できるサーバ）、ＨＤＴＶサーバ１０６、およびローカルのハードディスク１１６など多数のさまざまな種類の保護されたコンテンツ・ソースまたはプロバイダを含む。コンテンツ・プロバイダは、ネットワーク１０８、１１０、１１２、１１８のようなネットワーク、バス（例えばＰＣＩやＡＧＰバス）、などを含むことができる各種のメディア上で彼らのコンテンツを供給するように構成されている。通常、コンテンツは、ユーザに対してコンテンツを表示することができるいくつかのタイプのデバイスに供給される。デバイス例として、限定しないが、パーソナル・コンピュータ１１４、ハンドヘルドＰＣ  １２０、例えばセットトップボックス１２４を備えるテレビ１２２、などがある。
【００１５】
後述の説明では、このようなコンテンツ用の対象ハードウェアは、一実施形態では、保護ビデオ・カードが装着されているローカルＰＣであり、また他の実施形態では、ハンドヘルド・コンピュータなどのリモート・ハンドヘルド・デバイスである。このような例は、本明細書で説明している本発明の原理が使用される環境例を説明することを目的としているが、ほんの少数の例に過ぎないことは明白であり理解されるであろう。したがって、請求されている主題の精神と範囲から逸脱することなく他の種類のデバイスを使用することができる。
【００１６】
後述の方法、システム、およびアーキテクチャは、さまざまな種類のコンテンツ形式、その多くは、自分の権利の管理および暗号化を、多くの場合に含む特定のＤＲＭ（デジタル権利管理）特性を持つ、を処理することを目指している。このため、コンテンツを保護する際の柔軟性と堅牢性を大幅に高めることができる。したがって、柔軟なアーキテクチャを実現することで、すべてのコンテンツが必ず特定の１種類のＤＲＭ形式に結ばれていなければならないという状況を回避することができる。そこで、後述の１つまたは複数の実施形態のアーキテクチャの利点の１つは、第三者が、このアーキテクチャにインポートすることができるトランスレータ・モジュールで、これを使用してアーキテクチャ・コンポーネントが信頼でき検証済みであることを保証する共通権利管理および暗号化システムにマッピングできるトランスレータ・モジュールを作成して、提供できるという点である。
【００１７】
さらに、後述の実施形態では、下記の特徴および／または利点の１つまたは複数を採用できる。オーセンティケータ（authenticator）メカニズムを実現し、これをデータの流れに従う再帰的アルゴリズムに一般化することができる。いくつかの実施形態では、初期オーセンティケータが用意され、これが保護されているデータを処理するコンポーネントの連鎖を認証することを開始する。追加オーセンティケータが、その連鎖に沿って作成され、通信することができるセキュア・チャネルを確立することができる。オーセンティケータは、最初に、認証作業を実行するためにそのデータ・グラフの構造を知っている必要はない。さまざまな実施形態で、危うい状態にある既知のコンポーネントの使用を防ぐ取り消しリストを使用できる。さらに、いくつかの実施形態では、ハードウェアとの直接認証とハードウェア・デバイスへの暗号化も可能である。さまざまな実施形態を、信頼できないアプリケーションを扱えるように構成することができる。この場合、信頼できないアプリケーションからデータを保護することができ、しかも、信頼でき、且つ検証されたコンポーネントによるコンポーネントの連鎖により処理することができる。信頼できるアプリケーションなど正当なアプリケーションに対してデータへのアクセス権を与えることができる。これは、データを視覚化するか、または修正を加えるなどの方法でアプリケーションからデータを操作できるようにするのに役立つ。
【００１８】
認証および暗号化機能を完全にサポートしながら、さまざまなバス、ネットワークなどでデータをレンダリングできるリモート・デバイスに関してさまざまな実施形態を実装することができる。これにより、ホスト側に前処理およびインターフェース制御の大半を実行させ、リモート・デバイス（例えば、ＰＤＡ）側ではデータを表示するだけにできる。さらに、さまざまな実施形態ではさまざまなソースからの保護されたコンテンツを処理することができる。つまり、保護されたコンテンツを、ローカル・デバイス（例えば、ＤＶＤドライブ、ビデオ・カメラ、ＴＶチューナ、デジタル・ケーブル）およびリモート・ソース（Ｗｅｂまたはビデオ・サーバなど）により作成することができるということである。さらに、データの処理連鎖（data processing chains）を他のデータの処理連鎖内で再利用することもできる。例えば、ビデオ・クリップからオーディオ・トラックを保護するのに、セキュア・オーディオを再生するために使用されるコンポーネントのほとんどすべてを再利用することができる。
【００１９】
これらの利点およびその他の利点は、以下の説明に照らせば明らかになることであろう。
【００２０】
これらの実施形態では、どのようなデータストリームをも処理することができ、特にビデオまたはオーディオ・データのみに制限されるわけではない。そのため、他のデータ形式を保護するためにもこれらの実施形態を使用することができる。
【００２１】
コンピューティング・システムの例
図２は、後述のシステムでおよび関連する方法を実装できる適当なコンピューティング環境２００の一実施例を示している。
【００２２】
コンピューティング環境２００は、適当なコンピューティング環境の一例にすぎず、メディア処理システムの使用または機能の範囲に関する何らかの制限を示唆する意図はないことを理解されたい。またコンピューティング環境２００はコンピューティング環境例２００に示されているコンポーネントの１つまたは組み合わせに関係する依存性または要求条件があると解釈しないものとする。
【００２３】
説明されているさまざまな実施形態は、さらに、他の多数の汎用または専用コンピューティング・システム環境または構成で動作する。メディア処理システムとともに使用するのに適していると思われるよく知られているコンピューティング・システム、環境、および／または構成の例として、パーソナル・コンピュータ、サーバ・コンピュータ、シン・クライアント（thin client）、シック・クライアント（thick client）、ハンドヘルドまたはラップトップ・デバイス、マルチ・プロセッサ・システム、マイクロ・プロセッサ・ベース・システム、セットトップボックス、プログラム可能家電製品、ネットワークＰＣ、ミニ・コンピュータ、メインフレーム・コンピュータ、上記システムまたはデバイスのどれかを含む分散コンピューティング環境などがあるがこれに制限はされない。
【００２４】
いくつかの実装では、本システムおよび関連する方法は、コンピュータによって実行されるプログラム・モジュールなどのコンピュータ実行可能命令の一般的文脈において説明できるであろう。一般に、プログラム・モジュールには、特定のタスクを実行する、あるいは特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などが含まれる。これらの実施形態はさらに、通信ネットワークを介してリンクされているリモート処理デバイスによりタスクが実行される分散コンピューティング環境で実施することも可能である。分散コンピューティング環境では、プログラム・モジュールをメモリ記憶デバイスなどのローカルとリモートの両方のコンピュータ記憶メディアに配置できる。
【００２５】
図２に示されている実施例によれば、コンピューティング・システム２００は、１つまたは複数のプロセッサまたは処理装置２０２、システム・メモリ２０４、およびシステム・メモリ２０４などの各種システム・コンポーネントをプロセッサ２０２に結合するバス２０６を備えることが示されている。
【００２６】
バス２０６は、メモリ・バスまたはメモリ・コントローラ、周辺機器バス、グラフィック専用高速バス、およびさまざまなバス・アーキテクチャを使用するプロセッサまたはローカルバスを含む１つおよび複数のさまざまなタイプのバス構造を表すことを意図している。例えば、このようなアーキテクチャとしては、業界標準アーキテクチャ（ＩＳＡ）バス、マイクロ・チャネル・アーキテクチャ（ＭＣＡ）バス、拡張ＩＳＡ（ＥＩＳＡ）バス、Ｖｉｄｅｏ  Ｅｌｅｃｔｒｏｎｉｃｓ  Ｓｔａｎｄａｒｄｓ  Ａｓｓｏｃｉａｔｉｏｎ（ＶＥＳＡ）ローカルバス、およびＭｅｚｚａｎｉｎｅバスとも呼ばれるＰｅｒｉｐｈｅｒａｌ  Ｃｏｍｐｏｎｅｎｔ  Ｉｎｔｅｒｃｏｎｎｅｃｔ（ＰＣＩ）バスがあるがこれに制限されない。
【００２７】
コンピュータ２００は通常、さまざまなコンピュータ読み取り可能メディアを含む。このようなメディアは、コンピュータ２００からローカルでかつ／またはリモートからアクセス可能な有効なメディアであればよく、揮発性および不揮発性メディア、取り外し可能および取り外し不可能メディアの両方を含む。
【００２８】
図２では、システム・メモリ２０４は、ランダム・アクセス・メモリ（ＲＡＭ）２１０などの揮発性メモリおよび／または読み取り専用メモリ（ＲＯＭ）２０８などの不揮発性メモリの形式のコンピュータ読み取り可能メディアを備える。起動時などにコンピュータ２００内の要素間の情報伝送を助ける基本ルーチンを含む基本入出力システム（ＢＩＯＳ）２１２は、ＲＯＭ  ２０８に格納される。通常、ＲＡＭ  ２１０には、処理装置２０２に直接アクセス可能な、かつ／または現在操作されているデータおよび／またはプログラム・モジュールを格納する。
【００２９】
コンピュータ２００はさらに、その他の取り外し可能／取り外し不可能な揮発性／不揮発性コンピュータ記憶メディアを備えることもできる。例えば、図２は、取り外し不可能な不揮発性磁気メディアの読み書きを行うハード・ディスク・ドライブ２２８（図には示されておらず、通常「ハードドライブ」と呼ばれる）、取り外し可能な不揮発性磁気ディスク２３２（例えば、「フロッピー（登録商標）ディスク」）の読み書きを行う磁気ディスク・ドライブ２３０、およびＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、またはその他の光メディアなどの取り外し可能な不揮発性光ディスク２３６の読み書きを行う光ディスク・ドライブ２３４を示している。ハード・ディスク・ドライブ２２８、磁気ディスク・ドライブ２３０、および光ディスク・ドライブ２３４はそれぞれ、１つまたは複数のインターフェース２２６によりバス２０６に接続されている。
【００３０】
ドライブおよび関連コンピュータ読み取り可能メディアは、コンピュータ２００用のコンピュータ読み取り可能命令、データ構造、プログラム・モジュール、およびその他のデータを格納する不揮発性ストレージを備える。本発明で説明している環境例ではハードディスク２２８、取り外し可能磁気ディスク２３２、および取り外し可能光ディスク２３６を採用しているが、当業者であれば、磁気カセット、フラッシュ・メモリ・カード、デジタル・ビデオ・ディスク、ランダム・アクセス・メモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）などのコンピュータからアクセス可能なデータを格納できる他のタイプのコンピュータ読み取り可能メディアもオペレーティング環境例で使用できることも理解するであろう。
【００３１】
ハードディスク２２８、磁気ディスク２３２、光ディスク２３６、ＲＯＭ  ２０８、またはＲＡＭ  ２１０には、制限はされないが例としてオペレーティング・システム２１４、１つまたは複数のアプリケーション・プログラム２１６（例えば、マルチメディア・アプリケーション・プログラム２２４）、その他のプログラム・モジュール２１８、およびプログラム・データ２２０などの、多数のプログラム・モジュールを格納できる。ユーザはキーボード２３８およびポインティング・デバイス２４０（「マウス」など）などの入力デバイスを通じてコンピュータ２００にコマンドおよび情報を入力することができる。他の入力デバイスとしては、オーディオ／ビデオ入力デバイス２５３、マイクロフォン、ジョイスティック、ゲームパッド、衛星放送受信アンテナ、シリアル・ポート、スキャナなど（図には示されていない）がある。これらの入力デバイスやその他の入力デバイスは、バス２０６に結合されている入力インターフェース２４２を介して処理装置２０２に接続されるが、パラレル・ポート、ゲームポート、またはユニバーサル・シリアルバス（ＵＳＢ）などの他のインターフェースおよびバス構造により接続することもできる。
【００３２】
モニタ２５６やその他の種類の表示デバイスも、ビデオ・アダプタまたはビデオ／グラフィックス・カード２４４などのインターフェースを介してバス２０６に接続される。モニタに加えて、パーソナル・コンピュータは通常、スピーカやプリンタなどの他の周辺出力デバイス（図に示されていない）を備え、これらは、出力周辺インターフェース２４６を介して接続することができる。
【００３３】
コンピュータ２００は、リモート・コンピュータ２５０などの１つまたは複数のリモート・コンピュータへの論理接続を使用してネットワーク環境で動作することができる。リモート・コンピュータ２５０は、コンピュータに関して本明細書で説明している要素および機能の多くまたはすべてを備えることができる。
【００３４】
図２に示されているように、コンピューティング・システム２００はローカル・エリア・ネットワーク（ＬＡＮ）２５１および一般的なワイド・エリア・ネットワーク（ＷＡＮ）２５２を通じてリモート・デバイス（例えば、リモートコンピュータ２５０）に結合され通信できるようになっている。このようなネットワーキング環境は、事務所、企業規模のコンピュータ・ネットワーク、イントラネットおよびインターネットではよくある。
【００３５】
ＬＡＮネットワーキング環境で使用する場合は、コンピュータ２００は適当なネットワーク・インターフェースまたはアダプタ２４８を介してＬＡＮ  ２５１に接続される。ＷＡＮネットワーキング環境で使用する場合は、コンピュータ２００は通常、モデム２５４またはＷＡＮ  ２５２上で通信を確立するためのその他の手段を備える。モデム２５４は、内蔵でも外付けでもよいが、ユーザ入力インターフェース２４２またはその他の適切なメカニズムを介してシステム・バス２０６に接続できる。
【００３６】
ネットワーク環境では、パーソナル・コンピュータ２００またはその一部に関して述べたプログラム・モジュールは、リモート・メモリ・ストレージ・デバイスに格納できる。制限ではなく例として、図２は、リモート・アプリケーション・プログラム２１６がリモート・コンピュータ２５０のメモリ・デバイスに常駐しているものとして示している。図に示され説明されているネットワーク接続は例であり、コンピュータ間に通信リンクを確立するのにその他手段を使用できる
ことは理解されるであろう。
【００３７】
実施形態の例
図３は、本明細書で説明しているさまざまな発明の原理を理解するうえで役立つコンポーネントの連鎖の例を示している。図３のシステムの総合的な目標の１つは、暗号化されたデータまたはコンテンツおよびＤＲＭデータを何らかのソースから受信することが可能であること、それらのデータを共通システムにマッピングすることが可能であることにあり、このとき、そのデータまたはコンテンツは、保護されたメディア・パスが必要であることを指定するライセンスを有することが可能であることである。その後、システムは、メディア・パスを構成するシステムのコンポーネントが信頼できるものであることを検証することが可能となる。説明されている実施形態の一態様では、このアーキテクチャはさまざまな種類のデータ形式を扱うことができ、またこのアーキテクチャをさまざまな種類のコンポーネントのもとで採用することができる。つまり、このアーキテクチャは、保護されているコンテンツを効果的に処理しレンダリングするために特定のコンポーネントに強く結び付けられている必要はないということである。
【００３８】
以下の説明は、一実施形態によるさまざまな発明の原理を実現するシステムについての、幾分かハイレベルの、機能的な概要を提供している。システムの一実施例のより詳細な態様については、以下の「実装例−ローカル・デバイスの実施形態」というセクションで説明している。
【００３９】
図に示されているシステムは、さまざまな発明の原理を理解できるように、実実上、６段階に分割することができ、それぞれについて以下で詳述する。  
・コンテンツ・ソース・コンポーネントと、ライセンス・サーバ（例えば、コンテンツ・ソース３００）へのその接続。  
・クライアント・コンポーネント、およびデータを復号化し、ＤＲＭコンテンツを含むコンテンツマニフェストを処理する関連するコンポーネント（例えば、クライアント３０４）。  
・デマルチプレクサ、デコーダ、およびデータ再エンクリプタ（data re-encryptors）（例えば、デマルチプレクサ３０６、デコーダ３０８、およびエンクリプタ３１０）。  
・データストリームを処理しミキシングするアプリケーション（例えば、アプリケーション３１２）。  
・ハードウェアによる復号化をセットアップし、データの表示をスケジュールする１つまたは複数のレンダラ（renderers）（例えば、レンダラ３１４）。  
・データを復号しレンダリングするハードウェア（例えば、レンダリング・ハードウェア３１６）。
【００４０】
上記の段階に加えて、図のシステムではさらに、システムを構成するコンポーネントが信頼できるものであることを効果的に確認する検証プロセス期間に作成された複数の異なるオーセンティケータも使用する。これは、コンポーネント上で実現されている電子署名を検証することにより行うことができる。この例では、３つのオーセンティケータ−一次オーセンティケータ３１８と２つの二次オーセンティケータ３２０、３２２−がある。オーセンティケータ３１８および３２０はユーザ・モード・オーセンティケータであり、したがってユーザ・モード・コンポーネントを検証する場合に使用されることに留意されたい。他方、オーセンティケータ３２２はカーネル・モード・オーセンティケータであり、カーネル・モード・コンポーネントを検証する場合に使用される。
【００４１】
さらに、このシステムではトランスレータ３０２などのトランスレータを採用することができる。トランスレータ３０２を使用して、ＤＲＭ形式のコンテンツおよびライセンス・データをシステム側で認識できる形式に変換することができる。つまり、説明するシステムの利点の１つは、システムが本来認識しない、異なるいわゆる「外来の（foreign)」ＤＲＭ形式に関して動作するように構成できるという点である。特に、トランスレータ・コンポーネントは、例えば、さまざまなＤＲＭ形式を共通アーキテクチャとともに使用できるように第三者側で作成できる。そのようにして、さまざまな、知られているまたはそれ以降開発されたＤＲＭ形式をも利用できるようシステムの自由度を高めることができる。
【００４２】
コンテンツ・ソース
この特定の例では、コンテンツ・ソース３００などのコンテンツ・ソース・コンポーネントは、ネイティブのＤＲＭソース（つまり、コンポーネントが認識するソース）を読み込んだり、外部ＤＲＭ形式をコンポーネントが認識するＤＲＭ形式に変換したりする役目を持つ。後者の作業は、コンテンツ・ソースの一部を含む場合も含まない場合もあるトランスレータ３０２の助けを借りて実行することができる。トランスレータ３０２を使用して、コンテンツおよびライセンスを認識可能なＤＲＭ形式に転写することができる。
【００４３】
ＤＲＭコンテンツを提供するローカル・デバイス（ＤＴＶ受信機など）が、暗号システムおよびライセンス制限を認識可能なＤＲＭ形式に変換する。そのようなデバイスに関連するドライバは、ＤＲＭコンテンツを作成できるようにする署名を発行できる。そのライセンスによりリモート・ライセンス・サーバへの依存性を指定し、取り消しリストを更新できる。取り消しリストは通常、危うい状態にあるコンポーネントをシステム側で突き止められるように用意される。例えば、ライセンスにより、ローカルでキャッシュできる週単位の取り消しリストを要求することができる。
【００４４】
クライアントとオーセンティケータ
クライアント３０４は通常、暗号化されたコンテンツと、クライアントが受け取るマニフェストの一部として含めることができるライセンスを受け取る。通常、マニフェストは、コンテンツのレンダリングに必要なレンダリング・パイプラインのコンポーネントを記述する。さらにライセンスには、コンテンツが必要とするセキュリティのレベルなどの補足情報を含めることもできる。これについては、以下で詳述する。
【００４５】
マニフェストはさらに、レンダリング・パイプライン内のコンポーネントを検証するために使用する必要があるオーセンティケータの種類を指示すこともできる。それとは別に、マニフェストは、数種類のオーセンティケータを要求し、レンダラなどの他のパイプライン・コンポーネントに依存して、オーディオおよびビデオ・カーネル・オーセンティケータなどの対応するオーセンティケータを作成することもできる。
【００４６】
ネットワーク接続またはキャプチャ・ソースをセットアップした後、コンテンツ・ソース側は、ライセンスに応じてバインドするようクライアント３０４に指示することもできる。また、コンテンツ・ソースは、バインド・プロセスを補助するためクライアントまたは他のコンポーネントが使用するソース関連情報をセットアップすることもできる。ライセンスがバインドされると、クライアントでは、オーセンティケータ３１８などの１つまたは複数のオーセンティケータ（例えば、ビデオおよびオーディオ・オーセンティケータ）を作成することができる。クライアントは、ライセンス要件をオーセンティケータに、それがインスタンス化されるときに渡すことができる。
【００４７】
オーセンティケータは、パイプライン内の各コンポーネントを辿り（walk through the component）、暗号化されていないデータを処理するコンポーネントの署名を検証することができる。例えば、図のシステムで、クライアント３０４はセキュア・サーバによって認証されることが可能であり、認証された後、クライアントはオーセンティケータ３１８を作成できる。生成されると、オーセンティケータ３１８は、デマルチプレクサ３０６、デコーダ３０８、およびエンクリプタがすべて信頼できるものであることを検証することができる。
【００４８】
さらに、この例では、バスまたは認証されていないコンポーネント間で（例えば、暗号化されたリンクを使って）、またはカーネル空間へデータが渡されたときに、データフロー・パイプラインの残り部分を検証するために、二次オーセンティケータが生成される。したがって、この例では、レンダラ３１４で二次オーセンティケータ３２０を作成し、このオーセンティケータによりレンダラが信頼できるものであることを検証する。その後、オーセンティケータ３１８、３２０が、それらの間の、認証され且つ暗号化されたチャネル３１９をセットアップすることができる。
【００４９】
認証され暗号化されたチャネル３１９はさまざまな目的に使用することができる。例えば、チャネルでは隣接するオーセンティケータ間の通信を行うことができる。例えば、これにより、二次オーセンティケータは検証情報および妥当性確認またはその他の要求の報告を元のオーセンティケータに送り返すことができる。さらに、オーセンティケータは、危うい状態にあってもはや信頼できないと思われるコンポーネントを記述する取り消しリストをチェックできなければならない。さらに、認証され暗号化されているチャネルを使用して、信頼できるコンポーネントの間のビデオおよびオーディオ・データを暗号化する暗号化セッションをセットアップすることができる。
【００５０】
ハードウェア復号化機能がサポートされているリモート・レンダリング・デバイスでは（詳しくは後述）、リモート・デバイスへの暗号化および認証のプロキシとなる二次オーセンティケータを作成できる。リモート・デバイス上では、小さなだけで、場合によっては信頼されていないプロキシ・コンポーネントを用意するだけでよい。それでも、その後一次オーセンティケータにより取り消せるようにリモートハードウェアで自己識別を行う必要がある。
【００５１】
ビデオ・コンテンツについては、汎用オーディオ・ビデオ（ＡＶ）オーセンティケータが、ユーザ・モードのコンポーネントを検証し、レンダラがメディア特有のオーセンティケータを作成できる。
【００５２】
デマルチプレクサ、デコーダ、および再エンクリプタ
デマルチプレクサ３０６は、通常、クライアント３０４から暗号化されていないデータを受け取り、そのデータをオーディオおよびビデオ・ストリームなどの異なるストリームに分割する。次に、デマルチプレクサ３０６は、通常、それらのストリームをデコーダ３０８などの１つまたは複数のデコーダに渡し、さらに処理を行う。オーディオ・デコーダ（エンクリプタ３１０などのエンクリプタとともに）はデータを再暗号化し、それをアプリケーション３１２に送って処理することができる。ビデオ・デコーダは、ＰＣＩ／ＡＧＰバスでビデオ・カードのランダム・アクセス・メモリ（ＶＲＡＭ）に安全に転送できるようにデータを再暗号化する。ビデオ・デコーダは、通常、部分的に圧縮した（そして暗号化した）データをビデオ・カードに渡し、タイムスタンプの修正、データの再配列、およびヘッダの構文解析を実行できる。例えば、ＤＶＤの再生では、デコーダがベクトル・レベル・データと残余を抽出し、それらをビデオ・ハードウェアに渡して処理する。デコーダはさらに、修正を行って、逆方向再生または可変速度効果をシミュレートすることもできる。
【００５３】
アプリケーションとミキシング
アプリケーション３１２は、ビデオ・ストリームとオーディオ・ストリームをレンダラによって供給される混合バッファ（mixing buffers）内に入れ混在させることができる。その後、ハードウェアに対して、混合命令のリストとともにデコーダから暗号化されたバッファを実際に渡す。ピクセル・シェーダ（pixel shaders）および任意多角形マッピング（polygon mappings）を使用するような、多数のイメージ処理オペレーションおよび非線形ビデオ効果、が可能である。アプリケーション側で暗号化されていないデータにアクセスする必要が生じた場合、切り離された信頼できるワーカー・プロセス（separated trusted worker process）を作成できる。次に、アプリケーションは実際に、もうひとつの認証されているデコーダになり、データの復号化、処理、および再暗号化を行って、ビデオ・ハードウェアまたは次の処理ユニットに出力する。
【００５４】
レンダラおよびコンポジッタ（Compositors）
この例では、レンダラ３１４などのレンダラは、デコーダ３０８からディスプレイ・ドライバおよびオーディオ・ドライバ（たとえば、レンダリング・ハードウェア３１６）への暗号化セッションのプロキシになることができる。レンダラは、同期化処理およびハードウェアのセットアップの役目を担っている。レンダラは、関連するオペレーティング・システムおよびドライバＡＰＩのような、さまざまなユーザ・モードＡＰＩとコードを備えることができる。
【００５５】
データがビデオ・カードのＶＲＡＭに転送されると、場合によっては、このデータは、復号化され、他のビデオソースとブレンドされて、ユーザ用ディスプレイに直接マッピングされているメモリの一部（「デスクトップ」または「プライマリ・サーフェス（primary surface）」と呼ばれる）にコピーされる。上述したおよび後述する保護されているメディア・パス・システムでは、一時ミキシング・バッファ（temporary mixing buffers）とデスクトップが不正アクセスから保護されることを確実にすることになる。
【００５６】
デスクトップ上に配置された後のデータの完全性（integrity）を維持する方法として、信頼できるグラフィックス・ハードウェアを使用するやり方がある。このシステム例は、参照によりその開示が本明細書に組み込まれている文献（例えば、非特許文献１および非特許文献２参照）で説明されている。
【００５７】
本質的に、参照している特許出願で説明されているシステムでは、出力データをディスプレイ上のウィンドウの原点に関して暗号化している。ウィンドウを物理的に移動した場合、原点が移動するか、またはデータが新しい原点に関して暗号化される。ディスプレイのハードウェアのＤＡＣのみ、データの復号化および表示を行うことができる。
【００５８】
コンテンツは、デコーダによって直接デスクトップに暗号化するか、または最終的なイメージが組み立てられた後レンダラによって信頼できるハードウェアを使用して暗号化変換（transcrypt）することができる。
【００５９】
レンダラがネットワーク上で「軽量」クライアントに対して実行される実施形態では、レンダラを、認証されたローカル・コンポーネントとリモート・コンポーネントに分割することができる。ネットワークを介して、圧縮された暗号化データおよび操作命令がリモート・レンダラに送信される。リモートハードウェアのサポートがない場合には、ホスト上でデータのブレンドを実行できる。
【００６０】
レンダリング用のハードウェア
グラフィックス・カードはコンテンツ・ストリームの復号化、グラフィックス・プロセッサ・ユニット（ＧＰＵ）を使用したデータの操作、および出力データの表示を受け持つ。上記の参照により取り込まれている特許出願では、保護されているコンテンツを処理するために使用できる１つの信頼できるハードウェア構成を説明している。
【００６１】
つまり、これらの出願では、ＧＰＵ内の復号化／暗号化エンジンと鍵（「暗号プロセッサ」と呼ばれる）を管理するコンポーネントとに分割できる暗号法サポート機能を説明している。グラフィックス・ハードウェアは、ピクセル毎の暗号化サポートを備え、ＶＲＡＭを暗号化された形式で保持できる。次に、ＧＰＵによるそれぞれのグラフィックス・オペレーションで、着目しているピクセルを復号化し、それに対してある処理を実行し、その出力を再暗号化することができる。イメージは暗号鍵とともにタイル化され、各鍵領域がＧＰＵ内のキャッシュと効率よく整合することになる。ビデオＤＡＣの出力は、デジタル方式の保護またはアナログ方式の保護のいずれかを行うことができる。リモートのディスプレイでは、ディスプレイ・ハードウェアは、ネットワーク上で送信されるデータを復号化する何らかの形式の復号化サポートが知らされることになる。
【００６２】
図３ａは、一実施形態による方法のステップを説明する流れ図である。これらのステップは、適当なハードウェア、ソフトウェア、ファームウェア、またはそれらの組み合わせにより実装することができる。図の例では、これらのステップを上述および後述のようなソフトウェア・アーキテクチャに関して実行することができる。
【００６３】
ステップ３５４で、ＤＲＭの変換（translation）が必要かどうかを決定する。必要であれば、ステップ３５６で、ＤＲＭを、コンテンツをレンダリングする処理システムにより認識される形式に変換できる。このステップは、いくつかの場合に、第三者ソフトウェア・ベンダが供給する別のトランスレータ・モジュールで実行できる。ステップ３５０では、レンダリング・プロセスの期間中に保護されるべき暗号化されたコンテンツを受け取る。このコンテンツは、ＤＲＭ方式に従って保護されることになる。このコンテンツは任意の適当なソース、例えば、上述の例、から受信することができる。ステップ３５２で、コンテンツに関連付けられたマニフェストを受け取る。ステップ３５０および３５２は、クライアント３０４などの適当に構成されたクライアントにより実行できる（図３）。マニフェストには、コンテンツがそれによってレンダリングされるプロセスを制限する、保護されたメディア・パス要件が記述されている。このような要件はライセンスの形態を取ることができ、また通常はそうである。マニフェストは、暗号化されたコンテンツと同時に受け取る場合も、そうでない場合もある。
【００６４】
さらに、ステップ３５８で、暗号化されたコンテンツを受け取るクライアント・コンポーネントが信頼できるものであるかどうかを検証する。このステップは、例えば、クライアントに関連付けられた電子署名を検証するセキュア・サーバにより実装できる。ステップ３６０で、一次オーセンティケータを作成する。このステップは、クライアント側で実行できる。ステップ３６２で、１つまたは複数のダウンストリームの処理システム・コンポーネントを一次オーセンティケータに明確に伝える（articulate）。このステップは、クライアントおよび／またはダウンストリームのコンポーネントに実装できる。一実施形態では、一次オーセンティケータは、データの渡し先であるコンポーネントに関してクライアントにクエリを実行し、さらに、それらのコンポーネントについてクエリを実行する、さらに同様な処理を繰り返す。ステップ３６４では、１つまたは複数のダウンストリームのコンポーネントを一次オーセンティケータで認証する。このステップは、例えば、セキュア・サーバを使用してさまざまなコンポーネントと関連する電子署名を検証することにより実装できる。
【００６５】
ステップ３６６で、二次オーセンティケータが必要かどうかを決定する。二次オーセンティケータは、何らかの適当な理由から必要になる場合があり、この場合を後述する。二次オーセンティケータが必要ない場合、ステップ３６８では作成しない。他方、二次オーセンティケータが必要な場合は、ステップ３７０で、二次オーセンティケータを作成し、オーセンティケータ間の安全なチャネルを確立する。次に、ステップ３７２では、その二次オーセンティケータを使用して、１つまたは複数のダウンストリームのコンポーネントを認証する。その後、この方法はステップ３６６に戻り、追加二次オーセンティケータが必要かどうかを決定することができる。
【００６６】
実施例−ローカル・デバイスの実装形態
図４は、保護されているメディアを処理するように構成されている、一実施形態にしたがったシステム例を示している。システムは、いくつかの点で、図３に示され説明されているシステムと類似している。この特定の例では、システムはローカル・デバイス上のオーディオ／ビデオ・データを処理するように構成されている。適当なローカル・デバイスに、ローカルＰＣ、セットトップボックス、または通常、オーディオ／ビデオ・データを処理する任意のデバイスを含むことができる。
【００６７】
図４のシステムは、ビデオ経路とオーディオ経路を含む。ビデオ経路は、ユーザ・モードとカーネル・モード共に、ビデオ・カードのＶＲＡＭに送られるビデオを生成するコンポーネント（例えば、構文解析および変換コンポーネント）の連鎖で構成される。フレーム・バッファがデスクトップ上に表示され、それは、ＤＡＣを通じて出力デバイスに送られる。またオーディオ・ストリームを処理するためのオーディオ経路も用意される。
【００６８】
図４のシステムは、保護されているコンテンツを提供するコンテンツ・ソース４００を備える。上述のようなコンテンツには、通常、多くの場合マニフェストに含まれるライセンスが付属するか、またはライセンスに関連付けられている。ライセンスは通常、コンテンツを使用できる人やその使い方などを記述することによりコンテンツの使用を制限する。ライセンスはさらに、コンテンツとともに使用されることになる取り消しリスト、このような取り消しリストの使用の頻度、および取り消しリストのソースとしてのセキュア・サーバなどを指定することもできる。また通常、マニフェストにより、セットアップされる保護されているメディア・パスの性質、そのメディア・パスによるコンポーネントの識別、および暗号化／復号化要求条件など、保護されているコンテンツとともに使用されるセキュリティのレベルを記述することもできる。さらに、通常トランスレータを使用して外部ＤＲＭコンテンツをストリームで認識できるＤＲＭコンテンツに変換できることにも留意されたい。
【００６９】
コンテンツはコンテンツ・ソースによりクライアント４０４に供給される。上述のように、クライアントが取得するライセンスは、そのデータが、オーセンティケータ４１８などの、保護されているメディア・パスのオーセンティケータを必要とすることを示す。この例では、単一のクライアント４０４が、コンテンツ・ソースから受信したデータを復号化する。オーセンティケータ４１８、４２０、および４２２などのオーセンティケータを使用して、暗号化されていないデータを受信するコンポーネントの連鎖を検証する。この作業は、コンポーネントに関連付けられた電子署名を検証する、およびまたはＤＬＬアドレスのリストを通して検証する、などのさまざまな方法で実行できる。コンポーネントの処理連鎖がセットアップされた後、ＤＲＭサーバなどのサーバがクライアント４０４の認証を行う。次に、クライアント４０４は一次オーセンティケータ４１８を作成し、さらにこれにより、復号化されたデータを含むデータを処理するコンポーネントを見つけ出される。コンポーネントは、どのコンポーネントのそのコンポーネントがデータを渡すかについて、個々のコンポーネントにクエリを実行することにより、オーセンティケータ４１８によって見つけ出される。例えば、オーセンティケータ４１８は、クライアント４０４に対して、どのコンポーネントにクライアントがデータを供給するかについて、クエリを実行できる。クライアントは、データをデマルチプレクサ４０６に渡すことを示すことにより、オーセンティケータに応答する。このことは、デマルチプレクサ４０６を指示するポインタをオーセンティケータに渡すことにより、なされる。デマルチプレクサ４０６は暗号化されていないデータを処理するので、信頼される必要がある。デマルチプレクサ４０６は、クライアントにより暗号化されていないデータを受け取り、データをビデオ・ストリームとオーディオ・ストリームに多重化（多重化を解除）する。ビデオ・ストリームは、ビデオ・デコーダ４０８ａおよび関連するダウンストリームのコンポーネント（つまり、エンクリプタ４１０ａ、ビデオ・レンダラ４１４ａ、ビデオ・ドライバおよびＧＰＵ（４１６ａでまとめて示す））により処理されるが、オーディオ・ストリームはオーディオ・デコーダ４０８ｂおよびそのダウンストリーム・コンポーネント（つまり、エンクリプタ４１０ｂ、オーディオ・レンダラ４１４ｂ、オーディオ・ドライバおよびオーディオ・ハードウェア（４１６ｂでまとめて示す））により処理される。
【００７０】
処理連鎖内の個々のコンポーネントは、オーセンティケータに対して、暗号化されていないデータの渡し先である他のコンポーネントのアドレスを送る。その後オーセンティケータは、コンポーネントのリスト内を巡り、例えば、コンポーネントの対応するＤＬＬの署名を検証するなどして、コンポーネントの署名を検証する。これは、セキュア・サーバを使用して、なされる。そのように、例えば、オーセンティケータ４１８はデマルチプレクサ４０６の認証を行う。オーセンティケータ４１８は、次に、両方のデコーダ４０８ａ、４０８ｂを検証する。デコーダがデータを渡すコンポーネント（つまり、エンクリプタ４１０ａ、４１０ｂ）を習得した後、オーセンティケータ４１８は、それらのエンクリプタを認証する。アプリケーション４１２は、信頼できるアプリケーションであってもなくてもよい。アプリケーションが暗号化されていないデータを処理する場合、オーセンティケータ４１８はアプリケーションが信頼できるアプリケーションかどうかを検証することができる。アプリケーションは信頼できるものでない場合、その場合は、アプリケーションは暗号化されているデータを、単に、処理することになる。
【００７１】
最終的に、データはレンダラ４１４ａ、４１４ｂに渡される。レンダラは、自分専用のオーセンティケータ４２０を作成でき、これはオーセンティケータ４１８により検証される。オーセンティケータ４１８、４２０の間で認証され暗号化されたチャネルを確立することができる。検証が済むと、オーセンティケータ４２０はレンダラを認証することができる。
【００７２】
この例では、カーネル・モードのオーセンティケータ４２２がレンダラによって作成され、他のオーセンティケータのうち１つまたは複数により認証される。オーセンティケータ４２２は、ユーザ・モードのオーセンティケータに安全にリンクすることができ、それにより、コンポーネント４１６ａ、４１６ｂなどのカーネル・コンポーネントを検証できる。
【００７３】
さらに鍵マネージャ４２４も用意され、これはオーセンティケータ４２２により認証できる。鍵マネージャ４２４は、暗号化されたデータを渡す処理連鎖の中のさまざまなコンポーネントにより使用される暗号／復号鍵を管理する役割を持つ。鍵マネージャはさらに、暗号化プロセスで使用されるセッション鍵を管理することもできる。カスタム暗号法も、一部において、鍵マネージャ側によって、使用し、実装することができる。例えば、交換可能な暗号ライブラリを中間コンポーネントに提供することもできる。鍵はすべて、セッション・ベースの鍵として、各種コンポーネントに埋め込まれた複数の鍵を有することから避けなければならない。公開鍵暗号アルゴリズムを認証に使用し、ビデオ・ハードウェア上でデコーダと暗号プロセッサの間のセッション鍵をセットアップすることができる。認証に使用される暗号化されたチャネルは、セッション鍵のセットアップのために、認証されたコンポーネントによって再利用することができる。このことは、復号鍵は次のオーセンティケータにより検証されたエンティティにのみに渡されることを確実にする。コンポーネントが、暗号化されたデータとオーセンティケータのデータ・チャネルを同じ宛先に送らなければ、ダウンストリーム・エンティティでそのデータストリームを復号化することはできない。セッション鍵をセットアップするために使用されるアルゴリズムは、デコーダとレンダリング・コンポーネントに特有のものとすることができる。認証チャネルは、セッション鍵生成スレッドに対し個人化して、セッション鍵のセットアップのなりすまし（spoofing）を避けることができる。
【００７４】
各コンポーネントは、再認証することができ、また定期的に再認証すべきであり、鍵は、外部コンポーネントによる挿入攻撃（insertion attacks）を最小限に抑えるために再ネゴシエーション（renegotiate）すべきである。セッション鍵の配列は、ソース側が所定の間隔で鍵を効率よく変更することを可能にすることができる。鍵のセットアップは、比較的低速で、コストのかかるプロセスなので、データストリームと非同期に実行されることがある。数バンク分の鍵を順繰りに使用することにより、データ鍵の同期化問題を回避することができる。例えば、新しい鍵ネゴシエーションが完了する前に４つの鍵で４つのフレーム遅延を起こすことができる。これについては、以下の「鍵ネゴシエーションと同期」という表題のセクションで詳しく説明する。
【００７５】
鍵ネゴシエーションと同期
鍵バンクは通常、複数の鍵で構成される。ビデオの場合、ビデオ・レンダラでデータを処理するときに、通常、表示用の多数のフレームをキューに入れる。効率上の理由から、複数の鍵からなる鍵バンクを使用し、例えば１フレームにつき１つの鍵を同期させれば、フレーム毎に新しい鍵のネゴシエーションを行わなければならないことに関連付けられた問題を緩和することができる。つまり、鍵バンクを用意すれば、鍵のネゴシエーションが鍵毎に行われる必要はないという事実に基づき、鍵ネゴシエーション時間を短縮することができる。したがって、１バンク分の複数の鍵を使用すると、フレーム毎に１つの鍵を使用し、それらの鍵を順繰りに使用することができる。例えば、鍵１から４のネゴシエーションがされると、鍵１をフレーム１に、鍵２をフレーム２に、というように使用される。このように、個々の鍵のネゴシエーションを行う代わりに、複数の鍵に対するネゴシエーションを一度に実行し、その後、その鍵を順繰りに使用する。
【００７６】
例えば、保護されているビデオ経路で、認証されたＰＫＩ暗号システムを使用して、セッション鍵の配列をデコーダとビデオ・ハードウェアの間で確立することができる。その後、その鍵をビデオ・カード内のアクセスし難いメモリとデコーダによって保護されたメモリ内に保持することができる。各鍵は、セッション・インデックスで参照することができる。ビデオ・ハードウェアでは、データはデータの暗号化にどのセッションが使用されたかを示すセッションのインデックスまたはＩＤと関連付けることができる。ＧＰＵが、このセッション・インデックスを使用して、ＧＰＵ内の暗号エンジンをセットアップし、その後、暗号化されているデータを処理（つまり、復号化）することができる。オーセンティケータ連鎖は、辞書攻撃（dictionary attacks）を弱めさせ、挿入された外部コンポーネントの検出を試みるために、定期的に再ネゴシエーションがされ、認証されることが可能である。
【００７７】
オーセンティケータ
上述のように、再生メカニズム（つまり、処理連鎖）をセットアップした後、クライアント・コンポーネントがデータを復号化し、そのデータをビデオおよびオーディオ・デマルチプレクサに渡す。認証プロセスの一部としてクライアントは、デマルチプレクサに適用されるオーセンティケータを作成する。その後、そのオーセンティケータを、認証のために、次のビデオおよびオーディオ処理コンポーネントに送る。それから、レンダラが、対応するビデオ／オーディオ特有のカーネル・オーセンティケータを作成することができる。オーセンティケータは、各アドレスが置かれているＤＬＬに関連付けられたる電子署名を認証することができる。
【００７８】
オーセンティケータは、コンポーネントの署名を検証するだけでなく、処理連鎖が、コンテンツのライセンス内の要件を満たすに十分なセキュリティがあることを検証することもできる。例えば、ライセンスは、処理連鎖について必要とされるセキュリティのレベルを指定することもできる。このセキュリティ・レベルをオーセンティケータに渡し、そこで、セキュリティ・レベルへの適合性を確認することができる。それとは別に、特定のレベルのオーセンティケータ、例えばレベル１のオーセンティケータまたはレベル２のオーセンティケータを要求することにより、暗黙のうちにセキュリティ・レベルをエンコードすることができ、その両方がそのレベルの一次オーセンティケータを呼び出すことができる。
【００７９】
セキュリティ・レベルの例を以下に示す。  
・ビット０−圧縮されたデータ（および署名されているビデオ・ドライバ）のソフトウェア不明化（software obfuscation）  
・ビット１−圧縮されたデータの信頼できるソフトウェア保護  
・ビット２−バス上の圧縮されたデータのハードウェア保護  
・ビット３−ビデオ／オーディオ・デバイス内の圧縮されたデータのハードウェア保護  
・ビット４−出力デバイスから出るデータのアナログ保護  
・ビット５−出力デバイスから出るデータのデジタル保護
【００８０】
各コンポーネントはさらに、認証の第１パスとしてライセンスに制限を加える機能も備えることができる。これにより、コンポーネント（例えば、デコーダ）が、他のコンポーネントに互換性について問い合わせを行わなければならないようにできる。例えば、オーディオ・デコーダは、一定の条件を満たしたすアプリケーションで再生されることにライセンスされるだけとなる。
【００８１】
システムのバージョンに関する追加要件もまた、ドライバ・サポートの必要なレベルを指定するのに役立つ。例えば、ライセンスに、適合性を保証するためオーセンティケータに渡されるデータのペア（最小限の保護された経路／ドライバ・レベル、最小限のハードウェア要件）を含めることができる。
【００８２】
コンポーネント
オーセンティケータのさまざまな配列（arrangements）を使用して、上記の実施形態を実装することができる。例えば、図４に示され説明されているシステムでは、２つの別々の一次オーセンティケータ−ビデオ回路に１つとオーディオ回路に１つ、または図４に示されているように、オーディオおよびビデオ回路の両方と通信する単一の一次オーセンティケータが考えられる。さらに、ビデオ回路に１つおよびオーディオ回路に１つの、２つの別々のカーネル・モード・オーセンティケータが考えられる。このような場合、２つの別々の、認証され且つ暗号化されているチャネルが、オーディオ回路とビデオ回路のオーセンティケータ間にそれぞれ１つ、備えることができる。
【００８３】
下の説明では、特定の認証設計について説明している。説明されている設計が１つの認証設計を示しているに過ぎないことは理解されるであろう。したがって、請求されている主題の精神と範囲から逸脱することなく他の認証設計を実現することができる。
【００８４】
図５は、オーセンティケータが「Ａn」と指定されている認証設計例を示しており、処理連鎖内のさまざまなコンポーネントによりサポートされているインターフェースは、認証可能なインターフェースに対しては「ＩＡ」、認証プロキシ・インターフェース（authentication proxy interface）に対しては「ＩＡＰ」として示されている。プロキシ・インターフェース（proxy interface）は、別の認証可能なインターフェースへサービスを転送するインターフェースとして機能する。さまざまなコンポーネントの名前が、対応するコンポーネントの隣に示されている。例えば、オーディオ回路では、オーディオ・デコーダ、オーディオ・エンコーダ、アプリケーション、オーディオ・レンダラ、およびオーディオ・ドライバ／ハードウェアが示されている。同様に、ビデオ回路では、ビデオ・デコーダ、ビデオ・エンコーダ、アプリケーション、ビデオ・レンダラ、およびビデオ・ドライバ／ハードウェアが示されている。いくつかのコンポーネントでは、プロキシ・インターフェース（ＩＡＰ）と認証可能インターフェース（ＩＡ）の両方、例えばレンダラのそれぞれ、をサポートすることに留意されたい。
【００８５】
インターフェースは、コンポーネントの単なる論理的部分であり、他のコンポーネントから呼び出される、呼び出し可能な方法の集まりである。オーセンティケータ側で特定のコンポーネントとの通信を望んでいる場合、オーセンティケータはそのコンポーネントの適切なインターフェースを探し、そのインターフェースのメソッドを呼び出すことにより、そのコンポーネントに通信する。
【００８６】
オーセンティケータは、コンポーネントを検証し、他のオーセンティケータへの暗号化されたチャンネルを確立する。さらに、暗号化されていないデータを処理するコンポーネント間に、暗号化されているチャネル・サービスを提供する。このチャネルは、メイン・データを暗号化するコンポーネント間で、セッション鍵の配列のネゴシエーションを実行することに使用される。ＩＡインターフェースは、オーセンティケータに、検証対象のコンポーネントのリストと、検証を続けるためのダウンストリーム・コンポーネントのリストを提供する。ＩＡＰプロキシ・インターフェースは、非認証コンポーネントも合わせてリンクされているオーセンティケータ間で、認証情報を転送するためのパス・スルー・インターフェースである。
【００８７】
それぞれのオーセンティケータ内で、Ｅnは接続イニシエータ（connection initiator）の暗号／復号鍵ペアを表し、Ｄnは接続レシーバの暗号／復号鍵ペアを表す。
【００８８】
第１のオーセンティケータＡ1は、２つの別々の出力回路（例えば、ビデオおよびオーディオ）を検証するために使用されるので、複数の二次オーセンティケータ（Ａ2-5）をサポートすることができる。
【００８９】
クライアントは、初期オーセンティケータＡ1を作成し、第１のコンポーネント（つまり、デマルチプレクサ）のＩＡインターフェースをオーセンティケータに対して指定する。この例では、ＩＡインターフェースは以下の情報をオーセンティケータに返す。  
・ダウンストリーム・コンポーネント（複数）のＩＡインターフェースのリスト  
・（暗号化されたデータを見るだけの）ダウンストリーム・コンポーネント（複数）のＩＡプロキシ・インターフェースのリスト  
・署名を検証すべき従属コンポーネントのリスト  
・次のオーセンティケータのリンク・インデックスの記憶領域（同じオーセンティケータを複数のストリームに再利用することができる）  
・認証の連鎖（authentication chain）の鍵セッション番号（Key session number）
【００９０】
オーセンティケータ（Ａ1）では、クライアントを使用して、ＩＡインターフェースのアドレス、次に従属コンポーネントを検証し、ダウンストリームＩＡインターフェースのそれぞれで繰り返す。次に、オーセンティケータがリストに含まれるＩＡＰインターフェースのそれぞれを通じて暗号化され認証されているチャンネルをセットアップする。
【００９１】
ＩＡＰインターフェースは、次のオーセンティケータと送信するための２つのメソッドを備える。  
・ReadData (buffer, length)  
・WriteData (buffer, length)
【００９２】
通常、レンダラはＩＡＰおよびＩＡインターフェースをサポートする。レンダラのＩＡＰインターフェースは、参照されると、次のオーセンティケータを作成して、そのオーセンティケータに対するＩＡＰ呼び出しのプロキシとなる。その後、それらのオーセンティケータは、認証され暗号化されている通信チャネルを確立する。オーセンティケータはレンダラのＩＡインターフェースを渡され、レンダラから始まる新しい認証連鎖を開始できる。
【００９３】
オーセンティケータはさらに、ＩＡインターフェースを持つコンポーネントがオーセンティケータ・チャネルで情報を渡すためのメソッドを備えることもできる。オーセンティケータでは、これは以下のものを含むことができる。  
・EncryptAndSend(link ID,[in]data)−データを次のコンポーネントに送信する。  
オーセンティケータに渡されたＩＡのインターフェースでは、以下のコール・バックが存在できる。  
・DecryptAndReceive([out]data)−データを信号化して受け取り側コンポーネントに渡す場合に使用する。
・LinkIdentifier([out]link ID)−送信するＩＡインターフェースに渡される送信および受信メソッドが、コンポーネントによって使用され、メイン・データを暗号化するセッション鍵をセットアップすることができる。
【００９４】
クライアントを簡素化するため、オーセンティケータはさらに、以下の単純な暗号機能をサポートできる。  
・CreateSession(HANDLE[out],CLSID drmEncryptorID)−エンクリプタを作成して、セッション鍵を確立する。
・EncryptData(HANDLE[in],BYTE* pIn,BYTE* pOut)  
・DecryptData(HANDLE[in],BYTE* pIn,BYTE* pOut)
【００９５】
その後、オーセンティケータは、コンポーネントに対して暗号化オブジェクトを持続させる。
【００９６】
ネットワークの実施形態−ケースＩ
上述のアーキテクチャの一利点は、インターネットなどのネットワークと関連して使用でき、またインターネットなどのネットワークのもとで適用できるという点である。例えば、図４に関して示され説明されているシステムとさまざまな点で類似しているシステムを示す図６を考察する。図４の実施形態の同様の番号が適宜使用されている（ただし、図６での番号は「６ＸＸ」形式であるが、図４での番号は「４ＸＸ」形式である）。
【００９７】
この例では、リモート・デバイス６２４を備えており、これは、リモート・デバイス上でコンテンツをレンダリングするのに使用可能なソフトウェアおよびハードウェア（６１７でまとめて示す）を実現している。リモート・デバイスとしては、例えば、ハンドヘルドＰＣ、ＰＤＡ、ＵＳＢスピーカ、ＩＥＥＥ１３９４スピーカなどがある。クライアント６０４、鍵マネージャ６２４、デマルチプレクサ６０６、デコーダ６０８ａ、６０８ｂ、エンクリプタ６１０ａ、６１０ｂ、アプリケーション６１２、レンダラ６１４ａ、６１４ｂ、および一次オーセンティケータなどの１つまたは複数のオーセンティケータ６１８および二次オーセンティケータ６２０などのコンポーネントを、ホストなどのネットワーク接続の一方の側に配置することができる。そこで、デバイス６２４は、ネットワーク接続を介してホストと通信し、信頼できるソースから保護されたコンテンツをユーザ向けにレンダリングすることができる。
【００９８】
この例では、リモート・デバイス６２４は、上述においてカーネル・モードのオーセンティケータをセットアップし、構成したのと非常によく似た方法でセットアップし構成することができるオーセンティケータ６２２を含む。
【００９９】
つまり、この例では、ネットワークの両側にあるオーセンティケータ（例えば、オーセンティケータ６２０と６２２）の間に論理接続があるということである。この論理接続は、上で述べたすべての理由により、認証され暗号化されている。ネットワーク・レンダラには、ネットワークを介して通信し、リモート・デバイス６２４に存在するコンポーネントを確認する役割がある。そこでレンダラは、リモート・デバイス６２４上でオーセンティケータを確立し、２つのオーセンティケータ６２０、６２２の間の通信チャンネルを確立する。このチャネルを使用して、エンクリプタ６１０ａとレンダリング・ハードウェア（６１７）の間の鍵をセットアップすることができる。
【０１００】
ネットワークの各側の処理連鎖内の各種コンポーネントの認証が済んだら、保護されているコンテンツを、レンダリングするためにリモート・デバイス６２４に送ることができる。
【０１０１】
ネットワークの実施形態−ケースＩＩ
図７は、図６に示され説明されているシステムとわずかに異なるシステムを示している。ここでは、リモート・デバイス７２４は、純粋にハードウェアだけからなるレンダリング・コンポーネント７１７を包含する。ソフトウェア・プロキシ７１５が実現されており、認証プロセスを補助するが、必ずしも信頼できるものである必要はない。例えば、ハードウェアでＰＫＩ認証サポートを行うことによりハードウェア自体で認証を実行できる。
【０１０２】
この例では、ネットワーク・レンダラが、ネットワークの左側の認証プロトコルをデバイス７２４のハードウェア認証プロトコルにマッピングすることができる。この場合、ソフトウェア・プロキシ７１５内に常駐する認証変換モジュールを使用できる。するとこの場合、ソフトウェア・プロキシ７１５は信頼できるものである必要があり、検証する必要があることになる。それとは別に、ハードウェアはネットワークの左側の認証プロトコルと本来互換性があってもよいし、またハードウェアにマッピング・オペレーション自体を実行する変換モジュールを組み込み、デバイス上のソフトウェアの信頼性を求めたり、それを検証したりする必要をなくすこともできる。
【０１０３】
この種の配置は、第三者が、第三者自身のリモート・デバイス上で使用する、第三者自身のトランスレータ・モジュールを作成できるようにするという観点からはメリットがある。そこでこれらのモジュールは認証プロトコルの変換を実行することができ、そのため、どの認証設計にも縛られない。さらに第三者は、例えば、ビデオ・レンダラで暗号化されていないデータを処理する必要がある場合にネットワークの左側にユーザ・モードのオーセンティケータをセットアップすることもできる。
【０１０４】
さらに、上のアーキテクチャは、取り消しリストをさまざまなコンポーネント上で送信できる、例えば、サーバから取り消しリストをクライアントに送信し、さらにそのリストは処理連鎖を下って、リモート・デバイスに送信することができるという点で都合がよい。したがって、取り消されたコンポーネントはもはや、保護されているデータを処理することができなくなる。例えば、保護されているコンテンツに伴うライセンスで、そのコンテンツにメディア・パス・オーセンティケータが必要であること、さらにデバイスで定期的にサーバにアクセスして取り消しリストを取得する必要があることを指定することができる。そしてユーザは、ユーザのリモート・デバイスを使って、一定期間コンテンツを再生し、その後、ユーザのデバイスでサーバにアクセスして取り消しリストを取得し、それで、ユーザのデバイスが、コンポーネントが取り消されてしまったユーザのリストを更新する必要がある。
【０１０５】
その他の拡張と利点
図６および７の実施形態を拡張し、ネットワーク・レンダラをブロードキャスト・レンダラ（broadcast renderer）として実装するようにできる。例えば、ブロードキャスト・サービス（broadcast service）またはサーバが、暗号鍵をセットアップして、さまざまなハードウェア・デバイスと共有することができる。次に、ブロードキャスト・レンダラは保護されているコンテンツをそれらのデバイスにブロードキャストし、そのコンテンツが依然として保護されていることを確認することができる。
【０１０６】
このアーキテクチャの他の利点として、ユーザ・モードとカーネル・モードの間でデータを必要なだけ何回もやり取りできるという点が挙げられる。これは、オーディオ・データのエコー・キャンセルなどに役立つと思われる。つまり、オーディオ・レンダラがカーネルに入り、ユーザ・モードのコンポーネントへ出てまたカーネルに入る別の処理連鎖を構成できる。
【０１０７】
結論
上述の方法およびシステムでは、レンダリング可能なデジタル・データを処理する改良された方法とシステムを実現できる。上述の実施形態の利点として、制限されないが、信頼できないユーザ・モード・コンポーネント（デコーダ、ビデオ操作）およびカーネル・モード・コンポーネントでの保護されたコンテンツへの不正アクセスを禁止できるという点が挙げられる。さらに、認可されたコンポーネントは、保護されたコンテンツへの不正アクセスに利用されないよう保護することもできる。処理連鎖でさまざまなサード・パーティ・コンポーネントを使用し、また保護されたコンテンツへのアクセスの前にそのようなコンポーネントが信頼できるものであることを確認するメカニズムを備えることができる。変換プロセスまたはトランスレータ・モジュールを使用することで、複数の異なるソースからのコンテンツ、さらに複数の異なる種類のコンテンツおよびＤＲＭ手法をシステムに簡単に組み込むことができる。さまざまな実施形態では、さらに、保護されたコンテンツをデバイスやネットワーク境界をまたいで使用することができ、その際には、境界をまたいで変換可能な認証プロセスを、使用する。さらに、取り消しメカニズム（つまり、取り消しリスト）を使用して、危ういコンポーネントが保護されているコンテンツにアクセスできないようブロックすることができる。またこのアーキテクチャを使用すると、デコーダとレンダリング機能（つまり、表示用ハードウェア）との間にセキュリティ・レベルの高い通信チャネルを確立することもできる。このアーキテクチャは、コンポーネントのトポロジに関する情報を事前に必要とせず、またデータのフローに従うので複雑な構造に適用することができる。
【０１０８】
本発明は構造的機能および／または方法論的ステップに固有の言語で説明されているが、請求項で定められている発明は、説明した特定の機能またはステップに必ずしも限られないことは理解されるであろう。むしろ、特定の機能およびステップは請求されている発明を実施する好ましい形態として開示されている。
【符号の説明】
【０１０９】
１００    システム
１０２    ＤＶＤサーバ
１０４    コンテンツ・サーバ
１０６    ＨＤＴＶサーバ
１０８、１１０、１１２、１１８    ネットワーク
１１４    パーソナル・コンピュータ
１１６    ローカルのハードディスク
１２０    ハンドヘルドＰＣ
１２２    テレビ
１２４    セットトップボックス
２００    コンピューティング環境
２０２    １つまたは複数のプロセッサまたは処理装置
２０４    システム・メモリ
２０６    バス
２０８    読み取り専用メモリ（ＲＯＭ）
２１０    ランダム・アクセス・メモリ（ＲＡＭ）
２１２    基本入出力システム（ＢＩＯＳ）
２１６    リモート・アプリケーション・プログラム
２２８    ハード・ディスク・ドライブ
２３０    磁気ディスク・ドライブ
２３２    取り外し可能な不揮発性磁気ディスク
２３４    光ディスク・ドライブ
２３６    取り外し可能な不揮発性光ディスク
２３８    キーボード
２４０    ポインティング・デバイス
２４２    入力インターフェース
２４４    ビデオ／グラフィックス・カード
２４６    出力周辺インターフェース
２４８    適当なネットワーク・インターフェースまたはアダプタ
２５０    リモート・コンピュータ
２５１    ローカル・エリア・ネットワーク（ＬＡＮ）
２５２    ワイド・エリア・ネットワーク（ＷＡＮ）
２５３    オーディオ／ビデオ入力デバイス
２５４    モデム
２５６    モニタ
３００    コンテンツ・ソース
３０２    トランスレータ
３０４    クライアント
３０６    デマルチプレクサ
３０８    デコーダ
３１０    エンクリプタ
３１２    アプリケーション
３１４    レンダラ
３１６    レンダリング・ハードウェア
３１８    一次オーセンティケータ
３２０、３２２    二次オーセンティケータ
４０４    クライアント
４０６    デマルチプレクサ
４０８ａ    ビデオ・デコーダ
４０８ｂ    オーディオ・デコーダ
４１０ａ    エンクリプタ
４１０ｂ    エンクリプタ
４１４ａ    ビデオ・レンダラ
４１４ｂ    オーディオ・レンダラ
４１６ａ    ビデオ・ドライバおよびＧＰＵ
４１６ｂ    オーディオ・ハードウェア
４１８、４２０、および４２２    オーセンティケータ
４２４    鍵マネージャ
６０４    クライアント
６０６    デマルチプレクサ
６０８ａ、６０８ｂ    デコーダ
６１０ａ、６１０ｂ    エンクリプタ
６１２    アプリケーション
６１４ａ、６１４ｂ    レンダラ
６１７    レンダリング・ハードウェア
６１８    オーセンティケータ
６２０、６２２    オーセンティケータ
６２４    鍵マネージャ
６２４    リモート・デバイス
７１５    ソフトウェア・プロキシ
７１７    レンダリング・コンポーネント
７２４    リモート・デバイス
【図１】
2010114919.tif 000003
【図２】
2010114919.tif 000004
【図３】
2010114919.tif 000005
【図３ａ】
2010114919.tif 000006
【図４】
2010114919.tif 000007
【図５】
2010114919.tif 000008
【図６】
2010114919.tif 000009
【図７】
2010114919.tif 000010