CN103259810B - 一种交互式多媒体消息处理方法、装置以及系统 - Google Patents

Abstract

本发明公开了一种交互式多媒体消息处理方法、装置以及系统，该方法包括：根据用于描述操作过程的业务信息中能够生成微技widget应用的第一业务信息，生成第一widget应用；并根据生成的第一widget应用以及用于描述操作过程的业务信息中不能够生成widget应用的第二业务信息，创建交互式多媒体消息，并将创建的所述交互式多媒体消息发送给移动终端；接收移动终端根据所述多媒体消息中携带的第二业务信息，执行所述多媒体消息中携带的第一widget应用对应的操作后反馈的请求消息；并对接收到的请求消息进行相应响应。该方案操作流程非常简单。

Description

一种交互式多媒体消息处理方法、装置以及系统

技术领域

本发明涉及移动通信技术领域，尤指一种交互式多媒体消息处理方法、装置以及系统。

背景技术

随着移动通信技术的飞速发展，多媒体消息服务(MultimediaMessagingService，MMS)已经成为移动数据业务用户和运营商越来越关注的业务功能。多媒体消息支持多媒体功能，能够传递包括图像、音频、视频、数据、文本等文件的内容和信息。

尽管多媒体消息能够传递丰富多彩的多媒体内容和信息，但是传统的多媒体消息只包含广播式的静态信息，并不具备直接交互的功能。这也就使得用户仅可以实现很好的阅读体验，但是没办法进行交互性操作，限制多媒体消息的业务使用范围。例如：在航空订票时，当用户定完机票后会通过移动终端收到一条多媒体消息，该多媒体消息包括航班名称、起飞时间、起飞地点、降落时间、降落地点等信息，并且附带一条链接，用户点击该链接通过浏览器登陆航空公司网站办理乘机手续，预定座位。可见，现有流程中用户需要启动浏览器、输入身份证号等一系列信息、找到登机手续办理页面后，才能预定座位，流程非常繁琐。而在现有技术中缺少能够提供给用户直接进行操作的交互式多媒体消息的方案。

发明内容

本发明实施例提供一种交互式多媒体消息处理方法、装置以及系统，用以提供给用户直接进行操作的交互式多媒体消息方案。

一种交互式多媒体消息处理方法，包括：

根据用于描述操作过程的业务信息中能够生成微技widget应用的第一业务信息，生成第一widget应用；并

根据生成的第一widget应用以及用于描述操作过程的业务信息中不能够生成widget应用的第二业务信息，创建交互式多媒体消息，并将创建的所述交互式多媒体消息发送给移动终端；

接收移动终端根据所述多媒体消息中携带的第二业务信息，执行所述多媒体消息中携带的第一widget应用对应的操作后反馈的请求消息；并

对接收到的请求消息进行相应响应。

一种交互式多媒体消息处理方法，包括：

接收到交互式多媒体消息后，解析所述交互式多媒体消息中携带的业务信息和widget应用；并

显示解析得到的业务信息和解析得到的所述widget应用对应的操作；

在显示的操作根据现实的业务信息被执行后，生成对应的请求消息发送到网络侧；并

接收网络侧针对所述请求消息反馈的响应结果。

一种交互式多媒体消息处理装置，包括：

应用生成单元，用于根据用于描述操作过程的业务信息中能够生成微技widget应用的第一业务信息，生成第一widget应用；

消息创建单元，用于根据所述应用生成单元生成的第一widget应用以及用于描述操作过程的业务信息中不能够生成widget应用的第二业务信息，创建交互式多媒体消息，并将创建的所述交互式多媒体消息发送给移动终端；

消息接收单元，用于接收移动终端根据所述多媒体消息中携带的第二业务信息，执行所述多媒体消息中携带的第一widget应用对应的操作后反馈的请求消息；

消息响应单元，用于对所述消息接收单元接收到的请求消息进行相应响应。

一种交互式多媒体消息处理装置，包括：

消息接收单元，用于接收交互式多媒体消息；

消息解析单元，用于所述消息接收单元接收到交互式多媒体消息后，解析所述交互式多媒体消息中携带的业务信息和widget应用；

应用显示单元，用于显示所述消息解析单元解析得到的业务信息和解析得到的所述widget应用对应的操作；

消息生成单元，用于在所述应用显示单元显示的操作根据显示的业务信息被执行后，生成对应的请求消息发送到网络侧；

响应结果接收单元，用于接收网络侧针对所述请求消息反馈的响应结果。

一种移动终端，包括上述的交互式多媒体消息处理设备。

一种通信系统，包括上述的交互式多媒体消息处理装置、多媒体消息交换服务器、无线应用协议WAP网关；

所述交互式多媒体消息处理装置，用于根据用于描述操作过程的业务信息中能够生成微技widget应用的第一业务信息，生成第一widget应用；并根据生成的第一widget应用以及用于描述操作过程的业务信息中不能够生成widget应用的第二业务信息，创建交互式多媒体消息，并将创建的所述交互式多媒体消息通过所述多媒体消息交换服务器和WAP网关发送给移动终端；接收移动终端根据所述多媒体消息中携带的第二业务信息，执行所述多媒体消息中携带的第二widget应用对应的操作后反馈的请求消息；并对接收到的请求消息进行相应响应。

本发明实施例提供的交互式多媒体消息处理方法、装置以及系统，该方案根据用于描述操作过程的业务信息中能够生成微技widget应用的第一业务信息，生成第一widget应用；并根据生成的第一widget应用以及用于描述操作过程的业务信息中不能够生成widget应用的第二业务信息，创建交互式多媒体消息，并将创建的所述交互式多媒体消息发送给移动终端；接收移动终端根据所述多媒体消息中携带的第二业务信息，执行所述多媒体消息中携带的第二widget应用对应的操作后反馈的请求消息；并对接收到的请求消息进行相应响应。这样移动终端可以直接根据接收到的交互式多媒体消息执行相应的操作，操作流程非常简单，不用像现有技术一样需要点击链接，通过启动浏览器来进行操作，避免了繁琐的操作流程。

附图说明

图1为本发明实施例中交互式多媒体消息处理方法的流程图；

图2为本发明实施例中移动终端接收到的交互式多媒体消息的结构示意图；

图3为现有技术中的WACWidget的结构图；

图4为现有技术中的Widget引擎的框架图；

图5为本发明实施例中创建交互式多媒体消息的方法流程图；

图6为现有技术中的多媒体消息的结构示意图；

图7为现有技术中的移动终端到移动终端的多媒体消息业务模型的结构示意图；

图8为本发明实施例中的交互式多媒体消息的结构示意图；

图9为本发明实施例中移动终端接收到的交互式多媒体消息后的方法流程图；

图10为本发明实施例中交互式多媒体消息处理装置的结构示意图；

图11为本发明实施例中可设置在移动终端中的交互式多媒体消息处理装置的结构示意图；

图12为本发明实施例中的移动终端的结构示意图；

图13为本发明实施例中的通信系统的结构示意图。

具体实施方式

针对现有技术中存在的缺少能够提供给用户直接进行操作的交互式多媒体消息的方法的问题，本发明实施例提供一种交互式多媒体消息处理方法，该方法的流程如图1所示，具体执行步骤如下：

S10：根据用于描述操作过程的业务信息中能够生成微技widget应用的第一业务信息，生成第一widget应用。

交互式多媒体消息中可以包含widget应用、图片、文本、视频、音频等文件。如果要在交互式多媒体消息中完成背景技术提到的用户机票购买成功通知和办理登记手续的操作、进行投票的操作等等，就需要有描述该操作过程的业务信息，所需的业务信息可以是用于生成widget应用需要的业务信息、图片、文本、视频、音频等等。在生成交互式多媒体消息时，首先需要生成第一widget应用，用于生成第一widget应用的业务信息为第一业务信息，第一业务信息可以是一段程序代码，当然也可以采用其他的方式。

S11：根据生成的第一widget应用以及用于描述操作过程的业务信息中不能够生成widget应用的第二业务信息，创建交互式多媒体消息，并将创建的交互式多媒体消息发送给移动终端。

在交互式多媒体消息中所需的业务信息中，除了生成第一widget应用的第一业务信息，其余的业务信息是第二业务信息，可以是图片、文本、视频、音频等等。背景技术的具体使用场景中，将“机票购买成功通知”和“完成登机手续”这两件事合二为一的多媒体消息的结构如图2所示。航空公司通过发送多媒体消息通知用户“购票成功”，同时用户可以直接在多媒体消息中选择座位，直接完成登机手续。

S12：接收移动终端根据多媒体消息中携带的第二业务信息，执行多媒体消息中携带的第一widget应用对应的操作后反馈的请求消息。

第二业务信息可以起到注释的作用，向用户说明第一widget应用提供的操作，用户可以根据第二业务信息执行第一widget应用对应的操作。

S13：对接收到的请求消息进行相应响应。

上述方案可以向移动终端发送可提供移动终端直接进行操作的交互式多媒体消息，移动终端接收到该交互式多媒体消息后可以直接根据接收到的多媒体消息执行相应的操作，操作流程非常简单，不用像现有技术一样需要点击链接，通过启动浏览器来进行操作，避免了现有技术中的繁琐的操作流程。

下面介绍widget技术的原理：

Widget是一种基于互联网Web技术的小应用，采用JavaScript、Html、CSS及Ajax等标准Web技术进行开发，具备开发快捷、体积小巧、界面华丽、用户体验良好、资源消耗少等优点，适合于娱乐、工作、资讯、游戏、学习等多种用途，现在已经在各种桌面操作系统上得到了广泛的应用。随着移动终端应用技术的发展，Widget在移动领域也越来越受到广泛的关注，已形成了移动终端上新的应用形式一移动微技(MobileWidget)。

Mobilewidget结合了移动终端和移动互联网应用的特点，为移动终端用户带来良好的呈现方式和互联网体验。Mobilewidget具有界面个性化、小巧轻便、开发门槛低、潜在开发者众多、跨平台运行和功能完整的特点，有助于降低业务或应用开发和部署的成本，并极大丰富移动互联网应用的数量。

目前，最具影响力的MobileWidget标准是应用批发社区微技(WACWidget)。下面以应用批发社区WACWidget为例，介绍Widget的技术原理。

WACWidget文件的扩展名为“.wgt”，是一个符合zip压缩规范的打包文件，每个Widget程序包必须存在至少一个HTML文件作为Widget的入口，并通过config.xml的content属性进行定义。与工程类似，Widget可以包含JavaScript文件和CSS文件，同类文件可以被置入同一个文件夹。WACWidget典型结构如图3所示。

WACWidget文件所支持Web技术的最低版本标准如下：

ECMAScript-262第3版；

XHTML1.1；

CSS2.0；

SVGTiny1.2；

DOMLevel2。

一个WACWidget所包含的文件和文件夹包括：

HTML文件：.html；

CSS资源文件：.css；

JavaScript逻辑文件：.js；

图标文件：icon.png；

Manifest文件：config.xml；

签名文件。

Widget应用需要有解析器才能运行，称其为：Widget引擎。Widget应用与Widget引擎的关系可以简单地与Java技术中的Java应用和Java虚拟机作类比。Widget是运行于Widget引擎之上的应用程序，它用Web技术来创建：用HTML来呈现内容，用CSS来定制风格，用JavaScript来表现逻辑。Widget应用汲取了基于BS和CS架构应用的各自优点。它并不完全依赖网络，软件框架可以存在本地，而内容资源从网络获取，程序代码和UI设计同样可以从专门的服务器更新，保留了BS架构的灵活性。基于Web技术的特征使得Widget具有小巧轻便、易于开发、与操作系统耦合度低和功能完整等特点。Widget引擎的框架如图4所示。

上面介绍了widget应用的基本原理，下面详细介绍上述方法流程中的各个步骤。

具体的，上述S11中的根据生成的第一widget应用以及用于描述操作过程的业务信息中不能够生成widget应用的第二业务信息，创建交互式多媒体消息的过程，其流程如图5所示，具体包括如下步骤：

S50：指示widget签名服务器在生成的第一widget应用中添加应用标识信息和签名信息。

由widget签名服务器为Widget应用分配唯一的应用标识信息(WidgetID)，填写在Widget应用的配置文件config.xml的ID字段，并对Widget应用进行签名。

S51：根据添加应用标识信息和签名信息后的第二widget应用以及用于描述操作过程的业务信息中不能够生成widget应用的第二业务信息，创建交互式多媒体消息。

相应的，上述S13中的对接收到的请求消息进行相应响应，包括：指示widget签名服务器验证接收到的请求消息中携带的应用标识信息和签名信息是否与在生成的第一widget应用中添加应用标识信息和签名信息一致，并根据widget签名服务器的验证结果，对接收到的请求消息进行相应响应。

具体的，上述S50中的widget签名服务器在生成的第一widget应用中添加应用标识信息和签名信息，包括：widget签名服务器为生成的第一widget应用分配应用标识信息，以及根据生成第一widget应用的第一业务信息获取签名信息；在第一widget应用中添加分配的应用标识信息和获取的签名信息。

签名信息是根据第一业务信息计算得到的，这样就可以防止widget应用的程序代码被篡改，确定widget应用的合法行。

具体的，上述根据添加应用标识信息和签名信息后的第二widget应用以及第二业务信息，创建交互式多媒体消息，有两种以下方式：

第一种：确定添加应用标识信息和签名信息后的第二widget应用的属性信息以及第二业务信息的属性信息；将确定的属性信息、第二widget应用以及第二业务信息封装成数据包，作为交互式多媒体消息。

下面介绍一下多媒体消息的原理。

1)多媒体消息格式介绍

当多媒体消息(MultimediaMessagingService，MMS)发送的时候，相关信息会被封装成协议数据单元(ProtocolDataUnits，PDU)模型传递，MMSPDU是由消息头(Header)和消息体(Body)组成。Header具体描述了PDU的特定信息，Body是消息的具体内容(Body体是可选的)。大多数MMSPDU只含有Header域，用于建立和维持通信，Body体只用在M-Send.req和M-Retrieve.conf两个数据包中。如图6所示为MMSPDU基本结构。

Header：由一系列的域组成，包括PDU类型、接受方、发送方、发送时间等等信息。

Body：是多个不同类型的多媒体对象组成的，每个对象占据一个部分-Part，消息的组装方式为.application/vnd.wap.multipart.related，此方式说明附件是存在相关顺序的。

最后采用多用途互联网邮件扩展(MultipurposeInternetMailExtensions，MIME)标准将完整的MM打包封装在一起，也就是将SMIL、文本、图像、声音、视频等各个独立部分打包封装在一起，并发送。

2)移动终端到移动终端的多媒体消息业务模型

为实现MMS业务，除了MMS终端和多媒体消息业务中心(MultimediaMessageServiceCenter，MMSC)之外，还需要有WAP网关和短消息业务中心(ShortMessageServiceCenter，SMSC)。MMS终端与WAP网关之间采用无线应用协议(WAP)作为承载发送或提取MM消息；WAP网关和MMSC之间采用HTTP协议传输MM消息；WAP网关和SMSC之间采用短消息端对端协议(ShortMessagePeertoPeer，SMPP)等应用协议传输MM通知或发送报告。如图7显示了该业务模型的逻辑结构。

本发明实施例中的扩展后的包括Widget应用的内嵌型交互式多媒体消息的格式如图8所示。

在交互式多媒体消息中的widget应用的属性信息是用来描述在播放widget应用时的播放顺序、时间等信息的，交互式多媒体消息中的第二业务信息的属性信息是用来描述在播放该第二业务信息时的播放顺序、时间等信息的。交互式多媒体消息的属性信息可以存储在SMIL文件中，也就是其播放方式是以SMIL文档格式表示的。包含Widget应用的交互式多媒体消息的示例如下：

其中root-layout是交互式多媒体消息播放时的布局大小，交互式多媒体消息中包括airchinaCA556001222.wgtWidget内容。在body中的每一个par元素显示为Slideshow的一个slide，其中可以包含多个第二业务信息，例如：图片、文本、视频、音频等等。每个第二业务信息都是一个par元素，每一个par元素都有一个dur属性，指明此slide播放的时间。

第二种：确定第二业务信息的属性信息；将确定的属性信息以及第二业务信息封装成数据包，作为交互式多媒体消息，并将第二widget应用作为交互式多媒体消息的附件添加到交互式多媒体消息中。

这种交互式多媒体消息可以称为附件型交互式多媒体消息，其创建过程与内嵌型交互式多媒体消息的实现方案相同，只是Widget应用是作为附件添加到交互式多媒体消息中的。

具体的，上述根据widget签名服务器的验证结果，对接收到的请求消息进行相应响应，包括：当验证接收到的请求消息中携带的应用标识信息和签名信息与在生成的第一widget应用中添加应用标识信息和签名信息一致时，应答移动终端发送的请求信息；当验证不一致时，拒绝移动终端发送的请求信息，并向移动终端返回验证失败信息。

继续沿用上例，接收用户点击移动终端显示的如图2所示的Widget应用呈现业务页面中的“确认”后发送的携带签名信息以及唯一的WidgetID的请求信息，并指示签名服务器验证签名信息以及唯一的WidgetID，当接收到签名服务器验证该应用中携带的签名信息以及唯一的WidgetID与在生成的第一widget应用中添加应用标识信息和签名信息一致时，也就是说验证该widget应用合法后，返回“验证成功”的信息后，根据移动终端的请求信息，完成“乘机手续”手续，并返回“乘机手续”成功的信息给移动终端端；当接收到签名服务器返回“验证失败”信息后，将“签名信息与应用ID不合法”的信息返回给移动终端。

基于同一发明构思，本发明实施例提供一种交互式多媒体消息处理方法，该方法的流程如图9所示，具体包括如下步骤：

S90：接收到交互式多媒体消息后，解析交互式多媒体消息中携带的业务信息和widget应用；并显示解析得到的业务信息和解析得到的widget应用对应的操作。

根据业务信息的格式的不同，解析的方法和工具也是不同的，widget应用是由widget引擎来解析的，同时还可以完成执行和显示widget应用对应的操作，将widget应用显示为可阅读的形式。

S91：在显示的操作根据显示的业务信息被执行后，生成对应的请求消息发送到网络侧；并接收网络侧针对请求消息反馈的响应结果。

较佳的，还包括：解析widget应用中添加的应用标识信息和签名信息；在生成的请求消息中添加解析得到的应用标识信息和签名信息。

当widget应用中携带了应用标识信息和签名信息时，widget引擎还可以解析widget应用中的应用标识信息和签名信息。

网络侧可以向移动终端返回“乘机手续”成功的信息以表示完成所请求的操作；或者返回“签名信息与应用ID不合法”的信息以表示拒绝所请求的操作。

基于同一发明构思，本发明实施例提供一种交互式多媒体消息处理装置，该装置的结构如图10所示，包括：

应用生成单元101，用于根据用于描述操作过程的业务信息中能够生成微技widget应用的第一业务信息，生成第一widget应用。

消息创建单元102，用于根据应用生成单元生成的第一widget应用以及用于描述操作过程的业务信息中不能够生成widget应用的第二业务信息，创建交互式多媒体消息，并将创建的交互式多媒体消息发送给移动终端。

消息接收单元103，用于接收移动终端根据多媒体消息中携带的第二业务信息，执行多媒体消息中携带的第一widget应用对应的操作后反馈的请求消息。

消息响应单元104，用于对消息接收单元接收到的请求消息进行相应响应。

具体的，上述消息创建单元102，用于指示widget签名服务器在生成的第一widget应用中添加应用标识信息和签名信息；根据添加应用标识信息和签名信息后的第二widget应用以及用于描述操作过程的业务信息中不能够生成widget应用的第二业务信息，创建交互式多媒体消息。

上述消息响应单元104，用于指示widget签名服务器验证接收到的请求消息中携带的应用标识信息和签名信息是否与在生成的第一widget应用中添加应用标识信息和签名信息一致，并根据widget签名服务器的验证结果，对接收到的请求消息进行相应响应。

具体的，上述消息创建单元102，用于指示widget签名服务器为生成的第一widget应用分配应用标识信息，以及根据生成第一widget应用的第一业务信息获取签名信息；在第一widget应用中添加分配的应用标识信息和获取的签名信息。

具体的，上述消息创建单元102，用于确定添加应用标识信息和签名信息后的第二widget应用的属性信息以及第二业务信息的属性信息；将确定的属性信息、第二widget应用以及第二业务信息封装成数据包，作为交互式多媒体消息。

具体的，上述消息创建单元102，用于确定第二业务信息的属性信息；将确定的属性信息以及第二业务信息封装成数据包，作为交互式多媒体消息，并将第二widget应用作为交互式多媒体消息的附件添加到交互式多媒体消息中。

具体的，上述消息响应单元104，用于当验证接收到的请求消息中携带的应用标识信息和签名信息与在生成的第一widget应用中添加应用标识信息和签名信息一致时，应答移动终端发送的请求信息；当验证不一致时，拒绝移动终端发送的请求信息，并向移动终端返回验证失败信息。

基于同一发明构思，本发明实施例提供一种交互式多媒体消息处理装置，该装置可以设备在移动终端中，该装置的结构如图11所示，包括：

消息接收单元110，用于接收交互式多媒体消息。

消息解析单元111，用于消息接收单元110接收到交互式多媒体消息后，解析交互式多媒体消息中携带的业务信息和widget应用。

应用显示单元112，用于显示消息解析单元111解析得到的业务信息和解析得到的widget应用对应的操作。

消息生成单元113，用于在应用显示单元112显示的操作根据显示的业务信息被执行后，生成对应的请求消息发送到网络侧。

响应结果接收单元114，用于接收网络侧针对所述请求消息反馈的响应结果。

较佳的，该装置还包括信息处理单元115，用于解析消息解析单元111解析出的widget应用中添加的应用标识信息和签名信息；并在消息生成单元113生成的请求消息中添加解析得到的应用标识信息和签名信息。

基于同一发明构思，本发明实施例提供一种移动终端，该移动终端包括如图11所示的交互式多媒体消息创建装置。

较佳的，移动终端的结构如图12所示，可以包括：

操作系统是移动终端的基础，为移动终端提供系统服务和程序的运行环境。

WAP协议栈为MMS移动终端与多媒体消息中心建立通信连接的必备协议支持。

用户界面通过和用户的交互适时地调用MMS客户端提供的接口，从而可以直观地看到多媒体消息收发的结果。

通用分组无线无线服务技术(GeneralPacketRadioService，GPRS)拨号器：提供GPRS网络的拨通与挂断能力。

PDU编解码器：多媒体消息收发过程中处理所有层面PDU的接口，需要增加对Widget格式的识别。

多媒体消息发送器：是多媒体消息发送过程中一系列动作的触发者和协调者。完成多媒体消息构造、GPRS拨号、多媒体消息发送、GPRS挂断等动作。该多媒体消息发送器可以实现图11中的消息生成单元113的。

多媒体消息接收器：完成多媒体消息通知的地址解析、触发GPRS拨通、多媒体消息接收、GPRS挂断等动作。该多媒体消息接收器可以实现图11中的消息接收单元110和响应结果接收单元114的功能。

多媒体消息阅读器：将多媒体消息接收器接收到的多媒体消息解开成可阅读的形式。可包括Widget引擎，它负责多媒体消息中Widget内容的解析、执行、呈现，包括对Widget签名的验证。

PDU编解码器和多媒体消息阅读器可以实现图11中的消息解析单元111、应用显示单元112和信息处理单元115的功能。

用户操作widget应用呈现的界面时，可以通过wifi、2/3G等网络接入方式，来完成数据交互。

基于同一发明构思，本发明实施例提供一种通信系统，该系统的结构如图5所示，包括如图13所示的交互式多媒体消息处理装置131、多媒体消息交换服务器132、WAP网关133。

上述交互式多媒体消息处理装置131，用于根据用于描述操作过程的业务信息中能够生成微技widget应用的第一业务信息，生成第一widget应用；并根据生成的第一widget应用以及用于描述操作过程的业务信息中不能够生成widget应用的第二业务信息，创建交互式多媒体消息，并将创建的交互式多媒体消息通过多媒体消息交换服务器和WAP网关发送给移动终端134；接收移动终端根据多媒体消息中携带的第二业务信息，执行多媒体消息中携带的第二widget应用对应的操作后反馈的请求消息；并对接收到的请求消息进行相应响应。

较佳的，该系统还包括：签名服务器135，用于在交互式多媒体消息处理装置131生成的第一widget应用中添加应用标识信息和签名信息。

相应的，上述交互式多媒体消息处理装置131，具有用于根据添加应用标识信息和签名信息后的第二widget应用以及用于描述操作过程的业务信息中不能够生成widget应用的第二业务信息，创建交互式多媒体消息。

上述签名服务器135，还用于验证交互式多媒体消息处理装置131接收到的请求消息中携带的应用标识信息和签名信息是否与在生成的第一widget应用中添加应用标识信息和签名信息一致。

上述交互式多媒体消息处理装置，具体用于根据widget签名服务器的验证结果，对接收到的请求消息进行相应响应。

较佳的，上述系统还包括多媒体消息业务平台136；上述多媒体消息处理装置将创建的交互式多媒体消息通过多媒体消息业务平台、多媒体消息交换服务器和WAP网关发送给移动终端。

可以直接由网络运营商生成交互式多媒体消息，也可以由网络运营商许可第三方，由第三方生成交互式多媒体消息，并通过互式多媒体消息业务平台来接收第三方提交的交互式多媒体消息，然后再由网络运营商向移动终端进行发送。

交互式多媒体消息的生命周期可以分为三个阶段：创建阶段、传输阶段、接收阅读阶段。

在创建交互式多媒体消息时，可以由交互式多媒体消息处理装置和签名服务器来实现，也可以有业务服务器、widget生成工具、多媒体消息创建工具和签名服务器来实现，也就是说交互式多媒体消息处理装置可以设置为一个装置，也可以设置为三个装置，这三个装置组合起来就可以实现一个交互式多媒体消息处理装置的功能。其中业务服务器是业务信息和服务的承载平台；Widget生成工具可以将第一业务信息生成Widget应用；签名服务器可以为Widget应用分配唯一的WidgetID，同时对Widget应用进行签名；多媒体消息创建工具可以支持交互式多媒体消息的创建，可以在交互式多媒体消息中添加音频、图片、Widget应用等内容。

在传输交互式多媒体消息时，可以由网络运营商直接通过多媒体消息交换服务器和WAP网关发送给移动终端；也可以通过多媒体消息业务平台、多媒体消息交换服务器和WAP网关发送给移动终端。其中，多媒体消息业务平台是由运营商向第三方开放的可以提交交互式多媒体消息的平台；多媒体消息交换服务器负责交互式多媒体消息存储和转发；WAP网关将交互式多媒体消息下发给移动终端。

在接收阅读交互式多媒体消息阶段，由移动终端接收、提供给用户可阅读的交互式多媒体消息。其中，移动终端可以解析并显示交互式多媒体消息。

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims (15)

1.一种交互式多媒体消息处理方法，其特征在于，包括：

根据用于描述操作过程的业务信息中能够生成微技widget应用的第一业务信息，生成第一widget应用；并

根据生成的第一widget应用以及用于描述操作过程的业务信息中不能够生成widget应用的第二业务信息，创建交互式多媒体消息，并将创建的所述交互式多媒体消息发送给移动终端；

接收移动终端根据所述多媒体消息中携带的第二业务信息，执行所述多媒体消息中携带的第一widget应用对应的操作后反馈的请求消息；并

对接收到的请求消息进行相应响应；

根据生成的第一widget应用以及用于描述操作过程的业务信息中不能够生成widget应用的第二业务信息，创建交互式多媒体消息，包括：

指示widget签名服务器在生成的第一widget应用中添加应用标识信息和签名信息；

根据添加应用标识信息和签名信息后的第二widget应用以及用于描述操作过程的业务信息中不能够生成widget应用的第二业务信息，创建交互式多媒体消息；

对接收到的请求消息进行相应响应，包括：

指示widget签名服务器验证接收到的所述请求消息中携带的应用标识信息和签名信息是否与在生成的第一widget应用中添加应用标识信息和签名信息一致，并

根据widget签名服务器的验证结果，对接收到的请求消息进行相应响应。

2.如权利要求1所述的方法，其特征在于，widget签名服务器在生成的第一widget应用中添加应用标识信息和签名信息，包括：

widget签名服务器为生成的第一widget应用分配应用标识信息，以及根据生成所述第一widget应用的第一业务信息获取签名信息；

在所述第一widget应用中添加所述分配的应用标识信息和获取的签名信息。

3.如权利要求1所述的方法，其特征在于，根据添加应用标识信息和签名信息后的第二widget应用以及第二业务信息，创建交互式多媒体消息，包括：

确定添加应用标识信息和签名信息后的第二widget应用的属性信息以及第二业务信息的属性信息；

将确定的所述属性信息、第二widget应用以及第二业务信息封装成数据包，作为交互式多媒体消息。

4.如权利要求1所述的方法，其特征在于，根据添加应用标识信息和签名信息后的第二widget应用以及第二业务信息，创建交互式多媒体消息，包括：

确定第二业务信息的属性信息；

将确定的所述属性信息以及第二业务信息封装成数据包，作为交互式多媒体消息，并将第二widget应用作为所述交互式多媒体消息的附件添加到所述交互式多媒体消息中。

5.如权利要求1所述的方法，其特征在于，根据widget签名服务器的验证结果，对接收到的请求消息进行相应响应，包括：

当验证接收到的所述请求消息中携带的应用标识信息和签名信息与在生成的第一widget应用中添加应用标识信息和签名信息一致时，应答移动终端发送的请求信息；

当验证不一致时，拒绝移动终端发送的请求信息，并向移动终端返回验证失败信息。

6.一种交互式多媒体消息处理方法，其特征在于，包括：

接收到交互式多媒体消息后，解析所述交互式多媒体消息中携带的业务信息和widget应用；并

显示解析得到的业务信息和解析得到的所述widget应用对应的操作；

在显示的操作根据显示的业务信息被执行后，生成对应的请求消息发送到网络侧；并

接收网络侧针对所述请求消息反馈的响应结果；

还包括：

解析所述widget应用中添加的应用标识信息和签名信息；

在生成的请求消息中添加解析得到的应用标识信息和签名信息。

7.一种交互式多媒体消息处理装置，其特征在于，包括：

应用生成单元，用于根据用于描述操作过程的业务信息中能够生成微技widget应用的第一业务信息，生成第一widget应用；

消息创建单元，用于根据所述应用生成单元生成的第一widget应用以及用于描述操作过程的业务信息中不能够生成widget应用的第二业务信息，创建交互式多媒体消息，并将创建的所述交互式多媒体消息发送给移动终端；

消息接收单元，用于接收移动终端根据所述多媒体消息中携带的第二业务信息，执行所述多媒体消息中携带的第一widget应用对应的操作后反馈的请求消息；

消息响应单元，用于对所述消息接收单元接收到的请求消息进行相应响应；

所述消息创建单元，具体用于指示widget签名服务器在生成的第一widget应用中添加应用标识信息和签名信息；根据添加应用标识信息和签名信息后的第二widget应用以及用于描述操作过程的业务信息中不能够生成widget应用的第二业务信息，创建交互式多媒体消息；

所述消息响应单元，具体用于指示widget签名服务器验证接收到的所述请求消息中携带的应用标识信息和签名信息是否与在生成的第一widget应用中添加应用标识信息和签名信息一致，并根据widget签名服务器的验证结果，对接收到的请求消息进行相应响应。

8.如权利要求7所述的装置，其特征在于，所述消息创建单元，具体用于指示widget签名服务器为生成的第一widget应用分配应用标识信息，以及根据生成所述第一widget应用的第一业务信息获取签名信息；在所述第一widget应用中添加所述分配的应用标识信息和获取的签名信息。

9.如权利要求7所述的装置，其特征在于，所述消息创建单元，具体用于确定添加应用标识信息和签名信息后的第二widget应用的属性信息以及第二业务信息的属性信息；将确定的所述属性信息、第二widget应用以及第二业务信息封装成数据包，作为交互式多媒体消息。

10.如权利要求7所述的装置，其特征在于，所述消息创建单元，具体用于确定第二业务信息的属性信息；将确定的所述属性信息以及第二业务信息封装成数据包，作为交互式多媒体消息，并将第二widget应用作为所述交互式多媒体消息的附件添加到所述交互式多媒体消息中。

11.如权利要求7所述的装置，其特征在于，所述消息响应单元，具体用于当验证接收到的所述请求消息中携带的应用标识信息和签名信息与在生成的第一widget应用中添加应用标识信息和签名信息一致时，应答移动终端发送的请求信息；当验证不一致时，拒绝移动终端发送的请求信息，并向移动终端返回验证失败信息。

12.一种交互式多媒体消息处理装置，其特征在于，包括：

消息接收单元，用于接收交互式多媒体消息；

消息解析单元，用于所述消息接收单元接收到交互式多媒体消息后，解析所述交互式多媒体消息中携带的业务信息和widget应用；

应用显示单元，用于显示所述消息解析单元解析得到的业务信息和解析得到的所述widget应用对应的操作；

消息生成单元，用于在所述应用显示单元显示的操作根据显示的业务信息被执行后，生成对应的请求消息发送到网络侧；

响应结果接收单元，用于接收网络侧针对所述请求消息反馈的响应结果；

还包括信息处理单元，用于解析消息解析单元解析出的所述widget应用中添加的应用标识信息和签名信息；并在消息生成单元生成的请求消息中添加解析得到的应用标识信息和签名信息。

13.一种移动终端，其特征在于，包括如权利要求12所述的交互式多媒体消息处理装置。

14.一种通信系统，其特征在于，包括交互式多媒体消息处理装置、多媒体消息交换服务器、无线应用协议WAP网关；

所述交互式多媒体消息处理装置，用于根据用于描述操作过程的业务信息中能够生成微技widget应用的第一业务信息，生成第一widget应用；并根据生成的第一widget应用以及用于描述操作过程的业务信息中不能够生成widget应用的第二业务信息，创建交互式多媒体消息，并将创建的所述交互式多媒体消息通过所述多媒体消息交换服务器和WAP网关发送给移动终端；接收移动终端根据所述多媒体消息中携带的第二业务信息，执行所述多媒体消息中携带的第二widget应用对应的操作后反馈的请求消息；并对接收到的请求消息进行相应响应；

还包括签名服务器，用于在交互式多媒体消息处理装置生成的第一widget应用中添加应用标识信息和签名信息；

所述交互式多媒体消息处理装置，具体用于根据添加应用标识信息和签名信息后的第二widget应用以及用于描述操作过程的业务信息中不能够生成widget应用的第二业务信息，创建交互式多媒体消息；

所述签名服务器，还用于验证交互式多媒体消息处理装置接收到的所述请求消息中携带的应用标识信息和签名信息是否与在生成的第一widget应用中添加应用标识信息和签名信息一致；

所述交互式多媒体消息处理装置，具体用于根据签名服务器的验证结果，对接收到的请求消息进行相应响应。

15.如权利要求14所述的系统，其特征在于，还包括多媒体消息业务平台，所述多媒体消息处理装置将创建的所述交互式多媒体消息通过所述多媒体消息业务平台、所述多媒体消息交换服务器和WAP网关发送给移动终端。