(57)【特許請求の範囲】
【請求項１】
ユーザの第２のコンピューティングデバイス（以下、第２デバイス）に関する、該第２デバイスと区別される第１のコンピューティングデバイス（以下、第１デバイス）上の暗号化されたデジタルコンテンツをレンダリングする方法であって、前記第１デバイスが公開鍵 (ＰＵ１) とそれに対応する秘密鍵 (ＰＲ１) を所持し、前記第２デバイスが公開鍵 (ＰＵ２) とそれに対応する秘密鍵 (ＰＲ２) を所持し、前記デジタルコンテンツはコンテンツ鍵 (ＫＤ) に従って暗号化されており、該方法が、
ユーザの前記第２デバイスが、前記デジタルコンテンツと前記第２デバイスとに対応するデジタルライセンスを前記第２デバイスから区別されるライセンサーから取得するステップであって、前記デジタルライセンスはコンテンツ鍵 (ＫＤ)が前記第２デバイスの公開鍵（ＰＵ２）に従って暗号化形式で収められている（ＰＵ２（ＫＤ））を含み、かつ前記第２デバイスから前記第１デバイスへサブライセンスを発行することを許可しているかどうかを判断するためのルールをも含んでいる、ステップと、
ユーザの前記第２デバイスが、該第２デバイスから前記第１デバイスへのサブライセンスの発行を前記ルールが実際に許容していると判断するステップと、
ユーザの前記第２デバイスが、前記デジタルライセンスから前記（ＰＵ２（ＫＤ））を前記対応する秘密鍵（ＰＲ２）に従って解読して前記コンテンツ鍵（ＫＤ）を生成するステップと、
ユーザの前記第２デバイスが、前記第１デバイスから該第１デバイスの前記公開鍵（ＰＵ１）を取得するステップと、
ユーザの前記第２デバイスが、前記第１デバイスの前記公開鍵（ＰＵ１）に従って前記コンテンツ鍵（ＫＤ）を暗号化（ＰＵ１（ＫＤ））するステップと、
ユーザの前記第２デバイスが、前記第１デバイスについての前記取得したライセンスに従ってまた基づいて前記（ＰＵ１（ＫＤ））を含む前記サブライセンスを構成し、かつ該構成したサブライセンスを前記第１デバイスへ転送するステップとを含み、
前記第１デバイスは、前記転送されてきたサブライセンスの前記 (ＰＵ１(ＫＤ)) を自身の前記秘密鍵 (ＰＲ１) を用いて解読してコンテンツ鍵 (ＫＤ) を生成することができ、該生成されたコンテンツ鍵 (ＫＤ) を用いて前記第１デバイス上の前記暗号化コンテンツをレンダリングできることを特徴とする方法。
【請求項２】
請求項１に記載の方法において、前記サブライセンスを構成し、かつ該構成したサブライセンスを前記第１デバイスへ転送する前記ステップの前において、ユーザの前記第２デバイスは、前記取得したデジタルライセンスをチェックして、該デジタルライセンスが前記第１デバイスに対するサブライセンスの発行を許可しているかどうかを判断するステップを、さらに含むことを特徴とする方法。
【請求項３】
請求項１に記載の方法において、ユーザの前記第２デバイスが、さらに、前記デジタルコンテンツを前記第１デバイスに転送するステップを含むことを特徴とする方法。
【請求項４】
請求項１に記載の方法において、デジタル化権管理 (ＤＲＭ)システムが置かれている前記第１デバイス上の暗号化デジタルコンテンツをレンダリングする方法であって、前記ＤＲＭシステムは、前記公開鍵 (ＰＵ１) とそれに対応する前記秘密鍵 (ＰＲ１) を所持するものにおいて、該方法は、
ユーザの前記第２デバイスが、前記第１デバイスから前記ＤＲＭシステムの前記公開鍵 (ＰＵ１) を取得するステップと、
ユーザの前記第２デバイスが、前記第１デバイスの前記ＤＲＭシステムの前記公開鍵 (ＰＵ１) に従って前記コンテンツ鍵 (ＫＤ) を暗号化(ＰＵ１(ＫＤ))するステップと、
ユーザの前記第２デバイスが、取得した前記デジタルライセンスに対応しまた基づいて、前記(ＰＵ１(ＫＤ))を含むサブライセンスを構成するステップと、
ユーザの前記第２デバイスが、前記サブライセンスを前記第１デバイスに転送するステップとを含み、
前記第１デバイスの前記ＤＲＭシステムは、前記秘密鍵 (ＰＲ１) を使用して 、前記(ＰＵ１(ＫＤ)) を解読してコンテンツ鍵 (ＫＤ) を得ることができると共に、得られた前記コンテンツ鍵 (ＫＤ) を使用して前記第１デバイス上の暗号化デジタルコンテンツをレンダリングできることを特徴とする方法。
【請求項５】
請求項１に記載の方法において、
ユーザの前記第２デバイスが、前記デジタルライセンスを取得して、該取得したデジタルライセンスを前記第２デバイス上に格納するステップと、
ユーザの前記第２デバイスが、前記第２デバイス上の前記デジタルライセンスから前記暗号化コンテンツ鍵(ＰＵ２(ＫＤ))を第２デバイスの秘密鍵（ＰＲ２）を用いて解読して前記コンテンツ鍵（ＫＤ）を生成するステップと
ユーザの前記第２デバイスが、前記第１デバイスから前記公開鍵 (ＰＵ１) を取得するステップと、
ユーザの前記第２デバイスが、前記第１デバイスの前記公開鍵 (ＰＵ１) に従って前記コンテンツ鍵 (ＫＤ) を暗号化(ＰＵ１(ＫＤ))するステップと、
ユーザの前記第２デバイスが、前記取得したデジタルライセンスに対応してまた基づいて、前記 (ＰＵ１(ＫＤ)) を含むサブライセンスを構成し、該構成したサブライセンスを前記第１デバイスに転送ステップとを含み、
前記第１デバイスは、前記サブライセンスに含まれている前記(ＰＵ１(ＫＤ)) を前記秘密鍵 (ＰＲ１) を使用して 解読して前記コンテンツ鍵 (ＫＤ) を生成することができ、該生成されたコンテンツ鍵 (ＫＤ) を使用して前記第１デバイス上の暗号化デジタルコンテンツをレンダリングできることを特徴とする方法。
【請求項６】
請求項５に記載の方法であって、第２デバイスは公開鍵 (ＰＵ２) とそれに対応する秘密鍵 (ＰＲ２) を所持しているものにおいて、該方法は、
ユーザの前記第２デバイスが、前記デジタルコンテンツに対応するデジタルライセンスであって、前記第２デバイスの公開鍵 (ＰＵ２) に従ってコンテンツ鍵 (ＫＤ) を暗号化したもの (ＰＵ２(ＫＤ)) を含んでいるデジタルライセンスを取得するステップと、
ユーザの前記第２デバイスが、該第２デバイスの秘密鍵 (ＰＲ２) に従って前記デジタルライセンスから前記 (ＰＵ２(ＫＤ)) を解読して前記コンテンツ鍵 (ＫＤ) を生成するステップと
を含むことを特徴とする方法。
【請求項７】
請求項５に記載の方法において、前記第２デバイスはコンピュータであることを特徴とする方法。
【請求項８】
請求項１に記載の方法において、前記第１デバイスはポータブルデバイスであることを特徴とする方法。
【請求項９】
請求項１に記載の方法において、前記第１デバイスから前記公開鍵 (ＰＵ１) を取得する前記ステップは、ユーザの前記第２デバイスが、前記公開鍵 (ＰＵ１) が入っている証明書を前記第１デバイスから受け取ることを含むことを特徴とする方法。
【請求項１０】
請求項９に記載の方法において、ユーザの前記第２デバイスが、前記受け取った証明書を無効リストと突き合わせて比較することで、該証明書が無効にされていないことを確かめるステップを、さらに含むことを特徴とする方法。
【請求項１１】
請求項９に記載の方法において、ユーザの前記第２デバイスが、前記公開鍵 (ＰＵ１) と前記第１デバイスに関する情報とが入っている前記証明書を前記第１デバイスから受け取るステップを含むことを特徴とする方法。
【請求項１２】
請求項１１に記載の方法において、前記サブライセンスを構成し、構成された該サブライセンスを前記第１デバイスへ転送する前記ステップの前に、ユーザの前記第２デバイスが、前記取得したデジタルライセンスをチェックして、該デジタルライセンスが前記第１デバイスに対するサブライセンスの発行を許可しているかどうかを判断するステップをさらに含み、該チェックには、前記第１デバイスに関する前記情報を使用して、前記デジタルライセンスがサブライセンスの発行を許可しているかどうかを判断することが含まれることを特徴とする方法。
【請求項１３】
請求項１１に記載の方法において、ユーザの前記第２デバイスが、前記第１デバイスの前記公開鍵(ＰＵ１) と前記第１デバイスの名前、タイプおよびメーカのうちの少なくとも１つが入っている前記証明書を前記第１デバイスから受け取るステップを含むことを特徴とする方法。
【請求項１４】
請求項１に記載の方法において、前記第１デバイスが、転送されてきた前記サブライセンスから前記(ＰＵ１(ＫＤ)) を取得し、前記秘密鍵(ＰＲ１) を 該(ＰＵ１(ＫＤ)) に適用することで前記コンテンツ鍵 (ＫＤ) を得て、該コンテンツ鍵(ＫＤ) を適用して前記暗号化デジタルコンテンツを解読するステップをさらに含むことを特徴とする方法。
【請求項１５】
ユーザの第１のコンピューティングデバイス（以下、第１デバイス）とユーザの第２のコンピューティングデバイス（以下、第２デバイス）に関する、前記第１デバイスから区別される前記第２デバイスを通じて、公開鍵 (ＰＵ１) とそれに対応する秘密鍵 (ＰＲ１) を所持する前記第１デバイス上の暗号化されたデジタルコンテンツをレンダリングする方法であって、前記第２デバイスが公開鍵 (ＰＵ２) とそれに対応する秘密鍵 (ＰＲ２) を所持し、前記デジタルコンテンツはコンテンツ鍵 (ＫＤ) に従って暗号化されており、該方法が、
ユーザの前記第２デバイスが、前記デジタルコンテンツと前記第２デバイスとに対応するデジタルライセンスを前記第２デバイスから区別されるライセンサーから取得するステップであって、前記デジタルライセンスは前記第２デバイスの公開鍵（ＰＵ２）に従ってコンテンツ鍵 (ＫＤ)が暗号化形式で収められている（ＰＵ２（ＫＤ））を含み、かつ前記第２デバイスから前記第１デバイスへサブライセンスを発行することを許可しているかどうかを判断するためのルールをも含んでいる、ステップと、
ユーザの前記第２デバイスが、該第２デバイスから前記第１デバイスへサブライセンスの発行を前記ルールが実際に許容していると判断するステップと、
ユーザの前記第２デバイスが、前記デジタルライセンスから前記（ＰＵ２（ＫＤ））を前記対応する秘密鍵（ＰＲ２）に従って解読して前記コンテンツ鍵（ＫＤ）を生成するステップと、
ユーザの前記第２デバイスが、前記第１デバイスから該第１デバイスの前記公開鍵（ＰＵ１）を取得するステップと、
ユーザの前記第２デバイスが、前記第１デバイスの前記公開鍵（ＰＵ１）に従って前記コンテンツ鍵（ＫＤ）を暗号化（ＰＵ１（ＫＤ））するステップと、
ユーザの前記第２デバイスが、前記第１デバイスについての前記取得したライセンスに従ってまた基づいて前記（ＰＵ１（ＫＤ））を含む前記サブライセンスを構成し、かつ該構成したサブライセンスを前記第１デバイスへ転送するステップと、
ユーザの前記第１デバイスが、前記構成されたサブライセンスを前記第２デバイスから受信するステップと、
ユーザの前記第１デバイスが、前記受信したサブライセンスから前記（ＰＵ１（ＫＤ））を取得するステップと、
ユーザの前記第１デバイスが、自身の前記秘密鍵（ＰＲ１）を前記（ＰＵ１（ＫＤ））に適用して前記コンテンツ鍵（ＫＤ）を取得するステップと、
ユーザの前記第１デバイスが、前記コンテンツ鍵（ＫＤ）を適用することで前記暗号化デジタルコンテンツを解読するステップと、
ユーザの前記第１デバイスが、前記解読されたデジタルコンテンツをレンダリングするステップと、
を含むことを特徴とする方法。
【請求項１６】
請求項１５に記載の方法において、前記暗号化デジタルコンテンツは、ユーザの前記第１デバイスが前記第２デバイスから受け取った暗号化デジタルコンテンツであることをさらに含むことを特徴とする方法。
【請求項１７】
請求項１５に記載の方法において、デジタル化権管理 (ＤＲＭ) システムが置かれている前記第１デバイス上の暗号化デジタルコンテンツをレンダリングする方法であって、前記ＤＲＭシステムは公開鍵 (ＰＵ１) と該公開鍵に対応する秘密鍵 (ＰＲ１) を所持し、前記デジタルコンテンツはコンテンツ鍵 (ＫＤ) に従って暗号化されているものにおいて、該方法は、
ユーザの前記第１デバイスが、前記ＤＲＭシステムの公開鍵 (ＰＵ１) を第２デバイスに提供するステップと、
ユーザの前記第１デバイスが、前記第２デバイスによって構成された前記サブライセンスを前記第２デバイスから受け取るステップと、
ユーザの前記第１デバイスが、受け取った前記サブライセンスから前記 (ＰＵ１(ＫＤ)) を取得するステップと、
ユーザの前記第１デバイスが、前記ＤＲＭシステムの前記秘密鍵 (ＰＲ１) を前記 (ＰＵ１(ＫＤ)) に適用してコンテンツ鍵 (ＫＤ) を取得するステップと、
ユーザの前記第１デバイスが、前記(ＫＤ) を適用して暗号化デジタルコンテンツを解読するステップと、
ユーザの前記第１デバイスが、解読されたデジタルコンテンツを前記サブライセンスの前記ルールだけに従ってレンダリングするステップと
を含むことを特徴とする方法。
【請求項１８】
請求項１５に記載の方法において、前記第２デバイスはコンピュータであることを特徴とする方法。
【請求項１９】
請求項１５に記載の方法において、前記第１デバイスはポータブルデバイスであることを特徴とする方法。
【請求項２０】
請求項１５に記載の方法において、前記公開鍵 (ＰＵ１) を前記第２デバイスに提供する前記ステップは、ユーザの前記第１デバイスが、前記公開鍵 (ＰＵ１) が入っている証明書を前記第２デバイスに提供することを含むことを特徴とする方法。
【請求項２１】
請求項２０に記載の方法において、前記公開鍵 (ＰＵ１) を前記第２デバイスに提供する前記ステップは、ユーザの前記第１デバイスが、前記公開鍵(ＰＵ１) と前記第１デバイスに関する情報とが入っている前記証明書を前記第２デバイスに提供することを含み、該第２デバイスは、該第１デバイスに関する情報を使用して、前記取得されたデジタルライセンスがサブライセンスの発行を許可しているかどうか判断できることを特徴とする方法。
【請求項２２】
請求項２１に記載の方法において、ユーザの前記第１デバイスが、前記公開鍵(ＰＵ１) と前記第１デバイスの名前、タイプおよびメーカのうちの少なくとも１つに関する情報が入っている前記証明書を前記第２デバイスに提供するステップを含むことを特徴とする方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、デジタルコンテンツにおける権利強化のためのアーキテクチャに関する。さらに具体的には、本発明は、デジタルコンテンツのユーザによって取得されたライセンス権利で指定されたパラメータに従ってのみ暗号化デジタルコンテンツへのアクセスを許可する、強制アーキテクチャに関する。
【０００２】
本出願の関連特許出願
本出願に関連する特許出願として、「デジタル化権管理 (DRM) システムにおけるデジタルコンテンツのポータブルストレージデバイスなどへのバインディング(BINDING DIGITAL CONTENT TO A PORTABLE STORAGE DEVICE OR THE LIKE IN A DIGITAL RIGHTS MANAGEMENT (DRM) SYSTEM)」という名称で2000年8月25日に出願された米国特許出願第09/645,887号、「デジタル化権管理のための強制アーキテクチャおよび方法(ENFORCEMENT ARCHITECTURE AND METHOD FOR DIGITAL RIGHTS MANAGEMENT)」という名称で1999年4月12日に出願された米国特許出願第09/290,363号、および「デジタル化権管理のための強制アーキテクチャおよび方法(ENFORCEMENT ARCHITECTURE AND METHOD FOR DIGITAL RIGHTS MANAGEMENT)」という名称で1999年3月27日に出願された米国仮特許出願第60/126,614号があり、これらはいずれも、引用により本明細書の一部になっている。
【０００３】
【従来の技術】
デジタル化権管理(digital rights management)と強制（enforcement）は、デジタルオーディオ、デジタルビデオ、デジタルテキスト、デジタルデータ、デジタルマルチメディアなどのデジタルコンテンツに関して強く望まれており、この場合、かかるデジタルコンテンツはユーザに配信されるようになっている。代表的な配信形態としては、磁気（フロッピー：登録商標）ディスク、磁気テープ、光（コンパクト）ディスク (CD) などの有形デバイス、および電子掲示板 (electronic bulletin board)、電子ネットワーク (electronic network)、インターネット (the Internet) などの無形メディアがある。これらデジタルコンテンツがユーザによって受け取られると、そのユーザは、メディアプレイヤなどの適当なレンダリングデバイスを使用して、デジタルコンテンツをパーソナルコンピュータなどの上でレンダリング (rendering：表現、演出、演奏、翻訳など) または「プレイ」している。
【０００４】
代表例として、著作者、出版業者、放送業者などの、コンテンツ所有者または権利所有者（以下、「コンテンツ所有者」と称する）は、ライセンス使用料やその他の報酬の見かえりとして、そのデジタルコンテンツをユーザまたは受取人に配信することを望んでいる。そのコンテンツ所有者は、選択権を与えることで、配信されたデジタルコンテンツをユーザがどのように扱うかについての制限を設けることを望んでいる。例えば、コンテンツ所有者は、少なくとも、コンテンツ所有者が別のユーザからライセンス使用料を受け取るのを否定されるような形で、ユーザがそのコンテンツをコピーし、別のユーザに再配信するのを制限することを望んでいる。
【０００５】
さらに、コンテンツ所有者は、種々タイプの使用ライセンスを異なるライセンス使用料で購入する柔軟性をユーザに与えることを望んでいる一方で、どのタイプのライセンスが実際に購入されたかに関係なく、ユーザをそのライセンス条項に拘束することを望んでいる。例えば、コンテンツ所有者は、配信されたデジタルコンテンツがプレイされるときに、プレイ回数に制限を設けたり、総時間量に制限を設けたり、マシンのタイプに制限を設けたり、メディアプレイヤーのタイプに制限を設けたり、ユーザのタイプに制限を設けたりすることを望む場合がある。
【０００６】
しかし、配信が行われたあと、コンテンツ所有者によるデジタルコンテンツに対する管理は、例えそれがあったとしても、非常に限られている。このことは、ほとんどすべての新規または最新パーソナルコンピュータが、デジタルコンテンツのデジタルコピーをそっくりとって、そのデジタルコピーを書込み可能な磁気または光ディスクにダウンロードしたり、そのデジタルコピーをインターネット (the Internet) などのネットワーク上で任意の宛先に送信したりするのに必要なソフトウェアとハードウェアを備えていることから、特に問題になっている。
【０００７】
当然のことであるが、ライセンス使用料が取得されている適法トランザクションの一部として、コンテンツ所有者は、デジタルコンテンツのユーザに、そのデジタルコンテンツを再販しないことを約束させる場合がある。しかし、そのような約束は簡単に行われ、簡単に破られている。コンテンツ所有者は、いくつかの公知のセキュリティデバイスのいずれかで、通常は暗号化 (encryption) と解読 (decryption：復号化ともいう) を行うことによって再販を防止することを試みている。しかし、優柔不断なユーザが、暗号化デジタルコンテンツを解読し、そのデジタルコンテンツを非暗号化形式でセーブ（保存、記憶）したあとで、それを再販しないとの保証はほとんどない。
【０００８】
【発明が解決しようとする課題】
そこで、任意形体のデジタルコンテンツのレンダリングやプレイを制御下で行うことを可能にし、その制御が柔軟性をもち、デジタルコンテンツのコンテンツ所有者によって定義可能であるような、強制アーキテクチャと方法を提供することが要望されている。また、パーソナルコンピュータなどのコンピューティングデバイス上で制御下のレンダリング環境を提供することも要望され、そこでは、レンダリング環境が前記強制アーキテクチャの少なくとも一部を含んでいることが望まれている。この制御下のレンダリング環境によると、デジタルコンテンツがコンテンツ所有者の制御下にないコンピューティングデバイス上でレンダリングされる場合であっても、デジタルコンテンツは、コンテンツ所有者が指定した通りにしかレンダリングされないことになる。
【０００９】
さらに、コンピューティングデバイス上で実行されるトラステッドコンポーネント (trusted component：監督成分) が要望されており、この場合、そのトラステッドコンポーネントは、コンテンツ所有者が許可していない方法で、そのコンピューティングデバイスのユーザが１つのデジタルコンテンツにアクセスする試みに対しても、そのデジタルコンテンツに関してコンピューティングデバイス上でコンテンツ所有者の権利を強制するものである。１つの例として、そのトラステッドソフトウェアコンポーネントは、そのコンテンツ所有者が別に許可した場合を除き、コンピューティングデバイスのユーザがそのデジタルコンテンツのコピーをとるのを防止する。
【００１０】
【課題を解決するための手段】
本発明によれば、公開鍵 (public key) (PU1) とそれに対応する秘密鍵 (private key) (PR1) を所有する第１デバイス上で暗号化デジタルコンテンツをレンダリングするための方法が提供されており、そこでは、デジタルコンテンツはコンテンツ鍵 (content key) (KD) に従って暗号化されている。この方法では、コンテンツに対応するデジタルライセンス (digital license) が取得され、デジタルライセンスはコンテンツ鍵 (KD) を暗号化形式でそこに収めている。デジタルライセンスからの暗号化コンテンツ鍵 (KD) はコンテンツ鍵 (KD) を得るために解読（復号）され、第１デバイスの公開鍵 (PU1) はそこから取得される。そのあと、コンテンツ鍵 (KD) は第１デバイスの公開鍵 (PU1) に従って暗号化され (PU1(KD))、取得されたライセンスに対応し、それに基づくサブライセンスが構成され、そこでは、サブライセンスは (PU1(KD)) を含んでいる。構成されたサブライセンスは第１デバイスに転送され、そこでは、第１デバイスは、その秘密鍵 (PR1) で (PU1(KD)) を解読してコンテンツ鍵 (KD) を得ることができ、得られたコンテンツ鍵 (KD) を使用して暗号化コンテンツを第１デバイス上でレンダリングできるようにしている。
【００１１】
サブライセンスを第２デバイスから第１デバイスにチェックアウト (check out) するために、第２デバイスは、nonce （ワンタイム鍵のこと。以下、nonceと称す）を第１デバイスに要求し、そのnonceを受信する。そのあと、第２デバイスはチェックアウト済みサブライセンス (checked-out sub-license) とnonceを第１デバイスに送信する。そのあと、第１デバイスは、第２デバイスから送信されたnonceが、第２デバイスによって受信されたnonceと同じであると結論し、従って、送信nonceに付属して送信されたサブライセンスが適法（正規、正当ともいう）であると結論し、送信サブライセンスをストアしておく。チェックアウト済みサブライセンスをチェックイン (check in) するために、第１デバイスはチェックアウト済みサブライセンスを削除し、そのあと、チェックアウト済みサブライセンスが確かに削除されたとの信用通知 (trusted indication) を第２デバイスに与える。
【００１２】
本発明の概要は上述したとおりであるが、以下では、本発明の理解を容易にするために、添付図面を参照して本発明の実施形態を詳しく説明する。本発明の説明の便宜上、図面には、現時点で好適であると考えられる実施形態が示されている。なお、当然に理解されるように、本発明は図示されている具体的構成と手段に限定されるものではない。
【００１３】
【発明の実施の形態】
以下では、添付図面を参照して詳しく説明する。なお、図面全体を通して類似エレメントは類似符号を付けて示されている。図１は、本発明の一実施形態による強制アーキテクチャ (enforcement architecture) １０を示している。概要を説明すると、この強制アーキテクチャ１０によれば、デジタルコンテンツ１２の所有者は、そのデジタルコンテンツ１２がユーザのコンピューティングデバイス１４上でレンダリングされる前に満足しなければならないライセンスルールを指定することが可能になっている。このライセンスルールは、ユーザ/ユーザのコンピューティングデバイス (user's computing device) １４（以下では、これらの用語は同じ意味で用いられている）がコンテンツ所有者またはそのエージェントから取得しなければならないデジタルライセンス１６に組み込まれている。デジタルコンテンツ１２は暗号化形式 (encrypted form) で配信されるが、自由にかつ幅広く配信されることがある。好ましくは、デジタルコンテンツ１２を解読するための解読（復号）鍵 (decrypting key  KD) はライセンス１６に組み込まれている。
【００１４】
コンピュータ環境
図１３と以下の説明は、本発明および/またはその一部を実現することができる適当なコンピューティング環境の全体を要約して説明することを目的としている。必ずしもその必要はないが、本発明は、プログラムモジュールのように、クライアントワークステーションやサーバなどのコンピュータによって実行されるコンピュータ実行可能命令の広い意味で説明されている。一般的に、プログラムモジュールとしては、特定のタスクを実行し、あるいは特定の抽象データ型を実装しているルーチン、プログラム、オブジェクト、コンポーネント、データ構造などがある。さらに、当然に理解されるように、本発明および/またはその一部は、他のコンピュータシステム構成で実施することも可能であり、その中には、ハンドヘルドデバイス、マルチプロセッサシステム、マイクロプロセッサベースまたはプログラマブルコンシューマエレクトロニクス、ネットワークPC、ミニコンピュータ、メインフレームコンピュータなどが含まれている。また、本発明は、分散型コンピューティング環境で実施することも可能であり、そこでは、タスクは、通信ネットワークを通してリンクされたリモート処理デバイスによって実行されている。分散型コンピューティング環境では、プログラムモジュールは、ローカルとリモートの両方のメモリストレージデバイスに置いておくことができる。
【００１５】
図１３に示すように、例示の汎用コンピューティングシステムは従来のパーソナルコンピュータ１２０などを含み、パーソナルコンピュータは処理ユニット１２１、システムメモリ１２２、およびシステムメモリを含む種々のシステムコンポーネントを処理ユニット１２１に結合しているシステムバス１２３を装備している。システムバス１２３は、数種タイプのバス構造のいずれかにすることができ、その中には、種々のバスアーキテクチャのいずれかを採用したメモリバスまたはメモリコントローラ、ペリフェラル（周辺）バス、およびローカルバスが含まれている。システムメモリには、リードオンリメモリ (read only memory  ROM) １２４とランダムアクセスメモリ (random access memory  RAM) １２５が含まれている。スタートアップ時のときのように、パーソナルコンピュータ内のエレメント間で情報を転送するのを支援する基本ルーチンで構成された基本入出力システム (basic input/output system  BIOS) １２６は、ROM １２４に格納されている。
【００１６】
パーソナルコンピュータ１２０は、さらに、ハードディスク（図示せず）との間で読み書きを行うハードディスクドライブ１２７、取り外し可能磁気ディスク１２９との間で読み書きを行う磁気ディスクドライブ１２８、およびCD-ROMや他の光媒体などの取り外し可能光ディスク１３１との間で読み書きを行う光ディスクドライブ１３０を装備している。ハードディスクドライブ１２７、磁気ディスクドライブ１２８、および光ディスクドライブ１３０は、それぞれハードディスクドライブインタフェース１３２、磁気ディスクドライブインタフェース１３３、および光ディスクドライブインタフェース１３４を介してシステムバス１２３に接続されている。これらのドライブとそれぞれに関連するコンピュータ読取可能媒体は、不揮発性ストレージとしてコンピュータ読取可能命令、データ構造、プログラムモジュールおよび他のデータをパーソナルコンピュータ１２０のために格納している。
【００１７】
ここで説明している例示環境では、ハードディスク、取り外し可能磁気ディスク１２９、および取り外し可能光ディスク１３１が採用されているが、当然に理解されるように、コンピュータによってアクセス可能であるデータを格納して置くことができる他のタイプのコンピュータ読取可能媒体を、例示動作環境で採用することも可能である。そのような他のタイプの媒体としては、磁気カセット、フラッシュメモリカード、デジタルビデオディスク、ベルヌーイ (Bernoulli) カートリッジ、ランダムアクセスメモリ (RAM)、リードオンリメモリ (ROM) などがある。
【００１８】
いくつかのプログラムモジュールは、ハードディスク、磁気ディスク１２９、光ディスク１３１、ROM １２４またはRAM １２５に格納しておくことが可能であり、そのようなものとして、オペレーティングシステム１３５、１つまたは２つ以上のアプリケーションプログラム１３６、他のプログラムモジュール１３７およびプログラムデータ１３８がある。ユーザは、キーボード１４０やポインティングデバイス１４２などの入力デバイスを通してコマンドと情報をパーソナルコンピュータ１２０に入力することができる。他の入力デバイス（図示せず）としては、マイクロホン、ゲームパッド、サテライトディッシュ、スキャナなどがある。上記および他の入力デバイスは、システムバスに結合されたシリアルポートインタフェース１４６を通して処理ユニット１２１に接続されていることが多いが、パラレルポートやゲームポート、ユニバーサルシリアルバス (universal serial bus  USB) などの、他のインタフェースで接続することも可能である。モニタ１４７や他のタイプのディスプレイデバイスも、ビデオアダプタ１４８などのインタフェースを介してシステムバス１２３に接続されている。モニタ１４７のほかに、パーソナルコンピュータは、スピーカやプリンタなどの他のペリフェラル（周辺）出力デバイス（図示せず）を装備しているのが代表的である。図１３の例示システムは、ホストアダプタ１５５、小型コンピュータシステムインタフェース (Small Computer System Interface  SCSI) バス１５６、およびSCSIバス１５６に接続された外部ストレージデバイス１６１も含んでいる。
【００１９】
パーソナルコンピュータ１２０は、リモートコンピュータ１４９などの、１つまたは２つ以上のリモートコンピュータとの論理コネクションを使用するネットワーキング環境で動作することができる。リモートコンピュータ１４９は、別のパーソナルコンピュータ、サーバ、ルータ、ネットワークPC、ピアデバイスまたは他の共通ネットワークノードにすることが可能であり、図１３にはメモリストレージデバイス１５０だけが示されているが、パーソナルコンピュータ１２０に関して上述したエレメントの多くまたは全部を装備しているのが代表的である。図１３に示す論理コネクションとしては、ローカルエリアネットワーク (local area network  LAN) １５１と広域ネットワーク (wide area network  WAN) １５２がある。このようなネットワーキング環境は、オフィス、企業内 (enterprise-wide) コンピュータネットワーク、イントラネット (intranet)、およびインターネット (the Internet) で普及している。
【００２０】
LANネットワーキング環境で使用されるときは、パーソナルコンピュータ１２０は、ネットワークインタフェースまたはアダプタ１５３を通してLAN １５１に接続されている。WANネットワーキング環境で使用されるときは、パーソナルコンピュータ１２０は、インターネットなどの広域ネットワーク１５２上のコミュニケーションを確立するためのモデム１５４や他の手段を装備しているのが代表的である。モデム１５４は内蔵型と外付け型があるが、どちらも、シリアルポートインタフェース１４６を介してシステムバス１２３に接続されている。ネットワーキング環境では、パーソナルコンピュータ１２０に関して上述したプログラムモジュールまたはその一部は、リモートメモリストレージデバイスに格納しておくことが可能である。当然に理解されるように、図示のネットワークコネクションは例示であり、コンピュータ間の通信リンクを確立する他の手段を使用することも可能である。
【００２１】
アーキテクチャ
図１に戻って説明すると、本発明の一実施形態では、アーキテクチャ１０は、上述したユーザのコンピューティングデバイス１４のほかに、オーサリングツール (authoring tool) １８、コンテンツ鍵データベース２０、コンテンツサーバ２２、ライセンスサーバ２４、およびブラックボックスサーバ２６を含んでいる。
【００２２】
アーキテクチャ − オーサリングツール１８
オーサリングツール１８は、本発明のアーキテクチャ１０に関連して使用するのに扱い易い形体に１つのデジタルコンテンツ１２をパッケージ化するためにコンテンツ所有者によって使用される。具体的には、コンテンツ所有者は、デジタルコンテンツ１２、そのデジタルコンテンツ１２に付属させる指示および/またはルール、およびデジタルコンテンツ１２をどのようにパッケージ化させるかの指示および/またはルールをオーサリングツール１８に与えている。これを受けて、オーサリングツール１８は、暗号化/解読鍵に従って暗号化されたデジタルコンテンツ１２と、そのデジタルコンテンツ１２に付属する指示および/またはルールとを収めているデジタルコンテンツパッケージ１２ｐを出力する。
【００２３】
本発明の一実施形態では、オーサリングツール１８は、各々が異なる暗号化/解読鍵に従って暗号化された同じデジタルコンテンツ１２を収めている、いくつかの異なるデジタルコンテンツ１２のパッケージ１２ｐをシリアルに作成するように指示される。当然に理解されるように、いくつかの異なるパッケージ１２に同じデジタルコンテンツ１２を収めておくと、そのパッケージ１２ｐ/コンテンツ１２（以下では、特別な事情の場合を除き、単に「デジタルコンテンツ１２」と称す）の配信をトラッキング（追跡）するのに好都合である。この配信トラッキングは通常では必要でないが、デジタルコンテンツ１２が不法に販売またはブロードキャストされた場合には、調査当局によって使用されることがある。
【００２４】
本発明の一実施形態では、デジタルコンテンツ１２を暗号化する暗号化/解読鍵は、暗号化鍵は解読鍵 (KD) でもあるという意味で対称鍵 (symmetric key) になっている。以下で詳しく説明されているように、この解読鍵 (KD) は、そのデジタルコンテンツ１２のライセンスの一部として、見えない形でユーザのコンピューティングデバイス１４に送付される。好ましくは、１つひとつのデジタルコンテンツ１２はコンテンツIDをもち（または各パッケージ１２ｐはパッケージIDをもち）、各々の解読鍵 (KD) は鍵IDをもち、オーサリングツール１８は、１つひとつのデジタルコンテンツ１２の（または各パッケージ１２ｐの）解読鍵 (KD)、鍵ID、およびコンテンツID（またはパッケージID）を、コンテンツ鍵データベース２０にストアしておくようにする。さらに、デジタルコンテンツ１２について発行されるライセンス１６のタイプ、およびライセンスのタイプ別の条項と条件に関するライセンスデータは、コンテンツ鍵データベース２０にストアしておくことも、別のデータベース（図示せず）にストアしておくことも可能になっている。好ましくは、ライセンスデータは、事情とマーケット状態の要求に応じて、その後にコンテンツ所有者によって修正できるようになっている。
【００２５】
使用時には、特に、次のような情報がオーサリングツール１８に与えられる。
−  パッケージ化されるデジタルコンテンツ１２、
−  透かし (watermarking) および/または指紋が採用される場合、そのタイプとパラメータ、
−  データ圧縮が採用される場合、そのタイプとパラメータ、
−  採用される暗号化のタイプとパラメータ、および
−  デジタルコンテンツ１２に付属させる指示および/またはルール。
【００２６】
公知のように、透かしは、識別子 (ID) としてデジタルコンテンツ１２に付加される、目に見えないコンピュータ読取可能信号である。指紋は、インスタントごとに異なる透かしである。当然に理解されるように、インスタンス (instance) とは、それぞれがユニーク（一意的、固有）であるデジタルコンテンツ１２のバージョンである。どのインスタンスも、複数のコピーを作ることが可能であり、どのコピーも、特定のインスタンスに属している。デジタルコンテンツ１２の特定インスタンスが不法に販売またはブロードキャストされたとき、調査当局は、おそらく、そのデジタルコンテンツ１２に付加された透かし/指紋に従って容疑者を特定することができる。
【００２７】
データ圧縮 (data compression) は、本発明の精神と範囲から逸脱しない限り、任意の該当圧縮アルゴリズムに従って行うことができる。例えば、.mp3または.wav圧縮アルゴリズムを使用することができる。当然のことであるが、デジタルコンテンツ１２は、すでに圧縮状態にあることがあり、その場合には、付加的圧縮は不要である。
【００２８】
デジタルコンテンツ１２に付属させる指示および/またはルールとしては、本発明の精神と範囲から逸脱しない限り、ほとんどどのような該当指示、ルール、または他の情報にすることも可能である。以下で説明するように、付属する指示/ルール/情報は、デジタルコンテンツ１２をレンダリングするためのライセンス１６を得るために、主にユーザとユーザのコンピューティングデバイス１４によって使用される。従って、付属する指示/ルール/情報には、以下に詳しく説明されているように、適当にフォーマットされたライセンス取得スクリプトなどを含めておくことができる。付加的に、あるいは代替方法として、付属する指示/ルール/情報には、ユーザがデジタルコンテンツ１２をプレビューできるようにする「プレビュー」情報を含めておくことができる。
【００２９】
与えられた情報を使用して、オーサリングツール１８は、デジタルコンテンツ１２に対応する１つまたは２つ以上のパッケージ１２ｐを作成する。各パッケージ１２ｐは、外部への配信に備えてコンテンツサーバ２２にストアしておくことができる。
【００３０】
本発明の一実施形態では、図２を参照して説明すると、オーサリングツール１８は、ダイナミックオーサリングツール１８として、指定が可能で、操作を加えることができる入力パラメータを受け取る。従って、このオーサリングツール１８は、複数個のデジタルコンテンツ１２について複数種類のパッケージ１２ｐを高速に作成することができる。好ましくは、入力パラメータは、図示のように、ディクショナリ２８の形で具現化され、ディクショナリ２８には、次のようなパラメータが収められている。
−  デジタルコンテンツ１２を収めている入力ファイル２９ａの名前、
−  行われる符号化（エンコード）のタイプ、
−  採用される暗号化/解読鍵 (KD)、
−  デジタルコンテンツ１２と一緒にパッケージ１２ｐにパッケージ化される付属指示/ルール/情報（「ヘッダ情報」）、
−  行われる多重化 (muxing) のタイプ、および
−  デジタルコンテンツ１２に基づくパッケージ１２ｐが書き出される出力ファイル２９ｂの名前。
【００３１】
以上から理解されるように、このディクショナリ２８はオーサリングツール２８のオペレータ（人間またはマシン）によって容易かつ高速に修正可能であるので、オーサリングツール１８によって実行されるオーサリングのタイプも、同じようにダイナミックに容易かつ高速に修正可能である。本発明の一実施形態では、オーサリングツール１８は、人間のオペレータにコンピュータスクリーンから表示可能であるオペレータインタフェース（図示せず）を備えている。従って、人間のオペレータは、このインタフェースを通してディクショナリ２８を修正することができ、さらに、このインタフェースを通してディクショナリを修正するのを支援および/または制限することが可能になっている。
【００３２】
オーサリングツール１８では、図２に示すように、ソースフィルタ (source filter) １８ａは、デジタルコンテンツ１２を収めている入力ファイル２９ａの名前をディクショナリ２８から受け取り、そのデジタルコンテンツ１２をその入力ファイルから取り出し、デジタルコンテンツ１２をRAMなどのメモリ２９ｃに入れておく。そのあと、符号化フィルタ (encoding filter) １８ｂは、メモリ２９ｃに入っているデジタルコンテンツ１２に対して符号化を行い、ディクショナリ２８の中に指定されている符号化のタイプに従ってファイルを入力フォーマットから出力フォーマットに変換し（つまり、.wavから.aspに、.mp3から.aspに、など）、符号化デジタルコンテンツ１２をメモリ２９ｃに入れておく。図示のように、パッケージ化されるデジタルコンテンツ１２（例えば、ミュージック）は、.wavや.mp3フォーマットのような圧縮フォーマットで受け取られ、.asp（アクティブストリーミングプロトコル(active streaming protocol)）フォーマットなどのフォーマットに変換される。当然のことであるが、本発明の精神と範囲から逸脱しない限り、他の入力フォーマットや出力フォーマットを採用することも可能である。
【００３３】
そのあと、暗号化フィルタ (encryption filter) １８ｃは、ディクショナリ２８の中に指定されている暗号化/解読鍵 (KD) に従って、メモリ２９ｃ内の符号化デジタルコンテンツ１２を暗号化し、その暗号化デジタルコンテンツ１２をメモリ１２に入れておく。次に、ヘッダフィルタ (header filter) １８ｄは、ディクショナリ２８の中に指定されているヘッダ情報を、メモリ２９c内の暗号化デジタルコンテンツ１２に追加する。
【００３４】
当然に理解されるように、事情によっては、パッケージ１２ｐは、一時的に位置合わせされたデジタルコンテンツ１２の複数ストリームを含んでいる場合があり（その１つは図２に示されている）、そこでは、これらのストリームは多重化（つまり、"muxing"）されている。従って、多重化 (mux) フィルタ１８ｅは、ディクショナリ２８の中に指定されている多重化のタイプに従って、メモリ２９ｃに入っているヘッダ情報と暗号化デジタルコンテンツ１２に対して多重化を行い、その結果をメモリ２９ｃに入れておく。次に、ファイル書込みフィルタ (file writer filter) １８ｆは、前記結果をメモリ２９ｃから取り出し、ディクショナリ２８の中に指定されている出力ファイルにその結果をパッケージ１２ｐとして書き出す。
【００３５】
ここで注意すべきことは、事情によっては、実行される符号化のタイプは変わらないのが通常であることである。多重化 (muxing) のタイプは符号化のタイプに基づいているのが代表的であるので、多重化のタイプの場合も、同じように変わらないのが通常である。このことが実際に該当する場合には、符号化のタイプおよび/または多重化のタイプに関するパラメータは、ディクショナリ２８に入れておく必要がない。その代わりに、必要になるのは、多重化のタイプを「ハードワイヤド（ハード布線）」してmuxフィルタに組み入れておくことだけである。当然のことであるが、事情によっては、オーサリングツール１８は上述したフィルタのすべて備えていないこともあれば、他のフィルタを備えていることもあり、どのフィルタの場合も、ハードワイヤドでフィルタに組み入れることも、ディクショナリ２８の中で指定されているパラメータに従ってその関数を実行させることもできる。なお、これらは、すべて本発明の精神と範囲に含まれるものである。
【００３６】
好ましくは、オーサリングツール１８は、該当するソフトウェアを通して、該当するコンピュータ、プロセッサ、または他のコンピューティングマシン上に実現されている。このマシンとこのソフトウェアの構造と動作は、本明細書に開示されている説明を読めば理解できるはずであるので、本明細書ではこれ以上詳しく論じることは省略する。
【００３７】
アーキテクチャ − コンテンツサーバ２２
図１に戻って説明すると、本発明の一実施形態では、コンテンツサーバ２２は、オーサリングツール１８によって作成されたパッケージ１２ｐを配信し、さもなければ、取り出しができるようにする。このパッケージ１２ｐは、本発明の精神と範囲から逸脱しない限り、なんらかの該当配信チャネルを通して、コンテンツサーバ２２の要求に応じて配信することができる。例えば、この配信チャネルは、インターネットや別のネットワーク、電子掲示板 (electronic bulletin board)、電子メールなどにすることができる。さらに、コンテンツサーバ２２は、パッケージ１２ｐを磁気ディスクや光ディスクまたは他のストレージデバイス上にコピーするために使用できるので、そのあとでそのストレージデバイスを配信することができる。
【００３８】
以上から理解されるように、コンテンツサーバ２２は、信用上またはセキュリティ上の問題とは無関係にパッケージ１２ｐを配信する。以下で説明するように、この問題は、ライセンスサーバ２４およびそのライセンスサーバ２４とユーザのコンピューティングデバイス１４間の関係との関連で処理される。本発明の一実施形態では、コンテンツサーバ２２は、デジタルコンテンツ１２を収めているパッケージを自由に解放し、そのパッケージを要求する配信先に配信する。しかし、コンテンツサーバ１２は、本発明の精神と範囲から逸脱しない限り、制限された形でパッケージ１２ｐを解放し、配信することもできる。例えば、コンテンツサーバ２２は、事前に決めた配信料の支払いを先に要求してから配信を行うことも、配信先が本人であることを要求することも、あるいは配信を行うかどうかを配信先のIDに基づいて行うこともできる。
【００３９】
さらに、コンテンツサーバ２２を使用すると、将来の需要を見込んでいくつかの異なるパッケージ１２ｐを生成するようにオーサリングツール１８を制御することによって、インベントリ管理を行うことができる。例えば、このサーバは、同じデジタルコンテンツ１２に基づいて100個のパッケージを生成すれば、各々のパッケージ１２ｐを10回役立てることができる。例えば、パッケージ１２ｐのサプライが20に減少したとき、コンテンツサーバ２２は、例えば、この場合も、80個の追加パッケージを生成するようにオーサリングツール１８に指示することができる。
【００４０】
好ましくは、アーキテクチャ１０におけるコンテンツサーバ２２は、ユニークな公開鍵/秘密鍵ペア (PU-CS, PR-CS) をもち、これは、ライセンス１６を評価し、対応するデジタルコンテンツ１２を解読するための解読鍵 (KD) を取得するプロセスの一部として使用される。なお、これについては、以下で詳しく説明する。公知であるように、公開鍵/秘密鍵ペアは、鍵ペアの中の一方の鍵で暗号化されたものは、鍵ペアの中の他方の鍵によってのみ解読できるという意味で、非対称鍵 (asymmetric key) である。公開鍵/秘密鍵ペア暗号化システムでは、公開鍵は、外部に知らせることができるのに対し、秘密鍵は、その秘密鍵の所有者によって常に秘密に保たれている。従って、コンテンツサーバ２２が秘密鍵 (PR-CS) でデータを暗号化したときは、解読目的のためにその公開鍵 (PU-CS) と一緒に暗号化データを外部に送出することができる。これに対して、外部デバイスがデータをコンテンツサーバ２２に送信し、そのコンテンツサーバ２２だけがそのデータを解読できるようにしたい場合には、外部デバイスは、まず、コンテンツサーバ２２の公開鍵 (PU-CS) を取得する必要があり、そのあとでその公開鍵でデータを暗号化しなければならない。従って、コンテンツサーバ２２（およびコンテンツサーバ２２のみ）はその秘密鍵 (PR-CS) を使用して、その暗号化データを解読することが可能になる。
【００４１】
オーサリングツール１８の場合と同じように、コンテンツサーバ２２は、該当ソフトウェアを通して該当コンピュータ、プロセッサ、または他のコンピューティングマシン上に実現されている。このマシンとこのソフトウェアの構造と動作は、本明細書の説明を読めば理解できるはずであるので、本明細書ではこれ以上詳しく論じることは省略する。さらに、本発明の一実施形態では、オーサリングツール１８とコンテンツサーバ２２は、シングルコンピュータ、プロセッサまたは他のコンピューティングマシン上で、それぞれ別のワークスペースに置いておくことができる。さらに、当然に理解されるように、コンテンツサーバ２２は、事情によっては、オーサリングツール１８を組み入れておくことも、および/またはオーサリングツール１８の機能を実行させることも可能である。これは、上述した通りである。
【００４２】
デジタルコンテンツパッケージ１２ｐの構造
次に、図３を参照して説明すると、本発明の一実施形態では、コンテンツサーバ２２によって配信されるときのデジタルコンテンツパッケージ１２ｐは、次のものを含んでいる。
−  上述したように暗号化/解読鍵 (KD) を使用して暗号化されたデジタルコンテンツ１２（つまり、KD(CONTENT)）、
−  そのデジタルコンテンツ１２（またはパッケージ１２ｐ）のコンテンツID（またはパッケージID）、
−  解読鍵 (KD) の鍵ID、
−  好ましくは、非暗号化形式になっているライセンス取得情報、および
−  コンテンツサーバ２２の公開鍵 (PU-CS) を暗号化する鍵IDであって、コンテンツサーバ２２の秘密鍵 (PR-CS) で署名されたもの（つまり、(KD(PU-CS) S (PR-CS))）。
【００４３】
(KD(PU-CS) S (PR-CS))に関して理解すべきことは、以下で説明するように、このアイテムは、デジタルコンテンツ１２および/またはパッケージ１２ｐが有効かどうかの検査に関連して使用されることである。デジタル署名付きの証明書（以下参照）とは異なり、鍵 (PU-CS) がなくても (KD (PU-CS) が得られる。その代わりに、鍵 (PU-CS) は、解読鍵 (KD) を適用するだけで得られる。鍵 (PU-CS) が得られると、この鍵は署名 (S(PR-CS) の有効性をテストするために使用できる。
【００４４】
また、当然に理解されるように、このパッケージ１２Ｐをオーサリングツール１８に構築させるためには、そのオーサリングツール１８は、ライセンス取得情報と(KD(PU-CS) S (PR-CS)) を、おそらくディクショナリ２８から得られるヘッダ情報としてすでに所有していなければならない。さらに、オーサリングツール１８とコンテンツサーバ２２は、おそらく相互にやりとりして(KD(PU-CS) S (PR-CS)) を構築しなければならない。このやりとりは、例えば、次のステップで行うことができる。
−  コンテンツサーバ２２は (PU-CS) をオーサリングツール１８に送信し、
−  オーサリングツール１８は (KD) で (PU-CS) を暗号化して (KD (PU-CS) を取得し、
−  オーサリングツール１８は (KD) (PU-CS) をコンテンツサーバ２２に送信し、
−  コンテンツサーバ２２は (PR-CS) で (KD (PU-CS)) に署名して(KD(PU-CS) S (PR-CS)) を取得し、
−  コンテンツサーバ２２は(KD(PU-CS) S (PR-CS)) をオーサリングツール１８に送信する。
【００４５】
アーキテクチャ − ライセンスサーバ２４
図１に戻って説明すると、本発明の一実施形態では、ライセンスサーバ２４は、１つのデジタルコンテンツ１２に関連してライセンス１６を求める要求をユーザのコンピューティングデバイス１４から受信し、ユーザのコンピューティングデバイス１４が、発行されるライセンス１６を尊重するものとして信用できるかどうかを判断し、そのライセンス１６を交渉し、そのライセンス１６を構築し、そのライセンス１６をユーザのコンピューティングデバイス１４に送信する機能を実行する。好ましくは、送信されるライセンス１６には、デジタルコンテンツ１２を解読するための解読鍵 (KD) が含まれている。ライセンスサーバ２４と上記機能は、以下に詳しく説明されている。好ましくは、コンテンツサーバ２２と同様に、アーキテクチャ１０におけるライセンスサーバ２４は、ユニークな公開/秘密鍵ペア (PU-LS, PR-LS) を所有し、これは、ライセンス１６を評価し、対応するデジタルコンテンツ１２を解読するための解読鍵 (KD) を取得するプロセスの一部として使用される。なお、これについては、以下で詳しく説明する。
【００４６】
オーサリングツール１８およびコンテンツサーバ２２の場合と同様に、ライセンスサーバ２４は、該当ソフトウェアを通して該当コンピュータ、プロセッサ、または他のコンピューティングマシン上に実現されている。このマシンとこのソフトウェアの構造と動作は、本明細書に開示されている説明を読めば理解できるはずであるので、本明細書ではこれ以上詳しく論じることは省略する。さらに、本発明の一実施形態では、オーサリングツール１８および/またはコンテンツサーバ２２は、シングルコンピュータ、プロセッサ、または他のコンピューティングマシン上で、ライセンスサーバ２４と一緒にそれぞれ別のワークスペースに置いておくことができる。
【００４７】
本発明の一実施形態では、ライセンス１６の発行に先立って、ライセンスサーバ２４とコンテンツサーバ２２はエージェント契約などを結び、そこでは、ライセンスサーバ２４は、コンテンツサーバ２２によって配信されるデジタルコンテンツ１２の少なくとも一部について事実上のライセンシング機関 (licensing authority：ライセンス許託機関) となることに同意する。当然に理解されるように、本発明の精神と範囲から逸脱しない限り、１つのコンテンツサーバ２２が複数のライセンスサーバ２４とエージェント契約などを結ぶことも、および/または１つのライセンスサーバ２４が複数のコンテンツサーバ２２とエージェント契約などを結ぶことも可能である。
【００４８】
好ましくは、ライセンスサーバ２４は、コンテンツサーバ２２によって配信されたデジタルコンテンツ１２に対してライセンスを発行する権限を事実上有していることを外部に示すことができる。これを行うための好ましい方法は、ライセンスサーバ２４がライセンスサーバ２４の公開鍵 (PU-CS) をコンテンツサーバ２２に送信し、これを受けて、コンテンツサーバ２２がコンテンツサーバ２２の秘密鍵 (CERT (PU-LS) S (PR-CS) で署名されたコンテンツとして、PU-LSを収めているデジタル証明書をライセンスサーバ２４に送信することである。当然に理解されるように、この証明書の中のコンテンツ (PU-LS) は、コンテンツサーバ２２の公開鍵 (PU-CS) を使用してのみアクセス可能になっている。また、当然に理解されるように、一般に、基礎となるデータのデジタル署名は、そのデータを暗号化した形になっているので、そのデータが不正に改変されているか、あるいは他の方法で修正されていると、解読時にそのデータに一致しないことになる。
【００４９】
１つのデジタルコンテンツ１２に関係するライセンシング機関(licensing authority)として、およびライセンシング機能の一部として、ライセンスサーバ２４は、そのデジタルコンテンツ１２に対応する解読鍵 (KD) にアクセスできなければならない。従って、好ましいことは、そのデジタルコンテンツ１２（またはパッケージ１２Ｐ）に対応する解読鍵 (KD)、鍵ID、およびコンテンツID（またはパッケージID）が置かれているコンテンツ鍵データベース２０にライセンスサーバ２４がアクセスできることである。
【００５０】
アーキテクチャ − ブラックボックスサーバ２６
引き続き図１を参照して説明すると、本発明の一実施形態では、ブラックボックスサーバ２６は、新しいブラックボックス３０をユーザのコンピューティングデバイス１４にインストールおよび/またはアップグレード（バージョンアップ）する機能を実行する。以下に詳しく説明されているように、ブラックボックス３０は、ユーザのコンピューティングデバイス１４のために暗号化と解読機能を実行する。これも以下に詳しく説明されているように、ブラックボックス３０は、攻撃からセキュアで、保護されることを目的としている。このセキュリティと保護は、少なくともその一部は、以下で詳しく説明するように、ブラックボックスサーバ２６を通してブラックボックス３０を必要時に新バージョンにアップグレードすることにより得られている。
【００５１】
オーサリングツール１８、コンテンツサーバ２２、およびライセンスサーバ２４の場合と同じように、ブラックボックスサーバ２０は、該当ソフトウェアを通して該当コンピュータ、プロセッサ、または他のコンピューティングマシン上に実現されている。このマシンとこのソフトウェアの構造と動作は、本明細書に開示されている説明を読めば理解できるはずであるので、本明細書ではこれ以上詳しく論じることは省略する。さらに、本発明の一実施形態では、ライセンスサーバ２４、オーサリングツール１８および/またはコンテンツサーバ２２は、シングルコンピュータ、プロセッサ、または他のコンピューティングマシン上で、ブラックボックスサーバ２６と一緒にそれぞれ別のワークスペースに置いておくことができる。なお、セキュリティ上の目的から、賢明な方法は、ブラックボックスサーバ２６を別のマシン上に置いておくことである。
【００５２】
アーキテクチャ − ユーザのコンピューティングデバイス１４
次に、図４を参照して説明すると、本発明の一実施形態では、ユーザのコンピューティングデバイス１４は、キーボード、マウス、スクリーン、プロセッサ、RAM、ROM、ハードドライブ、フロッピドライブ、CDプレイヤなどのエレメントを装備したパーソナルコンピュータなどである。しかし、ユーザのコンピューティングデバイス１４は、特に、テレビジョンやモニタなどの専用表示デバイス、ステレオや他のミュージックプレイヤなどの専用オーディオデバイス、専用プリンタなどにすることも可能であり、これらは、すべて本発明の精神と範囲に属するものである。
【００５３】
１つのデジタルコンテンツ１２のコンテンツ所有者は、ユーザのコンピューティングデバイス１４が、そのコンテンツ所有者によって指定されたルールに従うものと、つまり、求めた通りにレンダリングを許可しているライセンス１６をユーザが取得していなければ、デジタルコンテンツ１２はレンダリングされないものと、信用しなければならない。この場合、好ましくは、ユーザのコンピューティングデバイス１４は、デジタルコンテンツ１２に関連するライセンス１６であって、ユーザによって取得されたものに具現化されているライセンスルールに従う場合を除き、そのコンピューティングデバイス１４がデジタルコンテンツ１２をレンダリングしないことを、コンテンツ所有者に納得させるようなトラステッドコンポーネントまたはメカニズム３２を備えていなければならない。
【００５４】
ここで、トラステッド (trusted) メカニズム３２とは、デジタル化権 (Digital Rights Management  DRM) システム３２のことであり、これは、ユーザが１つのデジタルコンテンツ１２をレンダリングすることを要求したとき使用許可され、求めた通りにデジタルコンテンツ１２をレンダリングするライセンス１６をユーザがもっているかどうかを判断し、必要ならばそのライセンス１６を取得することを有効化し、ライセンス１６に従ってデジタルコンテンツ１２をプレイする権利をユーザがもっているかどうかを判断し、確かに、ユーザがそのライセンス１６に従った権利をもっていれば、レンダリング目的のためにデジタルコンテンツ１２を解読する。以下では、ユーザのコンピューティングデバイス１４に置かれていて、アーキテクチャ１０に関係するDRMシステム３２の内容と機能について説明する。
【００５５】
DRMシステム３２
DRMシステム３２は、本明細書に開示されているアーキテクチャ１０を使用して次の４つの主要機能を実行する。すなわち、(1) コンテンツ取得、(2) ライセンス取得、(3) コンテンツレンダリング、および (4) ブラックボックス３０のインストール/更新である。当然に理解されるように、これらの機能のなかには、デジタルコンテンツ１２がすでに取得されていることが要件になっているものがあるが、好ましくは、どの機能も、いつでも実行することが可能になっている。
【００５６】
DRMシステム３２ − コンテンツ取得
ユーザおよび/またはユーザのコンピューティングデバイス１４によるデジタルコンテンツ１２の取得は、相対的に単純な問題であるのが代表的であり、暗号化デジタルコンテンツ１２を収めているファイルをユーザのコンピューティングデバイス１４に置いておくことが行われるのが一般的である。当然のことであるが、本明細書に開示されているアーキテクチャ１０とDRMシステム３２を取り扱うためには、暗号化デジタルコンテンツ１２は、以下で説明するように、デジタルパッケージ１２ｐのように、そのアーキテクチャ１０とDRMシステム３２に扱い易い形になっていることが必要である。
【００５７】
当然に理解されるように、デジタルコンテンツ１２は、本発明の精神と範囲から逸脱しない限り、直接的にも、間接的にも、どのような方法でコンテンツサーバ２２から取得することも可能である。例えば、そのデジタルコンテンツ１２は、インターネットなどのネットワークからダウンロードすることも、取得した光ディスクや磁気ディスクなどに置いておくことも、Eメールメッセージなどの一部として受信することも、あるいは電子掲示板などからダウンロードすることも可能である。
【００５８】
取得されたあとのデジタルコンテンツ１２は、取得されたデジタルコンテンツ１２が、コンピューティングデバイス１４上で実行されているレンダリングアプリケーション３４（以下で説明する）とDRMシステム３２によってアクセスできるような形でストアしておくことが好ましい。例えば、デジタルコンテンツ１２は、ユーザのコンピューティングデバイス１４のハードディスク（図示せず）上にファイルとして置いておくことも、コンピューティングデバイス１４にアクセスできるネットワークサーバ側に置いておくこともできる。取得したデジタルコンテンツ１２を光ディスクや磁気ディスクなどに入れておく場合には、そのディスクは、ユーザのコンピューティングデバイス１４に結合された該当ドライブ（図示せず）に置いておくだけで済むことになる。
【００５９】
本発明では、デジタルコンテンツ１２は、直接配信ソースとしてはコンテンツサーバ２２からでも、間接配信ソースとしては途中に介在するものからでも、特別なツールを必要としないで取得されるようになっている。つまり、好ましいことは、デジタルコンテンツ１２が、他のデータファイルと同じように容易に取得されることである。しかし、DRMシステム３２および/またはレンダリングアプリケーション３４は、ユーザがデジタルコンテンツ１２を取得しやすくするインタフェースを備えることができる。例えば、インタフェースとしては、デジタルコンテンツ１２を探し出すように特別に設計されたWebブラウザ、デジタルコンテンツ１２のソースであることが分かっている事前定義インターネットWebサイトへのリンク、などがある。
【００６０】
DRMシステム３２ − コンテンツレンダリング、パート１
次に、図５を参照して説明すると、本発明の一実施形態では、暗号化デジタルコンテンツ１２がユーザに配信され、ユーザによって受信され、ストアファイル (stored file) の形でユーザによってコンピューティングデバイス１４上に置かれていることを前提として、ユーザは、レンダリングコマンド (render command) のなんらかの変種を実行することによって、デジタルコンテンツ１２をレンダリングすることを試みる（ステップ５０１）。例えば、このレンダリングコマンドは、デジタルコンテンツ１２を「プレイ」または「オープン」する要求として具現化することができる。例えば、MICROSOFT社 (Redmond, Washington) 提供の "MICROSOFT WINDOWS（登録商標）" オペレーティングシステムのような、ある種のコンピューティング環境では、このプレイ (play) またはオープン (open) コマンドは、デジタルコンテンツ１２を表すアイコンを「クリック」するのと同じように単純化することができる。当然のことであるが、本発明の精神と範囲から逸脱しない限り、このレンダリングコマンドは他の形態で実現することも可能である。一般的に、このレンダリングコマンドは、デジタルコンテンツ１２を収めているファイルをオープンし、ランし、実行することをユーザが指示すると、実行されるものと考えて差し支えない。
【００６１】
重要なことは、さらに、このレンダリングコマンドは、プリントフォーム、ビジュアルフォーム、オーディオフォームなどのように、デジタルコンテンツ１２を別のフォームにコピーする要求として具現化できることである。当然に理解されるように、同じデジタルコンテンツ１２をコンピュータスクリーン上といったように、あるフォームでレンダリングした後で、プリントドキュメントのような別のフォームでレンダリングすることができる。本発明では、各タイプのレンダリングは、以下で説明するように、ユーザがそうする権利を所有している場合にだけ実行される。
【００６２】
本発明の一実施形態では、デジタルコンテンツ１２は、最後にエクステンションが付いたファイル名をもつデジタルファイルの形体になっており、コンピューティングデバイス１４は、特定のレンダリングアプリケーション３４を始動するかどうかを、そのエクステンションに基づいて判断できるようになっている。例えば、デジタルコンテンツ１２がテキストファイルであることをファイル名のエクステンションが示していれば、レンダリングアプリケーション３４は、MICROSOFT社 (Redmond, Washington) 提供の"MICROSOFT WORD" のような、ある種のワードプロセッサになっている。同様に、デジタルコンテンツ１２がオーディオ、ビデオ、および/またはマルチメディアファイルであることをファイル名のエクステンションが示していれば、レンダリングアプリケーション３４は、MICROSOFT社 (Redmond, Washington) 提供の "MICROSOFT MEDIA PLAYER" のような、ある種のマルチメディアプレイヤになっている。
【００６３】
当然のことであるが、本発明の精神と範囲から逸脱しない限り、レンダリングアプリケーションを判断する他の方法を採用することも可能である。１つの例として、デジタルコンテンツ１２には、メタデータ (meta-data) （つまり、上述したヘッダ情報）を非暗号化形式で収めておくことが可能であり、メタデータとしては、そのデジタルコンテンツ１２をレンダリングするために必要なレンダリングアプリケーション３４のタイプに関する情報がある。
【００６４】
好ましくは、このレンダリングアプリケーション３４は、ファイル名に関連するデジタルコンテンツ１２を検査し、そのデジタルコンテンツ１２が権利保護の形で暗号化されているかどうかを判断する（ステップ５０３、５０５）。保護されていなければ、デジタルコンテンツ１２は、あとは苦もなくレンダリングされることになる。保護されていれば、レンダリングアプリケーション３４は、そのデジタルコンテンツ１２をプレイするにはDRMシステム３２が必要であることを、暗号化デジタルコンテンツ１２から判断する。従って、このレンダリングアプリケーション３４は、DRMシステム３２をそこでランするようにユーザのコンピューティングデバイス１４に指示する（ステップ５０９）。次に、そのレンダリングアプリケーションはそのDRMシステム３２をコールして、デジタルコンテンツ１２を解読する（ステップ５１１）。以下に詳しく説明されているように、DRMシステム３２が実際にデジタルコンテンツ１２を解読するのは、ユーザがそのデジタルコンテンツ１２の有効なライセンス１６と、有効なライセンス１６のライセンスルールに従ってデジタルコンテンツ１２をプレイする権利を所有しているときだけである。好ましくは、DRMシステム３２がレンダリングアプリケーションよってコールされると、DRMシステム３２は、少なくとも、ユーザがそのデジタルコンテンツ１２をプレイする権利を所有しているかどうかを判断する目的で、レンダリングアプリケーション３４からコントロール（制御権）を受け取る（ステップ５１３）。
【００６５】
DRMシステム３２のコンポーネント
本発明の一実施形態では、図４に戻って説明すると、DRMシステム３２は、ライセンスエバリュエータ (license evaluator：ライセンス評価装置) ３６、ブラックボックス３０、ライセンスストア（ライセンス記憶装置）３８、およびステートストア（状態記憶装置）４０を備えている。
【００６６】
DRMシステム３２のコンポーネント − ライセンスエバリュエータ３６
ライセンスエバリュエータ３６は、特に、要求されたデジタルコンテンツ１２に対応する１つまたは２つ以上のライセンス１６を探し出し、そのライセンスが有効かどうかを判断し、その有効なライセンスのライセンスルールをレビューし、要求側ユーザが要求デジタルコンテンツ１２を求めた通りにレンダリングする権利を所有しているかどうかを、レビューしたライセンスルールに基づいて判断する。当然に理解されるように、ライセンスエバリュエータ３６はDRMシステム３２におけるトラステッド (trusted) コンポーネントである。本明細書では、「トラステッド」とは、トラステッドエレメントがライセンス１６の権利記述に従ってデジタルコンテンツ１２の所有者の希望を遂行し、ユーザが不法であるか否かに関係なく、どの目的のためにもそのトラステッドエレメントを容易に改変できないことを、ライセンスサーバ２４（または他のトラストエレメント）に納得させることである。
【００６７】
ライセンスエバリュエータ３６は、ライセンスエバリュエータ３６が実際にライセンス１６を正しく評価することを保証し、ライセンスエバリュエータ３６がライセンス１６の実際の評価をバイパスする目的でユーザによって不法に改変または修正されなかったことを保証するように信用されている必要がある。従って、ライセンスエバリュエータ３６は、ユーザがライセンスエバリュエータ３６にアクセスするのを拒否するような形で、保護または庇護された環境で実行される。本発明の精神と範囲から逸脱しない限り、ライセンスエバリュエータ３６に関連して他の保護措置を採用できることはもちろんである。
【００６８】
DRMシステム３２のコンポーネント − ブラックボックス３０
主として、上述したように、ブラックボックス３０は、DRMシステム３２において暗号化と解読機能を実行する。具体的には、ブラックボックス３０は、ライセンスエバリュエータ３６と一緒に働いて、ライセンス評価機能の一部としてある種の情報を解読し、暗号化する。さらに、要求したデジタルコンテンツ１２を求めた通りにレンダリングする権利を、ユーザが確かに所有しているとライセンスエバリュエータ３６によって判断されると、そのデジタルコンテンツ１２の解読鍵 (KD) がブラックボックス３０に与えられ、ブラックボックス３０は、その解読鍵 (KD) に基づいてそのデジタルコンテンツ１２を解読する機能を実行する。
【００６９】
ブラックボックス３０も、DRMシステム３２におけるトラステッドコンポーネントになっている。具体的には、ライセンスサーバ２４は、ブラックボックス３０がライセンス１６のライセンスルールに従ってのみ解読機能を実行することを信用すると共に、ライセンス１６の実際の評価をバイパスする悪意の目的でブラックボックス３０がユーザによって不法に改変または修正されたとき、そのブラックボックス３０が動作しないことを信用しなければならない。従って、ブラックボックス３０も、ユーザがブラックボックス３０にアクセスするのを拒否するような形で、保護または庇護された環境で実行される。この場合も、本発明の精神と範囲から逸脱しない限り、ライセンスエバリュエータ３６に関連して他の保護措置を採用できることはもちろんである。好ましくは、コンテンツサーバ２２およびライセンスサーバ２４と同じように、DRMシステム３２におけるブラックボックス３０は、ユニークな公開/秘密鍵ベア (PU-BB, PR-BB) をもち、これは、以下で詳しく説明するように、ライセンス１６を評価し、デジタルコンテンツ１２を解読するための解読鍵を取得するプロセスの一部として使用されている。
【００７０】
DRMシステム３２のコンポーネント − ライセンスストア３８
ライセンスストア３８は、対応するデジタルコンテンツ１２を得るためにDRMシステム３２によって受け取られたライセンス１６をストアしている。ライセンスストア３８自体は、ライセンス１６をストアしておくだけであり、ライセンス１６の各々は、以下で説明するように、トラステッドコンポーネントがすでにそこに組み込まれているので、信用されている必要はない。本発明の一実施形態では、ライセンスストア３８は、ハードディスクドライブやネットワークドライブのようなドライブのサブディレクトリであるにすぎない。しかし、ライセンスストア３８は、DRMシステム３２にとって比較的都合のよいロケーションにライセンス１６をストアする機能を実行する限り、本発明の精神と範囲から逸脱しない限り、他の形体で具現化することも可能である。
【００７１】
DRMシステム３２のコンポーネント − ステートストア４０
ステートストア４０は、ライセンスストア３８に現在置かれている、または以前に置かれていたライセンス１６に対応するステート情報を保存しておく機能を実行する。このステート情報は、DRMシステム３２によって作成され、必要時にステートストア４０にストアされる。例えば、特定のライセンス１６が１つの対応するデジタルコンテンツを事前に決めた回数だけレンダリングすることを許可している場合は、ステートストア４０は、そのライセンス１６に関して実際になん回レンダリングが行われたかに関するステート情報を保存しておく。ステートストア４０は、今はライセンスストア３８に残っていないライセンス１６に関する情報をそのまま保存しておき、ライセンスストア３８からライセンス１６を削除したあとで、対応するステート情報をステートストア４０から削除する試みとして同じライセンス１６を取得すると有利になるような事態が起こるのを防止している。
【００７２】
ステートストア４０も、そこにストアされた情報がユーザにとってもっと有利になるステートにリセットされないことを保証するように信用されている必要がある。従って、ステートストア４０も同様に、ユーザがそのステートストア４０にアクセスするのを拒否する形で、保護または庇護された環境で実行されている。この場合も、本発明の精神と範囲から逸脱しない限り、ステートストア４０に関して他の保護措置を採用できることはもちろんである。例えば、ステートストア４０は、DRMシステム３２によってコンピューティングデバイス１４上に暗号化形式でストアしておくことができる。
【００７３】
DRMシステム３２ − コンテンツレンダリング、パート２
図５に戻って、コンテンツレンダリングについてもう一度説明すると、本発明の一実施形態では、DRMシステム３２がコール側レンダリングアプリケーション３４からコントロールを受け取ると、そのDRMシステム３２は、要求したデジタルコンテンツ１２を求めた通りにレンダリングする権利を、ユーザが所持しているかどうかを判断するプロセスを開始する。具体的には、DRMシステム３２は有効で、使用許可するライセンス１６をライセンスストアから探し出すか（ステップ５１５、５１７）、あるいは有効で、使用許可するライセンス１６をライセンスサーバ２４から取得することを試みる（つまり、以下で説明するライセンス取得機能を図８に示すように実行する）。
【００７４】
最初のステップとして、図７に示すように、そのDRMシステム３２のライセンスエバリュエータ３６は、デジタルコンテンツ１２に対応する、１つまたは２つ以上の受信済みライセンス１６が存在するかどうかを調べるためにライセンスストア３８をチェックする（ステップ６０１）。代表例として、ライセンス１６は、以下で説明するように、デジタルファイルの形になっているが、当然に理解されるように、ライセンス１６は、本発明の精神と範囲から逸脱しない限り、他の形体にすることも可能である。代表例として、ユーザは、ライセンス１６なしでデジタルコンテンツ１２を受信するが、この場合も、当然に理解されるように、本発明の精神と範囲から逸脱しない限り、デジタルコンテンツ１２は対応するライセンス１６付きで受信されることもある。
【００７５】
図３を参照して上述したように、１つひとつのデジタルコンテンツ１２は、そのデジタルコンテンツ１２（またはパッケージ１２ｐ）を特定するコンテンツID（またはパッケージID）、および暗号化デジタルコンテンツ１２を解読する解読鍵 (KD) を特定する鍵IDと一緒にパッケージ１２ｐに入っている。好ましくは、コンテンツID（またはパッケージID）と鍵IDは、非暗号化形体になっている。従って、具体的には、デジタルコンテンツ１２のコンテンツIDに基づいて、ライセンスエバリュエータ３６は、そのコンテンツIDに適応可能なIDをもつライセンス１６をライセンスストア３８から探し出す。なお、特に、デジタルコンテンツ１２の所有者がそのデジタルコンテンツ１２に対して複数種類のライセンス１６を指定していて、ユーザが複数のライセンス１６を取得していた場合には、複数のライセンス１６が見つかることがある。実際に、ライセンスエバリュエータ３６が、要求されたデジタルコンテンツ１２に対応するライセンス１６をライセンスストア３８に見つけなかったときは、DRMシステム３２は、以下で説明するように、ライセンス取得の機能（図５のステップ５１９）を実行することになる。
【００７６】
以下では、DRMシステム３２が１つのデジタルコンテンツ１２をレンダリングするように要求され、それに対応する１つまたは２つ以上のライセンス１６がライセンスストア３８に存在すると想定する。本発明の一実施形態では、その場合、DRMシステム３２のライセンスエバリュエータ３６は、各々のライセンス１６についてそのライセンス１６自体が有効であるかどうかを判断する処理に進む（図７のステップ６０３と６０５）。好ましくは、具体的には、各ライセンス１６は、ライセンス１６のコンテンツ２８に基づくデジタル署名２６を含んでいる。当然に理解されるように、デジタル署名２６は、コンテンツ２８が不法に改変または修正されていれば、ライセンス１６に一致しないことになる。従って、ライセンスエバリュエータ３６は、コンテンツ２８がライセンスサーバ２４から受信された形体になっているか（つまり、有効であるか）どうかを、デジタル署名２６に基づいて判断することができる。有効なライセンス１６がライセンスストア３８に見つからなければ、DRMシステム３２は、以下に説明するライセンス取得機能を実行すると、有効なライセンス１６が得られる。
【００７７】
１つまたは２つ以上の有効なライセンスが見つかったとすると、各々の有効なライセンスについて、DRMシステム３２のライセンスエバリュエータ３６は、次に、その有効なライセンスが、対応するデジタルコンテンツ１２を希望通りにレンダリングする権利をユーザに与えているか（つまり、使用許可しているか）どうかを判断する（ステップ６０７と６０９）。具体的には、ライセンスエバリュエータ３６は、要求側ユーザが要求したデジタルコンテンツ１２をプレイする権利を所持しているかどうかを、各ライセンス１６の権利記述に基づいて、およびユーザがデジタルコンテンツ１２をどのように扱おうとしているかに基づいて判断する。例えば、その権利記述は、ユーザがデジタルコンテンツ１２をサウンドにレンダリングするのを許可しているが、解読されたデジタルコピーにレンダリングすることは許可していない場合がある。
【００７８】
当然に理解されるように、各ライセンス１６の権利記述は、ユーザがデジタルコンテンツ１２をプレイする権利を所持しているかどうかを、いくつかのファクタに基づいて、つまり、そのユーザが誰であるか、そのユーザはどこにいるか、そのユーザはどのタイプのコンピューティングデバイス１４を使用しているか、どのようなレンダリングアプリケーション３４がDRMシステム３２をコールしているか、日付、時刻などに基づいて規定している。さらに、権利記述は、例えば、ライセンス１６をあらかじめ決めたプレイ回数に制限していることも、あらかじめ決めたプレイ時間に制限していることもある。そのようなケースでは、DRMシステム３２は、ライセンス１６に関するステート情報（つまり、デジタルコンテンツ１２がなん回レンダリングされたか、デジタルコンテンツ１２がレンダリングされた総時間量など）を参照する必要があり、その場合、そのステート情報は、ユーザのコンピューティングデバイス１４側のDRMシステム３２のステートストア４０にストアされている。
【００７９】
従って、DRMシステム３２のライセンスエバリュエータ３６は、各々の有効なライセンスの権利記述をレビューし、その有効なライセンス１６が、求められた権利をユーザに与えているかどうかを判断する。その際、ライセンスエバリュエータ３６は、ユーザのコンピューティングデバイス１４に固有の他のデータを参照して、ユーザが求められた権利を所持しているかどうかを判断しなければならない場合もある。図４に示すように、そのようなデータとしては、ユーザのコンピューティングデバイス（マシン）１４のID４２とその特定側面、ユーザのID４４とその特定側面、レンダリングアプリケーション３４のIDとその特定側面、システムクロック４６などがある。デジタルコンテンツ１２を求めた通りにレンダリングする権利をユーザに与えている有効なライセンス１６が見つからなかったときは、DRMシステム３２は、そのライセンス１６が実際に取得可能であれば、下述するライセンス取得機能を実行してそのライセンス１６を取得することができる。
【００８０】
当然のことであるが、場合によっては、デジタルコンテンツ１２のコンテンツ所有者は権利を許与することを実際に指示しているために、ユーザは要求した通りにデジタルコンテンツ１２をレンダリングする権利を取得できないことがある。例えば、そのデジタルコンテンツ１２のコンテンツ所有者は、ユーザがテキストドキュメントを印刷し、あるいはマルチメディアプレゼンテーションを非暗号化形体にコピーするのを許可するライセンス１６を許与しないと指示している場合がある。本発明の一実施形態では、デジタルコンテンツ１２は、ライセンス１６の購入時にどのような権利が利用可能であるかに関するデータと、利用可能なライセンス１６のタイプに関するデータを含んでいる。しかし、当然に理解されるように、１つのデジタルコンテンツ１２のコンテンツ所有者は、そのデジタルコンテンツ１２で利用できるライセンス１６を変更することにより、そのデジタルコンテンツ１２で現在利用できる権利をいつでも変更することができる。
【００８１】
DRMシステム３２ − ライセンス取得
次に、図８を参照して説明すると、実際に、ライセンスエバリュエ−タ３６が、要求されたデジタルコンテンツ１２に対応する有効で、使用許可しているライセンスをライセンスストア３８に見つけることができなかったとき、DRMシステム３２は、ライセンス取得の機能を実行することができる。図３に示すように、各々のデジタルコンテンツ１２は、そのデジタルコンテンツ１２をレンダリングするためのライセンス１６を取得する方法に関する情報（つまり、ライセンス取得情報）と一緒に非暗号化形体でパッケージ化されている。
【００８２】
本発明の一実施形態では、このライセンス取得情報としては、（特に）利用可能なライセンス１６のタイプ、および１つまたは２つ以上の該当ライセンスサーバ２４にそこからアクセスできる１つまたは２つ以上のインターネットWebサイトまたは他のサイト情報があり、そこでは、各ライセンスサーバ２４は、事実上、デジタルコンテンツ１２に対応するライセンス１６を発行する能力を備えている。当然のことであるが、ライセンス１６は、本発明の精神と範囲から逸脱しない限り、他の方法で取得することも可能である。例えば、ライセンス１６は、磁気ディスクや光ディスクなどに置かれたファイルの形体で、電子掲示板からでも、本人自らでも、通常のメールでも、ライセンスサーバ２４から取得することが可能である。
【００８３】
ライセンス１６を取得するためのロケーションが、実際にはネットワーク上のライセンスサーバ２４であるとすると、ライセンスエバリュエータ３６は、Webサイトまたは他のサイト情報に基づいて、そのライセンスサーバ２４とのネットワークコネクションを確立してから、コネクトされたライセンスサーバ２４からライセンス１６の要求を送信する（ステップ７０１、７０３）。具体的には、DRMシステム３２がライセンスサーバ２４にコンタクトすると、そのDRMシステム３２は、該当のライセンス要求情報３６をそのライセンスサーバ２４に送信する。本発明の一実施形態では、そのライセンス１６の要求情報３６としては、特に、次のものがある。
【００８４】
−  DRMシステム３２のブラックボックス３０の公開鍵 (PU-BB)、
−  DRMシステム３２のブラックボックス３０のバージョン番号、
−  証明機関からのデジタル署名付き証明書であって、ブラックボックス３０を証明しているもの（この証明書は、実際には、ブラックボックス３０の上記公開鍵とバージョン番号を含んでいる場合がある）、
−  デジタルコンテンツ１２（またはパッケージ１２ｐ）を特定しているコンテンツID（またはパッケージID）、
−  デジタルコンテンツ１２を解読する解読鍵 (KD) を特定している鍵ID、
−  要求されたライセンスのタイプ（実際には、複数のタイプが利用可能である場合）、および/または
−  その他。
【００８５】
当然のことであるが、本発明の精神と範囲から逸脱しない限り、DRMシステム３２によってライセンスサーバ２４に送信されるライセンス１６の要求情報３６の量は、もっと多くすることも、もっと少なくすることも可能である。例えば、レンダリングアプリケーション２４のタイプに関する情報は必要でない場合があるのに対し、ユーザおよび/またはユーザのコンピューティングデバイス１４に関する追加情報は必要になる場合がある。
【００８６】
ライセンスサーバ２４がDRMシステム３２からライセンス１６の要求情報３６を受信すると、ライセンスサーバ２４は、信用/認証 (trust/authentication) チェックや他の目的のチェックを行うことができる。本発明の一実施形態では、そのライセンスサーバ２４は、証明機関のデジタル署名付き証明書をチェックし、それが不法に改変または修正されていないかどうかを判断する（ステップ７０５、７０７）。改変または修正されていれば、ライセンスサーバ２４は、要求情報３６に基づくライセンス１６の許与をすべて拒否する。ライセンスサーバ２４は、「不正」ユーザおよび/またはユーザのコンピューティングデバイス１４と判明しているもののリストも保存しておくことができるので、そのリストに載っている不正ユーザおよび/またはユーザのコンピューティングデバイス１４からの要求に基づくライセンスの許与をすべて拒否することができる。この「不正」リストは、本発明の精神と範囲から逸脱しない限り、どのような方法でもコンパイルすることができる。
【００８７】
受信した要求とその要求に関連する情報に基づき、具体的には、ライセンス要求情報の中のコンテンツID（またはパッケージID）に基づき、ライセンスサーバ２４は、コンテンツ鍵データベース２０（図１）を調べ、要求の基礎となっているデジタルコンテンツ１２（またはパッケージ１２ｐ）に対応するレコードを探し出すことができる。上述したように、そのレコードは、デジタルコンテンツ１２に対する解読鍵 (KD)、鍵ID、およびコンテンツIDを収めている。さらに、このレコードには、デジタルコンテンツ１２について発行されるライセンス１６のタイプに関するライセンスデータ、およびライセンス１６のタイプ別の条項と条件を収めておくことも可能である。別の方法として、このレコードには、追加情報が置かれているロケーションを指すポインタ、リンク、またはレファレンス（参照）を含めておくこともできる。
【００８８】
上述したように、複数のタイプのライセンス１６を用意することができる。例えば、ライセンス使用料が比較的小額の場合は、レンダリングの回数を制限したライセンス１６を用意することができる。ライセンス使用料が比較的高額の場合は、満了日まで無制限にレンダリングを許容するライセンス１６を用意することができる。ライセンス使用料がもっと高額の場合は、無期限（満了日なし）に無制限にレンダリングを許容するライセンス１６を用意することができる。本発明の精神と範囲から逸脱しない限り、ライセンス条項を任意に定めた、ほとんどどのタイプのライセンスでも考案して、ライセンスサーバ２４に発行させることが可能である。
【００８９】
本発明の一実施形態では、ライセンス１６の要求は、ライセンスサーバ２４からユーザのコンピューティングデバイス１４に送信されるWebページなどを利用して行われる。好ましくは、このWebページは、ライセンス１６の基礎となっているデジタルコンテンツ１２についてライセンスサーバ２４から提供される、すべてのタイプのライセンス１６に関する情報を含んでいる。
【００９０】
本発明の一実施形態では、ライセンス１６の発行に先立って、ライセンスサーバ２４は、ブラックボックス３０のバージョン番号をチェックし、そのブラックボックス３０が相対的に最新 (relatively current) であるかどうかを判断する（ステップ７０９、７１１）。当然に理解されるように、ブラックボックス３０は、悪意の目的（つまり、デジタルコンテンツ１２をライセンス１２なしに不正にレンダリングし、あるいは対応するライセンス１６の条項から逸脱する目的）をもつユーザからの攻撃に対しセキュアで、保護されることを目的としている。しかし、当然に理解されるように、どのシステムも、どのソフトウェアデバイスも、実際には、そのような攻撃から完全にセキュアになっていない。
【００９１】
また、当然に理解されるように、ブラックボックス３０が相対的に最新であれば、つまり、相対的に最近に取得または更新されたものであれば、そのブラックボックス３０が悪意のユーザによって攻撃され、それが成功する確率は低くなる。好ましくは、信用の問題として、ライセンスサーバ２４が、相対的に最新でないブラックボックス３０のバージョン番号を含んでいる要求情報３６と共にライセンス要求を受信したときは、そのライセンスサーバ２４は、以下で説明するように、対応するブラックボックス３０が最新 (current) バージョンにアップグレードされるまで、要求されたライセンス１６の発行を拒否する。簡単に説明すると、ライセンスサーバ２４は、ブラックボックス３０が相対的に最新のものでなければ、そのブラックボックス３０を信用しないことになる。
【００９２】
本発明のブラックボックス３０のコンテキストにおいて、「最新(current)」または「相対的に最新(relatively current)」という用語は、本発明の精神と範囲から逸脱しない限り、その経過年数または使用年数に基づいてブラックボックス３０を信用する機能と矛盾しない意味で用いられている。例えば、「最新」は、経過年数（つまり、一ヶ月以上経過している）に従って定義することができる。別の例として、「最新」は、ブラックボックス３０がデジタルコンテンツ１２を解読した回数（つまり、解読が200回以上行われた）に基づいて定義することもできる。さらに、「最新」は、各ライセンスサーバ２４によって設定されたポリシに基づくことも可能であり、その場合、あるライセンスサーバ２４は、「最新」について別のライセンスサーバ２４とは異なった定義を行うことができ、さらに、ライセンスサーバ２４は、特に、ライセンス１６の要求の基となったデジタルコンテンツ１２に応じて、あるいは要求されたライセンス１６のタイプに応じて、「最新」について異なった定義を行うことも可能である。
【００９３】
そのブラックボックス３０が最新のものであると、ライセンスサーバ２４がブラックボックス３０のバージョン番号や他の指標から納得したとすると、ライセンスサーバ２４は次に進み、ライセンス１６の条項と条件についてユーザと交渉することになる（ステップ７１３）。別の方法として、ライセンスサーバ２４はライセンス１６についてユーザと交渉してから、そのブラックボックス３０が最新のものであると、ブラックボックス３０のバージョン番号から納得することもある（つまり、ステップ７１３を実行してからステップ７１１を実行する）。当然のことであるが、どの程度の交渉が行われるかは、発行されるライセンス１６のタイプや他のファクタによって異なる。例えば、ライセンスサーバ２４が支払済みの使用無制限ライセンス１６を発行するだけの場合は、ほとんど交渉しないで済むことになる。他方、ライセンス１６が可変価格、スライディングスケール (sliding scales)、ブレークポイント (breaking point) などのアイテムやその他の明細に基づく場合は、そのアイテムと明細をライセンスサーバ２４とユーザの間で解決してから、ライセンス１６が発行されるようにすることができる。
【００９４】
当然に理解されるように、事情によっては、ライセンス交渉では、ユーザが別の情報（例えば、ユーザ、ユーザのコンピューティングデバイス１４などに関する情報）をライセンスサーバ２４に提供する必要が起こることがある。重要なことは、ライセンス交渉では、ユーザとライセンスサーバ２４が、特に、相互に合意した支払い手段（クレジットアカウント、デビットアカウント、郵便小切手など）および/または支払い方法（即時支払い、一定期間の猶予支払いなど）を決定する必要も起こることである。
【００９５】
ライセンス１６のすべての条項が交渉され、ライセンスサーバ２４とユーザの双方で合意されると（ステップ７１５）、デジタルコンテンツ１６はライセンスサーバ２４によって生成され（ステップ７１５）、そこでは、生成されるライセンス１６は、少なくとも部分的に、ライセンス要求、ブラックボックス３０の公開鍵 (PU-BB)、および要求の基礎となっているデジタルコンテンツ１２であって、コンテンツ鍵データベース２０から取り出されたものに対する解読鍵 (KD) に基づいている。本発明の一実施形態では、図９に示すように、生成されるライセンス１６は次のものを含んでいる。
【００９６】
−  ライセンス１６が適用されるデジタルコンテンツ１２のコンテンツID、
−  デジタル化権ライセンス (DRL) ４８（つまり、ライセンスサーバ３６が調べることのできる、事前に決められた形式で書かれたライセンス１６の権利記述または実際の条項と条件）。これは、おそらく解読鍵 (KD) で暗号化されている（つまり、KD (DRL)）。
−  ライセンス要求の中で受け取られたブラックボックス３０の公開鍵 (PU-BB) で暗号化されたデジタルコンテンツ１２に対する解読鍵 (KD)（つまり、(PU-BB (KD))、
−  (KD (DRL))と (PU-BB (KD))に基づき、ライセンスサーバ２４の秘密鍵で暗号化されたライセンスサーバ２４からのデジタル署名（付属の証明書はない）（つまり、(S (PR-LS))）、および
−  ライセンスサーバ２４がコンテンツサーバ２２から以前に取得した証明書。この証明書は、ライセンスサーバ２４がライセンス１６を発行する権限をコンテンツサーバ２２から得ていることを示している（つまり、(CERT (PU-LS) S (PR-CS))）。
【００９７】
当然に理解されるように、上述したエレメントおよび、おそらくは、他のエレメントは、デジタルファイルまたは他の該当形体にパッケージ化されている。また、当然に理解されるように、ライセンス１６の中のDRL ４８または (PU-BB (KD)) が不法に改変または修正されていると、ライセンス１６の中のデジタル署名 (S (PR-LS)) は一致しないので、そのライセンスを無効化することになる。以上の理由から、DRL ４８は、上述したように、必ずしも暗号化形式（つまり、(KD(DRL)) になっている必要はない。なお、この暗号化形式は、場合によっては望ましいこともあるので、本発明の精神と範囲から逸脱しない限り、採用することが可能である。
【００９８】
デジタルライセンス１６が準備されると、そのライセンス１６は要求側（つまり、ユーザのコンピューティングデバイス１４側のDRMシステム３２）に発行される（図８のステップ７１９）。好ましくは、ライセンス１６は、その要求が行われたときと同じ経路（つまり、インターネットまたは別のネットワーク）を利用して送信されるが、本発明の精神と範囲から逸脱しない限り、別の経路を利用することも可能である。ライセンス１６を受け取ると、要求側DRMシステム３２は、好ましくは、受け取ったデジタルライセンス１６を自動的にライセンスストア３８に入れておく（ステップ７２１）。
【００９９】
当然に理解されるように、ユーザのコンピューティングデバイス１４は誤動作することがあり、そのときは、そのユーザのコンピューティングデバイス１４側DRMシステム３２のライセンスストア３８にストアされたライセンス１６が回復不能に消失することがある。従って、好ましいことは、そのライセンスサーバ２４が発行済みライセンス１６のデータベース２４を保存しておき（図１）、ユーザが実際に再発行を受ける権利を有している場合は、そのライセンスサーバ２４が発行済みライセンス１６のコピーまたは再発行（以下、「再発行」と称す）をユーザに与えるようにすることである。上記のように、ライセンス１６が回復不能に消失することが起こると、ステートストア４０にストアされ、そのライセンス１６に対応するステート情報が消失することも起こり得る。消失したステート情報は、ライセンス１６の再発行時に考慮されるはずである。例えば、レンダリングの回数を制限しているライセンス１６は、相対的に短期間のあとでは、比例配分方式 (pro-rated form) で合法に再発行されるが、相対的に長期間のあとでは、まったく再発行されないことになる。
【０１００】
DRMシステム３２ − ブラックボックス３０のインストール/アップグレード
上述したように、ライセンス１６を取得する機能の一部として、ライセンスサーバ２４は、ユーザのコンピューティングデバイス１４側のDRMシステム３２に、相対的に最新のものでない、つまり、バージョン番号が相対的に古くなっているブラックボックス３０がインストールされていると、ユーザからのライセンス１６の要求を拒否することがある。そのようなケースでは、好ましいことは、ライセンス取得機能が先に進むことができるように、そのDRMシステム３２のブラックボックス３０をアップグレードすることである。当然のことであるが、ブラックボックス３０は、本発明の精神と範囲から逸脱しない限り、上記以外の時でもアップグレードすることが可能である。
【０１０１】
好ましくは、DRMシステム３２をユーザのコンピューティングデバイス１４にインストールするプロセスの一部として、ブラックボックス３０の非ユニークな lite' バージョン（短縮版）が用意されている。この短縮版ブラックボックス３０は、１つのデジタルコンテンツ１２をレンダリングする前に、ユニークな適法バージョンにアップグレードされる。当然に理解されるように、各DRMシステム３２に置かれた各ブラックボックス３０がユニークであれば、あるブラックボックス３０にセキュリティ違反が起こっても、他のブラックボックス３０に同じことが起こることは容易に防止される。
【０１０２】
次に、図１０を参照して説明すると、DRMシステム３２は、ブラックボックス２６などにユニークなブラックボックス３０を要求することによってそれを取得する（これは、図１を参照して上述した通りである）（ステップ９０１）。代表例として、この要求はインターネットを通して行われるが、本発明の精神と範囲から逸脱しない限り、他のアクセス手段を採用することも可能である。例えば、ブラックボックスサーバ２６とのコネクションは、ローカルであるか、リモートであるかに関係なく、直接的コネクションにすることができる。あるユニークな非短縮版 (lite) ブラックボックス３０から別のユニークな非短縮版ブラックボックス３０へのアップグレードは、例えば、上述したように、ライセンスサーバ２４がブラックボックス３０を最新でないと判断したときのように、DRMシステム３２によっていつでも要求することができる。
【０１０３】
そのあと、ブラックボックスサーバ２６は、新しいユニークなブラックボックス３０を生成する（ステップ９０３）。図３に示すように、各々の新ブラックボックス３０は、バージョン番号と証明機関からのデジタル署名付き証明書が付いている。ライセンス取得機能に関して上述したように、ブラックボックス３０のバージョン番号は、その相対的経過年数および/または使用年数を示している。これもライセンス取得機能に関して上述したように、証明機関からのデジタル署名付き証明書は、ライセンスサーバ２４がブラックボックス３０を信用していることを、証明機関が申し出るか、あるいは保証する仕組みである。当然のことであるが、ライセンスサーバ２４は証明機関を信用して、実際に信用できるブラックボックス３０に対して証明書を発行しなければならない。実際には、ライセンスサーバ２４は、特定の証明機関を信用しないで、その証明機関が発行したどの証明書も信用することを拒否することも起こり得る。例えば、特定の証明機関が不正に証明書を発行するパターンに関与していることが分かった場合には、信用されないことになる。
【０１０４】
好ましくは、上述したように、ブラックボックスサーバ２６は、新たに生成されたユニークなブラックボックス３０に新しいユニークな公開/秘密鍵ペア (PU-BB, PR-BB) を組み入れている（図１０のステップ９０３）。好ましくは、ブラックボックス３０の秘密鍵 (PR-BB) は、そのブラックボックス３０だけがアクセス可能になっており、そのブラックボックス３０をもつDRMシステム３２が置かれているコンピューティングデバイス１４とそのユーザを含む、他の外部からは隠され、アクセス不能になっている。
【０１０５】
ほとんどどの隠蔽方式 (hiding scheme) も、その隠蔽方式が実際に外部から秘密鍵 (PR-BB) を見えないようにする機能を備えている限り、本発明の精神と範囲から逸脱しない限り採用することが可能である。１つの例として、秘密鍵 (PR-BB) はいくつかのサブコンポーネントに分割することができ、各サブコンポーネントをユニークに暗号化して、別々のロケーションにストアしておくことができる。その場合に好ましいことは、これらのサブコンポーネント全体が結合されると、秘密鍵全体 (PR-BB) が得られるようにしないことである。
【０１０６】
本発明の一実施形態では、この秘密鍵 (PR-BB) は、コードベースの暗号化手法に従って暗号化される。具体的には、この実施形態では、ブラックボックス３０の実際のソフトウェアコード（または他のソフトウェアコード）が暗号化鍵として採用されている。従って、ブラックボックス３０のコード（または他のソフトウェアコード）が、例えば、悪意の目的をもつユーザによって不法に改変または修正されると、この秘密鍵 (PR-BB) は解読不能になる。
【０１０７】
新しいブラックボックス３０の各々は、新しい公開/秘密鍵ペア (PU-BB, PR-BB) と一緒に送付されるが、この新ブラックボックス３０は、ユーザのコンピューティングデバイス１４側のDRMシステム３２に以前に送付された旧ブラックボックス３０からの旧公開/秘密鍵ペアにもアクセス可能になっていることが好ましい（ステップ９０５）。従って、アップグレードされたブラックボックス３０は、以下で詳しく説明するように、旧鍵ペアに従って生成された旧デジタルコンテンツ１２とそれに対応する旧ライセンス１６にアクセスするために旧鍵ペアを、依然として使用することが可能になっている。
【０１０８】
好ましくは、ブラックボックスサーバ２６によって送付されたアップグレード済みブラックボックス３０は、ユーザのコンピューティングデバイス１４に緊密に結合されているか、関連付けられている。従って、アップグレード済みブラックボックス３０は、悪意の目的や他の目的のために、複数のコンピューティングデバイス１４間で操作可能に転送することが不可能になっている。本発明の一実施形態では、ブラックボックス３０に対する要求の一部として（ステップ９０１）、DRMシステム３２は、そのDRMシステム３２に固有のおよび/またはユーザのコンピューティングデバイス１４に固有のハードウェア情報を、ブラックボックスサーバ２６に提供し、ブラックボックスサーバ２６は、提供されたハードウェア情報の一部に基づいて、DRMシステム３２のためにブラックボックス３０を生成する。このように生成されたアップグレード済みブラックボックス３０は、ユーザのコンピューティングデバイス１４側のDRMシステム３２に送付され、インストールされる（ステップ９０７、９０９）。アップグレード済みブラックボックス３０が、なんらかの方法で別のコンピューティングデバイス１４に転送されると、転送されたブラックボックス３０は、その別のコンピューティングデバイス１４を目的としていないことを知るので、要求されたレンダリングがそのユーザのコンピューティングデバイス１４上で行われることを許可しないことになる。
【０１０９】
新ブラックボックス３０がDRMシステム３２にインストールされると、そのDRMシステム３２は、ライセンス取得機能または他の機能に進むことができる。
【０１１０】
DRMシステム３２ − コンテンツレンダリング、パート３
次に、図６を参照して説明すると、ここでは、ライセンスエバリュエータ３６が少なくとも１つの有効なライセンス１６を見つけ、その有効なライセンス１６の少なくとも１つが、対応するデジタルコンテンツ１２を求めた通りにレンダリングするために必要な権利をユーザに与えているとすると（つまり、使用許可している）、ライセンスエバリュエータ３６は、以後に使用されるライセンス１６の１つを選択する（ステップ５１９）。具体的には、要求されたデジタルコンテンツ１２をレンダリングするために、ライセンスエバリュエータ３６とブラックボックス３０は共同してそのライセンス１６から解読鍵 (KD) を取得し、ブラックボックス３０はその解読鍵 (KD) を使用してデジタルコンテンツ１２を解読する。本発明の一実施形態では、上述したように、ライセンス１６から取得された解読鍵 (KD) はブラックボックス３０の公開鍵 (PU-BB(KD)) を使用して暗号化され、ブラックボックス３０は、その秘密鍵 (PR-BB) を使用してその暗号化解読鍵を解読し、解読鍵 (KD) を得る（ステップ５２１、５２３）。しかし、本発明の精神と範囲から逸脱しない限り、デジタルコンテンツ１２の解読鍵 (KD) は他の方法で取得することも可能である。
【０１１１】
ブラックボックス３０がデジタルコンテンツ１２の解読鍵 (KD) を得て、デジタルコンテンツ１２をレンダリングする許可をライセンスエバリュエータ３６から取得すると、コントロールはレンダリングアプリケーション３４に戻される（ステップ５２５、５２７）。本発明の一実施形態では、コントロールを受け取ると、レンダリングアプリケーション３４はDRMシステム３２/ブラックボックス３０をコールし、解読鍵 (KD) に従って解読するために暗号化デジタルコンポーネント１２の少なくとも一部をブラックボックス３０へ送る（ステップ５２９）。ブラックボックス３０は、デジタルコンテンツ１２の解読鍵 (KD) に基づいてデジタルコンテンツ１２を解読し、そのあと、ブラックボックス３０は解読されたデジタルコンテンツ１２をレンダリングアプリケーション３４に戻し、実際のレンダリングが行われる（ステップ５３３、５３５）。レンダリングアプリケーション３４は、本発明の精神と範囲から逸脱しない限り、暗号化デジタルコンテンツ１２の少なくとも一部またはデジタルコンテンツ１２全体をブラックボックス３０に送り、そのデジタルコンテンツ１２の解読鍵 (KD) に基づいて解読を行うことができる。
【０１１２】
好ましくは、レンダリングアプリケーション３４が解読のためにデジタルコンテンツ１２をブラックボックス３０に送るとき、ブラックボックス３０および/またはDRMシステム３２はそのレンダリングアプリケーション３４を認証し、それが、DRMシステム３２をランさせるために最初に要求したレンダリングアプリケーション３４と同じであることを確かめる（ステップ５３１）。さもないと、レンダリング要求はあるタイプのレンダリングアプリケーションに基づいているが、実際には、別のタイプのレンダリングアプリケーションでレンダリングを行うことにより、レンダリング承認が不正に取得されることが起こり得る。この認証が正しく行われ、デジタルコンテンツ１２がブラックボックス３０によって解読されたとすると、レンダリングアプリケーション３４は、解読されたデジタルコンテンツ１２をレンダリングすることが可能になる（ステップ５３３、５３５）。
【０１１３】
鍵トランザクションのシーケンス
次に、図１１を参照して説明すると、本発明の一実施形態では、鍵トランザクションのシーケンスは、解読鍵 (KD) を取得し、要求された１つのデジタルコンテンツ１２のライセンス１６を評価するために実行される（つまり、図５と図６のステップ５１５−５２３が実行される）。主に、このシーケンスでは、DRMシステム３２は、ライセンス１６から解読鍵 (KD) を取得し、ライセンス１６から得られた情報とデジタルコンテンツ１２を使用して、両者の有効性を認証または確認し、そのあと、ライセンス１６が求めた通りにデジタルコンテンツ１２をレンダリングする権利を確かに与えているかどうかを判断する。そうであれば、デジタルコンテンツ１２はレンダリングすることが可能になる。
【０１１４】
留意すべきことは、デジタルコンテンツ１２に対する各ライセンス１６は、図９に示すように、次のものを含んでいることである。
−  ライセンス１６が適用されるデジタルコンテンツ１２のコンテンツID、
−  おそらくは、解読鍵 (KD) で暗号化されているデジタル化権ライセンス (Digital Rights License - DRL)（つまり、KD (DRL)）、
−  ブラックボックス３０の公開鍵 (PU-BB) で暗号化されたデジタルコンテンツ１２の解読鍵（つまり、(PU-BB (KD))、
−  ライセンスサーバ２４からのデジタル署名であって、(KD (DRL)) と(PU-BB (KD)) に基づき、ライセンスサーバ２４の秘密鍵で暗号化されているもの（つまり、(S (PR-LS))）、および
−  ライセンスサーバ２４がコンテンツサーバ２２から以前に取得した証明書（つまり、(CERT (PU-LS) S (PR-CS))）。
【０１１５】
さらに、留意すべきことは、デジタルコンテンツ１２をもつパッケージ１２Ｐは、図３に示すように、次のものを含んでいることである。
−  そのデジタルコンテンツ１２のコンテンツID、
−  KDで暗号化されたデジタルコンテンツ１２（つまり、(KD)(CONTENT)）、
−  暗号化されていないライセンス取得スクリプト、および
−  コンテンツサーバ２２の公開鍵 (PU-CS) を暗号化する鍵KDであって、コンテンツサーバ２２の秘密鍵 (PR-CS) で署名されたもの（つまり、(KD (PU-CS) S (PR-CS))）。
【０１１６】
以上の留意の下で、本発明の一実施形態では、デジタルコンテンツ１６に対する、ある特定ライセンスに関して実行される特定の鍵トランザクションシーケンスは、次のとおりである。
【０１１７】
1. ライセンス１６からの (PU-BB (KD)) に基づいて、ユーザのコンピューティングデバイス１４側のDRMシステム３２のブラックボックス３０は、(KD) を得るためにその秘密鍵 (PR-BB) を適用する（ステップ１００１）。(PR-BB (PU-BB (KD)) = (KD)。ここで重要なことは、ブラックボックス３０は、次に進んで、KDを使用すると、あとは苦もなくデジタルコンテンツ１２を解読できることである。しかし、この場合も重要なことは、ライセンスサーバ２４はそのようなことをしないものとブラックボックス３０を信用していることである。この信用は、そのブラックボックス３０が信用できるものと保証する証明機関からの証明書に基づいてそのライセンスサーバ２４がライセンス１６を発行した時点で確立されている。従って、ブラックボックス３０は、最終ステップではなく初期ステップとして解読鍵 (KD) を取得するにもかかわらず、DRMシステム３２は、以下で説明するように、ライセンス１６のすべての有効性検査と評価機能の実行を続ける。
【０１１８】
2. デジタルコンテンツ１２からの (KD (PU-CS) S (PR-CS)) に基づいて、ブラックボックス３０は、(PU-CS) を得るために、新たに取得した解読鍵 (KD) を適用する。(KD (KD (PU-CS)) = (PU-CS))。さらに、ブラックボックス３０は、署名 (S (PR-CS)) に対して (PU-CS) を適用して、その署名とそのデジタルコンテンツ１２/パッケージ１２ｐが有効であることに納得することができる（ステップ１００５）。有効でなければ、プロセスは中止され、デジタルコンテンツ１２へのアクセスは拒否される。
【０１１９】
3. ライセンス１６からの (CERT (PU-LS) S (PR-CS)) に基づいて、ブラックボックス３０は、新たに取得したコンテンツサーバ２２の公開鍵 (PU-CS) を適用して、証明書が有効であることに納得する（ステップ１００７）。このことは、ライセンス１６を発行したライセンスサーバ２４が、そうする権限をコンテンツサーバ２２から得ていることを意味している。そのあと、ブラックボックス３０は、証明書内容を検査して (PU-LS) を得る（ステップ１００９）。有効でなければ、プロセスは中止され、ライセンス１６に基づくデジタルコンテンツ１２へのアクセスは拒否される。
【０１２０】
4. ライセンス１６からの (S (PR-LS)) に基づいて、ブラックボックス３０は、新たに取得したライセンスサーバ２４の公開鍵 (PU-LS) を適用して、ライセンス１６が有効であることに納得する（ステップ１０１１）。有効でなければ、プロセスは中止され、ライセンス１６に基づくデジタルコンテンツ１２へのアクセスは拒否される。
【０１２１】
5. すべての有効性検査ステップが正常に完了し、ライセンス１６の中のDRL ４８が確かに解読鍵 (KD) で暗号化されているとすると、ライセンスエバリュエータ３６は、すでに取得した解読鍵 (KD) をライセンス１６から取得された (KD(DRL)) に適用して、ライセンス１６（つまり、DRL）からライセンス条項を取得する（ステップ１０１３）。当然のことであるが、ライセンス１８の中のDRL ４８が実際には解読鍵 (KD) で暗号化されていなければ、ステップ１０１３は省略することができる。次に、ライセンスエバリュエータ３６は、DRL ４８を評価し/調べて、対応するデジタルコンテンツ１２を求めた通りにレンダリングするための、ライセンス１６のDRL ４８に基づく権利をユーザのコンピューティングデバイス１４がもっているかどうか（つまり、DRL ４８が使用許可しているかどうか）を判断する（ステップ１０１５）。その権利が存在しないとライセンスエバリュエータ３６が判断したときは、プロセスは中止され、ライセンス１６に基づくデジタルコンテンツ１２へのアクセスは拒否される。
【０１２２】
6. 最後に、ライセンス１６を評価した結果、ユーザのコンピューティングデバイス１４が、対応するデジタルコンテンツ１２を求めた通りにレンダリングするための、DRL ４８の条項に基づく権利をもっているとの判断が肯定であるとすると、ライセンスエバリュエータ３６は、対応するデジタルコンテンツ１２を解読鍵 (KD) に従ってレンダリングできることをブラックボックス３０に通知する。そのあと、ブラックボックス３０は、パッケージ１２ｐからのデジタルコンテンツ１２を解読するために解読鍵 (KD) を適用する（つまり、(KD(KD(CONTENT)) = (CONTENT))（ステップ１０１７）。
【０１２３】
ここで注目すべきことは、上述した一連のステップは、ライセンス１６とデジタルコンテンツ１２の間で交互に代わること、つまり、「ピンポン」することを表していることである。このようにピンポンすると、有効性検査と評価プロセスは、デジタルコンテンツ１２とライセンス１６の両方が正しく発行され、有効な形式で存在するときだけ行われるので、デジタルコンテンツ１２はライセンス１６に緊密にバインド (bind) されることになる。さらに、ライセンス１６からコンテンツサーバ２２の公開鍵 (PU-CS) とパッケージ１２ｐからデジタルコンテンツ１２を、解読された形で得るためには（さらには、おそらくは、ライセンス１６からのライセンス条項（DRL ４８）を解読された形で得るためには）、同じ解読鍵 (KD) が必要になるので、これらのアイテムも緊密にバインドされる。署名の有効性検査を行うと、デジタルコンテンツ１２とライセンス１６は、それぞれ、コンテンツサーバ２２とライセンスサーバ２４から発行されたものと同じ形式に保たれることになる。従って、ライセンスサーバ２４をバイパスすると、不可能ではないとしても、デジタルコンテンツ１２を解読することが困難になり、また、不可能ではないとしても、デジタルコンテンツ１２またはライセンス１６を改変してから解読することが困難になる。
【０１２４】
本発明の一実施形態では、署名有効性検査、特にライセンス１６の署名有効性検査は、次のように交互に行われる。各ライセンス１６の署名はライセンスサーバ１６の秘密鍵 (PR-LS) によって暗号化されるのではなく、図９に示すように、署名は、秘密ルート鍵 (PR-R)（図示せず）によって暗号化され、その場合、各DRMシステム３２のブラックボックス３２は、秘密ルート鍵 (PR-R) に対応する公開ルート鍵 (PU-R)（これも図示せず）をもっている。この秘密ルート鍵 (PR-R) はルートエンティティだけに分かっているので、ライセンスサーバ２４は、そのライセンスサーバ２４がライセンス１６を発行する取り決めをルートエンティティと行ったときだけライセンス１６を発行することができる。
【０１２５】
具体的に説明すると、この実施形態では、
1. ライセンスサーバ２４は、その公開鍵 (PU-LS) をルートエンティティに提供する。
2. ルートエンティティは、秘密ルート鍵 (PR-R) で暗号化されたライセンスサーバ公開鍵 (PU-LS) をそのライセンスサーバ２４に返送する（つまり、(CERT (PU-LS) S (PR-R))）。
3. 次に、ライセンスサーバ２４は、ライセンスサーバ秘密鍵 (S (PR-LS)) で暗号化された署名付きライセンス１６を発行し、ルートエンティティからの証明書 (CERT (PU-LS) S (PR-R)) をそのライセンスに添付する。
【０１２６】
次に、DRMシステム１８は発行されたライセンス１６の有効性を検査するために、DRMシステム１８は、
1. 添付された証明書 (CERT (PU-LS) S (PR-R)) に公開ルート鍵 (PU-R) を適用して、ライセンスサーバ公開鍵 (PU-LS) を取得し、
2. 取得したライセンスサーバ公開鍵 (PU-LS) をライセンス１６の署名 (S (PR-LS) に適用する。
【０１２７】
重要なことは、当然に理解されるように、ルートエンティティが証明書 (CERT (PU-LS) S (PR-R)) をライセンスサーバ２４に提供することによって、ライセンス１６を発行する許可をそのライセンスサーバ２４に与えたのと同じように、ライセンスサーバ２４は、類似の証明書（つまり、(CERT (PU-LS2) S (PR-LS1))を別のライセンスサーバ２４に提供することによって、その別のライセンスサーバもライセンス１６を発行できるようにしたことである。以上から明らかであるように、別のライセンスサーバによって発行されたライセンス１６は、第１の証明書 (CERT (PU-LS) S (PR-R)) と第２の証明書 (CERT (PU-LS2) S (PR-LS1))を含むことになる。同様に、このライセンス１６は、第１と第２の証明書を通るチェーンをたどって行くことによって有効性が検査される。当然のことであるが、チェーンに別のリンクを追加して、そこを通過するようにすることも可能である。
【０１２８】
上述した署名検査プロセスの１つの利点は、ルートエンティティが秘密ルート鍵 (PR-R) を定期的に変更することによって、同じように定期的に各ライセンスサーバ２４に新しい証明書 (CERT (PU-LS) S (PR-R)) の取得を要求できることである。重要なことは、新しい証明書 (CERT (PU-LS) S (PR-R)) を取得するときの要件として、各ライセンスサーバに自身でアップグレードすることを要求できることである。ブラックボックス３０の場合と同様に、ライセンスサーバ２４が相対的に最新のものであれば、つまり、相対的に最近にアップグレードされていれば、ライセンスサーバ２４に対する攻撃が成功する確率は低くなる。従って、信用の問題として、署名検査プロセスなどの、該当アップグレードトリガメカニズム (upgrade trigger mechanism) を通して、各ライセンスサーバ２４に定期的にアップグレードするように要求することが好ましい。当然のことであるが、本発明の精神と範囲から逸脱しない限り、他のアップグレードメカニズムを採用することも可能である。
【０１２９】
当然のことであるが、秘密ルート鍵 (PR-R) が変更されたときは、各DRMシステム１８内の公開ルート鍵 (PU-R) も変更されなければならない。この変更は、例えば、通常のブラックボックス３０のアップグレード期間に行うことができるが、実際には、ブラックボックス３０にアップグレードを要求することができる。変更された公開ルート鍵 (PU-R) は、旧秘密ルート鍵 (PR-R) に基づいて発行された旧ライセンス１６の署名検査を妨げるおそれがあるが、この妨げは、アップグレードされたブラックボックス３０にすべての旧公開ルート鍵 (PU-R) を記憶させるようにすると最小限になる。別の方法として、この妨げは、例えば、そのライセンス１６がDRMシステム１８のライセンスエバリュエータ３６によって初めて評価されるとき、ライセンス１６の署名検査を一度だけ要求することで最小限にすることもできる。そのようなケースでは、署名検査が行われたかどうかのステート情報はコンパイルしておく必要があり、そのステート情報はDRMシステム１８のステートストア４０にストアしておく必要がある。
【０１３０】
デジタル化権ライセンス４８
本発明では、ライセンスエバリュエータ３６は、デジタル化権ライセンス (Digital Rights License  DRL) ４８をライセンス１６の権利記述または条項として評価し、そのDRL ４８が対応する１つのデジタルコンテンツ１２を求めた通りにレンダリングすることを許可しているどうかを判断している。本発明の一実施形態では、DRL ４８は、ライセンサ（つまり、コンテンツ所有者）によってどのDRL言語で書くことも可能になっている。
【０１３１】
当然に理解されるように、DRL ４８を規定するには多数の方法がある。従って、どのDRL言語においても、高度の柔軟性が許容されていなければならない。しかし、DRL ４８のすべての側面を特定のライセンス言語で規定することは実情に合わず、特定のデジタルライセンサが望んでいる可能な限りの側面を、その言語の作成者が理解することは不可能である。さらに、高度のライセンス言語は必要とされないことがあり、ライセンサが比較的単純なDRL ４８を用意するときの妨げとさえなっている。それにもかかわらず、ライセンサは、DRL ４８の規定の仕方において必要以上に制約されることがあってはならない。それと同時に、ライセンスエバリュエータ３８は、いくつかの具体的ランセンス質問に関して、いつでも回答がDRL ４８から得られるようになっている必要がある。
【０１３２】
次に、図１２を参照して説明すると、本発明では、DRL ４８は、どのライセンス言語でも規定することができるが、そこには、言語IDまたはタグ５４が含まれている。ライセンス１６を評価するライセンスエバリュエータ３６は、言語タグ５４をレビューする予備的ステップを実行してその言語を特定し、そのあと、その特定された言語でライセンス１６にアクセスするための該当ライセンス言語エンジン５２を選択している。当然に理解されるように、このライセンス言語エンジン５２は存在していて、ライセンスエバリュエータ３６にアクセス可能になっていなければならない。存在していないときは、言語タグ５４および/またはDRL４８は、好ましくは、その言語エンジン５２を取得するためのロケーション５６(代表例として、Webサイト)を含んでいる。
【０１３３】
代表例として、言語エンジン５２は、実行可能ファイルまたはファイルのセットの形になっており、ハードドライブのような、ユーザのコンピューティングデバイス１４のメモリに置かれている。言語エンジン５２は、ライセンスエバリュエータ３６が直接にDRL ４８を調べるのを支援し、ライセンスエバリュエータ３６は、間接的には、仲介者の働きをする言語エンジン４８などを通してDRL ４８を調べている。実行時には、言語エンジン５２は、RAMのような、ユーザのコンピューティングデバイス１４のメモリ内のワークスペースで実行される。しかし、本発明の精神と範囲から逸脱しない限り、他の形体の言語エンジン５２を採用することも可能である。
【０１３４】
好ましくは、どの言語エンジン５２も、どのDRL言語も、以下で説明するように、ライセンスエバリュエータ３６がどのDRL ４８からでも回答が得られると期待している、少なくともいくつかの具体的ライセンス質問をサポートしている。従って、ライセンスエバリュエータ３６は、どの特定DRL言語にも拘束されていないので、DRL ４８はどの該当言語で書くこともでき、新しいライセンス言語で規定されたDRL ４８は、対応する新言語エンジン５２を既存のライセンスエバリュエータ３６に取得させることによって、そのライセンスエバリュエータ３８が使用することが可能である。
【０１３５】
DRL言語
以下には、それぞれのDRL ４８に具現化されているDRL ４８の２つの例が示されている。最初の「単純」DRL ４８は、ライセンス属性を指定しているDRL言語で書かれており、他方、２番目の「スクリプト」DRL ４８は、DRL ４８に指定されているスクリップに従って関数を実行するDRL言語で書かれている。DRL言語で書かれているが、各コード行の意味は、その言語および/またはそのあとに続く属性説明図を見れば、理解されるはずである。
【０１３６】
0004226849.tif 000002
0004226849.tif 000003
0004226849.tif 000004
0004226849.tif 000005
0004226849.tif 000006
【０１３７】
上に示した２つのDRL ４８において、そこにリストされている属性の意味とデータ型は次の通りである。
0004226849.tif 000007
0004226849.tif 000008
【０１３８】
メソッド
上述したように、好ましいことは、どの言語エンジン５２も、どのDRL言語も、デジタルライセンスエバリュエータ３６がどのDRL ４８からも回答が得られると期待している、少なくともいつかの具体的ライセンス質問をサポートしていることである。本発明の精神と範囲から逸脱しない限り、および上記に示した２つのDRL ４８例で用いられている用語に矛盾しない限り、サポートされる質問には、どの質問を含めることも可能であるとの認識の上で、本発明の一実施形態では、サポートされる質問または「メソッド」には、以下に説明するように、「アクセスメソッド」、「DRLメソッド」、および「使用許可メソッド」が含まれている。
【０１３９】
アクセスメソッド (Access Method)
アクセスメソッドは、DRL ４８にクエリ（照会）してトップレベル属性を得るために使用される。
【０１４０】
VARIANT QueryAttribute (BSTR鍵)
有効な鍵としては、License.Name、License.Id、Content.Name、Content.Id、Content.Type、Owner.Name、Owner.Id、Owner.PublicKey、Licensee.Name、Licensee.Id、Licensee.PublicKey、Description、およびTermsがあり、各々からはBSTR可変データが戻され、さらに、Issued、Validity.StartおよびValidity.Endがあり、各々からは日付可変データが戻される。
【０１４１】
DRLメソッド
次のDRLメソッドがどのように実装されるかは、DRL ４８とDRL ４８との間で異なっている。DRLメソッドの多くは、'data' と名付けた可変パラメータをもち、これは、もっと先進的なDRL ４８と情報を通信することを目的としている。これが存在するのは、主に将来の拡張性のためである。
【０１４２】
Boolean IsActivated(可変データ)
このメソッドからは、DRL ４８がアクチベートされたかどうを示すBooleanが戻される。アクチベートされるライセンスの例として、最初のプレイ時に48時間だけアクチベートになるオペレーション制限ライセンス１６がある。
【０１４３】
Activate(可変データ)
このメソッドは、ライセンス１６をアクチベートするために使用される。ライセンス１６がいったんアクチベートされると、非アクチベートすることはできない。
【０１４４】
Variant QueryDRL(可変データ)
このメソッドは、もっと先進的なDRL４８と通信するために使用される。これは、主にDRL ４８フィーチャセットの将来の拡張性に関するものである。
【０１４５】
Variant GetExpress(BSTRアクション、可変データ)
このメソッドからは、渡されたアクションに関してライセンス１６の満了日が戻される。戻り値がNULLのときは、ライセンス１６は満了しないものとみなされるか、あるいはライセンス１６がアクチベートされていないためまだ満了日がない、などを意味する。
【０１４６】
Variant GetCount(BSTRアクション、可変データ)
このメソッドからは、渡されたアクションのオペレーションで、残っているオペレーションの数が戻される。NULLが戻されたときは、オペレーションは無制限の回数実行可能である。
【０１４７】
Boolean IsEnabled(BSTRアクション、可変データ)
このメソッドは、ライセンス１６が要求されたアクションを現在サポートしているかどうかを知らせる。
【０１４８】
Boolean IsSunk(BSTRアクション、可変データ)
このメソッドは、ライセンス１６が支払済みであるかどうかを知らせる。ライセンス１６が前払いのときは、TRUEが戻され、その使用時に支払いを集金するライセンス１６のように、ライセンス１６が前払いでないときは、FALSEが戻される。
【０１４９】
使用許可メソッド (Enabling Use Method)
これらのメソッドは、コンテンツの解読でライセンス１６を使用許可するために使用される。
【０１５０】
Boolean Validate(BSTRアクション)
このメソッドは、ライセンス１６の有効性を検査するために使用される。渡される鍵は、対応するデジタルコンテンツ１２の解読鍵 (KD) で暗号化されたブラックボックス３０の公開鍵 (PU-BB)（つまり、(KD(PU-BB))）であり、ライセンス１６の署名の有効性検査で使用される。戻り値がTRUEのときは、ライセンス１６が有効であることを示している。戻り値がFALSEのときは、無効であることを示している。
【０１５１】
Int OpenLicense 16(BSTRアクション、BSTR鍵、可変データ)
このメソッドは、解読された使用許可ビットにアクセス準備するために使用される。渡される鍵は上述した(KD(PU-BB))である。戻り値が0のときは、成功を示す。他の戻り値を定義することも可能である。
【０１５２】
BSTR GetDecryptedEnablingBits(BSTRアクション、可変データ)
Variant GetDecryptedEnablingBitsAsBinary(BSTRアクション、可変データ)
上記メソッドは、解読形式の使用許可ビットにアクセスするために使用される。これがなんらかの理由で失敗すると、ヌルストリングまたはヌル可変データが戻される。
【０１５３】
Void CloseLicense 16(BSTRアクション、可変データ)
このメソッドは、渡されたアクションを実行するために使用許可ビットへのアクセスをアンロックするために使用される。これがなんらかの理由で失敗すると、ヌルストリングが戻される。
【０１５４】
ヒューリスティック (Heuristics)
上述したように、１つの同じデジタルコンテンツ１２に複数のライセンス１６が存在する場合は、将来の使用に備えてライセンス１６の１つを選択しなければならない。上記メソッドを使用すると、この選択を行うように次のヒューリスティックを実現することができる。具体的には、１つのデジタルコンテンツ１２であるアクション（つまり、APLAY@）を実行するには、次のステップを実行することができる。
【０１５５】
1. １つの特定デジタルコンテンツ１２に適用されるすべてのライセンス１６を取得する。
【０１５６】
2. そのアクションを使用許可しない各ライセンス１６を、そのライセンス１６でIsEnabled関数をコールすることによって除去する。
【０１５７】
3. アクティブでない各ライセンス１６を、そのライセンス１６でIsAactivatedをコールすることによって除去する。
【０１５８】
4. 前払いでない各ライセンス１６を、そのライセンス１６でIsSunkをコールすることによって除去する。
【０１５９】
5. 残っているライセンス１６があれば、それを使用する。特に、プレイ回数無制限ライセンス１６に満了日がある場合は、プレイ回数有限ライセンス１６を使用する前にプレイ回数無制限ライセンス１６を使用する。たとえその選択が費用効果的でなくとも、すでに取得されている特定ライセンス１６を、ユーザがいつでも選択できるようにしておく必要がある。従って、ユーザは、おそらくDRMシステム３２から見えない基準に基づいてライセンス１６を選択することができる。
【０１６０】
6. ライセンス１６が残っていなければ、そのことを示すステータスが戻される。この場合、ユーザは次の中から選択することができる。
【０１６１】
使用可能であれば、前払いでないライセンス１６を使用する。
【０１６２】
使用可能であれば、ライセンス１６をアクチベートする、および/または
ライセンスサーバ２４からのライセンス取得を実行する。
【０１６３】
ポータブルデバイスなどでデジタルコンテンツをレンダリングする
次に、図１４を参照して説明すると、当然に理解されるように、デジタルコンテンツ１２を取得し、レンダリングするモードでは、そのデジタルコンテンツ１２はダウンロードされ、あるいは他の方法で、パーソナルコンピュータ６０などに置かれ、そのとき取得された対応するデジタルライセンス１６も、ダウンロードされ、あるいは他の方法で、パーソナルコンピュータ６０などに置かれる。代表例として、パーソナルコンピュータ６０などは、相対的に大きく、移動が容易でないデバイスであるため、外部供給電力を受け入れるためのパワーラインコネクションと、外部と通信するための通信回線コネクションが必要になる。さらに、図１３を参照して上述したように、コンピュータ６０は、ケーブル接続キーボード、ケーブル接続マウス、ケーブル接続スクリーンなどを備えると共に、スキャナ、プリンタ、および/または他のペリフェラル（周辺）デバイスに結合されていることがある。従って、コンピュータ６０は、これらのコネクションとペリフェラルによって比較的縛り付けられている。つまり、「束縛」されている。
【０１６４】
当然のことであるが、図３のパーソナルコンピュータ６０は、例えば、ペリフェラルを切り離すと束縛から解かれ、コンピュータ６０を、スクリーン、キーボード、マウス、およびバッテリ電源が組み込まれている全機能ラップトップコンピュータの形で実現すると、さらに束縛から解かれることになる。それにもかかわらず、例えば、ミュージカルセレクションなどのデジタルコンテンツ１２を、例えば、練習を行いながらレンダリングしたいと思っているユーザは、たとえそのラップトップコンピュータ６０の重量がわずか4または5ポンドであっても、その作業期間中にラップトップコンピュータ６０を持ち運ぶことに躊躇することは確かである。さらに、全機能ラップトップコンピュータ６０が2 - 4オンスといったように、軽量化されていても、コンピュータ６０は、その作業期間中に損傷を受けやすい、センシティブなコンポーネント（例えば、ハードドライブ）を依然として装備している。
【０１６５】
幸いなことに、図１４に戻って説明すると、束縛が解かれ、軽量化された真のポータブルコンピューティングデバイス６２が出現し、少なくともある種のデジタルコンテンツ１２をストアし、レンダリングするために使用することが可能になっている。例えば、S3 Incorporated (Santa Clara, California) が販売しているDIAMOND RIOポータブルミュージックプレイヤは、バッテリで動き、手のひらやポケットに収まり、可動部品がなく、デジタルコンテンツ１２を保存しておく大量のオンボードフラッシュメモリを備え、例えば、Windows（登録商標） Media Audio (WMA) またはMP3フォーマットであっても、デジタルコンテンツ１２をレンダリングすることが可能になっている。このDIAMOND RIOプレイヤには適当なケーブルが付いており、そのケーブルを通してコンピュータ６０からデジタルコンテンツ１２を、そこからダウンロードできるようにするインタフェースを備えている。その他のポータブルミュージックプレイヤとしては、RCAプレイヤ、Creative Nomad II、およびHewlett-Packard、CasioおよびCompaq提供のポケットPCデバイスがある。しかし、重要なことは、上述してきたようにDRMアーキテクチャをサポートするようにポータブルコンピューティングデバイス６２を構成すると、いくつかの問題が発生することである。
【０１６６】
１つの問題は、コンテンツの解読、コンテンツのレンダリングといった、プレイヤオペレーション用に確保されたメモリが比較的少量である、ある種のプレイヤで起こっている。このことから理解されるように、メモリが比較的少量であると、ポータブルデバイス６２は、例えば、公開鍵−秘密鍵の解読といったように、上述してきた、少なくとも一部のDRM関数を実行することができない。この問題に対処する解決方法は、「デジタル化権管理(DRM)システムにおいてデジタルコンテンツをポータブルストレージデバイスなどにバインディングする方法(Binding Digital Content to a Portable Storage Device Or the Like in A Digital Rights Management (DRM) System)」という名称で2000年8月25日に出願された米国特許出願第09/645,887号に記載されている。なお、その全内容は、引用により本明細書の一部になっている。
【０１６７】
しかし、重要なことは、前記米国特許出願に記載されている解決方法は、グローバルシークレットに基づく鍵方式に頼っているため、この鍵方式は、グローバルシークレットが露見され、広められると、グローバルに危険にさらされるおそれがあることである。従って、本発明の一実施形態では、ポータブルデバイス６２は、そこに置かれたメモリ内にインスタンス化されたポータブルDRMシステム３２ｐ（図１４）を通して公開鍵−秘密鍵解読を行っている。以上から理解されるように、このDRMシステム３２ｐと、コンテンツの解読、コンテンツのレンダリングといった付随するオペレーションは、そのポータブルデバイス６２上で利用可能なメモリ量を増やすか、メモリにインスタンス化されたDRMシステム３２ｐのサイズを小さくするか、あるいはその両方を行うことにより、ポータブルデバイス６２上に収まるようにしている。
【０１６８】
本発明の一実施形態では、前記米国特許出願第09/645,887号に開示されている主題の場合と同じように、ポータブルデバイス６２のためにデジタルコンテンツ１２とそれに対応するデジタルライセンス１６を取得することは、すべてコンピュータ６０などを通して行われている。具体的には、コンピュータ６０は、対応するデジタルコンテンツ１６のライセンス１６を取得し、そのあと、デジタルコンテンツ１２をポータブルデバイス６２上でレンダリングするためのサブライセンス１６ｓをポータブルデバイス６２に対して発行している。このサブライセンス１６ｓは、コンピュータ６０からポータブルデバイス６２へダウンロードしている過程で発行することも、コンピュータ６０からポータブルデバイス６２へダウンロードする前かした後の任意の時点で、あるいは別の時点で行うことも可能であり、これらは、すべて本発明の精神と範囲から逸脱しない限り行うことができる。なお、本発明は、図１４に示すように、コンピュータ６０とポータブルデバイス６２を中心に説明されているが、当然に理解されるように、本発明の精神と範囲から逸脱しない限り、本発明は、コンピュータ６０以外の特定タイプのコンピュータデバイス１４に関しても、それに見合う形で実現することが可能である。
【０１６９】
重要なことは、コンピュータ６０がポータブルデバイス６２のためにライセンス取得とコンテンツ取得の全機能を実行するので、そのポータブルデバイス６２とそこに置かれたDRMシステム３２ｐは、コンテンツ１２とサブライセンス１６ｓをダウンロードするのに必要な機能を除けば、前記機能を備えている必要がないことである。従って、コンピュータ６０側に置かれているDRMシステム３２の重要なライセンス取得とコンテンツ取得部分は、ポータブルデバイス６２側に置かれているDRMシステム３２ｐから省いておくことができる。
【０１７０】
ポータブルデバイス６２が全体的に閉じたデバイスとして定義されているのは、データが制限された方法でのみオンロードされ、オフロードされ、ポータブルデバイス６２内のハードウェアへのユーザアクセスが非常に制限され、入力とディスプレイ機能が少数の機能キーと、おそらくは小型LCDスクリーンに制限されているからである。従って、非暗号化形式でそこに置かれているコンテンツ１２または解読鍵を得るためにポータブルデバイス６２のメモリまたは物理的コンテンツを調べることによって、コンテンツ１２を盗もうとしてもほとんど無駄である。これとは対照的に、コンピュータ６０が全体的にオープンしたデバイスとして定義されているのは、データが広範囲のハードウェアおよび/またはソフトウェアによって幅広くオンロードされ、オフロードされ、ポータブルデバイス６２内のハードウェアへのユーザアクセスがほとんど無制限であり、入力とディスプレイ機能が全機能キーボード、マウス、高解像度モニタなどから利用できるからである。従って、コンテンツを盗もうとする人は、非暗号化形式でそこに置かれているコンテンツ１２と解読鍵を得るためにコンピュータ６０のメモリと物理的コンテンツを調べる機会がそれだけ多くなる。以上を要約すると、閉じたデバイスとしてのポータブルデバイス６２は、特にオープンしたデバイスとしてのコンピュータ６０に比べて、コンテンツを盗む人によって行われる悪意のアクションからの影響が少なくなっている。
【０１７１】
その結果、重要なことは、ポータブルデバイス６２とそこに置かれたDRMシステム３２ｐは、コンテンツ１２とサブライセンス１６ｓをダウンロードするとき必要になる機能を除けば、大部分のタイプのコンテンツ盗難と解読鍵盗難から保護するために必要とされる機能を備えている必要がないことである。従って、コンピュータ６０側に置かれているDRMシステム３２の重要な盗難防止機能は、ポータブルデバイス６２側に置かれているDRMシステム３２ｐから省いておくことができる。
【０１７２】
ここで、要約して説明すると、ポータブルデバイス６２側に置かれているDRMシステム６２は、(1) サブライセンス１６ｓをポータブルデバイスへダウンロードするときポータブルデバイス６２をコンピュータ６０に対して認証し、そのダウンロードを容易化するために必要な機能、および (2) ダウンロードされて、そこに置かれたサブライセンス１６ｓに従ってコンテンツ１２をポータブルデバイス６２上でレンダリングするために必要な機能を備えているだけで十分であり、この中には、サブライセンス１６ｓの要件を満たしていることを確かめ、サブライセンス１６ｓからコンテンツ鍵 (KD) を取得することが含まれている。コンピュータ６０側のDRMシステム３２に用意されている他の機能は、ポータブルデバイス６２側のDRMシステム３２ｐでは、いずれも不要であるか、あるいは閉じたデバイスであるポータブルデバイス６２に内在している。
【０１７３】
以上から理解されるように、また前記米国特許出願第09/645,887号に開示されているように、コンピュータ６０によって発行されるサブライセンス１６は、対応するコンテンツ１２をポータブルデバイス６２上でレンダリングするとき従わなければならない制限を設けている場合がある。当然のことであるが、コンピュータ６０は、該当ライセンスサーバ２４からコンピュータ６０によって取得された対応するライセンス１６の条項に従って許されている場合にだけ、そのサブライセンス１６ｓを発行することができる。また、前記米国特許出願第09/645,887号に開示されているように、コンピュータ６０は、サブライセンス１６ｓを発行するときライセンス１６の少なくとも一部を、ポータブルデバイス６２がもっと扱い易く、サブライセンス１６ｓをポータブルデバイス６２に結び付ける、つまり、バインドする形になるように書き換える。具体的には、コンピュータ６０は、コンテンツ１２を解読するためのコンテンツ鍵 (KD) を、ポータブルデバイス６２がもっと解読しやすくする形に再暗号化する。なお、ここでは、コンテンツ鍵は、ポータブルデバイス６２のDRMシステム３２ｐのブラックボックス公開鍵 (PU-BB-PD) に従って再暗号化される。
【０１７４】
具体的に説明すると、コンピュータ６０上のライセンス１６内のコンテンツ鍵 (KD) が上述したように、ブラックボックス公開鍵 (PU-BB-CO) などの非対称鍵に従って暗号化されているとすると、コンピュータ６０は、上述したように、コンピュータのブラックボックス秘密鍵 (PR-BB-CO) を適用することによってコンテンツ鍵 (KD) を取得し、そのあと、(PU-BB-PD) に従ってコンテンツ鍵 (KD) を再暗号化する。従って、当然に理解されるように、コンテンツ鍵 (KD) は、ポータブルデバイス６２のブラックボックス秘密鍵 (PR-BB-PD) を適用することにより、該当する時点でポータブルデバイス６２によって取得可能であるので、サブライセンス１６Ｓは、ポータブルデバイス６２に結び付けられるか、バインドされることになる。当然に理解されるように、コンテンツ鍵 (KD) を再暗号化しないと、ポータブルデバイス６２は (PR-BB-CO) を知らないので、(KD) を得るために (PU-BB-CO(KD)) を解読できないことになる。
【０１７５】
ポータブルデバイス６２へのコンテンツ１２とサブライセンス１６ｓの送付
次に、図１５と図１７を参照して説明すると、本発明の一実施形態では、コンテンツ１２とそれに対応するサブライセンス１６ｓは、以下に説明するステップに従ってポータブルデバイス６２にダウンロードされる。予備的に、ポータブルデバイス６２は、図１４に示すように、該当コネクション６４を通して該当コンピュータ６０に結合されていなければならない（ステップ１４０１）。コネクション６４は、本発明の精神と範囲から逸脱しない限り、どのようなコネクションであっても構わない。なお、代表例として、ポータブルデバイス６２は１つまたは２つ以上のインタフェース６６を装備し、どのタイプのコネクション６４が使用できるかはそのインタフェースによって決まる。例えば、インタフェース６６としては、シリアルポート、パラレルポート、USBポート、「ファイアウォール」ポート、赤外線ポートなどがあり、その場合、コンピュータ６０が対応するインタフェース６８と、それをサポートする該当ハードウェアおよび/またはソフトウェアを介してそのコネクション６４をサポートしているとすると、対応するタイプのコネクション６４が採用されていなければならない。コネクション６４、インタフェース６６、６８、およびこれらをサポートするハードウェアおよび/またはソフトウェアは、この分野の精通者に公知であり、当然に理解されるはずであるので、ここでは、これ以上詳しく説明することは省略する。
【０１７６】
コンピュータ６０とコンピューティングデバイス６２を結合する前または結合した後、ポータブルデバイス６２はコンテンツ１２を取得しなければならない（ステップ１４０３）。なお、コンテンツ１２は、磁気媒体、光媒体、または電子媒体などの、該当転送可能ストレージ媒体を通して、外部ソースから直接にポータブルデバイス６２上に置いておくことができる。例えば、ストレージ媒体としては、ミクロサイズ磁気ディスクや「メモリスティック」があり、そこには、ポータブルデバイス６２または別のデバイスによってコンテンツ１２がすでに収められている。なお、代表例として、特に、ポータブルデバイスのストレージ媒体が転送不能である場合には、コンテンツ１２は、まず、コンピュータ６０に置いておき、次に、コネクション６４を通してコンピュータ６０からポータブルデバイス６２に転送することによって、ポータブルデバイス６２に置かれている。なお、コンピュータ６０に置いておくことは、特に、コンピュータ６０がポータブルデバイス６２のために直接にコンテンツ１２を取得する場合は、非常に短時間に行われる。コンピュータ６０を経由する場合も、他の方法による場合も、コンテンツ１２を取得し、そのコンテンツ１２をポータブルデバイス６２に置いておくことは、この分野の精通者に公知であり、当然に理解されるはずであるので、ここでは、これ以上詳しく説明することは省略する。
【０１７７】
また、コンピュータ６０とポータブルデバイス６２を結合するまたは結合した後、コンピュータ６０は、上述したように、コンテンツ１２の対応するライセンス１６を該当ソースから取得しなければならない（ステップ１４０５）。なお、ライセンス１６は、対応するコンテンツ１２をコンピュータ６０上でレンダリングすることを、必ずしも許容している必要はない。しかし、このライセンス１６は、対応するサブライセンス１６ｓをポータブルデバイス６２のために発行することとだけでなく、そのコンテンツ１２をポータブルデバイス６２上でレンダリングすることも許容しているか、少なくとも禁止していてはならない。すなわち、ライセンサは、そのコンテンツ１２をポータブルデバイス６２上でレンダリングするのを、いくつかの理由で許可しないことを決定し、従って、対応するサブライセンス１６ｓをそのポータブルデバイス６２のために発行することを、対応するライセンス１６の条項によって禁止する場合がある。同様に、そのライセンサは、一部のポータブルデバイス６２に制限して、対応するサブライセンス１６ｓの発行を許可する場合もある。そのライセンサは、例えば、得られたライセンスのルールを規定するために、ライセンス１６のサブライセンス発行ルールを規定すること場合がある。
【０１７８】
従って、コンピュータ６０は取得されたライセンス１６をチェックして、ライセンス１６が確かにサブライセンス１６の発行を許可し、禁止していないかどうかを判断し、おそらくは、サブライセンス１６ｓをポータブルデバイス６２のために発行することを、確かに許可し、禁止していないかどうかを判断する（ステップ１４０７）。当然のことであるが、このチェックを行うには、ポータブルデバイス６２が識別情報をコンピュータ６０に伝える必要があるが、本発明の精神と範囲から逸脱しない限り、どのような形体にすることも可能である。チェックの結果、サブライセンス１６ｓが確かに発行可能であると判断されると、その発行が行われる。
【０１７９】
図１７に示すように、コンピュータ６０は、取得したライセンス１６に基づいてサブライセンス１６ｓを構築し、ポータブルデバイス６２に発行し、そこでは、ポータブルデバイス６２上のDRMシステム３２ｐは、サブライセンス１６ｓの条項だけに従って対応するコンテンツ１２をレンダリングする（ステップ１４０９）。そのサブライセンス１６ｓを構築し、発行するとき、上述したように、コンピュータ６０は、コンテンツ１２を解読するためのコンテンツ鍵 (KD) を (PU-BB-CO(KD)) から (PU-BB-PD(KD)) に再暗号化する。
【０１８０】
具体的には、忘れてならないことは、DRMアーキテクチャによれば、１つのデジタルコンテンツ１２は、対称コンテンツ鍵 (KD) に従って暗号化され、コンテンツ１２は、ブラックボックス３０をもつコンピューティングデバイス１４上でレンダリングされ、ブラックボックス３０は、関連の非対称公開/秘密鍵 (PU-BB, PR-BB) をもっており、コンテンツ１２の対応するライセンス１６は、(PU-BB)に従って暗号化されたコンテンツ鍵 (KD) を収めており、従って、ライセンス１６は、コンピューティングデバイス１４のブラックボックスおよびコンピューティングデバイス１４自体に結び付けられている、つまり、バインドされていることである。対応するコンテンツ１２のサブライセンス１６Ｓをポータブルデバイス６２に対して発行するとき、コンピュータ６０は、そこに置かれているコンテンツ鍵 (KD) を (PU-BB-PD) に従って再暗号化することによって、サブライセンス１６をポータブルデバイス６２に結び付けるか、バインドしなければならない。
【０１８１】
従って、コンピュータ６０は次の手順でその再暗号化を行う。
1. ポータブルデバイス６２から (PU-BB-PD) を取得する（ステップ１４０９ａ）。
2. (PU-BB-CO) に従って暗号化されたコンテンツ鍵 (KD)（つまり、(PU-BB-CO (KD))）をライセンス１６から取得する（ステップ１４０９ｂ）。
3. (PR-BB-CO) を (PU-BB-CO (KD)) に適用して (KD) を取得する（ステップ１４０９ｂ）。
4. (PU-BB-PD) に従って (KD) を暗号化する（ステップ１４０９ｂ）。
そのあと、この (PU-BB-PD(KD)) は、コンピュータ６０によってサブライセンス１６に入れられる（ステップ１４０９ｅ）。
【０１８２】
理解されるように、場合によっては、KDは、中間鍵を通してPU-BBに従って間接的に暗号化される。つまり、PU-BBが中間鍵を暗号化し、その中間鍵がKDを暗号化している。なお、KDはオリジナルライセンス１６に残っている。そこで、もっと一般的に説明すると、当然に理解されるように、コンピュータ６０は、ライセンス１６からコンテンツ鍵 (KD) を取得し、それを開封したあと、再びKDをサブライセンス１６ａ内に密封することによって再暗号化を行っている。
【０１８３】
本発明の一実施形態では、図１４に戻って説明すると、ポータブルデバイス６２は、その中に (PU-BB-PD) が収められている証明書６３を含んでいる。従って、この場合も当然に理解されるように、コンピュータ６０は、ポータブルデバイス６２がその (PU-BB-PD) のある証明書６３をコンピュータ６０に送信することを要求し、実際にその証明書６３を受信することによって（ステップ１４０９ａａ）、ポータブルデバイス６２から (PU-BB-PD) を取得している（ステップ１４０９ａ）。証明書６３は、証明書６３が不正に変更されていないことを確証するために、(PR-BB-PD) に基づいて署名することができる。コンピュータ６０によって受信された証明書６３は、無効リスト６５と突き合わせて比較され、証明書６３が無傷であることが確かめられる（ステップ１４０９ａｂ）。この無効リスト６５は、ライセンス１６に入れておくことも（図１７）、コンピュータ６０に置いておくことも（図１４）、ほかの場所に置いておくことも可能である。
【０１８４】
本発明の一実施形態では、ポータブルデバイス６２からの証明書６２には、ポータブルデバイス６２に関する情報６７も収められている。この情報は、本発明の精神と範囲から逸脱しない限り、どのような情報であっても構わない。一実施形態では、この情報６７は、ライセンス１６がサブライセンス１６ｓの発行を許可しているかどうかを判断するために使用できる情報に関係している（ステップ１４０７）。例えば、情報６７には、ポータブルデバイス６２の名前、タイプおよびメーカ、ポータブルデバイス６２のDRMシステム３２ｐに置かれているブラックボックスのバージョンなどを含めることができる。当然に理解されるように、この情報６７を証明書６３の形でコンピュータ６０に与えると、コンピュータ１６は、サブライセンス１６ｓをポータブルデバイス６２に対して発行すべきかどうかを、ポータブルデバイス６２自身のプロパティに基づいて判断するために、広範囲にわたる要件を指定することが可能になる。
【０１８５】
ライセンス１６がサブライセンス１６ｓの発行を許可しているかどうかを判断するために、この情報６７が実際に使用されるときは、証明書６３はステップ１４０７の前に受信されていなければならない（ステップ１４０９ａａ）。これに応じて、ライセンス１６がサブライセンス１６ｓの発行を許可しているかどうかを判断するために、情報６７が実際に使用されるときは、ステップ１４０７には、証明書６３から情報６７を取得することと（ステップ１４０７ａ）、ライセンス１６がサブライセンス１６ｓの発行を許可しているかどうかの判断にその情報を適用すること（ステップ１４０７ｂ）が含まれている（図１５）。当然に理解されるように、情報６７に基づく判断は、それが望ましければ、どのような判断にすることも可能である。例えば、この判断には、特に、ポータブルデバイスのメーカおよび/またはタイプが許容し得るものかどうか、および/またはポータブルデバイス６２のDRMシステム３２ｐに置かれたブラックボックス３０が許容し得るものかどうかの考慮を含めることができる。
【０１８６】
次に、サブライセンス１６ｓを構成し、発行するとき、コンピュータ６０は、図１７に示すように、(PU-BB-CO (KD)) を (PU-BB-PD (KD)) に置き換えるようにライセンス１６を書き換えることによって、ライセンス１６からサブライセンス１６ｓを生成する。サブライセンス１６ｓを生成するとき、コンピュータ６０は、権利記述もサブライセンス１６ｓに組み入れる（図１５のステップ１４０９ｆ）。この権利記述は、基本的には、ライセンス１６内に記述されている権利記述である（例えば、図９のDRL ４８）。なお、一般的には、権利記述の変更は要求されないが、コンピュータ６０は、必要ならば、あるいは望ましければ、この権利記述を変更することができる。これとは別に、ライセンサは、サブライセンス１６ｓの権利記述をライセンス１６の中で規定することができ、その場合、サブライセンス１６ｓの権利記述は、ライセンス１６の権利記述とは大幅に異なり、および/またはそれとは別になっている。
【０１８７】
ほぼ生成されると、サブライセンス１６ｓは、サブライセンス１６ｓの内容を検証するための署名を追加することによって完成する（ステップ１４０９ｇ）。当然に理解されるように、この署名は、サブライセンス１６ｓの情報の少なくとも一部に基づいている。従って、この情報を変更すると、署名の検証が失敗することになる。この署名は (PU-BB-PD) にも基づいている。
【０１８８】
以上の説明から理解されるように、上述した図１５のステップは、コンピュータ６０側のDRMシステム３２のために書かれ、DRMシステム３２によってアクセス可能な関数または関数の集合によって実行される。従って、この関数または複数の関数は、ユーザがコンテンツ１２および/またはサブライセンス１６ｓをコンピュータ６０からポータブルデバイス６２へダウンロードしようとすると、アクチュエートする。
【０１８９】
コンテンツ１２をサブライセンス１６ｓに従ってポータブルデバイス６２上にレンダリングする
次に、図１８を参照して説明すると、ポータブルデバイス６２にコンテンツ１２とサブライセンス１６ｓがダウンロードされると、そのポータブルデバイス６２は、サブライセンス１６ｓの権利記述によって許可されていれば、次の手順でコンテンツ１２をレンダリングすることができる。
【０１９０】
1. サブライセンスの内容をその署名と (PR-BB-PD) に基づいて検証する（ステップ１６０１）。
2. (PR-BB-PD) を (PU-BB-PD (KD)) に適用してコンテンツ鍵 (KD) を取得する（ステップ１６０３）。
3. (KD) を適用して暗号化コンテンツ１２を解読する（ステップ１６０５）。
【０１９１】
サブライセンス１６のチェックアウトとチェックイン
前述したように、コンピュータ６０は、ほぼ無制限数のサブライセンス１６ｓを複数のポータブルデバイス６２に対して発行することができる。なお、ライセンス１６に対して発行されたサブライセンス１６ｓの数がコンピュータ６０上のステートストア４０（図４）にステート情報としてストアされるようにし、従って、コンピュータ６０側のDRMシステム３２がライセンス１６に対応する発行サブライセンスの数を記録しておき、そのサブライセンス１６の条項に従ってその数を制限するような構成にすることが可能である。さらに、この構成をチェックイン (check-in)/チェックアウト (check-out) 構成にすることも可能であり、そこでは、ストアされる数は、サブライセンス１６ｓがポータブルデバイス６２に「チェックアウト」されると増加し、サブライセンス１６ｓがポータブルデバイス６２から「チェックアウト」されると減少し、その数の最大値は、対応するライセンス１６の条項に従って設定されるようになっている。
【０１９２】
当然に理解されるように、サブライセンス１６ｓのチェックインはサブライセンス１６ｓをポータブルデバイス６２から除去することを含み、本発明の精神と範囲から逸脱しない限り、どのような方法で行うことも可能である。例えば、このチェックインには、サブライセンス１６ｓをポータブルデバイス６２からコンピュータ６０に転送し、サブライセンス１６ｓをポータブルデバイス６２から削除する、といったことを含めることができる。このチェックインはこの分野の精通者に公知であり、当然に理解されるはずであるので、そのメカニックスは、ここでは、これ以上詳しく説明することは省略する。
【０１９３】
注目すべきことは、このチェックイン/チェックアウト構成は、チェックアウトされたサブライセンス１６ｓをポータブルデバイス６２からストレージデバイス（図示せず）にコピーしておき（可能ならば）、そのサブライセンスをポータブルデバイス６２からコンピュータ６０にチェックインし、コピーされたサブライセンス１６ｓをストレージデバイス（図示せず）からポータブルデバイス６２に戻すように再コピーするようにすると、壊されることになることである。このようなことが起こると、サブライセンス１６ｓがチェックインされても、ポータブルデバイス６２にまだ残っていることになる。
【０１９４】
前述した破壊は、ポータブルデバイス６２にチェックアウトされた各サブライセンス１６ｓに関する情報がそのポータブルデバイス６２のステートストア４０にステート情報としてストアされるような構成にすると、防止することができる。ポータブルデバイス６２側のDRMシステム３２ｐは、各サブライセンス１６ｓをそこに適法に記録しておき、そのステートストア４０に記録されていないで、すでにコンピュータ６０にチェックインされていると思われるサブライセンス１６ｓを使用することを拒否することができる。しかし、このような構成にすると、ポータブルデバイス６２側のDRMシステム３２ｐが過度に複雑化することになり、チェックインまたはチェックアウトトランザクションに割り込みが起こった場合には、同期上の問題が起こるおそれがある。
【０１９５】
本発明の一実施形態では、この問題は、チェックアウトとチェックイン期間に任意のチャレンジ値または nonce'（ワンタイム鍵、以下 "nonce" という）を使用することによって防止されており、そこでは、そのエレメントが適法であることを示すためにnonceが別のエレメントと一緒に戻されるようにしている。本発明の精神と範囲から逸脱しない限り、どのような方法でも、任意のnonceを生成し、使用することが可能である。具体的には、図１９に戻って説明すると、この実施形態では、コンピュータ６０側の（DRMシステム３２）からポータブルデバイス６２側の（DRMシステム３２ｐ）へのサブライセンス１６ｓのチェックインは、次の手順によって達成されている。
【０１９６】
1. コンピュータ６０によってポータブルデバイス１６ｓにnonceを要求し、そのnonceを受信する（ステップ１７０１）。
【０１９７】
2. チェックアウトされたサブライセンスと受信したnonceを、コンピュータ６０からポータブルデバイス６２によって送信する（ステップ１７０３）。
【０１９８】
3. ステップ１７０１でコンピュータ６０から送信されたnonceが、ステップ１７０１でコンピュータ６０によって受信されたnonceと同じであることを、ポータブルデバイス６２によって結論する（ステップ１７０５）。
【０１９９】
4. 従って、送信されたnonceに付属して送信されたサブライセンス１６ｓが適法であり、コピーされたソースまたは別の場所からのものでないことを、ポータブルデバイス６２によって結論する（ステップ１７０７）。
【０２００】
当然のことであるが、これらのnonceが一致していなければ、つまり、どのnonceにも送信サブライセンス１６ｓが付属していなければ、ポータブルデバイス６２は、送信サブライセンス１６ｓが適法でないと結論するので、その送信サブライセンスをポータブルデバイス６２側のDRMシステム３２ｐのライセンスストア３８にストアすることを拒否することができる。従って、nonceは、送信サブライセンス１６ｓを検証または信用伝達 (trust-imparting) デバイスとして働く。
【０２０１】
なお、nonceはサブライセンス１６ｓにバインドされている必要がある。さもないと、そのメッセージをインターセプトする攻撃者は、nonceとライセンスをミックスして、一致させることが可能になる。１つのバインディング方法は、サブライセンスの署名部分にnonceを組み入れておくことである。
【０２０２】
サブライセンスをチェックアウトする一部として、チェックアウト済みサブライセンス１６ｓをチェックインするとき必要になるように、チェックアウト済みサブライセンス１６ｓは、DRMシステム３２がアクセスできるカタログ７０に追加される（ステップ１７０９）。このカタログ７０は、例えば、ステートストア４０にストアしておくことができる。好ましくは、図１４に示すように、カタログ７０は、各々のサブライセンス１６ｓごとに、チェックアウト済みサブライセンス１６ｓを特定する識別子 (ID) と、そのサブライセンス１６ｓがチェックアウトされる先のポータブルデバイス６２を特定する識別子 (ID) を含むエントリをそこに収めている。
【０２０３】
この場合、チェックインは、チェックアウト済みサブライセンス１６ｓをポータブルデバイス６２から削除または除去し、チェックアウト済みサブライセンス１６ｓが確かに削除されたとの信用通知をコンピュータ６０に与えることによって達成される。具体的には、ポータブルデバイス６２側（のDRMシステム３２ｐ）からコンピュータ６０側（のDRMシステム３２）へのサブライセンス１６ｓのチェックインは、次の手順によって達成される。
【０２０４】
5. ユーザの要求またはその他の要求によって、ポータブルデバイス６２はチェックアウト済みサブライセンス１６ｓをそこから削除する（ステップ１７１１）。
【０２０５】
6. ポータブルデバイス６２によってnonceをコンピュータ６０に要求し、そのnonceを受信する（ステップ１７１３）。
【０２０６】
7. 受信したnonce、ポータブルデバイス６２を特定する識別子 (ID)、およびポータブルデバイス６２に現在置かれているすべてのサブライセンス１６ｓのリストを、ポータブルデバイス６２によってコンピュータ６０に送信し、そこでは、削除されたチェックアウト済みサブライセンス１６ｓは送信リストから除かれている（ステップ１７１５）。
【０２０７】
8. ステップ１７１５でポータブルデバイス６２によって送信されたnonceは、ステップ１７１３でポータブルデバイス６２によって受信したnonceと同じであることを、コンピュータ６０によって結論する（ステップ１７１７）。
【０２０８】
9. 従って、送信されたnonceに付属して送信された識別子とリストは適法であり、別のソースからのものでないことを、コンピュータ６０によって結論する（ステップ１７１９）。
【０２０９】
10. コンピュータ６０によって、送信リストをカタログ７０と比較し、削除されたチェックアウト済みサブライセンス１６ｓはカタログ７０にあるが、送信リストにないことを記録する（ステップ１７２１）。
【０２１０】
11. 削除されたチェックアウト済みサブライセンス１６ｓを特定する識別子とポータブルデバイス６２を特定する識別子があるエントリをカタログ７０から削除する（ステップ１７２３）。
【０２１１】
従って、ステートストア４０内のカタログ７０は、サブライセンス１６ｓをコンピュータ６０からチェックアウトする、全ポータブルデバイス６２の全チェックアウト済みサブライセンス１６ｓのライブラリの働きをし、チェックアウト済みサブライセンス１６ｓを特定するエントリの存在は、特定のライセンス１６からチェックアウトされたサブライセンス１６ｓの数をカウントすることを目的とした「カウント」の働きをする。従って、このカウントは、チェックアウト済みサブライセンス１６ｓの数を得るために、カタログ７０をサーチすることが含まれている。
【０２１２】
ライセンスをチェックアウトする場合と同様に、ライセンスをチェックインする過程で、nonceが一致していなければ、つまり、どのnonceにも送信リストと識別子が付属していなければ、コンピュータ６０は、送信リストと識別子が適法でないと結論するので、送信リストと識別子に基づいてサブライセンス１６ｓをチェックインすることを拒否する。従って、この場合も、nonceは、送信リストと識別子の検証または信用伝達デバイスの働きをする。
【０２１３】
図１９に示すメカニズムでは、チェックインは、サブライセンス１６ｓをポータブルデバイス６２からコンピュータ６０に返送することによって行われない。むしろ、サブライセンス１６ｓがポータブルデバイス６２から削除され、削除されたことが、信用される形で送信リストを通してコンピュータ６０に通知される。このことから理解されるように、このメカニズムでは、ポータブルデバイス６２側のDRMシステム３２ｐは、どのサブライセンス１６ｓがそこにチェックアウトされたかに関する、どの特定ステート情報も保存しておく必要がない。また、カタログ７０を使用すると、コンピュータ６０は、各ライセンス１６に基づいてチェックアウトされた各サブライセンス１６ｓのカウント情報を保存しておく必要がない。
【０２１４】
結論
本発明に関連して実行されるプロセスおよびインスタンス化されるモジュールを実現するために必要なプログラムミングは、比較的単純で、プログラミング分野の精通者ならば当然に理解されるはずである。従って、そのプログラミングは本明細書に添付されていない。なお、本発明の精神と範囲から逸脱しない限り、どのようなプログラミングによっても、本発明を実現することが可能である。
【０２１５】
これまでの説明から理解されるように、本発明は新規で、有用な強制アーキテクチャを含み、任意の形体のデジタルコンテンツ１２を制御の下でレンダリングまたはプレイすることを可能にしており、そこでは、その制御は柔軟性があり、デジタルコンテンツ１２のコンテンツ所有者によって定義可能になっている。また、本発明は、新規で、有用な制御によるレンダリング環境を含み、その環境では、デジタルコンテンツ１２が、ポータブルデバイス６２のように、コンテンツ所有者の制御下に置かれていないコンピューティングデバイス１４上でレンダリングされる場合であっても、デジタルコンテンツ１２は、コンテンツ所有者によって指定された通りにしかレンダリングされないようになっている。さらに、本発明は、コンピューティングデバイス１４のユーザが、コンテンツ所有者が許可していない方法で１つのデジタルコンテンツ１２にアクセスする試みに対しても、そのデジタルコンテンツ１２に関してそのコンピューティングデバイス１４上のコンテンツ所有者の権利を強制するトラステッドコンポーネントを含んでいる。
【０２１６】
以上の説明から理解されるように、上述してきた実施形態は、本発明の新規概念から逸脱しない限り、種々の変更が可能である。具体的には、本発明は、PCまたはコンピュータ６０に直接に接続されたポータブルデバイス６２を中心に説明され、そこでは、コンピュータ６０がライセンス１６を所持し、そのライセンス１６がポータブルデバイス６２に送信されるサブライセンス１６ｓの基礎となるものとなっているが、本発明はもっと広い意味で定義されている。
【０２１７】
例えば、ポータブルデバイス６２は、実際には、ポータブルである必要はなく、実際には、動き回れないほどに束縛され、あるいは重量があっても構わない。従って、このデバイス６２は、本発明の精神と範囲から逸脱しない限り、別のコンピュータまたはPCにすることも可能である。さらに、「ポータブルデバイス」６２へのパイプとなるコンピュータ６０は、必ずしもPCである必要はなく、別のポータブルデバイスにすることも、セットトップボックス、ビデオコンソール、ゲームプレイステーション、電話、アプライアンス、パーソナルデジタルアシスタントなどのタイプのコンピューティングデバイスにすることさえ可能である。広い意味で説明すると、本発明では、上述してきたメカニズムを利用すると、どのデバイスも、他のどのデバイスのためにもサブライセンス１６ｓを準備し、その別のデバイスに配信することができる。
【０２１８】
さらに、デバイス６２は、コンピュータ６０に直接に接続されている必要はなく、実際には、ワイヤド（有線）またはワイヤレス（無線）LANまたはWAN（例えば、インターネット）などのネットワーク経由で間接的に接続することも可能である。従って、コンピュータ６０はそのネットワーク上の任意のコンピュータにすることも、そのネットワーク上の複数コンピュータの１つにすることも可能である。もっと広い意味では、デバイス６２がネットワーク上の任意のコンピュータからサブライセンス１６ｓを受信できる場合には、そのデバイスは、そのサブライセンス１６ｓをライセンスサーバ２４から直接に取得することができる。この場合には、当然に理解されるように、サブライセンス１６ｓは書き直されずに、ライセンスサーバ２４によって直接に生成されることになる。
【０２１９】
さらに、これまではポータブルデバイス６２を中心に説明されてきたが、サブライセンス１６ｓは、そのデバイス６２に装着され、他のデバイス６２や広い意味での他のデバイスに転送可能である、ポータブル媒体用に直接に書くことも可能である。当然のことであるが、いくつかの変更が必要になる。重要なことは、ポータブルデバイスの識別子 (ID) がポータブル媒体の識別子 (ID) になり、サブライセンス１６ｓはデバイス６２から独立して書かれることである。
【０２２０】
さらに、当然に理解されるように、場合によっては、サブライセンス１６ｓは書かれることも、ダウンロードされないこともある。その代わりに、サブライセンス１６ｓは暗黙的になり（例えば、すべてのコンテンツはライセンスと同じ扱い方を受ける）、いくつかのライセンスタイプがポータブルデバイス６２上に定義され、１つひとつのコンテンツ１２がライセンスタイプを特定する、といったことになる。
【０２２１】
従って、以上から理解されるように、本発明は、ここに開示されている特定の実施形態に限定されるものではなく、請求項に定義されている本発明の精神と範囲に属する変更を包含するものである。
【図面の簡単な説明】
【図１】本発明の一実施形態による強制アーキテクチャを示すブロック図である。
【図２】本発明の一実施形態による図１のアーキテクチャのオーサリングツールを示すブロック図である。
【図３】本発明の一実施形態による図１のアーキテクチャに関連して使用されるデジタルコンテンツをもつデジタルコンテンツパッケージを示すブロック図である。
【図４】本発明の一実施形態による図１のユーザのコンピューティングデバイスを示すブロック図である。
【図５】本発明の一実施形態に従ってコンテンツをレンダリングするために図４のコンピューティングデバイスのデジタル化権管理 (DRM) システムに関連して実行されるステップを示すフロー図である。
【図６】本発明の一実施形態に従ってコンテンツをレンダリングするために図４のコンピューティングデバイスのデジタル化権管理 (DRM) システムに関連して実行されるステップを示すフロー図である。
【図７】本発明の一実施形態に従って有効で、使用許可しているライセンスが存在するかどうかを判断するために、図４のDRMシステムに関連して実行されるステップを示すフロー図である。
【図８】本発明の一実施形態に従ってライセンスを取得するために図４のDRMシステムに関連して実行されるステップを示すフロー図である。
【図９】本発明の一実施形態に従って図１のアーキテクチャに関連して使用されるデジタルライセンスを示すブロック図である。
【図１０】本発明の一実施形態に従って新ブラックボックスを取得するために図４のDRMシステムに関連して実行されるステップを示すフロー図である。
【図１１】本発明の一実施形態に従ってライセンスと１つのデジタルコンテンツが有効であるかどうかを検査し、コンテンツをレンダリングするために図４のDRMシステムに関連して実行される鍵トランザクションステップを示すフロー図である。
【図１２】本発明の一実施形態に従ってライセンスのデジタル化権ライセンス (DRL) およびDRLを解釈する言語エンジンと共に図４のライセンスエバリュエータを示すブロック図である。
【図１３】本発明および/またはその一部の側面が組み込まれている汎用コンピュータを示すブロック図である。
【図１４】本発明の一実施形態に従ってコンテンツとそれに対応するサブライセンスをダウンロードする目的でポータブルデバイスがコンピュータに結合されている構成を示すブロック図である。
【図１５】本発明の一実施形態に従ってデジタルコンテンツとサブライセンスをコンピュータから図１４のポータブルデバイスに配信する際に実行されるステップを示すフロー図である。
【図１６】本発明の一実施形態に従ってデジタルコンテンツとサブライセンスをコンピュータから図１４のポータブルデバイスに配信する際に実行されるステップを示すフロー図である。
【図１７】本発明の一実施形態に従って図１５に示す方法でライセンスとそのライセンスから得られたサブライセンスを示すブロック図である。
【図１８】本発明の一実施形態に従ってサブライセンスに基づくコンテンツをレンダリングする際に図１４のポータブルデバイスによって実行されるステップを示すフロー図である。
【図１９】本発明の一実施形態に従ってサブライセンスをチェックアウトし、チェックインするために図１４のコンピュータとポータブルデバイスによって実行されるステップを示すフロー図である。
【符号の説明】
１０  強制アーキテクチャ
１２  デジタルコンテンツ
１２ｐ  デジタルコンテンツパッケージ
１４  ユーザのコンピューティングデバイス
１６  ライセンス
１６ｓ  サブライセンス
１８  オーサリングツール
２０  コンテンツ鍵データベース
２２  コンテンツサーバ
２４  ライセンスサーバ
２６  ブラックボックスサーバ
３０  ブラックボックス
３２  コンピュータ６０側のDRMシステム
３２ｐ  ユーザのコンピューティングデバイス側のDRMシステム
３４  レンダリングアプリケーション
３６  ライセンスエバリュエータ
３８  ライセンスストア
４０  ステートストア
４８  デジタル権ライセンス (DRL)
６０  コンピュータ
６２  ポータブルコンピューティングデバイス
【図１】
0004226849.tif 000009
【図２】
0004226849.tif 000010
【図３】
0004226849.tif 000011
【図４】
0004226849.tif 000012
【図５】
0004226849.tif 000013
【図６】
0004226849.tif 000014
【図７】
0004226849.tif 000015
【図８】
0004226849.tif 000016
【図９】
0004226849.tif 000017
【図１０】
0004226849.tif 000018
【図１１】
0004226849.tif 000019
【図１２】
0004226849.tif 000020
【図１３】
0004226849.tif 000021
【図１４】
0004226849.tif 000022
【図１５】
0004226849.tif 000023
【図１６】
0004226849.tif 000024
【図１７】
0004226849.tif 000025
【図１８】
0004226849.tif 000026
【図１９】
0004226849.tif 000027