对比文件名称：2013-02-21_CA2844629A_发明专利_CA2844629A1 HANDLING A CONNECTION IN A WIRELESS COMMUNICATION SYSTEM
目标专利名称：728用于信令优化的寻呼增强CN109417772B
本次调用的模型名称：未指定
### 特征比对表格
| 技术特征描述及公开性判断结果 | 对比文件原文引用（翻译成中文） | 公开性论述 |
| **技术特征A：** 包括：通过网络元件标识无线电资源控制连接恢复请求过程要由用户设备使用以作为对寻呼消息的响应。 **《未公开》** | 对比文件未描述网络元件标识特定过程（如RRC连接恢复请求）作为对寻呼消息的响应的内容。对比文件主要描述网络元件（eNB）发起寻呼以触发UE进行连接恢复或重新建立，但未涉及网络元件在寻呼前或寻呼中标识UE应使用的具体响应过程。 | 目标专利中，网络元件主动标识UE应使用的过程（如RRC连接恢复请求）以作为对寻呼的响应，并可能基于上下文可用性进行选择。对比文件（例如[0035]至[0045]）描述了UE在收到寻呼后，根据自身上下文有效性决定发送RRC连接恢复请求或进行RRC连接建立，但网络元件并未标识或指定该过程。因此，对比文件既未直接公开也未隐含公开网络元件标识特定过程作为寻呼响应的技术方案。 |
| **技术特征B：** 在所述寻呼消息中，由所述网络元件向所述用户设备隐式地指示使用所述无线电资源控制连接恢复请求过程。 **《未公开》** | 对比文件未描述在寻呼消息中包含隐式指示以告知UE使用RRC连接恢复请求过程。对比文件中的寻呼消息仅用于触发UE响应，不包含过程指示。 | 目标专利的核心创新在于扩展寻呼消息以隐式指示响应过程。对比文件（例如图20、图21）中，寻呼消息仅作为触发信号，UE随后自行决定响应过程（如基于上下文有效性）。对比文件未教导或暗示在寻呼消息中通过任何隐式方式（如数据指示、优先级指示等）指示UE使用RRC连接恢复请求过程。因此，对比文件未公开此特征。 |
| **技术特征C：** 其中所述过程是基于所述用户设备的上下文的可用性来标识的。 **《未公开》** | 对比文件未描述网络元件基于上下文可用性来标识过程。对比文件描述了UE基于上下文可用性选择响应过程，但网络元件侧无此操作。 | 目标专利中，网络元件标识过程时考虑上下文可用性。对比文件（例如[0035]至[0036]）仅描述了UE侧在响应寻呼时基于上下文可用性选择过程（如上下文有效则发送恢复请求，无效则建立新连接）。网络元件（eNB）在发起寻呼时，虽然可能知道上下文状态，但并未基于此标识或指示UE使用特定过程。因此，对比文件未公开网络元件基于上下文可用性标识过程的技术特征。 |
| **技术特征D：** 其中所述隐式地指示包括使用经由控制平面的数据、经由用户平面的数据、正常数据、小数据、短连接、高优先级数据、低优先级数据或信令中的至少一种。 **《未公开》** | 对比文件未描述在寻呼消息中使用任何隐式指示（如数据特性、优先级等）来指示响应过程。 | 目标专利列举了多种隐式指示方式。对比文件全文未涉及在寻呼消息中携带此类指示。对比文件中的寻呼消息仅包含标准寻呼信息（如UE标识），未包含用于指示响应过程的数据特性或优先级信息。因此，对比文件未公开此特征。 |
| **技术特征E：** 包括：在寻呼消息中，由用户设备从网络元件接收使用无线电资源控制连接恢复请求过程作为对所述寻呼消息的响应的隐式的指示。 **《未公开》** | 对比文件未描述UE从寻呼消息中接收隐式指示以使用RRC连接恢复请求过程。UE在收到寻呼后自主决定响应过程。 | 目标专利中，UE通过寻呼消息中的隐式指示获知应使用RRC连接恢复请求过程。对比文件（例如[0035]至[0045]）中，UE收到寻呼后，基于自身上下文有效性或预设规则（如始终尝试恢复）决定响应过程，而非基于寻呼消息中的任何指示。因此，对比文件未公开UE从寻呼消息接收隐式指示的特征。 |
| **技术特征F：** 使用所述无线电资源控制连接恢复请求过程来对所述寻呼消息进行响应。 **《直接公开》** | “UE 101发起RRC连接恢复过程，通过发送RRC连接恢复请求（RRC Connection Reactivation Request）来响应寻呼消息。”（参见[0035]：Figure 17 shows... The need for an active RRC Connection is triggered by... the reception of a paging or DL data notification message... The UE 101 initiates an RRC Connection Reactivation procedure by sending an RRC Connection Reactivation Request.） | 对比文件[0035]明确描述了UE在接收到寻呼消息后，通过发送RRC连接恢复请求（RRC Connection Reactivation Request）来启动RRC连接恢复过程。该过程与目标专利中的“无线电资源控制连接恢复请求过程”本质相同，均用于恢复挂起的RRC连接。因此，对比文件直接公开了UE使用RRC连接恢复请求过程对寻呼消息进行响应的技术特征。 |
| **技术特征G：** 其中对所述寻呼消息进行响应包括在所述寻呼消息中没有显式指示的情况下，基于服务小区中的所述用户设备的上下文的可用性对信令过程的选择。 **《直接公开》** | “UE确定其挂起的RRC连接在当前服务小区中有效（3），然后发起RRC连接恢复过程（4）。”（参见[0035]：The UE 101 determines that its suspended RRC Connection is valid for the cell on which it is located (3). The UE 101 initiates an RRC Connection Reactivation procedure by sending an RRC Connection Reactivation Request (4).）”<br>“UE确定其挂起的RRC连接无效（3），释放挂起的连接并进入空闲模式（4），然后发起正常的RRC连接建立过程（5）。”（参见[0036]：The UE 101 determines that its suspended RRC Connection is not valid for the cell on which it is located (3). The UE 101 releases its suspended RRC Connection and enters the RRC idle state (4). The UE 101 then initiates a normal procedure for establishing an RRC Connection...） | 对比文件[0035]和[0036]明确描述了UE在收到寻呼后，在没有显式指示的情况下，基于服务小区中上下文的可用性选择信令过程：上下文有效时选择RRC连接恢复请求过程，上下文无效时选择RRC连接建立过程。这与目标专利的特征G完全一致，均体现了无显式指示时基于上下文可用性进行过程选择。因此，对比文件直接公开了此技术特征。 |
**结论：**
- 对比文件直接公开了技术特征F和G。
- 对比文件未直接公开或隐含公开技术特征A、B、C、D、E。
<<<F>>><<<G>>>