令和3(行ケ)10064審決取消請求事件

令和４年４月２８日判決言渡
令和３年（行ケ）第１００６４号 審決取消請求事件
口頭弁論終結日 令和４年２月１日
判 決
原 告 三 星 電 子 株 式 会 社
同訴訟代理人弁理士 佐 藤 英 昭
吉 田 豊 麿
丸 山 亮
林 晴 男
松 本 邦 夫
被 告 特 許 庁 長 官
同 指 定 代 理 人 山 崎 慎 一
田 中 秀 人
中 村 則 夫
冨 澤 美 加
主 文
１ 原告の請求を棄却する。
２ 訴訟費用は原告の負担とする。
３ この判決に対する上告及び上告受理申立てのための付加期間を３０
日と定める。
事実及び理由
第１ 請求
特許庁が不服２０１８－１５５５６号事件について令和２年１２月９日にし
た審決を取り消す。
第２ 事案の概要
１ 特許庁における手続の経緯等
⑴ エーサー・クラウド・テクノロジイ・インコーポレイテッド（以下「エー
サー」という。）は、平成１９年９月１３日（優先日平成１８年１１月９日、
同月１６日（以下「本願優先日」という。 、優先権主張国米国）を国際出願
）
日とする特許出願（特願２００９－５３６２２７号）の一部を分割した特許
出願（特願２０１３－２１４４４０号）の一部を更に分割した特許出願（特
願２０１５－１４９２２４号）を更に分割して、平成２９年３月２７日、発
明の名称を「サーバ」とする発明について、新たな特許出願（特願２０１７
－６０５０４号。以下「本願」という。）をした（甲１）。
エーサーは、同年１０月３０日付けの拒絶理由通知（甲５）を受けた後、
平成３０年２月１４日付けで、特許請求の範囲及び発明の名称について手続
補正をした（上記手続補正後の発明の名称は「サーバとこのサーバにより認
証されるクライアント装置」。甲１２）。
エーサーは、同年７月６日付けで、上記手続補正による特許請求の範囲の
補正について却下決定（甲１４）を受けるとともに、拒絶査定（甲１３）を
受けた。
⑵ エーサーは、平成３０年１１月２６日、拒絶査定不服審判（不服２０１８
−１５５５６号事件。甲１５）を請求した。
エーサーは、令和元年８月１９日付けの拒絶理由通知（甲１９）を受けた
ため、令和２年１月２７日付けで特許請求の範囲について手続補正（以下「本
件補正」という。甲２４）をした。
特許庁は、同年１２月９日、「本件審判の請求は、成り立たない。」との審
決（以下「本件審決」という。甲３２）をし、その謄本は、令和３年１月１
２日、エーサーに送達された。
その後、原告は、エーサーから、本願に係る特許を受ける権利の譲渡を受
け、同年３月１８日付けで、その旨の出願人名義変更届をした（甲３４、３
５）。
⑶ 原告は、令和３年５月１２日、本件審決の取消しを求める本件訴訟を提起
した。
２ 特許請求の範囲の記載
本件補正後の特許請求の範囲の請求項１の記載は、次のとおりである（以下、
請求項１に係る発明を「本願発明」という。甲２４）。
【請求項１】
数発生器と、
証明書リクエストモジュールと、
証明書検証モジュールと、
前記数発生器、前記証明書リクエストモジュール、及び前記証明書検証モジ
ュールに接続するインターフェースとを備えるとともに、不揮発性メモリを有
したクライアント装置を認証するためのサーバであって
動作において、
前記数発生器が第１の数を生成し、
前記証明書リクエストモジュールは、デバイス証明書のリクエストを生成し、
前記第１の数と前記デバイス証明書のリクエストは前記インターフェースを
介してクライアント装置に送られ、
前記第１の数と、
前記クライアント装置において該クライアント装置の製造中にプログラ
ムされたプライベートキーと前記サーバの数発生器が作成した第１の数を使
用して生成される第２の署名と、
前記クライアント装置の装置ＩＤ、発行者ＩＤ、前記プライベートキーの
関数である公開鍵及び前記クライアント装置の不揮発性メモリから読み出さ
れた第１の署名の関数として生成されたデバイス証明書と
を含むレスポンスが前記インターフェースで受け取られ、
前記証明書検証モジュールは前記デバイス証明書と第２の署名とを認証し、
前記サーバの数発生器が発生した第１の数と前記クライアント装置からの第
１の数が一致しているか否かを検証する
ことを特徴とするサーバ。
３ 本件審決の理由の要旨
⑴ 本件審決の理由は、別紙審決書（写し）記載のとおりである。
その要旨は、本願発明は、本願優先日前に頒布された刊行物である特開２
００６－９２２８１号公報（以下「引用文献１」という。甲６）に記載され
た発明及び特開２００４－１３５３２５号公報（以下「引用文献２」という。
甲２６）、特開２００６－１８７０９号公報（以下「引用文献３」という。甲
２７）、特開２００３－３２３３４２号公報（以下「引用文献４」という。甲
２８）に記載の技術事項に基づいて、当業者が容易に発明をすることができ
たものであり、特許法２９条２項の規定により特許を受けることができない
から、本願は拒絶すべきものであるというものである。
⑵ 本件審決が認定した引用文献１に記載された発明（以下「引用発明」とい
う。 、本願発明と引用発明の一致点及び相違点は、次のとおりである。
）
なお、原告は、引用文献１に引用発明の記載があることを認めている。
ア 引用発明
証明書要求部と、
乱数生成部と、
証明書検証部を有し、フラッシュメモリ１５１を有するセキュリティデ
バイス１０２の認証を行う、ＣＰ３０３であって、
前記乱数生成部は、乱数を生成し、
前記証明書要求部は、前記乱数を含む、セキュリティデバイス証明書を
要求するリクエストを生成して、前記リクエストを、前記セキュリティデ
バイス１０２に送信し、
前記セキュリティデバイス１０２から、セキュリティデバイス証明書と、
前記乱数に対して施した電子署名とを応答として受信し、
前記電子署名を前記セキュリティデバイス証明書を用いて検証する、Ｃ
Ｐ３０３。
イ 本願発明と引用発明の一致点及び相違点
（一致点）
「数発生器と、
証明書リクエストモジュールと、
証明書検証モジュールとを備えるとともに、
不揮発性メモリを有したクライアント装置を認証するためのサーバであ
って、
前記数発生器が第１の数を生成し、
前記証明書リクエストモジュールは、証明書のリクエストを生成し、
前記第１の数と前記証明書のリクエストは前記クライアント装置に送ら
れ、
前記クライアント装置において該クライアント装置の製造中にプログ
ラムされたプライベートキーと前記サーバの数発生器が作成した第１の
数を使用して生成される第２の署名と、証明書と
を含むレスポンスが受け取られ、
前記証明書検証モジュールは前記証明書と第２の署名とを認証する、サ
ーバ。」である点
（相違点１）
本願発明は、
「数発生器、前記証明書リクエストモジュール、及び前記証
明書検証モジュールに接続するインターフェース」を備えるものであるの
に対して、
引用発明においては、
「インターフェース」について、特に、言及されて
いない点。
（相違点２）
“証明書”に関して、
本願発明においては、
「クライアント装置の装置ＩＤ、発行者ＩＤ、前記
プライベートキーの関数である公開鍵及び前記クライアント装置の不揮
発性メモリから読み出された第１の署名の関数として生成されたデバイ
ス証明書」であるのに対して、
引用発明においては、 セキュリティデバイス証明書」
「 の詳細については、
特に、言及されていない点。
（相違点３）
“リクエスト”に関して、
本願発明においては、「リクエストは前記インターフェースを介してク
ライアント装置に送られ」るものであるのに対して、
引用発明においては、「リクエスト」が、「インターフェース」を介して
送信されることについては、特に、言及されていない点。
（相違点４）
“レスポンス”に関して、
本願発明においては、「レスポンス」が、「第１の数」を含むものである
のに対して、
引用発明においては、「応答」が、「乱数」を含む点については、特に、
言及されていない点。
（相違点５）
本願発明においては、「レスポンスが前記インターフェースで受け取ら
れ」るものであるのに対して、
引用発明においては、「応答」が、「インターフェース」で受信されるこ
とについては、特に、言及されていない点。
（相違点６）
本願発明においては、「サーバの数発生器が発生した第１の数と前記ク
ライアント装置からの第１の数が一致しているか否かを検証する」もので
あるのに対して、
引用発明においては、
「乱数」の一致に関しては、特に、言及されていな
い点。
４ 取消事由
引用文献１を主引用例とする本願発明の進歩性の判断の誤り
第３ 当事者の主張
１ 原告の主張
⑴ 一致点の認定の誤り
ア 「クライアント装置」に係る一致点の認定の誤り
本件審決は、引用発明の「セキュリティデバイス１０２」が本願発明の
「クライアント装置」に相当するとの認定を前提に、本願発明と引用発明
は、「前記第１の数と前記証明書のリクエストは前記クライアント装置に
送られ」る点で一致すると認定した。
しかし、引用発明は、
「セキュリティデバイス１０２」が「情報端末１０
１」に装着されて「情報端末１０１」と通信するように構成され，本願発
明の「サーバ」に相当する引用発明の「ＣＰ３０３」には「情報端末１０
１」が無線ネットワークを介して接続される構成であることからすると、
本願発明の「クライアント装置」に相当するのは、引用発明の「情報端末
１０１」であって、
「セキュリティデバイス１０２」でないから、本件審決
の上記一致点の認定は誤りである。
イ 「第２の署名」に係る一致点の認定の誤り
本件審決は、引用発明の「乱数に施した電子署名」が本願発明の「クラ
イアント装置において該クライアント装置の製造中にプログラムされた
プライベートキーと前記サーバの数発生器が作成した第１の数を使用し
て生成される第２の署名」に相当するとの認定を前提に、本願発明と引用
発明は、
「レスポンス」が「該クライアント装置の製造中にプログラムされ
たプライベートキーと前記サーバの数発生器が作成した第１の数を使用
して生成される第２の署名」を含む点で一致すると認定した。
しかし、引用発明の「乱数に施した電子署名」とは、その文言から、
「電
子署名を乱数に施した」ことを意味するものであり、電子署名自体には、
変化がなく、
「乱数に施したことで得られた電子署名」とは異なるものであ
る。一方、本願発明の「第１の数を使用して生成される第２の署名」は、
第１の数を使用して新たに生成されるものであり、「乱数に施したことで
得られた電子署名」に対応する署名であることからすると、引用発明の「乱
数に施した電子署名」は、本願発明の「クライアント装置において該クラ
イアント装置の製造中にプログラムされたプライベートキーと前記サー
バの数発生器が作成した第１の数を使用して生成される第２の署名」に相
当するものではないから、本件審決の上記一致点の認定は誤りである。
⑵ 相違点２の容易想到性の判断の誤り
ア 本件審決は、相違点２に関し、
「デバイスＩＤ」「署名」を含む「デバイ
、
ス証明書」については、引用文献３及び４の記載のとおり、本願優先日前
に、当業者に周知の技術事項であり、また、
「証明書」に「発行者ＩＤ」を
含ませることも、引用文献を提示するまでもなく、当業者に周知の技術事
項であるから、引用発明において、
「セキュリティデバイス証明書」 「セ
に、
キュリティデバイス１０２」のＩＤ、
「ＣＰ３０３」のＩＤ等を含ませるよ
う構成すること（相違点２に係る本願発明の構成とすること）は、当業者
が必要に応じて適宜なし得る事項である旨判断した。
しかし、
「デバイス証明書」に「署名」を含むこと自体は、引用文献３及
び４に開示された「公開鍵証明書」にあるように周知技術ではあるが、一
方で、相違点２に係る本願発明の構成は、
「クライアント装置の装置ＩＤ、
発行者ＩＤ、前記プライベートキーの関数である公開鍵及び前記クライア
ント装置の不揮発性メモリから読み出された第１の署名の関数として生
成されたデバイス証明書」というものであり、本願発明の「デバイス証明
書」に含まれる「第１の署名」は、
「第１の署名の関数」として「デバイス
証明書」を生成するためのものであるから、引用文献３及び４記載のよう
な「デバイス証明書」に単に「署名」を含むものと異なるものである。
また、引用文献１には、本願発明の「第１の署名の関数」に対応する記
載はないし、引用文献３及び４に開示された「公開鍵証明書」に含まれる
「署名」は、本願発明の「第１の署名」と同一視できるものではない。
したがって、相違点２に係る本願発明の構成は、引用発明及び引用文献
２ないし４記載の技術事項に基づいて当業者が必要に応じて適宜なし得
る事項であるとはいえないから、本件審決の上記判断は誤りである。
イ これに対し被告は、相違点２に係る本願発明の構成である「クライアン
ト装置の装置ＩＤ、発行者ＩＤ、前記プライベートキーの関数である公開
鍵及び前記クライアント装置の不揮発性メモリから読み出された第１の
署名の関数として生成されたデバイス証明書」とは、
「デバイス証明書」が、
「クライアント装置の装置ＩＤ、発行者ＩＤ、プライベートキーの関数で
ある公開鍵」と、これらを暗号化して生成される「第１の署名」とを含み、
「クライアント装置の装置ＩＤ、発行者ＩＤ、プライベートキーの関数で
ある公開鍵」に「第１の署名」を付して生成されるものであることを特定
するものであるとした上で、本願発明の「第１の署名」は、引用文献３及
び４に開示された「電子署名」と同等のものといえるから、本件審決にお
ける相違点２の容易想到性の判断に誤りはない旨主張する。
しかしながら、本願の願書に添付した明細書（以下、図面を含めて「本
願明細書」という。甲１）には「第１の署名」について「これらを暗号化
して生成される」との記載はなく、
【００６２】には、
「デバイス証明書が、
装置ＩＤ、発行者ＩＤ、公開鍵、署名、及び共通パラメータから作成され
る」こと（「デバイス証明書」に「署名」が含まれること）の記載があるの
みであるから、本願明細書を参酌しても、本願発明の「デバイス証明書」
が、
「クライアント装置の装置ＩＤ、発行者ＩＤ、プライベートキーの関数
である公開鍵」と、これらを暗号化して生成される「第１の署名」とを含
むものと解釈することはできない。
したがって、被告の上記主張は、その前提において失当である。
⑶ 相違点の看過
引用発明は、本願発明の「前記証明書検証モジュールは前記デバイス証明
書と第２の署名とを認証し」との構成を備えるものではない点で本願発明と
相違するが、本件審決は、この点を相違点として認定していないから、本件
審決には、かかる相違点を看過した誤りがある。
すなわち、本願明細書の【００１６】には「サーバ１０２における証明書
検証モジュール１１２は、信頼できる証明書チェーン(trusted certificate
chain)を用いて、証明書Ｃｅｒｔを認証し」との記載があること、証明書チ
ェーンは、認証パスとも呼ばれ、クライアント、サーバなどの証明書から、
中間認証局の証明書、ルート認証局の証明書までの連なりであり、チェーン
内の各証明書が次の証明書よって署名されることでセキュリティを確保する
ように構成されていることは技術常識であることからすると、本願発明の「前
記証明書検証モジュールは前記デバイス証明書と第２の署名とを認証し」と
は、「デバイス証明書」は「証明書チェーン」を用いて認証され、「第２の署
名」は「デバイス証明書」に含まれる公開鍵によって認証されることを意味
するものと解されるが、引用文献１には、引用発明における「セキュリティ
デバイス証明書を用いて検証する」との構成が、このような認証を意味する
ことを示した記載はないから、引用発明は、本願発明の「前記証明書検証モ
ジュールは前記デバイス証明書と第２の署名とを認証し」との構成を備える
ものでない点で本願発明と相違する。
これに対し被告は、引用文献１の【００５７】の「電子署名を…セキュリ
ティデバイス証明書を用いて検証する」との記載は、セキュリティデバイス」
「
が「セキュリティデバイス秘密鍵」を保持していることを「検証」すること
を意味するものであり、また、セキュリティデバイス証明書を用いて検証す
るためには、当該セキュリティデバイス証明書が正当なものであることが確
認できなければならないから、引用発明は、「セキュリティデバイス証明書」
と「電子署名」とをそれぞれ認証するものであるとして、上記相違点の看過
はない旨主張する。
しかし、
「セキュリティデバイス証明書を用いて検証する」とは、あくまで
「セキュリティデバイス証明書」に含まれている情報を検証することであっ
て、
「セキュリティデバイス証明書」そのものを認証するものとはいえないか
ら、被告の上記主張は失当である。
⑷ 小括
以上のとおり，本件審決には，一致点の認定の誤り、相違点２の容易想到
性の判断の誤り及び相違点の看過があるから、本願発明は，引用発明及び引
用文献２ないし４記載の技術事項に基づいて，当業者が容易に発明をするこ
とができたものであるとした本件審決の判断は，誤りである。
したがって、本件審決は取り消されるべきものである。
２ 被告の主張
⑴ 一致点の認定の誤りの主張に対し
ア 「クライアント装置」に係る一致点の認定の誤りの主張に対し
本願発明の特許請求の範囲（請求項１）には、サーバとクライアント装
置との接続が直接であるか間接であるかについて特定がされておらず、サ
ーバとクライアント装置との間に機器が介在する構成が排除されていな
いこと、引用発明の「セキュリティデバイス１０２」は、その機能を見て
も、
「ＣＰ３０３」の「証明書要求部」から「前記乱数を含む、セキュリテ
ィデバイス証明書を要求するリクエスト」が送信されてこれを受信し、
「セ
キュリティデバイス証明書と、前記乱数に対して施した電子署名とを応答
として」返信した上で、「ＣＰ３０３」において、「前記セキュリティデバ
イス証明書を用いて検証」されるものであり、
「サーバ」によって認証され
る「クライアント装置」といい得ることからすると、引用発明の「セキュ
リティデバイス１０２」が本願発明の「クライアント装置」に相当するこ
とは明らかである。
したがって、引用発明の「セキュリティデバイス１０２」が本願発明の
「クライアント装置」に相当するとした本件審決の一致点の認定に誤りは
ない。
また、仮に引用発明の「セキュリティデバイス１０２」と「情報端末１
０１」とを合わせたものを、本願発明の「クライアント装置」に相当する
ものと対比したとしても、引用発明が「クライアント装置」を備える点で
本願発明と一致することに変わりはないから、本件審決の結論に影響しな
い。
イ 「第２の署名」に係る一致点の誤りの主張に対し
「電子署名」は、乱数などの「情報Ａ」を公開鍵暗号方式で用いられる
「公開鍵－秘密鍵」ペアの「秘密鍵」で暗号化して生成され、
「公開鍵」を
用いて「署名検証」されるものであることは、技術常識である（乙１， 。
２）
本願発明の特許請求の範囲（請求項１）には、
「第２の署名」について、
「前記クライアント装置において…プライベートキーと前記サーバの数
発生器が作成した第１の数を使用して生成される」との記載があるところ、
本願明細書の【００１５】及び【００１６】記載の「署名Ｓｉｇ」及び「乱
数Ｒ」は、それぞれ本願発明の「第２の署名」及び「第１の数」に対応す
るものである。そして、上記技術常識を踏まえると、本願発明の「第２の
署名（署名Ｓｉｇ）」は、サーバから送られた「第１の数（乱数Ｒ）」を、
クライアント装置の「プライベートキー」で暗号化して生成され、
「証明書
Ｃｅｒｔ」を用いて署名検証されるものと理解できる。
一方、引用文献１の【００５３】及び【００５４】の記載と上記技術常
識によれば、引用発明の「電子署名」は、ＣＰ３０３から送られてきた「乱
数」を「セキュリティデバイス１０２」の「秘密鍵」で暗号化して生成さ
れ、
「セキュリティデバイス証明書」の「公開鍵」を用いて「署名検証」さ
れるものと理解できる。
そうすると、引用発明の「電子署名」と本願発明の「第２の署名」とは、
証明書に付された電子署名として、その生成についても署名検証について
も相違するところはないから、引用発明の「電子署名」は、本願発明の「第
２の署名」に相当するものといえる。
したがって、本願発明と引用発明は、
「レスポンス」が「該クライアント
装置の製造中にプログラムされたプライベートキーと前記サーバの数発
生器が作成した第１の数を使用して生成される第２の署名」を含む点で一
致するとした本件審決の一致点の認定に誤りはない。
⑵ 相違点２の容易想到性の判断の誤りの主張に対し
本願発明の特許請求の範囲（請求項１）の「前記クライアント装置の装置
ＩＤ、発行者ＩＤ、前記プライベートキーの関数である公開鍵及び前記クラ
イアント装置の不揮発性メモリから読み出された第１の署名の関数として生
成されたデバイス証明書」の記載（相違点２に係る本願発明の構成）の意味
は直ちには明確とはいえない。
しかるところ、本願明細書の【００２３】の「デバイス証明書は公知のも
のである」との記載、セキュア証明書（デバイス証明書）の作成方法の例を
示したフローチャートである図７のうちステップ７０８の記載及び【００６
２】の記載を参酌するとともに、公開鍵証明書に関する技術常識（乙１，２）
を踏まえれば、請求項１の上記記載は、「デバイス証明書」が、「クライアン
ト装置の装置ＩＤ、発行者ＩＤ、プライベートキーの関数である公開鍵」と、
これらを暗号化して生成される「第１の署名」とを含み、
「クライアント装置
の装置ＩＤ、発行者ＩＤ、プライベートキーの関数である公開鍵」に「第１
の署名」を付して生成されるものであることを特定していると理解できる。
そうすると、本願発明の「第１の署名」 「デバイス証明書」
は、 に含まれる、
「プライベートキーの関数である公開鍵」によって署名検証がされると解さ
れるので、引用文献３及び４に開示された「電子署名」と同等のものといえ
るから、本件審決における相違点２の容易想到性の判断に誤りはない。
⑶ 相違点の看過の主張に対し
原告は、本願明細書の【００１６】の記載を根拠として、本願発明の「前
記証明書検証モジュールは前記デバイス証明書と第２の署名とを認証し」に
いう「デバイス証明書」の「認証」とは、
「証明書チェーン」を用いて認証す
ることを意味するが、引用文献１には、引用発明における「セキュリティデ
バイス証明書を用いて検証する」との構成が、このような認証を意味するこ
とを示した記載はないから、引用発明は、本願発明の「前記証明書検証モジ
ュールは前記デバイス証明書と第２の署名とを認証し」との構成を備えるも
のでない点で本願発明と相違し、本件審決には、かかる相違点の看過がある
旨主張する。
ア しかし、本願発明の特許請求の範囲の請求項１には、本願発明の「前記
証明書検証モジュールは前記デバイス証明書と第２の署名とを認証し」に
いう「認証」の具体的な認証方法について特定する記載がないこと、本願
明細書の【００１６】には、サーバが受け取った証明書Ｃｅｒｔを，信頼
できる証明書チェーンを用いて認証することが記載されているが、これは、
証明書Ｃｅｒｔ（デバイス証明書）の認証に係る一実施形態の記載にすぎ
ないことからすると、当該「認証」が証明書チェーンを用いるものである
と限定解釈する必要はない。
イ 引用文献１の【００５７】に、
「アプリケーション発行要求８１３を受信
したＣＰ３０３は、アプリケーション発行要求８１３に含まれていた電子
署名（セキュリティデバイス証明書要求８０２または８１１に含まれてい
た乱数に対する電子署名）を同じくアプリケーション発行要求８１３に含
まれていたＣＰ３０３が発行したセキュリティデバイス証明書を用いて
検証して（署名検証８１４） セキュリティデバイス１０２がＣＰ３０３が
、
発行したセキュリティデバイス証明書に対応するセキュリティデバイス
秘密鍵を保持していることを検証し」と記載されているように、引用発明
のＣＰ３０３は、
「電子署名」を「セキュリティデバイス証明書」を用いて
「検証」することによって、
「セキュリティデバイス秘密鍵」を保持してい
ることを「検証」するものであり、これは、本願発明の「デバイス証明書」
を「認証」することに対応する。
そして、
「セキュリティデバイス証明書」を用いて「電子署名」を検証す
るためには、まず、当該「セキュリティデバイス証明書」が正当なもので
あることが確認できなければならないが、そのためには、当該「セキュリ
ティデバイス証明書」が正当なものであることを検証することができる情
報が含まれていなければならないこと、公開鍵証明書に関する技術常識を
踏まえれば、当該「セキュリティデバイス証明書」には、
「公開鍵」に加え
て、当該「セキュリティデバイス証明書」が正当なものであることを保証
する「署名（署名値）」が含まれることは、当業者にとって明らかである。
そうすると、引用発明のＣＰ３０３は、
「セキュリティデバイス証明書」
を受け取れば、当然に当該「署名（署名値）」を署名検証し、「セキュリテ
ィデバイス証明書」に含まれている情報が改ざんされていないことを確か
めることになり、これは、
「セキュリティデバイス証明書」を認証すること
にほかならないから、引用発明は、
「セキュリティデバイス証明書」と「電
子署名」とをそれぞれ認証するものである。
したがって、本件審決には、原告主張の相違点の看過はない。
⑷ 小括
以上のとおり，本件審決における一致点の認定及び相違点２の容易想到性
の判断に誤りはなく、また、本件審決に相違点の看過はないから、本願発明
は，引用発明及び引用文献２ないし４記載の技術事項に基づいて，当業者が
容易に発明をすることができたものであるとした本件審決の判断に誤りはな
い。
したがって、原告主張の取消事由は理由がない。
第４ 当裁判所の判断
１ 一致点の認定の誤りについて
⑴ 本願明細書の記載事項
本願明細書（甲１）には、次のような記載がある（下記記載中に引用する
図１、３、５ないし７については別紙１を参照）。
ア 【技術分野】
【０００１】
セキュアプロセッサは通常、ＩＤ、及び／又は格納された秘密鍵を含む。
セキュリティレベルを高めるために、ある量(quantities)の秘密鍵などが、
チップ内不揮発性メモリにプログラミングされて、セキュアプロセッサを
作ることがある。ＩＤ及び秘密鍵のプログラミングは、チップのセキュア
製造プロセスにおいて行われる。それぞれのＩＤは固有のものであり、プ
ライベートキーも又固有のものである。これらの量(these quantities)は、
デジタル権利管理や他のセキュリティ関連アプリケーションを実行する
ため、装置上のアプリケーションで使用される。通常、チップは、ネット
ワーク・プロトコル、秘密鍵などにおいて、使い捨てデータとして使用す
るために、暗号学的に強力な乱数を生成するメカニズムを含む。
【背景技術】
【０００２】
デジタル権利管理を実行するために使用される典型的なインフラにおい
て、サーバは、装置に対する権利を有効にするため、デジタル的に署名さ
れたチケットを供給するのに使用される。そのようなチケットは、装置に
チケットを結びつけるために、かかる装置のアイデンティティ、及び／又
は秘密鍵メカニズムを使用する。それぞれの装置ＩＤ／鍵の独自性を確実
にするため、サーバは通常、セキュア・データベースを使って、製造され
た各チップに対応するＩＤ（及び／又は署名された証明書）を格納してい
る。これらの証明書は、チップにプログラミングされた各秘密鍵（（プライ
ベートキー、公開鍵）ペアのプライベートキー）に対応する公開鍵を含ん
でいる。データベースに証明書を投入するためには、データベースに関連
するインフラを確実に製造プロセスに結び付け、製造されたチップとデー
タベース内の証明書の間で１対１対応を維持しなければならない。
【０００３】
上述したこれら関連技術の例や制限事項は、あくまで説明に役立つもの
として例証したものであって排他的ではない。関連技術の他の制限事項は、
当該技術者が本願明細書を読み、図面を検討することにより明らかになる
であろう。
【発明が解決しようとする課題】
【０００４】
以下の実施形態とその特徴は、あくまで例証的であって範囲を制限しな
いことを意図したシステム、ツール、および方法に関連して記載、図示さ
れる。種々の実施形態では、上述した問題の１つ又はそれ以上が低減又は
解消され、一方では他の実施形態がその他の改善に向けられる。
【０００５】
改善されたセキュア・プログラミング技術は、セキュアデバイスによっ
てサポートされる典型的なセキュア・アプリケーションを可能とすると同
時に、オンチップ秘密不揮発性メモリにプログラミングされるビットサイ
ズを減少させることを含む。また、改善されたセキュア・プログラミング
技術は、システムの製造プロセスを簡素化することを含む。一実施形態に
おいて、秘密事項のプログラミングは、オンチッププログラミングに対し
分離されており、特にシステム統合やインフラ設定のプロセスからは分離
される。
イ 【課題を解決するための手段】
【０００６】
セキュア・プログラミング技術は、チップの製造を、チケットを取得す
るために、チケットサーバに接続する後処理から分離させることを含む。
この技術に沿った方法は、チケットを受け取るための如何なる通信に先だ
って、装置から（製造）サーバの署名が入った証明書を送ることを含んで
も良い。この方法は、データベースを投入し、例えばちょうどチケットサ
ービスが必要となる時など、後のチケットサービス実行を容易にすること
を含んでも良い。
【０００７】
本技術に沿った装置は、製造プロセスにおいて、証明書をプライベート
キーと共に格納するためのチップ内不揮発性メモリを含んでも良い。プラ
イベートキーは、楕円カーブをベースとするプライベートキーであっても、
またそうでなくとも良い。楕円カーブの暗号ベースの鍵の長所は、相対的
な暗号強度にしては、多くの種類の鍵より小さいことである。更に、楕円
曲線アルゴリズムを使用し、無作為のプライベートキーを保存すると共に、
ランタイム計算によって公開鍵を算出することが可能である。
【０００８】
有利な点としては、特にオンチップ・リアルエステートを考慮して、圧
縮された証明書を不揮発性メモリ内に設けることが可能なことがある。
（デバイス証明書を保存するために必要とされるものより）より小さなデ
ータセットを使用して、かかる装置はデバイス上にダイナミックに証明書
を作成し、それを要求するアプリケーションに提供する。デバイス証明書
を複数回作っても、また作らなくとも良い。例えば、一旦デバイス証明書
を作成し、更なる使用に備えてシステムの外部記憶装置に格納するように
しても良い。このことは証明書が公知データであるため、特に不安定なこ
とではない（セキュアでない訳ではない）。
【０００９】
本技術によって構築された装置は、他の分野においても適用性を持つ可
能性がある。例えば、ピア又は、第１のデバイス証明書を必要とする如何
なるアプリケーションに対しても装置を認証することができる。またこれ
とは別に、不揮発性メモリにプログラミングするためのセキュアな製造プ
ロセスを使い、不揮発性メモリは、装置のためのセキュアな乱数発生器を
含んでも良い。
ウ 【発明を実施するための形態】
【００１１】
以下の説明では、本発明の実施形態の十分な理解を与えるために幾つか
の特定の具体的な構成が提示される。しかし、当業者であれば、１つ以上
のこれら特定の具体的な構成がなくとも、あるいは他の構成部などとの組
み合わせにより、本発明を実施することが可能であることが理解されるで
あろう。また別の例では、様々な実施形態における本発明の側面を覆い隠
すことがないように、周知の具体的構成は、図示または詳細に説明されて
いない。
【００１２】
図１は、サーバにおいてクライアントを認証する(validating)ためのシ
ステム１００の一例を示している。図１の例でシステム１００は、サーバ
１０２、ネットワーク１０４、及びクライアント１０６を含む。サーバ１
０２は、証明書リクエストモジュール１１０、証明書検証モジュール１１
２、証明書データベース１１４、擬似乱数（ＰＲＮ）発生器１１６、及び
インターフェース１１８を含む。クライアント１０６は、証明書作成モジ
ュール１２０、不揮発性（ＮＶ）メモリ１２２、及びインターフェース１
２４を含む。
【００１３】
サーバ１０２は、如何なる適用可能な公知の（又は手頃な）コンピュー
タであっても良い。ネットワーク１０４は、非限定的な例として、インタ
ーネットを含む如何なる通信ネットワークでも良い。クライアント１０６
は、セキュア記憶装置（技術的に安全性が保証された記憶装置）を有する、
如何なる適用可能な公知の（又は手頃な）コンピュータであっても良い。
不揮発性メモリ１２２はセキュア鍵ストアを含んでもよく、一実施形態で
は同不揮発性メモリ１２２はオンチップメモリである。
【００１４】
図１の例では、動作において、レジストレーション(registration)用又
はアクティベーション(activation)用プロトコルが、サーバ１０２によっ
て起動される（或いは、クライアント１０６が、レジストレーション又は
アクティベーションを起動するようにしても良い） 一実施形態では、
。 プロ
トコルは、装置の同一性(a device identity)を登録(register)したり、証
明書データベース１１４に証明書を与えたりする（certificate into）役
割を果たす。そのために、乱数発生器１１６は、乱数Ｒを生成し、サーバ
１０２の証明書リクエストモジュール１１０は、デバイス証明書のリクエ
ストを生成する。乱数Ｒとデバイス証明書のリクエストは、インターフェ
ース１１８を介して、ネットワーク１０４へと送られる。
【００１５】
乱数Ｒとデバイス証明書のリクエストは、クライアント１０６のインタ
ーフェース１２４で受け取られる。クライアント１０６の証明書作成モジ
ュール１２０は、証明書Ｃｅｒｔを作成する。証明書Ｃｅｒｔを作成する
のに使用されるアルゴリズム例としては、図７を参照して以下に説明する。
証明書作成モジュール１２０は、デバイス・プライベートキーを使用し、
乱数Ｒ上の署名Ｓｉｇを算出する。オペランド(operands)は、不揮発性メ
モリ１２２に格納されているが、それらは例えばセキュリティカーネル
（図５参照）にあるようにしても良い。また別の実施形態では、上記演算
には、装置ＩＤ、シリアルナンバー、リージョンコード、或いはその他幾
つかの数値を含む場合もある。クライアント１０６のインターフェース１
２４は、ネットワーク１０４に対し、乱数Ｒや何らかの任意データ、証明
書Ｃｅｒｔ、及び証明書Ｓｉｇを返す。
【００１６】
サーバ１０２Ｒは、インターフェース１１８で、乱数Ｒ、任意データ、
証明書Ｃｅｒｔ、及び署名Ｓｉｇを受けとる。サーバ１０２における証明
書 検 証 モ ジ ュ ー ル １ １ ２ は 、 信 頼 で き る 証 明 書 チ ェ ー ン (trusted
certificate chain)を用いて、証明書Ｃｅｒｔを認証し、証明書Ｃｅｒｔ
を用いて署名Ｓｉｇを認証し、更に乱数Ｒが、元々サーバ１０２によって
クライアント１０６に送られた乱数Ｒと同じであるか否かを検証する。こ
れらの認証及び検証が成功裏に完了したならば、サーバ１０２は、証明書
データベース１１６に証明書Ｃｅｒｔを取り込む。この時点で、クライア
ント１０６が、サーバ１０２から（或いはクライアント１０６に許可を与
える証明書を使用できる、その他幾つかのロケーションから）権利管理コ
ンテンツ(rights managed content)やその他のオペレーションのためのデ
ジタルライセンスを獲得することについて、推定上許可されることになる。
【００１７】
その他の実施形態としては、装置がＲＮＧを使って新しい鍵のペア｛pvt1、
pub1｝を作成し、署名者としてプライベートキーがプログラミングされた
装置を使用して、この新しい公開鍵 pub1 のために証明書が作成される場
合もある。この新しい鍵 pvt1 は、乱数Ｒを持つメッセージに署名するのに
つかわれる場合もある。
【００２３】
図３は、一回だけデバイス証明書を作成する方法の一例のフローチャー
ト３００を示している。図３の例では、フローチャート３００は、モジュ
ール３０２で始まり、ここでデバイス証明書がセキュアデバイスで作成さ
れる。次いでフローチャート３００は、モジュール３０４に進み、該デバ
イス証明書がシステムの外部記憶装置に格納される。装置はセキュア（技
術的に安全性が保証されたもの）であるために、この変化(variation)は注
目に値するが、デバイス証明書は公知のものである。従って、それはその
都度、再生されないが、証明書は依然としてセキュアなものである。
エ 【００３９】
図５は、図１乃至図３を参照して上述した技術を実施するのに適してい
たセキュアシステム５００の一例を示している。代表的なセキュアシステ
ム５００は、ゲーム機、メディアプレーヤー、埋め込み型(embedded)セキ
ュアデバイス、セキュアプロセッサ付き“従来型”PC、或いはセキュアプロ
セッサを備える他のコンピュータ・システムを備えても良い。
【００４９】
図５の例では、チケットサービス５０６とセキュリティ API５１８は、
システムセキュリティのための個々の実行スペースにおいて実行しても
よい。データブロックを有効化するために、チケットサービス５０６は、
ヘッダのデータを使ってチケットを有効にしても良い。そのチケットは、
暗号化された鍵を含んでも良い。チケットサービス５０６は、セキュリテ
ィカーネル５１４におけるサービス（例えば、暗号化/復号化エンジン５１
７）を利用して、鍵を復号化する。
【００５１】
矢印５２０～５２８を以て、システム５００のデータフローの例が例示
を目的として供される。チケットサービス５０６での証明書リクエストの
受取りは、呼出しアプリケーション５０８からチケットサービス５０６へ
の証明書リクエスト矢印５２０によって表わされる。
【００５２】
チケットサービス５０６からセキュリティ API５１６への証明書リクエ
ストの送りは、証明書リクエスト矢印５２２によって表されている。セキ
ュリティカーネル５１４において、公開鍵／デバイス証明書・作成エンジ
ン５１７は、鍵/署名ストア５１８からの鍵／署名データにアクセスする。
このアクセスは、プライベートキー／署名アクセス矢印５２４によって表
されている。セキュリティ API５１６は、デバイス証明書矢印５２６に示
すように、デバイス証明書をチケットサービス５０６に返し、それは更に
デバイス証明書矢印５２８に示すように、呼出しアプリケーション５０８
に転送される。
オ 【００５３】
図６は、セキュアデバイスを製造する方法の例を示すフローチャート６
００である。この方法、及び他の方法は、連続的に並べられたモジュール
の形で表現される。しかしながら、これらの方法における各モジュールは、
並べ替えされたり、並列実行のために適当に並べられたりしても良い。図
６の例において、フローチャート６００は、モジュール６０２でスタート
し、ここで装置ＩＤが取得される。装置ＩＤは、シリアルナンバーであっ
ても、或いは装置のための他の何らかの固有な識別子であっても良い。
【００５４】
図６の例で、フローチャート６００は、モジュール６０４に進み、ここ
では装置のために小署名プライベートキー(a small-signature private
key)として使用する目的で、擬似乱数が供される。今日に至るまで、本当
の意味での乱数というものはコンピュータ上では生成できないが、当然の
ことながら、疑似乱数発生器や外部のセキュアなハードウェアにおける真
性乱数発生器が、ここで意図する目的のために使用できるだろう。小署名
プライベートキーは、これに限定されない例として、楕円カーブプライベ
ートキーや比較的小さなフットプリント(footprint)を持った他の何らか
のプライベートキーでも良い。
【００５５】
図６の例で、フローチャート６００は、モジュール６０６に進み、ここ
では共通パラメータを使用してプライベートキーから公開鍵が算出され
る。例えば、スカラー倍数(scalar multiple)がプライベートキーとなるよ
うに、基点(base point)の倍数が算出されても良い。
【００５６】
図６の例で、フローチャート６００は、モジュール６０８に進み、ここ
では一定の証明書構造(fixed certificate structure)が、証明書を作成
するために使用される。証明書は、例えば楕円カーブＤＳＡなどの小署名
アルゴリズム(small signature algorithm)を使用して署名される。一実
施形態では、該一定の証明書構造は、少なくとも装置ＩＤ、発行者名、及
びデバイス公開鍵を含むかもしれない。小署名アルゴリズムは、署名サイ
ズを最小限におさえるのに使用される。これに限定されない例として、楕
円カーブ署名アルゴリズムが使用されても良い。
【００５７】
図６の例で、フローチャート６００は、モジュール６１０に進み、ここ
では｛装置ＩＤ、プライベートキー、発行者ＩＤ、署名｝が、装置の不非
揮発性メモリにプログラミングされる。このセットは、これらのアイテム
が殆どの目的に対して充分セキュリティを提供するという理由でこれら
４つのアイテムを含んでおり、また該セットは、比較的小さいサイズのプ
ライベートキーと署名のおかげで比較的小さいフットプリントを有する
（推定するに、装置ＩＤ及び発行者ＩＤも又、比較的小さいフットプリン
トを有している）。一実施形態では、例えば公開鍵など、デバイス証明書の
作成(construct)に必要とされる如何なるデータも、要求に応じてプログ
ラミングされた状態で生成されても良い。しかしながら、与えられた実施
形態や実装に見合った形で、より多くのアイテム、又より少ないアイテム
が不揮発性メモリにプログラミングされ得る。
【００５８】
図６の例では、フローチャート６００は、モジュール６１２に進み、秘
密の乱数が装置のＲＯＭにプログラミングされる。この秘密乱数は、疑似
乱数的に生成されても、また任意に割り当てられるようにしても良い。こ
の秘密乱数は、セキュアな擬似乱数の生成をサポートするのに利用できる。
また別の実施形態では、ＲＯＭが、他の公知の（又は手頃な）不揮発性記
憶装置と置き換えられても良い。
カ 【００５９】
図７は、セキュア証明書の作成方法の例を示したフローチャート７００
である。メリットとして、この方法は、不揮発性でプログラミングされた
鍵と必要なソフトウェアを有する装置が、装置認証に使用可能な完全なデ
バイス証明書を作成することを可能にする。図７の例では、フローチャー
ト７００は、モジュール７０２でスタートし、ここではデバイス証明書の
リクエストが、呼出しアプリケーションから受け取られる。
【００６０】
図７の例で、フローチャート７００は、モジュール７０４に進み、ここ
では｛装置ＩＤ、プライベートキー、発行者ＩＤ、署名｝が、不非揮発性
メモリから読み込まれる。一実施形態では、セキュリティカーネル・モジ
ュールが、不揮発性メモリにアクセスして読み込む。この目的のために適
切なセキュリティカーネル・モジュールの例としては、Srinivasan らによ
って２００３年２月７日に出願された“信頼性や下位互換性のあるプロセ
ッサ及びその上でのセキュアソフトウェア実行”というタイトルの米国出
願第１０／３６０、８２７号や、Srinivasan らによって２００６年１０月
２４日に出願された“セキュアデバイス認証システム及び方法”というタイ
トルの米国出願第１１／５８６、４４６号に記載されている。しかしなが
ら、如何なる適用可能な公知の（又は手頃な）セキュリティカーネル・モ
ジュールでも使用可能である。
【００６１】
図７の例で、フローチャート７００は、モジュール７０６に進み、ここ
では公開鍵が、プライベートキーと（もしあるならば）共通パラメータと
によって算出される。一実施形態では、この演算は、図６を参照して上述
した方法のような製造プロセスに使用されたのと同じアルゴリズムを利
用する。公開鍵は、セキュリティカーネルで算出されても良い。
【００６２】
図７の例で、フローチャート７００は、モジュール７０８に進み、ここ
ではデバイス証明書が、装置ＩＤ、発行者ＩＤ、公開鍵、署名、及び共通
パラメータから作成される。一実施形態において、セキュリティカーネル・
モジュールは、図６を参照して上述した方法のような製造プロセスで使用
されおり、該デバイス証明書の構造を認識している。メリットとして、デ
バイス証明書は、要求に応じて作成できる。
【００６５】
ここで使用されたように、用語“実施形態”は、それに限定されない一
例として説明を行うための実施例を意味している。
【００６６】
当業者であれば前述した実施例と実施形態は、代表的なものであり、本
発明の範囲を限定するものでないことが理解されるであろう。当業者が明
細書を考慮し、図面を検討したときに自明な置き換え、増強、均等物やそ
れらへの改良が、本発明の要旨と範囲に含まれることを意図している。し
たがって、添付された特許請求の範囲は、本発明の要旨と範囲内にあるこ
のような総ての変更、置き換え、均等物を含むことを意図している。
⑵ 引用文献１の記載事項
引用文献１（甲６）には、次のような記載がある（下記記載中に引用する
図１ないし４、８、２１については別紙２を参照）。
ア 【技術分野】
【０００１】
本発明は、データを盗聴、改竄等から安全に保持するＩＣカード等のセ
キュリティデバイスと、そのセキュリティデバイスを装着した携帯電話や
ＰＤＡ（Personal Digital Assistant）、パーソナルコンピュータなどの情
報端末に関するもので、特に、電子マネーや電子チケット、音楽や画像、
映像などのデジタルコンテンツ等の価値情報を扱う機器に関するもので
ある。
【背景技術】
【０００２】
近年、ＣＰＵと耐タンパ性のある記憶領域を持つＩＣカード等のセキュ
リティデバイスは、カードアプリ（アプリはアプリケーションの略である。
以下同様である）を動作させることが可能であり、電子マネーや定期券、
電子チケット等のサービスに利用されている。
【０００３】
例えば、前述したセキュリティデバイスが携帯電話等の情報端末に内蔵
されたものがある。これによれば、情報端末のキーボードやディスプレイ
をセキュリティデバイスに対するユーザインターフェイスとして使用す
ることができる。また、セキュリティデバイスに書き込むデータや読み出
したデータを、情報端末の通信機能を利用してネットワーク上で伝送する
ことができるので、様々なサービスを利用することができる。この場合、
それらのサービスを実行する際に情報端末が行うべき動作を規定した端
末アプリが情報端末上で動作する。
【０００４】
従来、情報端末は、サービスプロバイダからネットワークを通じて端末
アプリをダウンロードするなどして、この端末アプリを取得している。例
えば、図２１に示すように、セキュリティデバイス２１１１に保持された
電子マネーや電子チケット等の価値情報２１１３をオフライン環境下で
表示する端末アプリ２１０８を、サービスプロバイダ２１２１からダウン
ロードする携帯端末２１０１が開示されている（特許文献１参照）。
【０００５】
この携帯端末２１０１は、端末アプリ２１０８のダウンロード及びその
ダウンロードした端末アプリ２１０８を実行するプログラム制御部２１
０２と、ダウンロードした端末アプリを記憶する格納部２１０３と、サー
ビスプロバイダ２１２１との通信を行う通信部２１０４と、ユーザがサー
ビスプロバイダ２１２１のＵＲＬを入力するユーザ入力部２１０５と、Ｌ
ＣＤ等の表示部２１０６と、を備えている。また、プログラム制御部２１
０２には、さらに、ダウンロードした端末アプリを検証する検証部２１０
７を備えている。一方、セキュリティデバイス２１１１は、内部のメモリ
に記憶されている価値情報２１１３を管理するカードアプリ２１１２を
備えている。
【０００６】
このセキュリティデバイス２１１１に蓄積された価値情報２１１３を、
オフライン環境下において携帯端末２１０１を用いて参照する場合、ユー
ザは、まず、ユーザ入力部２１０５にサービスプロバイダ２１２１のサー
バに格納されている端末アプリ２１０８のＵＲＬを入力する。入力された
ＵＲＬはプログラム制御部２１０２に渡され、プログラム制御部２１０２
は渡されたＵＲＬに基づいて通信部２１０４を介してサービスプロバイ
ダ２１２１のサーバと通信し、サービスプロバイダ２１２１から端末アプ
リ２１０８をダウンロードし（１） 検証部２１０７において端末アプリ２
、
１０８の検証を行い（２） 問題がなければ端末アプリ２１０８を格納部２
、
１０３に保存する（３）。
【０００７】
ユーザによって端末アプリ２１０８の起動操作が行われると、プログラ
ム制御部２１０２は格納部２１０３から端末アプリ２１０８を読み出し、
起動する（４）。起動された端末アプリ２１０８は、携帯端末２１０１に装
着されたセキュリティデバイス２１１１のカードアプリ２１１２に価値
情報２１１３を要求する（５）。カードアプリ２１１２は、内部のメモリに
記憶されている価値情報２１１３を読み出して携帯端末２１０１側に送
り（６）、端末アプリ２１０８は、取得した価値情報２１１３を携帯端末２
１０１の表示部２１０６に表示する処理を行う（７）。
【発明が解決しようとする課題】
【０００８】
しかしながら、上記従来技術では、以下に示すような問題点があった。
すなわち、セキュリティデバイス２１１１は、サービスプロバイダ２１２
１から端末アプリケーション２１０８をダウンロードし、検証部２１０７
において検証を行い、格納部２１０３に保存する。しかし、一度検証を経
て保存された端末アプリケーション２１０８は再び検証される機会がな
い。そのため、一度検証を経て保存された端末アプリケーション２１０８
に対して、価値情報２１１３へのアクセスの制限などを解除する改竄が施
された場合は、セキュリティデバイス内の価値情報２１１３が不正に使用
される恐れがあり、セキュリティの観点から好ましくない。また、サービ
スプロバイダからダウンロードしたコンテンツについても同様の問題が
生じる。
【０００９】
本発明は、上記実情を鑑みてなされたものであり、改竄が加えられたア
プリケーション等の実行を防ぐことができるセキュリティデバイスを提
供することを目的とする。
イ 【課題を解決するための手段】
【００１０】
本発明のセキュリティデバイスは、内部に保持された価値情報を外部端
末から参照するためのアプリケーションを記憶する記憶手段と、前記アプ
リケーションの同一性を保証する加工処理を行う加工手段と、加工処理し
たアプリケーションを記憶する記憶手段と、加工処理したアプリケーショ
ンを前記外部端末に対して発行する発行手段とを備える。また、本発明の
セキュリティデバイスは、外部端末で再生するコンテンツを記憶する記憶
手段と、前記コンテンツの同一性を保証する加工処理を行う加工手段と、
加工処理したコンテンツを記憶する記憶手段と、加工処理したコンテンツ
を前記外部端末に対して発行する発行手段とを備える。また、本発明のセ
キュリティデバイスは、外部端末で再生するコンテンツを記憶する記憶手
段と、前記コンテンツの同一性を保証する加工処理を行う加工手段と、加
工処理したコンテンツを記憶する記憶手段と、加工処理したコンテンツを
前記外部端末に対して発行する発行手段と、前記コンテンツを再生するア
プリケーションを記憶する記憶手段と、前記アプリケーションの同一性を
保証する加工処理を行う加工手段と、加工処理したアプリケーションを記
憶する記憶手段と、加工処理したアプリケーションを前記外部端末に対し
て発行する発行手段とを備える。
【００１１】
上記構成によれば、セキュリティデバイスが保持する価値情報を外部端
末で参照するアプリケーションや外部端末で再生するコンテンツに対し
てセキュリティデバイス側でアプリケーション、コンテンツの同一性を保
証する加工処理を施した上で外部端末に発行することで、外部端末がアプ
リケーションの起動毎、コンテンツの再生毎にアプリケーション、コンテ
ンツの同一性を検証することが可能となり、改竄したアプリケーションの
実行、コンテンツの再生を防ぐことができる。
【発明の効果】
【００１２】
本発明によれば、セキュリティデバイスが保持する価値情報を外部端末
で参照するアプリケーションや外部端末で再生するコンテンツに対して
セキュリティデバイス側でアプリケーション、コンテンツの同一性を保証
する加工処理を施した上で外部端末に発行することで、外部端末がアプリ
ケーションの起動毎、コンテンツの再生毎にアプリケーション、コンテン
ツの同一性を検証することが可能となり、改竄したアプリケーションの実
行、コンテンツの再生を防ぐことができる。
ウ 【発明を実施するための最良の形態】
【００１３】
以下、本発明の実施の形態を、図面を参照しながら説明する。
（実施の形態１）
図１に、本発明の第１の実施の形態におけるセキュリティデバイス１０
２と情報端末１０１のシステム構成を示す。
【００１４】
セキュリティデバイス１０２は、耐タンパ機構を有し、その内部で安全
なデータ処理を行う耐タンパデータ処理部１５０と、耐タンパデータ処理
部１５０が処理したデータを格納するフラッシュメモリ１５１と、耐タン
パデータ処理部１５０が情報端末１０１などのホスト機器との通信を制
御するホスト機器通信手段１５７と、によって構成される。
【００１５】
耐タンパデータ処理部１５０は、内部にＣＰＵやＲＯＭ、ＥＥＰＲＯＭ、
ＲＡＭ、更には、暗号処理用のコプロセッサを有し、ＲＯＭおよびＥＥＰ
ＲＯＭに格納されたプログラムに基づいてＣＰＵがＲＡＭおよびフラッ
シュメモリ１５１を用いてデータ処理を行う。
【００１６】
耐タンパデータ処理部１５０には、ホスト機器通信手段１５７を介して
外部から端末アプリケーションを受信するアプリケーション取得手段１
５３と、
端末アプリケーションに対して、認証情報の埋め込みや、電子署名などの
加工処理を施すアプリケーション加工手段１５２と、加工処理を施した端
末アプリケーションを情報端末１０１に対して発行するアプリケーショ
ン発行手段１５４と、があり、これらは、実際には、耐タンパデータ処理
部１５０の内部のＲＯＭやＥＥＰＲＯＭに格納されているプログラムを
耐タンパデータ処理部１５０のＣＰＵが実行することによって実現され
る。
【００１７】
また、フラッシュメモリ１５１には、アプリケーション取得手段１５３
が外部から受信した加工処理を行う前の端末アプリケーションを格納す
る領域であるオリジナルアプリケーション記憶部１５５と、アプリケーシ
ョン加工手段１５２が加工処理を施した後の端末アプリケーションを格
納する領域である加工済みアプリケーション記憶部１５６と、がある。Ｃ
ＰＵが端末アプリケーションをオリジナルアプリケーション記憶部１５
５または加工済みアプリケーション記憶部１５６に格納する場合、端末ア
プリケーションは、ＣＰＵおよびコプロセッサによって、暗号化されてそ
れぞれの記憶部に格納され、また、オリジナルアプリケーション記憶部１
５５または加工済みアプリケーション記憶部１５６に暗号化された状態
で格納されている端末アプリケーションをＣＰＵが読み出した場合、端末
アプリケーションはＣＰＵおよびコプロセッサによって復号化される。
【００１９】
また、情報端末１０１は、プログラムに基づいてデータ処理を行うデー
タ処理部１１０と、セキュリティデバイス１０２との通信を制御するセキ
ュリティデバイス通信手段１１６と、ネット上のサーバ機器や他の情報端
末との無線通信を行う無線通信手段１１５と、キー入力スイッチなどの入
力手段１１７と、データ処理部１１０が処理したデータを表示するＬＣＤ
などの表示手段１１８と、によって構成される。
【００２０】
データ処理部１１０は、内部にＣＰＵやＲＯＭ、ＥＥＰＲＯＭ、ＲＡＭ
を有し、ＲＯＭおよびＥＥＰＲＯＭに格納されたプログラムに基づいてＣ
ＰＵがＲＡＭおよびＥＥＰＲＯＭを用いてデータ処理を行う。
【００２１】
データ処理部１１０には、端末アプリケーションのプログラムコードを
解釈して実行するアプリケーション実行手段１１１と、端末アプリケーシ
ョンのセキュリティデバイス１０２へのダウンロード、および、セキュリ
ティデバイス１０２に格納された端末アプリケーションの情報端末１０
１へのロードを行うアプリケーション管理手段１１３と、情報端末１０１
に次にロードされる端末アプリケーションを準備するアプリケーション
準備手段１１２と、端末アプリケーションに施された電子署名を検証して、
その有効性を検証するアプリケーション検証手段１１４と、があり、これ
らは、実際には、データ処理部１１０の内部のＲＯＭやＥＥＰＲＯＭに格
納されているプログラムをデータ処理部１１０のＣＰＵが実行すること
によって実現される。
【００２２】
アプリケーション検証手段１１４には、電子署名を検証する際に利用す
るルートＣＡ証明書１１９（ＣＡは Certificate Authority を意味する）
と、アプリケーション検証手段１１４が行う端末アプリケーションの検証
処理の仕様を示す検証プロファイル１２０と、が保持されている。アプリ
ケーション検証手段１１４はルートＣＡ証明書１１９を複数個、保持して
いても良い。
エ 【００２６】
端末アプリケーションをコンテンツプロバイダ（ＣＰ）のネット上のサ
ーバからダウンロードする場合には、端末アプリケーションは、アプリケ
ーション管理手段１１３によって、無線通信手段１１５を介してＣＰのサ
ーバからダウンロードされ、セキュリティデバイス通信手段１１６および
ホスト機器通信手段１５７を介してアプリケーション取得手段１５３に
送信され、アプリケーション取得手段１５３が、受信した端末アプリケー
ションをオリジナルアプリケーション記憶部１５５に格納する。
【００２７】
この後、アプリケーション準備手段１１２によって、加工処理要求がア
プリケーション加工手段１５２に送信され、加工処理要求を受信したアプ
リケーション加工手段１５２が、オリジナルアプリケーション記憶部１５
５に格納されている端末アプリケーションに対して適当な加工処理を施
し、加工済みアプリケーション記憶部１５６に格納する。
【００２８】
セキュリティデバイス１０２に格納された端末アプリケーションを実
行する場合には、アプリケーション管理手段１１３によって、アプリケー
ション発行要求がアプリケーション発行手段１５４に送信され、アプリケ
ーション発行要求を受信したアプリケーション発行手段１５４が、加工済
みアプリケーション記憶部１５６から要求された端末アプリケーション
を読出し、アプリケーション管理手段１１３に送信する。アプリケーショ
ン管理手段１１３は受信した端末アプリケーションをアプリケーション
検証手段１１４に転送し、アプリケーション検証手段１１４が端末アプリ
ケーションに施された電子署名を検証してその有効性を検証する。この時、
アプリケーション検証手段１１４による検証をパスした端末アプリケー
ションだけが、アプリケーション実行手段１１１に転送され、アプリケー
ション実行手段１１１によって端末アプリケーションが起動される。
【００２９】
この後、アプリケーション実行手段１１１によって起動された端末アプ
リケーションは、まず、アプリケーション発行手段１５４によって、加工
処理の際に埋め込まれた認証情報に基づいた認証処理が行われ、その認証
処理にパスした場合のみ、その後の端末アプリケーションに固有の処理が
アプリケーション実行手段１１１によって実行される。
【００３０】
このように、情報端末１０１において実行される端末アプリケーション
を、情報端末１０１とセキュリティデバイス１０２とが認証することによ
って、不正な端末アプリケーションの実行が防止される。特に、端末アプ
リケーションがセキュリティデバイスのフラッシュメモリ１５１に格納
された価値情報（図面には示されていない）を一定の制約のもとに利用す
るアプリケーションである場合には、それらの制約を不正に解除するなど
の改竄が行われた端末アプリケーションの実行自体が防止されるので、価
値情報は不正な利用から守られる。
【００３１】
次に、セキュリティデバイス１０２の内部のデータの詳細について説明
する。図２は、アプリケーション加工手段１５２が内部に保持するデータ
の詳細と、セキュリティデバイス１０２に格納される端末アプリケーショ
ンのデータ構成を示している。アプリケーション加工手段１５２は、内部
に、セキュリティデバイス１０２が装着されるホスト機器が行う端末アプ
リケーションの検証処理の仕様を示す検証プロファイル２２３と、端末ア
プリケーションに電子署名を行う際に用いるセキュリティデバイス秘密
鍵２２１と、セキュリティデバイス秘密鍵２２１に対応するセキュリティ
デバイス証明書２２２と、ルートＣＡ証明書２２４とを保持する。
【００３２】
アプリケーション加工手段１５２は、検証プロファイル２２３とセキュ
リティデバイス秘密鍵２２１、セキュリティデバイス証明書２２２、ルー
トＣＡ証明書２２４を、それぞれ、複数個、保持していても良い。
【００３３】
検証プロファイル２２３のデータ構造は、検証プロファイル１２０のデ
ータ構造と同様であり、セキュリティデバイス１０２を頻繁に装着するホ
スト機器としてセキュリティデバイス１０２に登録されたホスト機器の
検証プロファイルがホスト機器ごとに保持される。この場合は、情報端末
１０１の検証プロファイル１２０が検証プロファイル２２３として登録
されている。
【００３４】
また、オリジナルアプリケーション記憶部１５５に格納されている端末
アプリケーションは、それぞれ、実際のプログラムコードの部分であるア
プリケーションコード２０１と、端末アプリケーションの発行者であるコ
ンテンツプロバイダ（ＣＰ）によってアプリケーションコード２０１に施
された電子署名である署名２０２と、署名２０２の有効性を証明する証明
書チェーン２０３と、端末アプリケーションの属性情報２０４と、その端
末アプリケーションに施されるべき加工処理の内容を規定した加工指示
書２０５と、から構成される。
【００３５】
図４（ａ）は、オリジナルアプリケーション記憶部１５５に格納されて
いる端末アプリケーションのアプリケーションコード２０１と署名２０
２と証明書チェーン２０３の部分の一例を示しており、図３は、この場合
のルートＣＡ３０１と中間ＣＡ３０２、コンテンツプロバイダ（ＣＰ）３
０３、情報端末１０１、及びセキュリティデバイス１０２との間のシステ
ム構成を示している。
【００３６】
この場合、証明書チェーン２０３は、ルートＣＡ３０１によって発行さ
れた中間ＣＡ３０２の中間ＣＡ証明書３２２と、中間ＣＡ３０２によって
発行されたＣＰ３０３のＣＰ証明書３２２とから構成され、情報端末１０
１とセキュリティデバイス１０２は、それぞれ、保有するルートＣＡ証明
書を用いて、これらの証明書チェーン２０３を構成する証明書を検証する
ことによってＣＰ３０３によってアプリケーションコード２０１に施さ
れた署名２０２の有効性を検証することが出来る。
オ 【００４９】
次に、図８を用いて、ＣＰ３０３からセキュリティデバイス１０２に端
末アプリケーションをダウンロードするシーケンス、及び、セキュリティ
デバイス証明書をダウンロードするシーケンスについて説明する。
【００５０】
まず、入力手段１１７から入力されたユーザ操作に基づいて、情報端末
１０１が無線通信手段１１５を介し無線通信によってＣＰ３０３に端末
アプリケーションを要求するメッセージを送信すると（アプリケーション
要求８０１） ＣＰ３０３は、
、 情報端末１０１に装着されたセキュリティデ
バイス１０２に対して、セキュリティデバイス証明書を要求するメッセー
ジを送信する（セキュリティデバイス証明書要求８０２または８１１）。
【００５１】
セキュリティデバイス証明書要求８０２（または８１１）には、ＣＰ３
０３が生成した乱数が含まれており、情報端末１０１のセキュリティデバ
イス通信手段を介してセキュリティデバイス１０２に送信される。
【００５２】
セキュリティデバイス証明書要求８０２を受信したセキュリティデバイ
ス１０２は、アプリケーション取得手段１５３がアプリケーション加工手
段１５２に保持されているセキュリティデバイス証明書を調べ、ＣＰ３０
３が発行したセキュリティデバイス証明書が保有されている場合には、ア
プリケーション取得手段１５３がアプリケーションの発行を要求するメ
ッセージを生成して（アプリケーション発行要求生成８１３）ＣＰ３０３
に送信し（アプリケーション発行要求８１３） セキュリティデバイス証明
、
書を保有していない場合には、アプリケーション取得手段１５３がＣＰに
セキュリティデバイス証明書の発行を要求するメッセージを生成して（証
明書発行要求生成８０３）ＣＰ３０３に送信する（証明書発行要求８０４）。
【００５３】
この時、アプリケーション発行要求８１３には、ＣＰ３０３が発行した
セキュリティデバイス証明書と、アプリケーション取得手段１５３がその
セキュリティデバイス証明書に対応するセキュリティデバイス秘密鍵を
用いてセキュリティデバイス証明書要求８０２（または８１１）に含まれ
ていた乱数に対して施した電子署名が含まれ、証明書発行要求８０４には、
その他のセキュリティデバイス証明書と、アプリケーション取得手段１５
３がそのセキュリティデバイス証明書に対応するセキュリティデバイス
秘密鍵を用いてセキュリティデバイス証明書要求８０２に含まれていた
乱数に対して施した電子署名が含まれる。
【００５４】
証明書発行要求８０４を受信したＣＰ３０３は、証明書発行要求８０４
に含まれていた電子署名（セキュリティデバイス証明書要求８０２に含ま
れていた乱数に対する電子署名）を同じく証明書発行要求８０４に含まれ
ていたセキュリティデバイス証明書を用いて検証して（署名検証８０５）、
セキュリティデバイス１０２がセキュリティデバイス秘密鍵を保持して
いることを検証し、さらにＣＰ３０３は、そのセキュリティデバイス証明
書に含まれるセキュリティデバイス公開鍵を用いて新たにセキュリティ
デバイス証明書を生成して（セキュリティデバイス証明書生成８０６） セ
、
キュリティデバイス１０２に送信する（セキュリティデバイス証明書８０
７）。仮に、署名検証８０５においてエラーが検出された場合には、ＣＰ３
０３は、エラーメッセージを情報端末１０１に送信して処理を中止する
（図には示していない）。
【００５５】
セキュリティデバイス証明書８０７は、情報端末１０１を介してセキュ
リティデバイス１０２に送信され、セキュリティデバイス証明書８０７を
受信したセキュリティデバイス１０２は、アプリケーション取得手段１５
３がセキュリティデバイス証明書８０７をアプリケーション加工手段１
５２に保存して、セキュリティデバイス証明書８０７の取得を完了したこ
とを示す応答メッセージを情報端末１０１に送信する（完了応答８０９）。
【００５６】
完了応答８０９を受信した情報端末１０１は、改めてＣＰ３０３に端末
アプリケーションを要求するメッセージを送信する（アプリケーション要
求８１０）。
【００５７】
アプリケーション発行要求８１３を受信したＣＰ３０３は、アプリケー
ション発行要求８１３に含まれていた電子署名（セキュリティデバイス証
明書要求８０２または８１１に含まれていた乱数に対する電子署名）を同
じくアプリケーション発行要求８１３に含まれていたＣＰ３０３が発行
したセキュリティデバイス証明書を用いて検証して（署名検証８１４） セ
、
キュリティデバイス１０２がＣＰ３０３が発行したセキュリティデバイ
ス証明書に対応するセキュリティデバイス秘密鍵を保持していることを
検証し、さらにＣＰ３０３は、そのセキュリティデバイス証明書に含まれ
るセキュリティデバイス公開鍵を用いて発行する端末アプリケーション
を暗号化して（アプリケーション暗号化８１５） セキュリティデバイス１
、
０２に送信する（暗号化されたアプリケーション８１６）。
【００５８】
この時、暗号化する前の端末アプリケーションには、その有効性を示す
ためにＣＰ３０３による電子署名が施され、それを検証するための証明書
が付加されている（図４（ａ）は暗号化する前の端末アプリケーションデ
ータ構造の一例を示している） また仮に、
。 署名検証８１４においてエラー
が検出された場合には、ＣＰ３０３は、エラーメッセージを情報端末１０
１に送信して処理を中止する（図には示していない）。
【００５９】
暗号化されたアプリケーション８１６は、情報端末１０１を介してセキ
ュリティデバイス１０２に送信され、暗号化されたアプリケーション８１
６を受信したセキュリティデバイス１０２は、アプリケーション取得手段
１５３が、アプリケーション加工手段１５２が保持するセキュリティデバ
イス秘密鍵を用いて暗号を復号化し（暗号復号化８１７）、さらに、端末ア
プリケーションに施されたＣＰ３０３による電子署名を検証して端末ア
プリケーションの有効性を検証し（署名検証８１８） 端末アプリケーショ
、
ンをオリジナルアプリケーション記憶部１５５に保存して（アプリケーシ
ョン保存８１９）、端末アプリケーションの取得を完了したことを示す応
答メッセージを情報端末１０１に送信する（完了応答８２０）。
【００６０】
仮に、署名検証８１９においてエラーが検出された場合には、アプリケ
ーション取得手段１５３は、端末アプリケーションを消去し、エラーメッ
セージを情報端末１０１に送信して処理を中止する（図には示していな
い）。
【００６１】
完了応答８２０を受信した情報端末１０１は、端末アプリケーションの
ダウンロードが完了したことを示すメッセージを表示手段１１８に表示
して処理を終了する。
【００７０】
以上ように、情報端末１０１において実行される端末アプリケーション
を、情報端末１０１とセキュリティデバイス１０２とが認証することによ
って、不正な端末アプリケーションの実行が防止される。
【００７１】
特に、端末アプリケーションがセキュリティデバイスのフラッシュメモ
リ１５１に格納された価値情報（図面には示されていない）を一定の制約
のもとに利用するアプリケーションである場合には、それらの制約を不正
に解除するなどの改竄が行われた端末アプリケーションの実行自体が防
止されるので、価値情報は不正な利用から守られる。
⑶ 「クライアント装置」に係る一致点の認定の誤りについて
原告は、本願発明の「クライアント装置」に相当するのは、引用発明の「情
報端末１０１」であって、
「セキュリティデバイス１０２」でないから、本件
審決が、引用発明の「セキュリティデバイス１０２」が本願発明の「クライ
アント装置」に相当するとの認定を前提に、本願発明と引用発明は、
「前記第
１の数と前記証明書のリクエストは前記クライアント装置に送られ」る点で
一致すると認定したのは誤りである旨主張する。
ア 本願発明の特許請求の範囲の請求項１には、本願発明の「サーバ」は、
「数発生器」と「証明書リクエストモジュール」と、これらに「接続する
インターフェース」を備えており、「数発生器」は「第１の数」を、「証明
書リクエストモジュール」は「デバイス証明書のリクエスト」をそれぞれ
生成し、「前記第１の数」と「前記デバイス証明書のリクエスト」は、「前
記インターフェースを介してクライアント装置に送られ」るとの記載があ
る。これらの記載によれば、本願発明の「クライアント装置」 「サーバ」
は、
が生成し、送信する「第１の数」及び「デバイス証明書のリクエスト」を
受信する機能を有するものであると解される。
イ 引用文献１には、
「ＣＰ３０３は、情報端末１０１に装着されたセキュリ
ティデバイス１０２に対して、セキュリティデバイス証明書を要求するメ
ッセージを送信する（セキュリティデバイス証明書要求８０２または８１
１） 」【００５０】、
。（ ）「セキュリティデバイス証明書要求８０２（または８
１１）には、ＣＰ３０３が生成した乱数が含まれており、情報端末１０１
のセキュリティデバイス通信手段を介してセキュリティデバイス１０２
に送信される。 （
」 【００５１】 、
） 「セキュリティデバイス証明書要求８０２
を受信したセキュリティデバイス１０２」
（【００５２】 との記載があり、
）
また、上記各段落の説明に用いられる図８には、
「セキュリティデバイス証
明書要求８０２」及び「セキュリティデバイス証明書要求８１１」につい
て、それぞれ「ＣＰ３０３」から「情報端末１０１」を通過し「セキュリ
ティデバイス１０２」を終点とする矢印が引かれている。引用文献１の上
記記載及び図８から、引用発明の「ＣＰ３０３」は、
「乱数」と「セキュリ
ティデバイス証明書要求」を生成し、これらを「セキュリティデバイス１
０２」に送信し、
「セキュリティデバイス１０２」は、これらを受信するも
のと理解できる。そして、引用発明の「ＣＰ３０３」 「乱数」 「セキュリ
、 、
ティデバイス証明書要求」は、それぞれ、本願発明の「サーバ」 「第１の
、
数」 「デバイス証明書のリクエスト」に相当するから、引用発明の「セキ
、
ュリティデバイス１０２」は、「サーバ」（ＣＰ３０３）が生成し、送信す
る「第１の数」（乱数）及び「デバイス証明書のリクエスト」（セキュリテ
ィデバイス証明書要求）を受信する機能を有するものと認められる。
したがって、引用発明の「セキュリティデバイス１０２」は、本願発明
の「クライアント装置」に相当すると認められる。
ウ これに対し、原告は、引用発明は、
「セキュリティデバイス１０２」 「情
が
報端末１０１」に装着されて「情報端末１０１」と通信するように構成さ
れ，本願発明の「サーバ」に相当する引用発明の「ＣＰ３０３」には「情
報端末１０１」が無線ネットワークを介して接続される構成であることか
らすると、本願発明の「クライアント装置」に相当するのは、引用発明の
「情報端末１０１」であって、
「セキュリティデバイス１０２」でない旨主
張する。
しかし、前記イのとおり、引用文献１の図８において「ＣＰ３０３」か
ら発せられた「セキュリティデバイス証明書要求８０２」及び「セキュリ
ティデバイス証明書要求８１１」が、
「情報端末１０１」を通過して「セキ
ュリティデバイス１０２」に到達するように矢印が引かれていることに照
らすと、引用発明の「セキュリティデバイス１０２」が「ＣＰ３０３」か
ら送信された「乱数」及び「セキュリティデバイス証明書要求」の送受信
は、
「ＣＰ３０３」と「セキュリティデバイス１０２」との間で行われ、
「情
報端末１０１」は通過点にすぎないものと解される。
したがって、引用発明の「情報端末１０１」が本願発明の「クライアン
ト装置」に相当するとの原告の上記主張は理由がない。
エ 以上によれば、本願発明と引用発明は、
「前記第１の数と前記証明書のリ
クエストは前記クライアント装置に送られ」る点で一致するとした本件審
決の認定の誤りをいう原告の主張は理由がない。
⑷ 「第２の署名」に係る一致点の認定の誤りについて
原告は、本件審決は、引用発明の「乱数に施した電子署名」が本願発明の
「クライアント装置において該クライアント装置の製造中にプログラムされ
たプライベートキーと前記サーバの数発生器が作成した第１の数を使用して
生成される第２の署名」に相当するとの認定を前提に、本願発明と引用発明
は、
「レスポンス」が「該クライアント装置の製造中にプログラムされたプラ
イベートキーと前記サーバの数発生器が作成した第１の数を使用して生成さ
れる第２の署名」を含む点で一致すると認定したが、本願発明の「第１の数
を使用して生成される第２の署名」は、第１の数を使用して新たに生成され
るものであり、
「乱数に施したことで得られた電子署名」に対応する署名であ
るのに対し、引用発明の「乱数に施した電子署名」とは、その文言から、
「電
子署名を乱数に施した」ことを意味するものであり、電子署名自体には、変
化がなく、
「乱数に施したことで得られた電子署名」とは異なるものであるか
ら、本件審決の上記一致点の認定は誤りである旨主張する。
ア 本願発明の特許請求の範囲の請求項１の記載によれば、本願発明の「第
１の数を使用して生成される第２の署名」とは、「プライベートキー」（秘
密鍵）と「第１の数」を用いて生成される電子署名であると解される。こ
のような理解は、本願明細書の「証明書作成モジュール１２０は、デバイ
ス・プライベートキーを使用し、乱数Ｒ上の署名Ｓｉｇを算出する。（
」【０
０１５】）との記載にも合致する。
イ 引用文献１には、
「証明書発行要求８０４には、…セキュリティデバイス
秘密鍵を用いてセキュリティデバイス証明書要求８０２に含まれていた
乱数に対して施した電子署名が含まれる。 （
」 【００５３】 、
） 「証明書発行要
求８０４を受信したＣＰ３０３は、証明書発行要求８０４に含まれていた
電子署名（セキュリティデバイス証明書要求８０２に含まれていた乱数に
対する電子署名）を同じく証明書発行要求８０４に含まれていたセキュリ
ティデバイス証明書を用いて検証して（署名検証８０５） （
」 【００５４】）
との記載がある。これらの記載及び図８によれば、引用発明の「乱数に対
して施した電子署名」は、「プライベートキー」（セキュリティデバイス秘
密鍵） 「第１の数」
と （乱数）を用いて生成される署名であるといえるから、
本願発明の「第１の数を使用して生成される第２の署名」に相当すると認
められる。
ウ これに対し、原告は、引用発明の「乱数に施した電子署名」とは、その
文言から、「電子署名を乱数に施した」ことを意味するものであり、「乱数
に施したことで得られた電子署名」とは異なる旨主張する。
しかし、引用発明の「乱数に対して施した電子署名」
（乱数に施した電子
署名）が乱数に対してセキュリティデバイス秘密鍵を用いて生成される電
子署名を意味すると解されることは前記イのとおりであって、原告の上記
主張の解釈は、文言解釈として不自然であり、採用することができない。
エ 以上によれば、本願発明と引用発明は、
「レスポンス」が「該クライアン
ト装置の製造中にプログラムされたプライベートキーと前記サーバの数発
生器が作成した第１の数を使用して生成される第２の署名」を含む点で一
致するとした本件審決の認定の誤りをいう原告の主張は理由がない。
２ 相違点２の容易想到性の判断の誤りについて
⑴ 本願優先日当時の技術常識について
ア 各文献の記載事項
(ア) 乙１（「暗号技術入門 秘密の国のアリス」第３版、８頁～１０頁、
２２７頁～２２８頁、２０１６年３月１８日発行、ＳＢクリエイティブ
株式会社）
「暗号アルゴリズム
…平文から暗号文を作る手順、すなわち暗号化の手順のことを「暗
号化のアルゴリズム」と呼び、復号化の手順のことを「復号化のアル
ゴリズム」と呼びます。暗号化・復号化のアルゴリズムを合わせて暗
号アルゴリズムと呼びます。」
「鍵
…暗号化を行うときも、復号化を行うときも、いずれの場合にも鍵
が必要になります。」
「対称暗号と公開鍵暗号
暗号は、鍵の使い方によって、対称暗号と公開鍵暗号の２種類に分
類できます。
対称暗号（…）は、暗号化と復号化で同じ鍵を使う方式です。…
それに対して公開鍵暗号（…）は、暗号化と復号化で異なる鍵を使
う方式です。…
Ｆｉｇ．１－８●対称暗号と公開鍵暗号」
「公開鍵暗号とデジタル署名
…デジタル署名の実現には、…公開鍵暗号の仕組みを利用します。
公開鍵暗号では、公開鍵とプライベート鍵の鍵ペアを使い、公開鍵で
暗号化して、プライベート鍵で復号化しました（…）。
デジタル署名でも、同じように公開鍵とプライベート鍵の鍵ペアを
使います。しかし、２つの鍵の使い方は公開鍵暗号とは逆になります。
メッセージをプライベート鍵で暗号化することが署名の作成に相当し、
その暗号文を公開鍵で復号化することが署名の検証に相当します。２
つの図を比較して公開鍵暗号を「逆に使っている」様子を理解してく
ださい（…）。
…つまり、ある公開鍵を使って暗号文が正しく復号化できたなら、
その暗号文は、その公開鍵と対になったプライベート鍵で暗号された
はず、ということがいえます。
Ｆｉｇ．９－２●プライベート鍵による暗号化（デジタル署名）
プライベート鍵で暗号化するというのは、そのプライベート鍵を使
える人にしか実現できない行為ですから、この事実から「プライベー
ト鍵による暗号文」を「署名」として扱おうというのです（…）。
公開鍵は一般に公開できますから、公開鍵による復号化は誰にでも
できることになります。これは、誰でもデジタル署名の検証が行える
という大きなメリットになります。」
（「Ｆｉｇ．１－８」 「Ｆｉｇ．
及び ９－２」については別紙３を参照）
(イ) 乙２（「暗号技術のすべて」、５９８頁～５９９頁、２０１７年９月
１５日発行、株式会社翔泳社）
「８．５．１ 電子証明書とは
電子証明書（…）は、公開鍵がその証明書に書かれた所有者のも
のであることを証明するために用いられます。ここでいう公開鍵と
は、公開鍵暗号の公開鍵や、デジタル署名の検証鍵を指します。」
「８．５．２ 証明書のフォーマット
証明書のフォーマットは、国際標準化団体のＩＴＵ（国際電気通
信連合）により、標準化されており、その代表的なものがＸ．５０
９です。Ｘ．５０９では、証明書の論理的構造を規定しています。
…Ｘ．５０９証明書は、
「署名前証明書」
「署名アルゴリズム」
「署名
値」から構成されます（表８．６）。署名前証明書は、基本領域と拡
張領域に分けられます。基本領域には、証明書の所有者の公開鍵に
関する情報が記載されます。拡張領域には、基本領域を補足する情
報が追加されます。例えば、
「検証鍵情報」
「鍵使用目的（署名検証・
否認防止・暗号化など） 「ポリシー情報」などが含まれます。署名
」
値は、署名前証明書に対する認証局のデジタル署名です。
証明書は使用する形式によって、ＰＫＣＳ＃１１（ＩＣカードな
ど）やＰＫＣＳ＃１２（データファイルなど）で保存されます。」
（「表８．６」については別紙４を参照）
(ウ) 引用文献３（甲２７）
【０１１０】
クライアントＩＤが登録済みである場合は、ステップＳ１４５に進み、
サーバは、クライアントの保持するコピーコンテンツに対応するコンテ
ンツＩＤリストの送信をクライアントに要求する。なお、この要求をク
ライアントに送信する際、サーバは、サーバクライアント間で転送され
るコンテンツＩＤリストの安全性、正当性を確保するために適用するデ
ータとして、乱数値（Ｒａｎｄｏｍ ｃｈａｌｌｅｎｇｅ）とサーバの
保持するデバイス証明書（公開鍵証明書）をクライアントに送信する。
【０１１１】
クライアントは、ステップＳ２４４において、乱数値とデバイス証明
書を伴ったコンテンツＩＤリスト要求を受信し、ステップＳ２４５にお
いて、利用期間の更新要求対象としたコンテンツを受領したサーバのサ
ーバＩＤに対応付けられたコピーコンテンツのコンテンツＩＤからなる
リストを生成して、サーバに送信する。このリスト送信に際して、クラ
イアントは、クライアントが生成した乱数値と、クライアントのデバイ
ス証明書（公開鍵証明書）を送信する。
【０１１４】
図９（ｂ）に、リストに併せて送信されるデバイス証明書（公開鍵証
明書）のデータ構成例を示す。デバイス証明書（公開鍵証明書）は以下
のデータを含む。
デバイスＩＤ［Ｄｅｖｉｃｅ ＩＤ］＝クライアントＩＤ
デバイス公開鍵［Ｄｅｖｉｃｅ Ｐｕｂｌｉｃ Ｋｅｙ］
発行元電子署名［Ｓｉｇｎａｔｕｒｅ ｂｙ ＬＡ］
【０１１５】
図９（ｂ）に示す公開鍵証明書は、一般的な公開鍵証明書の構成であ
り、デバイスＩＤ、デバイス公開鍵と、発行元の電子署名を含む。例え
ばクライアントの公開鍵を格納したクライアントデバイス公開鍵証明書
を受領したサーバは、受領した公開鍵証明書に設定された署名に基づく
検証を実行して、証明書の改竄のないことの確認を行なった後に、格納
されたクライアントの公開鍵を取得する。サーバは、取得したクライア
ント公開鍵を適用して、図９（ａ）に示すコンテンツＩＤリストに設定
された電子署名、すなわちクライアント秘密鍵を適用して生成された署
名の検証を実行することができる。
(エ) 引用文献４（甲２８）
【００８０】不揮発メモリ１００には、このアクセス制御部６０を搭載
したデバイスが、正当なデバイスであることを証明するデバイス証明書
１０１と、アクセス制御部６０の公開鍵暗号用秘密鍵であるデバイス秘
密鍵１０５と、デバイス証明書１００を発行した認証機関の公開鍵１０
６とが格納されている。
【０１０５】デバイス証明（図２の１０１）には、デバイスＩＤ（図２
の１０２）と、デバイス公開鍵（図２の１０３）と、これらの記述に対
する電子署名（図２の１０３）
（認証機関の秘密鍵により作成さえた）を
含む。デバイス証明の正当性は、その電子署名を認証機関の公開鍵（図
２の１０６）で正しく復号できるかどうかにより確認される。第三者が
デバイス証明を偽造しようとしても、認証機関の秘密鍵を知らないので、
正しい電子署名（図２の１０３）を作成することができない。
イ デバイス証明書等に関する技術常識について
前記アの記載事項を総合すると，①「デバイス証明書」は、正当なデバ
イス（クライアント）であることを証明する電子証明書であり、
「公開鍵証
明書」が、「デバイス証明書」として用いられること（前記ア(ウ)、(エ)）、
②電子署名は、公開鍵とプライベート鍵（秘密鍵）の鍵ペアを使い、メッ
セージをプライベート鍵（秘密鍵）で暗号化することが「署名」の「作成」
に相当し、その暗号文を公開鍵で復号化することが「署名」の「検証」に
相当すること（前記ア(ア)）、③「公開鍵証明書」は、電子署名が、秘密鍵
を保有するものでなければ生成できないという性質を利用して、秘密鍵を
保有する者とその者の公開鍵とを結びつけ、公開鍵が、その公開鍵とペア
となる秘密鍵を保有する者のものであること等を証明する手段であるこ
と（前記ア(ア)）、④「公開鍵証明書」の代表的なフォーマットは、別紙４
のような論理的構造で規定されており、
「署名前証明書」、
「署名アルゴリズ
ム」及び「署名値」から構成されていること（前記ア(イ)）、⑤「署名前証
明書」の「基本領域」には、証明書の所有者の公開鍵に関する情報（「主体
者」「主体者公開鍵情報（アルゴリズム、主体者公開鍵） 、
、 」「発行者ユニー
ク識別子」「主体者ユニーク識別子」等）が、
、 「拡張領域」には、基本領域
を補足する情報が記載されており、また、「署名値」は、「署名前証明書」
部分について電子署名したものであること（前記ア(ア)、(イ)）、⑤「公開
鍵証明書」を受け取った者は、
「公開鍵証明書」に含まれる「公開鍵」 「署
で
名（署名値）」を「検証」することによって、「公開鍵証明書」に含まれる
情報（「署名前証明書」部分に含まれる情報）が改ざんされておらず、「公
開鍵」が確かに主体者のものであることを確認することができること（前
記ア(ア)、(ウ)、(エ)）は，本願優先日当時の技術常識であったことが認
められる。
⑵ 本願発明の「前記クライアント装置の装置ＩＤ、発行者ＩＤ、前記プライ
ベートキーの関数である公開鍵及び前記クライアント装置の不揮発性メモリ
から読み出された第１の署名の関数として生成されたデバイス証明書」の意
義について
ア 本願発明の特許請求の範囲の請求項１の「前記クライアント装置の装置
ＩＤ、発行者ＩＤ、前記プライベートキーの関数である公開鍵及び前記ク
ライアント装置の不揮発性メモリから読み出された第１の署名の関数と
して生成されたデバイス証明書」との記載から、本願発明の「第１の署名」
は、
「クライアント装置の不揮発性メモリから読み出された」ものであるこ
とを理解できるが、請求項１には、
「第１の署名」の構成や生成方法等につ
いて規定した記載はない。
また、本願明細書には、本願発明の「第１の署名」について定義した記
載はない。
一方で、本願明細書には、
「デバイス証明書」に関し、①「クライアント
１０６の証明書作成モジュール１２０は、証明書Ｃｅｒｔを作成する。…
証明書作成モジュール１２０は、デバイス・プライベートキーを使用し、
乱数Ｒ上の署名Ｓｉｇを算出する。 （
」 【００１５】 、
） 「図３は、一回だけデ
バイス証明書を作成する方法の一例のフローチャート３００を示してい
る。図３の例では、フローチャート３００は、モジュール３０２で始まり、
ここでデバイス証明書がセキュアデバイスで作成される。…デバイス証明
書は公知のものである。（
」【００２３】 、②「図６は、セキュアデバイスを
）
製造する方法の例を示すフローチャート６００である。…図６の例におい
て、フローチャート６００は、モジュール６０２でスタートし、ここで装
置ＩＤが取得される。装置ＩＤは、シリアルナンバーであっても、或いは
装置のための他の何らかの固有な識別子であっても良い。 （
」 【００５３】、
）
「図６の例で、フローチャート６００は、モジュール６０４に進み、ここ
では装置のために小署名プライベートキー(a small-signature private
key)として使用する目的で、擬似乱数が供される。…小署名プライベート
キーは、これに限定されない例として、楕円カーブプライベートキーや比
較的小さなフットプリント(footprint)を持った他の何らかのプライベー
トキーでも良い。 【００５４】、
」
（ ）「図６の例で、フローチャート６００は、
モジュール６０６に進み、ここでは共通パラメータを使用してプライベー
トキーから公開鍵が算出される。 （
」 【００５５】 、
） 「図６の例で、フローチ
ャート６００は、モジュール６０８に進み、ここでは一定の証明書構造
(fixed certificate structure)が、証明書を作成するために使用される。
証明書は、例えば楕 円カーブＤＳＡなど の小署名アルゴリズ ム (small
signature algorithm)を使用して署名される。一実施形態では、該一定の
証明書構造は、少なくとも装置ＩＤ、発行者名、及びデバイス公開鍵を含
むかもしれない。 【００５６】、
」
（ ）「図６の例で、フローチャート６００は、
モジュール６１０に進み、ここでは｛装置ＩＤ、プライベートキー、発行
者ＩＤ、署名｝が、装置の不非揮発性メモリにプログラミングされる。…
一実施形態では、例えば公開鍵など、デバイス証明書の作成(construct)に
必要とされる如何なるデータも、要求に応じてプログラミングされた状態
で生成されても良い。（
」【００５７】 、③「図７は、セキュア証明書の作成
）
方法の例を示したフローチャート７００である。メリットとして、この方
法は、不揮発性でプログラミングされた鍵と必要なソフトウェアを有する
装置が、装置認証に使用可能な完全なデバイス証明書を作成することを可
能にする。図７の例では、フローチャート７００は、モジュール７０２で
スタートし、ここではデバイス証明書のリクエストが、呼出しアプリケー
ションから受け取られる。 （
」 【００５９】 、
） 「図７の例で、フローチャート
７００は、モジュール７０４に進み、ここでは｛装置ＩＤ、プライベート
キー、発行者ＩＤ、署名｝が、不非揮発性メモリから読み込まれる。（
」【０
０６０】 、
）「図７の例で、フローチャート７００は、モジュール７０６に進
み、ここでは公開鍵が、プライベートキーと（もしあるならば）共通パラ
メータとによって算出される。一実施形態では、この演算は、図６を参照
して上述した方法のような製造プロセスに使用されたのと同じアルゴリ
ズムを利用する。公開鍵は、セキュリティカーネルで算出されても良い。」
（【００６１】 、
） 「図７の例で、フローチャート７００は、モジュール７０
８に進み、ここではデバイス証明書が、装置ＩＤ、発行者ＩＤ、公開鍵、
署名、及び共通パラメータから作成される。一実施形態において、セキュ
リティカーネル・モジュールは、図６を参照して上述した方法のような製
造プロセスで使用されおり、該デバイス証明書の構造を認識している。」
（【００６２】）との記載がある。
これらの記載と図６及び７を総合すると、本願明細書には、本願発明の
「デバイス証明書」の実施形態として、
「装置ＩＤ、発行者ＩＤ、公開鍵、
署名」の証明書構造からなるデバイス証明書が開示されており、このデバ
イス証明書は、
「公開鍵証明書」であること、 「装置ＩＤ、
上記 発行者ＩＤ、
公開鍵、署名」のうちの「署名」は、小署名アルゴリズム(small signature
algorithm)を使用して算出された電子署名であり、本願発明の「第１の署
名」に相当することを理解できる。
そして、本願明細書には、上記「署名」の具体的内容についての記載は
ないが、
「デバイス証明書は公知のものである。（
」【００２３】）との記載及
び前記⑴イ認定の本願優先日当時の技術常識を踏まえると、本願発明の
「デバイス証明書」は、
「公開鍵証明書」の代表的なフォーマット（別紙４
参照）に基づくものであり、上記「署名」は、
「公開鍵証明書」の「署名値」
（証明書の所有者の公開鍵に関する情報（「主体者」 「主体者公開鍵情報
、
（アルゴリズム、主体者公開鍵）、
」「発行者ユニーク識別子」「主体者ユニ
、
ーク識別子」等）を含む「署名前証明書」部分について電子署名したもの）
に相当するものと理解できる。
以上の本願発明の特許請求の範囲の請求項１の記載、本願明細書の上記
記載及び前記⑴イ認定の本願優先日当時の技術常識を総合すると、本願発
明の「デバイス証明書」の「第１の署名」とは、
「デバイス証明書」に含ま
れる「前記プライベートキーの関数である公開鍵」にいう「プライベート
キー」を用いて「前記クライアント装置の装置ＩＤ」 「発行者ＩＤ」及び
、
「公開鍵」を暗号化した「署名値（署名）」を意味するものと解される。
そうすると、本願発明の「前記クライアント装置の装置ＩＤ、発行者Ｉ
Ｄ、前記プライベートキーの関数である公開鍵及び前記クライアント装置
の不揮発性メモリから読み出された第１の署名の関数として生成された
デバイス証明書」とは、
「前記クライアント装置の装置ＩＤ、発行者ＩＤ、
前記プライベートキーの関数である公開鍵」及びこれらを前記プライベー
トキーを用いて暗号化した署名（署名値）から構成される公開鍵証明書で
あると解される。
イ これに対し原告は、本願明細書には、
「第１の署名」について「これらを
暗号化して生成される」との記載はなく、【００６２】には、「デバイス証
明書が、装置ＩＤ、発行者ＩＤ、公開鍵、署名、及び共通パラメータから
作成される」こと（「デバイス証明書」に「署名」が含まれること）の記載
があるのみであるから、本願明細書を参酌しても、本願発明の「デバイス
証明書」が、
「クライアント装置の装置ＩＤ、発行者ＩＤ、プライベートキ
ーの関数である公開鍵」 これらを暗号化して生成される
と、 「第１の署名」
とを含むものと解釈することはできない旨主張する。
しかしながら、前記アで説示したとおり、本願発明の特許請求の範囲の
請求項１の記載、本願明細書の記載及び前記⑴イ認定の本願優先日当時の
技術常識を総合すると、本願発明の「デバイス証明書」の「第１の署名」
とは、
「デバイス証明書」に含まれる「前記プライベートキーの関数である
公開鍵」にいう「プライベートキー」を用いて「前記クライアント装置の
装置ＩＤ」「発行者ＩＤ」及び「公開鍵」を暗号化した「署名値（署名）
、 」
を意味するものと解されるから、原告の上記主張は採用することができな
い。
⑶ 相違点２の容易想到性について
ア 引用文献１には、
「次に、図８を用いて、ＣＰ３０３からセキュリティデ
バイス１０２に端末アプリケーションをダウンロードするシーケンス、及
び、セキュリティデバイス証明書をダウンロードするシーケンスについて
説明する。 （
」 【００４９】 、
） 「まず、入力手段１１７から入力されたユーザ
操作に基づいて、情報端末１０１が無線通信手段１１５を介し無線通信に
よってＣＰ３０３に端末アプリケーションを要求するメッセージを送信
すると（アプリケーション要求８０１）、ＣＰ３０３は、情報端末１０１に
装着されたセキュリティデバイス１０２に対して、セキュリティデバイス
証明書を要求するメッセージを送信する（セキュリティデバイス証明書要
求８０２または８１１） （
」 【００５０】 、
） 「証明書発行要求８０４を受信し
たＣＰ３０３は、証明書発行要求８０４に含まれていた電子署名（セキュ
リティデバイス証明書要求８０２に含まれていた乱数に対する電子署名）
を同じく証明書発行要求８０４に含まれていたセキュリティデバイス証
明書を用いて検証して（署名検証８０５） セキュリティデバイス１０２が
、
セキュリティデバイス秘密鍵を保持していることを検証し、さらにＣＰ３
０３は、そのセキュリティデバイス証明書に含まれるセキュリティデバイ
ス公開鍵を用いて新たにセキュリティデバイス証明書を生成して（セキュ
リティデバイス証明書生成８０６）、セキュリティデバイス１０２に送信
する（セキュリティデバイス証明書８０７） 」【００５４】
。（ ）との記載があ
る。
これらの記載及び図８によれば、引用文献１記載の「証明書発行要求８
０４に含まれていたセキュリティデバイス証明書」
（引用発明の「セキュリ
ティデバイス証明書」に相当するもの）は、セキュリティデバイス１０２
がセキュリティデバイス秘密鍵を用いて生成した公開鍵を含む公開鍵証
明書であることを理解できる。
イ 一方で、引用文献１には、
「証明書発行要求８０４に含まれていたセキュ
リティデバイス証明書」の証明書構造に関する記載はない。
しかるところ、
「公開鍵証明書」の代表的なフォーマットは、別紙４のよ
うな論理的構造で規定されており、
「署名前証明書」、
「署名アルゴリズム」
及び「署名値」から構成されていることは、本願優先日当時の技術常識で
あったことを踏まえると、引用文献１に接した当業者は、引用発明の「セ
キュリティデバイス証明書」に上記「公開鍵証明書」の論理的構造を適用
して、セキュリティデバイス１０２の装置ＩＤ、発行者ＩＤ、セキュリテ
ィデバイス秘密鍵を用いて生成した公開鍵及びこれらを上記セキュリテ
ィデバイス秘密鍵を用いて暗号化した署名（署名値）から構成される公開
鍵証明書（相違点２に係る本願発明の構成）とすることを容易に想到する
ことができたものと認められる。
これに反する原告の主張は、採用することができない。
３ 相違点の看過について
原告は、①本願明細書の【００１６】には「サーバ１０２における証明書検
証モジュ ール １１２ は、信頼 でき る証明 書 チェー ン (trusted certificate
chain)を用いて、証明書Ｃｅｒｔを認証し」との記載があること、証明書チェ
ーンは、認証パスとも呼ばれ、クライアント、サーバなどの証明書から、中間
認証局の証明書、ルート認証局の証明書までの連なりであり、チェーン内の各
証明書が次の証明書よって署名されることでセキュリティを確保するように構
成されていることは技術常識であることからすると、本願発明の「前記証明書
検証モジュールは前記デバイス証明書と第２の署名とを認証し」とは、
「デバイ
ス証明書」は「証明書チェーン」を用いて認証され、
「第２の署名」は「デバイ
ス証明書」に含まれる公開鍵によって認証されることを意味するものと解され
る、②引用文献１には、引用発明における「セキュリティデバイス証明書を用
いて検証する」との構成が、このような認証を意味することを示した記載はな
いから、引用発明は、本願発明の「前記証明書検証モジュールは前記デバイス
証明書と第２の署名とを認証し」との構成を備えるものでない点で本願発明と
相違するが、本件審決は、この点を相違点として認定していないから、本件審
決には、かかる相違点を看過した誤りがある旨主張する。
⑴ 本願発明の特許請求の範囲の請求項１の記載から、本願発明の「前記証明
書検証モジュールは前記デバイス証明書と第２の署名とを認証し」との構成
は、
「サーバ」が備える「前記証明書検証モジュール」が「前記デバイス証明
書」と「第２の署名」を認証することを規定したものと理解できるが、請求
項１には、上記構成中の「認証」の認証方法について規定した記載はない。
また、本願明細書には、上記構成中の「認証」を特定の認証方法に限定す
ることを述べた記載はない。
次に、本願明細書には、「サーバ１０２Ｒは、インターフェース１１８で、
乱数Ｒ、任意データ、証明書Ｃｅｒｔ、及び署名Ｓｉｇを受けとる。サーバ
１０２における証明書検証モジュール１１２は、信頼できる証明書チェーン
(trusted certificate chain)を用いて、証明書Ｃｅｒｔを認証し、証明書Ｃ
ｅｒｔを用いて署名Ｓｉｇを認証し、更に乱数Ｒが、元々サーバ１０２によ
ってクライアント１０６に送られた乱数Ｒと同じであるか否かを検証する。」
（【００１６】）との記載があり、「証明書チェーン(trusted certificate
chain)を用いて、証明書Ｃｅｒｔを認証し、証明書Ｃｅｒｔを用いて署名Ｓ
ｉｇを認証」した実施形態が開示されているが、一方で、
「当業者であれば前
述した実施例と実施形態は、代表的なものであり、本発明の範囲を限定する
ものでないことが理解されるであろう。当業者が明細書を考慮し、図面を検
討したときに自明な置き換え、増強、均等物やそれらへの改良が、本発明の
要旨と範囲に含まれることを意図している。 （
」 【００６６】）との記載に照ら
すと、本願発明の「前記証明書検証モジュールは前記デバイス証明書と第２
の署名とを認証し」との構成にいう「認証」は、
【００１６】記載の「証明書
チェーン」を用いた認証方法に限定すべきものと解することはできない。
これに反する原告の主張は、採用することができない。
⑵ 引用文献１の【００５４】には「証明書発行要求８０４を受信したＣＰ３
０３は、証明書発行要求８０４に含まれていた電子署名（セキュリティデバ
イス証明書要求８０２に含まれていた乱数に対する電子署名）を同じく証明
書発行要求８０４に含まれていたセキュリティデバイス証明書を用いて検証
して（署名検証８０５） セキュリティデバイス１０２がセキュリティデバイ
、
ス秘密鍵を保持していることを検証し」との記載がある。この記載及び図８
から、引用発明において、「ＣＰ３０３」は、「乱数に対する電子署名」をセ
キュリティデバイス１０２からの証明書発行要求８０４に含まれていた「セ
キュリティデバイス証明書」を用いて検証する構成を有することが理解でき
る。そして、引用発明の「乱数に対する電子署名」が本願発明の「第２の署
名」に対応すること（前記１⑷イ）からすると、引用発明の上記構成は、本
願発明のサーバが備える「前記証明書検証モジュールは…第２の署名とを認
証する」構成に相当する。
次に、前記２⑴イのとおり、「公開鍵証明書」を受け取った者は、「公開鍵
証明書」に含まれる「公開鍵」 「署名
で （署名値） を検証することによって、
」
「公開鍵証明書」に含まれる情報（「署名前証明書」部分に含まれる情報）が
改ざんされておらず、
「公開鍵」が確かに主体者のものであることを確認する
ことができることは、本願優先日当時の技術常識であること、引用発明の「セ
キュリティデバイス証明書」は、「公開鍵証明書」であること（前記２⑶ア）
からすると、引用発明の「セキュリティデバイス証明書」を用いて同証明書
に含まれる署名を検証することによって同証明書に含まれる情報が改ざんさ
れていないことを確認することは自明である。
そうすると、引用発明の「ＣＰ３０３」においても、
「セキュリティデバイ
ス証明書」を認証する構成を備えていると認められ、上記構成は、本願発明
のサーバが備える「前記証明書検証モジュールは前記デバイス証明書…を認
証し」との構成に相当する。
以上によれば、引用発明は、本願発明の「前記証明書検証モジュールは前
記デバイス証明書と第２の署名とを認証し」との構成を備えるものと認めら
れるから、上記構成が相違点であることを理由に本件審決における相違点の
看過をいう原告の主張は、採用することができない。
⑶ その他原告は、本件審決における本願発明と引用発明の一致点の認定の誤
りないし相違点の看過について縷々主張するが、いずれも本願発明の発明特
定事項との関係が明確とはいえず、本件審決の結論に影響を及ぼすものとい
えないから、理由がない。
第５ 結論
以上のとおり、原告主張の取消事由は理由がなく、本件審決にこれを取り消
すべき違法は認められない。
したがって、原告の請求は棄却されるべきものであるから、主文のとおり判
決する。
知的財産高等裁判所第１部
裁判長裁判官 大 鷹 一 郎
裁判官 小 川 卓 逸
裁判官小林康彦は、転補のため署名押印することができない。
裁判長裁判官 大 鷹 一 郎
（別紙１）
【図１】
【図３】
【図５】
【図６】
【図７】
（別紙２）
【図１】
【図２】
【図３】
【図４】
【図８】
【図２１】
（別紙３）
Ｆｉｇ．１－８●対称暗号と公開鍵暗号
Ｆｉｇ．９－２●プライベート鍵による暗号化（デジタル署名）
（別紙４）