好的，作为一名资深专利代理师，我将严格遵循您的评估要求，对提供的对比文件与目标专利权利要求进行技术特征比对和公开性判断。
**本次调用的模型名称：** OpenAI GPT-4
**对比文件名称：** 2013-02-07_US2013034028A_发明申请_US20130034028A1 ALLOCATING PHYSICAL HYBRID ARQ INDICATOR CHANNEL (PHICH) RESOURCES
**目标专利名称：** 具有动态TDD DL/UL子帧配置的载波聚合 (CN105940631B)
---
## 特征比对表格
| 技术特征描述及公开性判断结果 | 对比文件原文引用 | 公开性论述 |
| **技术特征A：** 接收包括至少第一分量载波(CC)和第二CC的配置，所述第一CC或所述第二CC中的至少一个CC被启用用于针对业务适应的演进型干扰管理(eIMTA) <br>**判断结果：** 未公开 | 第[0056]段：“Operations 600 begin, at 602 by determining that a first Time division duplex (TDD) Component Carrier (CC) with a first uplink (UL)/downlink (DL) subframe configuration is cross carrier scheduled by a second CC with a second UL/DL subframe configuration.” <br>第[0057]段：“According to certain aspects, a UE may determine that the UL Hybrid Automatic Repeat Request (HARQ) timing of uplink transmissions on the first CC is based on the UL HARQ timing of uplink transmissions specified for the second CC.” | **直接公开判断：** 对比文件公开了接收包括第一TDD CC和第二CC（可以是FDD或TDD）的配置，并且第一CC被第二CC跨载波调度。然而，对比文件完全没有提及“针对业务适应的演进型干扰管理(eIMTA)”。eIMTA是LTE-Advanced中允许TDD UL/DL子帧配置根据业务需求动态变化的特性。对比文件（基于其申请日2011年8月）处理的TDD配置是静态或半静态的（如SIB1指示），不具备动态适应业务的能力。因此，本领域技术人员无法从对比文件毫无疑义地得出至少一个CC“被启用用于eIMTA”的技术方案。<br>**隐含公开判断：** eIMTA是一个特定的、后来引入的动态配置机制。对比文件讨论的TDD配置差异是固定的（如配置0、1、2等），其解决的是不同固定配置的CC间跨载波调度时的PHICH资源问题，而非由eIMTA引起的、随时间变化的动态配置问题。没有依据可以从对比文件的内容推理出eIMTA的概念。因此，该技术特征未被隐含公开。 |
| **技术特征B：** 确定用于所述第一CC和所述第二CC中的至少一个CC的混合自动重传请求(HARQ)时序 <br>**判断结果：** 直接公开 | 第[0056]段：“...determining that a first Time division duplex (TDD) Component Carrier (CC)...is cross carrier scheduled by a second CC...” <br>第[0056]段：“At 604, a Hybrid Automatic Repeat Request (HARQ) timing of uplink transmissions on the first CC is determined.” <br>第[0057]段：“According to certain aspects, a UE may determine that the UL Hybrid Automatic Repeat Request (HARQ) timing of uplink transmissions on the first CC is based on the UL HARQ timing of uplink transmissions specified for the second CC.” | 对比文件明确公开了在跨载波调度场景下，需要“确定”（determine）第一CC上的上行传输的HARQ时序。这是其解决PHICH资源分配问题的核心步骤之一。虽然对比文件主要关注上行HARQ（PUSCH到PHICH）的时序，而目标专利的HARQ时序可能更广泛，但“确定用于至少一个CC的HARQ时序”这一动作已被对比文件直接公开。其作用也是为了确保在特定配置下通信的正常进行。 |
| **技术特征C：** 所确定的HARQ时序是至少部分地基于所接收到的配置以及所述第一CC或所述第二CC中的所述至少一个CC被启用用于eIMTA的 <br>**判断结果：** 未公开 | 第[0057]段：“According to certain aspects, a UE may determine that the UL Hybrid Automatic Repeat Request (HARQ) timing of uplink transmissions on the first CC is based on the UL HARQ timing of uplink transmissions specified for the second CC.” <br>第[0058]段：“According to certain aspects, a UE may determine that the UL Hybrid Automatic Repeat Request (HARQ) timing of uplink transmissions on the first CC is based on the UL HARQ timing of uplink transmissions specified for the first CC.” | **直接公开判断：** 对比文件公开了HARQ时序的确定基于载波的配置（第一CC和第二CC的UL/DL子帧配置）以及它们之间的调度关系（是否跨载波调度）。然而，其“配置”是静态的TDD UL/DL配置（如配置0、1、2），完全不涉及“eIMTA”或“被启用用于eIMTA”的状态。eIMTA带来的动态配置变化是目标专利要解决的核心问题，对比文件未涉及此概念。<br>**隐含公开判断：** 无法从对比文件中对固定配置间时序问题的处理，推理出需要基于一个CC是否启用“动态业务适应(eIMTA)”这一特定属性来确定HARQ时序。这是两个不同的技术问题域。因此，该技术特征未被隐含公开。 |
| **技术特征D：** 所确定的HARQ时序是进一步基于以下各项的：所述第一CC和所述第二CC的交叉载波调度配置、以及使用与所述第一CC对应的第一子帧配置索引和与所述第二CC对应的第二子帧配置索引来对表进行索引 <br>**判断结果：** 隐含公开 | 第[0056]段：“...determining that a first Time division duplex (TDD) Component Carrier (CC) with a first uplink (UL)/downlink (DL) subframe configuration is cross carrier scheduled by a second CC with a second UL/DL subframe configuration.” <br>第[0100]-[0103]段及图10、12、13：描述了TDD CC1（配置2）跨载波调度TDD CC2（配置1）时，因PHICH资源不足（m4=m9=0）而需要修订HARQ时序或分配额外PHICH资源。这隐含了需要根据两个CC的具体子帧配置（索引）来处理时序/资源问题。 | **直接公开判断：** 对比文件明确公开了HARQ时序的确定需要考虑“交叉载波调度配置”（cross carrier scheduled）。对比文件也提到了第一CC和第二CC具有不同的“第一UL/DL子帧配置”和“第二UL/DL子帧配置”。然而，对比文件没有明确公开“使用与第一CC对应的第一子帧配置索引和与第二CC对应的第二子帧配置索引来对表进行索引”这一具体操作。目标专利说明书图4A、4B展示了这种查表方法，但对比文件中解决PHICH资源冲突的方案（如修订时间线、额外分配资源）并未描述为一种通用的“查表”过程。<br>**隐含公开判断：** 本领域技术人员阅读对比文件后，能够理解在载波聚合中，当两个TDD CC具有不同且固定的子帧配置（每个配置对应一个已知索引，如0-6）并进行跨载波调度时，必须根据这两个具体的配置来确定正确的HARQ时序或PHICH资源映射规则，以避免冲突。虽然对比文件未明确给出一个“表”，但根据两个配置索引来确定处理方案（无论是修订时间线还是分配资源）是本领域技术人员能够合理推断出的必然逻辑步骤。因此，该技术特征被对比文件隐含公开。 |
| **技术特征E：** 以及至少部分地基于所确定的HARQ时序，使用所述第一CC和所述第二CC中的所述至少一个CC进行通信 <br>**判断结果：** 直接公开 | 第[0056]段：“At 608, uplink transmissions are performed, based on the HARQ resource availability determination.” <br>第[0059]段：“According to certain aspects, the UE may determine the PHICH resources available and, in response to the determination, determine a HARQ response based on the determined PHICH resource.” | 对比文件公开了基于对PHICH资源可用性的确定（这本身是基于HARQ时序判断的，见操作606）来“执行上行传输”（perform uplink transmissions）。执行上行传输即是“使用CC进行通信”的一种具体形式。因此，“至少部分地基于所确定的HARQ时序进行通信”这一技术特征已被对比文件直接公开。其作用也是为了依据正确的时序执行通信动作，确保HARQ流程的有效性。 |
| **技术特征F：** 其中，确定所述HARQ时序是基于被启用用于eIMTA的所述至少一个CC的动态配置的下行链路/上行链路(DL/UL)子帧配置的 <br>**判断结果：** 未公开 | 无相应内容。对比文件全篇讨论的TDD子帧配置均为固定配置（如配置0、1、2），未提及配置可动态变化。 | **直接公开判断：** 对比文件完全没有提及“动态配置的DL/UL子帧配置”。其所有技术方案均基于预定义的、静态的TDD UL/DL配置。<br>**隐含公开判断：** eIMTA的动态配置是目标专利针对后来标准引入的新特性而提出的解决方案。在对比文件申请时（2011年），动态TDD配置尚未成为标准化的解决方案。因此，本领域技术人员无法从对比文件中推理出基于“动态配置”来确定HARQ时序。该技术特征未被隐含公开。 |
| **技术特征G：** 其中，确定所述HARQ时序是基于被启用用于eIMTA的所述至少一个CC的半静态下行链路/上行链路(DL/UL)子帧配置的 <br>**判断结果：** 隐含公开 | 第[0056]段：“...a first Time division duplex (TDD) Component Carrier (CC) with a first uplink (UL)/downlink (DL) subframe configuration...” <br>第[0057]段：“...based on the UL HARQ timing of uplink transmissions specified for the second CC.” | **直接公开判断：** 对比文件没有使用“半静态”（semi-static）一词来描述其TDD子帧配置。在目标专利语境中，“半静态”通常指通过RRC或SIB消息配置的、变化不频繁的配置。对比文件虽未明确定义其配置的属性，但其描述的配置可被视为一种固定的参考配置。<br>**隐含公开判断：** 本领域技术人员知晓，在LTE/LTE-A中，TDD UL/DL配置通常是通过系统信息（SIB1）广播的，这种配置在一段时间内是固定的，可以被认为是“半静态”的。对比文件中确定HARQ时序所基于的“第一UL/DL子帧配置”和“第二UL/DL子帧配置”，正是这种通过系统信息配置的、作为参考的固定配置。因此，可以合理推断对比文件中的HARQ时序确定是基于（目标专利所定义的）半静态DL/UL子帧配置的。该技术特征被隐含公开。 |
| **技术特征H：** 其中，UL HARQ时序是基于在用于被启用用于eIMTA的所述至少一个CC的广播系统信息块(SIB)消息中指示的子帧配置确定的 <br>**判断结果：** 未公开 | 无相应内容。对比文件未提及通过SIB消息获取或指示子帧配置。 | **直接公开判断：** 对比文件未提及“广播系统信息块(SIB)消息”或通过SIB消息指示子帧配置。<br>**隐含公开判断：** 虽然本领域公知TDD配置可通过SIB1广播，但对比文件的方案描述是独立于具体信令方式的。它直接假设CC具有某个UL/DL配置，但没有披露该配置的来源。因此，不能从对比文件内容中必然推理出“基于SIB消息中指示的子帧配置”这一具体限定。该特征未被隐含公开。 |
| **技术特征I：** 其中，DL HARQ时序是基于由用于被启用用于eIMTA的所述至少一个CC的无线资源控制(RRC)消息指示的子帧配置确定的 <br>**判断结果：** 未公开 | 无相应内容。对比文件未提及通过RRC消息获取或指示子帧配置。 | **直接公开判断：** 对比文件未提及“无线资源控制(RRC)消息”或通过RRC消息指示子帧配置。<br>**隐含公开判断：** 同理，对比文件未披露配置的具体信令来源。无法推理出基于RRC消息指示的配置。该特征未被隐含公开。 |
| **技术特征J：** 其中，所述HARQ时序包括HARQ确认(ACK)时序和HARQ调度时序中的至少一个 <br>**判断结果：** 隐含公开 | 第[0056]段：“...determining a Hybrid Automatic Repeat Request (HARQ) timing of uplink transmissions on the first CC...” <br>图9A, 9B, 10等：展示了修订后的时间线，其中包含了PUSCH传输与对应的PHICH（承载ACK/NACK）之间的时序关系。 | **直接公开判断：** 对比文件明确讨论了“HARQ timing of uplink transmissions”，这主要对应的是PUSCH传输与PHICH反馈（即HARQ ACK/NACK）之间的时序关系。对比文件没有明确提及“HARQ调度时序”（如下行调度授权到PUSCH的时序）。<br>**隐含公开判断：** HARQ时序在通信系统中是一个整体概念，通常包括调度时序（Grant to PUSCH）和确认时序（PUSCH to PHICH）。对比文件虽然重点解决PHICH资源问题，但其修订HARQ时间线（如图9A、9B、10）时，必然涉及对整个HARQ过程时序的考虑，否则无法保证PHICH资源的正确映射。本领域技术人员可以理解，当讨论和确定上行HARQ时序时，其内涵自然涵盖了ACK时序，并且在跨载波调度场景下，调度时序（由哪个子帧的PDCCH调度）也是确定PHICH资源时必须关联的因素。因此，该技术特征被对比文件隐含公开。 |
| **技术特征K：** 其中，所确定的HARQ时序是进一步至少部分地基于下面至少之一的：所述第一CC和所述第二CC是具有时域双工(TDD)还是频域双工(FDD)帧结构类型，所述第一CC和所述第二CC作为主CC或辅CC的指定，物理上行链路控制信道(PUCCH)的数量，或者所述第一CC和所述第二CC是针对载波聚合操作还是针对双连接操作配置的 <br>**判断结果：** 隐含公开 | 第[0056]段：“...cross carrier scheduled by a second CC with a second UL/DL subframe configuration.”（第二CC可以是TDD或FDD） <br>图5：展示了FDD DL CC跨载波调度TDD CC。 <br>图10, 12：展示了TDD CC跨载波调度另一个TDD CC。 <br>全文背景：基于载波聚合（CA）场景。 | **直接公开判断：** 对比文件公开了HARQ时序/资源确定需要考虑载波类型（TDD或FDD），如图5（FDD调度TDD）与图10/12（TDD调度TDD）的处理可能不同。对比文件也明确处于载波聚合（CA）的上下文。然而，对比文件没有明确提及“主CC或辅CC的指定”、“PUCCH的数量”以及“双连接操作”。<br>**隐含公开判断：** 在载波聚合中，通常存在主服务小区（PCell，对应主CC）和辅服务小区（SCell，对应辅CC）的概念。对比文件讨论跨载波调度，即一个CC（调度CC）为另一个CC（被调度CC）调度资源，这隐含了CC之间存在主从或调度与被调度的关系。虽然未明确使用“PCC/SCC”术语，但“调度CC”和“被调度CC”的功能划分是清晰的。关于“PUCCH的数量”和“双连接”，对比文件未涉及，但“载波聚合操作”已被公开。因此，技术特征K中“基于载波是TDD还是FDD”以及“针对载波聚合操作配置”这两点被隐含公开。其他点（主辅CC指定、PUCCH数量、双连接）未被公开，但根据判断标准，只要部分内容被隐含公开，即判断该特征整体被隐含公开。 |
| **技术特征L：** 其中，如果被启用用于eIMTA的所述至少一个CC是所述主CC并且所述PUCCH的数量是一，其中所述一个PUCCH是在所述主CC上的，则用于所述主CC和所述辅CC二者的所述HARQ时序是基于所述主CC的半静态DL/UL子帧配置的 <br>**判断结果：** 未公开 | 无相应内容。对比文件未涉及eIMTA、PUCCH数量与HARQ时序规则之间的条件关系。 | **直接公开判断：** 对比文件完全没有提及eIMTA，也没有描述这种基于“主CC启用eIMTA且PUCCH数量为1”等具体条件来确定HARQ时序的规则。<br>**隐含公开判断：** 该规则是目标专利为应对eIMTA引入的动态性而设计的具体实施方案。对比文件处理的是静态配置下的问题，没有动机也没有基础推导出如此具体且依赖于eIMTA状态和PUCCH配置的条件规则。因此，该技术特征未被隐含公开。 |
| **技术特征M：** 其中，如果被启用用于eIMTA的所述至少一个CC是所述辅CC并且所述主CC是TDD帧结构类型的，则用于所述主CC和所述辅CC二者的所述HARQ时序是基于所述辅CC的半静态DL/UL子帧配置的 <br>**判断结果：** 未公开 | 无相应内容。理由同技术特征L。 | 同技术特征L，该具体条件规则未被对比文件公开或隐含。 |
| **技术特征N：** 其中，如果被启用用于eIMTA的所述至少一个CC是所述辅CC，并且所述主CC是FDD帧结构类型的，则用于所述辅CC的所述HARQ时序是基于所述辅CC的动态DL/UL子帧配置的 <br>**判断结果：** 未公开 | 无相应内容。理由同技术特征L，且动态配置未被公开。 | 同技术特征L，且涉及“动态DL/UL子帧配置”，该概念在对比文件中不存在。因此未被公开。 |
| **技术特征O：** 其中，确定所述HARQ时序包括确定用于上行链路控制信息(UCI)报告的HARQ时序，并且所述HARQ时序指示用于发送所述UCI报告的一个或多个子帧 <br>**判断结果：** 未公开 | 第[0056]段：“...a Hybrid Automatic Repeat Request (HARQ) timing of uplink transmissions on the first CC...” 此处“uplink transmissions”在对比文件上下文中主要指PUSCH传输。 | **直接公开判断：** 对比文件确定的HARQ时序是针对PUSCH传输及其对应的PHICH反馈的时序。UCI报告（如CQI, PMI, RI, SR等）通常通过PUCCH或PUSCH发送，其上报时序（周期性或非周期性）与PUSCH的HARQ时序（尤其是PHICH反馈时序）属于不同的机制。对比文件未提及UCI报告或其发送时序。<br>**隐含公开判断：** 无法从对比文件对PUSCH HARQ-PHICH时序的处理中，推理出“确定用于UCI报告的HARQ时序”这一不同的技术特征。该特征未被隐含公开。 |
| **技术特征P：** 还包括：基于所述UCI报告是否针对被启用用于eIMTA的所述至少一个CC或者所述UCI报告是与固定的还是动态确定的子帧相关联，划分所述UCI的发送的优先级 <br>**判断结果：** 未公开 | 无相应内容。对比文件未涉及UCI报告，更未涉及基于eIMTA状态或子帧属性（固定/动态）进行优先级划分。 | 该特征完全依赖于eIMTA和UCI报告的概念，两者均未在对比文件中出现。因此未被公开。 |
| **技术特征Q：** 其中，确定用于发送所述UCI报告的所述HARQ时序是至少部分地基于被启用用于eIMTA的所述至少一个CC是否是携带物理上行链路控制信道(PUCCH)的CC的 <br>**判断结果：** 未公开 | 无相应内容。理由同技术特征O和P。 | 该特征涉及UCI报告和PUCCH CC与eIMTA的关系，对比文件未涉及这些概念。因此未被公开。 |
| **技术特征R：** 其中，如果被启用用于eIMTA的所述至少一个CC是携带PUCCH的所述CC，则用于在被启用用于eIMTA的所述至少一个CC上发送UCI报告的所述HARQ时序使用动态确定的上行链路子帧 <br>**判断结果：** 未公开 | 无相应内容。理由同技术特征O、P、Q，且涉及“动态确定的上行链路子帧”。 | 该特征集成了eIMTA、UCI、PUCCH和动态子帧等多个未公开概念。因此未被公开。 |
| **技术特征S：** 其中，如果被启用用于eIMTA的所述至少一个CC不是携带PUCCH的所述CC，则用于在携带所述PUCCH的所述CC上发送UCI报告的所述HARQ时序使用固定的上行链路子帧 <br>**判断结果：** 未公开 | 无相应内容。理由同技术特征R。 | 同技术特征R，未被公开。 |
| **技术特征T：** 其中，所述第一CC和所述第二CC是针对载波聚合(CA)操作配置的 <br>**判断结果：** 直接公开 | 全文背景：文件讨论跨载波调度、不同TDD配置的CC等，均属于载波聚合(CA)的技术领域。例如，第[0071]段提及“TDD carrier aggregation (CA)”。 | 对比文件通篇都在载波聚合（CA）的语境下讨论技术问题（跨载波调度、PHICH资源分配）。因此，“CC是针对载波聚合(CA)操作配置的”这一特征被直接公开。 |
| **技术特征U：** 其中，所述第一CC和所述第二CC是针对双向连接操作配置的 <br>**判断结果：** 未公开 | 无相应内容。对比文件只提及载波聚合（CA），未提及“双连接”（Dual Connectivity）操作。 | **直接公开判断：** 对比文件未提及“双连接操作”。<br>**隐含公开判断：** 双连接是比载波聚合更一般的概念，涉及与两个调度节点（可能回程非理想）的连接。对比文件处理的是单个调度节点下的跨载波调度问题，属于典型的CA场景。无法从对比文件推理出双连接配置。该特征未被隐含公开。 |
## 总结与代码输出
根据上述分析：
- **直接公开**的技术特征有：B, E, T。
- **隐含公开**的技术特征有：D, G, J, K。
- 其余技术特征（A, C, F, H, I, L, M, N, O, P, Q, R, S, U）均未被直接公开或隐含公开。
因此，在回答结尾插入的代码应为：<<<B>>><<<E>>><<<T>>><<<d>>><<<g>>><<<j>>><<<k>>>