【事件の表示】
　特願２００６−２６９５６９「保安方法及びシステム、その方法を記録したコンピュータで読み取り可能な記録媒体」拒絶査定不服審判事件〔平成１９年　４月１９日出願公開，特開２００７−１０２７８５〕について，次のとおり審決する。
【結　論】
　本件審判の請求は，成り立たない。
【理　由】
　
第１　手続の経緯
　
　本件審判請求に係る出願（以下，「本願」という。）は，２００６年９月２９日（パリ条約による優先権主張外国庁受理２００５年９月３０日（以下，「優先日」という。），韓国）を出願日とする出願であって，その手続の経緯は以下のとおりである。
　
　平成２１年　９月　７日　　　：出願審査請求書の提出
　平成２４年　２月１４日付け　：拒絶理由の通知
　平成２４年　６月２１日　　　：意見書，手続補正書の提出
　平成２４年　７月１１日付け　：拒絶査定　
　平成２４年１１月１９日　　　：審判請求書の提出
　平成２６年　２月２７日付け　：拒絶理由の通知（当審）
　平成２６年　６月　４日　　　：意見書，手続補正書の提出
　平成２６年１０月１４日付け　：拒絶理由（最後）の通知（当審）
　平成２７年　１月２１日　　　：意見書，手続補正書の提出
　
　
第２　平成２６年２月２７日付け拒絶理由通知書
　
　上記平成２６年２月２７日付けで当審より通知した拒絶理由の概要は以下のとおりである。
　
『　　　　　　　　　　　　　　理　由
　
１）この出願の下記の請求項に係る発明は，その出願前日本国内又は外国において頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて，その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから，特許法第２９条第２項の規定により特許を受けることができない。
　
２）この出願は，明細書，特許請求の範囲及び図面の記載が下記の点で，特許法第３６条第４項第１号及び第６項第２号に規定する要件を満たしていない。
　
 　　　　　　　　　　　　　　　　記
　
（理由１）
請求項１−１３：　
引用文献１，２　
　
［引用文献等一覧］
１．特開２００３−２５８７８８号公報
２．特開２００２−　７２８７４号公報
　
　備考：
　
（１）引用文献に記載されている事項及び引用発明
　
＜引用文献１＞
　引用文献１の特に段落【００１３】〜【００２５】の記載から，引用文献１には，
　互いに通信可能に接続された，ユーザ端末１０２と，ユーザ端末１０２からのユーザＩＤをデータベース１０５で管理する登録局サーバ１０４と，認証局サーバ１０７とが存在する環境下で行われる公開鍵暗号方式を利用した鍵管理方法において，　
　前記ユーザ端末１０２は新たな公開鍵の登録要求を行う必要があると判断した時点で，前記ユーザＩＤを前記登録局サーバ１０４に送信するステップと，
　前記登録局サーバ１０４は，受信した前記ユーザＩＤをキーとして前記データベース１０５を検索して，前記ユーザＩＤが存在する場合には，新たな公開鍵を前記ユーザＩＤに対応づけて前記前記データベース１０５に記憶し，前記ユーザ端末１０２から送られてくる前記新たな公開鍵の使用開始要求あるいは現在の公開鍵の失効要求を受信して，前記新たな公開鍵に対するデジタル証明書の発行要求を前記認証局サーバ１０７に送信し，前記認証局サーバ１０７から送られてくる前記新たな公開鍵に対するデジタル証明書を受信して，前記ユーザ端末Ａに前記新たな公開鍵に対するデジタル証明書を送信するステップと，
　前記新たな公開鍵に対するデジタル証明書を受け取った前記ユーザ端末１０２は，現用の公開鍵のデジタル証明書が記憶されているメモリ上の領域に，受け取った前記新たな公開鍵に対するデジタル証明書を上書きするステップと，を含む公開鍵暗号方式を利用した鍵管理方法。（以下，「引用発明１」という。）が記載されていると解される。
　
＜引用文献２＞
　引用文献２の特に段落【０００３】〜【０００５】の記載から，引用文献２には，
　送信元では，送信するデータをメッセージ要約関数を使って圧縮し，この圧縮文を秘密鍵で暗号化することで認証子（電子署名）を生成し，この認証子と送信するデータとからなる署名文を作成して，それを送信先に送信し，一方，送信先は，この送られてきた署名文から認証子を抽出して，それを公開鍵で復号することで復号化圧縮文を取得すると共に，送られてきた前記署名文の本体部分（送信データ部分）をメッセージ要約関数を使って圧縮することで圧縮文を生成し，この圧縮文と復号により得た前記復号化圧縮文とを比較して，両者が一致するときには，送られてきたデータが第三者により改竄されていないと判断し，一致しないときには，送られてきたデータが第三者により改竄されたと判断すること，すなわち，デシタル署名が付加されたデータを送信元から送信先に送信し，送信先では，公開鍵を利用して前記送信されてきたデータを認証すること，が記載されていると解される。
　
（２）請求項１について
　本願の請求項１に係る発明（以下，「本願発明」という。）と，引用発明１とを比較すると，引用発明１の「互いに通信可能に接続された，ユーザ端末１０２と，ユーザ端末１０２からのユーザＩＤをデータベース１０５で管理する登録局サーバ１０４と，認証局サーバ１０７とが存在する環境下で行われる公開鍵暗号方式を利用した鍵管理方法」は，本願発明の「保安維持のための方法」に相当している。
　また，引用発明１の「ユーザ端末１０２」及び「登録局サーバ１０４」は，本願発明の「クライアント」及び「サーバ」にそれぞれ相当しており，引用発明１の「ユーザＩＤ」と，本願発明の「現在公開キー情報」は，共に「クライアント」を識別するための情報であるといえるから，引用発明１の「前記ユーザ端末１０２は新たな公開鍵の登録要求を行う必要があると判断した時点で，前記ユーザＩＤを前記登録局サーバ１０４に送信するステップ」と，本願発明の「クライアントの現在公開キー情報をサーバへ伝送するステップ」とは，共に「クライアントを識別する識別情報をサーバへ伝送するステップ」である点で共通するといえる。
　また，引用発明１の「前記新たな公開鍵に対するデジタル証明書」には，「新たな公開鍵」情報が含まれていることは明らかであるから，引用発明１の「前記登録局サーバ１０４は，受信した前記ユーザＩＤをキーとして前記データベース１０５を検索して，前記ユーザＩＤが存在する場合には，新たな公開鍵を前記ユーザＩＤに対応づけて前記前記データベース１０５に記憶し，前記ユーザ端末１０２から送られてくる前記新たな公開鍵の使用開始要求あるいは現在の公開鍵の失効要求を受信して，前記新たな公開鍵に対するデジタル証明書の発行要求を前記認証局サーバ１０７に送信し，前記認証局サーバ１０７から送られてくる前記新たな公開鍵に対するデジタル証明書を受信して，前記ユーザ端末Ａに前記新たな公開鍵に対するデジタル証明書を送信するステップ」と，本願発明の「前記サーバは，前記現在公開キー情報を基盤に前記クライアントを認証し，前記クライアントのための認証情報を検索することによって最新公開キー情報とデジタル署名を含む最新の認証情報を生成し，前記最新の認証情報をクライアントへ伝送するステップ」とは，共に，「前記サーバは，前記クライアントを識別する識別情報を基盤に前記クライアントを認証し，前記クライアントのための認証情報を検索することによって最新公開キー情報を含む最新の認証情報を生成し，前記最新の認証情報をクライアントへ伝送するステップ」である点で共通するといえる。
　また，引用発明１の「前記新たな公開鍵に対する公開鍵のデジタル証明書を受け取った前記ユーザ端末１０２は，現用の公開鍵のデジタル証明書が記憶されているメモリ上の領域に，受け取った前記新たな公開鍵に対するデジタル証明書を上書きするステップ」と，本願発明の「前記認証が成功する場合，前記最新の認証情報を利用して前記現在公開キー情報をアップデートするステップ」とは，共に，「前記最新の認証情報を利用して前記現在公開キー情報をアップデートするステップ」である点で共通するといえる。
　
　したがって，本願発明と，引用発明１とは，以下の点で相違している。
　
　＜相違点１＞
　「クライアントを識別する識別情報」が，本願発明は，「現在公開キー情報」であるのに対して，引用発明１では，「ユーザＩＤ」である点。
　
　＜相違点２＞
　本願発明は，「最新公開キー情報とデジタル署名を含む最新の認証情報を生成し，前記最新の認証情報をクライアントへ伝送」するように構成しているのに対して，引用発明１は，「前記認証局サーバ１０７から送られてくる，前記新たな公開鍵に対するデジタル証明書を受信して，前記ユーザ端末Ａに前記新たな公開鍵に対するデジタル証明書を送信」している点。
　
　＜相違点３＞
　「前記最新の認証情報を利用して前記現在公開キー情報をアップデート」する条件として，本願発明は，「前記現在公開キー情報を利用して前記最新の認証情報を認証」できた場合であるのに対して，引用発明１は，この点が明記されていない点。
　
　上記相違点に対する当審の判断は以下のとおりである。
　
＜相違点１について＞
　クライアントを識別する識別情報として，本願発明のように「現在公開キー情報」を用いるか，あるいは，引用発明１のように「ユーザＩＤ」を用いるかは当業者がその必要に応じて適宜選択し得るものであるから，引用発明１における「ユーザＩＤ」を「現在公開キー情報」に代えて本願発明のように構成すること，すなわち，上記相違点１に係る構成とすることは，当業者が容易に想到し得たことである。
　よって，相違点１は格別なものではない。
　
＜相違点２について＞
　引用発明１における「前記認証局サーバ１０７から送られてくる，前記新たな公開鍵に対するデジタル証明書」には，新たな公開鍵情報とその認証情報が含まれていることは自明であるから，相違点２は実質的な相違点ではないが，仮に相違していたとしても，一般に，最新公開キー情報とデジタル署名を含む最新の認証情報を生成し，前記最新の認証情報として相手側に送信することは，従来周知の技術事項であるから，引用発明１にこのような従来周知の技術思想を適用して，本願発明のように構成すること，すなわち，上記相違点２に係る構成とすることは，当業者が容易に想到し得たことである。
　よって，相違点２は格別なものではない。
　
＜相違点３について＞
　引用発明１において，「受け取った前記新たな公開鍵に対するデジタル証明書を上書きする」のは，「前記新たな公開鍵に対するデジタル証明書」の認証が済んだ後であることは自明の技術事項であるから，上記相違点３は実質的な相違点ではない。
　また，仮に，相違しているとしてもこの点は当業者が適宜なし得る事項に過ぎない。
　よって，相違点３は格別なものではない。
　
（３）請求項２について
　送信元では，送信するデータをメッセージ要約関数を使って圧縮し，この圧縮文を秘密鍵で暗号化することで認証子（電子署名）を生成し，この認証子と送信するデータとからなる署名文を作成して，それを送信先に送信し，一方，送信先は，この送られてきた署名文から認証子を抽出して，それを公開鍵で復号することで復号化圧縮文を取得すると共に，送られてきた前記署名文の本体部分（送信データ部分）をメッセージ要約関数を使って圧縮することで圧縮文を生成し，この圧縮文と復号により得た前記復号化圧縮文とを比較して，両者が一致するときには，送られてきたデータが第三者により改竄されていないと判断し，一致しないときには，送られてきたデータが第三者により改竄されたと判断すること，すなわち，デシタル署名が付加されたデータを送信元から送信先に送信し，送信先では，公開鍵を利用して前記送信されてきたデータを認証することは，上記引用文献２に記載されているように従来周知の技術事項であるから，本願の請求項２に係る発明は，引用発明１及び引用文献２に記載されている従来周知の技術事項から，当業者が容易に想到し得たことである。
　
…（中略）…　
　
（理由２）
　
（１）特許法第３６条第４項１号について
　
ａ．請求項１−１３に関して，「現在公開キー情報」および，「現在公開キー情報」から生成される「最新公開キー情報」が発明特定事項に含まれ，これら発明特定事項について，発明の詳細な説明の００２１段落には，「認証情報伝送モジュール１１０は，メモリ１５１に保存されている認証情報を，通信モジュール１４０を通じてサーバ２００へ伝送し，サーバ２００から最新の認証情報を受信する。認証情報１５０は，公開キーについての情報を含むことが望ましい。また，サーバ２００は，既存の公開キーをアップデートするための情報として，最新の公開キー情報と，この公開キー情報についてのデジタル署名とを含む最新の認証情報を伝送する。このとき，サーバ２００は，クライアント１００から受信した認証情報を利用してクライアントを確認し，クライアントのための認証情報を検索して最新の認証情報を生成した後に送信する。」が記載され，００２４段落には，「サーバは，クライアントから受信した認証情報を利用して，クライアントのための最新の認証情報を生成して伝送する（Ｓ２０４）。このステップで，サーバは，クライアントの認証情報を基盤にクライアントの現在状態を把握し，クライアントが認証できる情報を検索して伝送する。このとき，サーバが伝送する最新の認証情報は，クライアントのための最新の公開キー情報と，この公開キー情報についてのデジタル署名とを含むことが望ましい。」が記載されているが，どのように現在公開キー情報を含む認証情報から最新公開キー情報を含む最新の認証情報を生成するのか，そのための情報処理が不明である。　
　すなわち，発明の詳細な説明の００２９段落には，「クライアントは，自身の公開キーを利用して受信された情報のデジタル署名を検証し（Ｓ５０６），受信された情報が安全であると判断される場合にのみ，自身の公開キーと最新の公開キーとを比較してアップデートの如何を決定する。アップデートが必要であると判断されれば，自身の公開キーを最新の公開キーに修正する（Ｓ５０８）。受信された情報の認証に失敗するか，または最新の認証情報に新たな内容がないと判断されれば，公開キーをアップデートせずに次のステップを行う。」と記載されており，「最新の公開キー」を含む「最新の認証情報」について「最新の認証情報に新たな内容がないと判断され」る場合が発生すると解されるが，００２１段落や００２４段落に記載の，現在公開キー情報を含む認証情報から最新公開キー情報を含む最新の認証情報の生成をどのような処理で実行すると，このような「最新の認証情報に新たな内容がないと判断され」る状況が発生するのか不明であり，理解することができない。　
　したがって，出願時の技術常識を考慮しても，発明の詳細な説明は，当業者が請求項１−１３に係る発明の実施をすることができる程度に明確かつ十分に記載したものでない。
　
…（後略）…　』
　
　
第３　本願発明の進歩性について
　
１　本願発明
　
　本願の請求項１に記載された発明（以下，「本願発明」という。）は，上記平成２７年１月２１日付け手続補正書により補正された特許請求の範囲及び明細書の記載からみて，その特許請求の範囲の請求項１に記載された以下のとおりのものと認める。
　
「　保安維持のための方法において，
　クライアントの現在公開キー情報を含む認証情報をサーバへ伝送するステップと，
　前記サーバは，前記認証情報に含まれる前記現在公開キー情報を基盤に前記クライアントを認証し，前記クライアントのための認証情報を検索することによって最新公開キー情報とデジタル署名を含む最新の認証情報を生成し，前記最新の認証情報をクライアントへ伝送するステップと，
　前記現在公開キー情報を利用して前記デジタル署名を解読し，前記最新の認証情報を認証するステップと，
　前記認証が成功する場合，前記最新の認証情報を利用して前記現在公開キー情報を含む前記最新の認証情報に前記認証情報をアップデートするステップと，を含むことを特徴とする保安方法。」　
　
　
２　引用例
　
（１）　引用例１に記載されている技術的事項および引用発明
　
ア　本願の優先日前に頒布され，当審からの上記平成２６年２月２７日付け拒絶理由通知において引用された，特開２００３−２５８７８８号公報（平成１５年９月１２日出願公開，以下，「引用例１」という。）には，関連する図面とともに，以下の技術的事項が記載されている。
　（当審注：下線は，参考のために当審で付与したものである。）
　
Ａ　「【００１２】
この発明は，このような課題に着目してなされたもので，前記デジタル証明書の余分な発行などにかかる費用や余分な公開鍵などの管理に対する負担を減少させつつ，現用の公開鍵失効後の新規公開鍵への切り替えが迅速に行える仕組みを実現する，登録局サーバ１０４の運用方法を提供することを目的とする。
【００１３】　
【課題を解決するための手段】
上記目的を達成する本発明の登録局サーバの運用方法は，互いに通信可能に接続された，ユーザ端末と認証局サーバと登録局サーバとが存在する環境下で行われる公開鍵暗号方式を利用した鍵管理方法における前記登録局サーバの運用方法であって，前記登録局サーバは，ユーザＩＤをデータベースで管理し，あるユーザ端末Ａから新たな公開鍵の登録要求を受信して，これに付帯して受信したユーザＩＤをキーとして前記データベースを検索し，ユーザＩＤが存在する場合には，新たな公開鍵を前記ユーザＩＤに対応づけて前記データベースに記憶し，ユーザ端末Ａあるいは他のユーザ端末から送られてくる前記新たな公開鍵の使用開始要求あるいは現在の公開鍵の失効要求を受信して，前記新たな公開鍵に対するデジタル証明書の発行要求を前記認証局サーバに送信し，前記認証局サーバから送られてくる，前記新たな公開鍵に対するデジタル証明書を受信して，ユーザ端末Ａに前記デジタル証明書を送信する
　
Ｂ　「【００１４】　
【発明の実施の形態】以下，本発明の実施の形態を，図を参照しながら詳細に説明する。　
【００１５】図１は，ネットワーク１０１のような通信手段を利用した「公開鍵暗号方式」による鍵管理方法の全体構成を示している。　
【００１６】
ユーザ１００が操作するユーザ端末１０２，１０３と，登録局１０６での登録局サーバ１０４と，認証局１０８での認証局サーバ１０７とが，運用されている。登録局サーバ１０４と認証局サーバ１０７とは，同一局の異なる部門にあって，ＬＡＮによって結ばれていても良い。
　
Ｃ　「【００１９】＜第１実施例＞登録局サーバ１０４では，鍵データベース１０５が稼働する。このデータベース１０５には，ユーザＩＤを含むユーザ情報，「公開鍵暗号方式」に利用される現用の鍵ペア，その現用公開鍵に対するデジタル証明書，予備の鍵ペア，その予備公開鍵に対するデジタル証明書，及び新規鍵に対する審査情報等が，関連づけて記憶されている。　
【００２０】
前述したように，秘密鍵や公開鍵は，使用頻度や時間経過とともに次第に危殆化が進行していく。ユーザ１００はその危殆化の進行度を，例えば，使用頻度などから判断し，ある時点で，予備鍵を新たに準備する時期であると判断する。その時点で，ユーザ１００は，ユーザ端末１０２を通じて登録局サーバ１０４が開設しているホームページ５００にアクセスし，それぞれ予備公開鍵と予備秘密鍵として，新たな公開鍵と新たな秘密鍵の準備を行う。
　
Ｄ　「【００２１】図２は，第１実施例の運用方法に関するフローチャートである。図５に，登録局サーバ１０４のホームページ５００の画面の一例を示す。　
【００２２】図２に示すように，
登録局サーバ１０４のホームページ５００において，ユーザ１００がユーザ端末１０２から「予備公開鍵の登録−予備公開鍵はもっていない−今すぐに生成して保管しておく」の各チェック欄５０１，５０２，５０５をクリックし，送信ボタン５０９をクリックすることによって登録局サーバ１０４に送信すると（ｓ２０１），登録局サーバ１０４は，送信されたユーザＩＤをキーとして，鍵データベース１０５を検索し，保管されているユーザ情報や現用公開鍵等の情報を得る。
審査が合格になると，登録局サーバ１０４は，鍵ペアを生成し（ｓ２０２），鍵データベース１０５にユーザＩＤと関連づけて保管する（ｓ２０３）。
【００２３】
ユーザは，現用秘密鍵の危殆化が過度に進行したと判断すると，ユーザ端末１０２を通じて同じホームページ５００にアクセスし，「予備公開鍵の使用開始」のチェック欄５０７をクリックすることにより，今度は予備公開鍵の使用開始要求を送信する（ｓ２０４）。この要求を受信した登録局サーバ１０４は，認証局サーバ１０７に，ユーザＩＤと関連づけた公開鍵，現用公開鍵の失効要求とともに，公開鍵のデジタル証明書の発行要求を送信する（ｓ２０５）。
【００２４】
つぎに，認証局サーバ１０７が，現用公開鍵のデジタル証明書を失効させる一方，要求された公開鍵のデジタル証明書を発行し，登録局サーバ１０４に送信する（ｓ２０６）と，これを受信した登録局サーバ１０４は，ユーザ端末１０２にその公開鍵に対するデジタル証明書を送信し（ｓ２０７），鍵データベース１０５にユーザＩＤと対応づけてユーザ情報及び公開鍵デジタル証明書を記憶する（ｓ２０８）。
【００２５】
このようにして前記公開鍵のデジタル証明書を受け取ったユーザ端末１０２は，現用の公開鍵のデジタル証明書が記憶されているメモリ上の領域に，受け取ったデジタル証明書を上書きする。
　
Ｅ　「【００３０】＜第３実施例＞
登録局サーバ１０４において，予備公開鍵をあらかじめ用意しておくのではなく，登録局１０６による審査だけを予め済ませておき，新規公開鍵への切り替えの際に，新たに予備公開鍵を生成するようにしてもよい。
【００３１】
この実施例では，ユーザ１００が，予備鍵ペアを準備する時期であると判断した時点で，ユーザ端末１０２を通じて登録局サーバ１０４のホームページ５００にアクセスし，ユーザ端末１０２において，「予備公開鍵の登録−予備公開鍵は持っていない−現用鍵からの切り替えの直前に生成する」の各チェック欄５０１，５０３，５０６という組み合わせをクリックし，ユーザ情報と共に入力情報を送信する（ｓ４０１）。登録局１０６は，ユーザ端末１０２から登録局サーバ１０４に送信されたユーザ情報に基づいて，上記と同様に審査を行う。審査が合格になると，登録局サーバ１０４は，ユーザＩＤと関連づけて，送信された登録要求を記録する（ｓ４０２）。これにより，第１実施例のときと同様，危殆化と関係なく現用公開鍵生成時から予備鍵を準備しなければならない必要性がなくなり，余分な予備鍵の管理負担を減少させることができるだけでなく，予備鍵の有効期間の開始は生成時から始まるため，無駄な有効期限の消費を防ぐことができる。
　
イ　ここで，上記引用例１に記載されている事項を検討する。　
　
（ア）　上記Ａの「この発明は，このような課題に着目してなされたもので，前記デジタル証明書の余分な発行などにかかる費用や余分な公開鍵などの管理に対する負担を減少させつつ，現用の公開鍵失効後の新規公開鍵への切り替えが迅速に行える仕組みを実現する，登録局サーバ１０４の運用方法を提供することを目的とする。」との記載からすると，引用例１には，公開鍵の管理を目的とする発明が読み取れる。
　また，上記Ａの「上記目的を達成する本発明の登録局サーバの運用方法は，互いに通信可能に接続された，ユーザ端末と認証局サーバと登録局サーバとが存在する環境下で行われる公開鍵暗号方式を利用した鍵管理方法における前記登録局サーバの運用方法であって，前記登録局サーバは，ユーザＩＤをデータベースで管理し」との記載，上記Ｂの「ユーザ１００が操作するユーザ端末１０２，１０３と，登録局１０６での登録局サーバ１０４と，認証局１０８での認証局サーバ１０７とが，運用されている。登録局サーバ１０４と認証局サーバ１０７とは，同一局の異なる部門にあって，ＬＡＮによって結ばれていても良い。」との記載からすると，「ユーザ端末」と「認証局サーバ」と「登録局サーバ」とが行う「公開鍵暗号方式を利用した鍵管理方法」が読み取れることから，引用例１には，
“互いに通信可能に接続された，ユーザ端末と，前記ユーザ端末からのユーザＩＤをデータベースで管理する登録局サーバと，認証局サーバとが存在する環境下で行われる公開鍵暗号方式を利用した鍵管理方法”　
が記載されていると解される。
　
（イ）　上記Ａの「あるユーザ端末Ａから新たな公開鍵の登録要求を受信して，これに付帯して受信したユーザＩＤをキーとして前記データベースを検索し」との記載，上記Ｃの「前述したように，秘密鍵や公開鍵は，使用頻度や時間経過とともに次第に危殆化が進行していく。ユーザ１００はその危殆化の進行度を，例えば，使用頻度などから判断し，ある時点で，予備鍵を新たに準備する時期であると判断する。その時点で，ユーザ１００は，ユーザ端末１０２を通じて登録局サーバ１０４が開設しているホームページ５００にアクセスし，それぞれ予備公開鍵と予備秘密鍵として，新たな公開鍵と新たな秘密鍵の準備を行う。」との記載からすると，ユーザは新たな公開鍵の登録要求を行う必要があると判断した時点で，「登録局サーバ」にアクセスするために，「ユーザ端末」から「ユーザＩＤ」を送信することが読み取れるから，引用例１には，
“ユーザ端末は新たな公開鍵の登録要求を行う必要があると判断した時点で，ユーザＩＤを登録局サーバに送信するステップ”　
が記載されていると解される。
　
（ウ）　上記Ａの「前記登録局サーバは，ユーザＩＤをデータベースで管理し，あるユーザ端末Ａから新たな公開鍵の登録要求を受信して，これに付帯して受信したユーザＩＤをキーとして前記データベースを検索し，ユーザＩＤが存在する場合には，新たな公開鍵を前記ユーザＩＤに対応づけて前記データベースに記憶し」との記載，上記Ｄの「登録局サーバ１０４のホームページ５００において，ユーザ１００がユーザ端末１０２から「予備公開鍵の登録−予備公開鍵はもっていない−今すぐに生成して保管しておく」の各チェック欄５０１，５０２，５０５をクリックし，送信ボタン５０９をクリックすることによって登録局サーバ１０４に送信すると（ｓ２０１），登録局サーバ１０４は，送信されたユーザＩＤをキーとして，鍵データベース１０５を検索し，保管されているユーザ情報や現用公開鍵等の情報を得る。　…（中略）…　審査が合格になると，登録局サーバ１０４は，鍵ペアを生成し（ｓ２０２），鍵データベース１０５にユーザＩＤと関連づけて保管する（ｓ２０３）。」との記載からすると，登録局サーバは，ユーザ端末から受信したユーザＩＤをキーとしてデータベースを検索して，前記ユーザＩＤが存在する場合には新たな公開鍵を生成し，前記ユーザＩＤに対応づけて前記データベースに記憶することが読み取れる。
　また，上記Ａの「ユーザ端末Ａあるいは他のユーザ端末から送られてくる前記新たな公開鍵の使用開始要求あるいは現在の公開鍵の失効要求を受信して，前記新たな公開鍵に対するデジタル証明書の発行要求を前記認証局サーバに送信し，前記認証局サーバから送られてくる，前記新たな公開鍵に対するデジタル証明書を受信して，ユーザ端末Ａに前記デジタル証明書を送信する」との記載，上記Ｄの「ユーザは，現用秘密鍵の危殆化が過度に進行したと判断すると，ユーザ端末１０２を通じて同じホームページ５００にアクセスし，「予備公開鍵の使用開始」のチェック欄５０７をクリックすることにより，今度は予備公開鍵の使用開始要求を送信する（ｓ２０４）。この要求を受信した登録局サーバ１０４は，認証局サーバ１０７に，ユーザＩＤと関連づけた公開鍵，現用公開鍵の失効要求とともに，公開鍵のデジタル証明書の発行要求を送信する（ｓ２０５）。」，「つぎに，認証局サーバ１０７が，現用公開鍵のデジタル証明書を失効させる一方，要求された公開鍵のデジタル証明書を発行し，登録局サーバ１０４に送信する（ｓ２０６）と，これを受信した登録局サーバ１０４は，ユーザ端末１０２にその公開鍵に対するデジタル証明書を送信し（ｓ２０７），鍵データベース１０５にユーザＩＤと対応づけてユーザ情報及び公開鍵デジタル証明書を記憶する（ｓ２０８）。」との記載からすると，登録局サーバは，ユーザ端末から新たな公開鍵の使用開始要求を受信すると，新たな公開鍵に対するデジタル証明書の発行要求を認証局サーバに送信する態様，登録局サーバは，認証局サーバから送られてくる新たな公開鍵に対するデジタル証明書を受信すると，ユーザ端末に当該デジタル証明書を送信する態様を読み取ることができるから，引用例１には，
“登録局サーバは，受信したユーザＩＤをキーとしてデータベースを検索して，前記ユーザＩＤが存在する場合には新たな公開鍵を生成し，前記ユーザＩＤに対応づけて前記データベースに記憶し，ユーザ端末から送られてくる前記新たな公開鍵の使用開始要求を受信して，前記新たな公開鍵に対するデジタル証明書の発行要求を認証局サーバに送信し，前記認証局サーバから送られてくる前記新たな公開鍵に対するデジタル証明書を受信して，前記ユーザ端末に前記新たな公開鍵に対するデジタル証明書を送信するステップ”　
が記載されていると解される。
　
（エ）　上記Ｄの「このようにして前記公開鍵のデジタル証明書を受け取ったユーザ端末１０２は，現用の公開鍵のデジタル証明書が記憶されているメモリ上の領域に，受け取ったデジタル証明書を上書きする。」との記載からすると，公開鍵のデジタル証明書を受け取り，受け取ったデジタル証明書を上書きするユーザ端末は，新たな公開鍵の使用開始要求を登録局サーバに送信したユーザ端末であることは明らかであるから，引用例１には，
“新たな公開鍵に対するデジタル証明書を受け取ったユーザ端末は，現用の公開鍵のデジタル証明書が記憶されているメモリ上の領域に，受け取った前記新たな公開鍵に対するデジタル証明書を上書きするステップ”　
が記載されていると解される。
　
ウ　以上，（ア）乃至（エ）の検討によれば，引用例１には，次の発明（以下，「引用発明」という。）が記載されているものと認める。
　
「互いに通信可能に接続された，ユーザ端末と，前記ユーザ端末からのユーザＩＤをデータベースで管理する登録局サーバと，認証局サーバとが存在する環境下で行われる公開鍵暗号方式を利用した鍵管理方法において，
　前記ユーザ端末は新たな公開鍵の登録要求を行う必要があると判断した時点で，前記ユーザＩＤを前記登録局サーバに送信するステップと，
　前記登録局サーバは，受信した前記ユーザＩＤをキーとして前記データベースを検索して，前記ユーザＩＤが存在する場合には新たな公開鍵を生成し，前記ユーザＩＤに対応づけて前記データベースに記憶し，前記ユーザ端末から送られてくる前記新たな公開鍵の使用開始要求を受信して，前記新たな公開鍵に対するデジタル証明書の発行要求を前記認証局サーバに送信し，前記認証局サーバから送られてくる前記新たな公開鍵に対するデジタル証明書を受信して，前記ユーザ端末に前記新たな公開鍵に対するデジタル証明書を送信するステップと，
　前記新たな公開鍵に対するデジタル証明書を受け取った前記ユーザ端末は，現用の公開鍵のデジタル証明書が記憶されているメモリ上の領域に，受け取った前記新たな公開鍵に対するデジタル証明書を上書きするステップと，
を含む公開鍵暗号方式を利用した鍵管理方法。」　
　
　
（２）　引用例２に記載されている技術的事項
　
　本願の優先日前に頒布され，当審からの上記平成２６年２月２７日付け拒絶理由通知において引用された，特開２００２−７２８７４号公報（平成１４年３月１２日出願公開，以下，「引用例２」という。）には，関連する図面とともに，以下の技術的事項が記載されている。
　（当審注：下線は，参考のために当審で付与したものである。）
　
Ｆ　「【０００３】
この電子署名を用いる場合，送信元は，図６の処理フローに示すように，送信するデータをメッセージ要約関数を使って圧縮し，この圧縮文を秘密鍵で暗号化することで認証子（電子署名）を生成する。そして，この認証子と送信するデータとからなる署名文を作成して，それを送信先に送信する。
【０００４】
この署名文を受けて，送信先は，図７の処理フローに示すように，送られてきた署名文から認証子を抽出して，それを公開鍵で復号することで復号化圧縮文を取得する。
【０００５】
そして，送られてきた署名文の本体部分（送信データ部分）をメッセージ要約関数を使って圧縮することで圧縮文を生成し，この圧縮文と復号により得た復号化圧縮文とを比較して，両者が一致するときには，送られてきたデータが第三者により改竄されていないと判断し，一致しないときには，送られてきたデータが第三者により改竄されたと判断する。
　
　
３　参考文献
　
（１）　参考文献１に記載されている技術的事項
　
　本願優先日前に頒布された，特開２００５−１８２３１７号公報（平成１７年７月７日出願公開，以下，「参考文献１」という。）には，関連する図面とともに，以下の技術的事項が記載されている。
　（当審注：下線は，参考のために当審で付与したものである。）
　
Ｇ　「【０００８】
　この電子カルテシステムにおいては，
通信端末固有の情報である公開鍵証明書の識別番号によって本人認証がおこなわれる。そして，この公開鍵証明書の識別番号は，通信端末の登録手段によって情報システムにオンラインで登録される。そのため，ユーザは面倒な登録作業をすることなく，本人認証に用いられる情報を容易に情報システムに登録することができる。
　…（中略）…
【００１９】
　端末格納部１８には，端末ユーザが医療機関から取得した自己の電子カルテの識別情報であるカルテＩＤが格納されている。
証明書受信部２０は，認証局１２から移動体通信網２８を介して自端末のクライアント証明書を受信して端末格納部１８に格納し，また移動体通信網２８及びインターネット３０を介して情報システム１６に対してクライアント証明書を送信する。なお，クライアント証明書は公開鍵証明書であるため，この証明書には公開鍵及び他の証明書との識別が可能な識別情報（以下，証明書ＩＤを称す。）が含まれている。
　
（２）　参考文献２に記載されている技術的事項
　
　本願優先日前に頒布された，特開２００２−２８７６３１号公報（平成１４年１０月４日出願公開，以下，「参考文献２」という。）には，関連する図面とともに，以下の技術的事項が記載されている。
　（当審注：下線は，参考のために当審で付与したものである。）
　
Ｈ　「【０００３】また，
ネットワーク上での本人認証方法として，利用者ＩＤ（識別子）とパスワードによる方法に比べて認証の為の情報を分散管理可能な，上記の公開鍵証明書を利用した本人認証方法が利用されている。
　…（中略）…
【０００６】この発明は，上述した事情を考慮してなされたもので，
属性証明書の発行時に公開鍵証明書で本人認証を行う属性証明書管理サーバ，属性証明書管理方法およびそのプログラムを提供することを目的とする。
　
　
４　対比
　
（１）　本願発明と引用発明とを対比する。
　
ア　引用発明の「互いに通信可能に接続された，ユーザ端末と，前記ユーザ端末からのユーザＩＤをデータベースで管理する登録局サーバと，認証局サーバとが存在する環境下で行われる公開鍵暗号方式を利用した鍵管理方法」は，セキュリティ維持のために公開鍵を管理することは明らかであるから，上位概念において本願発明の“保安維持のための方法”に相当すると言える。
　
イ　引用発明は「ユーザ端末は新たな公開鍵の登録要求を行う必要があると判断した時点で，前記ユーザＩＤを前記登録局サーバに送信する」ところ，「ユーザ端末」から「登録局サーバ」へ新たな公開鍵の登録要求を行うための「ユーザＩＤ」を送信することから，引用発明の「ユーザ端末」，「登録局サーバ」は，本願発明の「クライアント」，「サーバ」に相当すると言える。
　そして，引用発明の「ユーザＩＤ」と，本願発明の「現在公開キー情報を含む認証情報」は，共に「クライアント」を認証するための識別情報であると言えるから，引用発明の「ユーザ端末は新たな公開鍵の登録要求を行う必要があると判断した時点で，前記ユーザＩＤを前記登録局サーバに送信するステップ」と，本願発明の「クライアントの現在公開キー情報を含む認証情報をサーバへ伝送するステップ」とは後記する点で相違するものの，“クライアントを認証する識別情報をサーバへ伝送するステップ”である点で共通すると言える。
　
ウ　引用発明は「前記登録局サーバは，受信した前記ユーザＩＤをキーとして前記データベースを検索して，前記ユーザＩＤが存在する場合には新たな公開鍵を生成し，前記ユーザＩＤに対応づけて前記データベースに記憶」するところ，ユーザＩＤが存在するか否かを判定することから，登録局サーバは，ユーザを識別するユーザＩＤを基盤に前記ユーザを認証し，前記ユーザのための新たな公開鍵を生成すると言える。さらに，引用発明は「前記新たな公開鍵に対するデジタル証明書の発行要求を前記認証局サーバに送信し，前記認証局サーバから送られてくる前記新たな公開鍵に対するデジタル証明書を受信して，前記ユーザ端末に前記新たな公開鍵に対するデジタル証明書を送信する」ところ，登録局サーバは，ユーザＩＤにより識別された当該ユーザのための当該新たな公開鍵に対するデジタル証明書の発行を認証局サーバに要求し，認証局サーバから受信した当該新たな公開鍵に対するデジタル証明書をユーザ端末に送信していると言える。
　また，引用発明の「前記新たな公開鍵に対するデジタル証明書」には，「新たな公開鍵」情報が含まれていることは明らかであり，本願発明の「最新の認証情報」は，最新公開キー情報を含むクライアントの証明情報とみることができることから，引用発明の「新たな公開鍵に対するデジタル証明書」と，本願発明の「最新公開キー情報とデジタル署名を含む最新の認証情報」とは，共に“最新公開キー情報を含む最新の証明情報”である点で共通する。
　そうすると，引用発明の「前記登録局サーバは，受信した前記ユーザＩＤをキーとして前記データベースを検索して，前記ユーザＩＤが存在する場合には新たな公開鍵を生成し，前記ユーザＩＤに対応づけて前記データベースに記憶し，前記ユーザ端末から送られてくる前記新たな公開鍵の使用開始要求を受信して，前記新たな公開鍵に対するデジタル証明書の発行要求を前記認証局サーバに送信し，前記認証局サーバから送られてくる前記新たな公開鍵に対するデジタル証明書を受信して，前記ユーザ端末に前記新たな公開鍵に対するデジタル証明書を送信するステップ」と，本願発明の「前記サーバは，前記認証情報に含まれる前記現在公開キー情報を基盤に前記クライアントを認証し，前記クライアントのための認証情報を検索することによって最新公開キー情報とデジタル署名を含む最新の認証情報を生成し，前記最新の認証情報をクライアントへ伝送するステップ」とは後記する点で相違するものの，“サーバは，クライアントの識別情報を基盤に前記クライアントを認証し，前記クライアントのための最新公開キー情報を含む最新の証明情報を生成し，前記最新の証明情報をクライアントへ伝送するステップ”である点で共通すると言える。
　
エ　引用発明は「新たな公開鍵に対するデジタル証明書を受け取った前記ユーザ端末は，現用の公開鍵のデジタル証明書が記憶されているメモリ上の領域に，受け取った前記新たな公開鍵に対するデジタル証明書を上書きする」ところ，ユーザ端末は登録局サーバから受け取った最新の証明情報を利用して最新の証明情報にアップデートしているとみることができ，引用発明の「新たな公開鍵に対するデジタル証明書」と，本願発明の「最新の認証情報」とは，共に“最新の証明情報”である点で共通する。
　そうすると，引用発明の「新たな公開鍵に対するデジタル証明書を受け取った前記ユーザ端末は，現用の公開鍵のデジタル証明書が記憶されているメモリ上の領域に，受け取った前記新たな公開鍵に対するデジタル証明書を上書きするステップ」と，本願発明の「前記認証が成功する場合，前記最新の認証情報を利用して前記現在公開キー情報を含む前記最新の認証情報に前記認証情報をアップデートするステップ」とは後記する点で相違するものの，“最新の証明情報を利用して現在公開キー情報を含む前記最新の証明情報に前記証明情報をアップデートするステップ”である点で共通すると言える。
　
（２）　以上，ア乃至エの検討によれば，本願発明と引用発明とは，以下の点で一致し，また，以下の点で相違する。
　
（一致点） 
　
「　保安維持のための方法において，
　クライアントを認証する識別情報をサーバへ伝送するステップと，　
　前記サーバは，前記クライアントの前記識別情報を基盤に前記クライアントを認証し，前記クライアントのための最新公開キー情報を含む最新の証明情報を生成し，前記最新の証明情報を前記クライアントへ伝送するステップと，
　前記最新の証明情報を利用して現在公開キー情報を含む前記最新の証明情報に前記証明情報をアップデートするステップと，を含むことを特徴とする保安方法。」　
　
（相違点１）
　クライアントを認証する識別情報に関し，本願発明は，「現在公開キー情報を含む認証情報」により認証しているのに対して，引用発明は「ユーザＩＤ」を用いて認証する点。
　
（相違点２）
　クライアントに送信する最新公開キー情報を含む最新の証明情報の生成手順に関し，本願発明では，サーバが，「認証情報に含まれる前記現在公開キー情報を基盤に前記クライアントを認証し，前記クライアントのための認証情報を検索することによって最新公開キー情報とデジタル署名を含む最新の認証情報」を同時に生成するのに対して，引用発明では，登録局サーバが，「受信した前記ユーザＩＤをキーとして前記データベースを検索して」「新たな公開鍵」を予め生成し，「ユーザ端末から送られてくる前記新たな公開鍵の使用開始要求を受信し」た時点で，「新たな公開鍵に対するデジタル証明書の発行要求を前記認証局サーバに送信」する点。
　
（相違点３）
　最新の証明情報にアップデートする条件に関し，本願発明は，「前記現在公開キー情報を利用して前記デジタル署名を解読し，前記最新の認証情報を認証」できた場合に，「認証情報をアップデートする」のに対して，引用発明は，「新たな公開鍵に対するデジタル証明書を上書きする」条件について言及されていない点。
　
　
５　当審の判断
　
　上記相違点１乃至３について検討する。
　
（１）　相違点１について
　
　参考文献１（上記Ｇを参照）や参考文献２（上記Ｈを参照）に記載されるように，公開鍵の情報を含む認証情報を，クライアント端末ユーザの本人確認のために利用することは，本願優先日前には当該技術分野の周知技術であった。
　また，クライアント端末を利用するユーザの認証を行うために，如何なる認証情報を用いるかということは，通信の安全性等を考慮して適宜に選択すべき事項であると言える。
　してみると，引用発明において，上記周知技術を適用し，ユーザＩＤに代えて，適宜，現用の公開鍵を含む認証情報によりユーザを認証すること，すなわち，上記相違点１に係る構成とすることは，当業者が容易に想到し得たことである。
　
（２）　相違点２について
　
　引用発明は，登録局サーバが，「受信した前記ユーザＩＤをキーとして前記データベースを検索して」「新たな公開鍵」を予め生成し，「ユーザ端末から送られてくる前記新たな公開鍵の使用開始要求を受信し」た時点で，「新たな公開鍵に対するデジタル証明書の発行要求を前記認証局サーバに送信し，前記認証局サーバから送られてくる前記新たな公開鍵に対するデジタル証明書」をユーザ端末に送信するところ，ユーザを認証する識別情報を基盤に，新たな公開鍵と最新の証明情報とを順次に生成していると言える。そして，引用例１の上記Ｅの記載からすると，新たな公開鍵の生成と，新たな公開鍵の最新の証明情報の生成とを同時に行う態様も可能であることが読み取れることから，新たな公開鍵の生成を，証明情報の生成と同時に行うか，証明情報の生成より前に予め行うかは，当業者にとって必要に応じて選択し得た設計的事項であった。
　また，上記「（１）　相違点１について」での検討のとおり，公開鍵の情報を含む認証情報を，クライアント端末ユーザの本人確認のために利用することは，本願優先日前には周知技術であり，かつ，公開鍵に対するデジタル証明書にデジタル署名を付けて送信する旨の技術も，本願優先日前には当該技術分野の慣用技術であった。
　してみると，引用発明において，上記周知技術を適用し，適宜，登録局サーバが，現用の公開鍵を基盤にユーザを認証し，前記ユーザのための認証情報を検索することによって新たな公開鍵情報とデジタル署名を含む最新の認証情報とを生成すること，すなわち，上記相違点２に係る構成とすることは，当業者が容易に想到し得たことである。
　
（３）　相違点３について
　
　引用例２（上記Ｆを参照）に記載されるように，デシタル署名が付加されたデータを送信元から送信先に送信し，送信先では公開鍵を利用して前記送信されてきたデータの真正性を確認することは，本願優先日前に周知技術であり，安全性の高いデータの送受信を行うことを技術的課題としている点で引用発明と共通すると言える。
　また，受信データの真正性の確認が済んだ後に当該受信データに基づく登録データの更新処理を実行することは，セキュリティ通信の技術分野における周知慣用技術である。
　そうすると，引用発明において，上記の周知技術を適用し，適宜，現用の公開鍵を利用して新たなデジタル証明書に含まれるデジタル署名を解読し，前記新たなデジタル証明書を認証できた場合に，当該デジタル証明書をアップデートすること，すなわち，上記相違点３に係る構成とすることは，当業者が容易に想到し得たことである。
　
（４）　小括
　
　上記で検討したごとく，相違点１乃至３に係る構成は当業者が容易に想到し得たものであり，そして，これらの相違点を総合的に勘案しても，本願発明の奏する作用効果は，上記引用発明及び引用例２などに記載の当該技術分野の周知技術の奏する作用効果から予測される範囲内のものにすぎず，格別顕著なものということはできない。
　
　
６　本願発明の進歩性についてのむすび 
　
　以上のとおり，本願の請求項１に係る発明は，上記引用発明，引用例２などに記載の当該技術分野の周知技術に基づいて，当業者が容易に発明をすることができたものである。
　
　
第４　当審による平成２６年２月２７日付け拒絶理由通知書の理由２（記載不備）について
　
１　理由２（１）ａ．について
　
（１）　平成２７年１月２１日付け手続補正書により補正された特許請求の範囲請求項１には，「前記サーバは，前記認証情報に含まれる前記現在公開キー情報を基盤に前記クライアントを認証し，前記クライアントのための認証情報を検索することによって最新公開キー情報とデジタル署名を含む最新の認証情報を生成」することが特定されており， 「現在公開キー情報」および，「現在公開キー情報」から生成される「最新公開キー情報」が発明特定事項に含まれているところ，これら発明特定事項について，発明の詳細な説明の記載を参酌しても，如何にして現在公開キー情報を基盤にしてクライアントのための認証情報を検索し，如何にして最新公開キー情報とデジタル署名を含む最新の認証情報を生成するのか，そのための情報処理が依然として不明である。　
　すなわち，発明の詳細な説明の段落【００２１】には，「認証情報伝送モジュール１１０は，メモリ１５１に保存されている認証情報を，通信モジュール１４０を通じてサーバ２００へ伝送し，サーバ２００から最新の認証情報を受信する。認証情報１５０は，公開キーについての情報を含むことが望ましい。また，サーバ２００は，既存の公開キーをアップデートするための情報として，最新の公開キー情報と，この公開キー情報についてのデジタル署名とを含む最新の認証情報を伝送する。このとき，サーバ２００は，クライアント１００から受信した認証情報を利用してクライアントを確認し，クライアントのための認証情報を検索して最新の認証情報を生成した後に送信する。」が記載され，また，段落【００２４】には，「サーバは，クライアントから受信した認証情報を利用して，クライアントのための最新の認証情報を生成して伝送する（Ｓ２０４）。このステップで，サーバは，クライアントの認証情報を基盤にクライアントの現在状態を把握し，クライアントが認証できる情報を検索して伝送する。このとき，サーバが伝送する最新の認証情報は，クライアントのための最新の公開キー情報と，この公開キー情報についてのデジタル署名とを含むことが望ましい。」が記載されており，これらの記載からすると，クライアントから受信した認証情報を基盤に最新の認証情報を検索して生成することは把握できるものの，「クライアントのための認証情報を検索することによって最新公開キー情報とデジタル署名を含む最新の認証情報を生成」するための情報処理や，「現在公開キー情報」，「クライアントのための認証情報」，「最新公開キー情報」が当該「検索」を実行するための情報処理にどのように関与しているかについては，当該技術分野の技術常識を考慮しても，当業者が発明の実施をすることができる程度に明確かつ十分に記載されているとは言えない。
　
　また，上記と同様，本願発明の詳細な説明は，平成２７年１月２１日付け手続補正書により補正された特許請求の範囲請求項２−１２に係る発明の実施をすることができる程度に明確かつ十分に記載されているとは言えない。
　
（２）　したがって，この出願の発明の詳細な説明は，当業者が請求項１−１２に係る発明を実施することができる程度に明確かつ十分に記載したものでない。
　
２　請求人の主張について
　
（１）　なお，請求人は，上記平成２６年６月４日付け意見書において，
　
「４．拒絶理由について
…（中略）…
＜理由２＞
・特許法第３６条第４項第１号について
ａ「どのように現在公開キー情報を含む認証情報から最新公開キー情報を含む最新の認証情報を生成するのか」について
　まず，段落〔００２９〕から「または最新の認証情報に新たな内容がないと判断されれば」という記載を削除しました。これにより，「最新の認証情報に新たな内容がないと判断され」る状況が発生することがなくなりました。
　また，認証情報から最新公開キー情報を含む最新の認証情報を生成する情報処理は，例えば，認証情報に所定値を加えたり，認証情報をシードにして乱数を発生させることで新しい認証情報を作成します。
　以上により，補正後の請求項１〜１２に係る発明は，当業者が請求項１−１２に係る発明の実施をすることができる程度に明確かつ十分に記載したものになったと思料します。
　
…（後略）…」　
　
と主張している。
　
（２）　しかしながら，請求人が主張する「認証情報から最新公開キー情報を含む最新の認証情報を生成する情報処理は，例えば，認証情報に所定値を加えたり，認証情報をシードにして乱数を発生させることで新しい認証情報を作成します。」については本願明細書に記載されたものではなく，また，「現在公開キー情報」，「最新公開キー情報」がどのように関与しているかも不明であるから，本願明細書の発明の詳細な説明の段落【００２１】，【００２４】からは，クライアントから受信した認証情報を基盤に最新の認証情報を検索して生成することが把握されるにとどまる。それ故に，仮に請求人の主張する上記事項が当該技術分野の技術常識だとしても，当業者が発明の実施をすることができる程度に明確かつ十分に記載されているとはいえない。
　よって，「どのように現在公開キー情報を含む認証情報から最新公開キー情報を含む最新の認証情報を生成するのか」については，依然として情報処理が不明であり，請求人の当該主張についても，採用することはできない。
　
３　理由２（記載不備）についてのむすび 
　
　したがって，本願明細書の発明の詳細な説明は，平成２７年１月２１日付け手続補正書により補正された特許請求の範囲請求項１−１２に係る発明について，当業者がその実施をすることができる程度に明確かつ十分に記載したものではない。
　
　
第５　むすび　
　
　以上のとおり，本願の請求項１に係る発明は，特許法第２９条第２項の規定により特許を受けることができないものであるから，その余の請求項に係る発明について検討するまでもなく，本願は拒絶すべきものである。
　また，本願明細書の発明の詳細な説明は，特許法第３６条第４項第１号に規定する要件を満たしておらず，本願は拒絶すべきものである。
　
　よって，結論のとおり審決する。