好的，作为资深专利代理师，我将按照您的要求，严谨地评估对比文件US20070162578A1相对于目标专利CN101889424B的权利要求各技术特征的公开情况。
**对比文件名称：** 2007-07-12_US2007162578A_发明申请_US20070162578A1 System and method for application initiated user interaction
**目标专利名称：** 1139具有减少轮询的对基于因特网的应用的移动访问CN101889424B
**本次调用的模型名称：** AI专利分析模型
以下是特征比对表格：
| 技术特征描述及公开性判断结果 | 对比文件原文引用（译文） | 公开性论述 |
| 技术特征A：所述方法包括：在所述用户设备中运行客户端应用实例，其中所述客户端应用实例借助于包括轮询的协议经由网络与远程设置的服务器应用交互<br><br>**《未公开》** | [0004] “采用拉取（pull）方法，用户需要定期轮询（poll）应用程序，以确定是否需要其参与。”<br><br>[0010] “提供了一种响应于所述应用程序的推送（push）装置，用于通过确定的模态的客户端设备发起与用户的交互。”<br><br>[0023] “除了用户发起或基于拉取的交互外，系统还允许应用程序以对应用程序需求和用户当前上下文敏感的方式，主动向用户推送交互。” | 对比文件在背景技术部分描述了传统的拉取（pull）方法，其中包含轮询。然而，其发明核心是采用推送（push）技术来替代轮询，从而避免用户频繁轮询。对比文件并未公开其技术方案中的客户端应用实例是“借助于包括轮询的协议”与服务器交互。相反，对比文件教导了在应用发起交互时，服务器通过推送引擎和模态代理主动联系用户，客户端应用实例（如IM客户端、电话）本身并不执行轮询。因此，该技术特征未被公开。 |
| 技术特征B：发送消息到所述服务器应用，其中到所述服务器应用的所述消息包括唯一地标识所述用户设备和唯一地标识所述用户设备内的所述客户端应用实例的推送地址<br><br>**《未公开》** | [0032] “地址解析器返回用户的模态特定地址，例如用户的电话号码或电子邮件地址。它在内部使用一个注册表，维护从用户ID到其模态特定地址的映射。”<br><br>[0034] 步骤260：“推送引擎将交互描述符传递给相应的模态代理。它还将用户的ID和模态特定地址传递给每个模态代理。” | 对比文件公开了在应用发起交互时，推送引擎将用户ID和模态特定地址（如电话号码、邮箱地址）传递给模态代理。此处传递的地址是用于通过特定模态（如电话、邮件）联系用户的地址，其目的是联系用户这个人，而不是唯一标识用户设备内的一个特定“客户端应用实例”。它没有公开一个既能唯一标识用户设备又能唯一标识该设备内特定客户端应用实例的综合“推送地址”。因此，该技术特征未被直接或隐含公开。 |
| 技术特征C：由所述用户设备内的推送实体从推送服务器接收包括所述客户端应用实例的标识符的推送通知，并且使用所述客户端应用实例的标识符将所述推送通知引导到所述客户端应用实例，其中所述推送服务器响应于从所述服务器应用接收到推送请求而发送所述推送通知<br><br>**《未公开》** | [0034] 步骤260：“推送引擎将交互描述符传递给相应的模态代理。它还将用户的ID和模态特定地址传递给每个模态代理。”<br><br>[0038] “每个模态代理在Web服务接口中公开了以下方法： `void deliver(InteractionDescriptor id, UserID user, Address clientAddress);`” | 对比文件公开了推送引擎（相当于推送服务器）向模态代理（相当于用户设备外的实体）发送信息，而非向“用户设备内的推送实体”发送。模态代理接收信息后，负责主动联系用户（例如，拨打用户电话、发送即时消息），而不是将通知发送到用户设备内的某个实体，再由该实体根据客户端应用实例标识符进行路由。对比文件中的模态代理是独立于用户设备运行的服务器端组件。因此，对比文件未公开“由用户设备内的推送实体从推送服务器接收推送通知”以及用户设备内的实体进行内部路由的机制。 |
| 技术特征D：响应于所述推送通知，所述客户端应用实例经由所述网络将轮询消息发送到所述服务器应用<br><br>**《未公开》** | [0034] 步骤270：“模态代理根据视图标记与用户进行对话。”<br><br>[0027] “例如，IM模态代理是即时消息系统中的用户。用户可以开始与模态代理的即时消息会话并向其发送各种消息。” | 在对比文件中，当模态代理收到推送信息并联系用户后，交互是通过客户端（如IM客户端）与模态代理的直接通信进行的。客户端应用实例并不发送“轮询消息”到服务器应用。轮询消息是目标专利中客户端在收到推送后主动向服务器请求数据的特定行为，这与对比文件中模态代理与客户端之间建立会话并直接进行UI交互的方式完全不同。因此，该技术特征未被公开。 |
| 技术特征E：所述客户端应用实例接收对所述轮询消息的响应，其中所述响应包括与所述服务相关的信息<br><br>**《未公开》** | [0034] 步骤272至282描述了模态代理与用户交互、发送请求、接收应用响应并呈现视图的过程。 | 由于对比文件的技术方案中，客户端应用实例（如电话、IM客户端）不执行发送轮询消息的步骤，因此也就不存在接收对轮询消息的响应的过程。对比文件中，是由模态代理作为中介，从应用服务器获取数据并呈现给用户。客户端接收的是模态代理根据应用数据生成的交互内容，而非对客户端自身发起的轮询请求的直接响应。该技术特征未被公开。 |
| 技术特征F：在发送所述消息到所述服务器之后，但是在接收包括所述客户端应用实例的标识符的所述推送通知之前，在睡眠模式中操作所述客户端应用实例。<br><br>**《未公开》** | 全文未提及“睡眠模式”或类似概念。 | 对比文件说明书通篇未描述客户端应用实例或用户设备具有睡眠模式，也未提及在发送消息后、接收推送前进入低功耗或非活跃状态的概念。因此，该技术特征未被公开。 |
| 技术特征G：其中到所述服务器应用的所述消息是HTTP请求。<br><br>**《未公开》** | [0039] “会话对象向WPS应用程序发出一个HTTP GET请求，并获取要呈现的视图。”<br><br> 对比文件整体架构基于Web service，其底层通信通常依赖于HTTP协议。 | 虽然对比文件描述了模态代理与WPS（WebSphere Portal Server）之间的通信使用了HTTP GET请求（步骤262中模态代理向分发器发送请求，分发器最终与应用交互），但这发生在模态代理与分发器之间，并非目标专利所限定的“客户端应用实例”向“服务器应用”发送消息。目标专利中的消息（步骤211）用于注册推送地址，其协议未在对比文件中明确对应。因此，不能认为对比文件公开了客户端应用实例向服务器应用发送的消息是HTTP请求。该技术特征未被公开。 |
| 技术特征H：包括：使所述客户端应用实例响应于接收到包括所述客户端应用实例的标识符的所述推送通知而离开所述睡眠模式。<br><br>**《未公开》** | 全文未提及“睡眠模式”或客户端因收到通知而离开睡眠模式。 | 由于对比文件未公开睡眠模式（特征F），因此更不可能公开客户端实例因收到推送通知而离开睡眠模式这一特定触发机制。该技术特征未被公开。 |
| 技术特征I：包括：使所述客户端应用实例响应于检测到的动作而离开所述睡眠模式，所述检测到的动作由所述用户设备的用户发起。<br><br>**《未公开》** | [0033] 步骤202：“用户从协作客户端调用模态代理。”<br><br> 描述了用户主动发起交互（用户发起交互）的流程。 | 对比文件描述了用户主动发起交互的场景（用户呼叫模态代理），但这并非是从睡眠模式中唤醒。对比文件中不存在睡眠模式，因此也不可能因用户的主动操作而离开睡眠模式。该技术特征未被公开。 |
| 技术特征J：其中所述客户端应用实例是浏览器应用实例。<br><br>**《隐含公开》** | [0026] “系统容纳多样化且可扩展的客户端集合，包括传统的Web浏览器、IM客户端、电子邮件客户端……”。<br><br>[0041] “原始HTA允许任务参与者在Web浏览器上执行以下操作：……”<br><br>[0044] 描述了通过XForms增强Web表单能力。 | 对比文件说明书明确列举了“传统的Web浏览器”作为一种客户端应用实例。虽然其发明的核心在于通过模态代理支持多种客户端，但其系统架构明确涵盖并支持浏览器作为客户端，用于实现用户发起或应用发起的交互。本领域技术人员能够合理地推断出，在对比文件的框架内，浏览器可以作为“客户端应用实例”来接收推送并进行交互。因此，该技术特征被隐含公开。 |
**结论：**
综上所述，对比文件US20070162578A1未直接公开目标专利权利要求中的任何技术特征。仅技术特征J（客户端应用实例是浏览器应用实例）被隐含公开。
<<<j>>>