CN115080928A - 应用授权管理方法及相关设备 - Google Patents

Abstract

本申请关于一种应用授权管理方法及相关设备，涉及软件技术领域。本申请中，应用商店至少包括第一应用和第二应用，应用商店可以建立第一应用和第二应用的关联关系。第二应用能够调用第一应用以实现第一应用的功能。本申请可以对第一应用和第二应用一并进行授权管理，实现对第一应用和第二应用的授权加锁。

Description

应用授权管理方法及相关设备

技术领域

本申请涉及软件技术领域，尤其涉及一种应用授权管理方法及相关设备。

背景技术

应用程序(application，APP)也称应用，是指为完成某项或多项特定工作的计算机程序，可以运行在用户模式和用户进行交互，可以具有可视的用户界面。应用的开发者可以将开发好的应用上架到应用商店中，需要使用APP的用户可以从应用商店中下载应用。

目前，应用的开发者在开发应用时，可以为应用添加授权锁，对应用进行授权加锁。该授权锁一般是指在应用的程序内部植入的授权加密策略。用户在使用应用时，需要先从应用商店购买应用的授权钥匙。该授权钥匙可以用于对应用的程序内部所植入的授权加密策略进行授权解锁。应用在检测到授权钥匙后，才可以正常运行，供用户使用。

但是，目前的应用授权加锁方式均是在整个应用的层面对应用进行授权加锁，一个完整的应用一般只有一个授权锁。部分场景中，一个完整的应用可能包含多个子应用，针对这种场景，现有的应用授权管理方式并不适用，无法实现对完整的应用及其中的每个子应用进行授权加锁。

发明内容

本申请提供一种应用授权管理方法及相关设备，可以实现对具有关联关系的应用一并进行授权管理。本申请的技术方案如下：

第一方面，本申请提供一种应用授权管理方法，所述方法包括：接收授权请求，授权请求用于请求从应用商店中下载的第二应用的授权权限，第二应用与第一应用具有关联关系，第二应用能够调用第一应用以实现第一应用的功能。响应于授权请求，发送第一钥匙以及第二钥匙。

其中，第一应用具有第一授权锁，第一授权锁用于对第一应用进行授权加锁，第一钥匙用于解除对第一应用的授权加锁。第二应用具有第二授权锁，第二授权锁用于对第二应用进行授权加锁，第二钥匙用于解除对第二应用的授权加锁。

一些实现方式中，第一应用包括第一标识，第一标识用于标识第一应用进行了授权加锁；第二应用包括第二标识，第二标识用于标识第二应用进行了授权加锁。

一些实现方式中，用于授权加锁的授权锁包括：授权字段，授权字段用于标识授权锁具有控制应用的授权时间的功能；授权锁对应的钥匙包括：钥匙的有效使用时间。

一些实现方式中，用于授权加锁的授权锁包括以下一种或多种：使用授权锁授权加锁的应用的标识、授权锁的标识、以及授权类型；授权类型包括免费和收费。

一些实现方式中，授权锁对应的钥匙包括以下一种或多种：钥匙的标识、钥匙对应的授权锁的标识、使用钥匙对应的授权锁授权加锁的应用的标识。

可选地，第一应用是由第一应用的版权所有者采用第一授权锁进行授权加锁的；第二应用是由第二应用的版权所有者采用第二授权锁进行授权加锁的。

可选地，第一应用和第二应用的版权所有者相同或不同。

可选地，第一应用和第二应用的开发者相同或不同。

一些实现方式中，第二应用中包括第一信息，第一信息用于指示与第二应用关联的第一应用。

可选地，第一信息包括第一应用的标识；应用商店中的不同应用的标识不同。

一些实现方式中，第二应用还与从应用商店中下载的第三应用具有关联关系，能够调用第三应用以实现第三应用的功能；第三应用未被授权加锁。

第二方面，本申请提供一种应用授权管理装置，所述装置包括：接收模块，用于接收授权请求，授权请求用于请求从应用商店中下载的第二应用的授权权限，第二应用与第一应用具有关联关系，第二应用能够调用第一应用以实现第一应用的功能；发送模块，用于响应于授权请求，发送第一钥匙以及第二钥匙。

其中，第一应用具有第一授权锁，所第一授权锁用于对从应用商店中下载的第一应用进行授权加锁，第一钥匙用于解除对第一应用的授权加锁。第二应用具有第二授权锁，第二授权锁用于对第二应用进行授权加锁，第二钥匙用于解除对第二应用的授权加锁。

一些实现方式中，第一应用包括第一标识，第一标识用于标识第一应用进行了授权加锁；第二应用包括第二标识，第二标识用于标识第二应用进行了授权加锁。

一些实现方式中，用于授权加锁的授权锁包括：授权字段，授权字段用于标识授权锁具有控制应用的授权时间的功能；授权锁对应的钥匙包括：钥匙的有效使用时间。

一些实现方式中，用于授权加锁的授权锁包括以下一种或多种：使用授权锁授权加锁的应用的标识、授权锁的标识、以及授权类型；授权类型包括免费和收费。

一些实现方式中，授权锁对应的钥匙包括以下一种或多种：钥匙的标识、钥匙对应的授权锁的标识、使用钥匙对应的授权锁授权加锁的应用的标识。

可选地，第一应用是由第一应用的版权所有者采用第一授权锁进行授权加锁的；第二应用是由第二应用的版权所有者采用第二授权锁进行授权加锁的。

可选地，第一应用和第二应用的版权所有者相同或不同。

可选地，第一应用和第二应用的开发者相同或不同。

一些实现方式中，第二应用中包括第一信息，第一信息用于指示与第二应用关联的第一应用。

可选地，第一信息包括第一应用的标识；应用商店中的不同应用的标识不同。

一些实现方式中，第二应用还与从应用商店中下载的第三应用具有关联关系，能够调用第三应用以实现第三应用的功能；第三应用未被授权加锁。

第三方面，本申请提供一种电子设备，如电子设备可以是上述第一方面中所述的应用商店对应的硬件设备。电子设备包括：处理器，用于存储处理器可执行指令的存储器；处理器被配置为执行所述指令时，使得电子设备实现如第一方面及第一方面的任意一种可能的实现方式所述的方法。

第四方面，本申请提供一种计算机可读存储介质，其上存储有计算机程序指令；当所述计算机程序指令被电子设备执行时，使得电子设备实现如第一方面及第一方面的任意一种可能的实现方式所述的方法。

第五方面，本申请提供一种计算机程序产品，包括计算机可读代码，或者承载有计算机可读代码的非易失性计算机可读存储介质，当所述计算机可读代码在电子设备中运行时，所述电子设备中的处理器实现如第一方面及第一方面的任意一种可能的实现方式所述的方法。

第六方面，本申请提供一种应用授权管理方法，所述方法包括：发送授权请求，授权请求用于请求从应用商店中下载的第二应用的授权权限，第二应用与第一应用具有关联关系，第二应用能够调用第一应用以实现第一应用的功能。接收第一钥匙以及第二钥匙。

其中，第一应用具有第一授权锁，第一授权锁用于对从应用商店中下载的第一应用进行授权加锁，第一钥匙用于解除对第一应用的授权加锁。第二应用具有第二授权锁，第二授权锁用于对第二应用进行授权加锁，第二钥匙用于解除对第二应用的授权加锁。

一些实现方式中，第一应用包括第一标识，第一标识用于标识第一应用进行了授权加锁；第二应用包括第二标识，第二标识用于标识第二应用进行了授权加锁。

一些实现方式中，用于授权加锁的授权锁包括：授权字段，授权字段用于标识授权锁具有控制应用的授权时间的功能；授权锁对应的钥匙包括：钥匙的有效使用时间。

一些实现方式中，用于授权加锁的授权锁包括以下一种或多种：使用授权锁授权加锁的应用的标识、授权锁的标识、以及授权类型；授权类型包括免费和收费。

一些实现方式中，授权锁对应的钥匙包括以下一种或多种：钥匙的标识、钥匙对应的授权锁的标识、使用钥匙对应的授权锁授权加锁的应用的标识。

可选地，第一应用是由第一应用的版权所有者采用第一授权锁进行授权加锁的；第二应用是由第二应用的版权所有者采用第二授权锁进行授权加锁的。

可选地，第一应用和第二应用的版权所有者相同或不同。

可选地，第一应用和第二应用的开发者相同或不同。

一些实现方式中，第二应用中包括第一信息，第一信息用于指示与第二应用关联的第一应用。

可选地，第一信息包括第一应用的标识；应用商店中的不同应用的标识不同。

一些实现方式中，第二应用还与从应用商店中下载的第三应用具有关联关系，能够调用第三应用以实现第三应用的功能；第三应用未被授权加锁。

第七方面，本申请提供一种应用授权管理装置，所述装置包括：发送模块，用于发送授权请求，授权请求用于请求从应用商店中下载的第二应用的授权权限，第二应用与第一应用具有关联关系，第二应用能够调用第一应用以实现第一应用的功能。接收模块，用于接收第一钥匙以及第二钥匙。

其中，第一应用具有第一授权锁，第一授权锁用于对从应用商店中下载的第一应用进行授权加锁，第一钥匙用于解除对第一应用的授权加锁。第二应用具有第二授权锁，第二授权锁用于对第二应用进行授权加锁，第二钥匙用于解除对第二应用的授权加锁。

一些实现方式中，第一应用包括第一标识，第一标识用于标识第一应用进行了授权加锁；第二应用包括第二标识，第二标识用于标识第二应用进行了授权加锁。

一些实现方式中，用于授权加锁的授权锁包括：授权字段，授权字段用于标识授权锁具有控制应用的授权时间的功能；授权锁对应的钥匙包括：钥匙的有效使用时间。

一些实现方式中，用于授权加锁的授权锁包括以下一种或多种：使用授权锁授权加锁的应用的标识、授权锁的标识、以及授权类型；授权类型包括免费和收费。

一些实现方式中，授权锁对应的钥匙包括以下一种或多种：钥匙的标识、钥匙对应的授权锁的标识、使用钥匙对应的授权锁授权加锁的应用的标识。

可选地，第一应用是由第一应用的版权所有者采用第一授权锁进行授权加锁的；第二应用是由第二应用的版权所有者采用第二授权锁进行授权加锁的。

可选地，第一应用和第二应用的版权所有者相同或不同。

可选地，第一应用和第二应用的开发者相同或不同。

一些实现方式中，第二应用中包括第一信息，第一信息用于指示与第二应用关联的第一应用。

可选地，第一信息包括第一应用的标识；应用商店中的不同应用的标识不同。

一些实现方式中，第二应用还与从应用商店中下载的第三应用具有关联关系，能够调用第三应用以实现第三应用的功能；第三应用未被授权加锁。

第八方面，本申请提供一种电子设备，包括：处理器，用于存储处理器可执行指令的存储器；处理器被配置为执行所述指令时，使得电子设备实现如第六方面及第六方面的任意一种可能的实现方式所述的方法。

第九方面，本申请提供一种计算机可读存储介质，其上存储有计算机程序指令；当所述计算机程序指令被电子设备执行时，使得电子设备实现如第六方面及第六方面的任意一种可能的实现方式所述的方法。

第十方面，本申请提供一种计算机程序产品，包括计算机可读代码，或者承载有计算机可读代码的非易失性计算机可读存储介质，当所述计算机可读代码在电子设备中运行时，所述电子设备中的处理器实现如第六方面及第六方面的任意一种可能的实现方式所述的方法。

基于上述第一方面至第十方面中的任一方面，本申请至少具备如下有益效果：本申请中可以适用于个完整的应用包含多个子应用的场景(或称为一个完整的应用与多个子应用进行关联的场景)。对于某个第二应用而言，第二应用与第一应用具有关联关系，能够调用所述第一应用以实现所述第一应用的功能，则第一应用可以认为是第二应用的子应用。本申请可以实现分别对第二应用和第一应用进行授权。第二应用和第一应用分别具有授权锁，如第一应用具有第一授权锁，第二应用具有第二授权锁。当用户请求获取第二应用的授权权限时，应用商店可以将第二应用的授权钥匙(如第二钥匙)与第一应用的授权钥匙(如第一钥匙)一并打包下发给用户设备，实现对第一应用和第二应用共同进行授权。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本申请。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理，并不构成对本申请的不当限定。

图1为本申请实施例提供的应用授权管理方法的流程示意图；

图2为本申请实施例提供的一种应用的预定义的组成示意图；

图3为本申请实施例提供的应用授权管理方法的另一流程示意图；

图4为本申请实施例提供的应用授权管理方法的又一流程示意图；

图5为本申请实施例提供的模型和预定义的关系示意图；

图6为本申请实施例提供的数据模型的示意图；

图7为本申请实施例提供的第二应用的APP模型的组成示意图；

图8为本申请实施例提供的一种应用管理系统的组成示意图；

图9为本申请实施例提供的一种应用管理系统的另一组成示意图；

图10为本申请实施例提供的成品APP和零件APP的钥匙和授权锁的传输流程示意图；

图11为本申请实施例提供的应用授权管理装置的结构示意图；

图12为本申请实施例提供的应用授权管理装置的结构示意图。

具体实施方式

为了使本领域普通人员更好地理解本申请的技术方案，下面将结合附图，对本申请实施例中的技术方案进行清楚、完整地描述。

需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。还应当理解的是，术语“包括”指示所描述特征、整体、步骤、操作、元素和/或组件的存在，但并不排除一个或多个其他特征、整体、步骤、操作、元素和/或组件的存在或添加。

应用程序(application，APP)也称应用，是指为完成某项或多项特定工作的计算机程序，可以运行在用户模式和用户进行交互，可以具有可视的用户界面。

应用的开发者可以将开发好的应用上架到应用商店中，需要使用APP的用户可以从应用商店中下载应用。其中，应用商店可以在服务器、计算机等硬件设备上实现，也可以为用户提供一个可以交互的应用商店界面，供用户下载需要的应用。

例如，在工业相关场景中，可以基于服务器、计算机等硬件设备构建一个工业互联网平台，该工业互联网平台即前述应用商店。应用的开发者可以将开发好的应用上架到工业互联网平台中，需要使用应用的用户可以从工业互联网平台中下载使用应用。

目前，应用的开发者在开发应用时，可以为应用添加授权锁，对应用进行授权加锁。该授权锁一般是指在应用的程序内部植入的授权加密策略。用户在使用应用时，需要先从应用商店购买应用的授权钥匙。该授权钥匙可以用于对应用的程序内部所植入的授权加密策略进行授权解锁。应用在检测到授权钥匙后，才可以正常运行，供用户使用。

但是，目前的应用授权加锁方式均是在整个应用的层面对应用进行授权加锁，一个完整的应用一般只有一个授权锁。部分场景中，一个完整的应用可能包含多个子应用，针对这种场景，现有的应用授权管理方式并不适用，无法实现对完整的应用及其中的每个子应用进行授权加锁。

另外，由于目前的授权锁一般是指在应用的程序内部植入的授权加密策略，所以在应用已经上架到应用商店后，应用的开发者也不便在对授权加密策略进行调整。如果要对授权加密策略进行调整，可能会影响到应用的业务逻辑，需要重新上架应用。

基于此，本申请实施例提供了一种应用授权管理方法，该方法可以适用于个完整的应用包含多个子应用的场景(或称为一个完整的应用与多个子应用进行关联的场景)。例如，对于某个第二应用而言，第二应用与第一应用具有关联关系，能够调用所述第一应用以实现所述第一应用的功能，则第一应用可以认为是第二应用的子应用。该方法可以实现分别对第二应用和第一应用进行授权。第二应用和第一应用分别具有授权锁，如第一应用具有第一授权锁，第二应用具有第二授权锁。当用户请求获取第二应用的授权权限时，应用商店可以将第二应用的授权钥匙(如第二钥匙)与第一应用的授权钥匙(如第一钥匙)一并打包下发给用户设备，实现对第一应用和第二应用共同进行授权加锁。

另外，本申请实施例提供的应用授权管理方法中，每个应用的授权锁是独立在应用的程序之外的，并不是在应用的程序内部植入的授权加密策略。在应用已经上架到应用商店后，应用的授权锁还可以被进行调整(如取消或改变等)。在调整授权锁时，并不会影响到应用的业务逻辑，可以保证应用的功能稳定性。

示例性地，该方法具体可以在应用商店对应的硬件设备上实现，如：硬件设备可以包括服务器、计算机等。其中，服务器可以是单独的一个服务器，或者，也可以是由多个服务器构成的服务器集群。部分实施方式中，服务器集群还可以是分布式集群。本申请对应用商店对应的硬件设备的具体实现方式不作限制。需要说明的是，本申请实施例中涉及到的应用商店侧实现步骤，均可以是由应用商店对应的硬件设备来实现。

图1为本申请实施例提供的应用授权管理方法的流程示意图。如图1所示，该应用授权管理方法可以包括：

S101、接收授权请求，授权请求用于请求从应用商店中下载的第二应用的授权权限。

第二应用与第一应用具有关联关系，第二应用能够调用第一应用以实现第一应用的功能。

S102、响应于授权请求，发送第一第一钥匙以及第二钥匙。

其中，第一应用具有第一授权锁，第一授权锁用于对从应用商店中下载的第一应用进行授权加锁，第一钥匙用于解除对第一应用的授权加锁；第二应用具有第二授权锁，第二授权锁用于对第二应用进行授权加锁，第二钥匙用于解除对第二应用的授权加锁。

例如，应用商店至少可以包括第一应用和第二应用。第二应用能够调用第一应用以实现第一应用的功能。如，第一应用可以实现的功能为第一功能，则第二应用中不包括用于实现第一功能的代码，也可以通过调用第一应用的方式实现第一功能。第一应用和第二应用之间可以建立关联关系，用户可以使用用户设备(如手机、电脑等)向应用商店发送下载第二应用的请求。应用商店可以响应于该请求，向用户设备下发第二应用，同时，由于第二应用和第一应用之间建立了关联关系，所以应用商店可以基于该关联关系一并向用户设备下发第一应用。当用户设备运行下载后的第二应用时，第二应用可以调用下载的第一应用实现第一应用的功能。

在本申请中，第一应用可以认为是第二应用的子应用，但第一应用的代码又是独立在第二应用之外的。在应用商店中，第二应用和第一应用是分散独立存储的。这种分散独立存储的关系可以有效节省应用所占据的应用商店的存储资源。

用户设备从应用商店下载第二应用之后，当用户设备需要运行(非试运行)第二应用时，可以向应用商店发送授权请求以获取第二应用的授权权限。即S101中应用商店可以接收来自用户设备的授权请求，授权请求用于请求从应用商店中下载的第二应用的授权权限。

可选地，授权请求可以包含第二应用的标识，第二应用的标识用于指示授权请求用于请求从应用商店中下载的第二应用的授权权限。

如上所述，当第二应用被下载时，应用商店能够将第二应用和第一应用一并进行下发。第一应用具有第一授权锁，第二应用具有第二授权锁。例如，应用商店下发第一应用相关的信息中可以包括第一应用的程序以及第一授权锁，应用商店下发第二应用相关的信息中可以包括第二应用的程序以及第二授权锁。S102中，应用商店可以响应于授权请求，向用户设备发送第一钥匙以及第二钥匙，即将第一应用的授权钥匙与第二应用的授权钥匙一并下发。

当用户设备接收到第一钥匙以及第二钥匙后，在运行第二应用时，第二应用可以检测到第二授权锁和第二钥匙而正常创建运行实例。第二应用可以调用第一应用以实现第一应用的功能，第一应用可以检测到第一授权锁和第一钥匙而正常创建运行实例。

可以看到，本申请实施例提供的应用授权管理方法可以实现分别对第二应用和第一应用进行授权。当用户请求获取第二应用的授权权限时，应用商店可以将第二应用的授权钥匙(如第二钥匙)与第一应用的授权钥匙(如第一钥匙)一并打包下发给用户设备，实现对第一应用和第二应用共同进行授权。

可选地，对第一应用和第二应用而言，每个应用的授权锁是独立在应用的程序之外的，并不是在应用的程序内部植入的授权加密策略。在应用已经上架到应用商店后，应用的授权锁还可以被进行调整(如取消或改变等)。在调整授权锁时，并不会影响到应用的业务逻辑，可以保证应用的功能稳定性。

一些实现方式中，第一应用包括第一标识，第一标识用于标识第一应用进行了授权加锁；第二应用包括第二标识，第二标识用于标识第二应用进行了授权加锁。

示例性地，第一应用的预定义上可以有一个字段来标记第一应用是否进行了授权加锁，该字段即第一标识。第二应用的预定义上也可以有一个字段来标记第二应用是否进行了授权加锁，该字段即第二标识。用户设备在运行第二应用时，可以基于第二标识来判断是否需要向应用商店发送授权请求，以获取第二应用的授权权限。如用户设备在检测到第二标识时，可以向用户展示提示信息，提示用户进行获取第二应用的授权权限的操作，用户设备可以响应于该操作向应用商店发送授权请求。应用商店接收到授权请求后，可以分别基于第二标识和第一标识，确定需要向用户设备返回的第二授权锁和第二钥匙，以及第一授权锁和第一钥匙。如果第一应用没有第一标识，则表示第一应用没有进行授权加锁，应用商店不需要向用户设备发送第一授权锁和第一钥匙。

例如，图2为本申请实施例提供的一种应用的预定义的组成示意图。该应用可以是第一应用或第二应用。以图2所示的为第一应用的预定义为例，如图2所示，第一应用的预定义可以包括：名称、描述、GUID、模型GUID+版本、加锁状态等字段，其中字段“加锁状态”即第一标识，表示第一应用进行了授权加锁。

其中，名称、描述、GUID、模型GUID+版本等字段的含义将在下文的实施例中详细介绍。

第二应用的预定义与第一应用的预定义类似，不再赘述。

一些实现方式中，用于授权加锁的授权锁(如第一授权锁、第二授权锁)包括：授权字段，授权字段用于标识授权锁具有控制应用的授权时间的功能；授权锁对应的钥匙包括：钥匙的有效使用时间。

以第一授权锁为例，第一授权锁中可以包括第一授权字段，第一授权字段用于标识第一授权锁具有控制应用的授权时间的功能。第一授权锁对应的第一钥匙包括：第一钥匙的有效使用时间。假设第一钥匙的有效使用时间为一个月，则表示第一授权锁和第一钥匙可以对第一应用进行一个月的有效授权，在一个月后，第一钥匙失效，第一应用无法再创建运行实例。

一些实现方式中，用于授权加锁的授权锁包括以下一种或多种：使用授权锁授权加锁的应用的标识、授权锁的标识、以及授权类型；授权类型包括免费和收费。授权锁对应的钥匙包括以下一种或多种：钥匙的标识、钥匙对应的授权锁的标识、使用钥匙对应的授权锁授权加锁的应用的标识。

以第一授权锁为例，第一授权锁可以包括使用第一授权锁授权加锁的第一应用的标识(如第一应用的预定义的标识)、第一授权锁的标识(如授权锁ID)、授权类型(如免费或收费)等。第一授权锁对应的第一钥匙可以包括：第一钥匙的标识、第一钥匙对应的第一授权锁的标识、使用第一钥匙对应的第一授权锁授权加锁的第一应用的标识等。

可选地，一个授权锁可以产生多把授权钥匙，在此不作限制。

可选地，本申请实施例中，第一应用和第二应用的版权所有者可以相同或不同，第一应用和第二应用的开发者也可以相同或不同。

例如，第一应用的开发者为开发组织1，第二应用的开发者为开发组织2，但第一应用和第二应用版权所有者均为单位A。或者，第一应用的开发者为开发组织1、版权所有者为单位A，第二应用的开发者为开发组织2、版权所有者均为单位B。又或者，第一应用的版权所有者为单位A，第二应用的版权所有者均为单位B，但第一应用和第二应用开发者均为开发组织1。

可选地，本申请实施例中，第一应用和第二应用可以是由各自的版权所有者上架到应用商店的，也可以是由各自的开发者上架到应用商店的，在此不作限制。

一些实现方式中，第一应用是由第一应用的版权所有者采用第一授权锁进行授权加锁的；第二应用是由第二应用的版权所有者采用第二授权锁进行授权加锁的。例如。第一应用是由单位A采用第一授权锁进行授权加锁的；第二应用是由单位B采用第二授权锁进行授权加锁的。

可选地，应用商店中可以包括每个应用对应的开发者的信息和版权所有者的信息，如：开发者的团队名称，版权所有者的单位名称、地址等。

一些实现方式中，第二应用还与从应用商店中下载的第三应用具有关联关系，能够调用第三应用以实现第三应用的功能；当第三应用未被授权加锁，响应于授权请求，发送第一钥匙以及第二钥匙；当第三应用被授权加锁，响应于授权请求，发送第一钥匙、第二钥匙以及第三钥匙，第三钥匙用于解除对第三应用的授权加锁。例如，第三应用的授权锁可以时第三授权锁。

以上实施例从应用商店的角度介绍了本申请实施例提供的应用授权管理方法。对应于前述实施例，本申请实施例还提供了一种应用授权管理方法，可以应用于用户设备。

示例性地，图3为本申请实施例提供的应用授权管理方法的另一流程示意图。如图3所示，该应用授权管理方法可以包括：

S301、发送授权请求，授权请求用于请求从应用商店中下载的第二应用的授权权限。

第二应用与第一应用具有关联关系，第二应用能够调用第一应用以实现第一应用的功能。

S302、接收第一钥匙以及第二钥匙。

其中，第一应用具有第一授权锁，第一授权锁用于对从应用商店中下载的第一应用进行授权加锁，第一钥匙用于解除对第一应用的授权加锁。第二应用具有第二授权锁，第二授权锁用于对第二应用进行授权加锁，第二钥匙用于解除对第二应用的授权加锁。

该应用于用户设备的应用授权管理方法与前述实施例提供的应用于应用商店的应用授权管理方法完全对应，具体可以参考前述实施例中所述，不再详细描述。

结合图1和图3所示的实施例可以看到，本申请中，应用授权管理的过程实际上会涉及到用户设备和应用商店进行交互的逻辑，基于此，本申请实施例还可以从用户设备与应用商店进行交互的角度给出该应用授权管理的实现。

例如，图4为本申请实施例提供的应用授权管理方法的又一流程示意图。如图4所示，该应用授权管理方法可以包括：

S401、用户设备向应用商店发送授权请求。

授权请求用于请求从应用商店中下载的第二应用的授权权限。

相应地，应用商店接收授权请求。

S402、应用商店向用户设备发送第一钥匙以及第二钥匙。

相应地，用户设备接收第一钥匙以及第二钥匙。

同样的，图4所示的实施例的具体实现可以参考图1所示的实施例中所述，不再赘述。

下面对上述实施例中第一应用和第二应用之间的关联关系的实现进行示例性说明。

一些实现方式中，第二应用中可以包括第一信息，第一信息用于指示与第二应用关联的第一应用。应用商店建立第一应用和第二应用的关联关系，可以包括：基于第二应用中包括的第一信息，建立第一应用和第二应用的关联关系；或者，将第二应用中包括的第一信息作为第一应用和第二应用的关联关系。

可选地，第二应用的开发者在开发第二应用时，可以在第二应用中增加第一应用的标识，或者，增加能够指示第一应用的一些字段。第一应用的标识或者能够指示第一应用的字段即为上述第一信息。也即，第一信息可以包括：第一应用的标识或能够指示第一应用的一些字段。

本申请中，应用商店中的不同应用的标识不同。也即，应用商店中的不同应用具有唯一标识。

一种实现方式中，第一应用和第二应用的开发者相同，开发者可以在本地开发完成第一应用，并根据第一应用开发生成第二应用，然后将第一应用和第二应用上架到应用商店中。

另一种实现方式中，第一应用和第二应用的开发者不同，应用商店可以包括第一应用，开发者可以在从应用商店中获取第一应用，并根据第一应用开发生成第二应用，然后将第二应用上架到应用商店中。

下面以开发者从应用商店中获取第一应用，并根据第一应用开发生成第二应用的方式进行示例性说明。

例如，开发侧的设备可以向应用商店发送下载第一应用的请求。其中，开发侧的设备可以包括开发者所使用的服务器、计算机等。应用商店可以响应于下载第一应用的请求，向开发侧的设备发送第一应用。下载第一应用的请求中可以包括第一应用的标识，应用商店可以基于第一应用的标识找到存储的第一应用下发给开发侧的设备。此时，开发侧的设备可以从应用商店中获取到第一应用。开发人员可以根据第一应用生成第二应用。例如，开发者可以开发第二应用，并在第二应用中添加能够调用第一应用的接口，以使得第二应用能够调用第一应用以实现第一应用的功能。开发完成第二应用后，开发侧的设备可以将第二应用上架到应用商店中。

示例性地，根据第一应用生成第二应用的过程可以如下：

1)创建第二应用的APP模型，并为第二应用的APP模型分配唯一标识(如全球唯一标识)。例如，第二应用的开发者可以在开发工作室中创建第二应用的APP模型。

2)定义第二应用的APP模型依赖的数据模型，发布第二应用的APP模型依赖的数据模型的数据预定义(简称第二应用的数据预定义)到第二应用的系统仓库中，并为第二应用的数据预定义分配唯一标识(如全球唯一标识)；其中，第二应用的系统仓库也即开发第二应用的开发者所使用的系统仓库，第二应用的系统仓库与第二应用的开发者的开发工作室可以通过网络连接。

模型是在建模抽象时描述对象结构的信息，预定义是确定了结构的模型并配置有参数的信息。预定义上记录了模型的信息，预定义用来实例化对象，实例化对象是按照其模型的结构构建对象的结构，并把参数值作为对象的初始值。预定义也能被其他模型引用为子预定义。

例如，创建数据模型时，操作可以包括：新建模型，分配名字和标识；添加成员，指定成员类型；删除成员；添加或删除子预定义；设置子预定义的初值；更新模型版本；发布某模型版本生成预定义等。创建预定义时，操作可以包括：指定某模型版本发布(创建)预定义；分配名称和标识；设置预定义的参数值(属性和成员)等。

图5为本申请实施例提供的模型和预定义的关系示意图。如图5所示，模型可以包括基本属性和成员列表；基本属性可以包括名称、描述、全局唯一标识符(globally uniqueidentifier,GUID)、版本等信息；成员列表可以包括：“成员1：名称+类型”、“成员2：名称+类型”、“成员3：名称+类型”等信息。预定义可以包括基本属性和成员列表；基本属性可以包括名称、描述、GUID、模型GUID+版本等信息；成员列表可以包括：“成员1+值”、“成员2+值”、“成员3+值”等信息。

步骤2)中所述的数据模型是时空数据库中的概念，描述了时空库中数据对象的结构，是客观世界对象的抽象描述。

示例性地，图6为本申请实施例提供的数据模型的示意图。如图6所示，数据模型可以包括：基本属性、成员列表、以及子模型列表。具有子模型的数据模型是复合的数据模型，如：图中的数据模型A为复合的数据模型，数据模型B和数据模型C是数据模型A的子模型。

数据模型中，基本属性描述了数据的固有属性，包括名称、描述、GUID、时间属性(如精度)、空间属性(如坐标系、几何形状)等；成员列表描述了自由定义的字段，每个成员描述其字段名称、数据类型，如：成员1、成员2等。子模型列表中记录了引用为子模型的数据模型的数据预定义的标识，建立了子模型和数据模型之间的依赖关系，例如，数据模型A的子模型列表包括数据模型B和数据模型C的数据预定义的标识，如：“名称B1+引用模型ID+参数值”、“名称B2+引用模型ID+参数值”、“名称C3+引用模型ID+参数值”等。

3)定义第二应用的APP模型依赖的资源对象(简称第二应用的资源对象)到资源库，并为第二应用的资源对象分配唯一标识(如全球唯一标识)。

其中，资源对象是时空数据库中的概念。把二进制文件数据进行对象化组织和管理，为每个资源对象分配标识，第二应用的APP模型能够通过资源对象的标识访问资源对象的数据。例如，把图标定义为资源对象和第二应用的APP模型之间形成依赖关系，则第二应用的APP模型可以使用这个图标。又例如，把视频文件定义为资源对象和第二应用的APP模型之间形成依赖关系，则第二应用的APP模型可以通过依赖关系读取视频文件进行播放。

4)在第二应用的APP模型上建立第二应用的依赖数据预定义列表，从第二应用的系统仓库中选择第二应用的数据预定义，将第二应用的数据预定义的标识记录在第二应用的依赖数据预定义列表上。其中，第二应用的系统仓库中的数据预定义可以是开发者自建的，也可以是从应用商店上购买的。

5)在第二应用的APP模型上建立第二应用的依赖资源列表，从资源库中选择第二应用的资源对象，把第二应用的资源对象的标识记录在第二应用的依赖资源列表上。其中，资源库中的资源对象可以是开发者自建的，也可以是从应用商店上购买的。

6)添加第二应用的APP模型的子APP列表，从第二应用的系统仓库中选择作为子APP的第一应用的预定义，将第一应用的预定义的标识记录在第二应用的APP模型的子APP列表上。第一应用的预定义即S201-S202中从应用商店获取的第一应用。第一应用的预定义的标识即前述实施例中所述的第一应用的标识。第一应用的预定义可以由第一应用的版权所有者或者开发者上传到应用商店中。

7)编写第二应用的APP模型的功能函数的程序逻辑。

8)发布第二应用的APP模型的预定义(简称第二应用的预定义)到第二应用的系统仓库中，并为第二应用的预定义分配唯一标识(如全球唯一标识)。第二应用的预定义的标识即第二应用的标识。其中，发布第二应用的预定义时，还可以设置预定义的参数值(如：属性和成员)。

示例性地，图7为本申请实施例提供的第二应用的APP模型的组成示意图。如图7所示，第二应用的APP模型可以包括：基本属性、依赖数据列表、功能函数列表、以及子APP列表。基本属性可以包括：名称、描述、以及GUID(即第二应用的APP模型的唯一标识)。依赖数据列表记录了第二应用的APP模型需要使用的数据模型或资源对象，在第二应用的APP模型，以及依赖的数据模型或资源对象之间建立了关系。例如，“数据1：数据ID”、“数据2：数据ID”等表示依赖的数据模型的数据预定义的标识或资源对象的标识。依赖数据列表可以包括上述依赖数据预定义列表和/或上述依赖资源列表。功能函数列表可以包括：函数1、函数2等第二应用的APP模型的功能函数，这些功能函数是第二应用的APP模型的程序逻辑的实现。子APP列表中记录了第一应用的信息，在第二应用的APP模型和第一应用之间建立的关联关系。例如，子APP列表可以包括子APP-B1、APP-C2、APP-D3等第一应用的标识和配置参数。也即，APP模型B、APP模型C、以及APP模型D等可以是上述第一应用。

通过上述步骤1)-步骤8)所述的过程，即可实现S203中根据第一应用生成第二应用。

可以理解的，第一应用的开发过程与第二应用的开发过程类似。其区别仅仅在于，当第一应用不包括更深层级的子APP(即第一应用没有调用其他应用实现其他应用的功能)时，第一应用的开发过程中不包括类似于上述步骤6)中所述的过程。当第一应用还包括更深层级的子APP(即第一应用调用其他应用实现其他应用的功能)时，第一应用的开发过程中与上述步骤1)-步骤8)所述的过程一致。在此对第一应用的开发过程不再赘述。

需要说明的是，第二应用和第一应用可能存在依赖同一数据预定义或资源对象的情况，因为依赖关系是在第二应用和第一应用各自开发时建立的，也就是说，第二应用和第一应用的依赖数据列表中可能记录同一数据预定义或资源对象的标识。

示例性地，以第二应用是由第二应用的版权所有者上架到应用商店为例，第二应用的版权所有者将第二应用上架到应用商店的过程如下：

1)第二应用的版权所有者在应用商店中创建将第二应用的APP商品，第二应用的APP商品包括第二应用的预定义的标识。

其中，APP商品是指应用商店中为APP的预定义建立的对应的信息，主要描述APP的预定义的商品化信息。例如，第二应用的APP商品中还可以包括第二应用的图案(logo)、视频、商品定价、产品名称、产品说明等。

2)应用商店根据第二应用的版权所有者在应用商店中的注册账户(或者第二应用的版权所有者的系统产品码)，确定第二应用的APP商品对应的第二应用的预定义所归属的第二应用的系统仓库。也即，应用商店可以根据第二应用的版权所有者在应用商店中的注册账户，确定第二应用的APP商品对应的第二应用的预定义来自哪个系统仓库。

3)应用商店根据第二应用的APP商品中包括的第二应用的预定义的标识，向第二应用的系统仓库请求上架第二应用的预定义。

4)第二应用的系统仓库响应于来自应用商店的上架第二应用的预定义的请求，执行下述步骤(4.1)至步骤(4.2)：(4.1)第二应用的系统仓库向应用商店上传第二应用的预定义，第二应用的预定义可以包括第二应用的APP模型和配置参数。(4.2)第二应用的系统仓库根据第二应用的依赖数据预定义列表和依赖资源列表，向应用商店上传第二应用的数据预定义和资源对象。

通过上述步骤1)-步骤4)所述的过程，即可实现将第二应用上架到应用商店。

需要说明的是，上述步骤4)中，当第二应用还关联了其他本地的子APP(不是从应用商店获取的子APP)时，第二应用的系统仓库还可以向应用商店上传第二应用关联的本地的子APP的预定义，以及根据本地的子APP的依赖数据预定义列表和依赖资源列表，向应用商店上传本地的子APP的数据预定义和资源对象。对于第一应用而言，由于应用商店中已经存在第一应用相关的数据，则第二应用的系统仓库无需再向应用商店上传第一应用相关的数据，如：第一应用的预定义、第一应用的数据预定义和资源对象等。从而，应用商店中仅包括一份第一应用相关的数据，实现了前述实施例中所述的节省应用商店的存储资源的效果。

可选地，在本申请中，第二应用可以称为成品APP，第二应用的子APP(如第一应用)可以称为零件APP。成品APP可以是能够独立运行的程序。零件APP可以是能够独立运行的APP程序，也可以是不独立运行的程序。零件APP能够作为一个或多个成品APP的子APP，实现被成品APP调用以实现零件APP的功能。

可以理解的，零件APP和成品APP是个相对概念，作为子APP的应用都可以认称为零件APP。例如，存在一个第四应用可以调用第二应用实现第二应用的功能时，第四应用是成品APP，第二应用是零件APP。

下面以一个具体的示例，对本申请实施例提供的应用授权管理方法进行更进一步的说明。

图8为本申请实施例提供的一种应用管理系统的组成示意图。如图8所示，开发系统仓库1、开发系统仓库2、应用商店、以及消费者仓库可以组成应用管理系统。

开发系统仓库1可以是用于开发零件APP(如上述第一应用)的系统仓库。零件APP的开发者可以在开发系统仓库1中开发完成零件APP，并将零件APP上架到应用商店中。其中，零件APP可以包括依赖数据预定义列表和依赖资源列表。依赖数据预定义列表建立了零件APP与数据模型4(预定义)和数据模型5(预定义)的依赖关系。依赖资源列表建立了零件APP与资源数据4的依赖关系。

开发系统仓库2可以是用于开发成品APP(如上述第二应用)的系统仓库。成品APP的开发者可以从应用商店中下载零件APP到开发系统仓库2中，并根据零件APP在开发系统仓库2中开发完成成品APP，并将成品APP上架到应用商店中。其中，成品APP可以包括依赖数据预定义列表和依赖资源列表。依赖数据预定义列表建立了成品APP与数据模型1(预定义)、数据模型2(预定义)、以及数据模型3(预定义)的依赖关系。依赖资源列表建立了成品APP与资源数据1、资源数据2、以及资源数据3的依赖关系。成品APP和零件APP建立了关联关系，能够调用零件APP实现零件APP的功能。

消费者仓库可以是消费使用第二应用的消费者(用户)侧的仓库。消费者可以使用用户设备从应用商店中下载成品APP到消费者仓库。当消费者使用用户设备从应用商店中下载成品APP时，应用商店可以将成品APP和零件APP一并下发到消费者仓库。

示例性地，消费者从应用商店中下载成品APP的过程可以包括：1)消费者通过用户设备在应用商店提供的交互界面中执行下载成品APP的指令，触发用户设备向应用商店发送下载成品APP的请求，下载成品APP的请求可以指定成品APP的名称(如包括成品APP的标识)。2)应用商店根据下载成品APP的请求指定的成品APP的名称，将成品APP的预定义下发到消费者仓库中。3)应用商店根据成品APP的预定义的依赖数据预定义列表和依赖资源列表找到成品APP依赖的数据预定义和资源数据下发到消费者仓库中。4)应用商店根据成品APP中包括的零件APP的标识(如查询成品APP的子APP列表)，将零件APP的预定义下发到消费者仓库中。5)应用商店根据零件APP的预定义的依赖数据预定义列表和依赖资源列表找到零件APP依赖的数据预定义和资源数据下发到消费者仓库中。

可选地，上述开发系统仓库(开发系统仓库1和开发系统仓库2)可以是APP开发系统的一部分，APP开发系统还可以包括开发者工作室。开发者工作室是指开发者编辑APP模型的系统，能够创建、编辑、发布等APP模型管理操作。开发系统仓库是存放开发者开发完成的APP模型发布成APP预定义的系统。

可选地，消费者仓库可以是消费者应用系统的一部分，消费者应用系统还可以包括APP运行环境和APP运维系统。消费者应用系统是指一个独立的生产企业的业务应用系统，生产企业在系统上完成业务活动，并负责维护业务应用系统。消费者仓库是存放消费者购买的APP预定义的系统。APP运维系统是消费者运维APP的系统。APP运行环境是运行APP的环境系统。

成品APP和零件APP下载到消费者仓库后，成品APP预定义可以创建APP运行实例，并指定运行环境(计算机节点)、分配计算机资源(如中央处理器(central processingunit，CPU)、内存、网络带宽等)。APP运行实例上面带有APP的预定义的标识。APP运维系统可以根据APP运行实例上的APP的预定义的标识，把APP的预定义的APP模型(APP的预定义上携带了APP模型的标识)的功能逻辑部署到指定的计算机节点。APP运维系统、消费者仓库、APP运行环境之间通过网络通信完成APP程序文件的部署过程。完成部署之后，可以启动APP实例的运行，开始执行APP实例的功能函数逻辑。

可选地，应用商店可以包括一个由店铺系统和交易系统组成的商店系统。该商店系统可以作为应用商店的运营商运营的商品交易流通系统。APP软件开发企业(即开发者)和生产企业(即消费者)可以通过商店系统完成APP的交易和共享。其中，店铺系统可以包括一个或多个店铺，用于存放上架的APP商品，负责APP的上架、下载、授权钥匙分发等。交易系统可以实现订单管理、支付管理等功能。

本申请中，成品APP的开发者和零件APP的开发者之间可以实现协同开发，能够有效提升成品APP的开发效率。零件APP能够被一个或多个成品APP调用以实现零件APP的功能，可以实现零件APP能够在不同开发组织之间的复用。通过应用商店，零件APP能够被更多的开发组织采用，零件APP的价值被放大，零件APP开发者的价值也被放大，可以提升APP开发者的积极性。

以工业APP的场景为例，通过这种合作模式，众多的工业APP开发者能够分工协作，复杂的工业APP由单个开发者开发转变为众多开发者协作开发，工业APP的产出效率会提升。

另外，成品APP和零件APP在应用商店中分散存储，可以保证不出现冗余数据，节省APP所占据的应用商店的存储资源。

图9为本申请实施例提供的一种应用管理系统的另一组成示意图。如图9所示，对于图8所示的应用管理系统，开发系统仓库1可以包括开发组织仓库1和工作室1，开发系统仓库2可以包括开发组织仓库2和工作室2，消费者仓库可以包括应用系统仓库、APP运行系统、以及APP运行系统(即APP运行环境)。

零件APP开发者可以在工作室1开发零件APP，并将零件APP提交至开发组织仓库1。零件APP版权所有者可以决定是否对开发组织仓库1中的零件APP授权加锁，以及将开发组织仓库1中的零件APP上架到应用商店中。其中，授权加锁过程和零件APP开发过程无关，零件APP开发者无法对零件APP进行授权加锁。

零件APP版权所有者对零件APP授权加锁可以是指：在零件APP的预定义上设置加锁状态，即修改零件APP的预定义的授权保护状态为加锁状态，同时在开发组织仓库1中创建了零件APP的预定义的授权锁。零件APP版权所有者上架零件APP时，零件APP的预定义可以从开发组织仓库1上传到应用商店的店铺中(具体可以参考前述实施例所述)。

成品APP版权所有者可以下载零件APP到开发组织仓库2，如果零件APP为授权加锁状态(值为ture)，表示零件APP的预定义带有授权锁，应用商店会把零件APP和授权锁一同下载到开发组织仓库2。

成品APP开发者可以在工作室2组装零件APP，开发完成成品APP(具体参见前述实施例所述)，完成开发后提交成品APP到开发组织仓库2。成品APP版权所有者可以决定是否对开发组织仓库2中的成品APP授权加锁，以及将开发组织仓库2中的成品APP上架到应用商店中。成品APP版权所有者对成品APP授权加锁的过程与零件APP版权所有者对零件APP授权加锁的过程相同或相似，不再赘述。成品APP版权所有者上架成品APP时，成品APP的预定义可以从开发组织仓库2上传到应用商店的店铺中(具体可以参考前述实施例所述)。

消费者可以使用用户设备从应用商店下载成品APP，如前文所述，成品APP被下载时，成品APP和零件APP被一同下发，如应用商店可以向应用系统仓库(也称消费者仓库)下发成品APP和零件APP。下载的成品APP和零件APP可以被部署到APP运维系统。成品APP和零件APP可以各自具有对应的授权锁。当消费者需要获取成品APP的授权权限时，可以通过用户设备从应用商店购买成品APP(如发送授权请求)。响应于授权请求，应用商店可以向应用系统仓库下发成品APP和零件APP的授权钥匙(简称钥匙)，成品APP的授权钥匙用于解除对成品APP的授权加锁，零件APP的授权钥匙用于解除对零件APP的授权加锁。。

一种实现方式中，成品APP和零件APP的钥匙和授权锁可以分别存储在各自的开发组织仓库，应用商店可以从各自的开发组织仓库拷贝钥匙和授权锁并下发。例如，应用商店可以从开发组织仓库1拷贝零件APP的钥匙和授权锁、以及从开发组织仓库2拷贝成品APP的钥匙和授权锁，并下发到消费者的应用系统仓库。

另一种实现方式中，成品APP和零件APP的钥匙和授权锁可以预先上传到应用商店中，例如，零件APP的钥匙和授权锁可以和零件APP一起上传到应用商店中，成品APP的钥匙和授权锁可以和成品APP一起上传到应用商店中。

例如，图10为本申请实施例提供的成品APP和零件APP的钥匙和授权锁的传输流程示意图。如图10所示，成品APP的钥匙和授权锁可以从开发者组织仓库2上架到应用商店中，零件APP的钥匙和授权锁可以从开发者组织仓库1上架到应用商店中。应用商店中存放了所有的成品APP的和零件APP的的预定义、授权锁、钥匙。应用商店可以响应于授权请求，将成品APP的和零件APP的的授权锁和钥匙下发至消费者仓库。

上面任意一种实现方式中，应用商店在接收到授权请求后，获取成品APP和零件APP的钥匙的过程可以包括：根据授权请求中包含的成品APP的标识确定成品APP，根据成品APP中包含的第一信息确定第一信息对应的零件APP(如第一信息可以是零件APP的标识)；根据成品APP的标识确定成品APP的授权锁(如成品APP的授权锁中包含成品APP的标识)、以及根据零件APP的标识确定零件APP的授权锁(如零件APP的授权锁中包含零件APP的标识)；根据成品APP的标识确定成品APP的钥匙(如成品APP的钥匙中包含成品APP的标识)、以及根据零件APP的标识确定零件APP的钥匙(如零件APP的钥匙中包含零件APP的标识)，或者，根据成品APP的授权锁的标识确定成品APP的钥匙(如成品APP的钥匙中包含成品APP的授权锁的标识)、以及根据零件APP的授权锁的标识确定零件APP的钥匙(如零件APP的钥匙中包含零件APP的授权锁的标识)。

消费者购买完成品APP后，可以创建APP运行实例，需要指定运行环境(计算机节点)、分配计算机资源(CPU、内存、网络带宽)，一个运行实例对应一个APP的拷贝。运维系统首先到应用系统仓库中检测成品APP和零件APP的预定义是否进行了授权保护(通过授权加锁状态判断)，如果有授权保护，到应用系统仓库中检测是否有成品APP和零件APP的预定义的空余的授权钥匙拷贝，如果有空余的授权钥匙拷贝，则允许创建成品APP和零件APP的的运行实例，如果没有授权钥匙拷贝则无法创建成品APP和零件APP的运行实例。APP运行实例创建成功后会占用一个钥匙拷贝。APP运维系统会定时检测APP运行实例占用的授权钥匙拷贝状态，如果授权钥匙拷贝过期了，则会停止APP实例运行。如果APP运行实例被删除，其占用的授权拷贝被释放。APP运行实例授权状态对其子APP运行实例的授权状态有影响，APP运行实例授权过期停止运行，子APP也会停止运行(不管子App的授权状态如何)。

可以看到，本申请实施例中，APP开发者在APP逻辑中不处理授权，开发者提交的APP不带授权锁，而是由APP版权所有者对APP加授权锁。APP开发时在程序内部不植入授权加密策略，只处理业务功能。版权所有者在上架时为APP授权加密，可以方便开发组织调整加密策略而不影响APP的业务逻辑，保持APP功能的稳定性。

APP授权锁的授权钥匙可以由APP版权所有者制作，应用商店不直接制作授权钥匙，通过APP版权所有者的店铺获取授权钥匙，授权钥匙发放多少由APP版权所有者决定，能够保护APP版权所有者的权限。

成品APP及其零件APP都带有授权控制。零件APP和成品APP单独授权控制，能够保护零件APP版权所有者的权益，提升零件APP开发者的积极性。消费者购买成品APP时，商店根据APP内部的构成，逐层分解，一次把成品APP及其后代所有零件APP的授权一次拿到，发放到消费者的仓库，减少为了保护开发者的利益而导致消费者购买授权的复杂性。

可以理解的，在实际实施时，本申请实施例所述的应用商店、用户设备等可以包含有用于实现前述对应的应用授权管理方法的一个或多个硬件结构和/或软件模块，这些执行硬件结构和/或软件模块可以构成一个电子设备。本领域技术人员应该很容易意识到，结合本文中所申请的实施例描述的各示例的算法步骤，本申请能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

基于这样的理解，以应用商店包含的硬件结构和/或软件模块为例，本申请实施例还对应提供一种应用授权管理装置，可以应用于上述应用商店(如应用商店对应的硬件设备)。图11为本申请实施例提供的应用授权管理装置的结构示意图。如图11所示，该应用授权管理装置可以包括：接收模块1101，用于接收授权请求，授权请求用于请求从应用商店中下载的第二应用的授权权限；第二应用与第一应用具有关联关系，能够调用第一应用以实现第一应用的功能。发送模块1102，用于响应于授权请求，发送第一钥匙以及第二钥匙。其中，第一应用具有第一授权锁，第一授权锁用于对从应用商店中下载的第一应用进行授权加锁，第一钥匙用于解除对第一应用的授权加锁。第二应用具有第二授权锁，第二授权锁用于对第二应用进行授权加锁，第二钥匙用于解除对第二应用的授权加锁。

以用户设备包含的硬件结构和/或软件模块为例，本申请实施例还对应提供一种应用授权管理装置，可以应用于上述用户设备(如手机、计算机等)。图12为本申请实施例提供的应用授权管理装置的另一结构示意图。如图12所示，该应用授权管理装置可以包括：发送模块1201，用于发送授权请求，授权请求用于请求从应用商店中下载的第二应用的授权权限。第二应用与第一应用具有关联关系，能够调用第一应用以实现第一应用的功能。接收模块1202，用于接收第一钥匙以及第二钥匙。其中，第一应用具有第一授权锁，第一授权锁用于对从应用商店中下载的第一应用进行授权加锁，第一钥匙用于解除对第一应用的授权加锁。第二应用具有第二授权锁，第二授权锁用于对第二应用进行授权加锁，第二钥匙用于解除对第二应用的授权加锁。

如上所述，本申请实施例可以根据上述方法示例对应用授权管理方法中涉及到的各执行主体进行功能模块的划分。其中，上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。另外，还需要说明的是，本申请实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。例如，可以对应各个功能划分各个功能模块，也可以将两个或两个以上的功能集成在一个处理模块中。

关于上述实施例中的应用授权管理装置，其中各个模块执行操作的具体方式、以及具备的有益效果，均已经在前述方法实施例中进行了详细描述，此处不再赘述。

本申请实施例还提供一种电子设备，该电子设备可以是应用商店对应的硬件设备，或者上述用户设备。电子设备包括：处理器，用于存储处理器可执行指令的存储器；处理器被配置为执行所述指令时，使得电子设备实现如前述实施例所述的方法。

在示例性实施例中，本申请实施例还提供一种计算机可读存储介质，其上存储有计算机程序指令；当所述计算机程序指令被电子设备执行时，使得电子设备实现如前述实施例所述的方法。计算机可读存储介质可以是非临时性计算机可读存储介质，例如，所述非临时性计算机可读存储介质可以是ROM、随机存取存储器(RAM)、CD-ROM、磁带、软盘和光数据存储设备等。

在示例性实施例中，本申请实施例还提供一种计算机程序产品，包括计算机可读代码，或者承载有计算机可读代码的非易失性计算机可读存储介质，当所述计算机可读代码在电子设备中运行时，所述电子设备中的处理器实现如前述实施例所述的方法。

本领域技术人员在考虑说明书及实践这里申请的发明后，将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未申请的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本申请的真正范围和精神由下面的权利要求指出。

应当理解的是，本申请并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本申请的范围仅由所附的权利要求来限制。

Claims (24)

1.一种应用授权管理方法，其特征在于，所述方法包括：

接收授权请求，所述授权请求用于请求从应用商店中下载的第二应用的授权权限，所述第二应用与第一应用具有关联关系，所述第二应用能够调用所述第一应用以实现所述第一应用的功能；

响应于所述授权请求，发送第一钥匙以及第二钥匙；

其中，所述第一应用具有第一授权锁，所述第一授权锁用于对所述第一应用进行授权加锁，所述第一钥匙用于解除对所述第一应用的授权加锁；所述第二应用具有第二授权锁，所述第二授权锁用于对所述第二应用进行授权加锁，所述第二钥匙用于解除对所述第二应用的授权加锁。

2.根据权利要求1所述的方法，其特征在于，所述第一应用包括第一标识，所述第一标识用于标识所述第一应用进行了授权加锁；

所述第二应用包括第二标识，所述第二标识用于标识所述第二应用进行了授权加锁。

3.根据权利要求1所述的方法，其特征在于，用于授权加锁的授权锁包括：授权字段，所述授权字段用于标识所述授权锁具有控制应用的授权时间的功能；

所述授权锁对应的钥匙包括：所述钥匙的有效使用时间。

4.根据权利要求1所述的方法，其特征在于，用于授权加锁的授权锁包括以下一种或多种：使用所述授权锁授权加锁的应用的标识、所述授权锁的标识、以及授权类型；

所述授权类型包括免费和收费。

5.根据权利要求1所述的方法，其特征在于，授权锁对应的钥匙包括以下一种或多种：所述钥匙的标识、所述钥匙对应的授权锁的标识、使用所述钥匙对应的授权锁授权加锁的应用的标识。

6.根据权利要求1-5任一项所述的方法，其特征在于，所述第一应用是由所述第一应用的版权所有者采用所述第一授权锁进行授权加锁的；

所述第二应用是由所述第二应用的版权所有者采用所述第二授权锁进行授权加锁的。

7.根据权利要求1-5任一项所述的方法，其特征在于，所述第一应用和所述第二应用的版权所有者相同或不同。

8.根据权利要求1-5任一项所述的方法，其特征在于，所述第一应用和所述第二应用的开发者相同或不同。

9.根据权利要求1-5任一项所述的方法，其特征在于，所述第二应用中包括第一信息，所述第一信息用于指示与所述第二应用关联的所述第一应用。

10.根据权利要求9所述的方法，其特征在于，所述第一信息包括所述第一应用的标识；

所述应用商店中的不同应用的标识不同。

11.根据权利要求1-5任一项所述的方法，其特征在于，所述第二应用还与从所述应用商店中下载的第三应用具有关联关系，能够调用所述第三应用以实现所述第三应用的功能；

当所述第三应用未被授权加锁，响应于所述授权请求，发送第一钥匙以及第二钥匙；

当所述第三应用被授权加锁，响应于所述授权请求，发送第一钥匙、第二钥匙以及第三钥匙，所述第三钥匙用于解除对所述第三应用的授权加锁。

12.一种应用授权管理方法，其特征在于，所述方法包括：

发送授权请求，所述授权请求用于请求从应用商店中下载的第二应用的授权权限，所述第二应用与第一应用具有关联关系，所述第二应用能够调用所述第一应用以实现所述第一应用的功能；

接收第一钥匙以及第二钥匙；

其中，所述第一应用具有第一授权锁，所述第一授权锁用于对所述第一应用进行授权加锁，所述第一钥匙用于解除对所述第一应用的授权加锁；所述第二应用具有第二授权锁，所述第二授权锁用于对所述第二应用进行授权加锁，所述第二钥匙用于解除对所述第二应用的授权加锁。

13.根据权利要求12所述的方法，其特征在于，所述第一应用包括第一标识，所述第一标识用于标识所述第一应用进行了授权加锁；

所述第二应用包括第二标识，所述第二标识用于标识所述第二应用进行了授权加锁。

14.根据权利要求12所述的方法，其特征在于，用于授权加锁的授权锁包括：授权字段，所述授权字段用于标识所述授权锁具有控制应用的授权时间的功能；

所述授权锁对应的钥匙包括：所述钥匙的有效使用时间。

15.根据权利要求12所述的方法，其特征在于，用于授权加锁的授权锁包括以下一种或多种：使用所述授权锁授权加锁的应用的标识、所述授权锁的标识、以及授权类型；

所述授权类型包括免费和收费。

16.根据权利要求12所述的方法，其特征在于，授权锁对应的钥匙包括以下一种或多种：所述钥匙的标识、所述钥匙对应的授权锁的标识、使用所述钥匙对应的授权锁授权加锁的应用的标识。

17.根据权利要求12-16任一项所述的方法，其特征在于，所述第二应用中包括第一信息，所述第一信息用于指示与所述第二应用关联的所述第一应用。

18.根据权利要求17所述的方法，其特征在于，所述第一信息包括所述第一应用的标识。

19.根据权利要求12-16任一项所述的方法，其特征在于，所述第二应用还与从所述应用商店中下载的第三应用具有关联关系，能够调用所述第三应用以实现所述第三应用的功能；

当所述第三应用未被授权加锁，接收第一钥匙以及第二钥匙；

当所述第三应用被授权加锁，接收第一钥匙、第二钥匙以及第三钥匙，所述第三钥匙用于解除对所述第三应用的授权加锁。

20.一种应用授权管理装置，其特征在于，所述装置包括：

接收模块，用于接收授权请求，所述授权请求用于请求从应用商店中下载的第二应用的授权权限，所述第二应用与第一应用具有关联关系，所述第二应用能够调用所述第一应用以实现所述第一应用的功能；

发送模块，用于响应于所述授权请求，发送第一钥匙以及第二钥匙；

其中，所述第一应用具有第一授权锁，所述第一授权锁用于对所述第一应用进行授权加锁，所述第一钥匙用于解除对所述第一应用的授权加锁；所述第二应用具有第二授权锁，所述第二授权锁用于对所述第二应用进行授权加锁，所述第二钥匙用于解除对所述第二应用的授权加锁。

21.一种应用授权管理装置，其特征在于，所述装置包括：

发送模块，用于发送授权请求，所述授权请求用于请求从应用商店中下载的第二应用的授权权限，所述第二应用与第一应用具有关联关系，能够调用所述第一应用以实现所述第一应用的功能；

接收模块，用于接收第一钥匙以及第二钥匙；

其中，所述第一应用具有第一授权锁，所述第一授权锁用于对所述第一应用进行授权加锁，所述第一钥匙用于解除对所述第一应用的授权加锁；所述第二应用具有第二授权锁，所述第二授权锁用于对所述第二应用进行授权加锁，所述第二钥匙用于解除对所述第二应用的授权加锁。

22.一种电子设备，其特征在于，包括：处理器；存储器；以及计算机程序；其中，所述计算机程序存储在所述存储器上，当所述计算机程序被所述处理器执行时，使得所述电子设备实现如权利要求1-11任一项所述的方法，或者，如权利要求12-19任一项所述的方法。

23.一种计算机可读存储介质，所述计算机可读存储介质包括计算机程序，其特征在于，当所述计算机程序在电子设备上运行时，使得所述电子设备实现如权利要求1-11任一项所述的方法，或者，如权利要求12-19任一项所述的方法。

24.一种计算机程序产品，包括计算机可读代码，或者承载有计算机可读代码的非易失性计算机可读存储介质，其特征在于，当所述计算机可读代码在电子设备中运行时，所述电子设备中的处理器实现如权利要求1-11任一项所述的方法，或者，如权利要求12-19任一项所述的方法。

Images