(57)【要約】【課題】鍵管理ブロック（ＫＭＢ）が従来技術で論理鍵階層（ＬＫＨ）と称する形態である時に、ＫＭＢのサイズを管理する方法、システム、およびプログラム製品を提供すること。【解決手段】コンテンツ配布中にＫＭＢのサイズを管理する方法、システム、およびプログラム製品を提供する。具体的に言うと、デバイスの第１サブツリーに対応する第１ＫＭＢを、タイトル鍵を用いて暗号化されたコンテンツと共に受信する。第１ＫＭＢのサイズが所定の閾値を超える場合に、第２サブツリーを作成する。その後、デバイスの第２サブツリーに対応する第２ＫＭＢを生成する。第２ＫＭＢには、デバイスの第１サブツリー全体を取り消す項目が含まれ、したがって、第１ＫＭＢより小さい。準拠デバイスのすべてが、第１サブツリーから第２サブツリーに移行される。【選択図】　図２
2004048673.tif 000002
【特許請求の範囲】
【請求項１】
コンテンツ配布中に鍵管理ブロック（ＫＭＢ）のサイズを管理する方法であって、
第１副構造に対応する第１ＫＭＢと、タイトル鍵を用いて暗号化されたコンテンツとを提供するステップと、
前記第１ＫＭＢのサイズが所定の閾値を超えるかどうかを判定するステップと、
第２副構造に対応する第２ＫＭＢを提供するステップであって、前記第２ＫＭＢが、前記第１副構造を取り消す項目を含む、ステップと、
前記第１副構造から前記第２副構造へ準拠デバイスを移行するステップと
を含む方法。
【請求項２】
前記タイトル鍵が、前記第１ＫＭＢ内で保護される第１鍵暗号化鍵を用いて暗号化される、請求項１に記載の方法。
【請求項３】
前記第１ＫＭＢから回復される前記第１鍵暗号化鍵を用いて、前記暗号化されたタイトル鍵を暗号化解除するステップと、
前記第２ＫＭＢから回復される前記第２鍵暗号化鍵を用いて前記タイトル鍵を再暗号化するステップと
をさらに含む、請求項２に記載の方法。
【請求項４】
前記移行するステップが、
更新されたデバイス鍵情報を含む移行データを受信するステップと、
前記更新されたデバイス鍵情報をデバイスに送信するステップと、
前記デバイスが前記更新されたデバイス鍵情報を実施するステップと
を含む、請求項１に記載の方法。
【請求項５】
前記移行データが、前記第１副構造から前記第２副構造へ移行される準拠デバイスに対応する項目を含み、各項目が、前記第１副構造での少なくとも１つの準拠デバイスの位置と、前記少なくとも１つの準拠デバイスの更新されたデバイス鍵情報とを識別する、請求項４に記載の方法。
【請求項６】
前記移行データが、ライセンス管理組織からコンテンツ・サービス・プロバイダによって受信される、請求項４に記載の方法。
【請求項７】
コンテンツ配布中に鍵管理ブロック（ＫＭＢ）のサイズを管理する方法であって、
デバイスの第１サブツリーに対応する第１ＫＭＢと、タイトル鍵を用いて暗号化されたコンテンツとを提供するステップであって、前記タイトル鍵が、前記第１ＫＭＢ内で保護される第１鍵暗号化鍵を用いて暗号化される、ステップと、
前記第１ＫＭＢのサイズが所定の閾値を超えるかどうかを判定するステップと、
デバイスの第２サブツリーに対応する第２ＫＭＢを提供するステップであって、前記第２ＫＭＢが、デバイスの前記第１サブツリーを取り消す項目を含み、前記第２ＫＭＢが、前記第１ＫＭＢより小さい、ステップと、
デバイスの前記第１サブツリーからデバイスの前記第２サブツリーへ準拠デバイスを移行するステップと、
前記第２ＫＭＢから回復される第２鍵暗号化鍵を用いて前記タイトル鍵を再暗号化するステップと
を含む方法。
【請求項８】
前記再暗号化ステップの前に、前記第１ＫＭＢから回復される前記第１鍵暗号化鍵を用いて、前記暗号化されたタイトル鍵を暗号化解除するステップをさらに含む、請求項７に記載の方法。
【請求項９】
前記移行するステップが、
更新されたデバイス鍵情報を含む移行データを受信するステップと、
前記更新されたデバイス鍵情報をデバイスに送信するステップと、
前記デバイスが前記更新されたデバイス鍵情報を実施するステップと
を含む、請求項７に記載の方法。
【請求項１０】
前記移行データが、デバイスの前記第１サブツリーからデバイスの前記第２サブツリーへ移行される準拠デバイスに対応する項目を含み、各項目が、デバイスの前記第１サブツリーでの少なくとも１つの準拠デバイスの位置と、前記少なくとも１つの準拠デバイスの更新されたデバイス鍵情報とを識別する、請求項９に記載の方法。
【請求項１１】
コンテンツ配布中に鍵管理ブロック（ＫＭＢ）のサイズを管理するシステムであって、
デバイスの第１サブツリーに対応する第１ＫＭＢと、タイトル鍵を用いて暗号化されたコンテンツとを受信するシステムと、
デバイスの第２サブツリーに対応する第２ＫＭＢを受信するシステムであって、前記第２ＫＭＢが、前記第１ＫＭＢより小さく、前記第２ＫＭＢが、デバイスの前記第１サブツリーを取り消す項目を含む、システムと、
デバイスの前記第１サブツリーからデバイスの前記第２サブツリーへ移行データに基づいて準拠デバイスを移行するシステムと
を含むシステム。
【請求項１２】
前記第１ＫＭＢから回復される第１鍵暗号化鍵を用いて、前記暗号化されたタイトル鍵を暗号化解除するシステムと、
前記第２ＫＭＢから回復される第２鍵暗号化鍵を用いて前記タイトル鍵を再暗号化するシステムと
をさらに含む、請求項１１に記載のシステム。
【請求項１３】
前記移行するシステムが、
前記更新されたデバイス鍵情報を含む移行データを受信するシステムと、
前記更新されたデバイス鍵情報をデバイスに送信するシステムと、
を含む、請求項１１に記載のシステム。
【請求項１４】
前記移行データが、デバイスの前記第１サブツリーからデバイスの前記第２サブツリーへ移行される準拠デバイスに対応する項目を含み、各項目が、デバイスの前記第１サブツリーでの少なくとも１つの準拠デバイスの位置と、前記少なくとも１つの準拠デバイスの更新されたデバイス鍵情報とを識別する、請求項１３に記載のシステム。
【請求項１５】
前記第１ＫＭＢのサイズが所定の閾値を超えるかどうかを判定するシステムと、
デバイスの前記第１サブツリーの前記準拠デバイスをデバイスの前記第２サブツリーにマッピングするシステムと
をさらに含む、請求項１１に記載のシステム。
【請求項１６】
コンテンツ配布中に鍵管理ブロック（ＫＭＢ）のサイズを管理する、記録可能媒体に保管されたプログラムであって、該プログラムがコンピュータに、
デバイスの第１サブツリーに対応する第１ＫＭＢと、タイトル鍵を用いて暗号化されたコンテンツとを受信する機能と、
デバイスの第２サブツリーに対応する第２ＫＭＢを受信するプログラム・コードであって、前記第２ＫＭＢが、前記第１ＫＭＢより小さく、前記第２ＫＭＢが、デバイスの前記第１サブツリーを取り消す機能と、
デバイスの前記第１サブツリーからデバイスの前記第２サブツリーへ移行データに基づいて準拠デバイスを移行する機能と
を実現させるプログラム。
【請求項１７】
前記第１ＫＭＢから回復される第１鍵暗号化鍵を用いて、前記暗号化されたタイトル鍵を暗号化解除する機能と、
前記第２ＫＭＢから回復される第２鍵暗号化鍵を用いて前記タイトル鍵を再暗号化する機能と
をさらに含む、請求項１６に記載のプログラム。
【請求項１８】
前記移行する機能が、
前記更新されたデバイス鍵情報を含む移行データを受信する機能と、
前記更新されたデバイス鍵情報をデバイスに送信する機能と、
を含む、請求項１６に記載のプログラム。
【請求項１９】
前記移行データが、デバイスの前記第１サブツリーからデバイスの前記第２サブツリーへ移行される準拠デバイスに対応する項目を含み、各項目が、デバイスの前記第１サブツリーでの少なくとも１つの準拠デバイスの位置と、前記少なくとも１つの準拠デバイスの更新されたデバイス鍵情報とを識別する、請求項１８に記載のプログラム。
【請求項２０】
前記第１ＫＭＢのサイズが所定の閾値を超えるかどうかを判定する機能と、
デバイスの前記第１サブツリーの前記準拠デバイスをデバイスの前記第２サブツリーにマッピングする機能と
をさらに含む、請求項１６に記載のプログラム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
一般に、本発明は、コンテンツ配布中の鍵管理ブロック（ＫＭＢ：ＫｅｙＭａｎａｇｅｍｅｎｔ　Ｂｌｏｃｋ）のサイズを管理する方法、システム、およびプログラム製品を提供する。具体的には、本発明は、デバイスの第１サブツリーに対応するＫＭＢの、デバイスの第２サブツリーに対応するより小さいＫＭＢへの置換を提供する。
【０００２】
【従来の技術】
ディジタル・コンテンツの配布中に、ビデオ・データおよびオーディオ・データなどのコンテンツが、通常は、コンテンツ・ソースからコンテンツ受信側に送信される。１つの一般的な実施形態で、コンテンツが、コンテンツ所有者（たとえばケーブル・テレビジョン・ネットワーク）によって準備され、暗号化され、その後、コンテンツ・サービス・プロバイダ（たとえばケーブル・サービス・プロバイダ）に送達される。その後、サービス・プロバイダが、暗号化されたコンテンツを、加入顧客に送達する。コンテンツ配布の分野の新しい技術を、ブロードキャスト暗号化と称し、このブロードキャスト暗号化では、暗号化されたコンテンツおよびコンテンツにアクセスするのに必要なすべての情報が、一方向通信を介して送達される。すなわち、受信側は、ソースとのフォローアップ通信を保持する必要がない。この技術では、コンテンツが、タイトル鍵を用いて暗号化され、タイトル鍵自体は、鍵暗号化鍵を用いて暗号化される。鍵暗号化鍵は、コンテンツと共に送信される鍵管理ブロック（ＫＭＢ）内に保護された形で保管される。準拠する受信器デバイス（たとえば、セットトップ・ボックス、ＤＶＤプレイヤなど）は、ＫＭＢを処理して鍵暗号化鍵を回復することができ、その結果、タイトル鍵を暗号化解除でき、コンテンツにアクセスできるようになる。
【０００３】
一般に、ＫＭＢには、準拠受信器デバイスからのデバイス鍵を用いてのみ暗号化解除できる鍵暗号化鍵の保護された伝送物が含まれる。この範囲で、鍵暗号化鍵は、ＫＭＢ内で多数の形をとることができる。たとえば、鍵暗号化鍵を、複数回暗号化することができる（すなわち、有効なデバイス鍵の組ごとに１回）。さらに、ＫＭＢに、取り消されたデバイスの項目を含めることができる。具体的に言うと、受信器デバイスが、非準拠デバイスまたは迂回デバイスであると判定された場合に、そのデバイスを取り消す項目が、ＫＭＢ内に生成される。この項目によって、取り消されたデバイスが鍵暗号化鍵を回復できなくなる。
【０００４】
しかし、ＫＭＢのサイズが大きくなる時に、問題が生じる。具体的に言うと、ノアール−ノアール−ロツピエヒ（Ｎａｏｒ−Ｎａｏｒ−Ｌｏｔｓｐｉｅｃｈ）ツリー・アルゴリズムなどの一般的に使用される方法では、デバイスが取り消されるたびに、そのデバイスがＫＭＢ内の取消項目に置かれる（各項目が、複数のデバイスを取り消すことができる）。取消項目の数が増えるにつれて、ＫＭＢのサイズが増える。ＫＭＢは、鍵暗号化鍵を回復するために送信され、処理されなければならないので、ＫＭＢが大きくなるほど、コンテンツにアクセスするのに時間がかかるようになる。この範囲で、受信器デバイスがコンテンツを受信し始めた時からコンテンツを暗号化解除できる時までの時間期間を、収集時間と称する（たとえば、ＴＶチャンネルが変更された時から絵が表示される時までの時間期間）。したがって、ＫＭＢが大きくなるにつれて、収集時間が増え、これによって、消費者のより大きいフラストレーションが引き起こされる可能性がある。
【０００５】
収集時間を減らす、以前の試みでは、ＫＭＢの伝送物に割り振られる帯域幅を増やすことが用いられた。しかし、当技術分野で既知の通り、より大きい帯域幅は、非常に貴重である。上で言及したノアール−ノアール−ロツピエヒ・ツリー・アルゴリズムは、帯域幅要件を減らすのに役立つ（すなわち、取消ごとに１２バイトだけが必要）が、ＫＭＢ内のかなりのスペースが、取り消されたデバイスによって占められる可能性がある。
【０００６】
したがって、ＫＭＢのサイズを管理する方法、システム、およびプログラム製品の必要が存在する。具体的に言うと、デバイスの第１サブツリーに対応する第１ＫＭＢのサイズが所定の閾値を超える時を判定する必要が存在する。所定の閾値に達した時に第２のより小さいＫＭＢを実施する、さらなる必要が存在する。
さらに、第１サブツリーから第２サブツリーへ準拠デバイスを移行する必要が存在する。
【０００７】
【発明が解決しようとする課題】
本発明は、鍵管理ブロック（ＫＭＢ）が従来技術で論理鍵階層（ＬＫＨ：ＬｏｇｉｃａｌＫｅｙ　Ｈｉｅｒａｒｃｈｙ）と称する形態である時に、ＫＭＢのサイズを管理する方法、システム、およびプログラム製品を提供する。具体的に言うと、本発明の下で、第１副構造（たとえば第１サブツリー）に対応する第１ＫＭＢが、タイトル鍵を用いて暗号化されたコンテンツと共に受信される。タイトル鍵自体は、第１ＫＭＢから回復可能な鍵暗号化鍵を用いて暗号化されている。第１ＫＭＢのサイズが所定の閾値を超える時に、第２副構造（たとえば第２サブツリー）が作成される。その後、第２副構造に対応する第２ＫＭＢが生成される。第２ＫＭＢには、第１サブツリーを取り消す項目が含まれる。単一の項目が、第１副構造全体を取り消すのに十分なので、結果のＫＭＢは、実質的にサイズが減らされる。移行データに基づいて、すべての準拠デバイスが、第１副構造から第２副構造に移行される。移行は、多数の形で実行することができる。通常の実施形態では、移行に、第１サブツリーから第２サブツリーへの準拠デバイスのマッピングと、準拠デバイスへの更新されたデバイス鍵情報の送信が含まれる。第１副構造内で取り消されたデバイスは、移行されず、したがって、正しい鍵暗号化鍵の計算から排除される。
【０００８】
【課題を解決するための手段】
本発明の第１の態様によれば、コンテンツ配布中に鍵管理ブロック（ＫＭＢ）のサイズを管理する方法が提供される。この方法は、（１）第１副構造に対応する第１ＫＭＢと、タイトル鍵を用いて暗号化されたコンテンツとを提供するステップと、（２）前記第１ＫＭＢのサイズが所定の閾値を超えるかどうかを判定するステップと、（３）第２副構造に対応する第２ＫＭＢを提供するステップであって、前記第２ＫＭＢが、前記第１副構造を取り消す項目を含む、ステップと、（４）前記第１副構造から前記第２副構造へ準拠デバイスを移行するステップとを含む。
【０００９】
本発明の第２の態様によれば、コンテンツ配布中に鍵管理ブロック（ＫＭＢ）のサイズを管理する方法が提供される。この方法は、（１）デバイスの第１サブツリーに対応する第１ＫＭＢと、タイトル鍵を用いて暗号化されたコンテンツとを提供するステップであって、前記タイトル鍵が、前記第１ＫＭＢ内で保護される第１鍵暗号化鍵を用いて暗号化される、ステップと、（２）前記第１ＫＭＢのサイズが所定の閾値を超えるかどうかを判定するステップと、（３）デバイスの第２サブツリーに対応する第２ＫＭＢを提供するステップであって、前記第２ＫＭＢが、デバイスの前記第１サブツリーを取り消す項目を含み、前記第２ＫＭＢが、前記第１ＫＭＢより小さい、ステップと、（４）デバイスの前記第１サブツリーからデバイスの前記第２サブツリーへ準拠デバイスを移行するステップと、（５）前記第２ＫＭＢから回復される第２鍵暗号化鍵を用いて前記タイトル鍵を再暗号化するステップとを含む。
【００１０】
本発明の第３の態様によれば、コンテンツ配布中に鍵管理ブロック（ＫＭＢ）のサイズを管理するシステムが提供される。このシステムは、（１）デバイスの第１サブツリーに対応する第１ＫＭＢと、タイトル鍵を用いて暗号化されたコンテンツとを受信するシステムと、（２）デバイスの第２サブツリーに対応する第２ＫＭＢを受信するシステムであって、前記第２ＫＭＢが、前記第１ＫＭＢより小さく、前記第２ＫＭＢが、デバイスの前記第１サブツリーを取り消す項目を含む、システムと、（３）デバイスの前記第１サブツリーからデバイスの前記第２サブツリーへ移行データに基づいて準拠デバイスを移行するシステムとを含む。
【００１１】
本発明の第４の態様によれば、コンテンツ配布中に鍵管理ブロック（ＫＭＢ）のサイズを管理する、記録可能媒体に保管されたプログラム製品が提供される。
実行される時に、このプログラム製品は、（１）デバイスの第１サブツリーに対応する第１ＫＭＢと、タイトル鍵を用いて暗号化されたコンテンツとを受信するプログラム・コードと、（２）デバイスの第２サブツリーに対応する第２ＫＭＢを受信するプログラム・コードであって、前記第２ＫＭＢが、前記第１ＫＭＢより小さく、前記第２ＫＭＢが、デバイスの前記第１サブツリーを取り消す項目を含む、プログラム・コードと、（３）デバイスの前記第１サブツリーからデバイスの前記第２サブツリーへ移行データに基づいて準拠デバイスを移行するプログラム・コードとを含む。
【００１２】
本発明の第５の態様によれば、タイトル鍵を再暗号化する方法が提供される。
この方法には、（１）第１鍵暗号化鍵を用いてタイトル鍵暗号化を提供するステップと、（２）前記第１鍵暗号化鍵を回復するために第１サブツリーに対応する第１ＫＭＢを処理するステップと、（３）前記第１鍵暗号化鍵を用いて前記タイトル鍵を暗号化解除するステップと、（４）第２鍵暗号化鍵を回復するために第２サブツリーに対応する第２ＫＭＢを処理するステップと、（５）前記第２鍵暗号化鍵を用いて前記タイトル鍵を再暗号化するステップとが含まれる。
【００１３】
したがって、本発明は、コンテンツ配布中に鍵管理ブロック（ＫＭＢ）のサイズを管理する方法、システム、およびプログラム製品を提供する。
【００１４】
図面は、単に概略表現であって、本発明の特定のパラメータを描くことを意図したものではない。図面は、本発明の通常の実施形態だけを描くことを意図され、したがって、本発明の範囲を制限するものとみなしてはならない。図面では、類似する符号が類似する要素を表す。
【００１５】
【発明の実施の形態】
説明を明瞭にするために、本発明の詳細な説明は、下記のセクションを有する。
Ｉ．定義
ＩＩ．詳細な説明
【００１６】
Ｉ．定義
本明細書で使用される時に、下記の用語は、下記の定義を有する。
【００１７】
コンテンツ　ディジタル・イメージまたはサウンド・データなどの、ソースから受信側に送達可能なすべてのデータ。
【００１８】
コンテンツ所有者　映画スタジオなどの、コンテンツを所有する実体。
【００１９】
コンテンツ・サービス・プロバイダ　ケーブル・サービス・プロバイダなどの、コンテンツ所有者から消費者へコンテンツを送達する「パイプライン」を提供する実体。
【００２０】
消費者家庭ネットワーク　相互接続されたデバイスがコンテンツを共用できるように実施される、相互接続された一連の消費者デバイス。
【００２１】
デバイス　セットトップ・ボックス、ＤＶＤプレイヤなどの、コンテンツ所有者、コンテンツ・サービス、または消費者家庭ネットワーク内の別のデバイスから直接にコンテンツを受け取る消費者受信器デバイス。
【００２２】
受信側　コンテンツ・サービス・プロバイダまたはデバイスなどの、本発明の下で伝送物を受信することができるすべての実体。
【００２３】
ソース　コンテンツ所有者、コンテンツ・サービス・プロバイダ、またはデバイス（消費者家庭ネットワーク内）などの、本発明の下で伝送物を送ることができるすべての実体。
【００２４】
タイトル鍵　コンテンツを暗号化するのに使用される鍵。
【００２５】
コンテンツ使用条件　コピー・コントロールなどの、コンテンツの使用または活用を管理するガイドライン。
【００２６】
鍵暗号化鍵　タイトル鍵またはタイトル鍵−コンテンツ使用条件の組合せを暗号化するのに使用される鍵。
【００２７】
鍵管理ブロック（ＫＭＢ）　保護された形で鍵暗号化鍵を含むデータ構造。ＫＭＢは、セッション鍵ブロック、メディア鍵ブロック、鍵メディア・ブロック、または管理鍵ブロックとも称する。
【００２８】
デバイス鍵（セット）　ＫＭＢから鍵暗号化鍵を回復するのに使用される、消費者デバイスに割り当てられた鍵（の組）。
【００２９】
ＩＩ．詳細な説明
一般に、本発明は、鍵管理ブロック（ＫＭＢ）のサイズを管理する方法、システム、およびプログラム製品を提供する。上で示したように、ＫＭＢには、通常は、保護された「バージョン」の鍵暗号化鍵ならびに取り消されたデバイスの項目が含まれる。取消項目の量が増えるにつれて、ＫＭＢのサイズも増える。準拠デバイスは、コンテンツを暗号化解除し、コンテンツにアクセスするために、ＫＭＢを受信し、処理しなければならないので、ＫＭＢのサイズは、ＫＭＢを送信するのに要する時間ならびにＫＭＢを処理するのに要する時間の両方に影響する。したがって、ＫＭＢをあるサイズ以下に維持することによって、改良されたサービスが消費者に提供される。
【００３０】
下でさらに述べるように、本発明は、すべてのデバイス（準拠デバイスと取り消されたデバイスの両方）をデバイスのサブツリー（または、後続の副構造が作成される時に単一の項目を用いて取り消すことができる他の副構造）から引き抜くことによってＫＭＢのサイズを管理する。サブツリー（または副構造）には、それぞれが特定のデバイスに対応するノードまたはリーフが含まれる。第１サブツリーの取り消されたデバイスの量が、所定の閾値（たとえば１０００個）を超える時、または第１サブツリーに対応するＫＭＢのサイズが所定の閾値（たとえば１００００バイト）を超える時に、第２サブツリーが開始される。第２サブツリーには、すべての新しいデバイス（準拠デバイスおよび取り消されたデバイス）、ならびに第１の（現在は消滅した）サブツリーから移行された準拠デバイスが含まれる。第２サブツリーに対応するすべてのＫＭＢに、第１サブツリー全体（すなわちそのツリーにあったすべてのデバイス）を取り消す単一の項目が含まれる。したがって、これらのＫＭＢには第１サブツリーからのデバイスの個々の取消が含まれないので、第２サブツリーに対応するＫＭＢは、サイズが小さくなる。
【００３１】
第２サブツリーに対応するＫＭＢを使用する決断が、一般に、コンテンツ・サービス・プロバイダによって行われることを理解されたい。したがって、サービス・プロバイダは、第１サブツリーに対応するより大きいＫＭＢの使用を継続することを選択することができる。
【００３２】
図１を参照すると、ＫＭＢ１２の送達を示す流れ図が示されている。図からわかるように、ライセンス管理組織１０などの独立の実体が、ＫＭＢ１２を開発する。上で示したように、ＫＭＢ１２は、鍵暗号化鍵１４の保護されたバージョン（たとえば複数暗号化）および取り消されたデバイスの項目を含むデータ構造である。デバイス鍵１６は、ＫＭＢ１２と共に、鍵暗号化鍵１４を判定するのに使用され、鍵暗号化鍵１４は、タイトル鍵またはコンテンツ使用条件（下で詳細に説明する）あるいはその両方の暗号化／暗号化解除に使用される。具体的に言うと、ライセンス管理組織１０によって開発されると、ＫＭＢ１２は、コンテンツ所有者１８に配布され、コンテンツ所有者１８は、コンテンツ２４を準備し、タイトル鍵を用いて暗号化する。その後、タイトル鍵が、鍵暗号化鍵１４を用いて暗号化される。コンテンツ所有者１８は、暗号化されたコンテンツ２４を、ＫＭＢ１２と共に消費者３２に（または消費者３２にそのコンテンツを送達するコンテンツ・サービス・プロバイダに）送達する。ライセンス管理組織１０は、デバイス製造業者２２にも有効なデバイス鍵１６を送達し、デバイス製造業者２２は、有効なデバイス鍵１６を含む準拠するデバイス２６を消費者３２に送達（すなわち販売）する。消費者３２は、購入したデバイス２６内のデバイス鍵１６を使用して、ＫＭＢ１２を処理して、鍵暗号化鍵１４を回復することができ、この鍵暗号化鍵１４が、タイトル鍵の暗号化解除に使用される。消費者３２によって使用されるデバイス鍵が、真正でないか、ＫＭＢ１２内で取り消された場合には、正しい鍵暗号化鍵１４は回復されない。非準拠デバイスは、コンテンツを不法にまたは不正に利用できるようにする、迂回デバイスまたは取り消されたデバイスとして識別されるデバイスである。したがって、ＫＭＢ１２およびデバイス鍵１６によって、コンテンツが悪用されなくなる。
【００３３】
図２を参照すると、コンテンツ２４およびＫＭＢ１２の暗号化と、サービス・プロバイダ３０および消費者３２への送達が詳細に示されている。図からわかるように、コンテンツ所有者１８は、ＫＭＢ１２およびコンテンツ所有者鍵４６をライセンス管理組織１０から受信する。コンテンツ所有者１８は、コンテンツ所有者鍵４６を用いてＫＭＢ１２を処理して、鍵暗号化鍵１４を回復する。さらに示されているように、コンテンツ所有者１８は、タイトル鍵３４を用いてコンテンツ２４を暗号化する。コンテンツ２４を暗号化したならば、タイトル鍵３４自体を、鍵暗号化鍵１４を用いて暗号化する。任意選択として、コンテンツ所有者１８は、所有者コンテンツ使用条件３８を提供することができる。提供される場合に、そのような条件を、ダイジェスト４０に圧縮し、タイトル鍵３４と組み合わせる（たとえばＸＯＲ演算を介して）ことができる。結果の組合せ４２（たとえば、メッセージ確認コードまたはＭＡＣとも称する）を、鍵暗号化鍵１４を用いて暗号化して、暗号化された組合せ４４を作ることができる。所有者コンテンツ使用条件３８は、コピー・コントロールなど、コンテンツ２４に対して設定されるすべての制御とすることができる。
【００３４】
その後、暗号化されたコンテンツ３６を、任意選択として、ＫＭＢ１２および暗号化解除された所有者コンテンツ使用条件３８（提供される場合に）と共にコンテンツ・サービス・プロバイダ３０に送信するために、暗号化された組合せ４４（または暗号化されたタイトル鍵）にバインドすることができる。所有者コンテンツ使用条件３８およびその後続のダイジェスト４０への圧縮および鍵暗号化鍵１４による暗号化のためのタイトル鍵３４との組合せの指定が、本発明の下で任意選択であることを理解されたい。したがって、タイトル鍵３４だけを暗号化し、任意選択として送信のために、暗号化されたコンテンツ３６にバインドできることを涼解されたい。
【００３５】
図３を参照すると、コンテンツ所有者１８からの図２の伝送物の受信が詳細に示されている。受信時に、サービス・プロバイダ３０は、とりわけ、（１）通信をそのままで消費者３２に転送する、（２）新しい鍵暗号化鍵を用いてタイトル鍵を再暗号化する、または（３）コンテンツ使用条件を検証するか修正するかその両方を行う、あるいはこれらの組合せを含む多数の選択を実行することができる。図３からわかるように、サービス・プロバイダ３０は、暗号化された組合せ４４を受信し、それから暗号化されたコンテンツ３６をアンバインドする。ライセンス管理組織１０から受信したサービス・プロバイダ鍵６０を用いてＫＭＢ１２を処理することによって、鍵暗号化鍵１４を回復し、暗号化された組合せ４４の暗号化解除に使用することができる。暗号化解除された組合せ４８を作ったならば、サービス・プロバイダ３０は、タイトル鍵３４（図２）を回復するか、コンテンツ使用条件を修正するか、その両方を行うことができる。前者の場合に、タイトル鍵３４は、所有者コンテンツ使用条件３８を使用してダイジェスト４１を作成することによって回復することができる。作成されたならば、ダイジェスト４１は、暗号化された組合せ４８にダイジェストされたコンテンツ使用条件を分離するのに使用される。この時に、作成されたダイジェスト４１と暗号化された組合せ４８内のダイジェスト４０（図２）を比較することによって、所有者コンテンツ使用条件３８を検証することができる。後者の場合には、既存のコンテンツ使用条件に対するすべての修正または新しいコンテンツ使用条件の追加あるいはその両方が、サービス・プロバイダ・コンテンツ使用条件５２として供給される。そのようなサービス・プロバイダ・コンテンツ使用条件５２を、ダイジェスト５４に圧縮し、組合せ４８に追加して、組合せ５６を作る。この組合せ５６を、鍵暗号化鍵１４を用いて暗号化して、新しい暗号化された組合せ５８を作る。暗号化された組合せ５８は、その後、任意選択として、暗号化されたコンテンツ３６とバインドされ、ＫＭＢ１２、暗号化解除された所有者コンテンツ使用条件３８、および暗号化解除されたサービス・プロバイダ・コンテンツ使用条件５２と共に、消費者に送信される。
【００３６】
図３に関して図示し、説明した処理が、任意選択であり、例示のみのために本明細書に含まれることを理解されたい。具体的に言うと、サービス・プロバイダ３０は、タイトル鍵３４の回復またはコンテンツ使用条件の修正もしくはこの両方を行わずに、加入消費者に伝送物を単純に転送することができる。さらに、上で示したように、図２および３に示されたコンテンツ使用条件の実施形態は、本発明の制限的部分になることを意図されていない。具体的に言うと、タイトル鍵３４を、暗号化するだけにすることができる（すなわち、ダイジェスト４０および５４との組合せなし）。そのような場合には、タイトル鍵３４を回復するためのダイジェストの作成が不要になる。
【００３７】
図４を参照すると、デバイス２６による図３の伝送物の受信が詳細に示されている。デバイス２６は、ディジタル・コンテンツを受信できるすべての消費者デバイスの例として意図されている。そのようなデバイスには、とりわけ、ケーブル・テレビジョン信号を受信するセットトップ・ボックス、ＤＶＤプレイヤ、テレビジョン、パーソナル・コンピュータなどを含めることができる。図からわかるように、デバイス２６は、暗号化された組合せ５８を受信し、それから暗号化されたコンテンツ３６を分離する。その後、鍵暗号化鍵１４を使用して、暗号化された組合せ５８を暗号化解除して、組合せ５６を作る。鍵暗号化鍵１４は、デバイス鍵１６を用いてＫＭＢ１２を処理することによって回復される。図１に関して上で説明したように、デバイス鍵１６は、ライセンス管理組織１０によってデバイス製造業者に供給され、これを用いると、デバイス２６がＫＭＢ１２に含まれる鍵暗号化鍵１４を回復できるようになる。さらに、上で説明したように、ＫＭＢ１２は、非準拠と思われるデバイスを、それらが正しい鍵暗号化鍵１４を計算できないという意味で、取り消す。すなわち、デバイスが、迂回デバイスまたは取り消されたデバイスとして識別された場合に、そのデバイス鍵によって、ＫＭＢ１２内で保護された正しい鍵暗号化鍵１４を計算することができない。したがって、非準拠デバイスは、タイトル鍵３４を回復することができず、コンテンツ２４にアクセスすることができない。
【００３８】
暗号化解除された組合せ５６が明らかにされたならば、デバイス２６は、保全性を検証するか、タイトル鍵３４を回復するためにサービス・プロバイダ・コンテンツ使用条件５２を「分離」するか、その両方を行う。前者の場合に、検証は、図３に関して上で説明したように実行することができる。具体的に言うと、サービス・プロバイダ・コンテンツ使用条件５２に基づくダイジェスト５５を、作成し、暗号化解除された組合せ５６内のダイジェスト５４（図３）としてのサービス・プロバイダ使用条件と比較する。後者の場合には、デバイス２６は、ダイジェスト５５を使用して、暗号化解除された組合せ５６からサービス・プロバイダ・コンテンツ使用条件５２を除去して、組合せ４８を作る。サービス・プロバイダ・コンテンツ使用条件５２が除去されたならば、所有者コンテンツ使用条件３８（図２）を、類似する形で検証するか除去するかその両方を行うことができる。具体的に言うと、所有者コンテンツ使用条件３８を使用して、ダイジェスト４１を作成し、これを使用して、組合せ４８でダイジェストされた所有者コンテンツ使用条件３８の保全性を検証するか、「分離」するか、その両方を行うことができる。すべてのコンテンツ使用条件を「分離」したならば、タイトル鍵３４を回復する。タイトル鍵３４を用いると、暗号化されたコンテンツ３６を暗号化解除して、テレビジョン、モニタ、または類似物に表示できるようになる。
【００３９】
検証または「分離」あるいはその両方のほかに、デバイス２６は、伝送物で受信されたすべてのコンテンツ使用条件（提供される場合に）に従わなければならないことを諒解されたい。たとえば、所有者コンテンツ使用条件３８で、コンテンツ２４のコピーが止められており、サービス・プロバイダ・コンテンツ使用条件５２で、その再ブロードキャストが止められている場合には、デバイス２６は、コンテンツ２４のコピーも再ブロードキャストも行うことができない。さらに、図４に、所有者コンテンツ使用条件３８の前のサービス・プロバイダ・コンテンツ使用条件５２の分離が示されているが、分離を、実際には任意の順序で行うことができることを諒解されたい。さらに、図示されていないが、消費者３２（図１）に、コンテンツ使用条件を修正する（たとえば、既存の条件を編集するか、新規の条件を追加する）制限付きの権利を与えることができる。そのような権利は、たとえば、デバイス２６が消費者家庭ネットワークの一部である時に付与することができる。消費者家庭ネットワークでは、複数の認可されたデバイスを、単一の（たとえば世帯）ネットワークを介して相互接続することができ、コンテンツを自由に共用することを許可される。
【００４０】
上の説明からわかるように、ＫＭＢ１２は、コンテンツ２４にアクセスする手段になる。具体的に言うと、コンテンツ２４を暗号化解除するためには、デバイス２６がＫＭＢ１２を受信し、処理できることが必要である。さらに、サービス・プロバイダ３０または消費者３２あるいはその両方によって実行される可能性がある複数のステップ（たとえば、タイトル鍵３４回復、ダイジェスト作成／再作成など）に対して、ＫＭＢ１２が受信され、処理される速度が、大いに関係する。上で説明したように、デバイス２６による伝送物の受信と、コンテンツが暗号化解除され復号される時の間の時間を、収集時間と称する。収集時間の１例が、消費者３２がチャンネルを変更した時とコンテンツが表示される時の間の遅延である。
【００４１】
ＫＭＢ１２の効率的な送信および処理において、ＫＭＢのサイズが支配的要因になる。すなわち、ＫＭＢが大きいほど（たとえばバイト単位）、ＫＭＢの送信および処理に時間がかかる。ＫＢＭ１２には、取り消されたデバイスの項目（たとえば取り消されたデバイス鍵）が含まれるので、ＫＭＢ１２のサイズは、取り消されたデバイスの数が増えるにつれて大きくなる。ある点で、ＫＭＢ１２が、その送信および処理がもはや不可能なほどに大きくなる。これは、収集時間の増加および顧客の不満足につながる。
【００４２】
本発明は、デバイスのサブツリーに基づいてＫＭＢを生成することによってこの問題に対処する。ここで、サブツリー上の取り消されたデバイスの量が所定の閾値（たとえば１００００）を超えたか、ＫＭＢのサイズが所定の閾値（たとえば３００バイト）を超えた時に、新しいサブツリーを作成する。この時点から、生成される新しいＫＭＢのすべてが、新しいサブツリーに対応する。
【００４３】
図５を参照すると、第１サブツリー７２でのデバイスの配置が、詳細に示されている。図からわかるように、第１サブツリー７２は、マスタ・ツリー７０の部分である。第１サブツリー７２の各ノードは、単一の準拠デバイス７４または単一の取り消されたデバイス７６に対応する。ＫＭＢ１２が、第１サブツリー７２に基づいて作成される時に、ＫＭＢ１２に、すべての準拠デバイス７４が処理できる鍵暗号化鍵１４の保護されたバージョンが含まれる。ＫＭＢには、取り消されたデバイス７６の項目も含めることができる。ＫＭＢ１２のサイズまたはＫＭＢ１２の取消項目の数が所定の閾値を超える時に、第２サブツリーが作成される。具体的に言うと、各取り消されたデバイスは、ＫＭＢ１２に対応する項目を有しなければならない（項目によって、個々のデバイスまたはデバイスのグループのいずれかが識別される）ので、各取消によって、ＫＭＢ１２のサイズが増える。したがって、第１サブツリー７２のデバイスに対応する取消項目の数を制限することによって、ＫＭＢ１２のサイズも、所定の閾値までに本質的に制限される。
【００４４】
図６を参照すると、第２サブツリー７８が詳細に示されている。図からわかるように、第２サブツリーには、それぞれが新たに追加された準拠デバイス８０または新たに取り消されたデバイス８２に対応するノードが含まれる。すなわち、第２サブツリー７８には、第１サブツリー７２からの取り消されたデバイス７６が一切含まれない。しかし、第２サブツリー７８には、第１サブツリー７２から移行された準拠デバイス７４が含まれる（下で詳細に説明する）。
【００４５】
図７に示されているように、第２サブツリー８２に過剰な量の取り消されたデバイスが含まれるようになる時、または第２サブツリー８２に関連するＫＭＢが所定の閾値を超える時に、第３サブツリー８４を作成することができる。これは、マスタ・ツリー７０の容量まで継続することができる。具体的に言うと、使用可能なものがなくなるまでサブツリーの作成を継続することができる。なくなった場合には、サブツリーは、所定の閾値を超えることを許容される。すなわち、対応するＫＭＢのサイズは、もはや、所定の閾値未満である必要がない。
【００４６】
上で示したように、本発明が、サブツリーの使用に制限されないことを理解されたい。そうではなく、本発明の教示（ＫＭＢ作成を含む）は、ＫＭＢ内の単一の項目を用いて取り消すことができるすべての副構造に基づくものとすることができる。
【００４７】
図８を参照すると、本発明による処理の流れ図１００が示されている。図からわかるように（図１に関して説明したように）、ライセンス管理組織１０は、デバイス製造業者２２用のデバイス鍵と、第１サブツリー７２に対応する第１世代ＫＭＢを生成する。第１世代ＫＭＢは、コンテンツ所有者１８に送信され、コンテンツ所有者１８は、タイトル鍵３４を用いてコンテンツを暗号化し、次に、第１世代ＫＭＢから回復される鍵暗号化鍵１４を用いてタイトル鍵３４（またはタイトル鍵とコンテンツ使用条件の組合せ）を暗号化する。コンテンツ所有者１８は、暗号化されたコンテンツ、暗号化されたタイトル鍵、および第１世代ＫＭＢをサービス・プロバイダ３０に転送する。いったん受信すると、サービス・プロバイダ３０は、とりわけ、コンテンツ使用条件を修正し、保護されたコンテンツを消費者に送信するなどを行うことができる。本発明の下では、サービス・プロバイダ３０が、第２世代ＫＭＢの受信を選択することもできる。具体的に言うと、サービス・プロバイダ３０は、第１世代ＫＭＢが大きくなりすぎる時に、第２世代ＫＭＢを受信するようにライセンス管理組織１０と取り決めることができる。通常の実施形態では、ライセンス管理組織１０が、現在のサブツリー内の取消項目の量または現在のサブツリーに対応するＫＭＢのサイズが所定の閾値を超える時に、デバイスの新しいサブツリーを開始する。第２世代サブツリーには、第１世代サブツリーからの取り消されたデバイスが全く含まれないので、第２世代サブツリーに基づくＫＭＢの取消項目の数が、大幅に減る。したがって、第２世代サブツリーに対応するすべてのＫＭＢ（すなわち第２世代ＫＭＢ）は、サイズが小さくなる。サービス・プロバイダ３０は、この新しい世代のＫＭＢを受信するか、第１世代ＫＭＢの受信を継続するという選択権を有する。一実施形態では、サービス・プロバイダ３０が、新しい世代のＫＭＢを、それが生成される時に受信することを選択することができる。これによって、新しいサブツリーを始める時に関するすべての「意思決定」が、ライセンス管理組織１０に委ねられる。
もう１つの実施形態では、サービス・プロバイダ３０が、前の世代のＫＭＢが所定の閾値（サービス・プロバイダ３０、ライセンス管理組織１０、または両方によって設定される）を超える時に、新しい世代のＫＭＢの受信を選択することができる。この場合に、サービス・プロバイダ３０は、新しい世代のＫＭＢを要求するメッセージをライセンス管理組織１０に送信することができる。ライセンス管理組織１０は、まだそうしていない場合に、新しい世代のサブツリーおよびＫＭＢを開始する。
【００４８】
どの場合でも、サービス・プロバイダ３０が、第２世代ＫＭＢの受信を選択する場合に、対応する第２世代ＫＭＢを使用できるようになる前に、準拠デバイスを、第１世代サブツリーから第２世代サブツリーに移行しなければならない。具体的に言うと、鍵暗号化鍵の保護された伝送物を含めることのほかに、第２世代ＫＭＢの単一の項目によって、デバイスの第１世代サブツリー全体が取り消される。すなわち、第１サブツリーのすべてのデバイスのデバイス鍵が、もはや有効ではなくなる。したがって、第２世代ＫＭＢに対応する第２サブツリーに移行されない場合に、第１サブツリーからの準拠デバイスが、保護されたコンテンツにアクセスするために第２世代ＫＭＢから鍵暗号化鍵を回復することができなくなる。
【００４９】
準拠デバイスの移行は、多数の形で行うことができる。通常の実施形態では、デバイスの移行に、サービス・プロバイダ３０がライセンス管理組織１０から移行データを受信し、その後、移行データを使用して、更新されたデバイス鍵情報を準拠デバイスに供給することが含まれる。通常、ライセンス管理組織１０によって準備される移行データには、項目のテーブルが含まれ、この項目のそれぞれが、移行される１つまたは複数のデバイス（たとえば、デバイス「Ａ」、デバイス「Ａ」および「Ｂ」など）に対応する。各項目によって、（１）第１サブツリーでの特定のデバイスの位置、（２）特定のデバイスの更新されたデバイス鍵情報、および（３）第２サブツリーでの特定のデバイスの位置が識別される。第２サブツリーでのデバイスの位置を得るために、マッピングを実行しなければならない（たとえば、ライセンス管理組織１０によって）。そのようなマッピングは、多数の形で行うことができる。一実施形態では、移行される各デバイス（すなわち準拠デバイス）を、それが第１サブツリーで占めていたのと同一の第２サブツリーの位置またはノードに割り当てることができる。たとえば、デバイス「Ａ」が、第１サブツリーのノード「ＮｘＹ」を占める場合に、このデバイスを、第２サブツリーのノード「ＮｘＹ」に割り当てることができる。もう１つの実施形態では、移行されるデバイスを、第１サブツリーでの位置に無関係に、第２サブツリーで一緒にグループ化することができる。すべての移行可能なデバイスを一緒にグループ化することによって、第２サブツリーで、取り消されたデバイスが第１サブツリーに存在した場所に穴が残されなくなる（すなわち、取り消されたデバイスは、移行されないので）。どの場合でも、デバイス位置を決定したならば、デバイス位置を、更新されたデバイス鍵情報と共に移行データに含めることができる。
【００５０】
一般に、準拠デバイスに通信される情報には、新しい位置（たとえば第２サブツリーでの）および、特定のデバイスだけが、更新されたデバイス鍵を暗号化解除し、得ることができるように暗号化された（他の形で保護された）更新されたデバイス鍵情報が含まれる。これは、移行処理中の更新されたデバイス鍵の海賊行為を思いとどまらせるのに役立つ。更新されたデバイス鍵は、移行可能なデバイスによって要求される。というのは、上で示したように、第２世代ＫＭＢの項目によって、第１サブツリー内のすべてのデバイスが取り消されるからである。
したがって、第１サブツリー内のデバイスに割り当てられたデバイス鍵は、もはや有効ではない。更新されたデバイス鍵を用いると、準拠デバイスが、新しいＫＭＢを処理して、その中の新しい鍵暗号化鍵を回復できるようになる。新しいデバイス鍵の情報がないと、デバイスは、新しい鍵暗号化鍵を判定できず、したがって、コンテンツにアクセスするためにタイトル鍵を暗号化解除することができない。デバイスがめいめいの更新されたデバイス鍵情報を受信したならば、移行が完了する。
【００５１】
更新されたデバイス鍵情報のデバイスへの送信を、多数の形で行うことができ、本発明が、単一の方法に制限されないことを意図されていることを理解されたい。第１の実施形態では、更新されたデバイス鍵情報を、デバイスが次に再供給のためにサービス・プロバイダへの接続を確立する時に送信することができる。
このシナリオでは、サービス・プロバイダが、移行（すなわち再キーイング）しなければならないことをデバイスに示すことができる。デバイスは、現在は取り消されている第１サブツリーでの位置を含むメッセージを、サービス・プロバイダに送り返す。サービス・プロバイダは、移行データ内のテーブルを参照し、デバイスによって供給される第１サブツリー位置を使用して、関係する項目を識別することができる。識別されたならば、その項目からの更新された鍵情報および第２サブツリー位置が、デバイスに送り返される。デバイスは、情報を暗号化解除して、新しいデバイス鍵を得、第２サブツリーでの位置を記憶する。もう１つの実施形態では、サービス・プロバイダが、たとえば「制御」チャンネルの一部としてある帯域幅を割り振り、繰り返して移行データを送信することができる。
デバイスは、制御チャンネルに同調し、現在位置（すなわち第１サブツリー上の）に関連する項目を待たなければならない。識別されたならば、デバイスは、対応する更新されたデバイス鍵および位置（すなわち第２サブツリー上の）を得る。どの場合でも、これらの実施形態の複数の変形形態も可能である。たとえば、サービス・プロバイダ３０が、アクティブ加入者に対応するすべてのデバイスの第１サブツリー位置を知ることができ、関係する項目だけが保管されるように移行データ内の項目をフィルタリングすることができる。代替案で、第三者が、移行データを保管し、照会（たとえばサービス・プロバイダまたは加入者デバイスから）に応答して、サブツリー位置を供給するオンライン・アクセスを提供することができる。情報がデバイスに通信される方法にかかわりなく、移行されるデバイスだけが、第１世代および第２世代の両方のＫＭＢを処理できることを理解されたい。
【００５２】
上で説明した移行方式の１つの可能な実施形態が、下記である。３１レベルの高さを有するマスタ・ツリーを用いると、約２０億個のノード（デバイス）が可能になる。各デバイスが保管しなければならないデバイス鍵セットのサイズを減らすために、わずかに大きいＫＭＢと引き換えに、ツリーを切り捨てることができる。上から８レベルを切り捨てることによって、デバイス鍵サイズが、おおむね５００個から２５０個の鍵に減る。この切捨によって２５６個のサブツリーが定義されるが、これらのサブツリーは、本発明の対象になるサブツリーに無関係である。たとえば、このマスタ・ツリーには、１６個の世代またはサブツリーがありえる。各サブツリーは、１億３千万個のデバイスをサポートすることができる。上で説明した移行データは、それぞれが約２６０個の鍵を使用する約１億３千万個の項目を必要とする。
【００５３】
上で説明したように、デバイスの移行は、多数の形で達成することができる。
上で説明した実施形態は、そのような形の１つの例であることを意図されている。もう１つの実施形態では、サービス・プロバイダ３０に、ツリーのルートへのアクセスが許可され、そこからのすべての方式「秘密」を生成することができる。この実施形態の下では、第１サブツリー７２から第２サブツリー７８へのマッピングの表現（たとえばリスト）以外の情報を、サービス・プロバイダ３０に送信する必要がない。この実施形態では、秘密のセキュリティがより困難になる可能性があるが、サービス・プロバイダ３０が受信し処理しなければならない情報（移行データ）が減る。
【００５４】
準拠デバイスを第１サブツリーから移行することのほかに、サービス・プロバイダ３０（または第三者）が、タイトル鍵を再暗号化することもできる。再暗号化は、第２世代ＫＭＢに新しい鍵暗号化鍵が含まれる時に必要になる。タイトル鍵を再暗号化するために、サービス・プロバイダ３０は、サービス・プロバイダ鍵（ライセンス管理組織１０から得られる）を使用して第１世代ＫＭＢから第１世代鍵暗号化鍵を回復する。回復されたならば、タイトル鍵（またはタイトル鍵−コンテンツ使用条件の組合せ）が暗号化解除される。その後、サービス・プロバイダ３０は、ライセンス管理組織１０から直接に受信した第２世代ＫＭＢから第２世代鍵暗号化鍵を回復する。回復されたならば、第２世代鍵暗号化鍵を使用して、タイトル鍵を再暗号化する。この時点から、サービス・プロバイダ３０からの通信を受信するデバイスは、コンテンツにアクセスするのに第２世代鍵暗号化鍵を使用しなければならない。
【００５５】
ＫＭＢのサイズを管理するのに使用される図１から８の要素を、ハードウェア、ソフトウェア、あるいはハードウェアまたはソフトウェアの組合せとして実施できることを理解されたい。したがって、すべての種類のコンピュータ／サーバ・システム、または本明細書に記載の方法を実行するように適合された他の装置が、適する。ハードウェアおよびソフトウェアの通常の組合せは、ロードされ実行される時に本明細書に記載の方法を実行するコンピュータ・プログラムを伴う汎用（コンピュータ）システムとすることができる。その代わりに、本発明の基本的タスクの１つまたは複数を実行するように特殊化されたハードウェアを含む特定用途（コンピュータ）システムを、使用することができる。本発明は、本明細書に記載の方法の実施形態を可能にする特徴のすべてを含み、（コンピュータ）システムにロードされた時にこれらの方法を実行することができる、コンピュータ・プログラム製品に組み込むこともできる。この文脈でのコンピュータ・プログラム、ソフトウェア・プログラム、プログラム、またはソフトウェアは、（ａ）別の言語、コード、または表記への変換、または（ｂ）異なる材料形態での再生のいずれかまたは両方の後にあるいは直接にのいずれかで、情報処理能力を有するシステムに特定の機能を実行させることを意図された命令の組の、すべての言語、コード、または表記での表現を意味する。
【００５６】
図９を参照すると、本発明の例示的なコンピュータ化された実施形態が示されている。上で説明したように、ライセンス管理組織１０は、コンテンツ所有者１８とサービス・プロバイダ３０の両方と通信する。サービス・プロバイダ３０は、受信した伝送物を消費者３２に通信する。図からわかるように、サービス・プロバイダ３０には、一般に、中央処理装置（ＣＰＵ）２００、メモリ２０２、バス２０４、入出力インターフェース２０６、外部デバイス／リソース２０８、およびデータベース２１０が含まれる。メモリ２０２には、磁気媒体、光媒体、ランダム・アクセス・メモリ（ＲＡＭ）、読取専用メモリ（ＲＯＭ）、データ・キャッシュ、データ・オブジェクトなどを含む、すべての既知のタイプのデータ記憶媒体またはデータ伝送媒体を含めることができる。さらに、メモリ２０２は、１つまたは複数のタイプのデータ記憶域を含む単一の物理位置に存在するか、さまざまな形の複数の物理システムにまたがって分散させることができる。ＣＰＵ２００は、同様に、単一の処理ユニットを含めるか、たとえばクライアントおよびサーバなど、１つまたは複数の位置の１つまたは複数の処理ユニットにまたがって分散させることができる。
【００５７】
入出力インターフェース２０６には、外部ソースからの情報を交換するすべてのシステムを含めることができる。外部デバイス／リソース２０８には、スピーカ、ＣＲＴ、ＬＥＤスクリーン、ハンドヘルド・デバイス、キーボード、マウス、音声認識システム、読み上げシステム、プリンタ、モニタ、ファクシミリ、ポケットベルなどを含む、すべての既知のタイプの外部装置を含めることができる。バス２０４は、サービス・プロバイダ３０内の構成要素のそれぞれの間の通信リンクを提供し、同様に、バス２０４に、電気リンク、光学リンク、無線リンクなどを含むすべての既知のタイプの伝送リンクを含めることができる。さらに、図示されてはいないが、キャッシュ・メモリ、通信システム、システム・ソフトウェアなどの追加の構成要素を、サービス・プロバイダ３０に組み込むことができる。
【００５８】
データベース２１０は、ＫＭＢ、加入者情報などの、本発明を実行するのに必要な情報のストレージを提供することができる。したがって、データベース２１０には、磁気ディスク・ドライブまたは光ディスク・ドライブなどの１つまたは複数のストレージ・デバイスが含まれる。もう１つの実施形態では、データベース２１０に、たとえばローカル・エリア・ネットワーク（ＬＡＮ）、広域ネットワーク（ＷＡＮ）、またはストレージ・エリア・ネットワーク（ＳＡＮ）（図示せず）などにまたがって分散されたデータが含まれる。データベース２１０は、当業者が、１つまたは複数のストレージ・デバイスを含めるために解釈することができる形で構成することもできる。
【００５９】
図９に図示されてはいないが、ライセンス管理組織１０、コンテンツ所有者１８、および消費者３２にも、同様のコンピュータ構成要素を含めることができることを理解されたい。そのような構成要素は、説明を簡潔にするために図示しなかった。
【００６０】
サービス・プロバイダ３０のメモリ２０２に保管されているのが、ＫＭＢシステム２１２であり、これには、受信システム２１４、移行システム２１６、暗号化解除システム２１８、暗号化システム２２０、および送信システム２２２が含まれる。上で説明したように、第１世代ＫＭＢは、ライセンス管理組織１０によって、第１世代サブツリーに基づいて作成される。第１世代ＫＭＢは、コンテンツ所有者１８に送信され、コンテンツ所有者１８は、タイトル鍵を用いてコンテンツを暗号化し、第１世代ＫＭＢから回復された鍵暗号化鍵を用いてタイトル鍵を暗号化する。コンテンツ所有者は、暗号化されたコンテンツおよび第１世代ＫＭＢ（ならびにコンテンツ使用条件）をサービス・プロバイダ３０に転送し、サービス・プロバイダ３０は、受信システム２１４を介してこれを受信する。
【００６１】
受信されたならば、サービス・プロバイダ３０が、保護されたコンテンツおよび第１世代ＫＭＢを消費者３２に転送することができる。しかし、第１世代サブツリーが、所定の閾値より多い量の取り消されたデバイスを有するか、第１世代ＫＭＢが所定の閾値より大きいサイズを有すると判定される場合には、第２世代サブツリーを作成することができる。図９に示されているように、この機能性は、ライセンス管理組織１０内のデバイス・システム２２４によって提供することができる。具体的に言うと、ライセンス管理組織１０に、デバイス・システム２２４が含まれ、このデバイス・システム２２４に、判定システム２２６、サブツリー・システム２２８、ＫＭＢシステム２３０、およびデータ・システム２３２が含まれる。判定システム２２６は、閾値のどれかを超えたかどうかを判定する。そうである場合には、サブツリー・システム２２８が、第２世代サブツリーを生成し、これに基づいて、第２世代ＫＭＢが作成され、サービス・プロバイダ３０に送信される。これらの第２世代ＫＭＢには、第１世代サブツリー内のすべてのデバイスを取り消す単一の項目が含まれる。すなわち、第１世代サブツリーのデバイスのすべてのデバイス鍵が、取り消され、第２世代ＫＭＢからの鍵暗号化鍵を回復するのに使用できない。したがって、第１世代サブツリーの、まだ準拠するすべてのデバイスを、第２世代サブツリーに移行して、暗号化されたコンテンツにアクセスできるようにしなければならない。
【００６２】
図示されてはいないが、本明細書に記載の機能を実行する他の変形形態を提供できることを理解されたい。たとえば、ライセンス管理組織１０の代わりに、サービス・プロバイダ３０に、第１世代ＫＭＢのサイズが所定の閾値より大きいかどうかを判定するシステムを設けることができる。したがって、第２世代サブツリーまたは第２世代ＫＭＢが必要であると判定する当事者がどれであるかは、本質的ではない。
【００６３】
上で示したように、デバイスの移行には、サービス・プロバイダ３０がライセンス管理組織１０から移行データを受信することと、消費者３２用のデバイス鍵情報を更新することが含まれる。関係する移行データは、ライセンス管理組織１０によって、データ・システム２３２を介して組み立てられる。そのようなデータには、それぞれが移行されるデバイスに対応する項目のテーブルが含まれる。
各項目によって、特定のデバイスの、更新されたデバイス鍵、第１世代サブツリー位置、および第２世代サブツリー位置が識別される。デバイスの第２世代サブツリー位置を決定する際に、マッピングを実行しなければならない。上で説明したように、このマッピングは、第２世代サブツリーで、デバイスが第１世代サブツリーで占めていたのと同一の位置にデバイスを割り当てることによって実行することができる。その代わりに、第２世代サブツリーで、すべての移行可能なデバイスを一緒にグループ化することによって、マッピングを実行することができる。
【００６４】
移行データが組み立てられたならば、サービス・プロバイダ３０は、受信システム２１４を介してこれを受信する。この時点で、移行システム２１６が、データを処理し、移行を実行する。すなわち、サービス・プロバイダ３０は、消費者の新しいデバイス鍵情報および第２世代サブツリーでの位置を、送信システム２２２を介して消費者３２に通信する。さらに、第２世代ＫＭＢが、異なる鍵暗号化鍵を有する可能性があるので、基礎となるコンテンツを暗号化するのに使用されたタイトル鍵の再暗号化が必要になる可能性がある。この場合には、暗号化解除システム２１８が、第１世代ＫＭＢ（データベース２１０に保管される）を処理して、第１鍵暗号化鍵を回復し、タイトル鍵を暗号化解除する。その後、ライセンス管理組織１０から直接に受信した第２世代ＫＭＢから新しい鍵暗号化鍵を回復することによって、タイトル鍵を再暗号化する（たとえば暗号化システム２２０を介して）。この時点で、第１世代ＫＭＢは、もはや無関係であり、破棄することができる。サービス・プロバイダ３０は、その後、暗号化されたコンテンツ、再暗号化されたタイトル鍵、および第２世代ＫＭＢを消費者３２に送信することができ、消費者３２は、その更新されたデバイス鍵を使用して、第２世代ＫＭＢから新しい鍵暗号化鍵を回復する。タイトル鍵の再暗号化を、任意の実体が実行できることを理解されたい。再暗号化は、例示のみのためにサービス・プロバイダ３０によって実行されるものとして図示されている。
【００６５】
本発明は、コンテンツ配布中にＫＭＢのサイズを案利する方法、システム、およびプログラム製品を提供する。本発明の前述の説明は、例示および説明のために提示された。網羅的であることまたは開示された正確な形態に本発明を制限することは意図されておらず、明らかに、多数の修正形態および変形形態が可能である。当業者に明白である可能性があるそのような修正形態および変形形態は、請求項によって定義される本発明の範囲に含まれることが意図されている。
【００６６】
まとめとして、本発明の構成に関して以下の事項を開示する。
【００６７】
（１）コンテンツ配布中に鍵管理ブロック（ＫＭＢ）のサイズを管理する方法であって、
第１副構造に対応する第１ＫＭＢと、タイトル鍵を用いて暗号化されたコンテンツとを提供するステップと、
前記第１ＫＭＢのサイズが所定の閾値を超えるかどうかを判定するステップと、
第２副構造に対応する第２ＫＭＢを提供するステップであって、前記第２ＫＭＢが、前記第１副構造を取り消す項目を含む、ステップと、
前記第１副構造から前記第２副構造へ準拠デバイスを移行するステップと
を含む方法。
（２）前記タイトル鍵が、前記第１ＫＭＢ内で保護される第１鍵暗号化鍵を用いて暗号化される、上記（１）に記載の方法。
（３）前記第１ＫＭＢから回復される前記第１鍵暗号化鍵を用いて、前記暗号化されたタイトル鍵を暗号化解除するステップと、
前記第２ＫＭＢから回復される前記第２鍵暗号化鍵を用いて前記タイトル鍵を再暗号化するステップと
をさらに含む、上記（２）に記載の方法。
（４）前記移行するステップが、
更新されたデバイス鍵情報を含む移行データを受信するステップと、
前記更新されたデバイス鍵情報をデバイスに送信するステップと、
前記デバイスが前記更新されたデバイス鍵情報を実施するステップと
を含む、上記（１）に記載の方法。
（５）前記移行データが、前記第１副構造から前記第２副構造へ移行される準拠デバイスに対応する項目を含み、各項目が、前記第１副構造での少なくとも１つの準拠デバイスの位置と、前記少なくとも１つの準拠デバイスの更新されたデバイス鍵情報とを識別する、上記（４）に記載の方法。
（６）前記移行データが、ライセンス管理組織からコンテンツ・サービス・プロバイダによって受信される、上記（４）に記載の方法。
（７）コンテンツ配布中に鍵管理ブロック（ＫＭＢ）のサイズを管理する方法であって、
デバイスの第１サブツリーに対応する第１ＫＭＢと、タイトル鍵を用いて暗号化されたコンテンツとを提供するステップであって、前記タイトル鍵が、前記第１ＫＭＢ内で保護される第１鍵暗号化鍵を用いて暗号化される、ステップと、
前記第１ＫＭＢのサイズが所定の閾値を超えるかどうかを判定するステップと、
デバイスの第２サブツリーに対応する第２ＫＭＢを提供するステップであって、前記第２ＫＭＢが、デバイスの前記第１サブツリーを取り消す項目を含み、前記第２ＫＭＢが、前記第１ＫＭＢより小さい、ステップと、
デバイスの前記第１サブツリーからデバイスの前記第２サブツリーへ準拠デバイスを移行するステップと、
前記第２ＫＭＢから回復される第２鍵暗号化鍵を用いて前記タイトル鍵を再暗号化するステップと
を含む方法。
（８）前記再暗号化ステップの前に、前記第１ＫＭＢから回復される前記第１鍵暗号化鍵を用いて、前記暗号化されたタイトル鍵を暗号化解除するステップをさらに含む、上記（７）に記載の方法。
（９）前記移行するステップが、
更新されたデバイス鍵情報を含む移行データを受信するステップと、
前記更新されたデバイス鍵情報をデバイスに送信するステップと、
前記デバイスが前記更新されたデバイス鍵情報を実施するステップと
を含む、上記（７）に記載の方法。
（１０）前記移行データが、デバイスの前記第１サブツリーからデバイスの前記第２サブツリーへ移行される準拠デバイスに対応する項目を含み、各項目が、デバイスの前記第１サブツリーでの少なくとも１つの準拠デバイスの位置と、前記少なくとも１つの準拠デバイスの更新されたデバイス鍵情報とを識別する、上記（９）に記載の方法。
（１１）コンテンツ配布中に鍵管理ブロック（ＫＭＢ）のサイズを管理するシステムであって、
デバイスの第１サブツリーに対応する第１ＫＭＢと、タイトル鍵を用いて暗号化されたコンテンツとを受信するシステムと、
デバイスの第２サブツリーに対応する第２ＫＭＢを受信するシステムであって、前記第２ＫＭＢが、前記第１ＫＭＢより小さく、前記第２ＫＭＢが、デバイスの前記第１サブツリーを取り消す項目を含む、システムと、
デバイスの前記第１サブツリーからデバイスの前記第２サブツリーへ移行データに基づいて準拠デバイスを移行するシステムと
を含むシステム。
（１２）前記第１ＫＭＢから回復される第１鍵暗号化鍵を用いて、前記暗号化されたタイトル鍵を暗号化解除するシステムと、
前記第２ＫＭＢから回復される第２鍵暗号化鍵を用いて前記タイトル鍵を再暗号化するシステムと
をさらに含む、上記（１１）に記載のシステム。
（１３）前記移行するシステムが、
前記更新されたデバイス鍵情報を含む移行データを受信するシステムと、
前記更新されたデバイス鍵情報をデバイスに送信するシステムと、
を含む、上記（１１）に記載のシステム。
（１４）前記移行データが、デバイスの前記第１サブツリーからデバイスの前記第２サブツリーへ移行される準拠デバイスに対応する項目を含み、各項目が、デバイスの前記第１サブツリーでの少なくとも１つの準拠デバイスの位置と、前記少なくとも１つの準拠デバイスの更新されたデバイス鍵情報とを識別する、上記（１３）に記載のシステム。
（１５）前記第１ＫＭＢのサイズが所定の閾値を超えるかどうかを判定するシステムと、
デバイスの前記第１サブツリーの前記準拠デバイスをデバイスの前記第２サブツリーにマッピングするシステムと
をさらに含む、上記（１１）に記載のシステム。
（１６）コンテンツ配布中に鍵管理ブロック（ＫＭＢ）のサイズを管理する、記録可能媒体に保管されたプログラムであって、該プログラムがコンピュータに、デバイスの第１サブツリーに対応する第１ＫＭＢと、タイトル鍵を用いて暗号化されたコンテンツとを受信する機能と、
デバイスの第２サブツリーに対応する第２ＫＭＢを受信するプログラム・コードであって、前記第２ＫＭＢが、前記第１ＫＭＢより小さく、前記第２ＫＭＢが、デバイスの前記第１サブツリーを取り消す機能と、
デバイスの前記第１サブツリーからデバイスの前記第２サブツリーへ移行データに基づいて準拠デバイスを移行する機能と
を実現させるプログラム。
（１７）前記第１ＫＭＢから回復される第１鍵暗号化鍵を用いて、前記暗号化されたタイトル鍵を暗号化解除する機能と、
前記第２ＫＭＢから回復される第２鍵暗号化鍵を用いて前記タイトル鍵を再暗号化する機能と
をさらに含む、上記（１６）に記載のプログラム。
（１８）前記移行する機能が、
前記更新されたデバイス鍵情報を含む移行データを受信する機能と、
前記更新されたデバイス鍵情報をデバイスに送信する機能と、
を含む、上記（１６）に記載のプログラム。
（１９）前記移行データが、デバイスの前記第１サブツリーからデバイスの前記第２サブツリーへ移行される準拠デバイスに対応する項目を含み、各項目が、デバイスの前記第１サブツリーでの少なくとも１つの準拠デバイスの位置と、前記少なくとも１つの準拠デバイスの更新されたデバイス鍵情報とを識別する、上記（１８）に記載のプログラム。
（２０）前記第１ＫＭＢのサイズが所定の閾値を超えるかどうかを判定する機能と、
デバイスの前記第１サブツリーの前記準拠デバイスをデバイスの前記第２サブツリーにマッピングする機能と
をさらに含む、上記（１６）に記載のプログラム。
【図面の簡単な説明】
【図１】鍵管理ブロック（ＫＭＢ）の送達を示す流れ図である。
【図２】コンテンツ所有者による、コンテンツ・サービス・プロバイダへの送信のためのコンテンツの暗号化の流れ図である。
【図３】サービス・プロバイダによる、コンテンツ所有者からの図２の伝送物の受信の流れ図である。
【図４】受信器による、サービス・プロバイダからの図３の伝送物の受信の流れ図である。
【図５】デバイスの第１サブツリーを示す図である。
【図６】デバイスの第２サブツリーを示す図である。
【図７】デバイスの第Ｎレベルのサブツリーを示す図である。
【図８】本発明による処理の流れ図である。
【図９】本発明のコンピュータ・システム実施形態を示す図である。
【符号の説明】
１０　ライセンス管理組織
１２　ＫＭＢ
１４　鍵暗号化鍵
１６　デバイス鍵
１８　コンテンツ所有者
２４　コンテンツ
２６　デバイス
３０　サービス・プロバイダ
３２　消費者
３４　タイトル鍵
３６　暗号化されたコンテンツ
３８　所有者コンテンツ使用条件
４０　ダイジェスト
４２　組合せ
４４　暗号化された組合せ
【図１】
2004048673.tif 000003
【図２】
2004048673.tif 000004
【図３】
2004048673.tif 000005
【図４】
2004048673.tif 000006
【図５】
2004048673.tif 000007
【図６】
2004048673.tif 000008
【図７】
2004048673.tif 000009
【図８】
2004048673.tif 000010
【図９】
2004048673.tif 000011