对比文件名称：2006-05-30_US7054630B_发明授权_US07054630B2 Selective processing of the common control channel
目标专利名称：1917无线通讯系统管理队列功能的方法及其相关装置CN101309515B
本次调用的模型名称：AI语言模型
### 特征比对表格
| 技术特征描述及公开性判断结果 | 对比文件原文引用（中文翻译） | 公开性论述 |
| 技术特征A：启动上述小区更新程序<br>【直接公开】 | [0053] “步骤522：确定是否期望一个小区更新确认（CELL UPDATE CONFIRM）消息。小区更新确认消息是当远程站向基站请求小区更新消息时针对该远程站的响应。”<br>[0062] “当远程站向基站发送一个RRC消息（例如，信息或更新的请求）时，远程站转换到CCCH接收状态600。” | 对比文件明确记载远程站（客户端）向基站请求小区更新消息（即启动小区更新程序），并且该请求对应小区更新确认消息的期望。本领域技术人员可直接且毫无疑义地确定对比文件公开了“启动小区更新程序”这一技术特征，且作用与目标专利相同，均为发起小区更新流程。 |
| 技术特征B：于接收一包含等待时间信息元的小区更新确认讯息后，进入上述队列功能的等待状态<br>【未公开】 | 对比文件未提及“等待时间信息元”以及“队列功能的等待状态”。[0053]虽提及小区更新确认消息，但未描述其内容包含等待时间信息元，也未描述接收该消息后进入用于拥塞控制的等待状态。 | 对比文件涉及的是对CCCH消息的选择性处理，不涉及在拥塞时转移客户端到另一频率层并等待的队列功能。其“等待状态”概念（如CCCH等待状态802/805）是针对消息处理而非队列功能，且无等待时间信息元。因此，特征B未被直接或隐含公开。 |
| 技术特征C：其中上述队列功能是将客户端置于一小区传呼信道状态或一无线注册区域传呼信道状态中进行等待<br>【未公开】 | 对比文件未提及“小区传呼信道状态（CELL_PCH）”或“无线注册区域传呼信道状态（URA_PCH）”。[0033]等段落仅涉及CELL_FACH状态，并指出实施例针对该状态。 | 对比文件的核心在于优化CELL_FACH状态下的CCCH处理，完全未涉及队列功能将客户端置于CELL_PCH或URA_PCH状态。因此，特征C未被公开。 |
| 技术特征D：而且等待状态结束时客户端重新启动上述小区更新程序<br>【未公开】 | 对比文件未描述队列功能等待状态结束后的行为。[0060]提到远程站最终因小区重选或周期性小区更新定时器到期执行小区更新，但这并非队列功能等待状态结束所触发。 | 对比文件未定义与队列功能对应的等待状态及其结束条件，也未公开在等待状态结束时必然重新启动小区更新程序。特征D未被公开。 |
| 技术特征E：于处于上述等待状态期间，若发生传呼回应事件时，重新启动上述小区更新程序<br>【未公开】 | 对比文件未涉及“传呼回应事件”以及在该事件发生时于等待状态中重新启动小区更新。[0060]提到可能因小区重选或定时器到期执行更新，但无关传呼回应。 | 对比文件未提及传呼回应作为重新启动小区更新程序的触发条件，也未描述等待状态期间对此类事件的响应机制。因此，特征E未被公开。 |
| 技术特征F：其特征是，其另包含于重新启动上述小区更新程序时，停止定时器，上述定时器用来计时上述客户端所需停留在上述等待状态中的等待时间<br>【未公开】 | 对比文件在[0069]等处提及定时器，但其用途是“在接收到期望的RRC消息后设置，持续处理所有CCCH消息直到定时器超时”，与队列功能的等待时间定时器无关。未提到在重新启动小区更新时停止该定时器。 | 对比文件的定时器用于处理重复消息的完整性保护，并非用于计时队列功能中的等待时间，也未涉及在重新启动小区更新时停止该定时器。因此，特征F未被公开。 |
<<<A>>>