好的，作为一名经验丰富的资深专利代理师，我将严格遵循您的指示，对目标专利的权利要求技术特征与对比文件进行严谨的比对分析。
### 对比文件名称：
2016-02-09_US9258839B_发明授权_US09258839B2 Other network component receiving RRC configuration information from eNB
### 目标专利名称：
728用于信令优化的寻呼增强CN109417772B
### 本次调用的模型名称：
（此信息由您提供，我无法知晓，但我会根据您的要求进行分析）
---
### 特征比对表格
| 技术特征描述以及公开性判断结果 | 对比文件原文引用 | 公开性论述 |
| **技术特征A：包括：通过网络元件标识无线电资源控制连接恢复请求过程要由用户设备使用以作为对寻呼消息的响应** <br><br> **《直接公开》** | **对比文件原文引用（翻译）**：<br>段落[0377]：RRC连接重新激活可以由UE101中生成的上行链路数据触发，或者由接收到指示网络有下行链路数据等待发送的寻呼或下行链路数据通知消息触发。当这种情况发生时，UE 101首先确定其挂起的RRC连接对于其当前所在的小区是否有效。<br><br>段落[0378]：UE 101确定其挂起的RRC连接对于其所在的小区是有效的（3）。UE 101通过发送RRC连接重新激活请求来发起RRC连接重新激活过程（4）。<br><br>段落[0374]：在接收到包含UE标识的寻呼消息后，UE 101将尝试恢复其挂起的RRC连接，如下所述。<br><br>段落[0375]：当DL数据到达网络时...eNB1 102a缓冲DL数据（4），然后向UE 101发送寻呼消息或数据到达通知消息（5）。当UE 101响应寻呼/通知时（例如，通过发送RRC重新激活请求），挂起的RRC连接可以被重新激活... | 对比文件明确公开了以下内容：<br>1. **网络元件**：对比文件中的网络元件可以理解为网络侧的整体行为，包括S-GW、MME和eNB等。当网络有下行数据到达时，网络侧（如MME/eNB）会发起寻呼（段落[0375]）。<br>2. **标识过程**：对比文件公开了UE在接收到寻呼后，会使用“RRC连接重新激活请求”（RRC Connection Reactivation Request）来响应寻呼（段落[0378]）。虽然对比文件没有明确使用“RRC连接恢复请求”这个术语，而是使用了“RRC连接重新激活请求”，但这两个术语在本领域是实质等同的，都指代在RRC连接被挂起后，用于恢复该连接的过程。因此，对比文件公开了网络侧（通过发起寻呼）隐含地标识了UE需要使用连接恢复/重新激活过程来响应。<br>3. **作用相同**：在对比文件中，该过程（RRC连接重新激活）的作用与目标专利中RRC连接恢复请求过程的作用完全相同，即作为对寻呼消息的响应，以恢复被挂起的RRC连接并进行数据传输（段落[0378]）。<br><br>因此，对比文件直接公开了技术特征A。 |
| **技术特征B：在所述寻呼消息中，由所述网络元件向所述用户设备隐式地指示使用所述无线电资源控制连接恢复请求过程。** <br><br> **《隐含公开》** | **对比文件原文引用（翻译）**：<br>段落[0374]：在接收到包含UE标识的寻呼消息后，UE 101将尝试恢复其挂起的RRC连接，如下所述。<br><br>段落[0377]：RRC连接重新激活可以由UE101中生成的上行链路数据触发，或者由接收到指示网络有下行链路数据等待发送的寻呼或下行链路数据通知消息触发。<br><br>段落[0319]：在RRC连接挂起后，UE 101以与正常空闲模式UE 101类似的方式执行小区选择和重选。此外，UE 101可以以与空闲模式完全相同的方式监听寻呼信道...在接收到包含UE标识的寻呼消息后，UE 101将尝试恢复其挂起的RRC连接。 | 对比文件没有明确描述网络在寻呼消息中通过一个显式的信息单元（IE）来指示UE使用哪种过程。但是，对比文件隐含公开了该特征，理由如下：<br>1. **逻辑推理**：对比文件建立了一个完整的RRC连接挂起和恢复机制。当UE处于RRC连接挂起状态时，它执行空闲模式行为（如监听寻呼）（段落[0319]）。<br>2. **隐含指示**：在对比文件的上下文中，当UE处于RRC挂起状态时，网络向其发送寻呼消息，这一行为本身就被UE理解为一种隐式的指示，即：网络有下行数据要发送，并且期望UE使用“RRC连接重新激活”（即恢复）过程来响应，而不是从头开始建立一个新的RRC连接（段落[0374], [0377]）。因为如果网络期望一个全新的连接，它会通过其他方式（如空闲模式下的寻呼）触发标准的RRC连接建立过程。因此，对于处于“RRC挂起”状态的UE，接收到寻呼消息本身就隐式地指示了应使用连接恢复过程。<br>3. **部分公开**：对比文件公开了网络发起寻呼和UE以RRC连接重新激活过程响应这一整套信令流程，这构成了隐式指示的基础。本领域技术人员可以合理推断，在寻呼消息本身不需要增加新字段的情况下，通过UE的状态（挂起态）和寻呼消息的结合，就完成了对使用恢复过程的隐式指示。<br><br>因此，对比文件隐含公开了技术特征B。 |
| **技术特征C：其中所述过程是基于所述用户设备的上下文的可用性来标识的。** <br><br> **《直接公开》** | **对比文件原文引用（翻译）**：<br>段落[0377]：当这种情况发生时，UE 101首先确定其挂起的RRC连接对于其当前所在的小区是否有效。<br><br>段落[0378]：UE 101确定其挂起的RRC连接对于其所在的小区是有效的（3）。UE 101通过发送RRC连接重新激活请求来发起RRC连接重新激活过程（4）。<br><br>段落[0379]：在这种情况下，UE 101确定其挂起的RRC连接对于其所在的小区是无效的（3）（例如，如果UE 101位于未指定的有效区域内，或者有效性计时器已过期）。UE 101释放其挂起的RRC连接并进入RRC空闲状态（4）。然后，UE 101启动用于建立RRC连接和建立用户平面无线承载的正常过程（即UE启动NAS服务请求过程）（5）。<br><br>段落[0310]：CN节点（例如MME 103b和/或S-GW 103a）可以为每个UE维护一个有效性指示符...位置有效性标准可以包括例如记录最初从中接收RRC挂起通知的小区或eNB...基于计时器的有效性标准可以包括... | 对比文件明确且直接地公开了该技术特征：<br>1. **上下文可用性**：对比文件中的“挂起的RRC连接有效”与目标专利中的“用户设备的上下文可用”是实质等同的概念。有效的挂起连接意味着UE上下文（即RRC连接信息）在服务小区（或网络侧）可用或可以取回（段落[0377]）。<br>2. **基于该可用性标识过程**：对比文件明确描述了UE的行为是基于“挂起的RRC连接是否有效”这一判断来决定的。如果有效，则使用“RRC连接重新激活请求”过程（即连接恢复过程）（段落[0378]）；如果无效，则释放挂起的连接并走正常的RRC连接建立过程（段落[0379]）。这完全符合技术特征C描述的“基于用户设备的上下文的可用性来标识”要使用的过程。<br>3. **作用相同**：在对比文件中，上下文的有效性是决定使用恢复过程还是建立新过程的关键因素，这与目标专利中上下文可用性作为选择（标识）过程依据的作用完全相同。<br><br>因此，对比文件直接公开了技术特征C。 |
| **技术特征D：其中所述隐式地指示包括使用经由控制平面的数据、经由用户平面的数据、正常数据、小数据、短连接、高优先级数据、低优先级数据或信令中的至少一种。** <br><br> **《未公开》** | **对比文件原文引用（翻译）**：<br>对比文件通篇未提及在寻呼消息中，通过指示数据类型（如CP数据、UP数据、小数据等）来隐式指示UE应使用何种响应过程。 | 对比文件公开了RRC连接挂起和恢复机制，但并未公开或暗示技术特征D中列举的任何隐式指示方式。对比文件中的隐式指示是基于UE的状态（挂起态）和寻呼事件本身来触发的，而不是通过区分寻呼消息所关联的数据类型来实现的。对比文件没有描述任何关于“经由控制平面的数据”、“小数据”、“高优先级数据”等作为隐式指示手段的内容。因此，对比文件既未直接公开，也未隐含公开技术特征D。 |
| **技术特征E：包括：在寻呼消息中，由用户设备从网络元件接收使用无线电资源控制连接恢复请求过程作为对所述寻呼消息的响应的隐式的指示** <br><br> **《隐含公开》** | **对比文件原文引用（翻译）**：<br>段落[0374]：在接收到包含UE标识的寻呼消息后，UE 101将尝试恢复其挂起的RRC连接，如下所述。<br><br>段落[0377]：RRC连接重新激活可以由...接收到指示网络有下行链路数据等待发送的寻呼...触发。 | 基于与技术特征B相同的理由，对比文件隐含公开了技术特征E。<br>1. **UE接收隐式指示**：对比文件公开了UE在挂起状态下接收寻呼消息（段落[0374]）。<br>2. **推理**：在对比文件构建的系统中，当一个处于“RRC挂起”状态的UE在寻呼时机接收到一个包含其标识的寻呼消息时，该UE会逻辑地推断出网络期望它使用“RRC连接重新激活”（即恢复）过程来响应（段落[0374], [0377]）。这个推断是合理的，因为如果网络期望一个全新的连接，通常会在空闲模式下发起寻呼并通过后续的RRC连接建立流程来完成。因此，对于挂起状态的UE，寻呼本身就是一个隐式的指示，告诉它“使用恢复过程”。<br>3. **部分公开**：对比文件完全公开了“挂起态UE接收寻呼”和“UE使用重新激活过程响应”这两个端点事件，本领域技术人员可以很容易地将两者关联起来，推导出寻呼消息在此场景下起到了隐式指示的作用。<br><br>因此，对比文件隐含公开了技术特征E。 |
| **技术特征F：使用所述无线电资源控制连接恢复请求过程来对所述寻呼消息进行响应。** <br><br> **《直接公开》** | **对比文件原文引用（翻译）**：<br>段落[0378]：UE 101确定其挂起的RRC连接对于其所在的小区是有效的（3）。UE 101通过发送RRC连接重新激活请求来发起RRC连接重新激活过程（4）。<br><br>段落[0374]：在接收到包含UE标识的寻呼消息后，UE 101将尝试恢复其挂起的RRC连接...<br><br>图17（及其描述）：UE 101发起RRC连接重新激活过程，通过发送RRC连接重新激活请求（4）。 | 对比文件直接且明确地公开了该技术特征：<br>1. **响应寻呼**：对比文件明确描述了RRC连接重新激活过程可以由接收到寻呼消息触发（段落[0377]）。<br>2. **使用恢复请求过程**：对比文件明确描述了UE使用“RRC连接重新激活请求”消息来发起重新激活过程（段落[0378]）。如前所述，“RRC连接重新激活请求”与本技术特征中的“无线电资源控制连接恢复请求过程”是实质等同的。<br>3. **作用相同**：在对比文件中，UE使用该过程是直接响应网络寻呼并恢复连接，这与目标专利中的作用完全相同。<br><br>因此，对比文件直接公开了技术特征F。 |
| **技术特征G：其中对所述寻呼消息进行响应包括在所述寻呼消息中没有显式指示的情况下，基于服务小区中的所述用户设备的上下文的可用性对信令过程的选择。** <br><br> **《直接公开》** | **对比文件原文引用（翻译）**：<br>段落[0377]：当这种情况发生时，UE 101首先确定其挂起的RRC连接对于其当前所在的小区是否有效。<br><br>段落[0378]：UE 101确定其挂起的RRC连接对于其所在的小区是有效的（3）。UE 101通过发送RRC连接重新激活请求来发起RRC连接重新激活过程（4）。<br><br>段落[0379]：在这种情况下，UE 101确定其挂起的RRC连接对于其所在的小区是无效的（3）...UE 101释放其挂起的RRC连接并进入RRC空闲状态（4）。然后，UE 101启动用于建立RRC连接...的正常过程（5）。 | 对比文件直接且明确地公开了该技术特征：<br>1. **无显式指示**：对比文件描述的响应流程中，寻呼消息本身并不包含一个显式的指示来告诉UE使用哪个过程。UE的行为是基于其内部状态和上下文有效性判断的。<br>2. **基于上下文可用性选择**：这是对比文件的核心机制之一。UE在响应寻呼前，首先要判断其“挂起的RRC连接”（即上下文）在当前服务小区是否有效（段落[0377]）。<br> - 如果上下文有效（可用），UE选择“RRC连接重新激活请求”过程（段落[0378]）。<br> - 如果上下文无效（不可用），UE选择常规的“RRC连接建立”过程（段落[0379]）。<br>这完全符合技术特征G的描述：在没有显式指示的情况下，基于服务小区中用户设备上下文的可用性，对信令过程（恢复过程 vs. 建立新连接过程）做出选择。<br>3. **作用相同**：对比文件中这种基于上下文可用性的选择机制，与目标专利中描述的场景和作用完全一致。<br><br>因此，对比文件直接公开了技术特征G。 |
---
<<<A>>>
<<<C>>>
<<<F>>>
<<<G>>>
<<<b>>>
<<<e>>>