CN102737341A - 应用商店系统及实现应用内购买功能的方法 - Google Patents

Abstract

本发明提供了应用商店系统及实现应用内购买功能的方法，该系统包括：开发者社区功能实体和应用商店网店功能实体，还包括：配置模块，用于接受为应用配置对应的购买项和对应于所述购买项的信息，其中，所述应用是通过所述开发者社区功能实体上传的；应用内购买处理模块，用于接收来自所述应用的购买请求，按照所述购买请求所请求购买的购买项对应的信息进行扣费。本发明降低了普通开发者开发及维护存在程序内购买功能的应用的成本。

Description

应用商店系统及实现应用内购买功能的方法

技术领域

本发明涉及通信领域，具体而言，涉及一种应用商店系统及实现应用内购买(InApplicationPurchase，简称为IAP)功能的方法。

背景技术

随着第三代(the 3^rd Generation，简称为3G)移动通信的发展和智能移动终端(例如，智能手机)的发展，手机互联网(internet)的应用越来越广泛。在这样的环境下，苹果从2008年开始通过应用商店(apple app store)提供iPhone应用，在短期内取得了接近10亿的下载量。

这种手机应用商店的使用，造就了一大批独立应用开发者。各大运营商、手机制造商以及互联网厂商也将推出各自的在线应用商店提上日程，或业已推出在线应用商店。

随着应用商店的发展，应用的形式也发生了多种多样的变化。应用商店需要为这些不同的应用提供更好的系统支撑能力。一种典型的新兴的应用是在应用中内置一个商店。当用户下载该应用时，可以从应用内触发一个购买请求。这种应用可以是一个游戏，当游戏中需要某个道具时，用户可以从开发者为游戏开发的某个购买入口触发购买请求。这种应用也可以是一个电子阅读器，用户免费的下载了某电子阅读器的应用程序，打开该应用程序后可以在应用程序中购买电子书。据统计，这一类型的应用可以提高用户的购买意愿。开发者迫切的需要应用商店为其提供这类应用开发的系统和结算能力以降低开发这类应用的开发成本。而应用商店之争，最后也将演变为如何吸引更多开发者，所以应用商店也应从开发者的角度考虑，为其开发具备程序内购买功能的应用程序提供更好的系统支撑。

图1是根据相关技术的应用商店系统的基本架构图，如图1所示，在普通的应用商店系统中，主要的功能实体为应用商店网店以及开发者社区，以下分别进行简要的说明。

相关技术中的应用商店网店的主要功能模块包括：门户，鉴权模块，应用分发模块，供应销售模块，业务支撑模块和运营支撑模块。门户主要用于提供WEB门户、WAP门户、手机客户端或者PC客户端的访问入口，通过该入口，手机终端用户可以方便的搜索和下载应用。鉴权模块用于提供对用户的鉴权以及应用的鉴权。应用分发模块用于提供各种应用分发途径的功能，比如下载到电脑、WAP PUSH到手机、短信发送地址或者客户端直接下载安装等与应用分发相关的功能。供应销售模块用于提供对应用商店中销售的应用的管理，包括：店铺和货架的管理、应用上线下线的管理以及推荐排行的管理。应用商店网店功能实体主要负责与用户之间的交互。他们之间的交互通过WEB界面操作或者应用接口，在图中以“web/接口1”来表示。

相关技术中的开发者社区的主要功能包括：应用上传，应用管理功能，论坛功能，开发者wiki。开发者社区功能实体主要负责开发者和应用商店系统之间的交互。开发者与开发者社区之间的交互通过WEB界面操作或者SDK接口，在图中以“web/接口3”来表示。

开发者社区和应用商店网店之间的信息交互通过“接口2”，该接口主要负责将管理员审核通过的应用及应用信息从开发者社区同步到应用商店网店中。

目前的这种应用商店系统对于普通的应用已具备较好的开发支持能力，但是，在该系统中，如果开发者希望开发内置有程序内购买(也称为应用内购买或应用程序内购买)流程的应用，就需要自己再另外搭建一个服务器(server)来处理这些计费请求，同时也要提供相应的完整的结算功能。这样，开发及维护的代价均非常之高。

发明内容

本发明的主要目的在于提供一种应用商店系统及实现应用内购买功能的方法，以至少解决上述问题。

本发明的一个方面提供了一种应用商店系统，包括开发者社区功能实体和应用商店网店功能实体，还包括：配置模块，用于接受为应用配置对应的购买项和对应于所述购买项的信息，其中，所述应用是通过所述开发者社区功能实体上传的；IAP处理模块，用于接收来自所述应用的购买请求，按照所述购买请求所请求购买的购买项对应的信息进行扣费。

本发明的另一个方面提供了一种开发者社区功能实体，包括：配置模块，用于接受为应用配置对应的购买项和对应于所述购买项的信息，其中，所述应用是通过所述开发者社区功能实体上传的。

本发明的又一个发明提供了一种应用商店网店功能实体，包括：IAP处理模块，用于接收来自应用的购买请求，按照所述购买请求所请求购买的购买项对应的信息进行扣费，其中，所述购买项和所述购买项对应的信息是通过开发者社区功能实体和所述应用商店网店功能实体之间的接口同步到所述IAP处理模块中的。

本发明的再一个方面提供了一种应用商店系统，包括开发者社区功能实体和应用商店网店功能实体，还包括IAP管理模块，其中，所述IAP管理模块包括：配置模块，用于接受为应用配置对应的购买项和对应于所述购买项的信息，其中，所述应用是通过所述开发者社区功能实体上传的；购买请求处理模块，用于接收来自应用的购买请求，按照所述购买请求所请求购买的购买项对应的信息进行扣费。

本发明的再一个方面提供了一种实现IAP功能的方法，包括：响应于用户选定待购买的购买项的操作，应用向应用商店系统发送购买请求；所述应用商店系统接收所述购买请求，按照所述购买请求所请求购买的购买项对应的信息进行扣费。

通过本发明，在应用商店系统中设置用于实现购买项配置的配置模块，及按照配置进行购买项扣费、查询等应用与应用商店之间的交互处理的IAP处理模块，解决了开发者开发应用的成本过高的问题，降低了普通开发者开发及维护存在程序内购买功能的应用的成本。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1是根据相关技术的应用商店系统的基本架构图；

图2是根据本发明一个实施例的应用商店系统的结构框图；

图3是根据本发明一个实施例的应用商店系统的优选结构框图一；

图4是根据本发明一个实施例的应用商店系统的优选结构框图二；

图5是根据本发明一个实施例的IAP处理模块包含的接口的示意图；

图6是根据本发明另一个实施例的应用商店系统的结构框图；

图7是根据本发明另一个实施例的应用商店系统的优选结构框图；

图8是根据本发明另一个实施例的应用商店系统中的IAP管理模块的优选结构框图一；

图9是根据本发明另一个实施例的应用商店系统中的IAP管理模块的优选结构框图二；

图10是根据本发明实施例的实现应用内购买功能的方法的流程图；

图11是在不提供IAP功能的应用商店中，应用程序在运行时与应用程序SERVER之间的接口图；

图12是根据实施例1的应用商店、程序内购买功能模块、开发者和开发者应用server之间的接口关系图；

图13是根据实施例2的IAP功能中各模块分设于不同的功能实体的示意图；

图14是根据实施例2的开发者配置及用户进行应用内购买的流程图；

图15是根据实施例3的实现内建程序内购买的流程图；

图16是根据实施例4的实现独立server程序内购买的流程图。

具体实施方式

下文中将参考附图并结合实施例来详细说明本发明。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。

本发明的一个实施例提供了一种应用商店系统，图2是根据本发明一个实施例的应用商店系统的结构框图，如图2所示，该系统包括开发者社区功能实体22和应用商店网店功能实体24，还包括配置模块261，用于接受为通过开发者社区功能实体22上传的应用配置对应的购买项和对应于购买项的信息；IAP处理模块262，用于根据在配置模块261中的配置在所述应用和所述应用商店系统之间提供接口处理，优选地，用于接收来自应用的购买请求，按照购买请求所请求购买的购买项对应的信息进行扣费。以上的配置模块261和IAP处理模块262共同构成了用于处理应用内购买项购买请求和IAP购买项查询相关接口这类应用与应用商店之间的交互接口的IAP管理功能。

通过以上的系统，开发者在开发具备应用内购买功能的应用时，无需在应用服务器中配置购买功能，简化了开发者开发应用的复杂度。同时，通过该架构可以更方便的进行程序内购买项的管理及维护，简化了用户的操作。

图3是根据本发明一个实施例的应用商店系统的优选结构框图一，如图3所示，IAP管理功能所包含的模块(至少包含配置模块261和IAP处理模块262)可以全部设置在开发者社区功能实体22中。在图3中，应用商店网店功能实体与用户之间的交互WEB界面操作或者应用接口，在图中以“web/接口1”来表示。开发者社区功能实体主要负责开发者和应用商店系统之间的交互。开发者与开发者社区之间的交互通过WEB界面操作或者SDK接口，在图中以“web/接口3”来表示，IAP的管理和配置也通过该接口来完成。开发者社区和应用商店网店之间的信息交互通过“接口2”，该接口主要负责将管理员审核通过的应用及应用信息从开发者社区同步到应用商店网店中。由于开发者社区和应用之间无接口，所以当IAP处理模块配置在开发者社区中时，需要单独开放一个“接口4”(其功能由IAP处理模块262来实现)来完成应用和IAP处理模块之间的信息交互。

图4是根据本发明一个实施例的应用商店系统的优选结构框图二，如图4所示，IAP管理功能的各个模块也可以分别设置在开发者社区功能实体22和应用商店网店功能实体24中。其中配置模块261配置在开发者社区功能实体22中，IAP处理模块262配置在应用商店网店功能实体24中。配置模块261是开发者配置IAP购买项使用的，IAP处理模块262则主要处理应用和应用商店系统之间的有关IAP项的查询和购买相关信息的交互。开发者社区提供开发者上传和配置应用程序相关信息的入口，所以IAP配置模块配置在开发者社区，在开发者上传应用后，对应用内的IAP项一同进行配置。图4与图3所示的应用商店系统优选接口框图一的区别在于，由于应用商店网店系统是用户通过应用商店或WEB进行访问，涉及用户和应用商店系统的交互，所以当负责应用和应用商店系统之间的接口交互的IAP处理模块放在应用商店网店功能模块中时，应用商店网店中并无IAP可购买项的信息，所以需要增加开发者社区和应用商店网店功能实体之间的IAP信息同步接口(可在开发者社区功能实体22和应用商店网店功能实体24之间新增一个接口来实现，但优选地可复用目前在开发者社区功能实体22和应用商店网店功能实体24之间的接口2，通过对接口2进行扩展来实现以上同步过程)来用于将开发者配置的应用相关的IAP可购买项信息同步到应用商店网店功能实体中。当应用商店网店功能实体中具备了IAP可购买项的相关信息。用户通过应用中的接口来和IAP配置模块进行查询和购买等操作的时候IAP配置模块才能在应用商店网店功能实体中查询到相关信息。

在图4中，应用商店网店功能实体与用户之间的交互WEB界面操作或者应用接口，在图中以“web/接口1”来表示，应用和IAP处理模块的交互也通过该接口来完成。开发者社区功能实体主要负责开发者和应用商店系统之间的交互通过WEB界面操作或者SDK接口，在图中以“web/接口3”来表示，IAP的管理和配置通过该接口来完成。开发者社区和应用商店网店之间的信息交互通过“接口2”，该接口主要负责将管理员审核通过的应用、应用信息及IAP购买项相关信息从开发者社区同步到应用商店网店中。

图5是根据本发明一个实施例的IAP处理模块包含的接口的示意图，如图5所示，接口处理管理模块262主要包括以下几个主要的接口：购买请求接口2621，用于接收来自应用的应用IAP项的购买请求，按照购买请求所请求购买的购买项对应的信息进行扣费；购买请求响应接口2622，用于在购买请求接口2621扣费成功的情况下，返回购买是否成功的消息给应用；IAP查询接口2623，用于接收来自应用的查询请求，根据查询请求进行购买项的查询；查询请求响应接口2624，用于向应用返回查询到的购买项的信息。查询请求可以指示查询应用所对应的一个或多个购买项。

需要说明的是，为了简化开发者开发应用的复杂度，应用商店系统需要具备支持扣费(具体可以是应用商店系统自身完成扣费或应用商店系统通过外部结算系统完成扣费)的功能，从而使得开发者在开发具备IAP功能的应用时，无需在应用服务器中提供购买功能。在本应用商店系统中，IAP处理模块262(具体可以为IAP处理模块262中的购买请求接口2621)可以用于在接收到来自应用的购买请求后，按照购买请求所请求购买的购买项对应的信息，通过设置在应用商店系统中的购买功能模块进行扣费，或者通过外部接口控制外部结算系统进行扣费。

在实际应用中，返回的购买成功消息所携带的内容可以根据应用购买项的类别来决定，例如，IAP处理模块262(具体可以为IAP处理模块262中的购买请求响应接口2622)在扣费成功的购买项为应用中已下载的项目的情况下，返回携带有扣费成功的购买项的信息的购买成功消息，此时应用可以根据具体扣费成功的购买项，来确定解锁这些购买项供用户使用；以及在扣费成功的购买项为应用中未下载的项目的情况下，返回携带有经过加密的扣费凭证的购买成功消息，此时应用可以将加密的扣费凭证发送到应用服务器，以便应用服务器在对扣费凭证进行解密校验后决定是否向应用返回具体的服务内容。在实际操作中，可以通过多种方式来协助IAP处理模块262对购买项的类别进行判定，例如，配置模块261中配置的购买项的信息可以包括一个或多个参数来为该IAP购买项进行分类，一种是内建IAP购买项的，一种是需要下载内容的购买项，随着应用中功能的扩展，还可能包括其他类型的购买项。这样，IAP处理模块262就可以根据以上的参数确定当前的购买项的类型，从而决定后续的处理方式。

对于扣费凭证进行加密可以使用验证码的方式，例如，IAP处理模块262(具体可以为IAP处理模块262中的购买请求响应接口2622)返回的购买成功消息中携带的经过加密的扣费凭证通过以下方式获得：使用对应于该应用的校验码(一种可选的获得该验证码的方式是：开发者在应用商店为自己的应用申请一个扣费校验码)并应用加密算法对扣费凭证进行加密，其中，所述校验码、对应于所述应用的加密算法和验证规则配置在用于供所述应用下载所述扣费成功的购买项的应用服务器中，后续应用server收到加密后的扣费凭证后，则使用该解密算法和验证规则对扣费进行验证，通过验证后即可将下载扣费成功的购买项传递给应用程序。其中，加解密算法和验证规则由应用商店系统提供(例如，可以在开发手册中规定)。

需要说明的是，在实际应用中，以上IAP管理功能中的IAP处理模块的各个接口的功能，都可以通过在应用商店系统中设置具备相应功能的模块来实现，例如，购买请求接口的功能可以通过设置购买请求响应模块实现，购买请求响应接口可以通过设置购买请求响应模块来实现，IAP查询接口可以通过设置查询请求处理模块实现，IAP查询响应接口可以通过设置查询请求响应模块来实现，具体描述请详见后续关于应用商店系统的实施例的描述。应用通过具备这些功能的模块，同样可以完成处理请求的发送和/或处理响应的接收，从而实现整个购买功能。

本发明的另一个实施例还提供了一种开发者社区功能实体，包括以上描述的配置模块，用于接受为通过开发者社区功能实体上传的应用配置对应的购买项和对应于购买项的信息。

本发明的另一个实施例还提供了一种应用商店网店功能实体，包括IAP处理模块，用于接收来自应用的购买请求，按照购买请求所请求购买的购买项对应的信息进行扣费，其中，购买项和购买项对应的信息是通过开发者社区功能实体和应用商店网店功能实体之间的接口同步到IAP处理模块中的。

该IAP处理模块可以包括以上描述的购买请求接口、购买请求响应接口、IAP查询接口、查询请求响应接口中的一个或多个。

本发明的另一个实施例提供了一种应用商店系统，图6是根据本发明另一个实施例的应用商店系统的结构框图，如图6所示，该系统包括开发者社区功能实体62和应用商店网店功能实体64，还包括IAP管理模块66，其中，IAP管理模块66包括：配置模块661，用于接受为通过开发者社区功能实体62上传的应用配置对应的购买项和对应于购买项的信息；购买请求处理模块662，也称支付请求处理模块，用于接收来自应用的购买请求，按照购买请求所请求购买的购买项对应的信息进行扣费。

通过以上的系统，开发者在开发具备应用内购买功能的应用时，无需在应用服务器中配置购买功能，简化了开发者开发应用的复杂度。同时，通过该架构可以更方便的进行程序内购买项的管理及维护，简化了用户和开发者的操作。

需要说明的是，为了简化开发者开发应用的复杂度，应用商店系统需要具备支持扣费(具体可以是应用商店系统自身完成扣费或应用商店系统通过外部结算系统完成扣费)的功能，从而使得开发者在开发具备IAP功能的应用时，无需在应用服务器中提供购买功能。在本应用商店系统中，购买请求处理模块662可以用于在接收到来自应用的购买请求后，按照购买请求所请求购买的购买项对应的信息，通过设置在应用商店系统中的购买功能模块进行扣费，或者通过外部接口控制外部结算系统进行扣费。

图7是根据本发明另一个实施例的应用商店系统的优选结构框图，如图7所示，IAP管理模块66设置在开发者社区功能实体62中。

图8是根据本发明另一个实施例的应用商店系统中的IAP管理模块的优选结构框图一，如图8所示，IAP管理模块66还可以包括：购买请求响应模块663，也称支付请求响应模块，用于在购买请求处理模块662扣费成功的情况下，向应用返回购买成功消息。

在实际应用中，返回的购买成功消息所携带的内容可以根据应用购买项的类别来决定，例如，购买请求响应模块663在扣费成功的购买项为应用中已下载的项目的情况下，返回携带有扣费成功的购买项的信息的购买成功消息，此时应用可以根据具体扣费成功的购买项，来确定解锁这些购买项供用户使用；以及在扣费成功的购买项为应用中未下载的项目的情况下，返回携带有经过加密的扣费凭证的购买成功消息，此时应用可以将加密的扣费凭证发送到应用服务器，以便应用服务器在对扣费凭证进行解密校验后决定是否向应用返回具体的服务内容。在实际操作中，可以通过多种方式来协助购买请求响应模块663对购买项的类别进行判定，例如，配置模块661中配置的购买项的信息可以包括一个或多个参数来为该IAP购买项进行分类，一种是内建IAP购买项的，一种是需要下载内容的购买项，随着应用中功能的扩展，还可能包括其他类型的购买项。这样，购买请求响应模块663就可以根据以上的参数确定当前的购买项的类型，从而决定后续的处理方式。

对于扣费凭证进行加密可以使用验证码的方式，例如，购买请求响应模块663返回的购买成功消息中携带的经过加密的扣费凭证通过以下方式获得：使用对应于该应用的校验码(一种可选的获得该验证码的方式是：开发者在应用商店为自己的应用申请一个扣费校验码)并应用加密算法对扣费凭证进行加密，其中，所述校验码、对应于所述应用的加密算法和验证规则配置在用于供所述应用下载所述扣费成功的购买项的应用服务器中，后续应用server收到加密后的扣费凭证后，则使用该解密算法和验证规则对扣费进行验证，通过验证后即可将下载扣费成功的购买项传递给应用程序。其中，加解密算法和验证规则由应用商店系统提供(例如，可以在开发手册中规定)。

图9是根据本发明另一个实施例的应用商店系统中的IAP管理模块的优选结构框图二，如图9所示，IAP管理模块66还可以包括：查询请求处理模块664，用于接收来自应用的查询请求，根据查询请求进行购买项的查询；查询请求响应模块665，用于向应用返回查询到的购买项的信息。查询请求可以指示查询应用所对应的一个或多个购买项，查询请求处理模块664则根据查询请求进行购买项的查询，相应地返回对应的一个或多个购买项的信息。

需要说明的是，在实际应用中，以上IAP管理模块66中的各个模块的功能，都可以通过设置具备相应功能的接口来实现，应用通过具备这些功能的接口，就可以完成处理请求的发送和/或处理响应的接收，从而实现整个购买功能。

图10是根据本发明实施例的实现应用内购买功能的方法的流程图，该方法包括：

步骤S1002，响应于用户选定待购买的购买项的操作，应用向应用商店系统发送购买请求；

步骤S1004，应用商店系统接收来自应用的购买请求，按照购买请求所请求购买的购买项对应的信息进行扣费。

该方法适用于多种应用商店系统的结构，例如，若采用以上第一个实施例中的应用商店系统的结构来实现该方法，则在步骤S1002中，应用应向应用商店系统的IAP处理模块262发送购买请求，在步骤S1004中，应用商店系统的IAP处理模块262接收来自应用的购买请求，按照购买请求所请求购买的购买项对应的信息进行扣费；若采用以上第二个实施例中的应用商店系统的结构来实现该方法，则在步骤S1002中，应用应向应用商店系统的购买请求处理模块662发送购买请求，在步骤S1004中，应用商店系统的购买请求处理模块662接收来自应用的购买请求，按照购买请求所请求购买的购买项对应的信息进行扣费。

通过以上的方法，具备应用内购买功能的应用可以通过应用商店系统来进行购买项的购买，开发者无需在应用服务器中配置购买功能，简化了开发者开发应用的复杂度。需要说明的是，为了简化开发者开发应用的复杂度，应用商店系统需要具备支持扣费(具体可以是应用商店系统自身完成扣费或应用商店系统通过外部结算系统完成扣费)的功能，从而使得开发者在开发具备IAP功能的应用时，无需在应用服务器中提供购买功能。在本实施例中，应用商店系统中可以在接收到来自应用的购买请求后，按照购买请求所请求购买的购买项对应的信息，通过设置在应用商店系统中的购买功能模块进行扣费，或者通过外部接口控制外部结算系统进行扣费。

为了便于应用进行购买请求后的判定处理，在应用商店系统接收来自应用的购买请求，按照购买请求所请求购买的购买项对应的信息进行扣费之后，还可以包括：应用接收应用商店系统在扣费成功的情况下返回的购买成功消息；在扣费成功的购买项为应用中已下载的项目的情况下，应用根据购买成功消息中携带的扣费成功的购买项的信息授权使用扣费成功的购买项；在扣费成功的购买项为应用中未下载的项目的情况下，应用将购买成功消息中携带的经过加密的扣费凭证发送至供应用下载扣费成功的购买项的应用服务器。通过该流程，对于无需下载的购买项，应用可以直接判定是否购买成功后，决定是否向用户开放该项目；而对于需要下载的购买项，应用可以向应用服务器发送扣费凭证，请求下载已付费的服务或内容。在应用将购买成功消息中携带的经过加密的扣费凭证发送至应用服务器之后，应用服务器可以对经过加密的扣费凭证进行解密和校验，在扣费凭证合法的情况下，向应用传递扣费成功的购买项的服务内容。以上的购买响应处理过程适用于多种应用商店系统的结构，例如，若采用以上第一个实施例中的应用商店系统的结构来实现购买响应，则由应用商店系统的购买请求响应接口2622返回购买响应；若采用以上第二个实施例中的应用商店系统的结构来实现购买响应，则由应用商店系统中的购买请求响应模块663返回购买响应。

在应用向请求购买处理模块发送购买请求之前，应用可以向应用商店系统查询购买项的信息，从而便于用户决定是否进行购买项购买，具体可以采用以下的流程进行处理：应用向应用商店系统发起查询请求；应用商店系统根据查询请求进行购买项的查询，向该应用返回查询到的购买项的信息；应用显示接收到的购买项的信息。以上的购买项查询处理过程适用于多种应用商店系统的结构，例如，若采用以上第一个实施例中的应用商店系统的结构来实现购买项查询，则由应用商店系统的IAP查询2623接收查询请求，由IAP查询响应接口2624返回查询结果；若采用以上第二个实施例中的应用商店系统的结构来实现购买项查询，则由应用商店系统中的查询请求处理模块664接收查询请求，由查询请求响应模块665返回查询结果。

在实际情况下，应用发起购买项查询的过程可能有多种，以下例举两种可能比较常用的查询过程：

(1)对于内建购买项的查询，应用向应用商店系统发起用于指示查询应用所对应的所有购买项的查询请求；应用商店系统查询应用所对应的所有购买项的信息并返回给应用；应用显示接收到的购买项的信息，供用户查看。

(2)对于非内建购买项，需要去服务器下载内容的IAP购买项，应用向应用服务器发起用于查询能够被购买的购买项的查询请求；应用服务器向应用返回能够被购买的购买项的购买项标识的列表；应用向应用商店系统发起携带有待查询的购买项标识的查询请求；应用商店系统查询待查询的购买项标识所对应的购买项的信息并返回给应用；应用显示接收到的购买项的信息，供用户查看。

以下描述的实施例1-4，综合了上述多个优选实施例的技术方案。需要说明的是，以下实施例1和实施例2以上述第一个关于应用商店系统的实施例中的结构为基础进行描述，本领域技术人员应当理解，以下实施例同样适用于第二个关于应用商店系统的实施例中的结构，具体实现过程类似，在此不再赘述。

实施例1

本实施例描述增加了应用内购买功能模块的应用商店系统的基本架构，并通过举例的方式，详细说明相比于相关技术中的应用网店系统，采用本实施例中的应用商店系统所具备的优点。

如图2所示，在应用商店基本结构的基础上，增加了IAP功能。IAP功能主要由IAP配置模块和IAP处理模块组成。IAP配置模块主要负责为开发者提供用于管理其程序内购买产品的入口，IAP处理模块提供用户使用含有程序内购买功能的应用时的完整的购买结算流程。IAP配置模块和IAP处理模块可以是开发者社区的一个组成部分，也可以置于应用商店内其他的功能实体中。

应用中的可购买项分为两种形式，一种是内建IAP购买项的，一种是需要下载内容的购买项，以下分别进行说明：

内建IAP购买项的情况下，内容和服务已经在程序内部被用户下载了，用户需要购买后才能解锁某个内容或服务。以一个游戏为例，该游戏中的某一个关卡需要购买后才能玩。在相关技术中的没有提供IAP功能的应用商店中，用户如果需要实现这样的功能必须要提供一个游戏server给用户来完成购买。而在提供了IAP功能的应用商店中实现该游戏的功能，只需要上传应用之后给该应用建立一个IAP购买项，并为该项目定价。用户向应用商店购买该IAP项目的价格后才可以解锁该关卡继续游戏。

需要下载内容的购买项的情况下，用户内容和服务在应用服务器上由开发者提供，用户购买了IAP的某个产品后，去相应的应用服务器上下载对应的内容或使用某种服务。以一个可以购买杂志的阅读器应用程序为例，该阅读器售卖价格为0元，主要希望通过杂志的售卖来获得利润，每期杂志卖5元。用户如果需要实现程序内购买类似的功能，需要在自建应用程序server中完成所有的功能。开发者需要将应用程序上传到应用商店中进行售卖，价格为0元。同时需要自己建立一个应用程序server。在应用程序运行时，应用程序server需要提供应用程序查询可购买杂志的请求，购买杂志的请求，杂志递送和购买接口这几个基本的接口和功能，还须提供内部的上传杂志以及管理杂志信息和管理用户的基本管理功能。

如图11所示，显示了在不提供IAP功能的应用商店中，应用程序在运行时与应用程序server之间的接口关系。在应用程序被下载后，应用将只和自己的应用程序server之间进行信息交互和内容传递。应用程序server需要提供所有的内容传递，服务提供，程序内购买流程，购买流程的功能。可见，由于需要提供如此多功能的应用server，对于普通开发者来说，在没有提供IAP功能的应用商店中提供这种程序内购买功能的应用程序，开发的代价非常高。并且在购买问题上，也不仅仅是开发成本的问题，还须和网上银行合作。

如图12所示，显示了在提供了IAP功能的应用商店中，应用程序在运行时与应用程序server以及应用商店之间的接口关系。使用IAP功能的应用商店开发应用，在应用被用户下载后，用户从应用中可以触发购买，仍然需要与应用商店进行信息交互，如果需要发生购买行为，用户向应用商店购买。应用程序server中提供内容和服务，用户购买成功后可向应用程序server发起内容/服务请求，以获取购买的相应的内容/服务。举例说明，开发者如果要开发一个杂志阅读器，需要将应用程序上传到应用商店中进行售卖，价格为0元，在IAP管理中为该应用建立IAP购买项，比如名称为“2011年4月XX杂志”，定价为5元。同时也需要建立一个应用程序server，该应用程序server为应用提供杂志内容递送的服务。当用户购买杂志时，购买费用给应用商店，购买成功后去应用server下载对应的已购买杂志。

对于开发者来说，在提供了IAP功能的应用商店中开发这种应用大大降低了开发难度和开发成本。自建的应用程序server上只需要提供基本的内容管理和内容递送服务即可。关于购买过程、购买项等管理已经在应用商店中实现。

实施例2

IAP功能按模块可以划分为配置模块和IAP处理模块，其中配置模块和IAP处理模块可以分设在应用商店网店和开发者社区中，如图13所示。本实施例就描述了IAP功能模块分设的情形下，IAP购买功能实现的流程。

在如图13所示的配置模块和IAP处理模块分设的情况下，需要增加开发者社区和应用商店网店系统之间的IAP项相关信息的同步接口。即，当开发者在开发者社区中配置了IAP项，经过审核并生效后，开发者社区要将IAP项的相关信息同步到应用商店网店系统中，这样当应用与IAP处理模块交互的时候，应用商店网店系统才能在自己的系统中查询到该IAP项的相关信息。

在IAP配置模块和IAP处理模块分设的情况下。IAP购买项从开发者配置到用户购买的流程如图14所示，如图14所示，包括以下步骤：

步骤1401，开发者在开发者社区上传应用，并在IAP配置模块配置应用相关的IAP项；

步骤1402，管理员在开发者社区审核通过开发者应用及配置的IAP项；

步骤1403，开发者社区向应用商店网店系统同步IAP项相关信息；

步骤1404，应用被购买后，用户在应用内可以通过应用提供的界面查询到IAP可购买项，并进行购买。

在IAP配置模块置于开发者社区，IAP处理模块置于应用商店网店系统中的优选结构中，IAP的信息在开发者社区和应用商店网店系统的同步，也就是步骤1403，是必不可少的一个步骤。由于应用只和IAP处理模块进行信息交互，所以如果IAP的信息没有从开发者社区同步到应用商店网店系统的话，IAP处理模块就无法获取IAP相关信息供应用查询。

对于IAP配置模块和IAP处理模块分设的情形，与实施例1中IAP功能模块都置于开发者社区中的结构的主要区别在于，增加了开发者社区和应用商店网店之间的IAP信息同步功能。当然，IAP配置模块和IAP处理模块在应用商店中放置于什么功能实体中，由具体实现来决定。在实施例3和4中，统一使用应用商店系统来进行IAP流程描述，这种描述都适用于这两种架构，也适用于其他的类似的变形的但原理相同的应用商店网店架构。

实施例3

该实施例详细描述了用增加了IAP功能模块的应用商店开发应用程序内购买功能的应用程序的方法。假设该应用是一个游戏，该游戏的某一个关卡需要购买后才能继续。开发者上传该游戏后需要在IAP管理模块中为该游戏设置一个可购买IAP项，假设该IAP项为某个游戏道具，名称为“XX游戏XX道具”，价格为1元。游戏玩家购买之后，应用商店将购买成功消息返回给该游戏，该玩家才能在游戏中使用该道具。

图15是根据实施例3的实现内建程序内购买的流程图，下面实施例的步骤主要描述了用户在使用应用的过程中的道具购买的步骤，从步骤描述中可以清晰的了解到这类应用程序内购买实现的整个流程：

步骤1501，用户打开应用程序，在应用程序的使用过程中触发应用内购买流程。以游戏为例，这种触发可以是用户点击游戏中的“购买道具”按钮唤出可购买道具的页面。

步骤1502，应用程序通过查询IAP可购买项接口向应用商店的IAP功能模块发起请求。

步骤1503，应用商店IAP模块查询该应用对应的IAP可购买项，将结果通过查询IAP可购买项接口的response接口返回给应用程序。

步骤1504，应用程序根据接口的返回内容将IAP可购买项显示在界面上供用户选择。

步骤1505，用户选择一件或多件IAP购买项，可以是一个游戏道具或多个游戏道具，选择购买。

步骤1506，应用程序根据用户的选择向应用商店发起购买请求。

步骤1507，应用商店扣费成功后，将购买成功消息返回给应用，应用授权用户使用购买到的道具。

在上述实施例中，用户开发该游戏时，已经为游戏设置了可购买的道具，并且在使用道具时设置了认证。也就是说，当用户购买了道具后，并不需要再更新应用程序版本或下载一个道具，而是在应用程序内部对道具是否可以使用进行了判断即可。

对于需要购买后下载内容的应用，将在下面的实施例4中进行描述。

实施例4

该实施例详细描述了用增加了IAP功能模块的应用商店实现应用程序内购买功能的应用程序的方法。该应用程序中，存在需要访问应用程序服务器获取内容的购买项。假设该应用是一个杂志阅读器。用户免费在应用商店下载了该杂志阅读器。但是如果需要看杂志，则需要订购杂志并支付一定的费用才行。

图16是根据实施例3的实现独立server程序内购买的流程图，下面实施例的步骤主要描述了用户在使用杂志阅读器的过程中购买杂志的步骤，从步骤描述中可以清晰的了解到这类应用程序内购买实现的整个流程：

步骤1601，用户在手机中打开杂志阅读器应用程序，点击刷新最新杂志，则应用程序通过接口访问杂志服务器查询最新可购买杂志。

步骤1602，杂志服务器查询目前可购买杂志，返回可购买项的对应ID列表给应用程序。

步骤1603，应用程序根据杂志服务器返回的ID列表向应用商店发起请求，要求查询IAP的商品ID对应的IAP产品具体信息，包括名称，价格等。

步骤1604，应用商店查询IAP ID对应的IAP购买项的具体信息包括名称，价格等信息，并将结果发送给应用程序。

步骤1605，应用程序根据应用商店的返回结果将可购买IAP产品的信息展现给用户，供用户购买。

步骤1606，用户选择一个或多个产品，请求购买。

步骤1607，应用程序将用户的购买请求发送给应用商店，购买请求的关键信息为：购买的IAP的对应ID，购买价格。

步骤1608，应用商店处理购买请求，对用户进行扣费，返回应用程序扣费成功或失败结果，如果扣费成功，需要在返回参数里携带收费凭证，该收费凭证可以为加密的字符串。

步骤1609a，应用程序判断收费结果，如果失败，则流程结束。

步骤1609b，应用程序判断收费结果，如果成功，则将扣费成功的结果发送给应用程序服务器。

步骤1610，应用程序服务器收到扣费凭证后，对扣费凭证中的加密字符串进行解密和校验，如果凭证合法则应用程序将用户所购买的杂志传递给用户。

步骤1611，应用程序获取到所购买的杂志，用户可以阅读自己购买成功的杂志，流程结束。

在上述流程中可以发现，应用商店和应用程序server之间未设置直接接口。因为，应用程序服务器的地址有可能会进行修改。在应用商店侧维护应用程序服务器的信息是不合理的。所以，开发者开发的应用程序在应用程序内购买流程中需要将一些信息在应用商店和应用程序server之间传送，比如步骤1610，当应用程序收到应用商店的扣费成功消息之后需要将这个信息传递的到应用程序server中。在这里有一个关键点是扣费凭证需要进行加密，否则一旦应用程序被篡改后会导致一系列的伪冒支付的传递信息。

一个比较简单的实施办法是，开发者在应用商店为应用申请一个校验码。应用商店在开发者手册中提供购买凭证加解密算法和校验规则。应用商店扣费成功后就使用该校验码对购买凭证进行加密。当购买凭证通过应用程序传递到应用程序服务器时，应用程序server根据校验码解密购买凭证，并根据应用商店提供的校验规则校验购买凭证，当判断购买凭证有效后将用户购买的内容或服务传递给用户。需要说明的是，以上的处理方式只是提供一个优选的方案，这种对购买凭证加密可以有各种更改和变化，只要原理相同均在本发明的保护范围之内。

在上述实施例中，开发者如果希望上传最新一期的杂志，则只需要去应用商店的IAP管理模块增加一个IAP购买项，比如说20XX年X月XX杂志，定价4元，应用商店为该IAP购买项分配一个IAP ID。开发者根据该IAP ID在应用商店服务维护杂志信息即可。用户在使用杂志阅读器下载最新一期杂志时，完全不需要更新应用程序。这种IAP功能管理的形式，减少了开发者的工作量，同时，也简化了用户的操作。

综上所述，通过本发明实施例提供的方案，开发者在开发具备应用内购买功能的应用时，无需在应用服务器中配置购买项购买功能，简化了开发者开发应用的复杂度。同时，通过该架构进行购买项的管理及维护是比较容易实现的，简化了用户的操作。

显然，本领域的技术人员应该明白，上述的本发明的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而可以将它们存储在存储装置中由计算装置来执行，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本发明不限制于任何特定的硬件和软件结合。

以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (18)

1.一种应用商店系统，包括开发者社区功能实体和应用商店网店功能实体，其特征在于还包括：

配置模块，用于接受为应用配置对应的购买项和对应于所述购买项的信息，其中，所述应用是通过所述开发者社区功能实体上传的；

应用内购买IAP处理模块，用于接收来自所述应用的购买请求，按照所述购买请求所请求购买的购买项对应的信息进行扣费。

2.根据权利要求1所述的系统，其特征在于，

所述配置模块和所述IAP处理模块位于所述开发者社区功能实体中；或者，

所述配置模块位于所述开发者社区功能实体中，所述IAP处理模块位于所述应用商店网店功能实体中，所述开发者社区功能实体和所述应用商店网店功能实体之间的接口用于将所述购买项和对应于所述购买项的信息同步至所述IAP处理模块。

3.根据权利要求1所述的系统，其特征在于，所述IAP处理模块包括：

购买请求接口，用于接收来自所述应用的所述购买请求，按照所述购买请求所请求购买的购买项对应的信息进行扣费。

4.根据权利要求3所述的系统，其特征在于，所述IAP处理模块还包括：

购买请求响应接口，用于在所述购买请求接口扣费成功的情况下，向所述应用返回购买成功消息。

5.根据权利要求4所述的系统，其特征在于，所述购买请求响应接口用于在扣费成功的购买项为所述应用中已下载的项目的情况下，返回携带有扣费成功的购买项的信息的所述购买成功消息；以及用于在扣费成功的购买项为所述应用中未下载的项目的情况下，返回携带有经过加密的扣费凭证的所述购买成功消息。

6.根据权利要求5所述的系统，其特征在于，在扣费成功的购买项为所述应用中待下载的项目的情况下，所述购买请求响应接口返回的所述购买成功消息中携带的经过加密的扣费凭证通过以下方式获得：

使用对应于所述应用的校验码并应用加密算法对扣费凭证进行加密，其中，所述校验码、对应于所述应用的加密算法和验证规则配置在用于供所述应用下载所述扣费成功的购买项的应用服务器中。

7.根据权利要求1所述的系统，其特征在于，所述IAP处理模块包括：

IAP查询接口，用于接收来自所述应用的查询请求，根据所述查询请求进行购买项的查询；

IAP查询响应接口，用于向所述应用返回查询到的购买项的信息。

8.根据权利要求1、3-7中任一项所述的系统，其特征在于，所述配置模块和所述IAP处理模块位于所述应用商店系统的IAP管理模块中。

9.根据权利要求8所述的系统，其特征在于，所述IAP管理模块设置在所述开发者社区功能实体中。

10.一种开发者社区功能实体，其特征在于包括：

配置模块，用于接受为应用配置对应的购买项和对应于所述购买项的信息，其中，所述应用是通过所述开发者社区功能实体上传的。

11.一种应用商店网店功能实体，其特征在于包括：

应用内购买IAP处理模块，用于接收来自应用的购买请求，按照所述购买请求所请求购买的购买项对应的信息进行扣费，其中，所述购买项和所述购买项对应的信息是通过开发者社区功能实体和所述应用商店网店功能实体之间的接口同步到所述IAP处理模块中的。

12.根据权利要求11所述的应用商店网店功能实体，其特征在于，所述IAP处理模块包括：

购买请求接口，用于接收来自所述应用的购买请求，按照所述购买请求所请求购买的购买项对应的信息进行扣费。

13.根据权利要求12所述的应用商店网店功能实体，其特征在于，所述IAP处理模块还包括：

购买请求响应接口，用于在所述购买请求接口扣费成功的情况下，向所述应用返回购买成功消息。

14.根据权利要求11所述的应用商店网店功能实体，其特征在于，所述IAP处理模块还包括：

IAP查询接口，用于接收来自所述应用的查询请求，根据所述查询请求进行购买项的查询；

IAP查询响应接口，用于向所述应用返回查询到的购买项的信息。

15.一种实现应用内购买IAP功能的方法，其特征在于包括：

响应于用户选定待购买的购买项的操作，应用向应用商店系统发送购买请求；

所述应用商店系统接收来自应用的购买请求，按照所述购买请求所请求购买的购买项对应的信息进行扣费。

16.根据权利要求15所述的方法，其特征在于，在所述应用商店系统接收来自应用的购买请求，按照所述购买请求所请求购买的购买项对应的信息进行扣费之后，还包括：

所述应用接收所述应用商店系统在扣费成功的情况下返回的购买成功消息；

在扣费成功的购买项为所述应用中已下载的项目的情况下，所述应用根据所述购买成功消息中携带的扣费成功的购买项的信息授权使用所述扣费成功的购买项；在扣费成功的购买项为所述应用中未下载的项目的情况下，所述应用将所述购买成功消息中携带的经过加密的扣费凭证发送至供所述应用下载所述扣费成功的购买项的应用服务器。

17.根据权利要求16所述的方法，其特征在于，在所述应用将所述购买成功消息中携带的经过加密的扣费凭证发送至供所述应用下载所述扣费成功的购买项的应用服务器之后，还包括：

所述应用服务器对所述经过加密的扣费凭证进行解密和校验，在所述扣费凭证合法的情况下，向所述应用传递所述扣费成功的购买项的服务内容。

18.根据权利要求15所述的方法，其特征在于，在应用向所述请求购买处理模块发送购买请求之前，还包括：

所述应用向所述应用商店系统发起查询请求；

所述应用商店系统根据所述查询请求进行购买项的查询，向所述应用返回查询到的购买项的信息；

所述应用显示接收到的购买项的信息。

Images