CN115080243A - 虚拟资源的分配方法及相关设备 - Google Patents

Abstract

本申请关于一种虚拟资源的分配方法及相关设备，涉及软件技术领域。该方法包括：获取第一虚拟资源，第一虚拟资源是用户设备获取应用商店中的第二应用的授权权限时支付给应用商店的账户的。第二应用与第一应用具有关联关系，第二应用能够调用第一应用以实现第一应用的功能。根据第二应用的价值和第一应用的价值，确定第一虚拟资源中分配给第二应用的账户的第二虚拟资源、以及分配给第一应用的账户的第三虚拟资源。向第二应用的账户分配第二虚拟资源，以及，向第一应用的账户分配第三虚拟资源。本申请可以使得虚拟资源的分配过程更加简单快捷，分配过程简单可靠，减少开发者之间的利益分配争议，有效提升开发者参与应用开发生态的意愿和积极性。

Description

虚拟资源的分配方法及相关设备

技术领域

本申请涉及软件技术领域，尤其涉及一种虚拟资源的分配方法及相关设备。

背景技术

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

用户在获取应用的授权权限时，一般需要向应用商店的账户支付购买该应用的授权权限的费用。应用商店可以将用户所支付的费用向应用的账户进行分配。

目前，应用商店向应用的账户分配费用的方式为：应用商店的账户中每接收到一个应用的授权权限被购买时用户所支付的费用，则应用商店向该应用的账户分配该笔费用。但是，目前的这种分配方式效率低下，如果应用是多个开发者(或开发组织)协作完成的，目前的分配方式无法解决应用由多个开发者协作开发的场景下的费用分配问题。

发明内容

本申请提供一种虚拟资源的分配方法及相关设备，可以在用户购买第二应用的授权权限时，按照第二应用与第一应用之间的关联关系，将用户购买第二应用的授权权限时所支付的虚拟资源，向第二应用的账户以及第一应用的账户进行分配。

本申请的技术方案如下：

第一方面，本申请提供一种虚拟资源的分配方法，所述方法包括：获取第一虚拟资源；第一虚拟资源是用户设备获取应用商店中的第二应用的授权权限时支付给应用商店的账户的；第二应用与应用商店中的第一应用具有关联关系，第二应用能够调用第一应用以实现第一应用的功能。根据第二应用的价值和第一应用的价值，确定第一虚拟资源中分配给第二应用的账户的第二虚拟资源、以及分配给第一应用的账户的第三虚拟资源。向第二应用的账户分配第二虚拟资源，以及，向第一应用的账户分配第三虚拟资源。

一些实现方式中，所述根据第二应用的价值和第一应用的价值，确定第一虚拟资源中分配给第二应用的账户的第二虚拟资源、以及分配给第一应用的账户的第三虚拟资源，包括：根据第二应用的价值和第一应用的价值，从第一虚拟资源中确定第四虚拟资源。根据第一分配规则，从第四虚拟资源中确定第二虚拟资源。根据第一应用的价值，从第一虚拟资源中确定第五虚拟资源。根据第二分配规则，从第五虚拟资源中确定第三虚拟资源。

可选地，第四虚拟资源与第二应用的价值和第一应用的价值的差值等同。第五虚拟资源与第一应用的价值等同。

一些实现方式中，第一分配规则包括：第二虚拟资源占第四虚拟资源的比例，或者，第二虚拟资源是第四虚拟资源中去除第一固定虚拟资源后的剩余资源。

一些实现方式中，第二分配规则包括：第三虚拟资源占第五虚拟资源的比例，或者，第三虚拟资源是第五虚拟资源中去除第二固定虚拟资源后的剩余资源。

可选地，第一固定虚拟资源和第二固定虚拟资源相同或不同。

可选地，所述获取第一虚拟资源，包括：接收来自用户设备的授权请求，授权请求用于请求获取第二应用的授权权限。响应于授权请求，根据第二应用的价值，向用户设备发送第二信息，第二信息包括第二应用的价值。接收来自用户设备支付的第一虚拟资源。

可选地，所述方法还包括：接收来自用户设备的第一下载请求，第一下载请求用于请求下载第二应用。响应于第一下载请求，向用户设备发送第二应用和第一应用。

可选地，所述方法还包括：接收第二下载请求，第二下载请求用于请求下载应用商店中的第一应用。响应于第二下载请求，发送第一应用，其中，第一应用用于生成第二应用。

一些实现方式中，第一应用和第二应用的版权所有者相同。

另外一些实现方式中，第一应用和第二应用的版权所有者不同。

一些实现方式中，第一应用和第二应用的开发者相同。

另外一些实现方式中，第一应用和第二应用的开发者不同。

可选地，第二应用中包括第一信息，第一信息用于指示与第二应用关联的第一应用。

一些实现方式中，第一信息包括第一应用的标识；应用商店中的不同应用的标识不同。

第二方面，本申请提供一种虚拟资源的分配装置，所述装置应用于应用商店，应用商店至少包括第一应用和第二应用。该装置可以用于应用商店实现如第一方面及第一方面的任意一种可能的实现方式所述的虚拟资源的分配方法。该装置的功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。硬件或软件包括一个或多个与第一方面及第一方面的任意一种可能的实现方式所述的虚拟资源的分配方法中的步骤相对应的模块或单元。

例如，所述装置包括：获取模块、处理模块、以及分配模块。其中，获取模块，用于获取第一虚拟资源，所述第一虚拟资源是用户设备获取应用商店中的第二应用的授权权限时支付给所述应用商店的账户的；所述第二应用与所述应用商店中的第一应用具有关联关系，所述第二应用能够调用所述第一应用以实现所述第一应用的功能。处理模块，用于根据所述第二应用的价值和所述第一应用的价值，确定所述第一虚拟资源中分配给所述第二应用的账户的第二虚拟资源、以及分配给所述第一应用的账户的第三虚拟资源。分配模块，用于向所述第二应用的账户分配所述第二虚拟资源，以及，向所述第一应用的账户分配所述第三虚拟资源。

一些实现方式中，处理模块，具体用于根据第二应用的价值和第一应用的价值，从第一虚拟资源中确定第四虚拟资源；根据第一分配规则，从第四虚拟资源中确定第二虚拟资源；根据第一应用的价值，从第一虚拟资源中确定第五虚拟资源；根据第二分配规则，从第五虚拟资源中确定第三虚拟资源。

可选地，第四虚拟资源与第二应用的价值和第一应用的价值的差值等同。第五虚拟资源与第一应用的价值等同。

一些实现方式中，第一分配规则包括：第二虚拟资源占第四虚拟资源的比例，或者，第二虚拟资源是第四虚拟资源中去除第一固定虚拟资源后的剩余资源。

一些实现方式中，第二分配规则包括：第三虚拟资源占第五虚拟资源的比例，或者，第三虚拟资源是第五虚拟资源中去除第二固定虚拟资源后的剩余资源。

可选地，第一固定虚拟资源和第二固定虚拟资源相同或不同。

可选地，获取模块，具体用于接收来自用户设备的授权请求，授权请求用于请求获取第二应用的授权权限；响应于授权请求，根据第二应用的价值，向用户设备发送第二信息，第二信息包括第二应用的价值；接收来自用户设备支付的第一虚拟资源。

示例性地，获取模块可以包括接收模块和发送模块，接收模块可以用于接收来自用户设备的授权请求。发送模块可以用于响应于授权请求，根据第二应用的价值，向用户设备发送第二信息。接收模块还可以用于接收来自用户设备支付的第一虚拟资源。

可选地，接收模块还用于接收来自用户设备的第一下载请求，第一下载请求用于请求下载第二应用。发送模块还用于响应于第一下载请求，向用户设备发送第二应用和第一应用。

可选地，接收模块还用于接收第二下载请求，第二下载请求用于请求下载应用商店中的第一应用。发送模块还用于响应于第二下载请求，发送第一应用，其中，第一应用用于生成第二应用。

一些实现方式中，第一应用和第二应用的版权所有者相同。

另外一些实现方式中，第一应用和第二应用的版权所有者不同。

一些实现方式中，第一应用和第二应用的开发者相同。

另外一些实现方式中，第一应用和第二应用的开发者不同。

可选地，第二应用中包括第一信息，第一信息用于指示与第二应用关联的第一应用。

一些实现方式中，第一信息包括第一应用的标识；应用商店中的不同应用的标识不同。

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

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

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

基于上述第一方面至第五方面中的任一方面，本申请至少具备如下有益效果：

本申请中，当用户购买第二应用的授权权限时，应用商店可以按照第二应用与第一应用之间的关联关系，向第二应用的账户以及第一应用的账户分配用户购买第二应用的授权权限时所支付的虚拟资源。对于这种第二应用是不同的开发者协作开发的场景，本申请实现了更有效、方便的虚拟资源分配方式。例如，根据第二应用和第一应用之间的关联关系，向第二应用的账户以及第一应用的账户分配用户购买第二应用的授权权限时所支付的虚拟资源，可以使得虚拟资源的分配过程更加简单快捷，虚拟资源的分配过程简单可靠，减少了开发者之间的利益分配争议，能够有效提升开发者参与应用开发生态的意愿和积极性。

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

附图说明

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

图1为本申请实施例提供的虚拟资源的分配方法的流程示意图；

图2为本申请实施例提供的虚拟资源的分配方法的另一流程示意图；

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

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

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

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

图7为本申请实施例提供的消费者购买APP的流程示意图；

图8为本申请实施例提供的逐级分配的示意图；

图9为本申请实施例提供的虚拟资源的分配装置的结构示意图。

具体实施方式

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

需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例能够以除了在这里图示或描述的那些以外的顺序实施。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

还应当理解的是，术语“包括”指示所描述特征、整体、步骤、操作、元素和/或组件的存在，但并不排除一个或多个其他特征、整体、步骤、操作、元素和/或组件的存在或添加。

“和/或”用于描述关联对象的关联关系，表示可以存在三种关系。例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。

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

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

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

用户在应用商店中下载应用后，需要使用或长期使用应用时，需要先获取应用的授权权限。用户在获取应用的授权权限时，一般需要向应用商店的账户支付购买该应用的授权权限的费用。应用商店可以向应用的账户分配用户所支付的费用。

应当理解，应用的授权权限是指限制应用能够创建运行实例的权限。当应用具有授权权限时，可以在授权权限允许的范围(如时间范围)内创建运行实例。当应用不具有授权权限时，则应用仅可以试运行，不能够创建运行实例或创建运行实例的时间仅限制在试运行时间范围内。

目前，应用商店向应用的账户分配费用的方式为：应用商店的账户中每接收到一个应用的授权权限被购买时用户所支付的费用，则应用商店向该应用的账户分配该笔费用。

但是，目前的这种分配方式效率低下，如果应用是多个开发者(或开发组织)协作完成的，则多个开发者之间的费用只能线下进行分配。也即，目前的分配方式无法解决应用由多个开发者协作开发的场景下的费用分配问题。

基于此，本申请实施例提供了一种虚拟资源的分配方法。该方法可以适用于个完整的应用包含多个子应用的场景(或称为一个完整的应用与多个子应用进行关联的场景)。例如，对于某个第二应用而言，第二应用与第一应用具有关联关系，能够调用所述第一应用以实现所述第一应用的功能，则第一应用可以认为是第二应用的子应用。该虚拟资源的分配方法中，当用户购买第二应用的授权权限时，应用商店可以按照第二应用与第一应用之间的关联关系，向第二应用的账户以及第一应用的账户分配用户购买第二应用的授权权限时所支付的虚拟资源。

该方法可以有效提供虚拟资源的分配效率，解决应用由多个开发者协作开发的场景下的费用分配问题。

其中，虚拟资源是指用户购买应用商店中的应用(如第二应用)的授权权限时所支付的金钱、积分、能够用于交易APP的其他信息等虚拟资源，在此对虚拟资源的类型不作限制。

可选地，应用的账户可以是指开发应用的开发者的账户或应用的版权所有者的账户，在此不作限制。

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

下面对本申请实施例提供的虚拟资源的分配方法进行说明。

图1为本申请实施例提供的虚拟资源的分配方法的流程示意图。如图1所示，该虚拟资源的分配方法可以包括：

S101、获取第一虚拟资源，第一虚拟资源是用户设备获取应用商店中的第二应用的授权权限时支付给应用商店的账户的。

例如，当用户通过用户设备(如手机)向应用商店购买第二应用的授权权限时，需要向应用商店的账户支付一定数额的虚拟资源，该虚拟资源即S101中获取的第一虚拟资源。第一虚拟资源可以是金钱、积分等，在此不作限制。

S102、根据第二应用的价值和第一应用的价值，确定第一虚拟资源中分配给第二应用的账户的第二虚拟资源、以及分配给第一应用的账户的第三虚拟资源。

如上所述，第二应用与应用商店中的第一应用具有关联关系，第二应用能够调用第一应用以实现第一应用的功能。应用商店在分配第一虚拟资源时，不仅需要向第二应用的账户分配虚拟资源，还需要向第一应用的账户分配虚拟资源。

示例性地，S102中根据第二应用的价值和第一应用的价值，确定第一虚拟资源中分配给第二应用的账户的第二虚拟资源、以及分配给第一应用的账户的第三虚拟资源的步骤，可以包括：根据第二应用的价值和第一应用的价值，从第一虚拟资源中确定第四虚拟资源；根据第一分配规则，从第四虚拟资源中确定第二虚拟资源；根据第一应用的价值，从第一虚拟资源中确定第五虚拟资源；根据第二分配规则，从第五虚拟资源中确定第三虚拟资源。

以虚拟资源为金钱为例，假设第二应用的价值(即购买第二应用的授权权限所需的金钱)为300元，第一应用的价值为200元，则用户在购买第二应用的授权权限时，需要向应用商店的账户支付300元，这300元即上述第一虚拟资源。应用商店可以根据第二应用的价值(300元)和第一应用的价值(200元)，从300元中确定待分配给第二应用的账户的部分金钱(如100元)，以及从300元中确定待分配给第一应用的账户的部分金钱(如200元)。待分配给第二应用的账户的100元即上述第四虚拟资源，待分配给第一应用的账户的200元即上述第五虚拟资源。

对于待分配给第二应用的账户的100元，应用商店可以进行抽成，并将抽成后剩余的部分实际分配给第二应用的账户。如：应用商店可以从待分配给第二应用的账户的100元中抽成10元，抽成后实际分配给第二应用的账户的金钱为90元，这90元即上述第二虚拟资源。

类似地，对于待分配给第一应用的账户的200元，应用商店也可以进行抽成，并将抽成后剩余的部分实际分配给第一应用的账户。如：应用商店可以从待分配给第一应用的账户的200元中抽成10元，抽成后实际分配给第一应用的账户的金钱为190元，这190元即上述第三虚拟资源。

可选地，第四虚拟资源与第二应用的价值和第一应用的价值的差值可以等同；第五虚拟资源与第一应用的价值可以等同。例如，上述示例中，第二应用的价值为300元，第一应用的价值为200元，则第四虚拟资源可以是300元减去200元后的差值：100元，第五虚拟资源可以是200元。

可选地，第四虚拟资源与第二应用的价值和第一应用的价值的差值也可以不等同，如第四虚拟资源可以大于或小于第二应用的价值和第一应用的价值的差值；第五虚拟资源与第一应用的价值也可以不等同，如第五虚拟资源大于或小于第一应用的价值，在此均不作限制。

本申请实施例中，应用商店可以根据第一分配规则从第四虚拟资源中确定第二虚拟资源；以及，根据第二分配规则从第五虚拟资源中确定第三虚拟资源。

一些实现方式中，第一分配规则可以包括：第二虚拟资源占第四虚拟资源的比例，或者，第二虚拟资源是第四虚拟资源中去除第一固定虚拟资源后的剩余资源。

例如，以第四虚拟资源为上述100元为例，假设第一分配规则中包括第二虚拟资源占第四虚拟资源的比例为例90％，则应用商店根据第一分配规则可以确定第二虚拟资源为100元的90％：90元。又例如，假设第一分配规则中包括第二虚拟资源是第四虚拟资源中去除第一固定虚拟资源后的剩余资源，第一固定虚拟资源为15元，则应用商店根据第一分配规则可以确定第二虚拟资源为100元去除15元后剩余的85元。通过第一分配规则，可以实现应用商店从待分配给第二应用的账户的100元中进行抽成。

需要说明的是，本申请对第一分配规则中第二虚拟资源占第四虚拟资源的比例的大小、以及第一固定虚拟资源的大小均不作限制。

与第一分配规则类似，第二分配规则也可以包括：第三虚拟资源占第五虚拟资源的比例，或者，第三虚拟资源是第五虚拟资源中去除第二固定虚拟资源后的剩余资源。

例如，以第五虚拟资源为上述200元为例，假设第二分配规则中包括第三虚拟资源占第五虚拟资源的比例为例80％，则应用商店根据第二分配规则可以确定第三虚拟资源为200元的80％：160元。又例如，假设第二分配规则中包括第三虚拟资源是第五虚拟资源中去除第二固定虚拟资源后的剩余资源，第二固定虚拟资源为25元，则应用商店根据第二分配规则可以确定第三虚拟资源为200元去除25元后剩余的175元。

需要说明的是，本申请对第二分配规则中第三虚拟资源占第五虚拟资源的比例的大小、以及第二固定虚拟资源的大小均不作限制。

可选地，第一分配规则中第二虚拟资源占第四虚拟资源的比例的大小，与第二分配规则中第三虚拟资源占第五虚拟资源的比例的大小可以相同，也可以不同。上述第一固定虚拟资源和第二固定虚拟资源的大小可以相同，也可以不同，在此均不作限制。

S103、向第二应用的账户分配第二虚拟资源，以及，向第一应用的账户分配第三虚拟资源。

例如，以第一虚拟资源为300元，第二虚拟资源为90元，第三虚拟资源为190元为例，应用商店可以将应用商店账户中的300元中的90元分配给第二应用的账户，将应用商店账户中的300元中的190元分配给第一应用的账户。

由上所述，本申请实施例提供的虚拟资源的分配方法中，当用户购买第二应用的授权权限时，应用商店可以按照第二应用与第一应用之间的关联关系，向第二应用的账户以及第一应用的账户分配用户购买第二应用的授权权限时所支付的虚拟资源。该方法可以有效解决应用由多个开发者协作开发的场景下的费用分配问题，分配方式效率较高，能够使得虚拟资源的分配过程更加简单快捷，分配过程简单可靠，减少了开发者之间的利益分配争议，有效提升了开发者参与应用开发生态的意愿和积极性。

可选地，当用户购买第二应用的授权权限时，用户设备可以向应用商店发送授权请求，授权请求用于请求获取第二应用的授权权限。应用商店可以响应于授权请求，根据第二应用的价值，向用户设备发送第二信息，第二信息包括第二应用的价值。第二信息还可以包括第二应用的名称、开发者、版权所有者等信息中的一种或多种。用户可以在用户设备上根据第二应用的价值支付第一虚拟资源。也即，上述S101获取第一虚拟资源的步骤，可以包括：接收来自用户设备的授权请求；响应于授权请求，根据第二应用的价值，向用户设备发送第二信息；接收来自用户设备支付的第一虚拟资源。

例如，图2为本申请实施例提供的虚拟资源的分配方法的另一流程示意图。如图2所示，该虚拟资源的分配方法，可以包括：

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

其中，授权请求用于请求获取第二应用的授权权限。

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

示例性地，当第二应用在用户设备上运行时，第二应用可以显示一个能够发起授权请求的界面，用户可以在该界面进行交互操作，以触发用户设备向应用商店发送授权请求，获取第二应用的授权权限。

S202、应用商店响应于授权请求，根据第二应用的价值，向用户设备发送第二信息。

其中，第二信息包括第二应用的价值。

相应地，用户设备接收第二信息。

S203、用户设备向应用商店的账户支付第一虚拟资源。

相应地，应用商店接收来自用户设备支付的第一虚拟资源。

S204、应用商店根据第二应用的价值和第一应用的价值，确定第一虚拟资源中分配给第二应用的账户的第二虚拟资源、以及分配给第一应用的账户的第三虚拟资源。

S204可以参考上述S102所述，不再赘述。

S205、向第二应用的账户分配第二虚拟资源，以及，向第一应用的账户分配第三虚拟资源。

S205可以参考上述S103所述，不再赘述。

可选地，应用商店接收来自用户设备支付的第一虚拟资源后，可以继续响应于授权请求，向用户设备发送第一授权锁和第一钥匙、以及第二授权锁和第二钥匙。其中，第一授权锁用于对从应用商店中下载的第一应用进行授权加锁，第一钥匙用于解除对第一应用的授权加锁；第二授权锁用于对第二应用进行授权加锁，第二钥匙用于解除对第二应用的授权加锁。

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

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

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

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

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

需要说明的是，本申请实施例中所述的各应用(如第一应用、第二应用等)的价值，可以在应用上架至应用商店时，由应用的开发者或版权所有者上传至应用商店。对于第二应用而言，第二应用的开发者或版权所有者在确定第二应用的价值时，还需要考虑第一应用的价值。例如，第二应用的价值至少大于或等于第一应用的价值。

可选地，本申请实施例中所述的第一应用可以是包括多个层级的应用，例如，APP1调用了APP2实现APP2的功能，APP2又调用了APP3实现APP3的功能，则APP1可以认为是第二应用，APP2和APP3可以认为是两个层级的第一应用。或者，可以将APP2认为是第二应用，将APP3认为是第一应用。

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

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

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

例如，当第二应用被上架到应用商店后，应用商店侧可以根据第二应用中包括的第一应用的标识或者能够指示第一应用的字段，为第二应用和第一应用之间维护一个关联关系表，实现第一应用和第二应用的关联关系的建立。例如，关联关系表中可以包括第二应用的标识、以及与第二应用的标识对应的第一应用的标识或者能够指示第一应用的字段。当第二应用被下载时，应用商店可以通过查询第一应用和第二应用的关联关系(如关联关系表)，确定出哪个应用为第一应用，并将第二应用和第一应用一并进行下发。

又例如，当第二应用被上架到应用商店后，应用商店侧可以直接将第二应用中包括的第一应用的标识或者能够指示第一应用的字段，作为第一应用和第二应用的关联关系。当第二应用被下载时，应用商店可以通过查询第二应用中包括的第一应用的标识或者能够指示第一应用的字段，确定出哪个应用为第一应用，并将第二应用和第一应用一并进行下发。

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

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

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

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

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

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

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

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

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

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

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

如图3所示，模型可以包括基本属性和成员列表；基本属性可以包括名称、描述、全局唯一标识符(globally unique identifier,GUID)、版本等信息；成员列表可以包括：“成员1：名称+类型”、“成员2：名称+类型”、“成员3：名称+类型”等信息。

预定义可以包括基本属性和成员列表；基本属性可以包括名称、描述、GUID、模型GUID+版本等信息；成员列表可以包括：“成员1+值”、“成员2+值”、“成员3+值”等信息。

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

示例性地，图4为本申请实施例提供的数据模型的示意图。如图4所示，数据模型可以包括：基本属性、成员列表、以及子模型列表。具有子模型的数据模型是复合的数据模型，如：图中的数据模型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模型的预定义(简称第二应用的预定义)到第二应用的系统仓库中，并为第二应用的预定义分配唯一标识(如全球唯一标识)。第二应用的预定义的标识即第二应用的标识。

其中，发布第二应用的预定义时，还可以设置预定义的参数值(如：属性和成员)。

示例性地，图5为本申请实施例提供的第二应用的APP模型的组成示意图。

如图5所示，第二应用的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。

下面以一个具体的示例，对本申请实施例提供的虚拟资源分配方法进行更进一步的说明。

图6为本申请实施例提供的一种应用管理系统的组成示意图。如图6所示，开发系统仓库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所占据的应用商店的存储资源。

以虚拟资源为费用(如金钱)为例，图7为本申请实施例提供的消费者购买APP的流程示意图。如图7所示，消费者购买APP的流程可以如下：

1)消费者的账户从成品APP店铺(简称成品店铺)选择购买的成品APP加入购物车，对购物车中的APP商品(可以是多个)进行结算，提交购买订单到交易系统；

例如，消费者可以输入每个成品APP商品的拷贝数量、拷贝有效期(开始时间，结束时间)；成品店铺根据消费者输入信息显示订单内容，包括订单号、商品名称、数量、金额、购买账户、售卖账户、支付状态。应用商店根据成品APP的拷贝数量和单价核算交易金额。成品PP的订单买家为消费者的账户，卖家为成品APP的账户。消费者确定订单内容后提交成品APP订单给交易系统。

2)交易系统接收到提交的订单，根据成品APP的结构进行订单分解(子APP列表)，为所有包含的零件APP产生购买订单。如果零件APP是商品(可以根据子APP列表中记录的APP预定义ID在应用商店中检索到对应的APP商品)，交易系统产生零件APP的购买订单(金额计算同前面介绍)，零件APP的订单除了上述订单内容，还记录有上级订单编号，买家为成品APP的账户，卖家变成零件APP的账户。如果零件APP还存在下一层级的零件APP，按前述过程逐层产生购买订单。

3)在逐层分解过程中，如果零件APP的预定义在应用商店店铺中不存在，则成品APP的购买订单无法进行支付，如果店铺中涉及的零件APP存在，则消费者可以进行支付。

4)交易系统收到了成品APP订单的支付，按照前述分解的订单开始执行支付。具体为：消费者按照订单金额执行成品APP订单费用支付，应用商店交易系统收到费用后，按层级分别分配费用到成品APP的账户以及零件APP的账户。

例如，图8为本申请实施例提供的逐级分配的示意图。如图8所示，对于消费者的账户给应用商店的账户支付的购买成品APP的费用(如第一虚拟资源)，应用商店可以按照成品APP与零件APP的层级逐级分配给成品APP的账户和零件APP的账户，具体分配方式可以餐前前述实施例中所述，在此不再赘述。

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

基于这样的理解，以应用商店包含的硬件结构和/或软件模块为例，本申请实施例还对应提供一种虚拟资源的分配装置，可以应用于上述应用商店(如应用商店对应的硬件设备)。图9为本申请实施例提供的虚拟资源的分配装置的结构示意图。如图9所示，该虚拟资源的分配装置可以包括：获取模块901、处理模块902、以及分配模块903。其中，获取模块901，用于获取第一虚拟资源，所述第一虚拟资源是用户设备获取应用商店中的第二应用的授权权限时支付给所述应用商店的账户的；所述第二应用与所述应用商店中的第一应用具有关联关系，所述第二应用能够调用所述第一应用以实现所述第一应用的功能。处理模块902，用于根据所述第二应用的价值和所述第一应用的价值，确定所述第一虚拟资源中分配给所述第二应用的账户的第二虚拟资源、以及分配给所述第一应用的账户的第三虚拟资源。分配模块903，用于向所述第二应用的账户分配所述第二虚拟资源，以及，向所述第一应用的账户分配所述第三虚拟资源。

一些实现方式中，处理模块903，具体用于根据第二应用的价值和第一应用的价值，从第一虚拟资源中确定第四虚拟资源；根据第一分配规则，从第四虚拟资源中确定第二虚拟资源；根据第一应用的价值，从第一虚拟资源中确定第五虚拟资源；根据第二分配规则，从第五虚拟资源中确定第三虚拟资源。

可选地，第四虚拟资源与第二应用的价值和第一应用的价值的差值等同。第五虚拟资源与第一应用的价值等同。

一些实现方式中，第一分配规则包括：第二虚拟资源占第四虚拟资源的比例，或者，第二虚拟资源是第四虚拟资源中去除第一固定虚拟资源后的剩余资源。

一些实现方式中，第二分配规则包括：第三虚拟资源占第五虚拟资源的比例，或者，第三虚拟资源是第五虚拟资源中去除第二固定虚拟资源后的剩余资源。

可选地，第一固定虚拟资源和第二固定虚拟资源相同或不同。

可选地，获取模块901，具体用于接收来自用户设备的授权请求，授权请求用于请求获取第二应用的授权权限；响应于授权请求，根据第二应用的价值，向用户设备发送第二信息，第二信息包括第二应用的价值；接收来自用户设备支付的第一虚拟资源。

示例性地，获取模块901可以包括接收模块和发送模块，接收模块可以用于接收来自用户设备的授权请求。发送模块可以用于响应于授权请求，根据第二应用的价值，向用户设备发送第二信息。接收模块还可以用于接收来自用户设备支付的第一虚拟资源。

可选地，接收模块还用于接收来自用户设备的第一下载请求，第一下载请求用于请求下载第二应用。发送模块还用于响应于第一下载请求，向用户设备发送第二应用和第一应用。

可选地，接收模块还用于接收第二下载请求，第二下载请求用于请求下载应用商店中的第一应用。发送模块还用于响应于第二下载请求，发送第一应用，其中，第一应用用于生成第二应用。

一些实现方式中，第一应用和第二应用的版权所有者相同。

另外一些实现方式中，第一应用和第二应用的版权所有者不同。

一些实现方式中，第一应用和第二应用的开发者相同。

另外一些实现方式中，第一应用和第二应用的开发者不同。

可选地，第二应用中包括第一信息，第一信息用于指示与第二应用关联的第一应用。

一些实现方式中，第一信息包括第一应用的标识；应用商店中的不同应用的标识不同。

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

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

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

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

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

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

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

Claims (16)

1.一种虚拟资源的分配方法，其特征在于，所述方法包括：

获取第一虚拟资源，所述第一虚拟资源是用户设备获取应用商店中的第二应用的授权权限时支付给所述应用商店的账户的；所述第二应用与所述应用商店中的第一应用具有关联关系，所述第二应用能够调用所述第一应用以实现所述第一应用的功能；

根据所述第二应用的价值和所述第一应用的价值，确定所述第一虚拟资源中分配给所述第二应用的账户的第二虚拟资源、以及分配给所述第一应用的账户的第三虚拟资源；

向所述第二应用的账户分配所述第二虚拟资源，以及，向所述第一应用的账户分配所述第三虚拟资源。

2.根据权利要求1所述的方法，其特征在于，所述根据所述第二应用的价值和所述第一应用的价值，确定所述第一虚拟资源中分配给所述第二应用的账户的第二虚拟资源、以及分配给所述第一应用的账户的第三虚拟资源，包括：

根据所述第二应用的价值和所述第一应用的价值，从所述第一虚拟资源中确定第四虚拟资源；

根据第一分配规则，从所述第四虚拟资源中确定所述第二虚拟资源；

根据所述第一应用的价值，从所述第一虚拟资源中确定第五虚拟资源；

根据第二分配规则，从所述第五虚拟资源中确定所述第三虚拟资源。

3.根据权利要求2所述的方法，其特征在于，所述第四虚拟资源与所述第二应用的价值和所述第一应用的价值的差值等同；

所述第五虚拟资源与所述第一应用的价值等同。

4.根据权利要求2所述的方法，其特征在于，所述第一分配规则包括：所述第二虚拟资源占所述第四虚拟资源的比例，或者，所述第二虚拟资源是所述第四虚拟资源中去除第一固定虚拟资源后的剩余资源。

5.根据权利要求2所述的方法，其特征在于，所述第二分配规则包括：所述第三虚拟资源占所述第五虚拟资源的比例，或者，所述第三虚拟资源是所述第五虚拟资源中去除第二固定虚拟资源后的剩余资源。

6.根据权利要求1-5任一项所述的方法，其特征在于，所述获取第一虚拟资源，包括：

接收来自所述用户设备的授权请求，所述授权请求用于请求获取所述第二应用的授权权限；

响应于所述授权请求，根据所述第二应用的价值，向所述用户设备发送第二信息，所述第二信息包括所述第二应用的价值；

接收来自所述用户设备支付的所述第一虚拟资源。

7.根据权利要求1-5任一项所述的方法，其特征在于，所述方法还包括：

接收来自所述用户设备的第一下载请求，所述第一下载请求用于请求下载所述第二应用；

响应于所述第一下载请求，向所述用户设备发送所述第二应用和所述第一应用。

8.根据权利要求1-5任一项所述的方法，其特征在于，所述方法还包括：

接收第二下载请求，所述第二下载请求用于请求下载所述应用商店中的所述第一应用；

响应于所述第二下载请求，发送所述第一应用，其中，所述第一应用用于生成所述第二应用。

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

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

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

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

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

13.一种虚拟资源的分配装置，其特征在于，所述装置包括：

获取模块，用于获取第一虚拟资源，所述第一虚拟资源是用户设备获取应用商店中的第二应用的授权权限时支付给所述应用商店的账户的；所述第二应用与所述应用商店中的第一应用具有关联关系，所述第二应用能够调用所述第一应用以实现所述第一应用的功能；

处理模块，用于根据所述第二应用的价值和所述第一应用的价值，确定所述第一虚拟资源中分配给所述第二应用的账户的第二虚拟资源、以及分配给所述第一应用的账户的第三虚拟资源；

分配模块，用于向所述第二应用的账户分配所述第二虚拟资源，以及，向所述第一应用的账户分配所述第三虚拟资源。

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

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

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

Images