对比文件的名称：2013-09-04_CN103283173A_发明公开_CN103283173A 在基于TDD的无线通信系统中发射ACK_NACK的方法和设备
目标专利的名称：1040通信的方法、计算机可读介质和用于通信的装置CN109792322B
本次调用的模型名称：本分析由AI模型完成（模型名称：未指定）
### 特征比对表格
| 技术特征描述及公开性判断结果 | 对比文件原文引用 | 公开性论述 |
| **技术特征A：确定被分配给至少一个传输块的确认比特的数目**<br>《隐含公开》 | 对比文件[0170]定义ACK/NACK状态：“ACK：当在PDSCH上接收到的传送块的传输成功时。NACK：当在PDSCH上接收到的传送块的解码失败时。”<br>[0166]：“DL传送块被用于统称为要求ACK/NACK响应的任何数据。” | 对比文件虽未明确“确定”步骤，但每个DL传送块都需要ACK/NACK响应，本领域技术人员可以合理推断出每个传送块被分配了至少一个确认比特（通常为1比特，MIMO时为2比特），因此隐含公开了确定分配给传输块的确认比特数目。 |
| **技术特征B：所述至少一个传输块被包括在反馈实例中**<br>《隐含公开》 | [0167]：“根据UL-DL配置，M个DL子帧与UL子帧n相关联。”<br>[0221]：“四个DL子帧与一个UL子帧相关联。” | 对比文件明确一个UL子帧（反馈实例）与多个DL子帧相关联，这些DL子帧中的传输块都在该UL子帧中反馈，因此每个传输块被包括在反馈实例中。 |
| **技术特征C：所述至少一个传输块包括多个代码块**<br>《直接公开》 | [0197]：“以代码块单位来分段CRC附接的比特b0,b1,...,bB-1，并且以代码块单位来重新附接CRC奇偶比特（步骤210）。” | 对比文件直接公开了传输块在编码时被分割成多个代码块，故该特征被直接公开。 |
| **技术特征D：基于被分配给至少一个传输块的确认比特的数目以及多个代码块的数目**<br>《未公开》 | 无 | 对比文件未公开基于确认比特数目和代码块数目进行任何操作，其ACK/NACK反馈基于整个传输块或绑定组，不涉及代码块分组。 |
| **技术特征E：将多个代码块中的每个代码块分配给相应的代码块组**<br>《未公开》 | 无 | 对比文件未公开代码块分组的概念，反馈粒度不涉及代码块组。 |
| **技术特征F：每个代码块组与确认比特的数目中的一个确认比特数目相关联**<br>《未公开》 | 无 | 对比文件没有代码块组与确认比特关联的教导。 |
| **技术特征G：基于针对相应代码块组确定的确认结果，引起与每个相应代码块组相关联的确认比特的传输**<br>《未公开》 | 无 | 对比文件没有基于代码块组生成确认比特的过程。 |
| **技术特征H：确定被分配给传输块的确认比特的数目包括：确定被分配给反馈实例的确认比特的数目，反馈实例包括至少一个过程，至少一个过程包括至少一个传输块**<br>《隐含公开》 | [0218]：“UE基于UL DAI值来确定ACK/NACK有效载荷大小（步骤S104）。”该有效载荷大小对应反馈实例的总确认比特数目。<br>[0163]提及“HARQ处理编号”，表明存在HARQ过程。 | 对比文件公开了确定反馈实例的ACK/NACK有效载荷大小，且隐含公开了反馈实例包括HARQ过程、每个过程包含传输块。本领域技术人员可以合理推断，确定分配给传输块的确认比特数目首先需确定反馈实例总数目，再分配到过程，故该特征被隐含公开。 |
| **技术特征I：基于传输块大小，将确认比特分配给至少一个过程**<br>《未公开》 | 无 | 对比文件未公开基于传输块大小分配确认比特给过程，其分配基于UL DAI和小区配置。 |
| **技术特征J：确定被分配给过程的确认比特的数目，过程包括至少一个传输块**<br>《未公开》 | 无 | 对比文件未公开过程级别的确认比特数目确定。 |
| **技术特征K：基于传输块大小，将确认比特分配给至少一个传输块**<br>《未公开》 | 无 | 对比文件未公开基于TBS分配确认比特给传输块。 |
| **技术特征L：如果反馈实例包括多个过程或者至少一个过程包括多个传输块，则基于传输块大小而将确认比特分别分配给过程或传输块包括：确定过程之间的、或者传输块之间的传输块大小比率**<br>《未公开》 | 无 | 对比文件未涉及传输块大小比率。 |
| **技术特征M：基于最接近传输块比率的确认比特比率来分配确认比特**<br>《未公开》 | 无 | 对比文件无此分配方式。 |
| **技术特征N：包括：基于传输参数来确定传输块大小**<br>《隐含公开》 | [0163]：“PDCCH上的DCI包括若干字段，例如...调制和编译方案（MCS）、资源分配等。” | 在LTE中，传输块大小由MCS和分配的物理资源块数确定，这是本领域公知常识。对比文件提及了MCS和资源分配参数，本领域技术人员可合理推断出基于这些参数确定TBS，故该特征被隐含公开。 |
| **技术特征O：其中传输参数包括：调制编码方案和物理资源块号中的至少一个**<br>《隐含公开》 | [0163]提及MCS和资源分配（包含PRB信息）；[0088]等涉及MCS和资源块。 | 对比文件公开了MCS和资源块分配，这些是确定TBS的基本参数，因此该特征被隐含公开。 |
| **技术特征P：包括：从基站接收第一信息，第一信息包括对被分配给反馈实例的确认比特的数目的指示**<br>《直接公开》 | [0208]：“BS通过UL许可PDCCH将UL-DAI发射到UE（步骤S101）。”<br>[0218]：“UE基于UL DAI值来确定ACK/NACK有效载荷大小。” | 对比文件明确公开了从基站接收UL-DAI，该信息用于确定ACK/NACK有效载荷大小（即反馈实例的确认比特数目），故直接公开。 |
| **技术特征Q：包括：从基站接收切换信息，切换信息包括从第一反馈方案切换到第二反馈方案的指示**<br>《未公开》 | 无 | 对比文件未公开从基站接收切换不同反馈方案的指示。 |
| **技术特征R：其中每个组中的代码块的数目是相等的，或者每个组中的代码块的数目相差1**<br>《未公开》 | 无 | 对比文件未涉及代码块组的分组规则。 |
| **技术特征S：其中m‑r个代码块组包括L数目个代码块，并且r个代码块组具有L+1个代码块，其中m是确认比特的数目，L是对多个代码块的数目与确认比特的数目的商的向下取整，并且r是余数**<br>《未公开》 | 无 | 对比文件未公开任何类似的分组公式。 |
| **技术特征T：其中如果被传输的确认比特是否定确认**<br>《隐含公开》 | [0170]定义“NACK：当在PDSCH上接收到的传送块的解码失败时。”<br>[0110]描述当NACK时BS重传。 | 对比文件公开了NACK状态（即确认比特为否定确认），因此隐含公开了该条件。 |
| **技术特征U：接收代码块组的代码块的重传**<br>《未公开》 | 无 | 对比文件仅公开了传输块级别的重传，未公开基于代码块组的代码块重传。 |
<<<C>>><<<P>>><<<a>>><<<b>>><<<h>>><<<n>>><<<o>>><<<t>>>