【事件の表示】
　特願２０１５−　　７６５３「移動インターネットプロトコルを使用するＵＥ間転送サポート」拒絶査定不服審判事件〔平成２７年　５月２８日出願公開、特開２０１５−１００１２６〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１　手続の経緯
　本願は、２０１１年（平成２３年）４月１５日（パリ条約による優先権主張外国庁受理　２０１０年４月１６日　米国、２０１０年４月２９日　米国）を国際出願日とする出願である特願２０１３−５０５１６４号の一部を、平成２７年１月１９日に新たな特許出願としたものであって、平成２７年２月１８日に特許法第３６条の２第２項の規定による外国語書面及び外国語要約書面の日本語による翻訳文が提出され、同日に手続補正がされ、平成２７年３月１１日に手続補正がされ、平成２７年１２月２４日付けの拒絶理由通知に対して平成２８年４月１日に意見書が提出されるとともに手続補正がされ、平成２８年９月２３日付けで拒絶査定がされ、これに対し、平成２９年２月６日に拒絶査定不服審判の請求がされると同時に手続補正がされたものである。
第２　平成２９年２月６日にされた手続補正についての補正の却下の決定
［補正の却下の決定の結論］
　平成２９年２月６日にされた手続補正（以下、「本件補正」という。）を却下する。
［理由］
１　補正の内容
　本件補正前の特許請求の範囲の請求項１の記載は、次のとおりである。
「【請求項１】
　第１の無線送受信ユニット（ＷＴＲＵ）からフローを転送する方法において、
　ノードと前記フローを確立するステップであって、第１のトラフィックセレクタを含む第１のバインディング更新を送ることによって前記フローが確立されるステップと、
　ユニット間転送（ＩＵＴ）準備要求を第２のＷＴＲＵへ送るステップと、
　前記第２のＷＴＲＵが前記ＩＵＴを受け付けることを示しているＩＵＴ準備応答を、前記第２のＷＴＲＵから受信するステップと、
　前記受信されたＩＵＴ準備応答に基づいて、ＨＡへ第２のバインディング更新を送るステップであって、前記第２のバインディング更新は前記フローに属するパケットを前記第２のＷＴＲＵへルーティングする第２のトラフィックセレクタを含む、ステップと
　を備えることを特徴とする方法。」（以下、「本願発明」という。）
　そして、本件補正により、特許請求の範囲の請求項１の記載は、次のとおり補正された。（下線部は、補正箇所である。）
「【請求項１】
第１の無線送受信ユニット（ＷＴＲＵ）からフローを転送する方法において、
　
前記第１のＷＴＲＵによって、
前記フローは、複数のフローの中で前記フローを一意的に識別している関連付けられたフロー識別子を有している
　
前記第１のＷＴＲＵによって、
であって、前記ＩＵＴ準備要求は前記フローに関連付けられた情報を含んでいる、ステップ
　前記第１のＷＴＲＵによって、前記第２のＷＴＲＵがＩＵＴを受け付けることを示しているＩＵＴ準備応答を、前記第２のＷＴＲＵから受信するステップと、
　前記受信されたＩＵＴ準備応答に基づいて、ＨＡへ第２のバインディング更新を送るステップであって、前記第２のバインディング更新は、
前記フロー識別子と、
　を備えることを特徴とする方法。」（以下、「本件補正発明」という。）
２　補正の適否
　上記補正は、本願発明を特定するために必要な事項である「・・・確立するステップ」、「・・・送るステップ」、「・・・受信するステップ」を実行する主体を「第１のＷＴＲＵ」に限定し、「フロー」、「ＩＵＴ準備要求」及び「第２のバインディング更新」について下線部のとおり限定を付加するものであって、補正前の請求項１に記載された発明と補正後の請求項１に記載された発明の産業上の利用分野及び解決しようとする課題が同一であるから、特許法第１７条の２第５項第２号の特許請求の範囲の減縮を目的とするものに該当する。
　そして、本件補正において、特許法第１７条の２第３項（新規事項）、第４項（シフト補正）に違反するところはない。
　そこで、本件補正発明が特許出願の際独立して特許を受けることができるものであるか否かについて以下に検討する。
（１）本件補正発明
　本件補正発明は、上記「１」に「本件補正発明」として記載したとおりのものと認める。
（２）引用発明及び周知事項
ア　引用例１の記載事項及び引用発明
（ア）原査定の拒絶の理由で引用された国際公開第２００８／０８７９３７号（以下、「引用例１」という。）には、図面とともに、次の記載がある。（以下、下線は当審にて付した。）
「[0001]　本発明は
Ｍｏｂｉｌｅ　ＩＰ技術を利用した端末間のセッションハンドオーバシステムに関する
「[0010]　ＭＩＰ６では、ＭＮがＨｏｍｅ　Ｌｉｎｋにいる場合は、通常のＩＰｖ６通信と同様の動作を行う。
[0011]　次に、図２１に示すように、ＭＮ１８がＦｏｒｅｉｇｎ　Ｌｉｎｋへ移動した場合は、Ｆｏｒｅｉｇｎ　Ｌｉｎｋ上のルータ１９が定期的に、問い合わせメッセージ、ルータ広告（Ｒｏｕｔｅｒ　Ａｄｖｅｒｔｉｓｅｍｅｎｔ、以下「ＲＡ」という）を送信しているため、ＭＮ１８はこれを受信することで自身が移動したことを検知する。
[0012]　移動を検知すると、
ＭＮ１８は
気付けアドレス（Ｃａｒｅ−ｏｆ−Ａｄｄｒｅｓｓ、以下、「ＣｏＡ」という）
ＨＡ２０に対して登録要求（Ｂｉｎｄｉｎｇ　Ｕｐｄａｔｅ、以下、「ＢＵ」という、なお、「Ｂｉｎｄｉｎｇ」は、ＨｏＡとＣｏＡとの対応付けを表す）を行う
[0013]　
ＨＡ２０では、ＭＮ１８のＢＵを受信すると、
ＭＮ１８に関するホームアドレス（Ｈｏｍｅ　Ａｄｄｒｅｓｓ、以下、「ＨｏＡ」という）とＣｏＡの対を登録する。
[0014]　このようにすることで、ＭＮ１８と通信を行っている
対向ノード（Ｃｏｒｒｅｓｐｏｎｄｅｎｔ　Ｎｏｄｅ、以下、「ＣＮ」という）２１からＭＮ１８に向けて送信されたパケットは、ＨＡ２０が
転送する。ＭＮ１８では、
受信する。
「発明の効果
[0038]　本発明によれば、Ｍｏｂｉｌｅ　ＩＰの仕組みを利用し、かつ、Ｍｏｂｉｌｅ　ＩＰの機能を一部拡張することで、ネットワークセグメントを跨ったハンドオーバと、
異なる２つの端末間での切替えによる通信（セッションハンドオーバ、ＳＨ）
[0039]　すなわち、切替先
端末（ＭＮ）
端末（ＭＮ）
ホームエージェント（ＨＡ）
ホームアドレス（ＨｏＡ）
バインディングアップデート（ＢＵ）
[0040]　また、同じ通信相手と複数のセッションを張っていた場合、特定のセッションのみハンドオーバを行うことができる。」
「[0062]　
［実施例１］
　次に、
図４、５に示されるシーケンス図に従って、本実施例におけるＭＮ−ａ２からＭＮ−ｂ４へのＳＨの過程を説明する。
　すなわち、ＭＮ−ａ２は、切替元端末、ＭＮ−ｂ４は、切替先端末ということになる。
　尚、ＭＮ−ａ２からＭＮ−ｂ４へのＳＨを行う前提として、以下のことを既知として説明を行う。
[0063]　すなわち、
ＭＮ−ａ２、ＭＮ−ｂ４
互いのＣｏＡ（ＣｏＡ−ａ、ＣｏＡ−ｂ）
[0064]　
（１）ＳＨ実施前
　今、図４に示されるように、
ＭＮ−ａ２がＨＡ−ａ３を経由して、ＣＮ１からコンテンツを受信している
[0065]　
（２）ＳＨ要求
　本実施例では、ＭＮ−ｂ４がＳＨのきっかけを引き起こすとする。図５に示すように、
ＭＮ−ｂ４
は、ＭＮ−ａ２に対してＳＨ要求パケットを送信する。このパケットには、ＭＮ−ａ２からＭＮ−ｂ４へのＳＨを依頼する旨が記されている情報が含まれている。
・・・略・・・
[0067]　
（４）ＳＨ許可
　ＭＮ−ｂ４のＭＡＣアドレスが登録されている場合は、
ＳＨ通信手段１１がＳＨ許可をＭＮ−ｂ４に対して送信する。このパケットには、ＭＮ−ａ２からＭＮ−ｂ４へのＳＨを認める旨が記された情報が含まれている。
[0068]　（５）ＢＵ要求
　次に、
ＭＮ−ａ２からのＳＨ許可パケットを受信したＭＮ−ｂ４のＳＨ管理部１０
は、
自身のＭｏｂｉｌｅ　ＩＰ管理部９に対して、ＢＵ要求を行う。
[0069]　
（６）ＨＡ−ａ３へのＢＵ
　
ＢＵ要求を受け取ったＭＮ−ｂ４のＭｏｂｉｌｅ　ＩＰ管理部９では、ＨＡ−ａ３に対してＢＵを行う（ＢＵパケットを送信する）。
　　図６は、ＨＡ−ａ３におけるＢＵ前のＢＣを示す図である。
　　
図７は、ＭＮ−ｂ４からＨＡ−ａ３に送信されるＢｉｎｄｉｎｇ情報を示す図である。
　　
図８は、ＭＮ−ｂ４からＨＡ−ａ３に送信されるセッション情報を示す図である。
[0070]　本実施例では、
ＢＵパケットの内容として、
Ｂｉｎｄｉｎｇ情報、および
セッション情報が含まれている
Ｂｉｎｄｉｎｇ情報とは、ＨＡ−ａ３
に登録を要求するＢｉｎｄｉｎｇの情報を記載したものであり、
セッション情報とは、ＨＡ−ａ３
においてＢｉｎｄｉｎｇを更新する際に検索キーとして利用するための、セッションに関する情報である。
・・・略・・・
[0072]　（８）Ｂｉｎｄｉｎｇの更新
　ＢＵが認められた場合は、ＢＣ管理部１７にこれを伝え、該当するＢｉｎｄｉｎｇが更新される。尚、Ｂｉｎｄｉｎｇの更新方法については、非特許文献１で規定される通常のＭＩＰ機能を利用しても良いが、本実施例においては、図９記載のフローチャートに基づき、詳細に記述する。
[0073]　今、
Ｂｉｎｄｉｎｇが更新される前段階において、ＨＡ−ａ３
に、図６に示されるＢｉｎｄｉｎｇが登録されていた
図６を見ると、
ＨｏＡ−ａ宛のパケットがＣｏＡ−ａ宛に転送されることがわかる。
[0074]　今、ＨＡ−ａ３が図７記載のＢｉｎｄｉｎｇ情報と図８記載のセッション情報を含むＢＵパケットを受信したとする。
[0075]　まず、Ｓ１にて、ＨＡ−ａ３のＭｏｂｉｌｅ　ＩＰ管理部１６が、ＭＮ−ｂ４から受信したＢＵパケットからＢｉｎｄｉｎｇ情報およびセッション情報を抽出して、ＢＣ管理部１７に出力を行う。
[0076]　Ｓ２でＨＡ−ａ３のＢＣ管理部１７では、このセッション情報に一致するものが登録されているかを検索する。登録されていない場合には、Ｓ７において、Ｂｉｎｄｉｎｇ情報をＨＡ−ａ３のＢＣへ新規登録して処理を終了する。本実施例においては、図６を参照すると、該当するＢｉｎｄｉｎｇがあることがわかるので、次にＳ３で、Ｂｉｎｄｉｎｇ情報に含まれるｌｉｆｅｔｉｍｅの値を抽出する。０ｍｉｎ．であれば、Ｓ４にて、そのままｌｉｆｅｔｉｍｅの上書きを行うが、本実施例では０ｍｉｎ．ではないので、Ｓ５にて該Ｂｉｎｄｉｎｇを、ＭＮ−ｂ４から受信したＢＵパケット内のＢｉｎｄｉｎｇ情報内に記載のｌｉｆｅｔｉｍｅの期間（１０ｍｉｎ．）だけ無効化し（例えば図１０では、Ａｖａｉｌａｂｉｌｉｔｙの項目を「×、１０ｍｉｎ．」と表記することで無効化している）、さらにＳ６で、該Ｂｉｎｄｉｎｇのｌｉｆｅｔｉｍｅ（２ｍｉｎ．）とＢＵパケット内のＢｉｎｄｉｎｇ情報に記載されているｌｉｆｅｔｉｍｅ（１０ｍｉｎ．）を加算した１２ｍｉｎ．を新たに該Ｂｉｎｄｉｎｇのｌｉｆｅｔｉｍｅと設定した後、Ｓ７にてＢＵパケット内のＢｉｎｄｉｎｇ情報を、ＨＡ−ａ３のＢＣへ新規登録する。尚、新規に登録したＢｉｎｄｉｎｇのｌｉｆｅｔｉｍｅと、上記Ｂｉｎｄｉｎｇの無効化の過程において設定を行ったＨｏＡ−ａとＣｏＡ−ａ、ポート番号９０８０番に対応したｌｉｆｅｔｉｍｅとＡｖａｉｌａｂｉｌｉｔｙとは、互いに関連付けられているものとする。
[0077]　ＨＡ−ａ３のＢＣ管理部１７において更新されたＢｉｎｄｉｎｇ状況を図１０に示す。図１０を見ると、２行目が無効化され（ＣＮ＿Ａｄｄｒと９０８０番ポートを使用して通信しているＣｏＡ−ａ宛に転送されるＢｉｎｄｉｎｇが無効化され）、さらに、２行目のｌｉｆｅｔｉｍｅが２ｍｉｎ．から１２ｍｉｎ．に変更されていて、図７記載のＢｉｎｄｉｎｇ情報が３行目に新規登録され、追加されていることがわかる。尚、本実施例において、図１０のＡｖａｉｌａｂｉｌｉｔｙの項目の使い方として、Ｂｉｎｄｉｎｇを無効とするとき「×」というフラグを立てるとともに、無効時間も設定する場合について説明を行ったが、これに限るものではない。」
・・・略・・・
[0088]　以上の手順を経ることで、ＭＮ−ｂ４はＣＮ１からのコンテンツをＨＡ−ａ３経由で取得することができるようになる（ＭＮ−ａ２からＭＮ−ｂ４へのＳＨが可能になる）。
[0089]　このようにＭＮ−ａ２は実際には移動していないが、移動したように見せかけることでＭＮ−ａ２からＭＮ−ｂ４へのセッションハンドオーバを実現することが可能となる。
[0090]　また、
同じ通信相手と複数のセッションを張っていた場合、特定のセッションのみハンドオーバを行うことが可能
[0091]　尚、
本実施例においては、
切替元端末（ＭＮ−ａ２）側から切替先端末（ＭＮ−ｂ４）側へＳＨ要求を行うことも可能である。この場合、図５において、ＭＮ−ａとＭＮ−ｂとを入れ替えたシーケンス図に従って良い。
[0092]　１点目は、ＳＨ要求パケットに、ＭＮ−ａ２のＭＡＣアドレスを入れる必要があることと、事前にＭＮ−ｂ４にＭＡＣアドレスを登録しておく必要があることである。これは、ＭＮ−ｂ４でＳＨ要求パケットを受信した後、ＭＡＣアドレス認証を行う際に必要だからである。
[0093]　２点目は、ＳＨ許可パケットの中身として、ＨｏＡ−ａではなく、ＣｏＡ−ｂを入れる必要があることである。これは、ＭＮ−ａ２側からＨＡ−ａ３にＢＵパケットを送信するために、ＢＵ要求ならびにＢＵパケットに含める情報として、ＨｏＡ−ａとＣｏＡ−ｂの情報を入れる必要があるためであり、ＣｏＡ−ｂについては、ＭＮ−ａ２のアドレスではないため、知らない場合を考慮し、取得することとしている。」
「図５」
「図６」
「図７」
「図８」
（イ）上記記載によれば、用語と略称との対応関係は次のとおりである。
　ＨＡはホームエージェントの略称（上記［0039］）、ＨｏＡはホームアドレスの略称（上記［0039］）、ＳＨは異なる２つの端末間での切替えによる通信（セッションハンドオーバ）の略称（上記［0038］）、ＢＵはバインディング更新（アップデート）の略称（上記［0039］）、ＭＮは端末の略称（上記［0039］）、ＣｏＡは気付けアドレスの略称（上記［0012］）、ＣＮは対向ノードの略称（上記［0014］）。
　上記［0091］には、実施例１について、切替元端末（ＭＮ−ａ）側から切替先端末（ＭＮ−ｂ）側へＳＨ要求を行うことも可能であって、図５においてＭＮ−ａとＭＮ−ｂとを入れ替えたシーケンス図に従ってもよい旨の記載があるから、上記［図５］においてＭＮ−ａとＭＮ−ｂとを入れ替えることで、切替元端末（ＭＮ−ａ）側から切替先端末（ＭＮ−ｂ）側へＳＨ要求を行い、切替先端末（ＭＮ−ｂ）側から切替元端末（ＭＮ−ａ）側へＳＨ許可を行い、切替元端末（ＭＮ−ａ）側からＨＡ−ａにＢＵを行うものについて、以下検討を進める。
　上記［0001］によれば、引用例１はモバイルＩＰ技術を利用した端末間のＳＨに関し、上記［0062］〜［0093］にある実施例１には、ＭＮ−ａからＭＮ−ｂへのＳＨの過程が記載されている。そして、上記［0090］によれば、当該ＳＨでは、同じ通信相手と複数のセッションを張っていた場合、特定のセッションのみハンドオーバを行うことが可能であるから、「モバイルＩＰ技術を利用した、ＭＮ−ａからＭＮ−ｂへ、複数のセッションの中から特定のセッションをハンドオーバする方法」が記載されているといえる。
　上記［0064］によれば、ＳＨ実施前において、ＭＮ−ａはＨＡ−ａを経由してＣＮからコンテンツを受信している。
　また、上記［0073］によれば、Ｂｉｎｄｉｎｇが更新される前段階では、ＨＡ−ａには、図６に示されるＢｉｎｄｉｎｇが登録されており、ＨｏＡ−ａ宛のパケットがＣｏＡ−ａ宛に転送される。ここで、ＣｏＡ−ａは、ＭＮ−ａの気付けアドレス（上記［0063］）であるから、転送された当該パケットはＭＮ−ａが受信する。
　そして、Ｂｉｎｄｉｎｇの登録について、上記［0012］〜［0014］によれば、ＭＮはＨＡに対してＢＵを行い、これによって、ＨＡはＭＮのＢＵを受信するとＭＮに関するＨｏＡとＣｏＡの対を登録することが記載されており、ＢｉｎｄｉｎｇはＨｏＡとＣｏＡとの対応付けを表すとあるから、登録されるＨｏＡとＣｏＡの対とはＢｉｎｄｉｎｇの情報のことである。また、上記［0069］によれば、ＢＵを行うとは、ＢＵパケットを送信することであり、上記[図６]によれば、更新される前段階で登録されているＢｉｎｄｉｎｇは、ＨｏＡ、ＣｏＡ、通信相手のＩＰアドレス、ポート番号等から成ることが見て取れる。
　そうすると、「Ｂｉｎｄｉｎｇが更新される前段階において、ＭＮ−ａによって、ＨＡ−ａに対してＢＵパケットを送信することでＢＵを行うことであって、これによってＨＡにＨｏＡ、ＣｏＡ、通信相手のＩＰアドレス、ポート番号を含むＢｉｎｄｉｎｇが登録され、ＣＮからのＨｏＡ−ａ宛のパケットがＣｏＡ−ａ宛に転送され」るものといえる。
　上記［0065］及び［図５］には、ＳＨ要求において、「ＭＮ−ｂによって、ＳＨ要求パケットをＭＮ−ａへ送信する」こと、及び、「ＳＨ要求パケットはＳＨを依頼する旨が記されている情報を含んでいる」ことが記載されている。
　そして、上記［0091］を踏まえると、当該記載から「ＭＮ−ａによって、ＳＨ要求パケットをＭＮ−ｂへ送信する」こと、及び、「ＳＨ要求パケットはＳＨを依頼する旨が記されている情報を含んでいる」ことが把握できる。
　上記［0067］、［0068］及び［図５］によれば、ＳＨ許可において、ＭＮ−ａのＳＨ通信手段がＳＨ許可をＭＮ−ｂに対して送信し、このパケットには、ＭＮ−ａからＭＮ−ｂへのＳＨを認める旨が記された情報が含まれている。そして、ＭＮ−ａからのＳＨ許可パケットをＭＮ−ｂが受信する。
　そうすると、ＳＨ許可において、「ＭＮ−ｂによって、ＭＮ−ａがＳＨを認める旨が記された情報を含むＳＨ許可パケットを、ＭＮ−ａから受信」することが記載されているといえる。
　そして、上記［0091］を踏まえると、当該記載から、「ＭＮ−ａによって、ＭＮ−ｂがＳＨを認める旨が記された情報を含むＳＨ許可パケットを、ＭＮ−ｂから受信」することが把握できる。
　上記［0068］〜［0070］及び［図５］によれば、ＳＨ許可パケットを受信したＭＮ−ｂのＳＨ管理部は自身のＭｏｂｉｌｅ　ＩＰ管理部に対してＢＵ更新を行い、ＢＵ更新を受け取ったＭＮ−ｂのＭｏｂｉｌｅ　ＩＰ管理部はＨＡ−ａに対してＢＵパケットを送信する。
　そして、ＢＵパケットの内容として、ＨＡ−ａに登録を要求するＢｉｎｄｉｎｇの情報を記載したＢｉｎｄｉｎｇ情報及びＨＡ−ａにおいてＢｉｎｄｉｎｇを更新する際に検索キーとして利用するためのセッション情報が含まれており、上記［図７］によれば、Ｂｉｎｄｉｎｇ情報は、「ＨｏＡ、ＣｏＡ、通信相手のＩＰアドレス、ポート番号等」から成り、上記［図８］によれば、セッション情報は、「ＨｏＡ、ＣｏＡ、通信相手のＩＰアドレス及びポート番号」から成ることが見て取れる。また、上記［図７］によれば、Ｂｉｎｄｉｎｇ情報のＣｏＡ欄に「ＣｏＡ−ｂ」が含まれていることが見て取れるので、ＨｏＡ−ａへのパケットがＣｏＡ−ｂに転送される設定がされていることが把握できる。ここで、ＣｏＡ−ｂはＭＮ−ｂの気付けアドレス（上記［0063］）であるから、転送された当該パケットはＭＮ−ｂに転送される。
　そうすると、ＨＡ−ａへのＢＵにおいて、「ＳＨ許可パケットを受信すると、ＭＮ−ｂはＨＡ−ａへＢＵパケットを送信する」こと、このＢＵにより、ＢＵパケットに含まれるセッション情報を検索キーとして、登録されたＢｉｎｄｉｎｇが、ＢＵパケットに含まれるＢｉｎｄｉｎｇ情報で更新され、ＨｏＡ−ａへのパケットが、当該Ｂｉｎｄｉｎｇ情報に含まれるＣｏＡ−ｂをその気付けアドレスとするＭＮ−ｂに転送されることが把握できる。
　そして、上記［0091］を踏まえて、ＭＮ−ａとＭＮ−ｂとを入れ換えた場合には、「ＳＨ許可パケットを受信すると、ＭＮ−ａはＨＡ−ａへＢＵパケットを送信する」こと、「ＢＵパケットの内容として、ＨＡ−ａに登録を要求するＢｉｎｄｉｎｇの情報を記載したＢｉｎｄｉｎｇ情報及びＨＡ−ａにおいてＢｉｎｄｉｎｇを更新する際に検索キーとして利用するためのセッション情報が含まれており」、「セッション情報はＨｏＡ、ＣｏＡ、通信相手のＩＰアドレス及びポート番号から成り、Ｂｉｎｄｉｎｇ情報はＨｏＡ、ＣｏＡ、通信相手のＩＰアドレス、ポート番号を含」むこと、「このＢＵにより、ＢＵパケットに含まれるセッション情報を検索キーとして、登録されたＢｉｎｄｉｎｇが、ＢＵパケットに含まれるＢｉｎｄｉｎｇ情報で更新され、ＨｏＡ−ａへのパケットが、当該Ｂｉｎｄｉｎｇ情報に含まれるＣｏＡ−ｂをその気付けアドレスとするＭＮ−ｂに転送される」ことが把握できる。
（ウ）上記（ア）及び（イ）から、引用例１には、次の発明（以下、「引用発明」という。）が記載されていると認められる。
「モバイルＩＰ技術を利用した、ＭＮ−ａからＭＮ−ｂへ、複数のセッションの中から特定のセッションをハンドオーバする方法において、
　Ｂｉｎｄｉｎｇが更新される前段階において、ＭＮ−ａによって、ＨＡ−ａに対してＢＵパケットを送信することでＢＵを行うことであって、これによってＨＡにＨｏＡ、ＣｏＡ、通信相手のＩＰアドレス、ポート番号を含むＢｉｎｄｉｎｇが登録され、ＣＮからのＨｏＡ−ａ宛のパケットがＣｏＡ−ａ宛に転送され、
　ＭＮ−ａによって、ＳＨ要求パケットをＭＮ−ｂへ送信することであって、ＳＨ要求パケットはＳＨを依頼する旨が記されている情報を含み、
　ＭＮ−ａによって、ＭＮ−ｂがＳＨを認める旨が記された情報を含むＳＨ許可パケットを、ＭＮ−ｂから受信することと、
　ＳＨ許可パケットを受信すると、ＭＮ−ａはＨＡ−ａへＢＵパケットを送信することであって、ＢＵパケットの内容として、ＨＡ−ａに登録を要求するＢｉｎｄｉｎｇの情報を記載したＢｉｎｄｉｎｇ情報及びＨＡ−ａにおいてＢｉｎｄｉｎｇを更新する際に検索キーとして利用するためのセッション情報が含まれており、セッション情報はＨｏＡ、ＣｏＡ、通信相手のＩＰアドレス及びポート番号から成り、Ｂｉｎｄｉｎｇ情報はＨｏＡ、ＣｏＡ、通信相手のＩＰアドレス、ポート番号を含み、このＢＵにより、ＢＵパケットに含まれるセッション情報を検索キーとして、登録されたＢｉｎｄｉｎｇが、ＢＵパケットに含まれるＢｉｎｄｉｎｇ情報で更新され、ＨｏＡ−ａへのパケットが、当該Ｂｉｎｄｉｎｇ情報に含まれるＣｏＡ−ｂをその気付けアドレスとするＭＮ−ｂに転送される、方法。」
イ　引用例２の記載事項及び周知事項
（ア）原査定の拒絶理由で引用された、SOLIMAN他，FLOW BINDINGS IN MOBILE IPV6 AND NEMO BASIC SUPPORT; DRAFT-IETF-MEXT-FLOW-BINDING-06.TXT，IETF STANDARD-WORKING-DRAFT，掲載日２０１０年　３月　１日，ＵＲＬ：https://tools.ietf.org/html/draft-ietf-mext-flow-binding-06（以下、「引用例２」という。）には、次の記載がある。
「Abstract
This document introduces extensions to Mobile IPv6 that allow nodes to bind one or more flows to a care-of address.
（当審訳）
「要約
この文書は、ノードが気付けアドレスに１又は複数のフローをバインドすることを可能とするモバイルＩＰｖ６の拡張を導入するものである。
「3. Terminology
Terms used in this document are defined in [RFC3753] and [RFC4885]. The following terms are also used in this document:
Flow: A flow is a sequence of packets
Traffic Selector: One or more parameters that can be matched against fields in the packet's headers for the purpose of classifying a packet. Examples of such parameters include the source and destination IP addresses, transport protocol number, the source and destination port numbers and other fields in IP and higher layer headers.
Flow binding: It consists of a traffic selector
. IP packets from one or more flows that match the traffic selector associated with the flow binding,
Flow Identifier: A flow identifier uniquely identifies a flow binding
（当審訳）
「３．用語
この文書で用いられる用語は、［ＲＦＣ３７５３］及び［ＲＦＣ４８８５］に定義される。同様に、この文書において、次の用語も用いられる。
フロー：フローとは、
一連のパケットである。
トラフィックセレクタ：パケットを分類するためにパケットのヘッダ内のフィールドに対してマッチングされる１つまたは複数のパラメータである。そのようなパラメータの例は、ソース及び宛先ＩＰアドレス、トランスポートプロトコル番号、ソース及び宛先ポート番号、並びに、ＩＰ及びそれより高いレイヤのヘッダ内の他のフィールドなどを含む。
フローバインディング：フローバインディングはトラフィックセレクタ
から成る。フローバインディングに関連付けられたトラフィックセレクタに一致する１つ又は複数のフローからのＩＰパケット
フロー識別子：フロー識別子は
フローバインディングを一意的に識別する。
（イ）上記記載によれば、引用例２は、ノードがフローを気付けアドレスにバインド可能とするモバイルＩＰｖ６に関するもの（第１頁）である。
　そして、フロー識別子は、フローバインディングを一意的に識別するものであって、フローバインディングはトラフィックセレクタを含み、当該トラフィックセレクタに一致するパケットを選択するもの（第７頁）である。
　そうすると、フロー識別子は、フローバインディングを識別することによって、フローバインディングに関連付けられたトラフィックセレクタに一致するパケットからなるフローを一意的に識別する、フローに関連付けられた識別子といえる。
　加えて、引用例２はモバイルＩＰｖ６の規格についての提案であって当業者に周知のものであるから、引用例２には次の周知事項が記載されているといえる。
「フローバインディングを識別することによってフローを一意的に識別可能な、フローに関連付けられた、モバイルＩＰｖ６に関するフロー識別子。」（以下、「周知事項」という。）
（３）対比
ア　本件補正発明と引用発明とを対比する。
（ア）引用発明の「セッション」は通信におけるセッションであって、本願明細書【００６１】の記載等にもあるように、「通信セッション」を「フロー」と言い換えることができることは技術常識であるから、引用発明の「セッション」は本件補正発明の「フロー」に相当する。
　また、引用発明の「ＭＮ−ａ」、「ＭＮ−ｂ」、「ＨＡ−ａ」、「ＣＮ」、「ＢＵ」は、それぞれ本件補正発明の「第１のＷＴＲＵ」、「第２のＷＴＲＵ」、「ＨＡ」、「ノード」及び「バインディング更新」に相当する。
（イ）引用発明の「モバイルＩＰ技術を利用した、ＭＮ−ａからＭＮ−ｂへ、複数のセッションの中から特定のセッションをハンドオーバする方法」は、ＭＮ−ａからＭＮ−ｂに、複数のセッションの中から特定のセッションを転送するものといえる。そして、本件補正発明は、フロー識別子と一致する特定のフローを転送するものであるから、本件補正発明と引用発明とは、「第１の無線送受信ユニット（ＷＴＲＵ）からフローを転送する方法」である点で共通する。
（ウ）引用発明では、「Ｂｉｎｄｉｎｇが更新される前段階において、ＭＮ−ａによって、ＨＡ−ａに対してＢＵパケットを送信することでＢＵを行うこと」により、「ＨＡにＨｏＡ、ＣｏＡ、通信相手のＩＰアドレス、ポート番号を含むＢｉｎｄｉｎｇが登録され、ＣＮからのＨｏＡ−ａ宛のパケットがＣｏＡ−ａ宛に転送され」る。ここで、ＣｏＡはＭＮの気付けアドレス（上記［0063］）であるから、ＣｏＡ−ａ宛のパケットはＭＮ−ａに転送される。
　そうすると、登録されたＢｉｎｄｉｎｇに含まれるＨｏＡ、ＣｏＡ、通信相手のＩＰアドレス、ポート番号の各々は、通信トラフィック上のパケットを分類してルーティングを行うためのパラメータといえ、ＨＡ−ａは、Ｂｉｎｄｉｎｇに含まれるパラメータを参照してこれに一致するパケットをＭＮ−ａに転送するといえる。
　ここで、本件補正発明の「ノードとフローを確立するステップ」においてバインディング更新に含まれるとする「トラフィックセレクタ」がどのような内容のものかは明確ではないが、本願明細書には、「トラフィックセレクタは、パケットを分類するためにパケットのヘッダ内のフィールドに対してマッチングされる１つ又は複数のパラメータである。そのようなパラメータの例は、ソースおよび／または宛先ＩＰアドレス、・・・ソースおよび宛先ポート番号・・・などを含む」（【００６４】）との記載があることも勘案すると、引用発明においてＨｏＡ−ａ宛のパケットをＣｏＡ−ａ宛に転送する際に参照される「ＨｏＡ、ＣｏＡ、通信相手のＩＰアドレス、ポート番号」等のパラメータの１つ又は複数は、本件補正発明にいう「第１のトラフィックセレクタ」に相当するといえる。
　そして、引用発明が「モバイルＩＰ技術」を利用していることも踏まえれば、引用発明では、「Ｂｉｎｄｉｎｇが更新される前段階において、ＭＮ−ａによって、ＨＡ−ａに対して」、第１のトラフィックセレクタを含む「ＢＵパケットを送信すること」によってＢＵが行われたといえ、本件補正発明において「第１のバインディング更新」がＨＡに対して送られることも自明であるから、引用発明の「ＢＵパケット」は、本件補正発明の「第１のバインディング更新」に相当し、本件補正発明と引用発明とは、「前記第１のＷＴＲＵによって、第１のトラフィックセレクタを含む第１のバインディング更新を送る」点で共通する。
（エ）引用発明は、「ＭＮ−ａによって」、「ＳＨを依頼する旨が記されている情報を含」む「ＳＨ要求パケットをＭＮ−ｂへ送信」し、「ＭＮ−ｂがＳＨを認める旨が記された情報を含むＳＨ許可パケットを、ＭＮ−ｂから受信する」ものであるところ、引用発明の「ＳＨ」はセッションをＭＮ間で切替えることによって通信するものであるから、本件補正発明の「ユニット間転送（ＩＵＴ）」に相当する。そして、本件補正発明では、「ＩＵＴ準備要求」に対して「前記第２のＷＴＲＵがＩＵＴを受け付けることを示しているＩＵＴ準備応答」が返信されることからみて、本件補正発明にいう「ＩＵＴ準備要求」が「前記第２のＷＴＲＵがＩＵＴを受け付けること」を要求するものであることは明らかであるから、引用発明の「ＳＨ要求パケット」は、本件補正発明の「ＩＵＴ準備要求」に対応するといえる。
　そうすると、本件補正発明と引用発明とは、「前記第１のＷＴＲＵによって、ユニット間転送（ＩＵＴ）準備要求を第２のＷＴＲＵへ送るステップ」を備える点で共通する。
　また、引用発明の「ＳＨ許可パケット」は、本件補正発明の「ＩＵＴ準備応答」に相当し、引用発明の「ＭＮ−ａによって、ＭＮ−ｂがＳＨを認める旨が記された情報を含むＳＨ許可パケットを、ＭＮ−ｂから受信する」ことは、本件補正発明の「前記第１のＷＴＲＵによって、前記第２のＷＴＲＵがＩＵＴを受け付けることを示しているＩＵＴ準備応答を、前記第２のＷＴＲＵから受信するステップ」に相当する。
（オ）引用発明では、「ＳＨ許可パケットを受信すると」「ＭＮ−ａはＨＡ−ａへＢＵパケットを送信」し、「このＢＵにより、ＢＵパケットに含まれるセッション情報を検索キーとして、登録されたＢｉｎｄｉｎｇが、ＢＵパケットに含まれるＢｉｎｄｉｎｇ情報で更新され、ＨｏＡ−ａへのパケットが、当該Ｂｉｎｄｉｎｇ情報に含まれるＣｏＡ−ｂをその気付けアドレスとするＭＮ−ｂに転送される」。
　そして、引用発明において、ＨｏＡ−ａ宛のパケットをＣｏＡ−ｂ宛に転送する際に参照される、Ｂｉｎｄｉｎｇ情報に含まれる「ＨｏＡ、ＣｏＡ、通信相手のＩＰアドレス、ポート番号」等のパラメータの１つ又は複数は、上記（ウ）で判断したのと同様に、本件補正発明の「前記フローに属するパケットを前記第２のＷＴＲＵへルーティングする第２のトラフィックセレクタ」に相当する。
　また、引用発明の、ＳＨ許可パケットを受信するとＨＡ−ａへ送信される「ＢＵパケット」は、本件補正発明にいう「第２のバインディング更新」に対応し、本件補正発明と引用発明とは、「前記受信されたＩＵＴ準備応答に基づいて、ＨＡへ第２のバインディング更新を送るステップであって、前記第２のバインディング更新は、前記フローに属するパケットを前記第２のＷＴＲＵへルーティングする第２のトラフィックセレクタを含む、ステップ」を備える点で共通する。
イ　以上のことから、本件補正発明と引用発明との一致点及び相違点は、次のとおりである。
［一致点］
「第１の無線送受信ユニット（ＷＴＲＵ）からフローを転送する方法において、
　前記第１のＷＴＲＵによって、第１のトラフィックセレクタを含む第１のバインディング更新を送るステップと、
　前記第１のＷＴＲＵによって、ユニット間転送（ＩＵＴ）準備要求を第２のＷＴＲＵへ送るステップと、
　前記第１のＷＴＲＵによって、前記第２のＷＴＲＵがＩＵＴを受け付けることを示しているＩＵＴ準備応答を、前記第２のＷＴＲＵから受信するステップと、
　前記受信されたＩＵＴ準備応答に基づいて、ＨＡへ第２のバインディング更新を送るステップであって、前記第２のバインディング更新は、前記フローに属するパケットを前記第２のＷＴＲＵへルーティングする第２のトラフィックセレクタを含む、ステップと、
　を備えることを特徴とする方法。」
［相違点１］
　第１のバインディング更新を送るステップが、本件補正発明では、第１のバインディング更新を送ることによって「前記フローが確立され」る、「ノードと前記フローを確立するステップ」であるのに対し、引用発明では、これについて特定がない点。
［相違点２］
　本件補正発明では、「前記フローは、複数のフローの中で前記フローを一意的に識別している関連付けられたフロー識別子を有して」おり、第２のバインディング更新に当該「フロー識別子」が含まれるのに対し、引用発明ではこれらについて特定がない点。
［相違点３］
　本件補正発明では、ＩＵＴ準備要求が「フローに関連付けられた情報」を含んでいるのに対し、引用発明ではこれについて特定がない点。
（４）判断
　以下、相違点について検討する。
ア　相違点１について
　引用発明の「Ｂｉｎｄｉｎｇが更新される前段階において、ＭＮ−ａによって、ＨＡ−ａに対してＢＵパケットを送信することでＢＵを行うことであって、これによってＨＡにＨｏＡ、ＣｏＡ、通信相手のＩＰアドレス、ポート番号を含むＢｉｎｄｉｎｇが登録され、ＣＮからのＨｏＡ−ａ宛のパケットがＣｏＡ−ａ宛に転送され、」との事項において、上記Ｂｉｎｄｉｎｇの登録がされることにより、ＣＮ（本件補正発明の「ノード」に相当。）とＣｏＡ−ａ（本件補正発明の「第１のＷＴＲＵ」に相当。）との間でＨｏＡ−ａ（本件補正発明の「ＨＡ」に相当。）を介したフローが確立されることは明らかであるから、ＭＮ−ａによりＣＮとのフローを確立するための前記事項における「ＭＮ−ａによって、ＨＡ−ａに対してＢＵパケットを送信することでＢＵを行う」処理を、ノードに相当するＣＮとフローを確立するステップとして、また当該処理によりフローが確立されるステップとして実施することは当業者が適宜なし得る事項といえる。
イ　相違点２について
　引用発明の「セッション情報」は、更新対象となるセッションに対応するＢｉｎｄｉｎｇをＢＵパケットに含まれるＢｉｎｄｉｎｇ情報で更新するために、当該更新対象となるセッションの検索キーとして用いるものであるから、複数のセッションの中で更新対象となるセッションを一意的に識別（本件補正発明にいう「複数のフローの中で前記フローを一意的に識別」に相当。）するものといえる。そして、引用発明では、ＳＨ許可を受けて送信されるＢＵパケットに上記「セッション情報」を含めることで、転送するフローを一意的に識別している。
　そして、引用発明において、更新対象となるセッションを一意的に識別する「セッション情報」として、上記周知事項である「フローバインディングを識別することによってフローを一意的に識別可能な、フローに関連付けられた、モバイルＩＰｖ６に関するフロー識別子」（上記「（２）イ（イ）」参照）を採用し、ＳＨ許可を受けて送信されるＢＵパケット（本件補正発明の「第２のバインディング更新」に対応。）に当該フロー識別子を含めることは、当業者が容易に想到し得ることである。
ウ　相違点３について
　引用発明は、「複数のセッションの中から特定のセッションをハンドオーバする方法」であって、ＢＵパケットを送信する前に、ＳＨ先のＭＮ−ｂに「ＳＨ依頼する旨が記載されている情報」を含む「ＳＨ要求パケット」を送信し、当該ＳＨを認めるか否かの判断を促すものである。
　そうすると、ＳＨ先のＭＮ−ｂが特定のセッションのＳＨを認めるか否かの判断を行う際にＳＨに係るセッションを特定できるように、ＳＨ要求パケットに、当該ＳＨに係るセッションに関連付けられた情報を含めることは当業者が容易に想到し得ることである。
エ　作用効果について
　そして、上記相違点１〜３を総合的に勘案しても、本件補正発明の奏する作用効果は、引用発明及び周知事項の奏する作用効果から予測される範囲内のものに過ぎず、格別顕著なものということはできない。
（５）小括
　以上のとおり、本件補正発明は、引用発明及び周知事項に基づいて当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により、特許出願の際独立して特許を受けることができるものでない。
３　まとめ
　よって、特許法第１７条の２第６項において準用する同法第１２６条第７項の規定に違反するから、本件補正は、同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
第３　本願発明について
１　本願発明
　平成２９年２月６日にされた手続補正は上記のとおり却下されたので、本願の請求項１に係る発明は、上記「第２」の「１」にある「本願発明」のとおりのものと認める。
２　引用発明等
　引用発明及び周知事項は，上記「第２」の「２（２）」で認定したとおりである。
３　対比・判断
　本願発明は、本件補正発明の「・・・確立するステップ」、「・・・送るステップ」、「・・・受信するステップ」を実行する主体の限定を省き、「フロー」、「ＩＵＴ準備要求」及び「第２のバインディング更新」についてフロー識別子及びフローに関連付けられた情報に関する限定を省いたものであって、他の構成は同じである。
　そうすると、上記「第２」の「２（３）」〜「２（５）」での検討のとおり、本願発明に上記発明特定事項を付加した本件補正発明は、引用発明及び周知事項に基づいて当業者が容易に発明し得たものであるから、本願発明も同様の理由により当業者が容易に発明できたものである。
４　むすび
　以上のとおり、本願発明は、引用発明及び周知事項に基づいて当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により、特許を受けることができない。
　よって、結論のとおり審決する。