CN106375349A - 多系统通知消息处理方法及装置 - Google Patents

Abstract

本发明提供了一种多系统通知消息处理的方法及装置，应用于终端设备技术领域，包括：首先当后台运行的任一容器系统检测到自身容器系统的通知消息时，基于第一预定判断规则判断通知消息是否可转发，若判断结果为可转发通知消息，则后台运行的容器系统将通知消息转发至前台运行的容器系统，然后前台运行的容器系统基于第二预定判断规则判断接收到的通知消息是否可展现，若判断结果为可对通知消息进行展现，则依据预定转换规则，将通知消息转换为提醒消息，并显示提醒消息。本发明的技术方案解决了后台运行的容器系统中的敏感信息外泄以及通知消息有被其他用户偷窥风险，通知消息安全性较低的问题。

Description

多系统通知消息处理方法及装置

技术领域

本发明涉及终端设备技术领域，具体而言，本发明涉及一种多系统通知消息处理的方法及装置。

背景技术

随着信息技术的发展，移动终端在用户的日常生活中越来越重要，移动终端经常会接收到一些通知消息，在单系统的移动终端中，移动终端能够接收并显示该系统的通知消息，用户可以点击查看该通知消息。

随着多系统终端设备的兴起，前后台系统如何进行通知消息的提醒，成为一个重要问题。目前，现有的多系统通知消息处理的方法中，首先当后台运行的任一系统接收到该系统的通知消息后，将接收到的通知消息的全部内容直接转发至前台运行的系统中，然后，当前台运行的系统接收到后台运行的系统转发的通知消息之后，直接在移动终端显示界面上显示该通知消息中的全部内容。

然而，当后台运行的系统直接将通知消息转发至前台运行的系统，并直接显示该通知消息时，由于后台运行的系统只要接收到通知消息，即转发至前台运行的容器系统，即后台运行的系统将接收到的全部通知信息转发至前台运行的系统中，但后台运行的系统接收到的某些通知消息可能涉及敏感信息，若发送至前台运行的系统，可能导致后台系统的敏感信息外泄。另外，在某些应用场景下，若前台运行的系统直接将接收到的通知消息，显示在移动终端的显示界面，将造成通知信息有被其他用户偷窥的风险，从而导致信息外泄，使得通知信息的安全性较低。

发明内容

为克服上述技术问题或者至少部分地解决上述技术问题，特提出以下技术方案：

本发明的一个实施例提出了一种多系统通知消息处理的方法，该方法包括：

当后台运行的任一容器系统检测到自身容器系统的通知消息时，基于第一预定判断规则判断通知消息是否可转发；

若判断结果为可转发通知消息，则后台运行的容器系统将通知消息转发至前台运行的容器系统；

前台运行的容器系统基于第二预定判断规则判断接收到的通知消息是否可展现；

若判断结果为可对通知消息进行展现，则依据预定转换规则，将通知消息转换为提醒消息，并显示提醒消息。

其中，预定转换规则包括以下至少一种：

将一条通知消息转换为一条提醒消息；

将所属同一个应用的多条通知消息转换为一条提醒消息。

具体地，基于第一预定判断规则判断通知消息是否可转发的步骤，包括：

确定通知消息的涉密级别；

根据通知消息的涉密级别与预设最低可转发涉密级别的大小关系，判断通知消息是否可转发。

可选地，后台运行的容器系统将通知消息转发至前台运行的容器系统的步骤之前，还包括：

后台运行的容器系统将通知消息进行打包处理，得到携带通知消息的数据包；

具体地，后台运行的容器系统将通知消息转发至前台运行的容器系统的步骤，包括：

后台运行的容器系统将携带通知消息的数据包，通过后台运行的容器系统中的JAVA本地接口JNI通道发送至主控系统；

主控系统将接收到的携带通知消息的数据包，通过前台运行的容器系统中的JNI通道，转发至前台运行的容器系统。

具体地，前台运行的容器系统基于第二预定判断规则判断接收到的通知消息是否可展现的步骤，包括：

前台运行的容器系统确定解析得到的通知消息所属的应用程序；

前台运行的容器系统判断通知消息是否属于预设应用程序；

前台运行的容器系统根据判断结果，确定通知消息是否可展现。

具体地，前台运行的容器系统基于第二预定判断规则判断接收到的通知消息是否可展现的步骤，包括：

前台运行的容器系统判断接收到的通知消息的内容是否包含预设关键词；

前台运行的容器系统根据判断结果确定通知消息是否可展现。

本发明的一个实施例提供一种多系统通知消息处理的装置，该装置包括：

第一判断模块，位于后台运行的任一容器系统中，用于当后台运行的任一容器系统检测到自身容器系统的通知消息时，基于第一预定判断规则判断通知消息是否可转发；

第一转发模块，位于后台运行的容器系统中，用于当判断结果为可转发通知消息时，将通知消息转发至前台运行的容器系统；

第二判断模块，位于前台运行的容器系统中，用于基于第二预定判断规则判断接收到的通知消息是否可展现；

第一转换模块，位于前台运行的容器系统中，用于当判断结果为可对通知消息进行展现时，依据预定转换规则，将通知消息转换为提醒消息；

其中，预定转换规则包括以下至少一种：

将一条通知消息转换为一条提醒消息；

将所属同一个应用的多条通知消息转换为一条提醒消息。

显示模块，位于前台运行的容器系统中，用于显示提醒消息。

具体地，第一判断模块，位于后台运行的容器系统中，具体用于确定通知消息的涉密级别；

第一判断模块，位于后台运行的容器系统中，具体还用于根据通知消息的涉密级别与预设最低可转发涉密级别的大小关系，判断通知消息是否可转发。

可选地，装置还包括：打包处理模块；

打包处理模块，位于后台运行的容器系统中，用于将通知消息进行打包处理，得到携带通知消息的数据包；

具体地，第一转发模块，位于后台运行的容器系统中，具体用于将携带通知消息的数据包，通过后台运行的容器系统中的JAVA本地接口JNI通道发送至主控系统；

装置还包括：第二转发模块；

第二转发模块，位于主控系统中，用于将接收到的携带通知消息的数据包，通过前台运行的容器系统中的JNI通道，转发至前台运行的容器系统。

具体地，第二判断模块，位于前台运行的容器系统中，具体用于确定解析得到的通知消息所属的应用程序；

第二判断模块，位于前台运行的容器系统中，具体还用于判断通知消息是否属于预设应用程序；

第二判断模块，位于前台运行的容器系统中，具体还用于根据判断结果，确定通知消息是否可展现。

具体地，第二判断模块，位于前台运行的容器系统中，具体用于判断接收到的通知消息的内容是否包含预设关键词；

第二判断模块，位于前台运行的容器系统中，具体还用于根据判断结果确定通知消息是否可展现。

本发明提供了一种多系统通知消息处理的方法及装置，与后台运行的系统直接将通知消息转发至前台运行的系统，并直接显示该通知消息相比，本发明通过后台运行的容器系统根据第一预定判断规则判断该通知消息是否可转发，并在可转发时转发给前台运行的容器系统，然后前台运行的容器系统根据第二预定判断规则，判断接收到的可转发的通知消息是否可展现，再根据转换规则，将通知消息转换成提醒消息，进行显示，即后台的通知消息，在发送至前台运行的容器系统之前，先通过第一预定规则过滤掉一部分通知消息，仅将可以转发至前台运行的容器系统的通知消息转发至前台运行的容器系统，前台运行的容器系统再经过第二预定规则进行第二次过滤，随后基于转换规则将两次过滤后的通知消息转换为提醒消息，并在前台运行的容器系统中显示，而不是后台运行的容器系统直接把通知消息发送至前台运行的容器系统，并直接显示，从而避免敏感信息外泄，进而可以提高通知消息的安全性。

本发明附加的方面和优点将在下面的描述中部分给出，这些将从下面的描述中变得明显，或通过本发明的实践了解到。

附图说明

本发明上述的和/或附加的方面和优点从下面结合附图对实施例的描述中将变得明显和容易理解，其中：

图1为多系统终端设备中各系统间的关系示意图；

图2为本发明实施例的多系统通知消息处理的流程示意图；

图3为本发明实施例的另一种多系统通知消息处理的流程示意图；

图4为本发明实施例的又一种多系统通知消息处理的流程示意图；

图5为本发明实施例的又一种多系统通知消息处理的流程示意图；

图6为本发明实施例的又一种多系统通知消息处理的流程示意图；

图7为本发明实施例的一种多系统通知消息处理的装置结构示意图；

图8为本发明实施例的另一种多系统通知消息处理的装置结构示意图。

具体实施方式

下面详细描述本发明的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，仅用于解释本发明，而不能解释为对本发明的限制。

本技术领域技术人员可以理解，除非特意声明，这里使用的单数形式“一”、“一个”、“所述”和“该”也可包括复数形式。应该进一步理解的是，本发明的说明书中使用的措辞“包括”是指存在所述特征、整数、步骤、操作、元件和/或组件，但是并不排除存在或添加一个或多个其他特征、整数、步骤、操作、元件、组件和/或它们的组。应该理解，当我们称元件被“连接”或“耦接”到另一元件时，它可以直接连接或耦接到其他元件，或者也可以存在中间元件。此外，这里使用的“连接”或“耦接”可以包括无线连接或无线耦接。这里使用的措辞“和/或”包括一个或更多个相关联的列出项的全部或任一单元和全部组合。

本技术领域技术人员可以理解，除非另外定义，这里使用的所有术语(包括技术术语和科学术语)，具有与本发明所属领域中的普通技术人员的一般理解相同的意义。还应该理解的是，诸如通用字典中定义的那些术语，应该被理解为具有与现有技术的上下文中的意义一致的意义，并且除非像这里一样被特定定义，否则不会用理想化或过于正式的含义来解释。

本技术领域技术人员可以理解，这里所使用的“终端”、“终端设备”既包括无线信号接收器的设备，其仅具备无发射能力的无线信号接收器的设备，又包括接收和发射硬件的设备，其具有能够在双向通信链路上，进行双向通信的接收和发射硬件的设备。这种设备可以包括：蜂窝或其他通信设备，其具有单线路显示器或多线路显示器或没有多线路显示器的蜂窝或其他通信设备；PCS(Personal Communications Service，个人通信系统)，其可以组合语音、数据处理、传真和/或数据通信能力；PDA(Personal Digital Assistant，个人数字助理)，其可以包括射频接收器、寻呼机、互联网/内联网访问、网络浏览器、记事本、日历和/或GPS(Global Positioning System，全球定位系统)接收器；常规膝上型和/或掌上型计算机或其他设备，其具有和/或包括射频接收器的常规膝上型和/或掌上型计算机或其他设备。这里所使用的“终端”、“终端设备”可以是便携式、可运输、安装在交通工具(航空、海运和/或陆地)中的，或者适合于和/或配置为在本地运行，和/或以分布形式，运行在地球和/或空间的任何其他位置运行。这里所使用的“终端”、“终端设备”还可以是通信终端、上网终端、音乐/视频播放终端，例如可以是PDA、MID(Mobile Internet Device，移动互联网设备)和/或具有音乐/视频播放功能的移动电话，也可以是智能电视、机顶盒等设备。

本发明实施例的终端设备的内部结构的框架示意图如图1所示，包括：主控系统和两个以上的容器系统。

其中，本发明实施例中的容器系统，可以是设置在以Linux container(容器)虚拟化技术创建的容器中的操作系统。操作系统可以为传统意义上的Linux操作系统或Unix操作系统，也可以是基于Linux操作系统衍生出来的Android系统、Ubuntu系统或FireFox系统等，还可以为以Windows平台为基础的windows系统等等。实际上，本发明中的容器系统不限于前述例举的操作系统，可以涵盖所有能够在容器中运行的操作系统。

优选地，主控系统可以是上述传统的操作系统，也可以是对传统的kernel进行改进和/或在kernel之外(例如框架层和应用层)增加功能模块之后，得到的操作系统。

主控系统主要用于对多个容器系统进行前后台管理，与各容器系统进行交互等。

优选地，主控系统可以通过预定义的通道与容器系统进行通信。同理，容器系统之间可以通过容器通道进行通信。其中，预定义的通道可以是socket(套接字)通道。

本发明实施例的一种多系统通知消息处理的方法，如图2所示，所述方法包括：

步骤201、当后台运行的任一容器系统检测到自身容器系统的通知消息时，基于第一预定判断规则判断通知消息是否可转发。

对于本发明实施例，第一预定判断规则用于判断后台运行的容器系统将要转发至前台运行的容器系统的通知消息中是否有存在敏感信息的通知消息，并禁止存在敏感信息的通知消息转发至前台运行的容器系统。

对于本发明实施例，由于后台运行的某个容器系统可能安全级别较高的系统，如用户用于工作的系统，即该系统的通知消息中可能存在一些敏感信息，不想让其他容器系统获得，因此，后台容器系统需要先通过第一预定判断规则，判断需要转发至前台运行的容器系统的通知消息中是否存在敏感信息。

步骤202、若判断结果为可转发通知消息，则后台运行的容器系统将通知消息转发至前台运行的容器系统。

对于本发明实施例，若后台运行的容器系统根据第一预设规则，判断该通知消息中不存在敏感信息，则后台运行的容器系统将该通知消息转发至前台运行的容器系统。在本发明实施例中，不可转发的通知消息可能为所属某些工作软件的应用或者为系统应用，又或者涉及某些关键词的通知消息，在本发明实施例中不做限定。

对于本发明实施例，若判断结果为不可转发通知消息，则后台运行的容器系统不再对该不可转发的通知消息进行处理，即不将该不可转发通知消息转发至前台运行的容器系统。

步骤203、前台运行的容器系统基于第二预定判断规则判断接收到的通知消息是否可展现。

对于本发明实施例，当前台运行的容器系统接收到后台运行的容器系统的通知消息之后，先根据第二预定判断规则，判断接收到的通知消息可否需要转换为提醒消息提醒给用户。其中，第二预定判断规则用于判断是否需要将接收到的通知消息提醒给用户。

对于本发明实施例，前台运行的容器系统可以根据第二预定判断规则判断接收到的通知消息中是否为无用的通知消息。

例如，该无用的通知消息可能为一些应用程序定制的无用消息或者为音乐播放通知等应用推送消息。

步骤204、若判断结果为可对通知消息进行展现，则前台运行的容器系统依据预定转换规则，将通知消息转换为提醒消息。

对于本发明实施例，前台运行的容器系统可以调用规则转换引擎，将通知消息，转换为提醒消息。其中，规则转换引擎中设置有以下预定转换规则。

其中，预定转换规则包括以下至少一种：

将一条通知消息转换为一条提醒消息；

将所属同一个应用的多条通知消息转换为一条提醒消息。

例如，前台运行的容器系统接收到后台运行的容器系统的发送的一条微信通知消息，则将该通知消息转换为“您收到了吗？一条来自微信的通知消息”；前台运行的容器系统接收到后台运行的容器系统发送的五条QQ通知消息，则将该五条通知消息转换为“您收到了吗？五条来自QQ的通知消息”。

对于本发明实施例，预定转换规则的具体形式可以为：

步骤205、前台运行的容器系统显示提醒消息。

对于本发明实施例，前台运行的容器系统直接显示转换后的提醒消息，而不直接显示后台发送的通知消息。即前台运行的容器系统直接显示“您收到了吗？一条来自微信的通知消息”，而不显示该微信消息的具体内容。

对于本发明实施例，后台运行的容器系统中包含通知服务子系统，并且通知服务子系统中包含通知拦截子系统以及通知处理子系统，其中，通知拦截子系统拦截该后台运行的容器系统的通知消息，并将拦截到的通知消息发送至通知处理子系统，通知处理子系统能够根据第一预定判断规则判断通知消息是否可转发，并将可转发的消息转发至前台运行的容器系统，前台运行的容器系统的通知处理子系统根据第二预定判断规则对通知消息进行过滤，并将过滤后的通知消息，按照转换规则，转换为提醒消息，并显示。

本发明实施例提供了一种多系统通知消息处理的方法，与后台运行的系统直接将通知消息转发至前台运行的系统，并直接显示该通知消息相比，本发明实施例通过后台运行的容器系统根据第一预定判断规则判断该通知消息是否可转发，并在可转发时转发给前台运行的容器系统，然后前台运行的容器系统根据第二预定判断规则，判断接收到的可转发的通知消息是否可展现，再根据转换规则，将通知消息转换成提醒消息，进行显示，即后台的通知消息，在发送至前台运行的容器系统之前，先通过第一预定规则过滤掉一部分通知消息，仅将可以转发至前台运行的容器系统的通知消息转发至前台运行的容器系统，前台运行的容器系统再经过第二预定规则进行第二次过滤，随后基于转换规则将两次过滤后的通知消息转换为提醒消息，并在前台运行的容器系统中显示，而不是后台运行的容器系统直接把通知消息发送至前台运行的容器系统，并直接显示，从而避免敏感信息外泄，进而可以提高通知消息的安全性。

本发明实施例的另一种可能的实现方式，在如图2所示的基础上，步骤201、当后台运行的任一容器系统检测到自身容器系统的通知消息时，基于第一预定判断规则判断通知消息是否可转发，包括如图3所示的步骤301-302，其中附图3所示的步骤303-306的操作与如图2所示的步骤202-205相同，在此不再赘述。

步骤301、当后台运行的任一容器系统检测到自身容器系统的通知消息时，确定通知消息的涉密级别。

对于本发明实施例，当后台运行的任一容器系统拦截到自身容器系统的通知消息之后，可以按照该通知消息中是否包含预设关键词和/或包含预设关键词的个数和/或该通知消息所属应用是否为预设应用，在预设的涉密级别对照表中查询以确定该通知消息的涉密级别，其中，所述涉密级别对照表包括通知消息中包括的预设关键词和/或包含预设关键词的个数和/或通知消息所属应用是否为预设应用与涉密级别的映射关系。

例如，第一通知消息中包含2个预设关键词，并且该通知消息属于预设应用，则确定该通知消息的涉密级别为三级；第二通知消息中包含2个关键词，但该通知消息不属于预设应用，则确定该通知消息的涉密级别为二级。

步骤302、后台运行的容器系统根据通知消息的涉密级别与预设最低可转发涉密级别的大小关系，判断通知消息是否可转发。

对于本发明实施例，后台运行的容器系统先确定拦截到的通知消息的涉密级别，然后将该通知消息的涉密级别与预设最低可转发涉密级别进行比较，当该通知消息高于预设最低涉密级别时，后台运行的容器系统确定该通知消息不可转发；当该通知消息低于预设最低涉密级别时，后台运行的容器系统确定该通知消息可转发。

例如，若该预设最低涉密级别为二级，则包含2个预设关键词，并且该通知消息属于预设应用的第一通知消息不可转发；包含2个关键词，但该通知消息不属于预设应用的第二通知消息可转发。

对于本发明实施例，后台运行的容器系统调用第一过滤引擎根据通知消息的涉密级别与预设最低可转发涉密级别的大小关系，判断通知消息是否可转发。其中，该过滤引擎中配置有预设最低可转发涉密级别。

对于本发明实施例，后台运行的容器系统通过确定拦截到的通知消息所属的涉密级别，并且将该通知消息所属的涉密级别与预设最低涉密级别进行比较，以确定该通知消息是否可以转发至前台运行的容器系统，从而可以避免将一些涉密信息较多的通知消息发送至前台运行的容器系统，导致泄密，进而可以进一步提高通知消息的安全性。

本发明实施例的另一种可能的实现方式，在如图3所示的基础上，后台运行的容器系统将通知消息转发至前台运行的容器系统，之前还包括如图4所示的步骤403，后台运行的容器系统将通知消息转发至前台运行的容器系统的步骤具体包括如图4所示的步骤404-405，其中，附图4所示的步骤401-402所示的操作与图3所示的步骤301-302所示的操作相同，步骤406-408所示的操作与图3所示的步骤304-306相同，在此不再赘述。

步骤403、后台运行的容器系统将通知消息进行打包处理，得到携带通知消息的数据包。

对于本发明实施例，当后台运行的容器系统确定拦截到的通知消息可以转发至前台运行的容器系统之后，将该通知消息进行打包处理，得到携带该通知消息的数据包。其中，该数据包中携带该后台运行的容器系统的系统标识。

对于本发明实施例，该携带通知消息的数据包中可以携带容器系统的标识信息，以使得前台运行的容器系统确定该通知消息所属的后台容器系统。

步骤404、后台运行的容器系统将携带通知消息的数据包，通过后台运行的容器系统中的JAVA本地接口JNI通道发送至主控系统。

对于本发明实施例，JNI通道为基于JAVA的JNI技术构建的调用通道。在本发明实施例中，每个容器系统中均存在一个JNI通道，该JNI通道的一端与通知服务子系统连接，另一端与主控系统连接。因此，两个容器系统之间可以通过各自容器系统中的JNI通道以及主控系统进行数据包的传输。

步骤405、主控系统将接收到的携带通知消息的数据包，通过前台运行的容器系统中的JNI通道，转发至前台运行的容器系统。

本发明实施例的另一种可能的实现方式，在如图2所示的基础上，步骤203、前台运行的容器系统基于第二预定判断规则判断接收到的通知消息是否可展现，具体包括如图5所示的步骤503-505，图2中的步骤201-202所示的操作与图5所示的步骤501-502相同，步骤204-205所示的操作与图5中步骤506-507相同，在此不再赘述。

步骤503、前台运行的容器系统确定解析得到的通知消息所属的应用程序。

对于本发明实施例，由于前台运行的容器系统接收到后台运行的容器系统的携带通知消息的数据包，因此前台运行的容器系统在接收到数据包之后，先解析数据包，得到通知消息，并确定该通知消息所属的应用。其中该通知消息所属的应用可以为QQ、微信以及音乐播放器等。

例如，若前台运行的容器系统接收到后台运行的容器系统的数据包的通知消息为“**音乐准备为您播放”，则该通知消息所属应用为音乐播放器；若前台运行的容器系统接收到后台运行的容器系统的数据包的通知消息为QQ联系人发来的消息，则该通知消息所属应用为QQ。

步骤504、前台运行的容器系统判断通知消息是否属于预设应用程序。

对于本发明实施例，前台运行的容器系统预先配置一个或者多个预设应用程序。例如，该预设应用程序可以为音乐播放器、浏览器等。

对于本发明实施例，预设应用程序可以由用户根据自身的需求配置在前台运行的容器系统，也可以前台运行的容器系统配置。在本发明实施例中不做限定。

步骤505、前台运行的容器系统根据判断结果，确定通知消息是否可展现。

对于本发明实施例，前台运行的容器系统调用第二规则过滤引擎判断后台运行的容器系统发送的通知消息是否属于预设应用程序，以确定该通知消息是否可展现，其中该第二规则引擎中设置有预设应用程序。

对于本发明实施例，若前台运行的容器系统判断出后台运行的容器系统发送的通知消息属于预设应用程序，则确定该通知消息不可展现；若前台运行的容器系统判断出后台运行的容器系统发送的通知消息不属于预设应用程序，则确定该通知消息可展现。

例如，前台运行的容器系统接收到后台运行的容器系统发送的2条通知消息，分别为第一通知消息以及第二通知消息，并且前台运行的容器系统确定第一通知消息所属应用为QQ，第二通知消息所属应用为音乐播放器，则前台运行的容器系统确定第一通知消息可展现，第二通知消息不可展现。

对于本发明实施例，前台运行的容器系统通过判断解析出的通知消息所属应用是否属于预设应用，能够确定是否展现该通知消息，即当前台运行的容器系统解析得到的通知消息属于预设应用时，前台运行的容器系统不展现该通知消息，从而前台运行的容器系统仅展现用户需要的应用的通知消息，进而可以提升用户体验。

本发明实施例的另一种可能的实现方式，在如图2所示的基础上，步骤203、前台运行的容器系统基于第二预定判断规则判断接收到的通知消息是否可展现，具体包括如图6所示的步骤603-604，其中，图2中的步骤201-202所示的操作与图6所示的步骤601-602相同，步骤204-205所示的操作与图6中步骤605-606相同，在此不再赘述。

步骤603、前台运行的容器系统判断接收到的通知消息的内容是否包含预设关键词。

对于本发明实施例，预设关键词可以由前台运行的容器系统配置，也可以由用户配置在前台运行的容器系统。在本发明实施例中不做限定。

例如，预设关键词包括“娱乐”、“视频”或者“红毯”。

步骤604、前台运行的容器系统根据判断结果确定通知消息是否可展现。

对于本发明实施例，若前台运行的容器系统判断接收到的通知消息的内容包含预设关键词，则确定该通知消息不可展现；若前台运行的容器系统判断接收到的通知消息不包含预设关键词，则确定该通知消息可展现。

例如，前台运行的容器系统接收到的通知消息为“***登上戛纳红毯”，则前台运行的容器系统确定该通知消息不可展现。

对于本发明实施例，前台运行的容器系统调用第三规则过滤引擎，判断后台运行的容器系统发送的通知消息是否包含预设关键词，以确定该通知消息是否可展现，其中，第三规则过滤引擎中设置有预设关键词。

对于本发明实施例，前台运行的容器系统通过判断接收到的后台通知消息的内容是否包含预设关键词，能够确定该通知消息是否可展现，即前台运行的容器系统可以不展现含有预设关键词的某些后台通知消息，仅展现一些有用的通知消息，从而可以提升用户体验。

对于本发明实施例，前台运行的容器系统可以通过步骤503-505，确定接收到的后台通知消息是否可展现；或者通过步骤603-604，确定接收到的后台通知消息是否可展现；又或者通过步骤503-505以及步骤603-604，确定接收到的后台通知消息是否可展现。

本发明实施例提供了另一种多系统通知消息处理的方法，后台运行的容器系统通过确定拦截到的通知消息所属的涉密级别，并且将该通知消息所属的涉密级别与预设最低涉密级别进行比较，以确定该通知消息是否可以转发至前台运行的容器系统，从而可以避免将一些涉密信息较多的通知消息发送至前台运行的容器系统，导致泄密，进而可以进一步提高通知消息的安全性；前台运行的容器系统通过判断解析出的通知消息所属应用是否属于预设应用，能够确定是否展现该通知消息，即当前台运行的容器系统解析得到的通知消息属于预设应用时，前台运行的容器系统不展现该通知消息，从而前台运行的容器系统仅展现用户需要的应用的通知消息，进而可以提升用户体验；前台运行的容器系统通过判断接收到的后台通知消息的内容是否包含预设关键词，能够确定该通知消息是否可展现，即前台运行的容器系统可以不展现含有预设关键词的某些后台通知消息，仅展现一些有用的通知消息，从而可以提升用户体验。

本发明实施例提供了一种多系统通知消息的处理的装置，如图7所示，该装置包括：第一判断模块71、第一转发模块72、第二判断模块73、第一转换模块74、显示模块75。

第一判断模块71，位于后台运行的任一容器系统中，用于当后台运行的任一容器系统检测到自身容器系统的通知消息时，基于第一预定判断规则判断通知消息是否可转发。

第一转发模块72，位于后台运行的容器系统中，用于当判断结果为可转发通知消息时，将通知消息转发至前台运行的容器系统。

第二判断模块73，位于前台运行的容器系统中，用于基于第二预定判断规则判断接收到的通知消息是否可展现。

第一转换模块74，位于前台运行的容器系统中，用于当判断结果为可对通知消息进行展现时，依据预定转换规则，将通知消息转换为提醒消息。

显示模块75，位于前台运行的容器系统中，用于显示提醒消息。

第一判断模块71，位于后台运行的容器系统中，具体用于确定通知消息的涉密级别。

第一判断模块71，位于后台运行的容器系统中，具体还用于根据通知消息的涉密级别与预设最低可转发涉密级别的大小关系，判断通知消息是否可转发。

进一步地，如图8所示，该装置还包括：打包处理模块81。

打包处理模块81，位于后台运行的容器系统中，用于将通知消息进行打包处理，得到携带通知消息的数据包。

第一转发模块72，位于后台运行的容器系统中，具体用于将携带通知消息的数据包，通过后台运行的容器系统中的JAVA本地接口JNI通道发送至主控系统；

进一步地，如图8所示，该装置还包括：第二转发模块82。

第二转发模块82，位于主控系统中，用于将接收到的携带通知消息的数据包，通过前台运行的容器系统中的JNI通道，转发至前台运行的容器系统。

第二判断模块73，位于前台运行的容器系统中，具体用于确定解析得到的通知消息所属的应用程序。

第二判断模块73，位于前台运行的容器系统中，具体还用于判断通知消息是否属于预设应用程序。

第二判断模块73，位于前台运行的容器系统中，具体还用于根据判断结果，确定通知消息是否可展现。

第二判断模块73，位于前台运行的容器系统中，具体用于判断接收到的通知消息的内容是否包含预设关键词。

第二判断模块73，位于前台运行的容器系统中，具体还用于根据判断结果确定通知消息是否可展现。

本发明实施例提供了一种多系统通知消息处理的装置，与后台运行的系统直接将通知消息转发至前台运行的系统，并直接显示该通知消息相比，本发明实施例通过后台运行的容器系统根据第一预定判断规则判断该通知消息是否可转发，并在可转发时转发给前台运行的容器系统，然后前台运行的容器系统根据第二预定判断规则，判断接收到的可转发的通知消息是否可展现，再根据转换规则，将通知消息转换成提醒消息，进行显示，即后台的通知消息，在发送至前台运行的容器系统之前，先通过第一预定规则过滤掉一部分通知消息，仅将可以转发至前台运行的容器系统的通知消息转发至前台运行的容器系统，前台运行的容器系统再经过第二预定规则进行第二次过滤，随后基于转换规则将两次过滤后的通知消息转换为提醒消息，并在前台运行的容器系统中显示，而不是后台运行的容器系统直接把通知消息发送至前台运行的容器系统，并直接显示，从而避免敏感信息外泄，进而可以提高通知消息的安全性。

本发明实施例提供了另一种多系统通知消息处理的装置，后台运行的容器系统通过确定拦截到的通知消息所属的涉密级别，并且将该通知消息所属的涉密级别与预设最低涉密级别进行比较，以确定该通知消息是否可以转发至前台运行的容器系统，从而可以避免将一些涉密信息较多的通知消息发送至前台运行的容器系统，导致泄密，进而可以进一步提高通知消息的安全性；前台运行的容器系统通过判断解析出的通知消息所属应用是否属于预设应用，能够确定是否展现该通知消息，即当前台运行的容器系统解析得到的通知消息属于预设应用时，前台运行的容器系统不展现该通知消息，从而前台运行的容器系统仅展现用户需要的应用的通知消息，进而可以提升用户体验；前台运行的容器系统通过判断接收到的后台通知消息的内容是否包含预设关键词，能够确定该通知消息是否可展现，即前台运行的容器系统可以不展现含有预设关键词的某些后台通知消息，仅展现一些有用的通知消息，从而可以提升用户体验。

本发明实施例提供的多系统通知消息处理的装置可以实现上述提供的方法实施例，具体功能实现请参见方法实施例中的说明，在此不再赘述。

本技术领域技术人员可以理解，本发明包括涉及用于执行本申请中所述操作中的一项或多项的设备。这些设备可以为所需的目的而专门设计和制造，或者也可以包括通用计算机中的已知设备。这些设备具有存储在其内的计算机程序，这些计算机程序选择性地激活或重构。这样的计算机程序可以被存储在设备(例如，计算机)可读介质中或者存储在适于存储电子指令并分别耦联到总线的任何类型的介质中，所述计算机可读介质包括但不限于任何类型的盘(包括软盘、硬盘、光盘、CD-ROM、和磁光盘)、ROM(Read-Only Memory，只读存储器)、RAM(Random Access Memory，随即存储器)、EPROM(Erasable ProgrammableRead-Only Memory，可擦写可编程只读存储器)、EEPROM(Electrically ErasableProgrammable Read-Only Memory，电可擦可编程只读存储器)、闪存、磁性卡片或光线卡片。也就是，可读介质包括由设备(例如，计算机)以能够读的形式存储或传输信息的任何介质。

本技术领域技术人员可以理解，可以用计算机程序指令来实现这些结构图和/或框图和/或流图中的每个框以及这些结构图和/或框图和/或流图中的框的组合。本技术领域技术人员可以理解，可以将这些计算机程序指令提供给通用计算机、专业计算机或其他可编程数据处理方法的处理器来实现，从而通过计算机或其他可编程数据处理方法的处理器来执行本发明公开的结构图和/或框图和/或流图的框或多个框中指定的方案。

本技术领域技术人员可以理解，本发明中已经讨论过的各种操作、方法、流程中的步骤、措施、方案可以被交替、更改、组合或删除。进一步地，具有本发明中已经讨论过的各种操作、方法、流程中的其他步骤、措施、方案也可以被交替、更改、重排、分解、组合或删除。进一步地，现有技术中的具有与本发明中公开的各种操作、方法、流程中的步骤、措施、方案也可以被交替、更改、重排、分解、组合或删除。

以上所述仅是本发明的部分实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。

Claims (10)

1.一种多系统通知消息处理的方法，其特征在于，所述方法包括：

当后台运行的任一容器系统检测到自身容器系统的通知消息时，基于第一预定判断规则判断所述通知消息是否可转发；

若判断结果为可转发所述通知消息，则后台运行的容器系统将所述通知消息转发至前台运行的容器系统；

所述前台运行的容器系统基于第二预定判断规则判断接收到的所述通知消息是否可展现；

若判断结果为可对所述通知消息进行展现，则依据预定转换规则，将所述通知消息转换为提醒消息，并显示所述提醒消息。

2.根据权利要求1所述的多系统通知消息处理的方法，其特征在于，基于第一预定判断规则判断所述通知消息是否可转发的步骤，包括：

确定所述通知消息的涉密级别；

根据所述通知消息的涉密级别与预设最低可转发涉密级别的大小关系，判断所述通知消息是否可转发。

3.根据权利要求2所述的多系统通知消息处理的方法，其特征在于，

所述后台运行的容器系统将所述通知消息转发至前台运行的容器系统的步骤之前，还包括：

所述后台运行的容器系统将所述通知消息进行打包处理，得到携带所述通知消息的数据包；

其中，所述后台运行的容器系统将所述通知消息转发至前台运行的容器系统的步骤，包括：

所述后台运行的容器系统将所述携带所述通知消息的数据包，通过所述后台运行的容器系统中的JAVA本地接口JNI通道发送至主控系统；

所述主控系统将接收到的所述携带通知消息的数据包，通过所述前台运行的容器系统中的JNI通道，转发至所述前台运行的容器系统。

4.根据权利要求1所述的多系统通知消息处理的方法，其特征在于，所述前台运行的容器系统基于第二预定判断规则判断接收到的所述通知消息是否可展现的步骤，包括：

所述前台运行的容器系统确定解析得到的通知消息所属的应用程序；

所述前台运行的容器系统判断所述通知消息是否属于预设应用程序；

所述前台运行的容器系统根据判断结果，确定所述通知消息是否可展现。

5.根据权利要求1所述的多系统通知消息处理的方法，其特征在于，所述前台运行的容器系统基于第二预定判断规则判断接收到的所述通知消息是否可展现的步骤，包括：

所述前台运行的容器系统判断所述接收到的通知消息的内容是否包含预设关键词；

所述前台运行的容器系统根据判断结果确定所述通知消息是否可展现。

6.根据权利要求1所述的多系统通知消息处理的方法，其特征在于，所述预定转换规则包括以下至少一种：

将一条通知消息转换为一条提醒消息；

将所属同一个应用的多条通知消息转换为一条提醒消息。

7.一种多系统通知消息处理的装置，其特征在于，所述装置包括：

第一判断模块，位于后台运行的任一容器系统中，用于当后台运行的任一容器系统检测到自身容器系统的通知消息时，基于第一预定判断规则判断所述通知消息是否可转发；

第一转发模块，位于后台运行的容器系统中，用于当判断结果为可转发所述通知消息时，将所述通知消息转发至前台运行的容器系统；

第二判断模块，位于所述前台运行的容器系统中，用于基于第二预定判断规则判断接收到的所述通知消息是否可展现；

第一转换模块，位于所述前台运行的容器系统中，用于当判断结果为可对所述通知消息进行展现时，依据预定转换规则，将所述通知消息转换为提醒消息；

显示模块，位于所述前台运行的容器系统中，用于显示所述提醒消息。

8.根据权利要求7所述的多系统通知消息处理的装置，其特征在于，

所述第一判断模块，位于所述后台运行的容器系统中，具体用于确定所述通知消息的涉密级别；

所述第一判断模块，位于所述后台运行的容器系统中，具体还用于根据所述通知消息的涉密级别与预设最低可转发涉密级别的大小关系，判断所述通知消息是否可转发；

所述装置还包括：打包处理模块；

所述打包处理模块，位于所述后台运行的容器系统中，用于将所述通知消息进行打包处理，得到携带所述通知消息的数据包；

所述第一转发模块，位于所述后台运行的容器系统中，具体用于将所述携带所述通知消息的数据包，通过所述后台运行的容器系统中的JAVA本地接口JNI通道发送至主控系统；

所述装置还包括：第二转发模块；

所述第二转发模块，位于所述主控系统中，用于将接收到的所述携带通知消息的数据包，通过所述前台运行的容器系统中的JNI通道，转发至所述前台运行的容器系统。

9.根据权利要求7所述的多系统通知消息处理的装置，其特征在于，

所述第二判断模块，位于所述前台运行的容器系统中，具体用于确定解析得到的通知消息所属的应用程序；

所述第二判断模块，位于所述前台运行的容器系统中，具体还用于判断所述通知消息是否属于预设应用程序；

所述第二判断模块，位于所述前台运行的容器系统中，具体还用于根据判断结果，确定所述通知消息是否可展现。

10.根据权利要求7所述的多系统通知消息处理的装置，其特征在于，

所述第二判断模块，位于所述前台运行的容器系统中，具体用于判断所述接收到的通知消息的内容是否包含预设关键词；

所述第二判断模块，位于所述前台运行的容器系统中，具体还用于根据判断结果确定所述通知消息是否可展现。