【事件の表示】
　特願２０１５−５２４５８５「ユーザ機器コンテキストの識別方法，ユーザ機器及び基地局」拒絶査定不服審判事件〔平成２６年　２月　６日国際公開，ＷＯ２０１４／０１９１３８，平成２７年　８月１３日国内公表，特表２０１５−５２３８２４〕について，次のとおり審決する。
【結　論】
　本件審判の請求は，成り立たない。
【理　由】
１　手続の経緯・本願発明
　本願は，２０１２年７月３１日を国際出願日とする出願であって，平成２８年３月１８日付けで拒絶理由が通知され，同年５月２７日に意見書及び手続補正書が提出され，同年７月５日付けで拒絶査定がされ，これに対し，同年１０月１２日に拒絶査定不服審判が請求され，その後，当審において平成２９年１０月６日付けで拒絶理由が通知され，同年１１月１６日に意見書及び手続補正書が提出され，平成３０年３月２日付けで拒絶理由（以下，「当審拒絶理由」という。）が通知され，同年４月２７日に意見書及び手続補正書が提出されたものである。
　本願の請求項に係る発明は，平成３０年４月２７日に手続補正された特許請求の範囲の請求項１ないし９に記載された事項により特定されるものと認められるところ，その請求項１に係る発明（以下，「本願発明」という。）は，以下のとおりのものである。
「第２の基地局から第１の基地局へハンドオーバを行うユーザ機器のコンテキストの識別方法であって，
　前記第１の基地局は，前記ユーザ機器の第１の端末識別子を取得するステップであって，前記第１の端末識別子は，接続失敗が発生した後で前記ユーザ機器によりネットワーク側に送信される，ステップと，
　前記第１の基地局は，前記第１の端末識別子が前記第１の基地局により前記ユーザ機器に割り当てられ，或いは前記第１の基地局に対応すると判断された場合，前記第１の端末識別子に基づいて，前記ユーザ機器のコンテキストから前記第２の基地局に対応する第２の端末識別子を検索するステップと，
　前記第１の基地局は，前記第２の基地局に前記第２の端末識別子に基づいて前記ユーザ機器のコンテキストを検索させるように，前記第２の基地局に前記第２の端末識別子を含むハンドオーバ報告を送信するステップと，を含む，ユーザ機器コンテキストの識別方法。」
２　拒絶の理由
　当審拒絶理由は，「理由１（新規性）この出願の下記の請求項に係る発明は，その出願前に日本国内又は外国において頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明であるから，特許法第２９条第１項第３号に該当し，特許を受けることができない。」，「理由２（進歩性）この出願の下記の請求項に係る発明は，その出願前に日本国内又は外国において頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて，その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから，特許法第２９条第２項の規定により特許を受けることができない。」というものであり，請求項１に対して引用例１，５，６が提示されているところ，主引用例は引用例１であり，引用例５，６は引用例１の記載内容を確認するためのものである。
　　　　　　　　　　　　＜引用文献等一覧＞
　１．3GPP TSG-RAN WG3 Meeting #75 R3-120399，Nokia Siemens Networks，The way forward for intra-LTE MRO enhancements（掲載日２０１２年２月１０日)＜URL：http://www.3gpp.org/ftp/tsg_ran/WG3_Iu/TSGR3_75/docs/R3-120399.zip＞ 
　５．3GPP TSG-RAN WG3 Meeting #75 R3-120309，Ericsson，Offline discussion on MRO Enhancements for Release11（掲載日２０１２年１月３１日）＜URL：http://www.3gpp.org/ftp/tsg_ran/WG3_Iu/TSGR3_75/docs/R3-120309.zip＞
　６．3GPP TSG-RAN WG3 Meeting #75 R3-120197，LG Electronics Inc.，Discussion on HetNet intra LTE failure cases（掲載日２０１２年１月３１日）＜URL：http://www.3gpp.org/ftp/tsg_ran/WG3_Iu/TSGR3_75/docs/R3-120197.zip＞
３　引用発明 
　当審拒絶理由に引用された3GPP TSG-RAN WG3 Meeting #75 R3-120399，Nokia Siemens Networks，The way forward for intra-LTE MRO enhancements（［当審仮訳］：イントラＬＴＥ　ＭＲＯ強化のための方法）（掲載日：２０１２年２月１０日）＜ＵＲＬ：http://www.3gpp.org/ftp/tsg_ran/WG3_Iu/TSGR3_75/docs/R3-120399.zip＞（以下，「引用例１」という。）には，図面とともに以下の事項が記載されている。
「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.」（２／２ページ７〜１８行） 
（［当審仮訳］：
解決策３：ＵＥ　ＲＬＦ報告（及びＨＯ報告）にＣＲＮＴＩ（及び必要があればその他の必要な情報）を追加して，ｅＮＢにおけるストアされたＵＥコンテキストの失敗イベントに対するマッチングを可能とする。
　ハンドオーバにおいて，ソースセルは，選択されたＵＥ関連情報を，ＨＯ前にセルにおいて使用されていたＣＲＮＴＩ（１）及び例えばＸ２ＡＰＩＤ（１）といった追加情報とともにストアすることができる。ターゲットセルもまた，同じＣＲＮＴＩ（１）及びＸ２ＡＰＩＤ（１）を，ＵＥコンテキストとともにストアすることができる。ＵＥがＲＲＣ再確立をトリガとしてＲＬＦ報告を送信する場合，最後のサービングｅＮＢは，失敗の前に使用されていたＣＲＮＴＩ（２）をＲＬＦ表示メッセージで受信し，それ以後，このＵＥのためにストアされていた任意の情報を検索することができる。ＵＥがＲＲＣ接続セットアップをトリガとしてＲＬＦ報告を送信する場合，ＵＥは，失敗前に使用されていたＣＲＮＴＩ（２）及び例えばショートＭＡＣ−Ｉ（２）といった追加情報をＲＬＦ報告に含める。これはＲＬＦ表示で最後のサービングセルに転送され，当該セルはそれ以後このＵＥのためにストアされていたいかなる情報をも検索することができる。
　この情報が検索されると，ＨＯ報告メッセージにＣＲＮＴＩ（１）及びＸ２ＡＰＩＤ（１）を含めることができる。ＨＯ報告メッセージを受信したｅＮＢは，それ以後ストアされたこのＵＥに関連する任意の情報を検索することができる。）
　引用例１の上記記載及びこの分野における技術常識を考慮すると， 
(i) ＣＲＮＴＩ（Cell Radio Network Temporary Identity ）が，セル（ｅＮＢ）からＵＥに割り当てられる，当該セル固有の一時的な識別子であることは当業者における技術常識であるところ，ＣＲＮＴＩ（１）は，ＨＯ（ハンドオーバ）前にセルにおいて使用されていたものであるから，ソースセルにより割り当てられたＵＥに対するセル固有の識別子であるといえる。そして，ＨＯ（ハンドオーバ）が成功した後で失敗（ＲＬＦ：Radio Link Failure）が発生した場合は，失敗直前の「最後のサービングｅＮＢ」はターゲットセルであり，「失敗の前に使用されていたＣＲＮＴＩ（２）」は，ターゲットセルにより割り当てられた前記ＵＥに対するセル固有の識別子である場合があることは，当業者に自明である。
　そして，ＲＬＦ報告は失敗（ＲＬＦ：Radio Link Failure）が発生した後でＲＲＣ再確立／ＲＲＣ接続セットアップをトリガとしてＵＥから送信されるものであるところ，「最後のサービングｅＮＢは，失敗の前に使用されていたＣＲＮＴＩ（２）をＲＬＦ表示メッセージで受信し」，「ＵＥは，失敗前に使用されていたＣＲＮＴＩ（２）及び例えばショートＭＡＣ−Ｉ（２）といった追加情報をＲＬＦ報告に含める。これはＲＬＦ表示で最後のサービングセルに転送され」との記載によれば，失敗の前に使用されていたＣＲＮＴＩ（２）及びショートＭＡＣ−Ｉ（２）を含むＲＬＦ報告が，失敗が発生した後でＵＥによりネットワーク側に送信され，これにより最後のサービングｅＮＢといえるターゲットセルはＣＲＮＴＩ（２）及びショートＭＡＣ−Ｉ（２）を取得することは明らかである。
　したがって，引用例１には，「ターゲットセルは，前記ターゲットセルにより割り当てられたＵＥのＣＲＮＴＩ（２）（及びショートＭＡＣ−Ｉ（２））を取得し，前記ＣＲＮＴＩ（２）（及びショートＭＡＣ−Ｉ（２））を含むＲＬＦ報告が，失敗が発生した後で前記ＵＥによりネットワーク側に送信される」ことが記載されていると認められる。
(ii) 「ターゲットセルもまた，同じＣＲＮＴＩ（１）及びＸ２ＡＰＩＤ（１）を，ＵＥコンテキストとともにストアすることができる。」の記載によれば，ターゲットセルが，ＣＲＮＴＩ（１），Ｘ２ＡＰＩＤ（１）及びＵＥコンテキストをストアしていることは明らかである。そして，ＨＯ（ハンドオーバ）報告メッセージはターゲットセルからソースセルに送信されるものであり，上述のとおり「最後のサービングｅＮＢ」はターゲットセルであるから，「最後のサービングｅＮＢ」が検索する「このＵＥのためにストアされていた任意の情報」は，ターゲットセルがストアしている，ＣＲＮＴＩ（１），Ｘ２ＡＰＩＤ（１）及びＵＥコンテキストであると解される。
　そして，「最後のサービングｅＮＢは，失敗の前に使用されていたＣＲＮＴＩ（２）をＲＬＦ表示メッセージで受信し，それ以後，このＵＥのためにストアされていた任意の情報を検索することができる。」，「ＵＥは，失敗前に使用されていたＣＲＮＴＩ（２）及び例えばショートＭＡＣ−Ｉ（２）といった追加情報をＲＬＦ報告に含める。これはＲＬＦ表示で最後のサービングセルに転送され，当該セルはそれ以後このＵＥのためにストアされていたいかなる情報をも検索することができる。」及び「この情報が検索されると，ＨＯ報告メッセージにＣＲＮＴＩ（１）及びＸ２ＡＰＩＤ（１）を含めることができる。」との記載によれば，ターゲットセルがソースセルに送信するＨＯ（ハンドオーバ）報告メッセージに含まれるＣＲＮＴＩ（１）及びＸ２ＡＰＩＤ（１）は，ターゲットセルが，取得したＣＲＮＴＩ（２）（及びショートＭＡＣ−Ｉ（２））に基づいて，ストアしたＣＲＮＴＩ（１），Ｘ２ＡＰＩＤ（１）及びＵＥコンテキストを検索することにより得られたものであると解するのが相当である。
　したがって，引用例１には，「前記ターゲットセルは，前記ＣＲＮＴＩ（２）（及びショートＭＡＣ−Ｉ（２））に基づいて，前記ＵＥのためにストアされていたＣＲＮＴＩ（１），Ｘ２ＡＰＩＤ（１）及びＵＥコンテキストを検索し，前記ターゲットセルは，前記ソースセルに前記ＣＲＮＴＩ（１）を含むハンドオーバ報告メッセージを送信する」ことが記載されていると認められる。
(iii) 上述のとおりＨＯ（ハンドオーバ）報告メッセージはターゲットセルからソースセルに送信されるものであるから，「ＨＯ報告メッセージを受信したｅＮＢ」はソースセルといえる。してみると，ＨＯ（ハンドオーバ）報告メッセージを受信したｅＮＢが検索する「ストアされたこのＵＥに関連する任意の情報」とは，ソースセルがハンドオーバにおいてストアした，ＨＯ（ハンドオーバ）前にセルにおいて使用されていたＣＲＮＴＩ（１），追加情報及び選択されたＵＥ関連情報と解することができる。そして，ＣＲＮＴＩ（１）等が含まれたＨＯ（ハンドオーバ）報告メッセージを受信した以後検索することができるのであるから，ソースセルはＨＯ（ハンドオーバ）報告メッセージに含まれていた少なくともＣＲＮＴＩ（１）に基づいてストアされたこのＵＥに関連する任意の情報を検索すると解するのが相当である。
　したがって，引用例１には「前記ソースセルは，ハンドオーバ報告メッセージに含まれていた前記ＣＲＮＴＩ（１）に基づいてストアされた前記ＵＥに関連する任意の情報を検索する」ことが記載されていると認められる。
　そして，ソースセルにおける当該検索は，ソースｅＮＢにおけるストアされたＵＥコンテキストの失敗イベントに対するマッチングを可能とするものといえるから，引用例１には，「ソースセルからターゲットセルへハンドオーバを行うＵＥのＵＥコンテキストの失敗イベントに対するマッチングを可能とする方法」が記載されていると認められる。
　したがって，引用例１には以下の発明（以下，「引用発明」という。）が記載されているものと認める。
「ソースセルからターゲットセルへハンドオーバを行うＵＥのＵＥコンテキストの失敗イベントに対するマッチングを可能とする方法であって，
　前記ターゲットセルは，前記ターゲットセルにより割り当てられた前記ＵＥのＣＲＮＴＩ（２）（及びショートＭＡＣ−Ｉ（２））を取得し，前記ＣＲＮＴＩ（２）（及びショートＭＡＣ−Ｉ（２））を含むＲＬＦ報告が，失敗が発生した後で前記ＵＥによりネットワーク側に送信され，
　前記ターゲットセルは，前記ＣＲＮＴＩ（２）（及びショートＭＡＣ−Ｉ（２））に基づいて，前記ＵＥのためにストアされていたＣＲＮＴＩ（１），Ｘ２ＡＰＩＤ（１）及びＵＥコンテキストを検索し，
　前記ターゲットセルは，前記ソースセルに前記ＣＲＮＴＩ（１）を含むハンドオーバ報告メッセージを送信し，
　前記ソースセルは，ハンドオーバ報告メッセージに含まれていた前記ＣＲＮＴＩ（１）に基づいてストアされた前記ＵＥに関連する任意の情報を検索する，方法。」
４　対比 
　本願発明と引用発明とを対比すると，
(i) 本願発明の「ユーザ機器」と引用発明の「ＵＥ」は表記が異なるのみであって差異は無い。本願発明は第２の基地局から第１の基地局にハンドオーバするものであり，本願明細書の【００２９】のとおり第１の基地局はハンドオーバのターゲット基地局であり第２の基地局はハンドオーバのソース基地局であるから，引用発明の「ターゲットセル」，「ソースセル」は，それぞれ本願発明の「第１の基地局」，「第２の基地局」に相当する。
(ii) 本願明細書の【０００２】〜【０００５】の記載によれば，本願発明の「ユーザ機器のコンテキストの識別」とは，移動性能の最適化に関連して無線リンク障害（RLF：Radio Link Failure）報告に含まれる情報に基づいて基地局にユーザ機器のコンテキストを取得させることを含むものであるといえる。一方，引用例１のタイトル「イントラＬＴＥ　ＭＲＯ強化のための方法」の「ＭＲＯ」がMobility Robustness Optimization，すなわち移動性能の最適化を意味することが自明であるところ，引用発明の「ＵＥコンテキストの失敗イベントに対するマッチング」とは，ＵＥ　ＲＬＦ報告により取得した情報に基づいてソースセルでＵＥに関連する任意の情報を検索可能とすることである。してみると，引用発明の「ソースセルからターゲットセルへハンドオーバを行うＵＥのＵＥコンテキストの失敗イベントに対するマッチングを可能とする方法」は，「第２の基地局から第１の基地局へハンドオーバを行うユーザ機器のコンテキストの識別方法」といえる。
(iii)　ＣＲＮＴＩ（Cell Radio Network Temporary Identity ）が，セル（ｅＮＢ）からＵＥに割り当てられる，当該セル固有の一時的な識別子であること，ショートＭＡＣ−Ｉが，セルのセキュリティ構成を用いて計算された１６個のＭＡＣ−Ｉのビットからなるものであることは，いずれも当業者における技術常識であるから，引用発明の「前記ターゲットセルにより割り当てられた前記ＵＥのＣＲＮＴＩ（２）（及びショートＭＡＣ−Ｉ（２））」は，「前記第１の基地局により割り当てられ，或いは前記第１の基地局に対応する，前記ユーザ機器の第１の端末識別子」といえる。これは，本願明細書の【００３１】，【００３４】等の記載によれば，本願発明の「端末識別子」は，セル無線ネットワーク一時識別子（C-RNTI），短い媒体アクセス制御識別子（shortMAC-I），又はＣ−ＲＮＴＩ及びｓｈｏｒｔＭＡＣ−Ｉであってもよいのであるから，整合する解釈である。
　また，引用発明の「ＣＲＮＴＩ（１）」は，本願発明の「第２の基地局に対応する第２の端末識別子」に相当する。
(iv) 引用発明の「失敗」は（ＲＬＦ：Radio Link Failure）と解されるところ，本願明細書の【００２９】，【００３０】の記載によれば，本願発明の「接続失敗」は，無線リンク障害（RLF），ハンドオーバ失敗（HOF：Handover Failure），接続失敗後の無線リソース制御（RRC：Radio Resource Control）接続再確立（connection re-establishment）が成功していない場合等を含むものであるから，引用発明の「失敗」は本願発明の「接続失敗」に含まれる。
(v) 上記(i)〜(iv)のとおりであるから，両者は，「前記第１の基地局は，前記ユーザ機器の第１の端末識別子を取得するステップであって，前記第１の端末識別子は，接続失敗が発生した後で前記ユーザ機器によりネットワーク側に送信される，ステップ」を含む点で一致している。
(vi) 上記(i)〜(iii)のとおりであるから，本願発明の「前記第１の基地局は，前記第１の端末識別子が前記第１の基地局により前記ユーザ機器に割り当てられ，或いは前記第１の基地局に対応すると判断された場合，前記第１の端末識別子に基づいて，前記ユーザ機器のコンテキストから前記第２の基地局に対応する第２の端末識別子を検索するステップ」と，引用発明の「前記ターゲットセルは，前記ＣＲＮＴＩ（２）（及びショートＭＡＣ−Ｉ（２））に基づいて，前記ＵＥのためにストアされていたＣＲＮＴＩ（１），Ｘ２ＡＰＩＤ（１）及びＵＥコンテキストを検索し」とは，「前記第１の基地局は，前記第１の基地局により前記ユーザ機器に割り当てられた第１の端末識別子に基づいて，前記ユーザ機器のコンテキストから前記第２の基地局に対応する第２の端末識別子を検索するステップ」である限りにおいて一致している。
(vii) 引用発明は「前記ソースセルは，ハンドオーバ報告メッセージに含まれていた前記ＣＲＮＴＩ（１）に基づいてストアされた前記ＵＥに関連する任意の情報を検索する」のであるから，ソースセルに検索させるようにハンドオーバ報告メッセージの送信しているということができる。
　したがって，引用発明の「前記ターゲットセルは，前記ソースセルに前記ＣＲＮＴＩ（１）を含むハンドオーバ報告メッセージを送信し，前記ソースセルは，ハンドオーバ報告メッセージに含まれていた前記ＣＲＮＴＩ（１）に基づいてストアされた前記ＵＥに関連する任意の情報を検索する」は，本願発明の「前記第１の基地局は，前記第２の基地局に前記第２の端末識別子に基づいて前記ユーザ機器のコンテキストを検索させるように，前記第２の基地局に前記第２の端末識別子を含むハンドオーバ報告を送信するステップ」に相当する。
　したがって，本願発明と引用発明とは，両者は，以下の点で一致し，また，相違している。
（一致点） 
「第２の基地局から第１の基地局へハンドオーバを行うユーザ機器のコンテキストの識別方法であって，
　前記第１の基地局は，前記ユーザ機器の第１の端末識別子を取得するステップであって，前記第１の端末識別子は，接続失敗が発生した後で前記ユーザ機器によりネットワーク側に送信される，ステップと，
　前記第１の基地局は，前記第１の基地局により前記ユーザ機器に割り当てられた第１の端末識別子に基づいて，前記ユーザ機器のコンテキストから前記第２の基地局に対応する第２の端末識別子を検索するステップと，
　前記第１の基地局は，前記第２の基地局に前記第２の端末識別子に基づいて前記ユーザ機器のコンテキストを検索させるように，前記第２の基地局に前記第２の端末識別子を含むハンドオーバ報告を送信するステップと，を含む，ユーザ機器コンテキストの識別方法。」
（相違点）
　一致点の「前記第１の基地局は，前記第１の基地局により前記ユーザ機器に割り当てられた第１の端末識別子に基づいて，前記ユーザ機器のコンテキストから前記第２の基地局に対応する第２の端末識別子を検索するステップ」に関し，本願発明は，「前記第１の端末識別子が前記第１の基地局により前記ユーザ機器に割り当てられ，或いは前記第１の基地局に対応すると判断された場合」との条件の下で検索するのに対し，引用発明は「前記ターゲットセルは，前記ターゲットセルにより割り当てられた前記ＵＥのＣＲＮＴＩ（２）（及びショートＭＡＣ−Ｉ（２））を取得」するものであり，当該検索を行う条件を明示していない点。
５　判断
　引用発明は，ターゲットセルは，ターゲットセルにより割り当てられたＵＥのＣＲＮＴＩ（２）（及びショートＭＡＣ−Ｉ（２））を取得し，取得したＣＲＮＴＩ（２）（及びショートＭＡＣ−Ｉ（２））に基づいてＵＥのためにストアされていた情報を検索するのであるから，ターゲットセルにより割り当てられたＵＥのＣＲＮＴＩ（２）（及びショートＭＡＣ−Ｉ（２））を取得しなかった場合には，ＣＲＮＴＩ（２）（及びショートＭＡＣ−Ｉ（２））に基づく検索はされないことは自明である。
　してみると，上記相違点は実質的な相違点ではない。仮にそうでないとしても，無駄な処理を省くことは一般的な課題であるところ，ＣＲＮＴＩ（２）を取得していなければＣＲＮＴＩ（２）に基づく検索結果が得られないことは明らかであるから，無駄な検索を省くために，ＣＲＮＴＩ（２）（及びショートＭＡＣ−Ｉ（２））に基づく検索にあたり，取得したＣＲＮＴＩがターゲットセルによりＵＥに割り当てられたＣＲＮＴＩ（２）と判断された場合に検索するようにすることは，格別困難なことではなく，適宜なし得ることに過ぎない。
　そして，本願発明の作用効果も，引用発明に基づいて当業者が予測し得る範囲のものであり，格別なものではない。
（請求人の主張について）
　請求人は，平成３０年４月２７日に提出された意見書において，以下のように主張している。
(i) 「（本発明の特徴２について）
　上記の記載内容から分かるように，まず，引用文献１では，「the　CRNTI(1)　used　in　the　cell　before　HO」はソース基地局に対応するCRNTIに関するものであり，即ちCRNTI(1)は本発明の「第２の端末識別子」に相当する。
　引用文献１では，「CRNTI(2)　used　before　the　failure」について，ここの「failure」はハンドオーバを行った後にターゲット基地局で発生する失敗である場合があり，即ち，ここの「CRNTI(2)」はターゲット基地局に対応する端末識別子に相当する場合がある。しかし，引用文献１には，ＵＥがターゲット基地局にハンドオーバされてターゲット基地局に障害が発生したした後に，ＵＥがthe　last　serving　eNB（第３の基地局又は次の基地局など）にCRNTI(2)を送信することのみが開示され，接続失敗（例えばＵＥがターゲット基地局にハンドオーバされなかった）後に，ターゲット基地局がＵＥにより送信されたターゲット基地局に対応する端末識別子を受信／取得することが開示されていない。
　なお，本発明の従来技術（例えば引用文献１）に対する改善点としては，例えば，ターゲット基地局は，接続失敗（例えばＵＥがターゲット基地局にハンドオーバされなかった）後に，ＵＥにより送信されたターゲット基地局に対応する端末識別子を受信／取得してもよい。言い換えれば，ターゲット基地局は，接続失敗の前にターゲット基地局に対応する端末識別子をＵＥに予め割り当てたので，接続失敗の後にターゲット基地局に対応する端末識別子を受信してもよい。
　一方，引用文献１には，ＵＥがターゲット基地局にハンドオーバされて，ターゲット基地局がＵＥにCRNTI(2)を割り当て，ターゲット基地局に障害が発生したした後に，ＵＥがthe　last　serving　eNBにCRNTI(2)を送信することのみが開示され，接続失敗の後に，ターゲット基地局がＵＥにより送信されたターゲット基地局に対応する端末識別子を受信／取得してもよいことが開示されていない。
　さらに，引用文献１では，「target　cell　also　stores　the　same　CRNTI(1)」と記載され，即ちtarget　cell自身にもCRNTI(1)が保存されているため，target　cellがCRNTI(2)に基づいてＵＥのコンテキストからCRNTI(1)を検索する必要はない。
　従って，引用文献１には，「前記第１の基地局は，前記第１の端末識別子が前記第１の基地局により前記ユーザ機器に割り当てられ，或いは前記第１の基地局に対応すると判断された場合，前記第１の端末識別子に基づいて，前記ユーザ機器のコンテキストから前記第２の基地局に対応する第２の端末識別子を検索するステップ」という本発明の特徴２について開示がない。」，
(ii) 「（本発明の特徴３について）
　引用文献１は，「Add　CRNTI　in　UE　HO　Report」に関するものであり，ＵＥが「HO　report　message」に含まれているCRNTI(1)を送信し，「The　eNB　receiving　the　HO　report　messagecan　thereafter　retrieve　any　stored　information　related　to　this　UE」ことのみが開示され，ターゲット基地局がソース基地局にハンドオーバ報告を送信することについて開示がない。
　従って，引用文献１には，本発明の特徴３について開示がない。」，
(iii) 「（特徴１〜３の組み合わせについて）
　本発明は，上記効果を達成するために，特徴１〜３の全てを有する必要がある。一方，引用文献１には，本発明の特徴１〜３の組み合わせ及びその効果について，開示や示唆がない。」
　しかしながら，請求人も認めているように，引用例１の「failure」にはハンドオーバを行った後にターゲットセルで発生する失敗であることが含まれており，その場合，ＣＲＮＴＩ（２），ショートＭＡＣ−Ｉ（２）は，ターゲットセルである第１の基地局により割り当てられ，或いは第１の基地局に対応する第１の端末識別子に相当するといえる。そして，本願発明は，ターゲット基地局が接続失敗の前にターゲット基地局に対応する端末識別子をＵＥに予め割り当てること，接続失敗の後にターゲット基地局に対応する端末識別子を受信すること，は特定されていないから，ハンドオーバを行った後に失敗が生じ第１の基地局に対応する端末識別子を受信することを含むものである。
　また，本願発明は本願明細書の実施例１に対応するものと認められるところ，「＜実施例１＞  本発明の実施例は，ユーザ機器コンテキストの識別方法を提供し，該ユーザ機器は第２の基地局から第１の基地局へ
ハンドオーバを行い
ハンドオーバし
　また，ターゲットセルはＣＲＮＴＩ（１）を保存しているからこそ，ＣＲＮＴＩ（２）に基づいてＵＥのコンテキストからＣＲＮＴＩ（１）を検索し得るのであるから，上記主張は採用できない。
　更に，ＣＲＮＴＩ（２）に基づいてＵＥのコンテキストからＣＲＮＴＩ（１）を検索するのであるから，受信したＲＬＦ表示のＣＲＮＴＩが ＣＲＮＴＩ（２）であるか否かをまず判断することは，格別困難なことではなく，適宜なし得ることに過ぎない。
　したがって，上記(i) の主張は採用できない。
　また，ｅＮＢはＨＯ報告メッセージを受信するものであるところ，ハンドオーバ報告はターゲット基地局からソース基地局に送信されることが技術常識であるから，上記(ii) の主張は採用できない。
　更に，引用発明により「ｅＮＢにおけるストアされたＵＥコンテキストの失敗イベントに対するマッチングを可能とする」ことができるのであるから，本願明細書の【０００３】に記載された背景技術の問題が解決されることは明らかである。したがって，上記(iii) の主張は採用できない。
６　むすび
　以上のとおり，本願発明は，引用例１に記載された発明であり，また，引用例１に記載された発明に基づいて当業者が容易に発明をすることができたものであるから，特許法第２９条第１項第３号，同条第２項の規定により，特許を受けることができない。
　よって，結論のとおり審決する。