拒絶査定不服の審決｜不服2016-15325 - 特許審決データベース

会員機能

ランキング

請求人別審判件数

判例データベース

審決データベース

ポートフォリオ機能

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

この審決の個人情報、企業機密に関する修正依頼をする

PDF	PDFをダウンロード

審決分類	審判査定不服 1項3号刊行物記載特許、登録しない(前置又は当審拒絶理由) H04W 審判査定不服 2項進歩性特許、登録しない(前置又は当審拒絶理由) H04W
管理番号	1343576
審判番号	不服2016-15325
総通号数	226
発行国	日本国特許庁(JP)
公報種別	特許審決公報
発行日	2018-10-26
種別	拒絶査定不服の審決
審判請求日	2016-10-12
確定日	2018-08-23
事件の表示	特願2015-524585「ユーザ機器コンテキストの識別方法,ユーザ機器及び基地局」拒絶査定不服審判事件〔平成26年 2月 6日国際公開,WO2014/019138,平成27年 8月13日国内公表,特表2015-523824〕について,次のとおり審決する。
結論	本件審判の請求は,成り立たない。
理由	1 手続の経緯・本願発明本願は,2012年7月31日を国際出願日とする出願であって,平成28年3月18日付けで拒絶理由が通知され,同年5月27日に意見書及び手続補正書が提出され,同年7月5日付けで拒絶査定がされ,これに対し,同年10月12日に拒絶査定不服審判が請求され,その後,当審において平成29年10月6日付けで拒絶理由が通知され,同年11月16日に意見書及び手続補正書が提出され,平成30年3月2日付けで拒絶理由(以下,「当審拒絶理由」という。)が通知され,同年4月27日に意見書及び手続補正書が提出されたものである。本願の請求項に係る発明は,平成30年4月27日に手続補正された特許請求の範囲の請求項1ないし9に記載された事項により特定されるものと認められるところ,その請求項1に係る発明(以下,「本願発明」という。)は,以下のとおりのものである。「第2の基地局から第1の基地局へハンドオーバを行うユーザ機器のコンテキストの識別方法であって, 前記第1の基地局は,前記ユーザ機器の第1の端末識別子を取得するステップであって,前記第1の端末識別子は,接続失敗が発生した後で前記ユーザ機器によりネットワーク側に送信される,ステップと, 前記第1の基地局は,前記第1の端末識別子が前記第1の基地局により前記ユーザ機器に割り当てられ,或いは前記第1の基地局に対応すると判断された場合,前記第1の端末識別子に基づいて,前記ユーザ機器のコンテキストから前記第2の基地局に対応する第2の端末識別子を検索するステップと, 前記第1の基地局は,前記第2の基地局に前記第2の端末識別子に基づいて前記ユーザ機器のコンテキストを検索させるように,前記第2の基地局に前記第2の端末識別子を含むハンドオーバ報告を送信するステップと,を含む,ユーザ機器コンテキストの識別方法。」 2 拒絶の理由当審拒絶理由は,「理由1(新規性)この出願の下記の請求項に係る発明は,その出願前に日本国内又は外国において頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明であるから,特許法第29条第1項第3号に該当し,特許を受けることができない。」,「理由2(進歩性)この出願の下記の請求項に係る発明は,その出願前に日本国内又は外国において頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて,その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから,特許法第29条第2項の規定により特許を受けることができない。」というものであり,請求項1に対して引用例1,5,6が提示されているところ,主引用例は引用例1であり,引用例5,6は引用例1の記載内容を確認するためのものである。＜引用文献等一覧＞ 1.3GPP TSG-RAN WG3 Meeting #75 R3-120399,Nokia Siemens Networks,The way forward for intra-LTE MRO enhancements(掲載日2012年2月10日)＜URL:http://www.3gpp.org/ftp/tsg_ran/WG3_Iu/TSGR3_75/docs/R3-120399.zip＞ 5.3GPP TSG-RAN WG3 Meeting #75 R3-120309,Ericsson,Offline discussion on MRO Enhancements for Release11(掲載日2012年1月31日)＜URL:http://www.3gpp.org/ftp/tsg_ran/WG3_Iu/TSGR3_75/docs/R3-120309.zip＞ 6.3GPP TSG-RAN WG3 Meeting #75 R3-120197,LG Electronics Inc.,Discussion on HetNet intra LTE failure cases(掲載日2012年1月31日)＜URL:http://www.3gpp.org/ftp/tsg_ran/WG3_Iu/TSGR3_75/docs/R3-120197.zip＞ 3 引用発明当審拒絶理由に引用された3GPP TSG-RAN WG3 Meeting #75 R3-120399,Nokia Siemens Networks,The way forward for intra-LTE MRO enhancements([当審仮訳]:イントラLTE MRO強化のための方法)(掲載日:2012年2月10日)＜URL:http://www.3gpp.org/ftp/tsg_ran/WG3_Iu/TSGR3_75/docs/R3-120399.zip＞(以下,「引用例1」という。)には,図面とともに以下の事項が記載されている。「Solution 3: Add CRNTI (and other required information if any) in UE RLF Report (and HO Report) to allow at the eNB matching of stored UE contexts to failure events At handover, the source cell may store selected UE related information together with the CRNTI(1) used in the cell before HO and additional information, for example X2APID(1). The target cell also stores the same CRNTI(1) and the X2APID(1) together with the UE context. If the UE send the RLF report triggered at RRC re-establishment, the last serving eNB receives the CRNTI(2) used before the failure in the RLF indication message and can thereafter retrieve any information stored for this UE. If the UE send the RLF report triggered at RRC connection setup, the UE includes the CRNTI(2) used before the failure and additional information, for example the shortMAC-I(2) in the RLF report. This is forwarded in the RLF indication to the last serving cell which can thereafter retrieve any information stored for this UE. When this information is retrieved the CRNTI(1) and X2APID(1) can be included in the HO report message. The eNB receiving the HO report message can thereafter retrieve any stored information related to this UE.」(2/2ページ7?18行) ([当審仮訳]: 解決策3:UE RLF報告(及びHO報告)にCRNTI(及び必要があればその他の必要な情報)を追加して,eNBにおけるストアされたUEコンテキストの失敗イベントに対するマッチングを可能とする。ハンドオーバにおいて,ソースセルは,選択されたUE関連情報を,HO前にセルにおいて使用されていたCRNTI(1)及び例えばX2APID(1)といった追加情報とともにストアすることができる。ターゲットセルもまた,同じCRNTI(1)及びX2APID(1)を,UEコンテキストとともにストアすることができる。UEがRRC再確立をトリガとしてRLF報告を送信する場合,最後のサービングeNBは,失敗の前に使用されていたCRNTI(2)をRLF表示メッセージで受信し,それ以後,このUEのためにストアされていた任意の情報を検索することができる。UEがRRC接続セットアップをトリガとしてRLF報告を送信する場合,UEは,失敗前に使用されていたCRNTI(2)及び例えばショートMAC-I(2)といった追加情報をRLF報告に含める。これはRLF表示で最後のサービングセルに転送され,当該セルはそれ以後このUEのためにストアされていたいかなる情報をも検索することができる。この情報が検索されると,HO報告メッセージにCRNTI(1)及びX2APID(1)を含めることができる。HO報告メッセージを受信したeNBは,それ以後ストアされたこのUEに関連する任意の情報を検索することができる。) 引用例1の上記記載及びこの分野における技術常識を考慮すると, (i) CRNTI(Cell Radio Network Temporary Identity )が,セル(eNB)からUEに割り当てられる,当該セル固有の一時的な識別子であることは当業者における技術常識であるところ,CRNTI(1)は,HO(ハンドオーバ)前にセルにおいて使用されていたものであるから,ソースセルにより割り当てられたUEに対するセル固有の識別子であるといえる。そして,HO(ハンドオーバ)が成功した後で失敗(RLF:Radio Link Failure)が発生した場合は,失敗直前の「最後のサービングeNB」はターゲットセルであり,「失敗の前に使用されていたCRNTI(2)」は,ターゲットセルにより割り当てられた前記UEに対するセル固有の識別子である場合があることは,当業者に自明である。そして,RLF報告は失敗(RLF:Radio Link Failure)が発生した後でRRC再確立/RRC接続セットアップをトリガとしてUEから送信されるものであるところ,「最後のサービングeNBは,失敗の前に使用されていたCRNTI(2)をRLF表示メッセージで受信し」,「UEは,失敗前に使用されていたCRNTI(2)及び例えばショートMAC-I(2)といった追加情報をRLF報告に含める。これはRLF表示で最後のサービングセルに転送され」との記載によれば,失敗の前に使用されていたCRNTI(2)及びショートMAC-I(2)を含むRLF報告が,失敗が発生した後でUEによりネットワーク側に送信され,これにより最後のサービングeNBといえるターゲットセルはCRNTI(2)及びショートMAC-I(2)を取得することは明らかである。したがって,引用例1には,「ターゲットセルは,前記ターゲットセルにより割り当てられたUEのCRNTI(2)(及びショートMAC-I(2))を取得し,前記CRNTI(2)(及びショートMAC-I(2))を含むRLF報告が,失敗が発生した後で前記UEによりネットワーク側に送信される」ことが記載されていると認められる。 (ii) 「ターゲットセルもまた,同じCRNTI(1)及びX2APID(1)を,UEコンテキストとともにストアすることができる。」の記載によれば,ターゲットセルが,CRNTI(1),X2APID(1)及びUEコンテキストをストアしていることは明らかである。そして,HO(ハンドオーバ)報告メッセージはターゲットセルからソースセルに送信されるものであり,上述のとおり「最後のサービングeNB」はターゲットセルであるから,「最後のサービングeNB」が検索する「このUEのためにストアされていた任意の情報」は,ターゲットセルがストアしている,CRNTI(1),X2APID(1)及びUEコンテキストであると解される。そして,「最後のサービングeNBは,失敗の前に使用されていたCRNTI(2)をRLF表示メッセージで受信し,それ以後,このUEのためにストアされていた任意の情報を検索することができる。」,「UEは,失敗前に使用されていたCRNTI(2)及び例えばショートMAC-I(2)といった追加情報をRLF報告に含める。これはRLF表示で最後のサービングセルに転送され,当該セルはそれ以後このUEのためにストアされていたいかなる情報をも検索することができる。」及び「この情報が検索されると,HO報告メッセージにCRNTI(1)及びX2APID(1)を含めることができる。」との記載によれば,ターゲットセルがソースセルに送信するHO(ハンドオーバ)報告メッセージに含まれるCRNTI(1)及びX2APID(1)は,ターゲットセルが,取得したCRNTI(2)(及びショートMAC-I(2))に基づいて,ストアしたCRNTI(1),X2APID(1)及びUEコンテキストを検索することにより得られたものであると解するのが相当である。したがって,引用例1には,「前記ターゲットセルは,前記CRNTI(2)(及びショートMAC-I(2))に基づいて,前記UEのためにストアされていたCRNTI(1),X2APID(1)及びUEコンテキストを検索し,前記ターゲットセルは,前記ソースセルに前記CRNTI(1)を含むハンドオーバ報告メッセージを送信する」ことが記載されていると認められる。 (iii) 上述のとおりHO(ハンドオーバ)報告メッセージはターゲットセルからソースセルに送信されるものであるから,「HO報告メッセージを受信したeNB」はソースセルといえる。してみると,HO(ハンドオーバ)報告メッセージを受信したeNBが検索する「ストアされたこのUEに関連する任意の情報」とは,ソースセルがハンドオーバにおいてストアした,HO(ハンドオーバ)前にセルにおいて使用されていたCRNTI(1),追加情報及び選択されたUE関連情報と解することができる。そして,CRNTI(1)等が含まれたHO(ハンドオーバ)報告メッセージを受信した以後検索することができるのであるから,ソースセルはHO(ハンドオーバ)報告メッセージに含まれていた少なくともCRNTI(1)に基づいてストアされたこのUEに関連する任意の情報を検索すると解するのが相当である。したがって,引用例1には「前記ソースセルは,ハンドオーバ報告メッセージに含まれていた前記CRNTI(1)に基づいてストアされた前記UEに関連する任意の情報を検索する」ことが記載されていると認められる。そして,ソースセルにおける当該検索は,ソースeNBにおけるストアされたUEコンテキストの失敗イベントに対するマッチングを可能とするものといえるから,引用例1には,「ソースセルからターゲットセルへハンドオーバを行うUEのUEコンテキストの失敗イベントに対するマッチングを可能とする方法」が記載されていると認められる。したがって,引用例1には以下の発明(以下,「引用発明」という。)が記載されているものと認める。「ソースセルからターゲットセルへハンドオーバを行うUEのUEコンテキストの失敗イベントに対するマッチングを可能とする方法であって, 前記ターゲットセルは,前記ターゲットセルにより割り当てられた前記UEのCRNTI(2)(及びショートMAC-I(2))を取得し,前記CRNTI(2)(及びショートMAC-I(2))を含むRLF報告が,失敗が発生した後で前記UEによりネットワーク側に送信され, 前記ターゲットセルは,前記CRNTI(2)(及びショートMAC-I(2))に基づいて,前記UEのためにストアされていたCRNTI(1),X2APID(1)及びUEコンテキストを検索し, 前記ターゲットセルは,前記ソースセルに前記CRNTI(1)を含むハンドオーバ報告メッセージを送信し, 前記ソースセルは,ハンドオーバ報告メッセージに含まれていた前記CRNTI(1)に基づいてストアされた前記UEに関連する任意の情報を検索する,方法。」 4 対比本願発明と引用発明とを対比すると, (i) 本願発明の「ユーザ機器」と引用発明の「UE」は表記が異なるのみであって差異は無い。本願発明は第2の基地局から第1の基地局にハンドオーバするものであり,本願明細書の【0029】のとおり第1の基地局はハンドオーバのターゲット基地局であり第2の基地局はハンドオーバのソース基地局であるから,引用発明の「ターゲットセル」,「ソースセル」は,それぞれ本願発明の「第1の基地局」,「第2の基地局」に相当する。 (ii) 本願明細書の【0002】?【0005】の記載によれば,本願発明の「ユーザ機器のコンテキストの識別」とは,移動性能の最適化に関連して無線リンク障害(RLF:Radio Link Failure)報告に含まれる情報に基づいて基地局にユーザ機器のコンテキストを取得させることを含むものであるといえる。一方,引用例1のタイトル「イントラLTE MRO強化のための方法」の「MRO」がMobility Robustness Optimization,すなわち移動性能の最適化を意味することが自明であるところ,引用発明の「UEコンテキストの失敗イベントに対するマッチング」とは,UE RLF報告により取得した情報に基づいてソースセルでUEに関連する任意の情報を検索可能とすることである。してみると,引用発明の「ソースセルからターゲットセルへハンドオーバを行うUEのUEコンテキストの失敗イベントに対するマッチングを可能とする方法」は,「第2の基地局から第1の基地局へハンドオーバを行うユーザ機器のコンテキストの識別方法」といえる。 (iii) CRNTI(Cell Radio Network Temporary Identity )が,セル(eNB)からUEに割り当てられる,当該セル固有の一時的な識別子であること,ショートMAC-Iが,セルのセキュリティ構成を用いて計算された16個のMAC-Iのビットからなるものであることは,いずれも当業者における技術常識であるから,引用発明の「前記ターゲットセルにより割り当てられた前記UEのCRNTI(2)(及びショートMAC-I(2))」は,「前記第1の基地局により割り当てられ,或いは前記第1の基地局に対応する,前記ユーザ機器の第1の端末識別子」といえる。これは,本願明細書の【0031】,【0034】等の記載によれば,本願発明の「端末識別子」は,セル無線ネットワーク一時識別子(C-RNTI),短い媒体アクセス制御識別子(shortMAC-I),又はC-RNTI及びｓhｏｒｔMAC-Iであってもよいのであるから,整合する解釈である。また,引用発明の「CRNTI(1)」は,本願発明の「第2の基地局に対応する第2の端末識別子」に相当する。 (iv) 引用発明の「失敗」は(RLF:Radio Link Failure)と解されるところ,本願明細書の【0029】,【0030】の記載によれば,本願発明の「接続失敗」は,無線リンク障害(RLF),ハンドオーバ失敗(HOF:Handover Failure),接続失敗後の無線リソース制御(RRC:Radio Resource Control)接続再確立(connection re-establishment)が成功していない場合等を含むものであるから,引用発明の「失敗」は本願発明の「接続失敗」に含まれる。 (v) 上記(i)?(iv)のとおりであるから,両者は,「前記第1の基地局は,前記ユーザ機器の第1の端末識別子を取得するステップであって,前記第1の端末識別子は,接続失敗が発生した後で前記ユーザ機器によりネットワーク側に送信される,ステップ」を含む点で一致している。 (vi) 上記(i)?(iii)のとおりであるから,本願発明の「前記第1の基地局は,前記第1の端末識別子が前記第1の基地局により前記ユーザ機器に割り当てられ,或いは前記第1の基地局に対応すると判断された場合,前記第1の端末識別子に基づいて,前記ユーザ機器のコンテキストから前記第2の基地局に対応する第2の端末識別子を検索するステップ」と,引用発明の「前記ターゲットセルは,前記CRNTI(2)(及びショートMAC-I(2))に基づいて,前記UEのためにストアされていたCRNTI(1),X2APID(1)及びUEコンテキストを検索し」とは,「前記第1の基地局は,前記第1の基地局により前記ユーザ機器に割り当てられた第1の端末識別子に基づいて,前記ユーザ機器のコンテキストから前記第2の基地局に対応する第2の端末識別子を検索するステップ」である限りにおいて一致している。 (vii) 引用発明は「前記ソースセルは,ハンドオーバ報告メッセージに含まれていた前記CRNTI(1)に基づいてストアされた前記UEに関連する任意の情報を検索する」のであるから,ソースセルに検索させるようにハンドオーバ報告メッセージの送信しているということができる。したがって,引用発明の「前記ターゲットセルは,前記ソースセルに前記CRNTI(1)を含むハンドオーバ報告メッセージを送信し,前記ソースセルは,ハンドオーバ報告メッセージに含まれていた前記CRNTI(1)に基づいてストアされた前記UEに関連する任意の情報を検索する」は,本願発明の「前記第1の基地局は,前記第2の基地局に前記第2の端末識別子に基づいて前記ユーザ機器のコンテキストを検索させるように,前記第2の基地局に前記第2の端末識別子を含むハンドオーバ報告を送信するステップ」に相当する。したがって,本願発明と引用発明とは,両者は,以下の点で一致し,また,相違している。 (一致点) 「第2の基地局から第1の基地局へハンドオーバを行うユーザ機器のコンテキストの識別方法であって, 前記第1の基地局は,前記ユーザ機器の第1の端末識別子を取得するステップであって,前記第1の端末識別子は,接続失敗が発生した後で前記ユーザ機器によりネットワーク側に送信される,ステップと, 前記第1の基地局は,前記第1の基地局により前記ユーザ機器に割り当てられた第1の端末識別子に基づいて,前記ユーザ機器のコンテキストから前記第2の基地局に対応する第2の端末識別子を検索するステップと, 前記第1の基地局は,前記第2の基地局に前記第2の端末識別子に基づいて前記ユーザ機器のコンテキストを検索させるように,前記第2の基地局に前記第2の端末識別子を含むハンドオーバ報告を送信するステップと,を含む,ユーザ機器コンテキストの識別方法。」 (相違点) 一致点の「前記第1の基地局は,前記第1の基地局により前記ユーザ機器に割り当てられた第1の端末識別子に基づいて,前記ユーザ機器のコンテキストから前記第2の基地局に対応する第2の端末識別子を検索するステップ」に関し,本願発明は,「前記第1の端末識別子が前記第1の基地局により前記ユーザ機器に割り当てられ,或いは前記第1の基地局に対応すると判断された場合」との条件の下で検索するのに対し,引用発明は「前記ターゲットセルは,前記ターゲットセルにより割り当てられた前記UEのCRNTI(2)(及びショートMAC-I(2))を取得」するものであり,当該検索を行う条件を明示していない点。 5 判断引用発明は,ターゲットセルは,ターゲットセルにより割り当てられたUEのCRNTI(2)(及びショートMAC-I(2))を取得し,取得したCRNTI(2)(及びショートMAC-I(2))に基づいてUEのためにストアされていた情報を検索するのであるから,ターゲットセルにより割り当てられたUEのCRNTI(2)(及びショートMAC-I(2))を取得しなかった場合には,CRNTI(2)(及びショートMAC-I(2))に基づく検索はされないことは自明である。してみると,上記相違点は実質的な相違点ではない。仮にそうでないとしても,無駄な処理を省くことは一般的な課題であるところ,CRNTI(2)を取得していなければCRNTI(2)に基づく検索結果が得られないことは明らかであるから,無駄な検索を省くために,CRNTI(2)(及びショートMAC-I(2))に基づく検索にあたり,取得したCRNTIがターゲットセルによりUEに割り当てられたCRNTI(2)と判断された場合に検索するようにすることは,格別困難なことではなく,適宜なし得ることに過ぎない。そして,本願発明の作用効果も,引用発明に基づいて当業者が予測し得る範囲のものであり,格別なものではない。 (請求人の主張について) 請求人は,平成30年4月27日に提出された意見書において,以下のように主張している。 (i) 「(本発明の特徴2について) 上記の記載内容から分かるように,まず,引用文献1では,「the CRNTI(1) used in the cell before HO」はソース基地局に対応するCRNTIに関するものであり,即ちCRNTI(1)は本発明の「第2の端末識別子」に相当する。引用文献1では,「CRNTI(2) used before the failure」について,ここの「failure」はハンドオーバを行った後にターゲット基地局で発生する失敗である場合があり,即ち,ここの「CRNTI(2)」はターゲット基地局に対応する端末識別子に相当する場合がある。しかし,引用文献1には,UEがターゲット基地局にハンドオーバされてターゲット基地局に障害が発生したした後に,UEがthe last serving eNB(第3の基地局又は次の基地局など)にCRNTI(2)を送信することのみが開示され,接続失敗(例えばUEがターゲット基地局にハンドオーバされなかった)後に,ターゲット基地局がUEにより送信されたターゲット基地局に対応する端末識別子を受信/取得することが開示されていない。なお,本発明の従来技術(例えば引用文献1)に対する改善点としては,例えば,ターゲット基地局は,接続失敗(例えばUEがターゲット基地局にハンドオーバされなかった)後に,UEにより送信されたターゲット基地局に対応する端末識別子を受信/取得してもよい。言い換えれば,ターゲット基地局は,接続失敗の前にターゲット基地局に対応する端末識別子をUEに予め割り当てたので,接続失敗の後にターゲット基地局に対応する端末識別子を受信してもよい。一方,引用文献1には,UEがターゲット基地局にハンドオーバされて,ターゲット基地局がUEにCRNTI(2)を割り当て,ターゲット基地局に障害が発生したした後に,UEがthe last serving eNBにCRNTI(2)を送信することのみが開示され,接続失敗の後に,ターゲット基地局がUEにより送信されたターゲット基地局に対応する端末識別子を受信/取得してもよいことが開示されていない。さらに,引用文献1では,「target cell also stores the same CRNTI(1)」と記載され,即ちtarget cell自身にもCRNTI(1)が保存されているため,target cellがCRNTI(2)に基づいてUEのコンテキストからCRNTI(1)を検索する必要はない。従って,引用文献1には,「前記第1の基地局は,前記第1の端末識別子が前記第1の基地局により前記ユーザ機器に割り当てられ,或いは前記第1の基地局に対応すると判断された場合,前記第1の端末識別子に基づいて,前記ユーザ機器のコンテキストから前記第2の基地局に対応する第2の端末識別子を検索するステップ」という本発明の特徴2について開示がない。」, (ii) 「(本発明の特徴3について) 引用文献1は,「Add CRNTI in UE HO Report」に関するものであり,UEが「HO report message」に含まれているCRNTI(1)を送信し,「The eNB receiving the HO report messagecan thereafter retrieve any stored information related to this UE」ことのみが開示され,ターゲット基地局がソース基地局にハンドオーバ報告を送信することについて開示がない。従って,引用文献1には,本発明の特徴3について開示がない。」, (iii) 「(特徴1?3の組み合わせについて) 本発明は,上記効果を達成するために,特徴1?3の全てを有する必要がある。一方,引用文献1には,本発明の特徴1?3の組み合わせ及びその効果について,開示や示唆がない。」しかしながら,請求人も認めているように,引用例1の「failure」にはハンドオーバを行った後にターゲットセルで発生する失敗であることが含まれており,その場合,CRNTI(2),ショートMAC-I(2)は,ターゲットセルである第1の基地局により割り当てられ,或いは第1の基地局に対応する第1の端末識別子に相当するといえる。そして,本願発明は,ターゲット基地局が接続失敗の前にターゲット基地局に対応する端末識別子をUEに予め割り当てること,接続失敗の後にターゲット基地局に対応する端末識別子を受信すること,は特定されていないから,ハンドオーバを行った後に失敗が生じ第1の基地局に対応する端末識別子を受信することを含むものである。また,本願発明は本願明細書の実施例1に対応するものと認められるところ,「＜実施例1＞本発明の実施例は,ユーザ機器コンテキストの識別方法を提供し,該ユーザ機器は第2の基地局から第1の基地局へハンドオーバを行い,本実施例は第1の基地局側に適用する。」(【0024】),「ユーザ機器は,第2の基地局から第1の基地局へハンドオーバし,例えば無線リンク障害(RLF)又はハンドオーバ失敗(HOF:Handover Failure)などの接続失敗が生じた。」(【0029】)との記載によれば,当該実施例1ではハンドオーバしているのであるから,「UEがターゲット基地局にハンドオーバされなかった」場合は明細書の開示内容に基づかないものである。また,ターゲットセルはCRNTI(1)を保存しているからこそ,CRNTI(2)に基づいてUEのコンテキストからCRNTI(1)を検索し得るのであるから,上記主張は採用できない。更に,CRNTI(2)に基づいてUEのコンテキストからCRNTI(1)を検索するのであるから,受信したRLF表示のCRNTIが CRNTI(2)であるか否かをまず判断することは,格別困難なことではなく,適宜なし得ることに過ぎない。したがって,上記(i) の主張は採用できない。また,eNBはHO報告メッセージを受信するものであるところ,ハンドオーバ報告はターゲット基地局からソース基地局に送信されることが技術常識であるから,上記(ii) の主張は採用できない。更に,引用発明により「eNBにおけるストアされたUEコンテキストの失敗イベントに対するマッチングを可能とする」ことができるのであるから,本願明細書の【0003】に記載された背景技術の問題が解決されることは明らかである。したがって,上記(iii) の主張は採用できない。 6 むすび以上のとおり,本願発明は,引用例1に記載された発明であり,また,引用例1に記載された発明に基づいて当業者が容易に発明をすることができたものであるから,特許法第29条第1項第3号,同条第2項の規定により,特許を受けることができない。よって,結論のとおり審決する。
審理終結日	2018-06-20
結審通知日	2018-06-26
審決日	2018-07-11
出願番号	特願2015-524585(P2015-524585)
審決分類	P 1 8・ 113- WZ (H04W) P 1 8・ 121- WZ (H04W)
最終処分	不成立
前審関与審査官	伊東和重
特許庁審判長	北岡浩
特許庁審判官	羽岡さやか菅原道晴
発明の名称	ユーザ機器コンテキストの識別方法、ユーザ機器及び基地局
代理人	大竹裕明
代理人	高田大輔
代理人	平川明

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