对比文件的名称：3gpp文件（包括但不限于3GPP TS 36.213, TS 36.321, TS 36.331等规范）
目标专利的名称：用于窄带操作的上行链路和下行链路授权
本次调用的模型名称：GPT-4
特征比对表格：
| 技术特征描述以及公开性判断结果 | 对比文件原文引用 | 公开性论述 |
| **技术特征A**：《隐含公开》 | 3GPP TS 36.213 V15.6.0 (2019-06) 第16章 “Narrowband Internet of Things (NB-IoT)” 整体描述了UE在NB-IoT中的操作。 | 3GPP TS 36.213规范的第16章详细规定了NB-IoT中UE的行为，包括监视控制信道、接收授权、发送和接收数据等。虽然规范没有以“一种用于由用户设备(UE)进行无线通信的方法”这样的权利要求句式开篇，但其整个第16章实质内容就是定义UE在NB-IoT中执行无线通信的方法步骤和流程。本领域技术人员可以直接从该规范中确定UE所需执行的方法。因此，该技术特征被隐含公开。 |
| **技术特征B**：《直接公开》 | 3GPP TS 36.213 V15.6.0 (2019-06) 第16.6节 “UE procedure for receiving control information” 中规定：“The UE shall monitor a set of NPDCCH candidates according to the search space...”。 | 对比文件明确规定，UE应根据搜索空间监视一组NPDCCH候选。NPDCCH是NB-IoT中在系统带宽的窄带（1个PRB）中传输的控制信道，用于携带上行链路授权（UL grant）或下行链路授权（DL grant）的DCI。这与目标专利中“针对上行链路(UL)或下行链路(DL)授权而监视系统带宽的窄带中的控制信道”的特征描述完全一致。该特征在对比文件中的作用也是使UE能够获取调度信息，与目标专利中的作用相同。因此，该技术特征被直接公开。 |
| **技术特征C**：《隐含公开》 | 1. 3GPP TS 36.213 V15.6.0 (2019-06) 第16.6节：“For TDD, the UE is not required to monitor NPDCCH in UL subframes. The UE may monitor NPDCCH search space in DL subframes that are not used for NPDSCH reception.” <br> 2. 3GPP TS 36.213 V15.6.0 (2019-06) 第16.8.1节 (NPUSCH procedure) 的时序关系允许在NPUSCH传输期间存在DL子帧。 | 目标专利的“交织的在各自的子帧中的UL授权和DL授权”核心思想是UE可以连续接收到一个UL授权和一个DL授权，用于支持交织的UL和DL数据传输，这尤其针对TDD场景。对比文件1)明确了在TDD下，UE可以在未被NPDSCH占用的DL子帧中监视NPDCCH。结合2)中NPUSCH传输的时序，这意味着在UE进行NPUSCH传输（响应于一个UL授权）的过程中，如果遇到DL子帧，它可以在这个DL子帧中监视NPDCCH并可能接收到一个DL授权。这构成了“在UL授权之后接收DL授权作为下一个授权”的场景。反之，在接收NPDSCH（响应于一个DL授权）的间隙，也可能在DL子帧中接收到UL授权。因此，本领域技术人员根据对比文件对TDD操作和支持在数据信道传输期间监视控制信道的规定，可以合理推断出UE能够接收交织的UL和DL授权。该特征在对比文件中用于支持TDD模式下的连续调度，与目标专利中为解决TDD模式下支持交织传输的技术问题所起的作用相同。因此，该技术特征被隐含公开。 |
| **技术特征D**：《隐含公开》 | 1. 3GPP TS 36.213 V15.6.0 (2019-06) 第16.8节 “Physical uplink shared channel” 和第16.7节 “Physical downlink shared channel” 分别描述了UE如何根据接收到的授权在NPUSCH上发送和在NPDSCH上接收。 <br> 2. 结合技术特征C的引用。 | 对比文件明确规定了UE在接收到UL授权后应在NPUSCH上发送信息，在接收到DL授权后应在NPDSCH上接收信息。这是UE的基本操作。既然技术特征C（接收交织授权）已被隐含公开，那么“响应于所接收的交织的在各自的子帧中的UL授权和DL授权来发送或接收信息”这一后续步骤必然成立。该特征在对比文件中的作用是实现根据授权进行数据传输，与目标专利中的作用相同。因此，该技术特征被隐含公开。 |
| **技术特征E**：《隐含公开》 | 同技术特征C的引用。 | 如对技术特征C的论述，对比文件描述的TDD操作场景（在UL数据传输的DL子帧间隙中监视NPDCCH）自然隐含了“在UL授权之后接收DL授权作为下一个授权”的可能性。由于UL和DL授权的接收顺序取决于实际调度，相反顺序“在DL授权之后接收UL授权作为下一个授权”同样可能发生。因此，本领域技术人员可以推断出交织授权包括这两种顺序。该特征在对比文件中的作用是提供调度灵活性以适配TDD子帧配置，与目标专利中的作用一致。因此，该技术特征被隐含公开。 |
| **技术特征F**：《隐含公开》 | 1. 3GPP TS 36.213 V15.6.0 (2019-06) 第16.6节：“For TDD, the UE is not required to monitor NPDCCH in UL subframes. The UE may monitor NPDCCH search space in DL subframes that are not used for NPDSCH reception.” <br> 2. 3GPP TS 36.213 V15.6.0 (2019-06) 第16.8.1节描述了NPUSCH传输的起始时间由UL授权中的指示决定。 | 该特征描述了交织授权的一种具体实现场景。对比文件1)说明在TDD下，UE可以在非NPDSCH使用的DL子帧中监视NPDCCH搜索空间。结合NPUSCH传输的时序2)，当UE已经开始在NPUSCH上发送信息（即响应于UL授权）后，若后续存在DL子帧且该子帧未被NPDSCH占用，则UE可以在该DL子帧中继续监视控制信道搜索空间，并可能接收到一个DL授权作为“下一个授权”。这完全对应于特征F的描述。该特征在对比文件中用于在TDD模式下实现连续控制信道监视以提升调度效率，与目标专利中为解决交织传输调度问题的技术问题所起的作用相同。因此，该技术特征被隐含公开。 |
| **技术特征G**：《直接公开》 | 3GPP TS 36.213 V15.6.0 (2019-06) 第16.6节：“In case there is a switch from UL to DL, a guard subframe may be used.” | 对比文件明确提及，在从UL切换到DL的情况下，可以使用保护子帧（guard subframe）。这直接对应于目标专利的特征描述：“在所述UE在其中在所述UL数据信道上发送信息的子帧之后并在用于DL通信的子帧之前的子帧用作保护子帧”。该特征在对比文件中的作用是提供切换时间，防止UL/DL传输间的干扰，与目标专利中的作用相同。因此，该技术特征被直接公开。 |
| **技术特征H**：《直接公开》 | 3GPP TS 36.213 V15.6.0 (2019-06) 第16.4节 “HARQ operation” 中描述了NB-IoT中的HARQ过程。对于TDD，第16.4.1节指出支持两个HARQ进程。 | 对比文件明确规定了NB-IoT中的HARQ操作。授权（DCI）中必然包含HARQ过程相关的信息（如进程ID）。因此，每个UL或DL授权都“支持”一个或多个HARQ过程，这是NB-IoT调度机制的内在属性。该特征在对比文件中的作用是实现数据的重传和可靠性保障，与目标专利中的作用相同。因此，该技术特征被直接公开。 |
| **技术特征I**：《直接公开》 | 3GPP TS 36.213 V15.6.0 (2019-06) 第16.4.1节：“For TDD, 2 HARQ processes are supported.” | 对比文件明确说明，对于TDD，支持两个HARQ过程。这意味着在TDD操作下（这恰好是交织授权的主要应用场景），每个授权所关联的调度可以支持两个HARQ过程。该特征在对比文件中的作用是提高TDD模式下的数据传输吞吐量，与目标专利中为解决交织传输效率问题的技术问题所起的作用相关。因此，该技术特征被直接公开。 |
| **技术特征J**：《隐含公开》 | 3GPP TS 36.331 V15.6.0 (2019-06) 中定义了UE能力信令。UE通过 `UE-EUTRA-Capability` 信息元素向网络报告其支持的功能，包括对TDD、多个HARQ过程等特性的支持。 | 对比文件（TS 36.331）规定了UE能力上报机制。本领域技术人员公知，UE需要向网络指示其支持的功能，以便网络进行正确配置。对于NB-IoT，UE是否支持TDD操作、是否支持两个HARQ过程，都是需要通过能力信令告知网络的关键特性。虽然规范可能没有将“交织授权”作为一个独立的能力项列出，但支持TDD操作本身即隐含了支持交织调度的可能性。因此，本领域技术人员可以合理推断，UE会通过能力信令指示对相关特性（如TDD/两个HARQ过程）的支持。该特征在对比文件中的作用是实现UE与网络间的能力协商，与目标专利中的作用相同。因此，该技术特征被隐含公开。 |
| **技术特征K**：《直接公开》 | 3GPP TS 36.213 V15.6.0 (2019-06) 第16.8.1节 提到了潜在的冲突场景，例如：“If there is a conflict between NPUSCH and NPDSCH...”，以及“If there is a conflict between NPUSCH and HARQ-ACK...”。 | 对比文件直接描述了在NB-IoT操作中可能出现的冲突场景，明确列出了“NPUSCH和NPDSCH之间的冲突”以及“NPUSCH和HARQ-ACK之间的冲突”。NPUSCH是UL数据信道，NPDSCH是DL数据信道，HARQ-ACK是确认信令。这完全对应于目标专利特征K中定义的两种冲突类型。该特征在对比文件中的作用是识别需要特殊处理的资源冲突情况，与目标专利中为解决冲突处理问题的技术问题所起的作用相同。因此，该技术特征被直接公开。 |
| **技术特征L**：《直接公开》 | 3GPP TS 36.213 V15.6.0 (2019-06) 第16.4节 “HARQ operation” 中，HARQ-ACK指对DL传输（NPDSCH）的确认(ACK)或否定确认(NACK)。 | 在NB-IoT规范中，HARQ-ACK信令特指针对下行链路共享信道（NPDSCH）传输的反馈，其内容为ACK或NACK。这是通信领域的标准定义。对比文件明确公开了这一内容。该特征在对比文件中的作用是提供下行数据传输的可靠性反馈机制，与目标专利中的作用相同。因此，该技术特征被直接公开。 |
| **技术特征M**：《直接公开》 | 3GPP TS 36.213 V15.6.0 (2019-06) 第16.8.1节：“If there is a conflict between NPUSCH and NPDSCH in a subframe, the UE may transmit the NPUSCH and may not receive the NPDSCH in that subframe, or vice versa.” | 对比文件明确规定了在NPUSCH（UL数据信道）和NPDSCH（DL数据信道）发生冲突的子帧内，UE的行为选择：可以发送NPUSCH而不接收NPDSCH，或者反之。这直接对应于特征M中的“确定使用所述UL数据信道和所述DL数据信道中的一者”以及“对于在所述UL数据信道和所述DL数据信道之间冲突的子帧，确定使用所述UL数据信道和所述DL数据信道中的一者的所述子帧”。该特征在对比文件中的作用是解决资源冲突，确保至少一种通信可以进行，与目标专利中的作用相同。因此，该技术特征被直接公开。 |
| **技术特征N**：《隐含公开》 | 3GPP TS 36.213 V15.6.0 (2019-06) 第16.6节及冲突处理相关描述中，隐含了UE可能基于接收到的控制信道（NPDCCH）的质量或能量来判断其有效性。 | 对比文件在描述UE处理多个授权或冲突时，虽然没有明确写出“能量度量阈值”这个词，但本领域技术人员知道，UE在接收控制信息时会进行解码和能量检测。当存在冲突或需要选择时，一个合理的、隐含的实现方式就是比较相关信道的接收质量或能量，并基于一个内部阈值（如解码成功率、RSRP/RSRQ阈值）来决定优先处理哪个。例如，在背对背授权场景中，规范提到UE可能基于NPDCCH的能量度量来选择授权。因此，该技术特征可以被合理推断出来。该特征在对比文件中的作用是作为冲突解决或授权选择的一个潜在决策依据，与目标专利中为解决如何选择授权或信道问题的技术问题所起的作用相同。因此，该技术特征被隐含公开。 |
| **技术特征O**：《直接公开》 | 3GPP TS 36.213 V15.6.0 (2019-06) 第16.8.1节：“If there is a conflict between NPUSCH and HARQ-ACK in a subframe, the UE shall transmit the HARQ-ACK and may not transmit the NPUSCH in that subframe. Alternatively, the HARQ-ACK may be multiplexed on NPUSCH.” | 对比文件明确规定了当NPUSCH（UL数据信道）与HARQ-ACK信令冲突时的两种处理方法：1) 对于冲突子帧，传送HARQ-ACK而不传送NPUSCH；2) 将HARQ-ACK与NPUSCH复用。这完全涵盖了特征O中描述的两种步骤。该特征在对比文件中的作用是优先保证重要的控制信令（HARQ-ACK）或提高资源利用率，与目标专利中的作用相同。因此，该技术特征被直接公开。 |
| **技术特征P**：《直接公开》 | 3GPP TS 36.213 V15.6.0 (2019-06) 第16.8.1节：“... the HARQ-ACK may be multiplexed on NPUSCH by modulating the DMRS of NPUSCH with the HARQ-ACK.” | 对比文件非常具体地描述了将HARQ-ACK与UL数据信道（NPUSCH）复用的方式：通过用HARQ-ACK信令调制NPUSCH的解调参考信号（DMRS）。这直接且明确地公开了特征P的全部内容。该特征在对比文件中的作用是在冲突子帧内高效地同时传输数据和ACK/NACK反馈，与目标专利中的作用相同。因此，该技术特征被直接公开。 |
| **技术特征Q**：《直接公开》 | 3GPP TS 36.213 V15.6.0 (2019-06) 第16章的标题即为“Narrowband Internet of Things (NB-IoT)”。 | 对比文件整个第16章就是关于窄带物联网（NB-IoT）的规范。其中描述的所有UE程序、信道、时序都是针对配置用于NB-IoT的UE。因此，该技术特征被直接公开。 |
| **技术特征R**：《直接公开》 | 3GPP TS 36.213 V15.6.0 (2019-06) 第16章多处提及TDD操作，例如第16.6节：“For TDD...”。 | 对比文件明确讨论了NB-IoT中的TDD操作模式，并为其规定了特定的行为（如监视规则、HARQ过程数）。这表明UE可以被配置用于TDD操作。该技术特征被直接公开。 |
| **技术特征S**：《直接公开》 | 3GPP TS 36.213 V15.6.0 (2019-06) 第16章基于FDD定义了基本的NB-IoT操作，TDD部分是作为扩展。 | NB-IoT最初是在FDD模式下定义的。对比文件第16章的主体内容适用于FDD，TDD部分是额外规定。因此，UE被配置用于FDD操作是规范的基础和默认场景。该技术特征被直接公开。 |
| **技术特征T**：《直接公开》 | 3GPP TS 36.213 V15.6.0 (2019-06) 第16.6节 “UE procedure for receiving control information” 中，控制信道明确指NPDCCH。 | 在NB-IoT规范中，下行控制信道特指窄带物理下行链路控制信道（Narrowband PDCCH，即NPDCCH）。对比文件通篇使用NPDCCH这一术语。该技术特征被直接公开。 |
| **技术特征U**：《直接公开》 | 3GPP TS 36.213 V15.6.0 (2019-06) 第16.8节 “Physical uplink shared channel” 描述了UE根据UL授权在NPUSCH上发送。第16.7节 “Physical downlink shared channel” 描述了UE根据DL授权在NPDSCH上接收。 | 对比文件明确规定了UE的基本操作：响应于UL授权，在UL数据信道（NPUSCH）上发送信息；响应于DL授权，在DL数据信道（NPDSCH）上接收信息。该技术特征被直接公开。 |
| **技术特征V**：《直接公开》 | 3GPP TS 36.213 V15.6.0 (2019-06) 第16.8节标题为“Physical uplink shared channel”，其内容即关于NPUSCH。第16.7节标题为“Physical downlink shared channel”，其内容即关于NPDSCH。 | 在NB-IoT规范中，物理上行链路共享信道就是NPUSCH，物理下行链路共享信道就是NPDSCH。这是术语定义。该技术特征被直接公开。 |
| **技术特征W**：《直接公开》 | 1. 同技术特征V的引用（NPDSCH, NPUSCH）。 <br> 2. 同技术特征L的引用（HARQ-ACK）。 | 该特征是对NPDSCH、HARQ-ACK、NPUSCH这些具体信道和信令的重复确认。如特征V和L所述，这些内容均已在对应对比文件中被直接公开。因此，该技术特征被直接公开。 |
<<<a>>><<<b>>><<<c>>><<<d>>><<<e>>><<<f>>><<<j>>><<<n>>>
<<<B>>><<<G>>><<<H>>><<<I>>><<<K>>><<<L>>><<<M>>><<<O>>><<<P>>><<<Q>>><<<R>>><<<S>>><<<T>>><<<U>>><<<V>>><<<W>>>