【事件の表示】
　特願２００４−１１８７７４「証明書発行サービス方法、証明書発行サービス装置及び証明書発行サービスプログラム」拒絶査定不服審判事件〔平成１７年１０月２７日出願公開、特開２００５−３０３７７９〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯及び本願発明
　本願は、平成１６年４月１４日の出願であって、平成１６年１２月１７日付けで審査請求がなされ、平成１９年５月２５日付けで審査官により拒絶理由が通知されたことに対して、同年８月３日付けで意見書が提出されるとともに、同日付けで手続補正がなされたが、同年８月２９日付けで拒絶査定がなされ、それに対して同年１０月１０日付けで審判請求がなされるとともに、同年１１月７日付けで手続補正がなされ、平成２０年１月１５日付けで審査官による前置報告がなされ、平成２１年８月２５日付けで当審により審尋がなされ、それに対して同年１０月２３日付けで回答書が提出され、平成２２年１月１５日付けで当審により平成１９年１１月７日付けの手続補正が却下されるとともに、同日付けで拒絶理由が通知されたことに対して、同年３月２５日付けで意見書が提出されたものであって、
　その請求項１に係る発明は、平成１９年８月３日付けの手続補正によって補正された特許請求の範囲、明細書及び図面の記載からみて、特許請求の範囲の請求項１に記載された次のとおりのものと認める。（以下、これを「本願発明」という。）
　
「利用者が一つの認証局を信頼することで相互に認証が可能となるシステムで用いられる認証局として機能して、利用者の証明書発行申し込みに対応した証明書を作成して発行する、入手手段と取得手段と実行手段とを備える証明書発行サービス装置が実行する証明書発行サービス方法であって、
　上記入手手段が、証明書の発行に必要となる一つの証明書発行依頼情報を入手し、
　上記取得手段が、上記入手手段の入手した一つの証明書発行依頼情報に対応して、発行者秘密鍵を記憶する記憶手段から、複数の異なる発行者秘密鍵を取得し、
　上記実行手段が、上記入手手段の入手した一つの証明書発行依頼情報に基づいて、上記取得手段の取得した発行者秘密鍵の数に応じた複数の証明書を作成し、それらの証明書のそれぞれに、上記取得手段の取得した発行者秘密鍵を用いて同一の証明書発行主体としての署名を付与することを、
　特徴とする証明書発行サービス方法。」
　
２．引用刊行物に記載の発明
　これに対して、当審において、平成２２年１月１５日付けで通知した拒絶理由（以下、これを「当審拒絶理由」という）に引用した本願の出願前の平成１２年４月２１日付けで公開された特開２０００−１１５１６０号公報（以下、これを「引用刊行物１」という）には、対応する図面とともに次の事項が記載されている。
　
Ａ．「【請求項１】公開鍵証明証の発行申請用情報を申請者より受領する申請受領手段と、
受領した申請用情報をもとに公開鍵証明証用に電子署名を付加して前記申請者に返信する認証手段とを有し、
前記認証手段は、異なる複数の秘密鍵を用いて段階的に前記電子署名を生成するように構成されていることを特徴とする公開鍵証明証発行システム。」
　
Ｂ．「【請求項２】それぞれ異なる秘密鍵を管理し、自装置の秘密鍵を用いて電子署名を生成する複数の認証装置を含み、
前記複数の認証装置の少なくとも一つは、公開鍵証明証の発行申請用情報を申請者より受領する申請受領手段、自装置の電子署名および他の認証装置の電子署名を用いて公開鍵証明証を生成する手段、生成した公開鍵証明証を申請者に返信する手段の少なくともいずれかを有することを特徴とする、公開鍵証明証発行システム。
【請求項３】前記複数の認証装置は、第１電子署名を生成する第１装置と第２電子署名を生成して前記第１装置宛に送出する第２装置であり、
第１装置は、公開鍵証明証の生成に用いる基礎情報をハッシュ値に変換するとともにこのハッシュ値を第２装置宛てに送出する手段と、第２装置より受領した第２電子署名、前記基礎情報および前記第１電子署名に基づいて公開鍵証明証を生成する電子証明証生成手段とを有し、
第２装置が、前記第１装置より受領した前記ハッシュ値に基づいて前記第２電子署名を生成し、この第２電子署名を第１装置に送出する手段を有することを特徴とする、請求項２記載の公開鍵証明証発行システム。」
　
Ｃ．「【請求項５】所定の申請情報の受領を契機に自装置の秘密鍵により第１電子署名を生成する手段と、
前記申請情報をもとに公開鍵証明証生成に用いる基礎情報を生成するとともに、この基礎情報をハッシュ値に変換し、このハッシュ値を相互通信可能に接続された相手側装置宛てに送出する手段と、
前記相手側装置より相手側装置の秘密鍵で生成された第２電子署名を受領する手段と、
前記基礎情報、前記第１電子署名および前記第２電子署名に基づいて公開鍵証明証を生成する手段とを有する、公開鍵証明証生成装置。」
　
Ｄ．「【請求項７】所定の申請用情報を申請者より受領し、受領した申請用情報をもとに公開鍵証明証用の基礎情報を生成する過程と、
それぞれ異なる複数の秘密鍵を用いて複数の電子署名を生成する過程と、
前記基礎情報および複数の電子署名に基づいて公開鍵証明証を生成する過程とを含み、生成した公開鍵証明証を前記申請者に返送することを特徴とする、
公開鍵証明証発行方法。」
　
Ｅ．「【００１１】
【発明の実施の形態】以下、本発明の実施の形態を図面を参照して説明する。図１は、本発明の公開鍵証明証発行システムを適用した認証局（「ＣＡ」）の構成例である。
【００１２】ＣＡ１は、インターネット等の外部ネットワークを通じて申請者用端末および利用者端末と接続されており、ＣＡ内部は、第１装置と第２装置とが専用線Ｌを通じて双方向通信可能に接続されている。申請者用端末は、公開鍵証明証の発行申請を行う者（以下、申請者）が操作する通信端末であり、利用者端末は、ＣＡ１が発行した公開鍵証明証の検証を行うものである。以下、第１装置をＣＡサーバＡ１０、第２装置をＣＡサーバＢ２０と称する。ＣＡサーバＡ１０は署名用秘密鍵ＳＫ１、ＣＡサーバＢ２０は署名用秘密鍵ＳＫ２をそれぞれ有している。
【００１３】図２は、ＣＡ１における動作を説明するシーケンスチャートである。公開鍵証明証の発行申請を行う者（以下、申請者）から外部ネットワークを介して証明証発行申請を受信すると、ＣＡサーバＡ１０は、公開鍵証明証の発行に用いる基礎情報、例えば、利用者公開鍵や証明証本文などからなる証明証用データＤｃを生成する（ＣＡ１１）。
【００１４】次に、証明証用データＤｃのハッシュ値Ｄｈを求め、このハッシュ値ＤｈをＣＡサーバＢ２０宛てに送信する。ＣＡサーバＢ２０は、ＣＡサーバＡ１０よりハッシュ値Ｄｈを受信すると、このハッシュ値Ｄｈを署名用秘密鍵ＳＫ２で暗号化し、電子署名Ｓｉｇ２を生成する（ＣＡ２１）。その後、この電子署名Ｓｉｇ２をＣＡサーバＡ１０宛てに送信する。
【００１５】ＣＡサーバＡ１０は、証明用データＤｃのハッシュ値Ｄｈを、署名用秘密鍵ＳＫ１で暗号化し、電子署名Ｓｉｇ１を生成する（ＣＡ１２）。また、ＣＡサーバＢ２０より電子署名Ｓｉｇ２を受信したときに、証明証用データＤｃ、電子署名Ｓｉｇ１、Ｓｉｇ２を合わせて、公開鍵証明証を生成し（ＣＡ１３）、申請者への公開鍵証明証の発行を行う。この公開鍵証明証の内容の一例を図３に示す。」
　
Ｆ．「【００２２】なお、本実施形態では、二つのＣＡサーバを用いて秘密鍵を管理する場合の例であるが、互いに異なる複数のＣＡの秘密鍵が異なる場所で管理されて同一人が同時に見れないようにすれば、本発明を実施することができるので、これらの秘密鍵の数および管理形態は任意であって良い。」
　
　同じく当審拒絶理由に引用した、平成１４年７月２６日付けで公開された特開２００２−２０７４２６号公報（以下、これを「引用刊行物２」という）には、周知技術として次の事項が記載されている。
Ｇ．「【００１０】公開鍵証明書について図１を用いて説明する。公開鍵証明書は、公開鍵暗号方式における認証局（ＣＡ：Certification AuthorityまたはＩＡ：Issuing Authority）が発行する証明書であり、ユーザが自己のＩＤ、公開鍵等を認証局に提出することにより、認証局側が認証局のＩＤや有効期限等の情報を付加し、さらに認証局による署名を付加して作成される証明書」
　
Ｈ．「【００１２】電子署名は、証明書のバージョン番号、認証局が証明書利用者に対し割り付ける証明書の通し番号、電子署名に用いたアルゴリズムおよびパラメータ、認証局の名前、証明書の有効期限、証明書利用者の名前並びに証明書利用者の公開鍵全体に対し生成される電子署名であり、例えばハッシュ関数を適用してハッシュ値を生成し、そのハッシュ値に対して認証局の秘密鍵を用いて生成したデータである」
　
ア．上記Ａで引用した記載及び上記Ｄで引用した記載から、引用刊行物１には、“「公開鍵証明証発行システム」によって実行される「公開鍵証明証発行方法」”が記載されていることが読み取れる。
　
イ．上記Ｅで引用した「公開鍵証明証発行システムを適用した認証局（「ＣＡ」）の構成例」及び「ＣＡ１は、インターネット等の外部ネットワークを通じて申請者用端末および利用者端末と接続されており、ＣＡ内部は、第１装置と第２装置とが専用線Ｌを通じて双方向通信可能に接続されている。申請者用端末は、公開鍵証明証の発行申請を行う者（以下、申請者）が操作する通信端末であり、利用者端末は、ＣＡ１が発行した公開鍵証明証の検証を行うものである」から、引用刊行物１には、“「認証局ＣＡ１」に「公開鍵証明証発行システム」を適用した点”即ち“「認証局ＣＡ１」が「公開鍵証明書発行システム」として機能している点”が読み取れる。
　
ウ．上記Ａで引用した「公開鍵証明証の発行申請用情報を申請者より受領する申請受領手段」、「認証手段は、異なる複数の秘密鍵を用いて段階的に前記電子署名を生成するように構成されていることを特徴とする公開鍵証明証発行システム」から、引用刊行物１には、“「公開鍵証明書発行システム」は公開鍵証明書の発行申請用情報を受領する「申請受領手段」と異なる複数の秘密鍵を用いて段階的に電子署名を生成する「認証手段」とから構成されている点”が読み取れる。
　
エ．上記ウで指摘の「認証手段」について、上記Ｂで引用した「複数の認証装置の少なくとも一つは、公開鍵証明証の発行申請用情報を申請者より受領する申請受領手段、自装置の電子署名および他の認証装置の電子署名を用いて公開鍵証明証を生成する手段、生成した公開鍵証明証を申請者に返信する手段の少なくともいずれかを有する」と、「複数の認証装置は、第１電子署名を生成する第１装置と第２電子署名を生成して前記第１装置宛に送出する第２装置であり」及び上記Ｅで引用した「ＣＡ内部は、第１装置と第２装置とが専用線Ｌを通じて双方向通信可能に接続されている」並びに「第１装置をＣＡサーバＡ１０、第２装置をＣＡサーバＢ２０と称する。ＣＡサーバＡ１０は署名用秘密鍵ＳＫ１、ＣＡサーバＢ２０は署名用秘密鍵ＳＫ２をそれぞれ有している」から、
　引用刊行物１には、“「認証手段」が、「第１電子署名を生成する第１装置」と、「第２電子署名を生成する第２装置」とから構成される点”及び“「認証手段」を構成する「第１装置」、「第２装置」が、「専用線Ｌ」で接続されている点”が読み取れる。
　
オ．上記Ｂで引用した「第１装置は、公開鍵証明証の生成に用いる基礎情報をハッシュ値に変換するとともにこのハッシュ値を第２装置宛てに送出する手段と、第２装置より受領した第２電子署名、前記基礎情報および前記第１電子署名に基づいて公開鍵証明証を生成する電子証明証生成手段とを有し、第２装置が、前記第１装置より受領した前記ハッシュ値に基づいて前記第２電子署名を生成し、この第２電子署名を第１装置に送出する手段を有する」及び上記Ｅで引用した「ＣＡサーバＡ１０は、公開鍵証明証の発行に用いる基礎情報、例えば、利用者公開鍵や証明証本文などからなる証明証用データＤｃを生成する」と、「証明証用データＤｃのハッシュ値Ｄｈを求め、このハッシュ値ＤｈをＣＡサーバＢ２０宛てに送信する。ＣＡサーバＢ２０は、ＣＡサーバＡ１０よりハッシュ値Ｄｈを受信すると、このハッシュ値Ｄｈを署名用秘密鍵ＳＫ２で暗号化し、電子署名Ｓｉｇ２を生成する（ＣＡ２１）。その後、この電子署名Ｓｉｇ２をＣＡサーバＡ１０宛てに送信する」と、「ＣＡサーバＡ１０は、証明用データＤｃのハッシュ値Ｄｈを、署名用秘密鍵ＳＫ１で暗号化し、電子署名Ｓｉｇ１を生成する」と、「証明証用データＤｃ、電子署名Ｓｉｇ１、Ｓｉｇ２を合わせて、公開鍵証明証を生成」から、
　引用刊行物１には、“「認証手段」を構成する「第１装置」が「公開鍵証明証の生成に用いる基礎情報」を「ハッシュ値」に変換し、該「ハッシュ値」を「第２装置」に送信すると共に、該「ハッシュ値」に基づいて「第１電子署名」を生成する点”及び“「認証手段」を構成する「第２装置」が該「ハッシュ値」を受信し、受信した該「ハッシュ値」に基づいて「第２電子署名」を生成し、該「第２電子署名」を該「第１装置」に送出する点”並びに“「基礎情報」、「第１電子署名」、「第２電子署名」を用いて「公開鍵証明証」を生成する点”が読み取れる。また、“該「ハッシュ値」を「第２装置」に送信すると共に、該「ハッシュ値」に基づいて「第１電子署名」を生成”していることから、引用刊行物１においては、「第１装置」用の電子署名用及び「第２装置」用の電子署名用に同じ「ハッシュ値」を複数生成しているか、あるいは、生成した「ハッシュ値」のコピーを生成しているものと解される。
　
カ．上記Ｃに引用した「申請情報をもとに公開鍵証明証生成に用いる基礎情報を生成するとともに、この基礎情報をハッシュ値に変換」及び上記Ｅに引用した「公開鍵証明証の発行申請を行う者（以下、申請者）から外部ネットワークを介して証明証発行申請を受信すると、ＣＡサーバＡ１０は、公開鍵証明証の発行に用いる基礎情報、例えば、利用者公開鍵や証明証本文などからなる証明証用データＤｃを生成する」から、
　引用刊行物１には、“公開鍵証明証生成に用いる「基礎情報」は、「申請情報」をもとに生成される点”が読み取れる。
　
　以上ア〜カで指摘の事項から、引用刊行物１には、次の発明（以下、「引用発明」という）が記載されているものと認める。
　
　認証局として機能し、申請者の公開鍵証明証発行申請をもとに公開鍵証明証を生成して申請者に返送する申請受領手段と認証手段とを有する公開鍵証明証発行システムが行う公開鍵証明証発行方法であって、
　前記申請受領手段が、公開鍵証明証の発行申請用情報を受領し、
　前記認証手段が、受領した発行申請用情報をもとに公開証明証用に電子署名を、異なる複数の秘密鍵を用いて段階的に生成し、
　前記段階的に生成することは、前記認証手段を構成する第１装置が、受領した発行申請用情報をもとに公開鍵証明証生成に用いる基礎情報を生成し、前記基礎情報のハッシュ値を生成すると共に、前記ハッシュ値を、前記第１装置に接続され、前記認証手段を構成する第２装置に送信し、前記第２装置は、前記ハッシュ値を用いて第２電子署名を生成し、
　前記第２電子署名を前記第１装置に送信し、
　前記第１装置は、前記ハッシュ値を用いて第１電子署名を生成し、
　前記第２装置から受信した前記第２電子署名、前記第１電子署名及び基礎情報から、公開鍵証明証を作成することを、
　特徴とする公開鍵証明証発行方法
　
３．本願発明の引用発明との対比
　本願発明と引用発明とを対比すると、
　引用発明における「公開鍵証明書発行システム」は「認証局として機能」しているので、
　引用発明における「公開鍵証明書発行システム」が、本願発明における「証明書発行サービス装置」に相当し、
　引用発明における「申請受領手段」は、“申請者からの公開鍵証明書発行申請を受け付けている”ことから、
　引用発明における「申請受領手段」が、本願発明における「入手手段」に相当し、ここで、引用発明においても、「申請者」からの「公開鍵証明証発行申請」は一つであることは明らかである。
　引用発明においては、“受領した発行申請用情報をもとに公開鍵証明証生成に用いる基礎情報を生成”し、“基礎情報のハッシュ値から第１電子署名、第２電子署名を生成”し、“基礎情報、前第１電子署名及び第２電子署名から、公開鍵証明証を作成”しているから、
　引用発明における「基礎情報」も、本願発明における「証明書を作成し」の「証明書」も、「電子署名」を付加される「署名対象」である点で共通し、
　引用発明における「認証手段」は、“受領した発行申請用情報をもとに公開証明証用に電子署名を、異なる複数の秘密鍵を用いて生成”しており、
　本願発明も、“「入手手段」が複数の異なる発行者秘密鍵を取得し、「実行手段」が、該秘密鍵を用いて署名を行っている”ので、
　引用発明における「認証手段」も、本願発明における「入手手段」と「実行手段」の組も、“異なる複数の秘密鍵を用いて署名を行う署名手段”であるという点で共通する。
　また、引用発明も、本願発明も、“異なる複数の秘密鍵を用いて、複数の署名を生成している”点では共通している。
　そして、引用発明においては、「申請者の公開鍵証明証発行申請」を受け付ける「認証局」は１つであるから、引用発明においても“複数の署名は、同一の公開鍵証明証発行システムが行っている”ことは明らかである。
　
　以上に考察した点から、本願発明と引用発明との一致点及び相違点は以下のとおりである。
・一致点
　一つの認証局として機能して、利用者の証明書発行申し込みに対応した署名対象を作成する、入手手段と署名手段とを備える証明書発行サービス装置が実行する証明書発行サービスであって、
　上記入手手段が、証明書の発行に必要となる一つの証明書発行依頼情報を入手し、
　上記署名手段が、上記入手手段の入手した一つの証明書発行依頼情報に対応して、複数の異なる発行者秘密鍵を用いて、上記入手手段の入手した一つの証明書発行依頼情報に基づいて、署名対象を作成し、該署名対象に、上記複数の異なる発行者秘密鍵を用いて同一の証明書発行主体として署名を付与することを、
　特徴とする証明書発行サービス方法
　
・相違点１
　署名手段が、
　本願発明においては、一つの証明書発行依頼情報に対応して、発行者秘密鍵を記憶する記憶手段から、複数の異なる発行者秘密鍵を取得する取得手段と、該証明書発行依頼情報に基づいて、複数の異なる発行者秘密鍵を用いて署名を行う実行手段から構成されているのに対して、
　引用発明においては、署名手段に対応する認証手段が、公開鍵証明書発行申請情報に基づいて基礎情報を生成し、第１電子署名を生成し、第２装置が生成する第２電子署名、第１電子署名及び基礎情報から公開鍵証明証を生成する第１装置と、該第１装置に接続され、第２電子署名を生成する第２装置とから構成されている点、
　
・相違点２
　署名対象への署名について
　本願発明では、一つの証明書発行依頼に基づいて、複数の証明書を生成し、該証明書に署名を行っているのに対して、
　引用発明では、一つの公開鍵証明証発行申請情報に基づいて基礎情報を生成し、該基礎情報から複数のハッシュ情報を生成して、該複数のハッシュ情報を用いて複数の電子署名を生成し、該基礎情報と該複数の電子署名とから、公開鍵証明証を作成している点、
　
・相違点３
　複数の異なる発行者秘密鍵を、
　本願発明においては、発行者記憶手段を記憶する記憶手段が保持しているのに対して、
　引用発明においては、第１装置、第２装置がそれぞれ異なる鍵を保持している点、
　
４．当審の判断
　そこで、上記相違点について検討する。
　
４−１．相違点１及び相違点３について
　上記Ｆで引用した引用刊行物１の記載内容に「秘密鍵の数および管理形態は任意であって良い」とあることから、引用発明においても、第１装置、第２装置が、それぞれ、異なる秘密鍵を保持することに替えて、記憶手段で管理するよう構成すること、また、第１電子署名と第２電子署名を、それぞれ、第１装置、第２装置で生成することに替えて、第１装置、第２装置の何れか一方のみで行い得るようにすることは、当業者が適宜なし得る事項である。
　よって、相違点１格別のものではない。
　
４−２．相違点２について
　上記３でも指摘したように、本願発明における「証明書」も、引用発明における「基礎情報」も、ともに、「電子署名」を付加される対象である。
　そして、「電子署名」は、上記Ｇ及びＨで引用した、引用刊行物２に記載された周知技術（以下、これを「周知技術１」という）にあるように、“署名を付加する対象の情報のハッシュ値”に対して、“認証局の秘密鍵を用いて生成”されるものである。
　したがって、相違点２を言い換えると、
　電子署名の生成に際して、
　本願発明においては、署名対象となる同一情報を複数生成し、該複数の情報のそれぞれから、異なる鍵を用いて電子署名を生成するものであるのに対して、
　引用発明においては、署名対象となる情報を生成し、該情報のハッシュ値を複数生成し、該複数のハッシュ値のそれぞれから、異なる鍵を用いて電子署名を生成するものである点、
　となる。
　ここで、原審が拒絶の理由に引用した、２００３年１月２３日付けで公開された国際公開第０３／００７２０３号に、
Ｉ．「To overcome the threats associated with broken cryptographic schemes and key compromise, a service consisting of a (distributed) network of servers S１,..., SＳ create certificates that represent statements of the same type. For signing their statements, said servers may use different keys or signature schemes. If one of the keys or schemes become compromised, the certificates signed with the other keys or schemes remain authentic and can be used as trusted information to restore (renew) certificates created with the compromised scheme. 」（国際公開第０３／００７２０３号の国際公開公報第３頁第２７−３３行より引用）
（暗号機構の解読、鍵の危殆化に関連した脅威を克服するために、複数のサーバＳ１，・・・，ＳＳの（分散された）ネットワークからなるサービスは、同一タイプの声明を表す複数の証明書を生成する。これらの声明に署名するため、前記複数のサーバは、異なる鍵、或いは、異なる署名スキームを用い得る。もし、鍵、或いは、機構の一つが危殆化しても、他の鍵、或いは、機構を用いて署名された証明書が本物として残り、危殆化した機構によって生成された証明書を再格納（更新）するために信頼されている情報として用いることが出来る。＜当審にて訳出＞）、
　と記載されてもいるように、同一の署名の付加対象に対して、複数の暗号鍵を用いて署名を行って複数の証明書を生成すること自体は、本願出願時点で当業者に周知の技術事項である（以下、これを「周知技術２」という）。
　引用発明においては、署名付加対象である基礎情報と、複数の署名とから、公開鍵証明証を発行するために、ハッシュ値の段階で複製を生成しているが、周知技術２を考慮すれば、引用発明の構成であれば、一つの基礎情報から、複数の異なる秘密鍵による公開鍵証明証の発行を行うことに対応して、ハッシュ値の段階で複製を生成することに替えて、基礎情報を生成する段階で、該基礎情報の複製を生成し、該複数の基礎情報からハッシュ値を生成し（生成されたハッシュ値の値自体は同一）、生成されたそれぞれのハッシュ値を異なる秘密鍵で暗号化して署名を生成し、該生成した署名と、基礎情報を組にして、複数の公開鍵証明書を生成することは、当業者が適宜なし得る事項である。
　よって、相違点２は格別のものではない。
　
　上記で検討したごとく、相違点１〜３はいずれも格別のものではなく、そして、本願発明の構成によってもたらされる効果も、当業者であれば容易に予測できる程度のものであって、格別なものとは認められない。
　
　なお、審判請求人は、平成２２年３月２５日付けの意見書において、本願発明と引用刊行物との差異について、
「引用発明が解決しようとする課題は、引用文献１の段落【０００３】にもあるとおり、ＣＡ内部の者を通じての署名用秘密鍵の漏洩などの不正行為による証明書の偽造を防ぐことにあります。そして、当該課題を解決するために、引用発明では、複数のＣＡを導入し、一方のＣＡの秘密鍵が内部不正により漏洩しても、他方の秘密鍵が漏洩していなければ証明書の安全性を保つことができる構成としています。すなわち、引用発明では、利用する複数のＣＡの秘密鍵ＳＫ１、ＳＫ２は、異なる主体（ＣＡサーバＡ、ＣＡサーバＢ）が独立して管理し、ＣＡサーバＡ、ＣＡサーバＢが、それぞれ秘密鍵ＳＫ１、ＳＫ２により作成した署名Ｓｉｇ１、Ｓｉｇ２を、ＣＡサーバＡが一つの証明書に付与することにより、当該証明書の検証の際、署名Ｓｉｇ１、Ｓｉｇ２の両方の検証を行わせることによって、当該証明書の安全性を保つものです。
　一方、本願請求項１に係る発明が解決しようとする課題は、本願明細書の段落【０００６】にもあるとおり、発行者秘密鍵に危殆化の危機が発生した場合に、利用者の証明書を全て再発行する処理に関する負担を軽減するものであり、そのために、証明書発行サービス装置の実行手段が、入手手段の入手した一つの証明書発行依頼情報に基づいて、取得手段の取得した「発行者秘密鍵の数に応じた複数の」証明書を作成し、「それらの」証明書「のそれぞれ」に、上記取得手段の取得した発行者秘密鍵を用いて同一の証明書発行主体としての署名を付与する構成を採っています。
　したがって、本願請求項１に係る発明と引用発明との構成上の相違点は、解決すべき課題が異なっていることに起因して、生じているものです。
　ここで、本願請求項１に係る発明の構成を得るために、引用発明に引用文献２に記載されているような周知事項を適用し、利用者公開鍵や証明証本文からなる証明証用データＤｃ及び電子署名Ｓｉｇ１、利用者公開鍵や証明証本文からなる証明証用データＤｃ及び電子署名Ｓｉｇ２を、それぞれ一つの公開鍵証明書とし、これらの証明書発行主体がいずれもＣＡサーバＡとした場合、当然ながら、一つの公開鍵証明書に含まれる署名は、Ｓｉｇ１、又は、Ｓｉｇ２の一方となり、一つの公開鍵証明書を検証する際、検証される署名は、Ｓｉｇ１、又は、Ｓｉｇ２の一方だけとなるため、引用発明が元々解決しようとする課題が解決できないものとなります。
　つまり、引用発明に引用文献２に記載されているような周知事項を適用することは、引用発明の技術的特徴を失わせ、かつ、引用発明の本来の効果を喪失させるものですので、特別な動機付けもなく、引用発明に引用文献２に記載されているような周知事項を適用し、上記相違点１及び相違点２に関する本願請求項１に係る発明の構成を得ることは、当業者であっても容易ではないと考えます。」
　と主張しているので、当該主張について検討する。
　本願出願前の平成１０年１１月１７日付けで公開された特表平１０−５１２０７４号公報（出願人；インタートラスト　テクノロジーズ　コーポレーション）に、
Ｊ．「たとえある与えられた証明鍵が侵犯されても、１つ以上の「バックアップ」証明書を用いることができるように、異なる複数の鍵に基づく１つよりも多くの証明書を、サイトおよび／またはユーザに対して発行することができる。もしある証明鍵が侵犯されれば、VDE管理者は、このような鍵を用いて発行された証明書に基づいて認証するのを拒否し、さらに続くVDE加入者とのインタラクションにおいて、侵犯された鍵のすべての使用と、その鍵に関わるあらゆる証明書とを無効にする「バックアップ」証明書を用いて認証した後、信号を送ることができる。新しい１つ以上の「バックアップ」証明書および鍵は、このような侵犯の後、認証されたサイト／ユーザに対して作成され、送られうる。
  もし多数の証明書を利用可能であるのなら、それらの証明書中のいくつかをバックアップとしてとっておくことができる。あるいは、またはそれに加えて、一群の証明書の中からある証明書をある与えられた認証で（例えば、RNG 542を用いて）選択することによって、侵犯された証明鍵に関連する証明書が用いられる可能性を低くすることができる。さらに、ある与えられた認証で１つよりも多くの証明書を用いてもよい。」（第４７４頁第２５行〜第４７５頁第１２行）
　と記載されていて、“一つの「証明鍵が侵犯され」た場合の対策として、「１つ以上の「バックアップ」証明書を用いることができるように、異なる複数の鍵に基づく１つよりも多くの証明書を、サイトおよび／またはユーザに対して発行する」”ことは、本願出願時点で、当業者にとっては周知の技術事項であったことは明らかである（以下、これを「周知技術３」という）。また、上記Ｊで引用いた記載内容に、「さらに、ある与えられた認証で１つよりも多くの証明書を用いてもよい」とあるように、“「異なる複数の鍵に基づく１つよりも多くの証明書」を作成する環境において、鍵の危殆化に対する対応として、ある鍵が危殆化している場合に、他の鍵を用いた証明書を用いることで対応する手法（本願発明のおける対策に相当）と、ある認証において、複数の証明書、即ち、複数の署名を用いることで、何れかの証明書生成に用いた鍵、即ち、署名生成に用いた鍵が危殆化していても、同時に用いる他の証明書、即ち、他の署名にとって、該認証を成立させる手法（引用発明における対策に相当）”が実現可能であることも、当業者にとって周知の技術事項である（以下、これを「周知技術４」という）。
　本願発明も、引用発明も“署名用の秘密鍵の危殆化に対する対策”という点で課題は共通しており、
　引用発明は、複数の「秘密鍵」を用いて、複数の署名を施すことで、署名に用いた「秘密鍵」の一つが危殆化しても、該「公開鍵証明証」の安全性を担保するものであるが、
　これは、上記周知技術４で指摘した、一つの認証を複数の証明書を用いて行うことと同義であり、上記周知技術４で指摘したように、“異なる複数の鍵に基づく１つよりも多くの証明書」を発行する環境”においては“、一つの認証を複数の証明書を用いて行うこと”も、“ある鍵が危殆化している場合に、他の鍵を用いた証明書を用いること”も、ともに、実現可能であることが周知である以上、
　引用発明において、最終的に、複数の「公開鍵証明証」を生成するために、複数の電子署名を生成する過程において、「基礎情報」を生成したのち、該「基礎情報」の「ハッシュ値」に変換して、該「ハッシュ値」を複数生成することに替えて、
　該「基礎情報」を生成する時点で、該「基礎情報」を複数生成することは、当業者が適宜なし得る事項であり、
　上述したように、本願発明における手法も、引用発明における手法も、共に同一の環境から導き出されることは明らかであるから、
引用発明において、最終的に、複数の「公開鍵証明証」を生成するために、複数の電子署名を生成する過程において、「基礎情報」を生成したのち、該「基礎情報」の「ハッシュ値」に変換して、該「ハッシュ値」を複数生成することに替えて、
　該「基礎情報」を生成する時点で、該「基礎情報」を複数生成するという構成を構築することに、阻害要因は存在しない。
　以上のとおりであるから、本願発明の課題と、引用発明の課題とが、上記で引用した意見書において主張するものであったとしても、これらの課題には、上述したように、当業者にとって周知の課題であり、また、同一の環境を用いることで解決し得るものであり、当該環境は、引用発明においても内包されるものであるから、本願発明は、引用発明と当該技術分野における周知技術とから、当業者が容易になし得るものである。
　以上のとおりであるから、上記で引用した意見書における審判請求人の主張は採用できない。
　
５．むすび
　以上のとおりであるから、本願発明は、引用刊行物に記載された発明に基づいて当業者が容易にすることができたものであるので、特許法第２９条第２項の規定により特許をうけることができない。
　よって、結論のとおり審決する。