权限受管理可分发软件的制作方法

专利名称：权限受管理可分发软件的制作方法
技术领域：
本发明涉及一种分发权限受管理的软件的方法，并且涉及一种承载这样的软件的计算机可读介质。本发明特别但非排他性地涉及一种诸如如下的计算机游戏的软件，该计算机游戏在是权限管理型的同时被设计成在诸如移动电话的便携式设备的用户之间交换。2 引言本文档描述一种用于以如下方式分发二进制可移植计算机软件应用及其相应的数字许可的系统，该方式使得在接收设备上不存在许可时能 够以受限方式使用软件应用，并且在存在许可时能够完全地使用软件应用。如果不存在许可，则对应用的功能性的限制的方式由软件应用的出版者或者制作人、通常结合发行人来确定。限制可以采用时间限制或者使用限制的形式，以禁止应用的某些特征，或者限制可以采用很多其他形式。数字许可(“权限部件”)采用加密签名数据段的形式，该数据段描述许可有效所必要的条件。这些条件可以包括将许可锁定至使用唯一设备标识符的特定设备(或若干设备)、对可以使用软件的日期范围施加限制、对应用可以使用的次数进行限制、以及很多其他可能的条件。权限部件的有效性由其中运行应用的软件架构来评估。这允许对于软件应用的许多用例(use case),这些用例在使用加密的数字权限管理系统中通常是不可用的，其中，除非能够获得有效的许可(该许可通常包括解密密钥)，否则通常不可能存取内容。—个示例是“在购买之前试用”情节(scenario)，其中，用户直接从出版者或者认可的第三方接收软件应用，并且用户可以在选择是否购买软件的许可之前以受限方式使用应用。“病毒式分发”是另外的情节，其中，终端用户可以向其他终端用户分发应用软件，以使得接受者能够以受限方式访问应用，即使发送者可能已经具有应用的完全的许可。本发明不仅涉及一种用于分发权限受管理的软件的方法和系统，而且涉及一种实现这样的方法的软件，该软件存储在诸如磁盘、ROM或RAM的计算机可读介质中。本发明还涉及一种诸如移动电话的移动设备，该移动设备包含被布置成执行这样的方法的系统。本发明依赖于如下的组合权限管理系统、使用权限信息的加密签名以确保真实性、以及使用二进制可移植软件递送格式以使得内容和权限能够在很多不同类型的设备之间共享。此外，由于系统不依赖于可执行软件的递送格式的加密，因此，软件在被超分发(super-distributed)之后是直接可用的，而不需要联系权限发行者，但同时仍保持对软件使用的控制。本发明可以用各种方式来实现，现在将参照附图、通过示例来描述若干具体实施例，附图如下图I-分发文件格式ATX文件的类型；图2-DRM系统的操作一个权限部件对多个应用授权；图3-DRM系统的操作多个权限部件实现相同的接口 ；
图4-由软件环境处理权限；图5-由应用检查权限，示例I :受限等级试用模式；图6-由应用检查权限，示例2 :受限时间试用模式；图7-由应用检查权限，示例3 :受限功能性试用模式；图8-权限获取来自应用内部的自动浏览器重定向；图9-权限获取应用中的交易处理；

图10-权限发行者伪权限部件“在购买之前试用”；图11-权限发行者受限使用“在购买之前试用”；图12-权限发行者订阅(subscription)权限；图13-权限发行者设备锁定权限；图14-权限发行者制造商锁定；图15-权限发行者单个权限部件内的不同权限；以及图16-不同设备类型之间的病毒式分发。3.说明书
3.背景技术：
已经很好地提供了数字权限管理和密码学领域的文件，对此这里将不详细描述。可以在以下公开中找到背景信息，所有这些公开通过引用被合并 RSA 加密算法RSA public-key cryptography algotithim :美国专利
4,405, 829, Rivest, Shamir 和 Aldeman,申请日期 1977/12/14 ； SHA-I 安全散列标准Secure Hash Standard SHA-I, FIPS PUB 180-1，NIST，1995 ； PKCS#7 加密消息格式PKCS#7 Cryptographic Message Syntax, RFC2315 ；.1.509 指南，认证架构CCITT Recommendation X. 509 Thedirectory-Authentication Framework,1988 ；*ASN. I 数据格式CCITT推荐X. 208 !Specification of Abstract SyntaxNotationOne, 1988 以及CCITT推荐X. 209 !Specification of BasicEncoding Rules for AbstractSyntax Notation One,1988 ； ZIP 档案文件格式Zip File Format, PKffARE 公司； JAR 档案文件格式JAR File Format, Sun Microsystems, 2004 ;以及 BASE64 编码格式BaseM Data Encoding Format, RFC 4648。3.2分发文件格式在本实施例中，软件内容、资源和元数据以“ATX”文件格式分发，“ATX”文件格式是以上列出的JAR文件格式的扩展。当然，可以使用其他格式。具体地，ATX文件格式使用与Java的“ jarsigner”工具所使用的加密签名机制完全相同的加密签名机制，同时具有必须使用RSA和SHA-I算法的限制。ATX文件可以具有两种模式 ATX文件可以包含应用内容或元数据。这些ATX文件被加密签名以确保内容的真实性。像这样的ATX文件已知为“部件”。
· ATX文件可以包含其他ATX文件。这些ATX文件没有被加密签名，虽然内部ATX文件被签名。这用于将若干相关的ATX文件作为单个单元分发，而不修改其中的任何ATX文件。例如，通常以这种方式分发应用及其相应的权限部件。第一类型的ATX文件(部件)可以包含可执行代码、应用使用的数据文件(诸如图像、音频文件等)以及元数据。虽然没有由软件环境施加的将这些文件的分成不同类型的正式的划分，但是，有许多使用这些文件的通用方式，这导致这些文件的到如下多种类型的非正式的分类 应用部件。这些应用部件是其主要目的是包含软件应用的部件。这些应用部件还可以包含应用使用的数据。这些部件具有一个或更多个“可运行项能够由终端用户运行的应用程序。 库部件。这些库部件是包含如下可执行代码共享库的部件，这些可执行代码共享库对于应用是可用的，但是其自身不构成可用的软件应用。这些部件不包含可运行项目。 资源部件。这些资源部件是包含软件应用使用的数据文件的部件。资源部件本身通常不是可用的。资源部件的使用的示例是包含定义游戏应用的“等级”的数据文件的部件。这种类型的用途使得游戏具有可以与游戏本身分开安装的另外的等级。资源部件可以由多于一个软件应用来使用。 权限部件。这些权限部件是仅包含清单文件中的条目形式的元数据的部件，用于确定对于其他部件有效的权限是否可用。ATX文件的一些示例参见图I。3. 3部件清单头如已经描述的，部件ATX文件具有包含密钥/值对的清单，这一点在JAR文件规范中进行了定义。除了那里所定义的标准密钥名称之外，部件还具有多个附加头，这些附加头指定诸如以下的项目· AGC部件部件名称和版本号。部件的名称是由创建者分配的URI。URI是唯一的，从而可以用于明确地指代特定的部件。版本号简单地是64比特的数字(通常表示为该数字的两个32比特部分的十进制形式，由符号”分隔)。没有关于如何分配该数字的具体要求，但是，通常的做法是使用表示创建部件的日期的8位数表示用于前32比特的值(例如，用于2008年I月2日的20080102)，使用表示创建ATX文件的时间的6位数表示用于后32比特的值(例如，用于下午2点30分的143000)。这可以在构造部件时由构造工具容易地自动生成。除了为确定部件的特定版本比另外的版本更新还是更旧之外，部件版本号不具有任何语义含义。URI和具体版本号的组合唯一地标识确切的ATX文件。· AGC名称部件的人可读的名称(可选)· AGC出售者部件的出售者的名称(可选)· AGC描述LANG :用不同语言的部件的零个或更多个人可读的描述。字符名称中的串“LANG”用表示语言的2个字母国家代码(如ISO 3166-1中所定义的)代替。· AGC接口部件N:部件实现的零个或更多个接口名称和版本号。该上下文中的接口是部件完成或者包含(或者二者)的内容的规范。其形成实现该接口的部件与使用该接口的部件之间的约定。清单头名称中的N应当用从零开始的数字索引来代替。接口名称是与部件名称URI类似的唯一的URI。接口版本号也是如同部件版本号的64比特的数字。然而，与部件版本号不同，除了简单地表示部件比另外的部件更新或更旧之外，接口版本号还具有语义含义-它们指定不同版本的接口之间的兼容性。这在题为“部件接口版本编号”的部分中进行了更加详细的描述。部件可以实现多于一个接口(只要接口定义不冲突即可)。· AGC依赖性N :在部件要求存在某些其他部件的情况下，其可以在其清单中表达出对于这些部件的依赖性。这是使用URI和指定哪些版本是可接受的版本的版本范围来完成的。依赖性可以对部件名称或者对接口名称。清单头名称中的N应当用从零开始的数字索引来代替。更多的细节参见标题为“部件依赖性”的部分。· AGC规则N :指定单个布尔(Boolean)限制的单独的规则。清单头名称中的“N”用在清单内唯一的标识符来代替。该标识符用于指代一个或更多个AGC规则集头中的规则。AGC规则集M :指定如何组合规则并且评估规则以给出整个布尔结果值的表达。该表达包括对形成一般表达语言的运算符和布尔运算符分组，在一般表达语言中，用规则的唯一标识符来指代它们。清单头名称中的“M”用为规则集的名称的标识符来代替。更多的细节参见标题为“权限规则集”的部分。-AGC发行人URL :可以用于获得另外的权限的URL。这通常仅存在于权限部件中。· AGC项目N :对于包含能够凭本身运行的可执行程序(即不是可执行的共享库)的部件，包括这些清单头中的一个或更多个清单头，以指定应当运行哪个可执行程序、应当向其传递哪些命令行参数、以及应当向用户显示什么图标。可以呈现这些头中的若干头，并且，这些头中的若干头可以指代部件中的不同可执行程序或者指代具有不同命令行自变量的相同可执行程序以控制其行为。3.4部件接口版本编号部件接口是对部件提供的内容的定义。该定义可以是文件的形式，包含(例如，用于游戏的资源部件可以包括具有特定名称的数据文件)其清单中的元数据(参见标题为“部件依赖性”的部分)、或具有特定API的共享库。接口版本号指定接口的不同版本之间的兼容性。例如，用特定API表示共享库的接口可以为了若干理由而改变，诸如I.已经向API添加了新的功能2.已经以向后兼容的方式改变了 API中的现有功能3.已经以不可兼容的方式改变了 API中的现有功能4.已经改变了部件内的共享库文件的名称根据本示例，应当明显的是，某些类型的改变是向后兼容的(以上列表中的I和2)，表示被编写以使用旧版本接口的软件应用将在实际提供以向后兼容的方式改变的版本的实现的情况下继续工作。
其他(诸如以上列表中的3和4)是不兼容的改变，以使得期望接口的旧版本的软件应用在这样的改变之后不再工作。接口版本号指示接口的不同版本的兼容情况。对值的最低有效的32比特的改变表示向后兼容的改变，而对值的最高有效的32比特的改变表示不兼容的改变。虽然以上示例描述了对于具有共享库的接口的兼容和不兼容类型的改变，然而，对于指定数据文件或元数据以特定格式存在的接口，存在等效情节，其中，由接口定义所定义的内容发生改变。
依赖特定接口的部件应当表示能够接受的版本号的范围，以使得实现的有效实现的存在可以通过运行时间软件环境来确保。更多细节参见标题为“部件依赖性”的部分。3.5部件依赖性当部件依赖于其他部件中的功能性或数据时，该部件可以使用依赖性来确保其他部件存在。通常，情况如下，部件需要存在特定的一组功能性，而非该功能性的确切实现。如果是这样的情况，则依赖性应当是对部件接口而非对部件名称。通过使用部件接口，所提及的部件可以准确地指定其需要接口的什么版本。例如，对于包含需要包含共享库的另一个部件的可执行程序的部件，通常已经编写所提及的部件，以使用该库的API的特定版本。特别地，这需要存在在该API版本中定义的特征。然而，如果存在该接口的更新的版本，则只要较新的版本向后兼容应用所要求的版本，就可以认为满足依赖性。如果存在不是向后兼容的接口的较新版本，或者如果存在不包含所有特征要求的接口的更早的版本，则不能认为满足依赖性。对于资源部件和元数据部件，存在类似的情节，虽然库部件最倾向于这种类型的API改变。部件可以准确地指定它们允许接口的哪些版本。部件依赖性指定URI，该URI是部件名称或部件接口的URI。另外，指定版本范围(开始及结束版本号，使用通配符来指定)。如果URI是部件名称，则对于版本编号系统的含义没有正式定义，因此，指定范围的唯一明智的方法是用准确版本号的行为的知识。这通常只有在库部件的生产者与应用部件的生产者之间存在紧密合作的情况下才是可能的.然而，如果URI是部件接口名称，则参考者可以将范围的开始版本号指定为其中所要求的功能性全部都是可用的接口定义的最早版本。结束版本号通常定义具有与开始版本号相同的最高有效的32比特(表示与开始版本号不向后兼容的接口版本是不允许的)，而最低有效的32比特通常用通配符来定义(使用字符“ * ”而非十进制数)，这表示开始版本号的最低有效的32比特之后的任何版本号都是可接受的。这使得对接口具有依赖性的部件能够使用任何如下部件，该部件实现该接口的所要求的版本号或者与其向后兼容的任何未来的版本。这允许用于库和资源部件的简单的更新路径，而不需要与应用版本的同步。3. 6权限规则集在ATX文件格式规范中定义的清单头中的若干清单头涉及DRM系统:AGC规则N (定义命名的规则)和AGC规则集M (定义命名的表达)。规则集是命名的表达，该命名的表达使用分组运算符和布尔运算符来将单个规则组合成总的表达。清单可以具有测试不同限制的很多规则以及以各种方式组合这些规则以形成特定结果的若干规则集。规则可以测试宽范围的不同的限制，诸如·匹配设备的MEI、MSI、ESN或者其他唯一标识符，得到仅评估以“配准(TRUE) ”某些特定设备的规则。·匹配设备制造商的名称·匹配网络操作者的名称·匹配设备类型 检查日期是否在特定的范围内·检查日期是否没有超过部件安装之后指定量的时间·检查部件是否还未使用超过指定次数·检查部件是否还未使用超过指定量的时间·评估不同部件中的另外的规则集通过使用布尔运算符和分组运算符将这些规则组合成规则集，可以获得用于描述限制的非常灵活的系统。对于DRM目的，在部件中命名为“部件_权限”的规则集指定被评估的表达以确定对于该部件的权限是否有效。然而，虽然检查权限对于特定部件是否有效的软件环境使用来自该部件的“部件_权限”规则集，但是，规则集使用评估不同部件中的规则集的规则的能力意味着该部件实际上可以将权限限制中的一些或全部权限限制的描述委托给专门为此而生产的单独的部件-“权限部件”。这意味着不需要改变部件的清单来发行或改变权限。因此，权限部件可以包含特定于购买这些权限的用户的规则(诸如匹配特定设备ID)，可以在权限过期时重新发放权
限，等等。3. 7部件的安全性本系统中的部件(包括权限部件)的安全性通过验证权限部件的加密签名以及验证从签名证书到根证书的证书链来确保。这证实部件未被修改，这是因为其被签名。该系统的安全性主要依赖于执行攻击者不能够修改的签名有效性的软件程序和根证书。这完全依赖于基础的操作系统的安全模型，因此这在本文档的范围之外。在安全的基础的操作系统上，可以对于不能容易地绕开权限系统具有高度的信任。在安全性较差的系统上，可能存在攻击向量，该攻击向量可以代表攻击者用适度的努力获得成功，然而这是基础的操作系统的属性，并且其他DMR系统在这样的系统上通常具有类似的缺点。3.8 二进制可移植软件分发格式本发明的关键部分是被分发的应用软件是二进制可移植的事实。这意味着其不特定于特定的操作系统或者CPU类型。
这在优选实施例中是通过将最终的特定于机器的部分的源代码编译(这主要包括指令选择和寄存器分配)推迟直到应用软件被递送给要运行应用软件的设备为止来实现的。很多编译器在进行最终的代码生成之前以独立于机器的格式保持他们的内部状态，从而，在该点处划分编译处理是简单的步骤。这使得相同的应用包能够被递送给具有不同CPU和操作系统的设备，并且，如果该应用如通常那样已在一个操作中被编译用于该平台，则一旦被转换到本地，该应用就以与其类似的性能水平运行。通过将特定于机器的编译部分推迟直到应用被安装在其将要执行的目标设备上为止，可以利用特定的CPU的特征(硬件浮点、最优指令选择等)的优点，这在对横跨诸如ARM家族或者x86家族的类似的处理器的范围上需要是二进制可移植的程序进行编译时是不可能的。这使得能够生成对特定CPU变体修改的本地代码，以利用协同处理器、至指令集
的延伸或者指令执行的差异。与用最小公分母CPU家族二进制获得的性能相比，这可以得到明显更高的性能。分发中间代码并之后执行至本地代码的最终转换的概念是已知的，并且已经是很多学术论文和专利的主题(例如，Chan等人的美国专利5280613 :ANDF installer usingthe HPcode-Plus compiler intermediatelanguage、Koizumi 等人的美国专利 5586323 Complier system using anintermediate abstract form and machine-specificinstallers),并且也已经用在许多产品中。如上所述，这是该处理与DRM权限的使用的组合，这使得可以进行这里所描述的新使用情节。4. DRM系统的操作应用部件、库部件和资源部件可以具有在其清单中命名为“部件_权限”的规则集，该规则集指定要被评估的表达以确定权限有效性。通常，情况如下，不期望这些部件包含整个权限限制集，因为这将意味着为了将部件锁定至特定设备，必须修改其清单以包含具有相关设备的唯一标识符的规则，然后对部件重新签名。这具有若干缺点·当改变权限时，整个部件需要被再次下载。 可能有基于应用的签名者而授权于该应用的安全许可。这在例如J2ME系统中是普遍的。保持这些许可将要求权限发行者能够使用原始证书(这通常属于应用的出版者)重新签名，这几乎是不能接受的。 更普遍的是，要求权限的部件使用评估单独的部件、S卩“权限部件”中的另外的规则集的规则。4. I权限部件使用接口(由要求权限的部件的出版者定义)应用权限部件。规则集名称也由部件出版者来选择，这通常包括出售者名称和应用名称，以减少潜在的命名空间冲突。这样，权限发行者可以简单地生成实现该接口的权限部件(通常，具有在权限发行者拥有的URI命名空间中的部件名称)，并且，根据用户如何购买部件权限(例如，这可以限于一台设备、若干台设备，其可以具有时间、用途或日期范围限制以提供订阅能力，等)，使用任何合适的限制提供相关规则集的定义。如果权限部件由于“可消费的权限”被耗尽(诸如有限次数的使用或者有限量的时间)或者超出日期范围而过期，则可以简单地获得新的权限部件而不需要对与权限部件有关的部件的任何改变。4. 2支持多应用的权限部件如上所述，部件可以实现若干接口并且提供多个规则集。这使得单个权限部件能够提供用于 若干不同部件的权限，如图2中所示。这表示权限发行者可以为成组的应用提供权限。如果权限发行者提供使得能够使用一组智力游戏的权限部件，则该特征的使用的一个示例将基于订阅(可能在I个月之后过期)。4.3权限部件的多个实现使用接口引用权限部件，并且可能有实现该接口的若干不同的部件。当软件环境评估对规则集的引用时，其列举实现有关接口的所有部件，并且评估这些部件中的每个部件内的指定的规则集。选择最少限制的实现。例如，如果具有如下权限部件，该权限部件实现用于多个智力游戏的若干接口和规则集并且提供在某个日期之后过期的规则集(如在部分4. 2中的示例中所描述的)，则可能的是，用户还购买了用于该组内的游戏中的一个游戏的全部(不过期)权限部件。当用户试图玩该特定游戏时，评估权限的软件环境将选择该游戏的接口和规则集的最少限制的实现，该实现将是提供全部(不过期)权限的一个实现。当用户试图玩订阅权限部件所覆盖的一组智力游戏中的任何其他游戏时，仅有相应的接口和规则集的一个实现可用，因此，将选择订阅(过期)权限。图3不出了具有多个权限部件的系统的不例。4.4没有权限的情况下的默认部件行为要求权限的部件的作者可以控制如下情况下的软件环境的行为，在该情况下，不能够以多种方式获得有效的权限部件。通常，这种情况出现在“在购买之前试用”情节下(当用户直接从商店下载以试用部件时，或者当一个用户向另外的用户传送部件时)，或者在购买了但是日期限制的权限过期时出现。4. 4. I在清单中指定默认行为虽然与特定部件对应的权限规则中的大部分权限规则通常存在于与权限规则所应用的部件分开生成的权限部件中，然而，仍然有效的是，部件包含某些如下其他规则，当外部权限部件的所有实现评估为“失败”或者当不存在实现时，这些其他规则控制软件环境应当如何反应。通常，在这种情况下使用的规则是使得能够有限量地使用部件的规则使用部件的有限次数、使用部件的有限量时间、或者自从安装部件以来(而不管是否使用该部件)过去的有限量的挂钟时间。这些“可消费权限”由软件环境安全地追踪，以使得当这些权限用尽时，应用不再运行，或者软件环境提示用户获得另外的权限。4. 4. 2编程指定默认行为如果部件包含可执行代码，则其可以以某些方式编程控制DRM系统。
应用软件可以控制何时评估DRM权限并且根据结果修改其功能性。这意味着例如游戏可以允许用户玩第一等级，然后限制对于针对具有有效权限部件的设备的另外的等级的访问，或者应用可以允许使用应用本身而不允许保存结果，等。应用软件也可以定义在何时判断已经消费了“可消费权限”(如受限使用或者受限时间规则所解释的)，而非依赖于由DRM软件环境施加的何时已经使用了可消费权限的一般概念。例如，在游戏的情况中，游戏作者可以决定观看闪屏(splash-screens)和菜单所花费的时间不算在时间的消费上，并且，不认为用户已经消费了“玩”直到他们实际上进入游戏的主要部分为止。这些权限的消费由软件环境自动处理而没有与应用软件的相互作用的DRM系统不能提供相同等级的控制。此外，以这样的方式编程使用DRM系统的应用在权限过期时可以接收软件事件，以使其能够针对应用的类型适当调整其行为。例如，游戏可以使得能够完成整个等级而非
开始新的等级。其他类型的应用可以在出现权限已经过期的警告的情况下立即退出。在使用权限不可用的资源部件(诸如游戏的“升级包”)时，应用软件也可以使用这些技术来调整其行为，以使得能够限量地使用这些部件。4. 4. 3使用两种方法控制默认行为的最灵活且用户友好的方法之一是使用两种方法的组合，以使得用户能够在权限被评估和被消费时进行控制，并且还利用通过基础的软件环境的对“可消费的权限”使用的安全追踪。这使得应用能够提供应用中的用户接口，以使用户获得另外的权限，这给出了更加集成的应用/权限体验的感受。4.5权限过期当权力部件由于某些其他原因而过期或者无效时，其可以用于确定在哪里获得另外的权限。权限部件中的“AGC发行者URL”清单头包含URL。由于权限部件特定于特定的部件(或者部件的组)以及购买权限部件的商店二者，该URL可以将用户精确地导向至用于购买另外的权限的正确的网页，以更新订阅等。(进行用户认证)当用户试图使用对于其权限不可用的部件时，软件环境或者软件应用(在DRM知道应用部件的情况下)可以向用户提供如下选项启动平台的网络浏览器以去往过期的/无效的权限部件中指定的URL。如果不能获得从其可以确定发行者URL的权限部件时，则可以替代显示默认商店网页。4.6从商店下载“在购买之前试用”在从商店下载的“在购买之前试用”的情况下，商店网站生成“伪权限部件”，并且用户下载的ATX文件是包含该伪权限部件和应用该伪权限部件的部件二者的ATX文件。伪权限部件是不授予任何权限的权限部件，其规则集可以从不评估为“真”。然而，其包含有效的“AGC发行者URL”清单头，该清单头当被启动时将用户导向回正确的页面以购买有效的权限。与用户必须在商店上手动寻找正确的页面以购买权限的情节相比，这减小了获取新权限的复杂性，因此提高了完成权限获取处理的用户的比例。
4. 7应用传送终端用户之间的内容传送(超分发)是在该DRM模型下激励的。传送可以使用移动电话或者PC之间的蓝牙、通过红外或WiFi链接、通过电子邮件、或者通过很多其他传输机制来进行。被传送的包是包含有权限部件和主题部件的ATX文件。被传送的权限部件可以是在“在购买之前试用”操作中从商店下载的伪权限部件、或者是由发送者购买的完全有效的权限部件。由于所购买的权限部件被锁定至购买者的设备，所以其规则集在接收者的设备上不评估成“真”。然而，其仍然是可用的，这是因为其包含可以用于获取权限的“AGC发行者URL”清单头。伪权限部件在传送之后可以以相同的方式来使用。在该模型中，可以广泛地分发“在购买之前试用”应用，其中，任意或者所有接收者能够返回商店以购买权限，从而与内容不能超分发的系统相比，增加了权限购买的总数。5.使用情节5.1权限检查、消费和过期用例某些操作必须执行，以使得DRM系统能够正确地工作。·检查权限是否可用，以及，如果权限不可用则采取适当的动作·记录应用使用的次数以及使用应用的时间的量·处理权限过期事件(检查新的权限是否可用，以及，如果新的权限不可用则采取适当的动作)这些操作可以通过游戏或者软件环境来完成。以下描述若干用例。5.1.1软件环境自动处理权限检查、消费和过期这种情节在还未编写应用的情况下适用，以利用本文档中所描述的DRM能力。这种应用仍然可以与该DRM系统结合使用，然而与在DRM知道应用中的情形相比，在试用模式下可用的功能性较少。在这种情节下(参见图4)，软件环境在开始应用之前评估权限是否可用。如果权限不可用，则不开始应用。5. I. 2应用处理权限检查、消费和过期-示例I :受限等级试用模式如果在考虑到该DRM系统的知识的情况下编写应用，则可以定制DRM系统的行为，以提供更加用户友好的体验。应用必须执行上述动作，然而，关于其可以选择在何时进行这些动作有一定量的灵活性。图5示出了如下游戏，该游戏使得能够玩第一等级，然而在没有可用的权限的情况下该游戏使得用户不能够继续进行超过该等级。5. I. 3应用处理权限检查、消费和过期-示例2 :受限时间试用模式图6示出了如下游戏，该游戏使得如果权限不可用则其自身能够被使用I分钟(不包括导航菜单所花费的时间)。5. I. 4应用处理权限检查、消费和过期-示例3 :受限功能性图7示出了如下游戏，该游戏仅使得在以多玩家模式连接至另外的游戏实例时其自身能够被玩，其中，在另外的设备上有效的权限可用。为了简洁，可消费的权限消费、权限过期事件处理、以及向用户提供去往商店购买权限的选项的细节在本示例中未示出，假设以与之前的示例类似的方式对它们进行处理。5. 2权限获取用例以下描述用于获取权限的若干情节5.2.1手动用户导航最简单但最不令人满意的用户可以获取权限的方式是通过手动导航至商店网站上的有关的页面。这是不令人满意的，因为这通常需要用户登陆站点、找到有关的游戏等，这可能是一系列长的步骤。5. 2. 2来自应用内部的自动重定向当游戏与来自有关的商店网站的权限部件一起安装时，更好的情节(参见图8)是可能的，如权限部件在其清单中具有指定去哪里获取另外的权限的URL。所安装的权限部件不一定是有效的以便是可用的，其可以是从应用的另外的用户传送的有效的权限部件(在这种情况下，该有效的权限部件被锁定至该用户的设备，因而在接收者的设备上不是有效的)，该有效的权限部件可以是用于用户的设备的、有效但过期的权限部件，或者该有效的权限部件甚至可以是由商店为了承载该发行者URL信息而单独地生成的伪权限部件，在这种情况下，权限部件在任何设备上将永远都不是有效的。不管权限部件的来源和有效性，可以根据清单确定发行者URL，并且可以启动网页浏览器以直接去往用户可以得到权限的精确的页面。此外，如果商店网站以适当的方式生成URL，则与用户的设备有关的各信息段(诸如其唯一的ID)可以在调用网页浏览器之前被自动地插入到URL中。这使得商店网站能够自动地确定用户的身份，从而绕过另外的步骤。注意这仅用于识别，其不是认证机制并且不提供任何安全性。必须使用某些其他认证机制，诸如口令或者某种形式的自动网络操作者认证。5. 2. 3应用中的权限获取也利用编码在权限部件的清单中的发行者URL的用于权限获取的第三选择是应用中权限获取，其中，代替启动网页浏览器以处理交易，应用本身与某个网络服务通信以获取权限，如图9中所示。基于XML和HTTPS的网络服务通常用于这种操作，可以提供库，该库给予应用以相对简单的API，以发起和处理这样的交易。然而，如同对于基于网页浏览器的交易，需要相同的基本步骤，但是，在这种情况下，应用必须提供用于用户认证的用户界面，显示费用、从用户得到确认、选择付费方法等。这需要应用中的大量的用户接口支持，然而，这可以提供更加用户友好的体验。5. 3权限发行者用例权限发行者向用户提供各种选项，然后基于应用的某些参数发行权限，应用的某些参数诸如其是否是DRM知道的、出版者是否希望允许订阅或成组的权限等。5. 3. I 伪权限通常发行伪权限部件用于应用是DRM知道的“在购买之前试用”情节，如图10中所示。这样的权限部件的唯一目的是通过提供发行者URL来辅助后续的权限购买，并且在任何情况下从不提供有效的权限。5. 3. 2受限使用权限可以发行这些权限以提供针对非DRM知道的应用的“在购买之前试用”行为。软件架构评估权限的有效性，并且允许应用运行或者阻止其运行，如图11中所示。权限发行者可以发行时间受限或者使用受限的权限部件。5. 3. 3订阅权限
权限发行者可以生成在指定的日期和时间处过期的权限部件，如图12中所示。这可以用于提供订阅权限系统，一旦权限过期，则提示用户返回到商店以购买另外的权限。这些权限通常被锁定至使用唯一 ID的特定的一组设备，然而其还可以在没有设备限制的情况下用作“在购买之前试用”的替换形式。5. 3. 4设备锁定的权限权限发行者可以生成如下权限部件，该权限部件不具有除了在其上有效的一组设备之外的任何使用限制。这等同于为使用应用的权限的完全的、不受限的购买。这些权限部件被锁定至使用有关的唯一 ID的特定的一组设备。图13证实了如果这样的权限部件被传递给不是在权限规则集中指定的设备之一的设备，则权限如何在该设备上无效，从而应用回到试用模式。5. 3. 5制造商或操作者锁定权限发行者可以产生如下权限部件，该权限部件仅在由特定制造商制作的设备上、在特定移动电话网络上、或者在特定设备类型或一组设备类型上是有效的，如图14中所示。这可以用于提供锁定至特定的一组客户端设备的独占性的应用发布，同时仍然能够在设备之间自由地传送应用。这可以与本部分中所描述的任何其他用例(诸如订阅或在购买之前试用权限)结合使用。这还可以与规则集中的其他日期有关的规则结合使用，以提供用于游戏发布的(例如)第一个月的游戏的操作者或者制造商独占性，在这之后，该游戏在其他设备上自动
变得可用。5.3.6用于多个应用的权限包权限发行者在权限部件清单中指定支持什么接口名称和规则集名称。由于部件可以实现若干接口和规则集，所以这使得权限发行者有机会生成提供用于多个应用的有效权限的权限部件。这可以用于提供“智力游戏”订阅，例如，其中，一组游戏(由权限发行者确定)在权力部件有效时是有效的。5. 3. 7用于多个应用的权限用于具有提供用于多个应用的权限的单个权限部件的另外的用例源于如下事实权限发行者可以选择提供关于不同应用的不同的权限规则集，可能在购买了另一个应用的全部权限时提供一个应用的有限的有效期作为对用户的免费赠品。示例在图15中示出。5.4分发用例对于应用部件，存在许多分发用例。然而，这些可以分类成三个主要的方面。5. 4. I从商店下载
从商店直接下载内容。这可以是购买(直接地(outright)或订阅)或者可以是在购买之前试用情节。5. 4. 2物理介质内容在诸如CDROM或闪卡的物理介质分发。其示例包括介质通过物理商店的分发以及通过杂志封面磁盘的分发。用户得到包含应用部件的和伪权限部件的内容包，该伪权限部件的发行者URL被设定为在用户选择购买的情况下将用户导向至商店。5. 4. 3病毒式(用户至用户)分发在这种用例中，内容从一个用户传送给另外的用户。这可以通过任何通信介质发生，包括电子邮件、即时消息、蓝牙、闪存等。由商店对于最初下载内容的用户原始生成的权限部件用内容包来传递。如果权限部件是设备锁定的(如果用户通过购买而非购买之前试用来获得它的情况)，则权限在接收设备上不是有效的。然而，无论权限有效与否，权限部件的存在使得如果接收者选择购买内容，则使他们能够直接去往编码在权限部件中的发行者URL。图16示出了示例。商店可以选择将与原始购买者的身份有关的信息编码在该URL中的，这使得他们能够为推荐购买而给该人某种类型的奖励(例如，商店存款)。注意，在最终用户中的一个或更多个用户决定购买权限之前，内容包可以在不同的用户之间传递多次。这种情节的重要特征在于，当与横跨不同CPU和操作系统的可执行代码的二进制可移植性结合时，病毒式分发可以横跨比通常采用传统的可执行代码的情况更宽范围的设备发生。另一个重要特征在于，该分发机制可以应用于任何部件，例如，其可以应用于诸如游戏等级的资源部件以及应用部件(游戏本身)。
权利要求
1.一种分发权限受管理的软件的方法，包括向第一用户递送二进制可移植应用部件和相关联的权限部件，所述二进制可移植应用部件包括未加密的可执行代码，所述相关联的权限部件定义针对所述第一用户不受限地执行所述应用的加密签名的许可条件，由此，在所述第一用户将所述应用部件复制给第二用户时，所述应用部件当由所述第二用户执行时检查权限部件的存在，并且如果缺少权限部件或者如果所述权限部件确定关于所述第二用户不满足所述许可条件，则所述应用部件以受限模式运行。
2.根据权利要求I所述的方法，包括根据请求向所述第二用户递送新的权限部件，所述新的权限部件定义如下许可条件所述许可条件使得所述第二用户能够不受限地执行从所述第一用户接收的所述应用部件的副本。
3.根据权利要求I所述的方法，其中，单个权限部件定义用于多个应用部件的所述许可条件。
4.根据权利要求I所述的方法，包括检查多个权限部件的每一个权限部件的相应的所述许可条件，以确定是否以不受限模式运行所述应用部件。
5.根据权利要求4所述的方法，其中，对所述应用部件的执行由所述相应所述许可条件的最低限制确定。
6.根据权利要求I所述的方法，包括多个应用部件和多个权限部件，当执行每个所述应用部件时，每个所述应用部件检查所述权限部件的相应的许可条件，并且每个所述应用部件以由所述条件的最低限制确定的模式执行。
7.根据权利要求I所述的方法，其中，如果所述应用部件确定不存在权限部件，则以第一受限模式执行所述应用部件，而如果存在许可部件但不满足相应的许可条件，则以第二受限模式执行所述应用部件。
8.根据权利要求I所述的方法，其中，所述受限模式包括时间或使用限制，在所述时间或使用限制过期时，不能再执行所述应用。
9.根据权利要求8所述的方法，其中，所述过期由所述应用部件编程确定。
10.根据权利要求8所述的方法，在所述过期之后，所述第二用户被导向或者被给予选项以被导向至能够购买新的权限部件的在线位置。
11.根据权利要求10所述的方法，其中，所述在线位置是存储在所述应用部件中的URL。
12.根据权利要求10所述的方法，其中，所述在线位置是存储在所述权限部件中的URL。
13.根据权利要求I所述的方法，其中，被递送给所述第一用户的所述权限部件是伪权限部件，在所述伪权限部件中，所述许可条件从来都不能满足，以使得所述第一用户在决定是否购买使得能够进行不受限执行的权限部件之前能够以受限模式试用所述应用部件。
14.根据权利要求I所述的方法，其中，提供给所述第一用户的所述权限部件的所述许可条件要求在特定的设备上执行所述应用部件，以使得如果所述应用部件和所述权限部件被复制给不同的设备时，所述应用部件以所述受限模式执行。
15.根据权利要求I所述的方法，其中，所述应用部件是用于移动电话的游戏。
16.一种计算机可读介质，所述计算机可读介质存储用于在数字计算机上实现权利要求I所述的方法的程序代码。
全文摘要
一种分发权限受管理的软件的方法，该方法利用二进制可移植应用部件和相关联的权限部件。应用部件包括未加密的执行代码，如果缺少权限部件或者如果权限部件确定不满足有关的许可条件，则该未加密的执行代码使得应用部件以受限模式执行。这样的方法使得能够在用户之间自由地分发诸如用于移动电话的游戏的应用部件，并且使得该应用部件能够以受限模式即刻使用而不需要接收者联系权限发行者。
文档编号G06F21/00GK102804193SQ201080026452
公开日2012年11月28日 申请日期2010年5月5日 优先权日2009年6月16日
发明者丹尼尔·谢尔顿 申请人:安蒂克斯实验室有限公司