2018-006820

特願２０１６－５２８６６６「更新プログラム及び方法、及び、管理プログラム及び方法」拒絶査定不服審判事件〔平成２７年１２月２３日国際公開、ＷＯ２０１５／１９３９４５、請求項の数（１７）〕について、次のとおり審決する。

【結　論】 原査定を取り消す。 本願の発明は、特許すべきものとする。

【理　由】 第１　手続の経緯 本願は，２０１４年６月１６日を国際出願日とする出願であって，平成２９年６月３０日付けで拒絶理由通知がされ，平成２９年９月１１日に意見書が提出されるとともに手続補正がされ，平成３０年２月９日付けで拒絶査定（原査定）がされ，これに対し，平成３０年５月１８日に拒絶査定不服審判の請求がされると同時に手続補正がされ，平成３０年１２月２６日付けで当審より拒絶理由通知（以下，「当審拒絶理由通知１」という。）がされ，平成３１年３月５日に意見書が提出されるとともに手続補正がされ，令和元年５月２８日付けで当審より拒絶理由通知（以下，「当審拒絶理由通知２」という。）がされ，令和元年６月２０日に意見書が提出されるとともに手続補正がされたものである。 第２　原査定の概要 原査定（平成３０年２月９日付け拒絶査定）の概要は次のとおりである。 本願請求項１－１８に係る発明は，以下の引用文献１ないし４に基づいて，その発明の属する技術の分野における通常の知識を有する者（以下，「当業者」という。）が容易に発明できたものであるから，特許法第２９条第２項の規定により特許を受けることができない。 引用文献等一覧 １．特開２００６－６０７７９号公報 ２．盛合志帆，インターネットにおけるコンテンツ保護技術，映像情報メディア学会誌，映像情報メディア学会，2005年4月1日，Vol. 59, No. 4，pp. 532-537 ３．特開２００９－１１８３５０号公報 ４．相澤英孝，他，暗号と特許，日本銀行金融研究所ディスカッション・ペーパー・シリーズ，日本銀行金融研究所，１９９８年　６月，Ｎｏ．９８－Ｊ－９，ｐｐ．３４－３６，７９－８２ 第３　当審拒絶理由の概要 当審でなされた拒絶理由の概要は次のとおりである。 １．当審拒絶理由通知１ （１）（明確性）この出願は，特許請求の範囲の記載が，特許法第３６条第６項第２号に規定する要件を満たしていない。 （２）（サポート要件）この出願は，特許請求の範囲の記載が，特許法第３６条第６項第１号に規定する要件を満たしていない。 （３）（委任省令要件）この出願は，発明の詳細な説明の記載が，特許法第３６条第４項第１号に規定する要件を満たしていない。 （４）（進歩性）本願請求項１－１８に係る発明は，以下の引用文献ＡないしＧに基づいて，当業者が容易に発明できたものであるから，特許法第２９条第２項の規定により特許を受けることができない。 引用文献等一覧 Ａ．特開２００６－６０７７９号公報（原査定の引用文献１） Ｂ．盛合志帆，インターネットにおけるコンテンツ保護技術，映像情報メディア学会誌，映像情報メディア学会，2005年4月1日，Vol. 59, No. 4，pp. 532-537（原査定の引用文献２） Ｃ．特開２００９－１１８３５０号公報（原査定の引用文献３） Ｄ．相澤英孝，他，暗号と特許，日本銀行金融研究所ディスカッション・ペーパー・シリーズ，日本銀行金融研究所，１９９８年　６月，Ｎｏ．９８－Ｊ－９，ｐｐ．３４－３６，７９－８２（原査定の引用文献４） Ｅ．特開２００１－３２０３５６号公報 Ｆ．特開２００２－２９７５４８号公報 Ｇ．特開２００１－１１１５３８号公報 ２．当審拒絶理由通知２ （１）本件出願は，請求項１－１７に係る特許請求の範囲の記載が，特許法第３６条第６項第２号に規定する要件を満たしていない。 第４　本願発明 本願請求項１－１７に係る発明（以下，それぞれ「本願発明１」－「本願発明１７」という。）は，令和元年６月２０日付けの手続補正で補正された特許請求の範囲の請求項１－１７に記載された事項により特定される発明であり，以下のとおりの発明である。 「　【請求項１】 メッセージを暗号化して送受信するサーバとのセキュアな通信において，暗号化された該メッセージに対して，第１の公開鍵証明書に対応する第１のクライアント秘密鍵による電子署名を付与し，有効期限付きの該第１の公開鍵証明書を初めて用いた，該サーバへの接続のときに，該サーバに対し一時的に利用する一時サーバ公開鍵を要求し， 一時的に利用する一時クライアント鍵ペアを生成し，該一時クライアント鍵ペアのうち一時クライアント秘密鍵と前記サーバから前記セキュアな通信により受信した前記一時サーバ公開鍵とで一時共通鍵を生成し， 前記セキュアな通信において，前記一時クライアント秘密鍵とペアとなる一時クライアント公開鍵と，生成した前記一時共通鍵で暗号化した第２の公開鍵証明書に対応付けられるクライアント公開鍵とを，前記第１の公開鍵証明書を用い，前記第１の公開鍵証明書に対応する前記第１のクライアント秘密鍵による前記電子署名を付与して前記サーバへ送信することで，該第２の公開鍵証明書の発行要求を行い， 前記サーバから，前記一時共通鍵で暗号化された前記第２の公開鍵証明書を前記セキュアな通信により受領し，該一時共通鍵で該第２の公開鍵証明書を復号し， 前記第１の公開鍵証明書の有効期限が過ぎた場合は，前記セキュアな通信において，前記第２の公開鍵証明書に対応する第２のクライアント秘密鍵による電子署名をメッセージに付与して前記サーバと通信する 処理をコンピュータに実行させる更新プログラム。 【請求項２】 前記一時クライアント公開鍵を前記サーバに送信することで，該サーバとの間で一時共通鍵が共有され，前記第２の公開鍵証明書に対応付けられるクライアント公開鍵を送信することで，該サーバに前記第２の公開鍵証明書の発行要求を行うことを特徴とする請求項１記載の更新プログラム。 【請求項３】 前記第２の公開鍵証明書の取得後においても，前記第１の公開鍵証明書は前記有効期限まで使用可能とし，該有効期限が過ぎたことにより該第２の公開鍵証明書へと切り替えられ前記サーバへ初めて送出したタイミングで，次の公開鍵証明書の発行要求を行う請求項１記載の更新プログラム。 【請求項４】 メッセージを暗号化して送受信するサーバとのセキュアな通信において，暗号化された該メッセージに対して，第１の公開鍵証明書に対応する第１のクライアント秘密鍵による電子署名を付与し，有効期限付きの該第１の公開鍵証明書を初めて用いた，該サーバへの接続のときに，該サーバに対し一時的に利用する一時サーバ公開鍵を要求し， 一時的に利用する一時クライアント鍵ペアを生成し，該一時クライアント鍵ペアのうち一時クライアント秘密鍵と前記サーバから前記セキュアな通信により受信した前記一時サーバ公開鍵とで一時共通鍵を生成し， 前記セキュアな通信において，前記一時クライアント秘密鍵とペアとなる一時クライアント公開鍵と，生成した前記一時共通鍵で暗号化した，第２の公開鍵証明書に対応付けられるクライアント公開鍵とをメッセージに含め，前記第１の公開鍵証明書を用い，前記第１の公開鍵証明書に対応する前記第１のクライアント秘密鍵による前記電子署名を付与して前記サーバへ送信することで，該第２の公開鍵証明書の発行要求を行い， 前記サーバから，前記一時共通鍵で暗号化された前記第２の公開鍵証明書を前記セキュアな通信により受領し，該一時共通鍵で該第２の公開鍵証明書を復号し， 前記第１の公開鍵証明書の有効期限が過ぎた場合は，前記セキュアな通信において，前記第２の公開鍵証明書に対応する第２のクライアント秘密鍵による電子署名をメッセージに付与して前記サーバと通信する 処理をコンピュータが行う更新方法。 【請求項５】 プロセッサと， 要求元及びデータの正当性の確認に用いられる第１の公開鍵証明書を記憶した記憶部と， を有する端末装置であって， 前記プロセッサは， メッセージを暗号化して送受信するサーバとのセキュアな通信において，暗号化された該メッセージに対して，前記第１の公開鍵証明書に対応する第１のクライアント秘密鍵による電子署名を付与し，有効期限付きの該第１の公開鍵証明書を初めて用いた，該サーバへの接続のときに，該サーバに対し一時的に利用する一時サーバ公開鍵を要求し， 一時的に利用する一時クライアント鍵ペアを生成し，該一時クライアント鍵ペアのうち一時クライアント秘密鍵と前記サーバから前記セキュアな通信により受信した前記一時サーバ公開鍵とで一時共通鍵を生成し， 前記セキュアな通信において，前記一時クライアント秘密鍵とペアとなる一時クライアント公開鍵と，生成した前記一時共通鍵で暗号化した，第２の公開鍵証明書に対応付けられるクライアント公開鍵とを，前記第１の公開鍵証明書を用い，前記第１の公開鍵証明書に対応する前記第１のクライアント秘密鍵による前記電子署名を付与して前記サーバへ送信することで，該第２の公開鍵証明書の発行要求を行い 前記サーバから，前記一時共通鍵で暗号化された前記第２の公開鍵証明書を前記セキュアな通信により受領し，該一時共通鍵で該第２の公開鍵証明書を復号し， 前記第１の公開鍵証明書の有効期限が過ぎた場合は，前記セキュアな通信において，前記第２の公開鍵証明書に対応する第２のクライアント秘密鍵による電子署名をメッセージに付与して前記サーバと通信する端末装置。 【請求項６】 データを送信したクライアントの正当性と，該データの正当性の確認に用いられる公開鍵証明書の管理プログラムであって， メッセージを暗号化して送受信する前記クライアントとのセキュアな通信において，暗号化された該メッセージに対して，第１の公開鍵証明書に対応する第１のクライアント秘密鍵による電子署名を付与し，有効期限付きの該第１の公開鍵証明書を初めて用いた，該クライアントからの接続のときに，一時的に利用する一時サーバ公開鍵を新たに生成し，前記クライアントに送信し， 前記セキュアな通信により，前記クライアントから，前記第１の公開鍵証明書を用い，一時クライアント公開鍵と，前記一時サーバ公開鍵と一時クライアント秘密鍵から生成された一時共通鍵によって暗号化されたクライアント公開鍵とを含む第２の公開鍵証明書の発行要求を受信し， 前記一時サーバ公開鍵とペアとなる一時サーバ秘密鍵と，前記クライアントから受信した前記一時クライアント公開鍵とで前記一時共通鍵を生成し，生成した該一時共通鍵を用いて前記クライアント公開鍵を復号し， 前記セキュアな通信による前記クライアントからの第２の公開鍵証明書の発行要求に対して，復号した前記クライアント公開鍵を用いて該第２の公開鍵証明書を生成し，該第２の公開鍵証明書を前記一時共通鍵で暗号化して該クライアントに送信する 処理をコンピュータに実行させる管理プログラム。 【請求項７】 クライアント毎に，前記第１の公開鍵証明書と，該第１の公開鍵証明書を更新する前記第２の公開鍵証明書とを関連付けてテーブルに記憶する 処理を前記コンピュータに実行させる請求項６記載の管理プログラム。 【請求項８】 前記発行要求の回数をカウントし，該発行要求の回数が規定値を超えたら，不正な要求であると判断してエラーにする 処理を前記コンピュータに実行させる請求項６記載の管理プログラム。 【請求項９】 前記クライアントから，前記第２の公開鍵証明書に対応する，暗号化された前記クライアント公開鍵を受信し， 前記クライアント公開鍵を前記一時共通鍵で復号し， 復号された前記クライアント公開鍵に対して前記第２の公開鍵証明書を生成する 処理を前記コンピュータに実行させる請求項６記載の管理プログラム。 【請求項１０】 データを送信したクライアントの正当性と，データの正当性の確認に用いられる公開鍵証明書の管理方法であって， メッセージを暗号化して送受信する前記クライアントとのセキュアな通信において，暗号化された該メッセージに対して，第１の公開鍵証明書に対応する第１のクライアント秘密鍵による電子署名を付与し，有効期限付きの該第１の公開鍵証明書を初めて用いた，該クライアントからの接続のときに，一時的に利用する一時サーバ公開鍵を新たに生成し，前記クライアントに送信し， 前記セキュアな通信により，前記クライアントから，前記第１の公開鍵証明書を用い，一時クライアント公開鍵と，前記一時サーバ公開鍵と一時クライアント秘密鍵から生成された一時共通鍵によって暗号化されたクライアント公開鍵とを含む第２の公開鍵証明書の発行要求を受信し， 前記一時サーバ公開鍵とペアとなる一時サーバ秘密鍵と，前記クライアントから受信した前記一時クライアント公開鍵とで前記一時共通鍵を生成し，生成した該一時共通鍵を用いて前記クライアント公開鍵を復号し， 前記セキュアな通信による前記クライアントからの第２の公開鍵証明書の発行要求に対して，復号した前記クライアント公開鍵を用いて該第２の公開鍵証明書を生成し，該第２の公開鍵証明書を前記一時共通鍵で暗号化して該クライアントに送信する 処理をコンピュータが行う管理方法。 【請求項１１】 プロセッサと， データを送信したクライアントの正当性と，該データの正当性の確認に用いられる第１の公開鍵証明書を記憶する記憶部とを有するサーバであって， 前記プロセッサは， メッセージを暗号化して送受信する前記クライアントとのセキュアな通信において，暗号化された該メッセージに対して，第１の公開鍵証明書に対応する第１のクライアント秘密鍵による電子署名を付与し，有効期限付きの該第１の公開鍵証明書を初めて用いた，該クライアントからの接続のときに，一時的に利用する一時サーバ公開鍵を新たに生成し，前記クライアントに送信し， 前記セキュアな通信により，前記クライアントから，前記第１の公開鍵証明書を用い，一時クライアント公開鍵と，前記一時サーバ公開鍵と一時クライアント秘密鍵から生成された一時共通鍵によって暗号化されたクライアント公開鍵とを含む第２の公開鍵証明書の発行要求を受信し， 前記一時サーバ公開鍵とペアとなる一時サーバ秘密鍵と，前記クライアントから受信した前記一時クライアント公開鍵とで前記一時共通鍵を生成し，生成した該一時共通鍵を用いて前記クライアント公開鍵を復号し， 前記セキュアな通信により，前記クライアントからの第２の公開鍵証明書の発行要求に対して，復号した前記クライアント公開鍵を用いて該第２の公開鍵証明書を生成し，該第２の公開鍵証明書を前記一時共通鍵で暗号化して該クライアントに送信する 処理を実行するサーバ。 【請求項１２】 メッセージを暗号化して送受信するサーバとのセキュアな通信において，暗号化された該メッセージに対して，第１の公開鍵証明書に対応する第１のクライアント秘密鍵による電子署名を付与し，有効期限付きの該第１の公開鍵証明書を初めて用いた，該サーバへの接続のときに，該サーバとでそれぞれの一時公開鍵を交換し，クライアントの一時秘密鍵と該サーバの一時公開鍵とで一時共通鍵を生成し， 前記セキュアな通信において，前記サーバに対し，前記第１の公開鍵証明書を用い，生成した前記一時共通鍵で暗号化したクライアント公開鍵を含む第２の公開鍵証明書の発行要求を行い， 前記セキュアな通信において，前記クライアント公開鍵を用いて生成され，前記一時共通鍵で暗号化された前記第２の公開鍵証明書を受領し， 前記第１の公開鍵証明書の有効期限が過ぎた場合は，前記セキュアな通信において，前記一時共通鍵で復号した前記第２の公開鍵証明書に対応する第２のクライアント秘密鍵による電子署名をメッセージに付与して前記サーバとセキュアな通信を行う 処理をコンピュータに実行させる更新プログラム。 【請求項１３】 メッセージを暗号化して送受信するサーバとのセキュアな通信において，暗号化された該メッセージに対して，第１の公開鍵証明書に対応する第１のクライアント秘密鍵による電子署名を付与し，有効期限付きの該第１の公開鍵証明書を初めて用いた，該サーバへの接続のときに，該サーバとでそれぞれの一時公開鍵を交換し，クライアントの一時秘密鍵と該サーバの一時公開鍵とで一時共通鍵を生成し， 前記セキュアな通信において，前記サーバに対し，前記第１の公開鍵証明書を用い，生成した前記一時共通鍵で暗号化したクライアント公開鍵を含む第２の公開鍵証明書の発行要求を行い， 前記セキュアな通信において，前記クライアント公開鍵を用いて生成され，前記一時共通鍵で暗号化された前記第２の公開鍵証明書を受領し， 前記第１の公開鍵証明書の有効期限が過ぎた場合は，前記一時共通鍵で復号した前記第２の公開鍵証明書を用いて前記サーバとセキュアな通信を行う 処理をコンピュータが行う更新方法。 【請求項１４】 プロセッサと， 要求元及びデータの正当性の確認に用いられる第１の公開鍵証明書を記憶した記憶部と， を有する端末装置であって， 前記プロセッサは， メッセージを暗号化して送受信するサーバとのセキュアな通信において，暗号化された該メッセージに対して，前記第１の公開鍵証明書に対応する第１のクライアント秘密鍵による電子署名を付与し，有効期限付きの該第１の公開鍵証明書を初めて用いた，該サーバへの接続のときに，該サーバとでそれぞれの一時公開鍵を交換し，クライアントの一時秘密鍵と該サーバの一時公開鍵とで一時共通鍵を生成し， 前記セキュアな通信において，前記サーバに対し，前記第１の公開鍵証明書を用い，生成した前記一時共通鍵で暗号化したクライアント公開鍵を含む第２の公開鍵証明書の発行要求を行い， 前記セキュアな通信において，前記クライアント公開鍵を用いて生成され，前記一時共通鍵で暗号化された前記第２の公開鍵証明書を受領し， 前記第１の公開鍵証明書の有効期限が過ぎた場合は，前記一時共通鍵で復号した前記第２の公開鍵証明書を用いて前記サーバとセキュアな通信を行う端末装置。 【請求項１５】 データを送信したクライアントの正当性と，該データの正当性の確認に用いられる公開鍵証明書の管理プログラムであって， メッセージを暗号化して送受信する前記クライアントとのセキュアな通信において，暗号化された該メッセージに対して，第１の公開鍵証明書に対応する第１のクライアント秘密鍵による電子署名を付与し，有効期限付きの該第１の公開鍵証明書を初めて用いた，該クライアントからの接続のときに，該クライアントとでそれぞれの一時公開鍵を交換し， サーバの一時秘密鍵と該クライアントの一時公開鍵とで一時共通鍵を生成し， 前記クライアントからの，前記第１の公開鍵証明書を用い，該クライアントの一時秘密鍵と前記サーバの一時公開鍵とで生成した一時共通鍵で暗号化されたクライアント公開鍵を含む第２の公開鍵証明書の発行要求に対して，前記サーバの一時秘密鍵と該クライアントの一時公開鍵とで生成した前記一時共通鍵で該クライアント公開鍵を復元して，該第２の公開鍵証明書を生成し，該第２の公開鍵証明書を前記一時共通鍵で暗号化して該クライアントに送信する 処理をコンピュータに実行させる管理プログラム。 【請求項１６】 データを送信したクライアントの正当性と，データの正当性の確認に用いられる公開鍵証明書の管理方法であって， メッセージを暗号化して送受信する前記クライアントとのセキュアな通信において，暗号化された該メッセージに対して，第１の公開鍵証明書に対応する第１のクライアント秘 密鍵による電子署名を付与し，有効期限付きの該第１の公開鍵証明書を初めて用いた，該クライアントからの接続のときに，該クライアントとでそれぞれの一時公開鍵を交換し， サーバの一時秘密鍵と該クライアントの一時公開鍵とで一時共通鍵を生成し， 前記クライアントからの，前記第１の公開鍵証明書を用い，該クライアントの一時秘密鍵と前記サーバの一時公開鍵とで生成した一時共通鍵で暗号化されたクライアント公開鍵を含む第２の公開鍵証明書の発行要求に対して，前記サーバの一時秘密鍵と該クライアントの一時公開鍵とで生成した前記一時共通鍵で該クライアント公開鍵を復元して，該第２の公開鍵証明書を生成し，該第２の公開鍵証明書を前記一時共通鍵で暗号化して該クライアントに送信する 処理をコンピュータが行う管理方法。 【請求項１７】 プロセッサと， データを送信したクライアントの正当性と，該データの正当性の確認に用いられる第１の公開鍵証明書を記憶する記憶部とを有するサーバであって， 前記プロセッサは， メッセージを暗号化して送受信する前記クライアントとのセキュアな通信において，暗号化された該メッセージに対して，第１の公開鍵証明書に対応する第１のクライアント秘密鍵による電子署名を付与し，有効期限付きの該第１の公開鍵証明書を初めて用いた，該クライアントからの接続のときに，該クライアントとでそれぞれの一時公開鍵を交換し， サーバの一時秘密鍵と該クライアントの一時公開鍵とで一時共通鍵を生成し， 前記クライアントからの，前記第１の公開鍵証明書を用い，該クライアントの一時秘密鍵と前記サーバの一時公開鍵とで生成した一時共通鍵で暗号化されたクライアント公開鍵を含む第２の公開鍵証明書の発行要求に対して，前記サーバの一時秘密鍵と該クライアントの一時公開鍵とで生成した前記一時共通鍵で該クライアント公開鍵を復元して，該第２の公開鍵証明書を生成し，該第２の公開鍵証明書を前記一時共通鍵で暗号化して該クライアントに送信する 処理を実行するサーバ。」 第５　引用文献，引用発明等 １．引用文献１について 原査定の拒絶の理由に引用され，当審拒絶理由通知１にも引用された引用文献１（特開２００６－６０７７９号公報）には，図面とともに次の事項が記載されている。（下線は当審により付与。以下同様。） Ａ　「【０００４】 ここで，このＳＳＬに従った相互認証を行う場合の通信手順について，認証処理の部分に焦点を当てて説明する。図２１は，通信装置Ａと通信装置ＢとがＳＳＬに従った相互認証を行う際に各装置において実行する処理のフローチャートを，その処理に用いる情報と共に示す図である。 図２１に示すように，ＳＳＬに従った相互認証を行う際には，まず双方の通信装置に，ルート鍵証明書及び，私有鍵と公開鍵証明書を記憶させておく必要がある。この私有鍵は，認証局（ＣＡ：certificate authority）が各装置に対して発行した私有鍵であり，公開鍵証明書は，その私有鍵と対応する公開鍵にＣＡがデジタル署名を付してデジタル証明書としたものである。また，ルート鍵証明書は，ＣＡがデジタル署名に用いたルート私有鍵と対応するルート鍵に，デジタル署名を付してデジタル証明書としたものである。 【０００５】 図２２にこれらの関係を示す。 図２２（ａ）に示すように，公開鍵Ａは，私有鍵Ａを用いて暗号化された文書を復号化するための鍵本体と，その公開鍵の発行者（ＣＡ）や有効期間等の情報を含む書誌情報とによって構成される。そして，ＣＡは，鍵本体や書誌情報が改竄されていないことを示すため，公開鍵Ａをハッシュ処理して得たハッシュ値を，ルート私有鍵を用いて暗号化し，デジタル署名としてクライアント公開鍵に付す。またこの際に，デジタル署名に用いるルート私有鍵の識別情報を署名鍵情報として公開鍵Ａの書誌情報に加える。そして，このデジタル署名を付した公開鍵証明書が，公開鍵証明書Ａである。 【０００６】 この公開鍵証明書Ａを認証処理に用いる場合には，ここに含まれるデジタル署名を，ルート私有鍵と対応する公開鍵であるルート鍵の鍵本体を用いて復号化する。この復号化が正常に行われれば，デジタル署名が確かにＣＡによって付されたことがわかる。また，公開鍵Ａの部分をハッシュ処理して得たハッシュ値と，復号して得たハッシュ値とが一致すれば，鍵自体も損傷や改竄を受けていないことがわかる。 また，受信したデータを公開鍵Ａを用いて正常に復号化できれば，そのデータは，私有鍵Ａの持ち主から送信されたものであることがわかる。 【０００７】 ここで，認証を行うためには，ルート鍵を予め記憶しておく必要があるが，このルート鍵も，図２２（ｂ）に示すように，ＣＡがデジタル署名を付したルート鍵証明書として記憶しておく。このルート鍵証明書は，自身に含まれる公開鍵でデジタル署名を復号化可能な自己署名形式である。そして，ルート鍵を使用する際に，そのルート鍵証明書に含まれる鍵本体を用いてデジタル署名を復号化し，ルート鍵をハッシュ処理して得たハッシュ値と比較する。これが一致すれば，ルート鍵が破損等していないことを確認できるのである。 【０００８】 図２１のフローチャートの説明に入る。なお，この図において，２本のフローチャート間の矢印は，データの転送を示し，送信側は矢印の根元のステップで転送処理を行い，受信側はその情報を受信すると矢印の先端のステップの処理を行うものとする。また，各ステップの処理が正常に完了しなかった場合には，その時点で認証失敗の応答を返して処理を中断するものとする。相手から認証失敗の応答を受けた場合，処理がタイムアウトした場合等も同様である。 【０００９】 ここでは，通信装置Ａが通信装置Ｂに通信を要求するものとするが，この要求を行う場合，通信装置ＡのＣＰＵは，所要の制御プログラムを実行することにより，図２１の左側に示すフローチャートの処理を開始する。そして，ステップＳ１１１で通信装置Ｂに対して接続要求を送信する。 一方通信装置ＢのＣＰＵは，この接続要求を受信すると，所要の制御プログラムを実行することにより，図２１の右側に示すフローチャートの処理を開始する。そして，ステップＳ１２１で第１の乱数を生成し，これを私有鍵Ｂを用いて暗号化する。そして，ステップＳ１２２でその暗号化した第１の乱数と公開鍵証明書Ｂとを通信装置Ａに送信する。 【００１０】 通信装置Ａ側では，これを受信すると，ステップＳ１１２でルート鍵証明書を用いて公開鍵証明書Ｂの正当性を確認する。 そして確認ができると，ステップＳ１１３で，受信した公開鍵証明書Ｂに含まれる公開鍵Ｂを用いて第１の乱数を復号化する。ここで復号化が成功すれば，第１の乱数は確かに公開鍵証明書Ｂの発行対象から受信したものだと確認できる。 その後，ステップＳ１１４でこれとは別に第２の乱数及び共通鍵の種を生成する。共通鍵の種は，例えばそれまでの通信でやり取りしたデータに基づいて作成することができる。そして，ステップＳ１１５で第２の乱数を私有鍵Ａを用いて暗号化し，共通鍵の種を公開鍵Ｂを用いて暗号化し，ステップＳ１１６でこれらを公開鍵証明書Ａと共にサーバ装置に送信する。共通鍵の種の暗号化は，通信相手以外の装置に共通鍵の種を知られないようにするために行うものである。 また，次のステップＳ１１７では，ステップＳ１１４で生成した共通鍵の種から以後の通信の暗号化に用いる共通鍵を生成する。 【００１１】 通信装置Ｂ側では，通信装置ＡがステップＳ１１６で送信してくるデータを受信すると，ステップＳ１２３でルート鍵証明書を用いて公開鍵証明書Ａの正当性を確認する。そして確認ができると，ステップＳ１２４で，受信した公開鍵証明書Ａに含まれる公開鍵Ａを用いて第２の乱数を復号化する。ここで復号化が成功すれば，第２の乱数は確かに公開鍵証明書Ａの発行対象から受信したものだと確認できる。 その後，ステップＳ１２５で私有鍵Ｂを用いて共通鍵の種を復号化する。ここまでの処理で，通信装置Ａ側と通信装置Ｂ側に共通鍵の種が共有されたことになる。そして，この共通鍵の種は，生成した通信装置Ａと，私有鍵Ｂを持つ通信装置Ｂ以外の装置が知ることはない。ここまでの処理が成功すると，通信装置Ｂ側でもステップＳ１２６で復号化で得た共通鍵の種から以後の通信の暗号化に用いる共通鍵を生成する。 【００１２】 そして，通信装置Ａ側のステップＳ１１７と通信装置Ｂ側のステップＳ１２６の処理が終了すると，相互に認証の成功と以後の通信に使用する暗号化方式とを確認し，生成した共通鍵を用いてその暗号化方式で以後の通信を行うものとして認証に関する処理を終了する。なお，この確認には，通信装置Ｂからの認証が成功した旨の応答も含むものとする。以上の処理によって互いに通信を確立し，以後はステップＳ１１７又はＳ１２６で生成した共通鍵を用い，共通鍵暗号方式でデータを暗号化して通信を行うことができる。 【００１３】 このような処理を行うことにより，通信装置Ａと通信装置Ｂが互いに相手を認証した上で安全に共通鍵を共有することができ，通信を安全に行う経路を確立することができる。 なお，片方向認証を採用し，例えば通信装置Ｂが通信要求元の通信装置Ａを認証するのみでよいのであれば，図２１に示した認証処理において，第１の乱数の暗号化及び送信を省略することができる。この場合でも，共通鍵の種を通信装置Ａから通信装置Ｂに安全に送信するために，通信装置Ｂの公開鍵Ｂを用いた暗号化を行うとよいが，公開鍵Ｂに付されたデジタル署名の正当性を確認することは行わなくてよい。そして，この場合の認証処理は，図２３に示すように簡略化されたものになる。すなわち，通信装置Ａ側のステップＳ１１２及びＳ１１３の処理は不要となり，通信装置Ｂ側のステップＳ１２１の処理も不要となる。また，その他の処理も一部簡略化することができる。 【００１４】 以上のような認証処理においては，公開鍵で暗号化された内容は対応する私有鍵を持つ装置でしか復号できず，また，私有鍵で暗号化された内容は対応する公開鍵でしか復号できないことを利用して，通信相手が公開鍵証明書にその発行先として記載されている装置である（又はその装置の利用者が公開鍵証明書にその発行先として記載されている利用者である）と認証することになる。」 Ｂ　「【００１６】 ところで，公開鍵暗号方式においては，鍵長にもよるが，時間をかければ公開鍵から私有鍵を導くことができる。そして，私有鍵がわかってしまえば，第３者がその私有鍵の持ち主になりすますことが可能になるので，認証の確実性や通信の安全性が保たれない。そこで，上述のように鍵に有効期限を設け，所定期間毎に鍵のセットを更新するというセキュリティポリシーを採用するユーザが増えている。このため，例えば上記のような相互認証を利用した遠隔管理システム等を提供する場合には，顧客に対し，鍵の更新が可能なシステムであるという保証を行う必要が生じている。 【００１７】 また，第３者機関により公開鍵証明書を発行するサービスも提供されているが，このような機関が発行する公開鍵証明書は，安全性を考慮し，有効期間が１～３年程度と短い。そして，この期間が過ぎた証明書では認証が失敗するようにしてある。そこで，このような第３者機関が発行した公開鍵証明書を利用しようとする場合には，有効期間が経過する前に証明書を新しいものに更新する必要がある。 なお，上述した特許文献３及び４に記載の技術は，他の装置から受信したその送信元装置の公開鍵を，単にその送信元装置の情報と対応させて管理したり有効性を検証したりすることが記載されているのみであり，新たな公開鍵証明書の発行については特に記載されていない。 【００１８】 公開鍵証明書を用いて認証を受ける通信装置にこのような更新用の新しい公開鍵証明書を配布する方式としては，使用中の公開鍵証明書の有効期限が切れる前に，ＣＡが通信装置に対して新たな公開鍵証明書と私有鍵を発行し，これらとルート鍵証明書のセットを，ＣＡあるいはそれに代わる管理装置が，使用中の公開鍵証明書を用いて確立したＳＳＬによる通信経路で更新対象の装置に送信して設定させる方式が考えられる。 このようにすれば，通信装置が認証に使用する公開鍵証明書等を，有効期限が切れる前に自動的に更新することができるので，ユーザの手を煩わせることなく，通信装置を認証可能な状態に保つことができる。また，インターネットを介して送信を行う場合でも，安全な通信経路を確保して公開鍵証明書等の転送を行うことができる。 【００１９】 しかしながら，ＳＳＬを用いて安全な通信経路を確保したとしても，インターネットを経由して通信する場合，どのようなサーバを介して情報が転送されるかわからないのであるから，転送する情報を盗み見られたり，改竄されたりする可能性はゼロではない。そして，万一私有鍵を盗み見られてしまうと，なりすましが可能になってしまうので，このような危険性は例え僅かなものであっても排除したいという要求があった。 この発明は，このような要求に応え，通信装置が認証に使用する公開鍵証明書を自動的に更新することを可能としながら，私有鍵の漏洩の可能性を低下させ，安全な更新を実現させることを目的とする。」 Ｃ　「【００６７】 まず，図１０のシーケンス図に，更新処理全体の流れを示す。 図１０に示すとおり，この処理においては，管理対象機器４０は，管理装置３０との間の認証処理に使用する公開鍵証明書の有効期限の一定期間前（例えば１ヶ月前）になったことを検出すると（Ｓ１１），公開鍵証明書の更新時期になったと判断し，以下の証明書更新に関する処理を行う。なお，公開鍵更新に関する処理を開始する条件は，別の基準で定めるようにしてもよい。 そして，ステップＳ１２以下においては，まず鍵生成部４８の機能により，新たな公開鍵と私有鍵のペアを，更新用鍵ペアとして生成する（Ｓ１２）。その後，管理装置３０に通信を要求して通常通り認証処理に使用するものとして設定されている証明書を用いた認証処理を行い（Ｓ１３），認証が成功したら，鍵通知部４９の機能により，ステップＳ１２で生成した新たな公開鍵を更新用公開鍵として記載した自己生成公開鍵通知を管理装置３０に送信する（Ｓ１４）。なお，自己生成公開鍵通知は，管理装置３０に対して，送信した公開鍵にデジタル署名を付して公開鍵証明書を発行することを要求するコマンドであると考えることもできる。また，ステップＳ１３での認証は，相互認証が好ましいが，少なくとも管理装置３０が管理対象機器４０を認証できれば，相互認証でも片方向認証でも構わない。 【００６８】 管理装置３０は，管理対象機器から自己生成公開鍵通知を受信すると，要求通り公開鍵証明書を発行してよいかどうか判断するため，証明書審査部３６の機能により，通知の送信元である管理対象機器４０を審査する（Ｓ１５）。この審査は，受信した公開鍵自体の情報の他，ステップＳ１３での認証処理時に管理対象機器４０から受信した公開鍵証明書に記載されている事項も用いて行うが，その内容に付いては後に詳述する。 【００６９】 そして，管理対象機器４０が審査に合格した場合，証明書発行部３７の機能により，受信した更新用公開鍵にデジタル署名を付して更新用公開鍵証明書を作成して発行し，これを証明書記憶部３４のデータベースに登録する（Ｓ１６）。そして，作成した更新用公開鍵証明書を管理対象機器４０に送信する（Ｓ１７）。この送信は，ステップＳ１４で受信したコマンドに対する応答であると考えることができる。また，更新用公開鍵証明書の有効期限は，通常は少なくとも管理対象装置４０に現在設定されている証明書の有効期限よりは後である。 そして，更新用公開鍵証明書を受信した管理対象機器４０は，その受信した更新用公開鍵証明書と，ステップＳ１２で生成した更新用私有鍵とを，管理装置３０との間の認証処理に使用する公開鍵証明書及び私有鍵として設定する（Ｓ１８）。 【００７０】 以上の処理により，管理対象機器４０は，それまで使用していた公開鍵証明書よりも有効期限までの期間が長い公開鍵証明書を取得し，以後これを用いて管理装置３０との間の認証処理を行うことができるようにするとことができる。そして，このような処理を行うことにより，管理対象機器４０が管理装置３０と通信可能な状態である場合には公開鍵証明書の更新が可能となる。この処理は，管理対象機器４０に設定されている証明書がオリジナル証明書である場合にも，既に更新が行われた証明書である場合（２回目以降の更新を行う場合）でも，同様に行うことができる。 以下，このような更新処理を行う場合に管理装置３０及び管理対象機器４０が実行する処理について，より詳細に説明する。」 Ｄ　「【００８５】 次に，図１８に，図１０に示した処理を実行する場合の管理対象機器４０側の処理のフローチャートを示す。この図に示す処理は，管理対象機器４０のＣＰＵが所要の制御プログラムを実行することにより行うものである。 そして，管理対象機器４０のＣＰＵは，管理装置３０との間の認証処理に使用する公開鍵証明書の有効期限が近づいたことを検知すると，図１８のフローチャートに示す処理を開始する。なお，上述したように，この処理の開始条件すなわち公開鍵証明書の更新処理を行う条件は，別の基準で定めるようにしてもよい。 【００８６】 そして，まずステップＳ４１で，更新用の一対の鍵ペアとして，更新用公開鍵と，その公開鍵と対応する更新用私有鍵を生成する。この生成の際には，図１２に示したように，鍵本体の他，必要な書誌情報も付すものとする。 その後，ステップＳ４２で管理装置３０に通信を要求し，ステップＳ４３で管理装置３０との間でＳＳＬによる認証処理を行う。このとき，少なくとも管理対象機器４０が管理装置に認証を受けるが，逆に管理対象機器４０も管理装置３０を認証するようにするとよく，この場合，例えば背景技術の項で図２１を用いて説明した認証処理を採用することができる。 そして，ステップＳ４３での認証処理が成功すると，ステップＳ４４で更新用公開鍵を記載した自己生成公開鍵通知を生成し，この通知により更新用公開鍵を管理装置３０に送信する。そして，管理装置３０からの応答を待ち，ステップＳ４５でこの応答を受信する。 【００８７】 図１１を用いて説明した通り，管理装置３０からの応答には，管理装置３０が更新用公開鍵にデジタル署名を付して発行した更新用公開鍵証明書及びその正当性を確認するためのルート鍵証明書か，またはエラー通知が記載されているはずである。そこで，次のステップＳ４６で，更新用公開鍵証明書を受信したか否か判断する。 ここで受信していればステップＳ４７に進み，受信した更新用公開鍵証明書の正当性を，共に受信したルート鍵証明書を用いて確認する。そして，これが確認できると，ステップＳ４８からＳ４９に進み，受信した更新用公開鍵証明書と，ステップＳ４１で生成した更新用私有鍵とを，管理装置３０との通信に使用するものとして設定して処理を終了する。 【００８８】 一方，ステップＳ４６で更新用公開鍵証明書を受信していない（エラー通知を受信した）場合，あるいはステップＳ４８で更新用公開鍵証明書の正当性が確認できなかった場合には，ステップＳ５０でエラー処理をして終了する。 なお，エラー処理の内容はエラー通知の内容や更新用公開鍵証明書の確認結果に応じて異なるものであり，例えば更新用公開鍵証明書の正当性を確認できなかった場合には，証明書が破損していたと判断して再度図１８のフローチャートの処理を繰り返したり，管理契約期間が延長されていなかった場合には延長の案内メッセージを表示部に表示させたりといった動作が考えられる。 また，図１６及び図１７に示した例のように応答に審査結果を記載するようにした場合には，ステップＳ４７でその審査結果がＯＫかＮＧかを判断するようにしてもよい。この場合，ＯＫがＹＥＳに，ＮＧがＮＯに該当する。 【００８９】 以上の処理により，更新が成功した場合には，管理対象機器４０自身が生成した公開鍵に管理装置３０がデジタル署名を付して作成した公開鍵証明書を，管理装置３０との間の認証に使用する公開鍵証明書として設定することができる。また，私有鍵についても，管理対象機器４０自身が生成した公開鍵と対応する私有鍵を，管理装置３０との間の認証に使用するものとして設定することができる。 この場合において，図９に示したような更新前の証明書メモリの内容は，公開鍵証明書及び私有鍵の部分が更新後のものに置き換えられる。」 上記Ａの「この発明は，このような要求に応え，通信装置が認証に使用する公開鍵証明書を自動的に更新することを可能としながら，私有鍵の漏洩の可能性を低下させ，安全な更新を実現させることを目的とする。」との記載，及び，上記Ｃの「管理対象機器４０のＣＰＵが所要の制御プログラムを実行することにより行うものである。」との記載から，引用文献１には，“認証に使用する公開鍵証明書を自動的に更新することを，管理対象機器のＣＰＵにより実行する制御プログラム”について記載されているといえる。 また，上記管理対象機器の処理として，上記Ｃの記載から， “管理対象機器のＣＰＵが，管理装置との間の認証処理に使用する公開鍵証明書の有効期限が近づいたことを検知すると， 更新用の一対の鍵ペアとして，更新用公開鍵と，その公開鍵と対応する更新用私有鍵を生成し， 管理装置に通信を要求し，管理装置との間でＳＳＬによる認証処理を行い， 認証処理が成功すると，更新用公開鍵を記載した自己生成公開鍵通知を生成し，この通知により更新用公開鍵を管理装置に送信し， 管理装置からの応答として，更新用公開鍵証明書を受信したか否か判断し， ここで受信していれば，受信した更新用公開鍵証明書の正当性を，共に受信したルート鍵証明書を用いて確認し，これが確認できると，受信した更新用公開鍵証明書と，生成した更新用私有鍵とを，管理装置との通信に使用するものとして設定する” ことが読み取れる。 また，上記“管理装置との間”で行う“認証処理”に関し，上記Ｂの「管理装置３０に通信を要求して通常通り認証処理に使用するものとして設定されている証明書を用いた認証処理を行い」との記載から，上記“認証処理は，現在設定されている公開鍵証明書を用いて行われるものであ”ることが読み取れる。 また，上記“認証処理”の成功後に生成される上記“自己生成公開鍵通知”に関し，上記Ｂの「自己生成公開鍵通知は，管理装置３０に対して，送信した公開鍵にデジタル署名を付して公開鍵証明書を発行することを要求するコマンドであると考えることもできる」との記載から，上記“自己生成公開鍵通知は，管理装置に対して，送信した公開鍵にデジタル署名を付して公開鍵証明書を発行することを要求するコマンドであると考えることもできる”ことが読み取れる。 また，上記“ＳＳＬによる認証処理”の成功後の“管理装置”との情報のやり取りに関し，上記Ａの「ＳＳＬに従った相互認証を行う場合の通信手順について，認証処理の部分に焦点を当てて説明する」との記載，同じく上記Ａの「通信装置Ａ側のステップＳ１１７と通信装置Ｂ側のステップＳ１２６の処理が終了すると，相互に認証の成功と以後の通信に使用する暗号化方式とを確認し，生成した共通鍵を用いてその暗号化方式で以後の通信を行うものとして認証に関する処理を終了する。・・・以上の処理によって互いに通信を確立し，以後はステップＳ１１７又はＳ１２６で生成した共通鍵を用い，共通鍵暗号方式でデータを暗号化して通信を行うことができる。このような処理を行うことにより，通信装置Ａと通信装置Ｂが互いに相手を認証した上で安全に共通鍵を共有することができ，通信を安全に行う経路を確立することができる。」との記載から，上記“ＳＳＬによる認証処理”の成功後の“管理装置”との“自己生成公開鍵通知に記載された更新用公開鍵”及び“更新用公開鍵証明書”のやり取りは，“生成した共通鍵を用いてデータを暗号化して行う”ことが読み取れる。 また，上記Ｂの「管理対象機器４０が管理装置３０と通信可能な状態である場合には公開鍵証明書の更新が可能となる。この処理は，管理対象機器４０に設定されている証明書がオリジナル証明書である場合にも，既に更新が行われた証明書である場合（２回目以降の更新を行う場合）でも，同様に行うことができる」との記載から，“更新処理は，既に更新が行われた証明書である場合（２回目以降の更新を行う場合）でも，同様に行うことができる”ことが読み取れる。 以上の検討から，上記引用文献１には次の発明（以下，「引用発明」という。）が記載されていると認められる。 認証に使用する公開鍵証明書を自動的に更新することを，管理対象機器のＣＰＵにより実行する制御プログラムであって， 前記管理対象機器の処理として， 前記管理対象機器のＣＰＵが，管理装置との間の認証処理に使用する公開鍵証明書の有効期限が近づいたことを検知すると， 更新用の一対の鍵ペアとして，更新用公開鍵と，その公開鍵と対応する更新用私有鍵を生成し， 前記管理装置に通信を要求し，前記管理装置との間でＳＳＬによる認証処理を行い， 認証処理が成功すると，更新用公開鍵を記載した自己生成公開鍵通知を生成し，この通知により更新用公開鍵を前記管理装置に送信し， 前記管理装置からの応答として，更新用公開鍵証明書を受信したか否か判断し， ここで受信していれば，受信した更新用公開鍵証明書の正当性を，共に受信したルート鍵証明書を用いて確認し，これが確認できると，受信した更新用公開鍵証明書と，生成した更新用私有鍵とを，前記管理装置との通信に使用するものとして設定する， ことを行わせ， 上記認証処理は，現在設定されている公開鍵証明書を用いて行われるものであり， 上記自己生成公開鍵通知は，前記管理装置に対して，送信した公開鍵にデジタル署名を付して公開鍵証明書を発行することを要求するコマンドであると考えることもでき， 上記ＳＳＬによる認証処理の成功後の前記管理装置との自己生成公開鍵通知に記載された更新用公開鍵及び更新用公開鍵証明書のやり取りは，生成した共通鍵を用いてデータを暗号化して行うものであり， 上記更新処理は，既に更新が行われた証明書である場合（２回目以降の更新を行う場合）でも，同様に行うことができる， 制御プログラム。 ２．引用文献２について 原査定の拒絶の理由に引用され，当審拒絶理由通知１にも引用された引用文献２（盛合志帆，インターネットにおけるコンテンツ保護技術，映像情報メディア学会誌，映像情報メディア学会，2005年4月1日，Vol. 59, No. 4，pp. 532-537）には，ＳＳＬにおいて鍵共有するための方式としてＤｉｆｆｉｅ－Ｈｅｌｌｍａｎ方式を用いる，との技術事項が記載されている。 ３．引用文献３について 原査定の拒絶の理由に引用され，当審拒絶理由通知１にも引用された引用文献３（特開２００９－１１８３５０号公報）の特に段落【００４５】－【００５８】には，処理要求を受信した回数を計数し，当該回数が閾値を超えたら当該処理要求を不正な要求と判断する，との技術事項が記載されている。 ４．引用文献４について 原査定の拒絶の理由に引用され，当審拒絶理由通知１にも引用された引用文献４（相澤英孝，他，暗号と特許，日本銀行金融研究所ディスカッション・ペーパー・シリーズ，日本銀行金融研究所，１９９８年　６月，Ｎｏ．９８－Ｊ－９，ｐｐ．３４－３６，７９－８２）の特に「５．鍵配送・共有方式」（３４－３５頁），脚注２０７（８０頁）には，鍵共有のためのDiffie-Hellman方式として，利用者Ａと利用者Ｂとが同一の鍵Ｋを得るために，利用者Ａが，秘密の乱数ＸＡを生成し，乱数ＸＡからＹＡ＝α＾ＸＡ（ｍｏｄ　ｐ）を生成し，利用者ＢにＹＡを送信し，利用者Ｂが，秘密の乱数ＸＢを生成し，乱数ＸＢからＹＢ＝α＾ＸＢ（ｍｏｄ　ｐ）を生成し，利用者ＡにＹＢを送信し，利用者Ａが鍵Ｋ＝α＾ＹＢＸＡ（ｍｏｄ　ｐ）を生成し，また，利用者Ｂが鍵Ｋ＝α＾ＹＡＸＢ（ｍｏｄ　ｐ）を生成する方式，が記載されている。 ５．引用文献Ｅについて 当審拒絶理由通知１に引用された引用文献Ｅ（特開２００１－３２０３５６号公報）には，図面とともに次の事項が記載されている。 Ｅ　「【０１３３】図２０は，ルート登録局（ルートＲＡ）１６０１の管理下の登録局（ＲＡ）１７０１であるサービスプロバイダ（ＳＰ）が新たな公開鍵，秘密鍵を生成して，新たに生成した公開鍵の証明書の発行を行なう手続き，すなわち更新処理を示した図である。 【０１３４】まず，登録局（ＲＡ）１７０１は，新たな公開鍵，秘密鍵を生成する。次に登録局（ＲＡ）１７０１とルート登録局（ルートＲＡ）１６０１との間で相互認証処理を実行する。これは，現鍵（現在（更新前）の公開鍵，秘密鍵）を用いた相互認証処理，すなわち図１４で説明した非対象鍵暗号を用いた処理として実行できる。 【０１３５】次に，登録局（ＲＡ）１７０１は，登録局（ＲＡ）１７０１が新たに生成した公開鍵ＫｐＳＰ’を自己の秘密鍵で署名して，さらに相互認証時に生成したセッション鍵で暗号化してデータＥKs（｛ＫｐＳｐ’｝Sig・KsSP）を生成してルート登録局（ルートＲＡ）１６０１に送信する。このデータを受領したルート登録局（ルートＲＡ）１６０１は，失効チェックを実行する。失効チェックは，先の図９，図１０で説明した失効リストに失効する公開鍵データを書き込む処理として実行される。」 ６．引用文献Ｆについて 当審拒絶理由通知１に引用された引用文献Ｆ（特開２００２－２９７５４８号公報）には，図面とともに次の事項が記載されている。 Ｆ　「【００４３】また，端末登録装置20に登録した端末10の公開鍵は，所定の時期に更新することができる。この鍵更新は，端末側の主導で行っても，端末登録装置側の主導で行っても良い。 【００４４】この場合，端末10では，キーペア生成手段13が新公開鍵と新秘密鍵とのペアを生成し，図７に示すように，署名生成手段17が，新公開鍵と端末ＩＤとから成るデータの一方向性ハッシュ値を計算し，このハッシュ値を旧秘密鍵で暗号化して署名データ（旧署名（新公開鍵，端末ＩＤ））を生成する。そして，この署名データと新公開鍵と端末ＩＤとを含む更新登録要請データを送受信手段18から端末登録装置20に送信する。 【００４５】端末登録装置20では，送受信手段23が更新登録要請データを受信すると，署名検証手段24は，更新登録要請データから，端末ＩＤと新公開鍵とを取り出し，その一方向性ハッシュ値を計算する。また，認証端末記憶手段22から，端末ＩＤに対応する旧公開鍵を読み出し，旧署名（新公開鍵，端末ＩＤ）を旧公開鍵を復号化し，その値と，計算したハッシュ値とが一致しているかどうかを判定する。一致しているときは，正当な端末10からの更新登録要求であると判断し，認証端末記憶手段22に格納している，その端末の端末ＩＤに対応する公開鍵を新公開鍵に更新し，送受信手段23から，更新登録完了を示す更新登録確認データを端末10に返信する。この更新登録確認データを受信した端末10では，キーペア生成手段13が生成した新キーペアをキーペア格納手段14に格納する。 【００４６】このように，一旦登録した端末の公開鍵の更新についても，安全に行うことができる。端末登録装置20は，鍵の有効期間を設定して，鍵の更新を定期的に行わせることにより，登録機関としての信頼性を高めることができる。」 ７．引用文献Ｇについて 当審拒絶理由通知１に引用された引用文献Ｇ（特開２００１－１１１５３８号公報）には，図面とともに次の事項が記載されている。 Ｇ　「【００４５】このような状態において，まず，ゲートウェイ１０が使用する鍵を更新する処理について説明する。その場合，まずゲートウェイ１０の計算機システムは，装着されているＩＣカード４０に対して新たなＲＳＡ鍵ペアの生成を要求する（○１（当審注：丸数字の１を意味する。以下，同様。））。ＩＣカード４０では，これに基づいて，ＲＳＡ鍵生成部４１でＲＳＡ鍵ペアを生成し，公開鍵（図中では，Ｖ溝を有するシンボルＡ2 ）を新公開鍵記憶部４２に，秘密鍵（図中では，Ｖ山を有するシンボルＡ2 ）を新秘密鍵記憶部４３に記憶する。新たな鍵の生成が終了したら，計算機システムは，ＩＣカード４０に対して，現在の秘密鍵で署名を行なった新たな公開鍵を要求する。その結果，ＩＣカード４０においては，署名部４５において，新公開鍵記憶部４２に記憶されている新たな公開鍵が，現秘密鍵記憶部４４に記憶されている現在用いられている秘密鍵を用いて署名され，インターフェイス部４６を介して計算機システムに送信される（○２）。 【００４６】このようにして得られた現秘密鍵により署名された新公開鍵は，ゲートウェイ１０より認証局３０に送信され，認証局３０に新公開鍵が通知されるとともに，新公開鍵に対する電子証明書の発行が要求される（○３）。認証局３０においては，ゲートウェイ１０の現公開鍵を用いて送信された内容を検査し，確かにゲートウェイ１０から送信されたものであること確認すると，その新たなゲートウェイ１０の公開鍵を記憶しておく。また，自分（認証局３０）の秘密鍵によりゲートウェイ１０の新公開鍵に署名を行なって電子証明書を作成し，ゲートウェイ１０に送信する（○４）。ゲートウェイ１０においては，送信された電子証明書を，認証局３０の公開鍵を用いて検査し，確かに認証局３０により作成された電子証明書であることを確認する。」 第６　対比・判断 １．本願発明１について （１）対比 本願発明１と引用発明とを対比する。 ア　引用発明の「現在設定されている公開鍵証明書」，「更新用公開鍵」，「更新用公開鍵証明書」，「管理装置」は，それぞれ本願発明１の「第１の公開鍵証明書」，「第２の公開鍵証明書に対応付けられるクライアント公開鍵」，「第２の公開鍵証明書」，「サーバ」に相当する。 イ　引用発明は，「認証処理が成功すると，更新用公開鍵を記載した自己生成公開鍵通知を生成し，この通知により更新用公開鍵を前記管理装置に送信」するものであって，「上記自己生成公開鍵通知は，前記管理装置に対して，送信した公開鍵にデジタル署名を付して公開鍵証明書を発行することを要求するコマンドであると考えることもでき」るところ，この場合の「更新用公開鍵を記載した自己生成公開鍵通知」の送信は「ＳＳＬによる認証処理」の「成功」後であるから，データを暗号化して送信するセキュアな通信におけるものであるといえる。 そうすると，後記する点で相違するものの，本願発明１の，「前記セキュアな通信において，前記一時クライアント秘密鍵とペアとなる一時クライアント公開鍵と，生成した前記一時共通鍵で暗号化した第２の公開鍵証明書に対応付けられるクライアント公開鍵とを，前記第１の公開鍵証明書を用い，前記第１の公開鍵証明書に対応する前記第１のクライアント秘密鍵による前記電子署名を付与して前記サーバへ送信することで，該第２の公開鍵証明書の発行要求を行い」と，引用発明の，「認証処理が成功すると，更新用公開鍵を記載した自己生成公開鍵通知を生成し，この通知により更新用公開鍵を前記管理装置に送信」するものであって，「上記自己生成公開鍵通知は，前記管理装置に対して，送信した公開鍵にデジタル署名を付して公開鍵証明書を発行することを要求するコマンドであると考えることもでき」ることとは，“セキュアな通信において，第２の公開鍵証明書の発行要求を行い”である点で共通する。 ウ　引用発明は，「前記管理装置からの応答として，更新用公開鍵証明書を受信したか否か判断し，ここで受信していれば，受信した更新用公開鍵証明書の正当性を，共に受信したルート鍵証明書を用いて確認」するものであるから，後記する点で相違するものの，本願発明１の，「前記サーバから，前記一時共通鍵で暗号化された前記第２の公開鍵証明書を前記セキュアな通信により受領し，該一時共通鍵で該第２の公開鍵証明書を復号し」と，引用発明の，「前記管理装置からの応答として，更新用公開鍵証明書を受信したか否か判断し，ここで受信していれば，受信した更新用公開鍵証明書の正当性を，共に受信したルート鍵証明書を用いて確認」することとは，“サーバから，前記第２の公開鍵証明書を前記セキュアな通信により受領し”である点で共通する。 エ　引用発明である「管理対象機器のＣＰＵにより実行する制御プログラム」は，本願発明１である「コンピュータに実行させる更新プログラム」に対応する。 オ　上記アないしエの検討から，本願発明１と引用発明との間には，次の一致点，相違点があるといえる。 （一致点） 「セキュアな通信において，第２の公開鍵証明書の発行要求を行い， サーバから，前記第２の公開鍵証明書を前記セキュアな通信により受領する 処理をコンピュータに実行させる更新プログラム。」 （相違点１） 本願発明１は，「メッセージを暗号化して送受信するサーバとのセキュアな通信において，暗号化された該メッセージに対して，第１の公開鍵証明書に対応する第１のクライアント秘密鍵による電子署名を付与し，有効期限付きの該第１の公開鍵証明書を初めて用いた，該サーバへの接続のときに，該サーバに対し一時的に利用する一時サーバ公開鍵を要求」するものであるのに対して， 引用発明は，そのような特定はなされていない点。 （相違点２） 本願発明１は，「一時的に利用する一時クライアント鍵ペアを生成し，該一時クライアント鍵ペアのうち一時クライアント秘密鍵と前記サーバから前記セキュアな通信により受信した前記一時サーバ公開鍵とで一時共通鍵を生成」するものであるのに対して， 引用発明は，共通鍵の生成についてそのような特定はなされていない点。 （相違点３） 第２の公開鍵証明書の発行要求に関し， 本願発明１は，「一時クライアント秘密鍵とペアとなる一時クライアント公開鍵と，生成した前記一時共通鍵で暗号化した第２の公開鍵証明書に対応付けられるクライアント公開鍵とを，前記第１の公開鍵証明書を用い，前記第１の公開鍵証明書に対応する前記第１のクライアント秘密鍵による前記電子署名を付与して前記サーバへ送信することで」，第２の公開鍵証明書の発行要求を行うものであるのに対して， 引用発明は，公開鍵証明書を発行することを要求するコマンドである自己生成公開鍵通知についてそのような特定はなされていない点。 （相違点４） サーバからの第２の公開鍵証明書の受領に関し， 本願発明１は，「一時共通鍵で暗号化された」第２の公開鍵証明書をセキュアな通信により受領し，「一時共通鍵で該第２の公開鍵証明書を復号」するものであるのに対して， 引用発明は，受信した更新用公開鍵証明書についてそのような特定はなされていない点。 （相違点５） 本願発明１は，「第１の公開鍵証明書の有効期限が過ぎた場合は，前記セキュアな通信において，前記第２の公開鍵証明書に対応する第２のクライアント秘密鍵による電子署名をメッセージに付与して前記サーバと通信する」ものであるのに対して， 引用発明は，受信した更新用公開鍵証明書を，管理装置との通信に使用するものの，受信した更新用公開鍵証明書の使用を開始するのが，現在設定されている公開鍵証明書の有効期限が過ぎた場合であるとは特定されていない点。 （２）相違点についての判断 事案に鑑みて，上記相違点１及び３について，まとめて検討する。 上記相違点１及び３に係る構成は，「有効期限付きの該第１の公開鍵証明書を初めて用いた，該サーバへの接続のときに，該サーバに対し一時的に利用する一時サーバ公開鍵を要求」するものであるとともに，「サーバ」に対する，「一時的に利用する一時サーバ公開鍵」の「要求」，及び，上記「第２の公開鍵証明書」の発行要求のいずれも，「１の公開鍵証明書を用い」て行うものであり，これにより，「現行世代クライアント秘密鍵６ｂが推定されるリスクを大幅に低減することができる。第１に，現行世代クライアント公開鍵証明書６ｋに対する長期間にわたる推定に対抗するために，本実施例では，現行世代クライアント公開鍵証明書６ｋが使用されてからなるべく早い時期において，現行世代クライアント公開鍵証明書６ｋがクライアント５からサーバ１００に送信されたタイミングで，サーバ１００から次世代クライアント公開鍵証明書６ｋ'をセキュアにクライアント５に返信する。・・・従って，現行世代クライアント公開鍵６ａが第三者に推定される前に，次世代クライアント公開鍵６ａ'に切り替えることが可能となる。」（【０２５７】～【０２６０】）との効果を奏するものである。 そして，上記相違点１及び３に係る構成は，上記引用文献２ないし４，並びに，ＥないしＧのいずれにも記載されておらず，また，本願出願日前において周知技術であるともいえない。 そうすると，引用発明に基づいて，相違点１及び３に係る本願発明１の構成とすることは，当業者が容易になし得ることであるとはいえない。 したがって，本願発明１は，相違点２，４，５を検討するまでもなく，当業者であっても引用発明，引用文献２ないし４，並びに，ＥないしＧに記載された技術的事項，及び，周知技術に基づいて容易に発明できたものであるとはいえない。 ２．本願発明２－１７について 本願発明４－６，１０－１７は，本願発明１と実質同様の構成を有するか，カテゴリーが異なるだけであり，本願発明１の相違点１及び３に係る構成と同一または同様の構成を備えるものであるから，本願発明１と同様の理由により，引用発明，引用文献２ないし４，並びに，ＥないしＧに記載された技術的事項，及び，周知技術に基づいて容易に発明できたものであるとはいえない。 本願発明２，３，７－９は，本願発明１，６を更に限定したものであるので，本願発明１と同様の理由により，引用発明，引用文献２ないし４，並びに，ＥないしＧに記載された技術的事項，及び，周知技術に基づいて容易に発明できたものであるとはいえない。 第７　原査定についての判断 （特許法第２９条第２項について） 原査定は，請求項１－１８について上記引用文献１ないし４に基づいて，当業者が容易に発明できたものであるから，特許法第２９条第２項の規定により特許を受けることができないというものである。しかしながら，令和元年６月２０日付けの手続補正により補正された請求項１－１７は，それぞれ相違点１及び３に係る構成を有するものとなっており， 上記第６のとおり，本願発明１－１７は，上記引用発明，引用文献２ないし４，並びに，ＥないしＧに記載された技術的事項に基づいて，当業者が容易に発明できたものではない。したがって，原査定を維持することはできない。 第８　当審拒絶理由について １．特許法第２９条第２項について 上記「第６　対比・判断」で検討のとおり，令和元年６月２０日付けの手続補正により，この拒絶の理由は解消した。 ２．特許法第３６条第６項第２号について （１）当審拒絶理由通知１では，請求項１－１４，１６－１８の記載において，「第１の公開鍵証明書の有効期限まで，該第１の公開鍵証明書を用いた通信が可能な状態で」との語句がどこに係っているのか日本語として不明瞭であるとの拒絶の理由を通知しているが，令和元年６月２０日付けの手続補正において，当該記載は削除された結果，この拒絶の理由は解消した。 （２）当審拒絶理由通知１では，請求項１－１８の記載において，「前記第１の公開鍵証明書を最初に用いた，サーバに対するセキュアな通信接続が開始される毎に，」という語句がどこに係っているのかが明確でなく，当該セキュアな通信接続が開始される毎に行われる処理が，請求項１－１８に記載された処理のうちどこまでを含むのかを明確に把握できないとの拒絶の理由を通知しているが，令和元年６月２０日付けの手続補正において，「有効期限付きの該第１の公開鍵証明書を初めて用いた，該サーバへの接続のときに，」と補正された結果，この拒絶の理由は解消した。 （３）当審拒絶理由通知１では，請求項１－１８に記載の「公開鍵証明書を用いた」「セキュアな通信」は，具体的にどのような内容の通信を意味しているのかが明確でないとの拒絶の理由を通知しているが，令和元年６月２０日付けの手続補正において，「メッセージを暗号化して送受信するサーバとのセキュアな通信において，暗号化された該メッセージに対して，第１の公開鍵証明書に対応する第１のクライアント秘密鍵による電子署名を付与し，有効期限付きの該第１の公開鍵証明書を初めて用いた，該サーバへの接続のときに，該サーバに対し一時的に利用する一時サーバ公開鍵を要求し」，及び，「前記セキュアな通信において，前記一時クライアント秘密鍵とペアとなる一時クライアント公開鍵と，生成した前記一時共通鍵で暗号化した第２の公開鍵証明書に対応付けられるクライアント公開鍵とを，前記第１の公開鍵証明書を用い，前記第１の公開鍵証明書に対応する前記第１のクライアント秘密鍵による前記電子署名を付与して前記サーバへ送信することで，該第２の公開鍵証明書の発行要求を行い」と補正された結果，この拒絶の理由は解消した。 （４）当審拒絶理由通知１では，請求項２，４に記載の「前記セキュアな通信接続」について，請求項２，４には「セキュアな通信接続」は前記されておらず，他方，請求項２，４が引用する請求項１には，文言として，「前記第１の公開鍵証明書を最初に用いた，サーバに対するセキュアな通信接続」，「前記第１の公開鍵証明書を用いたセキュアな通信」，「前記第２の公開鍵証明書を用いて前記サーバとセキュアな通信」の３つの「セキュアな通信（接続）」が記載されており，これらが対応しているようにも見受けられるが，上記「前記セキュアな通信接続」は，これらのうちいずれを表しているのか依然明確でないとの拒絶の理由を通知しているが，令和元年６月２０日付けの手続補正において，「前記一時クライアント公開鍵を前記サーバに送信することで，該サーバとの間で一時共通鍵が共有され，前記第２の公開鍵証明書に対応付けられるクライアント公開鍵を送信することで，該サーバに前記第２の公開鍵証明書の発行要求を行う」と補正された結果，この拒絶の理由は解消した。 （５）当審拒絶理由通知１では，請求項３の「前記第１の公開鍵証明書を前記サーバに送出するタイミング」は，どのタイミングであるのかが不明であるとの拒絶の理由を通知しているが，令和元年６月２０日付けの手続補正において，「該有効期限が過ぎたことにより該第２の公開鍵証明書へと切り替えられ前記サーバへ初めて送出したタイミング」と補正された結果，この拒絶の理由は解消した。 （６）当審拒絶理由通知１では，請求項４に記載の「前記第２の公開鍵証明書に対応付けられるクライアント公開鍵に，前記第１の公開鍵証明書に対応するクライアント秘密鍵を用いて電子署名を付与する処理」について，請求項４が引用する請求項１に記載の「第２の公開鍵証明書に対応付けられるクライアント公開鍵とを，前記第１の公開鍵証明書を用いたセキュアな通信により前記サーバへ送信する」こととの技術的関係が明確でないとの拒絶の理由を通知しているが，令和元年６月２０日付けの手続補正において，請求項４を削除した結果，この拒絶の理由は解消した。 （７）当審拒絶理由通知１では，請求項７－１２の「前記クライアントから第２の公開鍵証明書の発行要求に対して，」との記載は誤記であるとの拒絶の理由を通知しているが，令和元年６月２０日付けの手続補正において，請求項６について，「前記クライアントからの第２の公開鍵証明書の発行要求に対して，」と補正された結果，この拒絶の理由は解消した。 （８）当審拒絶理由通知２では，請求項１－１７の「前記セキュアな通信において，前記一時クライアント秘密鍵とペアとなる一時クライアント公開鍵と，生成した前記一時共通鍵で暗号化した第２の公開鍵証明書に対応付けられるクライアント公開鍵とを，前記第１の公開鍵証明書に対応する前記第１のクライアント秘密鍵による前記電子署名を付与して前記サーバへ送信することで，該第２の公開鍵証明書の発行要求を行い」との記載は，「第２の公開鍵証明書の発行要求」を「第１の公開鍵証明書」を用いて行うことが明確に記載されておらず，当該「第２の公開鍵証明書の発行要求」がどのような態様で行われているのか不明確であるとの拒絶の理由を通知しているが，令和元年６月２０日付けの手続補正において，「前記セキュアな通信において，前記一時クライアント秘密鍵とペアとなる一時クライアント公開鍵と，生成した前記一時共通鍵で暗号化した第２の公開鍵証明書に対応付けられるクライアント公開鍵とを，前記第１の公開鍵証明書を用い，前記第１の公開鍵証明書に対応する前記第１のクライアント秘密鍵による前記電子署名を付与して前記サーバへ送信することで，該第２の公開鍵証明書の発行要求を行い」と補正された結果，この拒絶の理由は解消した。 （９）当審拒絶理由通知２では，請求項３の「該有効期限が過ぎたことにより該第２の公開鍵証明書へと切り替えられ前記サーバへ初めて送出たタイミングで，前記発行要求を行う」との記載は，「前記発行要求」が，「第２の公開鍵証明書」の発行要求であるのか，或いは，それ以外の公開鍵証明書の「発行要求」であるのか，不明確であるとの拒絶の理由を通知しているが，令和元年６月２０日付けの手続補正において，「該有効期限が過ぎたことにより該第２の公開鍵証明書へと切り替えられ前記サーバへ初めて送出したタイミングで，次の公開鍵証明書の発行要求を行う」と補正された結果，この拒絶の理由は解消した。 （１０）当審拒絶理由通知２では，請求項６－１１の「前記セキュアな通信により，前記クライアントから，一時クライアント公開鍵と，一時共通鍵によって暗号化されたクライアント公開鍵とを受信し」との記載は，クライアント側における「一時共通鍵」がどのように生成されたのか記載されておらず，また，上記「受信」において受信する内容に「第２の公開鍵証明書の発行要求」が含まれておらず前後の記載との間で整合性を欠いており，不明確であるとの拒絶の理由を通知しているが，令和元年６月２０日付けの手続補正において，「前記セキュアな通信により，前記クライアントから，前記第１の公開鍵証明書を用い，一時クライアント公開鍵と，前記一時サーバ公開鍵と一時クライアント秘密鍵から生成された一時共通鍵によって暗号化されたクライアント公開鍵とを含む第２の公開鍵証明書の発行要求を受信し」と補正された結果，この拒絶の理由は解消した。 ３．特許法第３６条第６項第１号について （１）当審拒絶理由通知１では，請求項１－１８の記載においては，クライアントとサーバで送受信される全てのメッセージが「ＰＫＩに基づき暗号化され」たものであることは必ずしも特定されておらず，結果，請求項１－１８に係る発明は，発明の詳細な説明に記載された実施例に対応しないものとなっているとの拒絶の理由を通知しているが，令和元年６月２０日付けの手続補正において，「メッセージを暗号化して送受信するサーバとのセキュアな通信において，暗号化された該メッセージに対して，第１の公開鍵証明書に対応する第１のクライアント秘密鍵による電子署名を付与し，有効期限付きの該第１の公開鍵証明書を初めて用いた，該サーバへの接続のときに，該サーバに対し一時的に利用する一時サーバ公開鍵を要求し」，及び，「前記セキュアな通信において，前記一時クライアント秘密鍵とペアとなる一時クライアント公開鍵と，生成した前記一時共通鍵で暗号化した第２の公開鍵証明書に対応付けられるクライアント公開鍵とを，前記第１の公開鍵証明書を用い，前記第１の公開鍵証明書に対応する前記第１のクライアント秘密鍵による前記電子署名を付与して前記サーバへ送信することで，該第２の公開鍵証明書の発行要求を行い」と補正された結果，この拒絶の理由は解消した。 （２）当審拒絶理由通知１では，請求項４の「前記第２の公開鍵証明書に対応付けられるクライアント公開鍵に，前記第１の公開鍵証明書に対応するクライアント秘密鍵を用いて電子署名を付与する」ことは，発明の詳細な説明に記載されていないとの拒絶の理由を通知しているが，令和元年６月２０日付けの手続補正において，請求項４を削除した結果，この拒絶の理由は解消した。 ４．特許法第３６条第４項第１号について （１）当審拒絶理由通知１では，発明の詳細な説明に記載された実施例においては，クライアントとサーバで送受信されるメッセージは「ＰＫＩに基づき暗号化され」ており，具体的には，「送信元の公開鍵を示す公開鍵証明書６ｋ（又は７ｋ）と，メッセージ１ｍと，送信元の電子署名６ｅ（又は７ｅ）とを含む」データとして送受信されるものであるが（段落【００２８】－【００３９】，図２－３，８等），当該構成について，ＰＫＩに基づく暗号化として上記のように送受信されるメッセージに「送信元の公開鍵を示す公開鍵証明書」を付加して送信することにより，如何なる技術的課題を解決しようとしているのか，その技術的意義を理解することができないとの拒絶の理由を通知しているが，令和元年６月２０日付けの意見書において，暗号化して送受信されるメッセージに「送信元の公開鍵を示す公開鍵証明書」を付加して送信することが可能であり，それを提示したものである旨釈明された結果，この拒絶の理由は解消した。 第９　むすび 以上のとおり，本願発明１－１７は，当業者が引用発明，引用文献２ないし４，並びに，ＥないしＧに記載された技術的事項に基づいて容易に発明することができたものではない。 したがって，原査定の拒絶理由を検討してもその理由によって拒絶すべきものとすることはできない。 また，他に本願を拒絶すべき理由を発見しない。 よって，結論のとおり審決する。