ポートフォリオ機能
| ポートフォリオを新規に作成して保存 |
|
|
| 既存のポートフォリオに追加保存 |
|
PDFをダウンロード
|
| 審決分類 |
審判 査定不服 特17条の2、3項新規事項追加の補正 特許、登録しない。 H04W 審判 査定不服 特36条6項1、2号及び3号 請求の範囲の記載不備 特許、登録しない。 H04W 審判 査定不服 5項独立特許用件 特許、登録しない。 H04W 審判 査定不服 2項進歩性 特許、登録しない。 H04W |
|---|---|
| 管理番号 | 1360888 |
| 審判番号 | 不服2019-7524 |
| 総通号数 | 245 |
| 発行国 | 日本国特許庁(JP) |
| 公報種別 | 特許審決公報 |
| 発行日 | 2020-05-29 |
| 種別 | 拒絶査定不服の審決 |
| 審判請求日 | 2019-06-05 |
| 確定日 | 2020-03-13 |
| 事件の表示 | 特願2016-508437「無線通信装置及び無線通信方法」拒絶査定不服審判事件〔平成27年 9月24日国際公開、WO2015/141012〕について、次のとおり審決する。 |
| 結論 | 本件審判の請求は、成り立たない。 |
| 理由 |
第1 手続の経緯 本願は、2014年(平成26年)3月20日を国際出願日とする出願であって、その手続の経緯は以下のとおりである。 平成29年11月20日付け 拒絶理由通知書 平成30年 2月13日 意見書、手続補正書の提出 平成30年 6月27日付け 拒絶理由通知書(最後) 平成30年 9月 3日 意見書、手続補正書の提出 平成31年 2月26日付け 平成30年9月3日にされた手続補正 についての補正の却下の決定、拒絶査定 令和 1年 6月 5日 拒絶査定不服審判の請求、 手続補正書の提出 令和 1年12月 3日 面接、手続補正書(案)の提出 第2 令和1年6月5日にされた手続補正についての補正の却下の決定 [補正の却下の決定の結論] 令和1年6月5日にされた手続補正(以下、「本件補正」という。)を却下する。 [理由] 1.補正の概要 本件補正は、平成30年2月13日にされた手続補正により補正された特許請求の範囲の請求項1に記載された 「 第1の通信装置から送信されるデータの一部を当該第1の通信装置と第1の経路を介して受信するとともに、前記第1の通信装置から送信されるデータの他の一部を第2の通信装置を経由する第2の経路を介して受信する受信部と、 前記第2の経路を介した通信に関する設定を変更する通信制御を行うことが可能な制御部と、 前記通信制御を行う場合に、前記受信部によって受信済みのデータ又は未受信のデータを特定する受信状態情報を前記第1の経路を介して前記第1の通信装置へ送信する送信部と を有することを特徴とする無線通信装置。」 という発明(以下、「本願発明」という。)を、 「 第1の通信装置と第2の通信装置と2元接続中に、前記第1の通信装置から送信されるデータの一部を当該第1の通信装置と第1の経路を介して受信するとともに、前記第1の通信装置から送信されるデータの他の一部を前記第2の通信装置を経由する第2の経路を介して受信する受信部と、 前記2元接続中に前記第2の通信装置からの通知によって、前記第2の通信装置と前記第1の通信装置間でロスしたパケットに関する情報と、移動局に対して送信がなされなかったパケットに関する情報と、を取得することが可能な前記第1の通信装置の制御に応じて、前記第1の通信装置との接続を1元接続に変更を行う通信制御が可能な制御部と、 前記通信制御を行う場合に、前記受信部によって受信済みのデータ又は未受信のデータを特定する受信状態情報を前記第1の経路を介して前記第1の通信装置へ送信する送信部と を有することを特徴とする無線通信装置。」 という発明(以下、「本件補正発明」という。)とすることを含むものである(下線は補正箇所を示すものとして請求人が付与したものである。)。 2.補正の適否 (1)新規事項の有無について 本件補正発明の「前記2元接続中に前記第2の通信装置からの通知によって、前記第2の通信装置と前記第1の通信装置間でロスしたパケットに関する情報と、移動局に対して送信がなされなかったパケットに関する情報と、を取得することが可能な前記第1の通信装置の制御に応じて、前記第1の通信装置との接続を1元接続に変更を行う」との補正事項によれば、第1の通信装置は、第2の通信装置からの通知によって「前記第2の通信装置と前記第1の通信装置間でロスしたパケットに関する情報」及び「移動局に対して送信がなされなかったパケットに関する情報」を取得することになる。 一方、願書に最初に添付した明細書、特許請求の範囲又は図面(以下、「当初明細書等」という。)には次の記載がある。 ・「開示の技術は、かかる点に鑑みてなされたものであって、送受信されるユーザデータの不整合を防止することができる無線通信装置及び無線通信方法を提供することを目的とする。」(段落0013) ・「第1に、スモール基地局200を介した送信経路(X2インタフェース及び無線リンク)においてデータのロス(X2インタフェースにおけるパケットロスや、スモール基地局においてトラヒックの輻輳にって発生するバッファ溢れによるデータ廃棄又は無線リンクにおける送信失敗など)が発生し、移動局300において、所望のデータが受信されなかった場合(PDCPレイヤにおけるタイマの満了で検出が可能である)である。」(段落0027) ・「また、受信部12は、スモール基地局200がエラー(通信の不具合)を検出した場合に、エラー検出通知をスモール基地局200から受信する。」(段落0037) ・「また、送信部23は、移動局300との間の通信においてエラーが検出された場合に、エラー検出通知をマクロ基地局100へ送信する。ここで検出されるエラーは、例えば移動局300へユーザデータを送信してから所定時間が経過してもユーザデータの受信確認(ACK)が移動局300から受信されないエラーや、ユーザデータの再送回数が所定の最大再送回数に到達するエラーなどである。なお、送信部23は、マクロ基地局100との間の通信においてエラーが検出された場合にも、エラー検出通知をマクロ基地局100へ送信しても良い。」(段落0042) ・「また、制御部24は、移動局300との間におけるデータの再送回数を監視し、再送回数が所定の最大再送回数に到達した場合に、エラーが発生したことを検出しても良い。さらに、制御部24は、マクロ基地局100から有線接続を介してパケットを受信してから所定時間が経過しても所望のパケットが受信されない場合に、エラーが発生したことを検出しても良い。制御部24がエラーを検出すると、通信部21は、有線接続を介してエラー検出通知をマクロ基地局100へ送信する。」(段落0070) ・「マクロ基地局100においては、スモール基地局200から送信されたエラー検出通知を受け、制御部14によって、2元接続を一時的に解除して1元接続に切り替えることが決定される。」(段落0100) これらの記載から、当初明細書等には、「第2の通信装置」に対応するスモール基地局200が、「第1の通信装置」に対応するマクロ基地局100との間の通信においてエラーが検出された場合、及び、「移動局」に対応する移動局300との間の通信においてエラーが検出された場合に、エラー検出通知をマクロ基地局100へ送信すること、エラー検出通知を受けたマクロ基地局100が2元接続を一時的に解除して1元接続に切り替えること、が記載されているといえる。また、当初明細書の段落0027及び段落0070によれば、「第2の通信装置」に対応するスモール基地局200を介した送信経路(X2インタフェース及び無線リンク)においてデータのロスが発生した場合にエラーが発生したことを検出すると記載されているといえる。しかしながら、当初明細書等には、エラー検出通知の中にどのような情報が含まれるかは開示されていない。 そして、発明が解決しようとする課題は「送受信されるユーザデータの不整合を防止する」(段落0013)ことであると認められるところ、当該課題と「第2の通信装置と前記第1の通信装置間でロスしたパケットに関する情報」及び「移動局に対して送信がなされなかったパケットに関する情報」との関連性は見出せない。ここで、仮にこれらの情報内容が、スモール基地局とideal backhaulで接続されたマクロ基地局において二元接続を解除するか否かの判断に寄与することがあるとしても、当初明細書等には二元接続を解除するか否かの判断については一切触れられておらず、また、当該判断は移動局に対応する本件補正発明の無線通信装置とは無関係のものである。 したがって、出願時の技術常識を考慮しても、発明が解決しようとする課題に照らして、エラー検出通知に「前記第2の通信装置と前記第1の通信装置間でロスしたパケットに関する情報」及び「移動局に対して送信がなされなかったパケットに関する情報」が含まれることが記載されていると同然とはいえない。 よって、本件補正は、当初明細書等のすべての記載を総合することにより導かれる技術的事項との関係において、第1の通信装置が第2の通信装置からの通知によって「前記第2の通信装置と前記第1の通信装置間でロスしたパケットに関する情報」及び「移動局に対して送信がなされなかったパケットに関する情報」を取得するという新たな技術的事項を導入するものであるから、令和1年6月5日付け手続補正書でした補正は、当初明細書等に記載した事項の範囲内においてするものとはいえず、特許法第17条の2第3項に規定する要件を満たしていない。 (2)独立特許要件について 上記(1)のとおり、本件補正は特許法第17条の2第3項の規定に違反するものであるが、更に進めて、仮に、本件補正が限定的減縮(特許法第17条の2第5項に掲げる事項)を目的とするものであるとして、本件補正発明が特許出願の際、独立して特許を受けることができるものであるか(特許法第17条の2第6項において準用する特許法第126条第7項の規定に適合するか)についても以下に検討する。 ア 特許法第36条第6項第1号について 上記(1)のとおり、「前記2元接続中に前記第2の通信装置からの通知によって、前記第2の通信装置と前記第1の通信装置間でロスしたパケットに関する情報と、移動局に対して送信がなされなかったパケットに関する情報と、を取得することが可能な前記第1の通信装置の制御に応じて、前記第1の通信装置との接続を1元接続に変更を行う」ことは、本願出願当初の明細書等に記載されておらず、発明が解決しようとする課題に照らして自明な事項でもない。したがって、本件補正発明は発明の詳細な説明において、発明の課題が解決できることを当業者が認識できるように記載された範囲を超えるものであって、特許法第36条第6項第1号の規定を満たしていない。 よって、本件補正発明は、特許法第36条第6項第1号の規定により特許出願の際独立して特許を受けることができない。 イ 特許法第29条第2項について (ア) 本件補正発明 本件補正発明は、上記「1.」に記載したとおりのものと認める。 (イ) 引用例等に記載された事項及び引用発明等 a 引用発明 原査定の拒絶の理由で引用されたEricsson,Dual Connectivity - non-mobility scenarios(当審仮訳:デュアルコネクティビティ-非モビリティシナリオ)、3GPP TSG-RAN WG3 Meeting #83 R3-140344、2014年2月1日アップロード、インターネット＜https://www.3gpp.org/ftp/tsg_ran/WG3_Iu/TSGR3_83/Docs/R3-140344.zip＞(以下、「引用例」という。)には、以下の事項が記載されている。(下線は当審が付与。) (a)「2.1 SeNB Addition (中略)  Figure 2.1-1: SeNB Addition. (中略) Note: In case of UP options 3C, transmission of user plane data may take place after step 8.」(1-3ページ) (当審仮訳: 2.1 SeNBの追加 (中略) (図省略) 図2.1-1:SeNBの追加 (中略) 注:UPオプション3Cの場合、ステップ8の後にユーザープレーンデータの送信が行われる場合がある。) (b)「2.5 SeNB Release-SeNB triggered This scenario describes differences to the SeNB-triggered case. The SeNB might e.g. realise that the UE is out-of-sync with SeNB resources or the UE did not use the SeNB resources for a while, etc.  Figure 2.5-1: SeNB Release-SeNB triggered. As can be seen in Figure2.5-1, the difference to the MeNB triggered case is in the preparation phase.Without the need to establish forwarding tunnels (for split bearer or in case of complete removal of E-RABs), a single message (step 1) would be sufficient to trigger the RRC Reconfiguration. The SeNB could release radio resources immediately after (see also open issue Rel-M-01). 」(9ページ) (当審仮訳: 2.5 SeNBリリース-SeNBによってトリガーされる このシナリオでは、SeNBによってトリガーされるケースとの違いについて説明する。SeNBは、たとえばUEがSeNBリソースと同期していない、又はUEがしばらくSeNBリソースを使用しなかったことなどを認識する。 (図省略) 図2.5-1:SeNBリリース-SeNBによってトリガーされる 図2.5-1に見られるように、MeNBによってトリガーされる場合との違いは準備フェーズである。フォワーディングトンネルを確立する必要がない場合(分割ベアラー又はE-RABの完全な削除の場合)、単一のメッセージ(ステップ1)でRRC再構成をトリガーできる。SeNBはその直後に無線リソースを解放できる(未解決の問題RelM-01も参照)。」 ここで、オプション3Cについての技術常識として、3GPPの規格書である3GPP TR 36.842 V1.0.0(2013-11)、3rd Generation Partnership Project; Technical Specification Group Radio Access Network; Evolved Universal Terrestrial Radio Access (E-UTRA); Study on Small Cell Enhancementsfor E-UTRA and E-UTRAN - Higher layer aspects(Release 12)、2013年発行には、次のように記載されている。 「8.1 Architecture and protocol enhancements for Dual connectivity (中略) 8.1.1.8 Alternative 3C (中略)  Figure 8.1.1.8-1: Alternative 3C」(32-38ページ) (当審仮約: 8.1 デュアルコネクティビティのアーキテクチャ及びプロトコルの拡張 (中略) 8.1.1.8 オプション3C (図省略) 図8.1.1.8-1:オプション3C) 上記記載によると、次の技術常識が見てとれる。 「 デュアルコネクティビティのオプション3Cにおいて、UEが、MeNBとSeNBと2元接続中に、MeNBから送信されるデータの一部を当該MeNBとUEとの直接の経路を介して受信するとともに、前記MeNBから送信されるデータの他の一部をSeNBを経由する経路を介して受信する。」 上記(a)、(b)の記載及び図面並びに当業者の技術常識を考慮すると、以下のことがいえる。 引用例のタイトルに「デュアルコネクティビティ」と記載され、上記(a)はUPオプション3Cの場合について述べられているように、引用例がデュアルコネクティビティにおけるユーザープレーンについて、オプション3Cの場合を想定していることは明らかである。そして、デュアルコネクティビティのオプション3Cでは、UEが、MeNBとSeNBと2元接続中に、MeNBから送信されるデータの一部を当該MeNBとUEとの直接の経路を介して受信するとともに、前記MeNBから送信されるデータの他の一部をSeNBを経由する経路を介して受信することは、当業者における技術常識である。 したがって、引用例に記載されたUEは「MeNBとSeNBと2元接続中に、MeNBから送信されるデータの一部を当該MeNBとUEへの直接の経路を介して受信するとともに、前記MeNBから送信されるデータの他の一部をSeNBを経由する経路を介して受信する」といえる。 上記(b)の記載及び図2.5-1によれば、引用例には、SeNBがメッセージ(ステップ1、SeNB Release Required)をMeNBに通知し、MeNBがUEに対してRRC Connection Reconfiguration(ステップ4)を送信すると、SeNBが無線リソースを解放することが記載されているといえる。 したがって、「MeNBがUEに対してRRC Connection Reconfigurationを送信することに応じて、SeNBが無線リソースを解放する」といえる。 上記(b)の図2.5-1のステップ5によれば、UEがRRC Connection Reconfiguration CompleteをMeNBへ送信することが見てとれる。すなわち、UEは、「RRC Connection Reconfiguration CompleteをUEとの直接の経路を介してMeNBへ送信する」といえる。 してみれば、引用例には次の発明(以下、「引用発明」という。)が記載されていると認める。 「 MeNBとSeNBと2元接続中に、MeNBから送信されるデータの一部を当該MeNBとUEとの直接の経路を介して受信するとともに、前記MeNBから送信されるデータの他の一部をSeNBを経由する経路を介して受信することと、 MeNBがUEに対してRRC Connection Reconfigurationを送信することに応じて、SeNBが無線リソースを解放することと、 RRC Connection Reconfiguration CompleteをUEとの直接の経路を介してMeNBへ送信することと、 を有するUE。」 b 公知技術 原査定の拒絶の理由で引用されたIntel Corporation、PDCP reordering for option 3C in dual Connectivity(当審仮訳:デュアルコネクティビティのオプション3CのためのPDCP並び替え)、3GPP TSG RAN WG2 Meeting #85 R2-140269、2014年 1月31日アップロード、インターネット＜https://www.3gpp.org/ftp/tsg_ran/WG2_RL2/TSGR2_85/Docs/R2-140269.zip＞(以下、「公知例」という。)には、以下の事項が記載されている。(下線は当審が付与。) (a)「The underlying assumption for this approach is that any PDCP SDU will be eventually received. However such assumption is not valid since PDCP SDUs might be discarded at eNB due to flow control, and packet might be lost in Xn interface (although the probability is very low).Gaps in PDCP SN may stall the reordering procedure if timer is not used.Therefore it is proposed to use RLC UM like approach, which is more robust to handle these issues. The other benefit of RLC UM approach, as pointed out in[2], is that SeNB release procedure can also be handled, where MeNB needs to retransmit packets which are originally handled by SeNB.」(2ページ3-8行) (当審仮訳: このアプローチの基本的な前提は、PDCP SDUが最終的に受信されることである。ただし、フロー制御のためにPDCP SDUがeNBで破棄され、Xnインターフェースでパケットが失われる可能性があるため(確率は非常に低いが)、このような仮定は無効である。 タイマーが使用されていない場合、PDCP SNのギャップが並べ替え手順を停止することがある。したがって、RLC UMのようなアプローチを使用することを提案する。これは、これらの問題を処理するためにより堅牢である。 [2]で指摘されているように、RLC UMアプローチのもう1つの利点は、MeNBが本来SeNBによって処理されたパケットを再送信する必要があるSeNBリリース手順も処理できることである。) (b)「For dual connectivity, during SeNB release procedure, the bearer originally handled by both MeNB and SeNB will be handled by MeNB only. When SeNB is released, there are PDCP SDUs unacknowledged (RLC AM) and/or un-transmitted. MeNB needs to retransmit those SDUs. (中略) Option B: MeNB keeps PDCP SDUs handled by SeNB in the buffer. In this approach, either SeNB or UE should inform MeNB about PDCP Status (the SNs for correctly received and missing PDCP SDUs) so that MeNB can remove from the buffer those PDCP SDUs which are correctly received by the UE. (中略) 2) During SeNB release procedure, in RRC Connection Reconfiguration message, MeNB can request UE to transmit PDCP status report. MeNB can then perform retransmission accordingly.」(2ページ18-43行) (当審仮訳: デュアルコネクティビティの場合、SeNBリリース手順の間に、元々MeNBとSeNBの両方によって処理されていたベアラはMeNBのみによって処理される。SeNBがリリースされると、未確認(RLC AM)及び/又は未送信のPDCP SDUがある。MeNBはそれらのSDUを再送信する必要がある。 (中略) オプションB:MeNBは、SeNBが処理するPDCP SDUをバッファに保持する。このアプローチでは、MeNBがUEによって正しく受信されたPDCP SDUをバッファから削除できるように、SeNB又はUEがMeNBにPDCPステータス(正しく受信及び欠落したPDCP SDUのSN)を通知する必要がある。 (中略) 2)SeNBリリース手順の間、RRC再構成メッセージで、MeNBはUEにPDCPステータスレポートの送信を要求できる。MeNBは、それに応じて再送信を実行できる。) 公知例のタイトルにデュアルコネクティビティのオプション3Cと記載されているように、公知例はデュアルコネクティビティのオプション3Cを前提としている。 また、「PDCPステータス」は、正しく受信及び欠落したPDCP SDUのSNを含むものであり、「受信部によって受信済みのデータ又は未受信のデータを特定する受信状態情報」であるといえる。 よって、オプション3CのSeNBリリース手順の間に、PDCPステータスをUEがMeNBに通知することは、オプション3CのSeNBリリース手順の間に、受信部によって受信済みのデータ又は未受信のデータを特定する受信状態情報を、UEがMeNBへ送信することであるといえる。 したがって、公知例には以下の発明(以下「公知技術」という。)が記載されていると認める。 「 オプション3CのSeNBリリース手順の間に、受信部によって受信済みのデータ又は未受信のデータを特定する受信状態情報を、MeNBへ送信するUE。」 (ウ) 対比及び判断 本件補正発明と引用発明を対比すると、以下のとおりとなる。 (a)引用発明は、「MeNBとSeNBと2元接続中に、MeNBから送信されるデータの一部を当該MeNBとUEとの直接の経路を介して」UEが受信するとともに、「前記MeNBから送信されるデータの他の一部をSeNBを経由する経路を介して」UEが受信するものであるから、引用発明の「MeNB」、「SeNB」、「UE」は、それぞれ本件補正発明の「第1の通信装置」、「第2の通信装置」、「無線通信装置」に相当する。また、引用発明の「UEとの直接の経路」、「SeNBを経由する経路」は、それぞれ「第1の経路」、「第2の経路」に相当する。 そして、引用発明のUEは、「MeNBとUEとの直接の経路を介して」又は「SeNBを経由する経路を介して」データを受信するものであるから、「受信部」を有することが明らかである。よって、引用発明のUEが「MeNBとSeNBと2元接続中に、MeNBから送信されるデータの一部を当該MeNBとUEへの直接の経路を介して受信するとともに、前記MeNBから送信されるデータの他の一部をSeNBを経由する経路を介して受信すること」は、本件補正発明と同様に、「第1の通信装置と第2の通信装置と2元接続中に、前記第1の通信装置から送信されるデータの一部を当該第1の通信装置と第1の経路を介して受信するとともに、前記第1の通信装置から送信されるデータの他の一部を前記第2の通信装置を経由する第2の経路を介して受信する受信部を有すること」であるといえる。 (b)引用発明の、「MeNBがUEに対してRRC Connection Reconfigurationを送信することに応じて、SeNBが無線リソースを解放する」について、「MeNBがUEに対してRRC Connection Reconfigurationを送信する」ことは、本件補正発明の「第1の通信装置の制御」に含まれるから、引用発明は「第1の通信装置の制御に応じて」SeNBが無線リソースを解放するといえる。 また、UEが2元接続していたSeNBが無線リソースを解放することに伴って、SeNBの解放された無線リソースを介した通信に関する設定を変更する通信制御をUEが行うことは自明であり、UEはそのための「制御部」を有するといえる。 よって、引用発明の「UE」と本件補正発明の「無線通信装置」とは、「第1の通信装置の制御に応じて、通信制御が可能な制御部」を有する点で共通する。 (c)引用発明のUEは、「RRC Connection Reconfiguration CompleteをUEとの直接の経路を介してMeNBへ送信する」ものであり、そのためにRRC Connection Reconfiguration Completeを第1の経路を介してMeNBへ送信する「送信部」を有することが明らかであるから、引用発明の「UE」と本件補正発明の「無線通信装置」とは、「信号を第1の経路を介して第1の通信装置へ送信する送信部」を有する点で共通する。 したがって、本件補正発明と引用発明は、以下の点で一致し、また、相違している。 (一致点) 「 第1の通信装置と第2の通信装置と2元接続中に、前記第1の通信装置から送信されるデータの一部を当該第1の通信装置と第1の経路を介して受信するとともに、前記第1の通信装置から送信されるデータの他の一部を前記第2の通信装置を経由する第2の経路を介して受信する受信部と、 第1の通信装置の制御に応じて、通信制御が可能な制御部と、 信号を第1の経路を介して第1の通信装置へ送信する送信部と を有することを特徴とする無線通信装置。」 (相違点1) 「第1の通信装置」について、本件補正発明では、「2元接続中に前記第2の通信装置からの通知によって、前記第2の通信装置と前記第1の通信装置間でロスしたパケットに関する情報と、移動局に対して送信がなされなかったパケットに関する情報と、を取得することが可能な前記第1の通信装置」であるとの発明特定事項を有するのに対して、引用発明では当該事項が特定されていない点。 (相違点2) 「制御部」が行う「通信制御」について、本件補正発明では、「前記第1の通信装置との接続を1元接続に変更を行う通信制御」であるのに対して、引用発明では、SeNBの解放された無線リソースを介した通信に関する設定を変更する「通信制御」であって、「第1の通信装置との接続を1元接続に変更を行う通信制御」であることが特定されていない点。 (相違点3) 「送信部」について、本件補正発明では、「通信制御を行う場合に、前記受信部によって受信済みのデータ又は未受信のデータを特定する受信状態情報信号を第1の経路を介して第1の通信装置へ送信する送信部」であるのに対して、引用発明では「RRC Connection Reconfiguration Completeを第1の経路を介して第1の通信装置へ送信する送信部」であって、「通信制御を行う場合に、前記受信部によって受信済みのデータ又は未受信のデータを特定する受信状態情報信号」を送信することが特定されていない点。 以下、相違点について検討する。 (相違点1について) 本件補正発明は、「無線通信装置」であるところ、本件補正発明の「2元接続中に前記第2の通信装置からの通知によって、前記第2の通信装置と前記第1の通信装置間でロスしたパケットに関する情報と、移動局に対して送信がなされなかったパケットに関する情報と、を取得することが可能な前記第1の通信装置」との発明特定事項は、「第1の通信装置」の動作を特定する一方で、「無線通信装置」の動作等を何ら特定していないから、上記発明特定事項は、サブコンビネーションの発明である「無線通信装置」を特定するための意味を有しないものである。 したがって、相違点1は実質的な相違点ではない。 (相違点2について) MeNBとSeNBと2元接続するデュアルコネクティビティにおいて、SeNBが無線リソースを解放すると、もはや2元接続ではなくなるから、UEが、MeNBとの接続を1元接続に変更を行う通信制御を行うことは当業者にとって自明である。よって、引用発明において、SeNBが無線リソースを解放することに伴って、UEが「MeNBとの接続を1元接続に変更を行う通信制御」を行うことは、当業者が容易になし得ることである。 (相違点3について) 上記「(イ)」「b」の公知技術のとおり、「オプション3CのSeNBリリース手順の間に、受信部によって受信済みのデータ又は未受信のデータを特定する受信状態情報を、MeNBへ送信するUE。」が公知であり、引用発明と公知技術は、いずれもデュアルコネクティビティのオプション3Cにおいて、SeNBが無線リソースを解放することに関するものである。そして、データの欠落を防ぐことは通信における一般的な課題であって、SeNBが無線リソースを解放する際、データの欠落を防ぐために、MeNBが、UEが受信済みのデータ又は未受信のデータを特定することは、当業者が当然に考慮すべきことであるから、引用発明に公知技術を組み合わせることに格別の困難性はなく、阻害要因も見出せない。 そうすると、引用発明に公知技術を組み合わせ、SeNBが無線リソースを解放する場合、すなわち、UEがMeNBとの接続を1元接続に変更を行う通信制御を行う場合に、受信部によって受信済みのデータ又は未受信のデータを特定する受信状態情報をMeNBへ送信すること、すなわち、第1の通信装置との接続を1元接続に変更を行う通信制御を行う場合に、受信部によって受信済みのデータ又は未受信のデータを特定する受信状態情報を第1の経路を介して前記第1の通信装置へ送信することは、当業者が適宜なし得たことである。 また、本件補正発明の作用効果も、引用発明及び公知技術から当業者が予測し得る範囲内のものである。 したがって、本件補正発明は、引用発明及び公知技術に基づいて、当業者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許出願の際独立して特許を受けることができない。 ウ まとめ 本件補正は、特許法第17条の2第3項の規定に違反するものであり、また、特許法第17条の2第6項において準用する特許法第126条第7項の規定に違反するものであるから、特許法第159条第1項において読み替えて準用する特許法第53条第1項の規定により却下すべきものである。 第3 本願発明について 1.本願発明 本件補正は、上記のとおり却下されたので、本願の特許請求の範囲に記載された発明は、平成30年2月13日にされた手続補正により補正された特許請求の範囲の請求項1-8に記載された事項により特定されるところ、その請求項1に係る発明は、上記「第2」「1.」の項で示した本願発明のとおりのものと認める。 2.原査定の拒絶の理由 原査定の拒絶の理由は、「2.(進歩性)この出願の下記の請求項に係る発明は、その出願前に日本国内又は外国において、頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができない。」というものであり、本件補正前の請求項1に対して引用例(Ericsson,Dual Connectivity - non-mobility scenarios(当審仮訳:デュアルコネクティビティ-非モビリティシナリオ)、3GPP TSG-RAN WG3 Meeting #83 R3-140344、2014年2月1日アップロード、インターネット＜https://www.3gpp.org/ftp/tsg_ran/WG3_Iu/TSGR3_83/Docs/R3-140344.zip＞)、公知例(Intel Corporation、PDCP reordering for option 3C in dual Connectivity(当審仮訳:デュアルコネクティビティのオプション3CのためのPDCP並び替え)、3GPP TSG RAN WG2 Meeting #85 R2-140269、2014年 1月31日アップロード、インターネット＜https://www.3gpp.org/ftp/tsg_ran/WG2_RL2/TSGR2_85/Docs/R2-140269.zip＞)が引用されている。 なお、原査定の拒絶の理由で引用された特表2011-514033号公報は、請求項2に係る発明の構成の一部に関して引用されたものであるので、当該構成を備えていない本願発明の進歩性の判断に関連しないから、割愛する。 3.引用発明等 (1)引用発明 引用例に記載された引用発明は、上記「第2」「2.」「(2)」「イ」「(イ)」「a」の項で認定したとおりのものと認める。 (2)公知技術 公知例に記載された公知技術は、上記「第2」「2.」「(2)」「イ」「(イ)」「b」の項で認定したとおりのものと認める。 4.対比及び判断 本願発明は、上記「第2」「2.」「(2)」「イ」「(ア)」の項で検討した本件補正発明から、「第1の通信装置と第2の通信装置と2元接続中に」との限定事項、及び、「2元接続中に前記第2の通信装置からの通知によって、前記第2の通信装置と前記第1の通信装置間でロスしたパケットに関する情報と、移動局に対して送信がなされなかったパケットに関する情報と、を取得することが可能な前記第1の通信装置の制御に応じて」との限定事項を削除し、「前記第1の通信装置との接続を1元接続に変更を行う通信制御」を「前記第2の経路を介した通信に関する設定を変更する通信制御」との上位概念にしたものである。 そうすると、上記「第2」「2.」「(2)」「イ」の項で検討したとおり、本件補正発明は引用発明及び公知技術に基づいて当業者が容易に発明をすることができたものであるから、本願発明も同様の理由により、当業者が容易に発明をすることができたものである。 (付記 手続補正書(案)について) なお、令和1年12月3日に行われた面接において手続補正書(案)(以下、「補正案」という。)が提示されたので、当該補正案についても検討する。 補正案の特許請求の範囲に記載された請求項1の補正箇所に係る「前記第2の通信装置と前記第1の通信装置間でロスしたパケットと、移動局に対して送信がなされなかったパケットと、に応じた通知を前記第2の通信装置から受信する前記第1の通信装置」との発明特定事項は、「第1の通信装置」の動作を特定する一方で、「無線通信装置」の動作等を何ら特定していないから、上記発明特定事項は、サブコンビネーションの発明である「無線通信装置」を特定するための意味を有しないものであり、請求項1に係る発明は、上記「第2」「2.」「(2)」「イ」と同様の理由で進歩性がない。 次に、補正案の特許請求の範囲に記載された請求項6に係る発明(以下、「補正案発明」という。)の「前記第2の通信装置と自装置間でロスしたパケットと、前記第1の通信装置に対して送信がなされなかったパケットと、に応じた通知を前記第2の通信装置から受信する」との発明特定事項について検討する。 引用例(「第2」「2.」「(2)」「イ」「(イ)」「a」の項参照)によれば、MeNBは「前記第1の通信装置に対して送信がなされなかったパケットに応じた通知」をSeNBから受信するものである。 そして、本願の出願前に頒布された刊行物であるHuawei、Data Transmission to Support Dual Connectivity UP 3C(当審仮訳:デュアルコネクティビティUP3Cのためのデータ送信)、2014年1月31日アップロード、インターネット＜https://www.3gpp.org/ftp/tsg_ran/WG3_Iu/TSGR3_83/Docs/R3-140120.zip＞の 「2.2 X2 data loss detection and recovery Data loss overthe X2 interface may occur because of the unreliable transfer over X2, such as congestion along the path due to ineffective flow control, or SeNB buffer overflow if MeNB is too aggressive in offloading data to SeNB. The probability of X2 loss is very rare though, which is expected to be less than 10-6. The lost data should be retransmitted by radio network to avoid affecting the TCP congestion control. (中略)The reporting of a missing packet over Xn may be done periodically, e.g., upon MeNB's configuration, or it may be triggered upon timer expiry. Upon identifying an X2 loss, MeNB may decide to retransmit the data to SeNB over X2 again, or MeNB may also decide to transmit the data to UE over the air directly. 」(2ページ) (当審仮訳:2.2 X2データロスの検出と回復 X2インターフェースでのデータロスは、非効率的なフロー制御によるパスでの輻輳や、MeNBがSeNBにデータをオフロードする際に積極的すぎる場合のSeNBバッファオーバーフローなど、X2での信頼性の低い転送が原因で発生する場合がある。ただし、X2損失の確率は非常にまれであり、10-6未満であると予想される。 TCP輻輳制御への影響を避けるために、失われたデータは無線ネットワークによって再送信される必要がある。 (中略) Xnを介した欠落パケットの報告は、たとえばMeNBの設定時に定期的に行われる場合がある。又は、タイマーの終了時にトリガーされる場合がある。 X2の損失を特定すると、MeNBはX2を介してSeNBにデータを再送信することを決定するか、MeNBが直接無線でUEにデータを送信することを決定する。)(下線は当審で付した。) との記載によれば、「SeNBとMeNB間でロスしたパケットに応じた通知を、SeNBから受信するMeNB。」は周知事項であるから、引用例に記載された発明において、MeNBが「前記第1の通信装置に対して送信がなされなかったパケットに応じた通知」に加えて「前記第2の通信装置と自装置間でロスしたパケットに応じた通知」をSeNBから受信することは、当業者が適宜なし得ることである。 また、補正案発明の作用効果も、引用例、公知例(「第2」「2.」「(2)」「イ」「(イ)」「b」の項参照)、周知事項から当業者が予測し得る範囲内のものである。 そうすると、補正案発明は、引用例、公知例、周知事項に基づいて、当業者が容易に発明をすることができたものである。したがって、上記補正案は、採用できない。 第4 むすび 以上のとおり、本願発明は、特許法第29条第2項の規定により特許を受けることができないから、他の請求項について検討するまでもなく、拒絶すべきものである。 よって、結論のとおり審決する。 |
| 審理終結日 | 2020-01-08 |
| 結審通知日 | 2020-01-14 |
| 審決日 | 2020-01-27 |
| 出願番号 | 特願2016-508437(P2016-508437) |
| 審決分類 |
P
1
8・
121-
Z
(H04W)
P 1 8・ 537- Z (H04W) P 1 8・ 561- Z (H04W) P 1 8・ 575- Z (H04W) |
| 最終処分 | 不成立 |
| 前審関与審査官 | 廣川 浩 |
| 特許庁審判長 |
菅原 道晴 |
| 特許庁審判官 |
原田 聖子 本郷 彰 |
| 発明の名称 | 無線通信装置及び無線通信方法 |
| 代理人 | 特許業務法人酒井国際特許事務所 |