CN103608778A - 分发多用户软件应用的方法 - Google Patents

Abstract

一种分发多用户软件应用的方法，所述方法利用在相应的主机设备和远程设备上运行的主程序和远程程序。两个程序作为单一包而一同分发，使得主机设备能够向远程设备发送远程程序或使得远程设备能够向主机设备发送主程序。

Description

分发多用户软件应用的方法

1.本发明的技术领域及概要

本发明涉及一种分发多用户软件应用的方法，并且涉及携带这样的软件的计算机可读介质。本发明具体但不是排他性地涉及被设计成在如移动电话等便携式设备的用户之间进行交换的如计算机游戏等软件。

本发明包括用于将全部二进制可移植计算机软件应用从一个终端用户设备传送至另一终端用户的系统，所述全部二进制可移植计算机软件应用包括所保存的应用状态和应用所需的任何库。计算机软件应用的二进制可移植属性使得这能够在不同类型的设备（包括不同的CPU类型和操作系统）上发生。

这使得在使用传统系统时通常不可能实现的用户情况成为可能，如在设备上提取进行中的被保存游戏（in-progress saved game），将游戏、库和游戏状态传送至第二设备，然后，继续在第二设备上从相同点玩该游戏。而所有这些都不需要与服务器进行连接以下载该应用的必要的库或安装包。

这能够对应用及其状态进行离线分发，从而减小了终端用户的成本、减轻了网络负载以及加速了应用的传送。

1.1背景技术

显示和输入设备虚拟化已经普及了许多年。这使得主机设备和远程设备通过某种通信链路来通信以在远程设备的显示器上显示来自主机设备整个屏幕或者一个或更多个窗口，并且将来自远程设备的输入事件（如键盘和鼠标事件）转发至主机设备以进行处理，就如同这些事件发生在主机设备上一样。

该方法的示例包括X-Windows、微软远程桌面连接和VNC。

在所有这些情况下，主机系统的输出被发送至远程系统以进行显示。上述输出通常被编码为渲染指令序列而不是被编码为屏幕捕获序列，因为将上述输出编码为渲染指令序列会导致较小通信量并且因此提高性能。

在微软远程桌面连接和VNC情况下，远程设备通常显示与主机设备相同的信息。在X-Windows中，远程设备通常用作用于在主机系统上运行的某些程序的主显示器。

该方法的更新实施包括微软Windows媒体中心扩展器和PS（游戏站）-3远程游戏设施。在这两种情况下，主机设备向用户发送对要显示的信息进行描述的一组指令，如菜单和可用内容等，并且当用户选择一段内容时，编码视频流被发送至远程设备，该远程设备对上述编码视频流进行解码和显示。

已经在如Java等二进制可移植编程环境中实施了VNC和X-Windows。

上述系统通常是不特定于其输入和输出以远程的方式给出的应用的普通服务。但是，存在以下其他系统：用于在远程设备上显示结果的程序和通信协议特定于主程序。

在这些系统中，远程程序的目的不是简单地在主机设备上显示应用的正常输出（有效地用作辅助显示器和输入装置集合），而是显示关于主机应用的状态的不同信息，并且指导用户向主机应用提供输入。远程程序是利用主机应用的数据结构和逻辑来编写的，并且在两个终端之间传送的信息通常表示语义对象，并且表示用户动作的更高级表示，如已经从列表中选择了特定项的信息等而非原始的按键或鼠标移动。上述语义对象表示主程序的状态而不是显式的渲染指令。

用户接口的显示是由远程程序基于保存关于主程序的状态的信息来完成，从而相比先前所述的方法，所使用的网络通信量大大地减小。图形、音频和其他资源可以使用远程程序来打包或可以根据需要从主程序通过通信链路来传送。

Windows Phone7设备的“Meteor”应用是该方法的示例，该应用连接至运行Windows媒体中心应用的PC（personal computer，个人计算机），并且显示使得电话用户能够控制Windows媒体中心的操作（包括显示可用内容、TV向导列表等）的用户接口。

再次使用二进制可移植代码来实施这样的系统（例如，上述“Meteor”程序是在作为二进制可移植系统的.NET框架中实施的）。

1.2发明内容

在本文献中所描述的系统是上述第二种类型的系统的扩展，即，具有自定义通信协议的应用指定远程程序。

通常，这些系统要求用户手动地在主机设备上安装主机应用程序和在远程设备上安装远程应用程序两者。

该文献描述了一种系统及方法，其中，“主程序”和“远程程序”被打包和一起分发，并且其中作为这些应用程序的基础的软件平台提供了用于自动将这两个程序或其中任何一个从第一计算设备发送至第二计算设备，以使得这些设备之一用作上述情形中的“远程设备”，并且另一个用作“主机设备”的功能。哪个设备执行哪个角色的选择取决于用户。

该文献还描述了一种系统及方法，其中第一设备在一个或更多个通信媒介上使用广播机制来发现可接入并且支持使得该系统工作的必要网络协议和软件特征的设备。

将上述程序部署给目标设备的处理是由用户触发并且以最小的用户交互来进行（至少需要选择目标设备和要发送的项）。此外，还需要某种安全交互，例如，每当该处理发生时或仅在第一情形中（“配对”设备），在这两个设备上输入个人标识号。

在优选实施方式中，主程序和远程程序在二进制可移植软件系统中实施，以使得它们可以在不同类型的设备之间传送，上述不同类型的设备包括具有不同形状要素的设备（如个人计算机、数字电视、机顶盒、移动电话等）和具有不同或是不兼容CPU的设备。

单一的软件应用（程序）可以实施主程序功能和远程程序功能两者。

本发明可以以多种方式来实施，并且将参考附图来描述各种具体实施方式，其中：

图1示出了实施本发明的单一远程程序；

图2示出了使用多个远程程序和单一主程序的纸牌游戏；

图3示出了在会话中作为对等物进行通信的应用的多个实例；

图4示出了组内的两个以上的应用；

图5示出了可移植二进制主机和远程程序在各种设备类型、CPU和操作系统上的使用；

图6示出了二进制可移植主机/远程包从移动设备的播送；

图7示出了二进制可移植主机/远程包从固定设备的播送；

图8示出了将不同网络媒介用于成批数据传送；

图9示出了应用指定远程程序；

图10示出了普通远程程序；

图11示出了当接收到播送包时目标设备的操作；

图12示出了依赖性协商；

图13示出了支持必需服务的设备的发现；

图14示出了元数据组件和播送包的创建；

图15示出了使用SRP协议以验证PIN或通行码的知识并且启动加密通信链路；以及

图1a至图8a在附录中被引用。

2.具体实施方式

2.1必要条件

本发明的优选实施方式是在[1]和[2]中描述的系统的扩展。其使用与在[1]中描述的相同的二进制可移植软件分发格式、打包格式、依赖性机制等，并且对在[2]中描述的元数据系统进行扩展以处理远程设备输入的具体使用情形。假定读者已经熟悉[1]和[2]。

2.1.1PCT/EP2010/056123（WO2010/145886）的相关部分的扼要重述如在[1]中描述的：

●二进制可移植软件系统分发格式采用应用程序的中间编译器表示的形式，其中，当精确的CPU架构已知时，编译的最终步骤（代码生成、寄存器分配等）在目标设备上完成。

●打包格式是“JAR”文件格式（被称为“ATX”文件格式）的扩展。JAR格式的扩展简单地为一些自定义清单属性的定义。

●ATX文件可以具有两个模式：包含应用代码、资源或元数据的文件（已知为ATX组件）；以及包含其他ATX文件的文件（已知为容器ATX文件）。

●ATX组件使用由Java“jarsigner”工具使用的标准加密算法来数字地进行签名。这用于确保ATX文件的内容的授权。

●容器ATX文件没有被签名，但是包含在其内的ATX文件通常被签名，以使该内容的授权总是可以被验证。

●每个ATX组件包括“清单”：包括某些名称/值对（被称为“属性”）的文件，所述名称/值对定义关于该组件的各种重要信息块，如唯一组件名称和相关联的版本号、由组件（同时具有相关联的版本号）实施的接口的声明、和与其他组件或接口的依赖性，每个指定对于该组件名称或接口的版本号的有效范围。

●每个设备具有唯一设备标识符。这在[1]中用于通过将相关设备唯一ID编码成权限规则集来将权限组件锁定至特定设备。

2.1.2英国专利申请1021875.8的相关部分的概括（参见附录）

如在[2]中描述的：

●应用、库、权限和元数据组件可以一起打包为“播送包”。

●使用适当的机制（如网络广播、服务发现或手动用户输入）来确定目标设备。

●源设备和目标设备可以交换关于已经安装至目标设备的组件的信息，以使得这样的组件可以通过源设备从播送包中移除，从而减小要传送的数据的尺寸。

●元数据组件被生成并且包括在播送包中，该播送包包括某些应用状态数据，如游戏保存信息、设置、用户生成内容（如游戏角色）等。还包括对应该在目标设备上进行处理的应用进行识别的数据项（“AGC-State（状态）-AppDependency（应用依赖性）”清单头）。

●当在目标设备上进行接收时，播送包中的任何应用、库或权限组件被安装。上面生成的元数据组件被提取并且通过使其内容能够由相关应用定位的方式来使得该内容对该应用可用。

2.2应用会话和会话状态

一组相关联的软件应用被产生，其被设计成通过一些通信媒介来通信并且交换信息以显示并且操作状态数据的组合集。该组应用可以包括：若干独立的应用，其中每个应用在组内执行不同的角色（例如，参见图4）；或者单一的应用，其可以自行执行所有必要的角色（例如，参见图3）。

该组内的一个或更多个应用可能在独立的计算设备上运行并且共同通信，形成“会话”。数据状态的该组合集合与该会话相关联。

取决于应用的架构，在会话内可能存在共同通信的若干不同的应用，例如，应用之一可能是“控制器”应用，而其他“从属”应用（例如，参见图2）；或者，可能仅存在单个应用，其能够与在不同设备上自行运行的其他实例以对等（peer-to-peer）的方式进行通信（例如，参见图3）。

通常，尽管不必要，但是组中的所有应用都被一起分发，无论是在单一ATX组件中（其中，应用被编写为单一组件内的多个程序），还是在容器ATX中（其中，应用被编写为分开的组件）。因此，从给出上述应用中任何一个应用的任何设备，来给出其他应用，因此可用于播送（参见图6，关于从第一设备到第二设备进行播送，然后从第二设备到第三设备进行播送的示例）。

在会话内，表示总体会话状态的数据可以被保留在单一应用的存储器或其他储存器内（而其他应用则保留对于它们执行它们的操作所必须的某个子集），上述数据在会话内可以由所有应用共享，或上述数据可以被分发，即，在会话中不是由应用中的任一个全部保留，而是通过所有应用保留的应用状态数据的组合集合来形成。

每个应用从其所运行的计算设备取得输入，并且将某个输出显示给用户。会话内的不同应用，或运行在会话内的不同设备上的同一应用的实例可以分别向该设备的用户显示不同的信息集合（例如，参见图2）。

关于用户输入的信息可以以表示特定输入事件（如鼠标移动或按键）的数据的形式，或以表示特定应用组的上下文内的语义事件的数据的形式（如由用户做出的播放特定音乐音轨或在游戏中进行移动的请求等）被发送至会话内的其他应用。

2.3将软件应用传送至远程设备

为了使得计算设备能够参与本文献所述的应用会话，必须在设备上配置相关软件应用。

其发生的机制与在[2]中描述的方法相同，其指定在设备之间进行依赖性协商的方法以及创建“播送包”的方式。

这部分给出了出于上述目的使用该方法来传送软件应用的方式的一些更具体的示例。

对于软件应用的传送的目标设备的选择可以以多种方式来进行，包括但不限于：

●使用通过传送媒介（如蓝牙）的已知服务发现协议。

●使用自定义发现协议，该协议通常通过使用基于IP的TCP或UDP的有线或无线传送媒介来利用一些广播形式。

●用户手动输入识别目标设备的信息。该信息可以是网络地址（如IP地址），或其可以是更加用户友好形式的标识，如完全限定性互联网域名或NetBIOS（网络输入输出系统）名称。

在图13中示出了这些技术。

在一些软件平台上，可能有必要由用户将目标设备手动地置于以下状态：准备好接收或响应这样的发现请求或连接。

在另一些软件平台上，这样的发现客户端程序可能一直保持运行，或向软件平台注册以便在检测到引入的连接或请求时该发现客户端程序被自动调用。

一旦目标设备被识别，从源设备至该目标设备的连接被建立。尽管[2]描述了应用软件传送不需要双向通信信道的系统，但是优选地，两个设备能够协商需要被传送的软件的子集和其他信息，以减小网络利用率并且增加传送速度。可以执行依赖性协商的双向连接构成优选实施方式的一部分。

一旦该连接被建立（或其部分被建立），使用安全机制来防止应用的非授权传送。这通常采用连接的加密的形式并且利用通行码或个人标识号（PIN，Personal-Identification-Number），该通行码和个人标识号必须在两个设备上输入以使得传送成功。

可以为用户提供与其他设备“配对”的选项，以允许与该设备进行未来的应用软件传送，而不需要使用通行码或PIN。

安全协议应该包括使每个设备自身相对于其他设备唯一地进行标识的机制，优选地采用下述方式：每个设备不能发送可由另一个设备用来模仿它的信息（例如，通过重放攻击）。

存在并且已知多个这样的系统，如安全远程密码协议[3]。该协议使得两个设备彼此证明，而不是它们两具有PIN或通行码，从而不暴露关于该设备的任何信息，该信息可能被偷听者用于模仿任一设备。此外，该协议导致两方具有可以用于加密通信的共享（但是相对于另一个其他方为秘密）的密钥。该协议用于优选实施方式中，并且在图15中被示出。

已经做出设备之间的连接并且建立了用于应用软件的传送操作的适当级别的安全和授权，现在可以进行[2]中所述的依赖性协商处理。图12示出了该过程，该过程导致产生需要传送以使得软件应用可在目标设备上工作的软件应用或其他组件的列表。

在一些情况下，该列表为空，例如，软件已经在先前传送操作中被传送至目标设备，或软件在两个设备上独立地安装。

文献[2]描述了没有元数据组件的使用，所述元数据组件对包含关于应用状态的信息进行加密签名。该文献详述了针对该机制的使用情形，其中，元数据组件包括关于目标设备要采取的期望动作的信息（例如，启动哪个应用组件以及使用什么样的参数），以及对会话内的其它计算设备进行识别的附加信息，在相关程序被启动时目标设备会变为上述会话的一部分。

该信息很可能采用一个或更多个网络地址以及端口号或服务ID的形式，例如，在简单的情况下，这会对网络端点进行识别，通过所述网络端点目标设备可以连接回发送设备上的原始应用。

如在[2]中所述的，该元数据组件与需要传送的任何应用、库和权限组件一起被打包，并且被传送给目标设备。如在[2]中所述，在目标设备上对上述组件进行安装和处理。

2.4识别期望动作和现有会话成员的元数据组件

由于如网络端点等各种数据块在每次生成播送包时可能不同，在用户选择所采取的动作时，元数据组件（对接收设备所采取的期望动作和现有会话成员进行识别）需要动态地生成。

有多种方式可以生成该元数据，如通过应用声明特定信息以使得软件框架可以在启动本地应用之前生成所有必需的元数据，可能包括网络端点的自动分配。

在此处描述的优选实施方式中，尽管可能利用由软件框架提供的库来执行各个方面的工作如打包和格式化，但元数据的生成主要通过应用自身来进行。

用户首先选择他们希望本地设备操作的模式，换言之，他们希望本地设备所执行的应用角色（服务器、客户端、主控器、从属设备、对等设备等）。角色的可能集合取决于特定的应用或应用的组。

用户可以通过以下来执行该操作：运行来自能够在会话中共同通信的应用组中的特定应用，或从已经运行的应用中选择操作模式（例如，其中相同的应用能够执行多个角色）。

完成此事后，对于呈现为可用选项的应用，用户可以选择启动新会话。有多个可能的应用配置，但是一些示例为：

●用户选择了本地设备来充当远程程序。为用户提供在另一个设备上运行主程序的机会。

●用户选择了本地设备来充当主程序。用户可能能够使用本地设备来完全操作该程序，但是可以提供使得用户能够在另一个设备上运行远程程序的选项（在多玩家游戏中，可能充分地允许用户选择多个远程设备，每个远程设备表示不同的玩家）。

●可能会给用户提供加入已经存在的会话的机会。

存在许多其他的可能应用配置，并且应用应该为用户提供适当的选项。

如果用户希望加入现有的会话，则应用适于以应用指定方式来发现这样的可用会话，并且与现的会话成员进行协商以允许接入。

如果用户选择了表明他们希望启动新会话的选项，则应用执行设备发现，以识别目标设备。目标设备必须支持必要的协议和软件框架以能够接收和处理如在[2]中描述的播送包，因此，通常通过使用由在本地设备上的软件框架所提供的库来促使该设备发现。上面更详细地描述了该设备发现过程。

识别了目标设备以后，应用可以在适当的网络媒介上分配网络端点。通常，这会是与用于发现目标设备的相同网络媒介（如蓝牙或Wi-Fi），但是这不是严格必需的---可以存在确定两个设备都能够通过与用于发现的媒介不同的媒介来通信的机制，并且由于如速度、用电、延迟、安全等准则，这样的媒介可以优选地选择。图8示出了该使用情形的示例。

在这点上，构建播送包的所有信息都可获得。应用调用由软件框架提供的库函数，传递如以下参数：

●目标设备的标识（可能以句柄或通过设备发现库的早先使用而返回的其他标识符的形式）。

●要求在目标设备上可用的组件集合。通常这会包括一个或更多个应用组件。软件框架会根据需要利用依赖性于应用组件的附加组件来自动地对该集合进行扩展。

●对目标设备上应该接收元数据组件的程序进行标识的标识符(URI)（参见，在[2]中指出的“AGC-State-AppDependency”清单头）。

●指定应该在目标设备上运行什么样的应用程序（例如，应该启动哪个模式）和目标设备所连接回的网络端点的应用指定数据。

应用指定数据被打包成元数据组件（参见用于说明的图4），并且播送包被创建，播送包包括该元数据组件以及应用集合、库和由软件框架确定的其他组件。该播送包被传送至上述目标设备。

2.5网络端点

在元数据组件中传送的网络端点是指定要连接的远程地址的文本记录。

这些文本记录包括多个要素：

●网络媒介和/或协议（“地址族”）。

●“地址”指定要连接的联网设备，并且通常是要连接至该设备的特定服务或端口号。该地址的格式特定于“地址族”。

对于IPv4端点，该地址是由以下形成：识别目标设备的32位值（通常格式化为“点地址（dotted quad）”）、16位端口号和表明端点是否被连接（TCP）或为数据报（UDP）的标记。

对于IPv6端点，该地址为：识别目标设备的128位值（通常格式化为8组4个十六进制数字，各组由冒号分隔开）、16位端口号和表明端点是否被连接（TCP）或为数据报（UDP）的标记。

对于蓝牙端点，地址为识别目标设备的48位值（通常格式化为6组2个十六进制数字，各组由冒号分离开）和128位服务UUID。

2.6播送包的接收

如在[2]所示，在目标设备上接收播送包并且安装。总的来说，其如下执行：

●安装任何应用、库或权限组件，如在[1]中所示。

●符合[2]中描述的任何元数据组件按照[2]中所述来安装，其中相关联的应用被自动确定，并且元数据组件的内容以可在启动时（或其他方便的时间）由应用进行列举的方式而对该应用可用。

如上所述，在该文献所描述的具体情况中，应用、库和权限组件表示来自能够通过网络链路进行通信以形成“应用会话”的一组应用程序中的一个或更多个应用程序。

当播送包内容已经被安装时，自动启动由元数据包中的“AGC-State-AppDependency”属性所识别的应用（如果该应用已经在运行，则被切换）。这可能须经受用户确认。

当该应用开始或被切换时，使用在[2]中描述的系统来列举元数据的“引入”项。当找到如在章节2.4中描述的所生成的元数据项时，其对指定期望动作和网络端点的应用指定数据进行检索。其通过切换至所请求的应用模式并且做出到所指定的网络端点的连接来按照这些指令执行。如上所述，原始设备应该已经在侦听该网络连接，并且会话设置和另外的操作应该立即进行。

图11示出了当接收播送包时目标设备的操作。

2.7使用应用指定远程程序

上述系统描述了在应用指定远程程序的传送中所涉及的所有共同的方面。剩下的详细内容是应用指定内容，如在形成会话的组内的应用程序的确切功能和协议的详细内容。

但是，可能提及了更多方面，这些方面描述了使用应用指定远程程序（或更具体地，在会话中通信的多个相关联的应用）的益处。

[1]中所述的ATX包可以包括程序代码（在优选实施方式中为二进制可移植程序代码）、图像和音频资源以及其他应用指定数据格式，如游戏关卡地图等。

与自然输入\输出虚拟化系统相比不仅可以极大地减小所传送的数据量，而且可以在会话之间在通信链路的两端（或更一般地，在运行参与会话的程序的所有设备上）缓存状态信息。

通过减小在后续会话开启时在设备之间所必须传送的数据量，进一步减小了网络通信量。网络通信量的减小又导致较快的启动和改善的用户体验。

当运行在主机系统上的应用具有要求远程设备上的屏幕改变或音频文件被播放的某种状态变化时，需要经过网络传送的信息为最小---仅仅为描述状态变化的数据。可以以低带宽需求和低延迟来在远程设备上更新图像，如需要时，还播放音频。

类似地，不是所有的事件都需要发送至主机设备，运行在远程设备上的程序可以在将结果报告给主机设备之前采取多个独立动作。

图9示出了应用指定远程程序情况。

2.8一般远程程序

尽管该描述公开了能够在会话中一起通信的一组应用程序的某个子集的半自动传送和启动，但是上述系统可以容易地支持“一般远程程序”，该程序不特定于主机应用程序。

使用该方法，主机应用程序代码可以相对地或完全地没有改变并且仍然支持该功能。

可以在远程设备上收集并且显示的输入和输出的范围相比可以使用应用指定远程程序来实现的范围而言不太全面，但是这仍然是有用的功能。

一般远程程序通常是被编写成使用网络连接来与某个软件进行通信的一种程序，所述某个软件作为主机应用程序所运行的软件框架的一部分来运行。因此，该软件可以插入输入事件并且从主机应用收集输出数据，而不需要改变主机应用程序自身。

一般远程程序可以简单地传送用户在远程设备上使用可用的输入设备（按钮、触摸屏、加速计）而触发的文字输入事件，或其可以执行输入事件的一些翻译或模拟，例如通过允许用户通过触摸触摸屏的不同区域（例如，4向键区、模拟操作杆、键盘等）而模拟不同输入事件来进行。在该情况下会显示适合的图形来指导用户的输入。

一般远程程序可以为用户提供在不同输入模式之间进行切换的机制，以使得用户能够使用触摸屏幕或其他单一输入设备来模拟来自多个不同输入设备的输入。

此外，用于在主机设备与远程设备之间通信的网络协议可以包括，哪个主机应用程序正主机设备上运行的通知。这使得一般远程程序能够记录用户针对不同应用选择了哪些输入设置，并且自动切换至正在使用的主机应用的、所记忆的模式。

在一般远程协议的主机侧实施的程序（通常用作运行主机应用的软件框架的一部分或紧密地链接至该软件框架）可能能够接收来自主机应用的关于其希望从哪个输入设备接收输入的反馈（可能通过由主机应用调用使能特定输入设备的某个API）。该信息可以被传达至一般远程程序以便能够为主程序自动选择适当的输入模式，而无需用户手动选择模式。

如音频输出和振动等简单输出可以以类似的方式来控制，尽管通过网络连接传送音频数据的额外延迟可能使得这在某些情况下不能实现。其中应用在较后时间注册要播放的样本并且随后触发回放的斑点效应可能要好于流视频---在特定软件环境中应用可用的API可以确定这是否可行。

图10示出了一般远程程序情况。

2.8.1一般远程程序的操作

一般远程程序可以以多种方式来工作。优选的实施方式如下。

一般远程程序首先由用户在远程设备上运行。在这方面，给予用户多个选择：

●搜索现有会话。如果该选项被选择，则一般远程程序尝试连接至软件框架的现有运行实例，该现有运行实例已经运行远程协议的主机侧。

这可以通过使用广播/多播机制，或通过列举远程设备先前与其通信或与其“配对”的一组设备来完成。

如果成功，则远程设备变为现有会话的一部分。

●在另一个设备上运行程序并且使用一般远程协议连接该设备。如果该选项被选择，则以上章节2.4中所述的序列被启动，其中目标设备被选择，要运行的程序被选择并且播送包被创建。

播送包内的元数据组件根据由一般远程程序提供的数据来生成。它指定，要在远程设备上运行的程序是实施一般远程协议的主机侧的某种“占位”应用。此外，它指定如由用户先前选择的要运行的程序、和其侦听连接的网络端点。

运行所选择的应用所需的任何软件组件包含在使用上面及[2]中描述的机制的播送包中。此外，如有必要，可以包括操作一般远程协议的主机侧所需的任何软件组件。在一些实施方式中，这些组件内置于软件框架中，但是在其他实施方式中，这些组件是分开的并且以与在[1]和[2]中所述的任何其他应用软件相同的方式来“播送”。

当接收到该播送包时，目标设备（在该情况下，这是“主机”设备）安装任何必需的软件组件并且如在[2]中所述，使得元数据包在相应应用的“引入”区域中可用，并且调用相关联的应用。

在该情况下，相关联的应用是处理一般远程协议的主机侧的应用。相关联的应用启动，实现返回至一般远程程序正在侦听的网络端点的连接，然后调用所指定的应用程序（其由远程设备上的用户来选择）。

取决于软件环境，可能同时运行两个程序，或可能有必要退出第一程序，以便以允许第一程序的必要部分保持出现在计算机存储器中的某种方式来链接至所选择的应用，从而其可以与一般远程程序通信并且将输入事件插入到主程序并且截听其输出。

该细节是操作系统所特定的并且是应用所指定的，并且此处不进行说明，但是示例包括，使用“终止并且保持贮存”程序、允许多个程序同时运行的操作系统等。

●前一选项的退化变型，其中用户选择远程设备和要在该设备上运行的程序，但是没有设置远程输入设备。

这仅仅是在目标设备上播送和/或启动应用的方式。与前一选项中的描述相同的机制被使用，但是元数据组件中省略了所连接回的网络端点。

在接收端，通常处理一般远程协议的主机侧的应用在安装了来自播送包的任何必要组件之后如上所述进行启动，但是由于缺乏远程网络端点，其简单地调用由用户选择的主机应用。在该情况下，在主机应用运行时第一应用不需要保持运行或驻留在内存中。

3.使用情形

3.1单一远程程序

在一种实施方式中，存在连接至主程序的单一远程程序，使得用户能够通过使用远程设备上的输入设备来控制主程序。

图1示出了该使用情形。

3.2远程程序的多个实例

在另一种实施方式中，存在连接至主程序的相同远程程序的一个以上的实例，其中每个远程程序使得用户能够控制如上主程序，但是在该情形中，远程设备还可以示出对于该特定远程设备的用户而言为私密的信息，如扑克等纸牌游戏中的纸牌，或“战舰”中用户的舰船的位置。主机设备仅示出了对于所有用户为公开的共享信息。

图2示出了该使用情形。

3.3单一程序的多个实例

在另一种实施方式中，存在对于同一应用的用作对等物（没有总体的控制器）的多个实例。通常在该情形中，每个应用与会话内的所有其他应用通信，而不是与单一控制应用实例通信。

图3示出了该使用情形。

3.4组内的两个以上的应用

在另一种应用中，在可以在会话中进行通信的应用组中存在多于两个的分离的应用。在会话内可能存在这些应用中的一些应用的多个实例，通常运行在不同的设备上。

图4给出示出该使用情形的示例。

3.5二进制可移植性

在优选实施方式中描述的软件的二进制可移植属性意味着软件在根据硬件（CPU、输入设备等）和软件（操作系统）而不同的广泛的远程设备上是可用的。

为了给出具体的示例，主机设备可以是机顶盒或电视，并且远程设备可以是运行Andriod、Windows-Mobile、Symbian、Linux等并且具有带有ARM（高级精简指令集机器）、MIPS（美普思）或x86构架的CPU的移动电话或各种其他设备。这可以具有触摸屏输入、简单的数字小键盘、加速计等。

图5示出了该使用情形的示例。注意，相同的二进制可移植远程程序在若干不同的设备上被使用，并且其可以在所有这些设备以及更多设备（支持运行二进制可移植应用的必要软件框架的任何设备）之间使用二进制可移植主程序进行打包和播送。

3.6播送来自便携式设备的主机/远程程序

在该使用情形下，在便携式设备（如移动电话）上具有应用的用户可以将该应用连同其远程程序播送至另一个便携式设备和/或固定设备，如电视。

然后可以在这些设备之间启动会话，其中原始设备可以运行主程序或远程程序（或组内的任何其他应用）。

图6示出了该使用情形。

3.7播送来自固定设备的远程程序

在该使用情形下，用户在固定设备（如电视或机顶盒上）下载（或是安装）应用。然后其将应用的远程程序（通常随着该应用）播送至一个或更多个便携式设备，如移动电话、数字音频播放器等。

然后如先前使用情形下，可以启动会话。在该情形中，原始设备（固定设备）通常会运行主程序，并且便携式设备将运行远程程序。

图7示出了该使用情形。

3.8针对发现使用与用于随后的通信不同的网络媒介

在该使用情形下，原始设备和目标设备针对成批数据传送使用与在进行设备发现时不同的网络媒介。

这可能出于功能、速度、延迟、用电、安全等原因。例如，一种媒介可能支持多播或广播或标准的服务发现机制，使得该媒介对于操作的发现部分是优选的。另一种媒介可能具有不同的有利特点，其使得该媒介对于成批数据传送是优选的。

图8以网络媒介蓝牙和Wi-Fi为例示出了该机制。

在该图中，设备A使用标准的蓝牙服务发现协议发现设备B。这使得设备B能够广告：其支持在本文献中描述的播送和/或应用会话协议，并且使得设备A能够搜索支持相关协议的设备。

该设备通过蓝牙网络启动数据连接。使用该连接，设备传达它们在任何其他网络媒介上的网络地址（例如，它们在Wi-Fi网络上的IP地址）。

对于两个设备均具有地址的任何网络，设备A打开侦听连接并且随机生成安全密钥。网络端点信息和随机密钥通过蓝牙连接被发送至设备B，设备B尝试连接至指定的网络端点。在图8所示的示例中，设备A所创建的侦听端点可能是随机分配的端口号。

注意，设备没必需具有足够信息来确定它们位于相同物理或逻辑网络，但是它们可以使用相同的协议确定它们位于一个网络（例如，他们都具有IP地址），所以它们可以尝试通信。

如果设备B成功设法连接至指定的网络端点（在该情况下，为IP地址和端口号），进行安全交换，其中每个设备验证另一个设备具有正确的安全信息（不会泄漏安全信息）。

此外，可以交换其他信息，并且可以进行测试以确定该连接是否适合于成批数据传送——例如，上述设备可能需要确定它们位于相同物理或逻辑网络上，如此，对该连接的使用通常不会引起明显的数据成本。这可以利用IP协议通过将TTL（存活时间）字段设置为很小的值以使得包不会到达在本地网络以外的路由。

如果成功地进行了这些协商，则可以关闭蓝牙连接，并且可以通过新的连接来进行所有另外的数据传送。如果没有成功，则如果另外的网络地址可用的话，可以尝试另外的网络地址，并且万不得已蓝牙连接可以用作成批数据传送。

参考文献

[1]RIGHTS MANAGED DISTRIBUTABLESOFTWARE:PCT/EP2010/056123:Shelton(Published as WO2010/145,886)。

[2]UK Patent Application1021875.8:Beaming of Binary-PortableSoftware Including Dependencies and Application State该英国专利与本申请的附录对应。

[3]T.Wu,"The Secure Remote Password Protocol",In Proceedings of the1998Internet Society Symposium on Network and Distributed SystemsSecurity,San Diego,CA,pp.97-111。

附录

这是英国专利申请1021875.8的完整副本：包括依赖性和应用状态的二进制可移植软件的播送

分发软件的方法

1.技术领域

本发明涉及一种分发软件的方法和承载这样的软件的计算机可读介质。本发明具体地但非排他地涉及软件，比如被设计为在便携设备（比如移动电话）的用户之间交换的计算机游戏。

2.导言

许多通用计算机系统允许用户人工复制应用状态数据——例如文字处理器文档等。常见的是，游戏控制台允许用户将保存的游戏状态复制到外部介质上（例如WII和GameCube（游戏盒子）控制台允许这一点）。

一些游戏平台允许用户向其他玩家传送某些游戏状态信息，比如车赛记录，从而接收玩家可以与所记录的游戏有效地竞赛并且受到挑战以试图胜过特定分数或者时间。高分数是通常在一群玩家之间共享的游戏状态项目的另一个例子。

用于移动设备的J2ME Java应用环境在一些情况下具有将应用从一个用户直接发送到另一用户的功能。

根据本申请，提供一种分发二进制可移植软件的方法，该方法包括：

（a）在第一用户设备上运行软件应用并且存储定义软件应用的状态的应用状态数据；

（b）从第二用户设备接收为了运行软件应用而需要的且尚未安装的所需软件组件的细节或者需要更新的所需软件组件的细节；

（c）生成用于向第二用户设备传送的、包括应用状态数据和所需的软件组件的包；

（d）向第二用户设备传送包；

（e）确定所述状态是否已经保存在第二用户设备处；并且

（f）向第二用户设备的用户提供用于从所述状态运行软件应用的选项。

本发明还扩展至一种计算机可读介质，该计算机可读介质存储用于在数字计算机（比如移动电话）上实施权利要求1的方法的程序代码。

可以用许多方式将本发明付诸实践，并且现在参照如下附图，通过示例描述若干具体实施例：

图1-在传送之间未修改的数据。

图2-在传送之间在原始设备上修改的数据。

图3-在传送之间在目标设备上修改的数据。

图4-在传送之间在两个设备上修改的数据。

图5-传送应用以及所有依赖性和所选择的应用状态。

图6-传送应用及其依赖性的子集。

图7-仅传送应用状态。

图8-播送（beaming）包的低成本离线传送。

3.说明

3.1技术背景

通常从服务器下载或者从物理介质安装软件应用。如果被下载，则它们经常以安装包到达，该安装包在应用被安装之后即被丢弃。

在许多情况下，应用具有为了运转所需要的依赖性（依赖其它软件块）。这些通常由终端用户人工安装或者无条件地包含于应用的安装包中。

仅安装应用及其库不足以从一个设备向另一设备传送应用的状态。应用一般将数据保存至永久性存储装置以允许信息在应用的不同调用之间保持不变。

这一数据在本专利申请中被描述为“应用状态”并且包括诸如以下项目：

●设置

●文档

●进行中的游戏的当前状态

●完成的游戏的记录

●用户生成的内容、比如游戏角色或者水平

以及许多其它项目。

传统系统未提供用于取得在一个设备上安装的应用（包括任何必需的依赖性和应用状态）并将该应用传送到另一设备的管理方式。

本专利申请描述了一种用于遍及相异设备类型针对二进制可移植软件应用进行上述操作的新颖系统，其中应用的已在目标设备上存在的部分不被传送，因此减少了传送的数据的大小并且因此减少了花费的时间和成本。

3.2益处

这一方式为用户提供了一些重要的优点：

●用户很容易在相异类型的设备之间传送应用及其状态，传统上这是困难的。

●由于传送是（或者至少可以是）直接从一个终端用户设备到另一终端用户设备，所以如果用户靠得较近则可以通过免费网络（比如蓝牙）完成这一操作，从而大大减少或者完全消除通过移动电话网络执行这样的传送的带宽成本。

●即使在无移动设备网络覆盖时通过短程零基础结构网络（比如蓝牙或者点对点（ad-hoc）Wi-Fi也可以传送应用。

●通过分析依赖性并且仅传送应用及其依赖性中在目标设备上需要且尚不存在的那些部分来减少传送应用所花费的时间。

●短程本地传送在许多情况下、特别是在发展中国家通常比移动电话网络更快。这也减少了传送应用所花费的时间。

该方法优选地包括被管理的“版本控制”，该版本控制在接收新状态数据时自动通知应用，并且跟踪它是否比已经在设备上的任何对应状态数据项目更旧、更新或者相同。

应用可以与应用状态数据（连同任何所需的库）一起以下述方式打包：使得所得到的包可以作为单元被发送给另一设备，即使先前未在接收设备上安装对应应用，该接收设备仍然可以允许用户查看/修改应用状态。

这允许通常不可用的使用情况，比如将（如上所述的）游戏挑战连同对应游戏一起发送，从而即使接收者他们尚未安装游戏、仍然可以尝试胜过发送者的分数。这可以用作一种用于鼓励接收者购买游戏的先试后买形式。

对移动电话网络运营商也有益处。移动电话网络即使在网络覆盖良好的发达国家仍然与智能设备的不断增加的带宽要求相抗争。

在发展中国家，在移动电话网络上的网络覆盖和带宽有效性会使得难以在合理时间内传送甚至适度大小的应用。传送大型应用、比如高级3D游戏需要如此之久以至于使它无人问津。

这里描述的系统允许网络运营商提供增强的用户体验，而无需对网络基础结构进行高成本的改进。

其它使用领域包括分布式计算机系统、TV、手持和固定游戏控制台等。

3.3必要条件

这一优选实施例是在本申请人的已公开PCT申请WO/2010/145886中描述的系统的扩展，并且使用与在该文献中的描述相同的二进制可移植软件分发格式、打包格式、依赖性机制等。假设读者熟悉这一公开。在本文中，它将被称为“在先公开”。通过引用将该在先公开合并于此。

3.3.1WO/2010/145886的相关部分的概括

●二进制可移植软件分发格式采用应用程序的中间编译器表示的形式，其中在已知确切的CPU架构时在目标设备上完成编译的最终步骤（代码生成、寄存器分配等）。

●打包格式是“JAR”文件格式（被称为“ATX”文件格式）的扩展。JAR格式的扩展仅是对一些自定义清单属性的定义。

●ATX文件可以具有两个模式：包含应用代码、资源或者元数据的文件（称为ATX组件）以及包含其它ATX文件的文件（称为容器ATX文件）。

●使用由Java“jarsigner”工具所使用的标准加密算法对ATX组件进行数字签名。这用来保证ATX文件的内容的真实性。

●未对容器ATX文件进行签名，但是在其内包含的ATX文件通常被签名，因此无论如何可以验证内容的真实性。

●ATX组件在其清单内具有如下属性：这些属性定义关于组件的各种重要信息块，比如唯一组件名称（和关联的版本号）、由组件（具有关联版本号）实施的接口的声明以及对其它组件或者接口的依赖性，该依赖性分别都指定用于该组件名称或者接口的有效版本号范围。

●每个设备具有唯一设备标识符。这在在先公开中用来通过将相关设备唯一ID编码成权限规则集来将权限组件锁定到特定设备。

3.4创建播送/传送包

为了从一个终端用户设备向另一终端用户设备传送（或者“播送”）应用，必须向目标设备传送许多数据块。在本文中详细描述的发明中，这通过选择相关的数据块并且将它们打包成称为“播送包”的单个容器ATX文件来完成。

要在这一个包中包括的数据包括：

●代表要播送的应用程序的ATX文件，如果其尚未存在于目标设备上。

●尚未存在于目标设备上的任何软件库。

●任选地，包括“权限组件”，该权限组件包含指示可以从何处购买应用的元数据（在在先公开中具体描述了权限组件）。

●用户选择的要向目标设备播送的任何应用状态。例如，用户可以具有多个进行中的被保存游戏、但是仅希望播送其中之一。替代地，用户可能希望仅播送它们的应用设置、但是不播送任何其它保存的应用状态。

因此，在播送包内的数据根据与目标设备交换的数据并且在用户输入时发生变化。

有时可能不能与目标设备直接通信。可能出现这种情形的原因是例如设备的网络连接穿过NAT防火墙、因此不能容易接收引入的连接，并且设备没有足够接近以使用短程技术，比如蓝牙、点对点Wi-Fi或者USB线缆。在这样的情况下，不能确定为了运行应用所需的哪些软件块已经安装于目标设备上，因此作为依靠，系统必须包括应用所需要的所有应用软件和库，或者向用户询问他们希望发送哪些部分。注意，即使在设备之间无直接连接的情况下，应用的传送仍然可能通过间接通信机制（比如电子邮件）来进行。

然而，如果两个设备可以直接通信，则下述更佳方式是可能的：它们可以通信并发现需要传送应用和库软件的哪些部分。

3.4.1与目标设备协商

假如源和目标设备可以通信，它们有可能交换关于安装什么应用、库、资源和元数据组件的信息。

源设备以其所知道的需要存在于目标设备上的组件集开始。这将通常包括主要应用组件本身、如果权限组件可用则加上权限组件。

给定这一组件列表，源设备可以询问每个组件是否安装于目标设备上（使用唯一的组件名称和版本号作为标识符对）。如果组件已经安装于目标设备上，则从列表去除它并且不对其给予进一步考虑。

可替代地，可以在列表中保留组件，并且如果接收设备报告它已经安装的组件的版本比要发送的版本更旧（在组件清单文件内有版本信息），则最终向接收设备发送该组件。

对于没有安装于目标设备上的每个组件，向要考虑的组件列表添加该组件的依赖性，且该过程继续。以这一方式，列举并检查原始组件集的整个依赖性集。

应当注意，如在在先公开中描述的依赖性可以由具有匹配的组件名称的组件或者由实施匹配的接口名称的组件来实现。这意味着依赖性在目标设备上的实施可以不同于在源设备上的实施。这可能是因为在实施所需接口的目标设备上有来自不同供应商的可安装组件，或者可能是因为目标设备上的软件环境包含接口的内置实施。

用于硬件（比如OpenGL-ES（开放图像语言-嵌入系统））的设备驱动器是这方面的常见示例——每个硬件制造商通常通过使用底层硬件能力来提供它们自己的OpenGL-ES软件的实施。在缺乏底层硬件能力时，有可能的是可以存在接口的软件实施（可以存在有来自不同销售商的多个不同软件实施）。

对于正被播送的应用，这是不相关的。接口指定必须实施的行为，因此只要应用需要的接口存在于目标设备上，无论实施如何都满足要求。

通过遵循这里描述的过程，源和目标设备可以协商为了使应用在目标设备上工作而需要传送的组件集。

也有可能的是，可能有在目标设备上不能满足的依赖性，比如在应用需要仅能够在具有特定硬件块（例如输入设备、比如加速度计）的设备上满足的接口时。这可以在协商阶段检测，并且可以用向用户指示失败原因的适当消息来中止播送过程。

3.4.2应用状态数据

应用可以保存多个分开的应用状态数据项目，并且用户可能希望选择要向接收设备传送的该数据的子集；这一子集经常是单个应用状态数据项目、比如进行中的被保存游戏。

在这里描述的系统中，应用本身无需与用户交互以允许他们选择他们希望在播送包中包括哪些应用状态数据的项目。取而代之，应用向软件环境提供描述数据的一些元数据，该元数据之后被软件环境用来允许用户选择应用状态数据。

3.4.2.1应用状态元数据

应用指定的元数据项目：

●用户可见的名称：向用户提供要传送的不同应用状态数据项目的选择，需要用于每个项目的用户友好名称。数据文件的文件名不适合于这一点，因为许多操作系统对文件名中可用的字符施加约束，包括对长度、纯ASCII字符、缺乏大小写、缺乏支持文件名中的空白等的约束。因此，有必要存储对与用户而言应当将数据与文件名区别开的名称。

●图标：代表保存的数据的图形。例如，来自进行中的被保存游戏的屏幕截图或者由应用状态数据代表的字符或者水平的呈现。

●类型：指定应用状态项目代表什么数据类别的值。这允许将可用应用状态项目归类成类别，从而为用户提供在多个应用状态项目之间选择的附加信息。

应用通过调用API函数以将应用状态数据“注册”为应当可用于播送的项目来提供这些元数据。也提供与这些元数据关联的应用状态数据的文件名。应用可以在之后更新这些元数据（例如，如果名称包含时间戳，则只要更新数据时都需要更新名称）。

应用可以调用对应函数以“撤消注册”应用状态项目，从而使它不再可用于播送（并且丢弃任何存储的元数据）。

除了应用明确提供的元数据之外，软件环境自动记录一些附加元数据：

●项目ID：在第一次注册应用状态项目时所分配的随机生成的标识符。应用可能向遵循某一模式（比如游戏水平的名称、时间戳等）的应用状态项目分配名称。这导致很可能出现以下情形：如果在多个设备上使用应用，则可能有命名冲突，即相同名称用来代表实际上不相同的应用状态项目。

在项目的元数据中记录随机标识符，使得以下操作称为可能：以合理的确信度来确定两个应用状态项目是否实际上代表相同的底层数据块或者它们是否仅恰好具有相同名称。

随机生成的标识符以遍及状态数据本身的修改并且也遍及在设备之间的传送而不变的方式来唯一地标识特定应用状态项目（即将它与其它应用状态项目区别开）。系统用来识别两个应用状态项目为“相同”的机制正是用于比较两个应用状态项目以发现哪个更新或者是否需要合并的必要条件。

●版本信息：一旦应用状态数据开始在设备之间被传送，就存在有数据的多个副本，每个副本可以被独立地更新。这引起了额外的问题，即识别哪个版本更新、冲突何时出现等。

这通过记录版本跟踪元数据来完成。在下一节中描述这一点。

●应用名称：对应用状态项目进行注册的应用的名称。

●应用依赖性信息：来自应用组件清单的“AGC-State-AppDependency”属性。将这作为依赖性编码到应用状态ATX文件（见下文）的清单中。应用应当实施对应接口。这允许应用作者对应用状态文件的数据格式的改变的兼容性进行控制。细节见“应用状态数据格式改变”。

这一信息识别与状态项目对应的应用。它通常由应用的作者分配。

3.4.2.2应用状态版本跟踪

考虑在设备A上保存应用状态数据项目并且向设备B传送应用状态数据项目的情况。现在有应用状态数据的两个副本，可以修改任一副本。如果随后在这些设备之间再次传送相同项目，则有多个不同情况：

●在传送之前尚未在任一设备上修改数据。

●在设备A上修改了数据、然后再次向设备B传送该数据。在这一情况下，来自设备A的引入版本比设备B上的现有版本更新。

●在设备B上修改了数据，但是然后从设备A向设备B再次传送该数据。在这一情况下，来自设备A的引入版本比设备B上的现有版本更旧。

●在两个设备上修改数据，然后在任一方向上传送数据。在这一情况下有冲突——任一版本在严格意义上不比另一版本更新，但是文件时间戳的单纯检查将暗示有严格排序。

在图1-4中图示了这四种情形。

用户一般难以保持跟踪，所保存文件的哪些版本比其它版本更新，因此系统通过保持跟踪应用状态数据文件的改变从而检测这些情形并且通知用户来辅助用户是有帮助的。

显然，这一情形使得用户甚至更难于保持跟踪何时涉及到两个以上设备，但是仍然可以检测并且向用户报告上文描述的基本情况。

在本文所描述的系统中，通过存储版本记录元数据单位的有序序列来解决这一情形，其中每个单位代表应用状态项目的生命周期中的分岔或者汇合点。

版本记录包括序列号（始于0并且以1为单位增加）、应用状态项目的内容的散列（hash）和添加有版本记录的设备的唯一标识符（这是在在先公开中提到的相同的唯一标识符）。

在初始创建应用状态项目时添加初始版本记录。根据以下过程添加后续版本记录：

1.散列化应用状态项目的内容（使用比如SHA-1的方法）。

2.比较散列与先前版本记录（具有最高序列号的版本记录）中的散列。

3.如果散列不同，则添加具有下一序列号、当前散列和当前设备唯一标识符的新版本记录。

4.如果散列相同，则不添加新版本记录。

添加版本记录的过程在以下方面来执行。

●分岔：紧接在即将播送应用状态项目之前（或者在某一用户选择的时间、即使在不存在播送时）。

●汇合：在接收应用状态项目时，如果在设备上存在有与引入项目具有相同的随机ID的应用状态项目，则对现有项目执行这一过程。

通过遵循这些步骤，在不同设备上构建修改历史。现在可以通过分析这些版本记录来区别上文描述的各种情形。

●传送之前尚未在任一设备上修改数据：版本记录相同。

●在设备A上修改了数据，然后再次向设备B传送数据。在这一情况下，来自设备A的引入版本比设备B上的现有版本更新。直至在设备B上的版本中完成版本记录的时刻版本记录是相同的。在该时刻之后来自设备A的引入版本具有一些附加记录。

●在设备B上修改数据，但是然后再次从设备A向设备B传送数据。在这一情况下，来自设备A的引入版本比设备B上的现有版本更旧。直至在来自设备A的引入版本中完成版本记录的时刻，版本记录是相同的。设备B上的现有设备在这时刻之后具有一些附加记录。

●在两个设备上修改数据，然后在任一方向上传送数据。在这一情况下有冲突——任一版本在严格意义上不比另一版本更新，但是文件时间戳的单纯检查将暗示有严格排序。版本记录直至某一时刻是相同的，并且该两个版本在这一时刻之后具有附加记录。

3.4.2.3应用状态数据打包

在在先公开中，针对ATX文件描述了两个模式：已签名“ATX组件”，其包含代码、数据或者元数据；和未签名“容器ATX文件”，其仅包含其它ATX文件，这些其它ATX文件本身通常是ATX组件。

本文描述了新的ATX文件类型——未签名文件，其包含应用状态项目，加上包含与该项目关联的元数据（随机标识符、类型、版本信息等）的清单。使用用于上述元数据项目的以下属性名称，按照标准JAR清单格式，将上述元数据编码为密钥/值对。

●AGC-State-AppName（AGC-状态-应用名称）：注册应用状态项目的应用的名称；

●AGC-State-AppDependency（AGC-状态-应用依赖性）：来自游戏清单的AGC-State-AppDependency头；

●AGC-State-ItemName（AGC-状态-项目名称）：应用状态项目的用户可见名称；

●AGC-State-ItemID（AGC-状态-项目ID）：应用状态项目的随机ID；

●AGC-State-ItemType（AGC-状态-项目类型）：应用状态项目的类型；

●AGC-State-ItemUpdate-n（AGC-状态-项目更新-n）：用于应用状态项目的版本记录序列。

由于未对这一文件加密签名，所以它的内容不能依赖于未进行修改。一种使攻击者修改这一数据略微更复杂的简单（但是不安全）方式是向应用状态数据文件追加循环冗余校验或者相似代码，然后使用基于清单的某一散列的密钥，利用流密码对所得数据文件进行编码。然而应当强调，这不会阻止危险的攻击者，仅对偶然尝试修改数据进行防御。

使用这一方式，对清单或者数据文件的修改通常将造成在对数据解码时CRC数据无效，从而允许在大多数情况下检测到修改。

3.5播送包

使用与目标设备的协商，可以确定运行应用所需的、但是不存在于目标设备上的应用、依赖性和权限组件集。然后用户选择要播送的零个或者更多个应用状态项目。在一个替代实施例中，可以自动选择要播送的应用状态而无需用户干预。例如，在一些应用中自动播送最新近应用状态可能是方便的。

作为协商过程的部分，在一个实施例中，接收设备可以向播送设备报告它可以接受的或者接收设备的用户希望接受的应用状态（例如通过用户选项）。这避免播送设备发送在接收设备处不使用或者不能使用的数据。

生成用于这些应用状态项目的ATX文件，并且与需要传送的所有应用、依赖性和权限组件的ATX安装包一起被存储在容器ATX文件中。

通过任何可用的传送机制向目标设备传送所得到的容器ATX文件。这可以包括通过蓝牙的OBEX、作为电子邮件消息的附件、通过Wi-Fi网络或者移动电话网络的自定义协议等。

3.6接收和安装播送包

在目标设备接收容器ATX文件时，检查其内部ATX文件并且作为结果采取多个动作：

1.在经用户确认后安装权限组件；

2.在经用户确认后安装应用和依赖性组件；

3.对容器ATX中存在的任何应用状态项目进行处理。

在在先公开中描述了步骤2中的二进制可移植软件组件的安装和步骤1中的权限组件的处置。

对应用状态项目进行如下处理：

●如果如在上文“应用状态数据打包”中描述的那样对应用状态数据文件进行编码，则通过散列化清单以产生解密密钥、解密数据文件然后检查和去除CRC来对数据进行编码。如果CRC与发送的值不匹配，则将应用状态项目视为被破坏并且丢弃。

●使用在在先公开中指定的依赖性机制来评价来自应用状态项目的清单的AGC-State-AppDependency属性，以便发现如下应用：该应用能够处置正在被处理的应用状态项目。如果未发现应用，则丢弃应用状态项目。

●使用来自应用状态项目的清单的AGC-State-ItemID属性，系统确定是否存在具有与设备上存在的随机标识符相同随机标识符的应用状态项目。如果是这样，则它比较两个项目中的版本记录信息，并且向用户呈现要采取的可能的动作选项：

○引入的应用状态与现有应用状态不对应：向用户询问他们是否想要安装应用状态项目，而默认回答为“是”。

○引入的应用状态对应于现有应用状态、但是为新的：在注释表明引入的应用状态为新的情形下，向用户询问他们是否想要用引入的应用状态重写他们的现有应用状态。默认回答为“是”。

○引入的应用状态对应于现有应用状态、但是为旧的：在注释表明引入的应用状态为旧的情形下，向用户询问他们是否想要用引入的应用状态重写他们的现有应用状态。默认回答为“否”。

○引入的应用状态对应于现有应用状态、但是有冲突：向用户提供用引入的应用状态重写他们的现有应用状态的选择，其中默认回答为“否”。如果应用的清单指示它可以合并这一类型的应用状态，则也向用户提供“合并”选项，该选项触发应用的合并功能。

如果用户没有拒绝引入的应用状态项目，则在对应用可见的目录中存储对应数据文件，其唯一目的是包含引入的应用状态数据文件。此外，以实质上类似于应用已经以正常方式注册项目的方式，将应用状态项目的元数据插入到应用状态项目的目标系统记录中。如果用户选择合并冲突，则这与用于项目的元数据一起被记录。

3.7应用支持

可能需要对希望利用应用状态播送设施的应用进行许多小改变。基于本公开内容这些改变对本领域技术人员而言是显然的。

3.7.1注册和取消注册应用状态项目

如上文描述的那样，应用可能需要调用API函数以将保存的数据文件“注册”为可用于播送。

应用也可以取消注册数据文件，从而去除文件的任何存储的元数据并且将其标记为不再可用于播送。

3.7.2应用状态数据格式改变

有时，应用可能需要改变它们的保存的数据文件的格式。这会在添加或者去除特征时或者仅为了提高效率等而发生。

在这种情形发生时，旧版本的应用通常不能使用新版本创建的数据文件，而新版本的应用可能能够或者可能不能使用由旧版本的应用所保存的数据文件。

软件应用的作者可以使用AGC-State-AppDependency和AGC-InterfaceComponent-n（AGC-接口组件-n）属性在应用清单中表示关于支持哪些版本的应用数据格式的信息。

将AGC-State-AppDependency属性编码成由应用创建的任何应用状态项目的元数据以及编码成向其它设备播送的任何应用状态项目的清单。

这表示对特定接口名称和版本范围的依赖性。应用实施这一接口。通过改变这两个清单属性中的接口版本号，可以有选择地允许或者不允许旧应用状态项目，并且将新应用状态数据文件标记为与更旧版本的应用不兼容。

例如：

●应用支持一个数据格式，但是如果数据格式曾经改变过，则作者希望提供与更旧格式的向后兼容。

AGG-InterfaceComponent-0：http：//someinterface.mycompanycom/if/game- state/somegame1.0

AGC-State-AppDependency：http://someinterface.mycompanycom/if/game-state/someqame1.0-1.*

在这一示例中，应用陈述它支持接口的1.0版本。放入应用状态元数据中的AGC-State-AppDependency条目指示它需要这一接口的至少1.0版本，但是它期望支持不同数据格式从而能够对它进行解码的未来版本。

●上文描述的应用具有对它的数据格式的改变：

AGC-InterfaceComponent-0:http://someinterface.mycompanycom/if/game state/somegame1.1

AGC-state-AppDependency:http://someinterface.mycompanycom/if/game-state/somegame1.1-1.*

这是前例的扩展，其中用于应用状态的数据格式已经改变。应用现在陈述它支持接口的1.1版本。

注意，这仍然与在由更早版本（1.0-1.*）的应用所创建的应用状态项目中存在的版本范围匹配。因此应用陈述它仍然支持由实现该接口的1.0版本的更早版本应用所创建的应用状态项目。

向由该应用保存的新应用状态项目分配新版本范围“1.1-1.*”。这不会与先前版本的应用（其实现该接口的1.0版本）匹配，其是正确的动作。

●应用改变它的数据格式并且丢弃针对旧格式的支持：

AGC-InterfaceComponent-0:http://someinterface.mycompanycom/if/game- state/somegame2.0

AGC-State-AppDependency:http://someinterface.mycompanycom/if/game-state/somegame2.0-2.*

这可以被视为前一示例的扩展，在前一示例中应用作者决定丢弃针对所有先前应用状态数据格式版本的支持，或者它可以用于作者从未想过为更旧数据格式提供向后兼容性的情形中。无论意图如何，机制相同。

来自更旧版本的应用的应用状态元数据需要在范围“1.*”中的版本号，因此不会与应用的这一新版本匹配。因此应用声明了它与那些版本不兼容。

通过修改主要版本号，应用作者可以对每当数据格式改变时他们是否想要保持向后兼容性进行控制。

3.7.3当接收到应用状态项目时采取的动作

在应用启动时（或者在一些其它定义好的时机、比如紧接在显示用户进行选择的被保存文件列表之前），预期调用API函数来枚举在存储有引入的应用状态项目数据文件的上述目录内的应用状态项目。

对于枚举中的每个项目，向应用提供引入的应用状态数据文件的名称、对应的现有应用状态数据文件（如果有）的名称、关于哪个更新和是否有冲突的信息以及用户是否想要安装引入版本或者尝试合并。

应用需要确认引入的应用状态数据文件的内容（以检查有意修改、破坏等）。应用状态数据文件是用于游戏系统的共同攻击矢量，因此重要的是，应用鲁棒地检查引入的应用状态数据文件的有效性以防范缓冲器溢出等。

一旦应用已确认引入文件，则它应当采取以下动作之一：

●调用API函数以接受引入文件，在数据文件应当移向的别处（未在“引入”目录内）提供文件名。如果存在具有相同AGC-State-ItemID的现有应用状态数据文件，则它将被引入文件（包括其元数据）替换。引入数据将被保存到的文件名可以与正在替换的现有应用状态数据文件的文件名相同，或者它可以不同，在该情况下将去除现有数据文件。

●调用API函数以去除引入文件及其对应的元数据。由于截至这一刻用户已经对他们是否想要接受引入文件这样的问题回答了“是”，所以可能适当的仅有情形是：如果引入的应用状态文件无效或者如果应用已经执行某一合并并且更新了现有应用状态数据文件，则不再需要引入的文件。

通过遵循这些规则，引入目录应当仅包含在设备上新近接收并且需要应用关注的文件，而应用保持对它的数据目录内的应用状态文件的命名约定和目录结构的控制。

应用如果在这一点进行选择则可以提供简单的合并功能。

例如，使用应用状态播送机制以传送从一个玩家到另一玩家的轮次的国际象棋游戏可以对代表进行中的被保存游戏的引入状态项目执行检查，以保证在对手玩家已经进行一个额外移动的情形下，所接收的游戏与它的游戏状态记录相匹配（即所有先前的移动相同）。有效地合并引入应用状态与现有状态。

如果应用状态数据格式内部包含各个改变的记录，则更复杂的合并是可能的，从而使应用能够检测文件内的各个修改，并且或许在有用户确认的情况下决定应当保持来自每个文件的哪些项目。

4.使用情形

这一节描述由本文中描述的系统所支持的一些使用情况。

4.1将应用与所有其依赖性和状态一起传送

在没有从源设备到目标设备的直接通信的情形中，两个设备不能协商为了使应用工作而需要传送的应用和依赖性组件集。

在这一情形中，有必要传送整个组件集。用户可以可选地选择将与应用一起传送的某一应用状态。

源和目标可能不能直接通信的原因有许多，包括连通原因并且也包括在创建播送包时不知道目标设备的情形——例如，如果源设备创建播送包并且使它可用于在公共可访问的网站服务器上下载。

在图5中图示了传送过程。

4.2传送应用及其依赖性的子集

更有用的情况是源和目标设备能够通信。在这一情况下，它们能够确定需要传送的确切组件子集。

同样，用户可以选择将在播送包中包括的某一应用状态。

在图6中图示了这一点。

4.3仅传送应用状态

在源与目标设备之间协商的最终示例是它们确定目标设备具有为了运行应用而需要的所有组件。在这一情况下，仅需传送应用状态项目（如果用户选择了任何应用状态项目）。

在图7中图示了这一点。

4.4在无电话网络覆盖时通过短程网络传送

这一系统的关键优点是数据的“离线”传送——通常通过短程无线技术，比如蓝牙或者Wi-Fi（包括其中无需现有Wi-Fi网络的点对点Wi-Fi）。在适合时也可以使用有线连接，比如USB或者以太网。

在图8中图示了这一点。

1.一种分发二进制可移植软件的方法，包括：

（a）在第一用户设备上运行软件应用，并且存储定义所述软件应用的状态的应用状态数据；

（b）从第二用户设备接收为了运行所述软件应用而需要的并且尚未安装的所需软件组件的细节或者需要更新的所需软件组件的细节；

（c）生成用于向所述第二用户设备传送的、包括所述应用状态数据和所述所需软件组件的包；

（d）向所述第二用户设备传送所述包；

（e）确定是否已经在所述第二用户设备处保存所述状态；并且

（f）向所述第二用户设备的用户提供用于从所述状态运行所述软件应用的选项。

2.一种方法，其中所述所需软件组件包括尚未在所述第二用户设备上安装的以下各项中的任一项：二进制可移植软件组件、权限组件和任何必需软件库或者依赖性。

3.一种方法，其中所述包包括二进制可移植软件组件，所述方法向所述第二用户设备的用户提供用于从所述状态运行先前未安装的软件应用的选项。

4.一种方法，包括向所述第一用户设备的用户提供要传送的期望状态的选项。

5.一种方法，包括从所述第二用户设备接收已经在所述第二用户设备上存储的一个或多个状态的细节，并且从所述包排除已经存储的所述一个或多个状态。

6.一种方法，其中所述包在未修改的情形下从所述第一用户设备传送至所述第二用户设备。

7.一种方法，包括如果所传送的状态比已经在所述第二用户设备上存储的状态更旧或者与其冲突，则警告所述第二用户设备的用户。

8.一种方法，其中所述应用状态数据定义多个状态记录，在最新近存储的状态的散列不同于将保存的当前状态的散列时，向所述应用状态数据添加新状态记录。

9.一种方法，其中在所述第二用户设备处接收所述包时，将所述传送的状态的散列与在所述第二用户设备处存储的状态的散列相比较，并且如果不同，则在所述第二用户设备处存储所传送的状态。

10.一种方法，其中所述状态由随机生成的标识符标识，并且将所述状态与具有与已经存储在所述第二用户设备处的标识符相同的标识符的一个或者多个状态相比较。

11.一种方法，其中所述包包括数据格式指示符，所述指示符由所述第二用户设备读取以确定所传送的数据格式是否与在所述第二用户设备上使用的数据格式兼容。

12.一种方法，其中所述第二用户设备将所传送的状态与已经在所述第二用户设备上存储的状态向合并，并且基于所合并的状态运行所述应用软件。

13.一种方法，其中所述第一用户设备和所述第二用户设备是移动电话。

14.一种方法，其中所述软件应用是游戏。

15.一种计算机可读介质，其存储用于在数字计算机上实施的程序代码。

附录结束

Claims (14)

1.一种用于跨过在启动用户设备与远离所述启动用户设备的接收用户设备之间的网络来分发用于执行的软件应用的方法，所述方法包括：

（a）在所述启动用户设备处存储用于实施所述软件应用的软件包，所述软件包包括用于在所述启动用户设备上执行的第一程序和用于在所述接收用户设备上执行的第二程序；

（b）从所述启动用户设备跨过所述网络来广播对来自兼容用户设备的响应的请求，所述兼容用户设备能够参与所述软件应用的执行；

（c）当接收到来自兼容的接收用户设备的响应时，将所述第二程序从所述启动用户设备跨过所述网络传送至所述接收用户设备，并且在所述接收用户设备上安装所述第二程序；以及

（d）通过在所述启动用户设备上运行所述第一程序以及在所述接收用户设备上运行所述第二程序来执行所述软件应用。

2.根据权利要求1所述的方法，其中，所述第一程序是主程序，并且所述第二程序是用于从所述接收用户设备控制所述启动用户设备的远程控制程序。

3.根据权利要求1所述的方法，其中，所述第二程序是主程序，并且所述第一程序是用于从所述启动用户设备控制所述接收用户设备的远程控制程序。

4.根据权利要求2或3所述的方法，其中，所述启动用户设备的用户选择是使用所述启动用户设备控制所述接收用户设备，还是使用所述接收用户设备控制所述启动用户设备；并且所述第二程序相应地从所述软件包内的可用程序中进行选择。

5.根据权利要求1所述的方法，其中，当在所述启动用户设备和所述接收用户设备上执行所述第一程序和所述第二程序时，所述第一程序和所述第二程序表示单一共用程序的分离的实例。

6.根据权利要求1所述的方法，其中，所述第一程序和所述第二程序两者是对等程序。

7.根据权利要求1所述的方法，包括：接收来自已经正在参与所述软件应用的现有会话的执行的接收用户设备的响应，以及为所述启动用户设备的用户提供加入所述现有会话的选项。

8.根据权利要求1所述的方法，其中，所述第一程序和所述第二程序至少部分地通过应用指定协议来直接通信。

9.根据权利要求1所述的方法，其中，所述第一程序和所述第二程序至少部分地通过一般协议来通信。

10.根据权利要求1所述的方法，其中，来自所述兼容的接收用户设备的响应通过第一网络来进行，并且所述第二程序至所述接收用户设备的传送通过第二网络来进行。

11.根据权利要求10所述的方法，其中，在执行所述软件应用时所述启动用户设备与所述接收用户设备之间通过所述第二网络来进行通信。

12.根据权利要求1所述的方法，其中，所述软件包、所述第一程序和所述第二程序以二进制可移植代码来实施。

13.根据权利要求1所述的方法，包括从所述启动用户设备向所述接收用户设备传送：

●所述软件包，或

●所述软件包中在所述接收用户设备上缺少的并且为了汇编所述软件包所必需的部分；以及

使用所述接收用户设备作为新的启动用户设备以进一步扩展所述软件应用的分发。

14.一种计算机可读介质，其存储用于在数字计算机上实施根据权利要求1所述的方法的程序代码。

Images