• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 5項独立特許用件 特許、登録しない。 H04L
審判 査定不服 2項進歩性 特許、登録しない。 H04L
管理番号 1364359
審判番号 不服2019-6234  
総通号数 249 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2020-09-25 
種別 拒絶査定不服の審決 
審判請求日 2019-05-13 
確定日 2020-07-13 
事件の表示 特願2017-545344「通信デバイスとネットワークデバイスとの間の通信におけるセキュリティ構成」拒絶査定不服審判事件〔平成28年 9月 1日国際公開,WO2016/137374,平成30年 3月15日国内公表,特表2018-507646〕について,次のとおり審決する。 
結論 本件審判の請求は,成り立たない。 
理由 第1.手続の経緯
本願は,2015年7月13日(パリ条約による優先権主張外国庁受理2015年2月27日 アメリカ合衆国)を国際出願日とする出願であって,
平成29年10月5日付けで特許法184条の4第1項の規定による明細書,請求の範囲,及び,図面(図面の中の説明に限る)の日本語による翻訳文,並びに,条約34条(2)(b)の規定に基づく補正書の日本語による翻訳文が提出され,同日付けで手続補正がなされると共に審査請求がなされ,平成30年7月30日付けで審査官により拒絶理由が通知され,これに対して平成30年9月10日付けで意見書が提出されると共に手続補正がなされたが,平成30年12月28日付けで審査官により拒絶査定がなされ(謄本送達;平成31年1月11日),これに対して令和1年5月13日付けで審判請求がなされると共に手続補正がなされ,令和1年6月24日付けで審査官により特許法164条3項の規定に基づく報告がなされ,令和1年9月13日付けで上申書の提出があったものである。

第2.令和1年5月13日付けの手続補正の却下の決定

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

令和1年5月13日付け手続補正を却下する。

[理由]

1.補正の内容
令和1年5月13日付けの手続補正(以下,「本件手続補正」という)により,平成30年9月10日付けの手続補正により補正された特許請求の範囲,
「【請求項1】
通信ネットワーク(36)のネットワークデバイス(44)と通信するための通信デバイス(40)であって,
チャレンジ(RAND),第1のPFSパラメータ(PFS_(1)),及び前記第1のPFSパラメータ(PFS_(1))についての第1の検証コード(VC_(1);VC_(1)A;VC_(1)B)を前記ネットワークデバイス(44)から受信し,
前記チャレンジの派生をUSIM(48)へ転送し,
少なくとも1つの結果パラメータ(CK/IK,RES)を,前記USIM(48)からの応答として受信し,
前記結果パラメータ(CK/IK,RES)に基づいて,前記第1のPFSパラメータ(PFS1)が真正であるかを判定し,
前記判定において前記第1のPFSパラメータ(PFS_(1))が真正である場合に,第2のPFSパラメータ(PFS_(2))を生成し及び前記ネットワークデバイスへ送信する,
ように動作可能な通信デバイス(40)。
【請求項2】
通信ネットワーク(36)のネットワークデバイス(44)と通信するための通信デバイス(40)であって,
チャレンジ(RAND),第1のPFSパラメータ(PFS_(1)),及び前記第1のPFSパラメータ(PFS_(1))についての第1の検証コード(VC_(1);VC_(1)A;VC_(1)B)を前記ネットワークデバイス(44)から受信し,
前記チャレンジをUSIM(48)へ転送し,
少なくとも1つの結果パラメータ(CK/IK,RES)を,前記USIM(48)からの応答として受信し,
前記結果パラメータ(CK/IK,RES)に基づいて,前記第1のPFSパラメータ(PFS_(1))が真正であるかを判定し,
前記判定において前記第1のPFSパラメータ(PFS_(1))が真正である場合に,第2のPFSパラメータ(PFS_(2))を生成し及び前記ネットワークデバイスへ送信する,
ように動作可能な通信デバイス(40)。
【請求項3】
前記通信デバイス(40)と前記ネットワークデバイス(44)との間の通信のためのセッション鍵(K´)を生成する,ようにさらに動作可能であり,前記セッション鍵は,前記第1及び第2のPFSパラメータ(PFS_(1),PFS_(2))を生成するために使用される値(x,y)に少なくとも基づく,請求項1又は請求項2に記載の通信デバイス(40)。
【請求項4】
前記通信デバイス(40)と前記ネットワークデバイス(44)との間の通信のためのセッション鍵(K´)を生成する,ようにさらに動作可能であり,前記セッション鍵は,前記第1のPFSパラメータ(PFS_(1))と前記第2のPFSパラメータ(PFS_(2))の指数(y)とに基づく,請求項1又は請求項2に記載の通信デバイス(40)。
【請求項5】
前記通信デバイスは,前記チャレンジ(RAND)を受信し,前記転送を実行し,前記少なくとも1つの結果パラメータを受信し,前記第1のPFSパラメータ(PFS_(1))が真正であるかを判定し,並びに第2のPFSパラメータ(PFS_(2))を生成し及び送信するように動作可能なモバイル機器(46),を含む,請求項1?4のいずれか1項に記載の通信デバイス(40)。
【請求項6】
前記通信デバイスは,鍵及び暗号処理手段を含む識別モジュール(48),を含む,請求項1?5のいずれか1項に記載の通信デバイス(40)。
【請求項7】
前記第1及び第2のPFSパラメータはディフィーヘルマンパラメータである,請求項1?6のいずれか1項に記載の通信デバイス(40)。
【請求項8】
前記第1の検証コード(VC_(1)A;VC_(1)B)は,少なくとも前記第1のPFSパラメータに基づくメッセージ認証コードを含む,請求項1?7のいずれか1項に記載の通信デバイス(40)。
【請求項9】
前記派生は,前記チャレンジと同一である,請求項1に記載の通信デバイス(40)。
【請求項10】
前記派生は,前記チャレンジのハッシュである,請求項1に記載の通信デバイス(40)。
【請求項11】
前記チャレンジ(RAND)を受信するように動作可能であるとき,前記第1のPFSパラメータ(PFS_(1))及び前記第1の検証コード(VC_(1);VC_(1)A;VC_(1)B)は,これらを前記ネットワークデバイス(44)から認証要求メッセージ(20)内で受信するように動作可能であり,前記認証要求メッセージはチャレンジ検証コード(AUTN)をも含み,前記少なくとも1つの結果パラメータ(CK/IK,RES)を受信するように動作可能であるとき,前記チャレンジに対する応答として応答パラメータ(RES)を受信するように動作可能であり,
前記第2のPFSパラメータ(PFS_(2))を生成し及び送信するように動作可能であるとき,第2の検証コード(VC_(2);VC_(2)A;VC_(2)B)と共に前記第2のPFSパラメータを生成し及びこれらを前記応答パラメータ(RES)をも含む認証応答メッセージ(24)内で送信するように動作可能である,
請求項1?10のいずれか1項に記載の通信デバイス(40)。
【請求項12】
通信ネットワーク(36)のネットワークデバイス(44)と通信関係にある通信デバイス(40)のための方法であって,前記方法は,前記通信デバイスによって実行され,
チャレンジ(RAND),第1のPFSパラメータ(PFS_(1)),及び前記第1のPFSパラメータ(PFS_(1))についての第1の検証コード(VC_(1);VC_(1)A;VC_(1)B)を前記ネットワークデバイス(44)から受信すること(64)と,
前記チャレンジの派生をUSIM(48)へ転送すること(65)と,
少なくとも1つの結果パラメータ(CK/IK,RES)を,前記USIM(48)からの応答として受信すること(66)と,
前記結果パラメータ(CK/IK,RES)に基づいて,前記第1のPFSパラメータ(PFS_(1))が真正であるかを判定すること(68)と,
前記判定において前記第1のPFSパラメータ(PFS_(1))が真正である場合に,第2のPFSパラメータ(PFS_(2))を生成(70)し及び前記ネットワークデバイスへ送信すること(72)と,
を含む方法。
【請求項13】
通信ネットワーク(36)のネットワークデバイス(44)と通信関係にある通信デバイス(40)のための方法であって,前記方法は,前記通信デバイスによって実行され,
チャレンジ(RAND),第1のPFSパラメータ(PFS_(1)),及び前記第1のPFSパラメータ(PFS_(1))についての第1の検証コード(VC_(1);VC_(1)A;VC_(1)B)を前記ネットワークデバイス(44)から受信すること(64)と,
前記チャレンジをUSIM(48)へ転送すること(65)と,
少なくとも1つの結果パラメータ(CK/IK,RES)を,前記USIM(48)からの応答として受信すること(66)と,
前記結果パラメータ(CK/IK,RES)に基づいて,前記第1のPFSパラメータ(PFS_(1))が真正であるかを判定すること(68)と,
前記判定において前記第1のPFSパラメータ(PFS_(1))が真正である場合に,第2のPFSパラメータ(PFS_(2))を生成(70)し及び前記ネットワークデバイスへ送信すること(72)と,
を含む方法。
【請求項14】
第1の通信ネットワーク(36)の第1のネットワークデバイス(44)であって,前記第1のネットワークデバイス(44)は,
チャレンジ(RAND)を取得し,
第1のPFSパラメータ(PFS_(1))を取得し,
前記第1のPFSパラメータ(PFS_(1))についての第1の検証コード(VC_(1);VC_(1)A;VC_(1)B)を取得し,
前記チャレンジ(RAND),前記第1のPFSパラメータ(PFS_(1))及び前記第1の検証コード(VC_(1);VC_(1)A;VC_(1)B)をUSIMを有する通信デバイス(40)へ送信し,
前記通信デバイス(40)から第2のPFSパラメータ(PFS_(2)),第2の検証コード(VC_(2);VC_(2)A;VC_(2)B)及び応答パラメータ(RES)を受信し,
前記応答パラメータの真正性を判定し,
前記第2の検証コード(VC_(2);VC_(2)A;VC_(2)B)に基づいて前記第2のPFSパラメータ(PFS_(2))を検証する
ように動作可能である,第1のネットワークデバイス(44)。
【請求項15】
前記通信デバイス(40)と前記第1のネットワークデバイス(44)との間の通信のためのセッション鍵(K´)を計算する,ようにさらに動作可能であり,前記セッション鍵は,前記第1及び第2のPFSパラメータ(PFS_(1),PFS_(2))を生成するために使用される値(x,y)に少なくとも基づく,請求項14に記載の第1のネットワークデバイス(44)。
【請求項16】
前記通信デバイス(40)と前記第1のネットワークデバイス(44)との間の通信のためのセッション鍵(K´)を計算する,ようにさらに動作可能であり,前記セッション鍵は,前記第2のPFSパラメータ(PFS_(2))と前記第1のPFSパラメータ(PFS_(1))の指数(x)とに基づく,請求項14に記載の第1のネットワークデバイス(44)。
【請求項17】
前記チャレンジを取得するように動作可能であるとき,チャレンジ検証コード(AUTN)を取得するようにも動作可能であり,前記チャレンジ(RAND),前記第1のPFSパラメータ(PFS_(1))及び前記第1の検証コード(VC_(1);VC_(1)A;VC_(1)B)を送信するように動作可能であるとき,これらを前記チャレンジ検証コード(AUTN)と共に認証要求メッセージ(20)内で送信するように動作可能であり,前記第2のPFSパラメータ(PFS_(2)),前記第2の検証コード(VC_(2);VC_(2)A;VC_(2)B)及び前記応答パラメータ(RES)を受信するように動作可能であるとき,これらを認証応答メッセージ(24)内で受信するように動作可能である,請求項14?16のいずれか1項に記載の第1のネットワークデバイス(44)。
【請求項18】
第1の通信ネットワーク(36)の第1のネットワークデバイス(44)のための方法であって,前記方法は,前記第1のネットワークデバイス(44)によって実行され,
チャレンジ(RAND)を取得するステップ(74)と,
第1のPFSパラメータ(PFS_(1))を取得するステップ(76)と,
前記第1のPFSパラメータについての第1の検証コード(VC_(1);VC_(1)A;VC_(1)B)を取得するステップ(78)と,
前記チャレンジ(RAND),前記第1のPFSパラメータ(PFS_(1))及び前記第1の検証コード(VC_(1);VC_(1)A;VC_(1)B)をUSIMを有する通信デバイス(40)へ送信するステップ(80)と,
前記通信デバイス(40)から第2のPFSパラメータ(PFS_(2)),第2の検証コード(VC_(2);VC_(2)A;VC_(2)B)及び応答パラメータ(RES)を受信するステップ(82)と,
前記応答パラメータの真正性を判定するステップ(84)と,
前記第2の検証コード(VC_(2);VC_(2)A;VC_(2)B)に基づいて前記第2のPFSパラメータ(PFS_(2))を検証するステップ(86)と
を含む方法。」(以下,上記引用の請求項各項を,「補正前の請求項」という)は,
「【請求項1】
通信ネットワーク(36)のネットワークデバイス(44)と通信するための通信デバイス(40)であって,
チャレンジ(RAND),第1のPFSパラメータ(PFS_(1)),及び前記第1のPFSパラメータ(PFS_(1))についての第1の検証コード(VC_(1);VC_(1)A;VC_(1)B)を前記ネットワークデバイス(44)から受信し,前記第1の検証コード(VC_(1)A;VC_(1)B)は,少なくとも前記第1のPFSパラメータに基づくメッセージ認証コードを含み,
前記チャレンジの派生をUSIM(48)へ転送し,
少なくとも1つの結果パラメータ(CK/IK,RES)を,前記USIM(48)からの応答として受信し,
前記結果パラメータ(CK/IK,RES)に基づいて,前記第1のPFSパラメータ(PFS_(1))が真正であるかを判定し,
前記判定において前記第1のPFSパラメータ(PFS_(1))が真正である場合に,第2のPFSパラメータ(PFS_(2))を生成し及び前記ネットワークデバイスへ送信する,
ように動作可能な通信デバイス(40)。
【請求項2】
通信ネットワーク(36)のネットワークデバイス(44)と通信するための通信デバイス(40)であって,
チャレンジ(RAND),第1のPFSパラメータ(PFS_(1)),及び前記第1のPFSパラメータ(PFS_(1))についての第1の検証コード(VC_(1);VC_(1)A;VC_(1)B)を前記ネットワークデバイス(44)から受信し,前記第1の検証コード(VC_(1)A;VC_(1)B)は,少なくとも前記第1のPFSパラメータに基づくメッセージ認証コードを含み,
前記チャレンジをUSIM(48)へ転送し,
少なくとも1つの結果パラメータ(CK/IK,RES)を,前記USIM(48)からの応答として受信し,
前記結果パラメータ(CK/IK,RES)に基づいて,前記第1のPFSパラメータ(PFS_(1))が真正であるかを判定し,
前記判定において前記第1のPFSパラメータ(PFS_(1))が真正である場合に,第2のPFSパラメータ(PFS2)を生成し及び前記ネットワークデバイスへ送信する,
ように動作可能な通信デバイス(40)。
【請求項3】
前記通信デバイス(40)と前記ネットワークデバイス(44)との間の通信のためのセッション鍵(K´)を生成する,ようにさらに動作可能であり,前記セッション鍵は,前記第1及び第2のPFSパラメータ(PFS_(1),PFS_(2))を生成するために使用される値(x,y)に少なくとも基づく,請求項1又は請求項2に記載の通信デバイス(40)。
【請求項4】
前記通信デバイス(40)と前記ネットワークデバイス(44)との間の通信のためのセッション鍵(K´)を生成する,ようにさらに動作可能であり,前記セッション鍵は,前記第1のPFSパラメータ(PFS_(1))と前記第2のPFSパラメータ(PFS_(2))の指数(y)とに基づく,請求項1又は請求項2に記載の通信デバイス(40)。
【請求項5】
前記通信デバイスは,前記チャレンジ(RAND)を受信し,前記転送を実行し,前記少なくとも1つの結果パラメータを受信し,前記第1のPFSパラメータ(PFS_(1))が真正であるかを判定し,並びに第2のPFSパラメータ(PFS_(2))を生成し及び送信するように動作可能なモバイル機器(46),を含む,請求項1?4のいずれか1項に記載の通信デバイス(40)。
【請求項6】
前記通信デバイスは,鍵及び暗号処理手段を含む識別モジュール(48),を含む,請求項1?5のいずれか1項に記載の通信デバイス(40)。
【請求項7】
前記第1及び第2のPFSパラメータはディフィーヘルマンパラメータである,請求項1?6のいずれか1項に記載の通信デバイス(40)。
【請求項8】
前記派生は,前記チャレンジと同一である,請求項1に記載の通信デバイス(40)。
【請求項9】
前記派生は,前記チャレンジのハッシュである,請求項1に記載の通信デバイス(40)。
【請求項10】
前記チャレンジ(RAND)を受信するように動作可能であるとき,前記第1のPFSパラメータ(PFS_(1))及び前記第1の検証コード(VC_(1);VC_(1)A;VC_(1)B)は,これらを前記ネットワークデバイス(44)から認証要求メッセージ(20)内で受信するように動作可能であり,前記認証要求メッセージはチャレンジ検証コード(AUTN)をも含み,前記少なくとも1つの結果パラメータ(CK/IK,RES)を受信するように動作可能であるとき,前記チャレンジに対する応答として応答パラメータ(RES)を受信するように動作可能であり,
前記第2のPFSパラメータ(PFS_(2))を生成し及び送信するように動作可能であるとき,第2の検証コード(VC_(2);VC_(2)A;VC_(2)B)と共に前記第2のPFSパラメータを生成し及びこれらを前記応答パラメータ(RES)をも含む認証応答メッセージ(24)内で送信するように動作可能である,
請求項1?9のいずれか1項に記載の通信デバイス(40)。
【請求項11】
通信ネットワーク(36)のネットワークデバイス(44)と通信関係にある通信デバイス(40)のための方法であって,前記方法は,前記通信デバイスによって実行され,
チャレンジ(RAND),第1のPFSパラメータ(PFS_(1)),及び前記第1のPFSパラメータ(PFS_(1))についての第1の検証コード(VC_(1);VC_(1)A;VC_(1)B)を前記ネットワークデバイス(44)から受信すること(64)であって,前記第1の検証コード(VC_(1)A;VC_(1)B)は,少なくとも前記第1のPFSパラメータに基づくメッセージ認証コードを含む,ことと,
前記チャレンジの派生をUSIM(48)へ転送すること(65)と,
少なくとも1つの結果パラメータ(CK/IK,RES)を,前記USIM(48)からの応答として受信すること(66)と,
前記結果パラメータ(CK/IK,RES)に基づいて,前記第1のPFSパラメータ(PFS_(1))が真正であるかを判定すること(68)と,
前記判定において前記第1のPFSパラメータ(PFS_(1))が真正である場合に,第2のPFSパラメータ(PFS2)を生成(70)し及び前記ネットワークデバイスへ送信すること(72)と,
を含む方法。
【請求項12】
通信ネットワーク(36)のネットワークデバイス(44)と通信関係にある通信デバイス(40)のための方法であって,前記方法は,前記通信デバイスによって実行され,
チャレンジ(RAND),第1のPFSパラメータ(PFS_(1)),及び前記第1のPFSパラメータ(PFS_(1))についての第1の検証コード(VC_(1);VC_(1)A;VC_(1)B)を前記ネットワークデバイス(44)から受信すること(64)であって,前記第1の検証コード(VC_(1)A;VC_(1)B)は,少なくとも前記第1のPFSパラメータに基づくメッセージ認証コードを含む,ことと,
前記チャレンジをUSIM(48)へ転送すること(65)と,
少なくとも1つの結果パラメータ(CK/IK,RES)を,前記USIM(48)からの応答として受信すること(66)と,
前記結果パラメータ(CK/IK,RES)に基づいて,前記第1のPFSパラメータ(PFS_(1))が真正であるかを判定すること(68)と,
前記判定において前記第1のPFSパラメータ(PFS_(1))が真正である場合に,第2のPFSパラメータ(PFS_(2))を生成(70)し及び前記ネットワークデバイスへ送信すること(72)と,
を含む方法。
【請求項13】
第1の通信ネットワーク(36)の第1のネットワークデバイス(44)であって,前記第1のネットワークデバイス(44)は,
チャレンジ(RAND)を取得し,
第1のPFSパラメータ(PFS_(1))を取得し,
前記第1のPFSパラメータ(PFS_(1))についての第1の検証コード(VC_(1);VC_(1)A;VC_(1)B)を取得し,前記第1の検証コード(VC_(1)A;VC_(1)B)は,少なくとも前記第1のPFSパラメータに基づくメッセージ認証コードを含み,
前記チャレンジ(RAND),前記第1のPFSパラメータ(PFS_(1))及び前記第1の検証コード(VC_(1);VC_(1)A;VC_(1)B)をUSIMを有する通信デバイス(40)へ送信し,
前記通信デバイス(40)から第2のPFSパラメータ(PFS_(2)),第2の検証コード(VC_(2);VC_(2)A;VC_(2)B)及び応答パラメータ(RES)を受信し,
前記応答パラメータの真正性を判定し,
前記第2の検証コード(VC_(2);VC_(2)A;VC_(2)B)に基づいて前記第2のPFSパラメータ(PFS_(2))を検証する
ように動作可能である,第1のネットワークデバイス(44)。
【請求項14】
前記通信デバイス(40)と前記第1のネットワークデバイス(44)との間の通信のためのセッション鍵(K´)を計算する,ようにさらに動作可能であり,前記セッション鍵は,前記第1及び第2のPFSパラメータ(PFS_(1),PFS_(2))を生成するために使用される値(x,y)に少なくとも基づく,請求項13に記載の第1のネットワークデバイス(44)。
【請求項15】
前記通信デバイス(40)と前記第1のネットワークデバイス(44)との間の通信のためのセッション鍵(K´)を計算する,ようにさらに動作可能であり,前記セッション鍵は,前記第2のPFSパラメータ(PFS_(2))と前記第1のPFSパラメータ(PFS_(1))の指数(x)とに基づく,請求項13に記載の第1のネットワークデバイス(44)。
【請求項16】
前記チャレンジを取得するように動作可能であるとき,チャレンジ検証コード(AUTN)を取得するようにも動作可能であり,前記チャレンジ(RAND),前記第1のPFSパラメータ(PFS_(1))及び前記第1の検証コード(VC_(1);VC_(1)A;VC_(1)B)を送信するように動作可能であるとき,これらを前記チャレンジ検証コード(AUTN)と共に認証要求メッセージ(20)内で送信するように動作可能であり,前記第2のPFSパラメータ(PFS_(2)),前記第2の検証コード(VC_(2);VC_(2)A;VC_(2)B)及び前記応答パラメータ(RES)を受信するように動作可能であるとき,これらを認証応答メッセージ(24)内で受信するように動作可能である,請求項13?15のいずれか1項に記載の第1のネットワークデバイス(44)。
【請求項17】
第1の通信ネットワーク(36)の第1のネットワークデバイス(44)のための方法であって,前記方法は,前記第1のネットワークデバイス(44)によって実行され,
チャレンジ(RAND)を取得する,ステップ(74)と,
第1のPFSパラメータ(PFS_(1))を取得するステップ(76)と,
前記第1のPFSパラメータについての第1の検証コード(VC_(1);VC_(1)A;VC_(1)B)を取得するステップ(78)であって,前記第1の検証コード(VC_(1)A;VC_(1)B)は,少なくとも前記第1のPFSパラメータに基づくメッセージ認証コードを含む,ステップと,
前記チャレンジ(RAND),前記第1のPFSパラメータ(PFS_(1))及び前記第1の検証コード(VC_(1);VC_(1)A;VC_(1)B)をUSIMを有する通信デバイス(40)へ送信するステップ(80)と,
前記通信デバイス(40)から第2のPFSパラメータ(PFS_(2)),第2の検証コード(VC_(2);VC_(2)A;VC_(2)B)及び応答パラメータ(RES)を受信するステップ(82)と,
前記応答パラメータの真正性を判定するステップ(84)と,
前記第2の検証コード(VC_(2);VC_(2)A;VC_(2)B)に基づいて前記第2のPFSパラメータ(PFS_(2))を検証するステップ(86)と
を含む方法。」(以下,上記引用の請求項各項を,「補正後の請求項」という)に補正された。

2.補正の適否
(1)新規性・目的要件
本件手続補正は,補正前の請求項1,同請求項2,同請求項13,同請求項14,及び,同請求項18に記載の発明特定事項である「第1の検証コード(VC_(1);VC_(1)A;VC_(1)B)」に対して,それぞれ,「少なくとも前記第1のPFSパラメータに基づくメッセージ認証コードを含み」という限定事項を付加し,補正後の請求項1,同請求項2,同請求項12,同請求項13,および,同請求項17とすると共に,補正前の請求項8を削除するものであって,当該限定事項は,平成29年10月5日付けで提出された明細書,請求の範囲の日本語による翻訳文(以下,これを「当初明細書等」という)の請求項8,及び,段落【0029】の記載に基づくものであり,本件手続補正は,当初明細書等の記載の範囲内でなされたものであるから,特許法184条の12第2項により読み替える同法17条の2第3項の規定を満たすものであり,本件手続補正は,限定的減縮,及び,請求項の削除を目的とするものであって,本件手続補正前に受けた拒絶理由通知において特許をすることができないものか否かについての判断が示された全ての発明と,本件手続補正により補正された請求項に係る発明とが,発明の単一性の要件を満たす一群の発明に該当するものであるから,特許法17条の2第4項,及び,第5項の規定を満たすものである。
そこで,本件手続補正が,特許法17条の2第6項において準用する同法126条7項の規定を満たすものであるか否か,即ち,補正後の請求項に記載されている事項により特定される発明が特許出願の際独立して特許を受けることができるものであるか否か,以下に検討する。

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

「通信ネットワーク(36)のネットワークデバイス(44)と通信するための通信デバイス(40)であって,
チャレンジ(RAND),第1のPFSパラメータ(PFS_(1)),及び前記第1のPFSパラメータ(PFS_(1))についての第1の検証コード(VC_(1);VC_(1)A;VC_(1)B)を前記ネットワークデバイス(44)から受信し,前記第1の検証コード(VC_(1)A;VC_(1)B)は,少なくとも前記第1のPFSパラメータに基づくメッセージ認証コードを含み,
前記チャレンジの派生をUSIM(48)へ転送し,
少なくとも1つの結果パラメータ(CK/IK,RES)を,前記USIM(48)からの応答として受信し,
前記結果パラメータ(CK/IK,RES)に基づいて,前記第1のPFSパラメータ(PFS_(1))が真正であるかを判定し,
前記判定において前記第1のPFSパラメータ(PFS_(1))が真正である場合に,第2のPFSパラメータ(PFS_(2))を生成し及び前記ネットワークデバイスへ送信する,
ように動作可能な通信デバイス(40)。」

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

A.「【0004】
これらのセキュリティの弱点は,第三世代(3G)無線通信規格における,セキュリティプロトコルの開発において検討された。特に,ユニバーサル移動電話システム(UMTS)のために開発された認証と鍵共有(AKA)プロトコルは,GSMが影響を受けやすい不正基地局の攻撃を防止する一連番号およびメッセージ認証符号(MAC)のような特徴を含む。したがって,ネットワーク認証のためにUMTSユーザサービス識別モジュール(USIM)を用いる移動加入者は,GSM加入者識別モジュール(SIM)のユーザに対して加えられる攻撃の影響を受けにくい。
【0005】
3G標準化団体は,例えば,第3世代パートナーシッププロジェクト文書3GPP 33.220汎用認証アーキテクチャ(GAA)において,汎用ブートストラッピングアーキテクチャのために汎用認証アーキテクチャ(GAA)を開発している。このアーキテクチャは,移動加入者のユーザ機器(UE)とブートストラッピングサーバ機能(BSF)として知られている新しいサーバエンティティとの間の鍵を確立するために3G AKAプロトコルに頼っている。これらの鍵から,BSFによって,さらなる複数の鍵が,ネットワークアプリケーション機能(NAF)と適切なUEの間で共有されるセキュリティ鍵を確立する方法として種々のNAFに対して導出され,提供されるかもしれない。
【0006】
開発中の手法は,GSMなどの2Gまたはより初期のレガシーシステムに比較して固有のセキュリティが改良されたUMTSのユニバーサル加入者識別モジュール(USIM)でサポートされるような3Gの認証と鍵共有法に頼っている。例えば,汎用認証アーキテクチャ(GAA)および汎用ブートストラッピングアーキテクチャ(GBA)は3Gネットワークに対して指定され,移動ユーザ機器とネットワークアプリケーションおよび/またはサービスを容易にするネットワークサーバとの間の安全な相互認証を提供するために,3G移動ネットワークのセキュリティインフラストラクチャ(すなわち,USIMベースのセキュリティ)を構築する。
【0007】
しかし,これらの相互認証手法(例えば,GAAおよびGBA)は,例えばGSM認証と鍵共有(AKA)プロトコルなどの,より以前に開発された(例えば,2G)通信システムでは利用可能でない。これらのGSMプロトコルは再実行攻撃の影響を受けやすい。したがって攻撃側は鍵の再使用を強制し,鍵を暴露するためにいくつかの状況における弱点を利用し,これによりセキュリティを攻撃するかもしれない。したがって,再実行攻撃の影響を受けにくく,鍵が容易に暴露されないような方法で,GSMの認証と鍵共有からアプリケーションセキュリティ鍵をブートストラップするための方法が必要である。
【発明の開示】
【発明が解決しようとする課題】
【0008】
したがって,3Gネットワークに対して指定された汎用認証アーキテクチャ(GAA)がレガシーシステム(例えば,2Gまたはそれ以前のシステム)をサポートするように拡張されるかもしれない手法を確立する必要がある。このことは,GSMの加入者または加入者識別モジュール(SIM)を有する他の装置が,SIMをUMTS USIMで置き替える必要無しに,移動ネットワークアプリケーションおよび/またはサービスを利用するための鍵を供給されることを可能とするだろう。さらに,そのような方法はGSM認証自体の脆弱性に基づく弱点を汎用認証アーキテクチャに持ち込むべきでない。
【課題を解決するための手段】
【0009】
アプリケーション-セキュリティ鍵をレガシー加入者識別モジュール(例えば3G AKA方式をサポートしないGSM SIMおよびCDMA2000 R-UIM)をサポートする移動端末と安全に共有するための相互認証方法が提供される。チャレンジ-応答の鍵交換はブートストラッピングサーバ機能(BSF)と移動端末(MT)の間で実施される。BSFはホームロケーションレジスタ(HLR)からこの移動端末に対応するネットワーク認証パラメータ(例えば,GSM RAND,SRES,Kc)を受信し,RANDを含む認証チャレンジを生成し,それをサーバ認証された公開鍵方式の下で前記MTへ送信する。この認証チャレンジは乱数,識別情報,タイムススタンプ,一連番号およびディフィー-ヘルマン公開鍵などの更なるパラメータを含むかもしれない。」(下線は,当審にて説明の都合上,付加したものである。以下,同じ。)

B.「【0027】
図1は1実施態様に従ってブートストラッピングサーバおよびレガシー移動端末が互いを相互認証できる通信システムを示すブロック図である。GSM準拠の,または,CDMA2000準拠の通信システムのようなネットワークアーキテクチャ100は移動端末(MT)102,ホームロケーションレジスタ(HLR)104,ブートストラッピングサーバ機能(BSF)106,および少なくとも1つのネットワークアプリケーション機能(NAF)108を含む。HLR104とBSF106に対して,ネットワークアーキテクチャ100のインフラストラクチャの一部である1つ以上のネットワーク装置および/またはサーバがホストとなるかもしれない。HLR104は,加入者に属する各MT102に対する国際移動加入者識別番号(IMSI)を含む無線キャリアに対する移動加入者情報を格納するデータベースを含む。IMSIはネットワーク内のMT102に関連する一意の数である。IMSIはまた,各MT102の加入者識別モジュール(SIM)にも格納され,MT102に関する情報を検索するためにネットワークHLRへMTによって送られる。
【0028】
MT102はネットワーク100上で通信するために,予め定義されたプロトコル(例えば,3Gより前のプロトコル)を用いてサービスプロバイダに登録するかまたは接続するレガシー無線通信装置であるかもしれない。いくつかの実施態様において,サービスプロバイダによるこの登録プロセスは,事前共有秘密鍵(例えば,GSM SIM,CDMA認証モジュール,または他のレガシーモジュールに格納されている)を用いてMT102を認証することを含むかもしれない。例えば,MT102は,MT102が,GSMまたはCDM2000ネットワークで動作できるように,および無線経由の通信のためのネットワークによって認証され得るように,GSM準拠のSIM,またはCDMA2000準拠の認証モジュールを含むかもしれない。
【0029】
MT102がネットワークを介した通信のためにサービスプロバイダによっていったん認証されると,本発明の1つの態様は,安全なネットワークアプリケーションを可能にするためにもう一つの認証の層を追加する。この付加的認証方式は基本的なネットワークベアラまたはベアラの認証方式とは別のものである。認証の付加的層は,ネットワークまたはベアラのセキュリティサービスとは独立している鍵を確立するためにSIMまたは認証モジュール内の既存の鍵を,新しいプロトコルと共に用いる。この新しい認証方式は,MT102と特定のNAFの間で共有され,BSF106を経由してNAF108に分配される認証用または他の目的のための鍵を提供する。例えば,NAF108はネットワーク化された装置で動作するアプリケーション,例えば商取引アプリケーションおよび/または,位置に基づくサービスであるかもしれない。
【0030】
MT102がネットワークアプリケーションの使用を始める準備ができている場合,それは通信リンク110を通じてNAF108との接続を開始する。MTとNAFが適切な鍵をまだ共有していない場合,NAF108はインターフェース112を通じてBSF106へ認証鍵を要求する。未だそうしていない場合,MT102とBSF106は,認証リンク114上でMT102と鍵を共有する。
【0031】
ディフィー-ヘルマンの鍵交換はMT102とBSF106の間の鍵共有処理の一部として用いられるかもしれない。ディフィー-ヘルマンの鍵交換は,互いの知識を予め有していない二者が,安全でない通信チャネル上で共有秘密鍵を共同で確立することを可能とする暗号化プロトコルである。1つのアプリケーションにおいて,この共有秘密鍵は対称鍵暗号法を用いて後続の通信を暗号化するために用いることができる。
【0032】
しかし,それだけでは従来のディフィー-ヘルマン鍵交換アルゴリズムは,このアルゴリズムのセキュリティを密かに攻撃する「中間者」の攻撃を受けやすい。これは,MT102とNAF108の間で商取引および/または秘密取引を実行するために,無線媒体上で情報が交換される場合に特に問題である。
【0033】
本発明の1つの特徴は,BSF106とMT102が公開鍵または共有秘密鍵を,GSMおよび/またはCDMA2000固有の弱点に影響されにくい方法で共有することを可能とするプロトコルを提供する。特に,BSF106を認証するために,MT102は最初に,ディジタル証明書を供給される。これは,BSF106からMT102への通信がディジタル署名されるかまたはサーバ認証されたチャンネルで伝達されることを可能とし,その結果,MT102が,認証処理の間に受信した鍵またはパラメータがBSF106から来るのであり,「中間者」または再実行攻撃を試みる別のエンティティから来るのではないことを確認することを可能とする。したがって,本方法は3Gの汎用ブートストラッピングアーキテクチャの認証方式を,ネットワーク認証からそれら自身利益を得ないUMTS AKA以外のプロトコルに拡張するために適用されるかもしれない。」

C.「【0048】
図6に,1つの実施態様に従って,ネットワークアプリケーション機能に対して相互に安全に認証するために,GSM準拠の移動端末608およびブートストラッピングサーバ機能604間でチャレンジ-応答プロトコルを実行する方法を示す。GSMの認証と鍵共有(AKA)はチャレンジ応答プロトコルに基づく。レガシーSIMに基づいてブートストラップするために,HLR/AuCおよびSIMは,既存の秘密鍵KiおよびGSMアルゴリズムA3およびA8に基づいて同様の計算を実行する。GSMプロトコルにおいて,秘密鍵Ki並びに認証アルゴリズムA3およびA8はネットワークHLR602と同様に,加入者識別モジュール(SIM)スマートカードにも格納される。SIM608は改竄防止となるように設計され,ユーザによって容易に読みだされないデータおよびアルゴリズムを含む。通常,秘密鍵Kiおよび認証アルゴリズムA3およびA8は,ネットワークによる無線経由のサービスを確立するために用いられる。
【0049】
一実施例において,認証鍵に対する要求は,MT606がSIM608から関連する国際移動加入者識別番号(IMSI)600を検索し,それをブートストラッピングサーバ機能(BSF)604に送ることによって開始されるかもしれない。BSF604はIMSI600を,IMSI600がネットワークに加入しているMTに属すかどうかを検証するかもしれないHLR602へ送る。HLR602はMT606内に加入者のSIMが入っている加入者に対するサービスプロバイダによって動作されるかもしれない。HLR602は,例えば,事前共有秘密鍵Kiと共に128ビットのランダムなチャレンジRANDを選択し,それらをそれぞれ署名された32ビットの出力SRESおよび64ビットの出力秘匿性鍵Kcを生ずるための2つのアルゴリズムA3およびA8に対する入力として用いる。次に,HLR602は,SIM608の識別番号IMSI600に対応する三個組(RAND,SRES,Kc)をBSF604へ送る。BSF604は,ランダム秘密の指数xを生成し,ディフィー-ヘルマン公開鍵P^(x)を計算する。ここで,Pは予めBSF604およびMT606の双方に供給された巡回群生成元である。巡回群は有限体の乗法群または楕円曲線の加法群のようなものである。次に,BSF602はMT606へ三個組(RAND,P^(x),SIG)610を送る。ここで,SIGはBSF604のRSAプライベート鍵を用いて計算されたディジタル署名である。メッセージ610は,トランザクション識別子のような他のサーバ認証されたパラメータを含むようにさらに機能強化されるかもしれない。
【0050】
MT606は,三個組(RAND,P^(x),SIG)610を受信し,SIGを検証するためにBSF604のディジタル証明書を用いる。MT606は,BSF604から伝送されたデータを認証することができるようにディジタル証明書を供給されると仮定されている。データがBSFで発せられたと見なされる場合,MT606は乱数yを生成し,P^(y)を計算する。また,MT606はRAND612をSIM608へ送る。SIM608はRANDおよびKiに基づいて生成される1組(SRES,Kc)614をMT606に返す。SIM608が真正である場合,HLR602によって生成したと同じSRESおよびKcを生成するべきである。次にMT606は,SRESおよびKcで鍵を掛けたP^(y)のメッセージ認証符号MACを計算し,応答(P^(y),MAC)616をBSF604へ送る。この応答616は,トランザクション識別子のように,MACが計算されるための他のパラメータを含むようにさらに機能強化されるかもしれない。
【0051】
BSF604は,P^(y)を受信し,HLR602から認証用三個組で受信したSRESとKcを用いてMACを検証する。このMACが正しい場合,BSFは,MT606が正しいSIM608を有していることを検証し,確認メッセージ618をMT606へ送るかもしれない。
【0052】
この実施例において,MT606およびBSF604は,このように相互認証されたディフィー-ヘルマンの鍵交換を実行し,それらがそれぞれ計算する鍵P^(xy)を共有する。次に,さらなる通信のための鍵は,例えば,MTおよびBSF双方に知られている識別情報,RAND,SRES,およびKcのような更なる情報を含むP^(xy)のハッシュとして計算されるかもしれない。SIM608ではなくMT606内でディフィー-ヘルマンの計算が行われるか,または結果として得られる鍵が格納される場合には,この鍵P^(xy)および得られた共有鍵は,MTからSIM608が外される場合,またはMTが異なるSIM608を用いて動作する場合には,削除されるべきである。
【0053】
このプロトコルはMT606がアルゴリズムA5/2をサポートしない場合には,GSMに起因する標準的弱点から保護することに注意のこと。A5/2アルゴリズムは,GSMプロトコルにおいて上記プロトコルを密かに攻撃するかもしれないほぼ瞬時の中断を許している。しかし,A5/2アルゴリズムは3GPPリリース6仕様において段階的に廃止されることになる。
【0054】
プロトコルの攻撃を試みる中間者はSIG故に最初のチャレンジ(RAND,P,SIG)を変えることができず,攻撃するものはそれ自身のP^(z)の挿入または異なるRANDの使用ができないことにさらに注意のこと。これは,これらのメッセージを再実行しかできないかもしれないが,どんな再実行も,一時的ディフィー-ヘルマンを用いるのと同等であるため,それはBSFになりすますことはできない。逆に,BSFが,用いられたRANDがこのプロトコルの1つの使用から次の使用までフレッシュであることを保証し,かつ応答(P^(y),MAC)が短時間の間だけ受信されることを保証する場合,攻撃側には,通常のGSMシナリオにおけるRANDによるチャレンジを行い,鍵を導出するA5/1アルゴリズムを攻撃するような他の手段によって,SRESおよびKcを導出する機会がない。」

(イ)原審拒絶理由に引用された,本願の第1国出願前に既に公知である,特表2009-512296号公報(公表日;2009年3月19日,以下,これを「引用文献2」という)には,関連する図面と共に,次の事項が記載されている。

D.「【0036】
この手順に関連したシグナリング交換が,KS生成シナリオ(すなわち図2に類似)を想定して,図3に示されている。
【0037】
状況次第では値RANDをNAFに明らかにすることは望ましくない場合がある。これは,B-TIDを,実際のRAND値(または実効RAND(RANDe))に対する参照を使用して形成することにより避けることができ,NAFは参照値のみを見るようになる。実効RAND(RANDe)はその場合AUTNと一緒にBSFからクライアントに信号で伝えられなければならないであろう。この修正された手順が図4に説明されている。
【0038】
図3および図4を参照して説明されている解決策の主たる利点は,BSFがクライアントにおける鍵生成を制御する更なる機会を有するであろうということである。クライアントは鍵を得るためにAUTNを必要とする。一方,クライアントはBSFに接続し,Ubインタフェース上でGBAプロトコルの新しい変形を要するBSFに向かって自身を認証しなければならないであろう。
【0039】
図3および図4の解決策に対する1つの脅威は,攻撃者が一群の(有効なB-TIDを含むと主張する)メッセージを生成し,それらを異なるクライアントに送りサービス不能(DoS)攻撃を開始する可能性があるということである。クライアントはメッセージを認証する手段(すなわちAUTN)を有しないので,受信したメッセージを認証しようとしてBSFに接続するであろう。そのような攻撃に対して反撃しない場合,BSF側でかなりの資源を消耗するであろう。そのようなDoS攻撃をさらに困難にするには,クライアントがNAFによりプッシュ配信されたメッセージのMACを直ちに確認し,BSFに接続しなくてもメッセージの正当性を立証することができるようにすることが望ましいであろう。これを達成するために,クライアントはメッセージのMAC化のために使用される鍵を得ることができなければならない。AUTNはプッシュ配信されるメッセージのなかではクライアントに送られないので,この導出はB-TID内のRAND(または派生値,図4)のみに基づかなければならない。
【0040】
1つの解決策はB-TID内のRAND(または派生値)を使用して2つの鍵Ck’およびIk’をBSFで得ることである。それからBSFはこれらの鍵を使用してMAC鍵を得て,MAC鍵をNAFに送る。このインテグリティ鍵はまた,好適にはNAFの識別情報に依存するべきである。NAF鍵をインテグリティ鍵の導出の際に得るために必要とされるその他の必要情報の“フィンガープリント”を使用することは,全ての情報をUEに送らなくてもこれを達成する1つの方法となるであろう。NAFは第2の(短い)MACをクライアントに送られるべき少なくとも一部のデータにわたって計算し,クライアントに送られるメッセージにMACを含める。クライアントで,USIM/ISIMはAKAアルゴリズムを使用してCk’およびIk’およびそれ故第2のMAC鍵を生成し,それからクライアントはメッセージを検証することができる。あるいは,BSFは鍵Ck’およびIk’をNAFに提供することができ,NAFが第2のMAC鍵それ自身を生成できるようにする。これは(タイムスタンプを使用して扱われ得るが)古いメッセージのリプレイを阻止しない,しかし攻撃者がランダムなメッセージを生成するのを阻止する。」

(ウ)原審拒絶理由に引用された,本願の第1国出願前に既に公知である,特開2010-288271号公報(2010年12月24日公開,以下,これを「引用文献3」という)には,関連する図面と共に,次の事項が記載されている。

E.「【0024】
一実施形態によれば,前記変更されたチャレンジは,前記チャレンジに第1の不可逆関数を適用することによって得られるものであり,
前記ネットワークが,より高度化されたものであるか又は高度化されていないものであるかに応じて,前記変更されていないチャレンジ又は前記変更されたチャレンジに基づいて計算される前記鍵は,前記変更されたチャレンジ又は前記変更されたチャレンジから導出される値と前記パラメータとの組み合わせに対して第2の不可逆関数を適用することに基づいて計算されるものである。
【0025】
このようにして,変更されたチャレンジを認証し,第2の不可逆関数を適用するときに識別されるネットワークの情報を含めることによって,モバイル機器を認証することができる。第2の不可逆関数が,変更されたチャレンジに適用されるだけでなく,第2の不可逆関数が,変更されたチャレンジから導出される値に適用される場合には,このメカニズムは,さらに一層セキュアになる。」

F.「【0036】
一実施形態によれば,前記高度化されていないネットワークは,3GPPネットワークであり,
前記チャレンジは,RANDであり,
認証が,前記より高度化されたネットワークに対して行われるべきである場合に,前記変更されたチャレンジを得るために前記チャレンジに適用されるべき前記不可逆関数は,g(RAND)であり,
前記変更されたチャレンジを得た後で前記モバイル機器において認証プロトコルを実行するステップは,
f1をメッセージ認証関数とする,メッセージ認証コードMAC’=f1K(SQN||g(RAND)||AMF),
f2を(おそらくは切り捨てられた)メッセージ認証関数とする,期待応答XRES’=f2K(g(RAND)),
f3を鍵生成関数とする,暗号鍵CK’=f3K(g(RAND)),
f4を鍵生成関数とする,完全鍵IK’=f4K(g(RAND)),
f5を鍵生成関数とする,又はf5≡0とする,匿名鍵AK’=f5K(g(RAND)),
のうちの1つ以上を計算することを含む。」

G.「【0048】
ある実施形態によれば,AとSとの間で使用するための鍵を鍵材料から作成するのに使用される鍵導出関数は,鍵の導出に使用されるチャレンジパラメータのうちの少なくとも1つに対して一方向ハッシュ関数が適用されるように変更され,その後,その結果が,認証を行うために実行される暗号プロトコルに渡される。サプリカントは,認証の要求がよりセキュアなアクセス技術(使用されるネットワーク技術を知らせるシグナリングなど)からのものであるかどうかについて知らされる。チャレンジパラメータが,そのようなよりセキュアなシステム(LTEシステムなど)からのものである場合には,チャレンジ値を暗号プロトコルに渡す前に,一方向ハッシュ関数を適用する。
【0049】
図4で概略的に示されているように,このアプローチは,サプリカント(モバイル機器)が2つの部分,すなわち,レガシ部分(USIM又はUICC(汎用ICカード)H/W)と,変更可能部分CP(モバイル端末,S/W)とを有する場合に適用することができる。典型的には,ロング・ターム鍵は,レガシ部分に記憶され,また鍵の導出もレガシ部分において行われる。そのような場合の認証パラメータは,ユーザ端末に送られる。そのユーザ端末では,認証パラメータは,変更可能部分CPに届き,変更可能部分CPでは,認証のための暗号プロトコルが実行されるレガシ部分LPに渡す前に,認証パラメータにハッシュ関数(又は不可逆関数)が適用される。
【0050】
より具体的な実施形態,すなわち,3GPP/AKAの環境において,そのようなメカニズムは,認証プロトコルを実行することによる他の全てのパラメータの計算のためにランダム・チャレンジRANDがUSIMに与えられる前に,モバイル端末(ME)がランダム・チャレンジRANDに一方向ハッシュ関数を適用することを含む。認証ベクトルに含まれる値(MEに送られる値)は,ランダム・チャレンジRANDである。認証の要求がLTEによってもたらされる場合(ネットワーク型によって暗黙的に知らされる),MEは,その認証ベクトルをUSIMに渡す前に,まず,チャレンジRANDにハッシュ関数又は任意の不可逆関数g(.)を適用する。また,アクセス技術はUMTSであり,少なくともMEのレガシ部分(USIM)によって行われる認証及び鍵交換AKAは,変更せずに実行することができる。」

ウ.引用文献1に記載の発明
(ア)上記Bの「図1は1実施態様に従ってブートストラッピングサーバおよびレガシー移動端末が互いを相互認証できる通信システムを示すブロック図である。GSM準拠の,または,CDMA2000準拠の通信システムのようなネットワークアーキテクチャ100は移動端末(MT)102,ホームロケーションレジスタ(HLR)104,ブートストラッピングサーバ機能(BSF)106,および少なくとも1つのネットワークアプリケーション機能(NAF)108を含む」という記載,同じく,上記Bの「MT102はネットワーク100上で通信するために,予め定義されたプロトコル(例えば,3Gより前のプロトコル)を用いてサービスプロバイダに登録するかまたは接続するレガシー無線通信装置であるかもしれない」という記載,及び,同じく,上記Bの「MT102がネットワークアプリケーションの使用を始める準備ができている場合,それは通信リンク110を通じてNAF108との接続を開始する。MTとNAFが適切な鍵をまだ共有していない場合,NAF108はインターフェース112を通じてBSF106へ認証鍵を要求する。未だそうしていない場合,MT102とBSF106は,認証リンク114上でMT102と鍵を共有する」という記載から,引用文献1には,
“ネットワーク上で,ブートストラッピングサーバ機能(BSF)と通信する,移動端末(MT)”が記載されていることが読み取れる。

(イ)上記Cの「図6に,1つの実施態様に従って,ネットワークアプリケーション機能に対して相互に安全に認証するために,GSM準拠の移動端末608およびブートストラッピングサーバ機能604間でチャレンジ-応答プロトコルを実行する方法を示す」という記載,同じく,上記Cの「HLR602は,例えば,事前共有秘密鍵Kiと共に128ビットのランダムなチャレンジRANDを選択し,それらをそれぞれ署名された32ビットの出力SRESおよび64ビットの出力秘匿性鍵Kcを生ずるための2つのアルゴリズムA3およびA8に対する入力として用いる。次に,HLR602は,SIM608の識別番号IMSI600に対応する三個組(RAND,SRES,Kc)をBSF604へ送る。BSF604は,ランダム秘密の指数xを生成し,ディフィー-ヘルマン公開鍵P^(x)を計算する。ここで,Pは予めBSF604およびMT606の双方に供給された巡回群生成元である。巡回群は有限体の乗法群または楕円曲線の加法群のようなものである。次に,BSF602はMT606へ三個組(RAND,P^(x),SIG)610を送る。ここで,SIGはBSF604のRSAプライベート鍵を用いて計算されたディジタル署名である」という記載,及び,同じく,上記Cの「MT606は,三個組(RAND,P^(x),SIG)610を受信し」という記載と上記(ア)において検討した事項から,引用文献1においては,
“MTは,チャレンジRAND,ディフィー-ヘルマン公開鍵P^(x),BSFのRSAプライベート鍵を用いて計算されたディジタル署名であるSIGを,BSFから受信する”ものであることが読み取れる。

(ウ)上記Cの「SIGを検証するためにBSF604のディジタル証明書を用いる。MT606は,BSF604から伝送されたデータを認証することができるようにディジタル証明書を供給されると仮定されている。データがBSFで発せられたと見なされる場合」という記載から,引用文献1においては,
“MTは,BSFから受信したSIGを,前記BSFからのディジタル証明書を用いて検証し,前記SIGは正当である場合に,伝送されたデータが前記BSFより送信されたと判断する”ものであるであることが読み取れる。

(エ)上記Cの「HLR/AuCおよびSIMは,既存の秘密鍵KiおよびGSMアルゴリズムA3およびA8に基づいて同様の計算を実行する。GSMプロトコルにおいて,秘密鍵Ki並びに認証アルゴリズムA3およびA8はネットワークHLR602と同様に,加入者識別モジュール(SIM)スマートカードにも格納される」という記載,及び,同じく,上記Cの「MT606は乱数yを生成し,P^(y)を計算する。また,MT606はRAND612をSIM608へ送る。SIM608はRANDおよびKiに基づいて生成される1組(SRES,Kc)614をMT606に返す。SIM608が真正である場合,HLR602によって生成したと同じSRESおよびKcを生成するべきである。次にMT606は,SRESおよびKcで鍵を掛けたP^(y)のメッセージ認証符号MACを計算し,応答(P^(y),MAC)616をBSF604へ送る」という記載と,上記(イ)において検討した事項から,引用文献1においては,
“MTは,チャレンジRANDを,SIMに送信し,前記SIMは,前記チャレンジRANDと,前記SIMに格納されている秘密鍵Kiに基づいて(SRES,Kc)の組を生成し,前記組を前記MTに返送し,前記MTは,乱数yを生成し,ディフィー-ヘルマン公開鍵をP^(y)を計算し,前記SRESおよび前記Kcで鍵を掛けた前記P^(y)メッセージ認証符号MACを計算し,応答(P^(y),MAC)を,BSFへ送信する”ものであることが読み取れる。

(オ)以上,上記(ア)?(エ)において検討した事項から,引用文献1には,次の発明(以下,これを「引用発明」という)が,記載されているものと認める。

「ネットワーク上で,ブートストラッピングサーバ機能(BSF)と通信する,移動端末(MT)であって,
前記MTは,チャレンジRAND,ディフィー-ヘルマン公開鍵P^(x),前記BSFのRSAプライベート鍵を用いて計算されたディジタル署名であるSIGを,前記BSFから受信し,
前記MTは,前記BSFから受信した前記SIGを,前記BSFからのディジタル証明書を用いて検証し,前記SIGは正当である場合に,伝送されたデータが前記BSFより送信されたと判断し,
前記MTは,前記チャレンジRANDを,SIMに送信し,前記SIMは,前記チャレンジRANDと,前記SIMに格納されている秘密鍵Kiに基づいて(SRES,Kc)の組を生成し,前記組を前記MTに返送し,前記MTは,乱数yを生成し,ディフィー-ヘルマン公開鍵P^(y)を計算し,前記SRESおよび前記Kcで鍵を掛けた前記P^(y)のメッセージ認証符号MACを計算し,応答(P^(y),MAC)を,前記BSFへ送信する,移動端末(MT)。」

エ.本件補正発明と引用発明との対比
(ア)引用発明における「ネットワーク」,「ブートストラッピングサーバ機能(BSF)」,「移動端末(MT)」,及び,「チャレンジRAND」が,それぞれ,
本件補正発明における「通信ネットワーク(36)」,「ネットワークデバイス(44)」,「通信デバイス」,及び,「チャレンジ(RAND)」に相当するので,
引用発明における「ネットワーク上で,ブートストラッピングサーバ機能(BSF)と通信する,移動端末(MT)であって」が,
本件補正発明における「通信ネットワーク(36)のネットワークデバイス(44)と通信するための通信デバイス(40)であって」に相当する。

(イ)引用発明において,「MT」が,「BSF」から受信する「SIG」は,自身が正当であることが示されることによって,当該「SIG」と共に「BSF」から受信する,「チャレンジRAND」,及び,「ディフィー-ヘルマン公開鍵P^(x)」が正当であることも示すことになるものであるから,
本件補正発明における「第1の検証コード(VC_(1);VC_(1)A;VC_(1)B)」と,
“認証で用いるデータの正当性を示す情報”である点で共通する。
また,前記「ディフィー-ヘルマン公開鍵P^(x)」と,
本件補正発明における「第1のPFSパラメータ(PFS_(1))」とは,
“受信データ”である点で共通する。
したがって,引用発明における「MTは,チャレンジRAND,ディフィー-ヘルマン公開鍵P^(x),前記BSFのRSAプライベート鍵を用いて計算されたディジタル署名であるSIGを,前記BSFから受信し」と,
本件補正発明における「チャレンジ(RAND),第1のPFSパラメータ(PFS_(1)),及び前記第1のPFSパラメータ(PFS_(1))についての第1の検証コード(VC_(1);VC_(1)A;VC_(1)B)を前記ネットワークデバイス(44)から受信し,前記第1の検証コード(VC_(1)A;VC_(1)B)は,少なくとも前記第1のPFSパラメータに基づくメッセージ認証コードを含み」とは,
“チャレンジ(RAND),受信データ,及び受信データの正当性を示す情報を,ネットワークデバイス(44)から受信”するものである点で共通する。

(ウ)引用発明における「SIM」と,
本件補正発明における「USIM」とは,
“加入者を特定するためのIDが記録されたICカード”である点で共通し,
引用発明における「チャレンジRAND」と,
本件補正発明における「チャレンジの派生」とは,
“チャレンジに関するデータ”である点で共通し,
引用発明における「(SRES,Kc)」と,
本件補正発明における「結果パラメータ(CK/IK,RES)」とは,
“加入者を特定するためのIDが記録されたICカードから応答として受信する,応答データ”である点で共通するので,
引用発明における「MTは,前記チャレンジRANDを,SIMに送信し」と,
本件補正発明における「前記チャレンジの派生をUSIM(48)へ転送し」とは,
“チャレンジに関するデータを,加入者を特定するためのIDが記録されたICカードに転送する”点で共通する。

(エ)引用発明における「前記SIMは,前記チャレンジRANDと,前記SIMに格納されている秘密鍵Kiに基づいて(SRES,Kc)の組を生成し,前記組を前記MTに返送し」と,
本件補正発明における「少なくとも1つの結果パラメータ(CK/IK,RES)を,前記USIM(48)からの応答として受信し」とは,
“少なくとも1つの応答データを,加入者を特定するためのIDが記録されたICカードから応答として受信する”点で共通する。

(オ)引用発明における「MTは,前記BSFから受信した前記SIGを,前記BSFからのディジタル証明書を用いて検証し,前記SIGは正当である場合に,伝送されたデータが前記BSFより送信されたと判断」することと,
本件補正発明における「結果パラメータ(CK/IK,RES)に基づいて,前記第1のPFSパラメータ(PFS_(1))が真正であるかを判定」することとは,
“ネットワークデバイス(44)から受信したデータが真正であるかを判定する”ことである点で共通する。

(カ)引用発明において,「MT」が,「乱数yを生成し,ディフィー-ヘルマン公開鍵P^(y)を計算し,前記SRESおよび前記Kcで鍵を掛けた前記P^(y)のメッセージ認証符号MACを計算し,応答(P^(y),MAC)を,前記BSFへ送信する」ことは,上記(イ)において指摘した「SIG」が正当である場合に,実施されるものであることは明らかであって,
引用発明における「ディフィー-ヘルマン公開鍵P^(y)」は,それを用いることによって,「メッセージ認証符号MAC」が生成されることから,「BSF」側で認証に用いられるデータであるから,
引用発明における「ディフィー-ヘルマン公開鍵P^(y)」は,
本件補正発明における「第2のPFSパラメータ(PFS_(2))」に相当するので,
引用発明における「MTは,乱数yを生成し,ディフィー-ヘルマン公開鍵P^(y)を計算し,前記SRESおよび前記Kcで鍵を掛けた前記P^(y)のメッセージ認証MACを計算し,応答(P^(y),MAC)を,前記BSFへ送信する」ことと,
本件補正発明における「判定において前記第1のPFSパラメータ(PFS_(1))が真正である場合に,第2のPFSパラメータ(PFS_(2))を生成し及び前記ネットワークデバイスへ送信する」こととは,
“ネットワークデバイス(44)から受信したデータが正当である場合に,第2のPFSパラメータ(PFS_(2))を生成し及び前記ネットワークデバイスへ送信する”点で共通する。

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

[一致点]
通信ネットワーク(36)のネットワークデバイス(44)と通信するための通信デバイス(40)であって,
チャレンジ(RAND),受信データ,及び受信データの正当性を示す情報を,前記ネットワークデバイス(44)から受信し,
前記チャレンジに関するデータを,加入者を特定するためのIDが記録されたICカードに転送し,
少なくとも1つの応答データを,前記加入者を特定するためのIDが記録されたICカードから応答として受信し,
前記ネットワークデバイス(44)から受信したデータが真正であるかを判定し,
前記ネットワークデバイス(44)から受信したデータが正当である場合に,第2のPFSパラメータ(PFS_(2))を生成し及び前記ネットワークデバイスへ送信する,
ように動作可能な通信デバイス(40)。

[相違点1]
“受信データ”に関して,
本件補正発明においては,「第1のPFSパラメータ(PFS_(1))」であるのに対して,
引用発明においては,「ディフィー-ヘルマン公開鍵P^(x)」である点。

[相違点2]
“受信データの正当性を示す情報”に関して,
本件補正発明においては,「第1のPFSパラメータ(PFS_(1))についての第1の検証コード(VC_(1);VC_(1)A;VC_(1)B)」であって,「第1の検証コード(VC_(1)A;VC_(1)B)は,少なくとも前記第1のPFSパラメータに基づくメッセージ認証コードを含」むものであるのに対して,
引用発明においては,「BSFのRSAプライベート鍵を用いて計算されたディジタル署名であるSIG」である点。

[相違点3]
“チャレンジに関するデータ”に関して,
本件補正発明においては,「チャレンジの派生」であるのに対して,
引用発明においては,「チャレンジ(RAND)」,即ち,「チャレンジ」そのものである点。

[相違点4]
“少なくとも1つの応答データ”に関して,
本件補正発明においては,「少なくとも1つの結果パラメータ(CK/IK,RES)」であるのに対して,
引用発明においては,「(SRES,Kc)の組」である点。

[相違点5]
“受信したデータが真正であるかを判定し”に関して,
本件補正発明においては,「結果パラメータ(CK/IK,RES)に基づいて,前記第1のPFSパラメータ(PFS_(1))が真正であるかを判定」するものであるのに対して,
引用発明においては,「SIG」の正当性の判定である点。

[相違点6]
本件補正発明においては,「USIM」を用いているのに対して,
引用発明においては,「SIM」を用いている点。

オ.相違点についての当審の判断
(ア)[相違点1],[相違点2],及び,[相違点6]について
上記「ウ.引用文献1に記載の発明」の(エ)において引用した,上記Cの記載,及び,上記Cの「BSF604は,P^(y)を受信し,HLR602から認証用三個組で受信したSRESとKcを用いてMACを検証する。このMACが正しい場合,BSFは,MT606が正しいSIM608を有していることを検証」という記載から,引用発明においても,「MT」側の「SIM」が生成する「SRES」と,「Kc」を用いて「P^(y)」の「メッセージ認証符号MAC」を生成し,「MSF」が,受信した「P^(y)」,「MAC」と,当該「MSF」が有する「SRES」と,「Kc」から,受信した「MAC」を検証することが示されていて,このことは,「BSF」が,「MT」に送信する「P^(x)」について,「BSF」側で,当該「P^(x)」についての「MAC」を生成した場合,当該「MAC」を,「MT」側で検証し得るものであることは,明らかである。
そして,「USIM」において生成される値を用いて,クライアント(UE)(本件補正発明における「通信デバイス(40)」に相当)において,「BSF」から送信された「MAC」を検証し得ることは,上記Dに引用した,引用文献2の「クライアントで,USIM/ISIMはAKAアルゴリズムを使用してCk’およびIk’およびそれ故第2のMAC鍵を生成し,それからクライアントはメッセージを検証することができる」という記載にもあるとおり,本願の第1国出願前に,当業者には,広く知られた技術事項である。
そして,引用発明は,上記Aに引用した,引用文献1の「開発中の手法は,GSMなどの2Gまたはより初期のレガシーシステムに比較して固有のセキュリティが改良されたUMTSのユニバーサル加入者識別モジュール(USIM)でサポートされるような3Gの認証と鍵共有法に頼っている」(段落【0006】)という記載,及び,「3Gネットワークに対して指定された汎用認証アーキテクチャ(GAA)がレガシーシステム(例えば,2Gまたはそれ以前のシステム)をサポートするように拡張されるかもしれない手法を確立する必要がある」(段落【0008】)という記載から明らかなように,“2Gまたはそれ以前のシステムをサポートする3G以降のシステム”に関するものである。即ち,引用発明は,上記に引用の引用文献2に開示の技術事項を含み得るものである。
以上に検討したことから,引用発明においても,「BSF」が「P^(x)」(本件補正発明における「第1のPFSパラメータ(PFS_(1))」に対応)と,当該「P^(x)」を認証するための「MAC」(本件補正発明における「第1の検証コード(VC_(1);VC_(1)A;VC_(1)B)」に対応)とを「MT」に送信し,当該「P^(x)」と共に,「MT」へ送信し,当該「MT」において,「SIM」の生成する値と,当該「P^(x)」([相違点1]に対応),「MAC」([相違点2]に対応)から,当該「P^(x)」を認証するよう構成することは,当業者が適宜なし得る事項である。
よって,[相違点1],及び,[相違点2]は,格別のものではない。

(イ)[相違点3]について
引用文献3の,上記Eに引用した記載中に,「一実施形態によれば,前記変更されたチャレンジは,前記チャレンジに第1の不可逆関数を適用することによって得られる」(段落【0024】),「変更されたチャレンジを認証し,第2の不可逆関数を適用するときに識別されるネットワークの情報を含めることによって,モバイル機器を認証することができる」(段落【0025】),上記Fに引用した記載中に,「一実施形態によれば,前記高度化されていないネットワークは,3GPPネットワークであり,前記チャレンジは,RANDであり,認証が,前記より高度化されたネットワークに対して行われるべきである場合に,前記変更されたチャレンジを得るために前記チャレンジに適用されるべき前記不可逆関数は,g(RAND)であり」,上記Gに引用した記載中に,「チャレンジパラメータが,そのようなよりセキュアなシステム(LTEシステムなど)からのものである場合には,チャレンジ値を暗号プロトコルに渡す前に,一方向ハッシュ関数を適用する」(段落【0048】),「3GPP/AKAの環境において,そのようなメカニズムは,認証プロトコルを実行することによる他の全てのパラメータの計算のためにランダム・チャレンジRANDがUSIMに与えられる前に,モバイル端末(ME)がランダム・チャレンジRANDに一方向ハッシュ関数を適用することを含む。認証ベクトルに含まれる値(MEに送られる値)は,ランダム・チャレンジRANDである」(段落【0050】)とあるように,“チャレンジRANDが,USIMに与えられる前に,変更されたチャレンジ(本件補正発明における「チャレンジの派生」に相当)に変換される”構成は,本願の第1国出願前に,当業者には広く知られた技術事項である。
そして,上記Aの「ネットワーク認証のためにUMTSユーザサービス識別モジュール(USIM)を用いる移動加入者は,GSM加入者識別モジュール(SIM)のユーザに対して加えられる攻撃の影響を受けにくい」(段落【0004】)という記載,及び,上記(ア)において引用した上記Aの記載内容から,引用発明は,「USIM」を用いる「UMTS」の環境下で,「SIM」を用いる「GSM」の環境への下位互換の機能を提供することを目的とするものであるから,引用発明自体が「UMTS」の環境に対応していることは,明らかである。
したがって,引用発明においても,「チャレンジRAND」に所定の演算を施して,「変更されたチャレンジ」を生成して用いるようにすることは,当業者が適宜なし得る事項である。
よって,[相違点3]は,格別のものではない。

(ウ)[相違点4],及び,[相違点5]について
上記(ア)において引用した,引用文献2の記載内容と,上記Eに引用した,引用文献3の「f1をメッセージ認証関数とする,メッセージ認証コードMAC’=f1K(SQN||g(RAND)||AMF),
f2を(おそらくは切り捨てられた)メッセージ認証関数とする,期待応答XRES’=f2K(g(RAND)),
f3を鍵生成関数とする,暗号鍵CK’=f3K(g(RAND)),
f4を鍵生成関数とする,完全鍵IK’=f4K(g(RAND))」という記載から,“USIMにおいて,CK’/IK’(本件補正発明における「CK/IK」に相当),及び,XRES’(本件補正発明における「RES」に相当)を生成する”ことは,本願の第1国出願前に,当業者には広く知られた技術事項である。
そして,上記(ア),及び,上記(イ)において指摘したとおり,引用発明は,「USIM」を採用する構成を含み得るものであるから,
上記(ア)において検討した,「MT」側における,「BSF」から送信された「データ」に対する認証において,「USIM」において「RAND」を用いて生成される「CK’/IK’」,及び,「XRES’」を「MT」が受け取って([相違点4]に対応),「MT」において,当該「データ」の認証を行う(「相違点5」に対応)ように構成することは,当業者が適宜なし得る事項である。
よって,[相違点4],及び,[相違点5]は,格別のものではない。

(エ)以上,上記(ア)?上記(ウ)において検討したとおりであるから,[相違点1]?[相違点5]は,格別のものではなく,本件補正発明の構成によってもたらされる効果も,当業者であれば当然に予測可能なものに過ぎず格別なものとは認められない。
よって,本件補正発明は,引用発明,及び,引用文献2,引用文献3に記載の技術事項に基づいて当業者が容易に発明をすることができたものであるので,特許法29条2項の規定により,特許出願の際,独立して特許を受けることができない。

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

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

第3.本願発明について
令和1年5月13日付けの手続補正は,上記のとおり却下されたので,本願の請求項1に係る発明(以下,これを「本願発明」という)は,平成30年9月10日付けの手続補正により補正された特許請求の範囲の請求項1に記載された,上記「第2.令和1年5月13日付けの手続補正の却下の決定」の「1.補正の内容」において,補正前の請求項1として引用した,次のとおりのものである。

「通信ネットワーク(36)のネットワークデバイス(44)と通信するための通信デバイス(40)であって,
チャレンジ(RAND),第1のPFSパラメータ(PFS_(1)),及び前記第1のPFSパラメータ(PFS_(1))についての第1の検証コード(VC_(1);VC_(1)A;VC_(1)B)を前記ネットワークデバイス(44)から受信し,
前記チャレンジの派生をUSIM(48)へ転送し,
少なくとも1つの結果パラメータ(CK/IK,RES)を,前記USIM(48)からの応答として受信し,
前記結果パラメータ(CK/IK,RES)に基づいて,前記第1のPFSパラメータ(PFS1)が真正であるかを判定し,
前記判定において前記第1のPFSパラメータ(PFS_(1))が真正である場合に,第2のPFSパラメータ(PFS_(2))を生成し及び前記ネットワークデバイスへ送信する,
ように動作可能な通信デバイス(40)。」

第4.引用文献に記載の発明
上記「第2.令和1年5月13日付けの手続補正の却下の決定」の「2.補正の適否」の「(2)独立特許要件」における「イ.引用文献に記載の事項」の(ア)において,引用文献1として引用した,本願の第1国出願前に既に公知である,特表2008-530681号公報(公表日;2008年8月7日)には,上記「第2.令和1年5月13日付けの手続補正の却下の決定」の「2.補正の適否」の「(2)独立特許要件」における「ウ.引用文献1に記載の発明」において検討したとおりの,次の引用発明が記載されているものと認める。

「ネットワーク上で,ブートストラッピングサーバ機能(BSF)と通信する,移動端末(MT)であって,
前記MTは,チャレンジRAND,ディフィー-ヘルマン公開鍵P^(x),前記BSFのRSAプライベート鍵を用いて計算されたディジタル署名であるSIGを,前記BSFから受信し,
前記MTは,前記BSFから受信した前記SIGを,前記BSFからのディジタル証明書を用いて検証し,前記SIGは正当である場合に,伝送されたデータが前記BSFより送信されたと判断し,
前記MTは,前記チャレンジRANDを,SIMに送信し,前記SIMは,前記チャレンジRANDと,前記SIMに格納されている秘密鍵Kiに基づいて(SRES,Kc)の組を生成し,前記組を前記MTに返送し,前記MTは,乱数yを生成し,ディフィー-ヘルマン公開鍵P^(y)を計算し,前記SRESおよび前記Kcで鍵を掛けた前記P^(y)のメッセージ認証符号MACを計算し,応答(P^(y),MAC)を,前記BSFへ送信する,移動端末(MT)。」

第5.本願発明と引用発明との対比
本願発明は,本件補正発明から,発明特定事項である「第1の検証コード(VC_(1)A;VC_(1)B)」に対する限定事項である,「少なくとも前記第1のPFSパラメータに基づくメッセージ認証コードを含」むという構成を取り除いたものであるから,
本願発明と,引用発明との,一致点,及び,相違点は,次のとおりである。

[一致点]
通信ネットワーク(36)のネットワークデバイス(44)と通信するための通信デバイス(40)であって,
チャレンジ(RAND),受信データ,及び受信データの正当性を示す情報を,前記ネットワークデバイス(44)から受信し,
前記チャレンジに関するデータを,加入者を特定するためのIDが記録されたICカードに転送し,
少なくとも1つの応答データを,前記加入者を特定するためのIDが記録されたICカードから応答として受信し,
前記ネットワークデバイス(44)から受信したデータが真正であるかを判定し,
前記ネットワークデバイス(44)から受信したデータが正当である場合に,第2のPFSパラメータ(PFS_(2))を生成し及び前記ネットワークデバイスへ送信する,
ように動作可能な通信デバイス(40)。

[相違点a]
“受信データ”に関して,
本願発明においては,「第1のPFSパラメータ(PFS_(1))」であるのに対して,
引用発明においては,「ディフィー-ヘルマン公開鍵P^(x)」である点。

[相違点b]
“受信データの正当性を示す情報”に関して,
本願発明においては,「第1のPFSパラメータ(PFS_(1))についての第1の検証コード(VC_(1);VC_(1)A;VC_(1)B)」であるのに対して,
引用発明においては,「BSFのRSAプライベート鍵を用いて計算されたディジタル署名であるSIG」である点。

[相違点c]
“チャレンジに関するデータ”に関して,
本件補正発明においては,「チャレンジの派生」であるのに対して,
引用発明においては,「チャレンジ(RAND)」,即ち,「チャレンジ」そのものである点。

[相違点d]
“少なくとも1つの応答データ”に関して,
本願発明においては,「少なくとも1つの結果パラメータ(CK/IK,RES)」であるのに対して,
引用発明においては,「(SRES,Kc)の組」である点。

[相違点e]
“受信したデータが真正であるかを判定し”に関して,
本願発明においては,「結果パラメータ(CK/IK,RES)に基づいて,前記第1のPFSパラメータ(PFS_(1))が真正であるかを判定」するものであるのに対して,
引用発明においては,「SIG」の正当性の判定である点。

[相違点f]
本願発明においては,「USIM」を用いているのに対して,
引用発明においては,「SIM」を用いている点。

第6.相違点についての当審の判断
本願発明と,引用発明との[相違点a],[相違点c]?[相違点f]は,それぞれ,本件補正発明と,引用発明との[相違点1],[相違点3]?[相違点6]と同じものであるから,上記「第2.令和1年5月13日付けの手続補正の却下の決定」の「2.補正の適否」の「(2)独立特許要件」における「オ.相違点についての当審の判断」において検討したとおり,格別のものではなく,本願発明と,引用発明との[相違点b]は,本件補正発明と,引用発明との[相違点2]と比較すると,「第1のPFSパラメータに基づくメッセージ認証コードを含」むという構成がない点で,相違の度合いが少ないものであるから,同様に,上記「第2.令和1年5月13日付けの手続補正の却下の決定」の「2.補正の適否」の「(2)独立特許要件」における「オ.相違点についての当審の判断」において検討したとおり,格別のものではない。
そして,本願発明本願発明の構成によってもたらされる効果も,当業者であれば当然に予測可能なものに過ぎず格別なものとは認められない。

第7.むすび
したがって,本願発明は,引用発明,及び,引用文献2,引用文献3に記載された技術事項に基づいて当業者が容易に発明をすることができたものであるので,特許法29条2項の規定により特許を受けることができない。

よって,結論のとおり審決する。
 
別掲
 
審理終結日 2020-02-07 
結審通知日 2020-02-10 
審決日 2020-02-28 
出願番号 特願2017-545344(P2017-545344)
審決分類 P 1 8・ 121- Z (H04L)
P 1 8・ 575- Z (H04L)
最終処分 不成立  
前審関与審査官 中里 裕正  
特許庁審判長 田中 秀人
特許庁審判官 石井 茂和
山崎 慎一
発明の名称 通信デバイスとネットワークデバイスとの間の通信におけるセキュリティ構成  
代理人 下山 治  
代理人 大塚 康徳  
代理人 高柳 司郎  
代理人 大塚 康弘  
代理人 木村 秀二  
代理人 大戸 隆広  

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