運営：アスタミューゼ株式会社
パナソニックで一緒に知財の仕事しませんか？
  • ポートフォリオ機能


追加

関連審決 不服2018-15556
元本PDF 裁判所収録の全文PDFを見る pdf
元本PDF 裁判所収録の別紙1PDFを見る pdf
元本PDF 裁判所収録の別紙2PDFを見る pdf
元本PDF 裁判所収録の別紙3PDFを見る pdf
事件 令和 3年 (行ケ) 10064号 審決取消請求事件

原告三星電子株式会社
同訴訟代理人弁理士 佐藤英昭 吉田豊麿 丸山亮 林晴男 松本邦夫
被告特許庁長官
同 指定代理人山崎慎一 田中秀人 中村則夫 冨澤美加
裁判所 知的財産高等裁判所
判決言渡日 2022/04/28
権利種別 特許権
訴訟類型 行政訴訟
主文 １ 原告の請求を棄却する。
２ 訴訟費用は原告の負担とする。
３ この判決に対する上告及び上告受理申立てのための付加期間を３０日と定める。
事実及び理由
請求
特許庁が不服2018-15556号事件について令和2年12月9日にし 1 た審決を取り消す。
事案の概要
1 特許庁における手続の経緯等 ? エーサー・クラウド・テクノロジイ・インコーポレイテッド(以下「エー サー」という。)は、平成19年9月13日(優先日平成18年11月9日、
同月16日(以下「本願優先日」という。 、優先権主張国米国)を国際出願 ) 日とする特許出願(特願2009-536227号)の一部を分割した特許 出願(特願2013-214440号)の一部を更に分割した特許出願(特 願2015-149224号)を更に分割して、平成29年3月27日、発 明の名称を「サーバ」とする発明について、新たな特許出願(特願2017 -60504号。以下「本願」という。)をした(甲1)。
エーサーは、同年10月30日付けの拒絶理由通知(甲5)を受けた後、
平成30年2月14日付けで、特許請求の範囲及び発明の名称について手続 補正をした(上記手続補正後の発明の名称は「サーバとこのサーバにより認 証されるクライアント装置」。甲12)。
エーサーは、同年7月6日付けで、上記手続補正による特許請求の範囲の 補正について却下決定(甲14)を受けるとともに、拒絶査定(甲13)を 受けた。
? エーサーは、平成30年11月26日、拒絶査定不服審判(不服2018 -15556号事件。甲15)を請求した。
エーサーは、令和元年8月19日付けの拒絶理由通知(甲19)を受けた ため、令和2年1月27日付けで特許請求の範囲について手続補正(以下「本 件補正」という。甲24)をした。
特許庁は、同年12月9日、「本件審判の請求は、成り立たない。」との審 決(以下「本件審決」という。甲32)をし、その謄本は、令和3年1月1 2日、エーサーに送達された。
2 その後、原告は、エーサーから、本願に係る特許を受ける権利の譲渡を受 け、同年3月18日付けで、その旨の出願人名義変更届をした(甲34、3 5)。
? 原告は、令和3年5月12日、本件審決の取消しを求める本件訴訟を提起 した。
2 特許請求の範囲の記載 本件補正後の特許請求の範囲の請求項1の記載は、次のとおりである(以下、
請求項1に係る発明を「本願発明」という。甲24)。
【請求項1】 数発生器と、
証明書リクエストモジュールと、
証明書検証モジュールと、
前記数発生器、前記証明書リクエストモジュール、及び前記証明書検証モジ ュールに接続するインターフェースとを備えるとともに、不揮発性メモリを有 したクライアント装置を認証するためのサーバであって 動作において、
前記数発生器が第1の数を生成し、
前記証明書リクエストモジュールは、デバイス証明書のリクエストを生成し、
前記第1の数と前記デバイス証明書のリクエストは前記インターフェースを 介してクライアント装置に送られ、
前記第1の数と、
前記クライアント装置において該クライアント装置の製造中にプログラ ムされたプライベートキーと前記サーバの数発生器が作成した第1の数を使 用して生成される第2の署名と、
前記クライアント装置の装置ID、発行者ID、前記プライベートキーの 関数である公開鍵及び前記クライアント装置の不揮発性メモリから読み出さ 3 れた第1の署名の関数として生成されたデバイス証明書と を含むレスポンスが前記インターフェースで受け取られ、
前記証明書検証モジュールは前記デバイス証明書と第2の署名とを認証し、
前記サーバの数発生器が発生した第1の数と前記クライアント装置からの第 1の数が一致しているか否かを検証する ことを特徴とするサーバ。
3 本件審決の理由の要旨 ? 本件審決の理由は、別紙審決書(写し)記載のとおりである。
その要旨は、本願発明は、本願優先日前に頒布された刊行物である特開2 006-92281号公報(以下「引用文献1」という。甲6)に記載され た発明及び特開2004-135325号公報(以下「引用文献2」という。
甲26)、特開2006-18709号公報(以下「引用文献3」という。甲 27)、特開2003-323342号公報(以下「引用文献4」という。甲 28)に記載の技術事項に基づいて、当業者が容易に発明をすることができ たものであり、特許法29条2項の規定により特許を受けることができない から、本願は拒絶すべきものであるというものである。
? 本件審決が認定した引用文献1に記載された発明(以下「引用発明」とい う。 、本願発明と引用発明の一致点及び相違点は、次のとおりである。
) なお、原告は、引用文献1に引用発明の記載があることを認めている。
ア 引用発明 証明書要求部と、
乱数生成部と、
証明書検証部を有し、フラッシュメモリ151を有するセキュリティデ バイス102の認証を行う、CP303であって、
前記乱数生成部は、乱数を生成し、
前記証明書要求部は、前記乱数を含む、セキュリティデバイス証明書を 4 要求するリクエストを生成して、前記リクエストを、前記セキュリティデ バイス102に送信し、
前記セキュリティデバイス102から、セキュリティデバイス証明書と、
前記乱数に対して施した電子署名とを応答として受信し、
前記電子署名を前記セキュリティデバイス証明書を用いて検証する、C P303。
イ 本願発明と引用発明の一致点及び相違点 (一致点) 「数発生器と、
証明書リクエストモジュールと、
証明書検証モジュールとを備えるとともに、
不揮発性メモリを有したクライアント装置を認証するためのサーバであ って、
前記数発生器が第1の数を生成し、
前記証明書リクエストモジュールは、証明書のリクエストを生成し、
前記第1の数と前記証明書のリクエストは前記クライアント装置に送ら れ、
前記クライアント装置において該クライアント装置の製造中にプログ ラムされたプライベートキーと前記サーバの数発生器が作成した第1の 数を使用して生成される第2の署名と、証明書と を含むレスポンスが受け取られ、
前記証明書検証モジュールは前記証明書と第2の署名とを認証する、サ ーバ。」である点 (相違点1) 本願発明は、
「数発生器、前記証明書リクエストモジュール、及び前記証 明書検証モジュールに接続するインターフェース」を備えるものであるの 5 に対して、
引用発明においては、
「インターフェース」について、特に、言及されていない点。
(相違点2) “証明書”に関して、
本願発明においては、
「クライアント装置の装置ID、発行者ID、前記プライベートキーの関数である公開鍵及び前記クライアント装置の不揮発性メモリから読み出された第1の署名の関数として生成されたデバイス証明書」であるのに対して、
引用発明においては、 セキュリティデバイス証明書」 「 の詳細については、
特に、言及されていない点。
(相違点3) “リクエスト”に関して、
本願発明においては、「リクエストは前記インターフェースを介してクライアント装置に送られ」るものであるのに対して、
引用発明においては、「リクエスト」が、「インターフェース」を介して送信されることについては、特に、言及されていない点。
(相違点4) “レスポンス”に関して、
本願発明においては、「レスポンス」が、「第1の数」を含むものであるのに対して、
引用発明においては、「応答」が、「乱数」を含む点については、特に、
言及されていない点。
(相違点5) 本願発明においては、「レスポンスが前記インターフェースで受け取られ」るものであるのに対して、
6 引用発明においては、「応答」が、「インターフェース」で受信されるこ とについては、特に、言及されていない点。
(相違点6) 本願発明においては、「サーバの数発生器が発生した第1の数と前記ク ライアント装置からの第1の数が一致しているか否かを検証する」もので あるのに対して、
引用発明においては、
「乱数」の一致に関しては、特に、言及されていな い点。
4 取消事由 引用文献1を主引用例とする本願発明の進歩性の判断の誤り
当事者の主張
1 原告の主張 ? 一致点の認定の誤り ア 「クライアント装置」に係る一致点の認定の誤り 本件審決は、引用発明の「セキュリティデバイス102」が本願発明の 「クライアント装置」に相当するとの認定を前提に、本願発明と引用発明 は、「前記第1の数と前記証明書のリクエストは前記クライアント装置に 送られ」る点で一致すると認定した。
しかし、引用発明は、
「セキュリティデバイス102」が「情報端末10 1」に装着されて「情報端末101」と通信するように構成され,本願発 明の「サーバ」に相当する引用発明の「CP303」には「情報端末10 1」が無線ネットワークを介して接続される構成であることからすると、
本願発明の「クライアント装置」に相当するのは、引用発明の「情報端末 101」であって、
「セキュリティデバイス102」でないから、本件審決 の上記一致点の認定は誤りである。
イ 「第2の署名」に係る一致点の認定の誤り 7 本件審決は、引用発明の「乱数に施した電子署名」が本願発明の「クラ イアント装置において該クライアント装置の製造中にプログラムされた プライベートキーと前記サーバの数発生器が作成した第1の数を使用し て生成される第2の署名」に相当するとの認定を前提に、本願発明と引用 発明は、
「レスポンス」が「該クライアント装置の製造中にプログラムされ たプライベートキーと前記サーバの数発生器が作成した第1の数を使用 して生成される第2の署名」を含む点で一致すると認定した。
しかし、引用発明の「乱数に施した電子署名」とは、その文言から、
「電 子署名を乱数に施した」ことを意味するものであり、電子署名自体には、
変化がなく、
「乱数に施したことで得られた電子署名」とは異なるものであ る。一方、本願発明の「第1の数を使用して生成される第2の署名」は、
第1の数を使用して新たに生成されるものであり、「乱数に施したことで 得られた電子署名」に対応する署名であることからすると、引用発明の「乱 数に施した電子署名」は、本願発明の「クライアント装置において該クラ イアント装置の製造中にプログラムされたプライベートキーと前記サー バの数発生器が作成した第1の数を使用して生成される第2の署名」に相 当するものではないから、本件審決の上記一致点の認定は誤りである。
? 相違点2の容易想到性の判断の誤り ア 本件審決は、相違点2に関し、
「デバイスID」「署名」を含む「デバイ 、
ス証明書」については、引用文献3及び4の記載のとおり、本願優先日前 に、当業者に周知の技術事項であり、また、
「証明書」に「発行者ID」を 含ませることも、引用文献を提示するまでもなく、当業者に周知の技術事 項であるから、引用発明において、
「セキュリティデバイス証明書」 「セ に、
キュリティデバイス102」のID、
「CP303」のID等を含ませるよ う構成すること(相違点2に係る本願発明の構成とすること)は、当業者 が必要に応じて適宜なし得る事項である旨判断した。
8 しかし、
「デバイス証明書」に「署名」を含むこと自体は、引用文献3及 び4に開示された「公開鍵証明書」にあるように周知技術ではあるが、一 方で、相違点2に係る本願発明の構成は、
「クライアント装置の装置ID、
発行者ID、前記プライベートキーの関数である公開鍵及び前記クライア ント装置の不揮発性メモリから読み出された第1の署名の関数として生 成されたデバイス証明書」というものであり、本願発明の「デバイス証明 書」に含まれる「第1の署名」は、
「第1の署名の関数」として「デバイス 証明書」を生成するためのものであるから、引用文献3及び4記載のよう な「デバイス証明書」に単に「署名」を含むものと異なるものである。
また、引用文献1には、本願発明の「第1の署名の関数」に対応する記 載はないし、引用文献3及び4に開示された「公開鍵証明書」に含まれる 「署名」は、本願発明の「第1の署名」と同一視できるものではない。
したがって、相違点2に係る本願発明の構成は、引用発明及び引用文献 2ないし4記載の技術事項に基づいて当業者が必要に応じて適宜なし得 る事項であるとはいえないから、本件審決の上記判断は誤りである。
イ これに対し被告は、相違点2に係る本願発明の構成である「クライアン ト装置の装置ID、発行者ID、前記プライベートキーの関数である公開 鍵及び前記クライアント装置の不揮発性メモリから読み出された第1の 署名の関数として生成されたデバイス証明書」とは、
「デバイス証明書」が、
「クライアント装置の装置ID、発行者ID、プライベートキーの関数で ある公開鍵」と、これらを暗号化して生成される「第1の署名」とを含み、
「クライアント装置の装置ID、発行者ID、プライベートキーの関数で ある公開鍵」に「第1の署名」を付して生成されるものであることを特定 するものであるとした上で、本願発明の「第1の署名」は、引用文献3及 び4に開示された「電子署名」と同等のものといえるから、本件審決にお ける相違点2の容易想到性の判断に誤りはない旨主張する。
9 しかしながら、本願の願書に添付した明細書(以下、図面を含めて「本 願明細書」という。甲1)には「第1の署名」について「これらを暗号化 して生成される」との記載はなく、
【0062】には、
「デバイス証明書が、
装置ID、発行者ID、公開鍵、署名、及び共通パラメータから作成され る」こと(「デバイス証明書」に「署名」が含まれること)の記載があるの みであるから、本願明細書を参酌しても、本願発明の「デバイス証明書」 が、
「クライアント装置の装置ID、発行者ID、プライベートキーの関数 である公開鍵」と、これらを暗号化して生成される「第1の署名」とを含 むものと解釈することはできない。
したがって、被告の上記主張は、その前提において失当である。
? 相違点の看過 引用発明は、本願発明の「前記証明書検証モジュールは前記デバイス証明 書と第2の署名とを認証し」との構成を備えるものではない点で本願発明と 相違するが、本件審決は、この点を相違点として認定していないから、本件 審決には、かかる相違点を看過した誤りがある。
すなわち、本願明細書の【0016】には「サーバ102における証明書 検証モジュール112は、信頼できる証明書チェーン(trusted certificate chain)を用いて、証明書Ceｒｔを認証し」との記載があること、証明書チ ェーンは、認証パスとも呼ばれ、クライアント、サーバなどの証明書から、
中間認証局の証明書、ルート認証局の証明書までの連なりであり、チェーン 内の各証明書が次の証明書よって署名されることでセキュリティを確保する ように構成されていることは技術常識であることからすると、本願発明の「前 記証明書検証モジュールは前記デバイス証明書と第2の署名とを認証し」と は、「デバイス証明書」は「証明書チェーン」を用いて認証され、「第2の署 名」は「デバイス証明書」に含まれる公開鍵によって認証されることを意味 するものと解されるが、引用文献1には、引用発明における「セキュリティ 10 デバイス証明書を用いて検証する」との構成が、このような認証を意味する ことを示した記載はないから、引用発明は、本願発明の「前記証明書検証モ ジュールは前記デバイス証明書と第2の署名とを認証し」との構成を備える ものでない点で本願発明と相違する。
これに対し被告は、引用文献1の【0057】の「電子署名を…セキュリ ティデバイス証明書を用いて検証する」との記載は、セキュリティデバイス」 「 が「セキュリティデバイス秘密鍵」を保持していることを「検証」すること を意味するものであり、また、セキュリティデバイス証明書を用いて検証す るためには、当該セキュリティデバイス証明書が正当なものであることが確 認できなければならないから、引用発明は、「セキュリティデバイス証明書」 と「電子署名」とをそれぞれ認証するものであるとして、上記相違点の看過 はない旨主張する。
しかし、
「セキュリティデバイス証明書を用いて検証する」とは、あくまで 「セキュリティデバイス証明書」に含まれている情報を検証することであっ て、
「セキュリティデバイス証明書」そのものを認証するものとはいえないか ら、被告の上記主張は失当である。
? 小括 以上のとおり,本件審決には,一致点の認定の誤り、相違点2の容易想到 性の判断の誤り及び相違点の看過があるから、本願発明は,引用発明及び引 用文献2ないし4記載の技術事項に基づいて,当業者が容易に発明をするこ とができたものであるとした本件審決の判断は,誤りである。
したがって、本件審決は取り消されるべきものである。
2 被告の主張 ? 一致点の認定の誤りの主張に対し ア 「クライアント装置」に係る一致点の認定の誤りの主張に対し 本願発明の特許請求の範囲(請求項1)には、サーバとクライアント装 11 置との接続が直接であるか間接であるかについて特定がされておらず、サ ーバとクライアント装置との間に機器が介在する構成が排除されていな いこと、引用発明の「セキュリティデバイス102」は、その機能を見て も、
「CP303」の「証明書要求部」から「前記乱数を含む、セキュリテ ィデバイス証明書を要求するリクエスト」が送信されてこれを受信し、
「セ キュリティデバイス証明書と、前記乱数に対して施した電子署名とを応答 として」返信した上で、「CP303」において、「前記セキュリティデバ イス証明書を用いて検証」されるものであり、
「サーバ」によって認証され る「クライアント装置」といい得ることからすると、引用発明の「セキュ リティデバイス102」が本願発明の「クライアント装置」に相当するこ とは明らかである。
したがって、引用発明の「セキュリティデバイス102」が本願発明の 「クライアント装置」に相当するとした本件審決の一致点の認定に誤りは ない。
また、仮に引用発明の「セキュリティデバイス102」と「情報端末1 01」とを合わせたものを、本願発明の「クライアント装置」に相当する ものと対比したとしても、引用発明が「クライアント装置」を備える点で 本願発明と一致することに変わりはないから、本件審決の結論に影響しな い。
イ 「第2の署名」に係る一致点の誤りの主張に対し 「電子署名」は、乱数などの「情報A」を公開鍵暗号方式で用いられる 「公開鍵-秘密鍵」ペアの「秘密鍵」で暗号化して生成され、
「公開鍵」を 用いて「署名検証」されるものであることは、技術常識である(乙1, 。
2) 本願発明の特許請求の範囲(請求項1)には、
「第2の署名」について、
「前記クライアント装置において…プライベートキーと前記サーバの数 発生器が作成した第1の数を使用して生成される」との記載があるところ、
12 本願明細書の【0015】及び【0016】記載の「署名Sig」及び「乱 数R」は、それぞれ本願発明の「第2の署名」及び「第1の数」に対応す るものである。そして、上記技術常識を踏まえると、本願発明の「第2の 署名(署名Sig)」は、サーバから送られた「第1の数(乱数R)」を、
クライアント装置の「プライベートキー」で暗号化して生成され、
「証明書 Ceｒｔ」を用いて署名検証されるものと理解できる。
一方、引用文献1の【0053】及び【0054】の記載と上記技術常 識によれば、引用発明の「電子署名」は、CP303から送られてきた「乱 数」を「セキュリティデバイス102」の「秘密鍵」で暗号化して生成さ れ、
「セキュリティデバイス証明書」の「公開鍵」を用いて「署名検証」さ れるものと理解できる。
そうすると、引用発明の「電子署名」と本願発明の「第2の署名」とは、
証明書に付された電子署名として、その生成についても署名検証について も相違するところはないから、引用発明の「電子署名」は、本願発明の「第 2の署名」に相当するものといえる。
したがって、本願発明と引用発明は、
「レスポンス」が「該クライアント 装置の製造中にプログラムされたプライベートキーと前記サーバの数発 生器が作成した第1の数を使用して生成される第2の署名」を含む点で一 致するとした本件審決の一致点の認定に誤りはない。
? 相違点2の容易想到性の判断の誤りの主張に対し 本願発明の特許請求の範囲(請求項1)の「前記クライアント装置の装置 ID、発行者ID、前記プライベートキーの関数である公開鍵及び前記クラ イアント装置の不揮発性メモリから読み出された第1の署名の関数として生 成されたデバイス証明書」の記載(相違点2に係る本願発明の構成)の意味 は直ちには明確とはいえない。
しかるところ、本願明細書の【0023】の「デバイス証明書は公知のも 13 のである」との記載、セキュア証明書(デバイス証明書)の作成方法の例を 示したフローチャートである図7のうちステップ708の記載及び【006 2】の記載を参酌するとともに、公開鍵証明書に関する技術常識(乙1,2) を踏まえれば、請求項1の上記記載は、「デバイス証明書」が、「クライアン ト装置の装置ID、発行者ID、プライベートキーの関数である公開鍵」と、
これらを暗号化して生成される「第1の署名」とを含み、
「クライアント装置 の装置ID、発行者ID、プライベートキーの関数である公開鍵」に「第1 の署名」を付して生成されるものであることを特定していると理解できる。
そうすると、本願発明の「第1の署名」 「デバイス証明書」 は、 に含まれる、
「プライベートキーの関数である公開鍵」によって署名検証がされると解さ れるので、引用文献3及び4に開示された「電子署名」と同等のものといえ るから、本件審決における相違点2の容易想到性の判断に誤りはない。
? 相違点の看過の主張に対し 原告は、本願明細書の【0016】の記載を根拠として、本願発明の「前 記証明書検証モジュールは前記デバイス証明書と第2の署名とを認証し」に いう「デバイス証明書」の「認証」とは、
「証明書チェーン」を用いて認証す ることを意味するが、引用文献1には、引用発明における「セキュリティデ バイス証明書を用いて検証する」との構成が、このような認証を意味するこ とを示した記載はないから、引用発明は、本願発明の「前記証明書検証モジ ュールは前記デバイス証明書と第2の署名とを認証し」との構成を備えるも のでない点で本願発明と相違し、本件審決には、かかる相違点の看過がある 旨主張する。
ア しかし、本願発明の特許請求の範囲の請求項1には、本願発明の「前記 証明書検証モジュールは前記デバイス証明書と第2の署名とを認証し」に いう「認証」の具体的な認証方法について特定する記載がないこと、本願 明細書の【0016】には、サーバが受け取った証明書Ceｒｔを,信頼 14 できる証明書チェーンを用いて認証することが記載されているが、これは、
証明書Ceｒｔ(デバイス証明書)の認証に係る一実施形態の記載にすぎ ないことからすると、当該「認証」が証明書チェーンを用いるものである と限定解釈する必要はない。
イ 引用文献1の【0057】に、
「アプリケーション発行要求813を受信 したCP303は、アプリケーション発行要求813に含まれていた電子 署名(セキュリティデバイス証明書要求802または811に含まれてい た乱数に対する電子署名)を同じくアプリケーション発行要求813に含 まれていたCP303が発行したセキュリティデバイス証明書を用いて 検証して(署名検証814) セキュリティデバイス102がCP303が 、
発行したセキュリティデバイス証明書に対応するセキュリティデバイス 秘密鍵を保持していることを検証し」と記載されているように、引用発明 のCP303は、
「電子署名」を「セキュリティデバイス証明書」を用いて 「検証」することによって、
「セキュリティデバイス秘密鍵」を保持してい ることを「検証」するものであり、これは、本願発明の「デバイス証明書」 を「認証」することに対応する。
そして、
「セキュリティデバイス証明書」を用いて「電子署名」を検証す るためには、まず、当該「セキュリティデバイス証明書」が正当なもので あることが確認できなければならないが、そのためには、当該「セキュリ ティデバイス証明書」が正当なものであることを検証することができる情 報が含まれていなければならないこと、公開鍵証明書に関する技術常識を 踏まえれば、当該「セキュリティデバイス証明書」には、
「公開鍵」に加え て、当該「セキュリティデバイス証明書」が正当なものであることを保証 する「署名(署名値)」が含まれることは、当業者にとって明らかである。
そうすると、引用発明のCP303は、
「セキュリティデバイス証明書」 を受け取れば、当然に当該「署名(署名値)」を署名検証し、「セキュリテ 15 ィデバイス証明書」に含まれている情報が改ざんされていないことを確か めることになり、これは、
「セキュリティデバイス証明書」を認証すること にほかならないから、引用発明は、
「セキュリティデバイス証明書」と「電 子署名」とをそれぞれ認証するものである。
したがって、本件審決には、原告主張の相違点の看過はない。
? 小括 以上のとおり,本件審決における一致点の認定及び相違点2の容易想到性 の判断に誤りはなく、また、本件審決に相違点の看過はないから、本願発明 は,引用発明及び引用文献2ないし4記載の技術事項に基づいて,当業者が 容易に発明をすることができたものであるとした本件審決の判断に誤りはな い。
したがって、原告主張の取消事由は理由がない。
当裁判所の判断
1 一致点の認定の誤りについて ? 本願明細書の記載事項 本願明細書(甲1)には、次のような記載がある(下記記載中に引用する 図1、3、5ないし7については別紙1を参照)。
ア 【技術分野】 【0001】 セキュアプロセッサは通常、ID、及び/又は格納された秘密鍵を含む。
セキュリティレベルを高めるために、ある量(quantities)の秘密鍵などが、
チップ内不揮発性メモリにプログラミングされて、セキュアプロセッサを 作ることがある。ID及び秘密鍵のプログラミングは、チップのセキュア 製造プロセスにおいて行われる。それぞれのIDは固有のものであり、プ ライベートキーも又固有のものである。これらの量(these quantities)は、
デジタル権利管理や他のセキュリティ関連アプリケーションを実行する 16 ため、装置上のアプリケーションで使用される。通常、チップは、ネットワーク・プロトコル、秘密鍵などにおいて、使い捨てデータとして使用するために、暗号学的に強力な乱数を生成するメカニズムを含む。
【背景技術】【0002】 デジタル権利管理を実行するために使用される典型的なインフラにおいて、サーバは、装置に対する権利を有効にするため、デジタル的に署名されたチケットを供給するのに使用される。そのようなチケットは、装置にチケットを結びつけるために、かかる装置のアイデンティティ、及び/又は秘密鍵メカニズムを使用する。それぞれの装置ID/鍵の独自性を確実にするため、サーバは通常、セキュア・データベースを使って、製造された各チップに対応するID(及び/又は署名された証明書)を格納している。これらの証明書は、チップにプログラミングされた各秘密鍵((プライベートキー、公開鍵)ペアのプライベートキー)に対応する公開鍵を含んでいる。データベースに証明書を投入するためには、データベースに関連するインフラを確実に製造プロセスに結び付け、製造されたチップとデータベース内の証明書の間で1対1対応を維持しなければならない。
【0003】 上述したこれら関連技術の例や制限事項は、あくまで説明に役立つものとして例証したものであって排他的ではない。関連技術の他の制限事項は、
当該技術者が本願明細書を読み、図面を検討することにより明らかになるであろう。
【発明が解決しようとする課題】【0004】 以下の実施形態とその特徴は、あくまで例証的であって範囲を制限しないことを意図したシステム、ツール、および方法に関連して記載、図示さ 17 れる。種々の実施形態では、上述した問題の1つ又はそれ以上が低減又は 解消され、一方では他の実施形態がその他の改善に向けられる。
【0005】 改善されたセキュア・プログラミング技術は、セキュアデバイスによっ てサポートされる典型的なセキュア・アプリケーションを可能とすると同 時に、オンチップ秘密不揮発性メモリにプログラミングされるビットサイ ズを減少させることを含む。また、改善されたセキュア・プログラミング 技術は、システムの製造プロセスを簡素化することを含む。一実施形態に おいて、秘密事項のプログラミングは、オンチッププログラミングに対し 分離されており、特にシステム統合やインフラ設定のプロセスからは分離 される。
イ 【課題を解決するための手段】 【0006】 セキュア・プログラミング技術は、チップの製造を、チケットを取得す るために、チケットサーバに接続する後処理から分離させることを含む。
この技術に沿った方法は、チケットを受け取るための如何なる通信に先だ って、装置から(製造)サーバの署名が入った証明書を送ることを含んで も良い。この方法は、データベースを投入し、例えばちょうどチケットサ ービスが必要となる時など、後のチケットサービス実行を容易にすること を含んでも良い。
【0007】 本技術に沿った装置は、製造プロセスにおいて、証明書をプライベート キーと共に格納するためのチップ内不揮発性メモリを含んでも良い。プラ イベートキーは、楕円カーブをベースとするプライベートキーであっても、
またそうでなくとも良い。楕円カーブの暗号ベースの鍵の長所は、相対的 な暗号強度にしては、多くの種類の鍵より小さいことである。更に、楕円 18 曲線アルゴリズムを使用し、無作為のプライベートキーを保存すると共に、
ランタイム計算によって公開鍵を算出することが可能である。
【0008】 有利な点としては、特にオンチップ・リアルエステートを考慮して、圧 縮された証明書を不揮発性メモリ内に設けることが可能なことがある。
(デバイス証明書を保存するために必要とされるものより)より小さなデ ータセットを使用して、かかる装置はデバイス上にダイナミックに証明書 を作成し、それを要求するアプリケーションに提供する。デバイス証明書 を複数回作っても、また作らなくとも良い。例えば、一旦デバイス証明書 を作成し、更なる使用に備えてシステムの外部記憶装置に格納するように しても良い。このことは証明書が公知データであるため、特に不安定なこ とではない(セキュアでない訳ではない)。
【0009】 本技術によって構築された装置は、他の分野においても適用性を持つ可 能性がある。例えば、ピア又は、第1のデバイス証明書を必要とする如何 なるアプリケーションに対しても装置を認証することができる。またこれ とは別に、不揮発性メモリにプログラミングするためのセキュアな製造プ ロセスを使い、不揮発性メモリは、装置のためのセキュアな乱数発生器を 含んでも良い。
ウ 【発明を実施するための形態】 【0011】 以下の説明では、本発明の実施形態の十分な理解を与えるために幾つか の特定の具体的な構成が提示される。しかし、当業者であれば、1つ以上 のこれら特定の具体的な構成がなくとも、あるいは他の構成部などとの組 み合わせにより、本発明を実施することが可能であることが理解されるで あろう。また別の例では、様々な実施形態における本発明の側面を覆い隠 19 すことがないように、周知の具体的構成は、図示または詳細に説明されていない。
【0012】 図1は、サーバにおいてクライアントを認証する(validating)ためのシステム100の一例を示している。図1の例でシステム100は、サーバ102、ネットワーク104、及びクライアント106を含む。サーバ102は、証明書リクエストモジュール110、証明書検証モジュール112、証明書データベース114、擬似乱数(PRN)発生器116、及びインターフェース118を含む。クライアント106は、証明書作成モジュール120、不揮発性(NV)メモリ122、及びインターフェース124を含む。
【0013】 サーバ102は、如何なる適用可能な公知の(又は手頃な)コンピュータであっても良い。ネットワーク104は、非限定的な例として、インターネットを含む如何なる通信ネットワークでも良い。クライアント106は、セキュア記憶装置(技術的に安全性が保証された記憶装置)を有する、
如何なる適用可能な公知の(又は手頃な)コンピュータであっても良い。
不揮発性メモリ122はセキュア鍵ストアを含んでもよく、一実施形態では同不揮発性メモリ122はオンチップメモリである。
【0014】 図1の例では、動作において、レジストレーション(registration)用又はアクティベーション(activation)用プロトコルが、サーバ102によって起動される(或いは、クライアント106が、レジストレーション又はアクティベーションを起動するようにしても良い) 一実施形態では、
。 プロトコルは、装置の同一性(a device identity)を登録(register)したり、証明書データベース114に証明書を与えたりする(certificate into)役 20 割を果たす。そのために、乱数発生器116は、乱数Rを生成し、サーバ102の証明書リクエストモジュール110は、デバイス証明書のリクエストを生成する。乱数Rとデバイス証明書のリクエストは、インターフェース118を介して、ネットワーク104へと送られる。
【0015】 乱数Rとデバイス証明書のリクエストは、クライアント106のインターフェース124で受け取られる。クライアント106の証明書作成モジュール120は、証明書Ceｒｔを作成する。証明書Ceｒｔを作成するのに使用されるアルゴリズム例としては、図7を参照して以下に説明する。
証明書作成モジュール120は、デバイス・プライベートキーを使用し、
乱数R上の署名Sigを算出する。オペランド(operands)は、不揮発性メモリ122に格納されているが、それらは例えばセキュリティカーネル(図5参照)にあるようにしても良い。また別の実施形態では、上記演算には、装置ID、シリアルナンバー、リージョンコード、或いはその他幾つかの数値を含む場合もある。クライアント106のインターフェース124は、ネットワーク104に対し、乱数Rや何らかの任意データ、証明書Ceｒｔ、及び証明書Sigを返す。
【0016】 サーバ102Rは、インターフェース118で、乱数R、任意データ、
証明書Ceｒｔ、及び署名Sigを受けとる。サーバ102における証明書 検 証 モ ジ ュ ー ル 1 1 2 は 、 信 頼 で き る 証 明 書 チ ェ ー ン (trustedcertificate chain)を用いて、証明書Ceｒｔを認証し、証明書Ceｒｔを用いて署名Sigを認証し、更に乱数Rが、元々サーバ102によってクライアント106に送られた乱数Rと同じであるか否かを検証する。これらの認証及び検証が成功裏に完了したならば、サーバ102は、証明書データベース116に証明書Ceｒｔを取り込む。この時点で、クライア 21 ント106が、サーバ102から(或いはクライアント106に許可を与 える証明書を使用できる、その他幾つかのロケーションから)権利管理コ ンテンツ(rights managed content)やその他のオペレーションのためのデ ジタルライセンスを獲得することについて、推定上許可されることになる。
【0017】 その他の実施形態としては、装置がRNGを使って新しい鍵のペア｛pvt1、
pub1｝を作成し、署名者としてプライベートキーがプログラミングされた 装置を使用して、この新しい公開鍵 pub1 のために証明書が作成される場 合もある。この新しい鍵 pvt1 は、乱数Rを持つメッセージに署名するのに つかわれる場合もある。
【0023】 図3は、一回だけデバイス証明書を作成する方法の一例のフローチャー ト300を示している。図3の例では、フローチャート300は、モジュ ール302で始まり、ここでデバイス証明書がセキュアデバイスで作成さ れる。次いでフローチャート300は、モジュール304に進み、該デバ イス証明書がシステムの外部記憶装置に格納される。装置はセキュア(技 術的に安全性が保証されたもの)であるために、この変化(variation)は注 目に値するが、デバイス証明書は公知のものである。従って、それはその 都度、再生されないが、証明書は依然としてセキュアなものである。
エ 【0039】 図5は、図1乃至図3を参照して上述した技術を実施するのに適してい たセキュアシステム500の一例を示している。代表的なセキュアシステ ム500は、ゲーム機、メディアプレーヤー、埋め込み型(embedded)セキ ュアデバイス、セキュアプロセッサ付き“従来型”PC、或いはセキュアプロ セッサを備える他のコンピュータ・システムを備えても良い。
【0049】 22 図5の例では、チケットサービス506とセキュリティ API518は、
システムセキュリティのための個々の実行スペースにおいて実行しても よい。データブロックを有効化するために、チケットサービス506は、
ヘッダのデータを使ってチケットを有効にしても良い。そのチケットは、
暗号化された鍵を含んでも良い。チケットサービス506は、セキュリテ ィカーネル514におけるサービス(例えば、暗号化/復号化エンジン51 7)を利用して、鍵を復号化する。
【0051】 矢印520〜528を以て、システム500のデータフローの例が例示 を目的として供される。チケットサービス506での証明書リクエストの 受取りは、呼出しアプリケーション508からチケットサービス506へ の証明書リクエスト矢印520によって表わされる。
【0052】 チケットサービス506からセキュリティ API516への証明書リクエ ストの送りは、証明書リクエスト矢印522によって表されている。セキ ュリティカーネル514において、公開鍵/デバイス証明書・作成エンジ ン517は、鍵/署名ストア518からの鍵/署名データにアクセスする。
このアクセスは、プライベートキー/署名アクセス矢印524によって表 されている。セキュリティ API516は、デバイス証明書矢印526に示 すように、デバイス証明書をチケットサービス506に返し、それは更に デバイス証明書矢印528に示すように、呼出しアプリケーション508 に転送される。
オ 【0053】 図6は、セキュアデバイスを製造する方法の例を示すフローチャート6 00である。この方法、及び他の方法は、連続的に並べられたモジュール の形で表現される。しかしながら、これらの方法における各モジュールは、
23 並べ替えされたり、並列実行のために適当に並べられたりしても良い。図6の例において、フローチャート600は、モジュール602でスタートし、ここで装置IDが取得される。装置IDは、シリアルナンバーであっても、或いは装置のための他の何らかの固有な識別子であっても良い。
【0054】 図6の例で、フローチャート600は、モジュール604に進み、ここでは装置のために小署名プライベートキー(a small-signature privatekey)として使用する目的で、擬似乱数が供される。今日に至るまで、本当の意味での乱数というものはコンピュータ上では生成できないが、当然のことながら、疑似乱数発生器や外部のセキュアなハードウェアにおける真性乱数発生器が、ここで意図する目的のために使用できるだろう。小署名プライベートキーは、これに限定されない例として、楕円カーブプライベートキーや比較的小さなフットプリント(footprint)を持った他の何らかのプライベートキーでも良い。
【0055】 図6の例で、フローチャート600は、モジュール606に進み、ここでは共通パラメータを使用してプライベートキーから公開鍵が算出される。例えば、スカラー倍数(scalar multiple)がプライベートキーとなるように、基点(base point)の倍数が算出されても良い。
【0056】 図6の例で、フローチャート600は、モジュール608に進み、ここでは一定の証明書構造(fixed certificate structure)が、証明書を作成するために使用される。証明書は、例えば楕円カーブDSAなどの小署名アルゴリズム(small signature algorithm)を使用して署名される。一実施形態では、該一定の証明書構造は、少なくとも装置ID、発行者名、及びデバイス公開鍵を含むかもしれない。小署名アルゴリズムは、署名サイ 24 ズを最小限におさえるのに使用される。これに限定されない例として、楕 円カーブ署名アルゴリズムが使用されても良い。
【0057】 図6の例で、フローチャート600は、モジュール610に進み、ここ では｛装置ID、プライベートキー、発行者ID、署名｝が、装置の不非 揮発性メモリにプログラミングされる。このセットは、これらのアイテム が殆どの目的に対して充分セキュリティを提供するという理由でこれら 4つのアイテムを含んでおり、また該セットは、比較的小さいサイズのプ ライベートキーと署名のおかげで比較的小さいフットプリントを有する (推定するに、装置ID及び発行者IDも又、比較的小さいフットプリン トを有している)。一実施形態では、例えば公開鍵など、デバイス証明書の 作成(construct)に必要とされる如何なるデータも、要求に応じてプログ ラミングされた状態で生成されても良い。しかしながら、与えられた実施 形態や実装に見合った形で、より多くのアイテム、又より少ないアイテム が不揮発性メモリにプログラミングされ得る。
【0058】 図6の例では、フローチャート600は、モジュール612に進み、秘 密の乱数が装置のROMにプログラミングされる。この秘密乱数は、疑似 乱数的に生成されても、また任意に割り当てられるようにしても良い。こ の秘密乱数は、セキュアな擬似乱数の生成をサポートするのに利用できる。
また別の実施形態では、ROMが、他の公知の(又は手頃な)不揮発性記 憶装置と置き換えられても良い。
カ 【0059】 図7は、セキュア証明書の作成方法の例を示したフローチャート700 である。メリットとして、この方法は、不揮発性でプログラミングされた 鍵と必要なソフトウェアを有する装置が、装置認証に使用可能な完全なデ 25 バイス証明書を作成することを可能にする。図7の例では、フローチャート700は、モジュール702でスタートし、ここではデバイス証明書のリクエストが、呼出しアプリケーションから受け取られる。
【0060】 図7の例で、フローチャート700は、モジュール704に進み、ここでは｛装置ID、プライベートキー、発行者ID、署名｝が、不非揮発性メモリから読み込まれる。一実施形態では、セキュリティカーネル・モジュールが、不揮発性メモリにアクセスして読み込む。この目的のために適切なセキュリティカーネル・モジュールの例としては、Srinivasan らによって2003年2月7日に出願された“信頼性や下位互換性のあるプロセッサ及びその上でのセキュアソフトウェア実行”というタイトルの米国出願第10/360、827号や、Srinivasan らによって2006年10月24日に出願された“セキュアデバイス認証システム及び方法”というタイトルの米国出願第11/586、446号に記載されている。しかしながら、如何なる適用可能な公知の(又は手頃な)セキュリティカーネル・モジュールでも使用可能である。
【0061】 図7の例で、フローチャート700は、モジュール706に進み、ここでは公開鍵が、プライベートキーと(もしあるならば)共通パラメータとによって算出される。一実施形態では、この演算は、図6を参照して上述した方法のような製造プロセスに使用されたのと同じアルゴリズムを利用する。公開鍵は、セキュリティカーネルで算出されても良い。
【0062】 図7の例で、フローチャート700は、モジュール708に進み、ここではデバイス証明書が、装置ID、発行者ID、公開鍵、署名、及び共通パラメータから作成される。一実施形態において、セキュリティカーネル・ 26 モジュールは、図6を参照して上述した方法のような製造プロセスで使用 されおり、該デバイス証明書の構造を認識している。メリットとして、デ バイス証明書は、要求に応じて作成できる。
【0065】 ここで使用されたように、用語“実施形態”は、それに限定されない一 例として説明を行うための実施例を意味している。
【0066】 当業者であれば前述した実施例と実施形態は、代表的なものであり、本 発明の範囲を限定するものでないことが理解されるであろう。当業者が明 細書を考慮し、図面を検討したときに自明な置き換え、増強、均等物やそ れらへの改良が、本発明の要旨と範囲に含まれることを意図している。し たがって、添付された特許請求の範囲は、本発明の要旨と範囲内にあるこ のような総ての変更、置き換え、均等物を含むことを意図している。
? 引用文献1の記載事項 引用文献1(甲6)には、次のような記載がある(下記記載中に引用する 図1ないし4、8、21については別紙2を参照)。
ア 【技術分野】 【0001】 本発明は、データを盗聴、改竄等から安全に保持するICカード等のセ キュリティデバイスと、そのセキュリティデバイスを装着した携帯電話や PDA(Personal Digital Assistant)、パーソナルコンピュータなどの情 報端末に関するもので、特に、電子マネーや電子チケット、音楽や画像、
映像などのデジタルコンテンツ等の価値情報を扱う機器に関するもので ある。
【背景技術】 【0002】 27 近年、CPUと耐タンパ性のある記憶領域を持つICカード等のセキュリティデバイスは、カードアプリ(アプリはアプリケーションの略である。
以下同様である)を動作させることが可能であり、電子マネーや定期券、
電子チケット等のサービスに利用されている。
【0003】 例えば、前述したセキュリティデバイスが携帯電話等の情報端末に内蔵されたものがある。これによれば、情報端末のキーボードやディスプレイをセキュリティデバイスに対するユーザインターフェイスとして使用することができる。また、セキュリティデバイスに書き込むデータや読み出したデータを、情報端末の通信機能を利用してネットワーク上で伝送することができるので、様々なサービスを利用することができる。この場合、
それらのサービスを実行する際に情報端末が行うべき動作を規定した端末アプリが情報端末上で動作する。
【0004】 従来、情報端末は、サービスプロバイダからネットワークを通じて端末アプリをダウンロードするなどして、この端末アプリを取得している。例えば、図21に示すように、セキュリティデバイス2111に保持された電子マネーや電子チケット等の価値情報2113をオフライン環境下で表示する端末アプリ2108を、サービスプロバイダ2121からダウンロードする携帯端末2101が開示されている(特許文献1参照)。
【0005】 この携帯端末2101は、端末アプリ2108のダウンロード及びそのダウンロードした端末アプリ2108を実行するプログラム制御部2102と、ダウンロードした端末アプリを記憶する格納部2103と、サービスプロバイダ2121との通信を行う通信部2104と、ユーザがサービスプロバイダ2121のURLを入力するユーザ入力部2105と、L 28 CD等の表示部2106と、を備えている。また、プログラム制御部2102には、さらに、ダウンロードした端末アプリを検証する検証部2107を備えている。一方、セキュリティデバイス2111は、内部のメモリに記憶されている価値情報2113を管理するカードアプリ2112を備えている。
【0006】 このセキュリティデバイス2111に蓄積された価値情報2113を、
オフライン環境下において携帯端末2101を用いて参照する場合、ユーザは、まず、ユーザ入力部2105にサービスプロバイダ2121のサーバに格納されている端末アプリ2108のURLを入力する。入力されたURLはプログラム制御部2102に渡され、プログラム制御部2102は渡されたURLに基づいて通信部2104を介してサービスプロバイダ2121のサーバと通信し、サービスプロバイダ2121から端末アプリ2108をダウンロードし(1) 検証部2107において端末アプリ2 、
108の検証を行い(2) 問題がなければ端末アプリ2108を格納部2 、
103に保存する(3)。
【0007】 ユーザによって端末アプリ2108の起動操作が行われると、プログラム制御部2102は格納部2103から端末アプリ2108を読み出し、
起動する(4)。起動された端末アプリ2108は、携帯端末2101に装着されたセキュリティデバイス2111のカードアプリ2112に価値情報2113を要求する(5)。カードアプリ2112は、内部のメモリに記憶されている価値情報2113を読み出して携帯端末2101側に送り(6)、端末アプリ2108は、取得した価値情報2113を携帯端末2101の表示部2106に表示する処理を行う(7)。
【発明が解決しようとする課題】 29 【0008】 しかしながら、上記従来技術では、以下に示すような問題点があった。
すなわち、セキュリティデバイス2111は、サービスプロバイダ212 1から端末アプリケーション2108をダウンロードし、検証部2107 において検証を行い、格納部2103に保存する。しかし、一度検証を経 て保存された端末アプリケーション2108は再び検証される機会がな い。そのため、一度検証を経て保存された端末アプリケーション2108 に対して、価値情報2113へのアクセスの制限などを解除する改竄が施 された場合は、セキュリティデバイス内の価値情報2113が不正に使用 される恐れがあり、セキュリティの観点から好ましくない。また、サービ スプロバイダからダウンロードしたコンテンツについても同様の問題が 生じる。
【0009】 本発明は、上記実情を鑑みてなされたものであり、改竄が加えられたア プリケーション等の実行を防ぐことができるセキュリティデバイスを提 供することを目的とする。
イ 【課題を解決するための手段】 【0010】 本発明のセキュリティデバイスは、内部に保持された価値情報を外部端 末から参照するためのアプリケーションを記憶する記憶手段と、前記アプ リケーションの同一性を保証する加工処理を行う加工手段と、加工処理し たアプリケーションを記憶する記憶手段と、加工処理したアプリケーショ ンを前記外部端末に対して発行する発行手段とを備える。また、本発明の セキュリティデバイスは、外部端末で再生するコンテンツを記憶する記憶 手段と、前記コンテンツの同一性を保証する加工処理を行う加工手段と、
加工処理したコンテンツを記憶する記憶手段と、加工処理したコンテンツ 30 を前記外部端末に対して発行する発行手段とを備える。また、本発明のセキュリティデバイスは、外部端末で再生するコンテンツを記憶する記憶手段と、前記コンテンツの同一性を保証する加工処理を行う加工手段と、加工処理したコンテンツを記憶する記憶手段と、加工処理したコンテンツを前記外部端末に対して発行する発行手段と、前記コンテンツを再生するアプリケーションを記憶する記憶手段と、前記アプリケーションの同一性を保証する加工処理を行う加工手段と、加工処理したアプリケーションを記憶する記憶手段と、加工処理したアプリケーションを前記外部端末に対して発行する発行手段とを備える。
【0011】上記構成によれば、セキュリティデバイスが保持する価値情報を外部端末で参照するアプリケーションや外部端末で再生するコンテンツに対してセキュリティデバイス側でアプリケーション、コンテンツの同一性を保証する加工処理を施した上で外部端末に発行することで、外部端末がアプリケーションの起動毎、コンテンツの再生毎にアプリケーション、コンテンツの同一性を検証することが可能となり、改竄したアプリケーションの実行、コンテンツの再生を防ぐことができる。
【発明の効果】【0012】本発明によれば、セキュリティデバイスが保持する価値情報を外部端末で参照するアプリケーションや外部端末で再生するコンテンツに対してセキュリティデバイス側でアプリケーション、コンテンツの同一性を保証する加工処理を施した上で外部端末に発行することで、外部端末がアプリケーションの起動毎、コンテンツの再生毎にアプリケーション、コンテンツの同一性を検証することが可能となり、改竄したアプリケーションの実行、コンテンツの再生を防ぐことができる。
31 ウ 【発明を実施するための最良の形態】 【0013】 以下、本発明の実施の形態を、図面を参照しながら説明する。
(実施の形態1) 図1に、本発明の第1の実施の形態におけるセキュリティデバイス10 2と情報端末101のシステム構成を示す。
【0014】 セキュリティデバイス102は、耐タンパ機構を有し、その内部で安全 なデータ処理を行う耐タンパデータ処理部150と、耐タンパデータ処理 部150が処理したデータを格納するフラッシュメモリ151と、耐タン パデータ処理部150が情報端末101などのホスト機器との通信を制 御するホスト機器通信手段157と、によって構成される。
【0015】 耐タンパデータ処理部150は、内部にCPUやROM、EEPROM、
RAM、更には、暗号処理用のコプロセッサを有し、ROMおよびEEP ROMに格納されたプログラムに基づいてCPUがRAMおよびフラッ シュメモリ151を用いてデータ処理を行う。
【0016】 耐タンパデータ処理部150には、ホスト機器通信手段157を介して 外部から端末アプリケーションを受信するアプリケーション取得手段1 53と、
端末アプリケーションに対して、認証情報の埋め込みや、電子署名などの 加工処理を施すアプリケーション加工手段152と、加工処理を施した端 末アプリケーションを情報端末101に対して発行するアプリケーショ ン発行手段154と、があり、これらは、実際には、耐タンパデータ処理 部150の内部のROMやEEPROMに格納されているプログラムを 32 耐タンパデータ処理部150のCPUが実行することによって実現される。
【0017】 また、フラッシュメモリ151には、アプリケーション取得手段153が外部から受信した加工処理を行う前の端末アプリケーションを格納する領域であるオリジナルアプリケーション記憶部155と、アプリケーション加工手段152が加工処理を施した後の端末アプリケーションを格納する領域である加工済みアプリケーション記憶部156と、がある。CPUが端末アプリケーションをオリジナルアプリケーション記憶部155または加工済みアプリケーション記憶部156に格納する場合、端末アプリケーションは、CPUおよびコプロセッサによって、暗号化されてそれぞれの記憶部に格納され、また、オリジナルアプリケーション記憶部155または加工済みアプリケーション記憶部156に暗号化された状態で格納されている端末アプリケーションをCPUが読み出した場合、端末アプリケーションはCPUおよびコプロセッサによって復号化される。
【0019】 また、情報端末101は、プログラムに基づいてデータ処理を行うデータ処理部110と、セキュリティデバイス102との通信を制御するセキュリティデバイス通信手段116と、ネット上のサーバ機器や他の情報端末との無線通信を行う無線通信手段115と、キー入力スイッチなどの入力手段117と、データ処理部110が処理したデータを表示するLCDなどの表示手段118と、によって構成される。
【0020】 データ処理部110は、内部にCPUやROM、EEPROM、RAMを有し、ROMおよびEEPROMに格納されたプログラムに基づいてCPUがRAMおよびEEPROMを用いてデータ処理を行う。
33 【0021】 データ処理部110には、端末アプリケーションのプログラムコードを 解釈して実行するアプリケーション実行手段111と、端末アプリケーシ ョンのセキュリティデバイス102へのダウンロード、および、セキュリ ティデバイス102に格納された端末アプリケーションの情報端末10 1へのロードを行うアプリケーション管理手段113と、情報端末101 に次にロードされる端末アプリケーションを準備するアプリケーション 準備手段112と、端末アプリケーションに施された電子署名を検証して、
その有効性を検証するアプリケーション検証手段114と、があり、これ らは、実際には、データ処理部110の内部のROMやEEPROMに格 納されているプログラムをデータ処理部110のCPUが実行すること によって実現される。
【0022】 アプリケーション検証手段114には、電子署名を検証する際に利用す るルートCA証明書119(CAは Certificate Authority を意味する) と、アプリケーション検証手段114が行う端末アプリケーションの検証 処理の仕様を示す検証プロファイル120と、が保持されている。アプリ ケーション検証手段114はルートCA証明書119を複数個、保持して いても良い。
エ 【0026】 端末アプリケーションをコンテンツプロバイダ(CP)のネット上のサ ーバからダウンロードする場合には、端末アプリケーションは、アプリケ ーション管理手段113によって、無線通信手段115を介してCPのサ ーバからダウンロードされ、セキュリティデバイス通信手段116および ホスト機器通信手段157を介してアプリケーション取得手段153に 送信され、アプリケーション取得手段153が、受信した端末アプリケー 34 ションをオリジナルアプリケーション記憶部155に格納する。
【0027】この後、アプリケーション準備手段112によって、加工処理要求がアプリケーション加工手段152に送信され、加工処理要求を受信したアプリケーション加工手段152が、オリジナルアプリケーション記憶部155に格納されている端末アプリケーションに対して適当な加工処理を施し、加工済みアプリケーション記憶部156に格納する。
【0028】 セキュリティデバイス102に格納された端末アプリケーションを実行する場合には、アプリケーション管理手段113によって、アプリケーション発行要求がアプリケーション発行手段154に送信され、アプリケーション発行要求を受信したアプリケーション発行手段154が、加工済みアプリケーション記憶部156から要求された端末アプリケーションを読出し、アプリケーション管理手段113に送信する。アプリケーション管理手段113は受信した端末アプリケーションをアプリケーション検証手段114に転送し、アプリケーション検証手段114が端末アプリケーションに施された電子署名を検証してその有効性を検証する。この時、
アプリケーション検証手段114による検証をパスした端末アプリケーションだけが、アプリケーション実行手段111に転送され、アプリケーション実行手段111によって端末アプリケーションが起動される。
【0029】この後、アプリケーション実行手段111によって起動された端末アプリケーションは、まず、アプリケーション発行手段154によって、加工処理の際に埋め込まれた認証情報に基づいた認証処理が行われ、その認証処理にパスした場合のみ、その後の端末アプリケーションに固有の処理がアプリケーション実行手段111によって実行される。
35 【0030】このように、情報端末101において実行される端末アプリケーションを、情報端末101とセキュリティデバイス102とが認証することによって、不正な端末アプリケーションの実行が防止される。特に、端末アプリケーションがセキュリティデバイスのフラッシュメモリ151に格納された価値情報(図面には示されていない)を一定の制約のもとに利用するアプリケーションである場合には、それらの制約を不正に解除するなどの改竄が行われた端末アプリケーションの実行自体が防止されるので、価値情報は不正な利用から守られる。
【0031】次に、セキュリティデバイス102の内部のデータの詳細について説明する。図2は、アプリケーション加工手段152が内部に保持するデータの詳細と、セキュリティデバイス102に格納される端末アプリケーションのデータ構成を示している。アプリケーション加工手段152は、内部に、セキュリティデバイス102が装着されるホスト機器が行う端末アプリケーションの検証処理の仕様を示す検証プロファイル223と、端末アプリケーションに電子署名を行う際に用いるセキュリティデバイス秘密鍵221と、セキュリティデバイス秘密鍵221に対応するセキュリティデバイス証明書222と、ルートCA証明書224とを保持する。
【0032】アプリケーション加工手段152は、検証プロファイル223とセキュリティデバイス秘密鍵221、セキュリティデバイス証明書222、ルートCA証明書224を、それぞれ、複数個、保持していても良い。
【0033】 検証プロファイル223のデータ構造は、検証プロファイル120のデータ構造と同様であり、セキュリティデバイス102を頻繁に装着するホ 36 スト機器としてセキュリティデバイス102に登録されたホスト機器の検証プロファイルがホスト機器ごとに保持される。この場合は、情報端末101の検証プロファイル120が検証プロファイル223として登録されている。
【0034】 また、オリジナルアプリケーション記憶部155に格納されている端末アプリケーションは、それぞれ、実際のプログラムコードの部分であるアプリケーションコード201と、端末アプリケーションの発行者であるコンテンツプロバイダ(CP)によってアプリケーションコード201に施された電子署名である署名202と、署名202の有効性を証明する証明書チェーン203と、端末アプリケーションの属性情報204と、その端末アプリケーションに施されるべき加工処理の内容を規定した加工指示書205と、から構成される。
【0035】 図4(a)は、オリジナルアプリケーション記憶部155に格納されている端末アプリケーションのアプリケーションコード201と署名202と証明書チェーン203の部分の一例を示しており、図3は、この場合のルートCA301と中間CA302、コンテンツプロバイダ(CP)303、情報端末101、及びセキュリティデバイス102との間のシステム構成を示している。
【0036】 この場合、証明書チェーン203は、ルートCA301によって発行された中間CA302の中間CA証明書322と、中間CA302によって発行されたCP303のCP証明書322とから構成され、情報端末101とセキュリティデバイス102は、それぞれ、保有するルートCA証明書を用いて、これらの証明書チェーン203を構成する証明書を検証する 37 ことによってCP303によってアプリケーションコード201に施さ れた署名202の有効性を検証することが出来る。
オ 【0049】 次に、図8を用いて、CP303からセキュリティデバイス102に端 末アプリケーションをダウンロードするシーケンス、及び、セキュリティ デバイス証明書をダウンロードするシーケンスについて説明する。
【0050】 まず、入力手段117から入力されたユーザ操作に基づいて、情報端末 101が無線通信手段115を介し無線通信によってCP303に端末 アプリケーションを要求するメッセージを送信すると(アプリケーション 要求801) CP303は、
、 情報端末101に装着されたセキュリティデ バイス102に対して、セキュリティデバイス証明書を要求するメッセー ジを送信する(セキュリティデバイス証明書要求802または811)。
【0051】 セキュリティデバイス証明書要求802(または811)には、CP3 03が生成した乱数が含まれており、情報端末101のセキュリティデバ イス通信手段を介してセキュリティデバイス102に送信される。
【0052】 セキュリティデバイス証明書要求802を受信したセキュリティデバイ ス102は、アプリケーション取得手段153がアプリケーション加工手 段152に保持されているセキュリティデバイス証明書を調べ、CP30 3が発行したセキュリティデバイス証明書が保有されている場合には、ア プリケーション取得手段153がアプリケーションの発行を要求するメ ッセージを生成して(アプリケーション発行要求生成813)CP303 に送信し(アプリケーション発行要求813) セキュリティデバイス証明 、
書を保有していない場合には、アプリケーション取得手段153がCPに 38 セキュリティデバイス証明書の発行を要求するメッセージを生成して(証明書発行要求生成803)CP303に送信する(証明書発行要求804)。
【0053】 この時、アプリケーション発行要求813には、CP303が発行したセキュリティデバイス証明書と、アプリケーション取得手段153がそのセキュリティデバイス証明書に対応するセキュリティデバイス秘密鍵を用いてセキュリティデバイス証明書要求802(または811)に含まれていた乱数に対して施した電子署名が含まれ、証明書発行要求804には、
その他のセキュリティデバイス証明書と、アプリケーション取得手段153がそのセキュリティデバイス証明書に対応するセキュリティデバイス秘密鍵を用いてセキュリティデバイス証明書要求802に含まれていた乱数に対して施した電子署名が含まれる。
【0054】 証明書発行要求804を受信したCP303は、証明書発行要求804に含まれていた電子署名(セキュリティデバイス証明書要求802に含まれていた乱数に対する電子署名)を同じく証明書発行要求804に含まれていたセキュリティデバイス証明書を用いて検証して(署名検証805)、
セキュリティデバイス102がセキュリティデバイス秘密鍵を保持していることを検証し、さらにCP303は、そのセキュリティデバイス証明書に含まれるセキュリティデバイス公開鍵を用いて新たにセキュリティデバイス証明書を生成して(セキュリティデバイス証明書生成806) セ 、
キュリティデバイス102に送信する(セキュリティデバイス証明書807)。仮に、署名検証805においてエラーが検出された場合には、CP303は、エラーメッセージを情報端末101に送信して処理を中止する(図には示していない)。
【0055】 39 セキュリティデバイス証明書807は、情報端末101を介してセキュリティデバイス102に送信され、セキュリティデバイス証明書807を受信したセキュリティデバイス102は、アプリケーション取得手段153がセキュリティデバイス証明書807をアプリケーション加工手段152に保存して、セキュリティデバイス証明書807の取得を完了したことを示す応答メッセージを情報端末101に送信する(完了応答809)。
【0056】 完了応答809を受信した情報端末101は、改めてCP303に端末アプリケーションを要求するメッセージを送信する(アプリケーション要求810)。
【0057】 アプリケーション発行要求813を受信したCP303は、アプリケーション発行要求813に含まれていた電子署名(セキュリティデバイス証明書要求802または811に含まれていた乱数に対する電子署名)を同じくアプリケーション発行要求813に含まれていたCP303が発行したセキュリティデバイス証明書を用いて検証して(署名検証814) セ 、
キュリティデバイス102がCP303が発行したセキュリティデバイス証明書に対応するセキュリティデバイス秘密鍵を保持していることを検証し、さらにCP303は、そのセキュリティデバイス証明書に含まれるセキュリティデバイス公開鍵を用いて発行する端末アプリケーションを暗号化して(アプリケーション暗号化815) セキュリティデバイス1 、
02に送信する(暗号化されたアプリケーション816)。
【0058】 この時、暗号化する前の端末アプリケーションには、その有効性を示すためにCP303による電子署名が施され、それを検証するための証明書が付加されている(図4(a)は暗号化する前の端末アプリケーションデ 40 ータ構造の一例を示している) また仮に、
。 署名検証814においてエラーが検出された場合には、CP303は、エラーメッセージを情報端末101に送信して処理を中止する(図には示していない)。
【0059】 暗号化されたアプリケーション816は、情報端末101を介してセキュリティデバイス102に送信され、暗号化されたアプリケーション816を受信したセキュリティデバイス102は、アプリケーション取得手段153が、アプリケーション加工手段152が保持するセキュリティデバイス秘密鍵を用いて暗号を復号化し(暗号復号化817)、さらに、端末アプリケーションに施されたCP303による電子署名を検証して端末アプリケーションの有効性を検証し(署名検証818) 端末アプリケーショ 、
ンをオリジナルアプリケーション記憶部155に保存して(アプリケーション保存819)、端末アプリケーションの取得を完了したことを示す応答メッセージを情報端末101に送信する(完了応答820)。
【0060】 仮に、署名検証819においてエラーが検出された場合には、アプリケーション取得手段153は、端末アプリケーションを消去し、エラーメッセージを情報端末101に送信して処理を中止する(図には示していない)。
【0061】 完了応答820を受信した情報端末101は、端末アプリケーションのダウンロードが完了したことを示すメッセージを表示手段118に表示して処理を終了する。
【0070】 以上ように、情報端末101において実行される端末アプリケーションを、情報端末101とセキュリティデバイス102とが認証することによ 41 って、不正な端末アプリケーションの実行が防止される。
【0071】 特に、端末アプリケーションがセキュリティデバイスのフラッシュメモ リ151に格納された価値情報(図面には示されていない)を一定の制約 のもとに利用するアプリケーションである場合には、それらの制約を不正 に解除するなどの改竄が行われた端末アプリケーションの実行自体が防 止されるので、価値情報は不正な利用から守られる。
? 「クライアント装置」に係る一致点の認定の誤りについて 原告は、本願発明の「クライアント装置」に相当するのは、引用発明の「情 報端末101」であって、
「セキュリティデバイス102」でないから、本件 審決が、引用発明の「セキュリティデバイス102」が本願発明の「クライ アント装置」に相当するとの認定を前提に、本願発明と引用発明は、
「前記第 1の数と前記証明書のリクエストは前記クライアント装置に送られ」る点で 一致すると認定したのは誤りである旨主張する。
ア 本願発明の特許請求の範囲の請求項1には、本願発明の「サーバ」は、
「数発生器」と「証明書リクエストモジュール」と、これらに「接続する インターフェース」を備えており、「数発生器」は「第1の数」を、「証明 書リクエストモジュール」は「デバイス証明書のリクエスト」をそれぞれ 生成し、「前記第1の数」と「前記デバイス証明書のリクエスト」は、「前 記インターフェースを介してクライアント装置に送られ」るとの記載があ る。これらの記載によれば、本願発明の「クライアント装置」 「サーバ」 は、
が生成し、送信する「第1の数」及び「デバイス証明書のリクエスト」を 受信する機能を有するものであると解される。
イ 引用文献1には、
「CP303は、情報端末101に装着されたセキュリ ティデバイス102に対して、セキュリティデバイス証明書を要求するメ ッセージを送信する(セキュリティデバイス証明書要求802または81 42 1) 」【0050】、
。( )「セキュリティデバイス証明書要求802(または8 11)には、CP303が生成した乱数が含まれており、情報端末101 のセキュリティデバイス通信手段を介してセキュリティデバイス102 に送信される。 ( 」 【0051】 、
) 「セキュリティデバイス証明書要求802 を受信したセキュリティデバイス102」 (【0052】 との記載があり、
) また、上記各段落の説明に用いられる図8には、
「セキュリティデバイス証 明書要求802」及び「セキュリティデバイス証明書要求811」につい て、それぞれ「CP303」から「情報端末101」を通過し「セキュリ ティデバイス102」を終点とする矢印が引かれている。引用文献1の上 記記載及び図8から、引用発明の「CP303」は、
「乱数」と「セキュリ ティデバイス証明書要求」を生成し、これらを「セキュリティデバイス1 02」に送信し、
「セキュリティデバイス102」は、これらを受信するも のと理解できる。そして、引用発明の「CP303」 「乱数」 「セキュリ 、 、
ティデバイス証明書要求」は、それぞれ、本願発明の「サーバ」 「第1の 、
数」 「デバイス証明書のリクエスト」に相当するから、引用発明の「セキ 、
ュリティデバイス102」は、「サーバ」(CP303)が生成し、送信す る「第1の数」(乱数)及び「デバイス証明書のリクエスト」(セキュリテ ィデバイス証明書要求)を受信する機能を有するものと認められる。
したがって、引用発明の「セキュリティデバイス102」は、本願発明 の「クライアント装置」に相当すると認められる。
ウ これに対し、原告は、引用発明は、
「セキュリティデバイス102」 「情 が 報端末101」に装着されて「情報端末101」と通信するように構成さ れ,本願発明の「サーバ」に相当する引用発明の「CP303」には「情 報端末101」が無線ネットワークを介して接続される構成であることか らすると、本願発明の「クライアント装置」に相当するのは、引用発明の 「情報端末101」であって、
「セキュリティデバイス102」でない旨主 43 張する。
しかし、前記イのとおり、引用文献1の図8において「CP303」か ら発せられた「セキュリティデバイス証明書要求802」及び「セキュリ ティデバイス証明書要求811」が、
「情報端末101」を通過して「セキ ュリティデバイス102」に到達するように矢印が引かれていることに照 らすと、引用発明の「セキュリティデバイス102」が「CP303」か ら送信された「乱数」及び「セキュリティデバイス証明書要求」の送受信 は、
「CP303」と「セキュリティデバイス102」との間で行われ、
「情 報端末101」は通過点にすぎないものと解される。
したがって、引用発明の「情報端末101」が本願発明の「クライアン ト装置」に相当するとの原告の上記主張は理由がない。
エ 以上によれば、本願発明と引用発明は、
「前記第1の数と前記証明書のリ クエストは前記クライアント装置に送られ」る点で一致するとした本件審 決の認定の誤りをいう原告の主張は理由がない。
? 「第2の署名」に係る一致点の認定の誤りについて 原告は、本件審決は、引用発明の「乱数に施した電子署名」が本願発明の 「クライアント装置において該クライアント装置の製造中にプログラムされ たプライベートキーと前記サーバの数発生器が作成した第1の数を使用して 生成される第2の署名」に相当するとの認定を前提に、本願発明と引用発明 は、
「レスポンス」が「該クライアント装置の製造中にプログラムされたプラ イベートキーと前記サーバの数発生器が作成した第1の数を使用して生成さ れる第2の署名」を含む点で一致すると認定したが、本願発明の「第1の数 を使用して生成される第2の署名」は、第1の数を使用して新たに生成され るものであり、
「乱数に施したことで得られた電子署名」に対応する署名であ るのに対し、引用発明の「乱数に施した電子署名」とは、その文言から、
「電 子署名を乱数に施した」ことを意味するものであり、電子署名自体には、変 44 化がなく、
「乱数に施したことで得られた電子署名」とは異なるものであるから、本件審決の上記一致点の認定は誤りである旨主張する。
ア 本願発明の特許請求の範囲の請求項1の記載によれば、本願発明の「第 1の数を使用して生成される第2の署名」とは、「プライベートキー」(秘 密鍵)と「第1の数」を用いて生成される電子署名であると解される。こ のような理解は、本願明細書の「証明書作成モジュール120は、デバイ ス・プライベートキーを使用し、乱数R上の署名Sigを算出する。( 」【0 015】)との記載にも合致する。
イ 引用文献1には、
「証明書発行要求804には、…セキュリティデバイス 秘密鍵を用いてセキュリティデバイス証明書要求802に含まれていた 乱数に対して施した電子署名が含まれる。 ( 」 【0053】 、
) 「証明書発行要 求804を受信したCP303は、証明書発行要求804に含まれていた 電子署名(セキュリティデバイス証明書要求802に含まれていた乱数に 対する電子署名)を同じく証明書発行要求804に含まれていたセキュリ ティデバイス証明書を用いて検証して(署名検証805) ( 」 【0054】) との記載がある。これらの記載及び図8によれば、引用発明の「乱数に対 して施した電子署名」は、「プライベートキー」(セキュリティデバイス秘 密鍵) 「第1の数」 と (乱数)を用いて生成される署名であるといえるから、
本願発明の「第1の数を使用して生成される第2の署名」に相当すると認 められる。
ウ これに対し、原告は、引用発明の「乱数に施した電子署名」とは、その 文言から、「電子署名を乱数に施した」ことを意味するものであり、「乱数 に施したことで得られた電子署名」とは異なる旨主張する。
しかし、引用発明の「乱数に対して施した電子署名」 (乱数に施した電子 署名)が乱数に対してセキュリティデバイス秘密鍵を用いて生成される電 子署名を意味すると解されることは前記イのとおりであって、原告の上記 45 主張の解釈は、文言解釈として不自然であり、採用することができない。
エ 以上によれば、本願発明と引用発明は、
「レスポンス」が「該クライアン ト装置の製造中にプログラムされたプライベートキーと前記サーバの数発 生器が作成した第1の数を使用して生成される第2の署名」を含む点で一 致するとした本件審決の認定の誤りをいう原告の主張は理由がない。
2 相違点2の容易想到性の判断の誤りについて ? 本願優先日当時の技術常識について ア 各文献の記載事項 (ア) 乙1(「暗号技術入門 秘密の国のアリス」第3版、8頁〜10頁、
227頁〜228頁、2016年3月18日発行、SBクリエイティブ 株式会社) 「暗号アルゴリズム …平文から暗号文を作る手順、すなわち暗号化の手順のことを「暗 号化のアルゴリズム」と呼び、復号化の手順のことを「復号化のアル ゴリズム」と呼びます。暗号化・復号化のアルゴリズムを合わせて暗 号アルゴリズムと呼びます。」 「鍵 …暗号化を行うときも、復号化を行うときも、いずれの場合にも鍵 が必要になります。」 「対称暗号と公開鍵暗号 暗号は、鍵の使い方によって、対称暗号と公開鍵暗号の2種類に分 類できます。
対称暗号(…)は、暗号化と復号化で同じ鍵を使う方式です。… それに対して公開鍵暗号(…)は、暗号化と復号化で異なる鍵を使 う方式です。… Fig.1-8●対称暗号と公開鍵暗号」 46 「公開鍵暗号とデジタル署名 …デジタル署名の実現には、…公開鍵暗号の仕組みを利用します。
公開鍵暗号では、公開鍵とプライベート鍵の鍵ペアを使い、公開鍵で 暗号化して、プライベート鍵で復号化しました(…)。
デジタル署名でも、同じように公開鍵とプライベート鍵の鍵ペアを 使います。しかし、2つの鍵の使い方は公開鍵暗号とは逆になります。
メッセージをプライベート鍵で暗号化することが署名の作成に相当し、
その暗号文を公開鍵で復号化することが署名の検証に相当します。2 つの図を比較して公開鍵暗号を「逆に使っている」様子を理解してく ださい(…)。
…つまり、ある公開鍵を使って暗号文が正しく復号化できたなら、
その暗号文は、その公開鍵と対になったプライベート鍵で暗号された はず、ということがいえます。
Fig.9-2●プライベート鍵による暗号化(デジタル署名) プライベート鍵で暗号化するというのは、そのプライベート鍵を使 える人にしか実現できない行為ですから、この事実から「プライベー ト鍵による暗号文」を「署名」として扱おうというのです(…)。
公開鍵は一般に公開できますから、公開鍵による復号化は誰にでも できることになります。これは、誰でもデジタル署名の検証が行える という大きなメリットになります。」 (「Fig.1-8」 「Fig. 及び 9-2」については別紙3を参照)(イ) 乙2(「暗号技術のすべて」、598頁〜599頁、2017年9月 15日発行、株式会社翔泳社) 「8.5.1 電子証明書とは 電子証明書(…)は、公開鍵がその証明書に書かれた所有者のも のであることを証明するために用いられます。ここでいう公開鍵と 47 は、公開鍵暗号の公開鍵や、デジタル署名の検証鍵を指します。」 「8.5.2 証明書のフォーマット 証明書のフォーマットは、国際標準化団体のITU(国際電気通 信連合)により、標準化されており、その代表的なものがX.50 9です。X.509では、証明書の論理的構造を規定しています。
…X.509証明書は、
「署名前証明書」 「署名アルゴリズム」 「署名 値」から構成されます(表8.6)。署名前証明書は、基本領域と拡 張領域に分けられます。基本領域には、証明書の所有者の公開鍵に 関する情報が記載されます。拡張領域には、基本領域を補足する情 報が追加されます。例えば、
「検証鍵情報」 「鍵使用目的(署名検証・ 否認防止・暗号化など) 「ポリシー情報」などが含まれます。署名 」 値は、署名前証明書に対する認証局のデジタル署名です。
証明書は使用する形式によって、PKCS#11(ICカードな ど)やPKCS#12(データファイルなど)で保存されます。」 (「表8.6」については別紙4を参照)(ウ) 引用文献3(甲27) 【0110】 クライアントIDが登録済みである場合は、ステップS145に進み、
サーバは、クライアントの保持するコピーコンテンツに対応するコンテ ンツIDリストの送信をクライアントに要求する。なお、この要求をク ライアントに送信する際、サーバは、サーバクライアント間で転送され るコンテンツIDリストの安全性、正当性を確保するために適用するデ ータとして、乱数値(Randｏm challenge)とサーバの 保持するデバイス証明書(公開鍵証明書)をクライアントに送信する。
【0111】 クライアントは、ステップS244において、乱数値とデバイス証明 48 書を伴ったコンテンツIDリスト要求を受信し、ステップS245にお いて、利用期間の更新要求対象としたコンテンツを受領したサーバのサ ーバIDに対応付けられたコピーコンテンツのコンテンツIDからなる リストを生成して、サーバに送信する。このリスト送信に際して、クラ イアントは、クライアントが生成した乱数値と、クライアントのデバイ ス証明書(公開鍵証明書)を送信する。
【0114】 図9(b)に、リストに併せて送信されるデバイス証明書(公開鍵証 明書)のデータ構成例を示す。デバイス証明書(公開鍵証明書)は以下 のデータを含む。
デバイスID[Deｖice ID]=クライアントID デバイス公開鍵[Deｖice Pｕblic Keｙ] 発行元電子署名[Signaｔｕｒe bｙ LA] 【0115】 図9(b)に示す公開鍵証明書は、一般的な公開鍵証明書の構成であ り、デバイスID、デバイス公開鍵と、発行元の電子署名を含む。例え ばクライアントの公開鍵を格納したクライアントデバイス公開鍵証明書 を受領したサーバは、受領した公開鍵証明書に設定された署名に基づく 検証を実行して、証明書の改竄のないことの確認を行なった後に、格納 されたクライアントの公開鍵を取得する。サーバは、取得したクライア ント公開鍵を適用して、図9(a)に示すコンテンツIDリストに設定 された電子署名、すなわちクライアント秘密鍵を適用して生成された署 名の検証を実行することができる。
(エ) 引用文献4(甲28) 【0080】不揮発メモリ100には、このアクセス制御部60を搭載 したデバイスが、正当なデバイスであることを証明するデバイス証明書 49 101と、アクセス制御部60の公開鍵暗号用秘密鍵であるデバイス秘 密鍵105と、デバイス証明書100を発行した認証機関の公開鍵10 6とが格納されている。
【0105】デバイス証明(図2の101)には、デバイスID(図2 の102)と、デバイス公開鍵(図2の103)と、これらの記述に対 する電子署名(図2の103) (認証機関の秘密鍵により作成さえた)を 含む。デバイス証明の正当性は、その電子署名を認証機関の公開鍵(図 2の106)で正しく復号できるかどうかにより確認される。第三者が デバイス証明を偽造しようとしても、認証機関の秘密鍵を知らないので、
正しい電子署名(図2の103)を作成することができない。
イ デバイス証明書等に関する技術常識について 前記アの記載事項を総合すると,@「デバイス証明書」は、正当なデバ イス(クライアント)であることを証明する電子証明書であり、
「公開鍵証 明書」が、「デバイス証明書」として用いられること(前記ア(ウ)、(エ))、
A電子署名は、公開鍵とプライベート鍵(秘密鍵)の鍵ペアを使い、メッ セージをプライベート鍵(秘密鍵)で暗号化することが「署名」の「作成」 に相当し、その暗号文を公開鍵で復号化することが「署名」の「検証」に 相当すること(前記ア(ア))、B「公開鍵証明書」は、電子署名が、秘密鍵 を保有するものでなければ生成できないという性質を利用して、秘密鍵を 保有する者とその者の公開鍵とを結びつけ、公開鍵が、その公開鍵とペア となる秘密鍵を保有する者のものであること等を証明する手段であるこ と(前記ア(ア))、C「公開鍵証明書」の代表的なフォーマットは、別紙4 のような論理的構造で規定されており、
「署名前証明書」、
「署名アルゴリズ ム」及び「署名値」から構成されていること(前記ア(イ))、D「署名前証 明書」の「基本領域」には、証明書の所有者の公開鍵に関する情報(「主体 者」「主体者公開鍵情報(アルゴリズム、主体者公開鍵) 、
、 」「発行者ユニー 50 ク識別子」「主体者ユニーク識別子」等)が、
、 「拡張領域」には、基本領域 を補足する情報が記載されており、また、「署名値」は、「署名前証明書」 部分について電子署名したものであること(前記ア(ア)、(イ))、D「公開 鍵証明書」を受け取った者は、
「公開鍵証明書」に含まれる「公開鍵」 「署 で 名(署名値)」を「検証」することによって、「公開鍵証明書」に含まれる 情報(「署名前証明書」部分に含まれる情報)が改ざんされておらず、「公 開鍵」が確かに主体者のものであることを確認することができること(前 記ア(ア)、(ウ)、(エ))は,本願優先日当時の技術常識であったことが認 められる。
? 本願発明の「前記クライアント装置の装置ID、発行者ID、前記プライ ベートキーの関数である公開鍵及び前記クライアント装置の不揮発性メモリ から読み出された第1の署名の関数として生成されたデバイス証明書」の意 義について ア 本願発明の特許請求の範囲の請求項1の「前記クライアント装置の装置 ID、発行者ID、前記プライベートキーの関数である公開鍵及び前記ク ライアント装置の不揮発性メモリから読み出された第1の署名の関数と して生成されたデバイス証明書」との記載から、本願発明の「第1の署名」 は、
「クライアント装置の不揮発性メモリから読み出された」ものであるこ とを理解できるが、請求項1には、
「第1の署名」の構成や生成方法等につ いて規定した記載はない。
また、本願明細書には、本願発明の「第1の署名」について定義した記 載はない。
一方で、本願明細書には、
「デバイス証明書」に関し、@「クライアント 106の証明書作成モジュール120は、証明書Ceｒｔを作成する。… 証明書作成モジュール120は、デバイス・プライベートキーを使用し、
乱数R上の署名Sigを算出する。 ( 」 【0015】 、
) 「図3は、一回だけデ 51 バイス証明書を作成する方法の一例のフローチャート300を示している。図3の例では、フローチャート300は、モジュール302で始まり、
ここでデバイス証明書がセキュアデバイスで作成される。…デバイス証明書は公知のものである。( 」【0023】 、A「図6は、セキュアデバイスを )製造する方法の例を示すフローチャート600である。…図6の例において、フローチャート600は、モジュール602でスタートし、ここで装置IDが取得される。装置IDは、シリアルナンバーであっても、或いは装置のための他の何らかの固有な識別子であっても良い。 ( 」 【0053】、
)「図6の例で、フローチャート600は、モジュール604に進み、ここでは装置のために小署名プライベートキー(a small-signature privatekey)として使用する目的で、擬似乱数が供される。…小署名プライベートキーは、これに限定されない例として、楕円カーブプライベートキーや比較的小さなフットプリント(footprint)を持った他の何らかのプライベートキーでも良い。 【0054】、
」 ( )「図6の例で、フローチャート600は、
モジュール606に進み、ここでは共通パラメータを使用してプライベートキーから公開鍵が算出される。 ( 」 【0055】 、
) 「図6の例で、フローチャート600は、モジュール608に進み、ここでは一定の証明書構造(fixed certificate structure)が、証明書を作成するために使用される。
証明書は、例えば楕 円カーブDSAなど の小署名アルゴリズ ム (smallsignature algorithm)を使用して署名される。一実施形態では、該一定の証明書構造は、少なくとも装置ID、発行者名、及びデバイス公開鍵を含むかもしれない。 【0056】、
」 ( )「図6の例で、フローチャート600は、
モジュール610に進み、ここでは｛装置ID、プライベートキー、発行者ID、署名｝が、装置の不非揮発性メモリにプログラミングされる。…一実施形態では、例えば公開鍵など、デバイス証明書の作成(construct)に必要とされる如何なるデータも、要求に応じてプログラミングされた状態 52 で生成されても良い。( 」【0057】 、B「図7は、セキュア証明書の作成 )方法の例を示したフローチャート700である。メリットとして、この方法は、不揮発性でプログラミングされた鍵と必要なソフトウェアを有する装置が、装置認証に使用可能な完全なデバイス証明書を作成することを可能にする。図7の例では、フローチャート700は、モジュール702でスタートし、ここではデバイス証明書のリクエストが、呼出しアプリケーションから受け取られる。 ( 」 【0059】 、
) 「図7の例で、フローチャート700は、モジュール704に進み、ここでは｛装置ID、プライベートキー、発行者ID、署名｝が、不非揮発性メモリから読み込まれる。( 」【0060】 、
)「図7の例で、フローチャート700は、モジュール706に進み、ここでは公開鍵が、プライベートキーと(もしあるならば)共通パラメータとによって算出される。一実施形態では、この演算は、図6を参照して上述した方法のような製造プロセスに使用されたのと同じアルゴリズムを利用する。公開鍵は、セキュリティカーネルで算出されても良い。」(【0061】 、
) 「図7の例で、フローチャート700は、モジュール708に進み、ここではデバイス証明書が、装置ID、発行者ID、公開鍵、
署名、及び共通パラメータから作成される。一実施形態において、セキュリティカーネル・モジュールは、図6を参照して上述した方法のような製造プロセスで使用されおり、該デバイス証明書の構造を認識している。」(【0062】)との記載がある。
これらの記載と図6及び7を総合すると、本願明細書には、本願発明の「デバイス証明書」の実施形態として、
「装置ID、発行者ID、公開鍵、
署名」の証明書構造からなるデバイス証明書が開示されており、このデバイス証明書は、
「公開鍵証明書」であること、 「装置ID、
上記 発行者ID、
公開鍵、署名」のうちの「署名」は、小署名アルゴリズム(small signaturealgorithm)を使用して算出された電子署名であり、本願発明の「第1の署 53 名」に相当することを理解できる。
そして、本願明細書には、上記「署名」の具体的内容についての記載は ないが、
「デバイス証明書は公知のものである。( 」【0023】)との記載及 び前記?イ認定の本願優先日当時の技術常識を踏まえると、本願発明の 「デバイス証明書」は、
「公開鍵証明書」の代表的なフォーマット(別紙4 参照)に基づくものであり、上記「署名」は、
「公開鍵証明書」の「署名値」 (証明書の所有者の公開鍵に関する情報(「主体者」 「主体者公開鍵情報 、
(アルゴリズム、主体者公開鍵)、
」「発行者ユニーク識別子」「主体者ユニ 、
ーク識別子」等)を含む「署名前証明書」部分について電子署名したもの) に相当するものと理解できる。
以上の本願発明の特許請求の範囲の請求項1の記載、本願明細書の上記 記載及び前記?イ認定の本願優先日当時の技術常識を総合すると、本願発 明の「デバイス証明書」の「第1の署名」とは、
「デバイス証明書」に含ま れる「前記プライベートキーの関数である公開鍵」にいう「プライベート キー」を用いて「前記クライアント装置の装置ID」 「発行者ID」及び 、
「公開鍵」を暗号化した「署名値(署名)」を意味するものと解される。
そうすると、本願発明の「前記クライアント装置の装置ID、発行者I D、前記プライベートキーの関数である公開鍵及び前記クライアント装置 の不揮発性メモリから読み出された第1の署名の関数として生成された デバイス証明書」とは、
「前記クライアント装置の装置ID、発行者ID、
前記プライベートキーの関数である公開鍵」及びこれらを前記プライベー トキーを用いて暗号化した署名(署名値)から構成される公開鍵証明書で あると解される。
イ これに対し原告は、本願明細書には、
「第1の署名」について「これらを 暗号化して生成される」との記載はなく、【0062】には、「デバイス証 明書が、装置ID、発行者ID、公開鍵、署名、及び共通パラメータから 54 作成される」こと(「デバイス証明書」に「署名」が含まれること)の記載 があるのみであるから、本願明細書を参酌しても、本願発明の「デバイス 証明書」が、
「クライアント装置の装置ID、発行者ID、プライベートキ ーの関数である公開鍵」 これらを暗号化して生成される と、 「第1の署名」 とを含むものと解釈することはできない旨主張する。
しかしながら、前記アで説示したとおり、本願発明の特許請求の範囲の 請求項1の記載、本願明細書の記載及び前記?イ認定の本願優先日当時の 技術常識を総合すると、本願発明の「デバイス証明書」の「第1の署名」 とは、
「デバイス証明書」に含まれる「前記プライベートキーの関数である 公開鍵」にいう「プライベートキー」を用いて「前記クライアント装置の 装置ID」「発行者ID」及び「公開鍵」を暗号化した「署名値(署名) 、 」 を意味するものと解されるから、原告の上記主張は採用することができな い。
? 相違点2の容易想到性について ア 引用文献1には、
「次に、図8を用いて、CP303からセキュリティデ バイス102に端末アプリケーションをダウンロードするシーケンス、及 び、セキュリティデバイス証明書をダウンロードするシーケンスについて 説明する。 ( 」 【0049】 、
) 「まず、入力手段117から入力されたユーザ 操作に基づいて、情報端末101が無線通信手段115を介し無線通信に よってCP303に端末アプリケーションを要求するメッセージを送信 すると(アプリケーション要求801)、CP303は、情報端末101に 装着されたセキュリティデバイス102に対して、セキュリティデバイス 証明書を要求するメッセージを送信する(セキュリティデバイス証明書要 求802または811) ( 」 【0050】 、
) 「証明書発行要求804を受信し たCP303は、証明書発行要求804に含まれていた電子署名(セキュ リティデバイス証明書要求802に含まれていた乱数に対する電子署名) 55 を同じく証明書発行要求804に含まれていたセキュリティデバイス証 明書を用いて検証して(署名検証805) セキュリティデバイス102が 、
セキュリティデバイス秘密鍵を保持していることを検証し、さらにCP3 03は、そのセキュリティデバイス証明書に含まれるセキュリティデバイ ス公開鍵を用いて新たにセキュリティデバイス証明書を生成して(セキュ リティデバイス証明書生成806)、セキュリティデバイス102に送信 する(セキュリティデバイス証明書807) 」【0054】 。( )との記載があ る。
これらの記載及び図8によれば、引用文献1記載の「証明書発行要求8 04に含まれていたセキュリティデバイス証明書」 (引用発明の「セキュリ ティデバイス証明書」に相当するもの)は、セキュリティデバイス102 がセキュリティデバイス秘密鍵を用いて生成した公開鍵を含む公開鍵証 明書であることを理解できる。
イ 一方で、引用文献1には、
「証明書発行要求804に含まれていたセキュ リティデバイス証明書」の証明書構造に関する記載はない。
しかるところ、
「公開鍵証明書」の代表的なフォーマットは、別紙4のよ うな論理的構造で規定されており、
「署名前証明書」、
「署名アルゴリズム」 及び「署名値」から構成されていることは、本願優先日当時の技術常識で あったことを踏まえると、引用文献1に接した当業者は、引用発明の「セ キュリティデバイス証明書」に上記「公開鍵証明書」の論理的構造を適用 して、セキュリティデバイス102の装置ID、発行者ID、セキュリテ ィデバイス秘密鍵を用いて生成した公開鍵及びこれらを上記セキュリテ ィデバイス秘密鍵を用いて暗号化した署名(署名値)から構成される公開 鍵証明書(相違点2に係る本願発明の構成)とすることを容易に想到する ことができたものと認められる。
これに反する原告の主張は、採用することができない。
56 3 相違点の看過について 原告は、@本願明細書の【0016】には「サーバ102における証明書検 証モジュ ール 112 は、信頼 でき る証明 書 チェー ン (trusted certificate chain)を用いて、証明書Ceｒｔを認証し」との記載があること、証明書チェ ーンは、認証パスとも呼ばれ、クライアント、サーバなどの証明書から、中間 認証局の証明書、ルート認証局の証明書までの連なりであり、チェーン内の各 証明書が次の証明書よって署名されることでセキュリティを確保するように構 成されていることは技術常識であることからすると、本願発明の「前記証明書 検証モジュールは前記デバイス証明書と第2の署名とを認証し」とは、
「デバイ ス証明書」は「証明書チェーン」を用いて認証され、
「第2の署名」は「デバイ ス証明書」に含まれる公開鍵によって認証されることを意味するものと解され る、A引用文献1には、引用発明における「セキュリティデバイス証明書を用 いて検証する」との構成が、このような認証を意味することを示した記載はな いから、引用発明は、本願発明の「前記証明書検証モジュールは前記デバイス 証明書と第2の署名とを認証し」との構成を備えるものでない点で本願発明と 相違するが、本件審決は、この点を相違点として認定していないから、本件審 決には、かかる相違点を看過した誤りがある旨主張する。
? 本願発明の特許請求の範囲の請求項1の記載から、本願発明の「前記証明 書検証モジュールは前記デバイス証明書と第2の署名とを認証し」との構成 は、
「サーバ」が備える「前記証明書検証モジュール」が「前記デバイス証明 書」と「第2の署名」を認証することを規定したものと理解できるが、請求 項1には、上記構成中の「認証」の認証方法について規定した記載はない。
また、本願明細書には、上記構成中の「認証」を特定の認証方法に限定す ることを述べた記載はない。
次に、本願明細書には、「サーバ102Rは、インターフェース118で、
乱数R、任意データ、証明書Ceｒｔ、及び署名Sigを受けとる。サーバ 57 102における証明書検証モジュール112は、信頼できる証明書チェーン (trusted certificate chain)を用いて、証明書Ceｒｔを認証し、証明書C eｒｔを用いて署名Sigを認証し、更に乱数Rが、元々サーバ102によ ってクライアント106に送られた乱数Rと同じであるか否かを検証する。」 (【0016】)との記載があり、「証明書チェーン(trusted certificate chain)を用いて、証明書Ceｒｔを認証し、証明書Ceｒｔを用いて署名S igを認証」した実施形態が開示されているが、一方で、
「当業者であれば前 述した実施例と実施形態は、代表的なものであり、本発明の範囲を限定する ものでないことが理解されるであろう。当業者が明細書を考慮し、図面を検 討したときに自明な置き換え、増強、均等物やそれらへの改良が、本発明の 要旨と範囲に含まれることを意図している。 ( 」 【0066】)との記載に照ら すと、本願発明の「前記証明書検証モジュールは前記デバイス証明書と第2 の署名とを認証し」との構成にいう「認証」は、
【0016】記載の「証明書 チェーン」を用いた認証方法に限定すべきものと解することはできない。
これに反する原告の主張は、採用することができない。
? 引用文献1の【0054】には「証明書発行要求804を受信したCP3 03は、証明書発行要求804に含まれていた電子署名(セキュリティデバ イス証明書要求802に含まれていた乱数に対する電子署名)を同じく証明 書発行要求804に含まれていたセキュリティデバイス証明書を用いて検証 して(署名検証805) セキュリティデバイス102がセキュリティデバイ 、
ス秘密鍵を保持していることを検証し」との記載がある。この記載及び図8 から、引用発明において、「CP303」は、「乱数に対する電子署名」をセ キュリティデバイス102からの証明書発行要求804に含まれていた「セ キュリティデバイス証明書」を用いて検証する構成を有することが理解でき る。そして、引用発明の「乱数に対する電子署名」が本願発明の「第2の署 名」に対応すること(前記1?イ)からすると、引用発明の上記構成は、本 58 願発明のサーバが備える「前記証明書検証モジュールは…第2の署名とを認 証する」構成に相当する。
次に、前記2?イのとおり、「公開鍵証明書」を受け取った者は、「公開鍵 証明書」に含まれる「公開鍵」 「署名 で (署名値) を検証することによって、
」 「公開鍵証明書」に含まれる情報(「署名前証明書」部分に含まれる情報)が 改ざんされておらず、
「公開鍵」が確かに主体者のものであることを確認する ことができることは、本願優先日当時の技術常識であること、引用発明の「セ キュリティデバイス証明書」は、「公開鍵証明書」であること(前記2?ア) からすると、引用発明の「セキュリティデバイス証明書」を用いて同証明書 に含まれる署名を検証することによって同証明書に含まれる情報が改ざんさ れていないことを確認することは自明である。
そうすると、引用発明の「CP303」においても、
「セキュリティデバイ ス証明書」を認証する構成を備えていると認められ、上記構成は、本願発明 のサーバが備える「前記証明書検証モジュールは前記デバイス証明書…を認 証し」との構成に相当する。
以上によれば、引用発明は、本願発明の「前記証明書検証モジュールは前 記デバイス証明書と第2の署名とを認証し」との構成を備えるものと認めら れるから、上記構成が相違点であることを理由に本件審決における相違点の 看過をいう原告の主張は、採用することができない。
? その他原告は、本件審決における本願発明と引用発明の一致点の認定の誤 りないし相違点の看過について縷々主張するが、いずれも本願発明の発明特 定事項との関係が明確とはいえず、本件審決の結論に影響を及ぼすものとい えないから、理由がない。
結論
以上のとおり、原告主張の取消事由は理由がなく、本件審決にこれを取り消 すべき違法は認められない。
59 したがって、原告の請求は棄却されるべきものであるから、主文のとおり判決する。
裁判長裁判官 大鷹一郎
裁判官 小川卓逸
裁判官 小林康彦
すごい知財EXPO'22