【事件の表示】
　特願２００８−５０５９７３「ＧＡＡのための汎用鍵の決定メカニズム」拒絶査定不服審判事件〔平成１８年１０月１９日国際公開、ＷＯ２００６／１０９１２２、平成２０年１０月２３日国内公表、特表２００８−５３８４７１〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１．手続の経緯等
　
１．手続の経緯の概要
　本願は、
２００５年４月１１日（以下「優先日」と記す。）のアメリカ合衆国での出願を基礎とするパリ条約に基づく優先権主張を伴って、
２００６年４月４日に国際出願された出願であって、
平成１９年１０月１０日付けで特許法第１８４条の５第１項の規定による書面が提出され、
平成１９年１２月１０日付けで特許法第１８４条の４第１項の規定による翻訳文が提出されるとともに、同日付けで審査請求がなされ、
平成２２年１１月２６日付けで拒絶理由通知（平成２２年１２月７日発送）がなされ、
平成２３年３月７日付けで意見書が提出されるとともに、同日付けで手続補正書が提出され、
平成２３年５月１７日付けで拒絶査定（平成２３年５月２４日発送）がなされ、
平成２３年９月５日付けで審判請求がされるとともに、同日付けで手続補正書が提出されたものである。
　
　なお、
平成２３年９月２９日付けで特許法第１６４条第３項に定める報告（前置報告）がなされ、
平成２３年１２月２２日付けで当該報告に対する意見を求める旨の審尋（平成２４年１月１０日発送)がなされ、これに対して
平成２４年４月５日付けで回答書が提出されている。
　
　
２．補正の内容
（１）平成２３年３月７日付け手続補正
　上記平成２３年３月７日付けの手続補正書は特許請求の範囲を以下のとおりに補正するものである。
「　【請求項１】
　受信ユニットと、決定ユニットと、提供ユニットと、を含む装置によって実現される、ネットワーク・アプリケーション・サーバのための汎用メカニズムを提供する方法であって、
　ネットワーク・アプリケーション機能に認証情報を提供するようにユーザ機器からの要求を前記受信ユニットにより受信するステップと、
　ユーザ・セキュリティ設定を用いて汎用認証アーキテクチャのネットワーク・アプリケーション機能鍵を前記決定ユニットにより決定するステップと、
　前記ネットワーク・アプリケーション機能に認証情報を前記提供ユニットにより提供するステップと、を含む方法。
　　【請求項２】
　前記提供ステップは、前記ユーザ・セキュリティ設定におけるユーザ機器のスマートカードのタイプまたはセキュリティ環境に関連するデータを提供し、
　ユニバーサル・モバイル・テレコミュニケーション・システム集積回路カード（UICC）に基づいて強化された汎用ブートストラッピング・アーキテクチャ（GBA_U）が、汎用加入者識別モジュール、加入者識別モジュール、インターネットプロトコル・マルチメディア・サブシステム、加入者識別モジュール（IMS SIM）カード、又は、別のセキュア環境を実施可能にするか否かを示すフラグ・フィールドを提供することを含む、請求項１に記載の方法。
　　【請求項３】
　前記提供ステップは、認証情報の認証ヘッダ中で送られるユーザ・セキュリティ設定における第１及び第２フラグ・フィールドを提供することを含み、
　前記第１フラグ・フィールドにおいては、ユニバーサル・モバイル・テレコミュニケーション・システム集積回路カード（UICC）に基づいて強化された汎用ブートストラッピング・アーキテクチャ（GBA_U）における第１導出鍵（Ks_int_NAF）が使用され、
　前記第２フラグ・フィールドにおいては、第２導出鍵（Ks_ext_NAF）または第３導出鍵（Ks_NAF）が使用される、請求項１に記載の方法。
　　【請求項４】
　前記決定ステップは、
　ネットワーク・アプリケーション機能の設定の間に、前記ネットワーク・アプリケーション機能に直接、局所的に鍵の使用法を設定することと、
　ブートストラッピング・サーバ機能に直接、局所的に鍵の使用法を設定することの、少なくとも一方を決定することと、
　ブートストラッピング・サーバ機能に送られるホーム加入者サーバに格納されたユーザ・セキュリティ設定に追加のフィールドを使用することと、
　鍵の使用法を示すブートストラッピング・サーバ機能に格納された属性値ペアを用いることと、を含む、請求項１に記載の方法。
　　【請求項５】
　使用される導出鍵のタイプ、あるいは、スマートカードまたは実現可能なセキュア環境のタイプを示す属性値ペアを使用し、
　前記導出鍵のタイプは、Ks_int_NAF、Ks_ext_NAFまたはKs_NAFを含み、
　前記スマートカードまたはセキュア環境はGBA_Uにより構成される、請求項４に記載の方法。
　　【請求項６】
　前記属性値ペアがKs_int_NAFの使用を示す場合は、前記決定ステップは、セキュリティ・レベルがより低い鍵が使用されないように、前記ネットワーク・アプリケーション機能によるKs_int_NAFの使用を要求することを含む、請求項５に記載の方法。
　　【請求項７】
　ウェブ・サーバがセキュア環境にある場合は、前記決定するステップは、ネットワーク・アプリケーションをユニバーサル・モバイル・テレコミュニケーション・システム（UMTS）集積回路カード（UICC）にさらに配置することを更に含み、
　前記UICCは前記ネットワーク・アプリケーション機能であり、
　生成された鍵（Ks_int_NAF）は、ウェブ・サービス事業体間の通信の保護のために使用される、請求項２に記載の方法。
　　【請求項８】
　前記ネットワーク・アプリケーションを配置する前記配置ステップは、ジャバ・アプリケーション、XMLアプリケーション、C++アプリケーション、パール・アプリケーション、またはビジュアル・ベーシック・アプリケーションを含む、請求項７に記載の方法。
　　【請求項９】
　ホーム加入者サーバ（HSS）に格納されたユーザ・セキュリティ設定に追加のフィールドを提供することにより、ブートストラッピング・サーバ機能（BSF）に局所的に鍵の使用法を前記装置により設定するステップを更に含む請求項１に記載の方法。
　　【請求項１０】
　ネットワーク・アプリケーション・サーバのための汎用メカニズムを提供する装置であって、
　ネットワーク・アプリケーション機能に認証情報を提供するようにユーザ機器からの要求を受信する受信手段と、
　ユーザ・セキュリティ設定を用いて汎用認証アーキテクチャのネットワーク・アプリケーション機能鍵を決定する決定手段と、
　前記ネットワーク・アプリケーション機能に認証情報を提供する第１提供手段と、を備える装置。
　　【請求項１１】
　ユーザ・セキュリティ設定においてユーザ機器のセキュア環境のタイプを提供する第２提供手段と、
　ユニバーサル・モバイル・テレコミュニケーション・システム集積回路カード（UICC）に基づいて強化された汎用ブートストラッピング・アーキテクチャ（GBA_U）が、汎用加入者識別モジュール、加入者識別モジュール、セキュア環境あるいはIMS SIMカードを実施可能にするか否かを示すフラグ・フィールドを提供する第３提供手段と、をさらに備える請求項１０に記載の装置。
　　【請求項１２】
　認証情報の認証ヘッダ中で送られるユーザ・セキュリティ設定内の第１及び第２フラグ・フィールドを提供する第２提供手段をさらに備え、
　前記第１フラグ・フィールドにおいては、ユニバーサル・モバイル・テレコミュニケーション・システム集積回路カード（UICC）に基づいて強化された汎用ブートストラッピング・アーキテクチャ（GBA_U）における第１導出鍵（Ks_int_NAF）が使用され、
　前記第２フラグ・フィールドにおいては、第２導出鍵（Ks_ext_NAF）または第３導出鍵（Ks_NAF）が使用される、請求項１０に記載の装置。
　　【請求項１３】
　前記汎用メカニズムは、
　ネットワーク・アプリケーション機能の設定の間に、前記ネットワーク・アプリケーション機能に直接、局所的に鍵の使用法を設定する第１ハード・コード手段、または、ブートストラッピング・サーバ機能に局所的に鍵の使用法を設定する第２ハード・コード手段の少なくとも一方と、
　ブートストラッピング・サーバ機能に送られるホーム加入者サーバに格納されたユーザ・セキュリティ設定に追加のフィールドを提供する第２提供手段と、
　鍵の使用法を示すブートストラッピング・サーバ機能に格納された属性値ペアを用いる第１使用手段と、を備える、請求項１０に記載の装置。
　　【請求項１４】
　使用される導出鍵のタイプ、あるいは、スマートカードまたは実現可能なセキュア環境のタイプを示す属性値を使用する第２使用手段をさらに備え、
　前記導出鍵のタイプは、Ks_int_NAF、Ks_ext_NAFまたはKs_NAFを含み、
　前記スマートカードまたはセキュア環境はGBA_Uにより構成される、請求項１３に記載の装置。
　　【請求項１５】
　前記属性値ペアがKs_int_NAFの使用を示す場合は、前記ネットワーク・アプリケーション機能は、セキュリティ・レベルがより低い鍵ではなく、Ks_int_NAFが使用されるようにさらに要求する、請求項１４に記載の装置。
　　【請求項１６】
　ウェブ・サーバが、前記スマートカードまたはセキュア環境にある場合は、ネットワーク・アプリケーションをユニバーサル・モバイル・テレコミュニケーション・システム（UMTS）集積回路カード（UICC）にさらに配置する配置手段をさらに有し、
　前記UICCは前記ネットワーク・アプリケーション機能であり、導出された鍵（Ks_int_NAF）は、ウェブ・サービス事業体間の通信の保護のために使用される、請求項１１に記載の装置。
　　【請求項１７】
　ホーム加入者サーバ（HSS）に格納されたユーザ・セキュリティ設定に追加のフィールドを提供することにより、ブートストラッピング・サーバ機能（BSF）に局所的に鍵の使用法を設定する第３ハード・コード手段をさらに備える請求項１０に記載の装置。
　　【請求項１８】
　ネットワーク・アプリケーション・サーバのための汎用メカニズムを提供するための装置であって、
　ネットワーク・アプリケーション機能に認証情報を提供するようにユーザ機器からの要求を受信する受信ユニットと、
　ユーザ・セキュリティ設定を用いて汎用認証アーキテクチャのネットワーク・アプリケーション機能鍵を決定する決定ユニットと、
　前記ネットワーク・アプリケーション機能に認証情報を提供する提供ユニットと、を備える装置。
　　【請求項１９】
　コンピュータ読み取り可能な媒体に具体化された、受信ユニットと、決定ユニットと、提供ユニットと、を含む装置によって実現される、ネットワーク・アプリケーション・サーバのための汎用メカニズムを提供するためのコンピュータ・プログラムであって、
　ネットワーク・アプリケーション機能に認証情報を提供するようにユーザ機器からの要求を前記受信ユニットにより受信するステップと、
　ユーザ・セキュリティ設定を用いて汎用認証アーキテクチャのネットワーク・アプリケーション機能鍵を前記決定ユニットにより決定するステップと、
　前記ネットワーク・アプリケーション機能に認証情報を前記提供ユニットにより提供するステップと、を実行するように構成されたコンピュータ・プログラム。
　　【請求項２０】
　前記提供ステップは、ユーザ・セキュリティ設定においてユーザ機器のスマートカードのタイプまたはセキュア環境に関連するデータを提供するステップと、
　ユニバーサル・モバイル・テレコミュニケーション・システム集積回路カード（UICC）に基づいて強化された汎用ブートストラッピング・アーキテクチャ（GBA_U）が、汎用加入者識別モジュール、加入者識別モジュール、セキュア環境、インターネットプロトコル・マルチメディア・サブシステム、加入者識別モジュール（IMS SIM）カードを実施可能にするか否かを示すフラグ・フィールドを提供することを含む、請求項１９に記載のコンピュータ・プログラム。
　　【請求項２１】
　前記提供ステップは、認証情報の認証ヘッダ中で送られるユーザ・セキュリティ設定における第１及び第２フラグ・フィールドを提供することを含み、
　前記第１フラグ・フィールドにおいては、ユニバーサル・モバイル・テレコミュニケーション・システム集積回路カード（UICC）に基づいて強化された汎用ブートストラッピング・アーキテクチャ（GBA_U）における第１導出鍵（Ks_int_NAF）が使用され、
　前記第２フラグ・フィールドにおいては、第２導出鍵（Ks_ext_NAF）または第３導出鍵（Ks_NAF）が使用される、請求項１９に記載のコンピュータ・プログラム。
　　【請求項２２】
　前記決定ステップは、ネットワーク・アプリケーション機能の設定の間に、
　前記ネットワーク・アプリケーション機能に直接、局所的に鍵の使用法を設定することと、ブートストラッピング・サーバ機能に直接、局所的に鍵の使用法を設定することと、の少なくとも一方を決定することと、
　ブートストラッピング・サーバ機能に送られるホーム加入者サーバに格納されたユーザ・セキュリティ設定に追加のフィールドを提供することと、
　鍵の使用法を示すブートストラッピング・サーバ機能に格納された属性値ペアを用いることと、を含む、請求項１９に記載のコンピュータ・プログラム。
　　【請求項２３】
　前記決定ステップは、使用される導出鍵のタイプ、あるいは、スマートカードのタイプまたは実現可能なセキュア環境を示す属性値を使用することを含み、
　前記導出鍵のタイプは、Ks_int_NAF、Ks_ext_NAFまたはKs_NAFを含み、前記スマートカードまたはセキュア環境はGBA_Uにより構成される、請求項２２に記載のコンピュータ・プログラム。
　　【請求項２４】
　前記属性値ペアがKs_int_NAFの使用を示す場合は、前記決定ステップは、セキュリティ・レベルがより低い鍵が使用されないように、前記ネットワーク・アプリケーション機能によるKs_int_NAFの使用を要求することを含む、請求項２３に記載のコンピュータ・プログラム。
　　【請求項２５】
　ウェブ・サーバが前記スマートカードまたはセキュア環境にある場合は、前記決定するステップは、ネットワーク・アプリケーションをユニバーサル・モバイル・テレコミュニケーション・システム（UMTS）集積回路カード（UICC）に配置することをを更に含み、
　前記UICCは前記ネットワーク・アプリケーション機能であり、
　生成された鍵（Ks_int_NAF）は、ウェブ・サービス事業体間の通信の保護のために使用される、請求項２０に記載のコンピュータ・プログラム。
　　【請求項２６】
　前記ネットワーク・アプリケーションを配置する前記配置ステップは、ジャバ・アプリケーション、XMLアプリケーション、C++アプリケーション、パール・アプリケーション、またはビジュアル・ベーシック・アプリケーションを含む、請求項２５に記載のコンピュータ・プログラム。
　　【請求項２７】
　前記プロセスは、ホーム加入者サーバ（HSS）に格納されたユーザ・セキュリティ設定に追加のフィールドを提供することにより、ブートストラッピング・サーバ機能（BSF）に局所的に鍵の使用法を前記装置により設定するステップをさらに含む、請求項１９に記載のコンピュータ・プログラム。」
　
（２）平成２３年９月５日付け手続補正
　上記平成２３年９月５日付けの手続補正書は特許請求の範囲を以下のとおりに補正しようとするものである。
「　【請求項１】
　受信ユニットと、決定ユニットと、提供ユニットと、を含む装置によって実現される、ネットワーク・アプリケーション・サーバのための汎用メカニズムを提供する方法であって、
　ネットワーク・アプリケーション機能に認証情報を提供するようにユーザ機器からの要求を前記受信ユニットにより受信する
受信ステップ
　ユーザ・セキュリティ設定を用いて汎用認証アーキテクチャのネットワーク・アプリケーション機能鍵を前記決定ユニットにより
、第１共有秘密鍵（Ks_int_NAF）、第２共有秘密鍵（Ks_ext_NAF）及び第３共有秘密鍵（Ks_NAF）から選択することにより決定するステップであって、前記第１共有秘密鍵（Ks_int_NAF）、前記第２共有秘密鍵（Ks_ext_NAF）及び前記第３共有秘密鍵（Ks_NAF）はマスター共有秘密鍵（Ks）から導出されたものである、決定ステップ
　前記ネットワーク・アプリケーション機能に認証情報を前記提供ユニットにより提供する
提供ステップ
　　【請求項２】
　前記提供ステップは、前記ユーザ・セキュリティ設定におけるユーザ機器のスマートカードのタイプまたはセキュリティ環境に関連するデータを提供し、
　ユニバーサル・モバイル・テレコミュニケーション・システム集積回路カード（UICC）に基づいて強化された汎用ブートストラッピング・アーキテクチャ（GBA_U）が、汎用加入者識別モジュール、加入者識別モジュール、インターネットプロトコル・マルチメディア・サブシステム、加入者識別モジュール（IMS SIM）カード、又は、別のセキュア環境を実施可能にするか否かを示すフラグ・フィールドを提供することを含む、請求項１に記載の方法。
　　【請求項３】
　前記提供ステップは、認証情報の認証ヘッダ中で送られるユーザ・セキュリティ設定における第１及び第２フラグ・フィールドを提供することを含み、
　前記第１フラグ・フィールドにおいては、ユニバーサル・モバイル・テレコミュニケーション・システム集積回路カード（UICC）に基づいて強化された汎用ブートストラッピング・アーキテクチャ（GBA_U）における第１
共有秘密
　前記第２フラグ・フィールドにおいては、第２
共有秘密
共有秘密
　　【請求項４】
　前記決定ステップは、
　ネットワーク・アプリケーション機能の設定の間に、前記ネットワーク・アプリケーション機能に直接、局所的に
共有秘密
　ブートストラッピング・サーバ機能に直接、局所的に
共有秘密
　ブートストラッピング・サーバ機能に送られるホーム加入者サーバに格納されたユーザ・セキュリティ設定に追加のフィールドを使用することと、
　
共有秘密
　　【請求項５】
　使用される
共有秘密
　前記
共有秘密
　前記スマートカードまたはセキュア環境はGBA_Uにより構成される、請求項４に記載の方法。
　　【請求項６】
　前記属性値ペアがKs_int_NAFの使用を示す場合は、前記決定ステップは、セキュリティ・レベルがより低い
共有秘密
　　【請求項７】
　ウェブ・サーバがセキュア環境にある場合は、前記決定するステップは、ネットワーク・アプリケーションをユニバーサル・モバイル・テレコミュニケーション・システム（UMTS）集積回路カード（UICC）にさらに配置する
配置ステップ
　前記UICCは前記ネットワーク・アプリケーション機能であり、
　
共有秘密
　　【請求項８】
　前記ネットワーク・アプリケーションを配置する前記配置ステップは、ジャバ・アプリケーション、XMLアプリケーション、C++アプリケーション、パール・アプリケーション、またはビジュアル・ベーシック・アプリケーションを含む、請求項７に記載の方法。
　　【請求項９】
　ホーム加入者サーバ（HSS）に格納されたユーザ・セキュリティ設定に追加のフィールドを提供することにより、ブートストラッピング・サーバ機能（BSF）に局所的に
共有秘密
　　【請求項１０】
　ネットワーク・アプリケーション・サーバのための汎用メカニズムを提供する装置であって、
　ネットワーク・アプリケーション機能に認証情報を提供するようにユーザ機器からの要求を受信する受信手段と、
　ユーザ・セキュリティ設定を用いて汎用認証アーキテクチャのネットワーク・アプリケーション機能鍵を
、第１共有秘密鍵（Ks_int_NAF）、第２共有秘密鍵（Ks_ext_NAF）及び第３共有秘密鍵（Ks_NAF）から選択することにより決定する決定手段であって、前記第１共有秘密鍵（Ks_int_NAF）、前記第２共有秘密鍵（Ks_ext_NAF）及び前記第３共有秘密鍵（Ks_NAF）はマスター共有秘密鍵（Ks）から導出されたものである、決定手段
　前記ネットワーク・アプリケーション機能に認証情報を提供する第１提供手段と、を備える装置。
　　【請求項１１】
　ユーザ・セキュリティ設定に
おける
スマートカードのタイプまたは
に関するデータ
　ユニバーサル・モバイル・テレコミュニケーション・システム集積回路カード（UICC）に基づいて強化された汎用ブートストラッピング・アーキテクチャ（GBA_U）が、汎用加入者識別モジュール、加入者識別モジュール、セキュア環境あるいはIMS SIMカードを実施可能にするか否かを示すフラグ・フィールドを提供する第３提供手段と、をさらに備える請求項１０に記載の装置。
　　【請求項１２】
　認証情報の認証ヘッダ中で送られるユーザ・セキュリティ設定内の第１及び第２フラグ・フィールドを提供する第２提供手段をさらに備え、
　前記第１フラグ・フィールドにおいては、ユニバーサル・モバイル・テレコミュニケーション・システム集積回路カード（UICC）に基づいて強化された汎用ブートストラッピング・アーキテクチャ（GBA_U）における第１
共有秘密
　前記第２フラグ・フィールドにおいては、第２
共有秘密
共有秘密
　　【請求項１３】
　前記汎用メカニズムは、
　ネットワーク・アプリケーション機能の設定の間に、前記ネットワーク・アプリケーション機能に直接、局所的に
共有秘密
共有秘密
　ブートストラッピング・サーバ機能に送られるホーム加入者サーバに格納されたユーザ・セキュリティ設定に追加のフィールドを提供する第２提供手段と、
　
共有秘密
　　【請求項１４】
　使用される
共有秘密
　前記
共有秘密
　前記スマートカードまたはセキュア環境はGBA_Uにより構成される、請求項１３に記載の装置。
　　【請求項１５】
　前記属性値ペアがKs_int_NAFの使用を示す場合は、前記ネットワーク・アプリケーション機能は、セキュリティ・レベルがより低い
共有秘密
　　【請求項１６】
　ウェブ・サーバが、前記スマートカードまたはセキュア環境にある場合は、ネットワーク・アプリケーションをユニバーサル・モバイル・テレコミュニケーション・システム（UMTS）集積回路カード（UICC）にさらに配置する配置手段をさらに有し、
　前記UICCは前記ネットワーク・アプリケーション機能であり、
第１共有秘密
　　【請求項１７】
　ホーム加入者サーバ（HSS）に格納されたユーザ・セキュリティ設定に追加のフィールドを提供することにより、ブートストラッピング・サーバ機能（BSF）に局所的に
共有秘密
　　【請求項１８】
　ネットワーク・アプリケーション・サーバのための汎用メカニズムを提供するための装置であって、
　ネットワーク・アプリケーション機能に認証情報を提供するようにユーザ機器からの要求を受信する受信ユニットと、
　ユーザ・セキュリティ設定を用いて汎用認証アーキテクチャのネットワーク・アプリケーション機能鍵を
、第１共有秘密鍵（Ks_int_NAF）、第２共有秘密鍵（Ks_ext_NAF）及び第３共有秘密鍵（Ks_NAF）から選択することにより決定する決定ユニットであって、前記第１共有秘密鍵（Ks_int_NAF）、前記第２共有秘密鍵（Ks_ext_NAF）及び前記第３共有秘密鍵（Ks_NAF）はマスター共有秘密鍵（Ks）から導出されたものである、決定ユニット
　前記ネットワーク・アプリケーション機能に認証情報を提供する提供ユニットと、を備える装置。
　　【請求項１９】
　コンピュータ読み取り可能な媒体に具体化された、受信ユニットと、決定ユニットと、提供ユニットと、を含む装置によって実現される、ネットワーク・アプリケーション・サーバのための汎用メカニズムを提供するためのコンピュータ・プログラムであって、
　ネットワーク・アプリケーション機能に認証情報を提供するようにユーザ機器からの要求を前記受信ユニットにより受信する
受信ステップ
　ユーザ・セキュリティ設定を用いて汎用認証アーキテクチャのネットワーク・アプリケーション機能鍵を前記決定ユニットにより
、第１共有秘密鍵（Ks_int_NAF）、第２共有秘密鍵（Ks_ext_NAF）及び第３共有秘密鍵（Ks_NAF）から選択することにより決定する決定ステップであって、前記第１共有秘密鍵（Ks_int_NAF）、前記第２共有秘密鍵（Ks_ext_NAF）及び前記第３共有秘密鍵（Ks_NAF）はマスター共有秘密鍵（Ks）から導出されたものである、決定ステップ
　前記ネットワーク・アプリケーション機能に認証情報を前記提供ユニットにより提供する
提供ステップ
　　【請求項２０】
　前記提供ステップは、ユーザ・セキュリティ設定においてユーザ機器のスマートカードのタイプまたはセキュア環境に関連するデータを提供するステップと、
　ユニバーサル・モバイル・テレコミュニケーション・システム集積回路カード（UICC）に基づいて強化された汎用ブートストラッピング・アーキテクチャ（GBA_U）が、汎用加入者識別モジュール、加入者識別モジュール、セキュア環境、インターネットプロトコル・マルチメディア・サブシステム、加入者識別モジュール（IMS SIM）カードを実施可能にするか否かを示すフラグ・フィールドを提供することを含む、請求項１９に記載のコンピュータ・プログラム。
　　【請求項２１】
　前記提供ステップは、認証情報の認証ヘッダ中で送られるユーザ・セキュリティ設定における第１及び第２フラグ・フィールドを提供することを含み、
　前記第１フラグ・フィールドにおいては、ユニバーサル・モバイル・テレコミュニケーション・システム集積回路カード（UICC）に基づいて強化された汎用ブートストラッピング・アーキテクチャ（GBA_U）における第１
共有秘密
　前記第２フラグ・フィールドにおいては、第２
共有秘密
共有秘密
　　【請求項２２】
　前記決定ステップは、ネットワーク・アプリケーション機能の設定の間に、
　前記ネットワーク・アプリケーション機能に直接、局所的に
共有秘密
共有秘密
　ブートストラッピング・サーバ機能に送られるホーム加入者サーバに格納されたユーザ・セキュリティ設定に追加のフィールドを提供することと、
　
共有秘密
　　【請求項２３】
　前記決定ステップは、使用される
共有秘密
　前記
共有秘密
　　【請求項２４】
　前記属性値ペアがKs_int_NAFの使用を示す場合は、前記決定ステップは、セキュリティ・レベルがより低い
共有秘密
　　【請求項２５】
　ウェブ・サーバが前記スマートカードまたはセキュア環境にある場合は、前記決定するステップは、ネットワーク・アプリケーションをユニバーサル・モバイル・テレコミュニケーション・システム（UMTS）集積回路カード（UICC）に配置する
配置ステップ
　前記UICCは前記ネットワーク・アプリケーション機能であり、
　
第１共有秘密
　　【請求項２６】
　前記ネットワーク・アプリケーションを配置する前記配置ステップは、ジャバ・アプリケーション、XMLアプリケーション、C++アプリケーション、パール・アプリケーション、またはビジュアル・ベーシック・アプリケーションを含む、請求項２５に記載のコンピュータ・プログラム。
　　【請求項２７】
　ホーム加入者サーバ（HSS）に格納されたユーザ・セキュリティ設定に追加のフィールドを提供することにより、ブートストラッピング・サーバ機能（BSF）に局所的に
共有秘密
実行するように構成された
　
　
３．引用文献
　
　本願の出願前でありかつ上記優先日よりも前の日に頒布または電気通信回線を通じて公衆に利用可能となり、原審の拒絶の査定の理由である上記平成２２年１１月２６日付けの拒絶理由通知の（理由１）において引用された、下記引用文献には、下記引用文献記載事項が記載されている。（下線は当審付与。）
　
＜引用文献１＞
「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:http://www.3gpp.com/ftp/tsg_sa/WG3_Security/TSGS3_32_Edinburgh/Docs/PDF/S3-040076.pdf
　
　＜引用文献記載事項１−１＞
「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. 
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.」（第２ページ第１行〜第３ページ第８行）
（当審訳：「２．３　プロシージャ詳細
図１は、
UEがBSFからNAFへのブートストラッピング情報のプッシングをトリガする、ブートストラッピング・プロシージャ
　
１．（オプション）UEがNAFと連絡をとる。NAFは、それが認証を要求し、かつ、GAAが用いられるべきであるということをUEへ通知する
２．UEが、ブートストラッピング・プロシージャを行う準備をする。UEがNAFを既に知っているならば、それはイニシャルブートストラッピングメッセージ３内にNAF_IDを加えてもよい。
３．UEはIMPIおよびオプションのNAF_IDを伴ったイニシャルHTTPリクエストをBSFへ送る。
４−５．（オプション）BSFはHSSから認証ベクトルAVとプロファイル情報をフェッチする。オプションとして、BSFがUEのためのAVを既に持っているならば、ステップ４と５をすべてスキップしてもよい。
６−７．通常のHTTPダイジェストAKAステップが行われる。そして、新しいブートストラッピング情報が確立される。
注：ステップ８−１０はオプションであり、ステップ３のイニシャルブートストラッピングリクエスト中でオプションのNAF_IDが与えられた場合のみ行われる。
８．（オプション）NAF_IDがイニシャルHTTPリクエスト（ステップ２）の中にあった場合、その時にはBSFは、NAF_IDによって識別されるNAFへブートストラッピング情報をプッシュする。
９．（オプション）NAF固有のブートストラッピング情報がBSFによってNAFへプッシュされる
１０．（オプション）NAFは、ブートストラッピング情報が受信され格納された旨の肯定応答をする。
１１．TIDを伴なうHTTPレスポンス２００OKがブートストラッピングプロシージャが成功したことを通知するためにUEに送られる。オプションの自発的なプッシュオペレーションが成功したか否かの通知はない。
１２．UEがNAFと連絡をとる。NAFがTIDによって識別されたブートストラッピング情報を既に持つ場合、Znインターフェース上のBSFからブートストラッピング情報をフェッチする必要はない。ブートストラッピング情報がNAF中で示されていない場合、それはZnインターフェース上のBSFから情報をフェッチする。」）
　
　＜引用文献記載事項１−２＞
「
　　　　　　　　　　　　　　　　　　　　　　」（第２頁のFigure 1）
　
　＜引用文献記載事項１−３＞
「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.
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部分の第６ページ第３行〜第９ページ第１８行）
（当審訳：「４．３．２　ブートストラッピング　プロシージャ
　あるUEがあるNAFと対話を望み、それがブートストラッピング・プロシージャが必要なことを認識しているとき、それは最初にブートストラッピング認証を行うものとする（図４を参照）。
編集者の注：プロシージャに関連付けられたZhインターフェースは、将来の開発においてここに加えられるだろう。それは、TS 29.228で明示されるCxインターフェースを再度用いるかもしれない。
　その他には、UEは、NAF（４．３．３副節参照）からのメッセージあるいは鍵更新指示を要求されるブートストラッピング・イニシエーションをそれが受信したときのみ、ブートストラッピング認証を行うものとする。
１．UEがBSFへのHTTPリクエストを送信する。そのリクエストはユーザーの識別を含んでいる。リクエストはNAF識別子を含んでいてもよい。
２．BSFはHSSからZhインターフェースを通じてユーザープロファイルとチャレンジ、すなわち認証ベクトル(AV,AV=RAND||AUTN||XRES||CK||IK)を引き出す。
３．その時、BSFは、４０１メッセージ（CK,IKとXRESは伴わない）内のUEへのRANDとAUTNを転送する。これはUEに自身を認証することを要求するものである。
４．UEは認証されたネットワークからのチャレンジを確認するのと同様に、メッセージ確認コード(MAC)を計算する。UEはまたCK、IKとRESを計算する。これは、BSFとUEの両方の中のセッションキーIKとCKになる。
５．UEは、BSFに対するレスポンスとしてのダイジェストAKA RESを用いて、リクエストを再び送る。
６．RESがAV内にあるXRESに等しい場合、UEが認証される。
７．BSFがCKとIKの連結により鍵マテリアルKsを生成する。Ksは鍵マテリアルKs_NAFを導出するために用いられる。Ks_NAFはUaインターフェースを安全にするために用いられる。
８．NAF識別子がイニシャルブートストラッピング・リクエストの中にあった場合、BSFは、NAF識別子によって識別されたNAFに、TID、KsとNAF固有のユーザプロフィールをプッシュする。
９．BSFはUEへ認証の成功を示すために、200 OKメッセージを送るべきであり、トランザクション識別子を供給すべきである。BSFは、またUbインターフェース上のUEへNAF_Id_n（次のブレット参照）を決めるために用いられるパラメーターnを供給してもよい。パラメーターnが供給されない場合、鍵導出は遂行されない、つまり、Ks=Ks_NAF。
１０．鍵マテリアルKsはCKとIKの連結によりUEで生成される。
Ｋｓは鍵マテリアルKs_NAFを導出するために用いられる。Ks_NAFはUaインターフェースを安全にするのための用いられる。
　
Ks_NAFはKs_NAF=KDF(Ks,鍵導出パラメーター)として計算される、ここに、KDFは適当な鍵導出関数で、鍵導出パラメーターはユーザーのIMSI、NAF_Id_nとRANDを含んでいる。
注：この注でNAF_Id_nを得る方法の例を挙げる：
NAFのDNS名がserver1.presence.bootstrap.operator.comでn=3ならば、NAF_Id_n＝bootstrap.operator.com
編集者の注：KDFの定義とさらなる鍵導出パラメーターの可能なインクルージョンは、ETSI SAGEにゆだねられる。」）
　
　
＜引用文献２＞
「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:http://www.3gpp.org/ftp/specs/archive/33_series/33.220/
　
　＜引用文献記載事項２−１＞
「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).
（当審訳：「ユーザー・セキュリティ・セッティング：
USSはアプリケーションと加入者固有のパラメータ・セットであり、これは２つのパート、つまり、認証部分（それはアプリケーションのために必要とされたユーザーのアイデンティティ（例えばIMPI、IMPU、MSISDN、仮名）のリストを含んでいる）と、認可部分（それはユーザー・パーミッション・フラグ（例えば許可されたアプリケーションにアクセス、頒布させられてもよい証明書のタイプ）を含んでいる）を定義する。
　
　＜引用文献記載事項２−２＞
「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.」（第１８ページ本文第２７行目〜第２０ページ本文第１２行目）
（当審訳：「4.5.2 ブートストラッピング・プロシージャ
（中略）
１．UEがBSFへHTTPリクエストを送る。
２．
BSFがHSSから基準点Zh上のGBAユーザー・セキュリティ・セッティングの完全なセットと１つの認証ベクトル(AVおよびAV=RAND||AUTN||XRES||CK||IK)を引き出す
（中略）
９．UEとBSFの両方は、４．５．３節で明示されるようなプロシージャ中に
鍵マテリアルKs_NAFを導出するためにKsを用いている
Ks_NAFは、Ks_NAF=KDF(Ks,gba-me, RAND, IMPI, NAF_Id)として計算される。
　
　＜引用文献記載事項２−３＞
「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).
（中略）
9.　Both the UICC and the BSF shall 
use the Ks to derive NAF-specific keys Ks_ext_NAF and Ks_int_NAF
 
Ks_ext_NAF is computed in the UICC as Ks_ext_NAF = KDF(Ks, gba-me, RAND, IMPI, NAF_Id)
Ks_int_NAF is computed in the UICC as Ks_int_NAF = KDF(Ks, gba-u, RAND, IMPI, NAF_Id)
（当審訳：「５．３．２　ブートストラッピング・プロシージャ
（中略）
１．MEがBSFへHTTPリクエストを送る。
２．BSFがHSSからZhの参照点上のGBAユーザー・セキュリティ・セッティングの完全なセットと１つの認証ベクトル(AV,AV=RAND||AUTN||XRES||CK||IK)を引き出す。
その後、BSFは、ユーザー・セキュリティ・セッティング（USSs）に基づいて、GBA_Uを遂行することを決定することができる。
（中略）
９．　UICCとBSFの両方は、適用可能な場合に、５．３．３節で明示されるようなプロシージャ中で
NAF固有キーKs_ext_NAFとKs_int_NAFを導出するためにKsを用いるものとする。
　
　
Ks_ext_NAFは、Ks_ext_NAF = KDF(Ks, gba-me, RAND, IMPI, NAF_Id)としてUICCで計算される。
Ks_int_NAFは、Ks_int_NAF = KDF(Ks, gba-u, RAND, IMPI, NAF_Id)としてUICCで計算される。
Ks_ext_NAF導出のために用いられる鍵導出パラメーターは、Ks_int_NAF導出のために用いられたものとは異ならなければならない。これは、鍵導出関数へ入力パラメーターとしてKs_ext_NAFには静的なストリングのgba-me、そしてKs_int_NAFにはgba-uを加えることにより行われる。」）
　
　＜引用文献記載事項２−４＞
「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.
（当審訳：「UEとNAFの間のコミュニケーションがスタートすることができる前に、UEとNAFはまずGBAによって得られた共有鍵を用いるべきかどうか合意しなければならない。UEがこのNAFによりGBAを用いるべきかどうか認識しない場合、それは５．３．１節内で述べられていたブートストラッピング・プロシージャのイニシエーションを用いる。
　一旦、それらがGBAを用いようとすることをUEとNAFが確立したならば、その後、UEがNAFと対話しようとするごとに、図５．３で表されるように、以下のステップが実行される。
　次に、
UEとNAFは、Ks_ext_NAFまたはKs_int_NAF、あるいは両方のどちらの種類の鍵を使用すべきかを、同意しなければならない。デフォルトはKs_ext_NAFのみの使用である。この使用もまたGBA_U不知のMEとNAFにサポートされる
　
　
　
第２．平成２３年９月５日付けの手続補正についての補正却下の決定
　
［補正却下の決定の結論］
　平成２３年９月５日付けの手続補正を却下する。
　
　
［理由］
１．本件補正の内容
　平成２３年９月５日付けの手続補正（以下「本件補正」と記す。）は、特許請求の範囲について、上記第１．２（１）記載の特許請求の範囲から、上記第１．２（２）記載の特許請求の範囲に補正しようとするものである。
　
２．本件補正が新規事項の追加であるか否かについての検討
　本件補正について検討するに、本件補正後の請求項１記載の「ユーザ・セキュリティ設定を用いて汎用認証アーキテクチャのネットワーク・アプリケーション機能鍵を
、第１共有秘密鍵（Ks_int_NAF）、第２共有秘密鍵（Ks_ext_NAF）及び第３共有秘密鍵（Ks_NAF）から選択することにより決定する決定手段
、第１共有秘密鍵（Ks_int_NAF）、第２共有秘密鍵（Ks_ext_NAF）及び第３共有秘密鍵（Ks_NAF）から選択することにより決定する決定手段
、第１共有秘密鍵（Ks_int_NAF）、第２共有秘密鍵（Ks_ext_NAF）及び第３共有秘密鍵（Ks_NAF）から選択することにより決定する決定ユニット
、第１共有秘密鍵（Ks_int_NAF）、第２共有秘密鍵（Ks_ext_NAF）及び第３共有秘密鍵（Ks_NAF）から選択することにより決定する決定ステップ
　なお、請求人は審判請求書において当該補正の根拠として「これは、本願明細書段落［００１７］、［００２０］等の記載に基づいています。」と説明している。
　しかしながら、当初明細書等の段落【００１７】、【００２０】の記載を詳細に検討しても、「ネットワーク・アプリケーション機能鍵」を、「Ks_int_NAF」と「Ks_ext_NAF」と「Ks_NAF」の３種の鍵から選択することを示唆する記載は見あたらない。
　また、当初明細書の【請求項３】には
「前記第１フラグ・フィールドにおいては、集積回路を基礎として強化（GBA_U）された第１生成鍵（Ks_int_NAF）が使用され、
　前記第２フラグ・フィールドにおいては、第２生成鍵（Ks_ext_NAF）または第３生成鍵（Ks_NAF）が使用される」との記載が、
【請求項５】には
「前記派生鍵のタイプは、Ks_int_NAF、Ks_ext_NAFまたはKs_NAFを含み」との記載が、
【請求項１２】には
「前記第１フラグ・フィールドにおいては、集積回路を基礎として強化（GBA_U）された第１生成鍵（Ks_int_NAF）が使用され、
　前記第２フラグ・フィールドにおいては、第２生成鍵（Ks_ext_NAF）または第３生成鍵（Ks_NAF）が使用される」との記載が、
【請求項１４】には
「前記派生鍵のタイプは、Ks_int_NAF、Ks_ext_NAFまたはKs_NAFを含み、」との記載が、
【請求項２１】には
「前記第１フラグ・フィールドにおいては、集積回路を基礎として強化（GBA_U）された第１生成鍵（Ks_int_NAF）が使用され、
　前記第２フラグ・フィールドにおいては、第２生成鍵（Ks_ext_NAF）または第３生成鍵（Ks_NAF）が使用される」との記載が、
【０００３】には
「携帯電話などの移動端末であるか、ユニバーサル・モバイル・テレコミュニケーション・システム（UMTS）集積回路カード（UICC）であるか、あるいはその移動端末に挿入された加入者識別モジュールであるかによって、3GPP汎用認証アーキテクチャ（GAA）は以下の鍵、即ち、Ks_int_NAF、Ks_ext_NAF及びKs_NAFを持つことができる。」との記載が、
段落【００２７】には
「既存の仕様書3GPP TS 29.109のUSSに搬送された１つまたは２つの認証フラグ・フィールドをUSSは備えている。第１のフラグ・フィールドにおいては、もしこのフィールドが存在する場合には、UICCを基礎とした共有秘密鍵（Ks_int_NAF）の使用は必須であることを示す。第２のフラグ・フィールドは付加的なフィールドであり、もし第２のフラグ・フィールドが存在する場合は、MEを基礎とした共有秘密鍵（Ks_ext_NAFまたはKs_NAF）の使用であることを示す。」との記載が、
段落【００３０】には
「工程３３０において、本方法では、付属書類Cとして添付された、既存の仕様書3GPP TS 29.109の認証ヘッダに送られる、１つまたは２つのフラグ・フィールドをUSSが有しているかどうかを決定する。第１のフラグ・フィールドにおいては、もしこのフィールドが存在する場合には、UICCを基礎とした共有秘密鍵（Ks_int_NAF）の使用は必須であることを示す。第２のフラグ・フィールドは付加的なフィールドであり、もし第２のフラグ・フィールドが存在する場合は、MEを基礎とした共有秘密鍵（Ks_ext_NAFまたはKs_NAF）の使用であることを示す。」との記載があるが、
「Ks_int_NAF」と「Ks_ext_NAF」と「Ks_NAF」の３種の鍵から選択することを示唆する記載は見あたらない。
　また、「ネットワーク・アプリケーション機能鍵」を、「Ks_int_NAF」と「Ks_ext_NAF」と「Ks_NAF」の３種の鍵から選択することが当該技術分野における技術常識であったとも認めることはできない。
　すなわち、本件補正は、当業者によって、当初明細書等のすべての記載を総合することにより導かれる技術的事項との関係において、新たな技術的事項を導入するものであり、当初明細書等に記載した事項の範囲内においてするものではない。
　したがって、本件補正は、特許法第１７条の２第３項の規定に違反するものである。 
　
　
３．本件補正の目的についての検討
（１）本件補正のうち、本件補正後の請求項１に係る補正は、
　本件補正前の請求項１に記載の発明を特定するための事項（以下「発明特定事項」と記す。）であるところの「ユーザ・セキュリティ設定を用いて汎用認証アーキテクチャのネットワーク・アプリケーション機能鍵を前記決定ユニットにより決定するステップ」を、「ユーザ・セキュリティ設定を用いて汎用認証アーキテクチャのネットワーク・アプリケーション機能鍵を前記決定ユニットにより
、第１共有秘密鍵（Ks_int_NAF）、第２共有秘密鍵（Ks_ext_NAF）及び第３共有秘密鍵（Ks_NAF）から選択することにより決定するステップであって、前記第１共有秘密鍵（Ks_int_NAF）、前記第２共有秘密鍵（Ks_ext_NAF）及び前記第３共有秘密鍵（Ks_NAF）はマスター共有秘密鍵（Ks）から導出されたものである、決定ステップ
　また、請求項１０、１８、１９に対しても同様の限定がなされており、これらの限定によっても、本件補正前後の請求項１０、１８、１９に係る発明の産業上の利用分野及び解決しようとする課題が格別変更されると言えるものでもない。
　したがって、これらの補正事項に関しては、その目的は特許法第１７条の２第４項第２号に掲げられる「特許請求の範囲の減縮（第３６条第５項の規定により請求項に記載した発明を特定するために必要な事項を限定するものであつて、その補正前の当該請求項に記載された発明とその補正後の当該請求項に記載される発明の産業上の利用分野及び解決しようとする課題が同一であるものに限る。）」（以下「限定的減縮」と記す。）に該当し、特許法第１７条の２第４項第２号に掲げられる事項を目的とするものであるとも言える。
　
（２）しかしながら、本件補正は、請求項１１における「ユーザ機器のセキュア環境のタイプを」を「ユーザ機器のスマートカードのタイプまたはセキュア環境に関するデータ」とする補正事項を含むものであり、該補正後の「スマートカードのタイプまたはセキュア環境に関するデータ」が、概念的に本件補正前の「ユーザ機器のセキュア環境のタイプ」の下位のものになるわけでも、複数の選択肢の一部を削除するものでもないことは明らかであるから、この補正事項は特許請求の範囲の減縮をするものでないことは明らかである。
　したがって、当該補正事項は特許法第１７条の２第４項第２号に掲げられる事項を目的とするものとは言えない。
　また、「スマートカードのタイプまたはセキュア環境に関するデータ」は「ユーザ機器のセキュア環境のタイプ」とは全く異なるものを意味するものであるから、当該補正事項が明瞭でない記載の釈明であるとも言えない。また、仮に明瞭でない記載の釈明であるとしても、当該補正事項に係る拒絶理由が通知されたことは無く、拒絶理由通知に係る拒絶の理由に示す事項についてする補正とも言えない。
　したがって、当該補正事項は特許法第１７条の２第４項第４号に掲げられる「明りようでない記載の釈明（拒絶理由通知に係る拒絶の理由に示す事項についてするものに限る。）」を目的とするものとも言えない。
　また、当該補正事項は、請求項の削除、誤記の訂正にも該当しないことも明らかであり、特許法第１７条の２第４項第１号、第３号に掲げられる事項を目的とするものとも言えない。
　よって、本件補正は、特許法第１７条の２第４項各号に掲げられる事項を目的とするものに限られるものでは無く、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第４項の規定に違反する。
　
　
４．独立特許要件についての検討
　上記３．（１）で述べたとおり、本件補正は限定的減縮を目的とするものとも言えるものであるから、本件補正後の請求項１、１０、１８、１９に記載されている事項により特定される発明が特許出願の際独立して特許を受けることができるものであるか否かについて、以下に検討する。
　
４−１．記載要件（特許法第３６条）
　上記２．で検討した、本件補正後の請求項１記載の「ユーザ・セキュリティ設定を用いて汎用認証アーキテクチャのネットワーク・アプリケーション機能鍵を
、第１共有秘密鍵（Ks_int_NAF）、第２共有秘密鍵（Ks_ext_NAF）及び第３共有秘密鍵（Ks_NAF）から選択することにより決定する決定手段
、第１共有秘密鍵（Ks_int_NAF）、第２共有秘密鍵（Ks_ext_NAF）及び第３共有秘密鍵（Ks_NAF）から選択することにより決定する決定手段
、第１共有秘密鍵（Ks_int_NAF）、第２共有秘密鍵（Ks_ext_NAF）及び第３共有秘密鍵（Ks_NAF）から選択することにより決定する決定ユニット
、第１共有秘密鍵（Ks_int_NAF）、第２共有秘密鍵（Ks_ext_NAF）及び第３共有秘密鍵（Ks_NAF）から選択することにより決定する決定ステップ
　したがって、本件補正後の請求項１、１０、１８、１９の記載は特許法第３６条第６項第１号に規定する要件を満たしていないものであるから、本件補正後の請求項１、１０、１８、１９に係る発明は特許出願の際独立して特許を受けることができるものではない。
　
　
４−２．進歩性（特許法第２９条第２項）
　
４−２−１．本件補正発明
　本件補正後の請求項１に係る発明（以下「本件補正発明」と記す。）は、上記第１．２．（２）において【請求項１】として記載したとおりのものである。
　
４−２−２．先行技術
（１）上記第１．３．で示したとおり、本願の出願前でありかつ上記優先日よりも前の日に頒布または電気通信回線を通じて公衆に利用可能となり、原審の拒絶の査定の理由である上記平成２２年１１月２６日付けの拒絶理由通知の（理由１）において引用された上記引用文献には上記引用文献記載事項が記載されている。
　
４−２−３．引用発明の認定
（１）引用文献１には、上記引用文献記載事項１−１のとおり「UEがBSFからNAFへのブートストラッピング情報のプッシングをトリガする、ブートストラッピング・プロシージャ」が記載されているところ、これは上記引用文献記載事項１−２の記載等から「UE、NAF、BSF、HSSが接続されたネットワーク」を前提としているものである。
　そして、該「プロシージャ」において該「BSF」が行う手順は、
「UE、NAF、BSF、HSSが接続されたネットワークにおいて、UEがBSFからNAFへのブートストラッピング情報のプッシングをトリガするブートストラッピング・プロシージャにおける該BSFが行う方法」と言えるものであり、
引用文献１には該方法が記載されているとも言える。
　
（２）引用文献記載事項１−１の「１．（オプション）UEがNAFと連絡をとる。NAFは、それが認証を要求し、かつ、GAAが用いられるべきであるということをUEへ通知する。」とのステップの記載から、
「該プロシージャは前記UEがNAFと連絡をとり、NAFが、認証を要求し、かつ、GAAが用いられるべきであるということをUEへ通知することで開始」すると言える。
　
（３）引用文献記載事項１−１の「３．UEはIMPIおよびオプションのNAF_IDを伴ったイニシャルHTTPリクエストをBSFへ送る。」とのステップの記載から、上記方法は
「前記UEからイニシャルHTTPリクエストを受け取るステップ」
を有していると言える。
　
（４）上記引用文献記載事項１−２の「8. BSF pushes the TID, NAF specific key (Ks_naf), and profile (prof_naf) to the NAF indicated by UE.」（当審訳：「８．BSFがUEによって示されたNAFへのTID、NAF固有キー（Ks_naf）とプロフィール(prof_naf)をプッシュする。」）等の記載から、「NAF固有キーKs_NAF」がBSF内で生成されていることは明らかであるところ、引用文献記載事項１−３には該「Ks_NAF」が「Ks_NAF=KDF(Ks,鍵導出パラメーター)として計算」されることも示されている。
　したがって、上記方法は
「NAF固有キーKs_NAFをKs_NAF=KDF(Ks,鍵導出パラメーター)として計算するステップ」
を有していると言える。
　
（５）上記引用文献記載事項１−１の「９．（オプション）NAF固有のブートストラッピング情報がBSFによってNAFへプッシュされる。」との記載及び上記引用文献記載事項１−２の「8. BSF pushes the TID, NAF specific key (Ks_naf), and profile (prof_naf) to the NAF indicated by UE.」との記載などから、上記方法は
「該NAF固有キーが含まれているNAF固有のブートストラッピング情報を前記NAFへプッシュするステップ」
を有していると言える。
　
（６）よって、引用文献１には、下記引用発明が記載されていると認められる。
　
＜引用発明＞
「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へプッシュするステップ
を有する方法。」
　
４−２−４．対比
　以下、本件補正発明と引用発明とを比較する。
　
（１）引用発明は「UE、NAF、BSF、HSSが接続されたネットワークにおいて、該UEが該BSFから該NAFへのブートストラッピング情報のプッシングをトリガするブートストラッピング・プロシージャにおける該BSFが行う方法」であるところ、該「NAF」や「BSF」がサーバすなわち「装置」において実現されているものであることは明らかであり、引用発明も本件補正発明と同様に「装置によって実現される、ネットワーク・アプリケーション・サーバのための汎用メカニズムを提供する方法」と言えるものである。
　
（２）引用発明における「前記UEからイニシャルHTTPリクエストを受け取るステップ」は、本件補正発明における「受信ステップ」に対応付けられるものであるところ、前者の「UE」は「ユーザ機器」にほかならないので「イニシャルHTTPリクエスト」は「ユーザ機器からの要求」と言えるものである。
　一方、引用発明における「プロシージャ」は「前記UEが前記NAFと連絡をとり、前記NAFが、認証を要求し、かつ、GAAが用いられるべきであるということを前記UEへ通知することで開始」するものであることなどから見て、引用発明において最終的にNAFへプッシュされる「NAF固有のブートストラッピング情報」は「認証情報」とも言えるものであるから、引用発明における「前記UEからイニシャルHTTPリクエストを受け取るステップ」は、「認証情報」を「NAF」へ「プッシュ」するためになされるものととらえることができ、これは本件補正発明の「受信ステップ」における「ネットワーク・アプリケーション機能に認証情報を提供するように」との事項に相当するものである。
　したがって、引用発明と本件補正発明とは「ネットワーク・アプリケーション機能に認証情報を提供するようにユーザ機器からの要求を」「受信する受信ステップ」を含む点で共通するといえる。
　
（３）引用発明における「NAF固有キーKs_NAFをKs_NAF=KDF(Ks,鍵導出パラメーター)として計算するステップ」は本件補正発明における「決定ステップ」に対応付けられるものであるところ、引用発明において計算される「NAF固有キーKs_NAF」は、NAFがUEへ通知した「GAAが用いられるべきである」という事項に基づく「NAF固有」の鍵であるから、「汎用認証アーキテクチャのネットワーク・アプリケーション機能鍵」とも言えるものである。
　また、「Ks_NAF=KDF(Ks,鍵導出パラメーター)」であるから、「NAF固有キーKs_NAF」は「マスター共有秘密鍵（Ks）から導出されたもの」とも言える。
　したがって、引用発明と本件補正発明とは「汎用認証アーキテクチャのネットワーク・アプリケーション機能鍵を」「決定するステップであって、」該鍵「はマスター共有秘密鍵（Ks）から導出されたものである、決定ステップ」を含む点で共通すると言える。
　
（４）引用発明における「該NAF固有キーが含まれているNAF固有のブートストラッピング情報を前記NAFへプッシュするステップ」は、本件補正発明における「提供ステップ」に対応付けられるものであるところ、前者の「NAF固有のブートストラッピング情報」は上記（２）でも言及したように「認証情報」と言えるものであるから、引用発明と本件補正発明は、「前記ネットワーク・アプリケーション機能に認証情報を」「提供する提供ステップ」を含む点で共通するといえる。
　
（５）よって、本件補正発明は、下記一致点で引用発明と一致し、下記相違点で引用発明と相違する。
　
＜一致点＞
「装置によって実現される、ネットワーク・アプリケーション・サーバのための汎用メカニズムを提供する方法であって、
　ネットワーク・アプリケーション機能に認証情報を提供するようにユーザ機器からの要求を受信する受信ステップと、
　汎用認証アーキテクチャのネットワーク・アプリケーション機能鍵を決定するステップであって、該鍵はマスター共有秘密鍵（Ks）から導出されたものである、決定ステップと、
　前記ネットワーク・アプリケーション機能に認証情報を提供する提供ステップと、を含む方法。」
　
＜相違点１＞
　本件補正発明における装置は「受信ユニットと、決定ユニットと、提供ユニットと、を含む」ものであり、本件補正発明における「受信ステップ」「決定ステップ」「提供ステップ」における「受信」「決定」「提供」はそれぞれ、「前記受信ユニット」「前記決定ユニット」「前記提供ユニット」によりなされる。
（これに対し、引用文献１には「受信ユニット」「決定ユニット」「提供ユニット」の明示はない。）
　
＜相違点２＞
　本件補正発明における「決定ステップ」ではネットワーク・アプリケーション機能鍵を「ユーザ・セキュリティ設定を用いて」、かつ、マスター共有秘密鍵（Ks）から導出された「第１共有秘密鍵（Ks_int_NAF）、第２共有秘密鍵（Ks_ext_NAF）及び第３共有秘密鍵（Ks_NAF）から選択することにより」決定している。
（これに対し、引用文献１（特に引用文献記載事項１−３）には、「鍵導出パラメーター」が「ユーザーのＩＭＳＩ」を含む旨の記載はあるものの「ユーザ・セキュリティ設定」への言及は無い。また、鍵を複数の秘密鍵から選択する旨の記載も無い。）
　
４−２−５．判断
　以下、上記相違点について検討する。
　
（１）相違点１について
　一連の情報処理を実現する際に、そのための所定の纏まりをもった機能実現手段の組合わせによって実現することは説示するまでもない当業者の常套手段であり、引用発明における「BSF」も「受信ユニットと、決定ユニットと、提供ユニットと、を含む」ものとし、上記「受信」「決定」「提供」が、それぞれ「前記受信ユニット」「前記決定ユニット」「前記提供ユニット」によりなされるものとすること、すなわち上記相違点１に係る構成は、当業者が通常採用する構成にすぎないもので、何ら格別なものではない。
　
（２）相違点２について
　鍵の生成にユーザーのアイデンティティを用いることは通常行われていることであるところ、引用文献記載事項２−１にはこのようなユーザーのアイデンティティをＵＳＳ（ユーザー・セキュリティ・セッティング）の一部とすることが記載されており、また、引用文献記載事項２−２にはこのようなＵＳＳに基づいて「Ks_NAF」を導出するアーキテクチャが開示されている。また、引用文献記載事項２−３、２−４には、このようなＵＳＳに基づいて「Ks_ext_NAF」又は「Ks_int_NAF」との２種類の鍵のどちらの種類の鍵を使用すべきかを決定して導出するアーキテクチャが開示されている。
　複数のアーキテクチャを選択的に利用できるように所謂兼用化を図ることは、当業者の創作活動において従来から常套の手法であり、引用文献２に接した当業者であれば、引用発明における「NAF固有キー」の決定を、「ユーザ・セキュリティ設定を用いて」、かつ、「マスター共有秘密鍵（Ks）」から導出されると言う共通の特徴をもつ「Ks_ext_NAF」、「Ks_int_NAF」及び「Ks_NAF」と言う複数の共有秘密鍵の中からの選択によって決定する構成とすることは、容易に想起し得たことであり、また、その実現に際して格別な困難性を伴うものでもない。
　してみると、引用発明においてもネットワーク・アプリケーション機能鍵を「ユーザ・セキュリティ設定を用いて」し、かつ、マスター共有秘密鍵（Ks）から導出された「第１共有秘密鍵（Ks_int_NAF）、第２共有秘密鍵（Ks_ext_NAF）及び第３共有秘密鍵（Ks_NAF）から選択することにより」決定するように構成すること、すなわち、上記相違点２に係る構成を採用することも、当業者であれば容易に想到し得たことである。
　
（３）したがって、本件補正発明の構成は引用文献１、２記載の発明に基づいて、当業者が容易に想到し得たものである。
　そして、当該構成の採用によって奏される作用効果も、当業者であれば容易に予測し得る程度のものであって、格別顕著なものではない。
　よって、本件補正発明は、引用文献１、２記載の発明に基づいて、当業者が容易に発明をすることができたものである。
　また、本件補正後の請求項１０、１８、１９に係る発明も同様に引用文献１、２記載の発明に基づいて、当業者が容易に発明をすることができたものである。
　
４−２−６．小結
　以上のとおり、本件補正後の請求項１、１０、１８、１９に係る発明は、その出願前に日本国内又は外国において頒布された刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基づいて、その発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、本件補正後の請求項１、１０、１８、１９に係る発明は特許出願の際独立して特許を受けることができるものではない。
　
　
４−３．中結
　上記４−１．及び４−２．で述べたとおり、本件補正後の請求項１、１０、１８、１９に係る発明は特許出願の際独立して特許を受けることができるものではないので、本件補正は平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第５項において準用する同法第１２６条第５項の規定に違反する
　
　
５．むすび
　上記２．で述べたとおり、本件補正は特許法第１７条の２第３項の規定に違反するので、同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　
　上記３．で述べたとおり、本件補正は平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第４項の規定に違反するので、この理由によっても、同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　
　上記４．で述べたとおり、本件補正は平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第５項において準用する同法第１２６条第５項の規定に違反するので、この理由によっても、同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　
　よって、上記補正却下の決定の結論のとおり決定する。
　
　
　
第３．本件審判請求の成否について
　
１．手続きの経緯、本願発明の認定
　本願の手続きの経緯は上記第１．１．のとおりのものであり、さらに、平成２３年９月５日付けの手続補正は上記第２．のとおり却下された。
　したがって、本願の特許請求の範囲は、上記第１．２．（１）に記載したとおりのものであり、その請求項１に係る発明（以下「本願発明」と記す。）はそこに【請求項１】として記載したとおりのものである。
　
２．先行技術・引用発明の認定
　上記第１．３．に示したとおり、本願の出願前でありかつ上記優先日よりも前の日に頒布または電気通信回線を通じて公衆に利用可能となり、原審の拒絶の査定の理由である上記平成２２年１１月２６日付けの拒絶理由通知の（理由１）において引用された上記引用文献には上記引用文献記載事項が記載されており、上記引用文献１には上記第２．４−２−３．で認定したとおりの引用発明が記載されていると認められる。
　
３．対比・判断
　上記第２．４−２．で検討した本件補正発明は、本願発明に対し上記第２．３．（１）で述べた限定的減縮をしたものと実質的に同じ発明であり、本願発明は、上記本件補正発明から当該限定的減縮により限定される要件を無くしたものに相当する。
　そして、本願発明の構成要件を全て含み、さらに他の要件を付加したものに相当する上記本件補正発明は、上記第２．４−２．で論じたとおり、上記引用文献１、２記載の発明に基づいて、当業者が容易に発明をすることができたものである。
　したがって、本願発明も同様の理由により、上記引用文献１、２記載の発明に基づいて、当業者が容易に発明をすることができたものである。
　また、本願請求項１０、１８、１９に係る発明も同様に引用文献１、２記載の発明に基づいて、当業者が容易に発明をすることができたものである。
　
４．むすび
　以上のとおり、本願請求項１、１０、１８、１９に係る発明は、その出願前に日本国内又は外国において頒布された刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができないものであり、他の請求項についての検討をするまでもなく、本願を拒絶すべきものとした原審の拒絶査定は妥当なものである。
　
　よって、上記結論のとおり審決する。