• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 4項4号特許請求の範囲における明りょうでない記載の釈明 特許、登録しない。 H04L
審判 査定不服 特17条の2、3項新規事項追加の補正 特許、登録しない。 H04L
審判 査定不服 4号2号請求項の限定的減縮 特許、登録しない。 H04L
審判 査定不服 特36条4項詳細な説明の記載不備 特許、登録しない。 H04L
審判 査定不服 2項進歩性 特許、登録しない。 H04L
審判 査定不服 5項独立特許用件 特許、登録しない。 H04L
管理番号 1279237
審判番号 不服2011-19024  
総通号数 167 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2013-11-29 
種別 拒絶査定不服の審決 
審判請求日 2011-09-05 
確定日 2013-09-11 
事件の表示 特願2008-505973「GAAのための汎用鍵の決定メカニズム」拒絶査定不服審判事件〔平成18年10月19日国際公開、WO2006/109122、平成20年10月23日国内公表、特表2008-538471〕について、次のとおり審決する。 
結論 本件審判の請求は、成り立たない。 
理由 第1.手続の経緯等

1.手続の経緯の概要
本願は、
2005年4月11日(以下「優先日」と記す。)のアメリカ合衆国での出願を基礎とするパリ条約に基づく優先権主張を伴って、
2006年4月4日に国際出願された出願であって、
平成19年10月10日付けで特許法第184条の5第1項の規定による書面が提出され、
平成19年12月10日付けで特許法第184条の4第1項の規定による翻訳文が提出されるとともに、同日付けで審査請求がなされ、
平成22年11月26日付けで拒絶理由通知(平成22年12月7日発送)がなされ、
平成23年3月7日付けで意見書が提出されるとともに、同日付けで手続補正書が提出され、
平成23年5月17日付けで拒絶査定(平成23年5月24日発送)がなされ、
平成23年9月5日付けで審判請求がされるとともに、同日付けで手続補正書が提出されたものである。

なお、
平成23年9月29日付けで特許法第164条第3項に定める報告(前置報告)がなされ、
平成23年12月22日付けで当該報告に対する意見を求める旨の審尋(平成24年1月10日発送)がなされ、これに対して
平成24年4月5日付けで回答書が提出されている。


2.補正の内容
(1)平成23年3月7日付け手続補正
上記平成23年3月7日付けの手続補正書は特許請求の範囲を以下のとおりに補正するものである。
「 【請求項1】
受信ユニットと、決定ユニットと、提供ユニットと、を含む装置によって実現される、ネットワーク・アプリケーション・サーバのための汎用メカニズムを提供する方法であって、
ネットワーク・アプリケーション機能に認証情報を提供するようにユーザ機器からの要求を前記受信ユニットにより受信するステップと、
ユーザ・セキュリティ設定を用いて汎用認証アーキテクチャのネットワーク・アプリケーション機能鍵を前記決定ユニットにより決定するステップと、
前記ネットワーク・アプリケーション機能に認証情報を前記提供ユニットにより提供するステップと、を含む方法。
【請求項2】
前記提供ステップは、前記ユーザ・セキュリティ設定におけるユーザ機器のスマートカードのタイプまたはセキュリティ環境に関連するデータを提供し、
ユニバーサル・モバイル・テレコミュニケーション・システム集積回路カード(UICC)に基づいて強化された汎用ブートストラッピング・アーキテクチャ(GBA_U)が、汎用加入者識別モジュール、加入者識別モジュール、インターネットプロトコル・マルチメディア・サブシステム、加入者識別モジュール(IMS SIM)カード、又は、別のセキュア環境を実施可能にするか否かを示すフラグ・フィールドを提供することを含む、請求項1に記載の方法。
【請求項3】
前記提供ステップは、認証情報の認証ヘッダ中で送られるユーザ・セキュリティ設定における第1及び第2フラグ・フィールドを提供することを含み、
前記第1フラグ・フィールドにおいては、ユニバーサル・モバイル・テレコミュニケーション・システム集積回路カード(UICC)に基づいて強化された汎用ブートストラッピング・アーキテクチャ(GBA_U)における第1導出鍵(Ks_int_NAF)が使用され、
前記第2フラグ・フィールドにおいては、第2導出鍵(Ks_ext_NAF)または第3導出鍵(Ks_NAF)が使用される、請求項1に記載の方法。
【請求項4】
前記決定ステップは、
ネットワーク・アプリケーション機能の設定の間に、前記ネットワーク・アプリケーション機能に直接、局所的に鍵の使用法を設定することと、
ブートストラッピング・サーバ機能に直接、局所的に鍵の使用法を設定することの、少なくとも一方を決定することと、
ブートストラッピング・サーバ機能に送られるホーム加入者サーバに格納されたユーザ・セキュリティ設定に追加のフィールドを使用することと、
鍵の使用法を示すブートストラッピング・サーバ機能に格納された属性値ペアを用いることと、を含む、請求項1に記載の方法。
【請求項5】
使用される導出鍵のタイプ、あるいは、スマートカードまたは実現可能なセキュア環境のタイプを示す属性値ペアを使用し、
前記導出鍵のタイプは、Ks_int_NAF、Ks_ext_NAFまたはKs_NAFを含み、
前記スマートカードまたはセキュア環境はGBA_Uにより構成される、請求項4に記載の方法。
【請求項6】
前記属性値ペアがKs_int_NAFの使用を示す場合は、前記決定ステップは、セキュリティ・レベルがより低い鍵が使用されないように、前記ネットワーク・アプリケーション機能によるKs_int_NAFの使用を要求することを含む、請求項5に記載の方法。
【請求項7】
ウェブ・サーバがセキュア環境にある場合は、前記決定するステップは、ネットワーク・アプリケーションをユニバーサル・モバイル・テレコミュニケーション・システム(UMTS)集積回路カード(UICC)にさらに配置することを更に含み、
前記UICCは前記ネットワーク・アプリケーション機能であり、
生成された鍵(Ks_int_NAF)は、ウェブ・サービス事業体間の通信の保護のために使用される、請求項2に記載の方法。
【請求項8】
前記ネットワーク・アプリケーションを配置する前記配置ステップは、ジャバ・アプリケーション、XMLアプリケーション、C++アプリケーション、パール・アプリケーション、またはビジュアル・ベーシック・アプリケーションを含む、請求項7に記載の方法。
【請求項9】
ホーム加入者サーバ(HSS)に格納されたユーザ・セキュリティ設定に追加のフィールドを提供することにより、ブートストラッピング・サーバ機能(BSF)に局所的に鍵の使用法を前記装置により設定するステップを更に含む請求項1に記載の方法。
【請求項10】
ネットワーク・アプリケーション・サーバのための汎用メカニズムを提供する装置であって、
ネットワーク・アプリケーション機能に認証情報を提供するようにユーザ機器からの要求を受信する受信手段と、
ユーザ・セキュリティ設定を用いて汎用認証アーキテクチャのネットワーク・アプリケーション機能鍵を決定する決定手段と、
前記ネットワーク・アプリケーション機能に認証情報を提供する第1提供手段と、を備える装置。
【請求項11】
ユーザ・セキュリティ設定においてユーザ機器のセキュア環境のタイプを提供する第2提供手段と、
ユニバーサル・モバイル・テレコミュニケーション・システム集積回路カード(UICC)に基づいて強化された汎用ブートストラッピング・アーキテクチャ(GBA_U)が、汎用加入者識別モジュール、加入者識別モジュール、セキュア環境あるいはIMS SIMカードを実施可能にするか否かを示すフラグ・フィールドを提供する第3提供手段と、をさらに備える請求項10に記載の装置。
【請求項12】
認証情報の認証ヘッダ中で送られるユーザ・セキュリティ設定内の第1及び第2フラグ・フィールドを提供する第2提供手段をさらに備え、
前記第1フラグ・フィールドにおいては、ユニバーサル・モバイル・テレコミュニケーション・システム集積回路カード(UICC)に基づいて強化された汎用ブートストラッピング・アーキテクチャ(GBA_U)における第1導出鍵(Ks_int_NAF)が使用され、
前記第2フラグ・フィールドにおいては、第2導出鍵(Ks_ext_NAF)または第3導出鍵(Ks_NAF)が使用される、請求項10に記載の装置。
【請求項13】
前記汎用メカニズムは、
ネットワーク・アプリケーション機能の設定の間に、前記ネットワーク・アプリケーション機能に直接、局所的に鍵の使用法を設定する第1ハード・コード手段、または、ブートストラッピング・サーバ機能に局所的に鍵の使用法を設定する第2ハード・コード手段の少なくとも一方と、
ブートストラッピング・サーバ機能に送られるホーム加入者サーバに格納されたユーザ・セキュリティ設定に追加のフィールドを提供する第2提供手段と、
鍵の使用法を示すブートストラッピング・サーバ機能に格納された属性値ペアを用いる第1使用手段と、を備える、請求項10に記載の装置。
【請求項14】
使用される導出鍵のタイプ、あるいは、スマートカードまたは実現可能なセキュア環境のタイプを示す属性値を使用する第2使用手段をさらに備え、
前記導出鍵のタイプは、Ks_int_NAF、Ks_ext_NAFまたはKs_NAFを含み、
前記スマートカードまたはセキュア環境はGBA_Uにより構成される、請求項13に記載の装置。
【請求項15】
前記属性値ペアがKs_int_NAFの使用を示す場合は、前記ネットワーク・アプリケーション機能は、セキュリティ・レベルがより低い鍵ではなく、Ks_int_NAFが使用されるようにさらに要求する、請求項14に記載の装置。
【請求項16】
ウェブ・サーバが、前記スマートカードまたはセキュア環境にある場合は、ネットワーク・アプリケーションをユニバーサル・モバイル・テレコミュニケーション・システム(UMTS)集積回路カード(UICC)にさらに配置する配置手段をさらに有し、
前記UICCは前記ネットワーク・アプリケーション機能であり、導出された鍵(Ks_int_NAF)は、ウェブ・サービス事業体間の通信の保護のために使用される、請求項11に記載の装置。
【請求項17】
ホーム加入者サーバ(HSS)に格納されたユーザ・セキュリティ設定に追加のフィールドを提供することにより、ブートストラッピング・サーバ機能(BSF)に局所的に鍵の使用法を設定する第3ハード・コード手段をさらに備える請求項10に記載の装置。
【請求項18】
ネットワーク・アプリケーション・サーバのための汎用メカニズムを提供するための装置であって、
ネットワーク・アプリケーション機能に認証情報を提供するようにユーザ機器からの要求を受信する受信ユニットと、
ユーザ・セキュリティ設定を用いて汎用認証アーキテクチャのネットワーク・アプリケーション機能鍵を決定する決定ユニットと、
前記ネットワーク・アプリケーション機能に認証情報を提供する提供ユニットと、を備える装置。
【請求項19】
コンピュータ読み取り可能な媒体に具体化された、受信ユニットと、決定ユニットと、提供ユニットと、を含む装置によって実現される、ネットワーク・アプリケーション・サーバのための汎用メカニズムを提供するためのコンピュータ・プログラムであって、
ネットワーク・アプリケーション機能に認証情報を提供するようにユーザ機器からの要求を前記受信ユニットにより受信するステップと、
ユーザ・セキュリティ設定を用いて汎用認証アーキテクチャのネットワーク・アプリケーション機能鍵を前記決定ユニットにより決定するステップと、
前記ネットワーク・アプリケーション機能に認証情報を前記提供ユニットにより提供するステップと、を実行するように構成されたコンピュータ・プログラム。
【請求項20】
前記提供ステップは、ユーザ・セキュリティ設定においてユーザ機器のスマートカードのタイプまたはセキュア環境に関連するデータを提供するステップと、
ユニバーサル・モバイル・テレコミュニケーション・システム集積回路カード(UICC)に基づいて強化された汎用ブートストラッピング・アーキテクチャ(GBA_U)が、汎用加入者識別モジュール、加入者識別モジュール、セキュア環境、インターネットプロトコル・マルチメディア・サブシステム、加入者識別モジュール(IMS SIM)カードを実施可能にするか否かを示すフラグ・フィールドを提供することを含む、請求項19に記載のコンピュータ・プログラム。
【請求項21】
前記提供ステップは、認証情報の認証ヘッダ中で送られるユーザ・セキュリティ設定における第1及び第2フラグ・フィールドを提供することを含み、
前記第1フラグ・フィールドにおいては、ユニバーサル・モバイル・テレコミュニケーション・システム集積回路カード(UICC)に基づいて強化された汎用ブートストラッピング・アーキテクチャ(GBA_U)における第1導出鍵(Ks_int_NAF)が使用され、
前記第2フラグ・フィールドにおいては、第2導出鍵(Ks_ext_NAF)または第3導出鍵(Ks_NAF)が使用される、請求項19に記載のコンピュータ・プログラム。
【請求項22】
前記決定ステップは、ネットワーク・アプリケーション機能の設定の間に、
前記ネットワーク・アプリケーション機能に直接、局所的に鍵の使用法を設定することと、ブートストラッピング・サーバ機能に直接、局所的に鍵の使用法を設定することと、の少なくとも一方を決定することと、
ブートストラッピング・サーバ機能に送られるホーム加入者サーバに格納されたユーザ・セキュリティ設定に追加のフィールドを提供することと、
鍵の使用法を示すブートストラッピング・サーバ機能に格納された属性値ペアを用いることと、を含む、請求項19に記載のコンピュータ・プログラム。
【請求項23】
前記決定ステップは、使用される導出鍵のタイプ、あるいは、スマートカードのタイプまたは実現可能なセキュア環境を示す属性値を使用することを含み、
前記導出鍵のタイプは、Ks_int_NAF、Ks_ext_NAFまたはKs_NAFを含み、前記スマートカードまたはセキュア環境はGBA_Uにより構成される、請求項22に記載のコンピュータ・プログラム。
【請求項24】
前記属性値ペアがKs_int_NAFの使用を示す場合は、前記決定ステップは、セキュリティ・レベルがより低い鍵が使用されないように、前記ネットワーク・アプリケーション機能によるKs_int_NAFの使用を要求することを含む、請求項23に記載のコンピュータ・プログラム。
【請求項25】
ウェブ・サーバが前記スマートカードまたはセキュア環境にある場合は、前記決定するステップは、ネットワーク・アプリケーションをユニバーサル・モバイル・テレコミュニケーション・システム(UMTS)集積回路カード(UICC)に配置することをを更に含み、
前記UICCは前記ネットワーク・アプリケーション機能であり、
生成された鍵(Ks_int_NAF)は、ウェブ・サービス事業体間の通信の保護のために使用される、請求項20に記載のコンピュータ・プログラム。
【請求項26】
前記ネットワーク・アプリケーションを配置する前記配置ステップは、ジャバ・アプリケーション、XMLアプリケーション、C++アプリケーション、パール・アプリケーション、またはビジュアル・ベーシック・アプリケーションを含む、請求項25に記載のコンピュータ・プログラム。
【請求項27】
前記プロセスは、ホーム加入者サーバ(HSS)に格納されたユーザ・セキュリティ設定に追加のフィールドを提供することにより、ブートストラッピング・サーバ機能(BSF)に局所的に鍵の使用法を前記装置により設定するステップをさらに含む、請求項19に記載のコンピュータ・プログラム。」

(2)平成23年9月5日付け手続補正
上記平成23年9月5日付けの手続補正書は特許請求の範囲を以下のとおりに補正しようとするものである。
「 【請求項1】
受信ユニットと、決定ユニットと、提供ユニットと、を含む装置によって実現される、ネットワーク・アプリケーション・サーバのための汎用メカニズムを提供する方法であって、
ネットワーク・アプリケーション機能に認証情報を提供するようにユーザ機器からの要求を前記受信ユニットにより受信する受信ステップと、
ユーザ・セキュリティ設定を用いて汎用認証アーキテクチャのネットワーク・アプリケーション機能鍵を前記決定ユニットにより、第1共有秘密鍵(Ks_int_NAF)、第2共有秘密鍵(Ks_ext_NAF)及び第3共有秘密鍵(Ks_NAF)から選択することにより決定するステップであって、前記第1共有秘密鍵(Ks_int_NAF)、前記第2共有秘密鍵(Ks_ext_NAF)及び前記第3共有秘密鍵(Ks_NAF)はマスター共有秘密鍵(Ks)から導出されたものである、決定ステップと、
前記ネットワーク・アプリケーション機能に認証情報を前記提供ユニットにより提供する提供ステップと、を含む方法。
【請求項2】
前記提供ステップは、前記ユーザ・セキュリティ設定におけるユーザ機器のスマートカードのタイプまたはセキュリティ環境に関連するデータを提供し、
ユニバーサル・モバイル・テレコミュニケーション・システム集積回路カード(UICC)に基づいて強化された汎用ブートストラッピング・アーキテクチャ(GBA_U)が、汎用加入者識別モジュール、加入者識別モジュール、インターネットプロトコル・マルチメディア・サブシステム、加入者識別モジュール(IMS SIM)カード、又は、別のセキュア環境を実施可能にするか否かを示すフラグ・フィールドを提供することを含む、請求項1に記載の方法。
【請求項3】
前記提供ステップは、認証情報の認証ヘッダ中で送られるユーザ・セキュリティ設定における第1及び第2フラグ・フィールドを提供することを含み、
前記第1フラグ・フィールドにおいては、ユニバーサル・モバイル・テレコミュニケーション・システム集積回路カード(UICC)に基づいて強化された汎用ブートストラッピング・アーキテクチャ(GBA_U)における第1共有秘密鍵(Ks_int_NAF)が使用され、
前記第2フラグ・フィールドにおいては、第2共有秘密鍵(Ks_ext_NAF)または第3共有秘密鍵(Ks_NAF)が使用される、請求項1に記載の方法。
【請求項4】
前記決定ステップは、
ネットワーク・アプリケーション機能の設定の間に、前記ネットワーク・アプリケーション機能に直接、局所的に共有秘密鍵の使用法を設定することと、
ブートストラッピング・サーバ機能に直接、局所的に共有秘密鍵の使用法を設定することの、少なくとも一方を決定することと、
ブートストラッピング・サーバ機能に送られるホーム加入者サーバに格納されたユーザ・セキュリティ設定に追加のフィールドを使用することと、
共有秘密鍵の使用法を示すブートストラッピング・サーバ機能に格納された属性値ペアを用いることと、を含む、請求項1に記載の方法。
【請求項5】
使用される共有秘密鍵のタイプ、あるいは、スマートカードまたは実現可能なセキュア環境のタイプを示す属性値ペアを使用し、
前記共有秘密鍵のタイプは、Ks_int_NAF、Ks_ext_NAFまたはKs_NAFを含み、
前記スマートカードまたはセキュア環境はGBA_Uにより構成される、請求項4に記載の方法。
【請求項6】
前記属性値ペアがKs_int_NAFの使用を示す場合は、前記決定ステップは、セキュリティ・レベルがより低い共有秘密鍵が使用されないように、前記ネットワーク・アプリケーション機能によるKs_int_NAFの使用を要求することを含む、請求項5に記載の方法。
【請求項7】
ウェブ・サーバがセキュア環境にある場合は、前記決定するステップは、ネットワーク・アプリケーションをユニバーサル・モバイル・テレコミュニケーション・システム(UMTS)集積回路カード(UICC)にさらに配置する配置ステップを更に含み、
前記UICCは前記ネットワーク・アプリケーション機能であり、
共有秘密鍵(Ks_int_NAF)は、ウェブ・サービス事業体間の通信の保護のために使用される、請求項2に記載の方法。
【請求項8】
前記ネットワーク・アプリケーションを配置する前記配置ステップは、ジャバ・アプリケーション、XMLアプリケーション、C++アプリケーション、パール・アプリケーション、またはビジュアル・ベーシック・アプリケーションを含む、請求項7に記載の方法。
【請求項9】
ホーム加入者サーバ(HSS)に格納されたユーザ・セキュリティ設定に追加のフィールドを提供することにより、ブートストラッピング・サーバ機能(BSF)に局所的に共有秘密鍵の使用法を前記装置により設定するステップを更に含む請求項1に記載の方法。
【請求項10】
ネットワーク・アプリケーション・サーバのための汎用メカニズムを提供する装置であって、
ネットワーク・アプリケーション機能に認証情報を提供するようにユーザ機器からの要求を受信する受信手段と、
ユーザ・セキュリティ設定を用いて汎用認証アーキテクチャのネットワーク・アプリケーション機能鍵を、第1共有秘密鍵(Ks_int_NAF)、第2共有秘密鍵(Ks_ext_NAF)及び第3共有秘密鍵(Ks_NAF)から選択することにより決定する決定手段であって、前記第1共有秘密鍵(Ks_int_NAF)、前記第2共有秘密鍵(Ks_ext_NAF)及び前記第3共有秘密鍵(Ks_NAF)はマスター共有秘密鍵(Ks)から導出されたものである、決定手段と、
前記ネットワーク・アプリケーション機能に認証情報を提供する第1提供手段と、を備える装置。
【請求項11】
ユーザ・セキュリティ設定におけるユーザ機器のスマートカードのタイプまたはセキュア環境に関するデータを提供する第2提供手段と、
ユニバーサル・モバイル・テレコミュニケーション・システム集積回路カード(UICC)に基づいて強化された汎用ブートストラッピング・アーキテクチャ(GBA_U)が、汎用加入者識別モジュール、加入者識別モジュール、セキュア環境あるいはIMS SIMカードを実施可能にするか否かを示すフラグ・フィールドを提供する第3提供手段と、をさらに備える請求項10に記載の装置。
【請求項12】
認証情報の認証ヘッダ中で送られるユーザ・セキュリティ設定内の第1及び第2フラグ・フィールドを提供する第2提供手段をさらに備え、
前記第1フラグ・フィールドにおいては、ユニバーサル・モバイル・テレコミュニケーション・システム集積回路カード(UICC)に基づいて強化された汎用ブートストラッピング・アーキテクチャ(GBA_U)における第1共有秘密鍵(Ks_int_NAF)が使用され、
前記第2フラグ・フィールドにおいては、第2共有秘密鍵(Ks_ext_NAF)または第3共有秘密鍵(Ks_NAF)が使用される、請求項10に記載の装置。
【請求項13】
前記汎用メカニズムは、
ネットワーク・アプリケーション機能の設定の間に、前記ネットワーク・アプリケーション機能に直接、局所的に共有秘密鍵の使用法を設定する第1ハード・コード手段、または、ブートストラッピング・サーバ機能に局所的に共有秘密鍵の使用法を設定する第2ハード・コード手段の少なくとも一方と、
ブートストラッピング・サーバ機能に送られるホーム加入者サーバに格納されたユーザ・セキュリティ設定に追加のフィールドを提供する第2提供手段と、
共有秘密鍵の使用法を示すブートストラッピング・サーバ機能に格納された属性値ペアを用いる第1使用手段と、を備える、請求項10に記載の装置。
【請求項14】
使用される共有秘密鍵のタイプ、あるいは、スマートカードまたは実現可能なセキュア環境のタイプを示す属性値を使用する第2使用手段をさらに備え、
前記共有秘密鍵のタイプは、Ks_int_NAF、Ks_ext_NAFまたはKs_NAFを含み、
前記スマートカードまたはセキュア環境はGBA_Uにより構成される、請求項13に記載の装置。
【請求項15】
前記属性値ペアがKs_int_NAFの使用を示す場合は、前記ネットワーク・アプリケーション機能は、セキュリティ・レベルがより低い共有秘密鍵ではなく、Ks_int_NAFが使用されるようにさらに要求する、請求項14に記載の装置。
【請求項16】
ウェブ・サーバが、前記スマートカードまたはセキュア環境にある場合は、ネットワーク・アプリケーションをユニバーサル・モバイル・テレコミュニケーション・システム(UMTS)集積回路カード(UICC)にさらに配置する配置手段をさらに有し、
前記UICCは前記ネットワーク・アプリケーション機能であり、第1共有秘密鍵(Ks_int_NAF)は、ウェブ・サービス事業体間の通信の保護のために使用される、請求項11に記載の装置。
【請求項17】
ホーム加入者サーバ(HSS)に格納されたユーザ・セキュリティ設定に追加のフィールドを提供することにより、ブートストラッピング・サーバ機能(BSF)に局所的に共有秘密鍵の使用法を設定する第3ハード・コード手段をさらに備える請求項10に記載の装置。
【請求項18】
ネットワーク・アプリケーション・サーバのための汎用メカニズムを提供するための装置であって、
ネットワーク・アプリケーション機能に認証情報を提供するようにユーザ機器からの要求を受信する受信ユニットと、
ユーザ・セキュリティ設定を用いて汎用認証アーキテクチャのネットワーク・アプリケーション機能鍵を、第1共有秘密鍵(Ks_int_NAF)、第2共有秘密鍵(Ks_ext_NAF)及び第3共有秘密鍵(Ks_NAF)から選択することにより決定する決定ユニットであって、前記第1共有秘密鍵(Ks_int_NAF)、前記第2共有秘密鍵(Ks_ext_NAF)及び前記第3共有秘密鍵(Ks_NAF)はマスター共有秘密鍵(Ks)から導出されたものである、決定ユニットと、
前記ネットワーク・アプリケーション機能に認証情報を提供する提供ユニットと、を備える装置。
【請求項19】
コンピュータ読み取り可能な媒体に具体化された、受信ユニットと、決定ユニットと、提供ユニットと、を含む装置によって実現される、ネットワーク・アプリケーション・サーバのための汎用メカニズムを提供するためのコンピュータ・プログラムであって、
ネットワーク・アプリケーション機能に認証情報を提供するようにユーザ機器からの要求を前記受信ユニットにより受信する受信ステップと、
ユーザ・セキュリティ設定を用いて汎用認証アーキテクチャのネットワーク・アプリケーション機能鍵を前記決定ユニットにより、第1共有秘密鍵(Ks_int_NAF)、第2共有秘密鍵(Ks_ext_NAF)及び第3共有秘密鍵(Ks_NAF)から選択することにより決定する決定ステップであって、前記第1共有秘密鍵(Ks_int_NAF)、前記第2共有秘密鍵(Ks_ext_NAF)及び前記第3共有秘密鍵(Ks_NAF)はマスター共有秘密鍵(Ks)から導出されたものである、決定ステップと、
前記ネットワーク・アプリケーション機能に認証情報を前記提供ユニットにより提供する提供ステップと、を実行するように構成されたコンピュータ・プログラム。
【請求項20】
前記提供ステップは、ユーザ・セキュリティ設定においてユーザ機器のスマートカードのタイプまたはセキュア環境に関連するデータを提供するステップと、
ユニバーサル・モバイル・テレコミュニケーション・システム集積回路カード(UICC)に基づいて強化された汎用ブートストラッピング・アーキテクチャ(GBA_U)が、汎用加入者識別モジュール、加入者識別モジュール、セキュア環境、インターネットプロトコル・マルチメディア・サブシステム、加入者識別モジュール(IMS SIM)カードを実施可能にするか否かを示すフラグ・フィールドを提供することを含む、請求項19に記載のコンピュータ・プログラム。
【請求項21】
前記提供ステップは、認証情報の認証ヘッダ中で送られるユーザ・セキュリティ設定における第1及び第2フラグ・フィールドを提供することを含み、
前記第1フラグ・フィールドにおいては、ユニバーサル・モバイル・テレコミュニケーション・システム集積回路カード(UICC)に基づいて強化された汎用ブートストラッピング・アーキテクチャ(GBA_U)における第1共有秘密鍵(Ks_int_NAF)が使用され、
前記第2フラグ・フィールドにおいては、第2共有秘密鍵(Ks_ext_NAF)または第3共有秘密鍵(Ks_NAF)が使用される、請求項19に記載のコンピュータ・プログラム。
【請求項22】
前記決定ステップは、ネットワーク・アプリケーション機能の設定の間に、
前記ネットワーク・アプリケーション機能に直接、局所的に共有秘密鍵の使用法を設定することと、ブートストラッピング・サーバ機能に直接、局所的に共有秘密鍵の使用法を設定することと、の少なくとも一方を決定することと、
ブートストラッピング・サーバ機能に送られるホーム加入者サーバに格納されたユーザ・セキュリティ設定に追加のフィールドを提供することと、
共有秘密鍵の使用法を示すブートストラッピング・サーバ機能に格納された属性値ペアを用いることと、を含む、請求項19に記載のコンピュータ・プログラム。
【請求項23】
前記決定ステップは、使用される共有秘密鍵のタイプ、あるいは、スマートカードのタイプまたは実現可能なセキュア環境を示す属性値を使用することを含み、
前記共有秘密鍵のタイプは、Ks_int_NAF、Ks_ext_NAFまたはKs_NAFを含み、前記スマートカードまたはセキュア環境はGBA_Uにより構成される、請求項22に記載のコンピュータ・プログラム。
【請求項24】
前記属性値ペアがKs_int_NAFの使用を示す場合は、前記決定ステップは、セキュリティ・レベルがより低い共有秘密鍵が使用されないように、前記ネットワーク・アプリケーション機能によるKs_int_NAFの使用を要求することを含む、請求項23に記載のコンピュータ・プログラム。
【請求項25】
ウェブ・サーバが前記スマートカードまたはセキュア環境にある場合は、前記決定するステップは、ネットワーク・アプリケーションをユニバーサル・モバイル・テレコミュニケーション・システム(UMTS)集積回路カード(UICC)に配置する配置ステップを更に含み、
前記UICCは前記ネットワーク・アプリケーション機能であり、
第1共有秘密鍵(Ks_int_NAF)は、ウェブ・サービス事業体間の通信の保護のために使用される、請求項20に記載のコンピュータ・プログラム。
【請求項26】
前記ネットワーク・アプリケーションを配置する前記配置ステップは、ジャバ・アプリケーション、XMLアプリケーション、C++アプリケーション、パール・アプリケーション、またはビジュアル・ベーシック・アプリケーションを含む、請求項25に記載のコンピュータ・プログラム。
【請求項27】
ホーム加入者サーバ(HSS)に格納されたユーザ・セキュリティ設定に追加のフィールドを提供することにより、ブートストラッピング・サーバ機能(BSF)に局所的に共有秘密鍵の使用法を前記装置により設定するステップをさらに実行するように構成された、請求項19に記載のコンピュータ・プログラム。」


3.引用文献

本願の出願前でありかつ上記優先日よりも前の日に頒布または電気通信回線を通じて公衆に利用可能となり、原審の拒絶の査定の理由である上記平成22年11月26日付けの拒絶理由通知の(理由1)において引用された、下記引用文献には、下記引用文献記載事項が記載されている。(下線は当審付与。)

<引用文献1>
「UE triggered unsolicited push from BSF to NAFs 3GPP TSA SA WG3 security-S3#32 S3-040076」,[online],2004年 2月,Nokia,[平成22年11月25日検索],Retrieved from the Internet:

<引用文献記載事項1-1>
「2.3 Procedure details
Figure 1 describes the bootstrapping procedure where UE triggers the pushing of bootstrapping information from BSF to a NAF.

1. (Optional) UE contacts a NAF. NAF indicates to the UE that it requires authentication and that GAA should be used.
2. UE prepares to do bootstrapping procedure. If UE already knows the NAF, it may add the NAF_ID in the initial bootstrapping message 3.
3. UE sends initial HTTP request to BSF with IMPI, and optional NAF_ID. (“NAF_ID?”means that NAF_ID parameter may be either absent or present in the message.)
4-5. (Optional) BSF fetches authentication vectors AV and profile information from HSS. Optionally, if BSF already has AV for the UE it may skip steps 4 and 5 all together.
6-7. Ordinary HTTP Digest AKA steps are done and new bootstrapping info is established.
Note: Steps 8-10 are optional and are done only if the optional NAF_ID was present in the initial bootstrapping request in step 3.
8. (Optional) If NAF_ID was present in the initial HTTP request (step 2), then BSF pushes the bootstrapping info to the NAF indentified by NAF_ID.
9. (Optional) NAF specific bootstrapping info is pushed to the NAF by BSF.
10. (Optional) NAF acknowledges that the bootstrapping info was received and stored.
11. HTTP response 200 OK with TID is sent to the UE to indicate that the bootstrapping procedure was successful. There is no indication whether the optional unsolicited push operation was successful or not.
12. UE contacts the NAF. If the NAF already possesses the bootstrapping info identified by the TID, it does not need to fetch the bootstrapping info from BSF over Zn interface. If the bootstrapping info is not present in the NAF, it fetches the info from BSF over Zn interface.」(第2ページ第1行?第3ページ第8行)
(当審訳:「2.3 プロシージャ詳細
図1は、UEがBSFからNAFへのブートストラッピング情報のプッシングをトリガする、ブートストラッピング・プロシージャを説明している。

1.(オプション)UEがNAFと連絡をとる。NAFは、それが認証を要求し、かつ、GAAが用いられるべきであるということをUEへ通知する。
2.UEが、ブートストラッピング・プロシージャを行う準備をする。UEがNAFを既に知っているならば、それはイニシャルブートストラッピングメッセージ3内にNAF_IDを加えてもよい。
3.UEはIMPIおよびオプションのNAF_IDを伴ったイニシャルHTTPリクエストをBSFへ送る。(「NAF_ID?」は、NAF_IDパラメーターがメッセージ内に有っても無くてもよいことを意味する。)
4-5.(オプション)BSFはHSSから認証ベクトルAVとプロファイル情報をフェッチする。オプションとして、BSFがUEのためのAVを既に持っているならば、ステップ4と5をすべてスキップしてもよい。
6-7.通常のHTTPダイジェストAKAステップが行われる。そして、新しいブートストラッピング情報が確立される。
注:ステップ8-10はオプションであり、ステップ3のイニシャルブートストラッピングリクエスト中でオプションのNAF_IDが与えられた場合のみ行われる。
8.(オプション)NAF_IDがイニシャルHTTPリクエスト(ステップ2)の中にあった場合、その時にはBSFは、NAF_IDによって識別されるNAFへブートストラッピング情報をプッシュする。
9.(オプション)NAF固有のブートストラッピング情報がBSFによってNAFへプッシュされる。
10.(オプション)NAFは、ブートストラッピング情報が受信され格納された旨の肯定応答をする。
11.TIDを伴なうHTTPレスポンス200OKがブートストラッピングプロシージャが成功したことを通知するためにUEに送られる。オプションの自発的なプッシュオペレーションが成功したか否かの通知はない。
12.UEがNAFと連絡をとる。NAFがTIDによって識別されたブートストラッピング情報を既に持つ場合、Znインターフェース上のBSFからブートストラッピング情報をフェッチする必要はない。ブートストラッピング情報がNAF中で示されていない場合、それはZnインターフェース上のBSFから情報をフェッチする。」)

<引用文献記載事項1-2>


」(第2頁のFigure 1)

<引用文献記載事項1-3>
「4.3.2 Bootstrapping procedures
When a UE wants to interact with an NAF, and it knows that bootstrapping procedure is needed, it shall first perform a bootstrapping authentication (see Figure 4)
Editor’s notes: Zh interface related procedure will be added here in future development. It may re-use Cx interface that is specified in TS 29.228.
Otherwise, the UE shall perform a bootstrapping authentication only when it has received bootstrapping initiation required message or a key update indication from the NAF (cf. subclause 4.3.3).

1. The UE sends an HTTP request towards the BSF. The requst contains the user identity. Request may contain a NAF identifier.
2. BSF retrieves the user profile and a challenge, i.e. the Authentication Vector (AV,AV=RAND||AUTN||XRES||CK||IK) over Zh interface from the HSS.
3. Then BSF forwards the RAND and AUTN to the UE in the 401 message (without the CK, IK and XRES). This is to demand the UE to authenticate itself.
4. The UE calculates the message authentication code (MAC) so as to verify the challenge from authenticated network; the UE also calculates CK, IK and RES. This will result in session keys IK and CK in both BSF and UE.
5. The UE sends request again, with the Digest AKA RES as the response to the BSF.
6. If the RES equals to the XRES that is in the AV, the UE is authenticated.
7. BSF generates key material Ks by concatenating CK and IK. Ks is used to derive the key material Ks_NAF.Ks_NAF is used for securing the Ua interface.
8. If NAF identifiers were present in the initial bootstrapping request, BSF pushes the TID, Ks, and NAF specific user profile to NAFs identified by the NAF identifiers.
9. The BSF shall send 200 OK message and shall supply a transaction identifier to the UE to indicate the success of the authentication. The BSF may also supply the parameter n used to determine the NAF_Id_n (cf. next bullet) to the UE over the Ub interface. If the parameter n is not supplied then no key derivation is performed, i.e. Ks=Ks_NAF.
10. The key material Ks is generated in UE by concatenating CK and IK. The Ks is used to derive the key material Ks_NAF. Ks_NAF is used for securing the Ua interface.
Ks_NAF is computed as Ks_NAF = KDF (Ks, key derivation parameters), where KDF is a suitable key derivation function, and the key derivation parameters include the user’s IMSI, the NAF_Id_n and RAND. The NAF_Id_n consists of the n rightmost domain labels in the DNS name of the NAF, separated by dots (n= 1, ..., 7). For n = 0, NAF_Id_n equals the full DNS name of the NAF. The next bullet specifies how the UE obtains n.
NOTE: This note gives an example how to obtain the NAF_Id_n: if the DNS name of the NAF is server1.presence.bootstrap.operator.com”, and n=3,then NAF_Id_n = “ bootstrap.operator.com”.
Editor’s note: the definition of the KDF and the possible inclusion of further key derivation parameters is left to ETSI SAGE.」(Attachment部分の第6ページ第3行?第9ページ第18行)
(当審訳:「4.3.2 ブートストラッピング プロシージャ
あるUEがあるNAFと対話を望み、それがブートストラッピング・プロシージャが必要なことを認識しているとき、それは最初にブートストラッピング認証を行うものとする(図4を参照)。
編集者の注:プロシージャに関連付けられたZhインターフェースは、将来の開発においてここに加えられるだろう。それは、TS 29.228で明示されるCxインターフェースを再度用いるかもしれない。
その他には、UEは、NAF(4.3.3副節参照)からのメッセージあるいは鍵更新指示を要求されるブートストラッピング・イニシエーションをそれが受信したときのみ、ブートストラッピング認証を行うものとする。
1.UEがBSFへのHTTPリクエストを送信する。そのリクエストはユーザーの識別を含んでいる。リクエストはNAF識別子を含んでいてもよい。
2.BSFはHSSからZhインターフェースを通じてユーザープロファイルとチャレンジ、すなわち認証ベクトル(AV,AV=RAND||AUTN||XRES||CK||IK)を引き出す。
3.その時、BSFは、401メッセージ(CK,IKとXRESは伴わない)内のUEへのRANDとAUTNを転送する。これはUEに自身を認証することを要求するものである。
4.UEは認証されたネットワークからのチャレンジを確認するのと同様に、メッセージ確認コード(MAC)を計算する。UEはまたCK、IKとRESを計算する。これは、BSFとUEの両方の中のセッションキーIKとCKになる。
5.UEは、BSFに対するレスポンスとしてのダイジェストAKA RESを用いて、リクエストを再び送る。
6.RESがAV内にあるXRESに等しい場合、UEが認証される。
7.BSFがCKとIKの連結により鍵マテリアルKsを生成する。Ksは鍵マテリアルKs_NAFを導出するために用いられる。Ks_NAFはUaインターフェースを安全にするために用いられる。
8.NAF識別子がイニシャルブートストラッピング・リクエストの中にあった場合、BSFは、NAF識別子によって識別されたNAFに、TID、KsとNAF固有のユーザプロフィールをプッシュする。
9.BSFはUEへ認証の成功を示すために、200 OKメッセージを送るべきであり、トランザクション識別子を供給すべきである。BSFは、またUbインターフェース上のUEへNAF_Id_n(次のブレット参照)を決めるために用いられるパラメーターnを供給してもよい。パラメーターnが供給されない場合、鍵導出は遂行されない、つまり、Ks=Ks_NAF。
10.鍵マテリアルKsはCKとIKの連結によりUEで生成される。
Ksは鍵マテリアルKs_NAFを導出するために用いられる。Ks_NAFはUaインターフェースを安全にするのための用いられる。
Ks_NAFはKs_NAF=KDF(Ks,鍵導出パラメーター)として計算される、ここに、KDFは適当な鍵導出関数で、鍵導出パラメーターはユーザーのIMSI、NAF_Id_nとRANDを含んでいる。NAF_Id_nはドットによって分離されたNAFのDNS名の中のnの右端のドメイン・ラベルから成る(n= 1, ..., 7)。n=0に対し、NAF_Id_nは、NAFの完全なDNS名と等しい。次のブレットは、UEがどのようにnを得るかを明示する。
注:この注でNAF_Id_nを得る方法の例を挙げる:
NAFのDNS名が"server1.presence.bootstrap.operator.com"でn=3ならば、NAF_Id_n="bootstrap.operator.com"
編集者の注:KDFの定義とさらなる鍵導出パラメーターの可能なインクルージョンは、ETSI SAGEにゆだねられる。」)


<引用文献2>
「3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Generic Authentication Architecture(GAA); Generic bootstrapping architecture(Release 6) 3GPP TS 33.330 V6.4.0 (2005-03)」, [online], 2005年 3月,[平成22年11月26日検索],Retrieved from the Internet:

<引用文献記載事項2-1>
「User Security Setting: A USS is an application and subscriber specific parameter set that defines two parts, an authentication part, which contains the list of identities of the user needed for the application (e.g. IMPI, IMPUs, MSISDN, pseudonyms), and an authorisation part, which contains the user permission flags (e.g. access to application allowed, type of certificates which may be issued). Sometimes also called application-specific user security setting. The USS is delivered to the BSF as a part of GUSS from the HSS, and from the BSF to the NAF if requested by the NAF.」(第9ページ本文第9行?第13行)
(当審訳:「ユーザー・セキュリティ・セッティング:USSはアプリケーションと加入者固有のパラメータ・セットであり、これは2つのパート、つまり、認証部分(それはアプリケーションのために必要とされたユーザーのアイデンティティ(例えばIMPI、IMPU、MSISDN、仮名)のリストを含んでいる)と、認可部分(それはユーザー・パーミッション・フラグ(例えば許可されたアプリケーションにアクセス、頒布させられてもよい証明書のタイプ)を含んでいる)を定義する。時にアプリケーション固有のユーザー・セキュリティ・セッティングとも呼ばれる。USSはHSSからBSFに、そしてもしNAFによって要求されればBSFからNAFへ、GUSSの一部として送られる。」)

<引用文献記載事項2-2>
「4.5.2Bootstrapping procedures
(中略)
1.The UE sends an HTTP request towards the BSF.
2.BSF retrieves the complete set of GBA user security settings and one Authentication Vector (AV, AV = RAND||AUTN||XRES||CK||IK) over the reference point Zh from the HSS.
(中略)
9.Both the UE and the BSF shall use the Ks to derive the key material Ks_NAF during the procedures as specified in clause 4.5.3. Ks_NAF shall be used for securing the reference point Ua.Ks_NAF is computed as Ks_NAF = KDF (Ks, "gba-me", RAND, IMPI, NAF_Id), where KDF is the key derivation function as specified in Annex B, and the key derivation parameters consist of the user's IMPI, the NAF_Id and RAND. The NAF_Id consists of the full DNS name of the NAF. KDF shall be implemented in the ME.」(第18ページ本文第27行目?第20ページ本文第12行目)
(当審訳:「4.5.2 ブートストラッピング・プロシージャ
(中略)
1.UEがBSFへHTTPリクエストを送る。
2.BSFがHSSから基準点Zh上のGBAユーザー・セキュリティ・セッティングの完全なセットと1つの認証ベクトル(AVおよびAV=RAND||AUTN||XRES||CK||IK)を引き出す。
(中略)
9.UEとBSFの両方は、4.5.3節で明示されるようなプロシージャ中に鍵マテリアルKs_NAFを導出するためにKsを用いているものとする。Ks_NAFは基準点Uaを安全にするために用いられているものとする。KDFが付属書類Bで明示されるような鍵導出関数である場合、Ks_NAFは、Ks_NAF=KDF(Ks,"gba-me", RAND, IMPI, NAF_Id)として計算される。そして、鍵導出パラメーターはユーザーのIMPI、NAF_IdとRANDから構成される。NAF_IdはNAFの完全なDNS名から構成される。KDFはMEにおいて実装されるものとする。」)

<引用文献記載事項2-3>
「5.3.2Bootstrapping procedure
(中略)
1.The ME sends an HTTP request towards the BSF.
2.The BSF retrieves the complete set of GBA user security settings and one Authentication Vector (AV, AV = RAND||AUTN||XRES||CK||IK) over the Zh reference point from the HSS.The BSF can then decide to perform GBA_U, based on the user security settings (USSs).In this case, the BSF proceeds in the following way:
(中略)
9. Both the UICC and the BSF shall use the Ks to derive NAF-specific keys Ks_ext_NAF and Ks_int_NAF during the procedures as specified in clause 5.3.3, if applicable. Ks_ext_NAF and Ks_int_NAF are used for securing the Ua reference point.
Ks_ext_NAF is computed in the UICC as Ks_ext_NAF = KDF(Ks, "gba-me", RAND, IMPI, NAF_Id), and Ks_int_NAF is computed in the UICC as Ks_int_NAF = KDF(Ks, "gba-u, RAND, IMPI, NAF_Id), where KDF is the key derivation function as specified in Annex B, and the key derivation parameters include the user's IMPI, the NAF_Id and RAND. The NAF_Id consists of the full DNS name of the NAF. The key derivation parameters used for Ks_ext_NAF derivation must be different from those used for Ks_int_NAF derivation. This is done by adding a static string "gba-me" in Ks_ext_NAF and "gba-u" in Ks_int_NAF as an input parameter to the key derivation function.」(第24ページ本文第7行?第26ページ本文第17行)
(当審訳:「5.3.2 ブートストラッピング・プロシージャ
(中略)
1.MEがBSFへHTTPリクエストを送る。
2.BSFがHSSからZhの参照点上のGBAユーザー・セキュリティ・セッティングの完全なセットと1つの認証ベクトル(AV,AV=RAND||AUTN||XRES||CK||IK)を引き出す。その後、BSFは、ユーザー・セキュリティ・セッティング(USSs)に基づいて、GBA_Uを遂行することを決定することができる。この場合、BSFは以下のようは方法で手続を行う:
(中略)
9. UICCとBSFの両方は、適用可能な場合に、5.3.3節で明示されるようなプロシージャ中でNAF固有キーKs_ext_NAFとKs_int_NAFを導出するためにKsを用いるものとする。Ks_ext_NAFとKs_int_NAFはUa参照点を安全にするために用いられる。

Ks_ext_NAFは、Ks_ext_NAF = KDF(Ks, "gba-me", RAND, IMPI, NAF_Id)としてUICCで計算される。ここに、KDFが付属書類Bで明示されるような鍵導出関数で、鍵導出パラメーターがユーザーのIMPI、NAF_IdとRANDを含んでいる場合、Ks_int_NAFは、Ks_int_NAF = KDF(Ks, "gba-u, RAND, IMPI, NAF_Id)としてUICCで計算される。ここに、KDFは付属書類Bで明示されるような鍵導出関数であり、そして、鍵導出パラメーターはユーザーのIMPI、NAF_IdとRANDを含んでいる。NAF_IdはNAFの完全なDNS名から構成される。
Ks_ext_NAF導出のために用いられる鍵導出パラメーターは、Ks_int_NAF導出のために用いられたものとは異ならなければならない。これは、鍵導出関数へ入力パラメーターとしてKs_ext_NAFには静的なストリングの"gba-me"、そしてKs_int_NAFには"gba-u"を加えることにより行われる。」)

<引用文献記載事項2-4>
「Before communication between the UE and the NAF can start, the UE and the NAF first have to agree whether to use shared keys obtained by means of the GBA. If the UE does not know whether to use GBA with this NAF, it uses the Initiation of Bootstrapping procedure described in clause 5.3.1.
Once the UE and the NAF have established that they want to use GBA then every time the UE wants to interact with a NAF the following steps are executed as depicted in figure 5.3.
Next, the UE and the NAF have to agree, which type of keys to use, Ks_ext_NAF or Ks_int_NAF, or both. The default is the use of Ks_ext_NAF only. This use is also supported by MEs and NAFs, which are GBA_U unaware. If Ks_int_NAF, or both Ks_ext_NAF and Ks_int_NAF are to be used, this use has to be agreed between UE and NAF prior to the execution of the procedure described in the remainder of this clause 5.3.3. Any such agreement overrules the default use of the keys. How this agreement is reached is application-specific and is not within the scope of this document.」(第26ページ第21行?第32行)
(当審訳:「UEとNAFの間のコミュニケーションがスタートすることができる前に、UEとNAFはまずGBAによって得られた共有鍵を用いるべきかどうか合意しなければならない。UEがこのNAFによりGBAを用いるべきかどうか認識しない場合、それは5.3.1節内で述べられていたブートストラッピング・プロシージャのイニシエーションを用いる。
一旦、それらがGBAを用いようとすることをUEとNAFが確立したならば、その後、UEがNAFと対話しようとするごとに、図5.3で表されるように、以下のステップが実行される。
次に、UEとNAFは、Ks_ext_NAFまたはKs_int_NAF、あるいは両方のどちらの種類の鍵を使用すべきかを、同意しなければならない。デフォルトはKs_ext_NAFのみの使用である。この使用もまたGBA_U不知のMEとNAFにサポートされる。Ks_int_NAF、あるいは双方のKs_ext_NAFとKs_int_NAFが用いられる場合、この使用は、この5.3.3節の残りで述べられていたプロシージャの実行に先立ってUEとNAFの間で合意しなければならない。どのそのような合意も、鍵のデフォルト使用を支配する。この合意がどのように得られるかはアプリケーションに特有で、このドキュメントの範囲内ではない。」)



第2.平成23年9月5日付けの手続補正についての補正却下の決定

[補正却下の決定の結論]
平成23年9月5日付けの手続補正を却下する。


[理由]
1.本件補正の内容
平成23年9月5日付けの手続補正(以下「本件補正」と記す。)は、特許請求の範囲について、上記第1.2(1)記載の特許請求の範囲から、上記第1.2(2)記載の特許請求の範囲に補正しようとするものである。

2.本件補正が新規事項の追加であるか否かについての検討
本件補正について検討するに、本件補正後の請求項1記載の「ユーザ・セキュリティ設定を用いて汎用認証アーキテクチャのネットワーク・アプリケーション機能鍵を、第1共有秘密鍵(Ks_int_NAF)、第2共有秘密鍵(Ks_ext_NAF)及び第3共有秘密鍵(Ks_NAF)から選択することにより決定する決定手段」、補正後の請求項10記載の「ユーザ・セキュリティ設定を用いて汎用認証アーキテクチャのネットワーク・アプリケーション機能鍵を、第1共有秘密鍵(Ks_int_NAF)、第2共有秘密鍵(Ks_ext_NAF)及び第3共有秘密鍵(Ks_NAF)から選択することにより決定する決定手段」、補正後の請求項18記載の「ユーザ・セキュリティ設定を用いて汎用認証アーキテクチャのネットワーク・アプリケーション機能鍵を、第1共有秘密鍵(Ks_int_NAF)、第2共有秘密鍵(Ks_ext_NAF)及び第3共有秘密鍵(Ks_NAF)から選択することにより決定する決定ユニット」、及び、補正後の請求項19記載の「ユーザ・セキュリティ設定を用いて汎用認証アーキテクチャのネットワーク・アプリケーション機能鍵を前記決定ユニットにより、第1共有秘密鍵(Ks_int_NAF)、第2共有秘密鍵(Ks_ext_NAF)及び第3共有秘密鍵(Ks_NAF)から選択することにより決定する決定ステップ」という技術的事項は、特許法第184条の12第2項において、同法第17条の2第3項中の「願書に最初に添付した明細書、特許請求の範囲又は図面」とあるのを、これに読み替える旨規定されるものであるところの、上記平成19年10月10日付けの翻訳文(以下「当初明細書等」と記す。)には記載されておらず、また当初明細書等の記載からみて自明な事項でもない。
なお、請求人は審判請求書において当該補正の根拠として「これは、本願明細書段落[0017]、[0020]等の記載に基づいています。」と説明している。
しかしながら、当初明細書等の段落【0017】、【0020】の記載を詳細に検討しても、「ネットワーク・アプリケーション機能鍵」を、「Ks_int_NAF」と「Ks_ext_NAF」と「Ks_NAF」の3種の鍵から選択することを示唆する記載は見あたらない。
また、当初明細書の【請求項3】には
「前記第1フラグ・フィールドにおいては、集積回路を基礎として強化(GBA_U)された第1生成鍵(Ks_int_NAF)が使用され、
前記第2フラグ・フィールドにおいては、第2生成鍵(Ks_ext_NAF)または第3生成鍵(Ks_NAF)が使用される」との記載が、
【請求項5】には
「前記派生鍵のタイプは、Ks_int_NAF、Ks_ext_NAFまたはKs_NAFを含み」との記載が、
【請求項12】には
「前記第1フラグ・フィールドにおいては、集積回路を基礎として強化(GBA_U)された第1生成鍵(Ks_int_NAF)が使用され、
前記第2フラグ・フィールドにおいては、第2生成鍵(Ks_ext_NAF)または第3生成鍵(Ks_NAF)が使用される」との記載が、
【請求項14】には
「前記派生鍵のタイプは、Ks_int_NAF、Ks_ext_NAFまたはKs_NAFを含み、」との記載が、
【請求項21】には
「前記第1フラグ・フィールドにおいては、集積回路を基礎として強化(GBA_U)された第1生成鍵(Ks_int_NAF)が使用され、
前記第2フラグ・フィールドにおいては、第2生成鍵(Ks_ext_NAF)または第3生成鍵(Ks_NAF)が使用される」との記載が、
【0003】には
「携帯電話などの移動端末であるか、ユニバーサル・モバイル・テレコミュニケーション・システム(UMTS)集積回路カード(UICC)であるか、あるいはその移動端末に挿入された加入者識別モジュールであるかによって、3GPP汎用認証アーキテクチャ(GAA)は以下の鍵、即ち、Ks_int_NAF、Ks_ext_NAF及びKs_NAFを持つことができる。」との記載が、
段落【0027】には
「既存の仕様書3GPP TS 29.109のUSSに搬送された1つまたは2つの認証フラグ・フィールドをUSSは備えている。第1のフラグ・フィールドにおいては、もしこのフィールドが存在する場合には、UICCを基礎とした共有秘密鍵(Ks_int_NAF)の使用は必須であることを示す。第2のフラグ・フィールドは付加的なフィールドであり、もし第2のフラグ・フィールドが存在する場合は、MEを基礎とした共有秘密鍵(Ks_ext_NAFまたはKs_NAF)の使用であることを示す。」との記載が、
段落【0030】には
「工程330において、本方法では、付属書類Cとして添付された、既存の仕様書3GPP TS 29.109の認証ヘッダに送られる、1つまたは2つのフラグ・フィールドをUSSが有しているかどうかを決定する。第1のフラグ・フィールドにおいては、もしこのフィールドが存在する場合には、UICCを基礎とした共有秘密鍵(Ks_int_NAF)の使用は必須であることを示す。第2のフラグ・フィールドは付加的なフィールドであり、もし第2のフラグ・フィールドが存在する場合は、MEを基礎とした共有秘密鍵(Ks_ext_NAFまたはKs_NAF)の使用であることを示す。」との記載があるが、
「Ks_int_NAF」と「Ks_ext_NAF」と「Ks_NAF」の3種の鍵から選択することを示唆する記載は見あたらない。
また、「ネットワーク・アプリケーション機能鍵」を、「Ks_int_NAF」と「Ks_ext_NAF」と「Ks_NAF」の3種の鍵から選択することが当該技術分野における技術常識であったとも認めることはできない。
すなわち、本件補正は、当業者によって、当初明細書等のすべての記載を総合することにより導かれる技術的事項との関係において、新たな技術的事項を導入するものであり、当初明細書等に記載した事項の範囲内においてするものではない。
したがって、本件補正は、特許法第17条の2第3項の規定に違反するものである。


3.本件補正の目的についての検討
(1)本件補正のうち、本件補正後の請求項1に係る補正は、
本件補正前の請求項1に記載の発明を特定するための事項(以下「発明特定事項」と記す。)であるところの「ユーザ・セキュリティ設定を用いて汎用認証アーキテクチャのネットワーク・アプリケーション機能鍵を前記決定ユニットにより決定するステップ」を、「ユーザ・セキュリティ設定を用いて汎用認証アーキテクチャのネットワーク・アプリケーション機能鍵を前記決定ユニットにより、第1共有秘密鍵(Ks_int_NAF)、第2共有秘密鍵(Ks_ext_NAF)及び第3共有秘密鍵(Ks_NAF)から選択することにより決定するステップであって、前記第1共有秘密鍵(Ks_int_NAF)、前記第2共有秘密鍵(Ks_ext_NAF)及び前記第3共有秘密鍵(Ks_NAF)はマスター共有秘密鍵(Ks)から導出されたものである、決定ステップ」と限定する補正事項を含むものであり、この限定によって、本件補正前後の請求項1に係る発明の産業上の利用分野及び解決しようとする課題が格別変更されると言えるものでもない。
また、請求項10、18、19に対しても同様の限定がなされており、これらの限定によっても、本件補正前後の請求項10、18、19に係る発明の産業上の利用分野及び解決しようとする課題が格別変更されると言えるものでもない。
したがって、これらの補正事項に関しては、その目的は特許法第17条の2第4項第2号に掲げられる「特許請求の範囲の減縮(第36条第5項の規定により請求項に記載した発明を特定するために必要な事項を限定するものであつて、その補正前の当該請求項に記載された発明とその補正後の当該請求項に記載される発明の産業上の利用分野及び解決しようとする課題が同一であるものに限る。)」(以下「限定的減縮」と記す。)に該当し、特許法第17条の2第4項第2号に掲げられる事項を目的とするものであるとも言える。

(2)しかしながら、本件補正は、請求項11における「ユーザ機器のセキュア環境のタイプを」を「ユーザ機器のスマートカードのタイプまたはセキュア環境に関するデータ」とする補正事項を含むものであり、該補正後の「スマートカードのタイプまたはセキュア環境に関するデータ」が、概念的に本件補正前の「ユーザ機器のセキュア環境のタイプ」の下位のものになるわけでも、複数の選択肢の一部を削除するものでもないことは明らかであるから、この補正事項は特許請求の範囲の減縮をするものでないことは明らかである。
したがって、当該補正事項は特許法第17条の2第4項第2号に掲げられる事項を目的とするものとは言えない。
また、「スマートカードのタイプまたはセキュア環境に関するデータ」は「ユーザ機器のセキュア環境のタイプ」とは全く異なるものを意味するものであるから、当該補正事項が明瞭でない記載の釈明であるとも言えない。また、仮に明瞭でない記載の釈明であるとしても、当該補正事項に係る拒絶理由が通知されたことは無く、拒絶理由通知に係る拒絶の理由に示す事項についてする補正とも言えない。
したがって、当該補正事項は特許法第17条の2第4項第4号に掲げられる「明りようでない記載の釈明(拒絶理由通知に係る拒絶の理由に示す事項についてするものに限る。)」を目的とするものとも言えない。
また、当該補正事項は、請求項の削除、誤記の訂正にも該当しないことも明らかであり、特許法第17条の2第4項第1号、第3号に掲げられる事項を目的とするものとも言えない。
よって、本件補正は、特許法第17条の2第4項各号に掲げられる事項を目的とするものに限られるものでは無く、平成18年法律第55号改正附則第3条第1項によりなお従前の例によるとされる同法による改正前の特許法第17条の2第4項の規定に違反する。


4.独立特許要件についての検討
上記3.(1)で述べたとおり、本件補正は限定的減縮を目的とするものとも言えるものであるから、本件補正後の請求項1、10、18、19に記載されている事項により特定される発明が特許出願の際独立して特許を受けることができるものであるか否かについて、以下に検討する。

4-1.記載要件(特許法第36条)
上記2.で検討した、本件補正後の請求項1記載の「ユーザ・セキュリティ設定を用いて汎用認証アーキテクチャのネットワーク・アプリケーション機能鍵を、第1共有秘密鍵(Ks_int_NAF)、第2共有秘密鍵(Ks_ext_NAF)及び第3共有秘密鍵(Ks_NAF)から選択することにより決定する決定手段」、補正後の請求項10記載の「ユーザ・セキュリティ設定を用いて汎用認証アーキテクチャのネットワーク・アプリケーション機能鍵を、第1共有秘密鍵(Ks_int_NAF)、第2共有秘密鍵(Ks_ext_NAF)及び第3共有秘密鍵(Ks_NAF)から選択することにより決定する決定手段」、補正後の請求項18記載の「ユーザ・セキュリティ設定を用いて汎用認証アーキテクチャのネットワーク・アプリケーション機能鍵を、第1共有秘密鍵(Ks_int_NAF)、第2共有秘密鍵(Ks_ext_NAF)及び第3共有秘密鍵(Ks_NAF)から選択することにより決定する決定ユニット」、及び、補正後の請求項19記載の「ユーザ・セキュリティ設定を用いて汎用認証アーキテクチャのネットワーク・アプリケーション機能鍵を前記決定ユニットにより、第1共有秘密鍵(Ks_int_NAF)、第2共有秘密鍵(Ks_ext_NAF)及び第3共有秘密鍵(Ks_NAF)から選択することにより決定する決定ステップ」との技術的事項は、本件補正後の発明の詳細な説明にも記載も示唆もされていないものである。
したがって、本件補正後の請求項1、10、18、19の記載は特許法第36条第6項第1号に規定する要件を満たしていないものであるから、本件補正後の請求項1、10、18、19に係る発明は特許出願の際独立して特許を受けることができるものではない。


4-2.進歩性(特許法第29条第2項)

4-2-1.本件補正発明
本件補正後の請求項1に係る発明(以下「本件補正発明」と記す。)は、上記第1.2.(2)において【請求項1】として記載したとおりのものである。

4-2-2.先行技術
(1)上記第1.3.で示したとおり、本願の出願前でありかつ上記優先日よりも前の日に頒布または電気通信回線を通じて公衆に利用可能となり、原審の拒絶の査定の理由である上記平成22年11月26日付けの拒絶理由通知の(理由1)において引用された上記引用文献には上記引用文献記載事項が記載されている。

4-2-3.引用発明の認定
(1)引用文献1には、上記引用文献記載事項1-1のとおり「UEがBSFからNAFへのブートストラッピング情報のプッシングをトリガする、ブートストラッピング・プロシージャ」が記載されているところ、これは上記引用文献記載事項1-2の記載等から「UE、NAF、BSF、HSSが接続されたネットワーク」を前提としているものである。
そして、該「プロシージャ」において該「BSF」が行う手順は、
「UE、NAF、BSF、HSSが接続されたネットワークにおいて、UEがBSFからNAFへのブートストラッピング情報のプッシングをトリガするブートストラッピング・プロシージャにおける該BSFが行う方法」と言えるものであり、
引用文献1には該方法が記載されているとも言える。

(2)引用文献記載事項1-1の「1.(オプション)UEがNAFと連絡をとる。NAFは、それが認証を要求し、かつ、GAAが用いられるべきであるということをUEへ通知する。」とのステップの記載から、
「該プロシージャは前記UEがNAFと連絡をとり、NAFが、認証を要求し、かつ、GAAが用いられるべきであるということをUEへ通知することで開始」すると言える。

(3)引用文献記載事項1-1の「3.UEはIMPIおよびオプションのNAF_IDを伴ったイニシャルHTTPリクエストをBSFへ送る。」とのステップの記載から、上記方法は
「前記UEからイニシャルHTTPリクエストを受け取るステップ」
を有していると言える。

(4)上記引用文献記載事項1-2の「8. BSF pushes the TID, NAF specific key (Ks_naf), and profile (prof_naf) to the NAF indicated by UE.」(当審訳:「8.BSFがUEによって示されたNAFへのTID、NAF固有キー(Ks_naf)とプロフィール(prof_naf)をプッシュする。」)等の記載から、「NAF固有キーKs_NAF」がBSF内で生成されていることは明らかであるところ、引用文献記載事項1-3には該「Ks_NAF」が「Ks_NAF=KDF(Ks,鍵導出パラメーター)として計算」されることも示されている。
したがって、上記方法は
「NAF固有キーKs_NAFをKs_NAF=KDF(Ks,鍵導出パラメーター)として計算するステップ」
を有していると言える。

(5)上記引用文献記載事項1-1の「9.(オプション)NAF固有のブートストラッピング情報がBSFによってNAFへプッシュされる。」との記載及び上記引用文献記載事項1-2の「8. BSF pushes the TID, NAF specific key (Ks_naf), and profile (prof_naf) to the NAF indicated by UE.」との記載などから、上記方法は
「該NAF固有キーが含まれているNAF固有のブートストラッピング情報を前記NAFへプッシュするステップ」
を有していると言える。

(6)よって、引用文献1には、下記引用発明が記載されていると認められる。

<引用発明>
「UE、NAF、BSF、HSSが接続されたネットワークにおいて、該UEが該BSFから該NAFへのブートストラッピング情報のプッシングをトリガするブートストラッピング・プロシージャにおける該BSFが行う方法であって、
該プロシージャは前記UEが前記NAFと連絡をとり、前記NAFが、認証を要求し、かつ、GAAが用いられるべきであるということを前記UEへ通知することで開始し、
前記UEからイニシャルHTTPリクエストを受け取るステップと、
NAF固有キーKs_NAFをKs_NAF=KDF(Ks,鍵導出パラメーター)として計算するステップと、
該NAF固有キーが含まれているNAF固有のブートストラッピング情報を前記NAFへプッシュするステップ
を有する方法。」

4-2-4.対比
以下、本件補正発明と引用発明とを比較する。

(1)引用発明は「UE、NAF、BSF、HSSが接続されたネットワークにおいて、該UEが該BSFから該NAFへのブートストラッピング情報のプッシングをトリガするブートストラッピング・プロシージャにおける該BSFが行う方法」であるところ、該「NAF」や「BSF」がサーバすなわち「装置」において実現されているものであることは明らかであり、引用発明も本件補正発明と同様に「装置によって実現される、ネットワーク・アプリケーション・サーバのための汎用メカニズムを提供する方法」と言えるものである。

(2)引用発明における「前記UEからイニシャルHTTPリクエストを受け取るステップ」は、本件補正発明における「受信ステップ」に対応付けられるものであるところ、前者の「UE」は「ユーザ機器」にほかならないので「イニシャルHTTPリクエスト」は「ユーザ機器からの要求」と言えるものである。
一方、引用発明における「プロシージャ」は「前記UEが前記NAFと連絡をとり、前記NAFが、認証を要求し、かつ、GAAが用いられるべきであるということを前記UEへ通知することで開始」するものであることなどから見て、引用発明において最終的にNAFへプッシュされる「NAF固有のブートストラッピング情報」は「認証情報」とも言えるものであるから、引用発明における「前記UEからイニシャルHTTPリクエストを受け取るステップ」は、「認証情報」を「NAF」へ「プッシュ」するためになされるものととらえることができ、これは本件補正発明の「受信ステップ」における「ネットワーク・アプリケーション機能に認証情報を提供するように」との事項に相当するものである。
したがって、引用発明と本件補正発明とは「ネットワーク・アプリケーション機能に認証情報を提供するようにユーザ機器からの要求を」「受信する受信ステップ」を含む点で共通するといえる。

(3)引用発明における「NAF固有キーKs_NAFをKs_NAF=KDF(Ks,鍵導出パラメーター)として計算するステップ」は本件補正発明における「決定ステップ」に対応付けられるものであるところ、引用発明において計算される「NAF固有キーKs_NAF」は、NAFがUEへ通知した「GAAが用いられるべきである」という事項に基づく「NAF固有」の鍵であるから、「汎用認証アーキテクチャのネットワーク・アプリケーション機能鍵」とも言えるものである。
また、「Ks_NAF=KDF(Ks,鍵導出パラメーター)」であるから、「NAF固有キーKs_NAF」は「マスター共有秘密鍵(Ks)から導出されたもの」とも言える。
したがって、引用発明と本件補正発明とは「汎用認証アーキテクチャのネットワーク・アプリケーション機能鍵を」「決定するステップであって、」該鍵「はマスター共有秘密鍵(Ks)から導出されたものである、決定ステップ」を含む点で共通すると言える。

(4)引用発明における「該NAF固有キーが含まれているNAF固有のブートストラッピング情報を前記NAFへプッシュするステップ」は、本件補正発明における「提供ステップ」に対応付けられるものであるところ、前者の「NAF固有のブートストラッピング情報」は上記(2)でも言及したように「認証情報」と言えるものであるから、引用発明と本件補正発明は、「前記ネットワーク・アプリケーション機能に認証情報を」「提供する提供ステップ」を含む点で共通するといえる。

(5)よって、本件補正発明は、下記一致点で引用発明と一致し、下記相違点で引用発明と相違する。

<一致点>
「装置によって実現される、ネットワーク・アプリケーション・サーバのための汎用メカニズムを提供する方法であって、
ネットワーク・アプリケーション機能に認証情報を提供するようにユーザ機器からの要求を受信する受信ステップと、
汎用認証アーキテクチャのネットワーク・アプリケーション機能鍵を決定するステップであって、該鍵はマスター共有秘密鍵(Ks)から導出されたものである、決定ステップと、
前記ネットワーク・アプリケーション機能に認証情報を提供する提供ステップと、を含む方法。」

<相違点1>
本件補正発明における装置は「受信ユニットと、決定ユニットと、提供ユニットと、を含む」ものであり、本件補正発明における「受信ステップ」「決定ステップ」「提供ステップ」における「受信」「決定」「提供」はそれぞれ、「前記受信ユニット」「前記決定ユニット」「前記提供ユニット」によりなされる。
(これに対し、引用文献1には「受信ユニット」「決定ユニット」「提供ユニット」の明示はない。)

<相違点2>
本件補正発明における「決定ステップ」ではネットワーク・アプリケーション機能鍵を「ユーザ・セキュリティ設定を用いて」、かつ、マスター共有秘密鍵(Ks)から導出された「第1共有秘密鍵(Ks_int_NAF)、第2共有秘密鍵(Ks_ext_NAF)及び第3共有秘密鍵(Ks_NAF)から選択することにより」決定している。
(これに対し、引用文献1(特に引用文献記載事項1-3)には、「鍵導出パラメーター」が「ユーザーのIMSI」を含む旨の記載はあるものの「ユーザ・セキュリティ設定」への言及は無い。また、鍵を複数の秘密鍵から選択する旨の記載も無い。)

4-2-5.判断
以下、上記相違点について検討する。

(1)相違点1について
一連の情報処理を実現する際に、そのための所定の纏まりをもった機能実現手段の組合わせによって実現することは説示するまでもない当業者の常套手段であり、引用発明における「BSF」も「受信ユニットと、決定ユニットと、提供ユニットと、を含む」ものとし、上記「受信」「決定」「提供」が、それぞれ「前記受信ユニット」「前記決定ユニット」「前記提供ユニット」によりなされるものとすること、すなわち上記相違点1に係る構成は、当業者が通常採用する構成にすぎないもので、何ら格別なものではない。

(2)相違点2について
鍵の生成にユーザーのアイデンティティを用いることは通常行われていることであるところ、引用文献記載事項2-1にはこのようなユーザーのアイデンティティをUSS(ユーザー・セキュリティ・セッティング)の一部とすることが記載されており、また、引用文献記載事項2-2にはこのようなUSSに基づいて「Ks_NAF」を導出するアーキテクチャが開示されている。また、引用文献記載事項2-3、2-4には、このようなUSSに基づいて「Ks_ext_NAF」又は「Ks_int_NAF」との2種類の鍵のどちらの種類の鍵を使用すべきかを決定して導出するアーキテクチャが開示されている。
複数のアーキテクチャを選択的に利用できるように所謂兼用化を図ることは、当業者の創作活動において従来から常套の手法であり、引用文献2に接した当業者であれば、引用発明における「NAF固有キー」の決定を、「ユーザ・セキュリティ設定を用いて」、かつ、「マスター共有秘密鍵(Ks)」から導出されると言う共通の特徴をもつ「Ks_ext_NAF」、「Ks_int_NAF」及び「Ks_NAF」と言う複数の共有秘密鍵の中からの選択によって決定する構成とすることは、容易に想起し得たことであり、また、その実現に際して格別な困難性を伴うものでもない。
してみると、引用発明においてもネットワーク・アプリケーション機能鍵を「ユーザ・セキュリティ設定を用いて」し、かつ、マスター共有秘密鍵(Ks)から導出された「第1共有秘密鍵(Ks_int_NAF)、第2共有秘密鍵(Ks_ext_NAF)及び第3共有秘密鍵(Ks_NAF)から選択することにより」決定するように構成すること、すなわち、上記相違点2に係る構成を採用することも、当業者であれば容易に想到し得たことである。

(3)したがって、本件補正発明の構成は引用文献1、2記載の発明に基づいて、当業者が容易に想到し得たものである。
そして、当該構成の採用によって奏される作用効果も、当業者であれば容易に予測し得る程度のものであって、格別顕著なものではない。
よって、本件補正発明は、引用文献1、2記載の発明に基づいて、当業者が容易に発明をすることができたものである。
また、本件補正後の請求項10、18、19に係る発明も同様に引用文献1、2記載の発明に基づいて、当業者が容易に発明をすることができたものである。

4-2-6.小結
以上のとおり、本件補正後の請求項1、10、18、19に係る発明は、その出願前に日本国内又は外国において頒布された刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基づいて、その発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、本件補正後の請求項1、10、18、19に係る発明は特許出願の際独立して特許を受けることができるものではない。


4-3.中結
上記4-1.及び4-2.で述べたとおり、本件補正後の請求項1、10、18、19に係る発明は特許出願の際独立して特許を受けることができるものではないので、本件補正は平成18年法律第55号改正附則第3条第1項によりなお従前の例によるとされる同法による改正前の特許法第17条の2第5項において準用する同法第126条第5項の規定に違反する


5.むすび
上記2.で述べたとおり、本件補正は特許法第17条の2第3項の規定に違反するので、同法第159条第1項において読み替えて準用する同法第53条第1項の規定により却下すべきものである。

上記3.で述べたとおり、本件補正は平成18年法律第55号改正附則第3条第1項によりなお従前の例によるとされる同法による改正前の特許法第17条の2第4項の規定に違反するので、この理由によっても、同法第159条第1項において読み替えて準用する同法第53条第1項の規定により却下すべきものである。

上記4.で述べたとおり、本件補正は平成18年法律第55号改正附則第3条第1項によりなお従前の例によるとされる同法による改正前の特許法第17条の2第5項において準用する同法第126条第5項の規定に違反するので、この理由によっても、同法第159条第1項において読み替えて準用する同法第53条第1項の規定により却下すべきものである。

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



第3.本件審判請求の成否について

1.手続きの経緯、本願発明の認定
本願の手続きの経緯は上記第1.1.のとおりのものであり、さらに、平成23年9月5日付けの手続補正は上記第2.のとおり却下された。
したがって、本願の特許請求の範囲は、上記第1.2.(1)に記載したとおりのものであり、その請求項1に係る発明(以下「本願発明」と記す。)はそこに【請求項1】として記載したとおりのものである。

2.先行技術・引用発明の認定
上記第1.3.に示したとおり、本願の出願前でありかつ上記優先日よりも前の日に頒布または電気通信回線を通じて公衆に利用可能となり、原審の拒絶の査定の理由である上記平成22年11月26日付けの拒絶理由通知の(理由1)において引用された上記引用文献には上記引用文献記載事項が記載されており、上記引用文献1には上記第2.4-2-3.で認定したとおりの引用発明が記載されていると認められる。

3.対比・判断
上記第2.4-2.で検討した本件補正発明は、本願発明に対し上記第2.3.(1)で述べた限定的減縮をしたものと実質的に同じ発明であり、本願発明は、上記本件補正発明から当該限定的減縮により限定される要件を無くしたものに相当する。
そして、本願発明の構成要件を全て含み、さらに他の要件を付加したものに相当する上記本件補正発明は、上記第2.4-2.で論じたとおり、上記引用文献1、2記載の発明に基づいて、当業者が容易に発明をすることができたものである。
したがって、本願発明も同様の理由により、上記引用文献1、2記載の発明に基づいて、当業者が容易に発明をすることができたものである。
また、本願請求項10、18、19に係る発明も同様に引用文献1、2記載の発明に基づいて、当業者が容易に発明をすることができたものである。

4.むすび
以上のとおり、本願請求項1、10、18、19に係る発明は、その出願前に日本国内又は外国において頒布された刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて、当業者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができないものであり、他の請求項についての検討をするまでもなく、本願を拒絶すべきものとした原審の拒絶査定は妥当なものである。

よって、上記結論のとおり審決する。
 
審理終結日 2013-04-12 
結審通知日 2013-04-16 
審決日 2013-05-01 
出願番号 特願2008-505973(P2008-505973)
審決分類 P 1 8・ 575- Z (H04L)
P 1 8・ 574- Z (H04L)
P 1 8・ 536- Z (H04L)
P 1 8・ 121- Z (H04L)
P 1 8・ 572- Z (H04L)
P 1 8・ 561- Z (H04L)
最終処分 不成立  
前審関与審査官 松平 英  
特許庁審判長 山崎 達也
特許庁審判官 石井 茂和
仲間 晃
発明の名称 GAAのための汎用鍵の決定メカニズム  
代理人 下道 晶久  
代理人 森 啓  
代理人 鶴田 準一  
代理人 青木 篤  

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