【事件の表示】
　特願２０１４−　９２４４５「ハンドオーバ処理」拒絶査定不服審判事件〔平成２６年　８月２８日出願公開，特開２０１４−１５８２９３〕について，次のとおり審決する。
【結　論】
　本件審判の請求は，成り立たない。
【理　由】
第１　手続の経緯
　本願は，２００８年４月３０日（パリ条約による優先権主張外国庁受理　２００７年５月１日　グレートブリテン及び北アイルランド連合王国）を国際出願日とする出願である特願２００９−５４５７５６号の一部を，平成２４年５月３１日に新たな特許出願とした特願２０１２−１２４９７１号の一部を，平成２６年４月２８日に新たな特許出願としたものであって，平成２７年１月２６日付けで拒絶理由が通知され，同年４月１日に手続補正がなされるとともに意見書が提出され，同年８月４日付けで拒絶査定がなされ，これに対し，同年１１月９日に拒絶査定不服審判が請求され，その後，当審より，平成２８年６月２９日付けで拒絶理由（以下，「当審拒絶理由」という。）が通知され，これに対し，同年８月２６日付けで手続補正がなされるとともに意見書が提出されたものである。
第２　本願発明
　本願の請求項１ないし９に係る発明は，平成２８年８月２６日付けの手続補正で補正された特許請求の範囲の請求項１ないし９に記載された事項により特定されるものと認められる。
　そして，本願の請求項８に係る発明（以下，「本願発明」という。）は以下のとおりである。
「　ソース基地局における通信制御方法であって，
　少なくとも１つのPDCPシーケンス番号(Packet Data Convergence Protocol Sequence Number)を含む状態報告を，データ送信を中止した後に，生成し，
　ハンドオーバ中に，前記状態報告を，ターゲット基地局へ送信し，
　前記状態報告を送信した後に，前記ターゲット基地局へデータを転送する通信制御方法。」
（特許請求の範囲の請求項１に記載の「送信する生成手段」は，「生成する生成手段」の誤記の可能性があり，発明が不明確であるため，請求項８に係る発明を「本願発明」と認定した。）。
第３　当審拒絶理由
　当審拒絶理由の概要は，次のとおりである。
「　　　　　　　　　　　　　　　　理　由
＜出願日の遡及について＞
　本願は特願２００９−５４５７５６号（優先日：平成１９年５月１日。以下，「原出願」という。）の分割出願である。
　本願特許請求の範囲の各項は，「ソース基地局において，少なくとも１つのPDCPシーケンス番号(Packet Data Convergence Protocol Sequence Number)を含む状態報告を生成し，ハンドオーバ中に，前記状態報告を，ターゲット基地局へ送信する」との技術事項（以下，「本願技術事項」という。）を含むが，下記Ａに詳述するように，上記本願技術事項は本願の発明の詳細な説明に記載されていない。また，図面にも記載されていない。
　そして，原出願の出願当初の明細書，特許請求の範囲又は図面（以下，「明細書等」という。）は本願請求項に対応した記載がない点を除き本願の明細書等と同じであるところ，上記本願技術事項は原出願の明細書等に記載されていないことは明らかである。
　したがって，本願の特許請求の範囲に記載された上記本願技術事項は原出願の明細書等に記載された事項の範囲内ではないため，分割の実体的要件を満たさないから，出願日の遡及を認めることができず，本願の出願日は現実の出願日である平成２６年４月２８日と認める。
Ａ　本件出願は，特許請求の範囲の記載が下記の点で不備のため，特許法第３６条第６項第１号に規定する要件を満たしていない。
　　　　　　　　　　　　　　　　記
　本願技術事項（「ソース基地局において，少なくとも１つのPDCPシーケンス番号(Packet Data Convergence Protocol Sequence Number)を含む状態報告を生成し，ハンドオーバ中に，前記状態報告を，ターゲット基地局へ送信する」こと）は，本願の発明の詳細な説明に記載されていない。
１　本願明細書の記載箇所について
　ソース基地局からターゲット基地局へ送信される情報に関して，本願明細書と図面には，【図６】の７ｄに「ソースｅＮｏｄｅＢがターゲットｅＮｏｄｅＢにパケットを転送し始める」と記載され，また，該７ｄのステップに関して【００２９】に「ｄ．両方向において，ユーザプレーンデータ送信が中止され，アップリンク及びダウンリンクの両方において状態パケットが交換されるので，ソースｅＮｏｄｅＢは，ソースｅＮｏｄｅＢとターゲットｅＮｏｄｅＢとの間でデータ伝送状態を正確に同期させることができるようになり，この後の任意の時点から，ＳＤＵ転送（ソースｅＮｏｄｅＢからターゲットｅＮｏｄｅＢへ）を開始することができる。」と記載されているように，「ＳＤＵ転送」が記載されているのみである。
　しかしながら，本願請求項１に「前記状態報告を送信した後に，前記ターゲット基地局へデータを転送するソース基地局」と記載されているように，上記「ＳＤＵ転送」が，本願技術事項の「状態報告」ではなく，該状態報告をターゲット基地局へ送信した後の「データ」の「転送」を指すことは明らかである。
　また，上記「ＳＤＵ転送」によりソース基地局とターゲット基地局との間のデータ伝送状態を正確に同期させることができる以上，「ＳＤＵ転送」とは別個の「状態報告」をソース基地局からターゲットに送信する必然性はないから，上記本願技術事項は発明の詳細な説明から自明に導き出せる事項でもない。
　したがって，上記本願技術事項は本願の発明の詳細な説明に記載されていない。
２　平成２７年４月１日に提出された意見書における請求人の主張について
　平成２７年４月１日に提出された意見書における請求人の主張は，要するに，本願明細書の【００２７】，【００２９】，【００３９】等の記載によれば，アップリンク及びダウンリンクの両方向で交換されるＰＤＣＰシーケンス番号を含む状態パケットがソースｅＮｏｄｅＢとターゲットｅＮｏｄｅＢとの間でデータ伝送状態を正確に同期させるために使用されていること，及び，そのような同期をとるためには，ソースｅＮｏｄｅＢからターゲットｅＮｏｄｅＢにＰＤＣＰシーケンス番号を含む状態パケットが伝送されなければならないこと，を明確に記載しているというものである。
　確かに，ＵＥとソースｅＮｏｄｅＢ間で「状態パケット」が交換されるとともにＤＬ送信とＵＬ送信が中止されることで，ソースｅＮｏｄｅＢにおいてＤＬとＵＬで送信済みのＰＤＣＰ　ＳＤＵが確定し，その結果，ソースｅＮｏｄｅＢはターゲットｅＮｏｄｅＢに「ＳＤＵ転送」を行うだけで両者の間でデータ伝送状態を正確に同期させることができるようになっている。その意味で，請求人の主張する「アップリンク及びダウンリンクの両方向で交換されるＰＤＣＰシーケンス番号を含む状態パケットがソースｅＮｏｄｅＢとターゲットｅＮｏｄｅＢとの間でデータ伝送状態を正確に同期させるために使用されている」点は一応は首肯できるものである。
　しかしながら，該主張における「状態パケット」はＵＥとソースｅＮｏｄｅＢとの間で交換されるものであるから，本願技術事項の「ソース基地局」から「ターゲット基地局」へ「送信」される「状態報告」ではあり得ない。そして，上述のとおり，その後の「ＳＤＵ転送」によりソースｅＮｏｄｅＢとターゲットｅＮｏｄｅＢはデータ伝送状態を正確に同期させることができるのであるが，該「ＳＤＵ転送」は上記「１」に述べたとおり，本願技術事項の「状態報告」ではない。
　また，上記「ＳＤＵ転送」によりソース基地局とターゲット基地局との間のデータ伝送状態を正確に同期させることができる以上，これとは別の「状態報告」をソース基地局からターゲット基地局に送信する必然性はないから，上記本願技術事項は発明の詳細な説明から自明に導き出せる事項でもない。
　したがって，上記請求人の主張は採用することはできず，上記本願技術事項が本願の発明の詳細な説明に記載されているということはできない。
　
３　小括
　以上のとおりであるから，従属項も含め，本願請求項１〜９は本願の明細書に記載されたものではない。
（以下省略）」
　そうすると，当審拒絶理由の趣旨は，「ソース基地局」において，「少なくとも１つのPDCPシーケンス番号(Packet Data Convergence Protocol Sequence Number)を含む状態報告」を「生成」し，「ハンドオーバ中に，前記状態報告を，ターゲット基地局へ送信」するという，本願発明に係る構成（以下，この構成を「本願発明構成」という。）は，発明の詳細な説明に記載したものではないので，本願発明は，特許法第３６条第６項第１号に規定する要件を満たしていないから，特許を受けることができない，というものである。
第４　当審拒絶理由の判断
　以下，当審拒絶理由の判断の妥当性について検討する。
　なお，当審拒絶理由においては，＜出願日の遡及について＞の欄において，出願日の遡及を認めない旨認定しているが，当該認定は確定したものではないので，以降では，出願日の遡及が認められるという前提の下で検討を行う。
（１）発明の詳細な説明及び図面に記載された事項
　本願の発明の詳細な説明及び図面には，本願発明構成に関連する，「ハンドオーバ」，「基地局」及び「状態報告」に関し，次のような記載がある。
ａ．「　【０００１】
　本発明は，移動通信ネットワーク，限定はしないが，特に３ＧＰＰ標準規格，又はその等価物若しくは派生物に従って動作するネットワークにおけるデータパケットの管理に関する。
【背景技術】
　【０００２】
　移動通信ネットワークでは，ユーザ装置（ＵＥ）が基地局間でハンドオーバすることを要求される。３ＧＰＰでは，最近になって，ソースｅＮｏｄｅＢ（基地局）からターゲットｅＮｏｄｅＢへのハンドオーバ（ＨＯ）のために制御プレーン（Ｃプレーン）において規定される手順が提案されている。当然，当業者には，３Ｇ通信に適用することができる種々の頭字語がよく知られているが，一般読者の便宜を図るために，用語集が添付される。
　【０００３】
　当業者が効率よく理解できるようにするために，本発明を３Ｇシステムとの関連で詳細に説明するが，それらのハンドオーバの原理は，他のシステム，たとえば，必要に応じてシステムの対応する構成要素を変更しながら，移動デバイス又はユーザ装置（ＵＥ）がいくつかの他のデバイス（ｅＮｏｄｅＢに対応する）のうちの１つと通信する他のＣＤＭＡ又は無線システムにも適用することができる。」
ｂ．「【発明の概要】
　【０００６】
　本発明の一態様によれば，ソース基地局であって，
少なくともPDCPシーケンス番号(Packet Data Convergence Protocol Sequence Number)を含む状態報告を生成する生成手段と，
ハンドオーバ中に，前記状態報告を，ターゲット基地局へ送信する送信手段を有し，
前記送信手段は，前記状態報告を送信した後に，前記ターゲット基地局へデータを転送するソース基地局が得られる。
　本発明の別の態様によれば，ソース基地局における通信制御方法であって，
少なくともPDCPシーケンス番号(Packet Data Convergence Protocol Sequence Number)を含む状態報告を生成し，
ハンドオーバ中に，前記状態報告を，ターゲット基地局へ送信し，
前記状態報告を送信した後に，前記ターゲット基地局へデータを転送する通信制御方法及びコンピュータプログラムが得られる。（以下省略）」
ｃ．「　【００１３】
　本発明は，理解するのを容易にするために，３Ｇ　ｅＮｏｄｅＢ間でのハンドオーバとの関連で説明されるが，それらの原理は，異なるネットワークのノード間，たとえば，３Ｇネットワークのノードと別のネットワークのノードとの間のハンドオーバにも拡張することができる。」
ｄ．「　【００１６】
概説
　図１は，移動（セルラー）通信システム１を概略的に示している。該システムにおいて，移動電話（ＭＴ）３−０，３−１及び３−２のユーザが，基地局５−１又は５−２のうちの１つ及び電話網７を介して，他のユーザ（図示せず）と通信することができる。この実施形態では，基地局５は，直交周波数分割多元接続（ＯＦＤＭＡ）技法を使用しており，移動電話３に送信されることになるデータは複数のサブキャリア上に変調される。移動電話３に送信されることになるデータの量に応じて，各移動電話３に異なるサブキャリアが割り当てられる。移動電話３がソース基地局（たとえば，基地局５−１）のセルからターゲット基地局（たとえば，基地局５−２）に移動するとき，ソース基地局５及びターゲット基地局５，並びに移動電話３においてハンドオーバ（ＨＯ）手順（プロトコル）が実行され，ハンドオーバプロセスが制御される。
　【００１７】
　そのハンドオーバプロセスは，以下の要件を伴う，ソース基地局５とターゲット基地局５との間の最適なハードハンドオーバ（ＨＨＯ）を提供することを目指す。
　１．高いＴＣＰスループット性能を達成する，非リアルタイム（ＮＲＴ）サービスのためのロスレスＨＨＯ。
　２．終端間でアプリケーションの良好な性能を確保するために，パケットロスを最小限に抑える，リアルタイム（ＲＴ）サービスのためのシームレスＨＨＯ。
　３．無線インタフェースを介しての重複パケット送信の最小化。
　４．ユーザプレーンデータのための最低限の中断時間。
　５．ＨＯ中に，ＮＡＳ（非アクセス階層）ＰＤＵの順次送達が保持されるべきである。
　６．重複送達及び非順次送達は，ＲＯＨＣ（ロバストヘッダ圧縮）及びアプリケーションには一切見えないようにすべきである。
　【００１８】
　ハードハンドオーバは，ソフトハンドオーバとは対照的に，ハンドオーバ中に移動電話と基地局との間の無線伝送に中断があるハンドオーバであり，移動電話は，ハンドオーバ手順中に，ソース基地局及びターゲット基地局の両方と無線リンクを確立する。それゆえ，パケットロス及びパケット再送を最小限に抑えながら，ハードハンドオーバを実行するのがさらに難しいことは，当業者には理解されよう。」
（当審注：【００１８】の記載のうち「
ハードハンドオーバは
ソース基地局及びターゲット基地局の両方と無線リンクを確立する
ｅ．「　【００１９】
基地局
　図２は，この実施形態において用いられる基地局５のそれぞれの主な構成要素を例示するブロック図である。図に示されるように，各基地局５はトランシーバ回路２１を備えており，該トランシーバ回路は，１つ又は複数のアンテナ２３を介して移動端末３に対し信号を送受信するように動作することができ（上述したサブキャリアを用いる），且つネットワークインタフェース２５を介して電話網７に対し信号を送受信するように動作することができる。コントローラ２７が，メモリ２９に格納されるソフトウエアに従って，トランシーバ回路２１の動作を制御する。そのソフトウエアは，中でも，オペレーティングシステム３１及びダウンリンクスケジューラ３３を含む。ダウンリンクスケジューラ３３は，移動端末３と通信する際に，トランシーバ回路２１によって送信されることになるユーザデータパケットをスケジューリングするように動作することができる。また，そのソフトウエアはハンドオーバモジュール３５も備えており，その動作は以下で説明される。」
ｆ．「　【００２２】
動作
　以下の説明は，ＵＴＲＡＮのロングタームエボリューション（ＬＴＥ）において用いられる用語を使用する。それゆえ，基地局を切り替えつつある移動電話３はＵＥと呼ばれ，ソース基地局５−１はソースｅＮｏｄｅＢ（又は単にｅＮＢ）と呼ばれ，ターゲット基地局５−２は，ターゲットｅＮｏｄｅＢと呼ばれる。ＬＴＥにおいて用いられるプロトコルエンティティは，ＬＴＥの下で外部ＡＲＱエンティティと呼ばれる無線リンク制御（ＲＬＣ）エンティティを除いて，ＵＭＴＳにおいて用いられるプロトコルエンティティと同じ名称である。ＬＴＥの外部ＡＲＱエンティティは，ＵＭＴＳのＲＬＣエンティティと（全く同一ではないが）概ね同じ機能を有する。」
ｇ．「　【００２３】
　図４は，ＵＥ及びｅＮｏｄｅＢにおいて用いられるプロトコルスタックの一部（下位の３つの層）を示す。最初の層は物理層（Ｌ１）であり，無線通信チャネルを介してデータを実際に送信するための役割を担う。その上には第２の層（Ｌ２）があり，Ｌ２は３つの副層，すなわち，無線インタフェースへのアクセスを制御するための役割を担う媒体アクセス制御層（Ｌ２／ＭＡＣ）と，必要に応じて，データパケットの連結及びセグメント化，パケットの応答，及びデータパケットの再送のための役割を担う外部ＡＲＱ（自動再送要求）層（Ｌ２／ＯＡＲＱ）と，ヘッダ圧縮及び暗号化のための役割を担うＰＤＣＰ（パケットデータコンバージェンスプロトコル）層（Ｌ２／ＰＤＣＰ）とに分割される。第２の層上には，ｅＮｏｄｅＢとＵＥとの間の無線インタフェースにおいて用いられる無線資源を制御するための役割を担う無線資源制御（ＲＲＣ）層（Ｌ３／ＲＲＣ）がある。図に示されるように，Ｌ２／外部ＡＲＱ層は，Ｃプレーンデータ及びＵプレーンデータの伝送を管理するために用いられる多数の外部ＡＲＱエンティティ９５を含み，Ｌ２／ＰＤＣＰ層は，Ｃプレーン及びＵプレーンデータを処理するために用いられるＰＤＣＰエンティティ９７を含む。
　【００２４】
　図５は，ダウンリンクデータパケットを処理するときに，ＰＤＣＰエンティティ９７及び外部ＡＲＱエンティティ９５によって実行される動作を概略的に示す。アップリンクデータパケットの場合にも同じようなプロセスが実行されるが，順序は逆である。図に示されるように，ＰＤＣＰエンティティ９７によって受信されるＰＤＣＰ　ＳＤＵ（サービスデータユニット）１０１は最初に，ヘッダ圧縮１０２を受けて，ヘッダが圧縮されている対応するＳＤＵ１０３が生成される。その後，ＰＤＣＰエンティティ９７は，ＵＥのためのＳＤＵのシーケンス内のそのＳＤＵの番号を特定するシーケンス番号（ＳＮ）を生成し，各ＳＤＵ１０３に添付する（１０４）。こうして生成された，ＳＮを有するＳＤＵ１０５は，その後，ＰＤＣＰバッファ１０７にバッファリングされる（１０６）。その後，これらのＳＤＵは，暗号化され（１０８），暗号化されたＰＤＣＰ　ＰＤＵ１０９が生成され，それらは外部ＡＲＱエンティティ９５に渡されて，そのエンティティにおいて，それらのＰＤＵはセグメント化され，外部ＡＲＱ　ＳＤＵセグメント１１１が形成される。その後，各外部ＡＲＱ　ＳＤＵセグメントは，対応するＰＤＣＰ　ＰＤＵ１０９内で，そのセグメント及びその位置を特定するデータでタグ付けされる。この実施形態では，外部ＡＲＱエンティティ９５は，ＰＤＣＰシーケンス番号（ＳＮ）と，元のＰＤＣＰ　ＰＤＵ１０９内の外部ＡＲＱセグメントの位置及び長さを指示するＯＦＦＳＥＴ及びＬＥＮＧＴＨとを再利用する。」
ｈ．「　【００２６】
ハンドオーバプロトコルの説明
　外部ＡＲＱエンティティ（ＬＴＥの場合のＲＬＣに相当するもの）は，すべての面において無線リンク制御（ＲＬＣ）と同一であるとは限らないが，以下に記載される説明は主に，データパケットの受信が受信機によって応答される応答モード（ＡＭ）無線リンク制御（ＲＬＣ）に当てはまる。応答モードエンティティと比べて異なる処理が適用される場合にはいつでも，ＶｏＩＰ及びストリーミングのようなリアルタイムアプリケーションのために利用される非応答モード（ＵＭ）外部ＡＲＱエンティティの仕様も持ち出される。
　【００２７】
　コンテキストを転送し，データを転送して，ロスレスｅＮｏｄｅＢ間ハンドオーバを支援するために，ソースｅＮｏｄｅＢが，ハンドオーバ中に自らとターゲットｅＮｏｄｅＢとの間でデータ伝送状態を同期させることができることが望ましいことを本発明人らは理解している。このことから，本発明者らは，ユーザプレーンデータのための中断時間が最低限であることを考慮に入れて，ハンドオーバ実行段階中の適切な時点において，データフローが中止されるべきであることが望ましいとの結論に達した。しかしながら，付加的なシグナリングを通じてデータ伝送を中止すると，ハンドオーバ時間全体が長くなるという問題を抱えることになるので，この望ましい要件を達成することは簡単ではない。本発明者らは，従来の手法（Ｃプレーンにおいてのみ実行される）を変更して，ハンドオーバプロセスの或る「実現形態」をユーザプレーンデータ転送プロセスに組み込むことによって，ハンドオーバ実行時に，ソースｅＮｏｄｅＢ及びＵＥにおいて（一方又は両方であるが，両方であることが好ましい）データ伝送を暗黙のうちに中止することが可能であることを理解している。さらに望ましい特徴は，ターゲットｅＮｏｄｅＢによって，又はＵＥによって無線で送信される重複パケットの数が最小限に抑えられることである。
　【００２８】
　図６は，上記の変更されたシーケンスの詳細と共に，ダウンリンク（ＤＬ）及びアップリンク（ＵＬ）においてＵプレーンデータ伝送を中止することが提案されるときのタイミングを示す。以下の説明は，データフローを中止するこの手法が，どのようにしてＬＴＥのための高速ロスレスハンドオーバの達成を容易にするかを説明する。
　【００２９】
　図６を参照すると，ＬＴＥ内アクセス・モビリティ・サポート（Intra-LTE-Access Mobility Support）のための情報フローが記述される。
　１）ソースｅＮｏｄｅＢ内のＵＥコンテキストは，接続確立時又は直前のＴＡ更新時に与えられるローミング制限に関する情報を含む。
　２）ソースｅＮｏｄｅＢエンティティは，エリア制限情報に従って，ＵＥ測定手順を構成する。ソースｅＮｏｄｅＢエンティティによって与えられる測定値は，ＵＥの接続移動性を制御する機能を支援することができる。
　３）ＵＥ及びソースｅＮｏｄｅＢからの測定結果に基づいて，おそらく付加的なＲＲＭ特有情報による支援を受けて，ソースｅＮｏｄｅＢは，ＵＥをターゲットｅＮｏｄｅＢによって制御されるセルにハンドオーバすることを決定する。
　４）ソースｅＮｏｄｅＢは，ターゲットｅＮｏｄｅＢエンティティにハンドオーバ要求を発行し，ターゲット側においてハンドオーバを準備するのに必要な情報を渡す。ターゲットｅＮｏｄｅＢは，要求された資源を構成する。
　５）ターゲットｅＮｏｄｅＢによってそれらの資源を与えられることができる場合には，ハンドオーバが成功する可能性を高めるために，ターゲットｅＮｏｄｅＢによって，アドミッション制御が実行される。
　６）ターゲットｅＮｏｄｅＢにおいてハンドオーバの準備が終了し，ＵＥがターゲットｅＮｏｄｅＢに向かう無線経路を再構成するための情報がソースｅＮｏｄｅＢに渡される。
　７）このステップは，以下のサブステップから成る。
　　ａ．下位のプロトコル層にＨＯコマンドをサブミットする前に，ソースｅＮｏｄｅＢ内の無線資源制御（ＲＲＣ）エンティティ９６が，外部ＡＲＱユーザプレーン（ＵＰ）エンティティ９５に，ダウンリンク方向において状態パケットを送信し，且つＤＬ送信を中止するように命令して，これらの外部ＡＲＱエンティティ９５が下位のプロトコル層にいかなるＡＲＱ　ＰＤＵもサブミットしないようにする。ＵＬ受信は継続すべきである。受信しているパケットがＵＭ外部ＡＲＱ　ＰＤＵである場合，外部ＡＲＱエンティティは，ＳＤＵを含む全てのＰＤＵが受信されると直ぐに，ＳＤＵを再構築し，それらを上位層に転送する。
　　ｂ．ＵＥは，ソースｅＮｏｄｅＢ　ＲＲＣエンティティ９６によって，ＨＯを実行するように命令される。ターゲット側無線資源情報は，その命令（コマンド）に含まれる。
　　ｃ．ＨＯコマンドを受信すると，ＵＥ内のＲＲＣエンティティ９６は，外部ＡＲＱ　Ｕプレーンエンティティに，アップリンク方向において状態パケットを送信し，且つＵＬ送信を中止するように命令する。それに応答して，ソースｅＮｏｄｅＢ内のＰＤＣＰ層は，対応するＰＤＣＰ　ＳＤＵを，そのバッファ１０７から確実に消去する。この後，ＵＥは，ターゲットｅＮｏｄｅＢにおいてＬ１／Ｌ２シグナリングを直ちに開始すべきである。
　　ｄ．両方向において，ユーザプレーンデータ送信が中止され，アップリンク及びダウンリンクの両方において状態パケットが交換されるので，ソースｅＮｏｄｅＢは，ソースｅＮｏｄｅＢとターゲットｅＮｏｄｅＢとの間でデータ伝送状態を正確に同期させることができるようになり，この後の任意の時点から，ＳＤＵ転送（ソースｅＮｏｄｅＢからターゲットｅＮｏｄｅＢへ）を開始することができる。
　８）ＵＥは，ターゲット側において同期を確立する。
　９）ＵＥは，セルにアクセスするのに成功すると，ターゲットｅＮｏｄｅＢに，ハンドオーバが完了したことの指示を送信する。
　１０ａ）下位層にハンドオーバ完了をサブミットした後に，ＵＥ内のＲＲＣエンティティ９６は，ＰＤＣＰエンティティ９７及び外部ＡＲＱエンティティ９５に，ＵＬ　Ｕプレーントラフィックを再開するように命令する。
　１０ｂ）ハンドオーバ完了を受信すると，ターゲットｅＮｏｄｅＢ内のＲＲＣエンティティ９６は，ＰＤＣＰエンティティ９７及び外部ＡＲＱ　Ｕプレーンエンティティ９５に，ＤＬトラフィックを再開するように命令する。ターゲットｅＮｏｄｅＢは，ソースｅＮｏｄｅＢから受信した，転送されたＤＬパケットの送信を開始する。
　１１）ＭＭＥ／ＵＰＥは，ＵＥがセルを変更したことを通知される。ＵＰＥは，データ経路をターゲットｅＮｏｄｅＢに切り替えて，ソースｅＮｏｄｅＢに向かう任意のＵプレーン／ＴＮＬ資源を解放することができる。
　１２）ＭＭＥ／ＵＰＥは，ハンドオーバ完了ＡＣＫメッセージによってターゲットｅＮｏｄｅＢへのハンドオーバ完了メッセージを確認する。
　１３）ターゲットｅＮｏｄｅＢは，ソース側において，資源の解放を開始する。ターゲットｅＮｏｄｅＢは，メッセージ９を受信した直後に，このメッセージを送信することができる。
　１４）解放資源メッセージを受信すると，ソースｅＮｏｄｅＢは，そのＵＥコンテキストに関連する無線及びＣプレーン関連資源を解放する。処理系依存機構が，データ転送を中止することができ，且つＵプレーン／ＴＮＬ資源を解放することができると決定するまで，ソースｅＮｏｄｅＢは，データ転送を実行し続ける。
　１５）新たなセルが，新たなトラッキングエリアのメンバである場合には，ＵＥはＭＭＥ／ＵＰＥで登録する必要があり，それにより，ＭＭＥ／ＵＰＥはターゲットｅＮｏｄｅＢにおいてエリア制限情報を更新する。
　【００３０】
外部ＡＲＱエンティティの一方向の停止
　ハンドオーバ実行時に，ソースｅＮｏｄｅＢ及びＵＥにおいてデータ伝送が中止されているため，転送中のデータパケットは，停止されているＲＬＣエンティティによって捨てられることになるので，両方向においてユーザプレーンデータ転送を一時中止する結果として（従来のＲＥＬ６ＲＬＣエンティティの場合のように），データロスが生じることを強調する必要がある。それゆえ，ハードハンドオーバが行なわれることになるＬＴＥシステムの場合，外部ＡＲＱエンティティ（ＲＬＣ）は，送信を中止すべきであるが，いかなるデータロスも避けるために，パケットを受信し続けるべきである。
　【００３１】
パケット転送
　この実施形態において，ＰＤＣＰシーケンス番号は，ハンドオーバ中に保持され（ターゲットｅＮｏｄｅＢによって用いられる），ソースｅＮｏｄｅＢは，ＵＥによってターゲットｅＮｏｄｅＢに応答されていない全てのダウンリンクＰＤＣＰ　ＳＤＵ１０５を（ＳＮと共に）選択的に（バッファ１０７から）転送し，まだ送信されていない任意の残りのダウンリンク外部ＡＲＱ　ＰＤＵセグメントを捨てる。ハンドオーバ中に，ソースｅＮｏｄｅＢは，順序通りに受信するのに成功したアップリンクＰＤＣＰ　ＳＤＵ１０５も電話網７（ＳＡＥゲートウエイ）に転送し，順序通りに受信されなかったアップリンクＰＤＣＰ　ＳＤＵ１０５を，バッファ１０７からターゲットｅＮｏｄｅＢに転送し，任意の残りのアップリンク外部ＡＲＱ　ＰＤＵを捨てる。順序通りに受信されなかったアップリンクＰＤＣＰ　ＳＤＵは，ターゲットｅＮｏｄｅＢ　ＰＤＣＰエンティティ９７に転送される前に，ＰＤＣＰエンティティ９７によってアップリンクパケットとしてマークを付され，そのパケットが非順次アップリンクパケットであり，ＵＥに送信するためのダウンリンクパケットではないことをターゲットｅＮｏｄｅＢが確認（establish）できるようにする必要がある。その後，欠けているアップリンクパケットがＵＥから受信されると，ターゲットｅＮｏｄｅＢ　ＰＤＣＰは，これらの非順次アップリンクパケットを電話網７に転送する。
　【００３２】
外部ＡＲＱエンティティを停止する前に状態ＰＤＵを送信する
　コンテキストを転送し，データを転送して，ロスレスｅＮｏｄｅＢ間ＨＯを支援するために，ソースｅＮｏｄｅＢは，ＨＯ中に，自らとＵＥとの間のデータ伝送状態を，ターゲットｅＮｏｄｅＢと同期させる。これは，ユーザプレーンのための中断時間が最低限であることを考慮に入れて，ＨＯ実行段階中の適切な時点においてデータフローを中止することによって容易にされる。一実施形態において，ソースｅＮｏｄｅＢ内及びＵＥ内の外部ＡＲＱエンティティは，適切な方向においてデータフローを中止する前に，他方のエンティティに状態報告（そのデバイスが受信に成功しているものを指示する）を送信する。この状態メッセージは，そのデバイスが受信したものだけを指示する簡単な報告とすることができる。これにより，ソースｅＮｏｄｅＢ及びＵＥは，ＨＯ実行中に送信を中止する前に，厳密なデータ伝送状態（すなわち，相手が受信したもの，それゆえ，依然として送信されなければならないもの）を知ることができるようになる。それゆえ，ＨＯ後に，無線インタフェースを介して重複パケットの送信を一切必要とすることなく，データ送信を再開することができる。
　【００３３】
　好ましい実施形態では，外部ＡＲＱ　ＰＤＵ１１１は（ＰＤＣＰ　ＳＮ，並びに各外部ＡＲＱ　ＰＤＵ１１１を特定するために必要とされるＯＦＦＳＥＴ及びＬＥＮＧＴＨデータを含むために），必然的にサイズが大きくなり，ハンドオーバを遅らせる場合があるので，ハンドオーバ時に交換される外部ＡＲＱ状態報告は，外部ＡＲＱ　ＰＤＵ１１１に基づく状態報告ではなく，ＰＤＣＰシーケンス番号（ＳＮ）を用いる外部ＡＲＱ　ＳＤＵ１０９に基づいている。ＰＤＣＰ　ＳＮに基づく状態報告の場合，状態ＰＤＵのサイズは，数十バイトの程度まで削減することができ，ハンドオーバの時の高速伝送を容易にする。通常動作中に，外部ＡＲＱエンティティは，より小さなサイズのＡＲＱ　ＰＤＵに基づいて，状態ＰＤＵを交換することができる。ハンドオーバ中に用いられる状態ＰＤＵとは異なり，これらの状態ＰＤＵは，より小さなＡＲＱ　ＰＤＵを特定するために必要とされるＯＦＦＳＥＴ及びＬＥＮＧＴＨデータを含むであろう。
（…中略…）
　【００３９】
　さらに，ハンドオーバコマンドがソースｅＮｏｄｅＢによって送信された後に，ＵＬ及びＤＬの両方向においてデータの伝送が続く場合には，ソースｅＮｏｄｅＢにある送信バッファ及び再送バッファ内のパケットの動的な性質に起因して，ソースｅＮｏｄｅＢとターゲットｅＮｏｄｅＢとの間のデータ伝送状態を同期させるのが複雑になり，結果として，非リアルタイム（ＮＲＴ）サービスのためのロスレスハンドオーバを確保するために，ＤＬにおいてターゲットｅＮｏｄｅＢによって，且つＵＬにおいてＵＥによって重複パケットが再送されることになるので，無線インタフェースの帯域幅を非効率的に使用することになる。しかしながら，ＵＭモードを用いるＶｏＩＰ等のようなリアルタイムサービスの場合，ソースｅＮｏｄｅＢによって送信され，ターゲットｅＮｏｄｅＢにおいて正確に受信されないデータパケットは，失われることになり，回復することはできない。それゆえ，ＲＴ及びＮＲＴ両方のサービスのためのデータフローを統一されたやり方で中止することは，ＮＲＴベアラの場合に無線インタフェースにおいてより良好に資源を利用するのに有用であり，ＲＴサービスの場合にデータロスを回避することになる。」
（当審注：
【００２９】に記載の「ｄ．両方向において，ユーザプレーンデータ送信が中止され，アップリンク及びダウンリンクの両方において状態パケットが交換
される
また，
【００３１】に記載の「この実施形態において，ＰＤＣＰシーケンス番号は，ハンドオーバ中に
保持
（ターゲットｅＮｏｄｅＢによって用いられる）
ターゲットｅＮｏｄｅＢに
と共に
ｉ．「
」（図１）
ｊ．「
」（図２）
ｋ．「
」（図５）
ｌ．「
」（図６）
（２）本願発明構成と発明の詳細な説明との対応関係についての検討
　前記ｂ．の【０００６】には，本願発明構成に対応する事項が記載されているが，当該記載は，【発明の概要】の一部を構成し，特許請求の範囲の実質的な複製にすぎず，発明の詳細な説明のうち，当該記載のみで，本願発明構成と表現上整合しているにすぎない。
　そこで，本願発明構成が，発明の詳細な説明と実質的に対応関係があるか否かについて検討する。
ア　本願発明の技術分野及び課題について
　前記ａ．の【０００１】ないし【０００３】，前記ｃ．の【００１３】，前記ｄ．の【００１６】，前記ｆ．の【００２２】並びに前記ｉ．の図１より，本願発明は，移動通信ネットワーク，とりわけ，３ＧＰＰのＬＴＥの規格に関し，ユーザ装置（ＵＥ）がソース基地局（ｅＮｏｄｅＢ）からターゲット基地局（ｅＮｏｄｅＢ）へハンドオーバ（ＨＯ）することを技術分野としている。（以降，「本願の出願時における技術常識」という場合には，本願の出願時における３ＧＰＰのＬＴＥの規格を含むものとする。）
　そして，前記ｄ．の【００１７】及び【００１８】，前記ｈ．の【００２７】より，本願発明は，ハンドオーバの中でも，ハードハンドオーバ（ＨＨＯ）をすることを前提とし，ハンドオーバ中のデータ伝送の中断時間を最小限とし，パケットロス及びパケット再送を最小限にすることを課題としている。
イ　ソース基地局（ｅＮｏｄｅＢ）及びターゲット基地局（ｅＮｏｄｅＢ）の構成について
　前記ｅ．の【００１９】及び前記ｊ．の図２には，基地局（ｅＮｏｄｅＢ）の構成について記載されており，このうち，前記ｅ．の【００１９】に記載の「基地局５」は，前記ｄ．の【００１６】に記載の「ソース基地局」である「基地局」５−１」と「ターゲット基地局」である「基地局５−２」の両方を指すことは明らかであるから，ソース基地局（ｅＮｏｄｅＢ）とターゲット基地局（ｅＮｏｄｅＢ）との間に構成上の差違があるとは認められない。
ウ　「状態報告」について
　「状態報告」の語句は，明細書においては，特許請求の範囲の実質的な複製にすぎない【発明の概要】の欄を除くと，前記ｈ．の【００３２】及び【００３３】しか記載がない。
　そして，【００３２】の記載「一実施形態において，ソースｅＮｏｄｅＢ内及びＵＥ内の外部ＡＲＱエンティティは，適切な方向においてデータフローを中止する前に，他方のエンティティに状態報告（そのデバイスが受信に成功しているものを指示する）を送信する。この状態メッセージは，そのデバイスが受信したものだけを指示する簡単な報告とすることができる。これにより，ソースｅＮｏｄｅＢ及びＵＥは，ＨＯ実行中に送信を中止する前に，厳密なデータ伝送状態（すなわち，相手が受信したもの，それゆえ，依然として送信されなければならないもの）を知ることができるようになる。」，【００３３】の記載「好ましい実施形態では，外部ＡＲＱ　ＰＤＵ１１１は（ＰＤＣＰ　ＳＮ，並びに各外部ＡＲＱ　ＰＤＵ１１１を特定するために必要とされるＯＦＦＳＥＴ及びＬＥＮＧＴＨデータを含むために），必然的にサイズが大きくなり，ハンドオーバを遅らせる場合があるので，ハンドオーバ時に交換される外部ＡＲＱ状態報告は，外部ＡＲＱ　ＰＤＵ１１１に基づく状態報告ではなく，ＰＤＣＰシーケンス番号（ＳＮ）を用いる外部ＡＲＱ　ＳＤＵ１０９に基づいている。ＰＤＣＰ　ＳＮに基づく状態報告の場合，状態ＰＤＵのサイズは，数十バイトの程度まで削減することができ，ハンドオーバの時の高速伝送を容易にする。」から「状態報告」は，ハンドオーバ時に交換され，デバイスが受信に成功しているものを指示する情報であって，具体的には，「ＰＤＣＰシーケンス番号（ＳＮ）」を含むメッセージ（「状態メッセージ」）と解される。そして，「ＰＤＣＰシーケンス番号（ＳＮ）」は，前記ｇ．の【００２４】の記載「ＳＤＵのシーケンス内のそのＳＤＵの番号を特定するシーケンス番号（ＳＮ）」より，「ＳＤＵの番号を特定するシーケンス番号（ＳＮ）」である。そうすると，「状態報告」とは，デバイスが受信に成功しているＳＤＵを指示するＰＤＣＰシーケンス番号（ＳＮ）を含むメッセージであるといえる。
　そして，前記【００３２】の記載「ソースｅＮｏｄｅＢ内及びＵＥ内の外部ＡＲＱエンティティは，適切な方向においてデータフローを中止する前に，他方のエンティティに状態報告（そのデバイスが受信に成功しているものを指示する）を送信する。」及び「これにより，ソースｅＮｏｄｅＢ及びＵＥは，…厳密なデータ伝送状態…を知ることができるようになる。」より，「状態報告」は，ソース基地局（ｅＮｏｄｅＢ）とユーザ装置（ＵＥ）との間で，データフローを中止する前に，交換（送受信）されるものと解される。
　以上から，「状態報告」とは，ハンドオーバ時に，かつ，データフローを中止する前に，ソース基地局（ｅＮｏｄｅＢ）とユーザ装置（ＵＥ）との間で送受信される，ソース基地局（ｅＮｏｄｅＢ）又はユーザ装置（ＵＥ）が受信に成功しているＳＤＵを指示するＰＤＣＰシーケンス番号（ＳＮ）を含む状態メッセージ，といえる。
エ　ハンドオーバの処理について
　前記ｈ．（特に，【００２９】）及び前記ｌ．の図６には，ハンドオーバの処理について記載されている。そして，【００２９】の記載において，ハンドオーバをすることを決定し，完了までの処理を再掲すると，次のとおりである。
「　４）ソースｅＮｏｄｅＢは，ターゲットｅＮｏｄｅＢエンティティにハンドオーバ要求を発行し，ターゲット側においてハンドオーバを準備するのに必要な情報を渡す。ターゲットｅＮｏｄｅＢは，要求された資源を構成する。
　５）ターゲットｅＮｏｄｅＢによってそれらの資源を与えられることができる場合には，ハンドオーバが成功する可能性を高めるために，ターゲットｅＮｏｄｅＢによって，アドミッション制御が実行される。
　６）ターゲットｅＮｏｄｅＢにおいてハンドオーバの準備が終了し，ＵＥがターゲットｅＮｏｄｅＢに向かう無線経路を再構成するための情報がソースｅＮｏｄｅＢに渡される。
　７）このステップは，以下のサブステップから成る。
　　ａ．下位のプロトコル層にＨＯコマンドをサブミットする前に，ソースｅＮｏｄｅＢ内の無線資源制御（ＲＲＣ）エンティティ９６が，外部ＡＲＱユーザプレーン（ＵＰ）エンティティ９５に，ダウンリンク方向において状態パケットを送信し，且つＤＬ送信を中止するように命令して，これらの外部ＡＲＱエンティティ９５が下位のプロトコル層にいかなるＡＲＱ　ＰＤＵもサブミットしないようにする。ＵＬ受信は継続すべきである。受信しているパケットがＵＭ外部ＡＲＱ　ＰＤＵである場合，外部ＡＲＱエンティティは，ＳＤＵを含む全てのＰＤＵが受信されると直ぐに，ＳＤＵを再構築し，それらを上位層に転送する。
　　ｂ．ＵＥは，ソースｅＮｏｄｅＢ　ＲＲＣエンティティ９６によって，ＨＯを実行するように命令される。ターゲット側無線資源情報は，その命令（コマンド）に含まれる。
　　ｃ．ＨＯコマンドを受信すると，ＵＥ内のＲＲＣエンティティ９６は，外部ＡＲＱ　Ｕプレーンエンティティに，アップリンク方向において状態パケットを送信し，且つＵＬ送信を中止するように命令する。それに応答して，ソースｅＮｏｄｅＢ内のＰＤＣＰ層は，対応するＰＤＣＰ　ＳＤＵを，そのバッファ１０７から確実に消去する。この後，ＵＥは，ターゲットｅＮｏｄｅＢにおいてＬ１／Ｌ２シグナリングを直ちに開始すべきである。
　　ｄ．両方向において，ユーザプレーンデータ送信が中止され，アップリンク及びダウンリンクの両方において状態パケットが交換されるので，ソースｅＮｏｄｅＢは，ソースｅＮｏｄｅＢとターゲットｅＮｏｄｅＢとの間でデータ伝送状態を正確に同期させることができるようになり，この後の任意の時点から，ＳＤＵ転送（ソースｅＮｏｄｅＢからターゲットｅＮｏｄｅＢへ）を開始することができる。
　８）ＵＥは，ターゲット側において同期を確立する。
　９）ＵＥは，セルにアクセスするのに成功すると，ターゲットｅＮｏｄｅＢに，ハンドオーバが完了したことの指示を送信する。」
　この中で，ソース基地局（ｅＮｏｄｅＢ）からターゲット基地局（ｅＮｏｄｅＢ）に送信される情報として明記されているのは，前記４）の「ターゲット側においてハンドオーバを準備するのに必要な情報」と，７）のｄ．の「ＳＤＵ」のみである。
　このうち，前記４）の「ターゲット側においてハンドオーバを準備するのに必要な情報」は，ターゲット基地局（ｅＮｏｄｅＢ）が，要求された資源を構成するために使用される情報であって，ターゲット基地局（ｅＮｏｄｅＢ）が，ハンドオーバ後にユーザ装置（ＵＥ）と通信するために必要な資源に関する情報である。そして，当該資源に関する情報が「状態報告」であることは，明細書及び図面には記載も示唆もなく，本願の出願時における技術常識でもない。
　また，前記７）の「ＳＤＵ」は，前記ｇ．の【００２４】の記載「ＳＮを有するＳＤＵ１０５」及び図５の記載より，「ＰＤＣＰシーケンス番号（ＳＮ）」を含むものではあるが，「ＳＤＵ」が「状態報告」であることは，明細書及び図面には記載も示唆もなく，本願の出願時における技術常識でもない。
　また，前記７）のｄ．には，「ソースｅＮｏｄｅＢは，ソースｅＮｏｄｅＢとターゲットｅＮｏｄｅＢとの間でデータ伝送状態を正確に同期させることができるようになり，この後の任意の時点から，ＳＤＵ転送（ソースｅＮｏｄｅＢからターゲットｅＮｏｄｅＢへ）を開始することができる。」と記載されているが，ソース基地局（ｅＮｏｄｅＢ）は，どのような手段により自身とターゲット基地局（ｅＮｏｄｅＢ）との間で「データ伝送状態を正確に同期させる」のかについて具体的な記載はない。
　また，ＳＤＵ転送に関し，前記ｈ．の【００３１】には，
「この実施形態において，ＰＤＣＰシーケンス番号は，ハンドオーバ中に保持され（ターゲットｅＮｏｄｅＢによって用いられる），ソースｅＮｏｄｅＢは，ＵＥによってターゲットｅＮｏｄｅＢに応答されていない全てのダウンリンクＰＤＣＰ　ＳＤＵ１０５を（ＳＮと共に）選択的に（バッファ１０７から）転送し，まだ送信されていない任意の残りのダウンリンク外部ＡＲＱ　ＰＤＵセグメントを捨てる。ハンドオーバ中に，ソースｅＮｏｄｅＢは，順序通りに受信するのに成功したアップリンクＰＤＣＰ　ＳＤＵ１０５も電話網７（ＳＡＥゲートウエイ）に転送し，順序通りに受信されなかったアップリンクＰＤＣＰ　ＳＤＵ１０５を，バッファ１０７からターゲットｅＮｏｄｅＢに転送し，任意の残りのアップリンク外部ＡＲＱ　ＰＤＵを捨てる。順序通りに受信されなかったアップリンクＰＤＣＰ　ＳＤＵは，ターゲットｅＮｏｄｅＢ　ＰＤＣＰエンティティ９７に転送される前に，ＰＤＣＰエンティティ９７によってアップリンクパケットとしてマークを付され，そのパケットが非順次アップリンクパケットであり，ＵＥに送信するためのダウンリンクパケットではないことをターゲットｅＮｏｄｅＢが確認（establish）できるようにする必要がある。その後，欠けているアップリンクパケットがＵＥから受信されると，ターゲットｅＮｏｄｅＢ　ＰＤＣＰは，これらの非順次アップリンクパケットを電話網７に転送する。」
と記載されている。
　この記載によると，ソース基地局（ｅＮｏｄｅＢ）は，ダウンリンクについては，ユーザ装置（ＵＥ）によって応答されていないＳＤＵをターゲット基地局（ｅＮｏｄｅＢ）に送信し，アップリンクについては，順序通りに受信されたＳＤＵは，電話網に転送し，順序通りに受信されなかったＳＤＵをマーク付けしてターゲット基地局（ｅＮｏｄｅＢ）に送信し，残りのＳＤＵは廃棄することが記載されている。そうすると，ターゲット基地局（ｅＮｏｄｅＢ）は，「ＳＤＵ転送」により受信したＳＤＵ（ＳＮを含む。）により，未処理のアップリンクＳＤＵ及び未処理のダウンリンクＳＤＵを識別できるから，実質的に，ソースｅＮｏｄｅＢとの間で，ユーザ装置（ＵＥ）との間のデータ伝送状態の同期を図ることができると解される。
　そうすると，ソース基地局（ｅＮｏｄｅＢ）は，「ＳＤＵ転送」により，ターゲット基地局（ｅＮｏｄｅＢ）との間で「データ伝送状態を正確に同期させる」ことを実現していると解するのが合理的である。そして，「ＳＤＵ転送」が「状態報告」を送信することに対応しないことは，上述したとおりである。
　なお，前記ｈ．の【００２７】に記載の「コンテキストを転送し，データを転送して，ロスレスｅＮｏｄｅＢ間ハンドオーバを支援するために，
ソースｅＮｏｄｅＢが
自らとターゲットｅＮｏｄｅＢとの間でデータ伝送状態を同期させることができることが望ましい
ソースｅＮｏｄｅＢとターゲットｅＮｏｄｅＢとの間のデータ伝送状態を同期させるのが複雑
オ　まとめ
　前記ａ．ないしｌ．により摘記した箇所以外の記載を参酌しても，明細書及び図面には，本願発明構成は記載されておらず，また，本願の出願時における技術常識を参酌しても自明であるとはいえない。
　また，前記エで述べたように，ソース基地局（ｅＮｏｄｅＢ）は，「ＳＤＵ転送」により，ターゲット基地局（ｅＮｏｄｅＢ）との間で「データ伝送状態を正確に同期させる」ことから，さらに「ＰＤＣＰシーケンス番号（ＳＮ）」を含む「状態報告」を送信する必要がないことは明らかである。
　したがって，本願の出願時における技術常識に照らしても，本願発明の範囲まで，発明の詳細な説明に開示された内容を拡張ないし一般化できるとはいえない。
　よって，本願発明は，発明の詳細な説明に記載したものでない。
（３）平成２８年８月２６日付けの意見書における主張について
　請求人は，平成２８年８月２６日付けの意見書において，次のような主張をしている。
ア　「　段落００２９の７ｄの記載は，段落００２９のステップ６におけるソースｅＮｏｄｅＢとターゲットｅＮｏｄｅＢ間の動作を更に詳細に説明するサブステップを記載したものです。このことは，段落００２９のステップ６の記載からも明らかです。更に，段落００２９の７ｄは，ソースｅＮｏｄｅＢとターゲットｅＮｏｄｅＢ間に示された図６の７ｄとも対応しています。このことからも，段落００２９の７ｄの記載は，ソースｅＮｏｄｅＢとターゲットｅＮｏｄｅＢとの間の動作を記載していることは明白です。
　ここで，本願明細書段落００２９における７ｄの記載を正確に引用しますと，『ｄ.両方向において，ユーザプレーンデータ送信が中止され，アップリンク及びダウンリンクの両方において状態パケットが交換されるので，ソースｅＮｏｄｅＢは，ソースｅＮｏｄｅＢとターゲットｅＮｏｄｅＢとの間でデータ伝送状態を正確に同期させることができるようになり，この後の任意の時点から，ＳＤＵ転送（ソースｅＮｏｄｅＢからターゲットｅＮｏｄｅＢへ)を開始することができる。』と記載されています。
　まず，上記引用箇所における『両方向』とは，ソースｅＮｏｄｅＢとターゲットｅＮｏｄｅＢとの間の両方向であることは，図６の７ｄがソースｅＮｏｄｅＢとターゲットｅＮｏｄｅＢとの間の動作として記載されていることからも明らかです。即ち，段落００２９の記載は，ソースｅＮｏｄｅＢとターゲットｅＮｏｄｅＢとの間の両方向において，データ送信が中止され，代わりに状態パケットがソースｅＮｏｄｅＢとターゲットｅＮｏｄｅＢとの間で交換されることを明記しております。
　更に，段落００２９の前段における『アップリンク及びダウンリンクの両方』とは，ソースｅＮｏｄｅＢ及びターゲットｅＮｏｄｅＢにおけるアップリンク方向及びダウンリンク方向の両方向の意味であることは，段落００２９における７ｄ以外の７ａ-７ｃの記載からも明らかです。
　また，段落００２９の前段における『状態パケット』は本願技術事項における「状態報告」であることは明らかですし，更に，状態パケット交換後，ソースｅＮｏｄｅＢからターゲットｅＮｏｄｅＢへＳＤＵ転送が実行されることも記載しております。
　拒絶理由通知書における認定では，『段落００２９の「ＳＤＵ転送」が「状態報告」ではなく，データ転送を指すことは明らかである。』とのことです。
　しかし，この認定は，段落００２９の前段における『ｄ.両方向において，ユーザプレーンデータ送信が中止され，アップリンク及びダウンリンクの両方において状態パケットが交換される』の記載を全く無視した認定であり，明らかに誤った認定であります。」
イ　「　また，拒絶理由通知書では，『ＳＤＵ転送』とは別個の『状態報告』をソース基地局からターゲットに送信する必然性はないとの御指摘です。
　しかし，本願明細書段落００３３における『ＰＤＣＰ　ＳＮに基づく状態報告の場合，状態ＰＤＵのサイズは，数十バイトの程度まで削減することができ，ハンドオーバの時の高速伝送を容易にする。』との記載からも明らかな通り，ハンドオーバ(特にハードハンドオーバ)の時の状態報告を高速で行うことができるという利点があります。よって，拒絶理由通知書における認定は，本願発明に係る明細書の記載を誤解したことに基づく誤った認定でありますので，取り消されるべきものであります。
ウ　「　また，拒絶理由通知書では，本願明細書の【図６】の７ｄにおける記載「ソースｅＮｏｄｅＢがターゲットｅＮｏｄｅＢにパケットを転送し始める」が引用されていますが，段落００２９の前段の記載『ｄ．両方向において，ユーザプレーンデータ送信が中止され，アップリンク及びダウンリンクの両方において状態パケットが交換されるので，ソースｅＮｏｄｅＢは，ソースｅＮｏｄｅＢとターゲットｅＮｏｄｅＢとの間でデータ伝送状態を正確に同期させることができるようになり，この後の任意の時点から，ＳＤＵ転送（ソースｅＮｏｄｅＢからターゲットｅＮｏｄｅＢへ）を開始することができる。』について何ら引用されておりません。
　よって，拒絶理由通知書の認定は，段落００２９の記載の一部のみを引用して，他の記載について言及されておりませんので，審理が尽くされているとは考えられません。」
　上記各主張について，以下，検討する。
（ア）主張アについて
（ア−１）ステップ６と，ステップ７ａ．ないし７ｃ．との関係について
　請求人は，「段落００２９の７ｄの記載は，段落００２９のステップ６におけるソースｅＮｏｄｅＢとターゲットｅＮｏｄｅＢ間の動作を更に詳細に説明するサブステップを記載したものです。このことは，段落００２９のステップ６の記載からも明らかです。」と主張している。
　しかしながら，明細書の段落【００２９】に記載の「６）ターゲットｅＮｏｄｅＢにおいてハンドオーバの準備が終了し，ＵＥがターゲットｅＮｏｄｅＢに向かう無線経路を再構成するための情報がソースｅＮｏｄｅＢに渡される。」及び図６の「６．ＨＯ応答」からして，ステップ６は，ターゲット基地局（ｅＮｏｄｅＢ）が，「ＨＯ応答」として，ＵＥがターゲット基地局（ｅＮｏｄｅＢ）に向かう無線経路を再構成するための情報を，ソース基地局（ｅＮｏｄｅＢ）に送信する処理に関するものである。
　一方，明細書の段落【００２９】及び図６の記載によれば，後続のステップ７ａ．は，ソース基地局（ｅＮｏｄｅＢ）が，ダウンリンク方向に状態パケットを送信し，ＤＬ送信（ダウンリンクの送信）を中止する処理に関するものであり，ステップ７ｂ．は，ソース基地局（ｅＮｏｄｅＢ）が，ユーザ装置（ＵＥ）に対してハンドオーバを実行する命令（ＨＯコマンド）を送信する処理に関するものであり，ステップ７ｃ．は，ユーザ装置（ＵＥ）が，ＨＯコマンドを受信して，アップリンク方向に状態パケットを送信し，ＵＬ送信（アップリンクの送信）を中止する処理に関するものであるから，ステップ７ａ．ないし７ｃ．はいずれも，ステップ６の処理（ＵＥがターゲット基地局（ｅＮｏｄｅＢ）に向かう無線経路を再構成するための情報を，ソース基地局（ｅＮｏｄｅＢ）に送信する処理）と関連しないことが明らかである。そして，ステップ７ａ．ないし７ｄ．は，そのナンバリングから，同種の処理に関係することが明らかであるから，ステップ７ｄ．のみが，ステップ６に関連するもの，すなわち，ステップ６におけるソース基地局（ｅＮｏｄｅＢ）とターゲット基地局（ｅＮｏｄｅＢ）間の動作を更に詳細に説明するサブステップであるということはできない。
　そうすると，明細書の段落【００２９】に記載の「７）このステップは，以下のサブステップから成る。」における「このステップ」は，前段のステップ６を指すのではなく，直前の数字「７」に係るステップすなわちステップ７を指すと解するのが合理的である。
（ア−２）「両方向」の解釈について
　さらに，請求人は，
「　ここで，本願明細書段落００２９における７ｄの記載を正確に引用しますと，『ｄ.両方向において，ユーザプレーンデータ送信が中止され，アップリンク及びダウンリンクの両方において状態パケットが交換されるので，ソースｅＮｏｄｅＢは，ソースｅＮｏｄｅＢとターゲットｅＮｏｄｅＢとの間でデータ伝送状態を正確に同期させることができるようになり，この後の任意の時点から，ＳＤＵ転送（ソースｅＮｏｄｅＢからターゲットｅＮｏｄｅＢへ)を開始することができる。』と記載されています。
　まず，上記引用箇所における『両方向』とは，ソースｅＮｏｄｅＢとターゲットｅＮｏｄｅＢとの間の両方向であることは，図６の７ｄがソースｅＮｏｄｅＢとターゲットｅＮｏｄｅＢとの間の動作として記載されていることからも明らかです。即ち，段落００２９の記載は，ソースｅＮｏｄｅＢとターゲットｅＮｏｄｅＢとの間の両方向において，データ送信が中止され，代わりに状態パケットがソースｅＮｏｄｅＢとターゲットｅＮｏｄｅＢとの間で交換されることを明記しております。」と主張している。
　まず，「『両方向』とは，ソースｅＮｏｄｅＢとターゲットｅＮｏｄｅＢとの間の両方向である」との認定が正しければ，「両方向において，ユーザプレーンデータ送信が中止され」るための前提として，ソース基地局（ｅＮｏｄｅＢ）とターゲット（ｅＮｏｄｅＢ）との間で「ユーザプレーンデータ送信」がなされている必要がある。
　しかしながら，明細書及び図面には，ソース基地局（ｅＮｏｄｅＢ）とターゲット（ｅＮｏｄｅＢ）との間で「ユーザプレーンデータ送信」がなされることは記載されていない。また，「ユーザプレーンデータ送信」がなされるのは，基地局（ｅＮｏｄｅＢ）とユーザ装置（ＵＥ）との間であることは，本願の出願時における技術常識であることから，ソース基地局（ｅＮｏｄｅＢ）とターゲット（ｅＮｏｄｅＢ）との間で「ユーザプレーンデータ送信」がなされることは自明ではない。
　また，前記「（２）本願発明構成と発明の詳細な説明との対応関係についての検討」の「イ　ソース基地局（ｅＮｏｄｅＢ）及びターゲット基地局（ｅＮｏｄｅＢ）の構成について」の項で述べたように，本願の明細書及び図面の記載において，ソース基地局（ｅＮｏｄｅＢ）とターゲット基地局（ｅＮｏｄｅＢ）との間に構成上の差違があるとは認められないから，いずれか一方の基地局（ｅＮｏｄｅＢ）がユーザ装置（ＵＥ）として動作するなどして，他方の基地局（ｅＮｏｄｅＢ）との間で「ユーザプレーンデータ送信」がなされるといった特別な事情が存在するとは認められない。
　そして，明細書の段落【００２９】には，ステップ７ａ．において，ソース基地局（ｅＮｏｄｅＢ）が，ＤＬ送信の中止を外部ＡＲＱユーザプレーンエンティティに命令し，ステップ７ｃ．において，ユーザ装置（ＵＥ）が，ＵＬ送信の中止を外部ＡＲＱユーザプレーンエンティティに命令することが記載されており，ＤＬ送信が，ユーザプレーンのダウンリンク送信であること，ＵＬ送信が，ユーザプレーンのアップリンク送信であることは自明である。そうすると，明細書の段落【００２９】に記載の「両方向において，ユーザプレーンデータ送信が中止されとは，ステップ７ａ．におけるＤＬ送信の中止，及び，ステップ７ｃ．におけるＵＬ送信の中止を意味することは明らかである。
（ア−３）「状態パケット」について
　さらに，請求人は，
「即ち，段落００２９の記載は，ソースｅＮｏｄｅＢとターゲットｅＮｏｄｅＢとの間の両方向において，データ送信が中止され，代わりに状態パケットがソースｅＮｏｄｅＢとターゲットｅＮｏｄｅＢとの間で交換されることを明記しております。」とも主張している。
　ここで，「状態パケット」の語句は，明細書においては，特許請求の範囲の実質的な複製にすぎない【発明の概要】の欄を除くと，段落【００２９】にしか記載がなく，ここでは，ステップ７ａ．において，ソース基地局（ｅＮｏｄｅＢ）が，ダウンリンク方向に状態パケットを送信することが記載され，ステップ７ｃ．において，ユーザ装置（ＵＥ）が，アップリンク方向に状態パケットを送信することが記載されている。
　そうすると，段落【００２９】のステップ７ｄ．の項目に記載されている「アップリンク及びダウンリンクの両方において状態パケットが交換される」は，ステップ７ａ．のソース基地局（ｅＮｏｄｅＢ）によるダウンリンク方向での状態パケットの送信，及び，ステップ７ｃ．のユーザ装置（ＵＥ）によるアップリンク方向での状態パケットの送信を意味すると解するのが合理的である。
（ア−４）「ＳＤＵ転送」が「状態報告」ではないとの認定について
　さらに，請求人は，
「　拒絶理由通知書における認定では，「段落００２９の『ＳＤＵ転送』が『状態報告』ではなく，データ転送を指すことは明らかである。」とのことです。
　しかし，この認定は，段落００２９の前段における『ｄ.両方向において，ユーザプレーンデータ送信が中止され，アップリンク及びダウンリンクの両方において状態パケットが交換される』の記載を全く無視した認定であり，明らかに誤った認定であります。」とも主張している。
　しかしながら，前記（ア−１）ないし（ア−３）において述べたように，段落【００２９】に記載の「ｄ.両方向において，ユーザプレーンデータ送信が中止され，アップリンク及びダウンリンクの両方において状態パケットが交換される」は，ソース基地局（ｅＮｏｄｅＢ）とユーザ装置（ＵＥ）との間の送受信に関する事項を特定するものであって，請求人が主張するように，ソース基地局（ｅＮｏｄｅＢ）とターゲット基地局（ｅＮｏｄｅＢ）との間の送受信に関する事項を特定したものではない。
　また，段落【００２９】に記載の「ＳＤＵ転送」が「状態報告」ではないことは，前記「（２）本願発明構成と発明の詳細な説明との対応関係についての検討」の「エ　ハンドオーバの処理について」の項で述べたとおりである。
　以上のとおり，主張アは，採用することができない。
（イ）主張イについて
　明細書の段落【００３３】には，外部ＡＲＱ　ＰＤＵ基づく状態報告は，ＰＤＣＰシーケンス番号（ＳＮ）のみならず，ＯＦＦＳＥＴ，ＬＥＮＧＴＨといった情報を含むため，サイズが大きくなるのに対し，外部ＡＲＱ　ＳＤＵに基づく状態報告は，ＰＤＣＰシーケンス番号（ＳＮ）のみですむために，高速化が実現できるという趣旨のことが記載されているが，当該外部ＡＲＱ　ＳＤＵに基づく状態報告が，ソース基地局（ｅＮｏｄｅＢ）からターゲット基地局（ｅＮｏｄｅＢ９）に送信されることは記載されていない。
　よって，主張イは，採用することができない。
（ウ）主張ウについて
　当審拒絶理由の「１　本願明細書の記載箇所について」の項において，段落【００２９】の記載のうち，「ｄ．両方向において，ユーザプレーンデータ送信が中止され，アップリンク及びダウンリンクの両方において状態パケットが交換されるので，ソースｅＮｏｄｅＢは，ソースｅＮｏｄｅＢとターゲットｅＮｏｄｅＢとの間でデータ伝送状態を正確に同期させることができるようになり，この後の任意の時点から，ＳＤＵ転送（ソースｅＮｏｄｅＢからターゲットｅＮｏｄｅＢへ）を開始することができる。」の部分を引用しており，当該記載部分を検討の対象としていることは明らかである。
　また，当該部分のうち，「両方向において，ユーザプレーンデータ送信が中止され，アップリンク及びダウンリンクの両方において状態パケットが交換される」は，前記「主張アについて」の項で説示したように，同じ段落【００２９】に記載されたステップ７ａ．及びステップ７ｂ．に関する記載から，ソース基地局（ｅＮｏｄｅＢ）からターゲット基地局（ｅＮｏｄｅＢ）への送信とは無関係であり，また，「両方向において，ユーザプレーンデータ送信が中止され，アップリンク及びダウンリンクの両方において状態パケットが交換される」の部分が，ソース基地局（ｅＮｏｄｅＢ）からターゲット基地局（ｅＮｏｄｅＢ）への送信に関する事項であることは，平成２８年８月２６日付けの意見書において初めて請求人が主張した事項であって，平成２７年４月１日付けの意見書においては主張がなされていなかった。
　また，本願発明が発明の詳細な説明に記載されているか否かを判断するにあたり，本願発明と関係のないことが明らかであるところまで，かつ，請求人が主張していないところまで，細部にわたって引用し説示する必要はないから，当審拒絶理由が，審理を尽くしていないとはいえない。
　よって，主張イは，採用することができない。
　したがって，請求人の主張は，いずれも採用することができない。
（４）出願日の遡及について
　本願発明は，分割出願の基礎となる出願（特願２００９−５４５７５６号，特願２０１２−１２４９７１号）の出願当初の明細書，特許請求の範囲または図面に記載した事項の範囲内にもない。
　よって，本願は，分割出願の要件を満たしていないから，出願日の遡及を認めない。
第５　むすび
　以上のとおり，本願発明は，特許法第３６条第６項第１号に規定する要件を満たしていないから，特許を受けることができない。
　したがって，本願は，その余の特許要件に論及するまでもなく拒絶すべきものである。
　よって，結論のとおり審決する。