CN103873354A - 一种即时通信客户端及服务端 - Google Patents

Abstract

本发明提供一种即时通信客户端以及服务端，其中群主客户端在该群消息界面选中群呼选项时，客户端向服务端发送群呼请求以请求服务端向其他在线用户的客户端发送呼叫请求，其他客户端接收到服务端发送的呼叫请求时，控制该终端输出呼叫提示且该呼叫提示的极限持续时长为第一指定时长。在相反的方向上，多个用户向服务端发送单呼请求时，服务端发现预定条件满足时，向群主的客户端发送呼叫请求。本发明根据群内即时通信的需要引入呼叫提示和普通消息提示两种输出机制，并且在上下行方向上采用不同呼叫请求触发机制，既能够合理使用呼叫请求机制来服务群内通信需要，又能够合理控制呼叫请求的使用。

Description

一种即时通信客户端及服务端

技术领域

本发明涉及即时通信领域，尤其涉及一种即时通信客户端及服务器。

背景技术

在互联网技术进入普通民众生活之后，即时通信技术给民众带来了各种工作与生活的便利。从早期的ICQ以及OICQ（今日广泛使用的QQ）到如今更新一代的微信以及来往等，即时通信技术正在不断地向着更加便利用户的方向演进。

目前很多即时通信客户端都开始支持群聊技术，群聊技术可以允许一些对共同话题关注的用户聚集在一起进行信息的交互与分享。在一个用户群内，群内用户通常区分为多种角色，比如管理员（也称为“群主”）与普通用户，当然可能还有副群主这样的角色。目前，在群聊应用中，用户的需求与点对点的通信需求有着较大的差异。群聊应用特点是共同话题与事件往往需要三个或者更多的用户一起参与，有时候需要多个不同角色的用户一起参与，缺少特定角色的用户或者缺少足够数量的用户，往往会导致特定应用下的用户体验下降。因此，用户群中用户非常关注召集话题参与者的功能。目前这种功能的实现依赖于传统的方式，比如发送即时消息，甚至打电话等等来通知特定用户登录并参与进来。

发送即时消息来实现参与用户召集其提示效果较差，用户可能并不关注即时消息的提示。而使用电话方式则更加不方便，召集者可能需要拨打多个电话，甚为不便。以一个简单的示例来说，假设一个同学关系的用户群中，多个用户希望就聚餐事宜通知大家相应的时间与地点。通知者往往是到群里发个消息，然后看看谁回复了，没有回复的人，通知者通常再拨打电话确认其是否收到该消息。由此可见，现有技术在群体即时通信的实现上仍然存在用户使用不便利等缺点。

发明内容

有鉴于此，本发明提供一种即时通信客户端，应用于便携式用户终端上，与服务端配合使用，该客户端包括：会话管理单元、呼叫发起单元以及呼叫处理单元，其中：

会话管理单元，用于为用户开启群消息界面，针对下行核心用户在该群消息界面上提供群呼选项，针对非核心用户在该群消息界面上提供单呼选项；

呼叫发起单元，用于在用户选中群呼选项时，向服务端发送针对群内所有其他用户的群呼请求，该群呼请求中携带有用户所属用户群标识以及群呼标识；当用户选中单呼选项，向所述服务端发送针对被叫用户的单呼请求；

呼叫处理单元，用于在接收到服务器发送的呼叫请求时按照预定的前台占用优先级向操作系统请求前台占用；并在请求前台占用成功的情况下，在用户终端屏幕上输出至少部分覆盖当前用户界面的呼叫响应界面，并在呼叫提示被允许的情况下控制该用户终端输出一种或多种呼叫提示，其中该呼叫响应界面包括接受选项以及拒绝选项。

本发明还提供一种即时通信服务端，应用于即时通信服务提供商的服务器上，与即时通信用户使用的客户端配合使用，该服务端端包括：群呼处理单元以及单呼处理单元，其中：

群呼处理单元，用于在接收到下行核心用户发送的群呼请求时，获取该消息中携带的用户群标识，向该用户群内的其他在线用户发送呼叫请求；

单呼处理单元，用于在接收到针对上行核心用户的单呼请求时，获取该消息中携带的用户群标识；在该用户群的单呼请求列表中记录本次单呼请求，判断当前单呼请求列表是否满足预定条件，若满足，则向该上行核心用户发送呼叫请求，清空该用户群的单呼请求列表。

相较于现有技术，本发明根据群内即时通信的需要引入呼叫提示和普通即时通信消息提示两种输出机制，并且在上下行方向上采用不同呼叫请求触发机制，既能够合理使用呼叫请求机制来服务群内通信需要，又能够合理控制呼叫请求的使用，避免给用户带来糟糕的体验。

附图说明

图1是本发明一种实施方式中客户端与服务端的逻辑结构以及基本硬件环境示意图。

图2是本发明一种实施方式中的处理流程图。

图3是本发明一种实施方式中客户端一侧的处理流程图。

图4是本发明一种实施方式中服务端一侧的第一部分处理流程图。

图5是本发明一种实施方式中服务端一侧的第二部分处理流程图。

具体实施方式

针对现有技术的问题，在优选的方式中，本发明提供一种新的即时通信客户端以及与之配合的服务端。在以下实施方式中，所述客户端以及服务端是一种计算机软件实现的虚拟装置，分别运行于便携式用户终端（比如智能手机）以及即时通信服务提供商的服务器上。当然本发明并不排除其他诸如逻辑器件或者硬件等实现方式。在此仅以最为流行的软件实现为例进行示例性说明，在硬件环境上，用户终端与服务器有较大的差异，但是为了描述方便起见，图1中只是示例性地给出了客户端与服务端运行所需的基本通用的硬件架构。

请参考图1，从逻辑功能层面上讲，该客户端包括会话管理单元、呼叫发起单元以及呼叫处理单元；而该服务端包括群呼处理单元以及单呼处理单元。在客户端一侧，从用户的角色做区分，用户可以分为两大角色。第一种是核心用户，在本发明中，核心用户细分为下行核心用户以及上行核心用户，其中下行核心用户拥有发送群呼请求权限，该群呼请求用于请求或者说触发服务端向群内所有其他在线用户发送呼叫请求。在实际使用过程中，下行核心用户一般为群主或副群主，当然也可以是群主指定的拥有该权限的用户；上行核心用户则为可以被服务端单独发送呼叫请求的用户。第二种是拥有单呼请求权限的非核心用户，一般情况下，群内所有用户都拥有该权限。在开发过程中，客户端的实现是可以统一的，依据权限不同的用户呈现不同的群消息界面给用户。以下为了描述方便，仅以群主同时是上行核心用户和下行核心用户为例进行说明，当然事实上，上行核心用户和下行核心用户可以是不同的用户。

用户在智能手机上安装好客户端之后，其可以进行注册，成为注册用户后上线。在用户登录过程中，客户端获取用户输入的身份认证信息（比如用户名与密码）发送给服务端，服务端对该身份认证信息进行验证，若通过则允许用户上线，并返回该用户的群属性信息。用户首次登陆时，其可能没有加入任何用户群，在登录后可以通过在用户界面上搜索，创建或者以其他方式加入某个用户群中，服务端记录该用户的群属性信息，群属性信息一般包括该用户所属用户群ID以及在各个用户群中的角色等。这部分的处理与实现可以参考现有技术，本发明在此不再一一详述。

请参考图2以及图3，在登录之后，用户开启群消息界面，此时会话管理单元根据用户权限来确定该用户的群消息界面。假设当前用户在其所属的用户群中为群主，则会话管理单元根据用户的开启指令，为用户开启群消息界面，并在该操作界面上提供群呼选项，比如图2中的“发送群呼”这一触摸按钮就是所述群呼选项；当然也可以为该用户提供单呼选项；对于普通群用户，则可以仅提供单呼选项。若用户在该操作界面上选中该群呼选项，比如用户点击该触摸按钮，则呼叫发起单元向服务端发送群呼请求，该消息中携带有群ID以及群呼类型标记，比如使用“0102”作为群呼类型标记，表征该消息为群呼类型的请求。在优选的方式中，呼叫发起单元在群消息界面上提供附加输入栏，以允许用户通过各种方式输入附加数据，比如文本类数据以及多媒体类地址数据中的一种或者多种，其中多媒体数据主要包括图片、音频以及视频，甚至可以是其他类型的文件。

用户输入附加数据的方式多种多样，一种方式是在文本输入栏中输入文本类数据，另一种方式是附加多媒体类地址数据。针对文本类的附加数据，该类附加数据可以携带在群呼请求中发送给服务端。在向上传服务端上传该多媒体文件并获取该上传服务端返回的多媒体类地址数据，用户通过附加输入栏附加多媒体文件时，呼叫发起单元则可先向上传服务器上传用户选择的多媒体文件（比如一个视频文件），并获得服务器返回的多媒体地址数据，该地址数据通常是一个URL。呼叫发起单元将该多媒体类地址数据携带在群呼请求中发送给服务端。

请继续参考图2、图3以及图4，在图4中，服务端收到群内通信的消息时，首先判断该消息是否合法，如果不合法则丢弃该消息。消息不合法的情况有多种，比如消息格式有误又或者群ID等信息不存在或者错误等。若消息合法，则可以先判断消息类型，对于群呼请求和单呼请求（后文继续描述）以外的普通消息，比如群内普通消息发布，按照既有规则在群内转发给其他在线用户即可。对于单呼请求，由单呼处理单元处理，对于群呼类型消息，则由群呼处理单元处理，其可根据该消息中携带的用户群标识向该用户群内其他在线用户发送呼叫请求，比如消息类型可以为“0103”。

如果群呼请求中没有携带附加数据，则直接发送呼叫请求即可。如果群呼请求中携带有附加数据，则群呼处理单元从该消息中获取该附加数据。在优选的方式中，群呼处理单元可以先判断该数据有无文本类的附加数据，若该附加数据中有文本类的附加数据，则将该附加数据添加到呼叫请求中发送给群内其他在线用户，接下来判断是否还有多媒体类附加数据，若该附加数据中还有多媒体类地址数据，则将该多媒体类地址数据携带在呼叫请求中发送给客户端，并向CDN（内容分发网络）系统发送针对该地址对应的多媒体数据（通常为一个多媒体文件）的同步请求。考虑到该地址后续可能被很多用户同时访问，若不进行同步，虽然并不影响访问的可达性，但是若同时访问的用户过多可能造成访问速度下降，从用户的角度看，则是视频音频播放不流畅，图片下载缓慢等等。此时本发明有针对性地通知CDN系统该地址对应的数据进行同步，可以确保用户能够以较佳的体验获得该多媒体数据，提升用户体验。值得注意的是，这里的在线用户是一个广义的概念，并不要求用户的客户端必须在前台在线运行，该用户的客户端在后台保持与服务端的连接并处于可唤醒客户端程序状态亦可。

每个在线用户的客户端收到该呼叫请求后，其呼叫处理单元确定该消息类型为呼叫请求，呼叫处理单元此时按照预定的前台占用优先级向手机操作系统申请前台占用。一般来说呼叫处理单元所使用的优先级是开发人员预定的，该优先级通常较高，在一种优选的方式中，呼叫处理单元按照仅仅低于电话应用的优先级向系统申请前台占用，其使用的优先级不低于其他应用的前台占用优先级。由于此时呼叫处理单元所使用的优先级很高，除非用户正在使用电话应用在通话中，否则呼叫处理单元请求前台占用的申请将被操作系统所允许。对于不支持移动通话通信功能的便携终端，比如Pad类的便携终端来说，所述预定的前台占用优先级可设定为最高的前台占用优先级。

在前台占用成功的情况下，呼叫处理单元在前台提供一个呼叫响应界面供用户来操作。一般来说，呼叫响应界面上提供接受选项和拒绝选项。与此同时，呼叫处理单元还可以通过驱动控制终端输出呼叫提示，呼叫提示可以包括响铃提示以及震动提示等方式。值得注意的是，本发明的呼叫提示与普通即时通信的消息提示的作用以及持续时间长度并不相同。从作用上来说，呼叫提示主要是将被叫用户“拉入”一个群内的实时会话，以便在群内进行持续性的且更接近于面对面效果的会话。从提示的输出极限时间长度上而言，一般来说普通即时通信消息提示的极限持续时长通常比较短，比如收到一个用户留言时，终端的语音提示或者震动提示通常可能仅仅只有数秒钟。而本发明在用户无干预的情况下呼叫提示的极限持续时长大于前者的极限持续时长。比如说，呼叫处理单元收到可以触发普通即时通信消息提示的普通群内消息（也就是非呼叫提示）时，控制用户终端进行语音提示或者震动提示，其提示极限持续时长可能仅仅只有数秒钟。呼叫提示的极限持续时长称为第一指定时长，其长度为数分钟，远大于前者。在优选的方式中，建议开发人员在1-60分钟这一区间内，选择一个时长作为所述第一指定时长。此外，若呼叫请求中携带有附加数据，则呼叫处理的单元在当前界面上播放该附加数据，对于文本类数据进行显示处理，对于多媒体类地址数据，则通过消息中的地址通过网络获取对应的多媒体数据进行播放。

在优选的方式中，根据呼叫请求输出呼叫提示时，若会话管理单元捕获到指定用户操作进行干预则通过驱动控制呼叫提示输出停止，比如说用户点击“Home键”或者“电源键”或者“音量键”或者指定的触摸按钮等操作来干预，这些指定操作可以由开发者自行定义，只要方便用户使用即可。在优选的方式中，呼叫处理单元在控制提供呼叫提示输出时还在界面上提供接受选项与拒绝选项。若用户选中接受选项，则会话管理单元根据该接受操作执行开启群消息界面处理并通过驱动控制呼叫提示输出停止，在前台为用户提供群消息界面。

在群消息界面下，用户可以自由选择通信方式。该群消息界面中可以包括语音聊天与视频聊天选项供用户选择，还可以包括其他手动消息输入栏，所谓手动消息输入栏可以包括文本输入栏位，还可以包括图片、音频、视频或其他文件附加栏位（比如说对讲机这样的功能就可以实现非实时的音频数据的传递）。与语音或视频聊天不同的是，在这些交流方式中，信息的传递其需要用户手动介入。由此可见，本发明通过前台占用的方式来提示群用户，使得群用户非常清晰地知道其有相对重要的群内通信需求。这种设计方式不但融入了电话呼叫的带有强制性处理要求的好处，又融合了即时通信客户端丰富多样的通信手段，避免了电话应用在交流手段上的单一性。在优选的方式中，处于实时会话状态的消息界面的前台占用优先级同样比较高，在优选的方式中该优先级与呼叫处理单元所使用的优先级一致。这样一来，该消息界面不再容易因其他应用占用前台而退入后台。

由于用户进入该消息界面是接受呼叫触发的，此时会话管理单元返回给服务端一个用户状态更新通知，通知服务端自身状态从异步会话状态变更为实时会话状态，而服务端则将该用户更新后的用户状态同步给群内其他用户的客户端，同样的道理，用户客户端的会话管理单元在收到服务器同步其他用户的状态更新消息时，相应将自身群用户列表中对应的用户状态进行更新。考虑到群消息界面可能因为各种原因离开前台，比如用户主动关闭该群消息界面；再比如说，此时用户的智能手机接收到一个电话呼叫，由于电话应用的前台占用优先级最高，因此电话呼叫会占用前台导致用户的群消息界面退入后台运行。在处于实时会话状态用户的群消息界面离开前台时，所述会话管理单元通知服务端自身状态从异步会话状态变更为实时会话状态。而其他客户端的会话管理单元在根据服务端同步过来的用户状态更新通知，相应将自身群用户列表中对应的用户状态进行更新。通过状态更新的同步机制，用户群内的每个用户可以知晓哪些用户是在实时会话状态，哪些用户是异步会话状态，哪些用户是离线状态。

若用户选中拒绝选项，则会话管理单元根据该拒绝操作通过驱动控制呼叫提示输出停止，并将之前的用户界面恢复。当然如果一直不选择，则呼叫处理单元通过驱动控制呼叫提示持续输出。如前所述，本发明的呼叫请求所触发的呼叫提示持续时间通常也有一定的限制，在收到呼叫请求时，呼叫处理单元启动第一定时器，该第一定时器的定时时长就是前述第一指定时长，在第一定时器超时的时候，呼叫处理单元通过驱动控制呼叫提示输出停止。在一些灵活的实施方式中，客户端可能允许用户指定一种或多种呼叫提示的输出，此时呼叫提示的输出将是用户允许的输出方式。当然用户也可能配置为完全不允许任何呼叫提示输出，比如用户设定了静音且不允许震动输出，此时呼叫提示将被禁止。当然在一些特殊的场景中，开发者可能不允许用户对呼叫提示的输出进行配置，此时相当于呼叫提示被默认允许了。

从以上的描述中可以看出，本发明实现了用户群中特定权限的用户对用户群中其他所有用户进行呼叫请求，以及群内用户召唤以及紧急事项通知的目标。用户若不进行操作干预，则用户终端会长时间持续输出呼叫提示，提示效果强烈。值得注意的是，由于这样的群体呼叫请求只能由群主这类有群呼权限的少数用户发起，群主这类少数用户通常在有相对重要的事项需要召集群内成员进行交流才会启动群呼功能，因此本发明可以在实现有效群体交流的同时，避免允许任意成员之间随意呼叫请求可能引发给用户带来困扰的问题，因为一个用户群中很多成员用户之间并不是熟人关系。

举例而言，假设一个兴趣主题是K歌的QQ群，群主若希望组织所有时间方便的成员在两个小时后到指定地点进行K歌活动，在传统方式中，群主只能在群内留言实现活动的通知。由于时间比较仓卒，部分用户可能因为对群发言进行不提示设置的原因无法接收到这一重要通知，而部分用户虽然对群内发言没有进行不提示设置，但由于群内发言量可能比较大，稍不留意就可能错过了这一重要的通知，或者需要不断地往回查找才能得到确切的消息。使用本发明之后，群主只需要在客户端界面上发送群呼请求，并输入K歌活动的详情即可实现召唤群内所有用户参加指定活动的目标。再比如说，假设群主是公司某个部门的总监，而群内其他成员是其下属的项目经理。该总监可以在其智能手机上使用本发明的客户端，通过群呼的方式召集所有项目经理，比如通告所有项目经理在指定时间指定地点集合开会，或者要求所有项目经理在指定时间立刻上报项目进展报告等等。这样一来该总监无需逐个电话通知，而且如果呼叫请求都无法召唤到该项目经理，只能说明该项目经理没有将手机随身携带，此时即便打电话也无济于事。

在相反的通信方向，本发明继续为用户提供便利。在用户群的交流中，除了群主通过群呼的方式来召唤其他用户之外，事实上还存在着其他用户召唤群主的需求。在一个公司内部的用户群应用中，普通群成员用户只需要拨打群主电话即可，比如说项目经理因紧急事项拨打总监的电话即可实现对群主的召唤。但是在社交类的用户群中，这一点往往是难以实现的。在很多社交类用户群（比如QQ群）中，各个用户之间往往并不知晓对方的电话号码等比较私密的联系方式，或者只有极少数的人知道群主的电话。若当前有紧急事项需要召唤群主，比如说需要群主维持讨论秩序避免讨论偏离主题，现有技术只能靠留言之类的方式来实现。留言的方式往往无法实现满足紧急事项在时间上的紧迫性要求。

请继续参考图2，假设此时群内在线用户因某紧急事项需要召唤群主进行处理，而群主当前并没有参与在线讨论，此时群内的在线用户可在自身客户端的群消息界面中选中“呼叫群主”这一单呼选项，此时客户端的呼叫发起单元向服务端发送单呼请求。如果用户在界面上添加了附加数据，则将该附加数据一并携带在单呼请求中发送给服务端，对于非核心用户而言，优选的方式中，建议附加输入栏仅允许输入文本类数据。这种方式的好处在于，如果大量用户都发送多媒体数据，那么群主有可能在后续收到大量多媒体数据，对群主所使用的终端来说下载和处理数据的压力较大。

请参考图5，服务端一侧收到单呼请求后，单呼处理单元获得该消息中携带的群ID，在该群的单呼请求列表中记录下本次请求。在优选的方式中，单呼处理单元记录本次单呼请求的接收时间以及发送者的用户ID。在记录之后，单呼处理单元继续判断该群的单呼请求列表是否已经满足预定条件，如果满足预定条件，则向群主发送呼叫请求。群主的客户端收到该呼叫请求之后则会根据呼叫请求持续输出呼叫提示，具体过程可以参考图3流程以及之前的相关描述。此外，如果单呼请求中有附加数据，则将对应的附加数据汇总之后添加在呼叫请求中。

上述方式中，单呼处理单元所采用的预定条件可以有多种变化，预定条件可以是第二指定时长内指定数量（大于或等于2）的用户发送了单呼请求，举例来说，此时该预定条件可以是1分钟内收到至少5个用户发送的单呼请求。请参考表1的单呼请求列表示例，在服务端收到用户E的单呼请求之后，此时群内已经有5个用户发送的单呼请求，但是1分钟内只有4个用户发送过，因此不满足预定条件，此时再次收到用户D在19：00：15第二次发送的单呼请求，条件还是不满足，因为此时消息数量虽然是5个，但是发送者还是4个。在收到用户F发送的单呼请求后，上述预定条件就得到了满足。

表1

再比如说，预定条件可以是指定时间内指定数量（M个）用户发送了指定数量（N个）单呼请求，M和N均大于等于2，一般来说N大于M。举例来说，此时该预定条件可以是1分钟内收到至少5个用户发送的至少8个单呼请求。请参考表1的示例，在服务端收到用户G的单呼请求时，该预定条件就满足了。上述的预定条件可以由开发者根据实际需要进行设定，其主要目标是让呼叫请求召唤群主这一行为变得合理，比如说限定时间区间，比如说凌晨时段的呼叫请求为无效，再比如说限定特定等级用户发送的呼叫请求有效等等。此外，在优选的方式中，单呼处理单元在接收到单呼请求时可相应启动第二定时器，并在该第二定时器超时时，从所述单呼请求列表中删除对应的单呼请求记录，其中该第二定时器的定时时长为第二指定时长。这样的处理方式可以及时删除掉一些已经不作为判断依据表项。

在优选的方式中，考虑到很多用户持续发送单呼请求会触发服务端产生多个呼叫请求，此时单呼处理单元发送呼叫请求前，先判断距离上次向群主发送呼叫请求的时长是否达到第三指定时长，如果是，则发送该呼叫请求，否则抑制本次呼叫请求的发送。一般来说，该第三指定时长可以与第一指定时长相同，或者略大于该第一指定时长。这是考虑到如果群主已经接收到一个呼叫请求，并且其终端的呼叫提示还在持续，则没有必要继续向其发送雷同的呼叫请求了。群主的客户端收到该呼叫请求之后，其上的呼叫处理单元按照同样的方式进行处理，具体过程不再详述。

上述实施方式中，呼叫请求是针对群主这个上行核心用户的，在一些更为灵活的实现方式中，呼叫请求可以针对其他上行核心用户。在一种灵活的设计方式中，上行核心用户也可以由用户选择，比如用户选择群主或者副群主，甚至选择任意群主指定的可以被呼叫请求的用户。此时呼叫发起单元在界面上除了需要提供单呼选项允许用户发送单呼请求之外，还需要提供对象选择栏位，供用户选择请求单呼的对象。此时表1可以变化为表2的示例。

表2

由此可见，本发明在群体即时通信交流过程中针对紧急或重要事项实现了强烈提示效果，而双向呼叫请求的触发机制又是不对称的。在下行方向允许少数用户向多数用户发送提示效果相对于普通消息提示更为强烈的呼叫提示，而在上行方向，则允许多数用户通过集体行为面向少数用户发送提示效果强烈的呼叫提示。本发明充分利用了群通信的客观特点，在两个方向上使用不同呼叫提示触发方式，能够充分控制呼叫提示的合理使用，避免呼叫提示的滥用引发用户体验糟糕的问题。

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明保护的范围之内。

Claims (14)

1.一种即时通信客户端，应用于便携式用户终端上，与服务端配合使用，该客户端包括：会话管理单元、呼叫发起单元以及呼叫处理单元，其特征在于：

会话管理单元，用于为用户开启群消息界面，针对下行核心用户在该群消息界面上提供群呼选项，针对非核心用户在该群消息界面上提供单呼选项；

呼叫发起单元，用于在用户选中群呼选项时，向服务端发送针对群内所有其他用户的群呼请求，该群呼请求中携带有用户所属用户群标识以及群呼标识；当用户选中单呼选项，向所述服务端发送针对被叫用户的单呼请求；

呼叫处理单元，用于在接收到服务端发送的呼叫请求时按照预定的前台占用优先级向操作系统请求前台占用；并在请求前台占用成功的情况下，在用户终端屏幕上输出至少部分覆盖当前用户界面的呼叫响应界面，并在呼叫提示被允许的情况下控制该用户终端输出一种或多种呼叫提示，其中该呼叫响应界面包括接受选项以及拒绝选项。

2.如权利要求1所述的客户端，其特征在于：

所述呼叫发起单元进一步用于针对下行核心用户在群消息界面上提供附加输入栏，并将用户通过该附加输入栏输入的附加数据添加在所述群呼请求中；

所述呼叫处理单元进一步用于获取呼叫请求中的附加数据，并在终端屏幕上播放该附加数据。

3.如权利要求2所述的客户端，其特征在于：所述附加输入栏包括文本附加输入栏以及多媒体附加输入栏，所述附加数据包括文本类数据以及多媒体类地址数据，其中所述呼叫发起单元进一步用于在用户通过附加输入栏附加多媒体文件时，向上传服务端上传该多媒体文件并获取该上传服务端返回的多媒体类地址数据；

所述呼叫处理单元进一步用于根据多媒体类地址数据从网络上获取多媒体数据进行播放。

4.如权利要求1所述的客户端，其特征在于：所述呼叫发起单元进一步用于针对非核心用户在群消息界面上提供文本附加输入栏，并将用户通过文本附加输入栏输入的文本类附加数据添加在所述单呼请求中；

所述呼叫处理单元进一步用于获取呼叫请求中的附加数据，并在终端屏幕上播放该附加数据。

5.如权利要求1所述的客户端，其特征在于：

所述会话管理单元进一步用于在接收到用户选中接受选项操作时，停止呼叫提示输出，并在该用户的群消息界面未开启的情况下，为该用户开启群消息界面；在接收到用户选中拒绝选项操作时，停止呼叫提示输出并将之前的用户界面恢复。

6.如权利要求1所述的客户端，其特征在于：所述呼叫处理单元进一步用于在接收到呼叫请求时启动第一定时器，其中该第一定时器的定时时长为所述第一指定时长，并在该第一定时器超时时停止呼叫提示输出。

7.如权利要求5所述的客户端，其特征在于：所述群消息界面至少包括手动消息输入栏。

8.如权利要求1所述的客户端，其特征在于：所述会话管理单元进一步用于：

在接收到用户选中接受选项操作时，通知服务端自身状态从异步会话状态变更为实时会话状态；

在群消息界面离开前台时，通知服务端自身状态从实时会话状态变更为异步会话状态；

在接收到服务同步的用户状态更新通知时，将群内用户列表中对应用户的状态进行相应的更新。

9.一种即时通信服务端，应用于即时通信服务提供商的服务器上，与即时通信用户使用的客户端配合使用，该服务端包括：群呼处理单元以及单呼处理单元，其特征在于：

群呼处理单元，用于在接收到下行核心用户发送的群呼请求时，获取该消息中携带的用户群标识，向该用户群内的其他在线用户发送呼叫请求；

单呼处理单元，用于在接收到针对上行核心用户的单呼请求时，获取该消息中携带的用户群标识；在该用户群的单呼请求列表中记录本次单呼请求，判断当前单呼请求列表是否满足预定条件，若满足，则向该上行核心用户发送呼叫请求，清空该用户群的单呼请求列表。

10.如权利要求9所述的服务端，其特征在于：所述群呼处理单元进一步用于获取群呼请求中携带的附加数据，并将该附加数据添加到所述呼叫请求中。

11.如权利要求10所述的服务端，其特征在于：当所述附加数据为多媒体类地址数据时，所述群呼处理单元进一步用于向内容分发网络CDN系统发送针对该地址对应的多媒体数据的同步请求。

12.如权利要求9所述的服务端，其特征在于：所述记录本次单呼请求具体包括记录本次单呼请求的接收时间以及发送者的用户ID，所述预定条件具体为：第二指定时长内接收到N个用户发送的单呼请求，其中N为大于或等于2的自然数；所述单呼处理单元进一步用于在接收到单呼请求时启动第二定时器，并在该第二定时器超时时，从所述单呼请求列表中删除对应的单呼请求记录，其中该第二定时器的定时时长为第二指定时长。

13.如权利要求9所述的服务端，其特征在于：所述单呼处理单元进一步用于在向该上行核心用户发送呼叫请求前，先判断距离上次向该上行核心用户发送呼叫请求的时长是否达到第三指定时长，如果是，则发送该呼叫请求，否则抑制本次呼叫请求的发送。

14.如权利要求9所述的服务端，其特征在于：所述单呼处理单元进一步用于获取单呼请求中携带的文本类数据并记录于该用户群的单呼请求列表中，在发送呼叫请求时将单呼请求列表中来自多个用户的附加数据汇总后添加到该呼叫请求中。

Images