コンテンツ操作を許可する方法及び装置
コンテンツアイテム（Ｃ１）について第１ユーザ（Ｐ２）により要求された操作をユーザ権（ＵＲ１）に従って許可する方法及びデバイス（Ｄ１）。ユーザ権は第１ユーザ又は第２ユーザ（Ｐ１）を識別し、該ユーザに前記コンテンツアイテムに要求された操作の実行を許可する。ユーザ権が第２ユーザを識別する場合には、前記操作は第１ユーザのユーザ権と第２ユーザのユーザ権をリンクする情報の受け取り次第許可される。この情報は、第１ユーザ及び第２ユーザを同じ許可ドメイン（ＡＤ）のメンバとして識別する１以上のドメイン証明書（ＤＣ１，ＤＣ２）を含むものとするのが好ましい。前記操作を可能にするコンテンツ権（ＣＲ１）を使用し、ユーザ権によってこのコンテンツ権（ＣＲ１）を第２ユーザに使用許可することができるようにするのが好ましい。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンテンツアイテムについて第１ユーザにより要求された操作を許可する方法に関する。本発明は更にコンテンツアイテムについて第１ユーザにより要求された操作を実行するデバイスに関する。
【背景技術】
【０００２】
近年、コンテンツ保護システムが急速に成長している。これらのシステムのいくつかはコンテンツを不正コピーから保護するのみであるが、他のものはユーザがコンテンツにアクセスすることも禁止する。第１のカテゴリはコピー防止（ＣＰ）システムと呼ばれている。ＣＰシステムは伝統的にコンシューマエレクトロニクス（ＣＥ）デバイスに集中しており、これは、このタイプのコンテンツ保護は安価に実施され、コンテンツ提供者と双方向インタラクションを必要としないと考えられていたからである。いくつかの例として、コンテンツスクランブリングシステム（ＣＳＳ）、ＤＶＤ ＲＯＭディスク及びＤＴＣＰの保護システム、IEEE1394 connectionsに対する保護システムがある。
【０００３】
第２のカテゴリはいくつかの名前で知られている。放送業界では、このカテゴリのシステムは一般に限定受信システム（ＣＡＳ）として知られているが、インターネット業界では一般にディジタル著作権管理（ＤＲＭ）システムとして知られている。
【０００４】
最近、新しいコンテンツ保護システムが導入されており、このシステムでは一組のデバイスが双方向接続を介して相互に認証することができる。この認証に基づいて、デバイスが互いを信頼して保護されたコンテンツを交換することができる。コンテンツに添付するライセンスには、ユーザが持つ権利及びユーザがコンテンツに実行許可された操作が記述される。このライセンスはジェネラルネットワーク秘密情報で保護され、家庭、或いは、もっと一般的には所定のドメイン（範囲，領域）内のデバイス間でのみ交換される。従って、デバイスのこのネットワークは許可ドメイン（Authorized Domain：ＡＤ）と呼ばれる。
【０００５】
許可ドメインのコンセプトは（著作権の保護を望む）コンテンツオーナと（コンテンツの自由な使用を望む）コンテンツコンシューマの双方の利益にかなうソリュージョンを見つけ出そうとするものである。基本原理は、許可ドメインの境界を越えない限りコンテンツを比較的自由に使用可能とする制御されたネットワーク環境を提供することにある。典型的には、許可ドメインは家庭環境の中心に置かれ、ホームネットワークともいう。勿論、他のシナリオも可能である。ユーザは、例えば、自分の携帯テレビジョンを旅行に持って行き、ホテルの部屋で自分の携帯テレビジョンを使って、自宅のビデオレコーダに蓄積されているコンテンツにアクセスすることができる。この携帯テレビジョンはホームネットワーク外にあるが、ユーザの許可ドメインの一部である。
【０００６】
デバイス間の安全な相互通信に必要な信頼は、安全な実施が得られることが試験され証明されたデバイスにのみ知られた秘密情報に基づくものである。秘密情報を知っていることは認証プロトコルを用いて試験される。これらのプロトコルに対する現在最もよく知られているソリュージョンは、1対の２つの異なる鍵を用いる「公開鍵」暗号化方式を用いるものである。この場合、試験すべき秘密情報は鍵ペアの秘密鍵であり、公開鍵は試験の結果を検証するために使用することができる。公開鍵の正当性を保証し、鍵ペアが認定デバイスの正当なペアであるかを検査するために、すべてのデバイスに対する公開／秘密鍵ペアの配布を管理する組織である認証局によりディジタル署名された証明書が公開鍵に添付される。簡単な実装では、認証局の公開鍵はデバイスにハードコードされる。
【０００７】
ＡＤのようなＤＲＭシステムのいくつかの実装例が既知である。しかし、これらのシステムは、マーケット内におけるそれらの配置及び受け入れを困難にする種々の制限や問題をこうむるのが典型的である。特に、十分に取り組まれていない重要な問題は、コンシューマが取得した権限をいつでもどこでも行使することができる許可ドメイン構造をどのように管理し維持するかである。現在のＡＤソリュージョンはコンシューマを特定の限定された一組のシステムに限定し、所望のフレキシビリティを提供しない。
【０００８】
一般的なアプローチは、コンテンツ権（コンテンツアイテムを利用するために必要な権利で、必要な復号鍵を含むのが典型的である）を購入する人にスマートカードのようなセキュアパーソナルデバイスを付与する。再生中、スマートカードがこの復号鍵をコンプライアント再生装置と共用する。従って、ユーザは自分のスマートカードを携帯する限りコンテンツを利用することができる。このソリュージョンは、スマートカードは限られた量のメモリを有し、すべての権利をカードに格納することができない欠点を有する。
【０００９】
このシステムの改良のために、コンテンツ権をスマートカードの公開鍵で暗号化し、これらの権利をどこかに、例えば多数の場所に、例えばコンテンツアイテムと一緒に格納可能にすることができる。しかし、コンテンツ権をユーザの家族とどのように共有可能にするについては今のところ全く不明である。現在、家族の一人がコンテンツアイテム、例えばコンパクトディスクに蓄積された楽曲（その利用権）を購入すると、この曲を家族の他のメンバと共有することができる。コンシューマはこのような共有をよく利用し、このような共用をＡＤベースシステムにも期待する。著作権法は、彼等が家族である限りこのような活動を許可するのが典型的である。ＤＲＭシステムは、第３者へのコピーを防止しようと試みているため、この種の許可された行為も不注意に阻止することになる。
【００１０】
コンテンツ権は家族メンバの各自のスマートカードの各自の公開鍵で再暗号化することができる。これは、すべての権利を個別に処理する必要があるので、かなりの時間と処理能力を要する。再暗号化されたコンテンツ権が供給されるべき特定のスマートカードを所有する家族メンバであるか検査するために、家族識別子をスマートカードに付加することができる。しかし、この方法は、１人のファミリメンバのスマートカードのコンテンツ権を削除又は取り消すことが極めて困難であるので、フレキシブルなソリュージョンでない。
【００１１】
本発明の目的はデバイスの代わりに個人に基づく権利管理を可能にする許可方法を提供することにある。
【００１２】
この目的は、コンテンツアイテムに第１ユーザにより要求された操作を、前記コンテンツアイテムに要求された前記操作を実行するために必要な情報を含むコンテンツ権と、前記第１ユーザを識別するとともに前記第１ユーザに前記コンテンツ権の使用を許可するユーザ権とに基づいて許可する本発明の方法によって達成される。ユーザ権は１人のユーザと１つのコンテンツ権とを結びつける唯一のものである。コンテンツ権は、例えば１つの必要な復号鍵を含むために、１つのコンテンツを利用(アクセス)するために必要とされる。各個人にコンテンツ権の使用を許可する多くのユーザ権を発行することにより個人に基づく権利管理が達成される。
【００１３】
この目的は、また、コンテンツアイテムに第１ユーザにより要求された操作を、第２ユーザを識別するとともに前記第２ユーザに前記コンテンツアイテムに要求された操作の実行を許可するユーザ権に基づいて許可し、前記操作の許可は第１ユーザのユーザ権と第２ユーザのユーザ権をリンクする情報の受取り時に行う本発明の方法によって達成される。ユーザ権によって、各個人がどのデバイスを使いたいかと無関係に、各個人に操作の実行を許可することができる。リンク情報は、コンテンツが存在するデバイスと無関係に又はコンテンツに操作を行う必要があるかもしれないコンテンツ権のような情報と無関係に、複数のユーザに権利の共有を可能にする。従って、権利管理はデバイスの変わりに個人に基づいて行われる。
【００１４】
リンク情報は、第１及び第２ユーザを同じ許可ドメインのメンバとして識別する１以上のドメイン証明書を含むのが好ましい。コンテンツアイテムへのアクセス権を特定の家族、又は、もっと一般的には特定のドメインのメンバと共有可能にするのが望ましい。この目的のために、ドメイン証明書（グループ又はドメインを示す証明書）を信頼できる第３者機関により発行してだれが特定のドメインのメンバであるかを特定する。今、第１ユーザが操作の実行を許可されていないが、同じドメイン内にこのような権利を有する第２ユーザがいる場合には、第１ユーザは依然として操作を実行することが許される。ユーザ権はシステム内のどこに格納してもよい。
【００１５】
かくして、
（所定数の）コンテンツの利用権を個人的に購入すること、
このような権利を家族/家庭内で共有すること、
家族の１人としてこのような権利を任意のデバイスで(世界中の)どこででも行使すること、
このような権利を（家族内及び外の）他の人に転送すること、
必要に応じ権利の取消及び／又は更新を行うこと、
家族構成の変化に対処すること、
権利秘密情報の暴露及び不正行為（例えばハッキング）に対処すること、
が可能になる。
【００１６】
本発明の方法は、一実施例では、コンテンツアイテムに要求された操作を実行するために必要な情報を含むコンテンツ権を受信し、第２ユーザのユーザ権は該コンテンツ権の使用を第２ユーザに許可するものとする。だれでもユーザ権を得ることができるので、他の人が所有するかもしれない他のユーザ権と独立に、コンテンツ権を行使することができる。コンテンツ権は、例えばコンテンツを利用するために必要な復号鍵を含んでいるために、デバイスが操作を実行することが可能になる。ユーザ権はコンテンツ権をデバイスで利用することを特定のユーザに許可するものである。このデバイスは、その権利が有効であるか及びユーザが有効であるか検査する必要がある。第２ユーザは、２人のユーザを結びつける正しいドメイン証明書も有効である場合に許可される。
【００１７】
他の実施例では、コンテンツ権が許可ドメインを識別しない場合には操作は許可しない。これによりコンテンツ権を特定の許可ドメインに限定することができる。この方法は権利管理を一層きめ細かくすることができるのみならず、特定の許可ドメイン内のデバイスを秘密解除して（コンテンツ権により与えられる）復号鍵を得ようとするハッカーによる損傷を制限することもできる。この実施例を更に拡張するために、オプションとして、対応する復号鍵がドメイン内のデバイスに利用可能である暗号鍵を用いてコンテンツ権を少なくとも部分的に暗号化することができるようにする。これによりコンテンツ権はドメイン外では使用不能にすることができる。
【００１８】
本発明の他の目的は、個人に基づいた権利管理を可能とするデバイスを提供することにある。
【００１９】
この目的は、コンテンツアイテムに第１ユーザにより要求された操作を、前記コンテンツアイテムに要求された前記操作を実行するために必要な情報を含むコンテンツ権と、前記第１ユーザを識別するとともに前記第１ユーザに前記コンテンツ権の使用を許可するユーザ権とに基づいて実行するよう構成された本発明のデバイスによって達成される。
【００２０】
この目的は、また、コンテンツアイテムに第１ユーザにより要求された操作を、第２ユーザを識別するとともに前記第２ユーザに前記コンテンツアイテムに要求された操作の実行を許可するユーザ権に基づいて実行するよう構成された装置であって、前記操作は第１ユーザのユーザ権と第２ユーザのユーザ権をリンクする情報の受取り時に許可するよう構成された本発明のデバイスによって達成される。
【００２１】
前記リンク情報は、第１及び第２ユーザを同じ許可ドメインのメンバとして識別する１以上のドメイン証明書を含むものとするのが好ましい。コンテンツアイテムの利用権を家族のメンバ、もっと一般的には特定のドメインのメンバと共有できるようにするのが望ましい。
【００２２】
本発明のデバイスは、一実施例では、コンテンツアイテムに要求された操作を実行するために必要な情報を含むコンテンツ権を受信するよう構成し、第２ユーザのユーザ権は該コンテンツ権の使用を第２ユーザに許可するものとする。この場合、対応する復号鍵が当該デバイスに使用可能である暗号鍵を用いてコンテンツ権の少なくとも一部分を暗号化するのが好ましい。このようにすると、特定の許可されたドメイン内のデバイスのみがコンテンツ権を使用可能となるので、コンテンツ権を特定のドメインに有効に限定することができる。
【００２３】
他の実施例では、前記コンテンツ権に該コンテンツ権の信頼性の検証を可能にするディジタル署名を付与する。この場合、デバイスは、前記ディジタル署名を許可されたコンテンツ提供者と関連するディジタル証明書を用いて正しく検証できた場合に前記操作を実行するよう構成する。このようにすると、コンテンツ提供者自体が「公式」コンテンツ権を生成することができる。
【００２４】
更に他の実施例では、本発明のデバイスは、前記ディジタル署名を特定のデバイスと関連するディジタル証明書を用いて正しく検証できた場合に前記操作を実行するよう構成する。このようにすると、第３者の関与の必要なしに、（該特定のデバイス上に生成された）パーソナルコンテンツも再生その他に使用することができる。
【００２５】
この実施例の改良例では、本発明のデバイスは、前記ディジタル署名が許可されたコンテンツ提供者と関連するディジタル証明書を用いて正しく検証できないとともに前記許可されたコンテンツ提供者と関連するディジタル透かしが前記コンテンツアイテムに存在しない場合に前記操作の実行を拒否するよう構成する。このようにすると、悪意のユーザが例えばテレビジョンスクリーンからアナログ記録を生成することにより公式コンテンツをパーソナルコンテンツとして通用させようとするときでも、悪意のユーザは「公式」コンテンツに対するコンテンツ権を生成することはできない。
【００２６】
更に他の実施例では、本発明のデバイスは、コンテンツアイテムのロバストなフィンガープリントを決定し、決定したロバストなフィンガープリントが前記コンテンツ権に含まれるロバストなフィンガープリントと一致しない場合に前記操作の実行を拒否するよう構成する。このようにすると、悪意のユーザがパーソナルコンテンツに対するコンテンツ権を生成し、これを「公式」コンテンツに対して使用しようと試みことはできない。
【００２７】
本発明のこれらの特徴及び他の特徴は図面に示す実施例を参照する明らかになる。
これらの図面を通して、同一もしくは対応する機能部は同一の符号で示されている。図面に示す機能部のいくつかは典型的にはソフトウエアで実現され、これらの機能部はソフトウエアモジュールやオブジェクトのようなソフトウエアエンティティ自体も表すものとする。
【００２８】
図１は個人、権利及びコンテンツに基づく許可ドメイン（ＡＤ）のモデルを示す。許可ドメインＡＤはコンテンツＣ１，Ｃ２，Ｃ３，．．，Ｃｋ，権利Ｒ１，Ｒ２，Ｒ３，．．．，Ｒｍ及び個人Ｐ１，Ｐ２，Ｐ３，．．．，Ｐｎを含む。本モデルは、コンテンツアイテム、例えばコンテンツアイテムＣｉはドメイン内に持ち込んだりドメイン外に持ち出すことができること及び個人、例えば個人Ｐｊはドメインに登録したりドメインから登録を取り消すことがことができることも示している。許可ドメインアーキテクチャ及び実装オプションに関するこれ以上の情報については、国際特許出願公開ＷＯ03/047204（出願人整理番号PHNL010880）又は国際特許出願番号PCT/IB03/01940（出願人整理番号PHNL010455）を参照されたい。
【００２９】
図1のモデルが与えられるドメインで使用可能ないくつかの機能例は次の通りである。
ＡＤの会員管理：
個人識別（個人がどのＡＤに所属するか）
ＡＤへの個人の登録
ＡＤからの個人の登録取消
ＡＤの個人−権利リンク管理：
個人−権利リンク識別（どの人が権利を使用できるか）
個人−権利リンクの生成
個人−権利リンクの切断
【００３０】
実際にはコンテンツはデバイスを操作するユーザによってアクセス／利用することができるのみである点に注意する必要がある。以下の説明では、システム内で使用するデバイスは「コンプライアント(準拠)」及び「パブリック（公開）」デバイスであるものとする。このことは、デバイスは所定の操作規則に従う（例えばコンテンツをディジタルインターフェース上に不正に出力しない）ことを意味するとともに、デバイスの所有権は重要でない（パブリックである）ことを意味する。デバイスコンプライアンス管理、即ちコンプライアントデバイス識別、デバイスの更新及びデバイスの取消、は（既知の技術を用いて）しかるべく行われものとし、ここではこれ以上考察しない。コンテンツ権はデバイスコンプライアンス管理を行うために使用することができる。
【００３１】
ユーザ権は1人のユーザと1つのコンテンツ権（１つのコンテンツを復号するために必要とされる）とを結びつける唯一のものである。このユーザ権を用いることにより、本発明のシステムでは次のように機能し得る５つのメインエンティティがある。
【００３２】
コンテンツ：コンテンツアイテムは暗号化され（多くのオプションがあり、例えばコンテンツタイトルごとに固有の鍵を用いる）、システム内の任意の場所に存在させることができる。
【００３３】
コンテンツ権：コンテンツ権は所定のコンテンツアイテムを利用するための規則（例えば１８歳以上の視聴年齢制限又はヨーロッパ市場のみ等）を含む。システムは、コンテンツ権をコンテンツタイトルごとに一意にすることができ、またコンテンツの見本（コピー）ごとに一意にすることさえできる意味でフレキシブルである。コンテンツ権はコンプライアントデバイスにのみ転送すべきである。もっとセキュアな規則は、コンテンツ権を許可されたユーザ（即ちユーザ権によって特定のコンテンツ権にアクセスすることを許可されたユーザ）により操作されるコンプライアントデバイスにのみ転送し得るように強制するものである。コンテンツ権はコンテンツと一緒に、例えば光ディスクに蓄積することもできる。
【００３４】
ユーザ権：（所定のコンテンツに属する）所定のコンテンツ権の使用を個人に許可するコンテンツ提供者によって発行される証明書である。ユーザ権は原理的にはシステム内のどこにあってもよい。ＳＰＫＩ認証（例えばＸ．５０９に準拠する）を用いてこのようなユーザ権を実施することができる。
【００３５】
デバイス：（コンプライアント）デバイスは個人識別装置（例えばスマートカード）又は生体認証（又はその両方）によってユーザを識別し、（例えばスマートカード又は他のデバイスから）当該ユーザが所定のコンテンツ権を使用できることを証明する証明書を収集する。このコンテンツ権は、これが格納されたスマートカードから得ることができ、また（適切な証明書の提示後に）ネットワーク上の別のデバイスから（安全に転送して）得ることができる。
【００３６】
ユーザ：ユーザは生体認証又は好ましくはユーザが携帯する個人識別装置（例えばスマートカード）により識別される。後者は、（オフラインデバイス上のコンテンツを利用するために）権利をユーザに携帯させることができるとともに署名を生成して自己の証明書（ユーザ権）を発行することができるために好ましい。正当な所有者以外のだれもこの識別装置を使用できないようにこの識別デバイス自体を生体認証機構により保護してもよい。
【００３７】
図２は、スマートカードＩＤを携帯するユーザにより操作されているデバイスＤ１の一例を示す。このユーザはコンテンツアイテムＣ１に、例えばコンテンツアイテムのレンダリング、コンテンツアイテムの記録、コンテンツアイテムの転送又はコンテンツアイテムのコピーの生成のような操作を行いたい。デバイスＤ１は、インターネット上の遠隔データベースＵＲＤＢから、好ましくはディジタル証明書として具体化されるユーザ権を得るとともにこれをローカル記憶媒体ＵＲに格納する。
【００３８】
コンテンツアイテムＣ１に前記操作を行うために必要とされるコンテンツ権（同様に好ましくはディジタル証明書として具体化される）を第２デバイスＤ２から得て、ローカル記憶媒体ＣＲに格納する。コンテンツ権の転送を開始する前に、デバイスＤ２はユーザのユーザ権を検査し（これは前述したようにコンテンツ権を転送するための規則に依存する）、デバイスＤ１がコンプライアントか検査する。この目的のために、デバイスＤ１及びＤ２にはそれぞれの認証モジュールＡＵＴＨが設けられる。これらのモジュールは、例えば公開鍵ベース認証を可能にするために公開／個人（秘密）鍵ペアのそれぞれの個人鍵及び関連する公開鍵の証明書を具えている。
【００３９】
コンテンツアイテムＣ１に対する操作は、当該コンテンツアイテムＣ１に対する要求操作を実行するために必要な情報を含むコンテンツ権と第１ユーザを識別するとともに第１ユーザに該コンテンツ権の使用を許可するユーザ権があれば許可される。他のシステムでは、例えばシステム内のコンテンツに対するすべての操作が常に許可されている場合には、別個のコンテンツ権の使用を不要にすることができる。
【００４０】
ユーザに操作の実行を許可するユーザ権がない場合、又はユーザにコンテンツ権の使用を許可するユーザ権がない場合には、この操作は通常行われない。しかし、第１ユーザのユーザ権と第２ユーザのユーザ権をリンクする情報を受信する場合にはこの操作は依然として許可することができる。このような情報は任意のタイプのものとすることができ、例えば両ユーザを識別する証明書又はユーザ権がリンクされていることを示すＷｅｂサーバ上のリストとすることができる。この情報は一方（又は両方）のユーザ権自体に含めることもできる。以下に説明するように、この情報は１以上のドメイン証明書の形で付与するのが好ましい。
【００４１】
提示するソリュージョンは、ユーザ、コンテンツ所有者及び信頼できる第３者機関が各自固有の個人鍵／公開鍵ペアを維持し、各自の個人鍵で署名をすることにより証明書を発行することができる公開鍵基盤のアベイラビリティを保証する。可能性の一つはＳＰＫＩ／ＳＤＳＩ基盤で規定されている証明書を用いることである。
【００４２】
許可ドメインの概念を導入するために、発明者等は他のタイプの証明書をシステムに導入することを提案する。どの人／エンティティが特定ドメインに属するかを定義するドメイン証明書と呼ぶ証明書を（信頼できる）第３者機関により発行する。このような証明書は主体（個人）の識別子（例えば生体情報、公開鍵）と該主体がその一部であると宣言された許可ドメインの識別子（例えば名前、公開鍵）とを含む。証明書は発行する第３者機関の公開鍵で署名される。更に、証明書は適切な取消システムと連携する「発行日」及び「有効期限」のような通常フィールドを含む必要がある。このドメイン証明書の実現にはＳＰＫＩ「名前証明書」を用いることができる。
【００４３】
例えば、１つの家庭ドメインをそこに住むすべてのユーザに対し定義することができる。これは、自冶体（又はその代表者）がユーザの登録住所を宣言する証明書を発行することにより行うことができる。このような証明書は個人（ユーザ）とその家族との唯一の関係を生成する。
【００４４】
ドメイン証明書は種々の方法で実施することができる。一実施例では、各ユーザに、自分を特定の許可ドメインのメンバとして識別する個別のドメイン証明書を発行する。２つのドメイン証明書のそれぞれのＡＤ識別子の比較は２人のユーザが同一ドメインのメンバであるかどうかを立証する。この方法ではすべてのドメイン証明書を個別に管理することができ、各自のドメイン証明書は他の人が許可ドメインに加わったり離れたりすることに影響されない。
【００４５】
他の実施例では、１つの許可ドメインのメンバに対する証明書を単一のドメイン証明書に列記する。この方法では２人のユーザが１つの許可ドメインに属するかどうかの検査がはるかに容易になる。更に、この場合にはすべての人が自分のドメインの他の全メンバのＡＤ会員情報を自動的に有するので、個別の証明書を受信する必要がない。しかし、新しい人がＡＤに加わると、すべての人は新しいドメイン証明書の発行を受けなければならない。
【００４６】
コンテンツへのアクセス（利用）を同じ許可ドメイン内に住んでいる人に許可することは次のように行うことができる。許可ドメイン（家庭）ＡＤ内に住む個人Ｐ１がコンテンツ権ＣＲ１、例えばコンテンツアイテムＣ１の再生を行使するユーザ権を有する場合、第２の個人Ｐ２も、同じ家庭に属するならば、以下の証明書：
Ｐ１がＣＲ１を行使する権利を有することを示す、コンテンツ提供者により署名されたユーザ権ＵＲ１；
Ｐ１がＡＤのメンバであることを示す、自冶体により署名されたドメイン証明書ＤＣ１；及び
Ｐ２がＡＤのメンバであることを示す、自冶体により署名されたドメイン証明書ＤＣ２；
をコンプライアントデバイスＤ１に提示することにより、コンテンツ権ＣＲ１を行使することができる。
【００４７】
この状態を図３に示す。デバイスＤ１は証明書が真の許可された発行者により署名されたものであることを検査するために所定のルート公開鍵を知っているものとする。
【００４８】
オプションとして、コンテンツ提供者はドメイン内の他の人には所定の状況の下でのみコンテンツの再生を許すことができる。この場合には、このことをユーザ権にいくつかの余分のビットを用いて記述する必要がある。ドメイン内の使用に関するパーミッションの記述に加えて、他のフラグやビットをユーザ権証明書に付加することができる。例えば、第１世代コピー又はワンタイム再生に対するパーミッションに対応するビットを証明書に付加することができる。このようなビットはコンテンツ権ＣＲ１に付加することもでき、この場合にはコンテンツ権の行使にどのユーザ権が使用されるかと無関係になる。
【００４９】
本発明のシステムは所謂クロス許可ドメイン権も可能にする。これらはコンテンツを許可ドメインの境界を超えた利用を可能にする権利である。これは、コンプライアントデバイスが従わなければならない許可されたクロスドメイン動作を示す追加のフィールドをユーザ権に付加することにより達成することができる。ユーザ権の１つのフィールドに、例えば家庭許可ドメイン外のユーザにはユーザ権証明書を発行すべきでないことを意味する「ＸＡＤ＝ｎｏ」のようなステートメントを含ませることができる。この目的のためにはＳＰＫＩ許可証明書におけるデリゲーションタグを用いることができる。このようにすると、シリアルコピー管理が実現され、コピーを１世代までに制限することができる。「COPY-ONCE」制限を実現することも望ましい。
【００５０】
システムを管理しやすく一貫したものにするためには、いくつかのルート公開鍵をデバイスが知っている必要がある。これは、システムに存在する証明書（及び証明書チェーン）を検査するために必要である。デバイスが知っていなければならないシステム内の信頼できる第３者機関のルート／マスタ鍵のいくつかを以下に列挙する。
【００５１】
コンテンツ所有者又は代表者のルート鍵：ユーザ権を検査するために使用（ユーザ権管理）。
デバイスコンプライアンスマネージャのルート鍵：システムの他のデバイスが（依然として）コンプライアントであるか検査するために使用（デバイスコンプライアンス管理）。
命名権限局（例えば家庭ドメイン証明書を発行する機関）のルート鍵：許可家庭ドメイン内の家族関係を検査するために使用（ドメイン管理）。
ユーザ管理のルート鍵：個々のユーザの鍵ペア（スマートカード）が真正であるか及び改ざんされていないか検査するために使用（ユーザ管理）。
【００５２】
権利の所有権及び家族（又は他のドメイン）の構成は時間とともに変化する。その上、デバイスがハッキングされたり、秘密鍵が知られたりするかもしれない。従って、以下の場合にダイナミックな対応を考える必要がある。
ドメイン（家族メンバ）管理：家族の構成は変化し得る。
ユーザ権管理：ユーザ権は変化し得る。ユーザは権利を他の人に譲ることができる。
ユーザ管理：ＩＤデバイスがハッキングされたり、ユーザが亡くなることがある。
デバイスコンプライアンス管理：デバイスがハッキングされることがあり、その場合には取消／更新の必要がある。
【００５３】
家族の構成は証明書に表示し、即ち証明書に家族のメンバを記載する。システムは、家族のメンバを限定された有効期限とともに記載するドメイン証明書を用いることにより家族構成の変化に対処する。有効期限の経過後は、家族は信頼できる第３者機関に新しい証明書を申請する必要がある。例えば、地域行政機関がこのような信頼できる第３者機関として作用し、家族構成の変化を考慮することができる。
【００５４】
日付／時間をコンテンツ権又はユーザ権に含めることで容易に、確実に且つ安全に転送することができる点に注意されたい。このようにすると、デバイスはドメイン証明書を、その日付がユーザ権又はコンテンツ権の日付より後である場合にのみ受諾することができる。デバイスは今後の使用のために日付／時間を「現在」時間に対する下方境界として格納することもできる。また、ある種の通し番号機構をユーザ権及びコンテンツ権に用いてドメイン証明書の受諾に対して同様の効果を達成することもできる。
【００５５】
ユーザ権は新しいドメイン証明書を家族に配布するために用いることもできる。これも実に好適である。この場合には、家族メンバがユーザ権を取り使いたい場合、該メンバは新しいドメイン証明書を自動的に受け取る。この方法は使用証明書(ユーザ権証明書)配布者がドメイン証明書も配布することを意味する（これは別の機関で行うこともできること勿論である）。
【００５６】
家庭証明書に対する取消機構は、このような取消証明書は阻止することができ、それらの配布が保証されないので、あまり有用でない。取消メッセージはユーザ権（又はローカルコンテンツ権）と一緒に配布することができる。
【００５７】
ユーザ権は更に有効期限を用いて処理する。このような有効期限は無期限に設定することもできる。しかし、依然としてユーザ権の転送に対処する必要がある（即ち、移動命令）。最も困難な場合は無限の有効期限を有するユーザ権の場合である。いくつかの可能なソリュージョンは：
このオプションを付与しない。
サービス提供者を用いて転送を行い、新しいユーザ権を付与し、古いユーザ権を取り消す。
取消メッセージをユーザＩＤデバイス（もし使用可能であれば）に送り、これに格納させる。ユーザがコンテンツを利用したいとき、コンテンツの利用に使用するデバイスはユーザＩＤデバイス内の取消リストを閲覧する。
取消メッセージをドメイン証明書に入れ（証明書が極めて大きくなり、拡張可能なソリュージョンでない）、コンテンツの利用時に、ユーザ権証明書の提示に加えて、ドメイン証明書の提示も要求する。
ユーザ権をユーザＩＤデバイス（固有の個人鍵での署名）の助けで転送し、取消データをＩＤデバイスに付加し、取消データを他の家族メンバに送信する。有効期限付きのユーザ証明書を発行する（これはある時点で更新する必要がある）。
ユーザ権を使用する前に外部取消データベースの閲覧を要求する。
【００５８】
前述したように、個人は各自の生体データに基づいて、又は各自のＩＤデバイス（例えば無線スマートカード、携帯電話等）に基づいて本人確認をすることができる。生体データは各人に生まれながらのものであり、これらのデータは「自動」であるという。しかし、ＩＤデバイスはハッキング、複写、紛失等の惧れがある。このような「イベント」に対処するためにはＩＤデバイスの注意深い管理が要求される。
【００５９】
ＩＤデバイスは公開/個人鍵ペアを用いる公開鍵アルゴリズムで動作するものとする。ベストはＩＤデバイスが有効期限を有するものとする（又は所定の時点で、新コンテンツに対し新ＩＤデバイスが必要とされるものとする）。個人鍵が知られた場合には、最初にデバイスＩＤを取り消す必要がある。このような取消メッセージは新しいコンテンツ権又は新しいユーザ権に含めることができる。更に、その人は家族証明書から除去すべきである。これは、ハッカーに追加のハードルを与えて家族メンバが所有するコンテンツを利用し得なくする。
【００６０】
ＩＤデバイスの更新は、個人がコンテンツを購入するとき、即ちユーザ権証明書を得るときに自動的に行われる点に注意されたい。
【００６１】
デバイスコンプライアンス管理はコンテンツ権の配布に基づいて行うことができる。コンプライアントデバイスのみがコンテンツ権を得ることを許される。デバイス管理及び安全なコンテンツ権配布を行うために種々の技術、例えばセキュア認証チャネル（ＳＡＣ）及び証明書を用いる、又はＣＰＰＭ及びＣＰＲＭで使用されるＭＫＢ構造を用いることができる（http://www.4centity.com/参照）。
【００６２】
一つの特定のソリュージョンは２つのタイプのコンテンツ権：グローバル権（世界中で使用可能）及びパーソナル／ファミリ権（コンテンツを購入したユーザに局所的にとどまり、配布できない）を用いる。その理由は、これにより、サービス提供者により署名された権利にカウンティング機構の使用が可能になるためであり、これはユーザ権では不可能である。
【００６３】
スペシフィック／カウンティング権利の場合には、コンテンツ権はパーソナル／ファミリ権とする必要がある。ユーザ権は、グローバル又はパーソナル/ファミリコンテンツ権を使用しなければならないことを示す必要がある。もっとジェネリックにするために、特定の１つのコンテンツに対し種々のコンテンツ権を許可する。ユーザ権はどの特定のコンテンツ権を使用すべきか示す。
【００６４】
コンテンツ権は、ユーザ権に対する取り消しデータ及びパーソナルＩＤデバイス又はコンテンツの再生前に所定の取り消しデータベースへコンタクトする命令を含むことができる。時間ベースの権利は時間情報を得るためにハートビート機構を用いることにより実現することができる（例えば国際特許出願ＷＯ03/058948（出願人整理番号PHNL020010）参照）。
【００６５】
コンテンツ権は、コンプライアントであり且つ該当するユーザ権を持つユーザにより操作されるデバイスにのみ転送されることが重要な前提である。この前提は常に正しいとはかぎらない。その理由は、実世界では（コンテンツの解読に必要な）秘密鍵を漏洩不能に保つことはできないためである。このようなことが起こると、ハッカーは同じコンテンツに対して新しいコンテンツ権をもとのコンテンツ権よりも少数の制限で生成することができる。一般に、コンテンツ提供者は、誰でも任意のコンテンツをシステムに入力可能にするコンテンツ権を生成できることは望んでいない。
【００６６】
上述した問題の最良の解決方法は、コンテンツ提供者がコンテンツ権にディジタル署名をすることである。更に、（コンプライアント）デバイスはコンテンツ権の署名を検査してコンテンツ提供者により署名されたコンテンツ権のみを受け取るようにしなければならない。従って、デバイスはコンテンツ提供者の（ルート）公開鍵を知っていなければならない。コンテンツ権に署名をすることは必須要件ではないこと勿論である。
【００６７】
この方法の追加の利点は、コンプライアントデバイスが知っていなければならない（ルート）公開鍵が少なくなることである。コンプライアントデバイスは、特にユーザ権の発行者、デバイスコンプライアンスマネージャ及び命名権者の（ルート）公開鍵を知らなければならない。これらの値はデバイスに何らかの方法で格納する必要がある。しかし、コンテンツ権がコンテンツ提供者に署名される場合には、これらの公開鍵はコンテンツ権に付加するだけとすることができる。デバイスはコンテンツ提供者の（ルート）公開鍵を知っているだけでよい。このようにすると、コンテンツ提供者がユーザ権、コンプライアンス証明書及びネーム証明書の発行を誰に許可するかを決めることができる。
【００６８】
更に、証明書取消情報をどこで検査すべきかに関する情報をコンテンツ権に付加することができる。ハッカーはコンテンツ権内のこの付加情報を変更することはできない。その理由は、正当なコンテンツ権はコンテンツ提供者によりディジタル署名されなければならないためである。
【００６９】
公式コンテンツ提供者（ＣＰと表記する）の個人鍵で署名されたコンテンツ権のみでＣＰから到来するコンテンツをシステムに安全に導入することができる。しかし、ユーザがパーソナルコンテンツ（休日の個人写真又はホームビデオ記録など）をシステムに導入したい場合、ユーザは所要のコンテンツ権を生成するために最初にＣＰを巻き込む必要がある。これは、ＣＰはパーソナルコンテンツを制御する権限を持たないために望ましくない。このため、パーソナルコンテンツをシステムに導入するための最初のステップはコンテンツ権にＣＰ以外の誰かが署名することを許可することにある。
【００７０】
導入する第1の規則は、ＣＰにより発行されないコンテンツ権はコンプライアントデバイスで署名されなければならないことである。そうでない場合には、コンテンツ権はこれらの権利を使用したい如何なる（コンプライアント）デバイスも拒絶しなければならない。このことは、パーソナルコンテンツはコンプライアントデバイスを介してシステムに入力できるのみであることを意味する。このようなコンプライアントデバイスは更にコンテンツに電子透かしがないことを検査する必要がある。電子透かし付きのコンテンツはもともとＣＰ出身であるため、ユーザは自己のコンテンツ権をこのようなコンテンツに対して生成する必要はない。
【００７１】
以上提示したソリュージョンは典型的なアタックを許すのでまだ完全に安全でない。ユーザが所定の自作のコンテンツに対するコンテンツ権を生成したものとする。このとき、悪意のユーザはこのコンテンツを、コンテンツ権が生成された後（従ってコンプライアントデバイスがそれに署名した後）に、別のコンテンツと置き換えることができる。すなわち、悪意のユーザは（不正）コンテンツを承認されたコンテンツ権内のコンテンツ鍵で（再）暗号化するとともに、このコンテンツに、当該コンテンツ権が生成された自作コンテンツと同一の識別子を与えることができる。それゆえ、同一の（漏洩した）コンテンツ鍵で暗号化すれば多数の不正コンテンツをシステムに入力することができる。
【００７２】
この問題を解決するためには、コンテンツ権と実際のコンテンツとの間にセキュアなリンクが必要である。コンテンツのフィンガープリントの利用はこのリンクを提供することができる。コンテンツアイテムのフィンガープリントは、コンテンツアイテムをわずかに変更するときでも変化しない当情報信号の表現である。このようなフィンガープリントは「ロバストハッシュ」として既知である。ロバストハッシュとは、例えば圧縮／解除、符号化、ＡＤ／ＤＡ変換などによるデータ処理及びデグラデーションに対してロバストなハッシュ関数をいう。ロバストハッシュはロバスト要約、ロバスト署名又は知覚ハッシュとも呼ばれる。フィンガープリント生成方法の一例は国際特許出願ＷＯ02/065782（出願人整理番号PHNL010110）に開示されている。
【００７３】
コンテンツ権はフィンガープリントがコンテンツのどの部分から正確に見つけだせるかを記述する追加の情報を含む必要がある。そして、コンテンツ全体のフィンガープリント情報（多量のデータ）を付加する代わりに、所定の時間ポイントにおけるフィンガープリント情報をその時間値と一緒に付加することができる。コンプライアントデバイスは署名前にこのフィンガープリント情報をコンテンツ権に付加する。コンテンツ権を（コンテンツの再生のために）使用するとき、コンプライアントデバイスはこのコンテンツ権に含まれるフィンガープリントデータが実際のコンテンツ（時間ポイントで指示された部分）に見つかるか検査する必要がある。見つからなければ、コンテンツ権を拒否しなければならない。
【００７４】
要するに、この実施例は次の通りである。
「公式」コンテンツ提供者ＣＰからのコンテンツは電子透かし処理され、コンテンツ権は該コンテンツ権がリンクするコンテンツについてのフィンガープリント情報を含まなければならない。
パーソナルコンテンツに対するコンテンツ権を生成するとき、コンプライアントデバイス（又はコンテンツ／サービス提供者）は電子透かしが存在しないことを検査しなければならない。
コンプライアントデバイスはフィンガープリント情報を、それに署名する前に、（パーソナルコンテンツに対する）新しいコンテンツ権に付加しなければならない。
該コンテンツ権を使いたいコンプライアントデバイスは該コンテンツ権内のフィンガープリント情報が実際のコンテンツと一致するか検査しなければならない。
【００７５】
原システムと同様に、コンテンツ権の生成者は、コンテンツを利用するためにはユーザ権発行者、命名権者及びデバイスコンプライアンスマネージャの（ルート）公開鍵のどれを検査しなければならないか決定する。ユーザは任意のパーティ（自分又は自分のデバイスを含む）に自分のパーソナルコンテンツに対する添付ユーザ権の発行を許可することができる。
【００７６】
デバイスにコンテンツのフィンガープリント情報を入力するアイディアは国際特許出願ＰＣＴ/ＩＢ03/００８０３（出願人整理番号PHNL020246）のアイディアに近似する。しかし、本発明のソリュージョンはもっと具体的で、コンテンツ提供者からの公式コンテンツ（電子透かし処理されている）とパーソナルコンテンツとを明確に区別している。
【００７７】
コンテンツが電子透かし処理されている場合には、コンプライアントデバイスは、そのコンテンツが公式コンテンツ提供者により署名された適正なコンテンツ権を有する場合にのみそのコンテンツをプレイすることができる。電子透かしが検出されない場合には、コンテンツは「パーソナルコンテンツ」と分類され、添付コンテンツ権は任意のコンプライアントデバイスで署名される。
【００７８】
他のオプショナルな拡張として、「コンテンツ権」をドメインレベルで「パーソナル化またはドメイン化」することができる。これは、一般に、コンプライアントデバイスを許可ドメインがコンテンツ権内に識別されない場合に操作の実行を拒否するように構成することにより行うことができる。このようにすると、コンテンツ権が「誤った」ドメインを識別する（又はドメインを全く識別しない）場合には、許可ドメインの人でもこの権利を行使できない。しかし、このアプローチは、膨大な量（数千万）のフューチャコンプライアントデバイスを危険にさらすおそれがある。即ち、１つのデバイスがハッキングされたら（十分高速に取り消しされないと）、これが全システム内のすべてのコンテンツ権に漏洩するおそれがある。
【００７９】
このパーソナル化及びドメイン化は、許可ドメイン内のデバイスが使用可能である復号鍵に対応する暗号鍵を用いてコンテンツ権を暗号化することにより行うのが好ましい。復号鍵は典型的にはＩＤデバイスから入手することができる。コンテンツ提供者はコンテンツ権を追加の鍵ＣＲＥＫ（Content Right Encryption Key：コンテンツ権暗号鍵）で次のように暗号化する。
Ｅ{ＣＲＥＫ}[コンテンツ権]
【００８０】
次に、この鍵をすべてのドメインメンバが使用可能なＩＤカード内の公開ドメイン鍵（ＰＤＫ）で暗号化する（コンテンツ提供者はこの公開ドメイン鍵を売買トランザクション中にＩＤカードから得ているためにこの鍵を使用することができる）。暗号化されたＣＲＥＫはコンテンツ権と連結し：
Ｅ{ＰＤＫ} {ＣＲＥＫ}||Ｅ{ＣＲＥＫ}[コンテンツ権]
を生成し、次にこれを(必要なら)コンテンツと一緒にユーザに送る。
【００８１】
すべてのユーザＩＤデバイス(例えばスマートカード)が個人(秘密)ドメイン鍵を有するものとすれば、ユーザ認証後に、再生のためのプロトコルは次のオペレーションとすることができる。
【００８２】
再生デバイスはユーザＩＤデバイスに、
Ｅ{ＰＤＫ} {ＣＲＥＫ}||ＰＫ_再生_デバイス
を送る。
ユーザＩＤデバイスは秘密鍵ＳＤＫでの復号によりＣＲＥＫを取り出し、次いでＣＲＥＫを再生デバイスの公開鍵（ＰＫ_再生_デバイス）で暗号化する。
次いでユーザＩＤデバイスは再生デバイスに、
Ｅ{ＰＫ_再生_デバイス}[ＣＲＥＫ]
を送る。
再生デバイスは今やＣＲＥＫを取り出すことができ、次いでコンテンツ権を復号し、コンテンツを復号することができる。
【００８３】
要するに、種々のデータ要素及びそれらの機能は以下の２つの表にリストアップされている。これらの表は単なる例示であって本発明を限定するものではない。
【００８４】
【表１】
【００８５】
【表２】
【００８６】
本発明を実施する最良の方法の一実施例を以下に検討する。このシステムの実施例はＳＰＫＩ/ＳＤＳＩフレームワークを使用する。SPKI Certificate Theory (Internet RFC2693)及びCarl Ellison, “Improvements on Conventional PKI wisdom”, Ist annual PKI Research Workshop, April 2002参照。Ｘ．５０９フレームワーク内の実施も可能であるとみなせる。すべてのエンティティが固有の公開/個人鍵ペアを維持するものと仮定する。公開鍵及び個人鍵はそれぞれ記号ＰＫ及びＳＫで示す。
【００８７】
ＳＰＫＩネーム証明書は４-タプル（Ｋ，Ａ，Ｓ，Ｖ）として表され、
Ｋ＝発行者の公開鍵
Ａ＝決定されたローカルネーム
Ｓ＝証明書の主体
Ｖ＝正当性仕様
である。
【００８８】
ＳＰＫＩ許可証明書は５-タプル（Ｋ，Ｓ，Ｄ，Ｔ，Ｖ）として表され、
Ｋ＝発行者の公開鍵
Ｓ＝証明書の主体
Ｄ＝デリゲーションビット
Ｔ＝与えられたパーミッションを指定するタグ
Ｖ＝正当性仕様
である。
【００８９】
デリゲーションビットが「真」に設定されている場合、主体は更に（タグ内に指定されている）パーミッションを他の鍵及びネームに委任することができる。
【００９０】
許可ドメインは、個人の公開鍵を公式ユニーク識別子（例えばネーム及びアドレス情報）に結合するＳＰＫＩネーム証明書を中央権限局に発行させることにより形成することができる。「アドレス権限局」ＡＡが個人「ＰＩ」へのアクセスを付与するこのような証明書の一例（ＳＰＫＩフォーム）はＳＫ_ＡＡ（即ちアドレス権限局の個人鍵）により署名された４-タプルを意味するＣｅｒｔ１＝ＳＫ_ＡＡ{(Ｋ，Ａ，Ｓ，Ｖ)}であり、ここで
Ｋ＝ＰＫ_ＡＡ
Ａ＝住所番号
Ｓ＝ＰＫ_Ｐ１
簡単のために正当性仕様はここでは省略した。この仕様は取消及び更新システムに従って選択する必要がある。
【００９１】
他のソリュージョンは許可ドメイン内のすべての人のＰＫを単一のドメイン証明書内にグループ化するものである。これは、一つのドメイン証明書を必要とするのみであるという追加の利点を有する。このような証明書の一例は、ＳＫ_ＡＡ（即ちアドレス権限局の個人鍵）により署名された４-タプルを意味するＣｅｒｔ1b＝ＳＫ_ＡＡ{(Ｋ，Ａ，Ｓ，Ｖ)}であり、ここで
Ｋ＝ＰＫ_ＡＡ
Ａ=家庭証明書
Ｓ＝ＰＫ_Ｐ１，ＰＫ_Ｐ２，ＰＫ_Ｐ３，．．．
【００９２】
さて、所定のコンテンツを再生するのに必要とされる規則及び鍵を保持するコンテンツ権ＣＲ１があるものとする。コンテンツ所有者ＣＯ１は次の証明書：Ｃｅｒｔ２＝ＳＫ_ＣＯ１{(Ｋ，Ｓ，Ｄ，Ｔ，Ｖ)}を発行することにより個人Ｐ１を許可することができ、ここで
Ｋ＝ＰＫ_ＣＯ１
Ｓ＝ＰＫ_Ｐ１
Ｄ＝偽
Ｔ＝ＣＲ１
【００９３】
証明書Ｃｅｒｔ２では、デリゲーションビットは「偽」に設定される。これは、ユーザは（コンテンツ権ＣＲ１の）ユーザ権を他のユーザに委任できないことを示す。デリゲーションビットが「真」に設定されている場合、個人Ｐ１はパーミッションを委任することができる。トータルシステムは、コンプライアントデバイスが同一（許可された）ドメイン内の他のユーザがＣＲ１を使用しそのコンテンツアイテムを再生することを依然として許すように設計することができる。この場合にはデリゲーションビットは権利が許可ドメインの外部に広がるのを阻止する。
【００９４】
ユーザはデバイスを介してコンテンツにアクセスする。ユーザが適正な一組の証明書を所有する場合にコンプライアントデバイスのみがアクセス（コンテンツ権内の鍵でのコンテンツの復号）を提供する。許可されたユーザがない場合にはたぶんデバイスはコンテンツ権を得ることができない点に注意されたい。
【００９５】
ユーザに属する証明書はネットワーク上の任意のロケーションから取り出し、ユーザのスマートカードに格納することができる。コンテンツ権はスマートカードに格納することもできる。これはコンテンツをオフラインデバイスで再生するために必要とされる。コンテンツ権をネットワークを介してアクセスし得るユーザの信頼できるプロキシに格納できるようにするのが有用であるかもしれない。このようにすると、ユーザは自分のスマートカードに格納されておらずネットワーク上の他の場所から入手し得ないコンテンツ権を取り出すことが依然としてできる。
【００９６】
以下のリストはソリュージョンを実行するときに必要とされる(又は有用な)証明書内のいくつかのフィールドを示す。このリストは前述した標準ＳＰＫＩ証明書フィールド以外のフィールドのみを示す。
署名日；
署名された証明書上のデバイス識別子（デバイスコンプライアンスサブシステム内で取消になり得るデバイスのレピュテーション情報の収集を促進する）
コピーワンス／コピーネバー／コピーノーモア及び類似フラグ；
リケーション／取消システムのサーバ；
【００９７】
上述の実施例は説明のためのものであって本発明を制限するものでなく、当業者は添付の特許請求の範囲から逸脱することなく多くの他の実施例を設計することができる。
【００９８】
本発明はいくつかの個別の素子を具えるハードウエアで実現することができるとともに、適切にプログラムされたコンピュータで実現することもできる。
【００９９】
いくつかの手段を列挙したデバイス請求項では、これらの手段のいくつかはハードウエアの１つの同一のアイテムで具体化することができる。所定の手段が互いに異なる従属請求項に列挙されている単なる事実は、これらの手段の組み合わせが有利に使用できないことを示しているのではない。
【０１００】
要するに、本発明はコンテンツアイテム（Ｃ１）について第１ユーザ（Ｐ２）により要求された操作をユーザ権（ＵＲ１）に従って許可する方法及びデバイス（Ｄ１）を提供するものである。ユーザ権は第１ユーザ又は第２ユーザ（Ｐ１）を識別し、該コンテンツアイテムについて要求された操作の実行を当該ユーザに許可することができる。ユーザ権が第２ユーザを識別する場合には、前記操作は第１ユーザのユーザ権と第２ユーザのユーザ権をリンクする情報の受取り時に許可される。この情報は第１及び第２ユーザを同一の許可ドメイン（ＡＤ）のメンバとして識別する１以上のドメイン証明書（ＤＣ１，ＤＣ２）を含むものとするのが好ましい。操作の権利を付与するコンテンツ権（ＣＲ１）を使用し、ユーザ権はこのコンテンツ権の使用を第２ユーザに許可するものとするのが好ましい。
【図面の簡単な説明】
【０１０１】
【図１】個人、権利及びコンテンツに基づく許可ドメインのモデルを示す。
【図２】コンテンツアイテムに操作を実行したいスマートカードを携帯するユーザにより操作されるデバイスの一例を示す。
【図３】１個人が同じドメインに属する他の個人のユーザ権を用いてどのようにコンテンツ権を行使するかを示す。
【技術分野】
【０００１】
本発明は、コンテンツアイテムについて第１ユーザにより要求された操作を許可する方法に関する。本発明は更にコンテンツアイテムについて第１ユーザにより要求された操作を実行するデバイスに関する。
【背景技術】
【０００２】
近年、コンテンツ保護システムが急速に成長している。これらのシステムのいくつかはコンテンツを不正コピーから保護するのみであるが、他のものはユーザがコンテンツにアクセスすることも禁止する。第１のカテゴリはコピー防止（ＣＰ）システムと呼ばれている。ＣＰシステムは伝統的にコンシューマエレクトロニクス（ＣＥ）デバイスに集中しており、これは、このタイプのコンテンツ保護は安価に実施され、コンテンツ提供者と双方向インタラクションを必要としないと考えられていたからである。いくつかの例として、コンテンツスクランブリングシステム（ＣＳＳ）、ＤＶＤ ＲＯＭディスク及びＤＴＣＰの保護システム、IEEE1394 connectionsに対する保護システムがある。
【０００３】
第２のカテゴリはいくつかの名前で知られている。放送業界では、このカテゴリのシステムは一般に限定受信システム（ＣＡＳ）として知られているが、インターネット業界では一般にディジタル著作権管理（ＤＲＭ）システムとして知られている。
【０００４】
最近、新しいコンテンツ保護システムが導入されており、このシステムでは一組のデバイスが双方向接続を介して相互に認証することができる。この認証に基づいて、デバイスが互いを信頼して保護されたコンテンツを交換することができる。コンテンツに添付するライセンスには、ユーザが持つ権利及びユーザがコンテンツに実行許可された操作が記述される。このライセンスはジェネラルネットワーク秘密情報で保護され、家庭、或いは、もっと一般的には所定のドメイン（範囲，領域）内のデバイス間でのみ交換される。従って、デバイスのこのネットワークは許可ドメイン（Authorized Domain：ＡＤ）と呼ばれる。
【０００５】
許可ドメインのコンセプトは（著作権の保護を望む）コンテンツオーナと（コンテンツの自由な使用を望む）コンテンツコンシューマの双方の利益にかなうソリュージョンを見つけ出そうとするものである。基本原理は、許可ドメインの境界を越えない限りコンテンツを比較的自由に使用可能とする制御されたネットワーク環境を提供することにある。典型的には、許可ドメインは家庭環境の中心に置かれ、ホームネットワークともいう。勿論、他のシナリオも可能である。ユーザは、例えば、自分の携帯テレビジョンを旅行に持って行き、ホテルの部屋で自分の携帯テレビジョンを使って、自宅のビデオレコーダに蓄積されているコンテンツにアクセスすることができる。この携帯テレビジョンはホームネットワーク外にあるが、ユーザの許可ドメインの一部である。
【０００６】
デバイス間の安全な相互通信に必要な信頼は、安全な実施が得られることが試験され証明されたデバイスにのみ知られた秘密情報に基づくものである。秘密情報を知っていることは認証プロトコルを用いて試験される。これらのプロトコルに対する現在最もよく知られているソリュージョンは、1対の２つの異なる鍵を用いる「公開鍵」暗号化方式を用いるものである。この場合、試験すべき秘密情報は鍵ペアの秘密鍵であり、公開鍵は試験の結果を検証するために使用することができる。公開鍵の正当性を保証し、鍵ペアが認定デバイスの正当なペアであるかを検査するために、すべてのデバイスに対する公開／秘密鍵ペアの配布を管理する組織である認証局によりディジタル署名された証明書が公開鍵に添付される。簡単な実装では、認証局の公開鍵はデバイスにハードコードされる。
【０００７】
ＡＤのようなＤＲＭシステムのいくつかの実装例が既知である。しかし、これらのシステムは、マーケット内におけるそれらの配置及び受け入れを困難にする種々の制限や問題をこうむるのが典型的である。特に、十分に取り組まれていない重要な問題は、コンシューマが取得した権限をいつでもどこでも行使することができる許可ドメイン構造をどのように管理し維持するかである。現在のＡＤソリュージョンはコンシューマを特定の限定された一組のシステムに限定し、所望のフレキシビリティを提供しない。
【０００８】
一般的なアプローチは、コンテンツ権（コンテンツアイテムを利用するために必要な権利で、必要な復号鍵を含むのが典型的である）を購入する人にスマートカードのようなセキュアパーソナルデバイスを付与する。再生中、スマートカードがこの復号鍵をコンプライアント再生装置と共用する。従って、ユーザは自分のスマートカードを携帯する限りコンテンツを利用することができる。このソリュージョンは、スマートカードは限られた量のメモリを有し、すべての権利をカードに格納することができない欠点を有する。
【０００９】
このシステムの改良のために、コンテンツ権をスマートカードの公開鍵で暗号化し、これらの権利をどこかに、例えば多数の場所に、例えばコンテンツアイテムと一緒に格納可能にすることができる。しかし、コンテンツ権をユーザの家族とどのように共有可能にするについては今のところ全く不明である。現在、家族の一人がコンテンツアイテム、例えばコンパクトディスクに蓄積された楽曲（その利用権）を購入すると、この曲を家族の他のメンバと共有することができる。コンシューマはこのような共有をよく利用し、このような共用をＡＤベースシステムにも期待する。著作権法は、彼等が家族である限りこのような活動を許可するのが典型的である。ＤＲＭシステムは、第３者へのコピーを防止しようと試みているため、この種の許可された行為も不注意に阻止することになる。
【００１０】
コンテンツ権は家族メンバの各自のスマートカードの各自の公開鍵で再暗号化することができる。これは、すべての権利を個別に処理する必要があるので、かなりの時間と処理能力を要する。再暗号化されたコンテンツ権が供給されるべき特定のスマートカードを所有する家族メンバであるか検査するために、家族識別子をスマートカードに付加することができる。しかし、この方法は、１人のファミリメンバのスマートカードのコンテンツ権を削除又は取り消すことが極めて困難であるので、フレキシブルなソリュージョンでない。
【００１１】
本発明の目的はデバイスの代わりに個人に基づく権利管理を可能にする許可方法を提供することにある。
【００１２】
この目的は、コンテンツアイテムに第１ユーザにより要求された操作を、前記コンテンツアイテムに要求された前記操作を実行するために必要な情報を含むコンテンツ権と、前記第１ユーザを識別するとともに前記第１ユーザに前記コンテンツ権の使用を許可するユーザ権とに基づいて許可する本発明の方法によって達成される。ユーザ権は１人のユーザと１つのコンテンツ権とを結びつける唯一のものである。コンテンツ権は、例えば１つの必要な復号鍵を含むために、１つのコンテンツを利用(アクセス)するために必要とされる。各個人にコンテンツ権の使用を許可する多くのユーザ権を発行することにより個人に基づく権利管理が達成される。
【００１３】
この目的は、また、コンテンツアイテムに第１ユーザにより要求された操作を、第２ユーザを識別するとともに前記第２ユーザに前記コンテンツアイテムに要求された操作の実行を許可するユーザ権に基づいて許可し、前記操作の許可は第１ユーザのユーザ権と第２ユーザのユーザ権をリンクする情報の受取り時に行う本発明の方法によって達成される。ユーザ権によって、各個人がどのデバイスを使いたいかと無関係に、各個人に操作の実行を許可することができる。リンク情報は、コンテンツが存在するデバイスと無関係に又はコンテンツに操作を行う必要があるかもしれないコンテンツ権のような情報と無関係に、複数のユーザに権利の共有を可能にする。従って、権利管理はデバイスの変わりに個人に基づいて行われる。
【００１４】
リンク情報は、第１及び第２ユーザを同じ許可ドメインのメンバとして識別する１以上のドメイン証明書を含むのが好ましい。コンテンツアイテムへのアクセス権を特定の家族、又は、もっと一般的には特定のドメインのメンバと共有可能にするのが望ましい。この目的のために、ドメイン証明書（グループ又はドメインを示す証明書）を信頼できる第３者機関により発行してだれが特定のドメインのメンバであるかを特定する。今、第１ユーザが操作の実行を許可されていないが、同じドメイン内にこのような権利を有する第２ユーザがいる場合には、第１ユーザは依然として操作を実行することが許される。ユーザ権はシステム内のどこに格納してもよい。
【００１５】
かくして、
（所定数の）コンテンツの利用権を個人的に購入すること、
このような権利を家族/家庭内で共有すること、
家族の１人としてこのような権利を任意のデバイスで(世界中の)どこででも行使すること、
このような権利を（家族内及び外の）他の人に転送すること、
必要に応じ権利の取消及び／又は更新を行うこと、
家族構成の変化に対処すること、
権利秘密情報の暴露及び不正行為（例えばハッキング）に対処すること、
が可能になる。
【００１６】
本発明の方法は、一実施例では、コンテンツアイテムに要求された操作を実行するために必要な情報を含むコンテンツ権を受信し、第２ユーザのユーザ権は該コンテンツ権の使用を第２ユーザに許可するものとする。だれでもユーザ権を得ることができるので、他の人が所有するかもしれない他のユーザ権と独立に、コンテンツ権を行使することができる。コンテンツ権は、例えばコンテンツを利用するために必要な復号鍵を含んでいるために、デバイスが操作を実行することが可能になる。ユーザ権はコンテンツ権をデバイスで利用することを特定のユーザに許可するものである。このデバイスは、その権利が有効であるか及びユーザが有効であるか検査する必要がある。第２ユーザは、２人のユーザを結びつける正しいドメイン証明書も有効である場合に許可される。
【００１７】
他の実施例では、コンテンツ権が許可ドメインを識別しない場合には操作は許可しない。これによりコンテンツ権を特定の許可ドメインに限定することができる。この方法は権利管理を一層きめ細かくすることができるのみならず、特定の許可ドメイン内のデバイスを秘密解除して（コンテンツ権により与えられる）復号鍵を得ようとするハッカーによる損傷を制限することもできる。この実施例を更に拡張するために、オプションとして、対応する復号鍵がドメイン内のデバイスに利用可能である暗号鍵を用いてコンテンツ権を少なくとも部分的に暗号化することができるようにする。これによりコンテンツ権はドメイン外では使用不能にすることができる。
【００１８】
本発明の他の目的は、個人に基づいた権利管理を可能とするデバイスを提供することにある。
【００１９】
この目的は、コンテンツアイテムに第１ユーザにより要求された操作を、前記コンテンツアイテムに要求された前記操作を実行するために必要な情報を含むコンテンツ権と、前記第１ユーザを識別するとともに前記第１ユーザに前記コンテンツ権の使用を許可するユーザ権とに基づいて実行するよう構成された本発明のデバイスによって達成される。
【００２０】
この目的は、また、コンテンツアイテムに第１ユーザにより要求された操作を、第２ユーザを識別するとともに前記第２ユーザに前記コンテンツアイテムに要求された操作の実行を許可するユーザ権に基づいて実行するよう構成された装置であって、前記操作は第１ユーザのユーザ権と第２ユーザのユーザ権をリンクする情報の受取り時に許可するよう構成された本発明のデバイスによって達成される。
【００２１】
前記リンク情報は、第１及び第２ユーザを同じ許可ドメインのメンバとして識別する１以上のドメイン証明書を含むものとするのが好ましい。コンテンツアイテムの利用権を家族のメンバ、もっと一般的には特定のドメインのメンバと共有できるようにするのが望ましい。
【００２２】
本発明のデバイスは、一実施例では、コンテンツアイテムに要求された操作を実行するために必要な情報を含むコンテンツ権を受信するよう構成し、第２ユーザのユーザ権は該コンテンツ権の使用を第２ユーザに許可するものとする。この場合、対応する復号鍵が当該デバイスに使用可能である暗号鍵を用いてコンテンツ権の少なくとも一部分を暗号化するのが好ましい。このようにすると、特定の許可されたドメイン内のデバイスのみがコンテンツ権を使用可能となるので、コンテンツ権を特定のドメインに有効に限定することができる。
【００２３】
他の実施例では、前記コンテンツ権に該コンテンツ権の信頼性の検証を可能にするディジタル署名を付与する。この場合、デバイスは、前記ディジタル署名を許可されたコンテンツ提供者と関連するディジタル証明書を用いて正しく検証できた場合に前記操作を実行するよう構成する。このようにすると、コンテンツ提供者自体が「公式」コンテンツ権を生成することができる。
【００２４】
更に他の実施例では、本発明のデバイスは、前記ディジタル署名を特定のデバイスと関連するディジタル証明書を用いて正しく検証できた場合に前記操作を実行するよう構成する。このようにすると、第３者の関与の必要なしに、（該特定のデバイス上に生成された）パーソナルコンテンツも再生その他に使用することができる。
【００２５】
この実施例の改良例では、本発明のデバイスは、前記ディジタル署名が許可されたコンテンツ提供者と関連するディジタル証明書を用いて正しく検証できないとともに前記許可されたコンテンツ提供者と関連するディジタル透かしが前記コンテンツアイテムに存在しない場合に前記操作の実行を拒否するよう構成する。このようにすると、悪意のユーザが例えばテレビジョンスクリーンからアナログ記録を生成することにより公式コンテンツをパーソナルコンテンツとして通用させようとするときでも、悪意のユーザは「公式」コンテンツに対するコンテンツ権を生成することはできない。
【００２６】
更に他の実施例では、本発明のデバイスは、コンテンツアイテムのロバストなフィンガープリントを決定し、決定したロバストなフィンガープリントが前記コンテンツ権に含まれるロバストなフィンガープリントと一致しない場合に前記操作の実行を拒否するよう構成する。このようにすると、悪意のユーザがパーソナルコンテンツに対するコンテンツ権を生成し、これを「公式」コンテンツに対して使用しようと試みことはできない。
【００２７】
本発明のこれらの特徴及び他の特徴は図面に示す実施例を参照する明らかになる。
これらの図面を通して、同一もしくは対応する機能部は同一の符号で示されている。図面に示す機能部のいくつかは典型的にはソフトウエアで実現され、これらの機能部はソフトウエアモジュールやオブジェクトのようなソフトウエアエンティティ自体も表すものとする。
【００２８】
図１は個人、権利及びコンテンツに基づく許可ドメイン（ＡＤ）のモデルを示す。許可ドメインＡＤはコンテンツＣ１，Ｃ２，Ｃ３，．．，Ｃｋ，権利Ｒ１，Ｒ２，Ｒ３，．．．，Ｒｍ及び個人Ｐ１，Ｐ２，Ｐ３，．．．，Ｐｎを含む。本モデルは、コンテンツアイテム、例えばコンテンツアイテムＣｉはドメイン内に持ち込んだりドメイン外に持ち出すことができること及び個人、例えば個人Ｐｊはドメインに登録したりドメインから登録を取り消すことがことができることも示している。許可ドメインアーキテクチャ及び実装オプションに関するこれ以上の情報については、国際特許出願公開ＷＯ03/047204（出願人整理番号PHNL010880）又は国際特許出願番号PCT/IB03/01940（出願人整理番号PHNL010455）を参照されたい。
【００２９】
図1のモデルが与えられるドメインで使用可能ないくつかの機能例は次の通りである。
ＡＤの会員管理：
個人識別（個人がどのＡＤに所属するか）
ＡＤへの個人の登録
ＡＤからの個人の登録取消
ＡＤの個人−権利リンク管理：
個人−権利リンク識別（どの人が権利を使用できるか）
個人−権利リンクの生成
個人−権利リンクの切断
【００３０】
実際にはコンテンツはデバイスを操作するユーザによってアクセス／利用することができるのみである点に注意する必要がある。以下の説明では、システム内で使用するデバイスは「コンプライアント(準拠)」及び「パブリック（公開）」デバイスであるものとする。このことは、デバイスは所定の操作規則に従う（例えばコンテンツをディジタルインターフェース上に不正に出力しない）ことを意味するとともに、デバイスの所有権は重要でない（パブリックである）ことを意味する。デバイスコンプライアンス管理、即ちコンプライアントデバイス識別、デバイスの更新及びデバイスの取消、は（既知の技術を用いて）しかるべく行われものとし、ここではこれ以上考察しない。コンテンツ権はデバイスコンプライアンス管理を行うために使用することができる。
【００３１】
ユーザ権は1人のユーザと1つのコンテンツ権（１つのコンテンツを復号するために必要とされる）とを結びつける唯一のものである。このユーザ権を用いることにより、本発明のシステムでは次のように機能し得る５つのメインエンティティがある。
【００３２】
コンテンツ：コンテンツアイテムは暗号化され（多くのオプションがあり、例えばコンテンツタイトルごとに固有の鍵を用いる）、システム内の任意の場所に存在させることができる。
【００３３】
コンテンツ権：コンテンツ権は所定のコンテンツアイテムを利用するための規則（例えば１８歳以上の視聴年齢制限又はヨーロッパ市場のみ等）を含む。システムは、コンテンツ権をコンテンツタイトルごとに一意にすることができ、またコンテンツの見本（コピー）ごとに一意にすることさえできる意味でフレキシブルである。コンテンツ権はコンプライアントデバイスにのみ転送すべきである。もっとセキュアな規則は、コンテンツ権を許可されたユーザ（即ちユーザ権によって特定のコンテンツ権にアクセスすることを許可されたユーザ）により操作されるコンプライアントデバイスにのみ転送し得るように強制するものである。コンテンツ権はコンテンツと一緒に、例えば光ディスクに蓄積することもできる。
【００３４】
ユーザ権：（所定のコンテンツに属する）所定のコンテンツ権の使用を個人に許可するコンテンツ提供者によって発行される証明書である。ユーザ権は原理的にはシステム内のどこにあってもよい。ＳＰＫＩ認証（例えばＸ．５０９に準拠する）を用いてこのようなユーザ権を実施することができる。
【００３５】
デバイス：（コンプライアント）デバイスは個人識別装置（例えばスマートカード）又は生体認証（又はその両方）によってユーザを識別し、（例えばスマートカード又は他のデバイスから）当該ユーザが所定のコンテンツ権を使用できることを証明する証明書を収集する。このコンテンツ権は、これが格納されたスマートカードから得ることができ、また（適切な証明書の提示後に）ネットワーク上の別のデバイスから（安全に転送して）得ることができる。
【００３６】
ユーザ：ユーザは生体認証又は好ましくはユーザが携帯する個人識別装置（例えばスマートカード）により識別される。後者は、（オフラインデバイス上のコンテンツを利用するために）権利をユーザに携帯させることができるとともに署名を生成して自己の証明書（ユーザ権）を発行することができるために好ましい。正当な所有者以外のだれもこの識別装置を使用できないようにこの識別デバイス自体を生体認証機構により保護してもよい。
【００３７】
図２は、スマートカードＩＤを携帯するユーザにより操作されているデバイスＤ１の一例を示す。このユーザはコンテンツアイテムＣ１に、例えばコンテンツアイテムのレンダリング、コンテンツアイテムの記録、コンテンツアイテムの転送又はコンテンツアイテムのコピーの生成のような操作を行いたい。デバイスＤ１は、インターネット上の遠隔データベースＵＲＤＢから、好ましくはディジタル証明書として具体化されるユーザ権を得るとともにこれをローカル記憶媒体ＵＲに格納する。
【００３８】
コンテンツアイテムＣ１に前記操作を行うために必要とされるコンテンツ権（同様に好ましくはディジタル証明書として具体化される）を第２デバイスＤ２から得て、ローカル記憶媒体ＣＲに格納する。コンテンツ権の転送を開始する前に、デバイスＤ２はユーザのユーザ権を検査し（これは前述したようにコンテンツ権を転送するための規則に依存する）、デバイスＤ１がコンプライアントか検査する。この目的のために、デバイスＤ１及びＤ２にはそれぞれの認証モジュールＡＵＴＨが設けられる。これらのモジュールは、例えば公開鍵ベース認証を可能にするために公開／個人（秘密）鍵ペアのそれぞれの個人鍵及び関連する公開鍵の証明書を具えている。
【００３９】
コンテンツアイテムＣ１に対する操作は、当該コンテンツアイテムＣ１に対する要求操作を実行するために必要な情報を含むコンテンツ権と第１ユーザを識別するとともに第１ユーザに該コンテンツ権の使用を許可するユーザ権があれば許可される。他のシステムでは、例えばシステム内のコンテンツに対するすべての操作が常に許可されている場合には、別個のコンテンツ権の使用を不要にすることができる。
【００４０】
ユーザに操作の実行を許可するユーザ権がない場合、又はユーザにコンテンツ権の使用を許可するユーザ権がない場合には、この操作は通常行われない。しかし、第１ユーザのユーザ権と第２ユーザのユーザ権をリンクする情報を受信する場合にはこの操作は依然として許可することができる。このような情報は任意のタイプのものとすることができ、例えば両ユーザを識別する証明書又はユーザ権がリンクされていることを示すＷｅｂサーバ上のリストとすることができる。この情報は一方（又は両方）のユーザ権自体に含めることもできる。以下に説明するように、この情報は１以上のドメイン証明書の形で付与するのが好ましい。
【００４１】
提示するソリュージョンは、ユーザ、コンテンツ所有者及び信頼できる第３者機関が各自固有の個人鍵／公開鍵ペアを維持し、各自の個人鍵で署名をすることにより証明書を発行することができる公開鍵基盤のアベイラビリティを保証する。可能性の一つはＳＰＫＩ／ＳＤＳＩ基盤で規定されている証明書を用いることである。
【００４２】
許可ドメインの概念を導入するために、発明者等は他のタイプの証明書をシステムに導入することを提案する。どの人／エンティティが特定ドメインに属するかを定義するドメイン証明書と呼ぶ証明書を（信頼できる）第３者機関により発行する。このような証明書は主体（個人）の識別子（例えば生体情報、公開鍵）と該主体がその一部であると宣言された許可ドメインの識別子（例えば名前、公開鍵）とを含む。証明書は発行する第３者機関の公開鍵で署名される。更に、証明書は適切な取消システムと連携する「発行日」及び「有効期限」のような通常フィールドを含む必要がある。このドメイン証明書の実現にはＳＰＫＩ「名前証明書」を用いることができる。
【００４３】
例えば、１つの家庭ドメインをそこに住むすべてのユーザに対し定義することができる。これは、自冶体（又はその代表者）がユーザの登録住所を宣言する証明書を発行することにより行うことができる。このような証明書は個人（ユーザ）とその家族との唯一の関係を生成する。
【００４４】
ドメイン証明書は種々の方法で実施することができる。一実施例では、各ユーザに、自分を特定の許可ドメインのメンバとして識別する個別のドメイン証明書を発行する。２つのドメイン証明書のそれぞれのＡＤ識別子の比較は２人のユーザが同一ドメインのメンバであるかどうかを立証する。この方法ではすべてのドメイン証明書を個別に管理することができ、各自のドメイン証明書は他の人が許可ドメインに加わったり離れたりすることに影響されない。
【００４５】
他の実施例では、１つの許可ドメインのメンバに対する証明書を単一のドメイン証明書に列記する。この方法では２人のユーザが１つの許可ドメインに属するかどうかの検査がはるかに容易になる。更に、この場合にはすべての人が自分のドメインの他の全メンバのＡＤ会員情報を自動的に有するので、個別の証明書を受信する必要がない。しかし、新しい人がＡＤに加わると、すべての人は新しいドメイン証明書の発行を受けなければならない。
【００４６】
コンテンツへのアクセス（利用）を同じ許可ドメイン内に住んでいる人に許可することは次のように行うことができる。許可ドメイン（家庭）ＡＤ内に住む個人Ｐ１がコンテンツ権ＣＲ１、例えばコンテンツアイテムＣ１の再生を行使するユーザ権を有する場合、第２の個人Ｐ２も、同じ家庭に属するならば、以下の証明書：
Ｐ１がＣＲ１を行使する権利を有することを示す、コンテンツ提供者により署名されたユーザ権ＵＲ１；
Ｐ１がＡＤのメンバであることを示す、自冶体により署名されたドメイン証明書ＤＣ１；及び
Ｐ２がＡＤのメンバであることを示す、自冶体により署名されたドメイン証明書ＤＣ２；
をコンプライアントデバイスＤ１に提示することにより、コンテンツ権ＣＲ１を行使することができる。
【００４７】
この状態を図３に示す。デバイスＤ１は証明書が真の許可された発行者により署名されたものであることを検査するために所定のルート公開鍵を知っているものとする。
【００４８】
オプションとして、コンテンツ提供者はドメイン内の他の人には所定の状況の下でのみコンテンツの再生を許すことができる。この場合には、このことをユーザ権にいくつかの余分のビットを用いて記述する必要がある。ドメイン内の使用に関するパーミッションの記述に加えて、他のフラグやビットをユーザ権証明書に付加することができる。例えば、第１世代コピー又はワンタイム再生に対するパーミッションに対応するビットを証明書に付加することができる。このようなビットはコンテンツ権ＣＲ１に付加することもでき、この場合にはコンテンツ権の行使にどのユーザ権が使用されるかと無関係になる。
【００４９】
本発明のシステムは所謂クロス許可ドメイン権も可能にする。これらはコンテンツを許可ドメインの境界を超えた利用を可能にする権利である。これは、コンプライアントデバイスが従わなければならない許可されたクロスドメイン動作を示す追加のフィールドをユーザ権に付加することにより達成することができる。ユーザ権の１つのフィールドに、例えば家庭許可ドメイン外のユーザにはユーザ権証明書を発行すべきでないことを意味する「ＸＡＤ＝ｎｏ」のようなステートメントを含ませることができる。この目的のためにはＳＰＫＩ許可証明書におけるデリゲーションタグを用いることができる。このようにすると、シリアルコピー管理が実現され、コピーを１世代までに制限することができる。「COPY-ONCE」制限を実現することも望ましい。
【００５０】
システムを管理しやすく一貫したものにするためには、いくつかのルート公開鍵をデバイスが知っている必要がある。これは、システムに存在する証明書（及び証明書チェーン）を検査するために必要である。デバイスが知っていなければならないシステム内の信頼できる第３者機関のルート／マスタ鍵のいくつかを以下に列挙する。
【００５１】
コンテンツ所有者又は代表者のルート鍵：ユーザ権を検査するために使用（ユーザ権管理）。
デバイスコンプライアンスマネージャのルート鍵：システムの他のデバイスが（依然として）コンプライアントであるか検査するために使用（デバイスコンプライアンス管理）。
命名権限局（例えば家庭ドメイン証明書を発行する機関）のルート鍵：許可家庭ドメイン内の家族関係を検査するために使用（ドメイン管理）。
ユーザ管理のルート鍵：個々のユーザの鍵ペア（スマートカード）が真正であるか及び改ざんされていないか検査するために使用（ユーザ管理）。
【００５２】
権利の所有権及び家族（又は他のドメイン）の構成は時間とともに変化する。その上、デバイスがハッキングされたり、秘密鍵が知られたりするかもしれない。従って、以下の場合にダイナミックな対応を考える必要がある。
ドメイン（家族メンバ）管理：家族の構成は変化し得る。
ユーザ権管理：ユーザ権は変化し得る。ユーザは権利を他の人に譲ることができる。
ユーザ管理：ＩＤデバイスがハッキングされたり、ユーザが亡くなることがある。
デバイスコンプライアンス管理：デバイスがハッキングされることがあり、その場合には取消／更新の必要がある。
【００５３】
家族の構成は証明書に表示し、即ち証明書に家族のメンバを記載する。システムは、家族のメンバを限定された有効期限とともに記載するドメイン証明書を用いることにより家族構成の変化に対処する。有効期限の経過後は、家族は信頼できる第３者機関に新しい証明書を申請する必要がある。例えば、地域行政機関がこのような信頼できる第３者機関として作用し、家族構成の変化を考慮することができる。
【００５４】
日付／時間をコンテンツ権又はユーザ権に含めることで容易に、確実に且つ安全に転送することができる点に注意されたい。このようにすると、デバイスはドメイン証明書を、その日付がユーザ権又はコンテンツ権の日付より後である場合にのみ受諾することができる。デバイスは今後の使用のために日付／時間を「現在」時間に対する下方境界として格納することもできる。また、ある種の通し番号機構をユーザ権及びコンテンツ権に用いてドメイン証明書の受諾に対して同様の効果を達成することもできる。
【００５５】
ユーザ権は新しいドメイン証明書を家族に配布するために用いることもできる。これも実に好適である。この場合には、家族メンバがユーザ権を取り使いたい場合、該メンバは新しいドメイン証明書を自動的に受け取る。この方法は使用証明書(ユーザ権証明書)配布者がドメイン証明書も配布することを意味する（これは別の機関で行うこともできること勿論である）。
【００５６】
家庭証明書に対する取消機構は、このような取消証明書は阻止することができ、それらの配布が保証されないので、あまり有用でない。取消メッセージはユーザ権（又はローカルコンテンツ権）と一緒に配布することができる。
【００５７】
ユーザ権は更に有効期限を用いて処理する。このような有効期限は無期限に設定することもできる。しかし、依然としてユーザ権の転送に対処する必要がある（即ち、移動命令）。最も困難な場合は無限の有効期限を有するユーザ権の場合である。いくつかの可能なソリュージョンは：
このオプションを付与しない。
サービス提供者を用いて転送を行い、新しいユーザ権を付与し、古いユーザ権を取り消す。
取消メッセージをユーザＩＤデバイス（もし使用可能であれば）に送り、これに格納させる。ユーザがコンテンツを利用したいとき、コンテンツの利用に使用するデバイスはユーザＩＤデバイス内の取消リストを閲覧する。
取消メッセージをドメイン証明書に入れ（証明書が極めて大きくなり、拡張可能なソリュージョンでない）、コンテンツの利用時に、ユーザ権証明書の提示に加えて、ドメイン証明書の提示も要求する。
ユーザ権をユーザＩＤデバイス（固有の個人鍵での署名）の助けで転送し、取消データをＩＤデバイスに付加し、取消データを他の家族メンバに送信する。有効期限付きのユーザ証明書を発行する（これはある時点で更新する必要がある）。
ユーザ権を使用する前に外部取消データベースの閲覧を要求する。
【００５８】
前述したように、個人は各自の生体データに基づいて、又は各自のＩＤデバイス（例えば無線スマートカード、携帯電話等）に基づいて本人確認をすることができる。生体データは各人に生まれながらのものであり、これらのデータは「自動」であるという。しかし、ＩＤデバイスはハッキング、複写、紛失等の惧れがある。このような「イベント」に対処するためにはＩＤデバイスの注意深い管理が要求される。
【００５９】
ＩＤデバイスは公開/個人鍵ペアを用いる公開鍵アルゴリズムで動作するものとする。ベストはＩＤデバイスが有効期限を有するものとする（又は所定の時点で、新コンテンツに対し新ＩＤデバイスが必要とされるものとする）。個人鍵が知られた場合には、最初にデバイスＩＤを取り消す必要がある。このような取消メッセージは新しいコンテンツ権又は新しいユーザ権に含めることができる。更に、その人は家族証明書から除去すべきである。これは、ハッカーに追加のハードルを与えて家族メンバが所有するコンテンツを利用し得なくする。
【００６０】
ＩＤデバイスの更新は、個人がコンテンツを購入するとき、即ちユーザ権証明書を得るときに自動的に行われる点に注意されたい。
【００６１】
デバイスコンプライアンス管理はコンテンツ権の配布に基づいて行うことができる。コンプライアントデバイスのみがコンテンツ権を得ることを許される。デバイス管理及び安全なコンテンツ権配布を行うために種々の技術、例えばセキュア認証チャネル（ＳＡＣ）及び証明書を用いる、又はＣＰＰＭ及びＣＰＲＭで使用されるＭＫＢ構造を用いることができる（http://www.4centity.com/参照）。
【００６２】
一つの特定のソリュージョンは２つのタイプのコンテンツ権：グローバル権（世界中で使用可能）及びパーソナル／ファミリ権（コンテンツを購入したユーザに局所的にとどまり、配布できない）を用いる。その理由は、これにより、サービス提供者により署名された権利にカウンティング機構の使用が可能になるためであり、これはユーザ権では不可能である。
【００６３】
スペシフィック／カウンティング権利の場合には、コンテンツ権はパーソナル／ファミリ権とする必要がある。ユーザ権は、グローバル又はパーソナル/ファミリコンテンツ権を使用しなければならないことを示す必要がある。もっとジェネリックにするために、特定の１つのコンテンツに対し種々のコンテンツ権を許可する。ユーザ権はどの特定のコンテンツ権を使用すべきか示す。
【００６４】
コンテンツ権は、ユーザ権に対する取り消しデータ及びパーソナルＩＤデバイス又はコンテンツの再生前に所定の取り消しデータベースへコンタクトする命令を含むことができる。時間ベースの権利は時間情報を得るためにハートビート機構を用いることにより実現することができる（例えば国際特許出願ＷＯ03/058948（出願人整理番号PHNL020010）参照）。
【００６５】
コンテンツ権は、コンプライアントであり且つ該当するユーザ権を持つユーザにより操作されるデバイスにのみ転送されることが重要な前提である。この前提は常に正しいとはかぎらない。その理由は、実世界では（コンテンツの解読に必要な）秘密鍵を漏洩不能に保つことはできないためである。このようなことが起こると、ハッカーは同じコンテンツに対して新しいコンテンツ権をもとのコンテンツ権よりも少数の制限で生成することができる。一般に、コンテンツ提供者は、誰でも任意のコンテンツをシステムに入力可能にするコンテンツ権を生成できることは望んでいない。
【００６６】
上述した問題の最良の解決方法は、コンテンツ提供者がコンテンツ権にディジタル署名をすることである。更に、（コンプライアント）デバイスはコンテンツ権の署名を検査してコンテンツ提供者により署名されたコンテンツ権のみを受け取るようにしなければならない。従って、デバイスはコンテンツ提供者の（ルート）公開鍵を知っていなければならない。コンテンツ権に署名をすることは必須要件ではないこと勿論である。
【００６７】
この方法の追加の利点は、コンプライアントデバイスが知っていなければならない（ルート）公開鍵が少なくなることである。コンプライアントデバイスは、特にユーザ権の発行者、デバイスコンプライアンスマネージャ及び命名権者の（ルート）公開鍵を知らなければならない。これらの値はデバイスに何らかの方法で格納する必要がある。しかし、コンテンツ権がコンテンツ提供者に署名される場合には、これらの公開鍵はコンテンツ権に付加するだけとすることができる。デバイスはコンテンツ提供者の（ルート）公開鍵を知っているだけでよい。このようにすると、コンテンツ提供者がユーザ権、コンプライアンス証明書及びネーム証明書の発行を誰に許可するかを決めることができる。
【００６８】
更に、証明書取消情報をどこで検査すべきかに関する情報をコンテンツ権に付加することができる。ハッカーはコンテンツ権内のこの付加情報を変更することはできない。その理由は、正当なコンテンツ権はコンテンツ提供者によりディジタル署名されなければならないためである。
【００６９】
公式コンテンツ提供者（ＣＰと表記する）の個人鍵で署名されたコンテンツ権のみでＣＰから到来するコンテンツをシステムに安全に導入することができる。しかし、ユーザがパーソナルコンテンツ（休日の個人写真又はホームビデオ記録など）をシステムに導入したい場合、ユーザは所要のコンテンツ権を生成するために最初にＣＰを巻き込む必要がある。これは、ＣＰはパーソナルコンテンツを制御する権限を持たないために望ましくない。このため、パーソナルコンテンツをシステムに導入するための最初のステップはコンテンツ権にＣＰ以外の誰かが署名することを許可することにある。
【００７０】
導入する第1の規則は、ＣＰにより発行されないコンテンツ権はコンプライアントデバイスで署名されなければならないことである。そうでない場合には、コンテンツ権はこれらの権利を使用したい如何なる（コンプライアント）デバイスも拒絶しなければならない。このことは、パーソナルコンテンツはコンプライアントデバイスを介してシステムに入力できるのみであることを意味する。このようなコンプライアントデバイスは更にコンテンツに電子透かしがないことを検査する必要がある。電子透かし付きのコンテンツはもともとＣＰ出身であるため、ユーザは自己のコンテンツ権をこのようなコンテンツに対して生成する必要はない。
【００７１】
以上提示したソリュージョンは典型的なアタックを許すのでまだ完全に安全でない。ユーザが所定の自作のコンテンツに対するコンテンツ権を生成したものとする。このとき、悪意のユーザはこのコンテンツを、コンテンツ権が生成された後（従ってコンプライアントデバイスがそれに署名した後）に、別のコンテンツと置き換えることができる。すなわち、悪意のユーザは（不正）コンテンツを承認されたコンテンツ権内のコンテンツ鍵で（再）暗号化するとともに、このコンテンツに、当該コンテンツ権が生成された自作コンテンツと同一の識別子を与えることができる。それゆえ、同一の（漏洩した）コンテンツ鍵で暗号化すれば多数の不正コンテンツをシステムに入力することができる。
【００７２】
この問題を解決するためには、コンテンツ権と実際のコンテンツとの間にセキュアなリンクが必要である。コンテンツのフィンガープリントの利用はこのリンクを提供することができる。コンテンツアイテムのフィンガープリントは、コンテンツアイテムをわずかに変更するときでも変化しない当情報信号の表現である。このようなフィンガープリントは「ロバストハッシュ」として既知である。ロバストハッシュとは、例えば圧縮／解除、符号化、ＡＤ／ＤＡ変換などによるデータ処理及びデグラデーションに対してロバストなハッシュ関数をいう。ロバストハッシュはロバスト要約、ロバスト署名又は知覚ハッシュとも呼ばれる。フィンガープリント生成方法の一例は国際特許出願ＷＯ02/065782（出願人整理番号PHNL010110）に開示されている。
【００７３】
コンテンツ権はフィンガープリントがコンテンツのどの部分から正確に見つけだせるかを記述する追加の情報を含む必要がある。そして、コンテンツ全体のフィンガープリント情報（多量のデータ）を付加する代わりに、所定の時間ポイントにおけるフィンガープリント情報をその時間値と一緒に付加することができる。コンプライアントデバイスは署名前にこのフィンガープリント情報をコンテンツ権に付加する。コンテンツ権を（コンテンツの再生のために）使用するとき、コンプライアントデバイスはこのコンテンツ権に含まれるフィンガープリントデータが実際のコンテンツ（時間ポイントで指示された部分）に見つかるか検査する必要がある。見つからなければ、コンテンツ権を拒否しなければならない。
【００７４】
要するに、この実施例は次の通りである。
「公式」コンテンツ提供者ＣＰからのコンテンツは電子透かし処理され、コンテンツ権は該コンテンツ権がリンクするコンテンツについてのフィンガープリント情報を含まなければならない。
パーソナルコンテンツに対するコンテンツ権を生成するとき、コンプライアントデバイス（又はコンテンツ／サービス提供者）は電子透かしが存在しないことを検査しなければならない。
コンプライアントデバイスはフィンガープリント情報を、それに署名する前に、（パーソナルコンテンツに対する）新しいコンテンツ権に付加しなければならない。
該コンテンツ権を使いたいコンプライアントデバイスは該コンテンツ権内のフィンガープリント情報が実際のコンテンツと一致するか検査しなければならない。
【００７５】
原システムと同様に、コンテンツ権の生成者は、コンテンツを利用するためにはユーザ権発行者、命名権者及びデバイスコンプライアンスマネージャの（ルート）公開鍵のどれを検査しなければならないか決定する。ユーザは任意のパーティ（自分又は自分のデバイスを含む）に自分のパーソナルコンテンツに対する添付ユーザ権の発行を許可することができる。
【００７６】
デバイスにコンテンツのフィンガープリント情報を入力するアイディアは国際特許出願ＰＣＴ/ＩＢ03/００８０３（出願人整理番号PHNL020246）のアイディアに近似する。しかし、本発明のソリュージョンはもっと具体的で、コンテンツ提供者からの公式コンテンツ（電子透かし処理されている）とパーソナルコンテンツとを明確に区別している。
【００７７】
コンテンツが電子透かし処理されている場合には、コンプライアントデバイスは、そのコンテンツが公式コンテンツ提供者により署名された適正なコンテンツ権を有する場合にのみそのコンテンツをプレイすることができる。電子透かしが検出されない場合には、コンテンツは「パーソナルコンテンツ」と分類され、添付コンテンツ権は任意のコンプライアントデバイスで署名される。
【００７８】
他のオプショナルな拡張として、「コンテンツ権」をドメインレベルで「パーソナル化またはドメイン化」することができる。これは、一般に、コンプライアントデバイスを許可ドメインがコンテンツ権内に識別されない場合に操作の実行を拒否するように構成することにより行うことができる。このようにすると、コンテンツ権が「誤った」ドメインを識別する（又はドメインを全く識別しない）場合には、許可ドメインの人でもこの権利を行使できない。しかし、このアプローチは、膨大な量（数千万）のフューチャコンプライアントデバイスを危険にさらすおそれがある。即ち、１つのデバイスがハッキングされたら（十分高速に取り消しされないと）、これが全システム内のすべてのコンテンツ権に漏洩するおそれがある。
【００７９】
このパーソナル化及びドメイン化は、許可ドメイン内のデバイスが使用可能である復号鍵に対応する暗号鍵を用いてコンテンツ権を暗号化することにより行うのが好ましい。復号鍵は典型的にはＩＤデバイスから入手することができる。コンテンツ提供者はコンテンツ権を追加の鍵ＣＲＥＫ（Content Right Encryption Key：コンテンツ権暗号鍵）で次のように暗号化する。
Ｅ{ＣＲＥＫ}[コンテンツ権]
【００８０】
次に、この鍵をすべてのドメインメンバが使用可能なＩＤカード内の公開ドメイン鍵（ＰＤＫ）で暗号化する（コンテンツ提供者はこの公開ドメイン鍵を売買トランザクション中にＩＤカードから得ているためにこの鍵を使用することができる）。暗号化されたＣＲＥＫはコンテンツ権と連結し：
Ｅ{ＰＤＫ} {ＣＲＥＫ}||Ｅ{ＣＲＥＫ}[コンテンツ権]
を生成し、次にこれを(必要なら)コンテンツと一緒にユーザに送る。
【００８１】
すべてのユーザＩＤデバイス(例えばスマートカード)が個人(秘密)ドメイン鍵を有するものとすれば、ユーザ認証後に、再生のためのプロトコルは次のオペレーションとすることができる。
【００８２】
再生デバイスはユーザＩＤデバイスに、
Ｅ{ＰＤＫ} {ＣＲＥＫ}||ＰＫ_再生_デバイス
を送る。
ユーザＩＤデバイスは秘密鍵ＳＤＫでの復号によりＣＲＥＫを取り出し、次いでＣＲＥＫを再生デバイスの公開鍵（ＰＫ_再生_デバイス）で暗号化する。
次いでユーザＩＤデバイスは再生デバイスに、
Ｅ{ＰＫ_再生_デバイス}[ＣＲＥＫ]
を送る。
再生デバイスは今やＣＲＥＫを取り出すことができ、次いでコンテンツ権を復号し、コンテンツを復号することができる。
【００８３】
要するに、種々のデータ要素及びそれらの機能は以下の２つの表にリストアップされている。これらの表は単なる例示であって本発明を限定するものではない。
【００８４】
【表１】
【００８５】
【表２】
【００８６】
本発明を実施する最良の方法の一実施例を以下に検討する。このシステムの実施例はＳＰＫＩ/ＳＤＳＩフレームワークを使用する。SPKI Certificate Theory (Internet RFC2693)及びCarl Ellison, “Improvements on Conventional PKI wisdom”, Ist annual PKI Research Workshop, April 2002参照。Ｘ．５０９フレームワーク内の実施も可能であるとみなせる。すべてのエンティティが固有の公開/個人鍵ペアを維持するものと仮定する。公開鍵及び個人鍵はそれぞれ記号ＰＫ及びＳＫで示す。
【００８７】
ＳＰＫＩネーム証明書は４-タプル（Ｋ，Ａ，Ｓ，Ｖ）として表され、
Ｋ＝発行者の公開鍵
Ａ＝決定されたローカルネーム
Ｓ＝証明書の主体
Ｖ＝正当性仕様
である。
【００８８】
ＳＰＫＩ許可証明書は５-タプル（Ｋ，Ｓ，Ｄ，Ｔ，Ｖ）として表され、
Ｋ＝発行者の公開鍵
Ｓ＝証明書の主体
Ｄ＝デリゲーションビット
Ｔ＝与えられたパーミッションを指定するタグ
Ｖ＝正当性仕様
である。
【００８９】
デリゲーションビットが「真」に設定されている場合、主体は更に（タグ内に指定されている）パーミッションを他の鍵及びネームに委任することができる。
【００９０】
許可ドメインは、個人の公開鍵を公式ユニーク識別子（例えばネーム及びアドレス情報）に結合するＳＰＫＩネーム証明書を中央権限局に発行させることにより形成することができる。「アドレス権限局」ＡＡが個人「ＰＩ」へのアクセスを付与するこのような証明書の一例（ＳＰＫＩフォーム）はＳＫ_ＡＡ（即ちアドレス権限局の個人鍵）により署名された４-タプルを意味するＣｅｒｔ１＝ＳＫ_ＡＡ{(Ｋ，Ａ，Ｓ，Ｖ)}であり、ここで
Ｋ＝ＰＫ_ＡＡ
Ａ＝住所番号
Ｓ＝ＰＫ_Ｐ１
簡単のために正当性仕様はここでは省略した。この仕様は取消及び更新システムに従って選択する必要がある。
【００９１】
他のソリュージョンは許可ドメイン内のすべての人のＰＫを単一のドメイン証明書内にグループ化するものである。これは、一つのドメイン証明書を必要とするのみであるという追加の利点を有する。このような証明書の一例は、ＳＫ_ＡＡ（即ちアドレス権限局の個人鍵）により署名された４-タプルを意味するＣｅｒｔ1b＝ＳＫ_ＡＡ{(Ｋ，Ａ，Ｓ，Ｖ)}であり、ここで
Ｋ＝ＰＫ_ＡＡ
Ａ=家庭証明書
Ｓ＝ＰＫ_Ｐ１，ＰＫ_Ｐ２，ＰＫ_Ｐ３，．．．
【００９２】
さて、所定のコンテンツを再生するのに必要とされる規則及び鍵を保持するコンテンツ権ＣＲ１があるものとする。コンテンツ所有者ＣＯ１は次の証明書：Ｃｅｒｔ２＝ＳＫ_ＣＯ１{(Ｋ，Ｓ，Ｄ，Ｔ，Ｖ)}を発行することにより個人Ｐ１を許可することができ、ここで
Ｋ＝ＰＫ_ＣＯ１
Ｓ＝ＰＫ_Ｐ１
Ｄ＝偽
Ｔ＝ＣＲ１
【００９３】
証明書Ｃｅｒｔ２では、デリゲーションビットは「偽」に設定される。これは、ユーザは（コンテンツ権ＣＲ１の）ユーザ権を他のユーザに委任できないことを示す。デリゲーションビットが「真」に設定されている場合、個人Ｐ１はパーミッションを委任することができる。トータルシステムは、コンプライアントデバイスが同一（許可された）ドメイン内の他のユーザがＣＲ１を使用しそのコンテンツアイテムを再生することを依然として許すように設計することができる。この場合にはデリゲーションビットは権利が許可ドメインの外部に広がるのを阻止する。
【００９４】
ユーザはデバイスを介してコンテンツにアクセスする。ユーザが適正な一組の証明書を所有する場合にコンプライアントデバイスのみがアクセス（コンテンツ権内の鍵でのコンテンツの復号）を提供する。許可されたユーザがない場合にはたぶんデバイスはコンテンツ権を得ることができない点に注意されたい。
【００９５】
ユーザに属する証明書はネットワーク上の任意のロケーションから取り出し、ユーザのスマートカードに格納することができる。コンテンツ権はスマートカードに格納することもできる。これはコンテンツをオフラインデバイスで再生するために必要とされる。コンテンツ権をネットワークを介してアクセスし得るユーザの信頼できるプロキシに格納できるようにするのが有用であるかもしれない。このようにすると、ユーザは自分のスマートカードに格納されておらずネットワーク上の他の場所から入手し得ないコンテンツ権を取り出すことが依然としてできる。
【００９６】
以下のリストはソリュージョンを実行するときに必要とされる(又は有用な)証明書内のいくつかのフィールドを示す。このリストは前述した標準ＳＰＫＩ証明書フィールド以外のフィールドのみを示す。
署名日；
署名された証明書上のデバイス識別子（デバイスコンプライアンスサブシステム内で取消になり得るデバイスのレピュテーション情報の収集を促進する）
コピーワンス／コピーネバー／コピーノーモア及び類似フラグ；
リケーション／取消システムのサーバ；
【００９７】
上述の実施例は説明のためのものであって本発明を制限するものでなく、当業者は添付の特許請求の範囲から逸脱することなく多くの他の実施例を設計することができる。
【００９８】
本発明はいくつかの個別の素子を具えるハードウエアで実現することができるとともに、適切にプログラムされたコンピュータで実現することもできる。
【００９９】
いくつかの手段を列挙したデバイス請求項では、これらの手段のいくつかはハードウエアの１つの同一のアイテムで具体化することができる。所定の手段が互いに異なる従属請求項に列挙されている単なる事実は、これらの手段の組み合わせが有利に使用できないことを示しているのではない。
【０１００】
要するに、本発明はコンテンツアイテム（Ｃ１）について第１ユーザ（Ｐ２）により要求された操作をユーザ権（ＵＲ１）に従って許可する方法及びデバイス（Ｄ１）を提供するものである。ユーザ権は第１ユーザ又は第２ユーザ（Ｐ１）を識別し、該コンテンツアイテムについて要求された操作の実行を当該ユーザに許可することができる。ユーザ権が第２ユーザを識別する場合には、前記操作は第１ユーザのユーザ権と第２ユーザのユーザ権をリンクする情報の受取り時に許可される。この情報は第１及び第２ユーザを同一の許可ドメイン（ＡＤ）のメンバとして識別する１以上のドメイン証明書（ＤＣ１，ＤＣ２）を含むものとするのが好ましい。操作の権利を付与するコンテンツ権（ＣＲ１）を使用し、ユーザ権はこのコンテンツ権の使用を第２ユーザに許可するものとするのが好ましい。
【図面の簡単な説明】
【０１０１】
【図１】個人、権利及びコンテンツに基づく許可ドメインのモデルを示す。
【図２】コンテンツアイテムに操作を実行したいスマートカードを携帯するユーザにより操作されるデバイスの一例を示す。
【図３】１個人が同じドメインに属する他の個人のユーザ権を用いてどのようにコンテンツ権を行使するかを示す。
【特許請求の範囲】
【請求項１】
コンテンツアイテムに第１ユーザにより要求された操作を、第２ユーザを識別するとともに前記第２ユーザに前記コンテンツアイテムに要求された操作の実行を許可するユーザ権証明書に基づいて許可する方法であって、前記操作の許可は前記第１ユーザ前記第２ユーザのユーザ権証明書をリンクする情報の受信時に行うことを特徴とするコンテンツ操作の許可方法。
【請求項２】
前記情報は、前記第１及び第２ユーザを同じ許可ドメインのメンバとして識別する１以上のドメイン証明書を含むことを特徴とする請求項１記載の方法。
【請求項３】
前記１以上のドメイン証明書は、前記第１ユーザを１つの許可ドメインのメンバとして識別する第１ドメイン証明書と、前記第２ユーザを前記１つの許可ドメインのメンバとして識別する第２ドメイン証明書とを含むことを特徴とする請求項２記載の方法。
【請求項４】
前記１以上のドメイン証明書は、前記第１及び第２ユーザを前記許可ドメインのメンバとして識別する単一の証明書を含むことを特徴とする請求項２記載の方法。
【請求項５】
前記操作は、コンテンツアイテムのレンダリング、コンテンツアイテムの記録、コンテンツアイテムの転送及びコンテンツアイテムのコピー生成のうちの少なくとも１つを含むことを特徴とする請求項１記載の方法。
【請求項６】
前記コンテンツアイテムに要求された前記操作を実行するために必要な情報を含むコンテンツ権を受信し、前記第２ユーザのユーザ権証明書は、前記第２ユーザに前記コンテンツ権の使用を許可するものであることを特徴とする請求項１又は２記載の方法。
【請求項７】
前記操作は、前記コンテンツ権が前記許可ドメインを識別しない場合には許可されないことを特徴とする請求項２に従属する請求項６記載の方法。
【請求項８】
コンテンツアイテムに第１ユーザにより要求された操作を、第２ユーザを識別するとともに前記第２ユーザに前記コンテンツアイテムに要求された操作の実行を許可するユーザ権証明書に基づいて実行するよう構成された装置であって、前記操作は前記第１ユーザと前記第２ユーザのユーザ権証明書をリンクする情報の受信時に許可するよう構成されていることを特徴とするデバイス。
【請求項９】
前記情報は、前記第１及び第２ユーザを同じ許可ドメインのメンバとして識別する１以上のドメイン証明書を含むことを特徴とする請求項８記載のデバイス。
【請求項１０】
前記１以上のドメイン証明書は、前記第１ユーザを１つの許可ドメインのメンバとして識別する第１ドメイン証明書と、前記第２ユーザを前記１つの許可ドメインのメンバとして識別する第２ドメイン証明書とを含むことを特徴とする請求項９記載の方法。
【請求項１１】
前記１以上のドメイン証明書は、前記第１及び第２ユーザを前記許可ドメインのメンバとして識別する単一の証明書を含むことを特徴とする請求項９記載の方法。
【請求項１２】
識別デバイスから前記第１ユーザの識別子を受信し、受信した識別子が前記１以上のドメイン証明書内の第１ユーザの識別情報と一致する場合に前記操作を実行するよう構成されていることを特徴とする請求項８記載のデバイス。
【請求項１３】
前記コンテンツアイテムに要求された前記操作を実行するために必要な情報を含むコンテンツ権を受信するよう構成され、前記第２ユーザのユーザ権証明書は、前記第２ユーザに前記コンテンツ権の使用を許可するものであることを特徴とする請求項８又は９記載のデバイス。
【請求項１４】
対応する復号鍵が当該デバイスに使用可能である暗号鍵を用いてコンテンツ権の少なくとも一部分を暗号化することを特徴とする請求項１１記載のデバイス。
【請求項１５】
前記コンテンツ権には該コンテンツ権の信頼性の検証を可能にするディジタル署名が付与されることを特徴とする請求項１３記載のデバイス。
【請求項１６】
前記ディジタル署名が許可されたコンテンツ提供者と関連するディジタル証明書を用いて正しく検証できた場合に前記操作を実行するよう構成されていることを特徴とする請求項１５記載のデバイス。
【請求項１７】
前記ディジタル署名が特定のデバイスと関連するディジタル証明書を用いて正しく検証できた場合に前記操作を実行するよう構成されていることを特徴とする請求項１５記載のデバイス。
【請求項１８】
前記ディジタル署名が許可されたコンテンツ提供者と関連するディジタル証明書を用いて正しく検証できないとともに前記許可されたコンテンツ提供者と関連するディジタル透かしが前記コンテンツアイテムに存在しない場合に前記操作の実行を拒否するよう構成されていることを特徴とする請求項１５記載のデバイス。
【請求項１９】
前記コンテンツ権から公開鍵を抽出し、抽出した公開鍵を用いて前記操作が許可されているか決定するよう構成されていることを特徴とする請求項１３〜１５の何れかに記載のデバイス。
【請求項２０】
前記コンテンツアイテムのロバストなフィンガープリントを決定し、決定したロバストなフィンガープリントが前記コンテンツ権に含まれるロバストなフィンガープリントと一致しない場合に前記操作の実行を拒否するよう構成されていることを特徴とする請求項１３記載のデバイス。
【請求項２１】
前記許可されたドメインが前記コンテンツ権により識別されない場合に前記操作の実行を拒否するよう構成されていることを特徴とする請求項１３〜１５の何れかに記載のデバイス。
【請求項２２】
コンテンツアイテムに第１ユーザにより要求された操作を、前記コンテンツアイテムに要求された前記操作を実行するために必要な情報を含むコンテンツ権と、前記第１ユーザを識別するとともに前記コンテンツ権の使用を前記第１ユーザに許可するユーザ権証明書とに基づいて許可するコンテンツ操作許可方法。
【請求項２３】
コンテンツアイテムに第１ユーザにより要求された操作を、前記コンテンツアイテムに要求された前記操作を実行するために必要な情報を含むコンテンツ権と、前記第１ユーザを識別するとともに前記第１ユーザに前記コンテンツ権の使用を許可するユーザ権証明書とに基づいて実行するよう構成されたデバイス。
【請求項２４】
対応する復号鍵が当該デバイスに使用可能である暗号鍵を用いてコンテンツ権の少なくとも一部分を暗号化することを特徴とする請求項２３記載のデバイス。
【請求項２５】
前記コンテンツ権には該コンテンツ権の信頼性の検証を可能にするディジタル署名が付与されることを特徴とする請求項２３記載のデバイス。
【請求項２６】
前記ディジタル署名が許可されたコンテンツ提供者と関連するディジタル証明書を用いて正しく検証できた場合に前記操作を実行するよう構成されていることを特徴とする請求項２５記載のデバイス。
【請求項２７】
前記ディジタル署名が特定のデバイスと関連するディジタル証明書を用いて正しく検証できた場合に前記操作を実行するよう構成されていることを特徴とする請求項２５記載のデバイス。
【請求項２８】
前記ディジタル署名が許可されたコンテンツ提供者と関連するディジタル証明書を用いて正しく検証できないとともに前記許可されたコンテンツ提供者と関連するディジタル透かしが前記コンテンツアイテムに存在しない場合に前記操作の実行を拒否するよう構成されていることを特徴とする請求項２５記載のデバイス。
【請求項２９】
前記コンテンツアイテムのロバストなフィンガープリントを決定し、決定したロバストなフィンガープリントが前記コンテンツ権に含まれるロバストなフィンガープリントと一致しない場合に前記操作の実行を拒否するよう構成されていることを特徴とする請求項２３記載のデバイス。
【請求項３０】
識別デバイスから前記第１ユーザの識別子を受信し、受信した識別子が前記第１ユーザのユーザ権内の第１ユーザの識別情報と一致する場合に前記操作を実行するよう構成されていることを特徴とする請求項２３記載のデバイス。
【請求項３１】
プロセッサに請求項１に記載の方法を実行させるようにプログラムされたコンピュータプログラムプロダクト。
【請求項３２】
プロセッサに請求項２２に記載の方法を実行させるようにプログラムされたコンピュータプログラムプロダクト。
【請求項１】
コンテンツアイテムに第１ユーザにより要求された操作を、第２ユーザを識別するとともに前記第２ユーザに前記コンテンツアイテムに要求された操作の実行を許可するユーザ権証明書に基づいて許可する方法であって、前記操作の許可は前記第１ユーザ前記第２ユーザのユーザ権証明書をリンクする情報の受信時に行うことを特徴とするコンテンツ操作の許可方法。
【請求項２】
前記情報は、前記第１及び第２ユーザを同じ許可ドメインのメンバとして識別する１以上のドメイン証明書を含むことを特徴とする請求項１記載の方法。
【請求項３】
前記１以上のドメイン証明書は、前記第１ユーザを１つの許可ドメインのメンバとして識別する第１ドメイン証明書と、前記第２ユーザを前記１つの許可ドメインのメンバとして識別する第２ドメイン証明書とを含むことを特徴とする請求項２記載の方法。
【請求項４】
前記１以上のドメイン証明書は、前記第１及び第２ユーザを前記許可ドメインのメンバとして識別する単一の証明書を含むことを特徴とする請求項２記載の方法。
【請求項５】
前記操作は、コンテンツアイテムのレンダリング、コンテンツアイテムの記録、コンテンツアイテムの転送及びコンテンツアイテムのコピー生成のうちの少なくとも１つを含むことを特徴とする請求項１記載の方法。
【請求項６】
前記コンテンツアイテムに要求された前記操作を実行するために必要な情報を含むコンテンツ権を受信し、前記第２ユーザのユーザ権証明書は、前記第２ユーザに前記コンテンツ権の使用を許可するものであることを特徴とする請求項１又は２記載の方法。
【請求項７】
前記操作は、前記コンテンツ権が前記許可ドメインを識別しない場合には許可されないことを特徴とする請求項２に従属する請求項６記載の方法。
【請求項８】
コンテンツアイテムに第１ユーザにより要求された操作を、第２ユーザを識別するとともに前記第２ユーザに前記コンテンツアイテムに要求された操作の実行を許可するユーザ権証明書に基づいて実行するよう構成された装置であって、前記操作は前記第１ユーザと前記第２ユーザのユーザ権証明書をリンクする情報の受信時に許可するよう構成されていることを特徴とするデバイス。
【請求項９】
前記情報は、前記第１及び第２ユーザを同じ許可ドメインのメンバとして識別する１以上のドメイン証明書を含むことを特徴とする請求項８記載のデバイス。
【請求項１０】
前記１以上のドメイン証明書は、前記第１ユーザを１つの許可ドメインのメンバとして識別する第１ドメイン証明書と、前記第２ユーザを前記１つの許可ドメインのメンバとして識別する第２ドメイン証明書とを含むことを特徴とする請求項９記載の方法。
【請求項１１】
前記１以上のドメイン証明書は、前記第１及び第２ユーザを前記許可ドメインのメンバとして識別する単一の証明書を含むことを特徴とする請求項９記載の方法。
【請求項１２】
識別デバイスから前記第１ユーザの識別子を受信し、受信した識別子が前記１以上のドメイン証明書内の第１ユーザの識別情報と一致する場合に前記操作を実行するよう構成されていることを特徴とする請求項８記載のデバイス。
【請求項１３】
前記コンテンツアイテムに要求された前記操作を実行するために必要な情報を含むコンテンツ権を受信するよう構成され、前記第２ユーザのユーザ権証明書は、前記第２ユーザに前記コンテンツ権の使用を許可するものであることを特徴とする請求項８又は９記載のデバイス。
【請求項１４】
対応する復号鍵が当該デバイスに使用可能である暗号鍵を用いてコンテンツ権の少なくとも一部分を暗号化することを特徴とする請求項１１記載のデバイス。
【請求項１５】
前記コンテンツ権には該コンテンツ権の信頼性の検証を可能にするディジタル署名が付与されることを特徴とする請求項１３記載のデバイス。
【請求項１６】
前記ディジタル署名が許可されたコンテンツ提供者と関連するディジタル証明書を用いて正しく検証できた場合に前記操作を実行するよう構成されていることを特徴とする請求項１５記載のデバイス。
【請求項１７】
前記ディジタル署名が特定のデバイスと関連するディジタル証明書を用いて正しく検証できた場合に前記操作を実行するよう構成されていることを特徴とする請求項１５記載のデバイス。
【請求項１８】
前記ディジタル署名が許可されたコンテンツ提供者と関連するディジタル証明書を用いて正しく検証できないとともに前記許可されたコンテンツ提供者と関連するディジタル透かしが前記コンテンツアイテムに存在しない場合に前記操作の実行を拒否するよう構成されていることを特徴とする請求項１５記載のデバイス。
【請求項１９】
前記コンテンツ権から公開鍵を抽出し、抽出した公開鍵を用いて前記操作が許可されているか決定するよう構成されていることを特徴とする請求項１３〜１５の何れかに記載のデバイス。
【請求項２０】
前記コンテンツアイテムのロバストなフィンガープリントを決定し、決定したロバストなフィンガープリントが前記コンテンツ権に含まれるロバストなフィンガープリントと一致しない場合に前記操作の実行を拒否するよう構成されていることを特徴とする請求項１３記載のデバイス。
【請求項２１】
前記許可されたドメインが前記コンテンツ権により識別されない場合に前記操作の実行を拒否するよう構成されていることを特徴とする請求項１３〜１５の何れかに記載のデバイス。
【請求項２２】
コンテンツアイテムに第１ユーザにより要求された操作を、前記コンテンツアイテムに要求された前記操作を実行するために必要な情報を含むコンテンツ権と、前記第１ユーザを識別するとともに前記コンテンツ権の使用を前記第１ユーザに許可するユーザ権証明書とに基づいて許可するコンテンツ操作許可方法。
【請求項２３】
コンテンツアイテムに第１ユーザにより要求された操作を、前記コンテンツアイテムに要求された前記操作を実行するために必要な情報を含むコンテンツ権と、前記第１ユーザを識別するとともに前記第１ユーザに前記コンテンツ権の使用を許可するユーザ権証明書とに基づいて実行するよう構成されたデバイス。
【請求項２４】
対応する復号鍵が当該デバイスに使用可能である暗号鍵を用いてコンテンツ権の少なくとも一部分を暗号化することを特徴とする請求項２３記載のデバイス。
【請求項２５】
前記コンテンツ権には該コンテンツ権の信頼性の検証を可能にするディジタル署名が付与されることを特徴とする請求項２３記載のデバイス。
【請求項２６】
前記ディジタル署名が許可されたコンテンツ提供者と関連するディジタル証明書を用いて正しく検証できた場合に前記操作を実行するよう構成されていることを特徴とする請求項２５記載のデバイス。
【請求項２７】
前記ディジタル署名が特定のデバイスと関連するディジタル証明書を用いて正しく検証できた場合に前記操作を実行するよう構成されていることを特徴とする請求項２５記載のデバイス。
【請求項２８】
前記ディジタル署名が許可されたコンテンツ提供者と関連するディジタル証明書を用いて正しく検証できないとともに前記許可されたコンテンツ提供者と関連するディジタル透かしが前記コンテンツアイテムに存在しない場合に前記操作の実行を拒否するよう構成されていることを特徴とする請求項２５記載のデバイス。
【請求項２９】
前記コンテンツアイテムのロバストなフィンガープリントを決定し、決定したロバストなフィンガープリントが前記コンテンツ権に含まれるロバストなフィンガープリントと一致しない場合に前記操作の実行を拒否するよう構成されていることを特徴とする請求項２３記載のデバイス。
【請求項３０】
識別デバイスから前記第１ユーザの識別子を受信し、受信した識別子が前記第１ユーザのユーザ権内の第１ユーザの識別情報と一致する場合に前記操作を実行するよう構成されていることを特徴とする請求項２３記載のデバイス。
【請求項３１】
プロセッサに請求項１に記載の方法を実行させるようにプログラムされたコンピュータプログラムプロダクト。
【請求項３２】
プロセッサに請求項２２に記載の方法を実行させるようにプログラムされたコンピュータプログラムプロダクト。
【図１】
【図２】
【図３】
【図２】
【図３】
【公表番号】特表２００６−５０４１７６（Ｐ２００６−５０４１７６Ａ）
【公表日】平成１８年２月２日（２００６．２．２）
【国際特許分類】
【出願番号】特願２００４−５４６２６０（Ｐ２００４−５４６２６０）
【出願日】平成１５年１０月１５日（２００３．１０．１５）
【国際出願番号】ＰＣＴ／ＩＢ２００３／００４５３８
【国際公開番号】ＷＯ２００４／０３８５６８
【国際公開日】平成１６年５月６日（２００４．５．６）
【出願人】（５９００００２４８）コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ (12,071)
【氏名又は名称原語表記】Ｋｏｎｉｎｋｌｉｊｋｅ Ｐｈｉｌｉｐｓ Ｅｌｅｃｔｒｏｎｉｃｓ Ｎ．Ｖ．
【住所又は居所原語表記】Ｇｒｏｅｎｅｗｏｕｄｓｅｗｅｇ １，５６２１ ＢＡ Ｅｉｎｄｈｏｖｅｎ， Ｔｈｅ Ｎｅｔｈｅｒｌａｎｄｓ
【Ｆターム（参考）】
【公表日】平成１８年２月２日（２００６．２．２）
【国際特許分類】
【出願日】平成１５年１０月１５日（２００３．１０．１５）
【国際出願番号】ＰＣＴ／ＩＢ２００３／００４５３８
【国際公開番号】ＷＯ２００４／０３８５６８
【国際公開日】平成１６年５月６日（２００４．５．６）
【出願人】（５９００００２４８）コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ (12,071)
【氏名又は名称原語表記】Ｋｏｎｉｎｋｌｉｊｋｅ Ｐｈｉｌｉｐｓ Ｅｌｅｃｔｒｏｎｉｃｓ Ｎ．Ｖ．
【住所又は居所原語表記】Ｇｒｏｅｎｅｗｏｕｄｓｅｗｅｇ １，５６２１ ＢＡ Ｅｉｎｄｈｏｖｅｎ， Ｔｈｅ Ｎｅｔｈｅｒｌａｎｄｓ
【Ｆターム（参考）】
[ Back to top ]