一种在移动电信系统内操作的用户设备中提供服务的方法，所述方法包括：在所述用户设备中运行客户端应用实例，其中所述客户端应用实例借助于包括轮询的协议经由网络与远程设置的服务器应用交互；发送消息到所述服务器应用，其中到所述服务器应用的所述消息包括唯一地标识所述用户设备和唯一地标识所述用户设备内的所述客户端应用实例的推送地址；由所述用户设备内的推送实体从推送服务器接收包括所述客户端应用实例的标识符的推送通知，并且使用所述客户端应用实例的标识符将所述推送通知引导到所述客户端应用实例，其中所述推送服务器响应于从所述服务器应用接收到推送请求而发送所述推送通知；响应于所述推送通知，所述客户端应用实例经由所述网络将轮询消息发送到所述服务器应用；所述客户端应用实例接收对所述轮询消息的响应，其中所述响应包括与所述服务相关的信息；并且在发送所述消息到所述服务器之后，但是在接收包括所述客户端应用实例的标识符的所述推送通知之前，在睡眠模式中操作所述客户端应用实例。

您好。作为一名经验丰富的专利代理师，我仔细阅读了您提供的权利要求文件、目标专利说明书以及对比文件 D1（WO2006070067A1）。现紧密结合目标专利说明书和对比文件原文，对权利要求1进行深入分析，并制定相应的无效策略建议。

### 第一部分：权利要求与对比文件特征比对

以下表格详细对比了权利要求1的技术特征与对比文件 D1 原文的对应情况，并指出了 D1 原文的详细出处。

**特征比对表**

---

### 第二部分：最接近对比文件的分析

**整体解决的技术问题：**

本发明（目标专利）和对比文件 D1 都旨在解决移动装置访问基于因特网的应用时，传统恒定轮询（PULL）技术导致过度消耗无线电资源和电池能量的问题。它们都提出了一种结合推送技术的方法，允许移动终端在没有频繁轮询的情况下及时获得状态改变或其他信息，从而既保持了 Web 应用的灵活性和交互性，又避免了资源的浪费。

**技术效果：**

两者实现的技术效果也高度一致，即通过引入推送机制，减少了用户设备的轮询频率。目标专利明确指出其效果是“避免了无线电和电池资源的过度使用”（目标专利说明书[0041]）。对比文件 D1 也强调其技术避免了现有推送技术（如SMS）的延迟、成本和合同问题，以及现有轮询技术的资源和带宽开销（D1原文 [p0034], [p0036]）。

**创造性分析中适合做最接近的对比文件的理由：**

基于上述分析，对比文件 D1 在创造性分析过程中非常适合作为**最接近的对比文件**。理由如下：

1. **技术领域相同：** 两者都属于移动电信系统、移动计算、因特网应用访问和推送消息技术领域。

2. **解决的技术问题相同：** 都致力于解决基于Web的移动应用中过度轮询导致的资源和能耗问题。

3. **技术方案高度契合：** 如特征比对表所示，D1 的主要技术特征（客户端-服务器架构、登录标识、服务器到客户端的推送、客户端响应推送发起的请求、休眠和保持存活机制）均能与权利要求1的相应特征对应或实质对应。D1完整地公开了一个能够实现权利要求1功能的系统架构和方法流程。

因此，在创造性分析中，D1 是建立无效策略的最佳起点。

---

### 第三部分：无效请求对于请求方来说最薄弱的技术特征分析

通过上述详细的比对分析，我认为若提出无效请求，对于请求方来说**最薄弱（即最难被证明已公开或被显而易见地引入）的技术特征是特征 F**，其次是特征 D。

#### **技术特征F：在发送所述消息到所述服务器之后，但是在接收包括所述客户端应用实例的标识符的所述推送通知之前，在睡眠模式中操作所述客户端应用实例。**

**薄弱理由分析：**

1. **D1公开程度的争议性：** D1 虽然提到了客户端“后台运行”[p0058]、可以使用“sleep that function”[p0070]，并对比了不需要客户端先前请求的推送技术[p0030]，但并未像目标专利那样清晰、明确地定义一种名为“睡眠模式”的操作模式，且这种模式具体被限定在发送消息后、接收推送前的时间段内，其主要特征是“不执行轮询”（目标专利说明书[0006], [0011], [0015], [0033]）。

* D1 中的“background”更接近多任务操作系统中的一个运行状态，不一定等同于资源消耗最小化的“睡眠模式”。

* D1 中的“sleep that function”出现在重新连接的上下文中，未必适用于在已建立稳定连接后等待推送的正常流程。

2. **目标专利对“睡眠模式”的特定定义：** 目标专利在背景技术[0006]中详细描述了轮询导致的无线电资源和电池能耗问题，并明确提出本发明的睡眠模式是为了解决此问题，即“减少终端的无线电接口停留在资源消耗状态中”。因此，目标专利中的“睡眠模式”是一个具有特定目的、明确定义的能耗优化状态，即在该模式下不进行常规的频繁轮询。

3. **对比文件是否显而易见：** 即使认为 D1 隐含了某种低能耗状态（由于推送技术的本质），但是否存在“将此状态显式定义为‘睡眠模式’，并将其具体限定在发送标识后、接收推送前”这一教导，在创造性判断上可能存在争议。目标专利通过明确定义此模式和时间段，强化了能耗优化的概念，这可能被认为具有创造性步骤。

因此，要证明特征 F 已被 D1 毫无异议地公开，或者在 D1 的基础上通过本领域普通技术人员的常规技能显而易见地得出，难度最大，是无效策略中的最弱环节。

#### **技术特征D：响应于所述推送通知，所述客户端应用实例经由所述网络将轮询消息发送到所述服务器应用。**

**薄弱理由分析（相对于特征A、B、C、E）：**

虽然 D1 公开了解析推送消息中的 URL 并启动 Web 浏览器访问该 URL 的过程 [p0072]，本质上是一种响应推送的拉取（PULL）操作。但 D1 的主导描述偏向于“ XPUSH”和“PROXY XPUSH”，即由服务器显式发送内容（URL 或网页）给客户端。特征 D 要求客户端在收到推送后主动发送一个“轮询消息”。虽然 D1 提到了“XPULL”过程，但那是由客户端启动的拉取，而不是对服务器推送的响应。要证明“响应于推送通知发送轮询消息”这一具体时序和操作模式，在 D1 中可能不如其他特征（如服务器发送推送、客户端接收响应等）那样毫无异议和清晰。

### 总结与建议

基于上述分析，如果我作为您的专利代理师处理此无效案件，我将采取以下策略：

1. **首选最接近对比文件：** 以 **WO2006070067A1 (D1)** 为核心，构建主要创造性无效理由。

2. **承认并利用已公开特征：** 在比对过程中，充分肯定特征 A、C、E 以及特征 B、D 的实质内容已被 D1 公开，减少不必要的争论。

3. **集中火力攻克薄弱特征：**

* **针对特征 F（最薄弱特征）：** 采取多角度论证。

* **实质公开角度：** 强调推送技术的本质就是让客户端在等待时无需先前请求（即不轮询），且 D1 的后台运行、低能耗keepalive和sleep功能实质上就是一种不进行常规轮询的睡眠状态。目标专利的定义仅是对现有技术状态的一种新标签，未产生预料不到的技术效果。

* **显而易见角度：** 即使特征 F 未被直接公开，但在移动设备能耗优化的大背景下，鉴于 D1 已公开推送机制和休眠尝试，本领域普通技术人员为了进一步优化 D1 系统的能耗，自然且显而易见地会引入更具体的能耗管理模式，包括在发送标识后进入不轮询的睡眠模式。

* **寻找补强证据：** 尝试寻找进一步公开移动应用“休眠模式”或专门针对推送机制进行能耗优化状态定义的公知常识或补强对比文件，通过与 D1 结合来无效特征 F。

* **针对特征 D：** 重点论证 D1 中浏览器响应 URL 发起 HTTP 请求的过程本质上就是响应推送通知发送轮询消息。强调“轮询消息”和常规 Web 请求在协议层面没有本质区别。

综上，特征 F 是无效请求方的最薄弱技术特征，但通过深入挖掘 D1 原文内涵、结合领域内能耗优化的普遍教导以及必要时的补强证据结合，仍有较大把握对其创造性提出有力挑战。

## 权利要求 1 的解释及其创造性分析

作为一名经验丰富的专利代理师，我将紧密结合目标专利说明书（CN101889424B）来解释权利要求 1 的技术特征，并通过与提供的对比文件进行详细比对和创造性分析。

### 第一部分：权利要求 1 技术特征的法律解释

权利要求 1 限定了一种在移动电信系统内的用户设备（UE）中提供服务的方法，旨在解决传统的“拉出（PULL）”技术（如 AJAX 的 XMLHttpRequest）中，客户端（如浏览器应用实例）必须频繁地轮询服务器以获取状态改变，从而导致无线电资源和电池能量过度消耗的问题（参见说明书背景技术 [0001]-[0006]）。

以下是对各技术特征的详细解释：

* **技术特征 A：在所述用户设备中运行客户端应用实例，其中所述客户端应用实例借助于包括轮询的协议经由网络与远程设置的服务器应用交互。**

* **解释：** 该特征限定了初始的操作模式。客户端应用实例（例如浏览器实例，参见说明书 [0009]、[0031]）与远程服务器应用（例如 web 应用）在常规模式下（步骤 205、207）承担客户端/服务器角色。所使用的协议“包括轮询”，这对应于说明书背景技术中描述的传统方式，客户端向服务器发起请求（拉出信息）（参见说明书 [0023]-[0024]）。

* **技术特征 B：发送消息到所述服务器应用，其中到所述服务器应用的所述消息包括唯一地标识所述用户设备和唯一地标识所述用户设备内的所述客户端应用实例的推送地址。**

* **解释：** 这是从常规轮询模式转换的关键步骤。客户端应用实例检测到由于信息不常改变，它应该停止轮询（根据策略）并进入睡眠模式（参见说明书 [0032]-[0033]）。为实现此目的，UE 发送一个消息（例如 HTTP 请求，参见说明书 [0010]）到服务器应用。该消息不仅包含标识 UE 的信息（如通常的 IP 地址），还包含一个“推送地址”，该地址特别地且“唯一地”标识该 UE 以及该 UE 内的“特定的”客户端应用实例（如特定的浏览器窗口或 AJAX 实例）。说明书 [0033]提到，这可能是通过请求用户设备内的推送实体供应移动推送地址和客户端实例标识符来获得的。

* **技术特征 C：由所述用户设备内的推送实体从推送服务器接收包括所述客户端应用实例的标识符的推送通知，并且使用所述客户端应用实例的标识符将所述推送通知引导到所述客户端应用实例，其中所述推送服务器响应于从所述服务器应用接收到推送请求而发送所述推送通知。**

* **解释：** 该特征描述了“推送”机制。服务器应用在确定需要向客户端供应服务相关信息（例如状态改变）时，它不再等待客户端的下一个轮询，而是利用之前储存的“推送地址”，向移动电信系统内的“推送服务器”发送“推送请求”（参见说明书 [0013]、[0036]）。推送服务器响应于该请求，向 UE 发送“推送通知”，该通知包含“客户端应用实例的标识符”。UE 内的“推送实体”（例如 WAP 推送实体或 SIP 推送实体，参见说明书 [0025]、[0029]）接收此通知，并根据其中的“客户端应用实例标识符”，将通知引导（或通知）到正确的（可能存在多个）客户端应用实例（参见说明书 [0038]）。

* **技术特征 D：响应于所述推送通知，所述客户端应用实例经由所述网络将轮询消息发送到所述服务器应用。**

* **解释：** 这是“被唤醒后的动作”。客户端应用实例在接收到（由推送实体引导的）推送通知后，重新进入常规操作模式（步骤 205），并将一个“轮询消息”发送到 web 应用，以主动请求更新的信息（参见说明书 [0039]）。

* **技术特征 E：所述客户端应用实例接收对所述轮询消息的响应，其中所述响应包括与所述服务相关的信息。**

* **解释：** 这是“拉出更新”。web 应用响应于上述轮询消息，将最新的服务相关信息（如更新的信息、状态改变等）发送给客户端应用实例（参见说明书 [0040]）。

* **技术特征 F：在发送所述消息到所述服务器之后，但是在接收包括所述客户端应用实例的标识符的所述推送通知之前，在睡眠模式中操作所述客户端应用实例。**

* **解释：** 这是实现减少资源消耗的“状态”。在步骤 B 发送包含推送地址的消息后，客户端应用实例主动转到（进入）“睡眠模式”，在此模式下它“不执行轮询”（参见说明书 [0034]）。直到在步骤 C 中通过推送机制“醒来”（离开睡眠模式）之前，它都保持在此模式，从而在没有信息更新期间节省了无线电资源和电池能量。

---

### 第二部分：对比文件特征比对及分析

我们将本申请权利要求 1 的技术特征与提供的三个对比文件（D1, D2, D3）进行比对。

**对比文件 1 (D1): US6381645B1**

* **出处：** "BACKGROUND OF THE INVENTION", "SUMMARY OF THE INVENTION", "FIG. 1", "DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT" (特别是第3页第2段、第3段, 第4页第2段)

* **公开内容：** D1 公开了一种在传统 Web 浏览器中实现推送技术的方法。它旨在允许远程代理控制客户浏览器显示的信息。

* 特征 A：D1 的“customer’s computer”运行“web browser program 54”，并通过“HTTP protocol”与“web server 52”交互（图 1）。背景技术提到浏览器不一定具有“push capability”（第3页第2段），隐含支持轮询。

* 特征 B：D1 的方法涉及在浏览器中下载并运行一个“JAVA™ applet 84”（摘要）。applet 维护与“push server 88”的“socket IP connection 86”。当客户登录（logs into）公司网站时，applet 被下载（第3页第2段、第4页第2段）。D1 确实公开了 applet 建立连接并可能发送标识，但没有具体公开发送的消息包括唯一标识 UE 和“唯一标识 UE 内客户端应用实例的推送地址”。D1 的标识通常是 IP 地址，重点在于 applet 维护连接。

* 特征 C：D1 公开了“push server 88 transmits a web address ... to the applet 84”（摘要）。applet 接收该地址（推送通知的一种形式）并将其转发给“browser program 54”，导致浏览器下载新页面（特征 C 的“接收...引导到客户端应用实例”的部分）。然而，D1 的推送服务器和 Web 服务器通常位于同一计算机，且其引导是直接由 applet 完成的，并没有明确区分“推送实体”（在 UE 内，处理多种协议）和“推送服务器”（响应 Web 服务器请求）之间的严格电信系统层面的架构关系，更重要的是，它不是基于唯一标识“应用实例标识符”来引导，而是基于 applet 本身维护的 socket 链接。

* 特征 D 和 E：D1 中 applet 转发地址给浏览器，浏览器“downloads the new page”（摘要），这相当于发送一个请求并接收响应。但这被描述为直接的“下载”新页面，而不是本申请中“客户端应用实例”在睡眠中通过专门的推送实体“被引导通知”后发起的特定“轮询消息”。D1 的 applet 更像是一个中介，而不是一个能在睡眠模式中被引导并随后发起轮询的“客户端应用实例”本身。

* 特征 F：D1 没有公开客户端应用实例在发送消息和接收推送通知之间处于“睡眠模式”。D1 的 applet 和浏览器是活跃的，尽管它们可能不主动请求新的页面，但它们并没有本申请中描述的为节省资源而“不执行轮询”的特定“睡眠模式”。D1 旨在解决即使浏览器未连接也能推送，而不是节省电池。

**对比文件 2 (D2): US7177628B2**

* **出处：** "SUMMARY OF THE INVENTION", "FIG. 4", "FIG. 9", "FIG. 10", "DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT" (特别是[0012], [0013], [0014], [0031])

* **公开内容：** D2 公开了一种为无线网络上的无线设备启用 IP 推送能力的方法。它旨在解决传统的 SMS “trigger-poll”方法（例如邮件服务器发送 SMS 通知，无线设备随后发起轮询）的缺点（例如实时性差，浪费网络资源）。

* 特征 A：D2 的“mobile device 102”可以通过无线网络浏览 Internet（[0026]）。虽然其主要示例是电子邮件（通过 SMS 通知拉取），但它涵盖了在数据可用时接收数据的系统（[0007]），隐含支持通过轮询协议交互的客户端应用实例（例如用于浏览的浏览器，尽管在 graceful degradation 模式下使用 trigger-poll）。

* 特征 B：D2 公开了“mobile device 102 opens a socket connection to the email server 202 and provides its IP address and other identification information ... After registers ... closes the socket”（摘要、[0036]）。D2 还公开了“sending a packet data protocol context request; receiving a response... includes context data comprising a packet data protocol address (IP address) assigned to the mobile terminal”（[0012]、[0029]）。虽然它发送标识信息（IP 地址、MIN 等，[0036]、[0038]），但并没有具体公开该消息“包括唯一地标识所述用户设备和唯一地标识所述用户设备内的所述客户端应用实例的推送地址”。D2 的标识主要用于建立 socket 连接，旨在关联邮件地址和 IP 地址以启用后续服务器发起的 socket 连接（[0009]），并不是标识特定的“客户端应用实例”以便推送实体引导。

* 特征 C：D2 公开了当有邮件时，内容提供商（通过中继服务器）向移动设备的 IP 地址发送“request for opening a communication channel (open socket request)”（[0030]、图 7）。这由网关服务器转发给移动设备（[0031]、图 8），移动设备响应并“opens the channel”（[0031]、图 9）。D2 公开了推送操作（通过服务器发起 socket），但它并没有公开由移动设备内的“推送实体”接收包含“应用实例标识符”的推送通知并进行引导。D2 的移动设备通过打开 socket 来响应，并不是通过推送实体引导到特定的活跃或睡眠中的客户端应用。

* 特征 D 和 E：D2 公开了在一般推送（启用 IP 推送）模式下，服务器发起 socket，移动设备通过打开 socket 响应，内容直接传输（[0031]、[0049]）。这不是响应于“推送通知”发起的特定“轮询消息”。只有在“优雅降级”模式下，移动设备接收 SMS 通知，获得新 IP 地址，发送“open socket request”到邮件服务器，并“requests a content download”（图 10、[0044]）。这虽然涉及基于通知的请求，但并非本申请特定的权利要求 1 的组合：基于应用实例标识引导的推送通知，随后客户端发起轮询。

* 特征 F：D2 的移动设备在注册后关闭 socket，但“维持 active the context data”（[0029]）。它没有公开“客户端应用实例”在发送消息后和接收通知前处于特定的“睡眠模式”，该模式下它“不执行轮询”（除了可能在 graceful degradation 下等待 SMS，但这不对应权利要求的具体流程）。

**对比文件 3 (D3): WO2007036779A1**

* **出处：** "BACKGROUND", "BRIEF SUMMARY OF THE INVENTION", "FIG. 1", "DETAILED DESCRIPTION" ([p0007], [p0018])

* **公开内容：** D3 公开了一种从本地设备上的 Web 浏览器调用 MIDlets 的方法和系统。它旨在利用 AMS 提供的 push registry 机制（如 SMS 或 socket）来异步调用应用，从而避免强制应用使用增加资源使用的同步轮询技术。

* 特征 A：D3 描述了“web browser 102”向“web server 102”（应为 server 206）发送 http 请求以请求需要与“MIDlet 100”交互的服务（图 1、[p0018]）。浏览器和 Web 服务器通过包括 http 协议（通常隐含轮询或请求响应）交互。背景技术提到避免“synchronous polling techniques that increase resource use”（[p0007]）。

* 特征 B：D3 公开了“web browser 102 issues an http request to web server ... In step 104, the http response contains a web page with a redirect to localhost... contains all the needed parameters for MIDlet 100... The AMS triggers MIDlet 100. MIDlet 100 reads the contents buffered in the socket and decodes the http request”（图 1、[p0018]）。这公开了向 Web 服务器（和本地重定向服务器）发送消息，但该消息旨在通过本地重定向由 AMS（应用管理软件）触发本地 MIDlet，并不包括发送唯一标识 UE 和“唯一标识 UE 内所述客户端应用实例的推送地址”到“服务器应用”以便后续服务器发起的推送。D3 的 http 请求是为了触发 MIDlet，而不是注册特定的推送地址以便服务器随时推送通知。

* 特征 C：D3 的步骤 104 涉及“http response contains ... a redirect to localhost... The AMS triggers MIDlet 100...decodes the http request... In step 106, MIDlet 100 completes it tasks and returns with an http response containing a redirect URL to the web server”（图 1、[p0018]）。这不对应本申请的特征 C。D3 描述的是一个通过 http 重定向由本地 AMS（更类似于 OS 的应用管理器）基于 socket 触发本地应用的机制。它不涉及从（远程）“推送服务器”接收包含“客户端应用实例标识符”的推送通知，并由 UE 内的“推送实体”引导。D3 的 AMS 触发本地已注册的应用，不涉及本申请中电信架构层面的推送实体基于实例标识的引导。

* 特征 D 和 E：D3 的步骤 107 涉及由浏览器发起的、包含 MIDlet 结果参数的 http 请求，步骤 108 涉及 Web 服务器返回 http 响应。这不对应特征 D（响应推送通知发起轮询消息）和 E。D3 描述的是浏览器重定向到本地、MIDlet 处理、MIDlet 返回重定向、浏览器向服务器发送结果的交互。

* 特征 F：D3 没有公开客户端应用实例处于“睡眠模式”。浏览器“hanging”在等待 MIDlet（[p0018]），但这并非为节省资源而“不执行轮询”的特定“睡眠模式”。此外，整个流程发生在触发本地应用期间，而不是在发送注册消息后等待未知时间的推送通知期间。

#### 综上所述特征比对表格如下：

---

### 第三部分：创造性分析过程的最接近对比文件

根据专利创造性审查指南，在确定最接近的对比文件时，应考虑以下因素：1) 与要求保护的发明属于相同或相近的技术领域；2) 旨在解决的技术问题最相近；3) 具有最多数目的相同技术特征。

**创造性分析过程的最接近对比文件：**

在创造性创造性分析过程中，适合做最接近对比文件（或最接近的对比文件之一）的是 **对比文件 2 (D2): US7177628B2**。

**理由如下：**

1. **整体解决的技术问题：**

* **本申请（CN101889424B）**：解决在移动电信系统内使用包括轮询的协议（拉出技术）进行交互时，频繁的轮询过度消耗无线电资源和电池能量的技术问题（[0001]-[0006]）。旨在通过引入推送通知机制来通知客户端有可用信息，从而在没有信息改变时允许客户端减少（或消除）轮询（[0007]、[0020]、[0041]）。

* **对比文件 2 (D2)**：旨在解决无线设备在接收数据时，传统的“trigger-poll”（SMS 通知，随后轮询）方法的缺点，例如网络资源浪费、实时性差（[0005]-[0006]）。旨在允许无线设备在数据可用时接收数据，且“without polling”（[0007]）。D2 通过引入服务器发起的 IP 推送连接来避免频繁轮询，或者在“优雅降级”模式下（当 IP 推送无法建立时）结合 SMS 和设备发起的请求（[0011]-[0012]、图 10）。

2. **技术领域：** D2 和本申请都明确属于移动电信系统内用户设备访问数据的技术领域，特别关注由于数据交互模式（传统轮询/拉出或由于 SMS 推送通知触发的轮询）而对网络资源和电池寿命产生的影响。D1 更通用地处理浏览器推送，并不特定关注无线电信系统的资源节省问题。D3 关注浏览器调用 MIDlet（本地应用）的机制。因此，D2 的技术领域与本申请非常接近。

3. **技术特征：** 尽管没有一个对比文件能覆盖所有特征，但 D2 在整体流程上与本申请最接近：

* 两者都涉及无线设备和内容服务器（或邮件服务器）。

* 两者都涉及设备发送标识信息到服务器进行注册，并获得网络地址信息（D2 的 IP 和 context 数据，本申请的推送地址）。

* 两者都旨在在常规数据交互或注册连接关闭期间（D2 维持 PDP context 但可能不执行轮询；本申请在睡眠模式下不执行轮询）通过推送机制节省资源。

* 两者都涉及服务器发起通知以促使设备在数据可用时进行动作（D2 服务器发起 socket 或发送 SMS；本申请推送服务器发送通知）。

* 更重要的是，在“优雅降级”模式下（图 10），D2 描述了设备接收 SMS 通知，激活 PDP context，发送“open socket request”请求内容的过程。这涉及“通知-触发-请求内容”的通用流程，与本申请“推送通知-引导客户端应用-客户端应用发送轮询消息-接收响应”的流程架构更为相似，尽管具体的标识引导和特定轮询消息细节不同。D1 是通过 applet 直接引导下载页面；D3 是本地触发应用。因此，D2 具有最多数目的实质类似的通用流程特征。

虽然 D2 可以作为最接近的对比文件，但也存在其他可能的最接近对比文件（例如，如果更关注浏览器交互，可能考虑 D1；如果更关注通过应用管理软件触发，可能考虑 D3），但根据整体解决的问题（节省电信系统资源）和通用流程（基于通知的服务器发起的特定请求流程），D2 确实是最合适的起步点。

---

### 第四部分：请求方最薄弱的技术特征

作为无效请求方，最薄弱的技术特征是指那些：在对比文件中完全没有公开，或者其公开程度非常实质地不如权利要求的特征，且该特征本身可能体现了相对于对比文件所描述的常规推送方法不可或缺的发明构思。

对于本权利要求，无效请求方最薄弱的技术特征是 **技术特征 B（结合技术特征 C 的引导部分）和技术特征 F**。

**详细解释：**

1. **关于技术特征 B 和 C 的引导部分**：本权利要求不仅仅是公开了一个通用的“推送地址”，而是要求发送的消息“包括**唯一地标识所述用户设备**和**唯一地标识所述用户设备内的所述客户端应用实例的推送地址**”。并且特征 C 要求由“推送实体”接收通知，并“**使用所述客户端应用实例的标识符将所述推送通知引导到所述客户端应用实例**”。

* 没有任何一个对比文件毫无异议地公开或实质公开了标识“应用实例”的推送地址。D2 公开了 IP 地址和 MIN 信息，但并未具体细化到标识特定“应用实例”以便推送实体引导。D1 依靠 applet 维护 socket 连接，不是基于实例标识引导。D3 依靠 AMS 触发已注册 MIDlet，非基于电信系统层面的推送通知的应用实例标识引导。

* 本申请的发明核心之一在于，如何在移动终端中可能运行多个浏览器（或 AJAX）实例的情况下，利用电信系统专用的推送机制（如 WAP PUSH 或 SIP PUSH，通过推送实体），**精准地**引导通知到那个特定的应用实例，从而使其“醒来”发起轮询。各对比文件都缺乏这一精准引导的核心特征，这构成了本申请相对于常规推送方法的关键区别特征。无效请求方很难通过组合对比文件，或根据公知常识在没有本申请教导的情况下，得出将推送地址细化到标识应用实例，并且由推送实体基于该应用实例标识符精准引导通知的教导。因此，这一特征对无效请求方来说是非常薄弱的。

2. **关于技术特征 F**：本权利要求要求在发送消息后、接收通知前，“在**睡眠模式中操作**所述客户端应用实例”。说明书 [0034] 明确定义睡眠模式“在此模式中它不执行轮询”。

* 如上特征比对表所述，没有任何一个对比文件毫无异议地公开了客户端应用实例处于特定的、旨在节省资源（不执行轮询）的“睡眠模式”。虽然 D2 在优雅降级下等待 SMS，或者 D3 浏览器“hanging”等待 MIDlet，但这不对应本申请定义的特定的、在发送注册消息后进入的、旨在减少无线电资源和电池能量过度消耗的、不执行轮询的“睡眠模式”。对比文件的推送技术大多旨在解决“未连接时的通知”，而不是专注于在通过轮询协议交互的浏览器/AJAX 环境下主动减少轮询以节省电池。

* 因此，要求无效请求方证明组合对比文件或基于公知常识得出“进入睡眠模式以节省电池，直到推送通知唤醒后才执行轮询”的教导，是非常困难的，特别是在考虑到这与本申请解决的主要技术问题和发明构思紧密结合的情况下。

基于以上分析，作为无效请求方，试图通过现有技术证明上述这些特征是公知常识或被对比文件所暗示（创造性），是非常薄弱且难以成功的。这些特征（精准的应用实例标识引导和旨在节省资源的特定睡眠模式）是区分本发明与传统推送机制的核心区别，构成了本权利要求创造性的关键。

如权利要求1所述的方法，其中到所述服务器应用的所述消息是HTTP请求。

如权利要求1所述的方法，包括：使所述客户端应用实例响应于接收到包括所述客户端应用实例的标识符的所述推送通知而离开所述睡眠模式。

如权利要求1所述的方法，包括：使所述客户端应用实例响应于检测到的动作而离开所述睡眠模式，所述检测到的动作由所述用户设备的用户发起。

如权利要求1所述的方法，其中所述客户端应用实例是浏览器应用实例。