CN103888600B - 一种即时通信客户端 - Google Patents

Abstract

本发明提供一种即时通信客户端，该客户端包括：呼叫发起单元，在用户下达的呼叫指令时，以该用户作为主叫用户针对被叫用户发起呼叫请求；呼叫处理单元，在接收到呼叫请求时按照预定的前台占用优先级向操作系统请求前台占用；在用户终端屏幕上输出至少部分覆盖当前用户界面的呼叫响应界面，并输出一种或多种呼叫提示，其中该呼叫响应界包括接受选项以及拒绝选项；会话管理单元，在用户选中接受选项时，停止呼叫提示输出，向被叫用户返回呼叫接受，开启消息界面，并在该消息界面上标注出实时会话状态，其中该消息界面至少包括手动消息输入栏。相较于现有技术，本发明使得用户体验到更加接近面对面沟通效果的会话方式。

Description

一种即时通信客户端

技术领域

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

背景技术

在互联网技术进入普通民众生活之后，即时通信技术给民众带来了各种工作与生活的便利。从早期的ICQ以及OICQ（今日广泛使用的QQ）到如今更新一代的基于移动终端的微信以及来往等，即时通信技术正在不断地向着更加便利用户的方向演进。即时通信技术在不断地与其他技术融合，比如说，如今人们已经可以使用手机QQ进行语音或者视频通话，可以使用手机QQ将刚刚拍摄到的图片发送给好友。然而即时通信技术的数十年的演进过程中，对于一些用户事实上非常关注的对话需求，却被广大开发者所忽视，一些天然合理的通信需求甚至被广泛性地遗忘。

发明内容

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

呼叫发起单元，用于在收到用户下达的呼叫指令时，以该用户作为主叫用户针对该呼叫指令所指定的被叫用户向该被叫用户发起呼叫请求；

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

会话管理单元，用于在用户选中接受选项时，停止呼叫提示输出，返回呼叫接受，根据会话属性为用户开启其与主叫用户进行会话的消息界面，并在该消息界面上标注出实时会话状态，其中该消息界面至少包括手动消息输入栏。

相较于现有技术，本发明打破便携终端上使用呼叫的惯性设计思路，允许用户通过呼叫将其他用户带入一个实时会话状态的消息界面上，使得用户体验到更加接近面对面沟通效果的会话方式。

附图说明

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

图2是本发明一种实施方式中的呼叫交互及对应处理过程示意图。

具体实施方式

本发明提供一种新的即时通信客户端。在以下实施方式中，所述客户端以及为该客户端提供的服务端是一种计算机软件实现的虚拟装置，分别运行于便携式用户终端（以下以智能手机为例进行说明）以及即时通信服务提供商的服务器上。当然本发明并不排除其他诸如逻辑器件或者硬件等实现方式。在此仅以最为流行的软件实现为例进行示例性说明。

请参考图1，从逻辑功能层面上讲，该客户端包括呼叫发起单元、呼叫处理单元以及会话管理单元。用户在智能手机上安装好客户端之后，其可以进行注册成为注册用户后上线。在用户登录过程中，客户端获取用户输入的身份认证信息（比如用户名与密码）发送给服务端，服务端对该身份认证信息进行验证，若通过则允许用户上线，并返回包括好友列表在内的该用户的各种属性信息。这部分的处理与实现可以参考现有技术，本发明在此不再一一详述。请参考图2，客户端在运行过程中执行如下处理过程。

步骤101，呼叫发起单元在收到用户下达的呼叫指令时，以该用户作为主叫用户针对该呼叫指令所指定的被叫用户向该被叫用户发起呼叫请求；

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

步骤103，会话管理单元在用户选中接受选项时，停止呼叫提示输出，返回呼叫接受，根据会话属性为用户开启其与主叫用户进行会话的消息界面，并在该消息界面上标注出实时会话状态，其中该消息界面至少包括手动消息输入栏。

在传统的即时通信技术中，用户若在智能手机的即时通信客户端上与其他用户（仅以用户的好友为例）进行持续性的交流，比如持续地进行图片分享和问题讨论，则该用户可以选择通过消息页面留言的方式来通知对方。此时用户只能被动等待好友的回应。若好友长时间无回应，比如未有听到消息提示，则该用户可能需要通过电话的方式来通知对方进入消息界面与自己进行交流。这种方式无疑给用户带来了不便利，而且如果用户没有社交好友的电话号码或者无法通过其他渠道获取，那么遇到紧急的事项只能等待。

请参考图2，当用户A因某种交互需求希望与某个好友（用户B）持续性地进行交流，就好像两个人在面对面交谈那样，此时用户A可以作为主叫用户通过自身的客户端向用户B发送呼叫请求。呼叫请求的发起方式有很多中，用户A可以在各种有呼叫选项的用户界面中来发起呼叫请求，比如在客户端的好友列表中通过右键菜单的方式向用户B发送呼叫请求，也可以选中好友打开消息界面中，在该界面发起该呼叫请求。在更为便利的方式中，若用户A的智能手机支持语音操作，用户A还可以通过语音指令的方式来发起呼叫。

请参考图2，在一种优选的方式中，用户A发起的呼叫请求事实上是一个消息，其可以向普通消息那样发送给服务端，而服务端同样可以将该呼叫请求作为一个普通消息那样转发给用户B。在这种实施方式中，不要求服务端在控制层面做出改进，只需要定义一种特别的消息类型即可，比如在消息类型字段中用“00000111”表征该消息为呼叫请求。这一消息类型需要好友的客户端进行特别处理，而服务端只需要进行转发即可。当然本发明并不排除其他的实现方式，比如说服务端需要介入进行处理，这里描述的只是一个更加简洁的实现。

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

在前台占用成功的情况下，呼叫处理单元在前台提供一个呼叫响应页面供用户B来操作，请参考图2中最右侧的界面示例。一般来说，呼叫响应页面上提供接受选项和拒绝选项。与此同时，呼叫处理单元同时还可以输出呼叫提示，呼叫提示可以包括响铃提示以及震动提示等方式。值得注意的是，这里的呼叫提示与普通即时通信的消息提示的作用以及长度都不同。从作用上来说，呼叫提示主要是将被叫用户“拉入”一个实时会话，以便进行持续性的且更接近与面对面效果的会话。从提示的输出的极限长度上而言，一般来说普通即时通信消息提示的极限持续时长通常比较短，比如收到一个用户留言时，终端的语音提示或者震动提示通常可能仅仅只有数秒钟。而本发明呼叫提示的极限持续时长，其长度可能为数分钟，远大于前者。在一种优选的方式中，该呼叫提示的输出时间大于或者等于电话呼叫提示的极限持续时间。也就是说，如果用户B不处理该呼叫，那么呼叫提示将长时间地持续输出。

在具体实现上，当呼叫请求到达时，呼叫处理单元一方面提供呼叫响应页面和输出呼叫提示，与此同时，呼叫处理单元还可以启动一个定时器，在定时器超时的时候停止输出和呼叫提示。此时定时器的定时时长就是呼叫提示的极限持续时间。建议开发人员在1-60分钟这一区间进行选择一个时长作为所述定时时长，当然开发人员还可以根据应用场景的变化为不同应用场景设定不同定时时长的定时器。在一些灵活的实施方式中，客户端可能允许用户指定一种或多种呼叫提示的输出，此时呼叫提示的输出将是用户允许的输出方式。当然用户也可能配置为完全不允许任何呼叫提示输出，比如用户设定了静音且不允许震动输出，此时呼叫提示将被禁止。当然在一些特殊的场景中，开发者可能不允许用户对呼叫提示的输出进行配置，此时相当于呼叫提示被默认允许了。

以触摸屏的智能手机为例，一旦用户在屏幕上选中了接受选项，比如通过滑动操作来选中。此时会话管理单元接收到该用户的选中接受选项操作，在前台为用户提供消息界面。这一消息界面的实体功能可以参考各种即时通信客户端的消息界面来设计，但是在状态上却有差异。由于进入该消息界面是接受呼叫触发的，此时会话管理单元在该消息界面上的状态栏中将状态设定为实时会话状态。处于实时会话状态的消息界面的前台占用优先级同样比较高，在优选的方式中该优先级与呼叫处理单元所使用的优先级一致。这样一来，该消息界面不再容易因其他应用占用前台而退入后台。

值得注意的是，用户B客户端为用户提供消息界面的方式可以根据当前用户的使用情况作出区分。用户B的客户端如在后台运行中，在后台运行的过程中，客户端通常只有少量的功能在运行，此时会话管理单元在用户选中接受选项时，将首先唤醒客户端各个功能单元，然后根据各种会话属性来生成消息界面，会话的属性有很多种，比如会话中的对方用户昵称、ID、当前签名、会话类型（群会话还是点对点会话）等等。如果用户B的客户端已经在前台运行，则接受呼叫后进入与A用户对话的消息界面。在一种非常特殊的情况中，用户B可能正在与用户A进行异步会话，也就是按照传统的方式进行即时通信交流，此时B用户在收到并接受呼叫后再次回到与A用户对话的消息界面，状态变更为实时会话状态。

从兼容性角度考虑，当用户通过非呼叫接受方式下发消息界面开启指令时，比如用户B在好友列表中双击用户A的图标，此时会话管理单元同样会为用户开启消息界面，不同的是，会话管理单元此时在消息界面的状态栏中将状态置为异步会话状态。请参考图2中中间界面的示例。图2中状态的文字描述并不是必须的，完全可以只通过一些图标来表达，比如黑色实心圆表示实时会话状态，而空心圆表示异步会话状态。

在另一方面，用户B客户端的会话管理单元还可以向服务端返回呼叫接受，经由服务端发送给主叫用户A。用户A客户端的会话管理单元接受到该呼叫接受之后，同样将主叫用户与被叫用户进行会话的消息界面提供给主叫用户，并在消息界面上的状态栏中将状态设定为实时会话状态。此时，由于主叫与被叫用户使用的消息界面都标注了实时会话状态，因此主叫用户与被叫用户都清楚地知道对方的消息界面在前台，随时可以通过消息界面上的各种通信功能与本方进行各种方式的交流。

值得注意的是，本发明与普通的QQ语音或视频这类的VOIP级的应用有本质的区别，虽然这些应用也有呼叫，但是这些呼叫被接受之后，应用进入了特定的语音视频通话状态，这种实现方式相当于在语音聊天等应用中沿用了电话设计，是本领域普通技术人员一种惯性的技术思维。但事实上，本发明则并不因为呼叫立刻进入音视频交互状态。在本发明中，客户端的呼叫是触发一个实时会话状态消息界面在两方开启。在这个消息界面下，两侧的用户可以自由选择通信方式。该消息界面中可以包括语音聊天与视频聊天选项供用户选择，还可以包括其他手动消息输入栏为，所谓手动消息输入栏可以包括文本输入栏位，还可以包括图片、音频、视频或其他文件附加栏位（比如说对讲机这样的功能就可以实现非实时的音频数据的传递）。与语音或视频聊天不同的是，在这些交流方式中，信息的传递其需要用户手动介入。

为了允许用户获得更好的使用体验，本发明还可以对呼叫占线以及实时会话退出进行相应处理。当一个用户的消息界面正处于实时会话状态时，若通过服务端接收到源自其他用户（比如用户C）的另一呼叫请求时，呼叫处理单元保持实时会话状态的消息界面的前台占用，并针对该另一呼叫请求在指定消息栏输出消息提示。这里呼叫处理单元的特殊处理可以很好地保障实时会话状态的消息界面不会被打扰。在具体实现上，呼叫处理单元可以先判断当前消息界面是否为实时会话状态，如果是，则其不再需要申请前台占用，可以仅仅在指定的提示栏上输出对应的提示即可，此时呼叫处理单元也不需要输出呼叫提示和启动定时器了。这样既可以保障用户在当前消息界面上的交流不被打断，也可以提示用户有另外一个呼叫进入。

考虑到消息界面可能因为各种原因离开前台，比如用户主动关闭该消息界面；再比如说，此时用户的智能手机接收到一个电话呼叫，由于电话应用的前台占用优先级最高，因此电话呼叫会占用前台导致用户的消息页面退入后台运行。在处于实时会话状态的消息界面离开前台时，会话管理单元所述会话管理单元向服务端发送会话退出。而对端客户端的会话管理单元在在通过服务端接收到会话退出时，将消息界面上的实时会话状态修改为异步会话状态。从对端的角度来看，其消息界面还在前台，并不因为另一端的消息界面离开前台而离开前台，但是其会很快知晓状态已经不再是实时会话状态，此时消息界面转入到异步会话状态。

通过以上的描述可以看出，本发明允许用户通过呼叫的方式将一个被叫用户带入一个实时会话状态的消息中，通过消息界面的状态标识，使得用户清晰地知道双方的在一种接近于面对面会话效果的状态。在实现处理上，本发明通过前台占用的方式来提示用户，使得用户非常清晰地知道其有相对重要的通信需求。这种设计方式不但融入了电话呼叫的带有强制性处理要求的好处，又融合了即时通信客户端丰富多样的通信手段，避免了电话应用在交流手段上的单一性。举例来说，一个客户需要供应商立刻汇报工作进展时，由于事件的复杂性，电话可能无法讲清楚，需要文字以及图片配合讲解，而且随时可能配合语音讲解，此时使用本发明双方进入实时会话状态的消息页面后，双方都知道对方在与自己进行实时对话。而传统的即时通信方式中，仅仅能通过“正在输入”这样的提示来表征，仅仅适用于文本，而且对方没有输入的时候，本方并不清楚对方到底是不是仍然在处理与自身的对话。由此可见，本发明的实施应用可以给使用即时通信客户端的双方带来更加接近面对面交流的效果，避免了传统即时通信工具用户使用体验上的问题。值得注意的是，以上实施方式中客户端通过服务端与其他客户端之间进行交互，但在一些特殊的实现方式中，用户A与用户B之间的消息有一些可以经过服务端转发，有一些也可以不经过服务端，因此本发明呼叫过程中的各种消息（比如呼叫请求、呼叫接收、会话退出等）也可以不经过服务端转发，由两个客户端直接进行交互，当然这种实现需要考虑网络通信可达性问题，如NAT（网络地址转换）穿越或者说NAT打洞。

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

Claims (9)

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

呼叫发起单元，用于在收到用户下达的呼叫指令时，以该用户作为主叫用户针对该呼叫指令所指定的被叫用户向该被叫用户发起呼叫请求；

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

会话管理单元，用于在用户选中接受选项时，停止呼叫提示输出，返回呼叫接受，根据会话属性为用户开启其与主叫用户进行会话的消息界面，并在该消息界面上标注出实时会话状态，其中该消息界面至少包括手动消息输入栏；

所述会话管理单元，进一步用于在用户通过非呼叫接受方式下发消息界面开启指令时，根据会话属性为用户开启消息界面，并在该消息界面上标注出异步会话状态；

所述会话管理单元进一步用于在收到源自被叫用户的呼叫接受时，为用户开启其与被叫用户进行会话的消息页面，并在该消息界面上标注出实时会话状态，其中该消息界面至少包括手动消息输入栏；

所述会话管理单元进一步用于在用户通过操作退出当前位于前台处于实时会话状态的消息界面时，返回会话退出；并用于在接收到会话退出时，将消息界面上的实时会话状态修改为异步会话状态。

2.如权利要求1所述的客户端，其特征在于：处于实时会话状态的消息界面的前台占用优先级为所述预定的前台占用优先级。

3.如权利要求1所述的客户端，其特征在于：当所述用户终端为手机时，所述预定的前台占用优先级小于便携终端中电话应用的前台占用优先级，且不小于其他应用的前台占用优先级。

4.如权利要求1所述的客户端，其特征在于：当所述用户终端不具有移动语音通信功能时，所述预定的前台占用优先级为最高的前台占用优先级。

5.如权利要求1所述的客户端，其特征在于，所述呼叫处理单元进一步用于在为输出的呼叫提示启动定时器，并在定时器超时时，停止输出呼叫提示；其中该定时器的定时时长大于消息提示的极限持续时长，且所述定时时长不小于电话应用呼叫提示的极限持续时长。

6.如权利要求1所述的客户端，其特征在于，所述手动消息输入栏包括多种不同数据类型的输入栏。

7.如权利要求1所述的客户端，其特征在于：所述消息界面中还包括音频或视频聊天选项。

8.如权利要求1所述的客户端，其特征在于：所属会话管理单元进一步用于在用户选中接受选项且客户端在后台运行时，将首先执行唤醒操作，然后根据会话属性为用户开启其与主叫用户进行会话的消息界面。

9.如权利要求1所述的客户端，其特征在于：所述客户端通过服务端与其他客户端之间进行交互。