**对比文件名称**：2012-02-16_CA2808232A_发明专利_CA2808232A1 HANDOVER LATENCY REDUCTION
**目标专利名称**：347在切换之后延迟对调度请求的触发CN106105313B
**本次调用的模型名称**：DeepSeek
根据目标专利说明书对技术特征的解释，以及对比文件CA2808232A1的内容，现创建特征比对表格如下：
| 技术特征描述以及公开性判断结果 | 对比文件原文引用 | 公开性论述 |
| **技术特征A**《直接公开》 | [0055] “Inter-RAT HO to E-UTRA... The handover to E-UTRAN procedure shown in Figure 3 may be used when the network hands over the UE from another RAT to E-UTRA.” <br> [0057] “...the RAN using another RAT initiates the handover-to-E-UTRA procedure...” | 对比文件明确描述了从源RAT（第一基站）到目标E-UTRA网络（第二基站）的切换过程，本领域技术人员可以毫无疑义地得出UE确定发生了切换。该内容在对比文件中用于描述切换流程，与目标专利中确定切换发生的技术特征作用相同。 |
| **技术特征B**《未公开》 | 无直接对应内容。对比文件涉及在切换后获取MIB以确定SFN极性，从而允许UE尽早发起随机接入（RACH），而非延迟调度请求（SR）。 | 对比文件的核心目的是**减少**切换延迟，教导UE在可能的情况下（如同步时）**避免等待MIB**即可发起随机接入。这与目标专利“基于未收到MIB而延迟SR传输”的技术方案构思相反。本领域技术人员无法从对比文件直接或隐含地得出该技术特征。 |
| **技术特征C**《未公开》 | 无直接对应内容。 | 技术特征C是特征B和D的上位概括，即延迟SR直到条件满足。由于对比文件未公开基于未收到MIB而延迟SR，也未将“接收到MIB”作为发送SR的延迟条件，因此该特征未被公开。 |
| **技术特征D**《未公开》 | [0061] “...if the determination to block 404 is ‘no,’ then the UE obtains the MIB by decoding the PBCH...” <br> [0073] “If ‘no’, then the UE determines whether the RANs are synchronized... If ‘yes’, then the UE determines the SFN polarity... If the RANs are not synchronized, then the UE obtains the MIB...” | 对比文件公开了在特定条件（PRACH资源非全帧配置且网络未同步）下，UE需要获取MIB。但获取MIB的目的是为了**确定系统帧号（SFN）极性**，以便在正确的帧上进行**随机接入（RACH）**。目标专利中“接收到MIB”是触发**调度请求（SR）** 的条件。SR和RACH是两种不同的上行链路资源请求机制。对比文件未将“接收到MIB”与“发送SR”相关联。 |
| **技术特征E**《未公开》 | 无直接对应内容。 | 对比文件全文未提及在切换前接收系统信息块（SIB）。其关注点在于切换后对MIB的获取或SFN极性的确定，以进行随机接入。 |
| **技术特征F**《未公开》 | 无直接对应内容。对比文件提到了MIB的传输时间（如PBCH TTI为40ms），但未将其与一个“预定时间段”相关联，也未将该时间段定义为“对上行链路定时的期望获取或期望导出”。 | 目标专利中“预定时间段”是专门为延迟SR触发而设置的，且其长度基于通过MIB获取上行链路定时的期望时间。对比文件未公开为延迟SR而设置此类时间段。 |
| **技术特征G**《隐含公开》 | [0058] “...it may be desirable for the UE to know whether the current SFN is even or odd before it can access the target E-UTRA cell after handover.” <br> [0063] “...a desire to minimize HO latency and interruption time.” | 对比文件多次提到UE在切换后需要“接入（access）”目标小区，并旨在最小化中断时间。接入目标小区的目的通常是为了进行通信，包括发送上行数据。本领域技术人员可以合理推断，UE在切换后决定发起随机接入过程，其背后隐含的原因是**有数据需要发送**。这是一种隐含公开。 |
| **技术特征H**《未公开》 | 无直接对应内容。 | 对比文件描述了在未同步且PRACH非全帧配置时，UE需要获取MIB。但并未描述UE主动进行一个“确定MIB不存在”的判断步骤。其流程是：如果未同步，则去获取MIB。这是一种条件分支，而非基于“未接收到MIB”状态的主动判断。 |
| **技术特征I**《未公开》 | 无直接对应内容。 | 该特征是特征B的执行动作。由于特征B（基于未收到MIB而决定延迟）未被公开，因此执行延迟动作的特征I也未被公开。 |
| **技术特征J**《未公开》 | 无直接对应内容。 | 对比文件通篇讨论在获取MIB或确定SFN极性后，UE执行的是**随机接入（RA/RACH）**。目标专利中“发送调度请求（SR）”是一种不同的、通常更高效的资源请求方式。对比文件未提及“调度请求（SR）”的触发或发送。 |
| **技术特征K**《未公开》 | 无直接对应内容。 | 对比文件未描述设置一个“预定时间段”并在其到期后检查MIB是否接收的循环或判断流程。 |
| **技术特征L**《未公开》 | 无直接对应内容。 | 对比文件未描述在第一次延迟后，因MIB继续不存在而进行第二次延迟的流程。 |
| **技术特征M**《未公开》 | 无直接对应内容。 | 同特征J，对比文件未提及“发送调度请求（SR）”。 |
| **技术特征N**《未公开》 | 无直接对应内容。 | 对比文件未提及在长时间未收到MIB时发起无线链路失败（RLF）过程。 |
| **技术特征O**《未公开》 | 无直接对应内容。对比文件提到了LTE帧长度为10ms，但未将其作为一个“预定时间段”的基础用于延迟SR。 | 目标专利将预定时间段与LTE帧数量关联，是其实施方案的具体化。对比文件未公开此具体关联。 |
| **技术特征P**《直接公开》 | 同技术特征A的引用。 | 装置特征“用于确定的单元”对应方法特征“确定”。由于方法特征A已被直接公开，本领域技术人员可以毫无疑义地得出，实现该方法的装置必然包含相应的功能单元。因此该装置特征被直接公开。 |
| **技术特征Q**《未公开》 | 无直接对应内容。 | 该装置特征对应方法特征B。由于方法特征B未被公开，因此该装置特征也未被公开。 |
| **技术特征R**《未公开》 | 无直接对应内容。 | 该装置特征对应方法特征C和D。由于方法特征C和D未被公开，因此该装置特征也未被公开。 |
| **技术特征S**《未公开》 | 无直接对应内容。 | 该装置特征对应方法特征E。由于方法特征E未被公开，因此该装置特征也未被公开。 |
| **技术特征T**《未公开》 | 无直接对应内容。 | 该装置特征对应方法特征F。由于方法特征F未被公开，因此该装置特征也未被公开。 |
| **技术特征U**《隐含公开》 | 同技术特征G的引用。 | 该装置特征“用于确定要发送数据的单元”对应方法特征G。由于方法特征G被隐含公开（UE在切换后发起接入隐含了有数据要发送），因此该装置特征也被隐含公开。 |
| **技术特征V**《未公开》 | 无直接对应内容。 | 该装置特征对应方法特征H。由于方法特征H未被公开，因此该装置特征也未被公开。 |
| **技术特征W**《未公开》 | 无直接对应内容。 | 该装置特征对应方法特征I。由于方法特征I未被公开，因此该装置特征也未被公开。 |
| **技术特征X**《未公开》 | 无直接对应内容。 | 该装置特征对应方法特征J。由于方法特征J未被公开，因此该装置特征也未被公开。 |
| **技术特征Y**《未公开》 | 无直接对应内容。 | 该装置特征对应方法特征K。由于方法特征K未被公开，因此该装置特征也未被公开。 |
| **技术特征Z**《未公开》 | 无直接对应内容。 | 该装置特征对应方法特征L。由于方法特征L未被公开，因此该装置特征也未被公开。 |
<<<A>>><<<P>>><<<g>>><<<u>>>