(57)【特許請求の範囲】
【請求項１】
媒体プレイバックアプリケーションと、前記媒体プレイバックアプリケーションの下流にあるダウンストリームコンポーネントとの間にセキュア通信チャネルを確立するステップと、
前記セキュア通信チャネルを使用することにより、前記媒体プレイバックアプリケーションが前記ダウンストリームコンポーネントに対して、物理コネクタを介して提供される媒体コンテンツを保護するための複数の異なるタイプのコンテンツ保護技術のうちの１つまたは複数をイネーブルするように指示することを少なくとも可能にするステップと、
を含むことを特徴とする方法。
【請求項２】
前記セキュア通信チャネルを使用することにより、前記媒体プレイバックアプリケーションが前記ダウンストリームコンポーネントに対して、前記異なるタイプのコンテンツ保護技術のうちの１つまたは複数のコンテンツ保護技術を適用する方法について保護タイプごとの保護レベルを指示することを可能にするステップをさらに含む、ことを特徴とする請求項１記載の方法。
【請求項３】
前記ダウンストリームコンポーネントはソフトウェアコンポーネントを含む、ことを特徴とする請求項１記載の方法。
【請求項４】
前記セキュア通信チャネルを使用することにより、前記媒体プレイバックアプリケーションが前記ダウンストリームコンポーネントに対してステータス情報を要求することを可能にするステップをさらに含む、ことを特徴とする請求項１記載の方法。
【請求項５】
前記セキュア通信チャネルを使用することにより、前記媒体プレイバックアプリケーションが前記ダウンストリームコンポーネントからステータス情報を要求することを可能にするステップと、
前記セキュア通信チャネルを使用することにより、前記ダウンストリームコンポーネントからステータス情報を受け取るステップと、
をさらに含むことを特徴とする請求項１記載の方法。
【請求項６】
前記セキュア通信チャネルを使用することにより、前記媒体プレイバックアプリケーションが前記ダウンストリームコンポーネントからステータス情報を要求することを可能にするステップと、
前記セキュア通信チャネルを使用することにより、前記媒体プレイバックアプリケーションによって以前に送られた命令に関係するステータス情報を前記ダウンストリームコンポーネントから受け取るステップと、
をさらに含むことを特徴とする請求項１記載の方法。
【請求項７】
前記セキュア通信チャネルを使用することにより、前記媒体プレイバックアプリケーションが前記ダウンストリームコンポーネントからステータス情報を要求することを可能にするステップと、
前記セキュア通信チャネルを使用することにより、前記媒体プレイバックアプリケーションによって以前に送られた命令に関係しないステータス情報を前記ダウンストリームコンポーネントから受け取るステップと、
をさらに含むことを特徴とする請求項１記載の方法。
【請求項８】
請求項１記載の方法を実施する１つまたは複数のコンピュータ可読命令を有する、ことを特徴とするコンピュータ可読媒体。
【請求項９】
請求項８のコンピュータ可読媒体に記載の１つまたは複数のコンピュータ可読命令を実施する、ことを特徴とするコンピュータシステム。
【請求項１０】
１つまたは複数のコンピュータ可読媒体と、
前記媒体に記憶されているソフトウェアコンポーネントであって、
媒体プレイバックアプリケーションとのセキュア通信チャネルを確立し、
前記セキュア通信チャネルを使用して前記媒体プレイバックアプリケーションから命令を受け取り、物理コネクタを介して提供される媒体コンテンツを保護するための複数の異なるタイプのコンテンツ保護技術のうちの１つまたは複数のコンテンツ保護技術をイネーブルにし、
前記１つまたは複数のコンテンツ保護技術のうちの少なくとも一部について実行する命令を受け取るように構成されたソフトウェアコンポーネントと、
を含むことを特徴とするシステム。
【請求項１１】
前記ソフトウェアコンポーネントはソフトウェアドライバを含む、ことを特徴とする請求項１０記載のシステム。
【請求項１２】
前記ソフトウェアコンポーネントは、さらに、前記セキュア通信チャネルを使用することにより、前記媒体プレイバックアプリケーションからステータスリクエストを受け取るように構成されている、ことを特徴とする請求項１０記載のシステム。
【請求項１３】
前記ソフトウェアコンポーネントは、さらに、前記セキュア通信チャネルを使用することにより前記媒体プレイバックアプリケーションからステータスリクエストを受け取るように構成され、前記ソフトウェアコンポーネントは、さらに、前記セキュア通信チャネルを使用することにより前記媒体プレイバックアプリケーションに対してステータス情報を送るように構成されている、ことを特徴とする請求項１０記載のシステム。
【請求項１４】
前記ソフトウェアコンポーネントは、さらに、前記セキュア通信チャネルを使用することにより前記媒体プレイバックアプリケーションからステータスリクエストを受け取るように構成され、前記ソフトウェアコンポーネントは、さらに、前記セキュア通信チャネルを使用することにより前記媒体プレイバックアプリケーションにステータス情報を送るように構成され、前記ステータス情報は前記媒体プレイバックアプリケーションから以前に受け取られた命令に関係する、ことを特徴とする請求項１０記載のシステム。
【請求項１５】
前記ソフトウェアコンポーネントは、さらに、前記セキュア通信チャネルを使用することにより前記媒体プレイバックアプリケーションからステータスリクエストを受け取るように構成され、前記ソフトウェアコンポーネントは、さらに、前記セキュア通信チャネルを使用することにより前記媒体プレイバックアプリケーションにステータス情報を送るように構成され、前記ステータス情報は前記媒体プレイバックアプリケーションから以前に受け取られた命令に関係しない、ことを特徴とする請求項１０記載のシステム。
【請求項１６】
請求項１０に記載のシステムを実施する、ことを特徴とするコンピューティングシステム。
【請求項１７】
媒体プレイバックアプリケーションとダウンストリームコンポーネントとの間に信頼を確立するステップと、
前記ダウンストリームコンポーネントに関連付けられた公開鍵を使用することにより、前記ダウンストリームコンポーネントによって提供される乱数と、
データ保全鍵と、
１つまたは複数の開始番号とを暗号化することによって、
前記媒体プレイバックアプリケーションと前記ダウンストリームコンポーネントとの間にセキュアチャネルを確立するステップと、
前記暗号化されたデータを前記ダウンストリームコンポーネントに送るステップと、
前記セキュアチャネルを使用することにより、コマンドを含むデータセクションと前記コマンドを認証するために使用可能なデータを含む認証セクションとを備えたコマンドメッセージを前記ダウンストリームコンポーネントに送るステップと、
前記セキュアチャネルを使用することにより前記ダウンストリームコンポーネントからステータス情報を要求するステップと、
前記セキュアチャネルを使用することにより、ステータス情報を含むデータセクションと前記ステータス情報を認証するために使用可能なデータを含む認証セクションとを備えたステータスメッセージを、前記ダウンストリームコンポーネントから受け取るステップと、
を含むことを特徴とする方法。
【請求項１８】
前記１つまたは複数の開始番号は、開始ステータスシーケンス番号と開始コマンドシーケンス番号とを含み、これらの番号はステータスメッセージまたはコマンドメッセージが失われたか否かをそれぞれ確認するために使用可能である、ことを特徴とする請求項１７記載の方法。
【請求項１９】
前記セキュアチャネルを使用することにより前記ダウンストリームコンポーネントからステータス情報を要求するステップは、前記ステータス情報の要求と共に乱数を送ることを含み、前記ステータスメッセージの前記認証セクションは、前記乱数に関連付けられたデータを含む、ことを特徴とする請求項１７記載の方法。
【請求項２０】
前記コマンドメッセージおよび前記ステータスメッセージの前記認証セクションは、前記データ保全鍵を使用することにより処理されたデータを含む、ことを特徴とする請求項１７記載の方法。
【請求項２１】
前記コマンドメッセージは、前記ダウンストリームコンポーネントに対して、物理コネクタを介して提供される媒体コンテンツを保護するための複数の異なるタイプのコンテンツ保護技術のうちの１つまたは複数のコンテンツ保護技術をイネーブルにするように指示するコマンドを含む、ことを特徴とする請求項１７記載の方法。
【請求項２２】
前記ダウンストリームコンポーネントはソフトウェアドライバを含む、ことを特徴とする請求項１７記載の方法。
【請求項２３】
請求項１７記載の方法を実施するコンピュータ可読命令を有する、ことを特徴とするコンピュータ可読媒体。
【請求項２４】
請求項２３記載の１つまたは複数のコンピュータ可読媒体を有する、ことを特徴とするコンピューティングシステム。
【請求項２５】
前記セキュアチャネルを使用することにより、保護された媒体コンテンツを前記ダウンストリームコンポーネントに提供するステップをさらに含む、ことを特徴とする請求項１７記載の方法。
【請求項２６】
１つまたは複数のコンピュータ可読媒体と、
前記媒体上に常駐しているソフトウェアコンポーネントであって、
媒体プレイバックアプリケーションとの信頼を確立し、
該ソフトウェアコンポーネントに関連付けられた公開鍵を前記媒体プレイバックアプリケーションに提供し、さらに前記公開鍵を使用することにより暗号化された暗号データを前記媒体プレイバックアプリケーションから受け取ることとによって、前記媒体プレイバックアプリケーションとのセキュアチャネルを確立し、
ここで、前記暗号データは、
該ソフトウェアコンポーネントによって以前に提供された乱数と、
データ保全鍵と、
１つまたは複数の開始番号とを含んでおり、
前記セキュアチャネルを使用することにより、コマンドを含むデータセクションと、前記コマンドを認証するために使用可能なデータを含む認証セクションとを有するコマンドメッセージを前記媒体プレイバックアプリケーションから受け取り、
前記セキュアチャネルを使用することにより、前記媒体プレイバックアプリケーションからステータスリクエストを受け取り、
前記セキュアチャネルを使用することにより、ステータス情報を含むデータセクションと、前記ステータス情報を認証するために使用可能なデータを含む認証セクションとを有するステータスメッセージを前記媒体プレイバックアプリケーションに送るように構成されたソフトウェアコンポーネントと、
を具備したことを特徴とするシステム。
【請求項２７】
前記１つまたは複数の開始番号は、開始ステータスシーケンス番号と開始コマンドシーケンス番号とを含み、これらの番号はステータスメッセージまたはコマンドメッセージが失われたか否かをそれぞれ確認するために使用可能である、ことを特徴とする請求項２６記載のシステム。
【請求項２８】
前記コマンドメッセージおよび前記ステータスメッセージの前記認証セクションは、前記データ保全鍵を使用することにより処理されたデータを含む、ことを特徴とする請求項２６記載のシステム。
【請求項２９】
前記コマンドメッセージは、前記ソフトウェアコンポーネントに対して、物理コネクタを介して提供される媒体コンテンツを保護するための複数の異なるタイプのコンテンツ保護技術のうちの１つまたは複数のコンテンツ保護技術をイネーブルするように指示するコマンドを含む、ことを特徴とする請求項２６記載のシステム。
【請求項３０】
前記コマンドメッセージは、前記ソフトウェアコンポーネントに対して、物理コネクタを介して提供される媒体コンテンツを保護するための複数の異なるタイプのコンテンツ保護技術のうちの１つまたは複数のコンテンツ保護技術をイネーブルするように指示するコマンドを含み、前記ソフトウェアコンポーネントは、複数の異なるタイプのコンテンツ保護技術をイネーブルするように構成されている、ことを特徴とする請求項２６記載のシステム。
【請求項３１】
請求項２６に記載のシステムを実施する、ことを特徴とするコンピューティングシステム。
【請求項３２】
コンピュータ可読媒体上に組み込まれたアプリケーションプログラムインターフェース（ＡＰＩ）を有するコンピュータプログラムであって、
媒体プレイバックアプリケーションによって呼び出し可能であり、前記媒体プレイバックアプリケーションとソフトウェアドライバコンポーネントとの間に信頼を確立する第１のメソッドと、
前記媒体プレイバックアプリケーションによって呼び出し可能であり、前記媒体プレイバックアプリケーションと前記ソフトウェアドライバコンポーネントとの間にセッション鍵を設定する第２のメソッドと、
前記媒体プレイバックアプリケーションによって呼び出し可能であり、前記ソフトウェアドライバコンポーネントに対して、物理コネクタを介して提供される媒体コンテンツを保護するための複数の異なるタイプのコンテンツ保護技術のうちの１つまたは複数のコンテンツ保護技術をイネーブルするように指示する第３のメソッドと、
前記媒体プレイバックアプリケーションによって呼び出し可能であり、前記ソフトウェアドライバコンポーネントに対してステータス情報を要求する第４のメソッドと、
を含むことを特徴とするコンピュータプログラム。
【請求項３３】
前記第１のメソッドは、前記ソフトウェアドライバによって生成された乱数、および、デジタル証明書を返される、ことを特徴とする請求項３２記載のコンピュータプログラム。
【請求項３４】
前記第２のメソッドは、グラフィクスハードウェアによって提供された乱数と、１つまたは複数のセッション鍵と、開始ステータスシーケンス番号と、開始コマンドシーケンス番号の暗号化された連結を提供する、ことを特徴とする請求項３２記載のコンピュータプログラム。
【請求項３５】
前記ＡＰＩは、ビデオレンダリングコンポーネントによって顕示される、ことを特徴とする請求項３２記載のコンピュータプログラム。
【請求項３６】
デバイスドライバを呼び出してコンテンツ保護デバイスのインスタンスを作成するステップであって、該コンテンツ保護デバイスの各々は、個々のビデオセッションに関連付けられており、かつ、該コンテンツ保護デバイスの各々は、該コンテンツ保護デバイスにコマンドおよびステータスリクエストを送ることができるプレイバックアプリケーションとの通信のエンドポイントとして機能する、ステップと、
コンテンツを保護するために適用されるコンテンツ保護の各タイプおよび各レベルに対するグローバル参照カウントを、前記デバイスドライバと共に、維持するステップと、
前記コンテンツ保護デバイスを介して適用されるコンテンツ保護の各タイプおよび各レベルに対するローカル参照カウントを、少なくとも１つのコンテンツ保護デバイスと共に、維持するステップと、
前記コンテンツ保護のタイプまたはレベルの変化に従って、前記グローバル参照カウントおよび前記ローカル参照カウントを調整するステップと、
を具備したことを特徴とする方法。
【請求項３７】
１つまたは複数のコンピュータ可読媒体と、
前記コンピュータ可読媒体上に組み込まれているソフトウェアドライバコードであって、該ソフトウェアドライバコードは、個々のビデオセッションに関連付けられている複数のコンテンツ保護デバイスを実現するように構成されており、コマンドおよびステータスリクエストをコンテンツ保護デバイスに送ることができるプレイバックアプリケーションとの通信のためのエンドポイントとして機能する、前記コンピュータ可読媒体上に組み込まれているソフトウェアドライバコードと、
を具備したコンピュータデバイスであって、
前記ソフトウェアドライバコードは、
ドライバが所与の出力コネクタのためのコンテンツ保護デバイスをサポートするか否かを判断するために呼び出すことができる第１のメソッドと、
関連付けられたコンテンツ保護デバイスを作成するために呼び出すことができる第２のメソッドと、
グラフィクスハードウェア証明書に関連した長さを判断し、ビデオセッションを開始させるために呼び出すことができる第３のメソッドとを含み、
前記コンテンツ保護デバイスの各々は、
グラフィクスハードウェア証明書の長さを問い合わせる第１のメソッドと、
可変長のグラフィクスハードウェアデジタル証明書を返す第２のメソッドと、
前記グラフィクスハードウェアに関連付けられた公開鍵を使用することにより暗号化された、データ保全セッション鍵と開始ステータスシーケンス番号と開始コマンドシーケンス番号の連結を受け取る第３のメソッドと、
前記コンテンツ保護デバイスに関連付けられた物理コネクタ上のコンテンツ保護を変更するためのコマンドを受け取る第４のメソッドと、
使用されている物理コネクタと、前記物理コネクタを介して伝送されるコンテンツに適用することができる保護のタイプと、前記物理コネクタ上でアクティブになっている現行保護レベルとに関する情報を問い合わせる第５のメソッドとを含んだ、呼び出し可能メソッドをサポートする、
ことを特徴とするコンピュータデバイス。
【請求項３８】
前記コンテンツ保護デバイスの第１のメソッドは、前記ソフトウェアドライバコードの第３のメソッドに直接マップする、ことを特徴とする請求項３７記載のコンピュータデバイス。
【請求項３９】
前記コンテンツ保護デバイスの第２のメソッドは、前記ソフトウェアドライバコードの第３のメソッドに直接マップする、ことを特徴とする請求項３７記載のコンピュータデバイス。
【請求項４０】
前記コンテンツ保護デバイスの第３のメソッドは、前記ソフトウェアドライバコードの第３のメソッドに直接マップする、ことを特徴とする請求項３７記載のコンピュータデバイス。
【請求項４１】
前記コンテンツ保護デバイスの第４のメソッドは、前記ソフトウェアドライバコードの第３のメソッドに直接マップする、ことを特徴とする請求項３７記載のコンピュータデバイス。
【請求項４２】
前記コンテンツ保護デバイスの第５のメソッドは、前記ソフトウェアドライバコードの第３のメソッドに直接マップする、ことを特徴とする請求項３７記載のコンピュータデバイス。
【請求項４３】
媒体プレイバックアプリケーションと、前記媒体プレイバックアプリケーションの下流にあるコンポーネントとの間にセキュア通信チャネルを確立する手段と、
前記セキュア通信チャネルを使用することにより、前記媒体プレイバックアプリケーションが前記下流にあるコンポーネントに対して、物理コネクタを介して提供される媒体コンテンツを保護するための複数の異なるタイプのコンテンツ保護技術のうちの１つまたは複数のコンテンツ保護技術をイネーブルにするように指示することを少なくとも可能にする手段と、
を具備したことを特徴とするシステム。
【請求項４４】
前記下流にあるコンポーネントはソフトウェアコンポーネントを含む、ことを特徴とする請求項４３記載のシステム。
【請求項４５】
前記下流にあるコンポーネントはハードウェアコンポーネントを含む、ことを特徴とする請求項４３記載のシステム。
【請求項４６】
前記下流にあるコンポーネントはグラフィクスハードウェアコンポーネントを含む、ことを特徴とする請求項４３記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、媒体コンテンツを保護する方法およびシステムに関する。
【背景技術】
【０００２】
データストリーム(data stream)の形態(form)を有するオーディオデータおよび／またはビデオデータなどを提供するコンテンツプロバイダや、そのようなデータをレンダリング(render)するためのアプリケーションを提供するアプリケーション供給者などの業者は、そのようなデータが無許可の者によって特定され、使用され、またはその他の方法でレンダリングされないように保護したいと望む場合が多い。そのような保護が望まれるのは、一般には、データが何らかの保護された形態で何らかのタイプの可読媒体上に存在する点から、そのようなデータを取り扱い、またはその他の方法で処理する一連のコンポーネントに沿って、当該データをディスプレイやスピーカなどの装置に供給する物理的な出力コネクタとそれらの装置自体の両方に至り、それらを含む範囲である。
【０００３】
例えば、図１を検討してみる。図１には、保護されたコンテンツ(protected content)１２、例えば圧縮または暗号化されたコンテンツを受け入れ、処理することができる例示のシステム１０がハイレベルで示されている。この例では、保護されたコンテンツ１２は、パーソナルコンピュータなどの民生用デバイス１４に供給される。この民生用デバイス内では、一般にはアプリケーション１６が例えばデクリプションコンポーネント(decryption component)１８を使用してコンテンツを解読し、デコーダコンポーネント(decoder component)２０を使用してコンテンツを復号(decode)または伸張(decompress)することによって、保護コンテンツ(protected content)を処理する。コンテンツは、復号された後で、一般には何らかの処理を受けることができ、その後、処理されたコンテンツはレンダラーコンポーネント(renderer component)２２に送られ、レンダラーコンポーネント２２は、当該データがディスプレイ２４（ビデオデータの場合）および／またはスピーカ２６（オーディオデータの場合）などの装置に確実に送られるようにする。
【０００４】
このシステムでは、データは、ディスプレイやスピーカなどの適切なハードウェア装置に送られるように、ＰＣＩ／ＡＧＰバスなどの何らかのタイプのバスを経由しなければならず、その後、物理コネクタを通過し、Ｓ―ＶｉｄｅｏケーブルやＤＶＩケーブルなどのケーブルを通らなければならない。
【０００５】
例えば、コンテンツが民生用デバイス１４内で解読(decrypt)され、ディスプレイやスピーカなどの出力デバイスに供給されるときコンテンツを保護するために、長年にわたり様々なタイプのコンテンツ保護方式および技術が開発され、使用されてきた。このような保護方式および技術は、多様なオーディオデータおよびビデオデータのタイプと同じ程、様々である。さらに、おそらく最も重要なのは、現在、アプリケーションがこのような多様なタイプのコンテンツ保護方式および技術の集りの「挙動(behavior)」を安全に制御する方法がないことである。
【０００６】
具体的には、最終的(ultimately)にハードウェアデバイスでレンダリング(render)されることになるデータを処理するコンポーネントの連鎖(chain of components)を考えてみる。当業者ならわかるように、データとそれに付随するアプリケーションからの通信情報とが連鎖(chain)内にある間に、当該データと通信情報とに接触またはその他の方法でアクセスするコンポーネントの様々な層がある。例えば、アプリケーションは一般には、データをレンダリングするハードウェアと直接には通信しない。通常は、アプリケーションが通信するユーザモードのソフトウェアスタックがあり、次に、実際にハードウェアと通信する、ユーザモードソフトウェアスタックの下のカーネルモードのドライバスタックがある。事実上、連鎖(chain)内にあるこれらコンポーネントのうちのいずれも、この連鎖に沿って通過するデータおよび／または通信情報に対して実際に改竄を加えることができる。
【発明の開示】
【発明が解決しようとする課題】
【０００７】
したがって、本発明の目的は、あるアプリケーションからその下流にあるコンポーネントに向かって流れる通信およびデータの両方に対して、セキュアチャネルを提供することにある。
【課題を解決するための手段】
【０００８】
概要
保護コンテンツ(protected content)プレイバックアプリケーション(playback application)を実行するコンピュータなどの装置と、モニタ、フラットパネルＬＣＤ、テレビジョンなどの付随するディスプレイのグラフィックドライバなどの関連付けられたドライバとの間の、セキュア通信チャネル(secure data channel)、および、実施形態によっては、セキュアデータチャネルを確立することによって、媒体コンテンツの保護を可能にするプロトコルを使用する方法およびシステムに関する。また、様々な実施形態は、物理コネクタを介してディスプレイなどの装置に出力されるデータにコンテンツ保護を適用すべきであることを通知するというコンテンツ提供者およびアプリケーション供給者にとっての必要に対処することを対象としている。
【０００９】
以下で説明する様々な実施形態は、ユーザモードプレイバックアプリケーション(user mode playback application)からグラフィクスドライバなどのドライバにコマンドを安全に渡し、ドライバからユーザモードアプリケーションにステータス情報(status information)を安全に返す手段を提供する。以下で説明する実施形態では、セキュア通信チャネルが確立された後は、ユーザモードアプリケーションは、関連するドライバに指示して、コンピュータとディスプレイとの間の物理コネクタに対するコンテンツ出力保護をイネーブルにさせることができる。セキュアチャネルセッション(secure channel session)の排他性によって、保護コンテンツがコンピュータからディスプレイに伝送される間に攻撃者が保護コンテンツを記録するのを防ぐことができる。
【００１０】
以下の説明において、これら様々な実施形態の説明は、別々の互いに関連する二筋に沿って進められる。具体的には、「アプリケーションからダウンストリームコンポーネントに至るセキュアチャネルの確立のためのプロトコル」と題する項では、本発明のプロトコルについて説明する。このプロトコルは、任意の利用可能なシステムと共に使用されることを意図したものであり、必ずしも特定の１つのシステムまたはオペレーティングシステムに拘束されるものではない。「Ｗｉｎｄｏｗｓ（登録商標）オペレーティングシステム上でのプロトコルの実施例」と題する項では、当該プロトコルについて、Ｗｉｎｄｏｗｓ（登録商標）オペレーティングシステムに係わる実装という文脈で説明する。この説明は、特に、特定の１つの実装と、当該特定の実装に付随する設計上の配慮の一部を例示することを意図したものである。
【発明を実施するための最良の形態】
【００１１】
アプリケーションからダウンストリームコンポーネントに至るセキュアチャネルの確立
のためのプロトコル
以下の説明では、アプリケーションが、媒体コンテンツ出力を保護するために、複数の可能なコンテンツ保護技術のうちのいずれの技法を適用すべきか、さらに、それらのコンテンツ保護技術のうちの少なくとも一部をどのように適用すべきかを通知することができるように、アプリケーションから様々なダウンストリームコンポーネントまでのセキュアシグナリング機構(secure signaling mechanism)を提供するために使用可能な、少なくともいくつかの実施形態について説明する。さらに、様々なタイプのコンテンツ保護(content protection)をイネーブルにし、設定(configure)するという概念(notion)に基づき、実施形態のうちの少なくとも一部は、媒体出力(media output)を保護するために使用されるコンテンツ保護技術(content protection technology)の「タイプ(type)」について問わない。これは、本明細書に記載のシステムおよびプロトコルが、多くの異なるタイプの現在および将来のコンテンツ保護技術に柔軟に適応可能であり、それらの技法と共に使用されるという点で有利である。
【００１２】
本発明のプロトコルが使用可能な典型的なシステムの概要の一例として、民生用デバイス(consumer device)２００の形態のコンピューティングシステムを示す図２を検討してみる。民生用デバイス２００は、保護媒体コンテンツをレンダリングするために使用可能な任意の適合するタイプの民生用デバイスとすることができる。そのような装置の一例は、パーソナルコンピュータである。他のタイプの装置としては、パーソナルビデオレコーダ（ＰＶＲ）装置、デジタルビデオレコーダ（ＤＶＲ）装置などがある。
【００１３】
民生用デバイス２００は、保護媒体コンテンツ供給源(protected media content source)から保護媒体コンテンツを入手することができるプレイバックアプリケーション(playback application)２０２と、保護媒体コンテンツの処理を容易にするシステムソフトウェア２０４と、処理された媒体コンテンツを、媒体コンテンツがユーザのためにレンダリング(render)される関連出力デバイス(associated output device)２１２に何らかのタイプの物理コネクタ(physical connector)２１０を介して供給するハードウェア２０８（ビデオカードなど）にインターフェースするために使用される、ドライバソフトウェア(driver software)２０６（または関連付けられたハードウェアのソフトウェア表現）とを備える。出力デバイスの例としては、前述のように、ディスプレイデバイスあるいはスピーカがある。
【００１４】
プレイバックアプリケーションと物理コネクタとの間の連鎖(chain)を構成することができる多種多様なものがあることが当業者なら間違いなくので、本明細書の説明、少なくとも本項の説明では、プレイバックアプリケーション、システムソフト、ドライバソフトウェア、およびハードウェアの「タイプ」は特に関係がない。したがって、以下の説明は特定の１つのタイプのシステムに限定されることを意図したものではない。
【００１５】
ここで例示し、説明する実施形態では、物理コネクタ２１０と出力デバイス２１２との間で媒体コンテンツを保護するために使用することができるコンテンツ保護技術は様々ある。例えば、当業者ならわかるように、様々なコンテンツ保護のタイプとしては、アナログコンテンツ保護（Ａｎａｌｏｇ  Ｃｏｎｔｅｎｔ  Ｐｒｏｔｅｃｔｉｏｎ：ＡＣＰ）、コピー生成管理システム−アナログ（Ｃｏｐｙ  Ｇｅｎｅｒａｔｉｏｎ  Ｍａｎａｇｅｍｅｎｔ  Ｓｙｓｔｅｍ−Ａｎａｌｏｇ：ＣＧＭＳ−Ａ）、および高帯域デジタルコンテンツ保護（Ｈｉｇｈ−ｂａｎｄｗｉｄｔｈ  Ｄｉｇｉｔａｌ  Ｃｏｎｔｅｎｔ  Ｐｒｏｔｅｃｔｉｏｎ：ＨＤＣＰ）などがある。本図では、これらの様々なタイプのコンテンツ保護技術(content protection technology)が２１４に示してある。
【００１６】
本明細書に記載の実施形態によると、アプリケーション２０２と、１つまたは複数のダウンストリームコンポーネント(downstream component)との間にセキュアリンク(secure link)またはセキュアチャネルが確立される。図の例では、２本の異なるセキュアチャネルが示されているが、いずれかのタイプの１本のチャネルを実現すればよい。具体的には、一実施形態では、アプリケーション２０２とドライバ２０６との間にセキュア通信チャネル２１６が確立される。他の実施形態では、アプリケーション２０２とハードウェア２０８との間にセキュアチャネル２１８が確立される。
【００１７】
ここで例示し、説明する実施形態では、チャネル２１６は主としてアプリケーションとドライバとの通信に使用することができる。そのような通信としては、アプリケーションとドライバとの間の「コマンド(command)」、「ステータスリクエスト(status request)」、およびそれに対応する「状況(status)」などを含めることができる。チャネル２１８は、この種の通信だけでなく、オーディオデータやビデオデータなどの実際の媒体データをハードウェアに供給するためにも使用することができる。
【００１８】
本明細書の文脈では、「コマンド(command)」とは命令(instruction)のことであり、他にも特徴があるなかで特に以下の特徴を備えることができる。まず、コマンドは、ハードウェア２０８の構成に変更を加え、またはその他の方法で影響を与えることができる。これに代えて、またはこれに加えて、コマンドは、媒体コンテンツを何らかの特定の方法で処理するようにハードウェアに指示することができる。
【００１９】
「ステータスリクエスト」とは、ハードウェアから２組の情報を実質的に取り出すことができる。第１に、ステータスリクエストは、アプリケーションからダウンストリームコンポーネントに送られたコマンドに関する情報を取り出すことができる。例えば、アプリケーションが何らかのタスク、例えば特定のタイプのコンテンツ保護技術の設定などを実行するコマンドを送った場合、そのタスクが実行されたか否かに関する情報を、対応するステータスリクエストによって取り出すことができる。第２に、ステータスリクエストは、コマンドが送られたか否かには必ずしも関連しない情報を取り出すことができる。例えば、ステータスリクエストは、特定の装置に固有のものである場合もある追加のハードウェア構成情報、例えば使用されている物理コネクタのタイプを取り出すことができる。このようなステータスリクエストは、特定の物理コネクタのためのハードウェアによってどのコンテンツ保護技術がサポートされているかを特定するためにも使用することができる。例えば、物理コネクタはＤＶＩコネクタとすることができるが、グラフィックスハードウェアにＨＤＣＰサポートがない場合がある。したがって、アプリケーションは、ビデオデータのダウンサンプル版または低解像度版を再生するか、または、場合によってはビデオデータをまったく再生しないという高度な選択を行うことができる。
【００２０】
セキュアチャネルの確立
本明細書で例示し、説明する実施形態では、一方向信頼モデル(one-way trust model)および鍵トランスポートプロトコル(key transport protocol)を使用することにより、通信連鎖(communication chain)の２つの終端(endpoint)間の信頼(trust)を確立(establish)する。当業者ならわかるように、鍵トランスポートの使用にはいくつかの利点がある。第１に、鍵トランスポートでは、エントロピの生成は信頼を確立する側に任せられる。この場合はアプリケーション２０２に任せられる。第２に、鍵トランスポートでは、「パススルー(pass through)」と呼ばれるものの実行が可能になる。パススルーによって、グラフィックスハードウェアまでの連鎖全体を通してコンテンツデータの暗号化を可能にすることができる。当業者ならわかるように、これによって、グラフィックスハードウェアはコンテンツデータを解読し、コンテンツデータを対応するサーフェスに復号し、コンテンツデータを処理して表示部に送ることができる。
【００２１】
チャネル２１６を例にとると、例えば公開鍵基盤（Public Key Infrastructure：ＰＫＩ）技法(technique)を使用することにより、アプリケーション２０２とドライバソフトウェア２０６との間に一方向認証チャネル(one-way authenticated channel)が確立される。具体的には、この例では、アプリケーション２０２とドライバソフトウェア２０６との間にデータ保全鍵(data integrity key)の形態のチャネル鍵(channel key)が設定される。チャネル鍵が設定された後は、コマンドとステータスメッセージを暗号化されていない状態で受け渡しすることができ、データ保全鍵を使用してメッセージ認証コード(message authentication code)すなわちＭＡＣを作成することができる。
【００２２】
例えば、図３と共に以下の例について述べる。ダウンストリームコンポーネントとの信頼(trust)を確立するために、アプリケーション２０２はまず、ドライバソフトウェア２０６を呼び出し、ドライバソフトウェアから、ハードウェア２０８（図２）に関連付けられた乱数ｒＧＨとデジタル証明書(digital certificate)ＣｅｒｔＧＨとを受け取る。アプリケーション２０２がデジタル証明書ＣｅｒｔＧＨを受け取ると、アプリケーションは証明書を処理してデジタル証明書上の署名が信用できる実体によって付与されたものであることを検証し、ドライバソフトウェア２０６（チャネル２１６使用の場合）またはグラフィクスハードウェア２０８（チャネル２１８使用の場合）の公開鍵（ＰＧＨ）を取り出す。これで、公開鍵ＰＧＨはアプリケーションによってデータを暗号化するために使用することができ、当該データは、ドライバソフトウェアまたはグラフィクスハードウェアによって安全に保管されている対応する秘密鍵によってのみ解読されることができる。以上の処理によって、アプリケーションとドライバソフトウェアの間に信頼が確立される。
【００２３】
信頼(trust)が確立(establish)されると、アプリケーションは鍵トランスポート(key transport)を設定(set up)することができる。この例では、アプリケーション２０２は、ドライバソフトウェアによって提供された乱数ｒＧＨと、データ保全鍵ｋＤＩ（セッション鍵(session key)とも呼ぶ）と、ランダム開始ステータスシーケンス番号(random starting status sequence number)（ｓｔａｔｕｓ＿ｓｔａｒｔ）と、ランダム開始コマンドシーケンス番号（ｃｏｍｍａｎｄ＿ｓｔａｒｔ）とを連結(concatenate)し、ドライバソフトウェアの公開鍵ＰＧＨを使用してこれらの値の連結(concatenation)を暗号化(encrypt)し、暗号化されたデータ(encrypted data)をドライバソフトウェア２０６に送る。以上の処理によって、アプリケーションとドライバソフトウェアとの間で使用されるセッション鍵が設定される。ランダム開始ステータスシーケンス番号（ｓｔａｔｕｓ＿ｓｔａｒｔ）とランダム開始コマンドシーケンス番号（ｃｏｍｍａｎｄ＿ｓｔａｒｔ）は、特定のメッセージが失われた場合に、当該メッセージがステータスリクエストまたは報告された状況（開始ステータスシーケンス番号の場合）であるか、コマンド（開始コマンドシーケンス番号の場合）であるかを確認するために使用され、所定のメッセージ受信側はそのことを特定することができる。具体的には、アプリケーションによってコマンドが送られるたびに、ランダム開始コマンドシーケンス番号が１ずつ増分される。同様に、ステータスメッセージが送られるたびに、送信側は、開始ステータスシーケンス番号を１ずつ増分する。受信側では、メッセージの受信先が、シーケンス番号が順番に現れているか否かを調べるだけで、メッセージが失われていないか否かを確認することができる。欠落したシーケンス番号がある場合、それに関連付けられたメッセージが失われており、適切な処置をとることができる。このようにして、ランダム開始シーケンス番号によってメッセージの保全性と順序を確保することができる。
【００２４】
一実施例では、上記の処理として以下の表に示す値と内容を使用することができる。
【００２５】
【表１】
0004809616.tif 000002
【００２６】
処理のこの時点で、アプリケーションとドライバソフトウェアとの間にセキュアチャネルが確立される。次に、本発明のプロトコルの２つの部分であるコマンドプロトコル(command protocol)とステータスプロトコル(status protocol)とについて説明する。
【００２７】
コマンドプロトコル
本プロトコルのコマンド部分は、ハードウェア２０８（図２）などのシステムのハードウェアがアプリケーションによって指示されてオンになることを可能にし、場合によっては、ＨＤＣＰやＣＧＭＳ−Ａなどの特定のコンテンツ保護技術を設定することを可能にする。ここで例示し、説明する実施形態では、コマンドメッセージは、データセクション(data section)とメッセージ認証コードセクション(message authentication code section)またはＭＡＣセクション(MAC section)の２つの部分を有するエンベロープ(envelope)に入れられる。
【００２８】
ここで例示し、説明する実施形態では、コマンドメッセージのデータセクションには、コマンドとそれに関連付けられたコマンドシーケンス番号が入れられる。メッセージ認証コードセクションまたはＭＡＣセクションには、コマンドとそれに関連付けられたコマンドシーケンス番号との、鍵付きハッシュ(keyed hash)とみなせるものが入れられる。鍵付きハッシュを生成するために使用される鍵は、上述のデータ保全鍵ｋＤＩである。
【００２９】
一例として、図４を説明する。図４には、アプリケーション２０２がドライバソフトウェア２０６に以下の形式のコマンドメッセージを送る様子が示されている。
【００３０】
Ｃｏｍｍａｎｄ，ＭＡＣｋＤＩ（Ｃｏｍｍａｎｄ）
ここで、メッセージの「Ｃｏｍｍａｎｄ」部(portion)は、アプリケーションからの関連付けられたコマンドだけなく、関連付けられたコマンドシーケンス番号も含む。メッセージの「ＭＡＣｋＤＩ（Ｃｏｍｍａｎｄ）」部は、アプリケーションによって計算された「Ｃｏｍｍａｎｄ」部のＭＡＣを含む。ドライバソフトウェア２０６は、コマンドメッセージを受け取ると、取り決められたセッション鍵ｋＤＩを使用してメッセージのコマンド部に対してＭＡＣアルゴリズムを実行することができる。コマンドメッセージのコマンド部に対してＭＡＣアルゴリズムが実行された後は、ドライバソフトウェアはその値をコマンドメッセージで受け取ったＭＡＣ値と比較することができる。２つの値が合致する場合、コマンドメッセージの保全性(integrity)が確立されている。
【００３１】
一実施例では、上記の処理で以下の表に示す値と内容を使用することができる。
【００３２】
【表２】
0004809616.tif 000003
【００３３】
ステータスプロトコル
ここで例示し、説明する実施形態では、ステータスメッセージは、データセクションとメッセージ認証コードセクションまたはＭＡＣセクションの２つの部分を有するエンベロープに入れられる。この実施例では、メッセージの送信側は、セッション鍵ｋＤＩとそれに対応するＭＡＣアルゴリズムとを使用して状況データのＭＡＣを計算する。
【００３４】
ステータスプロトコルをどのように実現(implement)するのかを示す一例として、図５を説明する。図５では、アプリケーション２０２が以下の形式でステータス情報(status information)の要求を行う。
【００３５】
ｒＡＰＰ，ＳｔａｔｕｓＲｅｑｕｅｓｔ
ここで、ｒＡＰＰはアプリケーションによって生成された乱数であり、「ＳｔａｔｕｓＲｅｑｕｅｓｔ」はステータス情報を求める実際の要求である。ドライバソフトウェア２０６は、アプリケーションからステータスリクエストを受け取るとそれに応答して、ステータス情報が適切であるか否かを確認し、そのステータス情報を適切な状況シーケンス番号と共にエンベロープのデータセクションに入れる。さらに、ドライバソフトウェアは、アプリケーションから提供された乱数と共にステータス情報のＭＡＣも計算する。次に、以下の形式でステータスメッセージがアプリケーションに戻される。
【００３６】
ｒＡＰＰ，Ｓｔａｔｕｓ，ＭＡＣｋＤＩ（ｒＡＰＰ，Ｓｔａｔｕｓ）
ここで「Ｓｔａｔｕｓ」は、ステータス情報だけでなく状況シーケンス番号も含む。メッセージのＭＡＣｋＤＩ（ｒＡＰＰ，Ｓｔａｔｕｓ）部は、アプリケーションによって提供された乱数とステータス情報のＭＡＣを含む。アプリケーションは、このステータスメッセージを受け取ると、乱数とステータス情報とに対してＭＡＣアルゴリズムを実行することによって乱数とステータス情報のＭＡＣを計算することができ、その後、その値をメッセージのＭＡＣｋＤＩ（ｒＡＰＰ，Ｓｔａｔｕｓ）部内の値と比較することができる。これにより、アプリケーションはステータスメッセージが正当なものであることを確認することができる。次に、アプリケーションはメッセージの内容を使用することにより、ステータスメッセージが正しい順序になっていることを（シーケンス番号によって）検証することができ、ステータス情報がアプリケーションによって前に送られたステータスリクエストに関するものであることを（乱数ｒＡＰＰによって）確認することができる。
【００３７】
一実施例では、上記の処理で以下の表に示す値と内容を使用することができる。
【００３８】
【表３】
0004809616.tif 000004
【００３９】
方法の例
図６は、一実施形態による方法のステップを示す。この方法は、任意の適合するハードウェア、ソフトウェア、ファームウェア、またはこれらの組合せと共に実装することができる。さらに、ソフトウェア実装によっては、この方法の態様を、１つまたは複数のコンピュータ可読媒体上に存在し、実行されて本明細書に記載の方法を実行するコンピュータ可読命令として実施することができる。この実施例では、例示の方法は２つの部分に分けられ、一方を「アプリケーション」と標示(label)し、他方を「ダウンストリームコンポーネント」と標示する。これは、以下に説明する動作をいずれの部分が実行するかを示すためである。したがって、「アプリケーション」という標示で記載する動作はアプリケーションによって実行され、「ダウンストリームコンポーネント」という標示で記載する動作は、アプリケーションの下流にあるコンポーネントによって実行される。一実施例では、ダウンストリームコンポーネントは、媒体データを処理するドライバソフトウェア、または対応するハードウェアのソフトウェア表現とすることができる。他の実施例では、ダウンストリームコンポーネントはハードウェアコンポーネント自体とすることができる。
【００４０】
以下で説明する方法を実施することができるシステムの一例を、前述の図２〜図５と共に例示し、説明する。特許請求対象の主旨および範囲から逸脱することなく、他のシステムも使用可能であることを理解されたい。
【００４１】
ステップ６００において、プレイバックアプリケーションから、下流のコンポーネントに関連付けられた公開鍵を確認する。これがどのように行われることができるかを示す例は、上記に記載されている。ステップ６０２において、公開鍵を使用することにより、プレイバックアプリケーションとダウンストリームコンポーネントとの間にセキュアチャネルを確立する。ステップ６００とステップ６０２とが組み合わさって、プレイバックアプリケーションとダウンストリームコンポーネントとの間に信頼を確立する。この信頼をどように確立することができるかを示す一例は、図３と共に前述されている。当然ながら、特許請求対象の主旨および範囲から逸脱することなく、他の方法も使用可能である。
【００４２】
ステップ６０４において、セキュアチャネルを使用することにより、ダウンストリームコンポーネントにコマンドメッセージを送る。任意の適合するコマンドメッセージ構造を使用することができるが、一例は図４と共に上記で示してある。さらに、任意の適合および／または適切なタイプのコマンドを、アプリケーションからダウンストリームコンポーネントに送ることができる。一実施例では、送ることができるコマンドは、システムによって処理される媒体コンテンツまたはデータを保護するために特定のタイプのコンテンツ保護技術をイネーブルにするようにダウンストリームコンポーネントに指示する。
【００４３】
ステップ６０６において、セキュアチャネルを介してコマンドメッセージを受け取る。このステップは、コマンドメッセージが送られるダウンストリームコンポーネントによって行われる。次に、ステップ６０８において、コマンドメッセージの保全性を検証する。コマンドメッセージの保全性を検証するために任意の適合する方法を使用することができるが、一例は図４と共に上記に示すものである。コマンドメッセージの保全性が検証されると、ステップ６１０において、コマンドメッセージに含まれる対応するコマンドを実行する。
【００４４】
ステップ６１２において、セキュアチャネルを使用してダウンストリームコンポーネントにステータスリクエストを送る。任意の適合するタイプのステータスリクエスト構造を使用することができるが、一例は図５と共に上記で示したものである。ステップ６１４において、セキュアチャネルを介してステータスリクエストを受け取り、ステップ６１６において、それに応答してステータスメッセージを作成し、セキュアチャネルを使用してアプリケーションにそのステータスメッセージを送る。任意の適合するステータスメッセージ構造を使用することができるが、一例は図５と共に上記に示すものである。
【００４５】
ステップ６１８において、セキュアチャネルを介してステータスメッセージを受け取り、ステップ６２０でステータスメッセージの保全性を検証する。ステータスメッセージの保全性を検証するために任意の適合する方法を使用することができるが、一例は上記に示すものである。
【００４６】
Ｗｉｎｄｏｗｓ（登録商標）オペレーティングシステム上でのプロトコルの実施例
システムの概要
図７の７００は、上述のセキュアチャネルプロトコルを実施するために使用可能なシステム全体を示す。以下の説明において、本実施例のプロトコルを「証明付き出力保護プロトコル(Certified Output Protection Protocol)」または「ＣＯＰＰ」と呼ぶ。本実施例では、ストリーミング媒体用のアーキテクチャであるＭｉｃｒｏｓｏｆｔ（登録商標）ＤｉｒｅｃｔＳｈｏｗ（登録商標）を一例として使用する。当業者ならわかるように、Ｍｉｃｒｏｓｏｆｔ（登録商標）ＤｉｒｅｃｔＳｈｏｗ（登録商標）は、マルチメディアストリームの高品質の再生を行うことができ、Ａｄｖａｎｃｅｄ  Ｓｔｒｅａｍｉｎｇ  Ｆｏｒｍａｔ（ＡＳＦ）、Ｍｏｔｉｏｎ  Ｐｉｃｔｕｒｅ  Ｅｘｐｅｒｔｓ  Ｇｒｏｕｐ（ＭＰＥＧ）、Ａｕｄｉｏ−Ｖｉｄｅｏ  Ｉｎｔｅｒｌｅａｖｅｄ（ＡＶＩ）、ＭＰＥＧ  Ａｕｄｉｏ  Ｌａｙｅｒ−３、ＷＡＶファイルを含めて、広範囲の形式に対応している。
【００４７】
ストリーミングビデオおよびオーディオデータに必要なスループットを達成するために、ＤｉｒｅｃｔＳｈｏｗ（登録商標）はＭｉｃｒｏｓｏｆｔ（登録商標）ＤｉｒｅｃｔＤｒａｗ（登録商標）およびＭｉｃｒｏｓｏｆｔ（登録商標）ＤｉｒｅｃｔＳｏｕｎｄ（登録商標）を使用することにより、システムのサウンドカードおよびグラフィクスカードにデータを効率的に供給する。ＤｉｒｅｃｔＤｒａｗ（登録商標）は、当業者ならわかるように、ソフトウェア設計者がディスプレイメモリ、ハードウェアブリッタ、ハードウェアオーバレイ、およびフリッピングサーフェスを直接操作することができるようにする、ＤｉｒｅｃｔＸ（登録商標）の表示コンポーネントである。ＤｉｒｅｔｔＤｒａｗ（登録商標）は、直接３２ビットパスで、装置固有の表示機能への装置に依存しないアクセスを可能にする。Ｗｉｎｄｏｗｓ（登録商標）の６４ビット版には６４ビットパスもある。ＤｉｒｅｃｔＤｒａｗ（登録商標）は、Ｗｉｎｄｏｗｓ（登録商標）グラフィクスデバイスインターフェース（ｇｒａｐｈｉｃｓ  ｄｅｖｉｃｅ  ｉｎｔｅｒｆａｃｅ：ＧＤＩ）またはデバイスインデペンデントビットマップ（ｄｅｖｉｃｅ−ｉｎｄｅｐｅｎｄｅｎｔ  ｂｉｔｏｍａｐ：ＤＩＢ）エンジンを介さずにディスプレイカードに直接アクセスするドライバにおいて重要な機能を呼び出す。
【００４８】
ＤｉｒｅｃｔＳｈｏｗ（登録商標）では、タイムスタンプ付き媒体サンプルのマルチメディアデータをカプセル化することによって同期を実現する。多様な媒体源、形式およびハードウェアデバイスを扱うために、Ｄｉｒｅｃｔｓｈｏｗ（登録商標）は、「フィルタ」と呼ばれるオペレーティングシステムコンポーネントを組み合わせ、整合させて多様な事例に対応させることができるモジュラアーキテクチャを使用する。本実施例では、これらのフィルタを組み合わせてフィルタグラフ７０４とすることができ、このフィルタグラフ７０４は、マルチメディアデータをハードウェアデバイスによって処理させ、レンダリングさせるためにプレイバックアプリケーション７０２によって使用される。
【００４９】
この実施例において、フィルタグラフ(filter graph)７０４は、媒体コンテンツを読み取るソースフィルタ７０６と、そのコンテンツを伸張(decompress)するデコーダ７０８（例えばＷＭＶまたはＭＰＥＧ２デコーダ）とを含む。ビデオレンダリング(video rendering)コンポーネント７１０は、伸張されたコンテンツ(decompressed content)またはデータを受け取り、そのコンテンツをレンダリングするハードウェアを判断する。この特定の実施例では、ＶＭＲ７（ＤｉｒｅｃｔＸバージョン７ＳＤＫ用に作成されたＶｉｄｅｏ  Ｍｉｘｉｎｇ  Ｒｅｎｄｅｒｅｒバージョン７）とＶＭＲ９（ＤｉｒｅｃｔＸバージョン９ＳＤＫ用に作成されたＶｉｄｅｏ  Ｍｉｘｉｎｇ  Ｒｅｎｄｅｒバージョン９）コンポーネントという使用可能な２つの異なるタイプのレンダラーコンポーネントがある。
【００５０】
本実施例では、ユーザモードＤｉｒｅｃｔＤｒａｗ（登録商標）部７１２を備えるが、これは、ＤｉｒｅｃｔＤｒａｗ（登録商標）アプリケーションによってロードされ、呼び出されるシステム提供ダイナミックリンクライブラリ（ＤＬＬ）である。このコンポーネントは、当業者にはわかるように、ハードウェアエミュレーションを行い、様々なＤｉｒｅｃｔＤｒａｗ（登録商標）オブジェクトを管理し、表示メモリと表示管理サービスを提供する。
【００５１】
さらに、カーネルモードＤｉｒｅｃｔＤｒａｗ（登録商標）部７１４も備える。これは、ｗｉｎ３２ｋ．ｓｙｓと一体の一部である。カーネルモード部７１４は、カーネルモードディスプレイドライバによってロードされるシステム提供グラフィクスエンジンである。このコンポーネントは、ドライバのためのパラメータ検証を行い、それによってより堅固なドライバの実施を容易にする。ＤｉｒｅｃｔＤｒａｗ（登録商標）グラフィクスドライバ７１６も備える。これは、典型的にはサードパーティハードウェア供給業者によって実施される。
【００５２】
動作時、保護コンテンツは一般に、それに関連付けられた何らかのポリシーのセットを有する。これらのポリシーによって、関連付けられたコンテンツがレンダリングされる際に使用されるコンテンツ保護のタイプおよびレベルを設定することができる。例えば、コンテンツがＤＶＩコネクタを介して再生出力される場合、ポリシーによって、ＨＤＣＰをイネーブルにする必要があることを設定したり、またはコンテンツが再生されないように設定することができる。
【００５３】
本実施例では、アプリケーション７０２はコンテンツに関連付けられたポリシーを認識している。実際には、ソースフィルタ７０６が、コンテンツに関連付けられたポリシーを特定し、アプリケーションに通知する機能を果たすコンポーネントを含むことができる。
【００５４】
ユーザモードアプリケーションプログラムインターフェース（ＡＰＩ）
ポリシー(policy)が抽出(extract)され、ポリシーの意味が特定されると、システム７００は、まず、当該特定のシステムでポリシーが実施可能であるか否かを判断する。これは、この特定の実施例では、ビデオレンダリングコンポーネント７１０によってエクスポーズ(expose)されるＩＡＭＣｅｒｔｉｆｉｅｄＯｕｔｐｕｔＰｒｏｔｅｃｔｉｏｎと呼ぶユーザモードアプリケーションプログラムインターフェース（ＡＰＩ）を介して行われる。一実施形態によると、ＩＡＭＣｅｒｔｉｆｉｅｄＯｕｔｐｕｔＰｒｏｔｅｃｔｉｏｎインターフェースは、アプリケーションによって呼び出されることができる以下のメソッドから成る。
【００５５】
【表４】
0004809616.tif 000005
【００５６】
【表５】
0004809616.tif 000006
【００５７】
【表６】
0004809616.tif 000007
【００５８】
上記の例において、ＡＭＣＯＰＰＣｏｍｍａｎｄ構造は、アプリケーションがダウンストリームコンポーネントにコマンドを送るために使用するデータ構造であり、図４に示すような交換で使用される。ＡＭＣＯＰＰＳｔａｔｕｓＩｎｐｕｔ構造は、アプリケーションがステータスリクエストを行うために使用するデータ構造であり、図５の左側に示すもののような交換で使用される。ＡＭＣＯＰＰＳｔａｔｕｓＯｕｔｐｕｔ構造は、グラフィクスドライバがアプリケーションにステータス情報を返すために使用するデータ構造であり、図５の右側に示すもののような交換で使用される。
【００５９】
カーネルモードＤＤＩ（ＤＸ−ＶＡ）
ＤＸ−ＶＡ証明付き出力保護プロトコル（Ｃｅｒｔｉｆｉｅｄ  Ｏｕｔｐｕｔ  Ｐｒｏｔｅｃｔｉｏｎ  Ｐｒｏｔｏｃｏｌ：ＣＯＰＰ）は、プレイバックアプリケーション７０２などのユーザモードアプリケーションからグラフィクスドライバ７１６などのドライバにコマンドを渡し、ドライバからユーザモードアプリケーションに状況を返す手段となる。前述のように、コマンドと状況が流れるチャネルは保護されている。
【００６０】
この特定の実施態様では、コンテンツ出力保護プロトコルは、以下に詳述するＤＸ−ＶＡ  ＣＯＰＰデバイスを使用する。以下の説明では、以下の用語を使用する。
【００６１】
・  ビデオストリーム：ビデオストリームは、表示ビデオフレームを含む主要イメージデータである。ビデオストリームからの画素は常に透明であり、ピクセル単位のアルファデータを含まない。
【００６２】
・  ビデオサブストリーム：ビデオサブストリームは、合成ビデオフレームの表示の前にビデオストリームのサンプルと合成する必要がある補助イメージデータのチャネルである。ビデオサブストリームの例としては、ＮＴＳＣクローズドキャプションイメージ、ＤＶＤサブピクチャイメージ、ＰＡＬテレテックスイメージなどがある。ビデオサブストリームの他の特性は、限られた色範囲とピクセル単位アルファ情報を含むことである。
【００６３】
・  ビデオセッション：ビデオセッションは、ビデオストリームと、場合によっては、コンピュータに接続された出力デバイス上に表示される前にビデオストリームと組み合わされる１つまたは複数のビデオサブストリームから成る。コンピュータ上では一度に複数のアクティブなビデオセッションが存在することができ、また、１つのプロセス内で複数のアクティブなビデオセッションが存在することができる。
【００６４】
・  ＤＸ−ＶＡ  ＣＯＰＰデバイス：コンテンツ出力保護プロトコルを介したコマンドとステータスリクエストの受領をサポートする新規なＤＸ−ＶＡデバイス。
【００６５】
・  コネクタ：グラフィクスハードウェアとディスプレイとの物理出力接続。
【００６６】
・  保護タイプ：コネクタを介して受け渡しされる信号に適用することができる保護のタイプ。１つのコネクタに複数のタイプの保護を適用することができる。
【００６７】
・  保護レベル：コネクタを介して受け渡しされる信号に適用することができる保護のレベル。この値は保護タイプに依存する。例えばＨＤＣＰのように、保護レベルが「オン」と「オフ」の２タイプしかない保護タイプもある。
【００６８】
設計の概要
本実施形態によると、ＤＸ−ＶＡ  ＣＯＰＰデバイスと呼ぶ単一のコンポーネントが各ビデオセッションごとに作成される。図７の例では、ドライバ７１６と共に２つの例示のＤＸ−ＶＡ  ＣＯＰＰデバイスが図示されている。ＤＸ−ＶＡ  ＣＯＰＰデバイスは、ＣＯＰＰコマンドおよびステータスリクエストのエンドポイントである。さらに、ＤＸ−ＶＡ  ＣＯＰＰデバイスは、物理コネクタの保護設定を仮想化することができる。１つの物理コネクタが複数のコンテンツ保護タイプをサポートすることもできる。例えば、Ｓ−Ｖｉｄｅｏコネクタはアナログコンテンツ保護と、ＣＧＭＳ−Ａ  Ｌｉｎｅ２０保護およびＣＧＭＳ−Ａ  Ｌｉｎｅ２１保護をサポートすることができる。ＣＯＰＰデバイスがドライバによってどのように実施可能であるかを示す一例を、本明細書の後掲のＣＯＰＰサンプルデバイスドライバコードによって示す。
【００６９】
図示および説明する本実施形態では、各ＤＸ−ＶＡ  ＣＯＰＰデバイスは、コンピュータ上で複数のビデオセッションがアクティブになっているときに適切に動作するように構成される。この場合、異なるプロセスがＣＯＰＰを介して出力ディスプレイアダプタの設定を試みるため、ドライバ７１６はＣＯＰＰ  ＤＸ−ＶＡでデバイスの複数のインスタンスを作成するように求められる。本実施例では、ドライバ７１６によってＤＸ−ＶＡ  ＣＯＰＰデバイスの２つのインスタンスが作成されている。
【００７０】
ローカル(local)およびグローバル(global)参照カウント(reference counts)
ドライバ７１６は、コンテンツ保護をサポートする物理コネクタごとに、各タイプおよび各レベルのグローバル参照カウントを維持する必要がある。ここで例示し、説明する本実施形態では、ドライバ７１６はこのグローバルステートを維持するグローバルステート部(global state component)を備える。
【００７１】
ビデオセッションのためにＣＯＰＰ  ＤＸ−ＶＡデバイスが作成される場合、当該デバイスは各保護タイプの各保護レベルについてローカル参照カウントを含む必要がある。これは、各デバイス内部の現行保護レベル部によって示される。保護タイプのデフォルトレベルカウンタは値１に設定されなければならず、当該タイプの他のすべての保護レベルカウンタは値ゼロに設定されなければならない。
【００７２】
ビデオセッションが特定の保護タイプに新しい保護レベルを設定すると、現行保護レベルの参照カウントが減分され、新しい保護レベルの参照カウントが増分される。これに対応する変更が、グローバル参照レベルカウンタにも加えられる。
【００７３】
グローバルレベルカウンタ(global level counter)のいずれかが変化するたびに、ドライバは当該コネクタのすべてのカウンタを調べ、保護レベルが、ゼロより大きい値の最高レベルカウンタに対応するレベルに確実に設定されるようにする必要がある。本実施例では、１つの関連付けられたコネクタについて、レベルＡとレベルＢの２つの異なる保護レベルがある。グローバルステート部は、当該物理コネクタにレベルＢ保護が適用されることを示していることに注目されたい。したがって、当該物理コネクタに適用可能な保護レベルのうちでレベルＢがより高い。ＤＸ−ＶＡ  ＣＯＰＰデバイス２が終了した場合、グローバルステート部は、物理コネクタに保護レベルＡを適用する。これがどのようにして行われるかを、後で例示するコードサンプルで示す。
【００７４】
グローバル参照カウンタがゼロより大きい間は、出力コネクタにコンテンツ保護を適用する必要がある。グローバル参照カウンタがゼロになると直ちに、出力コネクタのコンテンツ保護が解除されなければならない。ドライバがＤｅｓｔｒｏｙＤｅｖｉｃｅ呼び出しを受け取るたびに、デバイスのローカル参照カウンタの現行レベル分だけグローバル参照カウンタが減分されなければならない。コネクタ保護は、当該コネクタのグローバル参照カウンタがゼロになった場合にのみ解除されなければならない。
【００７５】
ＤｅｓｔｒｏｙＤｅｖｉｃｅは、デバイスがゼロより大きいローカル参照カウンタを有する間、呼び出し可能であることに留意されたい。その一例は、ユーザモードプロセスが異常終了した場合である。
【００７６】
ビデオセッションの初期設定(initialization)
ここで例示し、記載する本実施形態では、ビデオセッションは特定の物理出力コネクタと結びつけられる。ビデオセッションは、ディスプレイドライバレベルで、以下のステップによって初期設定される。
【００７７】
・  ＧｅｔＭｏＣｏｍｐＧｕｉｄｓが呼び出されて、ドライバが出力コネクタについてＤＸ−ＶＡ  ＣＯＰＰデバイスをサポートするか否かを判断する。
【００７８】
・  ドライバが出力コネクタについてＤＸ−ＶＡ  ＣＯＰＰデバイスをサポートしないとすれば、ＣｒｅａｔｅＭｏＣｏｍｐが呼び出され、ＤＸ−ＶＡ  ＣＯＰＰデバイスを作成する。
【００７９】
・  ＲｅｎｄｅｒＭｏＣｏｍｐがＤＸＶＡ＿ＣＯＰＰＧｅｔＣｅｒｔｉｆｉｃａｔｅＬｅｎｇｔｈＦｎＣｏｄｅ関数コードと共に呼び出され、当該セッションに使用されるべき可変長グラフィクスハードウェア証明書の長さが決定される。
【００８０】
・  ＲｅｎｄｅｒＭｏＣｏｍｐがＤＸＶＡ＿ＣＯＰＰＫｅｙＥｘｃｈａｎｇｅＦｎＣｏｄｅ関数コードと共に呼び出され、ドライバにビデオセッションアプリケーション証明証を渡す。ドライバは、１２８ビットの秘密鍵と、その可変長グラフィクスハードウェア証明書のコピーを返す。
【００８１】
・  最後に、ＲｅｎｄｅｒＭｏＣｏｍｐがＤＸＶＡ＿ＣＯＰＰＳｅｑｕｅｎｃｅＳｔａｒｔＦｎＣｏｄｅ関数コードと共に呼び出され、ビデオセッションが３２ビットのコマンドシーケンス開始コードおよび３２ビットの状況シーケンス開始コードで開始されたことを示す。
【００８２】
個々のＤＸ−ＶＡＲｅｎｄｅｒＭｏＣｏｍｐ関数コードの詳細を、以下に示す。
【００８３】
デバイス喪失条件の処理(handling device lost condition)
特定のビデオセッションのために出力コンテンツ保護(output content protection)がイネーブル(enable)になっているときに、以下の条件によってドライバのＤｅｓｔｒｏｙＭｏＣｏｍｐエントリポイントが呼び出される。
【００８４】
・  表示モードの変化
・  Ｗｉｎｄｏｗｓ（登録商標）デスクトップへのモニタの着脱
・  全画面ＤＯＳボックスになる場合
・  ＤＤｒａｗまたはＤ３Ｄ排他モードアプリケーションの開始
・  ファーストユーザスイッチング(fast user switching)
・  Ｗｉｎｄｏｗｓ（登録商標）デスクトップへのモニタの追加または削除
・  ワークステーションのロックまたはＷｉｎｄｏｗｓ（登録商標）ＸＰプロフェッショナル版上でのＡｌｔ−Ｃｔｒｌ−Ｄｅｌキーの押下
・  「リモートデスクトップ接続(remote desktop connection)」によるワークステーションへの接続
・  節電モード、例えば「サスペンド(suspend)」または「ハイバネート(hibernate)」に入る場合
・  予期せぬアプリケーション終了、例えば「ページ障害(page fault)」
これが起こると、ドライバは、破棄されるデバイスの現行ローカル保護レベルカウント分だけグローバル保護レベルカウントを減分する必要がある。変更されたグローバル保護レベルは検査される必要があり、出力コネクタに適用された保護はそれに応じて調整されなければならない。
【００８５】
ＤＸ−ＶＡコマンド
以下では、グラフィクスドライバ、具体的には個々のＤＸ−ＶＡ  ＣＯＰＰデバイスによってサポートされるいくつかのコマンドまたは関数について説明する。
【００８６】
ＣＯＰＰＯｐｅｎＶｉｄｅｏＳｅｓｓｉｏｎ
この関数は、特定のビデオセッションのために使用されるＣＯＰＰ  ＤＸ−ＶＡデバイスを初期設定する。
【００８７】
【表７】
0004809616.tif 000008
【００８８】
ＣＯＰＰＣｌｏｓｅＶｉｄｅｏＳｅｓｓｉｏｎ
この関数は、ビデオセッションに使用されているＣＯＰＰ  ＤＸ−ＶＡデバイスを終了させる。
【００８９】
【表８】
0004809616.tif 000009
【００９０】
ビデオセッションによって適用されている出力保護がある間、この関数が呼び出されることが可能である。ドライバは、当該ＤＸ−ＶＡ  ＣＯＰＰデバイスの保護設定を解除し、それに応じて大域保護設定を調整する必要がある。
【００９１】
ＣＯＰＰＧｅｔＣｅｒｔｉｆｉｃａｔｅＬｅｎｇｔｈ
これは、新たに作成されたＣＯＰＰ  ＤＸ−ＶＡデバイスが受け取る最初の関数呼び出しである。これは、ビデオレンダラーコンポーネント７１０が、グラフィクスハードウェアによって使用されている証明書のバイト単位の長さを問い合わせるために使用される。ドライバは、ＤＤ＿ＲＥＮＤＥＲＭＯＣＯＭＰＤＡＴＡ構造のｌｐＯｕｔｐｕｔＤａｔａフィールドで正しい長さを返さなければならない。
【００９２】
【表９】
0004809616.tif 000010
【００９３】
ＣＯＰＰＫｅｙＥｘｃｈａｎｇｅ
これは、新たに作成されたＣＯＰＰ  ＤＸ−ＶＡデバイスが２番目に受け取る関数呼び出しである。ドライバは、グラフィクスハードウェアの可変長デジタル証明書を返さなければならない。ＤＤ＿ＲＥＮＤＥＲＭＯＣＯＭＰＤＡＴＡ構造のｌｐＯｕｔＤａｔａフィールドが、ＤＸＶＡ＿ＣＯＰＰＫｅｙＥｘｃｈａｎｇｅＯｕｔｐｕｔ構造を指す。ＤＸＶＡ＿ＣＯＰＰＶａｒｉａｂｌｅＬｅｎｇｔｈＤａｔａフィールドに、前のＣＯＰＰＧｅｔＣｅｒｔｉｆｉｃａｔｅＬｅｎｇｔｈ  ＤＸＶＡコマンドで示された証明書の所要スペースが入れられる。
【００９４】
【表１０】
0004809616.tif 000011
【００９５】
【表１１】
0004809616.tif 000012
【００９６】
ＣＯＰＰＳｅｑｕｅｎｃｅＳｔａｒｔ
これは、ＤＸ−ＶＡ  ＣＯＰＰデバイスが受け取る３番目の関数呼び出しである。ドライバは、グラフィックハードウェアの公開鍵で暗号化された、１２８ビットのランダムデータ保全セッション鍵と、３２ビットのランダム開始ステータスシーケンス番号と、３２ビットのランダム開始コマンドシーケンス番号との連結(concatenation)を受け取る。ドライバは、ＣＯＰＰＫｅｙＥｘｃｈａｎｇｅ関数呼び出しを受け取る前にこの関数呼び出しを受け取った場合、または後続のＣＯＰＰＳｅｑｕｅｎｃｅＳｔａｒｔ呼び出しを受け取った場合、Ｅ＿ＵＮＥＸＰＥＣＴＥＤを返さなければならない。
【００９７】
【表１２】
0004809616.tif 000013
【００９８】
ＣＯＰＰＣｏｍｍａｎｄ
ＣＯＰＰコマンドは、ＤＸ−ＶＡ  ＣＯＰＰデバイスに関連付けられた物理コネクタの保護レベルを変更するビデオセッションからの命令を含むことができる。ドライバは、前述のように、すべて同じ物理コネクタを介するコンテンツを再生する複数のビデオセッションをサポートすることができなければならない。
【００９９】
【表１３】
0004809616.tif 000014
【０１００】
【表１４】
0004809616.tif 000015
【０１０１】
ドライバは、ＣＯＰＰＫｅｙＥｘｃｈａｎｇｅ関数呼び出しまたはＣＯＰＰＳｅｑｕｅｎｃｅＳｔａｒｔ関数呼び出しを受け取る前にこの関数呼び出しを受け取った場合、Ｅ＿ＵＮＥＸＰＥＣＴＥＤを返さなければならない。また、ドライバは、ドライバに渡されたパラメータが、使用されている所定の物理コネクタにとって有効であることを確認する必要がある。ＣＯＰＰＣｏｍｍａｎｄで渡されたパラメータのうちの１つまたは複数のパラメータが有効でない場合、ドライバは、Ｅ＿ＩＮＶＡＬＩＤＡＲＧを返さなければならない。
【０１０２】
以下の表に、本実施形態によりドライバが受け取ることができるＤＸ−ＶＡ  ＣＯＰＰコマンドのセットを示す。
【０１０３】
【表１５】
0004809616.tif 000016
【０１０４】
ＣＯＰＰＱｕｅｒｙＳｔａｔｕｓ
ＣＯＰＰＱｕｅｒｙＳｔａｔｕｓは、使用されている物理コネクタ、当該物理コネクタを介して伝送されるコンテンツに適用可能な保護のタイプ、当該物理コネクタ上でアクティブになっている現行保護レベルに関する情報を取り出す、ビデオセッションからの要求である。呼び出しの順序に関する同じ制約がこの場合も適用される。ドライバは、当該ビデオセッションについてＣＯＰＰＫｅｙＥｘｃｈａｎｇｅ呼び出しまたはＣＯＰＰＳｅｑｕｅｎｃｅＳｔａｒｔ呼び出しを受け取る前にこの呼び出しを受け取った場合、Ｅ＿ＵＮＥＸＰＥＣＴＥＤを返さなければならない。
【０１０５】
【表１６】
0004809616.tif 000017
【０１０６】
以下の表に、本実施形態によりドライバが受け取ることができるＤＸ−ＶＡステータスリクエストのセットを示す。
【０１０７】
【表１７−１】
0004809616.tif 000018
【０１０８】
【表１７−２】
0004809616.tif 000019
【０１０９】
【表１７−３】
0004809616.tif 000020
【０１１０】
ユーザモードＡＰＩのＤＤＩマッピング
この特定の実施形態例では、また、Ｗｉｎｄｏｗｓ（登録商標）オペレーティングシステム用ＤＤＩ基盤との適合性のために、本明細書で上述したＡＰＩは、ＤｉｒｅｃｔＤｒａｗおよびＤｉｒｅｃｔＸ  ＶＡ用の既存のＤＤＩに「マップ」されなければならない。当業者ならわかるように、このようなマッピング操作は、カーネルモードコンポーネントに大幅な変更を加える必要をなくすのに有用である。したがって、本項および以下の説明では、ＤｉｒｅｃｔＤｒａｗおよびＤＸ−ＶＡの既存ＤＤＩＣＯＰＰインターフェースマッピングについて説明する。
【０１１１】
ＤＸ−ＶＡ  ＤＤＩはそれ自体、「ＤＸ−ＶＡコンテナ(container)」と［ＤＸ−ＶＡデバイス」という２つの機能グループに分かれている。ＤＸ−ＶＡコンテナＤＤＩグループの目的は、表示ハードウェアに含まれる様々なＤＸ−ＶＡデバイスの数と機能を判断することである。したがって、この実施例では、ＤＸ−ＶＡドライバは１つのコンテナしか持つことができないが、複数のＤＸ−ＶＡデバイスに対応することができる。
【０１１２】
この項の他の部分では、前述のインターフェースがどのようにＤＸ−ＶＡデバイスＤＤＩにマップされるかについて説明する。他のＤＸ−ＶＡ  ＤＤＩとは異なる、ＣＯＰＰデバイスはビデオメモリサーフェスをまったく参照しないことに留意されたい。
【０１１３】
ユーザ−モードコンポーネントからのＤＤＩ呼び出し
ビデオレンダリングコンポーネント７１０（図７）などのユーザモードコンポーネントからＤＤＩを使用するステップの順序は以下の通りである。
【０１１４】
１．ＧｅｔＭｏＣｏｍｐＧｕｉｄｓを呼び出して、ドライバによってサポートされているＤＸ−ＶＡデバイスのリストを入手する。
【０１１５】
２．ＣｒｅａｔｅＭｏＣｏｍｐを呼び出して、ビデオセッションのためのＣＯＰＰデバイスを設定する。ＣＯＰＰデバイスＧＵＩＤは以下のように定義される。
【０１１６】
ＤＥＦＩＮＥ＿ＧＵＩＤ（ＤＸＶＡ＿ＣＯＰＰＤｅｖｉｃｅ，
０ｘｄ２４５７ａｄｄ，０ｘ８９９９，０ｘ４５ｅｄ，０ｘ８ａ，０ｘ８ａ，０ｘｄ１，０ｘａａ，０ｘ０４，０ｘ７ｂ，０ｘａ４，０ｘｄ５）；
３．次に、ビデオレンダリングコンポーネントは、要求されるＣＯＰＰ操作のタイプに応じて異なる関数パラメータ値を使用してＣＯＰＰデバイスのＲｅｎｄｅｒＭｏｃｏｍｐを呼び出す。
【０１１７】
４．ビデオレンダリングコンポーネントがそれ以上ＣＯＰＰ操作を行う必要がない場合、ＤｅｓｔｒｏｙＭｏｃＣｏｍｐを呼び出す。
【０１１８】
５．ドライバは、ＣＯＰＰデバイスによって使用されていた資源を解放する。
【０１１９】
ＣＯＰＰＯｐｅｎＶｉｄｅｏＳｅｓｓｉｏｎ
このメソッドは、ＤＤ＿ＭＯＴＩＯＮＣＯＭＰＡＣＡＬＬＢＡＣＫＳ構造のＣｒｅａｔｅＭｏＣｏｍｐメソッドに直接マップする。ＧＵＩＤはＣＯＰＰＤｅｖｉｃｅＧＵＩＤであり、ｐＵｎｃｏｍｐＤａｔａはデータを含まない（すべてゼロ）の構造を指し、ｐＤａｔａはＮＵＬＬを指す。
【０１２０】
ドライバが圧縮ビデオ(compressed video)の高速復号(accelerated decoding)をサポートする場合、ビデオレンダリングコンポーネントは、ドライバを呼び出して２つのＤＸ−ＶＡデバイスを作成することを理解されたい。一方は、ＤｉｒｅｃｔＸＶＡビデオデコーディング仕様によって規定されている実際のビデオデコーディング作業を行うデバイスであり、他方は出力コネクタに、コンテンツ出力保護プロトコルによる保護を適用するためにのみ使用されるデバイスである。
【０１２１】
例：ＣｒｅａｔｅＭｏＣｏｍｐのＣＯＰＰＯｐｅｎＶｉｄｅｏＳｅｓｓｉｏｎへのマッピング
以下のサンプルコードによって、ドライバがＣｒｅａｔｅＭｏＣｏｍｐ  ＤＤＩ呼び出しをＣＯＰＰＯｐｅｎＶｉｄｅｏＳｅｓｓｉｏｎにマップする方法を示す。このサンプルコードは、ＣｒｅｔｅＭｏＣｏｍｐ関数がＣＯＰＰにどのように使用されるかのみを示すものである。ドライバがＭＰＥＧ−２ビデオストリームなど他のＤＸ−ＶＡ機能をサポートする場合、以下のサンプルコードを拡張して、追加のＤＸ−ＶＡ  ＧＵＩＤの処理を組み込むことができる。
【０１２２】
【表１８】
0004809616.tif 000021
【０１２３】
【表１９】
0004809616.tif 000022
【０１２４】
例：ＧｅｔＭｏＣｏｍｐＧｕｉｄの実施
ＣｒｅａｔｅＭｏＣｏｍｐＤＤＩ関数に加えて、ドライバはＤＤ＿ＭＯＴＩＯＮＣＯＭＰＣＡＬＬＢＡＣＫＳ構造のＧｅｔＭｏＣｏｍｐＧｕｉｄｓメソッドも実施する必要がある。以下のサンプルコードは、ドライバでこの機能を実施する１つの可能な方法を示す。
【０１２５】
【表２０】
0004809616.tif 000023
【０１２６】
ＣＯＰＰＧｅｔＣｅｒｔｉｆｉｃａｔｅＬｅｎｇｔｈ
このメソッドは、Ｄ＿ＭＯＴＩＯＮＣＯＭＰＣＡＬＬＢＡＣＫＳ構造のＲｅｎｄｅｒＭｏＣｏｍｐメソッドに直接マップし、以下の通りである。
【０１２７】
・  ｄｗＮｕｍＢｕｆｆｅｒｓはゼロである。
【０１２８】
・  ｌｐＢｕｆｆｅｒＩｎｆｏはＮＵＬＬである。
【０１２９】
・  ｄｗＦｕｎｃｔｉｏｎはＤＸＶＡ＿ＣＯＰＰＧｅｔＣｅｒｔｉｆｉｃａｔｅＬｅｎｇｔｈＦｎＣｏｄｅと定義される。
【０１３０】
・  ｌｐＩｎｐｕｔＤａｔａはＮｕｌｌである。
【０１３１】
・  ｌｐＯｕｔｐｕｔＤａｔａは単一のＤＷＯＲＤを指す。
【０１３２】
ＣＯＰＰに使用されるＤＸ−ＶＡデバイスの場合、ＲｅｎｄｅｒＭｏＣｏｍｐはＢｅｇｉｎＭｏＣｏｍｐＦｒａｍｅもＥｎｄＭｏＣｏｍｐＦｒａｍｅも呼び出さずに呼び出されることに留意されたい。
【０１３３】
例：ＲｅｎｄｅｒＭｏＣｏｍｐのＣＯＰＰＧｅｔＣｅｒｔｉｆｉｃａｔｅＬｅｎｇｔｈへのマッピング
以下のサンプルコードは、ドライバがＲｅｎｄｅｒＭｏＣｏｍｐ  ＤＤＩ呼び出しをどのようにＣＯＰＰＧｅｔＣｅｒｔｉｆｉｃａｔｅＬｅｎｇｔｈにマップする必要があるかを示す。このサンプルコードは、ＲｅｎｄｅｒＭｏＣｏｍｐ関数がＣＯＰＰ制御に使用される方法のみを示している。ドライバが、ＭＥＰＥＧ−２ビデオストリームなどのＤＸ−ＶＡ機能をサポートする場合、このサンプルコードを拡張して追加のＤＸ−ＶＡ  ＧＵＩＤの処理を組み込むことができる。
【０１３４】
【表２１】
0004809616.tif 000024
【０１３５】
【表２２】
0004809616.tif 000025
【０１３６】
ＣＯＰＰＫｅｙＥｘｃｈａｎｇｅ
このメソッドは、Ｄ＿ＭＯＴＩＯＮＣＯＭＰＣＡＬＬＢＡＣＫＳ構造のＲｅｎｄｅｒＭｏＣｏｍｐメソッドに直接マップし、以下の通りである。
【０１３７】
・  ｄｗＮｕｍＢｕｆｆｅｒｓはゼロである。
【０１３８】
・  ｌｐＢｕｆｆｅｒＩｎｆｏはＮＵＬＬである。
【０１３９】
・  ｄｗＦｕｎｃｔｉｏｎはＤＸＶＡ＿ＣＯＰＰＫｅｙＥｘｃｈａｎｇｅＦｎＣｏｄｅと定義される。
【０１４０】
・  ｌｐＩｎｐｕｔＤａｔａはＮＵＬＬである。
【０１４１】
・  ｌｐＯｕｔｐｕｔＤａｔａはＤＸＶＡ＿ＣＯＰＰＫｅｙＥｘｃｈａｎｇｅＯｕｔｐｕｔデータ構造を指す。
【０１４２】
ＣＯＰＰに使用されるＤＸ−ＶＡデバイスの場合、ＲｅｎｄｅｒＭｏＣｐｍｐは、ＢｅｇｉｎＭｏＣｏｍｐＦｒａｍｅもＥｎｄＭｏＣｏｍｐＦｒａｍｅも呼び出さずに呼び出されることに留意されたい。
【０１４３】
例：ＲｅｎｄｅｒＭｏＣｏｍｐのＣＯＰＰＫｅｙＥｘｃｈａｎｇｅへのマッピング
以下のサンプルコードは、ドライバがＲｅｎｄｅｒＭｏＣｏｍｐ  ＤＤＩ呼び出しをどのようにＣＯＰＰＫｅｙＥｘｃｈａｎｇｅにマップする必要があるかを示す。このサンプルコードは、ＲｅｎｄｅｒＭｏＣｏｍｐ関数がＣＯＰＰ制御に使用される方法のみを示している。ドライバが、ＭＰＥＧ−２ビデオストリームなど他のＤＸ−ＶＡ機能をサポートする場合、このサンプルコードを拡張して追加のＤＸ−ＶＡ  ＧＵＩＤの処理を組み込むことができる。
【０１４４】
【表２３】
0004809616.tif 000026
【０１４５】
ＣＯＰＰＳｅｑｕｅｎｃｅＳｔａｒｔ
このメソッドは、Ｄ＿ＭＯＴＩＯＮＣＯＭＰＣＡＬＬＢＡＣＫＳ構造のＲｅｎｄｅｒＭｏＣｏｍｐメソッドに直接マップし、以下の通りである。
【０１４６】
・  ｄｗＮｕｎｍＢｕｆｆｅｒｓはゼロである。
【０１４７】
・  ｌｐＢｕｆｆｅｒＩｎｆｏはＮＵＬＬである。
【０１４８】
・  ｄｗＦｕｎｃｔｉｏｎはＤＸＶＡ＿ＣＯＰＰＳｅｑｕｅｎｃｅＳｔａｒｔＦｎＣｏｄｅと定義される。
【０１４９】
・  ｌｐＩｎｐｕｔＤａｔａはＤＸＶＡ＿ＣＯＰＰＳｉｇｎａｔｕｒｅデータ構造を指す。
【０１５０】
・  ｌｐＯｕｔｐｕｔＤａｔａはＮＵＬＬである。
【０１５１】
ＣＯＰＰに使用されるＤＸ−ＶＡデバイスの場合、ＲｅｎｄｅｒＭｏＣｏｍｐはＢｅｇｉｎＭｏＣｏｍｐＦｒａｍｅもＥｎｄＭｏＣｏｍｐＦｒａｍｅも呼び出さずに呼び出されることに留意されたい。
【０１５２】
例：ＲｅｎｄｅｒＭｏＣｏｍｐのＣＯＰＰＳｅｑｕｅｎｃｅＳｔａｒｔへのマッピング
以下のサンプルコードは、ドライバがＲｅｎｄｅｒＭｏＣｏｍｐのＤＤＩをどのようにＣＯＰＰＳｅｑｕｅｎｃｅＳｔａｒｔにマップする必要があるかを示す。サンプルコードは、ＲｅｎｄｅｒＭｏＣｏｍｐ関数がＣＯＰＰ制御に使用される方法のみを示している。ドライバが、ＭＰＥＧ−２ビデオストリームなど他のＤＸ−ＶＡ機能をサポートする場合、サンプルコードを拡張して追加のＤＸ−ＶＡ  ＧＵＩＤの処理も組み込むことができる。
【０１５３】
【表２４】
0004809616.tif 000027
【０１５４】
ＣＯＰＰＣｏｍｍａｎｄ
このメソッドは、Ｄ＿ＭＯＴＩＯＮＣＯＭＰＣＡＬＬＢＡＣＫＳ構造のＲｅｎｄｅｒＭｏＣｏｍｐメソッドに直接マップし、以下の通りである。
【０１５５】
・  ｄｗＮｕｍＢｕｆｆｅｒｓはゼロである。
【０１５６】
・  ｌｐＢｕｆｆｅｒＩｎｆｏはＮＵＬＬである。
【０１５７】
・  ｄｗＦｕｎｃｔｉｏｎはＤＸＶＡ＿ＣＯＰＰＣｏｍｍａｎｄＦｎＣｏｄｅと定義される。
【０１５８】
・  ｌｐＩｎｐｕｔＤａｔａはＤＸＶＡ＿ＣＯＰＰＣｏｍｍａｎｄデータ構造を指す。
【０１５９】
・  ｌｐＯｕｔｐｕｔＤａｔａはＮＵＬＬである。
【０１６０】
ＣＯＰＰに使用されるＤＸ−ＶＡデバイスの場合、ＲｅｎｄｅｒＭｏＣｏｍｐはＢｅｇｉｎＭｏＣｏｍｐＦｒａｍｅもＥｎｄＭｏＣｏｍｐＦｒａｍｅも呼び出さずに呼び出されることに留意されたい。
【０１６１】
例：ＲｅｎｄｅｒＭｏＣｏｍｐのＣＯＰＰＣｏｍｍａｎｄへのマッピング
以下のサンプルコードは、ドライバがＲｅｎｄｅｒＭｏＣｏｍｐ  ＤＤＩ呼び出しをどのようにＣＯＰＰＣｏｍｍａｎｄにマップする必要があるかを示す。このサンプルコードは、ＲｅｎｄｅｒＭｏＣｏｍｐ関数がＣＯＰＰ制御に使用される方法のみを示している。ドライバがＭＰＥＧ−２ビデオストリームなど他のＤＸ−ＶＡ機能をサポートする場合、このサンプルコードを拡張して追加のＤＸ−ＶＡ  ＧＵＩＤの処理を組み込むことができる。
【０１６２】
【表２５】
0004809616.tif 000028
【０１６３】
ＣＯＰＰＱｕｅｒｙＳｔａｔｕｓ
このメソッドは、Ｄ＿ＭＯＴＩＯＮＣＯＭＰＣＡＬＬＢＡＣＫＳ構造のＲｅｎｄｅｒＭｏＣｏｍｐメソッドに直接マップし、以下の通りである。
【０１６４】
・  ｄｗＮｕｍＢｕｆｆｅｒｓはゼロである。
【０１６５】
・  ｌｐＢｕｆｆｅｒＩｎｆｏはＮＵＬＬである。
【０１６６】
・  ｄｗＦｕｎｃｔｉｏｎはＤＸＶＡ＿ＣＯＰＰＱｕｅｒｙＳｔａｔｕｓＦｎＣｏｄｅと定義される。
【０１６７】
・  ｌｐＩｎｐｕｔＤａｔａはＤＸＶＡ＿ＣＯＰＰＳｔａｔｕｓＩｎｐｕｔデータ構造を指す。
【０１６８】
・  ｌｐＯｕｔｐｕｔＤａｔａはＤＸＶＡ＿ＣＯＰＰＳｔａｔｕｓＯｕｔｐｕｔデータ構造を指す。
【０１６９】
ＣＯＰＰに使用されるＤＸ−ＶＡの場合、ＲｅｎｄｅｒＭｏＣｏｍｐはＢｅｇｉｎＭｏＣｏｍｐＦｒａｍｅもＥｎｄＭｏＣｏｍｐＦｒａｍｅも呼び出さずに呼び出されることに留意されたい。
【０１７０】
例：ＲｅｎｄｅｒＭｏＣｏｍｐのＣＯＰＰＱｕｅｒｙＳｔａｔｕｓへのマッピング
以下のサンプルコードは、ドライバがＲｅｎｄｅｒＭｏＣｏｍｐのＤＤＩ呼び出しをどのようにＣＯＰＰＱｕｅｒｙＳｔａｔｕｓにマップする必要があるかを示す。このサンプルコードは、ＲｅｎｄｅｒＭｏＣｏｍｐ関数がＣＯＰＰ制御に使用される方法のみを示している。ドライバがＭＰＥＧ−２ビデオストリームなど他のＤＸ−ＶＡ機能をサポートする場合、このサンプルコードを拡張して追加のＤＸ−ＶＡ  ＧＵＩＤの処理を組み込むこともできる。
【０１７１】
【表２６】
0004809616.tif 000029
【０１７２】
【表２７】
0004809616.tif 000030
【０１７３】
ＣＯＰＰＣｌｏｓｅＶｉｄｅｏＳｅｓｓｉｏｎ
このメソッドは、ＤＤ＿ＭＯＴＩＯＮＣＯＭＰＣＡＬＬＢＡＣＫＳ構造のＤｅｓｔｒｏｙＭｏＣｏｍｐメソッドに直接マップする。
【０１７４】
例：ＤｅｓｔｒｏｙＭｏＣｏｍｐのＣＯＰＰＣｌｏｓｅＶｉｄｅｏＳｅｓｓｉｏｎへのマッピング
以下のサンプルコードは、ドライバがＤｅｓｔｒｏｙＭｏＣｏｍｐ  ＤＤＩをどのようにＣＯＰＰＣｌｏｓｅＶｉｄｅｏＳｅｓｓｉｏｎにマップする必要があるかを示す。このサンプルコードは、ＤｅｓｔｒｏｙＭｏｃＣｏｍｐ関数がＣＯＰＰデバイスに使用される方法のみを示している。ドライバがＭＰＥＧ−２ビデオストリームなど他のＤＸ−ＶＡ機能をサポートする場合、このサンプルコードを拡張して追加のＤＸ−ＶＡ  ＧＵＩＤの処理を組み込むこともできる。
【０１７５】
【表２８】
0004809616.tif 000031
【０１７６】
【表２９】
0004809616.tif 000032
【０１７７】
結論
上述の様々な実施形態は、保護コンテンツプレイバックアプリケーションを実行するコンピュータなどの装置と、モニタ、フラットパネルＬＣＤ、テレビジョンなどの関連付けられたディスプレイデバイスのグラフィクスドライバなどの関連付けられたドライバとの間に、セキュア通信チャネル、および、実施形態によっては、セキュアデータチャネルを確立することによって、媒体コンテンツの保護を可能にする。様々な実施形態によれば、コンピュータとそのディスプレイデバイスを物理的にリンクする出力アダプタを保護されたビデオ経路のためのゲートウェイとして使用することによって、媒体出力にコンテンツ保護を適用する必要があることを通知するというコンテンツ提供業者およびアプリケーション供給業者にとっての必要性に対処することができる。
【０１７８】
また、様々な実施形態によれば、ユーザモードプレイバックアプリケーションからグラフィクスドライバなどのドライバに安全にコマンドを渡し、ドライバからユーザモードアプリケーションに状況を安全に返す手段を提供する。本明細書に記載の実施形態によれば、セキュア通信チャネルを確立し、ユーザモードアプリケーションが、関連付けられたドライバに対して、コンピュータとディスプレイデバイスとの間の物理コネクタに対するコンテンツ出力保護をイネーブルにするように指示することができる。
【０１７９】
なお、各種実施形態について、構造上の特徴および／または方法ステップとして特有の用語で説明したが、特許請求の範囲で規定されている本発明は、記載されている特定の特徴またはステップに必ずしも限定されない。これらの特定の特徴およびステップは、請求の範囲に記載されている発明を実施する好ましい態様として開示されているものである。
【図面の簡単な説明】
【０１８０】
【図１】媒体コンテンツを処理することができるシステムを示すハイレベルブロック図である。
【図２】本発明の一実施形態による保護プロトコルの態様を例示するために使用されるシステムを示すブロック図である。
【図３】本発明の一実施形態による保護プロトコルの態様を示すブロック図である。
【図４】本発明の一実施形態による保護プロトコルの態様を示すブロック図である。
【図５】本発明の一実施形態による保護プロトコルの態様を示すブロック図である。
【図６】本発明の一実施形態による方法を示すフローチャートである。
【図７】本発明の一実施例を実現するためのシステム例を示すブロック図である。
【符号の説明】
【０１８１】
１２  保護コンテンツ
１８  デクリプションコンポーネント
２０  デコーダコンポーネント
２２  レンダラーコンポーネント
２４  ディスプレイ
２６  スピーカ
２０２  プレイバックアプリケーション
２０４  システムソフトウェア
２０６  ドライバソフトウェア
２０８  ハードウェア（ビデオカード）
２１０  物理コネクタ
２１２  出力デバイス
２１４  コンテンツ保護技術のタイプ
７０２  プレイバックアプリケーション
７０４  フィルタグラフ
７０６  ソースフィルタ
７０８  デコーダ
７１０  ビデオレンダリングコンポーネント
７１６  グラフィクスドライバ
【図１】
0004809616.tif 000033
【図２】
0004809616.tif 000034
【図３】
0004809616.tif 000035
【図４】
0004809616.tif 000036
【図５】
0004809616.tif 000037
【図６】
0004809616.tif 000038
【図７】
0004809616.tif 000039