好的，我们开始评估。
**对比文件名称**：2011-10-27_WO2011132721A_发明申请_WO2011132721A1 COMMUNICATION METHOD AND SYSTEM FOR PHYSICAL UPLINK CONTROL CHANNEL RESOURCE ASSIGNMENT, AND BASE STATION, USER EQUIPMENT AND INTEGRATED CIRCUIT THEREIN
**目标专利名称**：1542执行物理上行链路控制信道传输的方法和使用该方法的用户设备CN111869289B
**本次调用的模型名称**：未提供
以下为特征比对表格及公开性分析：
| 技术特征描述及公开性判断结果 | 对比文件原文引用（翻译） | 公开性论述 |
| **技术特征A**：所述方法由用户设备UE执行并且包括<br>**《直接公开》** | **[p0025]** “一种用户设备的方法，包括：基于从基站接收的高层信令配置四个物理上行链路控制信道资源索引；根据索引指示符确定所述四个索引中的一个索引；使用具有所述索引的物理上行链路控制信道资源向基站发送HARQ-ACK/NACK。” | 对比文件明确记载了由用户设备（UE）执行的方法，包括接收配置、确定索引和发送HARQ-ACK/NACK等步骤。该描述覆盖了方法执行主体的限定，本领域技术人员能够毫无疑义地确定该方法是UE执行的，与目标专利技术特征A作用相同，均涉及上行控制信道的传输过程。因此，技术特征A被对比文件直接公开。 |
| **技术特征B**：从基站接收系统信息，其中所述系统信息通知多个物理上行链路控制信道PUCCH资源集之中的PUCCH资源集，其中所述多个PUCCH资源集中的每个被预定义<br>**《未公开》** | **[p0089]** “基站进一步通过例如RRC信令向用户设备UE专用地配置PUCCH资源配置的参数。该UE专用配置的参数在本发明中包括PUCCH资源列表、分量载波索引等。其中，PUCCH资源列表包括指示一个或多个PUCCH资源的信息，这些资源是用户设备发送UCI（例如HARQ-ACK和/或CQI和/或SR）的可用候选。” | 对比文件公开的是通过专用RRC信令（高层信令）向UE配置PUCCH资源候选列表，该信令是UE特定的（UE-specific）。目标专利中“系统信息”特指广播的系统信息（如RMSI），用于通知多个预定义PUCCH资源集中的一个。对比文件既未使用广播系统信息，也未涉及多个预定义的资源集，其RRC配置的资源列表是动态配置的候选资源，与目标专利的预定义资源集概念不同。因此，技术特征B未被对比文件直接公开或隐含公开。 |
| **技术特征C**：基于所述PUCCH资源集中的PUCCH资源来执行PUCCH上的HARQ-ACK传输，其中在所述PUCCH上发送的比特数目小于2或更少<br>**《未公开》** | **[p0025]** “使用具有所述索引的物理上行链路控制信道资源向基站发送HARQ-ACK/NACK。”；**[p0013]** “多路复用结构也是提出的解决方案之一。对于多路复用，对应于来自不同下行分量载波的PDSCH的多个HARQ-ACK/NACK反馈比特将在一个上行分量载波上以类似LTE Rel-8中TDD HARQ-ACK/NACK复用方案的方式发送，这称为使用PUCCH格式1b结合信道选择的HARQ-ACK/NACK复用。” | 对比文件仅泛泛提及发送HARQ-ACK/NACK，未对PUCCH上发送的比特数目做任何限制。对比文件中载波聚合场景可能产生多于2比特的UCI（例如多个下行分量载波的HARQ-ACK）。目标专利的特征C限定“比特数目小于2或更少”（即≤2），该限定与初始接入时的少量UCI对应。对比文件既未明示也未暗示该比特数限制，本领域技术人员不能从对比文件毫无疑义地得出PUCCH传输仅用于≤2比特的HARQ-ACK。因此，技术特征C未被公开。 |
| **技术特征D**：其中，所述多个PUCCH资源集中的每个通知起始符号、符号数目和PUCCH格式；并且其中，所述PUCCH格式是PUCCH格式0或PUCCH格式1<br>**《未公开》** | **[p0093]** “上述PUCCH资源指资源块以及时域覆盖码和/或循环移位（具体参数取决于PUCCH格式的设计细节）。”；全文无关于起始符号、符号数目的记载；PUCCH格式方面主要涉及格式1a/1b/2/2a/2b等（如**[p0013]**提及PUCCH格式1b）。 | 对比文件描述的PUCCH资源配置使用PRB索引、循环移位、正交覆盖码等参数，没有涉及“起始符号”和“符号数目”这两个时域参数。在LTE系统中，PUCCH通常占用整个子帧（固定14个OFDM符号），起始符号固定为0，不存在像NR中那样由资源集明确指示灵活起始符号和符号数目的设计。此外，对比文件中的PUCCH格式为LTE的格式1a/1b/2等，而目标专利的PUCCH格式0和1是NR新定义的短格式（1-2符号）和长格式（4-14符号），两者在结构和用途上不同，对比文件未公开与NR格式0或1相对应的内容。因此，技术特征D未被公开。 |
| **技术特征E**：其中，所述预定义的多个PUCCH资源集的数目是16<br>**《未公开》** | 全文无记载。 | 对比文件未提及预定义PUCCH资源集的概念，更未提及数目为16。对比文件中由RRC信令配置的PUCCH资源列表包含4个候选资源（**[p0095]**：“PUCCH-AN-List是一个由4个整数变量组成的序列”），与16个预定义资源集完全不同。因此，技术特征E未被公开。 |
| **技术特征F**：其中，所述多个PUCCH资源集中的每个与所述PUCCH格式以及所述起始符号和所述符号数目的组合相关<br>**《未公开》** | 见特征D引用，对比文件未记载起始符号、符号数目，也未记载资源集与这些参数的组合关联。 | 目标专利中每个PUCCH资源集被定义为具有一个PUCCH格式以及一组起始符号和符号数目的组合（如{起始符号索引，持续时间}）。对比文件中的资源由PRB、CS、OCC等参数定义，与格式、起始符号、符号数目的组合无关。本领域技术人员无法从对比文件得到任何关于这种组合关联的技术启示。因此，技术特征F未被公开。 |
| **技术特征G**：其中，所述预定义的多个PUCCH资源集的符号数目包括2、10和14<br>**《未公开》** | 全文无记载。 | 对比文件未涉及PUCCH符号数目的定义，更未公开2、10、14这些具体数值。LTE中PUCCH通常为14个符号，但对比文件未明确其资源集包含10或2符号。目标专利特征G是NR特定设计中为适应不同场景（短PUCCH、长PUCCH）而设置的。因此，技术特征G未被公开。 |
| **技术特征H**：其中，所述UE不被配置专用PUCCH资源<br>**《未公开》** | **[p0089]** “基站通过例如RRC信令向用户设备UE专用地配置PUCCH资源配置的参数。”；**[p0093]** “该PUCCH资源集是新定义的，与LTE Rel-8中为UCI传输指定的不同。基站通过专用信令（如RRC信令）和/或广播信令（如SIB）向用户设备发信令通知该PUCCH资源集的配置。” | 对比文件的核心内容即通过RRC信令为UE配置专用PUCCH资源（包括资源候选列表和资源索引指示）。相反，目标专利特征H强调UE未被配置专用PUCCH资源，仍使用默认资源集（通过系统信息获取）。对比文件仅公开了UE被配置专用资源的情况，不存在未配置专用资源的场景，更未公开当不被配置专用资源时的处理方式。因此，技术特征H未被公开。 |
**总结：**
以上分析表明，对比文件仅直接公开了技术特征A，其余技术特征B至H均未被直接或隐含公开。
**输出代码：**
<<<A>>>