对比文件名称：发明专利_CA2850569A1 DEVICE COMMUNICATION USING A REDUCED CHANNEL BANDWIDTH
目标专利名称：用于窄带操作的上行链路和下行链路授权
模型名称：本次调用的模型
| 技术特征描述以及公开性判断结果 | 对比文件原文引用 | 公开性论述 |
| **技术特征A：一种用于由用户设备(UE)进行无线通信的方法** <br> **判断结果：直接公开** | 第[0002]段：“Systems and/or methods may be provided for supporting reduced channel bandwidth in wireless communications between devices such as UEs (e.g. including a low LTE UE category device) and/or low cost Machine-Type Communications (MTC) devices and networks that may support a full bandwidth (e.g. a full bandwidth network).” <br> 第[0153]段：“For example, in one embodiment, a low-complexity device such as a UE or MTC device may receive an inband DL assignment...” <br> 第[0154]段：“In a further embodiment, a device (e.g. a low-cost device that may support a reduced bandwidth) such as a UE or MTC device may receive an inband UL grant...” | 对比文件通篇描述了一种由用户设备（UE）或低成本MTC设备执行的、在减少的信道带宽下进行无线通信的方法，例如接收带内下行链路分配和上行链路授权。这直接公开了目标专利权利要求中“一种用于由用户设备(UE)进行无线通信的方法”这一主题。 |
| **技术特征B：针对上行链路(UL)或下行链路(DL)授权而监视系统带宽的窄带中的控制信道** <br> **判断结果：直接公开** | 第[0002]段：“...a device may receive inband assignments such as downlink assignments and/or uplink grants. Based on such inband assignments, the device may monitor and/or decide one or more transmissions that may be provided by the network (e.g. in the narrow or reduced channel bandwidth).” <br> 第[0003]段：“Additionally, in an example embodiment, a device may receive information (e.g. a definition or configuration) associated with an ePDCCH that may be used by the device. The device may then monitor and/or decode ePDCCH resources based on such information (e.g. in the narrow or reduced channel bandwidth).” <br> 第[0159]段：“Additionally, embodiments may enable a device such as UE or MTC devices to not use a legacy LTE PDCCH signal sent over the entire system bandwidth. For example, DL assignments and/or UL grants may be monitored and carried inband on a DL channel in the Data Region of a subframe such as a LTE subframe (e.g. the PDSCH) or the time and/or frequency region corresponding to DL data transmissions.” | 对比文件多次明确描述了设备（UE或MTC设备）在窄带或减少的信道带宽内监视控制信道（如ePDCCH）或带内信令，以获取下行分配（DL授权）和上行授权（UL授权）。这与目标专利特征B中“针对上行链路(UL)或下行链路(DL)授权而监视系统带宽的窄带中的控制信道”的描述完全一致，其作用都是为了获取资源调度授权。 |
| **技术特征C：接收交织的在各自的子帧中的UL授权和DL授权** <br> **判断结果：未公开** | 对比文件未提供相关内容。 | 对比文件虽然描述了设备可以接收DL分配和UL授权（参见特征B的引用），但从未提及这些授权是“交织的”（interleaved），也未描述UL授权和DL授权在“各自的子帧中”以交织的方式被接收。目标专利说明书中（例如第[0126]段）强调交织授权对于支持TDD模式或提高FDD效率的重要性，而对比文件完全没有涉及这一特定概念。因此，该特征既未被直接公开，也无法从对比文件内容中合理推断出来。 |
| **技术特征D：以及响应于所接收的交织的在各自的子帧中的UL授权和DL授权来发送或接收信息。** <br> **判断结果：未公开** | 对比文件未提供相关内容。 | 由于对比文件未公开“接收交织的在各自的子帧中的UL授权和DL授权”（技术特征C），因此基于此交织授权而进行的“发送或接收信息”这一后续动作也自然未被公开。对比文件中描述的发送或接收信息是基于单独的DL授权或UL授权，而非基于交织的授权。 |
| **技术特征E：根据权利要求1所述的方法，其中，接收所述交织的在各自的子帧中的UL授权和DL授权包括以下至少一者：在UL授权之后接收DL授权作为下一个授权，或者在DL授权之后接收UL授权作为下一个授权。** <br> **判断结果：未公开** | 对比文件未提供相关内容。 | 该特征是对“交织授权”接收顺序的具体化。如上所述，对比文件未公开“交织授权”的概念，因此更不可能公开其具体的接收顺序（UL后DL或DL后UL）。 |
| **技术特征F：根据权利要求1所述的方法，其中，所述UE监视控制信道搜索空间，并且在UL授权之后并在响应于所述UL授权的在UL数据信道上所述发送信息的开始之后，接收DL授权作为下一个授权。** <br> **判断结果：未公开** | 对比文件未提供相关内容。 | 该特征描述了一种非常具体的交织授权接收时序场景：UE在已经开始基于第一个UL授权进行上行传输后，才接收下一个DL授权。对比文件完全没有描述这种在数据信道传输开始后接收另一种类型授权的特定交织行为。 |
| **技术特征G：根据权利要求4所述的方法，其中，在所述UE在其中在所述UL数据信道上发送信息的子帧之后并在用于DL通信的子帧之前的子帧用作保护子帧。** <br> **判断结果：未公开** | 对比文件未提供相关内容。 | 该特征涉及为支持交织UL/DL数据传输而引入的“保护子帧”概念。对比文件全文未提及“保护子帧”（guard subframe）或其类似概念。 |
| **技术特征H：根据权利要求1所述的方法，其中，所述交织的在各自的子帧中的UL授权和DL授权中的每一个授权支持一个或多个混合自动重传请求(HARQ)过程。** <br> **判断结果：未公开** | 对比文件未提供相关内容。 | 该特征限定了交织授权中的每一个授权支持一个或多个HARQ过程。对比文件虽然提到了HARQ（例如第[0114]段提及PHICH用于传输ACK/NACK），但并未将HARQ过程的支持与“交织授权”这一未被公开的概念相关联，也未讨论每个授权支持一个或多个HARQ过程。 |
| **技术特征I：根据权利要求8所述的方法，其中，所述交织的在各自的子帧中的UL授权和DL授权中的每一个授权支持两个HARQ过程。** <br> **判断结果：未公开** | 对比文件未提供相关内容。 | 该特征进一步限定每个交织授权支持两个HARQ过程。对比文件未公开“交织授权”，也未讨论授权支持具体数量的HARQ过程（如两个）。 |
| **技术特征J：根据权利要求8所述的方法，其中，所述UE经由能力信令指示对以下至少一者的支持：针对每个UL授权或DL授权的两个HARQ进程，或UL授权和DL授权的交织。** <br> **判断结果：未公开** | 对比文件未提供相关内容。 | 该特征涉及UE通过能力信令指示对特定功能（两个HARQ进程或交织授权）的支持。对比文件提到了设备能力信令（例如第[0327]段提及设备在网络注册时提供能力信息），但并未涉及指示对“两个HARQ进程”或“UL授权和DL授权的交织”的支持。 |
| **技术特征K：根据权利要求1所述的方法，还包括：响应于所述响应于所接收的交织的在各自的子帧中的UL授权和DL授权来发送或接收信息，识别冲突，所述冲突包括以下至少一者：UL数据信道和DL数据信道之间的冲突，或 UL数据信道与混合ARQ确认(HARQ-ACK)信令之间的冲突。** <br> **判断结果：未公开** | 对比文件未提供相关内容。 | 该特征涉及在基于交织授权进行发送/接收时识别特定类型的冲突。对比文件未公开“交织授权”，因此也未描述因交织授权可能引发的冲突场景，如UL数据信道与DL数据信道冲突，或UL数据信道与HARQ-ACK冲突。 |
| **技术特征L：根据权利要求11所述的方法，其中，所述HARQ-ACK信令包括确认或否定确认(NACK)，并且其中，所述HARQ-ACK信令是针对所述DL数据信道的。** <br> **判断结果：未公开** | 对比文件未提供相关内容。 | 该特征是对技术特征K中HARQ-ACK信令的进一步说明。由于技术特征K未被公开，此从属特征自然也未被公开。对比文件单独提及ACK/NACK（如PHICH），但未在交织授权引发的冲突上下文中进行描述。 |
| **技术特征M：根据权利要求11所述的方法，其中，所述冲突包括所述UL数据信道和所述DL数据信道之间的所述冲突，所述方法还包括以下至少一个步骤：确定使用所述UL数据信道和所述DL数据信道中的一者，或对于在所述UL数据信道和所述DL数据信道之间冲突的子帧，确定使用所述UL数据信道和所述DL数据信道中的一者的所述子帧。** <br> **判断结果：未公开** | 对比文件未提供相关内容。 | 该特征提供了在UL数据信道和DL数据信道冲突时的具体处理步骤。对比文件未公开此类冲突场景，因此也未给出相应的冲突解决步骤。 |
| **技术特征N：根据权利要求13所述的方法，其中，所述确定使用的步骤是至少部分地基于能量度量阈值的。** <br> **判断结果：未公开** | 对比文件未提供相关内容。 | 该特征限定了冲突解决决策基于能量度量阈值。对比文件未公开冲突解决，因此也未提及基于能量度量阈值进行决策。 |
| **技术特征O：根据权利要求12所述的方法，其中，所述冲突包括所述UL数据信道与所述HARQ-ACK信令之间的冲突，所述方法还包括以下至少一个步骤：对于在所述UL数据信道和所述HARQ-ACK信令之间冲突的子帧，确定传送所述HARQ-ACK信令，或者将所述HARQ-ACK信令与所述UL数据信道复用。** <br> **判断结果：未公开** | 对比文件未提供相关内容。 | 该特征提供了在UL数据信道与HARQ-ACK冲突时的具体处理步骤。对比文件未公开此类冲突场景，因此也未给出相应的冲突解决步骤。 |
| **技术特征P：根据权利要求15所述的方法，其中，所述将所述HARQ-ACK信令与所述UL数据信道复用包括：对于在所述UL数据信道和所述HARQ-ACK信令之间冲突的子帧，用所述HARQ-ACK信令调制所述UL数据信道的解调参考信号(DMRS)。** <br> **判断结果：未公开** | 对比文件未提供相关内容。 | 该特征具体描述了如何将HARQ-ACK信令与UL数据信道复用，即调制DMRS。这是非常具体的实现细节，对比文件完全没有涉及。 |
| **技术特征Q：根据权利要求1所述的方法，其中，所述UE被配置用于窄带物联网(NB-IoT)。** <br> **判断结果：隐含公开** | 第[0001]段：“...reduce the channel bandwidth and data rate used to communicate with devices on the network.” <br> 第[0101]段：“For example, an example for the application of wireless communications technology may include Machine-Type Communications (MTC)...IoT UE includes...NB-IoT UE...” <br> 第[0102]段：“As described herein, a low cost device such as a UE or MTC device may generally include...reducing the maximum applicable transmission power in the uplink (UL) for such a device, the maximum supported receive (Rx) or transmit (Tx) channel bandwidth may be reduced and/or a half-duplex FDD mode may be supported.” <br> 第[0133]段：“...a device such an MTC device may read a portion of the system bandwidth...low-complexity MTC device or UE may support 5 MHz or smaller bandwidth...” | 对比文件明确将MTC设备、低成本UE与使用减少的信道带宽操作相关联，并多次提及窄带操作。第[0101]段更是明确将NB-IoT UE列为IoT UE的一种。虽然对比文件没有明确声明“UE被配置用于NB-IoT”，但其描述的低成本、窄带、半双工操作的MTC/UE设备，与本领域技术人员所理解的NB-IoT设备的典型特征高度重合。结合对比文件整体教导的设备在窄带中操作，本领域技术人员能够合理推断出，该方法可应用于被配置用于NB-IoT的UE。因此，该技术特征被隐含公开。 |
| **技术特征R：根据权利要求1所述的方法，其中，所述UE被配置用于时分双工(TDD)操作。** <br> **判断结果：隐含公开** | 第[0058]段：“The communications system 100 may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA)...” <br> 第[0063]段：“...UTRA, E-UTRA, UMTS, LTE, LTE-A...” (LTE支持TDD) <br> 第[0128]段：“...operating parameters such as the TDD UL/DL configuration (e.g. for TDD only)...” <br> 第[0143]段：“...frame structure 2 (TDD)...” | 对比文件描述的通信系统支持包括TDMA、LTE在内的多种多址技术和无线标准，其中LTE明确支持TDD操作。对比文件在描述系统信息（SIB1）和PRACH资源配置时也明确提到了TDD。虽然未明确声明执行该方法的UE“被配置用于TDD操作”，但鉴于对比文件描述的方法适用于所提及的无线通信系统（包括支持TDD的系统），本领域技术人员可以合理推断该方法也可在TDD模式下操作。因此，该技术特征被隐含公开。 |
| **技术特征S：根据权利要求1所述的方法，其中，所述UE被配置用于频分双工(FDD)操作。** <br> **判断结果：隐含公开** | 第[0058]段：“The communications system 100 may employ one or more channel access methods, such as...frequency division multiple access (FDMA)...” <br> 第[0063]段：“...UTRA, E-UTRA, UMTS, LTE, LTE-A...” (LTE支持FDD) <br> 第[0102]段：“...a half-duplex FDD mode may be supported.” <br> 第[0143]段：“...frame structure 1 (FDD)...” | 对比文件明确支持FDMA，并多次提到FDD和半双工FDD模式。虽然未明确声明执行该方法的UE“被配置用于FDD操作”，但鉴于对比文件描述的方法适用于所提及的无线通信系统（包括支持FDD的系统），本领域技术人员可以合理推断该方法也可在FDD模式下操作。因此，该技术特征被隐含公开。 |
| **技术特征T：根据权利要求1所述的方法，其中，所述控制信道包括窄带物理下行链路控制信道(NPDCCH)。** <br> **判断结果：未公开** | 第[0003]段：“...a device may receive information (e.g. a definition or configuration) associated with an ePDCCH that may be used by the device. The device may then monitor and/or decode ePDCCH resources...” <br> 第[0199]段：“An MTC device may receive the PDCCH in the PDSCH region...M-PDCCH...” | 对比文件提到了设备监视的窄带控制信道包括ePDCCH和M-PDCCH（MTC PDCCH）。NPDCCH是NB-IoT标准中特定的窄带控制信道名称。虽然ePDCCH或M-PDCCH在概念上也是在窄带中操作的控制信道，但“NPDCCH”作为一个具有特定帧结构、时序等规范定义的术语，并未在对比文件中出现。本领域技术人员不能从对比文件提及的ePDCCH或M-PDCCH直接且明确地确定目标专利中的“NPDCCH”。因此，该特征未被公开。 |
| **技术特征U：根据权利要求1所述的方法，其中，所述发送信息包括：响应于所接收的UL授权，在UL数据信道中发送信息；并且其中，所述接收信息包括响应于所述DL授权在DL数据信道中接收信息。** <br> **判断结果：直接公开** | 第[0153]段：“...a low-complexity device such as a UE or MTC device may receive an inband DL assignment that may identify an intended receiver of a PDSCH transmission...” (接收DL授权并接收PDSCH信息) <br> 第[0154]段：“...a device...such as a UE or MTC device may receive an inband UL grant for an upcoming PUSCH transmission...” (接收UL授权并发送PUSCH信息) <br> 第[0171]段：“When the device such as a UE or MTC device may decode its assigned UL identifier as part of the DL signal transmission, it may proceed to prepare for UL transmission of a data unit or units in the associated UL transmission resources...” | 对比文件明确描述了设备在接收到DL分配（授权）后，在PDSCH（DL数据信道）上接收信息（数据）；以及在接收到UL授权后，准备并在PUSCH（UL数据信道）上发送信息。这与技术特征U的描述完全对应。 |
| **技术特征V：根据权利要求21所述的方法，其中，所述UL数据信道包括窄带物理上行链路共享信道(NPUSCH)，并且其中，所述DL数据信道包括窄带物理下行链路共享信道(NPDSCH)。** <br> **判断结果：未公开** | 第[0153]段：“...PDSCH transmission...” <br> 第[0154]段：“...PUSCH transmission...” <br> 第[0246]段：“The M-PDSCH in the embodiments described herein may also be replaced by PDSCH...” | 对比文件中提到的数据信道是通用的PDSCH和PUSCH，或者针对MTC的M-PDSCH。NPUSCH和NPDSCH是NB-IoT标准中特定的窄带共享信道名称。虽然PUSCH/PDSCH与NPUSCH/NPDSCH在功能上相似，但作为特定术语，NPUSCH和NPDSCH并未在对比文件中出现。本领域技术人员不能从对比文件提及的PUSCH/PDSCH直接且明确地确定目标专利中的“NPUSCH”和“NPDSCH”。因此，该特征未被公开。 |
| **技术特征W：根据权利要求11所述的方法，其中，所述DL数据信道包括窄带物理下行链路共享信道(NPDSCH)，所述HARQ-ACK包括混合自动重传请求(HARQ)确认或否定确认，并且所述UL数据信道包括窄带物理上行链路共享信道(NPUSCH)。** <br> **判断结果：未公开** | 第[0114]段：“For example, the PHICH may be used to transmit ACK or NACK corresponding to the PUSCH...” (提及HARQ-ACK) <br> 第[0153]段：“...PDSCH...” <br> 第[0154]段：“...PUSCH...” | 该特征是对技术特征K中冲突涉及的信道和信令的进一步限定。由于技术特征K（冲突识别）未被公开，此从属特征自然也未被公开。此外，对比文件使用的是通用的PDSCH、PUSCH和PHICH（用于ACK/NACK），而非目标专利中特定的NPDSCH和NPUSCH。 |
<<<A>>><<<B>>><<<U>>>
<<<q>>><<<r>>><<<s>>>