• ポートフォリオ機能


ポートフォリオを新規に作成して保存
既存のポートフォリオに追加保存

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 特36条6項1、2号及び3号 請求の範囲の記載不備 特許、登録しない。 H04L
審判 査定不服 5項独立特許用件 特許、登録しない。 H04L
審判 査定不服 特36条4項詳細な説明の記載不備 特許、登録しない。 H04L
審判 査定不服 2項進歩性 特許、登録しない。 H04L
管理番号 1347298
審判番号 不服2017-17629  
総通号数 230 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2019-02-22 
種別 拒絶査定不服の審決 
審判請求日 2017-11-29 
確定日 2018-12-20 
事件の表示 特願2013- 10800「認証システム」拒絶査定不服審判事件〔平成26年 8月 7日出願公開,特開2014-143568〕について,次のとおり審決する。 
結論 本件審判の請求は,成り立たない。 
理由 第1.手続の経緯
本願は,平成25年1月24日の出願であって,
平成28年1月22日付けで審査請求がなされ,平成28年12月16日付けで審査官により拒絶理由が通知され,これに対して平成29年3月13日付けで意見書が提出されると共に手続補正がなされたが,平成29年8月22日付けで審査官により拒絶査定がなされ(謄本送達;平成29年8月29日),これに対して平成29年11月29日付けで審判請求がなされると共に手続補正がなされ,平成30年2月15日付けで審査官により特許法第164条第3項の規定に基づく報告がなされたものである。

第2.平成29年11月29日付けの手続補正の却下の決定

[補正却下の決定の結論]

平成29年11月29日付け手続補正を却下する。

[理由]

1.補正の内容
平成29年11月29日付けの手続補正(以下,「本件手続補正」という)により,平成29年3月13日付けの手続補正により補正された特許請求の範囲,
「 【請求項1】
第1の認証データを生成する被認証器と,
前記被認証器にて生成された前記第1の認証データを第2の認証データに変換する認証子変換器と,
前記認証子変換器にて変換された前記第2の認証データに基づいて,前記被認証器の認証を行う認証器と,を備え,
前記第1の認証データは,第1認証子と前記被認証器が有する所定データとを含み,
前記被認証器は,前記認証器から送信されたチャレンジデータと前記所定データを,共通鍵を用いた共通鍵暗号方式で計算して前記第1認証子を生成し,生成した前記第1認証子と前記所定データとを前記認証子変換器に送信し,
前記第2の認証データは,第2認証子と前記被認証器が有する前記所定データとを含み,
前記認証子変換器は,秘密鍵を有し,前記被認証器から送信された前記所定データと前記認証器から送信された前記チャレンジデータを前記秘密鍵を用いた公開鍵暗号方式で計算して前記第2認証子を生成し,生成した前記第2認証子と前記所定データを前記認証器に送信し,
前記認証器は,公開鍵を有し,前記認証子変換器から送信された前記所定データと前記認証子変換器に送信した前記チャレンジデータとを結合し,前記認証子変換器から送信された前記第2認証子を前記公開鍵を用いて復号し,復号した結果と,前記結合したデータとを比較して前記被認証器を認証することを特徴とする認証システム。
【請求項2】
前記認証子変換器は,前記被認証器から送信された前記所定データと前記認証器から送信された前記チャレンジデータを前記共通鍵を用いた共通鍵暗号方式で計算して第1の比較用認証子を生成し,前記被認証器から送信された前記第1認証子と前記第1の比較用認証子とを比較することにより,前記被認証器を認証することを特徴とする請求項1に記載の認証システム。
【請求項3】
第1の認証データを生成する被認証器と,
前記被認証器にて生成された前記第1の認証データを第2の認証データに変換する認証子変換器と,
前記認証子変換器にて変換された前記第2の認証データに基づいて,前記被認証器の認証を行う認証器と,を備え,
前記第1の認証データは,第1認証子と前記被認証器が有する所定データとを含み,
前記被認証器は,前記認証器から送信されたチャレンジデータと前記所定データを,第1の共通鍵を用いた共通鍵暗号方式で計算して前記第1認証子を生成し,生成した前記第1認証子と前記所定データとを前記認証子変換器に送信し,
前記第2の認証データは,第2認証子と前記被認証器が有する前記所定データとを含み,
前記認証子変換器は,前記被認証器から送信された前記所定データと前記認証器から送信された前記チャレンジデータを前記第1の共通鍵とは異なる第2の共通鍵を用いた共通鍵暗号方式で計算して前記第2認証子を生成し,生成した前記第2認証子と前記所定データを前記認証器に送信し,
前記認証器は,前記認証子変換器から送信された前記所定データと前記認証子変換器に送信した前記チャレンジデータとを結合し,前記第2の共通鍵を用いた共通鍵暗号方式で計算して第2の比較用認証子を生成し,前記認証子変換器から送信された前記第2認証子と前記第2の比較用認証子とを比較して前記被認証器を認証することを特徴とする認証システム。
【請求項4】
前記認証子変換器は,前記被認証器から送信された前記所定データと前記認証器から送信された前記チャレンジデータを前記第1の共通鍵を用いた共通鍵暗号方式で計算して第1の比較用認証子を生成し,前記被認証器から送信された前記第1認証子と前記第1の比較用認証子とを比較することにより,前記被認証器を認証することを特徴とする請求項3に記載の認証システム。
【請求項5】
前記認証子変換器は,公開鍵暗号方式における秘密鍵を有し,
前記認証器は,前記秘密鍵と対になる公開鍵を有し,
前記認証器は,前記公開鍵を用いた公開鍵暗号方式で計算して暗号化した前記第2の共通鍵を前記認証子変換器に送信し,
前記認証子変換器は,前記認証器より送信された前記暗号化された前記第2の共通鍵を前記秘密鍵を用いて復号することにより,前記第2の共通鍵を取得することを特徴とする請求項3又は4に記載の認証システム。
【請求項6】
前記第2の共通鍵は,使い捨ての共通鍵であり,
前記認証器は,新たな共通鍵を随時生成し,前記認証子変換器に送信することにより,前記使い捨ての共通鍵を変更することを特徴とする請求項5に記載の認証システム。
【請求項7】
前記認証子変換器は,前記被認証器の認証を前記第1の認証データに基づいて行い,前記被認証器の認証に成功した場合には,前記第2の認証データを前記認証器に送信することを特徴とする請求項1ないし6のいずれか1項に記載の認証システム。
【請求項8】
前記第2の認証データの暗号化された前記第2認証子は,前記認証子変換器が前記被認証器の認証を前記第1の認証データに基づいて行った認証結果をさらに含み,
前記認証子変換器は,前記被認証器の認証を前記第1の認証データに基づいて行い,前記被認証器の認証の成否にかかわらず,前記第2の認証データを前記認証器に送信することを特徴とする請求項1ないし6のいずれか1項に記載の認証システム。
【請求項9】
前記被認証器は,シートに画像を形成する画像形成装置が備える交換可能な装置又はユニットに設けられていることを特徴とする請求項1ないし8のいずれか1項に記載の認証システム。
【請求項10】
前記認証子変換器は,シートに画像を形成する画像形成装置が備える制御手段を有するユニットに設けられていることを特徴とする請求項1ないし9のいずれか1項に記載の認証システム。
【請求項11】
前記認証器は,シートに画像を形成する画像形成装置が備える制御手段を有するユニットに設けられていることを特徴とする請求項1ないし10のいずれか1項に記載の認証システム。
【請求項12】
前記認証器は,シートに画像を形成する画像形成装置と接続された外部装置に設けられていることを特徴とする請求項1ないし10のいずれか1項に記載の認証システム。」(以下,上記引用の請求項各項を,「補正前の請求項」という)は,
「 【請求項1】
第1の認証データを生成する被認証器と,
前記被認証器にて生成された前記第1の認証データに基づき前記被認証器を認証し,前記第1の認証データを第2の認証データに変換する認証子変換器と,
前記認証子変換器にて変換された前記第2の認証データに基づいて,認証処理を行う認証器と,を備え,
前記第1の認証データは,第1認証子と前記被認証器が有する所定データとを含み,
前記被認証器は,前記認証器から送信されたチャレンジデータと前記所定データを,共通鍵を用いた共通鍵暗号方式で計算して前記第1認証子を生成し,生成した前記第1認証子と前記所定データとを前記第1の認証データとして前記認証子変換器に送信し,
前記第2の認証データは,第2認証子と前記被認証器が有する前記所定データとを含み,
前記認証子変換器は,秘密鍵を有し,前記被認証器から送信された前記第1の認証データの前記所定データと前記認証器から送信された前記チャレンジデータを,前記共通鍵を用いた共通鍵暗号方式で計算して第1比較認証子を生成し,生成した前記第1比較認証子と,前記第1の認証データの前記第1認証子と,を比較し,前記第1比較認証子と前記第1認証子が一致した場合に,前記被認証器から送信された前記第1の認証データの前記所定データと前記認証器から送信された前記チャレンジデータを前記秘密鍵を用いた公開鍵暗号方式で計算して前記第2認証子を生成し,生成した前記第2認証子と前記所定データとを前記第2の認証データとして前記認証器に送信し,
前記認証器は,公開鍵を有し,前記認証子変換器から送信された前記第2の認証データの前記所定データと前記認証子変換器に送信した前記チャレンジデータとを結合し,前記認証子変換器から送信された前記第2の認証データの前記第2認証子を前記公開鍵を用いて復号し,復号した結果と,前記結合したデータとを比較して前記認証処理を行うことを特徴とする認証システム。
【請求項2】
第1の認証データを生成する被認証器と,
前記被認証器にて生成された前記第1の認証データに基づき前記被認証器を認証し,前記第1の認証データを第2の認証データに変換する認証子変換器と,
前記認証子変換器にて変換された前記第2の認証データに基づいて,認証処理を行う認証器と,を備え,
前記第1の認証データは,第1認証子と前記被認証器が有する所定データとを含み,
前記被認証器は,前記認証器から送信されたチャレンジデータと前記所定データを,第1の共通鍵を用いた共通鍵暗号方式で計算して前記第1認証子を生成し,生成した前記第1認証子と前記所定データとを前記第1の認証データとして前記認証子変換器に送信し,
前記第2の認証データは,第2認証子と前記被認証器が有する前記所定データとを含み,
前記認証子変換器は,前記被認証器から送信された前記第1の認証データの前記所定データと前記認証器から送信された前記チャレンジデータを,前記第1の共通鍵を用いた共通鍵暗号方式で計算して第1比較認証子を生成し,生成した前記第1比較認証子と,前記第1の認証データの前記第1認証子とを比較し,前記第1比較認証子と前記第1認証子とが一致した場合に,前記被認証器から送信された前記第1の認証データの前記所定データと前記認証器から送信された前記チャレンジデータを前記第1の共通鍵とは異なる第2の共通鍵を用いた共通鍵暗号方式で計算して前記第2認証子を生成し,生成した前記第2認証子と前記所定データとを前記第2の認証データとして前記認証器に送信し,
前記認証器は,前記認証子変換器から送信された前記第2の認証データの前記所定データと前記認証子変換器に送信した前記チャレンジデータとを結合し,前記第2の共通鍵を用いた共通鍵暗号方式で計算して第2比較認証子を生成し,前記認証子変換器から送信された前記第2の認証データの前記第2認証子と前記第2比較認証子とを比較して前記認証処理を行うことを特徴とする認証システム。
【請求項3】
前記認証子変換器は,公開鍵暗号方式における秘密鍵を有し,
前記認証器は,前記秘密鍵と対になる公開鍵を有し,
前記認証器は,前記公開鍵を用いた公開鍵暗号方式で計算して暗号化した前記第2の共通鍵を前記認証子変換器に送信し,
前記認証子変換器は,前記認証器より送信された前記暗号化された前記第2の共通鍵を前記秘密鍵を用いて復号することにより,前記第2の共通鍵を取得することを特徴とする請求項2に記載の認証システム。
【請求項4】
前記第2の共通鍵は,使い捨ての共通鍵であり,
前記認証器は,新たな共通鍵を随時生成し,前記認証子変換器に送信することにより,前記使い捨ての共通鍵を変更することを特徴とする請求項3に記載の認証システム。
【請求項5】
前記認証子変換器は,前記被認証器の認証を前記第1の認証データに基づいて行い,前記被認証器の認証に成功した場合には,前記第2の認証データを前記認証器に送信することを特徴とする請求項1ないし4のいずれか1項に記載の認証システム。
【請求項6】
前記第2の認証データの暗号化された前記第2認証子は,前記認証子変換器が前記被認証器の認証を前記第1の認証データに基づいて行った認証結果をさらに含み,
前記認証子変換器は,前記被認証器の認証を前記第1の認証データに基づいて行い,前記被認証器の認証の成否にかかわらず,前記第2の認証データを前記認証器に送信することを特徴とする請求項1ないし4のいずれか1項に記載の認証システム。
【請求項7】
前記被認証器は,シートに画像を形成する画像形成装置が備える交換可能な装置又はユニットに設けられていることを特徴とする請求項1ないし6のいずれか1項に記載の認証システム。
【請求項8】
前記認証子変換器は,シートに画像を形成する画像形成装置が備える制御手段を有するユニットに設けられていることを特徴とする請求項1ないし7のいずれか1項に記載の認証システム。
【請求項9】
前記認証器は,シートに画像を形成する画像形成装置が備える制御手段を有するユニットに設けられていることを特徴とする請求項1ないし8のいずれか1項に記載の認証システム。
【請求項10】
前記認証器は,シートに画像を形成する画像形成装置と接続された外部装置に設けられていることを特徴とする請求項1ないし8のいずれか1項に記載の認証システム。」(以下,上記引用の請求項各項を,「補正後の請求項」という)に補正された。

2.補正の適否
(1)新規事項及び目的要件について
本件手続補正は,補正前の請求項1に記載の「第2認証子を生成」することに対して,
「前記被認証器から送信された前記第1の認証データの前記所定データと前記認証器から送信された前記チャレンジデータを,前記共通鍵を用いた共通鍵暗号方式で計算して第1比較認証子を生成し,生成した前記第1比較認証子と,前記第1の認証データの前記第1認証子と,を比較し,前記第1比較認証子と前記第1認証子が一致した場合に」という限定を付加して補正後の請求項1とすると共に,補正前の請求項2を削除し,補正前の請求項3に,上記指摘の補正前の請求項1に付加した限定事項と同等の限定事項を付加して,補正後の請求項2とした上で,補正前の請求項4を削除し,補正前の請求項5?補正前の請求項12を,補正後の請求項3?補正後の請求項10とし,その他,補正後の請求項1,及び,補正後の請求項2において,明確でないと指摘された事項を明確とするものであって,本件手続補正は,願書に最初に添付された明細書,特許請求の範囲,及び,図面に記載した事項の範囲内でなされたものであるから,特許法第17条の2第3項の規定を満たすものであり,
加えて,本件手続補正は,上記検討の如く,請求項の削除,特許請求の範囲の減縮(特許法第36条第5項の規定により請求項に記載した発明を特定するために必要な事項を限定するものであって,その補正前の当該請求項に記載された発明とその補正後の当該請求項に記載される発明の産業上の利用分野及び解決しようとする課題が同一であるものに限る),及び,明りょうでない記載の釈明(拒絶理由通知に係る拒絶の理由に示す事項についてするものに限る)を目的とするものであるから,
本件手続補正は,特許法第17条の2第5項の規定を満たすものである。
そこで,本件手続補正が,特許法第17条の2第6項において準用する同法第126条第7項の規定を満たすものであるか否か,即ち,補正後の請求項1に記載されている事項により特定される発明が特許出願の際独立して特許を受けることができるものであるか否か,以下に検討する。

(2)独立特許要件
ア.補正後の請求項1に係る発明
補正後の請求項1に係る発明(以下,これを「本件補正発明」という)は,上記「1.補正の内容」において,補正後の請求項1として引用した,次のとおりのものである。

「第1の認証データを生成する被認証器と,
前記被認証器にて生成された前記第1の認証データに基づき前記被認証器を認証し,前記第1の認証データを第2の認証データに変換する認証子変換器と,
前記認証子変換器にて変換された前記第2の認証データに基づいて,認証処理を行う認証器と,を備え,
前記第1の認証データは,第1認証子と前記被認証器が有する所定データとを含み,
前記被認証器は,前記認証器から送信されたチャレンジデータと前記所定データを,共通鍵を用いた共通鍵暗号方式で計算して前記第1認証子を生成し,生成した前記第1認証子と前記所定データとを前記第1の認証データとして前記認証子変換器に送信し,
前記第2の認証データは,第2認証子と前記被認証器が有する前記所定データとを含み,
前記認証子変換器は,秘密鍵を有し,前記被認証器から送信された前記第1の認証データの前記所定データと前記認証器から送信された前記チャレンジデータを,前記共通鍵を用いた共通鍵暗号方式で計算して第1比較認証子を生成し,生成した前記第1比較認証子と,前記第1の認証データの前記第1認証子と,を比較し,前記第1比較認証子と前記第1認証子が一致した場合に,前記被認証器から送信された前記第1の認証データの前記所定データと前記認証器から送信された前記チャレンジデータを前記秘密鍵を用いた公開鍵暗号方式で計算して前記第2認証子を生成し,生成した前記第2認証子と前記所定データとを前記第2の認証データとして前記認証器に送信し,
前記認証器は,公開鍵を有し,前記認証子変換器から送信された前記第2の認証データの前記所定データと前記認証子変換器に送信した前記チャレンジデータとを結合し,前記認証子変換器から送信された前記第2の認証データの前記第2認証子を前記公開鍵を用いて復号し,復号した結果と,前記結合したデータとを比較して前記認証処理を行うことを特徴とする認証システム。」

イ.引用文献に記載の事項
(ア)原審における平成28年12月16日付けの拒絶理由(以下,これを「原審拒絶理由」という)に引用された,本願の出願前に既に公知である,特開2002-208926号公報(平成14年7月26日公開,以下,これを「引用文献1」という)には,関連する図面と共に,次の事項が記載されている。

A.「【0001】
【発明の属する技術分野】本発明は,インターネットなどのデータ通信におけるセキュリティに関する。
【0002】
【従来の技術】現在では,インターネットを利用した電子商取引が普及してきているが,その取引において重要なのが,取引相手が本人であることを証明し,改ざんを防ぐセキュリティである。このセキュリティとしては,公開鍵暗号方式(PKI)による電子署名や生体認証(指紋や虹彩,声紋,脈など)を利用した認証方法が使われている。
【0003】
【発明が解決しようとする課題】現状における電子署名のアルゴリズムは,いまだ標準化された仕様がなく,アプリケーションごとに独立した電子署名機能が実現されてるのが実状で,互換性がないために利便性が犠牲になっている点が問題である。たとえば,携帯電話や携帯情報端末(PDA)のチップカード(ICカード)に公開鍵あるいは秘密鍵を組み込む場合,アプリケーション(取引相手)ごとにチップカードを差し替えるというような事態になってしまう。
【0004】また,使用している電子署名の方式がクラッカーにより破られた場合,全取引相手に対する電子署名の使用中止,新たなセキュリティの構築などに多大なコストと時間を要することになり,その間の取引停止による損害はばかにならない。携帯電話など手軽な通信端末から簡単に金融情報へアクセスできる現在では,多額の損害が発生する危険性も非常に高まっている。
【0005】一方,生体認証をセキュリティに使用する場合,たとえば,指がない人や仕事柄指紋がすり減ってしまっている人に指紋認証を適用することなどないよう配慮する必要があるが,これを実現しているシステムはまだない。
【0006】本発明ではこれらの課題を解決し,今以上に堅牢で万人に適したセキュリティの方法を提案するものである。
【0007】
【課題を解決するための手段】本発明によれば,上記課題の解決手段として,多種類の電子署名方式を記憶した記憶手段をもち,その記憶されている各電子署名方式間の変換を行えるようにしたコンピュータを通信端末間の通信仲介役として備え,この仲介役コンピュータが,一方の通信端末から電子署名を受信し,該電子署名を所定の方式に変換して他方の通信端末へ送信することを特徴とした認証方法を提案する。たとえば,一方の取引者が銀行であり,他方の取引者として消費者との間でセキュリティセッションをはる場合に,消費者のもつ通信端末が携帯電話でそのシステムが当該銀行の電子署名方式に対応していなかったとしても,仲介役コンピュータが間に入り,銀行端末からの電子署名を受けて消費者の携帯電話に適した方式に変換することで,支障なくセキュリティで保護された通信を行うことができる。つまり,異種の電子署名方式間に互換性をもたせ,利便性の大幅な向上を実現する。」

B.「【0012】
【発明の実施の形態】図1に,本発明の認証方法を実行するシステムの概要を示し説明する。
【0013】多数の端末からインターネットや専用線を介してアクセス可能とした仲介役サーバが設けられ,仲介役コンピュータとして働いている。この仲介役サーバは,公開鍵暗号方式による電子署名の認証局である認証局A,B,Cと連係しており,その認証局ごとに異なる電子署名方式のアルゴリズムをハードディスクなどの記憶手段に記憶し,対応する証明書を発行することができるようになっている。また,認証局Dは本例では生体認証の認証局であり,この認証局Dと仲介役サーバが連係することで,その生体認証方式を仲介役サーバで実行することができるようになっている。これら認証局A?Dと仲介役サーバとの間の通信も,公開鍵暗号方式によるセキュリティがかけられているが,各認証局の暗号化アルゴリズムに仲介役サーバ独自の乱数を加えることで,外部アタックを跳ね返す堅牢なシェルター構造が形成されている。
【0014】このような仲介役サーバに対し,X銀行,Yクレジット,Z証券,そして消費者が契約することでその各所有通信端末…X銀行端末,Yクレジット端末,Z証券端末,消費者端末がアクセスし,互いに取引を行うことが可能となる。一例として,Yクレジットと消費者との間の通信を例にして説明する。
【0015】Yクレジット端末の電子署名方式は認証局Aの方式(電子署名方式A)であるが,消費者端末はこれに対応しておらず,認証局Bの方式(電子署名方式B)であれば対応しているとする。この場合,Yクレジット端末と消費者端末が直接通信を行ったのではセキュリティを構築することができない。そこで,仲介役サーバが間に入って電子署名の翻訳を実行する。すなわち,まずYクレジット端末と仲介役サーバとの間で電子署名方式Aによる通信が実施され,Yクレジット端末の方式Aによる公開鍵が証明書付で仲介役サーバへ渡される。証明書が確認されると,公開鍵により復号化が実施され,複合化(当審注;「復号化」の誤記である)した通信メッセージが一旦仲介役サーバに記憶される。一方,仲介役サーバと消費者端末との間には電子署名方式Bによるセキュリティがはられ,Yクレジット端末からの通信メッセージを復号化した仲介役サーバは,そのメッセージを方式Bによる秘密鍵により暗号化し,消費者端末へ送信する。消費者端末では,仲介役サーバから方式Bによる公開鍵が証明書付で入手されるので,証明書確認後,その公開鍵により復号化を実施する。
【0016】このようにすることで,消費者自身には仲介役サーバが介在していることを意識させることなく,あたかもYクレジットと直接通信しているかのようにして,セキュリティセッションを構築することができる。なお,Yクレジット端末と仲介役サーバとの公開鍵-秘密鍵の関係は逆でもよいし,両方が公開と秘密の鍵ペアをもち,サーバ認証とクライアント認証の両方を行う相互認証となっていても同様である。」

(イ)原審拒絶理由に引用された,本願の出願前に既に公知である,「Davis, D. W. and Price, W. L., ネットワーク・セキュリティ,日経マグロウヒル社,1985年12月5日, p.114-116, p.126-129」(以下,これを「引用文献2」という)には,関連する図面と共に,次の事項が記載されている。

C.「図5.1は認証子による方法の原理を示す。それは関数A(k,M)によって表わされた公開アルゴリズムに基づいている。鍵kは送り手と受け手に知られているが,敵には知られていない。認証されるべき通信文Mはどんな長さでもよいし,関数A(k,M)は通信文のビットすべてに依存する必要がある。関数Aは通信文の宛先に同行する認証子である。受信者はまたA(k,M)を計算し,受信したAとこれを比較する。もし,等しければ通信文を受け取る。」(114頁31行?35行)

D.「乱数の使用によるエンティティ認証
大きな組織では,認証は鍵の配布センター(第6章参照)から得られるセッション鍵に頼ることができるので,それぞれのエンティティは通信するものすべてについて鍵を必要とするわけではない。その代わりに,公開鍵(第8章参照)を使用して鍵の配布問題を単純化できる。こういった状況下では通常,それぞれの通信エンティティが別個の通し番号を維持することは実際的ではない。同一の鍵を使用して各通信文を他とは異なるようにする必要性は,乱数を含めることで(高い確率で)満たされる。例えば,図5.8に示す3つの通信文のトランザクションを考えてみよう。トランザクションの開始者は乱数Rを含んでおり,これは応答の一部として返される。各通信文は乱数を含む内容をすべてカバーする認証子を持っており,通信ネットワーク内容への干渉を探知できるようになっている。その乱数を返答することで,開始者はそれが実際のエンティティからの応答であり,従前の応答から再録できないことを保証する。この場合,乱数フィールドの大きさは誕生日の逆説(4.7節参照)による。もし,同一の鍵を使用するN個のトランザクションがあるなら,乱数フィールドは反復の確率を低い値に下げるため,N^(2)以上の大きさにしなければならない。
双方向の認証では,他のエンティティは応答の中に乱数Sを入れ,反復ではなく新たにトランザクションを開始した保証として,トランザクションの3番目の通信文で返さなければならない。他の乱数が見せかけである場合には,それぞれのエンティティは自分自身の乱数をプロトコルに挿入する。
M_(1)が以前のトランザクション開始の通信文の再送である可能性を考えてみよう。無邪気な受け手はRに対する正しい応答と新しい乱数Sを含めてM_(2)を返す。M_(3)を応答として受信した場合に,M_(3)は新しい認証子の値A_(3)を生成するために必要な秘密鍵をもつエンティティから来たものでなければならない。もし,M_(1)が偽であったとすれば,これがその鍵の本当の所有者だろうか?M_(1)を送信していない限り,鍵の所有者はM_(2)を有効であるとして受け入れはしないだろう。したがって,鍵の本当の所有者がM_(1)を発したことは間違いなく,有効であるとして受け入れることができる。しかし,M_(3)を受信しチェックするまで,M_(1)を有効として受け入れないことが重要である。例えば,M_(1)がデータベースを更新する要求だとしたら,M_(3)が到着するまで待つべきである。
さらに後続の通信文でトランザクションを続けるなら,前に記した方法によりそれらを以前の通信文にチェインする必要があるだろう。
誕生日の逆説のため,鍵の所与の有効期間について必要なフィールドの大きさは乱数の使用によりおよそ2倍になる。セッション鍵を1つのトランザクションだけに使用する場合,乱数を通常の認証子以上の大きさにする必要はないので,これでも問題はない。」(128頁13行?129頁15行)


E.「



(ウ)原審拒絶理由に引用された,本願の出願前に既に公知である,米国特許第6725276号明細書(2004年4月20日公開,以下,これを「引用文献3」という)には,関連する図面と共に,次の事項が記載されている。

F.「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.」(4欄34行?5欄55行)
(特に,図1は,本発明の望ましい実施例を実施するために利用され得る,好適なネットワークを模式的に示す。特に,ネットワークは,互いが従来型のマルチキャスト・プロトコルと一致して動作する,第1のマルチキャスト・ドメイン(“第1ドメイン10”)と,第2のマルチキャスト・ドメイン(“第2ドメイン12”)とを含む。好適な実施例において,両ドメインは,よく知られた,プロトコル独立マルチキャスト・プロトコル(別名“PIMプロトコル”)に従って動作する。しかしながら,注目すべきは,好適な実施例が,PIMプロトコルに関して,論じられてはいるが,本発明の本質は,インターネット・プロトコル・マルチキャスト・プロトコル(“IPマルチキャスト”)のような,他のマルチキャスト・プロトコルに当てはまる。PIMプロトコルは,それ故に,典型的な目的のためだけについて論じられ,好適な実施例の範囲を制限することを目的とされるものではない。
マルチキャスト・ドメイン10,及び,12のそれぞれは,マルチキャスト・パラメタを分配すること,及び,マルチキャスト分配木を形成することのためにランデヴー・ポイント・ルータ14を,ランデヴー・ポイント・ルータ14を選択し,識別することのために,ブートストラップ・ルータ16を,そして,PIMプロトコルにしたがって動作する,複数のPIMルータ18を含む。ネットワークは,また,単に,PIMルータ18への,PIMマルチキャスト・メッセージを転送するだけの,1以上の非PIMルータ(図示せず)を含む。加えて,第1ドメイン10は,ドメイン間の通信を翻訳する,及び,認証するために,第2ドメイン12内の第2ドメイン境界ルータ(“第2境界ルータ22”)と協働する,第1ドメイン境界ルータ(“第1境界ルータ20”)を含む。第1,及び,第2境界ルータ20,及び,22は,望ましくは,それぞれが,境界ルータとして動作するよう構成された,PIMルータ18である。それぞれのドメイン内に,1つだけ境界ルータが示されているが,それぞれのドメインは,追加の境界ルータを含み,本発明の好適な実施例にしたがって,さらに動作し得る。さらに,境界ルータ20,及び,22は,直接接続,大規模ネットワーク(例えば,インターネット),1以上のマルチキャスト・ドメイン,或いは,他の知られた方法を介するような,多くの方法において,通信し得る。いくつかの実施例において,1つの境界ルータは,両方のドメインのために利用される。注目すべきは,それぞれのドメイン内のすべてのネットワーク・デバイスは,マルチキャストを実行するために,相互接続(例えば,直接接続を介して,或いは,インターネットを介して)されている。それぞれのルータ18は,望ましくは,1以上のクライアント・コンピュータ・システムを含む,ローカル・ユーザ・グループ(例えば,ローカル・エリア・ネットワーク)と接続される。
上述のように,2つのドメインは,望ましくは,PIMプロトコルを実行する。それに基づいて,それぞれのドメイン内のルータ18は,それぞれが,添付のタグを有する,1以上のメッセージを介して,通信する。より具体的には,初期化するか,再鍵化する度に,与えられたPIMマルチキャスト・ドメイン内のランデヴー・ポイント・ルータ14は,与えられたドメイン内の,ルータ18それぞれの,対称認証鍵を,転送する。ルータ18それぞれは,それ故,ドメイン内の,他のルータ18から受信した,双方の認証メッセージのため,及び,ドメイン内で,そのメッセージに添付されるために,一致する認証タグを生成するため,鍵を利用する。例えば,(ルータ18に繋がれた)クライアント・コンピュータ・システムから生成されたメッセージと,そのドメインの鍵は,マルチキャスト・ドメイン内の全てのルータによってのみ知られている,与えられた鍵付ハッシュ関数への入力として,用いられるであろう。(“タグ”として,上記,及び,下記に言及する)鍵付ハッシュ関数の出力は,次に,そのドメイン内の第2のルータ18に,メッセージを送信することに先立って,メッセージに添付される。PIMプロトコル,及び,類似のマルチキャスト・プロトコルと共に用いた時,タグは,“メッセージ認証コード”(“MAC”)として,周知技術である。
メッセージの受領次第,第2のルータ18は,同様に,同一の鍵付ハッシュ関数に,鍵と,メッセージを入力し,次に,メッセージに添付のタグと,この関数の出力とを比較する。もし,タグが,計算した出力と一致すれば,そのとき,メッセージは認証されたと見なされる。その結果,第2のルータ18は,そのドメイン内の,他のルータ18に,そのメッセージを,転送し得る。逆に,もし,タグが,計算した出力と一致しなかったら,そのときは,メッセージは,認証されなかったと見なされる。もし,認証されなければ,そのとき,第2のルータ18は,そのメッセージを破棄する(即ち,そのメッセージを処理することも,それを,他のネットワーク・デバイスに転送することもない。)
注目すべきは,メッセージは,所定のドメインの範囲内で,認証されたネットワーク・デバイスから受信された時は,“本物である”と見なされる。所定のルータ18からの正当なメッセージの受領は,当該メッセージが,所定のルータ18が起源であることを暗示している。メッセージは,所定のルータ18が,当該メッセージに,タグを添付する場合は,その所定のルータ18が起源であると見なされ,その後,他のネットワーク・デバイスに,当該添付されたメッセージが,転送される。結果的に,メッセージは,当該ルータのタグが,他のドメイン内の,他のルータのタグに置き換えられた時でも,所定のルータ18が起源であると見なされる。周知技術,及び,上記説明から,PIMルータ18は,正当であると決定されるまで,タグを添付しない。<当審にて訳出。以下,同じ。>)

G.「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.」(8欄4行?9欄19行)
(特に,図4Aは,第1ドメイン10と,第2ドメイン12との間を転送されるメッセージを認証することの,別の方法を示している。その方法は,(第1ドメイン10内の)送信ルータが,メッセージ共に,よく知られた方法に従って,メッセージに,電子署名をするために,それらの公開鍵ペアの秘密鍵を用いることで,ステップ400において,始まる。電子署名は,望ましくは,そのメッセージに関連しているメッセージ・データ25の一部(即ちペイロード)として,そのメッセージに加えられる。加えて,第1ドメイン鍵は,上で説明したように,第1ドメインMAC32を生成するために,用いられる。生成された第1ドメインMAC32は,次に,電子署名されたメッセージに添付され,第1境界ルータ20に転送される。上で説明したのと似た方法で,送信ルータと,第1境界ルータ20との間に介在する,それぞれの第1ドメイン内のPIMルータ18が,第1ドメインMACを介して,証明されたメッセージを認証する。しかしながら,介在するルータの何れもが,電子署名をチェックしない。
プロセスは,次に,第1境界ルータ20が,送信ルータの電子署名と,第1ドメインMACの両方を認証する,ステップ402に進む。もし,認証されなければ,メッセージは破棄される。もし,認証されれば,次に,第1境界ルータ20は,送信ルータの電子署名と,第1ドメインMACの両方を取り除く(ステップ404)。送信ルータによって実行されたのと同様の方法で,第1境界ルータ20は,次に,メッセージのペイロードとして,自身の電子署名を加え,第2境界ルータ22に,結果としてのメッセージを転送する。実際には,そのメッセージに,それの電子署名を加えることによって,第1境界ルータ20は,送信ルータを起源とするところのメッセージの正当性を保証している。必須ではないが,境界ルータ間の,仲介MACが,添付され得る(図2,及び,図3A参照)。
プロセスは,次に,第2境界ルータ22が,受信したメッセージ内の,第1境界ルータの署名を確認する(即ち,認証する),ステップ406に進む。その目的で,第2境界ルータ22は,第1境界ルータの公開鍵を読み出す。この鍵は,例えば,認証機関から,或いは,それぞれのドメインにおける,ランデヴー・ルータ14間の,周知のマルチキャスト・ソース・デリバリ・プロトコル接続(“MSDP接続”)を介するというような,いくつかの知られた方法によって,読み出され得る。
認証されると,第2境界ルータ22は,第2ドメインMAC36を(例えば,第2ドメイン鍵,メッセージ,及び,鍵付ハッシュ関数を介して)確認し,最終メッセージ28を形成するために,署名されたメッセージに,それを添付する(ステップ408)。最終メッセージ28は,次に,任意の介在するルータ,或いは,他の第2ドメイン・ネットワーク・デバイスを介して,受信ルータに転送される。従来のPIM方法を踏まえ,及び,上に述べたことから,それぞれの,かかる介在PIMルータは,単に,添付された第2ドメインMACを試験することによって,そのメッセージを認証しているに過ぎない。第1境界ルータ20の電子署名は,それ故,望ましくは,そのような,他のネットワーク・デバイスによって,試験されることはない。受信されると,受信ルータは,添付された第2ドメインMSACにアクセスすることで,最終メッセージ28を,予め,認証する。(ステップ410,及び,412)。
ステップ412で,もし,最終メッセージ28が,予め認証されることが決定されれば,そのとき,受信ルータは,上に述べた方法で,第1境界ルータの電子署名を確認する。逆に,もし,最終メッセージ28が,ステップ412で,認証されなければ,次に,プロセスは,メッセージが破棄され,それ故,受信ルータ内の受信コンピュータ・システムへ届けられない,ステップ414へ進む。さらに,もし,正当でないと決定されれば,そのとき,第1境界ルータ20の電子署名は,メッセージが,少なくとも,第1境界ルータ20から送信されるまでは,正当であったことを,確認するために利用される。この方法において,第1境界ルータの署名を用いることは,その結果,メッセージが破棄された場合に用いられ得る,デバッギング・プロセスの助けとなる。
図4Bは,図4Aに示される方法によって処理されるような,メッセージの変形を示している。特に,オリジナル・メッセージ24は,メッセージ・データ25,ペイロードとして,送信ルータの電子署名38,及び,第1ドメインMAC32を含んでいる。境界ルータ20,及び,22のための中間鍵を使用するとき,第1境界ルータ20は,第1ドメインMAC32を取り除き,中間MAC34を付加する。加えて,第1境界ルータ20は,送信ルータ電子署名38を取り除き,自身の電子署名40を付加する。最後に,図4Bは,また,第2ドメインMAC36と,第1境界ルータの電子署名40を備える,最終メッセージ28を示している。)

(エ)本願の出願前に既に公知である,「岡本栄司,暗号理論入門,共立出版株式会社,1993年2月25日,p.129-131」(以下,これを「周知文献1」という)には,関連する図面と共に,次の事項が記載されている。

H.「7.1メッセージ認証
メッセージ認証(messsage authentication)とは,メッセージの正当性を確認する技術であり,認証子法と冗長暗号化法が実用化されている.

7.7.1 認証子法
証明者は認証子(MAC:messsage authentication code)と呼ばれるコードを作成してメッセージとともに送る.それを受けて検証者は,メッセージから同様に認証子を作成して,それが送られた認証子と一致するか否かで,メッセージの正当性(改ざんの有無)を判定する.図7.1は認証子法を示している.
認証子を作成するには,秘密鍵をパラメータとするハッシュ(hash)関数を使用する.すなわち,秘密鍵(認証鍵)Kを送信側と受信側で共有し,それを用いて認証子を作成するが,鍵Kを知らなければメッセージMと認証子h_(k)(M)から,異なるM’と対応するh_(k)(M’)を作れないような関数h_(k)である.」(129頁12行?130頁4行)

(オ)本願の出願前に既に公知である,特開平11-339045号公報(平成11年12月10日公開,以下,これを「周知文献2」という)には,関連する図面と共に,次の事項が記載されている。

I.「【0010】公開鍵暗号による電子署名は,以下の様に用いられる。以下では電子署名の作成者が,電子署名の検定者に渡したいデータのことを平文と呼ぶ。
【0011】先ず作成者は平文を秘密鍵で暗号化する。この平文を暗号化することにより生成されたデータを暗文と呼ぶ。この暗文が「電子署名」である。作成者は,平文と暗文(電子署名)を検定者に渡す。この平文と暗文の組合せを,以降,「電子署名データ」と呼ぶ。
【0012】次に検定者は,受け取った電子署名データの内,電子署名を作成者の公開鍵で復号する。作成者の公開鍵は,予め,または,電子署名データと共に,検定者に渡される。
【0013】次に検定者は,平文と電子署名を復号することにより得られたデータを比較する。以下では,この比較において,互いが一致することを検定の成功と呼び,一致しないことを検定の失敗と呼ぶ。
【0014】検定が成功したならば,以下のことがわかる。第一に,平文が改竄されていないことがわかる。平文を改竄すれば,電子署名の復号結果と一致しないからである。第二に,電子署名の作成者が,検定に用いた公開鍵と暗号鍵ペアを成す秘密鍵の所有者であることがわかる。何故なら,その公開鍵で復号できる暗文は,その公開鍵と暗号鍵ペアを成す秘密鍵で作成したものだけであることが,一般に公開鍵暗号アルゴリズムでは保証されているからである。」

ウ.引用文献1に記載の発明
(ア)上記Aの「多種類の電子署名方式を記憶した記憶手段をもち,その記憶されている各電子署名方式間の変換を行えるようにしたコンピュータを通信端末間の通信仲介役として備え,この仲介役コンピュータが,一方の通信端末から電子署名を受信し,該電子署名を所定の方式に変換して他方の通信端末へ送信する」という記載,及び,同じく,上記Aの「一方の取引者が銀行であり,他方の取引者として消費者との間でセキュリティセッションをはる場合に,消費者のもつ通信端末が携帯電話でそのシステムが当該銀行の電子署名方式に対応していなかったとしても,仲介役コンピュータが間に入り,銀行端末からの電子署名を受けて消費者の携帯電話に適した方式に変換することで,支障なくセキュリティで保護された通信を行うことができる」という記載から,引用文献1には,
“消費者のもつ通信端末である携帯電話と,銀行の通信端末である銀行端末との通信仲介役の仲介役コンピュータを設け,前記仲介役コンピュータは,前記銀行端末からの電子署名を受信し,受信した前記電子署名を,前記携帯電話に適した方式に変換して,前記携帯電話に送信する”ことが記載されているといえる。

(イ)上記Bの「Yクレジット端末と仲介役サーバとの間で電子署名方式Aによる通信が実施され,Yクレジット端末の方式Aによる公開鍵が証明書付で仲介役サーバへ渡される。証明書が確認されると,公開鍵により復号化が実施され,複号化した通信メッセージが一旦仲介役サーバに記憶される」という記載,及び,同じく,上記Bの「仲介役サーバと消費者端末との間には電子署名方式Bによるセキュリティがはられ,Yクレジット端末からの通信メッセージを復号化した仲介役サーバは,そのメッセージを方式Bによる秘密鍵により暗号化し,消費者端末へ送信する。消費者端末では,仲介役サーバから方式Bによる公開鍵が証明書付で入手されるので,証明書確認後,その公開鍵により復号化を実施する」という記載から,引用文献1には,
“Yクレジット端末と,消費者端末とが仲介役サーバを介して接続されたシステムであって,
前記Yクレジット端末から,前記仲介役サーバへ,電子署名方式Aによる電子署名と,Yクレジット端末の秘密鍵で暗号化された暗号化メッセージが送信され,前記仲介役サーバは,受信した前記電子署名方式Aによる電子署名を確認し,前記電子署名方式Aによる電子署名が正当であった場合,Yクレジット端末の公開鍵で,前記暗号化メッセージを復号し,復号したメッセージを,前記仲介サーバの秘密鍵で暗号化し,前記電子署名方式Aによる電子署名に替えて,電子署名方式Bによる電子署名を付して,前記暗号化メッセージを送信し,前記消費者端末は,受信した前記電子署名方式Bによる電子署名を確認するシステム”が記載されていると言える。

(ウ)上記(ア)において検討した,「消費者のもつ通信端末である携帯電話」,「銀行の通信端末である銀行端末」,及び,「仲介役コンピュータ」が,それぞれ,上記(イ)おいて検討した,「消費者端末」,「Yクレジット端末」,及び,「仲介役サーバ」に相当しており,「銀行の通信端末である銀行端末」,或いは,「Yクレジット端末」は,「業者側端末」といえ,「消費者のもつ通信端末である携帯電話」,或いは,「消費者端末」は,「消費者側端末」といえ,そして,「仲介役コンピュータ」,或いは,「仲介役サーバ」は,「仲介装置」といえるものであるから,上記(ア),及び,上記(イ)において検討した事項を踏まえると,引用文献1には,次の発明(以下,これを「引用発明」という)が記載されているものと認める。

「業者側端末と,消費者側端末とが,仲介装置を介して接続されたシステムであって,
前記業者側端末から,前記仲介装置へ,電子署名方式Aによる電子署名と,業界側端末の秘密鍵で暗号化された暗号化メッセージが送信され,
前記仲介装置は,受信した前記電子署名方式Aによる電子署名を確認し,前記電子署名方式Aによる電子署名が正当であった場合,業界側端末の公開鍵で,前記暗号化メッセージを復号し,復号したメッセージを,前記仲介装置の秘密鍵で暗号化し,前記電子署名方式Aによる電子署名に替えて,電子署名方式Bによる電子署名を付して,前記暗号化メッセージを,前記消費者側端末へ送信し,
前記消費者端末は,受信した前記電子署名方式Bによる電子署名を確認するシステム。」

エ.本件補正発明と引用発明との対比
(ア)引用発明における「業者側端末」は,結果として,「消費者側端末」に,その「電子署名」を確認される,即ち,認証されることになるので,
引用発明における「業者側端末」,「消費者側端末」が,それぞれ,本件補正発明における「被認証器」,「認証器」に相当する。

(イ)引用発明における「仲介装置」は,「業者側端末」の「電子署名」を確認,即ち,認証し,その後,当該「電子署名」を,「消費者側端末」が確認できる「電子署名」に置き換えているので,本件補正発明における「認証子変換器」に対応する。

(ウ)引用発明においても,「業者側端末」は,「電子署名方式Aによる電子署名」を生成するものであって,
引用発明における「電子証明方式Aによる電子署名」と,
本件補正発明における「第1の認証データ」とは,
“第1認証情報”である点で共通するので,
引用発明において,“業者側端末が,電子署名方式Aによる電子署名を生成する”ことと,
本件補正発明における「第1の認証データを生成する被認証器」とは,
“第1認証情報を生成する被認証器”である点で共通する。

(エ)引用発明において,「仲介装置」が,「電子署名方式Aによる電子署名」を確認することは,即ち,「業者側端末」が,正当な送信者であることを確認,即ち,認証することに他ならなず,
引用発明における「電子署名方式Bによる電子署名」と,
本件補正発明における「第2の認証データ」とは,
“第2認証情報”である点で共通するものであるから,
引用発明において,「仲介装置は,受信した前記電子署名方式Aによる電子署名を確認し,前記電子署名方式Aによる電子署名が正当であった場合,前記電子署名方式Aによる電子署名に替えて,電子署名方式Bによる電子署名を付」すことと,
本件補正発明における「被認証器にて生成された前記第1の認証データに基づき前記被認証器を認証し,前記第1の認証データを第2の認証データに変換する認証子変換器」とは,
“被認証器にて生成された第1認証情報に基づき前記被認証器を認証し,前記第1認証情報を第2認証情報に変換する認証子変換器”である点で共通する。

(オ)引用発明における「消費者端末は,受信した前記電子署名方式Bによる電子署名を確認する」と,
本件補正発明における「認証子変換器にて変換された前記第2の認証データに基づいて,認証処理を行う認証器」とは,
“認証子変換器にて変換された第2認証情報に基づいて認証処理を行う認証器”である点で共通する。

(カ)引用発明において,「仲介装置」は,「秘密鍵」を用いて,「消費者側端末」へ送信する「メッセージ」を暗号化しているので,
引用発明において,“仲介装置は,秘密鍵を有する”ことが,
本件補正発明における「認証子変換器は,秘密鍵を有し」に相当する。

(キ)引用発明において,「消費者側端末」は,「受信した前記電子署名方式Bによる電子署名を確認」した後,「暗号化メッセージ」を,「仲介装置」の「公開鍵」で復号することになるから,
引用発明において,“消費者側端末が,仲介装置の公開鍵を有する”ことは明らかであって,このことが,
本件補正発明における「認証器は,公開鍵を有し」に相当する。

(ク)以上,上記(ア)?(キ)において検討した事項から,本件補正発明と,引用発明との,一致点,及び,相違点は,次のとおりである。

[一致点]
第1認証情報を生成する被認証器と,
前記被認証器にて生成された前記第1認証情報に基づき前記被認証器を認証し,前記第1認証情報を第2認証情報に変換する認証子変換器と,
前記認証子変換器にて変換された前記第2認証情報に基づいて,認証処理を行う認証器と,を備え,
前記認証子変換器は,秘密鍵を有し,
前記認証器は,公開鍵を有する,システム。

[相違点1]
“第1認証情報”に関して,
本件補正発明においては,「第1の認証データは,第1認証子と前記被認証器が有する所定データとを含」むものであるのに対して,
引用発明における「電子証明方式Aによる電子署名」が,そのような構成を有するかについては,特に言及されていない点。

[相違点2]
本件補正発明においては,「被認証器は,前記認証器から送信されたチャレンジデータと前記所定データを,共通鍵を用いた共通鍵暗号方式で計算して前記第1認証子を生成し,生成した前記第1認証子と前記所定データとを前記第1の認証データとして前記認証子変換器に送信」するものであるのに対して,
引用発明においては,「業者側端末」の認証に「チャレンジ」を用いる点について,特に言及されていない点。

[相違点3]
“第2認証情報”に関して,
本件補正発明においては,「第2の認証データは,第2認証子と前記被認証器が有する前記所定データとを含」むものであるのに対して,
引用発明における「電子署名方式Bによる電子署名」が,そのような構成を有するかについては,特に言及されていない点。

[相違点4]
本件補正発明においては,「被認証器から送信された前記第1の認証データの前記所定データと前記認証器から送信された前記チャレンジデータを,前記共通鍵を用いた共通鍵暗号方式で計算して第1比較認証子を生成し,生成した前記第1比較認証子と,前記第1の認証データの前記第1認証子と,を比較し,前記第1比較認証子と前記第1認証子が一致した場合に,前記被認証器から送信された前記第1の認証データの前記所定データと前記認証器から送信された前記チャレンジデータを前記秘密鍵を用いた公開鍵暗号方式で計算して前記第2認証子を生成し,生成した前記第2認証子と前記所定データとを前記第2の認証データとして前記認証器に送信」するものであるのに対して,
引用発明においては,「仲介装置」における「電子署名方式Aによる電子署名」の確認が,「共通鍵暗号方式」の「チャレンジ」の検証である点については,特に言及されていない点。

[相違点5]
本件補正発明においては,「認証子変換器から送信された前記第2の認証データの前記所定データと前記認証子変換器に送信した前記チャレンジデータとを結合し,前記認証子変換器から送信された前記第2の認証データの前記第2認証子を前記公開鍵を用いて復号し,復号した結果と,前記結合したデータとを比較して前記認証処理を行う」ものであるのに対して,
引用発明においては,「電子署名方式Bによる電子署名を確認する」ことについて,具体的に特定されていない点。

オ.相違点についての当審の判断
(ア)[相違点1],及び,[相違点2]について
上記Gに引用した引用文献3の記載内容は,“引用発明における「業者側端末」(本件補正発明にける「被認証器」)に相当する送信ルータから送信された,送信ルータの電子署名と,第1ドメインMACの両方を認証する”ことが示されていて,「MAC」が,「認証子」であること,「MAC」の認証は,共通鍵暗号方式であり,受信した情報から求めた値と,当該受信した情報とともに取得した「MAC」とが一致するかによって行われるものであることは,上記Fに引用した引用文献3の記載内容,上記Cに引用した引用文献2の記載内容,或いは,上記Hに引用した周知文献1の記載内容にもあるように,本願の出願前に当業者には広く知られた技術事項である。
また,引用文献2には,上記Dに引用した記載内容にあるように,乱数R(本件補正発明における「チャレンジ」に相当)を送信し,当該送信に対する応答(レスポンス)が,正当であるかを判断して,相手の正当性を確認する,チャレンジ・レスポンスについて言及されていて,当該チャレンジ・レスポンスは,本願の出願前に当業者には広く知られた技術事項である。
そして,引用発明,引用文献2,及び,引用文献3は,何れも,通信相手の正当性を認証する技術に関するものであるから,引用発明において,署名検証に替えて,「MAC」を用いたチャレンジ・レスポンスを採用し,「業者側端末」から,「仲介装置」へ送信する情報として,「業者側端末」で計算した「MAC」と,「仲介装置」において,当該「MAC」を計算するために必要なデータを送信するよう構成することは,当業者が適宜なし得る事項である。
よって,[相違点1],及び,[相違点2]は,格別のものではない。

(イ)[相違点3],及び,[相違点4]について
上記(ア)においても検討した,上記Gに引用した引用文献3には,“第1境界ルータが,送信ルータの電子署名と,第1ドメインMACの両方の認証を行い,認証された場合には,当該送信ルータの電子署名と,第1ドメインMACの両方を取り除いて,代わりに当該第1境界ルータの電子署名を添付して,第2境界ルータ(引用発明における「消費者側端末」,本件補正発明における「認証器」に相当)に送信する”ことが示されていて,引用発明は,「業者側端末」による「電子署名方式Aによる電子署名」を,「仲介装置」において認証後,「消費者側端末」において認証可能な,「電子署名方式Bによる電子署名」に置き換えるものであるから,上記(ア)において検討した事項を踏まえれば,引用発明において,「業者側端末」と,「仲介装置」において採用した「MAC」を用いた認証に成功した場合に,当該「MAC」を,「電子署名方式Bによる電子署名」に置き換え,「消費者側端末」に,「電子署名方式Bによる電子署名」と,当該「電子署名」を検証するために必要な情報とを送信するよう構成することは,当業者が適宜なし得る事項である。
よって,[相違点3],及び,[相違点4]は,格別のものではない。

(ウ)[相違点5]について
公開鍵暗号を用いた署名検証自体は,本願の出願前に当業者には周知の技術事項である(必要であれば,上記Iに記載内容を引用した周知文献2等を参照されたい)。
したがって,上記(ア),及び,上記(イ)において検討した事項を踏まえれば,引用発明において,「業者側端末」と,「消費者側端末」において,チャレンジ・レスポンスによる認証を行う場合に,「消費者側端末」において,「仲介装置」から,送信されてきた「電子署名」を検証することで,結果として,「業者側端末」の正当性を認証するよう構成することは,当業者が適宜なし得る事項である。
よって,[相違点5]は,格別のものではない。

(エ)以上,上記(ア)?(ウ)において検討したとおり,[相違点1]?[相違点5]はいずれも格別のものではなく,そして,本件補正発明の構成によってもたらされる効果も,当業者であれば当然に予測可能なものに過ぎず格別なものとは認められない。
したがって,本件補正発明は,本願の特許出願前に日本国内又は外国において頒布された刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基づいて当業者が容易に発明をすることができたものであるので,特許法第29条第2項の規定により,特許出願の際,独立して特許を受けることができない。

3.補正却下むすび
したがって,本件手続補正は,特許法第17条の2第6項において準用する同法第126条第7項の規定に違反するので,同法第159条第1項の規定において読み替えて準用する同法第53条第1項の規定により却下すべきものである。

よって,補正却下の決定の結論のとおり決定する。

第3.原審拒絶査定の概略
原審における平成29年8月22日付けの拒絶査定(以下,これを「原審拒絶査定」という)の概略は,次のとおりである。
「備考
●理由2(特許法第36条第4項第1号)について
・請求項 1-12
補正後の請求項1には「前記認証子変換器にて変換された前記第2の認証データに基づいて,前記被認証器の認証を行う認証器」が記載されているところ,上記拒絶理由通知書において述べたとおり,本願明細書の発明の詳細な説明には,「前記認証子変換器にて変換された前記第2の認証データに基づいて,前記被認証器の認証を行う認証器」について,当業者が実施可能な程度に明確かつ十分に記載がなされていない。請求項3及びそれら請求項1,3を引用する請求項2,4-12についても同様のことがいえる。

よって,この出願の発明の詳細な説明は,依然として,当業者が請求項1-12に係る発明を実施することができる程度に明確かつ十分に記載されたものでない。
・・・(中略)・・・

●理由3(特許法第36条第6項第2号)について
・請求項 1-12
補正後の請求項1には「前記認証子変換器にて変換された前記第2の認証データに基づいて,前記被認証器の認証を行う認証器」及び「前記第2の認証データは,第2認証子と前記被認証器が有する前記所定データとを含み,
前記認証子変換器は,秘密鍵を有し,前記被認証器から送信された前記所定データと前記認証器から送信された前記チャレンジデータを前記秘密鍵を用いた公開鍵暗号方式で計算して前記第2認証子を生成し」が記載されている。
請求項1の記載「前記第2の認証データは,第2認証子・・・を含み」及び「前記認証子変換器は,秘密鍵を有し,・・・前記秘密鍵を用いた公開鍵暗号方式で計算して前記第2認証子を生成し」より,第2の認証データに基づいて行う認証は,その第2の認証データが含む,認証子変換器が,自ら有する秘密鍵を用いて計算した第2認証子に基づく認証であり,そのことから,第2認証子を生成した「認証子変換器」の認証である。
しかしながら,請求項1の記載「前記認証子変換器にて変換された前記第2の認証データに基づいて,前記被認証器の認証を行う認証器」から,請求項1には,認証器が行う認証が,第2の認証データに基づいて行う認証であるにも関わらず,「被認証器」の認証であると記載されている。
そうすると,「前記第2の認証データは,第2認証子・・・を含み」,「前記認証子変換器は,秘密鍵を有し,・・・前記秘密鍵を用いた公開鍵暗号方式で計算して前記第2認証子を生成」するにも関わらず,認証器が「前記第2の認証データに基づいて,前記被認証器の認証を行う」ということは,認証器が認証する対象について矛盾しており不明なものである。請求項3及びそれら請求項1,3を引用する請求項2,4-12についても同様のことがいえる。

よって,請求項1-12に係る発明は明確でない。

●理由4(特許法第29条第2項)について
・請求項 1-12
・引用文献等 1-6
補正後の請求項1に係る発明と引用文献1に記載された発明とは
「第1の認証データを生成する被認証器と,
前記被認証器にて生成された前記第1の認証データを第2の認証データに変換する認証子変換器と,
前記認証子変換器にて変換された前記第2の認証データに基づいて,認証を行う認証器と,を備え,
前記第1の認証データは,第1認証子と前記被認証器が有する所定データとを含み,
前記被認証器は,前記所定データを,暗号方式で計算して前記第1認証子を生成し,生成した前記第1認証子と前記所定データとを前記認証子変換器に送信し,
前記第2の認証データは,第2認証子と前記被認証器が有する前記所定データとを含み,
前記認証子変換器は,秘密鍵を有し,前記被認証器から送信された前記所定デーを前記秘密鍵を用いた公開鍵暗号方式で計算して前記第2認証子を生成し,生成した前記第2認証子と前記所定データを前記認証器に送信し,
前記認証器は,公開鍵を有し,前記認証子変換器から送信された前記第2認証子を前記公開鍵を用いて復号し,復号した結果と,データとを比較して認証することを特徴とする認証システム。」
である点で一致し,以下に挙げる点で相違する。
(a)認証器が,請求項1に係る発明では「被認証器」の認証を行うものであるのに対して,引用文献1に記載された発明では「被認証器」の認証を行うものか,明らかでない点。
(b)被認証器が,請求項1に係る発明では,「共通鍵を用いた共通鍵」暗号方式で計算して前記第1認証子を生成するのに対して,引用文献1に記載された発明では,暗号方式で計算して前記第1認証子を生成するものの,その暗号方式が「共通鍵を用いた共通鍵」暗号方式ではない点。
(c)請求項1に係る発明において,被認証器が第1認証子の生成にあたり「前記認証器から送信されたチャレンジデータ」をも用い,認証変換器が第2認証子の生成にあたり「前記認証器から送信された前記チャレンジデータ」をも用い,認証器が「前記認証子変換器から送信された前記所定データと前記認証子変換器に送信した前記チャレンジデータとを結合」し,復号した結果と,「前記結合した」データとを比較しているのに対して,引用文献1に記載された発明では,それらの如く構成していない点。

上記相違点について検討する。
(a)について
上記拒絶理由通知書の請求項1に関し相違点(a)についての項で述べたとおり,理由2,3にて述べたように,そもそも本願において,認証器が「被認証器」の認証を行うということが,発明の詳細な説明に実施可能な程度に記載されておらず,請求項1の記載において矛盾した不明なものであることを考慮すれば,この点を実質的な相違点とすることはできない。
(b)について
上記拒絶理由通知書の請求項2に関して述べたと同様,引用文献2,3に記載の技術を参酌し,引用文献1に記載された発明において,電子署名方式Aを,共通鍵によるものとして,被認証器が「共通鍵を用いた共通鍵」暗号方式で計算して前記第1認証子を生成するように構成することは,当業者にとって格別困難なことではない。
(c)について
上記拒絶理由通知書の請求項1に関し相違点(b)についての項で述べたと同様,引用文献2に記載の技術を参酌し,被認証器が第1認証子の生成にあたり「前記認証器から送信されたチャレンジデータ」をも用い,認証変換器が第2認証子の生成にあたり「前記認証器から送信された前記チャレンジデータ」をも用い,認証器が「前記認証子変換器から送信された前記所定データと前記認証子変換器に送信した前記チャレンジデータとを結合」し,復号した結果と,「前記結合した」データとを比較するように構成することは,当業者にとって容易である。

したがって,請求項1に係る発明は,引用文献1に記載された発明及び引用文献2,3に記載の技術に基づいて当業者が容易に想到し得たものであるから,特許法第29条第2項の規定により特許を受けることができない。請求項2-12に係る発明も,上記拒絶理由通知書において述べた同様のことから,引用文献1に記載された発明及び引用文献2-6に記載の技術に基づいて,当業者が容易に想到し得たものであり,特許法第29条第2項の規定により特許を受けることができない。
・・・(中略)・・・

<引用文献等一覧>
1.特開2002-208926号公報
2.Davis, D. W. and Price, W. L., ネットワーク・セキュリティ,日経マグロウヒル社,1985年12月5日, p.114-116, p.126-129
3.米国特許第6725276号明細書
4.特表2003-503901号公報
5.特開平8-101868号公報
6.特開2008-146179号公報」

第4.原審拒絶査定についての当審の判断
1.36条4項1号について
平成29年3月13日付けの手続補正により補正された特許請求の範囲の請求項1においても,「第2認証子を前記公開鍵を用いて復号し,復号した結果と,前記結合したデータとを比較して前記被認証器を認証する」と記載されていて,この記載に従えば,本願の請求項1に係る発明においては,“認証器は,第2認証子を用いて,被認証器を認証するものである”と解される。
これに対して,本願明細書の発明の詳細な説明の段落【0037】?段落【0048】に記載の内容,及び,段落【0067】?段落【0078】に記載の内容,特に,段落【0044】,段落【0047】,及び,段落【0076】,段落【0077】に記載の内容から,「認証器」は,「認証子変換器」内の「第2の耐タンパチップ」によって生成された「第2の認証子」の一致の判定を行うものであるから,当該本願明細書の発明の詳細な説明に記載の内容に従えば,本願明細書の発明の詳細な説明において,「第2の認証子」を用いて,「認証器」によって認証されているのは,「認証子変換器」である。
そして,本願明細書の発明の詳細な説明には,「第2の認証子」を用いて,「認証器」が,「被認証器」を認証する手法については,明確に示されておらず,どのようにして,「認証器」が,「第2の認証子」用いて,「認証子変換器」を認証することで,結果として,「認証器」が,「被認証器」を認証することになるのか,不明である。
よって,本願明細書の発明の詳細な説明は,依然として,経済産業省令で定めるところにより,その発明の属する技術分野における通常の知識を有する者がその実施をすることができる程度に明確かつ十分に記述したものでない。

2.36条6項2号について
上記1.において検討したとおり,平成29年3月13日付けの手続補正により補正された特許請求の範囲の請求項1には,
「第2認証子を前記公開鍵を用いて復号し,復号した結果と,前記結合したデータとを比較して前記被認証器を認証する」,
と記載されているが,本願の請求項1,及び,本願の他の請求項に記載の内容を検討しても,「認証子変換器」において生成された「第2認証子」を用いて,どのようにして,「認証子変換器」において,「第1認証子」を用いて認証される「被認証器」を認証し得るのか,不明である。
よって,本願の請求項1に係る発明は,依然として,明確ではない。

3.29条2項について
ア.本願発明について
平成29年11月29日付けの手続補正は,上記のとおり却下されたので,本願の請求項1に係る発明(以下,これを「本願発明」という)は,平成29年3月13日付けの手続補正により補正された特許請求の範囲の請求項1に記載された,上記「第2.平成29年11月29日付けの手続補正の却下の決定」の「1.補正の内容」において,補正前の請求項1として引用した,次のとおりのものである。
なお,上記2.において検討したとおり,本願発明においては,明確でない構成が存在するものの,字句どおりのものとして,以下の検討を行う。

「第1の認証データを生成する被認証器と,
前記被認証器にて生成された前記第1の認証データを第2の認証データに変換する認証子変換器と,
前記認証子変換器にて変換された前記第2の認証データに基づいて,前記被認証器の認証を行う認証器と,を備え,
前記第1の認証データは,第1認証子と前記被認証器が有する所定データとを含み,
前記被認証器は,前記認証器から送信されたチャレンジデータと前記所定データを,共通鍵を用いた共通鍵暗号方式で計算して前記第1認証子を生成し,生成した前記第1認証子と前記所定データとを前記認証子変換器に送信し,
前記第2の認証データは,第2認証子と前記被認証器が有する前記所定データとを含み,
前記認証子変換器は,秘密鍵を有し,前記被認証器から送信された前記所定データと前記認証器から送信された前記チャレンジデータを前記秘密鍵を用いた公開鍵暗号方式で計算して前記第2認証子を生成し,生成した前記第2認証子と前記所定データを前記認証器に送信し,
前記認証器は,公開鍵を有し,前記認証子変換器から送信された前記所定データと前記認証子変換器に送信した前記チャレンジデータとを結合し,前記認証子変換器から送信された前記第2認証子を前記公開鍵を用いて復号し,復号した結果と,前記結合したデータとを比較して前記被認証器を認証することを特徴とする認証システム。」

イ.引用刊行物に記載の発明
原審拒絶理由において引用された,特開2002-208926号公報(平成14年7月26日公開)には,上記「第2.平成29年11月29日付けの手続補正の却下の決定」の「2.補正の適否」の「(2)独立特許要件」における「ウ.引用文献1に記載の発明」において認定したとおりの,次の引用発明が記載されている。

「業者側端末と,消費者側端末とが,仲介装置を介して接続されたシステムであって,
前記業者側端末から,前記仲介装置へ,電子署名方式Aによる電子署名と,業界側端末の秘密鍵で暗号化された暗号化メッセージが送信され,
前記仲介装置は,受信した前記電子署名方式Aによる電子署名を確認し,前記電子署名方式Aによる電子署名が正当であった場合,業界側端末の公開鍵で,前記暗号化メッセージを復号し,復号したメッセージを,前記仲介装置の秘密鍵で暗号化し,前記電子署名方式Aによる電子署名に替えて,電子署名方式Bによる電子署名を付して,前記暗号化メッセージを,前記消費者側端末へ送信し,
前記消費者端末は,受信した前記電子署名方式Bによる電子署名を確認するシステム。」

ウ.本願発明と引用発明との対比
本願発明は,本件補正発明における,
「第1の認証データに基づき前記被認証器を認証し,前記第1の認証データを第2の認証データに変換する」,
「第2の認証データに基づいて,認証処理を行う」,
「生成した前記第1認証子と前記所定データとを前記第1の認証データとして前記認証子変換器に送信し」,
「第1の認証データの前記所定データと前記認証器から送信された前記チャレンジデータを前記秘密鍵を用いた公開鍵暗号方式で計算して前記第2認証子を生成し」,
「生成した前記第2認証子と前記所定データとを前記第2の認証データとして前記認証器に送信し」,
「第2の認証データの前記所定データと前記認証子変換器に送信した前記チャレンジデータとを結合し」,
「第2の認証データの前記第2認証子を前記公開鍵を用いて復号し」,
「認証処理を行う」,
を,
「第1の認証データを第2の認証データに変換する」,
「第2の認証データに基づいて,前記被認証器の認証を行う」,
「生成した前記第1認証子と前記所定データとを前記認証子変換器に送信し」,
「前記所定データと前記認証器から送信された前記チャレンジデータを前記秘密鍵を用いた公開鍵暗号方式で計算して前記第2認証子を生成し」,
「生成した前記第2認証子と前記所定データとを前記認証器に送信し」,
「前記所定データと前記認証子変換器に送信した前記チャレンジデータとを結合し」,
「前記第2認証子を前記公開鍵を用いて復号し」,
「前記被認証器を認証する」,
とし,本件補正発明における,
「前記被認証器から送信された前記第1の認証データの前記所定データと前記認証器から送信された前記チャレンジデータを,前記共通鍵を用いた共通鍵暗号方式で計算して第1比較認証子を生成し,生成した前記第1比較認証子と,前記第1の認証データの前記第1認証子と,を比較し,前記第1比較認証子と前記第1認証子が一致した場合に」,
という構成を削除したものであるから,
本願発明と,引用発明との,一致点,及び,相違点は,次のとおりである。

[一致点]
第1認証情報を生成する被認証器と,
前記被認証器にて生成された前記第1認証情報に基づき前記被認証器を認証し,前記第1認証情報を第2認証情報に変換する認証子変換器と,
前記認証子変換器にて変換された前記第2認証情報に基づいて,認証を行う認証器と,を備え,
前記認証子変換器は,秘密鍵を有し,
前記認証器は,公開鍵を有する,システム。

[相違点a]
“認証を行う認証器”に関して,
本願発明は,「被認証器を認証する」ものであるのに対して,
引用発明においては,「消費者側端末」は,直接,「業者側端末」を認証するものではない点。

[相違点b]
“第1認証情報”に関して,
本願発明においては,「第1の認証データは,第1認証子と前記被認証器が有する所定データとを含」むものであるのに対して,
引用発明における「電子証明方式Aによる電子署名」が,そのような構成を有するかについては,特に言及されていない点。

[相違点c]
本願発明においては,「被認証器は,前記認証器から送信されたチャレンジデータと前記所定データを,共通鍵を用いた共通鍵暗号方式で計算して前記第1認証子を生成し,生成した前記第1認証子と前記所定データとを前記第1の認証データとして前記認証子変換器に送信」するものであるのに対して,
引用発明においては,「業者側端末」の認証に「チャレンジ」を用いる点について,特に言及されていない点。

[相違点d]
“第2認証情報”に関して,
本願発明においては,「第2の認証データは,第2認証子と前記被認証器が有する前記所定データとを含」むものであるのに対して,
引用発明における「電子署名方式Bによる電子署名」が,そのような構成を有するかについては,特に言及されていない点。

[相違点e]
本願発明においては,「前記被認証器から送信された前記第1の認証データの前記所定データと前記認証器から送信された前記チャレンジデータを前記秘密鍵を用いた公開鍵暗号方式で計算して前記第2認証子を生成し,生成した前記第2認証子と前記所定データとを前記認証器に送信」するものであるのに対して,
引用発明においては,「共通鍵暗号方式」の「チャレンジ」を用いる点については,特に言及されていない点。

[相違点f]
本願発明においては,「認証子変換器から送信された前記所定データと前記認証子変換器に送信した前記チャレンジデータとを結合し,前記認証子変換器から送信された前記第2認証子を前記公開鍵を用いて復号し,復号した結果と,前記結合したデータとを比較して前記被認証器を認証する」ものであるのに対して,
引用発明においては,「電子署名方式Bによる電子署名を確認する」ことについて,具体的に特定されていない点。

エ.相違点についての当審の判断
(ア)[相違点b]?[相違点e]について
本願発明と,引用発明との[相違点b]?[相違点d]は,本件補正発明と,引用発明との[相違点1]?[相違点3]と同じものであり,
本願発明と,引用発明との[相違点e]は,「第2認証子」と,「所定データ」とを「認証器」に送信することに関する点については,[相違点4]と同じものであるから,
上記「第2.平成29年11月29日付けの手続補正の却下の決定」の「2.補正の適否」の「(2)独立特許要件」における「オ.相違点についての当審の判断」の(ア)?(エ)において検討したとおり,格別のものではない。

(イ)[相違点a],及び,[相違点f]について
本願発明と,引用発明との[相違点a],及び,[相違点f]は,上記「1.36条4項1号について」,及び,「2.36条6項2号について」において検討した,本願発明の明確でない構成に係るものであるから,どのように構成されているか不明であり,そのままでは,引用発明,或いは,他の引用文献等と対比することはできない。
仮に,[相違点a],及び,[相違点f]に係る構成が,本願明細書の発明の詳細な説明に記載の構成を表現したものであるとすれば,上記「第2.平成29年11月29日付けの手続補正の却下の決定」の「2.補正の適否」の「(2)独立特許要件」における「エ.本件補正発明と引用発明との対比」,及び,「オ.相違点についての当審の判断」の(ア)?(エ)において検討したとおり,[相違点a]は,[一致点]に含まれることとなり,[相違点f]は,本件補正発明と,引用発明との[相違点5]と同じものになるので,格別のものではない。

(ウ)以上,上記(ア),(イ)において検討したとおりであるから,本願発明において明確でない記載が存在する点を考慮しても,本願発明と,引用発明との[相違点a]?[相違点f]はいずれも格別のものではなく,引用発明,及び,引用文献2,引用文献3に記載された技術事項に基づいて,当業者が適宜なし得る事項である。
そして,本願発明の構成によってもたらされる効果も,当業者であれば当然に予測可能なものに過ぎず格別なものとは認められない。

第6.むすび
したがって,本願は,特許法第36条第4項第1号及び第6項第2号に規定する要件を満たしておらず,加えて,
本願発明は,本願の特許出願前に日本国内又は外国において頒布された刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基づいて当業者が容易に発明をすることができたものであるので,特許法第29条第2項の規定により特許を受けることができない。

よって,結論のとおり審決する。
 
審理終結日 2018-09-28 
結審通知日 2018-10-09 
審決日 2018-11-02 
出願番号 特願2013-10800(P2013-10800)
審決分類 P 1 8・ 537- Z (H04L)
P 1 8・ 536- Z (H04L)
P 1 8・ 575- Z (H04L)
P 1 8・ 121- Z (H04L)
最終処分 不成立  
前審関与審査官 中里 裕正  
特許庁審判長 辻本 泰隆
特許庁審判官 石井 茂和
山崎 慎一
発明の名称 認証システム  
代理人 中村 英子  
代理人 梶 俊和  

プライバシーポリシー   セキュリティーポリシー   運営会社概要   サービスに関しての問い合わせ