CN101556639B

CN101556639B - 应用打包设备及其控制方法

Info

Publication number: CN101556639B
Application number: CN2009101337331A
Authority: CN
Inventors: 松个下勇人
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2008-04-09
Filing date: 2009-04-08
Publication date: 2012-06-13
Anticipated expiration: 2029-04-08
Also published as: KR20090107949A; EP2109057A3; KR101061348B1; JP5121542B2; US20090260003A1; JP2009252091A; CN101556639A; EP2109057A2

Abstract

本发明提供应用打包设备及其控制方法。从应用中提取包含在多个加密的应用中的最终用户许可协议。这样，不用等待对所述多个加密的应用的解密完成就能从用户获得对所述最终用户许可协议的接受。

Description

应用打包设备及其控制方法

技术领域

本发明涉及将多个应用打包的应用打包设备以及用于控制该应用打包设备的方法。

背景技术

近年来，为了防止应用被非法地使用而采用了“许可(license)”的概念。一般来说，为单个应用分配单个许可，通过在应用安装处理的初始部分输入所分配的许可的详细信息，才能安装应用。

此外，已知一种创建包括多个应用的档案以使得将所述多个应用作为应用包来同时安装的方法。

然而，在安装包括分配了许可的多个应用的应用包的处理中，由于对于各个应用的个体安装均应输入各个许可，因此安装处理很复杂。

为了解决该问题，在日本专利特开第2006-163896号公报中提出了一种方法，该方法针对各个应用包将指定在应用包中包括的多个应用的许可数据以及验证该许可数据的有效性的数据集中添加到多个许可中的各个中。使用该方法，当安装包括分配了许可的应用的应用包时，只进行一次输入许可的处理。

使用日本专利特开第2006-163896号公报中公开的方法，由于在安装应用包处理的第一阶段只输入一次许可，所以很容易进行应用包的安装处理。然而，除了该许可之外，在安装处理中还应该输入其他项。

例如，通常使用EULA(最终用户许可协议)。该协议是其中记载了安装之前要认可的详细许可信息的协议。为了继续安装处理，用户应该接受该协议。

此外，可以设置针对各个应用特有的安装要求(例如允许应用安装的平台的版本以及需要的最小资源)。在这种情况下，可能发送表示由于应用不满足安装要求而不能安装该应用的通知或者表示继续安装处理的通知。

在日本专利特开第2006-163896号公报公开的方法中，应用包仅仅包括其中打包的多个应用并且针对各个应用进行安装处理。因此，当针对各个应用开始安装处理时，可能发送表示应用不满足安装要求的通知，所以可能需要进行用于确定是否要继续安装的输入操作，或者可能需要进行用于接受最终用户许可协议的输入操作。结果，存在使安装处理变复杂的可能性。例如，存在在安装处理期间向用户发送大量询问的可能性。

就目前的情况来看，如果在安装处理期间必须逐个地打开各个应用并且由用户接受其中的最终用户许可协议，则增加了使从多应用包中安装软件的速度变慢和复杂性的问题。这不仅增加了用于安装的时间，而且由于只有当将应用解密后才可能接受针对各个应用的单个许可并且用户不会提前知道这何时会发生，所以需要用户在整个安装处理过程中都要在场。因此，用户不能简单地设置要安装的应用包，由此接受最终用户许可协议，然后离开设备而不需要定期地干预软件的安装。这使得安装消耗更多的时间而且对用户来说很复杂。

发明内容

本发明提供了一种应用打包设备，该应用打包设备包括：解密单元，其被配置为逐个地对多个应用解密；复制单元，其被配置为复制包含在所述解密的应用中的最终用户许可协议；以及打包单元，其被配置为将所述最终用户许可协议的副本与尚未被解密的应用打包。

通过下面参照附图对示例性实施例的描述，本发明的其他特征将变得更加清楚。

附图说明

图1是例示根据本发明示例性实施例的图像形成装置的框图。

图2是例示根据本发明第一示例性实施例的打包设备的配置的框图。

图3是例示根据本发明第一示例性实施例的应用的配置的框图。

图4示出了例示根据本发明第一示例性实施例的应用定义的配置的列表。

图5是例示根据本发明第一示例性实施例的许可的配置的框图。

图6是例示根据本发明第一示例性实施例的应用包6的配置的框图。

图7是例示根据本发明第一示例性实施例的包许可(package license)的配置的框图。

图8是例示应用包生成处理的流程图。

图9A和图9B示出了例示安装处理的流程图。

图10示出了例示安装管理表的配置的列表。

图11是例示根据本发明第二示例性实施例的应用包的配置的框图。

图12示出了例示根据本发明第二示例性实施例的应用包定义的配置的列表。

图13示出了包许可。

图14是例示应用包生成处理的流程图。

图15A和图15B是例示安装处理的流程图。

具体实施方式

以下将参照附图对实现本发明的最佳方式进行说明。

第一示例性实施例

图像形成装置1

图1是例示根据本发明第一示例性实施例的图像形成装置1的框图。

图像形成装置1包括打印设备11和图像处理设备12。

图像处理设备12包括CPU 121、直接存储单元122(例如，RAM(随机存取存储器))、间接存储单元123(例如，ROM(只读存储器)或HDD(硬盘驱动器))、用户接口(user interface)124以及外部接口125。

直接存储单元122将数据直接发送给CPU 121或者从CPU 121直接接收数据。间接存储单元123通过直接存储单元122将数据发送给CPU 121或者从CPU 121接收数据。

直接存储单元122存储各种应用程序以及平台程序。

用户接口124包括键盘、鼠标和显示器，并能够接受用户输入的指示和进行数据(画面数据)显示。

外部接口125用于从外部设备接收数据或向外部设备发送数据。外部设备的示例包括外部存储设备(例如外部HDD或外部USB存储器)以及分开设置的设备(例如图像形成装置或通过网络连接的主机)。

平台部13

CPU 121进行一定的操作，以将存储在间接存储单元123中的平台程序传输到(或存储在)直接存储单元122中。在传输之后，使CPU 121处于可利用CPU 121执行平台程序的状态。

在该示例性实施例中，将可利用CPU 121执行平台程序的状态称作平台部13被激活的状态。

请注意，在本示例性实施例中将具有包括以下组件的配置的单元称作平台部13，所述组件为：CPU 121；直接存储单元122的存储平台程序的的部分区域；用于存储当CPU 121处理平台程序时获取的信息(例如计算结果)的区域(包括直接存储单元122的一部分和间接存储单元123的一部分)。

应用程序

平台部13将存储在间接存储单元123中的应用程序中的第一应用程序传输(存储)到直接存储单元122。在传输完成之后，使平台部13处于平台部13准备好执行第一应用程序的状态。在本示例性实施例中将这种操作称作由平台部13进行的激活第一应用程序的操作。

另一方面，平台部13能够从直接存储单元122中删除第一应用程序。在本示例性实施例中将这种操作称作由平台部13进行的中断第一应用程序的操作。

平台部13通过外部接口125接收表示第一应用程序的数据并将数据存储在其中。在此，平台部13存储关于第一应用程序存在的信息并使第一应用程序受其控制。在本示例性实施例中将这种操作称作在平台部13中安装第一应用程序的操作。

另一方面，平台部13能够从包含在平台部13中的间接存储单元123中将第一应用程序删除。在本示例性实施例中将这种操作称作由平台部13进行的卸载第一应用程序的操作。请注意，在当平台部13试图卸载第一应用程序时而第一应用程序已经处于激活状态的情况下，在第一应用程序停止之后进行卸载第一应用程序的操作。

尽管以第一应用程序为示例进行了上述说明，但是对于本领域的技术人员来说，很显然当使用其他应用程序(例如第二应用程序)时也能够获得相同的结果。

打包设备(应用打包设备)2

图2是例示根据本发明第一示例性实施例的打包设备2的配置的框图。

打包设备2包括接收单元21、发送单元22、包许可生成器23以及应用包生成器24。请注意，以下将对包许可生成器23和应用包生成器24进行详细说明。

打包设备2对应于诸如个人计算机或工作站的计算机。该计算机包括CPU、主存储单元、外部存储单元以及外部接口，作为主要配置。外部存储单元存储操作系统(OS)以及各种程序。主存储单元存储从外部存储设备读取的OS以及CPU要执行的各种程序。

请注意，在本示例性实施例中上述各种程序包括打包程序。根据打包程序的内容，打包设备2实现上述单元。

应用3

图3是例示根据本发明第一示例性实施例的应用3的配置的框图。

应用3包括非加密区31和加密区32。非加密区31包括存储将在下文中描述的应用定义311的特定目录(命名为“MANIFEST”)。加密区32也包括存储稍后描述的最终用户许可协议321以及与上述应用程序类似的应用程序322的特定目录(命名为“EULA”)。

应当将加密区32配置为使得只有当许可(将在下文中描述)有效时才能被解密，并且可以使用任意的加密方法。也就是说，有效的许可包括用来对加密区进行解密的信息(例如密钥)。

应用定义311

图4示出了例示根据本发明第一示例性实施例的应用定义311的配置的列表。

应用定义311包括应用ID 41、产品版本42、应用名43、安装接受平台44以及期望消耗资源大小45。应用ID 41是用来唯一地识别多个应用中的应用3的标识符。当产品版本42与应用ID 41组合使用时，能够指定应用3的版本。应用名43是表示应用名称的字符串。

安装接受平台44表示接受应用3的安装的平台程序。安装接受平台44表示平台程序的类型和版本、设备的唯一ID以及平台程序中应包含的功能。

在期望消耗资源大小45中，定义当安装应用3时或者安装应用3之后所需的资源大小。期望消耗资源大小45的示例包括要消耗的间接存储单元123的区域的大小以及要消耗的直接存储单元122的区域的大小。

许可5

图5是例示根据本发明第一示例性实施例的许可5的配置的框图。

许可5包括许可ID 51、应用ID 52以及许可信息53。

许可ID 51是用来识别许可5的唯一ID。应用ID 52存储关于已分配了许可5的应用3的应用ID 41的信息。许可信息53存储许可5的许可定义(例如，许可5的有效期限和能够分配许可5的次数)以及用来对应用3的加密区32解密的信息。

应用包6

应用包6由应用包生成器24生成，这将在下文中进行说明。应用包6包括多个应用611至613以及针对应用611至613的多个最终用户许可协议621至623。

将在下文中对由应用包生成器24进行的生成应用包6的处理进行说明。

包许可7

图7是例示根据本发明第一示例性实施例的包许可7的配置的框图。

通过将使用包许可生成器23生成的多个许可(例如71、72以及73)打包来获得包许可7。包许可7包括多个许可71至73。

生成应用包6的处理

现在参照图8的流程图，对由应用包生成器24进行的生成应用包6的处理(步骤S802至步骤S807)以及步骤S801和步骤S808中的操作进行说明。请注意，在本示例性实施例中，步骤S802至步骤S807中的所有操作都是自动进行的，并且不接受用户输入的指示。具体地说，在进行步骤S802中的解密操作至步骤S807中的获得总应用包的操作期间，不接受用户输入的指示。这个事实也适用于第二示例性实施例(也就是说，图14的步骤S1402至步骤S1410中的所有操作是自动进行的)。

应用包生成器24从包许可生成器23接收多个要打包的这类应用3。此外，在步骤S801中，应用包生成器24接收包含与应用3相对应的多个这类许可5的包许可7。

在步骤S802中，应用包生成器24对接收到的各个应用3进行解密。

然后，在步骤S803中，应用包生成器24选择一个解密的应用3，并确定所选择的应用3是否包括最终用户许可协议321。当确定结果是肯定的时，处理进入步骤S804。请注意，最终用户许可协议321存储在应用3中的特定目录(例如命名为“EULA”的目录)中，因此，通过使用应用包生成器24在特定目录中搜索最终用户许可协议321，来执行关于所选择的应用3是否包括最终用户许可协议321的确定。优选地确定最终用户许可协议321的文件名的形式。

然后，在步骤S804中，应用包生成器24复制包含在解密的应用3中的最终用户许可协议321。在步骤S805中，应用包生成器24对最终用户许可协议321的副本的文件名，分配作为用来唯一地指定最终用户许可协议321的标识符的应用ID 41。所分配的应用ID 41用来指定原始应用3。此外，应用3可以包括多个这类最终用户许可协议321(例如，在应用3兼容各种语言的情况下)。在这种情况下，复制所有的最终用户许可协议321，并对最终用户许可协议321的所有副本分配ID。

在对步骤S801中接收到的所有应用3进行了上述操作之后，在步骤S807中应用包生成器24进行下述操作。也就是说，将尚未经过步骤S802中解密操作的所有应用3以及在步骤S804中获得的并在步骤S805中分配了ID的多个最终用户许可协议321的副本打包。以这种方式生成应用包6。

然后，应用包生成器24将生成的应用包6以及包许可7发送给发送单元22。

请注意，在步骤S802至步骤S807中，应用包生成器24从相应的加密的应用3中提取最终用户许可协议321。然后，获得包含所提取的最终用户许可协议321以及应用3的应用包6。

换句话说，在步骤S802至步骤S807中，应用包生成器24在与包括尚未解密的应用3的区域不同的区域中，从加密的应用3中生成包括最终用户许可协议321的应用包6。

安装管理表10

图10示出了例示安装管理表1000的配置的列表。

当平台部13进行安装处理时使用安装管理表1000并且在安装处理完成之后将其丢弃。安装管理表1000包括根据各个应用3的应用定义311而设置的应用ID 1001、产品版本1002以及应用名1003。安装管理表1000还包括下文将详细描述的安装要求确认结果1004以及许可协议结果1005。

安装管理表1000还包括用来参照与应用3相对应的许可5的应用1006以及许可1007。

安装应用包6的处理

现在将参照图9A和图9B的流程图对平台部13进行的安装应用包6的处理进行说明。

请注意，在本示例性实施例中，安装处理包括应用程序的安装以及随安装一起进行的处理。具体地说，步骤S901的操作至步骤S915的操作包含在安装处理中，更具体地说，在步骤S914中进行安装。也就是说，在步骤S901至步骤S915中进行的安装应用的处理中进行应用程序的安装。

在步骤S901中，平台部13从外部接口125接收应用包6和包许可7。换句话说，平台部13通过外部接口125接收应用包6和包许可7。很明显平台部13同时接收由使用通过外部接口125连接的设备的用户发出的指示，该指示表示关于进行应用包6的安装处理的请求。

然后，在步骤S902中，平台部13进行下述处理。平台部13接收与包含在应用包6中的所有应用3相对应的、与上述应用定义311类似的多个应用定义311。平台部13从所接收到的包许可7获得与应用3相对应的许可5。然后，平台部13根据诸如应用3、应用定义311以及许可5的信息生成安装管理表1000。更具体地说，平台部13生成安装管理表1000，安装管理表1000存储除了要包含在安装管理表1000中的安装要求确认结果1004和许可协议结果1005以外的信息(关于应用定义311的信息以及关于许可5的信息)。

平台部13以在安装管理表1000中登记的顺序进行下述操作。

首先，在步骤S903中，平台部13从包含在要处理的相应一个应用3中的非加密区31中接收一个应用定义311，以及从获取的许可5中的一个许可5中接收许可信息53。然后，在步骤S904中，平台部13根据诸如应用定义311和许可信息53的信息进行确认许可5和安装要求的处理。作为该处理的结果，当确定安装是可接受的时，在步骤S905中用表示安装是可接受的信息来更新包含在安装管理表1000中的安装要求确认结果1004。另一方面，当确认安装要求的处理的结果表示安装是不可接受的时，在步骤S921中，平台部13将表示安装是不可接受的信息通知给外部接口125并通过外部接口125请求来自用户的指示。之后，在步骤S921中平台部13确认通过外部接口125发来的用户输入的指示(也就是说，平台部13确定是否要继续安装处理)。当确定要继续安装处理时(也就是说，当确定指示表示继续安装处理时)，在步骤S905中平台部13用表示安装是不可接受的信息来更新包含在安装管理表1000中的安装要求确认结果1004。另一方面，当确定不继续安装处理时(也就是说，当确定指示表示中断安装处理时)，在步骤S931中中断安装处理。

在步骤S906中，平台部13重复地进行上述操作直到在安装管理表1000中登记的所有应用3都被处理。

随后，平台部13仅对应用3中的、与表示安装是可接受的信息相对应的应用3进行下述的操作。

平台部13确定应用包6是否在除了应用3的区域以外的区域存储了要处理的应用3中的一个应用3的最终用户许可协议321的副本。当确定结果是肯定的时，在步骤S907中，平台部13获得最终用户许可协议321的副本。另一方面，当确定结果是否定的时，在步骤S910中，平台部13用表示无关性的信息来更新包含在安装管理表1000中的许可协议结果1005。当应用包6存储了副本时，在步骤S909中，平台部13将获得的最终用户许可协议321发送给外部接口125。然后，在步骤S909中，平台部13通过外部接口125从用户接收表示用户接受所通知的最终用户许可协议321的信息或表示用户不接受所通知的最终用户许可协议321的信息。当用户接受最终用户许可协议321时，用表示接受的信息更新包含在安装管理表1000中的许可协议结果1005。在更新之后，通过步骤S912、步骤S913以及步骤S915的操作来安装要处理的应用。另一方面，当用户不接受最终用户许可协议321时，在步骤S922中，平台部13通过外部接口125提示用户确定是否要继续安装处理。当确定要继续安装处理时，在步骤S910中，平台部13用表示不认可的信息更新包含在安装管理表1000中的许可协议结果1005。另一方面，当确定不继续安装处理时，在步骤S931中中断安装处理。

然后，在步骤S911中，平台部13仅对所有应用3中的、“其安装要求确认结果1004与表示安装是可接受的信息相对应”的应用3重复进行上述操作。之后，平台部13对在安装管理表1000中登记的所有应用3中的、“其安装要求确认结果1004与表示安装是可接受的信息相对应”且“其许可协议结果1005与表示无关性的信息或者表示接受的信息相对应”的应用3进行下述的操作。

在步骤S913中，平台部13对加密的应用3中的一个应用3进行解密。在步骤S914中，安装包含在应用3中的应用程序322。在步骤S915中重复进行这些操作直到安装了包含在要处理的所有应用3中的应用程序322为止，然后，结束安装处理。

以下将对步骤S914中的操作进行详细的说明。

首先，在步骤S914中，安装包含在“在步骤S910中用表示接受的信息来更新其许可协议结果1005的应用3”中的一个应用3中的应用程序。请注意，不安装包含在“在步骤S910中未用表示接受的信息来更新其许可协议结果1005的应用”中的应用程序。

此外，请注意，在步骤S914中忽略在步骤S913中通过对多个应用3解密而获得的许可协议结果1005。这是因为，关于许可协议，在步骤S910以及步骤S911中已经确认了最终用户许可协议321的副本。

用于确认安装要求的方法

现在将对由平台部13进行的确认安装处理中的安装要求的方法进行说明。

平台部13通过将由应用定义311定义的信息、关于平台部13的信息以及关于图像处理设备12的信息相互比较来确认安装要求。具体地，使用应用定义311中定义的安装接受平台44以及期望消耗资源大小45。

假设平台程序的版本是第二版本，图像处理设备12的间接存储单元123的剩余大小是100MB，并且还假设唯一ID为“#####0000000000”并且所提供的功能的唯一ID表示“打印功能的版本是第一版本并且用户接口124的显示器大小对应于SVGA(超级视频图形阵列)”，进行确定如下。

当要安装其中一个应用3的安装接受平台44的平台程序的版本是第一版本时，平台部13确定安装是不可接受的。也就是说，根据平台程序是否对应于能够安装应用3的平台的版本来进行确定。

此外，当应用3的期望消耗资源大小45(即应用3要消耗的间接存储单元123的区域的大小)为120MB时，平台部13确定安装是不可接受的。也就是说，根据设备是否具有等于或大于应用3要消耗的资源的剩余资源来进行确定。

当包含能够安装应用3的安装接受平台44的设备的唯一ID为“#####0000000000”时，平台部13确定安装是不可接受的。也就是说，根据唯一ID是否对应于能够安装应用3的设备的唯一ID来进行确定。

此外，当能够安装应用3的安装接受平台44的设备的功能的唯一ID表示“打印功能的第二版本”时，平台部13确定安装是不可接受的。也就是说，根据设备是否具有安装的功能来进行确定。

综上所述，平台部13通过将在应用定义311中定义的信息与关于设备的信息进行比较来确定安装是否可接受。

此外，在本示例性实施例中，应用包6未被加密。然而，与应用3一样，应用包6可以包括存储多个应用许可协议(621至623)和多个加密应用(611至613)的加密区。在该情况下，很明确在步骤S807和步骤S808中应用包生成器24对最终用户许可协议的副本进行加密。相似地，在步骤S807和步骤S808中应用包生成器24再次对多个加密的应用3进行加密。也就是说，应用3被加密两次。因此，通过将加密两次的应用3存储在加密区中来防止篡改最终用户许可协议。

请注意，当在步骤S807和步骤S808中进行加密时，解密所用的信息(例如密钥)被存储在步骤S801中获得的包许可7中。

如上所述，根据第一示例性实施例，当安装应用包时，可以在安装处理的第一阶段集中进行确认安装要求的操作、确认许可的操作以及接受最终用户许可协议的操作。这样，避免了例如在安装处理期间由于需要输入表示接受最终用户许可协议的指示以及表示继续安装处理的指示而使安装处理变复杂。

第二示例性实施例

在第二示例性实施例中，省略了与第一示例性实施例中的结构部件相同的结构部件的描述以及省略了与第一示例性实施例中的构成元件相同的构成元件的描述。请注意，对于与第一示例性实施例中的结构部件相同的结构部件以及与第一示例性实施例的构成元件相同的构成元件使用与第一示例性实施例的标号相同的标号。

请注意，以下将对第二示例性实施例中与第一示例性实施例有显著不同的一些地方进行说明。第二示例性实施例与第一示例性实施例的不同之处在于：第二示例性实施例的应用包包括应用包定义(参照图11)。第一示例性实施例的应用包不包括应用包定义(参照图6)。

因此，在第二示例性实施例中，不需要确认各个应用定义(参照图9A和图9B中位于步骤S904和步骤S921之间的菱形框)，只需要确认应用包定义(参照图15A中位于步骤S1503和步骤S1521之间的菱形框)。

此外，在第二示例性实施例中，当生成包括应用包定义的应用包时，根据包含在应用定义中的信息的类型进行计算(加法和乘法)。在不生成应用包定义的第一示例性实施例中没有涉及这种计算。

应用包1100

图11是例示根据本发明第二示例性实施例的应用包1100的配置的框图。

应用包生成器24生成应用包1100，在下文中将对此进行描述。应用包1100包括非加密区1101和加密区1102。下文中将要描述的应用包定义1103存储在非加密区1101的特定目录(命名为“MANIFEST”的目录)中。此外，在加密区1102中存储与多个应用1111至1113相对应的多个应用许可协议1121至1123。

只有当包许可(将在下文中描述)有效时，只要对加密区1102进行解密，就可以使用任意方法对加密区1102加密。也就是说，有效的许可包括用于对加密区1102解密的信息(例如密钥)。

应用包定义

图12示出了例示根据本发明第二示例性实施例的应用包定义1103的配置的列表。

应用包定义1103包括应用包ID 1201、产品版本1202、应用包名1203、安装接受平台1204以及期望消耗资源大小1205。应用包定义1103还包括应用定义1206至1208(即包含在应用包1100中的所有应用3的应用定义)。

应用ID 1201是用于在多个应用包中唯一地识别应用包1100的标识符。当产品版本1202与应用包ID 1201组合使用时，能够指定应用包1100的版本。应用名1203是表示应用名称的字符串。

安装接受平台1204表示接受包含在应用包1100中的所有应用3的安装的平台程序。安装接受平台1204表示平台程序的类型和版本、设备的唯一ID以及表示平台程序中应当包含的功能的ID。在期望消耗资源大小1205中，定义当安装所有应用3时或在安装了所有应用3之后所需的资源大小。期望消耗资源大小45的示例包括要消耗的间接存储单元123的大小和要消耗的直接存储单元122的大小。

包许可1300

图13是例示根据本发明第二示例性实施例的包许可1300的配置的框图。

通过对使用包许可生成器23生成的多个许可(例如1304、1305以及1306)打包来获得包许可1300。包许可1300包括包许可ID 1301、应用包ID 1302、包许可信息1303以及多个许可1304至1306。

包许可ID 1301是用来识别包许可1300的唯一ID。应用包ID 1302存储关于分配了许可的应用包1100的应用包ID 1201的信息。包许可信息1303存储例如包许可1300的定义以及用来对应用包1100的加密区1102解密的信息。有关包许可的定义包括包许可1300的有效期限和可以分配许可的次数。

生成应用包的处理

现在参照图14的流程图，将对应用包生成器24进行的生成应用包1100的处理(步骤S1402至步骤S1410)以及步骤S1401和步骤S1411中的操作进行说明。

在步骤S1401中，应用包生成器24从包许可生成器23接收以下项：要打包的多个应用3以及包含与应用3相对应的多个许可5的包许可1300。

在步骤S1402中，应用包生成器24对接收到的应用3解密。

然后，在步骤S1403中，应用包生成器24选择其中一个解密的应用3，并确定所选择的应用3是否包括最终用户许可协议321。当确定结果是肯定的时，处理进入步骤S1404。请注意，最终用户许可协议321存储在应用3中的特定目录(例如命名为“EULA”的目录)中，因此，通过使用应用包生成器24在特定目录中搜索最终用户许可协议321，来执行关于所选择的应用3是否包括最终用户许可协议321的确定。优选确定最终用户许可协议321的文件名的形式。

然后，在步骤S1404中，应用包生成器24复制包含在解密的应用3中的最终用户许可协议321。在步骤S1405中，应用包生成器24对最终用户许可协议321的副本的文件名分配作为用来唯一地指定最终用户许可协议321的标识符的应用ID 41。应用ID 41用来指定原始的应用3。此外，应用3可以包括多个最终用户许可协议321(例如，在应用3兼容各种语言的情况下)。在这种情况下，复制所有的最终用户许可协议321，并对最终用户许可协议321的所有副本分配ID。

随后，在步骤S1406中，应用包生成器24获得包含在应用3中的应用定义311。

应用包生成器24对在步骤S1401中接收到的所有应用3进行上述操作。之后，在步骤S1408中，应用包生成器24根据所有的应用定义311生成应用包定义1103，这将在下文中说明。

然后，在步骤S1409中，应用包生成器24进行下述操作。也就是说，将尚未经过步骤S1402中的解密操作的所有应用3、在步骤S1404中获得的并且在步骤S1405中分配了ID的最终用户许可协议321的副本以及在步骤S1408中生成的应用包定义1103打包。以这种方式，获得应用包1100。

然后，应用包生成器24将生成的应用包1100和包许可1300发送给发送单元22。

请注意，在步骤S1402和步骤S1409中，应用包生成器24从相应的加密应用3中提取最终用户许可协议321。

此外，在步骤S1406、步骤S1408以及步骤S1409中，应用包生成器24计算包含在相应的应用3中的应用定义1206至1208，以生成单个应用包定义1103。

此外，应用包生成器24生成包括所提取的最终用户许可协议321、所生成的应用包定义1103以及应用3的应用包1100。

换句话说，在步骤S1402和步骤S1409中，应用包生成器24在与包括尚未解密的应用3的区域不同的区域中生成包括加密的应用3的最终用户许可协议321的应用包1100。

此外，在步骤S1406、步骤S1408以及步骤S1409中，应用包生成器24在与尚未解密的加密应用3的区域不同的区域中生成包括应用包定义1103的应用包1100。请注意，如上所述，通过计算针对各个应用3定义的应用定义1206至1208，来获得应用包定义1103。

请注意，在本示例性实施例中，为了识别存储复制的最终用户许可协议321的原件的应用3，描述用来将应用3的应用ID 41分配给最终用户许可协议321的文件名的方法。然而，也可以采用其他方法，只要能识别存储复制的最终用户许可协议321的原件的应用3即可。例如，可以采用用来生成列出应用3和最终用户许可协议321之间的关联性的表并将该表存储在应用包1100的应用包定义1103中的方法。

生成应用包定义的方法

将对应用包生成器24进行的生成应用包定义1103的方法进行说明。

应用包生成器24通过计算在应用定义311中定义的信息项来生成应用包定义1103。具体来说，在应用定义311中定义的信息项中，计算关于安装接受平台1202的信息以及关于期望消耗资源大小1205的信息。

例如，假设对应用3A的应用定义311进行定义如下：安装接受平台的版本是第二版本，要消耗的间接存储单元123的区域的大小是100MB，安装接受设备的唯一ID为“#####0000000000，####0000000001”，所需的功能的唯一ID表示“打印功能是第二版本并且用户接口124的显示器大小(display size)对应于SVGA或VGA”。请注意，唯一ID“#####0000000000，####0000000001”意思是“#####0000000000或####0000000001”。

另一方面，假设对应用3B的应用定义311进行定义如下：安装接受平台的版本是第一版本或第二版本，要消耗的间接存储单元123的区域的大小是120MB，安装接受设备的唯一ID为“#####0000000000”，所需的功能的唯一ID表示“打印功能的版本是第一版本”。

在这种情况下，如下所述来生成应用包定义1103。

首先，根据包含在应用定义中的信息项的类型确定使用加法还是乘法，并进行计算。

具体来说，对于安装接受设备的间接存储单元的版本和大小确定使用加法。另一方面，对于安装接受设备的唯一ID和安装所需的功能的唯一ID确定使用乘法。

能够接受包含在应用包中的所有应用的安装的平台程序的版本是第二版本。这是使用逻辑乘法来计算的。

允许安装包含在应用包中的所有应用的间接存储单元123的大小是220MB或更大。这是使用数值加法来计算的，并得到以下表达式：220MB＝120MB+100MB。

此外，允许安装包含在应用包中的所有应用的安装接受设备的唯一ID是“#####0000000000”。这也是使用逻辑乘法(简单乘法)来计算的。也就是说，通过使用唯一ID“#####0000000000”和唯一ID“#####0000000000，####0000000001”进行逻辑乘法(乘法)来获得唯一ID。

安装应用包中包含的所有应用所需的功能的唯一ID表示“打印功能的版本是第二版本并且用户接口124的显示器大小对应于SVGA或VGA”。这是使用逻辑乘法来计算的。

如上所述，应用包生成器24通过使用加法或乘法(逻辑乘法)计算在应用定义311中定义的各个信息项来生成应用包定义1103。

安装应用包1100的处理

参照图15A和图15B的流程图，对平台部13进行的安装应用包1100的处理进行说明。

请注意，在本示例性实施例中，安装处理包括应用程序的安装和伴随安装一起进行的处理。具体来说，步骤S1501的操作至步骤S1514的操作包含在安装处理中，更具体地说，在步骤S1513中进行安装。也就是说，在步骤S1501至步骤S1514中进行的安装应用的处理中进行应用程序的安装。

在步骤S1501中，平台部13从外部接口125接收应用包1100和包许可1300。

然后，在步骤S1502中，平台部13进行下述处理。平台部13接收包含在应用包1100中的应用包定义1103以及包含在包许可1300中的包许可信息1303。然后，平台部13根据诸如所获取的应用包定义1103和所获取的包许可信息1303的信息，生成安装管理表1000。具体来说，平台部13生成安装管理表1000，该安装管理表1000存储除了包含在安装管理表1000中的安装要求确认结果1004以及许可协议结果1005以外的信息(诸如应用定义311和许可5的信息)。

然后，在步骤S1503中，平台部13根据应用包定义1103和包许可信息1303中的信息项，进行确认包许可1300以及安装要求的处理(将在下文中说明)。作为确认包许可1300以及安装要求的处理的结果，当确定安装是可接受的时，在步骤S1504中用表示安装是可接受的信息来更新包含在安装管理表1000中的安装要求确认结果1004。另一方面，当至少一个确认安装要求的处理的结果表示安装是不可接受的时，在步骤S1521中，平台部13将表示安装是不可接受的信息通知给外部接口125，并且通过外部接口125请求来自用户的指示。之后，在步骤S1521中，平台部13确认通过外部接口125发来的用户输入的指示(也就是说，平台部13确定是否要继续安装处理)。当确定要继续安装处理时，在步骤S1504中，平台部13用表示安装是不可接受的信息来更新包含在安装管理表1000中的针对不能安装的应用的安装要求确认结果1004。另一方面，当确定不继续安装处理时，在步骤S1531中，中断安装处理。

在步骤S1505中，平台部13对应用包1100解密。

随后，平台部13仅对在所生成的安装管理表1000中登记的应用中的、与表示安装是可接受的安装要求确认结果1004相对应的应用进行下述操作。

平台部13确定应用包1100是否在除了应用3之外的区域中存储了要处理的其中一个应用3的最终用户许可协议的副本。当确定结果是肯定的时，在步骤S1506中，平台部13获得最终用户许可协议321的副本。另一方面，当确定结果是否定的时，在步骤S1509中，平台部13用表示无关性的信息来更新包含在安装管理表1000中的许可协议结果1005。当应用包1100存储了副本时，在步骤S1508中，平台部13将获得的最终用户许可协议321发送给外部接口125。然后，在步骤S1508中，平台部13通过外部接口125从用户接收表示用户接受所通知的最终用户许可协议321的信息或表示用户不接受所通知的最终用户许可协议321的信息。当用户接受最终用户许可协议321时，在步骤S1509中，用表示用户接受所有应用3的安装的信息来更新包含在安装管理表1000中的许可协议结果1005。也就是说，当通过外部接口125获得了表示用户接受最终用户许可协议321的信息时，由表示接受的信息来更新许可协议结果1005。在更新之后，通过步骤S1511、步骤S1512以及步骤S1514的操作来安装要处理的应用。

另一方面，当接收到表示用户不接受最终用户许可协议321的信息时，在步骤S1522中，平台部13通过外部接口125提示用户确定是否要继续安装处理。当确定要继续安装处理时，在步骤S1509中，平台部13用表示不认可的信息来更新包含在安装管理表1000中的许可协议结果1005。另一方面，当确定不继续安装处理时，在步骤S1531中，中断安装处理。

然后，在步骤S1510中，平台部13仅对在安装管理表1000中登记的所有应用3中的、“其安装要求确认结果1004与表示安装是可接受的信息相对应”的应用重复进行上述操作。

之后，平台部13对在安装管理表1000中登记的所有应用3中的、“其安装要求确认结果1004与表示安装是可接受的信息相对应”且“其许可协议结果1005与表示无关性的信息或表示接受的信息相对应”的应用3进行下述操作。

在步骤S1512中，平台部13对加密的应用3中的一个进行解密。在步骤S1513中，安装包含在应用3中的应用程序322。在步骤S1514中，重复地进行操作直到安装了包含在要处理的所有应用3中的应用程序322为止，然后，结束安装处理。

以下将详细描述步骤S1513中的操作。

首先，在步骤S1513中，安装“在步骤S1509中用表示接受的信息来更新其许可协议结果1005的应用”中的一个应用中包含的应用程序。请注意，不安装“在步骤S1509中没有用表示接受的信息更新其许可协议结果1005的应用”中包含的应用程序。

此外，请注意，在步骤S1513中忽略在步骤S1512中通过对多个应用3解密获得的许可协议结果1005。这是因为，对于许可协议，已经在步骤S1509和步骤S1510中确认了最终用户许可协议321的副本。

用于确认包安装要求的方法

现在将对平台部13进行的在安装处理中确认包安装要求的方法进行说明。

平台部13通过将关于应用包定义1103的信息、关于平台部13的信息以及关于图像处理设备12的信息相互比较来确认安装要求。具体地说，使用在应用包定义1103中定义的安装接受平台1204和期望消耗资源大小1205。

假设平台程序的版本是第二版本并且图像处理设备12的间接存储单元123的剩余大小是100MB，此外，还假设唯一ID为“#####0000000000”并且设备中提供的功能的唯一ID表示“打印功能的版本是第一版本，扫描功能的版本是第一版本或第二版本”，按如下所述来进行确定。

当要安装应用包1100的安装接受平台1204的平台程序的版本是第一版本时，平台部13确定包含在包许可1300中的所有应用3都不能被安装。也就是说，根据平台程序的版本是否对应于能够安装应用3的平台的版本来进行确定。

此外，当应用3的期望消耗资源大小1205(即应用3要消耗的间接存储单元123中的区域的大小)为120MB时，平台部13确定不安装包含在包许可1300中的应用3。也就是说，根据设备是否具有等于或大于应用3要消耗的资源的剩余资源来进行确定。

当包括应用包1100的设备的唯一ID为“#####0000000001”时，平台部13确定不安装包含在包许可1300中的应用3。也就是说，根据唯一ID是否对应于能够安装应用3的设备的唯一ID来进行确定。

此外，当应用包1100的功能的唯一ID表示“打印功能的第二版本”时，平台部13确定不安装应用3。也就是说，根据设备是否具有安装的功能来进行确定。

此外，当确定不能安装包含在应用包1100中应用3时，平台部13进行下述操作。也就是说，确定根据包含在应用包定义1103中的应用定义311是否能够个别地安装包含在应用包1100中的应用3。

如上所述，平台部13通过将在应用包定义1103中定义的信息与关于设备的信息进行比较来确定安装是否是可接受的。

如上所述，根据第二示例性实施例，当安装应用包时，能够在安装处理的第一阶段集中进行确认安装要求的操作、确认许可的操作以及接受最终用户许可协议的操作。此外，由于生成了应用包定义和包许可信息，所以改进了确认安装要求的操作的实行和确认许可的操作的实行。这样，避免了例如在安装处理期间由于需要输入表示接受最终用户许可协议的指示以及表示继续安装处理的指示的操作而使安装处理变复杂。因此，改进了安装处理的实行。

根据上述的示例性实施例，从应用中提取包含在多个加密应用中的最终用户许可协议。因此，从用户获得最终用户许可协议的接受而不用对多个加密应用进行解密。也就是说，能够在早期阶段从用户获得最终用户许可协议的接受，因此，顺利地进行安装处理。

因此，不用发出请求针对最终用户许可协议的接受而进行的输入操作的通知。此外，在安装处理的中间阶段(或最后阶段)也不用发出这种通知。如果在中间阶段(或最后阶段)发出请求用户操作的这种通知，则处理会变得复杂。这是因为，为了进行操作，用户应当在安装处理开始之后一直等到中间阶段(或最后阶段)。

当使用(1)使计算机进行上述流程图中的操作的程序和(2)存储该程序的计算机可读存储介质时所获得的效果，与当使用(3)执行上述流程图的操作的设备和(4)用于使设备执行上述流程图的操作的方法时所获得的效果一样。因此，尽管省略了对(1)程序和(2)计算机可读存储介质的说明，(1)程序和(2)计算机可读存储介质也包含在本发明中。

作为“与在安装包含在应用中的应用程序之前通过接口请求用户输入指示的操作相关的数据”的示例，本文中描述了最终用户许可协议和应用定义。然而，最终用户许可协议和应用定义仅是示例。本文中描述的流程图不仅适用于最终用户许可协议和应用定义，还适用用于其他“与在安装包含在应用中的应用程序之前通过接口请求用户输入指示的操作相关的数据”。

请注意，最终用户许可协议是用来在安装包含在应用中的应用程序之前通过接口请求用户的认可的数据。因此，最终用户许可协议对应于“与在安装包含在应用中的应用程序之前通过接口请求用户输入指示的操作相关的数据”。

此外，当确定安装要求确认处理的结果表示安装是否是可接受的时使用应用定义。当确定安装是不可接受的时，通过接口请求用户进行输入指示的操作(步骤S921和S1521)。因此，应用定义是当确定是否通过接口请求用户进行输入指示的操作时所需的数据。因此，应用定义也对应于“与在安装包含在应用中的应用程序之前通过接口请求用户输入指示的操作相关的数据”。

尽管参照示例性实施例对本发明进行了说明，然而应理解的是，本发明不限于所公开的示例性实施例。应对下述权利要求的范围给予最宽泛的解释，从而包括所有变型例、等同结构和功能。

Claims

1.一种应用打包设备的控制装置，该应用打包设备用于生成要在另一设备中安装的应用包，该另一设备在安装应用之前请求接受所述应用的最终用户许可协议，该控制装置包括：

解密单元，其被配置为逐个地解密多个应用，所述多个应用中的各个均包括最终用户许可协议；

复制单元，其被配置为复制包含在各个解密的应用中的所述最终用户许可协议；以及

应用包生成单元，其被配置为通过将各个最终用户许可协议的副本和加密的应用打包来生成应用包。

2.根据权利要求1所述的控制装置，其中在所述应用包生成单元生成的所述应用包中，来自所述解密的应用的所述最终用户许可协议的副本被包括在所述应用包的、与包括所述加密的应用的区域不同的区域中。

3.根据权利要求2所述的控制装置，

其中，所述应用包生成单元还加密所述各个最终用户许可协议的副本。

4.根据权利要求2所述的控制装置，

其中，所述应用包生成单元计算在所述解密的应用中包括的应用定义来生成应用包定义，以使得通过所述计算获得的所述应用包定义被包括在所述包的、与对应于所述加密的应用的区域不同的区域中。

5.根据权利要求4所述的控制装置，

其中，所述应用包生成单元根据所述解密的应用中包括的所述应用定义中包含的信息项的类型，确定是使用加法还是乘法来计算所述应用定义中包含的各个信息项，以生成所述应用包定义。

6.一种应用安装设备的控制装置，该控制装置包括：

第一获得单元，其被配置为在根据权利要求2的所述控制装置生成的应用包中包括的多个加密的应用被解密之前，从所述应用包的、与包括所述加密的应用的区域不同的包括协议的区域中获得最终用户许可协议；以及

安装单元，其被配置为当通过接口从用户获得对各个最终用户许可协议的接受时，安装所述应用。

7.根据权利要求6所述的控制装置，该控制装置还包括：

第二获得单元，其被配置为在根据权利要求4的所述控制装置生成的应用包中包括的多个加密的应用被解密之前，从所述应用包的、与包括所述加密的应用的区域不同的区域中获得应用包定义；以及

确定单元，其被配置为根据在将所述加密的应用进行解密之前所获得的应用包定义，确定在所述应用包中包括的所有所述应用是否都是可安装的。

8.根据权利要求6所述的控制装置，该控制装置被设置为：根据包括所述应用定义和许可的信息，生成安装管理表。

9.根据权利要求8所述的控制装置，其中，该控制装置被设置为：在根据所获得的应用包定义作出关于所述应用包中包括的所有所述应用是否都是可安装的确定之前，检测是否获得了对各个许可的认可。

10.根据权利要求6所述的控制装置，其中，该控制装置被设置为：忽略在所述加密的应用中包括的最终用户许可协议。

11.一种应用打包设备的控制方法，该应用打包设备用于生成要在另一设备中安装的应用包，该另一设备在安装应用之前请求接受所述应用的最终用户许可协议，该控制方法包括如下步骤：

逐个地解密多个应用，所述多个应用中的各个均包括最终用户许可协议；

复制各个最终用户许可协议；以及

将所述各个最终用户许可协议的副本与加密的应用打包，来生成应用包。

12.一种应用安装设备的控制方法，该控制方法包括如下步骤：

在将根据权利要求2的所述控制装置生成的应用包中包括的多个加密的应用进行解密之前，从所述应用包的、与包括所述加密的应用的区域不同的包括协议的区域中获得最终用户许可协议；以及

当通过接口从用户获得对各个最终用户许可协议的接受时安装所述应用。