推消息处理方法、用于实现推消息处理方法的系统及设备

摘要

本发明公开了一种推消息处理方法、用于实现推消息处理方法的系统及设备，推消息处理方法包括：消息接收设备接收消息发送系统发送的包含推应用标识的推消息；消息接收设备根据所述推应用标识匹配相应的应用客户端，判断匹配的应用客户端是否已注册，以及所述匹配的应用客户端生成的推消息响应能力文件是否获得签名；若所述匹配的应用客户端已注册，且其推消息响应能力文件获得签名，启动所述匹配的应用客户端处理接收到的推消息；若所述匹配的应用客户端未注册，或其推消息响应能力文件未获得签名，则拒绝处理接收到的推消息。使得处理推消息的应用客户端安全可控，提高了推消息处理的安全性。

说明书

技术领域

本发明涉及通信技术，尤其涉及一种推消息处理方法、用于实现推消息处理方法的系统及设备。

背景技术

移动网络的推消息(PUSH消息)业务是移动网络中的基础业务。

移动网络运营商(或者增值业务提供商)可以通过PUSH消息业务，向移动网络终端发送控制类型的消息。例如，当移动终端用户(发方用户)向另外的移动终端用户(收方用户)发送多媒体消息(MMS)时，移动网络运营系统会向收方用户终端发送提取MMS消息的PUSH消息，收方用户终端根据PUSH消息的提示，到约定的网络地址提取MMS消息。另外，移动网络的增值业务提供商，向收方用户发送多媒体广告信息链接信息，收方用户终端接收到相关信息后，根据信息的约定，启动终端中的广告播放应用软件，广告播放应用软件按约定的信息播放广告。

PUSH消息处理系统包括：消息发送系统(设备)、消息递送系统及消息接收设备。移动网络运营商(或者增值业务提供商)通过消息发送系统(设备)生成并发送PUSH消息给消息递送系统，消息递送系统将PUSH消息推送给消息接收设备如收方用户终端。

但是PUSH消息的发送也存在通信安全问题，如PUSH消息是否来自恶意发送者，PUSH消息本身是否安全等。

现有技术中，申请号为200610137955.7的中国专利申请《一种用于验证PUSH消息及其发送方身份的方法》，通过推送发起者(PUSH Initiator，PI)的IP地址或PI在证书认证中心(Certificate Authority，CA)登记获得的数字证书验证PI的身份，并通过PUSH消息的数字签名验证PUSH消息的完整性，以防止通信过程中的任何攻击，实现PUSH消息发送过程中的安全性。

另外，为了保证安全，移动网络的运营商通常不开放PUSH消息的发送权，以针对现有PUSH消息处理技术和标准中没有统一安全控制机制的情况，确定PUSH消息发送安全。

现有技术存在的缺陷至少在于：上述方法虽然都能够保证PUSH消息发送过程中的安全性，但是都无法保证PUSH消息的处理安全可控。如一个实体(例如，移动网络运营商、增值业务提供商，称为发方实体)向另一个实体(例如，移动业务用户，称为收方实体)发送PUSH消息，当应用客户端为恶意应用客户端时，在PUSH消息的触发下，会执行诸如将消息接收设备中的重要资料发送出去等攻击行为。

发明内容

本发明提供一种推消息处理方法、用于实现推消息处理方法的系统及设备，用以解决现有技术中消息接收设备处理推消息的安全性低的问题，实现推消息处理安全性的提高。

本发明提供一种推消息处理方法，包括：

消息接收设备接收消息发送系统发送的包含推应用标识的推消息；

消息接收设备根据所述推应用标识匹配相应的应用客户端，判断匹配的应用客户端是否已注册，以及所述匹配的应用客户端生成的推消息响应能力文件是否获得签名；

若所述匹配的应用客户端已注册，且其推消息响应能力文件获得签名，启动所述匹配的应用客户端处理接收到的推消息；若所述匹配的应用客户端未注册，或其推消息响应能力文件未获得签名，则拒绝处理接收到的推消息。

本发明还提供一种用于实现上述推消息处理方法的消息安全管理系统，包括：

应用管理与服务模块，用于对应用客户端的推消息响应能力文件进行签名，对所述应用客户端进行注册，并验证所述应用客户端的推消息响应能力文件的签名；

可信应用列表管理与服务模块，用于建立并维护可信应用列表，所述可信应用列表为通过注册和签名的应用客户端信息列表。

本发明还提供一种用于实现上述推消息处理方法的消息接收设备，包括：

消息接收客户端，用于接收消息发送系统发送的包含推应用标识的推消息；

消息安全管理客端，与所述消息接收客户端相连，用于根据所述消息接收客户端接收的推消息中的推应用标识，匹配相应的应用客户端，判断匹配的应用客户端是否已注册，以及所述匹配的应用客户端生成的推消息响应能力文件是否获得签名，若所述匹配的应用客户端已注册且生成的推消息响应能力文件获得签名，则调用并启动所述匹配的应用客户端处理所述推消息；

应用客户端，与所述消息安全管理客户端相连，用于在所述消息安全管理客户端的调用下，启动并处理所述消息接收客户端接收的推消息。

本发明还提供一种推消息处理系统，包括消息发送系统、消息递送系统，其中，还包括：上述消息安全管理系统及上述消息接收设备；

所述消息安全管理系统与所述消息发送系统、消息递送系统及消息接收设备通信连接；

所述消息发送系统通过所述消息递送系统，将生成的包含推应用标识的推消息发送给所述消息接收设备，所述消息接收设备用于根据所述推应用标识匹配相应的应用客户端，判断匹配的应用客户端是否已注册，以及所述匹配的应用客户端生成的推消息响应能力文件是否获得签名；若所述匹配的应用客户端已注册且生成的推消息响应能力文件获得签名，则调用并启动所述匹配的应用客户端处理所述推消息。

本发明还提供一种用于上述推消息处理系统中申请身份证书的方法，包括：

消息发送系统、消息递送系统或消息接收设备向消息安全管理系统发送申请信息，申请身份证书，所述申请信息至少包括：用户名、用户密码、用户描述及服务类型；

所述消息安全管理系统根据所述申请信息生成身份证书及对应的密钥，反馈给所述消息发送系统、消息递送系统或消息接收设备。

本发明还提供一种用于上述推消息处理系统中应用客户端签名的方法，包括：

应用客户端生成至少包括推应用标识及应用客户端标识的推消息响应能力文件；所述应用客户端发送所述推消息响应能力文件的签名请求；

消息安全管理系统支持签名请求的情况下，计算所述推消息响应能力文件的文件摘要；所述消息安全管理系统采用自身证书私钥加密所述文件摘要；

所述消息安全管理系统将加密的文件摘要加入所述推消息响应能力文件中；所述消息安全管理系统将签名结果及加入了加密的文件摘要的推消息响应能力文件反馈给所述应用客户端。

本发明还提供一种用于上述推消息处理系统中应用客户端注册的方法，包括：应用客户端安装到消息接收设备时，向消息安全管理客户端提交注册请求信息，所述注册请求信息中包含推消息响应能力文件；

所述消息安全管理客户端审核所述注册请求信息中的推消息响应能力文件；若审核通过，则所述消息安全管理客户端查询和更新可信应用列表，所述可信应用列表为通过消息安全管理系统注册和签名的应用客户端的信息列表；若审核未通过，则结束注册，反馈注册失败结果；

若所述可信应用列表中包含有提交注册请求信息的应用客户端的信息，则所述消息安全管理客户端记录所述提交注册请求信息的应用客户端的注册信息，并反馈注册成功结果；若所述可信应用列表未包含所述提交注册请求信息的应用客户端的信息，则反馈注册失败结果。

本发明提供的推消息处理方法、用于实现推消息处理方法的系统及设备，通过在推应用标识匹配的应用客户端已注册且推消息响应能力文件获得签名的情况下，启动匹配的应用客户端处理接收到的推消息，否则拒绝处理推消息，保证了处理推消息的应用客户端的安全可靠性，使得处理推消息的应用客户端安全可控，提高了推消息处理的安全性。

附图说明

图1为本发明实施例提供的推消息处理方法的流程图；

图2为本发明实施例提供的消息安全管理系统的结构示意图；

图3为本发明实施例提供的可用于实现上述推消息处理方法的消息接收设备的结构示意图；

图4为本发明实施例提供的推消息处理系统的结构示意图；

图5为本发明实施例提供的推消息处理系统中消息发送系统的结构示意图；

图6为本发明实施例提供的推消息处理系统中消息递送系统的结构示意图；

图7为本发明实施例提供的推消息处理系统中申请身份证书的方法实施例的流程图；

图8为本发明实施例提供的推消息处理系统中消息发送系统申请身份证书的信令流程图；

图9为本发明实施例提供的推消息处理系统中应用客户端签名的方法实施例的流程图；

图10为与图9对应的信令流程图；

图11A为本发明实施例提供的推消息处理系统中应用客户端注册的方法实施例的流程图；

图11B为与图11A相对应的信令流程图；

图12为本发明实施例提供的推消息处理系统递送推消息的流程图；

图13为本发明实施例提供的推消息处理系统中消息接收设备处理推消息的流程图。

具体实施方式

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

图1为本发明实施例提供的推消息处理方法的流程图。如图1所示，推消息处理方法包括：

步骤11、消息接收设备接收消息发送系统发送的包含推(PUSH)应用标识的推消息；

步骤12、消息接收设备根据所述推应用标识匹配相应的应用客户端，判断匹配的应用客户端是否已注册，以及所述匹配的应用客户端生成的推消息响应能力文件是否获得签名；

步骤13、若所述匹配的应用客户端已注册，且其推消息响应能力文件获得签名，启动所述匹配的应用客户端处理接收到的推消息；若所述匹配的应用客户端未注册，或其推消息响应能力文件未获得签名，则拒绝处理接收到的推消息。

本实施例中，消息接收设备通过在推应用标识匹配的应用客户端已注册且推消息响应能力文件获得签名的情况下，启动匹配的应用客户端处理接收到的推消息，否则拒绝处理推消息，保证了处理推消息的应用客户端的安全可靠性，使得处理推消息的应用客户端安全可控，提高了推消息处理的安全性。

上述步骤11中，推消息还可进一步包括应用客户端标识，此时，步骤12中，消息接收设备根据所述推应用标识匹配相应的应用客户端包括：消息接收设备根据所述推应用标识及应用客户端标识匹配相应的应用客户端。

当推应用标识匹配有多个应用客户端时，可通过应用客户端标识直接匹配出消息发送系统期望使用的应用客户端，来处理推消息。

其中，推应用标识是指在PUSH消息应用规范中，用于标识应用客户端程序的应用标识串(文本字符串)。推应用标识由开放移动联盟(OMA)组织维护。同一个应用客户端，可以同时响应多个推应用标识。

应用客户端标识是指用于标识应用客户端的识别串，可以使用全球用户标识(GUID)作为应用客户端标识。

上述步骤11中，消息发送系统发送的包含推应用标识的推消息，还可包括消息摘要，该消息摘要可为经过所述消息发送系统签名的摘要。

当消息摘要为经过所述消息发送系统签名的摘要时，上述步骤12之前还可进一步包括：消息接收设备根据所述推消息经过所述消息发送系统签名的摘要即摘要签名验证所述消息发送系统的身份，若验证通过，则消息接收设备根据所述推应用标识匹配相应的应用客户端；若验证未通过，则拒绝处理所述推消息。保证在消息发送方不可靠的情况下，避免处理接收到的推消息，减轻了消息接收设备的处理负荷，提高了处理推消息的效率及安全性。

基于上述实施例中推消息处理方法的思想，本发明实施例提供了可用于实现上述推消息处理方法的消息安全管理系统及消息安全管理客户端，其中消息安全管理系统对应用客户端进行安全管理，负责确保应用客户端的安全可靠性，消息安全管理客户端安装在消息接收设备中，用于协助消息安全管理系统确保应用客户端的安全可靠性。

图2为本发明实施例提供的消息安全管理系统的结构示意图，如图2所示，消息安全管理系统包括：应用管理与服务模块21及可信应用列表管理与服务模块22。

应用管理与服务模块21用于对应用客户端的推消息响应能力文件进行签名，对所述应用客户端进行注册，并验证所述应用客户端的推消息响应能力文件的签名。其中，应用客户端可直接向消息安全管理系统发起注册和签名的申请，也可通过消息发送系统转发向消息安全管理系统发送注册和前面的申请。

可信应用列表管理与服务模块22用于建立并维护通过注册和签名的应用客户端信息列表，为便于描述，将通过注册和签名的应用客户端信息列表命名为可信应用列表(下同)。当应用客户端注册及签名PUSH消息响应能力文件时，消息安全管理系统修改和维护可信应用列表。只有通过注册和签名服务的应用客户端信息才被写入可信应用列表。消息安全管理客户端可定期(或不定期)地从消息安全管理系统中下载可信应用列表，以用于消息接收设备中安装应用客户端的注册，并用于调用并启动可靠的应用客户端处理推消息，详见下述消息接收设备实施例以及应用客户端注册、推消息处理实施例中的描述。

本实施例中，消息安全管理系统为PUSH消息处理系统的安全基础设施，可作为消息递送系统的新增功能设置于消息递送系统，也可单独设置。

本发明实施例提供的消息安全管理系统还可进一步包括证书管理与服务模块23，用于根据消息发送系统、消息递送系统或消息接收设备发送的申请信息，为消息发送系统、消息递送系统或消息接收设备的申请信息提供身份证书及对应的密钥，并验证所述消息发送系统、消息递送系统或消息接收设备的身份证书，以进一步确保推消息处理系统中发送、递送及接收各个环节的功能实体的安全可靠性。尤其对于消息发送系统，只要通过向消息安全管理系统申请获取身份证书及对应的密钥，并通过消息安全管理系统的身份验证，便可成为推消息的发送方，既保证了发送方的安全性，又保证了推消息发送的开放性。

其中，申请信息至少包括：用户名、用户密码、用户描述及服务类型等信息。所述身份证书至少包括：证书格式与版本、证书编码方法、签名算法、摘要算法、证书序列号、证书主题、证书的签名机构标识及证书摘要。证书格式与版本可以采用X.509格式；证书编码方法可以使用BASE64；签名算法可以使用RSA算法；摘要算法可以采用缩微图算法(SHA-1)；证书序列号由消息安全管理系统生成，可以是随机数；证书主题，可以包括国家标识、申请者类型等；证书的签名机构标识即消息安全管理系统的标识；证书摘要用于检测证书。身份证书对应的公钥存储在身份证书中，身份证书对应的私钥存储在相应功能实体如消息发送系统、消息递送系统、消息接收设备等的安全存储地点，并可以以加密的方式存储。

图3为本发明实施例提供的可用于实现上述推消息处理方法的消息接收设备的结构示意图，如图3所示，消息接收设备包括消息接收客户端31、消息安全管理客户端32及应用客户端33。

消息接收客户端31用于接收消息发送系统发送的包含推应用标识的推消息，具体地，消息发送系统发送的推消息可通过消息递送系统转发给消息接收客户端31。

消息接收客户端31接收到PUSH消息后，把PUSH消息推送给消息安全管理客户端32，由消息安全管理客户端32对PUSH消息进行后续处理。并且，消息接收客户端31还用于接收消息安全管理客户端32的处理结果。

消息安全管理客户端32与所述消息接收客户端31相连，用于根据所述消息接收客户端31接收的推消息中的推应用标识，匹配相应的应用客户端，判断匹配的应用客户端是否已注册，以及所述匹配的应用客户端生成的推消息响应能力文件是否获得签名，若所述匹配的应用客户端已注册且生成的推消息响应能力文件获得签名，则调用并启动所述匹配的应用客户端处理所述推消息。如果推消息中包含应用客户端标识，则处理方式详见上述方法实施例中的说明，或进一步详见下文中的描述。

应用客户端33可有多个，以用于不同推消息的处理，当然，一个推消息也可以由不同的应用客户端来处理。匹配的应用客户端33在消息安全管理客户端32的调用下，启动并处理消息安全管理客户端32传递的PUSH消息内容即消息接收客户端31接收的推消息。

应用客户端33在分发到消息接收设备之前，需要向消息安全管理系统注册，并请求消息安全管理系统对应用客户端33生成的PUSH消息响应能力文件进行签名。

应用客户端33在消息接收设备中安装时，需要向消息安全管理客户端32提交的注册请求信息，注册PUSH消息响应能力。注册请求信息至少包括：签名后的推消息响应能力文件、应用客户端安装路径及应用客户端主程序的全路径。消息安全管理客户端32根据所注册请求信息对提交该注册请求信息的应用客户端进行注册。以进一步保证消息接收设备中的应用客户端都是安全可信的，从而提高消息接收设备中推消息处理的安全性。

在注册时，应用客户端33需要向消息安全管理客户端32提供由消息安全管理系统签名的PUSH消息响应能力文件。

如果应用客户端33未生成PUSH消息响应能力文件，或者该能力文件未被消息安全管理系统签名，或者应用客户端33未在消息接收设备中注册，则该应用客户端33将不具备接收和处理PUSH消息的能力，也就是说，消息安全管理客户端32不会调用该应用客户端33处理PUSH消息。

消息安全管理客户端32可以看作是消息安全管理系统在消息接收设备中的延伸，协同消息安全管理系统，解决PUSH消息的安全问题。

当消息接收客户端31接收的推消息中摘要被签名时，消息安全管理客户端32还用于根据所述消息接收客户端31接收的推消息的摘要签名，对发送所述推消息的消息发送系统进行身份验证，若身份验证通过，则匹配相应的应用客户端，调用并启动匹配的应用客户端33处理所述推消息；若身份验证未通过，则拒绝处理所述推消息。

当消息接收客户端31接收的推消息中包含有应用客户端标识，表明消息发送方已选择了处理该推消息的应用客户端，则所述消息安全管理客户端32还可用于通过所述应用客户端标识直接匹配相应的应用客户端，以满足消息发送系统的要求。

在消息安全管理客户端32审核是否接受应用客户端的注册请求时，可协同消息安全管理系统。只有在消息安全管理系统注册过的应用客户端才可以被消息安全管理客户端32接受注册。

消息安全管理客户端32可定期(或不定期)地从消息安全管理系统获取可信应用列表，以作为消息安全管理客户端32是否接受应用客户端注册请求的重要依据。

本发明实施例提供的消息接收设备还可包括：身份申请模块34，用于向消息安全管理系统申请并获取身份证书及对应的密钥，以保证推消息处理系统中的消息接收设备也安全可靠。

本实施例中，消息接收设备通过消息安全管理客户端接收来自于消息接收客户端31推送的PUSH消息。消息安全管理客户端32根据PUSH消息的推应用标识，在消息接收设备的已注册的应用客户端列表中，查找匹配的应用客户端，找到并启动匹配的应用客户端，并把PUSH消息中的内容传递给启动的匹配的应用客户端。其中，已注册的应用客户端列表为消息接收设备中已安装的应用客户端的列表。显然，信息保存在该应用客户端列表中的应用客户端，其信息必然相应地保存在可信应用列表中。而信息保存在可信应用列表中的应用客户端不一定被安装到消息接收设备中，因此，当消息安全管理客户端调用应用客户端处理推消息时，还要根据已注册的客户端应用列表查看所要调用的应用客户端是否已被安装，否则，即使该应用客户端信息保存在可信应用列表中也不可用。消息接收设备中也可没有该已注册的应用客户端列表，这种情况下，可通过消息安全管理客户端在本地可信应用列表中保存的该应用客户端信息中，增加已安装的标识，来表示可信的应用客户端是否安装在消息接收设备中，也即本地可信应用列表中还包含有应用客户端是否安装在本地的信息。当PUSH消息还包含应用客户端标识时，则消息安全管理客户端32可直接根据应用客户端标识，在已注册的应用客户端列表中找到并启动匹配的应用客户端，处理接收到的推消息，保证了应用客户端的安全性以及消息处理的安全性，并且，消息接收设备处理推消息的应用客户端可由消息发送系统来控制。

本发明实施例提供的推消息处理系统通过引入上述实施例提供的消息安全管理系统、消息安全管理客户端及消息接收设备，来实现上述推消息处理方法。

图4为本发明实施例提供的推消息处理系统的结构示意图。如图4所示，推消息处理系统包括消息发送系统41、消息递送系统42、消息安全管理系统43及消息接收设备44。

消息安全管理系统43与所述消息发送系统41、消息递送系统42及消息接收设备44通信连接。

所述消息发送系统41通过所述消息递送系统42，将生成的包含推应用标识的推消息发送给所述消息接收设备44，所述消息接收设备44用于根据所述推应用标识匹配相应的应用客户端，判断匹配的应用客户端是否已注册，以及所述匹配的应用客户端生成的推消息响应能力文件是否获得签名；若所述匹配的应用客户端已注册且生成的推消息响应能力文件获得签名，则调用并启动所述匹配的应用客户端处理所述推消息。

消息安全管理系统43可为上述图2所示实施例提供的任一种消息安全管理系统，是推消息处理系统中的核心服务系统，具有PUSH消息安全相关的管理功能，包括：应用客户端的注册签名服务、可信应用列表管理与服务等。进一步地，还可提供其它功能实体的身份证书及密钥管理与服务。

消息发送系统41用于向用户发送PUSH消息，具体可通过消息递送系统42向消息接收设备44发送PUSH消息，同时也可以提供PUSH消息中约定的服务功能。例如，消息发送系统41向用户发送的PUSH消息中，包含邀请用户访问约定的网页的信息，则消息发送系统可以向用户提供支持所述网页的WEB服务。当消息发送系统41仅用于实现上述功能时，可用现有推消息处理系统中的消息发送系统替代。当消息发送系统41具有消息发送、身份证书获取等功能时，如图5所示，图5为本发明实施例提供的推消息处理系统中消息发送系统的结构示意图。消息发送系统41可包括：消息发送模块51、应用服务模块52及身份申请模块53。

消息发送模块51用于向消息递送系统发送生成的推消息。消息发送系统生成的PUSH消息中，包含推应用标识，详见上述实施例中的说明，用于消息接收设备根据推应用标识匹配可用来处理推消息的一个或多个应用客户端。

消息发送系统41生成的PUSH消息中包含的服务，可以由应用服务模块52提供，也可以由其它应用系统提供。例如，PUSH消息中包含访问某WEB网页的服务，该WEB网页可由消息发送系统的WEB应用服务提供，也可以由其它WEB应用服务提供。

身份申请模块53用于向消息安全管理系统申请并获取身份证书及对应的密钥，身份证书详见上述实施例中的说明。

消息发送系统41还可进一步包括应用客户端管理与服务模块54，用于协同应用客户端向所述消息安全管理系统43对所述应用客户端的推消息响应能力文件进行签名，并用于协同所述应用客户端向所述消息安全管理系统43进行注册。

应用客户端管理与服务模块54还用于记录向消息安全管理系统43进行注册和签名的应用客户端的信息，以便于发送推消息时从记录的应用客户端的信息中选择相应的应用客户端，并将选择的应用客户端的应用客户端标识设置在推消息中，指示消息接收设备44启动选择的应用客户端处理推消息，以保证消息处理的安全性。

消息发送系统41还可进一步包括摘要签名模块55，用于使用所述身份申请模块53获取的身份证书及对应的密钥，对所述消息发送系统41生成的推消息的消息摘要进行签名，以便于消息安全管理系统43、消息接收设备44能够确认发送推消息的消息发送系统41的身份，保证推消息的发送方是安全可信的。

消息发送系统41还可包括客户端标识附加模块56，用于在所述消息发送系统41生成的推消息中，设置用于指示消息接收设备44启动对应的应用客户端处理所述推消息的应用客户端标识，以保证消息接收设备44用来处理推消息的应用客户端，是发送推消息的消息发送系统已知的，推消息的处理是安全的。即消息发送模块51发送的推消息中还可以包含应用客户端标识，这样，消息发送系统41可以明确指明生成的PUSH消息由指定的应用客户端处理。

消息发送系统41不局限于上述结构，也可以是对现有消息发送系统(设备)的能力扩展，只要在现有消息发送系统的基础上增加如下功能即可：消息发送系统(设备)具有向消息安全管理系统申请系统(设备)的证书及对应的密钥，并支持相关证书及密钥算法的功能；具有协同注册应用客户端及应用客户端的PUSH响应能力文件，并记录应用客户端的信息的功能；具有在生成PUSH消息时，在PUSH消息中附带应用客户端标识；具有生成PUSH消息时，在PUSH消息中附带PUSH消息摘要，该消息摘要使用消息发送系统(设备)的证书及对应的私钥签名的功能。

消息递送系统42用于接收消息发送系统41发送的PUSH消息，并按发送要求，把该PUSH消息推送给消息接收设备44。如图6所示，消息递送系统42的主要功能包括：业务管理、消息处理、消息接收、消息递送。

消息递送系统42可以是对现有PUSH消息处理体系中的消息递送系统的改进。如消息递送系统42在现有PUSH消息递送系统的递送PUSH消息之前，向消息安全管理系统43请求对该PUSH消息及发送者做审核，通过审核的PUSH消息才可以被推送给消息接收设备44。

消息递送系统42还可以存储递送的PUSH消息。在所述PUSH消息中，包含消息发送者(消息发送系统)对PUSH消息的摘要签名，当消息安全管理系统43作为消息递送系统42的一部分设置在消息递送系统42中时，消息递送系统42本身可通过该摘要签名确认消息的发送者，以增强消息递送系统对PUSH消息的跟踪和监控能力。

消息递送系统42可以是对现有消息递送系统的能力扩展，即在现有消息递送系统的基础上增加了如下功能：可以向消息安全管理系统43申请系统的证书及对应的密钥，并支持相关证书及密钥算法的功能；在递送PUSH消息时，先通过消息安全管理系统43审核，并根据后者的审核结果确定是否进一步递送PUSH消息的功能；记录递送的PUSH消息，并能根据PUSH消息的摘要签名，查找和验证PUSH消息的实际发送实体的功能。

消息递送系统42还可以在现有消息递送系统的基础上增加身份申请模块61，用于向所述消息安全管理系统43发送申请信息，并用于从所述消息安全管理系统43获取身份证书及对应的密钥，以保证消息递送系统的可靠性，提高推消息在递送环节的安全性。所述申请信息至少包括：用户名、用户密码、用户描述及服务类型，所述身份证书至少包括：证书格式与版本、证书编码方法、签名算法、摘要算法、证书序列号、证书主题、证书的签名机构标识及证书摘要。

消息递送系统42在递送PUSH消息之前，向消息安全管理系统43请求对该PUSH消息及发送者做审核，通过消息安全管理系统43审核的PUSH消息才可以被推送给消息接收设备44，保证了消息来源的可靠性，增强了消息安全管理系统43对PUSH消息的跟踪和监控能力。

消息接收设备44也称为用户终端，用于接收和处理PUSH消息。消息接收设备44中的消息接收客户端接收消息，然后通知消息安全管理客户端，由消息安全管理客户端调用约定的应用客户端处理PUSH消息，即根据推消息中的应用客户端标识调用相应的应用客户端处理该推消息。消息接收设备44可为上述图3所示实施例提供的任一种消息接收设备。

上述实施例提供的推消息处理系统可通过消息发送系统生成PUSH消息，把PUSH消息推送给消息递送系统，通过消息安全管理系统或消息递送系统审核收到的PUSH消息，然后把通过审核的PUSH消息推送给消息接收设备；消息接收设备接收到PUSH消息后，查找和启动PUSH消息中约定的应用客户端，然后把PUSH消息内容推送给被启动的应用客户端。启动的应用客户端根据PUSH消息内容，访问约定的应用服务系统。

图7为本发明实施例提供的推消息处理系统中申请身份证书的方法实施例的流程图。如图7所示，消息发送系统41、消息递送系统42或消息接收设备44向消息安全管理系统43申请身份证书的方法包括：

步骤71、消息发送系统41、消息递送系统42或消息接收设备44向消息安全管理系统43发送申请信息，申请身份证书。所述申请信息详见上述实施例的说明，至少包括：用户名、用户密码、用户描述及服务类型；

步骤72、所述消息安全管理系统43根据所述申请信息生成身份证书及对应的密钥，反馈给消息发送系统41、消息递送系统42或消息接收设备44。身份证书详见上述实施例的说明，至少包括：证书格式与版本、证书编码方法、签名算法、摘要算法、证书序列号、证书主题、证书的签名机构标识及证书摘要。

所述消息安全管理系统43根据所述申请信息生成身份证书及对应的密钥之前还包括：

所述消息安全管理系统43根据所述申请信息验证所述消息发送系统41、消息递送系统42或消息接收设备44的身份，若验证未通过，则拒绝所述消息发送系统41、消息递送系统42或消息接收设备44的申请；若验证通过，则判断所述消息发送系统41、消息递送系统42或消息接收设备44是否已注册，因为请求方可能已申请过多次，若所述消息发送系统41、消息递送系统42或消息接收设备44已注册，即如果请求方已成功申请过(即成功注册过)，说明请求方的身份证书及对应的密钥之前已生成过，则消息安全管理系统43直接反馈已生成的身份证书及对应的密钥；若所述消息发送系统41、消息递送系统42或消息接收设备44未注册，则注册消息发送系统41、消息递送系统42或消息接收设备44，生成并存储相应的身份证书及对应的密钥。

以消息发送系统41向消息安全管理系统43申请身份证书及对应的密钥为例，具体步骤如图8所示包括：

步骤81、消息发送系统41向消息安全管理系统43发送申请信息，以申请身份证书及对应的密钥。

消息发送系统41向消息安全管理系统43发送的申请信息包括：消息发送系统的用户名、用户密码、用户描述、服务类型等信息。

步骤82、消息安全管理系统43检查，并生成身份证书及对应的密钥。

所述消息安全管理系统43根据所述申请信息验证所述消息发送系统41的身份，若验证未通过，则拒绝所述消息发送系统41的申请，转至步骤83反馈拒绝提供身份证书的申请结果及相关原因；若验证通过，则消息安全管理系统检查所述消息发送系统41是否存在有效注册，即检查该消息发送系统41是否已成功申请到身份证书及对应的密钥，如果存在有效注册，则消息安全管理系统43直接反馈已生成的所述消息发送系统41的身份证书以及对应的密钥，并执行步骤83，直接向所述消息发送系统41反馈生成的身份证书及对应的密钥。

如果所述消息发送系统41不存在有效注册，则注册消息发送系统41，生成并存储消息发送系统41的身份证书及对应的密钥，则转至步骤83反馈提供身份证书的申请结果。

步骤83、消息安全管理系统43向消息发送系统41反馈申请结果。若消息安全管理系统43为消息发送系统41提供身份证书及密钥，消息安全管理系统43向消息发送系统41反馈生成的身份证书及对应的密钥；若消息安全管理系统43确定不为消息发送系统41提供身份证书及密钥，则消息安全管理系统43向消息发送系统41反馈拒绝提供身份证书的申请结果及相关原因。

消息递送系统42申请身份证书及对应的密钥的步骤类似于上述步骤81～步骤83，申请主体改为消息递送系统即可。同样地，消息接收设备44申请身份证书及对应的密钥的步骤类似于上述步骤81～步骤83，申请主体改为消息接收设备即可。

图9为本发明实施例提供的推消息处理系统中应用客户端签名的方法实施例的流程图。如图9所示，应用客户端签名的方法包括：

步骤91、应用客户端生成至少包括推应用标识及应用客户端标识的推消息响应能力文件。推应用标识及应用客户端标识详见上述实施例中的说明。

步骤92、所述应用客户端发送所述推消息响应能力文件的签名请求。

应用客户端可直接向消息安全管理系统43发起签名请求，也可与消息发送系统41绑定，或者应用客户端与消息发送系统41是一个体系，则通过消息发送系统41发起签名请求，如图10所示，步骤101中所述应用客户端向消息发送系统41发送签名请求，步骤102中，消息发送系统41将签名请求转发给消息安全管理系统43。

除推消息响应能力文件外，应用客户端的签名请求还可以包括：版权、大小、应用描述等信息。

消息发送系统41利用获得的身份证书与消息安全管理系统43建立安全通信通道(例如，HTTPS)，在安全的环境下交互信息，把应用客户端的签名请求发送给消息安全管理系统43。

步骤93、消息安全管理系统43支持签名请求的情况下，计算所述推消息响应能力文件的文件摘要。

消息安全管理系统43审核消息发送系统41，以及应用客户端的签名请求，决定是否支持相关请求。如果消息安全管理系统43不支持相关请求，则反馈处理结果及拒绝原因。

如果消息安全管理系统43支持相关请求，则以所述推消息响应能力文件的内容为基础，采用约定的摘要算法(例如SHA-1)，计算所述推消息响应能力文件的文件摘要。

步骤94、消息安全管理系统43采用自身证书私钥加密所述文件摘要，即以自身证书对应的私钥加密所述能力文件摘要，生成新的能力文件摘要。

步骤95、消息安全管理系统43将加密的文件摘要加入所述推消息响应能力文件中，即把新生成的能力文件摘要加入到所述推消息响应能力文件中的约定位置，如加入到推消息响应能力文件的尾部等位置。

步骤96、消息安全管理系统43将签名结果及加入了加密的文件摘要的推消息响应能力文件反馈给所述应用客户端。

具体地，当应用客户端直接向消息安全管理系统43请求签名时，则消息安全管理系统43直接将签名结果及加入了加密的文件摘要的推消息响应能力文件发送给所述应用客户端；当应用客户端通过消息发送系统41请求签名时，消息安全管理系统43向消息发送系统41反馈所述能力文件的签名处理结果，再由消息发送系统41转发给应用客户端。此时，如果消息安全管理系统43返回签名后的推消息响应能力文件，则本发明实施例提供的应用客户端签名的方法还可进一步包括：

步骤97、所述消息发送系统41存储所述加入了加密的文件摘要的推消息响应能力文件，即存储签名后的推消息响应能力文件。这样，消息发送系统41在生成、发送推消息时，可以使用存储的能力文件信息，以选择处理推消息的应用客户端，保证推消息处理的安全性。

上述步骤97可在步骤96的执行过程中执行，也可在步骤96之后执行。

上述步骤96之后，还可进一步包括：

步骤98、所述应用客户端将加入了加密的文件摘要的推消息响应能力文件作为自身一部分，分发给消息接收设备44。

上述步骤97与步骤98无顺序要求，可同时执行，也可先执行步骤97后执行步骤98，或者先执行步骤98再执行步骤97。

若消息安全管理系统43拒绝签名，消息发送系统41向应用客户端反馈消息安全管理系统43的拒绝服务信息。

应用客户端被安装到消息接收设备44。应用客户端在安装时，需要向消息接收设备44的消息安全管理客户端注册自己的能力信息。应用客户端只有成功注册后，才可以被消息安全管理客户端调用，以处理PUSH消息。图11A为本发明实施例提供的推消息处理系统中应用客户端注册的方法实施例的流程图。图11B为与图11A相对应的信令流程图。如图11A、图11B所示，应用客户端注册的方法包括：

步骤111、应用客户端安装到消息接收设备44时，向消息安全管理客户端提交注册请求信息，所述注册请求信息中包含推消息响应能力文件。

提交的注册请求信息至少包括：所述签名后的推消息响应能力文件、应用客户端安装路径、应用客户端主程序的全路径(包括路径和主程序的全名)。还可以包括主程序启动的方法，例如，主程序执行时参数的写法等。

步骤112、消息安全管理客户端判断应用客户端是否已注册。

具体地，消息安全管理客户端检查该应用客户端是否已注册的依据可以是应用客户端主程序的全路径、以及签名后的能力文件是否已存在。如果已存在，并且与注册请求信息相同，则转到步骤116，直接向应用客户端反馈注册成功的信息，以避免应用客户端重复注册，且提高注册请求处理效率。对于应用客户端均未注册的情况，本步骤112可以省去。

步骤113、所述消息安全管理客户端审核所述注册请求信息中的推消息响应能力文件。

由于消息安全管理客户端有消息安全管理服务系统43的证书及公钥，消息安全管理客户端可以按消息安全管理服务系统43的摘要计算方法，以应用客户端提交的推消息响应能力文件为基础，生成能力文件的文件摘要A。

另外，消息安全管理客户端从应用客户端提交的推消息响应能力文件中，提取推消息响应能力文件的文件摘要B。

消息安全管理客户端使用消息安全管理系统43的公钥，解密文件摘要B，得到文件摘要C。

消息安全管理客户端比较文件摘要A与文件摘要C。如果两者相同，则认为应用客户端提交的能力文件是合法和有效的，审核通过；否则，认为是不合法的或者无效的，审核未通过，转向步骤116，向应用客户端反馈注册请求处理失败及原因，即，若审核未通过，则结束注册，反馈注册失败结果。

步骤114、若审核通过，则所述消息安全管理客户端查询和更新可信应用列表，所述可信应用列表详见上述实施例的说明，为通过消息安全管理系统注册和签名的应用客户端的信息列表。

所述可信应用列表是消息安全管理系统43中可信应用列表在消息接收设备44中的备份。所述可信应用列表由消息安全管理系统43生成与维护。在所述可信应用列表中，存储消息安全管理系统43信任的(即经消息安全管理系统43审核的)应用客户端信息，相关信息包括：应用客户端的推应用标识、应用客户端标识、签名后的能力文件，以及应用客户端的其它信息。

应用客户端在请求消息安全管理系统43签名推消息响应能力文件时，如果消息安全管理系统43接受应用客户端的请求，则会在自己的可信应用列表中添加所述应用客户端的信息。

消息安全管理客户端定期查看和下载消息安全管理系统43中的可信应用列表，维护消息接收设备44中的可信应用列表。消息安全管理客户端还可在需要时(例如，可信应用列表不存在，或者过期等情况下)，向消息安全管理系统43提交申请，下载最新的可信应用列表。消息安全管理客户端与消息安全管理系统43之间可以采用HTTPS等协议交互数据。

消息安全管理客户端查询本地已有的可信应用列表中是否包含有提交注册请求信息的应用客户端的信息，若不存在，则从消息安全管理系统下载最新的可信应用列表对本地进行更新，并在更新后的可信应用列表再次查询包含有提交注册请求信息的应用客户端的信息。

步骤115、若所述可信应用列表中包含有提交注册请求信息的应用客户端的信息，即请求注册的应用客户端可信，则所述消息安全管理客户端记录所述提交注册请求信息的应用客户端的注册信息，并继续执行步骤116，反馈注册成功结果；若所述可信应用列表未包含所述提交注册请求信息的应用客户端的信息，则转至步骤116，反馈注册失败结果。

步骤116、消息安全管理客户端向应用客户端反馈注册请求的处理结果。

如果消息安全管理客户端接受应用客户端的注册请求，则反馈注册成功结果的信息给应用客户端；否则，消息安全管理客户端反馈注册失败的信息。

本发明实施例提供的应用客户端注册的方法还可进一步包括：

步骤117、所述消息安全管理客户端记录安全管理的日志信息，并定期向所述消息安全管理系统43提交日志信息。

图12为本发明实施例提供的推消息处理系统递送推消息的流程图。如图12所示，消息发送系统41生成PUSH消息，递送给消息递送系统42，消息递送系统42通过消息安全管理系统43审核是否可以递送，如果可以，则消息递送系统42把消息推送给消息接收设备44。消息递送的主要步骤包括：

步骤121、消息发送系统41生成PUSH消息。

所述PUSH消息中，至少包含推应用标识。如果消息发送系统41希望指定处理所述PUSH消息的应用客户端，则可以在所述PUSH消息中加入应用客户端标识。

所述PUSH消息中，还包含根据PUSH消息内容生成的PUSH消息摘要。通过所述PUSH消息摘要，则可以认定所述PUSH消息是所述消息发送系统所生成。这是标识PUSH消息所属的重要方法。该PUSH消息摘要由消息发送系统41根据约定的摘要算法(例如，SHA-1)生成，然后使用消息发送系统41的私钥加密该PUSH消息摘要，并把加密后的摘要作为PUSH消息的组成部分。所述PUSH消息的格式，可以采用现有PUSH消息规范体系的约定。

步骤122、消息发送系统41将所述PUSH消息发送给消息递送系统42，请求其进一步发送。

消息发送系统41与消息递送系统42之间，可以采用HTTPS等协议交互数据。

由于PUSH消息与消息接收设备44的安全，以及业务运营系统的运营安全密切相关，因此，消息递送系统42在递送所述PUSH消息之前，可以请求消息安全管理系统43审核所述消息发送系统是否有能力发送所述PUSH消息。

步骤123、消息递送系统42向消息安全管理系统43请求检查和处理PUSH消息。如对PUSH消息的发送者进行身份验证。

步骤124、消息安全管理系统43检查和处理PUSH消息。

步骤125、消息安全管理系统43向消息递送系统42反馈PUSH消息的处理结果。

当消息安全管理系统43设置在消息递送系统42中，作为消息递送系统42的部分功能时，可省略步骤123至步骤125，由消息递送系统42检查和处理PUSH消息。

步骤126、在步骤125中反馈的处理结果为通过时，消息递送系统42把所述PUSH消息推送给消息接收设备44。

消息递送系统42可按现有PUSH消息推送的规范体系，把PUSH消息推送给消息接收设备44。步骤126是异步的。

步骤127、消息递送系统42向消息发送系统41反馈PUSH消息递送结果。

消息递送系统42可按现有PUSH消息推送的规范体系，向消息发送系统41反馈处理结果。步骤127是异步的。

图13为本发明实施例提供的推消息处理系统中消息接收设备处理推消息的流程图。如图13所示，消息接收设备44的消息接收客户端接收到PUSH消息后，把PUSH消息推送给消息安全管理客户端处理。消息安全管理客户端根据PUSH消息中的推应用标识和应用客户端标识，查找和启动目标应用客户端，通过目标应用客户端处理所述PUSH消息。消息接收设备处理PUSH消息的主要步骤包括：

步骤131、消息接收客户端接收PUSH消息。

消息接收客户端接收PUSH消息的方法，可按现有PUSH消息递送和接收技术处理。

步骤132、消息接收客户端把接收到的PUSH消息推送给消息安全管理客户端。

所述PUSH消息中，至少包含所述推应用标识，如果不包含，则转至步骤136，反馈无法处理所述PUSH消息。

步骤133、消息安全管理客户端从本地可信应用列表查找匹配的应用客户端。

当消息接收设备44中存储有已注册的应用客户端列表时，本步骤可省略，而直接执行下一步骤134。当消息接收设备44中没有该已注册的应用客户端列表，而是将已安装的应用客户端信息标识在本地可信应用列表中时，执行本步骤，首先判断目标应用客户端是否可靠。

消息安全管理客户端在本地可信应用列表中查找匹配所述推应用标识的应用客户端信息。通过相关查找，找到的应用客户端可能存在，也可能不存在，还可能同时存在多个。如果不存在，则转到步骤136，反馈无应用客户端可以操作所述PUSH消息。

如果所述PUSH消息中，还包含所述应用客户端标识，则消息安全管理客户端进一步匹配所述应用客户端标识。如果找到同时匹配所述推应用标识和所述应用客户端标识的应用客户端，则转至步骤134，如果未找到匹配所述应用客户端标识的应用客户端，则可以根据业务需要进一步处理，例如，终止调用，或者选择其一个调用等。

步骤134、消息安全管理客户端检查目标应用客户端的有效性。

具体地，消息安全管理客户端进一步检查目标应用客户端是否实际存在，即消息安全管理客户端通过已注册的应用客户端列表检查该目标应用客户端是否已安装在消息接收设备44。当消息接收设备中存储有已注册的应用客户端列表时，如果目标应用客户端已安装，则已注册的应用客户端列表中有目标应用客户端的信息，也即目标应用客户端实际存在。如果不存在，则转至步骤136，反馈无有效应用客户端处理所述PUSH消息。

当消息接收设备中安装的应用客户端信息标识在本地可信应用列表中时，执行上述步骤133时如果目标应用客户端的信息已保存在本地可信应用列表中，则进一步执行本步骤，判断本地可信应用列表中目标应用客户端信息中是否包含目标应用客户端已安装的标识，如果包含已安装标识，说明目标应用客户端实际存在；如果未包含已安装标识，说明目标应用客户端不存在，则转至步骤136，反馈无有效应用客户端处理所述PUSH消息。

步骤135、消息安全管理客户端按约定的规则启动目标应用客户端。

具体地，消息安全管理客户端按目标应用客户端注册时约定的方法启动目标应用客户端，并把所述PUSH消息发送给目标应用客户端处理。

步骤136、消息安全管理客户端向消息接收客户端反馈消息处理结果。

步骤137、消息安全管理客户端记录消息处理日志，并定期向消息安全管理系统43提交。步骤137是异步的，可选的。

本发明上述实施例不仅适用于移动网络，也适用于其它网络，例如，宽带固网、互联网等，在兼容现有PUSH消息处理技术的基础上，增强了推消息处理的安全性和开放性。

本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于一计算机可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述的存储介质包括：ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。