CN101018409A

CN101018409A - 消息处理设备、系统及方法

Info

Publication number: CN101018409A
Application number: CNA2007100066687A
Authority: CN
Inventors: 刘晓明; 江健; 郑仲恩; 阳武; 钟朝东; 孙志斌
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2006-04-14
Filing date: 2007-01-23
Publication date: 2007-08-15
Anticipated expiration: 2027-01-23
Also published as: CN100558188C

Abstract

本发明涉及移动通信技术，尤其涉及一种消息处理设备、消息转发设备、消息处理系统及消息处理方法，以解决现有技术中无法对用户消息数据进行永久保存的问题。通过消息处理设备和SMSC/MMSC等形成的系统，使单纯的消息转发扩展到了永久存储；进一步，本发明实施例提供的技术方案实现了SM、MM以及UM消息的统一存储，并对用户的各种消息进行有效的业务管理。

Description

消息处理设备、系统及方法

技术领域

本发明涉及移动通信技术，尤其涉及一种消息处理设备、消息转发设备、消息处理系统及消息处理方法。

背景技术

当前普遍应用的消息通信手段有短消息SM(Short Message)、多媒体消息MM(Multimedia Message)和统一消息UM(Unified messaging，包括普通E-mail、Voice-mail和Fax-mail)。短消息和多媒体消息易于存储，计费方式也灵活多样，但每条消息的存储能力有限，而UM消息所存储的信息量可以很大，但对于数以十亿计的手机用户而言，应用范围有限。

短消息业务中心SMSC(Short Message Service Center)：实现短消息存储转发的功能，一般SMSC只提供暂存功能。当SMSC收到一条用户上传消息MO(Mobile Originate)时，如果此时无法向目标用户发送下传消息MT(Mobile Terminate)，即将该消息缓存下来，缓存时间可以为2～3天，该缓存消息的数量一般可以配置，根据现网情况，通常为10条左右。现有SMSC只是提供暂存的功能，只要用户接收MT消息的时机成熟，该消息便到达目标用户，SMSC将该消息从缓存队列中清除。

多媒体消息业务中心MMSC(Multimedia Messaging Service Center)：实现多媒体消息的统一转发，多媒体消息包括文本、图像、音频、视频和数据等，其中一种主要形式是彩信消息，多媒体消息在一定程度上扩展了单条消息的承载能力，可以把包括文本在内的多种格式的文件以消息的形式进行传送。

UM消息：包括普通E-mail、Voice-mail和Fax-mail，这些都在当前互联网上最为普遍的基本的消息传递方式，无论在信息传递速度，传递内容的多样性，复杂性，可靠性，以及信息的永久存储都是其优点所在，电子邮件的客户群可以很方便地通过互联网进行各种资讯的交互。

上述现有的消息处理系统及消息处理方法存在以下缺陷：

1、SM只能转发不能永久存储，即使SMSC拥有一定的缓存能力，也无法实现消息的永久存储和业务管理，这给SM的应用带来了很大的局限性和不可塑性，不利于业务的开展。

2、MM虽然一定程度上扩展了消息的应用范围，丰富了消息的内容空间，但和SM一样，依然没有解决消息永久存储和业务管理的能力；此外，MMSC的MM7(多媒体消息业务接口)接口非常复杂，在互联网上基于HTTP层面上进行传输，附加信息带来的额外存储空间较多，在该接口层面上对MM进行业务管理，是一件非常复杂的事情，无疑增加服务提供商的运营成本，也为各业务提供带来不小的开发成本。

3、UM可以弥补SM、MM不能永久存储和业务管理的缺陷，使得互联网信息业务更加丰富灵活，但是对于E-mail等电子邮件消息来说，非常依赖于互联网终端，当前最灵活的互联网终端就是手机，而电子邮件在手机上的应用却是非常不统一，很多厂商推出的电子邮件服务在手机上的应用都非常有限，界面各异，无法实现灵活的计费。

另外，SM、MM以及UM消息，作为现代消息通信的三种重要通信手段，分别具有各自的优点，却不能形成有机的统一体，使用户方便的对各类消息进行有效的业务管理。

发明内容

本发明实施例提供一种消息处理设备、消息转发设备、消息处理系统及消息处理方法，以解决现有技术中无法对用户消息数据进行永久保存的问题。

本发明实施例提供的一种消息处理设备包括：

第一接口模块，用于接收用户的消息数据，该消息数据中包含用户身份信息；

用户管理模块，用于对应管理各用户的身份信息及业务信息，并对所述消息信息中包含的用户身份信息进行鉴权；

数据管理模块，用于管理用户的消息数据；

第一存储模块，用于存储通过鉴权的用户身份信息对应的消息数据，所述消息数据是对应用户的身份信息存储的。

其中，所述第一接口模块至少包括如下之一：

短消息实时接口单元，用于从短消息业务中心接收用户的短消息；

多媒体消息实时接口单元，用于从多媒体消息业务中心接收用户的多媒体消息；

统一消息业务消息接口单元，用于从统一消息业务服务器接收用户统一消息的摘要信息。

本发明提供的一种消息处理系统，包括消息转发设备和消息处理设备，所述消息处理设备用于从所述消息转发设备接收包含用户身份信息的用户消息数据，并根据对应管理的用户身份信息及业务信息鉴权所述消息信息中包含的用户身份信息；以及存储并管理通过鉴权的用户身份信息对应的消息数据，所述消息数据是对应用户的身份信息存储的。

其中，所述消息转发设备至少包括如下之一：短消息业务中心、多媒体消息业务中心、统一消息业务服务器。

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

接收用户的消息数据，该消息数据中包含用户身份信息；

根据对应管理的用户身份信息及业务信息，对所述消息数据中包含的用户身份信息进行鉴权；

存储通过鉴权的用户身份信息对应的消息数据，所述消息数据是对应用户身份信息存储的。

其中，所述用户的消息数据包括如下之一：

从短消息业务中心接收的短消息；

从多媒体消息业务中心接收的用户多媒体消息；

从统一消息业务服务器接收的用户统一消息的摘要信息。

进一步，所述方法还包括：接收用户的操作指令，并根据该操作指令对存储的消息数据执行相应的操作。以及

接收用户业务信息的订购、变更或取消操作，并更新对应管理的用户身份信息及业务信息。

本发明实施例还提供一种消息处理系统，包括消息转发设备和消息存储设备，其中，所述消息转发设备包括：

第二接口模块，用于接收用户的消息数据，该消息数据中包含用户身份信息；

消息处理模块，用于对应管理各用户的身份信息及业务信息，并对所述消息信息中包含的用户身份信息进行鉴权，以及将通过业务鉴权的用户身份信息及对应的消息数据发送给所述消息存储设备；

第三接口模块，用于和所述消息存储设备进行通信；

所述消息存储设备包括：

第四接口模块，用于和所述消息转发设备进行通信；

存储控制模块，用于接收并管理来自所述消息转发设备的用户身份信息及对应的消息数据；

第二存储模块，用于存储用户身份信息及对应的消息数据。

其中，所述消息转发设备包括：短消息业务中心和/或多媒体消息业务中心。

本发明实施例提供的另一种消息转发设备，包括第二接口模块，用于接收用户的消息数据，该消息数据中包含用户身份信息，所述消息转发设备还包括：

消息处理模块，用于对应管理各用户的身份信息及业务信息，并对所述消息信息中包含的用户身份信息进行鉴权，以及将通过业务鉴权的用户身份信息及对应的消息数据发送给外部存储设备；

第三接口模块，用于和所述外部存储设备进行通信。

进一步，所述消息转发设备还包括：备份设置接口模块，用于接收所述用户身份信息及业务信息，并转发给所述消息处理模块。

本发明实施例提供的技术方案可以分别实现各类消息的永久存储，进一步，本发明实施例提供的技术方案实现了SM、MM以及UM消息这些原本相互独立、互不关联的消息的统一存储，使这些本来具有非常明显优势的消息交互技术发挥各自的优势，形成有机的统一体，并对用户的各种消息进行有效的业务管理。

附图说明

图1为本发明实施例提供的第一种消息处理设备的主要结构示意图；

图2为本发明实施例中第一种消息处理设备实施例1的主要结构示意图；

图3为本发明实施例中第一种消息处理设备实施例2的主要结构示意图；

图4为本发明实施例中第一种消息处理设备实施例3的主要结构示意图；

图5为本发明实施例中第一种消息处理设备实施例4的主要结构示意图；

图6为本发明实施例中第一种消息处理系统具体实施例1的主要结构示意图；

图7为本发明实施例中第一种消息处理系统具体实施例2的主要结构示意图；

图8为本发明实施例中第一种消息处理系统具体实施例3的主要结构示意图；

图9为本发明实施例中第一种消息处理系统具体实施例4的主要结构示意；

图10为本发明实施例提供的第二种消息处理系统的主要结构示意图；

图11为本发明实施例提供的第二种消息处理系统具体实施1的主要结构示意图；

图12为本发明实施例提供的第二种消息处理系统具体实施2的主要结构示意图。

具体实施方式

本发明实施例为实现消息的永久存储，首先提供第一种消息处理设备，该消息处理设备可以从SMSC、MMSC或UM服务器接收用户的消息数据，并根据用户定制的业务信息，对用户的消息数据实现永久存储。

如图1所示，该消息处理设备可以包括如下主要结构：

第一接口模块10，用于接收用户的消息数据，该消息数据中包含用户身份信息；

用户管理模块14，用于对应管理各用户的身份信息及业务信息，并对所述消息数据中包含的用户身份信息进行鉴权；

数据管理模块15，用于管理用户的消息数据；

第一存储模块16，用于存储通过业务鉴权的用户身份信息对应的消息数据，所述消息数据是对应用户的身份信息存储的。

根据现有用户消息的类型及来源，第一接口模块至少可以包括下面列出的任何一个、其中两个或三个接口单元：

短消息实时接口单元，用于实时从短消息业务中心接收用户的短消息；

多媒体消息实时接口单元，用于实时从多媒体消息业务中心接收用户的多媒体消息；

统一消息业务消息接口单元，用于实时从统一消息业务服务器接收用户统一消息的摘要信息。

消息处理设备对各种消息进行接收处理，然后进行存储，用户及运营商对各种消息业务的管理也都是通过消息处理设备来完成的。

参见图2，其为本发明实施例1提供的一种消息处理设备的主要结构示意图，图2所示的消息处理设备的第一接口模块10同时包括短消息实时接口单元、多媒体消息实时接口单元和统一消息业务消息接口单元，可以同时实现短消息、多媒体消息及统一消息摘要信息的永久存储，称为综合消息处理中心UMC(Unified Message Center)，该UMC主要包括：

短消息实时接口单元11，用于进行协议转换与解析，与短消息业务中心进行通信，实时从短消息业务中心接收用户的短消息；

多媒体消息实时接口单元12，用于进行协议转换与解析，与多媒体消息业务中心进行通信，实时从多媒体消息业务中心接收用户的多媒体消息；

UM消息接口单元13，用于进行协议转换与解析，与UM服务器进行通信，实时从统一消息业务服务器接收用户统一消息的摘要信息；

用户管理模块14，分别与所述短消息接口单元11、所述多媒体消息接口单元12和所述UM消息接口单元13连接，用于管理用户身份信息和对应的业务信息，以及分析获取的短消息、多媒体消息、UM消息摘要信息中的用户身份信息并进行鉴权；

数据管理模块15，与所述用户管理模块14连接，用于对用户的消息数据进行管理；

第一存储模块16，与所述数据管理模块15连接，用于存储用户的消息数据，用户的消息数据是对应用户身份信息存储的。

参见图3，其为本发明实施例2提供的UMC的主要结构示意图，参见图2：

当所述第一接口模块中包括短消息实时接口单元11时，所述第一接口模块中还可以包括：短消息文件接口单元11a，与所述数据管理模块15连接，用于进行协议转换与解析，与短消息FTP服务器进行通信，短消息FTP服务器中存储有短消息缓存文件，该短消息缓存文件包括UMC从短消息业务中心接收但存储失败的短消息，还可能包括短消息业务中心向UMC发送失败的短消息；

当所述第一接口模块中包括多媒体消息实时接口单元12时，所述第一接口模块中还可以包括：多媒体消息文件接口单元12a，与所述数据管理模块15连接，用于进行协议转换与解析，与多媒体消息FTP服务器进行通信，多媒体消息FTP服务器中存储有多媒体消息缓存文件，该多媒体消息缓存文件包括UMC从多媒体消息业务中心接收但存储失败的多媒体消息，还可能包括多媒体消息业务中心向UMC发送失败的多媒体消息。

上述的两个实施例中的UMC只是完成了对输入的用户的各种消息数据进行统一存储，而在实际的应用中还需要对存储的各种消息及业务进行相应的管理，例如，用户根据需要对其存储的消息进行删除，或者取消某类消息的存储业务，以及运营商要对用户的消息存储业务进行收费等，所以该UMC还进一步包括与网络中的各种管理平台进行通信的接口单元。

参见图4，其为本发明的消息处理设备的实施例3的结构示意图，在实施例1的基础上还可以进一步包括：

Portal(门户，一个portal就是指一个基于网页的系统，通常都会提供个人化设置、单一登陆，并将各种信息通过网页的方式向用户呈现)接口单元19，与所述数据管理模块15连接，用于进行协议转换与解析，与Portal服务器进行通信；

计费模块17，与所述数据管理模块15连接，用于根据用户在UMC中使用的消息存储空间来计算用户的使用费用；

计费接口单元18，与所述计费模块17连接，用于进行协议转换与解析，与计费子系统进行通信。

用户业务管理接口单元20，与所述用户管理模块14连接，用于进行协议转换与解析，与用户业务管理子系统进行通信。

上述的三个接口单元彼此之间是相互独立的，可以在实施例1或2的基础上单独增设其中的某个单元，也可以同时设置在三个单元，用于实时的和网络中的Portal服务器、计费子系统及用户业务管理子系统进行通信，其中，计费模块与计费接口单元是同时设置的。

上述各实施例中设置各种接口单元的原因是，网络中的各个业务平台所采用的传输协议不同，为了能与各个业务平台进行通信，便设置了相应的接口单元，接口单元主要完成接收其他业务平台发送的信息，并进行解析获取到原始的内容以及将要发送给其他业务平台的信息根据传输协议进行转换并发送。

参见图5，其为本发明的消息处理设备的实施例4的结构示意图，在实施例1的基础上，该单元还包括：数据缓存模块21，与所述数据管理模块15连接，用于缓存在消息存储模块中存储失败的消息，在实际的应用中，第一存储模块采用数据库对消息进行存储，数据管理模块将收到的消息添加到数据库中。如果此时数据库操作失败，数据管理模块会将消息发送至消息缓存模块中进行缓存，生成消息缓存文件，等到数据库恢复时，数据管理模块将数据重新存入数据库，但该数据缓存模块只是对消息进行缓存，并且缓存的空间有限，所以当消息多次存储失败后，数据管理模块便会发送通过接口单元输出存储失败的响应消息。

上述的实施例1-4的消息处理设备可以完成对输入的用户的各种消息进行统一的存储和管理，但该设备只是一个基本的装置，在实际的应用中，由于各种消息的业务承载分别由不同的网络节点来负责，并且各种管理平台也是基于网络中的服务器，所以该单元只有和通信网络中的相关节点和服务器相连接，才能真正发挥对用户的各种消息的统一的实时的存储和管理。

参见图6，其为本发明实施例的第一种消息处理系统的具体实施例1的结构示意图，该系统包括：

消息处理设备1，用于对短消息、多媒体消息和UM消息进行集中的存储和管理；

短消息业务中心2，与所述消息处理设备1的短消息实时接口单元11连接，用于向消息处理设备发送用户的短消息；

多媒体消息业务中心3，与所述消息处理设备1的多媒体消息实时接口单元12连接，用于向消息处理设备发送用户的多媒体消息；

UM消息服务器4，与所述消息处理设备1的UM消息接口单元13连接，用于向消息处理设备发送用户的UM消息的摘要信息。

参见图7，其为本发明的消息处理系统的具体实施例2的结构示意图，该系统在综合消息处理系统的具体实施例1的基础上进一步包括：

短消息FTP服务器2a，与所述消息处理设备的短消息文件接口单元11a及短消息业务中心2连接，用于存储消息处理设备存储失败的短消息；

多媒体消息FTP服务器3a，与所述消息处理设备的多媒体消息文件接口12a单元及多媒体消息业务中心3连接，用于存储消息处理设备存储失败的多媒体消息。

参见图8，其为本发明的消息处理系统的具体实施例3的结构示意图，该系统在综合消息处理系统的具体实施例1的基础上进一步包括：

Portal服务器5，与所述消息处理设备1的Portal接口单元19连接，用于为用户提供管理平台，对消息处理设备1中存储的消息进行管理。

计费子系统6，与所述消息处理设备1的计费接口单元18连接，用于接收消息处理设备1发送的用户的使用费用信息，并根据该使用费用信息进行费用管理。

用户业务管理子系统7，与所述消息处理设备1的用户业务管理接口单元20连接，用于对用户的综合消息处理业务进行管理。

上述的Portal服务器、计费子系统和用户业务管理子系统彼此之间可以是相互独立的，可以在综合消息处理系统的实施例1和实施例2的系统的基础上单独增设其中的一个子系统或服务器，也可以增设上述三个服务器或子系统的任意组合。

基于本发明实施例提供的第一种消息处理系统，本发明实施例还提供一种消息处理方法，由网络中的消息转发设备将用户的各类消息数据转发给本发明实施例提供的消息处理设备，该消息数据中包含用户身份信息；消息转发设备例如：短消息业务中心、多媒体消息业务中心或UM消息服务器等，消息处理设备接收到用户的消息数据后，根据对应管理的用户身份信息及业务信息，对所述消息数据中包含的用户身份信息进行鉴权，并存储通过鉴权的用户身份信息对应的消息数据，所述消息数据是对应用户身份信息存储的。

下面通过实施例来进一步说明本方法。

消息的处理方法的具体实施例1，包括如下操作：

短消息业务中心收到短消息时，向消息处理设备的短消息实时接口单元发送包含该短消息的消息提交请求；短消息实时接口单元从接收到的消息提交请求中提取出所述短消息发送给用户管理模块，用户管理模块提取所述短消息中携带的用户身份信息并对该用户进行鉴权，如果鉴权成功则，将该短消息发送给数据管理模块，数据管理模块向第一存储模块发送指令，将该短消息存储在第一存储模块中该用户身份信息对应的存储空间中。

多媒体消息业务中心收到多媒体消息时，向消息处理设备的多媒体消息实时接口单元发送包含该多媒体消息的消息提交请求；多媒体消息实时接口单元从接收到的消息提交请求中提取出所述多媒体消息发送给用户管理模块，用户管理模块提取所述多媒体消息中携带的用户身份信息并对该用户进行鉴权，如果鉴权成功则，将该多媒体消息发送给数据管理模块，数据管理模块向第一存储模块发送指令，将该多媒体消息存储在第一存储模块中该用户身份信息对应的存储空间中。

UM服务器收到UM消息时，向消息处理设备的UM消息接口单元发送包含所述UM消息的摘要信息的消息提交请求；UM消息接口单元从接收到的消息提交请求中提取出所述摘要信息发送给用户管理模块，用户管理模块提取所述摘要信息中携带的用户身份信息并对该用户进行鉴权，如果鉴权成功则，将该摘要信息发送给数据管理模块，数据管理模块向第一存储模块发送指令，将摘要信息存储在第一存储模块中该用户对应的存储空间中。由于UM服务器自身可以对UM消息进行存储，因此，在消息处理设备只存储UM消息的摘要信息，不存储整个UM消息的内容。消息处理方法的具体实施例2，在综合消息的处理方法的具体实施例1的基础上还包括如下操作：

如果消息处理设备将短消息业务中心提交的短消息成功的存储在该用户对应的存储空间中，则向短消息业务中心发送存储成功的响应消息；如果存储失败，则向短消息业务中心发送存储失败的响应消息，短消息业务中心将生成该短消息的缓存文件并存储在短消息FTP服务器中；消息处理设备从该FTP服务器获取所述短消息并进行存储；

如果消息处理设备将多媒体消息业务中心提交的多媒体消息成功的存储在该用户对应的存储空间中，则向短消息业务中心发送存储成功的响应消息；如果存储失败，则向多媒体消息业务中心发送存储失败的响应消息，短消息业务中心将生成该多媒体消息的缓存文件并存储在多媒体消息FTP服务器中；消息处理设备从该FTP服务器获取所述多媒体消息并进行存储。

综合消息的处理方法的具体实施例3，在综合消息的处理方法的具体实施例1或2的基础上还可以单独包括如下三个操作，或这个三个操作的任意组合：

操作1：消息处理设备的Portal接口单元接收Portal服务器发送的包含对用户存储空间中的内容进行管理操作指令的消息，并将该操作指令发送给数据管理模块，数据管理模块根据该操作指令对第一存储模块中的所述用户存储空间的内容执行相应的操作。

操作2：消息处理设备的数据管理模块获取用户占用的存储空间信息，并将该存储空间信息通过计费接口单元发送给计费子系统，所述计费子系统根据该存储空间信息进行费用计算。

操作3：消息处理设备的用户业务管理接口接收用户业务管理子系统发送的用户业务的订购、变更或取消的信息，并将该信息发送给用户管理模块，所述用户管理模块根据该信息增加、更新或删除相应的用户数据。

下面提供一个本发明的综合消息处理系统的较佳实施例来进一步说明本发明，参见图9，其为本发明的综合消息处理系统的具体实施例4的结构示意，该系统包括：短消息业务中心(SMSC)2、短消息FTP服务器2a、多媒体消息业务中心(MMSC)3、多媒体消息FTP服务器3a、UM服务器4、消息处理设备(UMC)1、Portal服务器5、计费子系统(在本实施例中具体采用BOSS(business and operation support system，业务运营支撑系统)系统)6、用户业务管理子系统(在本实施例中具体采用Provision System(数据业务管理平台))7，还包括多个通信接口连接I1-I7。

1)短消息业务中心(SMSC)2与UMC1的短消息实时接口单元之间通过I1接口连接：I1为实时接口，遵从SMPP协议，使用TCP/IP协议进行数据传输。当SMSC当接收到用户发来的短消息时，在执行正常的业务处理流程的同时，也向UMC提交该短消息，UMC存储该消息并将存储结果实时地返回给SMSC，SMSC可以很快地就知道该消息是否存储成功。

2)短消息FTP服务器2a与短消息业务中心2连接，短消息FTP服务器2a与UMC1的短消息文件接口单元通过I2接口连接：I2为文件接口，采用私有的话单文件格式，使用FTP协议进行数据传输。当消息量很大的时候，或者由于UMC系统的原因，可能会出现短消息存储失败的情况，这时，UMC将向SMSC返回存储失败的响应消息，SMSC收到该存储失败的响应消息后便将该短消息存储在与其连接的短消息FTP服务器中；如果SMSC向UMC发送消息时发送失败，SMSC也会将发送失败的消息存储在所述FTP服务器中，该短消息FTP服务器是专门用来缓存存储失败及发送失败的短消息的，SMSC将短消息存储到该FTP服务器后，就不去管该短消息了，UMC将通过文件接口I2去该FTP服务器检测，当检测到短消息后，获取该消息再进行存储，UMC存储后也不需要再返回响应消息。UMC与短消息服务器间采私有的话单文件格式，使用FTP协议传输数据。正常情况下SMSC与UMC使用实时接口，当SMSC与UMC出现断连或UMC处理SMSC提交消息失败时，SMSC会生成该消息的缓存文件，并存储到与SMSC相连接的短消息FTP服务器中，该缓存文件的结构事先通过与SMSC和UMC协商确定的。UMC通过第三方FTP工具将SMSC生成的缓存文件保存到UMC指定的目录中，然后对该文件进行处理，提取出存储失败的短消息，然后进行存储。

3)多媒体消息业务中心3与UMC1的多媒体消息实时接口单元通过I3接口连接：I3为实时接口，遵从MM7(多媒体消息业务接口)协议，底层使用HTTP承载的SOAP协议进行数据传输。通过该接口，UMC将MMS消息存储到数据库和大文件系统中进行统一管理。虽然MMSC与SMSC对UMC所使用的协议不同，但基本的通信过程是一样的。

4)多媒体消息FTP服务器3a与多媒体消息业务中心3连接，多媒体消息FTP服务器3a与UMC1的多媒体消息文件接口单元通过I4接口连接，I4为文件接口，使用FTP协议进行数据传输。和SMSC一样，正常情况下MMSC是通过实时接口与UMC通信，如果UMC存储失败或多媒体消息业务中心向UMC发送多媒体消息失败时，MMSC会将多媒体消息缓存成与UMC事先协商好的格式的文件，并存储到与MMSC连接的FTP服务器中，UMC使用第三方FTP工具将这些缓存文件获取到本地，然后对该文件进行处理，提取出多媒体消息，然后进行存储。

5)UM服务器4与UMC1的UM接口单元通过I5接口连接：

I5为实时接口，UM服务器与UMC之间采用私有协议通信，底层使用TCP/IP协议进行数据传输。UM消息包括普通EMail、Fax_Mail和Voice_Mail三种，当UM用户收到或者发送UM消息时，UM服务器会主动将UM消息的摘要信息提交给UMC。同时，UM用户对UM服务器中存储的UM消息进行操作时，例如删除、更新UM消息，UM服务器也会通知UMC，UMC对其存储的UM消息的摘要信息执行相应的删除和更新等操作。

6)Portal服务器5与UMC1的Portal接口单元通过I6接口连接：

I6接口使用WSI(Web Service Interface，网络服务接口)协议进行数据传输，UMC和Portal服务器可以相互提供Web服务，两者之间的消息通过SOAP协议承载。UMC用户可以通过登录Portal，可以对存储的消息及文件夹进行各种管理操作。而Portal业务的实现是通过Portal服务器与UMC之间的WSI接口实现的，当用户通过Portal提交操作请求时，Portal会向UMC提交相应的请求，该请求符合WSI接口规范，UMC对用户请求进行处理后，执行相应的操作，并将执行结果返回给Portal服务器，用户便可以得到处理结果。例如用户需要删除一条SMS消息时，只需要在Portal删除消息的页面上对指定的SMS消息进行删除操作，Portal会向UMC提交删除该SMS消息的操作请求，UMC在数据库中将该消息删除后，向Portal返回删除的结果，并在Portal页面上显示。

7)计费子系统(在本实施例中具体采用BOSS)6与UMC1的计费接口单元之间通过接口I7连接：

I7为文件接口，采用FTP协议进行数据传输。UMC通过该接口将生成的用户计费话单传送至BOSS(business and operation support system，业务运营支撑系统)系统进行扣费。UMC通过计费模块，在每天固定的时间点(用户可配置)获取用户的在数据库中的当前容量信息，生成计费话单，通过第三方FTP工具将这些话单文件传送到BOSS系统，BOSS系统对这些话单进行处理。

8)用户业务管理子系统(在本实施例中具体采用Provision System)7与UMC1的用户业务管理接口单元通过接口I8连接：

I8为实时接口，遵从SMAP协议，底层采用TCP/IP协议进行数据传输。用户通过Provision System(数据业务管理平台)，对UMC发起业务订购、业务变更、业务取消和鉴权等操作。如用户需要订购UMC业务时，ProvisionSystem将向UMC提交用户订购业务请求，其中包括用户所订购业务的类型等信息，UMC用户管理模块根据该消息，在数据库中为该用户添加相关的信息，并操作结果返回给Provision System，Provision System根据返回结果确认订购。

基于上述系统，其主要业务流程如下：

1)业务订购、取消及变更流程：

用户可以通过Provision System进行开户，包括订购指定的业务套餐，变更业务，和取消业务。

业务订购：Provision System提交业务订购消息请求到UMC进行业务订购和套餐的确认，UMC接收到业务订购消息后，如果用户订购的业务中包含对UM消息的存储及管理业务，UMC向UM发送UM业务订购通知，并等待UM返回业务订购结果，UM接收并确认可以订购后向UMC返回订购结果应答。用户管理模块在数据库中添加该用户的相关信息，如果添加成功，向Provision System发送订购成功应答，否则发送订购失败应答消息。ProvisionSystem收到订购结果确认信息后，完成用户业务的订购。

业务取消：和订购相类似，由Provision System发起业务取消的消息，UMC根据Provision System提供的用户身份信息对用户订购的业务进行取消，如果用户所订购的UMC业务中包含UM业务，那么UMC会提交业务取消请求至UM服务器，并等待返回结果，当UMC收到UM服务器的取消业务的返回信息时，用户管理模块清除该用户在数据库中的相关数据，并将操作结果返回给Provision System。

业务变更：当Provision System发起业务变更请求时，用户管理模块对数据库中的用户业务信息进行更改，并将更改结果返回给Provision System。

2)消息存储流程

SMSC/MMSC通过实时接口提交一条短消息/多媒体消息到UMC，UMC的用户管理模块对该消息的用户进行鉴权，确认用户已经订购了短消息/多媒体消息业务，如果用户没有订购相应业务，相应的消息将无法被存储，向SMSC/MMSC返回错误应答消息，否则返回正确应答消息；如果鉴权成功，用户管理模块将消息转发至数据管理模块，数据管理模块将收到的短消息/多媒体消息添加到第一存储模块的数据库中，并更新用户容量；如果此时数据库操作失败，数据管理模块会将消息发送至消息缓存模块中进行缓存，生成消息缓存文件，等到数据库恢复时，数据管理模块将该短消息/多媒体消息重新存入数据库。

UM消息存储，UM消息存储过程和短消息/多媒体消息的存储过程大致相同。但UM消息比较特殊，UM是邮件服务器，当UM向UMC发出提交消息请求时，UM消息的主体仍然存放在UM服务器上，而只将消息的摘要信息存放到UMC中。这个特性区别于短消息/多媒体消息的存储方式，主要是由于SMSC/MMSC只做消息转发而不做消息存储，而UM本身对消息进行存储。

3)用户管理流程

用户管理包括对文件夹的管理和对消息的管理。服务提供商通过定制或自行开发遵守该WSI接口协议的Portal，即可和UMC进行通信，提供基于网页的多种多样的业务功能，用户通过登陆Portal，可以对自己的各类消息进行删除、查询，修改，定购和取消业务操作。另外，UMC提供的是基于文件夹式的消息管理方法，符合用户的使用习惯，也大大减少了用户对消息操作的使用难度。

(1)普通用户对消息及文件夹的管理：

普通用户对消息的管理：

i删除消息，Portal支持对短消息/多媒体消息/UM消息的删除；用户通过Portal删除消息时，在Portal的页面上执行删除相关消息的操作，Portal向UMC提交删除请求，数据管理模块从数据库中删除指定的消息后返回操作结果；需要指出的是，UM消息和SMS/MMS有所不同，UMC中存放的是UM消息的摘要信息，因此当要删除UM消息时，数据管理模块还需要通知UM服务器，将相应的消息删除并等待UM服务器应答消息，如果UM消息删除成功，数据管理模块会向Portal发送删除成功应答消息，否则返回失败应答消息。

ii消息状态修改，该状态是指消息已读/未读状态的修改；用户通过Portal，将一条或多条消息置为已读/未读状态，UMC的数据管理模块收到该消息后，在数据库中将指定的消息更改为用户指定的状态，并返回执行结果至Portal。

iii查询指定文件夹中的消息，移动消息到指定的文件夹。用户可以指定查询条件，用户通过Portal查询指定文件夹中的消息，数据管理模块根据文件夹ID在数据库中查找并返回查询结果；用户可以通过Portal将指定的消息移动到指定的文件下，数据管理模块在数据库中将用户需要移动的消息列表所归属的文件夹ID更改为用户指定的文件夹ID，返回操作结果；用户还可以通过各种查询条件如消息的日期范围、阅读状态、收/发件人等进行查询，数据管理模块根据查询的条件组合在数据库中进行查询，并将查询的结果返回给用户。

iv获取消息列表，以及获取短消息/多媒体消息/UM消息的详细内容；用户可以通过Portal获得SMS/MMS/UM消息的列表，并根据列表指定查看相应消息的详细信息。用户通过Portal，从数据管理模块中查询到相应用户的消息列表，并根据查询的列表结果，查询指定的消息内容，数据管理模块根据用户提交的消息ID从数据库中查询相应的消息摘要信息并返回给用户，如果是UM消息，UMC会向UM服务器提交查询消息详细内容请求，以获得UM消息的主体，并将结果返回给用户。

普通用户对文件夹的管理：

UMC提供的WSI接口是以文件夹的形式对消息进行归类管理的，普通用户登录Portal后，可以通过Portal对UMC的文件夹进行管理，包括：

i获得同层的文件夹的列表；

ii添加/删除/移动/重命名文件夹；

iii设置/取消文件夹的密码(这里所设置的密码针对同一用户的所有文件夹)；

iv设置/取消文件夹的密码标识(每一个文件夹都有自己的标识)；

v获得指定文件夹下的所有消息的容量；

vi设置/取消/获得文件夹的激活信息；

普通用户登录Portal后，在相关的操作页面中提交操作请求，Portal将向UMC提交执行请求，数据管理模块在数据库中根据用户ID和文件夹ID等相关的输入数据，执行查询/修改和删除操作，并将执行结果返回给Portal。

(2)超级用户对消息及文件夹的管理：

超级用户登录Portal后，可以进行的操作有：

i超级用户向指定的用户添加消息，包括短消息/多媒体消息；超级用户通过Portal，向指定用户提交SMS/MMS消息，数据管理模块收到添加消息后，会将该SMS/MMS消息添加到数据库中，并返回操作结果给超级用户。

ii获得指定用户的文件夹密码；超级用户通过Portal，向UMC查询指定用户的文件夹密码，数据管理模块在数据库中查找文件夹的密码后返回给超级用户。

iii重新设置指定用户的文件夹密码；超级用户通过Portal，向UMC提起修改指定用户的文件夹密码请求，数据管理模块在数据库中更新文件夹的密码后将操作结果返回给超级用户。

iv修改/删除/查询用户的套餐信息；超级用户通过Portal，向UMC提起修改/删除/查询用户套餐信息的请求消息，数据管理模块从数据库中修改/删除/查询用户的套餐信息，并将操作的结果返回给超级用户。

v同步用户的附加号码；UMC支持用户一卡多号的功能，即一个用户可以有多个号码：主号/Fax(传真号)/ALS(附号)。超级用户可以通过Portal页面提交请求，用户管理模块在数据库中将Fax/ALS号附加到指定的用户主号下。

(3)用户的容量管理

UMC支持对用户的消息存储提供容量管理功能。用户在订购业务套餐时，包含了容量信息，包括最小容量值，即用户定购使用的最小值，在这个容量使用范围之内，用户只需支付基本的包月费；用户所定制的套餐还包括最大容量，当用户当前的消息存储容量已达到最大上限时，用户不可以再向UMC中存储消息。当用户的消息容量已接近最小容量值时，系统会写容量告警话单，并向Portal发出容量告警，这个容量值取决于用户订购业务套餐中的最小容量和UMC系统所配置的最小容量阀值。而达到最小容量阀值和最大容量阀值时，UMC也同样会写容量告警话单并向Portal发送告警。当用户的当前消息容量大于最小容量后，UMC会对用户的容量超出部分按日和超出容量进行计费，生成计费话单，通过第三方FTP工具，将计费话单传送至BOSS系统，BOSS系统会根据UMC生成的计费话单对用户进行计费。

4)计费管理流程：

UMC支持后付费用户的计费，Provision System每月会对已订购UMC业务的用户进行月租费扣除，而用户在超出最小订购容量时，UMC在每天配置的时间点进行用户容量的检查并对超出最小订购容量的用户进行计费、写话单，根据该话单，BOSS系统将对该部分用户进行相应的扣费操作。UMC提供可靠的准确无重复的计费话单。由于UMC只存储UM消息的摘要信息，并对UM消息进行消息容量管理，因此UMC可以对UM消息按照用户定购的业务套餐类型来计费，这样的方式有利于根据用户的实际需要来对UM进行计费，而用户可以对所订购业务进行更改，并且配合SMS/MMS消息的存储容量管理，可以由用户自行管理各种消息的容量比例，从而实现灵活的计费模式。

基于同一技术构思，本发明实施例还提供第二种消息处理系统，如图10所示，该消息处理系统包括：消息转发设备21、消息存储设备22和业务服务器SS(Service Server)23，其中：

业务服务器23分别连接消息转发设备21和消息存储设备22，用于接收用户设置和管理的业务信息并转发给消息转发设备21，以及将用户对存储的消息进行操作的指令转发给消息存储设备22；用户的业务信息可以包括定制存储所有发送的消息和/或接收的消息等，或者对特定对象发送和/或接收的消息进行存储等。

消息转发设备21接收到用户消息时，根据存储的用户身份信息及对应的业务信息，直接对消息中包含的用户身份信息进行鉴权，如果鉴权通过，则将消息发送给消息存储设备22进行存储；消息转发设备21例如：短消息业务中心、多媒体消息业务中心或UM消息服务器等；

消息存储设备22收到消息转发设备21发送的消息后，根据用户身份信息分别存储，消息存储设备22例如消息存储中心MC(Message Center)。

本发明实施例提供的第二种消息处理系统的具体实施1如图11所示，其中：

消息转发设备包括：

第二接口模块211，用于接收用户的消息数据，该消息数据中包含用户身份信息；

消息处理模块212，用于对应管理各用户的身份信息及业务信息，并对所述消息信息中包含的用户身份信息进行鉴权，以及将通过业务鉴权的用户身份信息及对应的消息数据发送给所述消息存储设备；

第三接口模块213，用于和所述消息存储设备通信；

备份设置接口模块214，用于和业务服务器23通信；

所述消息存储设备22包括：

第四接口模块221，用于和所述消息转发设备通信；

第二存储模块222，用于从所述消息转发设备接收的消息数据，消息数据是对应用户身份信息存储的；

存储控制模块223，用于接收来自所述消息转发设备的用户身份信息及对应的消息数据并存储到第二存储模块222中，并根据用户的操作指令管理第二存储模块222中存储的用户消息数据。

业务管理接口模块224，用于和业务服务器23通信；

该具体实施例中，消息转发设备可以是短消息业务中心或多媒体消息业务中心。

参阅图12，第二种消息处理系统的具体实施例2中，业务服务器23分别连接短消息业务中心21a和多媒体消息业务中心21b，短消息业务中心21a和多媒体消息业务中心21b分别连接消息存储设备22，将用户需要存储的短消息或多媒体消息发送给MC进行存储。

Claims

1、一种消息处理设备，其特征在于，包括：

数据管理模块，用于管理用户的消息数据；

2、根据权利要求1所述的设备，其特征在于，所述第一接口模块至少包括如下之一：

3、根据权利要求2所述的设备，其特征在于：

当所述第一接口模块中包括短消息实时接口单元时，所述第一接口模块中还包括：短消息文件接口单元，用于从短消息FTP服务器接收短消息缓存文件，所述数据管理模块将该短消息缓存文件中包含的短消息存入所述第一存储模块；和/或

当所述第一接口模块中包括多媒体消息实时接口单元时，所述第一接口模块中还包括：多媒体消息文件接口单元，用于从多媒体消息FTP服务器接收多媒体消息缓存文件，所述数据管理模块将该多媒体消息缓存文件中包含的多媒体消息存入所述第一存储模块。

4、根据权利要求1所述的设备，其特征在于，该设备还包括：Portal接口单元，与所述数据管理模块连接，用于与Portal服务器进行通信。

5、根据权利要求1所述的设备，其特征在于，该设备还包括：

计费模块，与所述数据管理模块连接，用于根据用户在消息处理设备中使用的消息数据存储空间来计算用户的使用费用；

计费接口单元，与所述计费模块连接，用于与计费子系统进行通信。

6、根据权利要求1所述的设备，其特征在于，该设备还包括：用户业务管理接口单元，与所述用户管理模块连接，用于与用户业务管理子系统进行通信。

7、根据权利要求1所述的设备，其特征在于，该设备还包括：消息缓存模块，与所述数据管理模块连接，用于缓存待存入消息存储模块中的消息数据。

8、一种消息处理系统，包括消息转发设备，其特征在于，所述系统还包括：消息处理设备，用于从所述消息转发设备接收包含用户身份信息的用户消息数据，并根据对应管理的用户身份信息及业务信息鉴权所述消息信息中包含的用户身份信息；以及存储并管理通过鉴权的用户身份信息对应的消息数据，所述消息数据是对应用户的身份信息存储的。

9、根据权利要求8所述的处理系统，其特征在于，所述消息转发设备至少包括如下之一：短消息业务中心、多媒体消息业务中心、统一消息业务服务器。

10、根据权利要求9所述的处理系统，其特征在于：

当所述消息转发设备包括短消息业务中心时，所述系统还包括：短消息FTP服务器，用于存储短消息缓存文件，所述短消息缓存文件包括消息处理设备存储失败的短消息和短消息业务中心向消息处理设备发送失败的短消息，所述消息处理设备从该短消息FTP服务器获取所述短消息缓存文件，并存储该短消息缓存文件中包含的短消息；和/或

当所述消息转发设备包括多媒体消息业务中心时，所述系统还包括：多媒体消息FTP服务器，用于存储多媒体消息缓存文件，所述多媒体消息缓存文件包括消息处理设备存储失败的多媒体消息和多媒体消息业务中心向消息处理设备发送失败的多媒体消息，所述消息处理设备从该多媒体消息FTP服务器获取所述多媒体消息缓存文件，并存储该多媒体消息缓存文件中包含的多媒体消息。

11、根据权利要求8所述的处理系统，其特征在于，所述系统还包括：Portal服务器，与所述消息处理设备连接，用于为用户提供管理平台，对消息处理设备中存储的消息进行管理。

12、根据权利要求8所述的处理系统，其特征在于，所述系统还包括：计费子系统，与所述消息处理设备连接，用于接收消息处理设备发送的用户的使用费用信息，并根据该使用费用信息进行费用管理。

13、根据权利要求8所述的处理系统，其特征在于，所述系统还包括：用户业务管理子系统，与所述消息处理设备连接，用于对用户的业务信息进行管理。

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

接收用户的消息数据，该消息数据中包含用户身份信息；

15、根据权利要求14所述的方法，其特征在于，所述用户的消息数据包括：从短消息业务中心接收的短消息。

16、根据权利要求15所述的方法，其特征在于，所述方法还包括：

在存储失败所述从短消息业务中心接收的短消息时向短消息业务中心发送失败响应消息，并获取短消息业务中心根据失败响应消息生成的短消息缓存文件，该短消息缓存文件中包括所述存储失败的短消息；

存储该短消息缓存文件中包含的短消息。

17、根据权利要求15或16所述的方法，其特征在于，所述方法还包括：

获取短消息业务中心在短消息发送失败时生成的短消息缓存文件，该短消息缓存文件包含所述发送失败的短消息；

存储该短消息缓存文件中的短消息。

18、根据权利要求14所述的方法，其特征在于，所述用户的消息数据包括：从多媒体消息业务中心接收的用户多媒体消息。

19、根据权利要求18所述的方法，其特征在于，所述方法还包括：

在存储失败所述从多媒体消息业务中心接收的多媒体消息时向多媒体消息业务中心发送存储失败响应消息，并获取多媒体消息业务中心根据失败响应消息生成的多媒体消息缓存文件，该多媒体消息缓存文件包含所述存储失败的多媒体消息；

存储该多媒体消息缓存文件中包含的多媒体消息。

20、根据权利要求18或19所述的方法，其特征在于，所述方法还包括：

获取多媒体消息业务中心在多媒体消息发送失败时生成的多媒体消息缓存文件，该多媒体消息缓存文件中包含所述发送失败的多媒体消息；

存储该多媒体消息缓存文件中包含的多媒体消息。

21、根据权利要求14或18所述的方法，其特征在于，所述用户的消息数据还包括：从统一消息业务服务器接收的用户统一消息的摘要信息。

22、根据权利要求14所述的处理方法，其特征在于，所述方法还包括：接收用户的操作指令，并根据该操作指令对存储的消息数据执行相应的操作。

23、根据权利要求14所述的处理方法，其特征在于，所述方法还包括：接收用户业务信息的订购、变更或取消操作，并更新对应管理的用户身份信息及业务信息。

24、根据权利要求14所述的处理方法，其特征在于，所述方法还包括：根据用户的消息数据占用的存储空间对用户进行计费。

25、一种消息处理系统，包括消息转发设备和消息存储设备，其特征在于，所述消息转发设备包括：

第三接口模块，用于和所述消息存储设备进行通信；

所述消息存储设备包括：

第四接口模块，用于和所述消息转发设备进行通信；

第二存储模块，用于存储用户身份信息及对应的消息数据。

26、根据权利要求25所述的系统，其特征在于，所述消息转发设备包括：短消息业务中心和/或多媒体消息业务中心。

27、根据权利要求25所述的系统，其特征在于，所述系统还包括：业务服务器，用于将各用户的身份信息及业务信息发送给所述消息处理模块；以及为用户提供管理平台，通过所述存储控制模块对第二存储模块中的消息数据进行管理。

28、一种消息转发设备，包括第二接口模块，用于接收用户的消息数据，该消息数据中包含用户身份信息，其特征在于，所述消息转发设备还包括：

第三接口模块，用于和所述外部存储设备进行通信。

29、根据权利要求28所述的消息转发设备，其特征在于，所述消息转发设备还包括：备份设置接口模块，用于接收所述用户身份信息及业务信息，并转发给所述消息处理模块。

30、根据权利要求29所述的消息转发设备，其特征在于，所述消息转发设备包括：短消息业务中心或多媒体消息业务中心。