WO2011137781A1 - 业务通信的方法、系统、推送客户端和用户设备 - Google Patents

Description

业务通信的方法、 系统、 推 户端和用户设备 本申请要求于 2010年 7月 24日 提交中 国专利局， 申请号为 201010226151.0, 发明名称为"业务通信的方法、 系统、 推送客户端和用户设 备"的中国专利申请的优先权， 其全部内容通过引用结合在本申请中。 技术领域

本发明涉及数字通信系统， 具体地， 涉及数字通信系统中业务通信的方 法、 系统、 Push客户端和用户设备。 背景技术

在当今互联网上， 终端之间、 网元之间以及终端和网元之间需要利用互 联网协议（ IP )地址进行通信。从 IP地址的作用来看， IP地址具有双重语义： 在网络拓朴方面， IP地址表示某个终端接入网络时所处的拓朴位置； 在应用 方面， IP地址代表了终端的身份。

当第一终端和第二终端正在进行业务通信时，它们彼此知晓对方的 IP地 址。 如果第一终端移动， 它接入到网络的拓朴位置发生变化， 其 IP地址需要 随之发生相应的变化。 但是第二终端无法得知第一终端 IP地址的变化， 对于 第二终端而言，它始终认为它所知晓的 IP地址对应着正在与之通信的第一终 端。 这将导致业务通信的终端， 影响用户之间的通信体验。

为了解决 IP地址的双重语义问题导致的通信中断问题， 在现有技术中， 釆用了依赖于第三方应用服务器的方式来解决用户之间的连续通信问题。 两 个期望通信的终端可以通过第三方应用服务器进行连接， 由第三方应用服务 器在两个终端之间进行业务消息的转发。 两个期望通信的终端之一也可以从 应用服务器获得另一方的 IP地址， 再进行通信。 第三方应用服务器通常是由 服务提供商提供的， 包括但不限于 IM、 Twitter, Email, QQ等。

依赖于第三方服务器的通信过程简单描述如下： 用户在应用服务器上注 册， 获取应用服务器的标识， 如 QQ号码； 用户通过应用标识登入应用服务 器， 应用服务器获取用户的 IP地址； 其他用户需要联系该用户时， 通过应用 服务器的转发或直接从应用服务器获取该用户的 IP地址， 从而建立通信； 应 用服务器为了维护用户 IP的可达， 需要周期性的应用心跳来维持， 周期根据 情况而定， 一般是一至十几分钟。 在依赖于第三方应用服务器的通信中， 可 以釆用 Push (推送）技术， 利用第三方应用服务器将消息推送到通过心跳机 制维持 IP可达的终端用户。

依赖于第三方应用服务器的通信方式制约了通信双方的通信条件： 首先 双方用户必须主动发起与第三方应用服务器的通信以与第三方应用服务器维 持 IP可达， 否则第三方应用服务器将无法找到用户； 再者， 如果离开第三方 应用服务器， 通信双方的通信将难以发生或维续； 其次， 为了依赖于第三方 应用服务器， 用户的终端必须启动应用客户端并持续在线， 这将加剧终端耗 电， 降低终端性能。 发明内容

为此， 本发明实施例要解决的技术问题是提供业务通信的方法、 系统、 Push客户端和用户设备， 使得通信双方能够不需要依赖于第三方应用服务器 而在通信双方之间推送业务消息， 从而能够节省终端耗电并节省网络资源。

为解决上述技术问题， 一方面， 本发明实施例提供了一种业务通信的方 法， 该方法包括： 源 Push客户端生成 Push消息， 该 Push消息携带用于识别 目的端用户的目的端用户 Push标识； 源 Push客户端将该 Push消息发送给所 述目的端用户归属的目的 Push服务器；目的 Push服务器根据目的端用户 Push 标识获得到达目的 Push客户端的网络地址； 目的 Push服务器基于网络地址 将 Push消息发送给目的 Push客户端。

另一方面， 本发明实施例提供了一种业务通信的系统， 该系统包括： 源 Push客户端、 目的 Push客户端和目的 Push服务器， 其中， 源 Push客户端生 成 Push消息，该 Push消息携带用于识别目的端用户的目的端用户 Push标识； 源 Push客户端将该 Push消息发送给所述目的端用户归属的目的 Push服务器； 目的 Push服务器根据目的端用户 Push标识获得到达目的 Push客户端的网络 地址； 以及目的 Push服务器基于网络地址将所述 Push消息发送给目的 Push 客户端。

再一方面， 本发明实施例提供了一种用于业务通信的 Push客户端， 该 Push客户端包括： 生成模块， 用于生成 Push消息， 该 Push消息携带有用于 识别目的端用户的目的端用户 Push标识； 以及发送模块， 用于将生成模块生 成的 Push消息发送给所述目的端用户归属的目的 Push服务器， 以使得所述 目的 Push服务器根据所述目的端用户 Push标识获得到达目的 Push客户端的 网络地址， 并使得所述目的 Push服务器基于所述网络地址将所述 Push消息 发送给所述目的 Push客户端。

再一方面， 本发明实施例提供了一种用于业务通信的用户设备， 该用户 设备包括如上所述的 Push客户端。

基于上述的技术方案，本发明实施例根据 Push消息中携带的目的端用户 Push标识来进行地址转换以找到目的端用户， 使得源端用户和目的端用户之 间的通信能够根据 Push标识来完成， 而无需涉及第三方应用服务器。 因此， 本发明实施例能够在不依赖第三方应用服务器的情况下仍建立各种业务通 信， 从而避免用户时刻保持应用在线或定期去服务器查询， 同时仍可实时获 得通信对端发送的消息或内容， 由此本发明实施例能够节省终端耗电并节省 网络资源。 附图说明

为了更清楚地说明本发明实施例的技术方案， 下面将对本发明实施例中 所需要使用的附图作简单地介绍， 显而易见地， 下面描述中的附图仅仅是本 发明的一些实施例， 对于本领域技术人员来讲， 在不付出创造性劳动的前提 下， 还可以根据这些附图获得其他的附图。 图 1图示了根据本发明实施例的网络架构的示意图；

图 2图示了根据本发明实施例的业务通信方法的流程图；

图 3图示了根据本发明实施例的另一业务通信方法的示意图；

图 4图示了根据本发明实施例的由源 Push客户端获取目的端用户 Push标 识的方法的示意图；

图 5图示了根据本发明实施例的由源应用客户端获取目的端用户 Push标 识的方法的示意图；

图 6图示了根据本发明实施例的由源应用客户端获取目的端用户 Push标 识的另一方法的示意图；

图 7图示了根据本发明实施例的由源应用客户端获取目的端用户的 Push 标识的再一方法的示意图；

图 8图示了根据本发明实施例的由源 Push客户端获取目的端用户的 Push 标识的另一方法的示意图；

图 9图示了根据本发明实施例的由 Push服务器获取目的端用户的 Push标 识的再一方法的示意图；

图 10图示了才艮据本发明实施例的再一业务通信方法的示意图；

图 11图示了才艮据本发明实施例的业务通信的系统的示意图；

图 12图示了才艮据本发明实施例的业务通信的另一系统的示意图； 图 13图示了根据本发明实施例的用于业务通信的 Push客户端的结构框 图；

图 14图示了根据本发明实施例的用于业务通信的 Push客户端的另一结构 框图；

图 15图示了根据本发明实施例的用于业务通信的用户设备的结构框图； 具体实施方式

为使本发明实施例的目的、 技术方案和优点更加清楚， 下面将结合本发 明实施例中的附图， 对本发明实施例中的技术方案进行清楚、 完整地描述， 显然， 所描述的实施例是本发明一部分实施例， 而不是全部的实施例。 基于 本发明中的实施例， 本领域普通技术人员在没有作出创造性劳动前提下所获 得的所有其他实施例， 都属于本发明保护的范围。

首先结合图 1来描述可应用于本发明实施例的一种网络架构 100。

构成本发明的网络架构 100 可以包括用户终端 110、 数据网关节点 120 和 Push服务器 130。 各个元素可以是单独的网络实体， 也可以是集成在网络 实体中的功能实体。

用户终端 110中安装有 Push客户端， 用于与 Push服务器 130进行对等 通信。 在用户终端 110接入网络之后， Push客户端可以向 Push服务器 130 发起注册， 与 Push服务器 130进行 Push消息的交互， 既可以向 Push服务器 130发送 Push消息也可以从 Push服务器 130接收消息。

用户终端 110中还可以安装有应用客户端， 用于生成期望发送的业务信 息。 应用客户端将生成的业务信息发送给 Push客户端以生成 Push消息。

数据网关节点 120可以是接入数据网络的接入设备， 包括但不限于网关 GPRS支持节点 （GGSN ) 、 家乡代理（HA, Home Agent ) 、 分组数据网络 网关（ PDN-GW , Packet Data Network Gateway )等。 数据网关节点 120可以 为用户分配网络地址（例如， IP地址） 。 用户终端 110可以通过数据网关节 点 120来接入数据网络。

Push服务器 130可以是网络中新增的网元， 也可以是集成在已有网元中 的功能实体。 Push服务器 130可以存储用户 Push标识和用户终端网络地址的 映射关系， 可以将用户 Push标识转换为用户终端当前网络地址， 并且可以将 Push消息发送到相应的用户终端。 Push服务器还可以对 Push消息进行认证， 以确保 Push消息的合法推送。

Push服务器 130—般位于无线网络的分组交换域内， 无线网络包括但不 限于 2G、 GPRS , 3G、 WiMAX和 LTE等多种无线网络。 Push服务器 130中 存储有用户 Push标识和用户终端位置（例如， 网络地址）的映射关系， 具有 将用户 Push标识翻译到能够到达用户终端当前地址的功能。 另外，如果 Push 服务器 130位于电路交换域内， 则 Push服务器 130维护用户 Push标识和用 户网络内部标识（例如国际移动用户标识 IMSI )的映射关系，具有将用户 Push 标识翻译为用户网络内部标识 （例如 IMSI ) 的功能。

图 2图示了才艮据本发明实施例的业务通信方法 200的流程图。 如图 2所 示， 根据本发明实施例的一种业务通信的方法 200包括：

S210, 源 Push客户端生成 Push消息， 该 Push消息携带用于识别目的端 用户的目的端用户 Push标识；

S220, 源 Push客户端将 Push消息发送给目的端用户归属的目的 Push服 务器；

S230, 目的 Push服务器根据目的端用户 Push标识获得到达目的 Push客 户端的网络地址；

S240 , 目的 Push服务器基于网络地址将 Push消息发送给目的 Push客户 端。

作为消息发送方的源 Push客户端生成向作为消息接收方的目的 Push客 户端发送的 Push消息。 Push消息除了携带有业务信息之外，还可以携带用于 识别目的端用户的目的端用户 Push标识。源 Push客户端可以将所生成的 Push 消息发送给该目的端用户归属的目的 Push服务器。 由于目的 Push服务器中 存储有目的端用户 Push标识和目的端用户网络地址之间的映射关系，例如可 以是用户 Push标识和 IP地址的映射表，所以目的 Push服务器可以根据 Push 消息中所携带的目的端用户 Push标识来进行查询， 得到相应的目的 Push客 户端的网络地址。 目的 Push服务器获得网络地址之后， 可以根据该网络地址 将 Push消息从相应的端口发送出去， 从而最终到达目的端用户的目的 Push 客户端。

在本发明实施例提供的业务通信方法中，根据 Push消息中携带的目的端 用户 Push标识来进行地址查询以找到目的端用户，使得源端用户和目的端用 户之间的通信能够利用 Push标识来完成， 而无需涉及第三方应用服务器。 因 此， 本发明实施例能够在不依赖第三方应用服务器的情况下仍建立各种业务 通信， 从而避免用户时刻保持应用在线或定期去服务器查询， 同时仍可实时 获得通信对端发送的消息或内容， 由此本发明实施例能够节省终端耗电并节 省网络资源。

在本发明实施例中， 源 Push客户端将 Push消息发送给目的端用户归属 的目的 Push服务器， 既包括源 Push客户端直接将 Push消息发送给目的端用 户归属的目的 Push服务器， 也包括源 Push客户端通过源 Push服务器间接地 将 Push消息转发给目的 Push服务器， 这取决于源端用户的源 Push客户端与 目的端用户的目的 Push客户端是否归属于同一个 Push服务器以及用户是否 处于漫游地， 其中该源 Push服务器可以包括源端用户归属的 Push服务器， 也可以包括源端用户所在的漫游域内的漫游域 Push服务器。

即， 如果源端用户和目的端用户都没有漫游的情况下：

一方面， 如果源端用户的源 Push客户端与目的端用户的目的 Push客户 端归属于同一个 Push服务器， 那么该 Push服务器既是源端用户归属的源 Push服务器又是目的端用户归属的目的 Push服务器。 此时， 实现该业务通 信方法的系统包括源 Push客户端、 目的 Push客户端和 Push服务器， 该业务 通信方法即为： 源 Push客户端生成携带目的端用户 Push标识的 Push消息； 该源 Push客户端直接将该 Push消息发送给 Push服务器， 该 Push服务器既 是源端用户归属的 Push服务器，又是目的端用户归属的 Push服务器；该 Push 服务器根据目的端用户 Push标识进行查询， 获得到达目的 Push客户端的网 络地址， 并基于该网络地址将该 Push消息发送给目的 Push客户端。

另一方面， 如果源端用户的源 Push客户端与目的端用户的目的 Push客 户端不归属于同一个 Push服务器， 那么源 Push客户端可能直接将 Push消息 发送给目的端用户归属的目的 Push服务器， 这样做的前提是源 Push客户端 已经提前知道目的 Push服务器的地址， 或者根据目的端用户 Push标识获得 目的 Push服务器的地址； 源 Push客户端也可能通过源端用户归属的源 Push 服务器间接地将 Push消息转发给目的 Push服务器， 具体如图 3所示的实施 例。

如图 3所示， 在根据本发明另一实施例的业务通信的方法 300中， 在源 端用户归属的源 Push服务器与目的端用户归属的目的 Push服务器不同， 且 源端用户和目的端用户都没有发生漫游的情况时， S220可以包括：

S320,源 Push客户端将 Push消息发送给源端用户归属的源 Push服务器； 以及

S330, 源 Push服务器根据目的端用户 Push标识将 Push消息发送给目的 端用户归属的目的 Push服务器。

即，在源 Push客户端例如基于源端用户期望发送给目的端用户的业务信 息生成 Push消息之后 （ S310 ) , 其中该 Push消息携带用于识别目的端用户 的目的端用户 Push标识， 源 Push客户端首先将 Push消息发送给源端用户归 属的源 Push服务器（ S320 ) , 源 Push服务器可以根据目的端用户 Push标识 确定该目的端用户归属的目的 Push服务器和该源 Push服务器不同， 于是该 源 Push服务器可以根据目的端用户 Push标识将 Push消息发送给目的端用户 归属的目的 p_ush服务器（ S330 ) ， 目的 Push服务器根据目的端用户 Push标 识进行查询， 获得到达目的 Push客户端的网络地址（S340 ) , 并基于该网络 地址将 Push消息发送给目的端用户的目的 Push客户端 （ S350 ) 。

根据本发明实施例提供的业务通信方法，根据 Push消息中携带的目的端 用户 Push标识来进行地址查询以找到目的端用户，使得源端用户和目的端用 户之间的通信能够利用 Push标识来完成， 而无需涉及第三方应用服务器。 因 此， 本发明实施例能够在不依赖第三方应用服务器的情况下仍建立各种业务 通信， 从而避免用户时刻保持应用在线或定期去服务器查询， 同时仍可实时 获得通信对端发送的消息或内容， 由此本发明实施例能够节省终端耗电并节 省网络资源。

在本发明实施例中， 源 Push客户端可以基于接收的来自应用客户端的业 务信息生成 Push消息， 该应用客户端可以是具有与源 Push客户端进行通信 的 Push接口的应用客户端。该应用客户端相对于现有的普通应用客户端而言 增加了 Push功能， 也就是能够与源 Push客户端通信， 由此本发明实施例中 所涉及的应用客户端也可以被称为增强型应用客户端。 具体而言， 增强型应 用客户端可以包括以下几种情况中的一种或多种：

1. 增强型 RCS ( Rich Communication Suite, 富通信套件）。 目前的 RCS 可以为用户提供整套基于通讯录的呈现、 即时通信、 群组聊天、 文件传送等 在线通信应用， 即 RCS可以在用户通信录中集成多种第三方应用， 用户只需 经由 RCS界面， 就可以选择任何一种已经集成到 RCS中的第三方应用来联 系通信录中的好友， 并与之通信。 增强型 RCS是将 Push接口集成到目前的 RCS中，使得 RCS中所集成的所有第三方应用都可以基于本发明中提出了利 用 Push标识来进行业务通信的方法来实现。 增强型 RCS可以选择与 Push客 户端相通信来利用 Push方式向外推送消息；

2. 增强型通讯录。 增强目前普通的通信录的功能， 使得通信录可以支持 用户 Push标识和好友的转换。 用户 Push标识可以与好友的用户名、 好友的 电话号码、 好友的地址等中的至少一个相转换。 将 Push接口集成到通讯录中 得到的增强型通讯录可以通过 Push接口向好友发送消息，反过来， Push客户 端也可以查询通讯录以获取用户好友的名字。 此时， 通信双方直接利用终端 设备中的通信录进行通信， 不用登陆第三方应用程序；

3. 增强型第三方应用客户端软件。 增强型第三方应用客户端软件是在普 通客户端 （如 MSN、 QQ客户端软件等） 的基础上增加 Push功能， 以实现 Push客户端与第三方应用客户端之间的通信。 此时， 应用客户端的业务发起 不用先和第三方应用服务器进行交互， 也就是不用获取了用户信息之后才能 与对端通信（例如， QQ用户先要登陆 QQ服务器才能与对端通信）， 而是可 以通过获取目的端用户 Push标识来与对端用户进行直接通信。本文中所说的 直接通信是指不需要依赖于第三方应用服务器所进行的通信。

4. 代理客户端软件。 当应用客户端软件无法支持 Push功能， 也就是无 法将 Push接口集成在应用客户端中时， 代理客户端软件帮助应用客户端与 Push客户端之间进行信息交互。 此时的代理客户端可以相当于应用客户端和 Push客户端之间的 Push接口。 从 Push客户端的角度来看， 代理客户端可以 相当于增强型应用客户端。

源 Push客户端从增强了 Push功能的应用客户端接收业务信息之后， 可 以生成准备向目的端用户发送的 Push消息。在本发明实施例中， Push消息中 除了承载有业务信息和用于识别目的端用户的目的端用户 Push标识之外，还 可以携带用于识别源端用户的源端用户 Push标识和 /或用于识别业务类型的 应用标识。

目的端用户 Push标识和源端用户 Push标识都属于用户 Push标识。 用户 Push标识可以是与用户相对应的位于应用层的标识， 用来区分不同的用户。 用户 Push标识在网络中是唯一的， 通过用户 Push标识可以找到相应的用户。 这里所指的用户可以是操作用户终端的实际的用户， 也可以是通过网络中的 诸如用户名、 代码、 编号等识别的网络世界中虚拟的用户， 还可以相应于某 一特定终端设备。 总之， 所说的用户是可以由 Push标识来唯一识别的通信对 象。 由此， 用户 Push标识例如可以包括用来区分不同用户的用户电话号码、 用户名、 用户代码、 用户编号等。 用户 Push标识可以映射到用户终端中的 RCS、 通信录或应用客户端中显示的好友。 通过选择好友可以得到该好友对 应的 Push标识。 用户 Push标识由运营商分配， 具体地， 可以由网络中部署 的 Push服务器来分配， 也可以由其他网络中的功能实体（例如， 授权认证和 计费 AAA ( Authentication, Authorization, Accounting, 简称为" AAA" )服务器 等）来分配， 还可以由网络运营商通过执行签约手续来分配。 用户的 Push标 识可以是静态、 长期的， 也可以是动态短期的。 用户 Push标识可以是二进制 比特串， 也可以是用于识别用户的字符串。

应用标识可以具体指向特定应用程序， 也可以指明观看、 阅读、 操作业 务信息所需使用的应用程序的类型， 还可以说明业务信息的内容属性。 当然, 应用标识还可以是本领域技术人员可以想到了能够指明业务信息和应用程序 之间相应关系的其他数据。 应用标识的产生可以基于一项应用主动的申请。 当某一项应用主动申请应用标识时，该应用向部署 Push服务器的提供商提出 申请， 期望获得针对该项应用的应用标识。 经过审核通过后， 提供商在 Push 服务器上配置针对该应用的规则， 并为该应用分配应用标识。 应用标识的产 生也可以基于部署 Push服务器的提供商的要求。提供商可以向某项应用发出 邀请， 在该项应用同意的情况下， 在 Push服务器上为该应用配置针对该应用 的规则， 并为该应用分配应用标识。 也就是说， 应用标识是提前确定的， 且 在 Push服务器有相应的发送规则。 该发送规则可以是认证通过后才发送， 也 可以是优先发送， 还有可能是最小时延发送等。

根据本发明的实施例， 为了获取目的端用户 Push标识、 源端用户 Push 标识和应用标识中的至少一个， 可以釆用如下的获取方法。 下面的获取方法 以源端获取目的端用户 Push标识为例进行描述，其中源端获取源端用户 Push 标识和应用标识的过程、 以及目的端获取三个标识中的至少一个标识的过程 与之相类似。

在本发明实施例中，根据用户的用户名与用户 Push标识之间对应关系的 存储位置不同， 可以釆用不同的方式来获取用户 Push标识， 其中该对应关系 的存储位置可以包括以下三种情况：

1. 位于用户终端的配置文件或数据库中。 该配置文件或数据库可以是专 门用于记录对应关系的配置文件或数据库， 也可以是在现有配置文件或数据 库的基础上添加对应关系得到的配置文件或数据库等；

2. 位于应用客户端中或者 RCS 中或者通信录中， 其中与用户的用户名 相对应的用户 Push标识与用户名关联存放和管理。 3. 位于运营商网络内。 该对应关系可以存储在终端地址薄中， 该终端地 址薄可以是集成在特定网元中的功能模块， 也可以是单独的网元， 在该终端 地址薄上记录有用户名和用户 Push标识的对应关系。

此外， 根据该对应关系的不同的存储位置， 还可以由不同的主体（例如， 应用客户端、 Push客户端或 Push服务器）来获取用户 Push标识， 下面将详 细进行描述。

如图 4所示，其中图示了根据本发明实施例的由源 Push客户端获取目的 端用户 Push标识的方法 400的示意图。

在 S410中， 源应用客户端可以向源 Push客户端发送业务信息， 也就是 携带业务数据的 Push信息， 在 Push信息中还可携带有目的端用户的用户名。 例如， 给源 Push客户端发送 Push信息的是通信录对应的应用程序。 目的端 用户的用户名可以是源应用客户端在通信录中查找得到的， 并且该用户名不 限于用户的名称， 还可以是用户的电话号码、 用户的代码、 用户的昵称、 用 户的地址等。

在 S420中， 源 Push客户端根据目的端用户的用户名查询源端用户终端 中的配置文件， 得到目的端用户 Push标识。 该配置文件可以记录有目的端用 户的用户名和目的端用户 Push标识之间的映射关系。 在 S430中， 源 Push客 户端基于所得到的目的端用户 Push标识在 Push信息的基础上生成 Push消息 向源 Push服务器发送。 例如， 源 Push客户端可以将目的端用户 Push标识添 加到 Push信息的头部， 也可以将目的端用户 Push标识添加到 Push信息中的 保留或预留字段等， 其它由源应用客户端发送的 Push信息经过 Push客户端 的选择， 也有可能被填入生成的 Push消息中。

图 5图示了根据本发明实施例的由源应用客户端获取目的端用户 Push标 识的方法 500的示意图。

在 S510 中， 源应用客户端可以根据目的端用户的用户名来查询配置文 件， 以得到目的端用户 Push标识。 该配置文件可以是存储在源端用户终端中 的记录有目的端用户的用户名和目的端用户 Push标识之间的映射关系的文 件。

在 S520中，源应用客户端生成携带有目的端用户 Push标识的 Push信息， 并向源 Push客户端发送。 在 S530中， 源 Push客户端基于 Push信息生成携 带有目的端用户 Push标识的 Push消息，并向 Push服务器发送。例如，源 Push 客户端可以直接将携带有目的端 Push标识的 Push信息作为 Push消息。源 Push 客户端也可以将 Push信息的数据结构转换为符合 Push消息的数据结构的形 式等。

图 6图示了根据本发明实施例的由源应用客户端获取目的端用户 Push标 识的另一方法 600的示意图。

在 S610 中， 源应用客户端可以根据通信录中存储的目的端用户的用户 名， 向在网络侧存储的终端地址薄查询用户名对应的目的端用户 Push标识， 其中终端地址薄中可集中存储用户名和用户 Push标识的映射关系。

在 S620中， 源应用客户端基于查询得到的目的端用户 Push标识来生成 Push信息， 并向源 Push客户端发送。

在 S630中， 源 Push客户端基于 Push信息生成携带有目的端用户 Push 标识的 Push消息， 并向 Push服务器发送。

图 7图示了根据本发明实施例的由源应用客户端获取目的端用户的 Push 标识的再一方法 700的示意图。

在 S710中，源应用客户端查询源应用客户端或通信录中存储的目的端用 户与目的端用户 Push标识之间的映射关系，根据目的端用户的用户名得到目 的端用户的 Push标识。

在 S720中， 源应用客户端将目的端用户 Push标识携带在 Push信息中发 送给源 Push客户端。

在 S730中， 源 Push客户端将来自源应用客户端的目的端用户 Push标识 携带在 Push消息中， 发送给 Push服务器。 图 8图示了根据本发明实施例的由源 Push客户端获取目的端用户的 Push 标识的另一方法 800的示意图。

在 S810中， 源应用客户端向源 Push客户端发送 Push信息， 在 Push信 息中还携带有目的端用户的用户名， 该用户名可以是源应用客户端在通信录 中查找得到的， 并且该用户名不限于用户的名称， 还可以是用户的电话号码、 用户的代码、 用户的昵称、 用户的地址等。

在 S820中， 源 Push客户端根据目的端用户的用户名在网络侧的终端地 址薄上查询目的端用户 Push标识。该终端地址薄中可以存储有用户名和用户 Push标识的映射关系。

在 S830中， 源 Push客户端基于所得到的目的端用户 Push标识在 Push 信息的基础上生成 Push消息， 并向 Push服务器发送。

图 9图示了根据本发明实施例的由 Push服务器获取目的端用户的 Push 标识的方法的示意图。

在 S910中， 源应用客户端向源 Push客户端发送 Push信息， 在 Push信 息中还携带有目的端用户的用户名， 该用户名可以是源应用客户端在通信录 中查找得到的。

在 S920中， 源 Push客户端向 Push服务器发送携带有目的端用户的用户 名的 Push消息。

在 S930中， Push服务器根据 Push消息中携带的目的端用户的用户名， 向网络侧的终端地址薄进行查询， 获取与目的端用户的用户名相应的目的端 用户 Push标识。

在 S940中， Push服务器根据目的端用户的 Push标识来查找可以到达目 的端用户的网络地址。 当然， Push月良务器可以向 Push消息中添加目的端用户 Push标识。 虽然， 在该实施例中， 从源 Push客户端发送的 Push消息携带的 不是地址转换所需要的目的端用户 Push标识而是目的端用户的用户名，但是 目的端用户的用户名所起的唯一识别目的端用户的作用与目的端用户 Push标 识相同， 只是在表现形式上有所不同， 需要借助于 Push服务器来进行进一步 的转换。 所以， 从系统的角度来看， 或者从目的端用户的角度来看， 仍然可 以认为源 Push客户端发送的 Push消息携带目的端用户 Push标识。

此外， 获取应用标识的过程可以由应用客户端直接告诉 Push客户端， 或 者由应用客户端查询记录有应用标识与应用程序之间对应关系的配置文件之 后告诉 Push客户端， 或者由 Push客户端自己查询配置文件获得。 当然， 还 可以由 Push客户端根据应用客户端传递来的信息， 向网络侧查询获得。

在上述图 4至图 9所示的实施例中， 所述 Push服务器可能是源 Push服 务器， 也可能是目的 Push服务器， 这取决于源端用户的源 Push客户端与目 的端用户的目的 Push客户端是否归属于同一个 Push服务器。

综上所述， 应用客户端告诉 Push客户端源端用户 Push标识、 目的端用 户 Push标识和应用标识中的至少一个的方式包括通过内部通信的方式直接传 递相应的标识，也包括应用客户端告诉 Push客户端标识的相关信息， 由 Push 客户端自己在本地查找配置文件或者向网络侧的其他实体进行查询。 而 Push 客户端获取三种标识中的至少一个的方式可以在本地直接获得， 或者在网络 侧查找获得。 另外， 源 Push服务器也可以根据 Push消息来向网络中的特定 网元查询以获得对应的标识。

上述三种标识中的任意一种标识的获取过程可以首先由源应用客户端或 源 Push客户端进行并存储在设备内， 也可以由源 Push客户端在发送 Push消 息之前进行获取， 还可以在 Push消息发送到 Push服务器时由 Push服务器进 行获取。

在本发明上述实施例中， 应用客户端（例如， 通信录对应的应用程序等） 发送给 Push客户端的 Push信息可以是一条具体的 Push消息， 也可以是以带 参数调用 （例如， 应用客户端将目的端用户 Push标识、 本地用户 Push标识 等作为参数输入给 Push客户端， 由 Push客户端来生成 Push消息）的方式发 送给 Push服务器的 Push信息。 在上述实施例中， 目的端用户的用户名不局 限于用户的名称， 还可以是电话号码等信息， 只要能够区分不同的用户即可。 在本发明实施例中， 源 Push客户端在获得源端用户 Push标识、 目的端 用户 Push标识或应用标识之后，可以将这些标识之一或任意组合緩存在本地 用户终端中， 以便以后查询。

在本发明实施例中， 源 Push客户端可能直接知道源 Push服务器的网络 地址， 从而将 Push消息发送给源 Push服务器， 也可能源 Push客户端只知道 源 Push服务器的域名等信息， 源 Push客户端通过查询 DNS ( Domain Name System )系统得到源 Push服务器的网络地址，从而将 Push消息发送给源 Push 服务器。 此时， 源 Push服务器的域名信息或网络地址可以存储在源端用户终 端中， 由源 Push客户端直接查询或者才艮据源端用户 Push标识查询即可。 源 Push客户端也可能不知道源 Push服务器的网络地址。 此时， 源 Push客户端 可以向网络侧查询源 Push服务器的网络地址，也可以将 Push消息发送之后， 由其它网元根据 Push消息的类别而发送给源 Push服务器。 例如， 源 Push客 户端中可能只是静态配置了一个 Push服务器的域名， 根据该域名可获得该 Push服务器的地址，源 push客户端将所有 Push消息都发送到该 Push服务器 即可， 由该 Push服务器根据目的端用户 Push标识来确定是间接地转发给其 它 Push服务器， 还是进行地址查询， 然后基于查询得到的地址直接地将该 Push消息发送到目的 Push客户端。 此外， 在图 1的网络架构下， 源 Push客 户端需要通过数据网关节点将 Push消息发送给 Push服务器， 但是也并不排 除源 Push客户端通过诸如基站之类的接入设备或者直接发送给源 Push服务 哭口

在本发明实施例中，源 Push服务器和目的 Push服务器中的至少一个 Push 服务器可以根据所接收的 Push消息中携带的应用标识对 Push消息进行认证， 判断应用标识对应的应用是否授权合法， 以防止非授权的应用 Push垃圾信息 在网络中传输。 如果授权合法， 则转发经过认证的该 Push消息。 例如， 可以 将 Push消息携带的应用标识与存储在源 Push服务器中的合法应用标识列表 进行比较， 如果相同， 则认为该应用标识授权合法。 由于 Push服务器可以对 应用标识进行认证，因此能够防止非授权的应用 Push垃圾信息在网络中传输， 进一步节省网络资源， 并保证合法的网络应用环境。

在本发明实施例中，源 Push服务器和目的 Push服务器中的至少一个 Push 服务器也可以对 Push消息中携带的目的端用户 Push标识和 /或源端用户 Push 标识进行认证， 以使合法的目的端用户和 /或源端用户才能进行本发明实施例 所提供的业务通信。 例如， 可以将 Push 消息携带的需要认证的目的端用户 Push标识和 /或源端 Push标识与存储在源 Push服务器中的合法用户 Push标 识相比较， 如果相同， 则认为该用户合法。 当然， 目的端用户 Push标识和 / 或源端用户 Push标识也可以其他功能实体进行认证， 例如授权认证和计费 AAA服务器、 本地签约服务器（ Home Subscriber Server, 简称为 "HSS" )等。

在本发明实施例中， Push服务器的部署可以是一种分布式部署， 用户可 以归属于不同的 Push服务器， 每个用户所归属的 Push服务器可以称为自己 的家乡 Push服务器。 当源端用户所归属的家乡 Push服务器 （例如， 源 Push 服务器 )和目的端用户所归属的家乡 Push服务器（例如， 目的 Push服务器 ) 不同时， 可以根据如用户 Push标识中所携带的标志位来进行路由。 通过该标 志位可以映射到目的端用户的家乡 Push服务器， 从而实现根据用户 Push标 识将 Push消息在各个 Push服务器之间进行路由。 即在本发明上述实施例中， 源 Push服务器可以根据目的端用户 Push标识中的标志位将 Push消息发送给 目的 Push服务器。

当用户处于漫游状态即用户从家乡域移动到其他域时， 发送给该用户的 Push消息将首先到达该用户所归属的家乡 Push服务器，然后由家乡域的 Push 服务器将 Push消息转发给用户漫游域内的 Push服务器。 即目的 Push服务器 基于网络地址将 Push消息发送给目的 Push客户端可以包括： 目的 Push服务 器将 Push消息发送给目的端用户所在的漫游域内的漫游域 Push服务器； 以 及该漫游域 Push服务器基于网络地址将该 Push消息发送给目的 Push客户端。 为了实现这种路由， 用户每次漫游到其他域时， 需要向该漫游域内的 Push服 务器注册， 并可以经由漫游域 Push服务器来完成向家乡域的 Push服务器注 册。 发送给该用户的 Push消息可以首先根据该用户的用户 Push标识中的标 志位发送给该用户的家乡 Push服务器， 家乡 Push服务器由于在之前的注册 过程中获知了该用户漫游到了其他域的 Push服务器，根据记载的对应关系将 Push消息发送给该用户漫游域的 Push服务器， 由漫游域的 Push服务器发送 给该用户。

当漫游的用户需要向外发送 Push消息时，即漫游的用户作为源端用户时， 由漫游域内的 Push服务器来取代图 2至图 10所示实例中源端用户归属的源 Push服务器， 来完成对 Push消息接收和转发等功能。 即， 由源端 Push客户 端发出的 Push消息可以直接到达漫游域的 Push服务器， 由漫游域的 Push服 务器根据目的端用户 Push标识进行地址转换而发送给目的端用户 （此时， 目 的端用户归属于该漫游域的 Push服务器 )或者目的端用户归属的 Push服务 器， 而可以不经由漫游的源端用户的家乡 Push服务器。

例如， 用户 Push标识可以由一系列二进制比特组成， 前面四个比特对应 路由标志位， 后面的多个比特用户区分不同的用户。 前面四个比特的前两个 比特可以是运营商的标志位， 例如用 00代表中国移动， 用 01代表中国联通， 用 10代表中国电信等。 前面四个比特的后两个比特可以是顺序号， 用来指向 不同的 Push服务器， 例如， 00代表 Push服务器 1 , 01代表 Push服务器 2 等。 在该情况下， 如果编号为 0001的源 Push服务器收到一个 Push消息， 其 中携带的目的端用户 Push标识的路由标志位为 0011 , 则该 Push消息首先会 路由到编号为 0011的中国移动的 Push服务器 4。 因此， 源 Push服务器根据 目的端用户 Push标识中的路由标志位来确定目的 Push服务器，然后根据 Push 服务器及其网络地址之间的映射关系来获取目的 Push服务器的网络地址。 Push服务器及其网络地址之间的映射关系可以提前存储在源 Push服务器中， 也可以集中存储在其他网元中等待源 Push服务器的查询。 在本发明实施例中， 当目的 Push客户端接收到 Push消息时， 目的端用 户的终端设备中安装的该目的 Push客户端可以启动提示机制， 以告诉目的端 用户有 Push消息到达。 例如， 目的 Push客户端提示用户新的信息到达时， 可以在终端设备上弹出一个页面窗口或者响起一段铃声。 当然目的 Push客户 端还可以通过其它方式进行提示， 例如提示框、 声音、 图片、 振铃、 振动等 方式。

在本发明实施例中，当目的 Push客户端接收到 Push消息后，确定与 Push 消息中携带的应用标识相应的应用程序是否启动。 如果应用程序没有启动， 则目的 Push客户端拉起相应的目的应用客户端，也就是调用或启动相应的应 用程序。 优选地， 在目的 Push客户端启动提示机制后， 目的 Push客户端在 确定与应用标识相应的应用程序没有启动的情况下启动相应的应用程序。 由 于 Push客户端可以在相应的应用程序没有启动的情况下拉起应用程序，使得 应用程序不用保持开启状态， 甚至不用保持始终在线， 在需要时才被启动， 因此本发明实施例能够进一步节省终端功耗，并降低终端设备中的资源使用。

根据本发明上述实施例， 目的 Push客户端在确定与应用标识相应的应用 程序没有启动的情况下， 首先向目的端用户提示是否启动该应用程序， 然后 在接收到目的端用户确认启动该应用程序的确认信息时， 启动该应用程序。 由此用户之间可以分享业务。

启动或者拉起应用程序的过程可以包括如下几种情况：

1. 在 Push消息携带的应用标识对应一个具体的应用软件（例如 QQ软 件、 MSN软件等， 还包括 RCS 中集成的应用软件） ， 并且目的端用户终端 设备中也安装了该应用软件的情况下， 目的 Push客户端根据该应用标识拉起 该应用软件；

2. 在 Push消息携带的应用标识对应一个具体的应用软件， 但是目的端 用户终端设备中没有安装该应用软件的情况下， 目的 Push客户端根据该应用 标识尝试拉起相似的应用软件。 例如， 应用标识指明需要使用 Word软件， 但是目的端用户终端设备中没有安装 Word软件而安装有写字板软件时， 目 的 Push客户端尝试拉起写字板软件， 来显示 Push消息中携带的文本信息；

3. 在 Push消息携带的应用标识对应业务信息的内容属性的情况下， 目 的 Push客户端根据该应用标识尝试拉起能够为目的端用户呈现 Push消息中 业务信息的应用软件。 例如， 当应用标识指示 Push消息中的业务信息为图片 时， 目的 Push客户端根据应用标识拉起目的端用户终端设备中的图片浏览应 用软件。

在本发明实施例中， 当通信双方用户处于网络地址转换（ NAT )设备之 后时， 目的端用户收到源端用户发送的 Push消息之后， 可能不能直接与源端 用户直接进行通信， 这是因为现有网络中 NAT多为受限圓锥形 NAT, 对于 此种 NAT, 可以辅助 NAT穿越技术（如 UDP打洞技术）来使得双方用户能 够正常通信。 为了支持通信双方用户出于 NAT之后的场景，运营商可以部署 额外的具有公网地址的服务器， 以支持诸如 UDP打洞技术等的 NAT。 例如， 可以增强 Push服务器的功能， 使其可以支持 NAT穿越。 例如， Push服务器 在将用户 Push标识和网络地址进行地址转换时， 可以将用户 Push标识与网 络地址和端口号的集合进行地址转换。 另外， 当 Push消息在 Push服务器之 间路由时， 跨越不同域的 Push消息携带的网络地址需要是 NAT转换之后的 公网地址。

图 10 图示了才艮据本发明实施例的再一业务通信方法的示意图。 如图 10 所示， 在 S05中， 通信两端用户即源端用户和目的端用户分别接入网络， 例 如接入分组交换域（packet switch, 简称" PS" ) , 两端用户已经互相获知对端 的用户 Push标识， 获知方式可以是离线的或在线的， 类似于生活中人们互相 获知电话号码。 才艮据对端的用户 Push标识， 终端可以向另一个对端发起基于 Push的业务通信。

在 S 10中， 源应用客户端与源 Push客户端启动获取标识过程， 该标识包 括源用户 Push标识、 目的用户 Push标识和应用标识。 在 S15中， 源 Push客户端接收来自源应用客户端发送的业务信息， 并基 于该业务信息生成携带有用于识别目的端用户的目的端用户 Push 标识的 Push消息， 该 Push消息还可携带用于识别源端用户的源端用户 Push标识和 / 或用于识别业务类型的应用标识。 随后源 Push客户端将所生成的 Push消息 发送源 Push服务器， 其中该源 Push服务器包括源端用户归属的 Push服务器 或者该源端用户所在的漫游域内的 Push服务器；

在 S20中， 源 Push服务器对所接收的 Push消息中携带的应用标识进行 认证， 以防止非授权的应用 Push垃圾消息， 该源 Push服务器还可对两端用 户 Push标识进行认证。 在 Push消息通过认证后， 该源 Push服务器根据目的 端用户 Push标识确定目的端用户所归属的目的 Push服务器。

其中， 如果源 Push服务器根据 Push消息携带的目的端用户 Push标识确 定目的端用户所归属的目的 Push服务器就是它本身， 也就是源 Push服务器 和目的 Push服务器是相同的对象，则此时源 Push服务器根据目的端用户 Push 标识进行地址转换， 获得到达目的 Push客户端的网络地址， 并基于该地址将 Push消息发送给目的 Push客户端 （S35 ) 。 如果源端用户和目的端用户分别 归属于不同的 Push服务器， 那么源端 Push服务器可以根据目的端用户 Push 标识中的标志位将该 Push 消息路由到目的端用户归属的目的 Push服务器 ( S25 ) 。

在 S30中， 类似地， 目的 Push服务器对所接收的 Push消息中的应用标 识和 /或用户 Push标识进行认证。在 Push消息通过认证后， 目的 Push服务器 根据目的端用户 Push标识进行地址转换以获取目的端用户的当前 IP地址， 并向目的 Push客户端转发该 Push消息。 例如， 目的 Push服务器可以根据在 目的 Push服务器中存储的用户 Push标识和用户网络地址之间的映射关系来 得到目的端用户的网络地址，也可以根据目的端用户 Push标识向网络中存储 有该映射关系的特定网元查询目的端用户的网络地址。

在 S35中， 当釆用图 1的网络架构时， 目的 Push服务器需要通过数据网 关节点将 Push消息发送给目的端用户。 此时由于目的用户的 IP地址例如是 由目的端 GGSN分配的， 因此目的 Push服务器转发的 Push消息首先到达目 的端 GGSN, 然后该 GGSN将该 Push消息转发给目的 Push客户端。 但是本 发明实施例也不排除目的 Push服务器通过诸如基站之类的接入设备或者直接 发送给目的端用户， 只要由目的 Push服务器转发的 Push消息可以到达目的 端用户终端设备即可。

在 S40中， 目的 Push客户端提示目的端用户有 Push消息到达。

在 S45中， 当目的 Push客户端确定可以处理 Push消息的应用程序没有 启动时， 在得到目的端用户的确认之后启动应用程序， 以与源端用户共享业 务。 随后， 用户根据需要进行后续的直接通信（S50 ) 。

在本发明实施例提供的业务通信方法中，根据 Push消息中携带的目的端 用户 Push标识来进行地址转换以找到目的端用户，使得源端用户和目的端用 户之间的通信能够利用 Push标识来完成， 而无需涉及第三方应用服务器。 因 此， 根据本发明实施例提供的业务通信方法， 用户不需要始终运行应用客户 端， 也不需要维持应用在线就可以实现通信， 从而能够节约网络和终端资源， 减少终端耗电； 并且由于不依赖于第三方应用服务器的 Push通信方式， 从而 能够实现用户间的直接通信， 减少了第三方应用服务器的维护费用， 降低通 信延迟； 由此本发明实施例通过 Push方式的通信， 使得用户之间可以随时随 地分享信息。

接下来， 描述根据本发明实施例的业务通信的系统。 图 11图示了根据本 发明实施例的业务通信的系统 1100的示意图， 并且图 12图示了根据本发明 实施例的业务通信的另一系统 1200的示意图。

如图 11所示，系统 1100包括源 Push客户端 1110、目的 Push服务器 1120 和目的 Push客户端 1130。

源 Push客户端 1110可以生成 Push消息， 该 Push消息携带用于识别目 的端用户的目的端用户 Push标识， 并且源 Push客户端 1110可以将所生成的 Push消息发送给目的端用户归属的目的 Push服务器 1120。 目的 Push服务器 1120可以根据目的端用户 Push标识进行获得到达目的 Push客户端 1130的网 络地址， 并基于网络地址将 Push消息发送给目的 Push客户端 1130。

源 Push客户端 1110、 目的 Push服务器 1120和目的 Push客户端 1130 的上述和其他操作和 /或功能可以参考上述方法 200至 1000中的相应部分， 为了避免重复， 在此不再赘述。

根据本发明实施例提供的业务通信的系统， 目的 Push服务器根据 Push 消息中携带的目的端用户 Push标识来进行地址查询以找到目的端用户，使得 源端用户和目的端用户之间的通信能够利用 Push标识来完成而无需涉及第三 方应用服务器。 因此， 本发明实施例能够在不依赖第三方应用服务器的情况 下仍建立各种业务通信， 从而避免用户时刻保持应用在线或定期去服务器查 询， 同时仍可实时获得通信对端发送的消息或内容， 由此本发明实施例能够 节省终端耗电并节省网络资源。

如图 12所示， 系统 1200可以包括源 Push客户端 1210、 目的 Push服务 器 1220和目的 Push客户端 1230。系统 1200的源 Push客户端 1210、目的 Push 服务器 1220和目的 Push客户端 1230与系统 1100的源 Push客户端 1110、目 的 Push服务器 1120和目的 Push客户端 1130基本相同。

系统 1200还可以包括源 Push服务器 1215。 在源 Push服务器 1215与目 的 Push服务器 1220不同时，源 Push客户端 1210将 Push消息发送给源 Push 服务器 1215; 以及源 Push服务器 1215根据目的端用户 Push标识将 Push消 息发送给目的端用户归属的目的 Push服务器 1220, 其中该源 Push服务器可 以包括源端用户归属的 Push服务器，也可以包括该源端用户所在的漫游域内 的 Push服务器。

根据本发明的实施例， Push消息还可以携带有用于识别源端用户的源端 用户 Push标识和 /或用于识别业务类型的应用标识。

在本发明实施例中， 系统 1200还可以包括应用客户端 1205。 源 Push客 户端 1220接收的业务信息可以来自应用客户端 1205。 该应用客户端 1205可 以包括下列集合中的一种或多种： 能够与所述源 Push客户端通信的通讯录、 第三方应用客户端、 代理客户端和 RCS。

在本发明实施例中，应用客户端 1205和源 Push客户端 1210中的至少一 个可以通过查询源端用户终端来获取 Push消息携带的目的端用户 Push标识、 源端用户 Push标识或应用标识。也就是说， Push消息携带的目的端用户 Push 标识、 源端用户 Push标识或应用标识可以由应用客户端或源 Push客户端通 过向源端用户终端查询而获得。

另外， Push消息携带的目的端用户 Push标识、 源端用户 Push标识或应 用标识可以由应用客户端 1205直接查询存储在应用客户端 1205内的相关映 射关系而获得。

在本发明实施例中， 系统 1200还可以包括网络侧设备 1240。 Push消息 携带的目的端用户 Push标识、 源端用户 Push标识或应用标识可以由应用客 户端 1205或源 Push客户端 1210向网络侧设备 1240查询而获得。 网络侧设 备 1240可以是现有网元或者新增加的网元， 在其中存储有用户 Push标识与 用户的对应关系或者应用标识与应用程序的对应关系。例如，网络侧设备 1240 可以是存储有用户 Push标识和用户之间对应关系的网络侧设备的终端地址 薄， 网络侧设备 1240 也可以是存储有应用标识与应用程序之间对应关系的 Push服务器。

在本发明实施例中， 目的 Push服务器 1220还可以对 Push消息中携带的 应用标识进行认证， 以及基于网络地址将经过认证的 Push 消息发送给目的 Push客户端 1230。 通过对应用标识进行认证， 能够防止非授权的垃圾 Push 消息通过网络， 从而能够节省网络资源， 维护网络环境。

同样地， 目的 Push服务器 1220还可以对 Push消息中携带的目的端用户 Push标识和 /或源端用户 Push标识进行认证， 以及基于网络地址将经过认证 的 Push消息发送给目的 Push客户端 1230。 通过对用户 Push标识进行认证， 能够保证只有合法、 授权的用户能够进行该通信。

在本发明实施例中， 当源端用户和目的端用户归属于不同的 Push服务器 时， 也就是源 Push服务器和目的 Push服务器不同时， 图 12所示的源 Push 服务器 1215可以根据目的端用户 Push标识中的标志位将 Push消息发送给目 的 Push服务器 1220。 此时， 源 Push服务器 1215可以基于目的端用户 Push 标识中的标志位首先确定源 Push服务器 1215 自身不是目的 Push服务器， 然 后根据标志位查找在源 Push服务器 1215内存储的或者在特定网元中存储的 与标志位相应的 Push服务器的网络地址， 也就是目的 Push服务器 1220的网 络地址， 然后根据目的 Push服务器 1220的网络地址将 Push消息发送给目的 Push服务器 1220。

在本发明实施例中， 当用户处于漫游状态即用户从家乡域移动到其他域 时， 根据本发明实施例的业务通信系统还可以包括目的端用户所在的漫游域 内的漫游域 Push服务器， 其中目的 Push服务器将 Push消息发送给该漫游域 Push服务器；该漫游域 Push服务器基于网络地址将 Push消息发送给目的 Push 客户端。

在本发明实施例中， 目的 Push客户端 1230可以在接收到 Push消息后提 示目的端用户有 Push消息到达。 其中目的 Push客户端可以通过提示框、 声 音、 图片、 振动等方式来进行提示。 在目的 Push客户端 1230收到 Push消息 后， 目的 Push客户端 1230在确定与应用标识相应的应用程序没有启动的情 况下启动应用程序。在启动应用程序的过程中，优选地，目的 Push客户端 1230 可以在确定与应用标识相应的应用程序没有启动的情况下， 首先向目的端用 户提示是否启动应用程序， 然后在接收到目的端用户确认启动应用程序的确 认信息时启动应用程序。

系统 1200的应用客户端 1205、源 Push客户端 1210、源 Push服务器 1215、 目的 Push服务器 1220、 目的 Push客户端 1230和网络侧设备 1240的上述和 其他操作和 /或功能可以参考上述方法 200至 1000的相应部分， 为了避免重 复， 在此不再赘述。

在根据本发明实施例提供的业务通信的系统中， 目的 Push服务器根据 Push消息中携带的目的端用户 Push标识来进行地址转换以找到目的端用户， 使得源端用户和目的端用户之间的通信能够利用 Push标识来完成， 而无需涉 及第三方应用服务器。 由于用户不需要始终运行应用客户端， 也不需要维持 应用在线就可以实现通信， 因此本发明实施例能够节约网络和终端资源， 减 少终端耗电； 并且由于本发明实施例不依赖于第三方应用服务器的 Push通信 方式， 实现了用户间的直接通信， 由此能够减少第三方应用服务器的维护费 用， 并且降低通信延迟， 使得用户之间可以随时随地分享信息。

另外， 由于 Push服务器可以对应用标识进行认证， 因此能够防止非授权 的应用 Push垃圾信息在网络中传输， 进一步节省网络资源， 并保证合法的网 络应用环境。 另一方面， Push服务器可以对用户 Push标识进行认证， 因此能 够确保 Push用户身份的合法性， 防止违法用户使用该 Push服务。 此外， 由 于 Push客户端可以在相应的应用程序没有启动的情况下拉起应用程序，使得 应用程序不用保持开启状态， 甚至不用保持始终在线， 而仅在需要时才被启 动， 由此本发明实施例能够节省终端功耗， 并降低终端设备中的资源使用。

接下来， 描述根据本发明实施例的用于业务通信的 Push客户端。 图 13 图示了根据本发明实施例的用于业务通信的 Push客户端 1300的结构框图。

Push客户端 1300可以包括生成模块 1310和发送模块 1320。 生成模块 1310可以用于生成 Push消息， Push消息携带有用于识别目的端用户的目的 端用户 Push标识。 发送模块 1320可以用于将生成模块 1310生成的 Push消 息发送给该目的端用户归属的目的 Push服务器， 以使得该目的 Push服务器 根据该目的端用户 Push标识获得到达目的 Push客户端的网络地址， 并使得 该目的 Push服务器基于该网络地址将该 Push消息发送给该目的 Push客户端。

生成模块 1310和发送模块 1320的上述和其他操作和 /或功能可以参考上 述方法 200至 1000的相应部分， 为了避免重复， 在此不再赘述。 根据本发明实施例提供的用于业务通信的 Push客户端， Push客户端将目 的端用户 Push标识携带在 Push消息中，使得目的 Push服务器可以根据 Push 消息中携带的目的端用户 Push标识来进行地址转换以找到目的端用户，从而 源端用户和目的端用户之间的通信能够利用 Push标识来完成而无需涉及第三 方应用服务器。 因此， 本发明实施例能够在不依赖第三方应用服务器的情况 下仍建立各种业务通信， 从而避免用户时刻保持应用在线或定期去服务器查 询， 同时仍可实时获得通信对端发送的消息或内容， 由此本发明实施例能够 节省终端耗电并节省网络资源。

图 14图示了根据本发明实施例的用于业务通信的 Push客户端 1400的另 一结构框图。

Push客户端 1400可以包括生成模块 1410和发送模块 1420。 生成模块 1410可以用于生成 Push消息， Push消息携带有用于识别目的端用户的目的 端用户 Push标识。 发送模块 1420可以用于将生成模块 1410生成的 Push消 息发送给该目的端用户归属的目的 Push服务器， 以使得该目的 Push服务器 根据该目的端用户 Push标识获得到达目的 Push客户端的网络地址， 并使得 该目的 Push服务器基于该网络地址将该 Push消息发送给该目的 Push客户端。 Push客户端 1400的生成模块 1410和发送模块 1420与 Push客户端 1300的生 成模块 1310和发送模块 1420基本相同。

在本发明实施例中，发送模块 1420用于将生成模块 1410生成的 Push消 息发送给目的端用户归属的目的 Push服务器可以包括： 发送模块 1420具体 用于将该生成模块 1410生成的该 Push消息发送给源 Push服务器， 以使得该 源 Push服务器根据该目的端用户 Push标识将该 Push消息发送给该目的端用 户归属的目的 Push服务器， 其中该源 Push服务器可以包括源端用户归属的 Push服务器或者该源端用户所在的漫游域内的漫游域 Push服务器。

Push客户端 1400还可以包括第一接收模块 1430。第一接收模块 1430可 以用于接收目的 Push服务器基于网络地址而发送的 Push消息。 Push客户端 1400还可以包括第二接收模块 1440。第二接收模块 1440可 以用于接收来自应用客户端的业务信息， 其中应用客户端可以包括具有与 Push客户端 1400通信的 Push接口的通讯录、 第三方应用客户端、 代理客户 端和 RCS中的一种或多种， 并且其中生成模块 1410可以基于第二接收模块 1440接收的业务信息生成 Push消息。

Push客户端 1400还可以包括获取模块 1450。获取模块 1450可以用于获 取目的端用户 Push标识、 用于识别源端用户的源端用户 Push标识和用于识 别业务类型的应用标识中的一种或多种，其中生成模块 1410可以根据获取模 块 1450获取的目的端用户 Push标识、 源端用户 Push标识和应用标识生成 Push消息。

根据本发明的实施例，获取模块 1450可以用于通过向源端用户终端查询 而获取目的端用户 Push标识、源端用户 Push标识或应用标识。获取模块 1450 还可以用于从应用客户端获取目的端用户 Push标识、 源端用户 Push标识或 应用标识， 其中目的端用户 Push标识、 源端用户 Push标识或应用标识由应 用客户端通过向源端用户终端查询而获得， 或由应用客户端通过直接查询存 储在应用客户端内的相关映射关系而获得， 或由应用客户端通过向网络侧设 备查询而获得。获取模块 1450还可以用于通过向网络侧设备查询而获取目的 端用户 Push标识、 源端用户 Push标识或应用标识。

Push客户端 1400还可以包括提示模块 1460。提示模块 1460可以用于在 第一接收模块 1430接收到 Push消息后提示目的端用户有 Push消息到达。

Push客户端 1400还可以包括启动模块 1470。启动模块 1470可以用于在 第一接收模块 1430接收到 Push消息后， 在确定与所用标识相应的应用程序 没有启动的情况下启动所述应用程序。 例如， 启动模块 1470可以用于在确定 与应用标识相应的应用程序没有启动的情况下， 首先向目的端用户提示是否 启动应用程序， 然后在接收到目的端用户确认启动应用程序的确认信息的情 况下启动应用程序。 Push客户端 1400的生成模块 1410、发送模块 1420、第一接收模块 1430、 第二接收模块 1440、 获取模块 1450、提示模块 1460和启动模块 1470的上述 和其他操作和 /或功能， 可以参考上述方法 200至 1000的相应部分， 为了避 免重复， 在此不再赘述。

根据本发明实施例的用于业务通信的 Push客户端， Push客户端将目的端 用户 Push标识携带在 Push消息中， 使得目的 Push服务器可以根据 Push消 息中携带的目的端用户 Push标识来进行地址转换以找到目的端用户，从而源 端用户和目的端用户之间的通信能够利用 Push标识来完成而无需涉及第三方 应用服务器， 因此本发明实施例能够节省终端耗电并节省网络资源。 另外， 由于启动模块在接收到 Push消息时如果发现相应的应用程序没有启动才会启 动应用程序， 因此用户不需要始终运行应用客户端， 也不需要维持应用在线 就可以实现通信，从而能够进一步节约网络和终端资源，减少终端耗电。 Push 客户端通过与 Push服务器之间的交互过程来进行业务通信， 不需要依赖于第 三方应用服务器， 实现了用户间的直接通信， 减少了第三方应用服务器的维 护费用， 并且降低了通信延迟。 同时， 由于用户借助于 Push客户端来通过 Push方式进行通信， 使得用户之间可以随时随地分享信息。

图 15图示了根据本发明实施例的用于业务通信的用户设备 1500的结构 框图。

如图 15所示， 用户设备 1500包括上述的 Push客户端 1510。 用户设备 1500借助于 Push客户端 1510,可以生成携带有目的端用户 Push标识的 Push 消息， 使得目的 Push服务器可以根据 Push消息中携带的目的端用户 Push标 识来进行地址查询以找到目的端用户， 从而源端用户和目的端用户之间的通 信能够利用 Push标识来完成而无需涉及第三方应用服务器， 因此便利了通信 双方的通信。另外，由于用户设备 1500中的 Push客户端 1510具有启动模块， 在接收到 Push消息时如果发现相应的应用程序没有启动才会启动应用程序， 因此用户不需要始终运行应用客户端， 也不需要维持应用在线就可以实现通 信， 从而节约了网络和终端资源， 减少了用户设备 1500的功率消耗。 用户设 备 1500中的 Push客户端 1510通过与 Push服务器之间的交互过程来进行业 务通信， 不需要依赖于第三方应用服务器， 实现了用户间的直接通信， 减少 了第三方应用服务器的维护费用， 并且降低了通信延迟。 同时， 用户借助于 具有 Push客户端 1510的用户设备 1500来通过 Push方式进行通信， 使得用 户之间可以随时随地分享信息。

本领域技术人员可以意识到， 结合本文中所公开的实施例中描述的各方 法步骤和单元， 能够以电子硬件、 计算机软件或者二者的结合来实现， 为了 清楚地说明硬件和软件的可互换性， 在上述说明中已经按照功能一般性地描 述了各实施例的步骤及组成。 这些功能究竟以硬件还是软件方式来执行， 取 决于技术方案的特定应用和设计约束条件。 本领域技术人员可以对每个特定 的应用使用不同方法来实现所描述的功能， 但是这种实现不应认为超出本发 明的范围。

结合本文中所公开的实施例描述的方法步骤可以用硬件、 处理器执行的 软件程序、 或者二者的结合来实施。 软件程序可以置于随机存取存储器 ( RAM ) 、 内存、 只读存储器 （ROM ) 、 电可编程 ROM、 电可擦除可编程 ROM, 寄存器、 硬盘、 可移动磁盘、 CD-ROM或技术领域内所公知的任意其 它形式的存储介质中。

尽管已示出和描述了本发明的一些实施例，但本领域技术人员应该理解， 在不脱离本发明的原理和精神的情况下， 可对这些实施例进行各种修改， 这 样的修改应落入本发明的范围内。

Claims

权 利 要 求

1、 一种业务通信的方法， 其特征在于， 包括：

源推送 Push客户端生成 Push消息， 所述 Push消息携带用于识别目的端 用户的目的端用户 Push标识；

所述源 Push客户端将所述 Push消息发送给所述目的端用户归属的目的 Push服务器， 以使得所述目的 Push服务器根据所述目的端用户 Push标识获 得到达目的 Push客户端的网络地址， 并使得所述目的 Push服务器基于所述 网络地址将所述 Push消息发送给所述目的 Push客户端。

2、 根据权利要求 1所述的方法， 其特征在于， 所述源 Push客户端将所 述 Push消息发送给所述目的端用户归属的目的 Push服务器包括：

所述源 Push客户端将所述 Push消息发送给源 Push服务器， 以使得所述 源 Push服务器根据所述目的端用户 Push标识将所述 Push消息发送给所述目 的端用户归属的目的 Push服务器。

3、 根据权利要求 2所述的方法， 其特征在于， 所述源 Push服务器包括 源端用户归属的 Push服务器或者所述源端用户所在的漫游域内的漫游域 Push服务器。

4、根据权利要求 1至 3中任一项所述的方法， 其特征在于， 所述源 Push 客户端生成 Push消息包括：

所述源 Push客户端基于接收的来自应用客户端的业务信息生成 Push消 息， 其中所述应用客户端包括下列集合中的一种或多种： 能够与所述源 Push 客户端通信的通讯录、 第三方应用客户端、 代理客户端和富通信套件 RCS。

5、 根据权利要求 4所述的方法， 其特征在于， 所述 Push消息还携带有 用于识别源端用户的源端用户 Push标识和 /或用于识别业务类型的应用标识。

6、 根据权利要求 5所述的方法， 其特征在于， 所述 Push消息携带的所 述目的端用户 Push标识、 所述源端用户 Push标识或所述应用标识由所述应 用客户端或所述源 Push客户端通过向源端用户终端查询而获得。

7、 根据权利要求 5所述的方法， 其特征在于， 所述 Push消息携带的所 述目的端用户 Push标识、 所述源端用户 Push标识或所述应用标识由所述应 用客户端直接查询存储在所述应用客户端内的相关映射关系而获得。

8、 根据权利要求 5所述的方法， 其特征在于， 所述 Push消息携带的所 述目的端用户 Push标识、 所述源端用户 Push标识或所述应用标识由所述应 用客户端或所述源 Push客户端向网络侧设备查询而获得。

9、 根据权利要求 5所述的方法， 其特征在于， 所述目的 Push服务器基 于所述网络地址将所述 Push消息发送给所述目的 Push客户端包括：

所述目的 Push服务器对所述 Push消息中携带的所述应用标识进行认证； 所述目的 Push服务器基于所述网络地址将经过认证的所述 Push消息发 送给所述目的 Push客户端。

10、 根据权利要求 5所述的方法， 其特征在于， 所述目的 Push服务器基 于所述网络地址将所述 Push消息发送给所述目的 Push客户端包括：

所述目的 Push服务器对所述 Push消息中携带的所述目的端用户 Push标 识和所述源端用户 Push标识进行认证；

所述目的 Push服务器基于所述网络地址将经过认证的所述 Push消息发 送给所述目的 Push客户端。

11、 根据权利要求 2或 3所述的方法， 其特征在于， 所述源 Push服务器 根据所述目的端用户 Push标识将所述 Push消息发送给所述目的 Push服务器 包括：

所述源 Push服务器根据所述目的端用户 Push标识中的标志位将所述 Push消息发送给所述目的 Push服务器。

12、 根据权利要求 1至 3中任一项所述的方法， 其特征在于， 所述目的 Push服务器基于所述网络地址将所述 Push消息发送给所述目的 Push客户端 包括： 所述目的 Push服务器将所述 Push消息发送给所述目的端用户所在的漫 游域内的漫游域 Push服务器；

所述漫游域 Push服务器基于所述网络地址将所述 Push消息发送给所述 目的 Push客户端。

13、 一种业务通信的系统， 其特征在于， 包括： 源 Push客户端、 目的 Push客户端和目的 Push服务器， 其中，

所述源 Push客户端生成 Push消息， 所述 Push消息携带用于识别目的端 用户的目的端用户 Push标识；

所述源 Push客户端将所述 Push消息发送给所述目的端用户归属的所述 目的 Push服务器；

所述目的 Push服务器根据所述目的端用户 Push标识获得到达所述目的 Push客户端的网络地址；

所述目的 Push服务器基于所述网络地址将所述 Push消息发送给所述目 的 Push客户端。

14、根据权利要求 13所述的系统， 其特征在于， 所述系统还包括源 Push 服务器， 其中所述源 Push客户端将所述 Push消息发送给所述目的端用户归 属的目的 Push服务器包括：

所述源 Push客户端将所述 Push消息发送给所述源 Push服务器； 所述源 Push服务器根据所述目的端用户 Push标识将所述 Push消息发送 给所述目的端用户归属的目的 Push服务器。

15、 根据权利要求 14所述的系统， 其特征在于， 所述源 Push服务器包 括源端用户归属的 Push服务器或者所述源端用户所在的漫游域内的 Push服 务器。

16、 根据权利要求 13至 15中任一项所述的系统， 其特征在于， 所述系 统还包括应用客户端，其中所述源 Push客户端基于接收的来自所述应用客户 端的业务信息生成 Push消息，所述应用客户端包括下列集合中的一种或多种： 能够与所述源 Push客户端通信的通讯录、 第三方应用客户端、 代理客户端和

17、 根据权利要求 16所述的系统， 其特征在于， 所述 Push消息还携带 有用于识别源端用户的源端用户 Push标识和 /或用于识别业务类型的应用标 识。

18、 根据权利要求 17所述的系统， 其特征在于， 所述 Push消息携带的 所述目的端用户 Push标识、 所述源端用户 Push标识或所述应用标识由所述 应用客户端或所述源 Push客户端通过向源端用户终端查询而获得。

19、 根据权利要求 17所述的系统， 其特征在于， 所述 Push消息携带的 所述目的端用户 Push标识、 所述源端用户 Push标识或所述应用标识由所述 应用客户端直接查询存储在所述应用客户端内的相关映射关系而获得。

20、 根据权利要求 17所述的系统， 其特征在于， 所述系统还包括网络侧 设备， 其中所述 Push消息携带的所述目的端用户 Push标识、 所述源端用户 Push标识或所述应用标识由所述应用客户端或所述源 Push客户端向所述网 络侧设备查询而获得。

21、 根据权利要求 17所述的系统， 其特征在于， 所述目的 Push服务器 对所述 Push消息中携带的所述应用标识进行认证， 以及基于所述网络地址将 经过认证的所述 Push消息发送给所述目的 Push客户端。

22、 根据权利要求 17所述的系统， 其特征在于， 所述目的 Push服务器 对所述 Push消息中携带的所述目的端用户 Push标识和所述源端用户 Push标 识进行认证，以及基于所述网络地址将经过认证的所述 Push消息发送给所述 目的 Push客户端。

23、 根据权利要求 14或 15所述的系统， 其特征在于， 所述源 Push服务 器根据所述目的端用户 Push标识中的标志位将所述 Push消息发送给所述目 的 Push服务器。

24、 根据权利要求 13至 15中任一项所述的系统， 其特征在于， 所述系 统还包括所述目的端用户所在的漫游域内的漫游域 Push服务器，其中所述目 的 Push服务器将所述 Push消息发送给所述漫游域 Push服务器； 所述漫游域 Push服务器基于所述网络地址将所述 Push消息发送给所述目的 Push客户端。

25、 根据权利要求 13至 15中任一项所述的系统， 其特征在于， 所述目 的 Push客户端在收到所述 Push消息后提示目的端用户有 Push消息到达。

26、 根据权利要求 13至 15中任一项所述的系统， 其特征在于， 在所述 目的 Push客户端收到所述 Push消息后， 所述目的 Push客户端在确定与所述 应用标识相应的应用程序没有启动的情况下启动所述应用程序。

27、 根据权利要求 26所述的系统， 其特征在于， 所述目的 Push客户端 在确定与所述应用标识相应的应用程序没有启动的情况下， 首先向目的端用 户提示是否启动所述应用程序， 然后在接收到目的端用户确认启动所述应用 程序的确认信息时启动所述应用程序。

28、 一种用于业务通信的 Push客户端， 其特征在于， 包括：

生成模块， 用于生成 Push消息， 所述 Push消息携带有用于识别目的端 用户的目的端用户 Push标识；

发送模块，用于将所述生成模块生成的所述 Push消息发送给所述目的端 用户归属的目的 Push服务器， 以使得所述目的 Push服务器根据所述目的端 用户 Push标识获得到达目的 Push客户端的网络地址， 并使得所述目的 Push 服务器基于所述网络地址将所述 Push消息发送给所述目的 Push客户端。

29、 根据权利要求 28所述的 Push客户端， 其特征在于， 所述发送模块 用于将所述生成模块生成的所述 Push消息发送给所述目的端用户归属的目的 Push服务器包括： 所述发送模块具体用于将所述生成模块生成的所述 Push 消息发送给源 Push服务器， 以使得所述源 Push服务器根据所述目的端用户 Push标识将所述 Push消息发送给所述目的端用户归属的目的 Push服务器， 其中所述源 Push服务器包括源端用户归属的 Push服务器或者所述源端用户 所在的漫游域内的漫游域 Push服务器。

30、 根据权利要求 28所述的 Push客户端， 其特征在于， 所述 Push客户 端还包括：

第一接收模块， 用于接收目的 Push服务器基于网络地址而发送的 Push 消息。

31、 根据权利要求 28至 30中任一项所述的 Push客户端， 其特征在于， 所述 Push客户端还包括：

第二接收模块， 用于接收来自应用客户端的业务信息， 其中所述应用客 户端包括下列集合中的一种或多种：能够与所述源 Push客户端通信的通讯录、 第三方应用客户端、 代理客户端和 RCS , 并且其中所述生成模块基于所述第 二接收模块接收的所述业务信息生成所述 Push消息。

32、 根据权利要求 28至 30中任一项所述的 Push客户端， 其特征在于， 所述 Push客户端还包括：

获取模块， 用于获取所述目的端用户 Push标识、 用于识别源端用户的源 端用户 Push标识和用于识别业务类型的应用标识中的一种或多种，其中所述 生成模块根据所述获取模块获取的所述目的端用户 Push标识、所述源端用户 Push标识和所述应用标识中的一种或多种生成所述 Push消息。

33、 根据权利要求 32所述的 Push客户端， 其特征在于， 所述获取模块 通过向源端用户终端查询而获取所述目的端用户 Push标识、 所述源端用户 Push标识或所述应用标识。

34、 根据权利要求 32所述的 Push客户端， 其特征在于， 所述获取模块 从所述应用客户端获取所述目的端用户 Push标识、 所述源端用户 Push标识 或所述应用标识 , 其中所述目的端用户 Push标识、 所述源端用户 Push标识 或所述应用标识由所述应用客户端通过向源端用户终端查询而获得， 或由所 述应用客户端通过直接查询存储在所述应用客户端内的相关映射关系而获 得， 或由所述应用客户端通过向网络侧设备查询而获得。

35、 根据权利要求 32所述的 Push客户端， 其特征在于， 所述获取模块 通过向网络侧设备查询而获取所述目的端用户 Push标识、所述源端用户 Push 标识或所述应用标识。

36、 根据权利要求 30所述的 Push客户端， 其特征在于， 所述 Push客户 端还包括：

提示模块，用于在所述第一接收模块接收到所述 Push消息后提示目的端 用户有 Push消息到达。

37、 根据权利要求 30所述的 Push客户端， 其特征在于， 所述 Push客户 端还包括：

启动模块， 用于在所述第一接收模块接收到所述 Push消息后， 在确定与 所述应用标识相应的应用程序没有启动的情况下启动所述应用程序。

38、 根据权利要求 37所述的 Push客户端， 其特征在于， 所述启动模块 还用于在确定与所述应用标识相应的应用程序没有启动的情况下， 首先向目 的端用户提示是否启动所述应用程序， 然后在接收到目的端用户确认启动所 述应用程序的确认信息的情况下启动所述应用程序。

39、 一种用于业务通信的用户设备， 其特征在于， 所述用户设备包括根 据权利要求 28或 29所述的 Push客户端。