基于应用的消息免打扰方法、系统和应用后台系统与流程

本发明涉及消息推送领域，尤其涉及一种基于应用的消息免打扰方法、系统和应用后台系统。

背景技术：

目前很多的手机APP(应用)产品都支持以公众号的形式接入第三方业务系统。同时允许用户通过操作手机APP的消息免打扰功能来自行决定是否接收公众号推送的消息。其中，现有的消息免打扰功能主要通过两种方式实现，一种是用户设置消息免打扰功能后，手机端拒收服务器推送的消息，另一种是手机端接收到服务器推送的消息，但不向用户显示该消息。

现有消息免打扰规则固定，只允许用户选择开启或关闭接收消息按钮。以某即时通讯工具为例，只能设置是否接收公众号推送的消息，而不支持用户根据业务场景变化而选择是否接收业务系统推送的信息。

技术实现要素：

本发明要解决的一个技术问题是提供一种基于应用的消息免打扰方案能够实现基于业务需要灵活的向用户推送消息。

根据本发明一方面，提出基于应用的消息免打扰方法，包括：应用后台系统接收业务系统发送的消息，其中消息中包含消息类别标识；如果应用后台系统确定消息的类别属于屏蔽消息类别，则不向应用客户端推送消息。

进一步地，该方法还包括：应用后台系统将业务系统的消息类别信息发送至应用客户端，以便用户根据自身需求在应用客户端选择屏蔽消息类别；应用后台系统接收应用客户端返回的用户针对业务系统选择的屏蔽消息类别。

进一步地，该方法还包括：应用后台系统与业务系统交互，获得业务系统的消息类别信息；其中业务系统根据自身业务特性对需发送的消息进行分类。

进一步地，该方法还包括：应用后台系统将屏蔽消息类别与已保存的业务系统的消息类别信息进行比对，确定推送给用户的消息的推送消息类别。

进一步地，该方法还包括：如果应用后台系统确定消息的类别属于推送消息类别，则向应用客户端推送消息。

根据本发明的另一方面，还提出一种应用后台系统，包括：消息接收单元，用于接收业务系统发送的消息，其中消息中包含消息类别标识；消息推送单元，用于如果确定消息的类别属于屏蔽消息类别，则不向应用客户端推送消息。

进一步地，该应用后台系统还包括：消息类别发送单元，用于将业务系统的消息类别信息发送至应用客户端，以便用户根据自身需求在应用客户端选择屏蔽消息类别；屏蔽消息类别获取单元，用于接收应用客户端返回的用户针对业务系统选择的屏蔽消息类别。

进一步地，该应用后台系统还包括：消息类别获取单元，用于与业务系统交互，获得业务系统的消息类别信息；其中业务系统根据自身业务特性对需发送的消息进行分类。

进一步地，该应用后台系统还包括：推送消息类别确定单元，用于将屏蔽消息类别与已保存的业务系统的消息类别信息进行比对，确定推送给用户的消息的推送消息类别。

进一步地，消息推送单元还用于如果确定消息的类别属于推送消息类别，则向应用客户端推送消息。

根据本发明的另一方面，还提出一种基于应用的消息免打扰系统，包括业务系统、应用客户端和上述的应用后台系统；其中，业务系统用于根据自身业务特性对需发送的消息进行分类；应用客户端用于接收应用后台系统发送的业务系统的消息类别信息，以便用户根据自身需求选择屏蔽消息类别，并向应用后台系统返回屏蔽消息类别，以便应用后台系统根据屏蔽消息类别向应用客户端推送消息。

根据本发明的另一方面，还提出一种应用后台系统，包括：存储器；以及耦接至存储器的处理器，处理器被配置为基于存储在存储器的指令执行如上述的方法。

与现有技术相比，本发明应用后台系统接收业务系统发送的消息后，判断该消息的类型是否属于屏蔽消息类别，若属于，则不向应用客户端推送该消息。即根据业务系统的消息类别，灵活的向用户推送消息。

通过以下参照附图对本发明的示例性实施例的详细描述，本发明的其它特征及其优点将会变得清楚。

附图说明

构成说明书的一部分的附图描述了本发明的实施例，并且连同说明书一起用于解释本发明的原理。

参照附图，根据下面的详细描述，可以更加清楚地理解本发明，其中：

图1为本发明基于应用的消息免打扰方法的一个实施例的流程示意图。

图2为本发明基于应用的消息免打扰功能设置的一个实施例的流程示意图。

图3A为服务号配置页。

图3B为服务号按消息分类免打扰设置页。

图4为本发明基于应用的消息免打扰方法的另一个实施例的流程示意图。

图5为本发明应用后台系统的一个实施例的结构示意图。

图6为本发明应用后台系统的另一个实施例的结构示意图。

图7为本发明基于应用的消息免打扰系统的一个实施例的结构示意图。

图8为本发明应用后台系统的再一个实施例的结构示意图。

图9为本发明应用后台系统的又一个实施例的结构示意图。

具体实施方式

现在将参照附图来详细描述本发明的各种示例性实施例。应注意到：除非另外具体说明，否则在这些实施例中阐述的部件和步骤的相对布置、数字表达式和数值不限制本发明的范围。

同时，应当明白，为了便于描述，附图中所示出的各个部分的尺寸并不是按照实际的比例关系绘制的。

以下对至少一个示例性实施例的描述实际上仅仅是说明性的，决不作为对本发明及其应用或使用的任何限制。

对于相关领域普通技术人员已知的技术、方法和设备可能不作详细讨论，但在适当情况下，所述技术、方法和设备应当被视为授权说明书的一部分。

在这里示出和讨论的所有示例中，任何具体值应被解释为仅仅是示例性的，而不是作为限制。因此，示例性实施例的其它示例可以具有不同的值。

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步讨论。

为使本发明的目的、技术方案和优点更加清楚明白，以下结合具体实施例，并参照附图，对本发明进一步详细说明。

图1为本发明基于应用的消息免打扰方法的一个实施例的流程示意图。该方法包括以下步骤：

在步骤110，APP(Application，应用)后台系统接收业务系统发送的消息。其中，消息报文中包含消息类别参数，即消息类别的唯一标识。以监控中心调度任务消息为例，业务方发送的消息如下：

在步骤120，APP后台系统判断消息的类别是否属于屏蔽消息类别，若属于则执行步骤130，否则，执行步骤140。

其中，APP后台系统可以预先将业务系统的消息类别信息发送至APP客户端，由用户根据自身需求在APP客户端选择需要屏蔽的消息类别，APP客户端将屏蔽消息类别返回至APP后台系统。

在步骤130，APP后台系统不向APP客户端推送业务系统发送的消息。

在步骤140，APP后台系统将业务系统发送的消息推送到APP客户端。

在该实施例中，APP后台系统接收业务系统发送的消息后，判断该消息的类型是否属于屏蔽消息类别，若属于，则不向APP客户端推送该消息。因此，本发明能够基于业务需要动态、灵活、可配置的向用户推送消息，而不是将业务系统发送的消息全部屏蔽或全部推送给用户。

在实现上述基于APP的消息免打扰方法前，还需要进行免打扰设置，其具体实现过程如图2所示。

在步骤210，业务系统对消息进行分类。其中，业务系统可以根据自身业务特性对需要发送的消息进行分类。例如，当业务系统为流程系统时，可以分为：申请、审批、待办等；当业务系统为任务系统时，可以分为：我的负责、我关注的、进行中、已完成、已归档、今日任务、本周任务等；还可以根据消息来源进行分类。本领域的技术人员应当理解，业务系统对消息进行分类的规则仅是举例，具体分类方式与业务系统自身相关，有多少业务系统就可能存在多少分类，所有分类的集合形成字典。

以某平台的监控中心为例，监控中心生产的告警消息可以按消息来源进行分类。如表1所示：

表1

其中，公众号为监控中心，即APP产品以公众号的形式接入的第三方业务系统为监控中心。一级菜单包括调度任务监控、服务器监控两大消息类型，二级菜单包括消息大类下的若干消息小类。消息参数为消息类型的唯一标识，是否可用用于允许用户选择是否屏蔽该消息类型。当然也可以根据具体情况对消息进行更细粒度的分类设置。

在步骤220，APP后台系统与业务系统交互，获得业务系统的消息类别信息。即业务方发送消息时，在消息报文中添加消息类别参数，APP后台系统根据该消息报文就可获知该消息的类别。

在步骤230，APP后台系统将业务系统的消息类别信息发送至APP客户端。例如，APP后台系统将消息类别表格发送至手机APP客户端上，并在APP-公众号的设置页中，提供消息免打扰功能。

在步骤240，用户在APP客户端根据自身需求设置需要屏蔽的消息类别。如图3A所示，用户可以打开服务号的配置页设置消息免打扰功能。当用户点击消息免打扰功能后，进入图3B所示的按消息类别免打扰功能，用户根据自身工作需要，选择需要屏蔽的消息类别。

在步骤250，APP客户端将用户针对业务系统选择的屏蔽消息类别返回至APP后台系统。用户开启公众号-消息免打扰功能后，手机App客户端获取用户的屏蔽列表。以某平台-监控中心为例，获取的屏蔽消息类别列表如表2所示，此用户屏蔽了调度任务监控下的所有消息类别，而保留了服务器监控消息。证明此用户是工作与服务器相关，而与调度任务无关。手机App将此结果返回后台系统。通过上述设置，APP后台系统就可以根据屏蔽消息类别向用户推送消息。

表2

在该实施例中，还可以包括步骤260，APP后台系统将屏蔽消息类别与已保存的业务系统的消息类别信息进行比对，获得推送给用户的消息的推送消息类别。如表3所示，APP后台系统确定推送消息类别列表包括服务器监控的所有消息。

表3

通过上述设置，APP后台系统就可以根据推送消息类别向用户推送消息。

在该实施例中，允许用户根据自身工作需求定制接收消息的类别，突破了传统公众号消息免打扰的单一功能。经由业务系统、APP后台系统、App客户端等三方系统共同协作，本发明实现了基于业务需要动态、灵活、可配置的消息免打扰功能，弥补了传统方案的缺点。

在一个实施例中，APP后台系统还可以根据用户经常屏蔽的一些消息类别，当接入新的第三方业务系统时，自动向APP客户端推送是否需要屏蔽该第三方业务系统的某些消息类别，不需要用户进入公众号设置页面进行设置，方便了用户操作。

图4为本发明基于应用的消息免打扰方法的另一个实施例的流程示意图。该方法包括以下步骤：

在步骤410，第三方业务系统根据自身业务特性对消息进行分类。

在步骤420，第三方业务系统将消息类别信息发送至APP后台系统。

在步骤430，APP后台系统将消息类别信息转发至APP客户端。

在步骤440，用户根据自身需求在APP客户端设置屏蔽消息类别。

在步骤450，APP客户端向APP后台系统返回屏蔽消息类别。

在步骤460，APP后台系统比较屏蔽消息类别与已保存的消息类别，确定推送消息类别。

在步骤470，第三方业务系统向APP后台系统发送具有消息类别标识的消息。

在步骤480，APP后台系统判断该消息的类别与推送消息类别是否相匹配。

在步骤490，若该消息的类别与推送消息类别相匹配，APP后台系统则将该消息推送至APP客户端。

在该实施例中，APP后台系统接收业务系统发送的消息后，判断该消息的类型是否属于推送消息类别，若属于，则向APP客户端推送该消息。因此，本发明由第三方业务系统、APP后台系统、App客户端等三方系统共同协作，能够基于业务需要动态、灵活、可配置的向用户推送消息，弥补了传统方案的缺陷。

该方法可以应用于购物平台等大数据企业的监控、运维、办公等工作中。可以使不同分工的人员，获取自身工作相关的消息，避免了被海量的推送消息淹没，能够取得非常好的效果。

图5为本发明应用后台系统的一个实施例的结构示意图。该APP后台系统包括消息接收单元510和消息推送单元520，其中：

消息接收单元510用于接收业务系统发送的消息。其中，消息报文中包含消息类别参数，即消息类别的唯一标识。

消息推送单元520用于如果确定消息的类别属于屏蔽消息类别，则不向APP客户端推送该消息。其中，APP后台系统可以预先将业务系统的消息类别信息发送至APP客户端，由用户根据自身需求在APP客户端选择需要屏蔽的消息类别，APP客户端将屏蔽消息类别返回至APP后台系统，消息推送单元520根据屏蔽消息类别向APP客户端推送消息。

在该实施例中，APP后台系统接收业务系统发送的消息后，判断该消息的类型是否属于屏蔽消息类别，若属于，则不向APP客户端推送该消息。因此，本发明能够基于业务需要动态、灵活、可配置的向用户推送消息，而不是将业务系统发送的消息全部屏蔽或全部推送给用户。

图6为本发明应用后台系统的另一个实施例的结构示意图。该APP后台系统包括消息类别获取单元610、消息类别发送单元620、屏蔽消息类别获取单元630、消息接收单元640、消息推送单元650，其中：

消息类别获取单元610用于获取业务系统的消息类别信息。消息类别发送单元620用于将消息类别信息转发至APP客户端。当用户在APP客户端根据自身需求设置需要屏蔽消息类别后，屏蔽消息类别获取单元630用于获取APP客户端返回的用户针对业务系统选择的屏蔽消息类别。消息接收单元640用于接收业务系统发送的具有消息类别标识的消息。消息推送单元650用于如果确定消息的类别不属于屏蔽消息类别，则向APP客户端推送该消息。

APP后台系统还可以包括推送消息类别确定单元660，消息类别确定单元660用于将屏蔽消息类别与已保存的业务系统的消息类别信息进行比对，确定推送给用户的消息的推送消息类别。消息推送单元650用于如果确定消息的类别属于推送消息类别，则向APP客户端推送该消息。

在该实施例中，允许用户根据自身工作需求定制接收消息的类别，APP后台系统接收业务系统发送的消息后，判断该消息的类型是否属于屏蔽消息类别，若不属于则向APP客户端推送该消息，或者判断该消息的类型是否属于推送消息类别，若属于则向APP客户端推送该消息。因此，本发明由业务系统、APP后台系统、App客户端等三方系统共同协作，能够基于业务需要动态、灵活、可配置的向用户推送消息，弥补了传统方案的缺陷。

图7为本发明基于应用的消息免打扰系统的一个实施例的结构示意图。该免打扰系统包括业务系统710、APP后台系统720和APP客户端730，其中，APP后台系统720已在上述实施例中进行了详细介绍，此处不再进一步阐述。业务系统710用于根据自身业务特性对需发送的消息进行分类，例如，当业务系统为流程系统时，可以分为：申请、审批、待办等；当业务系统为任务系统时，可以分为：我的负责、我关注的、进行中、已完成、已归档、今日任务、本周任务等；还可以根据消息来源进行分类。本领域的技术人员应当理解，业务系统对消息进行分类的规则仅是举例，具体分类方式与业务系统自身相关，有多少业务系统就可能存在多少分类，所有分类的集合形成字典。

APP客户端730用于接收APP后台系统720发送的业务系统710的消息类别信息，以便用户根据自身需求选择屏蔽消息类别，并向APP后台系统720返回屏蔽消息类别，以便APP后台系统720根据屏蔽消息类别向APP客户端730推送消息。

在该实施例中，由业务系统、APP后台系统、App客户端等三方系统共同协作，能够实现基于业务需要动态、灵活、可配置的向用户推送消息，弥补了传统方案的缺陷。

下面以一个具体实施例介绍本发明方案在生活中的应用。例如，在某即时通讯APP中接入某一第三方业务系统，例如，以公众号的形式接入某购物平台，购物平台可能会推送订单物流消息、关注商铺每日更新消息、淘金币领取消息等等。其中，购物平台在发送消息时，可以在消息报文中添加消息类别参数，例如，消息类别参数“001”为订单物流消息，消息类别参数“002”为关注商铺每日更新消息，消息类别参数“003”为淘金币领取消息。

即时通讯后台系统与购物平台进行信息交互，获取购物平台发送消息类别信息，并将消息类别信息发送至即时通讯客户端。其中，即时通讯后台系统根据消息类别参数就可以获知该消息是订单物流消息、关注商铺每日更新消息还是淘金币领取消息。

用户打开即时通讯客户端后，可以在公众号配置页设置消息免打扰功能选项，当用户点击消息免打扰功能选项后，可以选择需要屏蔽的消息类别。例如，用户不想再收到“关注商铺每日更新消息”，则可以将该项消息进行屏蔽设置。即时通讯客户端将该屏蔽消息类别返回至即时通讯后台系统。

当购物平台再次向即时通讯后台系统推送消息时，即时通讯后台系统根据消息报文中的消息类别参数判断接收的消息类别是否为“关注商铺每日更新消息”，若是，则不再向即时通讯客户端推送该消息。如果消息类别不是“关注商铺每日更新消息”，例如为“订单物流消息”，由于用户并没有设置需要屏蔽该类消息，则即时通讯后台系统继续向客户端推送该消息。

当然，购物平台在发送消息时，可以在消息报文中添加更细粒度的消息类别参数，例如，针对关注商铺每日更新消息，根据消息报文中的消息类别参数识别出该消息是A商铺每日更新消息、B商铺每日更新消息还是其他商铺每日更新消息。即时通讯后台系统将消息类别信息发送至即时通讯客户端后，用户还可以在即时通讯客户端设置屏蔽某一个或几个已关注商铺每日更新消息，而对其他商铺的每日更新消息不进行屏蔽，即实现对消息更细粒度的设置。

在该实施例中，由购物平台、即时通讯后台系统和即时通讯客户端共同协作，并且允许根据用户需求定制接收消息的类别，突破了传统公众号消息免打扰的单一功能，能够更加动态、灵活、可配置的实现消息免打扰功能。

图8为本发明应用后台系统的再一个实施例的结构示意图。该免打扰装置包括存储器810和处理器820。其中：

存储器810可以是磁盘、闪存或其它任何非易失性存储介质。存储器用于存储图1-4所对应实施例中的指令。

处理器820耦接至存储器810，可以作为一个或多个集成电路来实施，例如微处理器或微控制器。该处理器820用于执行存储器中存储的指令，能够实现基于业务需要动态、灵活、可配置的向用户推送消息。

在一个实施例中，还可以如图9所示，APP后台系统900包括存储器910和处理器920。处理器920通过BUS总线930耦合至存储器910。该APP后台系统900还可以通过存储接口940连接至外部存储装置950以便调用外部数据，还可以通过网络接口960连接至网络或者另外一台计算机系统(未标出)。此处不再进行详细介绍。

在该实施例中，通过存储器存储数据指令，再通过处理器处理上述指令，能够实现基于业务需要动态、灵活、可配置的向用户推送消息。

至此，已经详细描述了本发明。为了避免遮蔽本发明的构思，没有描述本领域所公知的一些细节。本领域技术人员根据上面的描述，完全可以明白如何实施这里公开的技术方案。

可能以许多方式来实现本发明的方法以及装置。例如，可通过软件、硬件、固件或者软件、硬件、固件的任何组合来实现本发明的方法以及装置。用于所述方法的步骤的上述顺序仅是为了进行说明，本发明的方法的步骤不限于以上具体描述的顺序，除非以其它方式特别说明。此外，在一些实施例中，还可将本发明实施为记录在记录介质中的程序，这些程序包括用于实现根据本发明的方法的机器可读指令。因而，本发明还覆盖存储用于执行根据本发明的方法的程序的记录介质。

虽然已经通过示例对本发明的一些特定实施例进行了详细说明，但是本领域的技术人员应该理解，以上示例仅是为了进行说明，而不是为了限制本发明的范围。本领域的技术人员应该理解，可在不脱离本发明的范围和精神的情况下，对以上实施例进行修改。本发明的范围由所附权利要求来限定。