好的，作为一名资深专利代理师，我将对对比文件WO2016126330A1与目标专利CN109792322B的权利要求技术特征进行深入、严谨的比对分析。
**对比文件名称：** 2016-08-11_WO2016126330A_发明申请_WO2016126330A1 CODE BLOCK CLUSTER LEVEL HARQ
**目标专利名称：** 1040通信的方法、计算机可读介质和用于通信的装置CN109792322B
**本次调用的模型名称：** DeepSeek
### 特征比对表格
| 技术特征描述以及公开性判断结果 | 对比文件原文引用 | 公开性论述 |
| **技术特征A：** 确定被分配给至少一个传输块的确认比特的数目<br><br>**《未公开》** | 对比文件主要公开了基于代码块簇(CBC)级别的HARQ反馈，即针对每个CBC发送ACK/NACK。未明确公开确定被分配给传输块(TB)的ACK/NACK比特的总数目的步骤。虽然隐含了每个CBC对应一个ACK/NACK比特，但并未涉及计算或确定一个TB所有反馈比特总数的过程。 | 对比文件的核心是使用CBC作为反馈单元，其反馈开销是预定义的（每个CBC一个比特），而非由系统或UE动态“确定”分配给整个TB的比特数目。目标专利的特征A是一个主动的、自适应的确定过程，用于动态调整反馈粒度，这在对比文件中没有明确或隐含公开。 |
| **技术特征B：** 所述至少一个传输块被包括在反馈实例中<br><br>**《隐含公开》** | [0042] “...transport blocks may be configured with subunits known as code block clusters (CBCs)...”<br>整个说明书描述了在一个或多个HARQ过程上的数据传输和反馈。例如，图4的过程流400描述了在HARQ过程中传输一个包含多个CBC的TB。 | 对比文件虽然没有明确使用“反馈实例”这个术语，但其描述的HARQ操作必然发生在特定的时间/频率资源上，即一个反馈实例。一个反馈实例中通常会包含一个或多个HARQ过程，而每个HARQ过程包含传输块。因此，本领域技术人员可以直接、毫无疑义地确定，对比文件中讨论的、包含一个或多个CBC的传输块是包含在某个HARQ过程（feedback instance）中的。这属于隐含公开。 |
| **技术特征C：** 所述至少一个传输块包括多个代码块<br><br>**《直接公开》** | [0044] “A transport block may be made up of a number of sub-segments called code blocks.” <br>[0046] “...code blocks may be grouped together to form code block clusters (CBCs); for instance, a CBC may be an aggregation of one or more code blocks. Thus, a transport block may be made up of a number of CBCs, each of which may have the same or different number of code blocks.” | 对比文件明确公开了“传输块由多个称为代码块的子段组成”，并且代码块可以聚合成代码块簇（CBC）。因此，传输块包括多个代码块这一特征被直接公开。 |
| **技术特征D：** 基于被分配给所述至少一个传输块的所述确认比特的数目以及所述多个代码块的数目<br><br>**《未公开》** | 对比文件中没有公开任何基于“确认比特数目”和“代码块数目”进行后续操作的内容。对比文件的CBC分组是基于冗余版本(RV)，而非根据确认比特数目对代码块进行分组。 | 目标专利中，确认比特数目和代码块数目是后续代码块分组算法（特征E）的两个核心输入参数。对比文件虽然也有代码块分组（形成CBC），但其分组逻辑是基于重传次数（RV版本），与动态分配的确认比特数目无关。因此，对比文件完全没有公开使用这两个参数作为分组依据。 |
| **技术特征E：** 将所述多个代码块中的每个代码块分配给相应的代码块组<br><br>**《隐含公开》** | [0046] “...code blocks may be grouped together to form code block clusters (CBCs); for instance, a CBC may be an aggregation of one or more code blocks.”<br>[0075] “An RV segment may include one or several CBCs 325, all of which may have the same redundancy version.” | 对比文件明确公开了代码块组的概念，即代码块簇（CBC）和冗余版本段（RV segment）。每个CBC是一个代码块组，每个RV segment也是一个由多个CBC组成的更高级的组。因此，将代码块分配给代码块组（CBC）这一基本操作被直接公开。然而，目标专利的“分组”是基于特征A、D输入的算法进行的。对比文件的分组是基于RV，这与目标专利的分配逻辑不同。但就“将代码块分配到组”这一行为本身而言，对比文件是公开的。 |
| **技术特征F：** 其中每个代码块组与所述确认比特的数目中的一个确认比特数目相关联<br><br>**《隐含公开》** | [0045] “...a UE may send an acknowledgment (ACK) or negative acknowledgment (NACK) indicating the reception status of the data.”<br>[0046] “...the CBCs may be the minimum unit of PDSCH that is ACKed.”<br>[0091] “At step 435, UE 115-b may transmit (and base station 105-b may receive) ACK/NACKs for the first and second CBCs, and any additional CBCs.” | 对比文件公开了每个代码块簇（CBC）是ACK/NACK的最小单位，并针对每个CBC发送一个ACK/NACK反馈。这隐含了每个CBC（代码块组）与一个确认比特（ACK/NACK）相关联。虽然目标专利中的确认比特数目是动态确定的，而对比文件中一个CBC对应一个反馈比特是固定的，但“一个组对应一个比特”的核心关联关系是相同的。因此，本特征被隐含公开。 |
| **技术特征G：** 基于针对所述相应代码块组确定的确认结果，引起与每个相应代码块组相关联的所述确认比特的传输。<br><br>**《直接公开》** | [0073] “...UE 115-a may send CBC level ACK/NACKs 220, and base station 105-a may transmit redundancy versions of one or more of the CBCs based on the ACK/NACKs 220.”<br>[0091] “At step 435, UE 115-b may transmit (and base station 105-b may receive) ACK/NACKs for the first and second CBCs, and any additional CBCs.” | 对比文件明确公开了：UE对接收到的CBC进行解码，确定其是否正确（确认结果），然后基于该结果，为每个CBC（代码块组）传输ACK/NACK（确认比特）。其作用与目标专利完全相同，都是实现基于组的精细反馈，以减少重传开销。因此，本特征被直接公开。 |
| **技术特征H：** 其中确定被分配给传输块的所述确认比特的数目包括：确定被分配给反馈实例的所述确认比特的数目，所述反馈实例包括至少一个过程，所述至少一个过程包括所述至少一个传输块<br><br>**《未公开》** | 对比文件没有公开任何关于确定反馈实例的确认比特数目的内容。对比文件中反馈比特的数目是隐式确定的（每个CBC一个比特），没有在反馈实例层面进行资源分配或数目确定。 | 目标专利引入了一个层次化的ACK/NACK资源分配机制：先确定反馈实例的总比特数，再分配给过程，最后分配给传输块。对比文件完全没有涉及这种资源预算和分配的概念。它假设反馈资源是固定的或与CBC数量成正比，无需进行此类“确定”步骤。 |
| **技术特征I：** 基于传输块大小，将所述确认比特分配给所述至少一个过程。<br><br>**《未公开》** | 对比文件全文未出现基于传输块大小（TBS）分配确认比特的描述。对比文件中，一个过程（HARQ process）的反馈比特数由其包含的CBC数量决定，而非基于TBS。 | 目标专利的关键创新点在于根据TBS来自适应地分配ACK/NACK比特数，以优化反馈资源。对比文件的方案是静态的，CBC和ACK/NACK比特是1:1对应。因此，对比文件完全没有公开基于TBS进行比特分配的技术内容。 |
| **技术特征J：** 其中确定被分配给传输块的所述确认比特的数目包括：确定被分配给过程的所述确认比特的数目，所述过程包括所述至少一个传输块<br><br>**《未公开》** | 对比文件没有公开确定分配给一个过程的确认比特数目的步骤。 | 同特征H和I，对比文件没有这种层次化的确认比特数目确定过程。其反馈粒度是直接基于CBC的，没有先确定“过程的比特数”这一中间步骤。 |
| **技术特征K：** 基于传输块大小，将所述确认比特分配给所述至少一个传输块。<br><br>**《未公开》** | 对比文件未公开基于传输块大小（TBS）来分配确认比特。对比文件中，一个TB被分成多个CBC，每个CBC对应一个ACK/NACK，因此一个TB的反馈比特数等于其CBC数，而非基于TBS动态分配。 | 这是目标专利的核心发明点之一，即根据TBS大小来灵活分配不同TB的反馈比特数。例如，TBS大的TB分配更多比特，TBS小的分配更少比特。对比文件没有这种动态分配机制。 |
| **技术特征L：** 其中如果所述反馈实例包括多个过程或者所述至少一个过程包括多个传输块，则基于传输块大小而将所述确认比特分别分配给所述过程或所述传输块包括：确定所述过程之间的、或者所述传输块之间的传输块大小比率<br><br>**《未公开》** | 对比文件未公开任何关于传输块大小比率（TBS ratio）的内容。 | 特征L是特征I和K在特定场景（多过程或多TB）下的具体实现方式，通过计算TBS比率来公平分配比特。这是目标专利实现优化资源分配的关键算法。对比文件中完全没有这种跨过程或跨TB的基于比率的反馈资源分配机制。 |
| **技术特征M：** 基于最接近所述传输块比率的确认比特比率来分配所述确认比特。<br><br>**《未公开》** | 对比文件未公开基于比率进行比特分配的方法。 | 特征M是特征L的结论，即根据计算出的TBS比率，选择最接近的整数比特比率进行分配。这是一个具体的数学算法，在对比文件中完全没有记载。 |
| **技术特征N：** 包括：基于传输参数来确定所述传输块大小。<br><br>**《隐含公开》** | [0057] “The number of bits transferred in a transport block may be based on the modulation and coding scheme (MCS), as well as the number of resource blocks assigned to the UE...” | 对比文件明确指出，传输块的大小（The number of bits transferred in a transport block）是基于MCS和分配的RB数（即传输参数）来确定的。虽然对比文件没有明确说“确定TBS是为了后续分配确认比特”，但基于传输参数确定TBS本身是本领域的公知常识，且对比文件对此有明确教导。目标专利将此作为后续比特分配的依据，对比文件虽未建立此联系，但“基于传输参数确定TBS”这一行为被公开。 |
| **技术特征O：** 其中所述传输参数包括：调制编码方案和物理资源块号中的至少一个。<br><br>**《直接公开》** | [0057] “The number of bits transferred in a transport block may be based on the modulation and coding scheme (MCS), as well as the number of resource blocks assigned to the UE...” | 对比文件直接公开了用于确定传输块大小的传输参数包括调制编码方案（MCS）和物理资源块（resource blocks）数目。这与目标专利的特征O完全一致。 |
| **技术特征P：** 包括：从基站接收第一信息，所述第一信息包括对被分配给所述反馈实例的确认比特的数目的指示。<br><br>**《未公开》** | 对比文件未公开基站通过信令指示反馈实例的确认比特总数。对比文件中的ACK/NACK比特数是基于CBC数量隐式确定的。 | 目标专利中，基站可以通过下行信令（如PDCCH）动态指示UE本次反馈实例的总反馈比特数。这是实现动态反馈资源分配的关键信令。对比文件没有这种动态指示，其反馈粒度是固定的（CBC级），不需要额外的比特数目指示。 |
| **技术特征Q：** 包括：从所述基站接收切换信息，所述切换信息包括从第一反馈方案切换到第二反馈方案的指示。<br><br>**《未公开》** | 对比文件未公开任何关于反馈方案切换的信令或机制。 | 目标专利支持在不同反馈粒度（如TB级、CBC组级）之间动态切换，以适应不同场景。对比文件专注于CBC级别的HARQ，没有探讨或公开切换到其他反馈方案（如传统的TB级反馈）的技术方案。 |
| **技术特征R：** 其中每个组中的所述代码块的数目是相等的，或者每个组中的所述代码块的数目相差1。<br><br>**《未公开》** | 对比文件没有公开对代码块组的大小进行限制（相等或差1）。对比文件中，CBC可以是“an aggregation of one or more code blocks”，其大小没有特定规则。 | 目标专利特征R是对代码块分组大小的一个特定约束，目的是为了平衡各组的负载。这是目标专利实现其分组算法的结果。对比文件中的CBC分组是基于RV的，其大小没有这种数学上的均衡约束。 |
| **技术特征S：** 其中m‑r个代码块组包括L数目个代码块，并且r个代码块组具有L+1个代码块，其中m是所述确认比特的数目，L是对所述多个代码块的所述数目与所述确认比特的数目的商的向下取整，并且r是余数。<br><br>**《未公开》** | 对比文件没有公开任何类似的数学公式或分组算法。 | 特征S是特征R的具体实现公式，描述了如何将N个代码块均匀地分配到m个组中。这是一个非常具体且精确的算法。对比文件中完全没有公开或暗示这种将代码块尽可能均匀分配到与确认比特数目相等的组中的方法。 |
| **技术特征T：** 其中如果被传输的所述确认比特是否定确认<br><br>**《直接公开》** | [0046] “...if the data is not correctly received by the UE (e.g., a cyclic redundancy check (CRC) fails) the UE may send a NACK to the base station requesting a retransmission of the data...”<br>[0073] “...UE 115-a may send CBC level ACK/NACKs 220, and base station 105-a may transmit redundancy versions of one or more of the CBCs based on the ACK/NACKs 220.” | 对比文件明确公开了：如果UE发送NACK（否定确认），表示该CBC未被正确接收。这是HARQ的基本原理，其作用完全相同。 |
| **技术特征U：** 接收所述代码块组的所述代码块的重传。<br><br>**《直接公开》** | [0077] “First RV segment 310 may include the first retransmissions (e.g., RV1) of CBCs which were incorrectly received during a previous transport block.”<br>[0073] “...base station 105-a may transmit redundancy versions of one or more of the CBCs based on the ACK/NACKs 220.” | 对比文件明确公开了：当基站接收到NACK后，会重传对应的CBC（代码块组）的冗余版本。这完全对应于目标专利中“接收代码块组的代码块的重传”。其作用相同，都是基于精细的反馈进行选择性重传。 |
### 公开性代码汇总
根据以上分析，对比文件对各技术特征的公开情况如下：
* **直接公开：** 特征C, G, O, T, U
* **隐含公开：** 特征B, E, F, N
* **未公开：** 特征A, D, H, I, J, K, L, M, P, Q, R, S
因此，在回答的结尾插入对应代码。
<<<C>>><<<G>>><<<O>>><<<T>>><<<U>>><<<b>>><<<e>>><<<f>>><<<n>>>