【事件の表示】
　特願２０１６−５０８４３７「無線通信装置及び無線通信方法」拒絶査定不服審判事件〔平成２７年　９月２４日国際公開、ＷＯ２０１５／１４１０１２〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１　手続の経緯
　本願は、２０１４年（平成２６年）３月２０日を国際出願日とする出願であって、その手続の経緯は以下のとおりである。
平成２９年１１月２０日付け　　拒絶理由通知書
平成３０年　２月１３日　　　　意見書、手続補正書の提出
平成３０年　６月２７日付け　　拒絶理由通知書（最後）
平成３０年　９月　３日　　　　意見書、手続補正書の提出
平成３１年　２月２６日付け　　平成３０年９月３日にされた手続補正
　　　　　　　　　　　　　　　についての補正の却下の決定、拒絶査定
令和　１年　６月　５日　　　　拒絶査定不服審判の請求、
　　　　　　　　　　　　　　　手続補正書の提出
令和　１年１２月　３日　　　　面接、手続補正書（案）の提出
第２　令和１年６月５日にされた手続補正についての補正の却下の決定
［補正の却下の決定の結論］
　令和１年６月５日にされた手続補正（以下、「本件補正」という。）を却下する。
［理由］
１．補正の概要
　本件補正は、平成３０年２月１３日にされた手続補正により補正された特許請求の範囲の請求項１に記載された
「　第１の通信装置から送信されるデータの一部を当該第１の通信装置と第１の経路を介して受信するとともに、前記第１の通信装置から送信されるデータの他の一部を第２の通信装置を経由する第２の経路を介して受信する受信部と、
　前記第２の経路を介した通信に関する設定を変更する通信制御を行うことが可能な制御部と、
　前記通信制御を行う場合に、前記受信部によって受信済みのデータ又は未受信のデータを特定する受信状態情報を前記第１の経路を介して前記第１の通信装置へ送信する送信部と
　を有することを特徴とする無線通信装置。」
という発明（以下、「本願発明」という。）を、
「　
第１の通信装置と第２の通信装置と２元接続中に、前記
前記
　
前記２元接続中に前記第２の通信装置からの通知によって、前記第２の通信装置と前記第１の通信装置間でロスしたパケットに関する情報と、移動局に対して送信がなされなかったパケットに関する情報と、を取得することが可能な前記第１の通信装置の制御に応じて、前記第１の通信装置との接続を１元接続に変更を行う
御が
　前記通信制御を行う場合に、前記受信部によって受信済みのデータ又は未受信のデータを特定する受信状態情報を前記第１の経路を介して前記第１の通信装置へ送信する送信部と
　を有することを特徴とする無線通信装置。」
という発明（以下、「本件補正発明」という。）とすることを含むものである（下線は補正箇所を示すものとして請求人が付与したものである。）。
２．補正の適否
（１）新規事項の有無について
　本件補正発明の「前記２元接続中に前記第２の通信装置からの通知によって、前記第２の通信装置と前記第１の通信装置間でロスしたパケットに関する情報と、移動局に対して送信がなされなかったパケットに関する情報と、を取得することが可能な前記第１の通信装置の制御に応じて、前記第１の通信装置との接続を１元接続に変更を行う」との補正事項によれば、第１の通信装置は、第２の通信装置からの通知によって「前記第２の通信装置と前記第１の通信装置間でロスしたパケットに関する情報」及び「移動局に対して送信がなされなかったパケットに関する情報」を取得することになる。
　一方、願書に最初に添付した明細書、特許請求の範囲又は図面（以下、「当初明細書等」という。）には次の記載がある。
・「開示の技術は、かかる点に鑑みてなされたものであって、送受信されるユーザデータの不整合を防止することができる無線通信装置及び無線通信方法を提供することを目的とする。」（段落００１３）
・「第１に、スモール基地局２００を介した送信経路（Ｘ２インタフェース及び無線リンク）においてデータのロス（Ｘ２インタフェースにおけるパケットロスや、スモール基地局においてトラヒックの輻輳にって発生するバッファ溢れによるデータ廃棄又は無線リンクにおける送信失敗など）が発生し、移動局３００において、所望のデータが受信されなかった場合（ＰＤＣＰレイヤにおけるタイマの満了で検出が可能である）である。」（段落００２７）
・「また、受信部１２は、スモール基地局２００がエラー（通信の不具合）を検出した場合に、エラー検出通知をスモール基地局２００から受信する。」（段落００３７）
・「また、送信部２３は、移動局３００との間の通信においてエラーが検出された場合に、エラー検出通知をマクロ基地局１００へ送信する。ここで検出されるエラーは、例えば移動局３００へユーザデータを送信してから所定時間が経過してもユーザデータの受信確認（ＡＣＫ）が移動局３００から受信されないエラーや、ユーザデータの再送回数が所定の最大再送回数に到達するエラーなどである。なお、送信部２３は、マクロ基地局１００との間の通信においてエラーが検出された場合にも、エラー検出通知をマクロ基地局１００へ送信しても良い。」（段落００４２）
・「また、制御部２４は、移動局３００との間におけるデータの再送回数を監視し、再送回数が所定の最大再送回数に到達した場合に、エラーが発生したことを検出しても良い。さらに、制御部２４は、マクロ基地局１００から有線接続を介してパケットを受信してから所定時間が経過しても所望のパケットが受信されない場合に、エラーが発生したことを検出しても良い。制御部２４がエラーを検出すると、通信部２１は、有線接続を介してエラー検出通知をマクロ基地局１００へ送信する。」（段落００７０）
・「マクロ基地局１００においては、スモール基地局２００から送信されたエラー検出通知を受け、制御部１４によって、２元接続を一時的に解除して１元接続に切り替えることが決定される。」（段落０１００）
　これらの記載から、当初明細書等には、「第２の通信装置」に対応するスモール基地局２００が、「第１の通信装置」に対応するマクロ基地局１００との間の通信においてエラーが検出された場合、及び、「移動局」に対応する移動局３００との間の通信においてエラーが検出された場合に、エラー検出通知をマクロ基地局１００へ送信すること、エラー検出通知を受けたマクロ基地局１００が２元接続を一時的に解除して１元接続に切り替えること、が記載されているといえる。また、当初明細書の段落００２７及び段落００７０によれば、「第２の通信装置」に対応するスモール基地局２００を介した送信経路（Ｘ２インタフェース及び無線リンク）においてデータのロスが発生した場合にエラーが発生したことを検出すると記載されているといえる。しかしながら、当初明細書等には、エラー検出通知の中にどのような情報が含まれるかは開示されていない。
　そして、発明が解決しようとする課題は「送受信されるユーザデータの不整合を防止する」（段落００１３）ことであると認められるところ、当該課題と「第２の通信装置と前記第１の通信装置間でロスしたパケットに関する情報」及び「移動局に対して送信がなされなかったパケットに関する情報」との関連性は見出せない。ここで、仮にこれらの情報内容が、スモール基地局とideal backhaulで接続されたマクロ基地局において二元接続を解除するか否かの判断に寄与することがあるとしても、当初明細書等には二元接続を解除するか否かの判断については一切触れられておらず、また、当該判断は移動局に対応する本件補正発明の無線通信装置とは無関係のものである。
　したがって、出願時の技術常識を考慮しても、発明が解決しようとする課題に照らして、エラー検出通知に「前記第２の通信装置と前記第１の通信装置間でロスしたパケットに関する情報」及び「移動局に対して送信がなされなかったパケットに関する情報」が含まれることが記載されていると同然とはいえない。
　よって、本件補正は、当初明細書等のすべての記載を総合することにより導かれる技術的事項との関係において、第１の通信装置が第２の通信装置からの通知によって「前記第２の通信装置と前記第１の通信装置間でロスしたパケットに関する情報」及び「移動局に対して送信がなされなかったパケットに関する情報」を取得するという新たな技術的事項を導入するものであるから、令和１年６月５日付け手続補正書でした補正は、当初明細書等に記載した事項の範囲内においてするものとはいえず、特許法第１７条の２第３項に規定する要件を満たしていない。
（２）独立特許要件について
　上記（１）のとおり、本件補正は特許法第１７条の２第３項の規定に違反するものであるが、更に進めて、仮に、本件補正が限定的減縮（特許法第１７条の２第５項に掲げる事項）を目的とするものであるとして、本件補正発明が特許出願の際、独立して特許を受けることができるものであるか（特許法第１７条の２第６項において準用する特許法第１２６条第７項の規定に適合するか）についても以下に検討する。
ア　特許法第３６条第６項第１号について
　上記（１）のとおり、「前記２元接続中に前記第２の通信装置からの通知によって、前記第２の通信装置と前記第１の通信装置間でロスしたパケットに関する情報と、移動局に対して送信がなされなかったパケットに関する情報と、を取得することが可能な前記第１の通信装置の制御に応じて、前記第１の通信装置との接続を１元接続に変更を行う」ことは、本願出願当初の明細書等に記載されておらず、発明が解決しようとする課題に照らして自明な事項でもない。したがって、本件補正発明は発明の詳細な説明において、発明の課題が解決できることを当業者が認識できるように記載された範囲を超えるものであって、特許法第３６条第６項第１号の規定を満たしていない。
　よって、本件補正発明は、特許法第３６条第６項第１号の規定により特許出願の際独立して特許を受けることができない。
イ　特許法第２９条第２項について
（ア）　本件補正発明
　本件補正発明は、上記「１．」に記載したとおりのものと認める。
（イ）　引用例等に記載された事項及び引用発明等
ａ　引用発明
　原査定の拒絶の理由で引用されたEricsson，Dual Connectivity - non-mobility scenarios（当審仮訳：デュアルコネクティビティ−非モビリティシナリオ）、3GPP TSG-RAN WG3 Meeting #83 R3-140344、２０１４年２月１日アップロード、インターネット＜https://www.3gpp.org/ftp/tsg_ran/WG3_Iu/TSGR3_83/Docs/R3-140344.zip＞（以下、「引用例」という。）には、以下の事項が記載されている。（下線は当審が付与。）
（ａ）「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
（当審仮訳：
２．１　ＳｅＮＢの追加
（中略）
（図省略）
図２．１−１：ＳｅＮＢの追加
（中略）
注：
ＵＰオプション３Ｃの場合、ステップ８の後にユーザープレーンデータの送信が行われる場合がある
（ｂ）「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 
（当審仮訳：
２．５　ＳｅＮＢリリース−ＳｅＮＢによってトリガーされる
　このシナリオでは、ＳｅＮＢによってトリガーされるケースとの違いについて説明する。
ＳｅＮＢは、たとえばＵＥがＳｅＮＢリソースと同期していない、又はＵＥがしばらくＳｅＮＢリソースを使用しなかったことなどを認識する
（図省略）
図２．５−１：ＳｅＮＢリリース−ＳｅＮＢによってトリガーされる
　図２．５−１に見られるように、ＭｅＮＢによってトリガーされる場合との違いは準備フェーズである。フォワーディングトンネルを確立する必要がない場合（分割ベアラー又はＥ−ＲＡＢの完全な削除の場合）、
単一のメッセージ（ステップ１）でＲＲＣ再構成をトリガーできる
ＳｅＮＢはその直後に無線リソースを解放できる
　ここで、オプション３Ｃについての技術常識として、３ＧＰＰの規格書である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)、２０１３年発行には、次のように記載されている。
「8.1　Architecture and protocol enhancements for Dual connectivity
（中略）
8.1.1.8　Alternative 3C
（中略）
Figure 8.1.1.8-1: Alternative 3C」（３２−３８ページ）
（当審仮約：
８．１　デュアルコネクティビティのアーキテクチャ及びプロトコルの拡張
（中略）
８．１．１．８　オプション３Ｃ
（図省略）
図８．１．１．８−１：オプション３Ｃ）
　上記記載によると、次の技術常識が見てとれる。
「　デュアルコネクティビティのオプション３Ｃにおいて、ＵＥが、ＭｅＮＢとＳｅＮＢと２元接続中に、ＭｅＮＢから送信されるデータの一部を当該ＭｅＮＢとＵＥとの直接の経路を介して受信するとともに、前記ＭｅＮＢから送信されるデータの他の一部をＳｅＮＢを経由する経路を介して受信する。」
　上記（ａ）、（ｂ）の記載及び図面並びに当業者の技術常識を考慮すると、以下のことがいえる。
　引用例のタイトルに「デュアルコネクティビティ」と記載され、上記（ａ）はＵＰオプション３Ｃの場合について述べられているように、引用例がデュアルコネクティビティにおけるユーザープレーンについて、オプション３Ｃの場合を想定していることは明らかである。そして、デュアルコネクティビティのオプション３Ｃでは、ＵＥが、ＭｅＮＢとＳｅＮＢと２元接続中に、ＭｅＮＢから送信されるデータの一部を当該ＭｅＮＢとＵＥとの直接の経路を介して受信するとともに、前記ＭｅＮＢから送信されるデータの他の一部をＳｅＮＢを経由する経路を介して受信することは、当業者における技術常識である。
　したがって、引用例に記載されたＵＥは「ＭｅＮＢとＳｅＮＢと２元接続中に、ＭｅＮＢから送信されるデータの一部を当該ＭｅＮＢとＵＥへの直接の経路を介して受信するとともに、前記ＭｅＮＢから送信されるデータの他の一部をＳｅＮＢを経由する経路を介して受信する」といえる。
　上記（ｂ）の記載及び図２．５−１によれば、引用例には、ＳｅＮＢがメッセージ（ステップ１、SeNB Release Required）をＭｅＮＢに通知し、ＭｅＮＢがＵＥに対してRRC Connection Reconfiguration（ステップ４）を送信すると、ＳｅＮＢが無線リソースを解放することが記載されているといえる。
　したがって、「ＭｅＮＢがＵＥに対してRRC Connection Reconfigurationを送信することに応じて、ＳｅＮＢが無線リソースを解放する」といえる。
　上記（ｂ）の図２．５−１のステップ５によれば、ＵＥがRRC Connection Reconfiguration CompleteをＭｅＮＢへ送信することが見てとれる。すなわち、ＵＥは、「RRC Connection Reconfiguration CompleteをＵＥとの直接の経路を介してＭｅＮＢへ送信する」といえる。
　してみれば、引用例には次の発明（以下、「引用発明」という。）が記載されていると認める。
「　ＭｅＮＢとＳｅＮＢと２元接続中に、ＭｅＮＢから送信されるデータの一部を当該ＭｅＮＢとＵＥとの直接の経路を介して受信するとともに、前記ＭｅＮＢから送信されるデータの他の一部をＳｅＮＢを経由する経路を介して受信することと、
　ＭｅＮＢがＵＥに対してRRC Connection Reconfigurationを送信することに応じて、ＳｅＮＢが無線リソースを解放することと、
　RRC Connection Reconfiguration CompleteをＵＥとの直接の経路を介してＭｅＮＢへ送信することと、
　を有するＵＥ。」
ｂ　公知技術
　原査定の拒絶の理由で引用されたIntel Corporation、PDCP reordering for option 3C in dual Connectivity（当審仮訳：デュアルコネクティビティのオプション３ＣのためのＰＤＣＰ並び替え）、3GPP TSG RAN WG2 Meeting #85 R2-140269、２０１４年　１月３１日アップロード、インターネット＜https://www.3gpp.org/ftp/tsg_ran/WG2_RL2/TSGR2_85/Docs/R2-140269.zip＞（以下、「公知例」という。）には、以下の事項が記載されている。（下線は当審が付与。）
（ａ）「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 
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
（当審仮訳：
　このアプローチの基本的な前提は、ＰＤＣＰ　ＳＤＵが最終的に受信されることである。ただし、
フロー制御のためにＰＤＣＰ　ＳＤＵがｅＮＢで破棄され、Ｘｎインターフェースでパケットが失われる可能性がある
［２］で指摘されているように、ＲＬＣ　ＵＭアプローチのもう１つの利点は、ＭｅＮＢが本来ＳｅＮＢによって処理されたパケットを再送信する必要があるＳｅＮＢリリース手順も処理できる
（ｂ）「
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)
（中略）
2) 
During SeNB release procedure, in RRC Connection Reconfiguration message, MeNB can request UE to transmit PDCP status report.
（当審仮訳：
　
デュアルコネクティビティの場合、ＳｅＮＢリリース手順の間に、元々ＭｅＮＢとＳｅＮＢの両方によって処理されていたベアラはＭｅＮＢのみによって処理される。ＳｅＮＢがリリースされると、未確認（ＲＬＣ　ＡＭ）及び／又は未送信のＰＤＣＰ　ＳＤＵがある。ＭｅＮＢはそれらのＳＤＵを再送信する必要がある。
（中略）
　オプションＢ：ＭｅＮＢは、ＳｅＮＢが処理するＰＤＣＰ　ＳＤＵをバッファに保持する。このアプローチでは、ＭｅＮＢがＵＥによって正しく受信されたＰＤＣＰ　ＳＤＵをバッファから削除できるように、
ＳｅＮＢ又はＵＥがＭｅＮＢにＰＤＣＰステータス（正しく受信及び欠落したＰＤＣＰ　ＳＤＵのＳＮ）を通知する必要がある。
（中略）
2）
ＳｅＮＢリリース手順の間、ＲＲＣ再構成メッセージで、ＭｅＮＢはＵＥにＰＤＣＰステータスレポートの送信を要求できる
　公知例のタイトルにデュアルコネクティビティのオプション３Ｃと記載されているように、公知例はデュアルコネクティビティのオプション３Ｃを前提としている。
　また、「ＰＤＣＰステータス」は、正しく受信及び欠落したＰＤＣＰ　ＳＤＵのＳＮを含むものであり、「受信部によって受信済みのデータ又は未受信のデータを特定する受信状態情報」であるといえる。
　よって、オプション３ＣのＳｅＮＢリリース手順の間に、ＰＤＣＰステータスをＵＥがＭｅＮＢに通知することは、オプション３ＣのＳｅＮＢリリース手順の間に、受信部によって受信済みのデータ又は未受信のデータを特定する受信状態情報を、ＵＥがＭｅＮＢへ送信することであるといえる。
　したがって、公知例には以下の発明（以下「公知技術」という。）が記載されていると認める。
「　オプション３ＣのＳｅＮＢリリース手順の間に、受信部によって受信済みのデータ又は未受信のデータを特定する受信状態情報を、ＭｅＮＢへ送信するＵＥ。」
（ウ）　対比及び判断
　本件補正発明と引用発明を対比すると、以下のとおりとなる。
（ａ）引用発明は、「ＭｅＮＢとＳｅＮＢと２元接続中に、ＭｅＮＢから送信されるデータの一部を当該ＭｅＮＢとＵＥとの直接の経路を介して」ＵＥが受信するとともに、「前記ＭｅＮＢから送信されるデータの他の一部をＳｅＮＢを経由する経路を介して」ＵＥが受信するものであるから、引用発明の「ＭｅＮＢ」、「ＳｅＮＢ」、「ＵＥ」は、それぞれ本件補正発明の「第１の通信装置」、「第２の通信装置」、「無線通信装置」に相当する。また、引用発明の「ＵＥとの直接の経路」、「ＳｅＮＢを経由する経路」は、それぞれ「第１の経路」、「第２の経路」に相当する。
　そして、引用発明のＵＥは、「ＭｅＮＢとＵＥとの直接の経路を介して」又は「ＳｅＮＢを経由する経路を介して」データを受信するものであるから、「受信部」を有することが明らかである。よって、引用発明のＵＥが「ＭｅＮＢとＳｅＮＢと２元接続中に、ＭｅＮＢから送信されるデータの一部を当該ＭｅＮＢとＵＥへの直接の経路を介して受信するとともに、前記ＭｅＮＢから送信されるデータの他の一部をＳｅＮＢを経由する経路を介して受信すること」は、本件補正発明と同様に、「第１の通信装置と第２の通信装置と２元接続中に、前記第１の通信装置から送信されるデータの一部を当該第１の通信装置と第１の経路を介して受信するとともに、前記第１の通信装置から送信されるデータの他の一部を前記第２の通信装置を経由する第２の経路を介して受信する受信部を有すること」であるといえる。
（ｂ）引用発明の、「ＭｅＮＢがＵＥに対してRRC Connection Reconfigurationを送信することに応じて、ＳｅＮＢが無線リソースを解放する」について、「ＭｅＮＢがＵＥに対してRRC Connection Reconfigurationを送信する」ことは、本件補正発明の「第１の通信装置の制御」に含まれるから、引用発明は「第１の通信装置の制御に応じて」ＳｅＮＢが無線リソースを解放するといえる。
　また、ＵＥが２元接続していたＳｅＮＢが無線リソースを解放することに伴って、ＳｅＮＢの解放された無線リソースを介した通信に関する設定を変更する通信制御をＵＥが行うことは自明であり、ＵＥはそのための「制御部」を有するといえる。
　よって、引用発明の「ＵＥ」と本件補正発明の「無線通信装置」とは、「第１の通信装置の制御に応じて、通信制御が可能な制御部」を有する点で共通する。
（ｃ）引用発明のＵＥは、「RRC Connection Reconfiguration CompleteをＵＥとの直接の経路を介してＭｅＮＢへ送信する」ものであり、そのためにRRC Connection Reconfiguration Completeを第１の経路を介してＭｅＮＢへ送信する「送信部」を有することが明らかであるから、引用発明の「ＵＥ」と本件補正発明の「無線通信装置」とは、「信号を第１の経路を介して第１の通信装置へ送信する送信部」を有する点で共通する。
　したがって、本件補正発明と引用発明は、以下の点で一致し、また、相違している。
（一致点）
「　第１の通信装置と第２の通信装置と２元接続中に、前記第１の通信装置から送信されるデータの一部を当該第１の通信装置と第１の経路を介して受信するとともに、前記第１の通信装置から送信されるデータの他の一部を前記第２の通信装置を経由する第２の経路を介して受信する受信部と、
　第１の通信装置の制御に応じて、通信制御が可能な制御部と、
　信号を第１の経路を介して第１の通信装置へ送信する送信部と
　を有することを特徴とする無線通信装置。」
（相違点１）
　「第１の通信装置」について、本件補正発明では、「２元接続中に前記第２の通信装置からの通知によって、前記第２の通信装置と前記第１の通信装置間でロスしたパケットに関する情報と、移動局に対して送信がなされなかったパケットに関する情報と、を取得することが可能な前記第１の通信装置」であるとの発明特定事項を有するのに対して、引用発明では当該事項が特定されていない点。
（相違点２）
　「制御部」が行う「通信制御」について、本件補正発明では、「前記第１の通信装置との接続を１元接続に変更を行う通信制御」であるのに対して、引用発明では、ＳｅＮＢの解放された無線リソースを介した通信に関する設定を変更する「通信制御」であって、「第１の通信装置との接続を１元接続に変更を行う通信制御」であることが特定されていない点。
（相違点３）
　「送信部」について、本件補正発明では、「通信制御を行う場合に、前記受信部によって受信済みのデータ又は未受信のデータを特定する受信状態情報信号を第１の経路を介して第１の通信装置へ送信する送信部」であるのに対して、引用発明では「RRC Connection Reconfiguration Completeを第１の経路を介して第１の通信装置へ送信する送信部」であって、「通信制御を行う場合に、前記受信部によって受信済みのデータ又は未受信のデータを特定する受信状態情報信号」を送信することが特定されていない点。
　以下、相違点について検討する。
（相違点１について）
　本件補正発明は、「無線通信装置」であるところ、本件補正発明の「２元接続中に前記第２の通信装置からの通知によって、前記第２の通信装置と前記第１の通信装置間でロスしたパケットに関する情報と、移動局に対して送信がなされなかったパケットに関する情報と、を取得することが可能な前記第１の通信装置」との発明特定事項は、「第１の通信装置」の動作を特定する一方で、「無線通信装置」の動作等を何ら特定していないから、上記発明特定事項は、サブコンビネーションの発明である「無線通信装置」を特定するための意味を有しないものである。
　したがって、相違点１は実質的な相違点ではない。
（相違点２について）
　ＭｅＮＢとＳｅＮＢと２元接続するデュアルコネクティビティにおいて、ＳｅＮＢが無線リソースを解放すると、もはや２元接続ではなくなるから、ＵＥが、ＭｅＮＢとの接続を１元接続に変更を行う通信制御を行うことは当業者にとって自明である。よって、引用発明において、ＳｅＮＢが無線リソースを解放することに伴って、ＵＥが「ＭｅＮＢとの接続を１元接続に変更を行う通信制御」を行うことは、当業者が容易になし得ることである。
（相違点３について）
　上記「（イ）」「ｂ」の公知技術のとおり、「オプション３ＣのＳｅＮＢリリース手順の間に、受信部によって受信済みのデータ又は未受信のデータを特定する受信状態情報を、ＭｅＮＢへ送信するＵＥ。」が公知であり、引用発明と公知技術は、いずれもデュアルコネクティビティのオプション３Ｃにおいて、ＳｅＮＢが無線リソースを解放することに関するものである。そして、データの欠落を防ぐことは通信における一般的な課題であって、ＳｅＮＢが無線リソースを解放する際、データの欠落を防ぐために、ＭｅＮＢが、ＵＥが受信済みのデータ又は未受信のデータを特定することは、当業者が当然に考慮すべきことであるから、引用発明に公知技術を組み合わせることに格別の困難性はなく、阻害要因も見出せない。
　そうすると、引用発明に公知技術を組み合わせ、ＳｅＮＢが無線リソースを解放する場合、すなわち、ＵＥがＭｅＮＢとの接続を１元接続に変更を行う通信制御を行う場合に、受信部によって受信済みのデータ又は未受信のデータを特定する受信状態情報をＭｅＮＢへ送信すること、すなわち、第１の通信装置との接続を１元接続に変更を行う通信制御を行う場合に、受信部によって受信済みのデータ又は未受信のデータを特定する受信状態情報を第１の経路を介して前記第１の通信装置へ送信することは、当業者が適宜なし得たことである。
　また、本件補正発明の作用効果も、引用発明及び公知技術から当業者が予測し得る範囲内のものである。
　したがって、本件補正発明は、引用発明及び公知技術に基づいて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許出願の際独立して特許を受けることができない。
ウ　まとめ
　本件補正は、特許法第１７条の２第３項の規定に違反するものであり、また、特許法第１７条の２第６項において準用する特許法第１２６条第７項の規定に違反するものであるから、特許法第１５９条第１項において読み替えて準用する特許法第５３条第１項の規定により却下すべきものである。
第３　本願発明について
１．本願発明
　本件補正は、上記のとおり却下されたので、本願の特許請求の範囲に記載された発明は、平成３０年２月１３日にされた手続補正により補正された特許請求の範囲の請求項１−８に記載された事項により特定されるところ、その請求項１に係る発明は、上記「第２」「１．」の項で示した本願発明のとおりのものと認める。
２．原査定の拒絶の理由
　原査定の拒絶の理由は、「２．（進歩性）この出願の下記の請求項に係る発明は、その出願前に日本国内又は外国において、頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。」というものであり、本件補正前の請求項１に対して引用例（Ericsson，Dual Connectivity - non-mobility scenarios（当審仮訳：デュアルコネクティビティ−非モビリティシナリオ）、3GPP TSG-RAN WG3 Meeting #83 R3-140344、２０１４年２月１日アップロード、インターネット＜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（当審仮訳：デュアルコネクティビティのオプション３ＣのためのＰＤＣＰ並び替え）、3GPP TSG RAN WG2 Meeting #85 R2-140269、２０１４年　１月３１日アップロード、インターネット＜https://www.3gpp.org/ftp/tsg_ran/WG2_RL2/TSGR2_85/Docs/R2-140269.zip＞）が引用されている。
　なお、原査定の拒絶の理由で引用された特表２０１１−５１４０３３号公報は、請求項２に係る発明の構成の一部に関して引用されたものであるので、当該構成を備えていない本願発明の進歩性の判断に関連しないから、割愛する。
３．引用発明等
（１）引用発明
　引用例に記載された引用発明は、上記「第２」「２．」「（２）」「イ」「（イ）」「ａ」の項で認定したとおりのものと認める。
（２）公知技術
　公知例に記載された公知技術は、上記「第２」「２．」「（２）」「イ」「（イ）」「ｂ」の項で認定したとおりのものと認める。
４．対比及び判断
　本願発明は、上記「第２」「２．」「（２）」「イ」「（ア）」の項で検討した本件補正発明から、「第１の通信装置と第２の通信装置と２元接続中に」との限定事項、及び、「２元接続中に前記第２の通信装置からの通知によって、前記第２の通信装置と前記第１の通信装置間でロスしたパケットに関する情報と、移動局に対して送信がなされなかったパケットに関する情報と、を取得することが可能な前記第１の通信装置の制御に応じて」との限定事項を削除し、「前記第１の通信装置との接続を１元接続に変更を行う通信制御」を「前記第２の経路を介した通信に関する設定を変更する通信制御」との上位概念にしたものである。
　
　そうすると、上記「第２」「２．」「（２）」「イ」の項で検討したとおり、本件補正発明は引用発明及び公知技術に基づいて当業者が容易に発明をすることができたものであるから、本願発明も同様の理由により、当業者が容易に発明をすることができたものである。
（付記　手続補正書（案）について）
　なお、令和１年１２月３日に行われた面接において手続補正書（案）（以下、「補正案」という。）が提示されたので、当該補正案についても検討する。
　補正案の特許請求の範囲に記載された請求項１の補正箇所に係る「前記第２の通信装置と前記第１の通信装置間でロスしたパケットと、移動局に対して送信がなされなかったパケットと、に応じた通知を前記第２の通信装置から受信する前記第１の通信装置」との発明特定事項は、「第１の通信装置」の動作を特定する一方で、「無線通信装置」の動作等を何ら特定していないから、上記発明特定事項は、サブコンビネーションの発明である「無線通信装置」を特定するための意味を有しないものであり、請求項１に係る発明は、上記「第２」「２．」「（２）」「イ」と同様の理由で進歩性がない。
　次に、補正案の特許請求の範囲に記載された請求項６に係る発明（以下、「補正案発明」という。）の「前記第２の通信装置と自装置間でロスしたパケットと、前記第１の通信装置に対して送信がなされなかったパケットと、に応じた通知を前記第２の通信装置から受信する」との発明特定事項について検討する。
　引用例（「第２」「２．」「（２）」「イ」「（イ）」「ａ」の項参照）によれば、ＭｅＮＢは「前記第１の通信装置に対して送信がなされなかったパケットに応じた通知」をＳｅＮＢから受信するものである。
　そして、本願の出願前に頒布された刊行物であるHuawei、Data Transmission to Support Dual Connectivity UP 3C（当審仮訳：デュアルコネクティビティＵＰ３Ｃのためのデータ送信）、２０１４年１月３１日アップロード、インターネット＜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
The lost data should be retransmitted by radio network
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
（当審仮訳：２．２　Ｘ２データロスの検出と回復
　
Ｘ２インターフェースでのデータロス
　ＴＣＰ輻輳制御への影響を避けるために、
失われたデータは無線ネットワークによって再送信される必要がある。
Ｘｎを介した欠落パケットの報告は、たとえばＭｅＮＢの設定時に定期的に行われる場合がある。又は、タイマーの終了時にトリガーされる場合がある。 Ｘ２の損失を特定すると、ＭｅＮＢはＸ２を介してＳｅＮＢにデータを再送信することを決定するか、ＭｅＮＢが直接無線でＵＥにデータを送信することを決定する
との記載によれば、「ＳｅＮＢとＭｅＮＢ間でロスしたパケットに応じた通知を、ＳｅＮＢから受信するＭｅＮＢ。」は周知事項であるから、引用例に記載された発明において、ＭｅＮＢが「前記第１の通信装置に対して送信がなされなかったパケットに応じた通知」に加えて「前記第２の通信装置と自装置間でロスしたパケットに応じた通知」をＳｅＮＢから受信することは、当業者が適宜なし得ることである。
　また、補正案発明の作用効果も、引用例、公知例（「第２」「２．」「（２）」「イ」「（イ）」「ｂ」の項参照）、周知事項から当業者が予測し得る範囲内のものである。
　そうすると、補正案発明は、引用例、公知例、周知事項に基づいて、当業者が容易に発明をすることができたものである。したがって、上記補正案は、採用できない。
第４　むすび
　以上のとおり、本願発明は、特許法第２９条第２項の規定により特許を受けることができないから、他の請求項について検討するまでもなく、拒絶すべきものである。
　よって、結論のとおり審決する。