2017-003983

特願２０１５－２４５５７８「リンク失敗原因を分析する方法及び装置」拒絶査定不服審判事件〔平成２８年　４月２１日出願公開、特開２０１６－　５９０７３〕について、次のとおり審決する。

【結　論】 本件審判の請求は、成り立たない。

【理　由】 第１　手続の経緯 本願は、２０１２年（平成２４年）１月２０日を国際出願日とする出願である特願２０１４－５５２４７０号の一部を、平成２７年１２月１６日に新たな特許出願としたものであって、平成２８年９月１２日付けで拒絶理由が通知され、同年１１月２１日に意見書及び手続補正書が提出され、同年１２月１２日付けで拒絶査定がされたところ、平成２９年３月１７日に拒絶査定不服審判が請求され、同時に手続補正がされ、前置審査において、同年５月１日付けで拒絶理由が通知され、同年７月１３日に意見書及び手続補正書が提出されたものである。その後、審査官が同年７月２４日付けで作成した前置報告書に対して、同年８月２８日に上申書が提出された。 第２　本願発明 本願の請求項に係る発明は、平成２９年７月１３日に提出された手続補正書により補正された特許請求の範囲の請求項１－７に記載された事項により特定されるものと認められるところ、その請求項１に係る発明（以下、「本願発明」という。）は、以下のとおりのものである。 「　基地局であって、 ユーザ装置のリンクが失敗した後に、且つ前記ユーザ装置が前記基地局とコネクションを成功裏に再確立した後に、前記ユーザ装置が送信した、識別情報を含むリンク失敗報告を受信する受信ユニットであって、前記ユーザ装置に関する前記識別情報は、前記ユーザ装置がリンク失敗を観測した時に所在するセルの基地局における前記ユーザ装置の識別子である、受信ユニット；及び 前記識別情報を含む前記リンク失敗報告を含むリンク失敗指示を、前記ユーザ装置が前記リンク失敗を観測した時に所在する前記セルの前記基地局に送信する送信ユニットを含む、基地局。」 第３　拒絶の理由 平成２９年５月１日付けの拒絶理由の概要は次のとおりのものである。 この出願の請求項１に係る発明は、その出願前に日本国内又は外国において、頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。 １．Ericsson，MRO for HetNet mobility scenarios[online]，3GPP TSG-RAN WG3#73bis，3GPP，２０１１年１０月１４日，R3-112599，検索日[2017.05.01],インターネット＜URL:http://www.3gpp.org/ftp/tsg_ran/WG3_Iu/TSGR3_73bis/Docs/R3-112599.zip＞ ２．MediaTek，RLF report contents[online]，3GPP TSG-RAN WG2#73bis，3GPP，２０１１年　３月１５日，R2-112192，検索日[2017.05.01],インターネット＜URL:http://www.3gpp.org/ftp/tsg_ran/WG2_RL2/TSGR2_73bis/Docs/R2-112192.zip＞ 第４　引用発明と公知技術 １　引用発明 平成２９年５月１日付けの拒絶理由で引用したEricsson，MRO for HetNet mobility scenario（当審仮訳：ＨｅｔＮｅｔ移動シナリオのためのＭＲＯ），3GPP TSG-RAN WG3 #73bis R3-112599，２０１１年１０月１４日（当該日付けは会合の最終日であるが、下記URLから２０１１年１０月１９日にアップデートされたものが入手できる。），インターネット＜URL:http://www.3gpp.org/ftp/tsg_ran/WG3_Iu/TSGR3_73bis/Docs/R3-112599.zip＞（以下、引用例１という。）には、図面とともに、以下の記載がある。（［当審注］：下線は、強調のために当審が付与した。） 「2. MRO support in release 10 Connection failure due to intra-LTE mobility can be due to Too Late Handover, Too Early Handover, or Handover to Wrong Cell [2]. In the case of Too Late Handover, a connection failure occurs in the source cell (before handover is initiated or during the handover) and the UE tries to re-establish a connection in a target cell (if handover was initiated) or in a cell that is not the source cell (if handover was not initiated). （中略） In release 10, the three connection failure types are communicated via the X2: RLF INDICATION and X2: HANDOVER REPORT messages, as illustrated in Figure 1 - Figure 3 [2][3][4]. The X2: RLF INDICATION message contains the following information: - PCI of the cell in which the UE was connected prior to RLF (known as failure cell) - ECGI of the cell where RRC re-establishment attempt was made - C-RNTI of the UE in the failure cell The RLF INDICATION may also contain the following additional information: - MAC ID of the UE in the failure cell - UE RLF report (in a UE RLF Report Container IE) - A flag indicating whether the RLF report is retrieved after an RRC Connection Setup or not Figure 1: Too Late Handover （中略） The UE RLF Report Container IE contains the RLF report that is sent from the UE after RRC Connection Setup or RRC Connection Re-establishment, via the use of UE Information Request and UE Information Response messages. （後略）」（１ページ１７－２ページ３行目） （当審仮訳：「２．リリース１０のＭＲＯサポート ＬＴＥ内移動に起因する接続の失敗は、Ｔｏｏ　Ｌａｔｅ　Ｈａｎｄｏｖｅｒ、Ｔｏｏ　Ｅａｒｌｙ　Ｈａｎｄｏｖｅｒ、又は、Ｈａｎｄｏｖｅｒ　ｔｏ　Ｗｒｏｎｇ　Ｃｅｌｌ［２］によるものである。 Ｔｏｏ　Ｌａｔｅ　Ｈａｎｄｏｖｅｒの場合、（ハンドオーバが開始される前又はハンドオーバ中に、）ソースセルで接続障害が発生し、ＵＥは、（ハンドオーバが開始された場合、）ターゲットセル又は（ハンドオーバが開始されなかった場合、）ソースセルではないセルに接続の再確立を試みる。（中略） リリース１０では、３つの接続障害タイプは、図１－図３　［２］　［３］　［４］に示すように、Ｘ２：ＲＬＦ　ＩＮＤＩＣＡＴＩＯＮメッセージとＸ２：ＨＡＮＤＯＶＥＲ　ＲＥＰＯＲＴメッセージで通信される。 Ｘ２：ＲＬＦ　ＩＮＤＩＣＡＴＩＯＮメッセージには、次の情報が含まれる。 －　ＵＥがＲＬＦより前に接続された（障害セルとして知られている）セルのＰＣＩ －　ＲＲＣの再確立が試みられたセルのＥＣＧＩ －　障害セル内のＵＥのＣ－ＲＮＴＩ ＲＬＦ　ＩＮＤＩＣＡＴＩＯＮには、以下の追加情報も含まれる。 －　障害セル内のＵＥのＭＡＣ　ＩＤ －　（ＵＥ　ＲＬＦ　Ｒｅｐｏｒｔ　Ｃｏｎｔａｉｎｅｒ　ＩＥ内の）ＵＥ　ＲＬＦ　ｒｅｐｏｒｔ －　ＲＲＣ接続セットアップ後にＲＬＦ　ｒｅｐｏｒｔを取得されるかどうかを示すフラグ （図１は省略） （中略） ＵＥ　ＲＬＦ　Ｒｅｐｏｒｔ　Ｃｏｎｔａｉｎｅｒ　ＩＥは、ＵＥ　Ｉｎｆｏｒｍａｔｉｏｎ　ＲｅｑｕｅｓｔやＵＥ　Ｉｎｆｏｒｍａｔｉｏｎ　Ｒｅｓｐｏｎｓｅメッセージの使用を介してＲＲＣ接続セットアップ又はＲＲＣ接続再確立後にＵＥから送信される、ＲＬＦ　ｒｅｐｏｒｔを含む。」 上記摘記事項の記載及び図面並びにこの分野における技術常識を考慮すると、次のことがいえる。 ア　上記摘記事項によれば、ターゲットセルを形成するｅＮＢ（ｅＮＢ－Ｂ）は、ＵＥとソースセルを形成するｅＮＢ（ｅＮＢ－Ａ）との間で接続障害が発生した後に、ＵＥとＲＲＣ接続セットアップ又はＲＲＣ接続再確立後、ＵＥが送信したＲＬＦ　ｒｅｐｏｒｔをＵＥ　Ｉｎｆｏｒｍａｔｉｏｎ　Ｒｅｓｐｏｎｓｅを介して受信するといえる。 そして、ＲＬＦ　ｒｅｐｏｒｔを含むＵＥ　ＲＬＦ　Ｒｅｐｏｒｔ　Ｃｏｎｔａｉｎｅｒ　ＩＥを含むＲＬＦ　ＩＮＤＩＣＡＴＩＯＮは、結局、ＲＬＦ　ｒｅｐｏｒｔを含むＲＬＦ　ＩＮＤＩＣＡＴＩＯＮであるといえるので、ターゲットセルを形成するｅＮＢ（ｅＮＢ－Ｂ）は、障害セル内のＵＥのＣ－ＲＮＴＩに加え当該ＲＬＦ　ｒｅｐｏｒｔを含むＲＬＦ　ＩＮＤＩＣＡＴＩＯＮを、ソースセルを形成するｅＮＢ（ｅＮＢ－Ａ）に送信するといえる。 イ　上記摘記事項によれば、上記アは、リリース１０のＭＲＯ（Ｍｏｂｉｌｉｔｙ　Ｒｏｂｕｓｔｎｅｓｓ　Ｏｐｔｉｍｉｚａｔｉｏｎ）のＴｏｏ　Ｌａｔｅ　Ｈａｎｄｏｖｅｒの場合におけるターゲットセルを形成するｅＮＢの動作であるといえる。 上記ア、イを総合すると、引用例１には、以下の発明（以下、「引用発明」という。）が記載されているものと認められる。 （引用発明） 「　ターゲットセルを形成するｅＮＢであって、 ＵＥとソースセルを形成するｅＮＢの間で接続障害が発生した後に、ＵＥとＲＲＣ接続セットアップ又はＲＲＣ接続再確立後、ＵＥが送信したＲＬＦ　ｒｅｐｏｒｔをＵＥ　Ｉｎｆｏｒｍａｔｉｏｎ　Ｒｅｓｐｏｎｓｅを介して受信し、 障害セル内のＵＥのＣ－ＲＮＴＩに加え当該ＲＬＦ　ｒｅｐｏｒｔを含むＲＬＦ　ＩＮＤＩＣＡＴＩＯＮを、ソースセルを形成するｅＮＢに送信する、ターゲットセルを形成するｅＮＢ。」 ２　公知技術 平成２９年５月１日付けの拒絶理由で引用したMediaTek，RLF report contents（当審仮訳：ＲＬＦ　ｒｅｐｏｒｔ　コンテンツ），3GPP TSG -RAN WG2 #73bis R2-112192，２０１１年３月１５日（当該日付けは会合の最終日であるが、下記URLから２０１１年４月５日にアップデートされたものが入手できる。），インターネット＜URL:http://www.3gpp.org/ftp/tsg_ran/WG2_RL2/TSGR2_73bis/Docs/R2-112192.zip＞（以下、引用例２という。）には、以下の記載がある。（［当審注］：下線は、強調のために当審が付与した。） 「In rel-9 there was a MRO solution that eNB could notify another eNB about a re-establishment attempt using the X2 RLF indication message. This information is additionally enhanced by the UE reported RLF report that can be added in this X2 message, when available. （中略） ・For rel-10, the RLF report is also available at failed RRC re-establishment, e.g. due to eNB not being pre-prepared (should be a quite common case). In all cases of failed RRC re-establishment there would be an immediate NAS recovery, and then RLF report could be delivered by the UE. （中略） The issue: ・After unsuccessful RRC re-establishment the UE establishes a new RRC connection and the eNB/RAN cannot correlate the new RRC connection with a previous one, thus there is no mechanism to correlate such Rel-10 RLF report after new RRC establishment with network observations made for an earlier RRC connection. Thus in order to make RLF report in rel-10, after unsuccessful re-establishment, available to MRO solutions in release-10 it has been proposed that it shall be possible to do such correlation. In order to do Correlation there could be different solutions: a) SOLUTION A: UE provides his re-establishment ID {Cell-ID, CRNTI, and short MAC-I} also in the RLF-report, when RLF report is provided after a fresh RRC establishment. 」（１ページ１２－３３行目） （当審仮訳：「ｒｅｌ－９では、ｅＮＢがＸ２　ＲＬＦ　ｉｎｄｉｃａｔｉｏｎメッセージを使用して再確立試行について他のｅＮＢに通知できるＭＲＯソリューションがあった。この情報は、利用可能な場合、このＸ２メッセージに追加することができる、ＵＥがレポートしたＲＬＦ　ｒｅｐｏｒｔによってさらに強化される。 ・ｒｅｌ－１０の場合、ＲＬＦ　ｒｅｐｏｒｔは、例えば、ｅＮＢが事前準備されていないことによる（非常に一般的なケースであるはずである）、失敗したＲＲＣ接続再確立時にも利用できる。失敗したＲＲＣ接続再確立のすべての場合において、即時のＮＡＳ回復が存在し、ＲＬＦ　ｒｅｐｏｒｔがＵＥによって配信され得る。 （中略） 結果： ・成功しなかったＲＲＣ接続再確立の後、ＵＥは新しいＲＲＣ接続を確立するが、ｅＮＢ／ＲＡＮは新しいＲＲＣ接続を前のＲＲＣ接続と相関させることができないので、新しいＲＲＣ確立後のそのようなＲｅｌ－１０　ＲＬＦ　ｒｅｐｏｒｔを、以前のＲＲＣ接続に対して行われたネットワーク観測と相関させるメカニズムは存在しない。 したがって、ｒｅｌ－１０において、再確立が成功しなかった後、ＲＬＦ　ｒｅｐｏｒｔを、リリース１０のＭＲＯソリューションに利用できるようにするために、そのような相関を行うことが可能であることが提案されている。 相関を行うためには、さまざまな解決方法がある。 ａ）解決策Ａ：新しいＲＲＣ接続確立後にＲＬＦ　ｒｅｐｏｒｔが提供されるとき、ＵＥは、ＲＬＦ　ｒｅｐｏｒｔに再確立ＩＤ｛Ｃｅｌｌ－ＩＤ、ＣＲＮＴＩ、及びｓｈｏｒｔ　ＭＡＣ－Ｉ｝も提供する。」 上記摘記事項の記載及びこの分野における技術常識を考慮すると、次のことがいえる。 上記摘記事項によれば、再確立が成功しなかった後、ＲＬＦ　ｒｅｐｏｒｔを、リリース１０のＭＲＯソリューションに利用できるようにするために、ｅＮＢが「新しいＲＲＣ接続」を「前のＲＲＣ接続」と相関させることができるよう、新しいＲＲＣ接続確立後にＲＬＦ　ｒｅｐｏｒｔが提供されるとき、ＵＥは、ＲＬＦ　ｒｅｐｏｒｔに再確立ＩＤ｛Ｃｅｌｌ－ＩＤ、ＣＲＮＴＩ、及びｓｈｏｒｔ　ＭＡＣ－Ｉ｝も提供するものである。ここで、再確立ＩＤのうちのＣＲＮＴＩは、「新しいＲＲＣ接続」を「前のＲＲＣ接続」と相関させることができるようするためのものであるから、前のＲＲＣ接続の係るものであることは明らかである。 したがって、引用例２には、以下の技術（以下、「公知技術」という。）が記載されているものと認められる。 （公知技術） 「　ｅＮＢが新しいＲＲＣ接続を前のＲＲＣ接続と相関させることができるよう、ＵＥが前のＲＲＣ接続に係るＣＲＮＴＩも含むＲＲＣ　ｒｅｐｏｒｔを配信する。」 第５　対比 本願発明と引用発明とを対比する。 １　引用発明の「ターゲットセルを形成するｅＮＢ」は、「基地局」といえる。 ２　引用発明の「ＵＥとソースセルを形成するｅＮＢの間で接続障害が発生した」ことは、本願発明の「ユーザ装置のリンクが失敗した」ことに含まれる。 また、引用発明の「ＵＥと」「ＲＲＣ接続再確立際後」とは、本願発明の「ユーザ装置が前記基地局とコネクションを成功裏に再確立した後」に相当する。 そして、本願発明の「リンク失敗報告」と引用発明の「ＲＬＦ　ｒｅｐｏｒｔ」とは、表記上の差異にすぎない。 さらに、「ＵＥが送信したＲＬＦ　ｒｅｐｏｒｔをＵＥ　Ｉｎｆｏｒｍａｔｉｏｎ　Ｒｅｓｐｏｎｓｅを介して受信」することは、結局、ＲＬＦ　ｒｅｐｏｒｔを受信するといえ、ターゲットセルを形成するｅＮＢが受信するための手段を含むことは明らかである。 そうすると、引用発明のターゲットセルを形成するｅＮＢの「ＵＥとソースセルを形成するｅＮＢの間で接続障害が発生した後に、ＲＲＣ接続再確立後、ＵＥが送信した、ＲＬＦ　ｒｅｐｏｒｔを含むＵＥ　Ｉｎｆｏｒｍａｔｉｏｎ　Ｒｅｓｐｏｎｓｅを受信」するための手段は、本願発明の「ユーザ装置のリンクが失敗した後に、且つ前記ユーザ装置が前記基地局とコネクションを成功裏に再確立した後に、前記ユーザ装置が送信した、リンク失敗報告を受信する受信ユニット」に相当する。 ３　引用発明の「接続障害が発生した」「ソースセルを形成するｅＮＢ」は、本願発明の「ユーザ装置がリンク失敗を観測した時に所在するセルの基地局」に相当する。また、引用発明の「障害セル」は、接続障害が発生したソースセルである。 そして、「Ｃ－ＲＮＴＩ」は、セルを形成するｅＮＢが割り当てるＵＥの識別子であることは技術常識であるから、引用発明の「障害セル内のＵＥのＣ－ＲＮＴＩ」は、本願発明の「前記ユーザ装置がリンク失敗を観測した時に所在するセルの基地局における前記ユーザ装置の識別子である」「前記ユーザ装置に関する前記識別情報」に相当する。ここで、本願発明は「前記ユーザ装置に関する前記識別情報」を受信ユニットに関連して特定しているが、当該識別情報は、受信ユニットが受信するものであるとともに送信ユニットが送信するものであるから、受信ユニットに関連して特定するか、送信ユニットに関連して特定するか、あるいは独立して特定するかは、単なる表現上の差異に過ぎない。 ４　本願発明の「リンク失敗指示」と引用発明の「ＲＬＦ　ＩＮＤＩＣＡＴＩＯＮ」とは、表記上の差異にすぎない。そうすると、本願発明の「リンク失敗指示」と引用発明の「ＲＬＦ　ＩＮＤＩＣＡＴＩＯＮ」とは、「識別情報及び前記リンク失敗報告を含むリンク失敗指示」である点で共通する。 そして、ターゲットセルを形成するｅＮＢが、ＲＬＦ　ＩＮＤＩＣＡＴＩＯＮを、ソースセルを形成するｅＮＢに送信するための手段を含むことは明らかである。 そうすると、本願発明と引用発明とは、「識別情報及び前記リンク失敗報告を含むリンク失敗指示を、前記ユーザ装置が前記リンク失敗を観測した時に所在する前記セルの前記基地局に送信する送信ユニット」を含む点で共通する。 したがって、本願発明と引用発明とは以下の点で一致ないし相違する。 （一致点） 「　基地局であって、 ユーザ装置のリンクが失敗した後に、且つ前記ユーザ装置が前記基地局とコネクションを成功裏に再確立した後に、前記ユーザ装置が送信した、リンク失敗報告を受信する受信ユニット；及び 識別情報及び前記リンク失敗報告を含むリンク失敗指示を、前記ユーザ装置が前記リンク失敗を観測した時に所在する前記セルの前記基地局に送信する送信ユニットを含み、 前記ユーザ装置に関する前記識別情報は、前記ユーザ装置がリンク失敗を観測した時に所在するセルの基地局における前記ユーザ装置の識別子である、 基地局。」 （相違点） 受信ユニットが受信する「リンク失敗報告」及び送信ユニット送信する「識別情報加え前記リンク失敗報告を含むリンク失敗指示」に関し、本願発明は、「識別情報を含むリンク失敗報告」及び「前記識別情報を含む前記リンク失敗報告を含むリンク失敗指示」であるのに対し、引用発明が受信する「ＲＬＦ　ｒｅｐｏｒｔ」は「障害セル内のＵＥのＣ－ＲＮＴＩ」を含むことが明示されておらず、送信する「ＲＬＦ　ＩＮＤＩＣＡＴＩＯＮ」が含む「障害セル内のＵＥのＣ－ＲＮＴＩ」が「ＲＬＦ　ｒｅｐｏｒｔ」に含まれることが明示されていない点。 第６　判断 相違点について検討する。 引用発明は「障害セル内のＵＥのＣ－ＲＮＴＩ」がどのようにして得られたものか特定していないが、「ｅＮＢが新しいＲＲＣ接続を前のＲＲＣ接続と相関させることができるよう、ＵＥが前のＲＲＣ接続に係るＣＲＮＴＩも含むＲＲＣ　ｒｅｐｏｒｔを配信する。」ことが公知技術であることに鑑みれば、引用発明の「ＲＬＦ　ｒｅｐｏｒｔ」が前のＲＲＣ接続に係るＣＲＮＴＩである「障害セル内のＵＥのＣ－ＲＮＴＩ」を含むようにすることは、格別困難なことではなく、当業者が容易に想到し得ることである。 （上申書の補正案について） 平成２９年８月２８日に提出された上申書に補正案が付されているので、当該補正案についても検討する。 請求項１の補正案は以下のとおりである。 「　基地局であって、 ユーザ装置のリンクが失敗した後に、且つ前記ユーザ装置が前記基地局とコネクションを成功裏に確立した後に、前記ユーザ装置が送信した、識別情報を含むリンク失敗報告を受信する受信ユニットであって、前記ユーザ装置に関する前記識別情報は、前記ユーザ装置がリンク失敗を観測した時に所在するセルの基地局における前記ユーザ装置の識別子である、受信ユニット；及び 前記識別情報を含む前記リンク失敗報告を含むリンク失敗指示を、前記ユーザ装置が前記リンク失敗を観測した時に所在する前記セルの前記基地局に送信し、これにより、前記ユーザ装置が前記リンク失敗を観測した時に所在する前記基地局は、前記識別情報に基づいて、前記リンク失敗がハンドオーバー準備失敗によるものであると確定する送信ユニットを含む、基地局。」（［当審注］：下線部は、補正案の補正箇所を示す。） 新たに追加される「これにより、前記ユーザ装置が前記リンク失敗を観測した時に所在する前記基地局は、前記識別情報に基づいて、前記リンク失敗がハンドオーバー準備失敗によるものであると確定する」との事項は、請求項１に係る発明の「基地局」とは別の装置である「前記ユーザ装置が前記リンク失敗を観測した時に所在する基地局」を特定するものであって、請求項１に係る発明の「基地局」の構造、機能等について何ら特定していない。そして、引用発明の「ｅＮＢ」の「ＲＲＣ接続セットアップ又はＲＲＣ接続再確立後、ＵＥが送信した、ＲＬＦ　ｒｅｐｏｒｔを含むＵＥ　Ｉｎｆｏｒｍａｔｉｏｎ　Ｒｅｓｐｏｎｓｅを受信」することは、請求項１に係る発明の「基地局」の「前記ユーザ装置が前記基地局とコネクションを成功裏に確立した後に、前記ユーザ装置が送信した、識別情報を含むリンク失敗報告を受信する」ことに含まれるので、「これにより、前記ユーザ装置が前記リンク失敗を観測した時に所在する前記基地局は、前記識別情報に基づいて、前記リンク失敗がハンドオーバー準備失敗によるものであると確定する」点において、引用発明の「ｅＮＢ」と、請求項１に係る発明の「基地局」とは、記載上、表現上の相違があるものの、上記第５において認定した相違点以外に構造、機能等に差異はない。 そうすると、上記の判断と同様に、請求項１に係る発明は、引用発明及び公知技術に基づいて当業者が容易に想到し得るものである。 したがって、上記補正案は採用できない。 第７　むすび 以上のとおり、本願発明は、引用発明及び公知技術に基づいて当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。 したがって、本願は、他の請求項について検討するまでもなく、拒絶すべきものである。 よって、結論のとおり審決する。