对比文件名称：US2018206289A1_Description_20260218_1537
目标专利名称：178具有低延时传输的快速无线链路控制错误恢复CN107409020B
本次调用的模型名称：DeepSeek最新版本模型
## 特征比对表格
| 技术特征描述以及公开性判断结果 | 对比文件原文引用 | 公开性论述 |
| 技术特征A：在接收设备处至少部分地基于对来自发送设备的传输的解码失败以及混合自动重传请求(HARQ)过程的状态来检测传输错误 <br>**未被直接公开或隐含公开** | 对比文件第[0047]段：“A physical downlink control channel (PDCCH) reports to a UE about resource allocation of a paging channel (PCH) and a downlink shared channel (DL-SCH), and hybrid automatic repeat request (HARQ) information related to the DL-SCH.” <br>对比文件第[0077]段：“The drxRetransmission Timer corresponds to a timer that operates based on a maximum value corresponding to a number of continuous PDCCH subframes that are expected to be immediately re-transmitted by the user equipment via downlink. The drxRetransmission Timer corresponds to a timer that starts in a case when the user equipment fails to receive re-transmission data even after an expiration of a HARQ RTT timer.” | **直接公开判断**：对比文件虽然提到了HARQ过程和相关信息（如PDCCH携带HARQ信息），以及drxRetransmissionTimer在HARQ RTT定时器期满后未收到重传数据时启动，但并未明确公开“接收设备基于对来自发送设备的传输的解码失败以及HARQ过程的状态来检测传输错误”这一具体技术特征。目标专利中该特征涉及在MAC/RLC层主动检测传输失败以触发快速恢复，而对比文件描述的drxRetransmissionTimer启动条件（HARQ RTT定时器期满后未收到重传）是DRX操作的一部分，并非基于“解码失败”的主动检测机制。两者作用不同：目标专利用于快速错误恢复，对比文件用于节能的DRX监听控制。<br><br>**隐含公开判断**：对比文件提及了HARQ过程以及接收失败后启动定时器（drxRetransmissionTimer）的场景。本领域技术人员知晓HARQ过程本身涉及对传输块解码的成功或失败（ACK/NACK）。从对比文件第[0077]段“user equipment fails to receive re-transmission data”可以合理推断出接收设备知晓传输失败（即解码失败）的状态。然而，该段描述的是在HARQ RTT定时器期满这一特定事件后判断未收到重传数据，并未明确或必然推导出目标专利中所述的、基于解码失败和HARQ状态来“检测传输错误”作为启动一个独立定时器（非DRX定时器）的触发条件。该特征在目标专利中是快速错误恢复流程的起点，与对比文件中DRX机制下用于控制PDCCH监听时长的定时器在目的和上下文上存在本质区别。因此，无法从对比文件隐含公开该技术特征。 |
| 技术特征B：与检测到所述传输错误并发地或在检测到所述传输错误之后，来启动定时器 <br>**未被直接公开或隐含公开** | 对比文件第[0077]段：“The drxRetransmission Timer corresponds to a timer that starts in a case when the user equipment fails to receive re-transmission data even after an expiration of a HARQ RTT timer.” | **直接公开判断**：对比文件公开了drxRetransmissionTimer在HARQ RTT定时器期满且用户设备未能接收到重传数据时启动。这描述了在特定条件（定时器期满且未收到数据）满足后启动一个定时器。然而，该条件并非目标专利中明确的“与检测到传输错误并发地或在检测到传输错误之后”。目标专利的定时器启动直接基于传输错误的检测，旨在加速错误报告。对比文件的drxRetransmissionTimer是DRX机制的一部分，用于控制UE监听PDCCH以等待可能的下行重传的时长，其启动依赖于另一个定时器（HARQ RTT）的期满事件，并非直接或并发于传输错误检测本身。两者技术方案和作用不同。<br><br>**隐含公开判断**：对比文件描述了在“用户设备未能接收到重传数据”时启动drxRetransmissionTimer。“未能接收到重传数据”可视为一种传输失败或错误。因此，本领域技术人员有可能从对比文件推断出在检测到传输失败（未能接收数据）后启动一个定时器（drxRetransmissionTimer）。然而，关键在于对比文件明确限定了启动条件是“在HARQ RTT定时器期满之后”。这与目标专利中“与检测错误并发地或之后”的宽泛时机描述不完全一致。更重要的是，对比文件中的定时器是DRX相关的定时器，用于管理UE的激活时间，而目标专利中的定时器是专门用于快速错误恢复的独立定时器，其目的和所属协议流程（错误恢复 vs. 节能监听）不同。因此，即使存在部分概念重叠，但基于整体技术方案和作用的差异，不能认为对比文件隐含公开了目标专利中的该技术特征。 |
| 技术特征C：识别用于所述HARQ过程的新数据指示符(NDI) <br>**未被直接公开或隐含公开** | 无 | **直接公开判断**：在对比文件全文中，未提及“新数据指示符（NDI）”这一概念或任何功能等同的标识符。NDI是HARQ过程中用于区分新数据包传输与旧数据包重传的关键信号。对比文件虽然多次提及HARQ，但并未描述NDI或其识别。<br><br>**隐含公开判断**：对比文件未提及任何与NDI相关的内容。NDI是HARQ协议中的特定字段，用于指示传输块是否包含新数据。对比文件未部分公开该特征，也没有提供任何可让本领域技术人员推理出“识别NDI”这一技术方案的基础信息。因此，该技术特征未被隐含公开。 |
| 技术特征D：在识别所述NDI之后，确定在针对所述HARQ过程的重传的准许已经被接收之前所述定时器已经期满 <br>**未被直接公开或隐含公开** | 对比文件第[0077]段：“While the drxRetransmission Timer is activated, the user equipment may monitor the reception of the re-transmitted data during a HARQ process.” | **直接公开判断**：对比文件描述了在drxRetransmissionTimer激活期间，UE监控HARQ过程中的重传数据接收。这涉及定时器激活与监控重传的关系，但并未提及“识别NDI”这一前提条件，也未明确描述“确定在重传的准许已被接收之前定时器已经期满”这一判断逻辑。目标专利中该判断是触发错误报告的关键决策点，而对比文件中drxRetransmissionTimer的运行是DRX状态管理的一部分，目的不同。<br><br>**隐含公开判断**：由于技术特征C（识别NDI）未被公开，因此以“识别NDI之后”为前提的技术特征D更无从谈起。此外，对比文件没有描述将“定时器期满”与“重传的准许已被接收”这两个事件进行比较并做出确定的步骤。drxRetransmissionTimer的期满可能导致UE停止监听PDCCH，但并未被描述为触发向发送设备报告传输错误的直接原因。因此，该技术特征未被隐含公开。 |
| 技术特征E：以及至少部分地基于所述NDI和所述确定来向所述发送设备报告所述传输错误。 <br>**未被直接公开或隐含公开** | 无 | **直接公开判断**：对比文件没有描述基于NDI和定时器期满的确定来向发送设备报告传输错误的过程。对比文件中与错误反馈相关的仅有第[0047]段提及的PHICH携带HARQ ACK/NACK信号，这是一种物理层的即时反馈，而非目标专利中所述的可能涉及更高层（RLC/PDCP/MAC实体）的、基于特定条件触发的错误报告机制。<br><br>**隐含公开判断**：由于技术特征C和D均未被公开，因此基于这两者的特征E（基于NDI和所述确定来报告错误）也不可能被隐含公开。此外，对比文件的核心内容是SCPTM服务下的PDCCH监控和DRX配置，并未描述目标专利所涉及的、在低延时场景下为加速恢复而主动向发送设备报告传输错误的机制。因此，该技术特征未被隐含公开。 |
| 技术特征F：其中，报告所述传输错误包括：由所述接收设备向所述发送设备的无线链路控制(RLC)实体、分组数据会聚协议(PDCP)实体或介质访问控制(MAC)实体发送错误指示。 <br>**未被直接公开或隐含公开** | 对比文件第[0056]段：“The RLC layer provides three operation modes, i.e., a transparent mode (TM), an unacknowledged mode (UM), and an acknowledged mode (AM). The AM RLC provides a retransmission function through an automatic repeat request (ARQ) for reliable data transmission.” <br>对比文件第[0057]段：“The PDCP layer provides a function of header compression function... In addition, the PDCP layer provides a function of security.” <br>对比文件第[0051]段：“A MAC layer belongs to the L2. The MAC layer provides services to a radio link control (RLC) layer...” | **直接公开判断**：对比文件提及了RLC、PDCP、MAC这些协议实体的存在及其部分基本功能（如ARQ、头压缩、安全、向RLC提供服务）。然而，对比文件完全没有描述“接收设备向发送设备的RLC、PDCP或MAC实体发送错误指示”这一具体动作。目标专利中该特征是快速错误恢复报告的具体实现方式，而对比文件中未记载任何类似的跨设备或跨实体错误指示发送过程。<br><br>**隐含公开判断**：对比文件公开了协议栈中RLC、PDCP、MAC实体的存在。本领域技术人员知道这些实体之间可能存在通信。但是，对比文件完全没有提及在传输错误发生时，接收设备需要向发送设备的这些实体发送错误指示。特别是，对比文件主要关注SCPTM服务的接收和DRX配置，其上下文与目标专利的低延时快速错误恢复不同。没有内容支持可以合理推断出该具体的错误报告方式。因此，该技术特征未被隐含公开。 |
| 技术特征G：其中，发送所述错误指示包括使用基于竞争的资源来向所述发送设备的实体发送所述错误指示。 <br>**未被直接公开或隐含公开** | 无 | **直接公开判断**：对比文件全文中未提及“基于竞争的资源”（例如，基于竞争的随机接入资源）或使用此类资源发送任何信息，特别是错误指示。<br><br>**隐含公开判断**：对比文件未涉及基于竞争的传输机制。该特征在目标专利中是一种可能的错误报告传输方式，但对比文件没有提供任何相关的基础信息或上下文。无法从对比文件进行任何合理推断。因此，该技术特征未被隐含公开。 |
| 技术特征H：还包括：维护非终止传输的列表，其中，报告所述传输错误是至少部分地基于所述列表的。 <br>**未被直接公开或隐含公开** | 无 | **直接公开判断**：对比文件未提及“非终止传输的列表”这一概念。对比文件中与传输状态管理最相关的是DRX定时器的操作，但并未描述维护一个列表来追踪非终止传输（如活动的HARQ过程）。<br><br>**隐含公开判断**：对比文件未部分公开该特征。虽然对比文件提到了HARQ过程，但没有描述为这些过程维护一个列表，并将该列表用于错误报告。无法从对比文件的内容推理出该技术方案。因此，该技术特征未被隐含公开。 |
| 技术特征I：其中，所述列表中的每个条目被映射到时间索引。 <br>**未被直接公开或隐含公开** | 无 | **直接公开判断**：由于特征H（非终止传输列表）未被公开，其进一步限定的特征I（条目映射到时间索引）自然也未被公开。<br><br>**隐含公开判断**：同上，缺乏公开特征H的基础，特征I无法被隐含公开。对比文件无相关内容。 |
| 技术特征J：其中，报告所述传输错误包括：向所述发送设备发送与所述列表相对应的位图。 <br>**未被直接公开或隐含公开** | 对比文件第[0096]段：“That is, when a bit corresponding to a specific subframe in a bitmap is 1, it is indicated that the specific subframe is configured as an MBSFN subframe.” <br>对比文件第[0131]段：“The continuous subframe may be indicated by a bitmap.” <br>对比文件第[0135]段：“The subframe scheduling information may include bitmap information.” | **直接公开判断**：对比文件公开了使用位图（bitmap）来指示MBSFN子帧配置或调度信息。然而，目标专利中使用位图是为了报告与非终止传输列表相对应的错误状态。对比文件中位图的用途是配置子帧或指示调度，与报告传输错误无关。技术方案和作用均不相同。<br><br>**隐含公开判断**：对比文件公开了在无线通信中使用位图来指示信息这一通用手段。但是，该手段应用的具体上下文和目的与目标专利截然不同。本领域技术人员无法从对比文件“使用位图指示子帧配置”推理出“使用位图向发送设备报告与非终止传输列表相对应的传输错误”。目标专利的位图承载的是错误报告内容，而对比文件的位图承载的是资源配置信息。因此，该技术特征未被隐含公开。 |
| 技术特征K：其中，所述列表限于高优先级HARQ过程集合，其中，所述HARQ过程是所述高优先级HARQ过程集合的元素。 <br>**未被直接公开或隐含公开** | 无 | **直接公开判断**：对比文件未提及“高优先级HARQ过程集合”的概念，也未对HARQ过程进行优先级区分。<br><br>**隐含公开判断**：对比文件未涉及HARQ过程的优先级划分。该特征与目标专利的低延时、快速恢复场景紧密相关，而对比文件的SCPTM DRX配置场景并未涉及此概念。无法从对比文件推理出该技术方案。 |
| 技术特征L：其中，所述高优先级HARQ过程集合至少部分地基于延时操作模式来确定。 <br>**未被直接公开或隐含公开** | 无 | **直接公开判断**：对比文件未提及“延时操作模式”以及基于此确定HARQ过程集合。<br><br>**隐含公开判断**：对比文件未涉及延时操作模式。该特征未被隐含公开。 |
| 技术特征M：还包括：选择快速恢复模式，其中，启动所述定时器至少部分地基于所述选择。 <br>**未被直接公开或隐含公开** | 无 | **直接公开判断**：对比文件未提及“快速恢复模式”的选择。对比文件涉及的是SCPTM DRX配置的选择或使用，而非错误恢复模式。<br><br>**隐含公开判断**：对比文件的核心是DRX配置用于节能和PDCCH监控，与“快速恢复模式”用于加速错误处理在目的和功能上不同。无法从对比文件推理出该技术特征。 |
| 技术特征N：其中，所述选择至少部分地基于延时操作模式。 <br>**未被直接公开或隐含公开** | 无 | **直接公开判断**：由于特征M（选择快速恢复模式）未被公开，其从属特征N自然也未被公开。<br><br>**隐含公开判断**：同上，缺乏基础，未被隐含公开。 |
| 技术特征O：其中，所述选择至少部分地基于至少一个高优先级承载的配置。 <br>**未被直接公开或隐含公开** | 无 | **直接公开判断**：由于特征M（选择快速恢复模式）未被公开，其从属特征O自然也未被公开。<br><br>**隐含公开判断**：同上，缺乏基础，未被隐含公开。 |
| 技术特征P：还包括：至少部分地基于所述HARQ过程的所述状态来发送否定确认(NACK)。 <br>**未被直接公开或隐含公开** | 对比文件第[0047]段：“A physical hybrid ARQ indicator channel (PHICH) carries an HARQ acknowledgement (ACK)/non-acknowledgement (NACK) signal in response to UL transmission.” | **直接公开判断**：对比文件公开了PHICH信道携带HARQ ACK/NACK信号以响应上行传输。这确实公开了基于HARQ过程状态（解码成功/失败）来发送NACK。然而，目标专利中该特征是其快速错误恢复方法中的一个可选或附加步骤。从作用上看，两者都是对传输失败进行否定确认。因此，可以认为对比文件直接公开了“基于HARQ过程状态发送NACK”这一技术手段本身。 |
| 技术特征Q：还包括：将传输块集合在缓冲区中保持用于重传的最小时间段。 <br>**未被直接公开或隐含公开** | 对比文件第[0077]段：“The HARQ RTT corresponds to a timer defining a minimum number of subframes before the period during which downlink HARQ re-transmission is expected to be performed by the user equipment.” | **直接公开判断**：对比文件公开了HARQ RTT定时器，它定义了在用户设备预期执行下行HARQ重传的时段之前的最小子帧数。这隐含了发送设备需要将数据（如传输块）保持一段时间以供重传。目标专利中“将传输块集合在缓冲区中保持用于重传的最小时间段”与对比文件中HARQ RTT定时器所体现的、在重传预期期间内保持数据的概念相一致。两者作用都是支持HARQ重传机制。因此，本领域技术人员能够从对比文件的HARQ RTT定时器毫无疑义地得出，发送设备需要将传输数据在缓冲区中保持一个最小时间段（即HARQ RTT时间）以等待可能的重复请求。该技术特征被直接公开。 |
## 结论
根据上述比对分析，对比文件US2018206289A1直接公开了目标专利权利要求中的技术特征P和Q，未直接公开或隐含公开其余技术特征A-O。
<<<P>>><<<Q>>>