CN101917520B

CN101917520B - 移动终端数据的转换/备份方法、设备和系统

Info

Publication number: CN101917520B
Application number: CN201010277057.8A
Authority: CN
Inventors: 杨健; 陈国乔; 王雷; 范姝男
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2007-07-04
Filing date: 2007-07-04
Publication date: 2013-01-30
Anticipated expiration: 2027-07-04
Also published as: CN101917520A

Abstract

本发明涉及数据传输技术，特别涉及移动终端设备之间的数据传输技术和移动终端设备的数据备份技术。本发明实施例提供的技术方案利用格式转换单元将原始数据转换为规定格式的中间文件，规定格式的中间文件中包含原始数据的指定条目和对应的数据字段，根据中间文件的规定格式，格式转换单元还可以从中间文件中读取其中的数据字段，从而生成原始数据对应的目标数据。由于规定格式的中间文件中包含的指定条目是原始数据在各种移动终端设备上存储的共有信息字段，因此中间文件可以在各移动终端设备之间传输，达到数据传输的目的。同时，中间文件还可以作为原始数据的备份文件，提高原始数据的可靠性。

Description

移动终端数据的转换/备份方法、设备和系统

技术领域

本发明涉及数据传输技术，特别涉及移动终端设备之间的数据转换技术和移动终端设备的数据备份技术。

背景技术

移动终端设备之间的数据传输主要是指一个移动终端设备当中存储的原始数据要转移到另外的一个移动终端设备当中去，传输的原始数据类型包括：电话本、日程、SMS(Short Message Service，短消息)记录，MMS(MultimeidaMessage Services，多媒体消息)记录或邮件(Email)记录等。

目前常用的移动终端设备通常为电话，实现数据传输的方式主要是电话到服务器(Phone To Server)，或者电话到电话(Phone To Phone)的方式。PhoneTo Server的方式就是指电话通过数据链路的方式，将移动终端设备存储的信息根据服务器所规定的方式，利用特殊的传输协议发送到服务器，并在服务器上进行存储。当移动终端设备需要对这些数据进行传输的时候，也利用移动终端设备和服务器的这种通信方式完成数据的传输工作，这种方式可以方便实现电话数据文件在服务器上的备份。当然还可以通过服务器到电话(Server ToPhone)的方式将数据传输给电话，从而达到在电话之间传输数据的目的。

Phone To Phone的方式一般是指利用移动终端设备的本地连接能力，如红外或者蓝牙将数据在不同的移动终端设备之间进行传送。一般来说，这种方式仅仅适用于同一移动终端设备厂商的移动终端设备，或者同一型号的移动终端设备之间进行数据的传输。

现在数据传输的实现方法主要针对电话本数据文件，电话本数据文件包括Vcard(电子商务卡片)和Vcalendar(电子商务日程)，IMC(Internet MailConsortium)规定了Vcard和Vcalendar的统一数据格式用来存储用户的电话本信息和日程信息，其中包含若干数据字段，每一个数据字段都又相应的条目，例如Vcard中包含的条目有：姓名、地址、移动电话号码、固定电话号码等。

移动终端设备根据IMC规定的标准版本和格式，统一存储相应的Vcard和Vcalendar的相关数据，在进行数据的传输的过程当中，只需要将本机内部的Vcard和Vcalendar数据在不同的移动终端设备之间直接传输，就能够达到不同的移动终端设备对该数据进行识别的功能。

但是由于移动终端设备处理能力、格式转换单元硬件系统架构的不同，现有移动终端设备上的SMS、MMS、Email等消息数据的存储方式有所不同，移动终端设备之间无法利用类似电话本数据的传输方式实现SMS、MMS、Email等数据的传输。

综上，现有移动终端设备之间进行数据传输的前提是两个移动终端设备内部支持统一的数据格式，并将自己的数据按照这样的一种格式进行组织。在完成本地数据的组织之后，如果移动终端设备之间需要进行数据文件的传输，那么可以通过Phone To Phone、或者Phone To Server以及Server To Phone的方式来完成数据的传输过程。

事实上，各厂家移动终端设备的操作系统以及底层的实现都是相对封闭和独立的，各厂家对于各自的数据格式，以及数据格式的传输都有自己的规定，这样就造成了不同厂家生产的各种移动终端设备之间、甚至同一厂家生成的不同型号移动终端设备之间数据传输的困难。

发明内容

本发明实施例提供一种移动终端设备的数据转换方法、设备和系统，用于实现移动终端设备之间的数据传输。

本发明实施例还提供了一种移动终端设备的数据备份方法、设备和系统，用于实现移动终端设备上的数据备份。

本发明实施例提供的一种移动终端设备数据的转换方法，包括：

生成符合规定格式的中间文件，所述中间文件中包含至少一个指定条目和各指定条目对应的数据字段，所述各指定条目对应的数据字段是从第一移动终端设备保存的原始数据中获取的；

根据所述中间文件的规定格式，从所述中间文件中获取各指定条目对应的数据字段，并按照第二移动终端设备支持的格式将各指定条目对应的数据字段保存为目标数据。

本发明实施例提供的一种移动终端设备数据的转换系统，包括：

第一格式转换单元，用于生成符合规定格式的中间文件，所述中间文件中包含指定条目和每一个指定条目对应的数据字段，所述每一个指定条目对应的数据字段是从第一移动终端设备保存的原始数据中获取的；

第二格式转换单元，用于根据所述第一格式转换单元生成的中间文件的规定格式，从所述中间文件中获取各指定条目对应的数据字段，并按照第二移动终端设备支持的格式将各指定条目对应的数据字段保存为目标数据。

本发明实施例提供的一种移动终端设备，包括：

传输指令接收单元，用于接收数据传输指令；

原始数据存储单元、第一数据存储控制单元和第一格式转换单元，所述第一格式转换单元根据传输指令接收单元接收的原始数据传输指令，通过所述第一数据存储控制单元从原始数据存储单元中获取指定条目对应的数据字段，并生成符合规定格式的中间文件，所述中间文件中包含指定条目和每一个指定条目对应的数据字段；

中间文件发送单元，用于将所述中间文件发送给其它移动终端设备。

本发明实施例提供的一种移动终端设备，包括：

中间文件接收单元，用于接收其它移动终端设备发送的中间文件，所述中间文件中包含指定条目和每一个指定条目对应的数据字段，所述每一个指定条目对应的数据字段是从所述其它移动终端设备保存的原始数据中获取的；

第二格式转换单元、第二数据存储控制单元和目标数据存储单元，所述第二格式转换单元从中间文件接收单元接收的中间文件中获取各指定条目对应的数据字段，并通过所述第二数据存储控制单元按照移动终端设备支持的格式，在所述目标数据存储单元中将各指定条目对应的数据字段保存为目标数据。

本发明实施例提供的一种移动终端设备数据的备份方法，包括：

从移动终端设备保存的原始数据中获取指定条目对应的数据字段；

生成符合规定格式的中间文件，所述中间文件中包含指定条目和每一个指定条目对应的数据字段；

将所述中间文件保存为对应所述原始数据的备份文件。

本发明实施例提供的一种移动终端设备的数据备份系统，包括：

数据存储控制单元和第一格式转换单元，所述第一格式转换单元通过所述数据存储控制单元从移动终端设备的原始数据中获取指定条目对应的数据字段，生成符合规定格式的中间文件，所述中间文件中包含指定条目和每一个指定条目对应的数据字段；

中间文件存储单元，用于将所述第一格式转换单元生成的中间文件对应存储为所述原始数据的备份文件。

本发明实施例提供的技术方案利用格式转换单元将原始数据转换为规定格式的中间文件，规定格式的中间文件中包含原始数据的指定条目和对应的数据字段，根据中间文件的规定格式，格式转换单元还可以从中间文件中读取其中的数据字段，从而生成原始数据对应的目标数据。

附图说明

图1为本发明实施例所述移动终端设备之间直接传输数据时，发送端的处理流程示意图；

图2为本发明实施例所述移动终端设备之间直接传输数据时，接收端的处理流程示意图；

图3为本发明实施例提供的移动终端设备之间传输数据的转换系统结构示意图；

图4、图5、图6分别为本发明实施例提供的一种移动终端设备结构示意图；

图7为本发明实施例提供的一种利用第三方设备实现移动终端设备数据传输的系统结构示意图。

具体实施方式

本发明实施例为实现各种移动终端设备之间的数据传输，提供一种移动终端设备数据的转换方法，对现有各种移动终端设备上的每一种类型的原始数据，分析其中的共有条目，将共有条目作为该类型原始数据必须传输的指定条目，并为每一种类型的原始数据设定规定格式的中间文件，中间文件是按照统一的规定格式转换而成的，其中包含的各指定条目和对应数据字段，如果中间文件发送给接收端，接收端根据对应的规定格式识别中间文件，并从中获取各指定条目对应的数据字段，按照本地支持的格式将各指定条目对应的数据字段保存为目标数据，从而利用规定格式的中间文件实现移动终端设备之间的共有数据信息的传输。中间文件如果作为原始数据的备份文件，则可以从中获取原始数据的共有字段信息。

下面以第一移动终端设备向第二移动终端设备之间进行数据传输为例进行详细说明。

如图1所示，第一移动终端设备对数据的处理包括如下步骤：

S101、根据规定格式的中间文件中包含的指定条目，从本终端设备保存从原始数据中获取各指定条目对应的数据字段；

S102、生成中间文件，所述中间文件符合规定格式，其中包括各指定条目和各指定条目对应的数据字段；

S103、发送符合规定格式的中间文件。

如图2所示，第二移动终端设备的处理主要包括如下步骤：

S201、接收符合规定格式的中间文件，所述中间文件中包括各指定条目和对应的数据字段；

S202、根据规定格式中包含的各指定条目，从中间文件中获取各指定条目对应的数据字段；

S203、生成本终端支持的目标数据，目标数据中包含各指定条目对应的数据字段。

由于中间文件的格式是预先规定好的，因此本发明实施例提供的技术方案中，只需要在移动终端设备上设置进行数据转换的转换装置，第一移动终端设备利用该装置设置格式转换单元可以将指定条目和对应数据转换为中间文件的，第二移动终端设备利用该转换装置从符合规定格式的中间文件中获取各指定条目对应的数据字段，并按照第二移动终端设备支持的格式将各指定条目对应的数据字段保存为目标数据。

第一移动终端设备和第二移动终端设备各自的转换装置还可以设置在第三方设备上，例如计算机上，第一移动终端设备和第二移动终端设备分别通过总线连接到第三方设备后，第一移动终端设备和第二移动终端设备的转换装置之间通过内部通信接口连接，第一移动终端设备的转换装置通过总线从第一移动终端设备上获取指定条目的数据并生成符合规定格式的中间文件，通过内部接口将中间文件发送给第二移动终端设备的转换装置，第二移动终端设备的转换装置生成目标数据后，将目标数据发送给第二移动装置，从而完成移动终端设备之间的数据传输。

事实上，由于中间文件中包含原始数据中的大部分信息，所以可以作为原始数据的备份文件进行保存，如果中间文件时在第一移动终端设备上生成的，则中间文件可以保存在第一移动终端设备上的存储区域中，如果在第三方设备上生成的，则中间文件可以保存在第三方设备的存储区域中。

移动终端设备上的原始数据包括各种类型，例如：消息类数据、电话本类数据或邮件类数据，消息类数据又进一步包括SMS消息类数据、IM消息类数据或MMS类数据等。因此为识别各类原始数据，还可以为每一种类型的原始数据设定对应的类型标识，不同类原始数据各自对应不同的类型标识，在中间文件中利用类型标识区别各类原始数据。

本发明实施例提供的技术方案中，可以灵活设定各种传输模式，用户可以通过不同的数据传输指令选择其中的一种模式，例如每次传输一条SMS消息，或者同时传输多条SMS消息，这时需要在中间文件中设置编码信息，用于区别SMS消息对应的指定条目及数据字段息；还可以同时传输不同类型的原始数据，例如将电话本类数据和消息类数据一起传输等。

如图3所示，本发明实施例提供一种移动终端设备数据的转换系统，包括第一移动终端设备31和第二移动终端设备32，第一移动终端设备31和第二移动终端设备32之间通过红外或蓝牙无线连接，其中：

如图4所示，第一移动终端设备31包括：

传输指令接收单元311，用于接收数据传输指令；

原始数据存储单元312、第一数据存储控制单元313和第一格式转换单元314，所述第一格式转换单元314根据传输指令接收单元311接收的原始数据传输指令，通过所述第一数据存储控制单元313从原始数据存储单元312中获取指定条目对应的数据字段，并生成符合规定格式的中间文件，所述中间文件中包含指定条目和每一个指定条目对应的数据字段；

中间文件发送单元315，用于将所述中间文件发送给第二移动终端设备32。

如图5所示，第二移动终端设备32包括：

中间文件接收单元321，用于接收第一移动终端设备31发送的中间文件；

第二格式转换单元322、第二数据存储控制单元323和目标数据存储单元324，所述第二格式转换单元322从中间文件接收单元321接收的中间文件中获取各指定条目对应的数据字段，并通过所述第二数据存储控制单元323按照移动终端设备支持的格式，在所述目标数据存储单元中324将各指定条目对应的数据字段保存为目标数据。

进一步如图6所示，如果需要将中间文件保存为原始数据的备份文件，则第一移动终端设备上还包括：

中间文件存储单元316，用于存储所述第一格式转换单元314生成的中间文件。

由于移动终端之间的数据传输通常是双向的，第一移动终端设备上也可以设置中间文件接收单元和第二转换单元，用于从第二移动终端设备接收中间文件并转换为第一移动终端设备支持的目标数据。第二移动终端设备上也可以设置传输指令接收单元、原始数据存储单元、数据存储控制单元和第一格式转换单元，用于生成中间文件并发送给第一移动终端设备。这时，位于同一移动终端设备上的第一格式转换单元和第二格式转换单元合并设置，中间文件发送单元和中间文件接收单元合并设置。

如图7所示，本发明实施例中，第一移动终端设备31上除其它功能单元之外，第一格式转换单元314设置在第三方设备上，第二移动终端设备32上除其它功能单元之外，第二格式转换单元322也设置在第三方设备上，第一格式转换单元314和第二格式转换单元322通过内部通信接口连接，第一移动终端设备31和第二移动终端设备32分别通过总线连接第三方设备，这样通过第三方设备实现第一移动终端设备31和第二移动终端设备32之间的数据传输。

当然，第一格式转换单元314和第二格式转换单元322也可以分别设置在不同的第三方设备上，通过一个移动存储装置在格式转换单元之间传输中间文件。

参阅图6所示，第一数据存储控制单元、第一格式转换单元和中间文件存储单元形成了移动终端设备的数据备份系统。即使第一格式转换单元设置到第三方设备上，仍然可以为移动终端设备进行原始数据的备份。备份功能可以通过用户指令控制，也可以定期的自动执行，本发明实施例不限定具体的触发机制。

可见，本发明实施例提供的技术方案不需要统一移动终端设备上的数据存储格式，就可以方便实现移动终端设备之间数据的传输与互联互通。

本领域技术人员应当可以理解，本发明实施例提供的格式转换单元或其它功能单元，全部或部分是通过程序指令相关的硬件来完成，该程序可以存储在可读取存储介质中，可读取存储介质例如随机存储器、磁盘、光盘等。当该程序通过计算机运行后，可以实现移动终端设备之间的数据传输和备份。

本发明实施例中，中间文件可以采用txt文件或XML文件，其中：XML文件的格式可以使用DTD(Document Type Difinition，文档类型定义)/文档格式Schema描述。格式转换单元生成中间文件时，需要解析对应所述原始数据类型的规定格式，确定所述规定格式中包含的各指定条目；然后根据所述规定格式中包含的各指定条目，分别从所述原始数据中获取每一个指定条目对应的数据字段。格式转换单元从中间文件中获取各指定条目对应的数据字段时，也需要解析对应所述原始数据类型的规定格式，确定所述规定格式中包含的各指定条目；然后根据所述规定格式中包含的各指定条目，从所述中间文件中获取各指定条目对应的数据字段。

下面以移动终端设备直接传输数据为例，详细说明本发明技术方案。

实施例一、移动终端设备之间传输SMS数据

目前，移动终端设备存储的SMS数据包括：移动终端设备从网络侧收到的SMS数据、移动终端设备发送的SMS数据、在移动终端设备上编写的SMS数据草稿以及移动终端设备所接收到的发送报告等特殊的SMS数据。这些SMS数据形成SMS数据文件，根据确定的格式(或者用户选择的格式)存储在移动终端设备上，以供本地的SMS应用，如SMS的收件箱可以读取SMS数据，并且顺利地呈现给用户。由于各移动终端设备文件系统和操作系统、应用程序以及数据的存放方式不一样，所以各移动终端设备存放的SMS的方式可能不完全相同。

本实施例通过在移动终端设备设置格式转换单元实现SMS数据的传输，源移动终端设备完成SMS数据在源移动终端设备本地的存储，在数据传输时，设置在源移动终端设备上的格式转换单元读取本地存储的SMS数据中指定条目，并生成为数据传输所规定的中间文件格式，发送该中间文件给目的移动终端设备，目的移动终端设备上设置的格式转换单元解析中间文件后，获取需要的数据并存储为本移动终端设备支持的原始数据，然后存储在目标移动终端设备本地。

SMS需要保存的共有信息字段主要包括：

源地址字段，主要是指SMS的发送方的地址；

目的地址字段，主要是指SMS接收方的地址；

数据(Data)字段，主要是指SMS的主要内容，可能是文字，也可以是二进制内容；

时间信息(TimeStamp)字段，主要是指SMS的时间信息；

类型(Type)字段，主要是指SMS的类型，包括：接收的消息，发送的消息，草稿箱，Push消息，状态报告等内容。

该共有信息字段可以作为指定条目，需要包含在中间文件中。

生成中间文件的方式有很多，例如：

方式一、XML(Extensible Markup Language，可扩展标记语言)方式。其核心是用标记语言的方式来完成相应的数据转换的功能。各标记即为指定条目。由于XML方式是一个定义好规则的一种数据存储和传输的通用格式和方案，利用XML的方式，可以很轻松的实现数据传输。而且，在数据元素发生改变的情况下，只需要修改特定的DTD或Schema就可以让格式转换单元适应改变后的结果，而并不需要重新对格式转换单元进行修改，具有很大程度的适应能力。

XML实现的过程和文本方式比较对应，所不同的在于数据的格式和规则，是根据DTD和Schema来定义的。以下是相关的一个例子：

SMS数据中间文件的DTD的一种可能采用的形式，其中包括各指定条目，例如：ELEMENT Orignal_Address为SMS的发送方地址等：

<？xml version＝″1.0″encoding＝″UTF-8″？>

<！ELEMENT SMS_Bakup(Orignal_Address*，Destination_Address*，Date+，TimeStamp+，Type+)>

<！--SMS的备份的DTD的形式-->

<！ELEMENT Orignal_Address(#PCDATA)>

<！--主要是指SMS的发送方地址。-->

<！ELEMENT Destination_Address(#PCDATA)>

<！--主要是指SMS接收方的地址。-->

<！ELEMENT Date(#PCDATA)>

<！--主要是指SMS的主要内容，可能是文字，也可以是二进制内容。-->

<！ELEMENT TimeStamp(#PCDATA)>

<！--主要是指SMS的时间信息。-->

<！ELEMENT Type(MT_SMS？|MO_SMS？|Draft_SMS？|Delivery_Report？)>

<！--主要是指SMS的类型，目前主要包括4类。-->

<！ELEMENT MT_SMS(#PCDATA)>

<！--移动终端设备接收到的SMS类型-->

<！ELEMENT MO_SMS(#PCDATA)>

<！--移动终端设备发出的SMS类型。-->

<！ELEMENT Draft_SMS(#PCDATA)>

<！--移动终端设备本地编写的草稿SMS类型。-->

<！ELEMENT Delivery_Report(#PCDATA)>

<！--移动终端设备接收到的关于SMS的报告类型。-->

上面的DTD当中，主要规定了不同移动终端设备当中SMS共有的指定条目的格式，这其中包括了：

发件人的地址信息，在实际当中，发件人的地址信息和收件人的地址信息只存在一个，在本例当中，发件人和收件人的地址信息可以为空，也可以是一个或者多个，具体地址信息的数据根据具体的需求而定。

收件人的地址信息，在实际当中，发件人的地址信息和收件人的地址信息只存在一个，在本例当中，发件人和收件人的地址信息可以为空，也可以是一个或者多个，具体地址信息的数据根据具体的需求而定。

SMS的主要信息是SMS的主体内容，也就是SMS主要所携带的信息，可能是文字，也可能是其它形式的内容。对于长短信而言，这部分内容不在局限于140个字节，而可以是移动终端设备拼接完成后的长短信的内容；

SMS的时间信息，在这里主要包括年月日，以及以具体的小时、分钟和秒的信息；

SMS的类型等信息，在这里，主要根据不同用途的SMS进行分类，这些分类主要还是根据移动终端设备本地存储的SMS来区分的。比如说，从移动终端设备发出的SMS、移动终端设备接收到的SMS、移动终端设备本地存储的草稿SMS、移动终端设备存储的SMS的发送报告等，在中间文件中，可以为不同分类的SMS设定相应的标识信息。

移动终端设备A上SMS的原始数据以下面的逻辑形式存放在移动终端设备上的一块存储单元中：

A_Original_Address＝123456789

A_Destination_Address＝987654321

A_Data＝How Are You？

A_TimeStamp＝2007/6/19 GMT 00:00

A_SMS_Type＝Received SMS

A_Squene＝001

A_Status＝Read

移动终端设备A输出的包括指定条目数据字段的中间文件，采用XML的方式，形成如下一个XML的文档的形式：

<？xml version＝″1.0″encoding＝″UTF-8″？>

<！DOCTYPE SMS_Bakup xmls＝″http://www.sample.com/DTD/SMS-Bakup.dtd″>

<SMS_Bakup>

<Original_Address>123456789</Original_Address>

<Destination_Address>987654321</Destination_Address>

<SMS_Type>Received SMS</SMS_Type>

</SMS_Bakup>

上述的数据是一个XML的文档。其文档名可能是SMS_Bakup.xml。

如果传输同类型的原始数据，移动终端设备B生成的中间文件，和移动终端设备A所生成的中间文件格式完全相同，只是具体数据有差异。

移动终端设备B从移动终端设备A接收XML文档形式的中间文件，解析中间文件后根据各指定条目的数据字段生成以下形式的移动终端设备B支持的目标数据结构：

B_Original_Address＝123456789

B_Destination_Address＝987654321

B_Data＝How Are You？

B_TimeStamp＝2007/6/19 GMT 00:00

B_SMS_Type＝Received SMS

B_Message_Type＝SMS

通过上述的方式，就完成了SMS数据在不同的移动终端设备之间的传输。

方式二、其中，XML文档中间文件的格式还可以采用封装成二进制数据包的方式，则相应DTD如下所示，其中指定条目例如：ELEMENT Received_SMS表示短消息的类型等：

<？xml version＝″1.0″encoding＝″UTF-8″？>

<！ELEMENT SMS_Bakup_alternative(Sequence，SMS_Type，Data)>

<！ELEMENT Data(#PCDATA)>

<！ELEMENT Sequence(#PCDATA)>

<！ELEMENT SMS_Type(Received_SMS？|Delivery_SMS？|Draft_SMS？|Delivery_Report？)>

<！ELEMENT Received_SMS(#PCDATA)>

<！ELEMENT Delivery_SMS(#PCDATA)>

<！ELEMENT Draft_SMS(#PCDATA)>

<！ELEMENT Delivery_Report(#PCDATA)>

基于上述的DTD的方式，移动终端设备A生成的XML文档形式的中间文件如下所示：

<？xml version＝″1.0″encoding＝″UTF-8″？>

<！DOCTYPE SMS_Bakup_alternativexmls＝″http://www.sample.com/DTD/SMS-Bakup-Alternative.dtd″>

<SMS_Bakup_alternative>

<SMS_Type>

<Received_SMS>1</Received_SMS>

</SMS_Type>

</SMS_Bakup_alternative>

其中：

“0010101101010100000111111010101000000111111111111110101000000000001111111111”代表的内容则是本实施当中使用的一条SMS的二进制的形式，其中包含了SMS的所有信息和内容。

移动终端设备B接收中间文件后，解析中间文件并转化为本地存储的数据。

方式三：文本文件的方式。如txt等类似的文件的方式，事先规定好一定的信息组成的格式，格式转换单元根据规定的格式生成文本文件方式的文件。格式转换单元需要读取相关数据的时候，根据实现规定好的文本文件的规则进行读取和解析，并在解析完成之后提取相关的数据进行相应的存储，从而完成转化的过程。

文本文件的方式不仅仅局限于txt的方式，还可以采用其它的文本格式的方案，也可以采用自定义扩展名的方式。以下是一个例子：

存储在移动终端设备A上的SMS的原始数据可能采用下面的组织形式：

A_Original_Address＝123456789

A_Destination_Address＝987654321

A_Data＝How Are You？

A_TimeStamp＝2007/6/19 GMT 00:00

A_SMS_Type＝Received SMS

A_Squene＝001

A_Status＝Read

为了进行移动终端设备之间的数据传输，需要生成中间文件，本实施例中，采用事先定义好的规则来生成相应的文本文件，并在该文本文件当中保存SMS指定条目的数据以及相关条目。

中间文件例如：

SMS Data Bakup Version 1.0

Begin：

Original Address＝123456789

Destination Address＝987654321

Data＝How Are You？

TimeStamp＝2007/6/19 GMT 00:00

SMS Type＝Received SMS

End

如果这个中间文件是一个txt的文档，则可以命名为SMS.txt。

移动终端设备B接收移动终端设备A的中间文件，解析后获取相关数据，将会读入移动终端设备的SMS相应的存储控制模块，存储为移动终端设备B支持的目标数据，从而完成一个从外部数据到内部数据转换的过程。

完成转换后，移动终端设备B用于存储在本地移动终端设备上的目标数据的逻辑形式可能是：

B_Original_Address＝123456789

B_Destination_Address＝987654321

B_Data＝How Are You？

B_TimeStamp＝2007/6/19 GMT 00:00

B_SMS_Type＝Received SMS

B_Message_Type＝SMS

至此移动终端设备A到移动终端设备B的数据传输完成，移动终端设备B到移动终端设备A的数据传输完全相同。通过上述的过程，不同的移动终端设备之间可以实现SMS数据的自由交换，从而不必考虑对移动终端设备本身进行修改来提供相应的功能。

综上，通过本实施例当中所采用的方式，将SMS数据通过移动终端设备格式转换单元转化后，在不同的移动终端设备格式转换单元之间进行SMS数据的传输，然后利用移动终端设备格式转换单元的功能，将SMS数据转化成为本移动终端设备能够识别的SMS数据的方法可以有效地实现SMS数据在不同的移动终端设备之间的传输，这种方式改变了传统方式对移动终端设备的巨大改造，能够极大地提高数据传输的效率降低成本。

实施例二、推送(Push)消息类原始数据的传输

Push消息是为了服务器触发移动终端设备去获取服务器上相关信息，从而将部分的信息通过Push的方式下发到移动终端设备的消息。Push消息可以由很多种承载的方式，主要的消息可以分为两类，一类是SI(Services Indication，业务指示)消息，一类是SL(Services Loading，业务下载)消息。通过分析SI消息和SL消息的差异，并且比较目前移动终端设备上对SI和SL消息的存储方式，先将Push消息当中相对共有的部分进行总结。为了完整的表达Push消息的基本内容，并且完成移动终端设备之间Push消息数据的传输，至少需要通过下面的字段来完整的表达Push消息的信息。这些字段包括：

指示内容(Indication)字段。

信息内容(Infomation)字段。

其中，Indication字段包含的内容主要有：

Indication字段，主要是指该Push消息如何动作，指向何处。

Infomation字段，主要是指对该Push消息的用途描述。

超链接索引(href)字段，可选，主要是指该SI所指向的URI地址

SI标识(si-id)字段，可选，主要是指该SI的ID消息

创建者(created)字段，可选，主要是指该SI消息的创建时间

SI有效期(si-expires)字段，可选，主要是指该SI消息的失效时间

动作(action)字段，可选，主要是指该SI所采取的动作

其取值可以包括，signal-none，signal-low，signal-medium，signal-high，delete。默认的取值为″signal-medium″。

Information字段当中包括的数据主要有：

描述内容(item)字段，必选，主要是指该SI的描述信息。

分类等级(class)字段，必选，主要是指该Information的重要程度。

class取值为NMTOKEN

SL当中的数据字段还包括：

超链接索引(href)字段，必选，主要是指SL所指向的超链接地址，

动作(action)字段，必选，主要是指针对SL所采用的动作，

Action取值为execute-low，execute-high，cache当中的一种，默认的取值为″execute-low″。

上面是为了完整的表达移动终端设备所存储的Push消息所提取的公共的字段信息，这些共有字段信息可以作为指定条目的数据字段，包含在中间文件中进行传输。由于不同移动终端设备对于Push消息处理的方法不同，部分的移动终端设备还可能基于实现的考虑增加了部分的辅助信息，该辅助信息并不影响本发明实施例的具体实施。

下面举一个Push消息的例子，简单的说明如何在两个数据不完全兼容的移动终端设备之间进行Push消息数据的传输的过程。

首先，假定存在两个移动终端设备，移动终端设备A和移动终端设备B。移动终端设备的作用主要提供数据在本地的存储，为了使移动终端设备之间的数据能够在A和B移动终端设备之间顺利地传输，需要利用移动终端设备格式转换单元来进行移动终端设备A和B当中数据和中间文件之间的转换工作。

存储在移动终端设备A上的Push消息数据可能采用下面的数据组织形式。

A->indication->description＝“You have 4 new emails”

A->indication->href＝“http://www.xyz.com/email/123/abc.wml”

A->indication->created＝″2001-07-31T 10:13:00Z″

A->indication->si-expires＝″2001-08-07T10:13:00Z″

为了实现将Push消息的数据通过本发明所提出的方法，中间文件可以采用如下的几种可能的方式：

方式一：XML文档形式

例如，Push消息数据传输的DTD的一种可能采用的形式：

<？xml version＝″1.0″encoding＝″UTF-8″？>

<！ELEMENT Push_Message_Bakup(si？，sl？)>

<！ELEMENT si(indication，info？)>

<！ELEMENT indication(#PCDATA)>

<！ATTLIST indication

href％URI；#IMPLIED

si-id CDATA#IMPLIED

created％Datetime；#IMPLIED

si-expires％Datetime；#IMPLIED

action(signal-none|signal-low|signal-medium|signal-high|delete)″signal-medium″

>

<！ELEMENT info(item+)>

<！ELEMENT item(#PCDATA)>

<！ATTLIST item

class NMTOKEN#REQUIRED

>

<！ELEMENT sl EMPTY>

<！ATTLIST sl

href％URI；#REQUIRED

action(execute-low|execute-high|cache)″execute-low″

>

<！ENTITY％Datetime″CDATA″>

<！ENTITY％URI″CDATA″>

上面的DTD当中，主要规定了不同移动终端设备当中的指定条目，其中包括：

SI的Indication，其中包括：SI的链接地址、SI的消息ID、SI的创建日期、SI的失效日期、SI所需要移动终端设备采取的动作；

SI的Information，其中包括：SI的信息描述、以及SI的重要程度；

SL的属性信息，其中包括：SL的超链接地址、针对SL所需要采取的动作和行动；

移动终端设备格式转换单元根据A的Push消息原始数据，形成一个XML文档形式的中间文件：

<？xml version＝″1.0″encoding＝″UTF-8″？>

<！DOCTYPE Push_Message_Bakupxmls＝″http://www.sample.com/DTD/Push-Bakup.dtd″>

<Push_Message_Bakup>

<si>

<indication href＝′″http://www.xyz.com/email/123/abc.wml′″

created＝′created＝″2001-07-31 T 10:13:00Z′″

si-expires＝′″2001-08-07 T 10:13:00Z′″>

You have 4 new emails

</indication>

</si>

</Push_Message_Bakup>

上述文件是一个XML的文档，其文档名可能是Push_Bakup.xml。

由于Push消息具有SI和SL两种。上述的例子是一个SI的实例，本实施例当中主要以SI为例，SL的例子如下所示：

<？xml version＝″1.0″encoding＝″UTF-8″？>

<Push_Message_Bakup>

</Push_Message_Bakup>

下面仍以SI为例，利用A所生成的Push Bakup.xml进行Push消息的数据传输，移动终端设备B解析获取的中间文件，生成移动终端设备B用于存储在本地移动终端设备上的数据，其格式可以如下所示：

B->Push->SI->indication->description＝“You have 4 new emails”

B->Push->SI->indication->href＝“http://www.xyz.com/email/123/abc.wml”

B->Push->SI->indication->created＝″2001-07-31 T 10:13:00Z″

B->Push->SI->indication->si-expires＝″2001-08-07T10:13:00Z″

B->Push->Message_Type＝Push_SI

通过上述的方式，就完成了Push消息的数据在不同的移动终端设备当中的传输的过程。

方式二、XML文档中间文件的格式还可以采用封装成二进制数据包的方式，可以参考的DTD可以参见如下的方式：

<？xml version＝″1.0″encoding＝″UTF-8″？>

<！ELEMENT Push_Message_Bakup(Message_Type，Sequence，Data)>

<！--用于对Push消息进行备份的DTD-->

<！ELEMENT Message_Type(SI？，SL？)>

<！ELEMENT SI(#PCDATA)>

<！--封装的在移动终端设备本地存储的SI-->

<！ELEMENT SL(#PCDATA)>

<！--封装的在移动终端设备本地存储的SL-->

<！ELEMENT Sequence(#PCDATA)>

<！--被转化的消息的序列号-->

<！ELEMENT Data(#PCDATA)>

<！--封装的在移动终端设备本地存储的Push消息的数据-->

假设Push消息在移动终端设备的存储是一个二进制的方式，则利用移动终端设备A和移动终端设备格式转换单元，将移动终端设备A所存储的数据按照用来进行数据传输的XML文档的DTD进行封装，形成了如下的中间文件：

<？xml version＝″1.0″encoding＝″UTF-8″？>

<！DOCTYPE Push_Message_Bakupxmls＝″http://www.sample.com/DTD/Push-Bakup-Alternative.dtd″>

<Push_Message_Bakup>

<Message_Type>

</Message_Type>

</Push_Message_Bakup>

其中：

“0100001111010101000000111111110100111111111111111110000111111111111111111111”为实施例当中Push消息的SI部分在移动终端设备A当中的二进制的存储形式。

移动终端设备B在获取到移动终端设备A的中间文件后，通过格式转换单元可以将解析，并且形成移动终端设备B能够识别和存储的格式，其转化后的结果如下所示：

B->Push->SI->indication->description＝“You have 4 new emails”

B->Push->SI->indication->href＝“http://www.xyz.com/email/123/abc.wml”

B->Push->SI->indication->created＝″2001-07-31T10:13:00Z″

B->Push->SI->indication->si-expires＝″2001-08-07T10:13:00Z″

B->Push->Message_Type＝Push_SI

还可以采用文本文件的方式，具体实现参见实施例一所示。

实施例三、Email原始数据的传输

分析Email需要保存的共有信息字段主要包括：

日期(Date)字段，主要包括Email的时间信息。

发送者(From)字段，主要包括Email发件人的相关信息。

主题(Subject)字段，主要包括Email的主题信息。

接收者(To)字段，主要包括Email收件人的相关信息。

回复地址(Reply-to)字段，主要包括该Email的回复地址信息。

多用途互联网邮件扩展(MIME)版本(MIME-version)字段，主要包括Email的MIME的版本号。

回复路径(Return-Path)字段，主要是标识连接到目的服务器所采用的路由。一般只是一个发送者地址，表明邮件直接传送给目的服务器。

传递信息(Delivered-To)字段，主要是说明邮件被传送到那个邮箱。

接收信息(Received)字段，该头部分分别代表的信息包括：

from hostname(从host得到)；

by hostname(由host收取)；

via physical-path(通过什么路径——邮件服务器)；

with protocol(使用什么协议)；

id message-id(消息ID号)；

for final destination(消息目的地址)；

time(时间标记)。

每一个邮件服务器都向每一条收到的消息添加一个自己新的Received字段。可以看到这封邮件有两个Received头字段。

抄送地址(CC字段)，主要是指抄送方地址。

密送地址(BCC字段)，主要是指暗抄地址。

消息标识(Message-ID)字段，主要是指消息唯一的识别ID。

内容传输编码方式信息(Content-Transfer-Encoding)字段，主要是指嵌入到消息中的二进制数据如何被编码成ASCII文本。

内容描述(Content-Description)字段，主要是指用来在邮件消息的文本中标识数据的ASCII描述。

内容属性(Content-Disposition)字段，主要是Content的内容归属。

内容标识(Content-ID)字段，主要是指用来在使用多目录内容的情况下，以一个唯一的标识代码去标识一个MIME会话。

内容类型(Content-type)字段，此头字段是动作开始的地方，标识了在MIME消息中封装的数据。

内容等级(Content-class)字段，主要是指Content的级别。

字符集(Charset)字段，主要是指字符的编码方式。

内容数据(Data)字段，主要是用来包含Content内容的具体编码。

附件名(Name)字段，主要是用来描述Content的名字。

附件文件名(Filename)字段，主要是用来描述附件的文件名。

将上述主要信息字段作为指定条目，需要包含在中间文件中，中间文件可以采用XML方式等。本领域技术人员可以参见实施例一或实施例二获得XML文件的DTD和XML文档，这里不再详细描述。

方式一、XML方式

Email数据传输的DTD的一种可能采用的形式。

<？xml version＝″1.0″encoding＝″UTF-8″？>

<！ELEMENT Email_Bakup(Return-Path？，Delivered-To*，Received*，Date+，CC？，BCC？，Message-ID*，From+，Subject*，To+，Reply-to*，MIME-version+，Content+)>

<！ELEMENT Content (Content-type*，charset*，Data*，Name*，Filename*，Content-Transfer-Encoding*，Content-Description*，Content-Disposition*，Content-ID*，Content-class*)>

<！ELEMENT Return-Path(#PCDATA)>

<！ELEMENT Delivered-To(#PCDATA)>

<！ELEMENT Received(#PCDATA)>

<！ELEMENT Date(#PCDATA)>

<！ELEMENT CC(#PCDATA)>

<！ELEMENT BCC(#PCDATA)>

<！ELEMENT Message-ID(#PCDATA)>

<！ELEMENT From(#PCDATA)>

<！ELEMENT Subject(#PCDATA)>

<！ELEMENT To(#PCDATA)>

<！ELEMENT Reply-to(#PCDATA)>

<！ELEMENT MIME-version(#PCDATA)>

<！ELEMENT Content-Transfer-Encoding(#PCDATA)>

<！ELEMENT Content-Description(#PCDATA)>

<！ELEMENT Content-Disposition(#PCDATA)>

<！ELEMENT Content-ID(#PCDATA)>

<！ELEMENT Content-type(#PCDATA)>

<！ELEMENT Content-class(#PCDATA)>

<！ELEMENT charset(#PCDATA)>

<！ELEMENT Data(#PCDATA)>

<！ELEMENT Name(#PCDATA)>

<！ELEMENT Filename(#PCDATA)>

上面的DTD当中，主要规定了不同移动终端设备当中所共有的Email相关的信息格式，这其中包括了：

Email的时间信息；

Email发件人的相关信息；

Email的主题信息；

Email收件人的相关信息；

Email的回复地址信息；

Email的MIME的版本号信息；

Email被传送到哪个邮箱的信息；

Email抄送方地址信息；

Email暗抄地址信息；

Email消息唯一的识别ID信息等和Email相关的信息。

Email的原始数据在移动终端设备A上的逻辑形式可以采用下面的方式：

A_From＝Alice<Alicesample.com>

A_To＝Bobsample.com

A_Cc＝Mikesample.com

A_Subject＝FYI

A_Date＝Tue，26 Jun 2007 14:15:16+0800

A_MIME-Version＝1.0

A_Content-Type＝multipart/mixed

A_Type＝Received Email

A_Squene＝001

A_Status＝Read

A_Attachement＝Yes

A_AttacheNumber＝2

A_AttachFileName＝Email/Attachment/FYI.html

A_AttachFileName＝Email/Attachment/Attachment.txt

除了关于Email相关的描述信息之外，还有Email相关的附件的信息。Email的附件应该是一个一个的文件，它主要存放在移动终端设备的相关的存储单元当中。

FYI.html文件和Attachment.txt文件都放置在存储单元当中，并进行相应的存储。

移动终端设备A输出XML文档形式的中间文件，例如：

<？xml version＝″1.0″encoding＝″UTF-8″？>

<！DOCTYPE Email_Bakup xmls＝″http://www.sample.com/DTD/Email-Bakup-Final.dtd″>

<Email_Bakup>

<From>″Alice<Alicesample.com>″</From>

<To>″Alicesample.com″</To>

<Cc>″Alicesample.com″</Cc>

<MIME-Version>″1.0″</MIME-Version>

<Content-Type>″multipart/mixed″</Content-Type>

<Content-Type>text/plain</content-Type>

<Content-Transfer-Encoding>base64</Content-Transfer-Encoding>

<Data>

″RllJDQoNCg0KDQpDaGVuIEd1b3FpYW8gs8K5+sfHICBSJkQgRW5naW5lZXINCk1vYmlsZSBUZXJt

aW5hbCBEZXAuDQpIdWF3ZWkgVGVjaG5vbG9naWVzIENvLixMdGQuDQpIdWEgV2VpIEJsZC4sTm8u

MyBYaW54aSBSZC4sU2hhbmctRGkgSW5mb3JtYXRpb24gDQpJbmR1c3RyeSBCYXNlLEhhaS1EaWFu

IERpc3RyaWN0IEJlaWppbmcgUC5SLkNoaW5hIA0KWklQo7oxMDAwODUgIA0KVGVsOiArODYtMTAt

ODI4MzYzNjYNCkZBWKO6Kzg2LTEwLTgyODM2MTMzDQpFbWFpbDogY2hlbmd1b3FpYW9AaHVhd2Vp

LmNvbQ＝＝″

</Data>

</Content>

<Content-Type>text/html<content-Type>

<Content-Transfer-Encoding>″base64″</Content-Transfer-Encoding>

<data>

″PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv

L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu

dD0idGV4dC9odG1sOyBj aGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4w

MC4yODAwLjE1NjEiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8

Qk9EWSBiZ0NvbG9yPSNjY2U4Y2Y+DQo8RElWPjxGT05UIHNpemU9Mj5GWUk8L0ZPTlQ+PC9ESVY+

DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9

Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXpl

PTI+Q2hlbiBHdW9xaWFvILPCufrHxyZuYnNwOyBSJmFtcDtEIEVuZ2luZWVyPEJSPk1vYmlsZSBU

ZXJtaW5hbCANCkR1cC48QlI+SHVhd2VpIFR1Y2hub2xvZ2llcyBDby4sTHRkLjxCUj5IdWEgV2Vp

IEJsZC4sTm8uMyBYaW54aSBSZC4sU2hhbmctRGkgDQpJbmZvcm1hdGlvbiA8QlI+SW5kdXN0cnkg

QmFzZSxIYWktRGlhbiBEaXN0cmljdCBCZWlqaW5nIFAuUi5DaGluYSANCjxCUj5aSVCjujEwMDA4

NSZuYnNwOyA8QlI+VGVsOiArODYtMTAtODI4MzYzNj Y8QlI+RkFYo7orODYtMTAtODI4MzYxMzM8

QlI+RW1haWw6IA0KPEEgDQpocmVmPSJtYWlsdG86Y2hlbmd1b3FpYW9AaHVhd2VpLmNvbSI+Y2hl

bmd1b3FpYW9AaHVhd2VpLmNvbTwvQT48L0ZPTlQ+PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg＝＝″

</data>

</Content>

<Content-Type>″text/plain″</Content-Type>

<name>″attachment.txt″<name>

<Content-Transfer-Encoding>″7bit″</Content-Transfer-Encoding>

<Content-Disposition>attachment</Content-Disposition>

<filename>″attachment.txt″</filename>

<data>

″just test.″

</data>

</content>

</Email_Bakup>

XML文档的文档名可能是Email_Bakup.xml。

移动终端设备B获取的中间文件就是移动终端设备A所生成的XML的文档，例如Email_Bakup.xml。

移动终端设备B通过格式转换单元解析中间文件并存储在本地移动终端设备，原始数据例如：

B->Email->To＝Bobsample.com

B->Email->Cc＝Mikesample.com

B->Email->Subject＝FYI

B->Email->Date＝Tue，26Jun 2007 14:15:16+0800

B->Email->MIME-Version＝1.0

B->Email->Content-Type＝multipart/mixed

B->Email->Type＝Received Email

B->Email->Attachement＝Yes

B->Email->AttacheNumber＝2

B->Email->AttachFile_1->Name＝Email/Attachment/FYI.html

B->Email->AttachFile_2->Name＝Email/Attachment/Attachment.txt

通过上述的方式，就完成了Email数据在不同的移动终端设备之间的传输。

其中，Email的内容还可以的方式或者文本文件的形式。

方式二、XML采用完全封装成数据包的形式

可以参考的DTD可以参见如下的方式：

<？xml version＝″1.0″encoding＝″UTF-8″？>

<！ELEMENT Email_Bakup(Message_Type，Sequence，Data)>

<！--用于对Email消息进行备份的DTD-->

<！ELEMENT Message_Type(Send_Email？，Received_Email？，Draft_Email？)>

<！ELEMENT Send Email(#PCDATA)>

<！--封装的在移动终端设备本地存储的发送的Email-->

<！ELEMENT Received Email(#PCDATA)>

<！--封装的在移动终端设备本地存储的接收的Email-->

<！ELEMENT Draft_Email(#PCDATA)>

<！--封装的在移动终端设备本地存储的草稿的Email-->

<！ELEMENT Sequence(#PCDATA)>

<！--被转化的消息的序列号-->

<！ELEMENT Data(#PCDATA)>

<！--封装的在移动终端设备本地存储的Email的数据-->

由移动终端设备格式转换单元转化的XML文档形式的中间文件如下所示：

<？xml version＝″1.0″encoding＝″UTF-8″？>

<！DOCTYPE Email_Bakup xmls＝″http://www.sample.com/DTD/Email-Bakup-Alternative.dtd″>

<Email_Message_Bakup>

<Message_Type>

<Received_Email>1</Received_Email>

</Message_Type>

</Email_Message_Bakup>

其中：

“01000011110101010000001111111101001111111111111111100001111111111111111110101111010101010101011111111111111111111000001111111110001010101010101010101001010101010101011111111000011011111010111111111111111111111111111111111111111111111110000101010111111111111111111111111111111111111111111110000000101111111111111111111111111111111111111111111111111111111111111111111111111111111111100000000000101111111111111111011111110000000000000000000000000000000000000000000000000000000000000000000001111”为实施例当中Email消息在移动终端设备A当中的二进制的存储形式。

移动终端设备B在获取中间文件并转化后的结果如下所示：

B->Email->To＝Bobsample.com

B->Email->Cc＝Mikesample.com

B->Email->Subject＝FYI

B->Email->Date＝Tue，26 Jun 2007 14:15:16+0800

B->Email->MIME-Version＝1.0

B->Email->Content-Type＝multipart/mixed

B->Email->Type＝Received Email

B->Email->Attachement＝Yes

B->Email->AttacheNumber＝2

B->Email->AttachFile_1->Name＝Email/Attachment/FYI.html

B->Email->AttachFile_2->Name＝Email/Attachment/Attachment.txt

通过上述的方式，就完成了Email数据在不同的移动终端设备当中的传输的过程。

实施例四、MMS消息原始数据的传输

根据MMS业务的特点，将MMS需要保存的共有信息字段主要包括：

消息类型(Message_Type)字段，主要是标识消息的类型，如MM1_retrieve.RES。

多媒体消息版本信息(MMS_Version)字段，主要是标识MMS消息的版本信息。

消息标识(Message_ID)字段，主要是标识MM的消息ID。

发送者地址(Sender_address)字段，主要是表示最近处理过MM(即，提交过或转发过MM)的移动终端设备的地址。如果始发方移动终端设备已经请求对接收方隐藏其地址，则它的地址不会提供给接收方。

内容类型(Content_type)字段，主要是表示MM内容的内容类型。

接收者地址(Recipient_address)字段，主要是表示MM接收方的地址。可能存在多个地址。

消息等级(Message_class)字段，主要是表示消息的类别(例如，个人服务、广告服务和信息服务)。

时间日期(Date_and_time)字段，主要是表示移动终端设备最近处理(即，提交或转发)MM的时间和日期。

优先级(Priority)字段，主要是表示消息的优先级(重要性)(如果始发方移动终端设备已指定)。

主题(Subject)字段，主要是表示整个多媒体消息的标题(如果MM的始发方移动终端设备已指定)。

消息状态(MM_State)字段，主要是表示MM状态。入局MM可能缺少该状态，持久存储的MM存在该状态。

内容(Content)字段，主要是表示多媒体消息的内容(由MM的始发方移动终端设备指定)。

共有信息字段可以作为指定条目，相对应的数据字段和条目信息需要包含中间文件中，中间文件的形式可以是XML方式等。

方式一

例如，MMS数据交换的DTD的一种可能采用的形式：

<？xml version＝″1.0″encoding＝″UTF-8″？>

<！ELEMENT MMS_Bakup (Message_Type+， MMS_Version+， Message_ID+，Sender_address*，Content_type+，Recipient_address*，Message_class*，Date_and_time+，Priority*，Subject*，MM_State*，Content*)>

<！ELEMENT Message_Type(#PCDATA)>

<！--将此消息标识为MM1_retrieve.RES。-->

<！ELEMENT MMS_Version(#PCDATA)>

<！--标识MMSRelay/Server所支持接口的版本。-->

<！ELEMENT Message_ID(#PCDATA)>

<！--MM的消息ID。-->

<！ELEMENT Sender_address(#PCDATA)>

<！--最近处理过MM(即，提交过或转发过MM)的移动终端设备的地址。如果始发方移动终端设备已经请求对接收方隐藏其地址，则它的地址不会提供给接收方。-->

<！ELEMENT Content_type(#PCDATA)>

<！--MM内容的内容类型。-->

<！ELEMENT Recipient_address(#PCDATA)>

<！--MM接收方的地址。可能存在多个地址。-->

<！ELEMENT Message_class(#PCDATA)>

<！--消息的类别(例如，个人服务、广告服务和信息服务)-->

<！ELEMENT Date_and_time(#PCDATA)>

<！--移动终端设备最近处理(即，提交或转发)MM的时间和日期。-->

<！ELEMENT Priority(#PCDATA)>

<！--消息的优先级(重要性)(如果始发方移动终端设备已指定)。-->

<！ELEMENT Subject(#PCDATA)>

<！--整个多媒体消息的标题(如果MM的始发方移动终端设备已指定)。-->

<！ELEMENT MM State(#PCDATA)>

<！--MM状态。入局MM可能缺少该状态，持久存储的MM存在该状态。-->

<！ELEMENT Content(charset，Content-Transfer-Encoding，Content-Location，Data)>

<！--多媒体消息的内容(由MM的始发方移动终端设备指定)。-->

<！ELEMENT charset(#PCDATA)>

<！ELEMENT Content-Transefr-Encoding(#PCDATA)>

<！ELEMENT Content-Location(#PCDATA)>

<！ELEMENT Data(#PCDATA)>

上面的DTD当中，主要规定了不同移动终端设备当中所共有的MMS相关的信息格式，这其中包括了：

MMS消息的类型信息；

MMS消息的版本信息；

MMS的消息ID信息；

MMS发送者的地址信息；

MMS内容的内容信息；

MMS接收方的地址；

MMS消息的类别信息；

MMS的时间和日期信息；

MMS消息的优先级(重要性)信息；

MMS消息的标题信息；

MMS的状态信息；

MMS的具体内容信息等内容。

如前所述，MMS的信息原始数据在移动终端设备A上的逻辑形式存放在移动终端设备上的一块存储单元中：

A_Message_Type＝MM1_retrieve.RES

A_MMS_Version＝1.2

A_Message_ID＝060717544991000009318

A_Sender_address＝+8613910111111mmsc-bj-rsv.monternet.com

A_Content_type＝Multipart/Related

A_Recipient_address＝Alicesample.com

A_Message_class＝Personal

A_Date_and_time＝Wed，07Jun 2006 17:54:49+0800

A_Priority＝Normal

A_Subject＝Hello

A_MM_State＝Retrieved

除了在数据结构当中需要包含上述的内容之外，还需要将MMS所包含的数据内容同上面的MMS的消息相对应。因此，可以增加下面的内容：

A_AttachFile＝MMS/S.smil

A_AttachFile＝MMS/8712df01.asc

S.smil数据和8712df01.asc数据，都以文件的方式存放在移动终端设备的MMS文件夹下面。

移动终端设备A通过格式转换单元形成XML文档形式的中间文件例如：

<？xml version＝″1.0″encoding＝″UTF-8″？>

<！DOCTYPE MMS_Bakup xmls＝″http://www.sample.com/DTD/MMS-Bakup.dtd″>

<MMS_Bakup>

<Message_Type>″MM1_retrieve.RES″</Message_Type>

<！--必选-->

<！--将此消息标识为MM1_retrieve.RES。-->

<MMS_Version>″1.2″</MMS_Version>

<！--必选-->

<！--标识MMSRelay/Server所支持接口的版本。-->

<Message_ID>″060717544991000009318″</Message_ID>

<！--必选-->

<！--MM的消息ID。-->

<Sender_address>″+8613910111111mmsc-bj-rsv.monternet.com″</Sender_address>

<！--可选-->

<Content_type>

<type>″Multipart/Related″</type>

<type>″application/smil″</start>

</Content_type>

<！--必选-->

<！--MM内容的内容类型。-->

<Recipient_address>″Alicesample.com″</Recipient_address>

<！--可选-->

<！--MM接收方的地址。可能存在多个地址。-->

<Message_class>″Personal″</Message_class>

<！--可选-->

<！--消息的类别(例如，个人服务、广告服务和信息服务)-->

<Date_and_time>″Wed，07 Jun 2006 17:54:49+0800″</Date_and_time>

<！--必选-->

<Priority>″Normal″</Priority>

<！--可选-->

<Subject>″Hello″</Subject>

<！--可选-->

<MM_State>″Retrieved″</MM_State>

<！--可选-->

<！--可选-->

<Content-Type>″text/plain″</Content-Type>

<Content-Transfer-Encoding>″Base64″</Content-Transfer-Encoding>

<Content-Location>″8712df01.asc″</Content-Location>

<Data>″MDblubQ25pyINuaXpeaYr+S4qjY25aSn6aG655qE5ZCJ56Wl5pel5a2Q44CC5Zyo6L+Z5Liq

576O5aW955qE5pe25Yi777yM56Wd5oKo5bm456aP5ZCJ56Wl77yM5LqL5Lia6aG66aG65Yip

5Yip77yM55Sf5rS75byA5byA5b+D5b+D77yBAA＝＝″

</Data>

</Content>

<！--可选-->

<Content-Type>″application/smil″</Content-Type>

<Content-Transfer-Encoding>″Base64″</Content-Transfer-Encoding>

<Content-Location>″s.smil″</Content-Location>

<Data>″PHNtaWw+CjxoZWFkPgo8bGF5b3V0Pgo8cm9vdC1sYXlvdXQgd2lkdGg9IjI0MCIgaGVpZ2h0

PSIyNzQiLz4KPHJlZ2lvbiBpZD0iSW1hZ2UiIHdpZHRoPSIxMDAlIiBoZWlnaHQ9IjEwMCUi

IGxlZnQ9IjAlIiB0b3A9IjAlIiAvPgo8cmVnaW9uIGlkPSJUZXh0IiB3aWR0aD0iMTAwJSIg

aGVpZ2h0PSIxMDAlIiBsZWZ0PSIwJSIgdG9wPSIwJSIgLz4KPC9sYXlvdXQ+CjwvaGVhZD4K

PGJvZHk+CjxwYXIgZHVyPSI3MDAwbXMiPgo8dGV4dCBzcmM9Ijg3MTJkZjAxLmFzYyIgcmVn

aW9uPSJUZXh0IiBkdXI9IjcwMDBtcyIgLz4KPC9wYXI+CjwvYm9keT4KPC9zbWlsPgo＝″</Data>

</Content>

<！--多媒体消息的内容(由MM的始发方移动终端设备指定)。-->

</MMS_Bakup>

XML文档的文档名可能是MMS_Bakup.xml。

移动终端设备B解析移动终端设备A的中间文件，存储在本地移动终端设备上：

B->MMS->Message_Type＝MM1_retrieve.RES

B->MMS->MMS_Version＝1.2

B->MMS->Message_ID＝060717544991000009318

B->MMS->Sender_address＝+86139111111mmsc-bj-rsv.monternet.com

B->MMS->Content_type＝Multipart/Related

B->MMS->Recipient_address＝Alicesample.com

B->MMS->Message_class＝Personal

B->MMS->Date_and_time＝Wed，07Jun 200617:54:49+0800

B->MMS->Priority＝Normal

B->MMS->Subject＝Hello

B->MMS->MM State＝Retrieved

B->MMS->AttachFile_1＝MMS/Attachment/S.smil

B->MMS->AttachFile_2＝MMS/Attachment/8712df01.asc

MMS所包含的数据内容需同上面的MMS的消息相对应，可以存储在移动终端设备的MMS/Attachment/文件夹下。

通过上述的方式，就完成了MMS数据在不同的移动终端设备当中的交换的过程。

当然，MMS的内容可以是采用这种DTD的方式，也可以采用将MMS数据完全封装成数据包的方式来进行存储。所以，下面的DTD是另外一种可能的方式。

方式二、XML封装Push消息在移动终端设备的存储内容。其可以参考的DTD可以参加如下的方式：

<？xml version＝″1.0″encoding＝″UTF-8″？>

<！ELEMENT Email_Bakup(Message_Type，Sequence，Data)>

<！--用于对Email消息进行备份的DTD-->

<！ELEMENT Message_Type(Send_Email？，Received_Email？，Draft_Email？)>

<！ELEMENT Send_Email(#PCDATA)>

<！--封装的在移动终端设备本地存储的发送的Email-->

<！ELEMENT Received Email(#PCDATA)>

<！--封装的在移动终端设备本地存储的接收的Email-->

<！ELEMENT Draft_Email(#PCDATA)>

<！--封装的在移动终端设备本地存储的草稿的Email-->

<！ELEMENT Sequence(#PCDATA)>

<！--被转化的消息的序列号-->

<！ELEMENT Data(#PCDATA)>

<！--封装的在移动终端设备本地存储的Email的数据-->

假设Email消息在移动终端设备的存储是一个二进制的方式。利用移动终端设备A和格式转换单元，将移动终端设备A所存储的数据按照用来进行数据交换的XML文档的DTD进行封装，格式转换单元转化的XML文档形式中间文件如下所示：

<？xml version＝″1.0″encoding＝″UTF-8″？>

<！DOCTYPE MMS_Bakup xmls＝″http://www.sample.com/DTD/MMS-Bakup-Alternative.dtd″>

<MMS_Message_Bakup>

<Message_Type>

<Received_MMS>1</Received_MMS>

</Message_Type>

</MMS_Message_Bakup>

”11111111110000101010111111111111111111111111111111111111111111110000000101111111111111111111111111111111111111111111111111111111111111111111111111111111111111100000000000101111111111111111011111110000010110000100001001000011100001111000110000000111110000100000111000100010100010010010001010000001001111010000111101010100000011111111010011111111111111111001001111111111111111110101100000000000000011010101010101011111111111111111111000001111111110001010101011110101010101001010101010101011111111000011011111010111111111111111111111111111111111111”

移动终端设备B在获取到该中间文件后，通过格式转换单元可以将该数据将XML当中MMS消息的二进制存储内容进行提取，并且形成移动终端设备B能够识别和存储的格式，其转化后的结果如下所示：

B->MMS->Message_Type＝MM1_retrieve.RES

B->MMS->MMS_Version＝1.2

B->MMS->Message_ID＝060717544991000009318

B->MMS->Sender_address＝+86139111111mmsc-bj-rsv.monternet.com

B->MMS->Content_type＝Multipart/Related

B->MMS->Recipient_address＝Alicesample.com

B->MMS->Message_class＝Personal

B->MMS->Date_and_time＝Wed，07Jun 200617:54:49+0800

B->MMS->Priority＝Normal

B->MMS->Subject＝Hello

B->MMS->MM State＝Retrieved

B->MMS->AttachFile_1＝MMS/Attachment/S.smil

B->MMS->AttachFile_2＝MMS/Attachment/8712df01.asc

通过上述的方式，就完成了MMS数据在不同的移动终端设备当中的交换的过程。MMS的附件应该是一个一个的文件，它主要存放在移动终端设备的相关的存储单元当中。

S.smil文件和8712df01.asc文件都放置在存储单元中进行相应的存储。

实施例五、IM数据的传输

分析IM数据，IM数据需要保存的共有信息字段主要包括：

发件人URI(通用资源标识，Universal Resource Identifier)(From)字段，主要是指IM的发送方的URI。

收件人URI(To)字段，主要是指IM接收方的URI。

数据(Data)字段，主要是指IM的主要内容，可能是文字，也可以是二进制内容。

发送时间(Time)字段，主要是指IM的发送时间。

内容类型(Content-Type)字段，主要是指IM的内容类型。

媒体类型(Type)字段，主要是指IM的类型。

UA字段，主要是指IM的UserAgent的信息

上述共有字段可以作为指定条目，需要在中间文件中传输，中间文件的形式可以采用XML方式等。

方式一、XML方式

DTD的一种可能采用的形式例如：

<？xml version＝″1.0″encoding＝″UTF-8″？>

<！ELEMENT IM_Bakup(From，To，Subject，Date，Time，Message_Type，UA)>

<！ELEMENT From(#PCDATA)>

<！ELEMENT To(#PCDATA)>

<！ELEMENT Content-Type(#PCDATA)>

<！ELEMENT Data(#PCDATA)>

<！ELEMENT Time(#PCDATA)>

<！ELEMENT Message-Type(#PCDATA)>

<！ELEMENT UA(#PCDATA)>

上面的DTD当中，主要规定了不同移动终端设备当中所共有的IM相关的信息格式，这其中包括了：

发件人的URI；

收件人的URI；

IM的主要数据内容；

IM发送的时间；

IM的媒体类型

IM的类型等信息；

IM格式转换单元的用于代理(User Agent)的信息。

IM的原始数据在移动终端设备A上以下述逻辑形式存储在一个存储单元中：

A_From＝Alicesample.com

A_To＝Bobsample.com

A_Content_Type＝text/plain

A_Data＝How Are You？

A_Time＝Wed，07 Jun 2006 17:54:49+0800

A_Type＝Received IM

A_UA＝Microsoft MSN V 7.0

A_Squene＝001

A_Status＝Read

形成XML文档形式的中间文件例如：

<？xml version＝″1.0″encoding＝″UTF-8″？>

<！DOCTYPE IM_Bakup xmls＝″http://www.sample.com/DTD/IM-Bakup.dtd″>

<IM_Bakup>

<From>”Alicesample.com”</From>

<To>”Bobsample.com”</To>

<Content-Type>”text/plain”</Content-Type>

<Type>Received IM</Type>

<UA>”Microsoft MSN V 7.0”</UA>

</IM_Bakup>

上述的文件是一个XML的文档，其文档名可能是IM_Bakup.xml。

移动终端设备B获取中间文件，本地格式转换单元解析其实是移动终端设备A所生成的XML的文档。

移动终端设备B用于存储在本地移动终端设备上的数据：

B->IM->From＝Alicesample.com

B->IM->To＝Bobsample.com

B->IM->Content_Type＝text/plain

B->IM->Subject＝How Are You？

B->IM->Data＝How Are You？

B->IM->Time＝Wed，07 Jun 2006 17:54:49+0800

B->IM->Type＝Received IM

B->IM->UerAgent＝Microsoft MSN V 7.0

B->IM->Squene＝001

B->IM->Status＝Read

通过上述的方式，就完成了IM数据在不同的移动终端设备当中的传输。

其中，IM的内容可以是采用这种DTD的方式，也可以采用将IM数据完全封装成数据包的方式。

方式二、XML封装IM消息原始数据

DTD可以参见如下的方式：

<？xml version＝″1.0″encoding＝″UTF-8″？>

<！ELEMENT IM_Message_Bakup(Message_Type，Sequence，Data)>

<！--用于对IM消息进行备份的DTD-->

<！ELEMENT Message_Type(Send_IM？，Received_IM？，Draft_IM？)>

<！ELEMENT Send_IM(#PCDATA)>

<！--封装的在移动终端设备本地存储的发送的IM-->

<！ELEMENT Received_IM(#PCDATA)>

<！--封装的在移动终端设备本地存储的接收的IM-->

<！ELEMENT Draft_IM(#PCDATA)>

<！--封装的在移动终端设备本地存储的草稿IM-->

<！ELEMENT Sequence(#PCDATA)>

<！--被转化的消息的序列号-->

<！ELEMENT Data(#PCDATA)>

<！--封装的在移动终端设备本地存储的Push消息的数据-->

由格式转换单元转化的中间文件例如：

<？xml version＝″1.0″encoding＝″UTF-8″？>

<！DOCTYPE IM_Message_Bakupxmls＝″http://www.sample.com/DTD/IM-Bakup-Alternative.dtd″>

<Push_Message_Bakup>

<Message_Type>

</Message_Type>

</Push_Message_Bakup>

其中：

“0100001111010101000000111111110100111111111111111110000111111111111111111111”为实施例当中IM消息的SI部分在移动终端设备A当中的二进制的存储形式。

移动终端设备B根据中间文件形成移动终端设备B能够识别和存储的格式，其转化后的结果如下所示：

B->IM->From＝Alicesample.com

B->IM->To＝Bobsample.com

B->IM->Content_Type＝text/plain

B->IM->Subject＝How Are You？

B->IM->Data＝How Are You？

B->IM->Time＝Wed，07Jun 200617:54:49+0800

B->IM->Type＝Received IM

B->IM->UerAgent＝Microsoft MSN V 7.0

B->IM->Squene＝001

B->IM->Status＝Read

实施例六

本实施例主要的目的是在于实现移动终端设备相关数据在移动终端设备之间的无缝的交换。在交换的过程当中，为了使整个系统尽可能的简单，可以构造一个统一的中间文件格式，实现对所有的移动终端设备数据的交换与存储。为了完成统一数据交换，需要将所有用于移动终端设备之间进行交换的数据的形式进行统一的规定。这些数据具有很大的范围，比如说，SMS、Vcard、Vcalendar、Email、MMS、Picture等数据。本实施例主要描述消息(Message)数据格式的规定方式，其它类型的数据和消息类数据的处理完全相似。在将消息类的数据进行统一处理的过程当中，需要保存的信息字段主要包括：

Message-Type字段，原始数据类型标识，用来区分不同的消息类型，比如说，SMS、MMS、Email等。(必选)

Status字段，主要是指Message的状态。(可选)

Squence字段，主要指Message的序列号。

Message字段，主要是用来存储不同的Message类型。

采用XML方式时，Message数据交换的DTD的一种可能采用的形式。

<？xml version＝″1.0″encoding＝″UTF-8″？>

<！ELEMENT Message_Bakup(Message_Type*，Status*，Squence*，(SMS_Bakup |Push_Message_Bakup|MMS_Bakup|Email_Bakup|IM_Message_Bakup))+>

<！ELEMENT SMS_Bakup(SMS_Orignal_Address*，SMS_Destination_Address*，SMS_Date+，SMS_TimeStamp+，SMS_Type+)>

<！--SMS的备份的DTD的形式-->

<！ELEMENT SMS_Orignal_Address(#PCDATA)>

<！--主要是指SMS的发送方地址。-->

<！ELEMENT SMS_Destination_Address(#PCDATA)>

<！--主要是指SMS接收方的地址。-->

<！ELEMENT SMS_Date(#PCDATA)>

<！ELEMENT SMS_TimeStamp(#PCDATA)>

<！--主要是指SMS的时间信息。-->

<！ELEMENT SMS_Type(SMS_MT？|SMS_MO？|SMS_Draft？|SMS_Delivery_Report？)>

<！--主要是指SMS的类型，目前主要包括4类。-->

<！ELEMENT SMS_MT(#PCDATA)>

<！--移动终端设备接收到的SMS类型-->

<！ELEMENT SMS_MO(#PCDATA)>

<！--移动终端设备发出的SMS类型。-->

<！ELEMENT SMS_Draft(#PCDATA)>

<！--移动终端设备本地编写的草稿SMS类型。-->

<！ELEMENT SMS_Delivery_Report(#PCDATA)>

<！--移动终端设备接收到的关于SMS的报告类型。-->

<！ELEMENT MMS_Bakup(MMS_Message_Type+，MMS_Version+，MMS_Message_ID+，MMS_Sender_address*， MMS_Content_type+， MMS_Recipient_address*，MMS_Message_class*，MMS_Date_and_time+，MMS_Priority*，MMS_Subject*，MMS_State*，MMS_Content*)>

<！ELEMENT MMS_Message_Type(#PCDATA)>

<！--将此消息标识为MM1_retrieve.RES。-->

<！ELEMENT MMS_Version (#PCDATA)>

<！--标识MMSRelay/Server所支持接口的版本。-->

<！ELEMENT MMS_Message_ID(#PCDATA)>

<！--MM的消息ID。-->

<！ELEMENT MMS_Sender_address(#PCDATA)>

<！ELEMENT MMS_Content_type(#PCDATA)>

<！--MM内容的内容类型。-->

<！ELEMENT MMS_Recipient_address(#PCDATA)>

<！--MM接收方的地址。可能存在多个地址。-->

<！ELEMENT MMS_Message_class(#PCDATA)>

<！--消息的类别(例如，个人服务、广告服务和信息服务)-->

<！ELEMENT MMS_Date_and_time(#PCDATA)>

<！ELEMENT MMS_Priority(#PCDATA)>

<！ELEMENT MMS_Subject(#PCDATA)>

<！ELEMENT MMS_State(#PCDATA)>

<！--MM状态。入局MM可能缺少该状态，持久存储的

MM存在该状态。-->

<！ELEMENT MMS_Content (MMS_charset， MMS_Content-Transfer-Encoding，MMS_Content-Location，MMS_Data)>

<！--多媒体消息的内容(由MM的始发方移动终端设备指定)。-->

<！ELEMENT MMS_charset(#PCDATA)>

<！ELEMENT MMS_Content-Transfer-Encoding(#PCDATA)>

<！ELEMENT MMS_Content-Location(#PCDATA)>

<！ELEMENT MMS_Data(#PCDATA)>

<！ELEMENT Push_Message_Bakup(Push_si？，Push_sl？)>

<！ELEMENT Push_si(Push_indication，Push_info？)>

<！ELEMENT Push_indication(#PCDATA)>

<！ATTLIST Push_indication

Push_href％URI；#IMPLIED

Push_si-id CDATA#IMPLIED

Push_created％Datetime；#IMPLIED

Push_si-expires％Datetime；#IMPLIED

Push_action(Push_signal-none|Push_signal-low|Push_signal-medium|Push_signal-high|Push_delete)″Push_signal-medium″

>

<！ELEMENT Push_info(Push_item+)>

<！ELEMENT Push_item(#PCDATA)>

<！ATTLIST Push_item

Push_class NMTOKEN#REQUIRED

>

<！ELEMENT Push_sl EMPTY>

<！ATTLIST Push_sl

Push_href％URI；#REQUIRED

Push_action(Push_execute-low|Push_execute-high|Push_cache)″Push_execute-low″

>

<！ENTITY％ Datetime″CDATA″>

<！ENTITY％URI″CDATA″>

<！ELEMENT Email_Bakup(Push_Return-Path？，Push_Delivered-To*，Push_Received*，Push_Date+，Push_CC？，Push_BCC？，Push_Message-ID*，Push_From+，Push_Subject*，Push_To+，Push_Reply-to*，Push_MIME-version+，Push_Content+)>

<！ELEMENT Push_Content(Push_Content-type*，Push_charset*，Push_Data*，Push_Name*，Push_Filename*，Push_Content-Transfer-Encoding*，Push_Content-Description*，Push_Content-Disposition*，Push_Content-ID*，Push_Content-class*)>

<！ELEMENT Push_Return-Path(#PCDATA)>

<！ELEMENT Push_Delivered-To(#PCDATA)>

<！ELEMENT Push_Received(#PCDATA)>

<！ELEMENT Push_Date(#PCDATA)>

<！ELEMENT Push_CC(#PCDATA)>

<！ELEMENT Push_BCC(#PCDATA)>

<！ELEMENT Push_Message-ID(#PCDATA)>

<！ELEMENT Push_From(#PCDATA)>

<！ELEMENT Push_Subject(#PCDATA)>

<！ELEMENT Push_To(#PCDATA)>

<！ELEMENT Push_Reply-to(#PCDATA)>

<！ELEMENT Push_MIME-version(#PCDATA)>

<！ELEMENT Push_Content-Transfer-Encoding(#PCDATA)>

<！ELEMENT Push_Content-Description(#PCDATA)>

<！ELEMENT Push_Content-Disposition(#PCDATA)>

<！ELEMENT Push_Content-ID(#PCDATA)>

<！ELEMENT Push_Content-type(#PCDATA)>

<！ELEMENT Push_Content-class(#PCDATA)>

<！ELEMENT Push_charset(#PCDATA)>

<！ELEMENT Push_Data(#PCDATA)>

<！ELEMENT Push_Name(#PCDATA)>

<！ELEMENT Push_Filename(#PCDATA)>

<！ELEMENT IM_Message_Bakup(IM_Message_Type，IM_Sequence，IM_Data)>

<！--用于对IM消息进行备份的DTD-->

<！ELEMENT IM_Message_Type(IM_Send？，IM_Received？，IM_Draft？)>

<！ELEMENT IM_Send(#PCDATA)>

<！--封装的在移动终端设备本地存储的发送的IM-->

<！ELEMENT IM_Received(#PCDATA)>

<！--封装的在移动终端设备本地存储的接收的IM-->

<！ELEMENT IM_Draft(#PCDATA)>

<！--封装的在移动终端设备本地存储的草稿IM-->

<！ELEMENT IM_Sequence(#PCDATA)>

<！--被转化的消息的序列号-->

<！ELEMENT IM_Data(#PCDATA)>

<！--封装的在移动终端设备本地存储的Push消息的数据-->

Message-Type字段，主要是用来区分不同的消息，比如说，SMS、MMS、Email等。

Status字段，主要是指Message的状态。

Squence字段，主要指Message的序列号。

Message字段，主要是用来存储不同的Message类型。

本例是一个将所有的消息融合在一个XML当中的实施例。其采用的方法和前面实施例当中采用的方法比较相似，数据格式转化的方式参考上述的XML的DTD文档即可完成，具体的实现过程就不再这里累述了。

另外的一个方式就是将不同的Message的二进制或者封包后的文档作为Message_Bakup的一个Data部分。具体的DTD可以参考如下：

<？xml version＝″1.0″encoding＝″UTF-8″？>

<！ELEMENT Message_Bakup(Message_Type*，Status*，Squence*，Data+>

<！ELEMENT Message_Type(#PCDATA)>

<！ELEMENT Status(#PCDATA)>

<！ELEMENT Squence(#PCDATA)>

<！ELEMENT Data(#PCDATA)>

其中Data数据部分可以封装其它消息的数据。

具体的方式可以参考前面所述的实施例的实现方式。

实施例七、传输Vcard和Vcalendar的原始数据

其中：Vcard的指定条目包括：姓名(N)、移动电话号码(TEL；Cell)、办公电话号码(TEL；Work)、住宅电话号码(TEL；Home)、固定电话号码(TEL)、传真号码(TEL；FAX)、电子邮件(EMAIL)地址。除此之外，还可以包括家庭地址、通信地址等条目。

Vcalendar的指定条目至少包括：起始时间(Start Time)信息、结束时间(Stop Time)信息、描述(Description)信息、循环类型(Recur Type)事件、内容(Body)、提醒方式(Notify Type)、振铃方式(Ringer Type)和持续时间(Duration)等。

处于目前实现的情况的考虑，利用XML对Vcard和Vcalendar进行封装的时候，主要将Vcard和Vcalendar的指定条目的所有内容作为XML的一个Data单元进行封装，从而实现用XML封装Vcard和Vcalendar的功能。XML的方式封装Vcard和Vcalendar指定条目的数据字段时，DTD的描述可以如下：

<？xml version＝″1.0″encoding＝″UTF-8″？>

<！ELEMENT Vcard Bakup(Squence*，Data+>

<！ELEMENT Squence(#PCDATA)>

<！ELEMENT Data(#PCDATA)>

Vcalendar的实现方式如下：

<？xml version＝″1.0″encoding＝″UTF-8″？>

<！ELEMENT Vcard_Bakup(Squence*，Data+>

<！ELEMENT Squence(#PCDATA)>

<！ELEMENT Data(#PCDATA)>

在上述的方案当中，每个Vcard和每个Vcalendar都是一个XML的一个元素(Element)，多个的Vcard和多个的Vcalendar都可以封装在一个XML的文档当中，这样有助于大规模的数据交换，避免针对单个Vcard或者Vcalendar进行操作的时候所带来的不便。下面是对Vcard的方式进行一个简单的XML说明：

<？xml version＝″1.0″encoding＝″UTF-8″？>

<！DOCTYPE Vcard_Bakup xmls＝″http://www.sample.com/DTD/Vcard-Bakup.dtd″>

<Vcard_Bakup>

<Data>”BEGIN：VCARD

VERSION：2.1

N：Marks；Bennett

FN：Bennett Marks

ORG：Nokia；Standardization&Industry Relations

TITLE：Senior Architect

TEL；WORK；VOICE：+1(781)993-3932

TEL；HOME；VOICE：+1(978)371-0970

TEL；CELL；VOICE：+1(781)308-6556

TEL；WORK；FAX：+1(781)993-1822

ADR；WORK：；；5Wayside Road；Burlington；MA；01803；United States of

America

LABEL；WORK；ENCODING＝QUOTED-PRINTABLE：5 Wayside

Road＝0D＝0ABurlington，MA 01803＝0D＝0AUnited States of America

ADR；HOME：；；439Bedford Rd.；Carlisle；Mass.；01741；United States of America

LABEL；HOME；ENCODING＝QUOTED-PRINTABL E：439 Bedford

Rd.＝0D＝0ACarlisle，Mass.01741＝0D＝0AUnited States of America

URL；WORK：http://www.nokia.com

EMAIL；PREF；INTERNET：Bennett.Marksnokia.com

REV：20070629T071729Z

END：VCARD”

</Data>

</Vcard_Bakup>

下面是对Vcalendar的方式进行一个简单的XML说明：

<？xml version＝″1.0″encoding＝″UTF-8″？>

<！DOCTYPE Vcalendar_Bakupxmls＝″http://www.sample.com/DTD/Vcalendar-Bakup.dtd″>

<Vcalendar_Bakup>

<Data>”

BEGIN：VCALENDAR

PRODID：-//Microsoft Corporation//Outlook 11.0MIMEDIR//EN

VERSION：1.0

BEGIN：VEVENT

DT START：20070703T000000Z

DTEND：20070703T020000Z

LOCATION；ENCODING＝QUOTED-PRINTABLE：A110Room

UID：040000008200E00074C5B7101A82E0080000000070E833055BBDC7010

000000000000000100

000009E0D91D28D7A8E4B8C9EF47F7D8AEAA5

DESCRIPTION；ENCODING＝QUOTED-PRINTABLE：FYI＝0D＝0A

SUMMARY；ENCODING＝QUOTED-PRINTABLE：Meeting

PRIORITY：3

END：VEVENT

END：VCALENDAR”

</Data>

</Vcalenar_Bakup>

可见，本发明实施例提供的技术方案利用格式转换单元将原始数据转换为规定格式的中间文件，规定格式的中间文件中包含原始数据的指定条目和对应的数据字段，根据中间文件的规定格式，格式转换单元还可以从中间文件中读取其中的数据字段，从而生成原始数据对应的目标数据。由于规定格式的中间文件中包含的指定条目是原始数据在各种移动终端设备上存储的共有信息字段，因此中间文件可以在各移动终端设备之间传输，达到数据传输的目的。同时，中间文件还可以作为原始顺据的备份，提高原始数据的可靠性。本发明实施例还提供了在第三方设备上设置转换单元时的实现方式。

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

Claims

1.一种移动终端设备数据的交换方法，其特征在于，包括：

第一移动终端设备从自身的原始数据中获取指定条目对应的数据字段；所述指定条目是参与数据交换的移动终端设备上存储的原始数据的共有信息字段；

所述第一移动终端设备生成用于数据交换的中间文件，所述中间文件中包含至少一个所述指定条目、所述指定条目对应的数据字段以及用于在同一个所述中间文件当中区别不同原始数据类型的标识信息；

所述第一移动终端设备将所述中间文件发送给第二移动终端设备，以使所述第二移动终端设备从所述中间文件中获取所述第二移动终端设备的原始数据类型的规定格式中包含的指定条目对应的数据字段，并按照所述第二移动终端设备支持的格式将所述第二移动终端设备的原始数据类型的规定格式中包含的指定条目对应的数据字段保存为目标数据。

2.如权利要求1所述的方法，其特征在于，所述第一移动终端设备从自身的原始数据中获取指定条目对应的数据字段，包括：

所述第一移动终端设备解析所述第一移动终端的原始数据类型的规定格式，确定所述第一移动终端的原始数据类型的规定格式中包含的指定条目，并从所述第一移动终端的原始数据中获取所述指定条目对应的数据字段。

3.如权利要求1或2所述的方法，其特征在于，所述第二移动终端设备从所述中间文件中获取所述第二移动终端设备的原始数据类型的规定格式中包含的指定条目对应的数据字段，包括：

所述第二移动终端设备解析所述第二移动终端设备的原始数据类型的规定格式，确定所述第二移动终端设备的原始数据类型的规定格式中包含的指定条目，并从所述中间文件中获取所述第二移动终端设备的原始数据类型的规定格式中包含的指定条目对应的数据字段。

4.如权利要求1所述的方法，其特征在于，所述原始数据类型至少包括如下之一：消息类数据、电话本类数据、日程表类数据或邮件类数据。

5.如权利要求4所述的方法，其特征在于：

所述电话本类数据的规定格式中的指定条目至少包括：姓名、移动电话号码、办公电话号码、住宅电话号码、固定电话号码、传真号码和电子邮件地址；

所述日程表类数据的规定格式中的指定条目至少包括：起始时间信息、结束时间信息、描述信息、循环类型事件、内容、提醒方式、振铃方式和持续时间；和/或

所述邮件类数据的规定格式中的指定条目至少包括：日期、发送者、主题、接收者、回复地址、多用途互联网邮件扩展MIME版本、回复路径、传递信息、接收信息、抄送地址、密送地址、消息标识、内容传输编码方式信息、内容描述、内容属性、内容标识、内容类型、内容等级、字符集、内容数据、附件名、附件文件名。

6.如权利要求4所述的方法，其特征在于，所述消息类数据包括如下之一：短消息类数据、推送消息类数据、即时消息类数据和多媒体消息类数据。

7.如权利要求6所述的方法，其特征在于：

所述短消息类数据的规定格式中的指定条目至少包括：源地址、目的地址、数据、时间信息和类型；

所述推送消息类数据的规定格式中的指定条目至少包括：业务指示消息的各项指示信息，业务下载消息的各项内容信息；

所述即时消息类数据的规定格式中的指定条目至少包括：发件人通用资源标识URI、收件人URI、数据、发送时间、内容类型、媒体类型；和/或

所述多媒体消息类数据的规定格式中的指定条目至少包括：消息类型、多媒体消息版本信息、消息标识、发送者地址、内容类型、接收者地址、消息等级、时间日期、优先级、主题、消息状态、内容。

8.如权利要求1所述的方法，其特征在于，所述中间文件类型包括txt文件或XML文件。

9.一种移动终端设备数据的交换方法，其特征在于，包括：

第二移动终端设备接收第一移动终端设备发送的用于数据交换的中间文件，所述中间文件由所述第一移动终端设备从所述第一移动终端设备的原始数据中获取指定条目对应的数据字段并按照所述中间文件的规定格式生成；其中，所述指定条目是参与数据交换的移动终端设备上存储的原始数据的共有信息字段，所述中间文件中包含至少一个所述指定条目、所述指定条目对应的数据字段以及用于在同一个所述中间文件当中区别不同原始数据类型的标识信息；

所述第二移动终端设备从所述中间文件中获取所述第二移动终端设备的原始数据类型的规定格式中包含的指定条目对应的数据字段，并按照所述第二移动终端设备支持的格式将所述第二移动终端设备的原始数据类型的规定格式中包含的指定条目对应的数据字段保存为目标数据。

10.如权利要求9所述的方法，其特征在于，所述第一移动终端设备从自身的原始数据中获取指定条目对应的数据字段，包括：

11.如权利要求9或10所述的方法，其特征在于，所述第二移动终端设备从所述中间文件中获取所述第二移动终端设备的原始数据类型的规定格式中包含的指定条目对应的数据字段，包括：

12.如权利要求9所述的方法，其特征在于，所述原始数据类型至少包括如下之一：消息类数据、电话本类数据、日程表类数据或邮件类数据。

13.如权利要求12所述的方法，其特征在于：

14.如权利要求12所述的方法，其特征在于，所述消息类数据包括如下之一：短消息类数据、推送消息类数据、即时消息类数据或多媒体消息类数据。

15.如权利要求14所述的方法，其特征在于：

16.如权利要求9所述的方法，其特征在于，所述中间文件类型包括txt文件或XML文件。

17.一种移动终端设备，其特征在于，包括：

传输指令接收单元，用于接收数据传输指令；

原始数据存储单元、第一数据存储控制单元和第一格式转换单元，所述第一格式转换单元用于根据所述传输指令接收单元接收的所述数据传输指令，解析原始数据类型的规定格式，确定所述原始数据类型的规定格式中包含的指定条目，通过所述第一数据存储控制单元从所述原始数据存储单元中获取所述指定条目对应的数据字段，并生成用于数据交换的中间文件，所述中间文件中包含至少一个所述指定条目、所述指定条目对应的数据字段以及用于在同一个所述中间文件当中区别不同原始数据类型的标识信息，其中，所述指定条目是参与数据交换的移动终端设备上存储的原始数据的共有信息字段；

18.如权利要求17所述的移动终端设备，其特征在于，还包括：

中间文件存储单元，用于存储所述第一格式转换单元生成的中间文件。

19.如权利要求18所述的移动终端设备，其特征在于，还包括：

中间文件接收单元，用于接收所述其它移动终端设备发送的中间文件；

第二格式转换单元和目标数据存储单元，所述第二格式转换单元解析所述原始数据类型的规定格式，确定所述原始数据类型的规定格式中包含的所述指定条目，从所述中间文件接收单元接收的中间文件、和/或所述中间文件存储单元中保存的中间文件中获取所述原始数据类型的规定格式中包含的所述指定条目对应的数据字段，并通过第二数据存储控制单元按照所述移动终端设备支持的格式，在所述目标数据存储单元中将所述原始数据类型的规定格式中包含的所述指定条目对应的数据字段保存为目标数据。

20.如权利要求19所述的移动终端设备，其特征在于：

所述第一格式转换单元和所述第二格式转换单元合并设置；和/或

所述中间文件发送单元和所述中间文件接收单元合并设置。

21.一种移动终端设备，其特征在于，包括：

中间文件接收单元，用于接收其它移动终端设备发送的中间文件，所述中间文件中包含至少一个指定条目、所述指定条目对应的数据字段以及用于在同一个所述中间文件当中区别不同原始数据类型的标识信息，其中，所述指定条目是参与数据交换的移动终端设备上存储的原始数据的共有信息字段，所述指定条目对应的数据字段是从所述其它移动终端设备的原始数据中获取的；

第二格式转换单元、第二数据存储控制单元和目标数据存储单元，所述第二格式转换单元解析原始数据类型的规定格式，确定所述原始数据类型的规定格式中包含的所述指定条目，从所述中间文件接收单元接收的所述中间文件中获取所述原始数据类型的规定格式中包含的所述指定条目对应的数据字段，并通过所述第二数据存储控制单元按照所述移动终端设备支持的格式，在所述目标数据存储单元中将所述原始数据类型的规定格式中包含的所述指定条目对应的数据字段保存为目标数据。