对比文件名称：2007-11-08_US2007260851A_发明申请_US20070260851A1 Sleep optimization based on system information block scheduling
目标专利名称：在切换之后延迟对调度请求的触发 CN106105313B
模型名称：DeepSeek最新版本模型
### 特征比对表格
| 技术特征描述以及公开性判断结果 | 对比文件原文引用 | 公开性论述 |
| **技术特征A：包括：确定已经发生从第一基站到第二基站的切换** <br>《隐含公开》 | [0028] ... If the UE 105 decides to reselect and establish neighboring cell 115 as the new serving cell, the UE 105 can read various system information packets broadcast over a control channel. | 对比文件描述了UE执行小区重选并建立邻区作为新服务小区的过程。该过程涉及UE从当前服务小区（第一基站）切换到目标邻区（第二基站），这实质上是移动通信中的切换（handover/cell reselection）事件。虽然对比文件主要使用“重选（reselect）”一词，但在本领域，特别是在空闲模式下，小区重选是切换的一种形式或前序步骤。因此，本领域技术人员能够从对比文件的内容中，合理推断出UE确定发生了从一个小区（基站）到另一个小区（基站）的变更。该特征在对比文件中用于触发UE读取新小区的系统信息，与目标专利中用于触发后续延迟调度请求逻辑的作用起点相同。因此，该技术特征被**隐含公开**。 |
| **技术特征B：至少部分地基于确定在所述切换之后在所述移动设备处没有从所述第二基站接收到主信息块(MIB)，将对调度请求到所述第二基站的传输延迟预定时间段。** <br>《未公开》 | [0032] The MIBs contain information about the scheduling of the SIBs... <br>[0035] ...Upon reselection to a new cell, the UE 105 should collect the SIBs... <br>[0041] ...embodiments of the invention can adapt to other networks... | 对比文件确实公开了UE在小区重选（切换）后需要读取目标小区（第二基站）的MIB，以获取SIB调度信息。然而，对比文件的核心在于利用SIB调度信息来优化UE的睡眠周期以省电，**完全没有提及“调度请求（Scheduling Request）”及其传输**。目标专利的技术方案核心是：在切换后，若未收到MIB，则延迟调度请求的发送，以避免触发低效的随机接入过程。对比文件中UE读取MIB失败或延迟可能会影响SIB的收集，但其后果是可能导致小区重选过程延长或失败，或影响睡眠优化，而**非用于决定是否延迟一个上行调度请求的发送**。两者要解决的技术问题（省电 vs. 避免低效随机接入）和采用的技术手段（睡眠控制 vs. 调度请求延迟）均不相同。本领域技术人员无法从对比文件中毫无疑义地得出或合理推断出“基于未收到MIB而延迟调度请求传输”的技术方案。因此，该技术特征**未被公开**。 |
| **技术特征C：其中，所述延迟对所述调度请求的所述传输包括：延迟对所述调度请求的所述传输，直到满足条件为止。** <br>《未公开》 | [0037] ...Because the UE is using a conventional sleep algorithm, it will stay awake for the entire duration... <br>[0038] ...embodiments of the invention allow the UE 105 to detect the time gaps of sufficient length during SIB acquisition and use them as opportunities to go into sleep state without missing SIBs. | 对比文件公开了UE在SIB采集期间，根据检测到的时间间隙（条件）进入睡眠状态（一种延迟或暂停活动的行为）。然而，这里“延迟”的对象是**UE的射频活动/唤醒状态**，目的是进入睡眠以省电；而“条件”是**SIB调度时间表中是否存在足够长的空闲间隙**。目标专利中“延迟”的对象是**调度请求的传输**，目的是等待获取定时信息；而“条件”是**是否从第二基站接收到MIB**。两者延迟的对象和等待的条件在技术本质上不同。本领域技术人员无法从对比文件的“基于时间间隙进入睡眠”直接且毫无疑义地得出“基于接收MIB事件来延迟调度请求传输”的方案。因此，该技术特征**未被公开**。 |
| **技术特征D：其中，满足所述条件包括：从所述第二基站接收到所述MIB。** <br>《未公开》 | [0032] The MIBs contain information about the scheduling of the SIBs... <br>[0035] The RRC can read the SIB scheduling info from MIBs... | 对比文件公开了UE从基站接收MIB，并且MIB是获取SIB调度信息的来源。但是，在对比文件的技术方案中，接收MIB是执行后续SIB采集和睡眠优化的一个**必要步骤或前提**，而非作为一个“延迟动作的停止条件”。具体而言，对比文件并未描述将“接收到MIB”本身作为一个条件，用于判断是否结束某个特定动作（如调度请求传输）的延迟。目标专利将“接收到MIB”明确作为停止延迟、触发调度请求的条件。两者的技术构思和用途不同。因此，该技术特征**未被公开**。 |
| **技术特征E：还包括：确定在已经发生所述切换之前已经接收到系统信息块(SIB)。** <br>《未公开》 | [0035] The UE 105 may be configured to postpone reading other system information blocks until the content is needed. <br>[0060] The UE 105 may store SIB information after the serving cell is first acquired, and optimize SIB collection upon serving cell selection, or when there is a change in the parameters of the serving cell. | 对比文件提到了UE可以存储先前获取的SIB信息，并在重新选择服务小区时优化SIB收集过程，例如只读取发生变化的SIB。这隐含了在再次选择（或切换回）某个小区前，UE可能已经持有该小区的部分SIB信息。然而，对比文件并未明确描述在**从第一基站切换到第二基站（即发生切换）这一事件之前**，UE**确定**已经接收过来自第二基站的SIB。目标专利中该特征（如说明书[0011]段所述）可能用于界定应用延迟调度请求策略的场景（例如，切换前已收到SIB，但切换后仍需等待MIB以获取定时）。对比文件未公开这种在切换事件时刻对SIB接收状态的明确“确定”以及其与后续延迟逻辑的关联。因此，该技术特征**未被公开**。 |
| **技术特征F：其中，所述预定时间段是至少部分地基于以下各项的：通过从所述第二基站接收的所述MIB来对上行链路定时的期望获取或者期望导出。** <br>《未公开》 | [0029] ...The UE 105 may periodically go into the wake-up state in order to demodulate a Paging Indicator Channel (PICH)... <br>[0080]-[0089] (Appendix A) ...L1 may compute the Time To Wake up (TTW) based on the following parameters: Warm-up Time (WU), Setup Time (SU), and Teardown Time (TD)... The time when the next earliest SIB is scheduled... | 对比文件详细计算了睡眠时间间隔（TTW），该间隔基于硬件唤醒/拆除时间、以及下一个待解码SIB的预定调度时间。该时间段完全基于**下行链路**信道的调度（如下一个SIB或PICH的SFN）和UE内部处理延迟来计算，目的是控制睡眠周期。目标专利中的预定时间段是基于**通过MIB对上行链路定时的期望获取或导出**，即与上行同步相关。对比文件的技术方案完全不涉及上行链路定时的获取或导出，也未将MIB的内容（尽管MIB被接收）与计算一个用于延迟上行调度请求的时间段相关联。因此，该技术特征**未被公开**。 |
| **技术特征G：还包括：确定要在所述切换之后向所述第二基站发送数据** <br>《未公开》 | 全文未提及。 | 对比文件通篇围绕UE在空闲模式下接收系统信息（BCCH, MIB, SIB）和寻呼信息（PICH）以进行小区重选和睡眠优化，**完全没有提及UE有上行数据需要发送，也没有提及调度请求（SR）或任何上行资源请求机制**。确定要发送上行数据是触发调度请求的前提，也是目标专利要解决的技术问题（避免在此时触发低效随机接入）的起因。对比文件的技术场景和应用目标（省电）完全不同。因此，该技术特征**未被公开**。 |
| **技术特征H：基于确定在所述切换之后还没有从所述第二基站接收到所述MIB，确定所述MIB不存在** <br>《未公开》 | [0035] ...Each time the UE 105 reselects to a neighboring cell 115 whose valid system information it does not have, the UE 105 can collect the SIBs of the neighboring cell 115. <br>[0100] ...If the N-BCCH was not successfully established, an attempt to reacquire the N-BCCH is made... | 对比文件提到了UE在重选到新小区时，若没有有效的系统信息（可能包括未成功获取MIB），则会尝试收集SIB。也提到了邻居BCCH获取失败后的重试机制。这隐含了UE可能经历MIB获取失败的情况。但是，对比文件**没有明确描述“确定MIB不存在”这一具体的逻辑判断步骤**。目标专利中，“确定MIB不存在”是一个明确的判断动作，用于触发后续的延迟操作。对比文件更侧重于描述过程（尝试获取，若失败则可能重试或采取其他行动），而非这种用于控制流程的二元状态判断。因此，该技术特征**未被公开**。 |
| **技术特征I：将对所述调度请求的所述传输延迟所述预定时间段。** <br>《未公开》 | 全文未提及“调度请求（Scheduling Request）”。 | 该特征与技术特征B、C紧密相关，是延迟动作本身。由于对比文件根本没有公开“调度请求（Scheduling Request）”这一概念，更谈不上对其传输进行延迟。因此，该技术特征**未被公开**。 |
| **技术特征J：还包括：至少部分地基于确定在所述切换之后已经接收到所述MIB，向所述第二基站发送所述调度请求。** <br>《未公开》 | 全文未提及“调度请求（Scheduling Request）”。 | 该特征与技术特征D和M类似，涉及在接收到MIB后发送调度请求。由于对比文件未公开“调度请求”，也未建立“接收MIB”与“发送调度请求”之间的条件关系，因此该技术特征**未被公开**。 |
| **技术特征K：还包括：在所述预定时间段到期之后，确定是否已经接收到所述MIB** <br>《未公开》 | [0080]-[0089] (Appendix A) ...L1 may compute the Time To Wake up (TTW)... When there are no more 1's in the SSD, L1 shall go to sleep... | 对比文件描述了在计算出的睡眠时间（TTW）到期后，UE会唤醒并解码下一个预定的SIB或处理PICH。这个“到期后行动”的机制是基于**预先确定的调度表（SSD）**，而不是在到期后**重新评估一个事件（如是否收到MIB）的状态**。目标专利中，在预定时间段到期后，会再次主动检查MIB的接收状态，以决定下一步动作（如进一步延迟或触发SR）。这种“到期后检查条件”的循环控制逻辑在对比文件的睡眠优化方案中并未体现。因此，该技术特征**未被公开**。 |
| **技术特征L：响应于确定来自所述第二基站的所述MIB继续不存在，将对所述调度请求的所述传输进一步延迟第二预定时间段。** <br>《未公开》 | 全文未提及“调度请求（Scheduling Request）”及基于MIB接收状态的循环延迟逻辑。 | 对比文件没有公开任何与“调度请求传输”相关的延迟操作，更没有公开基于MIB持续未接收而进行的多次/递增延迟机制。因此，该技术特征**未被公开**。 |
| **技术特征M：还包括：响应于确定已经接收到所述MIB，发送所述调度请求。** <br>《未公开》 | 全文未提及“调度请求（Scheduling Request）”。 | 同技术特征J，由于对比文件未公开“调度请求”，因此“发送调度请求”这一动作以及其触发条件“响应于确定已经接收到MIB”均未被公开。 |
| **技术特征N：还包括：在所述第二预定时间段内未接收到所述MIB的情况下，发起无线链路失败(RLF)过程。** <br>《未公开》 | [0100] ...If the maximum number of reacquisition attempts is reached, the UE 105 aborts the attempt to reacquire the N-BCCH. | 对比文件提到了邻居BCCH重新获取尝试失败达到最大次数后，UE会中止该过程。这可以视为一种链路获取失败的处理。但是，这**不等同于发起“无线链路失败（RLF）过程”**。RLF在3GPP标准中是一个具有特定含义和流程的机制，通常发生在RRC连接状态下。对比文件描述的场景主要针对空闲模式下的小区重选和系统信息获取。此外，触发中止的条件是“重获取尝试次数超限”，而非“在第二预定时间段内未收到MIB”。因此，该技术特征**未被公开**。 |
| **技术特征O：其中，所述预定时间段是至少部分地基于预定数量的长期演进(LTE)帧的。** <br>《未公开》 | [0029] ...The SFN may be a sequential counter that can repeat after reaching a predefined value, and be associated with a fixed time value (e.g., 10 ms in some embodiments). | 对比文件使用了系统帧号（SFN）作为时间单位，并指出一个SFN可能对应10ms，这与LTE帧的长度相同。然而，对比文件应用的是UMTS系统，其帧结构可能与LTE不同，尽管时间长度可能巧合相同。更重要的是，对比文件中基于SFN计算的时间间隔是用于**控制睡眠周期**，其技术目的是省电。而目标专利中基于LTE帧的预定时间段是用于**延迟调度请求的传输**，其技术目的是等待上行定时获取以避免随机接入。两者虽然使用了相似的时间基准单位，但应用的目的、技术场景和解决的问题截然不同。本领域技术人员无法从对比文件的睡眠时间计算中，推理出将其用于延迟调度请求传输的时间基准。因此，该技术特征**未被公开**。 |
| **技术特征P：包括：用于确定已经发生从第一基站到第二基站的切换的单元** <br>《隐含公开》 | [0028] ...If the UE 105 decides to reselect and establish neighboring cell 115 as the new serving cell... | 该装置特征对应方法特征A。对比文件中描述了UE执行小区重选并建立新服务小区的功能，实现该功能的逻辑/模块（如图5中的平台502、ASIC 508、API 510及各协议层516协同工作）可视为“用于确定已经发生切换的单元”。该单元在对比文件中的作用是触发后续读取新小区系统信息的操作，与目标专利中对应单元的作用（触发后续延迟逻辑）在作为“切换事件检测器”的层面上是相同的。因此，该技术特征被**隐含公开**。 |
| **技术特征Q：用于至少部分地基于确定在所述切换之后在所述装置处没有从所述第二基站接收到主信息块(MIB)，将对调度请求到所述第二基站的传输延迟预定时间段的单元。** <br>《未公开》 | 全文未提及“调度请求（Scheduling Request）”及基于MIB接收状态延迟其传输的机制。 | 该装置特征对应方法特征B和I。由于对比文件未公开相关的方法步骤，因此实现这些步骤的功能单元也未被公开。 |
| **技术特征R：其中，所述用于延迟对所述调度请求的所述传输的单元延迟所述调度请求，直到已经从所述第二基站接收到所述MIB为止。** <br>《未公开》 | 全文未提及“调度请求（Scheduling Request）”及“延迟直到接收到MIB”的条件延迟机制。 | 该装置特征对应方法特征C和D。由于对比文件未公开相关的方法步骤，因此实现这些步骤的功能单元也未被公开。 |
| **技术特征S：还包括：用于确定在已经发生所述切换之前已经接收到系统信息块(SIB)的单元。** <br>《未公开》 | 对应方法特征E未被公开，因此该装置单元也未被公开。 | 该装置特征对应方法特征E。由于对比文件未公开“在切换之前确定已接收到SIB”这一方法步骤，因此实现该步骤的功能单元也未被公开。 |
| **技术特征T：其中，所述预定时间段是至少部分地基于以下各项的：通过从所述第二基站接收的所述MIB来对上行链路定时的期望获取或期望导出。** <br>《未公开》 | 对应方法特征F未被公开，因此该装置单元也未被公开。 | 该装置特征对应方法特征F。由于对比文件未公开“预定时间段基于通过MIB对上行链路定时的期望获取或导出”这一方法特征，因此该装置特征也未被公开。 |
| **技术特征U：还包括：用于确定要在所述切换之后向所述第二基站发送数据的单元** <br>《未公开》 | 对应方法特征G未被公开，因此该装置单元也未被公开。 | 该装置特征对应方法特征G。由于对比文件未公开“确定要在切换后发送数据”这一方法步骤，因此实现该步骤的功能单元也未被公开。 |
| **技术特征V：用于基于确定在所述切换之后还没有从所述第二基站接收到所述MIB，确定所述MIB不存在的单元** <br>《未公开》 | 对应方法特征H未被公开，因此该装置单元也未被公开。 | 该装置特征对应方法特征H。由于对比文件未公开“基于未收到MIB而确定MIB不存在”这一方法步骤，因此实现该步骤的功能单元也未被公开。 |
| **技术特征W：用于将对所述调度请求的所述传输延迟所述预定时间段的单元。** <br>《未公开》 | 对应方法特征I未被公开，因此该装置单元也未被公开。 | 该装置特征对应方法特征I。由于对比文件未公开“延迟调度请求传输”这一方法步骤，因此实现该步骤的功能单元也未被公开。 |
| **技术特征X：还包括：用于至少部分地基于确定在所述切换之后已经接收到所述MIB，向所述第二基站发送所述调度请求的单元。** <br>《未公开》 | 对应方法特征J和M未被公开，因此该装置单元也未被公开。 | 该装置特征对应方法特征J和M。由于对比文件未公开“基于接收到MIB而发送调度请求”这一方法步骤，因此实现该步骤的功能单元也未被公开。 |
| **技术特征Y：还包括：用于在所述预定时间段到期之后，确定是否已经接收到所述MIB的单元** <br>《未公开》 | 对应方法特征K未被公开，因此该装置单元也未被公开。 | 该装置特征对应方法特征K。由于对比文件未公开“在时间段到期后确定是否收到MIB”这一方法步骤，因此实现该步骤的功能单元也未被公开。 |
| **技术特征Z：用于响应于确定来自所述第二基站的所述MIB继续不存在，将对所述调度请求的所述传输进一步延迟第二预定时间段的单元。** <br>《未公开》 | 对应方法特征L未被公开，因此该装置单元也未被公开。 | 该装置特征对应方法特征L。由于对比文件未公开“响应于MIB继续不存在而进一步延迟”这一方法步骤，因此实现该步骤的功能单元也未被公开。 |
<<<a>>>