CN1988512A - 支持基于应用的多媒体消息发送接收的设备、方法和系统 - Google Patents

Abstract

提出基于应用的多媒体消息的发送设备、接收设备和发送、接收方法以及发送接收系统，该增量多媒体消息的消息体包括多媒体消息的动态数据部分、多媒体消息关联的静态数据指示以及被指示的静态数据和所述动态数据的关联关系。由于该增量多媒体消息可以以动态数据的方式直接发送消息的变化部分，在达到同样通信目的情况下，减少了传输的消息量；并且，由于传输的消息量减小，可以采用短消息通道发送接收该增量多媒体消息，更进一步减小了通信消耗。

Description

支持基于应用的多媒体消息发送接收的设备、方法和系统

技术领域

本发明涉及通信技术领域，特别地涉及一种支持基于应用的多媒体消息的方法、设备和系统。

背景技术

多媒体消息是一种由两个工业标准组织，WAP Forum(WAP论坛)和3GPP(3G Partnership Project：3G伙伴计划)所制订的新的全球化消息通信标准。它最大的特点就是支持多媒体功能，使得多媒体消息，包括文本、图象、动画、音频信息、视频信息等得以传递。多媒体消息(MMS)在信息的容量上比起短消息(SMS)有了巨大的提高，丰富了用户的感受，正在和将要成为网络运营商、服务运营商等的一个新的利润增长点。

多媒体消息被设计成可以在WAP协议的上层运行，它不依赖于任何具体的网络平台，任何可以支持WAP的网络都可以提供多媒体消息，因此多媒体消息可以支持高速电路交换数据业务HSCSD(High Speed CircuitSwitched Data)、通用分组无线业务GPRS(General Packet Radio Service)数据通信、GSM演进的增强数据率业务GSM EDGE(Enhanced Data ratafor GSM Evolution，)、通用移动通信系统UMTS(Universal MobileTelecommunication Systems)，这种多媒体消息的承载平台无关性可以极大地保护运营商的投资。

在图1中，简单示出了多媒体消息的消息结构。其中，多媒体消息包括多媒体消息报头和消息体。多媒体消息报头包括有关将多媒体消息如何从源端发送到接收端的信息，例如源地址、目标地址等信息。多媒体消息体包括几部分，包括媒体对象，例如图象，文本，音频，每个对象占一个单独的部分，以及可选的表示部分。表示部分包含解释应如何提供多媒体内容的指令。

对于如何将表示显现出来的计算机表示语言，现有技术中，有多种备选方案。一种本领域技术人员常使用的表示语言，是同步多媒体集成语言(SMIL)。SMIL(Synchronized Multimedia Integration Language，同步多媒体集成语言)是W3C组织于1998年6月推出的，专为流式多媒体设计的一种基于可扩展标记语言(XML)的语言，可通过时序排列对声音、影像、文字及图形文件进行顺序安排。SMIL是用于多媒体消息表示语言的常用布署。它是将多媒体集成到Web内容的重要方法。可以使用XML语言描述多媒体表示的定时、将超链接与媒体对象关联以及定义屏幕表示的布局。SMIL被看作是一种丰富当前基于文本消息传递技术的方法。SMIL语言包括一组模块，为特定的功能区定义了语义(Semantic)和语法(Syntax)。例如这些模块是布局模块、计时和同步模块以及动画模块。

由以上多媒体消息体结构可知多媒体消息被定义成表达文本、图片、视频等信息给用户的一种消息，随着多媒体消息的普及，很多内容提供商都将自己的应用封装成多媒体消息，用于和用户交流，例如基于多媒体消息的广告推送业务、聊天室等应用。但是对于这些应用，一个重要问题是：在两个消息之间没有通信语法信息来描述多媒体消息之间的关系，例如，一个超市想要推送给客户销售打折信息，它必须把所有的信息都打成一个包，如果销售打折信息有一点变化，多媒体消息系统必须将所有的信息，包括改变的信息和未改变的信息都要在一个新的包里重新发送，而不能只发送更新改变的信息，这造成过多信息的重复发送，造成网络上大量的消息流量，从而降低了多媒体消息系统的效率。

另外，由于多媒体消息使用WAP-push技术，这类似于短消息的存储与转发功能，所以从本质上说，当前的多媒体消息技术还是一种存储然后转发的技术。这意味着当发送者发送一条多媒体消息时，这条消息并不是由接收者直接收到，而是由发送者所在网络的多媒体消息中心先一步接收到，然后多媒体消息中心向接收者发送一条通知指令，通知接收者从多媒体消息中心下载消息。

这种基于WAP-push技术的多媒体消息发送接收机制对于目前服务运营商开发的很多多媒体消息应用来说，效率很差，下面根据图2进行详细说明。

在图2中，简单示出了在不进行漫游的情况下，现有的基于应用的多媒体消息发送接收实现系统，这里只列出了造成多媒体消息应用效率差的、和多媒体消息发送接收相关的部件，其它部件，例如为多媒体消息中心202、后台应用服务器提供通信接口的多媒体消息网关，就没有被列出。图2中，发送者为一个应用程序228，接收者为一个可以接收多媒体消息的多媒体消息客户端接收设备216，包括WAP协议栈220、短消息发送/接收器222、消息显示器224和消息存储器226。应用程序228经过多媒体消息发送设备200和射频发射塔214将多媒体消息发送给多媒体消息客户端接收设备216。以下图3会详细描述现有多媒体消息发送接收过程。多媒体消息发送设备200中，和多媒体消息发送接收相关的模块包括：多媒体消息中心202，短消息中心210以及和多媒体消息中心202相连的无线网络的WAP网关212。这里的多媒体消息中心202是多媒体消息发送设备200中多媒体消息处理的最核心的部分，它提供对多媒体消息的存储和操作支持，并具有灵活的寻址能力。多媒体消息中心202包括对多媒体消息进行处理的多媒体消息服务器204、通知短消息发送器206和多媒体消息存储器208。

图3给出了应用程序228发送多媒体消息以及多媒体消息客户端接收设备216接收多媒体消息的过程，在图3中，在步骤S301，应用程序228准备要发送的多媒体消息；在步骤S303，应用程序228将多媒体消息发给多媒体消息中心202；在步骤S305，多媒体消息中心202接收消息，将消息的内容转换成MIME的格式后存储在多媒体消息存储器208上，以上步骤S301、S303和S305是为发送一个多媒体消息的准备工作，在本发明后续描述中，将简称该三个步骤总和为发送多媒体消息的预备步骤。然后在步骤S307，多媒体消息中心202准备将多媒体消息发送给多媒体消息客户端接收设备216，多媒体消息中心202使用WAP push，即通知短消息中心210发送通知短消息，在步骤S309，短消息中心210就发送该通知短消息，这样就完成了一个应用程序228发送多媒体消息的过程。接下来是多媒体消息客户端接收设备216接收多媒体消息的过程，在步骤S311，多媒体消息客户端接收设备216接收到通知短消息，在步骤S313，多媒体消息客户端接收设备216建立一个WAP连接，通过WAP网关212发送一个包含多媒体消息存储位置URL的、请求获取多媒体消息的WAP请求到多媒体消息中心202；在步骤S315，多媒体消息中心202将多媒体消息通过同一个WAP连接发送至多媒体消息客户端接收设备216；在步骤S317，多媒体消息客户端接收设备216仍通过同一个WAP连接告知接收成功；在步骤S319，多媒体消息中心202告知发送方应用程序228消息已送达，发送方应用程序228终端显示“消息已送达”。这样就完成了一个多媒体消息接收端接收多媒体消息的过程。这里为了后续描述方便，将步骤S313、S315、S317和S319的组合称为接收普通多媒体消息步骤。

从上述多媒体消息发送的实现过程可以看到，多媒体消息中心202并不是直接将多媒体消息发送给多媒体消息客户端接收设备216，而是向其发送一个通知短消息，告诉多媒体消息客户端接收设备216有一条消息正在等待。除非多媒体消息最后通过WAP连接真正被送达到多媒体消息客户端接收设备216，否则用户并不知道将收到一条怎样的多媒体消息。当用户将多媒体消息客户端接收设备216设置成“立即提取”时，多媒体消息客户端接收设备216自己处理多媒体消息的提取，然后才告知发送方“消息已接收”。

并且从上述过程也可以看出，多媒体消息的接收过程是非常复杂的，尤其是当消息的大小很小时，通信的延迟相对来说很大。

综上所述，造成当前多媒体消息系统效率低的两个主要原因：一方面是过多信息的重复发送，造成大量的消息流量；另一方面是通知短消息带来的通信消耗。

发明内容

为了解决上述两个问题，本发明的发明目的在于利用新的多媒体消息描述格式，将多媒体消息变化部分单独描述出来，由于只发送了消息的变化部分，在达到同样通信目的的情况下，减少了传输的消息量，节约了网络资源，并且由于多媒体消息变化部分大小较小，可以利用短消息通道发送，这样可以提高多媒体消息系统的效率。

本发明可以在不改变现有的多媒体消息运作模型的前提下，加速多媒体消息传输的速度，提高多媒体消息应用的实时性，改善用户体验，并且由于采用短消息通道发送较小的多媒体消息，降低了用户使用费用，使多媒体消息服务变得容易接受，能够帮助多媒体服务运营商提高用户数量，提高服务质量和潜在增加服务收入。

根据本发明的一个方面，提供了一种支持基于应用的多媒体消息的客户端接收设备，用于处理应用发送给其的多媒体消息，该设备包括WAP协议栈、短消息发送/接收器、消息显示器以及消息存储器，所述多媒体消息客户端接收设备还包括：多媒体消息解析器，用于判别所述多媒体消息为增量多媒体消息还是普通多媒体消息，所述增量多媒体消息的消息体包括多媒体消息的动态数据部分、多媒体消息关联的静态数据指示以及被指示的静态数据和所述动态数据的关联关系；以及消息融合器，用于将增量多媒体消息根据关联关系融合成一个普通多媒体消息。

根据本发明的另一方面，提供了一种支持基于应用的客户端处理多媒体消息方法，该方法包括：判别要处理的多媒体消息为增量多媒体消息还是普通多媒体消息，所述增量多媒体消息的消息体包括多媒体消息的动态数据部分、多媒体消息关联的静态数据指示以及被指示的静态数据和所述动态数据的关联关系；以及将增量多媒体消息根据关联关系融合成一个普通多媒体消息。

根据本发明的又一方面，提供了一种支持基于应用的多媒体消息发送设备，包括多媒体消息服务器，多媒体消息存储器、WAP网关、通知短消息发送器，短消息中心，该发送设备还包括：判别器，用于判别要发送的多媒体消息是普通多媒体消息还是增量多媒体消息，其中所述增量多媒体消息的消息体包括多媒体消息的动态数据部分、多媒体消息关联的静态数据指示以及被指示的静态数据和所述动态数据的关联关系；发送通道选择器，用于根据要发送的增量多媒体消息的大小选择发送通道，如果消息大小小于所述设定阈值，采用短消息通道发送。

根据本发明的再一方面，提供了一种支持基于应用的多媒体消息发送方法，包括：判别要发送的多媒体消息是普通多媒体消息还是增量多媒体消息，其中所述增量多媒体消息的消息体包括多媒体消息的动态数据部分、多媒体消息关联的静态数据指示以及被指示的静态数据和所述动态数据的关联关系；对于要发送的增量多媒体消息，获取所述增量多媒体消息的大小；以及如果所述多媒体消息的大小小于所述阈值，采用短消息通道发送。

根据本发明的又一方面，提供了一种支持基于应用的多媒体消息发送接收系统，包括多媒体消息发送设备，该发送设备包括多媒体消息服务器，多媒体消息存储器、WAP网关、通知短消息发送器，短消息中心，该发送系统设备用于向客户端接收设备发送增量多媒体消息，其中所述增量多媒体消息的消息体包括多媒体消息的动态数据部分、多媒体消息关联的静态数据指示以及被指示的静态数据和所述动态数据的关联关系；多媒体消息客户端接收设备，用于处理应用发送给其的多媒体消息，该设备包括WAP协议栈、短消息发送/接收器、消息显示器以及消息存储器，所述多媒体消息客户端还包括：多媒体消息解析器，用于判别所述多媒体消息为增量多媒体消息还是普通多媒体消息；以及消息融合器，用于将增量多媒体消息根据关联关系融合成一个普通多媒体消息。

根据本发明的再一方面，提供了一种支持基于应用的多媒体消息发送接收方法，包括步骤：发送增量多媒体消息，其中所述增量多媒体消息的消息体包括多媒体消息的动态数据部分、多媒体消息关联的静态数据指示以及被指示的静态数据和所述动态数据的关联关系；响应该增量多媒体消息的发送，接收该增量多媒体消息；判别要处理的多媒体消息为增量多媒体消息还是普通多媒体消息；以及将增量多媒体消息根据关联关系融合成一个普通多媒体消息。

根据本发明的又一方面，提供了一种程序产品，包含程序代码，用于实现说明书中所述的方法以及承载该程序代码的承载介质。

附图说明

附加权利要求中陈述了本发明特有的新特征。但是，结合附图，参考后面实施例的详细说明，将更好地理解发明本身，以及本发明的优选使用方式、其它目的和优点，其中：

图1示意性示出了普通多媒体消息的消息结构；

图2示意性示出了现有的基于应用的多媒体消息发送接收系统；

图3示意性示出了现有的应用程序发送多媒体消息和客户端接收多媒体消息的过程；

图4示意性示出了依据本发明的一种增量多媒体消息的描述方法；

图5示意性示出了依据本发明的采用多媒体消息通知短消息格式的、对多媒体消息采用短消息通道发送时该标识为多媒体消息的短消息的格式；

图6示意性地示出了依据本发明的一种基于应用的多媒体消息的发送设备；

图7示意性地示出了依据本发明的一种基于应用的多媒体消息的发送方法流程图；

图8示意性地示出了依据本发明的一种基于应用的多媒体消息客户端接收设备；以及

图9示意性地示出了依据本发明的一种基于应用的多媒体消息接收方法的流程图。

具体实施方式

以下通过参考附图，对本发明的具体实施方式进行描述。应当理解，以下给出的描述使得本领域的普通技术人员能够实现本发明。对于本发明的各种修改对于本领域的普通技术人员来说都是显而易见的，并且本发明提出的原理也可以应用到其它实施方式中。因此，本发明并不限于以下所描述的实施例。

对于一个多媒体消息应用来说，在用户和后台应用服务器之间常常有很多的信息交流，因此，可以在多媒体消息包中加入一种增量更新机制，来减少通信流量。在本发明中，将采用现有的多媒体消息描述方式描述的多媒体消息称为普通多媒体消息，而将采用本发明提出的多媒体消息的描述方式描述的多媒体消息称为增量多媒体消息。

参照图4，图4示意性示出了一种增量多媒体消息的描述方法，该方法可以提供一种增量更新机制，图4的标号401描述了一种增量多媒体消息，该多媒体消息的消息体被分为静态数据部分和动态数据部分，静态数据部分包括普通的多媒体消息对象，包括文本、图片、音频等，静态数据是用户和服务器后续相关交流的基础消息，用于描述在用户和应用之间交流时，变化较少的数据，例如对于一个多媒体聊天应用，聊天室的背景可以作为静态数据；动态数据用于描述在用户和应用之间交流时，变化较多的数据，例如对于上述多媒体聊天应用，聊天的内容可以作为动态数据，这种动态数据和静态数据的组合表达了整个多媒体消息的内容，因此，这种组合就暗示了动态数据和静态数据之间的关联关系，可以认为是关联关系的一种描述方式。图4的标号403描述了另一种增量多媒体消息，该多媒体消息体包含动态数据部分，在该实施例中，还包含该多媒体消息的动态数据所关联的静态数据指示，以指示静态数据的位置、来源等信息，并且还包含一个关联关系，该关联关系可以描述如何将动态数据和静态数据融合成一个新的多媒体消息，例如该动态数据和初始发送的多媒体消息的静态数据如何组合成一个新的多媒体消息。发送这类多媒体消息可以大大减小消息体的数据大小，减少基于应用的通信流量。

以上两个实施例给出了增量多媒体消息的两种描述形式，但是增量多媒体消息不限于以上两种描述形式，只要消息体包括多媒体消息的动态数据部分、多媒体消息关联的静态数据指示以及被指示的静态数据和所述动态数据的关联关系，就是一种增量多媒体消息。

增量多媒体消息的关联关系描述了如何将所述增量多媒体消息的所述动态数据和所述静态数据指示标记的静态数据融合成一个新的普通多媒体消息，优选的实施方式是利用一个文件来定义关联关系，这里的文件为一种描述文件，可以采用多种文件格式，包括但不限于XML文件、文本文件等。作为一种优选的实施方式，图4的标号405给出了标号为403的多媒体消息采用的描述关联关系的XML文件。该关联关系文件中指出，在多媒体消息403中，要利用new.txt文件替换消息标号为001的消息中的chat.txt文件，然后组成一个新的多媒体消息。为了便于处理，一般来说可以对消息进行编号，这样，在只包含动态数据的多媒体消息中，多媒体消息所关联的静态数据指示可以使用该静态数据初始所在的多媒体消息的消息编号或者该消息编号指示的消息的一部分。实际上，静态数据本身也可以被认为是一种静态数据指示。因此，增量多媒体消息的静态数据指示可以是以下之一：已经接收的多媒体消息编号、通过消息编号指示的多媒体消息的一部分以及静态数据本身等。采用图4使用的增量多媒体消息的描述方法后，使用只包含增量动态数据的多媒体消息的消息体将会比使用原来的普通多媒体消息体通信量减少很多。

采用增量多媒体消息描述方式后，除了可以利用原来的多媒体消息通道发送增量消息外，还可以考虑采用短消息通道发送消息体数据量较小的多媒体消息。由于多媒体消息是一个经过通知短消息的通知由多媒体消息客户端通过WAP Push获取的多媒体消息，为了使多媒体消息客户端便于处理多媒体消息，可以采用多媒体消息通知短消息的格式来发送所述多媒体消息数据，而不需要发送通知短消息。但是，由于原来的通知短消息有特定的格式，使得多媒体消息客户端可以识别该通知短消息，这里需要对多媒体消息通知短消息格式略作修改以获得新的标识为多媒体消息的短消息的消息格式。然后，通过短消息通道发送的多媒体消息就要遵循这种标识为多媒体消息的短消息的消息格式，需要通过格式编码达到该目的。

参照图5，图5示意性示出了采用多媒体消息通知短消息格式的、对多媒体消息采用短消息通道发送时该标识为多媒体消息的短消息的格式。根据图1，可知多媒体消息包括多媒体消息报头和消息体。多媒体消息报头包括有关将多媒体消息如何从源发送到接收者的信息，例如源地址、目标地址等信息。现有技术中已经定义了通知短消息的消息格式，图5的501给出了通知短消息的格式，该通知短消息的格式包括短消息报头505和短消息消息体507，短消息报头505包括头长513、目标端口515、和源端口517；短消息消息体507包括事务ID 519、消息类型521以及多媒体消息通知数据523，其中对于多媒体消息的通知短消息，消息类型521规定为0x06。标识为多媒体消息的短消息503采用和多媒体消息通知短消息类似的格式，包括短消息报头509和短消息消息体511，短消息报头509包括头长525、目标端口527、源端口529；短消息消息体511包括事务ID 531，消息类型533以及多媒体消息数据535，其中对于标识为多媒体消息的短消息，消息类型533可以规定为其它数据，这里假设规定为0x07。该假设规定不应该被视为对本发明的限制，本领域技术人员应该知道，这里可以在短消息传输标准范围内，对本发明提出的标识为多媒体消息的短消息格式做合适的修改。所有这些修改都在本发明的保护范围之内。在本优选实施例中，采用消息类型用于区分多媒体消息的通知短消息和标识为多媒体消息的短消息，并且在通知短消息中给出了多媒体消息通知数据523，而标识为多媒体消息的短消息中给出了多媒体消息数据535。

参照图6，图6示意性给出了一种支持基于应用的增量多媒体消息的发送设备，所述多媒体消息发送设备600包含图2所示的现有多媒体消息的发送设备包含的装置，即包含的多媒体消息中心602，其包括多媒体消息存储器608、通知短消息发送器606、多媒体消息服务器604，以及WAP网关612、短消息中心610等，除此之外，还包括判别器601，用于判别要发送的多媒体消息是普通多媒体消息还是增量多媒体消息，对于要发送的多媒体消息是普通多媒体消息，可以直接利用现有技术进行发送；对于要发送的多媒体消息是增量多媒体消息，就要采用本发明提出的发送通道选择器603，该发送通道选择器603可以获取要发送的增量多媒体消息的消息大小，然后判别该要发送的多媒体消息大小和设定的阈值之间的关系，如果消息的大小小于等于某个阈值，可以采用现有的短消息通道进行发送。上述设定的阈值和短消息的一次最大通信量相关。这时的标识为多媒体消息的短消息是一个单一多媒体消息，即该短消息本身就代表了一个完整的多媒体消息，而不需要和其它短消息一起组合成一个多媒体消息。这里定义单一多媒体消息，主要原因是如果要发送的多媒体消息大小大于上述设定的阈值，在一定的情况下，可以分解成多个标识为一个多媒体消息的短消息进行发送。下面步骤中有对于该情况的具体处理。

优选地，所述发送设备还包括格式编码器605，用于对选择短消息通道发送的多媒体消息进行短消息格式编码。由于多媒体消息有其特有的格式，当采用短消息格式发送时，需要采用特别的短消息格式。在图5中已经定义了该格式，格式编码器605需要将多媒体消息数据按照图5所定义的格式进行格式编码。

优选地，对于消息的大小大于上述设定的阈值时，该发送通道选择器603可以通知多媒体消息中心602采用多媒体消息通道发送，即发送多媒体消息的通知短消息；也可以将该增量多媒体消息分解成多个短消息，采用短消息通道发送，这时标志该短消息为非单一多媒体消息，即该短消息本身就代表了一个不完整的多媒体消息，需要和其它短消息一起组合成一个多媒体消息。组成一个增量多媒体消息的各非单一多媒体消息需要被标识出来，本领域技术人员应该知道，可以采用各种标识方法，例如在多媒体消息数据535加一个头部。至于分解为多个短消息发送还是采用传统的多媒体消息发送方式，和具体的应用相关，也和短消息服务费用及多媒体消息服务费用相关，用户可以酌情使用。具体可以由发送通道选择器603来将增量多媒体消息分解成若干个标识为一个多媒体消息的短消息，然后由格式编码器605进行格式编码后发送。

上述判别器601、发送通道选择器603和格式编码器605功能可以由这样的装置来完成，其中包括中央处理单元、I/O接口等，并且这些装置物理上不限于位于多媒体消息中心602之外，也可以放置到多媒体消息中心602之中。

参照图7，图7给出了一种支持基于应用的增量多媒体消息的发送方法，在该方法中，在步骤S701，开始发送过程；在步骤S703，为现有技术的发送预备步骤，在图3的相关描述中，已经定义了该发送预备步骤。在步骤S705，判别要发送的多媒体消息是普通多媒体消息还是增量多媒体消息，在步骤S719，对于普通多媒体消息的发送，准备通知短消息后就在步骤S723发送该通知短消息。而对于增量多媒体消息，在步骤S707，首先从多媒体消息中心602将该增量多媒体消息传送给发送通道选择器603，即获取要发送的增量多媒体消息，然后在步骤S709，发送通道选择器603获取要发送的增量多媒体消息，如何获取消息的大小对本领域技术人员来说有很多种实现方法，这里并不限于某一固定方法。然后在步骤S711，发送通道选择器603对于要发送的多媒体消息，判断所述多媒体消息的大小是否大于某一事先设定的阈值，如果所述多媒体消息的大小小于等于所述阈值，转到步骤S717，选择短消息通道发送，如果所述多媒体消息的大小大于所述阈值，在步骤S713会进一步判断是否应该采用多个短消息发送该增量多媒体消息，如果合适，在步骤S715就要将该要发送的增量多媒体消息分解成多个短消息，然后在步骤S717，选择短消息通道发送，如果不应该分解成多个短消息发送，就转到步骤S719，准备通知短消息，采用普通短消息的发送方式，然后转到步骤S723，发送通知短消息。只要采用短消息通道发送，就要转到步骤S721，对要发送的增量多媒体消息进行短消息格式编码，然后转到步骤S723，发送短消息，在步骤S725，一个发送过程结束。因此，从上述步骤描述中可以看出，短消息发送设备最终发送的是一个短消息，这个短消息可以是普通短消息、标识为多媒体消息的短消息，多媒体消息的通知短消息。

参照图8，图8示意性地示出了一种基于应用的多媒体消息的客户端接收设备800，基于应用的多媒体消息客户端接收设备800可以是多媒体移动设备，包括但不限于多媒体移动电话，PDA等。多媒体消息客户端接收设备800可以处理增量多媒体消息，该多媒体消息客户端接收设备800除了包括现有技术中包括的WAP协议栈820、短消息发送/接收器822、消息显示器824以及消息存储器826之外，该多媒体消息客户端接收设备800还包括多媒体消息解析器805，用于判别所述多媒体消息为增量多媒体消息还是普通多媒体消息，还包括消息融合器803，用于将增量多媒体消息根据关联关系融合成一个普通多媒体消息。多媒体消息解析器805判别所述多媒体消息为增量多媒体消息还是普通多媒体消息的方法本领域技术人员应该知道有很多种，这里不限于某一具体判别方法，所有的判别方法都包含在本发明之内。

消息融合器803对增量多媒体消息进行消息融合，优选地，消息融合器803进一步包括关联融合器，用于根据动态数据、静态数据以及关联关系将该增量多媒体消息融合成普通多媒体消息。还包括静态数据判别器，用于判断所述增量多媒体消息的静态数据指示是否包含静态数据；如果包含静态数据，进一步包括静态数据存储器，用于存储该静态数据。如果不包含静态数据，进一步包括静态数据获取器，用于根据静态数据指示，获取该增量多媒体消息的静态数据；如果不包含静态数据，进一步包括完整消息判断器，用于判别不包含静态数据的增量多媒体消息是否为完整的多媒体消息；以及如果不是完整的多媒体消息，进一步包括完整消息获取器，用于获取不是完整的多媒体消息的增量多媒体消息相关的其它消息数据，判断是否已经获得完整的多媒体消息，如果没有，继续等待获取完整的多媒体消息。以上这些装置在图8中没有示出，本领域技术人员可以知道，这些装置都可以通过处理器、微处理器、DSP、专用电路等等来实现。因此，整体的消息融合器803的功能可以由这样的装置来完成，其中包括中央处理单元、I/O接口等。

优选地，图8所示的多媒体消息客户端接收设备800还包括短消息解析器807，短消息解析器807从短消息发送/接收器822获取短消息，对该内容进行解析，通过识别该短消息的消息类型，从而判别该短消息是普通短消息、多媒体消息的通知短消息还是标识为多媒体消息的短消息；对于标识为多媒体消息的短消息，短消息解析器807可以将消息转换成多媒体消息的描述格式，然后传送给消息融合器803；对于普通短消息，将该消息直接送给消息显示器824，对于多媒体消息的通知短消息，将该消息直接送给消息显示器824并同时通过WAP协议站820获取该多媒体消息。所述短消息解析器807的功能可以由这样的装置来完成，其中包括中央处理单元、I/O接口、存储器等。

优选地，所述的客户端接收设备800还包括交互式管理器809，用于管理所述客户端接收设备800和应用之间的交互，提供给客户端查询、检索等接口。所述交互式管理器809的功能可以由这样的装置来完成，其中包括中央处理单元、I/O接口、存储器等。

参照图9，图9示意性地示出了一种支持基于应用的多媒体消息客户端接收多媒体消息方法流程图，该方法中，在步骤S901，开始接收过程，在步骤S903，接收到一个短消息，在步骤S905，判别接收的短消息是被标识为多媒体消息的短消息、或者是多媒体消息的通知短消息，还是普通短消息。对于普通短消息，在步骤S931显示并存储该短消息后接收过程就结束了。对于多媒体消息的通知短消息，在步骤S907，多媒体消息客户端接收设备800通过WAP协议根据多媒体消息的通知短消息指示的URL信息，获取该多媒体消息，即图3中定义的接收普通多媒体消息的步骤，只是该多媒体消息即可以是普通多媒体消息，也可以是增量多媒体消息。对于标识为多媒体消息的短消息，在步骤S909解析所述标识为多媒体消息的短消息，以获取其多媒体消息的描述形式，所述多媒体消息描述形式包括增量多媒体消息的描述形式和普通多媒体消息的描述形式。这样，就得到了接收的多媒体消息的内容，但是该内容表现形式可以是普通多媒体消息的描述形式，也可以是增量多媒体消息的描述形式，为了进一步利用现有的多媒体消息客户端对普通多媒体消息的显示、存储等技术，在步骤S911，判别要处理的多媒体消息为增量多媒体消息还是普通多媒体消息，对于普通多媒体消息，只需结合现有技术进行显示、存储等处理即可，包括步骤S925显示多媒体消息，步骤S927存储多媒体消息以及步骤S929进行对话管理。对于增量多媒体消息，在步骤S913，判断所述增量多媒体消息的静态数据指示是否包含静态数据；在步骤S921，如果包含静态数据，存储该静态数据，该静态数据可为后来的消息交互提供基础，并在步骤S923根据动态数据、静态数据以及关联关系将该增量多媒体消息融合成普通多媒体消息。如果不包含静态数据，在步骤S915，判别该增量多媒体消息是否为完整的多媒体消息；如果为完整的多媒体消息，在步骤S917，获取该增量多媒体消息的静态数据，并在步骤S923根据动态数据、静态数据以及关联关系将该增量多媒体消息融合成普通多媒体消息。如果不是完整的多媒体消息，在步骤S919获取和该增量多媒体消息相关的其它消息数据，判断是否已经获得完整的多媒体消息，如果没有，继续等待获取完整的多媒体消息，如果已经获取了完整的多媒体消息，获取该多媒体消息的静态数据，并在步骤S923根据动态数据、静态数据以及关联关系将该增量多媒体消息融合成普通多媒体消息。然后可以对融合后的普通多媒体消息结合现有技术进行显示、存储等处理即可，包括步骤S925显示多媒体消息，步骤S927存储多媒体消息以及步骤S929进行对话管理。最后在步骤S733，一个接收过程结束。

回到图4，以图4所示的多媒体消息为例进一步说明该方法，多媒体消息客户端接收设备首先接收一个多媒体消息(1)401，该多媒体消息(1)401的消息体分为消息的静态部分和消息的动态部分，该静态数据也是后来交互的多媒体消息的静态数据，因此，存储多媒体消息(1)401的静态数据部分；然后接收一个被判别为标识为多媒体消息(2)403的短消息，对于该标识为多媒体消息403的短消息，解析所述短消息，得到所述多媒体消息(2)403的多媒体消息数据，该多媒体消息403数据包括动态数据部分和静态数据指示以及被指示的静态数据和所述动态数据的关联关系，解析该关联关系，可知静态数据的指示是通过<Type>Replace</Type>表现的，含义为所述多媒体消息(2)403的消息静态数据部分和所述多媒体消息(1)401的静态数据相同，关联关系是通过<Type>Replace</Type>、<SrcName>chat.txt</Src Name>和<Desc Name>new.txt</Desc Name>表现的，即利用多媒体消息(2)403中提供的new.txt文件替换多媒体消息(1)401中的chat.txt文件。这里，静态数据指示和关联关系放在一个XML文件405中表达，替换地，也可以将静态数据指示和关联关系分别表达。利用以上关联关系和静态数据指示获得多媒体消息(1)401的静态数据后，用new.txt文件替换多媒体消息(1)401中的chat.txt文件得到多媒体消息，可以在所述多媒体消息客户端显示该消息。这里，包含多媒体消息消息动态数据、静态数据指示和关联关系的多媒体消息的描述方式可以在不脱离本发明的精神和范围的情况下，作出多种改变，而本发明包括所有的这些多媒体消息描述方式的改变。

将图6所示的支持基于应用的多媒体消息的发送设备和图8所示的支持基于应用的多媒体消息客户端接收设备组合成一个支持基于的多媒体消息发送接收系统，该发送设备和图6所示的发射设备特征相同，接收设备和图8所示的接收设备特征相同，这里不再赘述。

将图7所示支持基于应用的多媒体消息发送方法的和图9所示的支持基于应用的多媒体消息的处理方法组合成一个支持基于的多媒体消息发送接收方法，该发送方法和图7所示的发射方法特征相同，接收方法和图9所示的接收方法特征相同，这里不再赘述。

本发明还提供一种程序产品，包含实现以上所有方法的程序代码以及承载该程序代码的承载介质。

虽然已参考具体实施例说明了本发明，不过所述说明不应被理解为对本发明的限制。当参考本发明的说明时，对本领域的技术人员来说，所公开实施例的各种修改，以及本发明的其它实施例将变得显而易见。于是可认为在不脱离附加权利要求中限定的本发明的精神或范围的情况下，可做出这样的修改。

Claims (42)

1.一种支持基于应用的多媒体消息的客户端接收设备，用于处理应用发送给其的多媒体消息，该设备包括WAP协议栈、短消息发送/接收器、消息显示器以及消息存储器，所述多媒体消息客户端接收设备还包括：

多媒体消息解析器，用于判别所述多媒体消息为增量多媒体消息还是普通多媒体消息，所述增量多媒体消息的消息体包括多媒体消息的动态数据部分、多媒体消息关联的静态数据指示以及被指示的静态数据和所述动态数据的关联关系；以及

消息融合器，用于将增量多媒体消息根据关联关系融合成一个普通多媒体消息。

2.根据权利要求1所述的客户端接收设备，所述客户端接收设备还包括短消息解析器，用于判别接收的短消息是被标识为多媒体消息的短消息，或者是多媒体消息的通知短消息，还是普通短消息。

3.根据权利要求2所述的客户端接收设备，其中当接收的短消息是被标志为多媒体消息的短消息时，所述短消息解析器还用于解析所述标识为多媒体消息的短消息，以获取其多媒体消息的描述形式，所述多媒体消息描述形式包括增量多媒体消息的描述形式和普通多媒体消息的描述形式。

4.根据权利要求1、2或3所述的客户端接收设备，其中所述关联关系描述如何将所述增量多媒体消息的所述动态数据和所述静态数据指示标记的静态数据融合成一个新的普通多媒体消息。

5.根据权利要求1、2或3所述的客户端接收设备，其中所述多媒体消息的静态数据指示是以下之一：已经接收的多媒体消息编号、通过消息编号指示的多媒体消息的一部分以及静态数据本身。

6.根据权利要求1、2或3所述的客户端接收设备，其中所述消息融合器进一步包括：

关联融合器，用于根据动态数据、静态数据以及关联关系将该增量多媒体消息融合成普通多媒体消息。

7.根据权利要求6所述的客户端接收设备，其中所述消息融合器进一步包括：

静态数据判别器，用于判断所述增量多媒体消息的静态数据指示是否包含静态数据；以及

静态数据存储器，用于存储该静态数据。

8.根据权利要求7所述的客户端接收设备，其中所述消息融合器进一步包括：

静态数据获取器，用于根据静态数据指示，获取该增量多媒体消息的静态数据。

9.根据权利要求7所述的客户端接收设备，其中所述消息融合器进一步包括：

完整消息判断器，用于判别不包含静态数据的增量多媒体消息是否为完整的多媒体消息；以及

完整消息获取器，用于获取不是完整的多媒体消息的增量多媒体消息相关的其它消息数据，判断是否已经获得完整的多媒体消息，如果没有，继续等待获取完整的多媒体消息。

10.根据权利要求1、2或3所述的客户端接收设备，其中所述关联关系的描述形式采用XML语言。

11.根据权利要求1、2或3所述的客户端接收设备，该设备还包括：交互式管理器，用于管理所述应用和所述客户端之间的会话。

12.根据权利要求1、2或3所述的客户端接收设备，其中所述短消息接收器还接收多个被标识为一个多媒体消息的短消息。

13.一种支持基于应用的客户端处理多媒体消息的方法，该方法包括：

判别要处理的多媒体消息为增量多媒体消息还是普通多媒体消息，所述增量多媒体消息的消息体包括多媒体消息的动态数据部分、多媒体消息关联的静态数据指示以及被指示的静态数据和所述动态数据的关联关系；以及

将增量多媒体消息根据关联关系融合成一个普通多媒体消息。

14.根据权利要求13所述的客户端处理多媒体消息方法，该方法还包括步骤：

接收一个短消息；以及

判别接收的短消息是被标识为多媒体消息的短消息、或者是多媒体消息的通知短消息，还是普通短消息。

15.根据权利要求14所述的客户端处理多媒体消息方法，该方法还包括步骤：

当接收的短消息被标志为多媒体消息时，解析所述标识为多媒体消息的短消息，以获取其多媒体消息的描述形式，所述多媒体消息描述形式包括增量多媒体消息的描述形式和普通多媒体消息的描述形式。

16.根据权利要求14所述的客户端处理多媒体消息方法，该方法还包括步骤：

当接收的短消息为多媒体消息的通知短消息时，根据通知短消息通过WAP连接获取该多媒体消息。

17.根据权利要求13-16之一所述的客户端处理多媒体消息方法，其中所述关联关系描述如何将所述增量多媒体消息的所述动态数据和所述静态数据指示标记的静态数据融合成一个新的普通多媒体消息。

18.根据权利要求13-16之一所述的客户端处理多媒体消息方法，其中所述多媒体消息的静态数据指示是以下之一：已经接收的多媒体消息编号、通过消息编号指示的多媒体消息的一部分以及静态数据本身。

19.根据权利要求13-16之一所述的客户端处理多媒体消息方法，其中融合步骤包括步骤：

判断所述增量多媒体消息的静态数据指示是否包含静态数据；以及

如果包含静态数据，存储该静态数据，并根据动态数据、静态数据以及关联关系将该增量多媒体消息融合成普通多媒体消息。

20.根据权利要求19所述的客户端处理多媒体消息方法，其中判断步骤进一步包括：

如果不包含静态数据，获取该增量多媒体消息的静态数据，并根据动态数据、静态数据以及关联关系将该增量多媒体消息融合成普通多媒体消息。

21.根据权利要求19所述的客户端处理多媒体消息方法，其中判断步骤进一步包括：

判别该增量多媒体消息是否为完整的多媒体消息；

如果是完整的多媒体消息，获取该增量多媒体消息的静态数据；以及

如果不是完整的多媒体消息，获取和该增量多媒体消息相关的其它消息数据，判断是否已经获得完整的多媒体消息，如果没有，继续等待获取完整的多媒体消息，如果已经获取了完整的多媒体消息，获取该多媒体消息的静态数据。

22.根据权利要求13-16之一所述的客户端处理多媒体消息方法，所述关联关系的描述形式采用XML语言。

23.根据权利要求13-16之一所述的客户端处理多媒体消息方法，该方法还包括步骤：管理所述应用和所述客户端之间的会话。

24.一种支持基于应用的多媒体消息发送设备，包括多媒体消息服务器、多媒体消息存储器、WAP网关、通知短消息发送器、短消息中心，该发送设备还包括：

判别器，用于判别要发送的多媒体消息是普通多媒体消息还是增量多媒体消息，其中所述增量多媒体消息的消息体包括多媒体消息的动态数据部分、多媒体消息关联的静态数据指示以及被指示的静态数据和所述动态数据的关联关系；

发送通道选择器，用于根据要发送的增量多媒体消息的大小选择发送通道，如果消息大小小于所述设定阈值，采用短消息通道发送。

25.根据权利要求24所述的多媒体消息发送设备，该系统还包括格式编码器，用于对选择短消息通道发送的多媒体消息进行短消息格式编码。

26.根据权利要求24所述的多媒体消息发送设备，其中发送通道选择器判断如果消息大小大于所述设定阈值，采用多媒体消息通道发送。

27.根据权利要求24所述的多媒体消息发送设备，其中所述发送通道选择器当判别所述多媒体消息大小大于所述阈值时，将该增量多媒体消息分解成多个短消息，采用短消息通道发送。

28.根据权利要求24-27之一所述的多媒体消息发送设备，其中所述多媒体消息的静态数据指示是以下之一：已经接收的多媒体消息编号、通过消息编号指示的多媒体消息的一部分以及静态数据本身。

29.根据权利要求24-27之一所述的多媒体消息发送设备，其中所述关联关系描述如何将动态数据和静态数据融合成一个新的普通多媒体消息。

30.根据权利要求24-27之一所述的多媒体消息发送设备，其中所述关联关系的描述形式采用XML文件。

31.一种支持基于应用的多媒体消息发送方法，包括：

判别要发送的多媒体消息是普通多媒体消息还是增量多媒体消息，其中所述增量多媒体消息的消息体包括多媒体消息的动态数据部分、多媒体消息关联的静态数据指示以及被指示的静态数据和所述动态数据的关联关系；

对于要发送的增量多媒体消息，获取所述增量多媒体消息的大小；以及

如果所述多媒体消息的大小小于所述阈值，采用短消息通道发送。

32.根据权利要求31所述的多媒体消息发送方法，还包括步骤：对选择短消息通道发送的多媒体消息进行短消息格式编码。

33.根据权利要求31所述的多媒体消息发送方法，其中当判别所述多媒体消息大小大于所述阈值，采用多媒体消息通道发送。

34.根据权利要求31所述的多媒体消息发送方法，其中当判别所述多媒体消息大小大于所述阈值，将所述多媒体消息分解成多个标识为所述多媒体消息的短消息，采用短消息通道发送。

35.根据权利要求31-34之一所述的多媒体消息发送方法，其中所述多媒体消息的静态数据指示是以下之一：已经接收的多媒体消息编号、通过消息编号指示的多媒体消息的一部分以及静态数据本身。

36.根据权利要31-34之一所述的多媒体消息发送方法，其中所述关联关系描述如何将动态数据和静态数据融合成一个新的普通多媒体消息。

37.根据权利要求31-34之一所述的多媒体消息发送方法，其中所述关联关系的描述形式采用XML文件。

38.一种支持基于应用的多媒体消息发送接收系统，包括

发送设备，包括多媒体消息服务器，多媒体消息存储器、WAP网关、通知短消息发送器，短消息中心，该发送设备用于向客户端接收设备发送增量多媒体消息，其中所述增量多媒体消息的消息体包括多媒体消息的动态数据部分、多媒体消息关联的静态数据指示以及被指示的静态数据和所述动态数据的关联关系；

客户端接收设备，用于处理应用发送给其的多媒体消息，该设备包括WAP协议栈、短消息发送/接收器、消息显示器以及消息存储器，所述多媒体消息客户端还包括：

多媒体消息解析器，用于判别所述多媒体消息为增量多媒体消息还是普通多媒体消息；以及

消息融合器，用于将增量多媒体消息根据关联关系融合成一个普通多媒体消息。

39.根据权利要求38所述的多媒体消息发送接收系统，其中所述发送设备进一步包括：

判别器，用于判别要发送的多媒体消息是普通多媒体消息还是增量多媒体消息；

发送通道选择器，用于根据要发送的增量多媒体消息的大小选择发送通道，如果消息大小小于所述设定阈值，采用短消息通道发送。

40.一种支持基于应用的多媒体消息发送接收方法，包括步骤：

发送增量多媒体消息，其中所述增量多媒体消息的消息体包括多媒体消息的动态数据部分、多媒体消息关联的静态数据指示以及被指示的静态数据和所述动态数据的关联关系；

响应该增量多媒体消息的发送，接收该增量多媒体消息；

判别要处理的多媒体消息为增量多媒体消息还是普通多媒体消息；以及

将增量多媒体消息根据关联关系融合成一个普通多媒体消息。

41.根据权利要求40所述的多媒体消息发送接收方法，其中发送增量多媒体消息的步骤进一步包括：

判别要发送的多媒体消息是普通多媒体消息还是增量多媒体消息；

对于要发送的增量多媒体消息，获取所述增量多媒体消息的大小；

如果所述多媒体消息的大小小于所述阈值，采用短消息通道发送。

42.一种程序产品，包含：

程序代码，用于实现如上述权利要求13-24、32-38或40-42所述之一的方法；以及承载该程序代码的承载介质。

Images