用于在云服务代理中多层计费的系统和方法与流程

本实用新型专利申请要求享有2016年12月28日提交的美国临时专利申请号62/439,619的公开内容的优先权，并通过引用将其并入本文。

本公开涉及一种计费系统和方法，更具体地，涉及一种用于在云服务代理中多层计费的系统和方法。

背景技术：

目前，许多软件供应商通过在线服务平台提供他们的软件。此类软件即服务(saas)平台允许saas订阅者/终端用户获取和使用由saas提供商托管的软件服务。saas，也称为“按需软件”，通常以按使用付费的方式定价，或使用订阅费。例如，saas订阅者可以向saas供应商支付每月(或每年)订阅费用，以便在特定时间段(例如，一个月)访问saas平台。相反，在按使用付费方案中，saas订阅者基于订阅者在给定时间段内对saas平台的使用情况向saas提供商付款。例如，可以基于每次使用的费率对订阅者收费，该使用是基于saas平台内的一个或多个资源来计量的。在这些“订阅者-供应商”方案中，订阅者和saas供应商之间的计费是一对一的关系，其中saas供应商的费用直接传递给订阅者，然后订阅者将支付该费用以确保继续访问saas平台。

在软件服务分销的替代系统中，使用云服务代理。云服务代理是一个充当订阅者/终端用户和saas供应商之间的中介的组织。云服务代理可以集成不同的软件服务(可从各种saas供应商获得)以向订阅者呈现统一的服务集(即，云服务包)。在某些情况下，云服务代理还托管软件服务并替代传统的saas供应商操作。此外，云服务代理允许为在不同级别的各种saas供应商提供和销售订阅，从而形成下游转售商的层级系统。这些转售商随后可以向次级转售商和终端用户转售服务。在某些情况下，这些转售商可能会以与saas供应商和/或云代理相比不同的定价方案为saas产品定价。

云服务代理系统中的计费通过云服务代理来管理，因为云服务代理是能够管理这种软件分销系统中的许多关系的唯一实体。云代理系统中计费的复杂性是由于saas供应商类型的混合，转售商的影响以及每个实体提供的各种计费方案而产生的。例如，云服务包可以包括来自多个saas供应商的多个软件服务。云服务包中的这些多个软件服务中的每一个可以包括各种计费方案(例如，基于使用和基于订阅的方案的组合，并且每个具有不同的奖励和计费属性)。此外，下游转售商可以为云服务包提供他们自己独特的定价方案。

当订阅者终端用户从云服务代理或下游转售商获得软件服务时，这些订阅者终端用户的计费不是像传统的“订阅者-供应商”方案中那样的一对一关系。相反，可以基于云服务代理分销通道的层内的不同定价来对云服务代理方案中的订阅者终端用户进行计费。因此，实现这样的计费方案必须考虑来自整个层级中的实体(即saas供应商、转售商、次级转售商等)的计费规则和计费方案的变化。此外，来自上游实体(例如saas供应商)和下游实体(例如转售商)的计费规则之间可能存在差异，从而基于一个特定实体计费方案对订阅者终端用户应用的计费是不合适的。例如，固定加价和折扣可以由上游实体(例如saas供应商)应用，这些加价和折扣可能不适合下游实体(例如，转售商的终端用户)。类似地，如果在软件分销系统的每个级别上应用相同的计费规则，则将导致非灵活的合同和软件服务分销规则。另外，不能基于分销通道中的特定类型的实体来定制定价(以及相应的计费规则)。例如，可以对直接订阅者终端用户与间接订阅者终端用户用不同方式收费。这导致软件分销系统的不同元素间的收入损失。最后，还不能进行批发购买要按照不同的计费规则分销的服务，这也导致较大的服务分销商失去机会。

因此，需要一种改进的用于在云服务代理中多层计费的系统和方法。

技术实现要素：

在本公开的至少一个实施例中，提供了一种用于在云服务代理中多层计费的系统。所述系统包括服务供应商、云代理和诸如第一转售商、第二转售商和第三转售商的不同层级的转售商。所述系统还包括终端客户，其中终端客户可以直接地从服务供应商，或间接地通过转售商接收服务。

在本公开的至少一个实施例中，用于在云服务代理中多层计费的系统包括市场、服务提供商数据库、合作伙伴数据库、市场代理、联合连接器、事务中介器、使用数据库、供应数据库、连接器、调度器和网络。

在本公开的至少一个实施例中，市场代理被配置为管理在系统中的各种实体之间建立的合同。

在本公开的至少一个实施例中，市场代理被配置为存储可用服务的目录，其被配置为监视连接器的计费使用，并且包括联合连接器。

在本公开的至少一个实施例中，市场代理被配置为经由市场向合作伙伴销售服务。

在本公开的至少一个实施例中，市场还包括被配置为存储关于通过系统的所有事务的账单信息的事务中介器。市场还被配置为存储关于通过系统的所有事务的特定于对账的细节

在本公开的至少一个实施例中，云代理可以由合作伙伴操作，合作伙伴操作以向订阅者提供服务供应商的服务。

在本公开的至少一个实施例中，云代理还被配置为维护转售商和次级转售商的层级结构。

在本公开的至少一个实施例中，云代理和市场代理可以作为单个实体操作。

在本公开的至少一个实施例中，提供了一种用于在云服务代理中多层计费的方法。所述方法包括：确定在计费时段上应用的事务，发起事务，其中基于事务属性更新或发起订阅者的计费周期，计算计费时段费用，确定服务供应商和云代理之间的合同，以及计算每个时段的代理销售。

在本公开的至少一个实施例中，所述方法包括维护每个服务供应商的合同和订阅的记录，以及计算在特定计费时段期间服务的每个单独费用。

在本公开的至少一个实施例中，所述方法包括计算每个服务供应商处的费用，计算云代理处的服务费用，计算转售商处的费用，以及为终端客户生成合并账单。

在本公开的至少一个实施例中，为每个服务供应商、云代理、转售商计算费用，并且为终端客户生成合并账单。

在本公开的至少一个实施例中，所述方法包括向事务中介器报告供应操作的属性，将数据存储在服务使用数据库中，请求服务使用报告以与服务供应商对账，接收服务供应商计费规则，计算服务的总使用量，将报告发送到联合连接器，将报告传送到市场代理，应用服务供应商的定价模型来创建使用报告以与服务供应商进行对账，请求服务使用报告以用于为合作伙伴开账单，从合作伙伴的订阅接收计费规则，计算服务的总使用量，将报告发送到联合连接器，将报告发送给市场代理，应用来自合作伙伴的定价模型，以及给合作伙伴开账单。

附图说明

图1示出了用于在云服务代理中多层计费的系统的示意图。

图1a示出了用于在云服务代理中多层计费的系统的示意图。

图1b示出了用于在云服务代理中多层计费的系统的示意图。

图2示出了用于在云服务代理中多层计费的系统的示意图。

图2a示出了用于在云服务代理中多层计费的方法的流程图和组件。

图2b示出了用于在云服务代理中多层计费的方法的流程图和组件。

图2c示出了用于在云服务代理中多层计费的方法的流程图和组件。

图3示出了用于在云服务代理中多层计费的方法的流程图和组件。

图4示出了用于在云服务代理中多层计费的方法的流程图和组件。

图5示出了用于在云服务代理中多层计费的方法的流程图和组件。

图6示出了用于在云服务代理中多层计费的系统的方法。

具体实施方式

现在将详细参考本公开的优选实施例，其示例在附图中示出。本公开的附加特征和优点将在随后的描述中阐述，并且将从描述中变得显而易见，或者可以通过本公开的实践来学习。应理解，前面的一般性描述和以下的详细描述都是示例性和说明性的，并且旨在提供对要求保护的本公开的进一步说明。

现在参考图1，示出了用于在云服务代理中多层计费的系统，一般性地用100表示。系统100包括服务供应商102、云代理104、第一转售商106、第二转售商108、第三转售商110和终端客户112。

在本公开的至少一个实施例中，服务供应商102是向其顾客(例如，不同大小的商业企业或客户)提供服务订阅的实体。为清楚起见，服务供应商102也可以称为“服务提供商”，并且应该理解，这两个术语可以互换使用。另外，服务供应商102可以提供对位于独立软件供应商的托管服务器(未示出)上的应用和服务的订阅。服务供应商102还可以托管客户订阅的服务。服务供应商102可以是开发、支持和运行服务的软件开发公司(通常在他们自己的云基础设施上)。服务供应商102还销售并提供对其服务的订阅。应当理解，服务供应商102为其每项服务提供应用程序编程接口(api)。api可以包括由服务供应商102提供的一组类、过程、函数、结构和常量，以用于外部应用程序。服务供应商102可以包括多个服务供应商(例如服务供应商102a、102b和102c)，例如网络服务和多个服务供应商102中的每一个提供各种软件服务，例如电子邮件、网络托管、文件共享和存储、网络、电话、消息收发、视频会议、一般通信、企业资源规划(erp)、客户关系管理(crm)、供应链管理，仅举几个非限制性示例。应当理解，服务供应商102可以直接向转售商或终端客户提供他们的服务。

在本公开的至少一个实施例中，服务供应商102被配置为监视转售商和终端客户对其服务的使用。例如，服务供应商102a(office)可以被配置为监视由订阅者使用服务供应商102a的服务引起的计算资源使用。应当理解，计算资源可以包括从由基于每次使用的一个或多个计算资源、一个或多个读取和写入i/o操作以及网络带宽使用(仅举几个非限制性示例)组成的组中选择的至少一个计量度量。将进一步理解，计量使用可以在一个或多个应用程序编程接口(api)处进行。还应当理解，从这种监视获得的度量可以存储在服务供应商102的环境中，或者可以传输到系统100中的其他实体，例如，通过因特网。

应当理解，服务供应商102可以被配置为应用他们自己的计费规则。例如，服务供应商102b(例如网络服务)可以应用统一费率的月度定价结构，而服务供应商102c(例如，)可以应用与计算资源的使用相对应的费率。将进一步了解，服务供应商102可以将计费规则发送到系统100中的其他实体。

在本公开的至少一个实施例中，系统100还包括云代理104。云代理104是经由api集成不同软件服务(例如，来自服务供应商102)并提供将对服务供应商102的服务的订阅供应、销售给各种其他实体(例如，转售商和终端客户)的功能的实体。应当理解，云代理104为不同类型的服务供应商102提供用户接口。例如，提供通信服务(例如，电子邮件)的服务供应商将具有与托管或存储服务供应商(例如，dropbox)不同的接口。将进一步理解，提供不同的接口支持转售商的层级系统，如本文进一步公开的。

在本公开的至少一个实施例中，系统100还包括处于不同层级的转售商。例如，第一转售商106可以是基于地理位置的转售商(例如，第一转售商106a服务于美国，第一转售商106b服务于法国，第一转售商106c服务于巴西)。系统100还可以包括下游转售商，例如第二转售商108和第三转售商110。可以基于任何因素来组织转售商，例如地理分布、行业垂直、客户垂直或技术垂直，仅举几个非限制性示例。尽管仅示出了选定数量的转售商和下游转售商，但是应当理解，系统100可以包括通过本领域公知类型的软件和硬件系统(例如因特网)连接的任何数量的转售商和下游转售商，它们可共同操作以执行根据本公开委托给转售商的功能。

在本公开的至少一个实施例中，系统100还包括终端客户112。终端客户112可以包括订阅由服务供应商102提供的服务的个人或企业组织(或者至少可以包括源自服务供应商102的服务)。应当理解，终端客户102可以直接从服务供应商102接收服务，或者间接地通过转售商接收服务。例如，参考图1，终端客户112a可以从第二转售商108a接收服务，其中第二转售商108a是第一转售商106a的下游转售商。类似地，终端客户112b可以从第三转售商110b接收服务，其中第三转售商110b是第二转售商108b的下游转售商，并且进而其中第二转售商108b是第一转售商106a的下游转售商。应当理解，每个转售商被配置为使用他们自己的计费和定价方案，使得每个终端客户112可能接收不同的定价和计费条款，即使他们订阅来自服务供应商102的相同的服务。

现在参考图1a，示出了用于在云服务代理中多层计费的系统，一般性地以120表示。系统120包括市场122、服务提供商数据库124、合作伙伴数据库126、市场代理128、联合连接器130、事务中介器132、使用数据库134、供应数据库136、连接器138、调度器140和网络142。

在本公开的至少一个实施例中，服务提供商数据库124、合作伙伴数据库126、使用数据库134和供应数据库136存储由系统120生成和/或从一个或多个信息源检索的信息。在本公开的至少一个实施例中，服务提供商数据库124和合作伙伴数据库126可以与市场代理128“关联”，并且使用数据库134和供应数据库136可以与事务中介器132“关联”，如图1a的实施例所示。服务提供商数据库124、合作伙伴数据库126、使用数据库134和供应数据库136中的每一个也可以与远离市场122的服务器或计算设备“关联”，只要远程服务器或计算设备能够与市场122进行双向数据传输，例如，在amazonaws、rackspace或其他虚拟基础设施或任何商业网络中。在本公开的至少一个实施例中，市场122上的服务提供商数据库124、合作伙伴数据库126、使用数据库134和供应数据库136中的每一个以电子方式连接到市场122(例如，通过网络142)和其组件，使得它们能够彼此进行连续的双向数据传输。

为了清楚起见，图1a中示出了服务提供商数据库124、合作伙伴数据库126、使用数据库134和供应数据库136中的每一个，并且称为单个数据库。本领域普通技术人员将理解，服务提供商数据库124、合作伙伴数据库126、使用数据库134和供应数据库136中的每一个可以包括通过本领域公知类型的软件系统连接的多个数据库，它们共同可操作以执行根据本公开委托给服务提供商数据库124、合作伙伴数据库126、使用数据库134和供应数据库136中的每一个的功能。服务提供商数据库124、合作伙伴数据库126、使用数据库134和供应数据库136中的每一个也可以是分布式数据架构的一部分，例如，用于大数据服务的hadoop架构。服务提供商数据库124、合作伙伴数据库126、使用数据库134和供应数据库136中的每一个可以包括关系数据库架构、nosql、olap或数据库领域中公知类型的其他数据库架构。服务提供商数据库124、合作伙伴数据库126、使用数据库134和供应数据库136中的每一个可以包括许多公知的数据库管理系统之一，例如，microsoft的sqlserver、microsoft的access、mongodb、redis、hadoop、或ibm的db2数据库管理系统，或可从oracle或sybase购得的数据库管理系统。如本文进一步公开的，服务提供商数据库124、合作伙伴数据库126、使用数据库134和供应数据库136中的每一个可检索地存储传送给它的信息。

在本公开的至少一个实施例中，市场代理128被配置为管理在系统100中的各种实体之间建立的合同(例如，服务供应商102、云代理104、第一转售商106、终端客户112等)。例如，对多个服务供应商102中的任何一个提供的服务的每次订阅都由合同约束，其中合同记录了服务的条款，例如定价、许可费用和服务水平协议，仅举几个非限制性示例。类似地，转售商(例如，第一转售商106)可以具有附加(或不同)合同条款，其中终端客户112的服务接收受到转售商合同条款的约束，而不是服务供应商合同的条款。在这样的示例性实施例中，供应、销售和修改特定服务的可能性由服务供应商102的适用合同条款管理。

在本公开的至少一个实施例中，市场代理128被配置为存储可用服务的目录(即，由服务供应商或转售商提供的服务)。当服务供应商102与市场122签订合同时，服务供应商102提供的服务被认为是“可用的”。在分配合同的过程中，服务提供商102可以提供服务计划、每项服务的计费规则(例如，sku，如本文进一步公开的)和与市场122的连接器(例如，连接器138)。服务供应商102的计划和计费规则存储在服务提供商数据库124中。

在本公开的至少一个实施例中，市场代理128还被配置为监视连接器138的计费使用。例如，合作伙伴104a可以是希望基于服务供应商102提供服务的实体。当合作伙伴104a基于服务供应商102创建新服务供应时，合作伙伴104a使用连接器138可操作地连接到市场122，使得服务供应商112的服务可以被签约。这可以被视为“供应”。例如，参考图1a，云代理104可以由合作伙伴104a操作，其中合作伙伴104a期望提供服务供应商102的服务。在这样的示例性实施例中，通过使用连接器138经由市场122使合作伙伴104a“可用”(即，通过使用连接器138使服务供应商102对合作伙伴104a来说可用)。继续该示例，合作伙伴104a现在可以在供应之后向转售商106或甚至终端客户112提供服务。

在本公开的至少一个实施例中，市场122还包括联合连接器130，联合连接器130被配置为从事务中介器132接收基于合作伙伴订阅的使用报告(如本文进一步公开的)。例如，市场代理和合作伙伴之间的合同可能要求在每月的第一天发送账单，其中联合连接器130在每月的第一天将请求发送到事务中介器132，以接收必要的数据。

在本公开的至少一个实施例中，市场122还包括连接器138。连接器138专门针对每项服务(例如，由任何服务供应商102提供的服务)配置。对于多个服务供应商102中的每一个(例如，如图1所示)，连接器138被配置为将一个订阅与另一个订阅区分开，如本文进一步公开的。连接器138被配置为识别服务的来源(即，服务供应商102的身份)和服务的目的地(例如，终端客户112的身份)。应当理解，连接器138还可以在供应服务期间接收关于服务的信息。在本公开的至少一个实施例中，连接器138被配置为定义合作伙伴104a及其订阅，因为连接器138基于每个伙伴订阅部署。应当理解，任何租户(例如，终端客户112)和终端用户id由云代理104生成，并且当多个服务供应商102中的每一个向连接器138确认供应已成功完成时，服务供应商102生成订阅id。将进一步理解，尽管示出了单个连接器138，但是系统120可以根据需要包括多个连接器138以支持多个服务供应商102中的每一个。例如，如果市场代理128购买了n个不同的服务的n个订阅，市场122可以为n个不同服务中的每一个提供n个连接器138实例。

在本公开的至少一个实施例中，市场代理128被配置为根据针对该特定合作伙伴的服务计划经由市场122将服务销售给合作伙伴(例如，合作伙伴104a)。应当理解，对于合作伙伴服务的每次销售，市场代理128向连接器集线器(未示出，但如美国申请序列号15/005,151中所公开的，使用连接器集线器服务提供应用，该申请通过引用将其全部并入本文中)发送请求以部署用于合作伙伴(例如，合作伙伴104a)的连接器实例(例如，连接器138)以与市场122可操作地连接，并且调整供应通道。同时，市场代理128经由联合连接器130和事务中介器132向合作伙伴提供计费服务。应当理解，市场代理128以与云代理104相同的方式操作但是云代理104提供了将软件作为服务销售的通道，而市场代理128提供了提供最终作为服务销售的服务的机制。

在本公开的至少一个实施例中，例如，当完成服务的供应时，连接器138可操作地连接到事务中介器132。连接器138还被配置为向事务中介器132报告，其中报告包括激活日期、供应、取消、改变、服务id(如本文进一步公开的)、云服务代理的标识、服务的数量、诸如激活、改变和取消之类的动作的标记，仅举几个非限制性示例。将进一步理解，连接器138可以报告层级计费系统内的实体的id。例如，实体可以包括第一转售商106、第二转售商108、第三转售商110和终端客户112。连接器138还进行操作以对事务中介器132的活动进行分析。

在本公开的至少一个实施例中，系统120还包括可操作地连接到连接器138的调度器140。应当理解，在示例性实施例中，销售服务包括磁盘空间、cpu时间(随用随付服务)。调度器140被配置为通过向适用的服务供应商102发送周期性请求来提供对资源使用的跟踪(例如，磁盘空间使用、cpu时间)，以检索这样的信息。调度器140还被配置为根据需要或周期性地将资源使用信息发送到事务中介器132。

在本公开的至少一个实施例中，市场122还包括事务中介器132。事务中介器132被配置为存储关于通过系统120的所有事务的计费信息。例如，终端客户112和服务供应商102a之间的事务可以是诸如购买来自服务供应商102a的软件、升级来自服务供应商102a的软件和/或服务、降级来自服务供应商102a的软件和/或服务、取消来自服务供应商102a的服务等类型。在本公开的至少一个实施例中，事务中介器132还被配置为跟踪服务标识符，服务标识符是与事务相关的资源类型的字母数字标识符。事务中介器132还被配置为跟踪度量单位(uom)，例如，服务供应商102的订阅者正在使用的单元或许可证的数量。事务中介器132还可以跟踪服务使用的数量以及开始和结束日期，以及从服务供应商102接收对计算资源使用和计费规则的任何计量或监视，以命名一些非限制性示例。

在本公开的至少一个实施例中，市场122还被配置为经由事务中介器132存储关于通过系统120的所有事务的特定于对账的细节。例如，多个服务供应商102中的每一个可以具有与其相关联的供应商标识符(id)。事务中介器132还被配置为收集其他标识符，例如服务供应商侧数据(例如，订阅id)、任何其他唯一标识符、任何转售商或终端客户的合作伙伴标识符或订阅id、合作伙伴侧数据(例如终端客户的订阅id)和订单标识符。

应当理解，对于每个事务，事务中介器132必须存储报告所需的最少量数据(如果适用)、供应商的身份、转售商的身份、终端客户的身份、来自服务供应商102和转售商(例如，第一转售商106、第二转售商108、第三转售商110)的计费规则，以及系统100中的每个实体的使用和定价。

在本公开的至少一个实施例中，云代理104可以由合作伙伴104a操作，合作伙伴104a操作以向订阅者提供服务供应商102的服务。应当理解，云代理104还被配置为接收所有通过请求所跟踪的资源类型、按资源类型所聚合的，且根据服务供应商102(或转售商)所提出的条款分摊的使用信息。继续前面的示例，如果服务供应商102a被配置为基于订阅者引起的计算资源使用而计费，则供应商102a可以跟踪该信息，并且事务中介器132被配置为接收该信息。

在本公开的至少一个实施例中，云代理104还被配置为维护转售商和次级转售商的层级结构。例如，云代理104可以服务第一转售商106、第二转售商108、第三转售商110和终端客户112(如图1所示)。在这样的示例性实施例中，云代理104被配置为捕获和维护订阅实体对云服务的消费。应当理解，云代理104被配置为使得合作伙伴能够捕获并对订阅者(例如，终端客户112)的使用计费，而市场代理128可以操作以向合作伙伴对连接器138的使用的计费。

应当理解，事务中介器132还配置有软件代理以记录在终端客户112和服务供应商102之间传递的指示云服务的单独可计费供应操作的事务。在本公开的至少一个实施例中，然后处理与事务相关的信息并将其传递到中央系统(例如，市场122)，在中央系统中可以提取它以用于计费目的。将进一步理解，通过监视供应流程，云代理104可以提供实时计费信息，而不需要依赖由服务供应商102的数据应用的相同计费规则。

在本公开的至少一个实施例中，云代理104和市场代理128可以作为单个实体操作，如图1b中的系统150所示。应当理解，市场代理128可以执行与云代理104相同的功能，如本文进一步公开的。

在本公开的至少一个实施例中，系统150包括第一转售商106、第二转售商108、第三转售商110和终端客户112。应当理解，第二转售商108可以包括次级转售商，如上所述，其中次级转售商操作以进一步转售来自第一转售商106的服务。将进一步理解的是，第三转售商110可以包括订阅来自市场代理128的服务的租户，其中租户操作以使用服务。将进一步理解，终端客户112可以是租户的终端用户(例如，已订阅服务的公司租户的雇员终端用户)，或转售商类型实体的终端用户(例如，由转售商110提供的集成软件服务的直接客户)。

在本公开的至少一个实施例中，市场代理128可操作地配置为根据需要供应第一转售商106、第二转售商108、第三转售商110和终端客户112，以便各方执行其自己的计费和定价规则，如本文进一步公开的。

现在参考图2，示出了用于在云服务代理中多层计费的方法的流程图和组件，一般性地以200表示。流程图200包括在计费时段204上应用的事务202。在本公开的至少一个实施例中，事务202包括购买210、附加购买212、升级214、降级216和取消218。尽管仅示出了挑选的事务，但是仍然可以理解，事务202可以包括由在云服务代理中多层计费的普通技术人员所熟知和实践的任何类型的事务。

在本公开的至少一个实施例中，每个事务202可以包括事务属性，例如服务开始日期、计费周期和任何奖励，仅举几个非限制性示例。例如，购买210包括以月为计费周期(即计费周期是一个月)；并且，奖励包括第一个月的免费服务。应当理解，事务属性(也称为计费规则)来自系统100中的各种实体(例如，云代理104、第一转售商106等)之间的合同。还将理解，对于每个事务202，可以包括其他计费规则，例如，免费时段、完全支付、购买和/或取消的分摊、附加购买、升级、降级、对齐(例如，在父订阅和子订阅之间的计费时段的对齐)和周年日。

在本公开的至少一个实施例中，订阅者(例如，终端客户112)可以发起事务，由此基于事务属性更新或发起订阅者的计费周期。例如，购买210是购买服务的事务。购买210的属性包括每月节奏(即，以月为计费周期)，其中第一个月的免费服务作为奖励。因此，在第一个计费周期(即第一个月)中，订阅者不收取任何费用。类似地，相同的订阅者可以在几个月之后发起附加购买212。在这样的示例中，附加购买212的费用被添加到订阅者服务的总费用中。如图2所示，订阅者费用210a在第三个月由订阅者费用212a补充。附加购买212的属性表明其计费周期与父购买(即购买210)的计费周期对齐。因此，附加购买212将在与购买210相同的计费周期期间计费。如图2所示，附加购买212包括作为奖励的免费第一个月。应当理解，附加购买212可以具有其自己的对齐属性，使得其计费周期不与父购买(即购买210)的计费周期对齐。

在本公开的至少一个实施例中，订阅者还可能想要升级服务。例如，可以发起升级214事务(例如，在市场122处)，由此将订阅者费用214a修改为升级的订阅者费用214b(如图2所示)。升级214包括“旧”时段期间的分摊属性和“新”时段期间的分摊。应当理解，在发起升级214的计费周期期间，从订阅者费用214a到订阅者费用214b的转换使得订阅者的费用按照转换的任一侧的月度计费周期分摊(即，基于从计费周期的开始到升级之前的订阅者费用214a来对订阅者进行分摊；并且基于从升级点到计费周期结束的订阅者费用214b来对订阅者进行分摊)。

在本公开的至少一个实施例中，基于订阅者产生的多个费用的总和，在每个计费时段结束时计算计费时段费用220。例如，在计费周期220a期间，并且假设一个订阅者已经发起了所有事务202，订阅者的费用可以包括订阅者费用210a、订阅者费用212a、订阅者费用214a、订阅者费用216a(包括转换到降级)。可以理解，计费时段220a的费用是订阅者产生的所有单独服务费用的总和。将进一步理解，这些费用可以包括每个转售商的费用、每个终端客户费用、或每个服务供应商的费用，仅举几个非限制性示例。

现在参考图2a，示出了根据本公开的至少一个实施例的用于在云服务代理中多层计费的示例性方法的示例240。在示例240中，定义服务供应商和云代理之间的合同，其中创建多个对服务供应商的订阅(即，对计划p1的订阅、对计划p2的订阅、以及对计划p3的订阅、并且其中每个计费时段计划p1费用为100美元、计划p2费用为200美元、计划p3费用为300美元)。应当理解，多个订阅中的每个订阅包括多个计费属性。在示例240中，多个订阅中的每个订阅具有订阅对齐，其中周年日期落在每个月的第十(10)天(这是多个订阅中的每个订阅的每个计费时段的开始/结束)。此外，多个订阅中的每个订阅包括促销时段，其中服务供应商提供直到第一个周年日期的免费时段。多个订阅中的每个订阅还包括在每个计费时段结束之后分摊和发账单的供应。应当理解，每个订阅的计费属性可以取决于服务供应商102。

继续示例240，第一订阅者(例如，终端客户112)可以最初订阅服务计划p1，如250a所示；第二订阅者最初可以订阅服务计划p3，如252a所示；并且第三订阅者可以最初订阅服务计划p3，如254a所示。在计费周期结束时，对于每个订阅者，服务供应商102将向相应的云代理(例如，云代理104)发送计费账单，如260b、262b、264b、266b和268b所示。例如，260b表示在计费时段260a期间订阅计划p1、p2和p3的总费用。在本示例中，260b处的费用是0美元，因为每个计划包括在第一周年结束时的促销免费服务时段，如上所述。类似地，在262b(计费时段262a的费用)处，计划p1的费用是100美元，计划p2的费用是0美元，计划p3的费用是600美元。

继续上述示例，在图2b中示出了云代理104与其订阅者(例如，终端客户112a、112b、112c、112d)之间的合同，其中订阅者注册了每月订阅。如图2b所示，对于订阅者，计划p1花费120美元、计划p2花费240美元、计划p3花费360美元。还应当理解，应用于每个计划的属性包括：订阅对齐，其中周年日落在购买日；无免费时段；计划变更不予退款；按比例取消；以及预付费用。

在图2b中所示的计费模型之后，每个时段的代理销售270是根据计费时段的总销售额的。例如，在时段270b期间，计划p1的总费用为120美元，计划p2的总费用为0美元，计划p3的总费用为720美元。同样，对于时段272b，计划p1的总费用为120美元，计划p2的总费用为0美元，计划p3的总费用为720美元。继续这个例子，在时段274b，计划p1的总费用是120美元，计划p2的总费用是240美元，计划p3的总费用是720美元。

在本公开的至少一个实施例中，系统100还被配置为维护每个服务供应商(例如服务供应商102)、转售商(例如转售商106)和终端客户(例如，终端客户112)的合同和订阅的记录。应当理解，这允许层次结构中的每个实体执行对账和损益分析。例如，参考图2c，示出了云代理104的代理销售270与云代理104的代理支付272之间的结算和对账。在该示例中，计划p1的时段270b中的代理销售是120美元，而计划p1的相同计费时段期间的代理支付为0美元，如260b所示。如图2c所示，可以理解，对于任何计费时段，在代理销售270和代理支付272之间存在结算和对账。

现在参考图3，示出了用于在云服务代理中多层计费的方法的流程图和组件，一般性地以300表示。流程图300示出了服务302、服务属性302a、计费时段310和月度费用312。在本公开的至少一个实施例中，每个服务302表示已经由订阅者(例如，终端客户112)订阅的服务。应当理解，当服务供应商102与云代理104签订合同以经由云代理104销售服务时，可以从云代理104接收服务302。在本公开的至少一个实施例中，每个服务302具有与其相关联的服务属性302a。例如，服务标识符“sku-c3”包括属性“a”、“f”和“p”，其中“a”表示sku-c3对齐；“f”表示它有一个免费的第一时段；并且“p”表示例如在取消期间分摊。

在本公开的至少一个实施例中，在特定计费时段310期间，通过将服务的每个单独费用相加来计算每个月度费用312。例如，在计费时段310b期间(2月)，月度总费用312b包括与sku-a1、sku-b2、sku-c3(afp)、sku-c3(afp)、sku-d4(apf)和sku-d4(uff)相关联的费用。应当理解，月度费用312中的每一个是基于每个服务属性302a通过将与服务302相关联的每个单独费用相加来计算的。

现在参考图4，示出了用于在云服务代理中多层计费的方法的流程图和组件，一般性地以400表示。在本公开的至少一个实施例中，生成销售订单402。销售订单402指示订阅时段404，其中订阅时段被划分为多个计费时段(406a、406b和406c)。对于每个计费时段，计算计费费用。例如，在计费时段406a中，计算计费前期订单408a。在计费时段406a结束时，收集使用情况。在计费时段406a结束时，计算计费后期订单410a。应当理解，订阅时段404可以基于销售订单402或订阅者与服务提供商(例如，服务供应商102或转售商)或者甚至是终端客户之间的一些其他商定的合同条款被划分为多个计费时段。

现在参考图5，示出了用于在云服务代理中多层计费的方法和组件，一般性地以500表示。方法500包括计算在每个服务供应商102处的费用的步骤502、计算在云代理104处的服务费用的步骤504、计算在转售商106a和108a处的费用的步骤508、以及为终端客户112a生成合并账单的步骤510。

在本公开的至少一个实施例中，在步骤502，为每个服务供应商102计算费用。例如，云代理104具有从第一次建立服务供应商102(即，变得“可用”)时起每个服务供应商102的合同信息。对于每个服务供应商102，开发了基于合同的定价方案。例如，服务供应商102a可以基于许可结构按照月度计费周期收费，其中计费周年日在每月的第4天，并且在该时段结束时支付。类似地，作为示例，服务供应商102b可以改为基于“随用随付”方案按照季度计费周期，周年日期落在每月的第5天，并且在该计费时段结束时支付。

在本公开的至少一个实施例中，在步骤504，计算在云代理104处的费用。例如，云代理104可能必须按照月度计费时段生成计费账单，即使服务供应商102b按照季度计费。在这样的示例性实施例中，云代理104被配置为如果服务供应商的计费时段在将来，则基于预期费用计算费用。

在本公开的至少一个实施例中，在步骤508，为转售商106a和108a计算费用。再次，转售商106a和108a中的每一个可以具有独立的合同条款，使得计费特征和服务供应商102a的不同。例如，在转售商108a处，服务供应商102a的周年日可以落在每月的15日，但是如所指出的，服务供应商102a在每月的第4天计费。

在本公开的至少一个实施例中，在步骤510，为终端客户112a生成合并账单。应当理解，对于终端客户112a，生成单个账单，使得由终端客户112a的订阅产生的所有费用会基于终端客户112a的计费特征生成到单个账单上。应当理解，终端客户112a的计费特征可以与上游实体(例如服务供应商102和转售商106a和108a)的计费特征不同。

现在参考图6，示出了用于在云服务代理中多层计费的方法，一般性地以600表示。在本公开的至少一个实施例中，所述方法包括：步骤602，连接器138向事务中介器132报告供应操作的属性；步骤604，事务中介器132将数据存储在服务使用数据库134中；步骤606，联合连接器130请求服务使用报告以与服务供应商102进行对账；步骤608，事务中介器132接收服务供应商102的计费规则以确定服务使用；步骤610，事务中介器132计算服务的总使用量；步骤612，事务中介器132将报告发送到联合连接器130；步骤614，联合连接器130将报告发送到市场代理128；步骤616，市场代理128应用服务供应商102的定价模型以创建用于与服务供应商102进行对账的使用报告；步骤618，联合连接器130请求服务使用报告，以给合作伙伴104a开账单；步骤620，事务中介器132从合作伙伴104a的订阅接收计费规则，并且事务中介器132应用计费规则以确定服务使用数据；步骤622，事务中介器132计算服务的总使用量；步骤624，事务中介器132将报告发送到联合连接器130；步骤626，联合连接器132将报告传输到市场代理128；以及步骤628，市场代理128针对使用报告，应用来自合作伙伴104a的订阅的定价模型，并给合作伙伴104a开账单。

尽管已经在附图和前面的描述中详细图示和描述了本发明，但是其被认为是说明性的而不是限制性的，应当理解，仅示出和描述了某些实施例并且希望保护本发明的精神内的所有的变化和修改。