【事件の表示】
　特願２００６−５５１１９９「事前認証、事前設定及び／又は仮想ソフトハンドオフを使用するモビリティアーキテクチャ」拒絶査定不服審判事件〔平成１７年　８月１１日国際公開、ＷＯ２００５／０７２１８３、平成１９年　８月　９日国内公表、特表２００７−５２２７２５〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯・本願発明
　本願は、２００５年１月２１日（パリ条約による優先権主張外国庁受理２００４年１月２２日、米国）を国際出願日とする出願であって、原審において平成２１年１１月２０日付けで拒絶査定され、平成２２年４月１日に審判請求がなされたものであるところ、
　本件出願の請求項１に係る発明（以下、「本願発明」という。）は、平成２１年９月３日付けで補正された明細書および図面の記載からみて、その特許請求の範囲の請求項１に記載された次のとおりのものである。
　
　「【請求項１】
　上位層事前認証に基づいてハンドオフの前に上位層コンテキストを事前に確立することによって、移動局のハンドオフ遅延を削減するステップと、
　複数の前記上位層コンテキストを事前に確立するための単一上位層認証プロトコルを使用するステップと、を含む、方法。」
　
　
２．引用例に記載された発明
　原査定の拒絶の理由に引用された、draft-ietf-mobileip-fast-mipv6-08.txt, INTERNET DRAFT, 10 October 2003, Mobile IP Working Group, Rajeev Koodli, URL:http://tools.ietf.org/html/draft-ietf-mobileip-fast-mipv6-08（以下、「引用例」という。）には、「Fast Handovers for Mobile IPv6」（邦訳：モバイルIPv6のための高速ハンドオーバー）として図面と共に次の記載がある。
　
イ．「Abstract
　
Mobile IPv6 enables a Mobile Node to maintain its connectivity to
the Internet when moving from an Access Router to another, a process
referred to as handover.  During handover, there is a period when
the Mobile Node is unable to send or receive packets both due to
link switching delay and IP protocol operations.  This ``handover
latency'' resulting from standard Mobile IPv6 procedures, namely
movement detection, new Care of Address configuration and Binding
Update, is often unacceptable to real-time traffic such as Voice
over IP. Reducing the handover latency could be beneficial to non
real-time, throughput-sensitive applications as well.  This document
specifies enhancements to reduce the handover latency due to standard
Mobile IPv6 procedures.  This document does not address improving the
link switching latency.」（Page i）
　
（イ．邦訳：
要約
　
モバイルIPv6は、モバイルノードが、あるアクセスルータから別のアクセスルータへ移動する、ハンドオーバーと呼ばれるプロセスにおいて、インターネットへの接続を維持することを可能にします。　ハンドオーバー中に、リンク・スイッチング遅延およびIPプロトコルオペレーションによって、モバイルノードがパケットを送信することも受信することもできない期間があります。　この「ハンドオーバー遅延」は、標準のモバイルIPv6手続き、すなわち移動の検出、新しい気付けアドレスの設定、結合の更新に起因するものであり、ボイス・オーバーIPのようなリアルタイムトラフィックにおいては、しばしば承諾しがたいものです。　ハンドオーバー遅延の削減は、非リアルタイムな、スループットに敏感なアプリケーションにも有益になりえます。　このドキュメントは、標準のモバイルIPv6手続きに起因する、ハンドオーバー遅延を削減するための拡張を規定します。　このドキュメントは、リンク・スイッチング遅延の改善には取り組みません。）
　
　
ロ．「1. Introduction
　
Mobile IPv6 [3] describes the protocol operations for a mobile node
to maintain connectivity to the Internet during its handover from one
access router to another.  These operations broadly involve movement
detection, IP address configuration, and location update phases.
The combined handover latency could be (especially) appreciable
for real-time applications.  Throughput-sensitive applications can
also benefit from reducing this latency.  This document describes a
protocol to reduce the handover latency.
　
This specification addresses the following problem:  how to allow
a mobile node to send packets as soon as it detects a new subnet
link, and how to deliver packets to a mobile node as soon as its
attachment is detected by the new access router.  The protocol
defines IP protocol messages necessary for its operation on any link
technology.  It does this without depending on specific link-layer
features while allowing link-specific customizations.  By definition,
this specification considers handovers that inter-work with Mobile
IP: once attached to its new access router, a MN engages in Mobile
IP operations including Return Routability [3].  Hence, there are no
special requirements for a mobile node to behave differently with
respect to its standard Mobile IP operations.
　
　
   2. Terminology
　
   The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL
   NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, OPTIONAL, and
   silently ignore in this document are to be interpreted as described
   in RFC 2119 [1].
　
   The following terminology and abbreviations are used in this
   document.  The reference handover scenario is illustrated in
   Figure 1.
　
      Mobile Node (MN)
               A Mobile IPv6 host
　
      Access Point (AP)
               A Layer 2 device connected to a subnet that offers
               wireless connectivity to a MN.
　
      Access Router (AR)
               The MN's default router
　
      Previous Access Router (PAR)
               The MN's default router prior to its handover
　
      New Access Router (NAR)
               The MN's anticipated default router subsequent to its
               handover
　
      Previous CoA (PCoA)
               The MN's Care of Address valid on PAR. The MN may reuse
               this address while attached to NAR until it finishes
               Mobile IP operations.
　
      New CoA (NCoA)
               The MN's Care of Address valid on NAR
　
      Handover
               A process of terminating existing connectivity and
               obtaining new IP connectivity.
　
      Router Solicitation for Proxy (RtSolPr)
               A message from the MN to the PAR requesting information
               for a potential handover
　
      Proxy Router Advertisement (PrRtAdv)
               A message from the PAR indicating a MN to undergo
               handover
　
      Fast Binding Update (FBU)
               A message from the MN instructing its PAR to redirect its
               traffic (towards NAR)
　
      Fast Binding Acknowledgment (FBACK)
               A message from the PAR in response to FBU
      Fast Neighbor Advertisement (FNA)
               A message from the MN to the NAR to announce attachment
               and to confirm use of NCoA when the MN has not received
               FBACK
　
      Handover Initiate (HI)
               A message from the PAR to the NAR to initiate handover
　
      Handover Acknowledge (HACK)
               A message from the NAR to the PAR as a response to HI
」（Page 2-3）
　
（ロ．邦訳：
1. はじめに
　
モバイルIPv6[3]は、あるモバイルノードが、一つのアクセスルータから別のアクセスルータまでハンドオーバーする間、インターネットへの接続を維持するためのプロトコル・オペレーションについて記述します。　これらのオペレーションは、広く移動検出、IPアドレス設定、および位置更新の相を含んでいます。
結合したハンドオーバー遅延は、（特に）リアルタイムアプリケーションにおいてはかなり問題になり得ます。
スループットに敏感なアプリケーションもまた、この遅延の削減から利益を得る場合があります。
このドキュメントは、ハンドオーバー遅延を削減するためのプロトコルについて記述します。
　
この仕様は次の問題に取り組みます:　モバイルノードが新しいサブネット・リンクを検知するとすぐに、パケットを送ることを可能にする方法、および新しいアクセスルータによって、アタッチメントが検知されるとすぐに、モバイルノードにパケットを配達する方法。　このプロトコルは、任意のリンク技術において動作するのに必要なIPプロトコルメッセージを定義します。　このプロトコルは、特定のリンクレイヤの特徴に依存しませんが、リンクに特有のカスタマイゼーションは許可されます。　定義によって、この仕様は、モバイルIPで相互に働くハンドオーバーを考慮します:　MNが一旦その新しいアクセスルータに付けられたならば、MNはリターン経路可能性[3]を含むモバイルIPオペレーションに従事します。　従って、モバイルノードが標準のモバイルIPオペレーションと違った動作をする必要は特にありません。
　
　
2. 用語
このドキュメント中のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、「OPTIONAL」、そして「静かに‥‥無視する」は、RFC 2119[1]に述べられているように解釈されるべきです。
　
次の用語および省略形は、このドキュメントの中で使用されます。
ハンドオーバーの参照シナリオは、図1に例示されます。
　
モバイルノード(MN)
　　モバイルIPv6のホスト
　
アクセス・ポイント(AP)
　　MNへ無線接続を提供する、サブネットに接続された2層装置
　
アクセスルータ(AR)
　　MNのデフォルト・ルーター
　
前のアクセスルータ(PAR)
　　ハンドオーバー前における、MNのデフォルト・ルーター
　
新しいアクセスルータ(NAR)
　　そのハンドオーバーの後に予期される、MNのデフォルト・ルーター
　
前のCoA(PCoA)
　　PARの上で有効なMNの気付けアドレス。
　　NARに接続されていても、MNがモバイルIPオペレーションを終了するまで、MNはこのアドレスを再使用するかもしれません。
　
新しいCoA(NCoA)
　　NARの上で有効な、MNの気付けアドレス
　
ハンドオーバー
　　既存の接続を終了し、新しいIP接続を得る過程。
　
プロキシー(RtSolPr)のためのルーター懇請
　　潜在的なハンドオーバーのための情報を要求する、MNからPARへのメッセージ
　
プロキシー・ルーター広告(PrRtAdv)
　　MNにハンドオーバーを経験することを示す、PARからのメッセージ
　
高速な結合の更新(FBU)
　　(NARへの)通信を転送するようにPARに命じる、MNからのメッセージ
高速な結合の認識(FBACK)
　　FBUへの応答としてのPARからのメッセージ
　
高速な隣接値広告(FNA)
　　アタッチメントを発表し、かつMNがFBACKを受け取っていない場合にNCoAの使用を確認する、MNからNARへのメッセージ
　
ハンドオーバー開始(HI)
　　ハンドオーバーを始める事を示す、PARからNARへのメッセージ
　
ハンドオーバー肯定応答(HACK)
　　HIへの応答としての、NARからPARまでのメッセージ）
　
　
ハ．「3. Protocol Overview
　
3.1. Addressing the Handover Latency
　
The ability to quickly send packets from a new subnet link depends
on the ``IP connectivity'' latency, which in turn depends on the
　
               Figure 1: Reference Scenario for Handover
　
movement detection latency and the new CoA configuration latency.
Once a MN is IP-capable on the new subnet link, it can send Binding
Update to its Home Agent and one or more correspondents.  Once
its correspondents successfully process the Binding Update, which
involves the Return Routability procedure, the MN can receive packets
at new CoA. So, the ability to receive packets from correspondents
directly at its new CoA depends on the Binding Update latency.
　
The protocol enables a MN to quickly detect that it has moved to
a new subnet by providing the new access point and the associated
subnet prefix information when the MN is still connected to its
current subnet (i.e., PAR in Figure 1).  For instance, a MN may
discover available access points using link-layer specific mechanisms
(e.g., a ``scan'' in WLAN) and then request subnet information
corresponding to one or more of those discovered access points.
The MN may do this after performing router discovery.  The MN may
also do this at any time during its sojourn on its current point of
attachment.  The result of resolving an identifier associated with
an access point is a [AP-ID, AR-Info] tuple, which a MN can use in
readily detecting movement:  when attachment to an access point
with AP-ID takes place, the MN knows the corresponding new router's
co-ordinates including its prefix, IP address and MAC address.  The
``Router Solicitation for Proxy (RtSolPr)'' and ``Proxy Router
Advertisement (PrRtAdv)'' messages are used for aiding in movement
detection.
　
Through the RtSolPr and PrRtAdv messages, the MN also formulates
a prospective new CoA (NCoA), again when still present on PAR's
link.  Hence, the latency due to new prefix discovery subsequent to
handover is eliminated.  Furthermore, this prospective address can
be used immediately after attaching to the new subnet link (i.e.,
NAR's link) when the MN has received a ``Fast Binding Acknowledgment
(FBack)'' message prior to its movement.  In the event it moves
without receiving an FBack, the MN can still start using NCoA after
announcing its attachment through a ``Fast Neighbor Advertisement
(FNA)'' message; NAR responds to FNA in case the tentative address
is already in use.  In this way, NCoA configuration latency is
reduced.  Under some limited conditions where the probability of
address collision is considered insignificant, it may be possible
to use NCoA immediately after attaching to the new link.  Even so,
all implementations MUST implement the mechanism specified in this
document to avoid potential address conflicts and SHOULD support
them.」（Page3-5）
　
（ハ．邦訳：
3. プロトコル概観
　
3.1. ハンドオーバー遅延の特定
　
新しいサブネット・リンクから迅速にパケットを送る能力は、「IP接続」の遅延、すなわちこれは順に、
　
            図1:ハンドオーバーの参照シナリオ
　
移動検出の遅延および新しい気付けアドレス設定の遅延に依存します。
一旦MNが新しいサブネット・リンク上でIP対応になれば、MNはそのホームエージェントおよび1人以上の通信相手へ結合の更新を送ることができます。　そして、一旦その通信相手が、リターン経路可能手続きを含む結合の更新の処理に成功すれば、MNは新しいCoAでパケットを受信することができます。　したがって、その新しいCoAで直接通信相手からのパケットを受信する能力は、結合の更新の遅延に依存します。
　
このプロトコルは、MNがその現在のサブネット(つまり図1の中のPAR)にまだ接続されている時に、新しいアクセス・ポイントおよび関連するサブネットプレフィックス情報を提供することにより、新しいサブネットにMNが移ったことを素早く検知することができます。　例えば、MNは、リンクレイヤ特有の機構(例えばWLANの中の「走査」)を使用して、利用可能なアクセス・ポイントを発見するかもしれません。そして次に発見されたアクセス・ポイントの1つ以上に対応するサブネット情報を要求するかもしれません。
MNは、ルーター発見を行なった後に、これをするかもしれません。　MNは、さらに現在の接続点への滞在の間にいつでも、これをするかもしれません。　アクセス・ポイントに関連した識別子を解決した結果は、MNが直ちに移動を検出する際に使用できる[AP-ID、AR情報]の組であり:　AP-IDを持つアクセス・ポイントへのアタッチメントが起こる場合、MNは対応する新しいルーターの接頭辞、IPアドレスおよびMACアドレスを含めた座標を知ることとなります。　「ルーターのプロキシー懇請(RtSolPr)」、そして「プロキシールーター広告(PrRtAdv)」メッセージは、移動検出の援助のために使用されます。
　
RtSolPrとPrRtAdvのメッセージによって、さらに再びPARのリンク上にまだ存在する場合であっても、MNは予期される新しいCoA(NCoA)を公式化もします。　従って、ハンドオーバーの後に続く新しい接頭辞発見のための遅延は除去されます。　更に、MNがその移動に先立って「高速な結合の認識」(FBack)メッセージを受け取った場合、新しいサブネット・リンク(つまりNARのリンク)に付いた後に直ちに、この予期されるアドレスは使用することができます。　MNがFBackを受け取らずに移動する場合であっても、それでもMNは、「高速な隣接値広告」(FNA)メッセージによってそのアタッチメントを発表した後にNCoAを使用し始めることができます;　この場合、もし一時的アドレスが既に使用されていた時には、NARはFNAに応答します。　このようにして、NCoA設定の遅延は削減されます。
アドレス衝突の可能性が些細であると考えられるいくつかの制限された条件の下では、新しいリンクに付いた直後にNCoAを使用することは可能かもしれません。　それでも、すべての実装は、潜在的なアドレス矛盾を回避するためにこのドキュメント中で指定された機構を実装しなければならず、また、それらをサポートしなければなりません。）
　
ニ．「
                 Figure 2: ``Predictive'' Fast Handover
」（Page8）
（ニ．邦訳：
　　　　　　　　　図2:「予測的な」高速ハンドオーバー）
　
　上記引用例の記載及び関連する図面ならびにこの分野における技術常識を考慮すると、
まず、上記引用例記載の方法は、上記イ．ロ．にあるように「モバイルノードが、あるアクセスルータから別のアクセスルータへ移動する、ハンドオーバーと呼ばれるプロセスにおいて」、「ハンドオーバー遅延の削減」をするための方法であって、
　上記ハ．４頁中段に「このプロトコルは、MNがその現在のサブネット(つまり図1の中のPAR)にまだ接続されている時に、新しいアクセス・ポイントおよび関連するサブネットプレフィックス情報を提供することにより」とあるように、
MN（モバイルノード）がPARにまだ接続されている時、すなわち移動（ハンドオーバー）する前に「サブネットプレフィックス情報を提供」する「プロトコル」を使用するものである。
　そして、上記ハ．４頁下段〜５頁上段には、「AP-IDを持つアクセス・ポイントへのアタッチメントが起こる場合、MNは対応する新しいルーターの接頭辞、IPアドレスおよびMACアドレスを含めた座標を知ることとなります。」、
「RtSolPrとPrRtAdvのメッセージによって、さらに再びPARのリンク上にまだ存在する場合であっても、MNは予期される新しいCoA(NCoA)を公式化もします。」、などの記載があって、
　更に上記ニ．の引用例図２には、MNの「disconnect」、「connect」（切断、接続：実効的なハンドオーバーの期間と認められる）の前に、前記「RtSolPr」、「PrRtAdv」更には「FBU」（高速な結合の更新）などのメッセージがやりとりされることが開示されており、
ここで、上記メッセージ自体あるいは、メッセージに含まれる、少なくとも「新しいルーターの接頭辞、IPアドレス」、「新しいCoA(NCoA)」（新しい気付けアドレス）などの情報は、前記「サブネットプレフィックス情報」と同様な『ネットワークに関する情報』であるから、結局、引用例記載の方法は、
『ハンドオーバーの前にネットワークに関する情報を事前にやりとりするためのプロトコル』を使用する方法であるということができる。
　
　したがって、上記引用例には以下の発明（以下、「引用発明」という。）が開示されている。
　
（引用発明）
「モバイルノードが、あるアクセスルータから別のアクセスルータへ移動する、ハンドオーバーと呼ばれるプロセスにおいて、ハンドオーバー遅延を削減するための方法であって、
　ハンドオーバーの前にネットワークに関する情報を事前にやりとりするためのプロトコルを使用する方法」
　
　
３．対比・判断
　本願発明と引用発明とを対比する。
　まず、引用発明の「モバイルノード」は、「モバイル」すなわち移動する「ノード」（通信局）であるから、本願発明の「移動局」に相当し、引用発明の「ハンドオーバー」は、本願発明の「ハンドオフ」のことである。
　また、引用発明の「ネットワークに関する情報」と、本願発明の「上位層コンテキスト」を対比すると、
　本願発明の「上位層」とは、本願明細書【００１４】によれば、「本書では、第２層より高い層（例えば、ＯＳＩモデル等でネットワーク層又は第３層を含む層）は上位層と呼ばれている。」とあり、
　本願発明の「コンテキスト」とは、本願明細書【００２３】によれば、「ハンドオフの間、システムは移動局と新しいネットワーク接続ポイントの間で維持される状態を確立し直す。ハンドオフに関係するこれらの状態は、ハンドオフコンテキスト又は単に「コンテキスト」と呼ばれることもある。」とあって、
　引用発明の「ネットワークに関する情報」も、上記認定で述べたように具体的には例えば、「新しいルーターの接頭辞」、「IPアドレス」、「新しいCoA(NCoA)」（新しい気付けアドレス）、「サブネットプレフィックス情報」などであって、
「ネットワーク層」（第３層）であるＩＰ層についての情報であるから「上位層」に関するものであり、
　ハンドオーバーに際してモバイルノードとアクセスルータとの間でやりとりされるから、ハンドオフに関する状態情報であって「コンテキスト」ということができるものである。
　小括すれば、両者は「上位層コンテキスト」の点で一致する。
　そして、引用発明の「ネットワークに関する情報」（上位層コンテキスト）は、上記のようにアクセスルータとの間でやりとりされるから、これらの間で「確立」されるものである。
　
　したがって、本願発明と引用発明とは、以下の点で一致し、また相違する。
　
（一致点）
「　ハンドオフの前に上位層コンテキストを事前に確立することによって、移動局のハンドオフ遅延を削減するステップと、
　前記上位層コンテキストを事前に確立するためのプロトコルを使用するステップと、を含む、方法」
　
（相違点）
（１）「上位層コンテキスト」の確立が、本願発明では「上位層事前認証に基づいて」行われるのに対し、引用発明では不明な点。
　
（２）「プロトコル」が、本願発明は「複数の前記上位層コンテキストを事前に確立するための単一上位層認証プロトコル」であるのに対し、引用発明は単に「ハンドオーバーの前にネットワークに関する情報を事前にやりとりするためのプロトコル」であって、「複数の」上位層コンテキストを事前に確立する点、および「単一上位層認証」プロトコルであるかが不明な点。
　
　
　まず、上記相違点（１）の「上位層事前認証」の点に関し検討するに、
　引用発明の「ネットワークに関する情報」として引用例に記載された「RtSolPr」、「PrRtAdv」などのメッセージの具体的フォーマットは、摘記はないが引用例の１５〜１８頁に記載があり、そこには「IP Fields:」（IPフィールド）のオプションとして「Authentication Header」（認証ヘッダ）が含まれうることが開示されている。
　ＩＰ層が「上位層」であることは、前記対比のところで述べたとおりであり、引用発明ではこれらの情報が事前にやりとりされるものであるから、引用発明の「ネットワークに関する情報」（上位層コンテキスト）を「上位層事前認証」に基づいて確立することは、上記引用例の記載より当業者であれば容易に想到し得たものであり、相違点（１）は格別のことではない。
　また別の観点によれば、移動体通信におけるハンドオーバ−に際して「事前認証」を行うことは、例えば特開２００３−２８４１１７号公報（請求項２１、【００３７】）、特開２００３−３３３６３９号公報（請求項３９，４０、【００３０】）、特開２００４−７５７６号公報（請求項１）にあるように周知技術であるから、引用発明を「上位層事前認証」に基づくものとして相違点（１）に関する本願発明をなすことは、これも当業者であれば容易に想到し得たものにすぎない。
　
　ついで、上記相違点（２）の、「複数の」上位層コンテキストを「単一上位層認証」プロトコルを使用して確立する点について検討する。
　そもそも引用発明の「プロトコル」は、引用例の上記イ．にあるように、既存の「Mobile IPv6」（モバイルIPv6）プロトコルに対する拡張として提案された、ＩＰ層（上位層）に関するプロトコルであるが、このようなプロトコルが、その改良、バージョンアップに伴い、種々の機能を追加・更新しながら一つのプロトコルとして発展的に定義されるものであることは、例えばIPv4からIPv6への移行自体にも見られるように、ネットワーク技術の分野では当然のことに過ぎない。
　また、上記相違点（１）の判断においても述べたように、引用例には「認証」に関する記載もあって、更にハンドオーバ−に際して「事前認証」を行うこと自体も周知技術である。
　そして、引用発明の「プロトコル」によって確立される「ネットワークに関する情報」（上位層コンテキスト）として、引用例には「新しいルーターの接頭辞」、「IPアドレス」、「新しいCoA(NCoA)」（新しい気付けアドレス）、「サブネットプレフィックス情報」など複数の種類の情報が例示されており、これらをまとめて「複数の」上位層コンテキストを「単一上位層認証」プロトコルを使用して確立するのは適宜なことであるから、相違点（２）も格別のことではない。
　
　また、本願発明の効果も引用発明及び周知技術から当業者が予測し得る範囲のものである。
　
４．むすび
　以上のとおり、本願発明は、引用発明及び周知技術に基づいて当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　
　よって、結論のとおり審決する。