好的，作为一名资深专利代理师，我将严格遵守您的评估指示和要求，对对比文件是否公开了目标专利权利要求的各技术特征进行严谨、深入的分析。
### 回答
**对比文件名称：** 2009-11-19_WO2009138841A_发明申请_WO2009138841A2 INCREASING RELIABILITY OF HYBRID AUTOMATIC REPEAT REQUEST PROTOCOL
**目标专利名称：** 1119无线通信网络中用于授予丢失检测和有关处理的方法和设备CN103190108B
**模型名称：** deepseek
### 特征比对表格
| 技术特征描述以及公开性判断结果 | 对比文件原文引用 (已翻译) | 公开性论述 |
| **技术特征A**：所述方法包括，借助于通过所述下行链路控制信道传送调度授予到移动终端，调度去往或来自所述移动终端的传送<br>《直接公开》 | [p0005] “...调度器在基站调度一个或多个用户终端以在PDSCH上接收数据...被调度在给定时间间隔内接收数据的用户终端的身份以及传输格式，通过物理下行链路控制信道（PDCCH）发送给用户终端。”<br>[p0008] “用户终端仅在已被调度在下行链路共享信道上接收数据时才向基站发送ACK/NACK反馈。” | 对比文件明确公开了：基站调度器通过下行链路控制信道（PDCCH）发送调度信息（即调度授予）给用户终端，以调度该用户终端在下行链路共享信道（PDSCH）上接收数据。这完全对应目标专利的“借助于通过所述下行链路控制信道传送调度授予到移动终端，调度去往或来自所述移动终端的传送”。因此，技术特征A被直接公开。 |
| **技术特征B**：基于检测对应于所述调度的传送的擦除事件，确定所述调度授予的任何一个授予是否丢失<br>《隐含公开》 | [p0008] “...用户终端可能无法解码在PDCCH上传输的调度消息。如果用户终端无法解码在PDCCH上传输的调度消息，基站将在期望接收ACK/NACK反馈的PUSCH上接收到用户数据。”<br>[p0023] “...基站20认为用户终端100已成功接收传输的数据包...这可能导致大的延迟。” | 对比文件描述了用户终端解码PDCCH失败（即调度授予丢失）的场景，并指出基站会因为未收到预期的ACK/NACK而收到用户数据，即发生“假ACK”场景。这描述了基站感知到“期望接收正常信息（ACK/NACK）但发生了异常事件（收到用户数据）”。目标专利将此异常事件定义为“擦除事件”，并基于此确定授予丢失。虽然对比文件未使用“擦除事件”一词，但其描述的“在期望ACK/NACK的资源上收到用户数据”本质上就是一种与预期不符的异常事件。本领域技术人员结合对比文件的内容，可以合理推断出：基站可以通过检测这种与预期调度的传送（ACK/NACK）不符的异常事件，来推断调度授予可能丢失。因此，技术特征B被隐含公开。 |
| **技术特征C**：响应确定各个调度授予是否丢失，控制所述下行链路控制信道的链路自适应或用于所述调度的传送的HARQ冗余版本设置或两者<br>《无公开》 | 全文未公开。 | 对比文件全文未提及在检测到调度授予丢失后，会采取任何措施来控制下行链路控制信道的链路自适应或HARQ冗余版本设置。对比文件的核心在于预先根据ACK/NACK的反馈信道（PUCCH或PUSCH）来调整PDCCH的可靠性（如[p0024]-[p0027]所述），以预防授予丢失的发生，而不是在丢失发生后进行响应性控制。因此，技术特征C既未被直接公开，也未被隐含公开。 |
| **技术特征D**：其中检测擦除事件包括检测对应于信息信号或解调参考信号的预期接收的接收信号能量<br>《无公开》 | 全文未公开。 | 对比文件描述了检测到“假ACK”的场景（即“基站将在期望接收ACK/NACK反馈的PUSCH上接收到用户数据”），但并未公开如何具体检测该场景。它没有公开通过检测接收信号能量（如能量阈值检测）来判断是否存在预期的ACK/NACK信号或DMRS。因此，技术特征D既未被直接公开，也未被隐含公开。 |
| **技术特征E**：比较所述接收信号能量和定义的阈值<br>《无公开》 | 全文未公开。 | 对比文件未公开任何关于能量检测或阈值比较的细节。因此，技术特征E既未被直接公开，也未被隐含公开。 |
| **技术特征F**：其中在所述调度授予是调度下行链路传送到所述移动终端的下行链路调度授予的情况下，检测擦除事件包括确定未从所述移动终端收到与所述调度的下行链路传送相符的确认信息。<br>《直接公开》 | [p0008] “...如果用户终端无法解码在PDCCH上传输的调度消息，基站将在期望接收ACK/NACK反馈的PUSCH上接收到用户数据。”<br>[p0023] “如果用户终端100无法解码在PDCCH上传输的调度消息，基站20将在期望接收ACK/NACK反馈的PUSCH上接收到用户数据。” | 对比文件明确公开了以下场景：基站发送了下行调度授予（PDCCH），但由于用户终端未成功解码该授予，导致基站未从用户终端收到预期的确认信息（ACK/NACK），并收到了用户数据。这实质上就是“确定未从所述移动终端收到与所述调度的下行链路传送相符的确认信息”。因此，技术特征F被直接公开。 |
| **技术特征G**：其中所述无线通信网络是LTE网络；并且检测擦除事件包括：如果是下行链路调度授予而不是上行链路调度授予被传送到所述移动终端，则监视在物理上行链路控制信道(PUCCH)上来自所述移动终端的Ack/Nack信令是否不存在<br>《直接公开》 | [p0007] “如果发送ACK/NACK时用户终端未被调度在PUSCH上发送，用户终端在物理上行链路控制信道（PUCCH）上发送ACK/NACK。”<br>[p0027] “如果调度器期望用户终端100使用更高可靠性的信道（例如PUCCH）来发送ACK/NACK反馈，基站20以正常可靠性在DL控制信道上发送调度信息。”<br>[p0024] “当ACK/NACK反馈在PUCCH上发送时...减少了基站20检测到假ACK的概率...” | 对比文件在LTE系统背景下，明确指出了当用户终端未被调度在PUSCH上发送数据时（即只收到DL调度授予，未收到UL调度授予），会使用PUCCH来发送ACK/NACK。此时基站通过监视PUCCH来接收该信令。如果用户终端未收到DL调度授予，就不会发送ACK/NACK，基站就能检测到该信令的缺失。对比文件将这种ACK/NACK缺失情况下的检测定义为“假ACK”检测的一部分。本领域技术人员可以毫无疑义地确定，对比文件中的“假ACK”检测场景包含了“监视在PUCCH上来自所述移动终端的Ack/Nack信令是否不存在”这一技术手段。因此，技术特征G被直接公开。 |
| **技术特征H**：如果下行链路和上行链路调度授予以能够促使所述移动终端在物理上行链路共享信道(PUSCH)上传送Ack/Nack信令的时间顺序被传送到所述移动终端，则监视在所述PUSCH上和所述PUCCH上来自所述移动终端的Ack/Nack信令是否不存在。<br>《无公开》 | [p0007] “如果用户终端被调度在PUSCH上发送数据，用户终端使用分配资源的一部分在PUSCH上发送ACK/NACK。”<br>[p0025] “当用户终端100预期在PUSCH上发送ACK/NACK反馈时，基站20可以增强PDCCH上信令信息的可靠性...” | 对比文件仅公开了在预期UE在PUSCH上发送ACK/NACK时，基站会增强PDCCH可靠性。但并未公开一种策略，即当DL和UL调度授予的时间关系可能导致UE在PUSCH上发送ACK/NACK时，基站会同时在PUSCH和PUCCH上监视ACK/NACK信令是否不存在。它没有公开这种“双重监视”或“回退监视”的具体机制。因此，技术特征H既未被直接公开，也未被隐含公开。 |
| **技术特征I**：其中所述无线通信网络是LTE网络；并且检测擦除事件包括如果预期有来自所述移动终端的上行链路传送，则通过检测是否在物理上行链路共享信道(PUSCH)上或在物理上行链路控制信道(PUCCH)上收到来自所述移动终端的预期解调参考信号(DMRS)，检测是否发生擦除事件。<br>《无公开》 | 全文未公开。 | 对比文件虽然基于LTE网络，但未公开任何关于使用解调参考信号(DMRS)的检测来作为判断擦除事件或授予丢失的依据。其整个方案围绕ACK/NACK信令本身展开，未涉及DMRS。因此，技术特征I既未被直接公开，也未被隐含公开。 |
| **技术特征J**：其中在所述调度授予是调度由所述移动终端进行的上行链路传送的上行链路调度授予的情况下，检测擦除事件包括确定所述调度的上行链路传送未在所述基站收到。<br>《无公开》 | 全文未公开。 | 对比文件主要关注下行链路调度授予丢失导致的“假ACK”问题。虽然提到了“上行链路调度授权信令”（[p0010]），但其目的是为了预留ACK/NACK资源。对比文件没有公开任何关于上行链路调度授予本身丢失的检测机制，即没有公开基站通过确定未收到预期的上行链路数据来判断UL授予丢失。因此，技术特征J既未被直接公开，也未被隐含公开。 |
| **技术特征K**：其中确定所述调度的上行链路传送未在所述基站收到包括：检测到在对应于所述调度的上行链路传送的信道资源上的接收信号能量低<br>《无公开》 | 全文未公开。 | 对比文件未公开通过检测接收信号能量低来判断上行链路传送是否未收到。因此，技术特征K既未被直接公开，也未被隐含公开。 |
| **技术特征L**：或检测到所述接收信号能量低结合检测到在所述基站对所述调度的上行链路传送的循环冗余校验(CRC)失败。<br>《无公开》 | 全文未公开。 | 对比文件未公开任何关于CRC失败的检测。因此，技术特征L既未被直接公开，也未被隐含公开。 |
| **技术特征M**：其中确定在所述基站未收到所述确认信息包括检测到在与所述确认信息相关联的信道资源上的接收信号能量低。<br>《无公开》 | 全文未公开。 | 对比文件未公开任何关于通过能量检测来确定ACK/NACK是否收到的细节。其描述的“假ACK”场景是通过解析收到的用户数据来识别的，而非能量检测。因此，技术特征M既未被直接公开，也未被隐含公开。 |
| **技术特征N**：其中控制所述下行链路控制信道的链路自适应包括控制所述下行链路控制信道的编码率或传送功率或两者。<br>《直接公开》 | [p0025] “信令信息的可靠性可以通过例如增加PDCCH上的发射功率、增加聚合级别或其组合来提高。”<br>[p0027] “增加聚合级别” | 对比文件明确公开了通过控制PDCCH的“发射功率”（对应传送功率）和“聚合级别”（聚合级别影响有效编码率，更高的聚合级别对应更低的编码率，即更健壮的编码）来提高可靠性。这直接对应于控制下行链路控制信道的“传送功率”和“编码率”。因此，技术特征N被直接公开。 |
| **技术特征O**：其中控制所述下行链路控制信道的链路自适应包括根据为所述移动终端维护的校正的信号质量估计，动态选择所述下行链路控制信道的编码率或传送功率或两者<br>《无公开》 | 全文未公开。 | 对比文件公开的链路自适应策略是基于用户终端预期的ACK/NACK反馈信道（PUCCH/PUSCH）这一单一因素，来决定是否采用“增强可靠性”模式，而非基于一个动态维护的、经“校正的”信号质量估计。对比文件没有公开任何关于“校正的信号质量估计”的概念或机制。因此，技术特征O既未被直接公开，也未被隐含公开。 |
| **技术特征P**：还包括基于来自所述移动终端的信道质量反馈和根据任一给定调度授予是否丢失而向上或向下调整的校正因子，维护所述校正的信号质量估计。<br>《无公开》 | 全文未公开。 | 对比文件未公开任何关于“校正因子”的概念，也未公开根据授予丢失与否来调整信号质量估计。其方案不依赖于授予丢失的检测结果来反馈调整链路自适应。因此，技术特征P既未被直接公开，也未被隐含公开。 |
| **技术特征Q**：还包括在与所述移动终端的无线电资源控制(RRC)连接的持续时间内，动态维护用于所述移动终端的所述校正因子。<br>《无公开》 | 全文未公开。 | 对比文件未公开任何关于“校正因子”的概念，也未提到RRC连接持续时间内的动态维护。因此，技术特征Q既未被直接公开，也未被隐含公开。 |
| **技术特征R**：其中控制所述下行链路控制信道的链路自适应包括根据为所述移动终端维护的校正的编码率值，动态选择所述下行链路控制信道的编码率或传送功率或两者<br>《无公开》 | 全文未公开。 | 对比文件未公开校正的编码率值。其公开的链路自适应是二元的（正常可靠性/增强可靠性），不涉及持续的、基于校正编码率值的动态选择。因此，技术特征R既未被直接公开，也未被隐含公开。 |
| **技术特征S**：还包括基于来自所述移动终端的信道质量反馈和根据任一给定调度授予是否丢失而向上或向下调整的校正因子，维护所述校正的编码率值。<br>《无公开》 | 全文未公开。 | 对比文件未公开任何关于“校正因子”的概念，也未公开基于授予丢失调整编码率值的机制。因此，技术特征S既未被直接公开，也未被隐含公开。 |
| **技术特征T**：其中在给定传送的调度授予是用于初始传送的下行链路调度授予并且被确定丢失的情况下，控制所述HARQ冗余版本设置包括发送新下行链路调度授予到所述移动终端<br>《无公开》 | 全文未公开。 | 对比文件未公开在确定DL授予丢失后，发送新的DL调度授予的行为。其方案旨在通过增强PDCCH可靠性来避免授予丢失，而非处理已发生的丢失。因此，技术特征T既未被直接公开，也未被隐含公开。 |
| **技术特征U**：将所述HARQ冗余版本重置成在所述丢失的授予中使用的相同值。<br>《无公开》 | 全文未公开。 | 对比文件未公开任何关于HARQ冗余版本重置的概念。其内容不涉及此技术细节。因此，技术特征U既未被直接公开，也未被隐含公开。 |
| **技术特征V**：其中在给定传送的调度授予是用于初始传送的上行链路调度授予并且被确定丢失的情况下，控制所述HARQ冗余版本设置包括发送新上行链路调度授予到所述移动终端。<br>《无公开》 | 全文未公开。 | 对比文件未公开上行链路调度授予丢失的检测，更未公开在检测到丢失后发送新上行链路调度授予。因此，技术特征V既未被直接公开，也未被隐含公开。 |
<<<A>>><<<F>>><<<G>>><<<N>>><<<b>>>