CN103490981A

CN103490981A - 一种跨移动应用的消息推送方法和装置

Info

Publication number: CN103490981A
Application number: CN201310409716.2A
Authority: CN
Inventors: 曹欢欢
Original assignee: Individual
Current assignee: Douyin Vision Co Ltd; Douyin Vision Beijing Co Ltd
Priority date: 2013-09-11
Filing date: 2013-09-11
Publication date: 2014-01-01
Anticipated expiration: 2033-09-11
Also published as: CN103490981B

Abstract

一种跨移动应用的消息推送方法和装置，用于用户在安装时关闭应用消息推送功能的状态下重要消息的推送，该方法包括S100：提供消息推送应用程序接口，需要向用户推送消息的移动应用A在其服务器端提供一个可供调用的消息推送应用程序接口；S200：获得移动应用A要推送的消息，移动应用B通过调用所述移动应用A的所述消息推送应用程序接口获得所述移动应用A要推送的消息；S300：显示消息，移动应用B将所述移动应用A要推送的消息显示给用户。本发明还提供了采用上述方法的跨移动应用的消息推送装置，包括消息推送模块、消息获取模块和消息显示模块。本发明在用户安装时选择不接受推送消息的情况下，能更灵活地促进用户打开应用。

Description

一种跨移动应用的消息推送方法和装置

技术领域

本发明涉及一种移动互联网的移动应用信息推送技术，特别是一种在用户关闭移动应用消息推送功能时仍可将重要消息推送至用户的跨移动应用的消息推送方法和装置。

背景技术

以往的移动应用消息推送方式主要是操作系统级别的。比如苹果的iOS系统和谷歌的Android系统都会提供应用程序的消息推送机制。该操作系统级别的消息推送机制一般要求移动应用在推送消息时调用操作系统开发商的API(Appiication Programming Interface，应用程序编程接口)，以便与操作系统开发商获取要推送的消息。而在移动设备的操作系统端，由于系统在网络状况良好的情况下系统会定期连接操作系统开发商的后台服务器，一旦后台服务器获得了移动应用要推送的消息，就可以立即传送到操作系统并显示给用户。苹果和谷歌的通知系统都是采用的类似原理。

为了增加用户活跃率，增加PV(page view)，进行消息推送移动应用的数量越来越多。用户往往反感这种消息推送而选择关闭某些移动应用的消息推送功能。一旦被关闭消息推送功能，即使某些应用有特别好的内容需要展示(比如视频、有趣的图片或超低折扣的商品等)，也永远无法通知用户了。这时，如果可以通过用户每天都会使用的热门应用(如微信、微博等)推送这些消息，这些应用就增加了留住用户的可能性。但现有技术中尚没有相应的技术方案可以实现跨移动应用的消息推送。

发明内容

本发明所要解决的技术问题是提供一种在用户关闭移动应用消息推送功能时仍可将重要消息推送至用户的跨移动应用的消息推送方法和装置。

为了实现上述目的，本发明提供了一种跨移动应用的消息推送方法，用于用户在安装时关闭应用消息推送功能的状态下重要消息的推送，其中，包括如下步骤：

S100：提供消息推送应用程序接口，需要向用户推送消息的移动应用A在其服务器端提供一个可供调用的消息推送应用程序接口；

S200：获得移动应用A要推送的消息，移动应用B通过调用所述移动应用A的所述消息推送应用程序接口获得所述移动应用A要推送的消息；

S300：显示消息，移动应用B将所述移动应用A要推送的消息显示给用户。

上述的跨移动应用的消息推送方法，其中，所述步骤S200包括：

S201：所述移动应用B检测用户设备上是否安装了所述移动应用A，若是，则执行步骤S202；若否，则执行步骤S204；

S202：所述移动应用B检测安装在该用户设备上的所述移动应用A是否被禁止推送消息，若是，则执行步骤S203；若否，则执行步骤S204；

S203：所述移动应用B调用所述移动应用A的所述消息推送应用程序接口，获取所述移动应用A要推送的消息，并执行步骤300；

S204：放弃对所述移动应用A的消息推送。

上述的跨移动应用的消息推送方法，其中，在所述步骤S203之后，还包括如下步骤：

S2031：移动应用B检测获取的所述移动应用A要推送的消息是否为空，若是，则执行步骤S204，若否，则执行步骤S203。

上述的跨移动应用的消息推送方法，其中，还包括：

步骤S400：移动应用B将所述移动应用A要推送的消息通过用户导引接口引导用户进入移动应用A的操作界面，若移动应用A没有运行，移动应用B能通过用户互动启动移动应用A。

上述的跨移动应用的消息推送方法，其中，移动应用B能同时显示多个需要向用户推送消息的移动应用委托的推送消息。

上述的跨移动应用的消息推送方法，其中，移动应用B能根据设定条件选择显示多个需要向用户推送消息的移动应用委托的推送消息的其中一部分。

上述的跨移动应用的消息推送方法，其中，移动应用B能根据设定条件对多个需要向用户推送消息的移动应用委托的推送消息进行排序后予以显示。

上述的跨移动应用的消息推送方法，其中，若移动应用A没有运行，移动应用B能通过用户互动启动移动应用A。

为了更好地实现上述目的，本发明还提供了一种跨移动应用的消息推送装置，用于用户在安装时关闭应用消息推送功能的状态下重要消息的推送，其中，包括：

消息推送模块：用于需要向用户推送消息的移动应用A在其服务器端提供一个可供调用的消息推送应用程序接口；

消息获取模块：用于获得移动应用A要推送的消息，移动应用B通过调用所述移动应用A的所述消息推送应用程序接口获得所述移动应用A要推送的消息；

消息显示模块，用于移动应用B将所述移动应用A要推送的消息显示给用户。

上述的跨移动应用的消息推送装置，其中，还包括：

用户导引模块，用于移动应用B引导用户进入移动应用A的操作界面，所述操作界面为所述移动应用A要推送的消息的操作界面，若移动应用A没有运行，移动应用B能通过用户互动启动移动应用A。

本发明的技术效果在于：

本发明在要推送消息的应用的后台提供一个获取推送消息的API，被委托推送消息的应用在被用户使用时调用检测用户是否安装了前者并在安装的前提下调用前者的API，展示要推送的消息，该消息可通过用户交互启动前者。和现有技术的通过操作系统推送消息方式相比，这种消息推送方式适用于用户在安装时选择不接受推送消息的情况，从而更灵活地促进用户打开应用，增加PV(page view)。

以下结合附图和具体实施例对本发明进行详细描述，但不作为对本发明的限定。

附图说明

图1为本发明跨移动应用的消息推送方法流程图；

图2为本发明第一实施例的消息推送流程图；

图3为本发明第一实施例的系统组件通信示意图；

图4为本发明第二实施例的消息推送流程图；

图5为本发明第三实施例的消息推送流程图；

图6为本发明第三实施例的系统组件通信示意图；

图7为本发明消息推送效果示意图；

图8为本发明一实施例的移动应用A服务器端提供推送消息获取接口流程图；

图9为本发明一实施例的移动应用B通过操作系统启动移动应用A流程图；

图10为步骤S201-S202的流程图；

图11为本发明跨移动应用的消息推送装置框图。

其中，附图标记

100 消息推送模块

200 消息获取模块

300 消息显示模块

101 用户设备

102 用户设备操作系统

103 移动应用A客户端

104 移动应用B客户端

105 移动应用A服务器端

106 移动应用B服务器端

1-10、S100-S400 步骤

具体实施方式

下面结合附图对本发明的结构原理和工作原理作具体的描述：

参见图1，图1为本发明跨移动应用的消息推送方法流程图。本发明的跨移动应用的消息推送方法，用于用户在安装时关闭应用消息推送功能的状态下重要消息的推送，包括如下步骤：

步骤S100：提供消息推送应用程序接口，需要向用户推送消息的移动应用A在其服务器端提供一个可供调用的消息推送应用程序接口；

此处的推送消息获取接口指一个能够通过调用传输推送消息的网络服务接口，调用逻辑遵循一般网络服务接口的规范。具体的接口调用流程参见图8，图8为本发明一实施例的移动应用A服务器端提供推送消息获取接口流程图。

其具体步骤如下：

步骤S1001：移动应用A服务器端105启动提供接口逻辑功能的网络服务：

步骤S1002：移动应用A服务器端105的网络服务器为实现接口功能的网络服务分配网络端口：

步骤S1003：外部网络程序(比如移动应用B的服务器端106)发送推送消息请求，包括授权码，用户设备ID等信息；

步骤S1004：该接口返回当前时刻需要推送的信息。

该接口的实现方法可以是一种RESTful1协议，也可以是一种RPC协议。采用RESTful协议实现时，移动应用A服务器端105只需运行提供接口逻辑功能的网络服务模块并为其分配网络端口，只要其它互联网上的应用程序经过授权后就可以向访问网站一样调用。而采用RPC协议实现时，其它程序要调用它必须安装一个相应的客户端。其中，RESTful：REST为REpresentational StateTransfer的缩写，RESTful泛指满足REST条件的网络服务协议，HTTP是一种最常见的RESTful协议，这类协议的特点是面向资源，具有状态无关性。RPC：Remote Procedure Call的缩写，另一种经典的网络服务协议，其特点是面向方法。

步骤S200：获得移动应用A要推送的消息，移动应用B通过调用所述移动应用A的所述消息推送应用程序接口获得所述移动应用A要推送的消息；

步骤S300：显示消息，移动应用B将所述移动应用A要推送的消息显示给用户。

参见图2，图2为本发明第一实施例的消息推送流程图。在本实施例中，所述步骤S200可具体包括：

步骤S201：所述移动应用B检测用户设备101上是否安装了所述移动应用A，若是，则执行步骤S202；若否，则执行步骤S204；

步骤S202：所述移动应用B检测安装在该用户设备101上的所述移动应用A是否被禁止推送消息，若是，则执行步骤S203；若否，则执行步骤S204；

步骤S203：所述移动应用B调用所述移动应用A的所述消息推送应用程序接口，获取所述移动应用A要推送的消息，并执行步骤300；

步骤S204：放弃对所述移动应用A的消息推送。

其中，在所述步骤S203之后，还可包括如下步骤：

在步骤S100之后，可以包括：

步骤S101：移动应用A授权移动应用B调用其消息获取接口。

其中，移动应用B被用户启动时检测移动应用A是否安装在用户设备101上并且被禁止推送消息，参见图10，图10为步骤S201-S202的流程图。具体可包括如下步骤：

S2010：移动应用B被用户启动；

S2011：移动应用B向其服务器端106获取移动应用A委托其推送消息的应用列表；

S2012：移动应用B向用户设备操作系统102请求设备安装应用列表：

S2013：通过比对两个列表，确定用户设备101是否安装了移动应用A。

现有技术中，某些移动操作系统(比如安卓系统)也提供了获取设备已安装应用列表的程序接口，一些被用户信赖的应用(比如微信)经过用户许可可以调用该接口，从而获得用户安装的应用列表。

参见图3，图3为本发明第一实施例的系统组件通信示意图。在该通信过程中，主要包括如下步骤：

步骤1：移动应用B客户端104向移动应用B服务器端106请求移动应用A委托进行消息推送的应用列表；

步骤2：移动应用B客户端104获得移动应用A委托进行消息推送的应用列表；

步骤3：移动应用B客户端104通过用户设备操作系统102检查用户设备101是否安装移动应用A；

步骤4：用户设备操作系统102检查到用户设备101安装了移动应用A后通知移动移动应用B；

步骤5：移动应用B向移动应用B服务器端106请求移动应用A的推送消息；

步骤6：移动应用B服务器端106向移动应用A服务器端105转发该请求；

步骤7：移动应用B服务器端106获取移动应用A的推送消息；

步骤8：移动应用B服务器端106将移动应用A的推送消息发送到移动应用B客户端104；

步骤9：用户点击该推送消息后移动应用B客户端104通知用户设备操作系统102启动移动应用A；

步骤10：用户设备操作系统102启动移动应用A并定位到移动应用A的指定界面。

假设移动应用A为需要提高用户活跃率而进行消息推送的一方，移动应用B为用户频繁访问的重度使用软件(如微信)，则具体推送过程如下：

1.需要向用户推送消息的移动应用A在其服务器端105提供一个可供调用的消息应用程序接口(API)；

2.如果移动应用A的提供方和移动应用B的提供方达成协议委托移动应用B向用户推送移动应用A的消息，那么当用户打开移动应用B时：

a.移动应用B检测用户设备101上是否安装了移动应用A；

b.如果用户安装了移动应用A，移动应用B通过调用移动应用A的消息API获得移动应用A要推送的消息并显示给用户；

c.某些推送的消息可以通过用户引导用户进入A的操作界面。

3.如果还有其它移动应用C，D等采取类似的方式委托B来推送消息，B可以同时显示多个消息，也可以根据条件(付费金额，随机选取)只显示一部分委托应用的推送信息，或者根据设定条件对所要显示的推送信息排序。

参见图4，图4为本发明第二实施例的消息推送流程图。在该实施例中，与第一实施例的区别主要在于，还包括：

参见图9，图9为本发明一实施例的移动应用B通过操作系统启动移动应用A流程图。具体可包括如下步骤：

步骤S401：用户点击移动应用A的推送消息；

步骤S402：移动应用B客户端104收到信号并获得委托推送该消息的应用ID；

步骤S403：移动应用B客户端104通过用户设备自带的操作系统(如安卓系统，iOS系统，其提供了所有移动应用运行所必须的运行环境，且该操作系统记录了所有安装在用户设备上的移动应用信息)获得运行在用户设备上的移动应用列表，检查移动应用A是否在运行，若是，则执行步骤S404，若否，则执行步骤S405；

步骤S404：移动应用B客户端104请求该用户设备自带的操作系统把移动应用A置于前台运行；

步骤S405：移动应用B客户端104请求该用户设备自带的操作系统启动移动应用A并置于前台运行。

许多移动操作系统(如安卓)提供应用程序接口(API)可以让一个应用程序启动其它未运行的应用程序，因其具体实现原理根据操作系统的不同而不同，均属于较成熟的现有技术，故在此不做赘述。

具体说，本实施例的具体过程可为：

S2001：移动应用B客户端104从移动应用A服务器端105获取需要推送消息的应用列表；

S201：移动应用B客户端104通过用户设备操作系统102查询应用A是否被安装，若是，则执行步骤S202，若否，则执行步骤S204；

S202：移动应用B客户端104判断移动应用A是否被禁用消息推送功能，若是，则执行步骤S203，若否，则执行步骤S204；其中，步骤S203具体包括：

S2030：移动应用B客户端104向其服务器端106发送请求获取移动应用A的推送消息；

S2032：移动应用B服务器端106转发该请求并获取移动应用A的推送消息：

S2033：移动应用B服务器端106将移动应用A的推送消息发送到移动应用B客户端104；

S300：移动应用B客户端104展示移动应用A的推送消息；

S400：用户点击该消息后移动应用B客户端104通过操作系统启动移动应用A。

参见图5，图5为本发明第三实施例的消息推送流程图。其中，第三实施例与第二实施例的主要区别在于，第三实施例中，可以在步骤S2030之后，直接执行步骤S2033，而无需经过步骤S2032，即可不通过移动应用B服务器端106转发该请求并获取移动应用A的推送消息，而是直接由移动应用B服务器端106将移动应用A的推送消息发送到移动应用B客户端104。即步骤S203具体包括步骤S2030和步骤S2033。

参见图6，图6为第三实施例的系统组件通信示意图。在该通信过程中，主要包括如下步骤：

步骤2：移动应用B客户端104获得移动应用A委托进行消息推送的该应用列表；

步骤4：用户设备操作系统102检查到用户设备101安装了移动应用A后通知移动移动应用B客户端104：

步骤5：移动应用B客户端104直接向移动应用A服务器端105请求移动应用A的推送消息；

步骤6：移动应用A服务器端105直接将移动应用A的推送消息发送到移动应用B客户端104；

步骤7：用户点击该消息后移动应用B客户端104通知用户设备操作系统102启动移动应用A；

步骤8：用户设备操作系统102启动移动应用A客户端103并定位到移动应用A客户端103的指定界面。

在该实施例中，移动应用A采取类似的流程通过移动应用B向用户推送消息。不同之处在于移动应用A的消息不经过移动应用B的服务器端直接发送到移动应用B的客户端。这种实现方式安全性更好，因为移动应用B的服务器端不能获取消息的内容，而且减少了移动应用B服务器端106的负载。其缺点在于移动应用B的服务器端106返回给其客户端104的委托方列表不仅包含委托方客户端ID还包括其服务器端调用地址，数据量较大，传输耗费更多的用户流量。如果用户设备101上没有安装任何委托方的应用，用户流量被浪费的更多。其具体推送过程参见图5。

在第一实施例中，移动应用B服务器端106返回的委托方列表只包含委托方应用ID，而第二或第三实施例中至少还包括委托方的推送消息调用接口地址和授权码，保守估计数据量至少大了两倍。如果委托方较少，这一问题尚不严重。但是随着这项技术的普及，高使用率的应用可能会受到成百上千其它应用的委托，这时传输数据量就成为需要考虑的问题。假设每个字段(应用ID，授权码，接口地址)平均需要20个字节(160B)的数据传输，关于委托应用数和传输数据量的关系可以参加下表：

授权应用数	实施例一	实施例三
			100	16KB	>48KB
500	80KB	>240KB
			1000	160KB	>480KB
2000	320KB	>960KB

假设每天调用一次，在受到1000个应用委托的情况下，一个月内实施例三至少比实施例一多耗费7.2M的用户流量。调用越频繁，多耗费的用户流量越多。

假设某新闻类移动应用A近期用户活跃度下降，其运营方需要提高用户活跃度来提高广告点击，提振营收。经过策划，运营方准备了一个大型的老用户抽奖活动。但是很多用户在安装移动应用A的客户端时选择了关闭消息推送功能，这就使得移动应用A无法利用操作系统的通知中心把这条消息推送给用户。移动应用B是某互联网巨头开发的活跃用户过亿的社交应用，其用户不但活跃率高，而且基本上涵盖了大部分主流移动应用的用户，其中也包括移动应用A的用户。移动应用B出于创收的目的，为一些活跃率低的移动应用有偿的提供间接消息推送服务。移动应用A在这种情况下通过注册收费委托移动应用B为其推送消息。其具体推送过程可参见图4。其中，移动应用A授权移动应用B调用其消息获取接口，为两家应用之间的一项协议流程。因为移动应用A需要移动应用B调用其推送消息获取接口以完成消息的推送，但是又需要避免此接口暴露后第三方程序的恶意调用，因此提供给移动应用B一个授权码，只有包含此授权码的请求才被接口处理并返回结果。移动应用A可通过注册收费委托移动应用B为其推送消息，移动应用A在移动应用B提供的消息推送服务网站上注册信息，提供授权码并按照服务网站上的账户信息付款。

参见图7，图7为本发明消息推送效果示意图。当然，根据本发明的原理，移动应用B也可同时显示多个需要向用户推送消息的移动应用C、D、E等委托的推送消息。在该显示过程中，移动应用B能根据设定条件选择显示多个需要向用户推送消息的移动应用委托的推送消息的其中一部分，或者，移动应用B能根据设定条件对多个需要向用户推送消息的移动应用委托的推送消息进行排序后予以显示。

参见图11，图11为本发明跨移动应用的消息推送装置框图。本发明的跨移动应用的消息推送装置应用上述的方法进行用户在安装时关闭应用消息推送功能的状态下重要消息的推送，包括：

消息推送模块100：用于需要向用户推送消息的移动应用A在其服务器端提供一个可供调用的消息推送应用程序接口；消息获取模块200：用于获得移动应用A要推送的消息，移动应用B通过调用所述移动应用A的所述消息推送应用程序接口获得所述移动应用A要推送的消息；消息显示模块300，用于移动应用B将所述移动应用A要推送的消息显示给用户。还可包括：用户导引模块，用于移动应用B引导用户进入移动应用A的操作界面，所述操作界面为所述移动应用A要推送的消息的操作界面，若移动应用A没有运行，移动应用B能通过用户互动启动移动应用A。

当然，本发明还可有其它多种实施例，在不背离本发明精神及其实质的情况下，熟悉本领域的技术人员当可根据本发明作出各种相应的改变和变形，但这些相应的改变和变形都应属于本发明所附的权利要求的保护范围。

Claims

1.一种跨移动应用的消息推送方法，用于用户在安装时关闭应用消息推送功能的状态下重要消息的推送，其特征在于，包括如下步骤：

2.如权利要求1所述的跨移动应用的消息推送方法，其特征在于，所述步骤S200包括：

S204：放弃对所述移动应用A的消息推送。

3.如权利要求2所述的跨移动应用的消息推送方法，其特征在于，在所述步骤S203之后，还包括如下步骤：

S2031：移动应用B检测获取的所述移动应用A要推送的消息是否为空，若是，则执行步骤S204，若否，则执行步骤S300。

4.如权利要求1、2或3所述的跨移动应用的消息推送方法，其特征在于，还包括：

5.如权利要求1、2或3所述的跨移动应用的消息推送方法，其特征在于，移动应用B能同时显示多个需要向用户推送消息的移动应用委托的推送消息。

6.如权利要求1、2或3所述的跨移动应用的消息推送方法，其特征在于，移动应用B能根据设定条件选择显示多个需要向用户推送消息的移动应用委托的推送消息的其中一部分。

7.如权利要求1、2或3所述的跨移动应用的消息推送方法，其特征在于，移动应用B能根据设定条件对多个需要向用户推送消息的移动应用委托的推送消息进行排序后予以显示。

8.如权利要求1、2或3所述的跨移动应用的消息推送方法，其特征在于，若移动应用A没有运行，移动应用B能通过用户互动启动移动应用A。

9.一种跨移动应用的消息推送装置，用于用户在安装时关闭应用消息推送功能的状态下重要消息的推送，其特征在于，包括：

10.如权利要求9所述的跨移动应用的消息推送装置，其特征在于，还包括：