【事件の表示】
　特願２０１３−　１０８００「認証システム」拒絶査定不服審判事件〔平成２６年　８月　７日出願公開，特開２０１４−１４３５６８〕について，次のとおり審決する。
【結　論】
　本件審判の請求は，成り立たない。
【理　由】
第１．手続の経緯
　本願は，平成２５年１月２４日の出願であって，
　平成２８年１月２２日付けで審査請求がなされ，平成２８年１２月１６日付けで審査官により拒絶理由が通知され，これに対して平成２９年３月１３日付けで意見書が提出されると共に手続補正がなされたが，平成２９年８月２２日付けで審査官により拒絶査定がなされ（謄本送達；平成２９年８月２９日），これに対して平成２９年１１月２９日付けで審判請求がなされると共に手続補正がなされ，平成３０年２月１５日付けで審査官により特許法第１６４条第３項の規定に基づく報告がなされたものである。
　
第２．平成２９年１１月２９日付けの手続補正の却下の決定
　
　［補正却下の決定の結論］
　
　平成２９年１１月２９日付け手続補正を却下する。
　
　［理由］
　
１．補正の内容
　平成２９年１１月２９日付けの手続補正（以下，「本件手続補正」という）により，平成２９年３月１３日付けの手続補正により補正された特許請求の範囲，
「　【請求項１】
　第１の認証データを生成する被認証器と，
　前記被認証器にて生成された前記第１の認証データを第２の認証データに変換する認証子変換器と，
　前記認証子変換器にて変換された前記第２の認証データに基づいて，前記被認証器の認証を行う認証器と，を備え，
　前記第１の認証データは，第１認証子と前記被認証器が有する所定データとを含み，
　前記被認証器は，前記認証器から送信されたチャレンジデータと前記所定データを，共通鍵を用いた共通鍵暗号方式で計算して前記第１認証子を生成し，生成した前記第１認証子と前記所定データとを前記認証子変換器に送信し，
　前記第２の認証データは，第２認証子と前記被認証器が有する前記所定データとを含み，
　前記認証子変換器は，秘密鍵を有し，前記被認証器から送信された前記所定データと前記認証器から送信された前記チャレンジデータを前記秘密鍵を用いた公開鍵暗号方式で計算して前記第２認証子を生成し，生成した前記第２認証子と前記所定データを前記認証器に送信し，
　前記認証器は，公開鍵を有し，前記認証子変換器から送信された前記所定データと前記認証子変換器に送信した前記チャレンジデータとを結合し，前記認証子変換器から送信された前記第２認証子を前記公開鍵を用いて復号し，復号した結果と，前記結合したデータとを比較して前記被認証器を認証することを特徴とする認証システム。
　　【請求項２】
　前記認証子変換器は，前記被認証器から送信された前記所定データと前記認証器から送信された前記チャレンジデータを前記共通鍵を用いた共通鍵暗号方式で計算して第１の比較用認証子を生成し，前記被認証器から送信された前記第１認証子と前記第１の比較用認証子とを比較することにより，前記被認証器を認証することを特徴とする請求項１に記載の認証システム。
　　【請求項３】
　第１の認証データを生成する被認証器と，
　前記被認証器にて生成された前記第１の認証データを第２の認証データに変換する認証子変換器と，
　前記認証子変換器にて変換された前記第２の認証データに基づいて，前記被認証器の認証を行う認証器と，を備え，
　前記第１の認証データは，第１認証子と前記被認証器が有する所定データとを含み，
　前記被認証器は，前記認証器から送信されたチャレンジデータと前記所定データを，第１の共通鍵を用いた共通鍵暗号方式で計算して前記第１認証子を生成し，生成した前記第１認証子と前記所定データとを前記認証子変換器に送信し，
　前記第２の認証データは，第２認証子と前記被認証器が有する前記所定データとを含み，
　前記認証子変換器は，前記被認証器から送信された前記所定データと前記認証器から送信された前記チャレンジデータを前記第１の共通鍵とは異なる第２の共通鍵を用いた共通鍵暗号方式で計算して前記第２認証子を生成し，生成した前記第２認証子と前記所定データを前記認証器に送信し，
　前記認証器は，前記認証子変換器から送信された前記所定データと前記認証子変換器に送信した前記チャレンジデータとを結合し，前記第２の共通鍵を用いた共通鍵暗号方式で計算して第２の比較用認証子を生成し，前記認証子変換器から送信された前記第２認証子と前記第２の比較用認証子とを比較して前記被認証器を認証することを特徴とする認証システム。
　　【請求項４】
　前記認証子変換器は，前記被認証器から送信された前記所定データと前記認証器から送信された前記チャレンジデータを前記第１の共通鍵を用いた共通鍵暗号方式で計算して第１の比較用認証子を生成し，前記被認証器から送信された前記第１認証子と前記第１の比較用認証子とを比較することにより，前記被認証器を認証することを特徴とする請求項３に記載の認証システム。
　　【請求項５】
　前記認証子変換器は，公開鍵暗号方式における秘密鍵を有し，
　前記認証器は，前記秘密鍵と対になる公開鍵を有し，
　前記認証器は，前記公開鍵を用いた公開鍵暗号方式で計算して暗号化した前記第２の共通鍵を前記認証子変換器に送信し，
　前記認証子変換器は，前記認証器より送信された前記暗号化された前記第２の共通鍵を前記秘密鍵を用いて復号することにより，前記第２の共通鍵を取得することを特徴とする請求項３又は４に記載の認証システム。
　　【請求項６】
　前記第２の共通鍵は，使い捨ての共通鍵であり，
　前記認証器は，新たな共通鍵を随時生成し，前記認証子変換器に送信することにより，前記使い捨ての共通鍵を変更することを特徴とする請求項５に記載の認証システム。
　　【請求項７】
　前記認証子変換器は，前記被認証器の認証を前記第１の認証データに基づいて行い，前記被認証器の認証に成功した場合には，前記第２の認証データを前記認証器に送信することを特徴とする請求項１ないし６のいずれか１項に記載の認証システム。
　　【請求項８】
　前記第２の認証データの暗号化された前記第２認証子は，前記認証子変換器が前記被認証器の認証を前記第１の認証データに基づいて行った認証結果をさらに含み，
　前記認証子変換器は，前記被認証器の認証を前記第１の認証データに基づいて行い，前記被認証器の認証の成否にかかわらず，前記第２の認証データを前記認証器に送信することを特徴とする請求項１ないし６のいずれか１項に記載の認証システム。
　　【請求項９】
　前記被認証器は，シートに画像を形成する画像形成装置が備える交換可能な装置又はユニットに設けられていることを特徴とする請求項１ないし８のいずれか１項に記載の認証システム。
　　【請求項１０】
　前記認証子変換器は，シートに画像を形成する画像形成装置が備える制御手段を有するユニットに設けられていることを特徴とする請求項１ないし９のいずれか１項に記載の認証システム。
　　【請求項１１】
　前記認証器は，シートに画像を形成する画像形成装置が備える制御手段を有するユニットに設けられていることを特徴とする請求項１ないし１０のいずれか１項に記載の認証システム。
　　【請求項１２】
　前記認証器は，シートに画像を形成する画像形成装置と接続された外部装置に設けられていることを特徴とする請求項１ないし１０のいずれか１項に記載の認証システム。」（以下，上記引用の請求項各項を，「補正前の請求項」という）は，
「　【請求項１】
　第１の認証データを生成する被認証器と，
　前記被認証器にて生成された前記第１の認証データに基づき前記被認証器を認証し，前記第１の認証データを第２の認証データに変換する認証子変換器と，
　前記認証子変換器にて変換された前記第２の認証データに基づいて，認証処理を行う認証器と，を備え，
　前記第１の認証データは，第１認証子と前記被認証器が有する所定データとを含み，
　前記被認証器は，前記認証器から送信されたチャレンジデータと前記所定データを，共通鍵を用いた共通鍵暗号方式で計算して前記第１認証子を生成し，生成した前記第１認証子と前記所定データとを前記第１の認証データとして前記認証子変換器に送信し，
　前記第２の認証データは，第２認証子と前記被認証器が有する前記所定データとを含み，
　前記認証子変換器は，秘密鍵を有し，前記被認証器から送信された前記第１の認証データの前記所定データと前記認証器から送信された前記チャレンジデータを，前記共通鍵を用いた共通鍵暗号方式で計算して第１比較認証子を生成し，生成した前記第１比較認証子と，前記第１の認証データの前記第１認証子と，を比較し，前記第１比較認証子と前記第１認証子が一致した場合に，前記被認証器から送信された前記第１の認証データの前記所定データと前記認証器から送信された前記チャレンジデータを前記秘密鍵を用いた公開鍵暗号方式で計算して前記第２認証子を生成し，生成した前記第２認証子と前記所定データとを前記第２の認証データとして前記認証器に送信し，
　前記認証器は，公開鍵を有し，前記認証子変換器から送信された前記第２の認証データの前記所定データと前記認証子変換器に送信した前記チャレンジデータとを結合し，前記認証子変換器から送信された前記第２の認証データの前記第２認証子を前記公開鍵を用いて復号し，復号した結果と，前記結合したデータとを比較して前記認証処理を行うことを特徴とする認証システム。
　　【請求項２】
　第１の認証データを生成する被認証器と，
　前記被認証器にて生成された前記第１の認証データに基づき前記被認証器を認証し，前記第１の認証データを第２の認証データに変換する認証子変換器と，
　前記認証子変換器にて変換された前記第２の認証データに基づいて，認証処理を行う認証器と，を備え，
　前記第１の認証データは，第１認証子と前記被認証器が有する所定データとを含み，
　前記被認証器は，前記認証器から送信されたチャレンジデータと前記所定データを，第１の共通鍵を用いた共通鍵暗号方式で計算して前記第１認証子を生成し，生成した前記第１認証子と前記所定データとを前記第１の認証データとして前記認証子変換器に送信し，
　前記第２の認証データは，第２認証子と前記被認証器が有する前記所定データとを含み，
　前記認証子変換器は，前記被認証器から送信された前記第１の認証データの前記所定データと前記認証器から送信された前記チャレンジデータを，前記第１の共通鍵を用いた共通鍵暗号方式で計算して第１比較認証子を生成し，生成した前記第１比較認証子と，前記第１の認証データの前記第１認証子とを比較し，前記第１比較認証子と前記第１認証子とが一致した場合に，前記被認証器から送信された前記第１の認証データの前記所定データと前記認証器から送信された前記チャレンジデータを前記第１の共通鍵とは異なる第２の共通鍵を用いた共通鍵暗号方式で計算して前記第２認証子を生成し，生成した前記第２認証子と前記所定データとを前記第２の認証データとして前記認証器に送信し，
　前記認証器は，前記認証子変換器から送信された前記第２の認証データの前記所定データと前記認証子変換器に送信した前記チャレンジデータとを結合し，前記第２の共通鍵を用いた共通鍵暗号方式で計算して第２比較認証子を生成し，前記認証子変換器から送信された前記第２の認証データの前記第２認証子と前記第２比較認証子とを比較して前記認証処理を行うことを特徴とする認証システム。
　　【請求項３】
　前記認証子変換器は，公開鍵暗号方式における秘密鍵を有し，
　前記認証器は，前記秘密鍵と対になる公開鍵を有し，
　前記認証器は，前記公開鍵を用いた公開鍵暗号方式で計算して暗号化した前記第２の共通鍵を前記認証子変換器に送信し，
　前記認証子変換器は，前記認証器より送信された前記暗号化された前記第２の共通鍵を前記秘密鍵を用いて復号することにより，前記第２の共通鍵を取得することを特徴とする請求項２に記載の認証システム。
　　【請求項４】
　前記第２の共通鍵は，使い捨ての共通鍵であり，
　前記認証器は，新たな共通鍵を随時生成し，前記認証子変換器に送信することにより，前記使い捨ての共通鍵を変更することを特徴とする請求項３に記載の認証システム。
　　【請求項５】
　前記認証子変換器は，前記被認証器の認証を前記第１の認証データに基づいて行い，前記被認証器の認証に成功した場合には，前記第２の認証データを前記認証器に送信することを特徴とする請求項１ないし４のいずれか１項に記載の認証システム。
　　【請求項６】
　前記第２の認証データの暗号化された前記第２認証子は，前記認証子変換器が前記被認証器の認証を前記第１の認証データに基づいて行った認証結果をさらに含み，
　前記認証子変換器は，前記被認証器の認証を前記第１の認証データに基づいて行い，前記被認証器の認証の成否にかかわらず，前記第２の認証データを前記認証器に送信することを特徴とする請求項１ないし４のいずれか１項に記載の認証システム。
　　【請求項７】
　前記被認証器は，シートに画像を形成する画像形成装置が備える交換可能な装置又はユニットに設けられていることを特徴とする請求項１ないし６のいずれか１項に記載の認証システム。
　　【請求項８】
　前記認証子変換器は，シートに画像を形成する画像形成装置が備える制御手段を有するユニットに設けられていることを特徴とする請求項１ないし７のいずれか１項に記載の認証システム。
　　【請求項９】
　前記認証器は，シートに画像を形成する画像形成装置が備える制御手段を有するユニットに設けられていることを特徴とする請求項１ないし８のいずれか１項に記載の認証システム。
　　【請求項１０】
　前記認証器は，シートに画像を形成する画像形成装置と接続された外部装置に設けられていることを特徴とする請求項１ないし８のいずれか１項に記載の認証システム。」（以下，上記引用の請求項各項を，「補正後の請求項」という）に補正された。
　
２．補正の適否
（１）新規事項及び目的要件について
　本件手続補正は，補正前の請求項１に記載の「第２認証子を生成」することに対して，
「前記被認証器から送信された前記第１の認証データの前記所定データと前記認証器から送信された前記チャレンジデータを，前記共通鍵を用いた共通鍵暗号方式で計算して第１比較認証子を生成し，生成した前記第１比較認証子と，前記第１の認証データの前記第１認証子と，を比較し，前記第１比較認証子と前記第１認証子が一致した場合に」という限定を付加して補正後の請求項１とすると共に，補正前の請求項２を削除し，補正前の請求項３に，上記指摘の補正前の請求項１に付加した限定事項と同等の限定事項を付加して，補正後の請求項２とした上で，補正前の請求項４を削除し，補正前の請求項５〜補正前の請求項１２を，補正後の請求項３〜補正後の請求項１０とし，その他，補正後の請求項１，及び，補正後の請求項２において，明確でないと指摘された事項を明確とするものであって，本件手続補正は，願書に最初に添付された明細書，特許請求の範囲，及び，図面に記載した事項の範囲内でなされたものであるから，特許法第１７条の２第３項の規定を満たすものであり，
　加えて，本件手続補正は，上記検討の如く，請求項の削除，特許請求の範囲の減縮（特許法第３６条第５項の規定により請求項に記載した発明を特定するために必要な事項を限定するものであって，その補正前の当該請求項に記載された発明とその補正後の当該請求項に記載される発明の産業上の利用分野及び解決しようとする課題が同一であるものに限る），及び，明りょうでない記載の釈明（拒絶理由通知に係る拒絶の理由に示す事項についてするものに限る）を目的とするものであるから，
　本件手続補正は，特許法第１７条の２第５項の規定を満たすものである。
　そこで，本件手続補正が，特許法第１７条の２第６項において準用する同法第１２６条第７項の規定を満たすものであるか否か，即ち，補正後の請求項１に記載されている事項により特定される発明が特許出願の際独立して特許を受けることができるものであるか否か，以下に検討する。
　
（２）独立特許要件
ア．補正後の請求項１に係る発明
　補正後の請求項１に係る発明（以下，これを「本件補正発明」という）は，上記「１．補正の内容」において，補正後の請求項１として引用した，次のとおりのものである。
　
「第１の認証データを生成する被認証器と，
　前記被認証器にて生成された前記第１の認証データに基づき前記被認証器を認証し，前記第１の認証データを第２の認証データに変換する認証子変換器と，
　前記認証子変換器にて変換された前記第２の認証データに基づいて，認証処理を行う認証器と，を備え，
　前記第１の認証データは，第１認証子と前記被認証器が有する所定データとを含み，
　前記被認証器は，前記認証器から送信されたチャレンジデータと前記所定データを，共通鍵を用いた共通鍵暗号方式で計算して前記第１認証子を生成し，生成した前記第１認証子と前記所定データとを前記第１の認証データとして前記認証子変換器に送信し，
　前記第２の認証データは，第２認証子と前記被認証器が有する前記所定データとを含み，
　前記認証子変換器は，秘密鍵を有し，前記被認証器から送信された前記第１の認証データの前記所定データと前記認証器から送信された前記チャレンジデータを，前記共通鍵を用いた共通鍵暗号方式で計算して第１比較認証子を生成し，生成した前記第１比較認証子と，前記第１の認証データの前記第１認証子と，を比較し，前記第１比較認証子と前記第１認証子が一致した場合に，前記被認証器から送信された前記第１の認証データの前記所定データと前記認証器から送信された前記チャレンジデータを前記秘密鍵を用いた公開鍵暗号方式で計算して前記第２認証子を生成し，生成した前記第２認証子と前記所定データとを前記第２の認証データとして前記認証器に送信し，
　前記認証器は，公開鍵を有し，前記認証子変換器から送信された前記第２の認証データの前記所定データと前記認証子変換器に送信した前記チャレンジデータとを結合し，前記認証子変換器から送信された前記第２の認証データの前記第２認証子を前記公開鍵を用いて復号し，復号した結果と，前記結合したデータとを比較して前記認証処理を行うことを特徴とする認証システム。」
　
イ．引用文献に記載の事項
（ア）原審における平成２８年１２月１６日付けの拒絶理由（以下，これを「原審拒絶理由」という）に引用された，本願の出願前に既に公知である，特開２００２−２０８９２６号公報（平成１４年７月２６日公開，以下，これを「引用文献１」という）には，関連する図面と共に，次の事項が記載されている。
　
Ａ．「【０００１】
【発明の属する技術分野】本発明は，インターネットなどのデータ通信におけるセキュリティに関する。
【０００２】
【従来の技術】現在では，インターネットを利用した電子商取引が普及してきているが，その取引において重要なのが，取引相手が本人であることを証明し，改ざんを防ぐセキュリティである。このセキュリティとしては，公開鍵暗号方式（ＰＫＩ）による電子署名や生体認証（指紋や虹彩，声紋，脈など）を利用した認証方法が使われている。
【０００３】
【発明が解決しようとする課題】現状における電子署名のアルゴリズムは，いまだ標準化された仕様がなく，アプリケーションごとに独立した電子署名機能が実現されてるのが実状で，互換性がないために利便性が犠牲になっている点が問題である。たとえば，携帯電話や携帯情報端末（ＰＤＡ）のチップカード（ＩＣカード）に公開鍵あるいは秘密鍵を組み込む場合，アプリケーション（取引相手）ごとにチップカードを差し替えるというような事態になってしまう。
【０００４】また，使用している電子署名の方式がクラッカーにより破られた場合，全取引相手に対する電子署名の使用中止，新たなセキュリティの構築などに多大なコストと時間を要することになり，その間の取引停止による損害はばかにならない。携帯電話など手軽な通信端末から簡単に金融情報へアクセスできる現在では，多額の損害が発生する危険性も非常に高まっている。
【０００５】一方，生体認証をセキュリティに使用する場合，たとえば，指がない人や仕事柄指紋がすり減ってしまっている人に指紋認証を適用することなどないよう配慮する必要があるが，これを実現しているシステムはまだない。
【０００６】本発明ではこれらの課題を解決し，今以上に堅牢で万人に適したセキュリティの方法を提案するものである。
【０００７】
【課題を解決するための手段】本発明によれば，上記課題の解決手段として，
多種類の電子署名方式を記憶した記憶手段をもち，その記憶されている各電子署名方式間の変換を行えるようにしたコンピュータを通信端末間の通信仲介役として備え，この仲介役コンピュータが，一方の通信端末から電子署名を受信し，該電子署名を所定の方式に変換して他方の通信端末へ送信する
一方の取引者が銀行であり，他方の取引者として消費者との間でセキュリティセッションをはる場合に，消費者のもつ通信端末が携帯電話でそのシステムが当該銀行の電子署名方式に対応していなかったとしても，仲介役コンピュータが間に入り，銀行端末からの電子署名を受けて消費者の携帯電話に適した方式に変換することで，支障なくセキュリティで保護された通信を行うことができる
　
Ｂ．「【００１２】
【発明の実施の形態】図１に，本発明の認証方法を実行するシステムの概要を示し説明する。
【００１３】多数の端末からインターネットや専用線を介してアクセス可能とした仲介役サーバが設けられ，仲介役コンピュータとして働いている。この仲介役サーバは，公開鍵暗号方式による電子署名の認証局である認証局Ａ，Ｂ，Ｃと連係しており，その認証局ごとに異なる電子署名方式のアルゴリズムをハードディスクなどの記憶手段に記憶し，対応する証明書を発行することができるようになっている。また，認証局Ｄは本例では生体認証の認証局であり，この認証局Ｄと仲介役サーバが連係することで，その生体認証方式を仲介役サーバで実行することができるようになっている。これら認証局Ａ〜Ｄと仲介役サーバとの間の通信も，公開鍵暗号方式によるセキュリティがかけられているが，各認証局の暗号化アルゴリズムに仲介役サーバ独自の乱数を加えることで，外部アタックを跳ね返す堅牢なシェルター構造が形成されている。
【００１４】このような仲介役サーバに対し，Ｘ銀行，Ｙクレジット，Ｚ証券，そして消費者が契約することでその各所有通信端末…Ｘ銀行端末，Ｙクレジット端末，Ｚ証券端末，消費者端末がアクセスし，互いに取引を行うことが可能となる。一例として，Ｙクレジットと消費者との間の通信を例にして説明する。
【００１５】Ｙクレジット端末の電子署名方式は認証局Ａの方式（電子署名方式Ａ）であるが，消費者端末はこれに対応しておらず，認証局Ｂの方式（電子署名方式Ｂ）であれば対応しているとする。この場合，Ｙクレジット端末と消費者端末が直接通信を行ったのではセキュリティを構築することができない。そこで，仲介役サーバが間に入って電子署名の翻訳を実行する。すなわち，まず
Ｙクレジット端末と仲介役サーバとの間で電子署名方式Ａによる通信が実施され，Ｙクレジット端末の方式Ａによる公開鍵が証明書付で仲介役サーバへ渡される。証明書が確認されると，公開鍵により復号化が実施され，複合化（当審注；「復号化」の誤記である）した通信メッセージが一旦仲介役サーバに記憶される
仲介役サーバと消費者端末との間には電子署名方式Ｂによるセキュリティがはられ，Ｙクレジット端末からの通信メッセージを復号化した仲介役サーバは，そのメッセージを方式Ｂによる秘密鍵により暗号化し，消費者端末へ送信する。消費者端末では，仲介役サーバから方式Ｂによる公開鍵が証明書付で入手されるので，証明書確認後，その公開鍵により復号化を実施する
【００１６】このようにすることで，消費者自身には仲介役サーバが介在していることを意識させることなく，あたかもＹクレジットと直接通信しているかのようにして，セキュリティセッションを構築することができる。なお，Ｙクレジット端末と仲介役サーバとの公開鍵−秘密鍵の関係は逆でもよいし，両方が公開と秘密の鍵ペアをもち，サーバ認証とクライアント認証の両方を行う相互認証となっていても同様である。」
　
（イ）原審拒絶理由に引用された，本願の出願前に既に公知である，「Davis, D. W. and Price, W. L., ネットワーク・セキュリティ，日経マグロウヒル社，1985年12月5日, p.114-116, p.126-129」（以下，これを「引用文献２」という）には，関連する図面と共に，次の事項が記載されている。
　
Ｃ．「図5.1は認証子による方法の原理を示す。それは関数Ａ（ｋ，Ｍ）によって表わされた公開アルゴリズムに基づいている。鍵ｋは送り手と受け手に知られているが，敵には知られていない。認証されるべき通信文Ｍはどんな長さでもよいし，関数Ａ（ｋ，Ｍ）は通信文のビットすべてに依存する必要がある。関数Ａは通信文の宛先に同行する認証子である。受信者はまたＡ（ｋ，Ｍ）を計算し，受信したＡとこれを比較する。もし，等しければ通信文を受け取る。」（１１４頁３１行〜３５行）
　
Ｄ．「乱数の使用によるエンティティ認証
　大きな組織では，認証は鍵の配布センター（第６章参照）から得られるセッション鍵に頼ることができるので，それぞれのエンティティは通信するものすべてについて鍵を必要とするわけではない。その代わりに，公開鍵（第８章参照）を使用して鍵の配布問題を単純化できる。こういった状況下では通常，それぞれの通信エンティティが別個の通し番号を維持することは実際的ではない。同一の鍵を使用して各通信文を他とは異なるようにする必要性は，乱数を含めることで（高い確率で）満たされる。例えば，図5.8に示す3つの通信文のトランザクションを考えてみよう。トランザクションの開始者は乱数Ｒを含んでおり，これは応答の一部として返される。各通信文は乱数を含む内容をすべてカバーする認証子を持っており，通信ネットワーク内容への干渉を探知できるようになっている。その乱数を返答することで，開始者はそれが実際のエンティティからの応答であり，従前の応答から再録できないことを保証する。この場合，乱数フィールドの大きさは誕生日の逆説（4.7節参照）による。もし，同一の鍵を使用するＮ個のトランザクションがあるなら，乱数フィールドは反復の確率を低い値に下げるため，Ｎ２以上の大きさにしなければならない。
　双方向の認証では，他のエンティティは応答の中に乱数Ｓを入れ，反復ではなく新たにトランザクションを開始した保証として，トランザクションの3番目の通信文で返さなければならない。他の乱数が見せかけである場合には，それぞれのエンティティは自分自身の乱数をプロトコルに挿入する。
　Ｍ１が以前のトランザクション開始の通信文の再送である可能性を考えてみよう。無邪気な受け手はＲに対する正しい応答と新しい乱数Ｓを含めてＭ２を返す。Ｍ３を応答として受信した場合に，Ｍ３は新しい認証子の値Ａ３を生成するために必要な秘密鍵をもつエンティティから来たものでなければならない。もし，Ｍ１が偽であったとすれば，これがその鍵の本当の所有者だろうか？Ｍ１を送信していない限り，鍵の所有者はＭ２を有効であるとして受け入れはしないだろう。したがって，鍵の本当の所有者がＭ１を発したことは間違いなく，有効であるとして受け入れることができる。しかし，Ｍ３を受信しチェックするまで，Ｍ１を有効として受け入れないことが重要である。例えば，Ｍ１がデータベースを更新する要求だとしたら，Ｍ３が到着するまで待つべきである。
　さらに後続の通信文でトランザクションを続けるなら，前に記した方法によりそれらを以前の通信文にチェインする必要があるだろう。
　誕生日の逆説のため，鍵の所与の有効期間について必要なフィールドの大きさは乱数の使用によりおよそ2倍になる。セッション鍵を1つのトランザクションだけに使用する場合，乱数を通常の認証子以上の大きさにする必要はないので，これでも問題はない。」（１２８頁１３行〜１２９頁１５行）
　
Ｅ．「
」
　
（ウ）原審拒絶理由に引用された，本願の出願前に既に公知である，米国特許第６７２５２７６号明細書（２００４年４月２０日公開，以下，これを「引用文献３」という）には，関連する図面と共に，次の事項が記載されている。
　
Ｆ．「In particular,  FIG.1 schematically shows a preferred network that may be utilized to implement preferred embodiments of the invention. In particular, the network includes a first multicast domain (“first domain 10”) and a second multicast domain (“second domain 12”) that each operate in accord with any conventional multicast protocol. In preferred embodiments, both. domains operate in accord with the well known Protocol Independent Multicast protocol (also known as the “PIN protocol”当審注；“PIM protocol”の誤記である). It should be noted, however, that although preferred embodiments are discussed in terms of the PIM protocol, principles of the invention may be applied to other multicast protocols, such as the Internet Protocol multicast protocol (“IP Multicast”). The PIM protocol therefore is discussed for exemplary purposes only and is not intended to limit the scope of preferred embodiments. 
Each of the two multicast domains 10 and 12 includes a rendezvous point router 14 for distributing multicast parameters and forming the multicast distribution tree, a bootstrap router 16 for selecting and identifying the rendezvous point router 14, and a plurality of PIM routers 18 that operate in accord with the PIM protocol. The network also may include one or more non-PIM routers (not shown) that merely forward PIM multicast messages toward the PIM routers 18. In addition, the first domain 10 includes a first domain border router (“first border router 20”) that cooperates with a second domain border router (“second border router 22”) within the second domain 12 to translate arid当審注；「and」の誤記である authenticate inter-domain communication. The first and second border routers 20 and 22 preferably are PIM routers 18 that each are configured to operate as a border router. Although only one border router is shown in each domain, each domain may include additional border routers and still operate in accord with preferred embodiments of the invention. Moreover, the border routers 20 and 22 may communicate in many manners, such as via a direct connection, a larger network (e.g., the Internet), one or more intervening multicast domains, or other known methods. In some embodiments, one border. router is utilized for both domains. It should be noted that all network devices in each domain are interconnected (e.g., via a direct connection or via the Internet) to execute a multicast. Each router 18 preferably is coupled to a local user group (e.g., a local area network) that includes one or more client computer systems. 
As noted above, the two domains preferably execute the PIM protocol. Accordingly, routers 18 within each domain communicate via one or more messages that each have an appended tag. More particularly, each time a multicast is either initialized or re-keyed, the rendezvous point router 14 in a given PIM multicast domain transmits a symmetrical authentication key to each router 18 in the given domain. Each router 18 consequently utilizes the key to both authenticate messages received from other routers 18 in the domain, and to generate corresponding authentication tags that are appended to messages within the domain. For example, a message generated from a client computer system (coupled to a router 18) and that domain#s key may be utilized as input into a given keyed hash function that is only known by all routers in the multicast domain. The output of the keyed hash function (referred to above and below as a “tag”) then may be appended to the message prior to transmitting the message to a second router 18 in the domain. When used with the PIM protocol and similar multicast protocols, the tag is known in the art as a “Message Authentication Code”(“MAC”). 
Upon receipt of the message, the second router 18 similarly enters the key and message into the same keyed hash function, and then compares the output of such function to the tag appended to the message. If the tag matches the calculated output, then the message is considered to be authenticated. Accordingly, the second router 18 may forward the message to another router 18 in the domain. Conversely, if the tag does not match the calculated output, then the message is considered to be not authenticated. If not authenticated, then the second router 18 may drop the message (i.e., it neither processes the message nor forwards it to another network device). 
It should be noted that a message is considered to be “authentic” when received from an authorized network device within a given domain. Receipt of an authentic message from a given router 18 implies that such message originated from the given router 18. A message is deemed to originate from the given router 18 when the given router 18 appends a tag to such message, and then transmits such appended message to another network device. Accordingly, a message may be considered to originate from a given router 18 even when such router's tag has been replaced by another router's tag in another domain. As known in the art and noted above, a PIM router 18 does not append a tag to a message until determined to be authentic.」（４欄３４行〜５欄５５行）
（特に，図１は，本発明の望ましい実施例を実施するために利用され得る，好適なネットワークを模式的に示す。特に，ネットワークは，互いが従来型のマルチキャスト・プロトコルと一致して動作する，第１のマルチキャスト・ドメイン（“第１ドメイン１０”）と，第２のマルチキャスト・ドメイン（“第２ドメイン１２”）とを含む。好適な実施例において，両ドメインは，よく知られた，プロトコル独立マルチキャスト・プロトコル（別名“ＰＩＭプロトコル”）に従って動作する。しかしながら，注目すべきは，好適な実施例が，ＰＩＭプロトコルに関して，論じられてはいるが，本発明の本質は，インターネット・プロトコル・マルチキャスト・プロトコル（“ＩＰマルチキャスト”）のような，他のマルチキャスト・プロトコルに当てはまる。ＰＩＭプロトコルは，それ故に，典型的な目的のためだけについて論じられ，好適な実施例の範囲を制限することを目的とされるものではない。
　マルチキャスト・ドメイン１０，及び，１２のそれぞれは，マルチキャスト・パラメタを分配すること，及び，マルチキャスト分配木を形成することのためにランデヴー・ポイント・ルータ１４を，ランデヴー・ポイント・ルータ１４を選択し，識別することのために，ブートストラップ・ルータ１６を，そして，ＰＩＭプロトコルにしたがって動作する，複数のＰＩＭルータ１８を含む。ネットワークは，また，単に，ＰＩＭルータ１８への，ＰＩＭマルチキャスト・メッセージを転送するだけの，１以上の非ＰＩＭルータ（図示せず）を含む。加えて，第１ドメイン１０は，ドメイン間の通信を翻訳する，及び，認証するために，第２ドメイン１２内の第２ドメイン境界ルータ（“第２境界ルータ２２”）と協働する，第１ドメイン境界ルータ（“第１境界ルータ２０”）を含む。第１，及び，第２境界ルータ２０，及び，２２は，望ましくは，それぞれが，境界ルータとして動作するよう構成された，ＰＩＭルータ１８である。それぞれのドメイン内に，１つだけ境界ルータが示されているが，それぞれのドメインは，追加の境界ルータを含み，本発明の好適な実施例にしたがって，さらに動作し得る。さらに，境界ルータ２０，及び，２２は，直接接続，大規模ネットワーク（例えば，インターネット），１以上のマルチキャスト・ドメイン，或いは，他の知られた方法を介するような，多くの方法において，通信し得る。いくつかの実施例において，１つの境界ルータは，両方のドメインのために利用される。注目すべきは，それぞれのドメイン内のすべてのネットワーク・デバイスは，マルチキャストを実行するために，相互接続（例えば，直接接続を介して，或いは，インターネットを介して）されている。それぞれのルータ１８は，望ましくは，１以上のクライアント・コンピュータ・システムを含む，ローカル・ユーザ・グループ（例えば，ローカル・エリア・ネットワーク）と接続される。
　上述のように，２つのドメインは，望ましくは，ＰＩＭプロトコルを実行する。それに基づいて，それぞれのドメイン内のルータ１８は，それぞれが，添付のタグを有する，１以上のメッセージを介して，通信する。より具体的には，初期化するか，再鍵化する度に，与えられたＰＩＭマルチキャスト・ドメイン内のランデヴー・ポイント・ルータ１４は，与えられたドメイン内の，ルータ１８それぞれの，対称認証鍵を，転送する。ルータ１８それぞれは，それ故，ドメイン内の，他のルータ１８から受信した，双方の認証メッセージのため，及び，ドメイン内で，そのメッセージに添付されるために，一致する認証タグを生成するため，鍵を利用する。例えば，（ルータ１８に繋がれた）クライアント・コンピュータ・システムから生成されたメッセージと，そのドメインの鍵は，マルチキャスト・ドメイン内の全てのルータによってのみ知られている，与えられた鍵付ハッシュ関数への入力として，用いられるであろう。（“タグ”として，上記，及び，下記に言及する）鍵付ハッシュ関数の出力は，次に，そのドメイン内の第２のルータ１８に,メッセージを送信することに先立って，メッセージに添付される。ＰＩＭプロトコル，及び，類似のマルチキャスト・プロトコルと共に用いた時，タグは，“メッセージ認証コード”（“ＭＡＣ”）として，周知技術である。
　メッセージの受領次第，第２のルータ１８は，同様に，同一の鍵付ハッシュ関数に，鍵と，メッセージを入力し，次に，メッセージに添付のタグと，この関数の出力とを比較する。もし，タグが，計算した出力と一致すれば，そのとき，メッセージは認証されたと見なされる。その結果，第２のルータ１８は，そのドメイン内の，他のルータ１８に，そのメッセージを，転送し得る。逆に，もし，タグが，計算した出力と一致しなかったら，そのときは，メッセージは，認証されなかったと見なされる。もし，認証されなければ，そのとき，第２のルータ１８は，そのメッセージを破棄する（即ち，そのメッセージを処理することも，それを，他のネットワーク・デバイスに転送することもない。）
　注目すべきは，メッセージは，所定のドメインの範囲内で，認証されたネットワーク・デバイスから受信された時は，“本物である”と見なされる。所定のルータ１８からの正当なメッセージの受領は，当該メッセージが，所定のルータ１８が起源であることを暗示している。メッセージは，所定のルータ１８が，当該メッセージに，タグを添付する場合は，その所定のルータ１８が起源であると見なされ，その後，他のネットワーク・デバイスに，当該添付されたメッセージが，転送される。結果的に，メッセージは，当該ルータのタグが，他のドメイン内の，他のルータのタグに置き換えられた時でも，所定のルータ１８が起源であると見なされる。周知技術，及び，上記説明から，ＰＩＭルータ１８は，正当であると決定されるまで，タグを添付しない。当審にて訳出。以下，同じ。）
　
Ｇ．「In particular, FIG.4A shows an alternative method of authenticating messages transmitted between the first domain 10 and the second domain 12. The method begins at step 400 in which a sending router (in the first domain 10) with a message utilizes the private key of its public key pair to digitally sign the message in accord with well known methods. The digital signature preferably is added to the message as part of the message data 25 (i.e., payload) associated with the message. In addition, the first domain key is utilized as discussed above to generate a first domain MAC 32. The generated first domain MAC 32 then is appended to the digitally signed message, and forwarded to the first border router 20. In a manner similar to that noted above, each intervening PIM router 18 in the first domain 10 between the sending router and the first border router 20 authenticates the signed message via the first domain MAC. None of the intervening routers, however, checks the digital signature. 
The process then continues to step 402 in which the first border router 20 authenticates both the digital signature of the sending router, and the first domain MAC. If not authenticated, the message is dropped. If authenticated, then the first border router 20 removes both the digital signature of the sending router and the first domain MAC (step 404). In a manner similar to that performed by the sending router, the first border router 20 then adds its own digital signature as payload to the message, and transmits the resulting message to the second border router 22. In effect, by adding its digital signature to the message, the first border router 20 is vouching for the authenticity of the message as originating from sending router. Although not necessary, an intermediate MAC between the border routers may be appended (see FIGS.2 and 3A). 
The process then continues to step 406 in which the second border router 22 confirms (i.e., authenticates) the first border router signature in the received message. To that end, the second border router 22 retrieves the public key of the first border router 20. This key may be retrieved by many known means, such as from a certification authority, or through a well known Multicast Source Discovery Protocol connection (“MSDP connection”) between the rendezvous routers 14 in each domain. 
Once authenticated, the second border router 22 ascertains the second domain MAC 36 (e.g., via the second domain key, message, and keyed hash function), and appends it to the signed message (step 408) to form a final message 28. The final message 28 then is transmitted to the receiving router via any intervening routers or other second domain network devices. In accord with conventional PIM methods and as described above, each such intervening PIM router merely authenticates the message by examining the appended second domain MAC. The digital signature of the first border router 20 thus preferably is not examined by any such network devices. Once received, the receiving router preliminarily authenticates the final message 28 by accessing the appended second domain MAC (steps 410 and 412). 
At step 412, if the final message 28 is determined to be preliminarily authenticated, then the receiving router confirms the first border router's digital signature in a manner described above. Conversely, if the final message 28 is not authenticated at step 412, then the process continues to step 414, in which the message is dropped and thus, not delivered to a receiving computer system in the receiving router's local network. Moreover, if determined to be not authentic, then the digital signature of the first border router 20 may be utilized to confirm that the message was authentic at least until transmitted from the first border router 20. Use of the first border router signature in this manner therefore aids debugging processes that may be utilized if messages are dropped. 
FIG.4B shows the transformation of a message as it is processed by the method shown in FIG.4A. Specifically, the original message 24 includes message data 25 and the digital signature 38 of the sending router as a payload, and the first domain MAC 32. When utilizing an intermediate key for the border routers 20 and 22, the first border router 20 removes the first domain MAC 32 and adds an intermediate MAC 34. In addition, the first border router 20 removes the sending router digital signature 38, and adds its own digital signature 40. Finally, FIG.4B also shows the final message 28 with the second domain MAC 36 and the first border router digital signature 40.」（８欄４行〜９欄１９行）
（特に，図４Ａは，第１ドメイン１０と，第２ドメイン１２との間を転送されるメッセージを認証することの，別の方法を示している。その方法は，（第１ドメイン１０内の）送信ルータが，メッセージ共に，よく知られた方法に従って，メッセージに，電子署名をするために，それらの公開鍵ペアの秘密鍵を用いることで，ステップ４００において，始まる。電子署名は，望ましくは，そのメッセージに関連しているメッセージ・データ２５の一部（即ちペイロード）として，そのメッセージに加えられる。加えて，第１ドメイン鍵は，上で説明したように，第１ドメインＭＡＣ３２を生成するために，用いられる。生成された第１ドメインＭＡＣ３２は，次に，電子署名されたメッセージに添付され，第１境界ルータ２０に転送される。上で説明したのと似た方法で，送信ルータと，第１境界ルータ２０との間に介在する，それぞれの第１ドメイン内のＰＩＭルータ１８が，第１ドメインＭＡＣを介して，証明されたメッセージを認証する。しかしながら，介在するルータの何れもが，電子署名をチェックしない。
　プロセスは，次に，第１境界ルータ２０が，送信ルータの電子署名と，第１ドメインＭＡＣの両方を認証する，ステップ４０２に進む。もし，認証されなければ，メッセージは破棄される。もし，認証されれば，次に，第１境界ルータ２０は，送信ルータの電子署名と，第１ドメインＭＡＣの両方を取り除く（ステップ４０４）。送信ルータによって実行されたのと同様の方法で，第１境界ルータ２０は，次に，メッセージのペイロードとして，自身の電子署名を加え，第２境界ルータ２２に，結果としてのメッセージを転送する。実際には，そのメッセージに，それの電子署名を加えることによって，第１境界ルータ２０は，送信ルータを起源とするところのメッセージの正当性を保証している。必須ではないが，境界ルータ間の，仲介ＭＡＣが，添付され得る（図２，及び，図３Ａ参照）。
　プロセスは，次に，第２境界ルータ２２が，受信したメッセージ内の，第１境界ルータの署名を確認する（即ち，認証する），ステップ４０６に進む。その目的で，第２境界ルータ２２は，第１境界ルータの公開鍵を読み出す。この鍵は，例えば，認証機関から，或いは，それぞれのドメインにおける，ランデヴー・ルータ１４間の，周知のマルチキャスト・ソース・デリバリ・プロトコル接続（“ＭＳＤＰ接続”）を介するというような，いくつかの知られた方法によって，読み出され得る。
　認証されると，第２境界ルータ２２は，第２ドメインＭＡＣ３６を（例えば，第２ドメイン鍵，メッセージ，及び，鍵付ハッシュ関数を介して）確認し，最終メッセージ２８を形成するために，署名されたメッセージに，それを添付する（ステップ４０８）。最終メッセージ２８は，次に，任意の介在するルータ，或いは，他の第２ドメイン・ネットワーク・デバイスを介して，受信ルータに転送される。従来のＰＩＭ方法を踏まえ，及び，上に述べたことから，それぞれの，かかる介在ＰＩＭルータは，単に，添付された第２ドメインＭＡＣを試験することによって，そのメッセージを認証しているに過ぎない。第１境界ルータ２０の電子署名は，それ故，望ましくは，そのような，他のネットワーク・デバイスによって，試験されることはない。受信されると，受信ルータは，添付された第２ドメインＭＳＡＣにアクセスすることで，最終メッセージ２８を，予め，認証する。（ステップ４１０，及び，４１２）。
　ステップ４１２で，もし，最終メッセージ２８が，予め認証されることが決定されれば，そのとき，受信ルータは，上に述べた方法で，第１境界ルータの電子署名を確認する。逆に，もし，最終メッセージ２８が，ステップ４１２で，認証されなければ，次に，プロセスは，メッセージが破棄され，それ故，受信ルータ内の受信コンピュータ・システムへ届けられない，ステップ４１４へ進む。さらに，もし，正当でないと決定されれば，そのとき，第１境界ルータ２０の電子署名は，メッセージが，少なくとも，第１境界ルータ２０から送信されるまでは，正当であったことを，確認するために利用される。この方法において，第１境界ルータの署名を用いることは，その結果，メッセージが破棄された場合に用いられ得る，デバッギング・プロセスの助けとなる。
　図４Ｂは，図４Ａに示される方法によって処理されるような，メッセージの変形を示している。特に，オリジナル・メッセージ２４は，メッセージ・データ２５，ペイロードとして，送信ルータの電子署名３８，及び，第１ドメインＭＡＣ３２を含んでいる。境界ルータ２０，及び，２２のための中間鍵を使用するとき，第１境界ルータ２０は，第１ドメインＭＡＣ３２を取り除き，中間ＭＡＣ３４を付加する。加えて，第１境界ルータ２０は，送信ルータ電子署名３８を取り除き，自身の電子署名４０を付加する。最後に，図４Ｂは，また，第２ドメインＭＡＣ３６と，第１境界ルータの電子署名４０を備える，最終メッセージ２８を示している。）
　
（エ）本願の出願前に既に公知である，「岡本栄司，暗号理論入門，共立出版株式会社，1993年2月25日，p.129-131」（以下，これを「周知文献１」という）には，関連する図面と共に，次の事項が記載されている。
　
Ｈ．「７．１メッセージ認証
　メッセージ認証（messsage authentication）とは，メッセージの正当性を確認する技術であり，認証子法と冗長暗号化法が実用化されている．
　
　７．７．１　認証子法
　証明者は認証子（ＭＡＣ：messsage authentication code）と呼ばれるコードを作成してメッセージとともに送る．それを受けて検証者は，メッセージから同様に認証子を作成して，それが送られた認証子と一致するか否かで，メッセージの正当性（改ざんの有無）を判定する．図７．１は認証子法を示している．
　認証子を作成するには，秘密鍵をパラメータとするハッシュ（hash）関数を使用する．すなわち，秘密鍵（認証鍵）Ｋを送信側と受信側で共有し，それを用いて認証子を作成するが，鍵Ｋを知らなければメッセージＭと認証子ｈｋ（Ｍ）から，異なるＭ’と対応するｈｋ（Ｍ’）を作れないような関数ｈｋである．」（１２９頁１２行〜１３０頁４行）
　
（オ）本願の出願前に既に公知である，特開平１１−３３９０４５号公報（平成１１年１２月１０日公開，以下，これを「周知文献２」という）には，関連する図面と共に，次の事項が記載されている。
　
Ｉ．「【００１０】公開鍵暗号による電子署名は，以下の様に用いられる。以下では電子署名の作成者が，電子署名の検定者に渡したいデータのことを平文と呼ぶ。
【００１１】先ず作成者は平文を秘密鍵で暗号化する。この平文を暗号化することにより生成されたデータを暗文と呼ぶ。この暗文が「電子署名」である。作成者は，平文と暗文（電子署名）を検定者に渡す。この平文と暗文の組合せを，以降，「電子署名データ」と呼ぶ。
【００１２】次に検定者は，受け取った電子署名データの内，電子署名を作成者の公開鍵で復号する。作成者の公開鍵は，予め，または，電子署名データと共に，検定者に渡される。
【００１３】次に検定者は，平文と電子署名を復号することにより得られたデータを比較する。以下では，この比較において，互いが一致することを検定の成功と呼び，一致しないことを検定の失敗と呼ぶ。
【００１４】検定が成功したならば，以下のことがわかる。第一に，平文が改竄されていないことがわかる。平文を改竄すれば，電子署名の復号結果と一致しないからである。第二に，電子署名の作成者が，検定に用いた公開鍵と暗号鍵ペアを成す秘密鍵の所有者であることがわかる。何故なら，その公開鍵で復号できる暗文は，その公開鍵と暗号鍵ペアを成す秘密鍵で作成したものだけであることが，一般に公開鍵暗号アルゴリズムでは保証されているからである。」
　
ウ．引用文献１に記載の発明
（ア）上記Ａの「多種類の電子署名方式を記憶した記憶手段をもち，その記憶されている各電子署名方式間の変換を行えるようにしたコンピュータを通信端末間の通信仲介役として備え，この仲介役コンピュータが，一方の通信端末から電子署名を受信し，該電子署名を所定の方式に変換して他方の通信端末へ送信する」という記載，及び，同じく，上記Ａの「一方の取引者が銀行であり，他方の取引者として消費者との間でセキュリティセッションをはる場合に，消費者のもつ通信端末が携帯電話でそのシステムが当該銀行の電子署名方式に対応していなかったとしても，仲介役コンピュータが間に入り，銀行端末からの電子署名を受けて消費者の携帯電話に適した方式に変換することで，支障なくセキュリティで保護された通信を行うことができる」という記載から，引用文献１には，
“消費者のもつ通信端末である携帯電話と，銀行の通信端末である銀行端末との通信仲介役の仲介役コンピュータを設け，前記仲介役コンピュータは，前記銀行端末からの電子署名を受信し，受信した前記電子署名を，前記携帯電話に適した方式に変換して，前記携帯電話に送信する”ことが記載されているといえる。
　
（イ）上記Ｂの「Ｙクレジット端末と仲介役サーバとの間で電子署名方式Ａによる通信が実施され，Ｙクレジット端末の方式Ａによる公開鍵が証明書付で仲介役サーバへ渡される。証明書が確認されると，公開鍵により復号化が実施され，複号化した通信メッセージが一旦仲介役サーバに記憶される」という記載，及び，同じく，上記Ｂの「仲介役サーバと消費者端末との間には電子署名方式Ｂによるセキュリティがはられ，Ｙクレジット端末からの通信メッセージを復号化した仲介役サーバは，そのメッセージを方式Ｂによる秘密鍵により暗号化し，消費者端末へ送信する。消費者端末では，仲介役サーバから方式Ｂによる公開鍵が証明書付で入手されるので，証明書確認後，その公開鍵により復号化を実施する」という記載から，引用文献１には，
“Ｙクレジット端末と，消費者端末とが仲介役サーバを介して接続されたシステムであって，
　前記Ｙクレジット端末から，前記仲介役サーバへ，電子署名方式Ａによる電子署名と，Ｙクレジット端末の秘密鍵で暗号化された暗号化メッセージが送信され，前記仲介役サーバは，受信した前記電子署名方式Ａによる電子署名を確認し，前記電子署名方式Ａによる電子署名が正当であった場合，Ｙクレジット端末の公開鍵で，前記暗号化メッセージを復号し，復号したメッセージを，前記仲介サーバの秘密鍵で暗号化し，前記電子署名方式Ａによる電子署名に替えて，電子署名方式Ｂによる電子署名を付して，前記暗号化メッセージを送信し，前記消費者端末は，受信した前記電子署名方式Ｂによる電子署名を確認するシステム”が記載されていると言える。
　
（ウ）上記（ア）において検討した，「消費者のもつ通信端末である携帯電話」，「銀行の通信端末である銀行端末」，及び，「仲介役コンピュータ」が，それぞれ，上記（イ）おいて検討した，「消費者端末」，「Ｙクレジット端末」，及び，「仲介役サーバ」に相当しており，「銀行の通信端末である銀行端末」，或いは，「Ｙクレジット端末」は，「業者側端末」といえ，「消費者のもつ通信端末である携帯電話」，或いは，「消費者端末」は，「消費者側端末」といえ，そして，「仲介役コンピュータ」，或いは，「仲介役サーバ」は，「仲介装置」といえるものであるから，上記（ア），及び，上記（イ）において検討した事項を踏まえると，引用文献１には，次の発明（以下，これを「引用発明」という）が記載されているものと認める。
　
「業者側端末と，消費者側端末とが，仲介装置を介して接続されたシステムであって，
　前記業者側端末から，前記仲介装置へ，電子署名方式Ａによる電子署名と，業界側端末の秘密鍵で暗号化された暗号化メッセージが送信され，
　前記仲介装置は，受信した前記電子署名方式Ａによる電子署名を確認し，前記電子署名方式Ａによる電子署名が正当であった場合，業界側端末の公開鍵で，前記暗号化メッセージを復号し，復号したメッセージを，前記仲介装置の秘密鍵で暗号化し，前記電子署名方式Ａによる電子署名に替えて，電子署名方式Ｂによる電子署名を付して，前記暗号化メッセージを，前記消費者側端末へ送信し，
　前記消費者端末は，受信した前記電子署名方式Ｂによる電子署名を確認するシステム。」
　
エ．本件補正発明と引用発明との対比
（ア）引用発明における「業者側端末」は，結果として，「消費者側端末」に，その「電子署名」を確認される，即ち，認証されることになるので，
　引用発明における「業者側端末」，「消費者側端末」が，それぞれ，本件補正発明における「被認証器」，「認証器」に相当する。
　
（イ）引用発明における「仲介装置」は，「業者側端末」の「電子署名」を確認，即ち，認証し，その後，当該「電子署名」を，「消費者側端末」が確認できる「電子署名」に置き換えているので，本件補正発明における「認証子変換器」に対応する。
　
（ウ）引用発明においても，「業者側端末」は，「電子署名方式Ａによる電子署名」を生成するものであって，
　引用発明における「電子証明方式Ａによる電子署名」と，
　本件補正発明における「第１の認証データ」とは，
“第１認証情報”である点で共通するので，
　引用発明において，“業者側端末が，電子署名方式Ａによる電子署名を生成する”ことと，
　本件補正発明における「第１の認証データを生成する被認証器」とは，
“第１認証情報を生成する被認証器”である点で共通する。
　
（エ）引用発明において，「仲介装置」が，「電子署名方式Ａによる電子署名」を確認することは，即ち，「業者側端末」が，正当な送信者であることを確認，即ち，認証することに他ならなず，
　引用発明における「電子署名方式Ｂによる電子署名」と，
　本件補正発明における「第２の認証データ」とは，
　“第２認証情報”である点で共通するものであるから，
　引用発明において，「仲介装置は，受信した前記電子署名方式Ａによる電子署名を確認し，前記電子署名方式Ａによる電子署名が正当であった場合，前記電子署名方式Ａによる電子署名に替えて，電子署名方式Ｂによる電子署名を付」すことと，
　本件補正発明における「被認証器にて生成された前記第１の認証データに基づき前記被認証器を認証し，前記第１の認証データを第２の認証データに変換する認証子変換器」とは，
“被認証器にて生成された第１認証情報に基づき前記被認証器を認証し，前記第１認証情報を第２認証情報に変換する認証子変換器”である点で共通する。
　
（オ）引用発明における「消費者端末は，受信した前記電子署名方式Ｂによる電子署名を確認する」と，
　本件補正発明における「認証子変換器にて変換された前記第２の認証データに基づいて，認証処理を行う認証器」とは，
“認証子変換器にて変換された第２認証情報に基づいて認証処理を行う認証器”である点で共通する。
　
（カ）引用発明において，「仲介装置」は，「秘密鍵」を用いて，「消費者側端末」へ送信する「メッセージ」を暗号化しているので，
　引用発明において，“仲介装置は，秘密鍵を有する”ことが，
　本件補正発明における「認証子変換器は，秘密鍵を有し」に相当する。
　
（キ）引用発明において，「消費者側端末」は，「受信した前記電子署名方式Ｂによる電子署名を確認」した後，「暗号化メッセージ」を，「仲介装置」の「公開鍵」で復号することになるから，
　引用発明において，“消費者側端末が，仲介装置の公開鍵を有する”ことは明らかであって，このことが，
　本件補正発明における「認証器は，公開鍵を有し」に相当する。
　
（ク）以上，上記（ア）〜（キ）において検討した事項から，本件補正発明と，引用発明との，一致点，及び，相違点は，次のとおりである。
　
［一致点］
　第１認証情報を生成する被認証器と，
　前記被認証器にて生成された前記第１認証情報に基づき前記被認証器を認証し，前記第１認証情報を第２認証情報に変換する認証子変換器と，
　前記認証子変換器にて変換された前記第２認証情報に基づいて，認証処理を行う認証器と，を備え，
　前記認証子変換器は，秘密鍵を有し，
　前記認証器は，公開鍵を有する，システム。
　
［相違点１］
“第１認証情報”に関して，
　本件補正発明においては，「第１の認証データは，第１認証子と前記被認証器が有する所定データとを含」むものであるのに対して，
　引用発明における「電子証明方式Ａによる電子署名」が，そのような構成を有するかについては，特に言及されていない点。
　
［相違点２］
　本件補正発明においては，「被認証器は，前記認証器から送信されたチャレンジデータと前記所定データを，共通鍵を用いた共通鍵暗号方式で計算して前記第１認証子を生成し，生成した前記第１認証子と前記所定データとを前記第１の認証データとして前記認証子変換器に送信」するものであるのに対して，
　引用発明においては，「業者側端末」の認証に「チャレンジ」を用いる点について，特に言及されていない点。
　
［相違点３］
“第２認証情報”に関して，
　本件補正発明においては，「第２の認証データは，第２認証子と前記被認証器が有する前記所定データとを含」むものであるのに対して，
　引用発明における「電子署名方式Ｂによる電子署名」が，そのような構成を有するかについては，特に言及されていない点。
　
［相違点４］
　本件補正発明においては，「被認証器から送信された前記第１の認証データの前記所定データと前記認証器から送信された前記チャレンジデータを，前記共通鍵を用いた共通鍵暗号方式で計算して第１比較認証子を生成し，生成した前記第１比較認証子と，前記第１の認証データの前記第１認証子と，を比較し，前記第１比較認証子と前記第１認証子が一致した場合に，前記被認証器から送信された前記第１の認証データの前記所定データと前記認証器から送信された前記チャレンジデータを前記秘密鍵を用いた公開鍵暗号方式で計算して前記第２認証子を生成し，生成した前記第２認証子と前記所定データとを前記第２の認証データとして前記認証器に送信」するものであるのに対して，
　引用発明においては，「仲介装置」における「電子署名方式Ａによる電子署名」の確認が，「共通鍵暗号方式」の「チャレンジ」の検証である点については，特に言及されていない点。
　
［相違点５］
　本件補正発明においては，「認証子変換器から送信された前記第２の認証データの前記所定データと前記認証子変換器に送信した前記チャレンジデータとを結合し，前記認証子変換器から送信された前記第２の認証データの前記第２認証子を前記公開鍵を用いて復号し，復号した結果と，前記結合したデータとを比較して前記認証処理を行う」ものであるのに対して，
　引用発明においては，「電子署名方式Ｂによる電子署名を確認する」ことについて，具体的に特定されていない点。
　
オ．相違点についての当審の判断
（ア）［相違点１］，及び，［相違点２］について
　上記Ｇに引用した引用文献３の記載内容は，“引用発明における「業者側端末」（本件補正発明にける「被認証器」）に相当する送信ルータから送信された，送信ルータの電子署名と，第１ドメインＭＡＣの両方を認証する”ことが示されていて，「ＭＡＣ」が，「認証子」であること，「ＭＡＣ」の認証は，共通鍵暗号方式であり，受信した情報から求めた値と，当該受信した情報とともに取得した「ＭＡＣ」とが一致するかによって行われるものであることは，上記Ｆに引用した引用文献３の記載内容，上記Ｃに引用した引用文献２の記載内容，或いは，上記Ｈに引用した周知文献１の記載内容にもあるように，本願の出願前に当業者には広く知られた技術事項である。
　また，引用文献２には，上記Ｄに引用した記載内容にあるように，乱数Ｒ（本件補正発明における「チャレンジ」に相当）を送信し，当該送信に対する応答（レスポンス）が，正当であるかを判断して，相手の正当性を確認する，チャレンジ・レスポンスについて言及されていて，当該チャレンジ・レスポンスは，本願の出願前に当業者には広く知られた技術事項である。
　そして，引用発明，引用文献２，及び，引用文献３は，何れも，通信相手の正当性を認証する技術に関するものであるから，引用発明において，署名検証に替えて，「ＭＡＣ」を用いたチャレンジ・レスポンスを採用し，「業者側端末」から，「仲介装置」へ送信する情報として，「業者側端末」で計算した「ＭＡＣ」と，「仲介装置」において，当該「ＭＡＣ」を計算するために必要なデータを送信するよう構成することは，当業者が適宜なし得る事項である。
　よって，［相違点１］，及び，［相違点２］は，格別のものではない。
　
（イ）［相違点３］，及び，［相違点４］について
　上記（ア）においても検討した，上記Ｇに引用した引用文献３には，“第１境界ルータが，送信ルータの電子署名と，第１ドメインＭＡＣの両方の認証を行い，認証された場合には，当該送信ルータの電子署名と，第１ドメインＭＡＣの両方を取り除いて，代わりに当該第１境界ルータの電子署名を添付して，第２境界ルータ（引用発明における「消費者側端末」，本件補正発明における「認証器」に相当）に送信する”ことが示されていて，引用発明は，「業者側端末」による「電子署名方式Ａによる電子署名」を，「仲介装置」において認証後，「消費者側端末」において認証可能な，「電子署名方式Ｂによる電子署名」に置き換えるものであるから，上記（ア）において検討した事項を踏まえれば，引用発明において，「業者側端末」と，「仲介装置」において採用した「ＭＡＣ」を用いた認証に成功した場合に，当該「ＭＡＣ」を，「電子署名方式Ｂによる電子署名」に置き換え，「消費者側端末」に，「電子署名方式Ｂによる電子署名」と，当該「電子署名」を検証するために必要な情報とを送信するよう構成することは，当業者が適宜なし得る事項である。
　よって，［相違点３］，及び，［相違点４］は，格別のものではない。
　
（ウ）［相違点５］について
　公開鍵暗号を用いた署名検証自体は，本願の出願前に当業者には周知の技術事項である（必要であれば，上記Ｉに記載内容を引用した周知文献２等を参照されたい）。
　したがって，上記（ア），及び，上記（イ）において検討した事項を踏まえれば，引用発明において，「業者側端末」と，「消費者側端末」において，チャレンジ・レスポンスによる認証を行う場合に，「消費者側端末」において，「仲介装置」から，送信されてきた「電子署名」を検証することで，結果として，「業者側端末」の正当性を認証するよう構成することは，当業者が適宜なし得る事項である。
　よって，［相違点５］は，格別のものではない。
　
（エ）以上，上記（ア）〜（ウ）において検討したとおり，［相違点１］〜［相違点５］はいずれも格別のものではなく，そして，本件補正発明の構成によってもたらされる効果も，当業者であれば当然に予測可能なものに過ぎず格別なものとは認められない。
　したがって，本件補正発明は，本願の特許出願前に日本国内又は外国において頒布された刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基づいて当業者が容易に発明をすることができたものであるので，特許法第２９条第２項の規定により，特許出願の際，独立して特許を受けることができない。
　
３．補正却下むすび
　したがって，本件手続補正は，特許法第１７条の２第６項において準用する同法第１２６条第７項の規定に違反するので，同法第１５９条第１項の規定において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　
　よって，補正却下の決定の結論のとおり決定する。
　
第３．原審拒絶査定の概略
　原審における平成２９年８月２２日付けの拒絶査定（以下，これを「原審拒絶査定」という）の概略は，次のとおりである。
「備考
●理由２（特許法第３６条第４項第１号）について
・請求項　１−１２
　補正後の請求項１には「前記認証子変換器にて変換された前記第２の認証データに基づいて，前記被認証器の認証を行う認証器」が記載されているところ，上記拒絶理由通知書において述べたとおり，本願明細書の発明の詳細な説明には，「前記認証子変換器にて変換された前記第２の認証データに基づいて，前記被認証器の認証を行う認証器」について，当業者が実施可能な程度に明確かつ十分に記載がなされていない。請求項３及びそれら請求項１，３を引用する請求項２，４−１２についても同様のことがいえる。
　よって，この出願の発明の詳細な説明は，依然として，当業者が請求項１−１２に係る発明を実施することができる程度に明確かつ十分に記載されたものでない。
・・・(中略）・・・
●理由３（特許法第３６条第６項第２号）について
・請求項　１−１２
　補正後の請求項１には「前記認証子変換器にて変換された前記第２の認証データに基づいて，前記被認証器の認証を行う認証器」及び「前記第２の認証データは，第２認証子と前記被認証器が有する前記所定データとを含み，
　前記認証子変換器は，秘密鍵を有し，前記被認証器から送信された前記所定データと前記認証器から送信された前記チャレンジデータを前記秘密鍵を用いた公開鍵暗号方式で計算して前記第２認証子を生成し」が記載されている。
　請求項１の記載「前記第２の認証データは，第２認証子・・・を含み」及び「前記認証子変換器は，秘密鍵を有し，・・・前記秘密鍵を用いた公開鍵暗号方式で計算して前記第２認証子を生成し」より，第２の認証データに基づいて行う認証は，その第２の認証データが含む，認証子変換器が，自ら有する秘密鍵を用いて計算した第２認証子に基づく認証であり，そのことから，第２認証子を生成した「認証子変換器」の認証である。
　しかしながら，請求項１の記載「前記認証子変換器にて変換された前記第２の認証データに基づいて，前記被認証器の認証を行う認証器」から，請求項１には，認証器が行う認証が，第２の認証データに基づいて行う認証であるにも関わらず，「被認証器」の認証であると記載されている。
　そうすると，「前記第２の認証データは，第２認証子・・・を含み」，「前記認証子変換器は，秘密鍵を有し，・・・前記秘密鍵を用いた公開鍵暗号方式で計算して前記第２認証子を生成」するにも関わらず，認証器が「前記第２の認証データに基づいて，前記被認証器の認証を行う」ということは，認証器が認証する対象について矛盾しており不明なものである。請求項３及びそれら請求項１，３を引用する請求項２，４−１２についても同様のことがいえる。
　よって，請求項１−１２に係る発明は明確でない。
●理由４（特許法第２９条第２項）について
・請求項　１−１２
・引用文献等　１−６
　補正後の請求項１に係る発明と引用文献１に記載された発明とは
「第１の認証データを生成する被認証器と，
　前記被認証器にて生成された前記第１の認証データを第２の認証データに変換する認証子変換器と，
　前記認証子変換器にて変換された前記第２の認証データに基づいて，認証を行う認証器と，を備え，
　前記第１の認証データは，第１認証子と前記被認証器が有する所定データとを含み，
　前記被認証器は，前記所定データを，暗号方式で計算して前記第１認証子を生成し，生成した前記第１認証子と前記所定データとを前記認証子変換器に送信し，
　前記第２の認証データは，第２認証子と前記被認証器が有する前記所定データとを含み，
　前記認証子変換器は，秘密鍵を有し，前記被認証器から送信された前記所定デーを前記秘密鍵を用いた公開鍵暗号方式で計算して前記第２認証子を生成し，生成した前記第２認証子と前記所定データを前記認証器に送信し，
　前記認証器は，公開鍵を有し，前記認証子変換器から送信された前記第２認証子を前記公開鍵を用いて復号し，復号した結果と，データとを比較して認証することを特徴とする認証システム。」
である点で一致し，以下に挙げる点で相違する。
（ａ）認証器が，請求項１に係る発明では「被認証器」の認証を行うものであるのに対して，引用文献１に記載された発明では「被認証器」の認証を行うものか，明らかでない点。
（ｂ）被認証器が，請求項１に係る発明では，「共通鍵を用いた共通鍵」暗号方式で計算して前記第１認証子を生成するのに対して，引用文献１に記載された発明では，暗号方式で計算して前記第１認証子を生成するものの，その暗号方式が「共通鍵を用いた共通鍵」暗号方式ではない点。
（ｃ）請求項１に係る発明において，被認証器が第１認証子の生成にあたり「前記認証器から送信されたチャレンジデータ」をも用い，認証変換器が第２認証子の生成にあたり「前記認証器から送信された前記チャレンジデータ」をも用い，認証器が「前記認証子変換器から送信された前記所定データと前記認証子変換器に送信した前記チャレンジデータとを結合」し，復号した結果と，「前記結合した」データとを比較しているのに対して，引用文献１に記載された発明では，それらの如く構成していない点。
　上記相違点について検討する。
（ａ）について
　上記拒絶理由通知書の請求項１に関し相違点（ａ）についての項で述べたとおり，理由２，３にて述べたように，そもそも本願において，認証器が「被認証器」の認証を行うということが，発明の詳細な説明に実施可能な程度に記載されておらず，請求項１の記載において矛盾した不明なものであることを考慮すれば，この点を実質的な相違点とすることはできない。
（ｂ）について
　上記拒絶理由通知書の請求項２に関して述べたと同様，引用文献２，３に記載の技術を参酌し，引用文献１に記載された発明において，電子署名方式Ａを，共通鍵によるものとして，被認証器が「共通鍵を用いた共通鍵」暗号方式で計算して前記第１認証子を生成するように構成することは，当業者にとって格別困難なことではない。
（ｃ）について
　上記拒絶理由通知書の請求項１に関し相違点（ｂ）についての項で述べたと同様，引用文献２に記載の技術を参酌し，被認証器が第１認証子の生成にあたり「前記認証器から送信されたチャレンジデータ」をも用い，認証変換器が第２認証子の生成にあたり「前記認証器から送信された前記チャレンジデータ」をも用い，認証器が「前記認証子変換器から送信された前記所定データと前記認証子変換器に送信した前記チャレンジデータとを結合」し，復号した結果と，「前記結合した」データとを比較するように構成することは，当業者にとって容易である。
　したがって，請求項１に係る発明は，引用文献１に記載された発明及び引用文献２，３に記載の技術に基づいて当業者が容易に想到し得たものであるから，特許法第２９条第２項の規定により特許を受けることができない。請求項２−１２に係る発明も，上記拒絶理由通知書において述べた同様のことから，引用文献１に記載された発明及び引用文献２−６に記載の技術に基づいて，当業者が容易に想到し得たものであり，特許法第２９条第２項の規定により特許を受けることができない。
・・・（中略）・・・
　
　　　　　　　　　　　　　＜引用文献等一覧＞
　１．特開２００２−２０８９２６号公報
　２．Davis, D. W. and Price, W. L., ネットワーク・セキュリティ，日経マグロウヒル社，1985年12月5日, p.114-116, p.126-129
　３．米国特許第６７２５２７６号明細書
　４．特表２００３−５０３９０１号公報
　５．特開平８−１０１８６８号公報
　６．特開２００８−１４６１７９号公報」
　
第４．原審拒絶査定についての当審の判断
１．３６条４項１号について
　平成２９年３月１３日付けの手続補正により補正された特許請求の範囲の請求項１においても，「第２認証子を前記公開鍵を用いて復号し，復号した結果と，前記結合したデータとを比較して前記被認証器を認証する」と記載されていて，この記載に従えば，本願の請求項１に係る発明においては，“認証器は，第２認証子を用いて，被認証器を認証するものである”と解される。
　これに対して，本願明細書の発明の詳細な説明の段落【００３７】〜段落【００４８】に記載の内容，及び，段落【００６７】〜段落【００７８】に記載の内容，特に，段落【００４４】，段落【００４７】，及び，段落【００７６】，段落【００７７】に記載の内容から，「認証器」は，「認証子変換器」内の「第２の耐タンパチップ」によって生成された「第２の認証子」の一致の判定を行うものであるから，当該本願明細書の発明の詳細な説明に記載の内容に従えば，本願明細書の発明の詳細な説明において，「第２の認証子」を用いて，「認証器」によって認証されているのは，「認証子変換器」である。
　そして，本願明細書の発明の詳細な説明には，「第２の認証子」を用いて，「認証器」が，「被認証器」を認証する手法については，明確に示されておらず，どのようにして，「認証器」が，「第２の認証子」用いて，「認証子変換器」を認証することで，結果として，「認証器」が，「被認証器」を認証することになるのか，不明である。
　よって，本願明細書の発明の詳細な説明は，依然として，経済産業省令で定めるところにより，その発明の属する技術分野における通常の知識を有する者がその実施をすることができる程度に明確かつ十分に記述したものでない。
　
２．３６条６項２号について
　上記１．において検討したとおり，平成２９年３月１３日付けの手続補正により補正された特許請求の範囲の請求項１には，
「第２認証子を前記公開鍵を用いて復号し，復号した結果と，前記結合したデータとを比較して前記被認証器を認証する」，
　と記載されているが，本願の請求項１，及び，本願の他の請求項に記載の内容を検討しても，「認証子変換器」において生成された「第２認証子」を用いて，どのようにして，「認証子変換器」において，「第１認証子」を用いて認証される「被認証器」を認証し得るのか，不明である。
　よって，本願の請求項１に係る発明は，依然として，明確ではない。
　
３．２９条２項について
ア．本願発明について
　平成２９年１１月２９日付けの手続補正は，上記のとおり却下されたので，本願の請求項１に係る発明（以下，これを「本願発明」という）は，平成２９年３月１３日付けの手続補正により補正された特許請求の範囲の請求項１に記載された，上記「第２．平成２９年１１月２９日付けの手続補正の却下の決定」の「１．補正の内容」において，補正前の請求項１として引用した，次のとおりのものである。
　なお，上記２．において検討したとおり，本願発明においては，明確でない構成が存在するものの，字句どおりのものとして，以下の検討を行う。
　
「第１の認証データを生成する被認証器と，
　前記被認証器にて生成された前記第１の認証データを第２の認証データに変換する認証子変換器と，
　前記認証子変換器にて変換された前記第２の認証データに基づいて，前記被認証器の認証を行う認証器と，を備え，
　前記第１の認証データは，第１認証子と前記被認証器が有する所定データとを含み，
　前記被認証器は，前記認証器から送信されたチャレンジデータと前記所定データを，共通鍵を用いた共通鍵暗号方式で計算して前記第１認証子を生成し，生成した前記第１認証子と前記所定データとを前記認証子変換器に送信し，
　前記第２の認証データは，第２認証子と前記被認証器が有する前記所定データとを含み，
　前記認証子変換器は，秘密鍵を有し，前記被認証器から送信された前記所定データと前記認証器から送信された前記チャレンジデータを前記秘密鍵を用いた公開鍵暗号方式で計算して前記第２認証子を生成し，生成した前記第２認証子と前記所定データを前記認証器に送信し，
　前記認証器は，公開鍵を有し，前記認証子変換器から送信された前記所定データと前記認証子変換器に送信した前記チャレンジデータとを結合し，前記認証子変換器から送信された前記第２認証子を前記公開鍵を用いて復号し，復号した結果と，前記結合したデータとを比較して前記被認証器を認証することを特徴とする認証システム。」
　
イ．引用刊行物に記載の発明
　原審拒絶理由において引用された，特開２００２−２０８９２６号公報（平成１４年７月２６日公開）には，上記「第２．平成２９年１１月２９日付けの手続補正の却下の決定」の「２．補正の適否」の「（２）独立特許要件」における「ウ．引用文献１に記載の発明」において認定したとおりの，次の引用発明が記載されている。
　
「業者側端末と，消費者側端末とが，仲介装置を介して接続されたシステムであって，
　前記業者側端末から，前記仲介装置へ，電子署名方式Ａによる電子署名と，業界側端末の秘密鍵で暗号化された暗号化メッセージが送信され，
　前記仲介装置は，受信した前記電子署名方式Ａによる電子署名を確認し，前記電子署名方式Ａによる電子署名が正当であった場合，業界側端末の公開鍵で，前記暗号化メッセージを復号し，復号したメッセージを，前記仲介装置の秘密鍵で暗号化し，前記電子署名方式Ａによる電子署名に替えて，電子署名方式Ｂによる電子署名を付して，前記暗号化メッセージを，前記消費者側端末へ送信し，
　前記消費者端末は，受信した前記電子署名方式Ｂによる電子署名を確認するシステム。」
　
ウ．本願発明と引用発明との対比
　本願発明は，本件補正発明における，
「第１の認証データに基づき前記被認証器を認証し，前記第１の認証データを第２の認証データに変換する」，
「第２の認証データに基づいて，認証処理を行う」，
「生成した前記第１認証子と前記所定データとを前記第１の認証データとして前記認証子変換器に送信し」，
「第１の認証データの前記所定データと前記認証器から送信された前記チャレンジデータを前記秘密鍵を用いた公開鍵暗号方式で計算して前記第２認証子を生成し」，
「生成した前記第２認証子と前記所定データとを前記第２の認証データとして前記認証器に送信し」，
「第２の認証データの前記所定データと前記認証子変換器に送信した前記チャレンジデータとを結合し」，
「第２の認証データの前記第２認証子を前記公開鍵を用いて復号し」，
「認証処理を行う」，
　を，
「第１の認証データを第２の認証データに変換する」，
「第２の認証データに基づいて，前記被認証器の認証を行う」，
「生成した前記第１認証子と前記所定データとを前記認証子変換器に送信し」，
「前記所定データと前記認証器から送信された前記チャレンジデータを前記秘密鍵を用いた公開鍵暗号方式で計算して前記第２認証子を生成し」，
「生成した前記第２認証子と前記所定データとを前記認証器に送信し」，
「前記所定データと前記認証子変換器に送信した前記チャレンジデータとを結合し」，
「前記第２認証子を前記公開鍵を用いて復号し」，
「前記被認証器を認証する」，
　とし，本件補正発明における，
「前記被認証器から送信された前記第１の認証データの前記所定データと前記認証器から送信された前記チャレンジデータを，前記共通鍵を用いた共通鍵暗号方式で計算して第１比較認証子を生成し，生成した前記第１比較認証子と，前記第１の認証データの前記第１認証子と，を比較し，前記第１比較認証子と前記第１認証子が一致した場合に」，
　という構成を削除したものであるから，
　本願発明と，引用発明との，一致点，及び，相違点は，次のとおりである。
　
［一致点］
　第１認証情報を生成する被認証器と，
　前記被認証器にて生成された前記第１認証情報に基づき前記被認証器を認証し，前記第１認証情報を第２認証情報に変換する認証子変換器と，
　前記認証子変換器にて変換された前記第２認証情報に基づいて，認証を行う認証器と，を備え，
　前記認証子変換器は，秘密鍵を有し，
　前記認証器は，公開鍵を有する，システム。
　
［相違点ａ］
“認証を行う認証器”に関して，
　本願発明は，「被認証器を認証する」ものであるのに対して，
　引用発明においては，「消費者側端末」は，直接，「業者側端末」を認証するものではない点。
　
［相違点ｂ］
“第１認証情報”に関して，
　本願発明においては，「第１の認証データは，第１認証子と前記被認証器が有する所定データとを含」むものであるのに対して，
　引用発明における「電子証明方式Ａによる電子署名」が，そのような構成を有するかについては，特に言及されていない点。
　
［相違点ｃ］
　本願発明においては，「被認証器は，前記認証器から送信されたチャレンジデータと前記所定データを，共通鍵を用いた共通鍵暗号方式で計算して前記第１認証子を生成し，生成した前記第１認証子と前記所定データとを前記第１の認証データとして前記認証子変換器に送信」するものであるのに対して，
　引用発明においては，「業者側端末」の認証に「チャレンジ」を用いる点について，特に言及されていない点。
　
［相違点ｄ］
　“第２認証情報”に関して，
　本願発明においては，「第２の認証データは，第２認証子と前記被認証器が有する前記所定データとを含」むものであるのに対して，
　引用発明における「電子署名方式Ｂによる電子署名」が，そのような構成を有するかについては，特に言及されていない点。
　
［相違点ｅ］
　本願発明においては，「前記被認証器から送信された前記第１の認証データの前記所定データと前記認証器から送信された前記チャレンジデータを前記秘密鍵を用いた公開鍵暗号方式で計算して前記第２認証子を生成し，生成した前記第２認証子と前記所定データとを前記認証器に送信」するものであるのに対して，
　引用発明においては，「共通鍵暗号方式」の「チャレンジ」を用いる点については，特に言及されていない点。
　
［相違点ｆ］
　本願発明においては，「認証子変換器から送信された前記所定データと前記認証子変換器に送信した前記チャレンジデータとを結合し，前記認証子変換器から送信された前記第２認証子を前記公開鍵を用いて復号し，復号した結果と，前記結合したデータとを比較して前記被認証器を認証する」ものであるのに対して，
　引用発明においては，「電子署名方式Ｂによる電子署名を確認する」ことについて，具体的に特定されていない点。
　
エ．相違点についての当審の判断
（ア）［相違点ｂ］〜［相違点ｅ］について
　本願発明と，引用発明との［相違点ｂ］〜［相違点ｄ］は，本件補正発明と，引用発明との［相違点１］〜［相違点３］と同じものであり，
　本願発明と，引用発明との［相違点ｅ］は，「第２認証子」と，「所定データ」とを「認証器」に送信することに関する点については，［相違点４］と同じものであるから，
　上記「第２．平成２９年１１月２９日付けの手続補正の却下の決定」の「２．補正の適否」の「（２）独立特許要件」における「オ．相違点についての当審の判断」の（ア）〜（エ）において検討したとおり，格別のものではない。
　
（イ）［相違点ａ］，及び，［相違点ｆ］について
　本願発明と，引用発明との［相違点ａ］，及び，［相違点ｆ］は，上記「１．３６条４項１号について」，及び，「２．３６条６項２号について」において検討した，本願発明の明確でない構成に係るものであるから，どのように構成されているか不明であり，そのままでは，引用発明，或いは，他の引用文献等と対比することはできない。
　仮に，［相違点ａ］，及び，［相違点ｆ］に係る構成が，本願明細書の発明の詳細な説明に記載の構成を表現したものであるとすれば，上記「第２．平成２９年１１月２９日付けの手続補正の却下の決定」の「２．補正の適否」の「（２）独立特許要件」における「エ．本件補正発明と引用発明との対比」，及び，「オ．相違点についての当審の判断」の（ア）〜（エ）において検討したとおり，［相違点ａ］は，［一致点］に含まれることとなり，［相違点ｆ］は，本件補正発明と，引用発明との［相違点５］と同じものになるので，格別のものではない。
　
（ウ）以上，上記（ア），（イ）において検討したとおりであるから，本願発明において明確でない記載が存在する点を考慮しても，本願発明と，引用発明との［相違点ａ］〜［相違点ｆ］はいずれも格別のものではなく，引用発明，及び，引用文献２，引用文献３に記載された技術事項に基づいて，当業者が適宜なし得る事項である。
　そして，本願発明の構成によってもたらされる効果も，当業者であれば当然に予測可能なものに過ぎず格別なものとは認められない。
　
第６．むすび
　したがって，本願は，特許法第３６条第４項第１号及び第６項第２号に規定する要件を満たしておらず，加えて，
　本願発明は，本願の特許出願前に日本国内又は外国において頒布された刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基づいて当業者が容易に発明をすることができたものであるので，特許法第２９条第２項の規定により特許を受けることができない。
　
　よって，結論のとおり審決する。