对比文件名称：WO2009133599A1_Description_20260623_2358
目标专利名称：1884在无线通讯系统中改善等待时间的方法及装置CN103096472B
本次调用的模型名称：无
## 特征比对表格
| 技术特征描述及公开性判断结果 | 对比文件原文引用 | 公开性论述 |
| 技术特征A：包括在一使用者设备中接收一消息。《直接公开》 | 对比文件说明书第1实施方式中记载：“在这种情况下，eNB向UE通知作为Msg4的表示不允许连接（拒绝或保留）的消息‘RRC connection reject’。” | 对比文件明确描述了UE接收来自eNB的RRC connection reject消息（Msg4），该接收动作属于“在一使用者设备中接收一消息”，且该消息是后续流程的起点，与技术特征A完全一致，因此被直接公开。 |
| 技术特征B：其中该消息用以指示一eWaitTime。《未公开》 | 同一段落中记载：“该消息可以包括关于应重新执行RA的定时（等待时间）的信息。” | 对比文件仅公开了消息中包含普通等待时间（待機時間），未涉及与机器类型通信、延迟容忍或低优先级相关的eWaitTime概念，也未说明该等待时间用于避免核心网过载或具有延长特性。因此，本领域技术人员无法从对比文件直接得出或合理推断出“eWaitTime”这一特定参数，技术特征B未被公开。 |
| 技术特征C：该使用者设备进入对应于该eWaitTime的一等待时间；并且使用者设备在该等待时间内不允许启动一延迟容忍或低优先级的无线电资源控制连接请求。《未公开》 | 对比文件后续描述UE行为时提及：“UE在接收RRC connection reject后，进入等待时间（待機時間），且在此期间无法发起随机接入（即不能建立RRC连接）。”但未限定原因类型。 | 对比文件虽公开了进入等待时间及不允许启动连接请求（通过退避机制），但所依赖的等待时间并非对应于eWaitTime，且禁止的是所有连接请求而并非仅针对“延迟容忍或低优先级”原因。该特定原因限制是目标专利的核心差异点，对比文件未给出任何启示，故技术特征C未被公开。 |
| 技术特征D：当该使用者设备在该等待时间内收到传呼该使用者设备的一传呼消息时。《未公开》 | 对比文件全文中未出现“传呼（paging）消息”及其在等待时间内被接收的场景。 | 对比文件仅涉及随机接入过程中的RRC连接拒绝与后续重试，未涉及寻呼流程，更没有在等待时间内处理寻呼消息的任何描述或暗示，因此技术特征D未被公开。 |
| 技术特征E：将该等待时间视为结束。《未公开》 | 对比文件未记载因接收寻呼消息而结束等待时间的技术内容。 | 对比文件没有公开在等待时间内因外部事件（寻呼）而终止等待时间的机制，故技术特征E未被公开。 |
| 技术特征F：还包括响应传呼该使用者设备的该传呼消息。《未公开》 | 对比文件未提及响应寻呼消息的任何行为。 | 对比文件未公开响应寻呼消息这一前提，技术特征F作为其后续动作的前提条件未被公开。 |
| 技术特征G：该使用者设备启动一连接建立程序。《未公开》 | 对比文件描述了在等待时间结束后UE可重新发起随机接入（属于连接建立），但启动时机并非响应寻呼消息。 | 技术特征G明确要求“响应传呼该使用者设备的该传呼消息”启动连接建立程序，对比文件没有公开通过寻呼触发连接建立的方案，故技术特征G未被公开。 |
| 技术特征H：其中该连接请求中指出的原因为延迟容忍或低优先级。《未公开》 | 对比文件未涉及连接请求消息中的原因值（EstablishmentCause）设置。 | 对比文件没有公开在RRC连接请求消息中填写延迟容忍或低优先级原因，因此技术特征H未被公开。 |
| 技术特征I：其中在该等待时间内《未公开》 | 该特征为上下文限定语，本身不构成独立技术方案；结合特征J、K，对比文件无任何关于紧急呼叫例外处理的记载。 | 对比文件未公开在等待时间内允许紧急请求且不影响等待时间的机制，故技术特征I（作为限定部分）未被公开。 |
| 技术特征J：允许该使用者设备启动一原因为紧急情况的无线电资源控制连接请求。《未公开》 | 对比文件未提及紧急情况下的特殊处理。 | 对比文件没有公开在等待时间内对紧急呼叫的优先级处理，技术特征J未被公开。 |
| 技术特征K：而该等待时间不受影响。《未公开》 | 对比文件无相关描述。 | 对比文件未公开紧急连接请求不影响等待时间的特性，故技术特征K未被公开。 |
| 技术特征L：其中在该使用者设备接收不是传呼该使用者设备的一传呼消息时《未公开》 | 对比文件未涉及对非自身寻呼消息的区分处理。 | 对比文件没有关于寻呼消息的任何处理逻辑，更无区分是否自己的寻呼消息，故技术特征L未被公开。 |
| 技术特征M：该使用者设备并不将该等待时间视为结束。《未公开》 | 对比文件无相关描述。 | 对比文件未公开对非自身寻呼消息不结束等待时间的限制，故技术特征M未被公开。 |
| 技术特征N：其中该消息为无线电资源控制连接拒绝消息或无线电资源控制连接解除消息。《直接公开》 | 对比文件说明书第1实施方式中明确记载：“消息‘RRC connection reject’（无线电资源控制连接拒绝消息）”。 | 对比文件直接公开了RRC connection reject这一具体消息类型，而技术特征N包含的两种可选方案中，RRC连接拒绝消息已被明确记载，因此至少该方案被直接公开，技术特征N整体被直接公开。 |
| 技术特征O：其中该传呼消息包含一过载信息用以指示一核心网络过载结束。《未公开》 | 对比文件未涉及寻呼消息，更无包含核心网过载结束信息的描述。 | 对比文件未公开任何关于寻呼消息携带过载指示的技术内容，故技术特征O未被公开。 |
| 技术特征P：其中将该等待时间视为结束包括该使用者设备停止一对应该等待时间的定时器。《未公开》 | 对比文件未描述定时器停止的操作。 | 对比文件没有公开通过停止定时器来实现等待时间结束的具体方式，故技术特征P未被公开。 |
| 技术特征Q：其中该等待时间是由一定时器所控制。《隐含公开》 | 对比文件说明书第1实施方式中记载：“该消息可以包括关于应重新执行RA的定时（等待时间）的信息。”虽未明确定时器，但“定时”一词隐含了时间测量手段。 | 在无线通信技术领域中，实现等待时间的标准方式就是使用定时器（如T302、T300等），本领域技术人员阅读对比文件后，结合公知常识，可以合理推断该等待时间必然由内部定时器控制。因此技术特征Q被隐含公开。 |
| 技术特征R：其中在接收到该eWaitTime后则开始该等待时间。《隐含公开》 | 对比文件记载：“UE接收包含等待时间信息的RRC connection reject后，进入等待时间（待機时间）。” | 尽管对比文件未使用术语“eWaitTime”，但其公开的机制是：UE在接收到指示等待时间的消息后立即开始等待。本领域技术人员可以合理认为，该等待时间的起点就是接收指示信息的时刻，与技术特征R“接收到等待时间指示后开始等待”实质相同，故技术特征R被隐含公开。 |
<<<A>>><<<N>>><<<q>>><<<r>>>