ライセンス管理システムおよび方法
【課題】 ライセンス管理システムおよび方法を提供する。
【解決手段】 代理認証書発給方法はライセンスマネージャがライセンス発給権限の委任を受けるための要請メッセージをライセンスサーバに伝送する段階と、ライセンスサーバが要請メッセージを検証する段階と、要請メッセージが有効な場合にライセンスサーバがライセンス発給権限に対する情報を含む代理認証書をライセンスマネージャに伝送する段階、およびライセンスマネージャが代理認証書を検証する段階を含む。
【解決手段】 代理認証書発給方法はライセンスマネージャがライセンス発給権限の委任を受けるための要請メッセージをライセンスサーバに伝送する段階と、ライセンスサーバが要請メッセージを検証する段階と、要請メッセージが有効な場合にライセンスサーバがライセンス発給権限に対する情報を含む代理認証書をライセンスマネージャに伝送する段階、およびライセンスマネージャが代理認証書を検証する段階を含む。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はライセンス管理システムおよび方法に関するものであって、より詳細にデジタルコンテンツ（以下、コンテンツ）の内容によるデバイスの多様なアクセス権限制御および効率的なライセンス管理のためのライセンス管理システムおよび方法に関するものである。
【背景技術】
【０００２】
デジタル著作権管理（ＤＲＭ；Ｄｉｇｉｔａｌ Ｒｉｇｈｔｓ Ｍａｎａｇｅｍｅｎｔ）の基本概念はコンテンツを正常的に購入したユーザが該当コンテンツを使用できるようにするためのものである。初期システムはあるユーザを一つのデバイスにバインディングすることによって、専ら該当するデバイスのみが購入したコンテンツを使用できるという方向で開発されてきた。しかし、家電技術の発達とユビキタス環境の発展によってあるユーザが同一なコンテンツを幾つものデバイスで使用する必要性が台頭した。
【０００３】
これを支援するために生まれた概念が認証されたドメイン（ＡＤ；Ａｕｔｈｏｒｉｚｅｄ Ｄｏｍａｉｎ）であり、ＡＤ概念はＡＤに属したデバイス間では制約なしにコンテンツを共有することができるようにし、ＡＤに属しないデバイスではコンテンツ共有に制約が加えられる。このようなＡＤの代表的な例としてネットワーク環境を挙げることができる。ＡＤ概念を支援する代表的なＤＲＭシステムとしてはＴｈｏｍｓｏｎ社のＳｍａｒｔ Ｒｉｇｈｔシステム、Ｏｐｅｎ Ｍｏｂｉｌｅ Ａｌｌｉａｎｃｅ（ＯＭＡ） ＤＲＭ標準、そしてＩＢＭ社のｘＣＰなどを挙げることができる。
【０００４】
ＯＭＡ ＤＲＭやｘＣＰの場合は、以下図１のように中央ライセンスサーバが各々のすべてのドメインを直接管理する。すなわちデバイスが特定ドメインに加入しようとする場合は中央ライセンスサーバとの協商によって可能であり、特定ドメインに加入の許可を受けた場合にはライセンスサーバからそのドメインに対応するドメインキーの伝達をうけるようになる。以下より具体的に説明する。
【０００５】
図１および図２は従来の複数個のデバイスがネットワークを構成する例を示す。
【０００６】
図１は４個のデバイスＤ１、Ｄ２、Ｄ３、Ｄ４が一つのネットワーク（Ｈｏｍｅ＿Ａ）１２を構成する例を示す。
【０００７】
ネットワーク（Ｈｏｍｅ＿Ａ）１２はＡＤ＿１とＡＤ＿２という二つのドメインを構成しており、ＡＤ＿１の場合はＤ１、Ｄ２、Ｄ３、Ｄ４すなわち、ネットワーク内のすべてのデバイスを含みドメインキー（ＤＫ＿１）を共有している。ＡＤ＿２の場合はネットワークの一部デバイスのＤ３とＤ４のみを含みドメインキー（ＤＫ＿２）を共有している。ＡＤ＿１とＡＤ＿２を区分する理由はコンテンツの用途によって必要な時にアクセス制御をするためである。
【０００８】
一方、Ｓｍａｒｔ Ｒｉｇｈｔシステムの場合はＯＭＡ ＤＲＭやｘＣＰとは異なり中央ライセンスサーバ１０の助けなしでデバイス間に直接自身の認証されたドメインを構成する。
【０００９】
図２はデバイスＤ１、Ｄ２、Ｄ３、Ｄ４が一つのネットワーク（Ｈｏｍｅ＿Ｂ）１４を構成する例を示す。ネットワーク（Ｈｏｍｅ＿Ｂ）１４はデバイスＤ２、Ｄ３、Ｄ４で構成された一つのドメインＡＤ＿３を構成しており、ドメインキーＤＫ＿３を共有している。デバイスＤ１は外部コンテンツ供給者から自身だけが解読し得る形態で暗号化されたコンテンツを受信してＡＤ＿３内のデバイスが再生し得る形態でライセンスを再包装して供給する役割を担当する。このような過程でＤ１はＡＤ＿３のドメインキー（ＤＫ＿３）を知らないためＡＤ＿３内のデバイスの助けを必要とする。
【００１０】
しかし、既存のＤＲＭシステムの認証されたドメイン管理方法には次のような問題点が存在する。
【００１１】
まずドメイン管理の観点からみれば、ＯＭＡ ＤＲＭやｘＣＰように中央ライセンスサーバによるドメイン管理方法は中央のライセンスサーバが各々のすべてのドメインを管理しなければならないため、ライセンスサーバに管理負担を与えることがあり、またユーザの立場から見れば自身のドメインに登録されたすべてのデバイスに関する情報を中央のライセンスサーバが知り得るため自身のドメインに対するプライバシー侵害問題が発生し得る。
【００１２】
一方、コンテンツ管理の観点からみれば、基本的に一つのドメインは一つのドメインキーでバインディングされているため各デバイスに対してコンテンツによる柔軟なアクセス権限制御が難しい。ＯＭＡ ＤＲＭやｘＣＰの場合は一つのネットワークに幾個かのＡＤを許容する方式で部分的に解決しているが、精巧なアクセス権限制御は提供するのが難しく、これは中央ライセンスサーバの管理負担を増大させる。そして、Ｓｍａｒｔ Ｒｉｇｈｔシステムの場合は個別デバイスのアクセス権限を制御する機能を提供しない。
【特許文献１】日本特許公開第2005-242543号公報
【特許文献２】韓国特許公開第2004-105684号公報
【特許文献３】韓国特許公開第2005-101940号公報
【特許文献４】韓国特許公開第2006-122676号公報
【発明の開示】
【発明が解決しようとする課題】
【００１３】
本発明はライセンス管理システムおよび方法を提供し、デジタルコンテンツの内容によるデバイスの多様なアクセス権限制御および効率的なライセンス管理を提供することにその目的がある。
【００１４】
本発明の目的は以上で言及した目的に制限されず、言及されていないまた他の目的は次の記載から当業者に明確に理解できるであろう。
【課題を解決するための手段】
【００１５】
前記目的を達成するために、本発明の実施形態による代理認証書発給方法はライセンスマネージャがライセンス発給権限の委任を受けるための要請メッセージをライセンスサーバに伝送する段階と、ライセンスサーバが要請メッセージを検証する段階と、要請メッセージが有効な場合にライセンスサーバがライセンス発給権限に対する情報を含む代理認証書をライセンスマネージャに伝送する段階、およびライセンスマネージャが代理認証書を検証する段階を含む。
【００１６】
本発明の実施形態による代理認証書更新方法は、ライセンスマネージャがライセンス発給権限に対する情報を含む代理認証書に対する更新要請メッセージをライセンスサーバに伝送する段階と、ライセンスサーバが更新要請メッセージを検証する段階と、更新要請メッセージが有効な場合にライセンスサーバがＯＣＳＰ（Ｏｎｌｉｎｅ Ｃｅｒｔｉｆｉｃａｔｅ Ｓｔａｔｕｓ Ｐｒｏｔｏｃｏｌ）サーバに代理認証書の有効の可否を質疑する段階、およびライセンスサーバがＯＣＳＰから代理認証書が有効だという応答を受けた場合、新しい代理認証書をライセンスマネージャに伝送する段階を含む。
【００１７】
本発明の実施形態による代理認証書の有効性検証方法はデバイスが代理認証書の有効性検証のための要請メッセージをライセンスマネージャに伝送する段階と、ライセンスマネージャが要請メッセージをＯＣＳＰ（Ｏｎｌｉｎｅ Ｃｅｒｔｉｆｉｃａｔｅ Ｓｔａｔｕｓ Ｐｒｏｔｏｃｏｌ）サーバに伝送する段階と、ＯＣＳＰサーバが代理認証書の有効性検証結果に対する応答メッセージをライセンスマネージャに伝送する段階、およびライセンスマネージャがデバイスに応答メッセージを伝送する段階を含む。
【００１８】
本発明の実施形態によるライセンスマネージャはライセンス発給権限に対する情報を含む代理認証書を要請するための第１要請メッセージまたは代理認証書の更新を要請するための第２要請メッセージを生成する第１生成部および第１要請メッセージによってライセンスサーバから受信した代理認証書を検証したり第２要請メッセージによってライセンスサーバから受信した新しい代理認証書を検証する第１検証部を含む。
【００１９】
本発明の実施形態によるライセンスサーバは、ライセンスマネージャから受信したライセンス発給権限に対する情報を含む代理認証書に対する第１要請メッセージまたは代理認証書の更新のため第２要請メッセージを検証する第２検証部および第１要請メッセージが有効な場合に代理認証書を生成したり第２要請メッセージが有効な場合に新しい代理認証書を生成する第２生成部を含む。
【００２０】
その他実施形態の具体的な事項は詳細な説明および図に含まれている。
【００２１】
本発明の利点および特徴、そしてそれらを達成する方法は添付される図面と共に詳細に後述されている実施形態を参照すれば明確になるだろう。しかし本発明は以下で開示される実施形態に限定されるものではなく互いに異なる多様な形態で具現されることができ、単に本実施形態は本発明の開示が完全なようにして、本発明が属する技術分野で通常の知識を有する者に発明の範疇を完全に知らせるために提供されるものであり、本発明は請求項の範囲によってのみ定義される。明細書全体にかけて同一参照符号は同一構成要素を指称する。
【００２２】
以下、添付された図面を参照し、本発明の好ましい実施形態を詳細に説明する。
【００２３】
図３は本発明の一実施形態によるライセンスサーバ（ＬＳ；Ｌｉｃｅｎｓｅ Ｓｅｒｖｅｒ）がライセンスマネージャ（ＬＬＭ；Ｌｏｃａｌ Ｌｉｃｅｎｓｅ Ｍａｎａｇｅｒ）にライセンス発給権限を委任する過程を示す。そして、図４は本発明の一実施形態による代理委任要請メッセージの様式の例を図示する。以下、図３および図４に基づきより具体的に説明する。
【００２４】
図３において、本実施形態の基盤となる代理権限委任方式はＸ．５０９代理認証書標準のためＲＦＣ ３８２０、「Ｉｎｔｅｒｎｅｔ Ｘ．５０９ ＰＫＩ Ｐｒｏｘｙ Ｃｅｒｔｉｆｉｃａｔｅ Ｐｒｏｆｉｌｅ」にある認証書による委任方式（ｄｅｌｅｇａｔｉｏｎ ｂｙ ｃｅｒｔｉｆｉｃａｔｅ）のうち所持者代理（ｂｅａｒｅｒ−ｐｒｏｘｙ）方式を応用することができる。具体的な委任手続は次のとおり。
【００２５】
まず、ライセンスマネージャ３１０は代理署名生成と検証に使用される代理個人キー（ＳＫ＿Ｐｒｏｘｙ）、および代理公開キー（ＰＫ＿Ｐｒｏｘｙ）を生成する。
【００２６】
ライセンスマネージャ３１０は図４のような構造を有する代理委任要請メッセージ（ＰｒｏｘｙＲｅｑ＿ＬＬＭ）４００を生成する。代理委任要請メッセージ４００は自身の身元（ｓｕｂｊｅｃｔ）と代理公開キー（ＰＫ＿Ｐｒｏｘｙ）などの情報を含み、ネットワークでライセンスの代理生成に関する規則（例えば、権限期間、ライセンス個数、発給対象など）を明示することができる。また、代理委任要請メッセージ４００は代理公開キー（ＰＫ＿Ｐｒｏｘｙ）を代理個人キー（ＳＫ＿Ｐｒｏｘｙ）で署名し、得られた署名値（ＳＩＧ＿Ｐｒｏｘｙ）４０２を含み得る。ここで署名値（ＳＩＧ＿Ｐｒｏｘｙ）４０２を含む理由は代理公開キーに対応される代理個人キーを自身が所有していることを証明するためである。
【００２７】
このような代理委任要請メッセージ４００の内容はライセンスマネージャ３１０の個人キー（ＳＫ＿ＬＬＭ）で改めて署名され、ライセンスマネージャ３１０は署名値（ＳＩＧ＿ＬＬＭ）４０４が添付された代理委任要請メッセージ４００をライセンスサーバ３００に伝送する（Ｓ３０１）。
【００２８】
次に、ライセンスサーバ３００は受信した前記代理委任要請メッセージ４００を検証する（Ｓ３１１）。すなわち、ライセンスサーバ３００はライセンスマネージャ３１０の公開キー（ＰＫ＿ＬＬＭ）として署名値（ＳＩＧ＿ＬＬＭ）４０４が有効なのか検証した次に、代理委任要請メッセージ４００に含まれている代理公開キー（ＰＫ＿Ｐｒｏｘｙ）を利用して署名値（ＳＩＧ＿Ｐｒｏｘｙ）４０２を検証する。
【００２９】
次に代理委任要請メッセージ４００が有効ならば、ライセンスサーバ３００はライセンスマネージャ３１０の身元と代理公開キー（ＰＫ＿Ｐｒｏｘｙ）をバインディングして、デバイスに対してライセンスを発給できる権限を付与するために以下図５のような代理認証書（Ｃｅｒｔ＿Ｐｒｏｘｙ）５００を生成する。図５は本発明の一実施形態による代理認証書５００の様式の例を図示する。代理認証書５００は権利発給者（Ｉｓｓｕｅｒ）、身元（ｓｕｂｊｅｃｔ）、一連番号（ｓｅｒｉａｌ ｎｕｍｂｅｒ）、代理公開キー、有効期間（ｖａｌｉｄｉｔｙ ｐｅｒｉｏｄ）、および委任情報（ＰｒｏｘｙＣｅｒｔＩｎｆｏ）を含み得る。委任情報は権利発給者がライセンスマネージャ３１０に権限を委任する具体的な情報を含む。具体的にライセンス発給回数、権限再委任の可能の可否などの情報が委任情報に含まれ、該当情報はライセンスマネージャ３１０内の所定モジュールが判読するようになる。
【００３０】
委任された権限の内容と制約事項はＸＭＬ基盤の権限技術言語を使用し記述されることがあり、代理認証書５００の拡張フィールドのうち所定フィールド（ＰｒｏｘｙＣｅｒｔＩｎｆｏ）に含まれ得る。このように生成された代理認証書はライセンスサーバ３００の個人キー（ＳＫ＿ＬＳ）に署名され署名値（ＳＩＧ＿ＬＳ）（５０２）が添付された後にライセンスマネージャ３１０に伝送される（Ｓ３２１）。
【００３１】
次に、ライセンスマネージャ３１０は受信された代理認証書５００の署名値（ＳＩＧ＿ＬＳ）（５０２）をライセンスサーバ３００の公開キー（ＰＫ＿ＬＳ）で検証する（Ｓ３３１）。署名が有効な場合には代理秘密キー（ＳＫ＿Ｐｒｏｘｙ）を利用して代理認証書５００に記述された権限内でデバイスにライセンスを発給することができるようになる。
【００３２】
ライセンスマネージャ３１０がコンテンツをデバイスに代わり購入するようになればライセンスサーバ３００はコンテンツ暗号化キーと該当コンテンツの利用に関する権利、制約条件、有効消費期間などが明示されたライセンスをライセンスマネージャ３１０に発給する。ライセンスマネージャ３１０は自身が受けたライセンスに基づきデバイスがコンテンツを再生できるよう委任を受けた権限すなわち、代理個人キー（ＳＫ＿Ｐｒｏｘｙ）を利用してライセンスを再包装した後に発給する。
【００３３】
代理認証書５００は有効期間が満了したりライセンス発給回数が超過すると効力が中止される。したがってライセンスマネージャ３１０は委任された権限を継続して維持するためには代理認証書５００の有効期間が満了する前の特定期間中に代理認証書を更新しなければならない。しかし長時間ネットワーク連結が円滑でなかったり、またはその他事情によって有効期間満了前に更新をできない場合でもそれ以後に代理認証書は更新される。このような手続はすべて自動でなされ得る。
【００３４】
図６は本発明の一実施形態による代理認証書の更新過程を図示する。そして、図７は本発明の一実施形態による代理認証書の更新要請メッセージ７００の様式の例を図示する。以下図６および図７に基づきより具体的に説明する。
【００３５】
ライセンスマネージャ３１０は図７のような構造を有する代理認証書の更新要請メッセージ（ＰｒｏｘｙＲｅｎｅｗＲｅｑ＿ＬＬＭ）７００を生成する。代理認証書の更新要請メッセージ７００は自身の身元と代理認証書の一連番号などの情報を含むことができ、このようなメッセージ内容はライセンスマネージャ３１０の個人キー（ＳＫ＿ＬＬＭ）で署名され前記図５の代理認証書と一緒にライセンスサーバ３００に伝送され得る（Ｓ６０１）。
【００３６】
ライセンスサーバ３００は伝達された代理認証書の更新要請メッセージ７００を検証する（Ｓ６１１）。すなわち、ライセンスサーバ３００はライセンスマネージャ３１０の公開キー（ＰＫ＿ＬＬＭ）を利用して署名値（ＳＩＧ＿ＬＬＭ）（４０４−１）を検証する過程を経るようになる。
【００３７】
ライセンスサーバ３００は署名値（ＳＩＧ＿ＬＬＭ）（４０４−１）が有効な場合に代理認証書の一連番号を利用してＯＣＳＰプロトコルによってＯＣＳＰサーバ３２０に代理認証書の有効の可否を質疑する（Ｓ６２１）。
【００３８】
そして、ライセンスサーバ３００は質疑した結果をＯＣＳＰサーバ３２０から受信する（Ｓ６３１）。前段階（Ｓ６２１）はライセンスサーバ３００が管理するＣＲＬ（Ｃｅｒｔｉｆｉｃａｔｅ Ｒｅｖｏｃａｔｉｏｎ Ｌｉｓｔ）を参照する方式で代替され得る。
【００３９】
ライセンスサーバ３００は前段階（Ｓ６３１）で受けた代理認証書の状態結果が有効な場合に、段階（Ｓ６０１）から伝達された代理認証書の有効期間またはライセンスの発給可能な回数などを再設定した後、自身の個人キー（ＳＫ＿ＬＳ）で再署名して、新しい代理認証書を作った後、ライセンスマネージャ３１０に伝送する（Ｓ６４１）。
【００４０】
ライセンスマネージャ３１０は伝送された新しい代理認証書の署名値（ＳＩＧ＿ＬＳ）をライセンスサーバ３００の公開キー（ＰＫ＿ＬＳ）で検証する（Ｓ６５１）。検証が有効な場合にライセンスマネージャ３１０は既存の代理認証書は削除して新しい代理認証書で代替する。
【００４１】
このような方式の更新メカニズムは代理公開キーを変更せずとも有効期間だけを延長する効果を招くためシステムの透明性を増進させることができる。一方、本実施形態の更新メカニズムは既存の代理認証書は廃棄させないため一時的に二個の有効な代理認証書が存在し得るが既存の代理認証書はいくらも残っていない有効期間が過ぎれば無効化（廃棄）されるためシステムの安全性には問題とならない。
【００４２】
代理認証書の有効期間すなわち、更新周期を決定する政策はシステムの効率性とシステムの安全性が相反関係にあるため運用戦略によって適切に選択しなければならない。有効期間を短く設定すればハッキングまたはその他、他の理由によるライセンスマネージャの権限不正乱用を早期に中断することができる反面、頻繁に代理認証書を更新しなければならないため全体システムの性能低下を誘発し得る。有効期間を長く設定すれば反対の効果が発生する。したがってシステムの性能がシステムの安全性より優先視されれば有効期間を比較的長く設定するのが有利であり、システムの安全性がさらに重要ならば有効期間を比較的短くする戦略が有利である。例えば、現在公認認証書の有効期間が１年である点を考慮すれば、代理認証書の有効期間は１月以内とするのが適切であろう。
【００４３】
一方、ライセンスマネージャ３１０に付与した権限を解約するためにも、または攻撃によって、ライセンスマネージャ３１０が権限を不正乱用したことが感知された場合、ライセンスサーバ３００は自身が付与した代理認証書をＯＣＳＰサーバ３２０に廃棄登録しなければならない。このような手続はライセンスサーバ３００によって、遂行され、後述される図８の段階（Ｓ１００）のようなＯＣＳＰプロトコルの廃棄認証書登録過程を通してＯＣＳＰサーバ３２０に登録される。廃棄認証書登録過程は従来の技術文書を参照していただきたい。
【００４４】
図８は本発明の一実施形態による代理認証書の有効性検証過程の一例を示す。
【００４５】
デバイス（Ｄ１、Ｄ２、…）がコンテンツを再生するためにはコンテンツとこれに対応するライセンスが必要である。ライセンスはライセンスマネージャ３１０が代理権限を利用して発給したものであるためコンテンツを再生する前にその代理権限が有効なのかを検証しなければならない。このためにはＯＣＳＰサーバ３２０への質疑によって代理認証書の有効性の有無を検証するのが好ましい。しかしすべてのデバイスが外部のＯＣＳＰサーバ３２０と直接連結し得る能力を備えていると仮定することができないため、この様な場合はＯＣＳＰとの通信方法を有しているライセンスマネージャ３１０を通して、代理認証書の有効性の有無を検証する作業を遂行することができる。ここで、伝送途中に当事者であるライセンスマネージャ３１０から検査結果値が操作されることがあり、これに対する補完策が用意されなければならない。これは次の過程によって、達成され得る。
【００４６】
デバイス（Ｄ２）は自身の身元と自身の公開キー（ＰＫ＿Ｄ２）、ライセンスマネージャ３１０の代理認証書の一連番号、タイムスタンプ、ノンス等の情報を含んだ代理認証書の有効性検証のための要請メッセージを生成した次に自身の署名（ＳＩＧ＿Ｄ２）を貼付してライセンスマネージャ３１０に伝送する（Ｓ８０１）。タイムスタンプ（ｔｉｍｅ ｓｔａｍｐ）、ノンス（ｎｏｎｃｅ）などの情報は要請メッセージに対するリプレイ（ｒｅｐｌａｙ）攻撃を防ぐために使用される。ここで、デバイス（Ｄ２）は前記のような作業に使用する個人キー（ＳＫ＿Ｄ２）と公開キー（ＰＫ＿Ｄ２）を安全に保存していなければならない。
【００４７】
ライセンスマネージャ３１０は代理認証書の有効性の有無を検証するためにデバイス（Ｄ２）から受信した要請メッセージをＯＣＳＰサーバ３２０に伝達する（Ｓ８１１）。
【００４８】
ＯＣＳＰサーバ３２０は受信した要請メッセージに含まれたデバイスの署名の有効性の可否をデバイス（Ｄ２）の公開キー（ＰＫ＿Ｄ２）で検証し、署名が有効な場合に要請メッセージに含まれた代理認証書の一連番号に対応する認証書の状態を確認する。そして、代理認証書の有効性検証結果に対する応答メッセージを自身の秘密キー（ＳＫ＿ＯＣＳＰ）で署名して、デバイス（Ｄ２）の公開キーで暗号化し、ライセンスマネージャ３１０に伝送する（Ｓ８２１）。
【００４９】
ライセンスマネージャ３１０は受信した応答メッセージをデバイス（Ｄ２）に伝達する（Ｓ８３１）。
【００５０】
デバイス（Ｄ２）はＯＣＳＰの公開キー（ＰＫ＿ＯＣＳＰ）で受信した応答メッセージの署名を検証した後、署名が有効な場合ににはその結果を参照する（Ｓ８４１）。その結果が有効な場合にすなわち、代理認証書が有効な場合にデバイスは該当ライセンスでコンテンツを再生し、そうではない場合には代理認証書とライセンスをメモリから削除して有効でないライセンスであるということをディスプレイに表示しユーザに通報しコンテンツは再生しない。
【００５１】
前記過程で伝送される要請メッセージおよび応答メッセージは暗号化され署名が添付されているため中間でライセンスマネージャが任意に操作できる可能性を防止することができる。
【００５２】
また、攻撃によって、ライセンスマネージャが前記のような有効性検証過程を遂行しない場合、デバイスは適切な応答を受信することができないことでライセンスマネージャ３１０が攻撃され、有効でないを推論することができる。
【００５３】
図９は本発明の一実施形態によるライセンス管理のためのシステム構成図の例を図示する。
【００５４】
前述した内容に基づいて、本発明のシステムはコンテンツ提供者を構成するライセンスサーバ３００とコンテンツサーバ（ＣＳ；Ｃｏｎｔｅｎｔｓ Ｓｅｒｖｅｒ）３０３、ユーザ側のネットワークを構成するライセンスマネージャ３１０とメディアサーバ（ＬＭＳ；Ｌｏｃａｌ Ｍｅｄｉａ Ｓｅｒｖｅｒ）３０５、ＯＣＳＰサーバ３２０を含み得る。
【００５５】
コンテンツサーバ３０３はコンテンツに対する知的財産権を所有しているコンテンツ提供者が運営するサーバであって、コンテンツに対する一次的な配布を遂行することができ、ライセンスサーバ３００はコンテンツ購買者に対して適法な使用権限を明示したライセンスを発給する役割を遂行することができる。この二つのサーバ３０３、３００は概念的に分離されているが実際の運営のために同一の物理的装置で動作し得る。すなわち、前述されたようにライセンスサーバ３００がコンテンツサーバ３０３の機能を含み得る。
【００５６】
コンテンツサーバ３０３はコンテンツをＤＲＭのような方法によって暗号化するなどの安全に包装したコンテンツをネットワーク内のメディアサーバ３０５に伝送する役割を遂行することができる。
【００５７】
ライセンスサーバ３００は前述したように購入したコンテンツに対して購買条件に合うアクセス権限を付与したライセンスを生成する。前記ライセンスには該当コンテンツがデバイスでどのように消費されなければならないのか記述されている。
【００５８】
前述された実施例でデバイス（Ｄ１、Ｄ２．．）はライセンスサーバ３００を通して直接ライセンスの発給を受けずネットワーク上でコンテンツを再生することができ、該当ドメインを管理するライセンスマネージャ３１０を通して自体的にライセンスが発給されデバイスに提供され得る。
【００５９】
すなわち、ライセンスマネージャ３１０は自身が属したネットワークを代表してデバイスに対してライセンスを発給することができる権限をライセンスサーバ３００から委任を受ける。
【００６０】
一方、ＯＣＳＰサーバ３２０は個体認証書や代理認証書の有効性の可否の質疑を受け、認証書の現状態を答弁する役割を担当する。応答メッセージにはＯＣＳＰの署名が添付される。
【００６１】
各個体は自分だけの個人キー（ＳＫ）、公開キー（ＰＫ）を有しており、また自身の公開キー認証のための信頼された認証機関（ＣＡ）が発給した個体認証書を含み得る。また、二つの個体が通信を望む時はまずＰＫＩ基盤の相互認証を遂行することができる。その他にユーザデバイスは適法なライセンスに明示された権限内でコンテンツを再生することができる信頼するだけのエージェントによって統制を受けることができる。
【００６２】
図１０は本発明の一実施形態によるライセンスマネージャのブロック図である。
【００６３】
ライセンスマネージャ３１０は第１生成部３１３、第１検証部３１５、更新部３１７、および発給部３１９を含む。
【００６４】
第１生成部３１３はライセンス発給権限に対する情報を含む代理認証書に対する要請メッセージを生成する。すなわち、ライセンスマネージャは代理認証書によってライセンス発給権限の委任を受けることができる。また、第１生成部３１３は代理署名生成と検証に使用される代理個人キー（ＳＫ＿Ｐｒｏｘｙ）、および代理公開キー（ＰＫ＿Ｐｒｏｘｙ）を生成することができる。要請メッセージは代理公開キー（ＰＫ＿Ｐｒｏｘｙ）を代理個人キー（ＳＫ＿Ｐｒｏｘｙ）で署名して得られた署名値（ＳＩＧ＿Ｐｒｏｘｙ）を含み得る。また、第１生成部３１３は代理認証書に対する更新要請メッセージを生成することができる。更新要請メッセージはライセンスマネージャの身元と代理認証書の一連番号などの情報を含むことができ、ライセンスマネージャの個人キー（ＳＫ＿ＬＬＭ）で署名され代理認証書と一緒にライセンスサーバに伝送され得る。
【００６５】
第１検証部３１５はライセンスサーバから受信したライセンス発給権限に対する情報を含む代理認証書を検証する。ここで、第１検証部３１５は代理認証書の署名値（ＳＩＧ＿ＬＳ）をライセンスサーバの公開キー（ＰＫ＿ＬＳ）で検証することができる。また、署名が有効な場合にには代理秘密キー（ＳＫ＿Ｐｒｏｘｙ）を利用して代理認証書に記述されたライセンス発給権限内でデバイスに後述される発給部（３１９）を通して、ライセンスを発給することができる。また、第１検証部３１５は新しい代理認証書を受信した場合、新しい認証書の署名値（ＳＩＧ＿ＬＳ）をライセンスサーバの公開キー（ＰＫ＿ＬＳ）で検証して検証が有効な場合に後述される更新部（３１７）は通じて既存の代理認証書は削除し、新しい代理認証書に代替され得る。
【００６６】
更新部３１７はライセンスサーバから新しい代理認証書を受信した場合、既存の代理認証書を新しい代理認証書として代替する。ここで、更新部（３１７）はまだ既存の代理認証書の有効期間が残っている場合、自動で有効期間が満了すれば既存の代理認証書を廃棄して新しい代理認証書に代替し得る。
【００６７】
発給部３１９は代理認証書に記述されたライセンス発給権限内でデバイスにコンテンツ利用のためのライセンスを発給する。
【００６８】
図１１は本発明の一実施形態によるライセンスサーバのブロック図である。
【００６９】
ライセンスサーバ３００は第２検証部３１６、および第２生成部３１８を含む。
【００７０】
第２検証部３１６はライセンスマネージャが伝送したライセンス発給権限の委任を受けるための要請メッセージを検証する。ここで、第２検証部３１６はライセンスマネージャの公開キー（ＰＫ＿ＬＬＭ）を利用して要請メッセージに含まれた署名値（ＳＩＧ＿ＬＬＭ）の有効性の可否を検証し、要請メッセージに含まれている代理公開キー（ＰＫ＿Ｐｒｏｘｙ）を利用して署名値（ＳＩＧ＿Ｐｒｏｘｙ）を検証することができる。また、第２検証部３１６はライセンスマネージャが伝送した代理認証書に対する更新要請メッセージを検証することができる。ここで、第２検証部３１６はライセンスマネージャの公開キー（ＰＫ＿ＬＬＭ）を利用して署名値（ＳＩＧ＿ＬＬＭ）を検証することができる。そして、第２検証部３１６は更新要請メッセージが有効な場合にライセンスサーバがＯＣＳＰサーバに前記代理認証書の有効の可否を質疑することができ、その結果に対する応答メッセージを受信することができる。
【００７１】
第２生成部３１８は要請メッセージが有効な場合にライセンス発給権限に対する情報を含む代理認証書を生成する。ここで、第２生成部３１８はライセンスマネージャの身元と代理公開キー（ＰＫ＿Ｐｒｏｘｙ）をバインディングした代理認証書を生成することができる。代理認証書は権利発給者、身元、一連番号、代理公開キー、有効期間、および委任情報のうち少なくとも一つを含み得る。ここで、代理認証書はライセンスサーバの個人キー（ＳＫ＿ＬＳ）に署名され署名値（ＳＩＧ＿ＬＳ）が添付された後、ライセンスマネージャに伝送され得る。また、第２生成部３１８は前述されたＯＣＳＰから代理認証書が有効だという応答を受けた場合、新しい代理認証書を生成し、ライセンスマネージャに伝送し得る。新しい代理認証書には代理認証書の有効期間およびライセンスの発給可能な回数に対する情報のうち少なくとも一つを含むことができ、ライセンスサーバの個人キー（ＳＫ＿ＬＳ）で再署名され得る。
【００７２】
図１２は本発明の一実施形態による代理認証書の有効性検証装置のブロック図である。
【００７３】
代理認証書の有効性検証装置１００は第３生成部１０３、第３検証部１０５および再生部１０７を含み、所定デバイス内に具現され得る。
【００７４】
第３生成部１０３はライセンスマネージャの代理認証書の一連番号、タイムスタンプ、ノンス等の情報を含んだ代理認証書の有効性検証のための要請メッセージを生成し、自身の公開キー（ＰＫ＿Ｄ２）で暗号化した後、自身の署名（ＳＩＧ＿Ｄ２）を貼付する。タイムスタンプ、ノンスなどの情報は要請メッセージに対するリプレイ攻撃を防ぐために使用され得る。
【００７５】
第３検証部１０５はＯＣＳＰの公開キー（ＰＫ＿ＯＣＳＰ）でＯＣＳＰから受信した応答メッセージの署名を検証した後、署名が有効な場合ににはその結果を参照する。その結果によって代理認証書が有効な場合にライセンスマネージャから発給を受けたライセンスで後述される再生部によってコンテンツを再生する。
【００７６】
再生部１０７は前述されたように代理認証書が有効な場合にコンテンツを再生する。もしその反対の場合、再生部は代理認証書とライセンスをメモリから削除することができる。
【００７７】
図１０、図１１および図１２で図示された各々の構成要素は一種の「モジュール」で構成され得る。前記「モジュール」はソフトウェアまたはＦｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ（ＦＰＧＡ）または注文型半導体（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ、ＡＳＩＣ）のようなハードウェア構成要素を意味し、モジュールはある役割を遂行する。しかしモジュールはソフトウェアまたはハードウェアに限定される意味ではない。モジュールはアドレッシングできる保存媒体に存在するように構成され得るがまたはそれ以上のプロセッサを実行させるように構成され得る。したがって、一例としてモジュールはソフトウェア構成要素、オブジェクト指向ソフトウェア構成要素、クラス構成要素およびタスク構成要素のような構成要素と、プロセス、関数、属性、プロシーザ、サブルーチン、プログラムコードのセグメント、ドライバ、ファームウェア、マイクロコード、回路、データ、データベース、データ構造、テーブル、アレイ、および変数を含む。構成要素とモジュールで提供されている機能はさらに小さい数の構成要素およびモジュールに結合したり追加的な構成要素とモジュールにさらに分離することができる。
【００７８】
以上添付された図面を参照し本発明の実施形態を説明したが、本発明が属する技術分野で通常の知識を有する者は本発明がその技術的思想や必須の特徴を変更せず、他の具体的な形態で実施され得るということを理解するはずである。そのため以上で記述した実施形態はすべての面で例示的なものであり、限定的ではないものと理解しなければならない。
【発明の効果】
【００７９】
前記したような本発明のライセンス管理システムおよび方法によれば次のような効果が一つあるいはそれ以上ある。
【００８０】
最初に、ネットワーク内のコンテンツ共有のためのライセンス管理問題をネットワーク内部すなわち、ライセンスマネージャ（ＬＬＭ）に引揚ることによって既存ＤＲＭシステムの問題点として指摘することができるネットワーク内のデバイスに対するプライバシー保護問題を解決することができるという長所がある。
【００８１】
二番目、ライセンスマネージャがライセンスを各々のデバイスに対して発給することができるためコンテンツの内容によってデバイスの多様なアクセス権限制御を遂行するこおができるという長所もある。
【００８２】
三つ目、有効期間を短く設定したり、または再生回数に制限を加え、ライセンスを発給することによってプレビュー（ｐｒｅｖｉｅｗ）形式で臨時的にコンテンツを再生することができ、プレビューによってコンテンツ市場の潜在的購買者を拡大する期待効果をまねくことができるという長所もある。
【００８３】
四つ目、外部のライセンスサーバから委任されたライセンス発給権限を更新および解約することができる方法を提供するという長所もある。
【００８４】
五つ目、ライセンスマネージャが悪意のユーザによって攻撃され、該当ライセンスの無分別な発給のような好ましくない動作を遂行する状況でも各々のデバイスはライセンスマネージャを経由してライセンスマネージャの権限委任の有効性の可否を検証できるという長所もある。
【図面の簡単な説明】
【００８５】
【図１】従来の複数個のデバイスがネットワークを構成する例を示す。
【図２】従来の複数個のデバイスがネットワークを構成する例を示す。
【図３】本発明の一実施形態によるライセンスサーバがライセンスマネージャにライセンス発給権限を委任する過程を示す。
【図４】本発明の一実施形態による代理委任要請メッセージの様式の例を示す。
【図５】本発明の一実施形態による代理認証書の様式の例を示す。
【図６】本発明の一実施形態による代理認証書の更新過程を示す。
【図７】本発明の一実施形態による代理認証書の更新要請メッセージの様式の例を示す。
【図８】本発明の一実施形態による代理認証書の有効性検証過程の一例を示す。
【図９】本発明の一実施形態によるライセンス管理のためのシステム構成図の例を示す。
【図１０】本発明の一実施形態によるライセンスマネージャのブロック図である。
【図１１】本発明の一実施形態によるライセンスサーバのブロック図である。
【図１２】本発明の一実施形態による代理認証書の有効性検証装置のブロック図である。
【符号の説明】
【００８６】
１００ 有効性検証装置
１０３ 第３生成部
１０５ 第３検証部
１０７ 再生部
３００ ライセンスサーバ
３０３ コンテンツサーバ
３０５ メディアサーバ
３１０ ライセンスマネージャ
３１３ 第１生成部
３１５ 第１検証部
３１６ 第２検証部
３１７ 更新部
３１８ 第２生成部
３１９ 発給部
３２０ ＯＣＳＰサーバ
【技術分野】
【０００１】
本発明はライセンス管理システムおよび方法に関するものであって、より詳細にデジタルコンテンツ（以下、コンテンツ）の内容によるデバイスの多様なアクセス権限制御および効率的なライセンス管理のためのライセンス管理システムおよび方法に関するものである。
【背景技術】
【０００２】
デジタル著作権管理（ＤＲＭ；Ｄｉｇｉｔａｌ Ｒｉｇｈｔｓ Ｍａｎａｇｅｍｅｎｔ）の基本概念はコンテンツを正常的に購入したユーザが該当コンテンツを使用できるようにするためのものである。初期システムはあるユーザを一つのデバイスにバインディングすることによって、専ら該当するデバイスのみが購入したコンテンツを使用できるという方向で開発されてきた。しかし、家電技術の発達とユビキタス環境の発展によってあるユーザが同一なコンテンツを幾つものデバイスで使用する必要性が台頭した。
【０００３】
これを支援するために生まれた概念が認証されたドメイン（ＡＤ；Ａｕｔｈｏｒｉｚｅｄ Ｄｏｍａｉｎ）であり、ＡＤ概念はＡＤに属したデバイス間では制約なしにコンテンツを共有することができるようにし、ＡＤに属しないデバイスではコンテンツ共有に制約が加えられる。このようなＡＤの代表的な例としてネットワーク環境を挙げることができる。ＡＤ概念を支援する代表的なＤＲＭシステムとしてはＴｈｏｍｓｏｎ社のＳｍａｒｔ Ｒｉｇｈｔシステム、Ｏｐｅｎ Ｍｏｂｉｌｅ Ａｌｌｉａｎｃｅ（ＯＭＡ） ＤＲＭ標準、そしてＩＢＭ社のｘＣＰなどを挙げることができる。
【０００４】
ＯＭＡ ＤＲＭやｘＣＰの場合は、以下図１のように中央ライセンスサーバが各々のすべてのドメインを直接管理する。すなわちデバイスが特定ドメインに加入しようとする場合は中央ライセンスサーバとの協商によって可能であり、特定ドメインに加入の許可を受けた場合にはライセンスサーバからそのドメインに対応するドメインキーの伝達をうけるようになる。以下より具体的に説明する。
【０００５】
図１および図２は従来の複数個のデバイスがネットワークを構成する例を示す。
【０００６】
図１は４個のデバイスＤ１、Ｄ２、Ｄ３、Ｄ４が一つのネットワーク（Ｈｏｍｅ＿Ａ）１２を構成する例を示す。
【０００７】
ネットワーク（Ｈｏｍｅ＿Ａ）１２はＡＤ＿１とＡＤ＿２という二つのドメインを構成しており、ＡＤ＿１の場合はＤ１、Ｄ２、Ｄ３、Ｄ４すなわち、ネットワーク内のすべてのデバイスを含みドメインキー（ＤＫ＿１）を共有している。ＡＤ＿２の場合はネットワークの一部デバイスのＤ３とＤ４のみを含みドメインキー（ＤＫ＿２）を共有している。ＡＤ＿１とＡＤ＿２を区分する理由はコンテンツの用途によって必要な時にアクセス制御をするためである。
【０００８】
一方、Ｓｍａｒｔ Ｒｉｇｈｔシステムの場合はＯＭＡ ＤＲＭやｘＣＰとは異なり中央ライセンスサーバ１０の助けなしでデバイス間に直接自身の認証されたドメインを構成する。
【０００９】
図２はデバイスＤ１、Ｄ２、Ｄ３、Ｄ４が一つのネットワーク（Ｈｏｍｅ＿Ｂ）１４を構成する例を示す。ネットワーク（Ｈｏｍｅ＿Ｂ）１４はデバイスＤ２、Ｄ３、Ｄ４で構成された一つのドメインＡＤ＿３を構成しており、ドメインキーＤＫ＿３を共有している。デバイスＤ１は外部コンテンツ供給者から自身だけが解読し得る形態で暗号化されたコンテンツを受信してＡＤ＿３内のデバイスが再生し得る形態でライセンスを再包装して供給する役割を担当する。このような過程でＤ１はＡＤ＿３のドメインキー（ＤＫ＿３）を知らないためＡＤ＿３内のデバイスの助けを必要とする。
【００１０】
しかし、既存のＤＲＭシステムの認証されたドメイン管理方法には次のような問題点が存在する。
【００１１】
まずドメイン管理の観点からみれば、ＯＭＡ ＤＲＭやｘＣＰように中央ライセンスサーバによるドメイン管理方法は中央のライセンスサーバが各々のすべてのドメインを管理しなければならないため、ライセンスサーバに管理負担を与えることがあり、またユーザの立場から見れば自身のドメインに登録されたすべてのデバイスに関する情報を中央のライセンスサーバが知り得るため自身のドメインに対するプライバシー侵害問題が発生し得る。
【００１２】
一方、コンテンツ管理の観点からみれば、基本的に一つのドメインは一つのドメインキーでバインディングされているため各デバイスに対してコンテンツによる柔軟なアクセス権限制御が難しい。ＯＭＡ ＤＲＭやｘＣＰの場合は一つのネットワークに幾個かのＡＤを許容する方式で部分的に解決しているが、精巧なアクセス権限制御は提供するのが難しく、これは中央ライセンスサーバの管理負担を増大させる。そして、Ｓｍａｒｔ Ｒｉｇｈｔシステムの場合は個別デバイスのアクセス権限を制御する機能を提供しない。
【特許文献１】日本特許公開第2005-242543号公報
【特許文献２】韓国特許公開第2004-105684号公報
【特許文献３】韓国特許公開第2005-101940号公報
【特許文献４】韓国特許公開第2006-122676号公報
【発明の開示】
【発明が解決しようとする課題】
【００１３】
本発明はライセンス管理システムおよび方法を提供し、デジタルコンテンツの内容によるデバイスの多様なアクセス権限制御および効率的なライセンス管理を提供することにその目的がある。
【００１４】
本発明の目的は以上で言及した目的に制限されず、言及されていないまた他の目的は次の記載から当業者に明確に理解できるであろう。
【課題を解決するための手段】
【００１５】
前記目的を達成するために、本発明の実施形態による代理認証書発給方法はライセンスマネージャがライセンス発給権限の委任を受けるための要請メッセージをライセンスサーバに伝送する段階と、ライセンスサーバが要請メッセージを検証する段階と、要請メッセージが有効な場合にライセンスサーバがライセンス発給権限に対する情報を含む代理認証書をライセンスマネージャに伝送する段階、およびライセンスマネージャが代理認証書を検証する段階を含む。
【００１６】
本発明の実施形態による代理認証書更新方法は、ライセンスマネージャがライセンス発給権限に対する情報を含む代理認証書に対する更新要請メッセージをライセンスサーバに伝送する段階と、ライセンスサーバが更新要請メッセージを検証する段階と、更新要請メッセージが有効な場合にライセンスサーバがＯＣＳＰ（Ｏｎｌｉｎｅ Ｃｅｒｔｉｆｉｃａｔｅ Ｓｔａｔｕｓ Ｐｒｏｔｏｃｏｌ）サーバに代理認証書の有効の可否を質疑する段階、およびライセンスサーバがＯＣＳＰから代理認証書が有効だという応答を受けた場合、新しい代理認証書をライセンスマネージャに伝送する段階を含む。
【００１７】
本発明の実施形態による代理認証書の有効性検証方法はデバイスが代理認証書の有効性検証のための要請メッセージをライセンスマネージャに伝送する段階と、ライセンスマネージャが要請メッセージをＯＣＳＰ（Ｏｎｌｉｎｅ Ｃｅｒｔｉｆｉｃａｔｅ Ｓｔａｔｕｓ Ｐｒｏｔｏｃｏｌ）サーバに伝送する段階と、ＯＣＳＰサーバが代理認証書の有効性検証結果に対する応答メッセージをライセンスマネージャに伝送する段階、およびライセンスマネージャがデバイスに応答メッセージを伝送する段階を含む。
【００１８】
本発明の実施形態によるライセンスマネージャはライセンス発給権限に対する情報を含む代理認証書を要請するための第１要請メッセージまたは代理認証書の更新を要請するための第２要請メッセージを生成する第１生成部および第１要請メッセージによってライセンスサーバから受信した代理認証書を検証したり第２要請メッセージによってライセンスサーバから受信した新しい代理認証書を検証する第１検証部を含む。
【００１９】
本発明の実施形態によるライセンスサーバは、ライセンスマネージャから受信したライセンス発給権限に対する情報を含む代理認証書に対する第１要請メッセージまたは代理認証書の更新のため第２要請メッセージを検証する第２検証部および第１要請メッセージが有効な場合に代理認証書を生成したり第２要請メッセージが有効な場合に新しい代理認証書を生成する第２生成部を含む。
【００２０】
その他実施形態の具体的な事項は詳細な説明および図に含まれている。
【００２１】
本発明の利点および特徴、そしてそれらを達成する方法は添付される図面と共に詳細に後述されている実施形態を参照すれば明確になるだろう。しかし本発明は以下で開示される実施形態に限定されるものではなく互いに異なる多様な形態で具現されることができ、単に本実施形態は本発明の開示が完全なようにして、本発明が属する技術分野で通常の知識を有する者に発明の範疇を完全に知らせるために提供されるものであり、本発明は請求項の範囲によってのみ定義される。明細書全体にかけて同一参照符号は同一構成要素を指称する。
【００２２】
以下、添付された図面を参照し、本発明の好ましい実施形態を詳細に説明する。
【００２３】
図３は本発明の一実施形態によるライセンスサーバ（ＬＳ；Ｌｉｃｅｎｓｅ Ｓｅｒｖｅｒ）がライセンスマネージャ（ＬＬＭ；Ｌｏｃａｌ Ｌｉｃｅｎｓｅ Ｍａｎａｇｅｒ）にライセンス発給権限を委任する過程を示す。そして、図４は本発明の一実施形態による代理委任要請メッセージの様式の例を図示する。以下、図３および図４に基づきより具体的に説明する。
【００２４】
図３において、本実施形態の基盤となる代理権限委任方式はＸ．５０９代理認証書標準のためＲＦＣ ３８２０、「Ｉｎｔｅｒｎｅｔ Ｘ．５０９ ＰＫＩ Ｐｒｏｘｙ Ｃｅｒｔｉｆｉｃａｔｅ Ｐｒｏｆｉｌｅ」にある認証書による委任方式（ｄｅｌｅｇａｔｉｏｎ ｂｙ ｃｅｒｔｉｆｉｃａｔｅ）のうち所持者代理（ｂｅａｒｅｒ−ｐｒｏｘｙ）方式を応用することができる。具体的な委任手続は次のとおり。
【００２５】
まず、ライセンスマネージャ３１０は代理署名生成と検証に使用される代理個人キー（ＳＫ＿Ｐｒｏｘｙ）、および代理公開キー（ＰＫ＿Ｐｒｏｘｙ）を生成する。
【００２６】
ライセンスマネージャ３１０は図４のような構造を有する代理委任要請メッセージ（ＰｒｏｘｙＲｅｑ＿ＬＬＭ）４００を生成する。代理委任要請メッセージ４００は自身の身元（ｓｕｂｊｅｃｔ）と代理公開キー（ＰＫ＿Ｐｒｏｘｙ）などの情報を含み、ネットワークでライセンスの代理生成に関する規則（例えば、権限期間、ライセンス個数、発給対象など）を明示することができる。また、代理委任要請メッセージ４００は代理公開キー（ＰＫ＿Ｐｒｏｘｙ）を代理個人キー（ＳＫ＿Ｐｒｏｘｙ）で署名し、得られた署名値（ＳＩＧ＿Ｐｒｏｘｙ）４０２を含み得る。ここで署名値（ＳＩＧ＿Ｐｒｏｘｙ）４０２を含む理由は代理公開キーに対応される代理個人キーを自身が所有していることを証明するためである。
【００２７】
このような代理委任要請メッセージ４００の内容はライセンスマネージャ３１０の個人キー（ＳＫ＿ＬＬＭ）で改めて署名され、ライセンスマネージャ３１０は署名値（ＳＩＧ＿ＬＬＭ）４０４が添付された代理委任要請メッセージ４００をライセンスサーバ３００に伝送する（Ｓ３０１）。
【００２８】
次に、ライセンスサーバ３００は受信した前記代理委任要請メッセージ４００を検証する（Ｓ３１１）。すなわち、ライセンスサーバ３００はライセンスマネージャ３１０の公開キー（ＰＫ＿ＬＬＭ）として署名値（ＳＩＧ＿ＬＬＭ）４０４が有効なのか検証した次に、代理委任要請メッセージ４００に含まれている代理公開キー（ＰＫ＿Ｐｒｏｘｙ）を利用して署名値（ＳＩＧ＿Ｐｒｏｘｙ）４０２を検証する。
【００２９】
次に代理委任要請メッセージ４００が有効ならば、ライセンスサーバ３００はライセンスマネージャ３１０の身元と代理公開キー（ＰＫ＿Ｐｒｏｘｙ）をバインディングして、デバイスに対してライセンスを発給できる権限を付与するために以下図５のような代理認証書（Ｃｅｒｔ＿Ｐｒｏｘｙ）５００を生成する。図５は本発明の一実施形態による代理認証書５００の様式の例を図示する。代理認証書５００は権利発給者（Ｉｓｓｕｅｒ）、身元（ｓｕｂｊｅｃｔ）、一連番号（ｓｅｒｉａｌ ｎｕｍｂｅｒ）、代理公開キー、有効期間（ｖａｌｉｄｉｔｙ ｐｅｒｉｏｄ）、および委任情報（ＰｒｏｘｙＣｅｒｔＩｎｆｏ）を含み得る。委任情報は権利発給者がライセンスマネージャ３１０に権限を委任する具体的な情報を含む。具体的にライセンス発給回数、権限再委任の可能の可否などの情報が委任情報に含まれ、該当情報はライセンスマネージャ３１０内の所定モジュールが判読するようになる。
【００３０】
委任された権限の内容と制約事項はＸＭＬ基盤の権限技術言語を使用し記述されることがあり、代理認証書５００の拡張フィールドのうち所定フィールド（ＰｒｏｘｙＣｅｒｔＩｎｆｏ）に含まれ得る。このように生成された代理認証書はライセンスサーバ３００の個人キー（ＳＫ＿ＬＳ）に署名され署名値（ＳＩＧ＿ＬＳ）（５０２）が添付された後にライセンスマネージャ３１０に伝送される（Ｓ３２１）。
【００３１】
次に、ライセンスマネージャ３１０は受信された代理認証書５００の署名値（ＳＩＧ＿ＬＳ）（５０２）をライセンスサーバ３００の公開キー（ＰＫ＿ＬＳ）で検証する（Ｓ３３１）。署名が有効な場合には代理秘密キー（ＳＫ＿Ｐｒｏｘｙ）を利用して代理認証書５００に記述された権限内でデバイスにライセンスを発給することができるようになる。
【００３２】
ライセンスマネージャ３１０がコンテンツをデバイスに代わり購入するようになればライセンスサーバ３００はコンテンツ暗号化キーと該当コンテンツの利用に関する権利、制約条件、有効消費期間などが明示されたライセンスをライセンスマネージャ３１０に発給する。ライセンスマネージャ３１０は自身が受けたライセンスに基づきデバイスがコンテンツを再生できるよう委任を受けた権限すなわち、代理個人キー（ＳＫ＿Ｐｒｏｘｙ）を利用してライセンスを再包装した後に発給する。
【００３３】
代理認証書５００は有効期間が満了したりライセンス発給回数が超過すると効力が中止される。したがってライセンスマネージャ３１０は委任された権限を継続して維持するためには代理認証書５００の有効期間が満了する前の特定期間中に代理認証書を更新しなければならない。しかし長時間ネットワーク連結が円滑でなかったり、またはその他事情によって有効期間満了前に更新をできない場合でもそれ以後に代理認証書は更新される。このような手続はすべて自動でなされ得る。
【００３４】
図６は本発明の一実施形態による代理認証書の更新過程を図示する。そして、図７は本発明の一実施形態による代理認証書の更新要請メッセージ７００の様式の例を図示する。以下図６および図７に基づきより具体的に説明する。
【００３５】
ライセンスマネージャ３１０は図７のような構造を有する代理認証書の更新要請メッセージ（ＰｒｏｘｙＲｅｎｅｗＲｅｑ＿ＬＬＭ）７００を生成する。代理認証書の更新要請メッセージ７００は自身の身元と代理認証書の一連番号などの情報を含むことができ、このようなメッセージ内容はライセンスマネージャ３１０の個人キー（ＳＫ＿ＬＬＭ）で署名され前記図５の代理認証書と一緒にライセンスサーバ３００に伝送され得る（Ｓ６０１）。
【００３６】
ライセンスサーバ３００は伝達された代理認証書の更新要請メッセージ７００を検証する（Ｓ６１１）。すなわち、ライセンスサーバ３００はライセンスマネージャ３１０の公開キー（ＰＫ＿ＬＬＭ）を利用して署名値（ＳＩＧ＿ＬＬＭ）（４０４−１）を検証する過程を経るようになる。
【００３７】
ライセンスサーバ３００は署名値（ＳＩＧ＿ＬＬＭ）（４０４−１）が有効な場合に代理認証書の一連番号を利用してＯＣＳＰプロトコルによってＯＣＳＰサーバ３２０に代理認証書の有効の可否を質疑する（Ｓ６２１）。
【００３８】
そして、ライセンスサーバ３００は質疑した結果をＯＣＳＰサーバ３２０から受信する（Ｓ６３１）。前段階（Ｓ６２１）はライセンスサーバ３００が管理するＣＲＬ（Ｃｅｒｔｉｆｉｃａｔｅ Ｒｅｖｏｃａｔｉｏｎ Ｌｉｓｔ）を参照する方式で代替され得る。
【００３９】
ライセンスサーバ３００は前段階（Ｓ６３１）で受けた代理認証書の状態結果が有効な場合に、段階（Ｓ６０１）から伝達された代理認証書の有効期間またはライセンスの発給可能な回数などを再設定した後、自身の個人キー（ＳＫ＿ＬＳ）で再署名して、新しい代理認証書を作った後、ライセンスマネージャ３１０に伝送する（Ｓ６４１）。
【００４０】
ライセンスマネージャ３１０は伝送された新しい代理認証書の署名値（ＳＩＧ＿ＬＳ）をライセンスサーバ３００の公開キー（ＰＫ＿ＬＳ）で検証する（Ｓ６５１）。検証が有効な場合にライセンスマネージャ３１０は既存の代理認証書は削除して新しい代理認証書で代替する。
【００４１】
このような方式の更新メカニズムは代理公開キーを変更せずとも有効期間だけを延長する効果を招くためシステムの透明性を増進させることができる。一方、本実施形態の更新メカニズムは既存の代理認証書は廃棄させないため一時的に二個の有効な代理認証書が存在し得るが既存の代理認証書はいくらも残っていない有効期間が過ぎれば無効化（廃棄）されるためシステムの安全性には問題とならない。
【００４２】
代理認証書の有効期間すなわち、更新周期を決定する政策はシステムの効率性とシステムの安全性が相反関係にあるため運用戦略によって適切に選択しなければならない。有効期間を短く設定すればハッキングまたはその他、他の理由によるライセンスマネージャの権限不正乱用を早期に中断することができる反面、頻繁に代理認証書を更新しなければならないため全体システムの性能低下を誘発し得る。有効期間を長く設定すれば反対の効果が発生する。したがってシステムの性能がシステムの安全性より優先視されれば有効期間を比較的長く設定するのが有利であり、システムの安全性がさらに重要ならば有効期間を比較的短くする戦略が有利である。例えば、現在公認認証書の有効期間が１年である点を考慮すれば、代理認証書の有効期間は１月以内とするのが適切であろう。
【００４３】
一方、ライセンスマネージャ３１０に付与した権限を解約するためにも、または攻撃によって、ライセンスマネージャ３１０が権限を不正乱用したことが感知された場合、ライセンスサーバ３００は自身が付与した代理認証書をＯＣＳＰサーバ３２０に廃棄登録しなければならない。このような手続はライセンスサーバ３００によって、遂行され、後述される図８の段階（Ｓ１００）のようなＯＣＳＰプロトコルの廃棄認証書登録過程を通してＯＣＳＰサーバ３２０に登録される。廃棄認証書登録過程は従来の技術文書を参照していただきたい。
【００４４】
図８は本発明の一実施形態による代理認証書の有効性検証過程の一例を示す。
【００４５】
デバイス（Ｄ１、Ｄ２、…）がコンテンツを再生するためにはコンテンツとこれに対応するライセンスが必要である。ライセンスはライセンスマネージャ３１０が代理権限を利用して発給したものであるためコンテンツを再生する前にその代理権限が有効なのかを検証しなければならない。このためにはＯＣＳＰサーバ３２０への質疑によって代理認証書の有効性の有無を検証するのが好ましい。しかしすべてのデバイスが外部のＯＣＳＰサーバ３２０と直接連結し得る能力を備えていると仮定することができないため、この様な場合はＯＣＳＰとの通信方法を有しているライセンスマネージャ３１０を通して、代理認証書の有効性の有無を検証する作業を遂行することができる。ここで、伝送途中に当事者であるライセンスマネージャ３１０から検査結果値が操作されることがあり、これに対する補完策が用意されなければならない。これは次の過程によって、達成され得る。
【００４６】
デバイス（Ｄ２）は自身の身元と自身の公開キー（ＰＫ＿Ｄ２）、ライセンスマネージャ３１０の代理認証書の一連番号、タイムスタンプ、ノンス等の情報を含んだ代理認証書の有効性検証のための要請メッセージを生成した次に自身の署名（ＳＩＧ＿Ｄ２）を貼付してライセンスマネージャ３１０に伝送する（Ｓ８０１）。タイムスタンプ（ｔｉｍｅ ｓｔａｍｐ）、ノンス（ｎｏｎｃｅ）などの情報は要請メッセージに対するリプレイ（ｒｅｐｌａｙ）攻撃を防ぐために使用される。ここで、デバイス（Ｄ２）は前記のような作業に使用する個人キー（ＳＫ＿Ｄ２）と公開キー（ＰＫ＿Ｄ２）を安全に保存していなければならない。
【００４７】
ライセンスマネージャ３１０は代理認証書の有効性の有無を検証するためにデバイス（Ｄ２）から受信した要請メッセージをＯＣＳＰサーバ３２０に伝達する（Ｓ８１１）。
【００４８】
ＯＣＳＰサーバ３２０は受信した要請メッセージに含まれたデバイスの署名の有効性の可否をデバイス（Ｄ２）の公開キー（ＰＫ＿Ｄ２）で検証し、署名が有効な場合に要請メッセージに含まれた代理認証書の一連番号に対応する認証書の状態を確認する。そして、代理認証書の有効性検証結果に対する応答メッセージを自身の秘密キー（ＳＫ＿ＯＣＳＰ）で署名して、デバイス（Ｄ２）の公開キーで暗号化し、ライセンスマネージャ３１０に伝送する（Ｓ８２１）。
【００４９】
ライセンスマネージャ３１０は受信した応答メッセージをデバイス（Ｄ２）に伝達する（Ｓ８３１）。
【００５０】
デバイス（Ｄ２）はＯＣＳＰの公開キー（ＰＫ＿ＯＣＳＰ）で受信した応答メッセージの署名を検証した後、署名が有効な場合ににはその結果を参照する（Ｓ８４１）。その結果が有効な場合にすなわち、代理認証書が有効な場合にデバイスは該当ライセンスでコンテンツを再生し、そうではない場合には代理認証書とライセンスをメモリから削除して有効でないライセンスであるということをディスプレイに表示しユーザに通報しコンテンツは再生しない。
【００５１】
前記過程で伝送される要請メッセージおよび応答メッセージは暗号化され署名が添付されているため中間でライセンスマネージャが任意に操作できる可能性を防止することができる。
【００５２】
また、攻撃によって、ライセンスマネージャが前記のような有効性検証過程を遂行しない場合、デバイスは適切な応答を受信することができないことでライセンスマネージャ３１０が攻撃され、有効でないを推論することができる。
【００５３】
図９は本発明の一実施形態によるライセンス管理のためのシステム構成図の例を図示する。
【００５４】
前述した内容に基づいて、本発明のシステムはコンテンツ提供者を構成するライセンスサーバ３００とコンテンツサーバ（ＣＳ；Ｃｏｎｔｅｎｔｓ Ｓｅｒｖｅｒ）３０３、ユーザ側のネットワークを構成するライセンスマネージャ３１０とメディアサーバ（ＬＭＳ；Ｌｏｃａｌ Ｍｅｄｉａ Ｓｅｒｖｅｒ）３０５、ＯＣＳＰサーバ３２０を含み得る。
【００５５】
コンテンツサーバ３０３はコンテンツに対する知的財産権を所有しているコンテンツ提供者が運営するサーバであって、コンテンツに対する一次的な配布を遂行することができ、ライセンスサーバ３００はコンテンツ購買者に対して適法な使用権限を明示したライセンスを発給する役割を遂行することができる。この二つのサーバ３０３、３００は概念的に分離されているが実際の運営のために同一の物理的装置で動作し得る。すなわち、前述されたようにライセンスサーバ３００がコンテンツサーバ３０３の機能を含み得る。
【００５６】
コンテンツサーバ３０３はコンテンツをＤＲＭのような方法によって暗号化するなどの安全に包装したコンテンツをネットワーク内のメディアサーバ３０５に伝送する役割を遂行することができる。
【００５７】
ライセンスサーバ３００は前述したように購入したコンテンツに対して購買条件に合うアクセス権限を付与したライセンスを生成する。前記ライセンスには該当コンテンツがデバイスでどのように消費されなければならないのか記述されている。
【００５８】
前述された実施例でデバイス（Ｄ１、Ｄ２．．）はライセンスサーバ３００を通して直接ライセンスの発給を受けずネットワーク上でコンテンツを再生することができ、該当ドメインを管理するライセンスマネージャ３１０を通して自体的にライセンスが発給されデバイスに提供され得る。
【００５９】
すなわち、ライセンスマネージャ３１０は自身が属したネットワークを代表してデバイスに対してライセンスを発給することができる権限をライセンスサーバ３００から委任を受ける。
【００６０】
一方、ＯＣＳＰサーバ３２０は個体認証書や代理認証書の有効性の可否の質疑を受け、認証書の現状態を答弁する役割を担当する。応答メッセージにはＯＣＳＰの署名が添付される。
【００６１】
各個体は自分だけの個人キー（ＳＫ）、公開キー（ＰＫ）を有しており、また自身の公開キー認証のための信頼された認証機関（ＣＡ）が発給した個体認証書を含み得る。また、二つの個体が通信を望む時はまずＰＫＩ基盤の相互認証を遂行することができる。その他にユーザデバイスは適法なライセンスに明示された権限内でコンテンツを再生することができる信頼するだけのエージェントによって統制を受けることができる。
【００６２】
図１０は本発明の一実施形態によるライセンスマネージャのブロック図である。
【００６３】
ライセンスマネージャ３１０は第１生成部３１３、第１検証部３１５、更新部３１７、および発給部３１９を含む。
【００６４】
第１生成部３１３はライセンス発給権限に対する情報を含む代理認証書に対する要請メッセージを生成する。すなわち、ライセンスマネージャは代理認証書によってライセンス発給権限の委任を受けることができる。また、第１生成部３１３は代理署名生成と検証に使用される代理個人キー（ＳＫ＿Ｐｒｏｘｙ）、および代理公開キー（ＰＫ＿Ｐｒｏｘｙ）を生成することができる。要請メッセージは代理公開キー（ＰＫ＿Ｐｒｏｘｙ）を代理個人キー（ＳＫ＿Ｐｒｏｘｙ）で署名して得られた署名値（ＳＩＧ＿Ｐｒｏｘｙ）を含み得る。また、第１生成部３１３は代理認証書に対する更新要請メッセージを生成することができる。更新要請メッセージはライセンスマネージャの身元と代理認証書の一連番号などの情報を含むことができ、ライセンスマネージャの個人キー（ＳＫ＿ＬＬＭ）で署名され代理認証書と一緒にライセンスサーバに伝送され得る。
【００６５】
第１検証部３１５はライセンスサーバから受信したライセンス発給権限に対する情報を含む代理認証書を検証する。ここで、第１検証部３１５は代理認証書の署名値（ＳＩＧ＿ＬＳ）をライセンスサーバの公開キー（ＰＫ＿ＬＳ）で検証することができる。また、署名が有効な場合にには代理秘密キー（ＳＫ＿Ｐｒｏｘｙ）を利用して代理認証書に記述されたライセンス発給権限内でデバイスに後述される発給部（３１９）を通して、ライセンスを発給することができる。また、第１検証部３１５は新しい代理認証書を受信した場合、新しい認証書の署名値（ＳＩＧ＿ＬＳ）をライセンスサーバの公開キー（ＰＫ＿ＬＳ）で検証して検証が有効な場合に後述される更新部（３１７）は通じて既存の代理認証書は削除し、新しい代理認証書に代替され得る。
【００６６】
更新部３１７はライセンスサーバから新しい代理認証書を受信した場合、既存の代理認証書を新しい代理認証書として代替する。ここで、更新部（３１７）はまだ既存の代理認証書の有効期間が残っている場合、自動で有効期間が満了すれば既存の代理認証書を廃棄して新しい代理認証書に代替し得る。
【００６７】
発給部３１９は代理認証書に記述されたライセンス発給権限内でデバイスにコンテンツ利用のためのライセンスを発給する。
【００６８】
図１１は本発明の一実施形態によるライセンスサーバのブロック図である。
【００６９】
ライセンスサーバ３００は第２検証部３１６、および第２生成部３１８を含む。
【００７０】
第２検証部３１６はライセンスマネージャが伝送したライセンス発給権限の委任を受けるための要請メッセージを検証する。ここで、第２検証部３１６はライセンスマネージャの公開キー（ＰＫ＿ＬＬＭ）を利用して要請メッセージに含まれた署名値（ＳＩＧ＿ＬＬＭ）の有効性の可否を検証し、要請メッセージに含まれている代理公開キー（ＰＫ＿Ｐｒｏｘｙ）を利用して署名値（ＳＩＧ＿Ｐｒｏｘｙ）を検証することができる。また、第２検証部３１６はライセンスマネージャが伝送した代理認証書に対する更新要請メッセージを検証することができる。ここで、第２検証部３１６はライセンスマネージャの公開キー（ＰＫ＿ＬＬＭ）を利用して署名値（ＳＩＧ＿ＬＬＭ）を検証することができる。そして、第２検証部３１６は更新要請メッセージが有効な場合にライセンスサーバがＯＣＳＰサーバに前記代理認証書の有効の可否を質疑することができ、その結果に対する応答メッセージを受信することができる。
【００７１】
第２生成部３１８は要請メッセージが有効な場合にライセンス発給権限に対する情報を含む代理認証書を生成する。ここで、第２生成部３１８はライセンスマネージャの身元と代理公開キー（ＰＫ＿Ｐｒｏｘｙ）をバインディングした代理認証書を生成することができる。代理認証書は権利発給者、身元、一連番号、代理公開キー、有効期間、および委任情報のうち少なくとも一つを含み得る。ここで、代理認証書はライセンスサーバの個人キー（ＳＫ＿ＬＳ）に署名され署名値（ＳＩＧ＿ＬＳ）が添付された後、ライセンスマネージャに伝送され得る。また、第２生成部３１８は前述されたＯＣＳＰから代理認証書が有効だという応答を受けた場合、新しい代理認証書を生成し、ライセンスマネージャに伝送し得る。新しい代理認証書には代理認証書の有効期間およびライセンスの発給可能な回数に対する情報のうち少なくとも一つを含むことができ、ライセンスサーバの個人キー（ＳＫ＿ＬＳ）で再署名され得る。
【００７２】
図１２は本発明の一実施形態による代理認証書の有効性検証装置のブロック図である。
【００７３】
代理認証書の有効性検証装置１００は第３生成部１０３、第３検証部１０５および再生部１０７を含み、所定デバイス内に具現され得る。
【００７４】
第３生成部１０３はライセンスマネージャの代理認証書の一連番号、タイムスタンプ、ノンス等の情報を含んだ代理認証書の有効性検証のための要請メッセージを生成し、自身の公開キー（ＰＫ＿Ｄ２）で暗号化した後、自身の署名（ＳＩＧ＿Ｄ２）を貼付する。タイムスタンプ、ノンスなどの情報は要請メッセージに対するリプレイ攻撃を防ぐために使用され得る。
【００７５】
第３検証部１０５はＯＣＳＰの公開キー（ＰＫ＿ＯＣＳＰ）でＯＣＳＰから受信した応答メッセージの署名を検証した後、署名が有効な場合ににはその結果を参照する。その結果によって代理認証書が有効な場合にライセンスマネージャから発給を受けたライセンスで後述される再生部によってコンテンツを再生する。
【００７６】
再生部１０７は前述されたように代理認証書が有効な場合にコンテンツを再生する。もしその反対の場合、再生部は代理認証書とライセンスをメモリから削除することができる。
【００７７】
図１０、図１１および図１２で図示された各々の構成要素は一種の「モジュール」で構成され得る。前記「モジュール」はソフトウェアまたはＦｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ（ＦＰＧＡ）または注文型半導体（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ、ＡＳＩＣ）のようなハードウェア構成要素を意味し、モジュールはある役割を遂行する。しかしモジュールはソフトウェアまたはハードウェアに限定される意味ではない。モジュールはアドレッシングできる保存媒体に存在するように構成され得るがまたはそれ以上のプロセッサを実行させるように構成され得る。したがって、一例としてモジュールはソフトウェア構成要素、オブジェクト指向ソフトウェア構成要素、クラス構成要素およびタスク構成要素のような構成要素と、プロセス、関数、属性、プロシーザ、サブルーチン、プログラムコードのセグメント、ドライバ、ファームウェア、マイクロコード、回路、データ、データベース、データ構造、テーブル、アレイ、および変数を含む。構成要素とモジュールで提供されている機能はさらに小さい数の構成要素およびモジュールに結合したり追加的な構成要素とモジュールにさらに分離することができる。
【００７８】
以上添付された図面を参照し本発明の実施形態を説明したが、本発明が属する技術分野で通常の知識を有する者は本発明がその技術的思想や必須の特徴を変更せず、他の具体的な形態で実施され得るということを理解するはずである。そのため以上で記述した実施形態はすべての面で例示的なものであり、限定的ではないものと理解しなければならない。
【発明の効果】
【００７９】
前記したような本発明のライセンス管理システムおよび方法によれば次のような効果が一つあるいはそれ以上ある。
【００８０】
最初に、ネットワーク内のコンテンツ共有のためのライセンス管理問題をネットワーク内部すなわち、ライセンスマネージャ（ＬＬＭ）に引揚ることによって既存ＤＲＭシステムの問題点として指摘することができるネットワーク内のデバイスに対するプライバシー保護問題を解決することができるという長所がある。
【００８１】
二番目、ライセンスマネージャがライセンスを各々のデバイスに対して発給することができるためコンテンツの内容によってデバイスの多様なアクセス権限制御を遂行するこおができるという長所もある。
【００８２】
三つ目、有効期間を短く設定したり、または再生回数に制限を加え、ライセンスを発給することによってプレビュー（ｐｒｅｖｉｅｗ）形式で臨時的にコンテンツを再生することができ、プレビューによってコンテンツ市場の潜在的購買者を拡大する期待効果をまねくことができるという長所もある。
【００８３】
四つ目、外部のライセンスサーバから委任されたライセンス発給権限を更新および解約することができる方法を提供するという長所もある。
【００８４】
五つ目、ライセンスマネージャが悪意のユーザによって攻撃され、該当ライセンスの無分別な発給のような好ましくない動作を遂行する状況でも各々のデバイスはライセンスマネージャを経由してライセンスマネージャの権限委任の有効性の可否を検証できるという長所もある。
【図面の簡単な説明】
【００８５】
【図１】従来の複数個のデバイスがネットワークを構成する例を示す。
【図２】従来の複数個のデバイスがネットワークを構成する例を示す。
【図３】本発明の一実施形態によるライセンスサーバがライセンスマネージャにライセンス発給権限を委任する過程を示す。
【図４】本発明の一実施形態による代理委任要請メッセージの様式の例を示す。
【図５】本発明の一実施形態による代理認証書の様式の例を示す。
【図６】本発明の一実施形態による代理認証書の更新過程を示す。
【図７】本発明の一実施形態による代理認証書の更新要請メッセージの様式の例を示す。
【図８】本発明の一実施形態による代理認証書の有効性検証過程の一例を示す。
【図９】本発明の一実施形態によるライセンス管理のためのシステム構成図の例を示す。
【図１０】本発明の一実施形態によるライセンスマネージャのブロック図である。
【図１１】本発明の一実施形態によるライセンスサーバのブロック図である。
【図１２】本発明の一実施形態による代理認証書の有効性検証装置のブロック図である。
【符号の説明】
【００８６】
１００ 有効性検証装置
１０３ 第３生成部
１０５ 第３検証部
１０７ 再生部
３００ ライセンスサーバ
３０３ コンテンツサーバ
３０５ メディアサーバ
３１０ ライセンスマネージャ
３１３ 第１生成部
３１５ 第１検証部
３１６ 第２検証部
３１７ 更新部
３１８ 第２生成部
３１９ 発給部
３２０ ＯＣＳＰサーバ
【特許請求の範囲】
【請求項１】
ライセンスマネージャがライセンス発給権限の委任を受けるための要請メッセージをライセンスサーバに伝送する段階と、
前記ライセンスサーバが前記要請メッセージを検証する段階と、
前記要請メッセージが有効な場合に前記ライセンスサーバが前記ライセンス発給権限に対する情報を含む代理認証書を前記ライセンスマネージャに伝送する段階、および
前記ライセンスマネージャが前記代理認証書を検証する段階を含む代理認証書発給方法。
【請求項２】
前記要請メッセージを検証する段階は、
前記ライセンスサーバが前記ライセンスマネージャの公開キーを利用して前記要請メッセージに含まれた署名値の有効性の可否を検証する段階を含む、請求項１に記載の代理認証書発給方法。
【請求項３】
前記ライセンスマネージャが、前記代理認証書に記述された権限内でデバイスにコンテンツ利用のためのライセンスを発給する段階をさらに含む請求項１に記載の代理認証書発給方法。
【請求項４】
ライセンスマネージャが、ライセンス発給権限に対する情報を含む代理認証書に対する更新要請メッセージをライセンスサーバに伝送する段階と、
前記ライセンスサーバが前記更新要請メッセージを検証する段階と、
前記更新要請メッセージが有効な場合に前記ライセンスサーバがＯＣＳＰサーバに前記代理認証書の有効の可否を質疑する段階、および
前記ライセンスサーバが前記ＯＣＳＰから前記代理認証書が有効であるという応答を受けた場合、新しい代理認証書を前記ライセンスマネージャに伝送する段階を含む代理認証書更新方法。
【請求項５】
前記ライセンスマネージャが、前記新しい代理認証書を前記ライセンスサーバの公開キーを利用して検証する段階をさらに含む、請求項４に記載の代理認証書更新方法。
【請求項６】
前記新しい代理認証書には代理認証書の有効期間およびライセンスの発給可能な回数に対する情報のうち少なくとも一つを含む請求項４に記載の代理認証書更新方法。
【請求項７】
前記ライセンスマネージャに保存された既存の代理認証書は、前記新しい代理認証書で代替されたり、前記既存の代理認証書が有効期間が満了したりすると自動で廃棄される請求項４に記載の代理認証書更新方法。
【請求項８】
デバイスが代理認証書の有効性検証のための要請メッセージをライセンスマネージャに伝送する段階と、
前記ライセンスマネージャが前記要請メッセージをＯＣＳＰサーバに伝送する段階と、
前記ＯＣＳＰサーバが前記代理認証書の有効性検証結果に対する応答メッセージを前記ライセンスマネージャに伝送する段階、および
前記ライセンスマネージャが前記デバイスに前記応答メッセージを伝送する段階を含む代理認証書の有効性検証方法。
【請求項９】
前記デバイスが、前記要請メッセージを自身の公開キーで暗号化と自身の署名を貼付する段階をさらに含む請求項８に記載の代理認証書の有効性検証方法。
【請求項１０】
前記ＯＣＳＰサーバが、前記デバイスの公開キーで前記要請メッセージに含まれた署名の有効性の可否を検証する段階をさらに含む請求項８に記載の代理認証書の有効性検証方法。
【請求項１１】
前記ＯＣＳＰサーバが、前記応答メッセージを自身の秘密キーで署名してデバイスの公開キーで暗号化する段階をさらに含む請求項８に記載の代理認証書の有効性検証方法。
【請求項１２】
前記応答メッセージの結果において、前記代理認証書が有効でないものと検証された場合、前記デバイスが前記ライセンスマネージャから発給を受けたライセンスおよび前記代理認証書のうち少なくとも一つを削除する段階をさらに含む請求項８に記載の代理認証書の有効性検証方法。
【請求項１３】
前記有効性検証の質疑に対して制限された時間内に前記ＯＣＳＰサーバから適切な応答を受信できない場合、前記代理認証書が有効でないものと見なして前記ライセンスマネージャから発給を受けたライセンスおよび前記代理認証書を削除する段階をさらに含む請求項８に記載の代理認証書の有効性検証方法。
【請求項１４】
ライセンス発給権限に対する情報を含む代理認証書を要請するための第１要請メッセージまたは前記代理認証書の更新を要請するための第２要請メッセージを生成する第１生成部、および
前記第１要請メッセージによってライセンスサーバから受信した前記代理認証書を検証したり前記第２要請メッセージによって前記ライセンスサーバから受信した新しい代理認証書を検証する第１検証部を含むライセンスマネージャ。
【請求項１５】
前記第１検証部は、前記代理認証書または前記新しい代理認証書の署名値を前記ライセンスサーバの公開キーを利用して検証する請求項１４に記載のライセンスマネージャ。
【請求項１６】
前記代理認証書に記述されたライセンス発給権限内でデバイスにコンテンツ利用のためのライセンスを発給する発給部をさらに含む請求項１４に記載のライセンスマネージャ。
【請求項１７】
前記代理認証書を、前記新しい代理認証書に代替する更新部を含む請求項１４に記載のライセンスマネージャ。
【請求項１８】
ライセンスマネージャから受信したライセンス発給権限に対する情報を含む代理認証書に対する第１要請メッセージまたは前記代理認証書の更新のため第２要請メッセージを検証する第２検証部、および
前記第１要請メッセージが有効な場合に前記代理認証書を生成したり前記第２要請メッセージが有効な場合に新しい代理認証書を生成する第２生成部を含むライセンスサーバ。
【請求項１９】
前記代理認証書は、権利発給者、身元、前記代理認証書の一連番号、代理公開キー、有効期間、および委任情報のうち少なくとも一つを含む請求項１８に記載のライセンスサーバ。
【請求項２０】
前記第２生成部は、既存の前記代理認証書の有効期間およびライセンスの発給可能な回収のうち少なくとも一つを再設定した後に前記新しい認証書を生成する請求項１８に記載のライセンスサーバ。
【請求項２１】
前記第２検証部は、前記第２要請メッセージが有効な場合にＯＣＳＰサーバに前記代理認証書の有効の可否を質疑し、
前記第２生成部は、前記ＯＣＳＰサーバから前記代理認証書が有効であるという応答を受けた場合、前記新しい代理認証書を生成する請求項１８に記載のライセンスサーバ。
【請求項１】
ライセンスマネージャがライセンス発給権限の委任を受けるための要請メッセージをライセンスサーバに伝送する段階と、
前記ライセンスサーバが前記要請メッセージを検証する段階と、
前記要請メッセージが有効な場合に前記ライセンスサーバが前記ライセンス発給権限に対する情報を含む代理認証書を前記ライセンスマネージャに伝送する段階、および
前記ライセンスマネージャが前記代理認証書を検証する段階を含む代理認証書発給方法。
【請求項２】
前記要請メッセージを検証する段階は、
前記ライセンスサーバが前記ライセンスマネージャの公開キーを利用して前記要請メッセージに含まれた署名値の有効性の可否を検証する段階を含む、請求項１に記載の代理認証書発給方法。
【請求項３】
前記ライセンスマネージャが、前記代理認証書に記述された権限内でデバイスにコンテンツ利用のためのライセンスを発給する段階をさらに含む請求項１に記載の代理認証書発給方法。
【請求項４】
ライセンスマネージャが、ライセンス発給権限に対する情報を含む代理認証書に対する更新要請メッセージをライセンスサーバに伝送する段階と、
前記ライセンスサーバが前記更新要請メッセージを検証する段階と、
前記更新要請メッセージが有効な場合に前記ライセンスサーバがＯＣＳＰサーバに前記代理認証書の有効の可否を質疑する段階、および
前記ライセンスサーバが前記ＯＣＳＰから前記代理認証書が有効であるという応答を受けた場合、新しい代理認証書を前記ライセンスマネージャに伝送する段階を含む代理認証書更新方法。
【請求項５】
前記ライセンスマネージャが、前記新しい代理認証書を前記ライセンスサーバの公開キーを利用して検証する段階をさらに含む、請求項４に記載の代理認証書更新方法。
【請求項６】
前記新しい代理認証書には代理認証書の有効期間およびライセンスの発給可能な回数に対する情報のうち少なくとも一つを含む請求項４に記載の代理認証書更新方法。
【請求項７】
前記ライセンスマネージャに保存された既存の代理認証書は、前記新しい代理認証書で代替されたり、前記既存の代理認証書が有効期間が満了したりすると自動で廃棄される請求項４に記載の代理認証書更新方法。
【請求項８】
デバイスが代理認証書の有効性検証のための要請メッセージをライセンスマネージャに伝送する段階と、
前記ライセンスマネージャが前記要請メッセージをＯＣＳＰサーバに伝送する段階と、
前記ＯＣＳＰサーバが前記代理認証書の有効性検証結果に対する応答メッセージを前記ライセンスマネージャに伝送する段階、および
前記ライセンスマネージャが前記デバイスに前記応答メッセージを伝送する段階を含む代理認証書の有効性検証方法。
【請求項９】
前記デバイスが、前記要請メッセージを自身の公開キーで暗号化と自身の署名を貼付する段階をさらに含む請求項８に記載の代理認証書の有効性検証方法。
【請求項１０】
前記ＯＣＳＰサーバが、前記デバイスの公開キーで前記要請メッセージに含まれた署名の有効性の可否を検証する段階をさらに含む請求項８に記載の代理認証書の有効性検証方法。
【請求項１１】
前記ＯＣＳＰサーバが、前記応答メッセージを自身の秘密キーで署名してデバイスの公開キーで暗号化する段階をさらに含む請求項８に記載の代理認証書の有効性検証方法。
【請求項１２】
前記応答メッセージの結果において、前記代理認証書が有効でないものと検証された場合、前記デバイスが前記ライセンスマネージャから発給を受けたライセンスおよび前記代理認証書のうち少なくとも一つを削除する段階をさらに含む請求項８に記載の代理認証書の有効性検証方法。
【請求項１３】
前記有効性検証の質疑に対して制限された時間内に前記ＯＣＳＰサーバから適切な応答を受信できない場合、前記代理認証書が有効でないものと見なして前記ライセンスマネージャから発給を受けたライセンスおよび前記代理認証書を削除する段階をさらに含む請求項８に記載の代理認証書の有効性検証方法。
【請求項１４】
ライセンス発給権限に対する情報を含む代理認証書を要請するための第１要請メッセージまたは前記代理認証書の更新を要請するための第２要請メッセージを生成する第１生成部、および
前記第１要請メッセージによってライセンスサーバから受信した前記代理認証書を検証したり前記第２要請メッセージによって前記ライセンスサーバから受信した新しい代理認証書を検証する第１検証部を含むライセンスマネージャ。
【請求項１５】
前記第１検証部は、前記代理認証書または前記新しい代理認証書の署名値を前記ライセンスサーバの公開キーを利用して検証する請求項１４に記載のライセンスマネージャ。
【請求項１６】
前記代理認証書に記述されたライセンス発給権限内でデバイスにコンテンツ利用のためのライセンスを発給する発給部をさらに含む請求項１４に記載のライセンスマネージャ。
【請求項１７】
前記代理認証書を、前記新しい代理認証書に代替する更新部を含む請求項１４に記載のライセンスマネージャ。
【請求項１８】
ライセンスマネージャから受信したライセンス発給権限に対する情報を含む代理認証書に対する第１要請メッセージまたは前記代理認証書の更新のため第２要請メッセージを検証する第２検証部、および
前記第１要請メッセージが有効な場合に前記代理認証書を生成したり前記第２要請メッセージが有効な場合に新しい代理認証書を生成する第２生成部を含むライセンスサーバ。
【請求項１９】
前記代理認証書は、権利発給者、身元、前記代理認証書の一連番号、代理公開キー、有効期間、および委任情報のうち少なくとも一つを含む請求項１８に記載のライセンスサーバ。
【請求項２０】
前記第２生成部は、既存の前記代理認証書の有効期間およびライセンスの発給可能な回収のうち少なくとも一つを再設定した後に前記新しい認証書を生成する請求項１８に記載のライセンスサーバ。
【請求項２１】
前記第２検証部は、前記第２要請メッセージが有効な場合にＯＣＳＰサーバに前記代理認証書の有効の可否を質疑し、
前記第２生成部は、前記ＯＣＳＰサーバから前記代理認証書が有効であるという応答を受けた場合、前記新しい代理認証書を生成する請求項１８に記載のライセンスサーバ。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【公開番号】特開２００９−１５８５２（Ｐ２００９−１５８５２Ａ）
【公開日】平成２１年１月２２日（２００９．１．２２）
【国際特許分類】
【出願番号】特願２００８−１７２９０７（Ｐ２００８−１７２９０７）
【出願日】平成２０年７月２日（２００８．７．２）
【出願人】（３９００１９８３９）三星電子株式会社 (8,520)
【氏名又は名称原語表記】ＳＡＭＳＵＮＧ ＥＬＥＣＴＲＯＮＩＣＳ ＣＯ．，ＬＴＤ．
【住所又は居所原語表記】４１６，Ｍａｅｔａｎ−ｄｏｎｇ，Ｙｅｏｎｇｔｏｎｇ−ｇｕ，Ｓｕｗｏｎ−ｓｉ，Ｇｙｅｏｎｇｇｉ−ｄｏ ４４２−７４２（ＫＲ）
【Ｆターム（参考）】
【公開日】平成２１年１月２２日（２００９．１．２２）
【国際特許分類】
【出願日】平成２０年７月２日（２００８．７．２）
【出願人】（３９００１９８３９）三星電子株式会社 (8,520)
【氏名又は名称原語表記】ＳＡＭＳＵＮＧ ＥＬＥＣＴＲＯＮＩＣＳ ＣＯ．，ＬＴＤ．
【住所又は居所原語表記】４１６，Ｍａｅｔａｎ−ｄｏｎｇ，Ｙｅｏｎｇｔｏｎｇ−ｇｕ，Ｓｕｗｏｎ−ｓｉ，Ｇｙｅｏｎｇｇｉ−ｄｏ ４４２−７４２（ＫＲ）
【Ｆターム（参考）】
[ Back to top ]