• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 特36条6項1、2号及び3号 請求の範囲の記載不備 特許、登録しない(前置又は当審拒絶理由) H04W
管理番号 1322987
審判番号 不服2015-20079  
総通号数 206 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2017-02-24 
種別 拒絶査定不服の審決 
審判請求日 2015-11-09 
確定日 2016-12-16 
事件の表示 特願2014- 92445「ハンドオーバ処理」拒絶査定不服審判事件〔平成26年 8月28日出願公開,特開2014-158293〕について,次のとおり審決する。 
結論 本件審判の請求は,成り立たない。 
理由 第1 手続の経緯
本願は,2008年4月30日(パリ条約による優先権主張外国庁受理 2007年5月1日 グレートブリテン及び北アイルランド連合王国)を国際出願日とする出願である特願2009-545756号の一部を,平成24年5月31日に新たな特許出願とした特願2012-124971号の一部を,平成26年4月28日に新たな特許出願としたものであって,平成27年1月26日付けで拒絶理由が通知され,同年4月1日に手続補正がなされるとともに意見書が提出され,同年8月4日付けで拒絶査定がなされ,これに対し,同年11月9日に拒絶査定不服審判が請求され,その後,当審より,平成28年6月29日付けで拒絶理由(以下,「当審拒絶理由」という。)が通知され,これに対し,同年8月26日付けで手続補正がなされるとともに意見書が提出されたものである。

第2 本願発明
本願の請求項1ないし9に係る発明は,平成28年8月26日付けの手続補正で補正された特許請求の範囲の請求項1ないし9に記載された事項により特定されるものと認められる。
そして,本願の請求項8に係る発明(以下,「本願発明」という。)は以下のとおりである。

「 ソース基地局における通信制御方法であって,
少なくとも1つのPDCPシーケンス番号(Packet Data Convergence Protocol Sequence Number)を含む状態報告を,データ送信を中止した後に,生成し,
ハンドオーバ中に,前記状態報告を,ターゲット基地局へ送信し,
前記状態報告を送信した後に,前記ターゲット基地局へデータを転送する通信制御方法。」

(特許請求の範囲の請求項1に記載の「送信する生成手段」は,「生成する生成手段」の誤記の可能性があり,発明が不明確であるため,請求項8に係る発明を「本願発明」と認定した。)。

第3 当審拒絶理由
当審拒絶理由の概要は,次のとおりである。

「 理 由

<出願日の遡及について>

本願は特願2009-545756号(優先日:平成19年5月1日。以下,「原出願」という。)の分割出願である。
本願特許請求の範囲の各項は,「ソース基地局において,少なくとも1つのPDCPシーケンス番号(Packet Data Convergence Protocol Sequence Number)を含む状態報告を生成し,ハンドオーバ中に,前記状態報告を,ターゲット基地局へ送信する」との技術事項(以下,「本願技術事項」という。)を含むが,下記Aに詳述するように,上記本願技術事項は本願の発明の詳細な説明に記載されていない。また,図面にも記載されていない。
そして,原出願の出願当初の明細書,特許請求の範囲又は図面(以下,「明細書等」という。)は本願請求項に対応した記載がない点を除き本願の明細書等と同じであるところ,上記本願技術事項は原出願の明細書等に記載されていないことは明らかである。
したがって,本願の特許請求の範囲に記載された上記本願技術事項は原出願の明細書等に記載された事項の範囲内ではないため,分割の実体的要件を満たさないから,出願日の遡及を認めることができず,本願の出願日は現実の出願日である平成26年4月28日と認める。


A 本件出願は,特許請求の範囲の記載が下記の点で不備のため,特許法第36条第6項第1号に規定する要件を満たしていない。



本願技術事項(「ソース基地局において,少なくとも1つのPDCPシーケンス番号(Packet Data Convergence Protocol Sequence Number)を含む状態報告を生成し,ハンドオーバ中に,前記状態報告を,ターゲット基地局へ送信する」こと)は,本願の発明の詳細な説明に記載されていない。

1 本願明細書の記載箇所について
ソース基地局からターゲット基地局へ送信される情報に関して,本願明細書と図面には,【図6】の7dに「ソースeNodeBがターゲットeNodeBにパケットを転送し始める」と記載され,また,該7dのステップに関して【0029】に「d.両方向において,ユーザプレーンデータ送信が中止され,アップリンク及びダウンリンクの両方において状態パケットが交換されるので,ソースeNodeBは,ソースeNodeBとターゲットeNodeBとの間でデータ伝送状態を正確に同期させることができるようになり,この後の任意の時点から,SDU転送(ソースeNodeBからターゲットeNodeBへ)を開始することができる。」と記載されているように,「SDU転送」が記載されているのみである。
しかしながら,本願請求項1に「前記状態報告を送信した後に,前記ターゲット基地局へデータを転送するソース基地局」と記載されているように,上記「SDU転送」が,本願技術事項の「状態報告」ではなく,該状態報告をターゲット基地局へ送信した後の「データ」の「転送」を指すことは明らかである。
また,上記「SDU転送」によりソース基地局とターゲット基地局との間のデータ伝送状態を正確に同期させることができる以上,「SDU転送」とは別個の「状態報告」をソース基地局からターゲットに送信する必然性はないから,上記本願技術事項は発明の詳細な説明から自明に導き出せる事項でもない。

したがって,上記本願技術事項は本願の発明の詳細な説明に記載されていない。

2 平成27年4月1日に提出された意見書における請求人の主張について
平成27年4月1日に提出された意見書における請求人の主張は,要するに,本願明細書の【0027】,【0029】,【0039】等の記載によれば,アップリンク及びダウンリンクの両方向で交換されるPDCPシーケンス番号を含む状態パケットがソースeNodeBとターゲットeNodeBとの間でデータ伝送状態を正確に同期させるために使用されていること,及び,そのような同期をとるためには,ソースeNodeBからターゲットeNodeBにPDCPシーケンス番号を含む状態パケットが伝送されなければならないこと,を明確に記載しているというものである。
確かに,UEとソースeNodeB間で「状態パケット」が交換されるとともにDL送信とUL送信が中止されることで,ソースeNodeBにおいてDLとULで送信済みのPDCP SDUが確定し,その結果,ソースeNodeBはターゲットeNodeBに「SDU転送」を行うだけで両者の間でデータ伝送状態を正確に同期させることができるようになっている。その意味で,請求人の主張する「アップリンク及びダウンリンクの両方向で交換されるPDCPシーケンス番号を含む状態パケットがソースeNodeBとターゲットeNodeBとの間でデータ伝送状態を正確に同期させるために使用されている」点は一応は首肯できるものである。
しかしながら,該主張における「状態パケット」はUEとソースeNodeBとの間で交換されるものであるから,本願技術事項の「ソース基地局」から「ターゲット基地局」へ「送信」される「状態報告」ではあり得ない。そして,上述のとおり,その後の「SDU転送」によりソースeNodeBとターゲットeNodeBはデータ伝送状態を正確に同期させることができるのであるが,該「SDU転送」は上記「1」に述べたとおり,本願技術事項の「状態報告」ではない。
また,上記「SDU転送」によりソース基地局とターゲット基地局との間のデータ伝送状態を正確に同期させることができる以上,これとは別の「状態報告」をソース基地局からターゲット基地局に送信する必然性はないから,上記本願技術事項は発明の詳細な説明から自明に導き出せる事項でもない。

したがって,上記請求人の主張は採用することはできず,上記本願技術事項が本願の発明の詳細な説明に記載されているということはできない。

3 小括
以上のとおりであるから,従属項も含め,本願請求項1?9は本願の明細書に記載されたものではない。

(以下省略)」

そうすると,当審拒絶理由の趣旨は,「ソース基地局」において,「少なくとも1つのPDCPシーケンス番号(Packet Data Convergence Protocol Sequence Number)を含む状態報告」を「生成」し,「ハンドオーバ中に,前記状態報告を,ターゲット基地局へ送信」するという,本願発明に係る構成(以下,この構成を「本願発明構成」という。)は,発明の詳細な説明に記載したものではないので,本願発明は,特許法第36条第6項第1号に規定する要件を満たしていないから,特許を受けることができない,というものである。

第4 当審拒絶理由の判断
以下,当審拒絶理由の判断の妥当性について検討する。
なお,当審拒絶理由においては,<出願日の遡及について>の欄において,出願日の遡及を認めない旨認定しているが,当該認定は確定したものではないので,以降では,出願日の遡及が認められるという前提の下で検討を行う。

(1)発明の詳細な説明及び図面に記載された事項
本願の発明の詳細な説明及び図面には,本願発明構成に関連する,「ハンドオーバ」,「基地局」及び「状態報告」に関し,次のような記載がある。

a.「 【0001】
本発明は,移動通信ネットワーク,限定はしないが,特に3GPP標準規格,又はその等価物若しくは派生物に従って動作するネットワークにおけるデータパケットの管理に関する。
【背景技術】
【0002】
移動通信ネットワークでは,ユーザ装置(UE)が基地局間でハンドオーバすることを要求される。3GPPでは,最近になって,ソースeNodeB(基地局)からターゲットeNodeBへのハンドオーバ(HO)のために制御プレーン(Cプレーン)において規定される手順が提案されている。当然,当業者には,3G通信に適用することができる種々の頭字語がよく知られているが,一般読者の便宜を図るために,用語集が添付される。
【0003】
当業者が効率よく理解できるようにするために,本発明を3Gシステムとの関連で詳細に説明するが,それらのハンドオーバの原理は,他のシステム,たとえば,必要に応じてシステムの対応する構成要素を変更しながら,移動デバイス又はユーザ装置(UE)がいくつかの他のデバイス(eNodeBに対応する)のうちの1つと通信する他のCDMA又は無線システムにも適用することができる。」

b.「【発明の概要】
【0006】
本発明の一態様によれば,ソース基地局であって,
少なくともPDCPシーケンス番号(Packet Data Convergence Protocol Sequence Number)を含む状態報告を生成する生成手段と,
ハンドオーバ中に,前記状態報告を,ターゲット基地局へ送信する送信手段を有し,
前記送信手段は,前記状態報告を送信した後に,前記ターゲット基地局へデータを転送するソース基地局が得られる。
本発明の別の態様によれば,ソース基地局における通信制御方法であって,
少なくともPDCPシーケンス番号(Packet Data Convergence Protocol Sequence Number)を含む状態報告を生成し,
ハンドオーバ中に,前記状態報告を,ターゲット基地局へ送信し,
前記状態報告を送信した後に,前記ターゲット基地局へデータを転送する通信制御方法及びコンピュータプログラムが得られる。(以下省略)」

c.「 【0013】
本発明は,理解するのを容易にするために,3G eNodeB間でのハンドオーバとの関連で説明されるが,それらの原理は,異なるネットワークのノード間,たとえば,3Gネットワークのノードと別のネットワークのノードとの間のハンドオーバにも拡張することができる。」

d.「 【0016】
概説
図1は,移動(セルラー)通信システム1を概略的に示している。該システムにおいて,移動電話(MT)3-0,3-1及び3-2のユーザが,基地局5-1又は5-2のうちの1つ及び電話網7を介して,他のユーザ(図示せず)と通信することができる。この実施形態では,基地局5は,直交周波数分割多元接続(OFDMA)技法を使用しており,移動電話3に送信されることになるデータは複数のサブキャリア上に変調される。移動電話3に送信されることになるデータの量に応じて,各移動電話3に異なるサブキャリアが割り当てられる。移動電話3がソース基地局(たとえば,基地局5-1)のセルからターゲット基地局(たとえば,基地局5-2)に移動するとき,ソース基地局5及びターゲット基地局5,並びに移動電話3においてハンドオーバ(HO)手順(プロトコル)が実行され,ハンドオーバプロセスが制御される。
【0017】
そのハンドオーバプロセスは,以下の要件を伴う,ソース基地局5とターゲット基地局5との間の最適なハードハンドオーバ(HHO)を提供することを目指す。
1.高いTCPスループット性能を達成する,非リアルタイム(NRT)サービスのためのロスレスHHO。
2.終端間でアプリケーションの良好な性能を確保するために,パケットロスを最小限に抑える,リアルタイム(RT)サービスのためのシームレスHHO。
3.無線インタフェースを介しての重複パケット送信の最小化。
4.ユーザプレーンデータのための最低限の中断時間。
5.HO中に,NAS(非アクセス階層)PDUの順次送達が保持されるべきである。
6.重複送達及び非順次送達は,ROHC(ロバストヘッダ圧縮)及びアプリケーションには一切見えないようにすべきである。
【0018】
ハードハンドオーバは,ソフトハンドオーバとは対照的に,ハンドオーバ中に移動電話と基地局との間の無線伝送に中断があるハンドオーバであり,移動電話は,ハンドオーバ手順中に,ソース基地局及びターゲット基地局の両方と無線リンクを確立する。それゆえ,パケットロス及びパケット再送を最小限に抑えながら,ハードハンドオーバを実行するのがさらに難しいことは,当業者には理解されよう。」
(当審注:【0018】の記載のうち「ハードハンドオーバは,ソフトハンドオーバとは対照的に,ハンドオーバ中に移動電話と基地局との間の無線伝送に中断があるハンドオーバであり,移動電話は,ハンドオーバ手順中に,ソース基地局及びターゲット基地局の両方と無線リンクを確立する。」は,「ハンドオーバ」に係る本願の出願時における技術常識及び本願の優先権主張の基礎となる英国特許出願の明細書が記載された英国特許出願公開第2449629号明細書の第6ページ第4-7行の記載「A hard handoover is one where there is a break in radio transmissions between the mobile telephone and the base stations during the handover, as opposed to a soft handover, whrere the mobile telephone will establish a radio link with both the source and target base stations during the handover procedure.」からすると,「ハードハンドオーバは,ソフトハンドオーバ(移動電話は,ハンドオーバ手順中に,ソース基地局及びターゲット基地局の両方と無線リンクを確立する。)とは対照的に,ハンドオーバ中に移動電話と基地局との間の無線伝送に中断があるハンドオーバである。」の誤記と解される。)

e.「 【0019】
基地局
図2は,この実施形態において用いられる基地局5のそれぞれの主な構成要素を例示するブロック図である。図に示されるように,各基地局5はトランシーバ回路21を備えており,該トランシーバ回路は,1つ又は複数のアンテナ23を介して移動端末3に対し信号を送受信するように動作することができ(上述したサブキャリアを用いる),且つネットワークインタフェース25を介して電話網7に対し信号を送受信するように動作することができる。コントローラ27が,メモリ29に格納されるソフトウエアに従って,トランシーバ回路21の動作を制御する。そのソフトウエアは,中でも,オペレーティングシステム31及びダウンリンクスケジューラ33を含む。ダウンリンクスケジューラ33は,移動端末3と通信する際に,トランシーバ回路21によって送信されることになるユーザデータパケットをスケジューリングするように動作することができる。また,そのソフトウエアはハンドオーバモジュール35も備えており,その動作は以下で説明される。」

f.「 【0022】
動作
以下の説明は,UTRANのロングタームエボリューション(LTE)において用いられる用語を使用する。それゆえ,基地局を切り替えつつある移動電話3はUEと呼ばれ,ソース基地局5-1はソースeNodeB(又は単にeNB)と呼ばれ,ターゲット基地局5-2は,ターゲットeNodeBと呼ばれる。LTEにおいて用いられるプロトコルエンティティは,LTEの下で外部ARQエンティティと呼ばれる無線リンク制御(RLC)エンティティを除いて,UMTSにおいて用いられるプロトコルエンティティと同じ名称である。LTEの外部ARQエンティティは,UMTSのRLCエンティティと(全く同一ではないが)概ね同じ機能を有する。」

g.「 【0023】
図4は,UE及びeNodeBにおいて用いられるプロトコルスタックの一部(下位の3つの層)を示す。最初の層は物理層(L1)であり,無線通信チャネルを介してデータを実際に送信するための役割を担う。その上には第2の層(L2)があり,L2は3つの副層,すなわち,無線インタフェースへのアクセスを制御するための役割を担う媒体アクセス制御層(L2/MAC)と,必要に応じて,データパケットの連結及びセグメント化,パケットの応答,及びデータパケットの再送のための役割を担う外部ARQ(自動再送要求)層(L2/OARQ)と,ヘッダ圧縮及び暗号化のための役割を担うPDCP(パケットデータコンバージェンスプロトコル)層(L2/PDCP)とに分割される。第2の層上には,eNodeBとUEとの間の無線インタフェースにおいて用いられる無線資源を制御するための役割を担う無線資源制御(RRC)層(L3/RRC)がある。図に示されるように,L2/外部ARQ層は,Cプレーンデータ及びUプレーンデータの伝送を管理するために用いられる多数の外部ARQエンティティ95を含み,L2/PDCP層は,Cプレーン及びUプレーンデータを処理するために用いられるPDCPエンティティ97を含む。
【0024】
図5は,ダウンリンクデータパケットを処理するときに,PDCPエンティティ97及び外部ARQエンティティ95によって実行される動作を概略的に示す。アップリンクデータパケットの場合にも同じようなプロセスが実行されるが,順序は逆である。図に示されるように,PDCPエンティティ97によって受信されるPDCP SDU(サービスデータユニット)101は最初に,ヘッダ圧縮102を受けて,ヘッダが圧縮されている対応するSDU103が生成される。その後,PDCPエンティティ97は,UEのためのSDUのシーケンス内のそのSDUの番号を特定するシーケンス番号(SN)を生成し,各SDU103に添付する(104)。こうして生成された,SNを有するSDU105は,その後,PDCPバッファ107にバッファリングされる(106)。その後,これらのSDUは,暗号化され(108),暗号化されたPDCP PDU109が生成され,それらは外部ARQエンティティ95に渡されて,そのエンティティにおいて,それらのPDUはセグメント化され,外部ARQ SDUセグメント111が形成される。その後,各外部ARQ SDUセグメントは,対応するPDCP PDU109内で,そのセグメント及びその位置を特定するデータでタグ付けされる。この実施形態では,外部ARQエンティティ95は,PDCPシーケンス番号(SN)と,元のPDCP PDU109内の外部ARQセグメントの位置及び長さを指示するOFFSET及びLENGTHとを再利用する。」

h.「 【0026】
ハンドオーバプロトコルの説明
外部ARQエンティティ(LTEの場合のRLCに相当するもの)は,すべての面において無線リンク制御(RLC)と同一であるとは限らないが,以下に記載される説明は主に,データパケットの受信が受信機によって応答される応答モード(AM)無線リンク制御(RLC)に当てはまる。応答モードエンティティと比べて異なる処理が適用される場合にはいつでも,VoIP及びストリーミングのようなリアルタイムアプリケーションのために利用される非応答モード(UM)外部ARQエンティティの仕様も持ち出される。
【0027】
コンテキストを転送し,データを転送して,ロスレスeNodeB間ハンドオーバを支援するために,ソースeNodeBが,ハンドオーバ中に自らとターゲットeNodeBとの間でデータ伝送状態を同期させることができることが望ましいことを本発明人らは理解している。このことから,本発明者らは,ユーザプレーンデータのための中断時間が最低限であることを考慮に入れて,ハンドオーバ実行段階中の適切な時点において,データフローが中止されるべきであることが望ましいとの結論に達した。しかしながら,付加的なシグナリングを通じてデータ伝送を中止すると,ハンドオーバ時間全体が長くなるという問題を抱えることになるので,この望ましい要件を達成することは簡単ではない。本発明者らは,従来の手法(Cプレーンにおいてのみ実行される)を変更して,ハンドオーバプロセスの或る「実現形態」をユーザプレーンデータ転送プロセスに組み込むことによって,ハンドオーバ実行時に,ソースeNodeB及びUEにおいて(一方又は両方であるが,両方であることが好ましい)データ伝送を暗黙のうちに中止することが可能であることを理解している。さらに望ましい特徴は,ターゲットeNodeBによって,又はUEによって無線で送信される重複パケットの数が最小限に抑えられることである。
【0028】
図6は,上記の変更されたシーケンスの詳細と共に,ダウンリンク(DL)及びアップリンク(UL)においてUプレーンデータ伝送を中止することが提案されるときのタイミングを示す。以下の説明は,データフローを中止するこの手法が,どのようにしてLTEのための高速ロスレスハンドオーバの達成を容易にするかを説明する。
【0029】
図6を参照すると,LTE内アクセス・モビリティ・サポート(Intra-LTE-Access Mobility Support)のための情報フローが記述される。
1)ソースeNodeB内のUEコンテキストは,接続確立時又は直前のTA更新時に与えられるローミング制限に関する情報を含む。
2)ソースeNodeBエンティティは,エリア制限情報に従って,UE測定手順を構成する。ソースeNodeBエンティティによって与えられる測定値は,UEの接続移動性を制御する機能を支援することができる。
3)UE及びソースeNodeBからの測定結果に基づいて,おそらく付加的なRRM特有情報による支援を受けて,ソースeNodeBは,UEをターゲットeNodeBによって制御されるセルにハンドオーバすることを決定する。
4)ソースeNodeBは,ターゲットeNodeBエンティティにハンドオーバ要求を発行し,ターゲット側においてハンドオーバを準備するのに必要な情報を渡す。ターゲットeNodeBは,要求された資源を構成する。
5)ターゲットeNodeBによってそれらの資源を与えられることができる場合には,ハンドオーバが成功する可能性を高めるために,ターゲットeNodeBによって,アドミッション制御が実行される。
6)ターゲットeNodeBにおいてハンドオーバの準備が終了し,UEがターゲットeNodeBに向かう無線経路を再構成するための情報がソースeNodeBに渡される。
7)このステップは,以下のサブステップから成る。
a.下位のプロトコル層にHOコマンドをサブミットする前に,ソースeNodeB内の無線資源制御(RRC)エンティティ96が,外部ARQユーザプレーン(UP)エンティティ95に,ダウンリンク方向において状態パケットを送信し,且つDL送信を中止するように命令して,これらの外部ARQエンティティ95が下位のプロトコル層にいかなるARQ PDUもサブミットしないようにする。UL受信は継続すべきである。受信しているパケットがUM外部ARQ PDUである場合,外部ARQエンティティは,SDUを含む全てのPDUが受信されると直ぐに,SDUを再構築し,それらを上位層に転送する。
b.UEは,ソースeNodeB RRCエンティティ96によって,HOを実行するように命令される。ターゲット側無線資源情報は,その命令(コマンド)に含まれる。
c.HOコマンドを受信すると,UE内のRRCエンティティ96は,外部ARQ Uプレーンエンティティに,アップリンク方向において状態パケットを送信し,且つUL送信を中止するように命令する。それに応答して,ソースeNodeB内のPDCP層は,対応するPDCP SDUを,そのバッファ107から確実に消去する。この後,UEは,ターゲットeNodeBにおいてL1/L2シグナリングを直ちに開始すべきである。
d.両方向において,ユーザプレーンデータ送信が中止され,アップリンク及びダウンリンクの両方において状態パケットが交換されるので,ソースeNodeBは,ソースeNodeBとターゲットeNodeBとの間でデータ伝送状態を正確に同期させることができるようになり,この後の任意の時点から,SDU転送(ソースeNodeBからターゲットeNodeBへ)を開始することができる。
8)UEは,ターゲット側において同期を確立する。
9)UEは,セルにアクセスするのに成功すると,ターゲットeNodeBに,ハンドオーバが完了したことの指示を送信する。
10a)下位層にハンドオーバ完了をサブミットした後に,UE内のRRCエンティティ96は,PDCPエンティティ97及び外部ARQエンティティ95に,UL Uプレーントラフィックを再開するように命令する。
10b)ハンドオーバ完了を受信すると,ターゲットeNodeB内のRRCエンティティ96は,PDCPエンティティ97及び外部ARQ Uプレーンエンティティ95に,DLトラフィックを再開するように命令する。ターゲットeNodeBは,ソースeNodeBから受信した,転送されたDLパケットの送信を開始する。
11)MME/UPEは,UEがセルを変更したことを通知される。UPEは,データ経路をターゲットeNodeBに切り替えて,ソースeNodeBに向かう任意のUプレーン/TNL資源を解放することができる。
12)MME/UPEは,ハンドオーバ完了ACKメッセージによってターゲットeNodeBへのハンドオーバ完了メッセージを確認する。
13)ターゲットeNodeBは,ソース側において,資源の解放を開始する。ターゲットeNodeBは,メッセージ9を受信した直後に,このメッセージを送信することができる。
14)解放資源メッセージを受信すると,ソースeNodeBは,そのUEコンテキストに関連する無線及びCプレーン関連資源を解放する。処理系依存機構が,データ転送を中止することができ,且つUプレーン/TNL資源を解放することができると決定するまで,ソースeNodeBは,データ転送を実行し続ける。
15)新たなセルが,新たなトラッキングエリアのメンバである場合には,UEはMME/UPEで登録する必要があり,それにより,MME/UPEはターゲットeNodeBにおいてエリア制限情報を更新する。
【0030】
外部ARQエンティティの一方向の停止
ハンドオーバ実行時に,ソースeNodeB及びUEにおいてデータ伝送が中止されているため,転送中のデータパケットは,停止されているRLCエンティティによって捨てられることになるので,両方向においてユーザプレーンデータ転送を一時中止する結果として(従来のREL6RLCエンティティの場合のように),データロスが生じることを強調する必要がある。それゆえ,ハードハンドオーバが行なわれることになるLTEシステムの場合,外部ARQエンティティ(RLC)は,送信を中止すべきであるが,いかなるデータロスも避けるために,パケットを受信し続けるべきである。
【0031】
パケット転送
この実施形態において,PDCPシーケンス番号は,ハンドオーバ中に保持され(ターゲットeNodeBによって用いられる),ソースeNodeBは,UEによってターゲットeNodeBに応答されていない全てのダウンリンクPDCP SDU105を(SNと共に)選択的に(バッファ107から)転送し,まだ送信されていない任意の残りのダウンリンク外部ARQ PDUセグメントを捨てる。ハンドオーバ中に,ソースeNodeBは,順序通りに受信するのに成功したアップリンクPDCP SDU105も電話網7(SAEゲートウエイ)に転送し,順序通りに受信されなかったアップリンクPDCP SDU105を,バッファ107からターゲットeNodeBに転送し,任意の残りのアップリンク外部ARQ PDUを捨てる。順序通りに受信されなかったアップリンクPDCP SDUは,ターゲットeNodeB PDCPエンティティ97に転送される前に,PDCPエンティティ97によってアップリンクパケットとしてマークを付され,そのパケットが非順次アップリンクパケットであり,UEに送信するためのダウンリンクパケットではないことをターゲットeNodeBが確認(establish)できるようにする必要がある。その後,欠けているアップリンクパケットがUEから受信されると,ターゲットeNodeB PDCPは,これらの非順次アップリンクパケットを電話網7に転送する。
【0032】
外部ARQエンティティを停止する前に状態PDUを送信する
コンテキストを転送し,データを転送して,ロスレスeNodeB間HOを支援するために,ソースeNodeBは,HO中に,自らとUEとの間のデータ伝送状態を,ターゲットeNodeBと同期させる。これは,ユーザプレーンのための中断時間が最低限であることを考慮に入れて,HO実行段階中の適切な時点においてデータフローを中止することによって容易にされる。一実施形態において,ソースeNodeB内及びUE内の外部ARQエンティティは,適切な方向においてデータフローを中止する前に,他方のエンティティに状態報告(そのデバイスが受信に成功しているものを指示する)を送信する。この状態メッセージは,そのデバイスが受信したものだけを指示する簡単な報告とすることができる。これにより,ソースeNodeB及びUEは,HO実行中に送信を中止する前に,厳密なデータ伝送状態(すなわち,相手が受信したもの,それゆえ,依然として送信されなければならないもの)を知ることができるようになる。それゆえ,HO後に,無線インタフェースを介して重複パケットの送信を一切必要とすることなく,データ送信を再開することができる。
【0033】
好ましい実施形態では,外部ARQ PDU111は(PDCP SN,並びに各外部ARQ PDU111を特定するために必要とされるOFFSET及びLENGTHデータを含むために),必然的にサイズが大きくなり,ハンドオーバを遅らせる場合があるので,ハンドオーバ時に交換される外部ARQ状態報告は,外部ARQ PDU111に基づく状態報告ではなく,PDCPシーケンス番号(SN)を用いる外部ARQ SDU109に基づいている。PDCP SNに基づく状態報告の場合,状態PDUのサイズは,数十バイトの程度まで削減することができ,ハンドオーバの時の高速伝送を容易にする。通常動作中に,外部ARQエンティティは,より小さなサイズのARQ PDUに基づいて,状態PDUを交換することができる。ハンドオーバ中に用いられる状態PDUとは異なり,これらの状態PDUは,より小さなARQ PDUを特定するために必要とされるOFFSET及びLENGTHデータを含むであろう。
(…中略…)
【0039】
さらに,ハンドオーバコマンドがソースeNodeBによって送信された後に,UL及びDLの両方向においてデータの伝送が続く場合には,ソースeNodeBにある送信バッファ及び再送バッファ内のパケットの動的な性質に起因して,ソースeNodeBとターゲットeNodeBとの間のデータ伝送状態を同期させるのが複雑になり,結果として,非リアルタイム(NRT)サービスのためのロスレスハンドオーバを確保するために,DLにおいてターゲットeNodeBによって,且つULにおいてUEによって重複パケットが再送されることになるので,無線インタフェースの帯域幅を非効率的に使用することになる。しかしながら,UMモードを用いるVoIP等のようなリアルタイムサービスの場合,ソースeNodeBによって送信され,ターゲットeNodeBにおいて正確に受信されないデータパケットは,失われることになり,回復することはできない。それゆえ,RT及びNRT両方のサービスのためのデータフローを統一されたやり方で中止することは,NRTベアラの場合に無線インタフェースにおいてより良好に資源を利用するのに有用であり,RTサービスの場合にデータロスを回避することになる。」
(当審注:
【0029】に記載の「d.両方向において,ユーザプレーンデータ送信が中止され,アップリンク及びダウンリンクの両方において状態パケットが交換されるので,ソースeNodeBは,ソースeNodeBとターゲットeNodeBとの間でデータ伝送状態を正確に同期させることができるようになり,この後の任意の時点から,SDU転送(ソースeNodeBからターゲットeNodeBへ)を開始することができる。」は,「ハンドオーバ」に係る本願の出願時における技術常識及び前記英国特許出願公開第2449629号明細書の第11ページ第16-20行の記載「d. Since the user plane data transmission is stopped in both directions and the status packet exchanged in both uplink and downlink, the source eNodeB will be able to accurately synchronize the data transmission status between source and target eNodeBs, and SDU forwarding (from Source eNodeB to target eNodeB) can start from any point after this.」からすると,「d.両方向において,ユーザプレーンデータ送信が中止され,アップリンク及びダウンリンクの両方において状態パケットが交換されているので,ソースeNodeBは,ソースeNodeBとターゲットeNodeBとの間でデータ伝送状態を正確に同期させることができるようになり,この後の任意の時点から,SDU転送(ソースeNodeBからターゲットeNodeBへ)を開始することができる。」の誤記と解される。
また,
【0031】に記載の「この実施形態において,PDCPシーケンス番号は,ハンドオーバ中に保持され(ターゲットeNodeBによって用いられる),ソースeNodeBは,UEによってターゲットeNodeBに応答されていない全てのダウンリンクPDCP SDU105を(SNと共に)選択的に(バッファ107から)転送し,まだ送信されていない任意の残りのダウンリンク外部ARQ PDUセグメントを捨てる。」は,「ハンドオーバ」に係る本願の出願時における技術常識及び前記英国特許出願公開第2449629号明細書の第12ページ第24-28行の記載「In this embodiment, the PDCP sequence numbers are maintained during handover (used by the target eNodeB) and the source eNodeB selectively forwards all downlink PDCP SDUs (with SN) 105 (from the buffer 107) that have not been ackowledged by the UE to the target eNodeB, and discards any remaining downlink Outer ARQ PDU segments that have not been transmitted.」からすると,「この実施形態において,PDCPシーケンス番号は(ターゲットeNodeBによって用いられるため),ハンドオーバ中に維持され,ソースeNodeBは,UEによって応答されていない全てのダウンリンクPDCP SDU105(SNを含む。)を選択的に(バッファ107から)ターゲットeNodeBに転送し,まだ送信されていない任意の残りのダウンリンク外部ARQ PDUセグメントを捨てる。」の誤記と解される。)

i.「

」(図1)

j.「

」(図2)

k.「

」(図5)

l.「

」(図6)

(2)本願発明構成と発明の詳細な説明との対応関係についての検討
前記b.の【0006】には,本願発明構成に対応する事項が記載されているが,当該記載は,【発明の概要】の一部を構成し,特許請求の範囲の実質的な複製にすぎず,発明の詳細な説明のうち,当該記載のみで,本願発明構成と表現上整合しているにすぎない。
そこで,本願発明構成が,発明の詳細な説明と実質的に対応関係があるか否かについて検討する。

ア 本願発明の技術分野及び課題について
前記a.の【0001】ないし【0003】,前記c.の【0013】,前記d.の【0016】,前記f.の【0022】並びに前記i.の図1より,本願発明は,移動通信ネットワーク,とりわけ,3GPPのLTEの規格に関し,ユーザ装置(UE)がソース基地局(eNodeB)からターゲット基地局(eNodeB)へハンドオーバ(HO)することを技術分野としている。(以降,「本願の出願時における技術常識」という場合には,本願の出願時における3GPPのLTEの規格を含むものとする。)
そして,前記d.の【0017】及び【0018】,前記h.の【0027】より,本願発明は,ハンドオーバの中でも,ハードハンドオーバ(HHO)をすることを前提とし,ハンドオーバ中のデータ伝送の中断時間を最小限とし,パケットロス及びパケット再送を最小限にすることを課題としている。

イ ソース基地局(eNodeB)及びターゲット基地局(eNodeB)の構成について
前記e.の【0019】及び前記j.の図2には,基地局(eNodeB)の構成について記載されており,このうち,前記e.の【0019】に記載の「基地局5」は,前記d.の【0016】に記載の「ソース基地局」である「基地局」5-1」と「ターゲット基地局」である「基地局5-2」の両方を指すことは明らかであるから,ソース基地局(eNodeB)とターゲット基地局(eNodeB)との間に構成上の差違があるとは認められない。

ウ 「状態報告」について
「状態報告」の語句は,明細書においては,特許請求の範囲の実質的な複製にすぎない【発明の概要】の欄を除くと,前記h.の【0032】及び【0033】しか記載がない。
そして,【0032】の記載「一実施形態において,ソースeNodeB内及びUE内の外部ARQエンティティは,適切な方向においてデータフローを中止する前に,他方のエンティティに状態報告(そのデバイスが受信に成功しているものを指示する)を送信する。この状態メッセージは,そのデバイスが受信したものだけを指示する簡単な報告とすることができる。これにより,ソースeNodeB及びUEは,HO実行中に送信を中止する前に,厳密なデータ伝送状態(すなわち,相手が受信したもの,それゆえ,依然として送信されなければならないもの)を知ることができるようになる。」,【0033】の記載「好ましい実施形態では,外部ARQ PDU111は(PDCP SN,並びに各外部ARQ PDU111を特定するために必要とされるOFFSET及びLENGTHデータを含むために),必然的にサイズが大きくなり,ハンドオーバを遅らせる場合があるので,ハンドオーバ時に交換される外部ARQ状態報告は,外部ARQ PDU111に基づく状態報告ではなく,PDCPシーケンス番号(SN)を用いる外部ARQ SDU109に基づいている。PDCP SNに基づく状態報告の場合,状態PDUのサイズは,数十バイトの程度まで削減することができ,ハンドオーバの時の高速伝送を容易にする。」から「状態報告」は,ハンドオーバ時に交換され,デバイスが受信に成功しているものを指示する情報であって,具体的には,「PDCPシーケンス番号(SN)」を含むメッセージ(「状態メッセージ」)と解される。そして,「PDCPシーケンス番号(SN)」は,前記g.の【0024】の記載「SDUのシーケンス内のそのSDUの番号を特定するシーケンス番号(SN)」より,「SDUの番号を特定するシーケンス番号(SN)」である。そうすると,「状態報告」とは,デバイスが受信に成功しているSDUを指示するPDCPシーケンス番号(SN)を含むメッセージであるといえる。
そして,前記【0032】の記載「ソースeNodeB内及びUE内の外部ARQエンティティは,適切な方向においてデータフローを中止する前に,他方のエンティティに状態報告(そのデバイスが受信に成功しているものを指示する)を送信する。」及び「これにより,ソースeNodeB及びUEは,…厳密なデータ伝送状態…を知ることができるようになる。」より,「状態報告」は,ソース基地局(eNodeB)とユーザ装置(UE)との間で,データフローを中止する前に,交換(送受信)されるものと解される。
以上から,「状態報告」とは,ハンドオーバ時に,かつ,データフローを中止する前に,ソース基地局(eNodeB)とユーザ装置(UE)との間で送受信される,ソース基地局(eNodeB)又はユーザ装置(UE)が受信に成功しているSDUを指示するPDCPシーケンス番号(SN)を含む状態メッセージ,といえる。

エ ハンドオーバの処理について
前記h.(特に,【0029】)及び前記l.の図6には,ハンドオーバの処理について記載されている。そして,【0029】の記載において,ハンドオーバをすることを決定し,完了までの処理を再掲すると,次のとおりである。

「 4)ソースeNodeBは,ターゲットeNodeBエンティティにハンドオーバ要求を発行し,ターゲット側においてハンドオーバを準備するのに必要な情報を渡す。ターゲットeNodeBは,要求された資源を構成する。
5)ターゲットeNodeBによってそれらの資源を与えられることができる場合には,ハンドオーバが成功する可能性を高めるために,ターゲットeNodeBによって,アドミッション制御が実行される。
6)ターゲットeNodeBにおいてハンドオーバの準備が終了し,UEがターゲットeNodeBに向かう無線経路を再構成するための情報がソースeNodeBに渡される。
7)このステップは,以下のサブステップから成る。
a.下位のプロトコル層にHOコマンドをサブミットする前に,ソースeNodeB内の無線資源制御(RRC)エンティティ96が,外部ARQユーザプレーン(UP)エンティティ95に,ダウンリンク方向において状態パケットを送信し,且つDL送信を中止するように命令して,これらの外部ARQエンティティ95が下位のプロトコル層にいかなるARQ PDUもサブミットしないようにする。UL受信は継続すべきである。受信しているパケットがUM外部ARQ PDUである場合,外部ARQエンティティは,SDUを含む全てのPDUが受信されると直ぐに,SDUを再構築し,それらを上位層に転送する。
b.UEは,ソースeNodeB RRCエンティティ96によって,HOを実行するように命令される。ターゲット側無線資源情報は,その命令(コマンド)に含まれる。
c.HOコマンドを受信すると,UE内のRRCエンティティ96は,外部ARQ Uプレーンエンティティに,アップリンク方向において状態パケットを送信し,且つUL送信を中止するように命令する。それに応答して,ソースeNodeB内のPDCP層は,対応するPDCP SDUを,そのバッファ107から確実に消去する。この後,UEは,ターゲットeNodeBにおいてL1/L2シグナリングを直ちに開始すべきである。
d.両方向において,ユーザプレーンデータ送信が中止され,アップリンク及びダウンリンクの両方において状態パケットが交換されるので,ソースeNodeBは,ソースeNodeBとターゲットeNodeBとの間でデータ伝送状態を正確に同期させることができるようになり,この後の任意の時点から,SDU転送(ソースeNodeBからターゲットeNodeBへ)を開始することができる。
8)UEは,ターゲット側において同期を確立する。
9)UEは,セルにアクセスするのに成功すると,ターゲットeNodeBに,ハンドオーバが完了したことの指示を送信する。」

この中で,ソース基地局(eNodeB)からターゲット基地局(eNodeB)に送信される情報として明記されているのは,前記4)の「ターゲット側においてハンドオーバを準備するのに必要な情報」と,7)のd.の「SDU」のみである。
このうち,前記4)の「ターゲット側においてハンドオーバを準備するのに必要な情報」は,ターゲット基地局(eNodeB)が,要求された資源を構成するために使用される情報であって,ターゲット基地局(eNodeB)が,ハンドオーバ後にユーザ装置(UE)と通信するために必要な資源に関する情報である。そして,当該資源に関する情報が「状態報告」であることは,明細書及び図面には記載も示唆もなく,本願の出願時における技術常識でもない。
また,前記7)の「SDU」は,前記g.の【0024】の記載「SNを有するSDU105」及び図5の記載より,「PDCPシーケンス番号(SN)」を含むものではあるが,「SDU」が「状態報告」であることは,明細書及び図面には記載も示唆もなく,本願の出願時における技術常識でもない。

また,前記7)のd.には,「ソースeNodeBは,ソースeNodeBとターゲットeNodeBとの間でデータ伝送状態を正確に同期させることができるようになり,この後の任意の時点から,SDU転送(ソースeNodeBからターゲットeNodeBへ)を開始することができる。」と記載されているが,ソース基地局(eNodeB)は,どのような手段により自身とターゲット基地局(eNodeB)との間で「データ伝送状態を正確に同期させる」のかについて具体的な記載はない。
また,SDU転送に関し,前記h.の【0031】には,
「この実施形態において,PDCPシーケンス番号は,ハンドオーバ中に保持され(ターゲットeNodeBによって用いられる),ソースeNodeBは,UEによってターゲットeNodeBに応答されていない全てのダウンリンクPDCP SDU105を(SNと共に)選択的に(バッファ107から)転送し,まだ送信されていない任意の残りのダウンリンク外部ARQ PDUセグメントを捨てる。ハンドオーバ中に,ソースeNodeBは,順序通りに受信するのに成功したアップリンクPDCP SDU105も電話網7(SAEゲートウエイ)に転送し,順序通りに受信されなかったアップリンクPDCP SDU105を,バッファ107からターゲットeNodeBに転送し,任意の残りのアップリンク外部ARQ PDUを捨てる。順序通りに受信されなかったアップリンクPDCP SDUは,ターゲットeNodeB PDCPエンティティ97に転送される前に,PDCPエンティティ97によってアップリンクパケットとしてマークを付され,そのパケットが非順次アップリンクパケットであり,UEに送信するためのダウンリンクパケットではないことをターゲットeNodeBが確認(establish)できるようにする必要がある。その後,欠けているアップリンクパケットがUEから受信されると,ターゲットeNodeB PDCPは,これらの非順次アップリンクパケットを電話網7に転送する。」
と記載されている。
この記載によると,ソース基地局(eNodeB)は,ダウンリンクについては,ユーザ装置(UE)によって応答されていないSDUをターゲット基地局(eNodeB)に送信し,アップリンクについては,順序通りに受信されたSDUは,電話網に転送し,順序通りに受信されなかったSDUをマーク付けしてターゲット基地局(eNodeB)に送信し,残りのSDUは廃棄することが記載されている。そうすると,ターゲット基地局(eNodeB)は,「SDU転送」により受信したSDU(SNを含む。)により,未処理のアップリンクSDU及び未処理のダウンリンクSDUを識別できるから,実質的に,ソースeNodeBとの間で,ユーザ装置(UE)との間のデータ伝送状態の同期を図ることができると解される。
そうすると,ソース基地局(eNodeB)は,「SDU転送」により,ターゲット基地局(eNodeB)との間で「データ伝送状態を正確に同期させる」ことを実現していると解するのが合理的である。そして,「SDU転送」が「状態報告」を送信することに対応しないことは,上述したとおりである。

なお,前記h.の【0027】に記載の「コンテキストを転送し,データを転送して,ロスレスeNodeB間ハンドオーバを支援するために,ソースeNodeBが,ハンドオーバ中に自らとターゲットeNodeBとの間でデータ伝送状態を同期させることができることが望ましいことを本発明人らは理解している。」は,ソース基地局(eNodeB)とターゲット基地局(eNodeB)との間でデータ伝送状態を同期させる必要性について説明されているにすぎず,また,前記h.の【0039】に記載の「さらに,ハンドオーバコマンドがソースeNodeBによって送信された後に,UL及びDLの両方向においてデータの伝送が続く場合には,ソースeNodeBにある送信バッファ及び再送バッファ内のパケットの動的な性質に起因して,ソースeNodeBとターゲットeNodeBとの間のデータ伝送状態を同期させるのが複雑になり,結果として,非リアルタイム(NRT)サービスのためのロスレスハンドオーバを確保するために,DLにおいてターゲットeNodeBによって,且つULにおいてUEによって重複パケットが再送されることになるので,無線インタフェースの帯域幅を非効率的に使用することになる。」は,ソース基地局(eNodeB)とターゲット基地局(eNodeB)との間でデータ伝送状態を同期させることの課題を説明しているにすぎず,これらの記載をもって直ちに,発明の詳細な説明に,ソース基地局(eNodeB)からターゲット基地局(eNodeB)に状態報告を送信することが記載されているということはできない。

オ まとめ
前記a.ないしl.により摘記した箇所以外の記載を参酌しても,明細書及び図面には,本願発明構成は記載されておらず,また,本願の出願時における技術常識を参酌しても自明であるとはいえない。
また,前記エで述べたように,ソース基地局(eNodeB)は,「SDU転送」により,ターゲット基地局(eNodeB)との間で「データ伝送状態を正確に同期させる」ことから,さらに「PDCPシーケンス番号(SN)」を含む「状態報告」を送信する必要がないことは明らかである。
したがって,本願の出願時における技術常識に照らしても,本願発明の範囲まで,発明の詳細な説明に開示された内容を拡張ないし一般化できるとはいえない。
よって,本願発明は,発明の詳細な説明に記載したものでない。

(3)平成28年8月26日付けの意見書における主張について
請求人は,平成28年8月26日付けの意見書において,次のような主張をしている。

ア 「 段落0029の7dの記載は,段落0029のステップ6におけるソースeNodeBとターゲットeNodeB間の動作を更に詳細に説明するサブステップを記載したものです。このことは,段落0029のステップ6の記載からも明らかです。更に,段落0029の7dは,ソースeNodeBとターゲットeNodeB間に示された図6の7dとも対応しています。このことからも,段落0029の7dの記載は,ソースeNodeBとターゲットeNodeBとの間の動作を記載していることは明白です。
ここで,本願明細書段落0029における7dの記載を正確に引用しますと,『d.両方向において,ユーザプレーンデータ送信が中止され,アップリンク及びダウンリンクの両方において状態パケットが交換されるので,ソースeNodeBは,ソースeNodeBとターゲットeNodeBとの間でデータ伝送状態を正確に同期させることができるようになり,この後の任意の時点から,SDU転送(ソースeNodeBからターゲットeNodeBへ)を開始することができる。』と記載されています。
まず,上記引用箇所における『両方向』とは,ソースeNodeBとターゲットeNodeBとの間の両方向であることは,図6の7dがソースeNodeBとターゲットeNodeBとの間の動作として記載されていることからも明らかです。即ち,段落0029の記載は,ソースeNodeBとターゲットeNodeBとの間の両方向において,データ送信が中止され,代わりに状態パケットがソースeNodeBとターゲットeNodeBとの間で交換されることを明記しております。
更に,段落0029の前段における『アップリンク及びダウンリンクの両方』とは,ソースeNodeB及びターゲットeNodeBにおけるアップリンク方向及びダウンリンク方向の両方向の意味であることは,段落0029における7d以外の7a-7cの記載からも明らかです。
また,段落0029の前段における『状態パケット』は本願技術事項における「状態報告」であることは明らかですし,更に,状態パケット交換後,ソースeNodeBからターゲットeNodeBへSDU転送が実行されることも記載しております。
拒絶理由通知書における認定では,『段落0029の「SDU転送」が「状態報告」ではなく,データ転送を指すことは明らかである。』とのことです。
しかし,この認定は,段落0029の前段における『d.両方向において,ユーザプレーンデータ送信が中止され,アップリンク及びダウンリンクの両方において状態パケットが交換される』の記載を全く無視した認定であり,明らかに誤った認定であります。」

イ 「 また,拒絶理由通知書では,『SDU転送』とは別個の『状態報告』をソース基地局からターゲットに送信する必然性はないとの御指摘です。
しかし,本願明細書段落0033における『PDCP SNに基づく状態報告の場合,状態PDUのサイズは,数十バイトの程度まで削減することができ,ハンドオーバの時の高速伝送を容易にする。』との記載からも明らかな通り,ハンドオーバ(特にハードハンドオーバ)の時の状態報告を高速で行うことができるという利点があります。よって,拒絶理由通知書における認定は,本願発明に係る明細書の記載を誤解したことに基づく誤った認定でありますので,取り消されるべきものであります。

ウ 「 また,拒絶理由通知書では,本願明細書の【図6】の7dにおける記載「ソースeNodeBがターゲットeNodeBにパケットを転送し始める」が引用されていますが,段落0029の前段の記載『d.両方向において,ユーザプレーンデータ送信が中止され,アップリンク及びダウンリンクの両方において状態パケットが交換されるので,ソースeNodeBは,ソースeNodeBとターゲットeNodeBとの間でデータ伝送状態を正確に同期させることができるようになり,この後の任意の時点から,SDU転送(ソースeNodeBからターゲットeNodeBへ)を開始することができる。』について何ら引用されておりません。
よって,拒絶理由通知書の認定は,段落0029の記載の一部のみを引用して,他の記載について言及されておりませんので,審理が尽くされているとは考えられません。」

上記各主張について,以下,検討する。
(ア)主張アについて
(ア-1)ステップ6と,ステップ7a.ないし7c.との関係について
請求人は,「段落0029の7dの記載は,段落0029のステップ6におけるソースeNodeBとターゲットeNodeB間の動作を更に詳細に説明するサブステップを記載したものです。このことは,段落0029のステップ6の記載からも明らかです。」と主張している。
しかしながら,明細書の段落【0029】に記載の「6)ターゲットeNodeBにおいてハンドオーバの準備が終了し,UEがターゲットeNodeBに向かう無線経路を再構成するための情報がソースeNodeBに渡される。」及び図6の「6.HO応答」からして,ステップ6は,ターゲット基地局(eNodeB)が,「HO応答」として,UEがターゲット基地局(eNodeB)に向かう無線経路を再構成するための情報を,ソース基地局(eNodeB)に送信する処理に関するものである。
一方,明細書の段落【0029】及び図6の記載によれば,後続のステップ7a.は,ソース基地局(eNodeB)が,ダウンリンク方向に状態パケットを送信し,DL送信(ダウンリンクの送信)を中止する処理に関するものであり,ステップ7b.は,ソース基地局(eNodeB)が,ユーザ装置(UE)に対してハンドオーバを実行する命令(HOコマンド)を送信する処理に関するものであり,ステップ7c.は,ユーザ装置(UE)が,HOコマンドを受信して,アップリンク方向に状態パケットを送信し,UL送信(アップリンクの送信)を中止する処理に関するものであるから,ステップ7a.ないし7c.はいずれも,ステップ6の処理(UEがターゲット基地局(eNodeB)に向かう無線経路を再構成するための情報を,ソース基地局(eNodeB)に送信する処理)と関連しないことが明らかである。そして,ステップ7a.ないし7d.は,そのナンバリングから,同種の処理に関係することが明らかであるから,ステップ7d.のみが,ステップ6に関連するもの,すなわち,ステップ6におけるソース基地局(eNodeB)とターゲット基地局(eNodeB)間の動作を更に詳細に説明するサブステップであるということはできない。
そうすると,明細書の段落【0029】に記載の「7)このステップは,以下のサブステップから成る。」における「このステップ」は,前段のステップ6を指すのではなく,直前の数字「7」に係るステップすなわちステップ7を指すと解するのが合理的である。

(ア-2)「両方向」の解釈について
さらに,請求人は,
「 ここで,本願明細書段落0029における7dの記載を正確に引用しますと,『d.両方向において,ユーザプレーンデータ送信が中止され,アップリンク及びダウンリンクの両方において状態パケットが交換されるので,ソースeNodeBは,ソースeNodeBとターゲットeNodeBとの間でデータ伝送状態を正確に同期させることができるようになり,この後の任意の時点から,SDU転送(ソースeNodeBからターゲットeNodeBへ)を開始することができる。』と記載されています。
まず,上記引用箇所における『両方向』とは,ソースeNodeBとターゲットeNodeBとの間の両方向であることは,図6の7dがソースeNodeBとターゲットeNodeBとの間の動作として記載されていることからも明らかです。即ち,段落0029の記載は,ソースeNodeBとターゲットeNodeBとの間の両方向において,データ送信が中止され,代わりに状態パケットがソースeNodeBとターゲットeNodeBとの間で交換されることを明記しております。」と主張している。
まず,「『両方向』とは,ソースeNodeBとターゲットeNodeBとの間の両方向である」との認定が正しければ,「両方向において,ユーザプレーンデータ送信が中止され」るための前提として,ソース基地局(eNodeB)とターゲット(eNodeB)との間で「ユーザプレーンデータ送信」がなされている必要がある。
しかしながら,明細書及び図面には,ソース基地局(eNodeB)とターゲット(eNodeB)との間で「ユーザプレーンデータ送信」がなされることは記載されていない。また,「ユーザプレーンデータ送信」がなされるのは,基地局(eNodeB)とユーザ装置(UE)との間であることは,本願の出願時における技術常識であることから,ソース基地局(eNodeB)とターゲット(eNodeB)との間で「ユーザプレーンデータ送信」がなされることは自明ではない。
また,前記「(2)本願発明構成と発明の詳細な説明との対応関係についての検討」の「イ ソース基地局(eNodeB)及びターゲット基地局(eNodeB)の構成について」の項で述べたように,本願の明細書及び図面の記載において,ソース基地局(eNodeB)とターゲット基地局(eNodeB)との間に構成上の差違があるとは認められないから,いずれか一方の基地局(eNodeB)がユーザ装置(UE)として動作するなどして,他方の基地局(eNodeB)との間で「ユーザプレーンデータ送信」がなされるといった特別な事情が存在するとは認められない。
そして,明細書の段落【0029】には,ステップ7a.において,ソース基地局(eNodeB)が,DL送信の中止を外部ARQユーザプレーンエンティティに命令し,ステップ7c.において,ユーザ装置(UE)が,UL送信の中止を外部ARQユーザプレーンエンティティに命令することが記載されており,DL送信が,ユーザプレーンのダウンリンク送信であること,UL送信が,ユーザプレーンのアップリンク送信であることは自明である。そうすると,明細書の段落【0029】に記載の「両方向において,ユーザプレーンデータ送信が中止されとは,ステップ7a.におけるDL送信の中止,及び,ステップ7c.におけるUL送信の中止を意味することは明らかである。

(ア-3)「状態パケット」について
さらに,請求人は,
「即ち,段落0029の記載は,ソースeNodeBとターゲットeNodeBとの間の両方向において,データ送信が中止され,代わりに状態パケットがソースeNodeBとターゲットeNodeBとの間で交換されることを明記しております。」とも主張している。
ここで,「状態パケット」の語句は,明細書においては,特許請求の範囲の実質的な複製にすぎない【発明の概要】の欄を除くと,段落【0029】にしか記載がなく,ここでは,ステップ7a.において,ソース基地局(eNodeB)が,ダウンリンク方向に状態パケットを送信することが記載され,ステップ7c.において,ユーザ装置(UE)が,アップリンク方向に状態パケットを送信することが記載されている。
そうすると,段落【0029】のステップ7d.の項目に記載されている「アップリンク及びダウンリンクの両方において状態パケットが交換される」は,ステップ7a.のソース基地局(eNodeB)によるダウンリンク方向での状態パケットの送信,及び,ステップ7c.のユーザ装置(UE)によるアップリンク方向での状態パケットの送信を意味すると解するのが合理的である。

(ア-4)「SDU転送」が「状態報告」ではないとの認定について
さらに,請求人は,
「 拒絶理由通知書における認定では,「段落0029の『SDU転送』が『状態報告』ではなく,データ転送を指すことは明らかである。」とのことです。
しかし,この認定は,段落0029の前段における『d.両方向において,ユーザプレーンデータ送信が中止され,アップリンク及びダウンリンクの両方において状態パケットが交換される』の記載を全く無視した認定であり,明らかに誤った認定であります。」とも主張している。
しかしながら,前記(ア-1)ないし(ア-3)において述べたように,段落【0029】に記載の「d.両方向において,ユーザプレーンデータ送信が中止され,アップリンク及びダウンリンクの両方において状態パケットが交換される」は,ソース基地局(eNodeB)とユーザ装置(UE)との間の送受信に関する事項を特定するものであって,請求人が主張するように,ソース基地局(eNodeB)とターゲット基地局(eNodeB)との間の送受信に関する事項を特定したものではない。
また,段落【0029】に記載の「SDU転送」が「状態報告」ではないことは,前記「(2)本願発明構成と発明の詳細な説明との対応関係についての検討」の「エ ハンドオーバの処理について」の項で述べたとおりである。

以上のとおり,主張アは,採用することができない。

(イ)主張イについて
明細書の段落【0033】には,外部ARQ PDU基づく状態報告は,PDCPシーケンス番号(SN)のみならず,OFFSET,LENGTHといった情報を含むため,サイズが大きくなるのに対し,外部ARQ SDUに基づく状態報告は,PDCPシーケンス番号(SN)のみですむために,高速化が実現できるという趣旨のことが記載されているが,当該外部ARQ SDUに基づく状態報告が,ソース基地局(eNodeB)からターゲット基地局(eNodeB9)に送信されることは記載されていない。
よって,主張イは,採用することができない。

(ウ)主張ウについて
当審拒絶理由の「1 本願明細書の記載箇所について」の項において,段落【0029】の記載のうち,「d.両方向において,ユーザプレーンデータ送信が中止され,アップリンク及びダウンリンクの両方において状態パケットが交換されるので,ソースeNodeBは,ソースeNodeBとターゲットeNodeBとの間でデータ伝送状態を正確に同期させることができるようになり,この後の任意の時点から,SDU転送(ソースeNodeBからターゲットeNodeBへ)を開始することができる。」の部分を引用しており,当該記載部分を検討の対象としていることは明らかである。
また,当該部分のうち,「両方向において,ユーザプレーンデータ送信が中止され,アップリンク及びダウンリンクの両方において状態パケットが交換される」は,前記「主張アについて」の項で説示したように,同じ段落【0029】に記載されたステップ7a.及びステップ7b.に関する記載から,ソース基地局(eNodeB)からターゲット基地局(eNodeB)への送信とは無関係であり,また,「両方向において,ユーザプレーンデータ送信が中止され,アップリンク及びダウンリンクの両方において状態パケットが交換される」の部分が,ソース基地局(eNodeB)からターゲット基地局(eNodeB)への送信に関する事項であることは,平成28年8月26日付けの意見書において初めて請求人が主張した事項であって,平成27年4月1日付けの意見書においては主張がなされていなかった。
また,本願発明が発明の詳細な説明に記載されているか否かを判断するにあたり,本願発明と関係のないことが明らかであるところまで,かつ,請求人が主張していないところまで,細部にわたって引用し説示する必要はないから,当審拒絶理由が,審理を尽くしていないとはいえない。
よって,主張イは,採用することができない。

したがって,請求人の主張は,いずれも採用することができない。

(4)出願日の遡及について
本願発明は,分割出願の基礎となる出願(特願2009-545756号,特願2012-124971号)の出願当初の明細書,特許請求の範囲または図面に記載した事項の範囲内にもない。
よって,本願は,分割出願の要件を満たしていないから,出願日の遡及を認めない。

第5 むすび
以上のとおり,本願発明は,特許法第36条第6項第1号に規定する要件を満たしていないから,特許を受けることができない。
したがって,本願は,その余の特許要件に論及するまでもなく拒絶すべきものである。
よって,結論のとおり審決する。
 
審理終結日 2016-10-14 
結審通知日 2016-10-19 
審決日 2016-11-02 
出願番号 特願2014-92445(P2014-92445)
審決分類 P 1 8・ 537- WZ (H04W)
最終処分 不成立  
前審関与審査官 ▲高▼橋 真之伊東 和重  
特許庁審判長 大塚 良平
特許庁審判官 萩原 義則
林 毅
発明の名称 ハンドオーバ処理  
代理人 松田 順一  
代理人 佐々木 敬  
代理人 池田 憲保  

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