• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 2項進歩性 特許、登録しない。 H04L
管理番号 1290517
審判番号 不服2012-16056  
総通号数 177 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2014-09-26 
種別 拒絶査定不服の審決 
審判請求日 2012-08-17 
確定日 2014-08-06 
事件の表示 特願2009-532508「相互認証のための方法および装置」拒絶査定不服審判事件〔平成20年 4月17日国際公開、WO2008/045773、平成22年 2月25日国内公表、特表2010-506542〕について、次のとおり審決する。 
結論 本件審判の請求は、成り立たない。 
理由 1.手続の経緯

本件審判請求に係る出願(以下、「本願」という。)は、2007年10月5日(パリ条約による優先権主張外国庁受理2006年10月10日及び2007年10月3日、いずれも米国)を国際出願日とする出願であって、平成21年4月10日に特許法第184条の5第1項に規定される書面が提出されるとともに、同年6月10日付けで特許法第184条の4第1項の規定による国際出願日における明細書、請求の範囲、図面(図面の中の説明に限る。)及び要約の翻訳文が提出され、同日付けで審査請求がなされ、平成23年11月22日付けで拒絶理由通知(同年11月29日発送)がなされ、平成24年3月23日付けで意見書が提出されるとともに、同日付けで手続補正がなされたが、同年4月12日付けで拒絶査定(同年4月17日謄本送達)がなされたものである。
そして、これに対して、「原査定を取り消す。本願は特許をすべきものである、との審決を求める。」ことを請求の趣旨として、平成24年8月17日付けで本件審判請求がなされたものである。

2.本願発明

本願の特許請求の範囲の請求項1に係る発明(以下、「本願発明」という。)は、上記平成24年3月23日付け手続補正書により補正された明細書及び図面の記載からみて、その特許請求の範囲の請求項1に記載された以下のとおりのものと認める。

「第1のハードウェアエンティティと第2のハードウェアエンティティとの間の相互認証のための方法であって、
前記第1のハードウェアエンティティが前記第2のハードウェアエンティティにメッセージを送信することにより相互認証を開始することと;
前記第2のハードウェアエンティティが前記第1のハードウェアエンティティに関連した第1の公開鍵を検証し、第1の乱数を生成し、前記第1の公開鍵を使用して前記第1の乱数を暗号化し、前記暗号化された第1の乱数をメッセージ中で前記第1のハードウェアエンティティに送信することと;
前記第1のハードウェアエンティティが前記第2のハードウェアエンティティに関連した第2の公開鍵を検証し、前記第1の公開鍵に対応した第1の秘密鍵を使用して前記暗号化された第1の乱数を復号し、第2の乱数を生成し、少なくとも前記第1の乱数に基づいて第1のハッシュを生成し、前記第2の公開鍵を使用して前記第2の乱数および前記第1のハッシュを暗号化し、前記暗号化された第2の乱数および第1のハッシュをメッセージ中で前記第2のハードウェアエンティティに送信することと;
前記第2のハードウェアエンティティが前記第2の公開鍵に対応する第2の秘密鍵を使用して前記暗号化された第2の乱数および第1のハッシュを復号し、前記第1のハードウェアエンティティを認証するために前記第1のハッシュを検証し、少なくとも前記第2の乱数に基づいて第2のハッシュ生成し、前記第2のハッシュを前記第1のハードウェアエンティティに送信することと;
前記第1のハードウェアエンティティが前記第2のハードウェアエンティティを認証するために前記第2のハッシュを検証することと;
を備える相互認証方法。」

3.引用文献に記載されている技術的事項及び引用発明の認定

(1)引用文献1

原審の拒絶査定の理由である上記平成23年11月22日付け拒絶理由通知書において引用され、本願の優先日前に頒布された刊行物である、特開2003-124927号公報(平成15年4月25日出願公開、以下、「引用文献1」という。)には、関連する図面とともに、以下の技術的事項が記載されている。
(当審注:下線は、参考のために当審で付与したものである。)

A 「【請求項9】第1の装置と第2の装置の間で所定の公開鍵暗号方式を用いて相互認証を行う相互認証方法であって、
第1の装置が自分の公開鍵E_(a)を含んだ電子署名C_(a)を第2の装置に送信するステップと、
第2の装置が、第1の装置の電子署名C_(a)を確認した後、相互認証用の乱数N_(b)及びセッション・キーの種S_(b)を生成するとともにS_(b)のハッシュ値Hash(S_(b))を計算して、N_(b)、S_(b)、Hash(S_(b))を第1の装置の公開鍵E_(a)で暗号化したデータE_(a)(N_(b),S_(b),Hash(S_(b)))を、自分の公開鍵E_(b)を含んだ電子署名C_(b)とともに第1の装置に送信するステップと、
第1の装置が、第2の装置の電子署名C_(b)を確認した後、自分の秘密鍵で受信データE_(a)(N_(b),S_(b),Hash(S_(b)))を復号化して、セッション・キーの種S_(b)のハッシュ値Hash'(S_(b))を計算して、受信したハッシュ値Hash(S_(b))と一致するか否かによって、公開鍵における復号化に失敗したか否かを判別するステップと、
復号化に失敗していないことに応答して、第1の装置が、相互認証用の乱数N_(a)及びセッション・キーの種S_(a)を生成するとともにS_(a)のハッシュ値Hash(S_(a))を計算して、N_(a)、S_(a)、Hash(S_(a))を第2の装置の公開鍵E_(b)で暗号化したデータE_(b)(N_(a),S_(a),Hash(S_(a)))を、受信データから取り出した乱数N_(b)とともに第2の装置に送信するステップと、
第2の装置が、受信した乱数N_(b)が自分で生成した乱数と等しいか否かで第1の装置を本人確認するステップと、
本人確認に成功したことに応答して、第2の装置が、自分の秘密鍵で受信データE_(b)(N_(a),S_(a),Hash(S_(a)))を復号化して、セッション・キーの種S_(a)のハッシュ値Hash'(S_(a))を計算して、受信したハッシュ値Hash(S_(a))と一致するか否かによって、公開鍵における復号化に失敗したか否かを判別するステップと、
復号化に失敗していないことに応答して、第2の装置が、相互認証用の乱数N_(a)を第1の装置に送信するステップと、
第1の装置が、受信した乱数N_(a)が自分で生成した乱数と等しいか否かで第2の装置を本人確認するステップと、を具備することを特徴とする相互認証方法。」

B 「【0112】図8には、携帯情報端末15とコンテンツ配信サーバ13間で行われる相互認証の処理手順に関する他の例を示している。但し、携帯情報端末15は、NTRU公開鍵暗号方式による公開鍵E_(a)とこれに非対称な秘密鍵を持ち、同様に、コンテンツ配信サーバ13は、NTRU公開鍵暗号方式による公開鍵E_(b)とこれに非対称な秘密鍵を持つものとする。」

C 「【0113】まず、クライアントとしての携帯情報端末15は、自分の公開鍵E_(a)を含んだ電子署名CertificationAを送信する(P11)。」

D 「【0114】コンテンツ配信サーバ13側では、この電子署名CertificationAを受信すると、電子署名検証部32でこれを検証する。
【0115】電子署名が正しいと判断された場合には、乱数発生部33で相互認証に用いる乱数N_(b)を発生させ、これを携帯情報端末15側の公開鍵E_(a)で暗号化して、これを電子署名生成部34で生成した電子署名CertificationBとともに携帯情報端末15に送信する(P12)。」

E 「【0116】携帯情報端末15側では、電子署名CertificationBと暗号データE_(a)(N_(b))からなるメッセージを受信すると、電子署名検証部32で電子署名CertificationBの検証を行う。電子署名が正しいと判断された場合には、暗号化処理部55において、暗号化データE_(a)(N_(b))を復号化して、N_(b)を取り出して、そのハッシュ値Hash(N_(b))を作成する。さらに、乱数生成部53で相互認証に用いる乱数N_(a)を発生させ、コンテンツ配信サーバ13側の公開鍵E_(b)でこれを暗号化する。そして、このようにして作成されたE_(b)(N_(a))及びHash(N_(b))を含むメッセージを、コンテンツ配信サーバ13に送信する(P13)。」

F 「【0117】コンテンツ配信サーバ13側では、E_(b)(N_(a))及びHash(N_(b))を含むメッセージを受信すると、携帯情報端末15についての認証処理を行う。図9には、コンテンツ配信サーバ13側で行う携帯情報端末15についての認証手続をフローチャートの形式で示している。以下、このフローチャートに従って、携帯情報端末15についての認証手続について説明する。
【0118】まず、所定のハッシュ・アルゴリズムにより乱数発生部32で発生した乱数N_(b)のハッシュ値を計算する(ステップS31)。そして、計算されたハッシュ値が、携帯情報端末15から受信したハッシュ値Hash(N_(b))と等しいか否かを判別する(ステップS32)。
【0119】これらハッシュ値が等しい場合、携帯情報端末15が正しくメッセージを復号化できたことを確認できるので、携帯情報端末15が本物の通信相手であることが判る。
【0120】次いで、受信した暗号化データE_(b)(N_(a))を暗号処理部35で復号化して、携帯情報端末15側の乱数N_(a)を取り出す(ステップS33)。
【0121】そして、所定のハッシュ・アルゴリズムによりこの乱数N_(a)のハッシュ値Hash(N_(a))を計算して(ステップS34)、これを携帯情報端末15に送信する(ステップS35)(P14)。」

G 「【0123】携帯情報端末15側では、ハッシュ値Hash(N_(b))を含むメッセージを受信すると、コンテンツ配信サーバ13についての認証処理を行う。図10には、携帯情報端末15側で行うコンテンツ配信サーバ13についての認証手続をフローチャートの形式で示している。以下、このフローチャートに従って、コンテンツ配信サーバ13についての認証手続について説明する。
【0124】まず、所定のハッシュ・アルゴリズムにより乱数発生部52で発生した乱数N_(a)のハッシュ値を計算する(ステップS41)。そして、計算されたハッシュ値が、コンテンツ配信サーバ13から受信したハッシュ値Hash(N_(a))と等しいか否かを判別する(ステップS42)。」

ここで、上記引用文献1に記載されている事項を検討する。

(ア)上記Bの「携帯情報端末15とコンテンツ配信サーバ13間で行われる相互認証の処理手順」との記載からすると、引用文献1には、
“携帯情報端末とコンテンツ配信サーバ間で行われる相互認証の処理手順”
が記載されている。

(イ)上記Cの「携帯情報端末15は、自分の公開鍵E_(a)を含んだ電子署名CertificationAを送信する」との記載からすると、引用文献1には、
“携帯情報端末が、自分の公開鍵E_(a)を含んだ電子署名CertificationAを送信する”態様
が記載されている。

(ウ)上記Dの「コンテンツ配信サーバ13側では、この電子署名CertificationAを受信すると・・・これを検証する・・・電子署名が正しいと判断された場合には、・・・相互認証に用いる乱数N_(b)を発生させ、これを携帯情報端末15側の公開鍵E_(a)で暗号化して、これを・・・電子署名CertificationBとともに携帯情報端末15に送信する」との記載からすると、引用文献1には、
“コンテンツ配信サーバが、電子署名CertificationAを受信するとこれを検証し、電子署名が正しいと判断された場合には、相互認証に用いる乱数N_(b)を発生させ、前記乱数N_(b)を携帯情報端末の公開鍵E_(a)で暗号化して(暗号化データE_(a)(N_(b))を作成し)、これを電子署名CertificationBとともに前記携帯情報端末に送信する”態様
が記載されている。

(エ)上記Eの「携帯情報端末15側では、電子署名CertificationBと暗号データE_(a)(N_(b))からなるメッセージを受信すると・・・検証を行う。電子署名が正しいと判断された場合には・・・暗号化データE_(a)(N_(b))を復号化して、N_(b)を取り出して、そのハッシュ値Hash(N_(b))を作成する。さらに・・・相互認証に用いる乱数N_(a)を発生させ、コンテンツ配信サーバ13側の公開鍵E_(b)でこれを暗号化する。そして、このようにして作成されたE_(b)(N_(a))及びHash(N_(b))を含むメッセージを、コンテンツ配信サーバ13に送信する」との記載からすると、引用文献1には、
“携帯情報端末が、電子署名CertificationBと暗号データE_(a)(N_(b))からなるメッセージを受信すると検証を行い、電子署名が正しいと判断された場合には、前記暗号化データE_(a)(N_(b))を復号化して、乱数N_(b)を取り出して、そのハッシュ値Hash(N_(b))を作成し、さらに相互認証に用いる乱数N_(a)を発生させ、コンテンツ配信サーバの公開鍵E_(b)で前記乱数N_(a)を暗号化して(暗号化データE_(b)(N_(a))を作成し)、そして、このようにして作成された暗号化データE_(b)(N_(a))及びハッシュ値Hash(N_(b))を含むメッセージを、コンテンツ配信サーバに送信する”態様
が記載されている。

(オ)上記Fの「コンテンツ配信サーバ13側では・・・携帯情報端末15についての認証処理を行う・・・まず・・・乱数N_(b)のハッシュ値を計算する・・・そして、計算されたハッシュ値が、携帯情報端末15から受信したハッシュ値Hash(N_(b))と等しいか否かを判別する・・・これらハッシュ値が等しい場合、携帯情報端末15が正しくメッセージを復号化できたことを確認できるので、携帯情報端末15が本物の通信相手であることが判る・・・次いで、受信した暗号化データE_(b)(N_(a))を・・・復号化して、携帯情報端末15側の乱数N_(a)を取り出す・・・そして、所定のハッシュ・アルゴリズムによりこの乱数N_(a)のハッシュ値Hash(N_(a))を計算して・・・これを携帯情報端末15に送信する」との記載からすると、引用文献1には、
“コンテンツ配信サーバが、乱数N_(b)のハッシュ値を計算し、当該計算されたハッシュ値が、携帯情報端末から受信した前記ハッシュ値Hash(N_(b))と等しいか否かを確認することで前記携帯情報端末の認証を行い、次いで、受信した前記暗号化データE_(b)(N_(a))を復号化して、前記情報携帯端末の乱数N_(a)を取り出し、所定のハッシュ・アルゴリズムによりこの乱数N_(a)のハッシュ値Hash(N_(a))を計算し、当該ハッシュ値Hash(N_(a))を前記携帯情報端末に送信する”態様
が記載されている。

(カ)上記Gの「携帯情報端末15側では・・・コンテンツ配信サーバ13についての認証処理を行う・・・まず・・・乱数N_(a)のハッシュ値を計算する・・・そして、計算されたハッシュ値が、コンテンツ配信サーバ13から受信したハッシュ値Hash(N_(a))と等しいか否かを判別する」との記載からすると、引用文献1には、
“携帯情報端末が、乱数N_(a)のハッシュ値を計算し、当該計算されたハッシュ値が、コンテンツ配信サーバから受信したハッシュ値Hash(N_(a))と等しいか否かを確認することでコンテンツ配信サーバの認証を行う”態様
が記載されている。

以上、(ア)ないし(カ)で指摘した事項から、引用文献1には、次の発明(以下、「引用発明」という。)が記載されているものと認める。

「携帯情報端末とコンテンツ配信サーバ間で行われる相互認証の処理手順において、
前記携帯情報端末が、自分の公開鍵E_(a)を含んだ電子署名CertificationAを送信することと;
前記コンテンツ配信サーバが、前記電子署名CertificationAを受信するとこれを検証し、電子署名が正しいと判断された場合には、相互認証に用いる乱数N_(b)を発生させ、前記乱数N_(b)を前記携帯情報端末の公開鍵E_(a)で暗号化して(暗号化データE_(a)(N_(b))を作成し)、これを電子署名CertificationBとともに前記携帯情報端末に送信することと;
前記携帯情報端末が、前記電子署名CertificationBと前記暗号データE_(a)(N_(b))からなるメッセージを受信すると検証を行い、電子署名が正しいと判断された場合には、前記暗号化データE_(a)(N_(b))を復号化して、乱数N_(b)を取り出して、そのハッシュ値Hash(N_(b))を作成し、さらに相互認証に用いる乱数N_(a)を発生させ、コンテンツ配信サーバの公開鍵E_(b)で前記乱数N_(a)を暗号化して(暗号化データE_(b)(N_(a))を作成し)、そして、このようにして作成された暗号化データE_(b)(N_(a))及びハッシュ値Hash(N_(b))を含むメッセージを、前記コンテンツ配信サーバに送信することと;
前記コンテンツ配信サーバが、前記乱数N_(b)のハッシュ値を計算し、当該計算されたハッシュ値が、前記携帯情報端末から受信した前記ハッシュ値Hash(N_(b))と等しいか否かを確認することで前記携帯情報端末の認証を行い、次いで、受信した前記暗号化データE_(b)(N_(a))を復号化して、前記情報携帯端末の前記乱数N_(a)を取り出し、所定のハッシュ・アルゴリズムによりこの乱数N_(a)のハッシュ値Hash(N_(a))を計算し、当該ハッシュ値Hash(N_(a))を前記携帯情報端末に送信することと;
前記携帯情報端末が、前記乱数N_(a)のハッシュ値を計算し、当該計算されたハッシュ値が、前記コンテンツ配信サーバから受信した前記ハッシュ値Hash(N_(a))と等しいか否かを確認することで前記コンテンツ配信サーバの認証を行うことと;
を備える相互認証処理手順。」

(2)引用文献2

原審の拒絶査定の理由である上記平成23年11月22日付け拒絶理由通知書において引用され、本願の優先日前に頒布された刊行物である、「Menezes, A. J. et al., HANDBOOK of APPLIED CRYPTOGRAPHY, CRC Press, 1997年, p.507-510」(以下、「引用文献2」という。)には、関連する図面とともに、以下の技術的事項が記載されている。
(当審注:下線は、参考のために当審で付与したものである。)

H 「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.」(508頁8?13行)
(当審訳:Needham-Schroeder公開鍵プロトコル
Needham-Schroeder公開鍵プロトコルは、相互エンティティ認証や相互鍵転送(AとB、それぞれが相互に対称鍵を転送)を提供する。鍵転送は、エンティティ認証、さらなる使用のための秘密鍵のため両方のナンスとして機能することができる。結果の共有鍵の組み合わせは、双方が寄与している結合鍵の計算を可能にする。)

J 「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_(X)(Y) denotes public-key encryption (e.g., RSA) of data Y using party X's public key; P_(X)(Y_(1),Y_(2)) denotes the encryption of the concatenation of Y_(1) and Y_(2). k_(1), k_(2) 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_(B)(k_(1),A) (1)
A ← B: P_(A)(k_(1),k_(2)) (2)
A → B: P_(B)(k_(2)) (3)
4. Protocol actions.
(a) A sends B message (1).
(b) B recovers k_(1) upon receiving message (1), and returns to A message (2).
(c) Upon decrypting message (2), A checks the key k_(1 )recovered agrees with that sent in message (1). (中略) A sends B message (3).
(d) Upon decrypting message (3), B checks the key k_(2) recovered agrees with that sent in message (2). The session key may be computed as f(k_(1),k_(2)) using an appropriate publicly known non-reversible function f.」(508頁14?36行)
(当審訳:12.38 プロトコル Needham-Schroeder公開鍵プロトコル
概要:AとBが3つのメッセージを交換する
結果:エンティティ認証、鍵認証、(相互)鍵転送
1.標記 P_(X)(Y)は、Xの公開鍵を用いたデータYの公開鍵暗号(例えば、RSA)を意味する。;P_(X)(Y_(1),Y_(2))は、データY_(1)とデータY_(2)を連結したものをXの公開鍵で暗号化したものを意味する。k_(1)及びk_(2)は、それぞれA及びBによって選択された秘密対称セッション鍵である。
2.一度だけのセットアップ A、Bは、互いの真正の公開鍵を所有すると仮定する。(もしそうでないとしても、各当事者が自身の公開鍵を運ぶ証明書を持っている場合は、一つの追加のメッセージが、証明書転送のために必要となる。)
3.プロトコルメッセージ
A → B: PB(k_(1),A) (1)
A ← B: PA(k_(1),k_(2)) (2)
A → B: PB(k_(2)) (3)
4.プロトコルの動作
(a)AがBにメッセージ(1)を送信する。
(b)Bは、メッセージ(1)を受信すると、k_(1)を復号し、Aにメッセージ(2)を返す。
(c)メッセージ(2)を復号する際に、Aは、復号した鍵k_(1)が、メッセージ(1)で送信されたものと一致するか確認する。(中略)AがBにメッセージ(3)を送信する。
(d)メッセージ(3)を復号する際に、Bは、復号した鍵k_(2)が、メッセージ(2)で送信されたものと一致するか確認する。セッション鍵は、適当な公知の非可逆関数fを用いて、f(k_(1),k_(2))として計算することができる。)

そして、上記H及びJの記載からすると、引用文献2には、
“A及びBが行う相互認証であって、AとBは、互いの認証された公開鍵を所有しているか、あるいは、自身の公開鍵の証明書を所有しており、その証明書をメッセージにより転送し(2. One-time setup)、
Aは、エンティティ認証におけるナンスでもある対称鍵k_(1)(The transported keys may serve both as nonces for entity authentication)をBの公開鍵P_(B)で暗号化したものを、メッセージとしてBに送信し(4.(_(a)))、
Bは、メッセージを受信すると、k_(1)を復号し、そのk_(1)とエンティティ認証におけるナンスでもある対称鍵k_(2)とを暗号化したものを、メッセージとしてAに送信し(4.(b))、
Aは、受信したメッセージを復号し、復号したk_(1)が送信したものと一致するか確認することでBのエンティティ認証を行い、k_(2)をBの公開鍵で暗号化したものをメッセージとしてBに送信し(4.(c))、
Bは、受信したメッセージを復号し、復号したk_(2)が送信したものと一致するか確認することでAのエンティティ認証を行い、セッション鍵は、公知の非可逆関数fを用いて、f(k_(1), k_(2))として計算される(4.(d))”技術
が記載されているものと解される。

4.本願発明と引用発明との対比

本願発明と引用発明とを対比する。

(1)引用発明の「携帯情報端末」、「コンテンツ配信サーバ」、及び「相互認証(のための)方法」は、それぞれ、本願発明の「第1のハードウェアエンティティ」、「第2のハードウェアエンティティ」、及び「相互認証(の)処理手順」に相当する。
してみると、引用発明の「携帯情報端末とコンテンツ配信サーバ間で行われる相互認証の処理手順」は、本願発明の「第1のハードウェアエンティティと第2のハードウェアエンティティとの間の相互認証のための方法」に相当する。

(2)引用発明の「自分の公開鍵E_(a)を含んだ電子署名CertificationA」は、メッセージと呼べるものであり、当該メッセージを送信することにより、引用発明の「相互認証の処理手順」が開始される。
そして、本願発明の「メッセージ」を受け取った第2のハードウェアエンティティが、「第1のハードウェアエンティティに関連した第1の公開鍵を検証」することから、第1のハードウェアエンティティが最初に送信するメッセージに「第1の公開鍵」が含まれていることは、当業者にとって自明の事項である。
してみると、引用発明の「前記携帯情報端末が、自分の公開鍵E_(a)を含んだ電子署名CertificationAを送信すること」は、本願発明の「前記第1のハードウェアエンティティが前記第2のハードウェアエンティティにメッセージを送信することにより相互認証を開始すること」に相当するといえる。

(3)引用発明の「乱数N_(b)」、「携帯情報端末の公開鍵E_(a)」、及び「暗号化データE_(a)(N_(b))」は、それぞれ、本願発明の「第1の乱数」、「第1の公開鍵」、及び「暗号化された第1の乱数」に相当する。
そして、引用発明の「コンテンツ配信サーバが、前記電子署名CertificationAを受信するとこれを検証」において、電子署名CertificationAに含まれる「携帯情報端末の公開鍵E_(a)」についても検証を行うことは、当業者にとって自明の事項である。
してみると、引用発明の「前記コンテンツ配信サーバが、前記電子署名CertificationAを受信するとこれを検証し、電子署名が正しいと判断された場合には、相互認証に用いる乱数N_(b)を発生させ、前記乱数N_(b)を前記携帯情報端末の公開鍵E_(a)で暗号化して(暗号化データE_(a)(N_(b))を作成し)、これを電子署名CertificationBとともに前記携帯情報端末に送信すること」は、本願発明の「前記第2のハードウェアエンティティが前記第1のハードウェアエンティティに関連した第1の公開鍵を検証し、第1の乱数を生成し、前記第1の公開鍵を使用して前記第1の乱数を暗号化し、前記暗号化された第1の乱数をメッセージ中で前記第1のハードウェアエンティティに送信すること」に相当するといえる。

(4)引用発明の「乱数N_(a)」、「コンテンツ配信サーバの公開鍵E_(b)」、「ハッシュ値Hash(N_(b))」、及び「暗号化データE_(b)(N_(a))」は、それぞれ、本願発明の「第2の乱数」、「第2の公開鍵」、「第1のハッシュ」、及び「暗号化された第2の乱数」に相当する。
そして、上記(3)と同様に、引用発明の携帯情報端末が、「前記電子署名CertificationBと前記暗号データE_(a)(N_(b))からなるメッセージを受信すると検証を行」う際に、電子署名CertificationBに含まれる「コンテンツ配信サーバの公開鍵E_(b)」についても検証を行うことは、当業者にとって自明の事項である。また、引用発明の「暗号化データE_(a)(N_(b))を復号化」において、公開鍵で暗号化されたものを復号化する際に、当該公開鍵に対応した秘密鍵を使用することについても、当業者にとって自明の事項である。
してみると、引用発明の「前記携帯情報端末が、前記電子署名CertificationBと前記暗号データE_(a)(N_(b))からなるメッセージを受信すると検証を行い、電子署名が正しいと判断された場合には、前記暗号化データE_(a)(N_(b))を復号化して、乱数N_(b)を取り出して、そのハッシュ値Hash(N_(b))を作成し、さらに相互認証に用いる乱数N_(a)を発生させ、コンテンツ配信サーバの公開鍵E_(b)で前記乱数N_(a)を暗号化して(暗号化データE_(b)(N_(a))を作成し)、そして、このようにして作成された暗号化データE_(b)(N_(a))及びハッシュ値Hash(N_(b))を含むメッセージを、前記コンテンツ配信サーバに送信すること」と、本願発明の「前記第1のハードウェアエンティティが前記第2のハードウェアエンティティに関連した第2の公開鍵を検証し、前記第1の公開鍵に対応した第1の秘密鍵を使用して前記暗号化された第1の乱数を復号し、第2の乱数を生成し、少なくとも前記第1の乱数に基づいて第1のハッシュを生成し、前記第2の公開鍵を使用して前記第2の乱数および前記第1のハッシュを暗号化し、前記暗号化された第2の乱数および第1のハッシュをメッセージ中で前記第2のハードウェアエンティティに送信すること」とは、“前記第1のハードウェアエンティティが前記第2のハードウェアエンティティに関連した第2の公開鍵を検証し、前記第1の公開鍵に対応した第1の秘密鍵を使用して前記暗号化された第1の乱数を復号し、第2の乱数を生成し、少なくとも前記第1の乱数に基づいて第1のハッシュを生成し、前記第2の公開鍵を使用して前記第2の乱数を暗号化し、前記暗号化された第2の乱数および第1のハッシュをメッセージ中で前記第2のハードウェアエンティティに送信すること”である点で共通するといえる。

(5)引用発明の「ハッシュ値Hash(N_(a))」は、本願発明の「第2のハッシュ」に相当する。
そして、上記(4)と同様に、引用発明の「暗号化データE_(b)(N_(a))を復号化」において、公開鍵で暗号化されたものを復号化する際に、当該公開鍵に対応した秘密鍵を使用することについても、当業者にとって自明の事項である。
してみると、引用発明の「前記コンテンツ配信サーバが、前記乱数N_(b)のハッシュ値を計算し、当該計算されたハッシュ値が、前記携帯情報端末から受信した前記ハッシュ値Hash(N_(b))と等しいか否かを確認することで前記携帯情報端末の認証を行い、次いで、受信した前記暗号化データE_(b)(N_(a))を復号化して、前記情報携帯端末の前記乱数Naを取り出し、所定のハッシュ・アルゴリズムによりこの乱数N_(a)のハッシュ値Hash(N_(a))を計算し、当該ハッシュ値Hash(N_(a))を前記携帯情報端末に送信すること」と、本願発明の「前記第2のハードウェアエンティティが前記第2の公開鍵に対応する第2の秘密鍵を使用して前記暗号化された第2の乱数および第1のハッシュを復号し、前記第1のハードウェアエンティティを認証するために前記第1のハッシュを検証し、少なくとも前記第2の乱数に基づいて第2のハッシュ生成し、前記第2のハッシュを前記第1のハードウェアエンティティに送信すること」とは、“前記第2のハードウェアエンティティが前記第2の公開鍵に対応する第2の秘密鍵を使用して前記暗号化された第2の乱数を復号し、前記第1のハードウェアエンティティを認証するために前記第1のハッシュを検証し、少なくとも前記第2の乱数に基づいて第2のハッシュ生成し、前記第2のハッシュを前記第1のハードウェアエンティティに送信すること”である点で共通するといえる。

(6)そして、引用発明の「前記携帯情報端末が、前記乱数N_(a)のハッシュ値を計算し、当該計算されたハッシュ値が、前記コンテンツ配信サーバから受信した前記ハッシュ値Hash(N_(a))と等しいか否かを確認することで前記コンテンツ配信サーバの認証を行うこと」は、本願発明の「前記第1のハードウェアエンティティが前記第2のハードウェアエンティティを認証するために前記第2のハッシュを検証すること」に相当するといえる。

以上から、本願発明と引用発明とは、以下の点で一致し、また、以下の点で相違する。

(一致点)

第1のハードウェアエンティティと第2のハードウェアエンティティとの間の相互認証のための方法であって、
前記第1のハードウェアエンティティが前記第2のハードウェアエンティティにメッセージを送信することにより相互認証を開始することと;
前記第2のハードウェアエンティティが前記第1のハードウェアエンティティに関連した第1の公開鍵を検証し、第1の乱数を生成し、前記第1の公開鍵を使用して前記第1の乱数を暗号化し、前記暗号化された第1の乱数をメッセージ中で前記第1のハードウェアエンティティに送信することと;
前記第1のハードウェアエンティティが前記第2のハードウェアエンティティに関連した第2の公開鍵を検証し、前記第1の公開鍵に対応した第1の秘密鍵を使用して前記暗号化された第1の乱数を復号し、第2の乱数を生成し、少なくとも前記第1の乱数に基づいて第1のハッシュを生成し、前記第2の公開鍵を使用して前記第2の乱数を暗号化し、前記暗号化された第2の乱数および第1のハッシュをメッセージ中で前記第2のハードウェアエンティティに送信することと;
前記第2のハードウェアエンティティが前記第2の公開鍵に対応する第2の秘密鍵を使用して前記暗号化された第2の乱数を復号し、前記第1のハードウェアエンティティを認証するために前記第1のハッシュを検証し、少なくとも前記第2の乱数に基づいて第2のハッシュ生成し、前記第2のハッシュを前記第1のハードウェアエンティティに送信することと;
前記第1のハードウェアエンティティが前記第2のハードウェアエンティティを認証するために前記第2のハッシュを検証することと;
を備える相互認証方法。

(相違点)

本願発明が、「前記第1のハードウェアエンティティが」「前記第2の公開鍵を使用して前記第2の乱数および前記第1のハッシュを暗号化し、前記暗号化された第2の乱数および第1のハッシュをメッセージ中で前記第2のハードウェアエンティティに送信」し、「前記第2のハードウェアエンティティが前記第2の公開鍵に対応する第2の秘密鍵を使用して前記暗号化された第2の乱数および第1のハッシュを復号」するものであるのに対して、引用発明は、携帯情報端末が、コンテンツ配信サーバの公開鍵E_(b)を使用して乱数N_(a)を暗号化し、暗号化された暗号化データE_(b)(N_(a))及びハッシュ値Hash(N_(b))を含むメッセージを、コンテンツ配信サーバに送信し、コンテンツ配信サーバが、(コンテンツ配信サーバの公開鍵E_(b)に対応する秘密鍵を使用して)前記暗号化データE_(b)(N_(a))を復号化するものである点で相違する。
(すなわち、本願発明が、第2の公開鍵を使用して「第2の乱数および第1のハッシュ」を暗号化し、第2の公開鍵に対応する秘密鍵を使用して暗号化された「第2の乱数および第1のハッシュ」を復号するものであるのに対して、引用発明は、コンテンツ配信サーバの公開鍵E_(b)を使用して「乱数N_(a)」を暗号化し、(当該公開鍵E_(b)に対応した秘密鍵を使用して)暗号化された「乱数N_(a)」を復号化するものであるが、「ハッシュ値Hash(N_(b))」については、暗号化及び復号化するものではない点で相違する。)

5.当審の判断

上記相違点について検討する。

上記引用文献2(特に、上記H及びJ)の記載からすると、引用文献2には、下記の技術(以下、「周知技術」という。)が記載されている。

「A及びBが行う相互認証であって、AとBは、互いの認証された公開鍵を所有しているか、あるいは、自身の公開鍵の証明書を所有しており、その証明書をメッセージにより転送し、
Aは、エンティティ認証におけるナンスでもある対称鍵k_(1)をBの公開鍵P_(B)で暗号化したものを、メッセージとしてBに送信し、
Bは、メッセージを受信すると、k_(1)を復号し、そのk_(1)とエンティティ認証におけるナンスでもある対称鍵k_(2)とを暗号化したものを、メッセージとしてAに送信し、
Aは、受信したメッセージを復号し、復号したk_(1)が送信したものと一致するか確認することでBのエンティティ認証を行い、k_(2)をBの公開鍵で暗号化したものをメッセージとしてBに送信し、
Bは、受信したメッセージを復号し、復号したk_(2)が送信したものと一致するか確認することでAのエンティティ認証を行い、セッション鍵は、公知の非可逆関数fを用いて、f(k_(1), k_(2))として計算される”技術

ここで、当該周知技術と引用発明とを対比する。

引用発明の「乱数N_(b)」は、エンティティ認証におけるナンスといえるものであるから、周知技術における「Aは、エンティティ認証におけるナンスでもある対称鍵k_(1)をBの公開鍵P_(B)で暗号化したものを、メッセージとしてBに送信」することと、引用発明における「前記コンテンツ配信サーバが・・・前記乱数N_(b)を前記携帯情報端末の公開鍵E_(a)で暗号化して(暗号化データE_(a)(N_(b))を作成し)、これを電子署名CertificationBとともに前記携帯情報端末に送信する」こととは、“ナンスを相手の公開鍵で暗号化したものを送信する”点で共通する。

そして、周知技術における「Bは、メッセージを受信すると、k_(1)を復号し、そのk_(1)・・・を暗号化したものを、メッセージとしてAに送信し、」「Aは、メッセージを受信すると、復号したk_(1)が送信したものと一致するか確認することでBのエンティティ認証を行」うことと、引用発明における「前記携帯情報端末が、前記電子署名CertificationBと前記暗号データE_(a)(N_(b))からなるメッセージを受信すると・・・前記暗号化データE_(a)(N_(b))を復号化して、乱数N_(b)を取り出して、そのハッシュ値Hash(N_(b))を作成し、・・・ハッシュ値Hash(N_(b))を含むメッセージを、前記コンテンツ配信サーバに送信」し、「前記コンテンツ配信サーバが、前記乱数N_(b)のハッシュ値を計算し、当該計算されたハッシュ値が、前記携帯情報端末から受信した前記ハッシュ値Hash(N_(b))と等しいか否かを確認することで前記携帯情報端末の認証を行」うこととは、“暗号化されたナンスを受信し、その暗号化されたナンスを復号し、復号したナンスに基づくものをメッセージとして送信し、そのメッセージを受信した側が、受信したメッセージからのナンスに基づくものを比較することによって、メッセージを送信した側を認証する”ことである点で共通する。

そうすると、周知技術の「対称鍵k_(1)」と、引用発明の「乱数N_(b)」及び「Hash(N_(b))」は、いずれも、送信元(周知技術における「A」、引用発明における「コンテンツ配信サーバ」)が、送信先(周知技術における「B」、引用発明における「携帯情報端末」)を認証するために、ナンス(周知技術における「k_(1)」、引用発明における「N_(b)」)を暗号化して送信し、送信先では、暗号化されたナンスを受信し復号したものからナンス(周知技術における「k_(1)」、引用発明における「Hash(N_(b))」)を得て、そのナンスを送信元へと送信し、送信元でナンスを比較することで認証を行う際に用いられるものであるから、「認証に用いる情報」である点で共通するといえる。

してみると、上記引用文献2のステップ(2)において、ナンスである対称鍵k_(1)を、ナンスである対称鍵k_(2)と共に暗号化する如く、引用発明においても、認証に用いる情報である「ハッシュ値Hash(N_(b))」を、N_(a)と共に暗号化して送受信するように構成すること、すなわち、上記相違点に係る構成とすることは、当業者が容易に想到し得たことである。

なお、上記引用文献1の上記Aに「第1の装置が・・・N_(a)、S_(a)、Hash(S_(a))を第2の装置の公開鍵E_(b)で暗号化したデータE_(b)(N_(a),S_(a),Hash(S_(a)))を、受信データから取り出した乱数N_(b)とともに第2の装置に送信する」、「第2の装置が、自分の秘密鍵で受信データE_(b)(N_(a),S_(a),Hash(S_(a)))を復号化」と記載されるように、上記引用文献1においても、“第1の装置が生成した相互認証用の乱数N_(a)及び相互認証用のハッシュ値Hash(S_(a))を第2の装置の公開鍵E_(b)で暗号化し、第2の装置が受信データを自分の秘密鍵で復号化する”技術が開示されており、相互認証用のハッシュ値についても暗号化及び復号化するように構成することは、当業者が必要に応じて適宜採用し得る設計的事項にすぎない。

よって、上記相違点は格別なものではない。

そして、本願発明の奏する作用効果についても、上記引用発明及び周知技術の奏する作用効果から予測される範囲内のものにすぎず、格別顕著なものということはできない。

したがって、本願発明は、上記引用発明及び周知技術に基づいて、容易に発明できたものである。

6.審判請求人の主張等について

なお、審判請求人は、上記平成24年8月17日付けの審判請求書において、

『(2)引用文献1には、審査官認定の通り、ハッシュ値Hash(Nb)を暗号化及び復号することについて何ら記載されていないことはもとより、乱数Nbのハッシュ値Hash(Nb)を相互認証のために使用することさえも何ら開示されていない。』
(当審注:下線は、参考のために当審で付与したものである。)

と主張しているが、上記引用文献1の上記Fに、

「【0118】まず、所定のハッシュ・アルゴリズムにより乱数発生部32で発生した乱数N_(b)のハッシュ値を計算する(ステップS31)。そして、計算されたハッシュ値が、携帯情報端末15から受信したハッシュ値Hash(N_(b))と等しいか否かを判別する(ステップS32)。」、
「【0119】これらハッシュ値が等しい場合、携帯情報端末15が正しくメッセージを復号化できたことを確認できるので、携帯情報端末15が本物の通信相手であることが判る。」

と記載されるように、乱数N_(b)のハッシュ値Hash(N_(b))を、相互認証における携帯情報端末の認証に使用することが明記されている。
したがって、上記引用文献1に、乱数N_(b)のハッシュ値Hash(N_(b))を相互認証のために使用することが開示されていないことをいう審判請求人の主張は失当である。

また、審判請求書におけるその余の主張についても、上記「5.当審の判断」において検討したように、採用することはできない。

してみれば、審判請求人の審判請求書におけるいずれの主張も理由がなく、採用することができない。

7.むすび

以上のとおり、本願発明は、本願の特許出願前に日本国内又は外国において頒布された刊行物に記載された発明に基づいて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができない。

したがって、その余の請求項について論及するまでもなく、本願は拒絶すべきものである。

よって、結論のとおり審決する。
 
審理終結日 2014-02-13 
結審通知日 2014-02-18 
審決日 2014-03-26 
出願番号 特願2009-532508(P2009-532508)
審決分類 P 1 8・ 121- Z (H04L)
最終処分 不成立  
前審関与審査官 中里 裕正  
特許庁審判長 金子 幸一
特許庁審判官 田中 秀人
仲間 晃
発明の名称 相互認証のための方法および装置  
代理人 竹内 将訓  
代理人 佐藤 立志  
代理人 幸長 保次郎  
代理人 河野 直樹  
代理人 砂川 克  
代理人 福原 淑弘  
代理人 中村 誠  
代理人 蔵田 昌俊  
代理人 岡田 貴志  
代理人 白根 俊郎  
代理人 井関 守三  
代理人 堀内 美保子  
代理人 野河 信久  
代理人 峰 隆司  

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