**对比文件名称**：发明申请_US20140269539A1 SYSTEMS AND METHODS FOR FEEDBACK REPORTING
**目标专利名称**：PUCCH资源映射和HARQ‑ACK反馈（基于说明书内容推断）
**本次调用模型名称**：DeepSeek最新版本模型
**特征比对表格**
| 技术特征描述及公开性判断 | 对比文件原文引用（译文） | 公开性论述 |
| **A. 一种用于由用户装备UE进行无线通信的方法** <br>**《直接公开》** | [0018] “一种用于发送反馈的用户装备（UE）…该UE接收信令以用具有第一上行链路/下行链路（UL/DL）配置的多个服务小区来配置该UE…该UE还基于该至少一个服务小区的第一UL/DL配置和该至少一个服务小区的附加重新配置信息来确定用于该至少一个服务小区的下行链路（DL）参考UL/DL配置…该UE进一步基于该DL参考UL/DL配置来发送物理下行链路共享信道（PDSCH）混合自动重复请求确认/否定确认（HARQ-ACK）信息。” | 对比文件[0018]段明确描述了一种由UE执行的方法，包括接收配置信令、确定参考配置以及发送HARQ-ACK反馈。这直接公开了“一种用于由用户装备UE进行无线通信的方法”这一上位概念。其在对比文件中的作用是定义UE在动态TDD重配置场景下的反馈报告流程，与目标专利中定义UE方法的作用相同。 |
| **B. 接收指示动态上行链路‑下行链路UL‑DL子帧配置的信令** <br>**《直接公开》** | [0018] “该UE接收信令以用具有第一上行链路/下行链路（UL/DL）配置的多个服务小区来配置该UE…如果该UE被配置有该多个服务小区并且至少一个服务小区被配置有允许动态UL/DL重新配置的附加重新配置信息…” | 对比文件[0018]段明确记载了UE接收信令以配置服务小区，且该信令包含“附加重新配置信息”，该信息“允许动态UL/DL重新配置”。这直接公开了接收指示动态UL-DL子帧配置的信令。其在对比文件中用于告知UE小区支持动态重配，与目标专利中用于指示动态子帧配置以进行后续处理的作用相同。 |
| **C. 基于所述动态UL‑DL子帧配置来确定混合自动重复请求HARQ确收/否定确收ACK/NACK定时** <br>**《隐含公开》** | [0018] “…该UE还基于该至少一个服务小区的第一UL/DL配置和该至少一个服务小区的附加重新配置信息来确定用于该至少一个服务小区的下行链路（DL）参考UL/DL配置…该UE进一步基于该DL参考UL/DL配置来发送…（HARQ-ACK）信息。” <br>[0039] “动态UL/DL重新配置允许对PDSCH HARQ-ACK定时应用一种配置，并对PUSCH调度和PUSCH HARQ-ACK定时应用另一种配置。” <br>[0072] “对于PDSCH HARQ-ACK报告，服务小区的DL参考UL/DL配置可以是当为UE配置多于一个服务小区时用于DL HARQ-ACK报告定时的服务小区的参考UL/DL配置。” | 1. **逻辑推理**：目标专利中“基于动态UL-DL子帧配置确定HARQ ACK/NACK定时”实质是确定在哪个UL子帧反馈对应DL子帧的ACK/NACK。对比文件[0018]明确教导UE需基于“DL参考UL/DL配置”来确定发送HARQ-ACK信息（即确定定时）。而该“DL参考UL/DL配置”是根据“第一UL/DL配置”和“附加重新配置信息（允许动态UL/DL重新配置）”来确定的（见[0018]）。因此，DL参考配置的确定依赖于动态重配置信息（即动态UL-DL子帧配置）。<br>2. **作用一致性**：在对比文件中，基于DL参考配置确定HARQ-ACK定时，是为了在动态TDD环境中统一和简化反馈时序，避免因动态切换导致的定时混乱。这与目标专利中为了解决动态子帧配置下的HARQ定时问题而基于动态配置确定定时的作用，在最终目的（确保正确反馈定时）上是相同的，只是实现路径（对比文件通过一个中间“参考配置”，目标专利可能直接基于动态配置）存在差异。本领域技术人员能够理解，在动态TDD系统中，确定HARQ定时必然需要考虑当前的动态子帧配置，对比文件给出的“基于动态重配置信息确定参考配置，再基于参考配置确定定时”的方案，隐含了“定时基于动态配置信息确定”这一更上位的技术思想。因此，该特征被对比文件隐含公开。 |
| **D. 基于所述动态UL‑DL子帧配置来确定针对物理上行链路控制信道PUCCH的HARQ资源分配** <br>**《未公开》** | （对比文件中未发现直接或隐含涉及基于动态UL-DL子帧配置来确定PUCCH资源分配的内容。对比文件核心在于确定HARQ-ACK报告的“定时”（即哪个UL子帧发），而非该UL子帧内具体使用哪个“资源”（即PUCCH资源号）。） | 目标专利中，技术特征D明确要求“基于动态UL-DL子帧配置来确定针对PUCCH的HARQ资源分配”。对比文件通篇聚焦于如何确定用于HARQ-ACK报告的“DL参考UL/DL配置”以及相应的“定时”（见[0018], [0072]等），并未涉及如何根据动态配置来分配具体的PUCCH资源（例如资源块、循环移位等）。资源分配是独立于定时确定的另一个层面问题。因此，对比文件既未直接公开也未隐含公开此特征。 |
| **E. 以及基于所确定的HARQ资源分配和HARQ ACK/NACK定时来在所述PUCCH上传送HARQ ACK/NACK** <br>**《隐含公开》** | [0018] “…该UE进一步基于该DL参考UL/DL配置来发送物理下行链路共享信道（PDSCH）混合自动重复请求确认/否定确认（HARQ-ACK）信息。” <br>[0104] “示例上行链路信道121包括PUCCH和PUSCH等。” | 1. **逻辑推理**：对比文件[0018]明确要求UE发送PDSCH HARQ-ACK信息。在LTE/LTE-A系统中，HARQ-ACK信息通常通过PUCCH或PUSCH发送。对比文件[0104]也明确将PUCCH列为上行链路信道。虽然未明确写“在PUCCH上发送”，但本领域技术人员公知，对于非伴随上行数据发送的HARQ-ACK反馈，其默认且主要的承载信道就是PUCCH。因此，从“发送HARQ-ACK信息”结合本领域公知常识，可以合理且直接地推断出“在PUCCH上传送HARQ ACK/NACK”。<br>2. **作用一致性**：该步骤在对比文件和目标专利中均为方法的最终执行动作，即按照之前确定的规则（定时、资源）进行反馈发送，其作用完全相同。因此，该特征被对比文件隐含公开。 |
| **F. 基于所述动态UL‑DL子帧配置来确定HARQ资源分配包括基于所述动态UL‑DL子帧配置来确定HARQ‑ACK码本大小。** <br>**《未公开》** | （对比文件中未提及“HARQ-ACK码本大小”及其确定方法。） | 目标专利特征F是特征D（确定资源分配）的一个具体实现方式，即通过确定码本大小来参与资源分配。由于对比文件根本未公开“基于动态配置确定HARQ资源分配”（特征D），因此其下位的具体实现方式“确定码本大小”自然也未被公开。对比文件未涉及码本大小的概念。 |
| **G. 所述码本大小或ACK/NACK位的数目中的至少一者基于所述动态UL‑DL子帧配置的DL关联集的大小来确定。** <br>**《未公开》** | （对比文件中未提及“码本大小”或“ACK/NACK位的数目”基于“DL关联集的大小”来确定。） | 此特征涉及资源分配中码本大小的具体确定规则。对比文件虽在[0098]提到了“下行链路关联集（DAS）”的概念，但仅将其作为查找表（Table 10.1.3.1-1）的输入以确定HARQ-ACK反馈对应的DL子帧集合（即定时关系），并未将其与“码本大小”或“ACK/NACK位的数目”的确定关联起来。因此，该特征未被公开。 |
| **H. 基于所述动态UL‑DL子帧配置来确定HARQ资源分配包括基于所述动态UL‑DL子帧配置来确定物理上行链路控制信道PUCCH资源分配。** <br>**《未公开》** | （同特征D，对比文件未涉及基于动态配置确定PUCCH资源分配。） | 此特征与特征D实质相同，强调资源分配的对象是PUCCH资源。由于对比文件未公开基于动态配置确定HARQ资源分配，因此该具体方面也未被公开。 |
| **I. 所述物理上行链路控制信道PUCCH资源分配基于所述动态UL‑DL子帧配置的DL关联集的大小来确定。** <br>**《未公开》** | （同特征G，对比文件未将DL关联集的大小与PUCCH资源分配关联。） | 此特征涉及PUCCH资源分配的具体规则。对比文件未公开基于动态配置确定PUCCH资源分配，更未公开其与DL关联集大小的关系。 |
| **J. 当确定所述DL关联集的所述大小时，集束集合中未被配置为所述动态UL‑DL配置中的DL的灵活子帧不被计及。** <br>**《未公开》** | （对比文件未描述在确定DL关联集大小时，对“未被配置为DL的灵活子帧”进行排除处理的规则。） | 目标专利此特征描述了一种在动态TDD下精简DL关联集的具体算法。对比文件虽然提到了“灵活子帧”（flexible subframe，见[0034]）和“DL关联集”（DAS，见[0098]），但并未揭示两者之间的这种处理关系。对比文件确定DL关联集是基于“DL参考UL/DL配置”（见[0098]），而该参考配置可能是固定的或是包含所有灵活子帧作为DL的配置（如[0075]所述），并未教导根据“当前动态配置中灵活子帧的实际方向”来动态调整计入DL关联集的子帧。 |
| **K. 包括通过移除UL子帧来确定所述集束集合中的剩余DL子帧的打包次序。** <br>**《未公开》** | （对比文件未提及“打包次序”的概念及其确定方法。） | 此特征涉及HARQ-ACK信息在反馈时的排序规则。对比文件未涉及“集束集合中的剩余DL子帧的打包次序”这一具体操作。 |
| **L. 其中，固定DL子帧在所述剩余DL子帧的打包次序中被映射为第一个。** <br>**《未公开》** | （对比文件未提及“固定DL子帧”以及其在打包次序中的优先映射规则。） | 此特征是对特征K中打包次序的进一步具体限定。对比文件未涉及相关内容。 |
| **M. 为能够支持动态UL‑DL子帧配置的UE和不能够支持动态UL‑DL子帧配置的UE配置分开的PUCCH区域。** <br>**《未公开》** | （对比文件未提及为不同类型的UE配置“分开的PUCCH区域”。） | 对比文件提到了旧式UE（legacy UE）和支持动态重配的UE（如Release 12 UE）共存（见[0038]），并提到eNB需调度旧式UE以避免冲突（见[0042]），但并未公开通过配置独立的PUCCH资源区域来解决冲突的技术手段。 |
| **N. 包括确定针对能够支持动态UL‑DL子帧配置的UE的所述PUCCH区域与针对不能够支持动态UL‑DL子帧配置的UE的所述PUCCH区域之间是否存在潜在冲突。** <br>**《未公开》** | （对比文件未提及UE侧需要执行“确定PUCCH区域潜在冲突”的操作。） | 此特征描述了一种冲突检测机制。对比文件仅从网络侧（eNB）角度提及避免冲突（见[0042]），未教导UE主动进行冲突检测。 |
| **O. 若没有检测到潜在冲突，则使用针对不能够支持动态UL‑DL子帧配置的UE的所述PUCCH区域。** <br>**《未公开》** | （对比文件未提及此判断和选择操作。） | 此特征是特征N检测后的具体行为之一。由于特征N未被公开，此特征也未被公开。 |
| **P. 若没有检测到潜在冲突，则为第一偏移值；以及若检测到潜在冲突，则为第二偏移值。** <br>**《未公开》** | （对比文件未提及基于冲突检测选择不同的“偏移值”。） | 此特征描述了一种基于冲突检测结果动态选择资源偏移值的机制。对比文件未涉及此机制。 |
| **Q. 指示动态上行链路‑下行链路UL‑DL子帧配置的所述信令包括动态信令。** <br>**《直接公开》** | [0018] “…至少一个服务小区被配置有允许动态UL/DL重新配置的附加重新配置信息…” <br>[0037] “已知物理（PHY）层信令可被扩展以实现动态DL到UL转换…” <br>[0046] “…系统和方法…可利用物理层信令来动态改变可转换或灵活子帧中的方向。” | 对比文件[0018]明确指出配置信息中包含“附加重新配置信息”，且该信息“允许动态UL/DL重新配置”。[0037]和[0046]进一步明确这种重配置可以通过“物理层（PHY）信令”实现，物理层信令是典型的动态信令（相对于高层的半静态信令）。这直接公开了指示动态UL-DL子帧配置的信令包括动态信令。其在对比文件中的作用是实现快速、灵活的子帧方向切换，与目标专利中动态信令的作用相同。 |
| **R. 所述动态信令经由以下至少一者来传达：用于发射功率控制TPC命令的下行链路控制信息DCI格式中的一个或多个位，或者一个或多个确收资源偏移ARO位。** <br>**《未公开》** | （对比文件未提及利用DCI中的TPC命令位或ARO位来传达动态UL-DL子帧配置信令。） | 目标专利此特征限定了动态信令的具体承载方式。对比文件虽然提到使用“物理层信令”（如[0037]），但未具体揭示其如何映射到DCI格式中的特定字段（如TPC或ARO位）。这属于未被公开的具体实现细节。 |
| **S. 检测丢失的动态UL‑DL子帧配置；以及响应于所述检测，基于系统信息块SIB中信令通知的UL‑DL子帧配置来确定HARQ资源分配。** <br>**《隐含公开》** | [0067] “第一UL/DL配置可以是动态UL/DL重新配置小区的默认UL/DL配置。第一UL/DL配置可以以与Release-8、9、10和11中相同的方式配置。例如，第一UL/DL配置可以用系统信息块-1（SIB1）信令通知。” <br>[0073] “对于不支持动态UL/DL重新配置的遗留UE…动态UL/DL重新配置小区可被视为具有第一UL/DL配置的常规TDD小区。” | 1. **逻辑推理**：目标专利特征S描述了一种回退机制：当动态信令丢失时，回退到SIB中配置的（静态）UL-DL配置来确定资源分配。对比文件[0067]明确教导，对于任何UE（包括支持动态重配的UE），都存在一个通过SIB1信令通知的“第一（或默认）UL/DL配置”。[0073]进一步指出，对于不支持动态重配的UE（可视为一种“回退”状态），就将小区视为仅具有该第一配置的常规小区。本领域技术人员可以合理推断，对于支持动态重配的UE，若其无法检测或解码动态重配置信令（即“丢失的动态配置”），一个自然且保守的回退操作就是忽略动态部分，仅依据已知的、可靠的SIB配置（即第一配置）来进行操作，包括确定相关的HARQ行为（虽然对比文件主要讨论定时，但资源分配是相关行为）。这种回退设计是通信系统鲁棒性设计的常见手段。<br>2. **作用一致性**：该特征在目标专利中的作用是提供可靠性保障，防止因动态信令失效导致通信中断。对比文件隐含的“依据第一/SIB配置操作”的理念，同样起到了为不支持动态功能的UE或动态功能失效场景提供基本通信保障的作用，两者解决的问题和实现的效果一致。因此，该特征被对比文件隐含公开。 |
**结论代码**：
根据上述分析，对比文件直接公开了技术特征A、B、Q，隐含公开了技术特征C、E、S。
<<<A>>><<<B>>><<<Q>>><<<c>>><<<e>>><<<s>>>