CN107979520A - 消息处理方法及消息处理装置 - Google Patents

Abstract

本发明公开了一种消息处理方法及消息处理装置；方法包括：为用户分配用于与业务方进行即时通信的全局标识；获取用户经由互联网媒体发送至业务方的用户消息；转换用户消息为适配业务方的消息协议的即时通信消息；发送携带有全局标识的即时通信消息至所述业务方；基于来自业务方的即时通信消息携带的全局标识，确定即时通信消息的目标用户，并转换来自业务方的即时通信消息为适配在互联网媒体中传输的用户消息；将转换得到的用户消息经由互联网媒体发送至目标用户。实施本发明，能够以通用化的方案实现不同通信方式的用户与业务方之间的上行/下行消息的对接，避免业务方的业务处理系统拓扑复杂化。

Description

消息处理方法及消息处理装置

技术领域

本发明涉及通信技术，尤其涉及一种消息处理方法及消息处理装置。

背景技术

目前，提供产品(或者服务)的业务方普遍通过网页、公众平台公众号等各种形式的互联网媒体向用户提供针对产品(或者服务)的客服业务(例如售前咨询、售后技术支持等)和订购业务。用户使用相应的客户端(如浏览器客户端、公众平台客户端)向客服了解、咨询相关信息并可以根据需求订购产品。

一般地，业务方会在网页上提供用户通过电邮、电话等与客服人员沟通的通信方式，以及在公众平台公众号上提供用户通过公众平台客户端与客服人员沟通的通信方式。

为实现上述客服业务，对于众多的业务方来说，需要分别对接不同通信方式的后台(例如电邮服务器、电话服务器以及公众平台)，并形成会话管理功能，包括：为用户分配客服，为用户与客服建立会话，对用户使用不同通信方式发送的消息根据相应的消息协议进行解析发送到客服，会话的保持和撤销等。

为此，业务方需要在业务方侧开发会话管理功能，导致业务方已有的业务处理系统拓扑复杂化、难以维护。

具体来说，由于业务方已有业务处理功能的无法兼容处理用户消息，因此需要增设额外的服务器承载会话管理功能解析采用不同消息协议的用户消息，并且，需要针对多种通信方式(如公众号、电邮、电话等)进行会话管理，对不同通信方式的用户消息进行解析，这无疑增大了业务方侧的业务处理系统拓扑的复杂程度，影响了系统的健壮性，并且，还需要根据通信方式的变更进行更新，维护困难。

发明内容

本发明实施例提供一种消息处理方法及消息处理装置，能够以通用化的方案实现使用不同通信方式的用户与业务方之间的上行/下行消息的对接，避免业务方的业务处理系统拓扑复杂化。

本发明实施例的技术方案是这样实现的：

第一方面，本发明实施例提供一种消息处理方法，所述方法包括：

为用户分配用于与业务方进行即时通信的全局标识；

获取所述用户经由互联网媒体发送至所述业务方的用户消息；

转换所述用户消息为适配所述业务方的消息协议的即时通信消息；

发送所述携带有所述全局标识的所述即时通信消息至所述业务方；

基于来自所述业务方的即时通信消息携带的全局标识，确定所述即时通信消息的目标用户，并转换来自所述业务方的即时通信消息为适配在所述互联网媒体中传输的用户消息；

将转换得到的用户消息经由所述互联网媒体发送至所述目标用户。

第二方面，本发明实施例提供一种消息处理装置，所述装置包括：

标识单元，用于为用户分配用于与业务方进行即时通信的全局标识；

获取单元，用于获取所述用户经由互联网媒体发送至所述业务方的用户消息；

转换单元，用于转换所述用户消息为适配所述业务方的消息协议的即时通信消息；

通信单元，用于发送所述携带有所述全局标识的所述即时通信消息至所述业务方；

所述转换单元，还用于基于来自所述业务方的即时通信消息携带的全局标识，确定所述即时通信消息的目标用户，并转换来自所述业务方的即时通信消息为适配在所述互联网媒体中传输的用户消息；

所述将转换得到的用户消息经由所述互联网媒体发送至所述目标用户。

第三方面，本发明实施例提供一种消息处理装置，包括处理器和存储器；存储器中存储有可执行指令，用于引起处理器执行包括以下的操作：

为用户分配用于与业务方进行即时通信的全局标识；

获取所述用户经由互联网媒体发送至所述业务方的用户消息；

转换所述用户消息为适配所述业务方的消息协议的即时通信消息；

发送所述携带有所述全局标识的所述即时通信消息至所述业务方；

基于来自所述业务方的即时通信消息携带的全局标识，确定所述即时通信消息的目标用户，并转换来自所述业务方的即时通信消息为适配在所述互联网媒体中传输的用户消息；

将转换得到的用户消息经由所述互联网媒体发送至所述目标用户。

第四方面，本发明实施例提供一种存储介质，存储有可执行指令，用于执行本发明实施例提供的消息处理方法。

本发明实施例具有这样的有益效果：

1)为用户分配的全局标识能够实现区分不同通信方式的用户，从而基于全局标识对用户与业务方之间的上行消息(用户消息)/下行消息(业务方返回的即时通信消息)对接，这样，不管用户通过使用何种通信方式的互联网媒体向业务方发送用户消息，都会被转换为即时通信消息发送至业务方，业务方只需要使用即时通信客户端即可处理响应不同通信方式的用户，不再需要使用不同的客户端，简化了业务方针对用户消息的处理，进而提升业务方与用户之间的沟通效率。

2)对于业务方和用户之间的用户传输即时通信消息的会话来说，只需要使用即时通信的消息协议实现即时通信消息的收发即可，不需要实现其他的会话管理功能，简化了业务方的业务系统的拓扑结构。

3)由于即时通信消息的转换处理与业务方无关，当用户与业务方之间的通信方式发生增加、删除或更新时，业务方也不需要针对通信方式而进行维护工作，实现降低业务方的维护难度的效果。

附图说明

图1是本发明实施例中提供的消息处理方法的一个可选的架构示意图；

图2是本发明实施例中提供的消息处理方法的一个可选的架构示意图；

图3-1是本发明实施例中提供的消息处理方法的一个可选的流程示意图；

图3-2是本发明实施例中提供的消息处理方法的一个可选的流程示意图；

图4是本发明实施例中针对使用不同通信方式的用户与业务方之间进行消息处理的一个可选的架构示意图；

图5-1和图5-2是本发明实施例中用户使用不同通信方式与业务方客服发起通信的示意图；

图6-1是本发明实施例中提供的消息处理方法的一个可选的流程示意图；

图6-2是本发明实施例中进行消息转换处理的一个可选的处理示意图；

图6-3是本发明实施例中对用户与业务方客服之间的上行消息进行处理的示意图；

图6-4是本发明实施例中对用户与业务方客服之间的下行消息进行处理的示意图；

图6-5是本发明实施例中提供的消息处理方法的一个可选的流程示意图；

图6-6是本发明实施例中提供的客服转接的一个可选的处理示意图；

图6-7至图6-9是本发明实施例提供的客服转接的一个可选的场景示意图；

图6-10是本发明实施例中针对多个公众平台的订阅用户进行客服转接的处理示意图；

图6-11是本发明实施例中针对使用电邮、电话与业务方联系的用户进行客服转接的处理示意图；

图7是本发明实施例中消息处理装置10的一个可选的软硬件结构示意图；

图8是本发明实施例中消息处理装置10的一个可选的功能结构示意图。

具体实施方式

以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所提供的实施例仅仅用以解释本发明，并不用于限定本发明。另外，以下所提供的实施例是用于实施本发明的部分实施例，而非提供实施本发明的全部实施例，在不冲突的情况下，本发明实施例记载的技术方案可以任意组合的方式实施。

对本发明进行进一步详细说明之前，对本发明实施例中涉及的名词和术语进行说明，本发明实施例中涉及的名词和术语适用于如下的解释。

1)互联网媒体，互联网中设置的业务方用于宣传产品或者服务的媒体，如网页、公众平台的公众号等。

2)业务方，向用户提供产品或者服务的一方，广义上包括业务方的硬件(如服务器)以及硬件上所运行的各种软件。

3)公众平台，设置于互联网的各种信息的聚合平台，用于供个人、团体等发布各种推广信息。

4)公众号，业务方(如商家)在公众平台上申请的应用账号，公众号的页面内提供基本的信息浏览功能，还提供与业务方的客服实现文字、图片、语音和视频等方式的沟通和互动的功能。

5)订阅用户，公众平台中关注特定公众号的用户，通常也成为公众号的粉丝，公众平台向订阅用户推送所关注公众号的相关信息。

6)通信方式，互联网媒体提供的与用户进行沟通的方式，例如，网页内提供业务方的免费网络电话和电子邮件等联系方式；公众号的页面内提供通过公众平台客户端与客服在线联系的方式。

7)网络(WEB)前端，负责网页在用户侧显示(例如页面布局、特效)以及与用户交互(例如，根据用户操作从后台拉取新的页面数据更新网页)的实体，包括上述基本功能的代码(程序)以及硬件。

8)应用程序接口(API，Application Program Interface)，也称为开发者API或者简称为API，负责接收用户消息的互联网媒体(如公众平台、电子邮件服务器、网络电话服务器)开放的用于进行二次开发的接口，通过调用开发者API可以获取互联网媒体所开放的功能，包括：a)互联网媒体的图形管理界面；b)输出用户向互联网发送的用户消息。例如，用户通过社交客户端向公众号发送消息时，公众平台可以通过开发者API输出用户发送的用户消息。

9)客服，针对业务方的产品或者服务向用户提供咨询的工作人员，这里的工作人员可以为经过产品或者服务的相关信息培训的自然人，也可以为通过人工智能方式实现的、能够针对业务方的产品或者服务提供相关咨询业务的自动应答机器人程序。

10)消息协议，用于指示对用户输入内容的封装格式，在特定的消息封装格式中填充用户在互联网媒体中输入的内容而形成在支持相应消息协议的系统中传输的用户消息。消息协议还指示通信双方支持实现会话控制的指令，如建立会话、会话撤销、会话保持和会话转接的指令。

以用户访问的互联网媒体为公众平台，并实现基于公众平台公众号的客服功能为例进行说明，参见图1示出的本发明实施例提供的公众平台公众号的客服功能的实现架构示意图。在图1中，涉及公众平台、公众平台公众号客服API、业务方WEB前端、业务方的业务后台(服务器)和业务方的即时通信客户端。

公众平台通过提供基于网络的API给业务方，当用户通过访问所订阅的业务方的公众号时，例如浏览所订阅的公众号(此时，业务方的WEB前端是公众号的页面)内发布的产品信息，并通过公众号的页面内公众号的客服发送消息时，业务方的业务后台通过API接收消息，通过建立连接用户-客服的会话，客服的即时通信客户端支持即时通信(IM，InstantMessenger)协议，接收来自用户的即时通信消息，并通过回复即时通信消息的方式向用户提供相关咨询信息。

针对公众平台内每个发送消息的业务后台维护对应的会话，实现用户与客服的沟通，在沟通结束后撤销会话。

上述示例是业务方针对公众平台公众号提供客服功能进行示例性说明，可以理解地，实际应用中，业务方会在多个公众平台如微信公众平台、QQ公众平台注册相应的公众号，同时，还可能发布用于宣传产品(或者服务)的HTML页面，并在页面中提供基于电话号码、电子邮箱、即时通信客户端(如QQ)与客服进行沟通的客服服务。

由于用户使用客服服务时可选择的通信方式多样，为了实现支持全部通信方式的客服功能，业务方需要针对每种通信方式实现类似图1的架构。

以实现针对QQ公众号和微信公众号的客服功能为例，如图2所示，业务提供方的业务后台需要分别对接不同通信方式的后台(例如前述的电邮后台、电话网关以及公众平台)的API以形成会话管理功能，包括为用户分配客服、针对用户建立会话、解析上行/下行消息等。

其中，解析上行/下行消息是指，由于不同公众平台的消息协议与业务方的即时通信客户端的消息协议不一致，因此，业务后台需要对来自不同公众平台的订阅用户的消息(上行消息)进行解析，然后封装为即时通信客户端自身所支持解析的消息并发送至即时通信客户端，同时，对于客服通过即时通信客户端应答的消息(下行消息)需要再次转为公众平台的消息协议可以处理的消息，经由公众平台返回订阅用户。

业务方根据自身的业务特点和需求有各自的业务处理逻辑，为了实现支持不同通信方式的客服功能，还需要针对多种通信方式(如公众号、电邮、电话等)额外设置会话管理功能，这复杂化了业务方的业务处理系统拓扑，影响了系统的健壮性；并且，在业务方调整支持客服的通信方式，如增加、删除或者修改已有的通信方式时，还需要对业务后台的会话管理功能对应进行更新，对于业务方来说难以维护。

针对上述问题，本发明实施例提出一种消息处理方法，以及应用消息处理方法的消息处理装置。参见图3-1示出的消息处理方法的一个可选的流程示意图，包括：

步骤101，为用户分配用于与业务方进行即时通信的全局标识。

步骤102a，获取用户经由互联网媒体发送至业务方的用户消息。

示例性地，可以基于互联网媒体的用于输出用户消息的应用程序接口的信息、以及业务方的用于接收即时通信消息的应用程序接口的信息，在服务后台侧绑定互联网媒体，从而使服务后台获知如何获取用户消息，以及如何将即时通信消息发送到业务方。

下面对互联网媒体的不同类型进行说明：

1)互联网媒体为公众号时，基于与公众平台之间的应用程序接口，获取业务方的公众号的订阅用户发送至业务方的客服的用户消息。

2)互联网媒体为网页，且提供业务方的客服的电邮时，基于与电邮服务器之间的应用程序接口，获取用户发送至业务方的客服的电子邮件。

3)互联网媒体为网页，且提供业务方的客服的免费电话时，基于与电话服务器之间的应用程序接口，获取用户通过呼叫业务方的客服而发送的语音数据。

步骤103a，转换用户消息为适配业务方的消息协议的即时通信消息。

基于互联网媒体使用的消息协议解析用户消息，得到用户在互联网媒体输入的内容，基于业务方使用的消息协议封装内容、以及用户的全局标识形成即时通信消息。

步骤104a，发送携带有全局标识的即时通信消息至业务方。

步骤102b，基于来自业务方的即时通信消息携带的全局标识，确定即时通信消息的目标用户。

步骤103b，转换来自业务方的即时通信消息为适配在互联网媒体中传输的用户消息。

针对互联网媒体的不同类型对步骤102b和步骤103b进行说明。

1)当互联网媒体为公众号时，基于来自业务方的即时通信消息携带的全局标识，映射出目标用户在相应公众平台的标识，转换相应的即时通信消息为适配在相应公众平台中传输的用户消息。

2)互联网媒体为网页，且提供业务方的客服的电邮时，基于来自业务方的即时通信消息携带的全局标识，映射出目标用户的电邮地址，转换返回的即时通信消息为待发送至电邮地址的电子邮件。

3)互联网媒体为网页，且提供业务方的客服的免费电话时，基于来自业务方的即时通信消息携带的全局标识，映射出目标用户的电话号码，转换返回的即时通信消息为适配在相应的电话网络中传输的语音数据。

步骤104b，将转换得到的用户消息经由互联网媒体发送至目标用户。

与图3-1的步骤执行顺序对应地，在步骤101中为所有用户统一分配全局标识(不管用户是否发起与业务方进行通信)，用户与业务方之间的通信可以由用户首先发起，业务方的客服进行应答，相应地，在步骤102b中来自业务方的即时通信消息为业务方的客服针对步骤104a中发送的即时通信消息进行的应答。

另外，图3-1示出的步骤执行顺序还可替换为：步骤102a；步骤101；步骤103a～步骤104a；步骤101；步骤102b～步骤104b。对应这样的场景：用户与业务方的客服之间的通信由业务方的客服首先发起，在步骤102a中获取到用户经由互联网媒体发送至业务方的用户消息时，在步骤101中对用户在互联网媒体中的标识进行映射处理，得到用户与业务方进行即时通信时作为即时通信用户的全局标识，然后通过步骤103a～步骤104a向业务方发送及时通信消息；并通过步骤102b～步骤104b向用户返回业务方客服应答。

另外，如图3-2所示，用户与业务方的客服之间的通信可以由客服首先发起(例如在客服向公众号的订阅用户)，在步骤101中为所有用户统一分配全局标识(不管用户是否与业务方进行通信)，用户与业务方之间的通信可以由用户首先发起，业务方的客服进行应答，相应地，在步骤104b中用户发送的即时通信消息为对步骤104b中业务方发送的即时通信消息的应答。

下文中以用户与业务方的客服之间的通信由用户发起为例进行说明，根据下文可以轻易在用户与业务方之间的通信由业务方客服发起的应用场景。

本发明实施例还提供实施应用上述消息处理方法的消息处理装置。以消息处理装置实施为图4示出的服务后台为例，如图4所示，业务方的互联网媒体(包括公众平台公众号、具有调用电话、电子邮件、即时通信等方式与业务方通信的HTML页面)与业务方之间设置服务后台，服务后台通过调用互联网媒体的API的方式接收用户通过不同方式发送的消息。

例如，如图5-1所示，业务方的微信公众号的订阅用户在公众号的页面内向业务方的客服发送的消息。

又例如，如图5-2所示，业务方的网页的访问用户通过点击客服的即时通信的图标(如QQ联系图标)的方式，通过即时通信客户端向客服发送消息；业务方的网页的访问用户通过点击网页内的客服的免费电话，向客服发起语音呼叫；业务方的网页的访问用户通过点击向业务方的客服电邮发送电子邮件。

服务后台对用户通过不同通信方式向客服发送的消息(上行消息)进行转发，具体来说，通过将用户消息进行转换为符合客户端消息协议的即时通信消息并转发，转换后的即时通信消息可由业务方的即时通信客户端直接进行解析处理。

对于客服在即时通信客户端答复的即时通信消息(下行消息)，服务后台转换为与上行消息的消息封装格式一致的用户消息，并通过API、经由互联网媒体返回用户。

首先，由于业务后台接收到的总是即时通信客户端可以使用自身的消息协议解析的即时通信消息，因此对于业务方的即时通信客户端来说感知到用户总是使用相同的通信方式，对于业务方的业务后台来说，不需要使用公众平台的消息协议对用户消息进行解析，简化了业务方的业务系统的拓扑结构；

其次，由于上行消息和下行消息的转换处理在服后台维护，实现了将复杂的会话管理功能独立(松耦合)于业务方的效果；当业务方的客服服务支持的通信方式发生增加、删除或更新时，在服务后台统一对消息的处理转换逻辑进行更新即可，业务后台自然也不需要针对通信方式而进行维护工作，降低业务方的维护难度。

再次，对于业务方的客服来说，由于总是在即时通信客户端中接收来自用户的即时通信消息，因此客服可以一直使用同一即时通信客户端对用户进行回复，不必针对使用不同通信方式的用户使用对应的客户端进行回复，从而提升客服与用户之间的沟通效率。

以下，首先以服务后台支持在业务方实现基于公众号的客服功能为例进行说明。

参见图6-1示出的消息处理方法的一个可选的流程示意图，包括步骤201至步骤213，下面结合各步骤进行说明。

步骤201，业务方向服务后台提交针对公众号的绑定请求。

在一个实施例中，存在这样的应用场景：业务方希望通过即时通信客户端对订阅用户在公众号页面的发送的用户消息统一进行处理。相应地，业务方登录服务后台的WEB前端，服务后台通过WEB前端向业务方提供绑定请求的提交页面，获取业务针对公众号提交的信息，示例性地，如表1所示：

表1

1)业务方需要绑定的公众号的名称和公众号所属的公众平台。

2)业务方的即时通信客户端接收用户消息的通信接口信息，例如，网际协议(IP，Internet Protocol)地址以及对应的虚拟端口。

可选地，业务方还可以提交以下信息：

3)绑定的有效时间，例如可以永久有效，在设定的日期内有效(如本周内有效)，在设定的时间段内有效(如每天9点至18点有效)等。

4)向业务方即时通信客户端转发用户消息的条件，例如：实时转发用户消息，也就是在通过API获取到用户消息立即转发。又例如，计数转发，通过API获取到预定数量的用户消息时转发。

5)消息协议，业务方的即时通信客户端对即时通信消息的封装格式、以及相关控制指令。

可以理解地，服务后台通过WEB前端支持业务方针对业务方在多个公众平台注册的公众号提交绑定请求，例如支持业务方对在微信平台注册的公众号、以及在QQ公众平台注册的公众号请求绑定。

当然，服务后台支持WEB前端支持业务方针对在同一公众平台注册的多个公众号提交绑定请求，例如，针对业务方在微信公众平台注册的多个公众号请求绑定。

步骤202，服务后台对业务方进行验证，并确定验证成功。

在一个实施例中，服务后台调用公众平台的公众号验证功能验证业务方持有的公众号，例如账号名称+密码验证，注册邮箱验证，注册电话动态口令验证方式的一种或者多种，确定业务方持有的公众号是否合法，避免恶意绑定公众号的情况。

例如，针对首次请求绑定的公众号，使用最高安全级别的验证机制，即采用上述验证方式结合的方式，通过服务后台的WEB前端获取业务方提交的验证信息，调用公众平台的验证功能对业务方提交的验证信息(包括账号名称+密码；动态口令等)进行验证。

再例如，对于非首次请求绑定的公众号，可以采用次高安全级别的验证机制，采用注册电话动态口令的验证方式，向业务方的注册电话下发验证码，并通过服务后台的WEB前端验证业务方提价的验证码是否与下发的验证码一致。

当然，实际应用中不同安全级别所采用的验证方式可可以根据需求灵活选用。

可以理解地，在某些情况下，例如，在业务方与服务后台已经提前形成相互信任的机制时，步骤202为可选执行的步骤。

步骤203，服务后台对公众号验证成功后，针对业务方请求绑定的公众号及进行绑定处理。

在一个实施例中，服务后台通过对公众号执行绑定处理，至少实现如下目的：服务后台获知如何获取公众号的API调用权限以获取用户消息，以及，获知将用户消息进行转换后处理后如何发送到业务方。

相应地，作为执行绑定处理的示例，服务后台存储绑定的公众号的如表1示出的信息，并基于绑定的公众号的如表1示出的相关信息，形成服务后台中对来自公众号的用户消息的处理逻辑：包括：

1)基于绑定的公众号的名称及所属的公众平台，从相应公众平台的API获取来自绑定公众号的订阅用户的用户消息；

2)在将绑定公众号向业务方即时通信客户端转发用户消息的有效时间到达时，从公众平台的API获取来自绑定公众号的订阅用户的用户消息；

3)在符合针对公众号向业务方即时通信客户端转发用户消息的条件时，将来自订阅用户的用户消息转发到业务方的即时通信客户端；

4)根据业务方即时通信客户端的接口信息，将订阅用户的用户消息转发到业务方的即时通信客户端。

当然，服务后台支持业务方通过服务后台的WEB前端对公众号的绑定状态进行修改，例如修改有效时间、转发条件等，或者，取消已绑定的公众号的绑定状态。

步骤204，公众平台接收公众号的订阅用户在公众号页面内发送的用户消息。

在公众号的订阅用户的一个应用场景中，订阅用户通过公众平台的客户端(例如微信客户端、QQ客户端)浏览公众号的页面，在需要与业务方的客服沟通时，在公众号页面的对话框内输入需要咨询的消息(用户消息)，在提交后，用户消息通过公众平台客户端与公众平台之间的通信链路传输到公众平台。

步骤205，服务后台向从公众平台获取所绑定公众号的API的调用权限。

在一个实施例中，服务后台向公众平台请求所绑定的公众号的调用权限，请求中可以携带公众平台对业务方进行验证时所提交的验证信息(如账号名称+密码)，如果公众平台对请求中携带的验证信息验证通过，则响应服务后台的API的调用权限的请求，增加为相应公众号开放API调用权限的记录。

另外，公众平台还可以向服务后台返回成功获取调用权限的确认消息，服务后台通过WEB前端展示公众号绑定成功的确认消息。

可以理解地，如果公众平台针对公众号的API的调用权限对服务后台处于默认开放的状态时，步骤205为可选执行的步骤。

步骤206，服务后台待用公众平台API，获取订阅用户发送至绑定的公众号的用户消息。

在另一个实施例中，为了节省服务后台与公众平台之间的带宽消耗，服务后台通过API向公众平台定期查询公众号的订阅用户的用户消息。

例如，查询的周期根据业务方对用户消息的响应实时性要求确定，当对用户消息的响应时延要求不超过1分钟时，如果用户消息从服务后台到即时通信客户端的处理以及传输时延为5秒，在业务方的即时通信客户端等待的时延为20秒，那么查询的周期不应超出35秒(1分钟-5秒-20秒)。

当然，查询的周期还可以结合业务方的客服的数量、以及每个客服在每个周期能够响应的用户消息的数量综合确定。

步骤207，服务后台针对用户消息的来源订阅用户分配全局标识。

在一个实施例中，服务后台解析用户消息得到订阅用户在公众平台的标识以及订阅用户所属公众平台的标识，基于订阅用户在公众平台的标识、以及订阅用户所在公众平台的标识区分不同的订阅用户，当用户消息的来源订阅未分配有全局标识时，基于订阅用户在公众平台的标识、以及订阅用户所在公众平台的标识区分不同的订阅用户为订阅用户分配不同的全局标识，用于区分向已绑定公众号发送用户消息的订阅用户。

示例性地，当服务后台仅绑定一个公众平台的(一个或多个)公众号时，全局标识可以采用公众号标识+订阅用户标识的形式，当服务后台绑定多个公众平台的公众号时，全局标识可以采用公众平台标识+公众号标识+订阅用户标识的形式。

例如，对于微信平台，假设接收到微信公众号A1的订阅用户U1、以及U2的用户消息，接收到微信公众号A2的订阅用户U3、以及U4的用户消息，那么，可以为订阅用户U1、U2、U3和U4对应映射不同的序列号UIN1、UIN2、UIN3和UIN4作为全局标识，其中，UIN1(A1+U1)、UIN2(A1+U2)、UIN3(A2+U3)和UIN4(A2+U4)为不重复的序列号。

另外，服务后台维护订阅用户所归属的公众平台的标识、订阅用户在公众平台的标识与全局标识之间的映射关系。

步骤208，服务后台将用户消息转换为对应业务方即时通信客户端的即时通信消息。

用户消息是订阅用户通过公众号的页面内输入例如文本、图片或语音等内容，经过公众平台客户端基于公众平台的消息协议而封装为可以在公众平台传输的数据格式。

业务方的即时通信客户端的消息协议往往是第三方开发的私有协议，公众平台的消息协议与业务方的即时通信客户端使用的消息协议存在不可避免的差异，为了得到支持在业务方的即时通信客户端传输的用户消息，服务后台基于公众平台所使用的消息协议解析用户消息得到消息内容(即订阅用户在公众号的页面内输入的内容)，基于即时通信客户端使用的消息协议对消息内容、以及订阅用户的全局标识进行封装，形成支持在业务方的即时通信客户端传输的用户消息。

其中，即时通信消息中携带订阅用户的全局标识用于代表即时通信消息的来源。

可以理解地，在将用户消息转换为即时通信消息时，即时通信消息中还可以携带公众平台中关于订阅用户的属性信息，例如，订阅用户在公众平台的账号、昵称、地区、性别以及偏好等，便于客服了解订阅用户的相关信息，提升沟通效率。

例如，如图6-2所示，假设公众平台传输的用户消息使用JASON(JavaScriptObject Notation)格式封装，则用户消息的数据实际是以JASON字符串的形式传递的；而业务方的即时通信消息使用自有的即时通信消息协议封装，那么，通过解析JASON格式封装的用户消息提取载荷(对应订阅用户输入内容的有效数据)，将载荷填充到即时通信消息的载荷部分中，可以形成被业务方的即时通信客户端直接支持的即时通信消息。

作为服务后台进行用户消息转换处理的示例，如图6-3所示，针对业务方1和业务方2，当服务后台通过公众平台1的API获取到用户1(业务方1的公众号的订阅用户)发送至业务方1的公众号的用户消息1，通过公众平台2的API获取到用户2(业务方2的公众号的订阅用户)发送至业务方2的公众号的用户消息2，基于公众平台1的消息协议进行解析得到用户1输入的内容的数据，基于业务方1的即时通信客户端支持的消息协议1、以及为用户分配的全局标识1进行封装形成即时通信消息1；同理，基于公众平台2的消息协议进行解析得到用户2输入的内容的数据，基于业务方2的即时通信客户端支持的消息协议2、以及为用户2分配的全局标识2进行封装形成即时通信消息2。即时通信消息1和即时通信消息2用于对应发送至业务方1和业务方2的即时通信客户端。

步骤209，服务后台选定响应用户消息的客服，建立订阅用户与所选定客服之间的即时通信会话。

在一个实施例中，服务后台优先选取处于空闲状态的客服，建立订阅用户与选定客服之间的即时通信会话，为订阅用户分配的全局标识作为即时通信会话的标识；当业务方的客服繁忙时选择繁忙程度最低的客服进行排队，当等待排队的客服结束当前即时通信会话时建立客服与订阅用户之间的即时通信会话。

可以理解地，针对建立的即时通信会话，服务后台还执行即时通信会话的保持和结束，例如，在会话空闲未超出预定时间(如1分钟)时保持会话有效，在会话空闲超出预定时间时结束会话。

步骤210，服务后台将即时通信消息通过所建立的会话发送到所选定的客服。

例如，接续上述示例，如图6-3所示，针对用户1选定业务方1空闲的客服1的客户端1，以服务后台与业务方1之间的通信链路为承载，建立用户1与客户端1之间的即时通信会话1；同理，针对用户2选定业务方2空闲的客服1的客户端4，以服务后台与业务方2之间的通信链路为承载，建立用户2与客户端4之间的即时通信会话2。

需要指出的，在即时通信的会话中传输的上行(从订阅用户到客服)消息携带全局标识以区分在服务后台与业务方之间传输的消息所归属的即时通信会话。

步骤211，服务后台接收来自客服的即时通信消息。

步骤212，服务后台将来自客服的即时通信消息转换为对应订阅用户归属的公众平台的用户消息。

可以理解地，步骤210为如图6-2示出的转换处理的逆过程，假设公众平台1传输的用户消息使用JASON(JavaScript Object Notation)格式封装，业务方1的即时通信消息使用自有的即时通信消息协议封装，那么，通过解析即时通信消息的载荷部分可以得到客服2在即时通信客户端2中输入内容(如文本、语音等)的数据，将数据转换为可以在公众平台1传输的JASON格式的字符串(用户消息)。

对于业务方2的客服4通过客户端4回复的就是通信消息2可以参照上述记载而对应处理。

步骤213，服务后台将用户消息通过公众平台API、经由公众平台传输到订阅用户。

在一个实施例中，服务后台通过维护的映射关系(订阅用户所归属的公众平台的标识、订阅用户在公众平台的标识与全局标识之间的映射关系)，以及客服返回的即时通信消息携带的全局标识，确定订阅用户所归属的公众平台的标识，根据订阅用户在公众平台的标识，从而可以经过相应公众平台的API向订阅用户发送用户消息。

作为步骤210和步骤211的示例，接续前述示例，如图6-4所示，服务后台基于业务方1的客服2通过即时通信客户端2回复的即时通信消息3携带的全局标识1，确定即时通信消息的目标订阅用户为归属于公众平台1的用户1，相应地，基于消息协议1解析即时通信消息3携带的载荷(客服2在客户端2中回复的内容如文本、语音的数据)，转换为支持在公众平台1传输的JASON字符串形式的用户消息3，经由API、公众平台1传输到用户1的公众平台客户端呈现。

同理，服务后台基于业务方2通过即时通信客户端3回复的即时通信消息4携带的全局标识2，确定即时通信消息的目标订阅用户为归属于公众平台2的用户2，相应地，基于消息协议2解析即时通信消息4携带的载荷(客服3在客户端3中回复的内容如文本、语音的数据)，转换为支持在公众平台2传输的JASON字符串形式的用户消息4，经由API、公众平台2传输到用户2的公众平台客户端呈现。

可以看出，服务后台基于为订阅用户分配的全局标识维护订阅用户与客服之间的即时通信会话，实现上行/下行消息的透明传输，会话管理功能从业务方剥离在服务后台实现，对于业务方一侧来说订阅用户的通信方式是透明的，业务方不会感知到订阅用户使用何种通信方式(如使用微信公众平台客户端还是QQ公众平台客户端通信，抑或，订阅用户来自哪个公众平台)，只需要实现基于业务方的消息协议对即时通信消息进行收发的处理逻辑：根据既有的消息协议解析消息在客户端呈现，并根据消息协议封装客服输入的内容为即时通信消息发送至服务后台。从而使得业务方的业务处理系统可以专注于自身业务逻辑的实现，降低系统的复杂程度和维护难度。

当业务方的客服对来自订阅用户的用户消息进行应答时，存在需要对会话进行转接的场景，即实现客服的转接，下面结合图6-5进行说明。

参见图6-5示出的消息处理方法的一个可选的流程示意图，包括以下步骤：

步骤214，服务后台接收业务方的客服针对即时通信会话提交的客服转接请求。

在一个实施例中，存在这样的应用场景：业务方的客服希望其他的客服对当前会话中的订阅用户进行回复，相应地，客服在即时通信客户端提交如下信息的客服转接请求：

1)即时通信会话的标识；2)即时通信会话中当前客服的标识；3)即时通信会话待转接的客服的标识。

可以理解地，即时通信会话中待转接的客服的标识为可以省略提交的信息，当转接请求中没有携带待转接客服的标识时，服务后台将根据既有的转接处理逻辑选定客服接入。

示例性地，服务后台随机选择处于空闲状态的客服接入即时通信会话，又或者，选择处于空闲状态、且级别高于当前客服的客服(例如，通过资深客服的记录)接入即时通信会话。

例如，如6-3所示，接续前述示例，对于来自用户1的用户消息1，服务后台通过建立用户1与客服2之间的即时通信会话1，使客服2在即时通信会话2中回复用户1，如果客服2因为各种原因无法回复用户消息1则需要其他客服进行回复，即实现客服的转接，则客服1在即时通信客户端1提交如下信息：当前正在参与即时通信会话1；即时通信会话1中当前的客服为客服1；即时通信会话1待转接的客服为客服2。

步骤215，服务后台执行客服转接处理。

在一个实施例选中，根据业务方客服提交的客服转接请求，服务后台将待执行客户转接处理的即时通信会话撤销，并建立待转接客服与撤销的即时通信会话中的订阅用户之间建立新的即时通信会话，新的即时通信会话中仍然采用为订阅用户分配的全局标识来标识上行/下行消息，在新的即时通信会话中上行/下行消息的传输可以参见前述的记载而实施。

例如，如6-6所示，接续前述图6-3和图6-4，对于来自用户1的用户消息1，服务后台通过建立用户1与客服2之间的即时通信会话1，使客服2在即时通信会话2中回复用户1，如果客服2因为各种原因无法回复用户消息1则需要其他客服进行回复，即实现客服的转接，则客服1在即时通信客户端1提交如下信息：当前正在参与即时通信会话1；即时通信会话1中当前的客服为客服1；即时通信会话1待转接的客服为客服2。服务后台撤销用户1与客服2之间的即时通信会话1，并建立用户1与客服1之间的新的即时通信会话1，新的即时通信会话1中的上行/下行消息仍以用户1的全局标识进行标识，以区分与其他用户参与的即时通信会话中传输的消息。

在客服侧客服转接的一个可选的场景示意图如图6-7至图6-9所示，即时通信会话中的原客服1004通过在转接客服的列表中选择客服1005，将当前接待的客户转接到客服1005。

下面，再结合微信公众平台和QQ公众平台实现跨公众平台的客户转接为例进行说明。

参见图6-10，业务方在QQ公众平台以及微信公众平台分别注册有相应的公众号，业务方期望在通过客户端(支持即时通信协议)统一处理来自不同公众平台的用户消息。

服务后台在本地绑定业务方的QQ公众号和微信公众号，基于绑定的公众号，服务后台获知可以通过调用相应公众平台的开发者API接收来自相应公众号的订阅用户的用户消息(上行消息)，并获知对上行消息转换后基于业务方的接口信息发送到业务方的客户端。

服务后台完成上行/下行消息的会话管理功能，包括对上行/下行消息的转换、以及客服的转接，下面分别进行说明。

一、上行/下行消息的转换、对接

QQ公众号的订阅用户通过公众平台客户端发送的用户消息通过QQ公众平台到达服务后台，同样地，微信公众号的订阅用户通过公众平台客户端发送的用户消息通过微信公众平台到达服务后台，服务后台针对用户消息的不同来源用户的标识OpenID对应映射一个全局标识UIN，建立订阅用户与分配的客户端之间的会话，对于JASON格式的用户消息转换为Hummer消息(适配业务方客户端的消息协议的消息)，并封装带订阅用户的UIN，并发送到业务方的客户端供客服进行响应。

服务后台根据客户端返回的即时通信消息携带的UIN逆向映射出即时通信消息的目标订阅用户处于哪个公众平台、以及在该公众平台的OpenID(在公众平台的标识)。

对于客服来说，来自订阅用户的消息总是以即时通信消息的方式呈现的，因此无法感知到用户来自哪个公众平台、以及用户消息的发送用户消息的方式。

以QQ公众号的订阅用户发送的用户消息的回复为例，服务后台将客服在客户端回复的即时通信消息(Hummer格式，携带订阅用户的全局标识)再次转换为JASON格式的用户消息，并经由QQ公众平台API、QQ公众平台传输到订阅用户的QQ公众平台客户端。

对于微信公众号的订阅用户发送的用户消息的回复与上述处理类似，可以看出，由于在服务后台为不同公众平台的订阅用户分配了全局标识，因此可以针对不同的订阅用户实现上行/下行消息的对接。

二、客户转接

以微信公众号的订阅用户转接客服为例，假设已经建立订阅用户与客户端1之间的会话，客户端1的客服1期望转接到客服端2的客服2，在客户端1提交针对当前会话转接到客服2的转接请求，转接请求通过与服务后台之间的转接命令通道发送到服务后台，服务后台撤销订阅用户与客户端1之间的会话，重新建立订阅用户与客户端2之间的会话，订阅用户可以在新的会话中与客服2沟通。

对于QQ公众号的订阅用户建立的与客户端之间的会话，在需要转接客服时的处理与上述处理类似。

由于在服务后台为不同公众平台的订阅用户分配了全局标识，针对不同订阅用户的会话、以及转接后新会话的上行/下行消息可以基于全局标识实现对接，从而可以实现针对不同公众平台的订阅用户转接客服的效果。

实际应用中，业务方通常会在网页上宣传产品(或者服务)，并在网页上提供电子邮件、免费电话的方式联系客服沟通。下面对服务后台对支持业务方使用即时通信客户端对来自邮件咨询用户、电话咨询用户的用户消息(电子邮件/语音数据)进行统一回复并实现转接的处理进行说明。

参见图6-11，业务方在服务后台本地绑定业务方的电话号码(例如，免费呼叫的网络电话)和电子邮箱，基于绑定的电话号码和电子邮箱，服务后台获知如获取来自用户的语音数据/电子邮件，并获知对语音数据/电子邮件转换为即时通信消息后，如何业发送到业务方的客户端。

例如，业务方登录服务后台的WEB前端，服务后台通过WEB前端向业务方提供绑定请求的提交页面，获取业务针对公众号提交的信息，在服务后台绑定电话号码/电子邮件来说，服务后台获取业务方提交的如下信息：1)业务方的电话号码/电子邮件；2)业务方的即时通信客户端接收用户消息的通信接口信息，例如，IP地址以及对应的虚拟端口。

一、上行/下行消息的转换、对接

对于通过网络电话服务器/电邮服务器的API接收的用户消息(语音数据/电子邮件)，服务后台针对用户消息的来源用户的标识(电话号码/电邮地址)区分不同的用户，为用户对应分配一个唯一的全局标识UIN。在服务后台维护用户的全局标识UIN、用户的电邮地址/电话号码的映射关系。

示例性地，用户的全局标识UIN可以基于来源用户的标识(电话号码/电邮地址)与用户使用的通信方式标识结合的方式映射得到，例如使用通信方式标识(代表电话通信方式或电邮通信方式)+用户标识(电话号码/电邮地址)的方式，当然，其他任意能够标识不同用户的方式均可采用，例如对不同用户顺序分配整数类型的UIN的方式。

接收用户电子邮件时从提取邮件正文，建立用户与客服之间的会话(客服的选取方式可以参见前述的记载)，基于业务方的即时通信客户端使用的消息协议，将邮件正文的数据作为载荷封装为即时通信消息，即时通信消息中还封装有用户的全局标识UIN，用于区分消息的归属用户。

接收用户语音数据时，建立用户与客服之间的会话，基于业务方的即时通信客户端使用的消息协议，将语音数据作为载荷封装为即时通信消息，即时通信消息中还封装有用户的全局标识UIN，用于区分消息的归属用户。

对于接收到即时通信消息的客服来说，用户的电子邮件或语音数据转换为即时通信客户端中的文本消息/语音消息，不会感知到用户使用何种通信方式发起咨询，客服通过即时通信客户端可以统一进行回复，即时通信客户端将客服回复的内容封装为即时通信消息(携带用户的全局标识UIN)发送到服务后台。

服务后台基于即时通信消息携带的UIN逆向映射出即时通信消息归属用户的电邮地址/电话号码，对应将即时通信消息转换为电子邮件/语音数据，通过电邮服务器/网络电话服务器向用户发送。

二、客服转接

以为拨打电话的用户转接客服为例，服务后台已经建立用户与客服1的客户端1之间的会话，如图6-10所示，客户端的客服1期望转接到客服端2的客服2，客服1在客户端1提交针对当前会话转接到客服2的转接请求，转接请求通过与服务后台之间的转接命令通道发送到服务后台，服务后台撤销用户与客户端1之间的会话，重新建立用户与客户端2之间的会话，用户的语音数据后续被转换为即时通信消息发送到客服2的客户端2，客服2通过客户端2发送的即时(语音)通信消息会被转换为语音数据，经由网络电话服务器以语音留言的方式发送到用户，当然，网路电话服务器可以双向连接用户和客服2，建立实时的语音通话，从而可以在新的会话中与客服2沟通。

为发送电子邮件的用户转接客服的处理可以参照上述的处理而实施，由于在服务后台为不同通信方式的用户分配了全局标识，针对不同用户的会话、以及转接后新会话的上行/下行消息可以基于全局标识实现对接，从而可以实现针对不同公众平台的订阅用户转接客服的效果。

在硬件层面上，示例性地，消息处理装置可以基于在拓扑上独立于业务方的业务处理系统的服务器侧的资源如计算资源(如处理器)和通信资源(如网络接口)实现，此时，即时通信服务器作为执行图3-1示出的消息处理方法的实体。

在软件层面上，消息处理装置可以实施为存储于存储介质的可执行指令，包括诸如程序、模块之类的计算机可执行指令，存储介质可以设置与即时通信服务器，或者，分布设置在多个服务器中。

如上，参见图7示出的消息处理装置10的一个可选的软硬件结构示意图，消息处理装置10包括硬件层、中间层、操作系统层和软件层。然而，本领域的技术人员应当理解，图7示出的消息处理装置10的结构仅为示例，并不构成对消息处理装置10结构的限定。例如，消息处理装置10可以根据实施需要设置较图7更多的组件，或者根据实施需要省略设置部分组件。

消息处理装置10的硬件层包括处理器11、输入/输出接口13，存储介质14以及网络接口12，组件可以经系统总线连接通信。

处理器11可以采用中央处理器(CPU)、微处理器(MCU，Microcontroller Unit)、专用集成电路(ASIC，Application Specific Integrated Circuit)或逻辑可编程门阵列(FPGA，Field－Programmable Gate Array)实现。

输入/输出接口13可以采用如显示屏、触摸屏、扬声器等输入/输出器件实现。

存储介质14可以采用闪存、硬盘、光盘等非易失性存储介质实现，也可以采用双倍率(DDR，Double Data Rate)动态缓存等易失性存储介质实现，其中存储有用以执行上述消息处理方法的可执行指令。

示例性地，存储介质14可以与消息处理装置10共同在同一地点设置，也可以相对于消息处理装置10异地远程设置，或者相对消息处理装置10本地和异地分布设置。网络接口12向处理器11提供外部数据如异地设置的存储介质14的访问能力，示例性地，网络接口12可以基于近场通信(NFC，Near Field Communication)技术、蓝牙(Bluetooth)技术、紫蜂(ZigBee)技术进行的近距离通信，另外，还可以实现如基于码分多址(CDMA，Code DivisionMultiple Access)、宽带码分多址(WCDMA，Wideband Code Division Multiple Access)等通信制式及其演进制式的通信。

驱动层包括用于供操作系统16识别硬件层并与硬件层各组件通信的中间件15，例如可以为针对硬件层的各组件的驱动程序的集合。

操作系统16用于提供面向用户的图形界面，示例性地，包括插件图标、桌面背景和应用图标，操作系统16支持用户经由图形界面对设备的控制本发明实施例对上述设备的软件环境如操作系统类型、版本不做限定，例如可以是安卓操作系统、iOS操作系统、Linux操作系统或UNIX操作系统等。

软件层提供供客服与多个媒体平台的用户进行即时通信的客户端应用(应用17)。

对消息处理装置的功能结构进行说明，参见图8示出的消息处理装置20的一个可选的功能结构示意图，包括：

标识单元22，用于为用户分配用于与业务方进行即时通信的全局标识；

获取单元21，用于获取所述用户经由互联网媒体发送至所述业务方的用户消息；

转换单元23，用于转换所述用户消息为适配所述业务方的消息协议的即时通信消息；

通信单元24，用于发送所述携带有所述全局标识的所述即时通信消息至所述业务方；

所述转换单元23，还用于基于来自所述业务方的即时通信消息携带的全局标识，确定所述即时通信消息的目标用户，并转换来自所述业务方的即时通信消息为适配在所述互联网媒体中传输的用户消息；将转换得到的用户消息经由所述互联网媒体发送至所述目标用户。

在一个实施例中，所述获取单元21，还用于基于与公众平台之间的应用程序接口，获取所述业务方的公众号的订阅用户发送至所述业务方的客服的用户消息。

在一个实施例中，所述获取单元21，还用于基于与电邮服务器之间的应用程序接口，获取所述用户发送至所述业务方的客服的电子邮件。

在一个实施例中，所述获取单元21，还用于基于与电话服务器之间的应用程序接口，获取所述用户通过呼叫所述业务方的客服而发送的语音数据。

在一个实施例中，所述标识单元22，还用于获取到所述用户经由互联网媒体发送至所述业务方的用户消息时，对所述用户在所述互联网媒体中的标识进行映射处理，得到所述用户与所述业务方进行即时通信时作为即时通信用户的全局标识。

在一个实施例中，所述消息处理装置20还包括：

绑定单元25，用于基于所述互联网媒体的用于输出所述用户消息的应用程序接口的信息、以及所述业务方的用于接收即时通信消息的应用程序接口的信息，在服务后台侧绑定所述互联网媒体。

在一个实施例中，所述转换单元23，还用于基于所述互联网媒体使用的消息协议解析所述用户消息，得到所述用户在所述互联网媒体输入的内容，基于所述业务方使用的消息协议封装所述内容、以及所述用户的全局标识形成所述即时通信消息。

在一个实施例中，所述转换单元23，还用于基于来自所述业务方的即时通信消息携带的全局标识，映射出所述目标用户在相应公众平台的标识，转换相应的即时通信消息为适配在相应公众平台中传输的用户消息。

在一个实施例中，所述转换单元23，还用于基于来自所述业务方的即时通信消息携带的全局标识，映射出所述目标用户的电邮地址，转换所述返回的即时通信消息为待发送至所述电邮地址的电子邮件。

在一个实施例中，所述转换单元23，还用于基于所述来自所述业务方的即时通信消息携带的全局标识，映射出所述目标用户的电话号码，转换所述返回的即时通信消息为适配在相应的电话网络中传输的语音数据。

在一个实施例中，所述消息处理装置20还包括：

转接单元26，用于检测到满足客服转接条件，撤销所述用户与所述业务方的客服之间用于传输所述即时通信消息的会话，并建立所述用户与所述业务方的待转接客服之间的会话。

在一个实施例中，所述转接单元26，还用于检测所述业务方提交的转接到所述待转接客服的转接请求，或者，检测到所述用户提交的所述客服转接请求。

本发明实施例具有以下有益效果：

1)为用户分配的全局标识能够实现区分不同通信方式的用户，从而基于全局标识对用户与业务方之间的上行消息(用户消息)/下行消息(业务方返回的即时通信消息)对接，这样，不管用户通过使用何种通信方式的互联网媒体向业务方发送用户消息，都会被转换为即时通信消息发送至业务方，业务方只需要使用即时通信客户端即可处理响应不同通信方式的用户，不再需要使用不同的客户端，简化了业务方针对用户消息的处理，进而提升业务方与用户之间的沟通效率。

2)对于业务方和用户之间的用户传输即时通信消息的会话来说，只需要使用即时通信的消息协议实现即时通信消息的收发即可，不需要实现其他的会话管理功能，简化了业务方的业务系统的拓扑结构。

3)由于即时通信消息的转换处理与业务方无关，当用户与业务方之间的通信方式发生增加、删除或更新时，业务方也不需要针对通信方式而进行维护工作，实现降低业务方的维护难度的效果。

4)实现了对不同公众平台的用户咨询统一在业务方的即时通信客户端中进行转接的效果，对于业务方来说，不必针对每个公众平台分配客服以及转接客服，有利于客服人员的调配，增进与用户的沟通效率。

本领域的技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于一计算机可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述的存储介质包括：移动存储消息处理装置、随机存取存储器(RAM，Random Access Memory)、只读存储器(ROM，Read-Only Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

或者，本发明上述集成的单元如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明实施例的技术方案本质上或者说对相关技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机消息处理装置(可以是个人计算机、服务器、或者网络消息处理装置等)执行本发明各个实施例所述方法的全部或部分。而前述的存储介质包括：移动存储消息处理装置、RAM、ROM、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以所述权利要求的保护范围为准。

Claims (24)

1.一种消息处理方法，其特征在于，包括：

为用户分配用于与业务方进行即时通信的全局标识；

获取所述用户经由互联网媒体发送至所述业务方的用户消息；

转换所述用户消息为适配所述业务方的消息协议的即时通信消息；

发送所述携带有所述全局标识的所述即时通信消息至所述业务方；

基于来自所述业务方的即时通信消息携带的全局标识，确定所述即时通信消息的目标用户，并转换来自所述业务方的即时通信消息为适配在所述互联网媒体中传输的用户消息；

将转换得到的用户消息经由所述互联网媒体发送至所述目标用户。

2.如权利要求1所述的方法，其特征在于，所述获取用户经由互联网媒体发送至业务方的用户消息，包括：

基于与公众平台之间的应用程序接口，获取所述业务方的公众号的订阅用户发送至所述业务方的客服的用户消息。

3.如权利要求1所述的方法，其特征在于，所述获取用户经由互联网媒体发送至业务方的用户消息，包括：

基于与电邮服务器之间的应用程序接口，获取所述用户发送至所述业务方的客服的电子邮件。

4.如权利要求1所述的方法，其特征在于，所述获取用户经由互联网媒体发送至业务方的用户消息，包括：

基于与电话服务器之间的应用程序接口，获取所述用户通过呼叫所述业务方的客服而发送的语音数据。

5.如权利要求1所述的方法，其特征在于，所述为用户分配用于与业务方进行即时通信的全局标识，包括：

获取到所述用户经由互联网媒体发送至所述业务方的用户消息时，对所述用户在所述互联网媒体中的标识进行映射处理，得到所述用户与所述业务方进行即时通信时作为即时通信用户的全局标识。

6.如权利要求1所述的方法，其特征在于，还包括：

基于所述互联网媒体的用于输出所述用户消息的应用程序接口的信息、以及所述业务方的用于接收即时通信消息的应用程序接口的信息，在服务后台侧绑定所述互联网媒体。

7.如权利要求1所述的方法，其特征在于，所述转换所述用户消息为适配所述业务方的消息协议的即时通信消息，包括：

基于所述互联网媒体使用的消息协议解析所述用户消息，得到所述用户在所述互联网媒体输入的内容，基于所述业务方使用的消息协议封装所述内容、以及所述用户的全局标识形成所述即时通信消息。

8.如权利要求1所述的方法，其特征在于，所述基于来自所述业务方即时通信消息携带的全局标识，确定所述即时通信消息的目标用户，并转换来自所述业务方的即时通信消息为适配在所述互联网媒体中传输的用户消息，包括：

基于来自所述业务方的即时通信消息携带的全局标识，映射出所述目标用户在相应公众平台的标识，转换相应的即时通信消息为适配在相应公众平台中传输的用户消息。

9.如权利要求1所述的方法，其特征在于，所述基于来自所述业务方即时通信消息携带的全局标识，确定所述即时通信消息的目标用户，并转换来自所述业务方的即时通信消息为适配在所述互联网媒体中传输的用户消息，包括：

基于来自所述业务方的即时通信消息携带的全局标识，映射出所述目标用户的电邮地址，转换所述返回的即时通信消息为待发送至所述电邮地址的电子邮件。

10.如权利要求1所述的方法，其特征在于，所述基于来自所述业务方即时通信消息携带的全局标识，确定所述即时通信消息的目标用户，并转换来自所述业务方的即时通信消息为适配在所述互联网媒体中传输的用户消息，包括：

基于来自所述业务方的即时通信消息携带的全局标识，映射出所述目标用户的电话号码，转换所述返回的即时通信消息为适配在相应的电话网络中传输的语音数据。

11.如权利要求1所述的方法，其特征在于，还包括：

检测到满足客服转接条件，撤销所述用户与所述业务方的客服之间用于传输所述即时通信消息的会话，并建立所述用户与所述业务方的待转接客服之间的会话。

12.如权利要求11所述的方法，其特征在于，所述检测到满足客服转接条件，包括：

检测所述业务方提交的转接到所述待转接客服的转接请求，或者，检测到所述用户提交的所述客服转接请求。

13.一种消息处理装置，其特征在于，包括：

标识单元，用于为用户分配用于与业务方进行即时通信的全局标识；

获取单元，用于获取所述用户经由互联网媒体发送至所述业务方的用户消息；

转换单元，用于转换所述用户消息为适配所述业务方的消息协议的即时通信消息；

通信单元，用于发送所述携带有所述全局标识的所述即时通信消息至所述业务方；

所述转换单元，还用于基于来自所述业务方的即时通信消息携带的全局标识，确定所述即时通信消息的目标用户，并转换来自所述业务方的即时通信消息为适配在所述互联网媒体中传输的用户消息；

所述将转换得到的用户消息经由所述互联网媒体发送至所述目标用户。

14.如权利要求13所述的消息处理装置，其特征在于，

所述获取单元，还用于基于与公众平台之间的应用程序接口，获取所述业务方的公众号的订阅用户发送至所述业务方的客服的用户消息。

15.如权利要求13所述的消息处理装置，其特征在于，

所述获取单元，还用于基于与电邮服务器之间的应用程序接口，获取所述用户发送至所述业务方的客服的电子邮件。

16.如权利要求13所述的消息处理装置，其特征在于，

所述获取单元，还用于基于与电话服务器之间的应用程序接口，获取所述用户通过呼叫所述业务方的客服而发送的语音数据。

17.如权利要求13所述的消息处理装置，其特征在于，

所述标识单元，还用于获取到所述用户经由互联网媒体发送至所述业务方的用户消息时，对所述用户在所述互联网媒体中的标识进行映射处理，得到所述用户与所述业务方进行即时通信时作为即时通信用户的全局标识。

18.如权利要求13所述的消息处理装置，其特征在于，所述消息处理装置还包括：

绑定单元，用于基于所述互联网媒体的用于输出所述用户消息的应用程序接口的信息、以及所述业务方的用于接收即时通信消息的应用程序接口的信息，在服务后台侧绑定所述互联网媒体。

19.如权利要求13所述的消息处理装置，其特征在于，

所述转换单元，还用于基于所述互联网媒体使用的消息协议解析所述用户消息，得到所述用户在所述互联网媒体输入的内容，基于所述业务方使用的消息协议封装所述内容、以及所述用户的全局标识形成所述即时通信消息。

20.如权利要求13所述的消息处理装置，其特征在于，

所述转换单元，还用于基于来自所述业务方的即时通信消息携带的全局标识，映射出所述目标用户在相应公众平台的标识，转换相应的即时通信消息为适配在相应公众平台中传输的用户消息。

21.如权利要求13所述的消息处理装置，其特征在于，

所述转换单元，还用于基于来自所述业务方的即时通信消息携带的全局标识，映射出所述目标用户的电邮地址，转换所述返回的即时通信消息为待发送至所述电邮地址的电子邮件。

22.如权利要求13所述的消息处理装置，其特征在于，

所述转换单元，还用于基于来自所述业务方的即时通信消息携带的全局标识，映射出所述目标用户的电话号码，转换所述返回的即时通信消息为适配在相应的电话网络中传输的语音数据。

23.如权利要求13所述的消息处理装置，其特征在于，还包括：

转接单元，用于检测到满足客服转接条件，撤销所述用户与所述业务方的客服之间用于传输所述即时通信消息的会话，并建立所述用户与所述业务方的待转接客服之间的会话。

24.如权利要求23所述的消息处理装置，其特征在于，

所述转接单元，还用于检测所述业务方提交的转接到所述待转接客服的转接请求，或者，检测到所述用户提交的所述客服转接请求。