JP4856063B2 - ファーストパーティをセカンドパーティに認証する認証方法 - Google Patents

Description

本発明は、コピープロテクションシステムに関し、より詳細には、認証が成功した条件で動作が実行されるファーストパーティをセカンドパーティに認証する認証方法に関する。

コンピュータ又はＰＣにおけるドライブ／ホストインタフェース間の非セキュアなリンクのような公的にアクセス可能な通信チャネルにわたりコンテンツが転送される各種のコピープロテクションシステム（ＣＰＳ）では、手順が行われ、ハードウェアドライブ及びソフトウェアアプリケーションが互いに信頼することができることを証明する必要がある。この手順は認証と呼ばれる。認証手順における重要なステップは、公開鍵の証明書の相互のやり取りである。公開鍵の証明書は、公知かつ信頼された認証局（ＣＡ）によりデジタル的に署名されたショートステートメントであり、識別番号ＩＤをもつ所定の装置又はアプリケーションが公開鍵（ＰＫ）を有するということを証明する。以下では、装置及びアプリケーションの両者はパーティと呼ばれる。ＣＡのＰＫが一般に知られており、証明書でＣＡの署名を確認するために何れかのパーティにより使用することができる。

このプロセスをイネーブルにするため、それぞれのパーティは、プライベートキーと呼ばれる多数の秘密鍵を保持する。これらの鍵及びそれらを使用した制御フローは、ハッカーがＣＰＳを回避するのを防止するためにプロテクトされるべきである。しかし、長期にわたり、プレイバックソフトウェアのようなアプリケーションと同様に幾つか又は多くの装置でさえもハッキングされ、許可されていないコンテンツのコピーが実行される可能性がある。

かかる許可されていないコピーを更に困難にするため、どのパーティが無効にされたかに関する情報を含む、いわゆる証明書失効リストが用意される。認証手順の一部として、全てのパーティがＣＲＬを読むことが強制され、少なくとも１つの２つの対話するパーティが無効にされた場合、手順が割り込まれる。２種類のＣＲＬが存在する。ホワイトリスト（ＷＬ）は、所定の時間のポイントで従順な全てのパーティを列挙する。ブラックリスト（ＢＬ）は、無効にされている全ての装置を列挙する。この用途のため、全ての無効にされた装置の情報によってどれがなお従順であるかを判定するため、ＷＬ及びＢＬが含まれる情報における違いは存在しない。

しかし、それらがどのように解釈されて使用されるかにおいて違いが存在する。ＢＬを使用するとき、ファーストパーティすなわちベリファイ（verifying）パーティは、セカンドパーティすなわちプルーブ（proving）パーティが無効にされていないことを判定することを望み、完全なＢＬを取得する必要がある。ＷＬを使用するとき、ベリファイパーティは、プルービングパーティを示すＷＬのそのパートを得なければならない。したがって、ホワイトリストの使用は、ＣＰＳにおけるストレージ要件及びバス伝送の負荷の観点で有利である。これは、ベリファイパーティが光ドライブのような計算能力を有さない装置であるときに特に重要である。長いＢＬを処理及び分析することは、かかる装置にとって厄介である。

しかし、シンプルなホワイトリストは、それぞれのパーティがその非無効な状態を証明するそれ自身の証明書を得ることを必要とし、結果的に、過剰なネットワーク又はディスクストレージのオーバヘッドとなる。この問題点を緩和するため、ＷＯ０３／１０７８８（代理人ドケットＰＨＮＬ０２０５４３）及びＷＯ０３／１０７８９（代理人ドケットＰＨＮＬ０２０５４４）に開示されるような２ステップのアプローチが有効である。プルービングパーティは、その公開鍵の証明書を供給するのみでなく、グループ証明書（ＧＣ）を供給する。ＧＣは、１以上のグループのうちの１つにプルーブパーティが属する１以上のグループが無効にされていないことの簡明な証明である。同じＧＣは、多くのパーティ、すなわちＧＣに記載される全てのパーティにより使用することができる。効果的に、全体のＣＲＬはＧＣに分裂されており、これらは個々に署名され、コミュニケート（communicate）パーティに配信される。先に記載された国際特許出願に係るＧＣを使用する１つのやり方は、ＧＣにおいて表現されるそれぞれのグループの上及び下の境界を示すことである。特定のグループにおけるパーティがその許可されたパーティとしてそのステータスを失うとき、１以上の新たなＧＣが生成される。更なる改善は、欧州特許出願０４１０１１０４．０（代理人ドケットＰＨＮＬ０４０３３２）で記載される。この改善は、多数の装置の認証ステータスのランレングス符号化された表現を生成することを含む。

ＧＣを使用することで良好なハッカーの防止効果を有するため、パーティは、時代遅れでない無効情報を使用するため、かなり最近のＧＣを強制的に使用されるべきである。さもなければ、失効ツールが殆ど使用されない。ＵＳ５，９４９，８７７では、相対的なＣＲＬの作成日が含まれる方法が開示される。ベリファイパーティの無効リストは、パーティがより最近のリストを受信したときにアップデートされる。

ＵＳ５，９４９，８７７の意図の実現では、それぞれのＧＣは、ＣＡによりＧＣが作成された時間を示すシーケンス番号（ＳｅｑＮｏ）を伝える。したがって、より高いＳｅｑＮｏはより最近の時間に対応する。典型的に、先に説明されたように、新たなＧＣのセットは、失効の後に生成され、それぞれのＧＣは増加されたＳｅｑＮｏを伝える。コンプライアント（compliant）パーティは、受信されたＧＣのＳｅｑＮｏをある「新鮮さ」の速度に比較する必要がある。典型的に、この速度は有効番号（ＶＮ）であり、ＳｅｑＮｏ≧ＶＮをもつＧＣが有効な証明として許容され、ＳｅｑＮｏ＜ＶＮをもつＧＣが却下される。オンラインコネクションを介して、ディスクを介して、及び他のパーティとコンタクトすることのような、新たなＧＣ及びＶＮに遭遇するための幾つかのやり方がパーティにとって存在する。全てのコンプライアントパーティはＶＮをキャッシュし、おそらく最も高いＶＮがこれまで遭遇している。ＰＣと、少なくとも幾つかのたとえば光学装置のような典型的に低電力の周辺装置との間の処理能力における相違のため、ＧＣの記憶が異なって処理される。したがって、アプリケーションは、これまでに遭遇した最も高いＳｅｑＮｏをもつ完全なＧＣのセットをキャッシュし、かかる周辺装置はＧＣをキャッシュしない。

しかし、ＶＮの使用は、望まれない状況を生じない場合がある。たとえば、プレイバックの状況におけるＳｅｑＮｏとＶＮとの比較について考える。第一のアプローチとして、ドライブはそのＶＮレジスタでこれまで見られていない最も高いＳｅｑＮｏを常にキャッシュするとし、ドライブは、認証手順の間、プレイバックアプリケーションのＧＣがＳｅｑＮｏ≧ＶＮを有することを要求する。このＳｅｑＮｏｓ及びＶＮを使用するやり方は、たとえば、ＢＤ−ＲＯＭ（Ｂｌｕｅ−Ｒａｙ Ｄｉｓｃ ＲＯＭ）規格のオプションとして考えられる。次いで、以下に記載されるように、深刻なユーザの悩みがオフラインの状況で生じる。

ここで第二のアプローチにしたがってＳｅｑＮｏ−ＶＮの代替的な使用を考える。プレイバックのための認証手順の間、ドライブは、再生されるべきディスクを通して伝達されたＶＮを使用する。アプリケーションのＧＣは、ＳｅｑＮｏ≧ＶＮ_discを有する場合にのみ許容される。このアプローチは、よりユーザフレンドリなやり方である。

しかし、コンテンツオーナの観点で、第二のアプローチは深刻な問題点を有する。アプリケーション“Ａｐｐ”がハッキングされた場合、コンテンツを盗むハッカーのアプリケーション“Ｒｉｐ”を構築するため、その秘密鍵が使用され、次いで、コンテンツを盗むハッカーのアプリケーションは、インターネットにわたり配信される。ＣＡは、全ての将来のＷＬで許可されていないとしてＡｐｐを列挙することでＡｐｐを失効し、すなわち、Ａｐｐは、ＳｅｑＮｏ＝ＸをもつＧＣで許可されているが、ＳｅｑＮｏ＞Ｘをもつ全てのＧＣにおいて失効される。次いで、この失効にも拘らず、ＲｉｐはＶＮ_disc≦Ｘをもつ全てのディスクからコンテンツを盗むために使用される可能性がある。第一のアプローチでは、これは、ハッカーが彼のドライブを全ての新たなディスクから分離させる必要があるので非常に困難である。

再び第一のアプローチを考える。ラップトップ及びプレイバックソフトウェアＡｐｐをもつユーザは、新たなディスクを運ぶ。これは、ディスクがＡｐｐのＳｅｑＮｏよりも高いＶＮを有し、したがってＡｐｐが却下されることがわかる。次いで、ユーザは、（おそらく無料である）リプレースメントソフトウェアをダウンロードすることでＡｐｐをアップデートする必要がある。しかし、ラップトップオーナについてむしろ頻繁に起こる、ユーザがその瞬間でインターネットへのアクセスを有さない場合、アップデートが可能ではない。このことが生じる悩みに加えて、ラップトップのディスクドライブがディスクのＶＮをキャッシュしており、Ａｐｐが実行することができないので、ユーザは何れかの古いディスクを再生することができない。言い換えれば、ユーザがアップデートされたソフトウェアをダウンロードすることができるまで、常に動作するディスクは、動作するのを突然停止する。幾つかの他の、むしろ一般的な状況が存在し、この場合、ユーザがアプリケーションをアップデートすることができるまで、ソフトウェアアプリケーションの実行がブロックされるように、ドライブのＶＮが増加される。１つのかかる状況は、取り外し可能なディスクがドライブのＶＮよりも高いＳｅｑＮｏを有するアプリケーションと通信し、別のＰＣと対話する。別のかかる状況は、同じＰＣの多数のソフトウェアアプリケーションが同じドライバと通信するが、等しいペースを保持しない。

第一のアプローチは、ユーザのアプリケーションが失効されていないが動作を停止する状況となる場合でさえ、おそらく使用されるであろう。その後、ユーザの悩みを低減する開発についての需要が生じるであろう。

本発明の目的は、先に記載された従来技術よりも良好に、ユーザ及びコンテンツの所有者の両者の目的を果たす認証方法を提供することにある。

上記目的は、特許請求の範囲の請求項１に定義された方法に従って達成される。
したがって、本発明の第一の態様では、本発明は、認証が成功した条件で動作が実行される、ファーストパーティをセカンドパーティに認証するための認証方法を提供するものであり、ファーストパーティが認証されたかを確認するステップと、ファーストパーティが認証されなかった場合、サブの認証（sub-authorization）としてファーストパーティに権限を与え、ファーストパーティがサブ認証の権限を有する場合、動作がなお実行される。

認証されたとは、認証手順の間にチェックされた主要又はメインの基準の（１以上の）セットが準拠していることを意味する。ソフトウェアアプリケーション又は装置のようなファーストパーティが認証されない場合、条件付き動作が所定の条件下で実行される場合がある。それら所定の条件が合致した場合、サブ認証が与えられる。

これにより、本方法は、たとえば、従来の方法で却下された少なくとも幾つかのアプリケーションの使用を可能にする。サブ認証の条件の適切な選択により、先に記載されたオフラインのユーザの悩みが回避される。実現の例は、以下の実施の形態から明らかである。

請求項２で定義される、認証方法の実施の形態によれば、コンプライアンス証明書は、認証手順に含まれる。したがって、コンプライアントパーティのみが認証される。
請求項３で定義される、認証方法の実施の形態によれば、証明書に含まれる発行基準の日付は、認証手順にも含まれる。発行基準の日付は、証明書が発行された日付のような時間に関連する。たとえば、発行基準の日付は、シーケンス番号となり、新たな証明書が発行されるたびにインクリメントされる。

請求項４で定義される、認証方法の実施の形態によれば、サブ認証の権限付けは、比較結果に依存する。たとえば、比較基準の適切な選択により、１つの基準の使用は、許容される証明書の年齢を制御することである。

請求項６で定義される、認証方法の実施の形態によれば、許容される有効番号のレンジが定義される。このレンジは、レンジが既存の一連の番号の何れかの部分をカバーする場合があるという定義に含まれるとしても、上限及び下限を定義するために使用可能であり、サブ認証の権限を与える可能性を狭くする。

請求項７に定義される、認証方法の実施の形態によれば、最小の有効番号が定義される。発行基準の日付が最小の有効番号よりも低い場合、サブ認証の権限が与えられる。これは、余りに古い証明書を有するパーティにサブ認証の権限が与えられることを防止するために使用されることが好ましい。

請求項８で定義される、認証方法の実施の形態によれば、証明書に準拠しないが、ファーストパーティにはサブの許容度（sub-allowance）の権限が与えられる。しかし、発行基準の日付が十分に高い場合、すなわち証明書、結果的にノンコンプライアンスが十分に最近である場合に、サブ認証のみが与えられる。勿論、最大値が規定されないが、好ましくは比較的高く選択される。

請求項９及び１０で定義される、認証方法の実施の形態によれば、セカンドパーティの２つの異なる有効な番号、すなわち現在の番号及び前の番号がレンジの制限値として使用される。これにより、レンジをセカンドパーティの有効番号のアップデートに依存させることができる。

請求項１１で定義される、認証方法の実施の形態によれば、ファーストパーティ、及びもしあれば他のファーストパーティがサブ認証される回数を制御するためのグレースカウンタが使用される。請求項１２に定義されるように、実施の形態では、カウンタがファーストパーティにサブ認証の権限が与えられるたびにデクリメントされる。たとえば、これは、幾つかの時間ポイントで、カウンタを予め定義された数に設定するために使用し、カウンタがゼロに到達したときにサブ認証の権限を与えるのを停止する。ファーストパーティが認証又はサブ認証されるため、証明書を新しくする必要がある。

請求項１８で定義される、本発明の第二の態様によれば、本発明は、認証プロセスでパーティとして機能するために構成されるデジタル装置が提供され、認証プロセスに含まれるパーティのコンプライアンスを判定するためにコンプライアンス証明書が使用される。装置は、時間と関連付けされ、前記認証プロセスで使用される、比較手段を保持する第一のメモリエリア、及び装置により認証プロセスに含まれる他のパーティの制限されたリストを保持する第二のメモリエリア、及び、前記リストのパーティに関するコンプライアンス証明書を保持する第三のメモリエリアを有する。

この第二の態様によれば、本発明は、少なくとも少し古い証明書により遭遇される問題に関して、装置がオフラインであるとき、ユーザの悩みを著しく低減する。メモリが制限されるが、デジタル装置による認証手順で従事されるべきパーティに関する証明書がデジタル装置の比較の数で同時にアップデートされる可能性が高い。証明書がそのパーティにとってアクセス可能であるので、成功の認証手順の可能性は高い。この第二の態様の教示は第一の態様の教示との組み合わせで使用可能である。

本発明の第三の態様によれば、本発明は、ファーストパーティをセカンドパーティに認証する認証方法が提供され、ファーストパーティが認証されたかを確認するステップと、ファーストパーティが認証されなかった場合、ファーストパーティのアイデンティフィケーションを認証されていないファーストパーティのリストを保持するローカルストレージに入力するステップとを含み、前記確認するステップは、ファーストパーティがリストのメンバーであるかを確認するステップを含む。

この第三の態様によれば、ローカルに許可されていないパーティのある種の失効リストが保持され、このリストは、少なくとも第二のパーティについてアクセス可能である。したがって、本発明は、特にコンテンツ所有者の観点で有利である。かつてリストに入力されていたパーティは、コンテンツ又はコンテンツキャリアのタイプに関わらず使用可能ではない。たとえば、本発明の背景の下で先に記載された第二のアプローチの問題点が除かれる。

本発明のこれらの態様及び他の態様は、以下に記載される実施の形態を参照して明らかにされるであろう。本発明は、添付図面を参照して更に詳細に説明されるであろう。

ファーストパーティ及びセカンドパーティは、認証手順に関与されることとなり、認証が成功した場合に動作が実行されることになる。例示的な目的のため、本発明に係る方法の第一の実施の形態では、ファーストパーティはソフトウェアアプリケーションであり、セカンドパーティは装置であり、実行されるべき動作はコンテンツへのアクセスであることが想定される。より詳細には、アプリケーションがコンテンツにアクセスすることを望み、このアクセスは装置によって条件付きで承認されることが想定される。

コンテンツへのアクセスの認証の一部として、コンテンツに関連する利用権利の情報がアップデートされる必要がある場合がある。１回の再生の権利が削除される必要があるか、又はそのステータスを「無効“invalid”」又は「使用済み“used”」に設定させる場合がある。いわゆるチケットが使用される場合もある。チケットベースのアクセスに関する更なる情報について、米国特許第6,601,046号（代理人ドケットＰＨＡ２３６３６）を参照されたい。この使用権利のアップデートは、ファーストパーティ又はセカンドパーティにより行われる場合がある。

当業者により理解されるように、異なるタイプのパーティ及び異なるタイプの動作等の様々な組み合わせが存在し、これらは本発明の範囲により包含される。幾つかの例は、移動装置と固定装置との間、及びＰＣとネットワークにおけるサービスとの間の認証手順である。

ソフトウェアアプリケーションが装置により受信されたコンテンツユニットのコンテンツにアクセスするために使用されることとなるとき、かかるアクセスについてアプリケーションを許可するために認証手順が行われる。本実施の形態を説明するときに想定されるように、典型的な状況は、アプリケーションが、ディスクドライブにより構成される装置に入力される、ディスクにより構成されるコンテンツユニットに記憶されるコンテンツを再生するために使用される。本実施の形態の理解をエンハンスするため、図１及び図２に示されるシステムが考慮される。システムは、そこにインストールされるアプリケーション（Ａｐｐ）１０３を有するラップトップ１０１のようなコンピュータ、これに接続される取り外し可能なディスクドライブ１０５を有する。ディスク１０７は、ディスクドライブ１０５に挿入されようとしている。ドライブ１０５は、インタフェースバス１０９を介してコンピュータ１０１と通信し、ディスク１０７のコンテンツは、光学的リンク１１１を介してドライブ１０５に転送される。典型的に、ディスクのコンテンツは、光学的にスキャニングされ、光電気トランスデューサ１１３により電気信号に変換される。

ドライブ１０５は、グレースカウンタｋ１１５、現在の有効番号（Ｃｕｒｒ）レジスタ１１７、及び前の有効番号（ＰｒｅｖＶＮ）レジスタ１１９を有する。アプリケーションＡｐｐ１０３は、Ａｐｐ１０３のアプリケーション及び装置のグループのグループ証明書（ＧＣ）１２１であるコンプライアンス証明書を保持する。ＧＣ１２１は、シーケンス番号（ＳｅｑＮｏ）１２３である発行基準の日付を有し、その値は、ＧＣ１２１が生成された時間のポイントに依存する。ＣｕｒｒＶＮ及びＰｒｅｖＶＮレジスタ１１７，１１９のコンテンツは、以下に説明されるように、発行基準すなわちシーケンス番号の日付との比較のために使用される比較基準に含まれる。

ディスク１０７がドライブ１０５に挿入され、Ａｐｐ１０３がディスク１０７のコンテンツを再生するために使用されることが判定されたとき、認証手順が始動される。ディスク１０７は、ドライブ１０５に提供される有効番号ＶＮを有する。ＶＮはドライブ１０５のＣｕｒｒＶＮ１１７に比較される。一般に、ディスクが新しい場合、ＶＮ＞ＣｕｒｒＶＮである。次いで、ＣｕｒｒＶＮレジスタ１１７はＶＮでアップデートされ、ＧＣのセットはドライブ、及び／又はドライブ１０５がこれに搭載又は接続されるＰＣのような装置で記憶される。認証手順の一部として、Ａｐｐ１０３は、コンテンツへのアクセス用に使用されるために認証されていることをドライブ１０５に立証する必要がある。先に記載された基本的なケースでは、ＧＣ１２１のＳｅｑＮｏは、ＣｕｒｒＶＮに比較され、それらは等しいことが判定され、ＡｐｐがＡｐｐ１０３に関する新たなＧＣに従ってなお準拠することが判定され、結果的に、Ａｐｐ１０３が認証されることが確認される。したがって、Ａｐｐは、ディスク１０７のコンテンツにアクセスするのを許可される。

しかし、先のバックグランドに記載されるように幾つかの状況では、新たなＧＣのコピーを防止するドライブ１０５におけるメモリリソースがないことによるＣｕｒｒＶＮ及びＧＣのフルアップデートがなく、ＣｕｒｒＶｎは高いＶＮでアップデートされる。Ａｐｐが新たなＧＣに従ってもはや準拠しない場合、Ａｐｐは認証されない。

本方法によれば、特定の状況において、Ａｐｐは認証されないが、アクセスがなお許容される。このアプリケーションの目的について、これはサブ認証と呼ばれる。しかし、サブ認証は、まるで認証されたかのような同じ利点をアプリケーションに与えるので、認証のための基準が準拠していないが、幾つかの制限が時間及び番号に依存させてサブ認証の授与に関連付けされる。したがって、その値は時間的にそれらが生成されたときに依存するので、シーケンス番号及び有効番号は、時間に関連されるエレメントである。かかるように、それらは、以下に記載されるように猶予期間を決定するために使用することができる。グレースカウンタｋは番号エレメントであるが、カウンタが終了番号にまでカウントし、一般的に無限であるが、ある時間量が経過したときから、といったやり方で時間にも関連付けされる。これは、以下の説明から明らかである。

前記認証手順の第一ステップとして、ＳｅｑＮｏ１２３は、ＣｕｒｒＶＮ１１７に比較される。ＳｅｑＮｏ＞ＣｕｒｒＶＮである場合、ＣｕｒｒＶＮの値は、ＰｒｅｖＶＮに記憶され、ＳｅｑＮｏの値は、ＣｕｒｒＶＮに記憶され、グレースカウンタｋは、ｋ０に設定される。ここで、ｋ０は以下に説明されるように、サブ認証の下での予め定義された再生回数を示す。次いで、Ａｐｐが準拠すること、又は失効されていないことをＡｐｐのＧＣが示しているかがチェックされる。Ａｐｐが失効されていない場合、ドライブ１０５により、Ａｐｐが認証され、コンテンツへのアクセスすなわちプレイバックが許可されたことが判定される。他方で、Ａｐｐが失効した場合、サブ認証が授与される。次いで、再生が許容されるが、ｋ０回についてのみである。そのため、この認証の部分としてｋがデクリメントされる。すなわちｋ→ｋ−１である。

ＳｅｑＮｏ＜ＣｕｒｒＶｎである場合、次のステップでは、ＳｅｑＮｏ１２３がＰｒｅｖＶＮ１１９に比較される。ＳｅｑＮｏ＜ＰｒｅｖＶＮである場合、ＡＰＰ１０３はドライブ１０５に認証されない。したがって、ユーザは、ソフトウェアアプリケーションＡｐｐ１０３が十分に高いＳｅｑＮｏを担うＧＣを有する最近のバージョンにアップデートされるまで、コンテンツにアクセスすることができない。

ＳｅｑＮｏ１２３が有効番号のレンジに含まれる場合、すなわち、失効の状態に関わらずＰｒｅｖＶＮ≦ＳｅｑＮｏ＜ＣｕｒｒＶＮである場合、次のステップで、ｋ＞０であるかがチェックされる。ｋ＞０である場合、Ａｐｐはサブ認証の権限が与えられ、ｋはデクリメントされ、再生が許可される。ｋ＝０である場合、サブ認証の権限が与えられず、コンテンツへのアクセスが否定される。結果は、ＳｅｑＮｏ＝ＣｕｒｒＶＮの組み合わせについて同じであり、Ａｐｐ１０３は失効される。最後に、ＳｅｑＮｏ＝ＣｕｒｒＶＮである場合、Ａｐｐは失効されず、その後Ａｐｐは認証される。カウンタは変更されない。

ＰｒｅｖＶＮの値は、アプリケーションがどの位古いか、及びなお使用可能であるかを判定する。しかし、ＰｒｅｖＶＮは、新たなディスクを連続的に使用するユーザによる典型的なケースでＣｕｒｒＶＮの後ろにある１つの番号であるので、ただ新たなアプリケーションのみが役立つ。代替的な実施の形態では、レンジの最小の有効な番号は、ＰｒｅｖＶＮではなく、前の前の有効番号ＰｒｅｖＰｒｅｖＶＮであり、これは、ＣｕｒｒＶＮの１ステップの更に後ろにある。この実施の形態では、ＰｒｅｖＰｒｅｖＶＮは、ＰｒｅｖＶＮの代わりにＳｅｑＮｏとの比較のために使用される。利点は、非常に古いハッキングツールの使用を防止しつつ、ユーザが彼の慣れたプレイバックアプリケーションを猶予期間の間に使用し続ける可能性が高いことである。

別の代替の実施の形態では、ＰｒｅｖＶＮカウンタは存在しない。これは、ＰｒｅｖＶＮを永続的にゼロに固定することに対応する。この実施の形態では、ユーザが猶予期間の間に彼のなれたプレイバックアプリケーションを使用し続けることは絶対的に確かである。

本発明に係るデジタル装置の実施の形態では、デジタル装置３００は、典型的な光ドライブのようなロウリソースタイプの装置である。メモリキャパシティが余りに僅かであり、通常はキャッシュメモリに、ＧＣのコンプリートリストを記憶することができない。しかし、デジタル装置は、制限された量のメモリ３０１を有し、より詳細には、不揮発性のランダムアクセスメモリ（ＮＶＲＡＭ）を有し、これは幾つかのＧＣを保持可能である。さらに、ドライブ３００は、パーティ、すなわちアプリケーション又は装置のリストを保持し、これにより、ドライブは認証手順に従事する。好ましくは、このリストは、時間を通してずっと、ファーストインファーストアウト（ＦＩＦＯ）のリストであり、典型的に、全てのパーティの一部を含むことができる。図３に示されるように、ドライブ３００は、この実施の形態では有効番号ＶＮである比較手段を保持する第一のメモリエリア３０３、ＦＩＦＯを保持する第二のメモリエリア３０５、及び３０５でＦＩＦＯのパーティに関するＧＣを保持する第三のメモリエリア３０７を有する。

ドライブ３００がそのＶＮをアップデートするとき、第三のメモリエリア３０７にＦＩＦＯリストのパーティに関するＧＣをキャッシュする。先のように、ＦＩＦＯリストのパーティがドライブ３００との認証手順に従事するとき、対応するＧＣのＳｅｑＮｏは、ドライブ３００のＶＮと比較される。パーティが認証されるため、ＧＣに準拠するとして述べられる必要があり、ＳｅｑＮｏ≧ＶＮが満たされる場合がある。典型的に、パーティはＦＩＦＯリストにあり、そのＧＣはドライブ３００のＶＮと共にアップデートされるので、そのＳｅｑＮｏは十分に高い。しかし、パーティがＦＩＦＯリストにない場合、不成功の認証について増加された可能性が存在する。なお、この実施の形態の装置では、装置が始動又は従事する認証手順は、先に記載された実施の形態のいずれかにおける手順とすることができる。

本発明によれば、ファーストパーティとセカンドパーティとの間に認証手順が提供され、ファーストパーティが認証されたかが確認される。ファーストパーティが認証されない場合、ファーストパーティのアイデンティフィケーションが認証されていないファーストパーティのリストを保持するローカルストレージに入力され、このストレージは、セカンドパーティにアクセス可能である。確認は、コンプライアンスチェック、及びファーストパーティが非認証リストのメンバーであるかのチェックを含む。このローカルリストは、ローカルＢＬとして考えることができる。このローカルリストは、本実施の形態に従って設けられ、動作する装置は、図４にほぼ概念的に示される。光ディスクドライブのような装置４００は、有効番号ＶＮを保持する第一のメモリエリア４０３、及びローカルＢＬを保持する第二のメモリエリア４０５を有するメモリ４０１を有する。アプリケーションのようなファーストパーティがドライブ４００に認証できないときは何時でも、そのアイデンティフィケーション（ＩＤ）は、第二のメモリエリア４０５でローカルＢＬに記憶される。アプリケーションが、それが準拠していることを示す、ＳｅｑＮｏ≧ＶＮを含むＧＣを使用して、ドライブ４００を認証しようとするときは何時でも、ドライブは、アプリケーションがローカルＢＬで生じているかをチェックする。生じている場合、ドライブ４００は認証を中止し、さもなければ、アプリケーションが認証される。この実施の形態は、第一のメモリが揮発性であって、現在存在するディスクで利用可能なＶＮの値を取る場合に特に価値がある。

本方法は、本方法に係るステップを実行する実行可能なコード部分を有するコンピュータプログラムとして実現可能である。プログラムは、先に記載されたディスクドライブのような装置にロードされ、該装置により実行され、ソフトウェアアプリケーションの準拠を確認するルールを有する。

本発明は、ホームネットワークでの用途を発見する場合がある。典型的なホームネットワークは、たとえばラジオレシーバ、チューナ／デコーダ、ＣＤプレーヤ、一対のスピーカ、テレビジョン、ＶＣＲ、デジタルレコーダ、モバイルフォン、テープデッキ、パーソナルコンピュータ、パーソナルデジタルアシスタント、ポータブルディスプレイユニット等といった多数の装置を含む。これらの装置は、たとえばテレビジョンといった一方の装置がたとえばＶＣＲといった別の装置を制御するのを可能にするために通常は相互接続される。たとえばチューナ／デコーダ又はセットトップボックス（ＳＴＢ）のような一方の装置は、他方に対して中央の制御を提供する、通常はセントラル装置である。コンテンツは、音楽、歌、映画、ＴＶ番組、写真、ゲーム、本等のようなものを典型的に有し、インタラクティブなサービスを含む場合もあるが、一般家庭のゲートウェイ又はセットトップボックスを通して受信される。また、コンテンツは、ストレージメディアのようなディスクといった他のソースを介して、又はポータブル装置を使用して家庭に入る。

ホームネットワークは許可されたドメインとして動作する場合がある。（Ｔｈｏｍｓｏｎ社のＳｍａｒｔＲｉｇｈｔ、又はＤＴＬＡからのＤＴＣＰのような）この種類のコンテンツプロテクションシステムでは、装置のセットは、双方向のコネクションを通して互いに認証することができる。この認証に基づいて、装置は互いに信頼し、これにより、プロテクトされたコンテンツをやり取りするのを可能にする。コンテンツを伴うライセンスでは、どの権利をユーザが有し、どの動作を彼／彼女がコンテンツを実行するために許可されるかが記載される。

認可されたドメインの特定のアーキテクチャは、国際特許出願ＷＯ０３／０９８９３１（代理人ドケットＰＨＮＬ０２０４５５）、欧州特許出願シリアル番号０３１００７７２．７（代理人ＰＨＮＬ０３０２８３）、欧州特許出願シリアル番号０３１０２２８１．７（代理人ドケットＰＨＮＬ０３０９２６）、欧州特許出願シリアル番号０４１００９９７．８（代理人ドケットＰＨＮＬ０４０２８８）、並びに、Ｆ．Ｋａｍｐｅｒｍａｎ及びＷ．Ｊｏｎｋｅｒ， Ｐ．Ｌｅｎｏｉｒ及びＢ．ｖｄ Ｈｅｕｖｅｌ“Ｓｅｃｕｒｅ Ｃｏｎｔｅｎｔ Ｍａｎａｇｅｍｅｎｔ ｉｎ ａｕｔｈｏｒｉｚｅｄ ｄｏｍａｉｎｓ”Ｐｒｏｃ．ＩＢＣ２００２， Ｐａｇｅ４６７−４７５， Ｓｅｐｔ．２００２で概説されている。

なお、この出願の目的について、特に特許請求の範囲で、単語“ｃｏｍｐｒｉｓｅ”は他のステップ又はエレメントを排除するものではなく、単語“ａ”又は“ａｎ”は、複数を排除するものではなく、これらは本質的に当業者にとって明らかであろう。

幾つかの手段を列挙している装置の請求項では、これら手段の幾つかが同一アイテムのハードウェアにより実施することができる。所定の手段が相互に異なる従属の請求項で引用されることは、これらの手段の組み合わせを使用することができないことを示すものではない。

本発明に係る方法が利用されるシステムの鳥瞰図である。 実施の形態の方法が図１のシステムでどのように動作するかを説明するブロック図である。 本発明に係るデジタル装置の実施の形態の関連する部分のブロック図である。 認証方法の別の実施の形態を利用するために構成される、装置の実施の形態の関連する部分のブロック図である。

Claims (16)

1. ファーストパーティをセカンドパーティに対して認証する認証方法であって、
   前記セカンドパーティの確認手段が、前記ファーストパーティが認証されたか否かを確認するステップと、
   前記セカンドパーティの実行手段が、認証が成功した場合に動作を実行するステップと、
   前記セカンドパーティの設定手段が、グレースカウンタを予め定義された数に設定するステップと、
   前記セカンドパーティの権限授与手段が、前記ファーストパーティが認証されなかった場合、前記ファーストパーティがサブの認証について権限が与えられた回数と関連付けされた前記グレースカウンタの値に依存して、前記ファーストパーティにサブの認証について権限を与えるステップとを含み、前記ファーストパーティが前記サブの認証について権限が与えられた場合、前記グレースカウンタの値がデクリメントされ、前記動作がなお前記実行手段により実行される、
   ことを特徴とする方法。
2. 前記確認するステップは、
   前記ファーストパーティが該ファーストパーティに関するコンプライアンス証明書に従って準拠するか否かを確認するステップを含み、
   前記ファーストパーティは該ファーストパーティが準拠する場合にのみ認証される、
   請求項１記載の認証方法。
3. 前記確認するステップは、
   前記コンプライアンス証明書の発行の基準の日付を前記セカンドパーティの比較の基準と比較するステップを含み、
   前記ファーストパーティは、前記発行基準の日付が時代遅れでないことが前記比較により判定された場合にのみ認証される、
   請求項２記載の認証方法。
4. 前記ファーストパーティにサブ認証の権限を与えるステップは、前記発行基準の日付と比較基準との前記比較の結果に依存する、
   請求項３記載の認証方法。
5. 前記ファーストパーティにサブ認証の権限を与えるステップは、前記コンプライアンス証明書の発行基準の日付を前記セカンドパーティの比較基準と比較するステップの結果に依存する、
   請求項２記載の認証方法。
6. 前記比較基準は、許容される有効番号のレンジを含む、
   請求項４又は５記載の認証方法。
7. 前記ファーストパーティは、前記発行基準の日付が前記許容される有効番号のレンジのなかの最小の有効番号よりも小さい場合、前記サブ認証について権限が与えられない、
   請求項６記載の認証方法。
8. 前記ファーストパーティが準拠しないことを前記コンプライアンス証明書が示す場合、前記発行基準の日付が前記有効番号のレンジのうちの最大の有効番号よりも高いか又は等しい場合、前記ファーストパーティは、サブ認証について権限が与えられる、
   請求項６又は７記載の認証方法。
9. 前記許容される有効番号のレンジのうちの最大の有効番号は、前記セカンドパーティで記憶される現在の有効番号である、
   請求項６乃至８のいずれか記載の認証方法。
10. 前記許容される有効番号のレンジのうちの最小の有効番号は、前記セカンドパーティで記憶される前の有効番号である、
    請求項６乃至９のいずれか記載の認証方法。
11. 前記コンプライアンス証明書は、グループ証明書である、
    請求項２乃至１０のいずれか記載の認証方法。
12. 前記動作はコンテンツにアクセスすることを含む、
    請求項１乃至１１のいずれか記載の認証方法。
13. 前記コンテンツは光ディスクに記憶される、
    請求項１２記載の認証方法。
14. 前記ファーストパーティはソフトウェアアプリケーションであり、前記セカンドパーティは装置である、
    請求項１乃至１３のいずれか記載の認証方法。
15. 前記セカンドパーティは制限されたファーストパーティからなるリストを保持し、
    前記セカンドパーティで前記比較の基準を更新するステップと、
    前記更新と共に、前記セカンドパーティで、前記ファーストパーティからなるリストのファーストパーティに関するコンプライアンス証明書を含む更新されたコンプライアンス証明書のセットを記憶するステップと、
    を含む請求項２乃至１４のいずれか記載の認証方法。
16. ファーストパーティを認証する装置であって、
    前記ファーストパーティが認証されたか否かを確認する確認手段と、
    認証が成功した場合に動作を実行する実行手段と、
    グレースカウンタを予め定義された数に設定する設定手段と、
    前記ファーストパーティが認証されなかった場合、前記ファーストパーティがサブの認証について権限が与えられた回数と関連付けされた前記グレースカウンタの値に依存して、前記ファーストパーティにサブの認証について権限を与える権限授与手段とを備え、
    前記ファーストパーティが前記サブの認証について権限が与えられた場合、前記グレースカウンタの値がデクリメントされ、前記動作がなお前記実行手段により実行される、
    ことを特徴とする装置。

Images