ポートフォリオ機能
| ポートフォリオを新規に作成して保存 |
|
|
| 既存のポートフォリオに追加保存 |
|
PDFをダウンロード
|
| 審決分類 |
審判 査定不服 特36条6項1、2号及び3号 請求の範囲の記載不備 特許、登録しない(前置又は当審拒絶理由) H04W 審判 査定不服 2項進歩性 特許、登録しない(前置又は当審拒絶理由) H04W |
|---|---|
| 管理番号 | 1369639 |
| 審判番号 | 不服2019-7479 |
| 総通号数 | 254 |
| 発行国 | 日本国特許庁(JP) |
| 公報種別 | 特許審決公報 |
| 発行日 | 2021-02-26 |
| 種別 | 拒絶査定不服の審決 |
| 審判請求日 | 2019-06-05 |
| 確定日 | 2020-12-23 |
| 事件の表示 | 特願2016-142019「無線システムのためのラジオリソース接続(RRC)の確立」拒絶査定不服審判事件〔平成28年12月 1日出願公開、特開2016-201832〕について、次のとおり審決する。 |
| 結論 | 本件審判の請求は、成り立たない。 |
| 理由 |
第1 手続の経緯 本願は,2008年(平成20年)1月10日(パリ条約による優先権主張外国庁受理 2007年1月10日 米国, 2008年1月9日 米国)を国際出願日とする特願2009-545675号の一部を,平成24年12月20日に新たな特許出願とした特願2012-278002号の一部を,平成26年9月16日に新たな特許出願とした特願2014-187852号の一部を,平成28年7月20日に新たな特許出願としたものであって,その手続の経緯の概略は以下のとおりである。 平成28年 8月17日 :手続補正書の提出 平成29年10月24日付け:拒絶理由通知書 平成30年 1月 9日 :意見書,手続補正書の提出 平成30年 6月19日付け:拒絶理由通知書 平成30年 8月29日 :意見書,手続補正書の提出 平成31年 1月30日付け:拒絶査定 令和 元年 6月 5日 :拒絶査定不服審判の請求 令和 2年 2月14日付け:拒絶理由通知書(当審) 令和 2年 5月12日 :意見書,手続補正書の提出 第2 本願発明 本願の請求項に係る発明は,令和2年5月12日に手続補正された特許請求の範囲の請求項1ないし28に記載された事項により特定されるものであるところ,その請求項1に係る発明は,以下のとおりのものと認める。 「 ソース基地局からターゲット基地局へのユーザ機器(UE)の無線ハンドオフの方法であって, 前記UEによって前記UE及び前記ソース基地局間のラジオリンク障害(RLF)を検出することと,前記RLFは,前記UEのプロトコルレイヤーにおいて前記UEと第三者との間の通信サービスを中断する, 前記RLFの検出後に,前記無線ハンドオフを開始するために前記ターゲット基地局に接続リクエストメッセージを送ることと,前記接続リクエストメッセージは,前記UEがアクティブ状態からサービス再確立サブ状態へ遷移しているという表示を含み,前記サービス再確立サブ状態は,前記通信サービスが前記無線ハンドオフの間継続的に前記アクティブ状態を維持することを可能にする, 前記UEが前記ソース基地局から前記ターゲット基地局にハンドオフ中に,前記UEのサービスレイヤーにおいて前記UEと前記第三者との間の前記通信サービスを維持することと, を備える方法。」 第3 拒絶の理由 令和2年2月14日付けで当審が通知した拒絶理由(以下,「当審拒絶理由」という。)の概要は, 「1.(進歩性)この出願の下記の請求項に係る発明は,その出願前に日本国内又は外国において,頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて,その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから,特許法第29条第2項の規定により特許を受けることができない。」 というものであり,本願の請求項1に係る発明に対して,以下の引用例3が引用されている。 引用例3:Panasonic,Necessity of forward handover,3GPP TSG RAN WG2 #54 R2-062146,[online],2006年8月23日アップロード, ＜URL:https://www.3gpp.org/ftp/tsg_ran/WG2_RL2/TSGR2_54/Documents/ R2-062146.zip＞ 第4 引用発明 当審拒絶理由に引用されたPanasonic,Necessity of forward handover(当審仮訳:フォワードハンドオーバの必要性),3GPP TSG RAN WG2 #54 R2-062146,[online],2006年8月23日アップロード, ＜URL:https://www.3gpp.org/ftp/tsg_ran/WG2_RL2/TSGR2_54/Documents/ R2-062146.zip＞には,図面とともに,以下の事項が記載されている。(下線は当審が付与。) 「1. Introduction In RAN2#53 meeting (Shanghai), RAN2 discussed radio link failure and concluded that a working assumption is no forward handover. That is, UE needs to go RRC_IDLE state after radio link failure. However, it was also stated that forward handover could be considered, if RAN2 recognises the necessity. This document analyses necessity of forward handover for radio link failure from following two aspects. - Radio link failure scenarios in LTE - UE and aGW behaviour in case of not to have forward handover (中略) 2.2 UE behaviour in case of no forward handover In UMTS, UE has following two steps, after a radio link failure occurs. ・ Cell update phase - UE stays in RRC_CONNECTED, and service continuously is not affected - Lower layer context are released ・ T314/315 expire phase - UE goes to RRC_IDLE, and service continuously is affected. - RRC context are almost released If no forward handover is supported in LTE, UE goes to RRC_IDLE and UE releases context which won’t be maintained in RRC_IDLE after radio link failure. Currently, although it’s not clear what kinds of information are maintained in RRC_IDLE, some contexts will be released in RRC_IDLE. If release of context in state transition to RRC_IDLE means service continuity is affected, no specific additional function is not necessary for radio link failure but the user experience is not good to compare with UMTS. Therefore we think service continuity should be kept from the user experience perspective. But such service continuity would require additional function or additional sub-state. We think additional complexity by introducing forward handover is relatively small as described in Annex. Therefore, we propose to have forward handover also should be considered. Conclusion2: UE behaviour after radio link failure depends on definition of RRC_IDLE. If additional function or sub-state is required for UE after radio link failure for service continuously, forward handover should be considered since introduction of forward handover requires only small complexity (中略) Annex: Procedure after radio link failure Possible forward handover procedure is illustrated in Figure A. Following functionalities is required to support forward handover. eNB ・ New eNB function to treat "Handover Request message" from UE, and configure UE by "Handover Setup message". ・ New eNB function to give a trigger of context transfer and data transfer to source eNB in new eNB ・ Source eNB function to transfer context and data to new eNB based on trigger from new eNB UE ・ Function to initiate "Handover Request message" to new eNB after radio link failure New message "Handover Request message" needs to be defined, but functions which are required in eNB are not so much different from functions in backward handover. So, we think that additional complexity by support of forward handover is relatively small for eNB. We also think that complexity of UE is also limited.  」 (当審仮訳: 1. イントロダクション RAN2#53ミーティング(上海)で,RAN2はラジオリンク障害について議論し,作業仮説はフォワードハンドオーバではないと結論付けた。つまり,UEは,ラジオリンク障害の後にRRC_IDLE状態になる必要がある。ただし,RAN2が必要性を認めた場合は,フォワードハンドオーバも検討することができるものとしている。 このドキュメントでは,ラジオリンク障害に対するフォワードハンドオーバの必要性を次の2つの側面から分析している。 - LTEのラジオリンク障害シナリオ - フォワードハンドオーバがない場合のUE及びaGWの動作 (中略) 2.2 フォワードハンドオーバがない場合のUEの動作 UMTSでは,ラジオリンク障害が発生した後,UEには次の2つのステップがある。 ・セル更新フェーズ - UEはRRC_CONNECTEDに留まり,サービスの継続性は影響を受けない。 - 下位レイヤのコンテキストが解放される。 ・T314/315期限切れフェーズ - UEがRRC_IDLEに移行し,サービスの継続性が影響を受ける。 - RRCコンテキストはほとんど解放される。 LTEでフォワードハンドオーバがサポートされていない場合,UEはRRC_IDLEに移行し,UEはラジオリンク障害後にRRC_IDLEで維持されないコンテキストを解放する。現在,RRC_IDLEでどのような種類の情報が維持されているのかは明確ではないが,RRC_IDLEで解放されるコンテキストもある。RRC_IDLEへの状態遷移におけるコンテキストの解放がサービスの継続性に影響することを意味する場合,ラジオリンク障害のために特定の追加機能は必要ないが,UMTSと比較してユーザ経験は悪化する。したがって,ユーザ経験の観点からは,サービスの継続性を維持する必要がある。ただし,このようなサービスの継続には,追加の機能又は追加のサブ状態が必要である。付録に記載されているように,フォワードハンドオーバの導入による追加の複雑さは比較的小さいと考えている。したがって,フォワードハンドオーバも検討すべきである。 結論2: ラジオリンク障害後のUEの動作は,RRC_IDLEの定義に依存する。ラジオリンク障害後のサービスの継続性のために,UEに追加の機能又はサブ状態が必要な場合,フォワードハンドオーバの導入に必要な複雑さは小さいことから,フォワードハンドオーバを検討する必要がある。 (中略) 付録:ラジオリンク障害後の手順 実現可能なフォワードハンドオーバ手順をFigure Aに示す。フォワードハンドオーバをサポートするには,次の機能が必要である。 eNB ・UEからの「Handover Request message」を扱い,「Handover Setup message」でUEを構成するNew eNB機能。 ・コンテキスト転送とデータ転送のトリガをNew eNBがSource eNBに提供するNew eNB機能 ・New eNBからのトリガに基づいてコンテキストとデータをNew eNBに転送するSource eNB機能 UE ・ラジオリンク障害後にNew eNBへの「Handover Request message」を開始する機能 新しいメッセージ「Handover Request message」を定義する必要があるが,eNBで必要な機能は,バックワードハンドオーバの機能とそれほど変わらない。 したがって,フォワードハンドオーバのサポートによる追加の複雑さは,eNBでは比較的小さいと考える。 また,UEの複雑さも限られていると考える。 (図面は省略) ) 上記の記載,並びに当業者の技術常識を考慮すると, 1 「Figure A」の記載から,「1.Detect out of sync」の前,すなわち,同期外れを検出する(Detect out of sync)処理により同期外れを検出する前は,UEはSource eNBとSAE radio bearerを介して通信を行っており,「1.Detect out of sync」により同期外れを検出した後に,UEは,「2. Handover Request」,「8. Handover Setup」,「9. Configure UE」,「10. Handover Response」,に関する処理を行い,最終的にNew eNBとSAE radio bearerを介して通信を行うことがみてとれる。 そして,「付録」の「ラジオリンク障害後の手順」という標題名と,「付録:ラジオリンク障害後の手順」の「実現可能なフォワードハンドオーバ手順をFigure Aに示す。」との記載から,上述した「1.Detect out of sync」,「2. Handover Request」,「8. Handover Setup」,「9. Configure UE」,「10. Handover Response」,に関する方法(処理)は,ラジオリンク障害後に,UE がSource eNBからNew eNBへフォワードハンドオーバするための方法といえる。 よって,引用例3には「ラジオリンク障害後に,UE がSource eNBからNew eNBへフォワードハンドオーバするための方法」が記載されていると認める。 2 「付録:ラジオリンク障害後の手順」の「・ラジオリンク障害後にNew eNBへの「Handover Request message」を開始する機能」との記載,及び「Figure A」の記載から,UEは,ラジオリンク障害後であり,「1.Detect out of sync」により,同期外れを検出した後に,「New eNB」へ「Handover Request message」を送信するといえる。そうすると,UEは,同期外れを検出することによって,UEとSource eNBとの間のラジオリンク障害を検出していることは明らかである。 よって,引用例3には「UEは,同期外れを検出することによって,UEとSource eNBとの間のラジオリンク障害を検出した後に,New eNBへHandover Request messageを送信すること」が記載されていると認める。 また,「Figure A」の「2. Handover Request」に関する記載から,「Handover Request message」は「Source eNB identifier」と「C-RNTI in Source eNB」を含むことが見てとれる。 よって,引用例3には「Handover Request messageは,Source eNB identifierとC-RNTI in Source eNBを含む」ことが記載されていると認める。 また,「2.2 フォワードハンドオーバがない場合のUEの動作」の「したがって,ユーザ経験の観点からは,サービスの継続性を維持する必要がある。ただし,このようなサービスの継続には,追加の機能又は追加のサブ状態が必要である。」,及び,「結論2: ラジオリンク障害後のUEの動作は,RRC_IDLEの定義に依存する。ラジオリンク障害後のサービスの継続性のために,UEに追加の機能又はサブ状態が必要な場合,フォワードハンドオーバの導入に必要な複雑さは小さいことから,フォワードハンドオーバを検討する必要がある。」との記載によれば,ラジオリンク障害後のサービスの継続性を維持するために,UEに追加のサブ状態を備えることが記載されているといえる。そして,「フォワードハンドオーバ」が行われる場合も,「ユーザ経験の観点からは,サービスの継続性を維持する必要がある」ことは明らかであるから,サービスの継続性を維持するために「UEに追加のサブ状態を備える」ものといえる。 よって,引用例3には,フォワードハンドオーバが行われる場合も,「ラジオリンク障害後のサービスの継続性を維持するために,UEに追加のサブ状態を備える」ことが記載されていると認める。 したがって,引用例3には,「UEは,同期外れを検出することによって,UEとSource eNBとの間のラジオリンク障害を検出した後に,New eNBへHandover Request messageを送信すること,ここで,Handover Request messageは,Source eNB identifierとC-RNTI in Source eNBを含み,ラジオリンク障害後のサービスの継続性を維持するために,UEに追加のサブ状態を備える」ことが記載されていると認める。 3 「付録:ラジオリンク障害後の手順」の「・コンテキスト転送とデータ転送のトリガをNew eNBがSource eNBに提供するNew eNB機能」,「・New eNBからのトリガに基づいてコンテキストとデータをNew eNBに転送するSource eNB機能」との記載,及び「Figure A」の記載から,New eNBは,「2. Handover Request」において,UEからHandover Request messageを受信した後に,「4. Context Request」において,コンテキスト転送とデータ転送のトリガをSource eNBに提供し,「6. Context Response」と「Data forwarding」において,Source eNBから転送されるコンテキストとデータを取得し,「7. Decide UE configuration」により,UEのコンフィグレーションを決定することが記載されているといえる。 よって,引用例3には「New eNBは,UEからHandover Request messageを受信した後に,コンテキスト転送とデータ転送のトリガをSource eNBに提供し,Source eNBから転送されるコンテキストとデータを取得し,UEのコンフィグレーションを決定するものである」ことが記載されていると認める。 以上を総合すると,引用例3には以下の発明(以下,「引用発明」という。)が記載されていると認める。 「 ラジオリンク障害後に,UE がSource eNBからNew eNBへフォワードハンドオーバするための方法であって, UEは,同期外れを検出することによって,UEとSource eNBとの間のラジオリンク障害を検出した後に,New eNBへHandover Request messageを送信すること,ここで,Handover Request messageは,Source eNB identifierとC-RNTI in Source eNBを含み,ラジオリンク障害後のサービスの継続性を維持するために,UEに追加のサブ状態を備え, また,New eNBは,UEからHandover Request messageを受信した後に,コンテキスト転送とデータ転送のトリガをSource eNBに提供し,Source eNBから転送されるコンテキストとデータを取得し,UEのコンフィグレーションを決定するものである, を備える方法。」 第5 対比・判断 本願発明と引用発明とを対比すると, 1 引用発明の「UE」,「Source eNB」は,本願発明の「ユーザ機器(UE)」,「ソース基地局」に相当する。 また,引用発明の「フォワードハンドオーバ」が無線ハンドオフの一種であることは明らかであるから,引用発明の「フォワードハンドオーバ」は,本願発明の「無線ハンドオフ」に含まれる。 また,引用発明の「New eNB」は,ハンドオーバ先の基地局であるから,引用発明の「New eNB」は,本願発明の「ターゲット基地局」に含まれる。 したがって,引用発明の「ラジオリンク障害後に,UE がSource eNBからNew eNBへフォワードハンドオーバするための方法」は,本願発明と同様に「ソース基地局からターゲット基地局へのユーザ機器(UE)の無線ハンドオフの方法」といえる点で共通する。 2 引用発明の「UEは,同期外れを検出することによって,UEとSource eNBとの間のラジオリンク障害を検出」することは,本願発明の「前記UEによって前記UE及び前記ソース基地局間のラジオリンク障害(RLF)を検出すること」に対応する。 3 引用発明の「Handover Request message」が,フォワードハンドオーバを開始するために,UEがNew eNBに対してハンドオーバによる接続をリクエストするメッセージであることは明らかである。 してみると,引用発明の「UEは,同期外れを検出することによって,UEとSource eNBとの間のラジオリンク障害を検出した後に,New eNBへHandover Request messageを送信すること」は,本願発明の「前記RLFの検出後に,前記無線ハンドオフを開始するために前記ターゲット基地局に接続リクエストメッセージを送ること」に対応する。 4 引用発明の「追加のサブ状態」は,ラジオリンク障害後のサービスの継続性を維持するための状態であるから,ラジオリンク障害後,フォワードハンドオーバの処理が完了し,UEとNew eNBの通信が開始されるまでの間,サービスの継続性を維持するための状態であることは自明である。そして,サービスの継続性を維持するためには,通信サービスをアクティブ状態に維持する必要があることは明らかである。 そうすると,本願発明の「サービス再確立サブ状態」と引用発明の「追加のサブ状態」は,双方とも,通信サービスが無線ハンドオフの間継続的にアクティブ状態を維持することを可能にするための状態といえる。 よって,引用発明の「ラジオリンク障害後のサービスの継続性を維持するために,UEに追加のサブ状態を備える」ことは,本願発明の「サービス再確立サブ状態は,前記通信サービスが前記無線ハンドオフの間継続的に前記アクティブ状態を維持することを可能にする」ことに相当する。 以上を総合すると,本願発明と引用発明とは,以下の点で一致し,また,相違している。 (一致点) 「 ソース基地局からターゲット基地局へのユーザ機器(UE)の無線ハンドオフの方法であって, 前記UEによって前記UE及び前記ソース基地局間のラジオリンク障害(RLF)を検出すること, 前記RLFの検出後に,前記無線ハンドオフを開始するために前記ターゲット基地局に接続リクエストメッセージを送ること,サービス再確立サブ状態は,通信サービスが前記無線ハンドオフの間継続的にアクティブ状態を維持することを可能にする, を備える方法。」 (相違点1) 「ラジオリンク障害(RLF)」に関し,本願発明は「前記RLFは,前記UEのプロトコルレイヤーにおいて前記UEと第三者との間の通信サービスを中断する」ことが特定されているのに対し,引用発明の「ラジオリンク障害」は,そのような特定がされていない点。 (相違点2) 「接続リクエストメッセージ」に関し,本願発明は「接続リクエストメッセージは,前記UEがアクティブ状態からサービス再確立サブ状態へ遷移しているという表示を含み」と特定されているのに対し,引用発明の「Handover Request message」は,「Source eNB identifierとC-RNTI in Source eNB」を含むものであるが,「UEがアクティブ状態からサービス再確立サブ状態へ遷移しているという表示」を含むことは特定されていない点。 (相違点3) 「通信サービス」に関し,本願発明は「前記UEが前記ソース基地局から前記ターゲット基地局にハンドオフ中に,前記UEのサービスレイヤーにおいて前記UEと前記第三者との間の前記通信サービスを維持すること」が特定されているのに対し,引用発明はそのような特定はされていない点。 上記の各相違点について検討する。 (相違点1,3について) 引用発明の「ラジオリンク障害」が発生した場合,少なくともプロトコルレイヤーである物理レイヤにおいて,UEと第三者との間の通信サービスが中断されることは明らかである。 更に,「第5 対比・判断」の「4」で検討したとおり,引用発明の「追加のサブ状態」は,通信サービスが無線ハンドオフの間継続的にアクティブ状態を維持することを可能にするための状態であるといえる。そして,UEに対する「サービス」が,サービスレイヤーにおいて提供されることは技術常識であるから,引用発明において,「ラジオリンク障害後のサービスの継続性を維持するため」に,引用発明の「UE」が,「フォワードハンドオーバ」の処理中に,サービスレイヤーにおいてUEと第三者との間の通信サービスを維持していることは明らかである。 そうすると,本願発明と引用発明は,双方とも,「RLF」により「UEのプロトコルレイヤーにおいて前記UEと第三者との間の通信サービスを中断する」ものであり,かつ,「UEが前記ソース基地局から前記ターゲット基地局にハンドオフ中に,前記UEのサービスレイヤーにおいて前記UEと前記第三者との間の前記通信サービスを維持する」ものといえるから,上記相違点1,3は実質的な相違点ではない。 (相違点2について) 引用発明の「New eNB」は,「UEからHandover Request messageを受信した後に,コンテキスト転送とデータ転送のトリガをSource eNBに提供し,Source eNBから転送されるコンテキストとデータを取得し,UEのコンフィグレーションを決定するものである」ところ,ラジオリンク障害の前にSource eNBがUEに提供していたサービスを継続するために,New eNBが,Source eNBからコンテキストとデータを取得していることは自明である。 そうすると,New eNBは,Source eNB identifierとC-RNTI in Source eNBを含むHandover Request messageを受信することにより,UEが「追加のサブ状態」であること,すなわち,「ラジオリンク障害後のサービスの継続性を維持するため」の状態であることを暗黙的に認識し,ラジオリンク障害の前にSource eNBがUEに提供していたサービスを継続するための処理を行っているといえる。 そして,UEから基地局に所定の情報を通知する方法として,暗黙的な方法により通知する方法と,明示的な情報を含めた信号を基地局に送信する方法とがあり,いずれも常套的に用いられている手法である。してみれば,引用発明のHandover Request messageに関して,Handover Request messageを介して暗黙的にUEの状態をNew eNBに通知することに代えて,Handover Request message にUEがアクティブ状態から「追加のサブ状態」に遷移していることを示す明示的な情報を含めるようにすることは,当業者が必要に応じて適宜なし得る事項にすぎない。 よって,引用発明において,相違点2に係る構成を採用することは,当業者が容易に想到しうることである。 そして,本願発明の作用効果も,引用発明に基づいて当業者が予測し得る範囲のものであり,格別なものではない。 したがって,本願発明は,引用例3に記載された発明に基づき,当業者が容易に想到できたものであるから,特許法第29条第2項の規定により,特許を受けることができない。 第6 むすび 以上のとおり,本願発明は,引用例3に記載された発明に基づき,当業者が容易に想到できたものであるから,特許法第29条第2項の規定により,特許を受けることができない。 したがって,本願は,他の請求項について検討するまでもなく,拒絶すべきものである。 よって,結論のとおり審決する。 |
| 別掲 |
|
| 審理終結日 | 2020-07-15 |
| 結審通知日 | 2020-07-21 |
| 審決日 | 2020-08-05 |
| 出願番号 | 特願2016-142019(P2016-142019) |
| 審決分類 |
P
1
8・
537-
WZ
(H04W)
P 1 8・ 121- WZ (H04W) |
| 最終処分 | 不成立 |
| 前審関与審査官 | 石田 紀之 |
| 特許庁審判長 |
岩間 直純 |
| 特許庁審判官 |
望月 章俊 相澤 祐介 |
| 発明の名称 | 無線システムのためのラジオリソース接続(RRC)の確立 |
| 代理人 | 福原 淑弘 |
| 代理人 | 井関 守三 |
| 代理人 | 蔵田 昌俊 |
| 代理人 | 岡田 貴志 |