**对比文件名称**：发明申请_US20150358138A1 Physical Resource Allocation for UL Control Channels in Adaptive TDD Systems
**目标专利名称**：PUCCH资源映射和HARQ‑ACK反馈
**本次调用模型名称**：专利创造性评估模型
**特征比对表格**
| 技术特征描述及公开性判断结果 | 对比文件原文引用 | 公开性论述 |
| **A：一种用于由用户装备UE进行无线通信的方法**<br>**判断结果：隐含公开** | 全文多处提及eIMTA UE在自适应TDD系统中进行操作，例如：[0024] “In this invention, ‘eIMTA UE’ means the UE with the ability to support adaptive TDD systems, i.e. eIMTA feature, and PUCCH and PRACH resource allocation of eIMTA UE is just discussed.”；[0025] “So, semi-static configuration shall be used as reference configuration followed by eIMTA UE to perform HARQ operation...”；以及从[0046]开始详细描述eIMTA UE执行PUCCH资源分配的多种解决方案。 | 对比文件通篇围绕“eIMTA UE”（即支持自适应TDD系统的UE）在自适应TDD系统中如何操作展开，具体描述了eIMTA UE接收配置、确定PUCCH资源以进行HARQ-ACK反馈等一系列无线通信方法步骤。虽然未使用与目标专利完全相同的措辞来定义方法，但其整体技术方案明确针对eIMTA UE的无线通信操作。本领域技术人员可以直接且毫无疑义地确定，对比文件公开了一种由用户装备（UE）执行的无线通信方法。 |
| **B：接收指示动态上行链路‑下行链路UL‑DL子帧配置的信令**<br>**判断结果：直接公开** | [0027] “Actual configuration shall be explicitly signaled via dedicated signaling, or implicitly derived via UL/DL assignment in all flexible subframes.” | 对比文件明确公开了“实际配置（actual configuration）”可以通过专用信令（dedicated signaling）明确指示，或者通过在所有灵活子帧中的UL/DL指配隐式推导获得。这里的“实际配置”即对应于目标专利中“动态UL-DL子帧配置”，其指示方式（显式信令）也与目标专利说明书[0170]段“动态L1信令”等描述相符。因此，该技术特征被对比文件直接公开。 |
| **C：基于所述动态UL‑DL子帧配置来确定混合自动重复请求HARQ确收/否定确收ACK/NACK定时**<br>**判断结果：未公开** | [0025] “So, semi-static configuration shall be used as reference configuration followed by eIMTA UE to perform HARQ operation, i.e. UL-reference configuration used for UL HARQ and DL-reference configuration used for DL HARQ.” | 对比文件明确教导eIMTA UE应遵循**半静态配置**（semi-static configuration）作为**参考配置**（reference configuration）来执行HARQ操作（包括DL HARQ）。目标专利说明书[0166]段明确指出其发明点在于“混合”设计，即HARQ定时基于**参考配置**，而资源分配基于**动态配置**。本技术特征要求基于**动态UL-DL子帧配置**确定HARQ ACK/NACK定时，这与对比文件公开的基于**参考配置**确定HARQ定时的方案在作用和原理上存在根本区别。对比文件未公开此技术特征。 |
| **D：基于所述动态UL‑DL子帧配置来确定针对物理上行链路控制信道PUCCH的HARQ资源分配**<br>**判断结果：直接公开** | [0071] “If the actual configuration is successfully obtained, PUCCH resource shall be implicitly determined by CCE index and a derived DL association set. The derived DL association set is based on the actual configuration...”<br>[0065]-[0069] 解决方案3和4中，部分PUCCH资源分配取决于与实际配置相关的DL关联索引。 | 对比文件在解决方案5中明确公开，如果成功获取实际配置（即动态UL-DL子帧配置），则PUCCH资源应基于该实际配置推导出的DL关联集来确定。在解决方案3和4中，也明确将是否采用显式资源分配与实际配置（或DL参考配置，其与实际配置相关）下的DL关联索引顺序或包含关系挂钩。这直接公开了基于动态UL-DL子帧配置（即实际配置）来确定PUCCH资源分配。 |
| **E：以及基于所确定的HARQ资源分配和HARQ ACK/NACK定时来在所述PUCCH上传送HARQ ACK/NACK**<br>**判断结果：隐含公开** | [0005] “If legacy UE and eIMTA (enhancement on Interference Mitigation and Traffic Adaption) UE respectively follow System configuration and DL-reference configuration to feedback DL HARQ-ACK and corresponding PUCCH resources are implicitly determined by CCE index...”<br>[0046] “Section 1: PUCCH Resource Allocation of eIMTA UE for PUCCH Format 1/1a/1b/1b with CS” | 对比文件全文的核心目的就是解决eIMTA UE的PUCCH资源分配问题，以便其能够反馈DL HARQ-ACK。确定PUCCH资源分配（特征D已公开）和HARQ定时（基于参考配置，特征C的替代方案）的最终目的，就是为了在PUCCH上发送HARQ ACK/NACK。本领域技术人员阅读对比文件后，能够直接且毫无疑义地推导出，在确定了资源和定时后，UE必然在PUCCH上传送HARQ ACK/NACK。这是实现HARQ反馈功能的必然步骤和结果。 |
| **F：基于所述动态UL‑DL子帧配置来确定HARQ资源分配包括基于所述动态UL‑DL子帧配置来确定HARQ‑ACK码本大小。**<br>**判断结果：未公开** | 对比文件未提及“HARQ-ACK码本大小（codebook size）”这一概念，也未描述基于动态UL-DL子帧配置来确定码本大小。其讨论的资源分配主要指具体的PUCCH物理资源索引（如n_PUCCH）。 | 目标专利说明书[0167]段明确将“基于动态UL-DL子帧配置确定HARQ-ACK码本大小”作为其混合设计的一个具体方面。对比文件通篇未涉及“码本大小”的确定问题，其关注点在于避免PUCCH物理资源冲突，而非调整ACK/NACK有效载荷的比特数。因此，该技术特征未被对比文件公开。 |
| **G：所述码本大小或ACK/NACK位的数目中的至少一者基于所述动态UL‑DL子帧配置的DL关联集的大小来确定。**<br>**判断结果：未公开** | （同特征F）对比文件未涉及“码本大小”或“ACK/NACK位的数目”的确定。 | 由于对比文件未公开基于动态配置确定码本大小（特征F），自然也未公开基于动态配置的DL关联集大小来确定码本大小或ACK/NACK位数。该技术特征未被公开。 |
| **H：基于所述动态UL‑DL子帧配置来确定HARQ资源分配包括基于所述动态UL‑DL子帧配置来确定物理上行链路控制信道PUCCH资源分配。**<br>**判断结果：直接公开** | （同特征D）[0071] “If the actual configuration is successfully obtained, PUCCH resource shall be implicitly determined by CCE index and a derived DL association set. The derived DL association set is based on the actual configuration...” | 此特征为特征D的进一步限定和具体化。对比文件解决方案5等已直接公开了基于实际配置（动态配置）来确定PUCCH资源分配。因此，该技术特征被直接公开。 |
| **I：所述物理上行链路控制信道PUCCH资源分配基于所述动态UL‑DL子帧配置的DL关联集的大小来确定。**<br>**判断结果：隐含公开** | [0049] “If one associated DL subframe has the same order m in the DL association set K of different UL-DL configurations, the PUCCH resource collision will not happen... This means re-ordering the DL association index km can avoid the PUCCH resource collision.” <br>公式(3)(4)及上下文表明，PUCCH资源n_PUCCH的计算依赖于M（DL关联集大小）和m（顺序）。 | 对比文件详细描述了通过修改DL关联集（包括其大小M和元素顺序m）来避免PUCCH资源冲突。在PUCCH资源隐式确定的方案中（如解决方案1、5），资源计算公式明确包含M（关联集大小）。当该DL关联集是基于实际配置（动态配置）推导或修改而来时（如[0071]），则意味着PUCCH资源分配是基于该动态配置的DL关联集大小来确定的。本领域技术人员可以合理推断出此关系。 |
| **J：当确定所述DL关联集的所述大小时，集束集合中未被配置为所述动态UL‑DL配置中的DL的灵活子帧不被计及。**<br>**判断结果：直接公开** | [0071] “The derived DL association set is based on the actual configuration and is a subset of DL association set of DL-reference configuration. If a DL association index is associated with a DL subframe under the actual configuration, the DL association index shall be included in the derived DL association set. Otherwise, the DL association index is not included.” | 对比文件明确公开：基于实际配置（动态配置）推导出的DL关联集，是DL参考配置的DL关联集的子集。只有当DL关联索引在实际配置下关联于一个DL子帧时，它才被包含在推导出的集合中。这直接对应于：在确定（推导出的）DL关联集的大小时，那些在实际配置（动态配置）中未被配置为DL子帧的（灵活子帧）所对应的关联索引不被计入。 |
| **K：包括通过移除UL子帧来确定所述集束集合中的剩余DL子帧的打包次序。**<br>**判断结果：直接公开** | [0049] “For example, as DL association set of configuration 0 in UL subframe #2 is K:{6}, corresponding DL association set K: {13,12,9,8,7,5,4,11,6} of configuration 5 shall be re-ordered as K: {6,13,12,9,8,7,5,4,11}...” | 对比文件在解决方案1中，为了避免资源冲突，明确提出了对DL参考配置的DL关联集进行重新排序（re-ordering）。例如，将配置5的关联集{13,12,9,8,7,5,4,11,6}重新排序为{6,13,12,9,8,7,5,4,11}。这个过程实质上就是调整“集束集合中的剩余DL子帧的打包次序”。虽然其直接目的是避免冲突，但技术手段本身就是改变打包次序。 |
| **L：其中，固定DL子帧在所述剩余DL子帧的打包次序中被映射为第一个。**<br>**判断结果：未公开** | 对比文件在重新排序的例子中（如[0049]），将k=6（对应特殊子帧/固定DL子帧？）移到前面，但并未概括出“固定DL子帧...被映射为第一个”的规则。其重新排序的规则是基于避免与系统配置冲突，而非基于子帧的“固定”属性。 | 目标专利说明书[0170]段提及“固定DL子帧始终被映射为第一个”作为一种可能的重新排序方式。对比文件虽然给出了一个将特定索引（k=6）前移的实例，但并未揭示或教导将“固定DL子帧”作为一类，并统一将其映射在打包次序首位的技术思想。该特征未被公开。 |
| **M：为能够支持动态UL‑DL子帧配置的UE和不能够支持动态UL‑DL子帧配置的UE配置分开的PUCCH区域。**<br>**判断结果：隐含公开** | [0005] “...PUCCH resource collision may happen, i.e. multiple PUCCHs are transmitted in single resource. The problem of PUCCH resource collision will cause PUCCH performance degeneration and needs to be resolved.”<br>[0062] “To resolve the problem of the PUCCH resource collision between eIMTA UE and legacy UE, another solution is to explicitly configure the PUCCH resource for eITMA UE via higher layer signaling and PHY signaling.” | 对比文件明确提出了eIMTA UE和传统（legacy）UE之间可能存在PUCCH资源冲突的问题，并致力于解决它。解决方案2（显式分配PUCCH资源）的核心思想就是由eNB为eIMTA UE显式配置PUCCH资源，这实质上就是为eIMTA UE配置了与依赖隐式资源的传统UE“分开的PUCCH区域”。本领域技术人员为了解决冲突问题，能够从对比文件的教导中合理推断出配置分开的PUCCH区域是一种可行的解决方案。 |
| **N：包括确定针对能够支持动态UL‑DL子帧配置的UE的所述PUCCH区域与针对不能够支持动态UL‑DL子帧配置的UE的所述PUCCH区域之间是否存在潜在冲突。**<br>**判断结果：直接公开** | [0005] “If legacy UE and eIMTA ... UE respectively follow System configuration and DL-reference configuration ... PUCCH resource collision may happen...”<br>图3及对应描述具体展示了一种冲突场景。 | 对比文件开篇就指出了eIMTA UE（支持动态配置）和传统UE（不支持动态配置）因遵循不同配置而可能导致PUCCH资源冲突。图3和[0036]段更是具体描述和图示了这种冲突是如何发生的。这直接公开了“确定...是否存在潜在冲突”这一技术特征，即认识到两类UE的PUCCH资源可能冲突这一问题本身。 |
| **O：若没有检测到潜在冲突，则使用针对不能够支持动态UL‑DL子帧配置的UE的所述PUCCH区域。**<br>**判断结果：未公开** | 对比文件未描述根据是否检测到冲突来动态选择使用传统UE的PUCCH区域（即默认的N_PUCCH^(1)）的机制。其解决方案（如方案1修改关联集、方案2显式分配）是预先设计或配置好的，不涉及这种条件判断和回退使用。 | 目标专利说明书[0171]段描述了在未检测到冲突时，eIMTA UE可以使用传统UE的默认N_PUCCH^(1)作为一种优化或回退。对比文件并未公开这种基于冲突检测结果的动态资源选择机制。 |
| **P：若没有检测到潜在冲突，则为第一偏移值；以及若检测到潜在冲突，则为第二偏移值。**<br>**判断结果：未公开** | 对比文件未提及根据冲突检测结果选择不同“偏移值”（offset value）的概念。其解决方案中的偏移（如HARQ-ACK resource offset）是用于从多个显式配置资源中选择一个，或作为ARO动态调整资源，并非用于在“第一偏移”和“第二偏移”之间进行条件选择。 | 该技术特征涉及一种特定的资源偏移选择逻辑。对比文件没有公开任何与“检测潜在冲突”结果绑定的、在两个预定偏移值之间进行选择的技术方案。 |
| **Q：指示动态上行链路‑下行链路UL‑DL子帧配置的所述信令包括动态信令。**<br>**判断结果：直接公开** | [0027] “Actual configuration shall be explicitly signaled via dedicated signaling...”<br>[0071] “Actual configuration shall be explicitly signaled or implicitly derived.” | 对比文件明确公开实际配置（动态配置）可以通过专用信令（dedicated signaling）明确指示。这种专用信令通常是动态的（例如L1信令），以区别于半静态的系统信息块（SIB）信令。这直接对应于目标专利中“动态信令”的概念。 |
| **R：所述动态信令经由以下至少一者来传达：用于发射功率控制TPC命令的下行链路控制信息DCI格式中的一个或多个位，或者一个或多个确收资源偏移ARO位。**<br>**判断结果：直接公开** | [0063] 表10及对应描述：“...the value of ‘TPC command for PUCCH’ in corresponding PDCCH assignment or the value of ‘HARQ-ACK resource offset’ in corresponding EPDCCH assignment...” | 对比文件在解决方案2中明确公开，可以通过PDCCH指配中的“TPC command for PUCCH”位或EPDCCH指配中的“HARQ-ACK resource offset”位来动态指示PUCCH资源值。这直接公开了动态信令经由TPC命令位或ARO位来传达的技术特征。 |
| **S：检测丢失的动态UL‑DL子帧配置；以及响应于所述检测，基于系统信息块SIB中信令通知的UL‑DL子帧配置来确定HARQ资源分配。**<br>**判断结果：隐含公开** | [0071] “If the actual configuration is not successfully obtained, e.g. CRC check is not passed or there is no any DL or UL assignment in some flexible subframe, PUCCH shall be dropped.”<br>[0027] “System configuration shall be signaled in SIB 1.” | 对比文件在解决方案5中提到，如果无法成功获取实际配置（即动态配置），则丢弃（drop）PUCCH。同时，对比文件指出系统配置（System configuration）在SIB1中通知。本领域技术人员可以合理推断，作为一种可行的回退（fallback）机制，在无法获取动态配置时，UE可以转而使用始终可用的、在SIB1中通知的系统配置来确定HARQ资源分配（尽管对比文件给出的极端方案是直接丢弃），以确保通信的鲁棒性。这是一种本领域技术人员基于对比文件公开内容和公知常识能够得出的合理且直接的扩展方案。 |
<<<B>>><<<D>>><<<H>>><<<J>>><<<K>>><<<N>>><<<Q>>><<<R>>>
<<<A>>><<<E>>><<<I>>><<<M>>><<<S>>>