对比文件的名称：2005-03-31_US2005070274A_发明申请_US20050070274A1 Apparatus and method for handling cell update during reconfiguration in universal mobile telecommunications system user equipment
目标专利的名称：1917无线通讯系统管理队列功能的方法及其相关装置CN101309515B
本次调用的模型名称：AI专利评估助手
### 特征比对表格
| 技术特征描述及公开性判断 | 对比文件原文引用（中文翻译） | 公开性论述 |
| 技术特征A：启动上述小区更新程序 《直接公开》 | [0015]“检测指示需要小区更新的触发事件”；[0047]“UE发送CELL UPDATE命令给UTRAN”。 | 对比文件明确描述了小区更新程序的启动过程：通过触发事件检测（如无线链路失败）启动小区更新程序，并发送CELL UPDATE消息。该步骤与目标专利的“启动小区更新程序”作用完全相同，均为小区更新流程的起始环节。本领域技术人员能毫无疑义地得出该技术特征，因此直接公开。 |
| 技术特征B：于接收一包含等待时间信息元的小区更新确认讯息后，进入上述队列功能的等待状态 《未公开》 | [0047]“UTRAN随后发送带有新配置Y的CELL UPDATE CONFIRM消息，并自身应用配置Y。” | 对比文件虽涉及CELL UPDATE CONFIRM消息，但其中仅包含新配置Y，未公开任何“等待时间信息元”。对比文件全文均未提及“队列功能”或“等待状态”，也没有揭示客户端在收到确认消息后进入特定等待状态的概念。目标专利中该特征用于频率层拥塞时的队列处理，而对比文件聚焦于重配置与小区更新的冲突处理，作用完全不相同。因此未直接或隐含公开。 |
| 技术特征C：其中上述队列功能是将客户端置于一小区传呼信道状态或一无线注册区域传呼信道状态中进行等待 《未公开》 | [0009]“一旦发生触发事件，UE移动至cell_FACH状态并发送CELL UPDATE请求消息。” | 对比文件在小区更新过程中明确指示UE进入cell_FACH状态，而非目标专利所要求的CELL_PCH或URA_PCH状态。对比文件没有给出任何关于将客户端置于传呼状态进行等待的教导或暗示，队列功能本身也未出现。因此未公开。 |
| 技术特征D：而且等待状态结束时客户端重新启动上述小区更新程序 《未公开》 | [0049]-[0050]行为B1：将小区更新延迟至重配置激活时间，待应用配置X后立即启动小区更新。 | 对比文件中的行为B1虽然将小区更新推迟到激活时间后执行，但该推迟并非因为“等待状态结束”，而是为了等待激活时间到达；且执行后直接发送CELL UPDATE，不涉及等待状态与重启的关联。目标专利中等待状态结束时重启小区更新是队列功能的自然环节，而对比文件无等待状态概念。因此未公开。 |
| 技术特征E：于处于上述等待状态期间，若发生传呼回应事件时，重新启动上述小区更新程序 《未公开》 | [0008]列举触发事件为：“无线链路失败、重新进入服务区、RLC不可恢复错误、小区重选和周期性小区更新”。 | 对比文件明确列出的触发事件不包括“传呼回应”。在目标专利中，传呼回应（如来电）是在等待状态期间可立即触发重新启动的唯一事件，作用在于防止耽搁重要信令。对比文件虽在多种行为中处理触发事件，但未提及传呼回应，更未在等待状态背景下讨论。因此未公开。 |
| 技术特征F：其特征是，其另包含于重新启动上述小区更新程序时，停止定时器，上述定时器用来计时上述客户端所需停留在上述等待状态中的等待时间 《未公开》 | [0056]-[0058]行为B1：控制器接收重配置命令，在定时器单元设定激活时间，等待激活时间到达后应用配置并启动小区更新。 | 对比文件中的定时器单元用于计时重配置激活时间，一旦激活时间到达即执行配置，本质与等待时间定时器无关。目标专利中的定时器专门用于队列功能的等待时间，在重新启动小区更新时停止，其作用是控制等待时长。对比文件没有公开任何与等待时间相关的定时器，也没有停止定时器的步骤。因此未公开。 |
### 公开性代码
<<<A>>>