拒絶査定不服の審決｜不服2017-11273 - 特許審決データベース

会員機能

ランキング

請求人別審判件数

判例データベース

審決データベース

ポートフォリオ機能

ポートフォリオを新規に作成して保存		追加
既存のポートフォリオに追加保存		追加

この審決の個人情報、企業機密に関する修正依頼をする

PDF	PDFをダウンロード

審決分類	審判査定不服 2項進歩性特許、登録しない。 H04W
管理番号	1349566
審判番号	不服2017-11273
総通号数	232
発行国	日本国特許庁(JP)
公報種別	特許審決公報
発行日	2019-04-26
種別	拒絶査定不服の審決
審判請求日	2017-07-28
確定日	2019-03-08
事件の表示	特願2015-500995「ACK/NACK用の拡張PUCCHリソースをEPDCCHによって使用されるeCCEに暗黙的にリンクする方法」拒絶査定不服審判事件〔平成25年 9月26日国際公開、WO2013/140237、平成27年 4月27日国内公表、特表2015-512575〕について、次のとおり審決する。
結論	本件審判の請求は、成り立たない。
理由	第1 手続の経緯本願は、2013年3月4日(パリ条約による優先権主張外国庁受理 2014年3月19日中国)を国際出願日とする特許出願であって、その後の手続の概要は、以下のとおりである。平成27年 8月21日付け:拒絶理由通知書平成28年 2月25日 :意見書及び手続補正書の提出平成28年 7月 6日付け:拒絶理由通知書平成29年 1月12日 :意見書及び手続補正書の提出平成29年 3月22日付け:拒絶査定平成29年 7月28日 :拒絶査定不服審判の請求第2 原査定の拒絶の理由原査定の拒絶の理由は、この出願の請求項1-10に係る発明は、その出願の前に日本国内又は外国において、頒布された又は電気通信回線を通じて公衆に利用可能となった下記の引用例1,2に記載された発明に基づいて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法29条2項の規定により特許を受けることができない、というものである。引用例1.Samsung,HARQ-ACK Transmission in Response to E-PDCCH Detection[online],3GPP TSG-RAN WG1#68 R1-120193,インターネット＜URL:http://www.3gpp.org/ftp/tsg_ran/WG1_RL1/TSGR1_68/Docs/R1-120193.zip＞,2012年1月31日掲載引用例2.ASUSTeK,PUCCH Resource Allocation Corresponding to ePDCCH[online],3GPP TSG-RAN WG1#68 R1-120666,インターネット＜URL:http://www.3gpp.org/ftp/tsg_ran/WG1_RL1/TSGR1_68/Docs/R1-120666.zip＞,2012年1月31日掲載第3 本願発明本願の請求項に係る発明は、平成29年1月12日にされた手続補正により補正された特許請求の範囲の請求項1ないし13に記載された事項により特定されるものであるところ、その請求項1に係る発明(以下「本願発明」という。)は、その請求項1に記載された事項により特定される、以下に記載のとおりのものと認める。「通信システムの基地局において、ACK/NACK用の拡張PUCCHリソースを、EPDCCHによって使用されるeCCEに暗黙的にリンクする方法であって、前記基地局は、ユーザ機器にサービスし、前記EPDCCHは、送信のために前記eCCEを使用し、前記方法は、 a.前記ACK/NACK用の複数の前記拡張PUCCHリソースに番号設定するステップであって、前記複数の拡張PUCCHリソースの各々が、1つのユーザ機器に対応する、ステップと、 b.すべての前記EPDCCHによって使用される前記eCCEに番号設定するステップと、 c.前記拡張PUCCHリソースの前記番号設定と前記eCCEの前記番号設定との間のリンクを決定するステップと、 d.前記リンク、および前記拡張PUCCHリソースの前記番号設定に関連付けられた第1の情報を、前記ユーザ機器と共有するステップと、 e.前記eCCEの前記番号設定に関連付けられた第2の情報を前記ユーザ機器に送信するステップと、を含む方法。」第4 引用発明 1 引用例1 原査定の拒絶の理由で引用された本願の優先日前に電気通信回線を通じて公衆に利用可能となった、Samsung,HARQ-ACK Transmission in Response to E-PDCCH Detection(当審訳:「E-PDCCH検出に応答したHARQ-ACK伝送」)[online],3GPP TSG-RAN WG1#68 R1-120193,インターネット＜URL:http://www.3gpp.org/ftp/tsg_ran/WG1_RL1/TSGR1_68/Docs/R1-120193.zip＞,2012年1月31日掲載(以下「引用例1」という。)には、図面とともに、次の記載がある。 (1) 「2 PUCCH Resources for HARQ-ACK The Rel.10 method for determining the PUCCH resource for an HARQ-ACK transmission in response to a PDCCH detection consists of 2 parts: a)The determination of the starting point of the PUCCH resources for HARQ-ACK transmissions. b)The determination of the PUCCH resource for HARQ-ACK transmission relative to the starting point of these PUCCH resources. The PUCCH resource n_(PUCCH) for HARQ-ACK transmission is obtained as n_(PUCCH) = n_(CCE) + N^((1))_(PUCCH )with the cell-specific offset N^((1))_(PUCCH )providing the starting point of the PUCCH resources and the first CCE of the detected PDCCH, n_(CCE ), providing the HARQ-ACK resource relative to the starting point of the PUCCH resources」(1ページ13-21行) (当審訳: 「2 HARQ-ACKのためのPUCCHリソース PDCCH検出に応答してHARQ-ACK送信のためのPUCCHリソースを決定するためのリリース10の方法は、2つの部分からなる。 a)HARQ-ACK送信のためのPUCCHリソースの開始点の決定。 b)これらのPUCCHリソースの開始点に関するHARQ-ACK送信のためのPUCCHリソースの決定。 HARQ-ACK送信のためのPUCCHリソース n_(PUCCH) は、n_(PUCCH) = n_(CCE) + N^((1))_(PUCCH)で与えられる。ここで、セル特有のオフセットN^((1))_(PUCCH) はPUCCHリソースの開始点を提供し、検出されたPDCCHの最初のCCEであるn_(CCE)はPUCCHリソースの開始点に関連するHARQ-ACKリソースを提供する。」) (2) 「In designing Rel-11 PUCCH HARQ-ACK indexing, a first issue is whether the same or separate PUCCH resources are used for HARQ-ACK transmission in resopnse to legacy PDCCH detection and E-PDCCH detection.The motivation for using the same set of resources is UL overhead reduction. As PUCCH resources for legacy HARQ-ACK transmissions are typically significantly over-dimensioned (many more CCEs exist than the number of UEs transmitting HARQ-ACK in respective PUCCHs), resource sharing is fundamentally possible in order to avoid increasing UL overhead by configuring additional PUCCH resources.」(1ページ22-27行) (当審訳: 「リリース11のPUCCH HARQ-ACKインデキシング設計において、最初の問題は、従来のPDCCH検出と同じ又は異なるPUCCHリソースをE-PDCCH検出に応答したHARQ-ACK転送のために、用いるかということである。同じリソースセットを使用する動機は、ULオーバーヘッド削減である。レガシーHARQ-ACK送信のためのPUCCHリソースは、一般的に著しく過剰になる(各PUCCHにおいてHARQ-ACKを送信するUEの数よりも多くのCCEが存在する)ので、リソースの共有は追加のPUCCHリソースを構成することによるULオーバーヘッドを増加させることを避けることが原理的に可能である。」 (3) 「In case the same set of PUCCH resources is used, one issue is the potential collisions. Assuming that an E-PDCCH consists of E-CCEs, if the same rule as in Rel.10 applies for the PUCCH resource determination for an HARQ-ACK transmission in response to an E-PDCCH detection, n^(E)_(PUCCH) , (for example, implicit resource determination in some form of n^(E)_(PUCCH) = n_(E-CCE) + N^((1))_(PUCCH )), a collision will occur if the first E-CCE for the detected E-PDCCH, n_(CCE-E)(当審注:「n_(E-CCE)」の誤記) , is the same as the first CCE of a detected PDCCH n_(CCE). Two possibilities exist to avoid collisions. The first is to leave it to the network implementation where, under some scheduling restrictions, the first CCE of each PDCCH for DL assignments is different than the first E-CCE of each E-PDCCH for DL assignments. As the search space design for E-PDCCHs is not yet determined, evaluating the impact of such a restriction is not possible but assuming a similar search space design as for the PDCCH (at least for distributed E-PDCCH transmissions), an increase in the blocking probability can be expected (FFS how significant). The second possibility is to introduce a hybrid of explicit and implicit resource determination as for the PHICH or for PUCCH format 3. This can be done by introducing an A/N Resource Indication (ARI) field in the DCI formats conveyed by E-PDCCH (e.g. 2 bits).」(1ページ30-41行) (当審訳: 「PUCCHリソースの同じセットが使用される場合、1つの問題は潜在的な衝突である。E-PDCCHがE-CCEからなると仮定すると、E-PDCCH検出に応答してHARQ-ACK送信のためのPUCCHリソース決定n^(E)_(PUCCH)にRel.10と同じ規則(例えば、n^(E)_(PUCCH) = n_(E-CCE) + N^((1))_(PUCCH) の形式の暗黙のリソース決定)が適用される場合、検出されたE-PDCCHの最初のE-CCEであるn_(E-CCE)が検出されたPDCCHの最初のCCEであるn_(CCE)がとまさに同じものである場合、衝突が発生するであろう。衝突を回避するには2つの可能性がある。一つ目の可能性は、ネットワークの実装にまかせるものであり、スケジューリングの制約の下で、DL割当ての各PDCCHの最初のCCEが、DL割当てのための各E-PDCCHの最初のE-CCEと異なるものとすることである。E-PDCCHのサーチスペースのデザインはまだ決定されていないので、このような制限のインパクトの評価は不可能であるが、PDCCHのためのサーチスペースのデザインと同様であると仮定すると(少なくとも分散E-PDCCH伝送の)、ブロッキングの可能性の上昇は期待される(どの程度のものであるか将来の課題である。)。二つ目の可能性はPHICH又はPUCCH format 3として明示及び暗示のリソース決定を複合したものを導入することである。このことは、E-PDCCHによるDCIフォーマットの伝送におけるA/Nリソースインディケーション(ARI)フィールド(例えば2ビット)の導入によってなされるだろう。」 (4) 「In case different sets of PUCCH resources are used then, considering legacy UEs, the ones corresponding to HARQ-ACK transmissions in response to E-PDCCH detections should be preferable placed between the legacy ones and the PUSCH resources in order to maximize the potential for frequency diversity. The starting position can be determined depending on whether a UE can detect legacy control channels. If so, based on the PCFICH value, the number of CCEs can be determined and the E-CCEs can be numbered after the CCEs. If not, the starting position can be configured by the network through an offset, N^((1))_(PUCCH-E ), and the transmission can occur anywhere either between the legacy PUCCH resources and the PUSCH resources (N^((1))_(PUCCH-E) > N^((1))_(PUCCH )- e.g. Figure 1) or prior to legacy PUCCH format 1a/1b resources associated with dynamic HARQ-ACK signaling (N^((1))_(PUCCH-E) < N^((1))_(PUCCH ) ). The network has enough flexibility in choosing the starting position. (中略) Figure 1: Resource Partitioning for HARQ-ACK Taransmissions in Response to PDCCH or E-PDCCH Detection.」(2ページ1-9行) (当審訳: 「PUCCHリソースの異なるセットが使用される場合、レガシーUEを考慮して、E-PDCCH検出に応答するHARQ-ACKの送信に対応するPUCCHリソースのセットは、周波数ダイバーシチのポテンシャルを最大化するために、レガシーのPUCCHリソースとPUSCHリソースとの間に配置されることが好ましい。開始位置は、UEがレガシーのコントロールチャネルを検出できるかどうかによって決定することができる。そうであれば、PCFICHの値に基づいて、CCEの数を決定することができ、E-CCEはCCEの後に番号付けすることができる。そうでない場合には、ネットワークによってオフセット, N^((1))_(PUCCH-E)を介して開始位置を設定することができ、伝送は、レガシーPUCCHリソースとPUSCHリソースとの間(N^((1))_(PUCCH-E) > N^((1))_(PUCCH) - 例えば図1)、又は動的なHARQ-ACKシグナリングを伴うレガシーPUCCHフォーマット1a / 1bリソースの前(N^((1))_(PUCCH-E) < N^((1))_(PUCCH))に起こる。ネットワークは開始位置を選択する十分な柔軟性を有する。 (中略) 図1:PDCCH又はE-PDCCH検出への応答におけるHARQ-ACK伝送のためのリソースのパーティショニング」) 上記(1)-(4)の記載及び当該分野の技術常識を考慮すると以下のことがいえる。上記(4)の図1によればN^((1))_(PUCCH-E )がE-PDCCHに対応するHARQ-ACKリソースの始点、_( )N^((1))_(PUCCH) がPDCCHに対応するHARQ-ACKリソースの始点であることが見て取れる。上記(3)によれば、PUCCHリソースの同じセットが使用される場合、E-PDCCHがE-CCEで構成されると仮定し、E-PDCCH検出に応答してHARQ-ACK送信のためのPUCCHリソース決定n^(E)_(PUCCH)にRel.10と同じ規則(例えば、n^(E)_(PUCCH) = n_(E-CCE) + N^((1))_(PUCCH)の形式の暗黙のリソース決定)を採用すると、n_(E-CCE)とn_(CCE)がとまさに同じものであると衝突が発生することがあること、上記(4)によれば、PUCCHリソースの異なるセットが使用される場合、E-CCEはCCEの後に番号付けするか、ネットワークによってオフセット N^((1))_(PUCCH-E)を介して開始位置を設定することができることが記載されていると認められる。そして、図1によれば、PUCCHリソースの異なるセットとして、オフセット N^((1))_(PUCCH-E) より上方(外側)の「For PDCCH」で表されるPUCCHリソースと、オフセット N^((1))_(PUCCH-E) より下方(内側)の「For E-PDCCH」で表されるPUCCHリソースとが使用されることが見てとれる。ここで、「For E-PDCCH」で表されるPUCCHリソースを、便宜上、以下「PUCCH-E」という。してみると、PUCCHリソースの異なるセットが使用される場合でネットワークによってオフセット N^((1))_(PUCCH-E)を介して開始位置を設定する場合、PUCCH-Eリソース決定n^(E)_(PUCCH)が、n^(E)_(PUCCH) = n_(E-CCE) + N^((1))_(PUCCH-E)となることは図1に照らして当業者に自明であり、これはPUCCH-Eリソースの番号設定とE-CCEの番号設定との間のリンクといえ、通信システムの基地局においてHARQ-ACK用のPUCCH-Eリソースを、E-PDCCHを構成するE-CCE番号から暗黙的に決定するものといえる。。また、n^(E)_(PUCCH) がPUCCH-Eリソースの番号であり、n_(E-CCE)がE-CCEの番号であることは当業者に明らかであるから、当該リンクを示す数式の前提として、HARQ-ACK用の複数のPUCCH-Eリソースに番号設定されていること、すべてのE-PDCCHによって使用されるE-CCEに番号設定されていることは当然のことに過ぎない。したがって、引用例1には以下の発明(以下「引用発明」という。)が記載されていると認める。「通信システムの基地局において、HARQ-ACK用のPUCCH-Eリソースを、E-PDCCHを構成するE-CCEの番号から暗黙的に決定する方法であって、前記E-PDCCHは、送信のためにE-CCEを使用し、前記方法は、前記HARQ-ACK用の複数のPUCCH-Eリソースに番号設定するステップと、すべての前記E-PDCCHによって使用される前記E-CCEに番号設定するステップと、前記PUCCH-Eリソースの番号設定と前記E-CCEの番号設定との間のリンクを決定するステップと、を含む方法。」 2 引用例2 原査定の拒絶の理由で引用された本願の優先日前に電気通信回線を通じて公衆に利用可能となった引用例であるASUSTeK,PUCCH Resource Allocation Corresponding to ePDCCH(当審訳:「ePDCCHに対応するPUCCHリソース割当て」)[online],3GPP TSG-RAN WG1#68 R1-120666,インターネット＜URL:http://www.3gpp.org/ftp/tsg_ran/WG1_RL1/TSGR1_68/Docs/R1-120666.zip＞,2012年1月31日掲載(以下「引用例2」という。)には、次の記載がある。「2. Discussion The enhanced physical downlink control channel (ePDCCH) is a newly designed control channel to carrier DL assignments and uplink grants in adaptation to different scenarios in Rel.11. Accordingly, several relative channels are required to be considered, such as PCFICH, PHICH, and PUCCH. Considering PUCCH, the main issue is how to determine the PUCCH 1a/1b resource based on the DL assignment receiving from ePDCCH [1]. For legacy PDCCH, the PUCCH 1a/1b resource is determined by n^((1))_(PUCCH) = n_(CCE) + N^((1))_(PUCCH) , where n_(CCE) is the number of the first CCE (i.e. lowest CCE index used to construct the PDCCH) used for transmission of the corresponding DCI assignment and N^((1))_(PUCCH) is the parameter n1PUCCH-AN included in the IE PUCCH-ConfigCommon configured by higher layer. (中略) Then, the PUCCH 1a/1b resource corresponding to ePDCCH could be indicated by the eCCE index and a higher layer configured parameter as similar in LTE. (中略) Thus, in order to feedback the HARQ-ACK for the DL transmission scheduled by ePDCCH, one possible method is that the eCCE index for indicating PUCCH 1a/1b resource is numbered within the search space configured for a UE. In this case, the higher-layer configured parameter to determine PUCCH 1a/1b resource corresponding to ePDCCH could be different for different UEs.」(1葉12-37行) (当審訳: 「2.ディスカッション拡張物理下りリンク制御チャネル(ePDCCH)は、Rel.11の異なるシナリオに適応するために、キャリアDL割当て及びアップリンク許可に新たに設計された制御チャネルである。したがって、PCFICH、PHICH、およびPUCCHなど、幾つかの関連するチャネルを考慮する必要がある。 PUCCHを考慮すると、主な問題は、ePDCCH [1]から受信するDL割当てに基づいてPUCCH 1a / 1bリソースを決定する方法である。レガシーPDCCHの場合、PUCCH 1a / 1bリソースは、n^((1))_(PUCCH) = n_(CCE) + N^((1))_(PUCCH)によって決定される。ここで、nCCEは、対応するDCI割当ての送信に使用される最初のCCE(すなわち、PDCCHを構成するために使用される最低のCCEインデックス)の番号であり、N^((1))_(PUCCH) は上位レイヤによって構成されるIE PUCCH-ConfigCommonに含まれるnlPUCCH-ANのパラメータである。 (中略) 次に、ePDCCHに対応するPUCCH1a / 1bリソースは、eCCEインデックス、及び、LTEと同様に上位レイヤが構成したパラメータによって示されうる。 (中略) したがって、ePDCCHによってスケジューリングされたDL送信のためのHARQ-ACKをフィードバックするために、1つの可能な方法は、PUCCH 1a / 1bリソースを指示するためのeCCEインデックスがUEのために構成されたサーチスペース内で番号付けされることである。この場合、ePDCCHに対応するPUCCH 1a / 1bリソースを決定する上位レイヤ構成パラメータは、異なるUEに対して異なることができる。」) 以上より、引用例2には、「N^((1))_(PUCCH)」は、上位レイヤによって設定される「PUCCH-ConfigCommon」のIEに含まれることが記載されており、上位レイヤ構成パラメータが事前に基地局からUEに送信され、基地局とUE間で共有されることは明らかである。してみれば、引用例2には「上位レイヤ構成パラメータを、基地局がUEに送信する。」(以下「公知技術1」という。)ことが記載されていると認められる。第5 対比本件補正発明と引用発明を対比すると、以下のとおりとなる。 (i) 本願発明の「ACK/NACK」と引用発明の「HARQ-ACK」は表現上の差異があるにすぎない。本願発明の「拡張PUCCHリソース」、「EPDCCH」、「eCCE」と、引用発明の「PUCCH-Eリソース」、「E-PDCCH」、「E-CCE」は表現上の差違があるにすぎない。本願発明の「ACK/NACK用の拡張PUCCHリソースを、EPDCCHによって使用されるeCCEに暗黙的にリンクする」と引用発明の「HARQ-ACK用のPUCCH-EリソースをE-PDCCHを構成するE-CCEの番号から暗黙的に決定する」は、表現上の差違があるにすぎない。引用発明には明示されていないが、「基地局は、ユーザ機器にサービス」することは、当然のことである。これらより、引用発明の「通信システムの基地局において、HARQ-ACK用のPUCCHリソースを、E-PDCCHを構成するE-CCE番号から暗黙的に決定する方法であって、前記E-PDCCHは、送信のためにE-CCEを使用し」は、本願発明の「通信システムの基地局において、ACK/NACK用の拡張PUCCHリソースを、EPDCCHによって使用されるeCCEに暗黙的にリンクする方法であって、前記基地局は、ユーザ機器にサービスし、前記EPDCCHは、送信のために前記eCCEを使用し」に相当する。 (ii) 引用発明の「前記HARQ-ACK用の複数のPUCCHリソースに番号設定するステップ」は、本願発明の「a.前記ACK/NACK用の複数の前記拡張PUCCHリソースに番号設定するステップ」に相当する。引用発明の「すべての前記E-PDCCHによって使用される前記E-CCEに番号設定するステップ」は、本願発明の「b.すべての前記EPDCCHによって使用される前記eCCEに番号設定するステップ」に相当する。引用発明の「前記PUCCHリソースの番号設定と前記E-CCEの番号設定との間のリンクを決定するステップ」は、本願発明の「c.前記拡張PUCCHリソースの前記番号設定と前記eCCEの前記番号設定との間のリンクを決定するステップ」に相当する。してみれば、本願発明と引用発明とでは、以下の点で一致する。「通信システムの基地局において、ACK/NACK用の拡張PUCCHリソースを、EPDCCHによって使用されるeCCEに暗黙的にリンクする方法であって、前記基地局は、ユーザ機器にサービスし、前記EPDCCHは、送信のために前記eCCEを使用し、前記方法は、 a.前記ACK/NACK用の複数の前記拡張PUCCHリソースに番号設定するステップと、 b.すべての前記EPDCCHによって使用される前記eCCEに番号設定するステップと、 c.前記拡張PUCCHリソースの前記番号設定と前記eCCEの前記番号設定との間のリンクを決定するステップと、を含む方法。」そして、本願発明と引用発明は、以下の点で相違する。相違点1 一致点の「a.前記ACK/NACK用の複数の前記拡張PUCCHリソースに番号設定するステップ」に関し、本願発明は「前記複数の拡張PUCCHリソースの各々が、1つのユーザ機器に対応する」との発明特定事項を有するのに対し、引用発明は当該事項が明らかにされていない点。相違点2 本願発明は,更に「d.前記リンク、および前記拡張PUCCHリソースの前記番号設定に関連付けられた第1の情報を、前記ユーザ機器と共有するステップ」と「e.前記eCCEの前記番号設定に関連付けられた第2の情報を前記ユーザ機器に送信するステップ」との構成を含むのに対して、引用発明は当該構成について特定がない点。第6 判断 1 相違点1について上記「第4 1」のとおり、引用発明の「PUCCH-Eリソースの番号設定と前記E-CCEの番号設定との間のリンク」は、n^(E)_(PUCCH) = n_(E-CCE) + N^((1))_(PUCCH-E)であり、n_(E-CCE) は1つのユーザ機器に対応するから、n^(E)_(PUCCH) も1つのユーザ機器に対応することになり、結果的に複数の拡張PUCCHリソースの各々が1つのユーザ機器に対応することとなることは明らかである。したがって、相違点1には実質的な差違はない、あるいは容易になし得たことに過ぎない。 2 相違点2について HARQ-ACK用のPUCCH-EリソースをE-PDCCHを構成するE-CCEの番号から暗黙的に決定する場合、リンクおよびPUCCH-Eリソースの番号設定に関連付けられた情報を、基地局とユーザ機器とが共有している必要があることは技術常識であるから、引用発明も実質的に「d.前記リンク、および前記拡張PUCCHリソースの前記番号設定に関連付けられた第1の情報を、前記ユーザ機器と共有するステップ」に相当するステップを有していることは当然である。また、本願明細書の[0039]によれば、本願発明の「前記eCCEの前記番号設定に関連付けられた第2の情報」は、「レガシのPDCCHリソースのCCEの番号設定の後にEPDCCHリソースのeCCEが番号設定されるのか、あるいはEPDCCHリソースのeCCEが別個に番号設定されるのか」に関する情報を含むと認められる。一方、引用例1には、UEがレガシーのコントロールチャネルを検出できる場合はE-CCEはCCEの後に番号付けすることができ、そうでない場合はネットワークによってオフセット, N^((1))_(PUCCH-E)を介して開始位置を設定することができることが記載されている(上記「第4 1 (4)」参照。)。そして、公知技術1のとおり「上位レイヤ構成パラメータを、基地局がUEに送信する。」ことが公知であることに鑑みれば、後者の場合である引用発明において、E-CCEはCCEの後に番号付けしたものとしないことを示す情報をユーザ機器に送信するようこと、すなわち、「e.前記eCCEの前記番号設定に関連付けられた第2の情報を前記ユーザ機器に送信するステップ」を備えるようにすることは当業者が適宜なし得ることに過ぎない。 2 請求人の主張について請求人は、審判請求書において、以下のとおり主張する。「(3-6) しかしながら引用文献2は、上記で教示された引用文献2のeCCEと、IE PUCCH-CｏnfigCｏmmｏnに含まれ、UEに送信される引用文献2のパラメータ「n1PUCCH-AN」との間の関連について全く言及しておりません。 (3-7) 以上説明申し上げました点から明らかなように、審査官殿のご認定とは異なり、実際には引用文献2は、請求項1に係る本願発明の発明特定事項である、「前記eCCEの前記番号設定に関連付けられた第2の情報を前記ユーザ機器に送信するステップ」、に対応しうる技術事項について開示しておりません。結果として、引用文献1に記載の発明と引用文献2に記載の発明を組み合わせることが技術的に可能だったと仮定しても、その組み合わせの結果物は請求項1に記載の発明の具備する全ての発明特定事項を開示しておらず、本願発明を自明とすることはできません。従いまして、請求項1に係る本願発明は、引用文献1及び引用文献2に対して特許性を有するものと思料致します。」しかしながら、前記「第4 2」で検討したとおり、公知技術1はPUCCH 1a/1bリソースを決定する「上位レイヤ構成パラメータを、基地局がUEに送信する。」というものであり、前記公知技術1は本願発明の「d.前記リンク、および前記拡張PUCCHリソースの前記番号設定に関連付けられた第1の情報を、前記ユーザ機器と共有するステップ」を示唆するものである。また、請求人の主張とは異なり、上記のとおり、「前記eCCEの前記番号設定に関連付けられた第2の情報を前記ユーザ機器に送信するステップ」との事項は、引用発明にも示唆されているといえる。してみれば、請求人の主張は採用することができない。第7 むすび以上のとおり、本願発明は、特許法第29条第2項の規定により特許を受けることができないから、他の請求項に係る発明について検討するまでもなく、本願は拒絶すべきものである。
別掲
審理終結日	2018-10-11
結審通知日	2018-10-16
審決日	2018-10-29
出願番号	特願2015-500995(P2015-500995)
審決分類	P 1 8・ 121- Z (H04W)
最終処分	不成立
前審関与審査官	吉村真治▲郎▼、青木健
特許庁審判長	菅原道晴
特許庁審判官	岩間直純海江田章裕
発明の名称	ACK/NACK用の拡張PUCCHリソースをEPDCCHによって使用されるeCCEに暗黙的にリンクする方法
代理人	岡部讓
代理人	吉澤弘司

プライバシーポリシーセキュリティーポリシー運営会社概要サービスに関しての問い合わせ