CN1288342A - 移动增值业务的动态实现方法及装置 - Google Patents

Abstract

本发明公开了一种基于STK技术的移动增值业务的动态实现方法及装置。其采用与具体业务无关的通用标识语言定义出移动终端和服务端交互的界面数据和业务数据;同时在移动终端利用STK开发工具建立一通用标识语言解析器,实现对服务端所发送的采用通用标识语言所定义的数据单元的解析,并将移动终端用户输入的业务数据采用通用标识语言定义的数据格式组合成服务请求发送到服务提供端。使基于STK技术的移动用户在不需要对SIM卡和移动终端进行任何改动的情况下,支持现有的和将来新出现的业务。

Description

移动增值业务的动态实现方法及装置

本发明涉及移动通信技术领域，特别是一种基于STK(SIM Tool Kit)技术的移动增值业务的动态实现方法及其装置。

现代通信技术的飞速发展，特别是移动通信的高速发展，带动了移动电话用户数以惊人的速度增长，且在一定的时期内持续保持着这种增长速度。移动通信所提供的业务也从开始的单纯提供话音功能发展到可以提供数据、语音信箱、短消息等多种业务。各家电信运营商为了争夺市场和客户，纷纷在增值业务上大下功夫。SIM(Subscriber Identity Module)卡作为GSM网络与GSM移动电话用户间的界面，其上的微处理器可充分地用来帮助开发新的增值业务。SIM应用开发工具SIM Tool Kit(Subscriber Identity Module Application ToolKit，简称STK)就是用来协助电信公司发展更多样化增值服务的一种工具，让GSM电信网络可以提供更丰富的增值服务给消费者，给电信运营商提供了前所未有的灵活性。

在基于STK技术的手机增值业务应用中，目前较多的做法是根据业务的需要，在SIM卡内定义一套适合业务需求的固定业务菜单以及各种业务功能所需要输入数据的输入界面。用户通过浏览菜单选择业务功能，并且在相应的业务数据输入界面中输入业务数据。然后，STK卡中的应用程序将用户输入的数据组合成业务功能所需要的数据，并通过GSM网络将信息发送到电信的移动增值服务平台。所需要实现的业务及其功能所对应的菜单、数据输入界面以及用户数据的发送格式都是在制作SIM卡时一次性写入的。用户如果需要享受这些服务，只需要拥有这些SIM卡，便可以方便的进行业务操作。

但是，业务的发展以及新业务的出现需要更改菜单、输入界面以及数据发送格式，但是，SIM卡中的业务相关数据是在SIM卡制作时写入的，所以需要对手机中的SIM卡重写以满足业务的新需求和增加新业务。如此，极大地限制了业务迅速发展，进而影响了移动增值服务的发展。而且，由于STK技术往往由SIM卡制作商掌握，而SIM卡的发行是由移动电话公司所控制的，因此，为了实现基于STK技术的增值业务的更换目的，需要涉及到多家服务提供商的合作，也就进一步限制了STK技术的增值业务的推广。

为了能够根据业务发展的需要随时地修改业务菜单、业务数据输入界面和业务数据发送格式等业务相关设置，SIM卡制造商和移动服务提供商都在研究新的STK增值业务实现方法。目前有以下几种实现方法：

第一，采用OTA(On The Air)技术，在需要更新业务时，将SIM卡内的业务菜单、业务数据输入界面和业务数据发送格式等从移动增值业务服务平台下载到SIM卡内。这种技术也称为“空中下载”技术。

第二，采用WAP(Wireless Application Protocol)技术，利用支持WAP协议的手机，通过类似于浏览器和WEB服务器之间的交互方式来实现不同业务的实现。

第三，采用特殊格式的短消息方式。这种方法不使用菜单和输入界面等技术，而是直接让用户输入根据业务所约定的特殊格式的短消息，然后将短消息发送到短消息增值服务系统进行业务处理。

上述的三种方法，在电信领域都有一定程度的应用，但是，由于各种方法都存在一些缺点，影响其进一步的推广应用。

第一种方式，由于需要对SIM卡中的菜单、输入界面、格式等更新，往往需要大量的数据，而一个短消息所能承载的数据量非常有限。对于ASCII码，一个短消息可以传输144个字节；对于中文等双字节字符，只能传输70个双字节字符。显然，通过OTA技术要下载某个业务所需要的数据，需要下载很多个短消息才能组合而成。在实际应用中，往往由于数据量大，多个短消息组合失败而导致菜单等下载失败。

第二种方式，由于WAP是一个参照OSI的网络七层模型而建立起来的无线应用协议，开销很大。所以，WAP协议都是通过手机中的CPU来运行的。从目前的应用来看，如果需要更新WAP协议，则需要更新整个手机。而且，目前WAP手机还不能完全解决安全加密的问题。

第三种方式，用户通过发送一些助记码来取得不同的菜单和数据输入模板，然后再编辑成服务端所需要的不同的业务格式的短消息。尽管对于最一般的手机，只要支持手机短消息，就可以采用这种方法。但是，该方法存在以下缺点：①用户需要记忆一些简码来获得菜单；②用户需要编辑短消息来完成业务数据的输入；③用户交互界面不够友好，操作复杂；④用户对新业务的使用需要一段时间的熟悉；⑤不能实现安全加密问题。

综上所述，本发明的目的就在于：在基于STK技术的基础上，提出一种与具体业务无关的移动增值业务的动态实现方法，使移动终端(如手机)的用户界面和业务数据与具体的业务无关，在不需要对SIM卡和移动终端进行任何改动的情况下，支持现有的和将来新出现的任何移动增值业务。

本发明的一种基于STK技术的移动增值业务的动态实现方法，至少包含以下步骤：

将移动终端与服务提供端间交互的界面数据和业务数据抽象为与具体业务无关的基本数据单元；

采用通用标识语言定义所述的基本数据单元；

在移动终端建立一通用标识语言解析器，该通用标识语言解析器实现对服务提供端所发送的采用通用标识语言所定义的基本数据单元的解析，控制移动终端按照基本数据单元对应的界面数据进行界面显示，并将用户通过界面输入的业务数据采用通用标识语言定义的数据格式组合成服务请求发送到服务提供端。

根据上述技术方案，对采用通用标识语言所标识的业务界面数据和业务数据，为了满足小速率通信线路以及小通信量通信的需要，进一步采用标识符编码以减少交互数据的长度。

移动终端与服务提供端之间交互的数据由基本的数据元组成，该基本的数据元格式由数据值类型(Tag)、数据值长度(Length)和数据值组成。

本发明采用与具体业务无关的通用标识语言定义出移动终端和服务提供端交互的界面数据和业务数据，如此信息格式统一的目的是使得各种与业务相关的界面数据和业务数据可以通过一种与业务无关的信息格式来进行定义，这样便可以达到增值业务的动态实现。

上述的通用标识语言采用扩展标记语言(XML)。

一种实现上述移动增值业务动态实现方法的移动终端，具有一利用SIM应用开发工具(STK)建立的通用标识语言解析器，是一个可以在SIM卡内可执行的小程序，按照移动通信的规范，很容易采用SIM卡内操作系统的编程语言进行编写实现。通用标识语言解析器负责控制移动终端的人机界面以及与移动通信服务端的数据通信。该解析器实现对服务提供端所发送的采用通用标识语言所定义的界面文件和数据格式等的解析，并控制移动终端按照通用标识语言所定义的界面进行显示，让用户按照界面输入业务数据，并将用户所输入的数据根据通用标识语言所定义的数据格式组合成服务请求发送到服务端。服务请求中的数据项根据业务的要求，可以是加密的、也可以是解密的。数据是否加密由服务端所发送的界面文件中的加密相关字段来进行定义。

移动终端可以是手机或车载电话等。

上述的通用标识语言解析器可以是在移动终端中，利用SIM应用开发工具(STK)建立的一浏览器，该浏览器实现对服务提供端所发送的采用通用标识语言所定义的界面数据和业务数据的解析，控制移动终端按照界面数据进行界面的显示，并将用户通过浏览器界面输入的业务数据采用通用标识语言定义的数据格式组合成服务请求发送到服务提供端。

一种实现上述移动增值业务动态实现方法的移动通信服务提供系统，包括业务处理部分、负责与移动终端数据通信的通信部分、负责控制不同移动终端界面显示的界面控制部分、负责根据业务的需要控制用户操作流程的业务流程控制部分、负责发送请求到业务处理部分及获得业务处理结果，并发送到业务流程控制部分进行控制的业务接口部分；

该服务提供系统根据业务的需要定义一套采用通用标识语言描述的业务流程控制界面及每种业务所需要的数据结构，在移动终端访问时，由其来控制移动终端的输入界面，同时，还规定了用户在发送服务请求时的数据格式；

该服务提供系统接受移动终端发送来的服务请求，并根据服务请求来选择移动终端的输入界面或处理移动终端所发送来的业务请求。

所述的通信部分可为负责与移动终端的短消息通信的SMS通信部分。

本发明综合分析了目前移动增值服务中的用户界面和业务数据，将其抽象为菜单、数据输入表单、文本、安全加密等基本的数据单元，并采用通用的标识语言来进行定义，如采用通用的XML标识语言来定义以上基本的数据单元。使用者可以充分利用手机SIM中的STK技术，在移动终端手机上实现一个基于STK技术的通用标识语言解析器，例如基于STK技术的浏览器，该通用标识语言解析器实现对服务提供商所发送的采用上述通用标识语言所定义的数据单元的解析，并使移动用户通过友好的用户界面输入业务数据，然后根据用户输入的数据采用通用标识语言定义的数据格式组合成服务请求发送到服务提供端。

依据本发明技术方案，采用通用标识语言所定义的基本数据单元可以根据实际业务的需要动态生成：首先，将移动终端和服务端交互的界面数据和业务数据抽象为采用与具体业务无关的菜单、数据输入表单、文本、安全加密等基本数据单元所标识的数据包，所有的应用都采用这些基本的数据单元来进行定义；其次，采用通用标识语言来定义以上的基本数据单元，例如采用XML语言来进行定义；最后，根据业务的需要设计界面数据和业务数据。

由于本发明实现了移动终端和服务端间交互的用户界面和业务数据与具体业务的无关性，即终端与业务无关，所有与具体业务相关的数据设计均在服务端进行，因此可以使基于STK技术的移动用户在不需要对SIM卡和移动终端进行任何改动的情况下，方便地使得移动终端的用户界面和业务数据格式可以根据业务的需要而动态地改变，支持现有的和将来新出现的业务，扩充性和安全性很强。

以下结合附图及具体实施例对本发明再作进一步详细的说明。

图1为基于STK技术的本发明应用框架示意图；

图2为采用SMS进行数据通信的基本数据元格式示意图。

在此，仅以移动终端与服务端的数据通信通过短消息(SMS)完成为实施例，对本发明技术方案予以详述。当然，该数据通信还可采用其他的方式，如非结构化承载业务数据USSD(Unstructured Supplementary Service Data)或通用无线分组交换业务GPRS(General Packet Radio Service)等，其只需将基本数据元格式予以相应的变化等。在这些方式下，对本发明技术方案的任何实施皆应认为不脱离本发明思想，视为在本发明保护范围之内。

首先，请参见图1所示，本发明实施例的整个应用框架由手机1、短消息业务中心(SMSC)2和移动通信服务提供端3三大部分完成。其中，手机1负责执行服务提供端发送的指令，根据指令进行移动终端(手机)的人机交互以及相关的安全处理等。SMSC是短消息的通信平台，仅负责短消息的发送，与具体业务无关。对于手机和服务提供端来说是透明的。服务提供端3负责与SMSC的通信、手机的人机界面的最终控制、业务流程的控制、同时它还提供了与业务处理系统的业务接口。

手机与SMSC采用STK技术。服务提供端采用TCP/IP或其他协议通过SMPP与SMSC相连。

在手机1中，利用STK开发工具建立一通用标识语言解析器--浏览器，该浏览器实现对服务提供端3所发送的采用通用标识语言所定义的数据单元的解析，并将用户通过浏览器界面输入的业务数据采用通用标识语言定义的数据格式组合成服务请求发送到服务提供端3。

服务端获得移动终端发送来的用户数据后，根据业务流程控制用户界面或进行相应的业务处理。用户界面包括业务菜单、输入表单和文本信息。输入表单中定义了用户发送请求的格式，输入数据项目等。如果用户接受到的是用户的菜单请求，服务端发送相应的菜单文件到服务端；如果用户发送来的是输入表单所对应的业务请求，服务端将用户请求数据转换为业务接口数据发送到业务处理系统中。

在业务流程更改或增加新的业务功能时，采用通用标识语言修改或编制新的界面数据和业务数据。移动终端不需要进行任何新的修改，只需要通过通用标识语言解析器对新的界面数据和业务数据进行处理即可。

手机1与服务提供端3通信的数据均由基本的数据元组成。数据元格式参见图2所示，其中，数据值类型Tag为一个字节，各位定义如下：

bit8：表示数据值Value中是否嵌套Tag

bit7～bit1：表示Tag的值，全为0和全为1不使用，即从1～126

Tag的嵌套方式如下：Tag，Length，[Tag，Length，Value[，…，Tag，Length，Value]]

采用XML方式进行数据表述。采用的标识符包括：

名称	说明
		id	标识码
title	显示标题
		Type	输入项类型
EncryptInfoID	加密方法索引号
		Value	输入项值
Header	信息头
		Version	版本
Attribute	属性
		Page	页码信息
EncryptInfo	加密信息
		EncryptMethod	加密方法

KeySeed	密钥生成种子
		KeyValue	密钥值
Menu	菜单
		MenuItem	菜单项
Input	表单
		InputItem	表单输入项
Option	输入选择项
		Text	静态文本

其中，id表示该信息单元的编号，可用于不同的Tag直接的索引。比如，某个Menu的Value为“stock”，那么，当选择该Menu时，手机发出值为“stock”的菜单请求或显示已经保存的id为“stock”的菜单。title表示该信息单元的显示信息，如果没有该tag，那么该信息单元不进行显示。Value表示信息单元的值。Type表示信息单元值的类型。EncryptInfoID表示信息单元所使用的加密方法。这些属性全部采用字符串表示。在以下的编码举例中，以16进制表示，分别定义id的码值为0x01、title的码值为0x02、Type的码值为0x03、EncryptInfoID的码值为0x04、Value的码值为0x05。

服务端向手机所发送的信息主要包括以下内容：

1、信息头Header

2、加密信息EncryptInfo

3、菜单和表单信息

手机向服务端发送的信息主要包括以下内容：

1、信息头

2、加密信息

3、菜单、表单请求或业务请求信息

综合分析目前移动增值服务中的用户界面和业务数据，将其抽象为菜单、数据输入表单、文本、安全加密等基本的数据单元，并采用通用的XML标识语言来定义以上基本的数据单元。数据类型定义文件(DTD)为：

    ＜！ELEMENT header(Version，Attribute，Page)＞

    ＜！ELEMENT menu(menuitem*|menu* )＞

　　＜！ATTLIST menu id CDATA #IMPLIED

　　                title CDATA #IMPLIED＞

　　＜！ELEMENT menuitem(#PCDATA)＞

　　＜！ATTLIST menuitem id CDATA  #IMPLIED＞

　　＜！ELEMENT input(inputitem+)＞

　　＜！ATTLIST input id CDATA #IMPLIED

　　                 title CDATA #IMPLIED＞

　　＜！ELEMENT inputitem(option*)＞

　　＜！ATTLIST inputitem tyPe CDATA #IMPLIED

　　                      title CDATA #IMPLIED

　　                      value CDATA #IMPLIED

　　                      encryptinfoid CDATA #IMPLIED＞

　　＜！ELEMENT option(#PCDATA)＞

　　＜！ATTLIST option id CDATA #IMPLIED

　　                  title CDATA #IMPLIED＞

　　＜！ELEMENT text(#PCDATA)＞

　　＜！ATTLIST text title CDATA #IMPLIED

　　                 id CDATA #IMPLIED＞

　　＜！ELEMENT encrypt(encryptinfo+)＞

　　＜！ELEMENT content(#PCDATA)＞
　　＜！ELEMENT encryptinfo(encryptmethod，keyseed？，keyvalue)＞

　　＜！ATTLIST encryptinfo id CDATA #IMPLIED＞

　　＜！ELEMENT encryptmethod(#PCDATA)＞

　　＜！ELEMENT keyvalue(#PCDATA)＞

　　＜！ATTLIST keyvalue base64 CDATA #IMPLIED＞

　　＜！ELEMENT Version(#PCDATA)＞

　　＜！ELEMENT Attribute(#PCDATA)＞
				
				<dp n="d9"/>
　　     ＜！ELEMENT Page EMPTY＞

　　     ＜！ELEMENT keyseed(#PCDATA)＞
　　     ＜！ELEMENT option(#PCDATA)＞   

　　     ＜！ATTLIST option id CDATA #IMPLIED

　　                        title CDATA #IMPLIED＞

信息头(Header)包括版本号(Version)、信息属性(Attribute)、页码(Page)。Version的值有两个字节表示，前字节表示主版本，后字节表示子版本。Attribute的定义如下：

bit1和bit2表示编码方式：

    00表示全部使用ASCII编码

    01表示采用值采用UCS-2编码而其他采用ASCII码的混合方式

    11表示全部采用UCS-2编码

bit3表示TAG的长度是否采用两个字节表示。

Page采用叁个字节表示，第一个字节表示信息页的id号，第二字节表示目前信息的页码，第三字节表示信息总页数。

如，Version的Tag值为0x11、Attribute的Tag值为0x12、Page的Tag值为0x13，Header举例如下：

0x90 0x0b 0x11 0x02 0x01 0x00 0x12 0x01 0x03 0x13 0x03 0x20 0x03 0x05

表示版本为1.0，采用UCS-2和ASCII混合编码，Value的长度采用一个字节表示，目前所传输的为5页中的第3页。

下面以菜单为例说明如何根据DTD来定义不同的数据单元。

菜单分为菜单请求和菜单定义。从用户发送到服务端的为菜单请求。服务端根据菜单请求中的菜单id以及某个菜单项的值来判断手机所请求的菜单定义。菜单有两个属性项为id和title，菜单由菜单项或子菜单组成，菜单项和子菜单都是可以重复的。菜单项有一个id属性，通过菜单项的值使用title属性来表示。

根据上面的定义，某个菜单文件举例说明如下：

<Menu id＝“0”title＝“iSwitch”>

    <Menu id＝“01”title＝“stock”>

      <Menuitem id＝“011”>Buy</>

      <Menuitem id＝“012”>Sell</>

      <Menuitem id＝“013”>Cancel</>

   </Menu>

   <Menuitem id＝“02”>Information</>

   <Menuitem id＝“03”>Bank</>

</Menu>

菜单Menu的Tag值为0x30，菜单项为0x31。根据定义可以编码如下：

0xb0 0x57 0x01 0x01“0”0x02 0x07“iSwitch”

   0xb0 0x33 0x01 0x02“01”0x02 0x05“stock”

      0xb1 0x0a 0x01 0x03“011”0x02 0x03“Buy”

      0xb1 0x0b 0x01 0x03“012”0x02 0x04“Sell”

      0xb1 0x0d 0x01 0x03“013”0x02 0x06“Cancel”

   0xb0 0x11 0x01 0x02“02”0x02 0x0b“Information”

   0xb0 0x0a 0x01 0x02“03”0x02 0x04“Bank”

手机接收到服务端发送来的菜单定义之后，其浏览器进行数据解析，在手机屏幕上进行显示，用户利用手机的按键选择菜单之后，将所选择的菜单id返回给服务端。手机返回的信息为

<Header Version＝“1.0”/>

<Menu id＝“01”>

  <menuitem id＝“012”>

</>

服务端根据Menu的id和Menuitem的id判断用户所请求的为证券买入的菜单请求。然后将证券买入的表单发送到用户端。

表单用于为用户提供业务请求的数据。表单由若干输入项组成，输入项分不同的类型，包括字符串、数字、浮点数以及是否为密码类型等。另外，还有一个是否加密的属性来定义输入项发送到服务端时是否加密。每个表单有id号和title，title用于显示本表单的标题。表单输入项(Inputitem)的type属性采用一个字节表示，最高位标识是否密文显示，低7为ACSII码标识不同的类型。表单项的输入方式有两种，一种的用户用手机按键输入字符方式(E)，另一种是用户在列表中进行选择方式(S1～S3)。列表选择方式分为单项选择、多项选择等方式。EncryptInfoID属性为一个可选属性。EncryptInfoID表示输入项是否采用加密的方式进行传输。如果该项值为“0”或没有这个属性的话，则表示该输入项向服务端传输时采用明文传输。如果该项值为“1”以上，则该字符所表示的数字为EncryptInfo中的id值，采用对应的加密方式进行加密。Value为可选属性，如果该属性为空，则表示输入项没有的缺省值。否则，Value值便是缺省值。

普通文本用于在手机屏幕上输出静态文本。采用Text作为Tag。Text有三个属性，即id，title和value。title表示在文本单独一屏显示时所显示的标题；value表示显示的内容。

移动终端和服务端所传输的数据如果是需要保密的数据，则需要对这些数据进行加密。为了便于数据格式的统一和与业务系统的数据接口以及与第三方系统的数据互联，所有传输的数据采用XML方式来进行定义。通过XML所定义的文件是由一些基本的数据单元组成的，为了保留数据单元的可理解性，需要采用基于字段的加密方法。

信息传输中的加密方法是在信息中的EncryptInfo数据单元中进行定义的。EncryptInfo数据单元中定义了各种不同的相关的加密方法。各种不同的加密方法均使用一个id来进行标识。如果某个数据段需要加密，仅仅需要引用该加密方法的id便可以了。EncryptInfo由三个不同的数据单元组成，即EncryptMethod，Keyseed和Keyvalue。EncryptMethod用于标识界面所实用的方法，比如DES，3DES等。Keyseed标识用于加密是产生密钥的种子，Keyvalue为加密后的会话密钥。不论是由移动终端向服务端发送加密信息还是由服务端发送加密信息到移动终端，均采用EncryptInfo来标识加密方法。在对数据单元加密后，标识数据单元所采用的加密方法的ID号。接收方收到加密的数据单元采用对应的解密方法进行解密。

输入表单、文本的数据单元的定义和处理可以参照菜单的实现方式来进行。

下面简单描述一下增值业务的通信流程和业务处理流程：

(1)用户使用移动终端发送服务初始请求(对于每个服务端是不变的，可以通过其他途径通知用户)到服务端；

(2)服务端接受到用户的请求后，根据用户身份(移动终端标识号来区分)来选择业务菜单(使用前面所描述的通用标识语言来编写的文件)，并通过移动通信模块发送到用户终端；

(3)用户终端接受到服务端所发送来的业务菜单后，通用标识语言解析器将业务菜单进行解析，并显示到移动终端的界面上，让用户进行选择；

(4)用户选择所需要的业务功能，并发送业务功能请求到服务端；

(5)服务端接受到业务功能请求后，判断用户是菜单请求还是表单请求，如果是菜单请求，则到(2)；否则，发送到业务请求的输入表单给用户移动终端；

(6)用户移动终端通过解析器解析输入表单标识文件，并在移动终端上显示输入表单，提示用户输入业务所需要的各项数据，并根据输入表单中的加密要求对需要加密的数据单元进行加密，最后组合成业务请求发送到服务端；

(7)服务端处理用户的业务请求数据，并转换成业务系统的请求格式发送到业务系统中；

(8)业务系统对数据进行处理，并将结果返回给服务端；

(9)服务端将结果发送到移动终端；

(10)移动终端的解析器解析服务端发送来的请求结果，并显示给最终用户。

(11)重复(2)开始的操作。

综上所述，本发明相比现有技术具有如下优点：

(1)用户界面友好，用户不需要记忆任何东西，只需要在手机界面的提示来通过简单的按键进行操作；

(2)用户不需要编辑短消息，只需要在屏幕的提示下输入一个一个的输入项；

(3)对于新的业务，用户不需要知道任何知识，仅通过服务端提示用户输入不同的数据；

(4)通过修改服务端的业务定义，便可以实现不同的业务，与移动终端无关；

(5)采用标准规范的标识语言，便于与其他系统进行信息交互；

(6)通过采用通用标识语言定义不同的业务界面和数据结构，可以同时提供多种增值业务系统。

(7)通过基于字段的加密技术，实现了数据的安全性，可以满足不同安全业务的需要；

(8)采用编码技术减少了数据长度；

(9)在增值业务扩展时，不需要更换移动终端的任何东西，不需要更换SIM卡；

(10)通过更换手机的SIM卡，便可以简单地升级移动终端的处理功能。不需要更换整个手机，经济实用。

Claims (17)

1、一种移动增值业务的动态实现方法，其特征在于该方法至少包含以下步骤：

将移动终端与服务提供端间交互的界面数据和业务数据抽象为与具体业务无关的基本数据单元；

采用通用标识语言定义所述的基本数据单元；

在移动终端建立一通用标识语言解析器，该通用标识语言解析器实现对服务提供端所发送的采用通用标识语言所定义的基本数据单元的解析，控制移动终端按照基本数据单元对应的界面数据进行界面显示，并将用户通过界面输入的业务数据采用通用标识语言定义的数据格式组合成服务请求发送到服务提供端。

2、根据权利要求1所述的方法，其特征在于：进一步的包括采用标识符编码以减少交互数据的长度。

3、根据权利要求1或2所述的方法，其特征在于：进一步的移动终端与服务提供端之间交互的数据由基本的数据元组成，该基本的数据元格式由数据值类型(Tag)、数据值长度(Length)和数据值组成。

4、根据权利要求1所述的方法，其特征在于：所述的基本数据单元至少包括菜单、数据输入表单、文本、安全加密。

5、根据权利要求1所述的方法，其特征在于：所述的通用标识语言采用扩展标记语言(XML)。

6、根据权利要求1或4所述的方法，其特征在于：所述的在移动终端建立的通用标识语言解析器为一浏览器，该浏览器实现对服务提供端所发送的采用通用标识语言所定义的界面数据和业务数据的解析，控制移动终端按照界面数据进行界面的显示，并将用户通过浏览器界面输入的业务数据采用通用标识语言定义的数据格式组合成服务请求发送到服务提供端。

7、根据权利要求1或4所述的方法，其特征在于：所述的服务请求包括菜单请求和业务请求。

8、根据权利要求1或4所述的方法，其特征在于：所述的服务请求中的数据项可以是加密的。

9、根据权利要求8所述的方法，其特征在于：所述的加密为采用基于字段加密的方式实现。

10、一种实现权利要求1所述方法的移动终端，其特征在于：在该移动终端中，具有一利用SIM应用开发工具(STK)建立的通用标识语言解析器，该通用标识语言解析器实现对服务提供端所发送的采用通用标识语言所定义的基本数据单元的解析，控制移动终端按照基本数据单元对应的界面数据进行界面的显示，并将用户通过界面输入的业务数据采用通用标识语言定义的数据格式组合成服务请求发送到服务提供端。

11、根据权利要求10所述的移动终端，其特征在于：所述的通用标识语言解析器为一浏览器，该浏览器实现对服务端所发送的采用通用标识语言所定义的数据单元的解析，并将用户通过浏览器界面输入的业务数据采用通用标识语言定义的数据格式组合成服务请求发送到服务提供端。

12、根据权利要求10或11所述的移动终端，其特征在于：所述的采用通用标识语言所定义的基本数据单元包括将移动终端和服务提供端交互的界面数据和业务数据抽象为与具体业务无关的菜单、数据输入表单、文本、安全加密的数据单元。

13、根据权利要求10或11所述的移动终端，其特征在于：所述的通用标识语言为扩展标记语言(XML)。

14、根据权利要求10或11所述的移动终端，其特征在于：所述的移动终端是手机或车载电话。

15、一种实现权利要求1所述方法的移动通信服务提供系统，包括业务处理部分、负责与移动终端数据通信的通信部分，其特征在于该系统进一步包括：负责控制不同移动终端界面显示的界面控制部分、负责根据业务的需要控制用户操作流程的业务流程控制部分、负责发送请求到业务处理部分及获得业务处理结果，并发送到业务流程控制部分进行控制的业务接口部分；

该服务提供系统根据业务的需要定义一套采用通用标识语言描述的业务流程控制界面及每种业务所需要的数据结构，在移动终端访问时，由其来控制移动终端的输入界面，及规定用户在发送服务请求时的数据格式；

该服务提供系统接受移动终端发送来的服务请求，并根据服务请求来选择移动终端的输入界面或处理移动终端所发送来的业务请求。

16、根据权利要求15所述的移动通信服务提供系统，其特征在于：所述的通信部分为负责与移动终端的短消息通信的SMS通信部分。

17、根据权利要求15所述的移动通信服务提供系统，其特征在于：所述的通用标识语言为扩展标记语言(XML)。

Images