【事件の表示】
　特願２０１２−１８１１１６「相互認証のための方法および装置」拒絶査定不服審判事件〔平成２５年　１月２４日出願公開，特開２０１３−　１７１９７〕について，次のとおり審決する。
【結　論】
　本件審判の請求は，成り立たない。
【理　由】
第１．手続の経緯
　本願は，２００７年１０月５日（パリ条約による優先権主張外国庁受理２００６年１０月１０日，２００７年１０月３日　アメリカ合衆国）を国際出願日とする特願２００９−５３２５０８号の一部を，平成２４年８月１７日に新たな特許出願としたものであって，
　平成２４年９月１４日付けで特許法第３６条の２第２項の規定によ外国語書面及び外国語要約書面の日本語による翻訳文が提出されると共に審査請求並びに手続補正がなされ，平成２４年１２月７日付けで手続補正がなされ，平成２５年７月８日付けで審査官により拒絶理由が通知され，これに対して平成２５年１０月１０日付けで意見書が提出されたが，平成２５年１０月２５日付けで審査官により拒絶査定がなされ（発送；平成２５年１０月２９日），これに対して平成２６年２月２８日付けで審判請求がなされたものである。
　
第２．本願発明について
　本願の請求項１に係る発明（以下，これを「本願発明」という）は，平成２４年１２月７日付けの手続補正により補正された特許請求の範囲の請求項１に記載された，次のとおりのものである。
　
「　【請求項１】
　ハードウェアの第１のエンティティとハードウェアの第２のエンティティとの間の相互認証のための方法であって，
　前記第１のエンティティが前記第２のエンティティにメッセージを送信することにより相互認証を開始することと；
　前記第２のエンティティが前記第１のエンティティに関連した第１の公開鍵を検証し，第１の乱数を生成し，第１の暗号化において前記第１の公開鍵を使用して前記第１の乱数を暗号化し，前記暗号化された第１の乱数をメッセージ中で前記第１のエンティティに送信することと；
　前記第１のエンティティが前記第２のエンティティに関連した第２の公開鍵を検証し，第１の復号において前記第１の公開鍵に対応した第１の秘密鍵を使用して前記暗号化された第１の乱数を復号し，第２の乱数を生成し，少なくとも前記第１の乱数に基づいて第１のハッシュを生成し，第２の暗号化において前記第２の公開鍵を使用して前記第２の乱数および前記第１のハッシュを暗号化し，前記暗号化された第２の乱数および第１のハッシュをメッセージ中で前記第２のエンティティに送信することと；
　前記第２のエンティティが第２の復号において前記第２の公開鍵に対応する第２の秘密鍵を使用して前記暗号化された第２の乱数および第１のハッシュを復号し，前記第１のエンティティを認証するために前記第１のハッシュを検証し，少なくとも前記第２の乱数に基づいて第２のハッシュを生成し，前記第２のハッシュを前記第１のエンティティに送信することと；
　前記第１のエンティティが前記第２のエンティティを認証するために前記第２のハッシュを検証することと；
　を備え，
　前記相互認証は，前記第１及び第２の暗号化を備える２つの暗号化以内に制限され，かつ，前記第１及び第２の復号を備える２つの復号以内に制限される，
　相互認証方法。」
　
第３．引用刊行物に記載の発明
　原審が，平成２５年７月８日付けの拒絶理由（以下，これを「原審拒絶理由」という）に引用した，本願の原出願の第１国出願前に既に公知である，特開２００３−１２４９２７号公報（２００３年０４月２５日公開，以下，これを「引用刊行物１」という）には，関連する図面と共に，次の事項が記載されている。
　
Ａ．「【０１１２】
図８には，携帯情報端末１５とコンテンツ配信サーバ１３間で行われる相互認証の処理手順に関する他の例を示している
携帯情報端末１５は
公開鍵暗号方式による公開鍵Ｅaとこれに非対称な秘密鍵を持ち
コンテンツ配信サーバ１３は
公開鍵暗号方式による公開鍵Ｅbとこれに非対称な秘密鍵を持つものとする
【０１１３】まず，
クライアントとしての携帯情報端末１５は，自分の公開鍵Ｅaを含んだ電子署名ＣｅｒｔｉｆｉｃａｔｉｏｎＡを送信する
【０１１４】
コンテンツ配信サーバ１３側では，この電子署名ＣｅｒｔｉｆｉｃａｔｉｏｎＡを受信すると，電子署名検証部３２でこれを検証する
【０１１５】
電子署名が正しいと判断された場合には，乱数発生部３３で相互認証に用いる乱数Ｎbを発生させ，これを携帯情報端末１５側の公開鍵Ｅaで暗号化して，これを電子署名生成部３４で生成した電子署名ＣｅｒｔｉｆｉｃａｔｉｏｎＢとともに携帯情報端末１５に送信する
【０１１６】
携帯情報端末１５側では，電子署名ＣｅｒｔｉｆｉｃａｔｉｏｎＢと暗号データＥa（Ｎb）からなるメッセージを受信すると，電子署名検証部３２で電子署名ＣｅｒｔｉｆｉｃａｔｉｏｎＢの検証を行う。電子署名が正しいと判断された場合には，暗号化処理部５５において，暗号化データＥa（Ｎb）を復号化して，Ｎbを取り出して，そのハッシュ値Ｈａｓｈ（Ｎb）を作成する。さらに，乱数生成部５３で相互認証に用いる乱数Ｎaを発生させ，コンテンツ配信サーバ１３側の公開鍵Ｅbでこれを暗号化する。そして，このようにして作成されたＥb（Ｎa）及びＨａｓｈ（Ｎb）を含むメッセージを，コンテンツ配信サーバ１３に送信する
【０１１７】
コンテンツ配信サーバ１３側では，Ｅb（Ｎa）及びＨａｓｈ（Ｎb）を含むメッセージを受信すると，携帯情報端末１５についての認証処理を行う
【０１１８】まず，
所定のハッシュ・アルゴリズムにより乱数発生部３２（当審注；「乱数発生部３３」の誤記である）で発生した乱数Ｎbのハッシュ値を計算する（ステップＳ３１）。そして，計算されたハッシュ値が，携帯情報端末１５から受信したハッシュ値Ｈａｓｈ（Ｎb）と等しいか否かを判別する
【０１１９】
これらハッシュ値が等しい場合，携帯情報端末１５が正しくメッセージを復号化できたことを確認できるので，携帯情報端末１５が本物の通信相手であることが判る
【０１２０】次いで，
受信した暗号化データＥb（Ｎa）を暗号処理部３５で復号化して，携帯情報端末１５側の乱数Ｎaを取り出す
【０１２１】そして，
所定のハッシュ・アルゴリズムによりこの乱数Ｎaのハッシュ値Ｈａｓｈ（Ｎa）を計算して（ステップＳ３４），これを携帯情報端末１５に送信する
　
Ｂ．「【０１２３】
携帯情報端末１５側では，ハッシュ値Ｈａｓｈ（Ｎb）を含むメッセージを受信すると，コンテンツ配信サーバ１３についての認証処理を行う
【０１２４】まず，
所定のハッシュ・アルゴリズムにより乱数発生部５２（当審注；「乱数発生部５３」の誤記である）で発生した乱数Ｎaのハッシュ値を計算する
計算されたハッシュ値が，コンテンツ配信サーバ１３から受信したハッシュ値Ｈａｓｈ（Ｎa）と等しいか否かを判別する
【０１２５】
これらハッシュ値が等しい場合，コンテンツ配信サーバ１３が正しくメッセージを復号化できたことを確認できるので，コンテンツ配信サーバ１３が本物の通信相手であることが判る
　
　上記引用のＡ，及び，Ｂ中の記載の下線を附した記載内容から，引用刊行物１には，次の発明（以下，これを「引用発明」という）が記載されているものと認める。
　
　携帯情報端末１５とコンテンツ配信サーバ１３間で行われる相互認証方法であって，
　前記携帯情報端末１５は，公開鍵暗号方式による公開鍵Ｅaとこれに非対称な秘密鍵を有し，
　前記コンテンツ配信サーバ１３は，公開鍵暗号方式による公開鍵Ｅbとこれに非対称な秘密鍵を有し，
　前記相互認証方法は，
　クライアントとしての前記携帯情報端末１５は，自分の公開鍵Ｅaを含んだ電子署名ＣｅｒｔｉｆｉｃａｔｉｏｎＡを，前記コンテンツ配信サーバ１３に送信するステップと，
　前記コンテンツ配信サーバ１３側では，前記電子署名ＣｅｒｔｉｆｉｃａｔｉｏｎＡを受信すると，電子署名検証部３２でこれを検証し，
　前記電子署名が正しいと判断された場合には，乱数発生部３３で相互認証に用いる乱数Ｎbを発生させ，これを前記携帯情報端末１５側の公開鍵Ｅaで暗号化して，これを電子署名生成部３４で生成した電子署名ＣｅｒｔｉｆｉｃａｔｉｏｎＢとともに前記携帯情報端末１５に送信するステップと，
　前記携帯情報端末１５は，前記電子署名ＣｅｒｔｉｆｉｃａｔｉｏｎＢと暗号データＥa（Ｎb）からなるメッセージを受信すると，前記電子署名検証部３２で前記電子署名ＣｅｒｔｉｆｉｃａｔｉｏｎＢの検証を行い，
　前記電子署名が正しいと判断された場合には，暗号化処理部５５において，暗号化データＥa（Ｎb）を復号化して，Ｎbを取り出して，そのハッシュ値Ｈａｓｈ（Ｎb）を作成し，
　乱数生成部５３で相互認証に用いる乱数Ｎaを発生させ，前記コンテンツ配信サーバ１３側の公開鍵Ｅbでこれを暗号化し，作成されたＥb（Ｎa）及びＨａｓｈ（Ｎb）を含むメッセージを，前記コンテンツ配信サーバ１３に送信するステップとを有し，
　前記コンテンツ配信サーバ１３は，前記Ｅb（Ｎa）及びＨａｓｈ（Ｎb）を含むメッセージを受信すると，前記携帯情報端末１５についての認証処理を行うために，
　所定のハッシュ・アルゴリズムにより前記乱数発生部３３で発生した乱数Ｎbのハッシュ値を計算するステップと，
　計算されたハッシュ値が，前記携帯情報端末１５から受信したハッシュ値Ｈａｓｈ（Ｎb）と等しいか否かを判別し，これらハッシュ値が等しい場合，前記携帯情報端末１５が本物の通信相手であることを認証するステップと，
　受信した暗号化データＥb（Ｎa）を暗号処理部３５で復号化して，前記携帯情報端末１５側の乱数Ｎaを取り出すステップと，
　所定のハッシュ・アルゴリズムにより，前記乱数Ｎaのハッシュ値Ｈａｓｈ（Ｎa）を計算するステップと，
　前記ハッシュ値Ｈａｓｈ（Ｎa）を前記携帯情報端末１５に送信するステップとを有し，
　前記携帯情報端末１５は，ハッシュ値Ｈａｓｈ（Ｎa）を含むメッセージを受信すると，前記コンテンツ配信サーバ１３についての認証処理を行うために，
　所定のハッシュ・アルゴリズムにより前記乱数発生部５３で発生した乱数Ｎaのハッシュ値を計算するステップと，
　計算されたハッシュ値が，前記コンテンツ配信サーバ１３から受信したハッシュ値Ｈａｓｈ（Ｎa）と等しいか否かを判別し，これらハッシュ値が等しい場合，前記コンテンツ配信サーバ１３が本物の通信相手であることを認証するステップとを有する，相互認証方法。
　
第４．本願発明と引用発明との対比
１．引用発明における「相互認証方法」は，「クライアントとしての前記携帯情報端末１５は，自分の公開鍵Ｅaを含んだ電子署名ＣｅｒｔｉｆｉｃａｔｉｏｎＡを，前記配信サーバ１３に送信するステップ」から開始されているので，引用発明における「携帯情報端末１５」が，本願発明における「第１のエンティティ」に相当し，引用発明における「コンテンツ配信サーバ１３」が，本願発明における「第２のエンティティ」に相当する。
　よって，引用発明における「携帯情報端末１５とコンテンツ配信サーバ１３間で行われる相互認証方法」が，
　本願発明における「ハードウェアの第１のエンティティとハードウェアの第２のエンティティとの間の相互認証のための方法」に相当する。
　
２．上記１．でも引用した引用発明における「クライアントとしての前記携帯情報端末１５は，自分の公開鍵Ｅaを含んだ電子署名ＣｅｒｔｉｆｉｃａｔｉｏｎＡを，前記コンテンツ配信サーバ１３に送信するステップ」は，「携帯情報端末」から，「コンテンツ配信サーバ」に，“メッセージ”を送信することに他ならないので，
　引用発明における「クライアントとしての前記携帯情報端末１５は，自分の公開鍵Ｅaを含んだ電子署名ＣｅｒｔｉｆｉｃａｔｉｏｎＡを，前記コンテンツ配信サーバ１３に送信するステップ」が，
　本願発明における「第１のエンティティが前記第２のエンティティにメッセージを送信することにより相互認証を開始すること」に相当する。
　
３．引用発明において，「コンテンツ配信サーバ１３側では，この電子署名ＣｅｒｔｉｆｉｃａｔｉｏｎＡを受信すると，電子署名検証部３２でこれを検証」することは，「電子署名ＣｅｒｔｉｆｉｃａｔｉｏｎＡ」が，「携帯情報端末１５」の「公開鍵Ｅaを含ん」でいるので，該「公開鍵Ｅa」を検証することに他ならないから，
　引用発明における「コンテンツ配信サーバ１３側では，この電子署名ＣｅｒｔｉｆｉｃａｔｉｏｎＡを受信すると，電子署名検証部３２でこれを検証」することは，
　本願発明における「第２のエンティティが前記第１のエンティティに関連した第１の公開鍵を検証」することに相当し，
　引用発明における「乱数Ｎb」，「携帯情報端末１５側の公開鍵Ｅa」が，
　本願発明における「第１の乱数」，「第１の公開鍵」に相当するので，
　引用発明における「乱数発生部３３で相互認証に用いる乱数Ｎbを発生させ，これを前記携帯情報端末１５側の公開鍵Ｅaで暗号化して，これを電子署名生成部３４で生成した電子署名ＣｅｒｔｉｆｉｃａｔｉｏｎＢとともに前記携帯情報端末１５に送信するステップ」が，
　本願発明における「第１の乱数を生成し，第１の暗号化において前記第１の公開鍵を使用して前記第１の乱数を暗号化し，前記暗号化された第１の乱数をメッセージ中で前記第１のエンティティに送信すること」に相当する。
　
４．引用発明において，「携帯情報端末１５は，前記電子署名ＣｅｒｔｉｆｉｃａｔｉｏｎＢと暗号データＥa（Ｎb）からなるメッセージを受信すると，前記電子署名検証部３２で前記電子署名ＣｅｒｔｉｆｉｃａｔｉｏｎＢの検証を行」うことは，「電子署名ＣｅｒｔｉｆｉｃａｔｉｏｎＢ」が，「コンテンツ配信サーバ１３」の「公開鍵Ｅb」を含むものであるから，該「公開鍵Ｅb」を検証することに他ならない。
　したがって，引用発明における「携帯情報端末１５は，前記電子署名ＣｅｒｔｉｆｉｃａｔｉｏｎＢと暗号データＥa（Ｎb）からなるメッセージを受信すると，前記電子署名検証部３２で前記電子署名ＣｅｒｔｉｆｉｃａｔｉｏｎＢの検証を行」うことが，
　本願発明における「第１のエンティティが前記第２のエンティティに関連した第２の公開鍵を検証」することに相当する。
　そして，引用発明において，「Ｎbを取り出し暗号化データＥa（Ｎb）を復号化」するためには，「携帯情報端末１５」が保持する，“公開鍵Ｅaに非対称な秘密鍵”が必要であることは明らかであって，該“公開鍵Ｅaに非対称な秘密鍵”が，
　本願発明における「第１の公開鍵に対応した第１の秘密鍵」に相当し，
　引用発明における「乱数Ｎa」は，「コンテンツ配信サーバ１３」が，「携帯情報端末１５」を認証するために，「携帯情報端末１５」において，「乱数生成部５３で」発生されるものであるから，
　本願発明における「第２の乱数」に相当し，
　引用発明における「ハッシュ値Ｈａｓｈ（Ｎb）」が，
　本願発明における「第１のハッシュ」に相当するので，
　引用発明における「暗号化処理部５５において，暗号化データＥa（Ｎb）を復号化して，Ｎbを取り出して，そのハッシュ値Ｈａｓｈ（Ｎb）を作成し，乱数生成部５３で相互認証に用いる乱数Ｎaを発生させ」ることが，
　本願発明における「第１の復号において前記第１の公開鍵に対応した第１の秘密鍵を使用して前記暗号化された第１の乱数を復号し，第２の乱数を生成し，少なくとも前記第１の乱数に基づいて第１のハッシュを生成」することに相当する。
　
５．引用発明においては，“発生させた乱数Ｎa”を，コンテンツ配信サーバ１３側の公開鍵Ｅbで暗号化し，作成されたＥb（Ｎa）及びＨａｓｈ（Ｎb）を含むメッセージを，前記コンテンツ配信サーバ１３に送信するステップとを有し”ていて，
　引用発明における「コンテンツ配信サーバ１３側の公開鍵Ｅb」が，
　本願発明における「第２の公開鍵」に相当するので，
　引用発明における「乱数Ｎaを発生させ，前記コンテンツ配信サーバ１３側の公開鍵Ｅbでこれを暗号化し，作成されたＥb（Ｎa）及びＨａｓｈ（Ｎb）を含むメッセージを，前記コンテンツ配信サーバ１３に送信するステップ」と，
　本願発明における「第２の暗号化において前記第２の公開鍵を使用して前記第２の乱数および前記第１のハッシュを暗号化し，前記暗号化された第２の乱数および第１のハッシュをメッセージ中で前記第２のエンティティに送信すること」とは，
“第２の暗号化において，第２の公開鍵を使用して，第２の乱数を暗号化し，暗号化された第２の乱数と，第１のハッシュをメッセージ中で，第２のエンティティに送信すること”である点で共通する。
　
６．引用発明において，「所定のハッシュ・アルゴリズムにより前記乱数発生部３３で発生した乱数Ｎbのハッシュ値を計算するステップ」と，「計算されたハッシュ値が，前記携帯情報端末１５から受信したハッシュ値Ｈａｓｈ（Ｎb）と等しいか否かを判別し，これらハッシュ値が等しい場合，前記携帯情報端末１５が本物の通信相手であることを認証するステップ」とは，引用発明において，「コンテンツ配信サーバ１３」が，「ハッシュ値Ｈａｓｈ（Ｎb）」を検証することにほかならないので，
　本願発明における「第１のエンティティを認証するために前記第１のハッシュを検証する」ことに相当し，
　引用発明において，「コンテンツ配信サーバ１３」で「受信した暗号化データＥb（Ｎa）」を復号するために，“公開鍵Ｅbに非対称な秘密鍵”が必要なことは明らかであり，前記“公開鍵Ｅbに非対称な秘密鍵”は，
　本願発明における「第２の公開鍵に対応する第２の秘密鍵」に相当するものであるから，
　引用発明における「受信した暗号化データＥb（Ｎa）を暗号処理部３５で復号化して，前記携帯情報端末１５側の乱数Ｎaを取り出すステップ」と，
　本願発明における「第２のエンティティが第２の復号において前記第２の公開鍵に対応する第２の秘密鍵を使用して前記暗号化された第２の乱数および第１のハッシュを復号」することとは，
“第２のエンティティが第２の復号において，第２の公開鍵に対応する第２の秘密鍵を使用して，暗号化された第２の乱数を復号する”ことである点で共通し，
　引用発明における「ハッシュ値Ｈａｓｈ（Ｎa）」は，「乱数Ｎa」（本願発明における「第２の乱数」に相当）のハッシュ値であるから，
　本願発明における「第２のハッシュ」に相当するので，
　引用発明における「所定のハッシュ・アルゴリズムにより，前記乱数Ｎaのハッシュ値Ｈａｓｈ（Ｎa）を計算するステップと，前記ハッシュ値Ｈａｓｈ（Ｎa）を前記携帯情報端末１５に送信するステップ」が，
　本願発明における「少なくとも前記第２の乱数に基づいて第２のハッシュを生成し，前記第２のハッシュを前記第１のエンティティに送信すること」に相当する。
　
７．引用発明における「前記携帯情報端末１５は，ハッシュ値Ｈａｓｈ（Ｎb）を含むメッセージを受信すると，前記コンテンツ配信サーバ１３についての認証処理を行うために，
　所定のハッシュ・アルゴリズムにより前記乱数発生部５３で発生した乱数Ｎaのハッシュ値を計算するステップと，
　計算されたハッシュ値が，前記コンテンツ配信サーバ１３から受信したハッシュ値Ｈａｓｈ（Ｎa）と等しいか否かを判別し，これらハッシュ値が等しい場合，前記コンテンツ配信サーバ１３が本物の通信相手であることを認証するステップ」は，
“携帯情報端末１５が，コンテンツ配信サーバ１３から受信したハッシュ値Ｈａｓｈ（Ｎa）を，コンテンツ配信サーバ１３を認証するために，検証する”ことに他ならないから，
　本願発明における「第１のエンティティが前記第２のエンティティを認証するために前記第２のハッシュを検証すること」に相当する。
　
８．上記１．〜８．において検討した事項から明らかなように，引用発明も，本願発明と同様に，「相互認証は，前記第１及び第２の暗号化を備える２つの暗号化以内に制限され，かつ，前記第１及び第２の復号を備える２つの復号以内に制限され」ている。
　
　以上１．〜７．において検討した事項から，本願発明と，引用発明との，一致点，及び，相違点は，次のとおりである。
　
［一致点］
　ハードウェアの第１のエンティティとハードウェアの第２のエンティティとの間の相互認証のための方法であって，
　前記第１のエンティティが前記第２のエンティティにメッセージを送信することにより相互認証を開始することと，
　前記第２のエンティティが前記第１のエンティティに関連した第１の公開鍵を検証し，第１の乱数を生成し，第１の暗号化において前記第１の公開鍵を使用して前記第１の乱数を暗号化し，前記暗号化された第１の乱数をメッセージ中で前記第１のエンティティに送信することと，
　前記第１のエンティティが前記第２のエンティティに関連した第２の公開鍵を検証し，第１の復号において前記第１の公開鍵に対応した第１の秘密鍵を使用して前記暗号化された第１の乱数を復号し，第２の乱数を生成し，少なくとも前記第１の乱数に基づいて第１のハッシュを生成し，第２の暗号化において前記第２の公開鍵を使用して，前記第２の乱数を暗号化し，前記暗号化された第２の乱数と，前記第１のハッシュをメッセージ中で前記第２のエンティティに送信することと，
　前記第２のエンティティが第２の復号において前記第２の公開鍵に対応する第２の秘密鍵を使用して前記暗号化された第２の乱数を復号し，前記第１のエンティティを認証するために前記第１のハッシュを検証し，少なくとも前記第２の乱数に基づいて第２のハッシュを生成し，前記第２のハッシュを前記第１のエンティティに送信することと，
　前記第１のエンティティが前記第２のエンティティを認証するために前記第２のハッシュを検証することと，を備え，
　相互認証は，前記第１及び第２の暗号化を備える２つの暗号化以内に制限され，かつ，前記第１及び第２の復号を備える２つの復号以内に制限される，相互認証方法。
　
［相違点１］
“第２の暗号化において前記第２の公開鍵を使用して，前記第２の乱数を暗号化し，前記暗号化された第２の乱数と，前記第１のハッシュをメッセージ中で前記第２のエンティティに送信すること”に関して，
　本願発明においては，「第２の暗号化において前記第２の公開鍵を使用して前記第２の乱数および前記第１のハッシュを暗号化し，前記暗号化された第２の乱数および第１のハッシュをメッセージ中で前記第２のエンティティに送信すること」であるのに対して，
　引用発明においては，「コンテンツ配信サーバ１３側の公開鍵Ｅb」で，「Ｈａｓｈ（Ｎb）」を暗号化していない点。
　
［相違点２］
“第２の復号において前記第２の公開鍵に対応する第２の秘密鍵を使用して前記暗号化された第２の乱数を復号する”ことに関して，
　本願発明においては，「第２の復号において前記第２の公開鍵に対応する第２の秘密鍵を使用して前記暗号化された第２の乱数および第１のハッシュを復号」しているのに対して，
　引用発明においては，「受信した暗号化データＥb（Ｎa）を暗号処理部３５で復号化して，前記携帯情報端末１５側の乱数Ｎaを取り出すステップ」において，「ハッシュ値Ｈａｓｈ（Ｎb）」の復号は行っていない点。
　
第５．相違点についての当審の判断
・［相違点１］，及び，［相違点２］について
　本願発明において，「第２のエンティティ」から，「第１のエンティティ」に送信された「第１の乱数」は，「第２のエンティティ」が，「第１のエンティティ」を認証するために用いる情報，即ち，“チャレンジ”であって，「第１のエンティティ」から，返送される「第２の公開鍵で暗号化された，第１の乱数のハッシュ値である，第１のハッシュ」は，前記“チャレンジ”に対する“レスポンス”である。
　このような，送受信の相手を認証するために行う，“チャレンジ・レスポンス”において，返送する“レスポンス”を，“チャレンジ”を送信してくる側の「公開鍵」で暗号化してから，返送するようなことは，例えば，原審拒絶理由に引用された，本願の原出願の第１国出願前に既に公知である，「Menezes, A. J. et al., HANDBOOK of APPLIED CRYPTOGRAPHY, CRC Press, 1997年, p.507-510」（以下，これを「引用刊行物２」という）に，
　
Ｃ．
Needham-Schroeder public-key protocol
The Needham-Schroeder public-key protocol provides mutual entity authentication and mutual key transport (A and B each transfer a symmetric key to the other). The transported keys may serve both as nonces for entity authentication and secret keys for further use. Combination of the resulting shared keys allows computation of a joint key to which both parties contribute.
　
12.38 Protocol Needham-Schroeder public-key protocol
　
SUMMARY: A and B exchange 3 messages.
RESULT: entity authentication, key authentication, and key transport (all mutual).
1. Notation. PＸ(Y) denotes public-key encryption (e.g., RSA) of data Y using party　X’s public key;  PＸ(Y１, Y２) denotes the encryption of the concatenation of Y１ and　Y２. k１, k２ are secret symmetric session keys chosen by A, B, respectively.
2. One-time setup. Assume A, B possess each other’s authentic public-key. (If this is　not the case, but each party has a certificate carrying its own public key, then one　additional message is required for certificate transport.)
3. Protocol messages.
A → B : PＢ(k１,A)   (1)
A ← B : PＡ(k１, k2) (2)
A → B : PＢ(k２)     (3)
4. Protocol actions.
(a) A sends B message (1).
(b) B recovers k1 upon receiving message (1), and returns to A message (2).
(c) Upon decrypting message (2), A checks the key k１ recovered agrees with that sent in message (1). (Provided k１ has never been previously used, this gives A both entity authentication of B and assurance that B knows this key.) A sends B message (3).
(d) Upon decrypting message (3), B checks the key k２ recovered agrees with that sent in message (2). The session key may be computed as f(k１, k２) using an appropriate publicly known non-reversible function f.」（５０８頁８行〜３６行）
（ニーダム・シュローダー公開鍵プロトコル
　ニーダム・シュローダー公開鍵プロトコルは，相互エンティティ認証，及び，（ＡとＢが，互いに，他方に，対称鍵を配送する）相互鍵配送を含む。配送された鍵は，エンティティ認証のノンス，及び，更に使用するための秘密鍵の両方として役立つ。結果として生じる共有された鍵の組み合わせは，両パーティが寄与する，結合鍵の計算を許可する。
　
１２．３８　プロトコル　ニーダム・シュローダー公開鍵プロトコル
要約：ＡとＢは，３つのメッセージを交換する。
結果：エンティティ認証，鍵認証，及び，鍵交換（全て相互）。
１．表記。ＰＸ（Ｙ）は，パーティＸの公開鍵を用いた，データＹの公開鍵暗号（例えば，ＲＳＡ）化を示す；ＰＸ（Ｙ１，Ｙ２）は，Ｙ１と，Ｙ２ の結合の暗号化を示す。ｋ１，ｋ２は，Ａと，Ｂが，個々に選択した，秘密対称セッション鍵である。
２．一時的な設定。Ａ，Ｂは，お互いの認証の公開鍵を所有している。（もし，この場合でなければ，しかしながら，それぞれのパーティは，自らの公開鍵を運ぶ証明書を持っているので，証明書の転送のために，更に一つのメッセージが必要になる。）
３．プロトコル・メッセージ。
　
Ａ　→　Ｂ　：　ＰＢ（ｋ１，Ａ）　　　（１）
Ａ　←　Ｂ　：　ＰＡ（ｋ１，ｋ２）  　 （２）
Ａ　→　Ｂ　：　ＰＢ（ｋ２）　　　　　（３）
　
４．プロトコル動作。
（ａ）Ａが，Ｂに，メッセージ（１）を送信する。
（ｂ）Ｂが，メッセージ（１）の受信において，ｋ１を復元し，そして，Ａにメッセージ（２）を返送する。
（ｃ）メッセージ（２）の復号において，Ａは，復元された鍵ｋ１が，メッセージ（１）に入れて送られたものものと一致するかを，確認する。（Ｋ１が，以前に，全く使用されていないのであれば，このことは，Ａに，Ｂのエンティティ認証と，Ｂが，この鍵を知っているという確信の，両方を与える。）Ａが，Ｂに，メッセージ（３）を送信する。
（ｄ）メッセージ（３）の復号において，Ｂは，復元された鍵ｋ２が，メッセージ（２）に入れられて送られたものと一致するかを，確認する。セッション鍵は，適当な公知の非可逆関数ｆを用いて，ｆ（ｋ１，ｋ２）として計算され得る。当審にて訳出）
　
　と記載されていて，この例では，Ａを認証するための情報は，ＡからＢへ送信した，“鍵ｋ１”であり，該“鍵ｋ１”は，Ｂから返送される時に，Ａの公開鍵で暗号化されて返送されて来るので，相手を認証するための情報が，自らの公開鍵で暗号化されて返送され，返送された公開鍵で暗号化された，認証のための情報を，自らの秘密鍵で復号することは，本願の原出願の第１国出願前に，当業者には周知の技術事項であった。
　更に，相手を認証するために，公開鍵で暗号化して送信した乱数を，被認証側において，該乱数のハッシュ値を計算し，該ハッシュ値を公開鍵で暗号化して，認証側に返送する点についても，例えば，本願の原出願の第１国出願前に既に公知である，特開２００２−２９７５４０号公報（２００２年１０月１１日公開，以下，これを「周知技術文献」という）に，
　
Ｄ．「【００３７】処理201では，まず，
ログ収集サーバ10において乱数を発生させる。ログ収集サーバ10は前記乱数を，上記テーブル（図２(A) ）に格納されたクライアントＡの公開鍵で暗号化する
【００３８】暗号化された乱数をチャレンジコードと呼ぶ。チャレンジコードとは，サーバが接続要求を送信してきたクライアントＡについて，アクセスを許されたクライアントであるか否かを確認するためのものである。
【００３９】
チャレンジコードを受信したクライアントＡでは，前記チャレンジコードを秘密鍵を用いて復号プログラムによって復号する
【００４０】処理104では
復号によって得られた文字列（ログ収集サーバ10で発生させた乱数）をハッシュ関数にかけて，ハッシュ・ダイジェスト(これをレスポンスコードと言う)を生成する。生成されたレスポンスコードを暗号化プログラムを用いてさらに公開鍵で暗号化する。暗号化されたレスポンスコード（暗号化レスポンスコード）がログ収集サーバ10に送信される
【００４１】処理202では，クライアントＡより送信された暗号化レスポンスコードを受信する。クライアントＡの秘密鍵（上述のテーブル（図２(A) に格納されている）で暗号化レスポンスコードが復号される。レスポンスコードが得られる。ログ収集サーバ10ではさらに上述のチャレンジコード（暗号化された乱数）をハッシュ関数にかけてハッシュダイジェストを生成する。生成されたハッシュダイジェストとレスポンスコードとが比較される。同じであれば，交信が認められたクライアントＡであると判断される。処理203に進む。そうでなければ不正アクセスとみなし，処理を中断する。」
　
　と記載されているように，本願の原出願の第１国出願前に，当業者には周知の技術事項である。
　以上検討した事項から，引用発明において，
　携帯情報端末１５から，コンテンツ配信サーバ１３に，Ｅb（Ｎa）及びＨａｓｈ（Ｎb）を含むメッセージを送信する際に，乱数Ｎaのみならず，Ｈａｓｈ（Ｎb）も，コンテンツ配信サーバ１３の公開鍵Ｅbで暗号化し，コンテンツ配信サーバ１３は，Ｅbで暗号化されたＨａｓｈ（Ｎb）受信すると，認証処理を行うために，前記Ｅbで暗号化されたＨａｓｈ（Ｎb）を，公開鍵Ｅbと非対称な秘密鍵を用いて復号するよう構成することは，当業者が適宜なし得る事項に過ぎない。
　したがって，相違点１，及び，相違点２は，格別のものではない。
　
　上記で検討したごとく，相違点１，及び，相違点２はいずれも格別のものではなく，そして，本願発明の構成によってもたらされる効果も，当業者であれば容易に予測できる程度のものであって，格別なものとは認められない。
　
第６．むすび
　したがって，本願発明は，本願の特許出願前に日本国内又は外国において頒布された刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基づいて当業者が容易に発明をすることができたものであるので，特許法第２９条第２項の規定により特許を受けることができない。
　
　よって，結論のとおり審決する。