**对比文件名称**：发明专利_TW201330558A 使用減少頻道頻寬裝置通訊
**目标专利名称**：用于窄带操作的上行链路和下行链路授权
**本次调用模型名称**：OpenAI GPT-4
根据目标专利权利要求的技术特征划分，结合对比文件公开内容，特征比对表格如下：
| 技术特征描述及公开性判断结果 | 对比文件原文引用 | 公开性论述 |
| **A：一种用于由用户设备(UE)进行无线通信的方法**<br>**判断结果：隐含公开** | 说明书：“设备可以接收带内指派（assignment），例如下行链路指派和/或上行链路授权。根据这种带内指派，设备可以监视和/或决定可以由网路提供的一个或多个传输（例如，在窄或者减少的通道频宽中）。” | 对比文件通篇描述了一种由设备（例如UE或低成本MTC设备）执行的无线通信方法，用于在系统带宽的窄带中操作。虽然未明确使用“由用户设备(UE)进行无线通信的方法”这一概括性表述，但本领域技术人员基于对比文件整体内容（例如设备执行监视、接收指派、发送/接收信息等操作）可以合理推断出其描述的正是一种由UE执行的方法。因此，该技术特征被对比文件隐含公开。 |
| **B：针对上行链路(UL)或下行链路(DL)授权而监视系统带宽的窄带中的控制信道**<br>**判断结果：直接公开** | 说明书：“设备可以接收带内指派（assignment），例如下行链路指派和/或上行链路授权。根据这种带内指派，设备可以监视和/或决定可以由网路提供的一个或多个传输（例如，在窄或者减少的通道频宽中）。” | 对比文件明确公开了设备（UE）接收下行链路指派和上行链路授权（即DL或UL授权），并且这些指派/授权是针对窄带或减少的通道频宽（即系统带宽的窄带）的。接收这些指派/授权的前提是设备需要监视相应的控制信道或信令资源。因此，技术特征B被对比文件直接公开。 |
| **C：接收交织的在各自的子帧中的UL授权和DL授权**<br>**判断结果：未公开** | 未找到对应内容。 | 目标专利的“交织的UL授权和DL授权”特指在时间上交替接收UL和DL授权（如一个UL授权后跟一个DL授权，或反之），用于支持TDD模式下的交织数据传输或提高FDD效率。对比文件虽然提到了设备可以接收DL指派和UL授权，但并未描述或暗示这些授权是以“交织”的方式在各自的子帧中被接收的。对比文件的核心在于支持窄带操作本身，而未涉及这种特定的、交织的授权时序安排。因此，该技术特征未被对比文件公开。 |
| **D：以及响应于所接收的交织的在各自的子帧中的UL授权和DL授权来发送或接收信息。**<br>**判断结果：未公开** | 未找到对应内容。 | 该特征是对特征C的响应动作，其成立依赖于特征C的“接收交织的授权”。由于对比文件未公开“接收交织的授权”，因此也就不存在“响应于所接收的交织的授权来发送或接收信息”这一特定行为。虽然对比文件提到了根据接收的指派发送或接收信息，但这与目标专利中针对“交织授权”的特定响应无关。因此，该技术特征未被对比文件公开。 |
| **E：根据权利要求1所述的方法，其中，接收所述交织的在各自的子帧中的UL授权和DL授权包括以下至少一者：在UL授权之后接收DL授权作为下一个授权，或者在DL授权之后接收UL授权作为下一个授权。**<br>**判断结果：未公开** | 未找到对应内容。 | 该特征进一步定义了“交织授权”的具体顺序。对比文件完全没有提及UL和DL授权之间存在这种“下一个授权”的交替顺序关系。因此，该技术特征未被对比文件公开。 |
| **F：根据权利要求1所述的方法，其中，所述UE监视控制信道搜索空间，并且在UL授权之后并在响应于所述UL授权的在UL数据信道上所述发送信息的开始之后，接收DL授权作为下一个授权。**<br>**判断结果：未公开** | 未找到对应内容。 | 该特征描述了在UL数据传输开始后接收DL授权的特定交织场景。对比文件未涉及任何关于在UL数据传输期间或之后接收DL授权的内容，更未提及“控制信道搜索空间”在此特定时序下的监视行为。因此，该技术特征未被对比文件公开。 |
| **G：根据权利要求4所述的方法，其中，在所述UE在其中在所述UL数据信道上发送信息的子帧之后并在用于DL通信的子帧之前的子帧用作保护子帧。**<br>**判断结果：未公开** | 未找到对应内容。 | 该特征涉及在交织的UL和DL传输之间使用保护子帧以避免冲突，这是TDD或半双工操作中的特定时序处理。对比文件未讨论交织的UL/DL传输，也未提及“保护子帧”的概念或用途。因此，该技术特征未被对比文件公开。 |
| **H：根据权利要求1所述的方法，其中，所述交织的在各自的子帧中的UL授权和DL授权中的每一个授权支持一个或多个混合自动重传请求(HARQ)过程。**<br>**判断结果：未公开** | 未找到对应内容。 | 该特征限定了交织授权对HARQ过程的支持。对比文件虽然可能提及HARQ（如“混合ARQ”），但并未将其与“交织的UL和DL授权”这一特定上下文相关联。由于对比文件未公开“交织授权”，因此该限定特征也无从谈起。 |
| **I：根据权利要求8所述的方法，其中，所述交织的在各自的子帧中的UL授权和DL授权中的每一个授权支持两个HARQ过程。**<br>**判断结果：未公开** | 未找到对应内容。 | 该特征进一步限定每个交织授权支持两个HARQ过程。对比文件未涉及“交织授权”，也未提及对两个HARQ过程的支持。因此，该技术特征未被对比文件公开。 |
| **J：根据权利要求8所述的方法，其中，所述UE经由能力信令指示对以下至少一者的支持：针对每个UL授权或DL授权的两个HARQ进程，或UL授权和DL授权的交织。**<br>**判断结果：未公开** | 未找到对应内容。 | 该特征涉及UE通过能力信令指示对特定功能（两个HARQ过程或交织授权）的支持。对比文件未提及UE通过能力信令指示支持“交织授权”或“两个HARQ过程”。因此，该技术特征未被对比文件公开。 |
| **K：根据权利要求1所述的方法，还包括：响应于所述响应于所接收的交织的在各自的子帧中的UL授权和DL授权来发送或接收信息，识别冲突，所述冲突包括以下至少一者：UL数据信道和DL数据信道之间的冲突，或UL数据信道与混合ARQ确认(HARQ-ACK)信令之间的冲突。**<br>**判断结果：未公开** | 未找到对应内容。 | 该特征涉及在交织授权场景下识别特定类型的冲突（如UL数据信道与DL数据信道冲突）。对比文件未讨论“交织授权”场景，因此也未曾涉及在此场景下可能发生的此类冲突及其识别。因此，该技术特征未被对比文件公开。 |
| **L：根据权利要求11所述的方法，其中，所述HARQ-ACK信令包括确认或否定确认(NACK)，并且其中，所述HARQ-ACK信令是针对所述DL数据信道的。**<br>**判断结果：未公开** | 未找到对应内容。 | 该特征是对特征K中冲突所涉HARQ-ACK信令的进一步定义。由于特征K未被公开，且对比文件未在交织授权上下文中定义此类冲突和信令，因此该技术特征未被对比文件公开。 |
| **M：根据权利要求11所述的方法，其中，所述冲突包括所述UL数据信道和所述DL数据信道之间的所述冲突，所述方法还包括以下至少一个步骤：确定使用所述UL数据信道和所述DL数据信道中的一者，或对于在所述UL数据信道和所述DL数据信道之间冲突的子帧，确定使用所述UL数据信道和所述DL数据信道中的一者的所述子帧。**<br>**判断结果：未公开** | 未找到对应内容。 | 该特征描述了在UL/DL数据信道冲突时的解决步骤。对比文件未公开此类冲突场景，因此也未提供相应的冲突解决步骤。因此，该技术特征未被对比文件公开。 |
| **N：根据权利要求13所述的方法，其中，所述确定使用的步骤是至少部分地基于能量度量阈值的。**<br>**判断结果：未公开** | 未找到对应内容。 | 该特征限定了冲突解决步骤基于能量度量阈值。由于特征M（冲突解决步骤）未被公开，且对比文件未提及在类似上下文中使用能量度量阈值进行决策，因此该技术特征未被对比文件公开。 |
| **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）。由于特征O（复用步骤）未被公开，且对比文件从未提及这种特定的复用技术，因此该技术特征未被对比文件公开。 |
| **Q：根据权利要求1所述的方法，其中，所述UE被配置用于窄带物联网(NB-IoT)。**<br>**判断结果：隐含公开** | 说明书：“NB-IoT可以指專門為IoT設計的窄帶無線電技術...設備例如MTC設備或者其他UE設備可以針對可以由GSM/GPRS網路處理的低端（例如，低成本、低速率）應用。” | 对比文件明确讨论了窄带物联网（NB-IoT）技术以及低成本、低速率设备（如MTC设备、IoT设备）在窄带中的操作。虽然未明确记载“UE被配置用于NB-IoT”这一具体表述，但本领域技术人员基于对比文件对NB-IoT及其设备应用的描述，可以合理推断其所描述的支持窄带操作的设备（UE）可以被配置用于NB-IoT。因此，该技术特征被对比文件隐含公开。 |
| **R：根据权利要求1所述的方法，其中，所述UE被配置用于时分双工(TDD)操作。**<br>**判断结果：未公开** | 未找到对应内容。 | 对比文件虽然提到了TDD（例如在描述PRACH和子帧配置时），但并未明确或暗示其所描述的支持窄带操作的UE被配置用于TDD操作。其技术方案主要聚焦于频带内、保护带或独立的窄带部署，未强调双工模式。因此，该技术特征未被对比文件公开。 |
| **S：根据权利要求1所述的方法，其中，所述UE被配置用于频分双工(FDD)操作。**<br>**判断结果：隐含公开** | 说明书：“例如，在FDD情況下，變數可以是隨機存取前導碼的子載波間隔...在FDD情況下可以是PRACH前導碼序列長度...”、“在示例實施方式中，eMTC UE可以提供高達15dB的覆蓋增強...eMTC UE可以在更寬的系統頻寬...中操作...”。 | 对比文件多次提及FDD情况下的参数和示例（如PRACH前導碼），并描述了eMTC等窄带操作技术，这些技术通常与FDD模式相关联。虽然未直接写明“UE被配置用于FDD操作”，但本领域技术人员结合对比文件对FDD相关参数和窄带通信（常基于FDD）的描述，可以合理推断其所描述的窄带UE能够被配置用于FDD操作。因此，该技术特征被对比文件隐含公开。 |
| **T：根据权利要求1所述的方法，其中，所述控制信道包括窄带物理下行链路控制信道(NPDCCH)。**<br>**判断结果：未公开** | 未找到对应内容。 | 对比文件提到了控制信道，如PDCCH、ePDCCH、M-PDCCH等，用于窄带设备。但“窄带物理下行链路控制信道(NPDCCH)”是NB-IoT标准中特定的控制信道名称。对比文件并未使用或提及“NPDCCH”这一特定术语。因此，该技术特征未被对比文件公开。 |
| **U：根据权利要求1所述的方法，其中，所述发送信息包括：响应于所接收的UL授权，在UL数据信道中发送信息；并且其中，所述接收信息包括响应于所述DL授权在DL数据信道中接收信息。**<br>**判断结果：直接公开** | 说明书：“设备可以接收带内指派（assignment），例如下行链路指派和/或上行链路授权。根据这种带内指派，设备可以监视和/或决定可以由网路提供的一个或多个传输（例如，在窄或者减少的通道频宽中）。” | 对比文件明确记载了设备接收下行链路指派（对应DL授权）和上行链路授权（对应UL授权），并根据这些指派/授权来决定/进行传输。这直接公开了响应于UL授权发送信息（上行传输）以及响应于DL授权接收信息（下行传输）的基本操作。因此，该技术特征被对比文件直接公开。 |
| **V：根据权利要求21所述的方法，其中，所述UL数据信道包括窄带物理上行链路共享信道(NPUSCH)，并且其中，所述DL数据信道包括窄带物理下行链路共享信道(NPDSCH)。**<br>**判断结果：未公开** | 未找到对应内容。 | 对比文件提到了上行链路和下行链路共享信道（如PUSCH, PDSCH）以及为窄带设备定义的数据信道（如M-PDSCH），但并未使用“窄带物理上行链路共享信道(NPUSCH)”和“窄带物理下行链路共享信道(NPDSCH)”这两个NB-IoT标准中特定的信道名称。因此，该技术特征未被对比文件公开。 |
| **W：根据权利要求11所述的方法，其中，所述DL数据信道包括窄带物理下行链路共享信道(NPDSCH)，所述HARQ-ACK包括混合自动重传请求(HARQ)确认或否定确认，并且所述UL数据信道包括窄带物理上行链路共享信道(NPUSCH)。**<br>**判断结果：未公开** | 未找到对应内容。 | 该特征进一步定义了特征K中冲突所涉及的信道和信令的具体类型。由于特征K（冲突识别）未被公开，且对比文件未提及“NPDSCH”和“NPUSCH”这些特定信道名称在该冲突上下文中的使用，因此该技术特征未被对比文件公开。 |
<<<A>>><<<B>>><<<D>>><<<q>>><<<s>>><<<U>>>