用于压缩以结构化定义语言表达的无线应用程序的系统和方法

摘要

提供用于压缩软件应用程序的系统和方法。所接收的软件应用程序包括通用标签和软件应用程序的等级属性、应用程序的专用元素和可显示数据。对通用标签和属性进行编码，并且还对应用程序的专用元素进行编码，而可显示数据仍然不被编码。从而可以生成包括编码通用标签和属性、编码应用程序专用数据和未编码可显示数据的压缩软件应用程序。编码应用程序的信息源和接收目的地设备可以共享压缩码的知识，所述压缩码用于对预定义的通用和预定义的应用程序专用元素进行编码。

说明书

技术领域

本申请概括地涉及无线网络通信和无线通信设备，更具体地涉及对传送到这种设备或从这种设备接收的无线应用程序进行压缩。

背景技术

随着被配置为可操作的无线通信设备和无线通信网络的持续地演进，设备用户期望来自这些设备的更广泛的功能。这些通信设备可以是诸如(但不限于)无线设备(PDA)等。当今的无线设备通常能够进行诸如Web浏览、信息下载等功能，这些功能典型地得到个人计算机(PC)的大范围和强有力地支持。然而，PC通常具有比无线设备更大和更快的处理器，并且可使用比在无线设备上有效的通信资源和电源具有更少限制的通信资源和电源。

对无线设备上的这些类型的功能和应用程序的支持并不是将软件应用程序和操作系统添加到(porting)无线设备的问题。并不针对无线通信来优化这些功能所基于的根本性协议、传输机制和数据格式。例如，可扩展标记语言(XML)快速地变为其中一种用于在不同的计算机系统间交换数据的最常用的方案，但其特征在于相当大的文件尺寸，因此不适合于基于无线或其它窄带通信系统进行传输。在无线设备中，大量数据的传输会消耗有限的设备资源，包括通信资源和电力资源二者。尽管诸如无线应用协议(WAP)二进制XML(WBXML)这样的、目标在于无线设备的压缩和编码方案是熟知的，但这些编码方案通常只提供有限的好处，并且必须要查阅(pass)包含设备和应用程序源之间的编码方案的字典。WBXML编码方案的其它不足在于：该编码方案还需要在将编码应用程序从应用程序提供商传递到接收方通信设备的过程中，查阅利用编码应用程序定义的二进制字典。

为无线网络通信中的应用程序传送提供应用程序压缩的系统和方法，以消除或减轻至少某些上面提到的不足。

发明内容

可扩展标记语言(XML)快速地变为其中一种用于在不同的计算机系统间交换数据的最常用的方案，但其特征在于相当大的文件尺寸，因此不适合于基于无线或其它窄带通信系统进行传输。在无线设备中，大量数据的传输会消耗有限的设备资源，包括通信资源和电力资源二者。尽管诸如无线应用协议(WAP)二进制XML(WBXML)这样的、目标在于无线设备的压缩和编码方案是熟知的，但这些编码方案通常只提供有限的好处。WBXML编码方案的其它不足在于：该编码方案还需要在将编码应用程序从应用程序提供商传递到接收方通信设备的过程中，查阅利用编码定义的二进制字典。

与现有的编码方案相对比，提供用于压缩软件应用程序的非显示元素的系统和方法。所接收的软件应用程序包括通用标签和软件应用程序的等级属性、应用程序的专用元素和可显示数据。对通用标签和属性进行编码，并且还对应用程序的专用元素进行编码，而可显示数据仍然不被编码。从而可以生成包括编码通用标签和属性、编码应用程序专用数据和未编码可显示数据的压缩软件应用程序。编码应用程序的信息源和接收目的地设备可以共享压缩码的知识，所述压缩码用于对预定义的通用和预定义的应用程序专用元素进行编码。

因此，提供一种用于压缩以结构化定义语言来表达的无线软件应用程序的方法，所述应用程序具有多个根据应用软件模板来预定义的可编码元素，以及多个被配置为在无线设备的用户接口上进行表达的未编码显示参数，所述方法包括步骤：根据包括多个用于表示作为可编码元素的所述应用软件预定义元素的代码的压缩字典来选择压缩格式；使用所选的压缩格式对预定义元素的通用元素进行编码，所述通用元素表示用于软件应用程序等级的通用结构；使用所选的压缩格式对应用程序内容的应用程序专用元素进行编码，所述应用程序专用元素被包括在所述预定义元素中，以未编码的格式来保持所述应用程序内容的显示参数；以及组合未编码的显示参数、已编码的通用元素和已编码的用于生成应用程序被压缩版本的应用程序专用元素；其中借助于被压缩软件程序的接收无线设备、通过使用所述模板内容的知识来配置所述压缩字典。

因此，提供一种对以结构化定义语言来表达的被压缩的无线软件应用程序进行解压缩的方法，所述应用程序具有多个根据应用软件模板来预定义的可编码元素，以及多个被配置为在接收方无线设备的用户接口上进行表达的未编码显示参数，所述模板内容的知识在所述设备和被压缩应用程序的应用程序提供商之间共享，所述方法包括步骤：根据包括多个用于表示作为可编码元素的所述应用软件预定义元素的代码的压缩字典来选择解压缩格式；使用所选的压缩格式对所选的预定义元素进行解码，所述预定义元素包括通用元素，该通用元素表示用于软件应用程序和所述应用程序内容的应用程序专用元素的等级的通用结构；以未编码的格式来保持所述应用程序内容的显示参数；并且在被配置为随后在所述设备的运行时间环境上执行的、未压缩的应用程序版本中包括已解码的预定义元素和显示参数。

还提供一种用于压缩以结构化定义语言来表达的无线软件应用程序的系统，所述应用程序具有多个可编码的预定义元素，以及多个被配置为在无线设备的用户接口上进行表达的未编码显示参数，所述系统包括：应用程序模板，用于定义所述预定义的元素并且包括有关显示参数的信息；压缩字典，用于表示包括多个表示作为可编码元素的所述应用程序预定义元素的代码的压缩格式；编码器，用于使用所选的压缩格式对预定义元素进行编码，所述预定义元素包括通用元素，该通用元素表示用于软件应用程序和所述应用程序内容的应用程序专用元素的等级的通用结构；以未编码的格式来保持所述应用程序内容的显示参数；以及生成器，用于组合未编码的显示参数和用于生成应用程序被压缩版本的已编码预定义元素；其中借助于被压缩软件程序的接收方无线设备、通过使用所述模板内容的共享知识来配置所述压缩字典。

此外，提供一种用于对以结构化定义语言来表达的压缩无线软件应用程序进行解压缩的系统，所述应用程序具有多个可编码的预定义元素，以及多个被配置为在接收方无线设备的用户接口上进行表达的未编码显示参数，所述系统包括：应用程序模板，用于定义所述预定义的元素并且包括有关显示参数的信息，以及在所述设备和被压缩应用程序的应用程序提供商之间共享的所述模板内容的知识；压缩字典，用于表示包括多个表示作为可编码元素的所述应用程序预定义元素的代码的压缩格式；解码器，用于使用所选的压缩格式对预定义元素进行解码，所述预定义元素包括通用元素，该通用元素表示用于软件应用程序和所述应用程序内容的应用程序专用元素的等级的通用结构；以未编码的格式来保持所述应用程序内容的显示参数；以及生成器，包括未编码的显示参数和在应用程序的未压缩版本中的解码预定义元素，所述应用程序被配置为随后在所述设备的运行时间环境上来执行。

还提供一种用于对以结构化定义语言来表达的压缩无线软件应用程序进行解压缩的计算机程序产品，所述应用程序具有多个可编码的预定义元素，以及多个被配置为在接收方无线设备的用户接口上进行表达的未编码显示参数，所述计算机程序产品包括：计算机可读介质；在所述计算机可读介质上存储的应用模板模块，所述应用模板模块用于定义所述预定义的元素并且包括有关显示参数的信息，以及在所述设备和被压缩应用程序的应用程序提供商之间共享的所述模板内容的知识；在所述计算机可读介质上存储的压缩字典模块，所述压缩字典模块用于表示包括多个表示作为可编码元素的所述应用程序预定义元素的代码的压缩格式；在所述计算机可读介质上存储的解码器模块，所述解码器模块用于使用所选的压缩格式对预定义元素进行解码，所述预定义元素包括通用元素，该通用元素表示用于软件应用程序和所述应用程序内容的应用程序专用元素的等级的通用结构；以未编码的格式来保持所述应用程序内容的显示参数；以及与所述解码器模块连接的生成器模块，所述生成器模块包括未编码的显示参数和在应用程序的未压缩版本中的解码预定义元素，所述应用程序被配置为随后在所述设备的运行时间环境上来执行。

附图说明

通过参照下面的附图和这里的详细说明可以获得更好地理解，其中：

图1是提供从通信设备接入到信息源的通信系统的框图；

图2是图1的设备的框图；

图3a是表示压缩图1中系统的软件应用程序的方法的流程图；

图3b是表示解压缩图1中系统的软件应用程序的方法的流程图；

图4是用于处理图1中系统的被压缩软件应用程序的系统的框图；

图5是图1中系统的软件应用程序压缩工具的框图；

图6是作为第一压缩软件应用程序系统拓扑结构的图1的系统的另一个示例；以及

图7是作为第二压缩软件应用程序系统拓扑结构的图1的系统的另一个示例。

具体实施方式

网络系统参照图1，网络系统10包括多个设备12，该多个设备12用于通过请求/响应消息105(即合适的通信信道或信道的组合，诸如调制解调器、串行连接或包括但不限于连接的广域网(WAN)16(诸如但不限于因特网)的计算机网络，)与一个或多个通常的信息服务13进行相互作用，通常的信息服务13具有数据服务器18和相关的信息源20。数据服务器18有效地使得设备12接入到信息服务13的信息源20。信息服务13的功能可以集成到单独的计算机系统中，或者通过适应合适的通信接口的多个计算机系统进行分发。设备12可以诸如是(但不限于)PDA、蜂窝电话等。通常的信息服务13可以是Web服务和/或其它的服务，诸如(但不限于)SQL数据库、基于IDL的CORBA和RMI/IIOP系统，以及COM/DCOM部件。此外，系统10还具有将无线设备12连接到WAN16的无线网络14。

无线设备12是适合于在无线通信网络14中进行操作的无线通信设备，诸如具有至少数据和可能的语音通信能力的双向通信设备。无线网络网关15在无线网络14和WAN16之间提供接口，并且执行诸如无线设备寻址以及将数据存储并转发到该无线设备12或从该无线设备12进行转发的功能。图1中示出的无线网络网关15提供了无线网络14和诸如因特网的WAN16之间的接口。诸如无线设备寻址、将数据存储并转发到该无线设备12或从该无线设备12进行转发的功能以及其它的接口功能可以通过无线网络网关15来执行。根据无线设备12提供的功能，可以操作诸如(但不限于)数据消息处理设备、双向寻呼机、具有数据消息处理能力的移动电话、无线因特网设备、数据通信设备(具有或不具有电话功能)、和/或被配置为与计算机系统或其它电子设备一同操作的无线调制解调器，然而这里仅参照无线设备12。应当承认的是，其它的设备和计算机(未示出)也可以经由WAN16和除了图1中所示的网络之外的相关网络与数据服务器18相连。

为了简单起见，例如可以将Web服务13选择为表示在下面系统10的描述中的信息服务13。然而，应当承认的是，如果需要的话，其它通常的信息服务13可以替代Web服务13。此外，为了简单起见，下文中将网络14、16和任何允许在系统10的这些网络中相互通信的合适的网关服务器总的称为“网络16”。

在无线设备12中的通信子系统的特别设计取决于无线设备12打算在其中运行的通信网络14。例如，针对北美市场的无线设备12可以包括被设计为在MobitexTM移动通信系统或DataTACTM移动通信系统中进行操作的通信子系统，而打算在欧洲使用的无线设备12可以并入通用分组无线电业务(GPRS)通信子系统。其它类型的无线设备和网络也是所期望的。实际上可以与任何无线网络14和无线设备12相结合地来执行这里所描述的系统和方法。

再次参照图1，设备12在与Web服务13的数据服务器18进行通信时，分别发送和接收请求/响应消息105。设备12可以作为Web服务13的Web客户端，通过使用消息头信息形式的请求/响应消息105进行操作，例如请求并接收产品报价和来自在线销售商的可用信息。例如，Web服务13是在设备12上的客户端应用程序320(参见图2)经由网络16与其进行通信以便向设备12的用户提供可用性的一个系统。网络系统10使用用于减少应用程序302的尺寸的压缩方案，正如下面进一步所描述的，其可以用于设备12的覆盖区域(footprint)和/或网络16的带宽考虑。在与Web服务13进行相互作用期间，应当承认消息105用于发送应用程序302和/或设备12上的应用程序302的操作(例如)期间的相关的消息(包括显示数据)。

为了满足Web服务13的适当的请求/响应消息105，数据服务器18可以通过各种用于将相关商业逻辑(方法)暴露给设备12的客户端应用程序302(参见图2)的协议(诸如但不限于HTTP和组件API)与信息源20进行通信。通过数据服务器18，设备12可以访问能够与数据服务器18进行通信的信息源20。数据服务器18还可以包括Web服务13的接口软件，诸如但不限于使用一种或多种结构化定义和/或脚本语言的规范，所述脚本语言诸如是Web服务描述语言(WSDL)和商业处理执行语言(BPEL)。信息源20可以是在数据服务器18处的本地数据存储器，或者是例如与Web服务器(未示出)相关的远端存储器。此外，数据服务器18和信息源20可以包括分发式Web服务13，并且通过网络16(包括因特网)(而不是图1所示的直接连接)进行通信。可以将信息源20认为是数据对于设备12有效的一个源。该数据可以由设备12来请求，或者可由信息源20发送到设备12而不需要首先被请求。应当理解，如果需要，信息源20可以结合数据服务器18或者某些其它的方便Web服务13的数据交换的装置。

设备12的应用程序302(参见图2)可以使用信息源20的商业逻辑，该商业逻辑类似于调用有关对象(或功能)的方法。应当承认，与信息源20相关的客户端应用程序302可以通过经由网络16的消息105直接下载/上载到设备12。进一步得到承认的是，设备12可以经由网络16与一个或多个Web服务13进行通信。同样得到承认的是，如果需要的话，设备12可以直接与信息源20相连，从而绕过数据服务器18。在可替换的配置中，如下面所描述的，可以将数据服务器18的功能结合到网关15或信息源20中。例如，应用程序服务提供商可以组合数据服务器18和信息源20。

尽管在图1中示出了无线设备12、无线网络14和无线网络网关15，但是所公开的系统和方法还可以应用于各种类型的无线网络拓扑结构、无线通信系统和无线设备。例如，处理资源和通信链路带宽往往并不被限制到桌上型计算机系统和有线通信链路，和无线设备以及无线通信网络，而是可以在某些实施方案中压缩数据的尺寸，还可以经由有线连接提供更快的文件的传送。

服务器环境

一般来说，Web服务13是对传统的基于浏览器和客户—服务器TCP/IP连接的基础结构和应用程序的一种替换。最初以一般的机器对机器(M2M)通信协议开始，Web服务13变为用于任何服务对服务(S2S)、或服务对客户(S2C)通信的标准。基于一组标准协议(例如WSDL、简单对象接入协议(SOAP)、统一描述、发现和集成(UDDI))，Web服务13可以提供一个例如基于XML的中性平台通信管道，该平台可以支持同步和/或异步通信消息105。图1的系统10优选地与S2C模型相关，并且涉及根据某种通用终端设备12运行的Web服务13的客户。

参照图1，Web服务13提供由设备12的客户应用程序302(参见图2)使用的信息消息105。作为选择，或者另外，Web服务13可以接收和使用由设备12提供的信息消息105，或执行代表在设备11上运行的客户应用程序302的任务。Web服务13可以认为是数据服务器18的一种软件服务，这种软件服务可以实现为使用在UDDI中登记的WSDL表达的一种接口，并且可以通过消息105与客户设备12进行通信，该客户设备12通过SOAP被暴露在网络104上。SOAP是定义了用于消息105的XML格式(包括在SOAP要素中公开的已知形式的XML片段)的一种规范。作为选择，Web服务13可以使用其它已知的通信协议，消息105的格式，以及可以以其它的Web服务语言来表达接口，这些Web服务语言不同于上面描述的用于与设备12通信中的Web服务语言。

通信设备

再次参照图1和图2，设备12是诸如(但不限于)移动电话、PDA、双向寻呼机或双模通信设备的设备。设备12包括经由连接218连接到设备基础结构204的网络连接接口200，诸如无线收发信机、串行/并行端口或调制解调器。连接接口200在设备12操作期间可连接到网络16，诸如通过RF链路连接到无线网络14，该RF链路可以使设备12彼此进行通信，并且经由网络16与外部系统(诸如Web服务13)进行通信，并且用于协调客户应用程序302和Web服务13之间的请求/响应消息105。网络16支持在设备12和连接到网络16的外部系统之间的请求/响应消息105中的数据传输。网络16也可以支持用于在设备12和在网络16外部的设备之间的电话呼叫的语音通信。将根据其中无线设备12易于操作的无线通信网络14来特别地设计无线设备12内的网络连接接口200。例如，目标在于北美市场的无线设备12可以包括被设计为在Mobitex TM移动通信系统或DataTAC TM移动通信系统中操作的网络连接接口，而旨在欧洲使用的无线设备12可以结合通用分组无线电业务(GPRS)的网络连接接口200。其它类型的无线设备和数据传输协议也是所期望的，诸如但不限于码分多址(CDMA)。

再次参照图2，设备12还具有用户接口202，通过连接222与设备基础结构204连接，以便与用户(未示出)相互作用。用户接口202包括一个或多个用户输入设备，诸如但不限于QWERTY键盘、键盘、导航键、触笔、鼠标、麦克风，还包括用户输出设备，诸如LCD显示屏显示器和/或扬声器。如果显示屏是触摸感应式的，则显示屏也可以用作由设备基础结构204控制的用户输入设备。用户接口202由设备12的用户用于协调系统10(参见图1)上的请求/响应消息信息105，该系统10由客户运行时间环境206的客户应用程序302来使用，下面将进一步说明。

再次参照图2，通过设备基础结构204可以进行设备12的操作。设备基础结构204包括计算机处理器208和相关的存储器模块210；计算机处理器208可以包括一个或多个处理单元，该处理单元可以包括一个或多个通用处理器和/或专用处理器(例如ASCI，FPGA，DSP等)。计算机处理器208通过执行相关的指令来操作设备12的网络接口200、用户接口202和客户运行时间环境206，这些相关指令由位于存储器模块210中的操作系统和客户应用程序302来提供。

此外，应当承认的是，设备基础结构204可以包括与处理器208相连的计算机可读存储介质212，其用于将指令提供给处理器208和/或用于在存储器模块210中加载/更新客户应用程序302。计算机可读存储介质212可以包括硬件和/或软件，诸如(仅借助于实例)磁盘、磁带、诸如CD/DVD ROM的光可读介质以及存储卡。在每一种情况下，计算机可读存储介质212都可以采用小磁盘、软盘、盒式磁带、硬盘驱动器、固体存储器卡或在存储器模块210中提供的RAM的形式。应当注意，上述举例列出的计算机可读介质212可以单独使用或组合使用。同样得到承认的是，可以通过Web服务13(或第三方信源)基于网络16(参见图1)来提供用于处理器208的指令和/或用于在存储器模块210中加载/更新客户应用程序302的指令，以便配置用于与Web服务13相互作用的设备12。

参照图2，设备12通过客户运行时间环境206来执行应用程序302，该客户运行时间环境206可以将应用程序302转换为本机代码，该本机代码由设备基础结构204中的处理器208来执行；多个这样的运行时间环境可潜在地由给定设备12的处理框架206来使用。作为选择，可以以本机代码来执行应用程序302，或者通过设备12上的其它软件模块或操作系统来解释该应用程序302。在任何一种情况下，组件应用程序302都在由设备12提供的终端运行时间环境中运行。

再次参照图1，可以将设备12提供的客户运行时间环境配置为使得设备12作为Web服务13的Web客户端进行操作。设备12的客户运行时间环境优选地能够产生、管理(hosting)和执行在设备12上的客户运行程序302；如果多个运行时间环境有效，则可以选择专用的一个运行时间环境由给定的应用程序302来使用。此外，客户运行时间环境的专用功能可以包括诸如(但不限于)对语言的支持、协调存储器分配、组网、在I/O操作期间的数据管理、在设备12的输出设备上协调图形，以及提供对核心目标定向等级的接入并支持文件/程序库。由设备12执行的运行时间环境例如可以包括诸如(但不限于)微软的通用语言运行时间(CLR)和Sun Microsystems的Java Runtime Environment(JRE)，这些运行时间环境便于产生、传输和接收在Web服务13和设备12之间的网络消息105。

压缩方案

通常，无线应用的空间迅速地增加，而且利用不同的配置平台和设备12，XML(例如)正在变为在软件应用程序定义中选择使用的结构化定义语言。使用UML，可以定义软件应用程序屏幕、数据结构和通过请求/响应消息105在设备12和数据服务器18或应用程序服务提供商13之间进行交换的消息。基于设备来执行的环境206从应用程序302的语言(例如XML)定义中产生本机软件代码组件，或者直接在用于表示应用程序302的结构化定义的语言上进行操作。换句话说，运行时间环境206要么直接执行XML代码，要么在执行之前首先将XML代码转变为相应的本机代码表示。

XML方法允许软件应用程序开发商以具有最小轻便性问题的不同设备12为目标建立软件应用程序302。为了使执行环境206(参见图2)能够与定义XML的应用程序相互作用，相关XML定义的格式优选地与预先定义的应用程序定义模板42(诸如但不限于文件类型的定义(DTD)或XML方案)(参见图4)相一致。这就创建了唯一的一种情形，即设备12和内容或服务提供商13二者共享包括在定义模板42中的定义格式的知识。该共享软件应用程序302的定义格式的知识，为基于通常在熟知的WBXML压缩中使用的更多的压缩XML软件应用程序302提供了机会，例如，得到认可的是：下面描述的针对基于XML应用程序302的压缩方案可以应用于其它具有预定义定义格式的结构化定义语言，诸如但不限于包括XML变型的其它标记语言。

根据在这些实施方式中其它的可能特征，通过对至少某些未显示数据的压缩(例如，二进制混淆)可以得到改进的压缩结果，从而在应用程序302的内容压缩期间，在非显示数据和显示数据之间做出区别(对应用程序302的终端用户来说)。在这种情形下，仅可以对预先定义的应用程序元素进行编码，诸如XML标记和属性，这些标记和属性对于软件应用程序的给定类和没有显示给设备12的终端用户的特定值是公知的。不会通过压缩方案对应用程序302的这些显示给设备12的用户的参数内容进行编码。从而，这些压缩方案可以减少所规定的空中下载(OTA)例如，被定义的XML、软件应用程序302)的尺寸。

因此，如下面进一步描述的压缩方案可以采用一个事实，即在不压缩的情况下，仅将可显示的数据/参数(针对设备12的用户接口202上的应用程序用户(参见图2))经由消息105发送到设备12。诸如软件应用程序302的内部名称和属性这样的通用预定义的元素可以进行二进制编码，并且以压缩格式发送到设备12。在设备12上，可能没有必要将这些已编码预定义名称和属性解码为原始未编码的名称和属性(由各个开发商来定义)，因为这些名称和属性仅在内部存储，并不对设备12(参见图2)的用户接口202上的用户显示。一旦到达设备12，在某些实施方式中，就可以根据执行环境206(参见图2)的性能将压缩应用软件302的已编码应用程序内部名称和属性恢复为已产生的特征序列(即，本机代码或其它可执行的格式)，或保持为被压缩的二进制格式。已经得到承认的是，压缩方案可以将除了二进制以外的变换格式用于表示应用程序302的被压缩的预定义元素。

参照图4，应当注意，模板42可以在设备12和应用程序302的Web服务13(例如内容或服务提供商)之间共享，因此对于在规定时间、在对用于处理的元素进行解码所需的运行时间环境206中解码通用应用程序元素(例如，对多个应用程序302公知的XML元素标记和属性)是有效地。此外，与旨在用户接口202(参见图2)上进行显示的动态变化的元素(可显示的参数)相比较，模板42的内容可以包括应用程序302的预定义应用元素。这些显示元素可以由Web服务13和设备12的用户动态地来产生。因此，没有必要利用已编码的软件应用程序302及相关的编码响应/请求消息105来重复地查阅压缩字典38。应当承认的是，已编码的预定义应用程序专用和通用数据定义通常不包括任何可对设备用户显示的信息，并且可以以编码的形式来保持，以便当在设备12上加载或者相反在设备12上提供上述内容时，进一步减少应用程序302的覆盖区域。例如，如果需要的话，字典38可以使用二进制压缩格式。

再一次参照图4，将设备12的运行时间环境206配置为处理经由消息105接收的(例如)被压缩的软件应用程序302。本领域的普通技术人员将理解在图4中仅包括直接包含在处理压缩软件应用程序302中的元素，设备12典型地包括除了图2中所示的部件之外的其它部件。能够用于被压缩软件应用程序302的设备12包括支持软件应用程序302下载的应用程序规定服务32，而且还可以包括用于解压缩或恢复所接收的被压缩XML应用程序302的应用程序解码器34。

解码器34的压缩字典38包括用于通用预定义元素(例如，XML名称和属性)解码的通用元素字典400，和用于处理预定义特定应用元素(例如属性值)的应用程序专用元素字典402。第一通用元素解码器36(诸如但不限于WBXML解码器)使用字典400来解码通用XML元素和可以定义应用程序302资源的属性。应用程序定义模板42包括有关应用程序302的给定类(class)的通用结构的信息。例如(但不限于)由DTD或XML方案所定义的，而且还可以包括有关可显示参数和其它未编码数据的知识，以便协调所述处理及其显示。第二值解码器/名称生成器40使用应用程序专用字典402进行恢复，并且例如在某些实施方式中，如果需要的话通过运行时间206来使预定义的应用程序专用元素有效。随意地，第二解码器40还对作为结果的解码应用程序302定义进行处理，以产生或恢复基于特征的属性值，其中设备执行环境206不能以压缩格式来存储并执行这些参数。

再次参照图4，当针对设备12规定被压缩的应用程序302的定义时，第一解码器36从压缩字典38中针对无线软件应用程序302的相应等级来检索字典400，并且相应地对通用预定义的XML元素和属性进行解码。在解码通用预定义XML元素和属性之后，部分解码的应用程序302的定义被传送至第二解码器40，该第二解码器40检索应用程序专用字典402，以便解码预定义的应用程序专用属性值。查找应用程序模板42的应用程序结构信息，以便鼓励通用和应用程序专用元素进行适当地处理和解码属性值的分配。被解码的应用程序302的定义可进一步选择性地由第二解码器40进行处理，以便完成解码属性的转换，这种转换通常是从二进制到原文的转换。当准备好时，被解码的应用程序302的定义传送到应用程序规定的服务32，并且例如为在设备12上执行而进行安装。应当承认上面描述的解码器34的组成和操作还适用于在操作规定的解码应用程序302期间，从Web服务13中解码通过设备12接收的消息105(参见图1)。还应当承认，解码器34可以表示为具有两个专用解码器34、40，如上所述，或者可以表示为解码通用和应用程序专用预定义元素的组合解码器。还应当承认，解码器34可以在数据服务器18和/或Web服务13(参见图1)的信息源20上实现，以便于在担当Web服务13的Web客户时，对从设备12接收的任何消息105的被压缩的内容进行解码。

此外，应当承认字典38可以从解码器34中分离，而且该解码处理(当通过运行时间环境206来执行时)可以根据需要对部分或全部预定义的通用和应用程序专用元素进行解码。例如，运行时间环境206可以使用字典来解码应用程序专用元素，并且将通用元素以被压缩的格式留在设备12上。

参照图5，图5表示软件应用程序压缩工具52的框图。与图4中一样，图5包括直接涉及软件应用程序302压缩的那些组件。压缩工具52，或与被配置为可操作的压缩工具52相关联的系统(诸如运行时间环境506)还可以包括除了图5中的部件之外的部件。应当承认，运行时间环境506可以是服务提供商13的系统(在服务器18和/或源20上)的一部分，而且还可以是该设备12的运行时间环境206的一部分。

压缩工具52从本地或远端应用程序源20接收软件应用程序302，对该软件应用程序302进行压缩，并且为目的地提供被压缩的软件应用程序302。该目的地是设备12或被配置为用于处理被压缩的软件应用程序302的系统，或可能是应用程序源20。例如，当应用程序源20使用远端压缩工具52来压缩软件应用程序302时，被压缩的软件应用程序302返回到应用程序源20，然后存储该被压缩的软件应用程序302，以便随后发送到适当配置的设备12或系统。

再次参考图5，在压缩工具52中，压缩字典38包括用于编码通用XML元素和属性的通用字典400，以及用于处理应用程序专用属性值的应用程序专用字典402。字典38包括与在目的地设备12或系统处的字典38中存储的字典相同的匹配字典400、402，所述目的地设备12或系统被配置为对已经由压缩工具52压缩的软件应用程序302进行处理。然而，应当理解，字典38还可以包括其它的通用和应用程序专用字典400、402，该字典400、402为多个设备12表明了其它的模板42和应用程序302的定义。第一编码器54(例如WBXML)使用字典400来编码XML元素和定义了应用程序资源的属性。应用程序定义模板42包括有关应用程序302(包括有线和无线)的专用类的通用结构的信息、以及有关被显示参数和任何其它未编码数据的信息。第二编码器(例如，二进制混淆)58使用来自字典38的应用程序专用字典，以进行编码，例如混淆和二进制编码，应用程序专用属性值。

软件应用程序定义模板42由压缩工具52来接收，并且被传递到第一编码器54，该第一编码器54从二进制字典38中检索用于软件应用程序302的适当等级的通用字典400。在对通用XML元素和属性进行编码之后，第一编码器54将部分已编码应用程序302的定义传递到第二编码器58。该第二编码器58从字典38中检索应用程序专用字典402，以便编码/混淆应用程序专用属性值，并且从应用程序定义模板42中查找应用程序结构信息，以便在混淆之后促进已编码应用程序302的完整性。当完成二进制混淆(binary obfuscation)时，将已编码和压缩的应用程序302的定义释放到目的地，该目的地为打算的接收设备12或系统，或者例如是在应用程序源20处的软件应用程序302库。应当承认，上面描述的编码器52的组件和操作还适用于编码消息105(参见图1)，所述编码消息105是在规定的解码应用程序302操作期间通过设备12从Web服务13接收的，或者是通过设备12发送到Web服务13。还应当承认，如上所述，编码器52可以表示为具有两个专用编码器54、58，或者可以表示为用于解码通用和应用程序专用预定义元素的组合解码器。还应当承认，编码器52可以在数据服务器18和/或Web服务13的信息源20(参见图1)上实现，以便于在担当Web服务13的Web客户时，对发送到设备12的任何消息105的被压缩的内容进行编码。还应当承认，可以在设备12上实现编码器52，该编码器52用于对发送到数据服务器18和/或Web服务13的信息源(参见图1)20的任何消息105的压缩内容进行编码。

压缩软件应用系统可适用于多种可能的拓扑。图6是第一种压缩软件应用系统拓扑结构的框图。在该第一种拓扑结构中，压缩工具52从应用程序源20接收软件应用程序302，并且将被压缩的软件应用程序302发送到设备12，该设备12可以包括被压缩的应用系统运行时间206，诸如在图4中所示。压缩工具52在中间系统中运行，并且代表应用程序源20压缩和分发软件应用程序302。在该拓扑结构的一种变型中，将压缩软件应用程序302返回到应用程序源20，该应用程序源本身对被压缩的软件应用程序302进行分发。“混合”变型也是所预期的，其中软件应用程序302被远程压缩，并且根据打算的目的地设备12或系统或软件应用程序302的类型，由压缩工具52和应用程序源20进行分发。

图7是另一个被压缩的软件应用系统拓扑结构的框图。在第二种拓扑结构中，应用程序服务提供商13包括应用程序源20和压缩工具52。设备12和被压缩的应用程序运行时间206实际上与图6中类似标记的部件相同。基于此，明显地是从图4和图5中可以看出，设备12的执行独立于拓扑结构。尽管已分别示出并描述了各种拓扑结构，但还可以将设备12配置为与支持各种拓扑结构的应用程序源20和服务提供商13进行通信。同样期望设备12可以与多个信息源20进行通信，其中的某些支持图6的拓扑结构，而另一些支持图7的拓扑结构。类似地，应用程序源20还可以支持用于扩展对压缩软件应用程序302有效的编码类型的拓扑结构。

当通过应用程序源20来提供保密或其它敏感的信息时，诸如图7所示的集成系统可能显著地不利。在这种情况下，不需要中间部件来压缩信息。例如，倘若端到端是安全的，则在服务提供商13处被加密的保密信息一直保持加密直到在设备12处解密为止，反之亦然。

二进制压缩方案的操作举例

图3a是表示压缩软件应用程序302的方法的流程图。该方法22包括通用预定义标志和属性的二相二进制转换和用于预定义专用应用数据的二进制混淆。图3b是表示解码软件应用程序302的方法的流程图。该方法23包括通用预定义标志和属性的二相二进制解码和预定义专用应用数据的二进制解码。

参考图3a和图5，在步骤24，通过压缩工具52从诸如20的信息源(参见图1)接收软件应用程序302。正如下面所描述的，压缩工具52可以在内容或服务提供商13处连同信息源13一起来实现，或者在为信息源20执行压缩的独立的系统(未示出)处，诸如在信息源20和打算接收被压缩的软件应用程序302的目的地设备12之间的中间第三方设备12或系统处实现。通过使用诸如DTD或XML方案的应用程序定义模板42，例如在应用程序模板42中的通用预定义元素名称和属性在步骤26被二进制编码。该通用预定义元素的编码是这样的，即在二进制压缩字典38中用于预定义元素名称和属性的二进制代码在压缩工具52和目的地设备12之间共享。基于此，与WBXML编码不同的是，不需要利用已编码的应用程序302的定义来查阅二进制压缩字典38。

通过使用应用程序302的定义的层次结构，步骤28包括对未向设备12的用户显示的预定义专用应用数据的二进制编码。可以从根部向下到相关叶节点并且以“从左到右”的顺序来执行该应用程序专用元素的编码。在步骤28的编码过程中，交叉引用的值优选地要保持完整，以便有助于最终得到的压缩应用软件302的正确性和完整性。在步骤28中，XML属性值的编码同样优选地与为应用程序模板42中的属性值定义的专用应用软件二进制字典402编码相匹配。例如，如果将属性类型定义为：

type(label|edit|text|list|radio|checkbox|button|image)#REQUIRED

然后，二进制字典402包括用于标签、编辑、文本、列表、无线电、检验栏、按钮和图像的二进制代码。当压缩工具52在XML应用程序302定义中遇到类型＝“标签”时，工具52将该字符串转换为相应的分配给在字典402中表示为“标签”的二进制代码。

参考图3b和图4，在步骤25，通过解码器34从诸如20的信息源(参见图1)接收软件应用程序302。通过使用诸如DTD或XML方案的应用程序定义模板42，例如在应用程序模板42中的通用预定义元素名称和属性在步骤27被二进制解码。该通用预定义元素的解码是这样的，即在二进制压缩字典38中用于预定义元素名称和属性的二进制代码在解码器34和目的地设备12之间共享。基于此，与WBXML编码不同的是，不需要利用已编码的应用程序302的定义来查阅二进制压缩字典38。

通过使用应用程序302定义的层次结构，步骤29包括对未向设备12的用户显示的预定义专用应用数据的二进制解码。可以从根部向下到相关叶节点并且以“从左到右”的顺序来执行该应用程序专用元素的解码。在步骤29的解码过程中，交叉引用的值优选地要保持完整，以便有助于最终得到的压缩应用软件302的正确性和完整性。在步骤29中，XML属性值的解码同样优选地与为应用程序模板42中的属性值定义的专用应用软件二进制字典402编码相匹配。例如，如果将属性类型定义为：

type(label|edit|text|list|radio|checkbox|button|image)#REQUIRED

然后，二进制字典402包括用于标签、编辑、文本、列表、无线电、检验栏、按钮和图像的二进制代码。当解码器32在XML应用程序302定义中遇到类型＝“标签”时，解码器32从分配给在字典402中表示为“标签”的相应二进制代码来解码该字符串。

对于任意应用程序专用定义模板42来说，应当基于编码定义中的应用程序专用元素所需的字节(或比特)数的知识来进一步优化所述编码/解码。例如，在上述DTD定义中，用于数据、消息或屏幕元素的二进制代码可能仅需要用于编码的单个比特。此外，可以将总的字节范围0-xFF划分为子字节范围，例如用于数据的0-x60，用于消息的x61-xC0以及用于屏幕的xCI-xFF。

示例1

将下面通常的XML文档片段考虑为应用程序定义的一部分：<elem1 attr11＝″a11.1″attr12＝″a12.1″>   <elem2attr21＝″a21.1″>data21</elem2>   <elem2attr21＝″a21.2″>data22</elem2>

<elem2attr21＝″a21.3″>data23</elem2></elem1> <elem3attr31＝″a31.1″attr3＝″[Ref]a21，1″>

<elem4attr41＝″a41.1″>[Ref]a11，1</elem4></elem3>.其中[Ref]表示用于与XML文档(例如，字符串″@″inWirelessPizza XML示例)中的其它值交叉引用的应用程序专用格式，并且仅有属性值a12.1and a41.1和elem2中的数据是对于设备12的应用程序302用户可显示的参数。

在被压缩的格式中，该XML片段的外表特征是：

WB1WB5BO1WB6a12，1  WB2WB7BO2data21WB2/  WB2WB7BO3data22WB2/  WB2WB7BO4data23WB2/  WB1/  WB3WB8BO5WB9BO2

WB4WB10a41.1BO1WB4/ WB3/，

其中WB#码表示二进制编码(步骤26)的结果，而BO#码表示二进制混淆(步骤28)的结果。应当注意，已经将交叉引用的值a11.1和a21.1分解为相同的二进制代码B01和B02，以便有助于被压缩应用程序302的正确性和完整性。应当承认，如果需要的话，WB#代码可以表示为一个单独码(例如，WB1WB5＝WB15)或表示为一系列多个码。

示例2

将下面的示例DTD(模板42)考虑为定义无线应用程序302的XML资源。

<!ELEMENT application(data*，msg*，screen*)><!ATTLIST application

name CDATA#REQUIRED>

<!ELEMENT data(field+)>

<!ATTLIST data

  name CDATA#REQUIRED

  persisted(true I false)″true″>

<!ELEMENT dfield(#PCDATA)>

<!ATTLIST dfield

   name CDATA#REQUIRED

   type(String|Number|Boolean|Date|Any)″Any″

  array(true|false)″false″

  nested(true|false)″false″

  nestedName CDATA#-IMPLIED

  key(true|false)″true″>

<!ELEMENT msg(field*)>

<!ATTLIST msg

name CDATA#REQUIRED

mapping CDATA#IMPLIED><!ELEMENT mfield(#PCDATA)><!ATTLIST mfield

name CDATA#REQUIRED

 type(String|Number I Boolean I Date|Array|XML)#IMPLIED

mapping CDATA#IMPLIED><!ELEMENT screen(control*，menu+)<!ATTLIST screen

name CDATA#REQUIRED

title CDATA#IMPLIED

dialog(true|false)″false″

param CDATA#IMPLIED>

<!ELEMENT control(entry+)><!ATTLIST control

name CDATA#REQUIRED

value CDATA#IMP LIED

mapping CDATA#IMPLIED

type(tabet|edit|text|list|radio|checkbox|button|image)#REQUIRED

entrytype(char|number|date|pwd|phone|email)″char″

readOnly(true g false)″false″

placement CDATA#IMPLIED

style CDATA#IMPLIED> <!ELEMENT menu(item*)><!ELEMENT item EMPTY><!ATTLIST item  name CDATA#REQUIRED   label CDATA#REQUIRED   screen CDATA#IMPLIED>  msg CDATA#IMPLIED><!ELEMENT entry(#PCDATA)>

可以以XML将与上述示例性模板42(例如DTD)相兼容的简单无线应用定义如下：

wcApp name＝″WirelessPizza″>  <data name＝″User″>

<dfiield name＝″name″type＝″String″key＝″true″/>

<dfield name＝″password″type＝″String″/>

<dfiield name＝″street″type＝″String″/>

<dfiield name＝″city″type＝″String″/>

 <dfield name＝″postal″type＝″String″/>

 <dfield name＝″phone″type＝″String″/>

</data><data name＝″OrderStatus″>

<dfield name＝″confNumber″type＝″Number″key＝″true″/>

<afield name＝″status″type＝″String″/>

    <dfield name＝″datetime″type＝″Date″/>

</data>

<data name＝″Order″>

      <dfield name＝″orderld″type＝″Number″key＝″true″/>

      <dfield name＝″items″type＝″String″array＝″true″/>

      <dfield name＝″user″nested＝″true″nestedName＝″@User″/>

      <dfield name＝″datetime″type＝″Date″/>

      <dfield name＝″orderStatus″nested＝″true″nestedName＝″@OrderStatus″/>

 </data>

 <msg name＝″onOrderStatusUpdate″>

    <mfield name＝″orderld″mapping＝″@Order.orderld″/>

    <mfield name＝″status″mapping＝″@Order.orderStatus″/>

 </msg>

 <msg name＝″updateUserlnfo″mapping＝″User″/>

 <msg name＝″placeOrder″mapping＝″Order″/>

 <screen name＝″scrDelivery″title＝″Please provide delivery info″param＝″@User″>

 <control name＝″lbl Street″type＝″label″value＝″Street：″/>

 <control name＝″edStreet″type＝″edit″mapping＝″@User.street″/>

 <control name＝″lblCity″type＝″label″value＝″City：″/>

 <control name＝″edCity″type＝″edit″mapping＝″@User.City″/>

 <control    name＝″lblPostalCode″type＝″label″value＝″Postalcode：″/>mapping＝″@User.postal″/>

 <control name＝″lblPhone″type＝“label″value＝″Telephone:″/>

 <control name＝″edPhone″type＝″edit″entrytype＝″phone″

                              mapping＝″@User.phone″/><menu>

 <item name＝″sendOrder″label＝″Send Order″

     screen＝″@scrOrderSent″msg＝″@placeOrder″/></menu></screen>

应当注意，应用程序302中的6个专用显示参数在上述粗体中给出。

XML元素标记和属性名称作为预定义通用和应用程序专用元素的二进制代码来编码。如上所述，根据这里所公开的系统和方法的压缩可以使用下面的情形，即仅有打算显示给应用程序302的用户的可显示数据需要被保持而不用进行二进制转换。在一个示例性实施方式中，上述相应编码的″scrDelivery″文档片段可以具有下面的形式：

[BB]Please provide delivery info[BB]

               [BB]Street:[BB]

               [BB]

               [BB]City[BB]

               [BB]

               [BB]Postal Code:[BB]

               [BB]

               [BB]Telephone:[BB]

               [BB]

               [BB]

                   [BB]Send Order[BB]

                   [BB]

               [BB][BB]

其中[BB]表示二进制编码数据。应当承认，[BB]压缩编码还可以表示为用于各种预定义元素和属性的一个或多个二进制代码。

应当理解，上面描述的内容与一个或多个示例性系统和/或方法相关联。对本领域的普通技术人员来说多种变型是显而易见的，而且这种显而易见的变型是在该申请的范围之内，而不考虑是否清楚地进行了描述。

例如，尽管在附图中示出了单个设备12、数据服务器18和信息源20，但是数据服务器18典型地可能经由不同的通信网络16为多个设备12提供服务，并且通过不同的方向或基于网络的连接来接入到多个信息源20。同样，任何通信网络16和任何信息源20都可以与多个数据服务器18进行通信。

上面的描述同样假定了将消息从源20发送到设备12。然而，假定在设备12和在目的地的压缩应用程序系统处的压缩工具52支持在从设备12的输出方向中的软件应用程序302和消息105的压缩。。

在某些方面中，输出内容的压缩级别可能要取决于配置的拓扑结构和安全性要求。对于上述图6中的拓扑结构来说，在远离应用程序源20或其它目的地的中间系统处实现被压缩的应用程序系统工具52，而后可以对包括字段名的整个消息105进行二进制编码。当利用中间系统进行消息105的交换时，可以将字段名定义为二进制代码。然后，通过中间系统利用原始字段名来代替这些代码，之后将它们传播到目的地。该模型可以提供将消息105的尺寸减到最小的额外的好处。在上述图7的拓扑结构中，消息105的字段名不必是可编码的，尽管消息105定义的其它属性，诸如格式、尺寸、类型等是可编码的。

另外，在图4和图5中作为通用XML标记和属性的编码方案的示例示出了WBXML。其它的编码方案对本领域的普通技术人员来说是显而易见的。