**对比文件名称：** 2013-11-14_US2013301600A_发明申请_US20130301600A1 METHOD FOR ALLOCATING RESOURCES FOR HARQ ACK_NACK SIGNAL TRANSMISSION, AND METHOD AND APPARATUS FOR HARQ ACK_NACK SIGNAL TRANSMISSION USING SAME
**目标专利名称：** 1542执行物理上行链路控制信道传输的方法和使用该方法的用户设备CN111869289B
**本次调用的模型名称：** 大型语言模型 (GPT-4)
---
## 特征比对表格
| 技术特征及公开性判断 | 对比文件原文引用（翻译后） | 公开性论述 |
| **技术特征A**：所述方法由用户设备UE执行并且包括<br>《直接公开》 | [0209] “MS（移动站，即UE）从BS接收更高层信令（如RRC信令）...（S1010）”；[0210] “MS接收下行控制信道上的信息（S1020）...获得由所接收的ARI指示的PUCCH资源（S1030）...使用所接收的PUCCH资源发送HARQ ACK/NACK信号（S1040）”。 | 对比文件明确描述了由移动站（MS/UE）执行的一系列步骤，包括接收高层信令、接收PDCCH（包含ARI）、获取PUCCH资源并发送HARQ-ACK/NACK。这与特征A的方法主体和基本流程一致，属于直接公开。 |
| **技术特征B**：从基站接收系统信息，其中所述系统信息通知多个物理上行链路控制信道PUCCH资源集之中的PUCCH资源集，其中所述多个PUCCH资源集中的每个被预定义<br>《未公开》 | [0196] “BS通过更高层信令如RRC信令向MS发送HARQ ACK/NACK信号传输所需的信息...包括ARI映射表，该表包含PUCCH资源集（子集）”。[0125] “ARI映射表...可通过更高层信令（如RRC信令）预先传送给MS”。 | 对比文件通过RRC信令（专用信令）发送ARI映射表，其中包含PUCCH资源子集，但并非通过广播系统信息（如SIB/RMSI）来通知一个从多个预定义资源集中选出的资源集。对比文件中的PUCCH资源集是由BS动态配置的，而非预定义在规范中（由标准事先规定）。本领域技术人员不能毫无疑义地从中得出“系统信息通知预定义的资源集”这一方案。且即使放宽标准，对比文件也未提供关于“系统信息”或“预定义资源集”的任何教导或暗示，因此不构成直接或隐含公开。 |
| **技术特征C**：基于所述PUCCH资源集中的PUCCH资源来执行PUCCH上的HARQ‑ACK传输，其中在所述PUCCH上发送的比特数目小于2或更少<br>《直接公开》 | [0087] “用于仅发送HARQ ACK/NACK信号的PUCCH格式包括PUCCH格式1a/1b...格式1a发送1比特，格式1b发送2比特”；[0201] “MS通过使用所获得的PUCCH资源在PUCCH上发送HARQ ACK/NACK信号”。 | 对比文件明确记载了MS使用通过ARI获得的PUCCH资源（即PUCCH资源集中的资源）在PUCCH上发送HARQ ACK/NACK信号，并且该HARQ ACK/NACK信号可以是1比特或2比特（≤2）。这种使用方式与特征C完全吻合，具有相同的作用——完成HARQ-ACK反馈。因此，技术特征C被直接公开。 |
| **技术特征D**：其中，所述多个PUCCH资源集中的每个通知起始符号、符号数目和PUCCH格式；并且，所述PUCCH格式是PUCCH格式0或PUCCH格式1<br>《未公开》 | 对比文件涉及LTE-A的PUCCH格式（1a/1b、3等），未提及PUCCH格式0或1。且对比文件没有“起始符号”、“符号数目”作为资源集可配置参数的概念；LTE中PUCCH的起始符号和符号数目是固定或由资源索引隐式确定，而不是作为通知参数。 | 目标专利中每个PUCCH资源集显式关联起始符号、符号数目和PUCCH格式（0或1），这是NR特有的设计。对比文件完全不涉及此类参数，也未描述PUCCH格式0和1（PUCCH格式0在NR中为短格式，对比文件无对应）。因此，无法直接或隐含公开该特征。 |
| **技术特征E**：其中，所述预定义的多个PUCCH资源集的数目是16<br>《未公开》 | 对比文件中ARI映射表通常包括4个PUCCH资源子集（对应2比特ARI），虽然可以扩展，但从未提及或暗示数目为16，也没有“预定义16个资源集”的概念。 | 目标专利明确预定义16个资源集（[0011]、[0019]），这是由标准预先规定的固定数量。对比文件中的资源集数目取决于网络配置（如k值），且没有16这个特殊数值。故不公开。 |
| **技术特征F**：其中，所述多个PUCCH资源集中的每个与所述PUCCH格式以及所述起始符号和所述符号数目的组合相关<br>《未公开》 | 同特征D，对比文件没有将PUCCH格式、起始符号、符号数目作为组合与资源集关联起来的任何记载。 | 特征F进一步强调每个资源集对应于特定的格式、起始符号和符号数目的组合。对比文件无此组合概念，也不存在通过组合区分资源集的教导。不公开。 |
| **技术特征G**：其中，所述预定义的多个PUCCH资源集的符号数目包括2、10和14<br>《未公开》 | 对比文件未提及PUCCH符号数目的可变性。LTE中PUCCH通常占用整个子帧（14个OFDM符号），没有2符号或10符号的PUCCH传输。 | 目标专利中符号数目2、10、14是NR PUCCH格式0/1的典型值，由标准预定义。对比文件无对应，且LTE系统不支持此类灵活的符号长度。不公开。 |
| **技术特征H**：其中，所述UE不被配置专用PUCCH资源<br>《未公开》 | 对比文件整个机制基于通过RRC信令配置专用资源（ARI映射表等），如[0209]“MS...接收更高层信令”，且未提及UE未配置专用资源的情况；没有与“不配置专用资源”相关的任何描述。 | 目标专利的特征H强调在UE未获得专用PUCCH资源配置时使用系统信息指示的默认资源集。对比文件涉及的是已配置专用资源的UE（通过RRC获得ARI映射表），没有提供关于“无专用配置时”的退避方案或默认操作。因此不公开。 |
---
**结论**：对比文件直接公开了技术特征A和技术特征C，其他技术特征未公开（既不直接公开也不隐含公开）。
<<<A>>><<<C>>>