技术领域
[0001] 本
发明涉及用户终端通知技术领域，尤其涉及一种通知消息的推送方法、服务器、用户终端及系统。
背景技术
[0002] 在计算机技术、网络技术不断发展的今天，人们可以根据需要，通过服务器和网络向使用相应程序应用的用户发送通知消息，以提醒用户有新的消息、或者有某些待办事项等。例如，美国苹果公司推出的APNS（Apple Push Notification Service，苹果推送通知服务）中，就包括专用的消息推送服务器用于为相应的苹果用户推送通知消息。
[0003] 在
现有技术中，通知消息的推送流程为：用户在用户终端中录入即时通讯等应用账号和密码登录到现有的
应用服务器；应用服务器在检测到需要向该应用账号对应的用户发送通知消息时，应用服务器将通知消息的内容及相应的用户信息发送给通知服务器如APNS的消息推送服务器；通知服务器在接收到通知消息后，在已经进行物理连接认证和设备令牌认证的用户信息列表中查找对应的用户终端，然后生成通知消息发送对应的用户终端。
[0004]
发明人发现，通过现有方式发送通知消息时，APNS中消息推送服务器等通知服务器需要处理大量的各类应用、各个用户终端的通知消息，这必然存在通知消息延迟、甚至发送失败的情况。
发明内容
[0005] 本发明
实施例所要解决的技术问题在于，提供一种通知消息的推送方法、服务器、用户终端及系统，可较为有效地减少通知消息延期以及发送失败的情况发生。
[0006] 为了解决上述技术问题，本发明实施例提供了一种通知消息的推送方法，包括：
[0007] 应用服务器当检测到需要向目标终端推送通知消息时，检测当前与所述目标终端的信令通道的状态；
[0008] 若信令通道为连通状态，则通过该信令通道向所述目标终端发送通知消息；
[0009] 若信令通道为断开状态，生成关于所述目标终端对应账号的通知
请求发送给通知服务器，以使所述通知服务器根据所述通知请求向所述目标终端推送通知消息。
[0010] 相应地，本发明实施例还提供了一种通知消息的提示方法，包括：
[0011] 用户终端接收应用服务器发送的通知消息，所述通知消息是所述应用服务器通过与本终端处于连通状态的信令通道向本终端发送的通知消息；
[0012] 若检测到对应的客户端应用处于客户端后台运行状态，根据所述通知消息的数据内容构造提示信息，并弹出该提示信息提示给用户。
[0013] 相应地，本发明实施例还提供了一种用于通知消息推送的服务器，包括：
[0014] 检测模
块，用于当检测到需要向目标终端推送通知消息时，检测当前与所述目标终端的信令通道的状态；
[0015] 第一处理模块，用于在信令通道为连通状态时，通过该信令通道向所述目标终端发送通知消息；
[0016] 第二处理模块，用于在信令通道为断开状态时，生成关于所述目标终端对应账号的通知请求发送给通知服务器，以使所述通知服务器根据所述通知请求向所述目标终端推送通知消息。
[0017] 相应地，本发明实施例还提供了一种用于通知消息提示的用户终端，包括：
[0018] 接收模块，用于接收应用服务器发送的通知消息，所述通知消息是所述应用服务器通过与本终端处于连通状态的信令通道向本终端发送的通知消息；
[0019] 检测显示模块，用于在检测到客户端应用处于客户端后台运行状态，根据所述通知消息的数据内容构造提示信息，并弹出该提示信息提示给用户。
[0020] 相应地，本发明实施例还提供了一种通知消息的推送系统，包括：应用服务器、通知服务器以及至少一个用户终端，其中，
[0021] 所述应用服务器，用于当检测到需要向所述至少一个用户终端推送通知消息时，检测当前与所述至少一个用户终端的信令通道的状态；若信令通道为连通状态，则通过该信令通道向所述至少一个用户终端发送通知消息；若信令通道为断开状态，生成关于所述至少一个用户终端对应账号的通知请求发送给所述通知服务器；
[0022] 所述通知服务器，用于在接收到所述应用服务器的通知请求时，根据所述通知请求向所述至少一个用户终端推送通知消息；
[0023] 所述至少一个用户终端，用于在接收到所述应用服务器发送的通知消息或者接收到通知服务器发送的通知消息时，向用户提示所述通知消息的内容。
[0024] 本发明实施例可以通过检测与用户终端的信令通道是否连通，并在连通时应用服务器向用户终端直接发送一个通知消息，在不连通是才请求用于向用户终端发送通知消息的服务器向用户终端发送通知消息，可以分担一部分用于向用户终端发送通知消息的服务器的通知处理负担，较好地减小通知消息的延迟，较好地避免了通知消息发送失败的情况。
附图说明
[0025] 为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
[0026] 图1是本发明实施例的一种通知消息的推送方法的流程示意图；
[0027] 图2是本发明实施例的另一种通知消息的推送方法的流程示意图；
[0028] 图3是本发明实施例的一种通知消息的提示方法的流程示意图；
[0029] 图4是本发明实施例的一种通知消息的推送系统的结构示意图；
[0030] 图5是本发明实施例的一种用于通知消息推送的服务器的结构示意图；
[0031] 图6是本发明实施例的另一种用于通知消息推送的服务器的结构示意图；
[0032] 图7是本发明实施例的一种用于通知消息提示的用户终端的结构示意图。
具体实施方式
[0033] 下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
[0034] 请参见图1，是本发明实施例的一种通知消息的推送方法的流程示意图，本发明实施例的所述推送方法可应用在各类需要向用户终端推送通知消息的应用服务器中，具体可以应用在各类
即时通信应用服务器向登录即时通信应用账号的用户终端发送新消息提醒、待办事项提醒等通知消息的场景。所述方法包括：
[0035] S101：应用服务器当检测到需要向目标终端推送通知消息时，检测当前与所述目标终端的信令通道的状态。
[0036] 在所述S101中，所述应用服务器可以通过判断是否接收到由所述目标终端中对应的即时通讯应用在信令通道中发起的连通信令，如果接收到连通信令，则可以确定当前与所述目标终端信令通道为连通状态，如果没有接收到连通信令，则为断开状态。进一步具体可以判断在预设的时间范围
阈值内是否接收到由所述目标终端中对应的即时通讯应用在信令通道中发起的连通信令。
[0037] 目标终端为任意一个登录了即时通信应用等应用账号的用户终端。应用服务器在向所述目标终端发送新消息或者检测到关于所述目标终端对应应用账号的待办事项发生等情况下，会向所述目标终端发送通知消息。应用服务器检测是否需要向目标终端推送通知消息为现有技术，在此不赘述。
[0038] 所述信令通道是网络中为了保证网络正常运行、用户正常使用的一个控制通道，应用服务器与目标终端之间可以在信令通道中发送简单的指令。
[0039] 用户在目标终端上通过应用账号登录到应用服务器后，信令通道可以作为目标终端（如即时通讯应用）和应用服务器之间发送“心跳
信号”的通道，目标终端可以通过心跳连接机制与应用服务器通信，使应用服务器确定该目标终端对应的用户为活跃用户。通过“心跳信号”应用服务器和目标终端相互能够知道对方的状态，确定对方是否能够接收和处理消息，应用服务器也能够知道目标终端的通信地址，以向所述目标终端发送消息。
[0040] 具体的，目标终端可以在每个一定时间通过一个自定义的数据结构体（心跳包或心跳
帧）发送给应用服务器，以便于使应用服务器确定该目标终端对应的应用账号在线，以确保目标终端和应用服务器之间连接的有效性。也就是说，在本发明实施例中，应用服务器可以通过检查心跳连接是否正常来判断当前与所述目标终端的信令通道的状态。与所述目标终端的信令通道的状态至少包括连通状态和断开状态。
[0041] S102：若信令通道为连通状态，则通过该信令通道向所述目标终端发送通知消息。
[0042] S103：若信令通道为断开状态，生成关于所述目标终端对应账号的通知请求发送给通知服务器，以使所述通知服务器根据所述通知请求向所述目标终端推送通知消息。
[0043] 其中，所述通知服务器具体为用于向所述目标终端对应账号推送通知消息的服务器，例如在APNS中的消息推送服务器。
[0044] 当前目标终端与应用程序的信令通道连通时，在所述S102中，应用服务器通过信令通道直接发送一条通知消息（即伪通知消息）给所述目标终端，并不需要通过专用的向所述目标终端对应账号推送通知消息的通知服务器（如APNS中的消息推送服务器）发送通知消息。随后在用户将相应的应用在所述目标终端前台打开后，将具体的新消息或者待办事项的数据发送给用户终端，由目标终端通过应用程序显示给用户。
[0045] 而如果目标终端与应用程序的信令通道连断开，那么在所述S103中，应用服务器则需要通过通知服务器如APNS中的消息推送服务器向所述目标终端发送通知消息，当用户将相应的应用在目标终端前台打开后，将具体的新消息或者待办事项的数据发送给目标终端，由目标终端通过应用程序显示给用户。
[0046] 本发明实施例可以通过检测与用户终端的信令通道是否连通，并在连通时应用服务器向用户终端直接发送一个通知消息，在不连通是才请求用于向用户终端发送通知消息的服务器向用户终端发送通知消息，可以分担一部分用于向用户终端发送通知消息的服务器的通知处理负担，较好地减小通知消息的延迟，较好地避免了通知消息发送失败的情况。
[0047] 再请参见图2，是本发明实施例的另一种通知消息的推送方法的流程示意图，本发明实施例的所述推送方法可应用在各类需要向用户终端推送通知消息的应用服务器中，具体可以应用在各类即时通信应用服务器向登录即时通信应用账号的用户终端发送新消息提醒、待办事项提醒等通知消息的场景。所述方法包括：
[0048] S201：应用服务器当检测到需要向目标终端推送通知消息时，检测当前与所述目标终端的信令通道的状态。
[0049] 检测是否需要向目标终端推送通知消息可采用现有技术实现，在本发明实施例中，所述S201具体可以包括：
[0050] 当检测到需要向目标终端推送通知消息时，判断与所述目标终端的心跳连接是否正常；若心跳连接正常，则检测确定当前与所述目标终端的信令通道的状态为连通状态，为连通状态时，执行下述的S202，若心跳连接异常，为断开状态，执行下述的S205。其中，心跳连接为正常还是为异常的判定可以采用现有技术实现。
[0051] S202：若信令通道为连通状态，应用服务器通过该信令通道向所述目标终端发送通知消息。
[0052] S203：应用服务器判断在预设的时间范围内是否接收到目标终端响应所述通知消息回复的通知确认消息。
[0053] 在所述S202中向目标终端发送了通知消息后，可能会由于网络的原因或者用户终端的原因导致通知消息没有正确
送达到目标终端。因此，在本发明实施例中，设置接收确认机制，即用户终端在接收到应用服务器通过信令通道直接发送的通知消息（伪通知消息）后，向应用服务器回复通知确认消息。用户终端也可以在接收到应用服务器通过信令通道直接发送的通知消息并成功显示提示给用户后，向应用服务器回复通知确认消息。没有接收到通知消息或者接收后没有正常提示，用户终端均不会自动回复通知确认消息。
[0054] 应用服务器在接收到目标终端响应所述通知消息回复的通知确认消息时，与现有技术相同，执行发送对应的消息或者待办事项等数据，没有接收到通知确认消息时，执行下述的S204。
[0055] S204：若在预设的时间范围内没有接收到所述目标终端回复的通知确认消息，应用服务器生成关于所述目标终端对应账号的通知请求发送给所述通知服务器，以使所述通知服务器根据所述通知请求向所述目标终端推送通知消息。
[0056] 应用服务器可以在通过该信令通道向所述目标终端发送通知消息时，开始计时，在预设的时间范围内，例如3秒内，没有接收到所述目标终端回复的通知确认消息，则可以确定本次通过信令通道发送的通知消息失败，执行所述S204，生成关于所述目标终端对应账号的通知请求发送给所述通知服务器，以使所述通知服务器根据所述通知请求向所述目标终端推送通知消息。
[0057] S205：若信令通道为断开状态，应用服务器生成关于所述目标终端对应账号的通知请求发送给通知服务器，以使所述通知服务器根据所述通知请求向所述目标终端推送通知消息。
[0058] 其中，本发明实施例中，在所述S204或S205中，生成关于所述目标终端对应账号的通知请求发送给通知服务器，包括：获取关于所述目标终端对应账号的通知内容数据，生成包括关于所述目标终端对应账号的通知内容数据的通知请求；将包括关于所述目标终端对应账号的通知内容数据的通知请求发送给通知服务器。所述获取的通知内容数据包括：获取用户有新消息的通知内容，或者获取用户有待办事项的通知内容等。应用服务器将相应的通知内容数据发送给APNS等通知服务器，由通知服务器生成相应的通知消息发送给所述目标终端。
[0059] 进一步可选地，在执行了所述的S205后，所述方法进一步还可以包括：
[0060] S206：所述应用服务器判断在预设的时间范围内是否接收到目标终端响应所述通知消息回复的通知确认消息；
[0061] S207：若在预设的时间范围内没有接收到所述目标终端回复的通知确认消息，所述应用服务器检测与所述目标终端的信令通道的状态；
[0062] S208：若信令通道为连通状态，所述应用服务器通过该信令通道向所述目标终端发送通知消息。
[0063] 在本发明实施例中，通过通知服务器向所述目标终端发送通知消息后，也可以通过一个终端反馈机制来确定用户终端是否接收到通知消息，并在没有接收到所述目标终端的用于反馈的通知确认消息时，再次检测与所述目标终端的信令通道的状态，由于目标终端中相应的即时通讯应用有可能在此时再次在信令通道中发起了连通信令（即心跳信令），因此，应用服务器有可能会检测确定与所述目标终端的信令通道的状态为连通状态，应用服务器就可以通过信令通道发送该通知消息给所述目标终端。
[0064] 本发明实施例可以通过检测与用户终端的信令通道是否连通，并在连通时应用服务器向用户终端直接发送一个通知消息，在不连通是才请求用于向用户终端发送通知消息的服务器向用户终端发送通知消息，可以分担一部分用于向用户终端发送通知消息的服务器的通知处理负担，较好地减小通知消息的延迟，较好地避免了通知消息发送失败的情况。并且，在通知消息发送后，还能够根据是否接收到用户终端反馈的确认消息以判断通知消息是否发送成功，在发送成功后再作通知处理，而在确定发送不成功后，再通过用于向用户终端发送通知消息的服务器向用户终端发送通知消息，较好地保证了通知消息能够送达到用户终端。
[0065] 再请参见图3，是本发明实施例的一种通知消息的提示方法的流程示意图，本发明实施例的所述方法可应用在各类需要向用户终端推送通知消息的应用中，由用户终端执行本发明实施例所述的方法向用户显示推送的通知消息，具体的，本发明实施例所述的方法包括：
[0066] S301：用户终端接收应用服务器发送的通知消息，所述通知消息是所述应用服务器通过与本终端处于连通状态的信令通道向本终端发送的通知消息。
[0067] 用户终端根据通知消息发送端的设备标识如IP地址以及传输通道，可以确定该通知消息是否由其对应的应用服务器通过与本终端处于连通状态的信令通道向本终端发送的通知消息。
[0068] S302：若检测到对应的客户端应用处于客户端后台运行状态，用户终端根据所述通知消息的数据内容构造提示信息，并弹出该提示信息提示给用户。
[0069] 所述用户终端可以为上述实施例中的所述目标终端。
[0070] 而如果为对应的即时通讯应用为如用户终端当前处于
锁屏状态或者用户当前正在处理其他事件时，用户终端后台运行，需要根据所述通知消息的数据内容构造一个简单的提示信息tips，并弹出该提示信息提示给用户。
[0071] 若检测到对应的客户端应用处于前台运行状态，用户终端不会显示所述通知消息；也就是说，用户当前正处于客户端应用的
用户界面中，例如在对应即时通讯应用的用户会话界面中，则直接接收并显示应用服务器发送的该通知消息对应的具体消息或者具体待办事项数据等内容以显示给用户，具体的包括：显示应用服务器在通知消息之后发送了一个消息，并且把该消息以及会话移到通讯列表的顶端。
[0072] 进一步的，在用户终端接收到应用服务器发送的通知消息后，还包括：向所述应用服务器发送通知确认消息。以便于通知应用服务器确定其通知消息发送成功，相反，如果用户终端没有接收到应用服务器发送的通知消息时，不会回复通知确认消息，应用服务器可以根据需要转由所述通知服务器向所述用户终端发送通知消息。
[0073] 而如果用户终端接收到的是APNS等通知服务器发送的通知消息，则其对接收到的通知消息的处理流程与现有技术相同，在此不赘述。
[0074] 用户终端能够直接通过信令通道接收通知消息，可以较好地保证通知消息的及时提醒，并且反馈机制也进一步地确保了在用户终端在信令通道中没有接收到通知消息时，也可以接收到应用服务器通过用于对用户终端发送通知消息的服务器发送的通知消息，可以进一步地保证通知消息的及时提醒，较好地减小通知消息的延迟，较好地避免了通知消息发送失败的情况。
[0075] 下面对本发明实施例的服务器、用户终端以及系统进行详细描述。
[0076] 请参见图4，是本发明实施例的一种通知消息的推送系统的结构示意图，本发明实施例的所述系统包括：应用服务器1、通知服务器2以及至少一个用户终端，本发明实施例以其中的用户终端3进行说明，其他用户终端执行相同的操作，其中，所述通知服务器为用于向所述目标终端对应账号推送通知消息的服务器，其可以为APNS中的消息推送服务器。具体的：
[0077] 所述应用服务器11，用于当检测到需要向所述用户终端3推送通知消息时，检测当前与所述用户终端3的信令通道的状态；若与所述用户终端3的信令通道为连通状态，则通过该信令通道向所述用户终端3发送通知消息；若与所述用户终端3的信令通道为断开状态，生成关于所述用户终端3对应账号的通知请求发送给所述通知服务器2；
[0078] 所述通知服务器2，用于在接收到所述应用服务器1的通知请求时，根据所述通知请求向所述用户终端3推送通知消息；
[0079] 所述用户终端3，用于在接收到所述应用服务器1发送的通知消息或者接收到通知服务器2发送的通知消息时，向用户提示所述通知消息的内容。
[0080] 所述用户终端3接收到通知服务器2发送的通知消息时，执行与现有技术相同的操作以向用户提示所述通知消息的内容。
[0081] 而在接收到所述应用服务器1发送的通知消息时，所述用户终端3具体用于若检测到对应的客户端应用处于前台运行状态，不显示所述通知消息，直接接收并显示应用服务器1后续发送的消息；若检测到对应的客户端应用处于客户端后台运行状态，根据所述通知消息的数据内容构造提示信息，并弹出该提示信息提示给用户。
[0082] 另外，所述用户终端3，还用于在接收到所述应用服务器发送的通知消息后，向所述应用服务器1发送通知确认消息。
[0083] 所述应用服务器1，还用于在通过与所述用户终端3处于连通状态的信令通道向所述用户终端3发送通知消息之后，判断在预设的时间范围内是否接收到用户终端3响应所述通知消息回复的通知确认消息；若在预设的时间范围内没有接收到所述用户终端3回复的通知确认消息，生成关于所述用户终端3对应账号的通知请求发送给所述通知服务器2。
[0084] 本发明实施例可以通过检测与用户终端的信令通道是否连通，并在连通时应用服务器向用户终端直接发送一个通知消息，在不连通是才请求用于向用户终端发送通知消息的服务器向用户终端发送通知消息，可以分担一部分用于向用户终端发送通知消息的服务器的通知处理负担，较好地减小通知消息的延迟，较好地避免了通知消息发送失败的情况。并且，在通知消息发送后，还能够根据是否接收到用户终端反馈的确认消息以判断通知消息是否发送成功，在发送成功后再作通知处理，而在确定发送不成功后，再通过用于向用户终端发送通知消息的服务器向用户终端发送通知消息，较好地保证了通知消息能够送达到用户终端。
[0085] 具体的，请参见图5，是本发明实施例的一种用于通知消息推送的服务器的结构示意图，本发明实施例的所述服务器可以为上述图4对应实施例中的应用服务器1，具体的，所述服务器包括：
[0086] 检测模块11，用于当检测到需要向目标终端推送通知消息时，检测当前与所述目标终端的信令通道的状态；
[0087] 第一处理模块12，用于在信令通道为连通状态时，通过该信令通道向所述目标终端发送通知消息；
[0088] 第二处理模块13，用于在信令通道为断开状态时，生成关于所述目标终端对应账号的通知请求发送给通知服务器，以使所述通知服务器根据所述通知请求向所述目标终端推送通知消息。
[0089] 所述目标终端为任意一个登录了即时通信应用等应用账号的用户终端，如上述图4对应实施例中的用户终端3。所述检测模块11在向所述目标终端发送新消息或者检测到关于所述目标终端对应应用账号的待办事项发生等情况下，会向所述目标终端发送通知消息。应用服务器通过所述检测模块11检测是否需要向目标终端推送通知消息为现有技术，在此不赘述。
[0090] 对于检测当前与所述目标终端的信令通道的状态，所述检测模块11可以通过检查心跳连接是否正常来判断当前与所述目标终端的信令通道的状态。与所述目标终端的信令通道的状态至少包括连通状态和断开状态。
[0091] 当前目标终端与应用程序的信令通道连通时，所述第一处理模块12通过信令通道直接发送一条通知消息（即通过此方式发送的通知消息为伪通知消息）给所述目标终端，并不需要通过专用的向所述目标终端对应账号推送通知消息的通知服务器（如APNS中的消息推送服务器）发送通知消息。随后在用户将相应的应用在用户终端前台打开后，将具体的新消息或者待办事项的数据发送给用户终端，由用户终端通过应用程序显示给用户。
[0092] 而如果目标终端与应用程序的信令通道连断开，那么所述第二处理模块13则需要通过通知服务器如APNS中的消息推送服务器向所述目标终端发送通知消息，当用户将相应的应用在目标终端前台打开后，将具体的新消息或者待办事项的数据发送给目标终端，由目标终端通过应用程序显示给用户。
[0093] 本发明实施例可以通过检测与用户终端的信令通道是否连通，并在连通时应用服务器向用户终端直接发送一个通知消息，在不连通是才请求用于向用户终端发送通知消息的服务器向用户终端发送通知消息，可以分担一部分用于向用户终端发送通知消息的服务器的通知处理负担，较好地减小通知消息的延迟，较好地避免了通知消息发送失败的情况。
[0094] 进一步地，再请参见图6，是本发明实施例的另一种用于通知消息推送的服务器的结构示意图，本发明实施例的所述服务器可以为上述图4对应实施例中的应用服务器1，并且，本发明实施例中的所述服务器包括上述图5对应实施例中的检测模块11、第一处理模块12以及第二处理模块13，在本发明实施例中，所述服务器还包括：
[0095] 第一判断模块14，用于在所述第一处理模块12向所述目标终端发送通知消息之后，判断在预设的时间范围内是否接收到目标终端响应所述通知消息回复的通知确认消息；
[0096] 所述第二处理模块13，还用于在预设的时间范围内没有接收到所述目标终端回复的通知确认消息时，生成关于所述目标终端对应账号的通知请求发送给所述通知服务器，以使所述通知服务器根据所述通知请求向所述目标终端推送通知消息。
[0097] 在所述第一处理模块12向目标终端发送了通知消息后，可能会由于网络的原因或者用户终端的原因导致通知消息没有正确送达到目标终端。因此，在本发明实施例中，设置接收确认机制，即用户终端在接收到应用服务器通过信令通道直接发送的通知消息（伪通知消息）后，向应用服务器回复通知确认消息。用户终端也可以在接收到应用服务器通过信令通道直接发送的通知消息并成功显示提示给用户后，向应用服务器回复通知确认消息。没有接收到通知消息或者接收后没有正常提示，用户终端均不会自动回复通知确认消息。
[0098] 所述第一判断模块14判断接收到目标终端响应所述通知消息回复的通知确认消息时，与现有技术相同，执行发送对应的消息或者待办事项等数据，而如果所述第一判断模块14判断没有接收通知确认消息，则通过所述第二处理模块13生成关于所述目标终端对应账号的通知请求发送给所述通知服务器，以使所述通知服务器根据所述通知请求向所述目标终端推送通知消息。
[0099] 进一步可选地，请参见图6，所述服务器还包括：
[0100] 获取模块15，用于获取关于所述目标终端对应账号的通知内容数据；
[0101] 所述第二处理模块13，用于生成包括关于所述目标终端对应账号的通知内容数据的通知请求，将包括关于所述目标终端对应账号的通知内容数据的通知请求发送给所述通知服务器。
[0102] 所述获取模块15获取的通知内容数据包括：获取用户有新消息的通知内容，或者获取用户有待办事项的通知内容等。所述第二处理模块13将相应的通知内容数据发送给APNS等通知服务器，由通知服务器生成相应的通知消息发送给所述目标终端。
[0103] 进一步可选地，再请参见图6，所述检测模块11具体可以包括：
[0104] 判断单元，用于当检测到需要向目标终端推送通知消息时，判断与所述目标终端的心跳连接是否正常；
[0105] 确定单元，用于在心跳连接正常时，确定当前与所述目标终端的信令通道的状态为连通状态，在心跳连接异常时，为断开状态。
[0106] 进一步可选地，再请参见图6，本发明实施例的所述装置还可以包括：
[0107] 第二判断模块16，用于判断在预设的时间范围内是否接收到目标终端响应所述通知消息回复的通知确认消息；
[0108] 所述检测模块11，还用于所述第二判断模块16的判断结果为接收到所述目标终端回复的通知确认消息，检测与所述目标终端的信令通道的状态；
[0109] 所述第一处理模块12，还用于若信令通道为连通状态，通过该信令通道向所述目标终端发送通知消息。
[0110] 在本发明实施例中，所述第二处理模块13通过通知服务器向所述目标终端发送通知消息后，也可以通过一个终端反馈机制来确定用户终端是否接收到通知消息，并在所述第二判断模块16在判断没有接收到所述目标终端的用于反馈的通知确认消息时，通过所述检测模块11再次检测与所述目标终端的信令通道的状态，由于目标终端中相应的即时通讯应用有可能在此时再次在信令通道中发起了连通信令（即心跳信令），因此，所述检测模块11有可能会检测确定与所述目标终端的信令通道的状态为连通状态，所述第一处理模块12就可以通过信令通道发送该通知消息给所述目标终端。
[0111] 本发明实施例可以通过检测与用户终端的信令通道是否连通，并在连通时应用服务器向用户终端直接发送一个通知消息，在不连通是才请求用于向用户终端发送通知消息的服务器向用户终端发送通知消息，可以分担一部分用于向用户终端发送通知消息的服务器的通知处理负担，较好地减小通知消息的延迟，较好地避免了通知消息发送失败的情况。并且，在通知消息发送后，还能够根据是否接收到用户终端反馈的确认消息以判断通知消息是否发送成功，在发送成功后再作通知处理，而在确定发送不成功后，再通过用于向用户终端发送通知消息的服务器向用户终端发送通知消息，较好地保证了通知消息能够送达到用户终端。
[0112] 再请参见图7，是本发明实施例的一种用于通知消息提示的用户终端的结构示意图，本发明实施例所述的用户终端可以为上述图4对应实施例中的用户终端3，具体的，本发明实施例的所述用户终端包括：
[0113] 接收模块31，用于接收应用服务器发送的通知消息，所述通知消息是所述应用服务器通过与本终端处于连通状态的信令通道向本终端发送的通知消息；
[0114] 检测显示模块32，用于在检测到客户端应用处于客户端后台运行状态，根据所述通知消息的数据内容构造提示信息，并弹出该提示信息提示给用户。
[0115] 所述接收模块31根据通知消息发送端的设备标识如IP地址以及传输通道，可以确定该通知消息是否由其对应的应用服务器通过与本终端处于连通状态的信令通道向本终端发送的通知消息。
[0116] 若检测到对应的客户端应用处于前台运行状态，用户终端不会显示所述通知消息，也就是说，用户当前正处于所述应用服务器对应的客户端应用的用户界面中，例如与对应即时通讯应用的用户会话界面中，所述检测显示模块32直接显示接收到的应用服务器发送的该通知消息对应的具体消息或者具体待办事项数据等内容以显示给用户。
[0117] 而如果为对应的即时通讯应用为如用户终端当前处于锁屏状态或者用户当前正在处理其他事件时，用户终端后台运行，所述检测显示模块32需要根据所述通知消息的数据内容构造一个简单的提示信息tips，并弹出该提示信息提示给用户。
[0118] 进一步可选地，再请参见图7，所述用户终端还可以包括：
[0119] 确认模块33，用于在接收应用服务器发送的通知消息后，向所述应用服务器发送通知确认消息。
[0120] 而如果所述接收模块31接收到的是APNS等用于向所述目标终端对应账号推送通知消息的通知服务器发送的通知消息，则其对接收到的通知消息的处理流程与现有技术相同，在此不赘述。
[0121] 用户终端能够直接通过信令通道接收通知消息，可以较好地保证通知消息的及时提醒，并且反馈机制也进一步地确保了在用户终端在信令通道中没有接收到通知消息时，也可以接收到应用服务器通过用于对用户终端发送通知消息的服务器发送的通知消息，可以进一步地保证通知消息的及时提醒，较好地减小通知消息的延迟，较好地避免了通知消息发送失败的情况。
[0122] 本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过
计算机程序来指令相关的
硬件来完成，所述的程序可存储于一计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，所述的存储介质可为磁碟、光盘、只读存储记忆体（Read-Only Memory，ROM）或随机存储记忆体（Random Access Memory，RAM）等。
[0123] 以上所揭露的仅为本发明较佳实施例而已，当然不能以此来限定本发明之权利范围，因此依本发明
权利要求所作的等同变化，仍属本发明所涵盖的范围。
