• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 特36条6項1、2号及び3号 請求の範囲の記載不備 特許、登録しない(前置又は当審拒絶理由) H04W
管理番号 1347041
審判番号 不服2016-14748  
総通号数 230 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2019-02-22 
種別 拒絶査定不服の審決 
審判請求日 2016-10-03 
確定日 2018-12-07 
事件の表示 特願2014-151947「無線技術間の網間接続方法」拒絶査定不服審判事件〔平成26年11月27日出願公開、特開2014-222940〕について、次のとおり審決する。 
結論 本件審判の請求は、成り立たない。 
理由 第1 手続の経緯
本願は、2010年(平成22年)12月23日(パリ条約による優先権主張外国庁受理 2009年12月31日 米国)を国際出願日とする出願である特願2012-547167号の一部を、平成26年7月25日に新たな特許出願としたものであって、平成27年7月21日付けで、特許法第50条の2の通知を伴う拒絶理由通知がされ、平成28年1月22日に意見書及び手続補正書が提出され、同年5月30日付けで拒絶査定されたところ、同年10月3日に拒絶査定不服審判が請求されたものである。その後当審において、平成29年8月7日付けで拒絶理由(以下、「当審拒絶理由」という。)が通知され、平成30年2月8日に意見書及び手続補正書が提出されたものである。

第2 拒絶の理由
当審拒絶理由の概要は、次のとおりのものである。

理由3(サポート要件)
この出願は、特許請求の範囲の記載が下記の点で、特許法第36条第6項第1号に規定する要件を満たしていない。

「認証拡張部」に関する記載について
(1)請求項4に「前記認証サーバにおいて、前記第2の無線アクセス技術用に確立された規格にしたがって、前記要求されたアクセス登録のために認証キーおよび第2の認証拡張部を生成するステップ」と記載されているが、発明の詳細な説明には、モビリティ・キーが、移動登録メッセージ中の認証拡張部(請求項4における「第1の認証拡張部」と解される)の計算に使用されること(段落【0018】及び【0024】)は記載されているものの、第2の認証拡張部を生成することは記載されていない。

(2)請求項4に「前記第1および第2の認証拡張部を比較することにより、前記認証サーバにおいて、受信した前記登録を要求するメッセージを検証するステップ」と記載されているが、発明の詳細な説明には、2つの認証拡張部を比較することも、比較によってメッセージを検証することも記載されていない。

上記(1)、(2)のとおりであるから、請求項4に係る発明は、発明の詳細な説明に記載したものではない。

第3 請求人の対応
当審拒絶理由に対して、請求人は、平成30年2月8日に、意見書及び特許請求の範囲を補正する手続補正書を提出した。

1 補正後の特許請求の範囲
平成30年2月8日提出の手続補正書により補正された特許請求の範囲(抜粋)は以下のとおりである。([当審注]:補正により、補正前の請求項4に補正前の請求項12の発明特定事項が付加され、補正前の請求項1-3及び11-16が削除されたため、当審拒絶理由に記載中の請求項4は、補正後の請求項1に対応する。)

「 【請求項1】
第1の無線アクセス技術を適用する第1のカバレージ・エリアから第2の無線アクセス技術を適用する第2のカバレージ・エリアに移動するモバイル・ノードのハンドオーバを提供するための無線通信システムの方法であって、前記モバイル・ノードが、前記第1の無線アクセス技術の規格に準拠して、前記第1のカバレージ・エリアに関連するネットワークと認証済み登録を最初に確立しており、
認証サーバにおいて、前記モバイル・ノードから前記第2のカバレージ・エリアへのアクセスのための登録を要求するメッセージを受信するステップであって、前記メッセージが、前記第2のカバレージ・エリアに適用される前記第2の無線アクセス技術を識別し、前記メッセージは第1の認証拡張部を含み、前記認証サーバが前記第2のアクセス技術とは異なる前記第1のアクセス技術を最初に使用するステップと、
前記認証サーバにおいて、前記第2の無線アクセス技術用に確立された規格にしたがって、前記要求されたアクセス登録のために認証キーおよび第2の認証拡張部を生成するステップと、
前記第1および第2の認証拡張部を用いて前記認証サーバにおいて、受信した前記登録を要求するメッセージを検証するステップと
を含み、
前記モバイル・ノードが、前記第2の無線アクセス技術を識別する前記認証サーバから何ら情報を受信することなく前記第1の認証拡張部を生成する方法。」(以下、「本願発明」という。[当審注]:下線部は、補正箇所である。)

2 意見書における請求人の主張
平成30年2月8日提出の意見書において、請求人は理由3及び4に関して、以下のように主張している。

「(3)意見の内容
(I) 理由3および4に関して
(A) (中略)
認証拡張部を生成することに関し、審判官殿が引用なさった段落[0018]及び[0024]には、「認証拡張部の計算」と記載されておりますが、ここで、「計算」とは、「加減乗除など、数式に従って処理し数値を引き出すこと」(デジタル大辞泉、小学館)を意味するので、この場合、数式に従って処理し引き出されたものが「認証拡張部」です。したがって、認証拡張部を生成することは本願明細書中に記載されているものと思料します。
なお、審判官殿が引用なさったこれらの段落には、「認証拡張部の計算」と記載されておりますが、これらの「認証拡張部」は、第1の認証拡張部に限定するものではありません。
また、補正前の請求項4の「比較することにより」を「用いて」と補正しました。これらの補正により、補正前の請求項4の記載は明確になったものと思料します。」

第4 当審の判断
1 「理由3(1)」について(第2の認証拡張部を生成することについて)
(1)本願発明について
本願発明は、「認証サーバにおいて、前記第2の無線アクセス技術用に確立された規格にしたがって、前記要求されたアクセス登録のために認証キーおよび第2の認証拡張部を生成するステップ」という発明特定事項を含む。すなわち、認証サーバが「認証キー」及び「第2の認証拡張部」の双方を生成するものである。

(2)発明の詳細な説明に発明として記載されたものについて
ア 明示的な記載の有無について
発明の詳細な説明には、「認証サーバにおいて、第2の無線アクセス技術用に確立された規格にしたがって、要求されたアクセス登録のために第2の認証拡張部を生成する」ことについて、明示的な記載はない。

イ 発明の詳細な説明に記載されているといえるものについて
(ア)発明の詳細な説明の記載について
発明の詳細な説明には、以下の記載がある。([当審注]:以下、下線は、強調のため、当審が付与した。)

a 「【0005】
モバイル端末は、その発信源を任意の確度で直ちに識別することができないRF信号によって、サービング・ネットワークにリンクされるので、無線通信の重要な態様は、モバイル端末の識別およびモバイル端末がネットワークの認定ユーザであることを確定するため、モバイル端末とサービング・ネットワーク間で、セキュリティ・アソシエーションを確立し維持することである。このセキュリティ・アソシエーションは、ネットワークに入るモバイル端末の初期認証の期間に、モバイル・ユーザ加入者のホーム・ネットワークが支援して作成され、通常、そのホーム・ネットワーク内の認証サーバによって、またはそのホーム・ネットワーク内の認証サーバの制御の下で実行される。典型的には、その認証サーバは、認証、認可、および課金(Authentication、 Authorization and Accounting、AAA)サーバとして実装される。そのような認証は、一般に、参加者に既知の、または関連するネットワークとモバイル端末の
実体の間でキーの暗号学的ハッシュを介して交換された、一連のセキュリティ・キーを介して実装される。」

b 「【0017】
本発明者は、多様な規格の下で動作するアクセス技術間の網間接続のための、いずれのアクセス技術もいかなる変更も必要とされない方法論を開発した。この方法論は、以下で図1に関して記載されることになる。図1は、異なるRATの下で動作する2つのアクセス・ネットワーク(AN1およびAN2)によりサービスを受け、共通のAAAサーバによりサービスを受ける移動局(MS)のためのアーキテクチャを示す。
【0018】
下でより詳細に説明されるように、本発明の方法論の基本的な要旨は、アクセス技術網間接続モビリティ・キー管理問題が、MSにより選択されるアクセス技術に基づいてAAAモビリティ・キー管理を実施することにより対処されることである。したがって、コア・ネットワーク内に存在するAAAサーバが、コア・ネットワークと異なる技術を有するアクセス・ネットワークからのものであるMSを検出するとき、AAAサーバは、MSのアクセス技術のための規格に基づいて、モビリティ・ルート・キーおよびモバイルIPキーを生成する。したがって、同じモビリティ・キーが、移動登録メッセージ中の認証拡張部の計算および(HAが、コア・ネットワーク内に存在するAAAからモビリティ・キーを取り出すとき、)HAによるメッセージの検証に使用される。MSが動作する規格のための公式を使用してAAAサーバがモビリティ・キーを計算するので、HAは、首尾良くMSからの移動登録を検証する。」

c 「【0020】
ここで図1を参照して、2つの異なる技術、RAT-タイプ1(AN1として図示される)およびRAT-タイプ2(AN2として図示される)を使用するコア・ネットワークにアクセス可能であるように、マルチモードMSが図示される。MSは、さらに、1度に1つのアクセス技術だけを用いてネットワークにメッセージを送信することができると特徴付けされており、換言すれば、MSは、デュアル・モードの単一送信機として提供される。(しかし、本発明の方法論は、デュアル・ラジオ・モバイル(dual-radio mobile)、換言すれば、2つの送信機/受信器を備えるモバイルにも適用可能であることを理解されたい。)MSがRAT-タイプ1により対象とされる1つの区域からRAT-タイプ2により対象とされる別の区域に移動するとき、MSは、継続中のセッション連続性を維持するために、ハンドオーバ手順を実施する必要がある。ハンドオーバ手続は、事前登録、モビリティ・キー導出、および本発明の議論に関係がない他の手続から構成される。
【0021】
MSがAN1(トランザクション1)を介してコア・ネットワークに登録するとき、AN1におけるネットワーク・アクセス・サーバ(図示せず)が、MS自身をRAT-タイプ1アクセス技術として識別し、MSとAAAサーバの両方が、RAT-タイプ1の規格およびプロトコルにしたがってキーを計算することになる。
【0022】
ハンドオーバ手続の部分として、MSは、MS自身からAN1へのエア・リンクおよびAN1からAN2へのトンネルを介して、AN2に事前登録し、AN2からコア・ネットワーク内のAAAサーバにAAA認可/認証メッセージを送信する。MSは、その時点で、まだエア・リンクを介してAN1と動作中であるが、AN2は、MS自身がRAT-タイプ2であることをコア・ネットワークに対し明確化することになる。したがって、コア・ネットワークにおけるAAAサーバは、RAT-タイプ2の規格およびプロトコルにしたがってキーを計算することになる。
【0023】
MSは、MSがAN2を用いてどのRAT-タイプを使用することになるか知っており、したがって、AN2に対するハンドオーバのためのMSの事前登録は、例えば、AAAサーバに対するアクセス要求メッセージ内に含まれるNASポート・タイプ・パラメータを介してなど、RAT-タイプ2の標識を含むことになる。
【0024】
したがって、AAAサーバがAN1からAN2へのMSハンドオーバに関するアクセス要求を検出すると、AAAサーバは、MSが次にRAT-タイプ2で動作することになると知り、RAT-タイプ2規格に基づいてモビリティ・ルート・キーおよびモバイルIPキーを生成することになる。したがって、同じモビリティ・キーが、移動登録メッセージ中の認証拡張部の計算および(HAが、AAAからモビリティ・キーを取り出すとき、)HAによるメッセージの検証に使用される。」

(イ)本願優先日における「認証拡張部」に関する技術常識について
3GPPの技術仕様書に記載された事項は当業者における技術常識といえるところ、本願の優先日より前に公知であった3GPPの規格文書である3GPP TS 33.402、V9.2.0、[online]、2009年12月18日アップロード、インターネット<http://www.3gpp.org/ftp/Specs/archive/33_series/33.402/33402-920.zip>には、以下の記載がある。

a 「9.2.1.2 Bootstrapping of MIPv4 FACoA parameters
9.2.1.2.1 Procedures
(中略)
2) The UE sends a Registration Request (RRQ) message to the FA as specified in TS 23.402 [5]. The UE includes the MN-HA Authentication Extension (AE) and optionally the MN-FA Authentication Extension (AE) as specified in RFC 3344 [17].
3) The FA processes the message according to RFC 3344 [17] and validates the MN-FA Authentication extension if present. The FA then forwards the RRQ message to the PDN GW. The RRQ message shall be protected between the FA and the PDN GW according to TS 33.210 [6].
4) The selected PDN GW obtains Authentication and Authorization information from the AAA/HSS.
5) The PDN GW validates the MN-HA authentication extension. After successful authentication extension validation, the PDN GW sends a Registration Reply (RRP) to the UE through the FA. The RRP message shall be protected between the PDN GW and the FA according to TS 33.210 [6].
(後略)」(32ページ12行目-33ページ22行目)
(当審仮訳:「9.2.1.2 MIPv4 FACoAパラメータのブートストラップ
9.2.1.2.1手順
(中略)
2)UEは、TS 23.402 [5]に規定されているように、登録要求(RRQ)メッセージをFAに送信する。UEは、RFC3344 [17]に規定されているように、MN-HA認証拡張部(AE)及びオプションとしてMN-FA認証拡張部(AE)を含める。
3)FAはRFC3344 [17]に従ってメッセージを処理し、存在する場合にはMN-FA認証拡張部を検証する。その後、FAはRRQメッセージをPDN GWに転送する。RRQメッセージは、TS 33.210 [6]に従ってFAとPDN GWとの間で保護されなければならない。
4)選択されたPDN GWはAAA/HSSから認証及び認可情報を取得する。
5)PDN GWは、MN-HA認証拡張部を検証する。認証拡張部の有効性確認が成功した後、PDNGWはFAを介して登録応答(RRP)をUEに送信する。RRPメッセージは、TS 33.210 [6]に従って、PDN GWとFAとの間で保護されなければならない。
(後略)」)

b 「9.2.1.2.2 MIPv4 Key Derivation
The Mobile IP Root Key (MIP-RK) is generated at the 3GPP AAA Server and the UE. (中略)
The MIP-RK is used to generate mobility keys. The MIPv4 keys are generated at the 3GPP AAA Server and at the UE. (後略)」(33ページ23-35行目)
(当審仮訳:「9.2.1.2.2 MIPv4 キーの導出
モバイルIPルートキー(MIP-RK)は、3GPP AAAサーバおよびUEで生成される。(中略)MIP-RKは、モビリティキーを生成するために使用される。MIPv4キーは、3GPP AAAサーバおよびUEで生成される。(後略)」)

c 「The derivation of mobility key is given below:
MN-HA = HMAC-SHA1(MIP-RK, CMIP4 MN HA | HA-IPv4 | MN-NAI | APN)
The lifetime of all MN-HA keys shall be set to the lifetime of the MIP-RK. During the initial attach or additional PDN connectivity, the UE may not know the HA IP address. In this case, the UE use ALL-ZERO-ONE-ADDR [21] in the RRQ message to request for dynamic HA assignment. Under this case, the UE shall derive the MN-HA key using the ALL-ZERO-ONE-ADDR as the HA-IPv4 address and use this key for deriving MN-HA Authentication Extension and send in the RRQ. Then the HA informs this to the 3GPP AAA server in the AAA protocol message. In response from the 3GPP AAA server, the HA will receive RRQ-MN-HA-KEY that is calculated based on ALL-ZERO-ONE-ADDR address and also MN-HA key that is calculated based on HA IP address. The HA shall use the RRQ-MN-HA-KEY for validation of MN-HA Authentication Extension in the received RRQ. The HA then use MN-HA key for deriving RRP MN-HA Authentication Extension and sends the HA IP address as part of the RRP message. The UE shall recalculate the MN-HA key using the HA IP address received in the RRP and use this key for MN-HA Authentication Extension validation for the RRP. If the MN-HA authentication extension is valid, the new MN-HA key shall be in effect.」(34ページ15行目-27行目)
(当審仮訳:「 モビリティキーの導出は以下の通りである。
MN-HA = HMAC-SHA1(MIP-RK, ”CMIP4 MN HA” | HA-IPv4 | MN-NAI | APN)
すべてのMN-HAキーの存続期間は、MIP-RKの存続期間に設定されなければならない。最初のアタッチまたは追加のPDN接続中に、UEはHA IPアドレスを知ることができない。この場合、UEはRRQメッセージ内のALL-ZERO-ONE-ADDR [21]を使用して動的HA割り当てを要求する。この場合、UEは、ALL-ZERO-ONE-ADDRをHA-IPv4アドレスとして使用してMN-HAキーを導出し、このキーを使用してMN-HA認証拡張部を導出し、RRQ内で送信する。その後、HAは、これをAAAプロトコルメッセージで3GPP AAAサーバに通知する。HAは、3GPP AAAサーバからの応答として、ALL-ZERO-ONE-ADDRアドレスに基づいて計算されたRRQ-MN-HA-KEYと、HA IPアドレスに基づいて計算されたMN-HAキーとを受信する。HAは、受信したRRQ内のMN-HA認証拡張部の検証にRRQ-MN-HA-KEYを使用するものとする。次に、HAは、RRP MN-HA認証拡張部を導出するためにMN-HAキーを使用し、RRPメッセージの一部としてHA IPアドレスを送信する。UEは、RRPで受信されたHA IPアドレスを使用してMN-HAキーを再計算し、このキーをRRPのMN-HA認証拡張検証部に使用する。MN-HA認証拡張部が有効である場合、新しいMN-HAキーが有効でなければならない。」)

(ウ)技術常識を踏まえた発明の詳細な説明の検討
まず、上記摘記事項(イ)b及び上記摘記事項(イ)cによれば、AAAサーバは、モバイルIPルートキー(MIP-RK)やモビリティキー(MIPv4キー、MN-HAキー)を生成するといえる。
また、上記摘記事項(イ)a及び上記摘記事項(イ)cによれば、UEは、モビリティキーであるMN-HAキーを使用して登録要求メッセージのMN-HA認証拡張部を導出し、HAは、AAAサーバから受信したMN-HAキーを使用して、UEから受信した登録要求メッセージ内のMN-HA認証拡張部を検証するので、UEは、モビリティキーを使用して送信するメッセージの認証拡張部を導出(すなわち、計算により生成)し、HAは、同じモビリティキーを使用してUEから受信するメッセージの認証拡張部を検証するといえる。
したがって、「AAAサーバは、モバイルIPルートキーやモビリティキーを生成し、UEは、モビリティキーを使用して送信するメッセージの認証拡張部を生成し、HAは、同じモビリティキーを使用してUEから受信するメッセージの認証拡張部を検証する。」ことは、本願優先日における技術常識であると認められる。

次に、発明の詳細な説明には、認証拡張部の生成に関して段落0018、0024に認証拡張部の計算について記載があるのみであるところ、上記摘記事項(ア)bの段落0018及び上記摘記事項(ア)cの段落0024によると、何が「移動登録メッセージ中の認証拡張部の計算」をするのか不明である。このため、上記技術常識を踏まえると、認証拡張部を生成するのはUE(MSと同義)であるから、発明の詳細な説明には、「AAAサーバは、MSのハンドオーバ先のRATの規格に基づいて、モビリティ・ルート・キーおよびモバイルIPキーを生成し、同じモビリティ・キーが、MSによる移動登録メッセージ中の認証拡張部の計算およびHAによる当該移動登録メッセージの検証に使用される」ことは、記載されているといえる。そして、段落0018、0024をみても、認証サーバとMSとが異なる認証拡張部を生成することは読みとれない。

そして、上記摘記事項(ア)aの段落0005によれば、AAAサーバは認証サーバであるから、発明の詳細な説明に発明として記載されたものは、「認証サーバにおいて、MSのハンドオーバー先のRATの規格に基づいて、モビリティ・ルート・キーおよびモバイルIPキーを生成し、MSにおいて、モビリティ・キーを使用して移動登録メッセージ中の認証拡張部を生成する。」といえる。

(3)判断
本願発明と発明の詳細な説明に発明として記載されたものとを対比すると、

発明の詳細な説明に発明として記載されたものには、「認証サーバにおいて、MSのハンドオーバー先のRATの規格に基づいて、モビリティ・ルート・キーおよびモバイルIPキーを生成」することを含むので、上記(1)の本願発明の発明特定事項に含まれる「認証サーバにおいて、前記第2の無線アクセス技術用に確立された規格にしたがって、要求されたアクセス登録のために認証キー」を生成することは発明の詳細な説明に記載されているといえる。
しかし、発明の詳細な説明に発明として記載されたものは、上記技術常識を参酌すると「MSにおいて、モビリティ・キーを使用して移動登録メッセージ中の認証拡張部を生成」するものであり、認証サーバにおいて移動登録メッセージ中の認証拡張部を生成するものでない。したがって、上記(1)の本願発明の発明特定事項に含まれる「認証サーバにおいて、第2の無線アクセス技術用に確立された規格にしたがって、要求されたアクセス登録のために第2の認証拡張部を生成する」ことは、発明の詳細な説明に記載されているといえない。
よって、上記(1)の本願発明の発明特定事項は、発明の詳細な説明に記載されていない。

更に、上記「第3 2」の請求人の主張について検討する。
請求人は、段落0018及び0024の「認証拡張部の計算」という記載から、認証拡張部を生成することは本願明細書中に記載されており、「認証拡張部」は第1の認証拡張部に限定するものではない旨主張する。
しかし、上記のとおり、「認証サーバにおいて、第2の無線アクセス技術用に確立された規格にしたがって、要求されたアクセス登録のために第2の認証拡張部を生成する」ことが、発明の詳細な説明に記載されているとはいえないので、請求人の上記主張は採用できない。

したがって、上記(1)を発明特定事項として含む本願発明は、発明の詳細な説明に記載したものとはいえない。

2 「理由3(2)」について(第1および第2の認証拡張部を用いて認証サーバにおいて、受信した登録を要求するメッセージを検証することについて)
本願発明は、「第1および第2の認証拡張部を用いて認証サーバにおいて、受信した登録を要求するメッセージを検証するステップ」という発明特定事項を更に含む。当該発明特定事項は、平成30年2月8日の補正により「前記第1および第2の認証拡張部を比較することにより、前記認証サーバにおいて、受信した前記登録を要求するメッセージを検証するステップ」から補正されたものである。([当審注]:下線部は、補正箇所である。)

上記発明特定事項について検討すると、発明の詳細な説明には、当該事項について明示的な記載はない。そして、上記1(2)イ(ウ)のとおり、上記技術常識を考慮すると、発明の詳細な説明に発明として記載されたものは、「MSにおいて、モビリティ・キーを使用して移動登録メッセージ中の認証拡張部を生成する」といえるから、第1の認証拡張部とは別に存在する認証サーバにおいて生成される「第2の認証拡張部」は、発明の詳細な説明に発明として記載されたものには存在しない。そうすると、「第2の認証拡張部」は存在しないから、認証サーバにおいて、受信した登録を要求するメッセージを検証する際、第1および第2の認証拡張部を比較することも、用いることもできないことは明らかである。
よって、「第1および第2の認証拡張部を用いて認証サーバにおいて、受信した登録を要求するメッセージを検証する」という発明特定事項を含む本願発明は、発明の詳細な説明に記載したものとはいえない。

エ 小括
上記1、2のとおり、本願発明は、発明の詳細な説明に記載したものとはいえないので、当審拒絶理由の理由3(1)、(2)は解消しておらず、本願発明は、特許法第36条第6項第1号に規定する要件を満たしていない。

第5 むすび
以上のことから、この出願は、特許請求の範囲の記載が特許法第36条第6項第1号の規定する要件を満たしてないから、他の要件を検討するまでもなく、特許を受けることができない。

よって、結論のとおり審決する。
 
別掲
 
審理終結日 2018-07-06 
結審通知日 2018-07-10 
審決日 2018-07-30 
出願番号 特願2014-151947(P2014-151947)
審決分類 P 1 8・ 537- WZ (H04W)
最終処分 不成立  
前審関与審査官 桑江 晃▲高▼木 裕子青木 健  
特許庁審判長 菅原 道晴
特許庁審判官 松永 稔
海江田 章裕
発明の名称 無線技術間の網間接続方法  
代理人 岡部 讓  
代理人 吉澤 弘司  

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