【事件の表示】
　特願２００９−５０９３３８「パケット通信方法及び受信側装置」拒絶査定不服審判事件〔平成２０年１０月２３日国際公開、ＷＯ２００８／１２６８２２〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１．手続の経緯
　本願は、２００８年４月７日（優先権主張　２００７年４月６日、日本国）の国際出願であって、平成２２年１０月２９日付けで拒絶査定がなされ、これに対し、平成２３年２月９日に拒絶査定に対する審判請求がなされるとともに同日付けで手続補正がなされたものである。
　
第２　補正却下の決定
　［補正却下の決定の結論］  
　　平成２３年２月９日付けの手続補正を却下する。
　
　［理由］
１．本願発明と補正後の発明
　上記手続補正（以下、「本件補正」という。）は、補正前の平成２２年９月１３日付けの手続補正書の特許請求の範囲の請求項４に記載された、
「　送信側装置のMACサブレイヤと受信側のMACサブレイヤとの間で、HARQ再送制御処理が行われており、該受信側装置のMACサブレイヤが、受信したRLC-PDUに対する順序補正処理を行うことなく、該受信側装置のRLCサブレイヤに対して該RLC-PDUを送信するパケット通信方法であって、
　第１のRLC-PDUのシーケンス番号が、第２のRLC-PDUのシーケンス番号よりも小さいとき、前記受信側装置のRLCサブレイヤが、該第１のRLC-PDUを受信する前に該第２のRLC-PDUを受信した場合に、順序補正タイマを起動する工程と、
　前記受信側装置のRLCサブレイヤが、前記順序補正タイマが満了するまでに、前記第１のRLC-PDUを受信しなかった場合、該第１のRLC-PDUを受信することはないと判断する工程とを有し、
　前記送信側装置のRLCサブレイヤと前記受信側装置のRLCサブレイヤとの間で確立されている論理チャネルを介して、前記第１のRLC-PDU及び前記第２のRLC-PDUが送信され、
　前記順序補正タイマは、前記論理チャネル毎に設定されることを特徴とするパケット通信方法。」
という発明（以下、「本願発明」という。）を、平成２３年２月９日付けの手続補正書の特許請求の範囲の請求項１に記載された、
　
「　送信側装置のMACサブレイヤと受信側のMACサブレイヤとの間で、HARQ再送制御処理が行われており、該受信側装置のMACサブレイヤが、受信したRLC-PDUに対する順序補正処理を行うことなく、該受信側装置のRLCサブレイヤに対して該RLC-PDUを送信するパケット通信方法であって、
　第１のRLC-PDUのシーケンス番号が、第２のRLC-PDUのシーケンス番号よりも小さいとき、前記受信側装置のRLCサブレイヤが、該第１のRLC-PDUを受信する前に該第２のRLC-PDUを受信した場合に、順序補正タイマを起動する工程と、
　前記受信側装置のRLCサブレイヤが、UMモードにおいて、前記順序補正タイマが満了するまでに、前記第１のRLC-PDUを受信しなかった場合、該第１のRLC-PDUを受信することはないと判断する工程とを有し、
　前記送信側装置のRLCサブレイヤと前記受信側装置のRLCサブレイヤとの間で確立されている論理チャネルを介して、前記第１のRLC-PDU及び前記第２のRLC-PDUが送信され、
　前記順序補正タイマは、前記論理チャネル毎に設定されることを特徴とするパケット通信方法。」
という発明（以下、「補正後の発明」という。）に補正することを含むものである。
　
２．補正の適否
（１）新規事項の有無、補正の目的要件について
　上記本件補正は、願書に最初に添付した明細書、特許請求の範囲又は図面に記載した事項の範囲内において、補正前の特許請求の範囲の請求項４の「前記受信側装置のRLCサブレイヤ」における「該第１のRLC-PDUを受信することはないと判断する工程」に関して、「UMモードにおいて」と限定して、特許請求の範囲を減縮するものであるから、平成２３年改正前特許法第１７条の２第３項（新規事項）及び同法第１７条の２第５項（補正の目的）の規定に適合している。
　　
（２）独立特許要件について
　上記本件補正は特許請求の範囲の減縮を目的とするものであるから、上記補正後の発明が、特許出願の際独立して特許を受けることができるものであるか（平成２３年改正前特許法第１７条の２第６項において準用する同法第１２６条第５項の規定に適合するか）について以下に検討する。
　
（２−１）　補正後の発明
　上記「１．本願発明と補正後の発明」の項で認定したとおりである。
　
（２−２）　引用発明
　Ａ．原査定の拒絶の理由に引用されたNTT DoCoMo, et al.著、「MAC reordering for LTE」、3gpp TSG RAN WG2#55 R2-062907、2006年10月5日、URL: http://www.3gpp.org/ftp/tsg_ran/WG2_RL2/TSGR2_55/Documents/R2-062907.zip（以下「引用例」という。）には、「MAC reordering for LTE」（当審仮訳：LTEに対するMACでの順序制御）として以下の事項（イ．〜ハ．）が記載されている。
　
（引用例）
　イ．「1.  Introduction
This document aims to close the open issue with regards to in-sequence delivery of RLC PDUs at MAC level, and provides a text proposal to the Stage 2 TS for E-UTRAN [1]. Specifically, the document addresses the following question:
Should MAC provide in-sequence delivery of RLC PDUs to RLC?」（１頁８−１２行）
　（当審仮訳）
　「1. はじめに
　この文書は、MACレベルのRLC PDUの順次送信に関する検討を終了することを目的とし、E-UTRANに対する仕様書ステージ２に文書提案をするものです。具体的には、この文書は次の問題を解決するものです。
　MACはRLCに対してRLC PDUの順次送信を提供するべきか。」
　
　ロ．「2.2 For LTE
In principle, in-sequence delivery needs to be provided only to the PDCP entity for radio bearers employing RoHC and to the application layer for radio bearers not employing RoHC. Therefore, MAC reordering of out of order caused by N-channel stop and wait is not needed. This resolves the above two performance issues observed for HSDPA and EUL (MAC level transmission window stalling and delay in delivering retransmitted RLC PDUs at the receiver MAC reordering entity).
Without in-sequence delivery from MAC, however, RLC needs to be more intelligent. Specifically, RLC cannot detect residual HARQ error just from out of order reception of RLC PDUs since the missing PDUs might reside in ongoing HARQ retransmissions. However, there are various simple ways to realize residual HARQ error detection in this case. For example, when an out of order RLC PDU is received, RLC can wait until all of the currently ongoing HARQ retransmissions are completed to determine whether there was a residual HARQ error or not. A simpler mechanism would be to run a timer which corresponds to a product of the HARQ RTT and maximum number of HARQ retransmissions (and some margin in the case of asynchronous HARQ) and to detect residual HARQ error if preceding RLC PDUs are still not received at timer expiry. Furthermore, MAC level detection of residual HARQ error based on unexpected toggling of NDI or no further HARQ retransmissions that have been proposed as part of HARQ ARQ interaction can also solve the issue.
Conclusion: Data received out of order data due to N-channel stop and wait HARQ does not to need to be reordered at receiver side MAC entity.」（１頁２３行−２頁５行）
　（当審仮訳）
   「原則として、順次送信（in sequence delivery)は、RoHCを使用する無線ベアラ用のPDCPエンティティ、およびRoHCを使用しない無線ベアラ用のアプリケーションレイヤーにのみ提供する必要があります。したがって、MACでNチャネル停止／待機によって引き起こされた順序が変わって受信したパケットを再整理する必要はありません。これによって、HSDPA、およびEULに対する上記の2つの性能の問題は解決されます。(MACレベルの送信ウィンドウの失速の問題及び受信側MACの順序整理エンティティでのRLC PDUの再送遅延の問題)。
　しかしながら、MACからの順次送信(in-sequence delivery)を無しとするためには、RLCはより知的である必要があります。具体的には、RLCは、順序が変わった(out of order)RLC PDUの受信のみからでは残余のHARQエラーを検知することができません。なぜなら、未受信のPDUが進行中のHARQ再送信によって受信するかもしれないためです。しかしながら、この場合残余のHARQ誤り検出を実現する様々な簡易な方法があります。例えば、RLC PDUの順序が変わって(out of order)受信した場合、残余のHARQエラーがあったか否かを判断するために、RLCは現在進行中のHARQ再送信が終了するまで待つことができます。より簡易な仕組みは、HARQ RTTおよびHARQ再送信の最大数（さらに、非同期HARQの場合、あるマージン）に相当するタイマーを起動することであり、タイマー満了時に、先行するRLC PDUが未だ受け取られていなければ、残余のHARQエラーを検知することでしょう。さらに、NDIの予期しないトグリング、または、HARQ ARQインタラクションの一部として提案されているHARQ再送信を行わないこと(no further HARQ retransmissions)、に基づく残余のHARQエラーのMACレベルでの検出も、この問題を解決することができます。
 
結論: Nチャネル停止／待機HARQにより生じた、順序が変わった状態で受信したデータを受信側のMACエンティティーにおいて順序整理する必要はありません。」
　
　ハ．「3.Text Proposal
6.1 MAC Sublayer
This subclause provides an overview on services and functions provided by the MAC sublayer.
6.1.1 Services and Functions
The main services and functions of the MAC sublayer include:
　- Mapping between logical channels and transport channels;
　- Multiplexing/demultiplexing of RLC PDUs belonging to one or different radio bearers into/from transport blocks (TB) delivered to/from the physical layer on transport channels;
　- Traffic volume measurement reporting;
　- Error correction through HARQ;
　- Priority handling between logical channels of one UE;
　- Priority handling between UEs by means of dynamic scheduling;
　- Transport format selection;
　- Mapping of Access Classes to Access Service Classes (FFS for RACH);
　- Padding (FFS);
NOTE: How the multiplexing relates to the QoS of the multiplexed logical channels is FFS.」（２頁６行−２１行）
　（当審仮訳）
　「3. テキスト提案
6.1 MACサブレイヤー
この小節は、MACサブレイヤーによって提供されるサービスと機能上の概観を提供します。
6.1.1 サービスおよび機能
MACサブレイヤーの主なサービスおよび機能は次のものを含んでいます:
- 論理チャネルとトランスポートチャネルの間のマッピング;
- 1つまたは異なる無線ベアラに属するRLC PDUを、トランスポートチャネル上の物理レイヤーにまたは物理レイヤーから配達されたトランスポートブロック(TB)へまたはトランスポートブロックから多重または分離する;
- トラフィック量の測定と報告;
- HARQによる誤り訂正;
- 1つのUEに対する複数論理チャネル間のプライオリティ取扱い;
- 動的スケジューリングによる複数UEの間のプライオリティ取扱い;
- トランスポートフォーマットの選択;
- 複数のアクセスクラスを複数のアクセスサービスクラスにマッピング(RACHについてさらに研究が必要);
- パディング(さらに研究が必要);
注:
多重化が多重論理チャネルのQoSにどのように関係があるかは、さらに研究が必要です。」
　                                               　
　上記引用例の記載及びこの分野における技術常識を考慮すると、
　（ａ）まず、上記引用例のハ．（２頁１０行及び１５行）にあるように、MACサブレイヤで、HARQ誤り訂正が行われることが記載されており、HARQ誤り訂正は自動再送制御で送受信装置間で行われることは技術常識であるから、引用例には『送信側装置のMACサブレイヤと受信側装置のMACサブレイヤの間で、HARQ誤り訂正が行われる』ことが記載されている。さらに、引用例のイ．（１頁１２行）及びロ．（２頁５−６行）には、「MACはRLCに対してRLC PDUの順次送信を提供するべきか。」及び「受信側装置のMACエンティティーで順序補正処理は必要ない。」とあるから、引用例には、「受信側装置のMACエンティティーでRLC PDUに対する順序補正処理は必要ない。」ことが記載されている。そして、引用例のイ．（１頁１２行）にはMACはRLC PDUを順次送信するべきかとあり、MACがRLC PDUをRLCに送信することを前提にしており、引用例に記載の技術はパケット通信に係るものであることは当業者に自明であるから、これらを総合すると、引用例には、
「送信側装置のMACサブレイヤと受信側装置のMACサブレイヤの間で、HARQ誤り訂正が行われ、
　受信側装置のMACエンティティーでRLC PDUに対する順序補正処理は必要なく、
  MACがRLC PDUをRLCに送信するパケット通信方法」
が記載されている。
　（ｂ）また、上記引用例のロ．（１頁３２行−２頁１行）にあるように、引用例には、「RLC PDUの順序が変わって(out of order)受信した場合、タイマーを起動する」ことが記載されている。
　（ｃ）また、上記引用例のロ．（１頁３５行−２頁３行）にあるように、「前記タイマーが満了するまでに、先行するRLC PDUを受信しない場合には、残余のHARQエラーと判断する」ことが記載されている。
　（ｄ）また、上記引用例のロ．（１頁３２行）にRLC PDUを受信するとあるから、RLC PDUが送信され、そして受信されることは当業者に自明であり、引用例のイ．（１頁１２行）に、MACは順次送信によりRLCにRLC PDUを送信するべきか、とあることから、前記RLC PDUはRLC間で送信されることもまた当業者に自明のことである。
　したがって、引用例には、「RLC間で、RLC PDUは送信される」ことが記載されている。
　（ｅ）また、上記引用例のロ．（１頁３３行−２頁１行）によれば、残余のHARQエラー検出のために「タイマーが設定される」ことが記載されている。　     
　したがって、上記引用例の記載及びこの分野における技術常識を考慮すると、上記引用例には、以下の発明（以下「引用発明」という。）が記載されているものと認められる。
   　
　（引用発明）
「送信側装置のMACサブレイヤと受信側装置のMACサブレイヤの間で、HARQ誤り訂正が行われ、
　受信側装置のMACエンティティーでRLC PDUに対する順序補正処理は必要なく、
  MACがRLC PDUをRLCに送信するパケット通信方法であって、
　RLC PDUの順序が変わって(out of order)受信した場合、タイマーを起動し、
　前記タイマーが満了するまでに、先行するRLC PDUを受信しない場合には、残余のHARQエラーと判断し、
　RLC間で、RLC PDUは送信され、
　タイマーが設定されるパケット通信方法。」
　
（２−３）　対比・判断
　［対比］
　補正後の発明と引用発明を対比する。
　
　（ア）まず、引用発明の「MACサブレイヤ」、「MACエンティティー」は、いずれも補正後の発明の「MACサブレイヤ」に相当する。引用発明の「HARQ誤り訂正」は補正後の発明の「HARQ再送制御処理」に相当する。また、引用発明の「RLC PDU」及び「RLC」は補正後の発明の「RLC-PDU」及び「RLCサブレイヤ」に相当する。そして、引用発明の「MACがRLC PDUをRLCに送信する」ことは、受信側装置のMACサブレイヤが受信側装置のRLCサブレイヤに対して、RLC-PDUを送信することであるから、結局、
　引用発明の「送信側装置のMACサブレイヤと受信側装置のMACサブレイヤの間で、HARQ誤り訂正が行われ、受信側装置のMACエンティティーでRLC PDUに対する順序補正処理は必要なく、MACがRLC PDUをRLCに送信するパケット通信方法」は、
　補正後の発明の「送信側装置のMACサブレイヤと受信側のMACサブレイヤとの間で、HARQ再送制御処理が行われており、該受信側装置のMACサブレイヤが、受信したRLC-PDUに対する順序補正処理を行うことなく、該受信側装置のRLCサブレイヤに対して該RLC-PDUを送信するパケット通信方法」に相当する。
  　
　（イ）また、引用発明の「RLC PDUの順序が変わって(out of order)受信した場合」とは、先に受信するRLC　PDUよりも後に受信するRLC　PDUを受信することを含むから、補正後の発明の「第１のRLC-PDUのシーケンス番号が、第２のRLC-PDUのシーケンス番号よりも小さいとき、前記受信側装置のRLCサブレイヤが、該第１のRLC-PDUを受信する前に該第２のRLC-PDUを受信した場合」と、「RLC PDUの順序が変わって(out of order)受信した場合」の点で共通である。
　また、引用発明の「タイマー」は、RLC PDUの順序が変わって受信した場合に起動されるものであり、上記対比を踏まえれば、補正後の発明の「順序補正タイマ」に相当する。
　したがって、引用発明の「RLC PDUの順序が変わって(out of order)受信した場合、タイマーを起動」することは、
　補正後の発明の「第１のRLC-PDUのシーケンス番号が、第２のRLC-PDUのシーケンス番号よりも小さいとき、前記受信側装置のRLCサブレイヤが、該第１のRLC-PDUを受信する前に該第２のRLC-PDUを受信した場合に、順序補正タイマを起動する工程」と、
「RLC-PDUの順序が変わって(out of order)受信した場合に、順序補正タイマを起動する工程」として共通である。
  　
　（ウ）また、引用発明の「先行するRLC PDU」は、補正後の発明の「第１のRLC-PDU」と、「先に受信する予定のRLC PDU」として共通である。
　また、引用発明の「残余のHARQエラー」は、補正後の発明の「該第１のRLC-PDUを受信することはない」と、「特定の状態」として共通するから、
　引用発明の「前記タイマーが満了するまでに、先行するRLC PDUを受信しない場合には、残余のHARQエラーと判断」することは、
　補正後の発明の「前記受信側装置のRLCサブレイヤが、UMモードにおいて、前記順序補正タイマが満了するまでに、前記第１のRLC-PDUを受信しなかった場合、該第１のRLC-PDUを受信することはないと判断」することと、
　「前記順序補正タイマが満了するまでに、先に受信する予定のRLC-PDUを受信しなかった場合、特定の状態と判断」する点で共通する。
　
　（エ）また、引用発明の「RLC間で、RLC PDUは送信」とは、上記（ａ）における認定を踏まえると、送信側装置のRLC と受信側装置のRLCとの間でRLC　PDUが送信されるといえる。さらに、送受信装置間で何らか信号を送信する場合に該送受信装置間にチャネルが確立されることは当業者に技術常識である。
　そして、上記（ア）のRLCサブレイヤに関する対比も踏まえると、
　引用発明の「RLC間で、RLC PDUは送信」は、
　補正後の発明の「前記送信側装置のRLCサブレイヤと前記受信側装置のRLCサブレイヤとの間で確立されている論理チャネルを介して、前記第１のRLC-PDU及び前記第２のRLC-PDUが送信」と、
　「前記送信側装置のRLCサブレイヤと前記受信側装置のRLCサブレイヤとの間で確立されているチャネルを介して、前記RLC-PDUが送信」される点で共通する。
  　
　（オ）また、引用発明の「タイマーが設定される」ことは、補正後の発明の「前記順序補正タイマは、前記論理チャネル毎に設定される」ことと「前記順序補正タイマは、設定される」点で共通である。
　
  したがって、両者は以下の点で一致し、また相違している。
　
　（一致点）
　「送信側装置のMACサブレイヤと受信側のMACサブレイヤとの間で、HARQ再送制御処理が行われており、該受信側装置のMACサブレイヤが、受信したRLC-PDUに対する順序補正処理を行うことなく、該受信側装置のRLCサブレイヤに対して該RLC-PDUを送信するパケット通信方法であって、
　RLC-PDUの順序が変わって(out of order)受信した場合に、順序補正タイマを起動する工程と、
　前記順序補正タイマが満了するまでに、先に受信する予定のRLC-PDUを受信しなかった場合、特定の状態と判断する工程とを有し、
　前記送信側装置のRLCサブレイヤと前記受信側装置のRLCサブレイヤとの間で確立されているチャネルを介して、前記RLC-PDUが送信され、
　前記順序補正タイマは、設定されるパケット通信方法。」
　
　（相違点）
　（１）「PLC-PDU」に関し、
　補正後の発明では、「シーケンス番号」を備えるのに対し、引用発明では、シーケンス番号を備えるか不明である点
　（２）さらに、「PLC-PDU」に関し、
　補正後の発明では、「第１のRLC-PDUのシーケンス番号が、第２のRLC-PDUのシーケンス番号よりも小さい」ものであり、「該第１のRLC-PDUを受信する前に該第２のRLC-PDUを受信した場合に、順序補正タイマを起動する」のに対し、
　引用発明では、「RLC PDUの順序が変わって(out of order)受信した場合に、タイマを起動する」点。
　（３）「RLC-PDUの順序が変わって(out of order)受信した場合」及び「先に受信する予定のRLC-PDUを受信しなかった場合」に関し、RLC-PDUを受信する／しない主体が
　補正後の発明では、「受信側のRLCサブレイヤ」であるのに対し、
　引用発明では、不明な点。
　（４）「判断する工程」に関し、
　補正後の発明では、「UMモードにおいて」行っているのに対し、
　引用発明では、UMモードにおいて行うか不明である点。
　（５）「先に受信する予定のRLC-PDU」に関し、
　補正後の発明では、「第１のRLC-PDU」であるのに対し、
　引用発明では、「先行するRLC PDU」である点。
　（６）「特定の状態」に関し、
　補正後の発明では、「該第１のRLC-PDUを受信することはない」ことであるのに対し、
　引用発明では、「残余のHARQエラー」である点。
　（７）「チャネル」に関し、
　補正後の発明では、「論理チャネル」であるのに対し、
　引用発明では、チャネルについて不明である点。
　（８）「順序補正タイマ」の設定に関し、
　補正後の発明では、「論理チャネル毎」にされているのに対し、
　引用発明では、どのように設けられているか不明である点。
　　
　［判断］
  上記相違点（１）について検討する。
　PDUがシーケンス番号を備え、PDUの順序管理や損失検出することは、当業者に周知のものであり（例えば、原審の拒絶の理由で示したSiemens著、「ARQ operation and HARQ」、3gpp TSG-RAN WG2#55 R2-062843、1頁32、33行及び2頁19行参照、2006年10月5日、URL、http://www.3gpp.org/ftp/tsg_ran/WG2_RL2/TSGR2_55/Documents/R2-062843.zip）、引用発明においてもRLC-PDUの順序管理や損失検出を行っているから、RLC-PDUがシーケンス番号を備えていると認められる。
　したがって、相違点（１）は実質的な相違ではない。
　
　上記相違点（２）及び、相違点（５）について検討する。
　引用発明の「RLC PDUの順序が変わって(out of order)受信した」とはその表現から、順序づけられた複数のRLC PDUが順序が入れ替わって受信した、または、ある順番のRLC PDUが抜けそれ以外のRLC PDUを受信したことを含むものである。そして、これらは、『先に受信する予定のRLC PDUを受信する前に、後に受信する予定のRLC PDUを受信したこと』、と同じ意味であるのは当業者に自明である。そして、『先に受信する予定のRLC PDU』を「第１のRLC-PDU」と呼ぶこと及び『後に受信する予定のRLC PDU』を「第２のRLC PDU」と呼ぶことは任意である。
　相違点（５）に関し、上記と同様の理由により、引用発明の「先行するRLC PDU」を「第１のRLC-PDU」と呼ぶことも任意である。
　したがって、引用発明に基づき、相違点（２）、（５）の構成とすることは格別のことではない。
　
　次に、相違点（３）について検討する。
　引用発明では、RLC PDUを受信する／しない主体について明記されていないものの、上記引用例のロ．（1頁33、34行）にRLC PDUの順序が変わって受信した場合に、RLCは待つことができる・・・、とあり、RLC PDUを受信できたか否かを最終的にRLC（RLCサブレイヤ）が認識することが示されている。そして、RLC PDUを受信する／しない主体を、RLC PDUを受信したか否かを最終的に確認する主体と同じRLC（RLCサブレイヤ）とすることは当業者が容易に想到し得るものといえ、相違点（３）は格別のものでない。
　したがって、引用発明に基づいて、相違点（３）の構成とすることは当業者が容易に想到し得るものである。
　
　次に、相違点（４）及び相違点（６）について検討する。
　引用発明が前提とするE-UTRANにおいて、RLCサブレイヤにAMモード、UMモード、TMモードの３つのモードがあることは、当業者に周知であるから(例えば、3GPP TR 25.813 V7.1.0(2006-09)（17頁23行−18頁3行参照）や原審の拒絶の理由で引用した国際公開２００５／１２５１２５号（3頁[18]参照））、引用発明において上記周知の3つのモードから適宜選択してUMモードを採用することに格別困難性を見いだせない。
　また、引用発明の「残余のHARQエラー」との判断は、RLC PDUを受信していないとの判断を意味することは当業者に周知である。（例えば、ITRI著、「Identification of residual HARQ errors in HSUPA」、3GPP TSG-RAN WG2 ad-hoc on LTE、2006年6月30日、Tdoc R2-062012 (3頁1−2行)URL: http://www.3gpp.org/ftp/tsg_ran/WG2_RL2/TSGR2_AHs/2006_06_LTE/Docs/R2-062012.zip参照）そして、該受信していないRLC PDUを再送により今後受信するか否かは上記AMモード(再送要求する）または上記UMモード(再送要求しない)に付随して決まることも当業者の技術常識であるから、引用発明の「残余のHARQエラー」と判断する構成において、上記検討したとおりUMモードを採用すれば、「第１のRLC-PDUを受信することはないと判断する」こととなるのは当業者に自明である。
　したがって、引用発明に基づいて、相違点（４）及び相違点（６）の構成とすることは格別のものではない。
　
　最後に、相違点（７）及び相違点（８）について検討する。
　送信側装置のRLCサブレイヤと受信側装置のRLCサブレイヤとの間で論理チャネルが確立されることは、例えば、3GPP TR 25.813 V7.1.0(2006-09)（13頁21行−24行及び図5.3a、URL: http://www.3gpp.org/ftp/Specs/2006-09/Rel-7/25_series/25813-710.zip参照）や原審の拒絶の理由で提示した国際公開２００５／１２５１２５号（2頁[12]参照）にみられるように、当業者に周知のものであり、引用発明においてRLC間で論理チャネルを確立することに格別困難性は認められない。
　また、引用発明においても複数の論理チャネルが用いられることは示されており（上記引用例ハ．2頁11、21行参照）、必要に応じて、残余のHARQエラーを検出するためにタイマーを複数の論理チャネル毎に設けることは当業者が適宜選択すべき設計事項と認められる。
　したがって、引用発明において、RLC間に論理チャネルを確立し、論理チャネル毎にタイマーを設け、相違点（７）及び相違点（８）の構成とすることは格別のものでない。
         　
　そして、補正後の発明の作用効果も、引用発明及び周知技術から当業者が予測できる範囲のものである。
　
　したがって、補正後の発明は、引用発明及び周知技術に基づいて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により、特許出願の際独立して特許を受けることができないものである。
　
３．むすび
　以上のとおり、本件補正は、平成２３年改正前特許法第１７条の２第６項において準用する同法第１２６条第５項〔独立特許要件〕の規定に違反するものであり、同法第１５９条第１項において読み替えて準用する同法第５３条第１項〔補正却下〕の規定により却下されるべきものである。
　
第３　本願発明について
１．本願発明
　本件補正は上記のとおり却下されたので、本願発明は、上記「第２．補正却下の決定」の「１．本願発明と補正後の発明」の項で「本願発明」として認定したとおりである。　
  　
２．引用発明
　引用発明は、上記「第２　補正却下の決定」の「（２−２）　引用発明」の項で認定したとおりである。
　
３．対比・判断
　本願発明は、上記補正後の発明から当該補正に係る構成を省いたものである。
　
　そうすると、本願発明の構成要件をすべて含み、さらに他の構成要件を付加又は限定した補正後の発明が、上記「第２　補正却下の決定」の「（２−３）対比・判断」の項に記載したとおり、引用発明及び周知技術に基づいて当業者が容易に発明をすることができたものであるから、本願発明も同様の理由により、当業者が容易に発明をすることができたものである。
　
４．むすび
　以上のとおり、本願発明は、引用発明及び周知技術に基づいて当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　
　よって、結論のとおり審決する。