对比文件名称：发明申请_WO2017014549A1 하향링크 제어 정보 수신 방법 및 사용자기기와, 하향링크 제어 정보 전송 방법 및 기지국
目标专利名称：用于窄带操作的上行链路和下行链路授权
模型名称：专利创造性评估模型
### 特征比对表格
| 技术特征描述以及公开性判断结果 | 对比文件原文引用 | 公开性论述 |
| **技术特征A**: 一种用于由用户设备(UE)进行无线通信的方法 <br> **判断结果**: 《直接公开》 | [7] 본 발명의 일 양상으로, 사용자기기 하향링크 제어 정보(downlink control information, DCI)를 수신함에 있어서, 상기 사용자기기의 커버리지 강화(coverage enhancement, CE) 모드를 결정; 하향링크 그랜트 DCI를 복호; 및 상기 하향링크 그랜트 DCI에 따라 물리 하향링크 공유 채널(physical downlink shared channel, PDSCH)를 수신하는 것을 포함하는, 하향링크 제어 정보 수신 방법이 제공된다. <br> 译文：根据本发明的一个方面，提供了一种用于接收用户设备下行链路控制信息(DCI)的方法，包括：确定所述用户设备的覆盖增强(CE)模式；解码下行链路授权DCI；以及根据所述下行链路授权DCI接收物理下行链路共享信道(PDSCH)。 | 对比文件[7]段明确公开了一种由用户设备(UE)执行的无线通信方法，即下行链路控制信息接收方法，该方法包括确定CE模式、解码下行链路授权DCI以及接收PDSCH。这与目标专利权利要求1中限定的“一种用于由用户设备(UE)进行无线通信的方法”在类型上相同，都是UE执行的方法。因此，技术特征A被对比文件直接公开。 |
| **技术特征B**: 针对上行链路(UL)或下行链路(DL)授权而监视系统带宽的窄带中的控制信道 <br> **判断结果**: 《直接公开》 | [159] MTC UE의 단가를 낮추기 위한 한가지 방법으로, 셀의 동작(operating) 시스템 대역폭(system bandwidth)과 무관하게, 예를 들어, 1.4 MHz의 축소된(reduced) UE 하향링크 및 상향링크 대역폭에서 MTC UE의 동작이 이루어질 수 있다. 이 때, 이러한 MTC UE가 동작하는 서브밴드(sub-band)(=narrowband)는, 도 6(a)에 도시된 것과 같이 항상 셀의 중심(예, 중심 6개 PRB들)에 위치할 수도 있고... <br> [160] 이러한 경우, MTC UE는 전 시스템 대역을 통해 전송되는 레거시 PDCCH를 제대로 수신할 수 없으며... 이를 해결하기 위한 한가지 방법으로 MTC UE를 위해 MTC가 동작하는 서브밴드 내에서 전송되는 제어 채널을 도입할 필요가 있다. 이러한 저-복잡도(low-complexity) MTC UE를 위한 하향링크 제어 채널로서, 기존의 EPDCCH를 그대로 사용될 수 있다. 또는 기존의 PDCCH/EPDCCH가 변형된 형태의 제어 채널인 MTC UE를 위한 M-PDCCH가 도입될 수도 있다. <br> 译文：[159] 为了降低MTC UE的成本，一种方法是，无论小区的操作系统带宽如何，MTC UE的操作都可以在例如1.4 MHz的缩减的UE下行链路和上行链路带宽中进行。此时，该MTC UE操作的子带（=窄带）可以如图6(a)所示始终位于小区的中心（例如，中心6个PRB）... <br> [160] 在这种情况下，MTC UE无法正确接收在整个系统带宽上传输的传统PDCCH...为了解决这个问题，需要为MTC UE引入在MTC操作的子带内传输的控制信道。作为这种低复杂度MTC UE的下行链路控制信道，可以直接使用现有的EPDCCH。或者，可以引入作为现有PDCCH/EPDCCH变体形式的、用于MTC UE的M-PDCCH。 | 对比文件[159]-[160]段明确描述了MTC UE在系统带宽内的窄带（子带，例如1.4MHz/6个PRB）中操作，并且为了解决传统宽带PDCCH接收问题，引入了在该窄带内传输的控制信道（如M-PDCCH）。UE需要监视该窄带控制信道以获取调度信息（如授权）。这与目标专利特征B“针对上行链路(UL)或下行链路(DL)授权而监视系统带宽的窄带中的控制信道”完全对应。在目标专利中，该特征用于窄带操作（如NB-IoT/eMTC）中的授权监视；在对比文件中，该特征同样用于MTC UE在窄带中接收控制信息（包含授权）。因此，技术特征B被直接公开。 |
| **技术特征C**: 接收交织的在各自的子帧中的UL授权和DL授权 <br> **判断结果**: 未公开 | 经查阅对比文件全文，未发现关于“交织的(interleaved)”UL授权和DL授权，或在一个UL授权之后接收DL授权作为下一个授权（或反之）的描述。对比文件主要涉及根据CE模式使用不同DCI格式来传输UL或DL授权，但未提及这些授权以交织的方式在连续子帧中接收。 | 目标专利说明书[0106]-[0108]及图12-14详细描述了“交织的UL和DL授权”，这是为了解决TDD模式下支持交织的UL和DL数据传输而引入的特定技术手段，即UE可以连续接收一个UL授权和一个DL授权（顺序不限）。对比文件虽然广泛讨论了MTC、窄带操作、DCI格式和HARQ过程，但从未提及或暗示这种“交织”的授权接收方式。本领域技术人员无法从对比文件中直接或通过合理推理得出“接收交织的在各自的子帧中的UL授权和DL授权”这一特定技术特征。因此，技术特征C未被公开。 |
| **技术特征D**: 以及响应于所接收的交织的在各自的子帧中的UL授权和DL授权来发送或接收信息。 <br> **判断结果**: 未公开 | 对比文件[13]段提到UE解码上行链路授权DCI并根据其传输PUSCH；[7]段提到UE解码下行链路授权DCI并根据其接收PDSCH。但这是针对单个授权（UL或DL）的响应，而非针对“交织的”授权。 | 该特征依赖于技术特征C。由于对比文件未公开“接收交织的UL和DL授权”，因此自然也未公开“响应于所接收的交织的UL和DL授权来发送或接收信息”这一后续动作。目标专利中此特征是实现交织数据传输的关键步骤。对比文件未涉及此概念。 |
| **技术特征E**: 接收所述交织的在各自的子帧中的UL授权和DL授权包括以下至少一者：在UL授权之后接收DL授权作为下一个授权，或者在DL授权之后接收UL授权作为下一个授权。 <br> **判断结果**: 未公开 | 未在对比文件中发现相关内容。 | 此特征是对“交织授权”顺序的具体限定。对比文件未公开“交织授权”本身，更未公开其具体顺序（UL后DL或DL后UL）。因此，该特征未被公开。 |
| **技术特征F**: 所述UE监视控制信道搜索空间，并且在UL授权之后并在响应于所述UL授权的在UL数据信道上所述发送信息的开始之后，接收DL授权作为下一个授权。 <br> **判断结果**: 未公开 | 未在对比文件中发现相关内容。 | 此特征描述了在UL数据传输开始后，仍在同一控制信道搜索空间中接收下一个（DL）授权的特定场景。对比文件未提及在UL数据传输期间继续监视控制信道以接收交织的DL授权。因此，该特征未被公开。 |
| **技术特征G**: 在所述UE在其中在所述UL数据信道上发送信息的子帧之后并在用于DL通信的子帧之前的子帧用作保护子帧。 <br> **判断结果**: 未公开 | 未在对比文件中发现相关内容。 | 此特征涉及为实现交织授权和数据传输而引入的保护子帧概念，用于处理UL到DL的切换。对比文件未提及在窄带操作中为接收交织授权而使用保护子帧。因此，该特征未被公开。 |
| **技术特征H**: 所述交织的在各自的子帧中的UL授权和DL授权中的每一个授权支持一个或多个混合自动重传请求(HARQ)过程。 <br> **判断结果**: 未公开 | 对比文件[313]段提到对于一般/小的CE，可以支持多个HARQ过程（例如最多8个）。但这是独立于“交织授权”概念的通用描述。 | 虽然对比文件公开了HARQ过程的支持，但该公开并未与“交织的UL和DL授权”这一特定上下文相关联。目标专利的此特征限定了交织授权中的每一个授权都支持HARQ过程。由于对比文件未公开“交织授权”，因此该限定特征也未被公开。 |
| **技术特征I**: 所述交织的在各自的子帧中的UL授权和DL授权中的每一个授权支持两个HARQ过程。 <br> **判断结果**: 未公开 | 未在对比文件中发现关于“交织授权支持两个HARQ过程”的描述。 | 此特征是对H特征的具体化（支持两个HARQ过程）。对比文件未公开交织授权，也未具体提及每个授权支持两个HARQ过程。因此，该特征未被公开。 |
| **技术特征J**: 所述UE经由能力信令指示对以下至少一者的支持：针对每个UL授权或DL授权的两个HARQ进程，或UL授权和DL授权的交织。 <br> **判断结果**: 未公开 | 未在对比文件中发现通过能力信令指示对“交织授权”支持的相关内容。 | 此特征涉及UE通过能力信令向网络报告其支持特性，特别是对交织授权或两个HARQ过程的支持。对比文件未提及此种能力信令机制。因此，该特征未被公开。 |
| **技术特征K**: 还包括：响应于所述响应于所接收的交织的在各自的子帧中的UL授权和DL授权来发送或接收信息，识别冲突，所述冲突包括以下至少一者：UL数据信道和DL数据信道之间的冲突，或UL数据信道与混合ARQ确认(HARQ-ACK)信令之间的冲突。 <br> **判断结果**: 未公开 | 未在对比文件中发现由于接收“交织授权”而导致的UL数据信道与DL数据信道冲突，或UL数据信道与HARQ-ACK冲突的描述。 | 此特征涉及交织授权可能引发的特定冲突场景及冲突识别。这是目标专利为解决交织操作引入的新问题而提出的。对比文件未涉及交织授权，因此也未提及由此产生的此类冲突。因此，该特征未被公开。 |
| **技术特征L**: 所述HARQ-ACK信令包括确认或否定确认(NACK)，并且其中，所述HARQ-ACK信令是针对所述DL数据信道的。 <br> **判断结果**: 《直接公开》 | [131] HARQ-ACK: PDCCH에 대한 응답 및/또는 PDSCH 상의 하향링크 데이터 패킷(예, 코드워드)에 대한 응답이다. PDCCH 혹은 PDSCH가 성공적으로 수신되었는지 여부를 나타낸다... HARQ-ACK 응답은 포지티브 ACK(간단히, ACK), 네거티브 ACK(이하, NACK), DTX(Discontinuous Transmission) 또는 NACK/DTX를 포함한다. <br> 译文：[131] HARQ-ACK：是对PDCCH和/或PDSCH上的下行链路数据分组（例如，码字）的响应。它指示PDCCH或PDSCH是否被成功接收...HARQ-ACK响应包括肯定确认（简称为ACK）、否定确认（以下称为NACK）、非连续传输(DTX)或NACK/DTX。 | 对比文件[131]段明确公开了HARQ-ACK信令包括ACK或NACK，并且是针对下行链路数据（PDSCH）的响应。这与目标专利特征L的定义完全一致。在目标专利中，此特征用于定义冲突处理中涉及的HARQ-ACK信令的性质；在对比文件中，该描述是HARQ机制的基础知识。因此，技术特征L被直接公开。 |
| **技术特征M**: 所述冲突包括所述UL数据信道和所述DL数据信道之间的所述冲突，所述方法还包括以下至少一个步骤：确定使用所述UL数据信道和所述DL数据信道中的一者，或对于在所述UL数据信道和所述DL数据信道之间冲突的子帧，确定使用所述UL数据信道和所述DL数据信道中的一者的所述子帧。 <br> **判断结果**: 未公开 | 未在对比文件中发现相关内容。 | 此特征涉及针对UL和DL数据信道冲突的具体解决步骤。对比文件未公开交织授权及由此产生的冲突，因此也未公开此类冲突解决步骤。 |
| **技术特征N**: 所述确定使用的步骤是至少部分地基于能量度量阈值的。 <br> **判断结果**: 未公开 | 未在对比文件中发现在冲突解决中基于“能量度量阈值”进行决策的相关内容。 | 此特征限定了冲突解决的一个具体判断依据（能量度量阈值）。对比文件未涉及此特定判断准则。 |
| **技术特征O**: 所述冲突包括所述UL数据信道与所述HARQ-ACK信令之间的冲突，所述方法还包括以下至少一个步骤：对于在所述UL数据信道和所述HARQ-ACK信令之间冲突的子帧，确定传送所述HARQ-ACK信令，或者将所述HARQ-ACK信令与所述UL数据信道复用。 <br> **判断结果**: 未公开 | 未在对比文件中发现相关内容。 | 此特征涉及另一种冲突（UL数据信道与HARQ-ACK）的解决步骤。对比文件未公开此类冲突或解决方式。 |
| **技术特征P**: 所述将所述HARQ-ACK信令与所述UL数据信道复用包括：对于在所述UL数据信道和所述HARQ-ACK信令之间冲突的子帧，用所述HARQ-ACK信令调制所述UL数据信道的解调参考信号(DMRS)。 <br> **判断结果**: 未公开 | 未在对比文件中发现用HARQ-ACK调制DMRS的相关内容。 | 此特征限定了复用的一种具体实现方式（用HARQ-ACK调制DMRS）。对比文件未涉及此特定技术手段。 |
| **技术特征Q**: 所述UE被配置用于窄带物联网(NB-IoT)。 <br> **判断结果**: 《直接公开》 | [27] 본 발명의 일 실시예에 의하면 사용자기기와 기지국이 좁은 대역(narrowband)에서 통신할 수 있다. <br> 译文：[27] 根据本发明的一个实施例，用户设备和基站可以在窄带(narrowband)中进行通信。 | 对比文件[27]段明确提到了用户设备和基站在窄带中通信。结合全文背景（MTC、IoT、窄带操作），这涵盖了窄带物联网(NB-IoT)的部署场景。目标专利中该特征限定了UE的应用场景；对比文件中同样描述了窄带通信场景。因此，技术特征Q被直接公开。 |
| **技术特征R**: 所述UE被配置用于时分双工(TDD)操作。 <br> **判断结果**: 《直接公开》 | [55] TDD 모드에서 하향링크 전송 및 상향링크 전송은 시간에 의해 구분되므로, 특정 주파수 대역에 대해 무선 프레임은 하향링크 서브프레임과 상향링크 서브프레임을 모두 포함한다. <br> 译文：[55] 在TDD模式下，下行链路传输和上行链路传输通过时间区分，因此对于特定频带，无线帧同时包含下行链路子帧和上行链路子帧。 | 对比文件[55]段明确描述了TDD操作模式的特点。这表明对比文件所描述的技术可应用于TDD模式。目标专利中该特征限定了UE的操作模式；对比文件公开了相同的操作模式。因此，技术特征R被直接公开。 |
| **技术特征S**: 所述UE被配置用于频分双工(FDD)操作。 <br> **判断结果**: 《直接公开》 | [55] 예를 들어, FDD 모드에서, 하향링크 전송 및 상향링크 전송은 주파수에 의해 구분되므로, 무선 프레임은 특정 주파수 대역에 대해 하향링크 서브프레임 또는 상향링크 서브프레임 중 하나만을 포함한다. <br> 译文：[55] 例如，在FDD模式下，下行链路传输和上行链路传输通过频率区分，因此对于特定频带，无线帧仅包含下行链路子帧或上行链路子帧中的一种。 | 对比文件[55]段明确描述了FDD操作模式的特点。这表明对比文件所描述的技术可应用于FDD模式。目标专利中该特征限定了UE的操作模式；对比文件公开了相同的操作模式。因此，技术特征S被直接公开。 |
| **技术特征T**: 所述控制信道包括窄带物理下行链路控制信道(NPDCCH)。 <br> **判断结果**: 《直接公开》 | [160] ... MTC UE를 위한 하향링크 제어 채널로서, 기존의 EPDCCH를 그대로 사용될 수 있다. 또는 기존의 PDCCH/EPDCCH가 변형된 형태의 제어 채널인 MTC UE를 위한 M-PDCCH가 도입될 수도 있다. <br> 译文：[160] ... 作为这种MTC UE的下行链路控制信道，可以直接使用现有的EPDCCH。或者，可以引入作为现有PDCCH/EPDCCH变体形式的、用于MTC UE的M-PDCCH。 | 对比文件[160]段明确提到了用于MTC UE的窄带下行链路控制信道，称为M-PDCCH。在目标专利的NB-IoT上下文中，对应的控制信道是NPDCCH。两者都是在窄带中操作、用于MTC/IoT设备的物理下行链路控制信道，概念上等同。因此，技术特征T被直接公开。 |
| **技术特征U**: 所述发送信息包括：响应于所接收的UL授权，在UL数据信道中发送信息；并且其中，所述接收信息包括响应于所述DL授权在DL数据信道中接收信息。 <br> **判断结果**: 《直接公开》 | [13] 본 발명의 각 양상에 있어서, 상기 사용자기기는 상향링크 그랜트 DCI를 복호; 및 상기 상향링크 그랜트 DCI에 따라 물리 상향링크 공유 채널(physical uplink shared channel, PUSCH)을 전송할 수 있다. <br> [7] 본 발명의 일 양상으로, 사용자기기 하향링크 제어 정보(downlink control information, DCI)를 수신함에 있어서... 하향링크 그랜트 DCI를 복호; 및 상기 하향링크 그랜트 DCI에 따라 물리 하향링크 공유 채널(physical downlink shared channel, PDSCH)를 수신하는 것을 포함하는... <br> 译文：[13] 在本发明的每个方面中，所述用户设备可以解码上行链路授权DCI；并根据所述上行链路授权DCI传输物理上行链路共享信道(PUSCH)。 <br> [7] 根据本发明的一个方面，提供了一种用于接收用户设备下行链路控制信息(DCI)的方法...包括：解码下行链路授权DCI；以及根据所述下行链路授权DCI接收物理下行链路共享信道(PDSCH)... | 对比文件[7]和[13]段分别明确描述了UE根据DL授权接收PDSCH，以及根据UL授权发送PUSCH。这与目标专利特征U“响应于UL授权发送信息”和“响应于DL授权接收信息”完全对应。在目标专利中，这是实现数据传输的基本步骤；在对比文件中，同样是实现数据传输的基本步骤。因此，技术特征U被直接公开。 |
| **技术特征V**: 所述UL数据信道包括窄带物理上行链路共享信道(NPUSCH)，并且其中，所述DL数据信道包括窄带物理下行链路共享信道(NPDSCH)。 <br> **判断结果**: 《直接公开》 | [13] ... 물리 상향링크 공유 채널(physical uplink shared channel, PUSCH)을 전송할 수 있다. <br> [7] ... 물리 하향링크 공유 채널(physical downlink shared channel, PDSCH)를 수신하는 것을 포함하는... <br> 译文：[13] ...可以传输物理上行链路共享信道(PUSCH)。 <br> [7] ...包括接收物理下行链路共享信道(PDSCH)... | 对比文件[7]和[13]段明确提到了PUSCH和PDSCH作为上行链路和下行链路数据信道。在目标专利的窄带操作（如NB-IoT）上下文中，对应的数据信道是NPUSCH和NPDSCH。两者是宽带与窄带场景下同类信道在不同标准中的具体名称，功能相同。因此，在对比文件公开了PUSCH/PDSCH的基础上，结合其窄带操作背景（特征B、Q），本领域技术人员能够直接且明确地确定在窄带中对应的数据信道即为窄带PUSCH和PDSCH（即NPUSCH和NPDSCH）。因此，技术特征V被直接公开。 |
| **技术特征W**: 所述DL数据信道包括窄带物理下行链路共享信道(NPDSCH)，所述HARQ-ACK包括混合自动重传请求(HARQ)确认或否定确认，并且所述UL数据信道包括窄带物理上行链路共享信道(NPUSCH)。 <br> **判断结果**: 《直接公开》 | [7] ... 물리 하향링크 공유 채널(physical downlink shared channel, PDSCH)를 수신하는... <br> [131] HARQ-ACK: PDCCH에 대한 응답 및/또는 PDSCH 상의 하향링크 데이터 패킷(예, 코드워드)에 대한 응답이다... HARQ-ACK 응답은 포지티브 ACK(간단히, ACK), 네거티브 ACK(이하, NACK)... <br> [13] ... 물리 상향링크 공유 채널(physical uplink shared channel, PUSCH)을 전송할 수 있다. <br> 译文：[7] ...接收物理下行链路共享信道(PDSCH)... <br> [131] HARQ-ACK：是对PDCCH和/或PDSCH上的下行链路数据分组（例如，码字）的响应...HARQ-ACK响应包括肯定确认（简称为ACK）、否定确认（以下称为NACK）... <br> [13] ...可以传输物理上行链路共享信道(PUSCH)。 | 对比文件[7]段公开了PDSCH（对应于NPDSCH），[131]段公开了HARQ-ACK包括ACK/NACK，[13]段公开了PUSCH（对应于NPUSCH）。这组合起来公开了技术特征W的全部限定内容。在目标专利中，这些是用于描述冲突的要素；在对比文件中，这些是无线通信系统中的基本要素。结合对比文件的窄带操作背景，本领域技术人员能够直接确定在窄带场景下这些要素即对应NPDSCH、HARQ-ACK和NPUSCH。因此，技术特征W被直接公开。 |
<<<A>>><<<B>>><<<Q>>><<<R>>><<<S>>><<<T>>><<<U>>><<<V>>><<<W>>>