【事件の表示】
　特願２０１４−１５１９４７「無線技術間の網間接続方法」拒絶査定不服審判事件〔平成２６年１１月２７日出願公開、特開２０１４−２２２９４０〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１　手続の経緯
　本願は、２０１０年（平成２２年）１２月２３日（パリ条約による優先権主張外国庁受理　２００９年１２月３１日　米国）を国際出願日とする出願である特願２０１２−５４７１６７号の一部を、平成２６年７月２５日に新たな特許出願としたものであって、平成２７年７月２１日付けで、特許法第５０条の２の通知を伴う拒絶理由通知がされ、平成２８年１月２２日に意見書及び手続補正書が提出され、同年５月３０日付けで拒絶査定されたところ、同年１０月３日に拒絶査定不服審判が請求されたものである。その後当審において、平成２９年８月７日付けで拒絶理由（以下、「当審拒絶理由」という。）が通知され、平成３０年２月８日に意見書及び手続補正書が提出されたものである。
第２　拒絶の理由
　当審拒絶理由の概要は、次のとおりのものである。
　理由３（サポート要件） 
　この出願は、特許請求の範囲の記載が下記の点で、特許法第３６条第６項第１号に規定する要件を満たしていない。 
　「認証拡張部」に関する記載について
（１）請求項４に「前記認証サーバにおいて、前記第２の無線アクセス技術用に確立された規格にしたがって、前記要求されたアクセス登録のために認証キーおよび第２の認証拡張部を生成するステップ」と記載されているが、発明の詳細な説明には、モビリティ・キーが、移動登録メッセージ中の認証拡張部（請求項４における「第１の認証拡張部」と解される）の計算に使用されること（段落【００１８】及び【００２４】）は記載されているものの、第２の認証拡張部を生成することは記載されていない。 
  
（２）請求項４に「前記第１および第２の認証拡張部を比較することにより、前記認証サーバにおいて、受信した前記登録を要求するメッセージを検証するステップ」と記載されているが、発明の詳細な説明には、２つの認証拡張部を比較することも、比較によってメッセージを検証することも記載されていない。 
　上記（１）、（２）のとおりであるから、請求項４に係る発明は、発明の詳細な説明に記載したものではない。
第３　請求人の対応
　当審拒絶理由に対して、請求人は、平成３０年２月８日に、意見書及び特許請求の範囲を補正する手続補正書を提出した。
１　補正後の特許請求の範囲
　平成３０年２月８日提出の手続補正書により補正された特許請求の範囲（抜粋）は以下のとおりである。（［当審注］：補正により、補正前の請求項４に補正前の請求項１２の発明特定事項が付加され、補正前の請求項１−３及び１１−１６が削除されたため、当審拒絶理由に記載中の請求項４は、補正後の請求項１に対応する。）
「　【請求項１】
　第１の無線アクセス技術を適用する第１のカバレージ・エリアから第２の無線アクセス技術を適用する第２のカバレージ・エリアに移動するモバイル・ノードのハンドオーバを提供するための無線通信システムの方法であって、前記モバイル・ノードが、前記第１の無線アクセス技術の規格に準拠して、前記第１のカバレージ・エリアに関連するネットワークと認証済み登録を最初に確立しており、
　認証サーバにおいて、前記モバイル・ノードから前記第２のカバレージ・エリアへのアクセスのための登録を要求するメッセージを受信するステップであって、前記メッセージが、前記第２のカバレージ・エリアに適用される前記第２の無線アクセス技術を識別し、前記メッセージは第１の認証拡張部を含
み、前記認証サーバが前記第２のアクセス技術とは異なる前記第１のアクセス技術を最初に使用する
　前記認証サーバにおいて、前記第２の無線アクセス技術用に確立された規格にしたがって、前記要求されたアクセス登録のために認証キーおよび第２の認証拡張部を生成するステッ
プと
　前記第１および第２の認証拡張部を
用いて
を含
み、
　
前記モバイル・ノードが、前記第２の無線アクセス技術を識別する前記認証サーバから何ら情報を受信することなく前記第１の認証拡張部を生成する
下線部
２　意見書における請求人の主張
　平成３０年２月８日提出の意見書において、請求人は理由３及び４に関して、以下のように主張している。
「（３）意見の内容
　（Ｉ）　理由３および４に関して
　（Ａ）　（中略）
　認証拡張部を生成することに関し、審判官殿が引用なさった段落［００１８］及び［００２４］には、「認証拡張部の計算」と記載されておりますが、ここで、「計算」とは、「加減乗除など、数式に従って処理し数値を引き出すこと」（デジタル大辞泉、小学館）を意味するので、この場合、数式に従って処理し引き出されたものが「認証拡張部」です。したがって、認証拡張部を生成することは本願明細書中に記載されているものと思料します。
　なお、審判官殿が引用なさったこれらの段落には、「認証拡張部の計算」と記載されておりますが、これらの「認証拡張部」は、第１の認証拡張部に限定するものではありません。
　また、補正前の請求項４の「比較することにより」を「用いて」と補正しました。これらの補正により、補正前の請求項４の記載は明確になったものと思料します。」
第４　当審の判断
１　「理由３（１）」について（第２の認証拡張部を生成することについて）
（１）本願発明について
　本願発明は、「認証サーバにおいて、前記第２の無線アクセス技術用に確立された規格にしたがって、前記要求されたアクセス登録のために認証キーおよび第２の認証拡張部を生成するステップ」という発明特定事項を含む。すなわち、認証サーバが「認証キー」及び「第２の認証拡張部」の双方を生成するものである。
（２）発明の詳細な説明に発明として記載されたものについて
ア　明示的な記載の有無について
　発明の詳細な説明には、「認証サーバにおいて、第２の無線アクセス技術用に確立された規格にしたがって、要求されたアクセス登録のために第２の認証拡張部を生成する」ことについて、明示的な記載はない。
イ　発明の詳細な説明に記載されているといえるものについて
（ア）発明の詳細な説明の記載について
　発明の詳細な説明には、以下の記載がある。（［当審注］：以下、
下線
ａ　「【０００５】
　モバイル端末は、その発信源を任意の確度で直ちに識別することができないＲＦ信号によって、サービング・ネットワークにリンクされるので、無線通信の重要な態様は、モバイル端末の識別およびモバイル端末がネットワークの認定ユーザであることを確定するため、モバイル端末とサービング・ネットワーク間で、セキュリティ・アソシエーションを確立し維持することである。このセキュリティ・アソシエーションは、ネットワークに入るモバイル端末の初期認証の期間に、モバイル・ユーザ加入者のホーム・ネットワークが支援して作成され、通常、そのホーム・ネットワーク内の認証サーバによって、またはそのホーム・ネットワーク内の認証サーバの制御の下で実行される。典型的には、その
認証サーバは、認証、認可、および課金（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ、　Ａｕｔｈｏｒｉｚａｔｉｏｎ　ａｎｄ　Ａｃｃｏｕｎｔｉｎｇ、ＡＡＡ）サーバとして実装される。
実体の間でキーの暗号学的ハッシュを介して交換された、一連のセキュリティ・キーを介して実装される。」
ｂ　「【００１７】
　本発明者は、多様な規格の下で動作するアクセス技術間の網間接続のための、いずれのアクセス技術もいかなる変更も必要とされない方法論を開発した。この方法論は、以下で図１に関して記載されることになる。図１は、異なるＲＡＴの下で動作する２つのアクセス・ネットワーク（ＡＮ１およびＡＮ２）によりサービスを受け、共通のＡＡＡサーバによりサービスを受ける移動局（ＭＳ）のためのアーキテクチャを示す。
【００１８】
　下でより詳細に説明されるように、本発明の方法論の基本的な要旨は、アクセス技術網間接続モビリティ・キー管理問題が、ＭＳにより選択されるアクセス技術に基づいてＡＡＡモビリティ・キー管理を実施することにより対処されることである。したがって、コア・ネットワーク内に存在するＡＡＡサーバが、コア・ネットワークと異なる技術を有するアクセス・ネットワークからのものであるＭＳを検出するとき、
ＡＡＡサーバは、ＭＳのアクセス技術のための規格に基づいて、モビリティ・ルート・キーおよびモバイルＩＰキーを生成する。したがって、同じモビリティ・キーが、移動登録メッセージ中の認証拡張部の計算および
ＨＡによるメッセージの検証に使用される。
ｃ　「【００２０】
　ここで図１を参照して、２つの異なる技術、ＲＡＴ−タイプ１（ＡＮ１として図示される）およびＲＡＴ−タイプ２（ＡＮ２として図示される）を使用するコア・ネットワークにアクセス可能であるように、マルチモードＭＳが図示される。ＭＳは、さらに、１度に１つのアクセス技術だけを用いてネットワークにメッセージを送信することができると特徴付けされており、換言すれば、ＭＳは、デュアル・モードの単一送信機として提供される。（しかし、本発明の方法論は、デュアル・ラジオ・モバイル（ｄｕａｌ−ｒａｄｉｏ　ｍｏｂｉｌｅ）、換言すれば、２つの送信機／受信器を備えるモバイルにも適用可能であることを理解されたい。）ＭＳがＲＡＴ−タイプ１により対象とされる１つの区域からＲＡＴ−タイプ２により対象とされる別の区域に移動するとき、ＭＳは、継続中のセッション連続性を維持するために、ハンドオーバ手順を実施する必要がある。ハンドオーバ手続は、事前登録、モビリティ・キー導出、および本発明の議論に関係がない他の手続から構成される。
【００２１】
　ＭＳがＡＮ１（トランザクション１）を介してコア・ネットワークに登録するとき、ＡＮ１におけるネットワーク・アクセス・サーバ（図示せず）が、ＭＳ自身をＲＡＴ−タイプ１アクセス技術として識別し、ＭＳとＡＡＡサーバの両方が、ＲＡＴ−タイプ１の規格およびプロトコルにしたがってキーを計算することになる。
【００２２】
　ハンドオーバ手続の部分として、ＭＳは、ＭＳ自身からＡＮ１へのエア・リンクおよびＡＮ１からＡＮ２へのトンネルを介して、ＡＮ２に事前登録し、ＡＮ２からコア・ネットワーク内のＡＡＡサーバにＡＡＡ認可／認証メッセージを送信する。ＭＳは、その時点で、まだエア・リンクを介してＡＮ１と動作中であるが、ＡＮ２は、ＭＳ自身がＲＡＴ−タイプ２であることをコア・ネットワークに対し明確化することになる。したがって、コア・ネットワークにおけるＡＡＡサーバは、ＲＡＴ−タイプ２の規格およびプロトコルにしたがってキーを計算することになる。
【００２３】
　ＭＳは、ＭＳがＡＮ２を用いてどのＲＡＴ−タイプを使用することになるか知っており、したがって、ＡＮ２に対するハンドオーバのためのＭＳの事前登録は、例えば、ＡＡＡサーバに対するアクセス要求メッセージ内に含まれるＮＡＳポート・タイプ・パラメータを介してなど、ＲＡＴ−タイプ２の標識を含むことになる。
【００２４】
　
したがって、ＡＡＡサーバがＡＮ１からＡＮ２へのＭＳハンドオーバに関するアクセス要求を検出すると、
ＲＡＴ−タイプ２規格に基づいてモビリティ・ルート・キーおよびモバイルＩＰキーを生成することになる。したがって、同じモビリティ・キーが、移動登録メッセージ中の認証拡張部の計算および
ＨＡによるメッセージの検証に使用される。
（イ）本願優先日における「認証拡張部」に関する技術常識について
　3GPPの技術仕様書に記載された事項は当業者における技術常識といえるところ、本願の優先日より前に公知であった3GPPの規格文書である3GPP TS 33.402、V9.2.0、[online]、２００９年１２月１８日アップロード、インターネット＜http://www.3gpp.org/ftp/Specs/archive/33_series/33.402/33402-920.zip＞には、以下の記載がある。
ａ　「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. 
（後略）」（３２ページ１２行目−３３ページ２２行目）
（当審仮訳：「9.2.1.2　ＭＩＰｖ４　ＦＡＣｏＡパラメータのブートストラップ
9.2.1.2.1手順
（中略）
２）
ＵＥは、ＴＳ　２３．４０２　［５］に規定されているように、登録要求（ＲＲＱ）メッセージをＦＡに送信する。ＵＥは、ＲＦＣ３３４４　［１７］に規定されているように、ＭＮ−ＨＡ認証拡張部（ＡＥ）
を含める。
３）ＦＡはＲＦＣ３３４４　［１７］に従ってメッセージを処理し、存在する場合にはＭＮ−ＦＡ認証拡張部を検証する。その後、ＦＡはＲＲＱメッセージをＰＤＮ　ＧＷに転送する。ＲＲＱメッセージは、ＴＳ　３３．２１０　［６］に従ってＦＡとＰＤＮ　ＧＷとの間で保護されなければならない。
４）選択されたＰＤＮ　ＧＷはＡＡＡ／ＨＳＳから認証及び認可情報を取得する。
５）
ＰＤＮ　ＧＷは、ＭＮ−ＨＡ認証拡張部を検証する。
（後略）」）
ｂ　「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.
（当審仮訳：「9.2.1.2.2 ＭＩＰｖ４　キーの導出
　
モバイルＩＰルートキー（ＭＩＰ−ＲＫ）は、３ＧＰＰ　ＡＡＡサーバおよびＵＥで生成される。
ＭＩＰ−ＲＫは、モビリティキーを生成するために使用される。ＭＩＰｖ４キーは、３ＧＰＰ　ＡＡＡサーバおよびＵＥで生成される。
ｃ　「
The derivation of mobility key is given below:
MN-HA 
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.
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. 
（当審仮訳：「　
モビリティキーの導出は以下の通りである。
　
ＭＮ−ＨＡ
　すべてのＭＮ−ＨＡキーの存続期間は、ＭＩＰ−ＲＫの存続期間に設定されなければならない。最初のアタッチまたは追加のＰＤＮ接続中に、ＵＥはＨＡ　ＩＰアドレスを知ることができない。この場合、ＵＥはＲＲＱメッセージ内のＡＬＬ−ＺＥＲＯ−ＯＮＥ−ＡＤＤＲ　［２１］を使用して動的ＨＡ割り当てを要求する。この場合、
ＵＥは、ＡＬＬ−ＺＥＲＯ−ＯＮＥ−ＡＤＤＲをＨＡ−ＩＰｖ４アドレスとして使用してＭＮ−ＨＡキーを導出し、このキーを使用してＭＮ−ＨＡ認証拡張部を導出し、ＲＲＱ内で送信する。
ＨＡは、３ＧＰＰ　ＡＡＡサーバからの応答として、ＡＬＬ−ＺＥＲＯ−ＯＮＥ−ＡＤＤＲアドレスに基づいて計算されたＲＲＱ−ＭＮ−ＨＡ−ＫＥＹと、ＨＡ　ＩＰアドレスに基づいて計算されたＭＮ−ＨＡキーとを受信する。ＨＡは、受信したＲＲＱ内のＭＮ−ＨＡ認証拡張部の検証にＲＲＱ−ＭＮ−ＨＡ−ＫＥＹを使用するものとする。
（ウ）技術常識を踏まえた発明の詳細な説明の検討
　まず、上記摘記事項（イ）ｂ及び上記摘記事項（イ）ｃによれば、ＡＡＡサーバは、モバイルＩＰルートキー（ＭＩＰ−ＲＫ）やモビリティキー（ＭＩＰｖ４キー、ＭＮ−ＨＡキー）を生成するといえる。
　また、上記摘記事項（イ）ａ及び上記摘記事項（イ）ｃによれば、ＵＥは、モビリティキーであるＭＮ−ＨＡキーを使用して登録要求メッセージのＭＮ−ＨＡ認証拡張部を導出し、ＨＡは、ＡＡＡサーバから受信したＭＮ−ＨＡキーを使用して、ＵＥから受信した登録要求メッセージ内のＭＮ−ＨＡ認証拡張部を検証するので、ＵＥは、モビリティキーを使用して送信するメッセージの認証拡張部を導出（すなわち、計算により生成）し、ＨＡは、同じモビリティキーを使用してＵＥから受信するメッセージの認証拡張部を検証するといえる。
　したがって、「ＡＡＡサーバは、モバイルＩＰルートキーやモビリティキーを生成し、
ＵＥは、モビリティキーを使用して送信するメッセージの認証拡張部を生成し
　次に、発明の詳細な説明には、認証拡張部の生成に関して段落００１８、００２４に認証拡張部の計算について記載があるのみであるところ、上記摘記事項（ア）ｂの段落００１８及び上記摘記事項（ア）ｃの段落００２４によると、何が「移動登録メッセージ中の認証拡張部の計算」をするのか不明である。このため、上記技術常識を踏まえると、認証拡張部を生成するのはＵＥ（ＭＳと同義）であるから、発明の詳細な説明には、「ＡＡＡサーバは、ＭＳのハンドオーバ先のＲＡＴの規格に基づいて、モビリティ・ルート・キーおよびモバイルＩＰキーを生成し、同じモビリティ・キーが、
ＭＳによる
　そして、上記摘記事項（ア）ａの段落０００５によれば、ＡＡＡサーバは認証サーバであるから、発明の詳細な説明に発明として記載されたものは、「認証サーバにおいて、ＭＳのハンドオーバー先のＲＡＴの規格に基づいて、モビリティ・ルート・キーおよびモバイルＩＰキーを生成し、
ＭＳにおいて、
（３）判断
　本願発明と発明の詳細な説明に発明として記載されたものとを対比すると、
　発明の詳細な説明に発明として記載されたものには、「認証サーバにおいて、ＭＳのハンドオーバー先のＲＡＴの規格に基づいて、モビリティ・ルート・キーおよびモバイルＩＰキーを生成」することを含むので、上記（１）の本願発明の発明特定事項に含まれる「認証サーバにおいて、前記第２の無線アクセス技術用に確立された規格にしたがって、要求されたアクセス登録のために認証キー」を生成することは発明の詳細な説明に記載されているといえる。
　しかし、発明の詳細な説明に発明として記載されたものは、上記技術常識を参酌すると「ＭＳにおいて、モビリティ・キーを使用して移動登録メッセージ中の認証拡張部を生成」するものであり、認証サーバにおいて移動登録メッセージ中の認証拡張部を生成するものでない。したがって、上記（１）の本願発明の発明特定事項に含まれる「認証サーバにおいて、第２の無線アクセス技術用に確立された規格にしたがって、要求されたアクセス登録のために第２の認証拡張部を生成する」ことは、発明の詳細な説明に記載されているといえない。
　よって、上記（１）の本願発明の発明特定事項は、発明の詳細な説明に記載されていない。
　更に、上記「第３　２」の請求人の主張について検討する。
　請求人は、段落００１８及び００２４の「認証拡張部の計算」という記載から、認証拡張部を生成することは本願明細書中に記載されており、「認証拡張部」は第１の認証拡張部に限定するものではない旨主張する。
　しかし、上記のとおり、「認証サーバにおいて、第２の無線アクセス技術用に確立された規格にしたがって、要求されたアクセス登録のために第２の認証拡張部を生成する」ことが、発明の詳細な説明に記載されているとはいえないので、請求人の上記主張は採用できない。
　したがって、上記（１）を発明特定事項として含む本願発明は、発明の詳細な説明に記載したものとはいえない。
２　「理由３（２）」について（第１および第２の認証拡張部を用いて認証サーバにおいて、受信した登録を要求するメッセージを検証することについて）
　本願発明は、「第１および第２の認証拡張部を
用いて
下線部
　上記発明特定事項について検討すると、発明の詳細な説明には、当該事項について明示的な記載はない。そして、上記１（２）イ（ウ）のとおり、上記技術常識を考慮すると、発明の詳細な説明に発明として記載されたものは、「ＭＳにおいて、モビリティ・キーを使用して移動登録メッセージ中の認証拡張部を生成する」といえるから、第１の認証拡張部とは別に存在する認証サーバにおいて生成される「第２の認証拡張部」は、発明の詳細な説明に発明として記載されたものには存在しない。そうすると、「第２の認証拡張部」は存在しないから、認証サーバにおいて、受信した登録を要求するメッセージを検証する際、第１および第２の認証拡張部を比較することも、用いることもできないことは明らかである。
　よって、「第１および第２の認証拡張部を用いて認証サーバにおいて、受信した登録を要求するメッセージを検証する」という発明特定事項を含む本願発明は、発明の詳細な説明に記載したものとはいえない。
エ　小括
　上記１、２のとおり、本願発明は、発明の詳細な説明に記載したものとはいえないので、当審拒絶理由の理由３（１）、（２）は解消しておらず、本願発明は、特許法第３６条第６項第１号に規定する要件を満たしていない。
第５　むすび
　以上のことから、この出願は、特許請求の範囲の記載が特許法第３６条第６項第１号の規定する要件を満たしてないから、他の要件を検討するまでもなく、特許を受けることができない。
　よって、結論のとおり審決する。