(57)【特許請求の範囲】
【請求項１】
商品を製造するユーザが使用する端末装置と、第１および第２の設計情報提供サーバと、前記商品の製造に必要な特許についてライセンスの契約を前記端末装置と締結する特許ライセンス発行サーバとを、通信可能に接続する設計情報提供システムであって、
前記第１の設計情報提供サーバは、前記商品の製造に必要な仕様を示す第１の設計情報を前記端末装置に送信し、
前記特許ライセンス発行サーバは、
前記第１の設計情報に関する特許のライセンスの契約を締結した端末装置のユーザの一覧を示す契約者リストを生成する生成手段と、
前記生成手段が生成した契約者リストを外部へ出力する出力手段とを備え、
前記第２の設計情報提供サーバは、
前記商品の製造に必要であって且つ前記商品に固有の第２の設計情報である暗号鍵の発行の要求を前記端末装置から受信する通信手段と、
前記暗号鍵の発行を要求した前記端末装置に当該暗号鍵を発行する発行手段と、
前記出力手段が出力した契約者リストを取得する取得手段と、
前記取得手段によって取得された契約者リストを格納するデータベースと、
前記通信手段によって前記暗号鍵の発行の要求が受信された際、前記データベースに格納されている契約者リストを閲覧し、前記契約者リストに、前記暗号鍵の発行を要求した端末装置のユーザが存在するか否かを判断し、前記ユーザが存在しないと判断したときには、前記端末装置に対する前記暗号鍵の発行を停止するように、前記発行手段を制御する制御手段とを備える
ことを特徴とする設計情報提供システム。
【請求項２】
前記制御手段は、前記通信手段によって前記暗号鍵の発行の要求が受信された際、所定の猶予期間の経過以後だけ、前記データベースに格納されている契約者リストを閲覧する
ことを特徴とする請求項１記載の設計情報提供システム。
【請求項３】
前記第２の設計情報提供サーバは、さらに、前記契約者リストに、前記暗号鍵の発行を要求した前記端末装置のユーザが存在しないと判断したときには、前記端末装置に対する前記暗号鍵を無効化する無効化手段を備える
ことを特徴とする請求項１記載の設計情報提供システム。
【請求項４】
前記制御手段は、前記所定の猶予期間が経過したか否かを判別し、
経過していないと判別したときには、前記契約者リストを閲覧することなく、前記発行手段による前記暗号鍵の発行を許可し、
経過していると判別したときには、前記契約者リストを閲覧し、前記ライセンスの契約の締結を前記契約者リストの閲覧によって確認できなかった端末装置に対する前記暗号鍵の発行を停止するように、前記発行手段を制御する
ことを特徴とする請求項２記載の設計情報提供システム。
【請求項５】
前記特許ライセンス発行サーバの生成手段は、前記第１の設計情報に関する特許に対するライセンス料の支払いがある場合に、前記契約者リストを生成し、
前記第２の設計情報提供サーバは、前記第２の設計情報に対するライセンス料の支払いがある場合に、前記暗号鍵を発行する
ことを特徴とする請求項１記載の設計情報提供システム。
【請求項６】
前記制御手段は、さらに、
前記ライセンスの契約の締結を前記契約者リストによって確認できなかった端末装置に対して、前記特許ライセンス発行サーバとの間における前記ライセンスの契約の締結を促すメッセージを前記通信手段に送信させる
ことを特徴とする請求項１記載の設計情報提供システム。
【請求項７】
商品を製造するユーザの端末装置と通信し、前記商品の製造に必要であって且つ前記商品に固有の第２の設計情報である暗号鍵の発行の要求を受信する通信手段と、
前記暗号鍵の発行を要求した前記端末装置に当該暗号鍵を発行する発行手段と、
前記商品の製造に必要な仕様を示す第１の設計情報に関する特許のライセンスの契約を締結した端末装置のユーザの一覧を示す契約者リストを取得する取得手段と、
前記取得手段によって取得された契約者リストを格納するデータベースと、
前記通信手段によって前記暗号鍵の発行の要求が受信された際、前記データベースに格納されている契約者リストを閲覧し、前記契約者リストに、前記暗号鍵の発行を要求した端末装置のユーザが存在するか否かを判断し、前記ユーザが存在しないと判断したときには、前記端末装置に対する前記暗号鍵の発行を停止するように、前記発行手段を制御する制御手段とを備える
ことを特徴とする設計情報提供サーバ。
【請求項８】
設計情報提供サーバが設計情報を提供する設計情報提供方法であって、
前記設計情報提供サーバは、通信手段と、発行手段と、取得手段と、格納手段と、制御手段とを備え、
前記通信手段が、商品を製造するユーザの端末装置と通信し、前記商品の製造に必要であって且つ前記商品に固有の第２の設計情報である暗号鍵の発行の要求を受信する通信ステップと、
前記発行手段が、前記暗号鍵の発行を要求した前記端末装置に当該暗号鍵を発行する発行ステップと、
前記取得手段が、前記商品の製造に必要な仕様を示す第１の設計情報に関する特許のライセンスの契約を締結した端末装置のユーザの一覧を示す契約者リストを取得する取得ステップと、
前記格納手段が、前記取得ステップで取得された契約者リストをデータベースに格納する格納ステップと、
前記制御手段が、前記通信ステップで前記暗号鍵の発行の要求が受信された際、前記データベースに格納されている契約者リストを閲覧し、前記契約者リストに、前記暗号鍵の発行を要求した端末装置のユーザが存在するか否かを判断し、前記ユーザが存在しないと判断したときには、前記端末装置に対する前記暗号鍵の発行を停止するように、前記発行ステップを制御する制御ステップとを含む
ことを特徴とする設計情報提供方法。
【請求項９】
請求項８に記載の設計情報提供方法に含まれるステップをコンピュータに実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、設計情報提供システムおよび設計情報提供サーバに関し、特に、ユーザが製造する商品に固有の設計情報を提供する技術に関する。
【背景技術】
【０００２】
例えば、現行のＤＶＤ−Ｖｉｄｅｏでは、ＤＶＤコンソーシアムの下、図１５に示されるように、フォーマット、暗号鍵、特許の各ライセンスの契約の締結が個別に行われている。
【０００３】
ここで、フォーマットとは、例えば、ディスクの物理構造、ディスクに記録するデータの構造等を記述した仕様書を指す。
【０００４】
また、一般ユーザによるコンピュータを用いたカジュアルコピーを防止するため、暗号鍵による暗号を利用したＤＶＤ著作権保護システムＣＳＳ（Ｃｏｎｔｅｎｔ  Ｓｃｒａｍｂｌｅ  Ｓｙｓｔｅｍ）が開発されている。ＤＶＤに記録するコンテンツは、３階層の鍵（タイトル鍵、ディスク鍵、マスタ鍵）を用いて暗号化される。ＤＶＤプレーヤには、ＣＳＳ管理機構よりライセンスを受けたメーカに対応したマスタ鍵が予め秘密に埋め込まれている。このＤＶＤプレーヤだけがこれを復号、再生できる仕組みを備えている（非特許文献１参照）。
【０００５】
また、ＤＶＤに大容量のコンテンツを記録するため、コンテンツを効率的に圧縮符号化し、伸張復号化する特許技術等も採用されている。
【０００６】
したがって、ＤＶＤに記録された暗号化されたコンテンツを再生するＤＶＤプレーヤ等を製造するメーカは、各ライセンスを取得し、各ライセンスについてライセンス料を支払うのが一般的である。
【非特許文献１】Ｎａｔｉｏｎａｌ  Ｔｅｃｈｎｉｃａｌ  Ｒｅｐｏｒｔ  第４３巻  第３号  松崎なつめ等著「ＤＶＤ著作権保護システム」、松下電器産業株式会社  技術総務センター、平成９年６月１８日、ｐ１１８−１２２
【発明の開示】
【発明が解決しようとする課題】
【０００７】
しかしながら、従来のシステムでは、以下のような問題がある。なおここでは、問題の所在を明確にするために、図１６に示されるように、ライセンサＡ，Ｂが独立に２つ存在する場合を想定する。そして、同じ製品に対して適用されるライセンサＡのライセンスと、ライセンサＢのライセンスが互いに独立して存在するものとする。ライセンサＡのライセンスは、ライセンスを受けなくても商品製造が可能な設計情報（例えば、上記した伸張復号化技術）についての特許ライセンスであり、ライセンサＢのライセンスは、ライセンスを受けないと商品製造が不可能な設計情報（例えば、上記のマスタ鍵等の秘密鍵）についてのライセンスである。
【０００８】
このような条件の下では、ライセンサＢからはライセンスを受けるが、ライセンサＡのライセンスを受けずに商品製造するメーカが存在しうる。
【０００９】
このような場合、ライセンサＡは特許権によりその商品の差し止めや、損害賠償を請求することも可能であるが、工場の移転等により権利行使も困難である。
【００１０】
したがって、特許ライセンスの契約を締結しないと、製品生産が継続できないような仕組みが要望されている。
【００１１】
そこで、本発明は特許ライセンスの契約を締結しないと、製品生産が継続できないような仕組みを備えた設計情報提供システムおよび設計情報提供サーバを提供することを目的とする。
【課題を解決するための手段】
【００１２】
ここで、本願発明者は、設計情報にも、これがないと商品を作れない情報（例えば暗号鍵）と、そうでない情報（例えば、伸張復号化技術に関する特許情報）とがある。そして、これがないと商品を作れない設計情報については、ライセンスの契約締結への強制力があり、契約締結への源となることに着目した。つまり、契約締結への源を元に、ライセンスの契約締結への強制力を利用して他のライセンサのライセンスについても契約締結できることに想到した。
【００１３】
そこで、上記目的を達成するために、本発明に係る設計情報提供システムは、商品を製造するユーザが使用する端末装置と、第１および第２の設計情報提供サーバと、前記商品の製造に必要な特許についてライセンスの契約を前記端末装置と締結する特許ライセンス発行サーバとを、通信可能に接続する設計情報提供システムであって、前記第１の設計情報提供サーバは、前記商品の製造に必要な仕様を示す第１の設計情報を前記端末装置に送信し、前記特許ライセンス発行サーバは、前記第１の設計情報に関する特許のライセンスの契約を締結した端末装置のユーザの一覧を示す契約者リストを生成する生成手段と、前記生成手段が生成した契約者リストを外部へ出力する出力手段とを備え、前記第２の設計情報提供サーバは、前記商品の製造に必要であって且つ前記商品に固有の第２の設計情報である暗号鍵の発行の要求を前記端末装置から受信する通信手段と、前記暗号鍵の発行を要求した前記端末装置に当該暗号鍵を発行する発行手段と、前記出力手段が出力した契約者リストを取得する取得手段と、前記取得手段によって取得された契約者リストを格納するデータベースと、前記通信手段によって前記暗号鍵の発行の要求が受信された際、前記データベースに格納されている契約者リストを閲覧し、前記契約者リストに、前記暗号鍵の発行を要求した端末装置のユーザが存在するか否かを判断し、前記ユーザが存在しないと判断したときには、前記端末装置に対する前記暗号鍵の発行を停止するように、前記発行手段を制御する制御手段とを備えることを特徴とする。
また、上記目的を達成するために、本発明に係る設計情報提供システムにおいては、商品を製造する第１ユーザが使用する端末装置と、前記商品の製造に必要な特許についてライセンスの契約を前記端末装置の第１ユーザと締結する第２ユーザが使用する特許ライセンス発行サーバと、前記商品に固有の設計情報を提供するための設計情報提供サーバとを、通信可能に接続する設計情報提供システムであって、前記特許ライセンス発行サーバは、前記ライセンスの契約の締結を確認するための確認情報を生成する確認情報生成手段と、前記確認情報生成手段が生成した確認情報を外部へ出力する確認情報出力手段とを備え、前記設計情報提供サーバは、前記設計情報の発行を要求をした端末装置に当該設計情報を発行するための設計情報発行手段と、前記確認情報出力手段が出力した確認情報を取得する確認情報取得手段と、前記確認情報によって前記ライセンスの契約の締結を確認できなかった端末装置に対する前記設計情報の発行を停止するように、前記設計情報発行手段を制御する制御手段とを備えることを特徴とする。
【００１４】
これにより、特許ライセンス発行サーバのユーザであるライセンサと端末装置のユーザとの間でライセンスの契約の締結が促進され、特許ライセンスを支払わないと、製品生産が継続できないような仕組みを形成することができる。
【００１５】
また、本発明に係る設計情報提供システムにおいては、前記確認情報は、前記ライセンスの契約を締結した第１ユーザの一覧を示す契約者リストであり、前記制御手段は、所定の猶予期間の経過以後だけ前記契約者リストを閲覧し、閲覧の結果、当該契約者リストに掲載されていない第１ユーザの端末装置に対する前記設計情報の発行を停止するように、前記設計情報発行手段を制御することを特徴とすることができる。
【００１６】
これにより、端末装置や、特許ライセンス発行サーバ、暗号鍵発行サーバに対して要求されるリソースが小さく、性能的・費用的負荷も小さなシステムにも適用でき、端末装置が特許ライセンス発行サーバとライセンスを締結していることの確認にも、猶予期間のあるシステムを確立することができる。
【００１７】
また、本発明に係る設計情報提供システムにおいては、前記確認情報は、前記ライセンスの契約を締結した当該端末装置に対して契約の締結を証明するために発行される契約証明書であり、前記制御装置は、前記端末装置から前記商品に固有の設計情報の発行の要求がある毎に、前記契約証明書により契約の締結を確認し、確認された端末装置に対して前記設計情報の発行を許可するように、前記設計情報発行手段を制御することを特徴とすることもできる。
【００１８】
これにより、特許ライセンス発行サーバのユーザであるライセンサと端末装置のユーザとの間でライセンスの契約の締結がより一層促進され、特許ライセンスを支払わないと、製品生産が継続できないような仕組みを素早く形成することができる。
【００１９】
また、本発明に係る設計情報提供システムにおいては、前記設計情報の発行要求に、要求する前記設計情報の数量と、前記契約証明書とを含めることが可能であり、前記設計情報提供サーバは、さらに前記端末装置と通信する通信手段を備え、前記制御手段は、前記設計情報の発行要求に前記契約証明書が含まれていない場合、前記設計情報を発行できない旨のメッセージを前記端末装置に送信するよう前記通信手段に指示することを特徴としてもよい。
【００２０】
また、本発明に係る設計情報提供システムにおいては、前記制御手段は、前記設計情報の発行要求に前記契約証明書が含まれている場合、前記契約証明書が有効であるか否かを判断し、有効でない場合には前記設計情報を発行できない旨のメッセージを前記端末装置に送信するよう前記通信手段に指示することを特徴としてもよい。
【００２１】
また、本発明に係る設計情報提供システムにおいては、前記契約証明書には、前記ライセンスの有効期間が含まれており、前記制御手段は、前記契約証明書が有効である場合には、前記ライセンスが有効であるか否かを判断し、前記ライセンスが有効でない場合には前記設計情報を発行できない旨のメッセージを前記端末装置に送信するよう前記通信手段に指示することを特徴としてもよい。
【００２２】
また、本発明に係る設計情報提供システムにおいては、前記制御手段は、前記ライセンスが有効である場合には、前記設計情報の要求に含まれる要求数量が契約数量内の数量であるか否かを判断し、契約数量を超える数量については前記設計情報を発行できない旨のメッセージを前記端末装置に送信するよう前記通信手段に指示することを特徴としてもよい。
【００２３】
また、本発明に係る設計情報提供システムにおいては、前記制御手段は、前記設計情報の要求に前記契約証明書が含まれ、前記契約証明書が有効で、前記ライセンスが有効で、かつ前記設計情報の要求に含まれる要求数量が契約数量内の数量である場合に、要求数量の設計情報を発行するように前記発行手段を制御し、発行された設計情報を前記端末装置に送信するように前記通信手段を制御することを特徴としてもよい。
【００２４】
これにより、設計情報とライセンスとがリンクされ、ライセンス契約を結んでいないと、設計情報をもらえず、ライセンス契約が切れると、設計情報をもらえなくすることができる。また、設計情報の発行数により、特許ライセンス向けにも製造台数を把握することもできる。
【００２５】
また、本発明に係る設計情報提供システムにおいては、前記設計情報は、暗号鍵であり、前記設計情報提供サーバは、さらに、前記商品がライセンスを受けていることを示すためのシールを前記端末装置のユーザに発行するシール発行手段を有し、前記制御手段は、発行する設計情報の数に応じた数量のシールを発行するように前記シール発行手段を制御することを特徴としてもよい。
【００２６】
これにより、シールを商品に添付することで、ライセンスを受けているかどうかを明示的にすることができ、シールがないことで、同じ暗号鍵を複数用いた不正な製品や、非ライセンス製品を目立たせることもできる。この結果、不正な製品や、非ライセンス製品であることの判明が容易になり、取り締まりも容易になる。
【００２７】
また、前記設計情報は、暗号鍵であり、前記設計情報提供サーバは、さらに、前記ライセンスの契約の締結を確認できなかった端末装置に対する前記暗号鍵を無効化する無効化手段を備えることを特徴とすることができる。
【００２８】
これにより、特許ライセンス発行サーバのユーザであるライセンサと端末装置のユーザとの間でライセンスの契約の締結がさらに一層促進され、特許ライセンスを支払わないと、製品生産が継続できないような仕組みを素早く形成することができる。
【００２９】
なお、本発明は、このような設計情報提供システムとして実現することができるだけでなく、このような設計情報提供システムを構成する設計情報提供サーバとして実現したり、設計情報提供サーバが備える特徴的な手段をステップとする設計情報提供方法として実現したり、それらのステップをコンピュータに実行させるプログラムとして実現したりすることもできる。そして、そのようなプログラムは、ＣＤ−ＲＯＭ等の記録媒体やインターネット等の伝送媒体を介して配信することができるのはいうまでもない。
【発明の効果】
【００３０】
以上の説明から明らかなように、本発明に係る設計情報提供システムおよび設計情報提供サーバによれば、特許ライセンス発行サーバのユーザであるライセンサと端末装置のユーザとの間でライセンスの契約の締結が促進され、特許ライセンスを支払わないと、製品生産が継続できないような仕組みを形成することが可能になるという効果が奏される。また、設計情報とライセンスとがリンクされ、ライセンス契約を結んでいないと、設計情報をもらえず、ライセンス契約が切れると、設計情報をもらえなくすることができる。また、設計情報の発行数により、特許ライセンス向けにも製造台数を把握することもできる。
【００３１】
さらに、シールを商品に添付することで、ライセンスを受けているかどうかを明示的にすることができ、シールがないことで、同じ暗号鍵を複数用いた不正な製品や、非ライセンス製品を目立たせることもできる。この結果、不正な製品や、非ライセンス製品であることの判明が容易になり、取り締まりも容易になる。
【００３２】
よって、本発明により、ライセンスの契約の締結が促進され、ＤＶＤや、ＢＤが普及してきた今日における本願発明の実用的価値は極めて高い。
【発明を実施するための最良の形態】
【００３３】
以下、本発明の実施の形態について、図面を用いて詳細に説明する。
【００３４】
（実施の形態１）
図１は、本実施の形態１におけるシステムの全体構成を示す図である。
【００３５】
設計情報提供システム１は、商品を製造するユーザに対して、特許などのライセンスの締結を促しつつ、設計情報およびライセンスを提供するシステムである。
【００３６】
なお、ここでは、下記の前提を元に説明する。
前提１：第１の設計情報（例えば、仕様書）と、第２の設計情報（例えば、暗号鍵８０）が揃って、商品（例えば、ＢＤ（ブルーレイディスク）プレーヤ５０）の製造が可能となる。
【００３７】
前提２：第２の設計情報（暗号鍵８０）は、ライセンシが製造する商品の個別性に関する情報である。そして、暗号鍵８０があって初めてＢＤプレーヤ５０の製造が可能となるので、暗号鍵８０についてのライセンスを締結する必要があり、締結する強制力がある。
【００３８】
前提３：第３の設計情報は、商品の内容に関する情報（例えば、コンテンツ復号技術情報）であり、特許公報等から取得されるものである。そして、この情報を利用して商品を正当に製造するためには、特許ライセンスを締結する必要があるが、締結する強制力がない。
【００３９】
図１に示されるように、設計情報提供システム１は、ＢＤプレーヤ５０の製造に必要な第１の設計情報としての仕様書を提供する仕様書サーバ１０と、ＢＤプレーヤ５０の製造に必要なコンテンツ復号技術についての特許ライセンスを発行する特許ライセンス発行サーバ２０ａと、ＢＤプレーヤ５０の製造に必要な暗号鍵８０を発行する暗号鍵発行サーバ３０ａと、ＢＤプレーヤ５０を製造するユーザ（ライセンシ）が使用する端末装置４０ａと、これらを接続するインターネット等のネットワークとから構成される。
【００４０】
ＢＤプレーヤ５０を製造する場合、ライセンシの端末装置４０ａは、仕様書サーバ１０に第１の設計情報（仕様書）を要求する。仕様書サーバ１０は、仕様書の要求があると、仕様書をライセンシの端末装置４０ａに提供する。仕様書には、特許ライセンスを提供する特許ライセンス発行サーバ２０ａのＩＰアドレスや、暗号鍵８０を提供する暗号鍵発行サーバ３０ａのＩＰアドレスが記載されている。
【００４１】
ライセンシの端末装置４０ａは、第１のライセンス発行サーバ（特許ライセンス発行サーバ２０ａ）に対して、契約台数等と共に契約要求を実施し、この契約台数に相当するライセンス料を支払う。ライセンス料の支払いがあると、特許ライセンス発行サーバ２０ａは、ライセンシの端末装置４０ａに契約証明書６０を送信する。
【００４２】
契約証明書６０の提供を受けたライセンシの端末装置４０ａは、欲しい第２の設計情報（暗号鍵８０）の数量と共に契約証明書６０を含む鍵発行要求７０を第２のライセンス発行サーバ（暗号鍵発行サーバ３０ａ）に送信し、暗号鍵８０を要求する。なお、また、鍵発行要求７０とともに、暗号鍵発行サーバ３０ａに対して、契約数量と共に契約要求を実施し、契約数量に相当するライセンス料を支払ってもよいが、ここでは、特許ライセンス発行サーバ２０ａの場合と同様に、事前に暗号鍵発行サーバ３０ａに対して、契約数量と共に契約要求を実施し、契約数量に相当するライセンス料を支払っているものとして説明する。
【００４３】
鍵発行要求７０があると、第２のライセンス発行サーバは、鍵発行要求７０に含まれる契約証明書の正当性を確認し、鍵発行要求７０で要求された数量分の暗号鍵８０の設計情報をライセンシに提供する。
【００４４】
次いで、設計情報提供システム１を構成する各装置の構成について説明する。なお、この設計情報提供システム１では、仕様書サーバ１０が仕様書を提供するだけであるので、仕様書サーバ１０の構成の詳細についての説明を省略する。
【００４５】
図２は、図１に示される特許ライセンス発行サーバ２０ａ、暗号鍵発行サーバ３０ａおよび端末装置４０ａの詳細な構成を示すブロック図である。
【００４６】
特許ライセンス発行サーバ２０ａは、自社ライセンス管理ＤＢ２１と、契約証明書作成部２２と、通信部２３と、制御部２４とを備える。
【００４７】
自社ライセンス管理ＤＢ２１は、自社で所有する特許に関するライセンスを管理する。自社ライセンス管理ＤＢ２１の管理内容としては、ライセンシ名（ライセンスＩＤ）、契約期間、契約数量、ライセンス料等がある。
【００４８】
契約証明書作成部２２は、特許ライセンス発行サーバの署名を含み、ライセンスの契約を証明する契約証明書６０を生成する。この契約証明書６０のフォーマット構成例を図３に示す。
【００４９】
契約証明書６０は、図３に示されるように、契約証明書６０の発行日付６１と、契約を締結したライセンシのライセンシ名（ライセンシＩＤ）６２と、契約期間６３と、契約数量６４と、この契約証明書６０を特定する契約書ＩＤ６５と、特許ライセンス発行サーバ２０ａが施した、上記発行日付６１〜契約書ＩＤ６５に対するデジタル署名６６とから構成される。
【００５０】
通信部２３は、ネットワークを介して端末装置４０ａ等と通信する。
制御部２４は、自社ライセンス管理ＤＢ２１〜通信部２３を統括制御する。具体的には、制御部２４は、端末装置４０ａから契約台数等と共に契約要求や、この契約台数に相当するライセンス料の支払いがあると、この特許ライセンスを自社ライセンス管理ＤＢ２１で管理させ、契約証明書作成部２２にこの特許ライセンスに対応する契約証明書６０を作成させ、作成された契約証明書６０を通信部２３を介して端末装置４０ａに送信する。
【００５１】
端末装置４０ａは、ライセンス管理ＤＢ４１と、契約証明書管理ＤＢ４２と、通信部４３と、制御部４４とを備える。
【００５２】
ライセンス管理ＤＢ４１は、仕様書サーバ１０から取得した仕様書や、特許ライセンス発行サーバ２０ａから取得した特許ライセンスおよびその特許情報、暗号鍵発行サーバ３０ａから取得したライセンスおよびその暗号鍵８０を管理する。
【００５３】
契約証明書管理ＤＢ４２は、特許ライセンス発行サーバ２０ａから取得した契約証明書６０を管理する。
【００５４】
通信部４３は、ネットワークを介して仕様書サーバ１０、特許ライセンス発行サーバ２０ａおよび暗号鍵発行サーバ３０ａ等と通信する。
【００５５】
制御部４４は、ライセンス管理ＤＢ４１〜通信部４３を統括制御する。具体的には、制御部４４は、通信部４３を介して、仕様書サーバ１０に仕様書を要求したり、仕様書サーバ１０から仕様書を受信したり、特許ライセンス発行サーバ２０ａに契約を要求したり、特許ライセンス発行サーバ２０ａから特許ライセンスや契約証明書６０を受けたり、要求する暗号鍵の数量と契約証明書とを含む鍵発行要求７０を生成し、生成した鍵発行要求７０を暗号鍵発行サーバ３０ａに送信したり、暗号鍵発行サーバ３０ａから必要量の暗号鍵８０を受けたりする。この鍵発行要求７０のフォーマット構成例を図４に示す。
【００５６】
鍵発行要求７０は、図４に示されるように、契約を締結したライセンシのライセンシ名（ライセンシＩＤ）７１と、要求する暗号鍵の数量７２と、特許ライセンス発行サーバ２０ａとの間の契約を証明するための契約証明書７３とから構成される。
【００５７】
暗号鍵発行サーバ３０ａは、自社ライセンス管理ＤＢ３１と、他社ライセンスリンク管理ＤＢ３２と、暗号鍵発行部３３と、通信部３４と、制御部３５とを備える。
【００５８】
自社ライセンス管理ＤＢ３１は、自社で所有するライセンスを管理する。自社ライセンス管理ＤＢ３１の管理内容としては、特許ライセンス発行サーバ２０ａの自社ライセンス管理ＤＢ２１の管理内容と同様に、ライセンシ名（ライセンスシＩＤ）、契約期間、契約数量、ライセンス料等がある。
【００５９】
他社ライセンスリンク管理ＤＢ３２は、暗号鍵８０と他社の特許ライセンスとをリンクさせるため、発行した暗号鍵８０の数量、契約証明書６０に含まれる契約数量等を管理する。
【００６０】
暗号鍵発行部３３は、ＢＤプレーヤ５０毎に固有の暗号鍵８０を発行する。
通信部３４は、ネットワークを介して端末装置４０ａ等と通信する。
【００６１】
制御部３５は、自社ライセンス管理ＤＢ３１〜通信部３４を統括制御する。具体的には、制御部３５は、端末装置４０ａから契約台数等と共に契約要求や、この契約台数に相当するライセンス料の支払いがあると、暗号鍵８０発行についてのライセンスを自社ライセンス管理ＤＢ３１で管理させる。また、暗号鍵８０の要求数量と契約証明書６０とを含む鍵発行要求７０があると、制御部３５は、有効な契約証明書６０を他社ライセンスリンク管理ＤＢ３２で管理させたり、暗号鍵発行処理を実行したりする。
【００６２】
図５は、暗号鍵発行サーバ３０ａの制御部３５によって行われる暗号鍵発行処理の動作を示すフローチャートである。
【００６３】
制御部３５は、通信部３４を介して鍵発行要求を受信するのを待つ（Ｓ１１）。鍵発行要求を受信すると（Ｓ１１でＹｅｓ）、制御部３５は、契約証明書が添付されているか否か判断する（Ｓ１２）。契約証明書が添付されていない場合（Ｓ１２でＮｏ）、制御部３５は、暗号鍵を発行できない旨のメッセージの送信を通信部３４に指示する（Ｓ１７）。なお、このメッセージに代えて、あるいはこのメッセージと共に、特許ライセンサとの間におけるライセンスの契約を締結すべき旨のメッセージを送信するようにしてもよい。
【００６４】
契約証明書が添付されていると（Ｓ１２でＹｅｓ）、制御部３５は、その契約証明書が有効か否か判断する（Ｓ１３）。この判断は、デジタル署名が正しいか否かによって行われる。
【００６５】
契約証明書が有効でない場合（Ｓ１３でＮｏ）、制御部３５は、暗号鍵を発行できない旨のメッセージの送信を通信部３４に指示する（Ｓ１７）。
【００６６】
契約証明書が有効であると（Ｓ１３でＹｅｓ）、制御部３５は、特許ライセンスが有効であるか否か判断する（Ｓ１４）。この判断は、特許ライセンスについての契約期間内であるかによって行われる。最も、暗号鍵のライセンスについての契約期間内であるかによっても行われるのはいうまでもない。なお、契約証明書に期間についての項目がない等の場合には、ステップ１４の判断を省略することができる。
【００６７】
特許ライセンスが有効でない場合（Ｓ１４でＮｏ）、制御部３５は、暗号鍵を発行できない旨のメッセージの送信を通信部３４に指示する（Ｓ１７）。
【００６８】
特許ライセンスが有効である場合（Ｓ１４でＹｅｓ）、制御部３５は、要求数量が契約数量内の暗号鍵の数量であるか否か判断する（Ｓ１５）。この判断は、具体的には、今回要求された暗号鍵の数量と、これまでに発行された暗号鍵の数量とのトータルと、特許ライセンスについての契約数量と比較によって行われる。最も、今回要求された暗号鍵の数量と、これまでに発行された暗号鍵の数量とのトータルと、暗号鍵のライセンスについての契約数量と比較によっても行われるのはいうまでもない。
【００６９】
要求数量が契約数量内の暗号鍵の数量でない場合（Ｓ１５でＮｏ）、制御部３５は、暗号鍵を発行できない旨のメッセージの送信を通信部３４に指示する（Ｓ１７）。なお、要求数量には足りないが契約数量が残っている場合には、残りの分の暗号鍵を発行すると共に、その契約数量を超える数量については前記設計情報を発行できない旨のメッセージを前記端末装置に送信するように通信部３４に指示するようにしてもよい。
【００７０】
要求数量が契約数量内の暗号鍵の数量である場合（Ｓ１５でＹｅｓ）、制御部３５は、暗号鍵発行部３３に要求数量の暗号鍵を発行することを指示し、通信部３４に発行された暗号鍵を送信することを指示する（Ｓ１６）。
【００７１】
すなわち、ステップＳ１２〜Ｓ１５のいずれかでＮｏである場合、暗号鍵を発行できない旨のメッセージが送信される。したがって、ＢＤプレーヤ５０を製造するためには、暗号鍵８０を取得する必要上、暗号鍵８０が「ライセンス締結強制力の源」となり、有効な契約証明書６０の提出が必要となる。そして、暗号鍵８０のライセンスの締結強制力により、ライセンス締結強制力の無い特許ライセンスについても、ライセンスの契約を推進することができ、特許ライセンサとの間におけるライセンスの契約締結が確保されることになる。
【００７２】
また、ステップＳ１２〜Ｓ１５の全てでＹｅｓである場合、つまり、契約証明書６０の確認を条件として、暗号鍵と特許ライセンスとがリンクされることになる。したがって、特許ライセンス契約を結んでいないと、「暗号鍵」をもらえず、特許ライセンス契約が切れると、「暗号鍵」をもらえなくすることができる。また、暗号鍵の発行数により、特許ライセンス向けにも製造台数を把握することもできる。
【００７３】
（実施の形態２）
次いで、実施の形態２に係るシステムについて説明する。
【００７４】
図６は、本実施の形態２におけるシステムの全体構成を示す図である。なお、実施の形態１の設計情報提供システム１の構成と対応する部分に同じ番号を付し、その説明を省略する。
【００７５】
ところで、“機器に個別性を持たせる”「第２の設計情報」である暗号鍵８０も、一部台数のみを正規に契約して入手して、複数利用される可能性がある。このような場合、その不正を見抜くのには、非常に困難である。このため、実施の形態２に係る設計情報提供システム２は、暗号鍵発行サーバ３０ａに代えて、暗号鍵８０の数に応じた数量のホログラムシール９０を、端末装置４０ａに対して発行する機能を有する暗号鍵発行サーバ３０ｂが用いられて構成されている。端末装置４０ａに対して発行されたホログラムシール９０は、ライセンスを受けていることの証として、製造されたＢＤプレーヤ５０の目立ちやすい箇所に貼着される。なお、暗号鍵８０の数に応じたホログラムシール９０の数量として、暗号鍵の数と同数が望ましい。また、製品への貼り損ないなどを考慮して、一定割合分を増やして発行してもよく、この場合には増分の使用量の報告を義務づけたり、貼り損なったシールの返却を義務づけることなどにより、暗号鍵とホログラムシール９０との対応関係を維持するようにしてもよい。
【００７６】
図７は、暗号鍵発行サーバ３０ｂの構成を示すブロック図である。
図７に示されるように、暗号鍵発行サーバ３０ｂは、暗号鍵発行サーバ３０ａを構成する自社ライセンス管理ＤＢ３１〜制御部３５の他、さらにホログラムシール発行部３６と、無効化鍵入力部３７とを備えて構成される。
【００７７】
ホログラムシール発行部３６は、制御部３５の指示に基づき、暗号鍵発行部３３によって発行される暗号鍵８０と同数のホログラムシール９０を発行する。
【００７８】
無効化鍵入力部３７は、ユーザから指示された無効化すべき暗号鍵の情報の入力を受け付ける。無効化すべき暗号鍵の情報は、制御部３５の指示に基づき、公開鍵証明書を発行するＣＡに送られ、公開鍵証明書無効化リスト（ＣＲＬ）に掲載されたり、コンテンツを暗号化してＢＤに記録するメーカ等に通知される。
【００７９】
図８は、暗号鍵発行サーバ３０ｂの制御部３５によって行われる暗号鍵発行処理の動作を示すフローチャートである。なお、図５の暗号鍵発行処理と対応する部分に同じステップ番号を付し、その説明を省略する。
【００８０】
暗号鍵発行部３３に要求数量の暗号鍵を発行することを指示し、通信部３４に発行された暗号鍵を送信することを指示し終わると（Ｓ１６）、制御部３５は、ホログラムシール発行部３６に要求数量のホログラムシールを発行することを指示し、ユーザ等に発行されたホログラムシール９０を送付することを指示する（Ｓ１８）。つまり、暗号鍵８０と同数のホログラムシール９０が、端末装置４０ａのライセンシに対して送付される。
【００８１】
ここで、このホログラムシール９０は、光を照射すると特定のマークが浮き出るものであり、偽造できないものである。
【００８２】
このため、ホログラムシール９０を商品に添付することで、ライセンスを受けているかどうかを明示的にすることができ、ホログラムシール９０がないことで、同じ暗号鍵８０を複数用いた不正な製品や、非ライセンス製品を目立たせることもできる。これにより、不正な製品や、非ライセンス製品であることの判明が容易になり、取り締まりも容易になる。
【００８３】
そして、暗号鍵８０が各機器に個別のものであり、契約台数を把握するためにも、暗号鍵８０の重複使用は許可しないことを確保するため、ホログラムシール９０のないＢＤプレーヤ５０を見つけた場合、そのＢＤプレーヤ５０の暗号鍵８０を解析し、その暗号鍵８０の情報を無効化鍵入力部３７から入力することにより、その暗号鍵を無効化する。
【００８４】
ここで、認証ベースの場合において、暗号鍵が認証用に使用される場合、認証（Ｃｈａｌｌｅｎｇｅ−Ｒｅｓｐｏｎｓｅ認証）の前に、公開鍵暗号については、証明書の交換が発生する。その際、認証側は、ＣＲＬ（証明書無効化リスト）に、無効化される暗号鍵に対応する証明書ＩＤを記し、当該暗号鍵は使用できなくすることができる。
【００８５】
図９は、公開鍵暗号を用いたＣｈａｌｌｅｎｇｅ−Ｒｅｓｐｏｎｓｅ認証の例を示す図である。なお、図中に示されるＳCAは、認証局ＣＡの秘密鍵を、ＰCAはＳCAに対する公開鍵を、ＳXは被認証者Ｘの秘密鍵を、ＰXはＳXに対応する公開鍵を、ＣｅｒｔXはＰXに対応する公開鍵証明書を、Ｓｉｇｎはデジタル署名アルゴリズムを、ＶｅｒｉｆｙはＳｉｇｎの検証アルゴリズムを、ＣｅｒｔXはＩＤX||ＰX||（「ＩＤX||ＰX」に対するＣＡのデジタル署名）をそれぞれ示している。なお、ＣｅｒｔXのフォーマットはこの例に限定されず、他のフォーマットでもよい。
【００８６】
被認証者Ｘは、認証要求と、ＣｅｒｔXとを認証者Ｙに転送する（Ｓ２１）。
認証者Ｙは、ＣＲＬにＣｅｒｔXが掲載されていないかどうかチェックする（Ｓ２２）。
【００８７】
掲載されている場合（Ｓ２２でＮＧ）、認証者Ｙは、認証を拒否する（Ｓ２３）。掲載されていない場合、認証者Ｙは、Ｖｅｒｉｆｙ（ＰCA，ＩＤX||ＰX，ＣｅｒｔXの署名部分）で、ＣｅｒｔXが正しい証明書かどうかを確認する（Ｓ２４）。確認の結果、ＮＧの場合、ステップＳ２３を実行する。
【００８８】
証明書が正しかったら、認証者Ｙは、乱数Ｃｈａを生成し（Ｓ２５）、Ｃｈａを被認証者Ｘに送信する（Ｓ２６）。
【００８９】
被認証者Ｘは、Ｃｈａに対して、ＳXを用いてデジタル署名Ｒｅｓを生成する（Ｓ２７）。ここで、Ｒｅｓ＝Ｓｉｇｎ（ＳX，Ｃｈａ）である。そして、被認証者Ｘは、Ｒｅｓを認証者Ｙに送信する（Ｓ２８）。
【００９０】
認証者Ｙは、Ｖｅｒｉｆｙ（ＰX，Ｃｈａ，Ｒｅｓ）で、ＲｅｓがＣｈａに対する正しいデジタル署名かどうかを確認する（Ｓ２９）。確認の結果、ＮＧの場合、ステップＳ２３を実行する。確認の結果、ＯＫならば、通信相手が確かにＸであることを認証する（Ｓ３０）。
【００９１】
このような処理を行うことにより、重複使用された暗号鍵の使用を排除することができる。
【００９２】
また、認証ベースの場合において、共通鍵暗号の場合は、認証側が同じ共通鍵データを保持することになるので、認証側で無効化を認識（上記のようなリストが存在する）して、認証を拒否すればよい。
【００９３】
さらに、ＣＲＬは使わないで一部の鍵を無効化する技術である暗号鍵ブロックの場合においては、ＭＫＢ技術（特開２０００−３１９２２号公報）や、ＲＫＢ技術（特開２００２−２８１０１３号公報）などのように、コンテンツ鍵を、機器に与える、認証に用いる共通鍵としてのデバイス鍵（暗号鍵８０に相当）をベースに、「効率的に暗号化」して送ることで、無効化された暗号鍵を保持する機器では、コンテンツ鍵を入手できなくすることができる。
【００９４】
したがって、このような処理を行うことによっても、重複使用された暗号鍵の使用を排除することができる。
【００９５】
なお、上記実施の形態２ではホログラムシール９０により実施したが、透かし（Ｗａｔｅｒｍａｒｋ）を含むデータを保持する機器貼着型のＩＣタグ等のシールにより、ライセンスを受けていることの証の存否を検証するようにしてもよい。
【００９６】
（実施の形態３）
次いで、実施の形態３に係るシステムについて説明する。
【００９７】
図１０は、本実施の形態３におけるシステムの全体構成を示す図である。なお、実施の形態１，２の設計情報提供システム１，２の構成と対応する部分に同じ番号を付し、その説明を省略する。
【００９８】
ところで、設計情報提供システム１，２では、端末装置４０ａが特許ライセンス発行サーバ２０ａとライセンスを締結していることを契約証明書６０で確認している。しかしながら、契約証明書６０でライセンスの締結を確認しようとすると、端末装置４０ａや、特許ライセンス発行サーバ２０ａ、暗号鍵発行サーバ３０ａ，３０ｂに対して要求されるリソースが大きくなり、性能的・費用的負荷も大きくなる。このため、端末装置や、特許ライセンス発行サーバ、暗号鍵発行サーバに対して要求されるリソースが小さく、性能的・費用的負荷も小さな設計情報提供システムが望まれる。
【００９９】
また、設計情報提供システム１，２では、端末装置４０ａから暗号鍵発行サーバ３０ａに鍵発行要求７０があった時点で、端末装置４０ａの使用者が特許ライセンス発行サーバ２０ａとライセンスを締結していることを確認している。しかしながら、プレーヤ５０を設計するためにはそれなりの期間を必要とし、設計が終わって初めてライセンスを締結したりするであるのが通例である。このため、端末装置が特許ライセンス発行サーバとライセンスを締結していることの確認にも、所定の猶予期間のある設計情報提供システムが望まれる。
【０１００】
そこで、この設計情報提供システム３においては、特許ライセンス発行サーバ２０ｂは、契約証明書６０に代えてライセンスの契約を締結した端末装置のユーザの一覧を示す契約者リスト１００を生成し、生成した契約者リスト１００を暗号鍵発行サーバ３０ｃに配信するように構成されている。そして、暗号鍵発行サーバ３０ｃは、所定の猶予期間が経過するまでは契約者リスト１００の確認ナシで暗号鍵８０を発行するが、所定の猶予期間が経過した以降は契約者リスト１００によって端末装置４０ａの使用者が特許ライセンス発行サーバ２０ａとライセンスを締結しているか否かを確認し、締結していなければ暗号鍵８０の発行を停止するように構成されている。
【０１０１】
図１１は、図１０に示される特許ライセンス発行サーバ２０ｂ、暗号鍵発行サーバ３０ｃおよび端末装置４０ｂの詳細な構成を示すブロック図である。なお、図２に示される特許ライセンス発行サーバ２０ａ、暗号鍵発行サーバ３０ａおよび端末装置４０ａの構成と対応する部分に同じ番号を付し、その説明を省略する。
【０１０２】
図１１に示されるように、特許ライセンス発行サーバ２０ｂは、契約証明書作成部２２に代えて、契約者リスト１００を作成する契約者リスト作成部２６を備えている。この契約者リスト１００は、図１２に示されるように、ライセンサを特定するためのライセンサ名１０１と、ライセンスの対象となる対象特許１０２と、ライセンスを締結したライセンシの名を特定するためのライセンシ名１０３等とから構成される。この契約者リスト１００は、対象特許１０２について新たなメーカとライセンスの契約を締結したり、ライセンスの契約が切れたりする、つまりライセンシ名１０３の内容が変わる毎に生成される。なお、契約者リスト１００にライセンス期間、数量、地域や、特許発明の実体化の形態（ＩＣチップ等）を示すライセンス内容を含めるようにしてもよい。
【０１０３】
端末装置４０ｂは、端末装置４０ａから契約証明書管理ＤＢ４２が削除されて構成される。
【０１０４】
暗号鍵発行サーバ３０ｃの他社ライセンスリンク管理ＤＢ３２は、特許ライセンス発行サーバ２０ｂから配信された契約者リスト１００を格納したりして管理する。自社ライセンス管理ＤＢ３１は、一連の鍵発行要求７０や、暗号鍵発行部３３によって発行された鍵の発行日、発行数等を管理する。制御部３５は、所定の猶予期間が経過するまでは契約者リスト１００の確認ナシで暗号鍵８０を発行するが、所定の猶予期間が経過した以降は他社ライセンスリンク管理ＤＢ３２が管理する契約者リスト１００によって端末装置４０ａの使用者が特許ライセンス発行サーバ２０ａとライセンスを締結しているか否かを確認する。
【０１０５】
図１３は、暗号鍵発行サーバ３０ｃの制御部３５が実行する暗号鍵発行処理の動作を示すフローチャートである。
【０１０６】
制御部３５は、通信部３４を介して鍵発行要求を受信したか否かを判断する（Ｓ１１）。鍵発行要求を受信すると（Ｓ１１でＹｅｓ）、制御部３５は、その鍵発行要求７０が最初の鍵発行要求であるか否か判断する（Ｓ２１）。最初の鍵発行要求である場合（Ｓ２１でＹｅｓ）、制御部３５は、暗号鍵発行部３３に要求数量の暗号鍵を発行することを指示し、通信部３４に発行された暗号鍵を送信することを指示する（Ｓ２２）。
【０１０７】
鍵発行要求を受信していない場合（Ｓ１１でＮｏ）、あるいは最初の発行要求でない場合（Ｓ２１でＮｏ）、つまり、不定期に、制御部３５は、ライセンス締結の確認時期が到来したか否か判断する（Ｓ２３）。このライセンス締結の確認時期は、例えば最初の鍵発行から１年６月を経過する日、あるいは第１のライセンスサーバ（特許ライセンス発行サーバ２０ｂ）のライセンス開始から２年経過した日が挙げられる。このような日は、端末装置４０ｂの使用者がプレーヤ５０を設計し終えるのに必要な猶予期間として十分であるからである。
【０１０８】
ライセンス締結の確認時期が到来していると、制御部３５は、他社ライセンスリンク管理ＤＢ３２で管理されている契約者リスト１００を閲覧し、この契約者リスト１００のライセンシ名１０３に端末装置４０ｂの使用者名が存在しているか否かを判断する（Ｓ２５）。使用者名が存在していない場合（Ｓ２５でＮｏ）、制御部３５は、暗号鍵の発行を停止する（Ｓ２６）。なお、この暗号鍵の発行を停止する際に、制御部３５は、暗号鍵を発行できない旨のメッセージの送信を通信部３４に指示してもよく、このメッセージに代えて、あるいはこのメッセージと共に、特許ライセンサとの間におけるライセンスの契約を締結すべき旨のメッセージを送信するようにしてもよい。
【０１０９】
ライセンス締結の確認時期が到来していない場合（Ｓ２３でＮｏ）、あるいはライセンス締結の確認時期が到来後、契約者リスト１００に端末装置４０ｂの使用者名が存在している場合（Ｓ２５でＹｅｓ）、制御部３５は、暗号鍵発行部３３に要求数量の暗号鍵を発行することを指示し、通信部３４に発行された暗号鍵を送信することを指示する（Ｓ２２）。
【０１１０】
つまり、ステップＳ１１，２１のいずれかでＮｏで、ステップＳ２３でＹｅｓ、かつステップＳ２５でＮｏである場合、暗号鍵発行が停止される。したがって、ＢＤプレーヤ５０を製造するためには、暗号鍵８０を取得する必要上、暗号鍵８０が「ライセンス締結強制力の源」となり、ライセンスの契約の締結が必要となる。そして、暗号鍵８０のライセンスの締結強制力により、ライセンス締結強制力の無い特許ライセンスについても、ライセンスの契約を推進することができ、特許ライセンサとの間におけるライセンスの契約締結が確保されることになる。
【０１１１】
また、所定の猶予期間の経過後は、契約者リスト１００による契約確認を条件として、暗号鍵と特許ライセンスとがリンクされることになる。したがって、特許ライセンス契約を結んでいないと、「暗号鍵」をもらえず、特許ライセンス契約が切れると、「暗号鍵」をもらえなくすることができる。
【０１１２】
したがって、端末装置や、特許ライセンス発行サーバ、暗号鍵発行サーバに対して要求されるリソースが小さく、性能的・費用的負荷も小さなシステムにも適用でき、端末装置が特許ライセンス発行サーバとライセンスを締結していることの確認にも、猶予期間のあるシステムを確立することができる。
【０１１３】
（実施の形態４）
なお、上述の実施の形態３の設計情報提供システム３では、特許ライセンス発行サーバ２０ｂが暗号鍵発行サーバ３０ｃに契約者リスト１００を直接配信するようにしたが、図１４に示される設計情報提供システム４のように特許ライセンス発行サーバ２０ｂが契約者リスト１００をホームページＨＰにアップロードし、暗号鍵発行サーバ３０ｄの他社ライセンスリンク管理ＤＢ３２がホームページＨＰから契約者リスト１００をダウンロードするようにしてもよい。この場合には、特許ライセンス発行サーバ２０ｂは契約者リスト１００が存在するホームページＨＰのＵＲＬを暗号鍵発行サーバ３０ｄに予め通知しておき、暗号鍵発行サーバ３０ｄの他社ライセンスリンク管理ＤＢ３２が、制御部３５の指示によりステップＳ２３を実行するタイミングで契約者リスト１００をダウンロードすればよい。
【産業上の利用可能性】
【０１１４】
本発明の設計情報提供システムは、製造されるＤＶＤプレーヤやＢＤプレーヤの製造において適用することができる。
【図面の簡単な説明】
【０１１５】
【図１】本実施の形態１におけるシステムの全体構成を示す図である。
【図２】図１に示される特許ライセンス発行サーバ２０ａ、暗号鍵発行サーバ３０ａおよび端末装置４０ａの詳細な構成を示すブロック図である。
【図３】図１に示される契約証明書６０のフォーマット構成例を示す図である。
【図４】図１に示される鍵発行要求７０のフォーマット構成例を示す図である。
【図５】暗号鍵発行サーバ３０ａの制御部３５によって行われる暗号鍵発行処理の動作を示すフローチャートである。
【図６】本実施の形態２におけるシステムの全体構成を示す図である。
【図７】図６に示される暗号鍵発行サーバ３０ｂの構成を示すブロック図である。
【図８】暗号鍵発行サーバ３０ｂの制御部３５によって行われる暗号鍵発行処理の動作を示すフローチャートである。
【図９】公開鍵暗号を用いたＣｈａｌｌｅｎｇｅ−Ｒｅｓｐｏｎｓｅ認証の例を示す図である。
【図１０】本実施の形態３におけるシステムの全体構成を示す図である。
【図１１】図１０に示される特許ライセンス発行サーバ２０ｂ、暗号鍵発行サーバ３０ｃおよび端末装置４０ｂの詳細な構成を示すブロック図である。
【図１２】図１０に示される契約者リスト１００の構成例を示す図である。
【図１３】暗号鍵発行サーバ３０ｃの制御部３５が実行する暗号鍵発行処理の動作を示すフローチャートである。
【図１４】本実施の形態４におけるシステムの全体構成を示す図である。
【図１５】現行のＤＶＤ−Ｖｉｄｅｏにおけるライセンスの契約の締結関係を示す図である。
【図１６】ライセンサＡ，Ｂが独立に２つ存在する場合におけるライセンスの締結関係を示す図である。
【符号の説明】
【０１１６】
１，２，３，４  設計情報提供システム
１０  仕様書サーバ
２０ａ，２０ｂ  特許ライセンス発行サーバ
２２  契約証明書作成部
２６  契約者リスト作成部
３０ａ，３０ｂ，３０ｃ，３０ｄ  暗号鍵発行サーバ
３１  自社ライセンス管理ＤＢ
３２  他社ライセンスリンク管理ＤＢ
３３  暗号鍵発行部
３４  通信部
３５  制御部
３６  ホログラムシール発行部
３７  無効化鍵入力部
５０  ＢＤプレーヤ
６０  契約証明書
７０  鍵発行要求
８０  暗号鍵
９０  ホログラムシール
１００  契約者リスト
【図１】
0004823807.tif 000002
【図２】
0004823807.tif 000003
【図３】
0004823807.tif 000004
【図４】
0004823807.tif 000005
【図５】
0004823807.tif 000006
【図６】
0004823807.tif 000007
【図７】
0004823807.tif 000008
【図８】
0004823807.tif 000009
【図９】
0004823807.tif 000010
【図１０】
0004823807.tif 000011
【図１１】
0004823807.tif 000012
【図１２】
0004823807.tif 000013
【図１３】
0004823807.tif 000014
【図１４】
0004823807.tif 000015
【図１５】
0004823807.tif 000016
【図１６】
0004823807.tif 000017