**对比文件名称**：发明公开_EP3036957A4 PUCCH RESOURCE MAPPING AND HARQ-ACK FEEDBACK
**目标专利名称**：PUCCH资源映射和HARQ‑ACK反馈
**本次调用的模型名称**：DeepSeek
### 特征比对表格
| 技术特征描述及公开性判断结果 | 对比文件原文引用 | 公开性论述 |
| **技术特征A**：一种用于由用户装备UE进行无线通信的方法<br>**判断结果**：直接公开 | 说明书第[0001]段：“本申请是申请日为2014年7月17日的题为“PUCCH资源映射和HARQ‑ACK反馈”的中国发明专利申请...的分案申请。” <br>说明书第[0023]段：“根据本文中所提供的某些方面，UE能够确定支持动态UL‑DL子帧配置的系统中的上行链路资源分配。” <br>说明书第[0186]段：“图11解说了根据本公开各方面的可由用户装备(UE)执行的用于无线通信的示例操作1100。” | 对比文件整体上描述了一种由用户装备（UE）执行的无线通信方法，涉及在支持动态TDD配置（eIMTA）的系统中进行PUCCH资源映射和HARQ-ACK反馈。其发明主题、应用场景与目标专利完全一致。因此，技术特征A被对比文件直接公开。 |
| **技术特征B**：接收指示动态上行链路‑下行链路UL‑DL子帧配置的信令<br>**判断结果**：直接公开 | 说明书第[0047]段：“本公开的各方面可以被使用在增强型干扰管理和话务适配(eIMTA)系统中，其中上行链路‑下行链路(UL‑DL)子帧配置可以被动态地切换...” <br>说明书第[0118]段：“操作1100开始于1102，接收指示动态上行链路‑下行链路(UL‑DL)子帧配置的信令。” | 对比文件明确描述了在eIMTA系统中，UL-DL子帧配置可以被动态切换，并且在图11所示的UE操作流程中，第一步就是接收指示该动态配置的信令。这与目标专利中特征B的内容完全相同。因此，技术特征B被对比文件直接公开。 |
| **技术特征C**：基于所述动态UL‑DL子帧配置来确定混合自动重复请求HARQ确收/否定确收ACK/NACK定时<br>**判断结果**：未公开 | 说明书第[0053]段：“为了简化eIMTA的操作，有可能将一种或多种DL/UL配置定义为用于许多物理层操作的参考。作为示例，DL HARQ操作可以基于作为参考配置的DL/UL子帧配置#5，而不管特定帧（或半帧）中正在使用的实际DL/UL子帧配置。” <br>说明书第[0065]段：“本公开的各方面提供了基于参考配置和动态配置两者的“混合”设计。例如，对于PDSCH HARQ‑ACK反馈，HARQ定时可以基于参考配置（例如，用以传送PDSCH HARQ‑ACK的子帧可以从参考配置确定）。” | 对比文件的核心教导之一是HARQ ACK/NACK定时基于一个**参考**UL-DL子帧配置来确定，而非基于**动态**UL-DL子帧配置。这是其“混合设计”的关键点，旨在解决基于动态配置确定定时可能导致的ACK/NACK传输机会错失等问题。这与目标专利中要求基于动态配置确定定时的特征C存在根本区别。因此，技术特征C既未被直接公开，也未被隐含公开。 |
| **技术特征D**：基于所述动态UL‑DL子帧配置来确定针对物理上行链路控制信道PUCCH的HARQ资源分配<br>**判断结果**：直接公开 | 说明书第[0065]段：“然而，HARQ‑ACK码本大小以及PUCCH资源分配可以通过动态TDD UL‑DL配置确定（例如，基于重配置的动态L1信令）。” <br>说明书第[0118]段：“在1106，UE可以基于动态UL‑DL子帧配置确定HARQ资源分配。” | 对比文件明确教导了PUCCH资源分配（即HARQ资源分配）是基于动态TDD UL-DL配置来确定的。这与其“混合设计”中“HARQ定时基于参考配置，而资源分配基于动态配置”的理念完全吻合。因此，技术特征D被对比文件直接公开。 |
| **技术特征E**：以及基于所确定的HARQ资源分配和HARQ ACK/NACK定时来在所述PUCCH上传送HARQ ACK/NACK<br>**判断结果**：直接公开 | 说明书第[0118]段（结合图11）：操作1100描述了UE接收动态配置信令、基于参考配置确定HARQ ACK/NACK定时、基于动态配置确定HARQ资源分配的完整流程。其必然的逻辑结果和目的是使用所确定的定时和资源在PUCCH上发送HARQ ACK/NACK。 <br>说明书第[0055]段：“PUCCH资源分配可以被隐式地确定...下行链路关联集可以取决于TDD UL‑DL配置。” 该描述隐含了确定资源的目的是用于ACK/NACK传输。 | 对比文件所描述的方法的最终目的和必然实施步骤就是在PUCCH上传输HARQ ACK/NACK。虽然原文没有用完全相同的句式描述“传送”这一动作，但根据说明书整体内容（尤其是图11的操作流程）和本领域公知常识，确定定时和资源分配后，必然是为了在PUCCH上进行相应的ACK/NACK传输。这属于直接公开的内容。 |
| **技术特征F**：基于所述动态UL‑DL子帧配置来确定HARQ资源分配包括基于所述动态UL‑DL子帧配置来确定HARQ‑ACK码本大小。<br>**判断结果**：直接公开 | 说明书第[0065]段：“然而，HARQ‑ACK码本大小以及PUCCH资源分配可以通过动态TDD UL‑DL配置确定...” <br>说明书第[0067]段：“在一些情形中，码本大小或者ACK/NACK位的数目可以基于如从动态UL‑DL配置和DL传输模式确定的DL关联集大小M的实际大小...来确定。” | 对比文件明确将“确定HARQ‑ACK码本大小”作为“基于动态UL-DL配置确定HARQ资源分配”的具体实现方式之一。这与特征F的表述完全一致。因此，技术特征F被对比文件直接公开。 |
| **技术特征G**：所述码本大小或ACK/NACK位的数目中的至少一者基于所述动态UL‑DL子帧配置的DL关联集的大小来确定。<br>**判断结果**：直接公开 | 说明书第[0067]段：“码本大小或者ACK/NACK位的数目可以基于如从动态UL‑DL配置和DL传输模式确定的DL关联集大小M的实际大小...来确定。” | 对比文件明确、直接地记载了码本大小或ACK/NACK位数基于动态UL-DL配置的DL关联集大小M来确定。这与特征G的表述完全一致。因此，技术特征G被对比文件直接公开。 |
| **技术特征H**：基于所述动态UL‑DL子帧配置来确定HARQ资源分配包括基于所述动态UL‑DL子帧配置来确定物理上行链路控制信道PUCCH资源分配。<br>**判断结果**：直接公开 | 说明书第[0068]段：“根据某些方面，PUCCH资源映射可以基于动态子帧配置确定。” <br>说明书第[0069]段：“...eIMTA UE可以基于动态指示的UL‑DL配置的DL关联集的大小M来确定PUCCH资源分配。” | 对比文件将“基于动态配置确定PUCCH资源分配”作为“基于动态配置确定HARQ资源分配”的核心内容和具体实施方式。这与特征H的表述完全一致。因此，技术特征H被对比文件直接公开。 |
| **技术特征I**：所述物理上行链路控制信道PUCCH资源分配基于所述动态UL‑DL子帧配置的DL关联集的大小来确定。<br>**判断结果**：直接公开 | 说明书第[0069]段：“eIMTA UE可以基于动态指示的UL‑DL配置的DL关联集的大小M来确定PUCCH资源分配。” | 对比文件明确、直接地记载了PUCCH资源分配是基于动态UL-DL配置的DL关联集大小M来确定的。这与特征I的表述完全一致。因此，技术特征I被对比文件直接公开。 |
| **技术特征J**：当确定所述DL关联集的所述大小时，集束集合中未被配置为所述动态UL‑DL配置中的DL的灵活子帧不被计及。<br>**判断结果**：直接公开 | 说明书第[0069]段：“更确切来说，集束集合中未被动态重配置信令配置为DL子帧的灵活子帧可以不被计及，而剩余的DL子帧可以被用来确定关联集大小M。” | 对比文件明确描述了在确定DL关联集大小M时，只计及被动态配置为DL的子帧，未被如此配置的灵活子帧则不被计及。这与特征J的表述完全一致。因此，技术特征J被对比文件直接公开。 |
| **技术特征K**：包括通过移除UL子帧来确定所述集束集合中的剩余DL子帧的打包次序。<br>**判断结果**：直接公开 | 说明书第[0069]段：“集束集合中的剩余DL子帧的打包次序也可以通过移除UL子帧来改变。” | 对比文件明确记载了通过移除UL子帧来改变（即确定）剩余DL子帧的打包次序。这与特征K的表述完全一致。因此，技术特征K被对比文件直接公开。 |
| **技术特征L**：其中，固定DL子帧在所述剩余DL子帧的打包次序中被映射为第一个。<br>**判断结果**：隐含公开 | 说明书第[0069]段：“此外，剩余DL子帧的打包次序也可以被重新排序，例如，其中固定DL子帧始终被映射为第一个。” | 对比文件明确提到了“固定DL子帧始终被映射为第一个”作为重新排序打包次序的一个示例。虽然该句以“例如”开头，表明这是一种可选或示例性方案，但本领域技术人员阅读该描述后，能够清楚地理解到“将固定DL子帧映射为第一个”是实现重新排序以优化资源利用、避免冲突的一种合理且明确的技术手段。因此，该技术特征被对比文件隐含公开。 |
| **技术特征M**：为能够支持动态UL‑DL子帧配置的UE和不能够支持动态UL‑DL子帧配置的UE配置分开的PUCCH区域。<br>**判断结果**：直接公开 | 说明书第[0070]段：“在一些情形中，分开的PUCCH资源区域可以被配置用于eIMTA UE和旧式UE以避免（1）冲突...” | 对比文件明确提到了为eIMTA UE（支持动态配置）和旧式UE（不支持动态配置）配置分开的PUCCH区域以避免冲突。这与特征M的表述完全一致。因此，技术特征M被对比文件直接公开。 |
| **技术特征N**：包括确定针对能够支持动态UL‑DL子帧配置的UE的所述PUCCH区域与针对不能够支持动态UL‑DL子帧配置的UE的所述PUCCH区域之间是否存在潜在冲突。<br>**判断结果**：直接公开 | 说明书第[0071]段：“然而，若eIMTA UE没有检测到与旧式UE PUCCH区域的冲突...” <br>说明书上下文隐含了“检测冲突”是选择使用哪个PUCCH区域或偏移值的前提步骤。 | 对比文件明确提到了eIMTA UE需要检测其PUCCH区域是否与旧式UE的PUCCH区域冲突。虽然“确定是否存在潜在冲突”这一动作未以独立步骤形式明确写出，但根据“若没有检测到冲突，则...”的逻辑表述，本领域技术人员可以直接且毫无疑义地确定，“检测/确定冲突”是该过程的一个必然包含的步骤。因此，技术特征N被对比文件直接公开。 |
| **技术特征O**：若没有检测到潜在冲突，则使用针对不能够支持动态UL‑DL子帧配置的UE的所述PUCCH区域。<br>**判断结果**：直接公开 | 说明书第[0071]段：“...若eIMTA UE没有检测到与旧式UE PUCCH区域的冲突，则旧式UE所使用的默认N PUCCH也可以被eIMTA UE使用。” | 对比文件明确记载了如果没有检测到冲突，eIMTA UE就使用旧式UE的PUCCH区域（即“默认N PUCCH”）。这与特征O的表述完全一致。因此，技术特征O被对比文件直接公开。 |
| **技术特征P**：若没有检测到潜在冲突，则为第一偏移值；以及若检测到潜在冲突，则为第二偏移值。<br>**判断结果**：直接公开 | 说明书第[0071]段：“...eIMTA UE可以确定在UL子帧中，若与用于旧式的UL子帧相关联的DL关联集和动态指示的配置相同，那么UE可以使用第一偏移（例如，与旧式UE相同）。否则，eIMTA可以使用第二偏移。” | 对比文件明确描述了根据条件（是否相同，这实质上对应是否存在潜在冲突）来选择使用第一偏移值或第二偏移值。这与特征P的表述完全一致。因此，技术特征P被对比文件直接公开。 |
| **技术特征Q**：指示动态上行链路‑下行链路UL‑DL子帧配置的所述信令包括动态信令。<br>**判断结果**：直接公开 | 说明书第[0065]段：“...基于重配置的动态L1信令。” <br>说明书第[0118]段：“如以上所述，指示动态UL‑DL子帧配置的信令可包括L1信令。” | 对比文件明确将指示动态配置的信令描述为“动态L1信令”，这属于动态信令的一种。因此，技术特征Q被对比文件直接公开。 |
| **技术特征R**：所述动态信令经由以下至少一者来传达：用于发射功率控制TPC命令的下行链路控制信息DCI格式中的一个或多个位，或者一个或多个确收资源偏移ARO位。<br>**判断结果**：直接公开 | 说明书第[0072]段：“...eNB可以重用在集束集合的共用DL子帧中传送的DCI格式（例如，1A/1B/1D/1/2A/2/2B/2C/2D）中的发射功率控制（TPC）命令位。” <br>说明书第[0072]段：“作为另一选项，共用DL子帧中的TPC命令可被用作HARQ‑ACK资源偏移（ARO）。” | 对比文件明确教导了动态信令（用于资源分配或偏移指示）可以通过DCI格式中的TPC命令位来传达，或者TPC命令位本身可以被用作ARO。这完全覆盖了特征R的两种传达方式。因此，技术特征R被对比文件直接公开。 |
| **技术特征S**：检测丢失的动态UL‑DL子帧配置；以及响应于所述检测，基于系统信息块SIB中信令通知的UL‑DL子帧配置来确定HARQ资源分配。<br>**判断结果**：直接公开 | 说明书第[0066]段：“支持回退方案也会是直接了当的，例如，在丢失动态重配置信令或者解码尝试失败的情形中。在此类情形中，SIB1 UL‑DL配置可以被用于确定HARQ‑ACK码本大小和PUCCH资源分配。” | 对比文件明确描述了在丢失动态信令（即检测到丢失）时，转而使用SIB1中的配置来确定HARQ资源分配（包括码本大小和PUCCH资源分配）。这与特征S的表述完全一致。因此，技术特征S被对比文件直接公开。 |
<<<A>>><<<B>>><<<D>>><<<E>>><<<F>>><<<G>>><<<H>>><<<I>>><<<J>>><<<K>>><<<M>>><<<N>>><<<O>>><<<P>>><<<Q>>><<<R>>><<<S>>><<<l>>>